Basically, in the information processing system according to the present invention, a master control device 14a can activate the federated device 14b, and command this specific device to return required information to the master control device 14a. As such a user of the master control device 14a can easily gather confidential information he or she needs from the other devices. In order to achieve the foregoing mode of operation, the information processing system contains a point-to-point communication mechanism. As shown in
As mentioned earlier, in the information processing system, a master control device 14a interoperates and collaborates with a federated device 14b to gather and process confidential information. In the mean time, the master control device 14a can receive public information from the information servers 10a and 10b. To conduct these communications, the master control device 14a must have a C&C (control and communication) unit 5 installed and executed. A federated device 14b also must have a C&C unit 6 to collaborate with the master control device 14a. Basically, the C&C units 5 and 6 have same functionality and ways of operation, except that one plays an active role while the other plays a passive role. A C&C unit is usually implemented as a resident service of the operating system running on the master control and federated devices. During the collaboration process, if required, the C&C unit 6 will invoke appropriate execution modules 8 to carry out the requests issued from the C&C unit 5. Similarly, the C&C unit 5 will invoke appropriate execution modules 7 to carry out the requests issued from the C&C unit 6 if necessary. The term “execution module” is used here to refer to independent software programs also installed on the same device as the C&C unit that can be activated by the C&C unit. An execution module could be another resident service of the operating system, an application program such as Microsoft® Word®, or an administration interface program of the C&C unit, just to name a few examples. The C&C unit can also be configured to activate certain execution modules when the C&C unit is started, or according to a schedule specified by the user. The interaction between the C&C unit and the execution module is loosely coupled and could be in a two-way manner. If an execution module is an application program, the execution module is activated by the C&C unit's calling the operating system's appropriate service. Some parameters can be passed to the activated execution module during its start-up. Once the execution module is activated, it is running as an independent process. Subsequently, the C&C unit can still interact with the execution module using appropriate mechanisms (such as Dynamic Data Exchange, DDE®) and information can be passed between the C&C unit and the execution module. A scenario of the interaction between the C&C unit and the execution module is as follows. A C&C unit receives three Word® document files and requests to open the three files from another C&C unit. The C&C unit first checks to see if the Word® program is already running; if yes, the C&C unit informs the Word® program to open the first Word® file at a specified directory; if not, the C&C unit activates the Word® program and instructs it to open the first Word® file at the specified directory. Subsequently, the C&C unit calls the running Word® program to open the second and third Word® files at the specified directory. After the three Word® files are opened, the C&C unit leaves the Word® program to run independently. The user then can operate the Word® program to view or edit the three Word® files.
It has to be stressed again that a device can be a master control device at one time and be a federated device to some other master control device at another time. Furthermore, a device can actually be, at the same time, both a master control device and a federated device. Therefore, a master control device can interoperate with more than one federated device, and one or more of the federated devices can further interoperate with their own federated devices. This is all achieved by the C&C units of these devices. Also through the C&C units, the master control device thereby can invoke an execution module in a federated device so as to gather the required information. Each device's C&C unit has a unique ID so as to distinguish one device from the other devices. The devices and servers conducts communications using messages expressed in an extensible language such as XML (eXtensible Markup Language). More details will be given later.
The C&C unit 5 of the master control device 14a gathers the required information from various sources specified in its service directories. There are two service directories in the C&C unit on a device: open service directory containing information about sources of open and public information, and proprietary service directory containing information about sources of private and confidential information.
As shown in
As will be explained later, each information provider of the information processing system will register its service in a registration server where a list of all available information services is thereby compiled. Then, the list of information services is subsequently passed to a device for setting up the device's open service directory. The information contained in the open service directory contains sets of information or instructions called scripts. The scripts are categorized into fixed scripts, variable scripts, and control scripts, all expressed in an extensible language such as XML. These scripts direct the C&C unit to activate appropriate execution module of the master control device to conduct agent-based one-to-many communications in gathering open or public information. An example of a fixed script is as follows:
This fixed script specifies that (1) the Instant Stock Price Index information is published from an information server whose ID is 1111 under a directory ID 98. Similarly, the Stock Market News information is published from another information server whose ID is 9999 under a director ID 99. An example of a variable script is as follows:
This variable script contains data about where to retrieve information and the data reflects the current network configuration (therefore, the name ‘variable’ script). In the example above, the variable script specifies that the Instant Stock Price Index information is available both from the agent servers whose IDs are 1515 (with an IP address 15.15.15.15) and 3030 (with an IP address 30.30.30.30). Similarly, the variable script also specifies that the Stock Market News information is available both from the agent servers whose IDs are 2020 (with an IP address 20.20.20.20) and 3030 (with an IP address 30.30.30.30). More details about the agent servers will be described later. On the other hand, the control script contains the instruction about how to retrieve specific information (therefore, the name ‘control’ script). An example of a control script is as follows:
Similarly, the information contained in the proprietary service directory also contains scripts. There are only fixed scripts and control scripts in the proprietary service directory, which direct the execution module in the master control device to conduct point-to-point communications in gathering private information from federated devices. The proprietary service directory does not contain variable scripts as, for example, there is no agent servers involved in the point-to-point communications. An example of a fixed script of the proprietary service directory is as follows:
This fixed script specifies that private information Stock Account is available from a federated device whose C&C unit ID is 1111 under a directory ID 97. An example of a control script of the proprietary service directory is as follows:
This control script specifies the ‘command’ used in a message to subscribe Stock Account information from the federated device whose C&C unit ID is 1111. In the following, the functions of the service directories will be described to explain how the point-to-point communications and agent-based one-to-many communications are conducted.
For execution modules 7b and 7d, as the stock pricing information and market news are public information, they follow the scripts in the open service directory to retrieve these pieces of information. As to the execution module 7c, as the bank account information is private and confidential, it follows the scripts in the proprietary service directory to retrieve this piece of information.
It is also possible to have the receiving agent servers 12a and 12b to distribute public information proactively to the devices 14a˜14d via a distribution rule, instead of waiting for the requests from the devices 14a˜14d. As such, whenever the devices 14a˜14d get access to the network, they can start receiving public information from the receiving agent servers 12a and 12b. The distribution rule, based on a classification of the content of the public information and a ranking of the devices 14a˜14d, describes whether, when, and in what sequence, the public information is passed to the devices 14a˜14d. The advantage in saving network traffic and offloading the information servers will become significantly apparent when there are a very large number of devices.
As shown in
Therefore, dependent on network bandwidth and loading, the information processing system of the present invention can have architecture as depicted in
In the foregoing discussion, it is assumed that each of the servers and the devices has relevant information such as service provided and address about the other party it is communicating with in advance. For a very large network with hundreds or thousands of servers and devices, the management, distribution, and configuration of these pieces of information are very difficult, if not impossible. To overcome these problems, as shown in
Similarly, when the receiving agent server 12a is started and gets access to the network, it too registers in the registration server 18 about its address, its agent ID, and the information service requirement. The registration server 18 again notifies the transmitting agent server 16a about the address, agent ID, and information service requirement of the receiving agent server 12a, and the receiving agent server 12a about the address and the list of information servers represented by the transmitting agent server 16a. As such, the transmitting agent server 16a is able to identify the receiving agent server 12a and starts to distribute the public information to the receiving agent server 12a. Please note that, during the foregoing process, the registration server 18 is able to know the public information services available in the information processing system and what transmitting and receiving agent servers are publishing a specific information service. Please also note that a transmitting or receiving agent server can publish for more than one information service.
A sample scenario about the process that a device obtains public information is described as follows, assuming that the device 14a has a C&C unit ID 9999. When the device 14a is started and gets access to the network, it will also register in the registration server about its address and C&C unit ID. If the device 14a requires subscribing a public information service, the device 14a sends a message to the registration server 18 for a list of information services. The message would contain a following script:
Upon receiving the message, the registration server 18 replies with a message containing the following script:
As mentioned earlier, these pieces of information are used to set up the fixed and control script of the device 14a's open service directory. Assuming that the device 14a would like to obtain Stock Market News and based on the fixed and control scripts of the open service directory, the device 14a sends a message containing the following script to the registration server 18:
If the information server 10a accepts the subscription, it replied with a message containing the following script:
Upon receiving this subscription notice, the registration sever 18 would perform a number of tasks: (1) registering that the device 14a has subscribed the Stock Market News from the information server 10a; (2) notifying the relevant receiving agent servers (e.g., 12a) about the address and C&C unit ID of the device 14a; and (3) notifying the device 14a by a message containing the following script:
This message is to let the device 14a know which receiving agent servers (2020 and 3030) is publishing the Stock Market News. These pieces of information are then stored in the variable scripts of the open service directory. In the mean time, the registration server 18 notifies the receiving agent server (e.g., 12a) about the address, C&C unit ID, and desired information service (by the directory_ID) the device 14a. As such, the receiving agent server 12a is able to identify the device 14a and starts to distribute the public information to the device 14a. Please note that, by incorporating appropriate control in the subscription message, various types of subscription can be achieved. There could be a one-time subscription where the subscription is cancelled automatically after the information is delivered to the device 14a. To receive the information again, the device 14a has to make another subscription as described above. The subscription can also be limited to a number of times of the information delivery; or the subscription can remain valid until being cancelled by the device 14a. Please also note that the information server 10a can reject a subscription or alter the type of the subscription. While the subscription is still valid, information about the subscription will be kept at the C&C unit of the device 14a, the information server 10a, and the registration server 18 and, whenever new information is produced on the information server 10a, the new information is delivered according to what is specified in the fixed and control scripts.
As the devices may be turned on and off, it is very possible that a device didn't receive complete public information. The solution to the problem is as follows.
The proprietary service directory is established via a similar process. For example, assuming that a device (e.g., 14b with a C&C unit ID 3333) provides confidential ROI (return on investment) Expectation Value information and when the device is started, it too registers the information provision in the registration server by a messaging having the following script:
This message may also contain other information such as which device (e.g., 14a) can obtain this confidential information. Please note that this information service will be delivered to the device requesting the list of information server as well, along with other public information services as described earlier. However this piece of information is stored in a fixed script of the proprietary service directory, instead of the open service directory. Assuming that the device 14a would like to obtain the confidential information, it issues a message having the following script to the registration server:
In other words, whenever there is a new information service available on the network, the new information server or device registers in the registration server which in turn pass this information to the rest of the network. The establishment of the open and proprietary service directories in each of the devices is achieved by each device and each information server registering in the registration server, and the registration server in turn distributes the service information to the agent servers and the devices as described above. Each of the devices, upon obtaining this new service information, is able to set up the fixed and control scripts for receiving new public information from the new information server or confidential information from the device. On the other hand, variable scripts in open service directory contain parameters that are dynamically updated to reflect the current status of the information processing system. For example, there may be various number of receiving agent servers and each one may have different workload. As such, when a device is started and registers to the registration server, the registration server is able to designate a receiving agent server based on the loading condition of the receiving agent servers. Upon receiving this new information, the device is able to update the parameters of the variable scripts. As the variable scripts are designed for public information, the proprietary service directory does not contain variable scripts.
The control script contains information about how to obtain a specific information service. The control script may be C&C unit ID of the federated device providing the private information, the schedule to gather the private information, which one of the execution modules is responsible for gathering the private information, whether to display pop-up messages when they come in, and whether to share the information obtained. As described, a user of a device can “subscribe” a public information service provided by an information server. Then, corresponding scripts are prepared in the open service directory of the device. When the execution module 7b and 7d are invoked, they follow the scripts in the open service directory to gather the subscribed public information (such as the stock pricing and the market news) and pass the gathered information to the execution module 7a. In turn, the execution module 7a presents the gathered information on a display for the user to view. Similarly, when private information is required, the execution module 7c is invoked, which follows the scripts in the proprietary service directory to conduct point-to-point communications with the federated device 14b. The gathered information is also passed to the execution module 7a for presentation to the user. All the foregoing flexibility is the result of the use of scripts and service directories in the devices.
The use of scripts can be very powerful and versatile. For example, a device may send a control script to its federated device which instructs the federated device to perform a specific task. In addition, the scripts of a federated device can be updated dynamically so that the federated device would behave differently. Based on the same principle, the registration server can do more than just relaying messages. For example, upon receiving a subscription message for Instant Stock Price Index, the registration server may request further subscriber information from the device:
In this example, a form with a number of fields (with default values) will be presented on the device's display. After a user has keyed in the required data, the data will be returned to the registration server for further processing (e.g., forwarding to the information server).
In real-life environment, a master control device 14a requiring the private information and a federated device 14b (such as a server of a bank) providing the private information may very possibly both access the network via NAT, as shown in
To allow the master control device 14a and the federated device 14b to conduct point-to-point communications with each other, a solution is provided as follows.
During the foregoing registration process, the decision unit in intermediate server 3 can compare address information contained in the data and header of the packets sent from the master control and federated devices 14a and 14b. If the addresses in the header and data sections of the packets are identical, the decision unit can decide that the device does not access network through NAT. If the decision unit decides that any one of the devices 14a and 14b is not behind NAT, the intermediate server 3 can provide a conventional point-to-point communication path for the devices 14a and 14b. If the decision unit decides that master control device 14a and federated device 14b both access network through NAT, the intermediate server 3 starts a communication mechanism of the present invention. According to the present invention, at least one of the ISP routers 17, 19 should have the capability supporting the tunneling technology, or a third party router 20 (shown in
In step 203, the master control device 14a sends a message to the intermediate server 3 through the maintained session requesting to engage in point-to-point communication with the federated device 14b. The decision unit of the intermediate server 3 decides how the point-to-point communications should be conducted according to the foregoing description. The decision unit of the intermediate server 3 will decide a router which supports the tunneling technology. This router could be the ISP router 17 or the ISP router 19 or the router 20. In the following, it is assumed that the router 20 is picked. Then, in step 204, the routing unit of the intermediate server 3 notifies the federated device 14b through the maintained session about the router 20 and the DHCP server 21 associated with the router 20. Upon receiving the notification, the federated device 14b creates a communication tunnel with the router 20 and obtains a real IP address from the associated DHCP server 21 in step 205. More specifically, the step 205 contains the following steps. In step 205-1: a tunnel is established between the federated device 14b and the router 20; in step 205-2, the router 20 requests a real IP address from the DHCP Server 21; in step 205-3, the DHCP Server 21 allocates and returns the real IP address back to the router 20; and in step 205-4, the router 20 establishes two-way packet transmission between the real IP address and the tunnel.
After creating a communication tunnel to the router 20 and obtaining a real IP address, the federated device 14b reports the real IP address to the routing unit of the intermediate server 3 in step 206 again through the maintained session. Please note that the real IP address will be released after the disconnection of the communication tunnel when the point-to-point communication is over.
In turn, the routing unit of the intermediate server 3 informs the master control device 14a of federated device 14b's real IP address in step 207. The master control device 14a then conducts a point-to-point communications with the federated device 14b using the real IP address as destination address in step 208. As described, the present invention utilizes the existing capability (mainly the tunneling technology) of routers 17 or 19 or 20 to allow true point-to-point communications between the master control device 14a and the federated device 14b. As the private information is passed through highly secured tunnels established therebetween, the present invention not only enables true point-to-point communications but also provides high information security. To further enhance data security, for example, tunnels can also be established between the master control device 14a and the router 20, so that the entire path of the private information is through tunnels all the way between the master control device 14a and the federated device 14b. Please note that, to achieve this function, the master control device 14a requires a real IP address as well.
The routing unit in the intermediate server 3 plays an important role in the process. In addition to providing the real IP address for establishing tunnels, it will also monitor the router status and response time through which the tunnel is established by the C&C units of the collaborating devices. Additionally, it can collect traffic statistics through the tunnels for future billing. When the point-to-point communication is over, the federated device 14b disconnects the tunnel to the router 20 and the real IP address is released in step 209. In the mean time, the master control device 14a notifies the routing unit of the intermediate server 3 about the conclusion of the point-to-point communication through the maintained session in step 210. The session could still be maintained by the master control device 14a for future usage. Similarly, the federated device 14b also notifies the routing unit of the intermediate server 3 about the termination of the point-to-point communication through the maintained session in step 211. This session can also still be maintained by the federated device 14b for future usage.
Although the present invention has been described with reference to the preferred embodiment thereof, it is apparent to those skilled in the art that a variety of modifications and changes may be made without departing from the scope of the present invention which is intended to be defined by the appended claims.