This invention relates generally to item storage and retrieval systems and more particularly to a web-enabled item storage and retrieval system including a secure enclosure which is controlled by computer apparatus employing browser technology type software.
The overnight delivery business is a highly competitive business, requiring delivery companies to develop innovative approaches to reduce delivery cost and increase customer satisfaction. With today's lifestyles, persons, i.e., customers, are frequently not at home to accept deliveries and/or it is inconvenient to return items. Thus there is a need for eliminating the requirement of couriers, meaning persons employed by a delivery company to make a delivery to a customer, to make multiple visits to the same residence or small business in order to complete delivery transaction(s).
Accordingly, there is a need for a secure item and delivery and return system which permits a customer to retrieve undelivered items or return items at any hour of the day, seven days a week. Typically, a customer receives some type of notification that an undeliverable item is stored at a remote location where there is located an item delivery and retrieval system. When it is convenient, the customer subsequently travels to the location of the system and retrieves the items. The benefits of such a system include labor savings, increased customer satisfaction, improved traceability, and improved process control and item security.
Accordingly, it is an object of the present invention to provide a method and apparatus for storing items of various types, sizes and shapes for subsequent retrieval or return when an initial delivery was unsuccessful.
It is a further object of the invention to provide an item delivery and retrieval system which is operable in multiple utilization scenarios.
It is yet another object of the invention to provide an item delivery and retrieval system which is accessible on demand by either delivery and/or storage clerks (employees), and clients (customers) wishing to store or retrieve undelivered items.
It is a further object of the invention to provide an item delivery and retrieval system which provides a requisite amount of security for items stored therein while providing relatively easy and user friendly access.
And it is still a further object of the invention to provide an item delivery and retrieval system which is controlled by application configurable digital computer apparatus supporting browser and web page software.
The foregoing and other objects are achieved by a storage subsystem and a computer subsystem. The storage subsystem provides a secure items storage and delivery environment including a secure enclosure having an item storage carousel including controller apparatus as well as a set of sensors. The computer subsystem is embodied in web page based customized application software for implementing an application interface of selectively configurable application interface controls, such as ActiveX controls, for providing user access to one or more storage bins located behind a set of normally closed doors which are selectively opened and then closed for item storage and retrieval, provides access control to the bins, and manages the location of the items in the storage sub-system. The doors are opened when proper identification is provided by a user so as to permit access only to specifically designated bin(s).
Further scope of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood, however, that the detailed description and specific example, while disclosing the preferred embodiment of the invention, is given by way of illustration only, since various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art from the following detailed description.
The present invention will become more fully understood when the detailed description provided hereinbelow is considered together with the accompanying drawings which are provided by way of illustration only and are thus not meant to be limitative of the subject invention and wherein:
Item delivery companies incur a high cost to make multiple deliveries at one location if a customer is not at home. The high cost results from: redeliveries that increase the delivery expense through additional man-hours and use of valuable space on a delivery truck; deliveries left at the delivery point without any signature are subject to theft, damage and lack delivery verification; and there is no method to handle returns. The customer also has concerns about the deliveries, namely: redeliveries are inconvenient; deliveries are difficult to schedule and wait for re-delivery; there are concerns about theft and weather damage to packages; and returning is a time-consuming and often irritable task.
Furthermore, delivery companies are belabored with item process control, typically: significant labor hours to hand-write left notices, e.g., first delivery attempt, second notice attempt, or final notice prior to returning to sender; the lack of visibility of the item while in the on-delivery, re-delivery, or return to sender life-cycle; manual process generates significant hard copy content to manage, store, protect and archive; and, hard copies are cumbersome to obtain quick visibility.
In accordance with the problems briefly referred to above, this invention is directed to an item delivery and retrieval system (IDRS) which stores a variety of products and items from post cards to large packages. The system may be installed in three scenarios: (1) behind the customer service counter for operation by employees; (2) free standing in a public access location for access by both the employees or customers; or (3) wall mounted in a public location as a customer operated system. If wall mounted, the front of the IDRS is accessible by customers in a common area or lobby, while the rear of the IDRS is accessible by employees/clerks for behind the scenes loading of items.
The IDRS in accordance with this invention is comprised of a single sided or a double sided storage subsystem and a computer subsystem. The storage subsystem provides secure item storage and delivery. The computer subsystem includes separate customer and employee interfaces, provides access control, and manages the location of items in the storage subsystem.
When necessary, multiple IDRS(s) may be co-located at a single facility, allowing the delivery company to configure the system based on site requirements. Multiple IDRS systems can be integrated, when desirable, with multiple storage and computer subsystems for efficiently serving a higher volume of items and customers.
Referring now to the drawings wherein like reference numerals refer to like components throughout,
As shown in
Additionally, the master server 20 supports and stores set(s) of web pages that are connected via the internet 22 to a web server 32. The web server 32 is a pass through connection via the internet 22 to user access terminals 24 and 26 supporting web browsers 28 and 30 located in the front office client 14 and back office module 16. A modem 34 connects the user access terminals 24 and 26 to the web server 32. A modem 35 connects the master server 20 to the web server 32.
As illustrated, the front office browser software 30 and the back office browser software 28 reside in separate user access terminals 26 and 24. This would be the case for double sided load and retrieve system as shown in
The web server 32 can also be internet connected to other software such as browsers 36, 38 and 40 located, for example, in another customer access terminal 42, a customer delivery terminal 44, or a personnel support terminal 46. The customer may view information about the items stored in the IDRS, for example, from terminal 42. This information may include date stored and type of item. The customer may also view any personalized information such as their e mail address and date of IDRS membership.
Delivery company personnel may view machine usage information such as is the IDRS full at certain locations and hardware failure information from a support terminal such as terminal 46 which is accessible by modem 45. The master server 20 is also shown connected to the delivery company-wide area network 15 which is coupled to the Internet 22 via a firewall 49 and connection 47.
The preferred embodiment of the storage subsystem 12 includes a vertical carousel 50, a single sided embodiment of which is shown in
The carousel 50 also includes a set of sensors and a control system 52 (
The carousel control system interfaces with the sensors and controls the movement of the carousel 50. The carousel control system responds to requests from the computer subsystem in either the back office module 16 or front office module 14 via a software carousel driver shown in
As shown in
The front office client module 14 provides a user friendly customer interface implemented in customized application software for the retrieval of an item. The term “application” is well known in the art and refers to a computer program for carrying out a certain function or producing a certain result. As shown in
The front office user access terminal 26 is further shown in
The back office module 16 provides an interface also implemented in customized application software for employees to load the IDRS from front and/or rear access doors of the carousel 50. Two front access doors 72 and 74 are shown in the single sided carousel 50 shown in
If the back office module 16 is located separate from the kiosk 27 such as where the carousel 50 is designed so as to be rear loaded from a back room, it would, for example, include a separate employee access terminal 24 equipped with its own application configuration browser software 28 as shown in
Also shown in
It should be noted that a single back office module 16 can control multiple front office modules 14 and storage subsystems 12 at high demand sites. This feature allows the delivery company to vary the quantity of front office kiosks 27 and carousels 50 based on site-to-site variations on demand.
The master server 20 shown in
Referring now briefly to
Before considering the details of the application software of this invention, reference is first made to
Referring now to
ActiveX control is a well known concept in current state of the art of digital computer technology. It is a programming language including a set of rules for how applications should share information and can be automatically downloaded and executed, for example, by a web browser. ActiveX controls have full access to a windows operating system using web pages. ActiveX control is particularly adapted to implement custom controls, which in the subject invention comprises the FO API 118, the BO API 119 and a carousel driver 126 which is connected to the carousel controller 38 (
The FO API 118, the BO API 119, and the carousel driver 126 combine together to form a customized application and carousel independent interface which is configured on demand to meet a desired configuration of utilization. Accordingly, the carousel driver 126 can be instantaneously used to control any manufacturer's carousel simply by enabling the particular manufacture software switch and recompiling the driver associated therewith.
The configuration of the carousel 50, e.g. bin locations and size, is controlled by a carousel database 128 also residing in the CUPSS software environment 58. The carousel driver 126 supports both double sided and single sided configurations such as shown in
The carousel driver 126 also interacts with an operating system 130 and a simple network management protocol (SNMP) agent 132 as shown in
The Connect function initializes connections of the ActiveX controls 120 and 121 to the carousel driver 126. The ActiveX control may also be required to pass an identification code to the carousel driver 126 for access control security. The Cue Bin Location function is used by the FO API 118 to rotate the carousel 50 such that the requested bin is positioned behind the doors 54 without any of the doors being opened. This function is used to reduce the service time required for the overall transactional session, if the operational rules of the application also include authentication of the user. The Cue Bin Location function will position the carousel 50 while the transactional process of authenticating the user takes place. This will reduce the overall transaction time. The Open Bin Location function is used by the BO API 119 and FO API 118 to position the carousel 50 and to open the doors to a specified bin. This may require an access code. The Open Doors function is a back office function that is used to gain full access to the carousel 50. This function may restrict access based on identification code. The Rotate Carousel function is used by the BO API 119 to position hidden carriers to the access point and may restrict access based on identification code. The Identify Bin function is used by the BO API 119 to identify a particular bin when all doors are open. This function may be used by applications to verify if bins are empty or indicate which items need attention. The Close Bin function is used by the FO API 118 and/or BO API 119 to close the doors. Once the door has been opened, the Close Bin function may also be used to clear bin access codes. The Close All Doors function is used by the BO API 119 to close all doors and secure the carousel 50.
The present invention also contemplates an enhanced item controlled architecture shown in
Application access for the enhanced item controlled architecture to the functions to be described can be classified in two types of control classes: (a) session access and, (b) bin access. Session access describes the protocol required to any given application to connect to the carousel driver 126. Bin access describes the protocol for a qualified application to reserve or lock any given bin.
Session access is controlled by means of an access control list (ACL) which is maintained in the data of the carousel driver 126. As is well known, a “list” is an ordered set of data which is normally accessed in a digital computer sequentially. The ACLs of the FO API 118 and BO API 119 will contain the ACL member ID of all authorized applications of the carousel 50. When an application initializes its embedded ActiveX controls 120 or 121, it in turn establishes the requisite transmission control protocol (TCP) connections to the carousel driver 126. The ACL member ID that is passed with the connection request will be checked against the carousel's ACL. A successful match will permit the connections to be made, assuming no other connection is established. An unsuccessful match will reject the connection and not permit that application to have access to the carousel 50. If there are no members in either ACLs, then it should be assumed that any application can access the carousel and no access security will be required to operate the carousel.
With respect to bin access, the carousel driver 126 will grant access to any given bin based on the access type declared for that bin at installation time. Each bin will be set up based on one of two access types Static or Dynamic.
The Static access type relates a given bin to a given application on the ACL. This type of bin access petitions the carousel 50 to either a single application or multiple applications with fixed storage capabilities. The Dynamic bin access type allows for more efficient use of the carousel 50 in the multiuse configuration by allowing applications to gain access to the bins based on a common pool of dynamically allocated bins. Once a bin has been accessed, the application may place or remove a lock on that bin with an application supplied access code. Subsequent access to that bin or removal of the lock will then require the access code for that bin. The carousel driver 126 will journal log all access activity via a simple network management protocol (SNMP). This information will provide the basis for “use accountability” for owners/administrators of the equipment.
It should be noted that if more than one member exists in the ACL of the BO API 121, back office operations will limit exposure of the bins, i.e., rotation operations, to only those bins which have any given application is authorized to use. This may be accomplished by closing all doors before a rotation and only granting open doors at authorized carrier level as will be described subsequently with respect to
The Static bin access type is the simpler of the two access services. The configuration of the carousel 50 is segmented into a predetermined configuration which specifies who has the right to access any given bin. If no ACL member is specified, it would be assumed that any application has access to the bin. At configuration time, it should be noted that the segmentation definition will take into account for the dual sided and/or single sided system as shown, for example, in
The Dynamic bin access has two modes of operation, with or without back office operations. Dynamic bin access without back office operations will permit any application to access any unlocked bin. Once the bin has been locked with an access code, both the ACL member ID and access code will be needed to re-access the bin or remove the lock. Dynamic bin access with back office operations, however, will operate as above, but with a further restriction such as to limit access to those bins where no other bin on that carrier, for single sided configurations and adjacent carrier for dual sided configurations, is locked by another ACL member ID.
The major function of these ActiveX controls for the enhanced architecture shown in
With respect to the functions listed in Table II, the Connect function, for example, initializes connections of the ActiveX control of FO API 118 and BO API 119 to the carousel driver 126. The ActiveX controls may also be required to pass an identification code to the carousel driver 126 for access control security. This function is the same as in the basic control outlined in Table I. The Cue Item function is similar to the Cue Bin Location function of Table I and is used by the FO API 118 to rotate the carousel 50 such that the requested item is positioned behind the doors 54 without any of the doors being opened. This function is also used to reduce the service time required for the overall transactional session. If the operational rules of the application include authentication of the user, the Cue Item function will position the carousel 50 while the transactional process of authenticating the user can take place, and thus will also reduce overall transaction time. The Register Item function is used by the BO API 119 to register an item and the item characteristics in the inventory data base 134 (
The Purge Item function is used by the BO API 119 to remove an item in the local data base 134 and clear the bin access code. This function may require a bin access code and also may use an external scanner or similar data entry device. The Close Bin function is used by FO API 118 and/or BO API 119 to close the doors 54, 72, 74. The Remove Item function is similar to the Open Bin Location function of Table I and is the function used by both the BO API 119 and the FO API 118 to position the carousel 50 and open the doors 54 to a specified item. The item is then marked as removed from the local database 134 and the bin access code is cleared if a bin access code is present.
The Return Item function is used by the FO API 118 to close the bin doors 54 and flag/mark the item in the database 134 for return. This function may also be used to flag an item that has not been removed from the carousel 50 but has been purged from the database 134. This function may be used to set the bin access code and is similar to the Remove Item and the Load Item function, noted above, with an item that is already in the system. The Query Item function is used by the FO API 118 to find and load time and status information into the database 134 regarding item removal or return. The Print Receipt function is used by the FO API 118 to print a transaction receipt of item removal or return from the carousel 50.
The Open All Doors function is a function of the BO API 119 that is used to gain full access to the carousel 50. The Open All Doors function may restrict access based on an identification code and is the same as in the basic control outlined in Table I. The Open Bin Location function is used by the BO API 119 to position the carousel 50 and to open the doors 72 or 74 to a specified bin and may require an access code. Again, this function is the same as in the basic control outlined above with respect to Table I. The Identify Bin function is used by the BO API 119 to identify a particular bin when all doors are opened. This function may be used by applications to verify if bins are empty or indicate which items need attention. This function is also the same as in the basic control outlined above.
The Rotate Carousel function is used by the BO API 119 to position hidden carriers to a specific access point and may restrict access based on an identification code. This function is also the same as in the basic control. The Close All Doors function is used by the BO API 119 to close all doors and secure the machine and is the same as in the basic control described with respect to
Other queries and maintenance functions of the local item inventory base will depend on the design of the database itself.
With respect to the three major interfaces considered above with respect to
The customer or FO API interface 118 has access to the carousel driver 126 through an immediate response port termed a “command respond port” shown by reference numeral 132 or a process and generate event port termed a “command process port” 134 shown in
As noted above, the carousel driver interface 136 is an executable program that communicates directly with the carousel 50, with both the customer FO API 118 and employee BO API 119. ActiveX controls 120 and 121 communicate with the carousel through this driver. The attached Appendix C is illustrative of the set of functions implemented by the carousel driver interface 126.
It should be noted that ActiveX controls can be used, without modification, by any development environment such as the Web. The application programming interface (API) remains constant, irrespective of whether a web page of a windows application is operating the carousel 50. This significantly reduces the software effort because the same API is used in both the Web and programming development environments. In addition, by hiding the peripheral details, this common use interface provides higher level interfaces to the developers, resulting in shorter time-to-market efforts.
For example,
Considering now
The notification form approach (1) requires the delivery company courier to leave a written notice at the residence or business of attempted delivery. The written notice has a barcode on the form matching a self-stick barcode label placed on the item. When the delivery of an item cannot be completed, the courier will fill out a notification form, peel off a self-stick barcode label, and apply it to the item. The form is left at the address and the item is brought back to the IDRS 10. Once back at the delivery facility, the employee uses the back office subsystem module to initiate loading the storage unit 12 including the carousel 50. The screen on the terminal 28 in the back office subsystem module 16 displays the available compartments in the carousel 50. The employee then selects an empty compartment to match the item size. The application software in the back office subsystem module 16 automatically requests the carousel 50 to move the compartment to the loading position and the doors of the carousel are opened. The employee scans the self-stick barcode label and an IDRS storage location barcode label is scanned and fed into a database.
Thereafter, a customer retrieves the items via the notification form. As shown in
The second scenario involves internet e-mail notification (2). This approach requires notifying the customer via a supplied e-mail address, contained in a database of the master server 20 whenever an item is stored in the IDRS. In such an operational mode, the customer is first registered for service via the Internet by accessing a website and requesting internet e-mail notification service. At a minimum, a delivery address is provided to re-direct to the IDRS system. An e-mail address is provided to receive the notification. After registering, the customer must activate the service by calling the IDRS from a phone at the address given during registration. A customer selects a delivery profile, e.g., automatic placement of the item in the IDRS system 10. The customer indicates a preference to automatically put deliveries into the carousel 50 and thereafter eliminate any further attempts to deliver to the customer's address.
When an item is then stored in the carousel 50, an e-mail is sent to the e-mail address on file. The e-mail contains instructions on how to retrieve the item, including a six-digit PIN along with the location of the IDRS system, i.e., the address at which the IDRS 10 is located and, when desirable, with an optional map showing street locations, etc.
Items for the customer will be directed immediately to the IDRS 10 if the customer selected this delivery profile for this account. Not delivering the item reduces courier delivery time, delivery vehicle wear, and delivery vehicle gas and maintenance. The item may contain other delivery company barcodes such as expedite shipment confirmation of delivery, insured item, and indication of any other special handling. Any of these additional barcodes will also be scanned into the IDRS when the item is stored in the carousel. An e-mail is thereafter sent to the e-mail address on file associated with the item's delivery address.
As shown in
The third scenario (3) is shown in
In such an instance, where the customer needs assistance as indicated by step 176, he/she would proceed to the front counter and see the clerk/employee per step 178 who would obtain the necessary information such as the delivery address and name and the necessary customer identification. The clerk then enters the address into the IDRS in the back office module 16 in accordance with step 180, whereupon the IDRS 10 uses the address to reference the storage location(s) linked to the address. The clerk/employee then retrieves the item(s) and upon receiving a customer signature per step 182, the item is supplied in accordance with step 184.
The fourth scenario (4) permits the customer to use a delivery company issued customer loyalty card to retrieve items stored in the IDRS. In this mode of operation, the customer would again register for service via the web by accessing a website and requesting customer loyalty service. This would again involve providing a delivery address to re-direct to the IDRS and an e-mail address to receive the notification. After registration, the delivery company mails a customer loyalty card to the customer.
Thereafter, the customer must activate the service by calling the IDRS from a phone at the address given during registration. The customer would then select a delivery profile, whereupon an e-mail notification is sent by the IDRS to the e-mail address on file. Contained in the e-mail are instructions on how to retrieve the item; however, there is no 6-digit PIN. Contained on the customer loyalty card is an encoded loyalty PIN number. The customer must then supply an associated PIN for authentication when using the customer loyalty card to access the IDRS.
Items will be directed immediately to the IDRS if a customer selected such a delivery profile for their account. The item may contain other delivery company barcodes such as expedited shipment confirmation of delivery, insured item indication of any other special handling required. Any of these additional barcodes will be scanned into the IDRS when the item stored upon non-delivery. An e-mail is sent to the e-mail address on file associated with the item delivery address.
When the customer arrives at the IDRS, he/she enters the customer loyalty card and PIN via the card reader in the PIN pad as shown by steps 186 and 188 in
It should be noted that the flexibility of the IDRS system 10 in accordance with the subject invention allows the delivery company to deploy the appropriate configuration depending upon available floor space, item mix and capacity.
Having thus shown and described what is at present considered to be the preferred embodiment of the invention, it should be noted that the foregoing detailed description merely illustrates principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements which although not explicitly described or shown herein, embody the principles of the invention and are thus within its spirit and scope.
This application is a Division of non-provisional application Ser. No. 09/817,375, filed on Mar. 27, 2001 now U.S. Pat. No. 6,748,295, including the subject matter and claiming the priority dates of Provisional Application No. Ser. No. 60/220,842, filed on Jul. 26, 2000, and Provisional Application Ser. No. 60/265,875 filed on Feb. 5, 2001, the contents of which are meant to be incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
4894717 | Komei | Jan 1990 | A |
5113351 | Bostic | May 1992 | A |
5273183 | Tuttobene | Dec 1993 | A |
5313393 | Varley et al. | May 1994 | A |
5385265 | Schlamp | Jan 1995 | A |
5386462 | Schlamp | Jan 1995 | A |
5467892 | Schlamp | Nov 1995 | A |
5499707 | Steury | Mar 1996 | A |
5544996 | Castaldi et al. | Aug 1996 | A |
5774053 | Porter | Jun 1998 | A |
5820237 | Robey | Oct 1998 | A |
5836662 | Robey | Nov 1998 | A |
5890136 | Kipp | Mar 1999 | A |
5902027 | Robey et al. | May 1999 | A |
5915909 | Smith | Jun 1999 | A |
6010239 | Hardgrave et al. | Jan 2000 | A |
6123223 | Watkins | Sep 2000 | A |
6313393 | Drost | Nov 2001 | B1 |
6404337 | Van Till et al. | Jun 2002 | B1 |
6456900 | Kakuta | Sep 2002 | B1 |
6694217 | Bloom | Feb 2004 | B1 |
20010047285 | Borders et al. | Nov 2001 | A1 |
20020156645 | Hansen | Oct 2002 | A1 |
20020184497 | Gage et al. | Dec 2002 | A1 |
20030052778 | Wong | Mar 2003 | A1 |
Number | Date | Country |
---|---|---|
0821518 | Jan 1988 | EP |
0845747 | Jan 1998 | EP |
2621803 | Apr 1989 | FR |
2643479 | Aug 1990 | FR |
WO002095536 | Nov 2002 | WO |
Number | Date | Country | |
---|---|---|---|
20040193314 A1 | Sep 2004 | US |
Number | Date | Country | |
---|---|---|---|
60265875 | Feb 2001 | US | |
60220842 | Jul 2000 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 09817375 | Mar 2001 | US |
Child | 10819990 | US |