US20140354403A1 - User selectable securable device - Google Patents

Abstract

The principles of the present invention provide for a more flexible kiosk securable device system and method that enables users to select their own securable device, such as a locker, rather than having the kiosk assign one to them. In selecting a securable device, the user enters the same access indicia (e.g., PIN) that he or she entered in the kiosk into any available securable device, and, in response to the kiosk or securable device verifying that access indicia, the selected securable device may be provisioned to the access indicia in accordance with rental parameter(s), such as rental duration, size of securable device, and so forth.

Description

RELATED APPLICATIONS
• This application claims priority to co-pending U.S. Provisional Application Ser. No. 61/808,523 filed Apr. 4, 2013, the contents of which are hereby incorporated by reference in their entirety.
BACKGROUND
• Rental securable devices, such as lockers at amusement parks and ski slopes, were historically coin operated. A couple of problems have traditionally existed with coin operated lockers, including people not having quarters and people simply using the lockers without paying for them as a result of coin operated lockers having to be unlocked before coins are deposited and a key being removed from the locker.
• More recently, for efficiency and informational purposes, banks of securable devices or locker systems rentable via a kiosk were developed. As understood in the art, these locker systems provide for one or more centrally configured kiosks to enable a user to interface with a single or multiple points to pay for and rent a securable device or locker. In renting a locker through such a conventional kiosk, a user submits a personal identification number (PIN) and the kiosk assigns a locker for the user and communicates the submitted PIN to the assigned locker, thereby enabling only that user to have access to that assigned locker. The user also sets the rental time for that locker at the kiosk.
SUMMARY
• The principles of the present invention provide for a more flexible kiosk securable device system that enables users to select their own securable device, such as a locker, rather than having the kiosk assign one to them. By allowing users to select their own securable device at the physical securable devices themselves, users can (i) select a securable device that is conveniently located instead of being computer assigned, (ii) select a securable device at a height that is convenient for a user, which is particularly helpful for disabled users, (iii) select a securable device that is away from congestion of other users at the time of selection, (iv) select a securable device that is easy to remember, and (v) start the rental period at a delayed start time as desired by the user. In selecting a securable device, the user enters the same access indicia (e.g., PIN) that he or she entered in the kiosk into any available securable device, the securable device communicating the access indicia to the kiosk, and, in response to the kiosk or securable device verifying the received access indicia, the kiosk may provision the selected securable device by associating and storing an identifier of the selected securable device with the access indicia in accordance with rental parameter(s), such as rental duration, size of securable device, and so forth.
• One embodiment of a method for provisioning a securable device may include providing a controller user interface to enable a user to initiate access of a securable device from a set of securable devices in local communication with the controller user interface. The user may be enabled, via the controller user interface, to submit an access indicia for accessing one of the securable devices from the set of securable devices. In response to receiving the access indicia, the access indicia may be stored independent of any particular securable device identifier associated with the set of securable devices by a controller computing device in communication with the controller user interface. In response to receiving (i) the access indicia from the user interfacing with a securable device user interface associated with a selected securable device and (ii) a securable device identifier via a communications medium, the access indicia received from the selected securable device matches the stored access indicia may be verified. In response to verifying a match, the securable device identifier and the access indicia may be associated by the controller computing device so as to provision the selected securable device for the user. A verification signal indicative of the access indicia received from the selected securable device matching the stored access indicia may be communicated to the securable device controller. The securable device controller may provision the securable device. Otherwise, in response to the access indicia received from the securable device not matching the stored access indicia, the user may be prevented from accessing the securable device.
• Another embodiment of a system for provisioning a securable device may include a set of securable devices and a set of securable device controllers, where each of the securable devices includes a securable device controller. A controller user interface may be in communication via a communications medium with the set of securable device controllers, and be configured to enable a user to (i) initiate access of a securable device from the set of securable devices and (ii) enable the user to submit an access indicia to access any one of the securable devices from the set of securable devices. A controller computing device may be in communication with the controller user interface, and be configured to (i) store, in response to receiving the access indicia, the access indicia independent of any particular securable device identifier associated with the set of securable devices and (ii) communicate, via a communications network, the access indicia to each of the securable device controllers in the set of securable device controllers. A selected one of the securable devices with an associated securable device controller may be configured to (i) in response to receiving an entered access indicia from the user at the selected securable device, verify that the entered access indicia matches the access indicia, (ii) in response to verifying that the entered access indicia matches the access indicia, enable entry of the selected securable device, otherwise, not enable entry of the selected securable device, and (iii) communicate the access indicia and a securable device identifier associated with the selected securable device via the communications medium to the controller computing device to provision the selected securable device thereby.
BRIEF DESCRIPTION
• Illustrative embodiments of the present invention are described in detail below with reference to the attached drawing figures, which are incorporated by reference herein and wherein:
• FIG. 1 is an illustration of an illustrative locker system that includes a kiosk that enables a user to pay for, access, and provision lockers in accordance with the principles of the present invention;
• FIG. 2 is an illustration of an illustrative keypad that provides a user interface for a user to access a locker ofFIG. 1;
• FIG. 3 is an illustration of an illustrative network environment in which a kiosk/controller may communicate with securable device controllers/locks in accordance with the principles of the present invention;
• FIG. 4 is an illustration of illustrative tables for use in provisioning securable devices and establishing undesignated rentals or access indicia for use of the securable devices;
• FIG. 5 is an interactive diagram of an illustrative process that enables users to select their own securable device at the physical securable devices in accordance with the principles of the present invention;
• FIG. 6 is a screenshot of an illustrative user interface provided on a kiosk that enables a user to rent a locker in accordance with the principles of the present invention;
• FIG. 7 is a screenshot of an illustrative user interface that enables a user to select a payment method for renting a securable device or locker;
• FIG. 8 is a screenshot of an illustrative user interface at a kiosk that enables a renter of a securable device to enter an access indicia (e.g., personal identification number (PIN));
• FIG. 9 is an illustration of an illustrative keypad on a locker in which the renter may use to select and access a locker by entering his or her access indicia as entered into a kiosk;
• FIG. 10 is an illustration of an illustrative amusement park where users may select lockers throughout the amusement park in accordance with the principles of the present invention;
• FIGS. 11A and 11B (collectivelyFIG. 11) is an interaction diagram of an illustrative process that enables a user to select any locker at the physical lockers themselves throughout a geographic region, such as an amusement park;
• FIG. 12 is a screenshot of an illustrative graphical user interface that may be used as an initial user rental screen at a kiosk or controller at a securable device station;
• FIG. 13 is a screen shot of an illustrative graphical user interface that allows a user to enter a 7-digit customer ID into a kiosk for renting securable devices;
• FIG. 14 is a screen shot of an illustrative graphical user interface that allows a user to enter a 4-digit access code or indicia into a kiosk for renting securable devices;
• FIG. 15 is a screen shot of a graphical user interface to confirm with a user attempting to switch portable securable devices whether or not to end a currently rented securable device;
• FIG. 16 is a screen shot of a graphical user interface to display a message that lists a locker number assigned to the user, rental expiration time, and selected rental type (e.g., single use locker); and
• FIG. 17 is a block diagram of illustrative software modules for execution on a controller or kiosk that enables a user to select his or her own locker and rent and/or select a locker within a geographic region or multiple geographic regions (e.g., different amusement parks or ski slope resorts).
DETAILED DESCRIPTION OF THE DRAWINGSSelect Your Own Locker
• With regard toFIG. 1, an illustration of anillustrative locker system100 may include alocker bank102 in which different sizedlockers102a-102mand102n-102z(collectively102) are available for people to rent. It should be understood that thelockers102 may alternatively all be the same size. Each of thelockers102 may include locks104a-104z(collectively104) that are inclusive of a user interface (e.g., keypad) and electromechanical lock mechanism, as understood in the art. Associated with thelocker bank102 is akiosk106 with which people may use to interface in renting thelockers102. Thekiosk106 may include ascreen108 that may display locker rental options. In one embodiment, thescreen108 is a touchscreen that enables the user to touch to make selections for renting a locker. Alternative configurations of a user interface, such as hard-buttons, may be utilized in accordance with the principles of the present invention. To make a payment for the rental of a locker,payment options110 may provide for a renter to enter a card (e.g., credit card or debit card), pay by bills, pay by coins, use a scanner to scan a ticket, image on a mobile device, or otherwise, or pay using near field communications (NFC) via a mobile device or otherwise. Alternative payment techniques may be provided, as well. A securable device includes a locker, but is not limited to a locker as other forms of securable devices, such as ski locking mechanisms to lock skis on an outdoor ski rack at a ski slope, may be utilized in accordance with the principles of the present invention.
• With regard to the scanner, the scanner may be a barcode reader, quick reference (QR) code reader, magnetic strip reader, camera, or any combination or other scanner as understood in the art to read an indicia on a ticket, mobile device, receipt, coupon, or other medium usable to provide thekiosk106 with payment credit or instructions (e.g., season locker payment amount, daily discount, etc.). For example, in one embodiment, the user may purchase a season ticket that also includes a season locker rental. The season locker rental may be a multiple of the cost of a daily rental, such as three times the cost of a daily rental, that may provide the user with certain access throughout a season, such as one lock/unlock per day per visit, unlimited unlocks per day, and so forth. To make the purchase, the user may purchase the seasonal locker rental from the amusement park and scan a purchase code or indicia (e.g., barcode) at a kiosk of the lockers, thereby initiating the user's seasonal rental. The QR code, if purchased via a mobile app or online via a website, may be communicated to and displayable on a mobile device and can be scanned by the scanner on the kiosk. In one embodiment, the kiosk may be in communication with the park's data system, often known as a park “folio” system (i.e., data system used to monitor seasonal ticket holders), and confirm the purchase of the seasonal locker rental prior to initiating the user's seasonal locker rental. The scanner functionality and payment options may be utilized for any rental option (e.g., “select your own,” “assigned locker,” “portable locker,” etc.) described herein.
• In accordance with the principles of the present invention, thekiosk106 may communicate with the locks104 to notify the locks104 that a user has selected or been assigned a particular lock or that the user has elected a “select your own locker” option that enables a user to enter his or her access indicia, such as a personal identification number (PIN), into any available locker (i.e., alock104aof alocker102a) that meets a criteria, such as small locker and/or large locker, that he or she chooses, as further described herein. Acommunication channel112 between thekiosk106 and the locks104 of thelockers102 may be hardwired or wireless databus, and communications may include an address for a particular lock104 or a broadcast message that is received by all of the locks104. Thecommunication channel112 may support any communications protocol, as understood in the art. The communication may include access indicia (e.g., personal identification, number) and, optionally, rental parameter(s) in a distributed system configuration or be a communication back to the kiosk from a lock or securable device controller to verify valid access indicia of thesystem100 is configured in a centralized system configuration, as further described herein.
• With regard toFIG. 2, an illustration ofkeypad104ais shown to includenumeric keys202, “enter” key204, and “end usage”key206. An “occupied”visual indicator208, such as an LED, may also be associated with the keypad of thelock104a. In one embodiment, thekeys202,204, and206 are hard-buttons that the user presses to interface with thekiosk106. Alternatively, a touchscreen electronic display with soft-buttons may be utilized. Additional indicators, such as a “PIN not recognized” indicator in the form of a light and/or audio signal (not shown), may additionally and/or alternatively be provided in association with thelock104a.
• With regard toFIG. 3, an illustrative network environment in which akiosk302 may be utilized by a user to rent a securable device is shown. Thekiosk302 may include aprocessing unit304 that executessoftware306 that configures theprocessing unit304 to perform certain functions in accordance with the principles of the present invention. Theprocessing unit304 may be in communication with amemory308, input/output unit310, andstorage unit312. Thestorage unit312 may include one or more data repositories314a-314m(collectively314). Theprocessing unit304 may further be in communication withuser interface316 that includes apayment unit318. Thesoftware306 may operate in conjunction with each of the other components, including providing functionality that supports theuser interface316 to assist in renting securable devices (e.g., lockers). These data repositories314 may include information in association with each rental and each securable device, such as interactions with each securable device by users who have rented the securable devices. Thepayment unit318 may be configured to accept payment (e.g., cash, credit, debit, scanning of receipt, ticket, mobile device) for rental of securable devices. Thesoftware306 may be configured to assign a securable device to a user, enable a user to select his or her own securable device at a bank of securable devices local (i.e., within a local proximity and/or local communication of the kiosk302) to thekiosk302, and/or remotely positioned from thekiosk302 and that may be associated with another kiosk (not shown).
• Multiple securable devices, such as lockers, may include a securable device controller/lock320a-320n(collectively320) that are in communication with the kiosk/controller302. The securable device controller/lock320amay be a “smart lock” and include aprocessor322 that executessoftware324 that is used to control operation of the securable device controller/lock320a. Thelock320amay further include amemory326 that is used to store data and software, input/output unit328,user interface330, and lock332. The input/output unit328 may be configured to communicate data over anetwork334 with the kiosk/controller302. Theuser interface330 may be that shown inFIG. 2 or be an alternative user interface that enables a user to enter his or her PIN or access indicia (e.g., fingerprint). In such an embodiment, thecontroller302 may communicate a PIN to thelock320avia thenetwork334 for storage in thememory326. In one embodiment, thesoftware324 may be configured to receive a PIN from theuser interface330 and compare the PIN with PINs stored in thememory326, and, if the PIN matches one of the PINs in thememory326, then thelock332 may be caused to open by theprocessor322. If the PIN does not match any PIN stored in thememory326, then thesoftware324 may prevent thelock332 from being opened. As a result of the securable device controller/lock320aincluding aprocessor322, the securable device controller/lock320amay operate autonomously after receiving an access indicia, thereby being immune from power failure or communication failure with the kiosk/controller302. Thenetwork334 may be a local area network (LAN), hardwired network, wireless network, wide area network (WAN), or any other communications network, as understood in the art.
• As further shown inFIG. 3, the kiosk/controller302 may be in communication with park server(s)336 that are configured to manage a park's data, such as season ticket holder data and point-of-sale (POS) data. The kiosk/controller300 may be configured to receive, request, and communicate data with the park server(s)336 to confirm locker rental purchases via a ticket booth of the park, seasonal ticket and/or locker rental purchases, online rental purchases of lockers, and so on.
• With regard toFIG. 4, an illustration ofillustrative data repositories400, including a provisioned securabledevices data repository402 and an established, unprovisionedrentals data repository404. The provisioned securabledevices data repository402 may include a number of data parameters, including securable device identifier, access indicia (e.g., PIN, RFID tag, scannable code, etc.), valid indicia condition(s), and user interactions with securable device. The access indicia may be a four digit indicia. Alternatively, other numbers of digits, such as seven, may be utilized. Still yet, the access indicia may be an alphanumeric value. Alternatively, the access indicia may be a biometric identifier (e.g., fingerprint or swipe of a user's finger), for example. The valid indicia condition(s) may include a variety of different valid conditions, such as the securable device being rented all day, over a limited period of time (e.g., 2:00 pm-5:00 pm), a limited time period starting from a locker selection time (e.g., 2 hours from locker selection) over a limited geographic area, local to a kiosk, a combination thereof, or otherwise. The conditions may be listed in a human-readable form, but machine readable information or information in other formats (e.g., all parks=p1-p4), for example. The user interactions with a securable device may include a historical listing of when an associated securable device is accessed by a user. All interactions may be captured and stored.
• In accordance with the principles of the present invention,data repository404 may be configured to store data of established, unprovisioned rentals. That is, the content stored in thedata repository404 is not yet associated or provisioned with any securable device. As shown, thedata repository404 may include a number of data parameters, including access indicia, valid indicia condition(s), and purchase date/time. The valid indicia condition(s) may include a time range (e.g., hours of accessibility, duration of accessibility from first locker access), date range, number of locks that a user can access securable devices in a certain geographic area, and time and date that the user has purchased the accessibility to any available securable device. The securable devices may also be specified based on size, such as small locker or large locker, and location, such as locker in park A, locker in any of parks A-N, locker at particular ride (e.g., rollercoaster), or otherwise.
• Because the users have requested to have an undesignated or unassigned locker, the data stored indata repository404 may be, at least in part, be communicated to securable devices that meet the criteria of the selected securable devices (e.g., time range, location, size) or utilized by the kiosk to compare when new access indicia are received from securable devices. That is, any securable device that meets rental parameter(s) and receives a valid access indicia may be provisioned or assigned with that access indicia. For example, in response to a user with access indicia “5250” entering that access indicia into a securable device controller of a securable device, the securable device controller, if the established unprovisioned rental data has been downloaded thereto, may vary of the access indicia and indicia condition(s) or communicate received access indicia to the kiosk for confirmation thereat prior to providing access to the securable device. Although not shown, a user identifier may be associated with the access indicia, thereby allowing the user to change his or her access indicia in different rental periods, and the system to track and use historical information of the user.
• With regard toFIG. 5, an interaction diagram of anillustrative process500 that enables a user or renter of a securable device to select his or her own securable device, as opposed to the kiosk assigning a securable device, is provided. Acentral controller502 operating as or within a kiosk may communicate with securable device controllers504a-504n(collectively504). The securable device controllers504 may be associated with respective securable devices that are local or in immediate proximity of the central controller502 (e.g., under the same roof or conspicuously near the kiosk).
• Theprocess500 may start atstep508, where a user interface is provided by thecentral controller502. The user interface may be a graphical user interface on a touchscreen, graphical user interface with hard-buttons associated with the graphical user interface for selection of user options, hard-buttons not on a graphical user interface, or otherwise, as understood in the art. Atstep510, thecentral controller502 may receive a user initiated request for a securable device including request parameters. The request parameters may include type of locker, size of locker, location(s) of locker, duration of rental, access indicia, payment, etc. Atstep512, thecentral controller502 may store access indicia and request parameters independent of a securable device identifier (e.g., locker number or identifier). The stored access indicia and request parameters are established, unprovisioned at this point and remain unprovisioned until the user enters the access indicia into a securable device associated with one of the securable device controllers504. Such a configuration allows for users to delay start time for rental periods. The storage may be in a data repository, such as those shown inFIG. 4.
• Atstep514, an optional step, as indicated by dashed lines, of communicating the access indicia and parameter(s) may be communicated to the securable device controllers504. That is, because the user requested to use a user selection process for one of the securable devices, the indicia and parameter(s) are communicated to the securable device controllers504 so that the securable device controllers504 may perform their own verification of an access indicia submitted into one of the securable devices by a user. In such a decentralized verification, provisioning of a selected securable device by thecentral controller502 thereafter or a centralized verification of the access indicia may be performed in addition to the decentralized verification (i.e., both the securable device controller andcentral controller502 may perform a verification of an entered access indicia).
• Ifstep514 is performed, then atstep516, thesecurable device controller504astores the access indicia and associated parameters. Atstep518, a user interface may be provided to a user. In one embodiment, the user interface may be a keypad, as provided inFIG. 2, for example. Alternative user interfaces may be provided at the securable devices, as well. Atstep520, thesecurable device controller504amay receive an access indicia from a user who is selecting his or her own securable device at a physical securable device. At step522, if the access indicia parameter(s) are communicated to thesecurable device controller504aatstep514, then thesecurable device controller504amay verify the access indicia. In verifying the access indicia, thesecurable device controller504amay verify (i) that the access indicia matches an access indicia (e.g., PIN) or has a match likelihood above a threshold if using biometrics, for example, of an access indicia being stored by thecontroller504aand that the parameters (e.g., date, time, time frame, location number of times of using locks, etc.) are valid. Steps524-530 performed bysecurable device controller504nmay be identical to the steps516-522 performed bysecurable device controller504a.
• Atstep532, in the event that step514 is not performed, where the securable device controllers504 are provided the access indicia and parameter(s) as is performed in a distributed system configuration, the access indicia entered into a selected one of the securable device controllers504 and associated securable device identifier are communicated back to thecentral controller502 for verification thereat. Atstep534, thecentral controller502 may verify theaccess indicia534 received from the selected securable device controller. This configuration is a centralized configuration, as opposed to a decentralized or distributed configuration where the securable device controllers504 perform the verification step. As shown, the dashed-line steps are for the decentralized configuration. Atstep536, thecentral controller502 may associate or compare the access indicia and securable device identifier to established, unprovisioned rentals in an effort to provision a securable device. In other words, in response to a user entering his or her access indicia into a securable device, thecentral controller502 will provision or assign the user-selected securable device to be in association with the access indicia.
• Atstep538, thecentral controller502 may communicate an access indicia verification to thesecurable device controller504a. Atstep540, usage of the securable device may be enabled for the user by thesecurable device controller504aby unlocking the securable device or otherwise recognizing that the securable device is being utilized by the user. If, atstep534, the access indicia is not verified, then thecentral controller502 may not associate the access indicia and securable device identifier so as to not provision the securable device, and a provision rejection signal may be communicated atstep538 to thesecurable device controller504ato prevent the user from accessing the associated securable device. Atstep542, thesecurable device controller504amay communicate any further interactions by the user with thesecurable device controller504a(i.e., locking, unlocking, entered access indicia, or otherwise).
• With regard toFIG. 6, a screenshot of an illustrative user interface600 is provided. The user interface600 may include a number of different selectable parameters, including duration of rental602, provisioning type604, locker size606, and locations of lockers608. The duration for rental section602 may include a single lock (i.e., lock the locker one time and the rental is complete), multiple locks for additional cost, two hours fixed time of locker rental unlimited locks, half day rental with an unlimited number of locks (i.e., in-and-outs of a locker), or all day rental with an unlimited number of locks. The provisioning section allows the user (i) to have a locker assigned to him or her by the kiosk or (ii) to select their own locker, where the user may select any qualifying locker by entering his or her indicia at any locker or any type or class of lockers (e.g., small or large). The locker size selection option606 may include a small locker for a first charge (e.g., no additional charge) or a large locker for an additional charge (e.g., $1.00 additional).
• It should be understood that the locker options may include different or additional options and may vary based on park type, locker types, or any other configuration of securable devices or system configurations. As an example, the user may be able to purchase rental of ride-only lockers that are meant for small items, such as mobile devices, for no or some charge ($1.00), for multi-ride only locker usage. If all large lockers are currently provisioned, then the system may prevent such a rental or provide notice that all large lockers are currently provisioned and allow for a large locker rental and allow the user to access small lockers and large lockers when one becomes available. In one embodiment, a “family or friends rental” option may be provided, where a certain number of simultaneous rentals, such as four large lockers, using the same or different access indicia may be performed to reduce the amount of time needed at the kiosk by related people. The location section608 allows the user to select a locker based on location of the lockers, such as a locker bank associated with the kiosk, a locker bank anywhere within a facility (e.g., ski lodge), at a particular ride (e.g., Tornado Alley coaster), at a particular park section (e.g., Fantasy Place), at a particular park (e.g., Dinosaur Park), all parks, or otherwise. A total due amount field610 may tabulate a total amount due by the user for the selected options.
• With regard toFIG. 7, a screen shot of an illustrative user interface700 for enabling a user to select a payment method for rental of a securable device is shown. The user interface may include a number of different payment options, including debit702a, credit702b, Paypal®702c, cash702d, or prepaid scan702e. It should be understood that any other form of payment may be included, such as using a near field communication (NFC) payment method via a smart phone (e.g., ewallet). In addition, the user interface may allow for promotional discounts, coupons, or other cost-offsetting discounts to be entered via scanning or text entry. Other possible payment systems may be utilized, including coins, private point-of-sale systems of amusement parks (e.g., Disney Dollars®) or ski resorts, for example, coupons, Internet or ticket booth pre-purchase codes, and so on. In one embodiment, a location in which the lockers are operating, such as an amusement park, may allow for users to purchase locker rentals while paying for passes into the location (e.g., amusement park day or multi-day pass). In such an embodiment, the park pass or entry ticket, which may include a code printed on the entry ticket or computer readable medium, such as a magnetic strip or RFID tag, on the entry ticket may include information that can be read by the kiosk, central controller, secondary controller, or securable device controller.
• The human or machine readable information may enable the user to have access to a securable device, thereby allowing the system to provision a securable device for the user without having pay money in any form at a kiosk or otherwise. That is, the user simply presents or scans the ticket at the local controller (e.g., kiosk) and the system reads and confirms payment information and handles the provisioning as if the user paid at the kiosk using another form of payment. Alternative means of payment may be made, such as (i) using a hotel room key with payment information for a securable device, (ii) text messaging a payment code, (iii) entering a coupon code (e.g., 8 digit alphanumeric code), (iv) submitting a prepaid code to a text message address that, if confirmed, is communicated to a central controller to establish payment, (v) imaging or scanning an indicia, such as a bar code or QR code, and messaging or uploading that imaged indicia to an online address or locally at a kiosk, (vi) presenting a machine readable code, such as a prepaid purchase code, on a ticket or coupon to a bar code scanner or camera at the kiosk, and (vii) so on. In one embodiment, rather than scanning, the kiosk may include a text message or other communications protocol processing capability so as to receive and process an electronic message sent by a user that includes a code, indicia, or otherwise that allows the kiosk to receive, confirm, or charge for payment.
• With regard toFIG. 8, an illustration of anillustrative user interface800 to enable a user to enter an access indicia, such as a PIN, that may be operated on a kiosk is shown. Theuser interface800 may display a general representation of akeypad802 that is used on securable devices. Alternative keypad representations may be utilized, such as a touch-tone telephone keypad. As shown, thekeypad802 may include, but not limited to,numeric keys804. After the user has entered his or her access indicia, the user may select an “enter” soft-button806. If the user makes a mistake in entering the access indicia, then the user may select the “clear” soft-button808. It should be understood that if the securable devices include a different input device, such as a touch pad, biometric reader device, or otherwise, that the different input device may be represented in theuser interface800 or made available at the kiosk (e.g., biometric reader device) rather than the keypad. As shown, a “fingerprint” soft-button804aand “phone NFC” soft-button804bmay be made available if either of those input devices are made available at the securable device.
• With regard toFIG. 9, an illustration of anillustrative user interface900 of a physical securable device is shown. The user interface may include akeypad902 that includes digits, an “enter”button904 to submit an entered PIN, and an “end usage”button906 when the user has completed using the securable device. Alternative configurations of thekeypad902 may be utilized, such as one that does not include an “enter” key if all PINS are required to be a certain number of digits, such as four digits. In addition to thekeypad902, theuser interface900 may also include avisual indicator908 to show that the securable device is currently occupied and visual indicator(s)910 to show that a PIN that is entered is valid or invalid. It should be understood that theuser interface900 may be mechanical in nature, as shown, or be displayed on an electronic display. Additionally and/or alternatively, biometric reader devices, NFC reader devices, scanners, or any other input devices that may assist in identifying a user who has rented a particular locker or any available locker through a “select your own locker” option may be utilized in accordance with the principles of the present invention. Other identification options that are possible, include, but are not limited to, barcode scanning, imaging, QR code scanning, machine readable code scanning, keyfob reading, key usage, magnetic strip card reading, Internet communication via smart phone or tablet, Near Field Communication (NFC) via smart phone or device, or any other technique.
Portable Locker
• With regard toFIG. 10, an illustration of anillustrative amusement park1000 is shown. Theamusement park1000 may include a number of different sections, includingsection1002a,1002b,1002c, and1002d(collectively1002). Each of the different sections may have a different theme, as understood in the art. As people who attend amusement parks are well aware, traveling between the different sections of an amusement park can be very time consuming, especially with children. As such, people who visit amusement parks and have valuables or other items of which they wish to store, tend to store those items in lockers that are central or conveniently located near the front of the park. However, by storing items in lockers near the front of the park, to retrieve those items during the day, the user is inconvenienced. As a result, people avoid renting lockers and, thus, have to carry their valuables or other items with them, thereby reducing their enjoyment and overall satisfaction with their park experience.
• Another problem that amusement parks have tried to solve over the years providing adequate and safe storage of items at rides on which people generally need to leave their valuables, such as sunglasses, wallets, prizes, mobile devices, and other items due to high speeds, inverted positions, water exposure, etc., of the rides. In some cases, those solutions are bins positioned at the ride itself. This solution, however, is insecure and many different people that are entering and exiting different cars or vehicles (e.g., boats) often have access to the items of others who are on the rides. With people carrying mobile devices, this solution is relatively unacceptable to people. As a result, an alternative, safe solution that includes a securable device is desired.
• As shown inFIG. 10, theamusement park1000 includes anentranceway1004 through which visitors of theamusement park1000 may enter. Two banks or sets ofsecurable devices1006aand1006b(collectively1006) are located close to theentranceway1004. The two banks of securable devices1006 may havekiosks1008aand1008b(collectively1008) available for visitors to rent securable devices either at theentranceway1004 or elsewhere throughout thepark1000, as further described herein. The combined banks of securable devices1006 and kiosks1008 are considered to be a securable device station. As previously described, the kiosks1008 may be configured to enable a user to rent a securable device that is associated with the kiosk(s)1008, such as any of the securable devices1006. In such a rental, the kiosks1008 may be configured to enable the user to have the kiosk assign one of the securable devices1006 to the user. Alternatively, the user may enter a PIN, for example, into the kiosk and then select one of the securable devices1006 by entering the same PIN in any of the available securable devices1006 that conforms to rental parameters (e.g., small or large securable device). In response to the user's entering a valid PIN in one of the securable devices1006, the selected securable device may be provisioned as being occupied by associating a securable device identifier with the PIN.
• As further shown in the park, a number of different securable device stations inclusive of banks of securable devices and kiosks1010a-1010q(collectively1010) are available. To avoid limiting users to a locker system in which the user initially rents a securable device, the principles of the present invention may provide for a user with a rental option that enables utilization of any securable device at a particular ride (e.g., Ferris Wheel) or location (e.g., food court), in one of the sections1002 of thepark1000, within theentire park1000, or even within multiple parks (e.g., various related or unrelated theme parks in Orlando) over a time frame (e.g., one or multi-day time span). In providing such an option, a central controller, which may or may not be part of one of the kiosks associated with any of the securable device stations1006 or1010 shown inFIG. 10, may receive all rental orders and communicate access indicia and rental parameter(s) to each of the securable device controllers that meet the conditions of the rental parameter(s). Alternatively, a central controller may receive access indicia submitted at the securable devices and determine whether or not the access indicia is valid for the associated securable devices by determining whether the access indicia meets the purchased rental parameter(s), such as one that allows for selecting a locker, one for selecting a locker at a particular time of day, and one for selecting a locker in a certain section in thepark1000.
• As another example, thepark1000 may have different types of securable devices, such as those that are large and located along walking paths and those that are small and located at loading points of a ride. The user may elect to purchase an option that allows for use of one or both types of securable devices. The user may also elect to purchase an option that allows for use of both types simultaneously so that the user may use a larger securable device to store larger items, while also allowing the user to use a small securable device to store smaller items, such as sunglasses, keys, mobile phone, wallet, etc., when participating on a ride. To employ these options, either a central or distributed network and controller configuration may be utilized, where a central configuration has a central system (e.g., server) receiving requests from each of the securable devices or their associated kiosks, if utilized, receive and verify access indicia and rental parameter(s), while a distributed configuration may have each of the local kiosks or securable device controllers handle verifying access indicia and rental parameter(s). In the central configuration, the access indicia and rental parameter(s) are not communicated from a central controller (e.g., kiosk) to securable device controllers, while the distributed configuration communicates the access indicia and rental parameter(s) to the securable device controllers so that the securable device controllers can operate autonomously from the central controller. A central configuration may be “cloud” based or a server may operate on a local network (e.g., at an amusement park).
• Fraud detection may also be employed to prevent one person renting a securable device and providing an access indicia, such as a PIN, to others for simultaneous use at other securable devices throughout thepark1000. In a central system, such a fraud detection system would verify whether the access indicia is currently in use and deny secondary requests for simultaneous usage at different securable devices. However, for a distributed configuration, the access indicia and, optionally, rental parameter(s) would be distributed to other kiosks and/or securable device controllers, and any changes to the status of usage would be distributed to the kiosks and/or securable device controller also. Sufficient memory may be provided for each of the distributed kiosks and/or securable device controllers and used to store each of the possible access indicia and associated rental parameter(s) available for use at those securable devices.
• With regard toFIG. 11, an interactive diagram of an illustrative process that1100 that enables a user to select any securable device in one or more geographic region(s) and, optionally, of a particular type, is shown. A number of different devices are shown, including a central controller1102 (e.g., kiosk) and associated securable device controllers1104a-1104n(collectively1104) that are part of locks on associated banks of securable devices. Asecondary controller1106 and associated securable device controllers1108a-1108n(collectively1108) are also provided to enable the user to (i) select his or her own securable device, as opposed to a kiosk or central controller assigning a securable device, (ii) in either of the local or remote banks of securable devices. In this context, the local bank of securable devices is the bank of securable devices that is locally associated with the respective controllers due to proximity and configuration (e.g., hardwired and/or local bus). In this example,central controller1102 is locally associated with securable device controllers1104 and secondary controller is locally associated with securable device controllers1108. Although not shown, there may be many secondary controllers locally associated with banks of securable devices each including a securable device controller. Each of the secondary controllers may operate as a kiosk that communicate with the local securable controllers to enable people to rent those local securable devices. In accordance with the principles of the present invention, each of thesecondary controllers1106 may enable a user to purchase a rental (i.e., pay for renting a securable device) that provides for the user to select a local or remotely located securable device by communicating such rental parameters in association with an access indicia along with rental parameter(s) to thecentral controller1102 and/or to other secondary controllers (not shown), as further described hereinbelow.
• Atstep1110a, thecentral controller1102 may provide a user interface to enable a user to rent a locker. The user interface may be the same or similar to the one shown inFIG. 6. Because the central andsecondary controllers1102 and1106 operate independent of one another, thesecondary controller1106 may provide the same or similar interface as the one being provided by the central controller atstep1110b. At step1112, a user request may be received and thecentral controller1102 may store an access indicia and rental parameter(s). Atstep1114, the access indicia and rental parameter(s) may be communicated to thesecondary controller1106 via a communications network. The access indicia may operate as a key for the secondary controller to use to determine whether the user is attempting to access one of the securable devices associated with the securable device controllers1108 at some point in the future. In one embodiment, the communication of the access indicia and rental parameter(s) may be performed in response to the user making the purchase. Alternatively, since the user cannot travel between thecentral controller1102 andsecondary controller1106 very quickly, the central controller may communicate such requests periodically (e.g., every 5 minutes) or aperiodically (e.g., responsive to the secondary making a request for an update in response to not recognizing an access indicia entered into one of the securable device controllers1108).
• Atstep1116, thesecurable device controller1104amay receive an access indicia, such as a PIN typed into a keypad, from a user. In a centralized configuration, the access indicia may be communicated atstep1118 to thecentral controller1102 for verification atstep1120. The verification may determine that the access indicia matches a stored access indicia along with verifying that other rental parameter(s) are satisfied (e.g., with a number of locks, within a rental time period purchased, within a rental date period purchased, within a size of securable device purchased, for a duration of time starting from a first use, or any other rental parameter). As previously described, if a distributed configuration is utilized, where thesecurable device controller1104ais capable of verifying that the access indicia is valid (i.e.,step1120 may be performed solely by thesecurable device controller1104arather than central controller1102), a situation of a power failure disabling usage of the securable devices as a battery backup may be used by the securable device controllers1104 and1108 may be avoided.
• Continuing with the centralized configuration, at step1122, an access verification indicator (e.g., Boolean value) may be communicated back to the securable device controller1104 from thecentral controller1102 to indicate that the access indicia is valid or invalid. Atstep1124, in response to the access verification indicator being received, thesecurable device controller1124 may enable or deny access to the securable device to the user. A status indicator illumination device or audible sound may be generated, as well, to alert the user to the success or failure of the attempt to access the securable device. Atstep1126, the current and further user interactions (e.g., unlocking, opening, closing, ending usage, etc.) with the securable device may be communicated by thesecurable device controller1104ato thecentral controller1102 so that thecentral controller1102 may maintain a record of the interactions, handle provisioning operations, manage and prevent fraudulent usage, and so forth.
• Atstep1128, status updates associated with the access indicia may be communicated to thesecondary controller1106 so that thesecondary controller1106 may operate independent of thecentral controller1102. As an example, if the access indicia has been used to access a securable device accessed via thesecurable device controller1104a, then the same access indicia cannot be used to simultaneously access any of the securable devices that are access controlled by the securable device controllers1108 while the securable device associated with thesecurable device controller1104ais being used by the user using the access indicia (assuming the user has purchased a rental that includes remotely located securable devices from the central controller1102).
• Atstep1130, thesecurable device controller1108amay receive an access indicia from the user. In the centralized configuration, thesecondary controller1106 is central to the securable device controllers1108 and independent from thecentral controller1102, the access indicia may be communicated from the securable device controller to thesecondary controller1106 atstep1132. Thesecondary controller1106 may verify the access indicia and, in response, communicate an access indicia indicator at step1136 back to thesecurable device controller1108a. Thesecurable device controller1108a, may, in response to receiving the indicator, enable or deny access to the user to the securable device atstep1138. Atstep1140, thesecurable device controller1108amay communicate the current and future user interactions with the securable device to thesecondary controller1106 to manage, provision, and prevent fraud. In response, thestatus updates1142 may be communicated back to thecentral controller1102 for management and redistribution purposes to othersecondary controllers1106. In an alternative configuration, thesecondary controller1106 may communicate the status updates directly with other secondary controllers and/or securable device controllers. The status updates may be performed real-time, on a period basis, or on an aperiodic basis. As with the securable device controllers1104, the securable device controllers1108 may operate in a distributed configuration such that the controllers1108 may perform verifications of access indicia entered by users independent ofsecondary controller1106.
• Although presented with regard toFIG. 11 that thecentral controller1102 may collect and manage information from thesecondary controller1106 and other secondary controllers, the principles of the present invention may alternatively utilize a “cloud” database (e.g., one accessible on a LAN or WAN, such as the Internet) that is common to each of thecontrollers1102 and1106, such that the same or similar management functionality described with respect to thecentral controller1102 is positioned on the “cloud” database. Such a “cloud” solution reduces the chances of a communications failure in the event thecentral controller1102 breaks or loses power as a “cloud” solution may also provide for redundancy. In addition, accounting, management, and reporting features may be more easily performed and accessible as lower operation resources of a “cloud” server are used as compared to the user-facingcontrollers1102 and1106. Other collection, reporting, and management configurations, such as all of the controllers sharing authorization and/or provisioning information with one another, that provide for the same or similar functionality of enabling a user to select his or her own securable device or have a “portable” securable device that is selectable from among any of the securable locker banks may be utilized.
• Furthermore, and as detailed above, users may have the option of a single use or “portable” securable device, such as a locker, rental, where a single use rental may enable a user to select one securable device from all of the securable devices in the independent banks of securable devices in an amusement park, for example. With a “portable” securable device rental, a user may change securable devices during a given time period as desired because each independentsecondary controller1106 has the rental parameter(s) that provide for an “all park,” “valid park sections,” “multi-park” rental parameter associated with the access indicia. With such a configuration, when the user has completed using a securable device, the user may press an “end rental” button and a report to acontroller1102 or1106 is performed to de-provision the access indicia from the associated securable device (e.g.,1104aor1108a). If the user forgets to press the “end rental” button, the system (e.g., secondary kiosk) may notify the user that the previous securable device is still being rented and ask whether the user wants to end that rental, as further described hereinbelow. Once de-provisioned, if the access indicia still has available time for usage with another securable device as specified by the associated rental parameter(s), then the access indicia and associated rental parameters(s) may be placed back into or otherwise identified as being available for usage by one or more of thecontrollers1102 and1106 (or “cloud” database). Alternatively, each securable device may be configured with a sensor, optical or otherwise, that automatically determines that the securable device is empty and currently unlocked or empty and unlocked for a predetermined period of time and automatically de-provisions the securable device. In one configuration, each user may select a PIN code, such as a 4-digit PIN code. Alternatively and/or additionally, each user may have a user identifier, such as a 7-digit user identifier. Other configurations are possible, as well. For example, a non-kiosk system may be provided where apps or an Internet available website on mobile devices are utilized to interact with a “cloud” database or directly with addressable controllers (e.g., controllers that control a bank of securable devices or securable device controllers).
• Continuing withFIG. 11, in an alternative embodiment, thesecondary controller1106 may operate as a “first stop” for a user in accessing a “portable” securable device at a remote securable device station, in this case includingsecondary controller1106 and securable devices associated with the securable device controllers1108, from thecentral controller1102. In this configuration, the user engages thesecondary controller1106 prior to any of the securable device controllers1108. At thesecondary controller1106, the user requests a portable locker at step1144 by selecting to move his or her portable locker to that securable device station via a user interface of thesecondary controller1106. If thesecondary controller1106 has already received an access code of the user from thecentral controller1102, then the user may gain access to a securable device associated with thesecondary controller1106 without having to re-create and/or re-rent a securable device via thesecondary controller1106. In response to thesecondary controller1106 receiving the access indicia from the user, thesecondary controller1106 may verify the access indicia and ensure that the user is complying with the parameters of his or her rental (e.g., within a purchase time limit).
• If thesecondary controller1106 determines that the user has purchased a portable securable device that is available at that securable device station, then the access indicia may be communicated to each of the securable device controllers1108 to enable the user to select his or her own securable device, as previously described. Alternatively, thesecondary controller1106 may be configured to assign a securable device for the user and communicate the access indicia to the selected securable device. Atstep1148, thesecurable device controller1108amay receive an access indicia from the user, and, in response, (i) determine that the user has access to that securable device and (ii) enable the user to access the securable device by unlocking a lock of the securable device. Atstep1150, thesecurable device controller1108amay communicate the access indicia to thesecondary controller1106, thereby notifying thesecondary controller1106 that the user has accessed the securable device controller1108. It should be understood that the access indicia received by thesecurable device controller1108amay be communicated to thesecondary controller1106 atstep1150, as well. Thesecondary controller1106 may store information associated with the user accessing thesecurable device controller1108ain a local repository and/or communicate that information remotely to thecentral controller1102 or elsewhere (e.g., “cloud” server).
• As the user further interacts with thesecurable device controller1108a, those user interactions may be reported by thesecurable device controller1108ato thesecondary controller1106 atstep1152. Thesecondary controller1106 may communicate status updates associated with the accessing the securable device to thecentral controller1102 atstep1154. Alternatively, the status updates may be communicated to another computing system, such as a “cloud” server. It should be understood that a variety of different configurations may be utilized in which thesecondary controller1106 may operate as a “first stop” for users in accessing the securable devices associated with the. securable device controllers1108.
• With regard toFIG. 12, a screenshot of an illustrativegraphical user interface1200 that may be used as an initial user rental screen at a kiosk or controller at a securable device station is shown. Thegraphical user interface1200 may provide for a number of options for a user, including soft-button1202 that allows a user to rent a single use locker or securable device at a local securable device station, soft-button1204 that allows the user to rent a multi-use ride locker, in the case of the kiosk operating in an amusement park or water park, for example, that can move to other locker or securable device stations, soft-button1206 that allows the user to move his or her multi-use ride locker to this securable device station from a currently different securable device station, and soft-button1208 that allows a user to open an expired locker or securable device. If the user selects soft-button1208 to open an expired locker, then the user may be required to add additional money for excess time beyond the expiration time that the user has used the securable device. It should be understood that the number of selectable options and specific functions of the options may vary based on an environment in which the securable device station(s) are located. For example, if the securable device station(s) are located at a ski slope, those options may be associated with mountains, lodges, top/bottom of mountain, and so forth.
• In addition to the four available selection options, thegraphical user interface1200 may provide a handicapped soft-button1210 that alerts the kiosk or controller that the user is handicapped and to accommodate the user in making available a securable device that is handicap configured. If the kiosk is configured to select a securable device for users, or at least handicapped users, then the kiosk may select a handicap-configured securable device. If the user is able to select his or her own securable device at the kiosk, then the securable device controllers of handicap-configured securable devices may be configured to allow the user to have access thereto by sending an access indicia of the user, for example.
• In addition to the functionality available on thegraphical user interface1200, help soft-buttons1212a-1212dassociated with soft-buttons1202-1208, respectively, may enable a user to receive additional information about each of the functions of the soft-buttons1202-1208. An overall help soft-button1214 may be provided to enable a user to receive instructions and information of how to use the system, kiosk, and securable devices at the securable device station and environment at which the station(s) are located (e.g., amusement park). With regard toFIG. 13, a screen shot of an illustrativegraphical user interface1300 that allows a user to enter a 7-digit customer ID into a kiosk for renting securable devices is shown. Thegraphical user interface1300 provides a soft-keypad1302 and text field(s)1304. A user of the kiosk may type in a 7-digit customer ID, such as a telephone number, and the 7-digit customer ID may be displayed in the text field(s)1304 so that the user can review prior to submission. The kiosk or other management system may use the 7-digit customer ID to verify the user and to manage the user's usage of securable devices. It should be understood that alternative number of digits may be utilized, but that a 7-digit customer ID allows for a user to use a telephone number of which he or she can easily remember.
• With regard toFIG. 14, a screen shot of an illustrativegraphical user interface1400 that allows a user to enter a 4-digit access code or indicia into a kiosk for renting securable devices is shown. A soft-keypad1402 for a user to type the 4-digit access indicia or PIN, and text field(s)1404 to allow the user to view the access indicia may be shown on the screen. It should be understood that any other number of digits may be used for the access indicia. Moreover, the access indicia may be a biometric indicia, such as a fingerprint via a fingerprint reader at the kiosk and that can also be read at the securable devices (e.g., one or more fingerprint reader for a bank of securable devices or one fingerprint reader for each securable device). The access indicia allows for the system to verify the user and securable device code.
• With regard toFIG. 15, a screen shot of agraphical user interface1500 to confirm with a user attempting to switch portable securable devices whether or not to end a currently rented securable device is shown. If, for example, the user forgets that he or she still has another securable device located at the same or another securable device station still in use, then the kiosk may notify the user by displaying amessage1502, such as “Are you sure you want to end the above rental?” and display an identifier of the current securable device (e.g., “QA Locker #3”) being rented. If the user does want to end the current rental, then the user may press a “confirm” soft-button1504. Otherwise, if the user does not want to end the current rental, then the user may press a “cancel” soft-button1506. If the user ends the existing rental, the associated controller and/or central controller may de-provision the securable device to unlock to enable other users to rent that securable device.
• With regard toFIG. 16, a screen shot of agraphical user interface1600 to display amessage1602 that lists a locker number assigned to the user, rental expiration time, and selected rental type (e.g., single use locker) is shown. Other information may additionally and/or alternatively be displayed. Once complete, the user may press a “finish” soft-button1604. In one embodiment, the kiosk may be configured to enable a user to submit an electronic address (e.g., mobile device telephone number) that allows the kiosk to communicate a message inclusive of locker number, expiration time, or other information that might be helpful to the user in using the securable device system.
• With regard toFIG. 17, a block diagram of an illustrative set ofsoftware modules1700 that may be executed on a central controller, secondary controllers, common “cloud” database, and/or securable device controllers is shown. Thesoftware modules1700 may include a manageuser interface module1702 that operates to manage a user interface, such as one shown inFIG. 6, to enable users to rent securable devices. A process securable deviceaccess transaction module1704 may be configured to receive access requests from securable devices. The access requests may be in the form of access indicia being entered into user interfaces on securable devices. Themodule1704 may receive the access indicia and determine whether the access indicia is valid or invalid based on rental parameter(s) and provide an indicator to a requesting securable device controller. In one embodiment, the verification process may be performed on a securable device controller.
• A communicate with securabledevice controllers module1706 may be configured to enable a central and/or secondary controller to communicate with securable device controllers. The communications may be performed over a communications link, such as a local area network, wide area network, or other communications network using any communications protocol, as understood in the art.
• A manage securable devicesdata repository module1708 may be configured to manage data associated with securable devices. The data may include a variety of different information, such as size, location, status (e.g., vacant or not vacant, locked or unlocked), usage/access information, or any other information.
• A manageaccess indicia module1710 may be configured to manage access indicia, including actual indicia (e.g., PIN, biometric data), date and time of purchase, rental parameter(s) (e.g., number of times to use locks purchased, duration of time purchased, dates purchased, geographic locations (e.g., at particular ride, sections of parks, multiple parks, etc.) purchased, assigned or selectable, or any other rental parameter).
• A communicate withother controllers module1712 may be configured to enable a central and/or secondary controller to communicate with other controllers. Themodule1712 may be configured to communicate status updates, access requests, new access indicia and associated rental parameter(s), and so on.
• A reportsmodule1714 may be configured to enable a supervisor of the securable device system to generate reports, including current or historical reports, usage reports, repeat user reports, or any other reports that help a supervisor manage and operate the securable device system.
• Amaintenance module1716 may be configured to assist a supervisor to maintain the securable device system, including locking or unlocking specific securable devices, disabling securable devices, operation built-in-self tests of securable devices and controllers, testing communication (i) between central and secondary controllers and (ii) between central and secondary controllers with securable device controllers, examine and edit data repositories, or any other maintenance function in accordance with the principles of the present invention.
• A parksystem communication module1718 may be configured to interface with a park computing system that manages data, such as a park's point-of-sale (POS) system. As previously provided, the parksystem communication module1718 may be in communication with a park's folio data system that manages season ticket holders who might purchase seasonal locker rentals.
• The previous description is of a preferred embodiment for implementing the invention, and the scope of the invention should not necessarily be limited by this description. The scope of the present invention is instead defined by the following claims.

Claims (24)

What is claimed:

1. A method for provisioning a securable device, said method comprising:

providing a controller user interface to enable a user to initiate access of a securable device from a set of securable devices in local communication with the controller user interface;

enabling, via the controller user interface, the user to submit an access indicia to access any one of the securable devices from the set of securable devices;

in response to receiving the access indicia, storing, by a controller computing device in communication with the controller user interface, the access indicia independent of any particular securable device identifier associated with the set of securable devices;

in response to receiving (i) the access indicia from the user interfacing with a securable device user interface associated with a selected securable device and (ii) a securable device identifier via a communications medium:

verifying that the access indicia received from the selected securable device matches the stored access indicia;

in response to verifying a match:

associating, by the controller computing device, the securable device identifier and the access indicia so as to provision the selected securable device for the user;

communicating a verification signal indicative of the access indicia received from the selected securable device matching the stored access indicia to the securable device controller; and

provisioning, by the securable device controller, the selected securable device;

alternatively, in response to the access indicia received from the securable device not matching the stored access indicia, preventing the user from accessing the selected securable device.

2. The method according toclaim 1, wherein providing a controller user interface to enable a user to initiate access of a securable device from a set of securable devices includes providing a controller user interface to enable a user to initiate access of a locker from a set of lockers.

3. The method according toclaim 1, wherein providing a controller user interface includes providing a kiosk.

4. The method according toclaim 1, wherein receiving the access indicia includes receiving data representative of a PIN.

5. The method according toclaim 1, further comprising communicating, by the controller computing device via the communications medium, the access indicia to each securable device computing device associated with respective securable device user interfaces for storage thereat prior to the user initiating access of the selected securable device.

6. The method according toclaim 1, further comprising establishing, by the controller computing device, at least one condition that defines whether the access indicia is valid.

7. The method according toclaim 6, wherein establishing the at least one condition includes establishing a condition that defines geographical locations in which the access indicia is valid.

8. The method according toclaim 7, wherein establishing the at least one condition includes establishing a condition that defines a time period during which the access indicia is valid.

9. The method according toclaim 6, further comprising communicating, by the controller computing device via a communications network, the access indicia and the at least one condition to a second controller computing device in communication with the controller computing device, the second controller computing device being configured to control provisioning of a second set of securable devices.

10. The method according toclaim 9, further comprising:

receiving, by the second controller computing device, the access indicia from a second selected securable device of the second set of securable devices and a second securable device identifier associated with the second selected securable device; and

determining, based on the at least one condition that defines whether the access indicia is valid, whether the access indicia is valid for accessing the second selected securable device of the second set of securable devices, and

if so, provisioning, by the second controller computing device, the second selected securable device;

otherwise, not provisioning the second selected securable device.

11. The method according toclaim 10, further comprising, in response to provisioning the second selected securable device, communicating the second securable device identifier to the controller computing device for provisioning thereby.

12. The method according toclaim 10, further comprising in response to receiving the access indicia and second selected securable device identifier, determining whether the access indicia is currently associated with another securable device, and, if so, preventing provisioning of the second selected securable device, otherwise, enabling provisioning of the second selected securable device.

13. A system for provisioning a securable device, said system comprising:

a set of securable devices;

a controller user interface in local communication with said set of securable devices, and configured to:

enable a user to initiate access of a securable device from said set of securable devices;

enable the user to submit an access indicia to access any one of the securable devices from the set of securable devices; and

a controller computing device in communication with said controller user interface, and configured to:

store, in response to receiving the access indicia, the access indicia independent of any particular securable device identifier associated with the set of securable devices;

in response to receiving (i) the access indicia from the user interfacing with a securable device user interface associated with a selected securable device and (ii) a securable device identifier via a communications medium:

verify that the access indicia received from the selected securable device matches the stored access indicia;

in response to verifying a match:

associate the securable device identifier and the access indicia so as to provision the selected securable device for the user;

communicate a verification signal indicative of the access indicia received from the selected securable device matching the stored access indicia to the securable device controller; and

provision the selected securable device;

alternatively, in response to the access indicia received from the securable device not matching the stored access indicia, prevent the user from accessing the selected securable device.

14. The system according toclaim 13, wherein said controller user interface is a kiosk.

15. The system according toclaim 13, wherein said controller computing device is further configured to communicate via the communications medium the access indicia to each securable device computing device associated with respective securable device user interfaces for storage thereat prior to the user initiating access of the selected securable device.

16. The system according toclaim 13, wherein said controller computing device is further configured to establish at least one condition that defines whether the access indicia is valid, the at least one condition including a condition that defines geographical locations in which the access indicia is valid.

17. The system according toclaim 16, wherein said controller computing device is further configured to establish a condition that defines a time period during which the access indicia is valid.

18. The system according toclaim 17, further comprising:

a second controller computing device in communication with the controller computing device; and

a second set of securable devices, wherein said controller computing device is further configured to communicate, via a communications network, the access indicia and the at least one condition to said second controller computing device, said second controller computing device being configured to control provisioning of said second set of securable devices.

19. The system according toclaim 18, where said second controller computing device is further configured to:

receive the access indicia from a second selected securable device of said second set of securable devices and a second securable device identifier associated with the second selected securable device; and

determine, based on the at least one condition that defines whether the access indicia is valid, whether the access indicia is valid for accessing the second selected securable device of said second set of securable devices, and

if so, provision the second selected securable device;

otherwise, not provision the second selected securable device.

20. The system according toclaim 19, wherein said second controller computing device is further configured to communicate the second securable device identifier to said controller computing device in response to provisioning the second selected securable device.

21. The system according toclaim 19, wherein said controller computing device is further configured to determine whether the access indicia is currently associated with another securable device in response to receiving the access indicia and second selected securable device identifier, and, if so, prevent provisioning of the second selected securable device, otherwise, enable provisioning of the second selected securable device.

22. A system for provisioning a securable device, said system comprising:

a set of securable devices;

a set of securable device controllers, wherein each of said securable devices includes a securable device controller;

a controller user interface in local communication via a communications medium with said set of securable device controllers, and configured to:

enable a user to initiate access of a securable device from said set of securable devices;

enable the user to submit an access indicia to access any one of the securable devices from said set of securable devices; and

a controller computing device in communication with said controller user interface, and configured to:

store, in response to receiving the access indicia, the access indicia independent of any particular securable device identifier associated with the set of securable devices;

communicate, via a communications network, the access indicia to each of the securable device controllers in said set of securable device controllers;

a selected one of said securable devices with an associated securable device controller being configured to:

in response to receiving an entered access indicia from the user at the selected securable device, verify that the entered access indicia matches the access indicia, and,

in response to verifying that the entered access indicia matches the access indicia, enable entry of the selected securable device,

otherwise, not enable entry of the selected securable device; and

communicate the access indicia and a securable device identifier associated with the selected securable device via the communications medium to said controller computing device to provision the selected securable device thereby.

23. The system according toclaim 22, wherein said controller computing device, in provisioning the selected securable device, is further configured to:

verify that the access indicia received from the selected securable device matches the stored access indicia;

in response to verifying a match:

associate the securable device identifier and the access indicia so as to provision the selected securable device for the user;

alternatively, in response to the access indicia received from the securable device not matching the stored access indicia, not provisioning the selected securable device for the user.

24. The system according toclaim 23, wherein said controller computing device is further configured to, in response to provisioning the selected securable device for the user, communicate a verification signal indicative of the access indicia received from the selected securable device matching the stored access indicia to the securable device controller; and, in response to provisioning the selected securable device, communicate a provision rejection signal to the securable device controller to prevent the user from accessing the selected securable device.

Images