System and method for network authentication using device level authentication control

Abstract

A system and method for network authentication with device level authentication control. The method includes receiving a first payment transaction request from a user device. In response to receiving agreement, the method comprises: enabling an authentication mode for the user to perform authentication using a selected authentication mode; and generating a key pair for linking with the enabled authentication mode to further authenticate the user device in one or more other transaction requests. The method further includes generating an enrollment completion message and executing the first payment transaction request upon successful signature using the linked key pair. In this way, the present disclosure may be configured to use device authentication data as part of a network authentication risk check, thereby providing a safer way to complete transactions.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Indian Provisional Patent Application No. 202241072014 filed on December 13, 2022, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to the field of digital transactions and, more particularly, to a system and method for network authentication using device-level authentication control. Background Art

[0004] In recent years, the use of user devices for e-commerce, card-on-file payments, Unified Payments Interface (UPI), and online banking has dramatically increased. In these transactions, users are required to enter a PIN and wait for a one-time password (OTP) to successfully complete the transaction. However, this approach can be time-consuming, as receiving the OTP can be delayed due to network or server issues. To address this issue, regulatory exemptions have emerged, allowing payment networks to authenticate transactions on behalf of issuers or payment networks. These approaches introduce authentication solutions that rely on device integrity and identity as primary factors for authenticating transactions, reducing friction during transactions. Despite the reduced friction and increased scalability achieved by these approaches, risk-averse users remain skeptical of payment processes without secondary authentication and are reluctant to make such payments. This has led to a decrease in the number of users using these network authentication services.

[0005] Furthermore, because transactions in such embodiments may be executed by a payment network, if such servers associated with the payment network fail due to server issues, the payment network may be unable to successfully complete the transaction. Furthermore, if the payment network's security mechanisms or authentication systems are not present, or if the authentication system is non-existent, this may result in unsuccessful authentication of the cardholder initiating the transaction, potentially leading to fraud. Therefore, there is a need for an improved method for network authentication using device-level authentication controls.

[0006] The information disclosed in this Background section of the present disclosure is only for enhancement of understanding of the general background of the present disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art. Summary of the Invention

[0007] The present disclosure can overcome one or more shortcomings of existing systems and provide additional advantages. Additional features and advantages can be achieved through the technology of the present disclosure. Other non-limiting embodiments and aspects of the present disclosure are described in detail herein and are considered part of the present disclosure.

[0008] Thus, improved systems, methods, and computer program products are provided for network authentication utilizing device-level authentication control.

[0009] Disclosed herein is a method for network authentication using device-level authentication control. The method includes receiving, by an authentication system, a first payment transaction request from a user device. The first payment transaction request includes consent to register a user of the user device for authentication based on an authentication mode selected by the user. In addition, in response to receiving the consent, the method includes enabling, by the authentication system, the authentication mode for the user to perform authentication using the selected authentication mode. After successful authentication, the method includes generating, by the authentication system, a key pair for linking with the enabled authentication mode to further authenticate the user device in one or more other transaction requests. In addition, the method includes generating, by the authentication system, a registration completion message, the registration completion message enabling the user device to be authenticated in one or more other transaction requests using the registered authentication mode. Thereafter, the method includes executing, by the authentication system, the first payment transaction request after successfully signing using the linked key pair.

[0010] In addition, the present invention discloses an authentication system for performing network authentication using device-level authentication control. The authentication system includes a processor and a memory communicatively coupled to the processor. The memory stores instructions that, when executed, cause the processor to receive a first payment transaction request from a user device. The first payment transaction request includes a user consenting to register the user device for authentication based on an authentication mode selected by the user. In addition, in response to receiving the consent, the processor is configured to enable the user to perform authentication using the selected authentication mode. In addition, after successful authentication, the processor is configured to generate a registration completion message that enables the user device to be authenticated in one or more other transaction requests using the registered authentication mode. Thereafter, the processor is configured to execute the first payment transaction request after successfully signing using the linked key pair.

[0011] Furthermore, the present disclosure discloses a method for network authentication using device-level authentication control. The method includes receiving, by an authentication system, a second payment transaction request from a user device and receiving, as input, an authentication pattern from the user. Furthermore, the method includes verifying, by the authentication system, user authentication based on a comparison of the input authentication pattern with a pre-registered authentication pattern set by the user. Furthermore, upon successful authentication of the user, the method includes signing, by the authentication system, one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication pattern. Thereafter, the method includes executing, by the authentication system, the second payment transaction request after successfully signing using the linked key pair.

[0012] In addition, the present disclosure discloses an authentication system for performing network-level authentication using device-level authentication control. The authentication system includes a processor and a memory. The memory is communicatively coupled to the processor. The memory stores instructions that, when executed, cause the processor to receive a second payment transaction request from a user device and receive an authentication pattern from the user as input. In addition, the processor is configured to verify user authentication based on a comparison of the input authentication pattern with a pre-registered authentication pattern set by the user. In addition, upon successful authentication of the user, the processor is configured to sign one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication pattern. Thereafter, the processor is configured to execute the second payment transaction request after successfully signing using the linked key pair.

[0013] The foregoing summary is illustrative only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

[0014] Additional non-limiting embodiments or aspects are set forth in the following numbered clauses:

[0015] Clause 1: A method comprising: receiving, by an authentication system, a first payment transaction request from a user device, wherein the first payment transaction request includes consent to register a user of the user device for authentication based on an authentication mode selected by the user; in response to receiving the consent, enabling, by the authentication system, the authentication mode for the user to perform authentication using the selected authentication mode; upon successful authentication, generating, by the authentication system, a key pair for linking with the enabled authentication mode to further authenticate the user device in one or more other transaction requests; generating, by the authentication system, a registration completion message, the registration completion message enabling the user device to be authenticated in one or more other transaction requests using the registered authentication mode; and executing, by the authentication system, the first payment transaction request after successfully signing using the linked key pair.

[0016] Clause 2: The method of clause 1, wherein the enabled authentication mode is one of a first plurality of registered authentication modes enrolled by a user, wherein the first plurality of registered authentication modes are associated with device-level authentication control.

[0017] Clause 3: A method according to clause 1 or 2, wherein the key pair comprises a private key and a public key, wherein the private key is used to sign one or more transactions originating from the user device and is stored in the user device, and wherein the public key is used to verify the signed transactions originating from the user device and is stored in the authentication system.

[0018] Clause 4: A method according to any one of clauses 1 to 3, wherein executing the first payment transaction request includes: determining the device integrity of the user device; accessing the key pair in response to a successful determination of the device integrity of the user device; and authenticating the first payment transaction request to proceed with payment of the first payment transaction request.

[0019] Clause 5: The method of any one of clauses 1 to 4, comprising storing in a database an authentication mode registered by a user, an authentication mode selected by a user, success or failure of device authentication, and a timestamp associated with the success or failure of device authentication.

[0020] Clause 6: A method according to any one of clauses 1 to 5, comprising: determining whether the user device is associated with a device-level authentication control; and in response to determining that the user device is not associated with the device-level authentication control, registering one of a second plurality of authentication modes to authenticate one or more other transaction requests.

[0021] Clause 7: A method comprising: receiving, by an authentication system, a second payment transaction request from a user device and receiving an authentication pattern from the user as input; verifying, by the authentication system, user authentication based on a comparison of the input authentication pattern with a pre-registered authentication pattern set by the user; signing, by the authentication system, one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication pattern upon successful authentication of the user; and executing, by the authentication system, the second payment transaction request after successful signing using the linked key pair.

[0022] Clause 8: The method of clause 7, wherein the key pair is accessed in response to a successful determination of device integrity of the user device.

[0023] Clause 9: A method according to clause 7 or 8, wherein the execution of the second payment transaction request includes: determining the integrity of the user device; and storing user device authentication data in a database, wherein the user device authentication data includes an authentication mode pre-registered by the user, an authentication mode selected by the user, the success or failure of the device authentication, and a timestamp associated with the success or failure of the device authentication.

[0024] Clause 10: The method of any of clauses 7 to 9, wherein to determine the integrity of the user device, the method further comprises determining one or more risks associated with the user device based on user device authentication data stored in a database.

[0025] Clause 11: An authentication system comprising: a processor; a memory communicatively coupled to the processor, wherein the memory stores instructions that, when executed, cause the processor to: receive a first payment transaction request from a user device, wherein the first payment transaction request includes consent to register a user of the user device for authentication based on an authentication mode selected by the user; in response to receiving the consent, enable the authentication mode for the user to perform authentication using the selected authentication mode; upon successful authentication, generate a key pair for linking with the enabled authentication mode to further authenticate the user device in one or more other transaction requests; generate a registration completion message, wherein the registration completion message enables the user device to be authenticated in one or more other transaction requests using the registered authentication mode; and execute the first payment transaction request after successfully signing using the linked key pair.

[0026] Clause 12: The authentication system of clause 11, wherein the enabled authentication mode is one of a first plurality of registered authentication modes enrolled by the user, wherein the first plurality of registered authentication modes are associated with the device-level authentication control.

[0027] Clause 13: An authentication system according to clause 11 or 12, wherein the key pair comprises a private key and a public key, wherein the private key is used to sign one or more transactions originating from the user device and stored on the user device, and wherein the public key is used to verify the signed transactions originating from the user device and stored in the authentication system.

[0028] Clause 14: An authentication system according to any one of clauses 11 to 13, wherein, in order to execute the first payment transaction request, the processor is configured to: determine the device integrity of the user device; access the key pair in response to a successful determination of the device integrity of the user device; and verify the first payment transaction request to proceed with payment of the first payment transaction request.

[0029] Clause 15: An authentication system according to any one of clauses 11 to 14, wherein the processor is configured to store in a database an authentication mode registered by a user, an authentication mode selected by a user, success or failure of device authentication, and a timestamp associated with the success or failure of device authentication.

[0030] Clause 16: An authentication system according to any one of clauses 11 to 15, wherein the processor is configured to: determine whether the user device is associated with a device-level authentication control; and in response to determining that the user device is not associated with the device-level authentication control, register one of a second plurality of authentication modes to authenticate one or more other transaction requests.

[0031] Clause 17: An authentication system comprising: a processor; a memory communicatively coupled to the processor, wherein the memory stores instructions that, when executed, cause the processor to: receive a second payment transaction request from a user device and receive an authentication pattern from the user as input; verify user authentication based on a comparison of the input authentication pattern with a pre-registered authentication pattern set by the user; upon successful authentication of the user, sign one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication pattern; and execute the second payment transaction request after successful signing using the linked key pair.

[0032] Clause 18: The authentication system of clause 17, wherein the key pair is accessed in response to a successful determination of device integrity of the user device.

[0033] Clause 19: An authentication system according to clause 17 or 18, wherein, for execution of the second payment transaction request, the processor is configured to: determine the integrity of the user device; and store user device authentication data in a database, wherein the user device authentication data includes an authentication mode pre-registered by the user, an authentication mode selected by the user, success or failure of the device authentication, and a timestamp associated with the success or failure of the device authentication.

[0034] Clause 20: The authentication system of any of clauses 17 to 19, wherein to determine the integrity of the user device, the processor is further configured to determine one or more risks associated with the user device based on user device authentication data stored in the database. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings, which are incorporated into and constitute a part of this disclosure, illustrate exemplary embodiments or aspects and, together with the description, serve to explain the principles disclosed. In the figures, the left-most digit of a reference number identifies the figure in which the reference number first appears. Like numerals are used throughout the figures to refer to like features and components. Some non-limiting embodiments or aspects of the systems and / or methods according to the subject matter of the present invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:

[0036] Figure 1 is a schematic representation depicting an environment for network authentication using device-level authentication control according to some non-limiting embodiments or aspects of the present disclosure;

[0037] Figure 2 is a detailed block diagram of an authentication system for network authentication using device-level authentication control according to some non-limiting embodiments or aspects related to the present disclosure;

[0038] Figure 3A A flowchart illustrating a method for performing network authentication using device-level authentication control according to some non-limiting embodiments or aspects of the present disclosure;

[0039] Figure 3B A flowchart illustrating a method for implementing network authentication using device-level authentication control according to some non-limiting embodiments or aspects of the present disclosure; and

[0040] Figure 4 is a block diagram of an exemplary computer system for implementing non-limiting embodiments or aspects according to the present disclosure.

[0041] Those skilled in the art will appreciate that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the presently disclosed subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes that can be substantially represented in a computer-readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown. DETAILED DESCRIPTION

[0042] For purposes of the following description, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and their derivatives shall relate to the orientation of an embodiment or aspect in the accompanying drawings. However, it shall be understood that the embodiments may employ various alternative variations and step orders, except where expressly specified to the contrary. It shall also be understood that the specific devices and processes illustrated in the accompanying drawings and described in the following specification are merely exemplary embodiments or aspects of the disclosed subject matter. Accordingly, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein shall not be considered limiting.

[0043] It should be understood that, unless expressly specified to the contrary, the present disclosure may employ various alternative variations and step sequences. It should also be understood that the specific devices and processes shown in the accompanying drawings and described in the following specification are merely exemplary and non-limiting embodiments or aspects. Therefore, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein should not be considered limiting.

[0044] Some non-limiting embodiments or aspects are described herein in conjunction with threshold values. As used herein, satisfying a threshold value may refer to a value greater than a threshold value, more than a threshold value, higher than a threshold value, greater than or equal to a threshold value, less than a threshold value, less than a threshold value, lower than a threshold value, less than or equal to a threshold value, equal to a threshold value, etc.

[0045] As used herein, the aspects, components, elements, structures, actions, steps, functions, instructions, etc. should not be understood as being critical or necessary unless explicitly described as such. Furthermore, as used herein, the article "one" is intended to include one or more items and can be used interchangeably with "one or more" and "at least one". Furthermore, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related items and unrelated items, etc.), and can be used interchangeably with "one or more" or "at least one". In the case of wishing only one item, the term "one" or similar language is used. Furthermore, as used herein, the term "having" etc. is intended to be an open term. Additionally, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on". Additionally, the reference to the action of "based on" a condition may refer to the action being "in response to" the condition. For example, in some non-limiting embodiments or aspects, the phrases "based on" and "in response to" may refer to the condition of automatically triggering an action (e.g., a specific operation of an electronic device such as a computing device or a processor).

[0046] As used herein, the term "communication" may refer to the reception, acceptance, transmission, transfer, provision, etc. of data (e.g., information, signals, messages, instructions, commands, etc.). A unit (e.g., a device, a system, a component of a device or system, a combination thereof, etc.) communicating with another unit means that the unit is capable of receiving information from the other unit and / or sending information to the other unit, directly or indirectly. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, etc.) that is wired and / or wireless in nature. In addition, although the information sent may be modified, processed, relayed, and / or routed between a first unit and a second unit, the two units may also communicate with each other. For example, a first unit may communicate with a second unit even if the first unit passively receives information and does not actively send information to the second unit. As another example, a first unit may communicate with a second unit if at least one intermediate unit processes information received from the first unit and transmits the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (e.g., a data packet, etc.) containing data. It should be understood that many other arrangements are possible.

[0047] As used herein, the term "computing device" may refer to one or more electronic devices configured to process data. In some examples, a computing device may include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and the like. A computing device may be a mobile device. By way of example, a mobile device may include a cellular phone (e.g., a smartphone or a standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0048] As used herein, the term "server" may refer to or include one or more computing devices that are operated by or facilitate communications and processing by multiple parties in a network environment such as the Internet, but it should be understood that communications may be facilitated through one or more public or private network environments, and that various other arrangements may be possible. In addition, multiple computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, etc.) that communicate directly or indirectly in a network environment may constitute a "system." As used herein, references to a "server" or "processor" may refer to a previously described server and / or processor, a different server and / or processor, and / or a combination of servers and / or processors that are stated to perform a previous step or function. For example, as used in the specification and claims, a first server and / or first processor stated to perform a first step or function may refer to the same or different server and / or processor stated to perform a second step or function.

[0049] As used herein, the term "system" may refer to one or more computing devices or combinations of computing devices (e.g., processors, servers, client devices, software applications, components of such computing devices, etc.). As used herein, references to "device," "server," "processor," and the like may refer to a previously stated device, server, or processor stated as performing a previous step or function, a different server or processor, and / or a combination of servers and / or processors. For example, as used in the specification and claims, a first server or first processor stated as performing a first step or first function may refer to the same or a different server or the same or a different processor stated as performing a second step or second function.

[0050] In this document, the word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment or implementation of the present subject matter described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or aspects.

[0051] Although the present disclosure is susceptible to various modifications and alternative forms, specific embodiments of the present disclosure have been shown in the drawings by way of example and will be described in detail below. However, it should be understood that it is not intended to limit the present disclosure to the specific forms disclosed, but on the contrary, the present disclosure will cover all modifications, equivalents and alternatives that fall within the scope of the present disclosure.

[0052] The terms "comprises," "comprising," "includes," or any other variations thereof are intended to cover a non-exclusive inclusion, such that an arrangement, apparatus, or method that comprises a list of components or steps includes not only those components or steps, but may also include other components or steps not expressly listed or inherent to such arrangement, apparatus, or method. In other words, the listing of one or more elements in a system or device following the phrase "comprising..." does not, without more constraints, exclude the presence of other or additional elements in the system or method.

[0053] In the following detailed description of non-limiting embodiments or aspects of the present disclosure, reference is made to the accompanying drawings that form a part of the present disclosure, and in the accompanying drawings, specific embodiments in which the present disclosure may be practiced are shown by way of illustration. These non-limiting embodiments or aspects are described in sufficient detail to enable those skilled in the art to practice the present disclosure, and it should be understood that other non-limiting embodiments or aspects may be utilized and may be changed without departing from the scope of the present disclosure. Therefore, the following description should not be considered in a limiting sense.

[0054] In recent years, digital transactions using user devices, such as e-commerce transactions, card-on-file payments, Unified Payments Interface (UPI), and online banking, have increased dramatically. However, these transactions can be time-consuming due to network issues. Issuer servers may be down due to an inability to generate an OTP, potentially leading to unsuccessful transactions. To address this issue, one implementation based on regulatory exemptions could allow payment networks to authenticate transactions on behalf of issuers.

[0055] However, despite the reduced friction and increased scalability achieved through these traditional solutions, risk-averse users who are reluctant to trust payment processes without secondary authentication remain reluctant to make such payments, leading to a decrease in the number of users using these network authentication services. Furthermore, since transactions in these implementations may be executed by the payment network, if the server associated with the payment network experiences a server failure due to server issues, the payment network may be unable to successfully complete the transaction. Furthermore, without a secure mechanism or authentication system, the cardholder initiating the transaction may not be successfully authenticated, potentially leading to fraud.

[0056] To address the aforementioned issues, the present disclosure relates to a method for performing network authentication using device-level authentication control. The method includes receiving, by an authentication system, a first payment transaction request from a user device. Furthermore, in response to receiving consent, the method includes enabling an authentication mode for the user to perform authentication using the selected authentication mode. Furthermore, the method includes generating a key pair for linking with the enabled authentication mode to further authenticate the user device in one or more other transaction requests; and generating a registration completion message, the registration completion message enabling the user device to be authenticated in the one or more other transaction requests using the registered authentication mode. Thereafter, the method includes executing the first payment transaction request after successfully signing using the linked key pair. Thus, the present disclosure can be configured to utilize device authentication data as part of a network authentication risk check and associated cryptographic techniques as part of a device integrity determination, thereby providing a more secure method for completing transactions. This secure transaction method, as disclosed in the method, ensures and verifies that a registered user is performing network authentication, thereby providing secure transactions for the user during such network authentication using device-level authentication control. As an additional advantage, since network authentication risk checking is utilized in device-level authentication control, the present disclosure may provide an enhanced security way of authenticating several users utilizing network authentication using device-level authentication control.

[0057] Figure 1 A schematic representation depicting an environment (100) for network authentication using device-level authentication control depicts some non-limiting embodiments or aspects of the present disclosure.

[0058] The environment (100) includes a user device (102) communicatively coupled to a communication network (106), an authentication system (104), and a payment network (108). The communication network (106) can be one of a wired communication network, a wireless communication network, or a combination of both. The communication network (106) can include user devices (102) interconnected via one or more network devices, such as switches, hubs, gateways, routers, and the like. The user device (102) associated with a user can be configured to send a payment transaction request to the payment network (108) for authentication of the transaction based on an authentication mode selected by the user. In some non-limiting embodiments or aspects, the payment transaction request can also be referred to as one or more transaction requests.

[0059] The authentication system (104) may be configured to perform network authentication using a device-level authentication control for one or more transaction requests. In some non-limiting embodiments or aspects, the authentication system (104) receives a first payment transaction request from a user device (102). The first payment transaction request may include consent to register a user of the user device (102) to authenticate transactions based on an authentication mode selected by the user. The authentication mode may be one of a first plurality of registered authentication modes registered by the user. The first plurality of registered authentication modes registered by the user is associated with the device-level authentication control. For example, if the authentication mode for unlocking the user device (102) associated with the user is a password, then the first plurality of registered authentication modes are password-based authentications, where the user can be authenticated by entering the same password. If the authentication system (104) determines that the user has not consented to register any authentication mode for authenticating transactions and the user device (102) is not associated with the device-level authentication control, then the authentication system (104) may register the user of the user device (102) to one of a second plurality of authentication modes to authenticate one or more other transaction requests. For example, the authentication system (104) provides the user with an option to set up a new authentication mode, such as a 4-digit PIN, as a device-level authentication for one or more other transactions.

[0060] When registering or enabling a first plurality of authentication modes for a user associated with the user device (102), the authentication system (104) may associate the first plurality of authentication modes with the user device (102). In some non-limiting embodiments or aspects, the authentication system may generate a key pair and may link the generated key pair with the enabled authentication modes to further authenticate the user device (102) in one or more other transaction requests. The key pair may include, but is not limited to, a private key and a public key. The private key may be used to sign one or more transactions originating from the user device (102). The public key may be used to verify the signed transactions originating from the user device (102) and stored in the authentication system (104).

[0061] Upon linking the user's first plurality of authentication modes with the key pair, the authentication system (104) may generate a registration completion message that enables the user device (102) to be authenticated in one or more other transaction requests using the registered authentication modes and to execute the first payment transaction request.

[0062] In some non-limiting embodiments or aspects, the authentication system (104) is configured to execute the first payment transaction request after verifying the integrity of the user device (102). For example, the authentication system (104) can determine the device integrity of the user device (102), and after successfully determining the device integrity of the user device (102), the authentication system (104) can verify the first payment transaction request by accessing a key pair. The verification of the key pair is performed using cryptographic techniques. In some non-limiting embodiments or aspects, the payment network (108) can verify the signature of the linked key pair. In some non-limiting embodiments or aspects, if the authentication system (104) determines that the integrity of the user device (102) is compromised, the authentication system (104) can not execute the first payment transaction and generate a transaction failure message notifying the user that the transaction was unsuccessful.

[0063] In some non-limiting embodiments or aspects, the authentication system (104) may receive a second payment transaction request and an associated input authentication pattern from a user device (102) associated with a user. Furthermore, to authenticate the user device (102) associated with the user, the authentication system (104) may authenticate the input authentication pattern from the user device (102) with a pre-registered authentication pattern. The pre-registered authentication pattern may be set by the user upon registration for use in authenticating one or more other transaction requests based on the authentication pattern selected by the user. Upon successful authentication of the user device (102) associated with the user, the authentication system (104) may sign one or more transaction elements of the second payment transaction request using a key pair linked to the pre-registered authentication pattern. In some non-limiting embodiments or aspects, the generated key pair may be used to cryptographically sign one or more transactions in a tokenized transaction or in a flow, such as, but not limited to, a 3DS 2.0 flow. Thereafter, the authentication system (104) may execute the second payment transaction request after successfully signing using the linked key pair. In some non-limiting embodiments or aspects, after successfully determining the device integrity of a user device (102) associated with a user, the authentication system (104) may access a key pair. The authentication system (104) may determine the integrity of a user device (102) associated with a user based on one or more risks associated with the user device (102) and user device authentication data stored in a database. The user device authentication data may include, but is not limited to, an authentication mode pre-registered by the user, an authentication mode selected by the user (also referred to as an input authentication mode), a success or failure status of the device authentication, and a timestamp associated with the success or failure status of the device authentication. For example, the authentication mode pre-registered by the user is a password for user device A, a face ID for user device B, and the like. The success or failure of the device authentication indicates the total number of successful or failed attempts by the user to authenticate one or more transaction requests using the authentication mode on the user device (102). The timestamp associated with the success or failure of the device authentication may be, for example, at 12:45 a.m., the device authentication failed after four attempts, at 01:45 p.m., the device authentication succeeded after three attempts, and the like. It can be inferred that even after four attempts, the authentication pattern entered by the user is still incorrect, resulting in device authentication failure for the transaction request, and entering the correct authentication pattern after two attempts results in successful device authentication for one or more transaction requests. Figure 2 Detailed instructions for network authentication using device-level authentication control are shown in .

[0064] Figure 2 Depicted is a detailed block diagram (200) of an authentication system (104) for network authentication using device-level authentication control, according to some non-limiting embodiments or aspects related to the present disclosure.

[0065] In some non-limiting embodiments or aspects, the authentication system (104) may include a processor (201), a memory (203), and an I / O interface (204). The I / O interface (204) may be configured to receive and transmit input signals and / or output signals related to one or more operations of the authentication system (104). The memory (203) may be communicatively coupled to the processor (201) and one or more modules (205). The processor (201) may be configured to use data (206) and the one or more modules (205) to perform one or more functions of the authentication system (104).

[0066] In an embodiment, the data (206) stored in the memory (203) may include, but is not limited to, transaction request data, authentication mode data (208), key pairs (210), user device authentication data (212), and other data (214). In some embodiments, the data (206) may be stored in the memory (203) in various data structures. Additionally, a data model may be used to organize the data (206). The other data (214) may include various temporary data and files generated by different components of the authentication system (104).

[0067] In some non-limiting embodiments or aspects, the transaction request data may include one or more transaction requests. The one or more transaction requests may include, but are not limited to, a first payment transaction request, a second payment transaction request, and the like. In some non-limiting embodiments or aspects, the one or more transaction requests include a request to perform network authentication using a device-level authentication control using an authentication mode selected by a user. The first payment transaction request may include consent to register the user device (102) for authentication based on the authentication mode selected by the user. For example, if the user selected a password as the authentication mode during the first transaction, then for one or more other transactions, the user should enter the same password to successfully complete the one or more other transactions. The second payment transaction request includes a request to perform a second payment transaction based on network authentication using a device-level authentication control. For example, if password A is used to register for performing network authentication using device-level authentication control, then the second payment transaction succeeds only after the same password A is entered.

[0068] In some non-limiting embodiments or aspects, the authentication mode data (208) may include a plurality of authentication modes registered by the user for performing network authentication using device-level authentication control. For example, the authentication mode may include, but is not limited to, a static PIN, a pattern, a password, biometric authentication, etc. The authentication mode may be one of a first plurality of authentication modes registered by the user, a second plurality of authentication modes registered by the user, etc. The first plurality of registered authentication modes is associated with the device-level authentication control. For example, if the user has set a password X for unlocking the user device (102) associated with the user, then the password X must be entered when performing authentication. The second plurality of registered authentication modes is an authentication mode selected by the user if the user has not yet registered or agreed to use the authentication mode to authenticate the transaction request.

[0069] In some non-limiting embodiments or aspects, a key pair (210) may be used to verify a second plurality of transactions associated with a second payment transaction request. The key pair (210) may include a private key and a public key that are linked to each other for use in verifying the second plurality of transactions. The private key is used to sign the second plurality of transactions originating from the user device (102) and is stored in the user device (102). The public key is used to verify the signed transactions originating from the user device (102) and is stored in the authentication system (104). After successfully determining the device integrity of the user device (102), the authentication system (104) may access the key pair. Furthermore, in some non-limiting embodiments or aspects, after successfully signing using the linked key pair, the authentication system (104) may execute one or more transaction requests. In some non-limiting embodiments or aspects, the payment network (108) may verify the signature of the linked key pair. In some non-limiting embodiments or aspects, the authentication system (104) may verify the signature of the linked key pair. Verifying the signature of the linked key pair may be performed using a state of the art cryptographic technique.

[0070] The user device authentication data (212) is a type of data used to determine the integrity of the user device (102). The user device authentication data (212) may include, but is not limited to, an authentication mode pre-registered by the user, an authentication mode selected by the user (also referred to as an input authentication mode), a success or failure status of the device authentication, and a timestamp associated with the success or failure status of the device authentication. Examples of the user device authentication data (212) are described in Figure 1 The user device authentication data (212) may be stored in a database associated with the authentication system (104).

[0071] In some non-limiting embodiments or aspects, the data (206) may be processed by one or more modules (205) of the authentication system (104). In embodiments, the one or more modules (205) may include, but are not limited to, a receiving module (216), an authentication mode enabling module (218), a payment transaction registration module (220), a user authentication verification module (222), a transaction element signing module (224), and other modules (226). In embodiments, the other modules (226) may be used to perform various miscellaneous functionalities of the authentication system (104). It should be understood that such one or more modules (205) may be represented as a single module or a combination of different modules.

[0072] In some non-limiting embodiments or aspects, the receiving module (216) may be configured to receive a first payment transaction request from a user device (102). When registering the user device (102) for network authentication to authenticate based on an authentication mode selected by a user, the authentication mode enabling module (218) may be configured to enable the user device (102) associated with the user to perform authentication using the selected authentication mode. After successfully authenticating the user device (102) associated with the user, the payment transaction registration module (220) may be configured to generate a registration completion message that enables the user device (102) to be authenticated in one or more other transaction requests using the registered authentication mode. In some non-limiting embodiments or aspects, the payment transaction registration module (220) may be configured to execute the first payment transaction request by determining the device integrity of the user device (102), accessing the key pair (210) in response to the successful determination of the device integrity of the user device (102), and verifying the first payment transaction request.

[0073] After successfully authenticating the first payment transaction request, in some non-limiting embodiments or aspects, the receiving module (216) may be configured to receive a second payment transaction request from the user device (102) and receive an input authentication pattern from the user as input. The user authentication verification module (222) may be configured to verify the user authentication by comparing the input authentication pattern with a pre-registered authentication pattern set by the user.

[0074] Upon successful authentication of a user device (102) associated with the user, the transaction element signing module (224) may be configured to sign one or more transaction elements associated with the second payment transaction request using a key pair (210) linked to a pre-registered authentication schema. Thereafter, upon successful signing using the linked key pair, the payment transaction registration module (220) may be configured to execute the second payment transaction request by determining the integrity of the user device (102) and storing the user device authentication data (212). To determine the integrity of the user device (102), the payment transaction registration module (220) may be configured to determine one or more risks associated with the user device (102) based on the user device authentication data (212). In some non-limiting embodiments or aspects, one or more risks associated with the user device (102) can be, for example, the payment transaction registration module (220) checking whether the user device (102) has any vulnerabilities or misconfigurations based on information received from a third-party application (e.g., an antivirus or malware application, a device configuration application, etc.) installed in the user device (102) as part of determining the integrity of the user device (102).

[0075] In an alternative embodiment, the transaction process performed by the payment network (108) and the merchant application (not shown) is explained in the following paragraphs. First, the merchant application receives a payment transaction request and an authentication pattern as input from a user device (102) associated with the user. The payment transaction request may include, but is not limited to, a unique identifier, user device authentication data (212) stored in the merchant wallet. In addition, the merchant collects the device authentication result and the authentication pattern and sends them along with the transaction details to the payment network as part of the authentication request. If the input authentication pattern is the same as the pre-registered authentication pattern, the merchant application sends the payment transaction request along with the user-shared input authentication pattern to the payment network (108). In addition, the payment network (108) checks whether the authentication pattern registered by the user device (102) is part of the network authentication performed using the device authentication control. Thereafter, the payment network (108) sends the issuer device authentication identifier and the shared secret to the merchant application. In some non-limiting embodiments or aspects, the issuer device authentication identifier can be a key associated with a key pair (210) generated and stored in the user device (102). In addition, the merchant application sends a request for the user to authenticate the transaction using a device-level authentication that is the same as the issuer device authentication identifier. Upon successful authentication, the merchant application retrieves a key pair (210) using the issuer device authentication identifier and signs a shared secret using the key pair (210). In some non-limiting embodiments or aspects, the shared secret is a random string (also known as dynamic text) that is dynamically generated for the transaction. The shared secret is received by the merchant application. In some non-limiting embodiments or aspects, if the merchant application successfully signs the random string based on the shared secret provided by the payment network (108), then it is inferred that the user has authenticated on the merchant application and the key pair is accessed by the merchant application based on the signature relative to the random string. In addition, the merchant application sends the signed secret to the payment network (108) using the key pair. Finally, the payment network (108) performs an authentication check using the data collected during network authentication using the device authentication response, the signed shared secret, and network-specific risk rule checks.

[0076] Figure 3A A flow chart depicting a method (300A) for network authentication using device-level authentication control according to some non-limiting embodiments or aspects of the present disclosure.

[0077] like Figure 3AAs shown, the method (300A) includes one or more blocks that illustrate a method (300A) for network authentication for device-level authentication control. The method (300A) can be described in the general context of computer-executable instructions. Generally, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions that perform functions or implement abstract data types.

[0078] The order in which the method (300A) is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method (300A). Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method (300A) may be implemented in any suitable hardware, firmware, or a combination of hardware and software.

[0079] At block 301, the method (300A) includes receiving, by an authentication system (104), a first payment transaction request from a user device (102). The first payment transaction request includes consent for a user of the user device (102) to register for authentication based on an authentication mode selected by the user.

[0080] At block 303 , in response to receiving the consent, the method ( 300A) includes enabling, by the authentication system ( 104 ), the authentication mode for the user to perform authentication using the selected authentication mode.

[0081] At block 305 , upon successful authentication, the method ( 300A) includes generating, by the authentication system ( 104 ), a key pair ( 210 ) for linking with the enabled authentication mode to further authenticate the user device ( 102 ) in one or more other transaction requests.

[0082] At block 307, the method (300A) includes generating, by the authentication system (104), a registration completion message that enables the user device (102) to be authenticated in one or more other transaction requests using the registered authentication mode.

[0083] At block 309 , after successfully signing using the linked key pair, the method ( 300A) includes executing, by the authentication system ( 104 ), the first payment transaction request after successfully signing using the linked key pair.

[0084] Figure 3B A flow chart depicting a method (300B) of implementing network authentication using device-level authentication control according to some non-limiting embodiments or aspects of the present disclosure.

[0085] like Figure 3BAs shown, the method (300B) includes one or more blocks that illustrate a method (300B) for network authentication using device-level authentication control. The method (300B) can be described in the general context of computer-executable instructions. Generally, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions that perform functions or implement abstract data types.

[0086] The order in which the method (300B) is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method (300B). Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method (300B) may be implemented in any suitable hardware, firmware, or a combination of hardware and software.

[0087] At block 311 , the method ( 300B) includes receiving, by the authentication system ( 104 ) from the user device ( 102 ), a second payment transaction request and receiving as input an authentication pattern from the user.

[0088] At block 313, the method (300B) includes verifying, by the authentication system (104), the user authentication based on a comparison of the input authentication pattern with a pre-registered authentication pattern set by the user.

[0089] At block 315 , upon successful authentication of the user, the method ( 300B) includes signing, by the authentication system ( 104 ), one or more transaction elements associated with the second payment transaction request using the key pair ( 210 ) linked to the pre-registered authentication schema.

[0090] At block 317 , after successful signing using the linked key pair, the method ( 300B) includes executing, by the authentication system ( 104 ), the second payment transaction request.

[0091] Figure 4 A block diagram of an exemplary computer system (400) for implementing an embodiment or aspect consistent with the present disclosure is shown. Thus, the computer system (400) can be used to receive a first payment transaction request from a user device (102). The computer system (400) can include a central processing unit (402) (also referred to as a "CPU" or "processor"). The processor (402) can include at least one data processor. The processor (402) can include a special processing unit, such as an integrated system (bus) controller, a memory management control unit, a floating point unit, a graphics processing unit, a digital signal processing unit, etc. The processor (402) can be used to implement Figure 2 The processor (201) described in.

[0092] The processor (402) may be arranged to communicate with one or more input / output (I / O) devices (not shown) via an input / output (I / O) interface (401). The I / O interface (401) may employ communication protocols / methods such as, but not limited to, audio, analog, digital, mono, RCA, stereo, IEEE (Institute of Electrical and Electronics Engineers)-1394, serial bus, universal serial bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, digital video interface (DVI), high-definition multimedia interface (HDMI), radio frequency (RF) antenna, S-Video, VGA, IEEE 802.n / b / g / n / x, Bluetooth, cellular (e.g., code division multiple access (CDMA), high-speed packet access (HSPA+), global system for mobile communications (GSM), long-term evolution (LTE), WiMax, etc.), etc.

[0093] Using the I / O interface (401), the computer system (400) can communicate with one or more I / O devices. For example, the input device (409) can be an antenna, a keyboard, a mouse, a joystick, an (infrared) remote control, a camera, a card reader, a fax machine, a dongle, a biometric reader, a microphone, a touch screen, a touchpad, a trackball, a stylus, a scanner, a storage device, a transceiver, a video device / source, etc. The output device (410) can be a printer, a fax machine, a video display (e.g., a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED), a plasma, a plasma display panel (PDP), an organic light emitting diode display (OLED), etc.), an audio speaker, etc.

[0094] The processor (402) can be arranged to communicate with a communication network via a network interface (403). The network interface (403) can communicate with the communication network. The network interface (403) can use a connection protocol including, but not limited to, a direct connection, Ethernet (e.g., twisted pair 10 / 100 / 1000Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), Token Ring, IEEE 802.11a / b / g / n / x, etc. The communication network can include, but not limited to, a direct interconnection, a local area network (LAN), a wide area network (WAN), a wireless network (e.g., using Wireless Application Protocol), the Internet, etc. The network interface (403) can use a connection protocol including, but not limited to, a direct connection, Ethernet (e.g., twisted pair 10 / 100 / 1000Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), Token Ring, IEEE 802.11a / b / g / n / x, etc.

[0095] The communication network includes, but is not limited to, a direct interconnection, an e-commerce network, a peer-to-peer (P2P) network, a local area network (LAN), a wide area network (WAN), a wireless network (e.g., using the Wireless Application Protocol), the Internet, Wi-Fi, and the like. The first network and the second network can be dedicated networks or shared networks, which represent a connection of different types of networks that communicate with each other using various protocols, such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), Wireless Application Protocol (WAP), etc. In addition, the first network and the second network can include various network devices, including routers, bridges, servers, computing devices, storage devices, etc.

[0096] In some non-limiting embodiments or aspects, the processor (402) may be arranged to communicate with a memory (405) (eg, Figure 4 The storage interface (404) can be connected to a memory (405), including but not limited to a memory drive, a removable optical drive, etc., and the memory uses a connection protocol such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), Fibre Channel, Small Computer System Interface (SCSI), etc. The memory drive can also include a drum, a magnetic disk drive, a magneto-optical disk drive, an optical disk drive, a redundant array of independent disks (RAID), a solid-state memory device, a solid-state hard disk, etc.

[0097] The memory (405) can store a series of program or database components, including but not limited to a user interface (406), an operating system (407), a web browser (408), etc. In some non-limiting embodiments or aspects, the computer system (400) can store user / application data, such as data, variables, records, etc., as described in the present disclosure. Such a database can be implemented as a fault-tolerant, relational, scalable, secure database, such as or The memory (405) can be used to implement Figure 4 The memory (203) described in

[0045] may be communicatively coupled to the processor (402). The memory (405) stores instructions executable by one or more processors (402), which, when executed, cause the processor (402) to perform network authentication using device-level authentication control.

[0098] The operating system (407) may facilitate resource management and operation of the computer system (400). Examples of operating systems include, but are not limited to, the APPLE MACINTOSH R OS X, UNIX R, UNIX-like system distributions (e.g., Berkeley Software Distribution) TM (BSD), FREEBSD TM , NETBSD TM 、OPENBSD TM etc.), LINUX DISTRIBUTIONS TM (For example, RED HAT TM UBUNTU TM 、KUBUNTU TM etc.), IBM TM OS / 2, MICROSOFT TM WINDOWS TM (XP TM VISTA TM / 7 / 8,10, etc.), APPLE R iOS TM 、GOOGLE R Android TM , BLACKBERRY R OS, etc.

[0099] In some non-limiting embodiments or aspects, the computer system (400) may implement a program component stored in a web browser (408). The web browser (408) may be a hypertext viewing application such as MICROSOFT R INTERNET EXPLORER TM 、GOOGLE R CHROME TM0 、MOZILLA R FIREFOX TM 、APPLE R SAFARI TM etc. Secure web browsing can be provided using Hypertext Transfer Protocol Secure (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. The web browser (408) can utilize AJAX, for example TM 、DHTML TM 、ADOBE R FLASH TM 、JAVASCRIPT TM , JAVA TM, application programming interface (API) and other facilities. In some non-limiting embodiments or aspects, the computer system (400) may implement a program component stored in a mail server (not shown). The mail server may be an Internet mail server, such as Microsoft Exchange. The mail server may utilize, for example, ASP.NET or other similar software. TM ACTIVEX TM , ANSI TM C++ / C#、MICROSOFT R ,NET TM 、CGI SCRIPTS TM , JAVA TM 、JAVASCRIPT TM PERL TM PHP TM 、PYTHON TM 、WEBOBJECTS TM The mail server can use facilities such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), Exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), and other communication protocols. In some non-limiting embodiments or aspects, the computer system (400) may implement a program component stored in a mail client. The mail client (not shown) may be a mail viewing application, such as APPLE R MAIL TM MICROSOFT R ENTOURAGE TM MICROSOFT R OUTLOOK TM 、MOZILLA R Thunderbird TM wait.

[0100] In addition, one or more computer-readable storage media may be utilized to implement embodiments or aspects consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory that can store information or data that can be read by a processor. Thus, a computer-readable storage medium can store instructions for execution by one or more processors, including instructions for causing the processor to execute steps or stages consistent with the embodiments or aspects described herein. The term "computer-readable medium" should be understood to include tangible items and does not include carrier waves and transient signals, i.e., non-transient. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, non-volatile memory, hard drives, compact disc read-only memory (CD ROM), digital video discs (DVD), flash drives, magnetic disks, and any other known physical storage media.

[0101] The present disclosure can be configured to utilize device authentication data as part of a network authentication risk check, and associated cryptographic techniques as part of a device integrity determination, thereby providing a more secure way to complete transactions. This secure transaction method as disclosed in the method ensures and checks whether a registered user is performing network authentication, thereby providing secure transactions for the user during such network authentication performed using device-level authentication control. As an additional advantage, due to the utilization of network authentication risk checks in the device-level authentication control, the present disclosure can provide an enhanced security method of authenticating several users using network authentication using device-level authentication control without compromising any user details. In addition, compared to conventional solutions, the present disclosure can provide enhanced convenience to users by providing a simple way to complete transactions based on the device-level authentication control in action, thereby allowing transactions to be completed faster.

[0102] In view of the technical advancements provided by the disclosed method and control module, as described above, the claimed steps are not ordinary, conventional, or well-known aspects of the art because the claimed steps provide the aforementioned solutions to technical problems present in conventional technology. Furthermore, the claimed steps clearly improve the functionality of the system itself because the claimed steps provide technical solutions to technical problems.

[0103] Unless expressly specified otherwise, the terms “include,” “including,” “have,” and variations thereof mean “including but not limited to.” Unless expressly specified otherwise, the terms “a,” “an,” and “said” mean “one or more.”

[0104] The description of an embodiment with several components in communication with each other does not imply that all of these components are required. Rather, various optional components are described to illustrate the wide variety of possible embodiments or aspects of the disclosure.

[0105] When a single device or article is described herein, it will be apparent that more than one device / article (whether or not cooperating) may be used in place of a single device / article. Similarly, where more than one device / article is described herein (whether or not cooperating), it will be apparent that a single device / article may be used in place of more than one device / article, or a different number of devices / articles may be used in place of the number of devices or procedures shown. The functionality and / or features of a device may alternatively be embodied by one or more other devices that are not explicitly described as having such functionality / features. Thus, other non-limiting embodiments or aspects of the present disclosure need not include the device itself.

[0106] Finally, the language used in the specification is selected primarily for readability and didactic purposes and is not selected to delineate or limit the subject matter of the present invention. It is therefore intended that the scope of the present disclosure be limited not by this detailed description, but rather by any claims that issue on applications based on the present disclosure. Accordingly, the embodiments or aspects of the present disclosure are intended to be illustrative, but not limiting, of the scope of the present disclosure, which is set forth in the appended claims.

[0107] Although embodiments or aspects have been described in detail for purposes of illustration, it should be understood that such detail is solely for that purpose and that the present disclosure is not limited to the disclosed embodiments or aspects, but, on the contrary, is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the present disclosure contemplates that, to the extent possible, one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect.

Claims

1. A method comprising: receiving, by an authentication system, a first payment transaction request from a user device, wherein the first payment transaction request includes consent for registering a user of the user device for authentication based on an authentication mode selected by the user; In response to receiving the consent, enabling, by the authentication system, the authentication mode for the user to perform authentication using the selected authentication mode; Upon successful authentication, generating a key pair by the authentication system for linking with the enabled authentication mode to further authenticate the user device in one or more other transaction requests; generating, by the authentication system, a registration completion message, the registration completion message enabling the user device to be authenticated in the one or more other transaction requests using the registered authentication mode; and The first payment transaction request is executed by the authentication system after being successfully signed using the linked key pair. 2 . The method of claim 1 , wherein the enabled authentication mode is one of a first plurality of registered authentication modes enrolled by the user, wherein the first plurality of registered authentication modes are associated with device-level authentication control.

3. The method of claim 1 , wherein the key pair comprises a private key and a public key, wherein the private key is used to sign one or more transactions originating from the user device and is stored in the user device, and wherein the public key is used to verify the signed transactions originating from the user device and is stored in the authentication system.

4. The method of claim 1 , wherein executing the first payment transaction request comprises: determining device integrity of the user device; responsive to a successful determination of device integrity of the user device, accessing the key pair; as well as The first payment transaction request is verified to proceed with payment of the first payment transaction request.

5. The method of claim 1, comprising storing the authentication mode registered by the user, the authentication mode selected by the user, success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication in a database.

6. The method according to claim 1, comprising: determining whether the user device is associated with a device-level authentication control; as well as In response to determining that the user device is not associated with the device-level authentication control, one of a second plurality of authentication modes is registered to authenticate the one or more other transaction requests.

7. A method comprising: receiving, by the authentication system, a second payment transaction request from the user device and receiving as input an authentication pattern from the user; verifying, by the authentication system, user authentication based on a comparison of an input authentication pattern with a pre-registered authentication pattern set by the user; upon successful authentication of the user, signing, by the authentication system, one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication schema; as well as The second payment transaction request is executed by the authentication system after being successfully signed using the linked key pair.

8. The method of claim 7, wherein the key pair is accessed in response to a successful determination of device integrity of the user device.

9. The method according to claim 7, wherein executing the second payment transaction request comprises: determining the integrity of the user device; as well as User device authentication data is stored in a database, the user device authentication data including the authentication mode pre-registered by the user, the authentication mode selected by the user, success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

10. The method of claim 9, wherein to determine the integrity of the user device, the method further comprises determining one or more risks associated with the user device based on user device authentication data stored in the database.

11. An authentication system comprising: processor; a memory communicatively coupled to the processor, wherein the memory stores instructions that, when executed, cause the processor to: receiving a first payment transaction request from a user device, wherein the first payment transaction request includes consent to register a user of the user device for authentication based on an authentication mode selected by the user; In response to receiving the consent, enabling the authentication mode for the user to perform authentication using the selected authentication mode; Upon successful authentication, generating a key pair for linking with the enabled authentication mode to further authenticate the user device in one or more other transaction requests; generating a registration completion message, the registration completion message enabling the user device to be authenticated in the one or more other transaction requests using the registered authentication mode; as well as The first payment transaction request is executed after successfully signing using the linked key pair.

12. The authentication system of claim 11, wherein the enabled authentication mode is one of a first plurality of registered authentication modes enrolled by the user, wherein the first plurality of registered authentication modes are associated with device-level authentication control.

13. An authentication system according to claim 11, wherein the key pair includes a private key and a public key, wherein the private key is used to sign one or more transactions originating from the user device and stored in the user device, and wherein the public key is used to verify the signed transactions originating from the user device and stored in the authentication system.

14. The authentication system of claim 11 , wherein to execute the first payment transaction request, the processor is configured to: determining device integrity of the user device; Responsive to a successful determination of device integrity of the user device, accessing the key pair; and The first payment transaction request is verified to proceed with payment of the first payment transaction request.

15. The authentication system according to claim 11, wherein the processor is configured to store the authentication mode registered by the user, the authentication mode selected by the user, success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication in a database.

16. The authentication system of claim 11, wherein the processor is configured to: determining whether the user device is associated with a device-level authentication control; and In response to determining that the user device is not associated with the device-level authentication control, one of a second plurality of authentication modes is registered to authenticate the one or more other transaction requests.

17. An authentication system comprising: processor; a memory communicatively coupled to the processor, wherein the memory stores instructions that, when executed, cause the processor to: receiving a second payment transaction request from a user device and receiving an authentication pattern from a user as input; verifying user authentication based on a comparison of an input authentication pattern with a pre-registered authentication pattern set by said user; upon successful authentication of the user, signing one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication schema; as well as The second payment transaction request is executed after successfully signing using the linked key pair.

18. The authentication system of claim 17, wherein the key pair is accessed in response to a successful determination of device integrity of the user device.

19. The authentication system according to claim 17, wherein, for execution of the second payment transaction request, the processor is configured to: determining the integrity of the user device; and User device authentication data is stored in a database, the user device authentication data including the authentication mode pre-registered by the user, the authentication mode selected by the user, success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

20. The authentication system of claim 19, wherein to determine the integrity of the user device, the processor is further configured to determine one or more risks associated with the user device based on user device authentication data stored in the database.

Images