Providers of banking services provide a plethora of financial services to customers to assist in the completion of transactions and to meet the needs of the customers. One service includes assisting with transactions that involve “in-hand” funds, for example, the withdrawal or deposit of cash. Currently, a customer may engage in the withdrawals and deposits of these funds by walking into a branch location of a provider and initiating the withdrawal or deposit request via interaction with a teller at the branch. However, the customer is only able to access the provider during operating hours, which are usually between the hours of 9 AM to 5 PM. Many customers may find these hours inconvenient and in conflict with their work schedules, requiring them to leave a job during the work day to complete the desired transaction. Some provider branch locations may offer an afterhours drop-box deposit service, but this is limited to availability and requires the customer to travel to a branch location that offers the service, the location possibly being far away from the customer's location. While a provider may have automated teller machines (“ATMs”) in various locations outside of a branch location to allow the customer, at any hour of the day, to withdraw cash after authenticating at the ATM, the type of transactions may not allow large withdrawals or deposits.
One embodiment relates to a lockbox bank. The lockbox bank includes one or more lockboxes. Each lockbox includes a receptacle configured to receive a currency drop-off and a locking mechanism. The lockbox bank further includes a safe coupled to the one or more lockboxes and a terminal of a lockbox computing system. The terminal of the lockbox computing system includes a network interface configured to communicate with a computing system associated with a provider of financial services, a display device configured to present information to a customer, one or more input/output devices configured to exchange data with the customer, and a processing circuit. The processing circuit includes a processor and a memory, the memory structured to store instructions that are executable by the processor. The instructions cause the processing circuit to receive, by the network interface or the one or more input/output devices, a request from the customer to use one of the one or more lockboxes for a currency drop-off; receive, by the one or more input/output devices, access credentials from the customer; and verify the access credentials. The instructions further cause the processing circuit to, in response to successful verification of the access credentials, grant the customer access to a lockbox by unlocking the locking mechanism of the lockbox and, in response to determining that the drop-off has been completed, move the drop-off from the receptacle of the lockbox to the safe.
Another embodiment relates to a method. The method includes receiving, at a lockbox computing system associated with a lockbox bank, the lockbox bank including one or more lockboxes coupled to a safe, each of the one or more lockboxes including a receptacle configured to receive a currency drop-off and a locking mechanism, a request from a customer to use one of the one or more lockboxes for a currency drop-off. The method also includes receiving, by the lockbox computing system, access credentials from the customer and verifying, by the lockbox computing system, the access credentials. The method further includes, in response to successful verification of the access credentials, granting, by the lockbox computing system, the customer access to a lockbox by unlocking the locking mechanism of the lockbox and, in response to determining that the drop-off has been completed, moving, by the lockbox computing system, the drop-off from the receptacle of the lockbox to the safe.
Another embodiment relates to a lockbox bank. The lockbox bank includes one or more lockboxes. Each lockbox includes a receptacle configured to receive a currency drop-off, a locking mechanism, and a weight sensor. The lockbox bank also includes a safe coupled to the one or more lockboxes and a terminal of a lockbox computing system. The terminal of the lockbox computing system includes a network interface configured to communicate with a computing system associated with a provider of financial services, a display device configured to present information to a customer, one or more input/output devices configured to exchange data with the customer, and a processing circuit. The processing circuit includes a processor and a memory, the memory structured to store instructions that are executable by the processor. The instructions cause the processing circuit to receive, by the network interface or the one or more input/output devices, a request from a customer to use one of the one or more lockboxes for a currency drop-off; receive, by the one or more input/output devices, access credentials from the customer; and verify the access credentials. The instructions also cause the processing circuit to, in response to successful verification of the access credentials, grant the customer access to a lockbox by unlocking the locking mechanism of the lockbox; receive a weight of the drop-off from the weight sensor of the lockbox; determine whether the weight of the drop-off matches an expected weight of the drop-off; and transmit a notification to the customer indicating whether the weight of the drop-off matches the expected weight. The instructions further cause the processing circuit to move the drop-off from the receptacle of the lockbox to the safe.
Referring generally to the figures, systems, and methods for depositing currency (e.g., U.S. dollars, Euros, yen, etc.) via a lockable box drop-off service are described. “Lockable boxes,” also referred to herein as “lockboxes,” include locking receptacles configured to receive, for example, currency dropped off by a customer. Lockboxes can be provided in a variety of shapes and configurations, such as a traditional grid of rectangles when viewed from the front but also hexagons, octagons, circles, triangles, shapes conducive for stacking, shapes conducive for aligning, and shapes that fit in with other lockboxes to form an overall shape or design. Additionally, lockboxes include lockable cubbies, lockers, compartments, cabinets, drawers, bins, baskets, boxes, caddies, capsules, cartridges, shells, chests, trunks, canisters, cubes, cubicles, cells, and the like. Lockboxes can be provided at a variety of locations, such as a branch of a bank, a mall, a parking lot, a student union, and the like.
According to the systems and methods described herein, a customer holds one or more accounts (e.g., one or more demand deposit accounts, such as a debit account or a savings account) with a provider of financial accounts. The customer brings an amount of currency to a bank of one or more lockboxes associated with the provider with the intention of dropping off the currency in one of the lockboxes. As an illustration, a customer owns a business and brings currency that customers have used to make purchases over one or more business days for deposit to the customer's account. In some arrangements, the lockboxes are configured to be accessible by customers at night (e.g., after regular business hours are over). In one example, the lockboxes are configured to be accessible between 6 AM and 12 AM. In another example, the lockboxes are configured to be accessible 24 hours a day. As such, a customer who, for example, owns a business and must be present at the business during regular business hours can bring currency payments made to the business for deposit after the customer has closed the business for the day. In some arrangements, the customer arranges the lockbox drop-off beforehand (e.g., such that the customer is provided with an order number for the drop-off). In other arrangements, the customer drops off the currency at a lockbox without any prior arrangement by the customer.
Once at a bank of one or more lockboxes, the customer accesses the lockbox using access credentials. For example, the customer provides the access credentials to a terminal of a computing system associated with the lockbox bank (e.g., a “lockbox computing system”). Depending on the embodiment, access credentials include an order number that the customer provides to the terminal, a near field communication (“NFC”) tap the customer performs with the terminal using the customer's phone, a password or personal identification number (“PIN”) that the customer provides to the terminal, and so on. The lockbox computing system then verifies whether the access credentials are correct, and if they are, the lockbox terminal grants the customer access to a lockbox for the purposes of making the drop-off. Alternatively, in some arrangements, the customer does not provide access credentials to access the lockbox and instead simply indicates to the terminal that the customer has currency to be dropped off at a lockbox. The lockbox computing system then grants the customer access to a lockbox.
Once the customer has access to a lockbox, the customer drops off the currency at the lockbox. The customer then closes the lockbox, which automatically relocks. Once the currency is in the lockbox, in some embodiments, the lockbox and/or the lockbox computing system performs one or more actions to confirm the drop-off. As an illustration, in some arrangements, the lockbox includes a weight sensor that weighs the currency that has been dropped off. The lockbox computing system determines whether the weight of the currency is approximately equal (e.g., within a certain amount of error) to an amount specified by the customer beforehand as corresponding to the currency drop-off. The lockbox computing system then performs one or more actions based on whether the weight matches the approximate weight, such as sending a notification to the customer who arranged the drop-off indicating that the drop-off has been completed and that the weight of the currency appears to match the specified amount. As another illustration, the lockbox computing system identifies or verifies the customer making the currency drop-off. As an example, the drop-off is made using a bag with an NFC device or a radio frequency identification (“RFID”) device configured to transmit a code associated with the customer. The lockbox contains an NFC or RFID device to receive the code, and the lockbox computing system is configured to verify, based on the transmitted code, which customer the drop off is for. As another example, the lockbox bank includes a camera, and the lockbox computing system is configured to use facial recognition software to identify the customer making the drop-off from the camera.
After the lockbox and/or the lockbox computing system performs the specified actions, if any, the lockbox bank is configured to move the drop-off to a more secure location. In one example, the bottom of the lockbox is configured to slide back or down, and the drop-off falls into a safe located below the lockbox. In another example, the back of the lockbox is connected to a chute that leads to a safe. The lockbox is thus configured to move the drop-off into the chute (e.g., by a back panel of the lockbox sliding away and a bottom panel of the lockbox sloping upward such that the drop-off slides into the chute), at which point the drop-off slides down the chute and into the safe. By moving the drop-off to a more secure location after the drop-off is completed, the lockbox can be used by another customer for a different drop-off, thereby decreasing the number of lockboxes needed at a single location. Moreover, in this way, the drop-offs are moved to a single, secure location to be picked up, for example, by an armored courier or an employee of the provider associated with the lockbox bank.
At some point after the drop-off occurs, an employee of the account provider verifies the amount of currency that was dropped off. The customer's account is then credited with the verified amount of currency.
The systems and methods described herein provide a number of technical advantages over present systems and methods for depositing currency. To begin with, as noted above, many customers are unable to make deposits of currency during the normal operating hours of a provider of financial accounts. While locations for night deposits exist, they can often be located far away from the customer. The present systems and methods provide for banks of lockboxes that can be accessed outside of regular business hours for deposits and can be provided at a variety of locations, thereby allowing customers to more easily make currency deposits. Moreover, these lockbox banks are configured to move currency drop-offs to secure locations, such as safes, allowing for better security of the deposit and customer confidence in the deposit system. Additionally, as noted above, the ability to move deposits from lockboxes to secure locations decreases the number of lockboxes that must be provided at a single location to serve the desired number of customers. The secure location also allows for drop-offs to be easily verified and picked up, for example, for transport to the account provider.
Additionally, some customers are unable to make deposits personally and may send, for example, an employee to make a currency drop-off. In these cases, the customer may worry that the deposit was made incorrectly or that the employee may have taken some of the currency before making the drop-off. However, according to the some of the embodiments described herein, a computing system associated with the lockbox used for a drop-off performs one or more actions to verify the drop-off. In one example, as described above, the customer specifies the amount or the approximate amount of currency in the drop-off. Once the drop-off is made, the lockbox weighs the drop-off, and the lockbox computing system verifies that the weight matches an expected weight for the amount of currency specified by the customer for the drop-off. The lockbox computing system then provides a notification to the customer confirming that the drop-off has occurred and that the amount included in the drop-off appears to be correct. As such, the customer is given peace of mind that the drop off occurred correctly.
Referring now to
The customer device 102 is associated with a customer holding one or more financial accounts with an account provider. As an example, the customer holds a checking account, a savings account, and/or a business account with an account provider. In various embodiments, the customer device 102 is a stationary or portable (e.g., mobile) computing device. As such, the customer device 102 includes, for example, any of a smartphone, a tablet, a laptop, a desktop computing system, a smart watch, smart glasses, and so on. As shown in
The network interface 120 is structured to facilitate operative communication between the customer device 102 and the other components of the system 100. For example, the network interface 120 is structured to facilitate communication between the customer device 102 and the provider computing system 104 and the lockbox computing system 106.
The input/output circuit 122 is configured to receive input from the customer via the customer device 102 and/or provide output to the customer via the customer device 102. In some embodiments, the input/output circuit 122 includes one or more input and/or output devices. In other embodiments, alternatively or additionally, the input/output circuit 122 is configured to receive communications from and/or send communications to one or more other components of the customer device 102. In some arrangements, the customer uses the input/output circuit 122 to provide information about a planned currency drop-off to the provider computing system 104 and/or the lockbox computing system 106. Additionally, in some arrangements, the input/output circuit 122 provides information received from the provider computing system 104 and/or the lockbox computing system 106 regarding a currency drop-off to the customer.
Additionally, as shown in
The display 124 is configured to visually present information (e.g., as user interfaces) to the customer. In some embodiments, the display 124 is further configured to receive information from the customer (e.g., through a keyboard provided as part of a touchscreen of the display 124). Additionally, in some arrangements, the display 124 is included in or communicably coupled to the input/output circuit 122.
The lockbox circuit 126 is configured to allow the customer to send and receive information about a currency drop-off. For example, in some embodiments, the lockbox circuit 126 is configured to provide the customer with user interfaces for arranging a lockbox currency drop-off. In other embodiments, the lockbox circuit 126 is alternatively or additionally configured to provide the customer with user interfaces showing the customer information about a planned lockbox drop-off or a completed lockbox drop-off.
The lockbox circuit 126 includes program logic (e.g., stored executable instructions) structured to implement at least some of the functions described herein. In some arrangements, the lockbox circuit 126 is implemented by accessing a website associated with the system 100 via a web browser (e.g., Safari®, Chrome®, Internet Explorer®) structured to receive and display web pages received from the provider computing system 104 and/or the lockbox computing system 106. As an illustration, the customer accesses lockbox services by logging into a provider account using online banking credentials (e.g., a username and password) via a webpage. In other arrangements, the lockbox circuit 126 is implemented as a dedicated application on the customer device 102 (e.g., as a specific lockbox currency drop-off application or as part of a banking application). For example, the lockbox circuit 126 is implemented as an application downloadable from an application store or from a specific website (e.g., a banking website associated with the provider computing system 104). In yet other arrangements, the lockbox circuit 126 is implemented through an existing or generic application, such as a text message application or an email application.
In some embodiments, the customer can arrange a drop-off using the lockbox circuit 126. For example, lockbox circuit 126 displays user interfaces allowing the customer to input information about a planned drop-off, such as the customer account that the customer would like the drop-off credited to, the drop-off amount, the desired drop-off location, and the estimated drop-off time. The lockbox circuit 126 provides that information to the provider computing system 104 and/or the lockbox computing system 106, which then provide confirmation of the drop-off to the customer via the lockbox circuit 126. As an illustration, the lockbox circuit 126 receives and provides to the customer (e.g., via the display 124) a confirmed location of the drop-off and an order number for the drop-off that the customer can use to access the lockbox 108 for the drop-off.
Alternatively or additionally, in some embodiments, the customer can receive information about a planned or completed drop-off via the lockbox circuit 126. In one example, the lockbox circuit 126 is configured to present a notification to the customer confirming that a drop-off has occurred and that a weight of the drop-off matches an estimated weight of the deposit amount. Examples of such a notification include an email, a text message, a pop-up notification, a splash page, and a push notification.
The provider computing system 104 is associated with a provider of financial accounts and services (e.g., demand deposit accounts, credit services, loan services, investment services). For example, in various embodiments, the account provider is a financial institution, such as a bank or a credit union. In the embodiment of
The network interface 130 is structured to facilitate operative communication between the provider computing system 104 and the other components of the system 100. For example, the network interface 130 is structured to facilitate communication between the provider computing system 104 and the customer device 102 and the lockbox computing system 106.
The customer accounts database 138 is structured to retrievably store information related to various customers of the provider. For example, the customer accounts database 138 stores biographical information about various customers (e.g., names, addresses, birthdays, emails, phone numbers), account information about various customers (e.g., account balances, account histories, direct deposit information), template or reference access credentials for various customers (e.g., passwords, PINs, order numbers, biometrics, customer device 102 data), and the like.
The lockbox database 140 is structured to retrievably store information about the one or more lockboxes 108. As examples, the lockbox database 140 retrievably stores information about the locations of the one or more lockboxes 108, lockbox 108 availability, lockbox 108 access hours, and so on. Moreover, in some embodiments, the lockbox database 140 is configured to retrievably store information about lockbox drop-off requests submitted by customers. For example, the lockbox database 140 stores an order number for a lockbox drop-off in association with a customer account to which the drop-off deposit amount will be credited and an amount that the customer indicated would be in the drop-off when the customer set up the drop-off.
The lockbox request circuit 134 is structured to facilitate the back-end process necessary to conduct a lockbox drop-off. Accordingly, the lockbox request circuit 134 is configured to receive and process a customer transaction request to engage in the lockbox drop-off service. Further, the lockbox request circuit 134 is configured to retrieve information about the one or more lockboxes 108 from the lockbox database 140.
In some arrangements, the lockbox request circuit 134 is initiated in response to the customer using the lockbox circuit 126 of the customer device 102 to arrange a lockbox drop-off. For example, if a customer provides a desired time for the drop-off and the customer's current zip code, via the lockbox circuit 126, the lockbox request circuit 134 is configured to determine, by accessing the lockbox database 140, that out of the plurality of lockbox locations near the customer's location, only a certain number are open or available at the customer's desired drop-off time and within a certain distance (e.g., 10 miles) of the customer. As another example, if the customer provides a desired location for the drop-off, the lockbox request circuit 134 is configured to provide the customer with an optimal time for the drop-off (e.g., based on the schedule of other planned drop-offs at that location). As yet another example, if a customer provides a desired time and location for the drop-off, and the lockbox request circuit 134 determines that the requested location is not available at that time, the lockbox request circuit 134 is configured to deny the request or provide the requesting customer with alternative locations or times wherein the drop-off could be completed. In some embodiments, the lockbox request circuit 134 is configured to provide confirmation details about a planned drop-off to the customer. For example, the lockbox request circuit 134 provides an order number to the customer that the customer can use to access a lockbox 108 at the planned location, or the lockbox request circuit 134 provides instructions to the customer for using the customer device 102 to access the lockbox 108.
In other arrangements, the lockbox request circuit 134 is initiated in response to the customer requesting access to a lockbox 108 via the lockbox computing system 106. For example, instead of scheduling the drop-off, the customer arrives at a lockbox location and uses the lockbox computing system 106 to request access to a lockbox 108 for the drop-off. In response to the drop-off request, the lockbox request circuit 134 is configured to, for example, receive information about the customer and/or the drop-off from the lockbox computing system 106 to facilitate the drop-off.
Additionally, in some embodiments, the lockbox request circuit 134 is configured to receive access credentials (e.g., from the lockbox computing system 106 or directly from the customer device 102) provided by the customer to access a lockbox 108 for the drop-off. In various arrangements, access credentials include an order number for the drop-off, a customer password, a customer PIN, and/or a customer biometric. The lockbox request circuit 134 is configured to verify the access credentials, such as by comparing a received access credential with a template credential stored in the customer accounts database 138 and/or lockbox database 140. For example, the customer provides a payment card number (e.g., by inserting a payment card associated with a customer account into a card receptacle in the lockbox computing system 106) and PIN to the lockbox computing system 106, which provides the card number and PIN to the lockbox request circuit 134. The lockbox request circuit 134 identifies the customer using the card number and verifies the PIN with a reference PIN previously provided by the customer and stored in the customer accounts database 138. If the PINs match, the lockbox request circuit 134 indicates that the lockbox computing system 106 should provide the customer with access to a lockbox 108. If the PINs do not match, the lockbox request circuit 134, for example, indicates to the lockbox computing system 106 that the customer needs to reenter the PIN or that the drop-off should be denied. Alternatively, in other embodiments, the customer access credentials authentication is carried out partially or totally by the lockbox computing system 106.
The account processing circuit 136 is configured to appropriately credit the customer's account with the drop-off deposit. For example, once an employee of the account provider (e.g., located at a centralized and secure vault) has verified the amount included in the currency drop-off, the employee provides that confirmation to the account processing circuit 136, which then credits that amount to the customer's account. In some arrangements, the account processing circuit 136 is configured to provide a provisional credit to the customer's account once the drop-off has been confirmed to prevent double usage of the drop-off funds. For example, if the drop-off weight matches an expected weight for the amount of the deposit provided by the customer, the account processing circuit 136 is configured to show a provisional credit in the customer's account (e.g., on an online banking website) that the customer can use once the deposit is confirmed. Additionally, in some embodiments, the account processing circuit 136 is configured to keep track of all lockbox drop-offs submitted and completed by the customer in order to comply with regulatory rules. Moreover, in certain embodiments, the account processing circuit 136 and the lockbox computing system 106 both keep track of the customer's drop-off transaction history, including details from request submission to completion by the customer.
The customer makes the currency drop-off at the lockbox bank 105, which includes the one or more lockboxes 108 coupled to the safe 176 and a terminal of the lockbox computing system 106 communicably coupled to the one or more lockboxes 108. The lockbox computing system 106 controls the operation of and access to the one or more lockboxes 108. In some arrangements, the one or more lockboxes 108 are provided at a lockbox bank 105 location, and the lockbox computing system 106 only controls the lockbox(es) 108 at that given location. For example, a building contains fifty lockboxes 108 that are controlled by a first lockbox computing system 106 connected to the provider computing system 104, and another building contains ten lockboxes 108 that are controlled by a second lockbox computing system 106. In other arrangements, the lockbox computing system 106 controls all lockboxes 108 provided as part of a lockbox drop-off service provided by the account provider. In yet other arrangements, the lockbox computing system 106 is associated with a single lockbox 108.
As illustrated in
The input/output circuit 152 is configured to receive input from various customers via the lockbox computing system 106 and/or provide output to various customers via the lockbox computing system 106. Similar to the input/output circuit 122 of the customer device 102, in various embodiments, the input/output circuit 152 includes one or more input and/or output devices. For example, the input/output circuit 152 includes a keypad, a biometric sensor, a card reader, a barcode scanner, and/or a fob sensor. Alternatively, or additionally, the input/output circuit 152 is configured to receive and/or send communications to one or more other components of the lockbox computing system 106. In some arrangements, the customer uses the input/output circuit 152 to provide access credentials to the lockbox computing system 106. Further, in some arrangements, the customer uses the input/output circuit 152 to make a request to use one of the lockboxes 108 to make a currency drop-off.
As shown in
In some arrangements, the input/output circuit 152 is provided at a terminal of the lockbox computing system 106 at the lockbox bank 105. Alternatively, in other arrangements, the input/output circuit 152 is at least partially provided as part of each of the lockboxes 108. For example, each lockbox 108 includes a keypad, NFC device 160, biometric sensor, card reader, barcode sensor, fob reader, and the like. The customer then provides access credentials at the specific lockbox 108 for the drop-off, for example, assigned by the provider computing system 104 for the drop-off based on a drop-off request submitted by the customer using the customer device 102.
The display 154 is configured to visually present information (e.g., user interfaces) to various customers. In some embodiments, the display 154 is further configured to receive information from various customers (e.g., through a keyboard provided as part of a touchscreen of the display 154). Additionally, in some arrangements, the display 154 is included in or communicably coupled to the input/output circuit 122.
The access control circuit 156 is configured to receive an authentication request from a customer at the lockbox computing system 106 terminal. The access control circuit 156 then determines whether to grant the requestor access to a lockbox 108. In various embodiments, the access control circuit 156 is configured to receive an access credential, such an order number, a passcode, a password, a PIN, a biometric, an access code, or the like, from a customer (e.g., via a touchscreen of the display 154, via the customer device 102 communicating through the NFC device 160, via a lockbox fob). The access control circuit 156 is configured to then authenticate the customer using the access credential. In some arrangements, the access control circuit 156 is configured to authenticate the customer by providing the access credential(s) to the provider computing system 104, which verifies the access credential(s) and provides the access control circuit 156 with an indication of whether the customer is authenticated, as described above. In other embodiments, the access control circuit 156 is configured to authenticate the customer. In one example, the provider computing system 104 provides a list of verified order numbers to the lockbox computing system 106. The access control circuit 156 is thus configured to grant lockbox 108 access to a customer who provides one of the verified order numbers to the lockbox computing system 106. For example, the access control circuit 156 pops open the lockbox 108 for the customer, indicates the number of the lockbox 108 to the customer, which is automatically opened or openable by the customer via NFC, and so on. Additionally, in some embodiments, the access control circuit 156 is configured to maintain a log of access requests, for example, including timestamps, identification of the requestor, a record of access credentials, and other information describing the request.
The content verification circuit 158 is configured to communicate with the lockbox 108 that a customer has been granted permission to access in order to verify the contents of the drop-off. For example, in some arrangements, the content verification circuit 158 is configured to receive the weight of the drop-off from the lockbox 108. The content verification circuit 158 then determines whether the weight matches an expected weight of the drop-off based on an amount the customer indicated would be included in the drop-off. For example, the content verification circuit 158 provides the weight of the drop-off to the provider computing system 104, which verifies the weight with an amount for the drop-off provided by the customer when the customer arranged the drop-off, as stored in the lockbox database 140. The lockbox computing system 106 or the provider computing system 104 then provides a notification to the customer indicating whether the drop-off weight matches the estimated weight for the drop-off. Further, in certain arrangements, the content verification circuit 158 uses machine-based learning to determine whether the drop-off weight is correct, such as by engaging a feedback loop from several verified checks from an employee of the customer to refine the accepted weight or weight range for the drop-off. Alternatively, in some arrangements, the content verification circuit 158 instructs the lockbox computing system 106 to reject the drop-off if the weight of the drop-off does not match the expected weight. In yet other arrangements, the weight is used to verify how many drop-offs have been made to serve as a replacement for certain branch tamper checks.
As another example, in some arrangements, the content verification circuit 158 receives information from the lockbox 108 about the bag used for the drop-off, such as an identifying code detected from an NFC device or RFID device embedded in the bag or a barcode on the bag that identifies the bag. The content verification circuit 158 then uses the identifying code to verify, or provides the code to the provider computing system 104 to verify, the customer associated with the bag. In certain arrangements, rather than providing access credentials to the access control circuit 156 as described above, the customer simply requests that the access control circuit 156 grant the customer lockbox 108 access to make a drop-off. The access control circuit 156 unlocks one of the lockboxes 108, and the customer makes the drop-off in the lockbox 108. The content verification circuit 158 then determines an identity of the customer using the identifying code (e.g., which is associated with a default account for the customer to which the drop-off should be credited). In this way, the customer does not need to provide any access credentials to the lockbox computing system 106 or request a drop-off beforehand in order to make the drop-off.
The one or more lockboxes 108 are structured to be secure containers for receiving currency drop-offs. In some embodiments, the one or more lockboxes 108 are configured specifically for currency drop-offs. In other embodiments, the one or more lockboxes 108 are configured to serve other lockbox functions and are repurposed as currency drop-off lockboxes 108, for example, once business hours are over. For example, during business hours, the one or more lockboxes 108 are used by the provider for making currency withdrawals by customers.
Each lockbox 108 includes a receptacle 170 configured to receive a currency drop-off from a customer. The configuration of the receptacle 170 depends on the configuration of the lockbox 108. In one example, if the lockbox 108 is shaped as a cube, the receptacle 170 is also cube-shaped. The size of the receptacle 170 can also vary depending on, for example, the configuration of the lockbox 108 or the intended use of the lockbox 108. In one example, the lockbox bank 105 includes lockboxes 108 in different sizes with differently sized receptacles 170 configured to receive different drop-off amounts. Moreover, in some arrangements, rather than being configured to receive a bag containing a drop-off, the receptacle 170 is configured with repositories for different types of currency, such as coin repositories and bill repositories. Additionally, as described in further detail below, in some embodiments, the receptacle 170 is configured to be altered or adjusted in order to move a currency drop-off from the receptacle 170 to a secure location (e.g., the safe 176).
Each receptacle 170 also includes a locking mechanism 171 configured to lock, open, close, or otherwise control access to the secure receptacle 170. For example, a locking mechanism 171 according to various embodiments includes a solenoid, motor, actuator, or other mechanical device configured to physically lock or unlock a door or other access point (e.g., implemented as a magnetic lock configured to selectively power and de-power an electromagnet that holds a door in a locked position). The locking mechanism 171 is controlled by the lockbox computing system 106 such that the lockbox computing system 106 limits access to the receptacle 170.
In various embodiments, each lockbox 108 includes one or more sensors configured to provide information about use of the lockbox 108 to the lockbox computing system 106. For example, in the embodiment of
As shown in
Referring to
The customer sets up a lockbox drop-off at 206. In some embodiments, the customer uses the customer device 102 to access, for example, an application or a website associated with the provider, through which the customer inputs information about the drop-off. The provider computing system 104 then uses that information to set up the drop off. For example, the customer inputs an amount of the drop-off and a desired location for the drop off, which the provider computing system 104 confirms by providing the customer with an order number. In other embodiments, the customer sets up a lockbox drop-off through another method, such as by calling a service center associated with the provider or by visiting a branch location associated with a provider and working with a provider employee to set up the drop-off. Alternatively, in some embodiments, the customer does not set up a lockbox drop-off 206 ahead of the drop-off. Instead, the customer simply visits the lockbox bank 105 and arranges the drop-off on site.
The customer provides access credentials to the lockbox computing system 106 at 208. In various embodiments, the customer provides access credentials to the lockbox computing system 106 via a terminal associated with the lockbox computing system 106 at the lockbox bank 105. In some embodiments, the customer uses the customer device 102 to transmit the access credentials. For example, the customer opens an application associated with the provider on the customer device 102, and the customer device 102 transmits the access credentials to the lockbox computing system 106 (e.g., via NFC or RFID). In other embodiments, the customer inputs access credentials through an input/output device of the lockbox computing system 106, such a keypad or touchscreen. Depending on the embodiment, the access credentials are an order number, a PIN, a password, a passcode, a biometric, and the like. Additionally, in some arrangements, the customer uses a physical object to provide at least some of the access credentials, such as a fob that the customer touches to a fob reader of the lockbox computing system 106 terminal or a payment card associated with a customer account that the customer inserts into a card reader of the terminal. Further, in some arrangements, the customer provides more than one access credential to the lockbox computing system 106 to gain access to the lockbox 108, such as a customer identifier (e.g., a customer name, email address, phone number) and an authenticator (e.g., a password, biometric sample, fob). For example, the customer provides two-factor authentication access credentials to the lockbox computing system 106.
Alternatively, in other arrangements, the customer provides no access credentials to the lockbox computing system 106. Instead, the customer simply requests access to a lockbox 108, and the lockbox computing system 106 verifies the identity of the customer making the drop-off through another method, such as by identifying the customer through an NFC or RFID device in the bag used for the drop-off or identifying the customer using a camera provided at the lockbox bank 105.
The lockbox computing system 106 receives the access credentials at 210. The lockbox computing system 106 then verifies the access credentials at 212. If the customer is verified, the lockbox computing system 106 grants the customer access to a lockbox 108 at 218. In some embodiments, the lockbox computing system 106 itself verifies the access credentials. For example, the lockbox computing system 106 receives a list of order numbers for prearranged drop-offs for a given period of time from the provider computing system 104. As such, when the lockbox computing system 106 receives an order number from a customer, the lockbox computing system 106 verifies the input order number by comparing the order number to the list. If the order number matches a number on the list, the lockbox computing system 106 grants the customer access to a lockbox 108 (e.g., by unlocking the locking mechanism 171 of the lockbox 108).
Alternatively or additionally, the lockbox computing system 106 communicates with the provider computing system 104 to verify the access credentials at 214. For example, the lockbox computing system 106 provides the access credentials to the provider computing system 104, which verifies whether they match template or reference access credentials stored for the customer in the customer accounts database 138 and/or the lockbox database 140. The provider computing system 104 then indicates that the access credentials have been verified to the lockbox computing system 106 at 216. In response, the lockbox computing system 106 grants the customer access to a lockbox 108 at 218 (e.g., by unlocking the locking mechanism 171 of the lockbox 108).
Once the customer has been given access to the lockbox 108, the customer drops off the currency deposit at 220. To do this, for example, the customer places the currency drop-off in the unlocked lockbox 108. The customer then relocks the lockbox 108, for example, by closing the door of the lockbox 108. In some arrangements, the locking mechanism 171 of the lockbox 108 relocks automatically once the door is closed. In other arrangements, the locking mechanism 171 of the lockbox 108 relocks once the customer indicates to the lockbox computing system 106 that the drop-off has been completed or once the lockbox computing system 106 verifies the drop-off by, for example, weighing the deposit, as described below.
The lockbox 108 receives the currency deposit at 222. In some embodiments, as part of receiving the currency deposit, the lockbox computing system 106 and lockbox 108 perform one or more actions to verify details about the deposit and/or the customer making the deposit. For example, the lockbox 108 identifies an NFC or RFID device or scans a barcode on the bag used to make the drop-off. The lockbox computing system 106 then identifies or verifies the identity of the customer associated with the bag. As another example, the lockbox computing system 106 and lockbox 108 gather visual information about the customer dropping off the currency (e.g., via a camera positioned at the lockbox bank 105 or inside the lockbox 108) and identify the customer using the visual information (e.g., via facial recognition software)
In various embodiments, the lockbox 108 weighs the currency drop-off at 224. The lockbox computing system 106 then sends a notification to the customer regarding the weight at 226, which the customer device 102 receives at 228. For example, the lockbox computing system 106 uses the weight to determine whether the weight of the drop-off is close (e.g., within a certain amount of error) to what would be expected based on an amount of currency that the customer indicated would be dropped off when the customer set up the drop-off. In some arrangements, the weight is also used to verify that the drop-off was made as part of a branch tamper. Further, in some arrangements, an indication of whether the weight for the drop-off is correct is send to the provider computing system 104 and/or to the customer holding the account. Additionally, in some embodiments, the lockbox computing system 106 and the lockbox 108 take one or more additional or alternative actions to verify details about the deposit and/or the customer making the deposit, such as by having the customer submit a biometric when the customer makes the drop-off.
Once the lockbox computing system 106 determines that the drop-off has been completed (e.g., the customer has shut the door of the lockbox 108 and/or the lockbox computing system 106 has verified the weight of the drop-off), the lockbox 108 moves the deposit to the safe 176 at 230. In one example, the safe 176 is positioned below a bank of lockboxes 108. Accordingly, a bottom of the receptacle 170 of the lockbox 108 used for the drop-off slides or pulls away such that the drop-off falls into the safe 176. In another example, the safe 176 is positioned behind a bank of lockboxes 108. The back of the receptacle 170 thus slides or moves such that the drop-off slides into the safe 176. In some embodiments, the lockbox deposit is moved to a different safe 176 depending on whether details about the deposit were successfully verified. For example, a bank of lockboxes 108 is connected to two safes 176. If the weight of the drop-off matches an approximate expected weight of the drop-off, the lockbox computing system 106 causes the lockbox 108 to move the deposit to a first safe 176. If the weight of the drop-off does not match an approximate expected weight of the drop-off, the lockbox computing system 106 causes the lockbox 108 to move the deposit to a second safe 176. The drop-offs in the second safe are then subjected to, for example, more rigorous screening before deposit before the drop-offs in the first safe.
Once the deposit amount is verified, the customer's account is credited at 232. For example, at some point after the drop-off, all of the drop-offs at the lockbox 108 location are transported to a secure location (e.g., via armed courier), such as a branch of the provider or a main vault of the provider. The amount of the drop-off is then verified by an employee of the provider, who credits the amount of the drop-off to the customer's account.
Referring now to
Referring first to
In response to the customer selecting the deposit button 302, for example, the customer is redirected to the user interface shown in
It should be understood that the fields 400-408 shown in
If the customer presses the continue button 410, for example, the customer is redirected to the user interface shown in
Once the customer is satisfied with the lockbox location and access method selections, the customer can press a submit order button 504 to confirm the drop-off options selected. The customer's selections in input fields 500 and 502 are then transmitted to the provider computing system 104. Alternatively, the customer can select a cancel button 506 to cancel the drop-off order or go back to the user interface shown in
In response to the customer selecting the submit order button 504, the drop-off order is confirmed, and the user is redirected to the user interface shown in
For example, as shown in
Alternatively, the customer can use the customer device 102 at the terminal 700 to open the lockbox computing system 106. For example, the customer can select the icon 600 shown in
However, it should be understood that
As discussed above, in various embodiments, the provider computing system 104 and/or the lockbox computing system 106 use a weight of the currency drop-off to determine whether the drop-off matches an expected weight based on the amount for the drop-off entered by the customer (e.g., $2,500 in the embodiment of
The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations present in the drawings.
It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”
As used herein, in various embodiments, the term “circuit” includes hardware structured to execute the functions described herein. In some embodiments, each respective “circuit” includes machine-readable media for configuring the hardware to execute the functions described herein. The circuit is embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit takes the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” includes any type of component for accomplishing or facilitating achievement of the operations described herein. In one example, a circuit as described herein includes one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, or XNOR), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on.
In other embodiments, the “circuit” includes one or more processors communicably coupled to one or more memories or memory devices. In this regard, the one or more processors execute instructions stored in the memory or execute instructions otherwise accessible to the one or more processors. In various arrangements, the one or more processors are embodied in various ways and are constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors are shared by multiple circuits (e.g., circuit A and circuit B comprise or otherwise share the same processor which, in some example embodiments, executes instructions stored, or otherwise accessed, via different areas of memory). Additionally, in various arrangements, a given circuit or components thereof (e.g., the one or more processors) are disposed locally (e.g., as part of a local server or a local computing system) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, in certain arrangements, a “circuit” as described herein includes components that are distributed across one or more locations.
As used herein, a processor is implemented as a general-purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a digital signal processor (DSP), a group of processing components, or other suitable electronic processing components. Additionally, in some arrangements, a “processor,” as used herein, is implemented as one or more processors. In certain embodiments, the one or more processors are structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors are coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. In some arrangements, the one or more processors take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, or quad core processor), microprocessor, etc. In some embodiments, the one or more processors are external to the apparatus, for example, the one or more processors are a remote processor (e.g., a cloud-based processor). Alternatively, or additionally, the one or more processors are internal and/or local to the apparatus. Accordingly, an exemplary system for implementing the overall system or portions of the embodiments might include general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit.
Additionally, as used herein, a memory includes one or more memory devices including non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media takes the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, or 3D NOR), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In some embodiments, the volatile storage media takes the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. In various arrangements, each respective memory device is operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, or script components), in accordance with the example embodiments described herein.
It should be understood that a “network interface,” as used herein, includes any of a cellular transceiver (Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Long-Term Evolution (LTE), etc.), a wireless network transceiver (e.g., 802.11X, ZigBee, or Bluetooth), or a combination thereof (e.g., both a cellular transceiver and a Bluetooth transceiver). In some arrangements, a network interface includes hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some arrangements, a network interface includes cryptography capabilities to establish a secure or relatively secure communication session with other devices in communication with a device that the network interface is provided thereon. Thus, in these arrangements, personal information about the user of the device, financial data, and other types of data is encrypted and transmitted to prevent or substantially prevent the threat of hacking.
In certain embodiments, an “input/output device” as used herein includes hardware and associated logics configured to enable a party to exchange information with a computing device to which the input/output device is connected. In various embodiments, an input aspect of an input/output device allows a user to provide information to the computing device and includes, for example, a touchscreen, a mouse, a keypad, a camera, a scanner, a fingerprint scanner, an eye scanner, a sensor that detects movement, a microphone, a joystick, a user input device engageable to the computing device via a USB, wirelessly, and so on, or any other type of input device capable of being used with a computing device. In various embodiments, an output aspect of an input/output device allows a party to receive information from the computing device and includes, for example, a display, a printer, a speaker, illuminating icons, LEDs, an output device engageable to the computing device via a USB, wirelessly, and so on, or any other type of output device capable of being used with a computing device.
For the purpose of this disclosure, the term “coupled” means the joining of two members directly or indirectly to one another. Such joining may be stationary or moveable in nature. Such joining may be achieved with the two members or the two members and any additional intermediate members being integrally formed as a single unitary body with one another, or with the two members or the two members and any additional intermediate members being attached to one another. Such joining may be permanent in nature or may be removable or releasable in nature.
Any foregoing references to currency or funds are intended to include fiat currencies, non-fiat currencies (e.g., precious metals), and math-based currencies (often referred to as cryptocurrencies). Examples of math-based currencies include Bitcoin, Litecoin, Dogecoin, and the like.
It should be noted that although the diagrams herein show a specific order and composition of method steps, it is understood that in various embodiments the order of these steps differs from what is depicted. As an example, two or more steps are performed concurrently or with partial concurrence. Also, in various embodiments, some method steps that are performed as discrete steps are combined, steps being performed as a combined step are separated into discrete steps, the sequence of certain processes is reversed or otherwise varied, and/or the nature or number of discrete processes is altered or varied. Furthermore, the order or sequence of any element or apparatus is varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques, with rule-based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.
The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or as acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions can be made to the design, operating conditions and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.
This application is a continuation of U.S. patent application Ser. No. 17/325,478, filed May 20, 2021 and entitled “Systems and Methods for a Night Drop System,” which is a continuation of U.S. patent application Ser. No. 16/177,788, filed Nov. 1, 2018 and entitled “Systems and Methods for a Night Drop System,” each of which is incorporated herein by reference in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
7295110 | Mercier | Nov 2007 | B2 |
9406187 | Hammonds et al. | Aug 2016 | B2 |
9745130 | Rawal | Aug 2017 | B1 |
9811784 | Wan et al. | Nov 2017 | B2 |
11017640 | Goetz | May 2021 | B1 |
11508221 | Goetz | Nov 2022 | B1 |
20100082151 | Young | Apr 2010 | A1 |
20140304156 | Geller | Oct 2014 | A1 |
20160358124 | Crane | Dec 2016 | A1 |
20170046896 | Schroader et al. | Feb 2017 | A1 |
20180046978 | Tartal | Feb 2018 | A1 |
20180197140 | Goja | Jul 2018 | A1 |
20180247481 | Gilbertson et al. | Aug 2018 | A1 |
20190231467 | Grimsley et al. | Aug 2019 | A1 |
20200077826 | Chenier | Mar 2020 | A1 |
20200151662 | Estill | May 2020 | A1 |
Number | Date | Country | |
---|---|---|---|
Parent | 17325478 | May 2021 | US |
Child | 17991797 | US | |
Parent | 16177788 | Nov 2018 | US |
Child | 17325478 | US |