AUTHENTICATING AND VERIFYING USERS WITH UNIQUE IDENTIFICATION NUMBERS AND FINGER VEIN PATTERNS

Techniques for executing authenticated and verified transactions using a finger vein pattern in combination with a Unique Identification Number (UIN) is disclosed. The techniques may be used to process one or more payment transactions between a registered customer and a registered merchant. The UIN and the finger vein pattern of the customer authorize payment to a merchant once a match is authenticated and verified based on the UIN and finger vein pattern.

FIELD OF INVENTION

The present invention relates to the field of identification and authentication of a user and, in particular, identifying and authenticating a user with a unique identification number and finger vein pattern.

BACKGROUND

Face-to-face transactions between merchants and customers are generally based on payment by card (e.g., credit or debit card(s)) for the payment of product(s) or service(s)). This usually requires the customer to insert or swipe a card into or through a reader included in or connected to a point-of-sale device. Alternatively, a user may be able to tap a card against a reader/point-of-sale device or transfer card data to a point-of-sale device via a contactless payment method, such as a phone app. The point-of-sale device then processes payments between the Merchant(s) and the Customer(s).

For verification and security clearance, merchant(s) sometimes request the customer(s) to present a proof of identification (e.g., Government issued ID like Drivers' license or International Passport) and payment is then processed. However, proof of identification is rarely required/implemented and, card fraud is relatively widespread. In response to card fraud, customers dispute transactions, which, in turn, cost banks and insurance companies, if not merchants themselves, billions of dollars in losses on an annual basis.

In view of at least the aforementioned issues, an efficient system and method for verifying and authenticating a user's identity is desirable.

SUMMARY

The present invention relates to a system and method to authenticate and verify a user. In accordance with at least one embodiment of the present invention, the method includes receiving, at a processor, a unique identification number (UIN) and finger vein data corresponding to a user; comparing, via the processor, the received UIN to a database comprising stored user profiles, the user profiles comprising stored UINs with corresponding stored finger vein data; identifying, via the processor, one or more user profiles based on the UIN; comparing, via the processor, the received finger vein data to the stored finger vein data of the determined one or more user profiles; and authenticating the user based on the comparing.

DETAILED DESCRIPTION

The following description is not to be taken in a limiting sense but is given solely for the purpose of describing the broad principles of the invention. Embodiments of the invention will be described by way of example, with reference to the above-mentioned drawings showing elements and results according to the present invention.

The techniques presented herein utilize finger vein technology and unique identification number (UIN) assignments to authenticate and verify a user/customer's identity during an electronic payment transaction. Thus, the systems and methods presented herein help secure transactions between customer(s) and merchant(s). These secure transactions can prevent fraud and can save financial institutions billions of dollars.

Put another way, the techniques presented herein associate two unique pieces of information with a user (the UIN and the user's finger vein pattern) to create a two-factor authentication during electronic payments. However, to ensure that the two-factor authentication does not cause undesirable processing delays at the point-of-sale (POS), the techniques streamline the backend processing of both pieces of information. That is, the UINs are assigned and/or distributed to users in a manner that improves processing of biometric information. Thus, secure and authenticated payments may be processed in nearly the same amount of time as traditional card payments (e.g., via chip insertion, swiping, or tapping) and avoid disrupting the flow of business at a POS, all while providing identity authentication and verification.

More specifically, the techniques presented herein may utilize the UIN to limit the number of stored vein patterns processed (e.g., analyzed) during a given transaction. By comparison, typically, the amount of time to carry out a comparison is highly impacted by, if not governed by, the amount of stored data to which received images or image data must be compared. For example, if a received image must be matched to one imaged stored within a collection of hundreds or thousands (if not more) stored images to authenticate a user, conventional techniques may compare the received image to each image in the collection until a match is found. This uses considerable processing power, occupying a substantial amount of a processor's computing resources. Moreover, as the size of the collection grows, the processing time will grow in-step. Consequently, for large and/or growing collections, authenticating a user based on a received image may take a considerable amount of time and computing resources. Advantageously, by using a UIN in combination with a vein pattern, this processing improvement may be realized naturally and/or automatically.

The authentication and verification method and system is described with use of authorizing payments for sales or services; however, embodiments are not limited thereto. The authentication and verification method and system may be applied to any situation where authentication and verification of a user's identity is desirable. For example, the system and method described herein may be applied to security systems for authorizing a user for access to a computer terminal, a network, a cloud-based database, a cloud-based document, a website, a building, a room, a closet, a storage device, online payments, Automatic Teller Machines (ATMs), bank transactions (in person and/or online), etc.

Now referring toFIG. 1for a description of an authentication system100and a one-time online account registration process10expected of the customer when intending to use the authentication system100for the purpose of paying for any sales or services. The authentication system100includes a user device114(e.g., a mobile device101and/or computer102having a graphical user interface with a display) that can connect to one or more servers108over a network107. The one or more servers108include a server application programming interface (API)110for interfacing with third party service providers113(e.g., banks, credit card companies, PayPal, etc.), a matching module111, and a database112. The one or more servers108support an e-wallet115for a user/customer to access during a transaction. For example, the registered user account may operate as an e-wallet115.

The one-time account registration process10can be completed as an online registration with the aid of a downloadable App on the mobile device101or the browser of a computer, desktop, or laptop102. The registration process includes downloading the App or accessing the website via a mobile device101or computer102in operation11, requesting an account in operation12, receiving a membership identification (ID) number and unique identification number (UIN) in operation13, and linking funding accounts in operation14. The one or more servers108receive the account information from the user114and store it in the database112to complete the registration process in operation15.

More specifically, in operation12, the user requests an account via the App or web browser accessed in operation11. For example, the App or web browser causes the user device114(e.g., mobile device101and/or computer102) to communicate with the one or more servers108via the network107, and request initiation of an account registration with user's data (e.g., user's name, date of birth, address, phone number, etc.). When the techniques presented herein are utilized for financial transactions, certain data fields, such as name, date of birth, address, etc., may be required. The user may input the data via a graphical user interface of the user device114.

In operation13, the user obtains a membership ID number and UIN. In some instances, the membership ID and UIN are generated by the one or more servers108and are associated with the received user data. Then, the membership ID number and UIN are transmitted from the one or more servers108to the user device114and are displayed to the user/customer. Alternatively, the user may select their membership and/or UIN. The selection/generation of the UIN is described in further detail below; however, regardless of how the UIN is obtained, in some implementations, the one or more servers108may further transmit instructions to the user device114to request that the user links the account with a third-party service provider113.

More specifically, at operation13, a customer/user can obtain a UIN by being assigned a UIN from the one or more servers108or by selecting their own UIN via the customer device114. In some implementations, the user may select one UIN from a group of UINs generated by the one or more servers108. Alternatively, the user may create their own UIN to be approved and assigned by the one or more servers108. When UINs are assigned, and/or approved, the UINs are assigned to dynamically balance the number of users associated with any particular UIN. This creates a natural filtering or hierarchal system, which enhances the speed at which transactions can be processed with finger vein pattern data. For example, UINs may be assigned based on user/customer phone numbers (e.g., the last four, five, six, or seven digits of a customer's phone number may be their UIN), which may naturally spread UIN amongst unique combinations. Regardless of how dynamic balancing is achieved, when a user completes a transaction with their UIN and scan of their finger vein pattern, the backend processing will only need to match a scanned finger vein pattern against a small portion of finger vein patterns registered with the system.

Additionally or alternatively, UINs may be associated with thresholds (fixed or dynamic) to ensure that particular UINs are associated with a limited number of UINs. Dynamic thresholds, if used, may vary based on the number of UINs in the system, the number of users in the system, the number of characters in the UIN, or any combination thereof. For example, in one embodiment, as many as 1000 registrations may be associated with each six-digit UIN. The UINs may be all numbers, alphabetic characters, or a combination thereof.

In operation14, the user links one or more accounts from one or more third party service providers113to the account. The service providers113may include one or more of a bank, a credit card company, PayPal (or another online payment system), and/or other financial institution. For example, the user may enter third party account information and/or login credentials for the one or more third party service provider113into the user device114, which may transmit the information to the one or more servers108.

In operation15, the one or more servers108store the user's data. The one or more servers108receive the user's data and third-party account information, and generate a user profile comprising the user's data, membership ID number, UIN, and third-party service provider account information. The user profile is stored in the database112and indexed by the corresponding membership ID number and/or UIN. Once the user profile is stored in the database112, the account registration process10is complete.

FIG. 2illustrates a finger vein reading system200and a one-time finger vein pattern registration process20for registering any one finger of the customer with their stored profile to be used for the verification and/or authentication of payment at a Point-of-Sale (POS). The customer need only register one finger, but can register any number of fingers (e.g., up to ten) and the finger vein pattern of each registered finger will be associated with the user's account. Regardless, the user/customer must interact with a finger vein pattern reader201to complete this registration.

In the depicted embodiment, the finger vein registration system200includes a merchant device207(e.g., the finger vein reader201, a mobile device, and/or a computer), the network107, and the one or more servers108. However, finger vein registration system200need not always include a merchant device207. That said, the finger vein pattern reader201includes a sensor for detecting a finger vein pattern, and a processor. In some implementations, the vein pattern reader201may be configured to communicate with the one or more servers108over the network107. Additionally, or alternatively, the vein pattern reader201may communicate with a computer (e.g., a mobile device101, a computer102) which in turn communicates with the one or more servers108over the network107.

The finger vein pattern registration process20includes receiving a user's membership ID number and UIN at the finger vein pattern reader201in operation21, confirming a user's identity with a one-time password (OTP) in operation22, scanning one or more finger vein patterns of the user in response to confirming the user's identity in operation23, and transmitting the membership ID number, the UIN, and the scanned finger vein pattern to the one or more servers108. In response to receiving the one or more finger vein patterns, membership ID number, and UIN, the one or more servers108store the one or more finger vein patterns with the profile associated with the membership ID number and UIN in operation25. Once the profile is updated with the one or more finger vein pattern and stored in the database, the finger vein registration process20is completed.

In operation21, the finger vein reader201initiates the process20by prompting the user/customer for the user's membership ID number and UIN. The finger vein reader201receives from the user the membership ID number and UIN, then transmits them to the one or more servers108. In response, the one or more servers108generates a one-time password (OTP) corresponding to the membership ID number and UIN, and transmits the OTP to the user device114via an email, a text message, or another secure message (e.g., a push notification pushed by an app installed on the user device114). Additionally or alternatively, the one or more servers108may transmit the OTP to the finger vein reader201and/or merchant device207.

In operation22, the user's identity is confirmed with the OTP. In the depicted embodiment, the finger vein reader201receives an input from the user and compares the user's input with the OTP received from the one or more servers108. For example, the user can enter the OTP received on the user device114one the graphical user interface of the finger vein reader201. The finger vein reader201verifies, or confirms, the user's identity if it determines that the OTP entered by the user matches the OTP received from the one or more servers108, and the finger vein registration process20continues to operation23. If the finger vein reader201determines that the user's input and the OTP do not match, the finger vein reader201prompts the user to try again. The user is given a number of tries before the system200locks the user out of her profile, or the finger vein registration process20starts over at operation21. However, again, the depicted embodiment is merely an example and in at least some implementations, the finger vein reader201can confirm an identity based on the OTP by communicating with the one or more servers108or any other remote computing resources (which may analyze the OTP and confirm the user's identity).

In operation23, the finger vein reader201scans one or more of the user's fingers for one or more finger vein patterns that are unique to the user. For example, in response to verifying the user's identity, the finger vein reader201can prompt the user to place a finger to be scanned over the sensor of the finger vein reader201. Upon detecting the user's finger is in place, the finger vein reader201activates the sensor and scans the user's finger vein pattern. In some implementations, operation23may be repeated for each finger the user would like to scan prior to any subsequent operations. Alternatively, some implementations may process one finger scan at a time and subsequent finger scans may be recorded by repeating finger vein pattern registration process20in its entirety. Either way, in some implementations, the user may not scan just her own finger, but also the finger of another person whom the user wants to have authorized access to the user's account (e.g., a family member). The finger vein reader201may further notify the user of success or failure to scan a finger vein pattern, and prompt the user to rescan the desired finger if the scan failed. After the finger vein reader201scans the desired one or more fingers, the process20continues to operation24.

In operation24, the finger vein reader201transmits finger vein data (e.g., one or more scanned finger vein patterns), the membership ID number, and the UIN to the one or more servers108. In some implementations, the finger vein reader201may further transmit the OTP received from the user to the one or more servers108to confirm the user's identity.

In operation25, the one or more servers108receive and store the received one or more finger vein patterns in the database112. For example, the matching module111may compare the received Membership ID number, and received UIN with a stored membership ID number and stored UIN associated the user's profile. In some implementations, matching module may further compare the received OTP with a stored OTP associated with the user's profile to verify the user. The database112stores the finger vein data comprising one or more received finger vein patterns in the user's profile corresponding to the matched membership ID and UIN. Upon storing the one or more received finger vein patterns in the user's profile, the finger vein pattern registration process20is complete. Alternatively, if the received OTP, received Membership ID number, and/or received UIN do not match the stored OTP, the stored membership ID number and/or the stored UIN associated with the user, the one or more servers108rejects the received finger vein data and transmits an error notice to the finger vein reader201. The finger vein registration process may start over at operation21or may be terminated.

Still referring toFIG. 2, as mentioned, the finger vein reader device201shown inFIG. 2is merely an example. In some implementations, a processor (e.g., mobile device or computer) may be communicatively coupled to the finger vein reader201to relay data between the finger vein reader201and the one or more servers108. In some instances, user registration with the system (e.g., perFIG. 2) could trigger shipment of a finger vein reader to the customer for temporary use (e.g., sent with a return label). Alternatively, the registering customer could use the finger vein reader at a participating merchant, or any other available device capable of scanning finger veins and communicating the captured data to another device (e.g., via BLUETOOTH, USB, Wifi, NFC) and/or the Internet. Regardless, once a device connected to the system presented herein receives finger vein data, the device can execute instructions stored in computer readable memory to complete a user registration (e.g., to associate the finger vein pattern with the user and a UIN of the user).

FIG. 3illustrates an authentication process30for authenticating a user with the user's UIN and scanning a user's finger with the finger vein reading system200. The authentication process30verifies and authenticates the user's details in order to authorize a user. For example, the authentication process30may include authorization of payment for transactions between an authenticated customer and a merchant while at the merchant's location to pay for any goods and services. In some implementations, the authentication process30may include authorizing the user to access a restricted area, building, terminal, computer, website, complete online payment and banking transactions (e.g., via ATMs or over the counter transactions), etc.

The authentication process30includes receiving a customer UIN in operation31, scanning a finger vein pattern in operation32, and transmitting the UIN and scanned finger vein pattern to the one or more servers108in operation33. The one or more servers108compare the UIN and finger vein pattern to stored profiles in the database112to authenticate the customer and authorize a transaction in operation34.

In operation31, the finger vein reader201receives a UIN of a user to be authenticated. For example, the user can enter her previously assigned UIN at the finger vein reader201. As mentioned, the UIN is previously assigned to the user during the online registration process10(discussed above with reference toFIG. 1). Once the UIN is entered, the finger vein reader201prompts the user to place her finger to be scanned on the reader's sensor, at operation32. Alternatively, the UIN could be entered after a finger is scanned or simultaneously (e.g., if a merchant enters a UIN received from the customer (e.g., verbally) while the customer scans their finger). That is, operations31and32need not be performed in the depicted order.

Notably, although operation31indicates that a user enters their UIN, the user could also tell the merchant their UID (e.g., verbally) who could then input the UIN on their behalf. Alternatively, a user device could transmit the UID to a merchant device (e.g., in response to user verification at the user device, such as via fingerprint verification, face scanning verification, code verification, etc.). In some implementations, the authentication process30may be initiated by a transaction between a merchant and a customer. For example, the user may be the customer attempting to purchase goods or services from the merchant. The merchant may initiate the authentication process30by entering the transaction in a POS device communicatively coupled to the finger vein reader201. In some implementations, the user may scan her finger with the finger vein reader201to initiate the authentication process30, and then enter her UIN.

In operation33, the finger vein reader201transmits the scanned finger vein pattern and the UIN to the one or more servers108for authentication. For example, the finger vein reader201may transmit data representative of the scanned finger vein pattern and the UIN to the one or more servers108via the network107. In some implementations, the data is transmitted as a data packet. The data packet comprises a one or more frames having a plurality of subframes. For example, the frame may include a header subframe and a payload subframe. The header subframe may contain the UIN and the payload subframe may include the finger vein pattern data (e.g., the scanned finger vein pattern).

Additionally, in some implementations, the data sent to the servers (e.g., from the finger vein reader201) may be time stamped. The time stamp may provide an additional layer of fraud protection. For example, the time stamp of the transmitted data from the finger vein reader may be compared to a particular time stamp applied by the one or more servers108or a timer maintained by the one or more servers108when the data is received. If the elapsed time (e.g., as measured by the difference or delta between two timestamps) exceeds a threshold, the data may be discarded (i.e., not considered) and/or flagged. As a specific example, the threshold could be approximately three seconds so that transactions associated with a timestamp delta greater than three seconds are denied while transactions associated with a timestamp delta less than three seconds may be approved (assuming the finger vein data and UIN also authorizes a transaction).

In operation34, the one or more servers108receive the data from the finger vein reader201and authenticate the user. Specifically, the one or more servers108extracts the UIN and finger vein pattern from the received data. The matching module111of the one or more servers108compares the received UIN to stored UINs corresponding to profiles in the database112. The matching module111selects one or more stored profiles with UINs that match the received UIN. The matching module111then compares the received finger vein pattern with stored finger vein patterns from the one or more selected profiles. The matching module111selects a stored profile (of the one or more selected profiles) having a stored finger vein pattern that matches the received finger vein pattern.

Said another way, the matching module111filters (i.e., removes from consideration) stored profiles with UINs that do not match the received UIN. The matching module111then compares the received finger vein pattern with one or more stored finger vein patterns from one or more remaining profiles in the database112. That is, the matching module compares the received finger vein pattern to each finger vein pattern corresponding to each of the one or more remaining profiles. Thus, the user's identity is authenticated by verifying the received UIN and the received finger vein pattern from the user matches the stored UIN and stored finger vein pattern corresponding to the user's profile. In other words, the one or more servers108verify that the selected profile belongs to the user in response to the matching module111matching the received finger vein pattern to the stored finger vein pattern associated with the selected profile.

Once the one or more servers108authenticate the user, the one or more servers108may authorize a transaction. For example, the one or more servers108can authorize a payment from a financial account corresponding to the authenticated user/customer's profile (e.g., e-wallet115) to a merchant's financial account. Additionally or alternatively, the one or more servers may authorize access to an area, room, building, terminal, network, document and/or allow a customer to complete banking transactions (e.g., online and/or via ATMs), etc., to which the user's profile indicates the user has access authority. For example, the finger vein reader201may be communicatively coupled to and capable of unlocking a door/gate lock, a terminal, or a computer in response to the user being authenticated by the one or more servers108.

Still referring toFIG. 3, to be clear, the finger vein reader device201included inFIG. 3is merely an example and the techniques presented herein need not utilize a finger vein reader device201for an in-person transaction. Additionally or alternatively, the techniques presented herein can facilitate online transactions, ATM transactions, access to a particular location (e.g., a building), etc. In these use cases, device201, a portable scanner, and/or any device capable of capturing a finger vein pattern can execute at least a portion of the techniques presented herein. For example, a portable scanner may include hardware and software to allow direct communications with the one or more servers108and/or may communicate with another electronic device (e.g., via BLUETOOTH, USB, Wifi, NFC), which may act as an intermediary. Regardless, once a device connected to the system presented herein receives finger vein data, the device can execute instructions stored in computer readable memory to complete, or at least attempt to complete at least a portion of a transaction based on UIN and finger vein data (and potentially a time stamp too).

FIG. 4illustrates the one-time merchant registration process40on an online platform400by using the downloadable App on a mobile device401or browser on a mobile device401or desktop or laptop402. This registration process40allows the merchant to set up an account that will be used for the collections of revenue from transaction with customers when paying for services or goods. The account is also used in adding devices (e.g., finger vein reader201) to the account, as desired.

The one-time merchant registration process40includes downloading an App or accessing a website via a merchant device207(e.g., the mobile device401or the computer402) in operation41, requesting an account in operation42, receiving a merchant identification (ID) number in operation43, confirming the merchant's identity with a one-time password (OTP) in operation44, and linking third party service providers413(e.g., financial institution account, bank account, credit card account, PayPal, etc.) in operation45. The one or more servers108receive the account information from the merchant device207and store it in a merchant account/profile in the database112to complete the registration process in operation46.

In operation42, the merchant requests an account via the App or web browser accessed in operation41. For example, the App or web browser causes the merchant device207(e.g., mobile device401and/or computer402) to communicate with the one or more servers108via the network107, and request initiation of a merchant account registration with merchant's data (e.g., merchant's name, date of birth, business name, business address, phone number, etc.). The merchant may input the data via a graphical user interface of the merchant device207.

In operation43, the one or more servers108generate a membership ID number associated with the received merchant data. The membership ID number is transmitted from the one or more servers108to the merchant device207and is displayed to the merchant. In some implementations, the one or more servers108may further transmit instructions to the merchant device207to prompt the merchant to link the merchant account with a third party service provider413. At operation44, a merchant can confirm their identity with an OTP. Additionally or alternatively, merchant finger vein data (e.g., of a person authorized to act on behalf of the merchant) could be used to confirm the merchant identity at operation44(e.g., based on similar steps to operations31-34).

In operation45, the merchant links one or more accounts from third party service providers413to the merchant account. The service providers413may include one or more of a bank, a credit card company, PayPal, and/or other financial institutions. For example, the merchant may enter third party account information and/or login credentials for the one or more third party service provides413into the merchant device207, which transmits the information to the one or more servers108.

In operation46, the one or more servers108store the merchant's data in a database112. The one or more servers108receive the merchant's data and third-party account information, and generate a merchant profile/account comprising the merchant's data, membership ID number, and third party account information. The merchant profile is stored in the database112and indexed by the corresponding membership ID number. Once the merchant profile is stored in the database112, the account registration is complete and the merchant can conduct transactions with users/customers who have a user account stored in the database112. For example, the merchant may scan a user's finger vein pattern to register the patterns with the user's profile (however, this might also be possible prior to completing merchant registration process40). Additionally, the merchant may scan a user's finger vein pattern for authorization of payment for a transaction from the user's account to the merchant's account.

FIGS. 5A-5Care flow charts of processes that illustrate the one-time customer registration process, including the online sign up for a customer account and the one-time finger vein pattern registration, as detailed above with reference toFIGS. 1 and 2. Specifically,FIG. 5Aillustrates a registration process500occurring at the user device114,FIG. 5Billustrates a registration process510occurring at the merchant device207, andFIG. 5Cillustrates the registration process520occurring at the one or more servers108.

Referring toFIG. 5A, the customer registration process500includes downloading an App or browsing a website in operation501, receiving a sign up request from a in operation502, receiving a customer membership ID number and a UIN in operation503, and receiving customer funding accounts and transmitting the funding accounts to the one or more servers108in operation504.

For example, at502, the customer can enter personal information in the downloaded App or web browser on the customer device114to request the customer account. The customer device114can then transmit the information to the one or more servers for generating the customer's account. In operation503, the user device114receives and displays a membership ID number and UIN associated with the customer's information (in accordance with the details provided above). The customer device114may further prompt the customer to link a funding account to the customer profile/account and receive funding account information. In response, the user may input funding account information into the customer device114. The customer device114can then transmit the funding account information with the membership ID number and UIN to the one or more servers108. The customer device114may receive a confirmation from the one or more servers108that the customer account registration is complete.

Now referring toFIG. 5B, a registration process510for registering a customer's finger vein pattern at a merchant device207includes receiving a customer membership ID number and UIN in operation511, receiving and verifying a customer OTP in operation512, scanning one or more finger vein patterns of a customer in operation513, and transmitting the membership ID number, UIN and the finger vein pattern data to the one or more servers108. Details of these operations are discussed above.

Referring toFIG. 5C, a registration process520for registering a customer's account and finger vein pattern data at one or more servers108. The registration process520includes receiving a sign up or registration request in operation521, generating and transmitting a membership ID number and UIN in operation522, and receiving third party account information and generating a customer profile in operation523. The customer profile includes the customer's account information, membership ID number, UIN, and third party account information.

In operation525, the one or more servers108generate an OTP in response to receiving a request to register a finger vein pattern, a membership ID number, and a UIN. The generated OTP is transmitted to the customer device114corresponding to the membership ID number and UIN. For example, the OTP may be transmitted to a mobile device101or an email address associated with the membership ID number. In operation526, the one or more servers receive finger vein pattern data containing one or more finger vein patterns, the customer's membership ID number, UIN, and OTP. The one or more servers108verify that the received OTP, membership ID number, and UIN match the transmitted OTP associated with the stored membership ID number and UIN. If the OTPs match, the one or more servers108update the customer profile corresponding to the received membership ID number and UIN with the received finger vein pattern data in operation527. The updated customer profile is saved in database112for future authentication of the customer. If the OTPs do not match, an error message may be transmitted and/or the process520may restart.

FIGS. 6A and 6Bare flow charts of processes that illustrate the one-time merchant registration process, including the online sign up for a merchant account and adding of devices to the account, as detailed above with reference toFIG. 4.FIG. 6Aillustrates a merchant registration process600occurring at the merchant device207andFIG. 6Billustrates the merchant registration process610occurring at the one or more servers108.

Referring toFIG. 6A, the merchant device207is started in operation601; the merchant device downloads an App or accesses a website in operation602. In operation603, the merchant signs up for a merchant account (as detailed above). The merchant device receives merchant data (e.g., business name, merchant first and last name, email address, business address, phone number, etc.) from the merchant. The merchant device transmits the received merchant information to the one or more servers108. In operation604, the merchant device receives a membership ID number from the one or more servers108and displays the membership ID number to the merchant.

In operation605, the merchant device207receives an OTP inputted by the merchant. The merchant may have received the OTP via email or a message to a mobile device401associated with the merchant. The merchant device207transmits the OTP and membership ID number to the one or more servers108for authorization. The merchant device207receives a merchant confirms authorization if the one or more servers108transmits a confirmation that the OTP and the membership ID number match. If the OTP and the membership ID number do not match, the merchant device207receives and displays an error message to the merchant. The merchant device207may prompt the merchant to reenter the OTP and/or start the process600over. In operation606, in response to authorization of the merchant, the merchant device207prompts the merchant to link a bank account or other financial institution account. The merchant device207receives the financial account information from the merchant and transmits it to the one or more servers108. Once the merchant's bank account is linked to the merchant account, the process600is complete.

Now referring toFIG. 6B, at the one or more servers108, the merchant registration process610includes receiving merchant data (e.g., business name, merchant first and last name, email address, business address, phone number, etc.) in operation611and, in response, generating a merchant account in operation612. In operation613, the one or more servers108generate an OTP associated with the generated merchant account and transmit the OTP to the merchant (e.g., via email, mobile device401, or merchant device207). In operation614, the one or more servers108receive an OTP from the merchant device207and compare the received OTP to the generated OTP. If the OTPs match, the one or more servers108transmit an authorization message to the merchant device207in operation615. If the OTPs do not match, an authentication failure message is transmitted to the merchant device207and the process may return to operation613or operation614. In operation616, the one or more servers108receive merchant financial data in response to authenticating the merchant, and update the merchant account with the financial data in operation617. The merchant registration process610concludes after operation617.

FIGS. 7A and 7Billustrate a complete transaction process from when a merchant inputs the cost of the service or goods (e.g., via barcode scanning) to when the customer and/or merchant input the Unique Identification Number (UIN) and the customer scans a registered finger (as detailed above with reference toFIG. 3). The device will then send the UIN and scanned finger vein data to the server for matching possibilities before authorization.FIG. 7Aillustrates a transaction process700occurring at the merchant device207, andFIG. 7Billustrates an authentication of a transaction process710occurring at one or more servers108.

Now referring toFIG. 7A, in operation701, the merchant device207receives a sale amount for a transaction and, in operation702, the merchant device207receives a UIN. For example, the customer may enter the UIN into the merchant device207. In operation703, the merchant device207prompts the customer to place their finger on a finger vein pattern reader and scans the customer's finger vein pattern. In operation704, the merchant device207transmits the UIN and finger vein pattern data to the one or more servers108. As mentioned above, this transmission may also include a time stamp. In operation708, the merchant device207receives and displays the transaction result. For example, the merchant device207may receive confirmation that the transaction has been authorized and completed. Alternatively, the merchant device207may receive a notice that the transaction has been declined. In some implementations, the process may restart at operation702if the transaction is declined. The transaction process700concludes after operation705.

Now referring toFIG. 7B, the transaction process710includes receiving a customer UIN, finger vein pattern data, and a transaction sale amount at one or more servers108. In operation712, the one or more servers108match the received UIN to one or more stored profiles. For example, the matching module111of the one or more servers108compares the received UIN to the database112containing user/customer profiles, and selects one or more customer profile with associated UINs that matches the received UIN. In operation713, the one or more servers compare the received finger vein pattern data with one or more finger vein patterns stored in the selected one or more profiles. For example, the matching module111of the one or more servers108compares the received finger vein pattern data (e.g., a scanned image of a finger vein pattern) with finger vein patterns stored in the one or more selected profiles until a match is found.

In response to finding a profile with a stored finger vein pattern matching the received finger vein pattern, the one or more servers108authorize a transaction on a customer account corresponding to the matched profile in operation714. Thus, the one or more servers108authenticate the customer based on the received UIN and finger vein pattern. In operation715, the one or more servers108transmit an authorization to the customer's financial institution and/or the merchant's financial institution for transfer of funds. Additionally, in operation716, the one or more servers108transmit a confirmation to the customer and merchant. After operation716, the authorization process710is completed.

Alternatively, at operation712and/or operation713, if a matching UIN or finger vein pattern is not matched or found in the database112, the one or more servers108denies the transaction in operation717. That is, the customer's identity is not authenticated and the transaction is not authorized. In operation718the one or more servers transmits a decline message to the merchant and/or the customer.

Notably, at713, the finger vein data received from704(e.g., scanned at the merchant POS device) need only be matched against finger vein data associated with the particular UIN. The UIN is not necessarily unique to the customer, but limits the amount of data that will be compared to the received finger vein data, thereby drastically reducing the amount of backend processing required to complete a transaction. Put another way, the particular manner in which the techniques presented herein combine UINs and finger vein data drastically improves the speed of biometric transactions while securing and authenticating transactions. Further, the techniques presented herein may be used with verifying and authenticating a user for access to a secured location, as noted above.

Referring toFIG. 8,FIG. 8illustrates a hardware block diagram of a computing device800that may perform functions associated with operations discussed herein in connection with the techniques depicted inFIGS. 1-7B. In various embodiments, a computing device, such as computing device800or any combination of computing devices800, may be configured as any entity/entities as discussed for the techniques depicted in connection withFIGS. 1-7Bin order to perform operations of the various techniques discussed herein.

In at least one embodiment, the computing device800may include one or more processor(s)802, one or more memory element(s)804, storage806, a bus808, one or more network processor unit(s)810interconnected with one or more network input/output (I/O) interface(s)812, one or more I/O interface(s)814, and control logic820. In various embodiments, instructions associated with logic for computing device800can overlap in any manner and are not limited to the specific allocation of instructions and/or operations described herein.

In at least one embodiment, processor(s)802is/are at least one hardware processor configured to execute various tasks, operations and/or functions for computing device800as described herein according to software and/or instructions configured for computing device800. Processor(s)802(e.g., a hardware processor) can execute any type of instructions associated with data to achieve the operations detailed herein. In one example, processor(s)802can transform an element or an article (e.g., data, information) from one state or thing to another state or thing. Any of potential processing elements, microprocessors, digital signal processor, baseband signal processor, modem, PHY, controllers, systems, managers, logic, and/or machines described herein can be construed as being encompassed within the broad term ‘processor’.

In at least one embodiment, memory element(s)804and/or storage806is/are configured to store data, information, software, and/or instructions associated with computing device800, and/or logic configured for memory element(s)804and/or storage806. For example, any logic described herein (e.g., control logic820) can, in various embodiments, be stored for computing device800using any combination of memory element(s)804and/or storage806. Note that in some embodiments, storage806can be consolidated with memory element(s)804(or vice versa), or can overlap/exist in any other suitable manner.

In at least one embodiment, bus808can be configured as an interface that enables one or more elements of computing device800to communicate in order to exchange information and/or data. Bus808can be implemented with any architecture designed for passing control, data and/or information between processors, memory elements/storage, peripheral devices, and/or any other hardware and/or software components that may be configured for computing device800. In at least one embodiment, bus808may be implemented as a fast kernel-hosted interconnect, potentially using shared memory between processes (e.g., logic), which can enable efficient communication paths between the processes.

In various embodiments, network processor unit(s)810may enable communication between computing device800and other systems, entities, etc., via network I/O interface(s)812(wired and/or wireless) to facilitate operations discussed for various embodiments described herein. In various embodiments, network processor unit(s)810can be configured as a combination of hardware and/or software, such as one or more Ethernet driver(s) and/or controller(s) or interface cards, Fibre Channel (e.g., optical) driver(s) and/or controller(s), wireless receivers/transmitters/transceivers, baseband processor(s)/modem(s), and/or other similar network interface driver(s) and/or controller(s) now known or hereafter developed to enable communications between computing device800and other systems, entities, etc. to facilitate operations for various embodiments described herein. In various embodiments, network I/O interface(s)812can be configured as one or more Bluetooth, USB port(s), NFC port(s) Ethernet port(s), Fibre Channel ports, any other I/O port(s), and/or antenna(s)/antenna array(s) now known or hereafter developed. Thus, the network processor unit(s)810and/or network I/O interface(s)812may include suitable interfaces for receiving, transmitting, and/or otherwise communicating data and/or information in a network environment.

Variations and Implementations

Networks through which communications propagate can use any suitable technologies for communications including wireless communications (e.g., 2G/3G/4G/5G/nG, CDMA, IEEE 802.11 (e.g., Wi-Fi®/Wi-Fi6®), IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), Radio-Frequency Identification (RFID), Near Field Communication (NFC), Bluetooth™, mm.wave, Ultra-Wideband (UWB), etc.), and/or wired communications (e.g., T1lines, T3lines, digital subscriber lines (DSL), Ethernet, Fibre Channel, etc.). Generally, any suitable means of communications may be used such as electric, sound, light, infrared, and/or radio to facilitate communications through one or more networks in accordance with embodiments herein. Communications, interactions, operations, etc. as discussed for various embodiments described herein may be performed among entities that may directly or indirectly connected utilizing any algorithms, communication protocols, interfaces, etc. (proprietary and/or non-proprietary) that allow for the exchange of data and/or information.

Finally, when used herein, the term “comprises” and its derivations (such as “comprising”, etc.) should not be understood in an excluding sense, that is, these terms should not be interpreted as excluding the possibility that what is described and defined may include further elements, steps, etc. Meanwhile, when used herein, the term “approximately” and terms of its family (such as “approximate”, etc.) should be understood as indicating values very near to those which accompany the aforementioned term. That is to say, a deviation within reasonable limits from an exact value should be accepted, because a skilled person in the art will understand that such a deviation from the values indicated is inevitable due to measurement inaccuracies, etc. The same applies to the terms “about” and “around” and “substantially”.