Patent Application
20070226312
The present invention relates generally to web syndication. More particularly, the present invention relates to the updating of web syndication content at various control points.
This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
Web syndication is a form of syndication in which information from a website is made available for use by other sites or clients. “Web syndication” commonly refers to making Web feeds available from a site so that other visitors can get an updated list of content from it. For example, with web syndication a user can obtain an updated list of a person's blog postings using web syndication. Web syndication originated with news and blog sites, but it is increasingly being used to syndicate virtually any type of information.
Universal Plug and Play (UPnP) technology defines an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and personal computers of all types. UPnP technology is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public locations, or systems connected to the Internet. UPnP technology provides a distributed, open networking architecture that leverages TCP/IP and web technologies to enable seamless proximity networking, in addition to providing control and data transfer among networked devices. The UPnP audio/video transport defines how media devices such as servers, renderers and control points can communication with each other for the distribution and consumption of content.
Content directory service (CDS) metadata typically includes two variables of interest to web syndication and the present invention. The CDS, which is defined as part of the UPnP AV architecture, provides a set of functionalities which allow UPnP control points to access the content stored on media servers. A SystemUpdateID variable is defined in CDS v. 1.0 and 2.0. This required variable changes whenever anything in the Content Directory changes. A change could comprise, for example, a new or removed object, or a change in the metadata of an object. The actual value of the SystemUpdateID variable is unspecified. When using the SystemUpdateID variable, clients should only check for equality with previous values of SystemUpdateID.
A ContainerUpdateID variable is an optional state variable. This variable is an unordered comma separated value (CSV) list of ordered pairs. Each pair comprises a ContainerID and a ContainerUpdateID, in that order. Each time a container is modified, its ContainerUpdateID is incremented and the ordered pair of the ContainerID and the ContainerUpdateID are concatenated to the list of ContainerUpdateIDs. The ContainerUpdateID is a moderated and evented state variable and is only used for eventing; it does not comprise a history list of container changes. Home devices can make use of the existing evented variables (e.g., SystemUpdateID and ContainerUpdateIDs) and actions (e.g., browse or search) to perform a basic synchronization.
The consumption of media in UPnP AV environments can be quite slow due to the fact that a control point needs to search or browse the CDS metadata each time before the content can be played/rendered. The browse and search actions involve usually heavy network traffic. As a result, latencies can be observed at the user interface level, making the overall usability relatively poor. This situation can be improved by caching the CDS metadata in the control point, thus eliminating the need to perform the search and browse operations on the CDS. In this situation, each time the SystemUpdateID (and implicitly the ContainerUpdateID) changes, the control point will fetch the metadata pointed to by ContainerID and cache it locally, allowing the metadata cache to be in sync with the CDS metadata.
In a typical UPnP environment, there might be several control points interacting with a single media server, and these control points can have interactions with the CDS metadata by adding, updating or deleting media items. A sample environment is depicted in
The situation described above is particularly problematic for mobile UPnP devices such as mobile phones which, by their nature, regularly leave and join the home UPnP network. The UPnP AV does not have any provisions to help disconnected devices (depicted at 130 in
It would therefore be desirable to develop an improved system for updating CDS logs in UPnP environments.
The present invention involves the use of ATOM/really simple syndication (RSS) feeds as a change log for web syndication. According to the present invention, whenever the SystemUpdateID changes, the CDS logs the change as a new entry in the ATOM feed. The SystemUpdateID is checked by a control point whenever it joins the network. If the SystemUpdateID is different, the control point will promptly fetch the log (e.g., the ATOM feed), thereby eliminating the need to browse the entire CDS. Therefore, even though the entries in the ATOM feed are basically deltas of the changed metadata and may not have any meaning by themselves, they are used in the context of a synchronization application.
One embodiment of the present invention comprises a method, computer program product, and device for synchronizing a content directory service log on a UPnP AV server at a control point, comprising transmitting a HTTP GET request of a log feed to the UPnP AV server; receiving an ATOM feed including a predetermined number of most recent updates of the content directory service log; and updating a cache of the control point with updates from the ATOM feed as necessary. It is then determined if the oldest update in the ATOM feed is more recent than the time that the last synchronization occurred at the control point. If the oldest update in the feed is more recent than the time that the last synchronization occurred at the control point, a next ATOM feed of updates is retrieved. Subsequent ATOM feeds of updates are retrieved until synchronization is complete at the control point, after which a value indicative of a last synchronization time is updated.
Another embodiment of the present invention comprises a method, computer program product, and device for aiding a UPnP control point in synchronizing a content directory service log, comprising receiving a HTTP GET request of a log feed from the UPnP control point and transmitting an ATOM feed including a predetermined number of most recent updates of the content directory service log. After the UPnP control point has updated a cache of the control point with updates from the ATOM feed as necessary and determined that the oldest update in the ATOM feed is more recent than the time that the last synchronization occurred at the control point, a next ATOM feed of updates is transmitted. Subsequent ATOM feeds of updates are transmitted until synchronization is complete at the control point.
A further embodiment of the present invention comprises a system for synchronizing a content directory service log, comprising a UPnP control point and a UPnP AV server in at least selective communication with the UPnP control point. The UPnP control point is configured to transmit a HTTP GET request of a log feed to the UPnP AV server; receive an ATOM feed including a predetermined number of most recent updates of a content directory service log; and update a cache of the control point with updates from the ATOM feed as necessary. The UPnP control point is also configured to determine if the oldest update in the ATOM feed is more recent than the time that the last synchronization occurred at the control point. If the oldest update in the feed is more recent than the time that the last synchronization occurred at the control point, the UPnP control point retrieves a next ATOM feed of updates. Subsequent ATOM feeds of updates are retrieved until synchronization is complete at the control point, at which time the UPnP control point updates a value indicative of the last synchronization time.
The present invention possesses several notable advantages over conventional systems. With the present invention, the synchronization logic is implemented in the client device. Implementers can choose to implement the logic and decide whether to have advanced functionality or not, while keeping the device simple in nature. With the present invention, a client/control point manufacturer can use the synchronization logic as a product differentiator. Additionally, the server is stateless with regard to the control points with the present invention. The log is the same for all clients; they decide when to stop the synchronization process. Therefore, the server remains a simple device. Furthermore, synchronization can also be performed with non-UPnP devices. The present invention can also be easily implemented because ATOM is based on HTTP, and the HTTP stack already exists in UPnP devices. There is therefore no need for new components. With the present invention, a control point can even synchronize remotely, since the ATOM feed can be easily accessed for external networks. Lastly, change logs embodied as ATOM feeds can also be used in non-UPnP environments. The present invention can be incorporated into a wide variety of Digital Living Network Alliance (DLNA)-compliant products and can also be used by virtually any device that needs to synchronize CDS metadata on at least an occasional basis.
These and other advantages and features of the invention, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, wherein like elements have like numerals throughout the several drawings described below.
The present invention involves the use of ATOM/really simple syndication (RSS) feeds as a change log for web syndication. According to the present invention, whenever the SystemUpdateID changes, the CDS logs the change as a new entry in the ATOM feed. The SystemUpdateID is checked by a control point whenever it joins the network. If the SystemUpdateID is different, the control point will promptly fetch the log (e.g., the ATOM feed), thereby eliminating the need to browse the entire CDS. Therefore, even though the entries in the ATOM feed are basically deltas of the changed metadata and may not have any meaning by themselves, they are used in the context of a synchronization application.
ATOM is an XML-based document format that is often used for the syndication of web content, as well as an HTTP-based protocol for editing weblogs based on the format. ATOM is a newer and more advanced protocol than RSS. Apart from the basic web syndication and feeds that are also provided by RSS, ATOM supports more standardized meta-data information, along with the ability to make posts from an ATOM client to an ATOM server. This is in contrast to RSS, which only allows the client to obtain information from a server and not to post information.
One advantage to using ATOM as a CDS log is that the CDS already possesses the functionality of detecting when the metadata is changing. According to the present invention, whenever the SystemUpdateID changes, the CDS logs the change as a new entry in the ATOM feed. When implementing the present invention, the URL to the ATOM feed should be included in the description document of the media server/CDS being used. It is up to the media server implementation to decide when log entries should be removed.
In response to the receipt of this notification, at 240 the control point 200 transmits an HTTP GET request of the log feed to the ATOM server 210. At 245, the ATOM server 210 responds with an HTTP messaging requiring WSSE authorization (WSSE is a family of open security specifications for web services). The control point 200 therefore provides its credentials for authentication at 250 in a HTTP message. The credentials can be derived, for example, from UPnP security keys. If the control point 200 is authenticated (which occurs at 255), then the ATOM server 210 transmits the latest x elements of the log in an ATOM feed to the control point 200 at 260. This feed includes the next (older) x entries of the log in ATOM syndication format. x refers to a value which is dependent upon the implementation of the UPnP AV server 230. The feed also includes a URL (e.g., http://10.0.0.1/atom/2) to the next x changes that exist in the log, using the “Collection Paging”, as specified in the ATOM publishing protocol.
At 265, the control point 200 receives and parses the ATOM feed. From a “atom:updated” field of each entry in the field, the control point 200 identifies when each item was last updated. Comparing it with the time that last sync occurred, the control point decides if the cache needs to be updated with the metadata included in the feed. If necessary, the cache is updated.
At 270, the control point 200 checks whether the oldest update in the feed is younger (newer) than the time that the last synchronization occurred. If the oldest update in the feed is younger (newer) than the time that the last synchronization occurred, then the control point 200 requests the next log entries at 275, using a HTTP GET message and the “next” URL feed provided by the ATOM server 210. Subsequent feeds (e.g., http://10.0.0.1/atom/2, http://10.0.0.1/atom/3, etc.) are then provided as represented by a feedback loop 280. When all of the items have been synchronized (i.e., when the oldest update in the feed is not younger (newer) than the time that the last synchronization occurred), the control point 200 updates the time of last synchronization to reflect the current time at 285. The control point 200 then invokes other UPnP methods at 290 as is known in the art. This is accomplished as if the control point 200 had browsed the UPnP CDS 220 using UPnP CDS functions according to conventional methods.
The following is a full example of the computer code use to implement one embodiment of the present invention:
In the above code, the following lines of texts comprise “collection paging” links:
The line <title>My UPnP CDS updates</title> is the feed title. The line <updated>2006-02-13T18:30:02Z</updated> indicates the time that the feed was last updated. Each code group beginning with <entry> and ending with </entry> indicates an entry. Of this code, the code line beginning with <content> represents the link to content. This code has many alternative representations and are known to those skilled in the art. The code line beginning with <id> is the unique ID of the entry. The code line beginning with <updated> indicates the time that the entry was last modified. The code line beginning with <summary> comprises metadata.
It should be noted that the ATOM feed or other web syndication feed discussed herein can be used as a change log in other environments where lightweight metadata synchronization is needed (one way synchronization). Additionally, it should also be noted that the UPnP AV environment is just one example where the present invention can be implemented. In fact, the present invention can implemented in non-AV environments as well.
The mobile telephone 12 of
Communication devices of the present invention may communicate using various transmission technologies including, but not limited to, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Transmission Control Protocol/Internet Protocol (TCP/IP), Short Messaging Service (SMS), Multimedia Messaging Service (MMS), e-mail, Instant Messaging Service (IMS), Bluetooth, IEEE 802.11, etc. A communication device may communicate using various media including, but not limited to, radio, infrared, laser, cable connection, and the like.
The present invention is described in the general context of method steps, which may be implemented in one embodiment by a program product including computer-executable instructions, such as program code, executed by computers in networked environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.
Software and web implementations of the present invention could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps. It should also be noted that the words “component” and “module,” as used herein and in the claims, is intended to encompass implementations using one or more lines of software code, and/or hardware implementations, and/or equipment for receiving manual inputs.
The foregoing description of embodiments of the present invention have been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the present invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the present invention. The embodiments were chosen and described in order to explain the principles of the present invention and its practical application to enable one skilled in the art to utilize the present invention in various embodiments and with various modifications as are suited to the particular use contemplated.
