Users have an ever-increasing selection of media content to choose from that is available for consumption, such as music, photographs, videos, and other media assets. Additionally, a typical user may have several different devices on which media assets can be consumed, such as a desktop computer, a laptop computer, and a smart phone, and each particular device can store a different collection of the various types of media assets. Thus, a user may have several different collections of media assets distributed over multiple different devices.
Situations can arise when a user wants to access a particular media asset that is stored on a device, but the user may not have immediate access to the device. For example, a user may be utilizing a smart phone at a location away from home and wants to play a song that is stored on a desktop computer at the user's home. Typical ways of locating and retrieving the song for playback on the smart phone can be cumbersome and require a large amount of bandwidth. Thus, the user may spend a great deal of time transferring a media asset from the desktop computer to the smart phone, or the user may simply forego retrieving the media asset.
This summary is provided to introduce simplified concepts of synchronized distributed media assets. The simplified concepts are further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.
Synchronized distributed media assets is described. In embodiments, a global media catalog of global metadata is maintained for media assets that are accessible by client devices registered to a user. The global metadata can correspond to instances of the media assets that are located remotely from one or more of the client devices. A client device can be registered to the user based on a user identifier associated with the global media catalog that is maintained at a remote location from the client device. Local metadata for local media assets that are stored on the client device can then be aggregated with the global metadata in the global media catalog. Additionally, the global metadata can be communicated from the global media catalog for receipt by the client devices that are registered to the user for aggregation into a local media catalog at each of the client devices. A client device can then initiate a request for a media asset that is identified by the global metadata and located remotely from the client device.
In other embodiments, user preferences can be detected on a client device that is associated with a user identifier. Entries from a global media catalog can then be located that correspond to the user preferences. The global media catalog can be associated with the user identifier and maintained by a resource remote from the client device. Media assets can then be received that correspond to the entries in the global media catalog and that are located based on the user preferences. The media assets can then be retrieved from a different client device that is associated with the user identifier.
Embodiments of synchronized distributed media assets are described with reference to the following drawings. The same numbers are used throughout the drawings to reference like features and components:
Embodiments of synchronized distributed media assets provide that a global media catalog is maintained that includes metadata for media assets stored on different devices that are associated with a particular user identifier. A user can utilize the user identifier to register a client device with the global media catalog. When registered, a local media catalog stored on the client device is synchronized with the global media catalog by aggregating metadata from the local media catalog into the global media catalog. Additionally, metadata from the global media catalog can be aggregated with the local media catalog at the client device to provide a catalog of metadata that describes media assets stored on the different devices that are associated with the user. The user can request, via the client device, a media asset that is stored on a different device. The media asset can be communicated (e.g., downloaded and/or uploaded) from the different device to a global media queue and made available to the client device (e.g., for download and/or streaming). Alternatively, the media asset can be communicated directly from the different devices to the requesting client device.
While features and concepts of the described systems and methods for synchronized distributed media assets can be implemented in any number of different environments, systems, and/or various configurations, embodiments of synchronized distributed media assets are described in the context of the following example systems and environments.
An example client device 108 is representative of the various client devices 104 that receive global media assets 110 when distributed from a global media queue 112 of the global media manager 102. In a media content distribution system, the global media manager 102 includes an identification manager 114 that facilities the registration of users and devices with the global media manager 102, as well as other authentication and verification tasks. In example implementations, an identifier, such as a user identifier, can be utilized to associate the client devices 104 with a particular user. Alternatively or in addition, the identifier can identify a particular client device and can be used to associate other client devices with the particular client device. In some implementations, a user can log on to the global media manager 102 via the client device 108, such as via a web page associated with the global media manager 102. When the user logs on to the global media manager 102, the global media manager can determine if one or more of the other client devices 104 are associated with the user and thus available for the retrieval of media assets for the user.
The global media manager 102 also includes a global media catalog 116 that maintains metadata for media assets that are stored by one or more of the client devices 104. Media content (e.g., to include recorded media content) can include media assets as any type of audio, video, and/or image data received from any media content and/or data source. Media assets can include, but are not limited to, television programs, movies, advertisements, music, video clips, interactive games, network-based applications, and any other content or data.
The communication network 106 can include any type of a data network, voice network, broadcast network, an IP-based network, and/or a wireless network 118 that facilitates communication of data and media content in any format. The communication network 106 can be implemented using any type of network topology and/or communication protocol, and can be represented or otherwise implemented as a combination of two or more networks. In addition, any one or more of the arrowed communication links facilitate two-way data communication.
The various client devices 104 in system 100 can be implemented as any one or combination of a wired and/or wireless device, as any form of computer device, portable computer device, consumer device, media device, communication device, video processing and/or rendering device, appliance device, electronic device, and/or as any other type of device that can be implemented to receive media content in any form of audio, video, and/or image data. A client device may also be associated with a user (i.e., a person) and/or an entity that operates the device such that a device describes logical devices that include users, software, firmware, and/or a combination of devices.
The example client device 108 is representative of the various client devices 104 that can implement embodiments of synchronized distributed media assets. Any of the devices described herein can be implemented with one or more processors, communication components, data inputs, memory components, processing and control circuits, and/or a media content rendering system. A device can also be implemented with any number and combination of differing components as described with reference to the example device shown in
In this example, client device 108 includes media content inputs 120 to receive global media assets 110 from global media queue 112. Alternatively or in addition, the media content inputs 120 can receive media content directly from a different client device of the client devices 104. The media content inputs 120 can include any type of communication interfaces and/or data inputs, such as Internet Protocol (IP) inputs over which streams of data can be received via an IP-based network. Client device 108 can be implemented with a device manager 122 that can include any one or combination of a control application, software application, processing and control module, code that is native to the particular device, and/or a hardware abstraction layer for the particular device.
In this example, the client device 108 also includes a local media manager 124 that is implemented to generate requests for global media assets 110 as well as receive requests for local media assets 126. In an implementation, the local media assets 126 can be communicated to the global media queue 112 and included in the global media assets 110. Alternatively or in addition, one or more of the media assets from the local media assets 126 can be made available for direct access by any of the various client devices 104.
Client device 108 also includes a local media catalog 128 that is implemented to store metadata related to the local media assets 126, as well as metadata from the global media catalog 116. The local media catalog 128 can be synchronized with the global media catalog 116 on a periodic basis and/or responsive to a change in the global media catalog 116. In an implementation, a user can request a media asset that is listed in the local media catalog 128 but that is stored remotely (e.g., on a different one of the various client devices 104). The request for the media asset is communicated by the local media manager 124 to the global media manager 102. The global media manager 102 then locates one of the client devices 104 on which the requested media asset is stored and requests the media asset. The media asset is then communicated to the global media queue 112 and stored as part of the global media assets 110.
In some implementations, the requested media asset can then be downloaded by the client device 108 from the global media queue 112 and included in the local media assets 126 for consumption (e.g., playback, use, etc.) on the client device 108. Alternatively or in addition, the requested media asset can be streamed from the global media queue 112 for consumption on the client device 108. The requested media asset can then be deleted from the global media queue 112, thus conserving storage space in the global media queue. In some implementations, the global media queue 112 is configured to store a requested media asset until the media asset is communicated to the client device 108 (e.g., via download, upload, and/or streaming), after which the media asset is deleted from the global media queue.
In an implementation, the global media manager 102 can receive a request from one of the client devices 104 other than client device 108 for a media asset that is stored on the client device 108. The requested media asset can be communicated from the client device 108 to the global media queue 112 and made available (e.g., via download and/or streaming) to the requesting client device.
In this example, the client device 108 also includes an asset monitor 130 that is implemented to track media asset use, consumption, and/or playback with respect to the client device 108. For example, the asset monitor 130 can track which instances of the local media assets 126 are played most frequently, as well as genres of media assets that are consumed on the client device 108 and/or requested by a user of the client device. A genre can include any appropriate way of categorizing media content and/or media assets. For example, music genres can include rock, pop, country, soul, world music, and so on. Video genres can include comedy, action, drama, and so on. Genres can also be user-specified, such as personal media content (e.g., family photos), business-related content, recreational content, and so on. The asset monitor 130 can store user asset interaction information as user preferences 132, which can be used to locate media assets that may be of interest to a user of the client device 108.
A calendar 134 is implemented to track events associated with the client device 108. For example, a user can record events (e.g., business meetings, social events, and so on) utilizing the calendar 134. The asset monitor 130 can access the calendar 134 and determine event information that may be utilized to locate appropriate media assets to be requested on the client device 108. In an implementation, events from the calendar 134 may be utilized along with the user preferences 132 to locate media assets for consumption on the client device 108.
Example methods 200-500 are described with reference to respective
The methods may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, computer-executable instructions may be located in both local and remote computer storage media, including memory storage devices. Further, the features described herein are platform-independent such that the techniques may be implemented on a variety of computing platforms having a variety of processors.
At block 202, a global media catalog is maintained of global metadata for media assets that are accessible by client devices that are registered to a user. For example, the global media catalog 116 maintains metadata for media assets that is stored on the client devices 104. Metadata can include information about media assets, such as song titles, video titles, genres, file sizes, digital rights management information, user identification information, and so on.
At block 204, a client device is registered to the user based on a user identifier associated with the global media catalog that is maintained remotely from the client device. For example, the client device 108 is registered with the global media manager 102, which provides the client device 108 with access to the global media catalog 116. At block 206, local metadata for local media assets that are stored in the client device is aggregated with the global metadata in the global media catalog. For example, metadata from the local media catalog 128 is aggregated with the global media catalog 116.
At block 208, the global metadata from the global media catalog is communicated for receipt by the client devices that are registered to the user. For example, metadata from the global media catalog 116 is communicated to the client device 108 and added to the local media catalog 128. Thus, the local media catalog 128 can include metadata for media assets that are stored on the client devices 104. The metadata can be utilized to create a list of media assets that can be requested via the client device 108.
At block 210, a request from the client device is received for a media asset that is identified by the global metadata and located remotely from the client device. For example, a user can request (e.g., via input to the client device 108) a media asset that is identified in the global media catalog 116 and stored in one of the other client devices 104. A user can initiate a request for a media asset with any type of user input from a list of media assets that is displayed at the client device 108.
At block 212, the requested media asset is communicated for receipt by the client device. For example, the media asset can be communicated from the one of the other client devices 104 and stored as part of the global media assets 110 in the global media queue 112. The client device 108 can then download the media asset from the global media queue 112. Alternatively or in addition, the media asset can be streamed from the global media manager 102 to the client device 108 for streaming consumption. In an implementation, when the media asset has been downloaded and/or streamed to the client device 108, the media asset can be deleted from the global media queue 112.
In various embodiments, a media asset can be stored in a format that may not be supported by a requesting device (e.g., one of the client devices 104). Example formats can include any type of file format, such as audio formats (e.g., WMA, WAV, MP3, OGG, and so on), video formats (e.g., MPEG, MOV, WAV, and so on), image formats (e.g., JPEG, BMP, TIFF, and so on), and/or any other format that can be utilized to encode and/or store the media asset. The media asset may then be converted to a different format before it is consumed on a device. In an implementation, the global media manager 102 can implement transcoding functionality that transcodes media content between different formats. When the global media manager 102 receives a media asset in response to a request for the media asset from the client device 108, the global media manager 102 can determine if the media asset is in a format that is supported by the client device 108. If the media asset is in a format that is not supported by the client device 108, the global media manager 102 can convert the media asset into a format that is supported by the client device 108.
Alternatively or in addition, the global media manager 102 can determine, prior to receiving a media asset, that the media asset is in a format that is not supported by the client device 108. The global media manager can then request that the media asset be transcoded into a format that is supported by the client device 108 before the media asset is communicated to the global media queue 112. Transcoding tasks can be performed by one or more of the client devices 104 that stores media assets and/or by the global media manager 102.
In some implementations, digital rights management (DRM) information can be considered before a media asset is uploaded to the global media queue 112 and/or made available for consumption on one or more of the client devices 104. For example, when a media asset is requested from the global media manager 102 by one of the client devices 104, the global media manager 102 can inspect metadata associated with the requested media asset for DRM information. If the metadata associated with the requested media asset includes DRM information, and the DRM information indicates that the media asset may be transferred to another device, the media asset can be communicated to the global media queue 112 and made available to the requesting device. Alternatively or in addition, information that is utilized to access a media asset can also be transferred with the media asset, such as a certificate, a password, a license, and so on.
Alternatively, if the DRM information indicates that the media asset may not be transferred (e.g., transfer of the media asset is not allowed under license terms), the global media manager 102 can communicate a notification to the requesting client device that the media asset is not available. Alternatively or in addition, the global media manager can determine if a different copy of the media asset is available that may be made available to the requesting device (e.g., a copy with DRM information that indicates that the media asset may be transferred to another device).
In various implementations, DRM information can be utilized to determine if a media asset is be listed in the global media catalog 116. For example, when the client device 108 is registered with the global media manager 114 and the local media catalog 128 is synchronized with the global media catalog 116, the global media manager can inspect metadata from the local media catalog 128 for DRM information. If the global media manager 102 detects DRM information that indicates that a particular media asset may not be transferred or performed on another device, the media asset may be omitted from the global media catalog 116. Accordingly, the global media catalog may be filtered to only include entries for instances of media assets having DRM information that indicates which of the media assets may be transferred to and/or consumed on other devices.
At block 302, an indication is received of a change to local metadata for local media assets that are stored on a client device. For example, a new media asset can be loaded onto the client device 108, and metadata for the new media asset can be added to the local media catalog 128.
At block 304, a global media catalog is updated based on the change to the local metadata. For example, periodic synchronization events can occur when new metadata in the local media catalog 128 is added to the global media catalog 116, and when new metadata in the global media catalog 116 is added to the local media catalog 128. Alternatively or in addition, the client device 108 can display a user interface that is populated with information from the global media catalog 116. Thus, in various embodiments, metadata from the global media catalog may not be stored on the client device 108, but rather, can be provided to the client device via a user interface, such as a web page that is associated with the global media manager 102.
At block 306, metadata associated with the change to the local metadata is communicated for receipt by an additional client device associated with the user identifier and remote from the client device. For example, new metadata in the local media catalog 128 can be communicated to update a local media catalog of a different one of the client devices 104. Thus, metadata synchronization can occur between the client device 108 and the global media manager 102, as well as between the various client devices 104.
At block 402, a request from a client device is received for a media asset that is located remotely from the client device. For example, a user of the client device 108 requests a media asset that is listed in the global media catalog 116 and stored at one of the other client devices 104. At block 404, the media asset is received and stored in a queue that is maintained remotely from the requesting client device. For example, the media asset is stored as part of the global media assets 110 in the global media queue 112.
At block 406, a determination is made as to whether the client device that requested the media asset is online. For example, the global media manager 102 can ping the client device 108 to determine if the client device 108 is online. If the client device that requested the media asset is not online (i.e., “no” from block 406), then at block 408 the media asset is held in the queue that is maintained remotely from the requesting client device. For example, the global media manager 102 determines that the client device 108 is not online (e.g., offline) and holds the media asset in the global media queue 112.
If the client device that requested the media asset is online (i.e., “yes” from block 406), then at block 410 the media asset is communicated for receipt by the requesting client device. For example, the media asset is communicated from the global media queue 112 to the local media assets 126. Alternatively or in addition, the media asset can be streamed from the global media queue 112 for consumption by the client device 108.
In various implementations, communication of media assets from one of the client devices 104 to the global media queue 112, and/or communication of media assets from the global media queue 112 to one of the client devices 104 can be scheduled based on bandwidth usage. For example, if a request for a media asset is made during a high bandwidth usage time (e.g., during the middle of the business day), communication of the requested media asset can be scheduled for a lower bandwidth usage time, such as early morning hours. The global media manager 102 can store the media asset in the global media queue 112 until bandwidth usage falls below a certain threshold, at which time the media asset is communicated to the client device 108.
At block 502, one or more user preferences and/or calendar events are detected on a first client device associated with a user identifier. For example, the user preferences 132 and/or one or more events from the calendar 134 are detected. The user preferences 132 can be automatically detected by the asset monitor 130 responsive to media asset interactions on the client device 108. Alternatively or in addition, a user can provide feedback related to the user's preferences, such as by expressly selecting particular genres and/or categories of media content.
At block 504, a request is initiated to locate one or more entries from a global media catalog that correspond to the one or more user preferences and/or the calendar events. For example, the local media manager 124 provides one or more of the user preferences 132 to the global media manager 102 with a request that one or more instances of media content (e.g., media assets) be located that correspond to the user preferences. The global media manager 102 can use metadata associated with the user preferences to locate one or more entries in the global media catalog 116 that correspond to the user preferences 132. For example, if the user preferences 132 indicate that the user often plays music from the hard rock genre, one or more entries from the global media catalog 116 can be located that correspond to the hard rock genre.
In an example implementation, calendar events from the calendar 134 can be utilized to locate media assets. For example, the user preferences 132 can indicate that during scheduled workout events indicated by the calendar 134, music from the pop rock genre is often consumed on the client device 108. When the calendar 134 indicates that at a time in the near future a workout is scheduled, the local media manager 124 can request that music from the pop rock genre be located in the local media catalog 128 and/or the global media catalog 116. The music from the pop rock genre can then be communicated for receipt by the client device 108 and/or made available for streaming to the client device 108 prior to and/or in time for the scheduled workout.
At block 506, one or more of the media assets are received that correspond to located entries in the global media catalog. For example, the media assets that are stored on one or more of the various client devices 104 are communicated to the global media queue 112 and made available to the client device 108.
At block 508, a request is received from an additional client device for one or more of the media assets that are stored on the first client device. For example, one of the client devices 104 requests one or more media assets from the global media manager 102. The global media manager 102 then determines that the requested media assets are stored on the client device 108 (e.g., as part of the local media assets 126). The global media manager 102 then communicates a request to the client device 108 (e.g., to the local media manager 124) for the media assets.
At block 510, the media assets that are stored on the first client device are communicated to a remote resource and made available to the second client device. For example, the media assets can be uploaded from the local media assets 126 to the global media queue 112. The media assets can then be communicated to the second client device, such as via download and/or for streaming consumption.
Device 600 includes communication devices 602 that enable wired and/or wireless communication of device data 604 (e.g., received data, data that is being received, data scheduled for broadcast, data packets of the data, etc.). The device data 604 or other device content can include configuration settings of the device, media content stored on the device, and/or information associated with a user of the device. Media content stored on device 600 can include any type of audio, video, and/or image data. Device 600 also includes one or more data inputs 606 via which any type of data, media content, and/or inputs can be received, such as user-selectable inputs, messages, music, television media content, recorded video content, and any other type of audio, video, and/or image data received from a content source and/or data source.
Device 600 also includes communication interfaces 608 that can be implemented as any one or more of a serial and/or parallel interface, a wireless interface, any type of network interface, a modem, and as any other type of communication interface. The communication interfaces 608 provide a connection and/or communication links between device 600 and a communication network by which other electronic, computing, and communication devices can communicate data with device 600.
Device 600 can include one or more processors 610 (e.g., any of microprocessors, controllers, and the like) which process various computer-executable instructions to control the operation of device 600 and to implement embodiments of synchronized distributed media assets. Alternatively or in addition, device 600 can be implemented with any one or combination of hardware, firmware, or fixed logic circuitry that is implemented in connection with processing and control circuits which are generally identified at 612. Although not shown, device 600 can include a system bus or data transfer system that couples the various components within the device. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures.
Device 600 can also include computer-readable media 614, such as one or more memory components, examples of which include random access memory (RAM), non-volatile memory (e.g., any one or more of a read-only memory (ROM), flash memory, EPROM, EEPROM, etc.), and a disk storage device. A disk storage device may be implemented as any type of magnetic or optical storage device, such as a hard disk drive, a recordable and/or rewriteable compact disc (CD), any type of a digital versatile disc (DVD), and the like. Device 600 can also include a mass storage media device 616.
Computer-readable media 614 provides data storage mechanisms to store the device data 604, as well as various device applications 618 and any other types of information and/or data related to operational aspects of device 600. For example, an operating system 620 can be maintained as a computer application with the computer-readable media 614 and executed on processors 610. The device applications 618 can include a device manager 622 (e.g., a control application, software application, signal processing and control module, code that is native to a particular device, a hardware abstraction layer for a particular device, etc.). The device applications 618 can also include any system components or modules of a local media manager 624 to implement embodiments of synchronized distributed media assets. In this example, the device applications 618 are shown as software modules and/or computer applications.
Device 600 can also include an audio and/or video input-output system 626 that provides audio data to an audio system 628 and/or provides video data to a display system 630. The audio system 628 and/or the display system 630 can include any devices that process, display, and/or otherwise render audio, video, and image data. Video signals and audio signals can be communicated from device 600 to an audio device and/or to a display device via an RF (radio frequency) link, S-video link, composite video link, component video link, DVI (digital video interface), analog audio connection, or other similar communication link. In an embodiment, audio system 628 and/or the display system 630 can be implemented as external components to device 600. Alternatively, the audio system 628 and/or the display system 630 can be implemented as integrated components of example device 600.
Although embodiments of synchronized distributed media assets have been described in language specific to features and/or methods, it is to be understood that the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as example implementations of synchronized distributed media assets.
Number | Name | Date | Kind |
---|---|---|---|
7475078 | Kiilerich et al. | Jan 2009 | B2 |
20030217077 | Schwartz et al. | Nov 2003 | A1 |
20040054931 | Himmel et al. | Mar 2004 | A1 |
20040068479 | Wolfson et al. | Apr 2004 | A1 |
20040117619 | Singer et al. | Jun 2004 | A1 |
20050060741 | Tsutsui et al. | Mar 2005 | A1 |
20050149340 | Murakami et al. | Jul 2005 | A1 |
20050165762 | Bishop | Jul 2005 | A1 |
20050182792 | Israel et al. | Aug 2005 | A1 |
20060143236 | Wu | Jun 2006 | A1 |
20060242259 | Vallabh et al. | Oct 2006 | A1 |
20060282856 | Errico et al. | Dec 2006 | A1 |
20070016695 | Rabbers et al. | Jan 2007 | A1 |
20070021997 | Hayes, Jr. et al. | Jan 2007 | A1 |
20070112687 | Read | May 2007 | A1 |
20070157222 | Cordray et al. | Jul 2007 | A1 |
20070174246 | Sigurdsson et al. | Jul 2007 | A1 |
20070233736 | Xiong et al. | Oct 2007 | A1 |
20070260989 | Vakil et al. | Nov 2007 | A1 |
20080016442 | Khoo | Jan 2008 | A1 |
20080021959 | Naghi et al. | Jan 2008 | A1 |
20080052371 | Partovi | Feb 2008 | A1 |
20080091717 | Garbow | Apr 2008 | A1 |
20080092168 | Logan | Apr 2008 | A1 |
20080114716 | Mock | May 2008 | A1 |
20080126476 | Nicholas | May 2008 | A1 |
20080154696 | Spiegelman et al. | Jun 2008 | A1 |
20080154959 | Dunko | Jun 2008 | A1 |
20080162510 | Baio et al. | Jul 2008 | A1 |
20080215568 | Yang et al. | Sep 2008 | A1 |
20080250312 | Curtis | Oct 2008 | A1 |
20080294607 | Partovi | Nov 2008 | A1 |
20080300944 | Surazski et al. | Dec 2008 | A1 |
20090006290 | Gunawardana | Jan 2009 | A1 |
20090006643 | Lee | Jan 2009 | A1 |
20090055377 | Hedge | Feb 2009 | A1 |
20090055759 | Svendsen | Feb 2009 | A1 |
20090063660 | Fleischman et al. | Mar 2009 | A1 |
20090069913 | Stefik | Mar 2009 | A1 |
20090083117 | Svendsen | Mar 2009 | A1 |
20090100018 | Roberts | Apr 2009 | A1 |
20090152349 | Bonev et al. | Jun 2009 | A1 |
20090178070 | Mitsuji et al. | Jul 2009 | A1 |
20090222522 | Heaney | Sep 2009 | A1 |
20090271417 | Toebes et al. | Oct 2009 | A1 |
20090271826 | Lee et al. | Oct 2009 | A1 |
20100169153 | Hwacinski et al. | Jul 2010 | A1 |
20100228591 | Therani et al. | Sep 2010 | A1 |
20100279708 | Lidsrom et al. | Nov 2010 | A1 |
20100324704 | Murphy et al. | Dec 2010 | A1 |
20100325205 | Murphy et al. | Dec 2010 | A1 |
Number | Date | Country |
---|---|---|
101099149 | Jan 2008 | CN |
03073292 | Sep 2003 | WO |
WO-2008124411 | Oct 2008 | WO |
Entry |
---|
Jesse Hollington, The Complete Guide to iTunes Movie Rentals, Part 1 (Updated), iLounge, Feb. 18, 2008. Retrieved on Apr. 11, 2013 from http://www.ilounge.com/index.php/articles/comments/the-complete-guide-to-itunes-movie-rentals-part-1/. |
“International Search Report”, Mailed Date: Jan. 6, 2011, Application No. PCT/US2010/038830, Filed Date: Jun. 16, 2010, pp. 7. |
“PCT Search Report and Written Opinion”, Application No. PCT/US2010/038839, (Jan. 28, 2011),8 pages. |
Seybold, Patty, “Synchronizing Your Life in Microsoft's Cloud”, Retrieved at <<http://outsideinnovation.blogs.com/pseybold/offlineonline—synchronization/>>, Apr. 29, 2008, pp. 1-2. |
Fiscus Vurbal, Rich, “Doubletwist Synchronizes Media Across Devices”, Retrieved at <<http://www.afterdawn.com/news/archive/12981.cfm>>, Feb. 19, 2008, pp. 1-4. |
“ZumoDrive”, Retrieved at <<http://zumodrive.com/>>, May 8, 2009, pp. 1-3. |
Kleiner, et al., “Secure and Privacy-Preserving DRM for Mobile Devices with Web Service Security—An Experience Report”, Retrieved at <<http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-362/space1.pdf>>, Intl Workshop on Trust in Mobile Environments, 2008, pp. 1-16. |
Mihovilovic, Domingo, “SugarSync Now allows you to Work Directly in Windows Explorer”, Retrieved at <<http://www.sugarsync.com/blog/2009/05/06/control-sugarsync-directly-in-windows-explorer/>>, May 8, 2009, pp. 1-6. |
“Gracenote Playlist”, Retrieved at <<http://www.gracenote.com/gn—products/onesheets/Gracenote—Playlist.pdf>>, Dec. 29, 2005, pp. 1-2. |
Liu, Kuanting et al., “Social Playlist: Enabling Touch Points and Enriching Ongoing Relationships through Collaborative Mobile Music Listening”, Retrieved from: http://delivery.acm.org/10.1145/1410000/1409299/p403-liu.pdf?key1=1409299&key2=7652061421&coll=GUIDE&dl=GUIDE&CFID=33445531&CFTOKEN=96193937., 4 Pages. |
French, James C., “Flycasting: On the Fly Broadcasting”, Retrieved from: http://www.ercim.org/publication/ws-proceedings/DelNoe02/JimFrench.pdf., 5 Pages. |
“Social Music: Top 5 Sites to Build a Playlist”, Retrieved from: http://mashable.com/2009/02/09/music-playlist/ on May 6, 2009., 36 Pages. |
Hakansson, Maria “Facilitating Mobile Music Sharing and Social Interaction with Push!Music”, Retrieved from: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04076547., 10 Pages. |
“ILike”, Retrieved from: http://www.techcrunch.com/tag/ilike/page/2/ on May 8, 2009., 12 Pages. |
Celma, Oscar “Foafing the Music: Bridging the Semantic Gap in Music Recommendation”, Retrieved from: http://iswc2006.semanticweb.org/items/swchallenge—celma.pdf., 8 Pages. |
Anglade, Amelie et al., “Complex-Network Theoretic Clustering for Identifying Groups of Similar Listeners in P2P Systems”, Retrieved from: http://delivery.acm.org/10.1145/1300000/1297239/p41-anglade.pdf?key1=1297239&key2=2457951421&coll=GUIDE&dl=GUIDE&CFID=34466622&CFTOKEN=18687506., 8 Pages. |
Slaney, Malcolm et al., “Similarity Based on Rating Data”, Retrieved from: http://ismir2007.ismir.net/proceedings/ISMIR2007—p479—slaney.pdf., 6 Pages. |
“Songkick Launches New Concert Recommendation Site”, Retrieved from: http://www.reuters.com/article/pressRelease/idUS44925+19-Mar-2008+BW20080319 on May 8, 2009., 3 Pages. |
“Final Office Action”, U.S. Appl. No. 12/486,580, (Apr. 13, 2011),13 pages. |
“Non-Final Office Action”, U.S. Appl. No. 12/486,580, (Jul. 18, 2011),14 pages. |
“Final Office Action”, U.S. Appl. No. 12/486,543, (Feb. 2, 2012),14 pages. |
“Final Office Action”, U.S. Appl. No. 12/486,580, (Jan. 5, 2012),18 pages. |
“Non-Final Office Action”, U.S. Appl. No. 12/486,543, (Oct. 28, 2011),14 pages. |
Sarwar, Badrul et al., “Item-Based Collaborative Filtering Recommendation Algorithms”, In Proceedings of WWW10, Available at <http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=53CDC5DC7FF8F88183770CD0C72DD017?doi=10.1.1.167.7612&rep=rep1&type=pdf>,(2001),11 pages. |
“Foreign Office Action”, Chinese Application No. 201080027699.0, (Sep. 5, 2012), 13 pages. |
“Foreign Office Action”, Chinese Application No. 201080027699.0, (Jan. 28, 2013), 12 pages. |
“Foreign Office Action”, Chinese Application No. 201080027700.X, (Nov. 19, 2012), 6 pages. |
“Non-Final Office Action”, U.S. Appl. No. 12/486,543, (Dec. 21, 2012), 15 pages. |
“Final Office Action”, U.S. Appl. No. 12/486,543, (Jul. 19, 2013), 15 pages. |
“Foreign Office Action”, Chinese Application No. 201080027699.0, (May 9, 2013), 12 pages. |
“Foreign Office Action”, Chinese Application No. 201080027700.X, (Jul. 10, 2013), 12 Pages. |
“Foreign Office Action”, Chinese Application No. 201080027700.X, Nov. 11, 2003, 9 Pages. |
Number | Date | Country | |
---|---|---|---|
20100325153 A1 | Dec 2010 | US |