WO2004044756A1

WO2004044756A1 - System and method relating to remotely accessible securely stored data files

Info

Publication number: WO2004044756A1
Application number: PCT/AU2003/001489
Authority: WO
Inventors: Danielle Lehrer
Original assignee: Mobidata Group Pty Limited
Priority date: 2002-11-14
Filing date: 2003-11-11
Publication date: 2004-05-27

Abstract

In a first broad form the present invention provides a method of and system for granting access to one of a plurality of versions of a data file, wherein a Uniform Resource Identifier (URI) is associated with said data file and said URI is associated with an access list which includes details of one or more parties who are permitted access to a particular version of said data file, such that a certain party is granted access to a first version of the data file, and another party is granted access to a second version of the data file, and each party is directed to the appropriate stored version of the data file as directed by the access list. If desired, more than two parties can be granted access to versions of the data file.

Description

SYSTEM AND METHOD RELATING TO REMOTELY ACCESSIBLE SECURELY STORED DATA FILES

Technical Field The present invention relates to a secure data or record storage system and method, a mobile networked identification system and an authentication or identification system and method based around use of a mobile communication device.

Background of the Invention

Presently, in prior art systems a user of a mobile communication device only stores data locally on the mobile communication device. If the user loses the mobile communication device, for example a mobile or cellular phone, which is an all too common occurrence, the user is inconvenienced and the data stored therein may be subject to a security concern, as personal data may be lost to the user or misused by another party in the event that the mobile communication device is lost or stolen.

Prior-art systems are known which allow 'business cards' to be sent via SMS. However, this does not allow a user to readily define different groupings of the user's own contact data so that different users can have access to different items of information. Prior art systems also raise concerns as to whether data is current and backed-up in the event that the mobile communication device, or SIM card in the case of a mobile telephone, is lost or damaged. Furthermore, prior art systems do not allow a user to provide access to different versions of data files, for example contact information, to different parties.

Still furthermore, presently the means by which an individual can prove his or her identity to a third party are generally limited to supplying hard copies of specific documents such as driving licences, passports or birth certificates. Other secondary forms of identification such as credit and bank cards may also be required. However, a problem with all of these forms of identification, and particularly the secondary ones, is that they can be relatively easily forged or stolen, thus allowing one individual to pass themselves off as someone else. This is also an inefficient means of proving identity, requiring an individual to firstly locate then physically transport valuable documents, introducing the possibility of loss.

In a networked data communications system, users have access to communication devices which are capable of requesting and receiving information and data (or data files) from remote information sources. In such a system, a mobile communication device may be a type of computer or computerised device, a mobile or cellular phone, a mobile data terminal, a personal digital assistant (PDA), a portable radiotelephone, an interactive television, a pager or any other similar type of transportable electronic device. The capability of the mobile communication device to request and/or receive information can be provided by an application program, hardware or other such entity.

An information source may be a server or any other type of computerised device coupled to an information storage device. The exchange of information or data (i.e. the request and/or receipt of information) between the mobile communication device and the information source, or other terminal(s), is facilitated by a communication channel, such as a physical line, optical cable, electromagnetic signal, RF signal, Bluetooth, IrDA, satellite link, ect., or any other such medium associated with a network infrastructure. The infrastructure may be a telephone switch, a base station, a bridge, a router, or any other such specialised component, which facilitates the connection between the mobile communication device and the information source.

Disclosure of Invention The present invention includes a number of different aspects, which may exist singly or in combination within the same system. Systems and methods employing embodiments of the invention have many uses, but a preferred use is in remote and secure access to personal data, which may find uses in e- commerce and banking applications.

In a first broad form of the present invention, there is provided a method of storing a copy of data stored on a user's mobile communication device in a database on a remote central server, including the steps of: providing wireless communication means between the mobile communication device and the central server; assigning to the user a secure data storage space on the central server; copying data stored in the mobile communication device to the assigned secure data storage space on a periodic basis or by specific user initiated instruction; and, allowing access to the stored data by a user operating a mobile communication device after the user's access right is verified.

According to particular aspects of embodiments of the invention: data is only transmitted to the central server when there has been a change in the data; a checksum, or other data transmission integrity procedure, attached to data files is utilised; the data includes an image of an user's identification document(s); the communication between the mobile communication device and the central server utilises an HTTP, HTTPS or SSL connection; the user is required to submit a password to access the stored data; each user's data is stored in separate directories and is encrypted; data updates to the central server are dynamically replicated to one or more additional servers providing data redundancy; the user can grant access to the stored data to another person by providing the another person with a private key; and/or the stored data can be replicated on a second mobile communication device after user authentication.

In a second broad form of the present invention, there is provided a system for storing a copy of data stored on a user's mobile communication device, the system including: a central server; a storage unit to house a database; a wireless communication network between the mobile communication device and the central server; an input device associated with the central server to receive the copy of data transmitted by the mobile communication device; at least one processor, the at least one processor being adapted to: assign to the user a secure data storage space in the database on the central server; facilitate copying of data stored in the mobile communication device to the assigned secure data storage space on a periodic basis or by specific user initiated instruction; and, allow access to the stored data by a user operating a mobile communication device after the user's access right is verified.

In a third broad form of the present invention, there is provided a method of accessing data stored on a central server using a mobile communication device, wherein the data stored on the server is compressed and encrypted, until access is requested from the mobile communication device, whereupon the compressed and encrypted data is decompressed and unencrypted on the basis of a secure key, and transmitted to the mobile communication device.

Preferably, the mobile communication device is a programmable or smart telephone. According to other possible aspects, the mobile communication device retains a local cache of at least some of the data which is also stored on the central server, and/or the local cache includes an index to the data stored on the server. In a fourth broad form of the present invention, there is provided a method for sharing contact information between a first user and a second user, wherein: the first user groups individual contact details together and associates the individual contact details with a unique identifier; the grouped details are transmitted to a central database; and, the second user is able to access the grouped contact details from a portable telephone by entering the unique identifier when prompted.

In a fifth broad form of the present invention, there is provided a method of providing remote access using a mobile communication device via a network to one of a plurality of stored versions of a data file, wherein a Uniform Resource Identifier (URI) and an access list are associated with the data file, said access list including details of one or more parties permitted access to a particular version of said data file, such that at least a first party is granted access to a first version of the data file when the first party utilises the URI to locate the data file, and at least a second party is granted access to a second version of the data file when the second party utilises the URI to locate the data file, and each party is directed to the appropriate stored version of the data file as directed by the access list.

According to further particular aspects of embodiments of the invention: the versions of the data file are stored on a party's mobile communication device and are replicated on a central server; more than two parties are granted access to versions of the data file; the versions of the data file are transferred between parties' mobile communication devices using a peer-to-peer network; the versions of the data file can be accessed on the central server if a mobile communication device is unavailable; each party is directed automatically to the appropriate version of data file; if a party is removed from the access list the party cannot access any version of the data file; the versions of the data file can contain substantially different information; the data file is a party's contact details; a first party can provide contact details to a second party by providing a unique identification code to the second party; the first party can assign different groups or parts of contact information to different identification codes; the access list and versions of the data file can be amended on the central server via an Internet connection to the server, and communicated to a party's mobile communication device; the number of maintained versions of the data file is selectable by a party; and/or the second party is required to authenticate itself at the central server before being provided with access to the data file.

In a sixth broad form of the present invention, there is provided a system for providing remote access to one of a plurality of stored versions of a data file, the system including: a network connecting one or more mobile communication devices and a central server, the one or more mobile communication devices and the central server able to store the versions of the data file; means to provide a Uniform Resource Identifier (URI) and an access list associated with the data file; the access list including details of one or more parties permitted access to a particular version of said data file, such that at least a first party is granted access to a first version of the data file when the first party utilises the URI to locate the data file, and at least a second party is granted access to a second version of the data file when the second party utilises the URI to locate the data file; whereby, each party is directed to the appropriate stored version of the data file as directed by the access list.

In a seventh broad form of the present invention, there is provided a method of identifying a person, including the steps of: the person providing documentary evidence of his or her identity to a trusted source; the trusted source satisfying itself of the person's identity; the trusted source creating a data file which can be used to verify the identity of the person; the trusted source encrypting said data file; a user seeking to verify the identity of the person being provided with a URI associated with the encrypted data file; the trusted source providing a decryption key to the user, allowing the user to decrypt and view the data file and thereby authenticate the person's identity.

According to a particular aspect, the trusted source encrypts the data file using a public key of the trusted source, and the trusted source further encrypts the encrypted data file using a private key of the trusted source and a private key of the person. Preferably, the encrypted data file is stored in a secure data storage space allocated to the person on a central server. The person can access the encrypted data file using a mobile communication device or a computer via an Internet connection.

In an eighth broad form of the present invention, there is provided a method of identifying a person, whereby a first person may authenticate his or her identity with a second person, using a mobile communication device having a SIM, the method including the steps of: the first person providing to the second person, using a communication means associated with the mobile communication device, a copy of the SIM record encrypted with a private key of the first person, an encrypted identity-proving data file and a public key of the first person; the second person decrypting the identity-proving data file using a public key available from a trusted source and the first person's public key to render the data file readable; the second person decrypting the encrypted SIM record using the first person's public key, and comparing the decrypted file with one available from the trusted source; the second person creating a private message including a random key known only to the second person, encrypting said private message using the first person's public key and the second person's private key, and sending said message to said first person; the first person, upon receipt of said private message, decrypting said message using the public key of the second person and the private key of the first person to reveal the random key; the first person sending to the second person a message including the random key, said message being encrypted using the first person's private key; and, the second person, upon receipt of the message, decrypting said message using the public key of the first person, so as to finalise the authentication of the first person.

Advantageously, the aforementioned systems and methods provide data security, as each user's data is stored in a unique data file which is separately compressed and encrypted ensuring that if access to one user's data file is compromised, no other user's data file is vulnerable.

The aforementioned systems and methods are preferably performed in a manner which renders the various message exchanges between parties largely invisible to the users. To that effect, suitable programmed mobile communication devices may be used which are arranged/programmed to manage all communications necessary with minimal instruction from the user.

Suitable communication channels for said exchanges include cellular data channels, Bluetooth connections and Infra-Red messaging (IrDA).

The skilled person should realise that some or all of the forms of the invention can inter-operate, and the following description should be understood accordingly. Other broad forms of the invention include suitably adapted and/or conditioned devices arranged to perform methods referred to previously.

In particular, it is advantageous to perform methods according to embodiments of the invention through use of a suitable programmed smart phone, that is a portable communication device arranged to be programmable, and able to communicate with a suitable communication network.

Embodiments of the invention further allow restricted access to the contact data, and allow versioning, back-up and automatic updating of the contact data, as described herein.

Brief Description of the Drawings

For a better understanding of the present invention and to understand how the same may be brought into effect, the invention will now be described by way of example only, with reference to the appended drawings in which:

Figure 1 illustrates a system providing a particular embodiment of the present invention;

Figure 2 shows a system/method according to an embodiment of the invention whereby an owner of certain information is able to control access to versions of that information;

Figure 3 illustrates the transfers between three parties seeking authentication of an individual;

Figure 4 illustrates a further specific example of a system design diagram according to the present invention;

Figure 5 illustrates a further specific example of the hierarchy and trust arrangement in the a specific embodiment of the invention;

Figure 6 illustrates a further specific example of system components according to a particular embodiment of the invention; and Figure 7 illustrates a further specific example of a system using authentication with a banking system.

Modes For Carrying Out The Invention

The following modes are described as applied to the description and claims in order to provide a more precise understanding of the subject matter of the present invention. The modes describe various aspects of the present invention including Secure Record Storage, Accessing Versions of Data, and Authentication.

Secure Record Storage System Embodiments of the invention permit secure storage and retrieval of personal records from any suitably connected device anywhere in the world. Suitable devices include, for example, mobile or cellular phones, portable radiotelephones, interactive televisions and portable computers.

Referring to Fig. 1 , the record storage system 100 allows a user to securely deposit electronic copies, for example digitally generated, facsimiled or scanned copies, of physical identification documents such as birth certificates, driving licences and ID cards in a central secure repository, to which access is restricted. The secure record storage may also be used to store original electronic documents such as digital signature certificates and the like. Other forms of non-identity documents may also be stored. Such documents may include items such as photographs which may be shared with all or selected third parties, work documents, contact details and other files.

A preferred embodiment of the present invention uses a cached client server architecture. However, other system architectures may also be used.

A particular embodiment of the present invention can be realised using the processing system 100. In particular, the processing system 100 generally includes at least a processor or processing unit 102, a memory 104, a data input receiving device 106 and a data output device 108 (which in one embodiment may be the same device as input device 106), coupled together via a bus or collection of buses 110. An interface 112 can also be provided for coupling the processing system 100 to a storage device 114 which houses a database 116 (or databases) of records, data or information. The memory 104 can be any form of memory device, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. The data input receiving device 106 receives data input 118 and can include, for example, a network card, data input card, telecommunications hardware, etc. The data output device 108 produces data output 120 and can include, for example, a network card, data input card, telecommunications hardware, etc., and may physically be the same device as device 106. The storage device 114 can be any form of storage means, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc.

In use, the processing system 100 is adapted to allow data or information to be stored in and retrieved from the database 116. The processor 102 acts on instructions typically stored in memory 104 and utilises data input 118. Mobile communication device 122 is operated by a user and transmits data 128 which is either received directly by input receiving device 106, or by some other device and then introduced into network 126 which then facilitates transmission of data to the input receiving device 106. Data output 120 is transmitted to network 126 or directly to mobile communication device 122 or another terminal 124, which may also, but not necessarily, be a mobile communication device. Terminal 124 could belong to the user or another party. In certain situations the mobile communication device 122 may be able to communicate with system 100 via a physical communication channel and network 126 as illustrated. It should be appreciated that the processing system 100 may be any form of processing system, computer terminal, server, specialised hardware, or the like.

A central repository (database) 116 is maintained which includes data which the owner wishes to be able to access from anywhere where a suitable data connection 126 or 128 is possible. The connection is made between the mobile communication device 122 and the central store (storage device) 114 using an HTTP connection. In order to ensure that the person seeking to connect is authorised to access the stored data in database 116, a secure login may be provided. Interactions with the central store 114 are performed using HTTP POST commands. These commands include session information and details of the last transaction performed. By including the details of the last transaction performed, the chances of an authorised party gaining access to the data is reduced, as they are extremely unlikely to have access to this information, but it can be conveniently stored in the user's access device 122.

To provide increased security, access to the central store 114 may be effected using HTTPS and secure sockets technology. Such technology ensures that transactions between connected devices are encrypted, thus rendering the transactions more immune to interception by unauthorised third parties.

The underlying architecture maintains all session information with the client/user at all relevant times. This can be achieved through the use of hidden fields in Web requests, or as converted Java session XML documents. No system state information is stored or persisted except for that data which is explicitly stored. In this way, superfluous data storage is minimised, and more importantly, any device may continue from where any other device leaves off in the event of failure of a device or connection, as all the information required to do this is maintained in the XML documents, which include the system state information.

Data traffic may be reduced by use of the Web Parameter form of "key=value&". In this way, the parsing of text on a user's device is kept to a minimum, as is the flow of data which would otherwise occur.

When a user connects to his or her record store, the user is assigned a unique data space within which to operate. All the records in that user's space are kept physically separate from each other user's records, by storing the records in a separate directory. This allows for greater security, as each directory, corresponding to each user, may be encrypted and stored separately, so that if the security of a single user is compromised, no other records should be in jeopardy. Individual records are stored in text format, by the text representation of key values, or, in the case of images, as uploaded files. Image files are preferably stored in PNG format, and may be automatically converted into this format if images are uploaded in other image formats. The use of PNG format allows different types of devices to display the images in a consistent fashion. Users may additionally be given the option of storing images in a particular format if that format would be better suited to a particular device.

Users may define and create additional folders which are stored in the normal manner within their own personal space. In this way, separate folders may be assigned to photographs, legal documents, identity documents and so on.

Once a user has completed a session, all the files in a user's data space are copied into a compressed file, such as a ZIP file, and is then encrypted using a strong encryption scheme such as PGP. Any non-encrypted files are deemed to be trivial and are deleted. In order to enable recovery of all a user's files in the event that the user loses the key, an administrator version of the compressed file may be created using the administrator's public key. In this way, an owner who loses a key or password may approach the administrator of the system who will be able to recover the data, using the associated private key. This last option may be disabled by the owner of the data, but file recovery will not then be possible.

The files are compressed to ensure that access to the site is load balanced, and connections are managed across devices. In practice, when a connection is completed, the contents of the user's data space are compressed into a ZIP file. When that user re-connects, network load is balanced in such a way that the new connection is allocated to a less utilised node to ensure that overall load is not too great on any particular node.

When updates are made to a user's data space, the same updates are dynamically replicated to one or more additional servers in order to ensure that a suitable level of system reliability is maintained. If, for example, a particular home server fails, all data traffic is re-directed to a backup server, so that a user of the system should not notice that there has been a problem.

According to a further particular aspect, when storing data in a personal data space, a user may assign a security level to individual records so that access can be granted to one or more selected individuals or groups aside from the actual user (i.e. owner). In this way, the user can choose to share some or all of the stored data with friends, family or selected individuals.

When another person is granted access to one or more records, they are given the private key to a given set of data using a secure record transfer mechanism which is described in detail later. In this way, the owner can restrict exactly who has access to any particular record by controlling who has access to the necessary key. The owner may allow open access to any document by explicitly storing the record with no encryption.

In addition, the owner of the information may set up the records so that different users have access to different versions of particular records. This is described in more detail later.

When a user accesses the data stored at the remote server, the local device (i.e. mobile communication device), which is preferably a wireless device such as a smart phone, caches a local copy of the accessed data. In this way, a user can retain access to certain elements of the user's stored data locally, and won't always need to access the server to view records. The user may assign a certain amount of memory to store local records. The records stored on the local device include at least an index to the records stored remotely, and whatever portion of the remote data can be stored within the constraints imposed by the amount of memory allocated locally. The index is kept locally so that the records may be navigated without the need to store all of the data on the local device. To manage the data stored locally, records, particularly images which are memory intensive, are arranged to be deleted routinely on a least-recently accessed basis.

In order to ensure a seamless interface, from the user's perspective, all the records on the local device, are backed up to the secure server on a defined incremental basis. In this way, if the user loses the mobile communication device, eg. the user's mobile phone, which is an all too common occurrence, the data is preserved and may be easily re-created in a new replacement device. Such a system enables a user to gain a degree of security for the user's personal data, and not worry that all such data will be irreplaceable in the event that the mobile phone is lost or stolen. The software in the mobile communication device may periodically backup the data, or may only do so when a certain number of changes have been made, or the user may specifically initiate a backup operation explicitly.

In order to reduce the amount of data transferred, each data file has an associated checksum related to the data in the file. In this way, when transferring data, the phone only sends files which have different checksums, and hence different contents, to the secure server. Other, unchanged copies are not sent. Data exchanges between the phone device and the secure server may be effected using any suitable communication protocol. Phones such as the Nokia 7650 smart phone use GPRS to effect data transfer, but other suitable devices may use regular GSM, WCDMA or analogue technologies. Phones which will be available in the near future will use third generation technologies.

In addition to use of the preferred mobile phone, the user may access remote secure data through use of any other communication device, for example a suitably enabled personal computer or web-connected television.

Accessing versions of data A problem with electronically stored data, as with more conventionally stored physical data, is that it can easily become out of date. For instance, when two parties exchange business cards, there are a large number of pieces of information which can change, and render the card obsolete. For instance, a party's name may change due to marriage, the party's business address may change, the party's email address may change or a company name may change due to merger or takeover. Embodiments of the invention allow information to be exchanged between parties securely and also allow the information to be kept up to date in such a way that the party owning the information can control which other parties may have access to the most current, or other, versions of it.

Fig. 2 shows a scenario where a person 200 has passed on his or her business card and contact information to two parties 210, 220. The form of the contact details is a URI 250. This is effectively an address which points to a location where the actual data is stored. However, embodiments of the invention utilise versioning of data, which allows different versions of essentially the same data to be stored simultaneously and differentiated by means of a different version number.

In the present scenario, the owner of the information stores his personal information on a computer or other electronic device. There are two versions stored on the computer - an old version and an updated version which includes new contact details. The owner 200 can control by means of an authorised party list which parties have access to which data, even though both parties gain access to the data via the same URI.

As well as the data being stored on the owner's personal device, for example the owner's mobile communication device, it is replicated to a central server. In this way, if any party attempts to access the URI which points to data stored on the owner's electronic device and it is not available, the party can be automatically re-directed to the centrally stored replicated version. The party need not be aware of this action. Party 210 is a friend of owner 200 and the owner wishes him or her to have access to the updated record 260 via access to the URI 250. As the friend's identity is registered on the access list for the updated record, when party 210 accesses the URI 250 from a computer, he or she is directed to the updated version 260 of the record including the owner's contact details.

However, party 220 is a person to whom the owner no longer wishes to allow access to his or her updated records. As such, party 220 is registered on the access list as only being allowed access to the old record 270. In this way, even though party 220 accesses the same URI 250 as party 260, party 220 will be directed to the physical record 270 which does not reveal the owner's 200 new contact details.

As an alternative, the owner 200 could simply remove the party 220's details from the access record such that if the party 220 tries to access the URI 250, the party 220 can be informed that the record is no longer available and has been removed from the system.

The approach adopted here can be contrasted with that used in typical prior art web-based systems which have no inherent versioning capability.

The approach used in embodiments of the invention is to transfer pointers (URIs) to data, rather than transfer the actual data itself. In this way, there is a single authoritative copy of the data (plus a replicated backup as described) in existence which can be updated, and can co-exist with earlier versions of the data. In this way, access to different versions of the data can be granted to different parties, allowing the owner of the data to exercise a degree of control over who has access to the data.

As the owner of the data has write access to all versions of the data, the owner can control the number of previous versions which are maintained. The system may be programmed to automatically delete previous versions of a file if more than a predefined number of versions are stored, or a version may be removed it is no longer referred to in the access list.

As the data is not primarily stored in a central database, and instead a peer-to- peer system is used, there is less chance of a bottleneck occurring in the data traffic, as there is no central point which is constantly accessed. The central server which replicates data can be accessed, but only in the event that the owner's device is unavailable. Statistical analysis of all connected devices and their availability can be performed to estimate the amount of data traffic likely to be experienced by the central server, so that its specifications may be defined accordingly.

In an embodiment of the invention, it is possible for two suitably registered users of the system to exchange contact details without having to manually enter the respective details. This is advantageous as entering address and other details using the generally small keypads provided on mobile telephones is time consuming, error-prone and can require great dexterity.

If a first user wishes to pass his or her contact details to a second user, the first user simply passes a unique identification code to the second user. The identification code can include a string of numbers or other characters, and uniquely identifies certain contact information of the first user.

To set up the information and unique identification code, the first user selects which parts of his or her contact information he or she wants to be available under a specific identification. In this way, the user can assign different groups of contact information to different identification codes.

For instance, the first user might be assigned the unique identifier 768543. The user can elect to further refine the information made available to different users by appending further digits to this identification number, so that if the user wishes to reveal a personal home address and telephone number, that group of information can be identified as 768543-1. The user's business contact details may be identified as 768543-2. If the user wishes to reveal all the user's various contact details, the user may assign the identification 768543-9, for instance. In any event, the root of the unique identification number is assigned by the system operator, and the user may append digits as shown above to further refine which information is revealed to other users.

If the first user then wishes to give business contact details to the second user, the user may do this in one of several different ways. The second user could simply select an appropriate menu option on the second user's smart phone to enter the unique identification manually. The entering of the data in this manner causes a query to be transmitted to the central database which holds all the data pertaining to each unique identification. The database can then respond to the second user with a message including the contact data of the first user. This data can be stored locally in the second user's smart phone, but can also be backed up in the central system as previously described.

To prevent the abuse of contact information, and to ensure that only authorised recipients are allowed to access the information, the steps described above can be modified to include a step whereby the first party explicitly allows the second party access to his contact data by sending a message to the central database including the identification of the second party, which serves as an authority from the first party to allow the second party access to the data.

Instead of entering the data manually, the first use may be able to transfer the unique identifier via use of a short-range communication medium such as Infra- Red or Bluetooth low-power RF messaging. Another alternative would be to transmit the unique identifier via SMS. In any event, the users will not need to explicitly enter the contact data itself, as this will be managed by the central system in a manner which is invisible to the users. Once the contact data has been added to the second user's contact list, it can be updated automatically, as described elsewhere herein, provided that the first user continues to allow the second user access to his contact data. At any time, the first user can re-direct the second user to a different version of his contact data, or even bar the user from accessing any details at all.

In contrast to prior-art systems which allow 'business cards' to be sent via SMS, embodiments of the invention offer advantages in that users can easily define different groupings of their own contact data so that different users can have access to different items of information. Also, embodiments of the invention allow the data to be automatically updated and stored centrally, ensuring that it is always current and always backed up in the event that the mobile phone or SIM is ever lost or damaged.

Authentication

In prior art systems, the means by which as individual can prove their identity to a third party are generally limited to hard copies of specific documents such as driving licences, passports and birth certificates. Other secondary forms of identification such as credit and bank cards may also be used. However, a problem with all of these forms of identification, and particularly the secondary ones, is that they can be relatively easily forged or stolen, thus allowing one individual to pass themselves off as someone else.

If a forgery of a particular document is discovered, or if a party is discovered attempting to use a stolen document, there is currently no simple way to alert the appropriate authorities so that preventative action may be taken.

Embodiments of the invention attempt to address these and other problems with prior art identification documents. Embodiments of the invention utilise the capabilities afforded by so-called smart or programmable mobile phones such as the Nokia 7650. Such devices offer mobile access to computer systems, and can be programmed to perform a variety of different tasks. Since more and more people are routinely carrying with them portable telephones, it is advantageous to make use of their capabilities to allow them to perform authentication tasks.

Embodiments of the invention allow an owner of certain identification documents such as driving licence, passport and birth certificate to create facsimile copies of each document which can then be processed electronically by a so-called trusted source. Trusted Sources are organisations which are authorised to verify the authenticity of the documents. The process which they perform on the electronic copies of the documents include the creation, using their private key, of an encrypted version of each document, as well as the creation of a private key encrypted certificate stating that they have also encrypted the electronic version of the document.

These encrypted documents are then stored in the user's secure data space referred to previously and indelibly linked to the owner's record store. The owner of the records can then access them from their mobile device, personal computer or other designated device.

It is thus possible for a third party to authenticate an individual by exchanging a record using the previously described mechanism i.e. by the owner of the record passing on a URI which points to the appropriate document. Once this has been completed, the party seeking authentication then has an encrypted version of the identification document.

In order to decrypt the document, the party seeking authentication is able to obtain the public key of the trusted source, by using the previously described mechanism for exchanging records, and is therefore able to decrypt the encrypted document either on a smart device or using a secure proxy device, such as a dedicated remote server. ln this way, the party wishing to authenticate a particular person's identity is able to do so based on the prior certification of the original identity document by the trusted source.

The approach adopted by embodiments of the inventions offers increased security over prior art approaches which rely on the use of easily lost or forged paper documents. In the event that the original paper documents are mislaid, the owner is able to rely on the certified electronic versions to obtain replacements if that should be necessary.

As the owner of the electronic documents retains them under his control at all times, the possibility of a third party obtaining the documents and assuming the owner's identity can be minimised. Also, there is no requirement to transmit any private data to perform authentication, again reducing the possibility of a third party intercepting the information.

In addition to authenticating a user through use of pre-processed identity documents, further embodiments of the invention utilise bio-authentication where one or more aspects of the user's physical characteristics are used to verify identity. Various widely available systems are available which may be included in the portable device in order to perform this function. For instance, voice authentication systems are available from Speechworks (www.speechworks.com) and Voice Security (www.voice-security.com). and these may be readily included in a portable programmable device to verify the identity of a user. Various other physical characteristics may be tested to prove identity. Such schemes include facial recognition and fingerprint recognition.

As the authentication is managed by accessing centrally stored certified records, it is a straightforward task to remove all access rights to the electronic authentication documents if the owner suspects that their security has been compromised. This can be achieved by a user telephoning a central authority, or accessing his records from a suitable device and manually altering the access rights to the records.

As an example of the transactions required in order for a party to be authenticated, consider the following situation, illustrated in Figure 3.

A person 300 wishes to acquire a means by which they will be easily able to verify their identity and credentials to third parties 310. Firstly, according to an embodiment of the invention, the person 300 is required to physically present their appropriate identity documents such as passport, birth certificate, drivers licence, or the like, to the trusted source 320, which may be a bank or other trusted body.

In order for an individual 300 to know whether a trusted source 320 is actually to be trusted, the trusted source advertises its public key and those of other trusted sources at several IP addresses. Individuals wishing to determine the trustworthiness of a particular source can cross-check a particular source's information with that available from other trusted sources. In this way, different trusted sources are able to vouch for each other's trustworthiness, resulting in a system which is quite immune to abuse, as each trusted source would need to be compromised in order to falsify all records.

Once approached by the individual 300, the trusted source 320 performs whatever checks are necessary in order to satisfy themselves that the person is who they are claiming to be. The trusted source then creates appropriate data files, which are preferably configured as a single data structure or file, which may be used to verify the identity of the person 300. The data file is encrypted using the public key of the trusted source. This is so that the trusted source is later able to verify the authenticity of the records using its private key.

Once the data file has been encrypted with the trusted source's public key, additional authentication information, as determined by the issuing authority, is augmented to the data structure if required, and the entire data structure is encrypted twice more using the trusted source's private key and then using the individual's private key.

Once this process is complete, the encrypted data structure is stored in the user's personal data space, as previously described, for later authentication purposes. The individual also registers the SIM card of their mobile device, together with their public key, with the trusted source. The SIM data is encrypted using the trusted source's private key. This data may then be advertised as required when authentication is requested. Using the SIM data together with the other authentication data ties the authentication data securely to the individual's mobile device.

When the individual 300, who has been through the above process, needs to authenticate his or her identity to a third party 310, he or she is able to do so by providing to the third party 310, by means of a suitably equipped and programmed portable communication device, the private key encrypted version of his SIM record, the encrypted authentication record stored in the user's personal data space and their public key.

The third party 310 then obtains a copy of the trusted source's public key from the trusted source 320, usually via a website, and then decrypts the authentication record using the trusted source's public key and the individual's public key. The authentication record is then rendered in readable plain text.

The next step is to decrypt the SIM record using the individual's public key, and then match the decrypted result with the record available from the published by the trusted source on their website.

Next, the authentication information and the trusted source's public key are read from the decrypted record, and the trusted source's public key is then matched against that read publicly. The third party 310 then encrypts a private message, containing a random key known only to the third party, using the individual's public key and their private key, and sends it to the individual.

Upon receiving the message from the third party 310, the individual 300 decrypts it using the third party's public key and his own private key. The individual then encrypts it again using a private key, sends it back to the third party who decrypts the message using the individual's public key to finalise the verification of the third party Upon receiving a copy of the aforementioned random key from the individual 300, the third party can be sure that the individual is who he or she claims to be and the authentication process is complete.

In the event that the user loses his mobile device, he is protected as access to the device is password protected and access to his personal data space is also password protected. In this way, access to his data files, and also his private key is not possible, and so the above described authentication process could not be completed.

If the mobile device is replaced after loss, the user should notify the trusted source of the new SIM details such that their records may be updated as necessary.

The above steps are performed automatically through use of a suitably programmed and conditioned smart portable communication device. In effect, the user of such a device does not have to perform each step of the process explicitly, as the controlling software operates in a manner rendering most steps invisible to the user.

Further detailed examples

The following detailed examples provide a more detailed outline of particular technical embodiments of the present invention. The detailed examples are intended to be merely illustrative and not limiting to the scope of the present invention.

Generally, a user can add to, or modify the content of the user's contacts list and at the next synchronisation the changes take effect on the server. Leaving the data stored on the user's phone and server identical. A user may retain and secure documentation on a remote server. A user may also authenticate secure financial transactions.

In the event that the information stored on a phone is lost, a user of the system can synchronise the phone with the server. Once synchronisation is complete, all information can be restored from the copy stored on the server.

Preferably, a web application is available to users, allowing users access to stored information via the Internet. The system provides a means for users to then make changes to this data, and upon the next synchronisation the changes can take effect on the user's phone.

Users are able to share information with other users (preferably subscribers) of the system. Making the exchange of information between users (including sensitive information) possible. Security and authentication measures ensure that data is only made available to users who should have access.

The system has the ability to perform synchronisation tasks reliably with a remote server. Therefore, a core functionality requirement of the user's device is that it must contain a synchronisation client implementation. SyncML is an industry standard synchronisation protocol, and API's for the construction of a SyncML client exist within version 7.0 of the Symbian Operating System so this is used in a particular implementation.

Preferred steps and/or features provided include: (1 ) The application loads in the background; (2) The application allows a user to synchronise contact data to a remote database; (3) The application ensures that data resides in the phones native management system; (4) Each user has multiple ID's (Active ID's) assigned that correspond to the user's HOME, BUSINESS, MOBILE and ALL sections; (5) Acitve ID's are used to assign tracking, matching and updating privileges; (6) The application accepts requests for users to be added to the contacts list based on the unique Active ID assigned to each users information categories; (7) The application allows a user to ban other users according to Active ID; (8) The application allows a user to permit another user to subscribe to contact updates based on AID; (9) The application overwrites PIM information for entries which have an AID; (10) The handset application allows users to update daily, weekly, ect., or now; (11 ) The application supports the transmission and secure storage of identity information; and (12) The application supports the transmission and secured validation of identity information to third parties.

Referring to Fig. 4, the communications server 410 is a full scale sync server compatible with SyncML 413 and secure HTTP 415 to enable communications with a phone 417 according to standard protocols. The server 410 communicates with the repository application 419 to store and retrieve the user contact data.

A storage repository 421 is used for the 'Honeycomb' database 422 in which all user records and security information is stored. This includes: (1 ) Optimisation for large scale transactions - Scaled with J2EE; (2) Designed for multiple servers, geographically dispersed. The servers only share data which is likely to be required based on past requests and usage patterns. A query hierarchy allows peered servers to traverse the network to retrieve secure client records. The Authoritative relationships within the system repository and the traversal of a national network to retrieve a trivial password data element; and (3) Information security. Implemented in Oracle, sensitive information is held in a double encrypted form and processed back to standard encryption for transmission to the client device 417. A web client interface 423 is provided to enable users to manage a user's own database via servers 425 with similar functionality to that as the phone development. Additionally the web interface 423 can also give the user access to manage the user's current billing status and also modify preferences.

The billing system 426 holds the details from which a full accounting system 427 can be attached and/or developed. Specifically: (1 ) CDR - (Call Detail Record) A comprehensive record of each and every transaction to the repository can be recorded that can be queried to produce accurate and timely billing and security access records in several different formats eg. Usage based, Time Based, Traffic based or Subscription; (2) Addition, Modification and Deletion of user (customer) records (No user or data would be physically deleted. Logical deletion only); (3) Customer Demographics; and (4) Customer Preferences.

The repository store 421 allows any type of electronic file to be stored in a secure remote location and retrieved using a fixed 429 or mobile computing device 417. A user interface is available in J2ME to allow these files to be viewed and edited on a mobile phone 417, the same documents may also be forwarded to other parties and viewed via the Internet 431. An extension of this infrastructure to allow the secure exchange of identity information allows facilitation of tri-party authentication for ID authentication.

Fig. 5 illustrates the hierarchical structure of phone 417 and server 410 communication according to a particular embodiment. At step 510 the user sends login details to a master directory server. At step 520 the server receives the user request and forwards it onto a root directory server. At step 530 the user authentication request is transported via an encrypted tunnel. At step 540 the root server receives the request, processes it and returns user information to the requesting server. At step 550 the user authentication request is transported back again using encryption. At step 560 the server receives data and returns an allow or deny to the client/user. At step 570 the user receives allow/deny notification.

Referring to Fig. 6, the system 600 components include:

(1 ) File Repository 603, a Scaled RDBMS server with Internet connection.

(2) Client Agency Transaction Server 605 - The transaction server is a device on the agency side of the authentication process, for example, in the bank premises that brokers the ID authentication by making a list of current requests for authorisation available within the organisation.

(3) Client User application 607- The handset application used to request ID authentication.

(4) Trusted Agency Authentication Server 609- The trusted agency server that the Client Agency 605 and the Client User application 607 access to exchange and validate information.

Referring to the file repository 603, files, information or data is stored in an object-relational database, each class of file created by the user is an extension of the base 'userdocument' object. For each class of 'userdocument' object, a security parameter is recorded in the database. These may be - (1 ) open, (2) minussecured, (3) secured and (4) plussecured, further described below:

(1 ) - Open object, no encryption is applied to the stored object either in transmission or storage, but it is protected by the RDBMS access control to prevent access by unauthorised viewers.

(2) - Minussecured objects, no transmission security is mandated, but each object is encrypted within the data store on a per user basis, preventing casual access to the documents due to a misconfiguration or circumvention of the RDBMS ACL's. These objects are unencrypted prior to transmission. (3) - Secured object, transmission security is mandated, any transmission without encryption will result in a downgrading of the objects security status to minussecured or open if it is subsequently stored in unencrypted format.

(4) - ID class data objects are fully secured and signed in the Honeycomb cell encryption system and may only be transmitted via encrypted channels to another Honeycomb cell database. Signed objects may only be destroyed once this security status has been attained.

Signed objects contain a weave of security information in the objects own data according to the security process described below.

Client Agency Transaction Server 605 - This Java based server receives unsolicited authentication messages from the trusted agency authentication server and allows the distribution of these messages for use in the client agency (eg, among a group of bank tellers). The server implements the agency client logic described in the authentication section in a J2EE environment 611 and provides secure encrypted communication to the trusted agency via a private network of the Internet.

Client User application 607- The handset application implements the logic described in the authentication section in a combination of J2ME and C++ (dependant on platform considerations). The device is responsible for informing the transaction server about the status and security of its communications as well as communicating the information needed for the transactions. The device may not store and re-send 'plussecured' data.

Trusted Agency Authentication Server 609 - The trusted agency authentication server implements the logic described in the authentication section in order to: (1 ) Allow the signing of ID documents; (2) Prevent the re-classification of documents without signing; and (3) Respond to authentication requests from other parties. This server is preferably implemented in J2EE with Blowfish and FIPS-127 (AES) standard encryption algorithms.

Referring to Fig. 7 the system 700 provides user identification authentication with banking institution system 703. Authentication body 704 utilises either device 705 and/or clients 711 and network 713 to communicate with repository storage servers 707 to validate and apply public and private keys to images and information stored in database 709. The user (client) 715 utilises handset 717 or client 719 and Internet 721 to communicate with server 707 and transmit required information and identification numbers. The client 715 transmits to server 707, via either handset 717 or web clients 719, files or data to be authenticated by authentication body 704. Server 707 transmits an authentication ID to handset 717 and to banking institution server 703. The client 715 can then show or transmit the authentication ID to the banking institution 722 or banking institution server 703 which can be compared to authentication ID received from repository server 707. The banking institution 722 or banking institution server 703 can then inform the client 715 or transmit to handset 717 a bank transaction ID, if approved.

The invention may also be said to broadly consist in the parts, elements and features referred to or indicated herein, individually or collectively, in any or all combinations of two or more of the parts, elements or features, and wherein specific integers are mentioned herein which have known equivalents in the art to which the invention relates, such as known equivalents are deemed to be incorporated herein as if individually set forth.

Although the preferred embodiment has been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein by one of ordinary skill in the art without departing from the scope of the present invention.

Claims

The claims:

1. A method of storing a copy of data stored on a user's mobile communication device in a database on a remote central server, including the steps of: providing wireless communication means between the mobile communication device and the central server; assigning to the user a secure data storage space on the central server; copying data stored in the mobile communication device to the assigned secure data storage space on a periodic basis or by specific user initiated instruction; and, allowing access to the stored data by a user operating a mobile communication device after the user's access right is verified.

2. The method as claimed in claim 1 , wherein data is only transmitted to the central server when there has been a change in the data.

3. The method as claimed in either claim 1 or 2, wherein a checksum, or other data transmission integrity procedure, attached to data files is utilised.

4. The method as claimed in any one of the claims 1 to 3, wherein the data includes an image of an user's identification document(s).

5. The method as claimed in any one of the claims 1 to 4, wherein the communication between the mobile communication device and the central server utilises an HTTP, HTTPS or SSL connection.

6. The method as claimed in any one of the claims 1 to 5, wherein the user is required to submit a password to access the stored data.

7. The method as claimed in any one of the claims 1 to 6, wherein each user's data is stored in separate directories and is encrypted.

8. The method as claimed in any one of the claims 1 to 7, wherein data updates to the central server are dynamically replicated to one or more additional servers providing data redundancy.

9. The method as claimed in any one of the claims 1 to 8, wherein the user can grant access to the stored data to another person by providing the another person with a private key.

10. The method as claimed in any one of the claims 1 to 9, wherein the stored data can be replicated on a second mobile communication device after user authentication.

11. A system for storing a copy of data stored on a user's mobile communication device, the system including: a central server; a storage unit to house a database; a wireless communication network between the mobile communication device and the central server; an input device associated with the central server to receive the copy of data transmitted by the mobile communication device; at least one processor, the at least one processor being adapted to: assign to the user a secure data storage space in the database on the central server; facilitate copying of data stored in the mobile communication device to the assigned secure data storage space on a periodic basis or by specific user initiated instruction; and, allow access to the stored data by a user operating a mobile communication device after the user's access right is verified.

12. A method of accessing data stored on a central server using a mobile communication device, wherein the data stored on the server is compressed and encrypted, until access is requested from the mobile communication device, whereupon the compressed and encrypted data is decompressed and unencrypted on the basis of a secure key, and transmitted to the mobile communication device.

13. The method as claimed in claim 12, wherein data on the server is stored in a text format or an image format such as PNG format.

14. The method as claimed in either claim 12 or 13, wherein the mobile communication device is a programmable or smart telephone.

15. The method as claimed in any one of the claims 12 to 14, wherein the mobile communication device retains a local cache of at least some of the data which is also stored on the central server.

16. The method as claimed in any one of the claims 12 to 15, wherein the local cache includes an index to the data stored on the server.

17. A method for sharing contact information between a first user and a second user, wherein: the first user groups individual contact details together and associates the individual contact details with a unique identifier; the grouped details are transmitted to a central database; and, the second user is able to access the grouped contact details from a portable telephone by entering the unique identifier when prompted.

18. A method of providing remote access using a mobile communication device via a network to one of a plurality of stored versions of a data file, wherein a Uniform Resource Identifier (URI) and an access list are associated with the data file, said access list including details of one or more parties permitted access to a particular version of said data file, such that at least a first party is granted access to a first version of the data file when the first party utilises the URI to locate the data file, and at least a second party is granted access to a second version of the data file when the second party utilises the URI to locate the data file, and each party is directed to the appropriate stored version of the data file as directed by the access list.

19. The method as claimed in claim 18, wherein the versions of the data file are stored on a party's mobile communication device and are replicated on a central server.

20. The method as claimed in either claim 18 or 19, wherein more than two parties are granted access to versions of the data file.

21. The method as claimed in any one of the claims 18 to 20, wherein the versions of the data file are transferred between parties' mobile communication devices using a peer-to-peer network.

22. The method as claimed in any one of the claims 19 to 21 , wherein the versions of the data file can be accessed on the central server if a mobile communication device is unavailable.

23. The method as claimed in any one of the claims 18 to 22, wherein each party is directed automatically to the appropriate version of data file.

24. The method as claimed in any one of the claims 18 to 23, wherein if a party is removed from the access list the party cannot access any version of the data file.

25. The method as claimed in any one of the claims 18 to 24, wherein the versions of the data file can contain substantially different information.

26. The method as claimed in any one of the claims 18 to 25, wherein the data file is a party's contact details.

27. The method as claimed in claim 26, wherein a first party can provide contact details to a second party by providing a unique identification code to the second party.

28. The method as claimed in claim 27, wherein the first party can assign different groups or parts of contact information to different identification codes.

29. The method as claimed in any one of the claims 19 to 28, wherein the access list and versions of the data file can be amended on the central server via an Internet connection to the server, and communicated to a party's mobile communication device.

30. The method as claimed in any one of the claims 18 to 29, wherein the number of maintained versions of the data file is selectable by a party.

31. The method as claimed in any one of the claims 19 to 30, wherein the second party is required to authenticate itself at the central server before being provided with access to the data file.

32. A system for providing remote access to one of a plurality of stored versions of a data file, the system including: a network connecting one or more mobile communication devices and a central server, the one or more mobile communication devices and the central server able to store the versions of the data file; means to provide a Uniform Resource Identifier (URI) and an access list associated with the data file; the access list including details of one or more parties permitted access to a particular version of said data file, such that at least a first party is granted access to a first version of the data file when the first party utilises the URI to locate the data file, and at least a second party is granted access to a second version of the data file when the second party utilises the URI to locate the data file; whereby, each party is directed to the appropriate stored version of the data file as directed by the access list.

33. A method of identifying a person, including the steps of: the person providing documentary evidence of his or her identity to a trusted source; the trusted source satisfying itself of the person's identity; the trusted source creating a data file which can be used to verify the identity of the person; the trusted source encrypting said data file; a user seeking to verify the identity of the person being provided with a URI associated with the encrypted data file; the trusted source providing a decryption key to the user, allowing the user to decrypt and view the data file and thereby authenticate the person's identity.

34. The method as claimed in claim 33, wherein the trusted source encrypts the data file using a public key of the trusted source, and the trusted source further encrypts the encrypted data file using a private key of the trusted source and a private key of the person.

35. The method as claimed in either claim 33 or 34, wherein the encrypted data file is stored in a secure data storage space allocated to the person on a central server.

36. The method as claimed in any one of the claims 33 to 35, wherein the person can access the encrypted data file using a mobile communication device or a computer via an Internet connection.

37. The method as claimed in any one of the claims 33 to 36, wherein bio- authentication, voice authentication, facial recognition or fingerprint recognition are used by the mobile communication device to assist in authenticating the person.

38. The method as claimed in any one of the claims 33 to 37, wherein the person can remove access to a data file by altering access rights stored on the central server.

39. A method of identifying a person, whereby a first person may authenticate his or her identity with a second person, using a mobile communication device having a SIM, the method including the steps of: the first person providing to the second person, using a communication means associated with the mobile communication device, a copy of the SIM record encrypted with a private key of the first person, an encrypted identity-proving data file and a public key of the first person; the second person decrypting the identity-proving data file using a public key available from a trusted source and the first person's public key to render the data file readable; the second person decrypting the encrypted SIM record using the first person's public key, and comparing the decrypted file with one available from the trusted source; the second person creating a private message including a random key known only to the second person, encrypting said private message using the first person's public key and the second person's private key, and sending said message to said first person; the first person, upon receipt of said private message, decrypting said message using the public key of the second person and the private key of the first person to reveal the random key;

the first person sending to the second person a message including the random key, said message being encrypted using the first person's private key; and, the second person, upon receipt of the message, decrypting said message using the public key of the first person, so as to finalise the authentication of the first person.