Patent Application
20130339941
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.
3.1 Background
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.
3.2 Benefits
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.
3.3 Prerequisites
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.
3.3.1 Recap of Relevant Parts of WO/2010/145886
3.4 Creation of a Beaming/Transfer Package
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.
3.4.2 Application State Data
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.
3.4.2.1 Application State Meta-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:
3.4.2.2 Application State Version Tracking
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:
3.4.2.3 Application State Data Packaging
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.
3.5 Beaming the Package
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.
3.6 Receiving and Installing the Beaming Package
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.
3.7 Application Support
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.
3.7.1 Registering and Deregistering Application State Items
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.
3.7.2 Application State Data Format Changes
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.
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
4.3 Transferring only the application state
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 |
|---|---|---|---|
| 1021875.8 | Dec 2010 | GB | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2011/073088 | 12/16/2011 | WO | 00 | 9/9/2013 |
