System and method for approving multiple security requests by using installation-free authentication and blockchain-based verification

Abstract

The embodiments relate to a system and a method for approving multiple security requests by using installation-free authentication and blockchain-based verification, the system and method comprising collecting, from a terminal device, web activity history information of the terminal device, the web activity history information including login history information and payment history information, recording the web activity history information of the terminal device in a blockchain on a blockchain network, receiving a request generated by authenticating a user by means of an authentication program embedded in the terminal device, determining whether the received request is an abnormal request on the basis of a blockchain record on the blockchain network, and approving the request of the terminal device if the request is not an abnormal request.

Description

A system and method for approving multiple security requests using installation-free authentication and blockchain-based verification.

[0001] Embodiments of the present application relate to a system and method for approving requests with multi-security using a blockchain-based verification technology and an installation-free authentication technology that authenticates users without installing a separate authentication app.

[0002] [Description of Nationally Supported Research and Development]

[0003] The research of the present invention was conducted with funding support from the Seoul Business Agency of Seoul Metropolitan Government's 2022 G Valley ICT Convergence Technology Commercialization Support Project (CG220018) for "Payment and Commerce System Combining Subscription Payment Function and Blockchain Security-Based Non-Installation Bio-Authentication System."

[0004] Thanks to rising standards of living and advancements in information and communication technology, many people now own and use personal devices such as personal computers or cell phones. These devices connect to servers via networks and can receive various services and content from the servers.

[0005] When processing a request from a terminal (e.g., login, adult verification, payment, transfer request, etc.) related to the provision of such services or contents, the server needs to determine whether the terminal or user has the legitimate authority to make the request, i.e., confirm whether the terminal or user is legitimate.

[0006] The most common example of this type of authentication method is one that utilizes a user-defined password. The server stores the user's password upon registration and then compares it with the password entered from the terminal. If the passwords match, the server verifies that the request was received by a legitimate user.

[0007] However, in existing payment systems, the password authentication method has limitations in that it is implemented in the form of app authentication, which operates on the application by installing a dedicated application for the payment system.

[0008] To solve the above-described problems, embodiments of the present application provide a system and method for approving requests with multi-security using a no-installation authentication technology and a blockchain-based verification technology that authenticates users without installing a separate authentication app.

[0009] However, the problems to be solved by the present invention are not limited to those mentioned above, and other problems to be solved that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present invention pertains from the description below.

[0010] A method for approving a request with multi-security according to one aspect of the present application may be performed by a system including a terminal device; and a server that participates as a node in a blockchain network while communicating with the terminal device through a public network. The method may include: a step of collecting web activity history information of the terminal device from the server, wherein the web activity history information includes login history information and payment history information; a step of recording, by the server, the web activity history information of the terminal device in a blockchain on the blockchain network; a step of authenticating a user through an authentication program built into the terminal device and generating a request and transmitting the request to the server; a step of determining, upon receiving the request from the server, whether the received request is an abnormal request based on a blockchain record on the blockchain network; and a step of approving and processing the request of the terminal device if the request is not an abnormal request.

[0011] In one embodiment, the method may further include, prior to receiving the web activity history information, receiving user identification information, blockchain address information corresponding to the identification information, and encrypted verification information from the terminal, and, if it is determined that the encrypted verification information is encrypted using a blockchain secret key corresponding to the identification information, matching the provided blockchain address information with the user's identification information and storing it on the server. The step of collecting the web activity history information of the terminal device from the server may be, at the terminal device, encrypting and transmitting the web activity history information of the terminal device using a pre-stored blockchain secret key. The step of recording, by the server, the web activity history information of the terminal device on a blockchain on the blockchain network may be, at the server, using a blockchain address corresponding to the identification information in the received web activity history information of the terminal device, decrypting the received encrypted web activity history information of the terminal device, and recording the decrypted web activity history information of the terminal device on the blockchain.

[0012] In one embodiment, the method comprises the steps of: receiving, from a different terminal device than the terminal device, an application for use of a blockchain secret key corresponding to the identification information; determining whether the application of the other terminal device is legitimate based on preset criteria; and controlling the terminal device so that, when the application of the other terminal device is determined to be legitimate, the terminal device transmits a blockchain secret key corresponding to the identification information to the other terminal device without going through the server; receiving, from the other terminal device, web activity history information of the other terminal device, the web activity history information of the other terminal device including the user's identification information, wherein the web activity history information of the other terminal device is encrypted with the blockchain secret key corresponding to the identification information obtained without going through the server; decrypting, by using blockchain address information corresponding to the identification information, the encrypted web activity history information of the other terminal device; And, if it is determined that the web activity history information of the other terminal device that has been encrypted through successful decryption has been encrypted using a blockchain secret key corresponding to the identification information, the step of recording the decrypted web activity history information of the other terminal device on the blockchain may be further included.

[0013] In one embodiment, the request is a login request or a payment request, and the step of authenticating the user through an authentication program built into the terminal device and generating a request and transmitting it to the server may be, if the request is a login request, generating a login request including authentication result information calculated by the built-in authentication program, connection information at the time of the request, and request information, or, if the request is a payment request, generating a payment request additionally including payment information at the time of the request.

[0014] In one embodiment, the step of determining whether the received request is an abnormal request based on a blockchain record on a blockchain network may include the steps of: when the server receives the request, generating a query condition for the request with at least some of the values ​​included in the request at the time of the request, and searching for block data having a value included in the query condition for the request with the query condition; calculating a matching rate between the web activity history information included in the searched block data and the information included in the request; and determining whether the request is an abnormal request based on the calculated matching rate. The step of searching for block data having a value included in the query condition for the request with the query condition may include calling a smart contract provided by nodes in the blockchain network, propagating the query condition for the request to a node capable of executing the smart contract, and executing the smart contract, thereby searching for block data having a value included in the query condition for the request from a distributed ledger stored in the node.

[0015] In one embodiment, the authentication result information may include the user's authentication probability value. The step of determining whether the request is an abnormal request based on the calculated matching rate may determine whether the request is an abnormal request based on a corrected matching rate obtained by applying the user's authentication probability value to the calculated matching rate.

[0016] In one embodiment, the step of searching for block data having a value included in the query condition for the request using the query condition may include the steps of: classifying values ​​included in the request at the time of the request into a first type of condition item or a second type of condition item according to a preset condition rule; generating a first query condition composed of values ​​for the first type of condition item among the values ​​at the time of the request; and searching for block data having a value included in the first query condition from a distributed ledger stored in the node by propagating the first query condition to a node capable of executing the smart contract and executing the smart contract. The step of calculating a matching rate between the web activity history information included in the searched block data and the values ​​at the time of the request may include the step of calculating a first matching rate between information corresponding to the first query condition in the web activity history information included in the searched block data and information corresponding to the first query condition in the information included in the request. The step of determining whether the request is an abnormal request based on the calculated matching rate may be determining whether the request is an abnormal request based on the calculated first matching rate.

[0017] In one embodiment, the step of searching for block data having a value included in the query condition for the request with the query condition may further include the steps of: generating a second query condition composed of values ​​for condition items of the second type; selecting block data having a first matching rate that is greater than or equal to the first threshold matching rate; and searching for block data having a value included in the second query condition in the selected block data by propagating the second query condition and a block hash of the selected block data to a node capable of executing the smart contract as a query condition for the selected block data and executing the smart contract.

[0018] The step of calculating a matching rate between the web activity history information included in the searched block data and the information included in the request may further include a step of calculating a second matching rate between information corresponding to the second query condition in the web activity history information included in the block data searched for both the first query condition and the second query condition and information corresponding to the second query condition in the information included in the request.

[0019] The step of determining whether the request is an abnormal request based on the calculated matching rate may be determining whether the request is an abnormal request based on the calculated second matching rate.

[0020] In one embodiment, the first threshold matching rate may be set to a value corresponding to a narrower confidence interval than the second threshold matching rate. The second threshold matching rate may be a threshold matching rate preset for comparison with the second matching rate.

[0021] In one embodiment, the method may further include a step of generating new web activity history information indicated by the request and additionally recording it on the blockchain network if the request is not determined to be an abnormal request. Then, the step of determining whether the request is an abnormal request based on the calculated matching rate may further include a step of first verifying whether the request is an abnormal request based on the matching rate, and then analyzing a change in the matching rate over a certain period of time among past matching rates recorded in the blockchain network, and if it is analyzed that the matching rate sequentially decreases over the certain period of time and if it is not analyzed that the matching rate increases again after the sequential decrease, determining the request having a matching rate higher than the threshold matching rate as an abnormal request.

[0022] According to another aspect of the present application, a computer-readable recording medium can record a program that causes a method of approving a request with multiple security according to the above-described embodiments.

[0023] According to another aspect of the present application, a server participates as a node in a blockchain network while communicating with a terminal device through a public network. The server may be configured to collect web activity history information of the terminal device from the terminal device, - the web activity history information includes login history information and payment history information; record the web activity history information of the terminal device in a blockchain on the blockchain network; receive a request generated by authenticating a user through an authentication program built into the terminal device; determine whether the received request is an abnormal request based on a blockchain record on the blockchain network; and, if the request is not an abnormal request, approve the request of the terminal device.

[0024] A multi-security request approval system utilizing installation-free authentication and blockchain-based verification according to one aspect of this application can be built by linking a web-based installation-free authentication system to a payment system. As a result, users can be initially authenticated through web-based biometric authentication without the need to install a separate authentication app.

[0025] Furthermore, the aforementioned multi-security request approval system utilizes block data recorded on the blockchain network to detect anomalous login and payment requests, further enhancing the security of installation-free systems. In particular, even if passwords or other information are leaked, the extent of damage can be reduced through anomalous request detection.

[0026] In particular, to prevent block data from being contaminated with false records from third parties other than the true user, blockchain key technology is utilized to authenticate legitimate users, ensuring that only legitimate users provide historical information to the server. This means that only legitimate users, not the server, can store historical information. Specifically, when processing historical information received from a terminal and recorded on the blockchain network, blockchain key technology can be used to determine the legitimacy of the historical information, and the historical information can be recorded based on the results of this legitimacy determination.

[0027] As a result, even if the above multi-security request approval system is built with a web-based system architecture without the need to install a separate authentication app, damage that may occur when login / payment or other requests are false can be prevented.

[0028] The effects of the present invention are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description of the claims.

[0029] To more clearly explain the technical solutions of embodiments of the present invention or prior art, the drawings required for the description of the embodiments are briefly introduced below. It should be understood that the drawings below are for the purpose of illustrating embodiments of the present specification and are not intended to be limiting. Furthermore, for clarity of explanation, some elements may be depicted with various modifications, such as exaggeration or omission, in the drawings below.

[0030] FIG. 1 is a schematic diagram of a multi-security request approval system according to one aspect of the present application.

[0031] FIG. 2 is a diagram illustrating a blockchain network according to various embodiments of the present application.

[0032] FIG. 3 is a flowchart of a process for recording web activity history information on a blockchain for multi-secure payment according to various embodiments of the present application.

[0033] FIG. 4 illustrates a process by which a server collects encrypted web activity history information of a user according to various embodiments of the present application.

[0034] FIG. 5 illustrates a process by which a server collects encrypted web activity history information of a user according to various embodiments of the present application.

[0035] FIG. 6 illustrates a request approval process of the multi-security request approval system for a login request according to various embodiments of the present application.

[0036] FIG. 7 illustrates a process for generating a login request using biometric authentication according to various embodiments of the present application.

[0037] FIG. 8 illustrates a blockchain-based anomaly detection process for a login request according to various embodiments of the present application.

[0038] FIG. 9 illustrates a request approval process of the multi-security request approval system for a payment request according to various embodiments of the present application.

[0039] FIG. 10 illustrates a process for generating a payment request using biometric authentication according to various embodiments of the present application.

[0040] FIG. 11 illustrates a blockchain-based anomaly detection process for a payment request according to various embodiments of the present application.

[0041] Hereinafter, embodiments of the present application will be described in detail with reference to the drawings.

[0042] However, this disclosure is not intended to limit the present disclosure to a specific embodiment, but should be understood to encompass various modifications, equivalents, and / or alternatives of the embodiments of the present disclosure. In connection with the description of the drawings, similar reference numerals may be used for similar components.

[0043] In this specification, expressions such as “has,” “may have,” “includes,” or “may include” indicate the presence of a feature (e.g., a component such as a number, function, operation, step, part, element, and / or component), and do not exclude the presence or addition of additional features.

[0044] When a component is referred to as being "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but that there may be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

[0045] The terms "first," "second," "first," or "second" used in various embodiments may describe various components, regardless of order and / or importance, and do not limit the components. These terms may be used to distinguish one component from another. For example, "first component" and "second component" may represent different components, regardless of order or importance.

[0046] The expression "configured to" as used herein can be used interchangeably with, for example, "suitable for," "having the capacity to," "designed to," "adapted to," "made to," or "capable of." The term "configured to" does not necessarily mean something is "specifically designed to" in terms of hardware. Instead, in some contexts, the expression "a device configured to" can mean that the device, together with other devices or components, is "capable of." For example, the phrase "a processor configured (or set) to perform A, B, and C" may mean a dedicated processor (e.g., an embedded processor) for performing those operations, or a general-purpose processor (e.g., a CPU or application processor) that can perform those operations by executing one or more software programs stored in a memory device.

[0047] The advantages and features of the present invention, and the methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided solely to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined solely by the scope of the claims.

[0048] When describing embodiments of the present invention, detailed descriptions of known functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the invention. Furthermore, the terms described below are defined based on their functions in the embodiments of the present invention and may vary depending on the intent or custom of the subscriber or operator. Therefore, their definitions should be based on the overall content of this specification.

[0049]

[0050] FIG. 1 is a schematic diagram of a multi-security request approval system according to one aspect of the present application.

[0051] Referring to FIG. 1, the multi-security request approval system (1) includes a terminal device (100) that communicates with a server (10). The server (10) and the terminal device (100) may also communicate with a third-party system (20). In various embodiments of the present application, the terminal device (100) may be a first terminal device (100-1) and a second terminal device (100-2). However, since the detailed configuration of the system (1) of FIG. 1 is merely a specific embodiment of the present invention, the technical idea of ​​the present invention is not limited by FIG. 1. For example, other terminal devices other than the first terminal (100-1) and the second terminal (100-2) may exist in the system (10). In addition, the system (10) may further include configurations that are obvious to those skilled in the art, as may be included in a system composed of a server and a terminal device, in addition to the configuration illustrated in FIG. 1.

[0052] The above system (1) may be entirely hardware, entirely software, or may have aspects that are partially hardware and partially software. For example, a system may collectively refer to hardware equipped with data processing capabilities and operating software for driving the same. In this specification, terms such as "unit," "module," "device," or "system" are intended to refer to a combination of hardware and software driven by the hardware. For example, hardware may be a computing device capable of processing data, including a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), or other processor. In addition, software may refer to a running process, an object, an executable, a thread of execution, a program, etc.

[0053] At least one component of the above multi-security request approval system (1) may operate as a node participating in a blockchain network (1000), so that the above multi-security request approval system (1) may be configured to operate in conjunction with the blockchain network (1000).

[0054] The above multi-security request approval system (1) can store at least a portion of the past request history of a user of a terminal device (100) using the blockchain network (1000). Information on at least one transaction representing the user's past request history is added to the blockchain in the form of block data and distributed and stored in participating nodes through the blockchain network (1000). To increase data transparency and prevent errors or fraud, the blockchain network (1000) records all transactions on a chain so that all participants in the network (1000) can review their details.

[0055] Furthermore, falsification is impossible through distributed storage via the blockchain network (1000). This is because each block contains the hash value of the previous block, ensuring data integrity. However, falsification impossibility does not necessarily mean that information within the block data cannot be altered. Information within the block data may be modified based on the consensus of participants within the blockchain network (1000). Then, the modified information within the block data is again distributed and stored via the blockchain network (1000), ultimately updating the modified information to ensure that falsification is impossible.

[0056] In this multi-security request approval system (1), the server (10)0 can be constructed by linking a web-based installation-free authentication system with a payment system where login requests and payment requests occur, and the web-based installation-free authentication system can be configured as an installation-free authentication system that does not require a separate authentication app to be installed on a terminal device (100) and an anomaly detection system that detects anomalies by utilizing block data recorded in a chain.

[0057] Below, the configuration (10, 100) of the multi-security request approval system (1) is first examined, and the linked blockchain network (1000) is described.

[0058]

[0059] The server (10), third-party system (20), and terminal device (100) are configured to communicate through a public network.

[0060] The above public network may refer to a public network that users can generally access via a communication network such as the Internet for easy access to the blockchain network (1000). The public network provides a wired / wireless electrical communication path through which a terminal device (100) and a server (10) can exchange data. The public network is not limited to a communication method based on a specific communication protocol, and an appropriate communication method may be used depending on the implementation example. For example, if the public network is configured as an Internet Protocol (IP)-based system, the public network may be implemented as a wired and / or wireless Internet network, and if the server (10) and the terminal (100) are implemented as mobile communication terminals, the public network may be implemented as a wireless network such as a cellular network or a wireless local area network (WLAN) network.

[0061] The server (10) may include a processor and a memory, and the processor may perform a series of operations based on the commands by executing the commands stored in the memory.

[0062] The terminal (100) is a device that performs an operation according to a user input, and includes at least one processor capable of processing data, a memory for storing data, and a communication unit for transmitting / receiving data. The terminal (100) may be implemented in the form of, for example, a laptop computer, a notebook, other computing devices, a tablet, a cellular phone, a smart phone, a smart watch, smart glasses, a head-mounted display (HMD), other mobile devices, or other wearable devices.

[0063] A single user can utilize multiple terminal devices (100). The first terminal device (100-1) and the second terminal device (100-2) may be different terminal devices. Here, the different terminal devices are not limited to different models, and may be of the same model, for example, both are smartphones, but may be different terminal devices. Accordingly, the first terminal device (100-1) and the second terminal device (100-2) may be mobile terminals such as smartphones, but they may also be non-mobile terminals such as personal computers, and it is a well-known fact that they may include hardware components such as memory and processors.

[0064] Since the concepts of server and terminal are self-evident to those skilled in the art, further detailed description of the hardware implementation of the server (10), the first terminal device (100-1), and the second terminal device (100-2) will be omitted.

[0065]

[0066] Terminal devices (100), such as the first terminal device (100-1) and the second terminal device (100-2), can transmit various types of requests (e.g., login requests, adult authentication requests, payment requests, transfer requests, etc.) to the server (10) in relation to receiving services or content from the server (10) or a second-party system (20).

[0067] The terminal device (100) is configured to pre-store the user's biometric information for user identification. The user's biometric information may include, but is not limited to, facial information, iris information, or other biometric information that can identify the user.

[0068] In addition, the terminal device (100) is configured to perform a biometric authentication operation, which acquires the user's biometric information through a camera or other sensors, and compares the acquired biometric information with pre-stored biometric information to verify the user. The built-in authentication program is an authentication program integrated and built into the OS of the terminal device (100) without requiring the user to install a separate authentication app on the terminal device (100), and may be various authentication programs provided by the manufacturer of the terminal device (100). In this specification, "no installation" means that the user does not install a separate authentication app.

[0069] The built-in authentication program may be an authentication program utilizing a password or pattern preset by the user, or a biometric authentication program utilizing the user's biometric information. The biometric authentication program built into the terminal device (100) may be, for example, Apple's Face ID program or Samsung Electronics' fingerprint recognition program, but is not limited thereto. For clarity, the present invention will be described in more detail below with examples in which the biometric authentication operation is implemented using a facial authentication method such as Face ID.

[0070] The terminal device (100) can authenticate users through a pre-built authentication program. The authenticated user is verified as a legitimate user of the terminal device (100).

[0071] In various embodiments of the present application, the terminal device (100) may obtain and store a blockchain secret key corresponding to a blockchain address. The terminal device (100) may access the blockchain network (1000) via the server (10) to obtain the blockchain secret key.

[0072] The terminal device (100) can encrypt at least a portion of the request using a blockchain secret key. Furthermore, the terminal device (100) can decrypt the encrypted information using its own blockchain secret key corresponding to the blockchain address.

[0073] The operation of the above terminal device (100) is described in more detail with reference to FIGS. 2 to 10 below.

[0074]

[0075] The server (10) may be a server that provides services and contents to the terminal device on its own, or may be a server that has been delegated approval of a user request from a third-party system (20) that provides the services and contents.

[0076] When the server (10) provides services and contents to a terminal device such as a first terminal device (100-1) or a second terminal device (100-2), the services provided by the server (10) may be payment-related services such as payment services and e-commerce services for the terminal device (100). The contents provided by the server (10) may be contents related to the services.

[0077] In various embodiments of the present application, the server (10) may be a node participating in the blockchain network (1000), and may be a blockchain network terminal. The server (10) may be directly connected to the blockchain network (1000) and may have blockchain client software installed to host at least some nodes of the network. The server (10) participates in the blockchain network (1000) and has blockchain and block data.

[0078] On the other hand, the terminal device (100) may be a light client device that does not have blockchain data or stores only necessary information and requests data from other nodes as needed.

[0079] The multi-security request approval system (1) is linked to a blockchain network (1000) through the server (10). The server (10) can access the linked blockchain network (1000) and perform various computational operations to approve a request from a terminal device (100) with multi-security.

[0080] FIG. 2 is a diagram illustrating a blockchain network (1000) according to various embodiments of the present application.

[0081] Referring to FIG. 2, the blockchain network (1000) in which the server (10) participates may be understood as a peer-to-peer network comprising a plurality of interconnected computing devices (hereinafter, "nodes"). Each node may include one or more processors to perform computations. Specifically, the blockchain network may be referred to as a peer-to-peer network comprising a plurality of interconnected computing devices (peers or nodes) via a network to implement a distributed database with a blockchain structure.

[0082] Users accessing the multi-security request approval system (1) can have blockchain account information registered in the blockchain network.

[0083] A blockchain network (1000) can process transactions and record them on the blockchain. For example, the blockchain network (1000) can process transactions representing web activity history information and record them on the blockchain.

[0084] Blockchain account information may include a private key and a public key. The private key may function as a user's digital signature to enable a transaction to occur on a blockchain network (e.g., a transaction to transfer a 'digital payment instrument' or 'information / data' from a first user account to a second user account, a transaction to deploy a smart contract on a blockchain network, a transaction to execute a smart contract, etc.). The public key may function as the user's account address (hereinafter, 'account'). In various embodiments, the account may include a human-readable string or number sequence.

[0085] Transactions are generated by nodes (e.g., servers (300)) utilizing a blockchain network. Transactions may include information related to an administrator terminal (100) (e.g., contract information), information related to a display device (e.g., location information of the display device), information related to a content provider terminal (200) (e.g., content information), information related to cryptocurrency / token transfers, or information related to smart contracts, as described below. Nodes can verify the results of transaction processing via the blockchain.

[0086] Transactions occurring on a blockchain network are cryptographically signed by the private key of the blockchain account of the entity that created the transactions, so they can be recorded on the blockchain network as cryptographic proof data that cannot be forged.

[0087] When a transaction occurs, nodes in the blockchain network verify the integrity of the transaction and, based on the consensus algorithm implemented in the blockchain network (e.g., Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), etc.), create a new block to follow the previously created block. The newly created block is then propagated to other nodes, allowing the transaction to be executed. A block can contain information about multiple transactions.

[0088] Information about blocks can be stored in a transaction database shared by nodes. The transaction database can be understood as a public ledger in which multiple nodes share the same information. Specifically, the multiple computing devices can have a single public ledger. A blockchain network can be referred to as a distributed network in that a single public ledger is created by each of the multiple computing devices. This single public ledger can be referred to as a blockchain.

[0089] In various embodiments of the present application, the blockchain network (1000) may be a private blockchain network. A private blockchain network is typically controlled by a single organization or specific entity and has limited participants. A private blockchain network may have a centralized structure. Unlike a public blockchain network, a specific entity or group has authority over the network and can perform activities such as verifying transactions or adding blocks. The private blockchain network restricts participation to nodes authorized by the entity or group of entities operating the network. Due to the limited number of participants and control, the private blockchain network provides a higher level of security than a public blockchain. Furthermore, because the number of participants is limited, the private blockchain network is efficient, with fast transaction processing speeds and low operating costs. Furthermore, the private blockchain network can restrict access to blockchain data due to the limited number of participants, thereby ensuring the privacy of sensitive information.

[0090] In some embodiments, the private blockchain network (1000) may be a consortium blockchain network operated by a consortium node. A consortium blockchain network is a network in which multiple organizations participate as operating nodes and jointly manage the network. No single organization has exclusive control over the network; instead, they operate the blockchain network through mutual agreement.

[0091] The above server (10) can participate in the blockchain network (1000) as an operating node or a general participant node.

[0092] It will be apparent to those skilled in the art that the multi-security request authorization system (1) having these components (10, 100) may also include other components not described herein. For example, it may further include a data input device, an output device such as a display and / or printer, a network, a network interface, and protocols.

[0093] When the above server (10) receives a request such as a login request or payment request from a terminal device (100), it can be configured to verify the legitimacy of the login request or payment request and approve the request for which legitimacy has been verified.

[0094]

[0095] Recorded on the blockchain network

[0096] FIG. 3 is a flowchart of a process for recording web activity history information on a blockchain for multi-secure payment according to various embodiments of the present application.

[0097] The method of FIG. 3 can be performed by the server (10) and the terminal device (100) of FIG. 1. However, since the method illustrated in FIG. 3 is merely a specific embodiment of the present invention, the spirit of the present invention is not limited by FIG. 3, and each step of the method illustrated in FIG. 3 may be performed in a different order from the drawing depending on the case, and this also applies to FIGS. 6 and 9 hereafter. In addition, the method of FIGS. 6 and 9 can be implemented through a method of installing an application program in the server (10), the first terminal device (100-1), and the second terminal device (100-2), and more specifically, can be implemented through an SDK (software development kit), an API (application programming interface), etc.

[0098] In addition, the method of FIG. 3 is explained under the assumption that the user has performed login activities, payment activities, or other activities on the web that can generate information (e.g., login history information, payment history information, or other activity history information) that records related activity history through the first terminal device (100-1) or the second terminal device (100-2), and that information necessary for the authentication process, such as identification information for identifying the user of the terminal device (100), or a blockchain address and blockchain secret key corresponding to the identification information, is provided in the server (10) or the first terminal device (100-1).

[0099] For example, the server (10) may have previously secured identification information and blockchain address information corresponding to the identification information. By receiving the identification information generated by the terminal device (100) and the blockchain address information corresponding to the identification information from the terminal device (100), the server (10) may prepare to decrypt the encrypted information included in the request using the corresponding blockchain address information whenever a request including the provided identification information is received. The identification information and blockchain address information are preferably continuously stored in the server (10), but may also be provided to the server (10) from another device whenever necessary. Meanwhile, when receiving the identification information and the blockchain address information corresponding to the identification information, the server (10) may also receive encrypted verification information from the terminal device (100). Such encrypted verification information may be generated by the terminal device (100) by encrypting the blockchain address information corresponding to the identification information using a blockchain secret key corresponding to the identification information. The server (10) can determine the legitimacy of the encrypted verification information (i.e., whether the blockchain address information corresponding to the identification information was created by encrypting the blockchain address information corresponding to the identification information using the blockchain secret key corresponding to the identification information) by decrypting the encrypted verification information using the blockchain address information, and if determined to be legitimized, the server (10) can match the provided blockchain address information to the identification information and store it in the server (10) or another device.

[0100] Referring to FIG. 3, the method includes a step (S310) of collecting the user's web activity history information from the terminal device (100); and a step (S320, S330) of recording the user's web activity history information in a blockchain on a blockchain network (1000).

[0101] The above terminal device (100) may be a first terminal device (100-1) and / or a second terminal device (100-2).

[0102] The third-party system (20) may be a system other than the server (10) that provides services or content to terminal devices. The third-party system (20) may be any of various e-commerce systems, search engine systems, other payment systems, or other login systems disclosed prior to the filing of the present invention.

[0103] A third-party system (20) and a terminal device (100) can access the website of the third-party system (20) via the World Wide Web, generate web activity history information, and store it within the device. The web activity history is a tracking and recording of user activities such as visiting a website, searching, clicking, or purchasing a product. The web activity history information may be stored in the terminal device (100) in the form of cookies.

[0104] The above web activity history information may be login history information or payment history information.

[0105] Login history information can be generated by tracking a user's login activity. This login history information may include the user's identification information, access information, and request information.

[0106] Request information indicates the specific details of a request for web activity history. For example, request information within login history information may indicate that the terminal device (100) wishes to log into a website.

[0107] Connection information indicates the status of access to the corresponding web page (e.g., login screen) for web activity, and may include, for example, one or more of the following information: connection location, connection device, connection device OS, connection browser, connection language, connection time, and connection website address.

[0108] The connection location may be the actual geographic location of the terminal device (100) (e.g., GPS coordinates, geographic address), or a location corresponding to the actual geographic location (e.g., a geographic region corresponding to an IP address). The geographic region may be a broader area including the actual geographic location, such as a city, province, state, or country.

[0109] The access website address may be a web page address that displays a login screen, or may be another web page address that shares at least a portion of the address with the web page address that displays the login screen among the web pages of a third-party system (20) that provides the login screen. The other web page address may be a representative address among the web pages provided by the third-party system (20), such as the main screen address.

[0110] Access time is the time when the website is accessed for a login attempt, and can be expressed as the day of the week and the time of access.

[0111] The access device is an identifier that indicates the device used to access the website, and may be, for example, a device ID, a universally unique identifier (UUID), or various identifiers associated with the device.

[0112] The connected device OS may be the identification number of the device OS (operating system).

[0113] The above identification information is information for identifying the user of the terminal device (100), and may be, for example, a user ID (identification), which is unique information provided by a third-party system (20) to identify the user, or an email address or other identification number. The user ID may be entered as login information on the login screen provided by the third-party system (20).

[0114] The above identification information may be associated with the web page address where the above identification information is used as login information. Since users may have different IDs registered for each third-party system (20), the ID entered as login information for a specific web page address may be different from the ID entered as login information for another web page address, even for the same user.

[0115] Payment history information can be generated by tracking a user's payment activity. This payment history information may include access information, payment information, and request information.

[0116] The request information within the payment details, similar to the request information within the login details, indicates the specific details of a request for details for web activities. For example, the request information within the payment details may indicate that the terminal device (100) wishes to pay for a specific product through the website's payment screen. Similar to the request information within the login details,

[0117] The connection information in the payment details information, like the connection information in the login details information, indicates the status of connection to the corresponding web page (e.g., payment screen), and may include, for example, one or more of the following information: connection location, connection device, connection device OS, connection browser, connection language, connection time, and connection website address. Since the connection information in the payment details information is similar to the connection information in the login details information, the differences will be mainly described.

[0118] The access website address may be the address of the web page that displays the payment screen.

[0119] Access time is the time when the website is accessed for a login attempt, and can be expressed as the day of the week and the time of access.

[0120] Payment information is information that describes payment activity and may include, for example, one or more of the following: payment amount, payment product, payment currency, payment method, number of repeat visits, previous payment history, payment method, and number of payment attempts.

[0121] Payment methods may be lump sum, installments, or other payment methods such as partial lump sum and partial installments.

[0122] The payment method may be a card, cash, or electronic money (e.g., points, etc.) accepted by a third-party system (20).

[0123] The number of revisits indicates the frequency of revisiting the terminal device (100) to the web page address displaying the payment screen.

[0124] Existing payment history represents payments made through the web page address that displays the payment screen above. This existing payment history can be expressed as payment information and access information from past payment activities.

[0125] The terminal device (100) generates web activity history information of the user and transmits the generated web activity history information to the server (10) (S310). The web activity history information may be generated and transmitted to the server (10) each time the corresponding web activity is performed. In other words, the generation time and the transmission time may be the same or similar.

[0126] In various embodiments of the present application, the terminal device (100) can encrypt and transmit the user's web activity history information using a blockchain secret key stored in the terminal device (100) (S310).

[0127] FIG. 4 illustrates a process by which a server collects encrypted web activity history information of a user according to various embodiments of the present application.

[0128] Referring to FIG. 4, the terminal device (100) can generate user web activity history information to be transmitted to the server (10) (S3101). The user web activity history information generated by the terminal device (100) may be generated by encrypting at least some of the user's identification information, user access information, and history information included in the web activity history information.

[0129] The terminal device (100) can generate encrypted information from part or all of the user's web activity history information, and such encrypted information can replace traditional authentication methods such as passwords. As described above, the user's identification information may vary for each web page, and therefore, it is not possible to guarantee that the entire web activity history information is the user's history with only one piece of identification information within the existing history information.

[0130] The terminal device (100) may encrypt the above-described encrypted information using a blockchain secret key corresponding to the identification information when generating the encrypted information. The secret key may function as a user's digital signature to enable a transaction (e.g., a transaction to transfer a 'digital payment method' from a first user account to a second user account, a transaction to distribute a smart contract on a blockchain network, a transaction to execute a smart contract, etc.) to occur on the blockchain network.

[0131] Here, encryption and decryption using blockchain secret keys and blockchain addresses will be described. Assuming there is some encrypted data, it may be necessary to verify whether the encrypted data was encrypted using a specific blockchain secret key. In this case, such verification is possible using a blockchain address corresponding to the blockchain secret key, and a method based on a public key infrastructure (PKI) can be used for this verification. More specifically, when data encrypted using a specific blockchain secret key is decrypted using a blockchain address corresponding to the blockchain secret key, if a value identical to a predetermined value is obtained, it can be determined that the encrypted data was encrypted using the specific blockchain secret key. Conversely, if a value identical to the predetermined value is not obtained, it can be determined that the encrypted data was not encrypted using the specific blockchain secret key.

[0132] Therefore, encryption using a blockchain private key can be called "signature," and decryption using a blockchain address can be called "verification" of the signature. Verification of a signature using a specific blockchain private key can be achieved only through decryption using the blockchain address corresponding to that specific blockchain private key. Such algorithms are called "asymmetric key encryption algorithms," and algorithms such as RSA and ECDSA can be used, for example.

[0133] Meanwhile, the term "blockchain private key" used in this document may include a private key based on various asymmetric key encryption algorithms, and "blockchain address information" may include a public key based on various asymmetric key encryption algorithms. The public key may function as a user's account address (hereinafter, "account"). In various embodiments, the public key may include a human-readable string or number sequence.

[0134] For the sake of ease of understanding, this document will describe the concepts by unifying the terms that can be called by various names into the names of 'blockchain secret key' and 'blockchain address'.

[0135] The terminal device (100) can store only the blockchain secret key corresponding to the identification information, and can allow other entities, including the server (10), to have the blockchain address corresponding to the blockchain secret key.

[0136] According to this method, since only the terminal device (100) can encrypt the user's web activity history information using the blockchain secret key corresponding to the identification information, the blockchain secret key corresponding to the identification information can serve as an authentication means to prove that the user's web activity history information was legitimately generated by the terminal device (100). As described above, anyone who can access the blockchain address corresponding to the identification information (e.g., server (10)) can verify the user's web activity history information. Accordingly, since the encrypted information included in the user's web activity history information can be decrypted by anyone through the blockchain address, which is public information, the encrypted information itself cannot be protected, but it is possible to determine whether the encrypted information is legitimate.

[0137] Meanwhile, unlike using private blockchain secret keys for encryption and public blockchain addresses for decryption, which are typically used for signing and verification (i.e., authentication), data can be encrypted using public blockchain addresses and decrypted using private blockchain secret keys. In this case, only legitimate users with undisclosed blockchain secret keys can decrypt encrypted data. Therefore, even if unauthorized users obtain the encrypted data, they cannot decrypt it. Consequently, encrypted data can be protected from unauthorized users.

[0138] The step (S310) of collecting web activity history information of a terminal device from the server may be to encrypt and transmit the web activity history information of the terminal device using a pre-stored blockchain secret key in the terminal device.

[0139] The server (10) can receive the user's web activity history information generated by the terminal device (100) from the terminal device (100) (S3102). Using the blockchain address corresponding to the identification information in the received user's web activity history information, the server (10) can decrypt the received encrypted information (S3103). Since the blockchain address corresponding to the identification information is publicly available, the server (10) may directly store the blockchain address, or, if necessary, may receive it from another device connected to the network and use it.

[0140] Based on the decryption result, the server (10) can determine whether to record the user's web activity history information received from the terminal device (100) in the blockchain network (1000) (S3104). More specifically, if the server (10) determines that the encrypted information was generated by encrypting it using a blockchain secret key corresponding to the identification information, i.e., if it is determined that the provider of the web activity history information is a legitimate user, the server (10) can initiate the recording of the web activity history information in the blockchain network (1000) (S3105).

[0141] Conversely, if it is determined that the encrypted information was not created by encrypting it using a blockchain secret key corresponding to the identification information, the server (10) may consider the web activity history information received in step (S3102) to have been created by a false third party or a false terminal, and, if there are no other conditions such as taking measures to send a notification to a legitimate user (S3106), may refuse to record the false web activity history information in the blockchain network (1000) (S3109).

[0142] This encrypted information collection process can prevent damage caused by false web activity history information during a security process to be performed later by blocking a third party who is not a genuine user from recording false web activity history information on the blockchain network (1000) while pretending to be the user. The false web activity history information of the third party may be information generated when the third party secretly performs web activities by obtaining the ID, password, etc. of a user registered in the third party system (20) without authorization.

[0143] In some embodiments, if the server (10) is set to require other conditions (S3106), and in a situation where recording of web activity history information as a result of the decryption should be rejected, instead of immediately rejecting the recording of web activity history information, the server (10) may send a notification to a recipient already matched with the identification information for the legitimate user (S3107). In this case, unlike the above-described case, since the terminal device (100) is not a terminal of the legitimate user corresponding to the identification information (e.g., an unregistered device), there may be a separate legitimate terminal corresponding to the identification information, and the server (10) may send a notification to the legitimate terminal already matched with the identification information. Alternatively, if the identification information indicates a specific user rather than a device such as a terminal, the server (10) may send a notification to the account of the specific user via email or a social network service (SNS). In this case, the notification may be transmitted in the form of an email, a short message service (SMS), or a pop-up message of an SNS application.

[0144] The server (10) receives a reply to the above notification, verifies whether the content of the received reply is positive or negative (S3108), and can approve or reject the recording of the web activity history information based on the content of the confirmed reply (S3105, S3109). Affirmation of the content means agreeing that the web activity history information is one's own. If a legitimate user confirms the legitimacy of the web activity history information through a reply (e.g., responds that he / she has legitimately transmitted the web activity history information through a newly used terminal device (100)) (i.e., responds positively), the server (10) will be able to approve the recording of the web activity history information (S3105). Conversely, if a legitimate user responds that the web activity history information is not legitimate (i.e., responds negatively), the server (10) will reject the recording of the web activity history information (S3109).

[0145] Meanwhile, if a response is received from a legitimate user indicating that the request is not legitimate, the server (10) may consider the terminal device (100) as an illegitimate terminal, and may be configured to automatically reject any subsequent requests from the terminal device (100) without sending a notification. In other words, the terminal device (100) may be included in a type of blacklist. This prevents the inconvenience of legitimate users receiving notifications every time the same illegitimate terminal transmits an illegitimate request multiple times.

[0146] The server (10) receives and decrypts the encrypted web activity history information from the first terminal device (100-1) or the third-party system (20) (S3105). In order to record the web activity history information of the terminal device in the blockchain of the blockchain network, the server decrypts the received encrypted web activity history information of the terminal device using the blockchain address corresponding to the identification information in the received web activity history information of the terminal device, and records the decrypted web activity history information of the terminal device in the blockchain. Specifically, the login history information and payment history information of the terminal device (100) are decrypted and recorded in the blockchain (S320, S330). In some embodiments, the server (10) transmits the user's web activity history information to the blockchain network (1000) as a transaction (S320). When multiple web activity history information is generated due to multiple web activities, multiple transactions representing each web activity history information can be transmitted to the blockchain network (1000) (S320).

[0147] Transmitting a transaction to the blockchain network (1000) in the above step (S320) means that the transaction is propagated to nodes participating in the blockchain network (1000). The propagated transaction is recorded in the distributed ledger of each node.

[0148] A new block is created on the blockchain network (1000) according to a consensus protocol, and the new block includes a transaction containing login history information or web activity history information (S330). Finally, the block created to record the user's login history information or web activity history information is added to the blockchain (S330). Thereafter, other nodes verify the added block, confirming that the block has been successfully added to the blockchain (S330).

[0149] A block can be added whenever an activity occurs, such as a login activity or a payment activity (S330). The block then contains historical information related to the activity.

[0150] After the user's web activity history information is recorded in the blockchain network (1000), the terminal device (100) performs a biometric authentication operation and transmits a request to the server (10). The server (10) can use the data recorded in the blockchain network (1000) to approve whether to process the request.

[0151] Since web activity history information is encrypted and transmitted to the server (10) in this manner (S310), the authentic web activity history of a legitimate user can be recorded on the blockchain without being contaminated by false web activity history information from a third party. As a result, the detection reliability of abnormal requests, as described below, is further improved.

[0152]

[0153] FIG. 5 illustrates a process by which a server collects encrypted web activity history information of a user according to various embodiments of the present application.

[0154] The embodiment of FIG. 5 is an embodiment related to receiving true web activity history information of a legitimate user from a second terminal device (100-2) in addition to the existing terminal device (100) of FIG. 4, i.e., the first terminal device (100-1), and additionally recording it in the blockchain network (1000). For example, there is a case where a user using the first terminal device (100-1) (e.g., a smartphone) requests the server (10) to create web activity history information and record it in the blockchain network (1000) through another terminal, i.e., a second terminal device (100-2) (e.g., a tablet PC, a desktop), which is another terminal possessed by the user, or there is a case where the first terminal to the nth terminal (n is a natural number greater than or equal to 2) (e.g., multiple computers) possessed by group members carrying out the project can access the server (10) with the same account. In addition, even if not mentioned separately, matters described in relation to FIG. 4 may also be applied to the embodiment of FIG. 5.

[0155] First, the server (10) can receive a request for use of a blockchain secret key corresponding to identification information indicating the first terminal device (100-1) or the user of the first terminal device (100-1) from the second terminal device (100-2) (S3111). This request is intended to enable the method of FIG. 4 to be performed not only by the first terminal device (100-1) but also by the second terminal device (100-2).

[0156] The server (10) can determine whether the above application is legitimate based on predetermined criteria. First, the server (10) can determine what identification information the second terminal device (100-2) has designated in relation to the above application (S3112). That is, it is necessary to determine whether the blockchain secret key that the second terminal device (100-2) wishes to use corresponds to the identification information indicating the first terminal device (100-1) or the user of the first terminal device (100-1). The intent for such designation may be included in the above application, or may be transmitted to the server (10) from the second terminal device (100-2) via a separate message.

[0157] Next, based on the designation of the above identification information, the server (10) may transmit a query to a recipient matched to the above identification information as to whether to allow the second terminal device (100-2) to use the blockchain secret key corresponding to the above identification information, i.e., the blockchain secret key for the first terminal device (100-1) (S3113). This recipient may be the first terminal device (100-1), but may also be the email address or SNS (social network service) account of the user of the first terminal device (100-1).

[0158] The server (10) can receive a response to the above query (S3114), and based on the received response, can determine whether the application by the second terminal device (100-2) is legitimate (S3115). Of course, the response is sent by the user of the first terminal device (100-1), and if the user of the first terminal device (100-1) indicates rejection through the response, the server (10) can consider the application by the second terminal device (100-2) to be illegitimate and disallow the application for a blockchain private key for the first terminal device (100-1) (S3116).

[0159] In contrast, if the user of the first terminal device (100-1) indicates his / her intent to approve through a reply, this indicates that the application by the second terminal device (100-2) was legitimately made by the user of the first terminal device (100-1), and therefore, the server (10) can control the first terminal device (100-1) to transmit the blockchain secret key for the first terminal device (100-1) to the second terminal device (100-2). At this time, the blockchain secret key can be transmitted directly from the first terminal device (100-1) to the second terminal device (100-2) without going through the server (10), for example, through P2P (peer-to-peer) communication. In this way, by transmitting the blockchain secret key between terminals without the server (10) intervening, the replication of the blockchain secret key can be performed more simply than in the conventional central management method.

[0160] In addition, since the transmission between terminals without going through the server (10) means that information regarding the blockchain secret key is not stored in the server (10), even if the server (10) is hacked, the blockchain secret key of the first terminal device (100-1) is not stolen, and as a result, higher security can be achieved.

[0161] Even so, there may still be concerns that the blockchain secret key may be stolen and used illegally when transmitted from the first terminal device (100-1) to the second terminal device (100-2). Accordingly, in one embodiment of the present invention, this problem is solved by encrypting the blockchain secret key of the first terminal device (100-1) using the blockchain address of the second terminal device (100-2).

[0162] Hereinafter, the steps according to the above method will be described. Separately from the first terminal device (100-1), the second terminal device (100-2) can also generate its own unique second blockchain address and second blockchain secret key (S3117). Since the second blockchain address can be made public, the server (10) can receive the second blockchain address of the second terminal device (100-2) from the second terminal device (100-2) (S3118). However, the second blockchain secret key of the second terminal device (100-2), which is private data, is stored only in the second terminal device (100-2) and is managed so as not to leak outside the second terminal device (100-2).

[0163] As explained above, information encrypted with the blockchain secret key of the second terminal device (100-2) can be decrypted using the blockchain address of the second terminal device (100-2), and information encrypted with the blockchain address of the second terminal device (100-2) can be decrypted using the blockchain secret key of the second terminal device (100-2).

[0164] Accordingly, the blockchain address of the second terminal device (100-2) can be used to determine whether any encrypted information is encrypted using the blockchain secret key of the second terminal device (100-2), and the blockchain secret key of the second terminal device (100-2) can be used to decrypt information encrypted using the blockchain address of the second terminal device (100-2).

[0165] The server (10) can transmit the blockchain address of the received second terminal device (100-2) to the first terminal device (100-1) (S3119), and can instruct the first terminal device (100-1) to encrypt its own blockchain secret key stored therein with the blockchain address of the second terminal device (100-2) and transmit the encrypted blockchain secret key to the second terminal device (100-2) (S3120). Then, the first terminal device (100-1) can encrypt its own blockchain secret key with the blockchain address of the second terminal device (100-2) (S3121), and transmit the encrypted blockchain secret key of the first terminal device (100-1) to the second terminal device (100-2) (S3122).

[0166] The encrypted information is web activity history information generated by the second terminal device (100-2).

[0167] In this way, the blockchain secret key of the first terminal device (100-1) encrypted with the blockchain address of the second terminal device (100-2) can be normally decrypted only using the blockchain secret key of the second terminal device (100-2). Therefore, even if an entity other than the second terminal device (100-2) storing the blockchain secret key of the second terminal device (100-2) steals the blockchain secret key of the first terminal device (100-1) encrypted with the blockchain address of the second terminal device (100-2), the stolen blockchain secret key of the first terminal device (100-1) cannot be used because the entity does not have the blockchain secret key of the second terminal device (100-2). Therefore, according to this method, the user's web activity history information can be recorded on the blockchain network (1000) with further improved security.

[0168] In addition, if the server (10) receives the web activity history information encrypted by the second terminal device (100-1) and successfully decrypts it (S310), it is confirmed that the web activity history information of the second terminal device (100-2) and the web activity history information of the first terminal device (100-1) both point to the web activity history information of the same user. Then, the server (10) can transmit the decrypted web activity history information of the second terminal device (100-2) as a transaction to the blockchain network (1000) to add a block including the transaction to the blockchain within the blockchain network (1000) (S330). Specifically, the server (10) receives web activity history information of the other terminal device, including identification information of the user, from the other terminal device - the web activity history information of the other terminal device is encrypted with the blockchain secret key corresponding to the identification information obtained without going through the server (S310), and decrypts the encrypted web activity history information of the other terminal device using the blockchain address information corresponding to the identification information, and when the decryption is successful and it is determined that the encrypted web activity history information of the other terminal device is encrypted using the blockchain secret key corresponding to the identification information, the decrypted web activity history information of the other terminal device can be recorded in the blockchain (S420, S430).

[0169] In this way, the number of providers of user web activity history information increases from the first terminal device (100-1) to the second terminal device (100-2), and further increases to two or more terminal devices (100). Consequently, the history information representing the true requests recorded in the blockchain network (1000) becomes richer, further improving the accuracy of detecting abnormal requests, as described below.

[0170]

[0171] The terminal device (100) that provides web activity history information in this manner authenticates the user, generates a request, and transmits it to the server (10). When the server (10) receives the request, it determines whether the received request is an abnormal request based on blockchain records on the blockchain network. If the request is not an abnormal request, it can approve the request from the terminal device. The request may be a login request or a payment request.

[0172] In various embodiments of the present application, determining whether the received request is an abnormal request based on a blockchain record on a blockchain network may include: when the server receives a request, generating a query condition for the request with at least some of the values ​​included in the request at the time of the request, and searching for block data having a value included in the query condition for the request with the query condition; calculating a matching rate between the web activity history information included in the searched block data and the information included in the request; and determining whether the request is an abnormal request based on the calculated matching rate. The searching for block data having a value included in the query condition for the request with the query condition may include calling a smart contract provided by nodes within the blockchain network, propagating the query condition for the request to a node capable of executing the smart contract, and executing the smart contract, thereby searching for block data having a value included in the query condition for the request from a distributed ledger stored in the node.

[0173] In various embodiments of the present application, the authentication result information includes the user's authentication probability value, and the step of determining whether the request is an abnormal request based on the calculated matching rate may be determining whether the request is an abnormal request based on a corrected matching rate obtained by applying the user's authentication probability value to the calculated matching rate.

[0174] In various embodiments of the present application, the step of retrieving block data having a value included in the query condition for the login request using the query condition may include the steps of: classifying values ​​included in the request at the time of the request into a first type of condition item or a second type of condition item according to a preset condition rule; generating a first query condition composed of values ​​for the first type of condition item among the values ​​at the time of the request; and retrieving block data having a value included in the first query condition from a distributed ledger stored in the node by propagating the first query condition to a node capable of executing the smart contract and executing the smart contract. The step of calculating a matching rate between the web activity history information included in the retrieved block data and the values ​​at the time of the request may include the step of calculating a first matching rate between information corresponding to the first query condition in the web activity history information included in the retrieved block data and information corresponding to the first query condition in the information included in the request. The step of determining whether the request is an abnormal request based on the calculated matching rate may be determining whether the request is an abnormal request based on the calculated first matching rate.

[0175] In various embodiments of the present application, the step of searching for block data having a value included in the query condition for the request with the query condition may further include the steps of: generating a second query condition composed of values ​​for condition items of the second type; selecting block data having a first matching rate that is greater than or equal to the first threshold matching rate; and searching for block data having a value included in the second query condition in the selected block data by propagating the second query condition and a block hash of the selected block data to a node capable of executing the smart contract as a query condition for the selected block data to execute the smart contract. The step of calculating a matching rate between the web activity history information included in the searched block data and the information included in the request may further include the step of calculating a second matching rate between information corresponding to the second query condition in the web activity history information included in the block data searched with both the first query condition and the second query condition and information corresponding to the second query condition in the information included in the request. The step of determining whether the request is an abnormal request based on the calculated matching rate may be determining whether the request is an abnormal request based on the calculated second matching rate.

[0176] In various embodiments of the present application, the first threshold matching rate may be set to a value corresponding to a narrower confidence interval than the second threshold matching rate, and the second threshold matching rate may be a threshold matching rate preset to be compared with the second matching rate.

[0177] In various embodiments of the present application, the server (10) may be further configured to generate new web activity history information indicated by the request and additionally record it on the blockchain network if the request is not determined to be an abnormal request. In this case, the step of determining whether the request is an abnormal request based on the calculated matching rate may further include the step of first verifying whether the request is an abnormal request based on the matching rate, and then analyzing a change in the matching rate over a certain period of time among past matching rates recorded in the blockchain network, and if it is analyzed that the matching rate sequentially decreases over a certain period of time and if it is not analyzed that the matching rate increases again after the sequential decrease, determining the request having a matching rate higher than the threshold matching rate as an abnormal request.

[0178] Below, a method for approving a request with multi-security and a system (1) for performing the same are described in more detail, with reference to embodiments where the request is a login request or a payment request.

[0179]

[0180] Multi-layer security for login requests

[0181] FIG. 6 illustrates a request approval process of the multi-security request approval system for a login request according to various embodiments of the present application.

[0182] The steps (S310 to S330) illustrated in Fig. 6 have been described above with reference to Fig. 3, and thus a detailed description thereof will be omitted.

[0183] Referring to FIG. 6, after recording the user's web activity history information in the blockchain network (1000) (S330), the terminal device (100) can generate a request to be transmitted to the server (10) (S410, S420, S430). While there may be various types of such requests as previously described, FIG. 6 will be described assuming that the request generated by the terminal device (100) is a login request.

[0184] The above terminal device (100) displays a login screen (S410), and when a command to initiate a login request is input (S420), the user can be authenticated through a built-in authentication program (S430).

[0185] FIG. 7 illustrates a process for generating a login request using biometric authentication according to various embodiments of the present application.

[0186] Referring to FIG. 7, the step of generating a login request includes a step (S410) in which the terminal device (100) displays a login screen; a step (S420) in which an initiation command for a login request is input through the login screen; a step (S430) in which biometric information of a user is acquired in response to the input of the command before generating the login request, and a step (S430) in which a biometric authentication operation is performed based on the acquired biometric information to authenticate the user who input the command, thereby generating authentication result information for the user; and a step (S440) in which a login request including the authentication result information, connection information of the terminal device (100) attempting the login request, and request information is generated and transmitted to the server (10).

[0187] The above login screen is a web page screen for requesting a login among web pages associated with the website. The login screen includes a button area (141) for generating a login request. When the button area (141) is selected, an operation for generating a login request can be initiated.

[0188] The above step (S430) may include a step of receiving a user's biometric information; a step of comparing the user's biometric information with biometric information pre-stored in the terminal device (100) to determine whether the user of the received biometric information is the user of the pre-stored biometric information, and a step of authenticating the user of the received biometric information.

[0189] In various embodiments of the present application, the operation of step (S430) may be performed through a biometric authentication program integrated into the OS of the terminal device (100) so that installation of a separate authentication application is unnecessary. If the command for initiating a login request is a command for executing a biometric authentication program, the user's biometric information is acquired and entered into the built-in biometric authentication program. Specifically, step (S430) may include a step of inputting the user's biometric information acquired from the terminal device (100) into a pre-installed biometric authentication program; and a step of acquiring authentication result information produced by the biometric authentication program.

[0190] The above biometric authentication program may include instructions that, when executed by a processor, perform the steps of comparing the user's biometric information with the user's biometric information stored in advance to determine whether there is a match between the biometric information; generating authentication result information indicating a successful authentication of the identity of the user of the acquired biometric information (i.e., the user attempting a login request) if the biometric information matches each other, and generating authentication result information indicating a failure in authentication of the user if the biometric information does not match.

[0191] The type of biometric information acquired by the terminal device (100) depends on the type of input data of the biometric authentication program. The biometric information may be, but is not limited to, a user's fingerprint or an image of the user's face.

[0192] In one example, as illustrated in FIG. 6, the biometric authentication program may be a face recognition-based authentication program. Then, the terminal device (100) may input a user's face image captured by a camera into the face recognition-based authentication program. The face recognition-based authentication program may include instructions that, when executed by a processor, cause the processor to perform the following steps: detecting face information from the user's face image; comparing the user's face information stored in advance with the detected face information to determine whether the user of the face image matches the user of the pre-stored face information; authenticating the user as the user of the face image being the user of the pre-stored face information if the user matches; and generating authentication result information indicating the user authentication result.

[0193] In various embodiments of the present application, the terminal device (100) can obtain the user's biometric information through a guide screen. As illustrated in FIG. 7, the guide screen can be configured to induce focusing on the facial area.

[0194] You can select other authentication methods through the above guide screen. These other authentication methods may be biometric authentication methods based on other biometric information, or non-biometric authentication methods. Non-biometric authentication methods may include, but are not limited to, passwords, PINs, or other text-based authentication methods.

[0195] The authentication result information may indicate that the user authentication failed because the acquired biometric information does not match the pre-stored biometric information, or that the user authentication succeeded because the acquired biometric information matches the pre-stored biometric information. In some embodiments, the authentication result information may further include an authentication probability value that the user of the acquired biometric information will be recognized as the user of the pre-stored biometric information.

[0196] When the above terminal device (100) generates the authentication result information through a biometric recognition program (S430), it generates the connection information and request information of the terminal device (100) at the time of the login request, and generates a login request including the authentication result information, connection information, and request information at the time of the login request of the terminal device (100) attempting the login request (S440).

[0197] The above connection information may be composed of the same items as the connection information included in the above web activity history information. The connection information may include one or more of the following information: connection location, connection device, connection device OS, connection browser, connection language, connection time, and connection website address.

[0198] The request information may include specific details of the request. For example, the login request information may indicate a desire to log in to a server (10) or a third-party system (20) using identification information.

[0199] Referring again to FIG. 6, the server (10) that received the login request can determine whether the login request is an abnormal request based on the blockchain record on the blockchain network (1000) (S450, S460).

[0200] FIG. 8 illustrates a blockchain-based anomaly detection process for a login request according to various embodiments of the present application.

[0201] Referring to FIG. 8, the server (10) receives a login request and acquires the authentication result information according to the login request of the terminal device (100) and the connection information at the time of the login request of the terminal device (100) (S440). The server (10) can determine whether to approve the login request even without acquiring the user's identification information.

[0202] The server (10) notifies at least one node on the blockchain network (1000) of the receipt of a login request, and searches for block data matching at least some of the access information at the time of the login request on the blockchain network (1000) (S450). The server (10) verifies whether the login request is an abnormal request based on the authentication result information and the matching rate between the searched access information and the access information in the login request (S460). The searched block data is block data having a value matching at least some of the access information at the time of the login request. The block data may include a transaction indicating a value matching at least some of the access information at the time of the login request.

[0203] In some embodiments, the server (10) may determine whether to initiate a search for the block data based on the authentication result information (S450). If the authentication probability value in the authentication result information is relatively low, the server may determine an abnormal request immediately without initiating a search for the block data (S460). In some embodiments, the server (10) may determine an abnormal request immediately without initiating a search for the block data if the authentication result information indicates a user authentication failure (S460).

[0204] In some embodiments, the node capable of executing the chaincode may be a server (10). Then, the server (10) can generate its own query conditions to retrieve block data.

[0205] In various embodiments of the present application, the step (S450) performed by the server (10) may include: when the server (10) receives a login request, a step of generating a query condition for the login request with at least some of the values ​​of the access information at the time of the login request in the login request; a step of searching for block data having a value included in the query condition for the login request with the query condition, calling a smart contract provided by nodes in the blockchain network (1000), and propagating the query condition for the login request to a node capable of executing the smart contract to execute the smart contract, thereby searching for block data having a value included in the query condition for the login request from a distributed ledger stored in the node.

[0206] The above step (S460) may include a step of calculating a matching rate between the connection information in the web activity history information included in the searched block data and the connection information at the time of the login request; and a step of determining whether the login request is an abnormal request based on the calculated matching rate.

[0207] A blockchain network (1000) can distribute and execute various smart contracts provided by various nodes. A smart contract is a protocol written in digital commands. When an event that complies with the terms of the protocol occurs on the blockchain network, a specific transaction can occur or another smart contract can be executed according to the established protocol.

[0208] Smart contracts can have a contract address (contract account). A contract address can be understood as the address where a node or other smart contract within a blockchain network generates a transaction to activate the smart contract. Upon receiving a transaction message, the contract address can perform the following actions (e.g., create a specific transaction, read a message, send a message to another account, or create another smart contract) according to the digital instructions defined by the internal protocol.

[0209] The above smart contract may be a chaincode provided by a private blockchain network (1000). The chaincode is a program that implements business logic executed on a private blockchain network, such as a Hyperledger blockchain network. The chaincode performs read or write operations on the blockchain's distributed ledger and may be written in a general programming language such as JavaScript.

[0210] In a Hyperledger blockchain network, chaincode is configured to perform functions such as processing transactions that update ledger information (e.g., state information) or querying ledger information (e.g., state information). When the chaincode is executed, ledger information can be queried.

[0211] The server (10) can generate query conditions for a login request before executing the chaincode. The query conditions may consist of values ​​for some or all of the connection items within the connection information. The connection items included in the query conditions may be set according to their security difficulty.

[0212] The server (10) may extract request values ​​corresponding to a preset condition set to generate a query condition for the login request. If the condition set includes a connection time zone, the server (10) may extract the connection time information value from the connection information in the request and change the connection time of the connection time information to the corresponding connection time zone. The changed connection time zone value is included in the query condition. In some embodiments, the server (10) may generate a connection time zone using a pre-stored time zone table. The time zone table may be a table recording the range of time zones. The range of time zones may be defined as a pair of different hours that do not overlap with each other. The range of time zones may be, but is not limited to, 1 hour, 3 hours, 4 hours, 6 hours, or 8 hours. The server (10) may search the time zone to which the connection time value belongs in the time zone table and use it as a condition value of the query.

[0213] The server (10) can calculate a matching rate for each piece of searched block data. The server (10) can calculate the matching rate by comparing the item-by-item values ​​of the connection information included in each piece of block data with the same item-by-item values ​​within the query conditions.

[0214] The server (10) determines whether the login request is an abnormal request based on the calculated matching rate. If the calculated matching rate is greater than or equal to a preset threshold matching rate, the server determines the login request is not an abnormal request. If the calculated matching rate is less than or equal to a preset threshold matching rate, the server determines the login request is an abnormal request.

[0215] The threshold matching rate can be set to a value that effectively prevents fraud and malicious activity while minimizing an uncomfortable user experience. For example, if 95% of legitimate users achieve a score of 70 or higher, the threshold can be set to 70.

[0216] In some embodiments, the step of determining whether the login request is an abnormal request based on the calculated matching rate may be determining whether the login request is an abnormal request based on the calculated matching rate and authentication result information within the login request. Specifically, the server (10) may determine whether the request is an abnormal request based on a corrected matching rate obtained by applying the user's authentication probability value to the calculated matching rate. The corrected matching rate is compared with the threshold matching rate to determine whether the login request is an abnormal request. For example, if the probability value is 0.9, a value obtained by multiplying the original matching rate by 0.9 may be compared with the threshold matching rate. In some embodiments, the threshold matching rate may be set based on statistical data to which the authentication probability value is applied. If the user authentication is successful but the authentication probability value is relatively low, the matching rate may be lowered by the lower probability, thereby increasing the likelihood that the login request will be determined as an abnormal request.

[0217] In various embodiments of the present application, the step (S450) may include a step of classifying the access information at the time of the login request into a first type condition item or a second type condition item according to a preset condition rule; generating a first query condition composed of values ​​for the first type condition item among the values ​​at the time of the login request; and propagating the first query condition to a node capable of executing the smart contract to execute the smart contract, thereby searching for block data having a value included in the first query condition in a distributed ledger stored in the node.

[0218] Then, the server (10) calculates a first matching rate between the information corresponding to the first query condition in the web activity history information included in the searched block data and the information corresponding to the first query condition in the connection information within the request (S460). In some embodiments, the server (10) may be configured to determine whether the login request is an abnormal request based on the calculated first matching rate in order to determine whether the request is an abnormal request based on the calculated first matching rate. The server (10) determines the login request as an abnormal request if there is no block data in which the calculated first matching rate is greater than or equal to a preset first threshold matching rate. That is, the server (10) may immediately determine the login request as an abnormal request based on the calculated first matching rate.

[0219] Alternatively, in some embodiments, the second type of condition items can be used to more reliably determine whether a login request is an abnormal request. Specifically, the step (S450) may further include: a step of generating, by the server (10), a second query condition composed of values ​​for the second type of condition items; a step of selecting block data having a first matching rate that is greater than or equal to a first threshold matching rate; and a step of searching for block data having a value included in the second query condition from the selected block data by propagating the second query condition and a block hash of the selected block data as a query condition for the selected block data to a node capable of executing the smart contract, thereby executing the smart contract. The server (10) may obtain a block hash value while selecting the block data. The obtained block hash value may be used to search for a block having the corresponding block hash value, and a block matching the second query condition may be finally searched for from the searched blocks.

[0220] Then, the step of calculating a matching rate between the web activity history information included in the searched block data and the information included in the request includes the step of calculating a second matching rate between information corresponding to the second query condition in the access information included in the web activity history information searched for block data with both the first query condition and the second query condition and information corresponding to the second query condition in the access information at the time of the login request. The server (10) may be configured to determine whether the login request is an abnormal request based on the calculated matching rate, based on the calculated second matching rate (S460).

[0221] In addition, the step of determining whether the login request is an abnormal request based on the second matching rate may be such that if there is block data for which the second matching rate for each block data is greater than or equal to a preset second threshold matching rate, the login request is determined not to be an abnormal request, and if there is no block data for which the second matching rate for each block data is greater than or equal to the second threshold matching rate, the login request is determined to be an abnormal request.

[0222] The condition items of the first type are items whose values ​​are relatively difficult to change in normal requests, not in abnormal requests. In normal requests, the condition items of the first type tend to have relatively identical or similar values. The condition items of the first type may be non-flexible items of the Hyperledger blockchain system among the connection information. For example, connection items such as connection location, connection device, connection device OS, connection language, or connection website address information among the connection information may be included as the first type of condition items in the query conditions for the login request. When a query is executed using the first query condition composed of values ​​for the condition items of the first type, candidate history information presumed to be a normal request in the past can be searched relatively quickly.

[0223] The second type of condition item is one whose value can be relatively easily changed even in normal requests, not in abnormal requests. In normal requests, the second type of condition item tends to have relatively different or dissimilar values. The second type of condition item may be a -Flexible item of the Hyperledge blockchain system among the connection information. For example, connection information items such as connection time (i.e., time zone, day of the week), connection site, and connection browser may be included in the query condition as the second type of condition item. When a query is executed using the second query condition composed of values ​​for the second type of condition item, the history information that best matches the current login request among the candidate history information initially guessed by the first query condition can be accurately retrieved.

[0224] In some embodiments, the first threshold matching rate may have a value corresponding to a narrower confidence interval than the second threshold matching rate. The confidence interval corresponding to the first threshold matching rate has a narrower interval than the confidence interval corresponding to the second threshold matching rate.

[0225] For example, the first threshold matching rate may correspond to a score that 95% of normal users have (e.g., 70 points), and the second threshold matching rate may correspond to a score that 99% of normal users have (e.g., 50 points). In other words, the first threshold matching rate can more strictly guarantee normal requests than the second threshold matching rate. A higher weight is set for the first query condition, which is relatively difficult to change, than for the second query condition, so that block data having a first matching rate higher than the first threshold matching rate can be designed to have a relatively low possibility of being determined as an abnormal request.

[0226] The server (10) can detect unexpected abnormal requests by performing a minimum of additional verification procedures using the second threshold matching rate.

[0227] If the above login request is determined to be a legitimate request and not an abnormal request, the server (10) can create new login history information including the user's access information, authentication result information, and request information included in the login request, and additionally record the created new login history information on the blockchain network (1000) (S470).

[0228] In the above step (S470), the server (10) transmits new login history information to the blockchain network (1000) as a transaction (S4720), so that a block including the transaction can be added to the blockchain (S4730). The operations of the above steps (S4720, 4073) correspond to the steps (S320, S330) of FIG. 3. That is, the step (S470) in which the server (10) records new login history information in the blockchain network (1000) (S4720, S4730) can be performed in the same principle as the step (S320, S330) in which past login history information is recorded in the blockchain network (1000) as web activity history information of FIG. 3, and thus a detailed description thereof will be omitted.

[0229] If the above login request is not determined to be an abnormal request, the server (10) can approve the login request (S480, S490). In one embodiment, if the server (10) has login approval authority for the website associated with the login screen, the server (10) can independently approve the login request of the terminal device (100) (S480). In another embodiment, if the server (10) does not have login approval authority for the website associated with the login screen and a third-party system (20) providing the website has login approval authority, the server (10) can approve the login request for the website associated with the login screen of the terminal device (100) by notifying the third-party system (20) of the approval fact of the request by sending an approval message notifying the fact of approval to the request (S480).

[0230] A terminal device (100) whose login request has been approved is allowed to perform the same activities as a user approved through a traditional login method such as ID and password on the website.

[0231] If the above login request is determined to be an abnormal request, the server (10) can notify the third-party system (20) of a disapproval message informing that the login request has been disapproved (S480).

[0232] In some embodiments, the server (10) may be further configured to first verify whether a login request is an abnormal request based on a matching rate, and then analyze the matching rate change over a certain period of time among the past matching rates recorded in the blockchain network (1000), and if a sequential decline in the matching rate over a certain period of time is analyzed and a re-increase in the matching rate after the sequential decline is not analyzed, determine the request having a matching rate higher than the threshold matching rate as an abnormal request (S460). The server (10) may not determine the request as an abnormal request even if the matching rate is higher than the threshold matching rate. This is because people's lives are generally regular, so even if they log in in an environment that is relatively less similar to their past login history, they will at some point log in in an environment that is very similar to their past login history. This takes into account that even if a person changes their lifestyle due to moving or changing jobs, they will return to a regular life after the moment of change has passed.

[0233] Through this multi-layer security, the request approval system (1) can securely approve login requests.

[0234]

[0235] Multi-layer security for payment requests

[0236] FIG. 9 illustrates a process for approving a request of the multi-security request approval system for a payment request according to various embodiments of the present application.

[0237] The steps (S310 to S330) illustrated in Fig. 9 have been described above with reference to Fig. 3, and thus a detailed description thereof will be omitted.

[0238] Referring to FIG. 9, after the user's web activity history information is recorded in the blockchain network (1000) (S330), the terminal device (100) can generate a request to be transmitted to the server (10) (S810, S820, S830). As described above, there may be various types of such requests, but FIG. 9 will be described assuming that the request generated by the terminal device (100) is a payment request. The request approval of FIG. 9 and the request approval of FIG. 6 are similar in operation, except that the requests are payment requests and login requests, respectively. Specifically, steps (S810 to S880) of FIG. 9 correspond to steps (S410 to S480) of FIG. 6. Therefore, the steps of FIG. 9 will be described mainly with respect to the differences compared to the steps of FIG. 6.

[0239] FIG. 10 illustrates a process for generating a payment request using biometric authentication according to various embodiments of the present application.

[0240] Referring to FIG. 10, the step of generating a payment request includes a step of displaying a payment screen by the terminal device (100) (S810); a step of receiving an initiation command for a payment request through the payment screen (S820); a step of obtaining user biometric information in response to the input of the command before generating the payment request, and performing a biometric authentication operation based on the obtained biometric information to authenticate the user who input the command, thereby generating authentication result information for the user (S830); and a step of generating a payment request including the authentication result information, connection information of the terminal device (100) attempting the payment request, and request information, and transmitting the payment request to the server (10) (S840).

[0241] The payment screen above is a web page for requesting payment among web pages associated with the website. The payment screen includes a button area (181) for generating a payment request. When the button area (181) is selected, a payment request is generated.

[0242] The above step (S830) may include a step of receiving a user's biometric information; a step of comparing the user's biometric information with biometric information pre-stored in the terminal device (100) to determine whether the user of the received biometric information is the user of the pre-stored biometric information, and a step of authenticating the user of the received biometric information.

[0243] The biometric authentication operation of the above step (S830) is identical in principle to the biometric authentication operation of step (S430) of FIGS. 6 and 7. The biometric authentication program and biometric authentication operation have been described above with reference to FIG. 7, and therefore a detailed description thereof will be omitted.

[0244] When the above terminal device (100) generates the authentication result information through a biometric recognition program (S830), it generates the connection information, request information, and payment information of the terminal device (100) at the time of the payment request, and generates a payment request including the authentication result information, connection information, request information, and payment information of the terminal device (100) attempting the payment request at the time of the payment request (S840).

[0245] The connection information within the payment request, like the connection information within the login request, may also be composed of the same items as the connection information contained in the web activity history information. The connection information may include one or more of the following: connection location, connection device, connection device OS, connection browser, connection language, connection time, and connection website address.

[0246] The request information may include specific details of the request. For example, the payment request information may indicate a desire to make a payment through a server (10) or a third-party system (20) using payment information included in the message.

[0247] Referring again to FIG. 9, the server (10) that received the payment request can determine whether the payment request is an abnormal request based on records on the blockchain network (1000) (S850, S860).

[0248] FIG. 11 illustrates a blockchain-based anomaly detection process for a payment request according to various embodiments of the present application.

[0249] Referring to FIG. 11, the server (10) receives a payment request and obtains the authentication result information according to the payment request of the terminal device (100), the connection information at the time of the payment request of the terminal device (100), and the payment information (S840).

[0250] The server (10) notifies at least one node on the blockchain network (1000) of the receipt of a payment request, and searches the blockchain network (1000) for block data representing at least a portion of the connection information and payment information at the time of the payment request (S850). In step (S850), some or all of the connection information and payment information items may be used as query items.

[0251] In various embodiments of the present application, the step (S850) performed by the server (10) may include: when the server (10) receives a payment request, generating a query condition for the payment request with at least some of the values ​​of the connection information at the time of the payment request in the payment request; searching for block data having a value included in the query condition for the payment request with the query condition, calling a smart contract provided by nodes in the blockchain network (1000) and propagating the query condition for the payment request to a node capable of executing the smart contract to execute the smart contract, thereby searching for block data having a value included in the query condition for the payment request in a distributed ledger stored in the node; calculating a matching rate between the connection information in the web activity history information included in the retrieved block data and the connection information at the time of the payment request; and determining whether the payment request is an abnormal request based on the calculated matching rate.

[0252] The server (10) can generate query conditions for payment requests before executing the chaincode. The query conditions for payment requests may consist of values ​​for some or all of the connection information and payment information combinations. The connection and payment items included in the query conditions may be set based on their security difficulty.

[0253] The server (10) may extract request values ​​corresponding to a preset condition set to generate a query condition for the payment request. If the condition set includes a payment amount range, the server (10) may extract the payment amount information value from the payment information in the request and change the payment amount information value to the corresponding payment amount. The changed payment amount range value is included in the query condition for the payment request. In some embodiments, the server (10) may generate a payment time zone using a pre-stored amount range table. The amount range table may be a table recording a range of amount ranges. The range of amount ranges may be defined as a pair of different amounts that do not overlap each other. The range of amount ranges may be defined equally in a specific amount unit, or may be defined unequally, such as less than or equal to 100,000 won, or between 100,000 won and 1 million won. The server (10) may search the amount range to which the payment amount value belongs in the amount range table and use it as a condition value for the query.

[0254] The server (10) can calculate a matching rate for each piece of searched block data. The server (10) can calculate the matching rate by comparing the item-by-item values ​​of the connection information included in each piece of block data with the same item-by-item values ​​within the query conditions.

[0255] The server (10) determines whether the payment request is an abnormal request based on the calculated matching rate. If the calculated matching rate is higher than a preset threshold matching rate, the server determines that the payment request is not an abnormal request. If the calculated matching rate is lower than a preset threshold matching rate, the server determines that the payment request is an abnormal request.

[0256] The threshold matching rate can be set to a value that effectively prevents fraud and malicious activity while minimizing an uncomfortable user experience. For example, if 95% of legitimate users achieve a score of 70 or higher, the threshold can be set to 70.

[0257] In some embodiments, the threshold matching rate may be changed depending on the payment amount. If the payment amount is relatively high, the server (10) may change the initially set threshold matching rate to a threshold matching rate corresponding to a narrower confidence interval than the confidence interval indicated by the initially set threshold matching rate. For example, if the initially set threshold matching rate is 70 points and the payment amount is relatively high, the threshold matching rate may be changed to 90 points. The server (10) may determine whether the payment request is an abnormal request based on the changed threshold matching rate (S860). In some embodiments, if the payment request includes a payment amount greater than a representative value (e.g., an average, a mode, or a median) of the payment amounts included in the searched block data, the server (10) may determine that the payment amount is relatively high and change the threshold matching rate.

[0258] In some embodiments, the server (10) may determine whether a payment request is an abnormal request by comparing a corrected matching rate obtained by applying the user's authentication probability value to the calculated matching rate with the threshold matching rate. For example, if the probability value is 0.9, a value obtained by multiplying the original matching rate by 0.9 may be compared with the threshold matching rate. In some embodiments, the threshold matching rate may be set based on statistical data to which the authentication probability value is applied. If the user authentication is successful but the authentication probability value has a relatively low probability, the matching rate may be lowered by the lower probability, thereby increasing the likelihood that the payment request will be determined as an abnormal request.

[0259] In various embodiments of the present application, the step (S850) of searching for the block data may include: a step of classifying the access information and payment information at the time of the payment request into a first type of condition item or a second type of condition item according to a preset condition rule; a step of generating a first query condition composed of values ​​for the first type of condition item among the values ​​of the access information and payment information at the time of the payment request; a step of propagating the first query condition to a node capable of executing the smart contract to execute the smart contract, thereby searching for block data having a value included in the first query condition in a distributed ledger stored in the node; a step of calculating a first matching rate between information corresponding to the first query condition in the web activity history information included in the retrieved block data and information corresponding to the first query condition in a combination of the access condition and payment information at the time of the payment request; and a step of determining whether the payment request is an abnormal request based on the calculated first matching rate. The server (10) may determine the payment request as an abnormal request if there is no block data in which the calculated first matching rate is greater than or equal to a preset first threshold matching rate.

[0260] In addition, in some embodiments, the step (S850) of searching for the block data may further include: a step of generating a second query condition composed of values ​​for the second type of condition items from among the values ​​of the connection information and payment information at the time of the payment request, i.e., a step of selecting block data having a first matching rate that is equal to or greater than a first threshold matching rate; a step of searching for block data having a value included in the second query condition from the selected block data by propagating the second query condition and the block hash of the selected block data to a node capable of executing the smart contract as a query condition for the selected block data and executing the smart contract. The server (10) may obtain a block hash value while selecting the block data. The obtained block hash value may be utilized to search for a block having the corresponding block hash value, and a block matching the second query condition may be finally searched for from the searched blocks.

[0261] Then, the step of calculating a matching rate between the web activity history information included in the searched block data and the information included in the request includes a step of calculating a second matching rate between the information corresponding to the second query condition in the access information and payment information in the web activity history information included in the block data searched for both the first query condition and the second query condition and the information corresponding to the second query condition in the access information and payment information at the time of the payment request. The server (10) may be configured to determine whether the payment request is an abnormal request based on the calculated matching rate, based on the calculated second matching rate (S860).

[0262] The above first type of condition item is an item whose value is relatively difficult to change in a normal request rather than an abnormal request, and may be a non-flexible item of the Hyperledge blockchain system among the above connection information. For example, connection items such as connection location, connection device, connection device OS, connection language, or connection website address information among the above connection information may be included in the query conditions as the first type of condition item. Among the above payment information, payment items such as payment currency, payment method, payment means, previous payment history, or number of payment attempts may be included in the query conditions for the payment request as the first type of condition item.

[0263] The second type of condition item is one whose value can be relatively easily changed even in normal requests, not in abnormal requests, and may be a flexible item of the Hyperledge blockchain system among the connection information. For example, connection information items such as connection time (i.e., time zone, day of the week), connection site, and connection browser may be included as the second type of condition item in the query condition. Payment items such as payment amount and payment product among the payment information may be included as the second type of condition item in the query condition for the payment request.

[0264] In some embodiments, the first threshold matching rate may have a value corresponding to a narrower confidence interval than the second threshold matching rate.

[0265] The server (10) can detect unexpected abnormal requests by performing a minimum of additional verification procedures using the second threshold matching rate.

[0266] If the above payment request is determined to be a legitimate request rather than an abnormal request, the server (10) may generate new payment details including the user's access information, authentication result information, and request information included in the payment request, and record the newly generated payment details on the blockchain network (1000) (S870). In some embodiments, the new payment details may further include a matching rate at the time of approval.

[0267] In the above step (S870), the server (10) transmits new payment history information to the blockchain network (1000) as a transaction (S8720), so that a block including the transaction can be added to the blockchain (S8730). The operations of the above steps (S8720, 8730) correspond to the steps (S320, S330) of FIG. 3. That is, the step (S870) in which the server (10) records new payment history information in the blockchain network (1000) (S8720, S8730) can be performed in the same principle as the step (S320, S330) in which past payment history information is recorded in the blockchain network (1000) as web activity history information of FIG. 3, and thus a detailed description thereof will be omitted.

[0268] If the payment request is not determined to be an abnormal request, the server (10) can approve the payment request (S880, S890). In one embodiment, if the server (10) has payment approval authority for the website associated with the payment screen, the server (10) can independently approve the payment request of the terminal device (100) (S880). In another embodiment, if the server (10) does not have payment approval authority for the website associated with the payment screen and a third-party system (20) providing the website has payment approval authority, the server (10) can approve the payment request for the website associated with the payment screen of the terminal device (100) by notifying the third-party system (20) of the approval fact for the request by sending an approval message notifying the fact of approval to the request (S880).

[0269] A terminal device (100) whose payment request has been approved is permitted to perform the same activities as a user approved using a traditional payment method such as an ID and password on the website.

[0270] If the above payment request is determined to be an abnormal request, the server (10) can notify the third-party system (20) of a disapproval message informing that the payment request has been disapproved (S880).

[0271] In some embodiments, the server (10) may be further configured to first verify whether a payment request is an abnormal request based on the matching rate, and then analyze the change in the matching rate over a certain period of time among the past matching rates recorded in the blockchain network (1000). If the matching rate is analyzed to sequentially decrease over a certain period of time and does not increase again after the sequential decrease, the request is determined to be an abnormal request even though the matching rate is above a threshold matching rate (S860). This is because people's lives are generally regular, so even if a payment was made in an environment relatively less similar to their past payment history, at some point the payment is made in an environment very similar to their past payment history. This takes into account that even if a person's lifestyle changes due to moving or changing jobs, they return to a regular life after the moment of change has passed.

[0272] These multi-layered security measures enable the request approval system (1) to securely approve payment requests. In particular, it can securely approve requests for automatic subscription payments that recur periodically and have a history of past payments.

[0273]

[0274] When implementing embodiments of the present invention using hardware, ASICs (application specific integrated circuits) or DSPs (digital signal processors), DSPDs (digital signal processing devices), PLDs (programmable logic devices), FPGAs (field programmable gate arrays), etc. configured to perform embodiments of the present application may be included as components of the present application.

[0275] The operations of the electronic prescription provision system and method according to the embodiments of the present application described above may be implemented, at least in part, as a computer program and recorded on a computer-readable recording medium. For example, the program product may be implemented together with a computer-readable medium containing program code, which may be executed by a processor to perform any or all of the described steps, operations, or processes.

[0276] The computer-readable recording medium includes all types of recording devices that store data that can be read by a computer. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. In addition, the computer-readable recording medium can be distributed across network-connected computer systems, so that computer-readable code can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the present embodiment will be readily understood by those skilled in the art to which the present embodiment pertains.

[0277] While the present invention has been described above with reference to the embodiments illustrated in the drawings, these are merely exemplary, and those skilled in the art will appreciate that various modifications and variations of the embodiments are possible. However, such modifications should be considered within the technical protection scope of the present invention. Therefore, the true technical protection scope of the present invention should be determined by the technical spirit of the appended claims.

[0278] The system and method for approving requests with multi-security of the present application utilizes a no-installation authentication technology and blockchain-based verification technology that authenticates users without installing a separate authentication app, enabling login, payment, and other requests to be approved, thereby improving user convenience while preventing risks, and thus is expected to have high industrial applicability.

Claims

1. A method for approving a request with multiple security, performed by a system including a terminal device and a server participating as a node in a blockchain network while communicating with the terminal device through a public network, A step of collecting web activity history information of a terminal device from the server - the web activity history information includes login history information and payment history information; A step of recording web activity history information of the terminal device into a blockchain on the blockchain network by the server; A step of authenticating a user through an authentication program built into the terminal device and generating a request and transmitting it to the server; When the above request is received from the above server, a step of determining whether the received request is an abnormal request based on the blockchain record on the blockchain network; and If the above request is not an abnormal request, a step of approving and processing the request of the terminal device is included. method.

2. In the first paragraph, the method, Before receiving the above web activity history information, the step of receiving the user's identification information, blockchain address information corresponding to the identification information, and encrypted verification information from the terminal, and, if it is determined that the encrypted verification information is encrypted using a blockchain secret key corresponding to the identification information, matching the provided blockchain address information to the user's identification information and storing it in the server; further comprising; The step of collecting web activity history information of the terminal device from the terminal device in the above server is: In the above terminal device, the web activity history information of the terminal device is encrypted and transmitted using a pre-stored blockchain secret key. The step of recording the web activity history information of the terminal device on the blockchain of the blockchain network by the server is as follows: Using a blockchain address corresponding to identification information in the received web activity history information of the terminal device, the server decrypts the received encrypted web activity history information of the terminal device and records the decrypted web activity history information of the terminal device in the blockchain. method.

3. In the second paragraph, the method, A step of receiving a request for use of a blockchain secret key corresponding to the identification information from a terminal device different from the terminal device; A step of determining whether the application of the other terminal device is legitimate based on preset criteria; and A step of controlling the terminal device so that, if the application of the other terminal device is determined to be legitimate, the terminal device transmits a blockchain secret key corresponding to the identification information to the other terminal device without going through the server; A step of receiving web activity history information of the other terminal device, including identification information of the user, from the other terminal device - the web activity history information of the other terminal device is encrypted with the blockchain secret key corresponding to the identification information obtained without going through the server; A step of decrypting the encrypted web activity history information of the other terminal device using the blockchain address information corresponding to the above identification information; and If the decryption is successful and it is determined that the encrypted web activity history information of the other terminal device is encrypted using a blockchain secret key corresponding to the identification information, a step of recording the decrypted web activity history information of the other terminal device on the blockchain is further included. method.

4. In paragraph 1, The above request is a login request or a payment request, The step of authenticating a user through an authentication program built into the terminal device and generating a request and sending it to the server is as follows: If the above request is a login request, a login request is created including the authentication result information produced by the built-in authentication program, the connection information at the time of the request, and the request information. If the above request is a payment request, it is characterized in that a payment request is created that additionally includes payment information at the time of the request. method.

5. In paragraph 1, The step of determining whether the above received request is an abnormal request based on the blockchain records on the blockchain network is as follows: When the server receives a request, a step of creating a query condition for the request with at least some of the values ​​included in the request at the time of the request, and searching for block data having the values ​​included in the query condition for the request with the query condition; A step of calculating a matching rate between the web activity history information included in the searched block data and the information included in the request; and A step of determining whether the request is an abnormal request based on the calculated matching rate is included, The step of retrieving block data having a value included in the query condition for the request using the above query condition is as follows: It is characterized in that it searches for block data having a value included in the query condition for the request from the distributed ledger stored in the node by calling a smart contract provided by nodes in the blockchain network, and propagating the query condition for the request to a node capable of executing the smart contract to execute the smart contract. method.

6. In paragraph 5, The above authentication result information includes the authentication probability value of the user, The step of determining whether the request is an abnormal request based on the above-mentioned calculated matching rate is as follows: Characterized in that it determines whether or not an abnormal request is made based on a corrected matching rate that applies the user's authentication probability value to the calculated matching rate. method.

7. In paragraph 5, The step of searching for block data having a value included in the query condition for the request using the above query condition is as follows: A step of classifying the values ​​included in the above request at the time of the request into a first type condition item or a second type condition item according to a preset condition rule; A step of generating a first query condition consisting of values ​​for the first type of condition item among the values ​​at the time of the request; and A step of searching for block data having a value included in the first query condition from a distributed ledger stored in the node by propagating the first query condition to a node capable of executing the smart contract and executing the smart contract, The step of calculating the matching rate between the web activity history information included in the above-mentioned searched block data and the values ​​at the time of the request is as follows: A step of calculating a first matching rate between information corresponding to a first query condition in the web activity history information included in the searched block data and information corresponding to the first query condition in the information included in the request; The step of determining whether the request is an abnormal request based on the calculated matching rate is as follows: Characterized in that it is determined whether the request is an abnormal request based on the calculated first matching rate. method.

8. In paragraph 7, The step of searching for block data having a value included in the query condition for the request using the above query condition is as follows: A step of generating a second query condition consisting of values ​​for the second type of condition items; A step of selecting block data having a first matching rate greater than or equal to the first threshold matching rate; A step of searching for block data having a value included in the second query condition in the selected block data by propagating the block hash of the second query condition and the selected block data to a node capable of executing the smart contract as a query condition for the selected block data and executing the smart contract; further comprising; The step of calculating the matching rate between the web activity history information included in the searched block data and the information included in the request is as follows: Further comprising a step of calculating a second matching rate between information corresponding to the second query condition in the web activity history information included in the block data searched for both the first query condition and the second query condition and information corresponding to the second query condition in the information included in the request; The step of determining whether the request is an abnormal request based on the calculated matching rate is as follows: Characterized in that it is determined whether the request is an abnormal request based on the calculated second matching rate. method.

9. In paragraph 8, The above first critical matching rate is set to a value corresponding to a narrower confidence interval than the second critical matching rate, The second critical matching rate is characterized in that it is a threshold matching rate preset to be compared with the second matching rate. method.

10. In paragraph 5, the method, If the above request is not determined to be an abnormal request, the method further includes a step of generating new web activity history information indicated by the request and additionally recording it on the blockchain network. The step of determining whether the request is an abnormal request based on the above-mentioned calculated matching rate is as follows: After first verifying whether the request is an abnormal request based on the matching rate, a step of analyzing the change in the matching rate over a certain period of time among the past matching rates recorded in the blockchain network, and if it is analyzed that the matching rate sequentially decreases over a certain period of time and if it is not analyzed that the matching rate increases again after sequentially decreasing, is further included in determining the request having a matching rate higher than the threshold matching rate as an abnormal request. method.

11. A computer-readable recording medium having recorded thereon a program for performing a method of approving a request with multiple security according to any one of claims 1 to 10.

12. In a server that participates as a node in a blockchain network while communicating with a terminal device through a public network, Collect web activity history information from the terminal device, and - the web activity history information includes login history information and payment history information; The web activity history information of the above terminal device is recorded in the blockchain of the above blockchain network, Receive a request generated by authenticating the user through an authentication program built into the terminal device, Determine whether the received request is an abnormal request based on the blockchain records on the blockchain network, and If the above request is not an abnormal request, the terminal device is configured to approve the request. Server.

Images