WO2000054525A1 - Mobile application service - Google Patents

Mobile application service Download PDF

Info

Publication number
WO2000054525A1
WO2000054525A1 PCT/AU2000/000174 AU0000174W WO0054525A1 WO 2000054525 A1 WO2000054525 A1 WO 2000054525A1 AU 0000174 W AU0000174 W AU 0000174W WO 0054525 A1 WO0054525 A1 WO 0054525A1
Authority
WO
WIPO (PCT)
Prior art keywords
objects
client
server
frame
runtime environment
Prior art date
Application number
PCT/AU2000/000174
Other languages
French (fr)
Inventor
Mary Brittain-White
Peter Koch
Original Assignee
Retriever Communications
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Retriever Communications filed Critical Retriever Communications
Priority to AU28974/00A priority Critical patent/AU2897400A/en
Publication of WO2000054525A1 publication Critical patent/WO2000054525A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/18Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Definitions

  • This invention concerns a mobile application service.
  • the invention concerns the server and remote client, and their methods of operation, in a system for providing a mobile application as a service, to users.
  • the invention is a centralised server, or software to program a centralised server, for a mobile application service system, where the server is programmed to create and maintain separate databases for respective mobile clients to hold client knowledge in the form of: free form database objects, known as frame objects, which hold client data in data fields and are replicated in client computers; and component based application modules, known as agent objects, which the server despatches to respective clients, as required, to create or manipulate information in the frame objects: and where the server is programmed such that, after a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed: and synchronisation of the server and the mobile client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity, then transmission of the determined delta frame objects achieves conformity.
  • free form database objects known as frame objects, which hold client data in data fields and are replicated in client computers
  • component based application modules known
  • the invention is a method of providing a mobile application service system, comprising the steps of: creating and maintaining at a server, separate databases for respective remote clients to hold client knowledge in the form of: free form database objects, known as frame objects, which hold client data in data fields and are replicated in client computers; and component based application modules, known as agent objects, which the server despatches to respective clients, as required, to create or manipulate information in the frame objects: and where, after a frame object has been changed, creating a new edition of the frame object, known as a delta frame object, which contains only the data fields that have been changed: and synchronising the server and the client by exchanging edition information between them, determining from the exchange which delta frame objects need to be aggregated, aggregating those delta frame objects, and transmitting the aggregated delta frame objects in order to bring them into conformity.
  • the invention is a client runtime environment, or software to program a runtime environment, where the runtime environment is programmed to hold: free form database objects, known as frame objects, which hold client data in data fields and are replicated in a remote server, and component based application modules, known as agent objects, received from the server despatches, as required, to create or manipulate information in the frame objects; and where the runtime environment is programmed such that, after a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed: and synchronisation of the client with the server or another client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity, then transmission of the determined delta frame objects achieves conformity.
  • free form database objects known as frame objects, which hold client data in data fields and are replicated in a remote server
  • component based application modules known as agent objects
  • the invention is a method of providing a runtime environment, comprising the steps of: programming the runtime environment to hold: free form database objects, known as frame objects, which hold client data in data fields and are replicated in a remote server, and component based application modules, known as agent objects, received from the server despatches, as required, to create or manipulate information in the frame objects; and where, after a frame object has been changed, creating a new edition of the frame object, known as a delta frame object, which contains only the data fields that have been changed: and synchronising the client with the server or another client by exchanging edition information between them, determining from the exchange which delta frame objects need to be aggregated, aggregating those delta frame objects, and transmitting the aggregated delta frame objects in order to bring them into conformity.
  • the server and client databases cooperate in the process of synchronisation to maintain editions of frame objects stored at the server and client databases.
  • An edition represents a complete frame object when taken in isolation.
  • An edition, when taken relative to a predecessor edition represents only the changes ("delta elements") to that predecessor edition.
  • the edition history may be arbitrarily long (i.e. the number of editions kept) although for data storage conservation reasons edition history may be trimmed without loss of integrity of the whole frame object. The tradeoff in this case will be that the whole frame object would need to be sent in any request for an edition which has been trimmed since the change information required to enable extraction of the delta elements will have been removed.
  • Objects are held at the server and client in persistent storage.
  • Frame objects can have data fields ("slots") arbitrarily added, changed or deleted.
  • Conventional compression schemes may also be employed to further improve the efficiency of data transfer.
  • the computer supporting the server database and the computers supporting the client databases will be connected via communications networks which are either charged on a time connected basis, or. a quantity of data transferred basis. In either case it is to the commercial benefit of the user to minimise the data traffic such that telecommunications costs are reduced.
  • the system may be designed to offer reliable uninterrupted operations.
  • the design may be flexible and broad enough to meet both current and future subscriber requirements.
  • the system may also minimise telecommunications traffic costs and cater for the typical mobile user who is "occasionally" connected to the service.
  • the central server infrastructure may support multiple companies operating simultaneously and with concurrent end-user sessions. It may be able to be rapidly and easily customised to meet an individual subscriber company ' s needs. It may be capable of adding or changing customised applications on the service without compromising the operating stability and reliability for existing subscribers. It may also provide users with an environment closely representing their "legacy" paperwork processes.
  • the system may interface with existing host computing systems to extend the functionality of a company's IT as seamlessly as possible. It may also maximise operational cost efficiency by sharing central server infrastructure over the entire subscriber base.
  • the service may support clients operating in "occasionally connected" mode to provide continuous functionality for mobile users or fixed clients with restricted communications continuity. It may minimise data transfer between clients and the server by only transferring those elements of data structures that have changed at either end. It may support mechanisms to stringently validate the integrity of data transferred between the server and clients. It may be capable of being localised to enable deployment in different international territories
  • the architecture enables the implementation of a reliable multi- subscriber mobile application service.
  • An innovative use of object technology and an application abstraction layer enables the system to run generalised software at the server (hub) and yet be fully customable to the unique needs of different subscriber companies.
  • Figure 1 is a schematic diagram of the tiers of the architecture of the service example.
  • Figure 2 is a schematic diagram of the architecture of the central service system.
  • Figure 3 is a schematic diagram of the client architecture.
  • Figure 4 is a schematic diagram of the communications structure assumed for the service. Best Modes of the Invention
  • the system architecture 1 of the service system is implemented as a multi-tiered client-server computing model, as illustrated in Figure 1.
  • a client-server communications layer 4 supports network traffic authenticated access, utility services and programmable (custom) services.
  • the programming model (client-server-service) relies on the concept of software services running in conjunction with the server with which clients interact.
  • a system-wide object programming model 5 supporting platform independent objects, object manipulation primitives (methods) and mechanisms for remote method invocation between clients and the server.
  • An application "runtime" environment 6 provides support for advanced object operations such as persistence (caching), queries, transfer, synchronisation, etc.
  • Component-based application modules 7 are dispatched to execute in the client runtime environment 6.
  • the applications 7 are called agents.
  • Agents 7 are objects able to create or manipulate information, which will subsequently be exchanged with the server system 2. deposited in an object store 8. and routed to their next destination (client). To an end user, agents might appear as forms and list items that display on the client device screen.
  • SDK System Development Kit
  • a set of programming tools that enable the rapid development of agents and other data definitions used to define an application.
  • administrative tools used in the operation and maintenance of the overall system.
  • the lower layer consists of an object-oriented client-server system that provides data communications, authenticates connections, routes data traffic. logs events, and provides a variety of other utilities (e.g.. Internet mail and paging system interfaces).
  • object-oriented client-server system that provides data communications, authenticates connections, routes data traffic. logs events, and provides a variety of other utilities (e.g.. Internet mail and paging system interfaces).
  • the client-server system implements the object model and object primitives used extensively by the upper layers of the architecture.
  • the object model is built around clients interacting with services, which are exposed to them through the server.
  • Clients create remote objects of defined types in services and send method calls to those objects for the server to execute on their behalf.
  • the client side runtime layer 6 implements a set of interfaces and functionality required for the execution of application agents 7 at a client.
  • Agents 7 are stored centrally 8 on the server and dispatched to a client as required.
  • all the resources and data that it requires to operate exist in the client runtime environment 6. Any requests that the client runtime cannot fulfil directly for an agent will be dealt with by having the runtime 6 "contact" the server 2. This can happen invisibly or the agent 7 can be notified of a connection requirement.
  • the central server system 2 is the transportation and distribution centre for the entire system.
  • the hub 2 enables agents 7 to travel to clients 3 in order to carry out their intended tasks.
  • clients 3 declare their platform type to the hub 2 which, in turn, dispatches agents 7 that are compatible with that client's computer platform.
  • the hub 2 is solely responsible for transporting and storing objects; it remains independent of any particular subscriber application.
  • the hub 2 is designed to support multiple subscriber companies using the system simultaneously and multiple concurrent client sessions. The services at the hub are available to all users.
  • Figure 2 shows an overview of the hub architecture.
  • the hub 2 moves all application data to and from clients.
  • the hub is configured for a new subscriber company by allocating a database 10 to a subscriber company and then depositing agents 7 and their accompanying data into that databaselO.
  • the software "knowledge" for a particular subscriber company is held entirely by the company specific agents and their accompanying data and view definitions.
  • Administration and monitoring of the overall system is carried out by client computer(s) with "administrator" privileges. Administrator clients are independent of the application system and interact directly with the client- server and runtime systems.
  • Administrative clients are used to manage functions such as adding or removing subscriber end users, depositing new versions of agents onto the system for use in a particular subscriber application, viewing system logs to trace abnormal events or faults, etc.
  • Agents 7 characterise the behaviour of a client 3. Agents 7, in conjunction with the data store 10, are the primary means of customising the system. Agents 7 stored at the hub 2 may contain code for execution on a number of different client platforms. The hub 2 will choose the appropriate code version to dispatch in an agent to a client 3. It is able to do this because clients 3 declare their platform type to the hub when they connect in. Neither the server nor client runtime layers 6 have any specific knowledge of the tasks that an agent implements for a particular subscriber company. The runtime environment deals with objects only. Agents are uniquely programmed to implement the "business rules".
  • Agents are dispatched from the hub to clients automatically and are held in persistent storage in a client until replaced or purged. Therefore, the hub may respond to a client's request for an agent and attached data by sending the data only, since the agent may already reside in memory. Agents may co-exist in clients with more versions of themselves. This enables multiple versions of "agent data" to reside in the system and still be processed by the agent of the correct (or older) version if required. This feature is important where large amounts of historical data may be held on the system. Older versions of data may need to be handled by a matching version of an agent. In this case agents and agent data of older versions must be able to co-exist.
  • Agents "carry around" the data that they require by referencing data objects.
  • the actual task of transporting the data is a function of the object store and the routing and transfer services. Consequently, agents never need to concern themselves with how they or the data they require travels.
  • Client computers may interact with human operators using an agent that has a Graphical User Interface (GUI).
  • GUI Graphical User Interface
  • Client computers can also act as a gateway to other computers or IT systems simply by creating the appropriate agent interface.
  • Standard agents can be constructed for use via published programmatic interfaces as ODBC and those that are delivered with the Operating systems and database software. Other standard agent interfaces for integrating with customer information systems such as SAP can be readily constructed.
  • the system is designed to enable clients to operate in off-line (not connected) mode.
  • the runtime environment attempts to satisfy all agent requests without connecting.
  • the object store caching mechanism captures data current to the last connection between the hub and a client.
  • the off-line mode of operation is used heavily for mobile clients; however, the use of the "occasionally connected" mode of operation is not restricted to use by mobile devices.
  • this class of device is a potential candidate for a mobile client computer.
  • the screen area, memory and processing power of these devices is generally limited to the extent that they are not candidates for a standard client.
  • a single interface client could act as a proxy for multiple simple clients.
  • Simple clients would generally be restricted to receiving schedule (job) data, acknowledging receipt of schedule data, submitting time use information. Simple clients could also perform well in the receiving of management information from the system so that business performance information could be conveyed to field based management.
  • a View Definition is yet another object and defines how a particular GUI operates on a client device. This is important where the same agent may execute on a variety of devices with differing screen sizes and input systems (e.g. handheld vs desktop or keyboard vs pen). Therefore, view definitions provide convenient and consistent ways for agent data to be displayed and input on a system wide basis.
  • Data definitions are objects with a known internal structure which have the sole purpose of describing the format of other free form objects.
  • Data definitions (DataDefs) have version information contained in them (just like agents). Consequently, multiple versions of the same basic data definition may exist in the system concurrently without causing concern (as you might expect this is actually true of all objects used in the application system).
  • Data definitions may reference other data definitions. Arbitrarily complex data structures can be constructed and moved around the system through this linking and embedding mechanism.
  • the object stores (hub and client) hold all subscriber specific data in the system.
  • the hub object store is designed for fast operations on multi- object hierarchical structures.
  • the object store only moves those objects that do not currently exist at the destination site (client or server).
  • the object store further economises on data traffic by moving only those parts of objects that have changed. This process of partial data transfer is termed
  • Synchronisation plays an important role in minimising traffic to and from mobile clients where communications bandwidth is at a premium.
  • a new edition of the frame object which contains only the data fields that have been changed.
  • Synchronisation of the server and the client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity. Then the determined delta frame objects are transmitted to achieve conformity.
  • An object based query system is built into the object store in order to enable content based searching and extraction of objects.
  • the hub object store caches all client data that passes through it. Clients also cache data but restrict this to items that are of concern to them. Therefore, the hub has a snapshot of information from clients current to their last connection. The caching of data at the hub enables the recovery of a particular client's state should it lose its local copy of data.
  • SDK System Development Kit
  • the SDK generates agents, view definition and data definition objects. Agents, view definitions and data definitions created by the SDK are loaded into storage on the hub for distribution to client computers.
  • the SDK supports the creation of derivative applications from base (template) applications. This substantially speeds the implementation of applications for specific companies. Derivative applications can co-exist in the system without conflict since all objects are assigned unique IDs.
  • the basic System requires mobile communications to support roaming connections from handheld clients, landline communications to support connections from office based clients and landline communications to support administration clients.
  • GSM Global System for Mobile communications
  • GPRS General Packet Radio Services
  • Packet services enable a (virtual) continuous connection between the client and the hub with the subscriber being charged by data traffic rather than connection time.
  • the implementation of GPRS will improve the utility of the Service by enabling mobile clients to dramatically increase their communication "uptime" with the service. While ever a mobile user is in radio coverage GPRS will enable client to server communications to take place and a more continuous exchange of information between the mobile user and the hub.
  • Alternative mobile data networks such as CDPD are supported by the Retriever system.
  • CDPD is a packet based system supporting TCP/IP communications. It is enjoying increased coverage in the USA and offers similar features to GPRS but operates on an analogue system (operates over legacy -AMPS cellular networks).
  • Providing Internet based access is a logical extension of the system. By using web access customers could review the status of current activity or review historical information.
  • Web access would be provided through a secured web site in order to retain security over the information. Web access would be "view only”. Customers would require a username and password in order to access the secure web site.

Abstract

A first aspect is a centralised server, or software to program a centralised server, for a mobile application service system, where the server is programmed to create and maintain separate databases for respective mobile clients to hold client knowledge. A second aspect is a client runtime environment, or software to program a runtime environment. There are also methods for operation. They involve free form database objects, known as frame objects, which hold client data in data fields and are replicated in client computers. Component based application modules, known as agent objects, which the server despatches to respective clients, as required, to create or manipulate information in the frame objects. The server and runtime environment are programmed such that, after a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed. Synchronisation of the server and the mobile client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity. Then transmission of the determined delta frame objects achieves conformity.

Description

Title
MOBILE -APPLICATION SERVICE
Technical Field
This invention concerns a mobile application service. In particular the invention concerns the server and remote client, and their methods of operation, in a system for providing a mobile application as a service, to users.
Summary of the Invention
In a first aspect the invention is a centralised server, or software to program a centralised server, for a mobile application service system, where the server is programmed to create and maintain separate databases for respective mobile clients to hold client knowledge in the form of: free form database objects, known as frame objects, which hold client data in data fields and are replicated in client computers; and component based application modules, known as agent objects, which the server despatches to respective clients, as required, to create or manipulate information in the frame objects: and where the server is programmed such that, after a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed: and synchronisation of the server and the mobile client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity, then transmission of the determined delta frame objects achieves conformity.
In a second aspect the invention is a method of providing a mobile application service system, comprising the steps of: creating and maintaining at a server, separate databases for respective remote clients to hold client knowledge in the form of: free form database objects, known as frame objects, which hold client data in data fields and are replicated in client computers; and component based application modules, known as agent objects, which the server despatches to respective clients, as required, to create or manipulate information in the frame objects: and where, after a frame object has been changed, creating a new edition of the frame object, known as a delta frame object, which contains only the data fields that have been changed: and synchronising the server and the client by exchanging edition information between them, determining from the exchange which delta frame objects need to be aggregated, aggregating those delta frame objects, and transmitting the aggregated delta frame objects in order to bring them into conformity.
In a third aspect the invention is a client runtime environment, or software to program a runtime environment, where the runtime environment is programmed to hold: free form database objects, known as frame objects, which hold client data in data fields and are replicated in a remote server, and component based application modules, known as agent objects, received from the server despatches, as required, to create or manipulate information in the frame objects; and where the runtime environment is programmed such that, after a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed: and synchronisation of the client with the server or another client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity, then transmission of the determined delta frame objects achieves conformity.
In a fourth aspect the invention is a method of providing a runtime environment, comprising the steps of: programming the runtime environment to hold: free form database objects, known as frame objects, which hold client data in data fields and are replicated in a remote server, and component based application modules, known as agent objects, received from the server despatches, as required, to create or manipulate information in the frame objects; and where, after a frame object has been changed, creating a new edition of the frame object, known as a delta frame object, which contains only the data fields that have been changed: and synchronising the client with the server or another client by exchanging edition information between them, determining from the exchange which delta frame objects need to be aggregated, aggregating those delta frame objects, and transmitting the aggregated delta frame objects in order to bring them into conformity.
By this arrangement and technique it may be possible to minimise the volume of data transfer required to maintain synchronisation between one or more remote client databases, where each client database holds several frame objects. Alternatively, it may be possible to minimise the volume of data transfer required to maintain synchronisation of a centralised, server, database holding an amalgamation of all frame objects which have been replicated to the server database from client databases.
The server and client databases cooperate in the process of synchronisation to maintain editions of frame objects stored at the server and client databases. An edition represents a complete frame object when taken in isolation. An edition, when taken relative to a predecessor edition represents only the changes ("delta elements") to that predecessor edition. The edition history may be arbitrarily long (i.e. the number of editions kept) although for data storage conservation reasons edition history may be trimmed without loss of integrity of the whole frame object. The tradeoff in this case will be that the whole frame object would need to be sent in any request for an edition which has been trimmed since the change information required to enable extraction of the delta elements will have been removed. Generally. Objects are held at the server and client in persistent storage.
All the objects are advantageously platform independent. Frame objects can have data fields ("slots") arbitrarily added, changed or deleted. Conventional compression schemes may also be employed to further improve the efficiency of data transfer.
The computer supporting the server database and the computers supporting the client databases will be connected via communications networks which are either charged on a time connected basis, or. a quantity of data transferred basis. In either case it is to the commercial benefit of the user to minimise the data traffic such that telecommunications costs are reduced.
Programming and administration tools may be provided for the system. The system may be designed to offer reliable uninterrupted operations. The design may be flexible and broad enough to meet both current and future subscriber requirements. The system may also minimise telecommunications traffic costs and cater for the typical mobile user who is "occasionally" connected to the service.
The central server infrastructure may support multiple companies operating simultaneously and with concurrent end-user sessions. It may be able to be rapidly and easily customised to meet an individual subscriber company's needs. It may be capable of adding or changing customised applications on the service without compromising the operating stability and reliability for existing subscribers. It may also provide users with an environment closely representing their "legacy" paperwork processes. The system may interface with existing host computing systems to extend the functionality of a company's IT as seamlessly as possible. It may also maximise operational cost efficiency by sharing central server infrastructure over the entire subscriber base. The service may support clients operating in "occasionally connected" mode to provide continuous functionality for mobile users or fixed clients with restricted communications continuity. It may minimise data transfer between clients and the server by only transferring those elements of data structures that have changed at either end. It may support mechanisms to stringently validate the integrity of data transferred between the server and clients. It may be capable of being localised to enable deployment in different international territories
The architecture enables the implementation of a reliable multi- subscriber mobile application service. An innovative use of object technology and an application abstraction layer enables the system to run generalised software at the server (hub) and yet be fully customable to the unique needs of different subscriber companies.
Brief Description of the Drawings
An example of the invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of the tiers of the architecture of the service example.
Figure 2 is a schematic diagram of the architecture of the central service system.
Figure 3 is a schematic diagram of the client architecture. Figure 4 is a schematic diagram of the communications structure assumed for the service. Best Modes of the Invention
The system architecture 1 of the service system is implemented as a multi-tiered client-server computing model, as illustrated in Figure 1. There is a central site server system 2, and remote clients 3. There are a number of tiers of the architecture.
A client-server communications layer 4 supports network traffic authenticated access, utility services and programmable (custom) services. The programming model (client-server-service) relies on the concept of software services running in conjunction with the server with which clients interact.
A system-wide object programming model 5 supporting platform independent objects, object manipulation primitives (methods) and mechanisms for remote method invocation between clients and the server. An application "runtime" environment 6 provides support for advanced object operations such as persistence (caching), queries, transfer, synchronisation, etc.
Component-based application modules 7 are dispatched to execute in the client runtime environment 6. The applications 7 are called agents. Agents 7 are objects able to create or manipulate information, which will subsequently be exchanged with the server system 2. deposited in an object store 8. and routed to their next destination (client). To an end user, agents might appear as forms and list items that display on the client device screen. The system also has a number of other important functional blocks. These are: a System Development Kit (SDK) that provides a set of programming tools that enable the rapid development of agents and other data definitions used to define an application. And a set of administrative tools used in the operation and maintenance of the overall system.
The lower layer consists of an object-oriented client-server system that provides data communications, authenticates connections, routes data traffic. logs events, and provides a variety of other utilities (e.g.. Internet mail and paging system interfaces).
The client-server system implements the object model and object primitives used extensively by the upper layers of the architecture. The object model is built around clients interacting with services, which are exposed to them through the server. Clients create remote objects of defined types in services and send method calls to those objects for the server to execute on their behalf.
In single-purpose application systems, the services consume a large proportion of the application specific code. However, this service system provides services that support object manipulation for the runtime environment executing in the clients. Subscriber-specific application code executes exclusively in the client runtime environment 6.
Applications are abstracted from the basic client-server system by a runtime layer. The client side runtime layer 6 implements a set of interfaces and functionality required for the execution of application agents 7 at a client. Agents 7 are stored centrally 8 on the server and dispatched to a client as required. As far as an agent 7 is concerned, all the resources and data that it requires to operate exist in the client runtime environment 6. Any requests that the client runtime cannot fulfil directly for an agent will be dealt with by having the runtime 6 "contact" the server 2. This can happen invisibly or the agent 7 can be notified of a connection requirement.
The central server system 2, or hub, is the transportation and distribution centre for the entire system. The hub 2 enables agents 7 to travel to clients 3 in order to carry out their intended tasks. Upon connection, clients 3 declare their platform type to the hub 2 which, in turn, dispatches agents 7 that are compatible with that client's computer platform. The hub 2 is solely responsible for transporting and storing objects; it remains independent of any particular subscriber application. The hub 2 is designed to support multiple subscriber companies using the system simultaneously and multiple concurrent client sessions. The services at the hub are available to all users.
Figure 2 shows an overview of the hub architecture.
The hub 2 moves all application data to and from clients. The hub is configured for a new subscriber company by allocating a database 10 to a subscriber company and then depositing agents 7 and their accompanying data into that databaselO. The software "knowledge" for a particular subscriber company is held entirely by the company specific agents and their accompanying data and view definitions. Administration and monitoring of the overall system is carried out by client computer(s) with "administrator" privileges. Administrator clients are independent of the application system and interact directly with the client- server and runtime systems.
Administrative clients are used to manage functions such as adding or removing subscriber end users, depositing new versions of agents onto the system for use in a particular subscriber application, viewing system logs to trace abnormal events or faults, etc.
Agents 7 characterise the behaviour of a client 3. Agents 7, in conjunction with the data store 10, are the primary means of customising the system. Agents 7 stored at the hub 2 may contain code for execution on a number of different client platforms. The hub 2 will choose the appropriate code version to dispatch in an agent to a client 3. It is able to do this because clients 3 declare their platform type to the hub when they connect in. Neither the server nor client runtime layers 6 have any specific knowledge of the tasks that an agent implements for a particular subscriber company. The runtime environment deals with objects only. Agents are uniquely programmed to implement the "business rules".
Agents are dispatched from the hub to clients automatically and are held in persistent storage in a client until replaced or purged. Therefore, the hub may respond to a client's request for an agent and attached data by sending the data only, since the agent may already reside in memory. Agents may co-exist in clients with more versions of themselves. This enables multiple versions of "agent data" to reside in the system and still be processed by the agent of the correct (or older) version if required. This feature is important where large amounts of historical data may be held on the system. Older versions of data may need to be handled by a matching version of an agent. In this case agents and agent data of older versions must be able to co-exist.
Agents "carry around" the data that they require by referencing data objects. The actual task of transporting the data is a function of the object store and the routing and transfer services. Consequently, agents never need to concern themselves with how they or the data they require travels.
The major elements of the client 3 architecture are shown in Figure 3. The scope of an agent's 7 interaction with the client operating system or connected devices is unrestricted. It is. therefore, possible to implement any required interface at a client. Client computers may interact with human operators using an agent that has a Graphical User Interface (GUI). Client computers can also act as a gateway to other computers or IT systems simply by creating the appropriate agent interface. Standard agents can be constructed for use via published programmatic interfaces as ODBC and those that are delivered with the Operating systems and database software. Other standard agent interfaces for integrating with customer information systems such as SAP can be readily constructed.
The system is designed to enable clients to operate in off-line (not connected) mode. The runtime environment attempts to satisfy all agent requests without connecting. The object store caching mechanism captures data current to the last connection between the hub and a client. The off-line mode of operation is used heavily for mobile clients; however, the use of the "occasionally connected" mode of operation is not restricted to use by mobile devices.
With the recent emergence of intelligent mobile phone handsets, this class of device is a potential candidate for a mobile client computer. The screen area, memory and processing power of these devices is generally limited to the extent that they are not candidates for a standard client. However, by using a standard client as an intermediate interface for these types of devices, it would be possible to support such simple mobile clients on the system. A single interface client could act as a proxy for multiple simple clients. Simple clients would generally be restricted to receiving schedule (job) data, acknowledging receipt of schedule data, submitting time use information. Simple clients could also perform well in the receiving of management information from the system so that business performance information could be conveyed to field based management.
An agent implements its GUI with the aid of View Definitions. A View Definition is yet another object and defines how a particular GUI operates on a client device. This is important where the same agent may execute on a variety of devices with differing screen sizes and input systems (e.g. handheld vs desktop or keyboard vs pen). Therefore, view definitions provide convenient and consistent ways for agent data to be displayed and input on a system wide basis.
In order to have data formats universally understood across the entire system all data is described by data definitions. Data definitions are objects with a known internal structure which have the sole purpose of describing the format of other free form objects. Data definitions (DataDefs) have version information contained in them (just like agents). Consequently, multiple versions of the same basic data definition may exist in the system concurrently without causing concern (as you might expect this is actually true of all objects used in the application system). Data definitions may reference other data definitions. Arbitrarily complex data structures can be constructed and moved around the system through this linking and embedding mechanism.
Each customised application will have its own set of data definitions which will be guaranteed to be unique within the system. The object stores (hub and client) hold all subscriber specific data in the system. The hub object store is designed for fast operations on multi- object hierarchical structures. The object store only moves those objects that do not currently exist at the destination site (client or server). The object store further economises on data traffic by moving only those parts of objects that have changed. This process of partial data transfer is termed
"synchronisation". Synchronisation plays an important role in minimising traffic to and from mobile clients where communications bandwidth is at a premium.
In more detail, when a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed. Synchronisation of the server and the client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity. Then the determined delta frame objects are transmitted to achieve conformity.
An object based query system is built into the object store in order to enable content based searching and extraction of objects.
The hub object store caches all client data that passes through it. Clients also cache data but restrict this to items that are of concern to them. Therefore, the hub has a snapshot of information from clients current to their last connection. The caching of data at the hub enables the recovery of a particular client's state should it lose its local copy of data.
All data associated with each subscriber company is held in separate object stores at the hub. Customisation to meet individual subscriber company requirements is carried out with the aid of a System Development Kit (SDK). The SDK generates agents, view definition and data definition objects. Agents, view definitions and data definitions created by the SDK are loaded into storage on the hub for distribution to client computers. The SDK supports the creation of derivative applications from base (template) applications. This substantially speeds the implementation of applications for specific companies. Derivative applications can co-exist in the system without conflict since all objects are assigned unique IDs.
The basic System requires mobile communications to support roaming connections from handheld clients, landline communications to support connections from office based clients and landline communications to support administration clients.
The communications structure assumed for the service is shown in Figure 4.
GSM is the prime wireless communications medium for handheld devices. This is well supported in Australia, Asia and Europe with the majority of GSM carriers having data capabilities in their networks. In order to increase the customer satisfaction with the GSM mobile connections there is "direct connect" of service servers to the GSM switch. Direct connect eliminates the need to exit the digital part of the GSM network in order to establish a data connection via analog modem to the server(s). This has the effect of reducing the connect time from a mobile handheld by approximately 20 seconds (analogue modem dialling/training time). The resulting connect time is then reduced to the TCP/IP communication setup and server login time. Advances in the GSM system will soon see the introduction of GSM packet based services known as General Packet Radio Services (GPRS). Packet services enable a (virtual) continuous connection between the client and the hub with the subscriber being charged by data traffic rather than connection time. The implementation of GPRS will improve the utility of the Service by enabling mobile clients to dramatically increase their communication "uptime" with the service. While ever a mobile user is in radio coverage GPRS will enable client to server communications to take place and a more continuous exchange of information between the mobile user and the hub. Alternative mobile data networks such as CDPD are supported by the Retriever system. CDPD is a packet based system supporting TCP/IP communications. It is enjoying increased coverage in the USA and offers similar features to GPRS but operates on an analogue system (operates over legacy -AMPS cellular networks).
Providing Internet based access is a logical extension of the system. By using web access customers could review the status of current activity or review historical information.
Web access would be provided through a secured web site in order to retain security over the information. Web access would be "view only". Customers would require a username and password in order to access the secure web site.
It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS:
1. A centralised server, or software to program a centralised server, for a mobile application service system, where the server is programmed to create and maintain separate databases for respective clients to hold client knowledge in the form of: free form database objects, known as frame objects, which hold client data in data fields and are replicated in client computers; and component based application modules, known as agent objects, which the server despatches to respective clients, as required, to create or manipulate information in the frame objects; and where the server is programmed such that, after a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed: and synchronisation of the server and the client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity, then transmission of the determined delta frame objects achieves conformity.
2. A centralised server, or software to program a centralised server, according to claim 1. where the client is mobile.
3. A centralised server, or software to program a centralised server, according to claim 1, where objects are held at the server and client in persistent storage.
4. A centralised server, or software to program a centralised server, according to claim 1. where the objects are platform independent.
5. A centralised server, or software to program a centralised server, according to claim 1, where frame objects have data fields added, changed or deleted.
6. A centralised server, or software to program a centralised server, according to claim 1. where conventional compression schemes are employed to improve the efficiency of data transfer.
7. A centralised server, or software to program a centralised server, according to claim 1. where programming and administration tools are provided for the system.
8. A method of providing a mobile application service system, comprising the steps of: creating and maintaining at a server, separate databases for respective remote clients to hold client knowledge in the form of: free form database objects, known as frame objects, which hold client data in data fields and are replicated in client computers; and component based application modules, known as agent objects, which the server despatches to respective clients, as required, to create or manipulate information in the frame objects: and where, after a frame object has been changed, creating a new edition of the frame object, known as a delta frame object, which contains only the data fields that have been changed; and synchronising the server and the client by exchanging edition information between them, determining from the exchange which delta frame objects need to be aggregated, aggregating those delta frame objects, and transmitting the aggregated delta frame objects in order to bring them into conformity.
9. A method according to claim 8, where the client is mobile.
10. A method according to claim 8, where objects are held at the server and client in persistent storage.
11. A method according to claim 8. where the objects are platform independent.
12. A method according to claim 8. where frame objects have data fields added, changed or deleted.
13. A method according to claim 8, where conventional compression schemes are employed to improve the efficiency of data transfer.
14. A method according to claim 8, where programming and administration tools are provided for the system.
15. A client runtime environment, or software to program a runtime environment, where the runtime environment is programmed to hold: free form database objects, frame objects, which hold client data in data fields and are replicated in a remote server, and component based application modules, known as agent objects, received from the server despatches, as required, to create or manipulate information in the frame objects; and where the runtime environment is programmed such that, after a frame object has been changed a new edition of the frame object, a delta frame object, is created which contains only the data fields that have been changed; and synchronisation of the client with the server or another client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity, then transmission of the determined delta frame objects achieves conformity.
16. A client runtime environment, or software to program a runtime environment according to claim 15, where the client is mobile.
17. A client runtime environment, or software to program a runtime environment according to claim 15, where objects are held at the server and client in persistent storage.
18. A client runtime environment, or software to program a runtime environment according to claim 15, where the objects are platform independent.
19. A client runtime environment, or software to program a runtime environment according to claim 15, where frame objects have data fields added, changed or deleted.
20. A client runtime environment, or software to program a runtime environment according to claim 15. where conventional compression schemes are employed to improve the efficiency of data transfer.
21. A client runtime environment, or software to program a runtime environment according to claim 15, where programming and administration tools are provided for the system.
22. A method of providing a runtime environment, comprising the steps of: programming the runtime environment to hold: free form database objects, frame objects, which hold client data in data fields and are replicated in a remote server, and component based application modules, agent objects, received from the server despatches, as required, to create or manipulate information in the frame objects; and where, after a frame object has been changed, creating a new edition of the frame object, known as a delta frame object, which contains only the data fields that have been changed; and synchronising the client with the server or another client by exchanging edition information between them, determining from the exchange which delta frame objects need to be aggregated, aggregating those delta frame objects, and transmitting the aggregated delta frame objects in order to bring them into conformity.
23. A method of providing a runtime environment according to claim 22, where the client is mobile.
24. A method according to claim 22, where objects are held at the server and client in persistent storage.
25. A method according to claim 22, where the objects are platform independent.
26. A method according to claim 22, where frame objects have data fields added, changed or deleted.
27. A method according to claim 22, where conventional compression schemes are employed to improve the efficiency of data transfer.
28. A method according to claim 22, where programming and administration tools are provided for the system.
PCT/AU2000/000174 1999-03-10 2000-03-10 Mobile application service WO2000054525A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU28974/00A AU2897400A (en) 1999-03-10 2000-03-10 Mobile application service

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AUPP9117A AUPP911799A0 (en) 1999-03-10 1999-03-10 Mobile application service
AUPP9117 1999-03-10

Publications (1)

Publication Number Publication Date
WO2000054525A1 true WO2000054525A1 (en) 2000-09-14

Family

ID=3813316

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2000/000174 WO2000054525A1 (en) 1999-03-10 2000-03-10 Mobile application service

Country Status (2)

Country Link
AU (1) AUPP911799A0 (en)
WO (1) WO2000054525A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1301475C (en) * 2001-08-13 2007-02-21 鸿富锦精密工业(深圳)有限公司 Positive data copying method for radio equipment
US7320011B2 (en) 2001-06-15 2008-01-15 Nokia Corporation Selecting data for synchronization and for software configuration
AU2003291909B2 (en) * 2002-12-26 2008-11-20 Citrix Systems International Gmbh System and method of creating and communicating with component based wireless applications
US7483925B2 (en) 2001-06-15 2009-01-27 Nokia Corporation Selecting data for synchronization
US8095495B2 (en) 2007-09-25 2012-01-10 Microsoft Corporation Exchange of syncronization data and metadata

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5825759A (en) * 1994-10-26 1998-10-20 Telefonaktiebolaget Lm Ericsson Distributing network services and resources in a mobile communications network
US5913164A (en) * 1995-11-30 1999-06-15 Amsc Subsidiary Corporation Conversion system used in billing system for mobile satellite system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5825759A (en) * 1994-10-26 1998-10-20 Telefonaktiebolaget Lm Ericsson Distributing network services and resources in a mobile communications network
US5913164A (en) * 1995-11-30 1999-06-15 Amsc Subsidiary Corporation Conversion system used in billing system for mobile satellite system

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"Java Developer's Guide", Copyright 1996 by JAMIE JAWORSKI, Section 19.1. *
"teach yourself JAVA 1.1 Programming in 24 hours", SAMS ISBN 1-57521-270-6, Copyright 1997 especially page 154, Figure 12.1. *
ANGIN ET AL.: "The mobiware toolkit programmable support for adaptive mobile networking", IEEE PERSONAL COMMUNICATIONS,, August 1998 (1998-08-01), pages 32 - 43 *
LEPPINEN ET AL.: "Java-and CORBA-based network management", IEEE COMPUTER,, June 1997 (1997-06-01), pages 83 - 87 *
MUNSON ET AL.: "Sync: A java framework for mobile collaborative applications", IEEE COMPUTER,, June 1997 (1997-06-01), pages 59 - 66 *
TOKMAKOFF ET AL.: "Service trading in mobile environments", ICICS '97,, 9 September 1997 (1997-09-09) - 12 September 1997 (1997-09-12), pages 417 - 421 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7320011B2 (en) 2001-06-15 2008-01-15 Nokia Corporation Selecting data for synchronization and for software configuration
US7483925B2 (en) 2001-06-15 2009-01-27 Nokia Corporation Selecting data for synchronization
CN1301475C (en) * 2001-08-13 2007-02-21 鸿富锦精密工业(深圳)有限公司 Positive data copying method for radio equipment
AU2003291909B2 (en) * 2002-12-26 2008-11-20 Citrix Systems International Gmbh System and method of creating and communicating with component based wireless applications
US8402432B2 (en) 2002-12-26 2013-03-19 Research In Motion Limited System and method of creating and communicating with component based wireless applications
US8095495B2 (en) 2007-09-25 2012-01-10 Microsoft Corporation Exchange of syncronization data and metadata

Also Published As

Publication number Publication date
AUPP911799A0 (en) 1999-04-01

Similar Documents

Publication Publication Date Title
CN101207550B (en) Load balancing system and method for multi business to implement load balancing
US6671746B1 (en) Execution of application process using registry having binding methods
CN103731447B (en) A kind of data query method and system
CN101969391B (en) Cloud platform supporting fusion network service and operating method thereof
US7831724B2 (en) Services layer model for providing standards-based communications
Gaddah et al. A survey of middleware paradigms for mobile computing
US20060234623A1 (en) System and method for efficient transfer of applications and data during device swap
US8566437B2 (en) Systems and methods for improved multisite management of converged communication systems and computer systems
US20060259523A1 (en) System and method of synchronization of internal data cache with wireless device application data repositories
US20040088186A1 (en) Distributed convergent service control platform
CN110213156A (en) A kind of span centre heart group's instant communicating method and system
CN100484014C (en) Distributed cluster service management system and service management method in intelligent network
CN110011984A (en) A kind of distributed cluster system and method based on REST and RPC
US20070226319A1 (en) Interactive wireless broadband network and business support system
WO2000054525A1 (en) Mobile application service
US6185626B1 (en) Arrangement and method for linking clients to servers at run time in a distributed networking environment
CN100490371C (en) A method for improving security of private data in open service
Mascolo et al. Principles of mobile computing middleware
Arbab et al. Mocha: A middleware based on mobile channels
Raza et al. Mobile agent middleware for multimedia services
KR100417850B1 (en) Integration system of wireless network and the internet
CN114615096B (en) Event-driven architecture-based telecommunication charging method, system and related equipment
Sommers et al. Cluster-based computing with active, persistent objects on the web
CN117675607A (en) Ubiquitous intelligent network construction method and device based on data intelligent service body
Kostkova et al. Support for dynamic trading and runtime adaptability in mobile environments

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase