Patent Description:
The article entitled <NPL>, describes a context manager to resolve conflicts for context-aware media services in smart home environments.

<CIT> is directed at systems and methods for automatically identifying user sessions (involving a user different to the user associated with a given device) utilizing demographics associated with a device identifier in comparison to demographics associated with requested content (e.g. video, website, etc.).

<CIT> describes a method to ascribe a network activity on a given device used by several users to a given user.

The invention is defined in independent claims <NUM>, <NUM> and <NUM>. Some further features are recited in the dependent claims. The wide availability and selection of digital content, combined with the large number of electronic devices available for its playback, mean that consumers may select and play desired content on several different screens. This allows users great flexibility in where and how they may view their content. Contemporary users can even elect to stream differing content on multiple devices simultaneously. For example, a user may discover interesting content on a laptop or tablet while listening to a podcast on his or her phone. Alternatively, users may wish to listen to background music while reading an e-book or articles online.

The ability to consume multiple different content streams concurrently is not without its difficulties, however. In particular, devices currently leave it to users to resolve their own conflicts, which can lead to excessive work and frustration. For instance, when users discover other content while listening to a podcast, they often want to pause the podcast while viewing the new content. In this manner, they can pick up on the podcast once they are finished with the new content. However, users currently must pause the podcast themselves. The need to manually implement content settings when multiple content streams are playing is, as above, a source of user frustration.

Accordingly, to overcome the problems and limitations of such services and their interfaces, systems and methods are described herein for a computer-based process that automatically determines when an individual is playing or requesting content playback on two different devices, determines whether the two content streams present a conflict, and if so, resolves the conflict. Conflict resolution may be performed by, for instance, pausing or muting one of the content streams. More specifically, a system automatically determines when a single user is requesting playback of content on two different devices, and determines whether the two content streams present a conflict. If so, the conflict is automatically resolved. For example, if the system determines that a single user is listening to a podcast on one device and decides to read an e-book on another device, the system recognizes that no conflict likely exists, as people can often read and listen simultaneously. However, if the system determines that the same user instead initiates a Ted Talk® video on laptop, a conflict is deemed to occur, as people typically cannot pay full attention to each of two simultaneous audio tracks containing speech. Accordingly, the podcast is automatically paused. Other examples exist and are further explained below.

In more detail, a list of users is maintained, and the system determines when a single user on the list is both playing a first content stream on one device and requests a second content stream on another device. If so, the system then determines whether the two content streams conflict. If no conflict is deemed to be present, both content streams are transmitted to the user. Conversely, if a conflict is deemed to occur, this conflict is resolved by pausing or redirecting one of the content streams.

The system does not require users to explicitly identify themselves when they are requesting content. Rather, the system automatically identifies the user associated with each requested content stream. Various methods may be employed to identify users. In one such method, information is stored associating each device with particular users and their user profiles. For example, the system can store a user identifier for each different user, a device identifier associated with each content playback device and with one or more user identifiers, account identifiers for user accounts of content applications (e.g., user Netflix® accounts), and user profiles for each user or user identifier.

This stored information may be used to identify users of each device. For instance, the device identifier associated with a device currently requesting content can be determined. If only one user identifier is associated with this device identifier, it may be deemed that the user corresponding to that user identifier is the one currently utilizing the device. Alternatively, if more than one user identifier is associated with the current device identifier, the correct user identifier may be determined according to a comparison of the content currently being requested to the user profiles of the various users associated with the current device identifier. That is, if more than one user identifier is associated with the current device identifier, the user profiles corresponding to each of these user identifiers are examined to determine which compares most closely to the content currently being requested. The user whose profile most closely lines up with the current content is deemed to be the current user.

Various embodiments also contemplate use of any other approach for determining the identity of a user from content being requested and/or the device it is requested on. The above approaches, and any others, may be used to determine the identity of the user of any device. That is, when content is requested on two different devices, the above and other methods may be employed for each device, to separately determine the identity of each device's user. If the determined users of the two devices are the same, then it is also determined that the same user is requesting simultaneous playback of two different content streams on two different devices.

In one embodiment, a check is first performed to determine whether the content requested is the type of content that the identified user would typically request. If not, then it is deemed that a different user is requesting content. That is, a first user requesting content on a first device is identified. When content is requested on a second device, and it is initially determined that the same user is requesting content on both devices, a check is performed to verify that the same user is requesting content on the second device. This check is performed by comparison to the user profile of the identified user. As one example, the account identifier associated with the request for content on the second device can be determined, as can the user identifier associated with this account identifier. The corresponding user profile is then determined, and the content requested on the second device is compared to the user profile, to determine whether the content matches a content profile listed in the user profile, i.e., a description of the content that the user prefers. If the content matches that listed in the user profile, i.e., the content matches that which the user prefers, then it is confirmed that the user of the second device is the same as that of the first device. Conversely, if the content does not match the user profile, then it is deemed that a different user is requesting content on the second device, and thus no conflict exists.

Once it is confirmed that the same user is streaming content on two different devices, the presence or absence of a conflict is determined. To assist in conflict determination, an audio/video type identifier is stored for each device identifier, where the audio/video type identifier is an indicator of the type of content the device is currently playing. Accordingly, the type identifier can be one of audio only, video only, and audio and video. The type of content playing on a device is then determined, and the type identifier for that device is set accordingly. In this manner, conflict can be determined by examination of the type identifiers currently set for two devices. When the audio/video type identifier of the first device is the same as that of the second device, i.e., each device on which content is requested has the same user and the same type identifier, it is determined that a conflict exists. That is, if each device has its type identifier set to audio only, or each is set to video only, or each is set to audio and video, then the two content streams are deemed to interfere with each other, representing a conflict. For example, two audio only streams, such as two simultaneous podcasts, would be difficult for a single user to listen to, and are thus deemed to conflict. Likewise, two video-and-audio streams, such as two movies, would present the same difficulty and would also be deemed to conflict.

One way of resolving such a conflict involves a secondary audio or video output. That is, conflicts between content streams can be resolved by providing another audio or video output to which one of the conflicting audio/video streams can be directed. Once an audio conflict is determined, and if a secondary audio output is available, the audio signal of the first content stream, or the audio of the first device, is directed to the secondary audio output. If no secondary audio output is available, audio of the first device can be halted (first device muted) while its video stream continues. Thus, for example, if a user is listening to streaming music on headphones, and starts a podcast on another device, the music is redirected to a less intrusive audio output such as room speakers. Meanwhile, the podcast can play on the second device, or be directed through the headphones connected to the first device. Similarly, once a video conflict is determined, and if a secondary video output is available, the video signal of the first content stream, i.e., the video of the first device, is directed to the secondary video output. If no such secondary video output is available, video of the first device can be halted while its audio stream continues.

Another approach to conflict resolution involves use of a state flag that designates a particular device or content stream as having audio priority in a conflict. More specifically, when two conflicting content streams are requested, and one is flagged as having the audio priority state, the flagged audio stream is played and the unflagged stream is paused or muted. Thus, it is determined when a single user is playing a first content stream on a first device and concurrently requests playback of a second content stream on a second device. When this is determined to occur, and when one of the devices/streams is flagged as having this audio priority state while the other is not, both audio and video of the flagged device/stream are played, while only the video and not the audio of the unflagged device/stream is played. This state may be referred to as a "conditional audio enabled" state. Thus, in a conflict, the conditional audio enabled device or stream would have both its audio and video played, while the conflicting device or stream would have only its video played.

Either devices or content streams can be flagged conditional audio enabled. That is, any of the above described first device, second device, first content stream, and second content stream can be labeled or flagged as conditional audio enabled.

The conditional audio enabled flag can be used to resolve conflicts in multiple different ways. As one example, if both devices, or both content streams, are flagged conditional audio enabled, and the two streams are deemed as conflicting, the conflict can be resolved by pausing playback of the first content stream on the first device while playing back the content stream on the second device. That is, in a conflict between two conditional audio enabled devices or streams, the later device/stream is played while the earlier one is paused. As another example, if both devices or both streams are flagged conditional audio enabled as above, but the first stream is paused before the second stream is requested, the second stream is played while the first stream is kept as paused. Conversely, if neither device and neither stream is flagged as conditional audio enabled, the first content stream is paused while the second stream is played back. That is, when no device or content stream is flagged as conditional audio enabled, conflicts are resolved by prioritizing the second device/stream over the first.

As still another example, if the first device or content stream is flagged as conditional audio enabled but the second device or stream is not, and the first device is playing the video but not the audio of its content stream, the conflict is resolved by pausing video of the first content stream, playing the audio of the first content stream, and playing the video but not the audio of the second content stream. That is, conflict is resolved by playing the audio of the first stream, and video of the second stream. In another similar example, if the first device or stream is flagged as conditional audio enabled but the second device/stream is not, the second device is playing video but not audio, and the first stream is paused, the second stream is played in whole (audio and video). That is, if the user pauses the first stream, both audio and video of the second stream are played, as no conflict exists anymore.

If a device is playing audio only, or if a content stream is an audio only stream such as a podcast, the device or stream can be designated conditional audio enabled. As the device/stream plays only audio, its audio should be given priority.

In one embodiment, the disclosure relates to systems and methods for automatically determining when a single party is playing or requesting conflicting content on two different devices, and resolving the conflict accordingly. Users that play back a content stream on one device, then request another content stream on another device are identified. If it is determined that the same user is requesting or playing back both content streams on both devices, a determination is made whether the two content streams conflict. If so, the conflict is automatically resolved in a number of ways, including by automatically pausing or redirecting one of the content streams.

Conflict identification may be carried out with the assistance of an added state flag that can be applied to either devices or content streams. This flag, which can be referred to as a "conditional audio enabled" flag, indicates a device or stream that has audio priority in a conflict. Thus, as an example, when one user requests two conflicting content streams, and only one stream is associated with the conditional audio enabled flag, the flagged stream plays at least its audio, while the other stream is muted.

<FIG> illustrates an exemplary system for detecting and resolving conflicts when a user simultaneously requests content on different devices, in accordance with embodiments of the disclosure. Here, system <NUM> includes a first content consumption device <NUM> and a second content consumption device <NUM> both being used by the user shown. First and second content consumption devices <NUM>, <NUM> each communicate with content direction device <NUM>, which receives and forwards content streamed from content providers <NUM>. In other words, content direction device <NUM> receives content from content providers <NUM> and transmits it on to the content consumption devices <NUM>, <NUM> currently used by a user.

In operation of system <NUM>, a user may be, for example, listening to a podcast on first content consumption device <NUM>, which may be his or her phone. The podcast is streamed from the leftmost content provider <NUM> to content direction device <NUM>, which in turn transmits the stream to the user's phone. While listening to the podcast, the user also requests content on second content consumption device <NUM>, which may be his or her TV, or alternatively may be a laptop or tablet computer. The user may request, for example, a Netflix® show on device <NUM>. In response, the content direction device <NUM> automatically determines whether the user of device <NUM> is the same user as that of device <NUM>. If not, i.e. content is being requested by two different users, the content direction device <NUM> finds that no conflict is occurring, and transmits two content streams from the respective content providers <NUM> to the devices <NUM> and <NUM>. Conversely, if device <NUM> determines that the same user is the one requesting content on both devices <NUM> and <NUM>, the device <NUM> then determines whether the two content streams, i.e. a podcast and a Netflix® show, present a conflict. As both streams include audio, a conflict likely occurs, as the user would be forced to listen to two different sources of dialog at the same time, which is often difficult. In this case, the content direction device <NUM> automatically resolves the conflict. Resolution of conflicts can be performed in any number of different ways. For example, content direction device <NUM> may pause one of the streams, mute one of the streams, or direct the audio of one stream to a different audio output device not shown.

<FIG> is a block diagram representation of the system of <FIG>, presented for further illustration. Any number of content consumption devices <NUM> and <NUM> may be in communication with content direction device <NUM> through, for example, a local area network <NUM>. The content direction device <NUM> is in electronic communication with content provider <NUM> through communications network <NUM>. As one example, the content consumption devices <NUM> and <NUM>, local area network <NUM>, and content direction device <NUM> may all be situated within a local area, e.g., within various rooms of a home or office. The content provider <NUM> may be a remotely located server at a content provider site, and the communications network <NUM> may be the public Internet. Alternatively, the content provider <NUM> may be situated within the local area and may be, for example, a local content storage and streaming application on a local computer including any of the above computing devices, or even a storage and application within the content direction device <NUM> itself. As in <FIG>, multiple content providers <NUM> may be in communication with content direction device <NUM> through communications network <NUM>.

As above, a user may be watching a show on first content consumption device <NUM>, at which point the content provider <NUM> is providing a stream of the show through communications network <NUM> to content direction device <NUM>. The content direction device <NUM> in turn receives this stream and directs it to device <NUM> over local area network <NUM>. When the user requests another show or other stream on one of the second content consumption devices <NUM>, the content direction device <NUM> verifies that the same user is the one requesting content on both devices <NUM> and <NUM>. Upon verification that it is the same user, the content direction device <NUM> determines whether the two streams conflict and, if so, resolves the conflict. As above, resolution of the conflict can be performed in different ways, including pausing the stream directed to device <NUM>, pausing the stream directed to device <NUM>, directing the audio stream of the first device <NUM> to another device, or the like.

The content consumption devices <NUM>, <NUM> may be any devices capable of receiving streamed content and executing playback for users. For example, content consumption devices <NUM>, <NUM> may be digital TVs, laptop computers, smartphones, tablet computers, or the like. <FIG> shows a generalized embodiment of an illustrative user equipment device <NUM> that may serve as a content consumption device. User equipment device <NUM> may receive content and data via input/output (hereinafter "I/O") path <NUM>. I/O path <NUM> may provide content (e.g., broadcast programming, on-demand programming, Internet content, content available over a local area network (LAN) or wide area network (WAN), and/or other content) and data to control circuitry <NUM>, which includes processing circuitry <NUM> and storage <NUM>. Control circuitry <NUM> may be used to send and receive commands, requests, and other suitable data using I/O path <NUM>. I/O path <NUM> may connect control circuitry <NUM> (and specifically processing circuitry <NUM>) to one or more communications paths (described below). I/O functions may be provided by one or more of these communications paths, but are shown as a single path in <FIG> to avoid overcomplicating the drawing.

Control circuitry <NUM> may be based on any suitable processing circuitry such as processing circuitry <NUM>. As referred to herein, processing circuitry should be understood to mean circuitry based on one or more microprocessors, microcontrollers, digital signal processors, programmable logic devices, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc., and may include a multi-core processor (e.g., dual-core, quad-core, hexa-core, or any suitable number of cores). In some embodiments, processing circuitry may be distributed across multiple separate processors or processing units, for example, multiple of the same type of processing units (e.g., two Intel Core i7 processors) or multiple different processors (e.g., an Intel Core i5 processor and an Intel Core i7 processor). In some embodiments, control circuitry <NUM> executes instructions for receiving streamed content and executing playback, such as executing application programs that provide interfaces for content providers <NUM> to stream and display content.

Control circuitry <NUM> may thus include communications circuitry suitable for communicating with a content provider <NUM> server or other networks or servers. Communications circuitry may include a cable modem, an integrated services digital network (ISDN) modem, a digital subscriber line (DSL) modem, a telephone modem, Ethernet card, or a wireless modem for communications with other equipment, or any other suitable communications circuitry. Such communications may involve the Internet or any other suitable communications networks or paths. In addition, communications circuitry may include circuitry that enables peer-to-peer communication of user equipment devices, or communication of user equipment devices in locations remote from each other.

Memory may be an electronic storage device provided as storage <NUM> that is part of control circuitry <NUM>. As referred to herein, the phrase "electronic storage device" or "storage device" should be understood to mean any device for storing electronic data, computer software, or firmware, such as random-access memory, read-only memory, hard drives, optical drives, digital video disc (DVD) recorders, compact disc (CD) recorders, BLU-RAY disc (BD) recorders, BLU-RAY 3D disc recorders, digital video recorders (DVR, sometimes called a personal video recorder, or PVR), solid state devices, quantum storage devices, gaming consoles, gaming media, or any other suitable fixed or removable storage devices, and/or any combination of the same. Storage <NUM> may be used to store various types of content described herein as well as media guidance data described above. Nonvolatile memory may also be used (e.g., to launch a boot-up routine and other instructions). Cloud-based storage may be used to supplement storage <NUM> or instead of storage <NUM>.

Control circuitry <NUM> may include video generating circuitry and tuning circuitry, such as one or more analog tuners, one or more MPEG-<NUM> decoders or other digital decoding circuitry, high-definition tuners, or any other suitable tuning or video circuits or combinations of such circuits. Encoding circuitry (e.g., for converting over-the-air, analog, or digital signals to MPEG signals for storage) may also be included. Control circuitry <NUM> may also include scaler circuitry for upconverting and downconverting content into the preferred output format of the user equipment <NUM>. Circuitry <NUM> may also include digital-to-analog converter circuitry and analog-to-digital converter circuitry for converting between digital and analog signals. The tuning and encoding circuitry may be used by the user equipment device to receive and to display, to play, or to record content. The tuning and encoding circuitry may also be used to receive guidance data. The circuitry described herein, including for example, the tuning, video generating, encoding, decoding, encrypting, decrypting, scaler, and analog/digital circuitry, may be implemented using software running on one or more general purpose or specialized processors. Multiple tuners may be provided to handle simultaneous tuning functions (e.g., watch and record functions, picture-in-picture (PIP) functions, multiple-tuner recording, etc.). If storage <NUM> is provided as a separate device from user equipment <NUM>, the tuning and encoding circuitry (including multiple tuners) may be associated with storage <NUM>.

A user may send instructions to control circuitry <NUM> using user input interface <NUM>. User input interface <NUM> may be any suitable user interface, such as a remote control, mouse, trackball, keypad, keyboard, touch screen, touchpad, stylus input, joystick, voice recognition interface, or other user input interfaces. Display <NUM> may be provided as a stand-alone device or integrated with other elements of user equipment device <NUM>. For example, display <NUM> may be a touchscreen or touch-sensitive display. In such circumstances, user input interface <NUM> may be integrated with or combined with display <NUM>. Display <NUM> may be one or more of a monitor, a television, a liquid crystal display (LCD) for a mobile device, amorphous silicon display, low temperature poly silicon display, electronic ink display, electrophoretic display, active matrix display, electro-wetting display, electrofluidic display, cathode ray tube display, light-emitting diode display, electroluminescent display, plasma display panel, high-performance addressing display, thin-film transistor display, organic light-emitting diode display, surface-conduction electron-emitter display (SED), laser television, carbon nanotubes, quantum dot display, interferometric modulator display, or any other suitable equipment for displaying visual images. In some embodiments, display <NUM> may be HDTV-capable. In some embodiments, display <NUM> may be a 3D display, and the interactive media guidance application and any suitable content may be displayed in 3D. A video card or graphics card may generate the output to the display <NUM>. The video card may offer various functions such as accelerated rendering of 3D scenes and 2D graphics, MPEG-<NUM>/MPEG-<NUM> decoding, TV output, or the ability to connect multiple monitors. The video card may be any processing circuitry described above in relation to control circuitry <NUM>. The video card may be integrated with the control circuitry <NUM>. Speakers <NUM> may be provided as integrated with other elements of user equipment device <NUM> or may be stand-alone units. The audio component of videos and other content displayed on display <NUM> may be played through speakers <NUM>. In some embodiments, the audio may be distributed to a receiver (not shown), which processes and outputs the audio via speakers <NUM>.

<FIG> is a generalized embodiment of an illustrative content direction device <NUM> constructed for use according to embodiments of the disclosure. Here, device <NUM> may serve as a content direction device. Device <NUM> may receive content and data via I/O paths <NUM> and <NUM>. I/O path <NUM> may provide content and data to the various content consumption devices <NUM> and <NUM>, while I/O path <NUM> may provide data to, and receive content from, one or more content providers <NUM>. Like the user equipment device <NUM>, the device <NUM> has control circuitry <NUM> which includes processing circuitry <NUM> and storage <NUM>. The control circuitry <NUM>, processing circuitry <NUM>, and storage <NUM> may be constructed, and may operate, similar to the respective components of user equipment device <NUM>.

Storage <NUM> is a memory that stores a number of programs for execution by processing circuitry <NUM>. In particular, storage <NUM> may store a number of device interfaces <NUM>, content provider interfaces <NUM>, manifests <NUM> described further below, and data transfer routines <NUM>. The device interfaces <NUM> are interface programs for handling the exchange of commands and data with the various content consumption devices <NUM>, <NUM>. Content provider interfaces <NUM> are interface programs for handling the exchange of commands and content streams with various content providers <NUM>, and are programmed to exchange commands and content similar to a corresponding application program on a content consumption device <NUM>, <NUM>. A separate interface <NUM> may exist for each different content provider <NUM> that has its own format for commands or content. Data transfer module <NUM> handles routing of content streams from the content providers <NUM> to the appropriate content consumption devices <NUM>, <NUM>. That is, module <NUM> contains routines for redirecting content streams received from content providers <NUM> to specific content consumption devices <NUM>, <NUM>. If content is stored within device <NUM> itself, it may be stored in storage <NUM> along with an application program that streams the stored content to a destination specified as below.

The device <NUM> may be any electronic device capable of receiving content streams and transferring them to one or more content consumption devices <NUM>, <NUM>. For example, the device <NUM> may be a networked in-home smart device connected between a home modem and various content consumption devices <NUM>, <NUM>. The device <NUM> may alternatively be a laptop computer or desktop computer configured as above.

<FIG> are exemplary manifests <NUM> for user identification and conflict determination according to embodiments of the disclosure. The manifests <NUM> shown in <FIG> are device, user, and content manifests respectively. <FIG> illustrates an exemplary device manifest which stores device identifiers DID and the associated device type and device state. Each device identifier DID corresponds to a single content consumption device <NUM>, <NUM>. That is, each device <NUM>, <NUM> is assigned a unique identifier DID. The device type describes the mode or modes that the device can play, i.e., audio (A), video (V), or audio and video (A/V). The device state indicates whether the corresponding device is currently receiving a content stream or not. Thus, the device manifest of <FIG> can be stored as one of the manifests <NUM> to indicate to processing circuitry <NUM> that three devices, DID<NUM>, DID<NUM>, and DID<NUM> are connected to content direction device <NUM> and currently receiving content, where DID<NUM> is receiving audio and video streams, while DID<NUM> and DID<NUM> are both receiving only audio streams.

The content direction device <NUM> constantly maintains and updates its device manifest as the devices connected thereto, and their states, change with time. The device <NUM> may construct and maintain its device manifest in any manner. In one embodiment, device <NUM> detects each content consumption device <NUM>, <NUM> as it powers on and registers with local area network <NUM>, and assigns each device <NUM>, <NUM> a unique number. The state and type fields can be updated when the device <NUM> transmits content to the corresponding content consumption device <NUM>, <NUM>.

<FIG> illustrates an exemplary user manifest which relates users to their devices, accounts, and user profiles. Each user is assigned a unique user identifier UID. Each user identifier UID is associated with one or more device identifiers DID, corresponding to the devices that the user has used at one time. The user manifest also stores account identifiers AID for each account maintained by one of the users with one of the content providers <NUM>. Additionally, the user manifest stores pointers to user profiles P_UID, which are unique user profiles for each user. The user profiles may also be stored in storage <NUM> or elsewhere as appropriate.

The user manifest can be built over time, as various users use the devices <NUM>, <NUM>. Initially, each device <NUM>, <NUM> can be assigned one user UID, and as users add accounts, the account identifiers AID are stored for each device DID that account is used on. A user profile UID is generated or retrieved for each UID, along with a pointer P_UID to that profile. Users can be added as new users register, new devices are added, as new accounts are added, or as comparison of the user profiles indicates that someone is requesting content that does not fit any existing user profile. The determination of a new user by negative comparison to existing profiles is known, and any such method is contemplated by the instant disclosure.

<FIG> illustrates an exemplary content manifest which is a record of devices that play content. When a device begins playing back content, the processor <NUM> records the time t at which playback begins, a content identifier CID from the content provider <NUM> or perhaps metadata of the content stream, the content provider <NUM> identifier CSID, associated device identifier DID, user identifier UID of the user determined to be requesting the content, content type, and content state. The content type is a type identifier for the content, taken from the content provider <NUM>, stream format, or metadata, and is used in determining whether a conflict exists, as is further described below. The content state indicates whether the content is currently being streamed, and can indicate which stream (e.g., audio or video) is being streamed and which is not. For example, in the content manifest of <FIG>, device DID<NUM> begins streaming a video at time t<NUM>, with the audio muted (<NUM>) but the video playing (<NUM>). The video is played from account AID<NUM>, which is associated with users UIDi and UID<NUM> although it cannot be determined which user was using the account at that time. The content manifest is updated when a new content stream begins or changes state, i.e., is paused, stopped, muted, or the like.

Storing the information in the manifests of <FIG> allows the content direction device <NUM> to determine when a single user is requesting content on two different devices. When the content direction device <NUM> receives a request to stream content, it determines the device identifier DID of the device from which it receives the request, and the account identifier AID of the account that generated the request. From this information, corresponding user identifiers UID are determined with reference to the manifest of <FIG>. If only one user identifier UID is associated with the device that requested the content, or only a single UID is associated with the AID that generated the request, that user can be deemed to be the user currently requesting content. If multiple UIDs are associated with the DID and AID, the correct user is determined from among the common users by comparison of the requested content to the user profiles (retrieved with associated pointer P_UID) of each common user. The profile expressing a preference for content that most closely matches the requested content may be deemed to identify the correct user. Such user identification processes are known. The present disclosure contemplates the selection of a correct user from among multiple candidates, with reference to user profiles, in any manner. The user identification steps herein may also be repeated when content is requested on a second device, to identify when the same user is simultaneously requesting two different content streams on two different devices.

Once it is determined that a single user is simultaneously requesting two different content streams on two different devices, it is then determined whether these two streams present a conflict. In one embodiment, this determination is made with reference to a conflict table which describes the situations in which a conflict is, or is not, deemed to occur. <FIG> is an exemplary conflict table for determining conflicts between various types of content. The table can be stored along with the manifests <NUM> as part of storage <NUM>.

The table lists content types on each axis, with conflicting content types indicated with an "x". Each axis represents one content stream on one device. In operation, processor <NUM> determines a conflict by consulting the content manifest of <FIG> to determine the content type of the currently playing stream, and determines the content type of the requested stream. The processor <NUM> then looks up the two content types on the table of <FIG> to determine whether a conflict exists, i.e., whether the corresponding table entry has an "x" or not. Thus, for example, a first device playing a video with dialog (Video_Dialog) would represent a conflict with a second device that requests play of an audio book (Audio_Book), as both have audio streams that would be difficult for a single user to follow when played simultaneously. Conversely, a first device playing an audio book (Audio_Book) and a second device requesting play of a video with muted or no audio (Video_audio_mute) does not present a conflict, as one is audio-only and the other is video-only. It is noted that the information of <FIG> is exemplary, and embodiments of the disclosure encompass conflicts determined in any manner. In particular, the table of <FIG> may vary in different embodiments, with conflicts found for different combinations of content types than those of <FIG>.

Attention now turns to further details of the processes of the disclosure. <FIG> is a flowchart illustrating process steps for detecting and resolving conflicts when a user simultaneously requests content on different devices, in accordance with embodiments of the disclosure. From a predetermined list or set of users, a particular user playing a first content stream on a first device is determined (Step <NUM>). As above, content direction device <NUM> stores user identifiers UID each associated with a different user, device identifiers DID each associated with a different content consumption device <NUM> or <NUM> and each associated with one or more UIDs, account identifiers AID each associated with a user identifier UID and identifying a user account of one of the content providers <NUM>, and user profiles (pointed to by user profile pointers P_UID) each associated with a UID. These identifiers may be stored in storage <NUM> in the form of the manifests of <FIG>, although the disclosure encompasses storage of such identifiers in any manner and within any data structures which are retrievable for use in identifying which users are using which content consumption devices <NUM>, <NUM>.

The stored identifiers are used as above, to determine which UID is associated with the first content stream on the first device <NUM>, <NUM>. As above, if there is only one UID associated with the DID of the first device, then this UID may be deemed as the UID of the user requesting the first content stream. If more than one UID is associated with the DID, then the correct UID is determined by comparing the content of the first content stream to the user profiles of those UIDs associated with the DID.

Once the correct UID for the first content stream is determined, the content direction device <NUM> may detect a request for a second content stream on a second content consumption device <NUM>, <NUM> (Step <NUM>). The UID for this request can be determined in the same manner as for the first content stream, or alternatively may be determined as further explained below. A comparison between the two UIDs is then made (Step <NUM>). If the two UIDs are not the same, then the two content consumption devices <NUM>, <NUM> are being watched by two different users, and there is no conflict. The second content stream is then streamed to the second device <NUM>/<NUM> (Step <NUM>), whereupon the process ends. However, if the two UIDs are the same, then the same user is deemed to be requesting two different content streams, raising the possibility of a conflict. The content type of each stream is retrieved, and the table of <FIG> is consulted to determine whether a conflict is presented (Step <NUM>). If not, then the process continues to Step <NUM>, and the second content stream is streamed to the second device <NUM>/<NUM>. On the other hand, if a conflict is determined to exist according to, e.g., the information of <FIG>, the content direction device <NUM> automatically resolves the conflict (Step <NUM>). Conflict resolution is accomplished in any manner. As one example, the first stream may simply be paused while the second stream is played on the second device, or conversely the second stream may be loaded in a pause state, i.e. immediately paused once streaming has begun, with the option given to resume playback, whereupon the first stream may be paused. Alternatively, the first stream/device may be muted when streaming of the second stream commences. That is, the first video stream may continue to be played while the first audio stream is paused, and both the audio and video streams of the second content stream commence streaming. Other approaches for conflict resolution are further described below. The embodiments of the disclosure contemplate all these and other approaches to conflict resolution.

As above, when the content direction device <NUM> receives a request for a second content stream on a second device, the content direction device <NUM> determines whether the request originates from the same user as requested the first content stream on the first device. This corresponds to Step <NUM> of <FIG>. This Step may be carried out in any manner, such as by the processes described above. <FIG> is a flowchart illustrating further details of an exemplary process for determining the identity of the user requesting the second content stream. Once the content direction device <NUM> receives a request for a second content stream on a second device <NUM>/<NUM>, the device <NUM> determines the account identifier AID associated with the request for the second content stream, i.e., the AID of the account from which the request was issued. This was previously described above with reference to Step <NUM>. From this AID, the content direction device <NUM> determines the associated UID (Step <NUM>). As above, there may be more than one associated UID. If so, the device <NUM> then determines the user profiles of each associated UID, using the pointers P_UID to each associated UID (Step <NUM>). The content of the second content stream is then compared to each user profile, to determine whether the content matches the content profile of the user (Step <NUM>). This comparison can be performed in any manner. For example, user profiles may contain a list of content genres that the associated user prefers, or a list of genres that the user does not wish to watch. The genre or genres of the second content stream (as determined, for instance, from metadata of the second content stream or from the content server <NUM>) can thus be compared to each user profile's lists to determine a match. The user profile whose lists most closely match the genre(s) of the second content stream can be deemed to be the user profile of the user requesting the second content stream. Alternatively, if the content of the second content stream does not match any lists of the user profiles, i.e. if the requested content does not fit the profile of any associated user, the content direction device determines that a different user is requesting the second content stream, and thus that no conflict exists (Step <NUM>).

The steps of <FIG> may be performed as above in connection with Step <NUM>, once the second content stream is requested. Alternatively, or in addition, the steps of <FIG> may also be performed after Step <NUM> is complete, i.e., after it is determined (through some other manner besides the process of <FIG>) that the same user is requesting both content streams. For example, the steps of <FIG> may be performed as a check to verify that the determination of a same user for both content streams is indeed correct. Thus, for example, Step <NUM> may determine a same user by determining that only one UID is associated with the second device <NUM>/<NUM>, but then the process of <FIG> may be carried out to determine that the user requesting the second content stream is actually different from that of the first content stream. This may occur, for instance, when the owner of a device <NUM>/<NUM> lends it to his or her child, who then requests content using the owner's account. In this situation, Step <NUM> may determine that the same user is requesting the second content stream, since the device and the account used to request the second stream are both associated with the owner. However, the process of <FIG> may then determine that the actual user is the owner's child, based on the child requesting content different from that which the owner typically requests (e.g., children's programs).

As previously described, embodiments of the disclosure contemplate many different conflict resolution processes. Some of these processes involve use of secondary audio and video outputs. <FIG> illustrate further details of the conflict resolution process when a secondary audio or video output is available. This secondary audio or video output may be any other device that can output video and/or audio streams of the first or second requested content streams. For instance, the secondary audio or video output may be networked speakers in communication with content direction device <NUM> via local area network <NUM>, another content consumption device <NUM>, <NUM>, or the like.

<FIG> is a flowchart illustrating process steps for conflict resolution with and without a secondary audio output. As above, an audio/video type identifier (A, V, or A/V) may be stored for each device currently playing or requesting a content stream. When one user is determined to be requesting first and second content streams on first and second devices <NUM>, <NUM>, the content direction device <NUM> determines the audio/video type identifier of each device from, e.g., the device manifest of <FIG>. The device <NUM> then determines whether there is an audio conflict, i.e., if the audio/video type identifier associated with the first device and the audio/video type identifier associated with the second device are each A or A/V. If so (Step <NUM>), the content direction device <NUM> determines whether a secondary audio output is available (Step <NUM>). If no secondary audio output is available, then the device <NUM> halts audio output of the first content stream and continues video output of the content stream on the first device <NUM>, <NUM> (Step <NUM>). That is, if no secondary audio output is available, then in the event of an audio conflict, the device <NUM> plays the requested second stream on the second device <NUM>, <NUM>, and plays only the video stream of the first content stream on the first device <NUM>, <NUM>. Thus, the first content stream is muted while the second content stream plays. In this manner, the user may listen to the second device <NUM>, <NUM> while continuing to watch the first device <NUM>, <NUM>. Conflict is resolved by playing only one audio stream (the second) for the user, while also playing both video streams.

If a secondary audio output is available, i.e., device <NUM> determines that another device on local area network <NUM> is currently capable of and available for audio output, the device <NUM> directs the audio signal of the first content stream to the secondary audio output (Step <NUM>). If present, the video signal of the first content stream continues to be directed to the first device, and the second content stream is directed to the second device. Thus, the first device plays mute, while the audio of its content stream is sent to the secondary audio output and the second content stream plays on the second device.

<FIG> is a flowchart illustrating process steps for conflict resolution with and without a secondary video output. As with <FIG> above, when one user is determined to be requesting first and second content streams on first and second devices <NUM>, <NUM>, the content direction device <NUM> determines the audio/video type identifier of each device from, e.g., the device manifest of <FIG>. The device <NUM> then determines if there is a video conflict, i.e., if the audio/video type identifier associated with the first device and the audio/video type identifier associated with the second device are each V or A/V. If so (Step <NUM>), then the content direction device <NUM> determines whether a secondary video output is available (Step <NUM>), such as by determining whether another device on local area network <NUM> is currently available for and capable of video output. If none is available, the device <NUM> halts video output of the first content stream but continues audio output of the first content stream (Step <NUM>). The second content stream is also played on the second device. Thus, the second content stream is played as normal, while only the audio of the first content stream is played, thus resolving conflict between video outputs. On the other hand, if a secondary video output is available, the content direction device <NUM> directs the video signal of the first content stream to the secondary video output (Step <NUM>), while the audio signal of the first content stream continues to be directed to the first device. Meanwhile, the second content stream is streamed to the second device.

When the type identifier of both devices is A/V, that is the conflict is between two streams that each have both audio and video, the processes of both <FIG> may apply. In this case, the content direction device <NUM> may use the process corresponding to the available secondary output. That is, if only a secondary audio output is available, the process of <FIG> may be used, whereas if only a secondary video output is available, the process of <FIG> may be used. If both a secondary audio and a secondary video output are available, the device <NUM> may utilize either the process of <FIG> or that of <FIG>, as preferred.

Another conflict resolution approach contemplated by embodiments of the disclosure involves use of a state flag that can be referred to as a "conditional audio enabled" (CAE) flag. The conditional audio enabled or CAE flag indicates audio priority in a conflict. When a conflict is deemed to occur, and when one of the devices/streams is flagged as having this audio priority state while the other is not, both audio and video of the flagged device/stream is played, while only the video and not the audio of the unflagged device/stream is played.

The CAE flag can be a setting stored by the content direction device <NUM> for each of its content consumption devices <NUM>, <NUM>, and may be determined according to properties of the devices <NUM>, <NUM>, or the content they play, in any manner. For example, the content direction device <NUM> can flag each of its content consumption devices <NUM>, <NUM> as being in the CAE state based on any criteria, e.g., the flag may be set by the user, the first device a user plays may be flagged CAE if it has audio capability and the first content stream includes an audio stream, or the like. Any one or more criteria are contemplated. Alternatively, the content direction device <NUM> may determine the setting of the CAE flag by content. For instance, metadata in a requested content stream may indicate whether that content is CAE content or not. The content direction device <NUM> may also automatically flag certain content as CAE based on various criteria, such as when content has only an audio stream and no video stream.

The CAE flag is used in conflict resolution. Accordingly, the content direction device first determines the UID of the user playing a first content stream on a first device <NUM>, <NUM> and concurrently requesting playback of a second content stream on a second device <NUM>, <NUM> (Step <NUM>). This step may be performed as previously described. It is then determined whether the two content streams present a conflict. If so, the content direction device <NUM> determines whether only one of the streams or only one of the devices is flagged CAE. If so, then the content direction device <NUM> plays both audio and video of the content stream associated with the CAE flag, and plays only the video of the content stream not associated with the CAE flag (Step <NUM>). That is, in a conflict, the device or content stream flagged CAE is played with both audio and video, while the device or content stream not flagged CAE is played without audio.

The CAE flag may also be used to resolve other situations that present conflicts. <FIG> and <FIG> are flowcharts illustrating further details of exemplary conflict resolution processes utilizing the CAE flag. Once a conflict is presented, the content direction device <NUM> determines whether the first device <NUM>, <NUM> or content stream is flagged CAE (Step <NUM>). If not, then the process continues to <FIG>, which is further explained below. However, if the first device or stream is flagged CAE, the content direction device <NUM> then determines whether the first content stream is also paused (Step <NUM>). If so, then the conflict is resolved by keeping the first content stream paused on the first device <NUM>, <NUM>, and playing the second stream on the second device <NUM>, <NUM> (Step <NUM>). If the first content stream has not been paused, then the content direction device <NUM> checks whether the second device <NUM>, <NUM> or second content stream has been flagged CAE (Step <NUM>). If so, then the conflict is between two devices/content streams that have both been flagged CAE. In this case, the content direction device <NUM> pauses the first stream on the first device <NUM>, <NUM>, and plays the second stream on the second device <NUM>, <NUM> (Step <NUM>). If not, i.e., if the first device/stream is flagged CAE but the second device/stream is not, then the content direction device <NUM> checks whether the second content stream has been muted (Step <NUM>), i.e., is currently playing in a mute state. If not, then conflict is resolved by playing the first stream on the first device <NUM>, <NUM>, and playing the second stream in mute on the second device <NUM>, <NUM> (Step <NUM>). That is, the first stream is played back on the first device <NUM>, <NUM>, and only the video stream, not the audio stream, of the second content stream is played on the second device <NUM>, <NUM>.

If the second content stream has already been muted, then the content direction device <NUM> determines whether the first content stream has been paused by the user (Step <NUM>). If so, i.e., if the conflict is between a paused first content stream flagged CAE and a muted second content stream not flagged CAE, then the first stream is kept in its paused state while the second content stream is unmuted (Step <NUM>). That is, conflict is resolved by keeping the first content stream paused and unmuting the second content stream, so that both its audio and video are played back. If, on the other hand, the first content stream has not been paused by the user, then the conflict is instead resolved by playing the first content stream on the first device <NUM>, <NUM> and playing the second stream in mute on the second device <NUM>, <NUM> (Step <NUM>). Thus, if the conflict is between a (non-paused) first content stream flagged CAE and a muted second content stream not flagged CAE, then the conflict is resolved by continuing play of the first content stream and muting the second content stream.

Returning to Step <NUM>, if the first device <NUM>, <NUM> or first content stream is not flagged CAE, then the process proceeds to <FIG>, where the content direction device determines if the first content stream has been paused (Step <NUM>). If so, then the conflict is resolved by continuing to pause the first content stream on the first device <NUM>, <NUM>, and playing the second content stream on the second device <NUM>, <NUM> (Step <NUM>). However, if the first content stream has not been paused, i.e., if the first content stream is currently playing when a conflict is determined, then the content direction device <NUM> determines whether the first content stream is playing in mute, or only the video stream but not the audio stream of the first content stream is being played (Step <NUM>). If so, then the content direction device <NUM> checks whether the second device <NUM>, <NUM> or second content stream is flagged CAE (Step <NUM>). If it has, then conflict is resolved by playing the first stream mute on the first device <NUM>, <NUM>, and playing the entire second content stream on the second device <NUM>, <NUM> (Step <NUM>). On the other hand, if the second device <NUM>, <NUM> or second content stream is not flagged CAE, then conflict is resolved by unmuting the first content stream and playing the second content stream on mute (Step <NUM>). Thus, if the conflict is between a first non-CAE content stream playing mute and a second content stream flagged CAE, the first stream is kept in its mute state while the second stream is played in its entirety (audio and video). Alternatively, if the conflict is between two non-CAE streams, the first of which is already muted, then the conflict is resolved by pausing and un-muting the first stream and playing the second stream on mute.

If, after Step <NUM>, the first content stream is not muted, then the content direction device checks whether the second content stream or second device <NUM>, <NUM> is flagged CAE (Step <NUM>). If so, i.e., if the conflict is between a first content stream not flagged CAE and a second content stream flagged CAE, then the first stream is muted and played, while the second stream is played (Step <NUM>). That is, the non-CAE content stream is muted but its video is played, and both the audio and video of the CAE content stream are played. On the other hand, if neither the first device/stream nor the second device/stream is flagged CAE, then the conflict is between two non-CAE devices/streams. In this case, the content direction device <NUM> resolves the conflict by pausing the first stream on the first device <NUM>, <NUM>, and playing the second stream on the second device <NUM>, <NUM> (Step <NUM>).

Claim 1:
A method of identifying a user requesting playback of multiple content streams, the method comprising:
determining, from a list of users, a single user playing a first content stream on a first device (<NUM>);
detecting a request for a second content stream on a second device (<NUM>);
determining whether the same user initiated the request for the second content stream;
if the same user initiated the request for the second content stream, determining whether a conflict exists between the first content stream on the first device (<NUM>) and the second content stream on the second device (<NUM>);
if the conflict exists, resolving the conflict by pausing or redirecting one of the first content stream and the second content stream; and
determining whether the conflict is an audio conflict or a video conflict;
if the conflict is an audio conflict, determining whether a secondary audio output is available, and:
if a secondary audio output is available, directing an audio signal of the first content stream to the secondary audio output; and
if a secondary audio output is not available, halting audio output of the first content stream while continuing video output of the first content stream to the first device (<NUM>); and
if the conflict is a video conflict, determining whether a secondary video output is available, and:
if a secondary video output is available, directing a video signal of the first content stream to the secondary video output; and
if a secondary video output is not available, halting video output of the first content stream while continuing audio output of the first content stream to the first device (<NUM>).