Method and apparatus for tracking transactions in an enterprise computer network

In an enterprise network system a plurality of software systems are integrated using an enterprise wide software management system and communicate with a plurality of clients. At least one of the clients is functionally represented by a plurality of subclients through a midware which is transparent to the software systems. Communication destined for any of the clients interfaced through the midware is received by the midware and converted to a format suitable for communication with one or more of the subclients prior to transmission thereto. Correspondingly, communications received from one or more subclients is converted to an appropriate format by the midware and forwarding to the assigned destination. Communications received by the midware is further monitored for fields which are tracked. Upon receiving communications having fields being tracked, the midware stores a least a portion of the communication in a report table.

TECHNICAL FIELD

The present invention relates to the field of information exchange and retrieval in an enterprise computer network having a plurality of heterogenous software systems and a plurality of clients communicating with one another. More particularly, the present invention relates to the integration of a midware into the enterprise computer network for interfacing clients represented by a plurality of subclients with the software systems.

BACKGROUND OF THE INVENTION

In today's economy companies are frequently turning to software solutions to help integrate and streamline business processes and lower overall operational costs. For example, a typical business may include a variety of organizations such as accounting, purchasing, sales, warehousing, human resources, etc. The specialized needs of each organization leads to each organization using their own software system designed to handle the functions and tasks to be performed. For example, accounting may utilize a special financial software system which allows for convenient entry of a company's assets and liabilities while sales may utilize a different software system which allows for easy order entry and tracking.

Although each organization performs different functions it is, of course, necessary that the organizations exchange and retrieve information with one another on a timely basis. For instance, once sales has received a signed purchase agreement from a customer indicating that the customer has committed to purchasing a given number of products, the sales department must immediately inform the accounting department of the transaction such that the transaction may properly be logged in the accounting records. To communicate this information it is possible for an individual in the sales department to send a paper or electronic form to the accounting department indicating the transaction which has taken place. Unfortunately, such procedures are often cumbersome and result in errors. For such reasons, enterprise wide software management systems have been developed.

Enterprise wide software management systems integrate both heterogenous and homogeneous software systems such that information may be exchanged, retrieved and updated among many systems and clients in real time. For instance, in the example above, an enterprise wide software management system would provide the appropriate connectivity to allow the accounting records to be automatically updated upon an individual from the sales department entering information related to the new purchase order. Thus, there is no need for the sales department to track and forward this information consciously to the other appropriate organizations in the company thereby minimizing overhead and reducing the possibility of introducing errors into the information to be shared.

In order to provide the necessary connectivity among different software systems and other clients in a particular business or corporation, specialized consultants or other information services individuals are often contracted by the business entity to configure a given enterprise wide software management system to meet the precise needs of the company. Configuring an enterprise wide software management system to a particular companies needs may often take several months to several years to complete depending on the size of the project at hand.

As companies and businesses continue to grow and expand, a recent trend has been to integrate wireless communications into a company's network infrastructure to help further optimize operations. For instance, wireless communication devices may take the form of wireless bar code readers which are used in a company's warehouse to help track inventory, wireless pen computing devices which may be used by individuals on a manufacturing floor to log problems or request replacement parts, and wireless arm mounted terminals which may be used by warehouse pickers to receive orders for replacement parts in real time so that the order may be filled immediately. As the price of these and other wireless computing devices continues to drop, the use of such devices by a company to increase productivity and efficiency continues to grow.

In companies having an enterprise wide software management system it is desirous to integrate wireless computing devices into to the enterprise wide system in order to utilize the wireless computing devices to their maximum potential. For instance, prior to the introduction of wireless computing devices into a company's manufacturing facility, an enterprise wide software management system may have been configured to send all requests for replacement parts to a central computer near a company's stockroom of replacement parts. Pickers who physically fill the requests would periodically check and retrieve new orders from the computer system or inform the requester if parts were currently unavailable. Upon providing each picker with a wireless arm mounted terminals, however, it would be desirous for replacement part requests to be routed directly to the appropriate picker's wireless terminal by the enterprise wide software management system. Further, it would be desirous for the picker to be able to respond directly back to the enterprise wide software management system as to whether the order has been filled or if the parts were unavailable and to automatically update the appropriate software systems in the company of the picker's transactions.

While it may be possible to reconfigure the enterprise wide software management system to provide the appropriate connectivity between each wireless terminal and the other software systems in a company, such reconfiguration would be extremely costly and time consuming. For instance, during reconfiguration, the enterprise wide software management system may need to be taken off line for several days or months so that the system can be updated with appropriate routing commands for each new wireless terminal. Further, such difficulties of updating and reconfiguring the enterprise wide software management system would occur each time additional wired and/or wireless terminals was to be fully integrated into the company's network infrastructure.

Therefore, what is needed is a method and apparatus of integrating wired and wireless devices into an existing computer network running an enterprise wide software management system which overcomes the difficulties described above and others.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus for integrating one or more clients represented by a plurality of subclients into an existing enterprise wide software management system. Each subclient may take the form of wireless mobile terminals or other devices which may be introduced and removed from the enterprise computer network on a regular basis. Integration of the subclients into the enterprise wide software management system is accomplished by way of midware which serves to provide appropriate transformation and routing of communication between the subclients and one or more software systems within the enterprise wide software management system. Thus, the midware allows the enterprise wide software management system may communicate with the subclients without being reconfigured to communicate specifically with each individual subclient.

The midware is configured to appropriately transform, manipulate, and route communications originating from one or more software systems to one or more subclients. Further, the midware is configured to appropriately transform, manipulate, and route communications originating from one or more subclients to one or more software systems. In transforming communications from a data structure of a receiving device to a data structure of a destination device, the midware is also configured to actively obtain any incomplete or deficient information. For example, the midware may query additional devices for such information or, if available, provide the information from the midware's own internal tables.

In order to determine the appropriate routing protocol for a given communication, the midware maintains a set of tables. The tables define for the midware the appropriate action which needs to be taken to respond to a particular task. Further, the tables keep track of which subclients are currently available to perform each task/subtask. Availability of a subclient is determined based on whether the subclient is currently registered with the midware. If more than one subclient is available, the tables further include a priority scheme to determine which of the available subclients should be selected to perform the task at hand.

With respect to communications originating from the software systems, the operations performed by the midware typically takes one or two forms. The first type of operation is one in which the midware forwards a communication to a particular client. For example, if the midware receives communication from a software system directed to a first client, the midware tables may indicate to the midware that first client is represented by first and second subclients and that half of the communication should be forwarded to the first subclient and the other half of the communication should be forwarded to the second subclient. Prior to routing such information, the midware would also reconfigure the communications to an appropriate data structure for the first and second subclients. The second type of operation performed by the midware involves a situation where the midware is to provide a response to a communication it received on behalf of a client represented by the midware. As the client is actually represented by subclients, the midware forwards the appropriate instructions to one or more subclients, waits for a response from each of the subclients, performs other appropriate operations to provide information in a particular format, and then forwards a single collective response to one or more assigned destination devices. For instance, the midware may determine that a particular task received by the midware should be routed to three subclient following which the midware should obtain a response from each of the subclients and forward a collective response to the originating software system and one other software system. In the event one or more of the subclients do not respond to a request for information, the midware is further configured to query the non-responding subclients for the desired information. In responding to a request it is also possible that the midware obtains certain response data from other sources. For example, if the current time and date was to be included in a response, such information may be provided by the midware itself.

With respect to communications originating from the subclients, the types of operations performed by the midware also typically takes one or two forms. The first type of operation is one in which the midware transforms the communication to an appropriate data structure and forwards a subclient's communication without the need to retrieve additional information. For instance, the subclient's task may involve forwarding the information provided in its entirety to two different software systems. The second type of operation is one in which prior to forwarding the subclient's communication, the midware needs to retrieve additional information. For instance, the subclient's task may enlist the midware to query two other subclients for information which is then collectively routed to one or more software systems.

In addition to routing communications, the midware is also configured to track certain predefined transactions carried on by subclients and generate reports based on the transactions which have taken place. More particularly, during the routing of communications through the midware, the midware continually monitors for the predefined transactions and, if found, automatically updates an appropriate table with such information such that a report of all such transactions may ultimately be recovered.

The midware may also be configured to serve as the primary processing power and memory for one or more subclients. More particularly, in order to allow for “thin” mobile devices, the midware may perform a large portion of the processing tasks for a given mobile device and transmit communications to the mobile devices which allow the mobile devices to display the results. For instance, the midware may include a bar code parse circuit which parses decoded bar code data forwarded by a mobile device. Thus, mobile devices having bar code readers would not need to include the additional barcode parse circuitry within the device itself. By shifting these and other conventional processing tasks to the midware, the mobile device may be designed in a more cost effective manner.

According to one aspect of the present invention, a midware server for use in an enterprise computer network having an enterprise management system and a plurality of clients communicatively coupled to the enterprise management system is provided. The midware server includes a network interface for communicatively coupling the enterprise management system to at least one of the plurality of clients functionally represented by a plurality of subclients, and a task processing circuitry for converting at least a portion of communications received according to a first data structure compatible with one of the enterprise management system and a first of the plurality of subclients to a second data structure different than the first data structure compatible with the other of the enterprise management system and the first of the plurality of subclients.

According to another aspect of the present invention a midware server for use in an enterprise computer network is provided. The enterprise computer network includes an enterprise management system for communicating with a plurality of clients within an enterprise network. The midware server includes a first communication means operatively coupling the midware server to the enterprise management system; a second communication means operatively coupling the midware server to at least one client of the plurality of clients, the at least one client functionally being represented by a plurality of subclients coupled to the midware server via the second communication means, and means for mapping, according to a predefined criteria, all or part of a communication received from the enterprise management system and directed to the at least one client to at least one of the plurality of subclients functionally representing the at least one client.

According to another aspect of the present invention, a midware server for use in an enterprise computer network is provided. The enterprise computer network includes an enterprise management system for communicating with a plurality of clients within an enterprise network. The midware server includes a first communication means operatively coupling the midware server to the enterprise management system; a second communication means operatively coupling the midware server to at least one client of the plurality of clients, each of the at least one client comprising a plurality of subclients functionally representing the respective at least one client, and means for mapping, according to a predefined criteria, all or part of individual communications received from at least one of the plurality of subclients to the enterprise management system.

According to still another aspect of the present invention, a midware server for use in an enterprise computer network is provided. The enterprise computer network includes an enterprise management system for communicating with a plurality of clients within an enterprise network. The midware server includes a first communication means operatively coupling the midware server to the enterprise management system; a second communication means operatively coupling the midware server to at least one client of the plurality of clients, the at least one client functionally being represented by a plurality of subclients coupled to the midware server via the second communication means, and means for mapping, according to a predefined criteria, all or part of a task command received from the enterprise management system and directed to the at least one client as subtasks to at least one of the plurality of subclients functionally representing the at least one client, the task command representing a task to be carried out by the at least one client and the subtasks representing at least part of the task.

According to yet another aspect of the present invention a mobile terminal for use in an enterprise computer network having a midware for communicatively interfacing an enterprise management system with one or more clients each represented by a plurality of subclients is provided. The mobile terminal includes a portable housing, a processor disposed in the housing, and means for transmitting and receiving wireless communications coupled to the processor, wherein the mobile terminal registers with the midware server in order to transmit and receive communication with the enterprise management system.

According to still yet another aspect of the present invention an enterprise network having an enterprise management system and a plurality of subclients representing one or more clients communicating with the enterprise management system through a midware is provided. A method includes the steps of receiving communications at the midware from one of the enterprise management system and a first of the plurality of subclients, converting at least a portion of the communications received into a data structure compatible with the other of the enterprise management system and the first of the plurality of subclients, and transmitting the at least a portion of the communications to the other of the enterprise management system and the first of the plurality of subclients according to the data structure.

According to still yet another aspect of the present invention In an enterprise network having an enterprise management system and a plurality of subclients representing a client communicating with the enterprise management system through a midware is provided. A method includes the steps of transmitting by the enterprise network communication destined for the client, receiving the communication by the midware, converting at least a portion of the communication to a first format compatible with a first of the plurality of subclients and another portion of the communication to a second format compatible with a second of the plurality of subclients, and transmitting the at least a portion of the communication to the first of the plurality of subclients in the first format and the at least another portion of the communication to the second of the plurality of subclients in the second format.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will now be described with reference to the drawings in which like reference numerals are used to refer to like elements throughout.

Turning now toFIG. 1, an enterprise computer network20is shown in which an enterprise wide software management system30(hereinafter referred to as enterprise system30) is installed for integrating various software systems35and clients40. The enterprise wide software management system30may, for example, be a version of SAP, Bann, Oracle, PeopleSoft, or other network integration system as is generally known in the art. In the present embodiment, the network20is shown to include three heterogeneous software systems35operating in a hospital environment. In particular, system35arepresents a first software system operating in the hospital's accounting department, system35brepresents a second software system operating in the hospital's pharmacy department, and system35crepresents a third software system operating in the hospital's nursing department. Each software system35is configured to interface with a respective set of clients40in order to communicate and retrieve information. It is possible for two or more different software systems35to be configured to communicate with one or more of the same clients40. Further, the enterprise system30enables communications originating in one software system35to be shared with another software systems35where the communications may be transmitted to the clients40of the other software system35in accordance with instructions preconfigured into the enterprise system30. It will be appreciated that while the present embodiment depicts three software systems35operating in a hospital environment, the present invention is suitable for use with any number or software systems operating in any business, government, or other environment including, for example, technology, retail, finance, warehousing, transportation, perishable goods, etc.

In the present embodiment, each software system35is preconfigured to communicate with one or more of the clients40represented by c1-c9. With respect to each client40with which a software system35is configured to communicate, the software system35further includes prestored information related to the data structure or format in which communication is to be exchanged with each affiliated client40. For example, client c1may expect to receive information in a format defined by a first data structure which is different than a data structure in which client c2expects to receive data. Thus, the software system35maintains information related to the data structure of each device with which the software system35intends to communicate.

Each software system35of an enterprise system20is preconfigured to communicate with specified clients40using a predetermined format or data structure. An appropriate data structure is typically selected by the respective software system35for communication with a client40from preconfigured standards. For instance, the software system35may be designed to communicate with desktop computers connected to an ethernet LAN using one preconfigured standard. However, upon introducing clients40to the enterprise system20for which the software system35does not have a preconfigured standard for communication, the software system35would need to be reconfigured to communicate with such clients. Thus, for example, the introduction of wireless mobile devices to the enterprise system20often involve communicating using a specialized protocol which takes into account the mobile nature of such devices. As discussed in the background section, such reconfiguration of the software systems35is often time consuming and expensive. By including a midware server50(hereinafter referred to as midware50), the present invention provides an efficient manner in which devices may communicate with the software systems35in a non-conventional manner. Further, the midware server50provides an efficient manner to integrate multiple devices into an existing enterprise system20. In particular, the midware50allows for such integration of additional devices by representing a client40with one or more subclients75which are transparent to the enterprise system30and performing the steps needed to allow communication to take place. Thus, for example, a given software system35may be interfaced with two or more subclients75through the midware50even though the software system35is preconfigured to communicate with only one client40. Similarly, with respect to communications originating from the subclients75, the midware50reformats the communication into an appropriate format for routing to the appropriate software system35.

Advantages of the midware50may be seen with respect to the hospital environment depicted inFIG. 1. For example, the pharmacy software system35bmay have originally been configured (at the time of installation) to communicate with client c1which represents a computer system in which doctors input authorized prescribed drugs for each patient, and client c5which originally represented a single computer system in which nurses entered re-fill order requests. In order to provide faster service, the hospital later decides to provide each nurse with a wireless pen base computer in which the nurses automatically enter re-fill orders as they visit each patient and determine such a need exists. Rather than reconfiguring the software systems35to communicate with each individual nurse via their respective wireless pen based computer, the present invention allows the midware50to effectively represent all of the wireless pen base computers as a single client to the software systems35. Thus, each software system35continues to believe it is communicating with a single client c5, however, the midware50is programmed to automatically convert communications to appropriate data structures and route communications directed to client c5to one or more of the appropriate subclients75which collectively represent client c5. As additional wireless pen based computers or other devices are added or removed from the hospital for performing the re-fill order task, these devices may be introduced and removed through the midware50while remaining transparent to the software systems35.

Similarly, in the retail industry, an enterprise system30may have originally been configured to receive all inventory data from a single computer of a store. However, as wireless bar code reading devices become increasingly popular, inventory is often taken by a several individuals operating such devices on the retail floor. As such, use of a midware to interface the existing enterprise system with such additional devices provides a cost effective and efficient way of providing such integration.

Referring now toFIG. 2, a table80is shown exemplifying the manner in which the midware50may be configured to perform certain tasks. As will be discussed in more detail below, a task is initiated when an initiating device (whether it is a software system35, client40, or subclient75) transmits information to a client40which is represented by the midware50. The midware50, receives the communication and based on its content performs a particular task as represented by column81. More particularly, the communication includes a task request and an appropriate data structure associated with the task as represented in column82. Alternatively, the communication may include just the task to be performed and the receiving, which in this case is the midware50, may be preconfigured handle the task according to known data structure. In the present example, the data structure associated with task1is represented by D1, D2, D3, D4. For instance, if task1represents a request by the pharmacy software system35bto receive data related to certain drugs administered by a particular doctor then D1may represent the name of a first drug, D2may represent the name of a second drug, D3may represent the name of the doctor, and D4may represent the time frame of interest.

In order to perform task1, the midware50is shown to perform a series of preconfigured operations as depicted in column83. Each operation is indexed by a unit of time which represents the sequence in which the individual operations are performed. Thus, for example, each of the operations indexed by “Time 1” is performed by the midware50substantially simultaneously, while those operations indexed by “Time 2” occur at some time after “Time 1” etc. In order to perform task1, the midware50is shown to perform a series of subtasks. More particularly, at step85, the midware is shown to select a sub-client to perform subtask1which is to retrieve information related to drug D1. As will be discussed in more detail below, selection of a subclient to perform a particular subtask is handled through a task specific mapping table600(FIG. 11) stored in the midware50. In this particular example, the midware50is shown to have selected subclient5ato perform subtask1. Once the subclient has been selected, the midware50in step86sends to subclient5athe information needed to perform its subtask according to the known data structure for subclient5a. For instance, in the present example, subclient5ais a pen based computer assigned to the doctor at a first hospital and is configured to receive data in the form of a drug name (e.g. D1) and time period (e.g. D4) for which information is sought. Next, in step87, the midware50receives a data structure S1, and S2from subclient5a. For example, S1may represent the name of the drug for which information was requested and S2may represent the amount of the drug administered during the time period specified in D4.

Similar to that discussed above with respect to step85, the midware50in step88selects subclient5bto perform subtask2which in this case is to retrieve information related to drug D2. In the present example, subclient5brepresents a different pen based computer assigned to the doctor at a different hospital. In response to the data structure sent to the subclient5bin step89, the midware50is shown to receive data structure S3and S4wherein S3in this example represents the name of the drug D2and S4represents the amount of the drug D2that was administered during the time period specified in D4.

Referring to step92, the midware50is also shown to match the data structure D3with data structure L1in order to conform with one or more data structures of devices which are to be responded to in task1. For instance, in the present example D3represents the doctor's name by way of a series of alphanumeric characters. However, the data structure of certain systems with which the midware50is configured to respond may only accepts social security numbers and not actual names. As such, the midware50accesses a table which may be either external or internal to the midware50which allows the midware to retrieve the doctor's social security number L1based on the name provided.

In steps93-96the midware is shown to respond to various places according to the data structure shown. For instance, in steps93and94the midware50is shown to send a response data structure to a report table1000(FIG. 14) which stores the information in a report format as is discussed in more detail below. In step95and96the midware50is shown to send a predefined data structure to the initiating pharmaceutical software system35band to a second software system (e.g. accounting software system35a).

Continuing to refer toFIG. 2, a call for the midware50to complete task2is shown to involve the initiating system providing the midware50with data structure D5and D6. For instance, task2in the present example is a request by subclient8ato retrieve a particular patient's blood pressure. Correspondingly, D5represents the patient's name and D6represents a field indicating that blood pressure data is desired. Referring again to the midware operation column83, in step102the midware50is shown to match data structure D5with data structures L10and L11. As discussed above, the matching allows the midware50to obtain data in an appropriate format for communicating with other devices or places. In this example, the patient's name D5is matched with the patient's room number L10and bed number L11. Thus, the midware50is able to communicate with those devices having a data structure which represents a patient by a room and bed number rather than the patient's name. In order to perform the matching, the midware50may access a table stored internally or an external table.

Next, in step103the midware50transmits a data structure having fields L10, L11and D6to a first system which in this case is the nursing software system35c. In response, the midware50receives in step104a data structure from the nursing software system35cwhich includes field D7which represent the patient's blood pressure. Finally, in steps105and106the midware50sends the data in accordance with a corresponding data structure shown in the table to both the initiating device (subclient8a) and to the report table1000for logging.

While the above examples serve to exemplify some of the functions of the midware50, it will be appreciated that midware50is able to perform a variety of other functions described herein and the example shown inFIG. 2is not meant to encompass the full operational scope of the midware.

Referring now toFIGS. 3a-3f, a summary of several midware routing protocols is shown in which the midware50interfaces two software systems35a,35bwith two subclients75a,75b. In the present example, the two subclients75a,75brepresent a single client X. As discussed above, however, that the midware50can of course interface multiple clients40each represented by a plurality of subclients75. The procedure for determining how information is routed by the system35and by the midware50is discussed in more detail below. For the present example, however, it is assumed that each system35a,35bis configured to transmit information to client X through the midware50. Additionally, the midware50is configured to route some or all of the information destined for client X to one or both subclients75a,75bdepending on the task and subtasks at hand.

Beginning withFIG. 3a, there is shown a scenario where a single system35atransmits information “I” to client X which is handled by the midware50. Upon receiving the information “I” the midware50determines that the task at hand involves communicating a portion of the information “I” to subclient75aand a portion of the information “I” to subclient75b. As such, the midware50routes a first portion of the information to subclient75aas depicted by “Ia” and a second portion of the information to subclient75bas depicted by “Ib”. For example, the nursing software system35cmay be transmitting information to a computer system (e.g. client X) on the third floor of a hospital to administer drugs to patient y and patient z. The third floor computer system is, however, now represented by the midware50which receives the communication from the nursing software system35cand performs the necessary conversions to forward information related to patient y (e.g. Ia) to subclient75aand information related to patient z (e.g.1b) to subclient75b.

FIG. 3brepresents a situation in which the midware50receives information “Ia” from subclient75aand information “Ib” from subclient75bfor routing to system35a. This situation may, for instance, arise following a request by the midware50for each subclient75a,75bto respond to a particular subtask. InFIG. 3bthe midware50is shown to combine the data received from both subclients75a,75band forward a single communication “I” to the system35ahaving the combined data. It will be appreciated that the information “Ia” and “Ib” to be combined and forwarded to the system35amay be received simultaneously or sequentially in time by the midware50. Further, it is possible that if either one or both of the subclients75a,75bhad failed to provide the midware50with the information to be forwarded to the system35awithin a predetermined period of time from when the midware50expected to receive the information, the midware50would have queried the non-responding subclient75a,75bfor the missing information.

FIG. 3crepresents a situation where a single subclient75atransmits information “Ia” to the midware50which is then routed by the midware50to both system35aand system35b. As will be discussed in more detail below, the midware50may transmit all or part of the information “Ia” it receives from the subclient75ato each system35a,35bas depicted by “I1” and “I2” respectively. Further, it will be appreciated, that the information contained in “I1” and “I2” may include additional information obtained by the midware50from other sources.

FIG. 3drepresents a situation where two systems35a,35btransmit information “I1” and “I2” to the midware50for routing to client X and in which the midware50combines the information and routes the combined information to subclient75a. The information “Ia” routed to subclient75amay include some or all of the combined information “I1” and “I2” received from the systems35a,35band/or additional information obtained by the midware50from other sources.

FIG. 3erepresents a situation in which system35atransmits information “I1” to the midware50at approximately the same time system35btransmits information “I2” to the midware50and wherein the midware50routes a first portion “Ia” of the combined data to subclient75aand a second portion “Ib” of the combined data to subclient75b. As with previous examples, the portions “Ia” and “Ib” of the combined data to be routed to each subclient75a,75bby the midware50may each include the same information or may include different portions of the combined data as determined by the midware50.

FIG. 3frepresents a situation in which subclient75aand subclient75beach transmit information “Ia” and “Ib” to the midware50and in which the midware50routes some or all of the combined information to each system35a,35b. Similar to the example ofFIG. 3b, it is possible that if the midware50does not receive information from both subclients75a,75bwithin a predetermined period of time, the midware50may be configured to query for the missing information prior to forwarding the information to the respective systems35a,35b.

It will be appreciated thatFIGS. 3a-3frepresent just a few examples of the possible routing protocols which the midware50is configured to handle. However, as can be seen from these examples, the midware50serves to interface subclients75with software systems35by virtue of assuming the identity of one or more clients from the perspective of the software systems35. Thus, the software systems35which are configured to communicate with one client at a time are now able to effectively communicate with multiple clients at a time through the midware50. As additional subclients75such as mobile terminals98are added to a network20, the additional subclients75may be configured to communicate through the midware50thereby minimizing the amount of re-configuration needed to the enterprises system30to incorporate the new devices.

Referring again toFIG. 1, clients c1, c2, c3, c4, c6, and c7each interface with software systems35a,35b, respectively, via a common physical network connection45. The network connection45may, for instance, be an ethernet, token ring, local talk, or other known network connection. Clients c5, c8and c9interface with the software systems35via the midware server50. In the present embodiment, systems35aand35binterface with the midware50via the network connection45while systems35cis directly connected to the midware50via a direct physical network connection60.

In the present embodiment, clients c1, c2, c3, c4, c6, and c7each represent computer system located at various local and remote locations from the software systems35. For instance, client c1-c4may be located within the same building as one or more software systems35, while clients c6and c7may be located at a regional offsite office, warehouse, or other facility. Clients c5, c8and c9may similarly be located local to or remote from software systems35and are each functionally represented by two or more subclients75. More particularly, client c5is shown to be represented by three wireless subclients5a,5b, and5c, client c8is shown to be represented by three wireless subclients8a,8b, and8cand client9is shown to be represented by two subclients9a,9bwhich are each directly connected to the midware50via conventional network connections37and38, respectively.

Referring now toFIG. 4, the interface between the midware50and subclients75is shown in more detail. As shown, a plurality of mobile terminals98which include wireless subclients5a-5cand8a-8care coupled to the midware50via a first and second LAN100,110respectively. Each LAN100,110includes a plurality of access points125for interfacing the mobile terminals98with one or more devices coupled to the LAN100,110. For instance, mobile terminals98may communicate via an access point125with the midware50, host computers115,116, other mobile terminals98and/or with devices coupled to other LANs via bridge135,136. In order to allow for wireless transmission and receipt of data, each access point125and each mobile terminal98include an antenna140. As is conventional, the type of antenna selected plays a significant factor in determining a particular device's communication cell coverage area. In the present embodiment, the antennas140are each omni directional antennas thereby providing for a generally spherical cell coverage. It will be appreciated, however, that directional, yagi and other types of antennas could alternatively be used to define a variety of cell coverage shapes and sizes.

In order to allow for transparent routing of information, each mobile terminal98registers with and communicates through a selected access point125in the mobile terminal's98cell coverage area. If the mobile terminal98roams out of cell coverage area of the access point125with which it is currently registered, the mobile terminal98attempts to register with a new access point125in order to maintain substantially fluid connectivity with the LAN100,110. Registration of a mobile terminal98with a new access point125triggers the new access point125to inform all other access points125on the particular LAN100,110of the new registration thereby ensuring that only one access point125routes communication to and from the particular mobile terminal98at any given time. The access points125each maintain a table of those mobile terminals98currently registered therewith and monitor for communications destined to or received from such mobile terminals98in a conventional manner. Thus, devices attempting to communicate with a given mobile terminal98do not need to continually track the current location of the mobile terminal98since the access points125serve as a transparent interface for appropriately routing such information.

Referring now toFIG. 5, the internal hardware components of the midware50is shown in more detail. As shown, the midware50includes a midware processor200such as a 300 MHZ Intel Pentium II processor for carrying out the operations of the midware50. A memory210is coupled to the processor200and stores data and executable code in order to perform the functions described herein. Also shown coupled to the processor200is a barcode parse circuit212which is discussed in more detail below. A conventional physical interface220provides interconnection of the midware50with the network backbone45, direct physical network connection60,37,38, and LANs100,110. The physical interface220couples to the processor200through a series of buffers225. Each of the buffers225serves as a latch for storing task requests from the software systems35and subclients75. In the present embodiment, the processor200samples and executes the pending tasks stored in the buffers35every 500 msec. Of course, the frequency at which the processor200samples the buffers35may be varied depending on system traffic and needs. Upon periodically receiving information from the software system buffers225via lines230and the subclient buffers225via line231, the processor200clears the content of each buffer225by way of asserting reset line235.

Referring now toFIG. 6, a software system configuration table275is shown. The software configuration table275is maintained as part of the enterprise system30and serves as a way of routing communication between each software system35and client40in the network20. The configuration table275is shown to be divided into three columns. The first column277represents each software system35in the network20, the second column279represents each of the clients40with which a particular software system35may communicate through the enterprise system30, and the third column281represents an assigned address of each of the clients40in the network20. As shown in column281, a midware programmer stores the midware address in the software system configuration table275for each client which is coupled to the midware50thereby making the subclients of each client transparent to the software system. In this manner, all communications directed to such clients is automatically routed directly to the midware50. In the present embodiment, the midware address has been assigned to client5, client8, and client9(seeFIG. 1) in each of the software systems35. As the midware50may be configured to interface with any number of subclients75, the software systems35are also effectively able to communicate with such subclients75by virtue of directing communication to a client40having the midware's address.

In order for the midware50to recognize whether a particular subclient is currently active, each subclient75of the present embodiment is configured to register with the midware50at startup and to de-register with the midware50upon the subclient75becoming inactivated or otherwise taken off line. The registration and de-registration routine for each subclient75is depicted inFIG. 7. More particularly, following startup at step300, the subclient300proceeds to step310where the subclient50transmits a registration request to the midware50. For example, if the subclient75is a mobile terminal98, then the subclient75wirelessly transmits the registration request to the midware50via the access point125with which the mobile terminal98is currently registered. Alternatively, if the subclient is75is physically coupled to the midware50as with subclients9aand9b(FIG. 4), then the subclient75directly sends the registration request to the midware50via the particular subclient's direct physical connection37,38. Following transmission of the registration request, the subclient75in step315determines whether a response has been received from the midware50within a time out period. If no response has been received, the subclient75proceeds to step320where the subclient75waits a predetermined period of time before returning to step310and re-transmitting the registration request.

If, however, in step315the subclient75has received a response from the midware50, the subclient50proceeds to step325where the subclient75registers with the midware50and responds to any information queries. For instance, prior to completing registration the midware50may request that an operator of the subclient75enter a user name and password in order to authenticate user access. Once all such requests are responded to by the operator, the subclient75registration process with the midware50is complete and the subclient75and midware may communicate with one another as depicted by step330. During communication with the midware50, the subclient75in step335continually monitors itself to determine whether an operator initiates a log-off routine. If an operator has not initiated a log-off routine, the subclient75returns to step330and maintains the communication session with the midware50. If, however, in step335the an operator has initiated a log-off routine, the subclient75continues to step340. In step340, the subclient75transmits a de-registration request to the midware50indicating to the midware50that the subclient75is about to become inactive. Following transmission of the de-registration request, the communication session between the subclient75and midware50is ended.

Turning now toFIG. 8, the operations of the midware processor200during registration of a subclient75to the midware50is depicted. In step400, the midware processor200determines whether it has received a registration request from any subclient75. If no registration requests have been received, the midware processor200returns to step400. If a registration request is received, the midware processor200proceeds to step410. In step410, the midware processor200requests any additional information needed prior to registering the subclient75with the midware50. For instance, as briefly mentioned above, the midware processor200may be configured to request a user ID and password prior to registering the subclient75. Following step410, the midware processor200continues to step415, where it is determined if the information requested is received before a time out period and if so, if the received information is correct. If the information received is deemed incorrect or is not received prior to the time out period, the midware processor200returns to step410where the information is again requested. If, however, the correct information is received prior to the time out period in step415, the midware processor200proceeds to step420. In step420, the registration with the subclient75is complete and the midware processor200activates the newly registered subclient75in the midware's task specific mapping table600, as described in more detail below with respect toFIG. 11.

Turning now toFIG. 9, the operation of the midware processor200during de-registration of a subclient75to the midware50is depicted. More particularly, at step450the midware processor200determines whether a de-registration request has been received from a subclient75. If a de-registration packet has been received, the midware processor200proceeds to step460where the subclient75transmitting the de-registration request is deactivated in the task specific mapping table600and communication between the subclient75and the midware50is ended. If, however, in step450a de-registration request is not received, the midware processor200proceeds to step455. In step455, the midware processor200determines whether the midware50has been unable to reach a particular subclient75for a predetermined period of time. For example, the midware processor200may be attempting to forward to a particular subclient75information received by the midware50from one or more software systems35. If, however, the midware processor200is unable to contact the subclient75for the predetermined period of time the midware processor200assumes that the subclient75has been turned off without de-registering. Alternatively, if the subclient75is a mobile terminal98, it may be that the subclient75has been moved out of communication range. Regardless, if the midware processor200determines that a response has not been received from the particular subclient75within the predetermined period of time, the midware processor200continues to step460where the subclient75is de-registered from the midware50by virtue of deactivating the subclient75in the task specific mapping table600. If, however, the subclient75has responded in sufficient time or if the predetermined period of time has not expired, the midware processor200returns to step450.

Referring now toFIG. 10, there is depicted the operations of the midware processor200in performing a task involving communications received from one or more software systems35and destined to a client represented by one or more subclients75. In step500, the midware processor200determines whether it has received any requests to communicate with a client40coupled thereto. For instance, in the present embodiment, the midware processor200determines whether any software system35is attempting to communicate with clients c5, c8, and/or c9. In order to determine if any requests have been received to communicate with such clients, the midware processor200periodically checks for requests pending on line230(FIG. 5). As mentioned above, in the present embodiment, the midware processor200is configured to check for requests every 500 msec. If no requests to communicate with the clients40represented by the midware50are pending, the midware processor200returns to step500. If, however, in step500the midware processor200determines one or more of such requests are pending, the midware processor200proceeds to step510.

In step510, the midware processor200accesses its task specific mapping table600which is stored in memory210(FIG. 5) to select the appropriate subclients75to perform the specified task or tasks requested by the software system(s)35. More particularly, as seen inFIG. 11, the task specific mapping table600includes a column605of all known tasks handled by the midware50. In particular there is shown entries for task1through task (n), where n represents the total number of tasks handled by the midware50. As discussed above with respect toFIG. 2, the tasks may involve communications received from a software system35, a client40, a subclient75, and/or other devices in the network20. Further, some of the tasks entered in column605may represent a task which corresponds to a combination of tasks which need to be performed in the event two or more devices place requests to the midware50at the substantially the same time. It will be appreciated, however, that rather than entering a single task in the task specific mapping table600for each combination of tasks requested of the midware50, the midware may alternatively handle both tasks individually. Also as discussed above with respect toFIG. 2, each task has associated therewith a data structure which the midware50expects to see when called upon to do that particular task. The data structure is stored in column610of the task specific mapping table600.

As shown in column615of the task specific mapping table600, each task has associated therewith one or more subtasks. Similar to the lists of tasks stored in column610, the subtasks are each prestored in the task specific mapping table600and provides the midware50with information on how a given task is to be divided. For instance, as shown in column615, task1is divided into three subtasks, namely subtask1, subtask2, and subtask3. As discussed above with respect to the examples provided inFIG. 2, the purpose of each subtask is typically to either obtain a portion of the complete information needed to accomplish the task at hand and/or to communicate a portion of information to a particular device.

With respect to each subtask in column615, there is stored in column620a list of authorized subclients75which may perform the subtask at hand. For instance, with respect to task1, subtask1, the authorized subclients75for performing subtask1are subclients5aand5b. Similarly, with respect to task1, subtask2, the authorized subclient75for performing subtask2is subclients5a,5b, and5c. In some instances there may only be one authorized sub-client75to perform a subtask as shown with respect to task1, subtasks1and2. Further, in some instances the authorized subclients may include two subclients75from different clients40as shown with respect to task4, subtask1. Thus, despite the fact that a particular software system35requests to communicate with a single client (e.g. client5), the midware50may be programmed to retrieve the information requested from subclients75of various different clients40depending on which subclients75are stored in the task table for performing the subtasks at hand. Further, it will be appreciated that certain tasks may be accomplished without communicating with a subclient75or a software system35. For example, this is shown with respect to task1, subtask3and task2, subtask1in which the information is obtained from an internal and external table, respectively.

In order to prioritize the order in which the midware processor200selects a particular subclient75or subsystem35to perform a subtask, the subclients75are entered into column620in order of highest priority first. Thus, for example, with respect to task1, subtask1, subclient5ais of higher priority than subclient5b. Optionally, the midware processor200may be programmed to dynamically reprioritize the priority level of each subclient based on criteria such as the quantity of tasks currently queued for a particular subclient, the location of the subclient, the number of errors received in communicating with the subclient, etc.

In order for the midware processor200to select the appropriate subclient75for performing each subtask, the midware processor200initially determines which subclients75listed in column620are currently active. As discussed above with respect toFIGS. 8 and 9, a subclient75is activated upon registering with the midware50and remains active until the subclient logs-off or fails to respond to the midware50within a predetermined period of time. Thus, in order to select the appropriate address of the subclient75to be stored in column625of the task specific mapping table600, the midware processor200in step510(FIG. 10) selects the highest priority subclient75which is currently active for each subtask. As subclients75register and de-register with the midware50, column625is updated accordingly.

Referring again toFIG. 10, based on the subclients75selected to perform each subtask in step510, the midway processor200continues to step515where the subtasks are transmitted to the appropriate subclients75for the particular task at hand. Once transmitted, the midware processor200proceeds to step517. In step517, the midware processor200determines whether the any subtasks transmitted to the subclients75are of a type which requires a response. If not, the midware processor200ends its operation. If, however, the midware processor200determines in step517that one or more responses are expected, the midware processor200proceeds to step520. In step520the midware processor200monitors to determine whether a response has been received from each of the subclients75contacted for a particular task.

In order to keep track of whether each subclient75associated with a particular task has responded has responded to a subtask request, the midware50maintains a received response column740in a translation table700(FIGS. 12a-12c). More particularly, as shown inFIG. 12a, the translation table700includes an entry for each task705which the midware50is configured to handle. With respect to each task entry, the midware50maintains a list of entries which relate to how and when the midware50should respond to a task as is discussed in more detail below. The type of information stored in the translation table700is shown by way of example inFIGS. 12band12c, whereFIG. 12brepresents a task which originated  from a software system35andFIG. 12crepresents a task which originated from a subclient75. Thus, in the present case, for each subclient75associated with a particular task, the translation table700stores in its received response column740whether the subclient75has responded to the most recent subtask request. If after a predetermined period of time, the midware processor200determines that all the subclients75for a particular task have not responded, the midware processor proceeds to step535.

In step535, the midware processor200re-transmits the subtask request to those subclients75which have not yet responded to the initial request transmitted in step515. Next, in step540the midware processor200again waits to determine whether the remaining subclients75have responded before a time out period. If one or more subclients75selected to perform the subtasks of a given task do not responded before the time out period in step540, or if a response is incomplete in any way, the midware processor200proceeds to step545to determine if there are any error handling routines. More particularly, referring again to the translation table700ofFIG. 12b, for each subclient75there may be associated one or more error codes stored in column745and a corresponding number of error handling routine stored in column750. If there are error handling routines associated with a particular subclient, then the midware processor200proceeds to step550. In step550, depending on the particular error occurring in attempting to obtain information from a subclient75an appropriate error handling routine is invoked by the midware processor200. For instance, error code1may represent the error handling routine to be invoked if a particular subclient only provided the midware50with a portion of the information requested. In such a situation, the error handling routine may be configured to have the midway processor200re-transmit a request to the subclient75requesting the missing information. Alternatively, the error handling routine may be configured to place filler data in the fields not completed by the subclient75. Of course, a variety of other error codes and corresponding error handling routines may be stored in the software translation table700as desired for each subclient75. Following completion of the error handling routine in step550, or following a determination that there are no error handling routines in step545, the midware processor200ends its routine.

Continuing to refer toFIG. 10, if in step520or step540the midware processor200determines that all of the subclients75contacted to complete a given task have responded, the midware processor200continues to step525. In step525, the midware processor200obtains any additional information needed to complete all of the fields of the task at hand. The location of the information needed to complete all fields not already at the midware50is shown in column735of the translation table700(FIG. 12b). For example, as depicted inFIG. 12b, fields S1and S2are obtained from subclient5awhile fields S3and s4are obtained from subclient5b. The additional fields may be obtained from one of a variety of different sources. For instance, fields D1, D2, and D4were each communicated to the midware with the original task request as shown inFIG. 11, column610. Additional fields may be obtained from one or more tables prestored in the midware memory210, from external tables retrieved by the midware processor200or other locations. Upon acquiring the additional information, the midware processor200proceeds to step530.

In step530, the midware processor200provides a response to the software systems35or other devices in accordance with the information stored in columns715and720of the software translation table700(FIG. 12a). More particularly, the translation table700maintains a predefined list of devices which are to be responded to as depicted in column715. Further, the translation table700maintains column720indicating the type of system with which the midware processor200is to respond so that the midware processor200may properly format the response. Thus, for example, upon obtaining all of the information requested by task1, columns715and720indicate to the midware processor200that the report table1000(FIG. 14) should receive two different data structures according to the fields shown in column730of table12b. Further, the midware50should forward to the pharmacy software system35bin 3270 Emulation format the respective data structure shown in column730. Similarly, the midware50should forward to the accounting software system35ain ODBC format the data respective data structure shown in column730. Of course, the midware processor200may be configured to communicate information according to other known formats such as HL7 and others as is well known in the art.

Referring now toFIG. 13, the operations of the midware50is shown in which the task to be performed results from unsolicited messages from one or more subclients75for routing to one or more software systems35as is the case with task2. Beginning at step800, the midware processor200determines whether any unsolicited communications from a subclient75has been received. If the midware processor200determines that no unsolicited communications have been received, the midware processor200returns to step800. If however, the midware processor200determines that an unsolicited communication has been received, the midware processor200proceeds to step815. In step815, the midware processor200determines if additional information is needed from any device prior to completing the task at hand. For instance, with respect to task2shown inFIG. 12c, the nursing software system35cis needed to respond to the midware50in order to obtain field D7as shown with respect to columns735and740. It will also be appreciated that there may be instances where a task initiated by a subclient75requires input from other subclients75before responding to the device listed in column720for that particular task. Thus, if in step815the midware processor200determines that all of the fields needed to respond to the devices associated with a given task are available, then the midware processor200proceeds to step850. If, however, the midware processor200determines that additional fields are needed prior to responding to the devices, then the midware processor200proceeds to step820.

In step820, the midware processor200determines which fields of information from column730(FIG. 12c) are missing and then sends out a request to each of the corresponding devices shown in column735to forward the missing information. Following step820, the midware processor200in step825determines if all of the requests for information have been responded to before a predetermined period of time. If all of the requests for information have not been responded to before the predetermined period of time, the midware processor200proceeds to step830. In step830, the midware processor200re-transits a request for information directed to those subclients75which have not responded to the request transmitted in step820. Following the re-transmitted request(s), the midware processor200in step835again determines if all of the requests have been responded to prior to a predetermined time out period. If all of the requests still have not been responded to, the midware processor200proceeds to step840where the midware processor200determines if there are any error handling routines as shown in columns745and750ofFIG. 12c. If there are any error handling routines, the midware processor200selects the appropriate error code and proceeds to step845where the corresponding error handling routine is executed. Following completion of the error handling routine in step845, or if no error handling routines is available as determined in step845, the midware processor200ends its routine.

If the midware processor200determines in any of steps815,825, or step835that all of the information needed to communicate with the devices associated with a particular task has been received, the midware processor200proceeds to step850. In step850, the midware processor200obtains any additional information needed to complete the fields shown in column725. Finally, in step855the midware processor200provides all the information associated with a particular task to the corresponding device shown in column715in the appropriate data structure as defined by column730.

Turning now toFIG. 14, there is shown a series of report tables1000which are maintained in memory210of the midware50. Each report table1000is continually updated with information related to a specified transaction being tracked as provided in column1010. More particularly, with respect to each table1000, there is included up to “n” columns/fields which are tracked and updated by the midware processor200on an ongoing basis. In order to maintain each table1000with accurate information, the midware processor200is configured to review and distinguish communications routed through the midware50for information related to the transactions being tracked by each table1000. For instance, if monitoring for blood pressure data, the midware processor200reviews all communication for field D7discussed above with respect toFIG. 2. If found, the communication is then parced according to the fields being stored in the table1000. It will be appreciated that the communications received by the midware may correspond to communications between a subclient75and host computer115,116(FIG. 5), a subclient75and other subclients75, between a subclient75and a software system35, and between two or more software ware systems35. If a transaction being tracked in found, the midware processor200automatically enters the associated fields in the appropriate columns and row of the report table1000. For instance, with respect to report table1100, a hospital may desire to track the number of blood tests administered during a given time period. In doing so, the hospital may also desire to track the subclient75associated with the administration of each blood test1020, the time and date the blood test was administered1030, the name of the patient1040, and other relevant information1050. Thus, each time the midware processor200receives communication related to a blood test, the midware processor200automatically enters the desired information into the blood test table1100. Similarly, information related to the other report tables1000is also automatically entered according to the fields being tracked.

Turning now toFIGS. 15 and 16an embodiment of a mobile terminal98in accordance with the present invention is depicted in which the mobile terminal98serves as a thin device1200. As will be explained in more detail below, a mobile terminal of the present embodiment is termed a thin device1200when a large percentage (e.g. >50%) of a mobile terminal's processing and storage is handled by the midware processor200and memory210(FIG. 5). In such situations, the mobile terminal may operate using a reduced amount of circuitry and processing power, thereby making the mobile terminal less expensive, light weight, and less power consumptive.

As shown inFIG. 15, the thin device1200includes a portable housing1210having a pressure sensitive display screen1215and a keypad1220disposed therein. Further, the thin device1200includes an electronic pen1225electrically tethered to the portable housing1210for inputting commands via the display screen1215. A bar code reader1227is disposed along a top portion of the portable housing1210and allows for reading of 1-D and 2-D bar codes as is known in the art. An antenna1230coupled to the portable housing1210allows for the wireless transmission and receipt of data.

As best seen inFIG. 16, the internal components of the thin device1200is shown in more detail. A processor1250couples to a bus1260and serves to communicate with processor210of the midware50via RF transceiver1270for controlling the operations of the thin device1200. A memory1275also couples to the processor1250and serves to store data and executable code. The keypad1220couples to the processor1250via a keypad scan circuit1280through which the processor1250determines when a key on the keypad1220is depressed. The display1215couples to the processor1250through display driver circuit1285which functions to activate and deactivate appropriate pixels of the display screen1215to produce a desired message. The bar code reader1227couples to processor1250via decode circuitry1290. In the present embodiment, the decode circuit1290serves to decode a 1-D or 2-D bar code into its underlying code format such as ASCII code. However, in order to minimize circuitry in the thin device1200, the parsing of the decoded bar code data is performed by the barcode parse circuit212coupled to the midware processor200(FIG. 5). Power is provided to the thin device1200via power source1280and is distributed to the components of the thin device via power control circuit1290.

The invention has been described with reference to the preferred embodiments. Obviously, modifications and alterations will occur to others upon reading and understanding the preceding detailed description. For instance, while the embodiments discussed above refer to the midware50storing a variety of table related to routing of information between software systems35and subclients75, it will be appreciated that the midware50may combine one or more table into a single table, or may store the information according to one of a variety of alternative techniques. It is intended that the invention be construed as including all such modifications and alterations.