WO2004051922A1

WO2004051922A1 - Data packet exchange system and method

Info

Publication number: WO2004051922A1
Application number: PCT/AU2003/001589
Authority: WO
Inventors: Chao Ling Chang; Mario J. Capazario; Jeffrey D. Rubin
Original assignee: Pro-Corp Holdings International Limited
Priority date: 2002-12-02
Filing date: 2003-11-28
Publication date: 2004-06-17
Also published as: AU2003302536A1

Abstract

A system for securely exchanging a data packet, the system having: a first computing device and a second computing device, each having access to a common key, the first computing device being operable to generate a control packet including information identifying the first computing device and to encode the control packet using the common key, the second computing device being configured to use the common key to decode the control packet encoded by the first computing device; wherein the second computing device is configured, when the control packet is decoded by the second computing device, to use the information therein identifying the first computing device to obtain a pass key that is known to the first computing device, the first and second computing devices being configured to encode or decode the data packet using the pass key, thereby allowing the secure exchange of the data packet.

Description

DATA PACKET EXCHANGE SYSTEM AND METHOD

This application is based on and claims the benefit of the filing date of US provisional application serial no. 60/430,052 filed 2 December 2002.

FIELD OF THE INVENTION

The present invention relates to a method and system for exchanging data packets/ of particular but by no means exclusive application in communicating over a computer network such as the Internet. The present invention also relates to a method of validating the transfer of a data set over an communications network.

BACKGROUND OF THE INVENTION

One existing electronic communications protocol, HotSync (TM) , is designed for a single user and a single session, between a single client (typically in the form of a Palm Pilot (TM) ) and a personal computer. The synchronisation process is controlled by the HotSync (TM) resident on the personal computer, but activated by other software components on the Palm Pilot (TM). However, HotSync (TM) is specific to the Palm Pilot (TM) operating system, and the user with his or her Palm Pilot (TM) must be in the immediate vicinity of the personal computer for synchronisation to be performed.

Another existing system, Asta SkySync (TM) , is designed to operate by means of TCP/IP and hence over the Internet. It allows multiple users simultaneous access. However, Asta SkySync (TM) has embedded business logical elements which make it larger, slower and dependent on particular business applications.

TCP/IP is a very reliable communication protocol, but using TCP/IP over a mobile wireless network can introduce problems as a mobile wireless network usually has 1) high bit error rates, 2) variations in bandwidth, and 3) changing topology. Because of this, TCP/IP alone may not be as reliable as desired for data transmission in some applications .

SUMMARY OF THE INVENTION

The present invention provides, therefore, a system for securely exchanging a data packet, the system having: a first computing device and a second computing device, each having access to a common key, said first computing device being operable to generate a control packet including information identifying said first computing device and to encode said control packet using said common key, said second computing device being configured to use said common key to decode said control packet encoded by said first computing device; wherein said second computing device is configured, when said control packet is decoded by said second computing device, to use said information therein identifying said first computing device to obtain a pass key that is known to said first computing device, said first and second computing devices being configured to encode or decode said data packet using said pass key, thereby allowing the secure exchange of said data packet.

Preferably said first and second computing devices are configured to encode and decode said data packet using said pass key.

Preferably said first computing device is one of a plurality of like first computing devices, each of said first computing devices is provided with access to its respective common key, said second computing device is provided with access to all of said common keys, and said second computing device is configured to try one or more of said common keys in order to decode a control packet encoded by any one of said first computing devices . Thus, the first computing device (typically a client) and the second computing device (typically a server) can then communicate securely. The client might be one of a plurality of clients in the form of hand-held computing devices (such as PDAs and the like, and including suitable mobile telephones mobile phones such as those capable of running Java applications) . However, the first and second computing devices need not be computers: these could also be other devices with digital processing capacity that are required to be in communication with each other (such as a mobile telephone, particularly in the role of first computing device) . The second computing device tries as many of the common keys as necessary until the control packet is decoded.

The information identifying the first computing device is important in allowing the system to operate with multiple first computing devices.

Preferably either said first or said second computing device is configured to periodically generate a new common key, and to transmit said new common key to the other of said first or said second computing device. More preferably, said second computing device is configured to periodically generate a new common key, and to transmit said new common key to said first computing device.

Thus, a new common key can be generated to increase security, and transmitted by means of the current common key to the other computing device, so that both devices are in possession of the new common key.

Preferably said data packet includes no field names, whereby said data packet is deciphered by said second computing device. Thus, the client and server could simply send and receive data packets, which are deciphered and processed by, for example, the web server.

The present invention also a method for securely exchanging a data packet, the method involving: providing a first computing device and a second computing device with access to a common key; generating by means of said first computing device a control packet including information identifying said first computing device; encoding said control packet by means of said first computing device using said common key; configuring said second computing device to use said common key to decode said control packet encoded by said first computing device; decoding said control packet by means of said second computing device to obtain said information identifying said first computing device; and obtaining a pass key known to said first computing device by means of said second computing device employing said information identifying said first computing device; wherein said first and second computing devices are configured to encode or decode said data packet using said pass key, thereby allowing the secure exchange of said data packet.

Preferably said first computing device is one of a plurality of like first computing devices, each of said first computing devices is provided with access to its respective common key, said second computing device is provided with access to all of said common keys, and said second computing device is configured to try one or more of said common keys in order to decode a control packet encoded by any one of said first computing devices.

Preferably the method includes either said first or said second computing device periodically generating a new common key, and transmitting said new common key to the other of said first or said second computing device. More preferably, the method includes said second computing device periodically generating a new common key, and transmitting said new common key to said first computing device.

Preferably said data packet includes no field names, and said method includes deciphering said data packet by means of said second computing device.

The present invention still further provides a method of validating the transfer of a data set over an communications network, involving: transferring said data set from a first computing device to a second computing device, said data set comprising one or more data records; transferring in association with said data set a control packet with identification information characterizing said data set according to type, wherein said data set can be any one of a plurality of possible predefined types of data set; providing said second computing device with access to a database containing information indicative of how many data records is correctly contained in each of said types of data set; and validating said transfer of said data set and hence said transferred data set if said number of records in said transferred data set equals the correct number of records for said type of said data set as indicated by said control data. A data set can comprise a table of data. The control data and data set can be transferred or transmitted as, respectfully, a header packet and a plurality of data packets (each data packet corresponding to one of said records) .

A plurality of data sets can be transferred in a single transfer session, and the plurality of data sets can comprise a body of data, wherein the method includes validating the body of data only if each of the data sets is individually validated.

The body of data may constitute the results of a survey or audit, which is only validated if each data set is validated.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the present invention may be more clearly ascertained, a preferred embodiment will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1A is a schematic diagram of a communications system according to a preferred embodiment of the present invention with a user of the client device thereof;

Figure IB is another schematic diagram of the communications system of figure 1A with a user of the client device thereof; Figure 1C is another schematic diagram of the communications system of figure 1A, illustrating the configuration of the component modules of the client device and the system server;

Figure 2 is a schematic diagram of a simplified uploading procedure executed by the communications system of figure 1A;

Figure 3 is a flow chart of the preparation of a header packet by the system of figure 1A;

Figure 4 is a flow chart of the packet authentication process of the system of figure 1A;

Figure 5 is a flow chart of an upload session of the system of figure 1A;

Figure 6 is a flow chart of the preparation of a data packet of the system of figure 1A;

Figure 7 is a flow chart of the check upload count procedure of the system of figure 1A; Figure 8 is a flow chart of the deletion of data when the system server of the system of figure 1A acknowledges the end of an upload session;

Figure 9 is a flow chart of the deletion of data when system server of the system of figure 1A acknowledges the end of uploading of an individual table;

Figure 10 is a flow chart of a download session of the system of figure 1A;

Figure 11 is a flow chart of the life cycle of a pair key for an upload session of the system of figure 1A; Figure 12 is a flow chart of the life cycle of a pair key for a download session of the system of figure 1A; and

Figure 13 is a flow chart of the life cycle of a private key of the system of figure 1A.

DETAILED DESCRIPTION

A communications system according to a preferred embodiment of the present invention is illustrated schematically generally at 10 in figure 1A with a user 12. The user 12 operates a client device in the form of hand held computing device 14 (such as a PDA) , which communicates with a system server 16 by means of the Internet, itself in communication with a web server 18. All analysis software and data packet preparation is conducted according to predetermined business rules on the web server 18. Figure IB is an alternative view of the system 10, in which the Internet 20 is depicted schematically, thereby illustrating how the transmission of data between the hand held computing device 14, the system server 16 and the web server 18 is mediated in each case by the Internet 20 via respective internet connections 22a, 22b, 22c. It should be noted, however, that in an alternative embodiment, hand held computing device 14 could instead be in the form of a mobile telephone handset, in which case some or all of connection 22a (i.e. between the hand held computing device and the internet) would comprise the cellular or other mobile telephone network.

Although only one user 12 and client device 14 are shown in these figures, it will be understood that the system 10 generally includes a plurality client devices essentially identical with client 14, the number being limited only by the capacity of the system server 16 hardware. It is envisaged that the system 10 would be of value in transmitting data from the field to a central location for compilation into a suitable database. For example, stock levels in a plurality of stores and diverse locations can inspected, and the results of the audit or survey transmitted to the central location. Handheld client devices 14 are convenient for such applications, as they allow - when operated in accordance with the present invention - on-site inspections with immediate reporting of audit results. The auditor (or user) of the handheld client device need not return to the central location to upload the results, and multiple users can upload (or download) data effectively simultaneously.

Each client device 14 consists of four main modules: 1) TCP/IP Socket communication module 24; 2) Data Packet Packing module 26: retrieves data from a mobile database 28 in client device 14 and converts each record into a data packet; 3) Data Packet Unpacking module 30: unpacks data packets received from system server 16 and saves each data packet into a record in the mobile database 28; and

4) Packet Security module 32: ensures data integrity by encrypting a control packet in the form of a header packet with a common key (referred to below as the "pair key") and a data packet with a user specific pass key (the "private key") .

The system server 16 is written in Java for reliability and portability, and be deployed in any suitable hardware, such as an Intel-based or Unix-based server. The number of users supported by the system server 16 is limited only by that hardware.

System server 16 consists of five main modules:

1) TCP/IP Socket communication module 34;

2) Data Packet Packing module 36: retrieves data from a back end database 38 (on the web server 18) and converts each record, comprising one row of a database, into a data packet;

3) Data Packet Unpacking module 40: converts each data packet received from the client device 14 into an array of data; this module usually works with the Data Packet Format module 42 to process the array of data into the designated format (Extensible Markup Language (XML) in this example) for further processing;

4) Data Packet Format module 42: a data packet can be further processed into a specific format given the data packet header; common formats are XML, comma separated file, text file and files in Excel (TM) format; and

5) Packet Security module 44: for the encryption and decryption of data packets.

It should be noted that, as mentioned above, the web server 18 has a back end database 38 that is accessed by the system server 16. The Data Packet Packing module 36 of the system server 16 retrieves data from that back end database 38, and system server 16 converts documents into XML and relays them to the web server 18 (as is described in greater detail below) . Alternatively, however, the functions of system server 16 and web server 18 can be combined (either entirely or in part) , such that database 46 of system server 16 constitutes this back end database. In that case, system server 16 would convert documents into XML and store them in its database 46.

Figure 1C is another schematic diagram of the system 10, illustrating the configuration of these modules of the client device 14 and the system server 16.

The system server modules 34,36,40,42,44 perform the following processes.

Data Packet Packing (DPP) :

The data packet packing process places a common delimiter between data and terminates the whole data packet by a packet delimiter.

Data Packet Unpacking (DPU) :

Data packet unpacking process converts an incoming data packet into an array of data for further processing. In the handheld client device 14, the array of data is saved into a mobile database 28 used by the mobile applications resident on the client device 14. In the system server 16 the array of data is mapped to an XML packet to produce an XML document.

Encryption/Decryption process:

A header packet is encrypted with a pair key. The pair key is maintained by system server 16 automatically and is, in normal operation, hidden from all parties. The pair key is sent to client device 14 and stored in the client device 14 after each successful synchronization session.

A data packet is encrypted with the user specific private key, stored on both the system server 16 and the respective client device 14. Thus, each client device 14 retains its own private key, while the system server 16 holds the private key of each of the client devices 14.

Authentication process: The first task in either downloading or uploading is to authenticate the user 12. The client device 14 sends a header data packet to system server 16, and must firstly be decrypted by the system server 16. The header packet, encrypted with the pair key, contains: 1) a Fixed header: informs system server 16 that the data packet is only a header and is for system 10; 2) a User id: for authenticating the user (as each data packet is encrypted with the user's private key); a unique User id and a private key are assigned to each user; in the mobile client devices, the User id and private key are stored in a table not accessible by the user but accessible to the client device 14; the User id and private key can be used to identify the user in the client device 14; 3) a Session id: uniquely identifies a session;

4) an Instruction code: indicates whether the request synchronization is a request for a download (from server 16 to client device 14) or an upload (from client device 14 to server 16) ; other instruction codes can be implemented as needed; and

5) a Table id: records the source or destination of the table of data being transferred; from this information the web server 18 can determine how many fields the table should contain and validate the table only if it does.

The authentication process comprises the first three steps of the system server side Packet Handling Process (described below) .

System Server Side Packet Handling Process: This Process, which manages a session and ensures the integrity of packets received, the system server 16 :

1) Decrypts a received packet with the pair key;

2) If this is a header packet, the server 16 retrieves the user's private key, locates the instruction code within the header packet and decrypts the instruction code by means of that user's private key;

3) Opens a session if user's private key and the instruction code are valid (or, if invalid, the data packet is discarded and the session is closed) ;

4) If a Data packet, decrypts received data packets with user's private key;

5) Stores decrypted data packets into a system database (on web server 18) ; and

6) if further Data Formatting is required, transmit the User id and Session id to the Data Packet Formatting Process.

Data Packet Formatting Process:

This Process converts data packets received during a session into a designated format. The rules for conversion are specified by the user and stored in a set of tables. The rules are user group specific. The format rules can contain rules to present one or a combination of data points, validate data, link data between data packets. The format rules also defines the final outcome of the document.

System 10 is session-less, so multiple users 12 can send and receive data from the system server 16 via their respective clients' devices 14 simultaneously.

All data exchanged between the client device 14 and the system server 16 during data synchronization is in the form of three possible types of data packet, each comprising an array of ASCII characters:

1) a Header Packet, which informs the system server 16 whether to prepare for upload or download for a specified database;

2) a Body or DATA Packet, which contains the actual content for data synchronization; and

3) a Terminator or END packet, which indicates that a synchronization process is complete or otherwise ended; when downloading data from the system server 16 the client device 14, the system server 16 sends a Terminator when there is no more data to download, while when uploading data to the system server 16, each client device 14 sends Terminator when no more data is to be uploaded.

The synchronization process is always initiated by the client device 14; system server 16 always reacts to a request sent by the client device 14 to the system server 16 and comprising a header packet that indicates whether begin either an upload or a download process

Briefly, when a user 12 initiates the downloading of data from the system server 16, the user's client device 14 sends a Header packet to system server 16 to request for a download. The system server 16 reacts to the request and prepares a body or DATA packet to be transferred. When each body packet is received by the client device 14, the client device 14 deciphers that body packet and stores it in a database. Again, each body packet contains the data of a single row of the database, so when the download is complete, the entire database has been transferred.

The download process is terminated when the system server 16 sends a Terminator packet to the client device 14. Upon receipting of the Terminator, the client device 14 closes the Internet connection. When a download Header packet is received by the system server 16, the system server 16 sends a request in XML to the web server 18. The web server 18 opens the necessary- database, converts data into XML and sends it to the system server 16. The system server 16 then translates the XML into body packets, one for each row of data, and sends these packets to the client device 14.

When a user uploads data to the system server 16, the client device 14 sends a Header packet to system server 16 to request an upload. The system server 16 reacts to the request by preparing to receive a body packet from the client device 14. The download process is terminated when the system server 16 receives a Terminator packet from the client device 14. All body packets from client device 14 are aggregated into XML and relayed to the web server 18.

The system server 16 is responsible for packaging the data packets passing through it, but the actual storage and retrieval of data from the central system database is accomplished by the web server 18.

The system server 16 is a ulti-threaded application, so it is capable of handling multiple client devices' requests simultaneously.

The web server 18 contains all the business operations related to received data packets. It has two main operations, to store and to retrieve data from a database. All data retrieved are wrapped into XML and sent to system server 16 for downloading. More business logic can be added to the web server 18. Eventually, a user will be able to drive business logic in the web server 18 using a palm with wireless connection.

Figure 2 is a simplified schematic representation of the typical steps carried out by system 10 in uploading data as described above, from client device 14 to system server 16. The individual steps in this procedure are described in greater detail below, but figure 2 is intended to provide an overview.

Client device 14 first opens a socket and then transmits a header to system server 16. System server 16 authenticates the header (i.e. that it is appropriate for the system and has been received from a legitimate client device 14) , and confirms to the client device 14 that data transfer can commence. The client device 14 transmits a packet containing a row of data (ultimately to be assembled into a table of such rows) ; the system server 16 receives this row packet, verifies the receipt of the row packet and logs this event. Further row packets are transmitted by the client device 14 to the system server 16 until the upload is complete. The row packet or packets constituting the complete table of information are converted into XML, which is sent to the web server 18.

The client device 14 thus deals with tables (containing rows of data, where each row corresponds to a DATA packet) , and only needs to know the structure of the table, not its content. The system server 16, on the other hand, deals with data as a whole to maintain the data integrity. Data integrity is maintained through the validation process described below.

System 10 takes both a detailed and overall approach to ensuring data integrity. For example, if user 12 conducts an audit or survey comprising twenty questions and hence twenty responses, and these responses are to be uploaded to the system server 16, the system server 16 both checks to ensure that each response is received but also that the complete audit or survey is received. An audit with incomplete questions is denied validation and removed from the system and a notification packet is sent to the client device requesting that the audit be re-sent. The client device 14 retains an audit in memory until a request to delete the audit is received from system server 16 (indicating, for example, that the entire audit has been validated, i.e. successfully received) .

The client and server side processes are described in greater detail as follows.

CLIENT SIDE PROCESSES

The client device 14 triggers an upload session by sending a header packet to the system server 16. As discussed above, a header packet contains a Fixed prefix, User id,

Instruction code, and Session id.

In overview, the upload method employed by system 10 includes the following steps: i) The client device 14 and the system server 16 are provided with a "common key" in the form of a pair key; ii) The client device 14 generates the header packet (a for of control packet) including the aforementioned User id, i.e. information that serves to identify the client device 14; iii) The client device 14 encodes the header packet by means of the pair key; iv) The system server 16 is configured to use the pair key to decode the header packet; v) The system server 16, upon receipt of the header packet, decodes the header packet second and obtains the User id; and vi) The system server 16 employs the thus obtained User id to retrieve a "pass key" in the form of a private key known to the client device 14.

The client device 14 and the system server 16, configured to encode or decode subsequent data packets (such as row packets) using the private key, can thereby securely exchange such data packets.

The flowcharts shown in figures 3 and 4 (described below) respectively illustrate steps ii) and iii) and steps iv) and vi) of this method. Steps i) and v) are not included in these flowcharts as they relate to the programming of the client device 14 and system server 16 and precede the illustrated steps.

Figure 3 illustrates the preparation of a header packet. The last process in the preparation of a header packet is to encrypt the packet with the pair key. The pair key is a secret code only accessible by client device 14 and system server 16. A pair key is generated at the end of each session by system server 16 and sent to client device 14. This approach is used instead of public key technology where substantial overhead is required to encrypt packets with the private key and transmit the packets, and where the key must be maintained by an outside authority.

The pair key technique is a lot simpler to implement than, for example, PGP. PGP carries a huge overhead for handheld devices. It is acceptable for ad hoc transmission like email or contact details but for applications such as those envisaged for system 10, which require high level of data traffic, PGP may not be desirable.

Since system 10 is mostly automated, the pair key approach provides the same level of security as public technology but is easier to maintain and use. Because each pair key between a particular client device 14 and system server 16 is unique, the identity of the owner of a header packet is authenticated and subsequent data packets are encrypted by the user's private key, so that it is certain that the packets are truly from the sender. Figure 4 illustrates the process of packet authentication. The system server 16 firstly attempts to decrypt the packet with each pair key in turn until successful. The system server 16 can then read the User id in the header packet, retrieve that user's private key from its own database of user private keys, and - using that private key - decrypts the data. Thus, the client device 14 cannot send data packets unless the system server 16 can locate an effective pair key, and all data packets are encrypted with the respective user's private key.

The use of a pair key ensures that only a particular client device 14 can send data packets of a particular user. Even if another person knows the private key of a user, he or she will not be able to send data packets for another user using another mobile client device.

Figure 5 illustrates an upload session. An upload session may comprise more than one table. Each table has its own header packet, data packets and end packet. Further, a single session can be used both to upload and download tables of data, though thee are illustrated separately and - in practice - it may be desirable to separate uploads and downloads into separate sessions for practical reason .

Referring to figure 5, client device 14 is in control of the session. After each packet is sent, client device 14 pauses for a short period of time for the system server 16 to acknowledge receipt (with an ACK packet) , but then continues to send even if the acknowledgment is not received.

At the end of each table, an END packet is sent by client device 14 to system server 16. The END packet simply contains "END" and is terminated by a carriage return. _After the END packet, if there are more tables to send, the client device 14 prepares the header packet for the next table and sends it to system server 16.

Once the header packet for a table is sent to system server 16, client device 14 begins to progress through each row in the table and package each row as a data packet. Figure 6 illustrates schematically the preparation of such a data packet. Each data packet is finally encrypted with the user's private key.

TABLE 1: C code to encode a string

function encode (string source, string key) as string; variables; string coded; numeric i; numeric keypoint; numeric s; numeric k; numeric v; end; coded = ""; keypoint = 0; for i = 0, i < length(source) ; s = asc (mid (source, i, 1) ) ; k - asc (mid(key,keypoint, 1) ) ; keypoint = keypoint + 1; if keypoint = length(key) ; keypoint = 0 ; end_if; v - s+k; coded = coded + char (v) ; next i; encode = coded; end; The C code to encode a string is presented in Table 1, the code to decode a string in Table 2. It will be understood, however, that alternative algorithms can be used to achieve the same object.

Referring to figure 7, the client device 14 keeps track of the number of data packets uploaded to system server 16. If the count is zero, the upload process is terminated as there could be a problem in Internet connection.

TABLE 2: C code to decode a string

# Decode - returns original string from coded (source)

# and key strings function decode (string source, string key) as string; variables; string coded; numeric i; numeric keypoint; numeric s; numeric k; numeric v; end; coded = ""; keypoint = 0 ; for i = 0, i < length(source) ; s = asc (mid(source, i, 1) ) ; k = asc (mid(key,keypoint, 1) ) ; keypoint = keypoint + 1; if keypoint = length(key); keypoint = 0; end_if; v = s-k; coded = coded + char(v) ; next i; decode = coded; end; The transportation protocol used to send packets is TCP as it is currently the most reliable protocol for the Internet communication. By using TCP the delivery of a packet is ensured.

A data packet is sent to a fixed TCP port (port 8883) of system server 16, though system 10 can use any port for sending and receiving packets.

Referring to figure 8, data in mobile client devices is only deleted when system server 16 acknowledges a session is complete. System server 16 only acknowledges a session is complete if: 1) the user is authenticated; 2) all packets received are correctly decrypted; and

3) data in packets is valid after checking business rules.

Client device 14 deletes all packets sent to system server 16 after an end of session acknowledgement is received, though it may also be desirable in some embodiments to delete packets in a table after each table is uploaded (rather than waiting until all the tables are uploaded) , as illustrated in figure 9.

Referring to figure 10, to trigger a download session client device 14 sends a header packet with an instruction code for download. The header packet is encrypted with the pair key. Once the header packet is authenticated a download session is established. In each download session client device 14 can request data from more than one table.

Once a download session is open, client device 14 requests data packets from the system server 16 by sending a Request packet. The Request packet consists of a table code and User id and is terminated with a carriage return. The Request packet is encrypted with the user's private key. A table download is complete when client device 14 receives an END packet from system server 16.

After client device 14 sends the Request packet to system server 16, the system 10 uses the table code in the Request packet arid the User id to retrieve any data packets to send to client device 14. The data packet is encrypted with the user's private key. Thus, only the intended user can decrypt the packets. The data packet contains delimited fields that are converted into an array of data and saved into the table.

The content of a table is removed after the system server 16 authenticates the header packet but before any new data packet is received.

SERVER SIDE PROCESSES

A header packet is always encrypted with the user's pair key. A pair key is unique between the mobile client device 14 and the system server 16. The packet authentication process is described above by reference to figure 4. A header packet can be decrypted by the pair key used, so the mobile client device 14 that was used to send the packets is known. From the User id in the header packet, system server 16 retrieves the correct private key which is then used to decrypt data packets.

The pair key is generated by the system server 16 and maintained in the system server 16. Each mobile client device 14 has its own pair key, which is needed to access the system server 16.

The pair key life cycle is slightly different between an upload and download session. Figure 11 is a flow chart of the pair key life cycle for an upload session. The pair key is generated when an END packet is received in an upload session. Figure 12 shows the pair key life cycle for a download session. In a download session, the pair key is generated after the END packet is sent to client device 14.

Figures 11 and 12 explain how the pair key is updated, but not how the pair key (and indeed the private key) is supplied to the client device 14 and system server 16 initially. The client device 14 is initalised before being deployed in the field. A User id and private key, and the first pair key, are downloaded to the client device 14 during this initialisation process by direct connection to a personal computer.

Both system server 16 and client device 14 always overwrite the previous pair key. The pair key record, stored in system server 16 for each client device 14 comprises: User id; Pair key; . Date and time the key is generated; and mobile client device 14 inventory tag number.

The use of the pair key ensures that packets sent from a mobile client device 14 are truly from that device. "The use of a private key, on the other hand, ensures that data is secured even if the mobile client device 14 is lost or stolen.

The user's private key can only be changed from the mobile client device 14. Changing a user's private key is effected in a process similar to an upload session.

Referring to figure 13, a header packet with "change private key" instruction code is sent to system server 16.

The header packet is encrypted with the pair key. The new private key is encrypted with the user's old private key.

Once the new private key is updated in the system server

16, a new pair key is sent to the client device 14 and stored. The private key in the mobile client device 14 is also updated to the new one. Figure 13 illustrates the life cycle of a private key.

The header packet is always the first packet before a session can be established. The header packet is always encrypted with the unique pair key. A header packet is valid only if the following two conditions are met:

1) the Fixed prefix is valid - the Fixed prefix is a fixed string (for example, the name of the operator of the system, such as PROCORP) for a particular implementation of the system; and

2) the User id is valid - the user id is valid when a private key can be found for the User id in the Header packet.

Once a private key is identified any subsequent data packets are decrypted with the private key. A data packet is valid if: 1) the Session id matches with Session id in the Header packet; and 2) the table code prefixed to the packet is valid.

To allow for the limitations of TCP when used over a mobile network, system server 16 employs business rules to validate data as a whole and thereby ensure data integrity. In addition to the use of pair keys, system server 16 has a business logic engine for defining rules and tables of values, allowing the user to define what constitutes a valid data set.

The use of tables allows one to change the logic of a program without changing the program itself . The auditing process is all driven by rules defined in tables. This means flexibility in adapting the system to any environments in shortest time. For example, the user could define that, for a complete audit, there must be one question header, 20 questions and optional product information. Thus, Complete Audit = 1 question header

+ 20 questions

+ zero to many product information.

The question header, question content and production information are preferably stored in three different tables, with Table ids such as QUESTIONJHEADER, QUESTION_CONTENT, and PRODUCT_INFO. Thus, for an audit or survey in location A to be valid, there must have one data packet in the QUESTION_HEADER table and exactly 20 data packets in QUESTION_CONTENT for location A.

Each constitutes a rule for its corresponding table, as summarized in Table 3 :

TABLE 3: RULES FOR EACH TABLE

The triggers of business rules are also defined in tables. In Table 4, the first entry tells the system server 16 to active the VALIDATE_RULE rule when a new packet is inserted into the QUESTION_HEADER table. The second entry tells system server 16 to run VALIDATE_PRICE rule when the INVENTORY table is updated.

TABLE 4: TRIGGERS OF BUSINESS RULES

Modifications within the scope of the invention may be readily effected by those skilled in the art. It is to be understood, therefore, that this invention is not limited to the particular embodiments described by way of example hereinabove.

Further, any reference herein to prior art is not intended to imply that such prior art forms or formed a part of the common general knowledge.

Claims

CLAIMS :

1. A system for securely exchanging a data packet, the system having: a first computing device and a second computing device, each having access to a common key, said first computing device being operable to generate a control packet including information identifying said first computing device and to encode said control packet using said common key, said second computing device being configured to use said common key to decode said control packet encoded by said first computing device; wherein said second computing device is configured, when said control packet is decoded by said second computing device, to use said information therein identifying said first computing device to obtain a pass key that is known to said first computing device, said first and second computing devices being configured to encode or decode said data packet using said pass key, thereby allowing the secure exchange of said data packet.

2. A system as claimed in claim 1, wherein said first and second computing devices are configured to encode and decode said data packet using said pass key.

3. A system as claimed in either claim 1 or 2, wherein said first computing device is one of a plurality of like first computing devices, each of said first computing devices is provided with access to its respective common key, said second computing device is provided with access to all of said common keys, and said second computing device is configured to try one or more of said common keys in order to decode a control packet encoded by any one of said first computing devices.

. A system as claimed in claim 3 , wherein each of said plurality of first computing devices comprises a client in the form of a hand-held computing device, and said second computing device comprises a server, whereby said first computing devices and said second computing device can communicate securely.

5. A system as claimed in any one of the preceding claims, wherein either said first or said second computing device is configured to periodically generate a new common key, and to transmit said new common key to the other of said first or said second computing device.

6. A system as claimed in claim 5, wherein said second computing device is configured to periodically generate a new common key, and to transmit said new common key to said first computing device.

7. A system as claimed in any one of the preceding claims, wherein said data packet includes no field names, whereby said data packet is deciphered by said second computing device.

8. A system as claimed in any one of the preceding claims, wherein said first computing device comprises a personal digital assistant or a mobile telephone.

9. A method for securely exchanging a data packet, the method involving: providing a first computing device and a second computing device with access to a common key; generating by means of said first computing device a control packet including information identifying said first computing device; encoding said control packet by means of said first computing device using said common key; configuring said second computing device to use said common key to decode said control packet encoded by said first computing device; decoding said control packet by means of said second computing device to obtain said information identifying said first computing device; and obtaining a pass key known to said first computing device by means of said second computing device employing said information identifying said first computing device; wherein said first and second computing devices are configured to encode or decode said data packet using said pass key, thereby allowing the secure exchange of said data packet .

10. A method as claimed in claim 9, wherein said first and second computing devices are configured to encode and decode said data packet using said pass key.

11. A method as claimed in either claim 9 or 10, wherein said first computing device is one of a plurality of like first computing devices, and the method further comprises: providing each of said first computing devices with access to its respective common key; providing said second computing device with access to all of said common keys; and configuring said second computing device to try one or more of said common keys in order to decode a control packet encoded by any one of said first computing devices .

12. A method as claimed in any one of claims 9 to 11, wherein either said first or said second computing device periodically generating a new common key, and transmitting said new common key to the other of said first or said second computing device.

13. A method as claimed in claim 12, further comprising said second computing device periodically generating a new common key, and transmitting said new common key to said first computing device.

14. A method as claimed in any one of claims 9 to 13, wherein said data packet includes no field names, and said method further comprises deciphering said data packet by means of said second computing device.

15. A method of validating the transfer of a data set over an communications network, involving: transferring said data set from a first computing device to a second computing device, said data set comprising one or more data records; transferring in association with said data set a control packet with identification information characterizing said data set according to type, wherein said data set can be any one of a plurality of possible predefined types of data set; providing said second computing device with access to a database containing information indicative of how many data records is correctly contained in each of said types of data set; and validating said transfer of said data set and hence said transferred data set if said number of records in said transferred data set equals the correct number of records for said type of said data set as indicated by said control data.

16. A method as claimed in claim 15, wherein said data set comprises a table of data.

17. A method as claimed in either claim 15 or 16, further comprising transferring or transmitting said control data and said data set as, respectfully, a header packet and a plurality of data packets, wherein each data packet corresponds to one of said records.

18. A method as claimed in any one of claims 15 to 17, wherein said data set is one of a plurality of such data sets, and said method further comprises transferring said plurality of data sets in a single transfer session.

19. A method as claimed in claim 18, wherein said plurality of data sets comprises a body of data, and the method further comprises validating said body of data only if each of the data sets is individually validated.

20. A method as claimed in claim 18, wherein said body of data comprises the results of a survey or audit, whereby said survey or audit is only validated if each of said plurality of data sets is validated.

21. A computer program product directly loadable into teϊie internal memory of a first computing device and a second computing device, comprising software code portions for performing the steps of the method of any one of claims 9 to 20 when said product is run on said first computing device and said second computing device.

22. A computer program product stored on a computer readable medium for causing a first computing device and a second computing device to perform the steps of the method of any one of claims 9 to 20.

23. A computer readable medium, having a program recorded thereon, where the program is to make a first computing device and a second computing device execute a method defined in any one of claims 9 to 20.