U.S. patent application number 11/729750 was filed with the patent office on 2008-06-05 for software update via peer-to-peer networks.
Invention is credited to Jose Costa-Requena, Inmaculada Espigares, Mika Helander, Kirmo Koistinen, Vesa Luiro, Markku Pulkkinen, Anssi Saarimaki.
Application Number | 20080130639 11/729750 |
Document ID | / |
Family ID | 39475661 |
Filed Date | 2008-06-05 |
United States Patent
Application |
20080130639 |
Kind Code |
A1 |
Costa-Requena; Jose ; et
al. |
June 5, 2008 |
Software update via peer-to-peer networks
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.
Inventors: |
Costa-Requena; Jose;
(Helsinki, FI) ; Espigares; Inmaculada; (Helsinki,
FI) ; Helander; Mika; (Oulu, FI) ; Koistinen;
Kirmo; (Oulu, FI) ; Luiro; Vesa; (Kempele,
FI) ; Pulkkinen; Markku; (Oulu, FI) ;
Saarimaki; Anssi; (Oulu, FO) |
Correspondence
Address: |
HOLLINGSWORTH & FUNK, LLC
Suite 125, 8009 34th Avenue South
Minneapolis
MN
55425
US
|
Family ID: |
39475661 |
Appl. No.: |
11/729750 |
Filed: |
March 29, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11633756 |
Dec 5, 2006 |
|
|
|
11729750 |
|
|
|
|
Current U.S.
Class: |
370/389 |
Current CPC
Class: |
H04W 8/245 20130101;
H04L 67/16 20130101; H04L 67/104 20130101; G06F 8/65 20130101; H04W
84/18 20130101; H04L 67/34 20130101; H04L 67/1068 20130101 |
Class at
Publication: |
370/389 |
International
Class: |
H04L 12/56 20060101
H04L012/56 |
Claims
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 of claim 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 of claim 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 of claim 1, wherein modifying the program on the
first device comprises adding a capability to the program.
5. The method of claim 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 of claim 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 of claim 1, wherein modifying the program on the
first device comprises reconfiguring the program.
8. The method of claim 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 of claim 8, wherein modifying the program comprises
providing parameters of the data session to the program of the
first device.
10. The method of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 13, wherein the ad-hoc, peer-to-peer
network comprises a Universal Plug and Play network.
17. The method of claim 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 of claim 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 of claim 19, wherein the peer-to-peer software
update service is advertised as a Universal Plug and Play
device.
21. The apparatus of claim 19, wherein the apparatus comprises the
device that executes the target program.
22. The apparatus of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] 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
[0003] Universal Plug and Play.TM. (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.
[0004] 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.
[0005] 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.
[0006] 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
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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
[0022] The invention is described in connection with the
embodiments illustrated in the following diagrams.
[0023] FIG. 1 is a block diagram illustrating a system according to
embodiments of the invention;
[0024] FIG. 2 is a block diagram illustrating an implementation of
a software update service according to embodiments of the
invention;
[0025] FIG. 3 is a block diagram illustrating a UPnP software
update and configuration architecture according to embodiments of
the invention;
[0026] FIG. 4 is a sequence diagram of a session handover
facilitated by an update service according to an embodiment of the
invention;
[0027] FIG. 5 is a block diagram of a mobile device according to
embodiments of the invention;
[0028] 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;
[0029] 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
[0030] 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
[0031] 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.
[0032] 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.
[0033] 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.TM. are protocols that provide functions
similar to those of UPnP.
[0034] 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.
[0035] 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.
[0036] 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).
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] In reference now to FIG. 1, a block diagram 100 illustrates
an example system according to embodiments of the invention.
Generally, technologies such as UPnP are designed for operating
within a limited space. In FIG. 1, a physical boundary defines a
local space 102. The dimensions of the local space 102 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 the local space 102 is for purposes of
illustration, and not of limitation.
[0045] The space 102 may include at least one local network 104
that is capable of supporting communications with one or more user
devices 106. The local network 104 may include any combination of
data transmission media and protocols. For example, the network 104
may utilize wired or wireless data transmission media. Similarly,
devices 106 on the local network 104 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 the network 104 as well, including TCP/IP,
UDP/IP, IPX, Appletalk, ICMP, ARP, SNMP, DNS, FTP, SMB, NetBEUI,
etc.
[0046] The user devices 106 generally include some manner of data
processing capabilities, and in particular at least some of the
devices 106 are capable of obtaining and running software via the
network 104. In most installations, this software includes user or
system programs that are capable of running on devices 106 having
general-purpose data processing capabilities. Such devices 106
usually include sufficient memory (e.g., random access memory) to
load in new programs that selectably alter the behavior of the
device. Such devices 106 generally include (or at least have access
to) some type of persistent data storage (e.g., hard disk, flash
memory) that allow the devices 106 to retain changed or added
software after the cycling of power.
[0047] Although the concepts described herein may be usefully
applied to general-purpose computing devices, the invention need
not be limited such devices. For example, the devices 106 may
include an embedded system device 107, 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 embedded system 107 may
be updated, modified, or replaced by a peer-to-peer software
distribution service as described herein. For example, the embedded
system 107 may include a "smart" UPnP appliance that performs a
single function via the network 104. Such device 107 may be
upgradeable (e.g., to enhance the specific function or fix bugs) by
modifying flash memory that contains the operating instructions of
the device 107. In such an arrangement, the device 107 may include
instructions that allow it to utilize a UPnP software distribution
service for obtaining and applying flash memory upgrades without
requiring user intervention.
[0048] In the illustrated diagram 100, other networkable devices
106 include a gaming console 108, mobile phone 109, laptop computer
110, personal digital assistant 112, portable music player 114,
tablet computer 116, personal computer 117, entertainment center
120, or any other device as represented by generic data processing
device 118. Because protocols such are UPnP are applicable to a
wide variety of consumer electronics, consumer electronics devices
such as the entertainment center 120 may include peer-to-peer
network functionality. In some configurations, the consumer
electronics device 120, like the embedded system 107, 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 the device 120, and thus are relatively fixed for
the life of the device 120. In other arrangements, however, the
device 120 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, the device 120 may be adaptable
to use or provide some or all of the software distribution services
described herein.
[0049] Preferably, the network 104 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 the network 104. In one embodiment,
the local network 104 may support one or more protocols for ad-hoc,
peer-to-peer service discovery and interoperability. The local
network 104 may be designed to service a limited physical region,
as indicated by the boundary 102. The protocols used in such a
local network 104 (e.g., UPnP) often assume that the network 104
will need to support only a limited number of devices operating
within a reasonably small area. However, many devices on the local
network 104 may benefit from information services available via an
external network, particularly the Internet 126. The UPnP
specification defines a special service/function known as an
Internet Gateway Device (IGD) 128. The IGD function 128 can be
provided by one or more of the devices 106 for purposes of provide
routing and firewall services on behalf of others of the devices
106 of the local UPnP network 104. In some arrangements, a
dedicated gateway device may perform the IGD functions 128 on the
UPnP network 104, as well as providing traditional gateway/router
functions for non-UPnP devices.
[0050] In one embodiment of the invention, one or more of the user
devices 106 have specialized components 130 that enable the devices
106 to distribute software programs and updates at least via the
local network 104. This component 130 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/service 130 may
be hosted by one or more of the network devices 106 and be
advertised 132 according to service discovery protocols of the
local peer-to-peer network 104. For example, devices on a UPnP
network advertise via SSDP, which uses XML UDP unicast and
multicast packets to advertise 132 services. In response to the
advertisement 132, a device 118 may initiate further negotiations
(e.g., queries) to discover particulars about the service 130.
Assuming the device 118 is willing and able to utilize the software
distribution service 130, the device can request 134 a software
distribution function via the service 130.
[0051] One software distribution function that may be requested 134
by the device is a download 136. In the illustrated environment,
the download 136 may involve data transfer directly from the
service 130 to the device 118. In another example, a download 138
may be facilitated by the service 130, but the data transfer 138
occurs from another device 117 in the local network 104. The device
117 from which the download 138 originates may or may not be
capable of communicating using the formats and protocols of the
service 130. For example, the device 117 may be in a sleep mode,
and the service/device 130 acts as a proxy that processes queries
and other transactions, but causes the download 138 to originate
from the device 117 after causing the device 117 to wake up. In
another example, the device 117 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 network 104. 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 for devices 106
to engage in ad-hoc, peer-to-peer interactions via the network
104.
[0052] In another arrangement, a download 140 may originate from an
outside network such as the Internet 126, and may be facilitated by
one or more local components, including the software distribution
service 130 and the IGD 128. Where the download originates from
outside the network, an entity 142 providing the download 140 may
not appear as a logical device on the local network 104. In one
arrangement, a device such as the IGD 128 may act as a proxy for
the software downloads, so that it appears that the IGD 128 is
providing the download, even though the data originates from an
external entity 142. The external entity 142 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 entities 130, 117 may also participate in similar
distributed software distribution.
[0053] It will be appreciated that in alternate arrangements, the
local service 130 may act as a proxy for the external entity 142.
In such an arrangement, the external entity generates its own
advertisement 141, which may be broadcast, multicast, or unicast to
the service 130 (e.g., by way of the IGD 128). This advertisement
141 may be provided directly to the network by way of the IGD 128,
or as illustrated, combined with the advertisements of the local
update/distribution service 130. Similarly requests/queries 134 of
the local network 104 may be sent directly to the external service
142, such as directly via the IGD 128, or indirectly by way of the
local service 130, which then forwards a request 143 to the
external service. In this way, the system enables forwarding
discovery from the peer-to-peer to software update service 130
and/or the local network 104 to an external repository service 142
outside the ad-hoc, peer to peer network 104. Thereafter, services
such as downloading 136, 140 can be utilized as described elsewhere
herein.
[0054] Downloading is only one example of a software distribution
function that may be facilitated by the device/service 130. Other
functions are illustrated as the setup/configure/activate function
144. These functions 144 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. The functions 144 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. The service 130 may directly
perform the function 144, or may facilitate functions between the
client 118 and another entity. An example of this is the
illustrated activation 146, which performed via an entity 142 that
is outside the local environment 102 (e.g. in an online software
repository service).
[0055] In other situations, setup, configuration and/or update data
may also originate from the external entity 142. The external
entity 142 may be, for example, a software update server of a
device manufacturer or other entity. Examples of these types of
Internet-based update facilities 142 include automatic updates
facilities included in operating systems such as Windows.TM. and
Linux.TM., 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.TM. 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.
[0056] In contrast to updates on personal computers, the
illustrated service 130 may be generally applicable to provide
updates to any device on the network 104. Proprietary update
mechanisms implemented on individual local devices 106 may be
extended to include a UPnP update interface. Similar adaptations
can be made for external update sites 142. Even though external
update sites 142 may have custom or proprietary interfaces, the
service 130 may be made modular, so that a manufacturer can install
a plug-in so that any updates offered by specialized external
update servers 142 can applied via a common UPnP interface locally.
The update service 130 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 the network 104, the new device can register with the
update service 130, the update service 130 can automatically
discover any extensions needed to interface with the remote server
142 and apply those extensions. Thereafter the service 130 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.
[0057] Note that the update service 130 may be able to
automatically cache update and configuration data and redistribute
updates as necessary, thus reducing bandwidth at the external
server 142. 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 the service 130.
[0058] It will be appreciated that the illustrated system 100 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.
[0059] In reference now to FIG. 2, a more detailed example is
presented of how updates and configurations can be facilitated in
accordance with embodiments of the invention. Two mobile terminals
202, 204 are coupled via an ad-hoc, peer-to-peer network 206. In
this example, mobile terminal 202 includes a control point/client
208 and a terminal 204 includes an update server 210 that may be
configured to update and/or configure software on mobile terminals
202, 204, or any other device of the network 206. It will be
appreciated that both terminals 202, 204 may contain any
combination of respective control point/client 208 and server
components 210, although in this example only the illustrated
components 208, 210 are being utilized on respective terminals 202,
204. In this scenario, the terminal 204 may be acting as a UPnP
device that is offering its update services 210 to other UPnP
devices on the network 206. As such, the terminal 204 may provide
an eXtensible Markup Language (XML) device description 212 in
response to queries received via the network 206.
[0060] The example device description 212 includes variables that
describe the device itself, such as the device type 214. This
implementation defines new UPnP DCP definition for a UPnP Software
configuration DCP root device 214 and may include optional embedded
devices. Generally, a UPnP device may also provide one or more
services, and the illustrated device description 212 shows an
example UPnP SWConfigurationService 216. The service 216 may be
associated with an action 218, 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, the device 214, service
216, and action 218 may be defined as a minimum mandatory
requirement for any device providing this type of network function
210.
[0061] The device type used with the GetDeviceType action 218 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.RTM. x86 compatible
CPU may run different OSes, such as Windows.RTM., Linux.RTM., OS
X.RTM., 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.
[0062] 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.TM. or
Microsoft.TM. .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.
[0063] It will be appreciated that the directory service 216 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 requesting device 208. Other issues that the
directory service 216 may need to take into account when
distributing software include the capacity of the requesting
terminal 202, 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, the software
configuration device 214 can provide a list of available updates
that satisfy the criteria. The list could be "flat," or be arranged
in a hierarchy. The client device 202 may utilize a control point
208 that is specially adapted for controlling the software
configuration device 214, as well as any other embedded devices and
associated services. Each embedded device may also have own control
point for controlling other similar applications.
[0064] The update server 210 may be hosted in any home device, and
the hosting apparatus 204 may store new software data that is
transferred to other devices in order to perform upgrades. The
server 210 can store the new software data in an upgrade repository
219 that is locally situated, either within the apparatus 204 or
elsewhere on the local network 206. In another arrangement, the
repository 219 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 point 208 will interact
with the upgrade server 210 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 the device 202. If
there is a difference in the versioning number of the service 210,
the client 208 will initiate the upgrade.
[0065] The client 208 may identify updates automatically or at the
prompting of a user. For example, the client 208 may query any
local update services 210 at a predetermined interval, such as once
per day. In another scenario, the client 208 may determine that
updates or upgrades are needed when the user first tries to use an
unavailable or non-activated service on the apparatus 202. This
scenario is shown in screen 222, which is an example display of a
video player application. The user has attempted to play a video on
the apparatus 202, but the player does not have the needed codec to
process a particular video file or stream. The screen 222 includes
a prompt 221 that requests whether the user wishes to attempt an
update. Assuming the user answers in the affirmative, the control
point/client 208 may access one or more update servers 210 to
obtain the upgrade. In turn, the service 210 may access one or more
upgrade repositories 219 to find the needed update. If available
updates are found, the user may be notified, such as via screen
222. 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.
[0066] Assuming the appropriate update is available, the server 210
will facilitate transferring update data to the terminal 202 (such
as via a separate download manager), thereby enabling the selected
update to be installed. The server 210 may be configured to
facilitate downloads of configurations and/or executable images,
either from the terminal 204 itself or from a third party. For
example, the server 210 may provide authentication that allows the
other terminal 202 to access a Web download site and obtain an
update or configuration.
[0067] In more particular examples of downloads, the serving
terminal 204 has the needed update files stored in the device's
local file system. The server 210 provides a link to the
installation files (e.g., a Uniform Resource Identifier, or URI)
and receiving client 208 can download the files using a UPnP
content directory service DCP. In another example, the serving
terminal 204 has a lightweight run-time object (Java or web browser
scripts) stored in the terminal's file system. The server 210
provides an HTTP link to the run-time files, and receiving client
208 can download them using a UPnP content directory service DCP.
In another example, server 210 provides an Internet HTTP URI to the
update files to the client 208, and the device 202 can download
them using suitable program.
[0068] 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 the update service 210 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.
[0069] 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. The upgrade server 210 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
the device 208 and any servers 210 that provide the updates
Security measures may be implemented in both the server 210 and/or
client 208. For example, the system may require that any software
be authenticated by a trusted source before the client machine 202
installs it. In other cases, a user interface of the control point
208 may require user confirmation before any software is
installed.
[0070] The device description 212 may include specific services
related to both security and rights management. Similarly, the
client/control point 208 may include provisions to ensure any
distribution server 210 is to be trusted. For example, transactions
with the server 210 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.
[0071] 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 to FIG. 3, a block diagram 300
illustrates an example implementation of a UPnP update and
configuration architecture according to an embodiment of the
invention. The diagram 300 includes two compatible peer devices
302, 304 that may interact via a UPnP network 306. The devices 302,
304 typically represent separate hardware components; however there
may be some arrangements where the devices 302, 304 are virtual
devices that share hardware with each other and with other
components of the network 306.
[0072] As illustrated, the device 302, 304 may contain compatible
functional components 308, 310, 312, 314, 338, 340, 342, 344 that
allow each device 302, 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 the devices 302,
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 device 302 may be
comprised of a handheld game controller acting as the UPnP control
point 338, and this controller communicates via Bluetooth with a
cellular phone acting as a UPnP client 340.
[0073] Functional components 308, 310, 312, 314 of peer device 304
will be described in greater detail below. It will be appreciated
that the same functionality may also be provided by analogous
components 338, 340, 342, 344 of device 302. The device 304
includes a UPnP software update control point 308, a UPnP software
update client 310, and a UPnP software update server 312. Each of
the components 308, 310, 312 are configured to communicate via UPnP
protocols, and as such will implement the UPnP Device Architecture
(UDA). Also associated with these components 308, 310, 312 is a
UPnP software update device control protocol (DCP) that defines the
actions and state variables of the various interactions between
components 308, 310, 312.
[0074] The UPnP software distribution control point 308 may provide
functions similar to other UPnP control points, such as the UPnP
audio video (AV) control point. Generally, the control point 308
includes the user interface and application logic that allows a
user to discover the services of other software update devices on
the UPnP network 306. The UPnP update control point 308 may also
provide other control functions for activities associated with
finding, selecting, buying, downloading, configuring, and/or
running updates. The control point 308 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,
the control point 308 may only provide minimal user interface
functions, such as reporting critical errors, or requiring
confirmation of updates as required by security policy
settings.
[0075] The software update client device 310 is a UPnP device that
provides UPnP interface for connecting to software update servers.
The client device 310 may operate in response to operations of the
control point 308, other user interface devices, or in response to
other, non-user initiated events. Generally, the client device 310
interacts with software update servers 312, 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.
[0076] The UPnP software distribution server 312 acts as a central
point for accessing specific updates 314 that are available via the
device 304. More specifically, the server 312 is a UPnP device with
the "software update" service exposing the available updates 314.
The server device 312 may also handle the actions and maintain the
state variables associated with installing the updates 314. The
server device 312 may use a registry or some other mechanism for
tracking and categorizing various updates 314 that are available
via the peer device 304. Generally, those updates may be applied to
programs 317. The programs 317 may include UPnP-capable and
non-UPnP-capable programs. Where the programs 317 are UPnP-capable,
the distribution of the updates 314 can be integrated with the
discovery of UPnP services, including UPnP services hosted by a
device 304 that also stores updates or helper programs for enabling
other devices to use the service. In such a way, the device 304 can
act as both a provider of the service and a provider of software
updates that enable use of that service.
[0077] In one configuration, the software update server 312 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, the software update server 312 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.
[0078] Where the software distribution server 312 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 the system 300. One difference between an AV Control point and
one adapted for use with the system 300 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 the system 300 are not necessarily "rendered" to a
user, but are generally installed on a computer. However,
components such as the clients 310, 340 may be adapted to resemble
a UPnP Media Renderer. In such a case, software update components
could be transferred via the network 306 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 the software update framework 300 can be made
compatible with some or all of the existing UPnP AV framework.
[0079] The components 308, 310, 312, 314, 338, 340, 342, 344 may
interact for such purposes as service discovery 316, cataloging
318, query/search 320, as well as initiation 322, download 324 and
configuration 326 of updates. In some situations, runtime data 328
of the installed updates may be communicated between components
308, 310, 312, 314, 338, 340, 342, 344. For example, once an update
is installed and successfully running, it may signal 328 a success
at runtime so that programs involved in the installation can
terminate and log the installation as a success. This type of
signal 328 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 mechanisms 329, either via a network or via
interprocess communication within the devices 302, 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.
[0080] It will be appreciated that the downloading function 324 may
involve downloads directly between the devices 302, 304 and/or by
using the devices 302, 304 as proxies. However, out-of-band
upload/download mechanisms 330, 332 may also be used, such as for
accessing updates from a database 334 and/or adding updates to the
database 334. Another illustrated out-of-band upload/download
mechanism includes distributed uploads/downloads 356, 358 which
generally allows downloads from multiple peer devices 360 at the
same time. Technologies such as BitTorrent allow this type of
distributed uploads/download 356, 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 the peers 360 that
can download a portion of the requested data. It will be
appreciated that the peers 360 may include any combination of hosts
within and outside of the UPnP network 306, including Internet
hosts.
[0081] In another configuration, the distributed uploads/downloads
356, 358 may be enabled using entirely UPnP network protocols. In
such an example, the UPnP update clients 310, 340 and servers 312,
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 (see FIG. 1) as a proxy.
[0082] 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 to FIG. 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.
[0083] In this example a mobile device 400 and a PC 402 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 the mobile device 400 to the PC. The mobile
device 400 includes an IM client 404 that facilitates the IM
session. The mobile device 400 also includes an update control
point 406 that can be used to control aspects of an update server
408. The control point 406 and server 408 may be UPnP components as
described in other embodiments, or may use an alternate ad-hoc,
peer-to-peer framework. Note that the server 408 may be located in
the mobile device 400, the PC 402, 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.
[0084] The PC 402 also includes an update client component 410.
This client 410 may be integrated with a control point-like
component, or be separate module. The PC 402 also includes an IM
client 412 that is capable of engaging in IM sessions, and is
capable of being configured or updated to receive a handover of a
session 414 with which the mobile client 404 is currently engaging.
Generally, the user of the mobile device 400 is engaging in the
session 414 outside the home, and the session 414 continues as the
user arrives home. Upon arriving home, the IM client 404 (or other
component) detects the existence of the network, here by receiving
service discovery announcements 416, 418 from the update server
408. The illustrated service discovery messages 416, 418
respectively advertise the services of the IM client 412 and the
update server 408. The full process of service discovery will often
involve additional data exchanges besides these initial messages
416, 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.
[0085] It will be appreciated that there are numerous other ways
that the mobile device 401 may become aware of the local ad-hoc
network besides the illustrated messages 416, 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 the IM client
404 that new ad-hoc services are available. In another example, the
PC 402 may not initially have the IM client 412 installed.
Nonetheless, the mobile device 400 may be able to conclude that the
PC 402 is configurable or upgradeable to support IM sessions. For
example, the PC 402 may advertise a UPnP DCP called
"MobileTelephony" that is currently configured to only handle Voice
over Internet Protocol (VoIP) sessions. The mobile device 400
discovers the MobileTelephony DCP and further determines that the
PC 402 includes the software update client 410 (e.g., via discovery
advertisement 418) that can automatically upgrade the
MobileTelephony DCP to include IM support.
[0086] After the user arrives to home and the mobile device 400
determines the existence of the PC IM client 412, the user receives
a notification 420 via the device's user interface. The
notification 420 informs the user that the chat session can be
continued using the PC 402. If the user selects to transfer the
session, an update notification 422, 424, 426, 428 is sent to the
PC's IM client 412 by way of the update components 406, 408, 410.
When the PC IM client 412 receives the notification 428, it is
informed that a device 400 with a compatible application 404 and
user preferences have arrived on the same network as the PC 402.
Further, this notification 428 informs the IM client 412, based on
the received preferences, that a handover of the session is
requested.
[0087] In response to the notification 428, the PC IM client
application 412 may query 430 the end user to verify that the
current IM session can be transferred to the PC 402. Assuming that
the user accepts the dialog 430, the PC IM client 412 receives a
handover of the IM session 432 and the mobile IM client 404 closes
the session 434. In this way, the session is dynamically
transferred to the PC 402, and the user may continue the PC IM chat
session 432. In addition, the user's IM presence is automatically
set to "Home" by way of a message 436 sent to a presence server.
The IM client 404 of the mobile device 400 may alternatively or in
addition signal a change of presence (not shown).
[0088] The session handover concepts shown in FIG. 4 may be equally
applicable to other types of one-way and multi-way communications
sessions. For example, the mobile device 400 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.
[0089] 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
to FIG. 5, an example is illustrated of a representative mobile
computing arrangement 500 capable of carrying out operations in
accordance with embodiments of the invention. Those skilled in the
art will appreciate that the exemplary mobile computing arrangement
500 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.
[0090] The processing unit 502 controls the basic functions of the
arrangement 500. Those functions associated may be included as
instructions stored in a program storage/memory 504. In one
embodiment of the invention, the program modules associated with
the storage/memory 504 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 the mobile computing arrangement 500 via
data signals, such as being downloaded electronically via one or
more networks, such as the Internet and an intermediate wireless
network(s).
[0091] The mobile computing arrangement 500 may include hardware
and software components coupled to the processing/control unit 502
for performing network data exchanges. The mobile computing
arrangement 500 may include multiple network interfaces for
maintaining any combination of wired or wireless data connections.
In particular, the illustrated mobile computing arrangement 500
includes wireless data transmission circuitry for performing
network data exchanges.
[0092] 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. A
transceiver 508, generally coupled to an antenna 510, transmits the
outgoing radio signals 512 and receives the incoming radio signals
514 associated with the wireless device. These components may
enable the arrangement 500 to join in one or more networks 515,
including mobile service provider networks, local networks, and
public networks such as the Internet.
[0093] The mobile computing arrangement 500 may also include an
alternate network/data interface 516 coupled to the
processing/control unit 502. The alternate network/data interface
516 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 interfaces 516
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 network 517. These alternate
interfaces 516 may also be capable of communicating via the
networks 515.
[0094] The processor 502 is also coupled to user-interface elements
518 associated with the mobile terminal. The user-interface 518 of
the mobile terminal may include, for example, a display 520 such as
a liquid crystal display and a camera 522. Other user-interface
mechanisms may be included in the interface 518, 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 the processor 502 as is known in the
art.
[0095] The program storage/memory 504 typically includes operating
systems for carrying out functions and applications associated with
functions on the mobile computing arrangement 500. The program
storage 504 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/memory 504 of the mobile computing arrangement 500 may
also include software modules for performing functions according to
embodiments of the present invention.
[0096] In particular, the program storage/memory 504 includes a
UPnP stack 530 that provides baseline UDA functionality for
communicating with devices of the peer-to-peer network 517. This
stack 530 may be implemented as common libraries and/or as a
standalone process. Alternatively, some or all UPnP applications on
the system 500 may implement their own UPnP stacks. These UPnP
applications may include a software update server device 532, a
software update client device 534, a software update control point
536, and UPnP-aware programs 538. Other programs 540 that are not
natively UPnP-aware may also be capable of utilizing UPnP functions
by way of a plug-in API 542. Generally, developers often include a
plug-in API 542 as a way for third parties to extend the
functionality of the base program 540. A plug-in can utilize this
API 542 to include UPnP functions that allow the programs 540 to be
integrated with the functionality of the other UPnP software update
modules 532, 534, 536, 538 for purposes such as software updates
and configurations.
[0097] The server and client 532, 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 the subscriptions database 546 and
the updates and versioning database 548. The subscriptions database
546 may include persistent data related to recurring updates
requested by peer devices. These subscriptions may be added to the
database 546 automatically in response to previous installations
serviced by the server device 532, or based on requests for
software update services from devices that discover this
subscription capability via descriptions of the server device 532.
Generally, the server device 532 (or some other component) may
regularly query known sources of updates, and push out the updates
to any subscribing peer devices.
[0098] The updates and versioning database 548 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 and
versioning database 548 may contain a reference to such data, so
that the data need not be stored locally. The updates and
versioning database 548 may utilize a subscription service (e.g.,
via the subscription database 546 and server device 532) to ensure
that data and/or references to data are kept up to date. The
updates and versioning database 548 may store metadata related to
versioning, platforms, and other relevant data to determine whether
a particular update is needed and applicable. The database 548 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.
[0099] In many cases, the software of the device 500 may include a
native UPnP interface, such as represented by the stack 530.
However, legacy programs (shown here as other applications 550)
that provide or use functions of the peer-to-peer network 517 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 component
532) or via other devices of the network 517. It may still be
possible to adapt such programs 550 to use UPnP through a helper
program or some other means. For example, some applications 550 may
be able to receive commands and configurations via an interprocess
communications (IPC) facility 552 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 by wrapper component 554, may set up a simulated
environment in which to run the application 550. In this way,
system or kernel calls can be intercepted, and events directed to
hardware (e.g., network interfaces 516, 508) and/or operating
system APIs can be intercepted and translated to conform to UPnP
protocols.
[0100] The mobile computing arrangement 500 of FIG. 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.
[0101] In reference now to FIG. 6, a flowchart illustrates a
procedure 600 for accessing a software update service via ad-hoc
peer-to-peer networks. A peer-to-peer software update service is
discovered 602 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 sent 604 to
the peer device for a description in response to the discovery 602.
A description is then received 606 that enables a particular update
to be identified.
[0102] In response to discovering 602 the peer-to-peer software
update service (and in some cases in response to the description
606), an update is selected 608 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 discovers 602 and selects 608, or may
be a different physical or logical device. The update is sent 610
to the first device, and the program of the first device is
modified 612 using the update.
[0103] In reference now to FIG. 7, a flowchart illustrates a
procedure 700 for providing a software update service via ad-hoc
peer-to-peer networks. A peer-to-peer software update service is
advertised 702 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 receives 704 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 facilitated 706. 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 monitored 708.
The peer device is then configured 710 to provide updates of the
external network update service via the peer-to-peer software
update service.
[0104] In reference now to FIG. 8, a flowchart illustrates a
procedure 800 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 discovered 802 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 selected 804 via the software update service. The update
is sent 806 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 updated 808.
[0105] 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.
[0106] 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.
* * * * *