Patent ID: 12211046

DETAILED DESCRIPTION

Referring generally to the figures, disclosed are systems, methods and non-transitory computer-readable media for a computing system that enables automatic customer authentication and remotely pre-staged transactions in drive-up banking. In an example illustrative scenario, a user (e.g., customer, authorized user, etc.) initiates a pre-staged transaction request from a user device. In some embodiments, the user device is a wireless user device, such as, a smart phone, a tablet, a laptop, a smart watch, etc. In some embodiments, the user device is a wired user device, such as a desktop computer, a kiosk, etc., The pre-staged transaction request may be initiated using a financial institution application, such as a mobile application, or via a financial institution website. A provider computing system that is associated with a service provider, such as a financial institution (FI), receives the pre-staged transaction request and: (1) selects a FI employee (e.g., teller) and/or service terminal to complete the request, (2) selects a transaction device to complete the request, and (3) automatically prints any transaction documents to facilitate the request. Selecting the FI employee and/or terminal may include analyzing a real-time status of each FI employee and/or terminal, analyzing a capability of reach FI employee and/or terminal, and determining the best FI employee to complete the pre-staged transaction.

As used herein, the terms “terminal”, “transaction device”, and similar terms refer to software-controlled interactive devices that are used to enable one or more users to execute a transaction. Examples of such devices include teller terminals, cash registers, ATMs, a drive-up station (e.g., a station with a pneumatic tube), and similar devices. In particular, the transaction devices described herein are advantageously controlled by software executed by on or more computing systems described herein, such that the transaction devices provide an enhanced drive-up banking experience with automatic authentication.

In a first example operating scenario, a user may use an application, provided to a user device, to pre-stage a transaction. Pre-staging the transaction (e.g., by the user and application on the mobile device) may include providing transaction details, such as a transaction account (e.g., a checking account, a savings account, a credit card account, etc.), a transaction type (e.g., a deposit, a withdrawal, a payment, etc.), and/or a transaction amount (e.g., a dollar value, a number and/or type of banknotes, etc.). In response to receiving a pre-staged transaction request, the provider computing system may generate authentication information and/or cause a token generator on the user device to generate authentication information, such as a token, a one-time password, etc. When a user arrives in the drive-up location, the provider computing system authenticates the user, for example, by receiving one or more tokens from the user device. Upon successful authentication, the financial institution performs operations including at least one of: (1) evaluating a real-time availability of tellers so as to add the user to a teller-specific dynamic queue, (2) automatically generate (e.g., print) documents for the pre-staged transaction, (3) verify transaction details, and/or (4) execute the pre-staged transaction.

In an example operating scenario, the FI computing system may request one or more authentication tokens from a user before initiating the pre-staged transaction. For example, a user may be prompted, via a user device and/or a transaction device, to input a first authentication token. The first authentication token may include an indication of which transaction device the user is using and/or a first identity token corresponding to the pre-staged transaction request such as a transaction identity (ID), a one-time password (OTP), a wireless connection to a pre-authorized mobile device (e.g., via near-field communications (NFC), Bluetooth, Wi-Fi, and the like), a personal identification number (PIN), and so on. In some embodiments, the user device may have stored in memory thereof a unique device identifier, which may include or consist of a manufacturer identifier, MAC address, IP address, mobile operating system identifier, application identifier (e.g., for the installed instance of the FI application for pre-staging transactions), user identifier, or any combination thereof. When paired to an authentication device at a particular drive-through location (e.g., when wirelessly connecting to an electronic reader, sensor, or other component of the authentication device), the user device may wirelessly transmit the device identifier as part of establishing a connection. The device identifier may comprise or may be included in the authentication token. In some embodiments, the token may be pictorially represented in the form of a scannable code, such as a QR code generated by the application provided to the user device. The second authentication token may include a second identity token that is different from the first identity token.

As will be described in more detail herein below, the first authorization token includes at least one of (1) a first identity token, (2) a an indication that a user has arrived within a second geolocation area associated with a transaction device, and/or (3) any other identifying information encoded in the token. In an some arrangements, the first identity token may include one or more identifiers, such as an obscured or anonymized identifier associated with the user device, application, session information, a user identifier (e.g., a biometric, a ID number, an account number, a PIN, a username, a password, etc.), a one-time password (OTP), an identification card, a picture of the user, a picture of the identification card and/or transaction information (e.g., a transaction ID). The first identity token may be used to verify the identity of the user and/or to verify that the user is associated with the pre-staged transaction. The second authorization token includes a second identity token. The second identity token may include one or more the same identifiers as the first identity token. In some arrangements, the second authentication token may include a different identifier than the first identity token, such that the transaction includes two forms of identification.

In an additional example operating scenario, one or more transaction devices may be designated for completing the pre-staged transactions. In some arrangements, the one or more transaction devices may be exclusive to only users that have initiated a pre-staged transaction. Accordingly, one or more transaction devices may be designated for completing non-pre-staged transaction (e.g., for users that have not initiated a pre-staged transaction). In some arrangements, the FI location does not include separate transaction devices for pre-staged transactions. In any of the above described arrangements, the user interface ofFIGS.6A and6Bmay display a notification to a user that has initiated a pre-staged transaction indicating a wait time for a pre-staged transaction compared to a non-pre-staged transaction.

The systems, methods and non-transitory computer-readable media described herein provide a technical solution to the technical problem of enabling a plurality of pre-staged transactions with automatic authentication. For example, the systems, methods and non-transitory computer-readable media described herein further provide an improved user interface for a provider employee. The improved user interface advantageously automatically arranges interactive icons displaying pre-staged transaction requests. In conventional systems, transaction requests may be ordered based on a first-come-first-serve (e.g., a queue of customers at a FI branch location, a queue of customers at a drive-up FI location, and so on), or based on a wait time (e.g., a queue based on when a customer first arrived at a FI location). The improved user interface described herein advantageously considerers multiple parameters for queuing the pre-staged transaction requests, for example, based on wait time, transaction type, and/or transaction device location.

In additional arrangements, the systems, methods and non-transitory computer-readable media described herein provide an improved transaction processing system that reduces the time to complete transactions via load balancing, queuing, and/or automatic authentication. For example, in some arrangements the FI computing system may automatically print transaction documents related to the pre-staged transaction request before and/or as the user associated with the pre-stage transaction request arrives at a FI location. In some arrangements, the FI computing system may prioritize certain pre-staged transaction requests by assigning the pre-staged transaction requests to particular tellers and/or particular transaction devices. Conventional systems may allow FI customers to interact with any teller and/or transaction device. However, when a transaction requires a different teller (e.g., a teller with higher administrative privileges) and/or a different transaction device, the transaction must be re-assigned. Accordingly, transaction requiring a particular teller and/or transaction device will be assigned to the correct teller and/or transaction device thereby preventing teller and/or transaction device re-assignment during a transaction.

Before turning to the figures, which illustrate certain example embodiments in detail, it should be understood that the present disclosure is not limited to the details or methodology set forth in the description or illustrated in the figures. It should also be understood that the terminology used herein is for the purpose of description only and should not be regarded as limiting.

FIG.1is a block diagram of a transaction computing system, according to an example arrangement. In some arrangements, the system100is associated with a service provider such as a business, a financial institution, and the like, which provides transaction devices for customers to perform transactions (e.g., deposits, withdrawals, purchases, or other transactions). In some arrangements, and as shown inFIG.1, the system100includes a provider computing system110, one or more provider devices150, one or more user devices160, one or more transaction devices170, and one or more I/O devices190. In some arrangements, the system100includes more or fewer components than as shown inFIG.1. For example, the system100one or more of the transaction device(s)170, and the I/O device(s)190may be optional components of the system100.

Each of the components of the system100are in communication with each other and are connected by a network105. Specifically, the provider computing system110, the one or more provider devices150, the one or more user devices160, the one or more transaction devices170, and the one or more I/O devices190are communicatively coupled to the network105such that the network105permits the direct or indirect exchange of data, values, instructions, messages, and the like (represented by the double-headed arrows inFIG.1). In some arrangements, the network105is configured to communicatively couple to additional computing system(s). For example, the network105may facilitate communication of data between the provider computing system110and other computing systems associated with the service provider or with a customer of the service provider such as a user device (e.g., a mobile device, smartphone, desktop computer, laptop computer, tablet, or any other computing system). The network105may include one or more of a cellular network, the Internet, Wi-Fi, Wi-Max, a proprietary provider network, a proprietary retail or service provider network, and/or any other kind of wireless or wired network.

In some arrangements, the provider computing system110may be a local computing system at a business location (e.g., a branch of a financial institution, a retail store location, or any other physical location). In some arrangements, the provider computing system110may be a remote computing system such as a remote server, a cloud computing system, and the like. In some arrangements, the provider computing system may be part of a larger computing system such as a multi-purpose server or other multi-purpose computing system. In some arrangements, the provider computing system110may be implemented on a third-party computing device operated by a third-party service provider (e.g., AWS, Azure, GCP, and/or other third party computing services).

As shown inFIG.1, the provider computing system110includes a processing circuit112, input/output (I/O) circuit120, one or more specialized processing circuits shown as an authentication circuit122, a provider device management circuit124, a user device management circuit125, a transaction device management circuit126, and a provider team management circuit128, and a database130. The processing circuit112may be coupled to the input/output circuit120, the specialized processing circuits, and/or the database130. The processing circuit112may include a processor114and a memory116. The memory116may be one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage) for storing data and/or computer code for completing and/or enabling the various processes described herein. The memory116may be or include non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memory116may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The memory116may be communicatively coupled to the processor114and include computer code or instructions for executing one or more processes described herein. The processor114may be implemented as one or more application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components. As such, the computing system110is configured to run a variety of application programs and store associated data in a database of the memory116(e.g., database130).

The input/output circuit120is structured to receive communications from and provide communications to other computing devices, users, and the like associated with the provider computing system110. The input/output circuit120is structured to exchange data, communications, instructions, and the like with an input/output device of the components of the system100. In some arrangements, the input/output circuit120includes communication circuitry for enabling the exchange of data, values, messages, and the like between the input/output device120and the components of the provider computing system110. In some arrangements, the input/output device120includes machine-readable media for enabling the exchange of information between the input/output circuit120and the components of the provider computing system110. In some arrangements, the input/output circuit120includes any combination of hardware components, communication circuitry, and machine-readable media.

In some arrangements, the I/O circuit120may include a network interface. The network interface may be used to establish connections with other computing devices by way of the network105. The network interface may include program logic that facilitates connection of the provider computing system110to the network105. In some arrangements, the network interface may include any combination of a wireless network transceiver (e.g., a cellular modem, a Bluetooth transceiver, a Wi-Fi transceiver) and/or a wired network transceiver (e.g., an Ethernet transceiver). For example, the I/O circuit120may include an Ethernet device such as an Ethernet card and machine-readable media such as an Ethernet driver configured to facilitate connections with the network105. In some arrangements, the network interface includes the hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some arrangements, the network interface includes cryptography capabilities to establish a secure or relatively secure communication session in which data communicated over the session is encrypted.

In some arrangements, the I/O circuit120includes suitable input/output ports and/or uses an interconnect bus (e.g., bus502inFIG.7) for interconnection with a local display (e.g., a liquid crystal display, a touchscreen display) and/or keyboard/mouse devices (when applicable), or the like, serving as a local user interface for programming and/or data entry, retrieval, or other user interaction purposes. As such, the input/output circuit120may provide an interface for the user to interact with various applications and/or executables stored on the provider computing system110. For example, the input/output circuit120may include a keyboard, a keypad, a mouse, joystick, a touch screen, a microphone, a biometric device, a virtual reality headset, smart glasses, and the like. As another example, input/output circuit120, may include, but is not limited to, a television monitor, a computer monitor, a printer, a facsimile, a speaker, and so on.

In some arrangements, the I/O circuit120may communicatively couple to the one or more I/O devices190(e.g., via the network105). Accordingly, the I/O circuit120may be structured to receive sensor data from the one or more I/O devices190. The I/O circuit120may also be structured to send and/or receive data to/from the I/O devices190. For example, a first I/O devices of the one or more I/O devices190may include a display, and the I/O circuit120may provide image data (e.g., a user interface, a scannable code, an operational status, etc.) to the first I/O device such that the image data is displayed by the first I/O device.

The memory116may store a database130, according to some arrangements. The database may retrievably store data associated with the provider computing system110and/or any other component of the system100. That is, the data may include information associated with each of the components of the system100. For example, the data may include information about the provider device(s)150, the user device(s)160, the transaction device(s)170, and/or the I/O device(s)190. The data may be retrievable, viewable, and/or editable by the provider computing system110(e.g., by user input via the I/O circuit120). The database130may be configured to store one or more applications and/or executables to enable operations such as transactions and/or any other operation described herein. In some arrangements, the applications and/or executables may be incorporated with an existing application in use by the provider computing system110. In some arrangements, the applications and/or executables are separate software applications implemented on the provider computing system110. The applications and/or executables may be downloaded by the provider computing system110prior to its usage, hard coded into the memory116of the processing circuit112, or be a network-based or web-based interface application such that the provider computing system110may provide a web browser to access the application, which may be executed remotely from the provider computing system110(e.g., by a user device). Accordingly, the provider computing system110may include software and/or hardware capable of implementing a network-based or web-based application. For example, in some instances, the applications and/or executables include software such as HTML, XML, WML, SGML, PHP (Hypertext Preprocessor), CGI, and like languages.

In the latter instance, a user (e.g., a provider employee) may log onto or access the web-based interface before usage of the applications and/or executables. In this regard, the applications and/or executables may be supported by a separate computing system including one or more servers, processors, network interface, and so on, that transmit applications for use to the provider computing system110.

In the arrangement shown inFIG.1, the database130stores an authentication dataset132, a provider executable134, and a user executable136. The authentication dataset132may include user account data associated with a user account such as an account number, an account balance, an account type, authentication data, and/or other data associated with a user account at the FI. The authentication data may include one or more of a password, a PIN, a voice ID, a biometric ID, a FI issued account number, a government issued ID, a token, a device identifier and so on. In some arrangements, the authentication dataset132may also store instructions for generating an OTP such that the provider computing system110and/or components thereof may generate an OTP. In some arrangements, the authentication dataset132may also store instructions for generating a user device identifier, an application instance identifier for an application represented by and/or associated with the user executable136on the user device, etc. In some arrangements, the authentication dataset132may also store instructions and/or store identifiers for establishing application sessions by the user executable136. For instance, a session may be automatically created when a user runs the user executable136to access the application on the user device and/or when it is determined (using, e.g., a sensor of the I/O device190) that the user device is in a predetermined geographical location, within a predetermined threshold of the authentication device in the drive-up location, etc. Accordingly, a session may be initiated without user interaction and may be utilized by the authentication device (e.g., via querying the authentication dataset136) to verify that the user device is indeed at the appropriate physical location, drive-up lane, etc. and to prevent the spoofing of the user device identifier. At least one of the authentication data and the OTP may be used to authenticate a user associated with a pre-staged transaction request.

The provider executable134includes one or more executables for providing a provider application on the provider device(s)150. In some embodiments, the provider executable134includes an application such as a mobile application, a computer application, and the like. In some arrangements, the provider executable134includes a web-based application such that the provider device(s)150may access the application via the network105. The provider executable134include instructions to enable operations such as pre-staged transactions described herein. For example, the provider executable134may include instructions for generating an improved provider interface (described herein, below, with respect toFIGS.5A and5B). In some embodiments, the provider executable134includes instructions for any other operation associated with the provider device(s)150described herein.

The user executable136includes one or more executables for providing a provider application on the user device(s)160. In some embodiments, the user executable136includes an application such as a mobile application, a computer application, and the like. In some arrangements, the user executable136includes a web-based application such that the user device(s)160may access the application via the network105. The user executable136include instructions to enable operations such as pre-staged transactions described herein. For example, the user executable136may include instructions for generating an improved user interface (described herein, below, with respect toFIGS.6A and6B). In some embodiments, the user executable136includes instructions for any other operation associated with the user device(s)160described herein. In various embodiments, the user executable136may include a token generator, a device identifier generator, an application instance identifier generator, a session generator, etc. In some embodiments, the generators are embodied in computer-executable code, which may be stored locally in memory of the transaction device or accessed at a remote computing system, such as the authentication dataset132at the provider computing system110.

In some arrangements, the provider computing system110includes hardware, software, or any combination of hardware and software structured to enable operations of the components of the system100. For example, and as shown inFIG.1, the provider computing system includes specialized processing circuits shown as an authentication circuit122, a provider device management circuit124, a user device management circuit125, a transaction device management circuit126, and a provider team management circuit128. The specialized circuits include any combination of hardware and software for enabling a pre-staged transaction. In some embodiments, the provider computing system110may include any combination of hardware and software including specialized processing circuits, applications, executables, and the like for controlling, managing, or enabling the operation of the other computing systems of the system100including the provider device(s)150, the user device(s)160, the transaction device(s)170, and/or the I/O device(s)190. For example, the provider computing system110may include additional processing circuits and associated software for controlling the operation of components of the system100. The additional specialized circuits may be substantially similar to the specialized processing circuits described herein below.

In some arrangements, the authentication circuit122is structured to enable automatically authenticating a user for a pre-staged transaction. In some arrangements, the authentication circuit122is structured to receive (e.g., via the I/O circuit120) from one or more components of the system100an authentication token. The authentication token may include one or more of a transaction token and an identity token. The transaction token may include information associated with a pre-staged transaction request such as a pre-staged transaction request number, an indication of a transaction device associated with the pre-staged transaction, and/or any other parameter associated with a pre-staged transaction request. The identity token may include a transaction identity (ID), a one-time password (OTP), a wireless connection to a pre-authorized mobile device (e.g., near field connection (NFC), Bluetooth, Wi-Fi, and the like), a personal identification number (PIN), a FI issued account number, a government issued ID, a device identifier, and/or any other identification or security value associated with a user.

Authenticating, by the authentication circuit122, includes receiving the authentication token and comparing the authentication token to the authentication dataset132and determining whether the authentication token is included in the authentication dataset132. For example, the authentication circuit122may receive a first authentication token having a first identity token. The authentication circuit122may compare the first identity token to identity tokens stored in the authentication dataset132. If the authentication circuit122finds a match, the authentication circuit122may provide an indication to one or more components of the provider computing system110and/or the system100that the first authentication token is verified. In some arrangements, the authentication token is received, by the authentication circuit122, from a device on the network105(e.g., via the I/O circuit120). For example, the authentication token may be received from at least one of the user device(s)160, the transaction device(s)170, and/or the I/O device(s)190. Accordingly at least one of the user device(s)160, the transaction device(s)170, and/or the I/O device(s)190may be configured to receive the authentication token from a user.

Please also make sure to describe a scenario where a customer pre-stages a transaction and their app generates the token comprising the device identifier and transaction identifier. The token can be transmitted to the provider system to be stored in a database and may be a time limited token. The authentication device will query the database to authenticate the customer-provided token against the stored token.

In some arrangements, the provider device management circuit124is structured to enable the operations of the provider device(s)150. For example, the provider device management circuit124may generate a provider interface (described herein, below). The provider device management circuit124may receive provider employee data from the provider device(s)150. The provider employee data may include a real-time (e.g., updated every second, every minute, etc.), status of each provider employee. Each real-time status includes an indication of a present task of a corresponding provider employee is doing in real-time. For example, a provider employee may be assisting a customer with a transaction, on break, idle, and so on. The real-time status may further indicate whether the present task is in progress, recently started, nearing completion, and so on. For example, the real-time status may indicate that a provider employee has recently started a break, the provider employee data may also include employee statistics for each provider employee. The statistics for each provider employee may include: years of experience, average mistakes made per transaction, seniority level, employment history, and/or other parameters associated with each provider employee.

In some arrangements, the user device management circuit125is structured to enable sending and receiving data to/from the user device(s)160. For example, the user device management circuit125may generate a user interface (described herein, below). The user device management circuit125may also be structured to receive the pre-staged transaction request from the user device(s)160. The pre-staged transaction request may include pre-staged transaction data, such as account information, transaction amounts, transaction types, and so on. The pre-staged transaction request may be received by the user device management circuit125(e.g., via the I/O circuit120and the network105).

In some arrangements, the transaction device management circuit126is structured to enable the operation of the transaction device(s)170. Accordingly, the transaction device management circuit126may include hardware and/or software for enabling the operation of the transaction device(s)170. In some arrangements, the transaction device management circuit126is structured to operate one or more components of the transaction device(s) such as transport apparatus176(described herein, below, with respect toFIG.2).

In some arrangements, the provider team management circuit128may be structured to select a provider employee of a plurality of provider employees for completing the pre-staged transaction, responsive to receiving the pre-staged transaction request. In these arrangements, the provider team management circuit128may receive provider employee data from the provider device managed circuit124. The provider team management circuit128is structured to select a provider employee for completing a pre-staged transaction based on the provider employee data. For example, provider team management circuit128may assign one or more thresholds to one or more parameters of a pre-staged transaction request including a minimum experience level provider employee, a minimum wait time, a maximum wait time, a maximum mistake risk threshold, a minimum seniority level, and/or thresholds for other parameters related to the provider employee and/or the pre-staged transaction.

In some arrangements, the provider device(s)150is a computing system for use by a provider employee. In some arrangements, the provider device(s)150may include a mobile device (e.g., smartphone, tablet, and so on), a laptop computer, a desktop computer, and the like. In some arrangements, the system100includes more than one provider device(s)150.

As shown inFIG.1, the provider device(s)150includes a processing circuit152, an I/O circuit157, and a database158. In some arrangements, the processing circuit152, the I/O circuit157, and the database158are the same or substantially similar to the processing circuit112, the I/O circuit120, and the database130of the provider computing system110. For example, the processing circuit152may include a processor, shown as processor154, and memory, shown as memory156, that is the same as or substantially similar to the processor114and memory116.

In some arrangements, the database158stores the provider executable134such that the provider device(s)150is operable to execute the provider executable134. For example, the provider device(s)150may execute the provider executable134to generate and/or display the provider interface (described herein, below).

As shown inFIG.1, the user device(s)160includes a processing circuit162, an I/O circuit167, and a database168. In some arrangements, the processing circuit162, the I/O circuit167, and the database168are the same or substantially similar to the processing circuit112, the I/O circuit120, and the database130of the provider computing system110. For example, the processing circuit162may include a processor, shown as processor164, and memory, shown as memory166, that is the same as or substantially similar to the processor114and memory116.

In some arrangements, the database168stores the user executable136such that the user device(s)160is operable to execute the provider executable134. For example, the user device(s)160may execute the user executable136to generate and/or display the user interface (described herein, below).

The transaction device(s)170is a device located at a physical location associated with the service provider (e.g., a FI branch). The transaction device(s)170is structured to enable a transaction. The transaction may be a pre-staged transaction or a non-pre-staged transaction. The transaction device(s)170may include one or more devices for passing transaction media between a provider employee and a user (e.g., customer), such as a vacuum air tube, a drawer, a series of belts or rollers, and so on. In some arrangements, the transaction device(s)170may have on-board computing systems for controlling the operation of the transaction device(s)170. In some arrangements, the transaction device(s)170may have control circuitry and a communication interface such that the operations of the transaction device(s)170are controlled by the transaction device management circuit126.

The one or more I/O devices190include one or more devices located at a physical location associated with the service provider (e.g., a FI branch). In some arrangements, the one or more I/O devices190may include any input device structured to receive one or more inputs associated with a pre-staged transaction described herein. For example, the one or more I/O devices190may include a biometric scanner, a camera, and so on. In some arrangements, the one or more I/O devices190may include any output device structured to output one or more outputs associated with a pre-staged transaction described herein. For example, the one or more I/O devices190may include a speaker, a display, and so on. In some arrangements, the one or more I/O devices190are structure to facilitate establishing communication via the network105. For example, the one or more I/O devices190may be structured to establish a near field connection (NFC), Bluetooth connection, Wi-Fi connection, and so on, between a computing device (e.g., the provider device150, the user device160, and so on) and the network105. In some arrangements, the one or more I/O devices190may have on-board computing systems for controlling the operation of the one or more I/O devices190. In some arrangements, the one or more I/O devices190may have control circuitry and a communication interface such that the operations of the one or more I/O devices190are controlled by the input/output circuit120. In some arrangements, one or more of the I/O devices190is provided on or proximally to one or more of the transaction devices170.

In some arrangements, the I/O devices190may include one or more sensors. The one or more sensors include one or more sensing devices located at a physical location associated with the service provider (e.g., a FI branch). The one or more sensors may include any physical sensor structured to detect one or more parameters associated with a pre-staged transaction described herein. For example, the one or more sensors may be structured to detect a location of a user device160, a biometric input, a video input, an audio input, and so on. In an example arrangement, the one or more sensors may include a positioning sensor, such as a GPS, structured to determine a location of a user device160and/or a provider device150. In some arrangements, the one or more sensors may have on-board computing systems for controlling the operation of the one or more sensors. In some arrangements, the one or more sensors may have control circuitry and a communication interface such that the operations of the one or more sensors are controlled by the input/output circuit120.

In some arrangements, at least one of the transaction device(s)170and/or the I/O device(s)190is structured as an authentication device. In some arrangements and as shown inFIG.2, at least one of the transaction device(s)170and/or the I/O device(s)190is provided at a particular drive-through location. Accordingly, at least one of the transaction device(s)170and/or the I/O device(s)190are structured to receive a token (e.g., an authentication token). In a first example arrangement, the transaction device(s)170may be structured to receive a user input (e.g., a touch input at a user interface174, shown inFIG.2) that includes the authentication token. In another example arrangement, the I/O device(s)190is structured as an electronic reader, sensor, or other wireless connection device, such that the I/O device(s)190wirelessly connects to the user device, and the user device may wirelessly transmit the authentication to the I/O device(s)190. In yet another example arraignment, one or more sensors of the I/O device(s)190are structured to sense, detect, or otherwise acquire a user input (e.g., a touch input, a voice input, a video input, a biometric input, etc.) that includes the authentication token.

FIG.2is a block diagram showing aspects of the system100ofFIG.1, according to an example arrangement. As shown the provider device150, the user device160, a first transaction device170a, and a first I/O device190aare communicatively coupled to each other (e.g., via the network105). In some arrangements, the provider device150, the user device160, a first transaction device170a, and a first I/O device190are also communicatively coupled to the provider computing system110.

As shown, the first transaction device170aincludes a provider interface172, a user interface174, and a transport apparatus176. The provider interface172may include interface elements for performing a transaction at the first transaction device170a. For example, the provider interface172may include a media pocket for receiving physical transaction media and providing the physical transaction media to the transport apparatus176. In some arrangements, the first I/O device190ais provided on or proximally to the provider interface172such that the first I/O device190aforms at least part of the provider interface172. For example, the provider interface172may include first I/O device190aimplemented as a display.

The user interface174may include interface elements for performing a transaction at the first transaction device170a. For example, the user interface174may include a media pocket for receiving physical transaction media and providing the physical transaction media to the transport apparatus176. In some arrangements, one or more of the first I/O device190ais provided on or proximally to the user interface174such that the first I/O device190aforms at least part of the user interface174. For example, the user interface174may include first I/O device190aimplemented as a display.

The transport apparatus176physically connects the provider interface172and the user interface174such that transport apparatus176is structured to transport physical transaction media between the provider interface172and the user interface174. In some arrangements, the transport apparatus176is one of a vacuum air tube, a drawer, and/or other suitable physical transport apparatus.

In some arrangements, the I/O device190amay enable communication between a user (e.g., customer) and a provider employee. For example the first I/O device190may include a two-way communication system having a speaker, a microphone, a video capture device, and/or a display. In some arrangements, the I/O device190amay enable communication between the provider device150and the user device160. For example the first I/O device190may include a wireless or wired transceiver capable of establishing communication between the provider device150and the user device160using a wired or wireless connection, such as Ethernet, Wi-Fi, Bluetooth, NFC, etc. For example, the first I/O device190amay include an NFC device, such as an NFC puck) positioned proximally to the user interface174. A user device160may scan the first I/O device190aand the first I/O device190amay provide an indication to the user device160(and/or to the provider device150and/or the provider computing system110via the user device160) that the user device160is at the first transaction device170a.

In some arrangements, the I/O device190amay enable receiving communication from a user (e.g., customer) and/or a user device160. For example the I/O device190amay include a user input device such as a microphone, a video capture device, a touch input device (e.g., keyboard, keypad, touchscreen display, and so on), and/or other suitable user input device. In some arrangements, the I/O device190amay include a communication between the provider device150and the user device160. For example the I/O device190amay include a wireless or wired transceiver capable of establishing communication between the provider device150and the user device160using a wired or wireless connection, such as Ethernet, Wi-Fi, Bluetooth, NFC, etc.

FIG.3is a flow diagram of a method300of enabling a pre-staged transaction with the transaction computing system100ofFIG.1, according to an example arrangement. In some arrangements, one or more of the computing systems of the system100may be configured to perform method300. For example, the provider computing system110, the provider device150, and/or the user device160may be structured to perform the method300. In some arrangements, one or more of the transaction device(s)170and/or the I/O device(s)190may be configured to perform the method300. In an example arrangement, the provider computing system110, the provider device150, and/or the user device160may, alone or in combination with other devices, such as the a transaction device(s)170and/or the I/O device(s)190may perform the method300. In some arrangements, the method300may include user inputs from a user (e.g., a provider employee) one or more user devices (such as devices of provider employees), another computing device on the network105, and the like.

In broad overview of method300, at step302, the provider computing system110receives a pre-staged transaction from the user device160. At step304, the provider computing system110receives a customer arrival notification. At step306, the provider computing system110evaluates a real-time status of tellers. At step308, the provider computing system110determines whether a teller is capable of processing the pre-staged transaction. At step310, the provider computing system110adds the customer to a teller-specific dynamic service queue. At step312, the provider computing system110generates documents for the transaction. At step314, the provider computing system110provides a service alert to the teller. At step316, the provider computing system110verifies the transaction. At step318, the provider computing system110completes the transaction. In some arrangements, the steps of the method300may be performed in a different order than as shown inFIG.3. For example, step308may be performed before step306. In some arrangements, the method300may include more or fewer steps than as shown inFIG.3.

Referring to the method300in more detail, at step302, the provider computing system110receives a pre-staged transaction request from the user device160. As briefly described above, the pre-staged transaction request includes one or more transaction parameters, such as an account number, a transaction type, a transaction amount, and so on. In some arrangements, the provider computing system110receives the pre-staged transaction request from the user device160via the network105.

At step304, the provider computing system110receives a customer arrival notification. The customer arrival notification may be received from the one or more I/O devices190. For example, the one or more I/O devices190may detect that a user device160has entered a first geolocation area, where the geolocation area is associated with a physical location of the FI.

At step306, the provider computing system110evaluates a real-time status of tellers. As described above, the provider team management circuit128may receive real-time status data from the provider device(s)150. The provider team management circuit128may determine, based on the real-time status data, a real time status for each of a plurality of provider employees.

At step308, the provider computing system110determines whether a teller is capable of processing the pre-staged transaction. In some arrangements, the provider team management circuit128may receive provider team member data including provider team member statistics. The provider team management circuit128may determine based on the provider team member statistics and/or the real time status of each provider employee, whether a provider employee is capable of processing the pre-staged transaction. For example, the provider team management circuit128may determine that a first provider employee is capable of processing the pre-staged transaction if the first provider employee's real-time status indicates that the first provider employee is currently idle or will finish a different work event (e.g., assisting another customer, on break, starting a shift, and so on) within a predetermined time period. The time period may be based on one or more of the transaction type, an amount of time the customer has already been waiting, and/or other parameters associated with the pre-staged transaction. In some arrangements, the provider team management circuit128may further determine that a first provider employee is capable of processing the pre-staged transaction if the first provider employee's statistics (e.g., experience level, tendency to make mistakes, seniority level, and so on) are within a threshold amount associated with the pre-staged transaction.

At step310, the provider computing system110adds the customer to a teller-specific dynamic service queue. The teller-specific dynamic service queue may be displayed on the provider device150(as described herein, below, with respect toFIG.5). In some arrangements, the provider team management circuit128and/or the provider device management circuit124may update the teller-specific dynamic service queue with additional pre-staged transaction requests. Accordingly the teller-specific dynamic service queue may be advantageously automatically updated with new pre-staged transaction requests as the provider computing system assigns customers to the teller-specific dynamic service queue. The pre-staged transaction requests may be positioned in the queue in an order based on a transaction type, an amount of time a customer has been waiting, and/or other parameters associated with the pre-staged transaction requests. For example, a first type of transaction may have a higher priority than a second type of transaction. Accordingly, a first pre-staged transaction request for a first transaction type may be positioned in a teller-specific dynamic service queue before a second pre-staged transaction request for a second transaction type. Additionally, a first pre-staged transaction request having a first user arriving before a second user associated with a second pre-staged transaction request may be positioned before the second pre-staged transaction request in the teller-specific dynamic service queue. In an example arrangement, the provider computing system110is structured to consider multiple variables when ordering the pre-staged transaction requests in the teller-specific dynamic service queue, such as teller experience, teller seniority level, number of pre-staged transactions already in a teller queue, teller break or shift start and end time (e.g., by comparing the expected transaction completion time to the amount of time remaining until a teller's scheduled break or end time), availability of media in a particular teller terminal (e.g., cash, transaction receipts, etc.).

At step312, the provider computing system110generates documents for the transaction. For example, if the pre-staged transaction request for a pre-staged transaction requires a specific document, the provider computing system110may automatically generate (e.g., print, via the I/O circuit120) the specific document for the pre-staged transaction. In some arrangements, the pre-staged transaction does not require a document and the provider computing system110skips step312.

At step314, the provider computing system110provides a service alert to the teller. The provider computing system110may, at least partially, generate a notification for displaying on the provider device150. In some arrangements, the provider device150, at least partially, generates the notification. The notification indicates that the user has arrived at a designated transaction device.

At step316, the provider computing system110verifies the transaction. For example, the authentication circuit122may authentic a user, as described, above, with respect toFIG.1. At step318, the provider computing system110completes the transaction. For example, the transaction device management circuit126may cause the transport apparatus176to pass physical transaction media between the provider interface172and the user interface174.

FIG.4is a flow diagram of a method320of enabling a pre-staged transaction with the transaction computing system100ofFIG.1, according to an example arrangement. In some arrangements, one or more of the computing systems of the system100may be configured to perform method320. For example, the provider computing system110, the provider device150, and/or the user device160may be structured to perform the method320. In some arrangements, one or more of the transaction device(s)170, and/or the I/O device(s)190may be configured to perform the method320. In an example arrangement, the provider computing system110, the provider device150, and/or the user device160may, alone or in combination with other devices, such as the a transaction device(s)170, and/or the I/O device(s)190may perform the method320. In some arrangements, the method320may include user inputs from a user (e.g., a provider employee) one or more user devices (such as devices of provider employees), another computing device on the network105, and the like. In some arrangements, the method320is performed concurrently, partially concurrently, or sequentially with the method300.

In broad overview of method320, at step322, the provider computing system110receives an indication of an active user session. At step324, the provider computing system110receives a customer arrival indication. At step236, the provider computing system110receives an input of a customer designating transaction details for pre-staging a transaction. At step328, the provider computing system110confirms the pre-staged transaction. At step330, the provider computing system110receives arrival details. At step332, the provider computing system110receives a second authentication. At step334, the provider computing system110receives approval confirmation. At step336, the provider computing system110completes the transaction. In some arrangements, the steps of the method320may be performed in a different order than as shown inFIG.4. For example, step236may be performed before step324. In some arrangements, the method320may include more or fewer steps than as shown inFIG.4.

Referring to the method320in more detail, at step322, the provider computing system110receives an indication of an active user session. The active user session may be a user session on a mobile application, a desktop application, a web browser, and so on. The user session may include the user interface described herein, below with respect toFIG.6. The user session may be configured to enable generating the pre-staged transaction request. In some arrangements, the provider computing system110may receive an indication that the user device160has executed the user executable136.

At step324, the provider computing system110receives a customer arrival indication. The customer arrival notification may be received from the one or more I/O devices190. For example, the one or more I/O devices190may detect (e.g., via a GPS signal received from the user device, via a device pairing request, by a proximity sensor, etc.) that a user device160has entered a first geolocation area, where the geolocation area is associated with a physical location of the FI. In some arrangements, when the provider computing system110receives the customer arrival indication, the provider computing system automatically causes the user device160to enter a branch mode. Software for executing the branch mode may be stored by the provider computing system110and/or the user device160. For example, the user executable136may include instructions for executing the branch mode. The branch mode may allow the user device160to interact directly with the components of the system100and/or enable executing the pre-staged transaction. The branch mode may include a second user interface as shown inFIG.6Band described herein, below.

At step236, the provider computing system110receives an input of a customer designating transaction details for pre-staging a transaction. The input may be received from the user device160and via the network105. A user may input the transaction information into the user device160(e.g., via the user interface shown inFIG.6A). The customer designating transaction details may include transaction information such as a transaction account, a transaction type, a transaction amount, and so on.

At step328, the provider computing system110confirms the pre-staged transaction. Responsive to receiving the transaction information form the user device160, the provider computing system110may generate a notification indicating that the pre-staged transaction request for the pre-staged transaction has been received. In some arrangements, the notification includes an indication of which transaction device170the user should use to complete the pre-staged transaction. In some arrangements, the notification includes an indication of which provider employee will assist the user in completing the pre-staged transaction. In some arrangements, the notification is sent via a mobile application notification (e.g., a “push notification”), a text message (e.g., SMS, MMS, RCS), e-mail, and/or other suitable communication method.

At step330, the provider computing system110receives arrival details. The arrival details may include the first authentication token. As briefly described above, the first authentication token may include an indication that a user has arrived within a second geolocation area associated with a transaction device and/or any other identifying information encoded in the token. In some arrangements, the transaction device is the same transaction device indicated at step328. The first authentication token may also include a first identity token, which may include an obscured or anonymize identifier associated with the user device, application, session information, and/or user. The first authentication token may be received via the one or more I/O device190.

In a first example arrangement, the first authentication token is received in the form of a user voice input. For example, a user may speak into a microphone and verbally provide the first authentication token. For example, the user may verbally provide the transaction ID. In some arrangements, the user may press a button to activate the microphone. In some arrangements, the microphone is provided on the user device160, on the transaction device170, or as a stand-alone I/O device190.

In a second example arrangement, the first authentication token is received in the form of a one-time password (OTP). In some arrangements, the OTP is provided to the user, via the user device160. The OTP may be generated by the provider computing system110and/or the provider device150(e.g., using the authentication dataset132). In some arrangements, the OTP is automatically transmitted to the user device160when the provider computing system110confirms the pre-staged transaction. In some arrangements, the OTP is manually transmitted to the user device160by a provider employee using the provider device150. In some arrangements, the OTP is entered by the user into the user interface174of the transaction device170. In some arrangements, the OTP is entered by the user into the user interface of the user device160. In some arrangements, the OTP is entered by the user into one or more I/O devices190, such as a touchscreen device, a keyboard, a keypad, etc., associated with the transaction device170.

In a third example arrangement, the first authentication token is received in the form of a communication from the user device160. For example, a user may “tap” the user device160on a NFC device associated with the transaction device170. In an example arrangement, the “tap” may initiate a wireless communication between the user device160and the provider computing system110. In other arrangements, the user device160may additionally and/or alternatively establish communication with the provider device150, and/or the transaction device170. Once communication is established, the provider computing system110(e.g., the user device management circuit125) may cause the user device160to transmit the first authentication token. In additional and/or alternative arrangements, the user device160may include a mobile wallet having a user debit card saved therein. The user device160may provide a debit card via the NFC device when the user “taps” the user device160to the NFC device.

In a fourth example arrangement, the first authentication token is received in the form of a communication from the user device160. For example, a user may scan a scannable code (e.g., a quick response code) using a sensor (e.g., camera) of the user device160. In an example arrangement, scanning the code may cause the user device160to initiate a wireless communication between the user device160and the provider computing system110. In other arrangements, the user device160may additionally and/or alternatively establish communication with the provider device150, and/or the transaction device170. Once communication is established, the provider computing system110(e.g., the user device management circuit125) may cause the user device160to transmit the first authentication token.

At step332, the provider computing system110receives a second authentication. The second authentication may be a second authentication token including a second identity token. The second identity token may include one or more of a password, a PIN, a OTP, a biometric scan, an identification card, a picture of the user, a picture of the identification card, and/or other suitable identifying parameters. In some arrangements, the second authentication token may include physically passing one or more identification documents (e.g., a drivers license, a passport, etc.) from the user to a provider employee (e.g., via the transport apparatus176).

At step334, the provider computing system110receives approval confirmation. The approval confirmation may include an indication that the user approves the pre-staged transaction. In some arrangements, prior to receiving the approval confirmation, the provider computing system110causes the user device160to display the transaction information. In an example arrangement, the user may provide a confirmation to the provider computing system110via the user device160. For example, the confirmation may be provided by an input to a mobile application, input to a web-based application, a text message, and the like. In some arrangements, the confirmation is received via the I/O devices190. For example, the confirmation may be provided by verbally via a microphone, a video capture, or other communication method.

At step336, the provider computing system110completes the transaction. For example, the transaction device management circuit126may cause the transport apparatus176to pass physical transaction media between the provider interface172and the user interface174.

FIG.5Ais an illustration of some aspects of a provider device interface400showing interactive icons, according to an example arrangement. The provider device interface400includes a first interface feature410. The first interface feature410may include the teller-specific dynamic service queue. As shown inFIG.5A, the first interface feature410includes one or more interactive icons shown as a first icon412, a second icon414, and a third icon416. It should be understood that the first interface feature410may include more or fewer interactive icons than as shown inFIG.5A.

In some arrangements, each of the interactive icons (e.g., the first icon412, the second icon414, and the third icon416) depict a pre-staged transaction request. For example, the first icon412depicts a first pre-staged transaction request shown as “Pre-staged transaction request A”. Each icon may depict one or more transaction parameters associated with the pre-staged transaction request. For example and as shown inFIG.5A, each icon may depict a wait time, a transaction type, and an assigned transaction device. It should be understood that the icons may include more or fewer transaction parameters than as shown inFIG.5A. In some arrangements, the interactive icons (e.g., the first icon412, the second icon414, and the third icon416) are ordered based on the teller-specific dynamic service queue. For example, the first icon412may represent the most urgent and/or the most important pre-staged transaction request. As described above, the provider computing system110may determine, based on one or more of the wait time, the transaction type, and/or other transaction parameters, the urgency and/or importance of each pre-staged transaction request, and the provider computing system110may order the -staged transaction requests based on the determination.

FIG.5Bis an illustration of some aspects of the provider device interface400ofFIG.5A, according to an example arrangement. The provider device interface400includes a second interface feature420. The second interface feature420may include an interface for enabling a pre-staged transaction. As shown inFIG.5B, the second interface feature420includes one or more interactive features shown as a first feature422, a second feature416, and a third feature430. It should be understood that the second interface feature420may include more or fewer interactive features than as shown inFIG.5B.

The first feature422may include a first interactive feature424. The first feature422may depict information related to verifying an identity of a user device160and/or an identity of a user associated with the user device160. For example, the first feature422may depict options that the user has pre-approved for verifying the user's identity, such as an identity token (described herein, above). In some arrangements, a provider employee may interact with the first interactive feature424to cause the user device160to capture and/or transmit the identity token. In some arrangements, selecting the first interactive feature424causes the provider computing system110to generate an OTP and provide the OTP to the user device160.

The second feature426may include a second interactive feature428. The second feature426may depict information related to verifying the pre-staged transaction. For example, the second feature426may depict transaction details such as an account number, a transaction type, and so on. In some arrangements, a provider employee may interact with the second interactive feature428to cause the user device160to display and/or transmit a transaction verification.

The third feature430may include a third interactive feature432. The third feature430may depict information related to completing the pre-staged transaction. For example, the third feature430may depict steps for completing the pre-staged transaction. In some arrangements, a provider employee may interact with the third interactive feature432to cause the transport apparatus176of the transaction device170to transport transaction media between the user and the provider employee.

FIG.6Ais an illustration of some aspects of a user device interface440showing interactive icons, according to an example arrangement. The user device interface440includes a first interface feature450. The first interface feature450may include a pre-staged transaction request form. As shown inFIG.6A, the first interface feature450includes one or more interactive icons shown as a first icon452, a second icon454, and a third icon456. It should be understood that the first interface feature450may include more or fewer interactive icons than as shown inFIG.6A.

In some arrangements, each of the interactive icons (e.g., the first icon452, the second icon454, and the third icon456) depict steps to complete a pre-staged transaction request. The first icon452may involve selecting and/or inputting an account for the pre-staged transaction. For example, the user may select between a checking and savings account. The second icon454may include selecting a transaction type. For example, the user may select from a list of transaction types. The third icon465may include inputting and/or selecting transaction details, such as a transaction amount. For example, the user may input, via a keyboard, a transaction amount.

FIG.6Bis an illustration of some aspects of the user device interface440ofFIG.6A, according to an example arrangement. The user device interface440includes a second interface feature460. The second interface feature460may include an interface for enabling a pre-staged transaction. As shown inFIG.6B, the second interface feature460includes one or more interactive features shown as a first feature462, a second feature466, and a third feature470. It should be understood that the second interface feature460may include more or fewer interactive features than as shown inFIG.6B. In some arrangements, the second interface feature460is displayed when the user device160is caused to enter a branch mode.

The first feature462may include a first interactive feature464. The first feature462may depict information related to verifying an identity of a user device160and/or an identity of a user associated with the user device160. In an example arrangement, the first feature462may be inactive until a provider employee sends a request for identity verification. In some arrangements, the first feature462is always active. When the first feature462is active, a user may select the first interactive feature464to input and/or send the identity verification (e.g., identity token). In some arrangements, selecting the first interactive feature464may cause the user device160to capture a voice recording, capture a picture, receive a user input (e.g., a password, an OTP, and the like) or other data related to the identity verification. In some arrangements, selecting the first interactive feature464may cause the user device160to transmit the identity verification to the provider computing system110.

The second feature466may include a second interactive feature468. The second feature466may depict information related to verifying the pre-staged transaction. For example, the second feature466may depict transaction details such as an account number, a transaction type, and so on. In an example arrangement, the second feature466may be inactive until a provider employee sends a request for transaction verification. In some arrangements, the second feature466is always active. When the second feature466is active, user may interact with the second interactive feature468to cause the user device160to transmit a transaction verification.

The third feature470may include a third interactive feature472. The third feature470may depict information related to completing the pre-staged transaction. For example, the third feature470may depict steps for confirming that the pre-staged transaction has been completed. In an example arrangement, the third feature470may be inactive until a provider employee sends an indication that the transaction is completed. In some arrangements, the third feature470is always active. In some arrangements, a user employee may interact with the third interactive feature472to send a notification to the provider computing system110that the user has confirmed that the pre-staged transaction is complete.

FIG.7is a component diagram of an example computing system suitable for use in the various arrangements described herein, according to an example arrangement. For example, the computing system500may implement an example provider computing system110, a provider device150, a user device160, and/or various other example systems and devices described in the present disclosure.

The computing system500includes a bus502or other communication component for communicating information and a processor504coupled to the bus502for processing information. The computing system500also includes main memory506, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus502for storing information, and instructions to be executed by the processor504. Main memory506can also be used for storing position information, temporary variables, or other intermediate information during execution of instructions by the processor504. The computing system500may further include a read only memory (ROM)508or other static storage device coupled to the bus402for storing static information and instructions for the processor504. A storage device510, such as a solid state device, magnetic disk or optical disk, is coupled to the bus502for persistently storing information and instructions.

The computing system500may be coupled via the bus502to a display514, such as a liquid crystal display, or active matrix display, for displaying information to a user. An input device512, such as a keyboard including alphanumeric and other keys, may be coupled to the bus502for communicating information, and command selections to the processor504. In another arrangement, the input device512has a touch screen display. The input device512can include any type of biometric sensor, a cursor control, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor504and for controlling cursor movement on the display514.

In some arrangements, the computing system500may include a communications adapter516, such as a networking adapter. Communications adapter516may be coupled to bus502and may be configured to enable communications with a computing or communications network105and/or other computing systems. In various illustrative arrangements, any type of networking configuration may be achieved using communications adapter516, such as wired (e.g., via Ethernet), wireless (e.g., via Wi-Fi, Bluetooth), satellite (e.g., via GPS) pre-configured, ad-hoc, LAN, WAN, and the like.

According to various arrangements, the processes that effectuate illustrative arrangements that are described herein can be achieved by the computing system500in response to the processor504executing an arrangement of instructions contained in main memory506. Such instructions can be read into main memory506from another computer-readable medium, such as the storage device510. Execution of the arrangement of instructions contained in main memory506causes the computing system500to perform the illustrative processes described herein. One or more processors in a multi-processing arrangement may also be employed to execute the instructions contained in main memory506. In alternative arrangements, hard-wired circuitry may be used in place of or in combination with software instructions to implement illustrative arrangements. Thus, arrangements are not limited to any specific combination of hardware circuitry and software.

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 that may be 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, the term “circuit” may include hardware structured to execute the functions described herein. In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be 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 may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOC) circuits), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on.

The “circuit” may also include one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some embodiments, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, a “circuit” as described herein may include components that are distributed across one or more locations.

An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing devices 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. Each memory device may include 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 may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, 3D NOR), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take 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. Each respective memory device may be 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, script components), in accordance with the example embodiments described herein.

It should also be noted that the term “input devices,” as described herein, may include any type of input device including, but not limited to, a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. Comparatively, the term “output device,” as described herein, may include any type of output device including, but not limited to, a computer monitor, printer, facsimile machine, or other output devices performing a similar function.

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 may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be 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 may be 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 may be made in the design, operating conditions and embodiment of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.