Invented by Jussi Ketonen, Carolyn Talcott, WEBLOYALTYCOM Inc, Top Moxie Inc
The WEBLOYALTYCOM Inc, Top Moxie Inc invention works as followsA system to assist a client mobile interact with computers associated includes a device mobile, a broker mini-server, and a personal agent. The mobile device transmits information about identification and security. Directly or via the broker, the requests are sent to the miniserver. Requests can also be sent to the personal agent. Requests that are public or restricted can be sent to the mini-server, which will respond to them by supplying information on the internet. Private requests are sent to the personal agent. If the request requires it, secure connections are made between the mobile device and the mini-server, broker or personal agent. The mini-server, personal agent or broker obtains and formats requested information in accordance with the requirements of mobile client identification. The requested information will be transmitted to the client mobile in a format that takes into account the limitations of its visual display.
Background for Method for transmitting and changing data between a mobile computer and a wireless network
Personal digital assistants are portable devices that typically have an input device and visual display. They also include a memory, a microprocessor, and a memory. PDAs can provide limited information or perform tasks for their users. PDAs typically work together with other computers by sharing data and “synchronizing” Data such as contact lists and schedules are shared by a PDA with another computer. To share data with the computer, the PDA might need to be wired.
Some PDAs can obtain information directly from the Internet. The HTTP protocol is used to obtain information on the Internet, including HTML documents. A computer must specify a URL, which is an address unique to a file published on the Internet. The HTML documents that are associated with a URL generally contain information formatted to be displayed in images on a large monitor. PDAs have smaller displays and less memory, so they may not be able to display HTML documents in their entirety.
The inventive mobile assistant system consists of hardware and software that facilitates communication between mobile clients (PDAs), the internet, or a personal agent (desktop computers) associated with it. The mobile assistant system responds to requests made by users via their mobile clients. It will obtain the information requested or perform the task requested. The mobile assistant system can recognize the type of PDA that is being used, and modify the information sent to the mobile client in order for it to be displayed correctly on the PDA’s visual display. The mobile assistant allows users to securely interact remotely with desktop applications to perform tasks like: banking, accounting and bidding at auctions.
In one embodiment, the mobile assistance system includes a personal assistant, a broker, and a mini server, which are all computers running the local assistant software. The mobile client sends requests to the broker or mini-server, such as for data, information, reminders, or spidering. The broker is like a messaging center that receives requests from the mobile clients and sends them to the source of information. The request contains information that identifies the mobile client, as well as any special security information, if confidential data is requested.
The mobile assistant system is capable of operating at different levels of security. Requests may include a security level, such as restricted, public or private. Public information is that which is easily accessible via the internet. Public requests do not always require user authentication, identification or secure communications. Restricted information is information that’s available on a public site but has restricted access. For example, financial or brokerage account information and other confidential data. Restricted requests can require authentication, user identification and a secure communication connection. Information stored on the agent’s personal computer that is only available to the user may be considered private information. “Private requests require the user to be identified, authenticated and have a secure communication connection.
The broker will determine the level of security and proceed accordingly. For a public-level request, the broker will open a nonsecure connection to the Mini-server. In the case for a restricted-level request, the broker will open a secure communication connection to the Mini-server. The broker associates the connection with the client request and sends the request to mini-server. The mini-server retrieves the requested information when it receives a request. The mini-server extracts information from the request regarding the characteristics of the mobile client devices and formats it accordingly. The broker receives the formatted information. This information is then sent by the broker to the mobile client via the mobile-client connection. The transaction is completed. The information requested has been formatted according to PDA specifications, so the information required can be viewed in full on the PDA display. A broker can be accessed via an internet URL, and one broker may support multiple mobile clients.
In the event of a private inquiry, the broker creates a ticket and stores the request along with the ticket in its private requests database to be retrieved by a personal agent later. The broker transmits the ticket in a format that allows the mobile client to access the requested data once it is available.
Periodically, the personal agent for a mobile customer will open a link to the broker and request pending requests. Personal agent gives identification and authentication data. The broker searches his database of private requests to find requests addressed to the personal agents that do not have a reply and have authentication data that matches the personal agent’s. The broker sends a ticket to the agent if it finds any. If no requests are pending, a message stating “no pending request” is sent to the personal agent. A message stating that there are no pending requests is sent to the personal agent. The broker’s response will end the transaction in either case.
The personal agent executes the request after retrieving the ticketed request. It could be gathering information or performing a task. The personal agent formats the reply according to the device characteristics of mobile clients. The personal agent opens a secure link with the broker, and posts the response along with the ticket. The broker saves the reply and the ticket together in the private request database.
When the mobile client sends a retrieval, the broker searches for an item that matches the ticket details of the request to which a response has been posted. The broker will then send the requested information to the ticket if there is a match. If the broker is unable to find a ticket that matches, the agent or mobile client will receive a message saying the information requested is not available.
In one embodiment, public requests may be sent directly from the mobile client to the server mini without the need for information to be passed through the broker. The request also includes the PDA’s identification. The mini-server will retrieve and format information if it is requested. The mini-server transmits the requested information to the mobile client. A secure connection is not required because public information has been requested.
The personal agent (PA), broker (B), and mini-server (MS) all have a client side local assistant computer program that is used to monitor communication activity, determine rules applicable, interpret rules, and manage local interaction databases (IDBs) and local ruleset databases (RDBs). Rules are syntactic description of conditions and actions that must be taken in relation to an information context. The ruleset is an ensemble of rules, meta-data and/or data that work together to implement local assistance functionality.
In one embodiment, the local assistant administrative system is also part of the mobile assistant. The local assistant administrator server is the source of information current for the mobile system. The local assistant administrative servers can transmit upgrades and utility information to other components of the mobile assistant system. Local assistant administrative servers can communicate with local agents, brokers, and mini-servers to easily load new features and upgrades.
The inventive system is a local assistant for managing business processes that improves on the “Local Assistant For Managing Business” The system described in the U.S. Patent application Ser. No. 09/696,558. The Mobile assistant (MA), system builds on the local assistant technology, by incorporating clients that can communicate with the Mobile assistant System.
The following is a description in detail of the preferred embodiments for the present invention. The present invention does not intend to be restricted to the embodiments described below or illustrated in the drawings. The description and drawings are only intended to illustrate the preferred embodiments currently of the invention.
The local assistant (LA), a client side software system, allows an internet agent provide highly flexible and efficient relevance-based information distribution services to merchants and internet-based entities to help them bring timely and relevant information and offers to online users. The client-side software is extendable and customizable through downloadable ‘rules’. Downloadable rules. “Each service/application is implemented using a rule set (called a ‘feature’) which consists of rules and meta-data.
FIG. The local assistant system is configured to support LA. FIG. Local assistant system is composed of one or several customer computers 100 connected to the internet 130, and a local assistant administrative system. Customer computer 100 includes a local assistance kernel 104 that interacts with rule database 105, and interaction database 106. Local assistant program 104 also communicates with local assistant administrative system. Local assistant administrative system 110 consists of a web server and local assistant administrative program 112. These interact with a merchant database 113, a database for administrative rulesets 114, and an administrative interactions database 115.
The local assistant system consists of a client computer 100 that runs a local assistance client-side program 104 and a local administrative system 110 which operates in conjunction with other web sites (represented on FIG. All of these are connected by the Internet 130 (which has been left implied in the rest of the figures of this document). The customer computer 100 is any computing device which allows the customer to browse websites interactively via a browser 107, and preferably control other devices like media players, location sensor, etc. as shown in FIG. An interaction point 101, such as a CD-player, and an interaction manager (such Win Amp) are shown in FIG. (Note that the web browser 107 itself is an example of an interaction manger 102, the interaction point 101 being a mouse/keyboard/pointing device.) The customer computer 100, for example, could be a PC connected to Internet via modem or a handheld or wearable computer that is connected by wireless communication.
The local assistant client-side program 104 is written in Java for the Top Moxie version. It includes functions such as monitoring client interactions, determining rules that apply, interpreting those rules, managing the local interaction database (IDB) and managing the local ruleset databases (RDB).
The local assistant program interacts with system resource manager to determine the current client activity, such as browser windows open or CD players running. The local assistant program constructs a context of information for each activity that is relevant using data from the interaction manager. The information can be as simple or complex as the HTML code of a website document. This information context is an extension of the implicit information context in the local interaction database (Local IDB). Local assistant program 104 queries the local ruleset databases (Local RDB) 105 to find applicable rules. It then schedules and executes these rules using a conventional, simple scheduling algorithm. The rule interpreter functionality decides what actions to take depending on the information context and rule that is provided. The possible actions are: invoking another rule, retrieving HTML files 122 from a server 121, and analysing them to extract relevant information, requesting operation on the interaction database 106, or the rulesets database 105; posting updates on the local assistant administrative site 110; and presenting the information to interacting with a customer. The interaction data manager functionality allows access to the local database 106, and manages data elements such as creation, lookups, updates and deletions. The ruleset manger provides functionality for querying the local ruleset databases 105 to find rules that apply in a specific context, to suspend or resume a ruleset and to delete it. It also allows you to download rulesets from the local assistant administrative site 110.
Click here to view the patent on Google Patents.