Information processing device, information processing method, and information processing program

The information processing device dynamically generates secret questions and adapts authentication methods based on user behavior logs and security policies, addressing reliability and flexibility issues in conventional authentication systems.

JP7742333B2Active Publication Date: 2025-09-19LY CORP
View PDF 13 Cites 0 Cited by

Patent Information

Application Number
JP2022069691
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2022-04-20
Publication Date
2025-09-19
Estimated Expiration
2042-04-20

AI Technical Summary

Technical Problem

Conventional authentication technologies lack an efficient method for dynamically creating secret questions for identity verification, leading to issues with reliability and security due to outdated personal attribute information and inflexible authentication methods.

Method used

An information processing device and method that dynamically generates secret questions based on user behavior logs, continuously manages personal attribute information, and adapts authentication methods to security policies by using a server device that integrates FIDO authentication with dynamic challenge creation and attestation mechanisms.

Benefits of technology

Enhances the reliability and flexibility of identity verification by continuously managing personal attribute information and adapting authentication methods to security policies, ensuring robust and secure access control.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007742333000005
    Figure 0007742333000005
  • Figure 0007742333000006
    Figure 0007742333000006
  • Figure 0007742333000007
    Figure 0007742333000007
Patent Text Reader

Abstract

To provide a technique to dynamically create a secret question in an authentication technology.SOLUTION: An information processing apparatus according to the present application comprises: a creation unit that, on the basis of a user's action log, dynamically creates a secret question and a correct answer for identification; and an authentication processing unit that collates a user's answer to the secret question with the correct answer to perform identification. For example, the authentication processing unit causes the user to input data of a document or an image obtained by the user in relation to a user's behavior as the user's answer to the secret question. The authentication processing unit collates a hash value based on the input data of the document or the image with a hash value stored in advance as the correct answer to perform identification.SELECTED DRAWING: Figure 9
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to an information processing device, an information processing method, and an information processing program. [Background technology]

[0002] A technology relating to authentication that uses an authentication device has been disclosed (see Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2020-141331 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the above-mentioned conventional technology, there is still room for improvement in the method of creating secret questions for identity verification in authentication technology.

[0005] The present application has been made in view of the above, and aims to provide a method for dynamically creating secret questions in authentication technology. [Means for solving the problem]

[0006] The information processing device according to the present application receives an access request from a user and kinds Activity log Select the event you are asking about. Extracting eventa generation unit that creates a question template in which one or more questions are determined from the list, determines a question item generation policy for generating secret questions, dynamically generates secret questions and correct answers for identity verification based on the question item generation policy, generates an authentication screen including the secret questions, and provides the authentication screen including the secret questions to the user as an authentication request; and an authentication processing unit that receives the answers to the secret questions entered by the user on the authentication screen, compares the received answers from the user with the correct answers created together with the secret questions, and determines that the authentication has been successful if they match, and provides the user with a result screen regarding the authentication result as an access response. [Effects of the Invention]

[0007] According to one aspect of the embodiment, a method for dynamically creating secret questions in authentication technology can be provided. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is an explanatory diagram showing an overview of an information processing method according to an embodiment. [Figure 2] FIG. 2 is a diagram showing an example of identity verification. [Figure 3] FIG. 3 is an explanatory diagram showing an overview of the identity service. [Figure 4] FIG. 4 is an explanatory diagram showing an outline of an embodiment in which personal identification is requested at the time of authentication. [Figure 5] FIG. 5 is an explanatory diagram showing an overview of the attestation mechanism. [Figure 6] FIG. 6 is an explanatory diagram showing an overview of authentication strength management. [Figure 7] FIG. 7 is an explanatory diagram illustrating an example of FIDO registration in authentication strength management. [Figure 8] FIG. 8 is an explanatory diagram showing an outline of an embodiment of re-execution of attestation. [Figure 9]FIG. 9 is an explanatory diagram outlining an embodiment of dynamic challenge creation. [Figure 10] FIG. 10 is an explanatory diagram showing an overview of an embodiment of delegation of authority for account recovery from a child to a parent. [Figure 11] FIG. 11 is a diagram illustrating an example of the configuration of an information processing system according to the embodiment. [Figure 12] FIG. 12 is a diagram illustrating an example of the configuration of a terminal device according to the embodiment. [Figure 13] FIG. 13 is a diagram illustrating an example of the configuration of a server device according to the embodiment. [Figure 14] FIG. 14 is a diagram illustrating an example of the user information database. [Figure 15] FIG. 15 is a diagram illustrating an example of the history information database. [Figure 16] FIG. 16 is a diagram illustrating an example of the authentication information database. [Figure 17] FIG. 17 is a flowchart showing a processing procedure according to the embodiment. [Figure 18] FIG. 18 is a diagram illustrating an example of a hardware configuration. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an information processing device, an information processing method, and an information processing program according to the present application (hereinafter referred to as "embodiments") will be described in detail with reference to the drawings. Note that the information processing device, the information processing method, and the information processing program according to the present application are not limited to these embodiments. Furthermore, the same components in the following embodiments will be denoted by the same reference numerals, and duplicated descriptions will be omitted.

[0010] [1. Overview of information processing method] First, an overview of an information processing method performed by an information processing device according to an embodiment will be described with reference to Fig. 1. Fig. 1 is an explanatory diagram showing an overview of an information processing method according to an embodiment. Note that Fig. 1 explains an example in which a method for dynamically creating secret questions is provided in authentication technology.

[0011] 1, the information processing system 1 includes a terminal device 10 and a server device 100. The terminal device 10 and the server device 100 are connected to each other via a network N (see FIG. 11) in a wired or wireless manner so as to be able to communicate with each other. In this embodiment, the terminal device 10 cooperates with the server device 100.

[0012] The terminal device 10 is a smart device such as a smartphone or tablet terminal used by a user U, and is a portable terminal device capable of communicating with any server device via a wireless communication network such as 4G (Generation (4G)) or LTE (Long Term Evolution) networks. The terminal device 10 has a screen such as a liquid crystal display with a touch panel function, and accepts various operations on displayed data such as content, such as tapping, sliding, and scrolling, performed by the user U with a finger or a stylus. An operation performed on an area of ​​the screen where content is displayed may be considered an operation on the content. The terminal device 10 may be not only a smart device, but also an information processing device such as a desktop PC (Personal Computer) or a notebook PC.

[0013] In this embodiment, the terminal device 10 functions as a FIDO client in FIDO authentication (Fast Identity Online). The FIDO client authenticates a user in cooperation with an authenticator. The authenticator may be implemented in the same device as the FIDO client (built-in authenticator), or may be implemented in a device physically different from the FIDO client (external authenticator).

[0014] For example, FIDO authentication can implement authentication methods using stored or possessed items such as PINs (Personal Identification Numbers), USB (Universal Serial Bus) security keys, and smart cards, as well as authentication methods using biometric or behavioral information such as fingerprints, faces, irises, veins, and voiceprints. Authentication methods are not limited to these, and any method can be implemented. Furthermore, multiple authentication methods can be combined to achieve multimodal biometric authentication or multifactor authentication.

[0015] For simplicity of explanation, the following description will be given assuming that the terminal device 10 is both a FIDO client and an authenticator, without distinguishing between the FIDO client and the authenticator. That is, the description will be given taking as an example a case where the authenticator is an internal authenticator. Note that, in reality, the authenticator may be an external authenticator that is physically independent from the terminal device 10 and can cooperate with the terminal device 10.

[0016] It is also possible to implement a Web authentication API (Application Programming Interface) that calls an authenticator from web content displayed in the FIDO client's web browser and enables FIDO authentication through interaction with the authentication server, but this description is omitted in this embodiment.

[0017] The server device 100 is an information processing device that functions as an authentication server (FIDO server) in FIDO authentication, and is realized by a computer, a cloud system, or the like. The authentication server corresponds to an RP (Relying Party) / IdP (Identity Provider). In FIDO authentication, no "secrets" such as passwords or biometric information are shared between an authenticator and the authentication server, making it resistant to phishing.

[0018] As shown in Figure 1, in FIDO authentication, when an authentication server receives an authentication request from a user, it sends a challenge to the authenticator on the user's side. The challenge is a random character string that is valid only once, and is a different data string each time determined based on random numbers. The user performs user verification using the authenticator and verifies their identity locally. The authenticator then signs the verification result with its private key and sends it to the authentication server as a signed response. When the authentication server receives the signed response, it verifies the signature with its public key.

[0019] In this way, with FIDO authentication, the authentication server uses a public key to verify that the authenticator on the user side has the appropriate private key, and the authenticator and authentication server do not share the "private key."

[0020] The server device 100 also functions as a federated RP / SP (Service Provider) that provides identity services through ID federation with RPs / IdPs that support FIDO authentication. When FIDO authentication and ID federation are combined, the authentication context is propagated from the authenticator to the federated RP / SP via the RP / IdP.

[0021] For simplicity of explanation, hereinafter, no distinction is made between the RP / IdP and the linked RP / SP, and the server device 100 is described as both the RP / IdP and the linked RP / SP. Note that in practice, the server device 100 as the RP / IdP and the server device 100 as the linked RP / SP may be different, physically independent server devices 100.

[0022] For example, the server device 100 may cooperate with the terminal device 10 of each user U and provide API (Application Programming Interface) services for various applications (hereinafter referred to as apps), etc., and various data to the terminal device 10 of each user U.

[0023] The server device 100 may also be an information processing device that provides some kind of online web service to the terminal device 10 of each user U. For example, the server device 100 may provide the following web services: internet connection, search service, social networking service (SNS), electronic commerce (EC), electronic payment, online games, online banking, online trading, hotel and ticket reservations, video and music distribution, news, maps, route search, route guidance, line information, operation information, and weather forecast. In practice, the server device 100 may cooperate with various servers that provide the above-mentioned web services and act as an intermediary for the web services or may be responsible for processing the web services.

[0024] The server device 100 can acquire user information about the user U. For example, the server device 100 acquires information about the attributes of the user U, such as the gender, age, and residential area of ​​the user U. The server device 100 then stores and manages the information about the attributes of the user U together with identification information (such as a user ID) that identifies the user U.

[0025] The server device 100 also acquires various types of history information (log data) indicating the behavior of the user U from the terminal device 10 of the user U or from various servers based on the user ID, etc. For example, the server device 100 acquires a location history, which is a history of the user U's location and date and time, from the terminal device 10. The server device 100 also acquires a search history, which is a history of search queries entered by the user U, from a search server (search engine). The server device 100 also acquires a browsing history, which is a history of content viewed by the user U, from a content server. The server device 100 also acquires a purchase history (payment history), which is a history of the user U's product purchases and payment processes, from an e-commerce server or a payment processing server. The server device 100 may also acquire a listing history and a sales history, which are a history of the user U's listings on the marketplace, from the e-commerce server or the payment processing server. The server device 100 also acquires a posting history, which is a history of the user U's posts, from a posting server or SNS server that provides a word-of-mouth posting service. The various servers and the like described above may be the server device 100 itself. That is, the server device 100 may function as the various servers and the like described above.

[0026] [1-1. Personal strength management] As shown in FIG. 2, a typical authentication system verifies whether a user is the real person through identity proofing. FIG. 2 is a diagram showing an example of identity proofing. In identity proofing, the user is deemed to be the real person by confirming that the attribute information previously registered by the user matches the presented attribute information. The server device 100 can provide a personalized identity service specific to the user, assuming that identity proofing has been properly performed. For example, the user's self-reported attribute information has low identity verification strength, and therefore cannot provide services that require high identity accuracy.

[0027] Furthermore, the reliability of a user's personal attribute information varies depending on the method of identity verification, and the reliability of the information decreases over time due to reasons such as the information becoming outdated and management information not being updated to correspond to the actual personal attribute information. Therefore, it is difficult to properly maintain the reliability of the information using conventional technology.

[0028] Furthermore, security policies are subject to frequent changes due to technological advances, the discovery of vulnerabilities, social demands, corporate policies, and so on.

[0029] As shown in Fig. 3, in this embodiment, the server device 100 continuously manages personal attribute information used for identity verification (personal identity verification) so as to satisfy a security policy. Fig. 3 is an explanatory diagram showing an overview of the identity service.

[0030] For example, the server device 100 appropriately and continuously manages the reliability of personal attribute information, and when controlling access to provide identity services, if the information does not satisfy the security policy, the server device 100 initiates new authentication or identity verification processing to satisfy the security policy.

[0031] During access control for providing identity services, the server device 100 calculates the attribute certainty for the online user currently being authenticated by multiplying the authentication certainty by the identity certainty. If the authentication certainty is p1 and the identity certainty is p2, the attribute certainty for the online user currently being authenticated is expressed by the following formula (1). Here, as an example, both probabilities are multiplied.

[0032]

number

[0033] If the original identity accuracy is low, the attributes linked to the ID are not reliable. If the authentication accuracy is weak, there is a possibility that the ID linked to the user is not appropriate (spoofing) in the first place. If ID: id, user: u, attribute: A, authentication accuracy: p1, identity accuracy: p2, the evaluation function is expressed by the following formula (2). Here, "*" means multiplication, and any operation can be defined.

[0034]

number

[0035] As shown in Figure 3, a link L1 between a user u and an ID id is established after each successful authentication attempt (authentication session). Once the validity period of the authentication session has expired, the strength of the link L1 becomes 0. The strength of this link L1 indicates the authentication certainty p1.

[0036] Attribute: A is managed by the authentication server. Attribute: A is a set of attributes (a1, a2, ...a n ) has strength as a whole. Attribute: A may have strength for each individual attribute, but it depends on the form of the identity verification document (identification document).

[0037] Furthermore, a link L2 between ID: id and attribute: A is established during identity verification. The strength of this link L2 changes (attenuates, increases, etc.) depending on the type of attribute. The strength of this link L2 indicates identity accuracy: p2.

[0038] In addition, the link L3 between ID:id and authentication information:password can also be considered one of the strengths of identity, but since it is set by the person who created the ID (or the administrator), the accuracy can be considered to be 1.

[0039] In this way, the server device 100 calculates the accuracy of personal attribute information for an online user currently being authenticated by multiplying the authentication accuracy by the identity accuracy. The authentication accuracy becomes 0 once the validity period of the authentication session established after each successful authentication attempt has expired. The identity accuracy varies depending on the type of personal attribute information.

[0040] [1-1-1. Identity management function] (1) Managing user attributes The server device 100, which is an authentication server, manages user attributes. For example, the server device 100 performs life cycle processes such as registration, update, and deletion.

[0041] (2) Management of attribute meta information The server device 100 also manages meta information of the attributes in association with the user attributes. For example, the server device 100 manages the identity verification method, identity verification document, meta information of the identity verification document (such as issuer), identity verification date and time, etc., used to obtain the user attributes.

[0042] (3) Identity verification management The server device 100 also manages the identity accuracy. For example, the server device 100 calculates it using a predetermined evaluation function using the above attributes and meta information, and manages it continuously. The server device 100 updates it periodically, or triggers it when necessary, such as when access control is required. At this time, the server device 100 performs evaluation that takes decay into account. The server device 100 may also use a security policy to describe and control how the identity accuracy information is managed. For example, the server device 100 updates it daily. Alternatively, the server device 100 may issue an alert if the validity period of the identity verification document has expired, or may request (ask) that identity verification be performed during authentication. Alternatively, the server device 100 may decrement the identity accuracy by 0.01 every day (from the date of issuance of the identity verification document).

[0043] [1-1-2. Identity verification required during authentication] An embodiment in which personal identification is requested at the time of authentication will be described with reference to Fig. 4. Fig. 4 is an explanatory diagram showing an overview of an embodiment in which personal identification is requested at the time of authentication.

[0044] As shown in Fig. 4, a user U uses a terminal device 10 to perform authentication using an ID and password with a server device 100, which is an authentication server, via a network N (see Fig. 11) (step S1). Note that this authentication may be performed in advance. For example, the user U may remain logged in to the server device 100 after being initially authenticated.

[0045] Next, the user U uses the terminal device 10 to transmit a service request to the server device 100, which is an authentication server, via the network N (see FIG. 11) (step S2).

[0046] Next, the server device 100, which is an authentication server, calculates the authentication certainty, the identity certainty, and an evaluation function in response to a service request from the user U, who is a user (step S3).

[0047] Next, the server device 100, which is an authentication server, has an identity management function, refers to the security policy, makes a control decision, and decides to implement a request for identity verification of the user U based on the security policy and the control decision (step S4). For example, if the identity verification document is a driver's license (paper copy) and the expiration date is December 2021, the server device 100 requests identity verification based on the security policy if the attribute information has expired.

[0048] Next, the server device 100, which is the authentication server, transmits a service response including an error indicating that the attribute information does not satisfy the security policy and a request for new identity verification processing to the terminal device 10, which is the authenticator, via the network N (see FIG. 11) (step S5). In this embodiment, the terminal device 10, which is the authenticator, is the terminal device 10 of the user U, who is the user. At this time, the server device 100, which is the authentication server, transmits a challenge to the terminal device 10, which is the authenticator.

[0049] Next, the terminal device 10 as an authenticator acquires attribute information included in an identification card (driver's license, My Number card, etc.) of the user U in response to a service response from the server device 100 as an authentication server (step S6). At this time, the terminal device 10 may request the user U to input the attribute information included in the identification card and accept the input of the attribute information. The method of inputting the attribute information is not limited to manual input, but may also be data upload, image data scanning and image analysis, voice input, etc. Alternatively, the terminal device 10 may extract attribute information stored internally.

[0050] Next, the terminal device 10 as the authenticator transmits a service request including a pair (set) of ID and attribute information to the server device 100 as the authentication server via the network N (see FIG. 11) (step S7). At this time, the terminal device 10 as the authenticator signs the challenge from the server device 100 using the authentication private key and transmits it.

[0051] Next, in response to a service request from the terminal device 10 acting as an authenticator, the server device 100 acting as an authentication server checks the identity verification document of the user U based on the ID and attribute information of the user U, updates the data if there are any changes, and verifies compliance with the security policy (step S8). At this time, the server device 100 acting as an authentication server verifies the signature of the signed challenge from the terminal device 10 acting as an authenticator using the authentication public key.

[0052] Next, the server device 100, which is the authentication server, transmits a service response indicating OK to the terminal device 10, which is the authenticator, via the network N (see FIG. 11) (step S9).

[0053] The accuracy function for personal identification may take into consideration that the accuracy of data decreases over time.

[0054] It is also possible to introduce the concept of risk-based authentication. For example, if the usage environment is different from usual, the threshold value can be set higher (or a security policy can be created to that effect).

[0055] The security policy may also be as follows: (1) If the evaluation function is lower than a predetermined threshold, identity verification is required. (2) If the user's self-declaration of attributes is entered (first entry or update), the relevant identification documents will be requested. (3) If the user self-declares their attributes, they are registered as not having identification documents.

[0056] In this manner, in this embodiment, the server device 100 verifies the identity of the user by confirming that the personal attribute information previously registered by the user matches the personal attribute information presented by the user. The server device 100 then continuously manages the registered personal attribute information used for identity verification so as to satisfy the security policy.

[0057] At this time, when controlling access to provide an identity service to a user, if the personal attribute information does not satisfy the security policy, the server device 100 initiates new authentication and identity verification processing to satisfy the security policy.

[0058] As a result, the server device 100 suppresses variations in the reliability of the personal attribute information due to differences in identity verification methods and continuously manages the reliability of the personal attribute information based on the security policy. Also, the server device 100 suppresses a decrease in the reliability of the personal attribute information over time and continuously manages the reliability of the personal attribute information based on the security policy.

[0059] Furthermore, when the security policy is changed, the server device 100 continuously manages the personal attribute information so that the personal attribute information satisfies the changed security policy.

[0060] In addition, if the identity verification document that is the basis for the registered personal attribute information has expired or if the identity verification document has expired, the server device 100 determines that the personal attribute information does not satisfy the security policy and initiates new authentication and identity verification processing to satisfy the security policy.

[0061] [1-2. Authenticator Management] In this embodiment, an authentication system is realized that can manage authenticator birth certificate documents (attestation) and change the authentication method.

[0062] With reference to Figure 5, we will explain how an authentication server determines the reliability of an authenticator using an authenticator birth certificate document (attestation) in normal (conventional) FIDO authentication. Figure 5 is an explanatory diagram showing an overview of the attestation mechanism.

[0063] As shown in Fig. 5, an authentication device vendor generates and distributes a key pair (private key, public key) for attestation at the time of shipment. In this embodiment, the authentication device vendor or the like stores the attestation private key in the authentication device at the time of shipment. The server device 100, which is an authentication server, obtains the attestation public key in advance from the authentication device vendor or the like.

[0064] Furthermore, when registering the authenticator, the user allocates an authentication key pair using an attestation key pair. In this embodiment, the terminal device 10 as the authenticator generates an authentication key pair when registering the authenticator. Then, the terminal device 10 as the authenticator registers and stores an authentication private key. Furthermore, the terminal device 10 as the authenticator sends an authentication public key to the server device 100 as the authentication server together with / included in data signed with the attestation private key (signed data). The server device 100 as the authentication server verifies the signature of the signed data received from the terminal device 10 as the authenticator using the attestation public key, and if successful, registers and stores the authentication public key received from the terminal device 10 as the authenticator.

[0065] However, in standard FIDO authentication, when a user registers a FIDO authenticator using the attestation mechanism, the authentication method cannot be changed even if the security policy of the authentication server changes afterwards. This is because the basis for the user's authentication accuracy is the attestation document.

[0066] Therefore, in this embodiment, the server device 100, which is an authentication server, stores and manages the user's attestation document received at the time of FIDO registration.

[0067] [1-2-1. Authentication strength management] An overview of authentication strength management will be described with reference to Fig. 6. Fig. 6 is an explanatory diagram showing an overview of authentication strength management.

[0068] As shown in Figure 6, a link L1 between a user u and an ID id is established after each successful authentication attempt (authentication session). Once the validity period of the authentication session has expired, the strength of the link L1 becomes 0. The strength of this link L1 indicates the authentication accuracy p1.

[0069] The authentication certainty: p1 is based on the public key reliability strength. That is, if a public key is created with a low-reliability attestation, the authentication strength for each authentication attempt will be low.

[0070] Note that the link L2 between ID:id and attribute:A is not relevant when managing authentication strength. In other words, identity certainty:p2 is not taken into consideration. However, in reality, there may be an option to manage authentication strength by combining identity certainty:p1 and identity certainty:p2.

[0071] Furthermore, the link L3' between the ID: id and the authentication information: public key indicates the reliability of the public key. Authentication information: The public key is set during FIDO registration. The authenticator's birth certificate (attestation document) is used as a measure of its trustworthiness.

[0072] The authenticator birth certificate (attestation document) certifies the authenticity of the authenticator / device that created the public key. The authenticity strength of the public key is determined by its contents.

[0073] In this embodiment, the server device 100, which is an authentication server, has an authentication device birth certificate management function and an authentication strength management function in addition to a FIDO registration function and a FIDO authentication function.

[0074] [1-2-2. FIDO Registration] An embodiment of FIDO registration in authentication strength management will be described with reference to Fig. 7. Fig. 7 is an explanatory diagram showing an overview of an embodiment of FIDO registration in authentication strength management.

[0075] As shown in FIG. 7, the server device 100, which is an authentication server, transmits a challenge, which is a random character string, as an authentication request to the terminal device 10, which is an authenticator (step S11).

[0076] Next, in response to an authentication request from the authentication server, the terminal device 10 as the authenticator performs user verification on the user U using a predetermined authentication means such as biometric authentication (step S12).

[0077] Next, if the user verification is successful, the terminal device 10 as the authenticator signs the challenge from the authentication server with the attestation private key 1 that it holds, generates an authentication key pair (authentication private key 1, authentication public key 1), and stores the authentication private key 1 (step S13).

[0078] Next, the terminal device 10 as the authenticator transmits the signed challenge, the authentication public key 1, and the attestation document 1 as an authentication response to the authentication request to the server device 100 as the authentication server (step S14).

[0079] Next, in response to the authentication response from the authenticator, the server device 100, which is the authentication server, verifies the signature of the signed challenge using the attestation public key 1 that it holds, and stores the authentication public key 1 (step S15).

[0080] In practice, the server device 100, which is the authentication server, may store the authentication public key 1 only when the signature verification is successful.

[0081] Next, if the signature verification is successful, the server device 100, which is the authentication server, extracts the user ID indicating the user U (step S16).

[0082] Next, the server device 100, which is the authentication server, stores the attestation document 1 in association with the extracted user ID (step S17). Note that the attestation document is an example of something that evaluates the authentication strength.

[0083] [1-2-3. Re-implementation of attestation] When the server device 100, which is an authentication server, decides to strengthen security and finds that the attestation document 1 of the user that is already stored does not satisfy the authentication strength (level), it re-performs attestation that satisfies the set strength.

[0084] For example, suppose a vulnerability is found in the currently used authenticator A. Then, suppose the security policy is updated to not allow authentication requests from the buggy authenticator A. In this case, when an authentication request is received from a user using authenticator A, the system prompts the user to update the firmware for authenticator A, and at the same time prompts the user to re-register with the updated authenticator A and update the attestation document. Alternatively, the system prompts the user to re-register with a new authenticator B and update the attestation document.

[0085] An embodiment of attestation re-execution will be described with reference to Fig. 8. Fig. 8 is an explanatory diagram showing an overview of an embodiment of attestation re-execution.

[0086] As shown in FIG. 8, the server device 100, which is the authentication server, refers to the user's authentication device birth certificate document (attestation document) in advance, and if it is found to be insufficient in strength, it is set to prompt re-registration at the next or subsequent authentication opportunity (step S20).

[0087] Then, at the opportunity for authentication, the server device 100, which is the authentication server, transmits a challenge, which is a random character string, as an authentication request to the terminal device 10, which is the authenticator, and prompts the user to re-register the authenticator birth certificate document (step S21).

[0088] Next, in response to an authentication request from the authentication server, the terminal device 10 as the authenticator performs user verification on the user U using a predetermined authentication means such as biometric authentication (step S22).

[0089] Next, if the user verification is successful, the terminal device 10 as the authenticator signs the challenge from the authentication server with the attestation private key 2 that it holds (step S23).

[0090] For example, when the firmware of the currently used authenticator A is updated (or the authentication application is updated) or when a new authenticator B is started to be used, the terminal device 10 serving as the authenticator will be in a state where it stores an attestation private key 2 that is different from the attestation private key 1. In other words, the authenticator vendor or the like will be in a state where a new attestation key pair (private key, public key) has been generated and distributed.

[0091] At this time, the terminal device 10 as the authenticator may delete the authentication private key 1 that it holds. This requires the above-mentioned FIDO registration to be performed again (see FIG. 8). That is, after re-performing this attestation, the terminal device 10 as the authenticator performs FIDO registration again and generates and distributes a new authentication key pair. Furthermore, the terminal device 10 as the authenticator may delete the attestation private key 1 if an attestation private key 1 that does not satisfy the authentication strength (level) remains inside.

[0092] Next, the terminal device 10 as the authenticator transmits the signed challenge and the attestation document 2 as an authentication response to the authentication request to the server device 100 as the authentication server (step S24).

[0093] Next, in response to the authentication response from the authenticator, the server device 100, which is the authentication server, verifies the signature of the signed challenge using the attestation public key 2 that it holds (step S25).

[0094] It is assumed that the server device 100, which is an authentication server, acquires and stores the paired attestation public key 2 when the terminal device 10, which is an authenticator, stores (or becomes able to acquire) the attestation private key 2. For example, the server device 100, which is an authentication server, acquires and stores the attestation public key 2 from an authenticator vendor or the like.

[0095] Next, if the signature verification is successful, the server device 100, which is the authentication server, extracts the user ID indicating the user U (step S26).

[0096] Next, the server device 100, which is the authentication server, stores the attestation document 2 in association with the extracted user ID, and updates the authenticator birth certificate document (step S27).

[0097] At this time, the server device 100, which is the authentication server, may discard (delete) the attestation document 1 that was linked to the user ID. For example, the server device 100, which is the authentication server, may overwrite the attestation document 1 that was linked to the user ID with the attestation document 2.

[0098] This allows the strength (level) of personal identification to be flexibly changed to satisfy the security policy even if the security policy changes. Also, the strength of personal identification can be adjusted to match the security policy without changing the user authentication process (procedure).

[0099] In this manner, in this embodiment, the server device 100, which is an authentication server, determines the reliability of the authenticator based on the attestation document and performs FIDO authentication with the trusted authenticator. To this end, the server device 100 stores the attestation document and continuously manages the authentication strength of the attestation document.

[0100] For example, when the server device 100 decides to strengthen security and the attestation document already stored does not satisfy the authentication strength, the server device 100 re-performs attestation to satisfy the authentication strength. Alternatively, the server device 100 re-performs attestation if the authenticator no longer satisfies the security policy due to the passage of time or the discovery of a problem. Alternatively, the server device 100 re-performs attestation if the authenticator no longer satisfies the security policy due to a change in the security policy.

[0101] The server device 100 also determines the reliability of the public key based on the contents of the attestation document. The server device 100 verifies the signature created using the private key of the authenticator with the public key corresponding to the private key. At this time, the server device 100 manages the reliability of the public key, and requests a change of the public key if the reliability of the public key has decreased.

[0102] For example, the server device 100 determines that the reliability of the public key has decreased over time and requests that the public key be changed. Alternatively, if the public key has expired, the server device 100 determines that the reliability of the public key has decreased and requests that the public key be changed. Furthermore, if the reliability of the public key does not satisfy the security policy, the server device 100 determines that the reliability of the public key has decreased and requests that the public key be changed.

[0103] [1-3. Creating dynamic secret questions] The information used to verify identity must be registered in advance, which is time-consuming, and unless it is registered, it is not possible to verify the identity of the person.

[0104] Therefore, in this embodiment, a "secret question" (a question specific to the user) for identity verification is dynamically generated. For example, the "secret question" for the user is dynamically generated based on the user's behavior log.

[0105] An embodiment of dynamic secret question generation will be described with reference to Fig. 9. Fig. 9 is an explanatory diagram showing an overview of an embodiment of dynamic secret question generation.

[0106] As shown in FIG. 9, the server device 100, which is an authentication server, analyzes the log of a user U in advance and generates a question template (step S30).

[0107] The terminal device 10 of the user U sends an access request including a user ID indicating the user U to the server device 100, which is an authentication server (step S31).

[0108] Next, the server device 100, which is an authentication server, generates questions and answers for the user U in response to an access request from the terminal device 10 of the user U, and also generates an authentication screen (including the questions) (step S32).

[0109] Next, the server device 100, which is the authentication server, provides (displays) an authentication screen including a question as an authentication request to the terminal device 10, which is the authenticator (step S33).

[0110] Next, the user U inputs an answer to a question included in the authentication screen displayed on the terminal device 10 serving as the authentication device (step S34).

[0111] Next, the terminal device 10 as the authenticator transmits the answer input by the user U as an authentication response to the authentication request from the server device 100 as the authentication server (step S35).

[0112] Next, the server device 100, which is the authentication server, verifies the response from the terminal device 10, which is the authenticator, and generates a result screen regarding the authentication result (step S36).

[0113] For example, the server device 100, which is an authentication server, compares the answer created together with the question with the answer from the terminal device 10, which is an authenticator, and determines the authentication result as successful if they match. Note that a perfect match is not required, and partial matches may also be acceptable.

[0114] Next, the server device 100, which is the authentication server, transmits a result screen relating to the authentication result or a request screen as an access response to the terminal device 10, which is the authenticator (step S37).

[0115] [1-3-1. Log analysis] In this embodiment, the server device 100, which is an authentication server, identifies the format of the action log of the user U, who is a user.

[0116] For example, the server device 100 identifies a purchase history, which is a history of product purchases and service usage by the user U. The server device 100 also identifies a posting history, which is a history of posts by the user U to an SNS. The server device 100 also identifies a payment history, which is a history of electronic payments made using a payment app on the terminal device 10.

[0117] Then, the server device 100, which is an authentication server, identifies and extracts question items from the action log whose format has been identified.

[0118] For example, the server device 100 identifies and extracts, from the purchase history of the user U, the date and time, product, price, product model / brand, product type, purchase store, frequency, pattern, frequently purchased store, period, etc. from multiple purchase histories as question items.

[0119] In addition, the server device 100 identifies and extracts, from the user U's SNS posting history, the date and time, the person with whom the user communicated, the posting destination, the content of the conversation, the frequency and pattern of multiple posts, the person with whom the user frequently converses, etc., as question items.

[0120] In addition, the server device 100 identifies and extracts, from the payment history of the user U, the date and time, store, amount, frequency and pattern of multiple transactions, frequently visited stores, etc. as question items.

[0121] Alternatively, the server device 100, which is an authentication server, may identify data question items using a statistical analysis method such as machine learning, instead of searching in a predetermined log format.

[0122] Furthermore, the server device 100, which is the authentication server, may add questions identified by a statistical analysis method to the questions selected in advance and use them from the next time onwards.

[0123] [1-3-2. Question Creation] (1) Extraction of question logs The server device 100, which is an authentication server, extracts one event that is the subject of the question from the data set of the behavior log of the user U. For example, the server device 100 extracts an event from the purchase history of the user U, such as "At 3:15 PM on January 14, 2022, one item of product BBB (priced at 5,000 yen) was purchased from the AAA store of Y Shopping."

[0124] (2) Creating a question template The server device 100, which is an authentication server, creates a question template in which one or more question items are determined from the question target log. For example, if the server device 100 determines the purchase date and time (time) as a question item, it creates a question template such as "At time xxxx, one PC BBB (priced at 5,000 yen) was purchased from the AAA store of Y Shopping."

[0125] (3) Determining the question generation policy The server device 100, which is an authentication server, determines a policy for generating questions (question item generation policy). For example, the server device 100 determines a policy for generating questions, such as free text or multiple-choice format with vague time periods.

[0126] (4) Question and answer generation The server device 100, which is an authentication server, generates questions and their answers (correct answers) in accordance with a question item generation policy. For example, the server device 100 generates the question "Around what time did you buy electrical appliances at Y Shopping?" with answer options "(a) 1 to 4 o'clock, (b) 4 to 7 o'clock, (c) 7 to 10 o'clock" and the correct answer "(a) 1 to 4 o'clock."

[0127] (5) Other The server device 100, which is the authentication server, may enter dummy questions (dummy questions). For example, the server device 100 may generate questions that are not based on the behavior log of the user U, who is a user, and that the user U cannot answer (no answer is the correct answer). In this case, the answer options for all questions may be set to "no correct answer" or "skip." Furthermore, when answers are entered as free text, an answer that is not entered (left blank) may be accepted. Various methods are conceivable for creating dummies.

[0128] Furthermore, the server device 100, which is the authentication server, may create questions by utilizing logs that span multiple services, rather than for each service. This enhances security to prevent attacks based on a single question.

[0129] Furthermore, the server device 100, which is an authentication server, may generate a question that takes into account anonymity (evaluation scale such as K-anonymity) as a privacy measure. For example, location information may be obscured.

[0130] Furthermore, it is preferable that the server device 100, which is the authentication server, has two or more questions, rather than just one. In other words, it is sufficient that the questions are not limited.

[0131] In this manner, in this embodiment, the server device 100 dynamically generates secret questions and correct answers for identity verification based on the user's behavior log. Then, the server device 100 verifies the user's identity by comparing the user's answers to the secret questions with the correct answers.

[0132] For example, the server device 100 identifies the format of the action log and identifies and extracts question items from the action log. Alternatively, the server device 100 identifies question items by a statistical analysis method using machine learning.

[0133] In addition, the server device 100 extracts a question target log from the user's multiple behavior logs, creates a question template that determines one or more question items from the question target log, determines a question item generation policy, and generates questions and correct answers based on the question item generation policy.

[0134] At this time, the server device 100 may generate a dummy question together with the secret question and present the dummy question together with the secret question to the user. Alternatively, the server device 100 may generate a dummy answer together with the correct answer and present the dummy answer together with the correct answer as a choice to the user, allowing the user to select one.

[0135] The server device 100 may generate one question based on multiple action logs of the user.

[0136] Furthermore, the server device 100 may prompt the user to input document or image data that the user has obtained in connection with the user's actions as the user's answer to the secret question.

[0137] For example, the server device 100 verifies the identity of the user by comparing a hash value based on the input document or image data with a hash value previously stored as the correct answer. At this time, the server device 100 has the user input data on multiple documents or images obtained by the user in connection with each of the user's multiple actions as the user's answer to the secret question, and verifies the identity of the user by comparing the hash value based on the data on the multiple documents or images with a hash value previously stored as the correct answer.

[0138] Alternatively, the server device 100 verifies the identity of the person by comparing the input document or image data with document or image data previously stored as the correct answer. Alternatively, the server device 100 verifies the identity of the person by comparing the characteristics of the input document or image data with the characteristics previously stored as the correct answer.

[0139] At this time, the server device 100 may require the user to input data from emails (order confirmation emails, product shipping notification emails) received by the user in connection with the user's purchasing behavior as the user's answers to the secret questions. For example, the server device 100 can verify the user's identity by comparing a combination of the contents (text) of each email related to the user's multiple purchasing behaviors with pre-registered correct answer data. Matching The data may be the data itself or a hash value. Furthermore, the content (text) of each email related to multiple purchasing behaviors may be combined with the purchase date and time (or email reception date and time).

[0140] [1-4. Identity Verification] When verifying whether a user is the real person in identity proofing, the server device 100, which is an authentication server, determines that the user is the real person by verifying that the attribute information entered matches the attribute information previously registered by the user. If the user fails to authenticate and is unable to access their account, the server device 100 performs account recovery.

[0141] Current account recovery methods may require users to answer several questions, including personal attribute information, when verifying their identity on the recovery screen. While these questions include general questions such as address, they also include specific questions such as those about payment app integration and ownership of a member card (company-issued credit card). Identity verification methods such as "secret questions" may also be used.

[0142] However, traditional identity verification methods such as "secret questions" use fixed questions, making them vulnerable to attacks such as guessing or researching the correct answers to the questions.

[0143] Therefore, in this embodiment, a non-fixed "secret question" that takes privacy protection into consideration is dynamically created to achieve secure identity verification. For example, a screen prompting the user to enter the "secret question" is dynamically created.

[0144] In this embodiment, the server device 100, which is an authentication server, has an authentication function, an identity verification determination function, and an identity verification screen generation function. The server device 100 displays a set of verification attributes, but different ones may be displayed each time, or dummy questions may be inserted.

[0145] [1-4-1. Identity Verification Judgment Logic] In this embodiment, the server device 100, which is an authentication server, uses the following formulas (3) and (4) as identity verification determination logic.

[0146]

number

[0147]

number

[0148] Here, for the weight W, W={w1, w2, …, w n}, and then w1+w2+…+w n = 1. Also, f_A n (x) is attribute A n It is a judgment function of x and returns the accuracy of x. If the value of the judgment function f(A) is greater than a predetermined threshold, it is considered to be the correct person. Note that a1, a2, ... may be empty. Also, if a1 and a2 are not independent, it may be f(a1, a2). Also, if A is included in the dummy question, n The weight corresponding to is w n =0.

[0149] Even if the attribute input screen for identity verification changes, identity verification can be performed simply by adjusting the corresponding judgment function above, allowing for flexible response.

[0150] [1-4-2. Screen Creation Logic] In this embodiment, the server device 100, which is an authentication server, uses the log generation logic C: "Dynamic secret question creation" to create multiple question templates from a predetermined log format (shopping, auction, etc.). For example, the server device 100 creates a question template such as "At what time did you purchase electrical appliances at Y Shopping?"

[0151] This allows users to enter various attribute information into questions on a unified, common screen, enabling identity verification. Also, because it is a common screen, different attribute information appears for each person, preventing privacy leaks such as people guessing registered attributes.

[0152] The server device 100, which is the authentication server, actively changes the attribute information to be asked for additional questions in addition to the static questions that are always included. In this case, the judgment function can be adjusted. However, a judgment function is registered for each identity verification attempt (session). For example, it can be changed depending on the ID, time period, or context. Alternatively, it can be random. Dummy questions can also be appropriately included.

[0153] Furthermore, the server device 100, which is the authentication server, may display the screen in steps (multi-step proofing). For example, a predetermined question can be viewed only after a certain question has been answered.

[0154] [1-4-3. Using the behavior log itself as the answer to the secret question] In this embodiment, the server device 100, which is an authentication server, registers a secret "behavior history (document)" in advance and uses it for identity verification questions. At this time, the server device 100 registers the type and behavior history (document) in association with the ID.

[0155] (1) At the time of registration The server device 100 classifies the behavior history (document) used for the identity verification question, identifies the type, and registers it. For example, the server device 100 classifies the type of behavior history (document) as "purchase of a bag at Y Shopping" and registers it.

[0156] Furthermore, the server device 100 registers, for example, "purchase results (email) from Y Shopping" as the behavior history (document). This itself (the content of the email about the purchase results) may be created by the user using free text.

[0157] (2) When verifying identity When verifying the user's identity, the server device 100 creates a list of options including the type associated with the ID and a dummy type, displays the list, and allows the user to select. For example, the server device 100 requests the user to input a "behavioral history (document)" corresponding to the selected "type."

[0158] In addition to the type, the server device 100 may also create options for behavioral history (documents) as well, including behavioral history (documents) linked to the ID and dummy behavioral history (documents), display them in a list, and allow the user to select one, when verifying the user's identity.

[0159] Then, the server device 100 verifies the authenticity of the behavioral history (document) by, for example, comparing the hash values ​​of the behavioral history (document). For example, the server device 100 obtains one hash value from the contents of multiple behavioral histories (documents) input (or selected) by the user, and compares it with a hash value (correct data) registered in advance to verify the authenticity of these behavioral histories (documents) and confirm the identity of the user.

[0160] Furthermore, when verifying identity for account recovery, etc., the server device 100 may generate questions for PIM (Product Information Management), media, lifestyle tools, finance, etc. provided by businesses. In particular, commerce and payment users have a high ARPU (Average Revenue Per User), so account recovery is given a high priority.

[0161] Furthermore, the server device 100 may give higher priority to users who use news comments or Q&A services.

[0162] In addition, users of general social networking services, including messaging apps, store personal data such as daily activities and photos, so recovery is also a high priority. Users of various services, such as email services, which are lifelines that involve personal information, such as confidentiality of communications, also have a high need for recovery. The server device 100 may increase the priority of these users.

[0163] For example, in PIM services such as email and calendars, the results of the email team's analysis of the subject and text, such as the names of other companies' services for which email addresses are registered and used to send and receive emails, the names of categories such as travel and commerce that are frequently received, and reservations and purchases for those services, can be applied to the technology described in the present embodiment.

[0164] Furthermore, analysis results of the news topics the user follows and the categories of frequently viewed content can be applied to the technology described in the embodiments of the present application. In addition to these, analysis results of various service histories, such as weather, home location information, nearest stations, route and ride history, and navigation service destinations, can also be applied to the technology described in the embodiments of the present application. Furthermore, securities account information, stocks and investment trusts handled, bank account and card billing-related information, etc. can also be used in questions.

[0165] [1-5. Delegation of Account Recovery Authority] In this embodiment, the server device 100, which is an authentication server, may allow a user to transfer authority for account recovery to a person who is responsible for the user's actions. For example, when performing account recovery for a terminal device of a child (authentication target, authority delegator), the authority for account recovery may be allowed to be delegated to the child's parent (authority delegatee).

[0166] An example of delegation of authority for account recovery from a child to a parent will be described with reference to Fig. 10. Fig. 10 is an explanatory diagram showing an overview of an example of delegation of authority for account recovery from a child to a parent.

[0167] As shown in FIG. 10, a child user U (U1) registers the account of another parent user U (U2) as a recovery helper in the server device 100, which is an authentication server (step S40).

[0168] For example, the terminal device 10 (10A) of a child user U (U1) transmits a child ID indicating the child user U (U1) and a parent ID indicating another parent user U (U2) as a recovery collaborator to the server device 100, which is an authentication server. The server device 100, which is an authentication server, associates and registers the child ID indicating the child and the parent ID indicating the parent. This enables the server device 100, which is an authentication server, to perform FIDO authentication of the other parent user U (U2).

[0169] In this case, the server device 100, which is an authentication server, may register the account of the other parent user U (U2) as a recovery collaborator only if the child user U (U1) can prove that he or she has received permission from the other parent user U (U2). For example, the server device 100 may communicate with the terminal device 10 (10B) of the other parent user U (U2) to request consent from the other parent user U (U2). Alternatively, the child user U (U1) may request registration only after receiving permission from the other parent user U (U2) via short-range wireless communication between the terminal devices 10.

[0170] Furthermore, if the other parent user U (U2) is a known user (a registered user), the server device 100, which is an authentication server, only needs to link and register the child ID indicating the child with the parent ID indicating the parent, but if the other parent user U (U2) is an unknown user (an unregistered user), the server device 100 may request registration (user registration, authentication device registration) from the terminal device 10 (10B) of the other parent user U (U2).

[0171] Next, when account recovery becomes necessary, the terminal device 10 (10A) of the child user U (U1) transmits a recovery request (child ID, parent ID) to the server device 100, which is the authentication server (step S41).

[0172] For example, when account recovery becomes necessary, the terminal device 10 (10A) of the child user U (U1) sends a recovery request (child ID, parent ID) to the server device 100, which is the authentication server, either automatically or in response to an operation by the child user U (U1). The parent ID indicates the party to whom the authority for account recovery is delegated. Note that if the server device 100, which is the authentication server, stores child IDs and parent IDs in one-to-one correspondence, only the child ID may be sent as the recovery request.

[0173] Next, the server device 100, which is the authentication server, generates a challenge in response to a recovery request from the terminal device 10 of the child user U (U1) (step S42).

[0174] Next, the server device 100, which is the authentication server, transmits a recovery permission request including the challenge and the parent ID to the terminal device 10 (10A) of the child user U (U1) (step S43).

[0175] Next, the terminal device 10 (10A) of the child user U (U1) transmits (transfers) a recovery permission request from the server device 100 to the terminal device 10 (10B) of another parent user U (U2) (step S44).

[0176] In this embodiment, it is assumed that the parent is near the child. For example, a user U (U1) who is the child may transmit a recovery permission request from the server device 100 to another user U (U2) who is the parent, by short-range wireless communication between terminal devices 10 such as Bluetooth (registered trademark) Low Energy (BLE).

[0177] Next, the terminal device 10 (10B) of the other parent user U (U2) performs FIDO authentication (user verification using an authenticator) and signs the challenge using the private key as approval for the recovery permission request from the server device 100 (step S45).

[0178] Next, the terminal device 10 (10B) of the other parent user U (U2) sends a recovery permission response including a signed challenge to the terminal device 10 (10A) of the child user U (U1) in response to the recovery permission request (step S46).

[0179] Next, the terminal device 10 (10A) of the child user U (U1) sends (transfers) the recovery permission response (signed challenge) from the terminal device 10 (10B) of another parent user U (U2) to the server device 100, which is the authentication server (step S47).

[0180] Next, the server device 100, which is the authentication server, verifies the signature using the public key in response to the recovery permission response (signed challenge) from the terminal device 10 (10A) of the child user U (U1) and confirms the recovery collaborator (step S48).

[0181] Next, if the server device 100, which is the authentication server, succeeds in verifying the signature and can confirm that the other parent user U (U2) is a recovery cooperator, it performs recovery control (step S49).

[0182] Next, the server device 100, which is the authentication server, transmits a recovery response based on the recovery control to the terminal device 10 (10A) of the child user U (U1) who made the recovery request (step S50). As a result, the server device 100 performs account recovery for the terminal device 10 (10A) of the child user U (U1).

[0183] Note that delegation of account recovery authority from a child to a parent is merely one example. In reality, account recovery authority may be delegated from an employee of a company or the like to their superior or a system administrator. Also, account recovery authority may be delegated to a person who lends the terminal device 10 to user U. In other words, it is sufficient that account recovery authority is delegated from an authority delegator, who is the subject of authentication, to an authority delegatee.

[0184] Alternatively, the terminal device 10 (10A) of a child user U (U1) may be the FIDO client, and the terminal device 10 (10B) of another parent user U (U2) may be the authenticator. In other words, the user who uses the FIDO client and the user who is verified by the authenticator may be different people.

[0185] As described above, in this embodiment, the server device 100 manages information on the authentication subject and the authority delegate designated by the authentication subject. In response to a request for account recovery from the authentication subject, the server device 100 performs account recovery for the authentication subject with the authorization of the authority delegate. At this time, the server device 100 accepts registration of the account of the authority delegatee from the authentication subject as a recovery collaborator, and manages the account of the authentication subject and the account of the authority delegatee in association with each other.

[0186] For example, in response to a recovery request from the terminal device of the subject to be authenticated, the server device 100 transmits a recovery authorization request including a challenge to the terminal device of the delegee via the terminal device of the subject to be authenticated. Note that data is exchanged between the terminal device of the subject to be authenticated and the terminal device of the delegee via short-range wireless communication. As a result, the server device 100 receives a recovery authorization response including a signed challenge from the terminal device of the delegee via the terminal device of the subject to be authenticated in response to the recovery authorization request. If the signature verification is successful, the server device 100 performs account recovery for the subject to be authenticated.

[0187] At this time, the server device 100 receives a recovery authorization response including a signed challenge generated by the grantee signing the challenge as approval for the recovery authorization request. If the signature verification is successful, the server device 100 confirms that the grantee is a recovery collaborator and performs account recovery for the authentication target.

[0188] For example, the server device 100 manages information on a child who is the subject of authentication and a parent who is the recipient of authority. In response to a request for account recovery from a child, the server device 100 recovers the child's account with the parent's approval. At this time, the server device 100 performs FIDO authentication on the parent.

[0189] [2. Example of information processing system configuration] Next, a configuration of an information processing system 1 including a server device 100 according to an embodiment will be described with reference to Fig. 11. Fig. 11 is a diagram showing an example of the configuration of the information processing system 1 according to an embodiment. As shown in Fig. 11, the information processing system 1 according to an embodiment includes a terminal device 10 and a server device 100. These various devices are connected to each other via a network N so as to be able to communicate with each other via a wired or wireless connection. The network N is, for example, a LAN (Local Area Network) or a WAN (Wide Area Network) such as the Internet.

[0190] Furthermore, the number of devices included in the information processing system 1 shown in Fig. 11 is not limited to that shown in the figure. For example, in Fig. 11, for the sake of simplicity, only one terminal device 10 is shown, but this is merely an example and is not limiting, and two or more devices may be included.

[0191] The terminal device 10 is an information processing device used by a user U. For example, the terminal device 10 is a smart device such as a smartphone or a tablet terminal, a feature phone, a PC (Personal Computer), a PDA (Personal Digital Assistant), a game console or AV device with a communication function, a car navigation system, a wearable device such as a smart watch or a head-mounted display, smart glasses, etc.

[0192] In addition, the terminal device 10 can connect to the network N via a wireless communication network such as LTE (Long Term Evolution), 4G (4th Generation), or 5G (5th Generation: 5th generation mobile communication system), or via short-range wireless communication such as Bluetooth (registered trademark) or wireless LAN (Local Area Network), and communicate with the server device 100.

[0193] The server device 100 is, for example, a computer such as a PC or a blade server, or a mainframe or a workstation, etc. The server device 100 may be realized by cloud computing.

[0194] [3. Example of terminal device configuration] Next, the configuration of the terminal device 10 will be described with reference to Fig. 12. Fig. 12 is a diagram showing an example configuration of the terminal device 10. As shown in Fig. 12, the terminal device 10 includes a communication unit 11, a display unit 12, an input unit 13, a positioning unit 14, a sensor unit 20, a control unit 30 (controller), and a storage unit 40.

[0195] (Communications Department 11) The communication unit 11 is connected to a network N (see FIG. 11) by wire or wirelessly, and transmits and receives information to and from the server device 100 via the network N. For example, the communication unit 11 is realized by a NIC (Network Interface Card), an antenna, etc.

[0196] (Display section 12) Display unit 12 is a display device that displays various information such as position information. For example, display unit 12 is a liquid crystal display (LCD) or an organic electro-luminescent display (OLED). Display unit 12 is also a touch panel display, but is not limited to this.

[0197] (Input section 13) The input unit 13 is an input device that accepts various operations from the user U. For example, the input unit 13 has buttons for inputting characters, numbers, etc. The input unit 13 may be an input / output port (I / O port), a USB (Universal Serial Bus) port, etc. If the display unit 12 is a touch panel display, a part of the display unit 12 functions as the input unit 13. The input unit 13 may be a microphone that accepts voice input from the user U. The microphone may be wireless.

[0198] (Positioning unit 14) The positioning unit 14 receives signals (radio waves) transmitted from satellites of a GPS (Global Positioning System), and acquires position information (e.g., latitude and longitude) indicating the current position of the terminal device 10, which is the device itself, based on the received signals. That is, the positioning unit 14 positions the position of the terminal device 10. Note that GPS is merely an example of a GNSS (Global Navigation Satellite System).

[0199] The positioning unit 14 can also measure the position using various methods other than GPS. For example, the positioning unit 14 may measure the position by using various communication functions of the terminal device 10 as an auxiliary positioning means for position correction, etc., as described below.

[0200] (Wi-Fi positioning) For example, the positioning unit 14 uses a Wi-Fi (registered trademark) communication function of the terminal device 10 or a communication network provided by each communication company to measure the position of the terminal device 10. Specifically, the positioning unit 14 performs Wi-Fi communication or the like and measures the distance to a nearby base station or access point, thereby measuring the position of the terminal device 10.

[0201] (Beacon positioning) The positioning unit 14 may also measure the position by using a Bluetooth (registered trademark) function of the terminal device 10. For example, the positioning unit 14 measures the position of the terminal device 10 by connecting to a beacon transmitter connected by the Bluetooth (registered trademark) function.

[0202] (geomagnetic positioning) The positioning unit 14 also measures the position of the terminal device 10 based on a geomagnetic pattern of a structure that has been measured in advance and a geomagnetic sensor that the terminal device 10 has.

[0203] (RFID positioning) Furthermore, for example, if the terminal device 10 has a function of an RFID (Radio Frequency Identification) tag equivalent to a contactless IC card used at station ticket gates, in stores, etc., or has a function of reading an RFID tag, the location where the terminal device 10 was used is recorded together with information on the payment or the like made by the terminal device 10. The positioning unit 14 may obtain such information to determine the location of the terminal device 10. Alternatively, the location may be determined by an optical sensor, an infrared sensor, or the like provided in the terminal device 10.

[0204] The positioning unit 14 may measure the position of the terminal device 10 using one or a combination of the above-mentioned positioning means, as needed.

[0205] (Sensor unit 20) The sensor unit 20 includes various sensors mounted on or connected to the terminal device 10. The connection may be wired or wireless. For example, the sensors may be detection devices other than the terminal device 10, such as wearable devices or wireless devices. In the example shown in FIG. 12 , the sensor unit 20 includes an acceleration sensor 21, a gyro sensor 22, a barometric pressure sensor 23, a temperature sensor 24, a sound sensor 25, a light sensor 26, a magnetic sensor 27, and an image sensor (camera) 28.

[0206] The above-described sensors 21 to 28 are merely examples and are not intended to be limiting. That is, the sensor unit 20 may be configured to include some of the sensors 21 to 28, or may include other sensors such as a humidity sensor in addition to or instead of the sensors 21 to 28.

[0207] The acceleration sensor 21 is, for example, a three-axis acceleration sensor, and detects physical movements of the terminal device 10, such as the direction of movement, speed, and acceleration of the terminal device 10. The gyro sensor 22 detects physical movements of the terminal device 10, such as tilt in three axial directions, based on the angular velocity of the terminal device 10. The air pressure sensor 23 detects, for example, the air pressure around the terminal device 10.

[0208] Since the terminal device 10 includes the acceleration sensor 21, the gyro sensor 22, the atmospheric pressure sensor 23, etc., it is possible to measure the position of the terminal device 10 using a technique such as Pedestrian Dead-Reckoning (PDR) that uses these sensors 21 to 23. This makes it possible to obtain indoor position information that is difficult to obtain using a positioning system such as GPS.

[0209] For example, the number of steps, walking speed, and distance walked can be calculated using a pedometer that uses the acceleration sensor 21. In addition, the direction of travel, line of sight, and body tilt of the user U can be determined using the gyro sensor 22. In addition, the air pressure detected by the air pressure sensor 23 can also be used to determine the floor number of the altitude Y floor where the terminal device 10 of the user U is located.

[0210] The temperature sensor 24 detects, for example, the temperature around the terminal device 10. The sound sensor 25 detects, for example, the sound around the terminal device 10. The light sensor 26 detects the illuminance around the terminal device 10. The magnetic sensor 27 detects, for example, the geomagnetism around the terminal device 10. The image sensor 28 captures an image around the terminal device 10.

[0211] The above-mentioned air pressure sensor 23, temperature sensor 24, sound sensor 25, light sensor 26, and image sensor 28 can detect the air pressure, temperature, sound, and illuminance, respectively, and capture images of the surroundings, thereby detecting the environment and situation around the terminal device 10. Furthermore, the accuracy of the location information of the terminal device 10 can be improved based on the environment and situation around the terminal device 10.

[0212] (control unit 30) The control unit 30 includes, for example, a microcomputer having a CPU (Central Processing Unit), ROM (Read Only Memory), RAM, input / output ports, etc., and various other circuits. The control unit 30 may also be configured with hardware such as an integrated circuit, for example, an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). The control unit 30 includes a transmitting unit 31, a receiving unit 32, and a processing unit 33.

[0213] (Transmitter 31) The transmission unit 31 can transmit, for example, various information input by the user U using the input unit 13, various information detected by each sensor 21 to 28 mounted on or connected to the terminal device 10, and location information of the terminal device 10 measured by the positioning unit 14 to the server device 100 via the communication unit 11.

[0214] (Receiver 32) The receiving unit 32 can receive various types of information provided by the server device 100 and requests for various types of information from the server device 100 via the communication unit 11.

[0215] (Processing unit 33) The processing unit 33 controls the entire terminal device 10, including the display unit 12. For example, the processing unit 33 can output various information transmitted by the transmitting unit 31 and various information received from the server device 100 by the receiving unit 32 to the display unit 12 for display.

[0216] (Storage unit 40) The storage unit 40 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), an optical disk, etc. The storage unit 40 stores various programs, various data, etc.

[0217] [4. Server device configuration example] Next, the configuration of the server device 100 according to the embodiment will be described with reference to Fig. 13. Fig. 13 is a diagram showing an example of the configuration of the server device 100 according to the embodiment. As shown in Fig. 13, the server device 100 includes a communication unit 110, a storage unit 120, and a control unit 130.

[0218] (Communication unit 110) The communication unit 110 is realized by, for example, a network interface card (NIC), etc. The communication unit 110 is also connected to a network N (see FIG. 11) by wire or wirelessly.

[0219] (Storage unit 120) The storage unit 120 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as an HDD, an SSD, an optical disk, etc. As shown in Fig. 13, the storage unit 120 has a user information database 121, a history information database 122, an authentication information database 123, and a policy information database 124.

[0220] (User Information Database 121) The user information database 121 stores user information about the user U. For example, the user information database 121 stores various information such as the attributes of the user U. FIG. 14 is a diagram showing an example of the user information database 121. In the example shown in FIG. 14, the user information database 121 has items such as "User ID (Identifier)," "Age," "Gender," "Home," "Workplace," and "Interests."

[0221] The "user ID" indicates identification information for identifying the user U. The "user ID" may be the contact information of the user U (telephone number, email address, etc.), or may be identification information for identifying the terminal device 10 of the user U.

[0222] Furthermore, "age" indicates the age of user U identified by the user ID. Note that "age" may be information indicating the specific age of user U (e.g., 35 years old), or may be information indicating the generation of user U (e.g., 30s). Alternatively, "age" may be information indicating the date of birth of user U, or may be information indicating the generation of user U (e.g., born in the 1980s). Furthermore, "gender" indicates the gender of user U identified by the user ID.

[0223] Furthermore, "home" indicates the location information of the home of user U identified by the user ID. In the example shown in FIG. 14, "home" is illustrated as an abstract code such as "LC11," but it may also be latitude and longitude information, etc. Furthermore, for example, "home" may also be the name of an area or an address.

[0224] Furthermore, "workplace" indicates location information of the workplace (school in the case of a student) of user U identified by the user ID. In the example shown in FIG. 14, "workplace" is illustrated as an abstract code such as "LC12," but it may also be latitude and longitude information, etc. Furthermore, for example, "workplace" may also be the name of a region or an address.

[0225] Furthermore, "interests" indicate the interests of user U identified by the user ID. In other words, "interests" indicate subjects in which user U identified by the user ID is highly interested. For example, "interests" may be search queries (keywords) entered by user U into a search engine. In the example shown in FIG. 14, each user U is shown with one "interest," but there may be multiple "interests."

[0226] For example, in the example shown in FIG. 14, the age of user U identified by user ID "U1" is "20s" and the gender is "male." Furthermore, for example, the home address of user U identified by user ID "U1" is "LC11." Furthermore, for example, the workplace of user U identified by user ID "U1" is "LC12." Furthermore, for example, the user U identified by user ID "U1" is interested in "sports."

[0227] 14, abstract values ​​such as "U1", "LC11", and "LC12" are used for illustration, but "U1", "LC11", and "LC12" are assumed to store information such as specific character strings and numerical values. Below, abstract values ​​may also be illustrated in diagrams relating to other information.

[0228] The user information database 121 may store various types of information depending on the purpose, without being limited to the above. For example, the user information database 121 may store various types of information related to the terminal device 10 of the user U. The user information database 121 may also store information related to the user U's attributes, such as demographic attributes, psychographic attributes, geographic attributes, and behavioral attributes. For example, the user information database 121 may store information such as name, family structure, hometown (hometown), occupation, job title, income, qualifications, type of residence (detached house, apartment, etc.), whether or not the user has a car, commuting time, commuting route, commuter pass area (station, line, etc.), frequently used stations (other than the station nearest to home or workplace), extracurricular activities (location, time zone, etc.), hobbies, interests, lifestyle, etc.

[0229] (History Information Database 122) The history information database 122 stores various information related to history information (log data) that indicates the behavior of the user U. Fig. 15 is a diagram showing an example of the history information database 122. In the example shown in Fig. 15, the history information database 122 has items such as "user ID," "location history," "search history," "browsing history," "purchase history," and "posting history."

[0230] "User ID" indicates identification information for identifying user U. "Location history" indicates the location history, which is the history of user U's location and movements. "Search history" indicates the search history, which is the history of search queries entered by user U. "Browsing history" indicates the browsing history, which is the history of content viewed by user U. "Purchase history" indicates the purchase history, which is the history of purchases made by user U. "Posting history" indicates the posting history, which is the history of posts made by user U. "Posting history" may also include questions about user U's possessions.

[0231] For example, in the example shown in Figure 15, user U, identified by user ID "U1," moved as shown in "Location History #1," searched as shown in "Search History #1," viewed content as shown in "Viewing History #1," purchased specific products at specific stores as shown in "Purchase History #1," and posted as shown in "Posting History #1."

[0232] Here, in the example shown in Figure 15, abstract values ​​such as "U1", "Location History #1", "Search History #1", "Viewing History #1", "Purchase History #1", and "Posting History #1" are used for the illustration, but "U1", "Location History #1", "Search History #1", "Viewing History #1", "Purchase History #1", and "Posting History #1" are assumed to store specific information such as character strings and numbers.

[0233] The history information database 122 is not limited to the above and may store various types of information depending on the purpose. For example, the history information database 122 may store the user U's usage history of a predetermined service. The history information database 122 may also store the user U's store visit history or facility visit history. The history information database 122 may also store the user U's payment history (electronic payment) using the terminal device 10.

[0234] (Authentication Information Database 123) The authentication information database 123 stores various information related to the FIDO authentication of the user U. Fig. 16 is a diagram showing an example of the authentication information database 123. In the example shown in Fig. 16, the authentication information database 123 has items such as "user ID," "authentication device," "attestation public key," "authentication public key," "identification document," "expiration date," "question," "correct answer," and "authority delegatee."

[0235] "User ID" indicates identification information for identifying user U. Furthermore, "authenticator" indicates the authenticator used by user U. Furthermore, "authenticator" may store the authenticator birth certificate document (attestation document).

[0236] Furthermore, the "attestation public key" indicates the attestation public key of the authenticator used by the user U. Furthermore, the "authentication public key" indicates the authentication public key of the authenticator used by the user U.

[0237] Furthermore, "identification document" indicates the identification document submitted by user U. Furthermore, "expiration date" indicates the expiration date of the identification document (or the information written therein).

[0238] Furthermore, "Question" indicates a secret question that is dynamically created to verify the identity of user U. Note that "Question" may store options as answers to the questions. Furthermore, "Correct Answer" indicates the correct answer to the questions. Note that "Correct Answer" may store a document or image data (set) that user U is requested to input and that is to be compared, or may store a hash value or data characteristics based on the document or image data (set).

[0239] Furthermore, "authority delegate" refers to identification information for identifying other users to whom authority is delegated from user U when delegating authority for account recovery. In other words, "authority delegate" refers to other users designated and registered by user U as targets for delegation of account recovery authority. For example, if user U is a child, the authority delegate would be the child's parent.

[0240] For example, in the example shown in Figure 16, "attestation public key #1" and "authentication public key #1" are registered as public keys for verifying the signature from "authenticator #1," which is the authenticator of user U identified by user ID "U1." User U's "identification document #1" will expire after "expiration date #1." When "correct answer #1" is given to "question #1" for user U's identity verification, the user is authenticated as the authentic user. When an account recovery request is received from user U, approval is sought from "authority delegate #1."

[0241] Here, in the example shown in Figure 16, abstract values ​​such as "U1," "Authentication device #1," "Atestation public key #1," "Authentication public key #1," "Personal identification document #1," "Expiration date #1," "Question #1," "Correct answer #1," and "Authority delegatee #1" are used for the illustration, but specific information such as character strings and numbers is assumed to be stored in "U1," "Authentication device #1," "Atestation public key #1," "Authentication public key #1," "Personal identification document #1," "Expiration date #1," "Question #1," "Correct answer #1," and "Authority delegatee #1."

[0242] The authentication information database 123 is not limited to the above and may store various types of information depending on the purpose. For example, the authentication information database 123 may store information on the authentication accuracy and identity accuracy of the user U. The authentication information database 123 may also store information on an evaluation function of identity accuracy and a judgment function of attributes. The authentication information database 123 may also store the password of the user U.

[0243] (Policy Information Database 124) The policy information database 124 stores various information related to the security policy of the authentication server, ie, the server device 100. The security policy is changeable.

[0244] The security policy may be set for each identity service, or may be set for each segment of users who are the target of the service.

[0245] (control unit 130) 13, the explanation will be continued. The control unit 130 is a controller, and is realized by, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or the like, executing various programs (corresponding to an example of an information processing program) stored in a storage device inside the server device 100 using a storage area such as a RAM as a working area. In the example shown in FIG. 13, the control unit 130 has an acquisition unit 131, a generation unit 132, an authentication processing unit 133, a management unit 134, and a provision unit 135.

[0246] (Acquisition part 131) The acquisition unit 131 acquires data input by a user U, who is a user, from the terminal device 10 of the user U via the communication unit 110. For example, the acquisition unit 131 acquires various registration information by the user U from the terminal device 10 of the user U.

[0247] Furthermore, the acquisition unit 131 acquires a search query input by the user U. For example, when the user U inputs a search query into a search engine or the like to perform a keyword search, the acquisition unit 131 acquires the search query via the communication unit 110. That is, the acquisition unit 131 acquires, via the communication unit 110, the keywords input by the user U into the search box of a search engine, website, or app.

[0248] Furthermore, the acquisition unit 131 acquires user information about the user U via the communication unit 110. For example, the acquisition unit 131 acquires identification information (such as a user ID) indicating the user U, location information of the user U, attribute information of the user U, etc. from the terminal device 10 of the user U. Furthermore, the acquisition unit 131 may acquire the identification information indicating the user U, attribute information of the user U, etc. when registering the user U. Then, the acquisition unit 131 registers the user information in the user information database 121 of the storage unit 120.

[0249] Furthermore, the acquisition unit 131 acquires various types of history information (log data) indicating the behavior of the user U via the communication unit 110. For example, the acquisition unit 131 acquires various types of history information indicating the behavior of the user U from the terminal device 10 of the user U or from various servers based on the user ID or the like. Then, the acquisition unit 131 registers the various types of history information in the history information database 122 of the storage unit 120.

[0250] (Generation unit 132) The generation unit 132 dynamically generates secret questions and answers for identity verification based on the user's behavior log. For example, the generation unit 132 identifies the format of the behavior log and identifies and extracts questions from the behavior log. Alternatively, the generation unit 132 identifies questions using a statistical analysis method using machine learning.

[0251] In addition, the generation unit 132 extracts a question target log from the user's multiple behavior logs, creates a question template that determines one or more question items from the question target log, determines a question item generation policy, and generates a question and a correct answer based on the question item generation policy.

[0252] At this time, the generation unit 132 may generate a dummy question along with the secret question. Also, the generation unit 132 may generate a dummy answer along with the correct answer. Also, the generation unit 132 may generate one question based on multiple action logs of the user.

[0253] (Authentication processing unit 133) The authentication processing unit 133 verifies the user's answer to the secret question by comparing it with the correct answer. At this time, the authentication processing unit 133 may present a dummy question to the user along with the secret question. The authentication processing unit 133 may also present the dummy answer along with the correct answer to the user as a choice, allowing the user to select one.

[0254] The authentication processing unit 133 may require the user to input document or image data obtained by the user in connection with the user's actions as the user's answer to the secret question. In this case, the authentication processing unit 133 may require the user to input email data obtained by the user in connection with the user's purchasing actions as the user's answer to the secret question.

[0255] For example, the authentication processing unit 133 verifies the identity of the user by comparing a hash value based on the input document or image data with a hash value previously stored as the correct answer. At this time, the authentication processing unit 133 has the user input data on multiple documents or images obtained by the user in connection with each of the user's multiple actions as the user's answer to the secret question, and verifies the identity of the user by comparing the hash value based on the data on the multiple documents or images with a hash value previously stored as the correct answer.

[0256] Alternatively, the authentication processing unit 133 verifies the identity of the person by comparing the input document or image data with document or image data that has been stored in advance as the correct answer. Alternatively, the authentication processing unit 133 verifies the identity of the person by comparing the characteristics of the input document or image data with the characteristics that have been stored in advance as the correct answer.

[0257] Furthermore, the authentication processing unit 133 verifies the identity of the user (user U) by confirming that the personal attribute information registered in advance by the user matches the personal attribute information presented by the user.

[0258] The authentication processing unit 133 also determines the trustworthiness of the authenticator based on the attestation document and performs FIDO authentication with the trusted authenticator. For example, the authentication processing unit 133 verifies a signature using a private key of the trusted authenticator with a public key corresponding to the private key.

[0259] Furthermore, in response to a request for account recovery from the person to be authenticated (authority delegater), the authentication processing unit 133 recovers the account of the person to be authenticated with the approval of the authority delegatee designated by the person to be authenticated.

[0260] For example, in response to a recovery request from the terminal device of the person to be authenticated, the authentication processing unit 133 transmits a recovery permission request including a challenge to the terminal device of the person to be authenticated via the terminal device of the person to be authenticated. Note that data is transmitted and received between the terminal device of the person to be authenticated and the terminal device of the person to be authenticated via short-range wireless communication.

[0261] Then, the authentication processing unit 133 receives a recovery authorization response including a signed challenge from the terminal device of the grantee via the terminal device of the authentication target as a response to the recovery authorization request. At this time, the authentication processing unit 133 receives the recovery authorization response including a signed challenge generated by the grantee by signing the challenge as approval for the recovery authorization request.

[0262] If the signature verification is successful, the authentication processing unit 133 performs account recovery for the person to be authenticated. At this time, if the signature verification is successful, the authentication processing unit 133 confirms that the authority delegatee is a recovery cooperator and performs account recovery for the person to be authenticated.

[0263] For example, in response to a request for account recovery from a child who is the subject of authentication, the authentication processing unit 133 recovers the child's account with the approval of a parent who is the recipient of authority. At this time, the authentication processing unit 133 performs FIDO authentication on the parent.

[0264] (Management Department 134) The management unit 134 continuously manages the registered personal attribute information used for identity verification so that it satisfies the security policy. Furthermore, when controlling access to provide an identity service to a user, if the personal attribute information does not satisfy the security policy, the management unit 134 initiates new authentication and identity verification processing so that it satisfies the security policy.

[0265] For example, the management unit 134 suppresses variations in the reliability of the personal attribute information due to differences in identity verification methods based on the security policy, and continuously manages the reliability of the personal attribute information. Alternatively, the management unit 134 suppresses a decrease in the reliability of the personal attribute information over time based on the security policy, and continuously manages the reliability of the personal attribute information.

[0266] Furthermore, when the security policy is changed, the management unit 134 continuously manages the personal attribute information so that it satisfies the changed security policy.

[0267] In addition, if the validity period of the personal identification document that is the basis for the registered personal attribute information has expired or if the personal identification document has expired, the management unit 134 determines that the personal attribute information does not satisfy the security policy and initiates new authentication and personal identification processing to satisfy the security policy.

[0268] The management unit 134 also calculates the accuracy of personal attribute information for an online user currently being authenticated by multiplying the authentication accuracy by the identity accuracy. The authentication accuracy becomes 0 once the validity period of the authentication session established after each successful authentication attempt has expired. The identity accuracy varies depending on the type of personal attribute information.

[0269] The management unit 134 also stores the attestation document and continuously manages the authentication strength of the attestation document. When the management unit 134 decides to strengthen security and the attestation document that has already been stored does not satisfy the authentication strength, the management unit 134 re-performs attestation that satisfies the authentication strength.

[0270] For example, the management unit 134 may re-perform attestation if the authenticator no longer satisfies the security policy due to the passage of time or the discovery of a problem, or if a change in the security policy causes the authenticator to no longer satisfy the security policy.

[0271] The management unit 134 also determines the reliability of the public key based on the contents of the attestation document. The management unit 134 also manages the reliability of the public key, and requests a change of the public key if the reliability of the public key has decreased.

[0272] For example, the management unit 134 determines that the reliability of the public key has decreased over time and requests that the public key be changed. Also, if the validity period of the public key has expired, the management unit 134 determines that the reliability of the public key has decreased and requests that the public key be changed. Also, if the reliability of the public key does not satisfy the security policy, the management unit 134 determines that the reliability of the public key has decreased and requests that the public key be changed.

[0273] Furthermore, with regard to the delegation of account recovery authority to another person (for example, delegation of account recovery authority from a child to a parent), the management unit 134 manages information about the person to be authenticated (authority delegator) and the person to whom the authority is delegated designated by the person to be authenticated. For example, the management unit 134 manages information about the child who is the person to be authenticated and the parent who is the person to whom the authority is delegated. In this case, the management unit 134 accepts registration of the account of the person to be authenticated who is the authority delegatee as a recovery collaborator from the person to be authenticated, and manages the account of the person to be authenticated and the account of the person to whom the authority is delegated in association with each other.

[0274] (Provider 135) The providing unit 135 provides an identity service to a user who has succeeded in FIDO authentication via the communication unit 110. That is, the providing unit 135 provides the identity service to the user U, who is the user, to the terminal device 10 of the user U.

[0275] Furthermore, the providing unit 135 may provide screen information (input screen, etc.) to the terminal device 10 of the user U, who is a user, via the communication unit 110. At this time, the terminal device 10 of the user U displays the input screen, etc., based on the provided screen information.

[0276] Furthermore, the providing unit 135 may provide information regarding the success or failure of FIDO authentication to the terminal device 10 of the user U, who is a user, via the communication unit 110. Furthermore, the providing unit 135 may provide various information related to FIDO authentication to the terminal device 10 of the user U, who is a user, via the communication unit 110.

[0277] [5. Processing Procedure] Next, a processing procedure by the server device 100 according to the embodiment will be described with reference to Fig. 17. Fig. 17 is a flowchart showing the processing procedure according to the embodiment. Note that the processing procedure shown below is repeatedly executed by the control unit 130 of the server device 100.

[0278] As shown in FIG. 17, the authentication processing unit 133 of the server device 100 determines the reliability of the authentication device based on the attestation document, and performs FIDO authentication with the trusted authentication device (step S101).

[0279] Next, the management unit 134 of the server device 100 continuously manages the registered personal attribute information used for identity verification so as to satisfy the security policy (step S102).

[0280] Next, when controlling access to provide an identity service to a user, if the personal attribute information does not satisfy the security policy, the management unit 134 of the server device 100 initiates new authentication and identity verification processing to satisfy the security policy (step S103).

[0281] Next, the management unit 134 of the server device 100 stores the attestation document and continuously manages the authentication strength of the attestation document (step S104).

[0282] Next, when the management unit 134 of the server device 100 decides to strengthen security, if the attestation document already stored does not satisfy the authentication strength, the management unit 134 re-performs attestation that satisfies the authentication strength (step S105).

[0283] Next, when authentication fails and the account cannot be accessed, the generation unit 132 of the server device 100 dynamically generates secret questions and answers for identity verification based on the user's behavior log before performing account recovery for the user (step S106).

[0284] Next, the authentication processing unit 133 of the server device 100 verifies the user's answer to the secret question against the correct answer and verifies the user's identity (step S107). For example, the authentication processing unit 133 verifies the user's identity by verifying a hash value based on the input document or image data against a hash value stored in advance as the correct answer.

[0285] Next, the management unit 134 of the server device 100 manages information regarding the person to be authenticated (authority delegator) and the person to whom the authority is delegated designated by the person to be authenticated regarding the delegation of authority for account recovery to another person (for example, delegation of authority for account recovery from a child to a parent) (step S108).

[0286] Next, in response to a request for account recovery from the person to be authenticated (authority delegater), the authentication processing unit 133 of the server device 100 performs account recovery for the person to be authenticated with the approval of the authority delegatee designated by the person to be authenticated (step S109).

[0287] [6. Modifications] The terminal device 10 and the server device 100 described above may be implemented in various different forms other than the above embodiment. Therefore, modifications of the embodiment will be described below.

[0288] In the above embodiment, some or all of the processing executed by the server device 100 may actually be executed by the terminal device 10. For example, the processing may be completed in a stand-alone manner (by the terminal device 10 alone). In this case, the terminal device 10 is assumed to have the functions of the server device 100 in the above embodiment. Furthermore, in the above embodiment, the terminal device 10 is linked to the server device 100, and therefore, from the perspective of the user U, it appears that the processing of the server device 100 is also being executed by the terminal device 10. In other words, from another perspective, the terminal device 10 can also be said to be equipped with the server device 100.

[0289] In the above embodiment, the server device 100 may perform multi-step authentication by combining FIDO authentication with other authentication methods. For example, the server device 100 may perform two-step authentication by combining FIDO authentication with password authentication. Alternatively, the server device 100 may perform two-step authentication by combining FIDO authentication with a secret question.

[0290] In the above embodiment, the server device 100 may perform authentication using a combination of two or more of the three authentication factors, "knowledge information," "possession information," and "biometric information," in FIDO authentication. That is, the server device 100 may employ multi-factor authentication (MFA).

[0291] In the above embodiment, the server device 100 may input data of a document obtained by the user in connection with the user's actions, and compare the vectorized value obtained by natural language processing (text analysis) of the input document data with a value stored in advance as a correct answer to verify the identity of the user. That is, the server device 100 may verify the identity of the user by comparing the vector value of the document, not limited to the hash value.

[0292] Furthermore, in the above embodiment, the server device 100 may use search history when dynamically creating a secret question. For example, the server device 100 may verify the identity of the user by comparing a hash value of a combination of multiple search queries entered (or selected) by the user with pre-registered correct answer data. Note that the hash value is not limited to a hash value, and may be a vectorized value obtained by subjecting the combination of search queries to natural language processing (text analysis).

[0293] Furthermore, in the above embodiment, the server device 100 may manage the attestation public key, the authentication public key, and the authenticator birth certificate document (attestation document) using a blockchain (BC). For example, the FIDO public key is managed by a distributed ledger device. The distributed ledger device is a server device compatible with distributed ledger technology (DLT), which allows each node constituting a network to manage / share the same ledger. The distributed ledger device may be one of the nodes constituting this network. Since a hash is included in a blockchain block, it is possible to verify whether the public key has been tampered with. Furthermore, authentication can be performed after verifying the appropriateness of the public key.

[0294] [7. Effects] As described above, the information processing device (terminal device 10 and server device 100) according to the present application includes an authentication processing unit 133 that verifies the identity of a user by confirming that the personal attribute information previously registered by the user matches the personal attribute information presented by the user, and a management unit 134 that continuously manages the registered personal attribute information used for identity verification so as to satisfy a security policy.

[0295] When controlling access to provide an identity service to a user, if the personal attribute information does not satisfy the security policy, the management unit 134 initiates new authentication and identity verification processing to satisfy the security policy.

[0296] The management unit 134 suppresses variations in the reliability of personal attribute information due to differences in identity verification methods, and continuously manages the reliability of personal attribute information, based on a security policy.

[0297] The management unit 134 suppresses a decrease in the reliability of the personal attribute information over time and continuously manages the reliability of the personal attribute information based on the security policy.

[0298] When the security policy is changed, the management unit 134 continuously manages the personal attribute information so that the personal attribute information satisfies the changed security policy.

[0299] If the validity period of the personal identification document that is the basis for the registered personal attribute information has expired or if the personal identification document has expired, the management unit 134 determines that the personal attribute information does not satisfy the security policy and initiates new authentication and personal identification processing to satisfy the security policy.

[0300] The management unit 134 calculates the accuracy of personal attribute information for an online user currently being authenticated by multiplying the authentication accuracy by the identity accuracy. The authentication accuracy becomes 0 once the validity period of the authentication session established after each successful authentication attempt has expired. The identity accuracy varies depending on the type of personal attribute information.

[0301] From another perspective, the information processing device (terminal device 10 and server device 100) according to the present application includes an authentication processing unit 133 that determines the reliability of the authentication device based on the attestation document and performs FIDO authentication with the trusted authentication device, and a management unit 134 that stores the attestation document and continuously manages the authentication strength of the attestation document.

[0302] When the management unit 134 decides to strengthen security, if the attestation document already stored does not satisfy the authentication strength, the management unit 134 re-performs attestation that satisfies the authentication strength.

[0303] If the authenticator no longer satisfies the security policy due to the passage of time or the discovery of a problem, the management unit 134 performs the attestation again.

[0304] If the authenticator no longer satisfies the security policy due to a change in the security policy, the management unit 134 performs attestation again.

[0305] The management unit 134 determines the reliability of the public key based on the contents of the attestation document.

[0306] The authentication processing unit 133 verifies a signature made using the private key of the authenticator with the public key corresponding to the private key. The management unit 134 manages the reliability strength of the public key and requests a change of the public key if the reliability strength of the public key decreases.

[0307] For example, the management unit 134 determines that the reliability of the public key has decreased over time, and requests that the public key be changed.

[0308] Furthermore, when the validity period of the public key has expired, the management unit 134 determines that the reliability of the public key has decreased, and requests that the public key be changed.

[0309] Furthermore, if the reliability of the public key does not satisfy the security policy, the management unit 134 determines that the reliability of the public key has decreased, and requests that the public key be changed.

[0310] From another perspective, the information processing device (terminal device 10 and server device 100) according to the present application includes a generation unit 132 that dynamically generates secret questions and correct answers for identity verification based on the user's behavior log, and an authentication processing unit 133 that verifies the user's identity by comparing the user's answers to the secret questions with the correct answers.

[0311] For example, the generation unit 132 identifies the format of the action log, and identifies and extracts question items from the action log.

[0312] Alternatively, the generation unit 132 identifies question items by a statistical analysis method using machine learning.

[0313] The generation unit 132 extracts a question target log from the user's multiple behavior logs, creates a question template that determines one or more question items from the question target log, determines a question item generation policy, and generates a question and a correct answer based on the question item generation policy.

[0314] The generation unit 132 generates a dummy question together with the secret question, and the authentication processing unit 133 presents the dummy question together with the secret question to the user.

[0315] The generation unit 132 generates a dummy answer along with the correct answer. The authentication processing unit 133 presents the dummy answer along with the correct answer to the user as options, and allows the user to select one.

[0316] The generation unit 132 generates one question based on multiple action logs of the user.

[0317] The authentication processing unit 133 prompts the user to input document or image data obtained by the user in connection with the user's actions as the user's answer to the secret question.

[0318] The authentication processing unit 133 verifies the identity of the person by comparing the input document or image data with document or image data stored in advance as the correct answer.

[0319] The authentication processing unit 133 verifies the identity of the person by comparing a hash value based on the input document or image data with a hash value stored in advance as the correct answer.

[0320] The authentication processing unit 133 has the user input data on multiple documents or images that the user has obtained in connection with each of the user's multiple actions as the user's answer to the secret question, and compares a hash value based on the data on the multiple documents or images with a hash value that has been stored in advance as the correct answer to verify the user's identity.

[0321] The authentication processing unit 133 verifies the identity of the person by comparing the characteristics of the input document or image data with characteristics stored in advance as correct answers.

[0322] The authentication processing unit 133 prompts the user to input data of an email received by the user in relation to the user's purchasing behavior as the user's answer to the secret question.

[0323] From another perspective, the information processing device (terminal device 10 and server device 100) according to the present application includes a management unit 134 that manages information on the person to be authenticated and the person to whom the authority is delegated designated by the person to be authenticated, and an authentication processing unit 133 that, in response to a request for account recovery from the person to be authenticated, performs account recovery for the person to be authenticated with the approval of the person to whom the authority is delegated.

[0324] The management unit 134 accepts registration of the account of the authority delegatee as a recovery collaborator from the person to be authenticated, and manages the account of the person to be authenticated and the account of the authority delegatee in association with each other.

[0325] In response to a recovery request from the terminal device of the person to be authenticated, the authentication processing unit 133 sends a recovery authorization request including a challenge to the terminal device of the person to be authenticated via the terminal device of the person to be authenticated, and receives a recovery authorization response including a signed challenge from the terminal device of the person to be authenticated via the terminal device of the person to be authenticated in response to the recovery authorization request, and if the signature verification is successful, performs account recovery for the person to be authenticated.

[0326] The authentication processing unit 133 receives a recovery authorization response including a signed challenge that the delegatee has generated by signing the challenge as approval for the recovery authorization request.

[0327] If the signature verification is successful, the authentication processing unit 133 confirms that the authority delegatee is a recovery cooperator and performs account recovery for the person to be authenticated.

[0328] Data is transmitted and received between the terminal device of the person to be authenticated and the terminal device of the person to whom the authority is delegated via short-range wireless communication.

[0329] The management unit 134 manages information on the child who is the subject of authentication and the parent who is the delegatee of authority. In response to a request for account recovery from the child, the authentication processing unit 133 recovers the child's account with the parent's approval. At this time, the authentication processing unit 133 performs FIDO authentication on the parent.

[0330] By performing any one or a combination of the above-described processes, the information processing device according to the present application can provide a method for dynamically creating secret questions in authentication technology.

[0331] [8. Hardware Configuration] The terminal device 10 and the server device 100 according to the above-described embodiments are realized by a computer 1000 having a configuration as shown in Fig. 18, for example. The following description will be given taking the server device 100 as an example. Fig. 18 is a diagram showing an example of a hardware configuration. The computer 1000 is connected to an output device 1010 and an input device 1020, and has a configuration in which a calculation device 1030, a primary storage device 1040, a secondary storage device 1050, an output I / F (Interface) 1060, an input I / F 1070, and a network I / F 1080 are connected via a bus 1090.

[0332] The arithmetic device 1030 operates based on programs stored in the primary storage device 1040 and the secondary storage device 1050, programs read from the input device 1020, and the like, and executes various processes. The arithmetic device 1030 is realized by, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or the like.

[0333] The primary storage device 1040 is a memory device such as a RAM (Random Access Memory) that temporarily stores data used by the arithmetic device 1030 for various calculations. The secondary storage device 1050 is a storage device in which data used by the arithmetic device 1030 for various calculations and various databases are registered, and is realized by a ROM (Read Only Memory), an HDD (Hard Disk Drive), an SSD (Solid State Drive), a flash memory, or the like. The secondary storage device 1050 may be an internal storage device or an external storage device. The secondary storage device 1050 may also be a removable storage medium such as a USB (Universal Serial Bus) memory or an SD (Secure Digital) memory card. The secondary storage device 1050 may also be cloud storage (online storage), a NAS (Network Attached Storage), a file server, or the like.

[0334] The output I / F 1060 is an interface for transmitting information to be output to an output device 1010 that outputs various types of information, such as a display, a projector, a printer, etc., and is realized by a connector conforming to a standard such as USB (Universal Serial Bus), DVI (Digital Visual Interface), or HDMI (High Definition Multimedia Interface), etc. The input I / F 1070 is an interface for receiving information from various input devices 1020, such as a mouse, a keyboard, a keypad, a button, a scanner, etc., and is realized by a USB, etc.

[0335] Furthermore, the output I / F 1060 and the input I / F 1070 may be wirelessly connected to the output device 1010 and the input device 1020, respectively. That is, the output device 1010 and the input device 1020 may be wireless devices.

[0336] The output device 1010 and the input device 1020 may be integrated into one device, such as a touch panel. In this case, the output I / F 1060 and the input I / F 1070 may also be integrated into one device as an input / output I / F.

[0337] The input device 1020 may be a device that reads information from, for example, an optical recording medium such as a CD (Compact Disc), a DVD (Digital Versatile Disc), or a PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory.

[0338] The network I / F 1080 receives data from other devices via the network N and sends it to the arithmetic device 1030, and also transmits data generated by the arithmetic device 1030 to other devices via the network N.

[0339] The arithmetic unit 1030 controls the output device 1010 and the input device 1020 via the output I / F 1060 and the input I / F 1070. For example, the arithmetic unit 1030 loads a program from the input device 1020 or the secondary storage device 1050 onto the primary storage device 1040 and executes the loaded program.

[0340] For example, when the computer 1000 functions as the server device 100, the arithmetic unit 1030 of the computer 1000 executes a program loaded onto the primary storage device 1040 to realize the functions of the control unit 130. The arithmetic unit 1030 of the computer 1000 may also load a program acquired from another device via the network I / F 1080 onto the primary storage device 1040 and execute the loaded program. The arithmetic unit 1030 of the computer 1000 may also cooperate with the other device via the network I / F 1080 to call and use the functions and data of a program from another program of the other device.

[0341] [9. Other] Although the embodiments of the present application have been described above, the present invention is not limited to the contents of these embodiments. Furthermore, the above-described components include those that can be easily imagined by a person skilled in the art, those that are substantially the same, and those that are within the scope of so-called equivalents. Furthermore, the above-described components can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the spirit of the above-described embodiments.

[0342] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method. In addition, the information including the processing procedures, specific names, various data, and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. For example, the various information shown in each drawing is not limited to the information shown in the drawings.

[0343] Furthermore, the components of each device shown in the figure are conceptual functional components and do not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0344] For example, the above-mentioned server device 100 may be realized by multiple server computers, and depending on the function, the configuration can be flexibly changed, such as by calling an external platform using an API (Application Programming Interface) or network computing.

[0345] Furthermore, the above-described embodiments and modifications can be combined as appropriate within the scope of not causing any contradiction in the processing content.

[0346] Furthermore, the above-mentioned "section, module, unit" can be read as "means" or "circuit," etc. For example, an acquisition unit can be read as an acquisition means or an acquisition circuit. [Explanation of symbols]

[0347] 1. Information Processing Systems 10 Terminal Equipment 100 Server device 110 Communications Department 120 Storage section 121 User Information Database 122 Historical Information Database 123 Credentials Database 124 Policy Information Database 130 control section 131 Acquisition Department 132 Generation part 133 Authentication processing section 134 Management Department 135 Provision Department

Claims

1. a generation unit that, in response to an access request from a user, extracts events to be questioned from multiple types of action logs of the user, creates a question template in which one or more questions are determined from the events, determines a question item generation policy for generating secret questions, dynamically generates secret questions and correct answers for identity verification based on the question item generation policy, generates an authentication screen including the secret questions, and provides the authentication screen including the secret questions to the user as an authentication request; an authentication processing unit that receives an answer to the secret question entered by the user on the authentication screen, compares the received answer from the user with the correct answer created together with the secret question, and determines that the authentication has been successful if the answers match, and provides the user with a result screen regarding the authentication result as an access response; An information processing device comprising:

2. The generation unit identifies and extracts, from the plurality of behavior logs of the user, at least one of a purchase history, which is a history of the user's product purchases or service usage, a posting history, which is a history of the user's posts on SNS, and a payment history, which is a history of electronic payments using a payment app on the user's terminal device, as a question target log, and identifies and extracts question items from the identified and extracted question target logs.

2. The information processing apparatus according to claim 1, wherein:

3. The generation unit identifies and extracts, from the purchase history of the user, at least one of date and time, product, price, product model or brand, product type, purchase store, frequency from multiple purchase histories, pattern, frequently purchased store, and cycle as a question item.

3. The information processing apparatus according to claim 2, wherein:

4. The generation unit identifies and extracts, from the user's SNS posting history, at least one of date and time, communication partner, posting destination, conversation content, frequency from multiple posts, pattern, and frequent conversation partner as a question item.

3. The information processing apparatus according to claim 2, wherein:

5. The generation unit identifies and extracts, from the user's payment history, at least one of date and time, store, amount, frequency and pattern of multiple transactions, and frequently visited stores as question items.

3. The information processing apparatus according to claim 1, wherein the information processing apparatus is a computer.

6. The generation unit extracts one event that is the subject of a question from the data set of the question target log.

3. The information processing apparatus according to claim 1, wherein the information processing apparatus is a computer.

7. The generation unit determines, as the question item generation policy, a policy for inputting answers to questions in free text, or a policy for inputting answers to questions in multiple-choice format.

3. The information processing apparatus according to claim 1, wherein the information processing apparatus is a computer.

8. The generation unit inputs, as a dummy question, a question that the user cannot answer or a question for which no answer is a correct answer to the secret question, and when the answer format to the secret question is multiple choice, sets no correct answer or skip as an answer to the dummy question.

8. The information processing apparatus according to claim 7,

9. The generation unit inputs, as a dummy question, a question that the user cannot answer or a question for which no answer is a correct answer, into the secret question, and when the answer format for the secret question is to input an answer in free text, the generation unit accepts a blank answer or an answer that is not input as an answer to the dummy question.

8. The information processing apparatus according to claim 7,

10. The generation unit utilizes an action log across multiple services, rather than for each service, and generates the secret question by including two or more question items instead of one.

3. The information processing apparatus according to claim 1, wherein the information processing apparatus is a computer.

11. The authentication processing unit has the user input data of a plurality of documents or images obtained by the user in connection with each of a plurality of actions of the user as answers to the secret questions, and verifies the identity of the user by comparing a hash value based on the data of the plurality of documents or images with a hash value stored in advance as a correct answer.

3. The information processing apparatus according to claim 1, wherein the information processing apparatus is a computer.

12. The authentication processing unit has the user input document or image data obtained by the user in connection with the user's actions as an answer to the secret question, and verifies the user's identity by comparing the characteristics of the input document or image data with characteristics stored in advance as correct answers.

3. The information processing apparatus according to claim 1, wherein the information processing apparatus is a computer.

13. The authentication processing unit prompts the user to input data of emails received by the user in relation to the user's purchasing behavior as the user's answers to the secret questions, and verifies the user's identity by comparing a combination of the contents of each email related to the user's multiple purchasing behaviors with pre-registered correct answer data.

3. The information processing apparatus according to claim 1, wherein the information processing apparatus is a computer.

14. An information processing method executed by an information processing device, a generation step of extracting events to be questioned from multiple types of action logs of the user in response to an access request from the user, creating a question template in which one or more questions are determined from the events, determining a question item generation policy for generating secret questions, dynamically generating secret questions and correct answers for identity verification based on the question item generation policy, generating an authentication screen including the secret questions, and providing the authentication screen including the secret questions to the user as an authentication request; an authentication processing step of receiving an answer to the secret question entered by the user on the authentication screen, comparing the received answer from the user with the correct answer created together with the secret question, determining that the authentication was successful if they match, and providing the user with a result screen regarding the authentication result as an access response; An information processing method comprising:

15. a generation procedure of extracting events to be questioned from multiple types of action logs of the user in response to an access request from the user, creating a question template in which one or more questions are determined from the events, determining a question item generation policy for generating secret questions, dynamically generating secret questions and correct answers for identity verification based on the question item generation policy, generating an authentication screen including the secret questions, and providing the authentication screen including the secret questions to the user as an authentication request; an authentication processing procedure of receiving an answer to the secret question entered by the user on the authentication screen, comparing the received answer from the user with the correct answer created together with the secret question, and determining that the authentication was successful if they match, and providing the user with a result screen regarding the authentication result as an access response; An information processing program characterized by causing a computer to execute the above.

Citation Information

Patent Citations

  • Authentication system

    JP2005190452A

  • Transaction management program and transaction management method

    JP2008269054A

  • Personal authentication system using image corresponding to action history, authentication method, and authentication program

    JP2014153859A

  • Server device, program, and system

    JP2015213743A

  • System and method for authenticating user by using history of user

    JP2017076380A