WO2002087178A1 - Systeme et procede de transmission d'informations entre emplacements sur un reseau informatique - Google Patents

Systeme et procede de transmission d'informations entre emplacements sur un reseau informatique Download PDF

Info

Publication number
WO2002087178A1
WO2002087178A1 PCT/US2002/012589 US0212589W WO02087178A1 WO 2002087178 A1 WO2002087178 A1 WO 2002087178A1 US 0212589 W US0212589 W US 0212589W WO 02087178 A1 WO02087178 A1 WO 02087178A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
data
packet
master
format
Prior art date
Application number
PCT/US2002/012589
Other languages
English (en)
Inventor
Diane L. Peterson
Original Assignee
Atitania Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/841,135 external-priority patent/US6950437B2/en
Priority claimed from US09/841,425 external-priority patent/US6801531B1/en
Application filed by Atitania Ltd. filed Critical Atitania Ltd.
Priority to EP02728880A priority Critical patent/EP1410586A1/fr
Publication of WO2002087178A1 publication Critical patent/WO2002087178A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H04L69/085—Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks

Definitions

  • This invention is related to data processing systems and their architecture. In one aspect, it relates to a network component for retransmitting data packets in accordance with ID codes embedded therein in a distributed manner.
  • classification databases One common way to create a search/classification system for specific products is to access and use government and/or industry specific classification systems (i.e., classification databases).
  • classification databases no existing classification database is comprehensive enough to address all the issues associated with building a classification system. These issues include: uniform numbers for products that cross multiple industries, restricting products from inclusion in classification, and non-usage of slang or industry standard language to access or classify products.
  • the classification databases frequently do not address all the products, thus resulting in inconsistencies even when companies use the same classification system.
  • companies could use the automatically- generated identification codes in place of their existing identification codes.
  • the use of the automatically-generated identification codes can be phased-in gradually as the of user base expands.
  • companies create search engines by developing hierarchies and families of products. They may create a thesaurus to encompass slang words. Companies often use drop down menus, keywords and product description capabilities to enhance their systems. It is desired to classify the data in such a way as to minimize the responses generated by a search, and therefore more effectively guide the buyer through the system.
  • most exchanges offer barely adequate search capabilities for their buyers.
  • Another challenging data management task is the transmission of data between dissimilar systems. Even within the same corporate organization it is very common to find different system types, applications and/or information structures being used. Transmitting data between such systems can be a time-consuming and expensive task. Under current practices, data transfer between dissimilar systems is often facilitated by the use of customized software applications known as "adapters". Some adapters "pull" data, i.e., extract it from the source system in the data format of the host system or host application, convert the data into another data format (e.g., EDI) and then sometimes convert it again into yet another data format (e.g., XML) for transmission to the destination system.
  • EDI data format
  • XML yet another data format
  • adapters "push" data, i.e., convert the data from the transmission data format (e.g., XML) to an intermediate data format (e.g., EDI) if necessary, then convert it to the data format of the host system or application at the destination system, and finally loading the data into the destination system. All of these adapter steps are performed on the host systems using the host systems' CPU. Thus, in adapter-based systems, CPU load considerations may affect when and how often data pulls can be scheduled.
  • transmission data format e.g., XML
  • intermediate data format e.g., EDI
  • All of these adapter steps are performed on the host systems using the host systems' CPU.
  • CPU load considerations may affect when and how often data pulls can be scheduled.
  • Network routers are known which direct datapackages on a network in accordance with TD codes embedded in the data packets. However, these routers typically direct data packets between similar nodes on a single network. It is now becoming increasingly common to transmit data across multiple networks, and even across different types of networks. A need therefore exists for a router which can direct data over networks of different types in accordance with associated TD codes. A need further exists for a router which can automatically transform a data packet having a first data format into a second data format.
  • the present invention disclosed and claimed herein in one aspect thereof, comprises a method for communicating between first and second unlike systems.
  • Information is generated at the first system in a first information format that is native to the first system.
  • a first conversion system in a first conversion operation, converts the generated information to a master space format such that a first converted information transmission is generated.
  • the first converted information is then transmitted to a master information system.
  • the received first converted information is routed to a second conversion system in the master system format.
  • the information transmitted thereto is converted from the master space format to a second information format in a second conversion operation to provide a second converted information transmission, the second information format being native to the second system.
  • the second converted information transmission is then routed to the second system.
  • FIGURE 1 illustrates an overall diagrammatic view of the system of the present disclosure
  • FIGURE 2 illustrates the detail of flow between elements of the system of the present disclosure
  • FIGURE 3 illustrates the flow of packets between elements in the system and the conversion as the packets flow through the system
  • FIGURES 4A-4D disclose diagrammatic views of the proprietary portion of a transaction packet
  • FIGURE 5 illustrates a diagrammatic view of databases at the host/client and the conversion thereof to a proprietary routing ID packet
  • FIGURE 6 illustrates a diagrammatic view of one instantiation of the system of the present disclosure illustrating a transaction from a first host to a second host or client on the system;
  • FIGURES 7A and 7B illustrate two separate channels on the system
  • FIGURE 8 illustrates a flow chart depicting the initial operation of generating the blocks of data for a transaction and scheduling those blocks for transmission;
  • FIGURE 9 illustrates a flow chart depicting the data flow analysis operation
  • FIGURE 10 illustrates a diagrammatic view of a transaction table that is formed during the transaction for analysis process
  • FIGURE 11 illustrates a flow chart depicting the export operation wherein the data is polled and transmitted in packets
  • FIGURE 12 illustrates the operation of assembling the data packets
  • FIGURE 13 illustrates a diagrammatic view of a single channel and the processes performed in that channel
  • FIGURE 14 illustrates a diagrammatic view of two adjacent channels that are utilized in completing a transaction or a process between an origin and a destination.
  • FIGURE 14A illustrates the joiner IDs for the two channels
  • FIGURE 15 illustrates a schematic diagram of three separate process systems joined by separate channels
  • FIGURE 16 illustrates a diagrammatic view of the manner in which feeds are propagated along a process chain
  • FIGURE 17 illustrates the process flow for the feeds in a given process or transaction
  • FIGURE 18 illustrates a flow chart for the operation at each process node for determining from the feed the process to run and then selecting the next feed;
  • FIGURE 19 illustrates a diagrammatic view of three adjacent channels in a single process flow
  • FIGURE 20 illustrates a diagrammatic view for a non-system host or origin process node accessing a system process node
  • FIGURE 21 illustrates the process at the router for handling an out of system process node that originates a transaction
  • FIGURE 22 illustrates a diagrammatic view of a simplified network for servicing a non- system node with the processes illustrated;
  • FIGURE 23 illustrates an alternative embodiment of the embodiment of FIGURE 22
  • FIGURE 24 illustrates a more detailed diagram of the data packet
  • FIGURE 25 illustrates a detail of the preamble of the data packet
  • FIGURE 26 and 27 illustrate the hierarchal structure of the classification system associated with the data packet
  • FIGURE 28 illustrates a diagrammatic flow of a classification operation
  • FIGURE 29 illustrates a flow chart for creating a data packet
  • FIGURE 30 illustrates a diagrammatic view for associating an input profile with a previous data packet, creating a new data packet
  • FIGURE 31 illustrates a block diagram for layering of data packets
  • FIGURES 32 and 33 illustrate block diagrams for two embodiments of a communication system for conversing between two nodes with data packets
  • FIGURES 34 and 34a illustrate an example of communication with a data packet.
  • Transaction system 102 is comprised of a router 108 that is interfaced with a network mesh 110, which network mesh 110 is local to the system 102.
  • the network mesh 110 allows the router
  • a host system node 114 that is the node at which a transaction arises.
  • an archival server 116 and a conversion server 118 are also attached to the network mesh 110. Since the host system 114, the servers 116 and 118, and the router 108 are all in the same network mesh 110, they communicate in a common protocol to that of the network mesh 110, and also may have the ability to communicate over the network mesh 110 with other network protocols that presently exist and any future protocols that would be developed at a later time. This allows data packets to be transferred between the various nodes on the network mesh 110.
  • the router 108 is also provided with various media interfaces 120 and 122.
  • Media interface 120 allows the router 108 to interface with a private network 124 which could be any type of private network such as a local area network (LAN) or a wide area network (WAN).
  • This private network 124 can have other systems attached thereto such that the router 108 can forward data through this network 124.
  • the media interface 122 is interfaced with a global public network (GPN) 126, which is typically referred to as the "Internet.” This allows the router 108 to interface with the GPN 126 and the multitude of resources associated therewith, as are well known in the art.
  • GPN global public network
  • the system 106 is similar to the system 102 in that it has associated therewith a central router 128.
  • the router 128 is interfaced with a network mesh 130, which network mesh 130 is also interfaced with a universal ID server 132 and auniversal web server 134.
  • the router 128 is also interfaced with the GPN 126 with a media interface 136.
  • the router 108 could effectively interface with the router 128 and the network resources in the form of the universal TD server 132 and the universal web server 134, the operation of which will be described hereinbelow.
  • the third system, the system 104 is comprised also of a central router 136, similar to the routers 108 and 128.
  • the router 136 is interfaced on the local side thereof to a local network mesh 138.
  • Local network mesh 138 has associated therewith three host or transaction nodes, a transaction node 140 associated with a system A, a transaction node 142 associated with a system B and a transaction node 144 associated with a system C
  • the system 104 has associated with its local network mesh 138 a core ID server 146, an account ID server 148, a conversion server 150 and an archival server 152.
  • Router 136 is operable to interface with the private network 124 via a media interface 154, interfaced with the GPN 126 via a media interface 156 and also to a transmission medium
  • the transmission medium 158 is an application specific medium that allows information to be transmitted to an end user output device 162 through a media interface device 164 or to be received therefrom.
  • this end user output device might be a fax machine, and the transmission medium 158 a telephone system or the such that allows data in the form of facsimile information to be transmitted from the router 136 through the transmission medium 158 to the end user output device 162 for handling thereof.
  • the transmission medium 158 may be merely a public telephone network (PTN) that allows the number of the end user output device 162 to be dialed, i.e., addressed, over the network or transmission medium 158, the call answered, a hand shake negotiated, and then the information transferred thereto in accordance with the transaction that originated in the access to the transmission medium 158.
  • PTN public telephone network
  • the transmission medium could include a satellite transmission system, a paging transmission system, or any type of other medium that interfaces between one of the routers and a destination/source device. This will be described in more detail hereinbelow.
  • a fifth transaction node 166 that is disposed on the GPN 126 and has access thereto via a media interface 168.
  • the transaction node 166 is operable to interface with any of the routers 108, 128 or 136. h operation, as will be described in more detail hereinbelow, each of the transaction nodes 114, 140, 142, 144, is able, through the use of the disclosed system, to complete a transaction on the system and utilize the system to send information to or retrieve information from another transaction node on the system, hi the private network 124, there is illustrated a phantom line connection between the router 108 and the router 136.
  • the router 136 could also allow one of the transaction nodes 140- 144 to interface with the router 108 through the GPN 126 such that a transaction can be completed with the transaction node 114 for system D. This would also be the case with respect to interfacing with the universal ID server 132 or the universal web server 134, the transaction node 166 for system E or with the end user output device 162.
  • Each of the routers 108-128 and 136 have associated therewith a data cache 170, 172 and 180, respectively. Whenever a particular router in one of the systems 102-106 has data routed thereto, data may be cached, then processed either outside the system or internal to the system, or the data is maintained in the cache for later transmittal.
  • the general operation of a transaction would require one of the transaction nodes to determine what type of transaction was being made and the destination of that transaction. If it were determined that the transaction would be between transaction node 140 and transaction node 114 on system 102, a unique transaction packet would be generated that would have unique transaction IDs associated therewith that defined the routing path in the system and the transaction associated therewith while processing what needed to be done between the two transaction nodes.
  • this transaction is distributed over the entire system, with only a portion thereof disposed at the transaction node itself. It is the unique transaction codes or IDs that are embedded in the information that is sent to the system that allows the transaction to be carried out in a distributed manner at all of the various elements along the path of the transaction.
  • transaction node 114 for system D utilizes a different database than transaction node 140, i. e. , the two nodes are in general incompatible and require some type of conversion or calculation to interface data and transactional information.
  • the transaction packet is transmitted to various nodes whichperform those discrete functions associated with the transaction packet for the purpose of converting, routing, etc. to ensure that the transaction packet arrives at the correct destination and achieves the correct transaction.
  • FIGURE 2 there is illustrated a diagrammatic view of the system 104 and a transaction between transaction nodes on the network mesh 138, which network mesh 138 is illustrated as a general network. It is noted that network mesh 138 could be any type of network, such as an Ethernet, a satellite, a Wide Area Network or a Local Area Network.
  • the transaction is illustrated as occurring between transaction node 140 for system A and transaction node 142 for system B. Although the details of a transaction will be described in more detail hereinbelow, this transaction is illustrated in a fairly simple form for exemplary purposes.
  • the transaction is initiated at transaction node 140 to generate information that will be transmitted to transaction node 142 for system B.
  • transaction node 140 When the transaction is generated, the type of transaction is determined, the manner in which the information is to be transmitted to transaction node 142 is determined and the route that it will take is determined, and all of the information is embedded in a transaction packet. This is a predetermined transaction that is completed with the use of IDs that are utilized by various systems on the network to appropriately route information and to possibly perform intermediate processes on the packet and the data associated therewith. Further, transaction node 140 has associated therewith information to allow the data that needs to be transferred to be transferred in a predetermined manner in accordance with a known profile of how transaction node 142 wants the transaction to be completed and in what form the data is to be run. For example, it may be that transaction node 140 desires to order aparticularproduct in aparticular quantity from transaction node 142.
  • the data associated with the transaction or transactions would be assembled, in accordance with a predetermined transaction profile as determined by the system beforehand and in accordance with a business relationship between the transacting parties, and forwarded to the appropriate location in the appropriate format to be received and processed by transaction node 142.
  • all transaction node 142 desires to do is to receive the transaction in a manner that is compatible with its operational environment. By using various conversion algorithms, routing algorithms and the such, the transaction can be effected between the two systems in a distributed manner.
  • the first step is to create the transaction packet and route it to the router 136. This is facilitated over a path "A" through the network 138.
  • the router 136 is then operable to examine the contents of the transaction packet and the IDs associated therewith with a look-up table (LUT) 202.
  • LUT look-up table
  • the router 136 determines that this transaction packet is associated with a particular transaction and that the transaction requires that any information for this type of transaction being received from transaction node 140 be transferred to the conversion server 150.
  • the router 136 then reassembles the packet and transfers this transaction packet over the network 138 to the conversion server on a path "B" and also stores the information in its associated data cache.
  • Router 136 has, as such, "handed off' the transaction to the conversion server 150 and then created a record in its local cache 180. (This could be stored in non local cache also, such as at the archive server 152.) It is noted that the transaction packet may be converted at each node along the path, depending upon the transaction and the action to be taken at each node.
  • the received packet from the path "B" is examined to determine information associated therewith.
  • the conversion server 150 also has an LUT associated therewith, an LUT 204.
  • the conversion server 150 recognizes that the information came from the router 136 and has a predetermined transaction associated therewith merely from examining the IDs, processing them through the LUT 204 and then determining what type of process is to be performed on the data packet and the contents thereof and where to forward them to.
  • the operation of the conversion server could be as simple as converting the data from an SML language to an XML language, it could be utilized to translate between languages, or any other type of conversion.
  • the contents of the transaction packet and associated data that was retrieved from the database associated with transaction node 140, associated with the transaction therein, may require conversion in order to be compatible with the destination transaction node 142.
  • the conversion server 150 places the data in the appropriate format such that it will be recognized and handled by the transaction node 142.
  • the specific manner by which this conversion is achieved is that setup in the initial setup when the business relationship between the two transaction nodes 140 and 142 was defined.
  • the reason that this particular conversion was performed is that the agreed upon transaction set these parameters in the system for this portion of the transaction which is stored in the LUT 204 at the conversion server 150.
  • the transaction data packet is then reassembled with the destination address of the router 136 and transferred back to the router 136 via a path "C," which may also modify the transaction packet to some extent, as will be described in more detail hereinbelow.
  • Router 136 recognizes this data packet as having come from the conversion server 150 and performs a look-up in the LUT 202 to determine that this particular transaction, determined from the transaction IDs associated therewith, requires data received from conversion server
  • the data 150 to be transferred to the transaction node 142.
  • the data is then assembled in a transaction packet and transmitted to transaction node 142 along the path "D.” Additionally, the previous cached data in cache 180 is replaced by the new data that is forwarded to transaction node 142. hi some instances, it is desirable to archive the data associated with this transaction. This is facilitated by the archive server 152, wherein the data transmitted to the transaction node 142 along the path "D" is also transferred to the archive server 152 along a path "D'.”
  • the entire transaction is determined by a unique transaction packet that has embedded therein routing information in the form of ID packets, data, etc.
  • the ID packets are unique numbers that are recognized by each of the nodes in the network to which it is routed.
  • the particular router 136, conversion server 150, etc. has information associated therewith that allows it to perfo ⁇ n the portion of the transaction associated with that particular node, i.e., the conversion server 150 performs a conversion and then routes it back to the router 136.
  • the originating transaction node need not embed all the transaction information therein and actually effect a direct connection, through a network or otherwise, to the destination transaction node in order to complete the transaction, nor does the originating transaction node require all the transaction information to be associated therewith.
  • the transaction itself is distributed throughout the network in a predetermined manner.
  • FIGURE 3 there is illustrated a diagrammatic view of the manner in which the packet is modified through the transaction.
  • An originating transaction packet 302 is generated at the originating transaction node 140. This is then transferred to the router 136, wherein the router 136 evaluates the transaction packet, determines where it is to be sent and then converts the packet to a "conversion transaction packet" 304, which is basically the transaction packet that is designated by the router 136 for transmittal to the conversion server 150 via the path "C" with the necessary information in the form of ID packets, data, etc., that will be required by the conversion server 150 to perform its portion of the transaction, it being noted that the transaction packet may undergo many conversions as it traverses through the system.
  • the conversion server 150 then processes the data contained in the conversion transaction packet and then, after processing, converts it to a router transaction packet 306 for transmission back to the router 136.
  • the router 136 then converts this to a destination transaction packet 308 for transmission to the destination. It is noted that the conversion server 150, after receiving the router transaction packet, has no knowledge of where the destination of the transaction packet will be eventually, as it has only a small portion of the transaction associated therewith. All it is required to know is that the transaction packet requires a certain action to be taken, i.e., the conversion process, and then this transaction packet must be transmitted back to the router 136.
  • each node that the transaction packet is transferred to or through will recognize where the transaction packet came from, what to do with the transaction packet and then where to transfer it to. Each node then will transfer the transaction packet to the destination eventually in a "daisy chain" manner.
  • FIGURES 4A-4D there are illustrated diagrammatic views of the packet transmission which facilitates transmission of a transaction packet between transaction nodes or even nodes in a network.
  • a "data" packet Prior to describing the formation of and transmission of the transaction packet, the distinction must be made between a "data" packet and a "transaction" packet.
  • data is transmitted over a network in a packetized mamier; that is, any block of data, be it large or small, is sent out in small “chunks" that define the packet.
  • the packet is a sequence of fields that represent such things as headers, footers, error correction codes, routing addresses and the data which is sent as an intact "unit.”
  • the data contained in the packet is actually a small portion of the actual overall data that is to be transmitted during a data transfer operation of some predetermined block of data.
  • These packets typically have finite length fields that are associated therewith and some even have longer variable length fields for the data.
  • the data will be divided up into smaller sub-blocks that can be sent in each packet. Therefore, for example, a large block of data would be sent to the network controller for transmission over a compatible network to a network controller on a receiving device for assembly thereat.
  • the block of data if it were large enough not to be compatible with a single data packet, would be divided up into sub-blocks. Each of these sub-blocks is disposed within a data packet and transmitted to the receiving device which, once receiving it, will ensure that this data is then sequenced into a combined block of data. If, for example, one of the data packets had an error in it, this would be communicated back to the fransmitting device and that particular data packet possibly retransmitted or the entire block of data retransmitted. Since each data packet has a sequence number when sending a group of data packets that represent one block of data, the individual packets that each contain a sub-block of data can be reassembled to provide at the receiving device the entire packet. This packetising of data is conventional.
  • FIGURE 4A there is illustrated the manner by which the data is actually transmitted.
  • network controllers are arranged in multiple "layers" that extend from an application layer down to a transport or network layer that inserts the data into a new format that associates a data field 402 with a header 406.
  • the embodiment of FIGURE 4A is referred to as an IP X data flow controller.
  • IP X data flow controller As noted hereinabove, whenever a computer is attached to a network, it becomes a node on a network and is referred to as a workstation. When information is sent between the nodes, it is packaged according to the protocol rules set up in the network and associated with the network controller.
  • the rules are processes that must be complied with to utilize the operating system protocol layers - the application layer, the presentation layer, the session layer, the transport layer, the network layer, the data link and the physical layer - in order to actually output a sequence of logical "1 's" and "O's” for fransmission on the network mesh.
  • the data field 402 which was generated at the application layer, is associated with the header 406.
  • This particular configuration is then sent down to the data link which is illustrated as a block 408 which basically associates the data field 402 with a UDP header 410 and then translates this data field 402, UDP header 410 and the IPX header 406 which is then translated into a new data field 412.
  • This new data field 412 at the datalink is then associated with IPX header 414 which is then again converted to a data field 414 associated with a media access controller (MAC) header 416 which is then compatible with the physical layer.
  • the physical layer is the network mesh. This data field 414 and header 416 are what is transferred to the network and what is received by the receiving device.
  • the receiving device upon receiving the MAC header 416, recognizes an address as being associated with that particular receiving device and then extracts the data field 414 therefrom, which is again utilized to extract the header 414 for examination purposes and, if it is compatible with the device, then the data field 412 is extracted and so on, until the data field 402 is exfracted.
  • data field 402 is only extracted if the data packet comprised of the MAC header 416 and data field 414 is that directed to the particular receiving device. It is noted that all devices on the network mesh will receive the data packet, i. e. , they can all "see" the data packet traveling across the network mesh.
  • each network controller will have a unique serial number associated therewith, there never being two identical serial numbers in any network controller or network card for the Ethernet environment.
  • ID packets a plurality of smaller packets that are referred to as "ID packets" that are generated in the application level.
  • the transaction packet is formulated with a plurality of these ID packets and data that are generated at the transaction node and modified at other nodes.
  • This fransaction packet once formed, is transmitted to the network level in such a manner that the appropriate header will be placed thereon to send it to the appropriate location. Therefore, the software or process running at the particular transmitting node on the network will have some type of overhead associated therewith that defines the address of the source node on the network and also the address of the destination node. Therefore, when data is received by any one of the nodes, it can recognize the defined field for the destination address as being its address.
  • the source address field which is at a particular location in the data packet, to determine where the data came from.
  • the ID packet 430 in the present disclosure, is comprised of a plurality of IDs, a core ID 432, a device ID 434 and an item ID 436.
  • the core ID 432 is that associated with a particular entity on the network such as a corporation. For example, if a co ⁇ oration had a profile set up, it would be assigned this particular core ID when initiated.
  • the device ID 434 is the unique ID of the device on the network.
  • the core 3D could be the corporation, and the device ID could be the computer or program that is assigning item IDs.
  • each of the core ID 432, device ID 434 and item ID 436 are comprised of two blocks, a group block 438 and an individual block 440.
  • the group block and the individual block 440 are comprised of a prefix 442, a time stamp 446 and a sequence number 448.
  • the prefix is a sequence of predetermined prefixes that define various items associated with a particular group or individual. For example, it could be that the setup of the profile define this individual as a vendor that had an account which was a core ID and other various prefix values. As such, many different companies or organizations could have the same prefix. However, once the prefix is defined, then the time that it is created is set in the time stamp 446 and then a sequence number is associated therewith in the field 448. Therefore, since only one entity will ever assign the time stamp and sequence values, the entire block, 438 will comprise a unique value or number or ID for that particular group. For example, if company A set up a profile, it would be assigned a unique number that would always identify that particular company and this would never change.
  • this is a block that further defines the core ID. For example, there maybe five or six different divisions within a co ⁇ oration such that this can be a subclassification.
  • the notable aspect for this particular core ID 432 is that it comprises a unique ID in the system and will define certain aspects of the overall ID packet 430, as well as the device ID 432, 434 and item ID 436. When all three of these core ID 432, device TD 434 and item ID 436 are combined, this defines a unique ID packet 430 that is associated with various information such as transactions, messages, pointers, etc. These are set up originally in the universal ID server 132 in a profile origination step (not described) wherein a particular operation can be associated with the ID packet 430.
  • this ID packet 430 is assembled into the transaction packet, it is only necessary for any node to examine each of the ID packets and determine if any of the ID packets define operations to be performed by that particular ID packet. For example, if the ID packet represented a fransaction such as a conversion, then the conversion server 150 in, for example, system 104, would recognize the particular ID packet indicating a conversion operation and also it might require information as to the destination node which is typically information contained in an ID packet, among other information, which defines exactly the process that must be carried out.
  • the conversion server could make a decision that a particular process is to be carried out. This is facilitated since a relational database will be associated with the conversion server 150 that will run a particular process therein. It is not necessary to send any information to the conversion server 150 as to exactly what must be carried out; rather, only the particular ID is necessary which comprises a "pointer" to a process within the conversion server 150.
  • the process that is running can utilize another ID packet contained therein for the pu ⁇ ose of determining which device in the node is to receive the results of the process and exactly how those results should be packaged in a new fransaction packet, it being noted that the transaction packet can be modified many times along with the fransaction as it traverses through the system.
  • FIGURE 4C there is illustrated a diagrammatic view of a transaction packet 460.
  • the transaction packet in FIGURE 4C is illustrated as being a plurality of "stacked" packets referred to as IDP1, IDP2, IDP3 and IDP4, followed by a data field 462, followed by additional ID packets, IDP5 and IDP6 and so on.
  • This transaction packet 460 can have any length, it being noted that the length is due to the number of ID packets, those being fixed length, and possibly variable length data field 462. By examining the ID packets as they arrive, which occurs in a sequential manner, then each of the ID packets can determine what follows and what action should be taken.
  • JDP4 may be an ID packet that defines exactly the length of the field 462 and what data is contained therein. Typically, these will be in finite length blocks.
  • FIGURE 4D there is illustrated a more detailed example of a fransaction packet 464.
  • this transaction packet there are provided a plurality of ID packets, IDPl, IDP2, IDP3-IDP6, and so on.
  • 1DP1 is associated with a transaction packet defining a predetermined transaction. As noted hereinabove, this is merely a pointer to a process that is defined in code on the recipient node, if that node is actually going to utilize the transaction.
  • this transaction packet IDPl maybe a fransaction that is designated for another node.
  • the IDP2 data packet which is associated with a message number.
  • a message number comprises the real ID of a line of data in the database of the fransmitting fransaction node.
  • the message number would be a block number in the IDP3 data packet followed by a block of data in a data packet 466.
  • the message number and block number define the sequence of the data packet 466 for later assembly. This could then be followed by the data packet IDP4 for another message number and IDP5 for a block number followed by a data packet 468 associated with the message number and block number of 1DP4 and IDP5, respectively.
  • ID packets various message numbers, block numbers, data, transactions, process IDs, etc. can be transmitted in ID packets, it being noted that all that is sent is a unique value that, in and of itself, provides no information. It is only when there is some type of relational database that contains pointers that can be cross-referenced to the unique ID packets that allows the information in the ID packet to be utilized. If it is a fransaction, as described hereinabove, then that transaction could be carried out by recognizing the pointer to that process disposed at the node that is processing the data.
  • FIGURE 5 there is illustrated a detail of a database at the source transaction node HI .
  • the databases will always be arranged in rows and columns with a row identification address (RID) associated with each row. With the row address, one can identify where the data is for the pmpose of extracting the data, updating the data, etc.
  • RID row identification address
  • each row of data is associated with two separate proprietary columns, which columns are proprietary to the system of the present disclosure. They are a column 502 and a column 504.
  • the column 502 is a date stamp on a given row, such that the particular row when accessed can be date stamped as to the time of access.
  • a row ID that is proprietary is also associated with the accessed row. Therefore, whenever a row is accessed, it is date stamped and assigned a row ID. hi this manner, even if the data is reorganized through a database packing operation or the such, the data can still be found.
  • a unique identification number for a given row can be generated with the proprietary row ID or the proprietary RID and the date stamp, such that a large number of proprietary numbers can be realized.
  • the databases are generated and put in the appropriate formats, it is desirable to transfer data that is stored for the pu ⁇ ose of a fransaction to actually facilitate or execute the transaction. This utilizes a unique "Extent" for that transaction, which Extent is defined by an arrow 506 that converts the data in the appropriate manner to a proprietary fransaction packet 508.
  • the Extent 506 is operable to determine how to process data, exfract it from the various tables, even creating intermediate tables, and then assemble the correct ID packets with the appropriate data in a transaction packet and transfer this transaction packet to the network. Since the transaction is a profiled fransaction for the whole network, the entire decision of how to route the data and ID packets to the destination and the manner in which the data is handled or delivered to the destination is not necessarily dete ⁇ nined in the
  • FIGURE 6 there is illustrated a diagrammatic view of two transaction nodes 602, labeled HI , and 604, labeled H2, in a system that are both associated with individual routers 606, labeled RI, and router 608, labeled R2.
  • Router 606(R1) is interfaced with the transaction node 602 through a local network 610, which also has associated therewith two conversion servers 612 and 616, labeled Cl and C2, respectively.
  • the router 606(R1) is interfaced with router 608(R2) via a network 618.
  • Router 608(R2) is interfaced with transaction node 604 through a local network 620, network 620 also interfaced with a conversion server 622 labeled C3.
  • FIGURES 7 A and 7B are illustrated graphical depictions of two channels, h FIGURE 7A, there is illustrated a channel from HI to H2 labeled "0011."
  • This channel requires the data to be generated at HI and transferred to RI.
  • a conversion operation is determined to be required and the data is merely sent to converter C 1 (after possible caching at the router.)
  • conversion server Cl the conversion is performed and then it is reassembled and passed back to RI.
  • Converter C2 then performs the appropriate conversion operation, based upon the feed ID packet and the other unique ID packets in the fransaction packet, and then transfers the fransaction packet back to RI .
  • this fransaction packet must be sent to another router, which is router R2.
  • the routing information could be global or it could be network specific, i.e. , the channels might be specific only to the systems associated with the appropriate router.
  • an intermediate "joiner ID" is generated that defines a particular relationship. This is an intermediate ID that is created for the pmpose of this particular transaction. This joiner ID then is generated and the information sent to the router R2 which indicates that router R2 is to transmit the transaction packet to H2.
  • the transaction packet is already appropriately conditioned for receipt by H2 and H2 will receive the transaction packet, and know what type of transaction is to be performed at H2, i.e., it is aware of the unique ID packets and their meaning, such as the feed ID, packet how to process information once received, etc. It therefore understands the parameters within which the transaction is to be effected.
  • FIGURE 7B there is illustrated another channel, channel "0022" for performing another transaction from H2 over to HI .
  • This channel requires that the fransaction packet be sent from H2 over to R2 and then from R2 over to C3 for conversion. After conversion, the fransaction packet is sent from C3 over to R2 and then from R2 over to RI with a joiner ID, similar to that of FIGURE 7A.
  • the data is transferred directly to HI . If the transaction for this particular channel is to be transmitted back to H2 along the same channel, the reverse path would be utilized.
  • FIGURE 8 there is illustrated a flow chart for initiating a fransaction.
  • a fransaction table is created.
  • This fransaction table will have data associated therewith with rows of data therein in a predetermined format that is associated with the native database of the transaction node.
  • This fransaction table will then have each row therein stamped with a proprietary date and a proprietary RID, as indicated by the function block 804.
  • the fransaction flow will be analyzed, in a function block 806, to determine how the data is to be arranged and transferred.
  • This transaction is then scheduled for fransmission, in a function block 808. This is facilitated with a process wherein various calls are created for each block of data in the database, as indicated by a function block 810 and then a run ID is created in a function block
  • FIGURE 9 there is illustrated a flow chart depicting the operation of analyzing the fransaction flow in the block 806.
  • the flow begins at a function block 902 to exfract select data from the database and assign destination information and source information thereto, i.e., determine that the fransaction comes from HI and flows to H2.
  • the type of extraction is determined, as indicated by block 901. It may be a partial extraction or a full extraction.
  • the partial exfraction is one in which less than all of the data for a given transaction is extracted, whereas the full exfraction extracts all the desired data in a single continuous operation.
  • the program in function block 902 operates in a filter mode and flows to a decision block 916 to determine if there is a restriction on the data which, if determined to be the case, will result in filtering by predetermined parameters, indicated by function block 918.
  • This restriction operation is a filter operation that sets various parameters as to how the data is "pulled" or extracted. If not restricted, or, after restriction (filtering), the program will flow to a block 920 to a function block 904 to then assign a transaction ID to the data.
  • a joiner ID in the event that it was determined the data should go across to systems and the joiner ID were appropriate. This joiner ID will be described hereinbelow.
  • the program then flows to a function block 906 wherein a message number is assigned to each fransaction. This message number is associated with a row of data.
  • the program then flows to a function block 908 to determine block flow.
  • the data is extracted in one large block of records. For example, a given fransaction may require 10,000 records to be transferred over the network. However, it may be that the recipient fransaction node desires only 500 records at a time as a function of the manner in which they conduct business. This, as noted hereinabove, is what is originally defined in the profile for the business relationship or the fransactional relationship between the two transaction nodes. This, again, is predefined information.
  • the program After determining the block flow, the program flows to a decision block 910 to determine if this is to be a divided block flow, i.e., the block is to be split up into sub blocks. If so, the program flows to a function block 912 to assign a block ID to each sub-block, such that the blocks can be assembled at a later time. The program then flows to a decision block 914. If it is not to be divided, the program will flow from the decision block 910 to the input of decision block 914.
  • a decision block 910 determine if this is to be a divided block flow, i.e., the block is to be split up into sub blocks. If so, the program flows to a function block 912 to assign a block ID to each sub-block, such that the blocks can be assembled at a later time.
  • the program then flows to a decision block 914. If it is not to be divided, the program will flow from the decision block 910 to the input of decision block 914.
  • Decision block 914 determines if more data is to be exfracted from the local database of the transaction node initiating the transaction and, if so, the program flows back to the input of function block 902 to pull more data. Once the data associated with the transaction has been extracted, the program will flow to a block 920 to return the operation.
  • FIGURE 10 there is illustrated a diagrammatic view of a sample transaction table.
  • the transaction table is basically comprised of the message number, the fransaction ID, the joiner ID (if necessary), the row ID and date with proprietary identification system and the block ID. Also, a RUN ID can be assigned to each block as it is being processed.
  • the row ID in a column 1002 and the date in a column 1004 is different from the database defining row ID in that they are always associated with the row.
  • the row ID in the database is defined as function of the database and can actually change through various rearranging of the database at the fransaction node.
  • FIGURE 11 there is illustrated a flow chart depicting the operation of actually exporting the data from the transaction table. This is initiated at a block 1100 and then flows to a function block 1102 to pull the first block in accordance with the Extent that is running. It should be understood that all of the flow charts from the start of the transaction to the end of a fransaction are associated with a predetermined transaction Extent.
  • This Extent is a sequence of instructions or codes that are downloaded to the particular node to allow the node to conduct its portion of the transaction in the predetermined manner defined by the transaction profile that is distributed throughout the system. Not all of the necessary transaction information is contained here but, rather, only the information or the process steps necessary to create and transmit the transaction packet out of the system in the correct manner.
  • the program will flow from the function block 1102 to a decision block 1104 to determine if a caching operation is to be performed. If not, the program will flow to a function block 1106 to process the block as pulled. If caching is required, the program will flow to a decision block
  • the decision block 1108 determines whether an encryption operation is to be performed. If the data is to be encrypted prior to fransmitting over the network, the program will flow to a function block 1110. If not, both function block 1110 and decision block 1108 will flow to the input of a function block 1112 to assemble the data packet. It is noted that the encryption operation is something that is optional and does require the overhead in each recipient node to decrypt the data. This function will not be described with respect to the remainder of the data flow.
  • the fransaction packet is assembled.
  • the program then flows to function block 1114 to determine if the fransaction packet is completely assembled and, once complete, the program will flow to a transmit block 1116.
  • FIGURE 12 there is illustrated a flow chart for the transaction packet assembly operation, as initiated at a block 1202.
  • the program flows to the function block 1204 to determine the size of the data packet, whether it is a small group of ID packets in the fransaction packet or plural ID packets in the transaction packet.
  • the program flows to a function block 1206 to determine the router to which information is to be transmitted. It is noted that more than one router could be on a network.
  • the router is determined, of course, as a function of the particular Extent that is running, this being the path to which the packet will be routed.
  • the program will flow to a function block 1208 to insert the feed ID and the channel ID.
  • FIGURE 13 there is illustrated a diagrammatic view of a fransaction or process that is originated at an origin node 1302 for transmission to the destination node 1304 on a single outgoing channel.
  • the outgoing channel defines the route and the transaction.
  • the origin node at 1302 utilizes a local Extent, indicated by box 1306, to generate the transaction.
  • this transaction there are a number of IDs that are generated. One is a "RUN ID,” one is a "FEED ID,” and the third is a "CHAN ID.” Although there may also be other ID packets that are generated, these three packets can basically define an entire transaction or process.
  • the origin node 1302 which can comprise the host node or the such, generates the fransaction packet comprised of at least the RUN ID, the FEED ID and a CHANNEL ID and forwards it to a first process node 1306 which processes the received fransaction packet in accordance with the above noted processes which then requires the transaction packet to be modified and transferred to a second process node 1308 for further processing, which then forwards this to a third processing node 1310 and then to a fourth processing node 1312 before final routing to the destination node 1304.
  • the destination node 1304, as described hereinabove, can be the system router. Additionally, the router could be one of the processing nodes 1306-1312. This process will use a single outgoing channel for transferring a fransaction packet from the origin node 1302 over to the destination node 1304.
  • the destination node 1304 can be the system router. Additionally, the router could be one of the processing nodes 1306-1312. This process will use a single outgoing channel for transferring a
  • this processing channel is defined graphically as ablock 1314.
  • This graphical representation indicates that a fransaction packet is generated and the process through various nodes in accordance with distributed processing described hereinabove to route the fransaction packet along various processing nodes to the destination node 1304 for handling thereat.
  • FIGURE 14 there is illustrated a diagrammatic view of two channels adjacent to each other, hi this embodiment, there is illustrated an origin node 1402 which is operable to generate a fransaction packet, as described hereinabove, through two processing nodes 1404 and 1406 to a router 1408, labeled RI .
  • This router RI is substantially the same as the destination node 1304 in the single outgoing channel noted with respect to FIGURE 13.
  • This combination of the origin node 1402, the two processing nodes 1404 and 1406 and the router 1408 comprise an outgoing channel.
  • a second channel is associated with a destination node 1410.
  • the overall transaction or process is operable to generate the transaction at the origin node 1404 and route it finally to the destination node 1410 for completion of the fransaction.
  • the router 1408 passes it over to a router 1412 labeled R2, which constitutes an incoming channel for the destination node 1410.
  • the router 1412 receives the packet from router 1408 and passes it through two processing nodes 1414 and 1416 to the destination node 1410.
  • the two systems, the one associated with router 1408 and the one associated with router 1412 could handle the fransaction packet and the ID packets associated therewith in a similar manner, i. e. , that is, they could utilize the same packet IDs.
  • the origin node 1402 and the destination node 1410 utilize a different set of ID packets referred to as joiner ID packets to transfer information therebetween.
  • joiner ID packets a different set of ID packets referred to as joiner ID packets to transfer information therebetween.
  • IDs is something that the origin node 1402 would not want to share with the destination node 1410. Therefore, the origin node 1402 and the destination node 1410 negotiate a relational database that associates an arbitrary j oiner ID with various IDs at the origin node 1402 such that the IDs have no meaning in any system other than for the business relationship between the outgoing channel and the incoming channel for the origin node 1402 and destination node 1410, respectively.
  • Thesejoiner IDs are illustrated in tables of FIGURE 14A.
  • router RI has a table associated therewith wherein the joiner ID "0128" is associated with an ID packet "XXXX.”
  • a table for router R2 is examined to determine that this joiner ID "0128" is associated with an ID packet "ZZZZ" therein.
  • origin node 1402 it may be that there is a unique ID associated with origin node 1402 that defines it in an overall system.
  • destination node 1410 defines the origin node 1402 in a different manner, t.e., as "ZZZZ.” Rather than redefine the joiner ID as "XXXX" in its system, it merely needs to have a j oiner ID that defines the relationship between the two systems.
  • the router R2 will convert this joiner ID to the ID packet "ZZZZ" such that it now recognizes that ID packet as the vendor number of the origin node 1402 within its system. Other than within the system associated with destination node 1410, this has no meaning.
  • the joiner ID can be associated with the transaction packet in any position along the processing path.
  • the joiner ID is assigned at the origin node 1404 when running the Extent associated therewith, i. e. , it is initially defined when the feed and the channel are assigned. However, it could actually be assigned at the router 1408.
  • processing blocks 1502, 1504 and 1506 represent a single channel and a processing system.
  • processing node 1502 could represent a single company and its associated router, conversion server, ID server, archival server and host node.
  • the fransaction packet is generated within the processing node 1502, processed therethrough in accordance with the distributed processing system as described hereinabove and then output from the processing block 1502 over to a second channel 1508 for routing to the processing block 1504.
  • the processing block 1504 represents a third channel and an independent and self-contained processing block.
  • the processing node 1504 may be an intermediate processing node that allows independent processing of a fransaction or processing event for transfer to the processing block 1506.
  • Each of these channels and each of these processing blocks comprise separate distinct processing operations which all operate on the same transaction packet (although the transaction packet maybe modified somewhat).
  • the processing block 1502 originates at an originating node therein the transaction. This transaction has a channel and feed associated therewith, which channel comprised all of the channels from the origin to the destination at processing block 1506.
  • FIGURE 16 there is illustrated a diagrammatic view of how the channel IDs and the feed IDs change as the fransaction packet is processed through various processing nodes.
  • a channel is defined as the route that a fransaction path is to take through the various processing nodes. Since the processing is distributed, the transaction packet must be routed to each node in order that the appropriate processing be carried out on that transaction packet. Since the processing is predefined with respect to the channel ID, very little information needs to be disposed within the fransaction packet in order to effect the processing.
  • This fransaction packet and the packet IDs associated therewith in the form of the feed ID, the channel ID, etc. define the portion of the processing that is to be carried out at each processing node, i.
  • the feed ID basically constitutes an instruction that is generated at one processing node for transfer to the second processing node that, defines the processes that are to be carried out. hi general, this feed ID is a "tracer" that follows the process to flow from node to node.
  • one node when one node receives a fransaction ID from another processing node, it recognizes that the process is that associated with the channel ID, but it also recognizes where in the process the transaction packet is. For example, a router may handle a transaction packet a number of times in order to effect transfer to one or more conversion servers, effect transfer to an ID server, etc. With the use of the feed ID, the router now has knowledge of what process is to be carried out in the overall fransaction process when it receives the transaction packet from a given processing node. Additionally, another aspect that the feed ID provides is the tracing function wherein a failure at any point along the process path can now be tracked to the previous process that was carried out.
  • Each of the processing nodes 1602 carry out a portion of the overall fransaction process which was predistributed to the processing node.
  • Each of the processing nodes 1602 carries out a plurality of processes, labeled P 1 , P2 and P3 for exemplary purposes. It should be understood that any number of processes could exist at a particular processing node 1602 that could be associated with a given channel ID or multiple channel Ids for many other transactions apart from the current fransaction. It is noted that each processing node can handle many different processes and transactions. Once a transaction ID packet is configured, each processing node will receive that transaction packet, examine the fransaction packet and determine exactly which process must be performed on that transaction packet, all of the effected with only a few ID packets of a fixed length.
  • processing node Nl receives the fransaction packet, it recognizes that the process to be carried out is defined by the feed ID and it has associated therewith a FEED1 block 1606 that defines the process that is to be carried out. This block 1606 then can select between the available processes P 1 -P3 for application to the fransaction packet.
  • FEED2 feed ID and processes the data in accordance with a block 1608 for this particular feed ID. Again, this selects between a plurality of processes for operation on the transaction packet.
  • the feed ID is incremented and the transaction packet transferred until it reaches the last processing node in the processing chain, the processing node NK.
  • this processing node will receive the feed ID, FEEDK, and the same channel ID, CHID 1. This will be processed with processing block 1610 in accordance with the feed ID to select the process that is to be applied to the fransaction packet and then this is transferred out to the destination.
  • this "hopping" operation allows the fransaction packet to be passed from one processing node to another.
  • each processing node can determine uniquely what process is to be carried out in the overall processing chain.
  • the feed ID provides this tracer operation, but could be eliminated. It could be that all that is required is the channel ID.
  • Each processing node would receive the channel ID and the processing associated therewith could be indicative of the process to be carried out by recognizing where the channel ID came from. Therefore, an entire transaction could be carried out with a single ID packet. For example, suppose that a transaction involved a conventional normal fransaction between two business entities that involve the transfer of 100 widgets to a particular warehouse.
  • a single channel ID could be fransferred to the destination company which, upon receipt, would recognize that a particular transaction was to be carried out in a particular way for this particular vendor. It may be that there are some conversions that are required during the process, which will require the ID packet to be transferred to a conversion server to possibly assign a joiner ID to the channel Id in order to provide some security to the system to prevent actual information at the origin in the form of its unique vendor ID, etc., to be fransferred to the destination node. As such, it may be that some type of conversion operation would be required to assign a joiner ID during the process in the first company's system for transfer to the second company's system.
  • a company system is that defined by a router, a network mesh, an ID server and a host node.
  • the ID server, the host node, the conversion server, and the network mesh are all typically associated and "owned” by a particular company.
  • FIGURE 17 there is illustrated a diagrammatic view of how the feed is incremented. This is initiated at a start block 1702 and then proceeds to various feed blocks for the feeds FEED1, FEED2, . . ., FEEDK.
  • the process must go through each of the feed blocks and, at each of the feed blocks, carry out the associated process. Therefore, the fransaction packet in effect not only carries a channel ID that can be utilized at a particular processing node to determine what fransaction is being processed but also receive intermediate instructions to indicate what processes in the fransaction are to be carried out. As noted hereinabove, it may be that the router is involved in the actual fransaction a number of times.
  • the processes that are applied to the transaction packet are determined as a function of where in the process the fransaction is.
  • the feed IDs indicate the position in the fransaction for the pu ⁇ oses of determining which predetermined fransaction processes are to be applied to the fransaction packet when received at a particular processing node. Additionally, the feed IDs also provide for some failure analysis in the event that a failure occurs. For example, in FIGURE 15, one could examine any transaction or process from the origin to the final destination at any place in the process and determine where in the process it was. Referring now to FIGURE 18, there is illustrated a flow chart depicting the operation of running the process at a given process node.
  • the program is initiated at a block 1802 and then proceeds to a function block 1804 to read the feed ID received in the fransaction packet.
  • the program then flows to a function block at 1806 to run the process or processes associated with that feed ID and then to a decision block 1808 to determine if all the processes have been run. If not, the program continues running processes in the block 1806 and, when complete, the program flows to a function block 1810 to increment to the next feed number and then transmit the fransaction packet to the next processing node, as indicated by a return block 1812.
  • FIGURE 19 there is illustrated a diagrammatic view of a plurality of channels which indicate processing from an origin to a destination in each channel and then handing off to a second channel or second system.
  • hi channel CHI there is provided an origin node 1902 and a destination node 1904 with two processing nodes 1906 associated therewith, hi the second channel, CH2, there is provided an origin node 1908 and a destination node 1910 with three intermediate processing nodes 1912.
  • the fransaction is initiated at the origin node 1902 for final transmission to the destination node 1916.
  • a line of demarcation 1920 with a similar line of demarcation 1922 disposed between destination node D2 and origin node 1914.
  • the destination node 1904 could be a router and the origin node 1908 could be a router in channel CH2.
  • the line of demarcation 1920 indicates that the first channel, CHI, basically "hands off the transaction to the second channel CH2 which processes the transaction in accordance with a predetermined process set forth therein in a distributed manner across the various processing nodes for handing it off to the third channel, CH3.
  • Each of the line of demarcations 1920 and 1922 define distinct boundaries such that the fransaction packet can be considered independently handled for each of the channels. For example, it maybe that in order to transfer from CHI to CH2, a joiner ID is provided. When handing off from destination 1910 to origin 1914 across line of demarcation 1922, a second joiner ID' maybe required.
  • FIGURE 20 there is illustrated a diagrammatic view of one of the systems of 102- 108 wherein a non-system node 2002 is interfaced with the system 104 through a network 2006, which interfaces with the router 136.
  • the non-system node 2002 since it is not part of the overall system 104, is not identified in the system per se without some processing in the system 104.
  • the non-system node 2002 first must be identified and the fransaction associated with its access to the router 136 identified. Once this identification is made, then the necessary transaction packet is assembled and the fransaction conducted in accordance with the process described hereinabove. For example, the non-system node 2002 will initiate a transaction merely by contacting the router 136.
  • the router 136 upon recognizing the URL of the non-system node 2002, i.e., the source URL, would recognize that a transaction is being initiated. The router would then create a transaction packet and route it to the conversion server 150. The conversion server 150 would then convert information received from the non-system node 2002 over to a format compatible with a transaction to be conducted with, for example, fransaction node 140 on the network mesh 138 in the system 104.
  • non-system node 2002 wanted to send an order via e-mail to transaction node 140.
  • non-system node 2002 would fill out a form in a predetermined order with information disposed in predetermined fields.
  • This e-mail would then be routed to the router 136.
  • the router 136 would recognize the source of the e-mail and the fact that it was an e-mail. By recognizing both the source of the e-mail and the fact that it is e-mail, the router 136 would now recognize a transaction. It would create a form ID for the non-system node 2002, which would define the type of form that is to be routed to the conversion server 150, and various other IDs that are associated with the transaction.
  • This form and the form ID in addition to other identification information in the form of ID packets, would be sent to the conversion server 150.
  • the conversion server 150 would then exfract the information from the form in accordance with the form ID pointer, and convert this to information associated with the transaction. This would then be transferred to fransaction node 140.
  • FIGURE 21 there is illustrated a flow chart depicting the operation of the router 136 when receiving information from within the system and from outside of the system.
  • the operation of the router 136 is operable to receive data in the form of packetised data from the non-system node 2002. This is indicated at decision block 2102.
  • the program then proceeds to decision block 2104 to determine whether this is a system packet. If so, then this indicates that this is a system node and the program will proceed to a function block 2106 to process the received fransaction packet in a normal mode. If it is not a system packet or fransaction packet, the program would flow to a function block 2108 to convert the packet to a system packet and then to the function block 2106.
  • FIGURE 22 there is illustrated a block diagram of a simplified embodiment of FIGURE 20.
  • the router 136 must have some type of ID process, indicated by block 2202, by which to recognize the non-system node 2002 and associate the fransaction packet therewith, which involves the use of a form ID, as described hereinabove.
  • ID process indicated by block 2202
  • the transaction packet is created by the router 136, then the transaction packet is routed to the conversion server 150 and a conversion process, as indicated by block 2204, is run and the information received from the non-system node 2002 converted to the appropriate format to complete the fransaction.
  • FIGURE 23 there is illustrated an alternate embodiment of the embodiment of FIGURE 22, wherein the non-system transaction node 2002 has software associated therewith that allows it to form the transaction packet.
  • the non-system node 2002 has an ID process block 2302 associated therewith that allows the non-system node 2002 to create a transaction packet.
  • the non-system node 2002 has a definite ID on the system which has been defined in the original setup wherein the ID process in block 2302 was created and "pushed" out to the non-system node 2002.
  • the ID process is run and a transaction packet assembled. This transaction packet is then forwarded to the router 136, in accordance with information in the transaction packet. This is due to the fact that the fransaction packet created by the ID process 2302 has a channel ID and the such contained therein.
  • the router 136 receives the transaction packet, it recognizes this transaction packet as one that exists on the system and routes it in accordance with a routing process in a process block 2304. Thereafter, this transaction packet is modified, if necessary, and routed to the conversion server 150 for processing thereby.
  • the routing to the conversion server 150 is in accordance with the channel definition set forth in the ID process 2302. Thereafter, the information is processed as described hereinabove with respect to FIGURE 22.
  • FIGURE 24 there is illustrated a more detailed diagrammatic view of the ID packet that constitutes the proprietary portion of a transaction packet that is transferred over the network, it being noted that this ID packet is typically embedded within a data fransmission between the network with all of the commensurate overhead associated with such a transfer. As was described hereinabove, this ID packet represents the smallest fixed length portion of a fransaction packet.
  • the ID packet is divided into three sections, a core ID section 2402, a device 3D section 2404 and an item ID section 2406.
  • Each of the sections 2402-2406 are divided into two sections, a "Group” ID and a "Individual" 3D section.
  • a detail is illustrated of the core section 2402.
  • Each of the Group and Individual sections are comprised of three sections, a preamble section 2408, a time stamp section 2410 and a sequence section 2412.
  • the preamble section 2408 comprises a classification section that is comprised of aplurality of "classifiers.”
  • the time stamp section 2410 and the sequence section 2412 provide a unique value that, when associated with a classifier section 2408, provides a unique group value for the core section 2402.
  • the Individual section is also organized as such, h the preamble section 2408 of the Group section, it can be seen that there are a number of classifiers associated therewith. Of these, one classifier will always be the classifier "G.” There can be multiple other classifiers, it being understood that the number of classifiers is finite. As will be described hereinbelow, each of these classifiers is comprised of a single alpha character, there being twenty-six alpha characters, each of which can be represented by an ASCII value which is a finite length value. Of course, this limits the number of values to twenty-six for each classifier field. There could be any type of value system utilized, it only being necessary that the field be a fixed length.
  • the field were defined as a digital word having a four bit length, this would provide 2 4 values.
  • this also has a finite number of classifier fields, one of which will be the classifier "I" designating this as an Individual ID.
  • the core ID 2402, device ID 2404 and item ID 2406 are illustrated in Table 1 as follows:
  • the core ID 2402 is directed toward the basic owner of the ID packet.
  • This could be a co ⁇ oration, such as Co ⁇ oration ABC.
  • the device ID is associated with the device that assigned the values in the packet. For example, this could actually be the ID of the computer, the phone, etc. that actually was responsible for assigning the packet.
  • the item ID is the subject of the data packet or the object, i.e., an article of commerce, anetwork address, a real estate property or the such. This is referred to as the "Who, Where, What" aspect of the ID packet.
  • Co ⁇ oration ABC is originally defined as the owner of the ID packet.
  • a unique core ID is initially associated with the ABC co ⁇ oration wherein a defined classification preamble 2408 is associated therewith and then a unique time stamp and sequence number.
  • This classifying preamble 2408 may actually be identical to the classification associated with other co ⁇ orations in the system.
  • this core ID becomes unique as to that co ⁇ oration or entity against others.
  • an ID packet is being created to uniquely define that item in the system
  • the preamble 2408 is comprised of a plurality of fields. These are referred to in FIGURE 25 as "FI, F2, F3, F4, F5, . . .” There are a fixed number of fields for the preamble 2408 which, in the present disclosure, are fixed for each Group ID and Individual ID for each of the core, device and item IDs. However, it could be that the fields differ between preambles, the only requirement being that they do not differ between ID packets.
  • a typical five field preamble section of an ID is illustrated in Table 2 as it exists in the database, understanding that more fields may be inco ⁇ orated.
  • each field has an alpha character associated therewith.
  • This alpha character has a predefined relationship for the classifier. For example, if a field were associated with the type of ID, there could be two values, one associated with a permanent ID and one associated with a joiner ID. This would therefore be a field having only two values. It could be that this utilized the alpha characters "P" and "J.” However, it could use any alpha character (number, character, symbol, etc.), it being recognized that the value or relationship (meaning) of the characters is unimportant; rather, it is the relationship of that packet disposed in other locations in the system that is important.
  • the database associated with a particular ID has associated therewith the fields in the preamble, the time stamp/sequence field (TS/SEQ) section in addition to a content column.
  • the content column defines what this preamble is associated with. For example, if this were the Group ID in the core ID 2402, then this could refer to, for example, a content of "chemical co ⁇ orations.” If this were C ⁇ oration ABC, then the Individual ID would have a preamble field that might be common with other individual co ⁇ orations but the TS/SEQ section would be unique only to that co ⁇ oration and the content associated with that particular co ⁇ oration would have the term "Co ⁇ oration ABC" in the content column.
  • the core ID 2402 would be unique to that co ⁇ oration.
  • Each of the Group ID and Individual IDs for the core, device and item IDs in the ID packet would be configured similarly.
  • each of the fields in the preamble 2408 is defined as having only 26 values due to the choice of an alpha character as the classifier, one of the fields can be combined with the TS/SEQ value to provide a larger value associated therewith. Since the TS/SEQ value can comprise a unique and very large number, it does not constitute a classifier as such. By combining the twenty-six alpha numeric values each with the TS/SEQ value, the number of classifiers for that particular field becomes very large. For example, if one wanted to define a field in the preamble for the item ID 2406 as the field that defines the item, more than twenty-six item classifiers can now be provided.
  • FIGURE 26 there is illustrated a diagrammatic view of the classification scheme.
  • four fields that are being classified in a preamble, it being understood that more or less fields could be defined for the preamble structure, with only three values illustrated for each field. However, each of these values can be conditional upon the previous path, as will be described hereinbelow.
  • the field FI there are illustrated three classifier values, A, B, C.
  • the classifier of interest in field FI is "A.”
  • field F2 is only associated with three classifiers, these being again, A, B, and C. It should be understood that the classifications being associated with the classifier A is not necessarily the same classifier associated with the classifier A in field FI.
  • the classifier B in field 1 may also point to three separate classifiers A, B and C in field F2.
  • the classifier A in field F2 that the classifier B in field FI could point to may not be the same as classifier A in field F2 pointed to by the classifier A in field FI .
  • the classifier in any one of the fields below field FI has a value that may be conditioned upon the classifier in the previous field from which it derives. It can be seen that each of the classifiers in field F2 will point to one or more classifiers in the next field F3, there being illustrated three, A, B and C. Further, field F4 further expands this will three classifiers, A, B and C for each of the classifiers in field F3. Again, although there are illustrated as multiple classifiers A in field F3, they are not identical in value or classification function but, rather, they are unique to the associated path.
  • the preamble may be classified as "A" in field FI and it may point to classifier "B" in field F2. Although the path could go to classifiers "A" or "C” only one path is selected.
  • classifier B points to classifier "A” in field F3 and classifier "A” in field F3 points to classifier "B” in field F4. Therefore, once it has been determined that field F 1 has classifier A, then the next determination must be which of the classifiers in field F2 associated with classifier A in field FI will be selected.
  • classifiers in a lower field with those in an upper field that defines the classification scheme.
  • classifier "B" in field FI could point to a classifier "B” in field F2 that is different than that associated with classifier "A" in field FI.
  • some fields have identical classifiers for each of the above fields.
  • the last field will always be "G” defining the Group ID as such (not a conditional classifier.)
  • the individual ID will always have a "I” in the last field thereof defining it as such. Therefore, there need not be any association between fields though there can be an association. With respect to the Individual ID, this follows the same path as the Group ID with the exception that it is defined as having values of "D,” "E,” and "F.”
  • the ID that is generated will be stored in a table in the database of the ID server with alpha titles that can be searched, in association with the code associated therewith.
  • a typical table in the database is illustrated in Table 3.
  • the field FI is associated with an ID that is either a permanent ID or joiner ID. This is referred to as P/ in one column, this is defined as a permanent or j oiner field with the code associated with the permanent field being a "P" and the code associated with the j oiner field with the j oiner value being a " J.”
  • the second field F2 is associated with different types of devices are Individual IDs or Group IDs, defined, in this embodiment as a profile type, a network type or a system type.
  • the one column will define the type as being profile, network or system and the code associated with the profile type will be "F,” the code associated with a profile type would be “P,” with a network type would be “N” and with a system type would be “S.”
  • Field F3 is associated with an item which could be a type of computer such as an Apple computer, an item such as a catheter, a URL for a network address or the name of a system such as ANC or with a system referred to as a PPLL, this basically being an acronym for some type of system in the industry, as an arbitrary example.
  • the code is the combination of an alpha character plus the time stamp for that row, to provide a large number of values therefor.
  • field F4 this is the category of the ID which, in this example can either be a core ID or a vendor ID. If it is a core ID, it will have a code of "C" and if it is a vendor ID, it will have a code of "N.” There will also be a time stamp associated with each row. It can be seen that there are two IDs having identical values in all of these fields with the exception that field F3 is associated with different catheters. As such, the code value would be distinguishable between the two because the code
  • P+TS is associated with a different time stamp. This is what makes these two IDs distinct, even though they are associated with the same item, they are both vendor IDs, they are both permanent IDs and they are both profile IDs.
  • time stamp By utilizing the time stamp in association with a alpha character, a much larger number of items can be defined for this particular field.
  • FIGURE 28 there is illustrated a diagrammatic view of the method in which the data packet is created and the database populated with the data packet.
  • a profile screen 2802 is provided which provides a plurality of user modifiable fields 2804 that allow the user to insert information. Each of these fields is utilized for the classification operation.
  • this is an interactive system wherein inserting information into one field will result in another type of field being made available. For example, if somebody were classifying a data packet as being associated with a network, it might be that the URL of the network were provided as a possible input for another classifier, whereas that particular classifier, the URL, might not be appropriate for a previous classifier.
  • the flow would move to a block 2806 wherein the information that is input by the user would be classified into the preamble of the appropriate ID in the data packet.
  • This would be required in order to classify all of the IDs in the JJD packet.
  • a co ⁇ orate name would be specified which automatically would pull up the core ID for that co ⁇ oration.
  • the device that is being utilized to fill in the profile would already be known and would constitute the device ID.
  • the remaining portion of the profile 2802 would be utilized for the pmpose of providing the item profile.
  • the classifier would assemble all of this information and then flow to a block 2808 wherein the data packet is populated and the database is populated, as indicated by block 2810.
  • This population of the database would provide information associated with the ID packet, as set forth in Table 3, such that all of the information necessary to identify a ID packet is contained therein.
  • Table 3 is as follows:
  • the ID packet now provides a method to "point" to a specific row in the database, due to the fact that all of the preambles and the time stamps exist.
  • Table 3 illustrated only a single ID in the ID packet, it should be understood that each ID packet is represented by all of the IDs, which comprise a single row in the database. This database is typically populated at the ID server and then the ID server, as described hereinabove, "pushes" all of the ID packets in the database to the respective account servers such as the conversion server, the router, etc. Also as noted hereinabove, some of these ID packets could identify processes.
  • FIGURE 29 there is illustrated a flow chart depicting the operation of entering a profile.
  • the program is initiated at a block 2902 and then proceeds to a block 2904 to enter the profile, this typically performed by a user. It could be that, additionally, a profile that is received in the form of a filled out "form" that is provided by some input device from a non-system user. That is, for example, ordering a product from a system node in a transaction. If the profile already exists, as determined by a decision block 2906, then the program will flow to a function block 2910 to use an existing ID.
  • the program will flow along a "N" path to a function block 2912 wherein a time stamp will be applied and then to function block 2914 where a sequence number will be assigned. Typically, if this particular device is creating new packets, a different sequence number will be attached to the various time stamp in a predetermined sequence. However, this could be a random sequence.
  • the program then flows to a function block 2916 to store the ID and then to a decision block 2918 to determine if more profiles are to be entered. This is also the destination of the function block 2910. If more are required, the decision block 2918 will flow back to the input of function block 2904 and, if not, the program will flow to an End Block 2920.
  • FIGURE 30 there is illustrated a diagrammatic view for defining a single ID in an ID packet.
  • This ID is associated with the profile for a butterfly catheter. This typically will be the item ID.
  • the user indicates it as being a permanent ID, aprofile and types out the word "cat"
  • the system will recognize all of the first three and last two classifiers as being identical to others in the system and it will also recognize that the term "butterfly" as identical to aprevious one that was entered. This type of search during the classification operation is performed by actually looking at the database in the non-coded column for the particular word in the field.
  • FIGURE 31 there is illustrated a diagram of a system for layering data packets received from different systems that are potentially "non-like" systems.
  • a system 3102 there are illustrated three systems, a system 3102, a system 3104 and a system 3106, labeled system "A,” "B” and "C,” respectively.
  • Each of these systems operates in a different environment and may actually have a different database structure.
  • database structure For example, one might utilize an Oracle database with a specific and clearly defined database structure and another system might utilize a different database structure.
  • Each of these database structures is an independent structure with possibly separate methods for identifying vendors and the such, i.e., there can actually be a different vendor number in each system for the same vendor or a different product number for a common product.
  • ID packets there can only be one common ID for a packet associated with any vendor or item. For example, if a field were present for an employee number associated with an employee, a field present for the days worked and a field present for the days out of the office, each of these particular types of data would be reflected in a different format in each database. Therefore, a specific employee number from one database would have to be converted into an ID packet format for the master system such that both systems employee number could be recognized, categorized and analyzed, or transferred from one system to the other.
  • Extents The manner for converting data and information in one database to the master system is provided by the extensions referred to hereinabove as "Extents,” that provide a software program for retrieving information from the non-master database and converting it to ID packets from the master system.
  • System 3102 has associated therewith an Extent 3108, system
  • Extent 3110 associated therewith
  • system 3106 has an Extent 3112 associated therewith.
  • Extents 3108 is operable to retrieve the data and forward it to a conversion server 3114 as ID packets.
  • the interface connection between the Extents 3108-3112 and the conversion server 3114 are illustrated as separate connections, but they are actually fransferred through the network. Additionally, there could be multiple inputs to the conversion server from different networks.
  • Each of the Extents is interfaced to an ID server 3116, which ID server 3116, which ID server 3116 is operable to "push" IDs for various items and the such to each of the associated Extents.
  • ID server 3116 which ID server 3116 is operable to "push" IDs for various items and the such to each of the associated Extents.
  • system 3102 had associated therewith database information that was to be converted over to an ID packet out of the ID packets associated therewith would be stored in the Extent 3108.
  • system 3102 would recognize for example, that each employee in its database required a separate ID packet to uniquely identify that employee. These would be set up by the ID server 3116 and pushed to the appropriate Extent 3108.
  • system 3102 fransferred an employee number as part of a data fransfer to the conversion server 3114 or any other account server on the system, it would be processed through the Extent 3108 and the appropriate ID packet generated, i.e., exfracted from the associated ID packet table of the Extent 3108, and then forwarded to the conversion server 3114.
  • the conversion server 3114 is illustrated as the destination of the information for the pmpose of layering, as will be described hereinbelow. However, it should be understood that all of the data will first go to a router and then to the appropriate account server, if necessary.
  • the illustration of FIGURE 31 is simplified for this example.
  • data from system A When data from system A is received for a particular conversion operation, it is stored in a database 3118 in a first location 3120. All the data from system 3104 is associated with a location 3122 and all the information from system 3106 is associated with a location 3124 in database 3118. This information is layered, such that common ID packet types, such as employee numbers, are arranged in a predetermined format. This is illustrated in a Table 3126, which is organized to illusfrate four ID packets, IDPl, IDP2, JJDP3 and IDP4. IDPl may be employee numbers which are arranged in three locations, such that they all are in a common column. It should be understood that each of the IDPs can be different for employee numbers, i. e.
  • each employee has a separate distinct ID packet.
  • system 3102 and system 3106 both had the same employee in their database, they would have a common ID packet associated with the ID server 3116, this being set up initially. It can be seen, therefore, that the layering system allows a transaction or an analysis to pull data from non-like systems, convert it to like data in an organized structure and dispose it in a common table that will allow analysis thereof.
  • FIGURE 32 there is illustrated a diagrammatic view of the transaction system for utilizing ID packets to converse between two systems through a master space.
  • this master space includes the router, the network mesh, the core servers, the ID server, etc. that are required to process data packets.
  • this system is illustrated with a block 3202 that defines the master data system.
  • the master data system is essentially a system that receives, routes and operates on data packets to perform processes, etc.
  • each of these ID packets constitutes a pointer to some process associated with traversal of information through the master data system 3202 from an origination point outside the system to a destination point outside the system through the master data system 3202 or to a point within the master data system for processing thereof.
  • This processing system is referred to with a block 3204 which is operable that is also provided a master ID server 3206 that contains the ID packets that are operable with the system, these referred to as internal ID packets.
  • These are differentiated from external ID packets for an external system, which is not disclosed herein.
  • an external system 3208 that interfaces with the master data system 3202 via a conversion block 3310, system 3308 having a local database 3312 that is associated with its native database language or structure.
  • a second system 3314 that is interfaced with the master data system through a conversion block 3316 and has associated therewith a native database 3318.
  • the master data system 3202 In order to operate in this manner, there must be some type of conversion to the master data space. This is not necessarily defined by the system itself, but, rather, the master data system 3202 through its ID server 3206 defines the manner by which each system will communicate therethrough. As such, this is a push operation with the definition. Not only are the parameters of the definition assigned, but the actual ID packet that is communicating therebetween. For example, there may actually be a common item, such as a catheter, that exists in both databases. By having this information determined by the master ID server 3206, an ID packet can be generated in the master ID server 3206 and associated with the same items in the two different databases 3312 and 3218.
  • the master ID server be able to identify the ID packet and associate it with the same item in two different databases such that, when pushing the ID packet to one of the systems, it also pushes the associated relationship to information in the database 3312 or 3318.
  • an employee number in database 3312 has a certain format and value that is set up in the master ID server 3206 as being related to a specific ID packet.
  • the ID packet is fransferred to the conversion block 3310, it is associated with its value in the database 3312. Therefore, whenever the value in database 3312 is sent to the conversion block 3310, this value acts as a pointer and the appropriate ID packet can then be forwarded to the master data system 3202.
  • FIGURE 33 there is illustrated an alternate embodiment of the embodiment of FIGURE 32.
  • system 3302 has associated therewith a master data system 3306 and a master
  • System 3304 has associated therewith a master data system 3310 and a master ID server 3312. There is provided one external system, system 3314 associated with system 3302 in a conversion block 3316 disposed between system 3314 and master data system 3306. There is associated in a local database 3318 with system 3314. ID server 3308 is internal to the master data system 3306. Therefore, whenever system 3314, which is part of system 3302, communicates with master data system 3306, it will use internal ID packets associated with the ID server 3308, as described hereinabove. However, when conversing with master data system 3310, the ED packets are different, they are those associated with ID server 3312, these being external to system 3302. Therefore, master data system 3306 has stored in ID server 3308 external ID packets associated with the external side of the system, i.e., all other systems that are external thereto.
  • System 3304 has associated therewith an external system node 3320, which communicates with master data system 3310 through a conversion block 3322 and also has associated therewith a local database 3324.
  • a data packet will be generated for information in the local database 3318.
  • the employee number would be extracted from D database 3318 with the conversion block 3316, as part of the overall transaction.
  • This employee number would be converted to an internal ID packet associated with system 3302.
  • information in the ID server 3308 would be utilized to determine the external data packet to be transferred to master data system 3310.
  • it could actually be the ID packet associated with the employee number that resides in ID server 3312.
  • it could be a joiner ID packet which is a negotiated ID packet between the two systems, such that the actual ID packet associated with the employee number in either of the systems 3302 or 3304 is not known to the other.
  • ID packet with a joiner ID packet, are transferred from master data system 3306 to master data system 3310, it is the processed in accordance with the transaction and fransferred to the conversion block 3322 as the appropriate ID packet for that employee number. This is then converted to the format of database 3324 and processed by system 3320.
  • FIGURE 34 there is illustrated a diagrammatic view of an example of a transaction.
  • this transaction it is desirable to have information about employees as to the number of days they worked and the number of days they did not work.
  • This information is analyzed in the master data system 3202. Therefore, the first thing that must be performed is a conversion from the employee number to a data packet, the days in information to a data packet and the days out information to a data packet.
  • the employee number has previously been determined through a profiling operation to be defined as a unique ID packet. Therefore, a relational database can be utilized to pull the employee number from a database that is associated with the conversion block.
  • the days in information canalsobea unique data packet.
  • the information is illustrated in a table 3402 in the native database. This is converted to a packetized value for a given row in a transaction packet.
  • the first ID packet, IDPKT P, 3404 is generated to indicate the process that is being carried out, i.e., employee information regarding the days in and days out as being fransferred to the master data system 3202 for the pmpose of evaluating information in a particular process. This is followed by an ID packet 3406 labeled "IDPKT EM" for the employee number. Followinged by that would be an ID packet 3408 for the days in. This is followed by an ID packet 3412 for the days out information. At the end of the information is provided a termination data packet 3418.
  • This is then "stacked" in a stack 3420 such that it is stacked in a processing string as opposed to an organized data structure of columns and rows. Since the data is comprised of data packets, it is possible to place the data in such an organization.
  • FIGURE 34A there is illustrated a diagrammatic view of how the database is populated with ID packets. It can be seen that there are two columns, one for employee and one for an ID packet that represents data in and data out. It can be seen that unlike data is stored in the second column, i.e., that the information regarding days in is different than that regarding days out in that it would normally be contained within different columns of a database. This facilitates the processing operation. Therefore, by utilizing ID packets, the ID packets can be assembled in single columns representing different data. Further, they can be assembled in the column in the sequence in which information is to be processed in the later analysis routine.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé permettant de communiquer entre un premier et un second systèmes différents. Les informations sont générées au niveau du premier système dans un premier format d'informations propre au premier système (302). Un premier système de conversion, lors d'une première opération de conversion, convertit les informations générées en un format d'espace maître, ce qui permet de générer une première transmission d'informations converties (304). Les premières informations converties sont ensuite transmises à un système d'informations maître (306). En réponse à la réception des premières informations converties au niveau du système d'informations maître, les premières informations converties sont acheminées vers un second système de conversion dans le format du système maître (308). Au niveau du second système conversion, les informations ainsi transmises sont converties du format d'espace maître à un second format d'informations lors d'une seconde opération de conversion de façon à fournir une seconde transmission d'informations converties, ledit second format d'informations étant propre au second système.
PCT/US2002/012589 2001-04-24 2002-04-23 Systeme et procede de transmission d'informations entre emplacements sur un reseau informatique WO2002087178A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02728880A EP1410586A1 (fr) 2001-04-24 2002-04-23 Systeme et procede de transmission d'informations entre emplacements sur un reseau informatique

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/841,135 US6950437B2 (en) 2001-04-24 2001-04-24 System and method for transmission of information between locations on a computer network with the use of unique packets
US09/841,425 2001-04-24
US09/841,135 2001-04-24
US09/841,425 US6801531B1 (en) 2001-04-24 2001-04-24 Distributed processing system and method

Publications (1)

Publication Number Publication Date
WO2002087178A1 true WO2002087178A1 (fr) 2002-10-31

Family

ID=27126239

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/012589 WO2002087178A1 (fr) 2001-04-24 2002-04-23 Systeme et procede de transmission d'informations entre emplacements sur un reseau informatique

Country Status (2)

Country Link
EP (1) EP1410586A1 (fr)
WO (1) WO2002087178A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6101189A (en) * 1996-11-20 2000-08-08 Fujitsu Limited Gateway apparatus and packet routing method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6101189A (en) * 1996-11-20 2000-08-08 Fujitsu Limited Gateway apparatus and packet routing method

Also Published As

Publication number Publication date
EP1410586A1 (fr) 2004-04-21

Similar Documents

Publication Publication Date Title
US7099350B2 (en) Method and apparatus for converting data between two dissimilar systems
US7646776B2 (en) Method and apparatus for generating unique ID packets in a distributed processing system
US20060126658A1 (en) System and method for transmission of information between locations on a computer network with the use of unique packets
US6975595B2 (en) Method and apparatus for monitoring and logging the operation of a distributed processing system
US7134075B2 (en) Conversion of documents between XML and processor efficient MXML in content based routing networks
JP4367650B2 (ja) 方法、コンテンツベースルータ、コンテンツベースネットワーク
US5974443A (en) Combined internet and data access system
US7814204B1 (en) Method of and system for analyzing the content of resource requests
EP0725523A2 (fr) Acheminement de messages de transaction dans un réseau numérique de communication
US20030135653A1 (en) Method and system for communications network
WO2002019146A1 (fr) Systeme et procede de messagerie electronique pour une remise amelioree de contenu multimedia riche
US8819135B2 (en) Method of performing data mediation, and an associated computer program product, data mediation device and information system
US6654892B1 (en) Methods and apparatus for permitting transactions across firewalls
WO2004023322A1 (fr) Procede et appareil de conversion de donnees entre deux systemes dissemblables
US6801531B1 (en) Distributed processing system and method
KR100965621B1 (ko) 디지털 통신 데이터에 액션을 트리거링 하기 위한 방법 및컴퓨터 시스템
WO2002087178A1 (fr) Systeme et procede de transmission d'informations entre emplacements sur un reseau informatique
CA2498324C (fr) Procede et dispositif permettant de generer des paquets a identification unique dans un systeme de traitement reparti
WO2003010907A1 (fr) Equilibrage de charge pour systeme de traitement distribue
WO2004036443A1 (fr) Generateur de code pour systeme de traitement distribue

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2002728880

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 2002728880

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP