`(19) United States
`(12) Patent Application Publication (io> Pub. No.: US 2002/0124065 Al
`Sep. 5,2002
`(43) Pub. Date:
`Barritt et al.
`
`(54) MOBILE COMPUTING SYSTEM
`ARCHITECTURE
`
`(76) Inventors: Michael Ewart Barritt, Cornwall
`(GB); Vincent Gregori, Cornwall (GB);
`Judy Clark, Cornwall (GB); Steven
`Barritt, Cornwall (GB); John William
`Glazebrook, Cornwall (GB)
`
`Correspondence Address:
`WORKMAN NYDEGGER & SEELEY
`1000 EAGLE GATE TOWER
`60 EAST SOUTH TEMPLE
`SALT LAKE CITY, UT 84111 (US)
`
`(21) Appl. No.:
`
`10/069,259
`
`(22) PCT Filed:
`
`Aug. 6, 2001
`
`(86) PCT No.:
`
`PCT/GB01/03527
`
`(30)
`
`Foreign Application Priority Data
`
`Aug. 5, 2000 (GB)...................................... 0019190.8
`Dec. 7, 2000 (GB)...................................... 0029937.0
`
`Publication Classification
`
`(51) Int. Cl.7 ....................... G06F 15/177; G06F 15/16
`(52) U.S. Cl............................................. 709/221; 709/203
`
`(57)
`
`ABSTRACT
`
`A system for operating plurality of diverse mobile comput
`ing devices 200 used by mobile users is described. A
`subscriber database 150 is provided comprising information
`about the hardware and/or software capabilities of the
`mobile units. An application server 100 accesses the sub
`scriber database 150, allowing preparation of an application
`script from script segments according to the hardware and/or
`software capabilities of the unit.
`
`A master application 715 in markup language may be used
`for the preparation of the application script. Applications
`and data in the form of script can then be downloaded to
`each mobile computing device and can continue to function
`offline with periodic synchronization of data and application
`with information held in an information server database 460.
`
`460
`
`Netflix v. VideoLabs
`IPR2023-00628
`Netflix. Ex. 1015
`
`
`
`Patent Application Publication Sep. 5,2002 Sheet 1 of 3
`
`US 2002/0124065 Al
`
`MAML
`
`Figure 1
`
`
`
`Patent Application Publication Sep. 5,2002 Sheet 2 of 3
`
`US 2002/0124065 Al
`
`Figure 2
`
`
`
`Patent Application Publication Sep. 5,2002 Sheet 3 of 3
`
`US 2002/0124065 Al
`
`Figure 3
`
`
`
`US 2002/0124065 Al
`
`1
`
`Sep. 5, 2002
`
`MOBILE COMPUTING SYSTEM ARCHITECTURE
`[0001] The present invention relates to the field of mobile
`computing solutions. A particular embodiment relates to a
`fully customisable system and software means for coordi
`nating, organising and fulfilling the computing needs of
`mobile workers.
`[0002] At the present time, many industries provide
`mobile workers with mobile computing and communication
`devices which are used to provide the mobile worker with
`information they need to carry out their job, and also to store
`information reporting the tasks they have carried out.
`Example mobile workers are meter readers, goods delivery
`workers, travelling salesmen etc. Examples of the type of
`information would be a list of things to do during the day,
`customer addresses etc and then confirmation and verifica
`tion information that tasks had been carried out, time stamps
`for particular events, new client information, notes etc.
`[0003] For example, a postal delivery worker might, on a
`daily basis, download a list of parcels to deliver, where and
`when they have to be delivered and may, in the course of
`deliveries, scan parcel bar codes or make records to show
`that deliveries have been completed at particular times.
`Typically, these systems require considerable hardware spe
`cific programming and implementation. Such systems need
`customised depending on the nature of the hardware devices
`carried by mobile workers, the servers organising the system
`and the networking hardware (e.g. ethernet, telephone net
`work) use for interfacing with mobile units at the beginning
`and end of the day. As well as the time and expense involved
`in customisation this means that individual organisations
`have separate and non-compatible mobile computing solu
`tions.
`[0004] Recently, internet-based application servers have
`become a popular method of delivering computing solutions
`to multiple users. It would be desirable to provide an
`application server adapted for the needs of companies with
`mobile workers. However, given the use by different firms of
`different hardware and software programs it is hard to see
`how this could be achieved and so an aim of the present
`invention is to provide application server technology for use
`in delivering mobile computing solutions to multiple users,
`being fully internet enabled, customisable and requiring
`minimal or no configuration by mobile workers.
`[0005] One aim of the present invention is to provide a
`system which can be operated using any type of commer
`cially available mobile computing hardware without cust
`omisation. In the present system the only action typically
`required by a user to configure a mobile unit for use with the
`system is to input one internet address once.
`[0006] A further aim of the present invention is to provide
`a means for enabling the system to function when individual
`mobile communication and computing devices are periodi
`cally on and off-line. In one extreme at the present time,
`mobile computing device have information downloaded into
`them once per day (e.g. a list of tasks) and uploaded to a
`central server at the end of the day. In another extreme it is
`known to provide a web server application which can be
`accessed online; however, this type of system cannot func
`tion when offline and, as it is prohibitively expensive to
`remain permanently connected, is not financially viable.
`[0007] Therefore, another aim of the present invention is
`to enable mobile workers to benefit from the communica
`
`tions possibilities of mobile network communications with a
`base system, whilst continuing to be able to function seam
`lessly when said mobile communications networks are
`unavailable.
`[0008] A further aim is to gain the benefits of dynamic
`communication with a remote server without the high costs
`of, for example, an always on internet connection.
`[0009] A further aim of the present invention is to provide
`a worker with access to the task and data information servers
`belonging to a plurality of third party organisations which
`have different hardware and software systems.
`[0010] A yet further aim is to implement the above aims
`whilst requiring the mobile units to have only standard
`browser and communications software and hardware.
`[0011] According to a first aspect of the present invention
`there is provided a system comprising:
`[0012] a plurality of mobile units for use by mobile
`users;
`[0013] an application server;
`[0014] communications means for enabling said
`mobile units to communicate with the application
`server;
`[0015] a subscriber database comprising information
`about the software and/or hardware capabilities of
`individual mobile units;
`[0016] a script database comprising equivalent script
`segments for carrying out particular functions on
`mobile units with different software and/or hardware
`capabilities; wherein
`[0017] the application server is adapted to provide
`an application script to a mobile unit, said appli
`cation script being prepared from script segments
`selected from the script database according to the
`information about the mobile unit stored in the
`subscriber database.
`[0018] Preferably, the system further comprises a master
`database, said master database having mobile user specific
`data, said application script further comprising mobile user
`specific data specific to the mobile user acquired from the
`master database.
`[0019] Preferably, a mobile unit stores a copy of said
`mobile user specific data.
`[0020] More preferably, a mobile unit edits the copy of
`said mobile user specific data.
`[0021] Preferably also, the copy of said mobile user spe
`cific data is synchronised with the mobile user specific data
`stored in the master database.
`[0022] Most preferably, the application script is synchro
`nised concomitantly with synchronisation of the mobile user
`specific data.
`[0023] Typically, the mobile user specific data relates to
`tasks carried out by said mobile user.
`[0024] Preferably mobile user specific data relates to tasks
`which have been or are being carried out by said mobile user.
`
`
`
`US 2002/0124065 Al
`
`2
`
`Sep. 5, 2002
`
`[0025] Preferably, the system further comprises master
`application program code means which are interpreted by
`the application server to prepare the application script.
`[0026] Most preferably, the master application program
`code means is stored in markup language.
`[0027] Said mobile units may communicate with the appli
`cation server over the internet.
`[0028] Said mobile units may comprise a browser, said
`browser executing the application script.
`[0029] According to a second aspect of the present inven
`tion there is provided a method comprising the steps of:
`[0030] acquiring information about the software and/or
`hardware capabilities of a mobile unit from a subscriber
`database, the mobile unit being for use by a mobile
`user; and
`[0031] preparing an application script customised for
`the mobile unit from script segments being selected
`from a script segment database according to the soft
`ware and/or hardware capabilities of the mobile unit.
`[0032] Preferably, said application script further com
`prises data specific to a mobile user acquired from a master
`database of mobile user specific data.
`[0033] Preferably also, a mobile unit stores a copy of said
`data specific to a mobile user.
`[0034] Preferably, the copy of the data specific to a mobile
`user is edited by the mobile user.
`[0035] More preferably, the method further comprises the
`step of synchronising the copy of the data specific to a
`mobile user with the data specific to a mobile user stored in
`the master database.
`[0036] Preferably, said data specific to a mobile user
`comprises information concerning tasks to be performed by
`or which have been performed by said mobile user.
`[0037] Preferably, said application script is prepared with
`reference to a master application.
`[0038] Typically, said master application is stored in the
`form of a markup language.
`[0039] A mobile unit may comprise a browser and the
`application script be executed by said browser.
`[0040] According to a third aspect of the present invention
`there is provided a computer program comprising program
`instructions which, when loaded into a computer, comprise
`the application server of the system of the first aspect.
`[0041] According to a fourth aspect of the present inven
`tion there is provided a computer program comprising
`program instructions for causing a computer to perform the
`process of any of the second aspect.
`[0042] According to a fifth aspect of the present invention
`there is provided a computer program comprising the appli
`cation script of any of the second aspect.
`[0043] The present invention will now be illustrated with
`reference to the following figures in which:
`[0044] FIG. 1 shows a schematic diagram of overall
`system architecture;
`
`[0045] FIG. 2 shows a flow chart of a typical days
`operations by a mobile worker;
`[0046] FIG. 3 shows a block diagram of components of a
`mobile device according to the present invention.
`[0047] System Overview
`[0048] FIG. 1 illustrates in block format the individual
`components of the system and the connectivity between
`them. The system comprises a web application server 100,
`and a plurality of mobile computing devices capable of
`executing scripts shown by way of example as 201-204 and
`referred to generally as 200. Typically, there are further
`provided one or more information servers shown by way of
`example as 451-453 and referred to generally as 450.
`[0049] The invention comprises program code, usually
`localised on the web application server, to enable different
`mobile units to function with the web application server. The
`invention also comprises one or more applications in a
`mark-up language, referred to below as mobile application
`mark-up language (MAML), and the overall methodology
`and hardware of the system as a whole. MAML Applications
`dictate mobile device functionality and, in two different
`embodiments are either (a) interpreted into a script language
`appropriate to an individual mobile unit with reference to a
`database 150 of subscriber mobile unit information or (b)
`transmitted in MAML to the mobile computing devices
`which have thereon MAML interpreters.
`[0050] The invention also comprises a further protocol
`using markup language, here termed Application Extensible
`Mobile Language (AXML) used for exchange of informa
`tion between the web application server and information
`servers.
`[0051] The mobile devices 200 for use with the system can
`be of a variety of different types. The requirements of each
`are that it can communicate with the web application server,
`downloading and executing scripts and having the capacity
`to upload data.
`[0052] Mobile Device Hardware/Software
`[0053] Example mobile devices 200 would be a Windows
`CE™ mobile device 201 with JavaScript™ enabled browser
`211, a WAP mobile device 202 with WMLScript™212
`connected through a WAP server 222, a KVM™ mobile
`device 203 or Java™ virtual machine. Future technologies
`such as iMode™ and other formats could clearly also be
`used. In another embodiment an uninterpreted Application
`in the proprietary format herein referred to as MAML,
`discussed below can be interpreted by a MAML enabled
`mobile device 204. Essentially, each mobile device 200
`requires the capacity to exchange information with the web
`application server 100, execute a script and input/output date
`through a user interface.
`[0054] Browsers may be supplemented by ActiveX™
`components or Java™ Applets on the device to communi
`cate with device specific interfaces 220 for driving periph
`erals 221, for example, software and hardware interfaces for
`signature capture systems, scanners, printers, the global
`positioning system, mobile telephone locating systems etc.
`This means that the mobile device can be used more or less
`out of the box with no specific applications or data required.
`[0055] Mobile devices may for example be in the form of
`mobile telephones, palmtop organisers, laptop computers,
`
`
`
`US 2002/0124065 Al
`
`3
`
`Sep. 5, 2002
`
`computers integrated into vehicles etc. Users of mobile
`devices will typically be travelling workers such as sales
`men, meter readers, delivery workers, van drivers, factory
`workers or robots.
`[0056] In the example embodiment, mobile devices 200
`communicate with the central web application server 100 via
`a network server 125, typically an HTTP server, using
`TCP/IP. Communication between server 125 and mobile
`units 200 is through a communications network 300. The
`communications network 300 could be a fixed PSTN line,
`LAN or WAN into which mobile units 200 can be connected
`from time to time, but will preferably be a mobile commu
`nications network such as GSM, GPRS or future mobile
`telephone systems. The mobile device could also be con
`nected to either an Intranet or an Internet via a standard RAS
`connection using a direct network connection. Information
`is exchanged between the network server 125 and mobile
`units 200 using known hardware independent exchange
`protocols such as TCP/IP. Use of a standard protocol such as
`TCP/IP allows different physical communications 300 to be
`readily used with different mobile devices 200. Different
`types of physical communications network can be integrated
`as alternatives or consecutively as a data transmission path
`way.
`[0057] Application Server Hardware/Software
`[0058] The web application server can be implemented in
`an industry standard development environment and appli
`cation server for example COLDFUSION™ Usefully
`COLDFUSION™ can be run on any platform such as
`Windows NT™, SOLARIS™, LINUX™. The HTTP serv
`ers can be implemented using, for example, APACHE™, or
`other similar servers.
`[0059] The web application server 100 has access to a
`subscriber database 150 which comprises information about
`the hardware and software capabilities, configuration and
`user data relating to individual subscriber mobile devices
`showing generally as 200. The subscriber database is
`describe further below. Typically, the subscriber database is
`directly connected to the web application server 100; alter
`natively, information can be stored on information servers or
`MAML enabled mobile devices 204.
`[0060] Information Server Hardware/Software
`[0061] Information server systems comprise typically, an
`HTTP server 400, an information server. Native or ODBC
`drivers 470 may be used to interface between an server 451
`and associated database 460. Said databases and drivers are
`readily implemented using common software tools available
`from, for example, Sybase™, Oracle™, DB2™, SQL
`server™ etc. Commonly available information servers
`include those sold by VANMAN™, OPTRAC™ and Sys
`tems Union™.
`[0062] Typically, the central web application server 100 is
`connected through the internet to one or more information
`server systems shown by way of example as 451, 452 and
`453 and referred to generally as 450. The information
`servers 450 may belong to the same organisation that owns
`the web application server 100 or may belong to third party
`organisations. Importantly, each of these information server
`systems may be entirely different in internal composition
`and configuration. The only requirement is that they can
`communicate with the central web application server in a
`
`specified interface format discussed below. The information
`servers function to provide information required by users of
`mobile units and to store information returned by them. For
`example, an information server may comprise information
`about a list of tasks to be performed on a particular day by
`a particular mobile user, belonging to a particular organisa
`tion which has subscribed to the facility provided by the web
`application server 100.
`[0063] Use of System by End User
`[0064] FIG. 2 shows a flow chart of an example day’s use
`of a mobile communications device and of the systems
`owned by an individual travelling worker. An important is
`that the system as a whole can work with different mobile
`units without them requiring extensive personalisation. The
`aspect of the system which makes this possible is the ability
`of the web application server to store in the subscriber
`information database information about the individual
`mobile unit and the use of MAML/AXML described below
`to customise the script sent to the individual mobile unit.
`[0065] To begin with 601, the mobile communications
`device connects across a network such as an Intranet or the
`Internet as discussed above to the central web application
`server 100. After connecting 602, the device logs in 603 to
`an information server 450 or central web application server
`100, for example, using TCP/IR The mobile unit might log
`into a start page defined by a universal resource locator, for
`example it might connect to a web page belonging to a
`proprietor/user of an information server 450, preferably this
`will be the internet address of the web application server
`100.
`[0066] The mobile unit may be pre-set up for a particular
`user with password etc information. Alternatively, the web
`application server may use caller line identification, cookies
`or other identification techniques to establish the user. The
`user is then either recognised or rejected 604. Upon log-in
`the system identifies the user 605 and their device as this is
`part of the user set-up. The subscriber database 150 may
`contain further information relating to the particular user of
`the mobile device, such as the type of device they are using,
`their location, the nature of their business, the type of third
`party application servers 450 to which they should be
`allowed access etc. A document is then downloaded 606
`from the central web application server and third party
`application servers 415. The particular information down
`loaded is based on information held in the central subscriber
`database 150 and task information stored in third parties
`databases and servers 450460.
`[0067] These can be managed directly from the depot
`which controls individual projects. For example, it will
`prescribe a particular series of tasks such as locations we
`visited, parcels to be dropped off which has been decided by
`the depot. The information is downloaded in the form of a
`script comprising both an application and associated data.
`The script is customised for the particular mobile unit and
`mobile worker, the application being adapted to function on
`their particular mobile unit and the data being customised to
`a particular list of tasks. This customisation is described
`further below.
`[0068] At some point after recognition 605 and typically
`after download or concurrently with download 606, the
`mobile unit 200 will in some embodiments be locked 607 to
`
`
`
`US 2002/0124065 Al
`
`4
`
`Sep. 5, 2002
`
`prevent access to other functionality. This enables the com
`plete functionality of the hand-held unit to be prescribed,
`although, for example, a restricted option password may be
`provided to allow a return to full operating system function
`ality. The access to other mobile device functionality whilst
`the programme is running may be varied depending on
`information held on the subscriber database 150 about the
`nature of the user and their level of technical sophistication.
`Locking is not essential but will be preferred for some users.
`
`[0069] Next, the user will perform their day’s work 608.
`For example, they will be able to print information such as
`receipts, print-outs of job tasks etc., look at lists of tasks and
`associated information. They will be able to read bar code
`information, read/write to intelligent tags etc. They may be
`able to capture signatures and other identifying material and
`transmit these back to base. Abenefit of the invention is that
`instead of them having to perform this upload only at the end
`of the day or only on-line every time they carry out a
`transaction, data and application synchronisation can be
`performed at intervals. Furthermore, they will be able to
`read credit cards/smart card information, handle complex
`transaction information such as calculating pricing costs etc
`offline and will be able to communicate with other devices
`such as vehicle black boxes, GPS etc 218. Importantly,
`interface design will be simple and easy to use.
`[0070] At any point during the day the user will be able to
`synchronise 609/transmit/download information from the
`Web application server 100 and information servers. For
`example, they would be able to transmit information of work
`that has been completed such as parcels picked up or
`delivered, and pick up information about new work. As well
`as just exchanging and synchronising data, the system is also
`capable of exchanging and synchronising the actual appli
`cation software running on the mobile unit. Therefore they
`can readily download updates to software. This feature
`might be particularly important when they wish to deal with
`several different third party information services 451, 452
`and 453 for which different software will be required.
`[0071] The term “synchronise” refers to the known pro
`cess of making two different data sets, such as lists of tasks,
`correspond in meaning. Typically, the list of tasks in the
`mobile unit is synchronised with the list of tasks stored in an
`information server 450 or associated database 460. For
`example, when the mobile unit has updated a record relating
`to a particular task, the synchronisation process would
`involve updating the record in the database 460 with that
`updated record. Rules can readily be written by one skilled
`in the art to deal with situations when both records may have
`changed. Application synchronisation involves ensuring that
`the application within the mobile unit is the version consid
`ered most appropriate by the web application server 100.
`[0072] At the end of the day the user can then reconnect
`to the central web application server 100 and upload data
`610 concerning their tasks carried out during the day. At that
`point the day’s tasks end 611 and information to do with one
`journey is finished and another journey can be begun imme
`diately or at a later date. Although one day has been referred
`to as the duration of an individual journey in this application,
`it will be clear to one skilled in the art that this could be any
`period, for example, a few hours or a few days or weeks or
`even indefinitely.
`
`[0073] The above operation routine is common to all
`potential use of the system, for example van sales, parcel
`delivery, fuel service etc.
`[0074] Data Formats
`[0075] A variety of different information exchange for
`mats are used between different components of the system
`and several of these are new and important to the function
`ality of the invention. Importantly, application and data
`information delivered to individual mobile units is in the
`form of script in standard mark-up language. Whereas the
`information delivered and the way in which it operates is
`new, the underlying software, being delivery of web docu
`ments through standard HTTP servers, is standard allowing
`integration with common known software and hardware
`implementations. HTTP is used as common protocol for
`communications and also allows the central web application
`server 100 to exchange information with other HTTP servers
`400, database sources and other devices such as mobile
`telephones etc.
`[0076] As discussed above, each mobile device 200 has
`the capacity to execute a script and input/output data with a
`user.
`[0077] The central web application server 100 accepts,
`validates, authenticates and processes requests from the
`mobile units 200. Importantly, the central web application
`servers provides a subscriber database 150 to use in this
`process. This database contains information on the types of
`browsers, other software components, subscribers applica
`tions and any spoken language translations provided on
`individual mobile units. The information for the subscriber
`database can be imported from the information servers 450
`or the information servers associated databases 460, or may
`be maintained standalone and connected directly to the web
`application server as shown in FIG. 1. Alternatively, the
`subscriber database can be held in a plurality of locations.
`[0078] Once requests for information are received from
`the mobile unit and validated, script is then delivered by the
`central web application server 100 to the mobile unit 200.
`Importantly, the central web application server 100 obtains
`data and application information relevant to the user of the
`individual handheld unit 200, for example task lists, from
`the relevant HTTP information server 400 in the form of a
`specialised version of XML, referred to herein as application
`extensible mark-up language, AXML.
`[0079] This data is then combined with application related
`information which is assembled in the form of mobile
`application mark-up language, MAML which is a format we
`have designed to enable the HTML/JavaScript capabilities
`and mobile browsers (or in the case of WAP browsers,
`WML/WMLScript) to function with this system. MAML
`also allows the delivered application to continue running and
`being used without the browser being connected to the
`server. It also provides specific functions required on the
`individual mobile device 200 to make that application easy
`and fast to use.
`[0080] Data Flow, MAML Interpretation
`[0081] FIG. 3 shows an example of the flow of data
`through the system. In this example, a mobile unit 200 sends
`an HTTP request to the web application server 100. In
`response to this the web application server 100 makes a
`
`
`
`US 2002/0124065 Al
`
`5
`
`Sep. 5, 2002
`
`further HTTP request to an information server 450 in AXML
`for task data relating to the particular user of the mobile unit.
`[0082] Task related data 701 is stored within a database
`750 and in an example format contains header information
`704 relating to a particular individual 703 and a particular
`day 702. The database 750 can be stored on or associated
`with an information server or in any other location directly
`or indirectly accessible by the web application server 100. A
`list of tasks 705, 706 etc is also stored in an appropriate data
`format as will be clear to one skilled in the art. Example
`tasks might involve a particular action (deliver a parcel/meet
`a client/read a meter), identifier information (location for a
`delivery, identifier for a parcel, miscellaneous information
`data), time and location information.
`[0083] Task data can be submitted to the system in numer
`ous ways. For example, it could be held on task information
`databases associated with third party information servers
`450 to enable easy interface with in-house systems. Alter
`natively, it could be submitted over the internet directly to a
`task information database associated with the web applica
`tion server 100. For example, a worker at a factory requiring
`delivery of a product might use conventional web technol
`ogy to submit a request to a web site associated with the
`tasks information databases for said particular product to be
`delivered. Information might also be supplied by mobile
`users, during the process of application and data synchro
`nisation or as separate requests.
`[0084] In response to the request from the web application
`server 200, the task data record 701 is then processed by the
`information server 450 and transmitted to the central web
`application server 100 in the form of an AXML document
`710.
`[0085] An Application 715 for interpretation and delivery
`to the mobile unit 200 is stored in MAML format, typically
`on the web server 100 although it can be supplied by
`information servers 450 or other sources. In order to prepare
`a script 740 to transmit to the mobile unit, the AXML
`document 710 and MAML Application 715 are required,
`along with two different further classes of data records: a
`subscriber database 720 and script database 730 are usually
`held within the subscriber database 150. The subscriber
`database 720 contains information concerning the particular
`user of a mobile unit 200 and the configuration and capa
`bilities of that unit and peripherals associated therewith. The
`script database 730 contains hardware and software specific
`segments of script. Preferably, subscriber database and script
`database are both in the form of lists.
`[0086] MAML is interpreted by the web application server
`100 by sequentially selecting script segments from script
`database 730 as appropriate depending on the user informa
`tion stored in the subscriber database 720. For example, the
`script segment data records will contain script for common
`functions e.g. displaying buttons, formatting frames, dis
`playing text etc. in several different formats such as WML
`Script, JavaScript etc. and the appropriate script segment is
`selected depending on the type and capabilities of the
`machine as stored in the user information records 120.
`[0087] Therefore a script 740 comprising an interpreted
`application is produced and combined with the data received
`in AXML format. This is then delivered to the mobile unit
`200 where it is executed. As part of the execution process,
`
`the copy of the data on the mobile unit 200 can be viewed,
`amended, edited, deleted or added to. Importantly, this can
`be carried out whilst the mobile unit 200 is offline.
`[0088] Whilst it runs offline the data contained within the
`script can be altered and records containing additional
`information, such as signatures, notes and timestamps relat
`ing to deliveries and events can be stored within for trans
`mission back to the mobile web application server 100 the
`next time the mobile unit communicates with the web
`application server 100.
`[0089] Periodically the mobile unit 200 can request syn
`chronisation and the task data is synchronised with that
`stored in the task database 460, being reconverted into
`AXML for transmission to information servers 450.
`[0090] As a result of this process, information for trans
`mission to/from diverse information servers 450, can be
`integrated into a standardised form and exchanged with
`diverse mobile units 200. This allows the owners of the
`information servers 450 to concentrate on provision of the
`data being exchanged whereas the owners of the central web
`application server 100 can concentrate on the front end, user
`interface and, importantly, adaptation for different software
`a