WO2004063937A2

WO2004063937A2 - Downloading data files

Info

Publication number: WO2004063937A2
Application number: PCT/GB2003/005406
Authority: WO
Inventors: Nicolas Bernard Sauvage
Original assignee: Ttp Com Limited
Priority date: 2003-01-08
Filing date: 2003-12-12
Publication date: 2004-07-29
Also published as: GB2397201A; AU2003290248A8; GB0300415D0; WO2004063937A3; AU2003290248A1

Abstract

A method of transferring a data file (2) from a service provider (1) to a mobile communications device (5) comprises the steps of splitting the file into first and second parts (A and B), transmitting the first and second file parts over respective first and second communications routes (3 and 4) from the service provider to the mobile communications device, and reassembling the file from the first and second file parts at the mobile communications device.

Description

Downloading Data Files

This invention relates to a method of, and a system for, downloading data files to a communications device, and in particular to a method of, and system for, downloading large data files (such as game files or music files) to a mobile communications device such as a mobile phone or a Personal Digital Assistant (PDA).

It is known to download such data files from a Network Operator Network (NON) to a mobile communications device (for example, BREW from Qualcomm for CDMA networks, or Ex-En from In-Fusio for GSM networks). Where data files are large, as is the case with game files and music files, such downloads can be very slow, being limited by the bandwidth capability of the network concerned, and expensive (network usage costs normally being charged on top of the price of the file being downloaded).

The aim of the invention is to provide a method of, and a system for, downloading large data files to a communications device more rapidly and/or less expensively than known methods and systems.

The present invention provides a method of transferring a data file from a service provider to a mobile communications device, the method comprising the steps of splitting the file into first and second parts, transmitting the first and second file parts over respective first and second communications routes from the service provider to the mobile communications device, and reassembling the file from the first and second file parts at the mobile communications device.

Advantageously, the first file part is big in size and could, for example, be larger than the second file part. Preferably, the first file part is at least an order of magnitude larger than the second file part, and more preferably the first file part is more than 99% of the data file. In a preferred embodiment the first communications route is a lower cost route than the second communications route.

Conveniently, the first communications route includes first and second parts, the first part of the first route being an Internet connection between the service provider and a computer, and the second part of the first route being a short-range communications link between the computer and the mobile communications device.

Alternatively, the first communications route includes first and second parts, the first part of the first route being from a dedicated server associated with the service provider to a dedicated base station, and the second part of the first route being a short-range communications link between the dedicated base station and the mobile communications device. In this case, the dedicated server is likely to contain a large number of data files, and means are provided for updating the data files, for example by using the Internet or a phone line.

In either case, the second part of the first communications route may be constituted by a wireless connection. Preferably, the wireless connection uses the Bluetooth protocol. The wireless connection could also use any wireless protocol in the 802.11 family.

Preferably, the second communications route is a network operator network associated with the service provider.

In a preferred embodiment, the file is split into the first and second parts using an algorithm that ensures neither of the file parts can be used by a user of the mobile communications device until the file has been reassembled. In this way, files such as the first file parts which are readily accessible for downloading from the Internet, cannot be used by an end-user without the corresponding second file part, for which the service provider can charge/bill for before, during and/or after sending that file part. The service provider may also charge or bill on a regular basis, for example, monthly or yearly. Advantageously, the user of the mobile communications device is charged for the data file when the second file part is transmitted.

Preferably, an encryption key is sent to the user of the mobile communications device with the second file part, and the encryption key is subsequently usable by the mobile communications device for encryption of the second file part for transmission to another mobile communications device. Alternatively, an encryption key is sent to the user of the mobile communications device with the second file part, and the encryption key is subsequently usable by the mobile communications device for encryption of a complete re-assembled file part for transmission to another mobile communications device.

Conveniently, the user of said another mobile communications device accesses the service provider to obtain a key for decrypting the received encrypted second part (the second file part or the re-assembled file part), the service provider sending charging/billing data with said key. In the case where only the second file part is received, that user can then, or before the transfer, obtain the corresponding first file part, either from the Internet or from the dedicated base station, so as to be able to reassemble the data file. In the case where the complete re-assembled file is received encrypted, that user only needs to receive the key to be able to decrypt the file.

The invention also provides a data file transfer system comprising a service provider and a mobile communications device, the service provider comprising a memory for storing a data file, means for splitting the data file into first and second parts, and means for transmitting the first and second file parts over respective first and second communications routes to the mobile communications device, and the mobile communications device having means for reassembling the file from the first and second file parts.

Preferably, the memory of the service provider is such as to store a large number of data files. In a preferred embodiment, the first communications route includes first and second parts, and the system further comprises an intermediate device, the first part of the first route being between the service provider and the intermediate device, and the second part of the first route being a short-range communications link between the intermediate device and the mobile communications device.

Advantageously, the intermediate device is a computer. In this case, the first part of the first route is an Internet connection. Alternatively, the intermediate device is a dedicated base station for storing a plurality of first file parts.

Preferably, the system further comprises a dedicated server associated with the service provider, the dedicated server including a memory for storing a large number of data files.

In a preferred embodiment, the short-range communications link uses the 802.11b protocol or any other protocol from the 802.11 family, or a universal serial bus.

The invention will now be described in greater detail, by way of example, with reference to the accompanying drawing, the single figure of which is a schematic representation of a system for downloading large data files from a service provider to a mobile communications device.

Referring to the drawing, a service provider 1 has a library of files (only one of which - identified by the reference numeral 2 - is shown). These files are data files such as game files or music files. Each of the files in the library of the service provider 1 is split into two parts, one of which is stored in the NON 3 of that service provider, the other being stored on the Internet 4. For example, the file 2 is stored in parts A and B respectively on the NON 3 and on the Internet 4. Typically, for a game file, part A contains 1% or less of the data of the file 2, and part B contains 99% or more of the data. The file 2 is split into the two parts A and B using any suitable algorithm, such as that described below. The main requirement of the algorithm used is that each of the parts A and B is useless (that is to say the data it contains cannot be used for the initial purpose of the file 2) without the data from the other part. Moreover, the way the file 2 is split into the two parts A and B, and the way the two parts are merged to provide a usable file for a user to use inputs that are unique to the file 2, so that knowledge of the algorithm used to split the file 2 is not sufficient to merge the two parts A and B to reconstitute that file. In other words, in order to merge the downloaded parts A and B, the user needs to know the parameters that were used to split the file 2 in the first place. A further desirable property of the split/merge algorithm, although not essential, is that the process by which the parts A and B are merged should be relatively quick.

If the user of a mobile communications device 5 wants to download the file 2 from the service provider 1, this is accomplished by directly downloading the part A from the NON 3, and by downloading the part B from the Internet 4, for example, by the user's PC 6. The PC 6 can then be linked to the mobile communications device 5, either via a cable such as a USB cable or wirelessly, for example, using Bluetooth or the wireless protocol 802.1 lb.

As mentioned earlier, the part B cannot be used on its own. The part A is also needed, as is the merge process (using the algorithm and its inputs). Only then, is it possible for the end-user to use the original file 2. the end-user will, therefore, need to access the NON 3 to receive the part A. It should be noted that this can be before, after, or during the download of the part B.

When the end-user accesses the NON 3 to obtain the part A, that user will be authenticated and charged/billed for the file, (most likely using a Public Key Infrastructure (PKI) infrastructure, to ensure that part of the Digital Rights Management (DRM) issues are being taken care of.

During the download of the part A, the inputs used for the split algorithm are also sent, so that the mobile device 5 can merge the parts A and B. These two parts may be merged immediately in the device 5, or stored in separate memory locations for future use. In some cases, it is preferable to merge the parts A and B immediately, for example when the merge process can take longer than the end-user is prepared to wait each time the complete file is accessed. This is particularly the case for large files such as music files. The file is then stored in memory, and an identification of that file is available for browsing by other end-users in what is known as a public list of files. In this case, an encryption key K is sent to the end-user at the same time as the part A is sent. The key K will only be used to encrypt the file when the file is sent to, or requested by, another user, as is described below. Where the parts A and B are stored separately on the mobile communications device 5, the algorithm inputs are stored with the part A. The parts A and B and the algorithm inputs are only merged when the end-user wants to use the file. Merging then takes place, and the merged file is placed in the memory of the mobile communication device 5 just before the file is executed/read. In this case, the parts A and B may be stored in a different areas of memory in the mobile communications device 5, the part A preferably being stored in a safer part of the memory. Here again, the part B is stored, and an identification of that part file is made available in the public list of file for browsing by other end-users. Advantageously, part B could be stored in a removable memory card, such as an MMC card.

The drawing also shows a mobile communications device 7 of another end-user. If that end-user wants to obtain the file 2, this can be obtained from the mobile communications device 5. In order to do this, the mobile communications device 7 uses a browser to browse the public list of files stored in the device 5, and then to request a particular file (say the file 2) of interest. Thus, where the parts A and B of the file were merged straightaway in the mobile communications device 5, that device will encrypt the entire file using the key K, and then transmit the encrypted file to the device 7. The user of the device 7, after having received the encrypted file, will access the NON 3 to receive a key to decrypt the file. When accessing the NON 3, that user will be authenticated and charged/billed for the file. The mobile communications device 7 of that user will need to send information about the file that has been transferred and from whom it is received, in order to permit the system to give that other user the correct key to decrypt the file. This key may be the key K or another key. At the same time, that user receives a second key K2. This key K2 will be used to encrypt the file again, so that that user can pass the file on to yet another end-user. This further end-user will then need to contact the NON 3 to obtain a key to decrypt the file, and a further key K3 for encrypting the file for sending on to yet another end-user. When accessing the NON 3, the further end-user will be authenticated and charged/billed for the file, again after sending information about the file transferred, and from whom it is received. In this way, the file can be passed on through multiple users, each of which can then decrypt the file and use it.

Where the parts A and B were stored separately on the mobile communications device 5, the file can be re-assembled and encrypted before being sent to the mobile communications device 7 of the other end user, or only the part B is sent to the mobile communications device 7 of the other end-user. In the case only part B is sent, on receiving the part B, that user will access the NON 3 to request the part A. When accessing the NON 3, that user's mobile communications device 7 will be authenticated, and that user will be charged/billed for the file. As before, the process can be replicated to further end-users, all of which can replicate to other end-users and so on.

In order to produce the part A, the file 2 is first RS A encrypted. Assuming, for the sake of simplicity, that the file part B is 10% of the file 2, 1/lOfh of the bits have to be removed. In order to do this every 20th bit is then removed from the file 2, and the remaining 5% of that file is removed from random locations. If any random location defines a sequence of consecutive bits on a random length, that random length has a maximum of 0.5% of the total length of the file. The off-set of where bits are removed randomly, and the length over which random bit lengths are removed is appended at the end of the remaining file (that is to say that part of the file which remains after the 10% has been removed). A 32 bit mask is then created, and the data is XORed with the 32 bit mask, 16 bits of the XORed mask being placed at the beginning of the remaining file, and 16 bits at the end. When the user of the mobile communications device 5 downloads the part A, it reads the mask and inverts the XOR process. The device 5 then contacts the NON 3, and requests the missing data from the table extracted from the end of the file, that is to say the 5% of the data which was randomly removed from the file 2. Those missing pieces are then inserted at the right places, after which every 20th bit, that is to say the 5% of the data which was removed as every 20th bit from the file 2, is requested from the NON 3 and inserted at the appropriate place. Finally, the file is decrypted.

In a modified arrangement, the file part B could be stored at a dedicated base station rather than on the Internet 4. In this case, the part files B could easily be downloaded to the mobile communications device of an end user using, for example, Bluetooth or some other suitable wireless protocol. An advantage of this arrangement is that users could be provided with the locations of dedicated base stations, so that users can readily access the files of interest. Another advantage of this arrangement is that, where the part files B are applications such as game files, those part files could be up-dated, on a regular basis, by a service provider server so that users can update their files. That server would contain a large number of data files. The server would then place the parts A and the parameters used for file splitting onto the NON 3 and the parts B onto the dedicated base stations. Each base station may be a server (or a PC) having a hard disc for file storage.

Claims

1. A method of transferring a data file from a service provider to a mobile communications device, the method comprising the steps of splitting the file into first and second parts, transmitting the first and second file parts over respective first and second communications routes from the service provider to the mobile communications device, and reassembling the file from the first and second file parts at the mobile communications device.

2. A method as claimed in claim 1, wherein the first file part is larger than the second file part.

3. A method as claimed in claim 2, wherein the first file part is at least an order of magnitude larger than the second file part.

4. A method as claimed in claim 2 or claim 3, wherein the first file part is more than 99% of the data file.

5. A method as claimed in any one of claims 1 to 4, wherein the first communications route is a lower cost route than the second communications route.

6. A method as claimed in any one of claims 1 to 5, wherein the first communications route includes first and second parts, the first part of the first route being an Internet connection between the service provider and a computer, and the second part of the first route being a short-range communications link between the computer and the mobile communications device.

7. A method as claimed in any one of claims 1 to 5, wherein the first communications route includes first and second parts, the first part of the first route being from a dedicated server associated with the service provider to a dedicated base station, and the second part of the first route being a short-range communications link between the dedicated base station and the mobile communications device.

8. A method as claimed in claim 7, wherein the dedicated server contains a large number of data files, and means are provided for updating the data files.

9. A method as claimed in any one of claims 6 to 8, wherein the second part of the first communications route is constituted by a wireless connection.

10. A method as claimed in claim 9, wherein the wireless connection uses the Bluetooth protocol.

11. A method as claimed in claim 9, wherein the wireless connection uses the 802.1 lb protocol or any other protocol from the 802.11 family.

12. A method as claimed in any one of claims 1 to 11, wherein the second communications route is a network operator network associated with the service provider.

13. A method as claimed in any one of claims 1 to 12, wherein the file is split into the first and second parts using an algorithm that ensures neither of the file parts can be used by a user of the mobile communications device until the file has been reassembled.

14. A method as claimed in any one of claims 1 to 13, wherein the user of the mobile communications device is charged/billed for the data file when the second file part is transmitted.

15. A method as claimed in any one of claims 1 to 14, wherein an encryption key is sent to the user of the mobile communications device with the second file part, and wherein the encryption key is subsequently usable by the mobile communications device for encryption of the second file part for transmission to another mobile communications device.

16. A method as claimed in any one of claims 1 to 14, wherein an encryption key is sent to the user of the mobile communications device with the second file part, and wherein the encryption key is subsequently usable by the mobile communications device for encryption of a complete re-assembled file part for transmission to another mobile communications device.

17. A method as claimed in claim 15 or claim 16, wherein the user of said another mobile communications device accesses the service provider to obtain a key for decrypting the received encrypted file part, the service provider sending charging data with said key.

18. A data file transfer system comprising a service provider and a mobile communications device, the service provider comprising a memory for storing a data file, means for splitting the data file into first and second parts, and means for transmitting the first and second file parts over respective first and second communications routes to the mobile communications device, and the mobile communications device having means for reassembling the file from the first and second file parts.

19. A system as claimed in claim 18, wherein the memory of the service provider is such as to store a large number of data files.

20. A system as claimed in claim 18 or claim 19, wherein the first communications route includes first and second parts, and the system further comprises an intermediate device, the first part of the first route being between the service provider and the intermediate device, and the second part of the first route being a short-range communications link between the intermediate device and the mobile communications device.

21. A system as claimed in claim 20 wherein the intermediate device is a computer.

22. A system as claimed in claim 21, wherein the first part of the first route is an Internet connection.

23. A system as claimed in claim 20, wherein the intermediate device is a dedicated base station for storing a plurality of first file parts.

24. A system as claimed in any one of claims 20 to 23, further comprising a dedicated server associated with the service provider, the dedicated server including a memory for storing a large number of data files.

25. A system as claimed in any one of claims 18 to 24, wherein the short-range communications link uses the Bluetooth protocol.

26. A system as claimed in any one of claims 18 to 24, wherein the short-range communications link uses the 802.11b protocol or any other protocol from the 802.11 family.

27. A system as claimed in any one of claims 18 to 24, wherein the short-range communications link is a universal serial bus.