AU2006228083A1 - Development Environment - Google Patents

Description

13-OCT-2006 17:24 A J PARK 64 9 3566990 P.04 Regulation 3.2

AUSTRALIA

PATENTS ACT, 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT

ORIGINAL

Name of Applicant Actual Inventors: Address for servicc in Australia: Invention Title: MADGE NZ IIMITED ANDREW PAUL WATERS, GRANT CHRISTOPHER

HARWOOD

A J PARK, Level 11, 60 Marcus Clarke Street, Canberra ACT 2601, Australia Development Environment The following statement is a full description of this invention, including the best method of performing it known to us.

COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-2006 17:244 A J PRRK 64 9 3566990 -2-

NO

0 FIELD OF THE INVENTION The present invention relates to a system, software and/or method for enabling O user configuration to integrate mobile devices with a enterprise computer system BACKGROUND TO THE INVENTION Various mobile computing devices are available on the market that are 00 connectable to telecommunications networks via various wireless protocols. Such devices 00 include personal digital assistants (PDAs), mobile telephones with organiser functionality and the like. Many organisations have their contractors and employees in the field use such N 10 devices in order to provide them with information relating to jobs that must be carried out 0 and/or products that must be supplied to customers. The devices also enable the contractors/employees to record information relating particular jobs carried out, or products supplied.

To further improve on the flexibility and utility of such devices, it is desirable for the devices to be in communication with an enterprise computer system run by the enterprise, and generally located at the enterprise's offices. The computer system might include, for example, a database containing client, job and other useful information along with terminals and appropriate software for accessing the database. The software may also provide scheduling functionality so that an operator in the enterprise offices can schedule particular jobs and organise workload between various employees/contractors accordingly.

The information between the mobile devices and the computer system at the enterprise can be synchronised, which enables the users of the mobile devices to receive up-to-date scheduling and job information, while the database can be periodically updated with the information entered into mobile devices by individual employees/contractors. Typically mobile devices are devices such as mobile phones, PDAs, handheld computers and the like that have transceiving functionality either over a mobile telephone network or some other suitable network.

As an example, the enterprise might provide trade services, such as plumbing. The enterprise computer system might include information on customers along with schedules of plumbing jobs that certain customers have requested be done. Information on the customers and jobs to be done can be deployed to the individual mobile device for each contractor/employee, so that the respective contractor/employee can view what jobs need carrying out, and can review the necessary customer information to carry out the job.

Other information pertaining to the job can be provided via the mobile device, and also COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-DCT-200E6 1?:24 A J PARK 64 9 3566990 P.06 -3-

\O

0 0 entered into the device by the contractor/employee. A specially designed graphical user Sinterface (GUI) enables the user of the mobile device to view the information, and enter O information, usually by way of a menu system. Periodically, as new information is entered Sinto the device by the user on particular customers, this information is transferred back to the computer system, and the associated fields in the computer system are updated with the new information. Likewise, as new information is entered in data fields in the computer 00 system, this information transferred to the mobile device, and the associated fields in the C0 mobile device are updated with the new information. This data synchronisation takes place over a suitable communications channel using suitable protocols. Mobile devices can be N 10 used in a similar manner where the enterprise for whom the contractor/employees work o provides products.

The difficulty, however, with such systems is there is no currently available system or other tool for enabling an enterprise to re-design and re-deploy different scheduling functionality that can be executed on the mobile devices and enable synchronisation to take place between the mobile devices and the enterprise computer system database. Often, the requirements for the scheduling, information transferral to the mobile devices and information entered into the mobile devices needs to change as the type of work or needs of the customers and/or enterprise changes. Any such changes require amendments to the mobile device GUI and functionality and the communication protocols between the mobile device and the enterprise database to allow data transfer between the two in relation to the new functionality.

At present, each mobile device vendor has proprietary development and communications protocols, and the enterprises themselves employ a wide range of operating systems, software and database structures. To alter the mobile device functionality and GUI and to allow data synchronisation for this altered functionality requites highly skilled labour to redevelop the system each time an amendment is required.

This involves updating or amending the mobile device client software and also the enterprise computer system to enable transfer to take place for the new types of information transfer and functionality that are required. Therefore, there is a large overhead required and associated expense when a change is desired.

Therefore, it would be desirable to have a system, software and/or method in which a system operator could relatively easily develop new information retrieval, display and/or capture functionality for mobile devices along with a new GUI, all of which could COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-206 17:24 Af J PAFRK 64 9 3566990 P.07 -4- 0 o be configured to integrate with the enterprise computer system to enable transfer of Sinformation over a communications channel to effect data synchronisation.

0 SSUMMARY OF THE INVENTION It is an object of the invention to provide a system, computer program and/or method to assist in enabling a user to configure one or more mobile devices and/or Ce 00 associated computer systems to enable data transfer between the two.

O0 In one aspect the present invention may be said to consist in a method of C configuring one or more mobile devices to provide one or more user interfaces to at least IO 10 one database on a remote computer system, the method comprising the steps of: defining o an index of one or more shadow fields, each shadow field being associated with one or more of data fields in the at least one database, and receiving input defining a user interface to the at least one database for deployment on a mobile device, and generating configuration data specifying the user interface, the configuration data comprising data specifying one or more of the shadow data fields associated with the user interface, wherein the configuration data is adapted to configure a mobile device as a user interface to the at least one database by: configuring the mobile device to display, store and/or receive data entries in relation to the shadow data fields specified by the configuration data, and configuring the mobile device for data synchronisation of data entries in relation to the specified shadow data fields with data entries in the one or more associated data fields in the database.

Preferably the configuration data is adapted to be received and utilised by a mobile device to configure itself to provide the user interface.

Preferably the method further comprises the step of transferring the configuration data to one or more mobile devices during a communication session.

Preferably the configuration is transferred over a non-persistent communications channel.

Preferably the configuration data is transferred periodically during a communication session Preferably the step of receiving input defining a user interface to the at least one database comprises recciving input specifying one or more display items for display on the mobile device.

Preferably the configuration data further comprises data specifying one or more of display items.

COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-DCT-206 17:25 A J PARK 64 9 3566990 P.08 0 0 c\O Preferably the display items comprise one or mote of menu options, icons, O requests for information, data input fields.

SPreferably the configuration data is adapted to be received and utilised by a mobile device to configure itself to receive data in relation to one or more of the display items and store received data in one or more shadow fields associated with a respective display item 0 for which data is received.

0 0 Preferably the step of receiving input defining the user interface to the at least one 0 database comprises receiving input defining tasks and/or questions for display and/or <0 10 storage on a mobile device, wherein the tasks and/or questions are associated with one or o more of the shadow data fields.

Preferably the configuration data further comprises data specifying one or more of the tasks and/or questions for display and/or storage on the mobile device.

Preferably prior to the step of transferring the configuration data to one or more mobile devices during a communication session, the method comprises the step of storing the configuration data in an intermediary store.

Preferably the step of transferring the configuration data to one or more mobile devices during a communication session comprises transferring the configuration data from the intermediary store to a data store in each respective mobile device.

Preferably the method further comprises the step of receiving data from one or mobile devices and storing it in the intermediary store.

Preferably the method further comprises step of updating the at least one database with data in the intermediary store received from one or more mobile devices.

Preferably the method further comprises the step of synchronising data in the data fields of the at least one database with data stored in relation to the shadow data fields specified by the configuration data..

Preferably the method further comprises transferring the configuration data to a plurality of mobile devices.

Preferably the step of receiving input defining a user interface to the at least one database for deployment on a mobile device comprises: receiving user input specifying the mobile device type of a desired vendor, emulating a graphical user interface of the mobile device, and receiving input selecting display items with one or more associated shadow data fields.

COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-CT-20306 17:25 A J PARK 64 9 3566990 P.09 -6-

O

0 0 Preferably the method further comprises the steps of receiving the configuration Sdata at a mobile device and configuring the mobile device as a user interface to the at least O one database using the configuration data.

C Preferably the method further comprises the step of receiving further configuration data at the mobile device and re-configuring the mobile device as a re-configured user interface to the at least one database using the configuration data.

00 Preferably the method further comprises the step of synchronising data in the 00 specified shadow data fields with data in the data fields of the at least one database.

C In another aspect the present invention may be said to consist in a system adapted NO 10 to facilitate configuration of one or more mobile devices to provide one or more user o interfaces to at least one database on a remote computer system, the system comprising: a computer system comprising, or adapted to communicate with, at least one database that comprises a data structure with one or more data fields, each data field for storing one or more data entries,, the computer system comprising at least one computer programmed to: define an index of one or more shadow fields, each shadow field being associated with one or mote of data fields in the at least one database, and receive input defining a user interface to the at least one database for deployment or a mobile device, and generate configuration data specifying the user interface, the configuration data comprising data specifying one or more of the shadow data fields associated with the user interface,wherein the configuration data is adapted to configure a mobile device as a user interface to the at least one database by: configuring the mobile device to display, store and/or receive data entries in relation to the shadow data fields specified by the configuration data, and configuring the mobile device for data synchronisation of data entries in the specified shadow data fields with data entries in the one or more associated data fields in the database.

Preferably the configuration data is adapted to be received and utilised by a mobile device to configure itself to provide a user interface.

Preferably the system further comprises a definition file coupled to or integrated with the computer for storing the configuration data.

Preferably the system comprises a first transmitter and the computer is further programmed to transfer the configuration data to one or more mobile devices during a communication session via the first transmitter.

Preferably the configuration data is transferred over a non-persistent communications channel.

COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-2006 17:25 A J PARK 64 9 3566990 -7-

O

0 0 Preferably the configuration data is transferred periodically during a O communication session.

SPreferably receiving input defining a user interface to the at least one database comprises receiving input defining one or more display itcts for display on the mobile device.

Ce 00 Preferably the configuration data further comprises data specifying one or more of 00 display items.

0 Preferably the display items comprise one or more of: menu options, icons, IN 10 requests for information, data input fields.

O Preferably the configuration data is adapted to be received and utilised by a mobile device to configure itself to receive data in relation to one or more of the display items and store received data in one or more shadow fields associated with a respective display item for which data is received.

Preferably receiving input defining a user interface to the at least one database comprises receiving input defining tasks and/or questions for display and/or storage on the mobile device, and the tasks and/or questions are associated with one or more of the shadow data fields.

Preferably the configuration data further comprises data specifying one or more of the tasks and/or questions for display and/or storage on the mobile device.

Preferably the system further comprises an intermediary store coupled to or integrated with the computer wherein prior to transferring the configuration data to one or more mobile devices during a communication session, the computer is programmed to store the configuration data in the intermediary store.

Preferably transferring the configuration data to one or more mobile devices during a communication session comprises transferring the configuration data from the intermediary store to a data store in each respective mobile device using the first transmitter.

Preferably the system comprises a first receiver, wherein the system is adapted to receive data from one or mobile devices via the first receiver and store it in the intermediary store, the data comprising data in the specified shadow data fields.

Preferably the system is adapted to update the data fields of the at least one database that arc associated with the specified shadow data fields, the data fields being updated with data from the intermediary store received from one or more mobile devices.

COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-2006 17:26 A J PARK 64 9 3566990 P.11 -8- 0 SPreferably receiving input defining a user interface to the at least one database for deployment to a mobile device comprises:receiving user input specifying the mobile device 0 type of a desired vendor, emulating a graphical user interface of the mobile device, and Sreceiving input selecting display items with one or more associated shadow data fields.

Preferably the system further comprises at least one mobile device, the device comprising a second receiver adapted to receive configuration data transmitted via the first transmitter, wherein the mobile device is adapted to configure itself as a user interface to 0 Sthe at least one database using the received configuration data.

00 ^C Preferably the mobile device is adapted to receive further configuration data IO 10 transmitted via the first transmitter and re-configure itself as a re-configured user interface Sto the at least one database using the additional configuration data.

Preferably the mobile device further comprises a second transmitter, wherein the device is adapted to transmit data to the intermediary store via the first receiver, the data being form updating the data fields of the at least one database that are associated with the specified shadow data fields.

Preferably the mobile device is adapted to periodically communicate with the intermediary store to receive configuration data, and periodically re-configure itself as a user interface to the at least one database using the configuration data- In another aspect the present invention may be said to consist in a mobile device comprising a transceiver and configuration software, the mobile device adapted to receive the configuration data, and adapted to configure itself with the configuration software using the configuration data to provide a user interface to the at least one database.

In another aspect the present invention may be said to consist in a method for facilitating configuration of a mobile device and integration of the mobile device with a remote computer system including at least one database, to provide for data synchronisation between the mobile device and the remote computer system, the method including: configuring a mobile device functionality and/or user interface, including selecting menu elements for display, methods for the elements and one or more shadow data fields related to the elements and associated with data fields in the database, using software that configures a system to facilitate data synchronisation between the mobile device and database.

In another aspect the present invention may be said to consist in a computer program for operating a computer connected to at least one database to facilitate COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-200 17:26 A J PARK 64 9 3566990 P.12 -9- 0 0 configuration of a mobile device to provide a mobile interface to the at least one database on a renmote computer system, the computer program comprising: a index module adapted o to enable the definition of an index of one or more shadow data fields for use in en configuring the mobile device, each shadow data field being associated with one or more data fields in the at least one database, each data field in the at least one database containing one or more data entries, and a user configuration module adapted to enable cn 00 configuration of the functionality of the mobile device, the user configuration module 00 enabling a user to select one or more of the shadow data fields, wherein the user F1 configuration module generates configuration data for configuration of a mobile device to

I

N 10 display, store and/or receive data entries in relation to the selected shadow fields and for 0 data synchronisation of data entries in the selected shadow fields displayed, stored or received on the mobile device, and data entries in the one or more associated data fields in the database.

Preferably the configuration data is adapted to be received by the mobile device during a communication session, and adapted to be utilised by the mobile device to configure itself as defined by the configuration data.

Preferably the configuration data further defines tasks and/or questions for display and/or storage on the mobile device, and wherein the configuration data is adapted to be received and utilised by a mobile device to configure itself to receive, display and/or store tasks and/or questions defined by the configuration data receive data entries in respect of those tasks and/or questions.

Preferably the tasks and/or questions are associated with one or more of the shadow data fields.

Preferably the configuration data is adapted to be stored in a configuration data store that is in communication with a data store in the mobile device.

Preferably the user configuration module is further adapted to receive user input specifying display items for association with one or more of the selected shadow data fields, the user configuration module adapted to generate configuration data defining the display items and the respective associations of those display items with one or more of the selected shadow data fields, the configuration data being adapted to be received and utilised by a mobile device to configure itself to display the specified display items.

Preferably the display comprise one ot more of menu options, icons, requests for information, data input fields.

COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-DCT-2006 17:26 A J PARK 64 9 3566990 P.13

O

o Preferably the configuration data is adapted to be received and utilised by a mobile Sdevice to configure itself to receive data in relation to one or more of the display items and 0 store received data in one or more shadow fields associated with a respective display item for which data is received.

Preferably the computer program facilitates configuration of a plurality of mobile devices.

0 Preferably the computer program facilitates configuration of a plurality of different 0 mobile device types supplied by different vendors.

Preferably the use configuration module is adapted to:receive user input specifying NO 10 the mobile device type of the desired vendor, emulate a graphical user interface of the o mobile device, and display user specified display items and/or the data entries for the selected shadow fields associated with those specified display items.

Preferably the user configuration module simulates data synchronisation between data entries display, stored and/or received in respect of the selected shadow fields and data entries in the associated data fields in the database.

Preferably the configuration data is adapted to be stored in an intermediary store prior to data transfer to a mobile device.

Preferably the computer program further comprises a run-time scheduling module for editing display items, requests, tasks and information, the run-time scheduling module adapted to receive user input specifying changes to display items, requests, task and information and generates update configuration data defining the changes, the update configuration data being adapted to received and utilised by a mobile device to configure itself as defined by the configuration data.

In this specification where reference has been made to patent specifications, other external documents, or other sources of information, this is generally for the purpose of providing a context for discussing the features of the invention. Unless specifically stated otherwise, reference to such external documents is not to be construed as an admission that such documents, or such sources of information, in any jurisdiction, are prior art, or form part of the common general knowledge in the art The term "comprising" as used in this specification means "consisting at least in part of'. Related terms such as "comprise" and "comprised" are to be interpreted in the same manner.

To those skilled in the art to which the invention relates, many changes in construction and widely differing embodiments and applications of the invention will COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-DCT-200 17:27 A J PARK 64 9 3566990 P.14 -11-

O

Ssuggest themselves without departing from the scope of the invention as defined in the Sappended claims. The disclosures and the descriptions herein are purely illustrative and are not intended to be in any sense limiting BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the invention will be described with reference to the 00 following drawings, ofwhich: 0 0 Figure 1 is a schematic diagram showing an overview of a system according to a CN preferred embodiment of invention, including a configuration interface, .0 10 Figure 2 is a schematic diagram showing components of a preferred embodiment 0 of the software that is implemented in a preferred embodiment of the system, Figure 3 is a block diagram showing a preferred embodiment of the system, Figure 4 shows a graphical user interface of the Mapped Data Field Index Generation module, including an example of typical selections, Figure 5 shows an example of a typical data structure in an enterprise database and the mapping of fields in that database into the Mapped Data Field Index, Figure 6 shows a graphical user interface of the User Configuration Module for configuring the mobile device and data transfer process, Figure 7 shows a graphical user interface of the Run-time Scheduling Module, Figure 8 shows a configured menu as it is displayed on the mobile device, Figure 9 shows a configured task list screen including scheduled tasks as it is displayed on the mobile device, Figure 10 shows a configured question sub-menu as it is displayed on the device, Figure 11 shows an information screen for display of general information on a mobile device, Figure 12 shows a typical data structures for the various configuration data files used in the system, and Figure 13 shows a flow diagram of a method according a preferred embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Overview of System and Software Figure 1 shows in schematic form an overview of a system 1 in accordance with a prcferred embodiment of the invention. The system 1 includes an enterprise computer COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-200 17:27 A J PARK 64 9 3566990 -12-

VO

0 0 system 2, including one or more databases, integrated with a number of mobile devices 4 deployed in the field for assisting each contractor or employee of the enterprise with task 0 scheduling, and in particular the planning, actioning and documenting of services carried Sout for clients on behalf of the enterprise and/or products supplied in accordance with the enterprise's business model. The system 1 facilitates task scheduling, and uses the mobile devices 4 to convey the scheduling information to the contractors/employees and capture o0 scheduling information from the employees/contractors. It will be appreciated that the O0 term task scheduling relates to more than just the tasks themselves, but also refers to the information associated with the scheduled tasks, both provided to and received by the IN 10 contractors/employees carrying out the tasks and the functionality deployed to the mobile O device to implement scheduling. The mobile devices 4 facilitate this function by providing a range of hierarchical menus in a graphical user interface (GUI), each with displayed menu elements that might relate to a request to input information, information associated with a data field in the enterprise computer system, or a link to a sub-menu. The data on the mobile device can be synchronised with data in the enterprise computer system such that the scheduling information on both is replicated. It will be appreciated that in this specification, any description relating to a mobile device can be extended to a range of such devices all of different types. Typically mobile devices are devices such as mobile phones, PDAs, handheld computers and the like that have transceiving functionality either over a mobile telephone network or some other suitable network.

For example, the enterprise might provide trade services, such as plumbing. The enterprise computet system 2 might include information on customers along with schedules of plumbing jobs that certain customers have requested be done. Information on the customers and jobs to be done can be deployed to the individual mobile device for each contractor/employee, so that the respective contractor/employee can view which jobs need carrying out, and can review the necessary customer information to cattrry out the job.

Other information pertaining to the job can be provided via the respective mobile device 4, and also entered into the device by the contractor/employee. Information on each mobile device 4 and in the enterprise computer system 2 can be periodically synchronised through an update procedure.

In a preferred embodiment of the invention, a configuration interface 3 is provided which forms an intermediary component of the overall system 1. 'The configuration interface 3 includes software running on a computer system that is in communication with the business computer system 2 and the mobile devices 4 operated by users in the field COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-206 17:27 A J PARK 64 9 3566990 P.16 -13-

NO

0 0 carrying out work under instruction of the enterprise. The configuration interface 3 facilitates the configuration of the mobile devices 4 to provide the required functionality O and GUI to assist users in carrying out the work, enable access to required information S from the enterprise computer system 2 to carry out the work, facilitates the deployment of the configuration to the mobile devices 4, and facilitates the configuration of the overall system 1 to enable data transfer between the mobile devices 4 and the enterprise computer Ce 00 system 2 to enable data synchronisation. In effect, once configured, each mobile device is 0 provides a user interface to the one or more databases in the enterprise computer system 2.

^C Here, the term "user interfacee" refers to more than just a graphical user interface, but all VaO 10 the associated functionality to allow a user at least partial access to information in the Sdatabases, and also exchange information therewith. The system allows for dynamic updating of the mobile devices in accordance with the configurations made by a user through the configuration interface. It also allows for data exchange or synchronisation of data in relation to the configurations made. The mobile device configuration can be continually or periodically updated, in accordance with configuration data changes as part of the data synchronisation process.

More particularly, in overview, the configuration interface communicates with the enterprise computer system 2 and allows a system operator to interrogate the various databases it implements, and view the various data fields used in the data structures of those databases. The system operator can then utilise the configuration interface 3 to select various data fields and produce an index of shadow data fields each mapped to one or more data fields in the database. The shadow data fields chosen will contain data entries useful in carrying out task scheduling. For example, they may be data fields relating to customer names, addresses, order numbers and customer history. The software of the configuration interface 3 then enables the user to configure the system to enable access to these fields via the users mobile device and allow data synchronisation between the two.

This facilitates the data scheduling process of the system 1.

There are several aspects to the configuration. The first is a configuration of a GUI and functionality of the mobile devices, to display menu options, information, information requests and other display items to enable task scheduling information to be conveyed to a user of the mobile device, and capture information from them. This configuration can be different for each different type of mobile device in the system. To doing so, the software configures the system to allow deployment of those configuration settings to the each mobile device, and also configures the system to allow data synchronisation with each COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-DCT-206 17:28 A J PARK 64 9 3566990 P.17 -14-

NO

0 0 newly configured mobile device. Therefore, the system 1 not only allows for configuration 9 of new functionality for each mobile device, but also carres out the underlying 0 configurations required to ensure the newly configured mobile devices are integrated into en the system 1 overall, so that data transfer can take place. In a preferred embodiment, the configuration interface 3 is implemented as software that communicates with the enterprise computer system 2 and the various mobile devices 4. The configuration interface 3 could Cn 00 for example sit on a computer that is connected via a LAN or other computer network to 00 ECS 2. The configuration interface 3 and ECS 2 could form part of the same overall system and be located centrally or remotely. Figure 1 shows the logical arrangement of NO 10 these components, but not necessarily the physical implementation. Many possible 0 physical implementations could be envisaged by those skilled in the art. The system 1 also comprises a transceiver (or a separate transmitter and receiver) to allow for data transfer between the mobile devices and the ECS 2 and configuration interface 3.

It will be appreciated that the term enterprise relates to any commercial or noncommercial business, company organisation or the like that provides some type of service, product or other activity.

Figure 2 indicates in schematic form an overview of the components 20-23 of the preferred embodiment of the configuration interface 3. A mapped data field index (MDI) generation module 20 is provided which communicates with the enterprise computer system (ECS) 2. The MDI generation module 20 interrogates the databases of the ECS 2 and enables the system operator to view the various data fields implemented in the data structures of the various databases in the ECS 2. The data fields contain data entries representing stored information. The MDI generation module 20 enables the user to select the data fields they wish to utilise in the mobile device task scheduling functionality, and after selection, the MDI generation module produces an index of shadow data fields that replicate or are mapped to the associated fields in the various databases in the RCS 2 that have been selected by the user. The shadow data fields in the index may be given aliases by the user. The mapped data field index (MDI) 31 (seen in Figure 3) replicates the information from the associated field in the ECS 2 selected by the system operator. That is, it is a database with a data structure defining the selected shadow fields, and includes data entries in each shadow data field that replicate the data entries in the associated fields in the ECS 2. The data entries in each data field (or data source) is termed a "dataset".

While generally there will be one to one mapping between the shadow data fields and the data fields in the EBS 2 databases, this is not a requirement. The MDI produced by the COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-206 17:28 A J PARK 64 9 3566990 P.18

O

0 O MDI generation module 20 then provides the system operator with a repository of shadow Sdata fields for use in configuring the task scheduling process for deployment to the mobile O devices 4. This index or library is maintained by the system operator and may be updated en at any time to add or remove references to reflect changes in data source requirements. A choice of data format protocol is provided, using contemporary descriptor standards for data storage technology such as ODBC (object database connectivity), MS Excel 00 (@Microsoft), MS Outlook (@Microsoft), csv (comma separated value), xml (hypertext ~O markup language). The software displays source data extraction views of all fields defined by the MDI generation module IO 10 As shown in Figure 2, the configuration interface 3 further includes a user 0 O configuration module (UCM) 21 that enables the user to design and emulate the desired functionality and GUI for each mobile device 4 of the system. In particular, the emulation software enables the user to design the mobile device GUI to display the required menu elements, information requests (questions) and other information, and where required, link the menu elements to the shadow data fields defined in the MDI 3. During synchronisation, datasets from the ECS 2 data fields associated with the shadow fields are transferred to each mobile device 4 for presentation to the respective users and information entered into each mobile device 4 in respect of shadow data fields therein is transferred back to the associated data fields in the ECS 2.

The UCM 21 enables functionality and GUIs to be emulated and configured for a range of different mobile device types from different vendors. The emulator enables design of a consistent user interface applicable to the technical constraints of the particular mobile device for example, screen size and viewing capability, peripheral device availability such as barcode scanners, global positioning systems (GPS) and handwriting recognition capacity. The emulator depicts a visual representation of the particular mobile device, along with the user configuration of its GUI. The UCM 21 also enables the system operator to simulate their mobile device 4 configuration, prior to deployment of the configuration to the actual device. The UCM 21 also generates configuration data in accordance with the mobile device user interface emulations developed by the system operator. This includes configuration data for deployment to the mobile devices 4 to enable configuration of those devices in accordance with the emulations, and configuration data that facilitates data transfer to synchronise data between shadow data fields implemented on the mobile devices 4 and the associated data fields on the ECS 2. The configuration data relates to display items chosen by a user using the UCM 21 and also COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-206 17:29 A J PARK 64 9 3566990 P.19 -16- 0 o comprises data relating to shadow data fields relating to those display items. The (N configuration data comprises the data required for a mobile device to configure itself as a C) database interface as specified by the user.

O

In addition to the configuration interface 3, preferably each mobile device 4 has a Mobile Device Software Component (MDSC) 22 installed. The MDSC replicates a user interface for each mobile device 4 exactly as configured by the UCM. This is effected by a software program installed onto the mobile device 4 which reactively generates its GUI 0 from definition files relayed from the UCM 21 in over the communications layer. This Ci application sits on each mobile device 4, and uses the configuration data generated by the \0 10 configuration interface 3 to configure the mobile device such that it executes the 0 o functionality and GUI configured by the system operator, and to integrate the mobile device with the ECS 2. In particular, it configures the mobile device to display the GUI designed by the system operator, and it also facilitates the transfer of data to enable data synchronisation with the ECS 2. The MDSC 22 receives the configuration data over a telecommunications layer 24 to be described later on.

The MDI generation module 20 and UCM 21 implement the setup mode of the invention, to generate configuration data and simulate capability, as described above. Once the configuration process is complete, the configuration data is deployed to the mobile devices 4, and the invention enters a run-time mode..An advantage of the invention is that it also allows for re-configuration at run-time, without interrupting the operation mode.

Preferably, a Run-time Scheduling Module (RSM) 23 is also included in the configuration interface that provides a run-time manual user interface to the iCS 2 and the mobile devices 4. This enables a user to provide, edit and re-arrange scheduling status data on the business computer system and the mobile devices 4.

Detailed Description of System and Software According to a Preferred Embodiment of the Invention Figure 3 shows a schematic diagram of the architecture of a preferred embodiment of the system 1, including software executed on the system 1. The system 1 includes a server-side subsystem 30 and a mobile device subsystem. The server-side subsystem includes the ECS 2 and the configuration interface 3 (shown in dotted lines), which is software executing on a computer system as described above. The mobile device subsystem includes one or more mobile devices 4, all executing the MDSC 22 (shown in COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 1-OCT-2006~ 1?:29 A J PARK 64 9 3566990 -17- 0 Sdotted lines). Only one mobile device is shown for clarity. Any suitable number of mobile Sdevices can be implemented in the system each running the MDSC 22.

O The ECS 2 includes one or more databases storing information relating to the r enterprise's business. This may include information such as customer name, address, customer history, customer account information, order and job numbers and the like. This information is stored as individual data entries in respective data fields that are defined in 00 the data structure of the database. The data entries for each data field form a dataset. For O0 example, each of the customer, customer address, customer number and the like is an C individual data field defined in the database, with individual data entries relating to kC 10 respective records. The ECS 2 is in communication with the configuration interface 3.

O The configuration interface includes a computer system running software that includes the MDI generation module 20, a MDI 31, and the UCM 21. A MDSC 22 is on the mobile device 4. All of these modules function as described briefly in relation to Figure 2 above and will be described in further detail below.

The MDI generation module 20 defines which datasets from the ECS 2 are to be replicated as a synchronized database in the MDI 31. Any industry standard database synchronization protocol may be utilized for this function (eg. Oracle PL/SQL or SQL triggers) or a batch or update process to refresh the data on a timer. The MDI 31 provides a database storage of replicated data from the ECS 2 as defined by the MDI generation module 20. The datasets in the shadow data fields in the MDI 31 are updated periodically to reflect changes in the datasets of the associated data fields in the enterprise computer system. So the entire system is based on a fault-tolerant data redundancy communications backbone.

Acting from data within this MDI 31 database, the UCM 21 extracts for each individual participating mobile device 4 a temporary User Interface (UI) definition file 32.

This file stored configuration data relating to the shadow fields (and the datasets contained in them) defined in the MDI 31 that have been selected by the system operator for deployment to a respective mobile device. The UCM 21 is in communication with the UI definition file 32 that stores configuration data.

Likewise the RSM 23, in accordance with system operator selections, extracts a temporary file of current diary tasks defined for the individual participating mobile device 4 assigned. The RSM 23 is in communication with the diary task store 33 which stores configuration data defining diary tasks and other similar scheduling information that is generated by the system operator in the RSM 23. The UI definition file 32 and task store COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-2006E1 17:29 A J PARK 64 9 3566990 P.21 -18-

\O

0 O 33 implement XML data structures containing for each data segment to be transmitted, a standardised header descriptor to specify intended target location appended to variable O content as selected, for storing the required configuration data.

pq The UI definition file 32 and task store 33 are in communication with a temporary update store 34a which is a temporary store reflecting any changes in the UI definition file 32 and task store 33 that have occurred since the last synchronisation process. This is also 00 termed an intermediary store as it acts as an intermediary repository to allow for transfer of data to allow synchronisation between shadow fields in the mobile device and the database in the ECS 2. That is, they include changes relating to: i) datascts stored in data fields in VO 10 the ECS 2 associated with the shadow data fields defined in the MDI 31 and selected for 0 O deployment to a respective mobile device 4, ii) changes in the shadow data field selections for deployment to a respective mobile device 4, and iii) changes in diary tasks effected by the system operator using the ECS 2. The temporary update store 34a also includes data representing changes in respect of diary tasks and datasets that have been specified on the respective mobile device and that have been transferred from the mobile device to the temporary store during a previous data update process for the purposes of altering the computer system data fields to reflect those changes.

The configuration interface 3 on the server-side subsystem according to the invention 1 is in communication with the MDSC 22 installed on each mobile device that forms part of the overall system 1. Preferably, the MDSC 22 on each respective mobile device 4 and the configuration interface 3 are in a non-persistent commnunication, whereby updates occur periodically. The MDSC 22 includes a temporary update store 34b, similar to that in the UCM 21 which is a temporary store of data reflecting any changes in the UI definition file 32 and diary task file 33 of the UCM 21 that have occurred since the last synchronisation (update) process. The temporary update store 34b also includes data representing changes in respect of diary tasks and datasets that have been specified on the respective mobile device 4 for transfer to the UCM 21 temporary store 34b during the next synchronisation procedure for the purposes of altering the ECS 2 data fields to reflect those changes.

The temporary update store 34b exchanges data with a UI definition file 35 and task store 36, and also new data request file 37 and a completed transaction file 38 all of which form part oEthe MDSC 22. The MDSC 22 also includes the application software 39 which exchanges data with these files to facilitate data transfer to achieve data synchronisation, and it also receives configuration data from them and uses this to COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-DCT-206 17:30 f J PARK 64 9 3566990 P.22 19- 0 o configure the MDSC 22 functionality and the mobile device GUI 40 in accordance with Sconfiguration data produced by the UCM 21.

o, In summary, the system allows the definition of shadow data fields relating to data Cc) fields in the ECS 2. The MDI 31 is periodically updated such that the data sets in those shadow data fields reflect the data sets in the associated data fields of the ECS 2. These shadow data fields can be accessed through the UCM 21, and used by a system operator to 00 define the functionality and GUI of each mobile device. Once the configuration has taken o place for a particular mobile device the UCM generates configuration data which is stored c in the UI definition file 32 and diary task file 33 for deployment to the particular mobile \O 10 device during the next synchronisation procedure. The UI definition file 32 and diary task Sfile 33 also include data received from the mobile device 4 during the last data synchronisation procedure for updating the ECS 2 such that the data sets of the data fields therein reflect those of the associated shadow data fields in the mobile device 4. The temporary update store 34a stores configuration data from the UI definition file 32 and diary task file 33 for transfer to the mobile device 4 and also includes data received during the last data synchronisation process from the mobile device 4 for transfer to the UI definition file 32 and diary task file 33. The temporary update store 34a is in non-persistent communication with a respective temporary update store 34b in a MDSC 22 installed on the mobile device. The communication is via a transceiver (or transmitter and receiver) in the server-side subsystem 30 and the respective transceivers in the mobile devices. This could be over a mobile telephone network, or some other suitable network. The temporary data store 34b also contains configuration data received from the temporary update store 34a in the UCM 21 received during the last synchronisation process. It also contains data from its UI definition file 35 diary task file 36 new data request file 37 and completed transactions file 38 for transfer to the temporary update store 34a of the UCM 21 during the next update process. This data is used to synchronise the ECM 22 with the data on the mobile device. The MDSC 22 on the mobile device also includes the application software for utilising configuration data to configure the functionality of the mobile device and the user interface.

Data synchronisation enables data transfer such that the data entries in the specified shadow fields and the data entries in the associated data fields of the database ate altered to mirror each other. Alternatively, data entries in the specified shadow fields are altered to match those data entries in the associated data fields of the database.

Alternatively, data entries in the data fields in the database are altered to match the COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-CT-2006 17:30 A J PARK 64 9 3566990 P.23 o specified shadow fields with which they are associated. Alternatively, some other data transfer regime takes place between the specified shadow fields and the associated data O fields in the database.

C The configuration data is stored in a configuration data store. The data store is in communication with a data store in the mobile device. An application running on the mobile device has the ability to self-configure and re-configure its own user interface 0 dynamically acting on message files in the configuration data store from each system to 00 which the mobile device is addressed. Given this capability, it is possible that various user configuration modules hosted by various enterprises may each deploy a customised S 10 application to the same mobile device, which can select upon start up which host user O configuration module session the user wishes to participate in at that time.

Each of the components of the system architecture 1 shown in Figure 3 will now be described in detail.

Mapped Data Fields Index (MDI) and Mapped Data Fields Index (MDI) Generation Module As described in the overview, the MDI generation module 20 enables a system operator to select the desired data fields defined in the database structure of the business ECS 2 for use in the UCM 21 to configure mobile device 4 task scheduling functionality and GUI. The selected fields are mapped and stored in the MDI 31.

Figure 4 shows in schematic form a GUI 40 for operating the MDI generation module 20, containing a number of fields with example selections as shown. Figure shows an example data structure 50 of a database in the ECS 2, and an example mapped index in the MDI 31, generated using the GUI 40. As can be seen, the example database structure includes one database called "SALES", which includes tables called "CUSTOMER", "PRODUCTS" and "PIICING". The "CUSTOMER" table includes the data fields named "C_NAME", "ADDRESS" and "PHONE" with the fields being populated with the data entries as shown. It will be appreciated that the "PRODUCTS" and "PRICING" fields will also have defined data fields and data entries, although these have been omitted for clarity. Further, there may be more than database, although again, only one is shown here for clarity.

In overview of the MDI generation process, the system operator uses the MDI generation module 20 to select from the available list of databases (or inputs a valid Connection string) and then selects from a list of tables within that database, then selects COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-DCT-206 17:30 A J PARK 64 9 3566990 P.24 -21o from a list of field names within that table, which datasets the user wishes to nominate for Sthe MDI to maintain as an offline storage replication of the enterprise computer system Q data. The system operator may optionally define an 'Alias' (alternate descriptor) for each en field, to make the MDI 31 datasct more readable.

Referring to Figure 4, the interface 40 includes a selection box 41 providing predefined options of standard database connection types, which the user may choose. In this 0c case an ODBC connection method is used to connect to the ECS 2 database. A range of 0 other connection methods could be provided for selection. The interface 40 also includes C a database name selection box 42 indicating which of the databases in the ECS 2 the MDI S 10 generation module 20 should connect to. In this example, the database named "SALES" is O selected from a number of filename location descriptions for the databases in the ECS 2. A N table name selection box 43 is provided to select a table name "CUSTOMER") from within the "SALES" database, and a field name selection box 44 is provided to select a field name "CC NAME") from within the "CUSTOMER" database table. An alias input field 45 is provided for optional input of an alias, namely an alternative reference title for the field name. This alias is used in the MDI 31. An activation button 46 enables the user to view an extract of the data specified, for visual verification of a sample of the selected data contents. The user interface 40 can be used to select and alias a number of different field names, from a number of different table names, from a number of different databases in the ECS 2. For each selected field name, a corresponding shadow data field is created in a MDI 31, as shown in Figure 5. In this case a mapped data structure of including the "C_NAME" and "PHONE" fields of the "CUSTOMER" table of the "SALES" database is shown. The "Company Name" shadow data field and associated entries are shown as generated according to the example in Figure 4. The "PHONE" shadow data field shown would be generated in a similar manner.

The purpose of the MDI generation module 20 and MDI 31 is to create an indirect link between the ECS 2 databases and the mobile device platform. It can be seen that this definition structure supports discrete mapping of any available data fields within a standard RDBMS (relational database management system). Passwords required by the ECS 2 for security access to these tables, will be prompted as required from this screen. This first part of the setup process preferably occurs in a secure, high-bandwidth network environment attached to the business computer system by TCP/IP, which is suited for the resource intensive task of mapping and synchronizing a replicated database potentially accumulated from various sources including multiple mobile devices.

COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-2006 17:31 A J PARK 64 9 3566990 22

INO

o In a possible implementation, a software program is developed using the Microsoft.NET development environment to display the user screens described following and carry out all technical functions automatically as required transparent to the user. This CC) is facilitated by an ADODB connection from within the Microsoft.NET development environment which enumerates to the user of the MDI generation module 20, all available data sources registered on the host computer via standard ODBC connections on the 0 attached TCP/IP network server(s). Having generated the MDI 31, the MDI generation 0 module 20 then perpetually maintains a regular or persistent data synchronization via the ^c internal (industry standard) ADODB connection method in both directions as required to S 10 maintain an offline replicated subset of the server data in a format suitable for use by UCM o 21. In the preferred embodiment, this data would be stored in an industry-standard RDBMS such as MSAccess mirroring the structure of the source data tables selected from the ECS 2 databases, for example as shown in Figure 5. Note however that the data storage format is not limited to a defined RDBMS structure but may alternatively be stored in an XML text format structured to suit the data contents required. Any other suitable format known to those skilled in the art could also be used.

User Configuration Module (UCM) The UCM 21 works on two levels. The first level provides a means to emulate each mobile device type in the system and configure the MDSC 22 of those devices 4 so each respective mobile device provides the required graphical interface and functionality to enable user in the field to carry out the required tasks. At another level, it also generates the underlying configuration data reflecting the system operator configurations, that enables the deployment of the configurations to the mobile devices 4, and integrates the mobile devices and ECS 2 to enable data transfer between them in accordance with the new configurations. To facilitate this, the preferred UCM 21 will emulate on screen both pictorially and functionally, a mirrored simulation of what the end application would look like and function like, on the target mobile device 4.

Figure 6 shows in schematic form a user interface 60 of the UCM 21, including the screen design elements for developing the scheduling functionality and graphical user interface for execution on the mobile devices 4. By means of an emulation screen, the configuration software is made to appear with a similar graphical display to the intended run-time version of the mobile device 4 display for which configuration is taking place, displaying the same functional elements. The UCM 21 provides editing of the screen COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-206 17:31 A J PARK 64 9 3566990 P.26 -23 o displays for the mobile device, to provide the required scheduling functionality, then allows simulation in run-mode to trial the resulting functionality/GUI that is configured. This may 0 then be simulated over a network or across real mobile devices 4 with the MDSC 22 O loaded, which will receive operating parameter files generated from that model, interpret and run that model immediately as configured by the system operator.

The structure of the mobile device 4 functionality and GUI is defined by 'pages'.

c n Each 'page' 64) represents a screen-full display of display elements on the mobile 0 0 device 4, as appropriate to the screen display capability of the device. These 'pages' can be 00 C organised into a user-configurable hierarchical menu structute of options (with user- 0 10 defined titles), so that the design may support many 'pages' of business activity processing, o each with its own navigational title meaningful to the user but entirely configurable by the C UCM 21. More detail on the actual functionality is described later on. With reference to the user interface in Figure 6, the functionality and GUI of mobile devices 4 is configured as follows. The mobile device 4 type is selected (in this example "Interrne CN3") from a drop-down list of possible mobile device types from different vendors that arc support by the UCM 21. This controls the display picture characteristics of the device illustration 63 to closely resemble the actual device. A device name or id is specified in field 62 to enable automated deployment of device configurations by the software as soon as the configuration for the selected mobile device is completed and saved by clicking the "save page" button 69. The configurations are deployed to a mobile device having a mobile client software installed and having the selected identifier pre-set in the mobile software.

Given this capability, it is possible that various UCM 21 hosted by various companies may each deploy a customised application to the same client mobile device, who can select upon start up which host UCM session the user wishes to participate in at that time.

The simulated navigational buttons 65 acting in identical function to that of the mobile device 4, enables this emulation to navigate through identical screens to the target device. The difference to the actual mobile device on which the configuration will be deployed is that the page tides and options are directly editable on this screen so that the UCM system operator may customise and save the configured mobile device functionality.

The mobile device emulation displays a number of editable menu elements 64, the label of which can be edited to identify their function. The function could be a link to a sub-menu, a link to data pertaining to a data field, a barcode scan, data input, information request, or any other functionality required. For example, one menu clement is edited to say "Customer Name?". Another is edited to say "Barcode Scan". Next to each menu COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-CT-206 17:32 A J PARK 64 9 3566990 P.27 -24o element 64 is a field with a drop-down list of action methods 66 that may be individually Sselected to configure the function of the associated menu element. Six example methods O are illustrated in Figure 6 next to the six menu elements 64, which provide the basic input n and action options allowable, when the end user (on the target mobile device) selects the indicated corresponding menu clement in the run-time version. Other methods will be known to those skilled in the art, and the six shown are merely exemplary. In the example 00 shown, the method associated with "Customer Name?" is configured with a method to 0 provide a question (such as "Please enter customer"). The method associated with the last c menu element would be "Barcode Scan" As a further example of the software N0 10 implementation logic, at run-time on the mobile device the software would pop-up a o numeric keypad when the user selects the "ORDER QUANTITY" element as illustrated, this being applicable for the data type selected- A corresponding list of six exemplary datasets 67 populated from the shadow data fields m the MDI 31 linked to the UCM 21 module enables configuration of source data to populate the action method that has been selected. For example, in respect of the question method for "Customer Name?", a data field dataset is selected that is defined as being sourced from the data table "Sales Customer Name" from the MDI 31. In the illustrated example of the Barcode scan at "Menu Option 6" this would validate the barcode scanned from the table "Sales Products Code" rather than display a list, because the software has this logic built into it to process results on the basis of data type applied. Fields 68 enable the system operator to specify the storage location for input data from the mobile device user in response to the respective methods (such as questions).

This input data is saved as new transactional data into the MDI 31 which is subsequently relayed to the ECS 2 by the MDI 31. In summary, in reference to Figure 6, the menu options 64 are edited to specify the question to ask, or other required functionality. The associated configuration field 66 defines a method, such as how to ask the question. The respective dataset configuration fields 67 define optionally what to ask, and the configuration fields 68 define where to store the answer.

Once the system operator has configured the desired functionality and GUI of the mobile device 4 through use of the interface 60, the UCM 21 generates configuration data representing the system operator configurations. The configuration data includes user interface definitions which are stored in the UI definition file 32. This specifies the menu options, the actions associated with those menu options, the shadow data fields associated with the actions, and the shadow data fields to which input data should be transferred.

COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-200 17:32 A J PARK 64 9 3566990 P.28 \0O o This configuration, data when transferred to the respective mobile devices, enables those devices to configure themselves to carry out the designed functionality and render the O designed GUI. The configuration data in the UI definition field 32 is then deployed to the O mobile device 4 identified during the next update procedure. The update procedure will be described in detail later on.

The emulated graphical interface 63 also includes a "TODO" button 64a. This

C

c leads to the menu with all the diary tasks that are nominated for a user of the mobile device 00 o to carry out The diary tasks in this menu can be edited at run-time, and therefore 00 C' preferably this portion of the mobile device 4 functionality and GUI are configured using S 10 the optional Run-time Scheduling Module (RSM) 23. When activated in the UCM 21, the o "TODO" button activates the RSM 23, which will be described later in relation to Figure C 12. Alternatively, it is possible for this configuration to be carried out using the UCM 21.

Run-time Scheduling Module (RSM) Once the configuration of the mobile device 4 and system has taken place using the UCM 21, and the configuration has been deployed and implemented, a RSM 23 provides a user interface to centrally maintain and coordinate schedules of pending activities for each or several of the mobile device users. This includes: 1. An editable list of diary items 2. For each item, a. Ability to set priority of this task b. Set a colour code for this task (as displayed on the mobile device) c. Additional job information with definitions mapped to the DLAI for automated data population d. Supplemented with free text information c. Definition of a corresponding Activity page (as Figure 6) to which the mobile device user will be directed upon selection of that diary item task 3. Definition of automated schedules import from the MDI with respect to automated population of diary items at regular intervals prescribed, for each mobile device.

Figure 7 shows a user interface 70 of the RSM, that includes the mobile device's display of a "TODO list" which during run-time is reached by activating the "TODO" button displayed on the mobile device screen. During run-time the scheduling component enables alteration of the diary tasks and other parameters of the to-do list that appears on COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-200 17:32 A J PARK 64 9 3566990 P.29 -26 Sthe mobile device. The diary tasks 71 may be edited directly or an automatic population of _c these items defined by selection of an available MDI data field source 72. In a similar 0 fashion to the UCM 21, for each diary task the user may set values for each of: Priority (sequence) number 73 Colour for highlight on the mobile screen 74 S Input free-text Notes 75 for display as per Figure 11 3 Select a Question page tide 76 from a list of all question pages (ie. Figure 10) as 0 defined in UCM 21 for this device.

OO

c( For example, as shown in Figure 7, there are three diary tasks each with a S 10 configured menu element 71. They are "Supply product to ABC", "Visit Big Co." and o "Ring Little Co." These tasks have been sourced from a "Diary Tasks" data field in the enterprise computer system, as shown in data source field 72. Each menu element has been labelled with the diary task as per the entry in the data source data field, and each has been assigned a priority and colour. In addition, notes can be provided and related questions can be defined. This enables a system operator to dynamically schedule tasks that can be deployed to respect mobile devices, and displayed in accordance with the functional and GUI configurations of the respective mobile devices 4. Once a schedule defined on the interface 70 is completed, the "Save Page" button is pressed and configuration data detailing the schedule stored in the diary tasks file 32. This information is then deployed to the mobile device 4 identified during the next update procedure. The update procedure will be described in detail later on.

The RSM could also enable the rearrangement of diary tasks between different mobile devices of different users. This could be by way of an additional screen, showing tasks on various devices, and facilitating rearrangement.

It should be noted that the RSM 23 is optional, and the invention could operate without this module.

Mobile Device and Mobile Device Software Client (MSDC) Each mobile device 4 has a processor, communications system, memory and other data storage capability, display and input means, as is known to those skilled in the art. The each mobile device could be one of a range of different types of such devices provided by a range of vendors. In combination with the MDSC 22 which it executes, the mobile device is adapted to carry out the functionality designed on the UCM 21 and in particular display, store and receive data. The data can be received from the server-side subsystem and can COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-OCT-206 17:33 A J PARK 64 9 3566990 -27-

O

o be received from a user of the device via an input means. The shadow data fields defined

C

N for use by the mobile devices 4 and datasets contained in those data fields are stored in the O mobile device memory in a suitable manner known to those skilled in the art The MDSC 22 is a client application loaded onto each participating mobile device 4. It includes all the components shown in the dotted box of Figure 3 and as described in relation to that Figure. The preferred method of development is the Microsoft VB.Net c mobile device programming language, and installation would be facilitated by a standard 0 Microsoft Setup program. The MDSC 22 enables the mobile device on which it is installed 00 to communicate with the server side of the subsystem 30 to receive configuration data S 10 from the UI definition 32 file and the task file 33. It further enables the device to o configure itself using the configuration data such that it carries out functionality designed c by the user on the UCM 21, renders a GUI in accordance with the design, and allows transfer of data to synchronise data entries in shadow data fields between the mobile device 4 and associated data fields in the ECS 2. Once installed, a text definition file related to the program is configured with a unique device name and a defined URL to the host TCP/IP network address, and the application is ready for use. This application has the ability to self-configure and re-configure its own user interface dynamically acting on message files from each server-side system to which it is addressed.

Periodically, the MDSC 22 communicates with the server-side subsystem 30 to exchange data in an update process to be described in detail later on. During exchange, the MDSC 22 receives configuration data from the UI definition file 32 and the diary task file 33 in the server-side subsystem 30. Preferably, the configuration data is in XML format, although any other suitable file format could be used. Within the structure of the XML message file is a checksum facility so that the receiving application (MDSC) is able to verify that the file has arrived undamaged. If so, it removes the file from the server after advising next version as a flag to the UCM 21. Now the MDSC application parses and interprets the xm message file, to construct and maintain the following structured XML data files for use by the (ie. its own) User Interface: User Interface definition file Diary items pending action Data lists required for population of selection lists on question screens This received configuration data is stored in the UI definition file 32 and diary task 33 definition file which form part of the MDSC 22. Now the MDSC application uses each of these XML definition files to dynamically build its own screen layouts to display to the COMS ID No: SBMI-05042446 Received by IP Australia: Time 14:34 Date 2006-10-13 13-DCT-2006 17:35 A J PARK 64 9 3566990 P.02/30 -28-

O

o user. Given that screen layouts conform to standard common formats, upon startup it will parse the UI definition file (stored locally 35) to construct the Main Menu options. As each Snavigation button is pressed on the screen the application parses the UI definition file n or diary tasks 36 file, or data list files as applicable to build and display the resulting screen.

Thus the mobile device 4 can change functionality and its GUI 40 dynamically, reacting to events advised by the server-side subsystem 30 over a real-time but non-persistent 00 communications medium. Once the initial MDSC 22 has been installed on the client C device 4 it has the perpetual capability to upgrade itself and learn' new business rules dynamically based on configurations made in the UCM 21 and RSM 23.

IN 10 During the update process, the MDSC 22 also performs a similar file transfer o mechanism in the reverse direction, collating all new transactional data created using the MDSC User Interface 40, which would be operating concurrently, into a send message file stored in the completed transactions file 38. The data in the completed transactions file is then copied to the server-side subsystem 30. The UCM 21 similarly parses each message file received and merges its data instructions into the MDI, which subsequently triggers the MDI 31 generation module 20 to relay these new transactions to the ECS 2.

Figure 8 shows the display of the mobile device 4 once it has configured itself in accordance with the configuration data generated by the system operator using the UCM 21. As can be seen, the display is configured to mimic all the menu elements 81 designed on the UCM 21 as described in relation to Figure 6. A Main menu of options is presented to the user for selection upon program startup. This menu might further branch to other menu pages of sub menus e.g. button 81a, with each menu list having a title and menu option items and navigational buttons 83 with which to navigate through the hierarchical menu structure, or scroll up and down through more available menu items for selection.

Alternatively, the menu item might relate to a question, for example "Customer Name?' 81b, or the menu item in the case of "TODO" button 84 provides a link to a set of diary tasks.

Referring to Figure 9, upon clicking the "TIODO" button 84, the user is taken to a todo list screen 90, which lists the diary tasks 91, as configured using the RSM 23 in the manner described above. The diary items on this screen would be regularly populated by requests issued from the RSM 23. Each item would typically branch directly to an information display page revealing further particulars about the task, then further to an activity page upon which questions are asked related to this diary activity. For example, clicking on a menu item 91a in the todo list might bring up the informatiun scxccn, such as COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-CT-2006 17:35 A J PARK 64 9 3566990 P.03/30 29

NO

0 O shown in Figure 10. A title for the page related to the diary task or activity is displayed, below which is displayed information relating to the diary task. The menu clement in O Figure 9 and the display in Figure 11 relating to the diary task will be configured according Mn to the selections made in the RSM interface screen 70 shown in Figure 7. A search button enables the user to search current records of similar data to that highlighted by the user and display this data also in the information panel. In addition, questions might be asked, and Ce 00 information entered in response. The fields in this screen can be populated with 00 information from associated data fields in the enterprise computer system and entered data can be transferred back to those data fields during the data synchronisation process.

S 10 Such as in the case of the "Customer Name?" menu element, clicking on an o element may take the user to an activity page upon which questions are asked as shown in Figure 10. The user may elect to view or input data on an ad hoc basis at any time, or may be taken to same screens as a result of a diary item request as described following. A list of questions defined by the system operator via the UCM user interface 60 are presented to the user for selection or input In general, there may just be one question, or multiple questions. Upon selection of a question the software will display an input facility corresponding to the data type requested. This could be in the format of a pop-up numeric keypad or alpha keypad or free-form writing or drawing panel, or a list of available predefined selections or may prompt the user to collect the data via a peripheral device attached to the mobile computer eg. Barcode scan. The answers provided are displayed for visual confirmation before saving/sending (indirectly) to the ECS 2.

Referring back to the menu elements in Figures 8, 9 and 10, the MDSC 22 configures functionality of the mobile device such that the questions and shadow data fields configured in relation to each menu element are implemented on the mobile device.

For example, the "Customer Name?" question which relates to menu option 4 is linked to a shadow data field defined in the device memory, which in turn is associated with one or more data fields in the ECS 2. When information is entered into the device in relation to this field, in the question screen in Figure 10, update data is stored in the transactions completed file 38, and ultimately the temporary update store 34b in the mobile device.

Upon the update procedure, the data in the shadow field is thus transferred to the associated field int the ECS 2. Similarly, data in the data field in the ECS is during update transferred to the shadow data field in the mobile device, for use and display by the device 4. The transfer of data between the shadow data field defined in device memory and the associated device in the ECS 2 is referred to as data synchronisation. Similarly, shadow COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-CT-20306 1?:36 A J PARK 64 9 3566990 P.04/30

NO

0 0 data fields are defined for the remaining menu options where appropriate which enables data synchronisation with the associated data fields in the ECS 2.

0 In summary, the structure of the preferred mobile device application allows for the Cen following basic functions, which are presented to the user in a consistent manner and interface regardless of the variable content of specific questions or information displayed: U A hierarchical set of menu options.

00 These menu options leading to activity pages 00 These activity pages to contain diary items to complete and/or; C Questions and answers in pre-defined formats to complete and/or, o 10 Display of related information from the ECS SHaving navigated through the menu structure, the user would arrive in each case, at an activity page with elements as illustrated in Figure 8. Each page may collect business data from the user, or display relevant data from the ECS 2. The UCM 21 enables configuration of any data from the MDI to be displayed at various screen locations on any page. Conversely, the UC module can define any question prompts from the mobile device user, to collect data from the device (either by manual input or configuration to a peripheral electronic measurement or data capture device attachment to the mobile device) and update this answer with an automated date and time allocation for the transaction, back to the MDI (and subsequently, the ECS as new transactional data).

The mobile device could support fingerprint recognition to control access to the device and validate a user.

Communications between Server-Side Subsystem and Mobile Devices Referring back to Figure 3, the communications between the server-side subsystem 30 and the mobile devices 4 will be described in detail. The communications enables deployment of the mobile device configurations to enable configuration of the devices to provide the desired functionality and GUI. Further, the communications provides a data synchronisation or update process in accordance with the configurations.

As described earlier, the server-side subsystem 30 includes a UI definition file 32 which contains configuration data for configuring the mobile device with the required functionality and GUI, and a diary task file 33 which contains configuration data for providing scheduled tasks to the mobile device. The temporary update store 34a stores data reflecting changes in both files since the last update or synchronisation procedure with the respective mobile device 4. The MDSC 22 on the mobile device has UT definition file COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-DCT-200 17:36 A J PARK 64 9 3566990 P.05/30 -31

\O

0 O 35, diary task file 36 data request file 37 and completed transactions file 38. It also has a Stemporary file 34b that stores data reflecting changes in these files since the last update or O synchronisation. This MDSC 22 software connects its temporary update store to that of n the configuration interface via standard (radio) telecommunications protocols to relay data at regular intervals, as appropriate to the telecommunications service available.

The communications setup provides an inherent fault-tolerant service by allocating Cn 00 off-line temporary storage at both locations which synchronize each end's data contents by 00 confirmation and validation of sequential message files before activating them, in both Sdirections from the mobile device. This reduces the risk of data loss from the mobile O 10 business operation deployment The telecommunications transfer process is triggered at o the mobile device 4 by means of a polled data transfer process at regular intervals controlled by a preset timer which checks for new messages at either end of the connection in the temporary message folders 34a and 34b. The incoming messages are extracted into the various data groups required for use by the MDI 31. Application software 39 on the mobile device to construct the GUI 40 in real-time and collect transactional data to be relayed back through the same /reverse process back to the Server.

It should be noted that the UCM 2 itself provides such a replicated off-line storage of mapped data fields from the ECS 2 in the same fashion. The MDI generation module defines which datasets from the ECS 2 are to be replicated as a synchronized database in the MDI 31. Any industry standard database synchronization protocol may be utilized for this function (eg. Oracle PL/SQL or SQL triggers). So the entire system is based on a faulttolerant data redundancy communications backbone. In reference to the drawing Figure the MDI provides a database storage of replicated data from the ECS as defined by the MDI generation module 20- Acting from data within this MDI database, the UCM 21extracts (for each individual participating mobile device assigned) a tempotaty User Interface definition file 32. Likewise the RSM 23 extracts a temporary file 33 of current diary requests for the individual participating mobile device 4 assigned. These files are maintained in a temporary message folder 34a awaiting telecommunications transfer to the mobile device 4.

Having collected user inputs as described the UCM 21, RSM 23 and MDSC 22 act together to store and move data files in the manner described, to complete the communications and deployment process. In the preferred software development implementation, the UCM 21 software having collected user defined configuration settings for each individual mobile device to be deployed, stores these settings in a structured XML COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-OCT-206 17:36 A J PRRK 64 9 3566990 P.06/30 -32-

INO

o file on the desktop pc/server where the UCM is run, in individual files discrete to each mobile device (name) specified. The UCM 21 does not attempt to parse or extract data O from the MDI 31 in this step; it is simply recording a definition file of the chosen operating parameters of each mobile device 4. Typically these definition files would not be changed often after initial creation; from that point the UCM 21 acts primarily in an automated background processing role to collate and relay message data as described following. The oc RSM 23 stores data files in a similar fashion, to an XMI. file for each participating mobile 00 Sdevice, but typically on a regular basis as these user inputs are related to regular transient 00 transactional data.

0 10 The UCM operating in its automated background processing mode now collates o (on a regular titer control) all required message data to be relayed to each mobile device, into discrete XML files for each device ready for collection by the MDSC 22 at a shared network location.

Each XML transmission file contains 'change advice' records for each of the following events: Changes to the User Interface definition file Changes to any records contained in tables in the MDI nominated for use by his device, as parsed from its UI definition file New diary items generated by the RSM On a timer the application polls the server at regular preset intervals across a public data transport protocol (ie. any standard communications protocol provided with the device hardware, typically GPRS/CDMA telecommunications or 802.11 WIFI) to request the waiting message file nominated for this device (ie. user) on that server (generated by the UCM as described above).

Data Structure of UI Definition, Diary Task, Temporary Update Store, New Data Request and Completed Transaction Files.

The files 32, 33, 34a, 34b 35, 36, 37 and 38 used for transferral of data relating to configuration and synchronisation utilise a suitable data structure to store the information.

Figure 12 shows one example of a data structure that could be used for each file 32, 33, 34a, 34b 35, 36, 37 and 38, although this is exemplary only, and other data structures could also be used. It will also be appreciated that Figure 12 shows only a portion of each file for clarity reasons. Each file could contain a large number of fields and entries as required, and a separate file might be used for each mobile device, and mobile device type, as required.

COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-DCT-20066 17:37 A J PRRK 64 9 3566990 P.07/30 -33-

\O

0 O Each file indicates a DevicelD to indicate this. The fields and the data entries populated therein are in accordance with the system operator's configurations selected, as described O above.

SReferring to Figure 12, the UI definition files 32, 35 for the server-side subsystem 30 and mobile device side subsystem are shown. They include PagcID and LocationlD fields which contain entries showing the location on the page and the page itself in the 00 menu structure, of each menu element that has been configured in the UCM 21. The Tide 00 field shows the system operator defined label for each respective menu element, and the Action Method field shows which action was configured. The Dataset View and Dataset S 10 Save fields relate to the shadow fields that will be deployed for use on a mobile device 4, 0 and for which data synchronisation will take place between the mobile device 4 and the ECS 2.

The diary task files 33, 36 for the server-side subsystem 30 and mobile device side subsystem are also shown. The data entries and fields are in accordance with the configurations that are preferably made in the RSM 23 as described above. They include a Sequence field for indicating an order of the tasks, along with a Task field identifying the task, a Colour field for display purposes and Notes field, and a PageID showing which page the task will be displayed on in the mobile device 4 GUL The Temporary Update Store files 34a, 34b reflect changes in the other files since the last synchronisation, and therefore indicate what data needs transferral between the mobile device 4 and the server 30 at next synchronisation. A Record Type field indicates the data type of record that needs updating, e.g. task or data associated with a menu element. Datal, Data2 and Data3 fields indicate references and labels respectively that identify the data requiring synchronisation. Datn4 specifies the actual data that requires transferal during synchronisations and Data5 and Data6 fields show the source and destination data fields that the Data4 will be transferred between.

On occasion the mobile device may relay a uscr-generated request to the MDI 31 for specific supplementary information activated on-demnand by the Search button on the Information screen (see Figure 11). The New Data Request file 37 provides a structure for accumulating this request and the subsequent answer provided by the MDI 31. This file data is relaying to and from the MDI 31 via the Temporary Update Store files 34a, 34b in the.same manner as 32,33,35,36.

All user responses to the Questions Screen (see Figure 10) are collected in the Transactions Completed file 38 for relaying to the MDI 31 via the Temporary Update COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-DCT-20066 17:37 A J PARK 64 9 3566990 P.08/30 -34-

O

0 o Store files 34b, 34a. The Transactions Completed file 38 includes a Dataset field providing Sthe target location in the MDI 31 and a Value field providing the results data collected U from the user, to be stored in the MDI 31 as transactional records.

C)

00 0 00

O

0 ci COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-CT-20063 17:37 A J PARK 64 9 3566990 P.09/30

NO

SMethod of Use The flow charts in Figures 13 briefly summarise the method carried out by both an 0 operator and the system during operation of the invention, as described in more detail above.

Firstly, in step 130, the MDI 31 is created by the system operator using the MDI generation module 20. The system generates the MDI 31 in accordance with field 00 selections made by the system operator, and periodically updates the data entries therein by 0 0 synchronising with the ECS 2. Next, step 131, the system operator configures the desired functionality of each mobile device 4 using the UCM 21. In addition, step 132, the system I0 10 operator may simulate their configurations for each mobile device 4 using the UCM 21.

o Next, step 133, task schedules can be configured using the RSM 23 (often this may take place after initial deployment of configurations). It will be appreciated that this sets out the initial set up, but reconfiguration can take place at will by the operator, as indicated at step 136, 137 as reconfigurations are required. Next, step 134, the configurations are deployed, during a synchronisation update procedure carried out by the system on a timer basis as described earlier. Also, step 135, data synchronisation takes place as described. It should be noted that steps 134 and 135 could occur in the same process. These two steps will occur repeatedly as shown at step 135a, as the system carries out the update process after waiting for a time.

It will be appreciated that the configuration and synchronisation steps of the method could occur in any order, and the order shown is merely for exemplary purposes.

Update occurs periodically and reconfiguration can take place at any time as required by the operator.

COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13

Claims (33)

13-DCT-006 17:37 A J PARK 64 9 3566990 P.10/30 -36- \O 0 o WHAT WE CLAIM IS: ci Q 1. A method of configuring one or more mobile devices to provide one or more user C interfaces to at least one database on a remote computer system, the method comprising the steps of: defining an index of one or more shadow fields, each shadow field being associated 00 with one or more of data fields in the at least one database, and 00 receiving input defining a user interface to the at least one database for deployment C on a mobile device, and 10 generating configuration data specifying the user interface, the configuration data O comprising data specifying one or more of the shadow data fields associated with the user interface, wherein the configuration data is adapted to configure a mobile device as a user interface to the at least one database by; configuring the mobile device to display, store and/or receive data entries in relation to the shadow data fields specified by the configuration data, and configuring the mobile device for data synchronisation of data entries in relation to the specified shadow data fields with data entries in the one or more associated data fields in the database. 2. A method according to claim 1 wherein the configuration data is adapted to be received and utilised by a mobile device to configure itself to provide the user interface. 3. A method according to claim 2 further comprising the step of transferring the configuration data to one or more mobile devices during a communication session. 4. A method according to claim 3 wherein the configuration is transferred over a non- persistent communications channel 5. A method according to claim 4 wherein the configuration data is transferred periodically during a communication session COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-OCT-206 1?:42 F J PFRK 64 9 3566990 P.28/30 -37- NO 0 0 6. A method according to any preceding claim wherein the step of receiving input Sdefining a user interface to the at least one database comprises receiving input specifying O one or more display items for display on the mobile device. C) 7. A method according to claim 6 wherein the configuration data further comprises C data specifying one or more of display items. 00 0 00 CN 8. A method according to claim 6 or 7 wherein the display items comprise one or N0 more of: menu options, icons, requests for information, data input fields. o 9. A method according to claim 7 or 8 wherein the configuration data is adapted to be received and utilised by a mobile device to configure itself to receive data in relation to one or more of the display items and store received data in one or more shadow fields associated with a respective display item for which data is received A method according to any preceding claim wherein the step of receiving input defining the user interface to the at least one database comprises receiving input defining tasks and/or questions for display and/or storage on a mobile device, wherein the tasks and/or questions are associated with one or more of the shadow data fields. 11. A method according to claim 10 wherein the configuration data further comprises data specifying one or more of the tasks and/or questions for display and/or storage on the mobile device. 12. A method according to any one of claims 3 to 11 whercin prior to the step of transferring the configuration data to one or more mobile devices during a communication session, the method comprises the step of storing the configuration data in an intermediary store. 13. A method according to claim 12 above wherein the step of transferring the configuration data to one or more mobile devices during a communication session comprises transferring the configuration data from the intermediary store to a data store in each respective mobile device. COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-OCT-2066 17:38 A J PARK 64 9 3566990 P.11/30 -38- NO 0 O 14. A method according to claim 12 or 13 further comprising the step of receiving data from one or mobile devices and storing it in the intermediary store. O 0 A method according to claim 13 above further comprising step of updating the at least one database with data in the intermediary store received from one or more mobile devices. 00 00 16. A method according to any preceding claim further comprising the step of synchronising data in the data fields of the at least one database with data stored in relation V N O 10 to the shadow data fields specified by the configuration data..

17. A method according to any preceding claim comprising transferring the configuration data to a plurality of mobile devices.

18. A method according to any preceding claim wherein the step of receiving input defining a user interface to the at least one database for deployment on a mobile device comprises: receiving user input specifying the mobile device type of a desired vendor, emulating a graphical user interface of the mobile device, and receiving input selecting display items with one or more associated shadow data fields.

19. A method according to any preceding claim further comprising the steps of receiving the configuration data at a mobile device and configuring the mobile device as a user interface to the at least one database using the configuration data. A method according to claim 19 further comprising the step of receiving further configuration data at the mobile device and re-configuring the mobile device as a re- configured user interface to the at least one database using the configuration data.

21. A method according to claim 20 wherein futhcr comprising the step of synchronising data in the specified shadow data fields with data in the data fields of the at least one database. COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-OCT-206 17:38 Al J PRRK 64 9 3566990 P.12/30 -39- INO O 22. A system adapted to facilitate configuration of one or more mobile devices to provide one or more user interfaces to at least one database on a remote computer system, 0 the system comprising; M a computer system comprising, or adapted to communicate with, at least one database that comprises a data structure with one or more data fields, each data field for storing one or more data entries,, the computer system comprising at least one computer oc programmed to: 00 O define an index of one or more shadow fields, each shadow field being associated C with one or more of data fields in the at least one database, and IO 10 receive input defining a user interface to the at least one database for deployment 0 o or a mobile device, and generate configuration data specifying the user interface, the configuration data comprising data specifying one or more of the shadow data fields associated with the user interface, wherein the configuration data is adapted to configure a mobile device as a user interface to the at least one database by: configuring the mobile device to display, store and/or receive data entries in relation to the shadow data fields specified by the configuration data, and configuring the mobile device for data synchronisation of data entries in the specified shadow data fields with data entries in the one or more associated data fields in the database.

23. A system according to claim 22 wherein the configuration data is adapted to be received and utilised by a mobile device to configure itself to provide a user interface.

24. A system according to claim 23 further comprising a definition file coupled to or integrated with the computer for storing the configuration data. A system according to anyone of claims 22 to 24 wherein the system comprises a first transmitter and the computer is further programmed to transfer the configuration data to one or more mobile devices during a communication session via the first transmitter.

26. A system according to claim 25 wherein the configuration data is transferred over a non-persistent communications channel COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-OCT-206 17:38 A J PRRK 64 9 3566990 P.13/30 40 o 27. A system according to claim 26 above wherein the configuration data is transferred periodically during a communication session. C

28- A system according to any one of claims 22 to 27 wherein receiving input defining a user interface to the at least one database comprises receiving input defining one or more C display items for display on the mobile device. 00 00 S29. A system according to claim 28 above wherein the configuration data further o comprises data specifying one or more of display items. 0 N A system according to claim 28 or 29 wherein the display items comprise one or more of menu options, icons, requests for information, data input fields.

31. A system according to one of claims xx wherein the configuration data is adapted to be received and utilised by a mobile device to configure itself to receive data in relation to one or more of the display items and store received data in one or more shadow fields associated with a respective display item for which data is received.

32. A system according to any one of claims 22 to 31 wherein receiving input defining a user interface to the at least one database comprises receiving input defining tasks and/or questions for display and/or storage on the mobile device, and the tasks and/or questions are associated with one or more of the shadow data fields.

33. A system according to claim 32 wherein the configuration data further comprises data specifying one or more of the tasks and/or questions for display and/or storage on the mobile device.

34. A system according to anyone of claims 25 to 33 further comprising an intermediary store coupled to or integrated with the computer wherein prior to transferring the configuration data to one or more mobile devices during a communication COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-OCT-206 17:39 A J PARK 64 9 3566990 P.14/30 -41- 0 O session, the computer is programmed to store the configuration data in the intermediary Sstore. 0 0 en 35. A system according to claim 34 wherein transferring the configuration data to one or more mobile devices during a communication session comprises transferring the configuration data from the intermediary store to a data store in each respective mobile 00 device using the first transmitter. 00

36. A system according to anyone of claims 22 to 35 wherein the system comprises a o 10 first receiver, wherein the system is adapted to receive data from one or mobile devices via Sthe first receiver and store it in the intermediary store, the data comprising data in the specified shadow data fields.

37. A system according to claim 36 wherein the system is adapted to update the data fields of the at least one database that are associated with the specified shadow data fields, the data fields being updated with data from the intermediary store received from one or more mobile devices.

38. A system according to anyone of claims 22 to 37 wherein the receiving input defining a user interface to the at least one database for deployment to a mobile device comprises: receiving user input specifying the mobile device type of a desired vendor, emulating a graphical user interface of the mobile device, and receiving input selecting display items with one or more associated shadow data fields.

39. A system according to anyone of claims 22 to 38 further comprising at least one mobile device, the device comprising a second receiver adapted to receive configutation data transmitted via the first transmitter, wherein the mobile device is adapted to configure itself as a user interface to the at least one database using the received configuration data. A system according to claim 39 wherein the mobile device is adapted to receive further configuration data transmitted via the first transmitter and re-configure itself as a COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-OCT-2006 17:39 A J PARK 64 9 3566990 P.15/30 -42- O 0 o re-configured user interface to the at least one database using the additional configuration data. O 0 CM 41. A system according to claim 40 wherein the mobile device further comprises a second transmitter, wherein the device is adapted to transmit data to the intermediary store via the first receiver, the data being form updating the data fields of the at least one Ce 00 database that are associated with the specified shadow data fields. 0 00 C 42. A system according to claim 41 wherein the mobile device is adapted to periodically o 10 communicate with the intermediary store to receive configuration data, and periodically re- 0 configure itself as a user interface to the at least one database using the configuration data.

43. A mobile device comprising a transceiver and configuration software, the mobile device adapted to receive the configuration data of any one of claims 22 to 42, and adapted to configure itself with the configuration software using the configuration data to provide a user interface to the at least one database.

44. In another aspect the present invention may be said to consist in a method for facilitating configuration of a mobile device and integration of the mobile device with a remote computer system including at least one database, to provide for data synchronisation between the mobile device and the remote computer system, the method including: configuring a mobile device functionality and/or user interface, including selecting menu elements for display, methods for the elements and one or more shadow data fields related to the elements and associated with data fields in the database, using software that configures a system to facilitate data synchronisation between the mobile device and database. A computer program for operating a computer connected to at least one database to facilitate configuration of a mobile device to provide a mobile interface to the at least one database on a remote computer system, the computer program comprising: a index module adapted to enable the definition of an index of one or more shadow data fields for use in configuring the mobile device, each shadow data field being COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-OCT-206 17:39 A J PRRK 64 9 3566990 P.16/30 -43- \0 0 O associated with one or more data fields in the at least one database, each data field in the at Sleast one database containing one or more data entries, and 0 a user configuration module adapted to enable configuration of the functionality of C the mobile device, the user configuration module enabling a user to select one or more of the shadow data fields, wherein the user configuration module generates configuration data for configuration of a. mobile device to display, store and/or receive data entries in relation 00 to the selected shadow fields and for data synchronisation of: 00 data entries in the selected shadow fields displayed, stored or received on the N C mobile device, and Va o 10 data entries in the one or more associated data fields in the database.

46. A computer program according to claim 45 wherein the configuration data is adapted to be received by the mobile device during a communication session, and adapted to be utilised by the mobile device to configure itself as defined by the configuration data.

47. A computer program according to claim 45 or 46 wherein the configuration data further defines tasks and/or questions for display and/or storage on the mobile device, and wherein the configuration data is adapted to be received and utilised by a mobile device to configure itself to receive, display and/or store tasks and/or questions defined by the configuration data receive data entries in respect of those tasks and/or questions.

48. A computer program according to claim 47 wherein the tasks and/or questions are associated with one or more of the shadow data fields.

49. A computer program according to any one of claims 45 to 48 wherein the configuration data is adapted to be stored in a configuration data store that is in communication with a data store in the mobile device. A computer program according to any one of claims 45 to 49 wherein the user configuration module is further adapted to receive user input specifying display items for association with one or more of the selected shadow data fields, the user configuration module adapted to generate configuration data defining the display items and the respective associations of those display items with one or mote of the selected shadow data fields, the COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 13-0CT-2006 17:42 A J PARK 64 9 3566990 P.29/30 -44 oconfiguration data being adapted to be rtceived and utilised by a mobile device to configure itself to display the specified display items.

51. A computer program according to claim 50 wherein the display comprise one or more of menu options, icons, requests for information, data input fields. M 52. A computer program according to one of claims 50 or 51 wherein the 00 o configuration data is adapted to be received and utilised by a mobile device to configure 00 C'l itself to receive data in relation to one or more of the display items and store received data N 10 in one or more shadow fields associated with a respective display item for which data is oreceived.

53. A computer program according to anyone of claims 45 to 52 that facilitates configumation of a plurality of mobile devices.

54. A computer program according to claim 53 wherein the computer program facilitates configuration of a plurality of different mobile device types supplied by different vendors.

55. A computer program according to claim 54 wherein the user configuration module is adapted to: receive user input specifying the mobile device type of the desired vendor, emulate a graphical user interface of the mobile device, and display user specified display items and/or the data entries for the selected shadow fields associated with those specified display items.

56- A computer program according to anyone of claims 45 to 55 wherein the user configuration module simulates data synchronisation between data entries display, stored and/or received in respect of the selected shadow fields and data entries in the associated data fields in the database.

57. A computer program according to anyone of claims 45 to 56 wherein the configuration data is adapted to be stored in an intertnediary store prior to data transfer to a mobile device. COMS ID No: SBMI-05042672 Received by IP Australia: Time 14:44 Date 2006-10-13 16-OCT-2006 12:44 A J PARK 64 9 3566990 P.02 45

58. A computer program according to anyone of claims 45 to 57 further comprising a run-time scheduling module for editing display items, requests, tasks and information, the run-time scheduling module adapted to receive user input specifying changes to display items, requests, task and information and generates update configuration data defining the changes, the update configuration data being adapted to received and utilised by a mobile device to configure itself as defined by the configuration data.

59. A method as hereinbefore described with reference to the accompanying drawings.

60. A system as hereinbefore described with reference to the accompanying drawings.

61. A computer program as hereinbefore described with reference to the accompanying drawings. TOTAL P.02 COMS ID No: SBMI-05049869 Received by IP Australia: Time 09:46 Date 2006-10-16