Patent Description:
The term "streaming media" generally refers to the reception of multimedia content, such as television programming and other audiovisual content, through a communications network at a bitrate enabling presentation of the content in real time as it is received. Streaming media may be viewed live or on-demand and provided by, for example, a pay Television (TV) provider, a Video-On-Demand (VOD) provider, or a remotely-controlled placeshifting device. In the case of VOD services, the media content may be stored in a pre-encoded format and distributed to a client media receiver, such as a mobile phone or Set-Top Box (STB), over a Content Delivery Network (CDN). In the case of placeshifted media, a digital video recorder (DVR), STB, or a similar device having placeshifting capabilities and located within a user's residence may encode and transmit selected streaming media to a client media receiver, such as a mobile phone or tablet, operated by the end user. Increasingly, a demand has arisen to provide such streaming content in a linear multichannel format as, for example, Over-The-Top (OTT) TV programming.

Ideally, multichannel streaming services mimic the familiar in-home viewing experience provided by legacy cable and satellite broadcast systems. However, network reliability issues, bandwidth constraints, latency effects, and other such limiting factors may negatively impact multichannel streaming services delivered through the Internet and similar communications networks. As a specific example, relatively prolonged delays or temporal lags can occur in implementing user-requested channel changes when streaming multichannel content to a mobile phone or other client media receiver. Depending upon dynamic network parameters, such as varying bandwidth constraints, the duration of such lags (as measured from input of the channel change request to presentation of the newly-requested streaming channel) can approach or exceed <NUM> seconds in certain instances. Such pronounced lags in executing channel change requests detracts from the viewing experience and may be frustrating to end users accustom to near instantaneous channel browsing (colloquially, "channel surfing") offered by traditional broadcast systems. As an additional drawback, prolonged channel browsing by an end user can result in the transmission of a needless series of channel change requests to the streaming media server, which consumes network bandwidth and increases server processing demands.

It is thus desirable to lessen, if not eliminate lags in implementing end user request to change streaming channels during multichannel streaming sessions. Similarly, it is desirable to better utilize network bandwidth capacity and alleviate media server processing loads in multichannel streaming environments by, for example, reducing excessive channel change requests generated by a client media receiver when an end user engages in prolonged channel browsing or "channel surfing" behaviors. The following describes devices, systems, methods, and program products providing such desirable features and characteristics. Other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background section.

European patent application <CIT> describes a system to reduce change latency and/or to provide a picture-in-picture (PIP) feature within a place-shifted media stream. As the viewer receives a primary stream containing selected programming, secondary programming that is likely to be of interest to the user is predicted. A secondary stream containing the predicted content is obtained at the same time as the primary stream selected by the user. The secondary stream may be of lower quality than the primary stream to preserve network bandwidth. If the user subsequently selects the predicted secondary content, the previously-obtained content can be quickly provided as an output to the display. Alternately, the primary and secondary streams may be simultaneously output to the display in PIP or another manner.

US patent application <CIT> describes a method for processing a channel change request in a television system operating according to the IP protocol. The method is implemented in a digital decoder of the subscriber and its purpose is to avoid overloading the access network in the case of burst zapping and avoid penalising the reactivity time of the system in the case of simple zapping. According to the invention, in the case of reception of a burst of channel change requests separated by a time interval less than the duration of the predetermined timeout (Ttempo), the digital decoder transmits, to the access network of the system, two physical channel change requests, one for the first channel change request and the other for the last channel change request of the burst. The first request is transmitted immediately after the reception of the first channel change request and the last request is transmitted with a delay equal to the duration of the timeout after the reception of the last channel change request. In the case of simple zapping, the digital decoder transmits immediately after reception of the channel change request a physical channel change request.

US patent application <CIT> describes a system for rapid content switching between pieces of content presented in a plurality of stations using streaming content distribution. One embodiment includes processing a portion of a station manifest that includes identifiers for content stations and identifiers for pieces of content associated with content stations, selecting jump points that are associated with specific locations within pieces of content, determining a current content station, playing a portion of a current piece of content associated with the current content station, determining alternative pieces of content using the station manifest, preparing additional content for playback at each of the jump points by preparing alternative pieces of content during playback of the current content, receiving a user instruction during playback, selecting a target jump point based upon the user instruction, and commencing playback of additional content starting from the target jump point.

The methods set-forth above and described elsewhere in this document can be implemented utilizing complementary program products, such as software applications executed on suitably-equipped client media receivers and streaming media servers. Various additional examples, aspects, and other useful features of embodiments of the present disclosure will also become apparent to one of ordinary skill in the relevant industry given the additional description provided below.

Exemplary embodiments will hereinafter be described in conjunction with the following drawing figures, wherein like numerals denote like elements, and:.

The following Detailed Description is merely exemplary in nature and is not intended to limit the invention or the application and uses of the invention. The term "exemplary," as appearing throughout this document, is synonymous with the term "example" and is utilized repeatedly below to emphasize that the description appearing in the following section merely provides multiple non-limiting examples of the invention and should not be construed to restrict the scope of the invention, as set-out in the Claims, in any respect.

The following describes devices, systems, methods, and program products enabling temporally-seamless change functionalities during a multichannel streaming session established between a streaming media server and a client media receiver. Upon initialization of a given multichannel streaming session, the streaming media server transmits to the client media receiver a streaming channel bundle. The streaming channel bundle contains multiple streaming channels, at least one of which is initially designated as a "primary" streaming channel and others of which are initially designated as "secondary" streaming channels. The particular channels identified as the primary and secondary streaming channels may be varied by the client media receiver in accordance with user input and other factors. The streaming channel currently viewed by the end user will typically be identified as the "primary" streaming channel, at any given time, although this may not be the case during channel browsing when one or more secondary channels are briefly presented in a transitory manner. The streaming media server usefully ensures that the high priority primary streaming channel is encoded and transmitted to the client media receiver in a substantially continuous or non-interrupted manner and at an optimal quality during the multichannel streaming session, absent severe bandwidth constraints. In contrast, the lower priority secondary channels may be transmitted intermittently by the streaming media server and/or the quality of the secondary channels may be selectively reduced during the multichannel streaming session to, for example, accommodate variations in communications network bandwidth or other limiting resources.

In embodiments, the client media receiver monitors for channel change requests generated by an end user during a given multichannel streaming session. Upon receipt of a user channel change request, the client media receiver presents a live stream of the requested streaming channel if available as a part of the streaming channel bundle. If a live stream of the requested streaming channel is presently unavailable to the receiver, the client media receiver may instead present a recently-recorded segment of the newly-requested streaming channel, as stored in a memory contained in or otherwise associated with and accessible by the client media receiver. When appropriate, the client media receiver may also transmit instructions to the streaming media server to provide a live stream of the newly-requested streaming channel. The live stream of the newly-requested streaming channel may be appended to the recorded segment prior to elapse of the segment to avoid any discontinuity in presentation of the streaming channel to the end user. In certain embodiments, the client media receiver may also request and receive a historical gap fill segment spanning a time period from the conclusion of the recorded segment to the time of live streaming. In this manner, content from any requested streaming channel for which recorded segments are repeatedly (continually or periodically) stored by the client media receiver can be presented to the end user in an essentially instantaneous manner. Temporally-seamless channel browsing is thus supported in a multichannel streaming environment. This is highly desirable.

Different prioritization hierarchies may be utilized to classify or categorize to the streaming channels contained in the streaming channel bundle. In certain instances, a relatively simple, two tier hierarchy may be employed such that the primary streaming channel is assigned the highest possible priority ranking, while the remaining secondary channels are assigned lower priority rankings. In other implementations, hierarchies containing more than two tiers may be employed; e.g., certain secondary channels may be assigned intermediate priority levels based upon relevancy to the content of the primary streaming channel, predicted likelihood of future selection by the end user, numerical proximity (in channel number) to the primary streaming channel, and other such factors. Regardless of the complexity of the channel priority ranking scheme, the streaming media server usefully references the priority ranking in determining bandwidth allocations between the streaming channels. As generally indicated above, the streaming media server may allocate available bandwidth in a manner ensuring substantially continuous encoding and transmission of the primary streaming channel at an optimal quality level, to the extent possible. Comparatively, those secondary streaming channels assigned lower priority levels may be selectively encoded and transmitted to the client media receiver at lower qualities and/or in an intermittent (e.g., temporally-staggered) manner, as dictated by changing bandwidth constraints and with due consideration given to any variance in priority rankings between the secondary streaming channels.

In various embodiments, the client media receiver may selectively transmit channel reprioritization commands to the streaming media server during multichannel streaming sessions. Issuance of the channel reprioritization commands can be based, at least in part, on user channel change requests received at the client media receiver. For example, after receiving a user channel change request, the client media receiver may await the elapse of a predetermined time threshold or wait period before transmitting a channel reprioritization command to the streaming media server. In this case, countdown of the channel change wait period may commence upon receipt of a user channel change request and begin anew should an additional user channel change request be received prior to elapse of the channel change wait period. Through the implementation of such a channel change wait period in combination with the above-described streaming channel prioritization scheme, the transmission of needless or superfluous channel change requests or reprioritization commands from the client media receiver to the streaming media server can be minimized. This, in turn, alleviates server processing loads and helps optimize network bandwidth allocations during multichannel streaming sessions.

Embodiments of the multichannel streaming devices, systems, methods, and program products described herein may provide other useful functionalities in addition to or in lieu of those set-forth above. Such other functionalities may include, but are not limited to, the provision of a "jump-to-live" option when a temporal delay or lag is imparted to currently-viewed streaming channel by virtue of the presentation of recently-recorded segment of the streaming channel. Additionally or alternatively, the client media receiver may enable an end user to transition from live multichannel viewing to Video On Demand (VOD) consumption by, for example, automatically downloading one or more additional episodes of an episodic series when an episode of the series is currently being viewed by the end user on the primary streaming channel. The client media receiver may then provide corresponding prompts at a designated trigger event (e.g., after conclusion of the currently-viewed episode) to determine whether the end user would like to view any additional episodes of the series as VOD programming. Exemplary embodiment of devices, systems, methods, and program products providing such useful functionalities will now be described in conjunction with <FIG>.

<FIG> schematically illustrates a multichannel streaming system <NUM>, which may conduct a prioritized multichannel streaming session and which is depicted in accordance with an embodiment of the present disclosure. In the illustrated example, multichannel streaming system <NUM> includes a streaming media server <NUM>, a client media player or receiver <NUM>, and a display device <NUM>. During operation of multichannel streaming system <NUM>, bidirectional communication between streaming media server <NUM> and client media receiver <NUM> occurs through a communications network <NUM>, while client media receiver <NUM> outputs video (and possibly audio) signals over a wired or wireless connection to display device <NUM>. The foregoing components can each be implemented utilizing any suitable number and combination of known devices including microprocessors, memories, power supplies, storage devices, interface cards, and other standard components. Such components may include or cooperate with any number of software programs or instructions designed to carry-out the various methods, process tasks, encoding and decoding algorithms, and relevant display functions described herein. Multichannel streaming system <NUM> may also contain other conventionally-known components, which are not shown in <FIG> to avoid unnecessarily obscuring the drawing.

During a multichannel streaming session, streaming media server <NUM> transmits a prioritized streaming channel bundle <NUM> through communications network <NUM> to client media receiver <NUM>. The term "streaming channel bundle," as appearing herein, refers to a streaming data transmission containing multiple channels, regardless of the particular revenue model employed (if any) and regardless of whether certain channels in the bundle are provided in an interrupted manner or as a discontinuous component stream (as may occur for certain secondary channels in the bundle, as explained more fully below). In embodiments, streaming channel bundle <NUM> contains Over-The-Top (OTT) linear television (TV) programing. Streaming channel bundle <NUM> is "prioritized" in that varying priority levels or rankings are assigned to the streaming channels contained in bundle <NUM>. These priority levels may be assigned and repeatedly reassigned or adjusted by client media receiver <NUM> during a multichannel streaming session. In certain cases, streaming media server <NUM> may also adjust the priority levels assigned to the streaming channels contained in bundle <NUM>. Such a channel prioritization hierarchy is usefully referenced by streaming media server <NUM> in allocating available bandwidth between the streaming channels within bundle <NUM>. While only three streaming channels are schematically shown in <FIG>, prioritized streaming channel bundle <NUM> can contain any practical number of streaming channels greater than one. This is emphasized in <FIG> by the labeling of the lower most channel stream as "streaming channel n" and the ellipsis symbol vertically separating streaming channel n from streaming channel <NUM>.

With continued reference to <FIG>, streaming media server <NUM> can assume the form of any device, system, or component suitable for obtaining content from one or more content sources <NUM>, encoding the content utilizing one or more encoder modules <NUM> under the command one or more control modules <NUM>, and transmitting the encoded content to client media server <NUM> over communications network <NUM>. As generically shown in <FIG>, modules <NUM>, <NUM> can be implemented utilizing software, hardware, firmware, and combinations thereof. The encoded channel streams will often contain both video and audio component streams, which may be combined with other streaming data including packet identification data. Any currently-known or later-developed packetized format can be employed by streaming media sever <NUM> including, but not limited to, MPEG, QUICKTIME, WINDOWS MEDIA, and/or other formats suitable for transmission over communications network <NUM>. In one implementation, client media server <NUM> functions as an OTT server, which provides streaming channel bundle <NUM> to client media receiver <NUM> as a subscription-based streaming OTT linear TV service.

Generally, communications network <NUM> may encompass any number of digital or other networks enabling multiple nodes (e.g., devices <NUM>, <NUM>) to communicate using any common protocols and signaling schemes. Communications network <NUM> can include one or more open Content Delivery Networks (CDNs), Virtual Private Networks (VPNs), the Internet, and various other communications networks implemented in accordance with TCP/IP protocol architectures or other conventional protocols. In various embodiments, network <NUM> may further encompass one or more wired or wireless local area networks (LANs), wide area networks (WANs), cellular networks, and/or any other pubic or private networks. Communications network <NUM> as illustrated in <FIG>, then, is intended to broadly encompass any communications network(s), systems, or architectures for transmitting data between the various components of multichannel streaming system <NUM>.

Client media receiver <NUM> can be any device, system, player, or the like suitable for performing the processes described herein. A non-exhaustive list of such devices includes mobile phones, laptop computers, desktop computers, gaming consoles, tablets, Digital Video Recorders (DVRs), and Set-Top Boxes (STBs). When engaged in a multichannel streaming session, client media receiver <NUM> outputs visual signals for presentation on display device <NUM>. Display device <NUM> can be integrated into client media receiver <NUM> as a unitary system or electronic device. This may be the case when receiver <NUM> assumes the form of a mobile phone, tablet, laptop computer, or similar electronic device having a dedicated display screen. Alternatively, display device <NUM> can assume the form of an independent device, such as a freestanding monitor or television set, which is connected to client media receiver <NUM> (e.g., a gaming console, DVR, STB, or similar peripheral device) via a wired or wireless connection. Video output signals generated by client media receiver <NUM> may be formatted in accordance with conventionally-known standards, such as S-video, High-Definition Multimedia Interface (HDMI), Sony/Philips Display Interface Format (SPDIF), Digital Visual Interface (DVI), or IEEE <NUM> standards.

Client media receiver <NUM> may contain a processor <NUM> configured to selectively execute software instructions, in conjunction with associated memory <NUM> and conventional Input/Output (I/O) features <NUM>. I/O features <NUM> can include a network interface, an interface to mass storage, an interface to display device <NUM>, and/or various types of user input interfaces. Client media receiver <NUM> may execute a software program or application <NUM> directing the various hardware features of client media receiver <NUM> to perform the functions described herein. Application <NUM> suitably interfaces with processor <NUM>, memory <NUM>, and I/O features <NUM> via any conventional operating system <NUM> to provide such functionalities. Software application can be a placeshifting application in embodiments in which streaming media server <NUM> assumes the form of a STB, DVR, or similar electronic device having placeshifting capabilities and, in many cases, located within the residence of an end user. In certain implementations, client media receiver <NUM> may be realized utilizing special-purpose hardware or software, such as the SLINGCATCHER-brand products available from Sling Media, Inc. , presently located in Foster City, California.

As schematically shown in <FIG>, application <NUM> suitably includes control logic <NUM> adapted to process user input, obtain prioritized streaming channel bundle <NUM> from one or more content sources <NUM>, decode received streams, and supply corresponding output signals to display device <NUM>. The streaming channels contained in prioritized streaming channel bundle <NUM> are decoded utilizing known techniques. In implementations, each channel stream contained in bundle <NUM> may be simultaneously decoded by a separate decoding modules. The decoding module or modules may be implemented using specialized hardware or software executing on processor <NUM>. Decoded programming can be provided to a presentation module <NUM>, which then generates output signals to display device <NUM>. In some embodiments, presentation module <NUM> may combine decoded programming from multiple streaming channels to create a blended or composite image; e.g., as schematically indicated in <FIG>, one or more PIP images <NUM> may be superimposed over a main or primary image generated on a screen of display device <NUM>.

In operation, control logic <NUM> of client media receiver <NUM> obtains programming in response to end user inputs received at I/O features <NUM> of receiver <NUM>. Control logic <NUM> may establish a control connection with remote streaming media server <NUM> via communications network <NUM> enabling the transmission of commands from control logic <NUM> to control module <NUM>. Streaming media server <NUM> may operate by responding to commands received from a client media receiver <NUM> via network <NUM>, as indicated in <FIG> by arrow <NUM>. Such commands may include information utilized to initiate a multichannel streaming session with streaming media server <NUM> possibly including data supporting mutual authentication of server <NUM> and receiver <NUM>. When streaming media server <NUM> assumes the form of a consumer placeshifting device, such as a STB or DVR located in an end user's residence, control commands <NUM> may include instructions to remotely operate the placeshifting device. Control commands <NUM> may also contain channel reprioritization commands selectively transmitted from client media receiver <NUM> to streaming media server <NUM> during a prioritized multichannel streaming session, as described more fully below in conjunction with <FIG>.

<FIG> is a message timing diagram of a multichannel streaming process <NUM> illustrated in accordance with an exemplary embodiment of the present disclosure. Exemplary process <NUM> may be carried-out by streaming media server <NUM> and client media receiver <NUM> during a prioritized multichannel streaming session to provide a temporally-seamless channel change experience to an end user. Process <NUM> commences with receipt of user input requesting initialization of a multichannel streaming session (FUNCTION <NUM>, <FIG>). Such a user request can be entered by an end user into client media receiver <NUM> utilizing a user input interface (e.g., a keyboard, pointer device, touchscreen, scroll wheel, voice command system, remote control, etc.) included within I/O features <NUM> (<FIG>) or otherwise operably coupled to media receiver <NUM>. Client media receiver <NUM> recognizes this user request and transmits a corresponding command to initiate a multichannel streaming session to streaming media server <NUM> (TRANSMISSION <NUM>, <FIG>). This command may include information identifying an initial channel priority setting or hierarchy assignment, which client media receiver <NUM> may recall from memory <NUM> (<FIG>). One way or two way authentication processes can also be performed, as desired.

The prioritization of the streaming channels contained in bundle <NUM> may be determined by client media receiver <NUM> and communicated to streaming media server <NUM> via the initial streaming channel priority setting included in TRANSMISSION <NUM> (<FIG>) and subsequent channel reprioritization commands as contained in below-described TRANSMISSION <NUM> (<FIG>). Streaming media server <NUM> may also be permitted to adjust the streaming channel priority ranking in embodiments, although any such adjustments by server <NUM> will typically be subservient to channel priority ranking commands received from client media receiver <NUM>. Client media receiver <NUM> may assign the highest priority level to a streaming channel initially presented to the end user in an embodiment. In the absence of user input specifying a particular channel with which to begin the newly-initiated multichannel streaming session, client media receiver <NUM> may assign the highest priority level to the channel last presented to the end user during the previous multichannel streaming session.

In certain implementations, a two tier hierarchy may be employed in prioritizing the streaming channels such that the primary streaming channel is assigned the highest priority ranking, while the secondary streaming channels are assigned a lower priority ranking. In other embodiments, the priority hierarchy may contain more than two tiers such that one or more additional channels may be assigned a moderate priority level based upon any number of specified criteria. Such criteria may be based upon the content of the secondary streaming channels; e.g., whether the additional channels currently provide coverage of live events and/or the relatedness of the additional channels to the content currently presented on the primary streaming channel. Additionally or alternatively, the predicted likelihood of the end user requesting a channel change to the secondary channels may be considered; e.g., based upon a user profile created from past viewing habits and/or user input specifying preferences. As a first example, the primary streaming channel may be assigned the highest priority ranking, those channels frequently viewed by the end user may be assigned a moderate priority ranking, and all other channels included in streaming channel bundle <NUM> may be assigned a lower priority ranking. In other embodiments, those channels featuring live events, such as live sporting events, breaking news, or a live broadcast of a presidential address, may be assigned a moderate or intermediate priority level. As still further possibility, those channels immediately above or below the primary streaming channel by channel number, and thus more likely to be selected by a user when sequentially scrolling through the streaming channels contained in bundle <NUM>, may be assigned a moderate priority level. Various other approaches can also be utilized.

In response to streaming session initialization, streaming media server <NUM> transmits streaming channel bundle <NUM> (<FIG>) to client media receiver <NUM> over communications network <NUM> (TRANSMISSION <NUM>, <FIG>). Streaming media server <NUM> may encrypt streaming channel bundle <NUM> in its entirety, encrypt selected channels in bundle <NUM>, or may not employ encryption. As previously noted, prioritized streaming channel bundle <NUM> contains at least one channel identified as a primary streaming channel (e.g., the streaming channel viewed by the end user over a current or recent time period in a non-transitory manner) and any number of additional channels identified as secondary streaming channels. Depending upon bandwidth constraints and other such factors, the secondary streaming channels (and, in certain circumstances, the primary streaming channel) may be provided at lower quality levels (e.g., lower frame rates and/or image resolutions) and/or provided intermittently, as described below in conjunction with <FIG>. Upon or immediately after initial reception of prioritized stream channel bundle <NUM>, client media receiver <NUM> performs the appropriate process tasks (e.g., decoding and decryption) and outputs signals corresponding to primary streaming channel to display device <NUM> for presentation to the end user (FUNCTION <NUM>, <FIG>). The end user may then view the primary streaming channel on the screen of display device <NUM> (ACTION <NUM>, <FIG>).

Client media receiver <NUM> continually monitors for channel change requests during the multichannel streaming session (FUNCTION <NUM>, <FIG>). Client media receiver <NUM> may also record and repeatedly rerecord segments of one, a subset of, or possibly all secondary channels contained in prioritized streaming channel bundle <NUM> (<FIG>). The recorded segments may be stored in memory <NUM> as cached clippings of the relevant channels. The recorded segments may be referred to as "rolling recorded segments" or having "rolling start times" as each segment is updated on a repeated basis utilizing recently received content from each streaming channel extending into the past by a predetermined or set duration, which may be several seconds to several minutes from the time of live streaming (TLS, described below). The duration of the rolling recorded segments may vary among implementations and may be tailored to suit a particular application based upon, for example, storage capacity and availability, client or server response time, the length of the below-described channel change wait period, and other such factors. The duration of the recorded segments may be fixed or may be varied by client media receiver <NUM> in accordance with changes in one or more monitored parameters, such as network latency. For example, client media receiver <NUM> may shorten the duration of the recorded segments in conjunction with decreasing network latencies, decreasing memory availability (as may occur as receiver storage capacity becomes increasingly filled), and/or other such factors.

When receiving a user channel change request for a streaming channel for a which live stream is not presently available, client media receiver <NUM> may present the corresponding recorded rolling segments or cached clips to the end user. This provides the end user with content from the requested streaming channel, while a live stream of the newly-requested channel is obtained from streaming media server <NUM> (absent receipt of a further user channel change request within the below-described channel change wait period). In effect, a tradeoff is leveraged, which introduces a modest time-shift or delay in the time position at which content from the newly-requested streaming channel is presented, as measured relative to the time of live streaming (TLS). Through this tradeoff, a non-interrupted or continuous viewing experience is provided in a multichannel streaming environment, while accommodating channel change requests for streaming channels for which live streams are not immediately available to client media receiver <NUM>.

When a user channel change request is received at client media receiver <NUM> (ACTION <NUM>, <FIG>), client media receiver <NUM> outputs the newly-requested streaming channel to display device <NUM> accordingly (FUNCTION <NUM>, <FIG>). As previously indicated, client media receiver <NUM> may present a live stream of the newly-requested streaming channel if such a live stream is currently provided to media receiver <NUM> as part of prioritized streaming channel bundle <NUM>. Alternatively, client media receiver <NUM> may present the recorded segment of the newly-requested streaming channel if a live stream of the channel is not currently available. In either event, content from the newly-requested streaming channel is outputted to display device <NUM> and thus presented for immediate viewing by the end user (ACTION <NUM>, <FIG>).

Immediately following or concurrently with FUNCTION <NUM> (<FIG>), client media receiver <NUM> begins monitoring for the receipt of additional channel change commands over the channel change wait period. The channel change wait period is essentially an assuredness mechanism utilized to determine with a higher confidence level that a given streaming channel is likely to be selected or settled upon by the end user for prolonged viewing. For a given iteration, countdown of the channel change wait period commences upon receipt the last channel change request received form the end user (FUNCTION <NUM>, <FIG>). If an additional channel change request is received within the channel change wait period, client media receiver <NUM> returns to FUNCTIONS <NUM>, <NUM>, as described above; receiver <NUM> outputs the newly-requested streaming channel and recommences monitoring for further channel change requests for a new iteration of the channel change wait period. The generation of excessive channel change requests or reprioritization commands by client media receiver <NUM> is consequently minimized, if not largely eliminated. In certain embodiments, the channel change wait period may have a fixed value on the order of, for example, <NUM> to <NUM> seconds. In other embodiments, the channel change wait period may be dynamic and adjusted based upon one or more parameters, such as past end user behavior when channel browsing during previously multichannel streaming sessions.

If an additional channel change request is not received within the channel change wait period, client media receiver <NUM> transmits a channel reprioritization command to streaming media server (TRANSMISSION <NUM>, <FIG>). The channel reprioritization command may identify the streaming channel last requested by the end user (and typically currently presented on display device <NUM> (<FIG>)) as the primary streaming channel, which is then assigned the highest priority ranking. The channel change reprioritization command may contain information identify the current priority ranking to each of the streaming channels contained within bundle <NUM>, as assigned by receiver <NUM>. Any historical gap fill segment, as required to ensure continuity in the presentation of content from a requested streaming channel, may also be requested in conjunction with the channel reprioritization command. Additional description in this regard is provided below conjunction with <FIG>. The prioritization ranking of the secondary streaming channels may also be adjusted at this juncture. For example, if the newly-selected primary streaming channel is presently covering a sporting event (e.g., a particular college basketball game), the secondary streaming channels depicting other similar sporting events (e.g., other concurrently-broadcast college basketball games) may be assigned a moderate or high priority level by client media receiver <NUM> as part of transmission <NUM> or, perhaps, by streaming media server <NUM> when receiving transmission <NUM>. Streaming media server <NUM> then continues transmission of streaming channel bundle <NUM> (<FIG>) in accordance with the newly-received reprioritization instructions (TRANSMISSION <NUM>, <FIG>).

In some embodiments, client media receiver <NUM> may provide additional functionalities during process <NUM>, as indicated in <FIG> at FUNCTION <NUM>. Such other functions may include the ability to advance to the live streaming when time position of a streaming channel is delayed relative to the time of live streaming due to presentation of stored video segments to the end user in the absence of a live stream. An example of such a jump-to-live function is described below in conjunction with <FIG>. Additionally or alternatively, client media receiver <NUM> may permit an end user to transition from live multichannel streaming to VOD viewing in certain instances. For example, client media receiver <NUM> may automatically (that is, without requiring additional user input) download additional episodes of a series presently viewed by the end user. Client media receiver <NUM> may provide user prompts through an on-screen Graphical User Interface (GUI) and adjust the video output, as appropriate, to carry-out such additional features (ACTION <NUM>). Afterwards, client media receiver <NUM> determines whether the current streaming session should continue (FUNCTION <NUM>, <FIG>). If determining that the current streaming session should be continued, client media receiver <NUM> returns to FUNCTION <NUM> and the above-described process repeats. If, instead, determining that the current streaming session should conclude, client media receiver <NUM> progresses to FUNCTION <NUM> and terminates the current multichannel streaming session.

Turning now to <FIG>, several exemplary scenarios are depicted in which client media receiver <NUM> selectively implements user channel change requests and transmits corresponding channel reprioritization commands to streaming media server <NUM>. For consistency with <FIG>, client media receiver <NUM> is illustrated as receiving three content streams corresponding to channels <NUM>, <NUM>, and n, as generically represented by graphics <NUM>, <NUM>, and <NUM>, respectively. However, as previously indicated, any number of streaming channels can be contained in streaming channel bundle <NUM>. The horizontal axis in <FIG> represents a time frame encompassing the time position of live streaming or "TLS" (that is, the time position at which the streaming programming appears when presented in real time as received by client media receiver <NUM>), as well as the rolling start time for any recorded segments (TRS_S). The rolling end time position for the recorded segments will typically be concurrent with TLS; it is, however, possible for the end time for one or more of the recorded segments to extend into the future beyond TLS when such future content is available. In this regard, and as indicated in <FIG>, future content (that is, content extending forward in time relative to TLS) may be available for one or more of the secondary streaming channels when the content presented on such channels has previously been created and is accessible by receiver <NUM>; e.g., as may be the case when the streamed content is preexisting movie, an episode of an ongoing series, or other such content. Finally, as appearing at multiple locations in <FIG>, graphic <NUM> indicates the time position of the streaming channel currently outputted by client media receiver <NUM> to display device <NUM>.

With initial reference to <FIG>, a first exemplary scenario is presented under idealized bandwidth conditions in which all applicable streaming channels are received continuously, concurrently, and at optimal quality. Addressing specifically <FIG>, the exemplary scenario is depicted prior to receipt of a user channel change request by client media receiver <NUM>. As indicated by the positioning of graphic <NUM>, client media receiver <NUM> presently outputs a live stream of streaming channel <NUM>, which is identified as the primary streaming channel assigned the highest priority level in this example. Under such conditions, client media receiver <NUM> implements user channel change requests by altering the output signal to display device <NUM> to depict any newly-selected channel stream at essentially the same time as the channel change request is received at receiver <NUM>. This may be appreciated by comparing <FIG>, which further illustrates the first exemplary scenario after receipt of a user request to change to presentation of streaming channel <NUM>. As streaming channel <NUM> is immediately available at an optimal quality to client media receiver <NUM> as part of streaming channel bundle <NUM> (<FIG>), client media receiver <NUM> need only alter the output signal provided to display device <NUM> (<FIG>) to now depict the second channel stream, as indicated in <FIG> by the repositioning of graphic <NUM>.

In the scenario of <FIG> in which all applicable streaming channels are received concurrently, continuously, and at optimal quality, client media receiver <NUM> may function essentially as does a STB in a cable or satellite distribution system. However, the persistence of such idealized conditions under real world conditions cannot be ensured, particularly when streaming channel bundle <NUM> (<FIG>) contains a relatively large number of channels. Thus, concurrent with changing the video output signal to streaming channel <NUM>, client media receiver <NUM> may perform FUNCTION <NUM>, as described above in conjunction with <FIG>, and await additional channel change requests over the predetermined time threshold or channel change wait period. If no such channel change requests are received over this period, client media receiver <NUM> may then transmit a channel reprioritization command to streaming media server <NUM> indicating that streaming channel <NUM> should now be assigned the highest priority ranking as the newly-selected primary streaming channel. Additional changes in the priority rankings of the other streaming channels contained in streaming channel bundle <NUM> (<FIG>) may also be adjusted; e.g., streaming channel <NUM> may be assigned a low or moderate priority level, as appropriate. In this manner, streaming media server <NUM> may reduce the quality of streaming channel <NUM> and the other secondary streaming channels in lieu of any degradation to the quality of streaming channel <NUM> should bandwidth constraints arise during continued transmission of streaming channel bundle <NUM>.

Advancing to <FIG>, a second exemplary scenario is illustrated in which all applicable channels are received continuously, concurrently, and with varied quality levels. At this juncture of the exemplary scenario, a user channel change request has not yet been received at client media receiver <NUM>. Streaming media server <NUM> encodes and transmits the primary streaming channel (here, streaming channel <NUM>) in optimal quality, while providing some or all secondary streams (here, streaming channels <NUM>-n) in sub-optimal quality; e.g., at a lower frame rate and/or image resolution to bring about a controlled reduction in the bitrate of the streamed content. As appearing herein, the term "sub-optimal quality" is utilized in a relative sense to denote some degree of intentional quality degradation relative to the optimal quality in which the streaming channels may otherwise be encoded and transmitted. Streaming channels provided in sub-optimal quality may thus still be perceived by an end user to be of relatively high visual quality and may different only modesty in image resolution, frame rate, and other such quality measurements.

<FIG> illustrates the same exemplary scenario as does <FIG>, but after receipt and implementation of a channel change request by client media receiver <NUM>. The user channel change request indicates that a user desired to view streaming content from channel <NUM>. Accordingly, as indicated by the repositioning of graphic <NUM>, client media receiver <NUM> transitions to outputting streaming channel <NUM> to display device <NUM> (<FIG>). As the streaming channel <NUM> is continuously provided over the relevant time period, a delay has not been introduced between the present time position of content outputted to display device <NUM> and TLS. Client media receiver <NUM> further transmits a channel reprioritization command to streaming media server <NUM> (<FIG>) indicating that streaming channel <NUM> is now properly identified as the primary streaming channel after elapse of the above-described channel change wait period, providing no other channel change requests are received within the wait period. Streaming media server <NUM> responds to the channel reprioritization command by prioritizing streaming channel <NUM> over streaming channel <NUM> and the other streamed secondary in continued transmission of bundle <NUM>. Accordingly, streaming media server <NUM> will reduce the quality (and, perhaps, interrupt transmission of the secondary channels including streaming channel <NUM>) before reducing the quality of the primary streaming channel (streaming channel <NUM>) should bandwidth constraints arise necessitating such actions.

Streaming media server <NUM> performs appropriate adjustments encoding and transmission of streaming channel bundle <NUM> in response to receipt of the channel reprioritization command. For example, under the bandwidth constrained conditions of <FIG>, streaming media server <NUM> may transition from encoding and transmitting streaming channel <NUM> in optimal quality (as indicated by a first cross-hatch pattern for segment <NUM>(a) of streaming channel <NUM>) to providing streaming channel <NUM> in sub-optimal quality (as indicated by a second cross-hatch pattern for segment <NUM>(b) of streaming channel <NUM>). At essentially the same time, streaming media server <NUM> may also transition from encoding and transmitting streaming channel <NUM> in sub-optimal quality (as indicated by the first cross-hatch pattern for segment <NUM>(a)) to now providing streaming channel <NUM> in optimal quality (as indicated by the second cross-hatch pattern for segment <NUM> (b)). An analogous process can be performed if the user channel change request indicates that a different streaming channel, such as streaming channel n, is desirably presented on display device <NUM> (<FIG>).

Turning lastly to <FIG>, a third exemplary scenario is presented in which streaming media sever <NUM> is prevented (e.g., due to bandwidth constraints) from encoding and transmitting all channels within streaming channel bundle <NUM> simultaneously, continuously, and at optimal quality levels. Under such conditions, streaming media server <NUM> may transmit selected secondary streams in an intermittent or non-continuous manner, whether at an optimal or sub-optimal quality level (represented by a third cross-hatch pattern in <FIG>). In one embodiment wherein channel <NUM> is the primary stream, streaming media server <NUM> provides the secondary channels (e.g., channel <NUM> and channel n in <FIG>) at an optimal quality level, but as a number of temporally-staggered segments. Client media receiver <NUM> may thus receive the primary streaming channel assigned the high priority ranking as a continual stream over a period of time, while concurrently receiving the plurality of other streaming channels assigned lower priority rankings as discontinuous streams over the period of time. In this manner, the overall bitrate of streaming channel bundle <NUM> can be lowered, while the end viewer may still be presented with any selected channel in optimal quality during channel browsing. Prior to the below-described channel change request, client media receiver <NUM> may output streaming channel <NUM> to display device <NUM> (<FIG>) at an optimal quality and at a time position concurrent with TLS.

With reference to <FIG>, the illustrated scenario is depicted after entry of a user channel change request into client media receiver <NUM>, but prior to reception of current streaming content corresponding to the newly-requested streaming channel. To avoid any discontinuity in presenting content to the viewer obtained from the newly-requested streaming channel to the end user, client media receiver <NUM> recalls the recently-recorded segment of the newly-requested streaming channel (in this example, streaming channel <NUM>) from memory and outputs this streaming channel to display device <NUM>. A delay or temporal lag in the time position of the content for streaming channel <NUM> is thus introduced relative to TLS; however, the end user may be unaware of this time delay when browsing through the streaming channels and only temporarily viewing streaming channel <NUM> (and any other such channels through which the end user quickly browses) on a transitory basis. If, however, the end user does not issue further channel change requests prior to elapse of the above-described channel change wait period, client media receiver <NUM> may perform additional actions, as discussed in conjunction with <FIG>.

<FIG> illustrates the third exemplary scenario at an instance or juncture following (e.g., several seconds after) the scenario of <FIG>. As additional user channel change requests have not been received, client media receiver <NUM> transmits a channel reprioritization command to streaming media server <NUM> indicating that streaming channel <NUM> should now be assigned the highest priority ranking as the newly-selected primary stream. Correspondingly, streaming media server <NUM> updates streaming multichannel bundle <NUM> to contain streaming channel <NUM> as a continuous stream provided in optimal quality, absent sever bandwidth constraints. This is indicated in <FIG> by segments <NUM>(b)-(c) of streaming channel <NUM>. Client media receiver <NUM> has further requested, and streaming media server <NUM> has supplied, a historical gap fill segment <NUM>(b) corresponding to streaming channel <NUM>. This historical gap fill segment <NUM>(b) is appended or joined to the end of the recorded segment of streaming channel <NUM> to ensure that continuity in the presentation of content from streaming channel <NUM>. Content from the newly-selected streaming channel (channel <NUM>) can thus be presented immediately upon user request, with the quality of the newly-selected streaming channel elevated at the earliest opportunity. As a corollary, a slight delay is introduced to the time position of the presented content, as indicated in <FIG> by the positioning of graphic <NUM>. If desired, the end user may be presented with an option to progress the time position of the presented content to the time of live stream (TLS), as indicated graphic <NUM>. Such a "jump-to-live" option may be presented at any desired time and by, for example, visual prompts overlaid onto the video stream outputted to display device <NUM> (<FIG>). Should the end user select this option, client media receiver <NUM> may then advance to the time of live streaming (TLS), as indicated in <FIG>.

There has thus been provided devices, systems, method, and program products enabling temporally-seamless change functionalities during multichannel (e.g., OTT linear TV) streaming sessions established between a streaming media server and a client media receiver. The foregoing processes can be implemented utilizing program products or software applications installed on and executed by an electronic device functioning as the client media receiver, such as a user-operated mobile phone. In certain embodiments, the streaming media server may be a STB located in a residence of an end user, in which case commands may be transmitted from the client media receiver to the set-top box to enable placeshifting of the prioritized streaming channel bundle for viewing at the client media receiver. Embodiments of the devices, systems, method, and program products may also favorably reduce the generation of unwarranted channel change request when an end user engages in prolonged channel browsing or channel surfing behaviors during a multichannel streaming session.

Claim 1:
A method carried-out by a client media receiver (<NUM>), comprising:
receiving, at the client media receiver (<NUM>), a prioritized streaming channel bundle (<NUM>) transmitted over a communications network (<NUM>) by a streaming media server (<NUM>), the prioritized streaming channel bundle comprising a plurality of streaming channels (<NUM>, <NUM>, <NUM>) having varying priority levels assigned to each one of the streaming channels, wherein the priority levels are used by the streaming media server for bandwidth allocation purposes;
outputting, to a display device (<NUM>) associated with the client media receiver (<NUM>), a first streaming channel (<NUM>) contained in the prioritized streaming channel bundle (<NUM>);
receiving, at the client media receiver (<NUM>), a user channel change request (<NUM>) to view a second streaming channel (<NUM>) contained in the prioritized streaming channel bundle;
outputting, to the display device, the second streaming channel that is contained in the prioritized streaming channel bundle for immediate viewing;
monitoring, at the client media receiver (<NUM>), for an additional channel change request within a predetermined wait period commencing upon receipt of the user channel change request; and
if an additional user channel change request is received within the predetermined wait period, outputting, to the display device (<NUM>), the newly-requested streaming channel from the prioritized streaming channel bundle (<NUM>), if it is available, and repeating the step of monitoring, and if an additional user channel change request is not received within the predetermined wait period, transmitting a channel reprioritization command (<NUM>) to the streaming media server (<NUM>) to prioritize the streaming channel last requested by the user over the first streaming channel (<NUM>) in continued transmission of the prioritized streaming channel bundle.