Patent Application
20140379853
The present invention relates to a method of distributing a multi-user software application, and to computer readable media carrying such software. It relates in particular, although not exclusively, to software such as computer games which are designed to be exchanged between users of portable devices such as mobile phones.
The invention includes a system for transferring from one end-user device to another an entire binary-portable computer software application, including any libraries required by the application and saved application state. The binary-portable nature of the computer software application allows this to happen across dissimilar types of devices, including different CPU types and operating-systems.
This enables use-cases which are not typically possible using traditional systems, such as taking an in-progress saved game on one device, transferring the game, libraries and game state to a second device and then continuing to play the game from the same point on the second device, all without any requirement to have a connection to a server to download the necessary libraries or an installation package for the application.
This allows off-network distribution of applications and their state, reducing costs for the end-user, reducing network load, and speeding up the transfer of the application.
Display and input-device virtualisation have been common for a number of years. This entails a host device and a remote device communicating over a some communication link to display either the entire screen or one or more windows from the host device on the remote device's display, and forwarding input events such as keyboard and mouse events from the remote device to the host device to be processed as if they had happened locally on the host device.
Examples of this approach include X-Windows, Microsoft Remote Desktop Connection, and VNC.
In all of these cases, the output of the host system is transmitted to the remote system for display, typically encoded as a sequence of rendering instructions rather than as a sequence of screen captures, as this results in less communications traffic and thus improved performance.
In the case of Microsoft Remote Desktop Connection and VNC, the remote device typically displays the same information as the host device. In X-Windows, the remote device typically acts as the primary display for certain programs running on the host system.
More recent implementations of this approach include Microsoft Windows Media Center Extenders, and the Playstation-3 Remote Play facility. In both of these cases, the host device transmits a set of instructions describing the information to be displayed to the user, such as menus and available content, and when the user selects a piece of content an encoded video stream is transmitted to the remote device, which decodes and displays it.
Implementations of VNC and X-Windows have been made in binary-portable programming environments such as Java.
The systems described above are typically generic services which are not specific to the application whose input and output are being presented remotely. However, there are other systems where both the communications protocol and the program displaying the results on the remote device are specific to the host program.
In these systems, the purpose of the remote program is not simply to display the normal output of an application on the host device (effectively acting as an auxiliary display and set of input devices), but instead to display different information about the state of the host application, and to guide the user to provide input to the host application. The remote program is written with knowledge of the host application's data structures and logic, and the information transmitted between the two ends typically represents semantic objects representing the host program's state instead of explicit rendering instructions, and higher-level representations of user actions such as information that a particular item has been selected from a list, rather than the raw key presses or mouse movements.
The display of a user-interface is done by the remote program based on the information that it holds about the host program's state, allowing vastly less network traffic to be used than the previously described approach. Graphical, audio and other assets may be packaged with the remote program or they may be transferred across the communication link from the host program as required.
The “Meteor” application for Windows Phone 7 devices is an example of this approach—this application connects to a PC running the Windows Media Center application and displays a user-interface allowing the user of the phone to control the operation of the Windows Media Center, including showing the available content, TV guide listings, etc.
Such systems have again been implemented using binary-portable code (for example, the “Meteor” program described above is implemented in the .NET framework, which is a binary-portable system).
The system described in this document is an extension to the second type of system described above—the application-specific remote program with a custom communication protocol.
Typically, these systems require the user to manually install both the host application program on the host device, and the remote application program on the remote device.
This document describes a system and method whereby the “host program” and the “remote program” are packaged and distributed together, and where the software platform underlying these application programs provides a facility for automatically sending either or both of these programs from a first computing device to a second computing device, such that one of these devices acts as the “remote device” in the scenario described above, and the other acts as the “host device”. The choice of which device performs which role depends on the user.
This document also describes a system and method where the first device uses a broadcast mechanism over one or more communication mediums to discover devices which are accessible and which support the necessary network protocols and software features to enable this system to work.
The process of deploying the programs to the target device is triggered by the user and takes place with a minimum of user interaction—selection of the target device and the item or items to send are the minimum requirements. In addition, there may be some security interaction required—for example entering a personal identification number on both devices either each time this process happens, or only on the first occasion (“pairing” the devices).
In the preferred embodiment, the host program and the remote program are implemented in a binary-portable software system, such that they can be transferred between dissimilar device types, including devices with different form-factors (such as personal computers, digital televisions, set-top boxes, mobile phones, etc), and devices with different and otherwise incompatible CPUs.
A single software application (program) may implement both the host program functionality and the remote program functionality.
The invention may be carried into practice in a number of ways and a variety of specific embodiments will now be described, with reference to the accompanying drawings, in which:
a to 8a are referred to in the appendix.
The preferred embodiment of this invention is an extension of the systems described in [1] and [2]. It uses the same binary-portable software distribution format, packaging format, dependency mechanism and so on as described in [1], and extends the meta-data system described in [2] to handle the specific use-case of remote device input. The reader is assumed to be familiar with [1] and [2].
As described in [1]:
As described in [2]:
A group of associated software applications are produced, which are designed to communicate over some communications medium and exchange information to display and manipulate a combined set of state data. This group of applications may comprise several separate applications each of which performs a distinct role within the group (see
One or more of the applications within this group, potentially running on independent computing devices and communicating together, form a “session”. The combined set of state data is associated with this session.
Depending on the architecture of the applications, there may be several different applications communicating together within a session—for example one of the applications might be a “controller” application and the others “slave” applications (see
Typically, although not necessarily, all of the applications in the group are distributed together, either in a single ATX component (where the applications are written as multiple programs within a single component) or else in a container ATX (where the applications are written as separate components). As a result, from any device where any of them is present, the others are also present and thus available for beaming (see
The data representing the overall session state may be retained within the memory or other storage of a single application within the session (with the others retaining some subset of it which is necessary for them to perform their operations), it may be shared by all of the applications within the session, or it may be distributed—not retained in its entirety by any of the applications but being formed by the combined set of application state data retained by all applications in the session.
Each application takes input from the computing device on which it is running, and displays certain output to the user. Different applications within the session or instances of the same application running on different devices within the session may each display a different set of information to the user of that device (see
Information regarding user input may be transmitted to other applications within the session, either in the form of data which represents specific input events (such as a mouse movement or a key press), or in the form of data which represents semantic events within the context of the specific group of applications (such as a request by the user to play a specific music track, to make a move in a game, etc).
In order for a computing device to be able to take part in an application session as described in this document, the relevant software applications must be deployed on the devices.
The mechanism by which this takes place is the same as the method described in [2], which specifies the method by which dependency negotiation takes place between devices, and how “beaming packages” are created.
This section gives some more concrete examples of how this method is used to transfer software applications for the purposes described above.
Selection of a target device for the transfer of a software application can be done in a number of ways, including but not limited to:
These techniques are illustrated in
On some software platforms it may be necessary for the target device to be manually placed by the user into a state where it is ready to receive or respond to such discovery requests or connections.
On other software platforms, it may be possible for such a discovery client program to remain running at all times, or to be registered with the software platform such that it is automatically invoked when an incoming connection or request is detected.
Once the target device has been identified, a connection is established to it from the source device. Although [2] also describes a system whereby a bi-directional communication channel is not required for application software transfer, it is preferable for the two devices to be able to negotiate the subset of software and other information needing to be transferred in order to reduce network utilization and increase transfer speed. A bi-directional connection over which dependency negotiation can be performed therefore forms part of the preferred embodiment.
Once the connection has been established (or as part of its establishment), security mechanisms are used to prevent unauthorized transfer of applications. This typically takes the form of encryption of the connection along with the use of a passphrase or Personal-Identification-Number (PIN) which must be entered on both devices in order for the transfer to succeed.
The users may be offered the option of “pairing” with the other device, allowing future application software transfers to take place from that device without requiring the use of a passphrase or PIN.
The security protocol should include a mechanism for each device to uniquely identify itself to the other, preferably in a manner whereby each device does not transmit information which could be used by another device to impersonate it (for example by using a replay attack).
A number of such systems exist and are well known, such as the Secure Remote Password Protocol [3]. This protocol allows two devices to prove to each other than they both have the PIN or passphrase, without exposing any information about it which could be used by an eavesdropper to impersonate either device. In addition, this protocol results in both parties having a shared (but secret from any other party) key which can be used for encrypted communication. This protocol is used in the preferred embodiment, and is illustrated in
Having made a connection between the devices and established an appropriate level of security and authenticity for the application software transfer operation, the dependency negotiation process described in [2] can now take place.
In some cases this list will be empty—for example where the software has already been transferred to the target device during a previous transfer operation, or where the software was independently installed on both devices.
Document [2] describes the use of a meta-data component which is not cryptographically signed to contain information about application state. This document details a use-case for this mechanism where the meta-data component contains information about the desired action for the target device to take (e.g. which application component to start, and using what parameters), plus additional information identifying other computing devices within the session which the target device will become part of when the relevant program is started.
This information is likely to take the form of one or more network addresses and port numbers or service IDs—for example in a simple case this would identify the network endpoint via which the target device can connect back to the originating application on the sending device.
As described in [2], this meta-data component is packaged with any application, library and rights components needing to be transferred and transferred to the target device. The components are installed and processed on the target device as described in [2].
The meta-data component (identifying the desired actions for the receiving device to take and the existing session members) needs to be generated dynamically when the user selects the action to take, since various pieces of data such as the network endpoints may differ each time the beaming package is generated.
There are a number of ways in which this meta-data could be generated, such as by the application declaring certain information such that the software framework can generate all of the necessary meta-data, potentially including the automatic allocation of a network endpoint, prior to starting the local application.
In the preferred embodiment described here, the generation of the meta-data is performed primarily by the application itself, although potentially making use of libraries provided by the software framework to perform various aspects of the work such as the packaging and formatting.
The user first selects which mode they wish the local device to operate in—in other words which application role they wish it to perform (server, client, master, slave, peer, etc). The possible set of roles depends on the specific application or group of applications.
The user may do this by running a specific application from the group of applications which can communicate together in a session, or by selecting an operating mode from within an already running application (for example, where the same application can perform multiple roles).
Having done this, the user is given the option to start a new session, with the application presenting the available options. There are many possible application configurations, but some examples are:
Many other possible application configurations exist, and the application should present the appropriate options to the user.
If the user wishes to join an existing session, it is up to the application to discover such available sessions in an application-specific manner, and to negotiate with the existing session members to allow access.
If the user selects an option indicating that they wish to initiate a new session, the application performs device discovery to identify the target device. This target device must support the necessary protocols and software framework to be able to receive and process beaming packages as described in [2], and so this device discovery will typically be facilitated by using a library provided by the software framework on the local device. This device discovery procedure is described in more detail above.
Having identified the target device, the application can allocate a network endpoint on an appropriate network medium. Typically this will be the same network medium that was used to discover the target device (such as Bluetooth or Wi-Fi), but this is not strictly necessary—there may be a mechanism to determine that both devices are able to communicate over a different medium than that used for discovery, and such a medium may be selected in preference due to criteria such as speed, power utilization, latency, security, etc.
At this point all information necessary to build the beaming package is available. The application calls a library function provided by the software framework, passing in as parameters:
The application-specific data is packaged into a meta-data component (see
The network endpoints transferred in the meta-data component are text records specifying the remote address to connect to.
These are comprised of a number of elements:
For IPv4 endpoints, the address is formed of a 32-bit value identifying the target device (typically formatted as a “dotted quad”), a 16-bit port number and a flag indicating whether the endpoint is connected (TCP) or datagram (UDP).
For IPv6 endpoints, the address is a 128-bit value identifying the target device (typically formatted as 8 groups of 4 hexadecimal digits, separated by colons), a 16-bit port number and a flag indicating whether the endpoint is connected (TCP) or datagram (UDP).
For Bluetooth endpoints, the address is a 48-bit value identifying the target device (typically formatted as 6 groups of 2 hexadecimal digits, separated by colons) and a 128-bit service UUID.
As discussed in [2], the beaming package is received on the target device and installed. To recap, this takes place as follows:
As discussed above, in the particular case described in this document, the application, library and rights components represent one or more application programs from a group of application programs which are able to communicate over a network link to form an “application session”.
Once the beaming package contents have been installed, the application identified by the “AGC-State-AppDependency” property in the meta-data package is automatically started (or switched to, if it is already running). This may be subject to user confirmation.
When this application starts or is switched to, it enumerates the “incoming” items of meta-data using the system described in [2]. Upon finding the meta-data item generated as described in section 2.4, it retrieves the application-specific data which specifies the desired actions and network endpoint. It acts upon these instructions by switching to the requested application mode, and making a connection to the specified network endpoint. As described above, the originating device should already be listening for this network connection, and session setup and further operation should proceed immediately.
The system described above describes all of the common aspects involved in the transfer of an application-specific remote program. The remaining details are application-specific, such as the details of the protocol and the exact functionality of the application programs within the group which form a session.
However, a few more points can be mentioned which describe the benefits of using an application-specific remote program (or more generally, a number of associated applications which communicate in a session).
The ATX packages described in [1] can contain program code (binary-portable program code in the preferred embodiment), graphical and audio assets, as well as other application-specific data formats such as game level maps, etc.
Not only can the amount of data transferred be vastly reduced compared to a naïve input/output virtualisation system, but also state information can be cached at both ends of the communication link (or more generally, on all devices running programs which are participating in a session) between sessions.
This further reduces network traffic by reducing the amount of data that must be transferred between devices on subsequent session start-up. In turn, this reduction in network traffic results in faster start-up and an improved user experience.
When the application running on the host system has some kind of state change which requires the screen on the remote device to be changed, or an audio file played, the information needing to be transmitted across the network is minimal—simply the data describing the state change. The graphics can be updated on the remote device and audio played as necessary with low bandwidth requirements and low latency.
Similarly, not all input events need to be sent to the host device—the program running on the remote device can take a number of independent actions before reporting the results to the host device.
Although this description discloses the semi-automatic transfer and start-up of some subset of a group of application programs able to communicate together in a session, the system described above can easily support a “generic remote program”—one which is not specific to the host application program.
Using this approach, the host application program code can be either relatively—or completely—unchanged and still support this facility.
The range of inputs and outputs which can be gathered and displayed on a remote device is less comprehensive than can be achieved using an application-specific remote program, but this is still a useful facility.
A generic remote program would typically be a program which is written to communicate using a network connection with some software running as part of the software framework under which the host application program is running. Thus, this software can insert input events and gather output data from the host application without any need to change the host application program itself.
The generic remote program could simply communicate the literal input events that the user triggers on the remote device using the input devices available (buttons, touch-screen, accelerometer, etc), or it could perform some translation or simulation of input events—for example by allowing the user to simulate different input events by touching different areas of a touch-screen (for example, a four-directional keypad, an analogue joystick, a keyboard, etc). A suitable graphic would be displayed in this case to guide the user's input.
The generic remote program could provide the user with a mechanism to switch between different input modes, allowing the user to simulate input from a number of different input devices using a touch-screen or other single input device.
In addition, the network protocol used to communicate between the host device and the remote device could include notification of which host application program is being run on the host device. This allows the generic remote program to record which input settings have been selected by the user for different applications, and to automatically switch into the remembered mode for the host application being used.
The program implementing host side of the generic remote protocol (which typically acts as part of the software framework in which the host application is running, or is closely linked to it) may be able to receive feedback from the host application about which input devices it wishes to receive input from (perhaps by the host application calling some API which enables particular input devices). This information can be communicated to the generic remote program such that an appropriate input mode can be automatically selected for a host program, without the user having to manually select a mode.
Simple outputs such as audio output and vibration can be controlled in a similar way, although the additional latency of transferring audio data across the network connection may make this impractical in some cases. Spot-effects, where the application registers a sample to be played at a later time and later triggers the playback, are likely to work better than streaming audio—the APIs available to the application in a particular software environment may determine whether this is feasible.
The generic remote program could work in a variety of ways. The preferred embodiment is as follows.
The generic remote program is first run by the user on the remote device. At this point, the user is given a number of choices:
This may be done using a broadcast/multicast mechanism, or by enumerating a set of devices with which the remote device has previously communicated or with which it is “paired”.
If successful, the remote device becomes part of the existing session.
The meta-data component within the beaming package is generated from data supplied by the generic remote program. It specifies that the program to run on the remote device is some kind of “stub” application which implements the host side of the generic remote protocol. In addition, it specifies the program to be run, as previously selected by the user, and the network endpoint on which it is listening for connections.
Any software components necessary to run the selected application are included in the beaming package using the mechanism described above and in [2]. In addition, if necessary any software components required to operate the host side of the generic remote protocol may be included. In some embodiments these are built-in to the software framework, but in other embodiments these are separate and can be “beamed” in the same way as any other application software as described in [1] and [2].
Upon receipt of this beaming package, the target device (in this case, this is the “host” device) installs any necessary software components and makes the meta-data package available in the “incoming” area of the corresponding application as described in [2], and invokes the associated application.
In this case, the associated application is the application which handles the host side of the generic remote protocol. It starts up, makes a connection back to the network endpoint on which the generic remote program is listening, and then invokes the specified application program (which was selected by the user on the remote device).
Depending on the software environment, it may be possible for both programs to run simultaneously, or it may be necessary for the first program to exit, chaining on to the selected application program in some way which allows the necessary portion of the first program to remain present in the computer's memory such that it can communicate with the generic remote program and insert input events into the host program and intercept its outputs.
The details of this are operating-system-specific and application-specific, and are not addressed here, but examples include the use of “terminate and stay resident” programs, operating-systems which allow multiple programs to run simultaneously, etc.
This is simply a means of beaming and/or launching the application on a target device. The same mechanism described in the previous option is used, but the network endpoint to connect back to is omitted from the meta-data component.
At the receiving end, the application which usually handles the host side of the generic remote protocol starts as described above after the installation of any necessary components from the beaming package, but due to the lack of a remote network endpoint it simply invokes the host application selected by the user. In this case, there is no need for the first application to remain running or resident in memory while the host application runs.
In one embodiment there is a single remote program connected to the host program, allowing the user to control the host program by using input devices on the remote device.
In another embodiment there is more than one instance of the same remote program connected to the host program, where each remote program allows the user to control the host program as above, but in this scenario the remote devices may also show information which is private to the user of that specific remote device, such as cards in a card game such as Poker, or the position of their ships in Battleships. The host device shows only the shared information which is public to all users.
In another embodiment there are multiple instances of the same application acting as peers (no overall controller). Typically in this scenario, each application communicates with all others within the session, rather than with a single controlling application instance.
3.4 More than Two Applications within Group
In another embodiment there are more than two separate applications within the group of applications which can communicate in a session. There may be multiple instances of some of these applications within a session, typically running on different devices.
The binary-portable nature of the software described in the preferred embodiment means that it is usable across a wide range of remote devices, varying in terms of hardware (CPU, input devices, etc) and software (operating-system).
To give a concrete example, the host device might be a set-top box or a television, and the remote device might be a mobile phone running Android, Windows-Mobile, Symbian, Linux, etc, and having a CPU with the ARM, MIPS or x86 architecture, or a variety of others. This might have touch-screen input, a simple numeric keypad, an accelerometer, etc.
3.6 Beaming Host/Remote Programs from Portable Device
In this use-case, a user with an application on his portable device (such as a mobile phone) can beam the application along with its remote program to another portable device and/or a fixed device such as a television.
A session can then be initiated between these devices, where the originating device can be running either the host or the remote program (or any other application within the group).
3.7 Beaming Remote Programs from Fixed Device
In this use-case, a user downloads (or otherwise installs) an application on a fixed device such as a television or set-top box. He then beams the remote program for the application (typically along with the application) to one or more portable devices such as mobile phones, digital audio players, etc.
A session can then be initiated as in the previous use-case. In this scenario the originating device (the fixed device) would typically run the host program and the portable device would run the remote program.
3.8 Use of a Different Network Medium for Discovery than for Later Communication
In this use-case, the originating and target device use a different network medium for bulk data transfer than they do for device discovery.
This may be for reasons of functionality, speed, latency, power utilization, security, etc. For example, one medium might support multicast or broadcast or a standard service-discovery mechanism, making it preferable for the discovery part of the operation. Another medium might have different advantageous characteristics which make it the preferred medium for bulk data transfer.
In this figure, Device A discovers Device B using the standard Bluetooth Service Discovery Protocol. This allows Device B to advertise that it supports the beaming and/or application session protocols described in this document and allows Device A to search for devices supporting the relevant protocol.
The devices initiate a data connection over the Bluetooth network. Using this connection, they communicate their network addresses on any other network mediums (for example their IP addresses on the Wi-Fi network).
For any networks which they both have addresses on, Device A opens a listening connection and randomly generates a security key. The network endpoint information and random key are sent across the Bluetooth connection to Device B, which attempts to connect to the specified network endpoint. In the example shown in
Note that the devices don't necessarily have enough information to determine that they are on the same physical or logical network, but they can determine that they are both on a network using the same protocol (for example, they both have IP addresses), so they can attempt to communicate.
If Device B successfully manages to connect to the specified network endpoint (in this case an IP address and port number), a security exchange takes place whereby each device verifies that the other has the correct security information (without revealing the security information).
In addition, other information may be exchanged and tests may be made to determine whether the connection is suitable for bulk data transfer—for example, the devices may need to determine that they are on the same physical or logical network and so use of the connection will not typically incur significant data costs. This may be done in the IP protocol by setting the TTL (time-to-live) field to a small value so that packets do not get routed outside of the local network.
If these negotiations take place successfully, the Bluetooth connection can be closed and all further data transfer can take place over the new connection. If not, another network address may be attempted if available, and as a last resort the Bluetooth connection may be used for the bulk data transfer.
The present invention relates to a method of distributing software, and to computer readable media carrying such software. It relates in particular, although not exclusively, to software such as computer games which are designed to be exchanged between users of portable devices such as mobile phones.
Many general-purpose computer systems allow a user to copy application state data manually—for example word-processor documents, etc. It is also quite common for games consoles to allow the user to copy saved game state onto external media (for example the WII and GameCube consoles allow this).
Some gaming platforms allow a user to transfer certain game state information such as recordings of a car race to other players, such that the receiving player can effectively race against a recorded game and is challenged to try to beat a particular score or time. High-scores are another example of game-state items which are commonly shared among a community of players.
The J2ME Java application environment for mobile devices in some cases has the facility to send applications directly from one user to another.
According to the present application there is provided a method of distributing binary-portable software comprising:
The invention further extends to a computer-readable media storing program code for implementing on a digital computer (such as a mobile phone) the method of claim 1.
The invention may be carried into practice in a number of ways and several specific embodiments will now be described by way of example, with reference to the accompanying figures, as follows:
FIG. 1—Data not modified between transfers.
FIG. 2—Data modified on originating device between transfers.
FIG. 3—Data modified on target device between transfers.
FIG. 4—Data modified on both devices between transfers.
FIG. 5—Transferring an application with all dependencies and selected application state.
FIG. 6—Transferring an application with a subset of its dependencies.
FIG. 7—Transferring only the application state
FIG. 8—Low-cost off-network transfer of beaming package.
Software applications are typically downloaded from a server or installed from physical media. If downloaded, they often come in installation packages which are discarded after the application is installed.
In many cases, the application has dependencies (other pieces of software) which are required in order for it to work. These are typically either installed manually by the end-user, or included unconditionally in the application's installation package.
Simply installing an application and its libraries is not sufficient to transfer the state of an application from one device to another. Applications generally save data to persistent storage to allow information to persist across different invocations of the application.
This data is described as “application state” in the present patent application, and includes items such as:
Traditional systems do not provide a managed way to take an application installed on one device and transfer it to another, including any necessary dependencies and the application state.
This patent application describes a novel system for doing this for binary-portable software applications across dissimilar device types, whereby parts of the application which are already present on the target device are not transferred, thus reducing the size of the data being transferred and thus the time taken and the costs.
This approach provides some important advantages for the user:
The method preferably includes managed “version control” which automatically notifies the application when new state data is received and which tracks whether it is older, newer or the same as any corresponding state data item already on the device.
The application may be packaged along with the application state data (along with any required libraries) in such a way that the resulting package can be sent as a unit to another device which can then allow the user to view/modify the application state even if the corresponding application was not previously installed on that receiving device.
This allows use-cases which are not commonly available, such as sending a game challenge (as described above) along with the corresponding game, so that the recipient can attempt to beat the sender's score even if they do not already have the game installed. This could be used as a form of try-before-you-buy to encourage the recipient to purchase the game.
There are also benefits to mobile phone network operators. Mobile phone networks struggle with the increasing bandwidth requirements of smart devices, even in developed counties where network coverage is good.
In developing countries the network coverage and the bandwidth availability over mobile phone networks can make it difficult to transfer even modest sized applications in a reasonable time. Transferring large applications such as advanced 3D games takes so long as to make it prohibitive.
The system described here allows network operators to offer an enhanced user experience without requiring costly improvements to the network infrastructure.
Other fields of use include distributed computer systems, TVs, hand-held and fixed gaming consoles and the like.
This preferred embodiment is an extension of the system described in the present applicant's published PCT application WO/2010/145886, and uses the same binary-portable software distribution format, packaging format, dependency mechanism and so on as described in that document. The reader is assumed to be familiar with this publication. In the text, it will be referred to as “the prior publication”. The prior publication is incorporated by reference.
In order to transfer (or “beam”) an application from one end-user device to another, a number of pieces of data must be transferred to the target device. In the invention detailed in this document, this is done by selecting the relevant pieces of data and packaging them into a single container ATX file, called a “beaming package”.
The data to be included in this package includes:
The data within the beaming package therefore varies depending on data exchanged with the target device and upon user input.
Sometimes it may not be possible to directly communicate with the target device. This may occur, for example, because the devices' network connections go through a NAT firewall so cannot receive incoming connections easily, and the devices are not close enough together to use a short range technology such as Bluetooth, ad-hoc Wi-Fi or a USB cable. In such a case it cannot be determined which pieces of software required for running the application are already installed on the target device, and so as a fallback the system must include all application software and libraries required by the application, or ask the user which parts they wish to send. Note that even in this case where there is no direct connection between the devices, the transfer of the application may still be possible through an indirect communication mechanism such as e-mail.
However, if the two devices can communicate directly, a better approach is possible: they can communicate and discover which parts of the application and library software need to be transferred.
3.4.1 Negotiation with the Target Device
Given that the source and target devices can communicate, it is possible for them to exchange information about what application, library, asset and meta-data components are installed.
The source device starts with a set of components which it knows need to be present on the target device. This will typically include the main application component itself, plus a rights component if one is available.
Given this list of components, the source device can query whether each component is installed on the target device (using the unique component name and version number as a pair of identifiers). If a component is already installed on the target device, it is removed from the list and is given no further consideration.
Alternatively, a component may be retained in the list, and ultimately sent to the receiving device if the receiving device reports that the version of the component it already has installed is older than the version to be sent (there is version information within the component manifest file).
For each component which is not already installed on the target device, the dependencies of that component are added to the list of components to be considered, and the procedure continues. In this way, the entire set of dependencies of the original set of components are enumerated and checked.
It should be noted that the dependencies as described in the prior publication can fulfilled by either a component with a matching component name or by a component which implements a matching interface name. This means that the implementation of the dependency on the target device may be different from the implementation on the source device. This could be because there is an installable component from a different supplier on the target device which implements the required interface, or it could be because the software environment on the target device contains a built-in implementation of the interface.
Device drivers for hardware such as OpenGL-ES are a common example of this—each hardware manufacturer typically provides their own implementation of the OpenGL-ES software using making use of underlying hardware capabilities. In the absence of this, it is possible that a software implementation of the interface might be present (there may be a number of different software implementations in existence from different vendors).
For the application being beamed this is irrelevant. The interface specifies the behaviour that must be implemented, and so as long as the interface that the application requires is present on the target device, the requirement is satisfied regardless of the implementation.
By following the procedure describe here, the source and target devices can negotiate a set of components which need to be transferred in order for the application to work on the target device.
It is also possible that there might be a dependency which cannot be satisfied on the target device, such as when the application requires an interface which can only be satisfied on devices which have a particular piece of hardware (for example an input device such as an accelerometer). This can be detected at this negotiation stage and the beaming procedure can be aborted with an appropriate message to the user indicating the cause of the failure.
Applications may save a number of separate items of application state data and the user may wish to select a subset of that data to be transferred to the receiving device; often this subset will be a single item of application state data such as an in-progress saved game.
In the system described here, the application itself is not required to interact with the user in order to allow them to select which items of application state data they wish to include in the beaming package. Instead, the application provides the software environment with some meta-data describing the data, which is later used by the software environment to allow the user to select the application state data.
Items of meta-data specified by the application:
The application provides these meta-data by calling an API function to “register” the application state data as an item which should be available for beaming. The filename of the application state data to be associated with these meta-data is also supplied. The application can update these meta-data later (for example, if the name contains a time-stamp this may need to be updated whenever the data is updated).
The application can call a corresponding function to “deregister” the application state item, marking it as no longer available for beaming (and discarding any stored meta-data).
In addition to meta-data explicitly provided by the application, the software environment automatically records some additional meta-data:
Consider the case where an item of application state data is saved on device A and transferred to device B. There are now two copies of the application state data, either of which might be modified. If subsequently the same item is transferred between these devices again, there are a number of different cases:
These four scenarios are illustrated in
It is generally difficult for users to keep track of which versions of saved files are newer than others, and so it is helpful for the system to assist the user by keeping track of changes to the application state data files, detecting these situations and notifying the user.
Clearly this situation is even more difficult for users to keep track of when more than two devices are involved, but the basic cases described above can still be detected and reported to the user.
In the system described by this document, this situation is addressed by storing an ordered sequence of version-record meta-data units where each unit represents a branching or joining point in the lifecycle of the application state item.
A version-record consists of a sequence number (starting at 0 and increasing in units of 1), a hash of the contents of the application state item, and the unique identifier of the device on which the version-record was added (this is the same unique identifier mentioned in the prior publication).
An initial version-record is added when the application state item is initially created. Subsequent version-records are added according to the following procedure:
This procedure for adding version-records is executed at the following points:
By following these steps, we build up a history of modifications on different devices. The various scenarios described above can now be distinguished by analysing these version-records:
In the prior publication, there are two modes described for ATX files—signed “ATX components” which contain code, data or meta-data, and unsigned “container ATX files” which simply contain other ATX files, which themselves are typically ATX components.
This document describes a new type of ATX file—an unsigned file containing an item of application state, plus a manifest containing the meta-data associated with that item (the random identifier, type, version information, etc). The meta-data described above is encoded in the standard JAR manifest format as key/value pairs using the following property names for the meta-data items described above:
Since this file is not cryptographically signed, its contents cannot be relied upon not to be modified. A simple (but non-secure) way to make it slightly more complex for an attacker to modify this data would be to append a cyclic-redundancy-check or similar code to the application state data file, and then encode the resulting data file using a stream cipher using a key based on some hash of the manifest. It should be stressed however that this will not stop a serious attacker and is only useful against casual attempts to modify the data.
Using this approach, modifications to the manifest or the data file will typically result in the CRC data being invalid when the data is decoded, allowing the modification to be detected in the vast majority of cases.
Using negotiation with the target device, the set of application, dependency and rights components required to run the application but not present on the target can be determined. The user then selects zero or more items of application state to be beamed. In an alternative embodiment, the application state(s) to be beamed may be selected automatically with no user-intervention required. For example, it may be convenient in some applications automatically to beam the most recent application state,
As part of the negotiation process, in one embodiment the receiving device can report to the beaming device the application states that it can accept, or that the user of the receiving device wishes to accept (e.g. by way of a user option). This avoids the beaming device transmitting data which will not or cannot be used at the receiving device.
The ATX files for these application state items are generated and stored in a container ATX file, along with the ATX installation packages for all of the application, dependency and rights components that need to be transferred.
The resulting container ATX file is transferred to the target device over any available transport mechanism. This can include OBEX over Bluetooth, as an attachment to an email message, a custom protocol over a Wi-Fi network or a mobile phone network, etc.
When a container ATX file is received by the target device, its inner ATX files are examined and a number of actions taken as a result:
The installation of the binary-portable software components in step 2, and the handling of rights components in step 1 are described in the prior publication.
Application state items are processed as follows:
If the user does not reject an incoming item of application state, the corresponding data file is stored in a directory visible to the application whose sole purpose is to contain incoming application state data files. In addition, the meta-data for the application-state item is inserted into the target system's record of application state items, in essentially the same way as if the item had been registered in the normal manner by an application. If the user chose to merge a conflict, this is recorded along with the meta-data for the item.
A number of small changes may need to be made to applications wishing to make use of the application state beaming facility. These will be evident to the skilled person on the basis of this disclosure.
Applications may need to call an API function to “register” a saved data file as being available for beaming, as described above.
The application may also deregister data files, removing any stored meta-data for the file and marking it as no longer available for beaming.
Sometimes applications may need to change the format of their saved data files. This can happen when features are added or removed, or simply for efficiency improvements, etc.
When this happens, old versions of the application are typically unable to use data files created by the new version, whereas new versions of the application may or may not be able to use data files saved by old versions of the application.
The author of the software application can express information in the application manifest about which versions of the application's data formats are supported using the AGC-State-AppDependency and AGC-InterfaceComponent-n properties.
The AGC-State-AppDependency property is encoded into the meta-data of any application state item created by the application, and into the manifest of any application state items that are beamed to other devices.
This expresses a dependency on a specific interface name and version-range. The application implements this interface. By changing the interface version numbers in these two manifest properties, old application state items can be selectively allowed or disallowed, and new application state data files marked as being incompatible with older versions of the application.
For example:
In this example, the application states that it supports version 1.0 of the interface. The AGC-State-AppDependency entry which is put into the application state meta-data indicates that it requires at least version 1.0 of this interface, but that it expects future versions of the application which support different data formats to be able to decode it as well.
This is an extension of the previous example, in which the data format for application-state has changed. The application now states that it supports version 1.1 of the interface.
Note that this still matches the version range which will exist in application state items created by the earlier version of the application (1.0-1.*). The application is therefore stating that it still supports application state items created by the earlier version of the application which implemented version 1.0 of this interface.
New application state items saved by this application will be assigned the new version range “1.1-1.*”. This will not match the previous version of the application (which implemented version 1.0 of this interface), which is the correct behaviour.
This can be considered as an extension of the previous example in which the application author decides to drop support for all previous application state data format versions, or it could be used in a situation where the author never had any intention of providing backward-compatibility for older data formats. Regardless of the intention, the mechanism is the same.
The application state meta-data from older versions of the application will require a version number in the range “1.*”, so will not match this new version of the application. The application has therefore declared its incompatibility with those versions.
By modifying the major version number, the application authors can keep control over whether they want to retain backward compatibility at each change to the data format.
3.7.3 Actions Taken when Application State Items are Received
When the application starts (or at some other well-defined occasions, such as immediately before displaying a list of saved files for the user to choose from), it is expected to call an API function to enumerate the application state items within the directory described above where incoming application state item data files are stored.
For each item in the enumeration, the application is given the name of the incoming application state data file, the name of the corresponding existing application state data file (if any), information about which is newer and whether there was a conflict, and whether the user chose to install the incoming version or attempt a merge.
The application is required to validate the contents of the incoming application state data file (to check for deliberate modification, corruption, etc). Application state data files are a common attack vector for gaming systems, so it is important the applications robustly check the validity of incoming application state data files to protect against buffer-overruns, etc.
Once the application has validated the incoming file, it should take one of the following actions:
By following these rules, the incoming directory should only contain files which have recently been received on the device and which require attention from the application, while the application retains control over the naming convention and directory structure of application state files within its data directories.
The application can provide simple merging facilities if it chooses at this point.
For example, a chess game using the application state beaming mechanism to transmit the turns from one player to another might perform a check on incoming state items representing an in-progress saved-game, to ensure that the received game matched its record of the game state (i.e. all previous moves the same) with one extra move having been made by the opposing player. Effectively the incoming application state is merged with the existing state.
More complex merges might be possible if the application state data format contains internally a record of individual changes, enabling the application to detect individual modifications within the file and resolve which items should be retained from each file, perhaps with user confirmation.
This section describes some use-cases supported by the system described in this document.
4.1 Transferring an Application Along with all of its Dependencies and State
In a situation where there is no direct communication from the source device to the target device, the two devices cannot negotiate the set of application and dependency components which need to be transferred in order to make the application work.
In this situation, it is necessary to transfer the entire set of components. The user may optionally select some application state to be transferred along with the application.
There are many reasons why the source and targets might not be able to communicate directly, including connectivity reasons and also the situation where the target device is not known at the time that the beaming package is created—for example if the source device creates the beaming package and makes it available for download on a publicly accessible web server.
The transfer process is illustrated in
4.2 Transferring an Application with a Subset of its Dependencies
A more useful case is where the source and target devices are able to communicate. In this case, they are able to determine the exact subset of components that need to be transferred.
Again, the user may choose some application state to be included in the beaming package.
This is illustrated in
The ultimate example of the negotiation between the source and target devices is where they determine that the target device has all of the components that it needs in order to run the application. In this case, only application state items (if any are selected by the user) need to be transferred.
This is illustrated in
4.4 Transferring Over a Short-Range Network when there is No Phone Network Coverage
A key advantage of this system is the “off-network” transfer of the data—typically over a short-range wireless technology such as Bluetooth or Wi-Fi (including ad-hoc Wi-Fi where no existing Wi-Fi network is required). A wired connection such as USB or Ethernet can also be used where appropriate.
This is illustrated in
| Number | Date | Country | Kind |
|---|---|---|---|
| 1107978.7 | May 2011 | GB | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP12/58744 | 5/11/2012 | WO | 00 | 9/15/2014 |
