Reducing unicast session duration with restart TV
Claim Score by NHIP
Abstract
A first portion of programming aired prior to a first time is obtained via a unicast session with a server, the first portion including previously aired programming. When the programming data being sent via the unicast session catches up to a multicast broadcast of the programming, the unicast session is terminated and a switch is made to obtaining a remaining portion of the programming from a different source other than the server. This different source can be, for example, a local storage device or a multicast broadcast of the programming.
Term
2.2 yearsleft in the term
Expires 25 November 2028.
- Priority
- Filed
- Granted
- Today
- Expires
40 claims: 5 independent, 35 dependent
- 1A method implemented in a consumer device, the method comprising:receiving a request at a first time for programming that has already begun to air transmit , wherein the programming is scheduled for transmission to a plurality of users user devices during a scheduled time interval, and wherein the first time corresponds to a point after a beginning time of the scheduled time interval;determining the beginning time of the scheduled time interval;obtaining by the consumer device, based on determining the beginning time, via a unicast session with a server, a first portion of the programming aired transmitted prior to the first time, the first portion including previously aired transmitted programming, wherein the previously aired transmitted programming corresponds to programming transmitted to a the plurality of users user devices starting from the beginning time of the scheduled time interval, and wherein the first portion is obtained as a first plurality of packets, each packet of the first plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the first plurality of packets;obtaining by the consumer device, via a multicast broadcast of the programming concurrently with obtaining the first portion by the consumer device via the unicast session, at least part of a remaining portion of the programming that airs transmitted after the first time, wherein initiating said obtaining the first portion of the programming and said obtaining the remaining portion of the programming begin together at the consumer device, and wherein the multicast broadcast is obtained as a second plurality of packets, each packet of the second plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the second plurality of packets;comparing a first presentation timestamp of a first packet of the first plurality of packets with a second presentation timestamp of a second packet of the second plurality of packets;determining , based on the comparing, whether the a first presentation timestamp of the a first packet of the first plurality of packets matches the a second presentation timestamp of the a second packet of the second plurality of packets;in response to determining that the first presentation timestamp of the first packet of the first plurality of packets matches the second presentation timestamp of the second packet of the second plurality of packets, determining that the unicast session has caught up to the multicast broadcast;and stopping, the unicast session when the unicast session has caught up to the multicast broadcast, to obtain the programming data from the unicast session, and continuing to obtain via the multicast broadcast the remaining portion of the programming from a different source other than the server.
- 10A method implemented in a computing device, the method comprising:sending, to a consumer device via a unicast session with the consumer device, a first portion of programming aired transmitted prior to a first time that corresponds to a request to at least one of view or record the programming, the first portion including previously aired transmitted programming and being identifiable using metadata associated with the programming that indicates the previously aired transmitted programming spans from a beginning of the programming up to the first time that corresponds to the request to at least one of view or record the programming, wherein the programming is scheduled for transmission to a plurality of users user devices during a scheduled time interval, and wherein the first time corresponds to a point after a beginning time of the scheduled time interval, wherein the consumer device is initiated to obtain the first portion of the programming via the unicast session concurrently with obtaining a multicast broadcast of the programming via the multicast broadcast of the programming, wherein initiating said obtaining the first portion of the programming and said obtaining the multicast broadcast of the programming begin together at the consumer device, wherein the first portion is obtained as a first plurality of packets, each packet of the first plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the first plurality of packets, and the multicast broadcast is obtained as a second plurality of packets, each packet of the second plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the second plurality of packets, wherein the first portion corresponds to programming transmitted to a the plurality of users user devices starting from the beginning time of the scheduled time interval, and wherein the multicast broadcast of the programming is configured for storage to enable playback by the consumer device after the first portion of the programming is played back by the consumer device;comparing a first presentation timestamp of a first packet of the first plurality of packets with a second presentation timestamp of a second packet of the second plurality of packets;determining , based on the comparing, whether the a first presentation timestamp of the a first packet of the first plurality of packets matches the a second presentation timestamp of the a second packet of the second plurality of packets;in response to determining that the first presentation timestamp of the first packet of the first plurality of packets matches the second presentation timestamp of the second packet of the second plurality of packets, determining that the unicast session has caught up to the stored multicast broadcast of the programming;and stopping the unicast session when the unicast session has caught up to the stored multicast broadcast of the programming.
- 15A system for communication with a consumer device having a local storage device, the system comprising:a server configured to establish a unicast session and/or a multicast broadcast with the consumer device, the server comprising: memory circuitry configured to store content of the unicast session and/or the multicast broadcast for distribution to the consumer device;and control processing circuitry configured to: receive a request from the consumer device at a first time for programming that has already begun to air transmit , wherein the programming is scheduled for transmission to a plurality of users user devices during a scheduled time interval, and wherein the first time corresponds to a point after a beginning time of the scheduled time interval;establish a the unicast session with a at the server based on the received request;determine the beginning time of the scheduled time interval;obtain, based on determining the beginning time, via the unicast session and in response to the request, a first portion of the programming that aired transmitted prior to a first time, the first portion including previously aired transmitted programming and being identifiable using metadata associated with the programming that indicates the previously aired transmitted programming spans from a beginning of the programming up to the first time, wherein the first portion is obtained at a rate faster than a playback rate of the programming, and wherein the first portion is obtained for playback by the consumer device, wherein the first portion corresponds to programming transmitted to a the plurality of users user devices starting from the beginning time of the scheduled time interval, and wherein the first portion is obtained as a first plurality of packets, each packet of the plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the first plurality of packets;obtain the first portion of the programming via the unicast session, together with obtaining and recording, via a the multicast broadcast of the programming, at least a first part of the multicast broadcast of the programming, at the consumer device, wherein the multicast broadcast is obtained as a second plurality of packets, each packet of the second plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the second plurality of packets;compare a first presentation timestamp of a first packet of the first plurality of packets with a second presentation timestamp of a second packet of the second plurality of packets;determine , based on the comparing, whether the a first presentation timestamp of the a first packet of the first plurality of packets matches the a second presentation timestamp of the a second packet of the second plurality of packets;in response to determining that the first presentation timestamp of the first packet of the first plurality of packets matches the second presentation timestamp of the second packet of the second plurality of packets, determining that data obtained via the unicast session has caught up to the recorded multicast broadcast;and stop, based on determining that data obtained via the unicast session has caught up to the recorded multicast broadcast, obtaining via the unicast session, the first portion of the programming, and obtaining a remaining portion of the programming from a the local storage device of the consumer device on which the at least the first part of the multicast broadcast was recorded, wherein the remaining portion is obtained for playback by the consumer device.
- 21Broadest claimClaim Score 27, narrow(NHIP)A method for playing, on a media device, a portion of programming that was broadcast prior to a time at which the media device began playing the programming the method comprising:beginning to obtain, at a first time, via a first stream, programming that is scheduled for broadcast during a scheduled time interval, wherein the first time corresponds to a point after a beginning time of the scheduled time interval;receiving, at a second time later than the first time, a request for a portion of the programming that was broadcast prior to the first time;in response to receiving the request: obtaining, via a second stream, a first plurality of packets containing media data of a first portion of the programming that was broadcast prior to the first time, each packet of the first plurality of packets having a presentation timestamp that indicates a respective play time of media data;continuing to obtain, via the first stream, the programming, wherein the first stream is obtained as a second plurality of packets, each packet of the second plurality of packets having respective a presentation timestamp that indicates a play time of media data;in response to determining that a presentation timestamp of the most recently obtained packet of the second plurality of packets matches a presentation timestamp of a most recently obtained packet of the first plurality of packets, determining, when playing the programming, that the second stream has caught up to the first stream;and in response to determining that the second stream has caught up to the first stream, ending obtaining the second stream, and continuing to obtain via the first stream a remaining portion of the programming;wherein the first stream is a multicast broadcast and the second stream is a unicast session.
- 31A system for playing a portion of programming that was broadcast prior to a time at which the media device began playing the programming, the system comprising:a server configured to establish a second stream and/or a first stream with the media device, the server comprising: memory circuitry configured to store content of the second stream and/or the first stream for distribution to the media device;and processing circuitry configured to: begin to obtain, at a first time, via the first stream, programming that is scheduled for broadcast during a scheduled time interval, wherein the first time corresponds to a point after a beginning time of the scheduled time interval;receive, at a second time later than the first time, a request from the media device for a portion of the programming that was broadcast prior to the first time;in response to receiving the request: obtain, via the second stream, a first plurality of packets containing media data of a first portion of the programming that was broadcast prior to the first time, each packet of the first plurality of packets having a presentation timestamp that indicates a respective play time of media data;continue to obtain, via the first stream, the programming, wherein the first stream is obtained as a second plurality of packets, each packet of the second plurality of packets having respective a presentation timestamp that indicates a play time of media data;in response to determining that a presentation timestamp of the most recently obtained packet of the second plurality of packets matches a presentation timestamp of a most recently obtained packet of the first plurality of packets, determine, when playing the programming, that the second stream has caught up to the first stream;and in response to determining that the second stream has caught up to the first stream, end obtaining the second stream, and continue to obtain via the first stream a remaining portion of the programming;wherein the first stream is a multicast broadcast and the second stream is a unicast session.
Independent claims5
92 paragraphs in 5 sections, as filed
id="REI-00001" date="20250325"
RELATED U.S. APPLICATION DATA
id="REI-00001"
This application is a reissue application of U.S. Pat. No. 10,063,934, which issued based upon U.S. patent application Ser. No. 12/277,797, which is hereby incorporated by reference herein in its entirety.
BACKGROUND
Television viewing and recording technology has been continually advancing, with hundreds of channels, digital video recorders (DVRs), and video-on-demand programs finding their way into many homes. Despite such advances, problems still remain. One such problem is that although some systems may allow different users to begin watching the same program at different times, this can result in situations where many dedicated sessions are established between a program server and each of multiple individual users' systems for the same program. This can thus result in increased resource requirements and costs for servers and other components, and thus the overall cost of the television viewing system.
SUMMARY
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
In accordance with one or more aspects, a first portion of programming aired prior to a first time is obtained via a unicast session with a server. The first portion includes previously aired programming. A switch is made, after programming data received via the unicast session catches up to a multicast broadcast of the programming, to obtaining a remaining portion of the programming from a different source other than the server.
In accordance with one or more aspects, a first portion of programming aired prior to a first time is sent to a consumer device via a unicast session with the consumer device. The first portion of programming includes previously aired programming. The unicast session is terminated after programming data sent to the consumer device via the unicast session catches up to a multicast broadcast of the programming.
BRIEF DESCRIPTION OF THE DRAWINGS
The same numbers are used throughout the drawings to reference like features.
<figref idref="DRAWINGS">FIG. <b>1</b></figref> illustrates an example system implementing the reducing unicast session duration with restart TV in accordance with one or more embodiments.
<figref idref="DRAWINGS">FIGS. <b>2</b>, <b>3</b>, and <b>4</b></figref> illustrate different examples of the reducing unicast session duration with restart TV in accordance with one or more embodiments.
<figref idref="DRAWINGS">FIG. <b>5</b></figref> is a flowchart illustrating an example process for reducing unicast session duration with restart TV in accordance with one or more embodiments.
<figref idref="DRAWINGS">FIG. <b>6</b></figref> is a flowchart illustrating another example process for reducing unicast session duration with restart TV in accordance with one or more embodiments.
<figref idref="DRAWINGS">FIG. <b>7</b></figref> illustrates various components of an example client device that can implement one or more embodiments of the reducing unicast session duration with restart TV.
<figref idref="DRAWINGS">FIG. <b>8</b></figref> illustrates an example entertainment and information system in which one or more embodiments of the reducing unicast session duration with restart TV can be implemented.
DETAILED DESCRIPTION
Reducing unicast session duration with restart TV is discussed herein. In accordance with one or more embodiments, when a user requests to have audio/video programming played back that is already being aired, the programming is transmitted to the user's device via a combination of a unicast session and a multicast broadcast. A first portion of the programming, including a portion that was broadcast prior to the user's request, is obtained by the user's device via a unicast session with a server maintaining a copy of the programming. Concurrently, the remaining portion of the programming can optionally be recorded by the user's device via the multicast broadcast. Once the data sent to the user's device via the unicast session catches up to the data in the program being currently multicast broadcast, the unicast session is terminated. The remainder of the programming can then be played back at the user's device from another source, such as from the recording on the user's device, or from the multicast broadcast.
<figref idref="DRAWINGS">FIG. <b>1</b></figref> illustrates an example system <b>100</b> implementing the reducing unicast session duration with restart TV in accordance with one or more embodiments. System <b>100</b> includes a server <b>102</b> that can communicate with one or more (M) consumer devices <b>104</b>(<b>1</b>-M) via a network <b>106</b>. Network <b>106</b> can be a variety of different networks, including the Internet, a local area network (LAN), a cellular or other wireless phone network, a public telephone network, an intranet, other public and/or proprietary networks, combinations thereof, and so forth. In one or more embodiments network <b>106</b> is implemented to include an Internet Protocol (IP)-based network that facilitates programming content distribution and data communication between the server <b>102</b> and any number of consumer devices <b>104</b>. An IP-based network is a network that supports communication among devices using IP, such as IP version 4 (IPv4, such as discussed in IETF RFC 791), as well as other versions such as IP version 6 (IPv6).
Server <b>102</b> includes a unicast module <b>112</b> and a network buffer <b>114</b>. Although server <b>102</b> is illustrated as including both module <b>112</b> and buffer <b>114</b>, alternatively module <b>112</b> and buffer <b>114</b> can be implemented in different servers. Server <b>102</b> can be implemented as one or more computing devices. Additionally, although a single server <b>102</b> is illustrated in <figref idref="DRAWINGS">FIG. <b>1</b></figref>, alternatively multiple servers can communicate with consumer devices <b>104</b> via network <b>106</b>.
Generally, server <b>102</b> receives programming <b>120</b> in the form of a multicast broadcast from one or more sources as the programming is aired by the source(s). Server <b>102</b> stores the aired programming as programming data in network buffer <b>114</b>. This programming data stored in buffer <b>114</b> is then made accessible to consumer devices <b>104</b> after (and during) airing of the programming so that the programming can be obtained and played back (and/or stored) by consumer devices <b>104</b>. This allows a user of a device <b>104</b> to request playback of a particular program after the program has begun airing, and have the portion of the program that has already aired transferred to the device <b>104</b> from network buffer <b>114</b>. This functionality allowing playback of a program that has already begun airing is also referred to as restart TV, as it allows a user to restart playback of particular programming from the beginning of the programming (e.g., restart playback of a particular television program from the beginning of the television program).
Programming <b>120</b> can also be distributed directly to consumer devices <b>104</b> via network <b>106</b>. Programming <b>120</b> is typically a multicast broadcast of programming data. A multicast broadcast refers to the transmission of programming in a one-to-many configuration, where one source can broadcast the same data to multiple recipients concurrently. Different channels carrying different programming are typically multicast broadcast by one or more sources, and individual consumer devices <b>104</b> can tune to particular channels in order to obtain the programming being broadcast on the tuned-to channel.
Programming <b>120</b> includes audio and/or video programs from one or more sources, such as a satellite operator, a network television operator, a cable operator, and so forth. Programming <b>120</b> can be received from the sources via a variety of different transmission media, such as satellite transmission, radio frequency transmission, cable transmission, and so forth. Optionally, a content distributor (not shown in <figref idref="DRAWINGS">FIG. <b>1</b></figref>) receives programming <b>120</b> from the various sources and converts programming <b>120</b> into an appropriate format for a multicast broadcast via network <b>106</b>. Alternatively, one or more sources can directly broadcast programming <b>120</b> via network <b>106</b> without using such a content distributor. The airing or broadcasting of programming refers to the transmitting of the programming by a source via any transmission media.
Programming <b>120</b> can include a variety of different television programs having a variety of different lengths, such as television sitcoms, news broadcasts, documentaries, cartoon shows, movies, and so forth. These programs can optionally include advertisements as well. Any program that can be aired by a source can be included as a program of programming <b>120</b>.
Programming <b>120</b> is stored in network buffer <b>114</b>. In one or more embodiments, all programs received as programming <b>120</b> by server <b>102</b> are stored in network buffer <b>114</b> at least temporarily. Alternatively, server <b>102</b> can optionally impose one or more filters to restrict which programs are stored in network buffer <b>114</b>. Network buffer <b>114</b> stores programs at least temporarily, and the duration of this temporary storage can vary. For example, the duration can be 4 hours, 48 hours, 72 hours, 1 week, and so forth. It is to be appreciated that the exact duration of this temporary storage can vary by implementation and based on the desires of an operator of server <b>102</b>.
Unicast module <b>112</b> manages unicast sessions between consumer devices <b>104</b> via which programming stored in network buffer <b>114</b> can be sent. A unicast session refers to a one-to-one configuration in which a dedicated communication session between server <b>102</b> and one consumer device <b>104</b> is established. Programming data from network buffer <b>114</b> can be sent to the one consumer device <b>104</b> via this dedicated communication session, but no other consumer device receives the programming data via this dedicated communication session. Unicast module <b>112</b> can typically manage multiple unicast sessions concurrently. However, each of these multiple unicast sessions would be to a different consumer device <b>104</b> or would be independent unicast sessions to the same device <b>104</b>, even if the same programming data were being communicated in the multiple unicast sessions.
It should be noted that each unicast session typically involves a dedicated server and also relies on having access to a particular quality of service for network path resources. An operator of server <b>102</b> typically plans network and server capacity to meet a peak demand. This can result in significant resource needs for the unicast sessions as deployments scale to serve large numbers of users.
As discussed in more detail below, unicast module <b>112</b> receives a request from a consumer device <b>104</b> for programming that is currently being aired. Unicast module <b>112</b> establishes a unicast session with the requesting consumer device <b>104</b>, and a portion of the program that has already been aired is sent to the consumer device <b>104</b> from network buffer <b>114</b> via the unicast session. Once the data that is sent via the unicast session catches up to the data being broadcast as programming <b>120</b>, consumer device <b>104</b> switches to obtaining the remaining portions of the programming from a different source. This different source could be, for example, the source of programming <b>120</b> as programming <b>120</b> is being multicast broadcast, or from a local storage device of the consumer device <b>104</b> as discussed in more detail below.
Each consumer device <b>104</b> can be a variety of different types of devices. For example, a consumer device <b>104</b> can be a desktop computer, a mobile station, an entertainment appliance, a television, a portable computer, a television set-top box, a cellular or other wireless phone, a gaming system, an automotive computer, and so forth. Thus, consumer devices <b>104</b> may range from a full resource device with substantial memory and processor resources (e.g., personal computers, game consoles) to a low-resource device with limited memory and/or processing resources (e.g., traditional set-top boxes, hand-held game consoles).
Each consumer device <b>104</b> includes a unicast module <b>132</b>, a multicast module <b>134</b>, a local storage module <b>136</b>, and a program playback module <b>138</b>. It is also to be appreciated that a consumer device <b>104</b> can include multiple unicast modules <b>132</b>, multiple multicast modules <b>134</b>, multiple local storage modules <b>136</b>, and/or multiple program playback modules <b>138</b>. Unicast module <b>132</b> communicates with unicast module <b>112</b> of server <b>102</b> to establish a unicast session between server <b>102</b> and consumer device <b>104</b>. Unicast module <b>132</b> also manages obtaining data from server <b>102</b> (the programming data from network buffer <b>114</b>) via the unicast session. Unicast module <b>132</b> forwards the data obtained via the unicast session to program playback module <b>138</b> for playback, and/or to local storage module <b>136</b> for storage. In one or more embodiments, unicast module <b>132</b> initiates establishing the unicast session with module <b>112</b> in response to a user request received at consumer device <b>104</b> for a particular program to be played back and/or recorded, as discussed in more detail below.
Multicast module <b>134</b> manages obtaining programming <b>120</b> as the programming <b>120</b> is being multicast broadcast. Multicast module <b>134</b> receives programming <b>120</b> via network <b>106</b>, and forwards the data obtained from the multicast broadcast to program playback module <b>138</b> for playback, and/or to local storage module <b>136</b> for storage.
Local storage module <b>136</b> manages the storage of programming data on a local storage device of consumer device <b>104</b>. Module <b>136</b> can implement, for example, a digital video recorder (DVR). In one or more embodiments this local storage device is included as part of consumer device <b>104</b> (e.g., an internal disk drive of consumer device <b>104</b>). An example of such a local storage device is shown as storage device <b>140</b>(<b>1</b>). Alternatively, this local storage device can be coupled to consumer device <b>104</b>, such as via a bus (e.g., an IEEE 1394 bus, a universal serial bus (USB), a wireless universal serial bus (wireless USB), etc.), via a local network (e.g., a LAN), and so forth. An example of such a local storage device is shown as storage device <b>140</b>(M). Programming that is obtained by unicast module <b>132</b> and/or multicast module <b>134</b> can be stored in the local storage device <b>140</b> by local storage module <b>136</b>.
Program playback module <b>138</b> manages the playback of programming by consumer device <b>104</b>. Consumer device <b>104</b> can include display and/or audio playback components via which programming is played back, or alternatively consumer device <b>104</b> can output a signal to one or more other components or devices which in turn can display and/or audibly playback the programming. The video content of programming can be played back on any type of television, monitor, LCD, projector, or similar television-based display system that renders video and/or image data. The audio content of programming can be played back on any type of television, stereo, or similar television-based audible playback system that renders audio data.
The programming played back by program playback module <b>138</b> can be programming received from unicast module <b>132</b>, programming received from multicast module <b>134</b>, and/or programming retrieved from a local storage device <b>140</b> by local storage module <b>136</b>. Playback module <b>136</b> can playback programs that have been received in their entirety, as well as portions of programs (e.g., one part of a program can be played back while one or more other parts of the program are being received from multicast module <b>134</b> or unicast module <b>132</b>).
Users can input requests to consumer devices <b>104</b> for programming to be played back and/or recorded in a variety of different manners. In one or more embodiments, an electronic programming guide (EPG) is displayed to the user. The EPG includes a listing of various programs that are available, and optionally other information such as a channel on which the programs are available, a time at which the programs are aired, summary information describing the programs, and so forth. The user can navigate through the EPG in any of a variety of conventional manners (e.g., using directional keys on a remote control device) to select a particular program that he or she desires to have recorded. Alternatively, such requests can be input in other manners, such as selection of a program from a drop-down menu, inputting text identifying the program, selecting of one or more channel identifiers on a remote control (e.g., entering a channel number on the remote control), and so forth. Additionally, requests can optionally be forwarded to consumer device <b>104</b> from another device. For example, a user of a handheld device or cellular phone can send a request to consumer device <b>104</b> to request playback and/or recording of particular programming.
During operation, a user of consumer device <b>104</b> can request particular programming <b>120</b>. This request can be a request to view and/or record the programming <b>120</b>. Additionally, this request can be a request to view a particular program, or alternatively to just watch whatever programming is currently being aired on a particular channel. Situations often arise where the user requests particular programming <b>120</b> after a particular program has already begun airing. In such situations, unicast module <b>132</b> establishes a unicast session with server unicast module <b>112</b> of server <b>102</b> in order to obtain the portion of the particular program that has already begun airing from network buffer <b>114</b>. Once the programming data obtained via the unicast session catches up to the programming data being multicast as programming <b>120</b>, the unicast session can be terminated and the remaining portion of the programming obtained via the multicast broadcast.
In situations where the user requests to view and/or record a particular program, then the previously aired portion of that program is obtained as the previously aired portion of the programming by unicast module <b>132</b> via a unicast session. The previously aired portion of a program is the portion of the program that was aired starting with the beginning of the program and spanning up to the time of the user request. The previously aired portion of the program can be readily identified by consumer device <b>104</b> and/or server <b>102</b> using programming guide data (e.g., EPG data) or other metadata associated with programming <b>120</b>.
In situations where the user requests to view and/or record a particular channel rather than requesting a particular program, the previously aired portion of the programming can be identified in different manners. In one or more embodiments, a current program being aired on the channel is identified and the previously aired portion of the programming is the previously aired portion of the identified program. The program can be identified in different manners, such as via programming guide data or other metadata associated with programming <b>120</b>.
In other embodiments, the previously aired portion of the programming is identified by going backwards in time from the point in time at which the request was received. For example, the previously aired portion of the program can be a certain amount of time before the point in time at which the request was received (e.g., the preceding 15 minutes, the preceding hour, etc.). By way of another example, the previously aired portion of the programming can be the programming received since a most recent particular interval before the point in time at which the request was received (e.g., the most recent time on the hour, the most recent time on the half-hour, and so forth). As a specific example, if the request was received at 5:37 pm, then the previously aired programming could be the programming from 5:30 pm to 5:37 pm, from 5:00 pm to 5:37 pm, from 4:00 pm to 5:37 pm, and so forth. It is further to be appreciated that the previously aired portion of the programming can alternatively be identified in other manners.
In one or more embodiments, the user request is a request to playback and/or record particular programming after the airing of the programming has already begun. This request can be made by the user in a variety of different manners. The request could be a specific “restart” request via which the user requests playback and/or recording of the programming even though airing of the programming has already begun. The “restart” request invokes the restart TV functionality discussed herein. The “restart” request could be input by the user in a variety of different manners, such as by pressing a “restart” key, selecting an on-screen “restart” menu option, selecting a program that has already begun airing from an electronic programming guide, other inputs, and so forth. Alternatively, the request could be inferred by other user inputs, such as tuning to a particular channel. For example, consumer device <b>104</b> can be configured so that whenever the user tunes to or otherwise requests programming from certain channels, the tuning or other request is interpreted as a request to playback programming that has already begun airing. These certain channels can be set in different manners, such as via user preferences, device default settings, and so forth.
By way of yet another example, the “restart” request can be inherently input when a user enters a “rewind” or “skip back” command (e.g., presses a “rewind” or “skip back” button on a remote control). In response to such a command, the programming will be played back rolling backwards, using first any portion already captured on local storage device <b>140</b> and then continuing with a portion received via a unicast session with server <b>102</b>. In one or more embodiments, the user can rewind up to the earliest point of time of programming available on server <b>102</b> (e.g., 4 hours ago) or up to a point that is the beginning of the current program. When the user reaches that point the programming received via the unicast session with server <b>102</b> automatically starts playing (in the normal forward direction). If the user were to enter a “fast forward” or “skip” command, playback of the programming at a faster rate would continue with programming received via the unicast session with server <b>102</b> until the data received via the unicast session catches up to the multicast broadcast (or to data stored on local storage device <b>140</b>).
The user request could also be a request automatically input on behalf of the user, or inherent in some other request or situation. For example, a “restart” request can be incorporated into a recovery process in which a portion of the programming was missed due to a failure or other problem (e.g., a device or system crashes). As part of the recovery process, a “restart” request is included so that the missed portion of the programming can be obtained via a unicast session with server <b>102</b>.
As indicated above, once the programming data obtained via the unicast session catches up to the programming data being multicast as programming <b>120</b>, the unicast session can be terminated and the remaining portion of the programming can be obtained from another source. The manner in which the unicast session catches up to the programming data being multicast as programming <b>120</b> can vary. Generally, the data being received via the unicast session catching up to the multicast broadcast refers to the situation where the data from the unicast session is the same as the data being multicast broadcast.
In the discussions herein, reference is made to bandwidth and the amount of bandwidth available to the consumer devices <b>104</b>. Generally, the amount of bandwidth available to a particular consumer device <b>104</b> refers to the amount of data that the particular device <b>104</b> can receive. Bandwidth is oftentimes expressed in megabits per second (Mbps), although other units of measure can alternatively be used. The amount of data that a device <b>104</b> can receive can vary based on the particular device, the location of the device, a type of network the device is coupled to, other data being transferred to the device, and so forth.
In one or more embodiments, consumer device <b>104</b> obtains the previously aired portion of the programming via the unicast session concurrently with obtaining at least a portion of the remaining portion of the programming being multicast as programming <b>120</b>. In such embodiments, it is assumed that consumer device <b>104</b> has sufficient bandwidth to obtain the portions of the program via the unicast session and the multicast broadcast concurrently. By way of example, assume that programming is played back at consumer device <b>104</b> at a rate of 1 Mbps, and that consumer device <b>104</b> has 2 Mbps of available bandwidth. Accordingly, the previously aired programming is transferred to consumer device <b>104</b> via the unicast session at a rate of 1 Mbps, and the multicast broadcast of the remaining portion of the programming is broadcast at a rate of 1 Mbps. Accordingly, in this example consumer device <b>104</b> would use the available 2 Mbps of bandwidth in order to concurrently obtain both the previously aired programming and the remaining programming. In this example, the unicast session catches up to the multicast broadcast at the time in the programming that consumer device <b>104</b> began obtaining the remaining portion of the program via the multicast broadcast.
<figref idref="DRAWINGS">FIG. <b>2</b></figref> illustrates an example of the reducing unicast session duration with restart TV in accordance with one or more embodiments. <figref idref="DRAWINGS">FIG. <b>2</b></figref> illustrates an example situation where the previously aired portion of the programming is obtained via the unicast session concurrently with obtaining at least a portion of the remaining portion of the programming. In the example of <figref idref="DRAWINGS">FIG. <b>2</b></figref>, programming <b>200</b> is represented by a bar. A request to playback and/or record programming <b>200</b> after it has begun airing is received at time <b>202</b>. A previously aired portion of the programming spanning from a programming beginning time <b>204</b> and the time <b>202</b> of the request is transferred to the consumer device via a unicast session. This beginning time <b>204</b> can be a time at which a particular program began airing, or alternatively this previously aired portion can be identified in other manners as discussed above.
The remaining portion of the programming <b>200</b>, spanning from time <b>202</b> to the programming ending time <b>206</b> is transferred to the consumer device via the multicast broadcast. The programming ending time <b>206</b> refers to the time at which the consumer device stops recording and/or playing back the programming <b>200</b> being received. This programming ending time <b>206</b> can be identified in different manners, such as being the time at which airing of a particular program requested by the user ends, being the time at which the user changes channels, and so forth.
The example of <figref idref="DRAWINGS">FIG. <b>2</b></figref> assumes that the previously aired programming is obtained by the consumer device at the same rate as the programming is played back by the consumer device. Accordingly, for an amount of time <b>210</b> after the time <b>202</b> of the request, the previously aired portion of the programming is obtained via the unicast session concurrently with obtaining the remaining portion of the programming via the multicast broadcast. The amount of time <b>210</b> is approximately equivalent to the amount of time <b>212</b> between the beginning time <b>204</b> and the time <b>202</b> of the request.
As the multicast broadcast is obtained, it is stored on a local storage device by the consumer device (e.g., by a local storage module <b>136</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). In response to the request received at time <b>202</b>, playback of programming <b>200</b> at the consumer device begins at beginning time <b>204</b> using the programming data obtained via the unicast session. After amount of time <b>212</b> elapses, the playback of programming <b>200</b> at the consumer device continues using the data from the multicast broadcast that was stored on the local storage device. Accordingly, the unicast session can be terminated after the amount of time <b>212</b> elapses as the unicast session has caught up with the multicast broadcast. The remaining portion of programming <b>200</b> is played back from the multicast broadcast data stored on the local storage device by the consumer device. The duration of the unicast session can thus be reduced because the remaining portion of programming <b>200</b> is obtained via the multicast broadcast.
It should also be noted that, in the example of <figref idref="DRAWINGS">FIG. <b>2</b></figref>, after the unicast session is terminated the remaining portion of programming <b>200</b> is typically played back from the local storage device of the consumer device. As the user requested playback of the programming <b>200</b> after the programming <b>200</b> had already begun airing, the user is essentially watching a delayed version of programming <b>200</b> (delayed relative to the time the programming <b>200</b> is aired). Accordingly, after the unicast session is terminated, part of programming <b>200</b> previously recorded by the consumer device from the multicast broadcast is played back, while concurrently portions of programming <b>200</b> being multicast broadcast are recorded for subsequent playback.
Returning to <figref idref="DRAWINGS">FIG. <b>1</b></figref>, situations can arise where consumer device <b>104</b> has additional bandwidth beyond that used for the unicast session and the multicast broadcast. In such situations, the previously aired programming can be transferred to consumer device <b>104</b> via the unicast session at a rate that is faster than the rate at which the programming is played back. This transferring of the data at a faster rate allows the previously aired portion of the programming to catch up to the multicast broadcast more quickly, and allows the unicast session to thus be terminated more quickly.
By way of example, assume that programming is played back at consumer device <b>104</b> at a rate of 1 Mbps, and that consumer device <b>104</b> has 3 Mbps of available bandwidth. The remaining portion of the programming is multicast broadcast at a rate of 1 Mbps. The previously aired portion of the programming is obtained via the unicast session at a rate up to the 2 Mbps available bandwidth, allowing the previously aired portion of the program to be obtained at twice the rate as it is played back. Accordingly, in this example consumer device <b>104</b> would use the available 3 Mbps of bandwidth in order to concurrently obtain both the previously aired programming and the remaining programming. In this example, the unicast session catches up to the multicast broadcast at a time in the programming prior to the time at which consumer device <b>104</b> began obtaining the remaining portion of the program via the multicast broadcast.
<figref idref="DRAWINGS">FIG. <b>3</b></figref> illustrates an example of the reducing unicast session duration with restart TV in accordance with one or more embodiments. <figref idref="DRAWINGS">FIG. <b>3</b></figref> illustrates an example situation where the previously aired portion of the programming is obtained via the unicast session concurrently with obtaining at least a portion of the remaining portion of the programming, and where consumer device <b>104</b> has additional bandwidth beyond that used for the unicast session and the multicast broadcast. In the example of <figref idref="DRAWINGS">FIG. <b>3</b></figref>, programming <b>200</b> is represented by a bar. A request to playback and/or record programming <b>200</b> after it has begun airing is received at time <b>202</b>. A previously aired portion of programming <b>200</b> spanning from a programming beginning time <b>204</b> and the time <b>202</b> of the request is transferred to the consumer device via a unicast session. The remaining portion of programming <b>200</b>, spanning from time <b>202</b> to the programming ending time <b>206</b> is transferred to the consumer device via the multicast broadcast. These times <b>202</b>, <b>204</b>, and <b>206</b> are those discussed above with reference to <figref idref="DRAWINGS">FIG. <b>2</b></figref>.
In <figref idref="DRAWINGS">FIG. <b>3</b></figref>, at least part of the remaining portion of the programming is obtained by the consumer device concurrently with the unicast session. The example of <figref idref="DRAWINGS">FIG. <b>3</b></figref> assumes that the previously aired programming is obtained by the consumer device at a rate that is faster than the rate at which the programming is played back by the consumer device. Accordingly, for an amount of time <b>302</b> after the time <b>202</b> of the request, the previously aired portion of the programming <b>200</b> is obtained via the unicast session concurrently with obtaining the remaining portion of the programming <b>200</b> via the multicast broadcast. The amount of time <b>302</b> is less than the amount of time <b>304</b> between the beginning time <b>204</b> and the time <b>202</b> of the request because of the faster transfer rate.
As the multicast broadcast is obtained, it is stored on a local storage device by the consumer device (e.g., by a local storage module <b>136</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). Additionally, the excess bandwidth is used by the unicast session to transfer portions of programming <b>200</b> beginning at time <b>202</b> working backwards towards beginning time <b>204</b>. These portions transferred in the excess bandwidth are also stored on the local storage device by the consumer device (e.g., by a local storage module <b>136</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>).
In response to the request received at time <b>202</b>, playback of programming <b>200</b> at the consumer device begins at beginning time <b>204</b> using the programming data obtained via the unicast session. After the part of programming <b>200</b> that was originally aired between time <b>204</b> and time <b>202</b> has been transferred via the unicast session (the amount of time <b>302</b>), playback of programming <b>200</b> at the consumer device continues using the data stored on the local storage device of the consumer device. This playback from the local storage device begins using the data that was stored from the unicast session (the data transferred in the excess bandwidth), then continues using the data from the multicast broadcast. Accordingly, the unicast session can be terminated after the amount of time <b>302</b> elapses as the unicast session has caught up with the multicast broadcast. The duration of the unicast session can thus be reduced because the remaining portion of programming <b>200</b> is obtained via the multicast broadcast, and further because the excess bandwidth is used to obtain the previously aired portion of programming <b>200</b> more quickly.
Alternatively, the unicast session can be used to obtain the previously aired portion of the programming in other manners other than using the excess bandwidth to transfer portions of programming <b>200</b> beginning at time <b>202</b> working backwards towards beginning time <b>204</b>. By way of example, the unicast session could use the excess bandwidth to generate a buffer locally on the consumer device (e.g., by local storage module <b>136</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). This buffer would be filled working forward from time <b>204</b> to time <b>202</b>, until the unicast session catches up to the multicast broadcast. In this example, the previously aired programming is played back from the buffer on the consumer device rather than being played back as it is received in the unicast session.
Returning to <figref idref="DRAWINGS">FIG. <b>1</b></figref>, situations can arise where consumer device <b>104</b> does not have sufficient bandwidth to obtain both the previously aired programming via the unicast session and the remaining portion of the programming via the multicast broadcast concurrently. In such situations, consumer device <b>104</b> obtains the data for the programming via the unicast session until the data obtained via the unicast session catches up with the multicast broadcast. If there is sufficient bandwidth, the data can be transferred to consumer device <b>104</b> via the unicast session at a rate that is faster than the rate at which the programming is played back in order to catch up with the multicast broadcast quicker.
By way of example, assume that programming is played back at consumer device <b>104</b> at a rate of 1 Mbps, that the programming is multicast broadcast at a rate of 1 Mbps, and that consumer device <b>104</b> has 1.5 Mbps of available bandwidth. The previously aired portion of the programming is obtained via the unicast session at a rate up to the 1.5 Mbps available bandwidth. Additional portions of the programming aired after the request to playback and/or record the programming are also obtained via the unicast session. In this example, the unicast session catches up to the multicast broadcast at a time in the programming after the time at which the user requested playback and/or recording of the programming.
<figref idref="DRAWINGS">FIG. <b>4</b></figref> illustrates an example of the reducing unicast session duration with restart TV in accordance with one or more embodiments. <figref idref="DRAWINGS">FIG. <b>4</b></figref> illustrates an example situation where the consumer device has insufficient bandwidth to obtain both the previously aired programming via the unicast session and the remaining portion of the programming via the multicast broadcast concurrently. In the example of <figref idref="DRAWINGS">FIG. <b>4</b></figref>, programming <b>200</b> is represented by a bar, the programming <b>200</b> having a beginning time <b>204</b> and an ending time <b>206</b>. A request to playback and/or record programming after it has begun airing is received at time <b>202</b>. These times <b>202</b>, <b>204</b>, and <b>206</b> are those discussed above with reference to <figref idref="DRAWINGS">FIG. <b>2</b></figref>.
In response to the request to playback and/or record programming <b>200</b> at time <b>202</b>, transfer of a previously aired portion of the programming from programming beginning time <b>204</b> begins. The portion of programming <b>200</b> being multicast broadcast is not received and stored by the consumer device as there is insufficient bandwidth for the consumer device to do so.
If there is no excess bandwidth beyond the rate at which the consumer device plays back programming <b>200</b>, then the unicast session typically does not catch up to the multicast session. However, if there is excess bandwidth beyond the rate at which the consumer device plays back programming <b>200</b>, then the unicast session can catch up to the multicast broadcast, typically at some time after time <b>202</b>. Whether the unicast session catches up to the multicast broadcast, and if so the exact time at which the unicast session catches up to the multicast broadcast, can vary based on the amount of excess bandwidth, the time <b>202</b> the request was received, and how much time remains between the time <b>202</b> the request was received and the programming ending time <b>206</b>.
<figref idref="DRAWINGS">FIG. <b>4</b></figref> illustrates one example where the consumer device has excess bandwidth beyond the rate at which the consumer device plays back programming <b>200</b>. In this example, the unicast session catches up to the multicast broadcast at a time <b>402</b> that is later in programming <b>200</b> than the time <b>202</b> that the request was received. The consumer device stores on a local storage device (e.g., using a local storage module <b>136</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>) portions of programming <b>200</b> obtained via the unicast session that are not yet played back. Once the unicast session catches up to the multicast broadcast, the consumer device begins storing the multicast data on the local storage device (e.g., using a local storage module <b>136</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). In this example, portion <b>404</b> of the programming is obtained via the unicast session, while portion <b>406</b> of the programming is obtained via the multicast broadcast. The duration of the unicast session can thus be reduced because of the excess bandwidth being used to obtain portions of programming <b>200</b> more quickly.
Thus, following this example in <figref idref="DRAWINGS">FIG. <b>4</b></figref>, in response to the request at time <b>202</b>, playback of the programming begins with the programming being obtained via the unicast session. After the unicast session catches up to the multicast broadcast, playback of the programming continues using the data stored on the local storage device of the consumer device. This playback from the local storage device begins using the data that was stored from the unicast session (the data transferred in the excess bandwidth), then continues using the data from the multicast broadcast.
In alternate embodiments, situations where the consumer device has insufficient bandwidth to obtain programming from the unicast session and the multicast broadcast concurrently are managed differently. By way of example, if the multicast broadcast protocol allows the multicast broadcast to be joined even if the consumer device has insufficient bandwidth, then the consumer device can obtain part of the programming via the multicast broadcast concurrently with obtaining part of the programming via the unicast session. Any parts of the multicast broadcast that could not be recorded due to the insufficient bandwidth can be obtained in other manners, such as via the unicast session, via another multicast broadcast, and so forth.
Various examples are discussed with reference to <figref idref="DRAWINGS">FIGS. <b>2</b>-<b>4</b></figref> above. These examples refer to the playback of programming <b>200</b>, although it is to be appreciated that the techniques discussed above can be used in situations where programming <b>200</b> is being recorded but not yet played back. In such situations, the data received via the unicast session is recorded to the local storage device of the consumer device rather than being played back. Subsequently, in response to a user request to playback the data, the programming data received via the unicast session and the multicast session is played back from the local storage device.
Also in the discussions of <figref idref="DRAWINGS">FIGS. <b>2</b>-<b>4</b></figref>, reference is made to a time <b>202</b> that a request is being received. It is to be appreciated that various actions based on time <b>202</b> are only approximations, and that various delays may be present with respect to time <b>202</b>. For example, a delay (e.g., 300 milliseconds, 2 seconds, 5 seconds, etc.) may exist between the time the user physically inputs a request and the time the consumer device begins obtaining and recording the multicast broadcast.
As discussed above, a switch from obtaining data via the unicast session to obtaining data from another source is made when the unicast session catches up to the multicast broadcast. Generally, this catching up refers to the situation where the data received (or to be received) via the unicast session is the same as the data received (or to be received) via the multicast broadcast. This situation can be identified in a variety of different manners.
In one or more embodiments, the programming is separated into multiple pieces or packets each having an associated timestamp. This timestamp can be, for example, the time at which that piece or packet is to be played back relative to the other pieces or packets in the programming (e.g., a presentation timestamp), the time at which the piece or packet is to be sent to consumer devices relative to the other pieces or packets in the programming (e.g., a delivery timestamp), a specific date and/or time at which that piece or packet is to be played back, and so forth. When the timestamp for a piece or packet received via the unicast session is the same as the timestamp for a piece or packet being broadcast via the multicast broadcast, then the unicast session has caught up to the multicast broadcast. In one or more embodiments, this determination of when the timestamps are the same can be made by a server (e.g., server <b>102</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). Alternatively, the timestamps for pieces or packets being broadcast via the multicast broadcast can be made available to the consumer device, in which case the consumer device can make the determination.
<figref idref="DRAWINGS">FIG. <b>5</b></figref> is a flowchart illustrating an example process <b>500</b> for reducing unicast session duration with restart TV in accordance with one or more embodiments. Process <b>500</b> is carried out by a consumer device, such as a device <b>104</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>, and can be implemented in software, firmware, hardware, or combinations thereof. Process <b>500</b> is an example process for reducing unicast session duration with restart TV. Additional discussions of reducing unicast session duration with restart TV are included herein with reference to different figures.
In process <b>500</b>, a unicast session is established with a server (act <b>502</b>). This unicast session is typically established in response to a request from a user of the consumer device to playback and/or record programming that has already begun airing. A first portion of programming is obtained via the unicast session (act <b>504</b>). A check is made as to whether the data in the unicast session has caught up with the multicast broadcast of the programming (act <b>506</b>), and this first portion continues to be obtained via the unicast session until the data in the unicast session catches up with the multicast broadcast of the programming. As discussed above, the point at which the unicast session catches up with the multicast broadcast of the programming can vary, based at least in part on the time when the request to playback and/or record the programming is received and the amount of bandwidth available to the consumer device. Also as discussed above, the unicast session can be determined to have caught up to the multicast session in a variety of different manners.
When the data obtained in the unicast session has caught up with the multicast broadcast of the programming, then the consumer device switches to obtaining the remaining portion of the programming from a different source (act <b>508</b>). As discussed above, this different source could be a local storage device (e.g., a local DVR), or could be the multicast broadcast. As part of this switching, a request to terminate the unicast session can be sent to the server.
<figref idref="DRAWINGS">FIG. <b>6</b></figref> is a flowchart illustrating an example process <b>600</b> for reducing unicast session duration with restart TV in accordance with one or more embodiments. Process <b>600</b> is carried out by a server, such as a server <b>102</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>, and can be implemented in software, firmware, hardware, or combinations thereof. Process <b>600</b> is an example process for reducing unicast session duration with restart TV. Additional discussions of reducing unicast session duration with restart TV are included herein with reference to different figures.
In process <b>600</b>, a unicast session is established with a consumer device (act <b>602</b>). This unicast session is typically established in response to a request from a user of the consumer device to playback and/or record programming that has already begun airing. A first portion of programming is sent to the consumer device via the unicast session (act <b>604</b>). This first portion continues to be sent via the unicast session until the data in the unicast session catches up with the multicast broadcast of the programming (act <b>606</b>). As discussed above, the point at which the unicast session catches up with the multicast broadcast of the programming can vary, based at least in part on the time when the request to playback and/or record the programming is received and the amount of bandwidth available to the consumer device. Also as discussed above, the unicast session can be determined to have caught up to the multicast session in a variety of different manners.
When the data obtained in the unicast session has caught up with the multicast broadcast of the programming, then the unicast session is terminated (act <b>608</b>). In one or more embodiments the server determines when the unicast session has caught up with the multicast broadcast of the program, and terminates the unicast session at that time. The server also optionally informs the consumer device that the unicast session is being terminated, and that the consumer device is to obtain the remaining portion of the programming from another source. In other embodiments, the consumer device determines when the unicast session has caught up with the multicast broadcast of the program, and informs the server that the unicast session is to be terminated.
It should be noted that, in one or more embodiments various changes can be made to the particular programming that is obtained by the consumer device via the unicast session and/or the multicast broadcast. For example, if the user were to fast forward through part of the previously aired programming being obtained via the unicast session, then that part that is fast forwarded through would not need to be obtained via the unicast session, allowing the unicast session to catch up to the multicast broadcast sooner.
<figref idref="DRAWINGS">FIG. <b>7</b></figref> illustrates various components of an example client device <b>700</b> that can be implemented as any form of a computing, electronic, or television client device to implement one or more embodiments of the reducing unicast session duration with restart TV. For example, client device <b>700</b> can be implemented as any of the consumer devices <b>104</b>(<b>1</b>-M) shown in <figref idref="DRAWINGS">FIG. <b>1</b></figref>. In various embodiments, client device <b>700</b> can be implemented as any one or combination of a television client device, a gaming system, or as any other computing-based device, such as a desktop computer, a portable computer, a television set-top box, a digital video recorder (DVR), an appliance device, a gaming console, and/or as any other type of computing-based client device.
Client device <b>700</b> includes one or more media content inputs <b>702</b> that may include Internet Protocol (IP) inputs over which streams of media content (programming) are received via an IP-based network. These streams can be received via unicast sessions and/or multicast broadcasts as discussed above. Client device <b>700</b> further includes communication interface(s) <b>704</b> that can be implemented as any one or more of a serial and/or parallel interface, a wireless interface, any type of network interface, a modem, and as any other type of communication interface. A wireless interface enables client device <b>700</b> to receive control input commands <b>706</b> and other information from an input device, such as from remote control device <b>708</b>, a portable computing-based device (such as a cellular phone) <b>710</b>, or from another infrared (IR), 802.11, Bluetooth, or similar RF input device.
A network interface provides a connection between client device <b>700</b> and a communication network by which other electronic and computing devices can communicate data with device <b>700</b>. Similarly, a serial and/or parallel interface provides for data communication directly between client device <b>700</b> and the other electronic or computing devices. A modem facilitates client device <b>700</b> communication with other electronic and computing devices via a conventional telephone line, a DSL connection, cable, and/or other type of connection.
Client device <b>700</b> also includes one or more processors <b>712</b> (e.g., any of microprocessors, controllers, and the like) which process various computer-executable instructions to control the operation of device <b>700</b>, to communicate with other electronic and computing devices, and to implement embodiments of the local recording of previously aired programming. Client device <b>700</b> can be implemented with computer-readable media <b>714</b>, such as one or more memory components, examples of which include random access memory (RAM), non-volatile memory (e.g., any one or more of a read-only memory (ROM), flash memory, EPROM, EEPROM, etc.), and a disk storage device. A disk storage device can include any type of magnetic or optical storage device, such as a hard disk drive, a recordable and/or rewriteable compact disc (CD), a DVD, a DVD+RW, and the like.
Computer-readable media <b>714</b> provides data storage mechanisms to store various information and/or data such as software applications and any other types of information and data related to operational aspects of client device <b>700</b>. For example, an operating system <b>716</b> and/or other computer applications <b>718</b> can be maintained as software applications with the computer-readable media <b>714</b> and executed on processor(s) <b>712</b> to implement embodiments of the local recording of previously aired programming.
Client device <b>700</b> can also include a program guide application <b>720</b> that is implemented to process program guide data and generate program guides for display. A program guide enables a viewer to navigate through an onscreen display and locate various media content such as broadcast programs, recorded programs, video-on-demand programs and movies, interactive game selections, network-based applications, and other media content of interest to the viewer.
Client device <b>700</b> can also include a DVR system <b>724</b> with playback application <b>726</b>, and recording media <b>728</b> to maintain recorded media content <b>730</b> that client device <b>700</b> downloads (or otherwise receives) and/or records. DVR system <b>724</b> can optionally include local storage module <b>136</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>. Further, client device <b>700</b> may access or receive additional recorded media content that is maintained with a remote data store (not shown). Client device <b>700</b> may also receive media content from a video-on-demand server, or media content that is maintained at a broadcast center or content distributor that distributes the media content to subscriber sites and client devices. The playback application <b>726</b> is a video control application that can be implemented to control the playback of media content, the recorded media content <b>730</b>, and/or other video-on-demand media content, music, and any other audio, video, and/or image media content which can be rendered and/or displayed for viewing.
Client device <b>700</b> also includes an audio and/or video output <b>732</b> that provides audio and/or video data to an audio rendering and/or display system <b>734</b>. The audio rendering and/or display system <b>734</b> can include any devices that process, display, and/or otherwise render audio, video, and image data. Video signals and audio signals can be communicated from client device <b>700</b> to a display device <b>736</b> via an RF (radio frequency) link, S-video link, composite video link, component video link, DVI (digital video interface), analog audio connection, or other similar communication link. Alternatively, the audio rendering and/or display system <b>734</b> can be implemented as integrated components of the example client device <b>700</b>. Client device <b>700</b> along with the audio rendering and/or display system <b>734</b> is an example of a viewing system that can be implemented in a household viewing area for viewing television programs and/or receiving other television media content.
<figref idref="DRAWINGS">FIG. <b>8</b></figref> illustrates an example entertainment and information system <b>800</b> in which one or more embodiments of the reducing unicast session duration with restart TV can be implemented. System <b>800</b> facilitates the distribution of media content, program guide data, and advertising content to multiple viewers and to multiple viewing systems. System <b>800</b> includes a content distributor <b>802</b> and any number “N” of client systems <b>804</b>(<b>1</b>-N) each configured for communication via a communication network <b>806</b>. Each client system <b>804</b>(<b>1</b>-N) is an example of the consumer devices <b>104</b>(<b>1</b>-M) described with reference to <figref idref="DRAWINGS">FIG. <b>1</b></figref>. Each of the client systems <b>804</b>(<b>1</b>-N) can receive data streams of media content, program content, program guide data, advertising content, closed captions data, and the like from content server(s) of the content distributor <b>802</b> via the communication network <b>806</b>.
The communication network <b>806</b> can be implemented as any one or combination of a wide area network (e.g., the Internet), a local area network (LAN), an intranet, an IP-based network, a broadcast network, a wireless network, a Digital Subscriber Line (DSL) network infrastructure, a point-to-point coupling infrastructure, or as any other media content distribution network. Additionally, communication network <b>806</b> can be implemented using any type of network topology and any network communication protocol, and can be represented or otherwise implemented as a combination of two or more networks. A digital network can include various hardwired and/or wireless links <b>808</b>(<b>1</b>-N), routers, gateways, and so on to facilitate communication between content distributor <b>802</b> and the client systems <b>804</b>(<b>1</b>-N).
System <b>800</b> includes a media server <b>810</b> that receives media content from a content source <b>812</b>, program guide data from a program guide source <b>814</b>, and advertising content from an advertisement source <b>816</b>. In one or more embodiments, the media server <b>810</b> represents an acquisition server that receives the audio and video media content from content source <b>812</b>, an EPG server that receives the program guide data from program guide source <b>814</b>, and/or an advertising management server that receives the advertising content from the advertisement source <b>816</b>.
The content source <b>812</b>, the program guide source <b>814</b>, and the advertisement source <b>816</b> control distribution of the media content, the program guide data, and the advertising content to the media server <b>810</b> and/or to other servers. The media content, program guide data, and advertising content can be distributed via various transmission media <b>818</b>, such as satellite transmission, radio frequency transmission, cable transmission, and/or via any number of other wired or wireless transmission media. In this example, media server <b>810</b> is shown as an independent component of system <b>800</b> that communicates the program content, program guide data, and advertising content to content distributor <b>802</b>. In an alternate implementation, media server <b>810</b> can be implemented as a component of content distributor <b>802</b>.
Content distributor <b>802</b> is representative of a headend service in a content distribution system, for example, that provides the media content, program guide data, and advertising content to multiple subscribers (e.g., the client systems <b>804</b>(<b>1</b>-N)). The content distributor <b>802</b> can be implemented as a satellite operator, a network television operator, a cable operator, and the like to control distribution of media content, program and advertising content, such as movies, television programs, commercials, music, and other audio, video, and/or image content to the client systems <b>804</b>(<b>1</b>-N).
Content distributor <b>802</b> includes various content distribution components <b>820</b> to facilitate media content processing and distribution, such as a subscriber manager, a device monitor, and one or more content servers. The subscriber manager manages subscriber data, and the device monitor monitors the client systems <b>804</b>(<b>1</b>-N) (e.g., and the subscribers), and maintains monitored client state information.
Although the various managers, servers, and monitors of content distributor <b>802</b> (to include the media server <b>810</b> in one or more embodiments) are described as distributed, independent components of content distributor <b>802</b>, any one or more of the managers, servers, and monitors can be implemented together as a multi-functional component of content distributor <b>802</b>. Additionally, any one or more of the managers, servers, and monitors described with reference to system <b>800</b> can implement features and embodiments of the reducing unicast session duration with restart TV.
The content distributor <b>802</b> includes communication interface(s) <b>822</b> that can be implemented as any type of interface to communicate and receive data from client devices of the television system, including unicast sessions and/or multicast broadcasts as discussed above. The content distributor <b>802</b> also includes one or more processors <b>824</b> (e.g., any of microprocessors, controllers, and the like) which process various computer-executable instructions to control the operation of content distributor <b>802</b>. The content distributor <b>802</b> also includes a network buffer <b>838</b> that operates analogous to network buffer <b>114</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>, temporarily storing programs received from content source <b>812</b> (e.g., via media server <b>810</b>). The content distributor <b>802</b> can be implemented with computer-readable media <b>826</b> which provides data storage to maintain software applications such as an operating system <b>828</b> and media content <b>830</b> for distribution to the client systems <b>804</b>(<b>1</b>-N).
The client systems <b>804</b>(<b>1</b>-N) can each be implemented to include a client device <b>832</b> and a display device <b>834</b> (e.g., a television, LCD, and the like). A client device <b>832</b> of a respective client system <b>804</b> can be implemented in any number of embodiments, such as a set-top box, a digital video recorder (DVR) and playback system, an appliance device, a gaming system, and as any other type of client device that may be implemented in an entertainment and information system. In an alternate embodiment, client system <b>804</b>(N) is implemented with a computing device <b>836</b> as well as a client device. The computing device <b>836</b> is an example of a connected data store that can record and maintain media content for a client device. Additionally, any client device <b>832</b> of a respective client system <b>804</b> can implement features and embodiments of the reducing unicast session duration with restart TV as described herein.
Generally, any of the functions or techniques described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module” and “component” as used herein generally represent software, firmware, hardware, or combinations thereof. In the case of a software implementation, the module or component represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer-readable memory devices, further description of which may be found with reference to <figref idref="DRAWINGS">FIGS. <b>7</b> and <b>8</b></figref>. The features of the local recording of previously aired programming techniques described herein are platform-independent, meaning that the techniques can be implemented on a variety of commercial computing platforms having a variety of processors.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Contents5
8 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8
Every citation, both waysCites: the store holds 1,000 of 3,646
| Document | Relation | Office | Cited during |
|---|---|---|---|
| WO0001149A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0002385A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0004706A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0004707A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0004708A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0004709A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0005885A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0005889A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0007368A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0008850A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0008851A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0008852A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0011865A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0011869A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0013415A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0013416A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0016336A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0016548A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0017738A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0027122A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0028379A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0028734A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0028739A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0030345A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0033160A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0033208A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0033224A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0033560A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0033565A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0033573A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0033578A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0034891A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0035193A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0040012A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0040014A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0040026A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0044146A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0049801A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0051310A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0058214A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0058833A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0058967A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0059214A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0059223A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0059230A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0059233A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0062298A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0062299A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0062533A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0067475A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| EP0072153A2 | Cites | European Patent Office (EPO) | Applicant |
| WO0074383A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0079798A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0101677A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0103088A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0106784A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0110126A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0110128A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0115438A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| EP0122626A2 | Cites | European Patent Office (EPO) | Applicant |
| WO0122729A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| EP0133985A2 | Cites | European Patent Office (EPO) | Applicant |
| WO0135662A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0137549A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0146843A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0147238A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0147249A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0147257A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0147273A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0147279A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| EP0160545A2 | Cites | European Patent Office (EPO) | Applicant |
| WO0169929A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0176239A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0176248A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0176704A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0182600A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0189213A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0193588A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0198920A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO02067579A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO02069636A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO02078317A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO02084992A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0231731A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| EP0239884A1 | Cites | European Patent Office (EPO) | Applicant |
| EP0276425A2 | Cites | European Patent Office (EPO) | Applicant |
| WO03005712A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO03032634A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO03041410A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO03043321A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO03047235A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO03060157A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO03098932A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| EP0339675A2 | Cites | European Patent Office (EPO) | Applicant |
| EP0396062A2 | Cites | European Patent Office (EPO) | Applicant |
| EP0401930A2 | Cites | European Patent Office (EPO) | Applicant |
| EP0408892A1 | Cites | European Patent Office (EPO) | Applicant |
| EP0420123A2 | Cites | European Patent Office (EPO) | Applicant |
| EP0424469A1 | Cites | European Patent Office (EPO) | Applicant |
| EP0424648A2 | Cites | European Patent Office (EPO) | Applicant |
3 members in 1 office
Priority claims1
| Document | Office | Kind | Date |
|---|---|---|---|
| 27779708 | United States of America | A |
Members3
| Document | Office | Kind | |
|---|---|---|---|
| US2010131995A1 | United States of America | A1 | |
| US10063934B2 | United States of America | B2 | |
| USRE50355EThis record | United States of America | E |
127 transactions on the USPTO file
Allowed after 3 non-final rejections, 3 final rejections and 2 RCEs.
- Non-final rejections
- 3
- Final rejections
- 3
- RCEs
- 2
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Patent eGrant NotificationMEPG_NTF | MEPG_NTF | |
| Patent eGrant NotificationEPG_NTF | EPG_NTF | |
| Recordation of Patent eGrantEPG/ | EPG/ | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Response to 312 Amendment (PTO-271)MN271 | MN271 | |
| Response to Amendment under Rule 312N271 | N271 | |
| Pubs Case Remand to TCPUBTC | PUBTC | |
| Amendment after Notice of Allowance (Rule 312)AllowedA.NA | A.NA | |
| Email NotificationEML_NTR | EML_NTR | |
| Mailing Corrected Notice of AllowabilityMCNOA | MCNOA | |
| Corrected Notice of AllowabilityCNOA | CNOA | |
| Pubs Case Remand to TCPUBTC | PUBTC | |
| Email NotificationEML_NTR | EML_NTR | |
| Filing Receipt - CorrectedFLRCPT.C | FLRCPT.C | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Final ActionA.NE | A.NE | |
| Oath or Declaration Filed (Including Supplemental)C602 | C602 | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Interview Summary RecordEXIN | EXIN | |
| Electronic request for Examiner InterviewM865E | M865E | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Application ready for PDX access by participating foreign officesCCRDY | CCRDY | |
| Application ready for PDX access by participating foreign officesCCRDY | CCRDY | |
| Mail Post CardPST_CRD | PST_CRD | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Interview Summary RecordEXIN | EXIN | |
| Electronic request for Examiner InterviewM865E | M865E | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Interview Summary RecordEXIN | EXIN | |
| Electronic request for Examiner InterviewM865E | M865E | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Interview Summary RecordEXIN | EXIN | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Electronic request for Examiner InterviewM865E | M865E | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Paralegal Reissue Review CompletePRIR | PRIR | |
| Paralegal Reissue Review CompletePRIR | PRIR |
4 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Fee payment procedureENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP |
Numbers
- Publication
- RE050355
- Application
- 17006545
Titles
- English
- Reducing unicast session duration with restart TV
Classification
- CPC, 6
- H04N21/631
- H04N21/4325
- H04N21/4334
- H04N21/4622
- H04N21/6405
- H04N21/6408
- IPC, 6
- H04N21 63
- H04N21 432
- H04N21 433
- H04N21 462
- H04N21 6405
- H04N21 6408