Method and system of communication for automated inventory systems

Abstract

Various embodiments of this invention are directed towards the communication infrastructure of an automated inventory system, on which the necessary communication between a dispensing unit and an administrative unit of the system occurs. To facilitate the integration of the automated inventory system into the client's computer network, the infrastructure is preferably implemented using hypertext transfer protocol (http) or its secured counterpart (https). In certain embodiments the administrative unit is located external to the client's network, beyond the client's firewall. In these embodiments it is preferable to have the dispensing unit initiate communication with the administrative units because the firewall is typically setup to reject external connection requests.

Description

PRIORITY INFORMATION

This application is a continuation of U.S. patent application Ser. No. 10/100,219, filed Mar. 15, 2002, and also claims the benefit of U.S. Provisional Patent Application No. 60/276,054 filed Mar. 15, 2001, the entireties of which are incorporated by reference herein and made a part of the present disclosure.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to a method and system of communication for a dispensing system. Specifically, the embodiments of this invention are directed towards the communication infrastructure of an automated inventory system.

2. Description of the Related Art

In most industrial operations, supplies are stored in centrally located storerooms, tool cribs or lockers. These supplies are manually requisitioned and taken to a work area to be used. The removal of these supplies is later input into an inventory system, often manually. Due to the inherent lag between removal and input, the inventory data is rarely up-to-date.

Thus frequently supplies that appear to be available on the inventory system may actually have been already used. When supplies reach critically low levels, they have to be reordered on an expedited or emergency basis, often at a premium, to minimize disruption of the work flow. The alternative is to maintain inventory at an unnecessarily high level, which increases overhead costs and decreases cash flow.

As long as inventory data is updated in an auditing manner, i.e., post use, it cannot reflect the actual availability of supplies. This shortcoming is exacerbated by increases in the turnover rate of supplies. When the turnover of supplies is slow compared to the lag, the probability of critical shortages is small. However, as the turnover of supplies increases, so does the lag because more inventory data has to be input, thereby increasing the likelihood that supplies that appear as available on the inventory system have already been used. Thus the frequency of critical shortages also increases.

SUMMARY OF THE INVENTION

To eliminate the lag, inventory data may be updated at the point-of-use. As doing so manually is too cumbersome, an automated inventory system that captures inventory data at the point-of-use, i.e. when supplies are removed, is desirable. In such an automated inventory systems, a user enters his user id (and optionally a password) into a dispensing unit, which records the quantity of supplies taken by him and automatically updates inventory data. Point-of-user information provides an additional advantage in allowing user efficiency and waste to be tracked.

The viability of such an automated inventory system often hinges upon the convenience of using its dispensing units. If doing so is inconvenient, users will hoard or stockpile supplies to minimize the inconvenience. This leads to an opposite problem, in which supplies that appear to be used or unavailable on the inventory system are actually available, albeit at an unknown location. Once again, the maintenance of inventory at an unnecessarily high level increases overhead costs and decreases cash flow.

As the area of a workspace increases, a centralized dispensing unit becomes more inconvenient for more users. Thus, multiple decentralized dispensing units are necessary to maintain user convenience and the viability of an automated inventory system. However, the administration of an automated inventory system becomes more difficult with the addition of dispensing units, as inventory data has to be transferred and consolidated, for administrative purposes. This may be achieved via the communication infrastructure of the automated inventory system. Commonly, this communication infrastructure is proprietary, and thus expensive to implement and maintain.

Various embodiments of this invention are directed towards the communication infrastructure of an automated inventory system, on which the necessary communications between dispensing units and administrative units occur.

In one embodiment the automated inventory system comprises an administrative unit and a dispensing unit. Various information about users, items and transactions are transferred between the two units. User information may include user id, password, and access rights. Item information may include alias, quantity, location, cost and inventory management levels. Transaction information may include user, account billed to, item and quantity.

In some embodiments, a dispensing unit limits supplies available to a user according to his access rights. These limits may be based on the item, quantity, cost, time or other variables and combinations of variables.

In some embodiments events are triggered when the quantity of an item approaches, reaches or falls below an amount defined as an inventory management level associated with that item. In one of these embodiments, a message regarding the shortage of the item is generated. In another one of these embodiments, if an item is unavailable in a first dispensing unit, the administrative unit survey the availability of that item on other dispensing units, and sends a message to the first dispensing unit advising its user of that item's availability on other dispensing units. In this embodiment user access rights may be temporarily modified during the unavailability of an item at a dispensing unit. In yet another one of these embodiments, the item is automatically reordered from its vendor.

In one embodiment user information may be added, changed or deleted only from an administrative unit. In another embodiment user information may be added, changed or deleted on a dispensing unit adapted for such administrative functions.

In some embodiments all the information to be transferred from an administrative unit to a dispensing unit is stored in a first file, and all the information to be transferred from a dispensing unit to an administrative unit is stored in a second file, to facilitate the two transfers. In one of these embodiments, the first file is transferred before the second, while in another one of these embodiments, the order in which the files are transferred is set from the administrative unit.

In some embodiments, other files such as the communication configuration file or the error log file are transferred between an administrative unit and a dispensing unit. In one of these embodiments the error log file is downloaded from the dispensing unit to the administrative unit for analysis following the transfer of regular user, item and transaction data. In another one of the these embodiments, the communication configuration file is uploaded from the administrative unit to the dispensing unit to reset or update the parameters of their communication. These parameters may include IP addresses and transfer intervals.

In some embodiments the communication infrastructure is implemented using the hypertext transfer protocol (http) or its secured counterpart (https). These embodiments are preferred over implementations using traditional ftp, as http implementations are more secure. This makes http based communication infrastructure compatible with client networks having stringent security protocols. A http based communication infrastructure may be integrated into the client's own computer network, reducing cost of implementation and maintenance.

In one embodiment the communication infrastructure comprises the client's own LAN, WAN, or intranet. In this embodiment communication between an administrative unit and a dispensing unit can be initiated from either unit. In another embodiment the communication infrastructure comprises the Internet. As the administrative unit is located beyond the client's firewalls and proxies, communication between an administrative unit and a dispensing unit is preferably initiated by the dispensing unit, to comply with the client's network security restrictions. Frequent communication between the dispensing unit and the administrative unit will advantageously generate an approximately real time inventory picture at the administrative unit, even though the communication may be initiated by the dispensing unit.

In this embodiment the administrative unit can be managed by the vendor of supplies, who is responsible for restocking the dispensing units, to achieve instant delivery e-commerce.

For purposes of summarizing the invention, certain aspects, advantages and novel features of the invention have been described herein. It is to be understood that not necessarily all such advantages may be achieved in accordance with any particular embodiment of the invention. Thus, the invention may be embodied or carried out in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other advantages as may be taught or suggested herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a network diagram showing an automated inventory system integrated into a client's own network (LAN/intranet) in one embodiment of this invention.

FIG. 2 is an overview flowchart of the program running on a dispensing unit.

FIG. 3 is a detailed flowchart of step 202, the initialization step, in FIG. 2.

FIG. 4 is a detailed flowchart of step 204, the connect and transfer step, in FIG. 2.

FIG. 5 is a detailed flowchart of step 414, the receive incoming file step, in FIG. 4.

FIG. 6 is a detailed flowchart of step 416, the send outgoing file step, in FIG. 4.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 is a network diagram showing an automated inventory system integrated into a client's own network (LAN/intranet) in one embodiment of this invention. The client network originally comprises of a firewall 100, and four workstations 102, 104, 106, and 108, before the implementation of the automated inventory system. The automated inventory system comprises of an administrative unit 110, and three dispensing units 112, 114 and 116. The automated inventory system uses the client network as part of its communication infrastructure. The dispensing units 112, 114, and 116 are connected to available ports on the client network. The administrative unit 110 is connected to the client network via the Internet, and is thus located beyond the firewall 100.

Each dispensing unit has at least one bin, tray, or other compartment adapted to store supplies. The setup of the compartments depend on the supplies to be dispensed and the environment in which the dispensing unit is used in. For example, the dispensing unit maybe used in offices, hospitals, manufacturing operations, etc. Usually, each compartment stores a single type of item. To access the supplies in the dispensing unit, a user first identifies himself. This may be accomplished in many ways, including but not limited to, user id (and password, optionally) entry, key cards or other electronic identification, fingerprint and iris scanning. As the user removes supplies from the dispensing unit, it tracks the quantities of items removed. There are many ways to do so, including but not limited to, compartments adapted to count and dispense a quantity input by the user, compartments programmed to dispense a preset quantity, and weight-sensitive compartments that senses the change in weight after a user removes supplies. An exemplary dispensing unit is disclosed in U.S. application Ser. No. 10/008,612, the entirety of which is herein incorporated by reference. Optionally the user may enter one or more accounts to which the costs of the supplies removed are to be billed. The transaction information thus collected needs to be periodically sent to the administrative unit.

For security, the firewall 100 is often set to reject connection requests originating from outside the client network, with the exception of e-mail. For example, if the administrative unit 110 attempts to connect to the dispensing unit 112, i.e. by polling, this connection request will be rejected by the firewall 100. Thus it is desirable to have the dispensing unit, for example, 112, initiate the connection to the administrative unit 110. To the firewall 100, this is equivalent to a user accessing the Internet from a workstation, for example, 102. This connection may be via the hypertext transfer protocol (http) or its secured counterpart (https).

After connection, the administrative unit 110 can upload files to, and download files from, a dispensing unit, for example, 112, as though connected via the traditional file transfer protocol (ftp). These files include the regular incoming and outgoing (from viewpoint of dispensing unit) files with information on users, items and transactions. These files may also include error log files, communication configuration files, and dispensing unit executable files. The administrative unit 110 can also execute commands on the dispensing unit, for example, rebooting the dispensing unit. These commands are sent to the dispensing unit in a file during the file transfer, and contain parameters recognized as commands by the program running on the dispensing unit.

The administrative unit 110 has an interface for an administrator to perform all the above functions. Other functions available on this interface may include adding, changing and deleting users and dispensing units. The administrative unit 110 also keeps a connection log from each dispensing unit. In some embodiments events are triggered by an aberrant dispensing unit, one which has not communicated with the administrative unit 110 over a preset period of time. In one of these embodiments a message is dispatched to the administrator advising him to physically check on the aberrant dispensing unit. In another one of these embodiments the administrative unit 110 may prioritize the next connection attempt from the aberrant dispensing unit.

FIG. 2 is an overview flowchart of the program running on a dispensing unit. Following an initialization step 200, the program determines in step 202 whether it is time to connect to the administrative unit, by comparing a timer value to the communication interval. If so, it connects to the administrative unit in step 204 and transfer files. If not, it next determines in step 206 whether the file transfer request is urgent. If it is urgent, the program loops back to step 204. Step 208 represents an interrupt at which the program may be terminated, passing control back to the system handler in step 210. In step 212 the dispensing unit determines if the communication configuration file has changed. If so it updates the changed communication parameters, such as the communication interval or the administrative unit's IP address, in step 214. The program runs in a loop, labeled the MAIN LOOP, defined by steps 202, 206, 208 and 212.

FIG. 3 is a detailed flowchart of step 202 in FIG. 2. The executable file containing the program is run in step 300. In step 302, the program opens a http port. In step 304 it checks the integrity of the files on the dispensing unit. In step 306 it reads the communication configuration file of the dispensing unit, and determines if the file is corrupted in step 308. If so, the file is reset with default communication parameters in step 310. In step 312, the timer is started, and the program returns to the MAIN LOOP. Steps 314, 316, and 318 are points at which the program may be terminated, passing control back to the system handler in step 320.

FIG. 4 is a detailed flowchart of step 204 in FIG. 2. The program initiates the connection to the administrative unit in step 400. In step 402 the program determines whether the connection has timed out. If so the program returns to the MAIN LOOP. In step 406 the program attempts to log into the administrative unit. In step 408 the program determines whether the connection has timed out. If so the program returns to the MAIN LOOP. In step 410 the program determines whether it has access to the administrative unit. If access is denied the program returns to the MAIN LOOP. If access is granted the program next determines in step 412 whether an older version of the incoming file already exists. If not the incoming file is received in step 414. If an older version of the incoming files exists in step 412, that means it has not been processed by the dispensing unit, and program skips step 414. In step 416 the outgoing file is sent to the administrative unit. Steps 418 and 420 are points at which the program may be terminated, passing control back to the system handler in step 422.

FIG. 5 is a detailed flowchart of step 414 in FIG. 4. In step 500 the program sends a http request to the administrative unit for the incoming file. In step 502 the dispensing unit receives a block of the incoming file. If the connection times out, as represented by step 504, the temp file storing the blocks received so far is deleted in step 506 and the program returns to the MAIN LOOP. In step 508 the checksum is calculated for error correction. If there is an error a NACK is sent to the administrative unit in step 510. If the number of NACK's exceeds a predetermined limit in step 512, the temp file storing the blocks received so far is deleted in step 514 and the program returns to the MAIN LOOP. If there is no error after the checksum is calculated in step 508 the received block is appended to the temp file in step 516 and an ACK is sent to the administrative unit in step 518. In step 520 the program determines whether the received block is the last block of the incoming file. If not the timer is reset in step 522 and the program loops back to step 502. If the last block of the incoming file has been received, the temp file is renamed to the incoming file in step 524. Step 526 represents an interrupt at which the program may be terminated, passing control back to the system handler in step 528.

FIG. 6 is a detailed flowchart of step 416 in FIG. 4. In step 600 the outgoing file is broken down into blocks. The next block is determined in step 602 and a checksum for error correction is calculated in step 604. In step 606 this block is transmitted to the administrative unit. If the connection times out, as represented by step 608, the program returns to the MAIN LOOP. The program requests an acknowledgement from the administrative unit in step 610. Once again, if the connection times out, as represented by step 612, the program returns to the MAIN LOOP. If a NACK is received in step 610, the program determines if the number of NACK's exceeds a predetermined limit in step 614. If so, the program returns to the MAIN LOOP. If an ACK is received in step 610, the program determines whether there are more blocks to transmit in step 616. If so the program loops back to step 602. If there are no more blocks to transmit in step 616, the outgoing file is deleted in step 618 and the program determines whether there are other files to be transferred to the administrative unit in step 620. For example, the administrative unit may request that the error log file from the dispensing unit be transferred. Steps 622 and 626 are points at which the program may be terminated, passing control back to the system handler in steps 624 and 628, respectively.

While certain embodiments of the inventions are described above, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the invention.

Claims

1. A method of communication between a dispensing unit and an administrative unit of an automated inventory system, comprising:

dispensing a quantity of an item in a transaction by said dispensing unit;

collecting transaction data by said dispensing unit;

establishing a communication connection to said administrative unit by said dispensing unit; and

transferring said transaction data to said administrative unit from said dispensing unit.

2. The method of claim 1, wherein said step of collecting transaction data occurs contemporaneously with dispensing a quantity of an item.

3. The method of claim 2, additionally comprising the step of tabulating said transaction data.

4. The method of claim 3, wherein said step of tabulating said transaction data is performed by said administrative unit.

5. The method of claim 3, wherein said step of tabulating said transaction data is performed by said dispensing unit before said step of transferring said transaction data to said administrative unit.

6. The method of claim 1, additionally comprising the step of transferring user data and item data between said dispensing unit and said administrative unit.

7. The method of claim 1, additionally comprising the steps of transferring a file with at least one command from said administrative unit to said dispensing unit and executing said command by said dispensing unit.

8. An automated inventory system, comprising:

an administrative unit; and

a dispensing unit configured to: dispense a quantity of an item; maintain a record of said quantity of said item; establish a communication connection to said administrative unit; and transfer said record to said administrative unit.

9. The automated inventory system of claim 8, wherein said dispensing unit is further configured to identify a user.

10. The automated inventory system of claim 8, wherein said administrative unit is configured to monitor an availability of said item in said dispensing unit.

11. The automated inventory system of claim 10, wherein said administrative unit is further configured to generate a warning when said availability reaches an amount defined as an inventory management level associated with said item.

12. The automated inventory system of claim 10, wherein said administrative unit is further configured to reorder said item when said availability reaches an amount defined as an inventory management level associated with said item.

13. The automated inventory system of claim 12, wherein said administrative unit is managed by a vendor of said item.

14. The automated inventory system of claim 8, further comprising a plurality of other dispensing units.

15. The automated inventory system of claim 14, wherein said dispensing unit is further configured to point out other dispensing units where said item is available if said item is unavailable at said dispensing unit.

16. The automated inventory system of claim 15, wherein said administrative unit is configured to modify a user's access rights.

17. The automated inventory system of claim 8, additionally comprising a communication infrastructure.

18. The automated inventory system of claim 17, wherein said communication infrastructure comprises a client's computer network.