1. Field of the Invention
The present invention relates generally to communication networks, and more particularly to a communication network for communicating with objects having unique identifiers.
2. Description of the Related Art
The use of the Internet and wireless networks have increased exponentially in recent years. This has allowed many new disparate devices to interact and communicate with each other. Unfortunately, current Internet and wireless network solutions lack key components required to allow large numbers of these devices to seamlessly interact with one another. Currently, their are two network models are being used to connect devices: a centralized network architecture (client-server) and a distributed network architecture (peer-to-peer (P2P)).
Centralized network architectures require a central control point to connect devices. This control point runs applications that control and communicate with the connected devices. All of the devices have a standard hardware and software (protocol) interface. This model is good for communication between a single company's devices (Echelon to Echelon, or Phone.com WAP to Phone.com WAP), however, it is impractical for interoperability between different vendors' devices. Moreover, the addition of a new function in any single device requires modification of all the protocols and notification/upgrade to all other possible devices. For this reason, this architecture is good for communications between one company's devices using their own protocols, but poor for inter-vendor communications.
Peer-to-Peer network architectures have no control point and every device communicates with every other device over an open interface. Each computer or device has equivalent capabilities and responsibilities. Thus, the total number of possible links between devices/users is N(N−1)/2. This model is used in the Internet for the Hyper Text Transfer Protocol (HTTP). Examples of distributed peer-to-peer solutions include Microsoft's HailStorm suite (.NET/Passport/DCOM). This architecture is good for communications between generic devices (HTTP) or a small number of similar intelligent applications (XML). However, the P2P architecture is poor for connecting a large number of dissimilar devices because, for example, any peer can go “dark” at any time, there is no easy way to enforce content ownership/copyrights, it is difficult to enforce technical and/or ethical standards any many others. While this architecture is good for communications between a small number of different company's devices, it does not provide for an environment where new device types can be readily introduced and assimilated.
One embodiment of the invention is a wide area network for connecting and controlling a plurality of devices. The network includes: a plurality of devices, wherein each device has a unique identifier; at least one edge server configured to communicate with at least one of said plurality of devices and receive said unique identifier; and at least one first virtual registry in communication with said at least one edge server and configured to associate said unique identifier with at least one server, wherein said at least one server stores an instruction file configured for execution on said edge server, wherein execution of said instruction file enables the edge server to control the device.
Another embodiment of the invention is a method of controlling a plurality of devices in a wide area network. This embodiment includes: providing a plurality of devices, wherein each device has a unique identifier; transmitting said unique identifier to an edge server, wherein said edge server is configured to transmit said unique identifier to a virtual registry; determining at least one server comprising an instruction file by using said virtual registry to associate said unique identifier with said server; and transmitting said instruction file to said edge server, wherein said edge server is configured to execute said instruction file and thereby control functions of said device.
Still another embodiment of the invention is a system for controlling a plurality of devices in a wide area network. The system includes: means for providing a plurality of devices, wherein each device has a unique identifier; means for transmitting said unique identifier to an edge server, wherein said edge server is configured to transmit said unique identifier to a virtual registry; means for determining at least one server comprising an instruction file by using said virtual registry to associate said unique identifier with said server; and means for transmitting said instruction file to said edge server, wherein said edge server is configured to execute said instruction file and thereby control functions of said device.
Embodiments of the invention will now be described with reference to the accompanying Figures, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of certain specific embodiments of the invention. Furthermore, embodiments of the invention may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the inventions herein described.
Embodiments of the invention relate to a distributed system, termed herein, and “Internet Operating System” for connecting, or communicating with, a plurality of devices using a set of predefined rules contained in dynamic libraries. In one embodiment, each device uses a unique identifier to connect to an “edge server” which provides access into a trusted domain of the system. Within the trusted domain is a central registry that is configured to connect the edge server to a repository of software that is unique to each type, or manufacturer, of device. For example, if the device is a Toshiba® Model 123 video recorder, the central registry will connect the video recorder to software that is specific that particular model and brand of video recorder. The software can then be downloaded as an instruction file to the edge server and used to update or configure the video recorder. In one embodiment, the software is a set of macro-like instructions that are compiled in real-time on the edge server and then used to update or configure the video recorder. As can be envisioned, such a system allows a wide variety of devices, from a wide variety of vendors to be efficiently controlled.
Embodiments of the invention also relate to an Internet Operating System that is configured to define trigger rules and responses in a plurality of devices. The trigger rules are run in response to an event being triggered with a device while a the responses define the proper action to take once the event has been triggered. The IOS also is configured to allow users to store and manipulate a set of rules relating the interactions between various devices using a set of predefined, or user defined, rules contained in dynamic libraries. In one embodiment, each device uses a unique identifier to connect to an “edge server” which provides access into a trusted domain of the system. Within the trusted domain is a central registry that is configured to allow the edge server to download software from a repository of software that is unique to each type, or manufacturer, of device and to download execution logic that specifies a set of rules amongst the devices. For example, if one device is a Toshiba® Model 123 video recorder, and another device is a Mitsubishi® Model 321 video recorder the central registry will identify the proper software to download to the edge servers to expose each video recorder to other users and devices registered in the IOS. Authorized users or other devices in the system can then specify interaction rules for dynamic links between the devices and also specify the events that will trigger the interactions and the device's responses to the interactions. Once the rules are defined, the devices are capable of autonomously interacting with one another without human intervention.
In one embodiment, the software is a set of macro-like instructions that are compiled in real-time on the edge server when a trigger occurs to execute rules allowing interaction between the video recorders. Interaction rules can be specified between devices and other devices, or between devices and users, or between users and users. Users can be humans, or software application programs such as Inventory systems or customer resource systems. As can be envisioned, such a system allows a wide variety of devices, from a wide variety of vendors to efficiently and autonomously interact.
In one embodiment, a user can store their own software instructions that can be used to define the interactions between devices that they own. For example, a user may log into the system and store commands that instruct the video recorder to send the user an email indicating that the recorder has started to record a program. The user would log into the system and use a user interface to store commands that would autonomously detect when the video recorder had started to record a program, and then send an email to a particular email address in response. This software would be dynamically be downloaded to the edge server that was attached to the video recorder. This and other embodiments of the system will be described in more detail below.
The Internet Operating System (IOS) 100 is preferably a trusted domain with a plurality of Global Mobility Edge Servers (GLOMEs) 114 at its edge, wherein users and devices interface with the IOS 100 through an individual GLOME 106. Each GLOME 106 communicates with each other and other elements of the IOS 100 using an internal bus 312. The GLOMEs range from large systems (GLOME Switches) for use in metropolitan areas to small systems, such as GLOME HUBS deployed in a small office. In one embodiment, the functionality of the GLOMEs is the same no matter what their size is. The type of access a user makes to the GLOMEs 106 may depend on the type of user. Certain users may interface with a GLOME using HTTP or wireless protocols such as WAP, SMS and MMS. They may also interact with the GLOMEs using XML based languages, such as VoiceXML which originates from an Intelligent Voice Recognition System. External application programs may interface with the IOS 100 through a GLOME that supports XML and BPEL based protocols. Devices interact with the IOS 100 via programmable object devices (PODs) that are stored on the device. Devices can also interact with GLOMES using a remote Software Entity, wherein they connect into a GLOME through another device.
The GLOMEs 106 connect with external networks such as Wireless Access Networks 102, Cable Access Networks 103, Corporate LANs 105 and the Internet 143 using protocols such as TCP/IP and SMS. The GLOMEs 114 are connected to multiple entities within the IOS 100, including a Global Virtual Registry 115 which comprises an Object Global Virtual Registry 107 and Internet Global Virtual Registry 108. The Global Virtual Registry 115 is configured to store information for all of the users and devices in communication with the IOS 100. Of course, it should be realized that many different Global Virtual Registries could be used within the system as well as stand alone Object Global Virtual Registries 107 and Internet Global Virtual Registries 108. New Object Entries for objects new to the IOS 100, and new user entries for users that are new to the IOS 100, are created in the object global virtual Registry 107 and the Internet global virtual registry 108, respectively, using a Provisioning System 113. The provisioning system 113 includes the software and data storage required to load and maintain new users within the system 100.
The GLOMEs 106 are also in communication with multiple Library Repositories 116, including a POD Library Repository 109, a Device Library Repository 110, a Lynx Library Repository 111, an Internet Object Icon Library Repository 117, and an Internet Object connection library repository 112. The Library Repository 116 can be a series of repositories that are physically located in separate geographic locations.
The GLOME 106 also comprises a Local Virtual Registry module 205 configured to cache recent results from global virtual registry queries and cache transient data associated with individual transactions, wherein the global virtual registry queries are performed by an Application Gateway Control Protocol (AGCP) module 206 configured to use AGCP to query the global virtual registries 115. The network interface 208 is configured to facilitate communication with the library repositories 116 and Global Virtual Registries 115, and may be based on standard TCP/IP, for example.
When Device 313 generates a message via POD 300A, the GLOME 106A interprets the messages by looking in its message Mapping Table 203 for the POD Identifier 401 and Message Number 2401 and dynamically places the proper libraries 308, 309 to be used in its Library Execution Engine 202. The Libraries 308, 309 contain execution logic that is used to process the message sent from the device 313. The libraries 308, 309 are lodged at the library socket 201 of the GLOME 106, as illustrated in
The illustrated POD WCP Encoder Decoder and Arbitration Function 400 further comprises a GLOME attachment address field 407 configured to store an initial address for the GLOME 106 the POD 300 will attach to or communicate with when it is first activated. The POD WCP Encoder Decoder and Arbitration Function 400 also includes an authentication function 408, configured to correspond with the authentication function 209 at the GLOME 106 with which the POD will attach to or communicate. The POD WCP Encoder Decoder and Arbitration Function 400 can also include a JAVA object 406 which will allow additional software to be loaded on the POD to augment the existing POD software that was designed for the standard off-the-shelf controller the Pod is emulating.
In one embodiment, the JAVA Object 406 dynamically converts a POD into an Intelligent POD (IntelliPOD) allowing the POD to be proactive and enabling it to plan ahead and take initiative rather than waiting to be instructed what to do. It can also detect favorable situations that serve the devices goal and inform the GLOME 106 server when they occur. In one embodiment, the JAVA Object 406 also allows the IntelliPOD to be responsive to changing circumstances enabling it to be aware of its environment, and functioning appropriately and in a timely manner when encountering exceptional circumstances.
In another embodiment, the JAVA Object 406 also allows the IntelliPOD to be trainable, giving it the ability to modify its future behavior based on past executions, so improving its effectiveness over time. For example, the IntelliPOD may learn a vending machines usage pattern and modify how often it creates and sends reports to focus on busy times thus improving its level of support for monitoring the vending machine. In another embodiment, the JAVA Object 406 can allow the IntelliPOD to be capable of building dynamic relationships thereby allowing it to interact with other IntelliPODs in a very flexible manner. The also allows IntelliPODs to dynamically set up rules by posing as an IOS user. The interfaces and relationships among IntelliPODs need not be fixed, but can change dynamically just as the tasks and business driver's change. IntelliPODs can form temporary groups in order to co-operate to achieve a task or solve a problem. The interfaces, terms and conditions among these IntelliPODs can be negotiated dynamically. IntelliPODs can interact directly with one another via WCP over standard Internet Protocol (IP) communications. These IntelliPOD embodiments can be used individually or in conjunction within a POD.
The unique identity information 401, 402 for each POD 300 is also stored at the Object global Virtual Registry 107.
As discussed above, users such as individuals and business processes can access POD enabled devices over the IOS 100. Information identifying and relating to these users is stored in the Internet Global Virtual Registry (I-GVR) 108 (
Each POD in the IOS has a unique record in the O-GVR. These records are shown in
When a trigger condition occurs in one of the PODs 300, it generates a WCP Data Message 2600 containing the Message Number 2401 and its unique POD Identifier 401. The Message Record 906 contains the composition of the libraries needed to process the message and is stored in the GLOME 106 Message Mapping Table 203.
When the GLOME 106 receives a WCP Trigger Message 3800 it searches the MSG POD Records 2300 in the Message Mapping Table 203 based on the POD Identifier 401. When the MSG POD Record 2300 is found, the Message Record 906 is searched for the matching Message Number 2401. When the proper MSG Record 906 is found, the GLOME 106 knows which libraries to fetch to run in its Library Engine 202.
A user can also generate an incoming message. The GLOME 106 then searches the MSG User Records 2202 in its message Mapping Table 203 based on the User Identifier 701. When the matching MSG User Record 2202 is found, the Message Records 906 are searched for the matching Message Number 2401. When the proper MSG Record 906 is found, the GLOME 106 knows which libraries to fetch to run in its Library Engine 202. Messages can also enter the GLOME from the IOS for delivery to PODs or users.
When a GLOME receives an incoming Result Message 3700 message from the internal IOS Bus 312 it checks the POD Identifier 3702 field for a non-null and valid Pod Identifier 401. If the POD Identifier is valid and non-null, the GLOME searches the IOS POD Records 2203 in its message Mapping Table 203 based on the POD Identifier 401. When the matching IOS POD Record 2203 is found, the Message Class List 4302 is searched using the Message Class 3704 from the Result Message 3700. When the proper Message Class Record 4302 is found, the GLOME knows which Libraries 4303,4304 to fetch from its Library Engine 202.
The GLOME 106 also checks the User Identifier 701 in the Result Message 3700 for a non-null and valid user identifier. If the User Identifier 701 is valid and non-null, the GLOME searches the IOS User Records 2204 in its message Mapping Table 203 based on the User Identifier 701. When the matching IOS User Record 2204 is found, the Message Class List 4102 is searched using the Message Class 3704 from the Result Message 3700. When the proper Message Class Record 4102 is found, the GLOME knows which Libraries 4103,4104 to fetch for its Library Engine 202.
If the GLOME cannot find a message in its Message Table, it queries the I-GVR 108 using the User Identifier 701 if the message is from or to a user and the O-GVR using the POD ID 401 if the message is to or from a POD.
Since the same triggers rules with the same set of parameters in a POD could be set by different user or Lynx Libraries, there can be multiple MSG Numbers 2401 owning the same set of parameters.
Programmable Object Devices
Programmable Object Devices (PODs) are small control devices and come in four versions; a remote POD (rPOD) that has physical wire interfaces, a Virtual Software POD vPOD, a microcontroller replacement POD (MicroPOD) as shown in
Wireless PODs can communicate wirelessly through the existing wireless access network 102 eliminating the need to purchase expensive private radio systems or deploy bulky cabling and wiring. Wireless PODs communicate to a GLOME 106 through an external wireless network 102 using the WCP Encoder Decoder and Arbitration Function 1402 and industry standard components imbedded in or external to the POD. The industry standard components which are fabricated on the pin compatible MicroPOD include the base band component 3602 which modulates the signal, the RF Component 3601 which converts the modulated signal to an RF signal, and the Filters and Oscillators 3600 which filter the RF signals and amplify them. The Antenna 3604 then attaches to the Filters and Oscillators 3600. PODs that connect to GLOMEs 106 via wired access networks such as 103, 104 and 105 do not require the components 3600,3601,3602 and 3604. They instead connect to the wired network directly via the the WCP Encoder Decoder and Arbitration function 1402. PODs typically contain the WCP Encoder Decoder and Arbitration function 1402. The WCP Encoder Decoder and Arbitration function 1402 contains the functions and capabilities shown in
PODs can be connected to devices to control and monitor signals, or as direct replacements for the microcontrollers or microprocessors that are already designed for use in the object. MicroPODs, when replacing microcontrollers and microprocessors appear to be identical to the devices that they replace in both cost and functionality, but have an additional capability of communicating through an embedded WCP Encoder Decoder and Arbitration Function to a GLOME 106 at the edge of the IOS. An example of the WCP Encoder Decoder and Arbitration Function for a MicroPOD is shown in
The Programmable Object Devices (PODs) can be used for applications ranging from home appliances to automotive diagnostics. Like a standard microcontroller, the POD has software definable parallel and serial ports and FLASH EPROM program store. Wireless versions of the POD can leverage off of the existing cellular network to send and receive short bursts of information using the Wireless Control Protocol (WCP) described in
Autonomously or when requested, PODs can transmit or receive short bursts of data from GLOMES 106 at the edge of the IOS 100. These short bursts of data are WCP Messages 4000. Since PODs need to communicate with GLOMES 106 over existing access networks and infrastructures 102, 103, 104, 105 there are several access options that a POD can be manufactured with. These include but are not limited to Basic Wireline/LAN, Basic Wireline/Modem, Basic Bluetooth, LAN/Ethernet, xDSL, Cable Modem, Modem, Residential Gateway, GSM, CDMA, TDMA, 802.11, WiMAX, HyperLAN 1 and 2, HomeRF, 3G, LMDS, MMDS, Broadband, GPS and Custom. PODS may also have additional Bluetooth and GPS capabilities included at manufacture time.
Object Browser
An Object Browser can consist of an IoConnect Library 2403 and standard HTTP browser PC 3400 as shown in
In one embodiment, the Object Browser supports web links and ObjectLinks. Weblinks link to web pages inside and outside of the IOS, while ObjectLinks link to POD imbedded Devices 313 in the IOS. The can be in a format like www.xxx.obj and are used to interact with objects in the network. Using weblinks and objectlinks, a user or intelligent POD can perform Object Searches, Phrase Searches, Attribute Searches and Directory Listing Searches. Connectivity searches can also be performed to graphically see how objects, users and sub-objects are interconnects and interrelated.
In one embodiment, the Object Browser allows the user or POD to search, modify and create new Shareware Libraries, Device Libraries, Connect Libraries, Lynx Libraries, and Private Libraries that are physically contained in the Library Repositories.
In one embodiment, the Object Browser allows the user to graphically display Libraries and generate linking rules and parameter mappings amongst them. In this case, the user will also be able to use a graphically based Internet/Object Icon (IoIcon) editor to make new intelligent Icons and rules templates when needed. Device Libraries will be pictorially displayed with a representation of Device to Message Class mapping and rules. The IoConnect Libraries will be pictorially displayed with a representation of existing protocols such as Wireless Application Protocol (WAP), and ASP to IOS mapping and rules. The user can use an easy Internet/Object Icon (IoIcon) editor to make new intelligent Icons and to generate WAP/ASP/etc. to standard object mappings and rules.
The Lynx Libraries will be pictorially displayed with a representation of interaction between devices and the capability to use Drag and Drop methods to connect and specify rules amongst POD imbedded Device and user. The Object Browser also provides graphical representation of Message Class 4102 to Message Class 4102 mapping for connecting and providing cascaded rules amongst Lynx Libraries 1800, Device Libraries 1900 and IoConnect Libraries 2100. The Object Browser also provides graphical representation of mapping to external protocols such as XML for external application programs and WAP protocol to wireless phone users. The Triggering rules and controllable parameters in Devices including event, alarm and trigger access points will be graphically represented along with picture quality graphical representations of the physical controls, displays and functions of the Device the POD is embedded in. The user will also be able to build relationships between devices, users and libraries using drag and drop capabilities coupled with the IoIcons. Some PODs may communicate directly amongst themselves using Bluetooth or WIFI without going through a GLOME 106 or the IOS. In this case the rule are graphically defined in the Object Browser.
In one embodiment, the Object Browser allows the user to chat with other users in closed communities. In one embodiment, the Object Browser allows the user to navigate through a virtual village of devices and user Icons (pictures) under their control and modify and interconnect the objects. In one embodiment, the Object Browser allows the user to navigate through a virtual village of devices and user Icons (pictures) that have been made visible to them by other users. In one embodiment, the Object Browser allows the user to navigate through a virtual village of devices and users Icons (pictures) that have been made visible and partially or fully modifiable by them by other users.
In one embodiment, the Object Browser allows the user to define which of their devices are viewable in various virtual communities, and which parameters are visible and modifiable by others in each community. In one embodiment, the Object Browser allows the user to enable or disable functionality of a device. For example, this capability could be used to remotely block Television stations from being viewable or disabling a car remotely. This can also be used by device manufacturer to upgrade device capabilities remotely when a device owner orders upgraded device functionality.
In one embodiment, the Object Browser allows the user to enable or disable functionality of a device. For example, this capability could be used to remotely block Television stations from being viewable or disabling a car remotely. This can also be used by device manufacturer to upgrade device capabilities remotely when a Device owner orders upgraded device functionality.
In one embodiment, the Object Browser allows a software vendor to remotely control a Software Object instead of a POD. This is used if the Device being controlled is licensed software and allows owners of software download sites to control licensing of products. In one embodiment, the Object Browser allows the user to create and/or join virtual communities of users and virtual cities composed of their devices and other devices and control other visible devices. In one embodiment, the Object Browser allows the user to create and/or join virtual communities of users and virtual cities composed of their devices and other devices and chat and exchange data with other users.
In one embodiment, the Object Browser allows the user to create and/or modify IoIcons representing their user mail and office systems interfaced via a GLOME and define the rules between these systems and their own Devices and users. In one embodiment, the Object Browser allows the user to create, set, monitor and/or modify Alarms in devices using Graphical Colored icons and graphically based rules/connection screens. In one embodiment, the Object Browser allows the user to create, set, monitor and/or modify Events in devices using Graphical Colored icons and graphically based rules pages to define event processing. In one embodiment, the Object Browser allows the user to create, set, monitor and/or modify Triggers in devices using Graphical Colored icons and graphically based representations of triggers to cause user or object rules to be executed. In one embodiment, the Object Browser allows the user to create, set, monitor and/or modify Parameter Controls in devices using Graphical Colored icons and graphically based IoIcon that look like the device with pull down menus.
In one embodiment, the Object Browser allows the user to upload download, and/or modify software in the Devices using a Drag and Drop Software download function. In one embodiment, the Object Browser allows the user to upgrade software in the Devices using a Drag and Drop Software upgrade function. This will typically be done by the Device Manufacturer user type to upgrade a Buyers device with more functionality after the device is bought. This will also be done by the POD manufacturer to update PODs in the field, and Device Manufacturers to install software during and after manufacturing.
User Account
During a PODs lifecycle, multiple Individual and business accounts will interact with the POD. These will typically include the POD Manufacturer, the Device Manufacturer, one or more Device Sellers and one or more Device Buyers. Each of these users will preferably have a user account. The user accounts are created in the Internet Global Virtual Registry (I-GVR) 108 and are placed in one of the I-GVR Records 602 using the provisioning system 113. The users will then be able to build libraries and interact with their PODs, other users PODs that are visible, and other users using an Object Browser portal that is connected through an IoConnect Library 2100 hosted in a GLOME's Library Socket 201.
When a new user including an Individual, External Application Software or Automaton signs up to use the IOS 100, the provisioning system 113 is used to create a new I-GVR Record 602 at the I-GVR 600. As illustrated in
POD Registration
During or after manufacture of a device, a POD is installed in the device in a step 2702. For the POD enabled device, a device manufacturer can use an IOS Portal to bind the POD 300 to the Device in a step 2703. This procedure modifies the existing O-GVR record 502 for the POD by updating the POD Record 902 to include a Current POD Library Link 1004 that specifies the proper POD library for the device in which the POD 300 is installed. The POD State Block 1003 is also set to Active with an Owner State of “Manufacturer”. Device information for the POD enabled device is stored in the Device Record 802, and may include the Identity of the Device 1201 which is typically a name, and the Serial Number and Version of the Device in the Device Information field 1203. The Device Class 1202 is also entered in the Device Record 802 to help identify the proper libraries to use with the device. The Device State Block 1204 is set to Manufacturer.
If the device is a piece of hardware, the Device State Block 1204 is set to Hardware. Software and digital Media such as Music, videos, etc can also be tracked with the IOS. In the case of a software device, the Device State Block indicates Software instead of Hardware. Also, there is no POD associated with the Software/Digital Media, only a serial number. The POD Identifier 901 therefore is used only as a key in the O-GVR and does not refer to an actual piece of hardware. A link to the Proper Device Library is entered in the Current Device Library Field 1205 and a link to the IoIcon Library is entered in the IoIcon Link 803. The Device Manufacturer also adds their I-GVR link 1101 to the I-GVR List Record 905.
When the POD enabled device is turned on or powered up, the POD registers with the GLOME 106 identified in the GLOME Attachment Address 407 via an access network 102, 103, 104, 105 in a step 2704. The POD 300 transmits the POD Identifier 401, and the POD Authentication Key 402. The Local Virtual Registry module 205 and AGCP module 206 at the GLOME 106 are used to query the O-GVR 107 using the POD Identifier 401. In response to the query, the O-GVR 107 returns the O-GVR record 502 for the POD 300. The GLOME 106 may use a standard RAND authentication algorithm to authenticate the POD Authentication Key from the POD record 902 against the Authentication Key from the POD 300 using the Authentication Function 209 at the GLOME 106 and the Authentication Function 408 at the POD 300.
Once the POD is authenticated, the O-GVR 107 stores the attachment GLOME's IP address 407 in the O-GVR record 502 and changes the POD State Block 1003 to Active—Manufacturer. The GLOME 106 also retrieves the POD Library 303 defined in the current POD Library 1004 from the POD Library Repository 109, and downloads the library to the POD Library Socket 403 in the POD 300. The device manufacturer may want to use the POD to test the device 300 in a step 2706. The device manufacturer may use their Portal to download testing software to the POD 300, and the testing software is loaded in the POD Software Object 404, and the Device State Block 1204 at the device record 802 is set to testing.
Following device testing in step 2706, the device is shipped to the device seller's warehouse for sale in a step 2707. The Device Seller changes the Device State Block 1204 in the device record 802 using their portal in a step 2708. A link to the sellers I-GVR record will be included in the I-GVR Seller Link field 1102. Additional information on the Seller can be included in the Additional Information Field 1105 of the I-GVR List Record 905. When the seller sells the device to a buyer 2709, the seller changes the Device State Block 1204 in the device record 802 to Buyer and adds the Buyer's I-GVR Link 1103 to the I-GVR List Record 905 if the Buyer has an IOS account. The Buyer can now log into their portal and interact with the device 300 via the imbedded POD. The Device Manufacturer can also interact with the device via their portal to collect statistics and upgrade software.
Using the Object Browser to Set up Dynamic Interaction Relationships
Once the users in the IOS 100 have accounts (I-GVR Records), the IOS 100 enables them to interact with each other and devices using a set of rules. A set of rules is specified for each interaction between Individuals, External application programs, and devices in the IOS. These rules are stored in libraries. These libraries include POD Libraries 2000 which are downloaded from the POD Library Repository 109 and installed at PODs 300 to mediate between devices and PODs; Device Libraries 1900 which are dynamically downloaded to GLOMEs 106 from the Device Library Repository 110 and used to mediate between devices and Lynx Libraries; Lynx Libraries 1800 which are dynamically downloaded to GLOMEs 106 from the Lynx Library Repository 111 to mediate between devices, users, or other Lynx Libraries; and IoConnect Libraries 2100 which are dynamically downloaded to GLOMEs 106 from the IoConnect Library Repository 112 and used to mediate between Lynx Libraries and individual users or external application programs. The POD Libraries are typically defined by the POD or device manufacturer, the Device Libraries are typically defined by the device manufacturer, the IoConnect Libraries are typically defined by the IOS service provider, and the Lynx Libraries are typically defined by the individual user.
When two or more users in the IOS 100 interact, they do so through the GLOMEs 106 to which they are attached. These GLOMEs dynamically download the proper libraries associated with the users according to their I-GVR Record 602 to allow the interaction when a user generates a message.
Based on the User Type 704 and Browser IoConnect Library Link 707, stored in the I-GVR record 602, the GLOME 106 checks the Library Cache 204 for the proper IoConnect Library for the User Type. If the library designated in the library link 70 is not in the library cache 204, the GLOME 106 retrieves the Browser IoConnect library from the IoConnect Library Repository 112 in a step 2813.
For each O-GVR List Record 705 in the I-GVR Record 700, the GLOME 106 retrieves the POD's O-GVR record 502 from the O-GVR 107 using the POD Identifier 401 in a step 2814. This ensures that the most current states of all PODs are provided to the user 2800. The GLOME 106 also fetches the IoIcon Libraries specified in the IoIcon Link 803 of each O-GVR List Record 705 from the IoIcon Library Repository 117 in a step 2815. The GLOME 2801 also fetches the Lynx Libraries specified in the Lynx Library List 708 from the Lynx Library Repository 111. The Lynx Libraries can be public or uniquely built and owned by the user 2800. If the user 2800 has subscribed to statistics database 118 or watcher status 119, the links to the repositories for this information are retrieved from the fields 804 and 805.
Once the libraries are fetched, the IoIconnect (browser) and IoIcon library logic is moved to the GLOME's Library Engine 202 for generation of a graphic user interface (GUI), such as a web page, that presents an Object Browser to the user 2800 in a step 2816. The Object Browser displays the status of all the PODs, devices, and users associated with the Individual User's Account using predetermined icons, such as graphical 3D Icons retrieved from the IoIcon Library. In one embodiment, substantially all parameters that can be monitored or controlled in each POD enabled device are displayed as a sub-icon of the device icon as it physically appears in the device and can be selected (clicked on) to modify or drop and dragged to couple with other physical devices (or controls).
For example a DVD player is displayed graphically as a virtual 3D DVD player with knobs, buttons, and displays, and an automobile will appear as a 3D automobile that can be rotated to view the dash or with its hood opened. If the user 2800 wants to make a new set of rules relating between the DVD player and the automobile, they can do so by dragging and dropping the relevant components from one device to another (or the same device) and establishing rules in a step 2817. For example, the user 2800 may want the DVD player to start playing a movie when the car is started. To implement this rule, the user 2800 drags a sub-icon representing starting the car, such as a key sub-icon in the car icon, over the power button sub-icon on the DVD player icon. In response to the overlay of the car start sub-icon over the DVD player power button sub-con, the Object Browser displays a rule screen, wherein the user 2800 can specify that the power is to be turned on when the key is turned on by selection of predefined parameters, for example. Then the user 2800 drags the DVD power button sub-icon over the DVD play button sub-icon, and selects a rule corresponding to the instruction that the DVD player start playing when its power is turned on.
Once the user 2800 has defined one or more rules for their associated devices, the IoConnect Library, which is acting as the Object Browser, generates a new Lynx Library with the new rules, and this new Lynx Library is stored in the Lynx Library Repository 111 with a unique name in a step 2818. The new Lynx Library is also added to the Lynx Library list 708 in the user's I-GVR Record 602 at the I-GVR 108 in a step 2826. For each POD enabled device affected by the new rules, the IoConnect Library acting as an Object Browser, generates a set of trigger rules and a message number based on the new rules in the new Lynx Library. In one embodiment, the message number for each individual POD is one greater than the highest message number 2401 already stored in the MSG Record 2400 for that POD. Existing trigger rules that are changed or removed, will be flagged to be removed in the Message Record 906 in the O-GVR Record 502 and will be published to the GLOME 106 servicing the respective POD.
The GLOME 106A stores the new Message Record 906 at its O-GVR Record 502. The GLOME 106A then uses the Application Gateway Control Protocol (AGCP) Interface 206 to send an update to the O-GVR 107 with the POD identifier 401, updated O-GVR Record 502, and an encapsulated WCP Trigger Message 3800 (
The O-GVR 107 knows which GLOME 106B to forward the message to based on the GLOME attachment address 402 at the O-GVR record 502 for the POD 300 in a step 2820. The messaging from the O-GVR 107 to GLOME 106B for the Encapsulated WCP Trigger Message 3800 is performed using a Result Message 3700 with a MSG Class 3704 set to “WCP Trigger Message” (
The GLOME 106B can update its Message Mapping Table 203 in a step 2821 upon receipt of the Result Message 3700, or wait until a new trigger is generated by the POD 300 when its sends a WCP Data Message 2600 to its associated GLOME 106B, which will check its MSG Mapping Table 203 for the new message number from the POD 300. If the number is not in the Mapping Table 203, the GLOME 106B queries the O-GVR 107 based on the POD Identifier 401.
POD to User Interaction
Upon receipt of the WCP Message 4000 at the GLOME 106B, the unencrypted POD Identifier 401 (or Temporary POD Identifier) in the Encryption Information Field 4003 is used to look up the MSG POD Record 2300 in the Message Mapping Table 203 using the POD Identifier 401 in a step 2910. If the message had come from an Individual user or external application Program, the GLOME 106B would search the MSG User Records 2202 in the message mapping table 203. If the POD 300 has a record 2300 in the Message Mapping Table 203, the WCP Message 4000 is de-encrypted using the Authentication Function 209 and the Authentication Key 402 for the POD 300 that is stored in the Local Virtual Registry Function 205 of the GLOME 106B. The GLOME 106B then searches the MSG POD Record 2300 for the Message Record 2303 using the Message Number 2401 specified in the Message Number Field of the WCP data message 2600.
The Message Record 2303 identifies one or more Libraries IDs 2402, 2403 which correspond to the Libraries needed to process the WCP data message 2600. In one embodiment, the order of the Library IDs 2402, 2403 in the message record 2303 specifies the order that the libraries are placed in the GLOME Library Sockets 201 for use by the library engine 202. The libraries may be device libraries or lynx libraries, for example. In this example, the Destination User ID 2405 designates the end user 2900 for receipt of information in response to the trigger event. If the destination is a POD instead of a user, the Destination POD ID 2404 contains a POD Identifier 401 for the Destination POD. The Destination POD ID 2404 may be blank when the destination is an Individual user and not a POD. The GLOME 106B checks its Library Cache 204 to see if the device libraries specified by the Library Ids 2402 are there. If not, the GLOME 106B retrieves the library specified by the Library IDs 2402 using the Application Query Language function 207 in a step 2912. In one embodiment, Application Query Language is the same as SQL except it is optimized for retrieving execution logic (libraries). The GLOME 106B also checks if the Lynx Library identified by Library ID 2403 is stored in the GLOME 106B Library Cache 204 in a step 2913 and retrieves the Lynx Library from the Lynx Library repository 111 in a step 2914 if not in the cache 204. Since all Library IDs are unique, the Library IDs 2403 specify the Library Required.
Once the GLOME 106B has retrieved all of the libraries, the Library Engine 202 executes the libraries using the parameters 2603 passed in the WCP Data Message 2600 in a step 2915 and communicates the result in a result message 3700 to one or more destination GLOMEs 106A, as specified in the Destination User ID field 2405 of the MSG Record 2400, in a step 2916. The Result Message 3700 will contain the Destination GLOME Identifier 3701 and the Individual User Identifier 701 of the Destination User. The Message Class Field 3704 contains the Output Class 1803 specified by the last Lynx Library 2403 in the MSG Record 2303.
The GLOME 106B removes the libraries from the Library Engine 202 following execution, but continues to store the libraries and the authentication key 402 in its Library Cache 204 for later use until a specified time or until the library is explicitly removed. Since the Result Message 3700 is destined for an Individual User from the IOS, the Destination GLOME 106A checks the IOS User Record 2204 in its Message Mapping Table 203 in a step 2917 for the User Identifier 701 specified in the Result Message 3700. When the IOS User Record 2204 is found, the GLOME 106A searches for the record with the MSG Class 4102 as described in
Once all of the triggers have occurred and the libraries are retrieved (if not cached) in step 2919, the libraries are executed on the Library Engine 202 at the GLOME 106A in a step 2930. The message generated in response to the execution of the libraries is communicated to the user 2900 in a step 2931 using the destination User Identifier 701 specified in the Result Message 3700, and the receipt of the message is acknowledged to the GLOME 106A in a step 2932. The acknowledgment is communicated to the GLOME 106B in a step 2933, and to the POD 300 in a step 2936.
If a GLOME does not have a record in the Message Mapping Table 203, the GLOME 2908 uses the POD Identifier 401 contained in the Encryption Info Field 2703 to Query 2911 the O-GVR 2903 associated with the POD. The O-GVR will download the O-GVR record 900 for the POD to the GLOME where it will be placed in the Local Virtual Registry Function 205 of the GLOME. This query and response can be performed using the Application Gateway Control Protocol 206 function in the GLOME 106B. The GLOME 106B will then store the Message Records 906 for the POD 300 in the Message Mapping Table 203 as a Message Record 2400 and the Authentication Key 402 in the GLOME's Local Virtual Registry 205.
POD to POD Interaction
Upon receipt of the WCP Message 4000 at the GLOME 3007, the unencrypted POD Identifier 401 (or Temporary POD Identifier) in the Encryption Information Field 4003 is used to look up the MSG POD Record 2300 in the Message Mapping Table 203 using the POD Identifier 401 in a step 3010. If the message had come from an Individual User or External application Program, the GLOME 3007 would search the MSG User Records 2202 in the message mapping table 203. If the POD 3008 has a record 2300 in the Message Mapping Table 203, the WCP Message 4000 is de-encrypted using the Authentication Function 209 and the Authentication Key 402 for the POD 3008 that is stored in the Local Virtual Registry Function 205 of the GLOME 3007. The GLOME 3007 then searches the MSG POD Record 2300 for the Message Record 2303 using the Message Number 2401 specified in the Message Number Field of the WCP data message 2600.
The Message Record 2303 identifies one or more Libraries IDs 2402, 2403 which correspond to the Libraries needed to process the WCP data message 2600. In one embodiment, the order of the Library IDs 2402, 2403 in the message record 2303 specifies the order that the libraries are placed in the GLOME Library Sockets 201 for use by the library engine 202. The libraries may be device libraries or lynx libraries, for example. In this example, the Destination User ID 2405 is empty anf the Destination POD ID 2404 designates the POD 3000 for receipt of information in response to the trigger event. The GLOME 3007 checks its Library Cache 204 to see if the Device libraries specified by the Library Ids 2402 are there. If not, the GLOME 3007 retrieves the library specified by the Library IDs 2402 using the Application Query Language function 207 in a step 3012. In one embodiment, Application Query Language is the same as SQL except it is optimized for retrieving execution logic (libraries). The GLOME 3007 also checks if the Lynx Library identified by Library ID 2403 is stored in the GLOME 3007 Library Cache 204 in a step 3013 and retrieves the Lynx Library from the Lynx Library repository 111 in a step 3014 if not in the cache 204. Since all Library IDs are unique, the Library IDs 2403 specify the Library Required.
Once the GLOME 3007 has retrieved all of the libraries, the Library Engine 202 executes the libraries using the parameters 2603 passed in the WCP Data Message 2600 in a step 3015 and communicates the result in a result message 3700 to one or more destination GLOMEs 3001, as specified in the Destination POD ID field 2404 of the MSG Record 2400. The Result Message 3700 will contain the Destination GLOME Identifier 3701 and the Individual POD Identifier 401 of the Destination POD. The Message Class Field 3704 contains the Output Class 1803 specified by the last Lynx Library 2403 in the MSG Record 2303.
The GLOME 3007 removes the libraries from the Library Engine 202 following execution, but continues to store the libraries and the authentication key 402 in its Library Cache 204 for later use until a specified time or until the library is explicitly removed. Since the Result Message 3700 is destined for a POD from the IOS, the Destination GLOME 3001 checks the IOS POD Record 2203 in its Message Mapping Table 203 in a step 3016 for the POD Identifier 401 specified in the Result Message 3700. When the IOS POD Record 2203 is found, the GLOME 3001 searches for the record with the MSG Class 4102 as described in
Once all of the triggers have occurred and the Libraries are retrieved (if not cached) in step 3018, the libraries are executed on the Library Engine 202 at the GLOME 3001 in a step 3019. The message generated in response to the execution of the libraries is communicated to the POD 3000 in a step 3020 using the destination POD Identifier 401 specified in the Result Message 3700, and the receipt of the message is acknowledged to the GLOME 3001 in a step 3021. The acknowledgment is communicated to the GLOME 3007 in a step 3022, and to the POD 3008 in a step 3023.
If a GLOME does not have a record in the Message Mapping Table 203, the GLOME 3007 uses the POD Identifier 401 contained in the Encryption Info Field 2703 to Query 3011 the O-GVR 3003 associated with the POD 3008. The O-GVR will download the O-GVR record 900 for the POD to the GLOME 3007 where it will be placed in the Local Virtual Registry Function 205 of the GLOME 3007. This query and response can be performed using the Application Gateway Control Protocol 206 function in the GLOME 3007. The GLOME 3007 will then store the Message Records 906 for the POD 3008 in the Message Mapping Table 203 as a Message Record 2400 and the Authentication Key 402 in the GLOME's Local Virtual Registry 205. A similar process may be required in GLOME 3001.
User to POD Interaction
Upon receipt of the message at the GLOME 3107, the user ID is used to look up the MSG User Record 2202 in the Message Mapping Table 203 using the User Identifier 701 in a step 3110. The message may be encrypted and will then be de-encrypted using the Authentication Function 209 and the User Identifier 701 and User Password 702 for the User that is stored in the Local Virtual Registry Function 205 of the GLOME 3107. The GLOME 3107 then searches the MSG User Record 2202 for the Message Record 2303 using the Message Number 2401 specified in the message from the user.
The Message Record 2303 identifies one or more Library IDs 2402, 2403 which correspond to the libraries needed to process the parameters passed by the user. In one embodiment, the order of the Library IDs 2402, 2403 in the message record 2303 specifies the order that the libraries are placed in the GLOME Library Sockets 201 for use by the library engine 202. The libraries may be IoConnect libraries or lynx libraries, for example. In this example, the Destination User ID 2405 is empty and the Destination POD ID 2404 designates the POD 3100 for receipt of information in response to the user initiated event. The GLOME 3107 checks its Library Cache 204 to see if the IoConnect libraries specified by the Library Ids 2402 are there. If not, the GLOME 3107 retrieves the library specified by the Library IDs 2402 using the Application Query Language function 207 in a step 3112. In one embodiment, Application Query Language is the same as SQL except it is optimized for retrieving execution logic (libraries). The GLOME 3107 also checks if the Lynx Library identified by Library ID 2403 is stored in the GLOME 3107 Library Cache 204 and retrieves the Lynx Library from the Lynx Library repository 3105, 111 in a step 3113 if not in the cache 204. Since all Library IDs are unique, the Library IDs 2403 specify the Library Required.
Once the GLOME 3107 has retrieved all of the libraries, the Library Engine 202 executes the libraries using the parameters passed Message from the user and communicates the result in a result message 3700 to one or more destination GLOMEs 3101, in a step 3115 as specified in the Destination POD ID field 2404 of the MSG Record 2400. The Result Message 3700 will contain the Destination GLOME Identifier 3701 and the Individual POD Identifier 401 of the Destination POD. The Message Class Field 3704 contains the Output Class 1803 specified by the last Lynx Library 2403 in the MSG Record 2303.
The GLOME 3107 removes the libraries from the Library Engine 202 following execution, but continues to store the libraries and the authentication key 402 in its Library Cache 204 for later use until a specified time or until the library is explicitly removed. Since the Result Message 3700 is destined for a POD from the IOS, the Destination GLOME 3101 checks the IOS POD Record 2203 in its Message Mapping Table 203 in a step 3116 for the POD Identifier 401 specified in the Result Message 3700. When the IOS POD Record 2203 is found, the GLOME 3101 searches for the record with the MSG Class 4102 as described in
Once all of the triggers have occurred and the Libraries are retrieved (if not cached), the libraries are executed on the Library Engine 202 at the GLOME 3101 in a step 3120. The message generated in response to the execution of the libraries is communicated to the POD 3100 in a step 3121 using the destination POD Identifier 401 specified in the Result Message 3700, and the receipt of the message is acknowledged to the GLOME 3101 in a step 3122. The acknowledgment is communicated to the GLOME 3107 in a step 3123, and to the user 3108 in a step 3124.
If GLOME 3107 does not have a record in the Message Mapping Table 203, the GLOME 3107 uses the User Identifier 701 contained in the message from the user to Query 3111 the 1-GVR 3102 associated with the user 3108. The I-GVR will download the I-GVR record 602 for the user 3108 to the GLOME 3107 where it will be placed in the Local Virtual Registry Function 205 of the GLOME 3107. This query and response can be performed using the Application Gateway Control Protocol 206 function in the GLOME 3107. The GLOME 3107 will then store the Message Records 906 for the user 3108 in the Message Mapping Table 203 as a Message Record 2400 and the User Password 702 in the GLOME's Local Virtual Registry 205.
If GLOME 3101 does not have a record in the Message Mapping Table 203, the GLOME 3101 uses the POD Identifier 401 contained in the Result Message 3700 to Query 3117 the O-GVR 3103 associated with the POD 3100. The O-GVR will download the O-GVR record 900 for the POD 3100 to the GLOME 3101 where it will be placed in the Local Virtual Registry Function 205 of the GLOME 3101. This query and response can be performed using the Application Gateway Control Protocol 206 function in the GLOME 3101. The GLOME 3101 will then store the Message Records 906 for the POD 3001 in the Message Mapping Table 203 as a Message Record 2400 and the Authentication Key 402 in the GLOME's Local Virtual Registry 205.
One POD to Many POD Interaction
Upon receipt of the WCP Message 4000 at the GLOME 3207, the unencrypted POD Identifier 401 (or Temporary POD Identifier) in the Encryption Information Field 4003 is used to look up the MSG POD Record 2300 in the Message Mapping Table 203 using the POD Identifier 401 in a step 3210. If the message had come from an Individual User or External application Program, the GLOME 3207 would search the MSG User Records 2202 in the message mapping table 203. If the POD 3208 has a record 2300 in the Message Mapping Table 203, the WCP Message 4000 is de-encrypted using the Authentication Function 209 and the Authentication Key 402 for the POD 3208 that is stored in the Local Virtual Registry Function 205 of the GLOME 3207. The GLOME 3207 then searches the MSG POD Record 2300 for the Message Record 2303 using the Message Number 2401 specified in the Message Number Field of the WCP data message 2600.
The Message Record 2303 identifies one or more Libraries IDs 2402, 2403 which correspond to the Libraries needed to process the WCP data message 2600. In this case, the Message Record 2303 has two records for the same Message Number 2401 meaning that there are two receivers for this message number. The GLOME 3207 must process the parameters 2603 in passed in the WCP Data Message 2600 in a step 3212 for both records using the Library IDs 2401 and Destination POD ID 2404 in each record individually.
If the GLOME 3207 needs to query the O-GVR or get libraries as described in the examples above for each of the destination GLOMEs, it does this in a step 3211.
Once the GLOME 3207 has retrieved all of the libraries, the Library Engine 202 executes the libraries specified in the first entry of the MSG Record 2400 using the parameters 2603 passed in the WCP Data Message 2600 in a the step 3212 and communicates the result in a result message 3700 to the destination GLOME 3203, as specified in the Destination POD ID field 2404 of the first entry of the MSG Record 2400 in a step 3313. The Result Message 3700 will contain the Destination GLOME Identifier 3203 and the Individual POD Identifier 401 of the Destination POD 3202. The Message Class Field 3704 contains the Output Class 1803 specified by the last Lynx Library 2403 in the MSG Record 2303.
The Library Engine 202 next executes the libraries specified in the second entry of the MSG Record 2400 using the parameters 2603 passed in the WCP Data Message 2600 in a the step 3212 and communicates the result in a result message 3700 to the destination GLOME 3202, as specified in the Destination POD ID field 2404 of the second entry of the MSG Record 2400 in a step 3314. The Result Message 3700 will contain the Destination GLOME Identifier 3203 and the Individual POD Identifier 401 of the Destination POD 3202. The Message Class Field 3704 contains the Output Class 1803 specified by the last Lynx Library 2403 in the MSG Record 2303.
The GLOME 3007 removes the libraries from the Library Engine 202 following execution, but continues to store the libraries and the authentication key 402 in its Library Cache 204 for later use until a specified time or until the library is explicitly removed.
The GLOME 3203 will process the 3700 message delivered in step 3213 in the normal fashion by checking its message mapping table 203, getting the libraries if needed in a step 3315, running the library logic on the Library Engine is a step 3216, and delivering the message to the destination POD 3201 in a step 3217. The POD 3201 will acknowledge to the GLOME 3203 in a step 3223 and the GLOME 3203 will pass an acknowledgement to the GLOME 3207. Since the GLOME 3207 remembers that there was more than Result Message 3700 sent out for this transaction, it will wait for an acknowledgement from GLOME 3203 before sending an acknowledgement to POD 3208.
The GLOME 3201 will process the 3700 message deliverd in step 3214 in the normal fashion by checking its message mapping table 203, getting the libraries if needed in a step 3218, running the library logic on the Library Engine is a step 3219, and delivering the message to the destination POD 3200 in a step 3220. The POD 3200 will acknowledge to the GLOME 3202 in a step 3221 and the GLOME 3202 will pass an acknowledgement to the GLOME 3207. Since the GLOME 3207 remembers that there was more than Result Message 3700 sent out for this transaction, it has been waiting for the acknowledgement. It can now send an acknowledgement to POD 3208 in a step 3226.
Many PODs to One POD Interaction with Waiting
The POD 3308 sends a WCP message to the GLOME 3306 when a trigger occurs as described above. The GLOME 3306 checks its Message Mapping Table in a step 3310 and runs its library engine on the resulting libraries in a step 3311 as described previously. It is assumed that the proper libraries are already in its Library Cache 204. It then forwards a Result Message 3700 to the Destination GLOME 3301 in the standard way. The GLOME 3301 checks its Message Mapping table on the incoming message in a step 3313, and runs its library engine in a step 3314. In this case the logic of one of the libraries specifies another input result must be received before execution can proceed, so the GLOME 3301 waits for further inputs in a step 3315. The library specifies the Result Message(s) 3700 that are required before it can proceed. Since Result Messages contain the POD Identifier 401 or User Identifier 701 of the Destination as well as the Message Class 4102, the GLOME 3301 knows which messages to wait for.
Soon the POD 3307 sends a WCP message to the GLOME 3305 when a trigger occurs as described above. The GLOME 3305 checks its Message Mapping Table in a step 3317 and runs its library engine on the resulting libraries in a step 3318 as described previously. It is assumed that the proper libraries are already in its Library Cache 204. It then forwards a Result Message 3700 to the Destination GLOME 3301 in the standard way. The GLOME 3301 checks its Message Mapping table on the incoming message in a step 3319 and realizes that it is waiting for this message to complete a previously initiated transaction. The GLOME now runs its library engine in a step 3320 using the parameters from both messages as inputs and sends the result to the POD 3300. The POD 3300 acknowledges in a step 3322 and the GLOME 3301 sends acknowledge messages to both GLOMEs 3305 and 3306 in steps 3323 and 3325 respectively. The GLOMEs 3307 and 3308 send acknowledgements to their respective PODs in steps 3324 and 3326.
This application claims priority to U.S. Provisional Patent Application No. 60/569,224 entitled “INTERNET OPERATING SYSTEM” and filed on May 7, 2004. The disclosure of the above-described application is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
60569224 | May 2004 | US |