In one embodiment, a script executes code on a testing device to automatically control a control device. A media player on the control device interacts with a video streaming service. The testing device receives events from the control device based on the control device being controlled by the script to perform actions. The actions performed by the control device results in the events being asynchronously sent to the testing device. The events is then stored in the event buffer. The script initiates a wait for routine that waits for a target event to occur before execution of the script can continue and receives the events from the event buffer where the events are stored in the event buffer. The script then analyzes the events to determine if the target event occurred to allow the script to continue execution.
|
1. A method comprising:
executing, by a script on a testing device, code to automatically control a control device that is remotely located from the testing device, wherein, during the control, a media player on the control device interacts with a video streaming service remotely located from the control device;
determining, by the script, when to start storing events in an event buffer based on the executing of the code;
receiving, by the testing device, a set of events from the control device based on the control device being controlled by the script to perform a set of actions related to interacting with the video streaming service, wherein the set of actions performed by the control device results in the set of events being asynchronously sent to the testing device;
storing, by the testing device, the set of events in the event buffer;
initiating, by the script, a wait for routine that waits for a target event to occur before execution of the script can continue;
receiving, by the script, the set of events from the event buffer, the set of events being stored in the event buffer based on the determining of when to start storing events in the event buffer; and
analyzing, by the script, the set of events to determine if the target event occurred to allow the script to continue execution, wherein the target event was stored in the event buffer before initiating the wait for routine.
20. A system comprising:
a control device comprising a media player; and
a testing device configured for:
executing, by a script on the testing device, code to automatically control the control device that is remotely located from the testing device, wherein, during the control, a media player on the control device interacts with a video streaming service remotely located from the control device;
determining, by the script, when to start storing events in an event buffer based on the executing of the code;
receiving, by the testing device, a set of events from the control device based on the control device being controlled by the script to perform a set of actions related to interacting with the video streaming service, wherein the set of actions performed by the control device results in the set of events being asynchronously sent to the testing device;
storing, by the testing device, the set of events in the event buffer;
initiating, by the script, a wait for routine that waits for a target event to occur before execution of the script can continue;
receiving, by the script, the set of events from the event buffer, the set of events being stored in the event buffer based on the determining of when to start storing events in the event buffer; and
analyzing, by the script, the set of events to determine if the target event occurred to allow the script to continue execution, wherein the target event was stored in the event buffer before initiating the wait for routine.
11. A non-transitory computer-readable storage medium containing instructions, that when executed, control a computer system to be configured for:
executing, by a script on a testing device, code to automatically control a control device that is remotely located from the testing device, wherein, during the control, a media player on the control device interacts with a video streaming service remotely located from the control device;
determining, by the script, when to start storing events in an event buffer based on the executing of the code;
receiving, by the testing device, a set of events from the control device based on the control device being controlled by the script to perform a set of actions related to interacting with the video streaming service, wherein the set of actions performed by the control device results in the set of events being asynchronously sent to the testing device;
storing, by the testing device, the set of events in the event buffer;
initiating, by the script, a wait for routine that waits for a target event to occur before execution of the script can continue;
receiving, by the script, the set of events from the event buffer, the set of events being stored in the event buffer based on the determining of when to start storing events in the event buffer; and
analyzing, by the script, the set of events to determine if the target event occurred to allow the script to continue execution, wherein the target event was stored in the event buffer before initiating the wait for routine.
2. The method of
3. The method of
determining, by the script, when to clear events in the event buffer based on the executing of the code; and
clearing the set of events from the event buffer based on determining when to clear the events.
4. The method of
causing, by the script, a marker to be set at a position in the event buffer, the marker indicating events generated by the control device should be stored in the event buffer in relation to the position, wherein the set of events are stored in the event buffer based on the position.
5. The method of
6. The method of
7. The method of
8. The method of
causing the control device to be provisioned to communicate with the testing device; and
causing the media player or the control device to be provisioned based on testing characteristics for the script.
9. The method of
a set of commands from the script are sent to the control device in a session using a messaging protocol, and
the set of events are sent in the session using the messaging protocol to the testing device.
10. The method of
the control device is situated behind a firewall on a local area network for a location, and
the testing device is outside of the firewall and communicates with the control device through a wide area network.
12. The non-transitory computer-readable storage medium of
13. The non-transitory computer-readable storage medium of
the marker is explicitly set by the script and explicitly cleared, and
issuing the command comprises sending multiple commands where the event buffer is not cleared until explicitly cleared due to the marker being explicitly set.
14. The non-transitory computer-readable storage medium of
causing, by the script, a marker to be set at a position in the event buffer, the marker indicating events generated by the control device should be stored in the event buffer in relation to the position, wherein the set of events are stored in the event buffer based on the position.
15. The non-transitory computer-readable storage medium of
16. The non-transitory computer-readable storage medium of
17. The non-transitory computer-readable storage medium of
causing the control device to be provisioned to communicate with the testing device; and
causing the media player or the control device to be provisioned based on testing characteristics for the script.
18. The non-transitory computer-readable storage medium of
a set of commands from the script are sent to the control device in a session using a messaging protocol, and
the set of events are sent in the session using the messaging protocol to the testing device.
19. The non-transitory computer-readable storage medium of
the control device is situated behind a firewall on a local area network for a location, and
the testing device is outside of the firewall and communicates with the control device through a wide area network.
|
The present disclosure is a continuation of U.S. application Ser. No. 13/868,416, entitled “AUTOMATION FRAMEWORK TO REMOTELY CONTROL DEVICES AND PROCESS ASYNCHRONOUS EVENTS”, filed Apr. 23, 2013, which claims priority to U.S. Provisional Application No. 61/637,172, entitled “AUTOMATION FRAMEWORK TO REMOTELY CONTROL DEVICES”, filed Apr. 23, 2012, the contents of both are incorporated herein by reference in their entirety.
The number of devices that are available to play streaming media is increasing. These devices include different configurations and capabilities. A media player is typically used to play media that is streamed to the device. However, because of the different configurations and capabilities, the media player may work differently on each device. Thus, a company providing a streaming service must test and maintain the media player on each different device making it increasingly costly to test and maintain the media player on all supported devices.
In one embodiment, a script executes code on a testing device to automatically control a control device that is remotely located from the testing device. During the control, a media player on the control device interacts with a video streaming service remotely located from the control device. The script determines when to start storing events in the event buffer based on the executing of the code. The testing device receives a set of events from the control device based on the control device being controlled by the script to perform a set of actions related to interacting with the video streaming service. The set of actions performed by the control device results in the set of events being asynchronously sent to the testing device. The set of events is then stored in the event buffer. The script initiates a wait for routine that waits for a target event to occur before execution of the script can continue and receives the set of events from the event buffer where the set of events are stored in the event buffer based on the determining of when to start storing events in the event buffer. The script then analyzes the set of events to determine if the target event occurred to allow the script to continue execution. The target event was stored in the event buffer before initiating the wait for routine.
In one embodiment, a non-transitory computer-readable storage medium contains instructions, that when executed, control a computer system to be configured for: executing, by a script on a testing device, code to automatically control a control device that is remotely located from the testing device, wherein, during the control, a media player on the control device interacts with a video streaming service remotely located from the control device; determining, by the script, when to start storing events in the event buffer based on the executing of the code; receiving, by the testing device, a set of events from the control device based on the control device being controlled by the script to perform a set of actions related to interacting with the video streaming service, wherein the set of actions performed by the control device results in the set of events being asynchronously sent to the testing device; storing, by the testing device, the set of events in the event buffer; initiating, by the script, a wait for routine that waits for a target event to occur before execution of the script can continue; receiving, by the script, the set of events from the event buffer, the set of events being stored in the event buffer based on the determining of when to start storing events in the event buffer; and analyzing, by the script, the set of events to determine if the target event occurred to allow the script to continue execution, wherein the target event was stored in the event buffer before initiating the wait for routine.
In one embodiment, a system includes: a control device comprising a media player; and a testing device configured for: executing, by a script on the testing device, code to automatically control the control device that is remotely located from the testing device, wherein, during the control, a media player on the control device interacts with a video streaming service remotely located from the control device; determining, by the script, when to start storing events in the event buffer based on the executing of the code; receiving, by the testing device, a set of events from the control device based on the control device being controlled by the script to perform a set of actions related to interacting with the video streaming service, wherein the set of actions performed by the control device results in the set of events being asynchronously sent to the testing device; storing, by the testing device, the set of events in the event buffer; initiating, by the script, a wait for routine that waits for a target event to occur before execution of the script can continue; receiving, by the script, the set of events from the event buffer, the set of events being stored in the event buffer based on the determining of when to start storing events in the event buffer; and analyzing, by the script, the set of events to determine if the target event occurred to allow the script to continue execution, wherein the target event was stored in the event buffer before initiating the wait for routine.
The following detailed description and accompanying drawings provide a better understanding of the nature and advantages of particular embodiments.
Described herein are techniques for an automation framework. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of particular embodiments. Particular embodiments as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.
Overview
Before beginning the automatic control, device 102 needs to be provisioned. In a step 1, script 106 reserves a device from a device pool 112 for use. Devices 102 include devices that may be used to play a media program, such as a video. For example, devices 102 include a smartphone, tablet computer, television, laptop, and other “living room” devices. For example, script 106 contacts a device broker service 114 to request a device to control. The request may include reservation criteria that define characteristics of a desired device. For example, the criteria may be a smartphone model #. Device broker service 114 then assigns a device for a current session. At the end of the session, the script 106 may release the device, so that it can be used by other scripts later. This described scenario is when a company has a device pool of available devices that can be remotely tested by scripts. Scripts 102 reserve devices to test and only one script 102 may test a device. There may be two considerations in this step: a. If all devices that match the reservation criteria are currently locked by other scripts, device broker service 114 may block the request until a device is available. This may cause script 106 to block or time out. If script 106 has timed out by the time script 106 obtains the requested device, device broker service 114 needs to ensure that the device is returned to the pool; and b. In case there are misbehaving scripts that unnecessarily hold on to hardware device after its use, the reservation will expire after a certain amount of inactivity. In other embodiments, scripts 106 may be testing devices in a user's “living room”. For example, a user may be purchased a device and the automation framework is used to troubleshoot any problems.
In a step 2, a provisioning server 116 provisions device 102 according to a requested configuration by script 106. For example, script 106 might be a test script that needs to download a specific piece of code, such as a git branch, for testing on the given hardware device. Additionally, during the provisioning step, automation provisioning manager 110 may also customize device 102 as follows:
a. Media Player software version
b. Device firmware version
c. Beacon service location
d. Log collector service location
e. Other service location for service provider
Provisioning server 116 may configure the software version of a media player being used on device 102 and the firmware or operating system of device 102. Automation provisioning manager 110 may also configure how events are sent by device 102 to scripts 102 by setting the beacon service location, the log collector service location, and other service location for a service provider. The events will be described in more detail below.
At a step 3, when device 106 is provisioned, device 102 connects to a test server 110, such as an Extensible Messaging and Presence Protocol (XMPP) server, using an automation addressing scheme. This is a messaging protocol that sends messages between device 106 and automation manager 104. In this case, device 102 connects to test server 110 using an address received from provisioning server 116. Although automatic provisioning is discussed, a user can manually provision a device 102. For example, a user can start controlling a device 102 without having to add it to device pool 112, which is managed by device broker service 114 and provisioning server 116. Also, script 106 connects to test server 110 using an address received from device broker service 114. Once connecting to test server 110, particular embodiments may begin the automatic testing.
Script 106 sends commands to device 102 via test server 110. Device 102 may acknowledge each command with a response. The commands may cause device 102 to perform some action. For example, the command may be commands to start playing a video using the media player, stop playing a video, perform certain trick play commands for a video, etc. In general, the commands may be causing actions to be performed with respect to the media player.
When performing actions in response to the commands, device 102 may generate certain events. For example, events may be generated when a video finishes playing. One event may be an event that script 106 needs to receive to continue the automation testing. For example, script 106 may be executing and waiting for certain events to occur on device 102. Because of the nature of the testing, script 106 does not know when the event will occur. For example, script 102 does not know when the media player will finish playing the video. This may be because a streaming service separate from device 102 is streaming the video to the media player. Various unknown and variable conditions may result, such as bandwidth variations, that make it uncertain when the media player will finish playing the video. When script 106 receives notification that the event occurs, script 102 may then stop waiting and continue to execute, such as by sending more commands.
Other types of events may be logs events or beacons. As part of session establishment, particular embodiments can reconfigure the media player in device 102 to start sending log events and beacons to collector 120. After an automation session, particular embodiments then query the log collection service to retrieve all the log entries belonging to the automation session. These log entries can be used for debugging or test assertion purposes. These events may not be needed by script 106 to continue executing. Device 102 sends these events to a collector 120, which may be located in a separate entity from test server 118 or be located in test server 118. Beacons may be web requests that are generated to document the actions taken at device 102. For example, when a browser requests information from a website, the beacon may aggregate information, such as the IP address of the computer being used; the time the material was viewed; the type of browser that was used, the type of action taken by the user, etc. A log event may be any other events that occur, such as a video stops playing. In one embodiment, events may be sent using different protocols. For example, beacons and log events may be sent using HyperText Transfer Protocol (HTTP) to an HTTP client 124 in interface 108 of automation manager 104.
Script 106 and device 102 communicate using a bi-directional, asynchronous messaging bus over HTTP. In one embodiment, device 102 sends the events through test server 118 through a transport interface 122 in interface 108 of automation manager 104. In one embodiment, a messaging protocol is used, such as XMPP. In one embodiment, devices 102, such as devices referred to as “living room” devices (e.g., those devices located on a home or local area network) may not be allowed to open up network ports for security reasons. Also, particular embodiments aim to enable automation protocol across network address translation (NAT) and firewalls that exist in networks, such as home networks. Once a protocol session is established, script 106 can sends control commands to the connected device 102, and device 102 should be able to initiate event notification to script 106. The communication between device 102 and script 106 may be an asynchronous transmission of messages (meaning, either end point should be able to send a message off without having to wait for response). The asynchronous transmission is used because script 106 is executing remotely from device 102 and does not know when events will occur at device 102. As will be discussed below, event handling is needed to ensure proper execution of script 106.
At a step 4, once automation run is finished, script 106 can retrieve any beacons and log entries belonging to the current session from collector 120. This information can be used to make test assertions or to aid debugging.
Handling Device Events
As discussed above, communication between script 106 and device 102 may be asynchronous. Script 106 issues commands to control devices 102 and events occur due to the controlling. At some points in the script 106, lines of code may be waiting for events to occur to continue executing. However, events might happen before the script starts looking for the event (that is, the script has not reached the line of code that is looking for the event). When this occurs, script 106 may run in an infinite loop waiting for the event to occur because the event has already occurred and will never be encountered. Particular embodiments provide event handling for events that might happen before software code is executed that waits for an event to occur. The event handling is performed to ensure that script 102 receives the events it is waiting for at the appropriate time.
Once script 106 and device 102 establish a connection, device 102 sends events back to script 106 during the automated testing. For example, script 106 may automatically control a media player to play a video from a streaming service. While being automatically controlled, certain events may occur, such as:
Each of these events is defined using the similar mechanism as commands. For example,
Script 102 may register a callback to receive the events. The following is an example callback registration:
device.on_event(:all_events, Bender::Message::EventBase) do |event|
puts “event received: #{event}”
end
The above code registers an event handler :all_events that match all events, and prints them out. (in one embodiment, all events inherit from EventBase). Particular embodiments can register multiple callbacks for the same event. So, in addition to the above event, particular embodiments could register another callback for a specific event as follows:
$ad_count = 0
device.on_event(:ad_count, Bender::Message::Event::PlaybackAdStart)
do |event|
$ad_count += 1
end
The above code will count how many times the PlaybackAdStart event has fired. Note that the |event| object that gets passed in is an instance of the event class that particular embodiments are capturing. So, particular embodiments can access details as follows:
device.on_event(:progress, Bender::Message::Event::PlaybackProgress)
do |event|
puts event.data content_id
puts “At %f second mark” % (event.data.current_position.to_f /
1000.0)
end
The event handler names (such as :all_events, :ad_count, and :progress) are there so that particular embodiments can later remove an event handler if needed, using remove_on_event API. Here is an example:
device.remove_on_event(:progress)
After registering to receive events, script 106 includes code that may be waiting for an event to occur for script 106 to continue execution. That is, script 106 controls the execution flow of the code based on events received. Interface 108 provides a wait_for application programmer interface (API) that allows script 106 to block (e.g., wait) until certain event is fired from device 102. This causes script 106 to wait until the event occurs.
At 300, script 106 sends a command for staring playback of a media program in a media player. After sending the command, script 106 looks for an event to occur on device 102. For example, at 302, a line 3 of script 106 is waiting for the very first PlaybackFinished (playback_finished) event before continuing to line 4. Script 106 blocks inside the wait_for API here. Due to the asynchronous nature of the communication between script 106 and device 102, there may be no guarantee that events caused by an issued command will arrive after the wait_for routine gets a chance to run. For example, PlaybackFinished event might arrive between line 2 and line 3 in the code (as shown at 304 before wait_for API call), and when script 106 executes the wait_for routine on line 3, script 106 might get stuck forever waiting for an event that already has occurred between lines 2 and 3. However, particular embodiments provide an event buffer facility to address this situation.
In addition to event buffer 402, markers may be used to determine when to capture events. In some embodiments, buffer manager 404 flushes event buffer 402 automatically at appropriate points over the course of script execution. In one example, unless particular embodiments use event markers, buffer manager 404 flushes event buffer 402 every time script 106 issues a new command. To avoid the flushing at every command, particular embodiments use event markers.
In one example, the wait_for API is waiting for an event that indicates the playback of a video has finished in a media player. However, due to the asynchronous nature of the automation testing, the media player may finish playing the video before script 106 invokes the wait_for API. Thus, by storing the events in event buffer 402, the wait_for API correctly receives the event when invoked.
In some cases, script 106 needs to capture events across multiple commands. In this case, buffer manager 404 sets event markers through a set_marker API. With this API, particular embodiments can explicitly control event buffer 402. In contrast to the example in
At 554, script 106 calls the wait_for routine that is waiting for a playback_finished event, which is when the media player finishes playing the video. At this point, buffer manager 404 delivers the events in event buffer 402 to the wait_for API. As shown, events E1-E5 are delivered. The wait_for routine thus receives all events that may have occurred after script 106 set marker A. This ensures that the wait_for routine receives the event it is looking for even if it occurred before script 106 executed line 6. Because the marker is a manual marker, script 106 may want to clear the marker when events no longer need to be saved in event buffer 402. At 556, script 106 clears marker A and any events in event buffer 402.
Sometimes, script 106 may want to call wait_for routines multiple times after issuing a command. It may be desirable that only events received after the first wait_for routine is executed be delivered to the second wait_for routine. In this case, the events received before the first wait_for routine is executed may not be relevant. Script 106 allows multiple wait_for routines by keeping track of the last processed event within the current marker.
At 652, script 106 calls a first wait_for routine (device.wait_for(:playback_started)) that is waiting for a playback_started event, which is when the media player starts playing the video. At this point, buffer manager 404 delivers the events in event buffer 402 to the wait_for routine. As shown, events 1-3 are delivered. The wait_for routine thus receives all events that may have occurred before script 106 issued the command and after marker A was set. This ensures that the wait_for routine receives the event it is looking for even if it occurred before script 106 executed line 2.
At 654, buffer manager 404 sets an iteration marker B. The iteration marker indicates in buffer 402 where the last event was sent to the last wait_for routine. The iteration marker may be automatically set when multiple wait_for routines are issued without an intervening command. Buffer manager 404 then receives events 4 and 5 asynchronously from device 102 and stores the events in event buffer 402. At 656, script 106 calls a second wait_for routine (device.wait_for(:playback_progress_occurred)) that is waiting for a progress report of the playback of the video, which is in the middle of when the media player is playing the video. At 658, buffer manager 404 delivers the events in event buffer 402 to the wait_for routine. As shown, events 4-5 are delivered, but not events 1-3. In this case, buffer manager 404 determines where the iteration marker B was set and delivers events from that point on in the event buffer 402. The wait_for routine thus receives all events that may have occurred before script 106 issued the command and after marker B was set. This ensures that the wait_for routine receives the event it is looking for even if it occurred before script 106 executed line 3.
Finally, sometimes it is necessary to set and clear a marker for a limited scope. For example, particular embodiments may want to send a command within a subroutine, but does not want to affect the calling code.
When the subroutine ends, script 106 returns to the calling code and executes a wait_for routine at 716. This command is waiting for a playback started command indicating that the media player started playback of the video. This event was received at 718 before the subroutine was called. However, the execution of commands in the subroutine caused another marker to be set, which cleared the playback started command from buffer 402 as shown at 718. Thus, the wait_for routine does not receive the playback started event.
In order to avoid the situation where commands run within a subroutine clear markers set for a calling routine, event manager 404 provides a mechanism to save and restore the caller's marker. This allows the calling routine to avoid losing track of events, even when the calling routine calls subroutines that may set and clear markers themselves.
After setting marker m, buffer 402 receives events 3 and 4. When a wait_for event is encountered within the subroutine, buffer 402 delivers the events after marker m to script 106. Thus, buffer 402 delivers events 3 and 4, but not events 1 and 2. Also, buffer manager 404 has not cleared events 1 and 2 from buffer 402 even though wait for routines have been issued in the subroutine and events from event buffer 402 have been delivered.
When the subroutine returns, at 768, buffer 402 may deliver all events within buffer 402 to script 106 (or just the events before new marker m). In this case, the wait_for routine playback_started receives the playback started event properly.
The automation framework allows users to control TV devices remotely and programmatically, significantly improving development and testing efficiency. Such efficiency gain can also be extended to other companies or users in the form of software development kit that contains components of the automation framework to facilitate a TV certification process, which is one of the use cases of automation framework. Also, particular embodiments can be leveraged for use in end-user scenarios in production. Example scenarios include the “companion device experience” in which particular embodiments enable the end users to interact with a media player on their TV from their tablet or phone devices. Another scenario might be to enable a customer support agent to diagnose problems by directly connecting to TV devices in the customer's living room.
Bus 802 may be a communication mechanism for communicating information. Computer processor 804 may execute computer programs stored in memory 808 or storage device 808. Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented. The routines can execute on a single computer system 800 or multiple computer systems 800. Further, multiple processors 806 may be used.
Memory 808 may store instructions, such as source code or binary code, for performing the techniques described above. Memory 808 may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 806. Examples of memory 808 include random access memory (RAM), read only memory (ROM), or both.
Storage device 810 may also store instructions, such as source code or binary code, for performing the techniques described above. Storage device 810 may additionally store data used and manipulated by computer processor 806. For example, storage device 810 may be a database that is accessed by computer system 800. Other examples of storage device 810 include random access memory (RAM), read only memory (ROM), a hard drive, a magnetic disk, an optical disk, a CD-ROM, a DVD, a flash memory, a USB memory card, or any other medium from which a computer can read.
Memory 808 or storage device 810 may be an example of a non-transitory computer-readable storage medium for use by or in connection with computer system 800. The computer-readable storage medium contains instructions for controlling a computer system to be operable to perform functions described by particular embodiments. The instructions, when executed by one or more computer processors, may be operable to perform that which is described in particular embodiments.
Computer system 800 includes a display 812 for displaying information to a computer user. Display 812 may display a user interface used by a user to interact with computer system 800.
Computer system 800 also includes a network interface 804 to provide data communication connection over a network, such as a local area network (LAN) or wide area network (WAN). Wireless networks may also be used. In any such implementation, network interface 804 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.
Computer system 800 can send and receive information through network interface 804 across a network 814, which may be an Intranet or the Internet. Computer system 800 may interact with other computer systems 800 through network 814. In some examples, client-server communications occur through network 814. Also, implementations of particular embodiments may be distributed across computer systems 800 through network 814.
Particular embodiments may be implemented in a non-transitory computer-readable storage medium for use by or in connection with the instruction execution system, apparatus, system, or machine. The computer-readable storage medium contains instructions for controlling a computer system to perform a method described by particular embodiments. The computer system may include one or more computing devices. The instructions, when executed by one or more computer processors, may be operable to perform that which is described in particular embodiments.
As used in the description herein and throughout the claims that follow, “a”, “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
The above description illustrates various embodiments along with examples of how aspects of particular embodiments may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of particular embodiments as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents may be employed without departing from the scope hereof as defined by the claims.
Carter, Andrew Sherman, Jang, Myul Ryul, Mahrt, Dallas Stephan
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
6473778, | Dec 24 1998 | AT&T Corp | Generating hypermedia documents from transcriptions of television programs using parallel text alignment |
6697569, | Sep 11 1998 | Telefonaktiebolaget LM Ericsson (publ) | Automated conversion of a visual presentation into digital data format |
7330875, | Jun 15 1999 | Microsoft Technology Licensing, LLC | System and method for recording a presentation for on-demand viewing over a computer network |
8356251, | Apr 21 2011 | TOUCHSTREAM TECHNOLOGIES, INC | Play control of content on a display device |
8935424, | Jan 07 2011 | RPX Corporation | Method and apparatus for signaling presentation description updates in HTTP streaming |
20020083182, | |||
20020147634, | |||
20030009452, | |||
20030061305, | |||
20050091672, | |||
20050262187, | |||
20140181877, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
May 06 2015 | HULU, LLC | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Dec 06 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Nov 21 2023 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Date | Maintenance Schedule |
Jun 07 2019 | 4 years fee payment window open |
Dec 07 2019 | 6 months grace period start (w surcharge) |
Jun 07 2020 | patent expiry (for year 4) |
Jun 07 2022 | 2 years to revive unintentionally abandoned end. (for year 4) |
Jun 07 2023 | 8 years fee payment window open |
Dec 07 2023 | 6 months grace period start (w surcharge) |
Jun 07 2024 | patent expiry (for year 8) |
Jun 07 2026 | 2 years to revive unintentionally abandoned end. (for year 8) |
Jun 07 2027 | 12 years fee payment window open |
Dec 07 2027 | 6 months grace period start (w surcharge) |
Jun 07 2028 | patent expiry (for year 12) |
Jun 07 2030 | 2 years to revive unintentionally abandoned end. (for year 12) |