Patent Description:
In some instances, a first user may be interested in a media content item that is playing back or otherwise active on a media playback device of a second user. However, currently there are no convenient techniques that enable the media content item of interest to be automatically added to the first user's library.

<CIT> discloses Systems, methods, apparatus, and articles of manufacture for discovery and remote configuration of content for playback via a multimedia playback network. An example method includes facilitating identification of multimedia content being played, the identification including at least one of a content identifier associated with the content and the content itself. An example method includes relaying at least one of the content identifier and the content to a playback system located remotely from a location of the multimedia content playback.

In general terms, this disclosure is directed to a system for device-to-device media capturing. In one possible configuration and by non-limiting example, a first device is associated with an active media content item that is provided by a media service. A second device that is associated with a user account of the media service is moved proximate to the first device causing transmission of one or more wireless communications between the devices. Device-to-device media capturing is triggered, and an identifier for the active media content item is stored to a library of the user account. For example, the identifier is stored in response to detecting the proximity of the devices and determining that the second device is moving towards the first device. Various aspects are described in this disclosure, which include, but are not limited to, the following aspects.

One aspect is a method for device-to-device media capturing as defined in claim <NUM>. A further aspect is a server for device-to-device media capturing as defined in claim <NUM>. A further aspect is a first device for device-to-device media capturing as defined in claim <NUM>. A further aspect is a second device for device-to-device media capturing as defined in claim <NUM>. A further aspect is a computer readable storage medium as defined in claim <NUM>.

An example method includes detecting that a first device and a second device are proximate to one another. The first device is associated with a first user account of a media service and an active media content item provided by the media service. The second device is associated with a second user account of the media service. The example method further includes determining that the second device is moving toward the first device, and in response to detecting that the first device and the second device are proximate to one another and determining that the second device is moving toward the first device, storing an identifier of the active media content item to a library associated with the second user account.

An example server includes at least one processing device and a memory coupled to the at least one processing device and storing instructions. The instructions, when executed by the at least one processing device, cause the at least one processing device to detect that a first device and a second device are proximate to one another. The first device is associated with a first user account of a media service and an active media content item provided by the media service. The second device is associated with a second user account of the media service. The at least one processing device is further caused to determine that the second device is moving toward the first device, and in response to detecting that the first device and the second device are proximate to one another and determining that the second device is moving toward the first device, store an identifier of the active media content item to a library associated with the second user account.

An example computer readable storage medium stores executable instructions that, when executed by at least one processing device, cause the at least one processing device to detect that a first device and a second device are proximate to one another. The first device is associated with a first user account of a media service and an active media content item provided by the media service. The second device is associated with a second user account of the media service. The at least one processing device is also caused to determine that the second device is moving toward the first device, and in response to detecting that the first device and the second device are proximate to one another and determining that the second device is moving toward the first device, store an identifier of the active media content item to a library associated with the second user account.

One example is a method for device-to-device media capturing. An example method includes detecting that a first device and a second device are proximate to one another. The first device is associated with a first user account of a media service and an active media content item provided by the media service. The second device is associated with a second user account of the media service. The example method further includes determining that the second device is moving toward the first device, and sending an indication to the first device to prompt the first device to transmit an identifier of the active media content item to the second device. The second device stores the identifier to a library associated with the second user account upon receipt from the first device.

Another example is a method for capturing a media content item. An example method includes detecting, by a first device that is associated with a first user account of a media service and an active media content item provided by the media service, that a second device is proximate to the first device. The second device is associated with a second user account of the media service. The example method also includes determining that the second device is moving toward the first device, and transmitting an identifier of the active media content item to the second device. The second device stores the identifier to a library associated with the second user account upon receipt from the first device.

<FIG> illustrates an example operating environment for a device-to-device media capturing system <NUM>. In this example, the system <NUM> includes a plurality of media playback devices <NUM> and a media delivery system <NUM> that communicate over a network <NUM>. In some embodiments, the media delivery system <NUM> provides a media service to the media playback devices <NUM>, where each of the media playback devices <NUM> is associated with a user account of the media service. For example, the media playback devices <NUM> include a first device <NUM> associated with a first user account of the media service and a second device <NUM> associated with a second user account of the media service.

In some embodiments, a media playback engine <NUM> runs on the media playback devices <NUM>, including first device <NUM> as illustrated, and a device-to-device media capturing engine <NUM> runs on the media delivery system <NUM>. Although not illustrated, the media playback engine <NUM> can also run on the second device <NUM>. In other embodiments, in addition to running on the media delivery system <NUM>, the device-to-device media capturing engine <NUM> can also run on the media playback devices <NUM>, including the first device <NUM> and/or the second device <NUM>.

As illustrated in <FIG>, the first device <NUM> operates to play back one or more media content items, such as Track A <NUM>. A media content item is an item of media content, including audio, video, or other types of media content, which are stored in any format suitable for storing media content. Non-limiting examples of media content items include songs, albums, music videos, movies, television episodes, podcasts, other types of audio or video content, and portions or combinations thereof. In this document, the media content items can also be referred to as tracks. In some examples, the media content items may be in a form of a playlist.

The first device <NUM> operates to play the media content items, such as Track A <NUM>, to produce media output <NUM>, the playing thereof facilitated by the media playback engine <NUM>. In some embodiments, the media content items are provided by the media delivery system <NUM> and transmitted to the first device <NUM> using the network <NUM>.

A media content item being played by the first device <NUM>, such as Track A <NUM>, is an example type of an active media content item associated with the first device <NUM>. However, in other examples, an active media content item can be a media content item that has been selected for playback but is currently paused or is next in queue to be played by the first device <NUM>. In some embodiments, the first device <NUM>, when associated with an active content item, such as Track A <NUM>, can activate a module that awaits a proximity-based interaction with another device, such as second device <NUM>.

Also shown is a user U who, in this particular example, uses the second device <NUM> to interact with (e.g., by moving the second device <NUM> proximate to) the first device <NUM> to capture the active media content item, Track A <NUM>, being played back by the first device <NUM>. For example, proximity-based communication technologies, such as Near Field Communication (NFC), Radio Frequency Identification (RFID) technologies, BLUETOOTH® Low Energy (BLE) or Wireless Fidelity (Wi-Fi), can be utilized to trigger device-to-device media capturing. For example, based on a proximity of the second device <NUM> to the first device <NUM>, one or more wireless communications are transmitted between the first device <NUM> and the second device <NUM>. As described in more detail below, the communications cause each of the first device <NUM> and the second device <NUM> to provide user account-related information included in the communications along with device motion data to the media delivery system <NUM>. In another embodiment, facial and gesture recognition techniques can be utilized to trigger the device-to-device media capturing. For example, facial recognition is implemented to identify a user of each of the first device <NUM> and the second device <NUM> from which the user account-related information can be determined and provided to the media delivery system <NUM>. Additionally, gestures from one or both users can be recognized that indicate which device user has the intent to capture the active media content item.

The media delivery system <NUM> is connectable to and operates to provide the media content items to the plurality of media playback devices <NUM>, including first device <NUM> and second device <NUM>. In some embodiments, the media delivery system <NUM> provides the media content items to one or more of the media playback devices <NUM> independently or simultaneously. Additionally, the media delivery system <NUM> operates to facilitate device-to-device media capturing. For example, when the device-to-device media capturing is triggered upon the second device <NUM> being moved into proximity with the first device <NUM>, the device-to-device media capturing engine <NUM> receives information from the devices that are used to determine which, if any of the devices, is a device capturing the active media content item (e.g., a device whose user intends to capture the active media content item).

In the illustrated example, the second device <NUM> is determined to be the device capturing the active media content item based on the movement of the second device <NUM> towards the first device <NUM>. For example, the device-to-device media capturing engine <NUM> receives, from each device, user-account related information exchanged in the communications between the devices and motion data of the device to determine that the second device <NUM> is proximate to the first device <NUM> and is moving towards the first device <NUM>. While motion of the devices is discussed herein as an example type of information being used by the device-to-device media capturing engine <NUM> to determine which device is the device capturing the active media content item, types of information used for such determination are not so limited and can be generally understood as any type of information revealing that an interaction of one device with another device associated with an active media content item is an intentional interaction controlled by a user of the device to capture the active media content item. Another example type of information can include gestures of a user controlling a device, where capture and recognition of a particular gesture by the user can be used to determine that the device is the device capturing the active media content item. In some examples, the gesture of the user can be captured by the device itself and/or by the other device (e.g., the device associated with the active media content item) and provided to the device-to-device media capturing engine <NUM> for recognition and use in the determination of which device is the device capturing the active media content item.

Based on the determination that the second device <NUM> is the device capturing the active media content item, the device-to-device media capturing engine <NUM> may, in some embodiments, store an identifier for the active media content item (e.g., Track A ID <NUM>) to a library <NUM> of the second user account associated with the second device <NUM>. In other embodiments, the device-to-device media capturing engine <NUM> transmits an indication to the first device <NUM> that prompts the first device <NUM> to transmit the identifier for the active media content item in a wireless communication to the second device <NUM> such that the second device <NUM> stores the identifier.

In some examples, upon storage of the identifier, the device-to-device media capturing engine <NUM> causes immediate playback of the media content item on the second device <NUM> (e.g., facilitated by a media playback engine of the second device <NUM>). In further examples, the device-to-device media capturing engine <NUM> provides a notification for display on the second device <NUM> that indicates the storage of the identifier <NUM> to the library <NUM>. In one example, the notification is only provided if the media content item is not immediately played back.

<FIG> illustrates an example device-to-device media capturing system <NUM>. As described herein, a media playback device <NUM> operates to play media content items. First device <NUM> and second device <NUM> described in detail with reference to <FIG> are examples of media playback device <NUM>. In some embodiments, the media playback device <NUM> operates to play media content items that are provided (e.g., streamed, transmitted, etc.) by a system external to the media playback device such as the media delivery system <NUM>, another system, or a peer device. Alternatively, in some embodiments, the media playback device <NUM> operates to play media content items stored locally on the media playback device <NUM>. Further, in at least some embodiments, the media playback device <NUM> operates to play media content items that are stored locally as well as media content items provided by other systems.

In some embodiments, the media playback device <NUM> is a computing device, handheld entertainment device, smartphone, tablet, watch, headphone, wearable device, or any other type of device capable of playing media content. In yet other embodiments, the media playback device <NUM> is a laptop computer, desktop computer, television, gaming console, set-top box, network appliance, Blu-ray or DVD player, media player, stereo, or radio.

In at least some embodiments, the media playback device <NUM> includes a location-determining device <NUM>, a touch screen <NUM>, a processing device <NUM>, a memory device <NUM>, a motion detector <NUM>, a content output device <NUM>, and a network access device <NUM>. Other embodiments may include additional, different, or fewer components. For example, some embodiments may include a recording device such as a microphone or camera that operates to record audio or video content. As another example, some embodiments do not include one or more of the location-determining device <NUM> and the touch screen <NUM>.

The location-determining device <NUM> is a device that determines the location of the media playback device <NUM>. In some embodiments, the location-determining device <NUM> uses one or more of the following technologies: Global Positioning System (GPS) technology which may receive GPS signals from satellites S, cellular triangulation technology, network-based location identification technology, Wi-Fi positioning systems technology, and combinations thereof.

The touch screen <NUM> operates to receive an input from a selector (e.g., a finger, stylus etc.) controlled by a user. In some embodiments, the touch screen <NUM> operates as both a display device and a user input device. In some embodiments, the touch screen <NUM> detects inputs based on one or both of touches and near-touches. In some embodiments, the touch screen <NUM> displays a user interface <NUM> for interacting with the media playback device <NUM>. As noted above, some embodiments do not include a touch screen <NUM>. Some embodiments include a display device and one or more separate user interface devices. Further, some embodiments do not include a display device.

In some embodiments, the processing device <NUM> comprises one or more central processing units (CPU). In other embodiments, the processing device <NUM> additionally or alternatively includes one or more digital signal processors, field-programmable gate arrays, or other electronic circuits.

The memory device <NUM> operates to store data and instructions. In some embodiments, the memory device <NUM> stores instructions for a media playback engine <NUM>. Optionally, the memory device <NUM> also stores instructions for the device-to-device media capturing engine <NUM>. As part of the data stored, the memory device <NUM> can optionally store at least a portion of a library <NUM> of a user account for the media service associated with the media playback device <NUM> locally.

The memory device <NUM> typically includes at least some form of computer-readable media. Computer readable media include any available media that can be accessed by the media playback device <NUM>. By way of example, computer-readable media include computer readable storage media and computer readable communication media.

Computer readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any device configured to store information such as computer readable instructions, data structures, program modules, or other data. Computer readable storage media includes, but is not limited to, random access memory, read only memory, electrically erasable programmable read only memory, flash memory and other memory technology, compact disc read only memory, Blu-ray discs, digital versatile discs or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the media playback device <NUM>. In some embodiments, computer readable storage media is non-transitory computer readable storage media.

Computer readable communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, computer readable communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.

The motion detector <NUM> operates to detect three-dimensional motion of the media playback device <NUM>. In some examples, the motion detector <NUM> includes an accelerometer that operates to measure acceleration forces acting on the media playback device <NUM> to determine a position of the media playback device <NUM> in space and monitor movement of the media playback device <NUM>.

The content output device <NUM> operates to output media content. In some embodiments, the content output device <NUM> generates media output <NUM> (<FIG>) for the user U. Examples of the content output device <NUM> include a speaker, an audio output jack, a BLUETOOTH® transmitter, a display panel, and a video output jack. Other embodiments are possible as well. For example, the content output device <NUM> may transmit a signal through the audio output jack or BLUETOOTH® transmitter that can be used to reproduce an audio signal by a connected or paired device such as headphones or a speaker.

The network access device <NUM> operates to communicate with other computing devices over one or more networks, such as the network <NUM>. Examples of the network access device include wired network interfaces and wireless network interfaces. Wireless network interfaces include infrared, BLUETOOTH® wireless technology, <NUM>. 11a/b/g/n/ac, and cellular or other radio frequency interfaces in at least some possible embodiments.

The media playback engine <NUM> running on the media playback device <NUM> operates to play back one or more of the media content items (e.g., audio). As described herein, the media playback engine <NUM> is configured to communicate with the media delivery system <NUM> to receive one or more media content items (e.g., through the stream media <NUM>). In some embodiments, the media playback device <NUM> also stores instructions for the device-to-device media capturing engine <NUM> locally in the memory device <NUM> that can be operated independently from or in conjunction with the device-to-device media capturing engine <NUM> running on the media delivery system <NUM>.

With further reference to <FIG>, the media delivery system <NUM> includes one or more computing devices and operates to provide media content items to the media playback device <NUM> and, in some embodiments, other media playback devices as well. In some embodiments, the media delivery system <NUM> operates to transmit the stream media <NUM> to media playback devices <NUM> such as the first device <NUM> or second device <NUM> described in <FIG>.

In some embodiments, the media delivery system <NUM> includes a media server <NUM> and a device-to-device media capturing server <NUM>. In this example, the media server <NUM> includes a media server application <NUM>, a processing device <NUM>, a memory device <NUM>, and a network access device <NUM>. The processing device <NUM>, memory device <NUM>, and network access device <NUM> may be similar to the processing device <NUM>, memory device <NUM>, and network access device <NUM> respectively, which have each been previously described.

In some embodiments, the media server application <NUM> operates to stream music or other audio, video, or other forms of media content. The media server application <NUM> includes a media stream service <NUM>, a media data store <NUM>, an account data store <NUM>, and a media application interface <NUM>.

The media stream service <NUM> operates to buffer media content such as media content items <NUM> (including 170A, 170B, and 170Z) for streaming to one or more streams 172A, 172B, and 172Z.

The media application interface <NUM> can receive requests or other communication from media playback devices or other systems, to retrieve media content items from the media delivery system <NUM>. For example, in <FIG>, the media application interface <NUM> receives communications <NUM> from the media playback device <NUM>.

In some embodiments, the media data store <NUM> stores media content items <NUM>, media content metadata <NUM>, and media contexts <NUM>. The media data store <NUM> may comprise one or more databases and file systems. Other embodiments are possible as well. As noted above, the media content items <NUM> may be audio, video, or any other type of media content, which may be stored in any format for storing media content.

The media content metadata <NUM> operates to provide various pieces of information associated with the media content items <NUM>. The media content metadata <NUM> includes an identifier for each of the media content items <NUM>. The identifier can be a media service catalog number, for example, by which the media server application <NUM> can identify the respective media content item from other of the media content items <NUM>. In some embodiments, the media content metadata <NUM> also includes one or more of title, artist name, album name, length, genre, mood, era, etc. associated with each of the media content items <NUM>. In addition, the media content metadata <NUM> includes acoustic metadata which may be derived from analysis of the track. Acoustic metadata may include temporal information such as tempo, rhythm, beats, downbeats, tatums, patterns, sections, or other structures. Acoustic metadata may also include spectral information such as melody, pitch, harmony, timbre, chroma, loudness, vocalness, or other possible features. The media content metadata <NUM> can also include a machine-readable code for each of the media content items <NUM>, where the code is scannable or capable of being captured by a camera of the media playback device <NUM>. In some examples, the machine-readable code can be linked to or include the identifier for media content item. Examples of the media content metadata <NUM> are illustrated and described in more detail with reference to <FIG>.

Each of the media contexts <NUM> is used to identify one or more of the media content items <NUM>. In some embodiments, the media contexts <NUM> are configured to group one or more of the media content items <NUM> and provide a particular context to the group of media content items <NUM>. Some examples of the media contexts <NUM> include albums, artists, playlists, and individual media content items. By way of example, where a media context <NUM> is an album, the media context <NUM> can represent that the media content items <NUM> identified by the media context <NUM> are associated with that album.

As described above, the media contexts <NUM> can include playlists. The playlists are used to identify one or more of the media content items <NUM>. In some embodiments, the playlists identify a group of the media content items <NUM> in a particular order. In other embodiments, the playlists merely identify a group of the media content items <NUM> without specifying a particular order. Some, but not necessarily all, of the media content items <NUM> included in a particular one of the playlists are associated with a common characteristic such as a common genre, mood, or era. Examples of the media contexts <NUM> are illustrated and described in more detail with reference to <FIG>.

In some embodiments, the account data store <NUM> includes user account data <NUM> and libraries <NUM>. The account data store <NUM> can comprise one or more databases and file systems. The user account data <NUM> includes data specific to each of a plurality of user accounts associated with the media service. For example, for each user account, the user account data <NUM> includes one or more media service identifiers for that account. Example media service identifiers can include a user account identifier, a user identifier, and a device identifier for the user account, among other examples. A user account identifier can be a string of numbers and/or letters that identify the user account. A user identifier can be a string of numbers and/or letters that identify a particular user associated with the user account. For example, a single user account can be associated with two or more users, where each user has their own associated user identifier. A device identifier can be a string of numbers and/or letters that identify a device that is associated with the user account. A plurality of devices can be associated with each user account. The user account data <NUM> can also include information such as an account password and a subscription type. In some examples, the user account data <NUM> can also include playback state information associated with the user account, such as an active media content item on one or more of the devices associated with the user account. Examples of the user account data <NUM> are illustrated and described in more detail with reference to <FIG>.

The libraries <NUM> include at least one library for each user account (e.g., including the library <NUM> for the user account associated with the media playback device <NUM>). A library for a user account stores identifiers for a set of media content items that either an associated user manually liked or favorited through a user interface on their device or were automatically captured using device-to device media capturing as described herein (e.g., by the user moving their device in close proximity to another device on which the media content item is an active media content item). In some embodiments, a library is in the form of a playlist. An example library for a user account is illustrated and described in more detail with reference to <FIG>.

Referring still to <FIG>, in this example, the device-to-device media capturing server <NUM> includes the device-to-device media capturing engine <NUM>, a media capturing interface <NUM>, a media capturing data store <NUM>, a processing device <NUM>, a memory device <NUM>, and a network access device <NUM>. The processing device <NUM>, memory device <NUM>, and network access device <NUM> may be similar to the processing device <NUM>, memory device <NUM>, and network access device <NUM> respectively, which have each been previously described.

The device-to-device media capturing engine <NUM> operates to determine which device of two media playback devices detected as being proximate to one another is the device capturing an active media content item associated with the other device. In some examples, the determination can be made based on movement of the devices relative to one another based on information received from each of the media playback devices. The device-to-device media capturing engine <NUM> then stores an identifier of the active media content item to a library of a user account associated with the device determined to be capturing the active media content item from the other device.

The media capturing interface <NUM> can receive requests or other communications from other systems. For example, the media capturing interface <NUM> receives communications <NUM> from the media server application <NUM>, the communications including an identifier of an active media content item on one or more of the media playback devices <NUM> involved in the device-to-device media capturing. The media capturing interface <NUM> can also send requests to the media server application <NUM> (e.g., through the communications <NUM>). For example, the requests include to store the identifier of the active content item associated with a particular media playback device to a library (e.g., within libraries <NUM>) of a user account associated with another media playback device that is determined by the device-to-device media capturing engine <NUM> to be the device capturing the active media content item (e.g., the device that is proximate and moving toward that particular media playback device).

Additionally, the media capturing interface <NUM> may facilitate transmission of the communications <NUM> to media playback devices (e.g., to media playback engine <NUM> and/or device-to-device media capturing engine <NUM> of media playback device <NUM>). In some embodiments, the communications <NUM> can indicate whether that media playback device <NUM> is a transmitting device or a receiving device in the device-to-device capturing process based on if the media playback device <NUM> is determined to be capturing the active media content item. For example, if the media playback device <NUM> is determined not to be capturing the active media content item then it is a transmitting device, and in some examples, is prompted to transmit the identifier of the active media content item to the other device (e.g., the receiving device) over a wireless communication. In other examples, the communications <NUM> include a notification for display on the media playback device <NUM> that can indicate either the identifier of the active media content item has been stored in the library or that the active media content item has been captured by another device dependent on whether the media playback device <NUM> is the device capturing the active media content item or not.

In some embodiments, the media capturing data store <NUM>, at least temporarily, stores information received from the media playback devices that is used by the device-to-device media capturing engine <NUM> to determine which device is capturing the active media content (e.g., user-account related information and device motion data to detect proximity and determine relative movement of the devices to one another). The media capturing data store <NUM> can also, at least temporarily store the identifier for the active content items received from the media server application <NUM> via the communications <NUM>. The media capturing data store <NUM> may comprise one or more databases and file systems. Other embodiments are possible as well.

Referring still to <FIG>, the network <NUM> is an electronic communication network that facilitates communication between the media playback device <NUM> and the media delivery system <NUM>. An electronic communication network includes a set of computing devices and links between the computing devices. The computing devices in the network use the links to enable communication among the computing devices in the network. The network <NUM> can include routers, switches, mobile access points, bridges, hubs, intrusion detection devices, storage devices, standalone server devices, blade server devices, sensors, desktop computers, firewall devices, laptop computers, handheld computers, mobile telephones, and other types of computing devices.

In various embodiments, the network <NUM> includes various types of links. For example, the network <NUM> can include wired and/or wireless links, including BLUETOOTH®, ultra-wideband (UWB), <NUM>, ZigBee, cellular, and other types of wireless links. Furthermore, in various embodiments, the network <NUM> is implemented at various scales. For example, the network <NUM> can be implemented as one or more local area networks (LANs), metropolitan area networks, subnets, wide area networks (such as the Internet), or can be implemented at another scale. Further, in some embodiments, the network <NUM> includes multiple networks, which may be of the same type or of multiple different types.

Although <FIG> illustrates only a single media playback device <NUM> communicable with a single media delivery system <NUM>, in accordance with some embodiments, the media delivery system <NUM> can support the simultaneous use of multiple media playback devices, and the media playback device can simultaneously access media content from multiple media delivery systems. Additionally, although <FIG> illustrates a streaming media based system for facilitating automatic capture of media content items from one device to another, other embodiments are possible as well. For example, in some embodiments, the media playback device <NUM> includes a media data store <NUM> and an account data store <NUM> stored locally and is configured to perform device-to-device media capturing without accessing the media delivery system <NUM>, as described in detail in <FIG> below.

<FIG> illustrates an example method <NUM> for device-to-device media capturing. In this example, the method <NUM> is described as being performed by the device-to-device media capturing engine <NUM>. In some examples, the device-to-device media capturing engine <NUM> is running on the media delivery system <NUM> (e.g., on the device-to-device media capturing server <NUM> of the media delivery system <NUM>). In other examples, the device-to-device media capturing engine <NUM> is running on a media playback device <NUM>, such as on one or both of the first device <NUM> and the second device <NUM> described in <FIG>.

The method can begin at operation <NUM>, where a first device associated with an active media content item provided by a media service is detected to be proximate to a second device. The second device is associated with a user account of the media service (e.g., a second user account). The first device can also be associated with a different user account of the media service (e.g., a first user account). In some examples, the active media content item is a media content item that is being played by the first device or is selected for playback but is currently paused. In other examples, the active media content item can be an item in queue for playback by the first device.

In some embodiments, due to the active media content item, a module of the first device is activated that awaits a proximity-based interaction with another device. For example, the proximity of the first and second devices to one another causes one or more wireless communications to be transmitted between the first and second devices. Example types of wireless communications can include NFC, RFID, BLE, or Wi-Fi communications. Within these communications, user account-related information, such as one or more media service identifiers for the first and second user account, can be exchanged between the first and second devices. For example, the first device receives a second media service identifier associated with the second user account from the second device, and the second device receives a first media service identifier associated with the first user account from the first device in the one or more wireless communications. These communications can serve to trigger the device-to-device media capturing. In some embodiments, this trigger causes information, including the respective media service identifiers exchanged, to be provided from the first and second devices to the device-to-device media capturing engine <NUM>. The first device and the second device can be detected to be proximate to one another based on a correlation between the respective media service identifier received from the respective device. In some examples, additional or alternative data such as GPS data or other similar data collected by the devices (e.g., by the location-determining device <NUM> of media playback device <NUM> described in <FIG>) and provided to the device-to-device media capturing engine <NUM> can be used to detect proximity of the first and second devices.

Once proximity of the first and second devices are detected, the second device is determined to be moving toward the first device at operation <NUM>. The determination can be made based on a comparison of motion data collected by the motion detector <NUM> of each device. In some embodiments, the motion data includes an acceleration of each device at a point in time that the devices came into very close or actual physical contact (e.g., came into proximity of one another) causing the one or more wireless communications to be transmitted between the first and second devices. Example processes for determining the movement of the first and second devices relative to one another is described in more detail with respect to <FIG>.

At operation <NUM>, an identifier of the active media content item is caused to be stored to a library associated with the user account associated with the second device (e.g., the second user account). That is, the identifier rather than the active media content item itself is stored to the library. Storage of the identifier to the library allows the respective user of the user account to quickly locate and access the active media content item for later playback. In some embodiments, and as described in more detail with respect to <FIG>, once the identifier is stored, the active media content item can be immediately played back on the second device and/or a notification can be provided for display on one or both of the first device and the second device to provide feedback that the capture occurred.

In this example method <NUM>, the identifier of the active media content item is caused to be stored to a library associated with the user account of the second device that is determined to be moving toward the first device. This is based on an assumption that movement of the second device toward the first device indicates that a user of the second device controlling the movement has the intent to capture the active media content item. However, the systems and methods described herein are not so limited.

In other scenarios, the second device moving towards the first device as controlled by a user of the second device can indicate the user is willing to share the active media content item with the first device (e.g., in response to a user of the first device indicating they were interested in the active media content item). In such scenarios, determination that the second device is moving toward the first device can cause the identifier of the active media content item to be stored to a library of the user account associated with the first device.

In further scenarios, the first and second users of the first device and second device are both moving their devices toward one another. In one embodiment, if only the first device has an associated active media content item, and both the first and second devices are determined to be moving toward one another, the identifier of the active media content item is caused to be stored to a library associated with the user account associated with the second device.

In other embodiments, if both the first and second devices have an associated active media content item, and both the first and second devices are determined to be moving toward one another, the outcome can be dependent on an acceleration of each device. This is based on an assumption that a greater acceleration (e.g., a quicker movement) of a device indicates that a user of that device controlling the movement has the intent to capture the active media content item. For example, if the second device is moving towards the first device at a greater acceleration than the first device is moving toward the second device, the identifier of the active media content item is caused to be stored to a library associated with the user account associated with the second device.

In some embodiments, the difference in a first acceleration of the first device and a second acceleration of the second device must be above a predefined threshold value to cause an active media content item to be stored to a library of a user account associated with the device having the greater acceleration when active media content items are associated with each device. In one embodiment, if the threshold is not met, neither identifier is stored to a library of a user account associated with the other device. This outcome is based on an assumption that neither user of the first or second device had the intention to capture the active media content item associated with the other device. In another embodiment, if the threshold is not met, the identifier for each active media content item on the first and second device is caused to be stored to a library of a user account associated with the other device. For example, the identifier for the active media content item associated with the first device is stored to a library of a user account associated with the second device, and the identifier for the active media content item associated with the second device is stored to a library of a user account associated with the first device. This outcome is based on the assumption that both users of the first and second device had equal intentions to capture the active media content item associated with the other device based on the similar accelerations of the first and second devices toward one another.

<FIG> illustrates a conceptual diagram <NUM> for a first configuration of a device-to-device media capturing system. As shown in diagram <NUM>, at least two media playback devices <NUM>, such as a first device <NUM> and a second device <NUM>, come into proximity of one another as the second device <NUM> is moved toward the first device <NUM> into very close or actual physical contact. The first device <NUM> is associated with an active media content item. For example, the first device <NUM> is playing Track B <NUM>, however the playback may be currently paused. In some examples, the first device <NUM> or another peripheral device paired to the first device <NUM> visually displays information about the active media content item associated with the first device <NUM>. For example, at least a portion of the media content metadata <NUM> for Track B <NUM> stored in the media data store <NUM> is received and displayed on a user interface of the first device <NUM>. The portion of the media content metadata <NUM> can include a machine-readable code, cover art, and/or a text description, including information such as title, artist name, album name, length, genre, mood, or era. In some embodiments, the first device <NUM>, when associated with the active content item, can activate a module that awaits a proximity-based interaction with another device, such as second device <NUM>.

In this example, both the first device <NUM> and the second device <NUM> are smartphones that are NFC capable. As the second device <NUM> is moved toward the first device <NUM> and into a predefined NFC range of the first device <NUM> for a predefined time period (e.g., when the second device <NUM> taps the first device <NUM>), NFC communication is initiated to exchange data between the first device <NUM> and the second device <NUM> over one or more wireless communications (e.g., initiating performance of device-to-device media capturing process steps). As one example, at steps 1a and 1b, at least one media service identifier (MSID) of a user account associated with each of the first device <NUM> and the second device <NUM> is exchanged. One example type of MSID includes a user account identifier. The user account identifier can be a string of numbers and/or letters that identify a user account of the media service. For example, at step 1a, a first user account identifier (UAID <NUM>) <NUM> for a first user account associated with the first device <NUM> is transmitted from the first device <NUM> to the second device <NUM> over a wireless communication. At step 1b, a second user account identifier (UAID <NUM>) <NUM> for a second user account associated with the second device <NUM> is transmitted from the second device <NUM> to the first device <NUM> over another wireless communication.

Upon exchange of the user account identifiers <NUM>, <NUM>, the first device <NUM> and the second device <NUM> transmit sets of information <NUM>, <NUM> over the network <NUM> to the media delivery system <NUM> for use by the device-to-device media capturing engine <NUM> at steps 2a and 2b. Specifically, at step 2a, a first set of information <NUM> transmitted by the first device <NUM> includes the second user account identifier <NUM> received from the second device <NUM> in the NFC communication data exchange and first motion data (Device <NUM> Motion Data) <NUM> of the first device <NUM>. In some examples, the first set of information <NUM> can also include location data (e.g., GPS coordinates) of the first device <NUM>.

In further examples, the first set of information <NUM> can also include an indication or identifier of the active media content item associated with the first device <NUM> (e.g., an identifier of Track B <NUM>). Additionally or alternatively, the device-to-device media capturing engine <NUM> receives the indication or identifier of the active media content item associated with the first device <NUM> from the media server application <NUM> based on playback state information maintained by the media server application <NUM> (e.g., stored in account data store <NUM>). For example, the device-to-device media capturing engine <NUM> can request playback state information of the first device <NUM> and/or second device <NUM> from the media server application <NUM> upon receipt of the first and second sets of information <NUM>, <NUM>.

At step 2b, a second set of information <NUM> transmitted by the second device <NUM> includes the first user account identifier <NUM> received from the first device <NUM> in the NFC communication data exchange and second motion data (Device <NUM> Motion Data) <NUM> of the second device <NUM>. In some examples, the second set of information <NUM> can also include location data (e.g., GPS coordinates) of the second device <NUM>.

At step <NUM>, upon receipt of the first and second sets of information <NUM>, <NUM> from the first and second devices <NUM>, <NUM>, the device-to-device media capturing engine <NUM> detects the proximity of the first device <NUM> and the second device <NUM> to one another based on the media service identifiers received in the first and second sets of information <NUM>, <NUM>. For example, based on receiving the second user account identifier <NUM> associated with the second device <NUM> from the first device <NUM> and the first user account identifier <NUM> associated with the first device <NUM> from the second device <NUM>, a correlation between the first device and the second device <NUM> can be made that is indicative of the first device <NUM> and the second device <NUM> being proximate to one another. This correlation can be made given a known understanding that media service identifiers, such as user account identifiers, are exchanged between devices when the devices are proximate to one another.

Additionally or alternatively, location data of the first and second devices <NUM>, <NUM> included in the received first and second sets of information <NUM>, <NUM> can be utilized by the device-to-device media capturing engine <NUM> to detect and/or confirm the proximity of the first device <NUM> and the second device <NUM>.

Once the first device <NUM> and the second device <NUM> are determined to be proximate to one another, at step <NUM>, the device-to-device media capturing engine <NUM> determines the second device <NUM> is moving toward the first device <NUM> based on the first motion data <NUM> of the first device <NUM> and the second motion data <NUM> of the second device <NUM> received in the first and second sets of information <NUM>, <NUM>, respectively. For example, a comparison of the first motion data <NUM> and the second motion data <NUM> indicates that the first device <NUM> is relatively stationary or is at least moving towards the second device <NUM> at a lesser acceleration than an acceleration at which the second device <NUM> is moving toward the first device <NUM>. In some embodiments, the movement of the second device <NUM> toward the first device <NUM> and at a greater acceleration indicates a deliberate movement of the second device <NUM> by a user controlling that movement, which is indicative of the user's intent to capture the active media content item (e.g., Track B <NUM>) of the first device <NUM>. Resultantly, the device-to-device media capturing engine <NUM> determines the second device <NUM> is the receiving device that is capturing the active media content item.

At step <NUM>, the device-to-device media capturing engine <NUM> can then store an identifier for the active media content item (e.g., Track B ID <NUM>) in a library <NUM> for the second user account associated with the second device <NUM> that has been designated as the receiving device that is capturing the active media content item.

At step <NUM>, the device-to-device media capturing engine <NUM> provides a notification <NUM> to the second device <NUM> for display on the second device <NUM> at step <NUM>. The notification <NUM> includes an indication that the identifier for the active media content item has been stored in the library <NUM>. The notification <NUM> serves as positive feedback to a user of the second device <NUM> to confirm to the user that the media delivery system <NUM> has fulfilled the user's intent to capture the active media content item. Optionally, at step <NUM> and as described in more detail with reference to <FIG>, the second device <NUM> can begin immediate playback of the active media content item. In such examples, the media server application <NUM> can provide the active media content item to the second device <NUM> for playback. In some embodiments, if immediate playback occurs, the notification is not displayed and the playback itself serves as the positive feedback to the user of the second device <NUM>.

In further embodiments, a notification can also be provided to the first device <NUM> for display, where the notification indicates that the active media content item, Track B <NUM>, has been captured by another device, for example.

<FIG> illustrates a conceptual diagram <NUM> for a second configuration of a device-to-device media capturing system. As shown in diagram <NUM>, at least two media playback devices <NUM>, such as a first device <NUM> and a second device <NUM>, come into proximity of one another as the second device <NUM> is moved toward the first device <NUM> into very close or actual physical contact. The first device <NUM> is associated with an active media content item. For example, Track C <NUM> is next in queue for playing by the first device <NUM>. In some examples, the first device <NUM> or another peripheral device paired to the first device <NUM> visually displays information about the active media content item associated with the first device <NUM>. For example, at least a portion of the media content metadata <NUM> for Track C <NUM> stored in the media data store <NUM> is received and displayed, including a machine-readable code, cover art, and/or a text description, including information such as title, artist name, album name, length, genre, mood, or era. In some embodiments, when associated with the active content item, a module of the first device <NUM> is activated that awaits a proximity-based interaction with another device, such as second device <NUM>.

In this example, the first device <NUM> is a smartphone and the second device <NUM> is a wearable smart band, where both are NFC capable. As the second device <NUM> is moved toward the first device <NUM> and into a predefined NFC range of the first device <NUM> for a predefined time period (e.g., when the second device <NUM> taps the first device <NUM>), NFC communication is initiated to exchange data between the first device <NUM> and the second device <NUM> over one or more wireless communications (e.g., initiating performance of device-to-device media capturing process steps). As one example, at steps 1a and 1b, at least one media service identifier (MSID) of a user account associated with each of the first device <NUM> and the second device <NUM> is exchanged. One example type of MSID includes a device identifier. The device identifier can be a string of numbers and/or letters that identify a device having a known association with a user account of the media service. For example, at step 1a, a first device identifier (DID <NUM>) <NUM> for the first device <NUM> associated with a first user account is transmitted from the first device <NUM> to the second device <NUM> over a wireless communication. At step 1b, a second device identifier (DID <NUM>) <NUM> for the second device <NUM> associated with a second user account is transmitted from the second device <NUM> to the first device <NUM> over another wireless communication.

Upon exchange of the device identifiers <NUM>, <NUM>, the first device <NUM> and the second device <NUM> transmit sets of information <NUM>, <NUM> over the network <NUM> to the media delivery system <NUM> for use by the device-to-device media capturing engine <NUM> at steps 2a and 2b. Specifically, at step 2a, a first set of information <NUM> transmitted by the first device <NUM> includes the second device identifier <NUM> received from the second device <NUM> in the NFC communication data exchange and first motion data (Device <NUM> Motion Data) <NUM> of the first device <NUM>. In some examples, the first set of information <NUM> can also include location data (e.g., GPS coordinates) of the first device <NUM>.

In further examples, the first set of information <NUM> can also include an indication or identifier of the active media content item associated with the first device <NUM> (e.g., an identifier of Track C <NUM>). Additionally or alternatively, the device-to-device media capturing engine <NUM> receives the indication or identifier of the active media content item associated with the first device <NUM> from the media server application <NUM> based on playback state information maintained by the media server application <NUM> (e.g., stored in account data store <NUM>). For example, the device-to-device media capturing engine <NUM> can request playback state information of the first device <NUM> and/or second device <NUM> from the media server application <NUM> upon receipt of the first and second sets of information <NUM>, <NUM>.

At step 2b, a second set of information <NUM> transmitted by the second device <NUM> includes the first device identifier <NUM> received from the first device <NUM> in the NFC communication data exchange and second motion data (Device <NUM> Motion Data) <NUM> of the second device <NUM>. In some examples, the second set of information <NUM> can also include location data (e.g., GPS coordinates) of the second device <NUM>.

At step <NUM>, upon receipt of the first and second sets of information <NUM>, <NUM> from the first and second devices <NUM>, <NUM>, the device-to-device media capturing engine <NUM> detects the proximity of the first device <NUM> and the second device <NUM> to one another based on the media service identifiers, such as the device identifiers <NUM>, <NUM> received in the first and second sets of information <NUM>, <NUM>. For example, based on receiving the second device identifier <NUM> associated with the second device <NUM> from the first device <NUM> and the first device identifier <NUM> associated with the first device <NUM> from the second device <NUM>, a correlation between the first device and the second device <NUM> can be made that is indicative of the first device <NUM> and the second device <NUM> being proximate to one another. This correlation can be made given a known understanding that media service identifiers are exchanged between devices when the devices are proximate to one another.

Once the first device <NUM> and the second device <NUM> are determined to be proximate to one another, at step <NUM>, the device-to-device media capturing engine <NUM> determines the second device <NUM> is moving toward the first device <NUM> based on the first motion data <NUM> of the first device <NUM> and the second motion data <NUM> of the second device <NUM> received in the first and second sets of information <NUM>, <NUM>, respectively. For example, a comparison of the first motion data <NUM> and the second motion data <NUM> indicates that the first device <NUM> is relatively stationary or is at least moving towards the second device <NUM> at a lesser acceleration than an acceleration at which the second device <NUM> is moving toward the first device <NUM>. In some embodiments, the movement of the second device <NUM> toward the first device <NUM> and at a greater acceleration indicates a deliberate movement of the second device <NUM> by a user controlling that movement, which is indicative of the user's intent to capture the active media content item (e.g., Track C <NUM>) of the first device <NUM>. Resultantly, the device-to-device media capturing engine <NUM> determines the first device <NUM> as a transmitting device and the second device <NUM> as the receiving device that is capturing the active media content item.

At step <NUM>, the device-to-device media capturing engine <NUM> transmits an indication <NUM> over the network <NUM> to the first device <NUM> (e.g., the determined transmitting device). In some examples, the indication <NUM> prompts the first device <NUM> to transmit an identifier for the active media content item (e.g., Track C ID <NUM>) to the second device <NUM> (e.g., the determined receiving device) over a wireless communication, such as an NFC communication. At step <NUM>, the first device <NUM> transmits the Track C ID <NUM> in a wireless communication to the second device <NUM> responsive to the indication <NUM> received from the device-to-device media capturing engine <NUM>.

At step <NUM>, the second device <NUM> can then store the Track C ID <NUM> included in the communication transmitted by the first device <NUM> in a library for the second user account associated with the second device <NUM>. At step <NUM>, and as discussed in more detail with respect to <FIG>, the second device <NUM> can begin immediate playback of the active media content item and/or display a notification indicating that the identifier for the active media content item has been stored in the library. The immediate playback and/or notification serves as positive feedback to a user of the second device <NUM> to confirm to the user that the media delivery system <NUM> has fulfilled the user's intent to capture the active media content item. In some embodiments, if immediate playback occurs, the notification is not displayed and the playback itself serves as the positive feedback. In other embodiments, a notification can also be displayed on the first device <NUM>, where the notification indicates that the active media content item has been captured by the second device <NUM>.

<FIG> illustrates a conceptual diagram <NUM> for a third configuration of a device-to-device media capturing system. In this third configuration, each of the steps of the device-to-device media capturing process are being executed by one or more media playback devices <NUM> independently from the media delivery system <NUM> (e.g., utilizing instructions for the device-to-device media capturing engine <NUM> stored locally on the media playback devices <NUM> as described in <FIG>). As one illustrative scenario, this third configuration is implemented when at least one of the media playback device <NUM> is unable to connect to the media delivery system <NUM>.

As shown in diagram <NUM>, at least two media playback devices <NUM>, such as a first device <NUM> and a second device <NUM>, come into proximity of one another as the second device <NUM> is moved toward the first device <NUM> into very close or actual physical contact. The first device <NUM> is associated with an active media content item. For example, Track D <NUM> is currently being played by the first device <NUM>. In some examples, the first device <NUM> or another peripheral device paired to the first device <NUM> visually displays information about the active media content item associated with the first device <NUM>. For example, at least a portion of the media content metadata <NUM> for Track D <NUM> can be displayed, including a machine-readable code, cover art, and/or a text description, including information such as title, artist name, album name, length, genre, mood, or era. In some embodiments, the first device <NUM>, when associated with the active content item, can activate a module that awaits a proximity-based interaction with another device, such as second device <NUM>.

In this example, the first device <NUM> is a smart television and the second device <NUM> is a smartphone, where both are NFC capable. As the second device <NUM> is moved toward the first device <NUM> and into a predefined NFC range of the first device <NUM> for a predefined time period (e.g., as the second device <NUM> taps the first device <NUM>), NFC communication is initiated to exchange data between the first device <NUM> and the second device <NUM> over one or more wireless communications (e.g., initiating performance of device-to-device media capturing process steps).

As one example, at steps 1a and 1b, sets of information <NUM>, <NUM> are exchanged between the first and second devices <NUM>, <NUM>. Each of the sets of information <NUM>, <NUM> can include at least one media service identifier (MSID) of a user account associated with each of the first device <NUM> and the second device <NUM>. One example type of MSID includes a user identifier associated with a user account. A user identifier can be a string of numbers and/or letters that identify a particular user of one or more users associated with the user account of the media service. Each of the sets of information <NUM>, <NUM> can also include motion data associated with each of the first device <NUM> and the second device <NUM>. For example, at step 1a, a first user identifier (UID <NUM>) <NUM> for a first user account associated with the first device <NUM> and first motion data (Device <NUM> Motion Data) <NUM> of the first device <NUM> is transmitted from the first device <NUM> to the second device <NUM> over one or more wireless communications. At step 1b, a second user identifier (UID <NUM>) <NUM> for a second user account associated with the second device <NUM> and second motion data (Device <NUM> Motion Data) <NUM> of the second device <NUM> is transmitted from the second device <NUM> to the first device <NUM> over one or more other wireless communication.

Upon exchange of the sets of information <NUM>, <NUM>, the device-to-device media capturing engine <NUM> running locally on each of the first device <NUM> and the second device <NUM> detects the proximity of the first device <NUM> and the second device <NUM> to one another at steps 2a and 2b. Specifically, at step 2a the device-to-device media capturing engine <NUM> running locally on the first device <NUM> detects the proximity of the first device <NUM> and the second device <NUM>, and at step 2b the device-to-device media capturing engine <NUM> running locally on the second device <NUM> detects the proximity of the first device <NUM> and the second device <NUM>. In some embodiments, the device-to-device media capturing engine <NUM> is able to identify the other proximate device involved based on the media service identifiers, such as the user identifiers <NUM>, <NUM> received in the first and second sets of information <NUM>, <NUM>.

At steps 3a and 3b, the device-to-device media capturing engine <NUM> stored locally on each of the first and second devices <NUM>, <NUM> independently determines that the second device <NUM> is moving toward the first device <NUM> based on a comparison of the first motion data <NUM> of the first device <NUM> and the second motion data <NUM> of the second device <NUM>. Each of the first and second devices <NUM>, <NUM> has access to its own motion data, and then receives the motion data of the other device as part of the sets of information received.

In this example, a comparison of the first motion data <NUM> and the second motion data <NUM> indicates that the first device <NUM> is stationary and the second device <NUM> is moving toward the first device <NUM>. In some embodiments, the movement of the second device <NUM> toward the first device <NUM> indicates a deliberate movement of the second device <NUM> by a user controlling that movement, which is indicative of the user's intent to capture the active media content item (e.g., Track D <NUM>) of the first device <NUM>. Resultantly, the device-to-device media capturing engine <NUM> running locally on each of the first and second devices <NUM>, <NUM> independently designates the first device <NUM> as a transmitting device and the second device <NUM> as the receiving device that is capturing the active media content item.

At step <NUM>, the first device <NUM> based on its designation as the transmitting device transmits an identifier for the active media content item (e.g., Track D ID <NUM>) to the second device <NUM> designated as the receiving device over a wireless communication, such as an NFC communication. In some embodiments, the active media content item itself can also be transmitted.

At step <NUM>, the second device <NUM> can then store the Track D ID <NUM> included in the communication transmitted by the first device <NUM> in a library for the second user account associated with the second device <NUM>. At step <NUM>, and as described in more detail with reference to <FIG>, the second device <NUM> can begin immediate playback of the active media content item and/or display a notification indicating that the identifier for the active media content item has been stored in the library. The immediate playback and/or notification serves as positive feedback to a user of the second device <NUM> to confirm to the user that the user's intent to capture the active media content item has been fulfilled. In some embodiments, if immediate playback occurs, the notification is not displayed and the playback itself serves as the positive feedback.

In other embodiments, a notification can also be displayed on the first device <NUM>, where the notification indicates that the active media content item has been captured by the second device <NUM>.

The example configurations described above in <FIG> implement NFC technology as the proximity-based technology that triggers the device-to-device media capturing. Use of NFC technology (or RFID technology that similarly relies on electromagnetic signals) can be beneficial in that a closer proximity range is required to initiate the NFC communication and exchange of data. Based on the closer proximity range, a user is required to move their device in very close or actual physical contact with another device to trigger the device-to-device media capturing. This increases the probability that such a device movement by the user is indicative of the user's intent to trigger the device-to-device media capturing in order to capture an active media content item. However, NFC and RFID technologies are just a few, non-limiting examples of the types of proximity-based technology that can be implemented. Other examples include BLE or Wi-Fi technologies. For example, the at least two media playback devices <NUM> can establish BLE and Wi-Fi connections to enable exchange of communications using the respective protocols, where the communications include similar information included in the NFC communications described above. In further examples, the NFC or RFID technologies can be used to establish one or more of these other BLE or Wi-Fi connections.

<FIG> illustrates an example data structure <NUM> stored within one or more databases of the media delivery system <NUM> that facilitates the device-to-device media capturing. In other embodiments, the example data structure <NUM> or a portion thereof can be stored locally on each of the media playback devices <NUM>. In this embodiment, the data structure <NUM> is represented with a plurality of tables which identifies a rational nature of the one or more databases. However, in alternative embodiments, the data may be stored using other database models.

In the illustrated example, the data structure <NUM> includes a user account table <NUM>, a media context table <NUM>, and a media content item table <NUM>. For each user account, the data structure <NUM> includes a device data table <NUM>, a playback state table <NUM>, and at least one library table <NUM>. It is noted that, where user data is to be protected, the user data is handled according to robust privacy and data protection policies and technologies. For instance, whenever personally identifiable information and any other information associated with users is collected and stored, such information is managed and secured using security measures appropriate for the sensitivity of the data. Further, users can be provided with appropriate notice and control over how any such information is collected, shared, and used. In addition, the data contained in the data structure <NUM> is stored according to a defined security policy and in accordance with applicable regulations.

In some embodiments, the user account table <NUM>, the device data table <NUM>, the playback state table <NUM>, and the library table <NUM> are maintained within the account data store <NUM> of the media server application <NUM> of media delivery system <NUM>, while the media context table <NUM> and the media content item table <NUM> are maintained within the media data store <NUM> of the media delivery system <NUM>. In other embodiments, each of the tables may be maintained in a single database of the media delivery system <NUM>.

The user account table <NUM> can be configured to include data usable to identify users and accounts of those users of the media delivery system <NUM> (e.g., a media content provider or a media service). In some embodiments, the user account table <NUM> can reference one or more other tables, and/or be referenced by one or more other tables. Some embodiments of the user account table <NUM> can contain a field for user account identifiers (IDs) <NUM>, a field for user identifiers (IDs) <NUM>, a field for passwords <NUM>, and a field for subscription types <NUM>. The user account ID field identifies a plurality of user account IDs <NUM> associated with the user accounts of the media delivery system <NUM>. The user ID field identifies user IDs <NUM> associated with the one or more users of each of the user accounts. The user IDs <NUM> include names or other identification information that the users can use to identify themselves in the service provided by the media delivery system <NUM>. The user IDs <NUM> can be set up by the users or automatically assigned to the users. The password field stores data associated with passwords <NUM> of the users, such as hashed and salted passwords. The subscription type field identifies subscription types <NUM> associated with the user accounts. Examples of the subscription types <NUM> include a free subscription and a fee-based subscription with a single tier or with multiple tiers. Such a fee-based subscription can provide services that the free subscription does not provide.

Referring still to <FIG>, each user account that can be identified in the user account table <NUM> is associated with, and identifies, a set of data for providing various services from the media delivery system <NUM>. In some embodiments, such a set of data includes a device data table <NUM>, a playback state table <NUM>, and at least one library table <NUM>. In the illustrated example, the tables <NUM>, <NUM>, and <NUM> are primarily described to be associated with a single user account (e.g., User Account ID: ABC). However, it is understood that, in other embodiments, the tables <NUM>, <NUM>, and <NUM> can be structured to be associated with a plurality of user accounts.

The device data table <NUM> identifies one or more devices associated with a particular user account (e.g., User Account ID: ABC in <FIG>). In some embodiments, the device data table <NUM> can be referenced by the user account table <NUM>. Other tables can reference the device data table <NUM>. The device data table <NUM> can also reference one or more other tables. The device data table <NUM> can contain a field for device identifiers (IDs) <NUM>, a field for device names <NUM>, and a field for device status <NUM>. The device ID field includes one or more device IDs <NUM> of one or more media playback devices <NUM> that are associated with the particular user account. For example, User Account ID: ABC may include three different devices associated with the user account, where each of the three different devices includes a different device ID <NUM>.

In some embodiments, a plurality of media playback devices <NUM> can be respectively used to access media content service from the media delivery system <NUM> which is associated with a single user account. For example, a user can use different media playback devices <NUM> to log in to media content service with the user's user account information, and the media content service associated with the user account can be provided to one or more of the media playback devices <NUM> through which the user has logged in to the user account.

The device name field includes one or more device names <NUM> associated with the device IDs <NUM>. The device status field identifies a device status <NUM> for each of the media playback devices <NUM> identified in the device data table <NUM>. In some embodiments, the device status <NUM> can be either active or inactive. When the device status <NUM> of a media playback device <NUM> is active, the media playback device <NUM> is in operation and accessible by the media delivery system <NUM> via the network <NUM>. When the device status <NUM> of a media playback device <NUM> is inactive, the media playback device <NUM> is not in operation and thus inaccessible by the media delivery system <NUM> via the network <NUM>.

The playback state table <NUM> includes information about playback of one or more media contexts <NUM>. In some embodiments, where a plurality of media playback devices is used to play media content associated with a particular user account, only one of the plurality of media playback devices <NUM> can be used to play the media content while the other media playback devices may not be used to play the same media content simultaneously. In these embodiments, the playback state table <NUM> is configured to indicate playback information of the media content that is in common among the plurality of media playback devices associated with the particular user account. In other embodiments, the playback state table <NUM> is configured to indicate playback information for each of the media playback devices associated with the particular user account, where the media playback devices may be used independently to play media content in different manners.

In some embodiments, the playback state table <NUM> contains a current context <NUM>, a current media content item (i.e., a current track) <NUM>, a playback mode <NUM>, a playback speed <NUM>, a next media content item (i.e., a next track) <NUM>, and an elapsed playback time <NUM>. In addition or alternatively, the playback state table <NUM> can contain other playback-related information. In some embodiments, the playback state table <NUM> can reference one or more other tables, and/or be referenced by one or more other tables. The current context <NUM> indicates a media context <NUM> that is being currently played in a media playback device <NUM>. The current media content item <NUM> indicates a media content item <NUM> that is being currently played from the current context <NUM>. In some examples, the media content item being currently played back can be indicated by an identifier for the media content item <NUM>. The playback mode <NUM> indicates a playback mode that is currently selected. Examples of the playback mode include a normal playback mode, a repeat playback mode, and a shuffle playback mode. The playback speed <NUM> indicates a playback speed that is currently selected. Examples of the playback speed include a normal playback speed, one or more faster playback speeds, and one or more slower playback speeds. The next media content item <NUM> indicates a media content item that is in queue and will be subsequently played after the current media content item <NUM>. The elapsed playback time <NUM> indicates a time that a media content item has progressed for playback (e.g., a playback progress time). In some embodiments, the elapsed playback time <NUM> can include a remaining playback time which indicates a time that remains until the playback of a media content item is complete.

Referring still to <FIG>, the library table <NUM> represents liked media content items playlist. The liked media content items playlist includes a set of media content items <NUM> that either a user associated with user account ID: ABC manually liked or favorited through a user interface of one or more of their devices or the identifiers thereof were automatically captured via device-to-device media capturing as described herein (e.g., by the user moving one their devices in close proximity to another device on which the media content item is an active media content item).

Each row of the library table <NUM> represents a media content item from the set and includes data associated with one or more fields of the library table <NUM>. Exemplary fields include a media content item (e.g., track) ID field <NUM>, a device ID field <NUM>, a date field <NUM>, and a time field <NUM>. The media content item ID field <NUM> stores an identifier of the media content item that was manually liked/favorited or automatically captured through device-to-device media capturing. The device ID field <NUM> stores an identifier of the device that was used to manually like/favorite the media content item or automatically capture the media content item identifier through device-to-device media capturing. The date field <NUM> stores a date on which the media content item was manually liked/favorited or automatically captured through device-to-device media capturing. The time field <NUM> stores a time at which the media content item was manually liked/favorited or automatically captured through device-to-device media capturing. Other information related to each media content item in the set or details associated with a manner in which the media content item was captured for inclusion in the set (e.g., manual vs. automatic) can be included in the library table <NUM>.

With reference still to <FIG>, the media context table <NUM> is configured to identify one or more media contexts <NUM> as described with reference to <FIG>. As illustrated, some embodiments of the media context table <NUM> can respectively identify a media context <NUM> by a media context identifier <NUM>. The media context table <NUM> contains various pieces of information about a corresponding media context <NUM>. Examples of such information include a media context title <NUM>, a media context type <NUM>, a media context artist <NUM>, a media context genre <NUM>, and a list of media content items <NUM> associated with the media context <NUM>. Other information can also be included in the media context table <NUM>.

The media context title <NUM> indicates a title of the media context <NUM>. The media context type <NUM> indicates a type of the media context <NUM>, such as a playlist, an album, an artist, and a track. The media context artist <NUM> indicates one or more artists associated with the media context <NUM>. The media context genre <NUM> indicates a genre associated with the media context <NUM>. The list of media content items <NUM> indicates one or more media content items (i.e., tracks) associated with the media context <NUM>. Each of the media content items can be identified by a media content item (e.g., track) identifier <NUM>. In some embodiments, one or more of the media content items <NUM>, as described with reference to <FIG>, are identified by the list of media content items <NUM>.

The media content item table <NUM> is configured to identify one or more media content items (i.e., tracks) <NUM> by the track identifiers <NUM>. In some embodiments, one or more of the media content items <NUM> are selected from the media content items <NUM> as described with reference to <FIG>. For each media content item <NUM> identified by its respective track identifier <NUM>, the media content item table <NUM> can store at least a portion of the media content metadata <NUM> as described with reference to <FIG>. The media content metadata <NUM> can include various attributes of the media content item <NUM>. Example attributes included in the media content item table <NUM> can include a media content item title <NUM>, artist identification <NUM> (e.g., individual artist name or group name, or multiple artist names or group names), genre <NUM>, era <NUM>, and other attributes of the media content item.

<FIG> illustrates an example method <NUM> for determining movement of at least two media playback devices <NUM> relative to one another. In some embodiments, the method <NUM> can be used to at least partially perform the operation <NUM> described in <FIG>. The method <NUM> can be performed by the device-to-device media capturing engine <NUM> running on the media delivery system <NUM> as described in the first and second configurations of the device-to-device media capturing system in <FIG> and <FIG> respectively. Alternatively, the method <NUM> can be performed locally on the media playback devices <NUM> based on the instructions to operate the device-to-device media capturing engine <NUM> stored in the memory of the media playback devices <NUM> similar to the third configuration of device-to-device media capturing system described in <FIG>.

Returning to the example described in <FIG>, the first device <NUM> is playing track A <NUM> and the second device <NUM> is being moved by the user in proximity of the first device <NUM>. Following detection that the first device <NUM> and second device <NUM> are proximate to one another, the method <NUM> begins at operation <NUM> where a first acceleration of a first device that is associated with an active media content item (e.g., an acceleration of first device <NUM> playing track A <NUM>) is received. In some embodiments, the first acceleration is included in first motion data collected by the motion detector of the first device, such as the motion detector <NUM> described in <FIG>. In one example, the first acceleration included in the motion data is the acceleration of the first device at a time that the first and second devices came into very close or actual physical contact with one another.

At operation <NUM>, a second acceleration of a second device detected to be proximate to the first device (e.g., an acceleration of second device <NUM>) is received. In some embodiments, the second acceleration is included in second motion data collected by the motion detector of the second device. In one example, the second acceleration included in the motion data is the acceleration of the second device at a time that the first and second devices came into very close or actual physical contact with one another.

In one embodiment, each of first and second motion data including the first and second acceleration, respectively, are transmitted to the media delivery system <NUM> over the network <NUM> and received at the device-to-device media capturing engine <NUM> running on the media delivery system <NUM>. In another embodiment, the first device and the second device can exchange the first motion data and the second motion data with one another over one or more wireless communications. Accordingly, the device-to-device media capturing engine <NUM> running locally on the first device receives the first motion data from the motion detector of the first device and the second motion data from the wireless communication transmitted from the second device. Similarly, the device-to-device media capturing engine <NUM> running locally on the second device receives the second motion data from the motion detector of the second device and the first motion data from the wireless communication transmitted from the first device.

At operation <NUM>, the first acceleration and the second acceleration are compared. In some embodiments, the first and second accelerations are compared to determine whether one or both of the devices are moving and if so, a speed and direction in which the devices are moving relative to each other.

At operation <NUM>, a determination is made that the second device is moving towards the first device based on the comparison. For example, returning to the example presented in <FIG>, the comparison indicates that the first device <NUM> is stationary based on the first acceleration and the second device <NUM> is a device that is moving towards the first device <NUM> based on the second acceleration.

Based on the determined movement of the devices relative to one another, a further determination can be made as to which device is the device to receive an identifier of the active content item for storage in a library of a user account associated with the device (e.g., which device is the device capturing the active media content item). In one embodiment, the second device moving towards the first device as controlled by a user of the second device indicates that the user's intent was to capture the active media content item. Thus, the identifier is to be stored in a library of a user account associated with the second device.

In another embodiment, the second device moving towards the first device as controlled by a user of the second device can indicate the user is willing to share the active media content item with the first device (e.g., after a user of the first device indicates interests). Thus, the identifier is to be stored in a library of a user account associated with the first device.

In further embodiments, and as described in detail in <FIG> below, when an active media content item is associated with both devices, the difference between the first and second accelerations can be used to determine which of the devices, if any, is to receive the identifier of the active media content item associated with the other device.

<FIG> illustrates a conceptual diagram <NUM> for determining a media content item to be captured based on a movement of at least two devices relative to one another when each of the two devices are associated with an active media content item.

As illustrated in diagram <NUM>, media playback devices <NUM>, including a first device <NUM> and a second device <NUM>, are simultaneously moved toward one another into very close or actual physical contact (e.g., into proximity of one another). The first device <NUM> is a smartphone, for example, that is associated with a first user account of a media service. The first device <NUM> is also associated with a first active media content item (e.g., Track E <NUM>) provided by the media service. In some embodiments, due to the active media content item, a module of the first device <NUM> is activated that awaits a proximity-based interaction with another device. The second device <NUM> is a pair of smart headphones, for example, that is associated with a second user account of the media service. The second device <NUM> is also associated with a second active media content item (e.g., Track F <NUM>) provided by the media service. In some embodiments, due to the active media content item, a module of the second device <NUM> is activated that awaits a proximity-based interaction with another device.

Based on the proximity of the first device <NUM> and the second device <NUM>, device-to-device media capturing is triggered resulting in the provision and/or exchange of various data, including first motion data of the first device <NUM> and second motion data of the second device <NUM>. In some embodiments, the motion data includes an acceleration of each device. In one example, the acceleration included in the motion data is the acceleration at a time that the first device <NUM> and second device <NUM> came into very close or actual physical contact with one another.

As one illustrative example, the first motion data of the first device <NUM> indicates that the first device <NUM> had a first acceleration of x meters per second squared (m/s<NUM>) in a direction toward the second device <NUM>. The second motion data of the second device <NUM> indicates that the second device <NUM> had a second acceleration of y m/s<NUM> in a direction toward the first device <NUM>, where y is greater than x.

Based on the determined movement of both the devices relative to one another and the active media content item associated with each device, a further determination can be made as to which of the devices, if any, is to receive an identifier of the active content item of the other device for storage in a library of a user account associated with the device (e.g., which device is the device capturing the active media content item). In some embodiments, a device having a greater acceleration is determined to be the device capturing the active content item that will receive the identifier. Thus, in the example illustrated in <FIG>, the second device <NUM> having the greater acceleration of y m/s<NUM> is determined to be the device capturing the active media content item. As a result, an identifier for the first active media content item associated with the first device <NUM> (e.g., a Track E ID) is stored in a library of the second user account associated with second device <NUM>.

In other embodiments, the device having the greater acceleration is determined to be the device capturing the active content item when that acceleration is greater than an acceleration of the other device by a predefined threshold. In other words, the difference between the accelerations is greater than the predefined threshold. As a result, if the accelerations are about the same and thus the difference between them is not greater than the predefined threshold, in one example, neither device is determined to be the device capturing the active content item. That is, no device will receive the identifier. Thus, in the example illustrated in <FIG>, even though the second device <NUM> has the greater acceleration of y m/s<NUM>, if the difference between x and y is not greater than the threshold, the identifier for the first active media content item <NUM> associated with the first device <NUM> (e.g., a Track E ID) will not be stored in a library of the second user account associated with second device <NUM>. Similarly, an identifier for the second active media content item <NUM> associated with the second device <NUM> (e.g., a Track F ID) will not be stored in a library of the first user account associated with first device <NUM>.

In another example, if the accelerations are about the same and thus the difference between them is not greater than the predefined threshold, both devices can be determined to be the device capturing the active media content item. That is, both devices will receive the identifier for the active media content item associated with the other device. Thus, in the example illustrated in <FIG>, the identifier for the first active media content item associated with the first device <NUM> (e.g., a Track E ID) will be stored in a library of the second user account associated with second device <NUM>. Similarly, the identifier for the second active media content item associated with the second device <NUM> (e.g., a Track F ID) will be stored in a library of the first user account associated with first device <NUM>.

<FIG> illustrates an example notification <NUM> displayed on a device <NUM> to indicate storage of an active media content item identifier. In this example, the device <NUM> is associated with a user account of a media service. A user of the device <NUM> having the intent to capture an active media content item (e.g., Track G) associated with another device moves the device <NUM> into proximity with the other device. As a result of the detected proximity and determination that the device <NUM> is moving toward the other device, the device <NUM> is determined to be the device capturing the active media content item, and an identifier of the active media content item (e.g., Track G ID) is stored to a library of the user account associated with the device <NUM>. In some embodiments, upon storage of the identifier, the notification <NUM> is displayed on a user interface of the device <NUM> as a form of positive feedback to the user to indicate the storage of the active media content item identifier to the library. In some examples, the notification <NUM> can include a selectable option <NUM> to play the active media content item whose identifier was stored to the library. In other examples, at least a snippet of the active media content item is automatically played by the device <NUM> upon storage. In further examples, such automatic playback serves as the positive feedback to the user, and thus the notification <NUM> is not displayed when automatic playback occurs.

As illustrated, the notification <NUM> is a visual notification displayed on a user interface of the device <NUM>. In some examples, the notification <NUM> is a pop-up notification associated with an application running on the device <NUM> (e.g., an application associated with the media service). In other examples, the notification <NUM> can be provided as a message, such as an application message or an SMS (Short Message Service) message. In some embodiments, the notification <NUM> can be displayed on a different device than the device that was used to capture the active media content item (e.g., if the device used to capture the active media content item does not have a user interface). The different device is another device associated with the user account of the media service (e.g., determined based on user account data <NUM>). In further embodiments, the notification <NUM> can be an audio notification, such as a tone, alert, or speech.

<FIG> illustrates an example process flow diagram <NUM> for capturing an active media content item. In <FIG> and the corresponding description above, the at least two media playback devices participating in the device-to-device media capturing have been assumed to be capable of supporting the proximity-based technology that triggers the device-to-device media capturing process. For example, each of the media playback devices have been assumed to be NFC-capable (or alternatively RFID-capable, BLE-capable, and/or Wi-Fi capable). However, in some embodiments, at least one of the media playback devices may not have such capabilities. Therefore, <FIG> describes alternative operations that can be performed in such instances to enable capture of the active media content item.

Process flow diagram <NUM> begins at step <NUM>, where a second device is brought into proximity with a first device that is associated with an active media content item provided by a media service. In some examples, at least a portion of the media content metadata (e.g., media content metadata <NUM>) for the active media content item is received and displayed by the first device, including a machine-readable code, cover art, and/or a text description, including information such as title, artist name, album name, length, genre, mood, or era.

At step <NUM>, a decision is made whether both the first device and the second device are enhanced devices. Enhanced devices are devices capable of supporting a type of proximity-based technology being implemented to trigger the device-to-device media capturing, such as NFC. In other examples, the proximity-based technology implemented can be RFID, BLE, and/or Wi-Fi technologies. If both the first and second devices are NFC-capable for example, and thus enhanced devices, the process flow diagram <NUM> proceeds to step <NUM>, where the method <NUM> described with reference to <FIG> is performed. If one or both of the first and second devices are not NFC-capable for example, and thus are not enhanced devices, the process flow diagram <NUM> proceeds to step <NUM>. In other embodiments, dependent on the type of proximity-based technology implemented, the decision at step <NUM> can further include a determination of whether an associated network is active (e.g., online), where if the network is active, the process flow diagram <NUM> proceeds to step <NUM>, and otherwise the process flow diagram <NUM> proceeds to step <NUM>.

At step <NUM>, a capture, by the second device, of the machine-readable code for the active media content item displayed on the first device is detected. For example, the code is scanned or captured by a camera of the second device, where the code can be linked to or include an identifier for the active media content item. Based on the detected capture, the identifier for the active media content item can be automatically stored in a library of a user account of the media service associated with the second device at step <NUM>.

In some embodiments, after either step <NUM> or step <NUM> is performed, a further decision whether to playback the active media content item on the second device is made at step <NUM>. In some examples, the decision can be made based a plurality of factors. Example factors can include the following: predefined playback settings for the second device or the user account associated with the second device, whether another media content item is active on the second device, a time of day, a day of the week, and/or a location of the second device, among other examples. As one illustrative example, if it is a weekend afternoon and the second device is determined to be located at a gym, a decision is made to immediately playback the active media content item on the second device based on an assumption (given the factors) that the user of the second device would be interested in and able to listen now. As another illustrative example, if it is a weekday morning and the second device is determined to be located at a place of business, a decision is made to not playback the active media content item on the second device based on an assumption (given the factors) that it would not be appropriate for the user of the second device to listen now as they are likely at work and unable to do so.

Claim 1:
A method for device-to-device media capturing, the method comprising:
detecting that a first device and a second device are proximate to one another, wherein the first device is associated with a first user account of a media service and an active media content item provided by the media service, and the second device is associated with a second user account of the media service;
receiving, from the first device, first motion data associated with the first device;
receiving, from the second device, second motion data associated with the second device;
comparing the first motion data and the second motion data; and
based on the comparison, determining that the second device is moving toward the first device, wherein the first motion data includes a first acceleration of the first device and the second motion data includes a second acceleration of the second device, and the second acceleration is greater than the first acceleration; and
in response to detecting that the first device and the second device are proximate to one another and determining that the second device is moving toward the first device, storing an identifier of the active media content item to a library associated with the second user account.