Method, systems and computer-readable medium for name verification

The 3-D Secure protocol is used for efficient name verification, addressing cumbersome verification processes by integrating with existing transaction systems, reducing resource usage and network load.

GB2640866APending Publication Date: 2025-11-12MASTERCARD INT INC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
GB2024006345
Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-05-07
Publication Date
2025-11-12

AI Technical Summary

Technical Problem

Existing name verification processes are cumbersome, requiring separate infrastructure and registration processes, leading to increased memory and processor usage and network loading.

Method used

Utilizing the existing 3-D Secure (3DS) protocol for name verification, leveraging existing connections between merchants and card issuers, eliminating the need for separate name registration and infrastructure, and integrating name verification with transaction processes.

Benefits of technology

Reduces memory and processor usage and network loading by leveraging existing 3DS connections for efficient name verification without additional setup, ensuring seamless integration with transaction processes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

Computer implemented method for performing name verification. A 3-D secure (3DS) request message requesting verification of a name in relation to an account is received S302 from a requestor. The request message indicates the account and name information for verification. A determination is made about the extent to which the name information corresponds to a name associated with the account S304. Based on the determination, a 3DS response message is sent S306 to the requestor. Other embodiments include a corresponding method for sending a 3DS request for verification of a name, an alternative method for requesting verification of a name and use of a 3DS secure protocol for name verification. Optionally, the 3DS response message indicates that the name associated with the account is the same as, a partial match for, or does not match the name information for verification. The 3DS request message may include a request for a transaction on the account.
Need to check novelty before this filing date? Find Prior Art

Description

There are many situations that require verification of the name of an individual. For example, the name of a user or customer may need to be validated or the name associated with a payment instrument (such as a card) may need to be checked. Additionally or alternatively, there may be a legal requirement during certain payments, or non-payment use cases, to check if the name of a user / payee is equal to the supposed name of the user of the service - for example when an online gambling portal is being used. The sending of a picture copy of an identity document or card is a cumbersome solution and third party services can require onerous pre-registration and / or require significant processing in order to perform name verification. SUMMARY This summary introduces concepts that are described in more detail in the detailed description. It should not be used to identify essential features of the claimed subject matter, nor to limit the scope of the claimed subject matter. According to a first aspect, there is provided a computer-implemented method comprising: receiving, from a requestor, a 3-D secure (3DS) request message requesting verification of a name in relation to an account, the 3DS request message indicating the account and name information for verification; determining an extent to which the name information for verification corresponds to a name associated with the account; and based on the determining, sending a 3DS response message to the requestor. The 3DS response message may indicate that the name information for verification is the same as the name associated with the account. The 3DS response message may indicates that the name information for verification partially matches the name associated with the account. The 3DS response message may indicate that the name information for verification does not match the name associated with the account. The 3DS request message may include a request for a transaction on the account. The method may further comprise: receiving from the requestor a request for Strong Customer Authentication (SCA) of the transaction; initiating the requested SCA; and based on the determining, sending an SCA response message to the requestor that is indicative of the results of the requested SCA. According to a further aspect, there is provided a computer-implemented method comprising: sending, to a verifier, a 3-D secure (3DS) request message requesting verification of a name in relation to an account, the request message indicating the account and name information for verification; receiving a 3DS response message indicating an extent to which the name information for verification corresponds to a name associated with the account; and based on the 3DS response message, determining whether the name has been verified. The 3DS response message may indicate that the name information for verification is the same as the name associated with the account. The 3DS response message may indicate that the name information for verification partially matches the name associated with the account. The 3DS response message may indicate that the name information for verification does not match the name associated with the account. The 3DS request message may include a request for a transaction on the account. The method may further comprise: sending to the verifier a request for Strong Customer Authentication (SCA) of the transaction; and receiving from the verifier an SCA response message that is indicative of the results of the requested SCA. According to a further aspect, there is provided a computer-implemented method comprising: receiving, from a requestor, a 3-D secure (3DS) request message requesting verification of a name in relation to an account, the 3DS request message indicating the account and name information for verification; and forwarding the 3DS request message to a verifier for verification. According to a further aspect, there is provided a computer-implemented method comprising: receiving from a verifier a 3DS response message indicating an extent to which name information for verification corresponds to a name associated with an account forwarding the 3DS response message to a requestor. According to a further aspect, there is provided a method comprising: using a 3-D secure protocol for name verification. According to a further aspect, there is provided a computer system comprising one or more processors arranged to perform any of the methods described herein. According to a further aspect, there is provided a computer-readable medium storing instructions that, when executed by one or more processors of one or more computing devices, cause the one or more computing devices to perform any of the methods described herein. BRIEF DESCRIPTION OF THE FIGURES Specific embodiments are described below by way of example only and with reference to the accompanying drawings in which: Figure 1 shows a 3-D Secure system for use in implementing the processes described herein; Figure 2 shows an expanded flowchart of a process for use in verifying the name of a party; Figure 3 shows a flowchart of a process for use in verifying the name of a party; Figure 4 shows a flowchart of a process for use in verifying the name of a party; Figure 5 shows a flowchart of a process for use in verifying the name of a party; Figure 6 shows a flowchart of a process for use in verifying the name of a party; and Figure 7 shows a schematic diagram of a computing device for implementing the methods of the present disclosure. DETAILED DESCRIPTION The inventor has arrived at an insight that the 3-D Secure (3DS) protocol can be used not only for card authentication in the context of transaction authorisation, but also that it can be employed for name verification. The name validation leverages the existing 3DS connections between merchants and card issuers and so no new infrastructure or connections need to be set up in order to provide this service and instead the existing 3DS rails can be utilized. As name information is determinable from account information, the new approach avoids any need to separately store name information or to perform any separate name registration process. Furthermore, this insight enables name verification to be easily performed alongside account transactions without the need for burdensome separate processes for name verification. The approaches described herein thus enable reduced memory and processor usage and also reduce network loading. Figure 1 shows a system lOOthat can be employed for implementingthemethods / processes described herein. A merchant device 110 (such as a processor of internet payments - such as may be associated with an online gambling offering) is provided. The user device 110 may comprise a 3DS server (not shown) or may be communicatively coupled to a 3DS server. The merchant device may also be described as a requestor or requestor device. The merchant device 110 is arranged to communicate with an access control server 114 (ACS) - which may also be known as a verifier or verifier device - by way of one or more communication protocols (such as, but not limited to: 3G, 4G, 5G, WiFi, Bluetooth, NFC, HTML) using 3DS messages. Some or all of that communication may be wireless communication. The communication may be direct or indirect - as may occur if communication is via an intermediary such as a directory server 112. Figure 2 shows an expanded flowchart of a process for use in verifying the name of a party. At step S202, a determination that a merchant device 110 (requestor) should check the name of a cardholder is made. At step S204, a 3DS server (which may form part of the merchant device 110) creates and sends a 3DS request message. The 3DS request message indicates an account associated with a card of the card holder, a name given by the cardholder (name information for verification) and that name verification is required - the latter two of which may be indicated by way of a message extension. As an example, that may be achieved by including in the 3DS request message / message extension a name verification flag, a completed name field and / or a completed account number field. The 3DS request message may also include a request for a transaction on the account. At steps S206 and S208, directory server 112 receives the 3DS request message and sends it to access control server (ACS) 114. At S208, the directory server 112 may also validate any message extension and / or perform authentication processing of any request for a transaction on the account that is contained in the 3DS. At step S210, ACS 114 retrieves, based on the account indicated by the 3DS request message, a name associated with the account (for example from a card issuer and accessed either by real-time communication with the card issuer or from pre-loaded memory) and performs a comparison between the name associated with the account and the name information for verification (as indicated by the 3DS request message) to determine an extent to which the name information for verification corresponds to the name associated with the account. The result of the comparison may be a binary extent - either the name information for verification completely corresponds to the name associated with the account (pass) or it does not (fail). As another possibility, a degree of correspondence may be determined. As one example, four different categories may be defined: A = 100% name identical, B = Last name 100% identical, first name small difference, C = Last name small difference, first name small difference, D = verification failed. A small difference may be defined, for example, by a one or two characters being different. At S210, the ACS 114 may also perform authentication processing of any transaction request contained in the 3DS request message. In the event of a verification fail, the ACS may determine to reject any transaction request contained in the 3DS request message. At step S212, the ACS server 114 sends to the merchant 110 a 3DS response message the content of which is based on the determining of the extent to which the name information for verification corresponds to the name associated with the account. In this manner the 3DS response message indicates the extent to which name information for verification corresponds to a name associated with an account. The indication may be achieved by way of a message extension. As an example, the 3DS message (or message extension) may indicate that one of: the name information for verification is the same as the name associated with the account, the name information for verification partially matches the name associated with the account, the name information for verification does not match the name associated with the account. The 3DS response message may also include a response to any transaction request that was contained in the3DS request message-for example approval or rejection of the transaction request. At step S214, the directory server 112 receives the 3DS response message which is conveyed via the 3DS server (step S216) to the merchant 110. At step S218, the merchant 110 reviews the indication of the extent to which name information for verification corresponds to a name associated with an account and decides whether the request for name verification has passed, failed (step S220), or whether a challenge requiring strong proof is needed (S222, S224). If strong proof is needed, the merchant 110 asks the ACS 114 to perform Strong Customer Authentication (SCA) to confirm that the cardholder with the verified name is in fact present. This may be done, for example, using biometrics. SCA is performed at step S226 and the process then branches at point S228. If the SCA was successful then the merchant 110 is informed of the success S230 and thus has SCA-secured proof that the name is correct. In such situations where a transaction has been requested, the transaction payment may then be actioned. If the SCA fails, then a message indicating the failure is sent to the Merchant at step S232 and the merchant 110 has no proof that the current user is the entitled holder of the card. Figure 3 shows a flowchart of a process 300 for use in verifying the name of a party. At step S302, the ACS 114 receives, from the directory server 112, a 3DS request message requesting verification of a name in relation to an account, the 3DS request message indicating the account and name information for verification. At step S304, the ACS 114 determines the extent to which the name information for verification corresponds to a name associated with the account. At step S306 and based on the determining step S304, the ACS 114 sends, to the merchant 110, a 3DS response message indicating an extent to which name information for verification corresponds to a name associated with an account Figure 4 shows a flowchart of a process 400 for use in verifying the name of a party. At step S402, the merchant 110 sends to the ACS 114 a 3DS request message requesting verification of a name in relation to an account, the request message indicating the account and name information for verification. At step S404, the merchant 110 receives a 3DS response message indicating an extent to which the name information for verification corresponds to a name associated with the account. At step S406 and based on the 3DS response message, the merchant 110 determines whether the name has been verified. Figure 5 shows a flowchart of a process 500 for use in verifying the name of a party as may be performed, for example, at the directory server 112. At step S502, the directory server 112 receives from the merchant 110 a 3DS request message requesting verification of a name in relation to an account, the 3DS request message indicating the account and name information for verification; and at step S504, the directory server 110 forwards the 3DS request message to the ACS for verification. Figure 6 shows a flowchart of a process 600 for use in verifying the name of a party as may be performed, for example, at the directory server 112. At step S602, the directory server 112 receives from the ACS 114 a verifier a 3DS response message indicating an extent to which name information for verification corresponds to a name associated with an account and, at step S604, the directory server 112 forwards the 3DS response message to the merchant 110. Although the above has been described by reference to a merchant 110 communicating with an ACS 114 via a directory server 112, it will be appreciated that there may be further intermediary communications devices that lie communicatively between the merchant 110 and the directory server 112 and / or between the directory server 112 and the ACS 114 - as may occur, for example, when communication occurs across a distributed network - such as the internet. Similarly, whereas in the above the directory server 112 relays the 3DS request to the ACS 1114 and relays the 3DS response to the merchant 110, it may be that the 3DS request and / or response messages are exchanged between the merchant 110 and the ACS 114 without passing via any directory server 112. Figure 7 is a schematic and simplified representation of a computer apparatus 700 which can be used to perform the methods described herein, either alone, in combination with other computer apparatuses or as part of a "cloud" computing arrangement. In particular, the computer apparatus 700 may be configured to perform some or all of the steps of any of methods 300, 400, 500 and / or 600 as described herein. The computer apparatus 700 comprises various data processing resources such as a processor 702 (in particular a hardware processor) coupled to a central bus structure. Also connected to the bus structure are further data processing resources such as memory 704. A display adapter 706 connects a display device 708 to the bus structure. One or more user-input device adapters 710 connect a userinput device 712, such as a keyboard and / or a mouse to the bus structure. One or more communications adapters 714 are also connected to the bus structure to provide connections to other computer systems 700 and other networks. In operation, the processor 702 of computer system 700 executes a computer program comprising computer-executable instructions that may be stored in memory 704. When executed, the computerexecutable instructions may cause the computer system 700 to perform one or more of the methods described herein, such as some or all of any of methods 300, 400, 500 and / or 600 as described herein. The results of the processing performed may be displayed to a user via the display adapter 706 and display device 708. User inputs for controlling the operation of the computer system 700 may be received via the user-input device adapters 710 from the user-input devices 712. It will be apparent that some features of computer system 700 shown in Figure 7 may be absent in certain cases. For example, one or more of the plurality of computer apparatuses 700 may have no need for display adapter 706 or display device 708. This may be the case, for example, for particular server-side computer apparatuses 700 which are used only for their processing capabilities and do not need to display information to users. Similarly, user input device adapter 710 and user input device 712 may not be required. In its simplest form, computer apparatus 700 comprises processor 702 and memory 704. In addition, it will be appreciated that the methods may be implemented by multiple computing apparatuses 700 (e.g. in a distributed computing environment). The described methods may be implemented using computer executable instructions. A computer program product or computer readable medium may comprise or store the computer executable instructions. The computer program product or computer readable medium may comprise a hard disk drive, a flash memory, a read-only memory (ROM), a CD, a DVD, a cache, a random-access memory (RAM) and / or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and / or for caching of the information). A computer program may comprise the computer executable instructions. The computer readable medium may be a tangible or non-transitory computer readable medium. The term "computer readable" encompasses "machine readable". Although the above has been described in relation to a merchant device, directory server, and access control server, the functionality of one or both of those devices may be realised by one or more computer processes which may be distributed across multiple distinct processors which may themselves be located at geographically distant locations - as may occur for example with cloud computing operations. Accordingly, mention herein of any merchant, merchant device, requestor, requestor device, directory server, access control server, verifier, and / or verifier device device refers to any computer implementation thereof having the functionality respectively described herein in relation thereto. The singular terms "a" and "an" should not be taken to mean "one and only one". Rather, they should be taken to mean "at least one" or "one or more" unless stated otherwise. The word "comprising" and its derivatives including "comprises" and "comprise" include each of the stated features, but does not exclude the inclusion of one or more further features. The above implementations have been described by way of example only, and the described implementations are to be considered in all respects only as illustrative and not restrictive. Of the various alternatives described herein, there is disclosed any premutation or combination thereof. It will be appreciated that variations of the described implementations may be made without departing from the scope of the invention. It will also be apparent that there are many variations that have not been described, but that fall within the scope of the appended claims.

Claims

1. A computer-implemented method comprising:receiving, from a requestor, a 3-D secure (3DS) request message requesting verification of a name in relation to an account, the 3DS request message indicating the account and name information for verification;determining an extent to which the name information for verification corresponds to a name associated with the account; andbased on the determining, sending a 3DS response message to the requestor.

2. The method of claim 1, wherein the 3DS response message indicates that the name information for verification is the same as the name associated with the account.

3. The method of claim 1, wherein the 3DS response message indicates that the name information for verification partially matches the name associated with the account.

4. The method of claim 1, wherein the 3DS response message indicates that the name information for verification does not match the name associated with the account.

5. The method of any preceding claim, wherein the 3DS request message includes a request for a transaction on the account.

6. The method of claim 5 as dependent on claim 2 or 3, further comprising:receiving from the requestor a request for Strong Customer Authentication (SCA) of the transaction;initiating the requested SCA; andbased on the determining, sending an SCA response message to the requestor that is indicative of the results of the requested SCA.

7. A computer-implemented method comprising:sending, to a verifier, a 3-D secure (3DS) request message requesting verification of a name in relation to an account, the request message indicating the account and name information for verification;receiving a 3DS response message indicating an extent to which the name information for verification corresponds to a name associated with the account; andbased on the 3DS response message, determining whether the name has beenverified.

8. The method of claim 7, wherein one of:the 3DS response message indicates that the name information for verification is the same as the name associated with the account;the 3DS response message indicates that the name information for verification partially matches the name associated with the account;the 3DS response message indicates that the name information for verification does not match the name associated with the account.

9. The method of claim 7 or 8, wherein the 3DS request message includes a request for a transaction on the account.

10. The method of claim 9, further comprising:sending to the verifier a request for Strong Customer Authentication (SCA) of the transaction; andreceiving from the verifier an SCA response message that is indicative of the results of the requested SCA.

11. A computer-implemented method comprising:receiving, from a requestor, a 3-D secure (3DS) request message requesting verification of a name in relation to an account, the 3DS request message indicating the account and name information for verification; andforwarding the 3DS request message to a verifier for verification.

12. A computer-implemented method comprising:receiving from a verifier a 3DS response message indicating an extent to which name information for verification corresponds to a name associated with an account;forwarding the 3DS response message to a requestor.

13. Use of a 3-D secure protocol for name verification.

14. A computer system comprising one or more processors arranged to perform the method or use of any preceding claim.

15. A computer-readable medium storing instructions that, when executed by one or more processors of one or more computing devices, cause the one or more computing devices to perform the method or use of any of claims 1 to 13.13

Citation Information

Patent Citations

  • Authentication framework extension to verify identification information

    US20110191247A1

  • Systems and methods for authenticating online users with an access control server

    US20190392448A1