US20080130639A1 - Software update via peer-to-peer networks - Google Patents

Abstract

Providing a software update service involves discovering, via an ad-hoc peer-to-peer network, a peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network. The peer-to-peer software update service is offered by a peer device and facilitates updates of programs via the ad-hoc, peer-to-peer network. In response to discovering the peer-to-peer software update service, an update is selected that is applicable to a program of a first device of the ad-hoc peer-to-peer network. The update is sent to the first device and the program of the first device is modified using the update.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
• This is a continuation-in-part of application Ser. No. 11/633,756, entitled “Software Distribution Via Peer-To-Peer Networks”, filed on Dec. 5, 2006, which is assigned to the assignee of the instant application, the contents of which are incorporated herein by reference.
FIELD OF THE INVENTION
• This invention relates in general to computing devices, and more particularly to providing software update and configuration services via ad-hoc, peer-to-peer networks and online services.
BACKGROUND OF THE INVENTION
• Universal Plug and Play™ (UPnP) defines an architecture for pervasive, peer-to-peer networking between all types of consumer electronics, including intelligent appliances, wireless devices, and PCs of all form factors. UPnP technologies provide a way for disparate processing devices to exchange data via proximity or ad-hoc networks. The UPnP framework 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 spaces, or attached to the Internet. UPnP technologies provide a distributed, open networking architecture that leverages TCP/IP and the Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices.
• The UPnP Device Architecture (UDA) is designed to support zero-configuration, “invisible” networking, and automatic discovery for a breadth of device categories from a wide range of vendors. This means a device can dynamically join a network, obtain an IP address, convey its capabilities, and learn about the presence and capabilities of other devices. The UPnP specification includes standards for service discovery, and a number of particular device control protocols (DCP) are published by the UPnP Forum. These published DCPs standardize particular types of UPnP network functions. For example, some DCPs define functions used to render audio and video via a UPnP network. Various contributors can implement these and other UPnP device and service descriptions, thus creating a way to easily connect devices into a functioning network. It is the goal of UPnP to enable home electronics to seamlessly interact, thus furthering the usefulness of such devices.
• The UPnP standard includes standards for service discovery, and is mainly targeted for proximity or ad-hoc networks. Various contributors publish UPnP device and service descriptions, thus creating a way to easily connect devices and simplifying the implementation of networks. UPnP is designed to work in many environments, including the home, businesses, public spaces, and on devices attached to the Internet. The UPnP standard is an open architecture that leverages Web technologies and is designed to provide ad-hoc networking and distributed computing.
• UPnP and related protocols were developed primarily to allow consumers to easily assemble a home network, and to access and control devices not normally associated with networked computing. However, the flexible nature of UPnP means that it can be implemented anywhere, and can be adapted to uses not foreseen by the originators of the network framework. As peer-to-peer technologies such as UPnP become more ubiquitous, these technologies may be used for many other purposes besides facilitating control of diverse consumer devices. The present disclosure provides an example of such adaptations.
SUMMARY OF THE INVENTION
• To overcome limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present specification discloses a system, apparatus and method for configuring and updating software via a data processing apparatus of an ad-hoc, peer-to-peer network. In one embodiment of the invention, a method involves discovering, via an ad-hoc peer-to-peer network, a peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network. The peer-to-peer software update service is offered by a peer device and facilitates updates of programs via the ad-hoc, peer-to-peer network. In response to discovering the peer-to-peer software update service, an update is selected that is applicable to a program of a first device of the ad-hoc peer-to-peer network. The update is sent to the first device and the program of the first device is modified using the update.
• In more particular embodiments, the method may further involve sending, to the peer device, at least one query for a description of the peer-to-peer software update service in response to discovering the peer-to-peer software update service. A description of the peer-to-peer update service is received in response the query, and the update is selected based on the description. The at least one query may include a description of a computer platform of the target device used for filtering a result returned in response to the query and/or a software category used for filtering a result returned in response to the query.
• In other arrangements, the discovery of the peer-to-peer software update service and the selection of the update are performed by a second device of the ad-hoc, peer-to-peer network, and the second device initiates sending of the update to the first device and modifying of the program of the first device using the update. The ad-hoc, peer-to-peer network may include a Universal Plug and Play network.
• In other, more particular embodiments, modifying the program on the first device may involve adding a capability to the program. In such a case, adding the capability involves adding the capability for the program to access a service of the ad-hoc, peer-to-peer network. In such an arrangement, selection of the update may be initiated by the first device in response to the first device detecting the service being advertised on the ad-hoc peer-to-peer network.
• In other, more particular embodiments, modifying the program on the first device involves reconfiguring the program. In another example, modifying the program involves modifying the program to receive a handover of a data session currently being conducted by a second device on the ad-hoc peer-to-peer network. In such a case, modifying the program may involve a) providing parameters of the data session to the program of the first device, b) adding a capability to the program that enables the program to engage in the data session, and/or c) updating a presence of the user by one of the first and second devices based on the handover of the data session.
• In another embodiment of the invention, a method, involves advertising, via a peer device coupled to an ad-hoc, peer to peer network, a peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network. The peer-to-peer software update service facilitates updating of programs to other entities of the ad-hoc peer-to-peer network. The peer device receives at least one query for a description of the peer-to-peer software update service. In response to the at least one query, transmission of an update to a target device is facilitated via the peer-to-peer software update service. The update is used to modify a program on the target device.
• In more particular embodiments, the method involves monitoring an external network update service that is independent of the ad-hoc peer to peer network and configuring the peer device to provide updates of the external network update service via the peer-to-peer software update service. The method may further involve forwarding discovery from the peer-to-peer to software update service to an external repository service outside the ad-hoc, peer to peer network. The ad-hoc, peer-to-peer network may include a Universal Plug and Play network. The at least one query may includes a) a description of a computer platform of the target device used for filtering a result returned in response to the query and/or b) a software category used for filtering a result returned in response to the query.
• In another embodiment of the invention, an apparatus includes a network interface capable of communicating via an ad-hoc peer-to-peer network and a processor coupled to the network interface. A peer-to-peer software update service is offered by a peer device and facilitates updating programs via the ad-hoc peer-to-peer network. A memory storage device is coupled to the processor and includes instructions that cause the processor to: a) discover the peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network; b) select an update that is compatible with a target program in response to the discovery of the peer-to-peer software update service; c) facilitate sending the update to a device of the ad-hoc peer-to-peer network that executes the target program; and d) facilitate modifying the target program using the update.
• In more particular embodiments, the apparatus is the device that executes the target program. In other particular embodiments, the instructions further cause the processor to advertise, via the service discovery protocol, a locally provided peer-to-peer software update service that facilitates updating programs via the ad-hoc, peer-to-peer network, and facilitate transferring a second update to a target device via the locally provided peer-to-peer software update service, wherein the second update is used to modify a program of the target device. In such a case, the instructions may further cause the processor to monitor an external network update service that is independent of the ad-hoc peer-to-peer network and offer updates of the external network update service via the locally provided peer-to-peer software update service.
• In more particular embodiments, the target program is capable of engaging in user-interactive data sessions, and modifying the target program involves modifying the program to receive a handover of a data session currently being conducted by a second device on the ad-hoc peer-to-peer network.
• In another embodiment of the invention, a computer-readable storage medium has instructions which are executable by an apparatus capable of being coupled to an ad-hoc peer-to-peer network. A peer-to-peer software update service is offered by a peer device and facilitates updates of programs via the ad-hoc, peer-to-peer network. The instructions are executable by the apparatus for performing steps that include a) discovering a peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network; b) selecting, in response to discovering the peer-to-peer software update service, an update that is applicable to a target program; c) facilitate sending the update to a device of the ad-hoc peer-to-peer network that executes the target program; and d) facilitate modifying the target program using the update.
• In more particular embodiments, the steps further include e) offering a locally provided peer-to-peer software update service that facilitates updating of programs via the ad-hoc, peer to peer network; f) advertising the locally provided, peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network; g) facilitating transmission of a second update to a target device via the peer-to-peer software update service in response to advertising the locally provided, peer-to-peer software update service.
• In another embodiment of the invention, a system includes means for advertising a peer-to-peer software update service via a service discovery protocol of an ad-hoc peer-to-peer network. The generic peer-to-peer software update service facilitates peers of the network to update programs of the peers. The system further includes means for discovering the peer-to-peer software update service via the ad-hoc peer to peer network, means for facilitating transmission of an update to a peer device via the peer-to-peer software update service, and means for modifying a program of the peer device using the update.
• In more particular embodiments, the system further includes means for monitoring an external network update service that is independent of the ad-hoc peer-to-peer network and means for offering updates of the external network update service via the peer-to-peer software update service. The system may further include means for modifying the program of the peer device using the update to receive a handover of a data session currently being conducted by another device on the ad-hoc peer-to-peer network. In such a case, the system may include means for updating a presence of a user of the peer device based on the handover of the data session. In another more particular embodiment the system further includes means for forwarding discovery from the peer-to-peer to software update service to an external repository service outside the ad-hoc, peer to peer network.
• These and various other advantages and features of novelty which characterize the invention are pointed out with particularity in the claims annexed hereto and form a part hereof. However, for a better understanding of the invention, its advantages, and the objects obtained by its use, reference should be made to the drawings which form a further part hereof, and to accompanying descriptive matter, in which there are illustrated and described representative examples of systems, apparatuses, and methods in accordance with the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
• The invention is described in connection with the embodiments illustrated in the following diagrams.
• FIG. 1 is a block diagram illustrating a system according to embodiments of the invention;
• FIG. 2 is a block diagram illustrating an implementation of a software update service according to embodiments of the invention;
• FIG. 3 is a block diagram illustrating a UPnP software update and configuration architecture according to embodiments of the invention;
• FIG. 4 is a sequence diagram of a session handover facilitated by an update service according to an embodiment of the invention;
• FIG. 5 is a block diagram of a mobile device according to embodiments of the invention;
• FIG. 6 is a flowchart illustrating a procedure for accessing a software update service via ad-hoc, peer-to-peer networks according to embodiments of the invention;
• FIG. 7 is a flowchart illustrating a procedure for providing a software update service via ad-hoc, peer-to-peer networks according to embodiments of the invention; and
• FIG. 8 is a flowchart illustrating a procedure for handing over a data session via a software update service of an ad-hoc, peer-to-peer networks according to embodiments of the invention.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
• In the following description of various exemplary embodiments, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized, as structural and operational changes may be made without departing from the scope of the present invention.
• Generally, the present invention relates to methods, systems, and apparatus that enable software to be configured and/or updated via ad-hoc, peer-to-peer networks or online software repository service. Such networks are considered to be “ad-hoc” because the network may be automatically self-formed by peer nodes that discover each other's existence and capabilities automatically. Each peer may be willing to forward data (and provide other peer-to-peer services) for other peers, and so the determination of which nodes provide a particular service is made dynamically based on the network connectivity. This is in contrast to older network technologies in which some designated nodes, usually with custom infrastructure hardware (e.g., servers, routers, hubs, firewalls, and switches) perform designated tasks or services. Minimal configuration and quick deployment make ad hoc networks suitable for emergency situations like emergencies, where some infrastructure elements may not be relied upon. Such ad-hoc networks are also useful in consumer environments, because they free the consumer from having to understand and configure the function of various infrastructure devices.
• An example of ad-hoc, peer-to-peer protocols are those protocols used in the UPnP architecture. UPnP uses the Simple Service Discovery Protocol (SSDP) for service discovery, and is generally built on top of Internet Protocol (IP) based networks. Although concepts of the present invention may be described in terms of UPnP networks, those familiar with the applicable art will appreciate that these concepts may be applied to any manner of ad-hoc, peer-to-peer networking arrangement suitable for consumer or business networks. For example, the Service Location Protocol (SLP), Zeroconf, and Jini™ are protocols that provide functions similar to those of UPnP.
• The UPnP framework includes several layers that cover the addressing, discovering, and control functions associated with connecting to and using services of the network. The UPnP Device Architecture (UDA) consists of the layer that takes care of the basic addressing and networking functionality. On top of the Device Architecture, UPnP define additional services such as audio-video (AV), Remote User Interface (UI), Printing, etc.
• UPnP is designed to be flexible, and as a result UPnP applications are constantly evolving. This evolution occurs at all levels, from the low-level network protocols and interfaces to the high-level applications that utilize UPnP. An example of a low-level network update includes updating the UDA and UPnP services by adding support for newer network protocols such as IPv6. Another network update may include updating the Web service protocols upon which discovery and other functions are based. An example of a high level service that may be changed (which may still require changes be made to the UDA) is making a transition from printing service to enhanced printing service.
• As UPnP and its related standards evolve, a device may need to update a protocol, service, UDA, or other software in order to interoperate with other devices. Currently, the UPnP framework has no automatic way of doing this. The user has to manually install the new version of the software or service into the device. Without such capability, the UPnP framework may fall short of its promise of providing a seamless and automatic way for devices to interoperate. This is particularly true for devices and services that do not have a substantial user interface, such as special purpose consumer devices (e.g., appliances, control modules). In such a case, updating the software may require physically accessing the device and using a non-UPnP interface to do the update (e.g., by connecting the device to a computer with a cable and updating the device via a specialized update program).
• Existing device software may be updated and/or reconfigured for such purposes as fixing bugs and improving performance. It may also be desirable to extend the functionality of devices to provide a service for which the device was not originally provisioned. In particular, such extensions are particularly useful if they can be provided on demand, such as when a user or other network device advertises or attempts to use the service. For example, a sizeable number of users depend on on-line services, like Instant Messaging (IM), email, web access, etc. Currently the online sessions of the Internet capable devices are limited to one device per session and there is no way to move the session from device to another without breaking the online connection. If the end user wants to move the session to another device (e.g. current IM chatting session from mobile device to personal computer) the session must be closed and started again using another device. It would be beneficial for the end user if the online session (like chatting session in IM client) could be transparently moved from the device to another without interruption in online session.
• However, current UPnP implementations lack a mechanism for handing over presence to mobile device when user moves away with it from a personal computer (PC), and restoring the presence back to the PC when the user returns. This applies also to other services and protocols, like games, browsing sessions, etc. The presence and session control of the online application must be transferred manually. For example, when the end user wants to change the session from a PC IM application to a mobile IM application, the user must first manually set the PC status to “offline,” and then set it to “online” from the mobile client.
• The present disclosure describes an adaptation to ad-hoc, peer-to-peer, local networking technologies such as UPnP that allow devices to automatically update software and software configurations, regardless of the diversity of target devices and the diverse methodologies chosen by device vendors and/or software maintainers to obtain apply updates. Like other UPnP interfaces, a standardized UPnP software configuration/update interface can become a commonly accessible service on the network usable by any type of device, regardless of vendor, operating platform, and proprietary update methodologies. These adaptations to UPnP (or any other ad-hoc, peer-to-peer framework) may also be used for dynamic device update and configuration.
• A new UPnP DCP may be defined for these automatic update and dynamic configuration functions. This new DCP may enable applications with equivalent functionalities to configure each other dynamically. The automatic update and dynamic configuration may be implemented as UPnP upgrade/configuration service that will be discoverable as any of the existing services. Thus, for example, when a user receives an error indicating the device does not support the service the user was trying to access, the user or the device automatically can search for the UPnP upgrade service and initiate the automatic update of the UPnP UDA or services.
• The “update” and/or “configuration” of software may involve any combination of discovery, transmission, verification, installation, purchase, activation, and maintenance of processor executable instructions between two or more computing arrangements. The software may include any type of system or user software that can be executed on a data processing device. One example of such software is a game that is made available for download via a distribution service of the peer-to-peer network. Such a game may also utilize the peer-to-peer network to advertise the use of the game, updates that enable a device to participate in the game, and/or to use the network to exchange game play data. Although various embodiments shown herein may be described in terms of various specific types of software such as games, it will be appreciated that the invention is not so limited, and may be applied to any manner of computer-assisted activities known in the art.
• In a system according to an embodiment of the invention, a generic software update and configuration service may be discovered and utilized via a single generic interface. In some scenarios, the updates and/or configurations may be made available to assist a device to access another service on the peer-to-peer network. For example, a peer device may discover a multiplayer game that is advertised via the discovery protocols of the network. The multiplayer game may use the peer-to-peer network for both discovery and game play events. In order to play the game, the user device may discover and/or be automatically directed to a software distribution service that enables compatible software to be installed on the user device. Alternatively, if the device was already configured to play the game, but detects a new version is in use, the user device may discover and/or be automatically directed to a software update service that enables the needed upgrades to be installed on the user device. In this way, the user can seamlessly utilize theretofore unknown and uninstalled capabilities that arise on the peer-to-peer network, and seamlessly maintain those capabilities even when versions used by other devices change.
• In one arrangement, the ad-hoc, peer-to-peer network that enables the software distribution service may be a Universal Plug and Play (UPnP) network. The UPnP framework includes two layers: a general-purpose UPnP device architecture (UDA) and device-specific device control protocols (DCP). There are currently about ten standardized DCPs for various device categories. Software distribution via UPnP may involve creating a generic framework that enables users to search any available programs, such that the search would not be tied to any particular software type, device platform, licensing scheme or other categories typically associated with software distribution. A software update and configuration DCP may be created that would define the services, actions and state variables that a “UPnP software update and configuration device” would expose to the UPnP network.
• In reference now toFIG. 1, a block diagram100 illustrates an example system according to embodiments of the invention. Generally, technologies such as UPnP are designed for operating within a limited space. InFIG. 1, a physical boundary defines alocal space102. The dimensions of thelocal space102 are generally confined by the underlying network protocols and media, as well as the scalability of the ad-hoc, peer-to-peer networking technologies used to facilitate software distribution. However, it will be appreciated that other ad-hoc, peer-to-peer protocols may not be limited to any physical space limitations, and so the illustration of thelocal space102 is for purposes of illustration, and not of limitation.
• Thespace102 may include at least onelocal network104 that is capable of supporting communications with one ormore user devices106. Thelocal network104 may include any combination of data transmission media and protocols. For example, thenetwork104 may utilize wired or wireless data transmission media. Similarly,devices106 on thelocal network104 may various physical and data link layer protocols to intercommunicate, including, Ethernet, FDDI, PPP, ATM, HDLC, Fibre Channel, X-10, serial/parallel point-to-point connections, etc. A number of higher layer network protocols may operate on thenetwork104 as well, including TCP/IP, UDP/IP, IPX, Appletalk, ICMP, ARP, SNMP, DNS, FTP, SMB, NetBEUI, etc.
• Theuser devices106 generally include some manner of data processing capabilities, and in particular at least some of thedevices106 are capable of obtaining and running software via thenetwork104. In most installations, this software includes user or system programs that are capable of running ondevices106 having general-purpose data processing capabilities.Such devices106 usually include sufficient memory (e.g., random access memory) to load in new programs that selectably alter the behavior of the device.Such devices106 generally include (or at least have access to) some type of persistent data storage (e.g., hard disk, flash memory) that allow thedevices106 to retain changed or added software after the cycling of power.
• Although the concepts described herein may be usefully applied to general-purpose computing devices, the invention need not be limited such devices. For example, thedevices106 may include an embeddedsystem device107, which is a limited-purpose data processing arrangement that is not, in general, extendable by the addition of new programs. However, the existing specific-purpose program contained in the embeddedsystem107 may be updated, modified, or replaced by a peer-to-peer software distribution service as described herein. For example, the embeddedsystem107 may include a “smart” UPnP appliance that performs a single function via thenetwork104.Such device107 may be upgradeable (e.g., to enhance the specific function or fix bugs) by modifying flash memory that contains the operating instructions of thedevice107. In such an arrangement, thedevice107 may include instructions that allow it to utilize a UPnP software distribution service for obtaining and applying flash memory upgrades without requiring user intervention.
• In the illustrated diagram100, othernetworkable devices106 include agaming console108,mobile phone109,laptop computer110, personaldigital assistant112,portable music player114,tablet computer116,personal computer117,entertainment center120, or any other device as represented by genericdata processing device118. Because protocols such are UPnP are applicable to a wide variety of consumer electronics, consumer electronics devices such as theentertainment center120 may include peer-to-peer network functionality. In some configurations, theconsumer electronics device120, like the embeddedsystem107, may have fixed functionality, such as being only capable of rendering sound or video. For example, such capabilities may be included in a flash memory program of thedevice120, and thus are relatively fixed for the life of thedevice120. In other arrangements, however, thedevice120 may include general-purpose computer capabilities such as access to random access memory (RAM) and/or persistent storage, and as such may be able to add new programs to extend the device's capability. In either arrangement, thedevice120 may be adaptable to use or provide some or all of the software distribution services described herein.
• Preferably, thenetwork104 and its underlying protocols are designed to be generic and flexible so that many types of control or data processing functionality can be abstracted and offered as a service to other entities on thenetwork104. In one embodiment, thelocal network104 may support one or more protocols for ad-hoc, peer-to-peer service discovery and interoperability. Thelocal network104 may be designed to service a limited physical region, as indicated by theboundary102. The protocols used in such a local network104 (e.g., UPnP) often assume that thenetwork104 will need to support only a limited number of devices operating within a reasonably small area. However, many devices on thelocal network104 may benefit from information services available via an external network, particularly theInternet126. The UPnP specification defines a special service/function known as an Internet Gateway Device (IGD)128. TheIGD function128 can be provided by one or more of thedevices106 for purposes of provide routing and firewall services on behalf of others of thedevices106 of thelocal UPnP network104. In some arrangements, a dedicated gateway device may perform the IGD functions128 on theUPnP network104, as well as providing traditional gateway/router functions for non-UPnP devices.
• In one embodiment of the invention, one or more of theuser devices106 have specializedcomponents130 that enable thedevices106 to distribute software programs and updates at least via thelocal network104. Thiscomponent130 may be referred to alternately as a device or a service. In the UPnP specifications, the concept of a “device” is a logical abstraction that does not necessarily have a one-to-one correspondence to a single piece of physical hardware. The software distribution device/service130 may be hosted by one or more of thenetwork devices106 and be advertised132 according to service discovery protocols of the local peer-to-peer network104. For example, devices on a UPnP network advertise via SSDP, which uses XML UDP unicast and multicast packets to advertise132 services. In response to theadvertisement132, adevice118 may initiate further negotiations (e.g., queries) to discover particulars about theservice130. Assuming thedevice118 is willing and able to utilize thesoftware distribution service130, the device can request134 a software distribution function via theservice130.
• One software distribution function that may be requested134 by the device is adownload136. In the illustrated environment, thedownload136 may involve data transfer directly from theservice130 to thedevice118. In another example, adownload138 may be facilitated by theservice130, but thedata transfer138 occurs from anotherdevice117 in thelocal network104. Thedevice117 from which thedownload138 originates may or may not be capable of communicating using the formats and protocols of theservice130. For example, thedevice117 may be in a sleep mode, and the service/device130 acts as a proxy that processes queries and other transactions, but causes thedownload138 to originate from thedevice117 after causing thedevice117 to wake up. In another example, thedevice117 may use an “out-of-band”mechanism to transfer data. As used herein, the term “out-of-band” generally refers to the use of one or more protocols that are not part of the protocols of the ad-hoc peer-to-peer network104. For example, although both File Transfer Protocol (FTP) and UPnP may work on top of TCP/IP networks, a simple host-to-host FTP file transfer may be considered out-of-band because such a transfer, by itself, does not utilize the UPnP protocol stack. Conversely, “in-band” mechanisms use at least a minimum set of the protocols defined fordevices106 to engage in ad-hoc, peer-to-peer interactions via thenetwork104.
• In another arrangement, adownload140 may originate from an outside network such as theInternet126, and may be facilitated by one or more local components, including thesoftware distribution service130 and theIGD128. Where the download originates from outside the network, anentity142 providing thedownload140 may not appear as a logical device on thelocal network104. In one arrangement, a device such as theIGD128 may act as a proxy for the software downloads, so that it appears that theIGD128 is providing the download, even though the data originates from anexternal entity142. Theexternal entity142 may include a single server or multiple, distributed hosts that provide a partial download using peer-to-peer technologies such as BitTorrent and Gnutella.Local entities130,117 may also participate in similar distributed software distribution.
• It will be appreciated that in alternate arrangements, thelocal service130 may act as a proxy for theexternal entity142. In such an arrangement, the external entity generates itsown advertisement141, which may be broadcast, multicast, or unicast to the service130 (e.g., by way of the IGD128). Thisadvertisement141 may be provided directly to the network by way of theIGD128, or as illustrated, combined with the advertisements of the local update/distribution service130. Similarly requests/queries134 of thelocal network104 may be sent directly to theexternal service142, such as directly via theIGD128, or indirectly by way of thelocal service130, which then forwards arequest143 to the external service. In this way, the system enables forwarding discovery from the peer-to-peer tosoftware update service130 and/or thelocal network104 to anexternal repository service142 outside the ad-hoc, peer to peernetwork104. Thereafter, services such as downloading136,140 can be utilized as described elsewhere herein.
• Downloading is only one example of a software distribution function that may be facilitated by the device/service130. Other functions are illustrated as the setup/configure/activatefunction144. Thesefunctions144 may include any actions other than downloading that cause the instructions to operate correctly on a particular device. For example, configuration may include adding and modifying files or other data to the target device. This configuration data may be used by an installer program, be read from and written to by programs to maintain states, used to store log data, etc. Thefunctions144 may also involve placing of files and other persistent objects in the correct places of a file system hierarchy, patching of binaries, activation of protected/encrypted code, making system file/registry changes, communication with existing software components, etc. Theservice130 may directly perform thefunction144, or may facilitate functions between theclient118 and another entity. An example of this is the illustratedactivation146, which performed via anentity142 that is outside the local environment102 (e.g. in an online software repository service).
• In other situations, setup, configuration and/or update data may also originate from theexternal entity142. Theexternal entity142 may be, for example, a software update server of a device manufacturer or other entity. Examples of these types of Internet-basedupdate facilities142 include automatic updates facilities included in operating systems such as Windows™ and Linux™, and automatic virus definition updates used by virus scanning programs. It should be noted that these update features are typically limited to updating specific components, and are not generally applicable to a wide range of consumer device. For example, even though the Windows Update™ feature automatically detects and downloads upgrades to the operating system, by default it does not download updates to the application programs, even those of the same vendor. Moreover, the upgrades can be updates in specific functionality of an applications, such as new UPnP actions on an existing service like schedule recording, printing or the basic connectivity in the device architecture (DA). Similarly, although a Linux distribution such as Ubuntu may automatically detect and apply updates to the OS and application programs, these updates are limited to those programs supported by the distribution. In these cases, independent application developers must provide alternate update mechanisms to ensure their products get updated.
• In contrast to updates on personal computers, the illustratedservice130 may be generally applicable to provide updates to any device on thenetwork104. Proprietary update mechanisms implemented on individuallocal devices106 may be extended to include a UPnP update interface. Similar adaptations can be made forexternal update sites142. Even thoughexternal update sites142 may have custom or proprietary interfaces, theservice130 may be made modular, so that a manufacturer can install a plug-in so that any updates offered by specializedexternal update servers142 can applied via a common UPnP interface locally. Theupdate service130 itself may be automatically updateable to add these extensions, such as by the use of plug-ins that can extend the functionality of existing programs. So if a user adds a new device to thenetwork104, the new device can register with theupdate service130, theupdate service130 can automatically discover any extensions needed to interface with theremote server142 and apply those extensions. Thereafter theservice130 can ensure that the new device is kept up to date, and can also be used to extend the functionality of the new device if such new functionality is requested and the device is so capable.
• Note that theupdate service130 may be able to automatically cache update and configuration data and redistribute updates as necessary, thus reducing bandwidth at theexternal server142. Such caching is particularly useful where a single update or configuration is applicable to a number of devices. In some cases, a home network may include a number of identical devices, such as electrical controllers for lights, alarm systems, monitoring systems, etc. In other cases, different devices may support a common software component. For example, many devices may support running platform independent program modules (e.g., Java Applets or Midlets) and some functions, such as time synchronization or power management, may be common to different types of devices. These components can be added and updated by using objects cached by theservice130.
• It will be appreciated that the illustratedsystem100 holds many advantages over traditional ways of distributing and maintaining software. In typical systems, the user must first have knowledge of the particular software, find the downloads of the software for a particular computing platform, and install the software. Where the software involves interaction with other people or devices (e.g., in a UPnP environment) the user may also have to seek out a device, user, or community in which to engage in the software activity. However, in a system according to embodiments of the invention, the existence of the target activity and the existence of other people and devices that are willing to engage in the activity may be determined by just performing service discovery via the ad-hoc networks. In many situations, the users may be unable to engage in the targeted activity without additional software. In such a case, the software that facilitates the activity could be automatically downloaded on a trial or permanent basis from others in the local environment or elsewhere. This allows users to be more discerning about which software that they wish to install on their system. The decisions may therefore be based on the actual usage of such activities in environments frequented by the user, rather than based on possibly outdated or inaccurate data obtained via public forums such as the Web.
• In reference now toFIG. 2, a more detailed example is presented of how updates and configurations can be facilitated in accordance with embodiments of the invention. Twomobile terminals202,204 are coupled via an ad-hoc, peer-to-peer network206. In this example,mobile terminal202 includes a control point/client208 and a terminal204 includes anupdate server210 that may be configured to update and/or configure software onmobile terminals202,204, or any other device of thenetwork206. It will be appreciated that bothterminals202,204 may contain any combination of respective control point/client208 andserver components210, although in this example only the illustratedcomponents208,210 are being utilized onrespective terminals202,204. In this scenario, the terminal204 may be acting as a UPnP device that is offering itsupdate services210 to other UPnP devices on thenetwork206. As such, the terminal204 may provide an eXtensible Markup Language (XML)device description212 in response to queries received via thenetwork206.
• Theexample device description212 includes variables that describe the device itself, such as thedevice type214. This implementation defines new UPnP DCP definition for a UPnP Software configurationDCP root device214 and may include optional embedded devices. Generally, a UPnP device may also provide one or more services, and the illustrateddevice description212 shows anexample UPnP SWConfigurationService216. Theservice216 may be associated with anaction218, GetDeviceType. GetDeviceType returns the type of the device, which can be, for example, mobile phone, PC, PDA, television etc. Devices may use this information for determining which device has higher priority. Generally, to ensure compatibility across platforms and systems, thedevice214,service216, andaction218 may be defined as a minimum mandatory requirement for any device providing this type ofnetwork function210.
• The device type used with theGetDeviceType action218 may also include a descriptor of the device platform. As is known in the art, a “computing platform” is sometimes defined as the combination of central processing unit (CPU) and operating system (OS) used by a device. For example, an Intel® x86 compatible CPU may run different OSes, such as Windows®, Linux®, OS X®, Free BSD, etc. Although all programs that run natively on an x86 CPU will use the same instruction set, the programs need particular arrangements of instructions and data in order to be compatible with a particular OS. In some cases, a program may even rely on a particular patch level of the OS, and will not run correctly on incompatible patch levels. Similarly, the Linux OS has been compiled to run on a wide variety of different CPUs. However, a program compiled for Linux x86, for example, will have to be recompiled to run on a different CPU, e.g., PowerPC.
• A number of adaptations have been created to ease the problem of using software on incompatible platforms. In some arrangements, an emulation program creates a virtual processor and OS that allows a program to run even if it was compiled for a different OS and CPU, albeit with significant performance degradation. Other adaptations, such as the Wine Project, allow programs that are compiled for a particular CPU to run in a different operating system on the same CPU. These adaptations emulate the application program interface (API) of another operating system, but because the program was compiled for the same CPU type, the program instructions can still be run natively on the CPU without any translation. Still other adaptations involve distributing programs that do not utilize CPU specific instructions at all. One form of these adaptations are scripting languages such as Perl, Python, Basic, etc., which utilize programs written in ASCII text, and the text is converted to machine language “on-the-fly” at run-time. Other adaptations, such as Java™ or Microsoft™ .NET, use binary programs that are designed to run in platform independent runtime environments. Programs compatible with the run-time environment can be compiled once and thereafter run on any platform that has the run-time environment installed.
• It will be appreciated that thedirectory service216 may have to take into account the platform of the requesting device when processing directory requests. Even when the programs are platform independent (e.g., Java) there may be version incompatibilities that require considering the particular runtime environments of the requestingdevice208. Other issues that thedirectory service216 may need to take into account when distributing software include the capacity of the requestingterminal202,204 (e.g., memory, processor speed, graphics capability, required user input devices), licensing issues, software categories, content restrictions (e.g., parental controls, corporate IT policies), other software versions (e.g., UPnP version, UPnP DA, UPnP service version), OS patch level, etc. In response to various combinations of such criteria, thesoftware configuration device214 can provide a list of available updates that satisfy the criteria. The list could be “flat,” or be arranged in a hierarchy. Theclient device202 may utilize acontrol point208 that is specially adapted for controlling thesoftware configuration device214, as well as any other embedded devices and associated services. Each embedded device may also have own control point for controlling other similar applications.
• Theupdate server210 may be hosted in any home device, and the hostingapparatus204 may store new software data that is transferred to other devices in order to perform upgrades. Theserver210 can store the new software data in anupgrade repository219 that is locally situated, either within theapparatus204 or elsewhere on thelocal network206. In another arrangement, therepository219 may be part of an external source, such as a manufacturer's site where the updates are stored for generic, public download. The client device/control point208 will interact with theupgrade server210 and will check the list of services and available versions (e.g., version of UPnP Device Architecture) and will compare them with the ones existing in thedevice202. If there is a difference in the versioning number of theservice210, theclient208 will initiate the upgrade.
• Theclient208 may identify updates automatically or at the prompting of a user. For example, theclient208 may query anylocal update services210 at a predetermined interval, such as once per day. In another scenario, theclient208 may determine that updates or upgrades are needed when the user first tries to use an unavailable or non-activated service on theapparatus202. This scenario is shown inscreen222, which is an example display of a video player application. The user has attempted to play a video on theapparatus202, but the player does not have the needed codec to process a particular video file or stream. Thescreen222 includes a prompt221 that requests whether the user wishes to attempt an update. Assuming the user answers in the affirmative, the control point/client208 may access one ormore update servers210 to obtain the upgrade. In turn, theservice210 may access one ormore upgrade repositories219 to find the needed update. If available updates are found, the user may be notified, such as viascreen222. If multiple compatible updates are found, the user may have the option of selecting one based on factors such as trust placed in the offer/offeror, cost, perceived quality, licensing, location/bandwidth, etc.
• Assuming the appropriate update is available, theserver210 will facilitate transferring update data to the terminal202 (such as via a separate download manager), thereby enabling the selected update to be installed. Theserver210 may be configured to facilitate downloads of configurations and/or executable images, either from the terminal204 itself or from a third party. For example, theserver210 may provide authentication that allows theother terminal202 to access a Web download site and obtain an update or configuration.
• In more particular examples of downloads, the servingterminal204 has the needed update files stored in the device's local file system. Theserver210 provides a link to the installation files (e.g., a Uniform Resource Identifier, or URI) and receivingclient208 can download the files using a UPnP content directory service DCP. In another example, the servingterminal204 has a lightweight run-time object (Java or web browser scripts) stored in the terminal's file system. Theserver210 provides an HTTP link to the run-time files, and receivingclient208 can download them using a UPnP content directory service DCP. In another example,server210 provides an Internet HTTP URI to the update files to theclient208, and thedevice202 can download them using suitable program.
• It will be appreciated that, in the example scenario described above, software updates can be distributed rather widely and easily. However, software vendors may be concerned about distributing updates to users who may not have obtained the software legally. In other cases, software contains digital rights managements (DRM) feature that prevent software modifications under certain circumstances. Thus theupdate service210 may be required to process certain software updates differently, depending on the licensing and/or DRM associated with the software and/or restrictions place on the vendors. For some software distribution scenarios, such as Open Source software, freely distributing copies of the program is an acceptable use under the Open Source license, and thus updates are also typically freely distributable. However, most proprietary models of software distribution require that at least some of the end users purchase software. In some cases, the vendor may want to validate whether the target program was obtained legally before an update is given out. In other cases, the vendor may want to limit third-party modifications to a program, such as programs that illicitly enable certain features by modifying binary executables.
• Implementing rights management into a software distribution service may address concerns related to illegal distribution of some types of software. Another concern that may need to be addressed in implementing the distribution service is that of security. For example, certain types of software (often referred to as “malware”) may become installed unintentionally on a user device. In some cases, malware may consume resources for unwelcome or nefarious purposes, intentionally damage data and/or hardware, attempt to access and divulge private data, etc. In order to prevent the spread of malicious or unwanted software, the underlying platform may implement security measures, such as only allowing digitally signed and authenticated software to be installed. Theupgrade server210 may include security features to ensure updates are authenticated and validated. The updates and configurations may be secured using security mechanisms of the local network, e.g., UPnP security mechanisms. In other arrangements, independent verification and authentication may be performed, such as by using pre/shared certificates to authenticate thedevice208 and anyservers210 that provide the updates Security measures may be implemented in both theserver210 and/orclient208. For example, the system may require that any software be authenticated by a trusted source before theclient machine202 installs it. In other cases, a user interface of thecontrol point208 may require user confirmation before any software is installed.
• Thedevice description212 may include specific services related to both security and rights management. Similarly, the client/control point208 may include provisions to ensure anydistribution server210 is to be trusted. For example, transactions with theserver210 may involve exchanging authentication keys that can be independently verified. An a priori configuration (e.g., shared encryption key, manual authorization) may also be used, although such a priori configurations are typically less user-friendly than an automated authentication from a trusted verification source.
• The systems described herein may be implemented using any combination of networking technologies known in the art. In particular, network updates may be implemented using the UPnP framework. In reference now toFIG. 3, a block diagram300 illustrates an example implementation of a UPnP update and configuration architecture according to an embodiment of the invention. The diagram300 includes twocompatible peer devices302,304 that may interact via aUPnP network306. Thedevices302,304 typically represent separate hardware components; however there may be some arrangements where thedevices302,304 are virtual devices that share hardware with each other and with other components of thenetwork306.
• As illustrated, thedevice302,304 may contain compatiblefunctional components308,310,312,314,338,340,342,344 that allow eachdevice302,304 to facilitate software update and configuration for others (e.g., act as a server) and find/use updates and configurations for itself (e.g., act as a client). It will be appreciated that it is not necessary for thedevices302,304 to each include all of the listed functionality to form a usable system. For example, some devices may be configured to act only as clients, such as by disabling update server functionality or by not having such functionality installed to begin with. Similarly, the functional components may be distributed across multiple physical devices yet operate in an integrated fashion as if on a single device. For example,peer device302 may be comprised of a handheld game controller acting as theUPnP control point338, and this controller communicates via Bluetooth with a cellular phone acting as aUPnP client340.
• Functional components308,310,312,314 ofpeer device304 will be described in greater detail below. It will be appreciated that the same functionality may also be provided byanalogous components338,340,342,344 ofdevice302. Thedevice304 includes a UPnP softwareupdate control point308, a UPnPsoftware update client310, and a UPnPsoftware update server312. Each of thecomponents308,310,312 are configured to communicate via UPnP protocols, and as such will implement the UPnP Device Architecture (UDA). Also associated with thesecomponents308,310,312 is a UPnP software update device control protocol (DCP) that defines the actions and state variables of the various interactions betweencomponents308,310,312.
• The UPnP softwaredistribution control point308 may provide functions similar to other UPnP control points, such as the UPnP audio video (AV) control point. Generally, thecontrol point308 includes the user interface and application logic that allows a user to discover the services of other software update devices on theUPnP network306. The UPnPupdate control point308 may also provide other control functions for activities associated with finding, selecting, buying, downloading, configuring, and/or running updates. Thecontrol point308 can invoke the UPnP software update DCP to perform these actions in order to get a desired response. In some applications, it is desirable to hide the UPnP functionality from the user as much as possible. In such a case, thecontrol point308 may only provide minimal user interface functions, such as reporting critical errors, or requiring confirmation of updates as required by security policy settings.
• The softwareupdate client device310 is a UPnP device that provides UPnP interface for connecting to software update servers. Theclient device310 may operate in response to operations of thecontrol point308, other user interface devices, or in response to other, non-user initiated events. Generally, theclient device310 interacts withsoftware update servers312,342 to at least initiate downloads of update data, and may also handle the other actions such as configuration and activation needed to apply those updates.
• The UPnPsoftware distribution server312 acts as a central point for accessingspecific updates314 that are available via thedevice304. More specifically, theserver312 is a UPnP device with the “software update” service exposing the available updates314. Theserver device312 may also handle the actions and maintain the state variables associated with installing theupdates314. Theserver device312 may use a registry or some other mechanism for tracking and categorizingvarious updates314 that are available via thepeer device304. Generally, those updates may be applied toprograms317. Theprograms317 may include UPnP-capable and non-UPnP-capable programs. Where theprograms317 are UPnP-capable, the distribution of theupdates314 can be integrated with the discovery of UPnP services, including UPnP services hosted by adevice304 that also stores updates or helper programs for enabling other devices to use the service. In such a way, thedevice304 can act as both a provider of the service and a provider of software updates that enable use of that service.
• In one configuration, thesoftware update server312 may be implemented similarly to the UPnP Content Directory Service (CDS). The CDS is a UPnP Audio Video (AV) service template, identified as “urn:schemas-upnp-org:service:ContentDirectory:1.” The CDS is a server-side interface used for accessing media storage devices. The CDS provides lookup functions such as “browse” and “search” that allows devices to discover individual data objects stored on the media servers and access that content. The existing CDS interface may be extended to include software update repositories. Alternatively, thesoftware update server312 may use a service template that is modeled after the CDS, but includes features unique to update distribution, including features that address rights management and security concerns.
• Where thesoftware distribution server312 is configured as a CDS or CDS-like service, a standard AV Control Point component may be used (or adapted) to view and select software made available via thesystem300. One difference between an AV Control point and one adapted for use with thesystem300 is that a standard AV Control Point sends data from a media storage device to an AV Media Renderer device, where the media is rendered and (presumably) perceived by a user. In the present system, the software updates distributed by thesystem300 are not necessarily “rendered” to a user, but are generally installed on a computer. However, components such as theclients310,340 may be adapted to resemble a UPnP Media Renderer. In such a case, software update components could be transferred via thenetwork306 to an update “consumer” in a manner similar to the sending of digital media from a media storage device to a rendering device, the rendering device being the end “consumer” of the media. In such an arrangement, the operations of thesoftware update framework300 can be made compatible with some or all of the existing UPnP AV framework.
• Thecomponents308,310,312,314,338,340,342,344 may interact for such purposes asservice discovery316, cataloging318, query/search320, as well asinitiation322, download324 and configuration326 of updates. In some situations,runtime data328 of the installed updates may be communicated betweencomponents308,310,312,314,338,340,342,344. For example, once an update is installed and successfully running, it may signal328 a success at runtime so that programs involved in the installation can terminate and log the installation as a success. This type ofsignal328 may also be used to hand over a data session where the handover is preceded by an update or configuration that enables the handover to occur. Such data may also be communicated by out-of-band mechanisms329, either via a network or via interprocess communication within thedevices302,304. Such out of band mechanisms may include using dedicated network connections, alternate network access mechanisms and media, streaming data, multicast data, writing to a remote database, etc.
• It will be appreciated that thedownloading function324 may involve downloads directly between thedevices302,304 and/or by using thedevices302,304 as proxies. However, out-of-band upload/download mechanisms330,332 may also be used, such as for accessing updates from adatabase334 and/or adding updates to thedatabase334. Another illustrated out-of-band upload/download mechanism includes distributed uploads/downloads356,358 which generally allows downloads frommultiple peer devices360 at the same time. Technologies such as BitTorrent allow this type of distributed uploads/download356,358 by distributing a file that contains metadata about the files to be shared, and about a server (or “tracker”) that coordinates the file distribution. The tracker assists the downloading device in discovering thepeers360 that can download a portion of the requested data. It will be appreciated that thepeers360 may include any combination of hosts within and outside of theUPnP network306, including Internet hosts.
• In another configuration, the distributed uploads/downloads356,358 may be enabled using entirely UPnP network protocols. In such an example, theUPnP update clients310,340 andservers312,342 may be extended to act as BitTorrent-type peers, without requiring the use of a tracker. Such UPnP distribution would only require the querying of devices on the local UPnP network to discover distributed download devices/services, although the availability of updates in such a case could be extended to entities outside the network by the use of a proxy, such as by configuring a UPnP IGD (seeFIG. 1) as a proxy.
• As previously described, software updates may be found and installed automatically using the discovery and data transfer protocols of the ad-hoc network. In some cases, a user may actively search for particular updates, or the user may be advised of the existence of an update or upgrade when the user tries to access an unavailable feature. In some cases, the updates can be used to continue a real-time data session by allowing the session to be transferred between devices. In reference now toFIG. 4, a sequence diagram illustrates an example use of software update and configuration services to help maintain a session according to an embodiment of the invention.
• In this example amobile device400 and aPC402 are capable of communicating via an ad-hoc, peer-to-peer network, such as a UPnP network. In the following example, software update and configuration services are used to hand over an instant messaging (IM) session from themobile device400 to the PC. Themobile device400 includes anIM client404 that facilitates the IM session. Themobile device400 also includes anupdate control point406 that can be used to control aspects of anupdate server408. Thecontrol point406 andserver408 may be UPnP components as described in other embodiments, or may use an alternate ad-hoc, peer-to-peer framework. Note that theserver408 may be located in themobile device400, thePC402, or any other network peer. The advantage of ad-hoc, peer-to-peer protocols is that the end users of the services do not depend on the service being located at any predetermined location, as long as such services can eventually be discovered by use of the network protocols.
• ThePC402 also includes anupdate client component410. Thisclient410 may be integrated with a control point-like component, or be separate module. ThePC402 also includes anIM client412 that is capable of engaging in IM sessions, and is capable of being configured or updated to receive a handover of asession414 with which themobile client404 is currently engaging. Generally, the user of themobile device400 is engaging in thesession414 outside the home, and thesession414 continues as the user arrives home. Upon arriving home, the IM client404 (or other component) detects the existence of the network, here by receivingservice discovery announcements416,418 from theupdate server408. The illustratedservice discovery messages416,418 respectively advertise the services of theIM client412 and theupdate server408. The full process of service discovery will often involve additional data exchanges besides theseinitial messages416,418, and such additional messages are not illustrated. The particulars of how service discovery are particular to different ad-hoc peer-to-peer frameworks, and the present disclosure is not dependent on any particular form of service discovery.
• It will be appreciated that there are numerous other ways that the mobile device401 may become aware of the local ad-hoc network besides the illustratedmessages416,418. For example, another program (not shown) may occasionally test network connections in order to determine the existence of a desired ad-hoc network. That program may query and enumerate the available services, and based on this determination, signal to theIM client404 that new ad-hoc services are available. In another example, thePC402 may not initially have theIM client412 installed. Nonetheless, themobile device400 may be able to conclude that thePC402 is configurable or upgradeable to support IM sessions. For example, thePC402 may advertise a UPnP DCP called “MobileTelephony” that is currently configured to only handle Voice over Internet Protocol (VoIP) sessions. Themobile device400 discovers the MobileTelephony DCP and further determines that thePC402 includes the software update client410 (e.g., via discovery advertisement418) that can automatically upgrade the MobileTelephony DCP to include IM support.
• After the user arrives to home and themobile device400 determines the existence of thePC IM client412, the user receives anotification420 via the device's user interface. Thenotification420 informs the user that the chat session can be continued using thePC402. If the user selects to transfer the session, anupdate notification422,424,426,428 is sent to the PC'sIM client412 by way of theupdate components406,408,410. When thePC IM client412 receives thenotification428, it is informed that adevice400 with acompatible application404 and user preferences have arrived on the same network as thePC402. Further, thisnotification428 informs theIM client412, based on the received preferences, that a handover of the session is requested.
• In response to thenotification428, the PCIM client application412 may query430 the end user to verify that the current IM session can be transferred to thePC402. Assuming that the user accepts thedialog430, thePC IM client412 receives a handover of theIM session432 and themobile IM client404 closes thesession434. In this way, the session is dynamically transferred to thePC402, and the user may continue the PCIM chat session432. In addition, the user's IM presence is automatically set to “Home” by way of amessage436 sent to a presence server. TheIM client404 of themobile device400 may alternatively or in addition signal a change of presence (not shown).
• The session handover concepts shown inFIG. 4 may be equally applicable to other types of one-way and multi-way communications sessions. For example, themobile device400 may include a mobile TV or radio application. The user may be watching a mobile TV show or listening to Internet radio when the user arrives home. The mobile media application informs the end user that the session may be transferred to a home entertainment center. If the user agrees, the TV or radio is automatically opened to the channel that user was watching with his/her mobile, and the user can continues enjoying the program.
• Many types of apparatuses may be able to engage in software update and configuration activities as described herein. Mobile devices are particularly useful in this role because they are portable user interface devices, and therefore may be called upon to control a wide variety of networked components. In reference now toFIG. 5, an example is illustrated of a representativemobile computing arrangement500 capable of carrying out operations in accordance with embodiments of the invention. Those skilled in the art will appreciate that the exemplarymobile computing arrangement500 is merely representative of general functions that may be associated with such mobile devices, and also that landline computing systems similarly include computing circuitry to perform such operations.
• Theprocessing unit502 controls the basic functions of thearrangement500. Those functions associated may be included as instructions stored in a program storage/memory504. In one embodiment of the invention, the program modules associated with the storage/memory504 are stored in non-volatile electrically-erasable, programmable read-only memory (EEPROM), flash read-only memory (ROM), hard-drive, etc. so that the information is not lost upon power down of the mobile terminal. The relevant software for carrying out conventional mobile terminal operations and operations in accordance with the present invention may also be transmitted to themobile computing arrangement500 via data signals, such as being downloaded electronically via one or more networks, such as the Internet and an intermediate wireless network(s).
• Themobile computing arrangement500 may include hardware and software components coupled to the processing/control unit502 for performing network data exchanges. Themobile computing arrangement500 may include multiple network interfaces for maintaining any combination of wired or wireless data connections. In particular, the illustratedmobile computing arrangement500 includes wireless data transmission circuitry for performing network data exchanges.
• This wireless circuitry includes a digital signal processor (DSP)506 employed to perform a variety of functions, including analog-to-digital (A/D) conversion, digital-to-analog (D/A) conversion, speech coding/decoding, encryption/decryption, error detection and correction, bit stream translation, filtering, etc. Atransceiver508, generally coupled to anantenna510, transmits theoutgoing radio signals512 and receives theincoming radio signals514 associated with the wireless device. These components may enable thearrangement500 to join in one ormore networks515, including mobile service provider networks, local networks, and public networks such as the Internet.
• Themobile computing arrangement500 may also include an alternate network/data interface516 coupled to the processing/control unit502. The alternate network/data interface516 may include the ability to communicate on secondary networks using any manner of data transmission medium, including wired and wireless mediums. Examples of alternate network/data interfaces516 include USB, Bluetooth, Ethernet, 802.11 Wi-Fi, IRDA, etc. In the illustrated example, the alternate network interface is coupled to a local, ad-hoc, peer-to-peer network517. Thesealternate interfaces516 may also be capable of communicating via thenetworks515.
• Theprocessor502 is also coupled to user-interface elements518 associated with the mobile terminal. The user-interface518 of the mobile terminal may include, for example, adisplay520 such as a liquid crystal display and acamera522. Other user-interface mechanisms may be included in theinterface518, such as keypads, speakers, microphones, voice commands, switches, touch pad/screen, graphical user interface using a pointing device, trackball, joystick, vibration generators, etc. These and other user-interface components are coupled to theprocessor502 as is known in the art.
• The program storage/memory504 typically includes operating systems for carrying out functions and applications associated with functions on themobile computing arrangement500. Theprogram storage504 may include one or more of read-only memory (ROM), flash ROM, programmable and/or erasable ROM, random access memory (RAM), subscriber interface module (SIM), wireless interface module (WIM), smart card, hard drive, or other removable memory device. The storage/memory504 of themobile computing arrangement500 may also include software modules for performing functions according to embodiments of the present invention.
• In particular, the program storage/memory504 includes aUPnP stack530 that provides baseline UDA functionality for communicating with devices of the peer-to-peer network517. Thisstack530 may be implemented as common libraries and/or as a standalone process. Alternatively, some or all UPnP applications on thesystem500 may implement their own UPnP stacks. These UPnP applications may include a softwareupdate server device532, a softwareupdate client device534, a softwareupdate control point536, and UPnP-aware programs538.Other programs540 that are not natively UPnP-aware may also be capable of utilizing UPnP functions by way of a plug-inAPI542. Generally, developers often include a plug-inAPI542 as a way for third parties to extend the functionality of thebase program540. A plug-in can utilize thisAPI542 to include UPnP functions that allow theprograms540 to be integrated with the functionality of the other UPnPsoftware update modules532,534,536,538 for purposes such as software updates and configurations.
• The server andclient532,534 may need to access persistent or non-persistent data storage for caching and or storing update images, configuration data, and state data. An example of this storage requirement is shown as thesubscriptions database546 and the updates andversioning database548. Thesubscriptions database546 may include persistent data related to recurring updates requested by peer devices. These subscriptions may be added to thedatabase546 automatically in response to previous installations serviced by theserver device532, or based on requests for software update services from devices that discover this subscription capability via descriptions of theserver device532. Generally, the server device532 (or some other component) may regularly query known sources of updates, and push out the updates to any subscribing peer devices.
• The updates andversioning database548 may contain the files needed to distribute software updates, including binary images, configurations files/scripts, and other metadata distributed with the programs. In some instances the updates andversioning database548 may contain a reference to such data, so that the data need not be stored locally. The updates andversioning database548 may utilize a subscription service (e.g., via thesubscription database546 and server device532) to ensure that data and/or references to data are kept up to date. The updates andversioning database548 may store metadata related to versioning, platforms, and other relevant data to determine whether a particular update is needed and applicable. Thedatabase548 may use some aspects of target platforms and versions to arrange the data, such as by creating a hierarchy with levels for different processor types, operating systems, virtual platforms, target applications, etc.
• In many cases, the software of thedevice500 may include a native UPnP interface, such as represented by thestack530. However, legacy programs (shown here as other applications550) that provide or use functions of the peer-to-peer network517 may still be useful, but certain restrictions (e.g., copyright concerns, no access to source code) may prevent adapting those programs to utilize UPnP, and in particular to use UPnP software update functionality provided locally (e.g., via server component532) or via other devices of thenetwork517. It may still be possible to adaptsuch programs550 to use UPnP through a helper program or some other means. For example, someapplications550 may be able to receive commands and configurations via an interprocess communications (IPC)facility552 of the operating system. These IPC mechanisms may include system messaging, sockets, pipes, middleware (e.g., CORBA, Java RMI), shared files, command line arguments, etc. Alternatively, a virtual environment, here represented bywrapper component554, may set up a simulated environment in which to run theapplication550. In this way, system or kernel calls can be intercepted, and events directed to hardware (e.g., network interfaces516,508) and/or operating system APIs can be intercepted and translated to conform to UPnP protocols.
• Themobile computing arrangement500 ofFIG. 5 is provided as a representative example of a computing environment in which the principles of the present invention may be applied. From the description provided herein, those skilled in the art will appreciate that the present invention is equally applicable in a variety of other currently known and future mobile and landline computing environments. For example, desktop computing devices similarly include a processor, memory, a user interface, and data communication circuitry. Thus, the present invention is applicable in any known computing structure where data may be communicated via a network.
• In reference now toFIG. 6, a flowchart illustrates aprocedure600 for accessing a software update service via ad-hoc peer-to-peer networks. A peer-to-peer software update service is discovered602 via an ad-hoc peer-to-peer network using a service discovery protocol of the network. Generally the peer-to-peer software update service is offered by at least one peer device and facilitates updates of programs via the ad-hoc, peer-to-peer network. Although discovery mechanisms may differ between different types of ad-hoc networks, in some networks a query is sent604 to the peer device for a description in response to thediscovery602. A description is then received606 that enables a particular update to be identified.
• In response to discovering602 the peer-to-peer software update service (and in some cases in response to the description606), an update is selected608 that is applicable to a program of a first device of the ad-hoc peer-to-peer network. The first device may be the same device that discovers602 and selects608, or may be a different physical or logical device. The update is sent610 to the first device, and the program of the first device is modified612 using the update.
• In reference now toFIG. 7, a flowchart illustrates aprocedure700 for providing a software update service via ad-hoc peer-to-peer networks. A peer-to-peer software update service is advertised702 via a peer device coupled to an ad-hoc, peer to peer network using a service discovery protocol of the ad-hoc peer-to-peer network. The peer-to-peer software update service facilitates updating of programs to other entities of the ad-hoc peer-to-peer network. The peer device receives704 at least one query for a description of the peer-to-peer software update service. In response to the at least one query, transmission of an update to a target device via the peer-to-peer software update service is facilitated706. The update may be transmitted from the peer device or another device inside of or outside of the network. The update is used to modify a program on the target device. In one optional configuration, an external network update service that is independent of the ad-hoc peer to peer network is monitored708. The peer device is then configured710 to provide updates of the external network update service via the peer-to-peer software update service.
• In reference now toFIG. 8, a flowchart illustrates aprocedure800 for handover of a data session via a software update service of an ad-hoc peer-to-peer network. A peer-to-peer software update service is discovered802 using a service discovery protocol of the network. An update for handing over a data session currently being conducted by a second device on the ad-hoc, peer-to-peer network is selected804 via the software update service. The update is sent806 to the first device the program of the first device is modified using the update so that the program can receive the handover of the data session. A presence of the user by at least one of the first and second devices based on the handover may be optionally updated808.
• It will be appreciated that various alternates to the illustrated ad-hoc, peer-to-peer software distribution services may be implemented. For example, when a UPnP software update/configuration service is registered, the service may notify other UPnP services that can utilize update service. These devices may request that the service locate and make available particular updates. For example, when a program or device is added to the network and discovers the update service, the new program/device may register with the update service and provide details such as the types of updates needed, the location of such updates, the frequency of checking for new updates, etc. Thereafter, the program/device may rely on the update service to automatically ensure the program/device is kept up to date.
• The foregoing description of the exemplary embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not with this detailed description, but rather determined by the claims appended hereto.

Claims (31)

1. A method, comprising:

discovering, via an ad-hoc peer-to-peer network, a peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network, wherein the peer-to-peer software update service is offered by a peer device and facilitates updates of programs via the ad-hoc, peer-to-peer network;

selecting, in response to discovering the peer-to-peer software update service, an update that is applicable to a program of a first device of the ad-hoc peer-to-peer network;

sending the update to the first device; and

modifying the program of the first device using the update.

2. The method ofclaim 1, further comprising:

sending, to the peer device, at least one query for a description of the peer-to-peer software update service in response to discovering the peer-to-peer software update service;

receiving a description of the peer-to-peer update service in response the query; and

wherein the update is selected based on the description.

3. The method ofclaim 1, wherein the discovery of the peer-to-peer software update service and the selection of the update is performed by a second device of the ad-hoc, peer-to-peer network, and wherein the second device initiates sending of the update to the first device and modifying of the program of the first device using the update.

4. The method ofclaim 1, wherein modifying the program on the first device comprises adding a capability to the program.

5. The method ofclaim 4, wherein the adding the capability comprises adding the capability for the program to access a service of the ad-hoc, peer-to-peer network.

6. The method ofclaim 5, wherein the selection of the update is initiated by the first device in response to the first device detecting the service being advertised on the ad-hoc peer-to-peer network.

7. The method ofclaim 1, wherein modifying the program on the first device comprises reconfiguring the program.

8. The method ofclaim 1, wherein modifying the program comprises modifying the program to receive a handover of a data session currently being conducted by a second device on the ad-hoc peer-to-peer network.

9. The method ofclaim 8, wherein modifying the program comprises providing parameters of the data session to the program of the first device.

10. The method ofclaim 8, wherein modifying the program on the first device comprises adding a capability to the program that enables the program to engage in the data session.

11. The method ofclaim 8, further comprising updating a presence of the user by one of the first and second devices based on the handover of the data session.

12. The method ofclaim 1, wherein the ad-hoc, peer-to-peer network comprises a Universal Plug and Play network.

13. A method, comprising:

advertising, via a peer device coupled to an ad-hoc, peer to peer network, a peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network, wherein the peer-to-peer software update service facilitates updating of programs to other entities of the ad-hoc peer-to-peer network;

receiving, at the peer device, at least one query for a description of the peer-to-peer software update service;

facilitating, in response to the at least one query, transmission of an update to a target device via the peer-to-peer software update service, wherein the update is used to modify a program on the target device.

14. The method ofclaim 13, further comprising:

monitoring an external network update service that is independent of the ad-hoc peer to peer network; and

configuring the peer device to provide updates of the external network update service via the peer-to-peer software update service.

15. The method ofclaim 13, further comprising forwarding discovery from the peer-to-peer to software update service to an external repository service outside the ad-hoc, peer to peer network.

16. The method ofclaim 13, wherein the ad-hoc, peer-to-peer network comprises a Universal Plug and Play network.

17. The method ofclaim 13, wherein the at least one query includes a description of a computer platform of the target device used for filtering a result returned in response to the query.

18. The method ofclaim 13, wherein the at least one query includes a software category used for filtering a result returned in response to the query.

19. An apparatus, comprising:

a network interface capable of communicating via an ad-hoc peer-to-peer network;

a processor coupled to the network interface; and

a memory storage device coupled to the processor, the memory storage device including instructions that cause the processor to,

discover a peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network, wherein the peer-to-peer software update service is offered by a peer device and facilitates updating programs via the ad-hoc peer-to-peer network;

select an update that is compatible with a target program in response to the discovery of the peer-to-peer software update service;

facilitate sending the update to a device of the ad-hoc peer-to-peer network that executes the target program; and

facilitate modifying the target program using the update.

20. The apparatus ofclaim 19, wherein the peer-to-peer software update service is advertised as a Universal Plug and Play device.

21. The apparatus ofclaim 19, wherein the apparatus comprises the device that executes the target program.

22. The apparatus ofclaim 19, wherein the instructions further cause the processor to:

advertise, via the service discovery protocol, a locally provided peer-to-peer software update service that facilitates updating programs via the ad-hoc, peer-to-peer network; and

facilitate transferring a second update to a target device via the locally provided peer-to-peer software update service, wherein the second update is used to modify a program of the target device.

23. The apparatus ofclaim 22, wherein the instructions further cause the processor to,

monitor an external network update service that is independent of the ad-hoc peer-to-peer network; and

offer updates of the external network update service via the locally provided peer-to-peer software update service.

24. The apparatus ofclaim 19, wherein the target program is capable of engaging in user-interactive data sessions, and wherein modifying the target program comprises modifying the program to receive a handover of a data session currently being conducted by a second device on the ad-hoc peer-to-peer network.

25. A computer-readable storage medium having instructions stored thereon which are executable by an apparatus capable of being coupled to an ad-hoc peer-to-peer network for performing steps comprising:

discovering a peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network, wherein the peer-to-peer software update service is offered by a peer device and facilitates updates of programs via the ad-hoc, peer-to-peer network;

selecting, in response to discovering the peer-to-peer software update service, an update that is applicable to a target program;

facilitate sending the update to a device of the ad-hoc peer-to-peer network that executes the target program; and

facilitate modifying the target program using the update.

26. The computer readable medium ofclaim 25, wherein the steps further comprise:

offering a locally provided peer-to-peer software update service that facilitates updating of programs via the ad-hoc, peer to peer network;

advertising the locally provided, peer-to-peer software update service using a service discovery protocol of the ad-hoc peer-to-peer network;

facilitating transmission of a second update to a target device via the peer-to-peer software update service in response to advertising the locally provided, peer-to-peer software update service.

27. A system comprising:

means for advertising a peer-to-peer software update service via a service discovery protocol of an ad-hoc peer-to-peer network, wherein the generic peer-to-peer software update service facilitates peers of the network to update programs of the peers;

means for discovering the peer-to-peer software update service via the ad-hoc peer to peer network;

means for facilitating transmission of an update to a peer device via the peer-to-peer software update service; and

means for modifying a program of the peer device using the update.

28. The system ofclaim 27, further comprising:

means for monitoring an external network update service that is independent of the ad-hoc peer-to-peer network; and

means for offering updates of the external network update service via the peer-to-peer software update service.

29. The system ofclaim 27, further comprising means for modifying the program of the peer device using the update to receive a handover of a data session currently being conducted by another device on the ad-hoc peer-to-peer network.

30. The system ofclaim 29, further comprising means for updating a presence of a user of the peer device based on the handover of the data session.

31. The system ofclaim 27, further comprising means for forwarding discovery from the peer-to-peer to software update service to an external repository service outside the ad-hoc, peer to peer network.

Images