Information processing device, information processing method, and program
The information processing device streamlines service application by deriving and sharing user trustworthiness across services, addressing the inconvenience of repetitive verification in electronic payment systems, thus enhancing user convenience and provider efficiency.
Patent Information
- Application Number
- JP2023084194
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2023-05-22
- Publication Date
- 2025-10-01
- Estimated Expiration
- 2042-08-04
AI Technical Summary
Existing electronic payment systems are inconvenient for users and service providers due to the need for repetitive and burdensome identity verification and information input when applying for additional services.
An information processing device and method that derives user trustworthiness based on user information and communication information, allowing seamless integration and sharing of identity verification results across different services, thereby reducing the need for redundant information input and verification.
Enhances user convenience by streamlining the application process for additional services by leveraging existing identity verification data, reducing user burden and improving service provider efficiency.
Smart Images

Figure 0007747689000001 
Figure 0007747689000002 
Figure 0007747689000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to an information processing device, an information processing method, and a program. [Background technology]
[0002] BACKGROUND ART Conventionally, in electronic commerce, a system is known in which electronic authentication is performed to verify the identity of a person and electronic payment is made based on the electronic authentication (see, for example, Patent Document 1). [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2002-123726 Summary of the Invention [Problem to be solved by the invention]
[0004] However, the above-mentioned devices may be less convenient for users or service providers.
[0005] The present invention has been made in consideration of the above circumstances, and one of its objects is to provide an information processing device, an information processing method, and a program that can improve user convenience. [Means for solving the problem]
[0006] One aspect of the present invention is an information processing device comprising: a first acquisition unit that acquires user information, which is information about a store where a user has used an electronic payment service; a second acquisition unit that acquires communication information, which is one or both of information about a device used by the user to use the electronic payment service and information about a network used by the user; a derivation unit that derives the user's trustworthiness based on the user information and the communication information; and a provision unit that provides the trustworthiness to a service server that provides a service different from the electronic payment service. [Effects of the Invention]
[0007] According to one aspect of the present invention, it is possible to provide an information processing device, an information processing method, and a program that can improve user convenience. [Brief explanation of the drawings]
[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. [Figure 2] FIG. 1 is a sequence diagram illustrating an example of the general flow of electronic payment in Pattern 1. [Figure 3] FIG. 10 is a sequence diagram illustrating the general flow of electronic payment in Pattern 2. [Figure 4] FIG. 2 is a configuration diagram of a payment server 100. [Figure 5] FIG. 10 is a diagram showing an example of the contents of user information 172. [Figure 6] FIG. 10 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] This is a conceptual diagram of the processing (part 1). [Figure 8] This is a conceptual diagram of the processing (part 2). [Figure 9] 10 is a diagram illustrating the functional configuration of a first management unit 128 and a second management unit 130. FIG. [Figure 10] 10 is a diagram showing an example of information registered by a second management unit 130. FIG. [Figure 11] FIG. 2 shows a mini appli 30 included in the payment appli 20. [Figure 12] FIG. 2 is a diagram showing an example of an interface image IM1. [Figure 13] FIG. 10 is a diagram for explaining the process of opening a bank account using the mini appli 30. [Figure 14] FIG. 10 is a diagram showing an example of an interface screen IM8. [Figure 15]FIG. 10 is a diagram for explaining the process when applying for use of a predetermined service using the mini appli 30. [Figure 16] FIG. 10 is a sequence diagram showing an example of a flow of processing executed by a service system and a payment system. [Figure 17] This is a conceptual diagram of information sharing. [Figure 18] FIG. 10 is a conceptual diagram of providing a result of identity verification. [Figure 19] FIG. 10 is a diagram for explaining a process for correcting information on an input content confirmation screen. [Figure 20] FIG. 10 is a sequence diagram showing an example of a flow of processing executed by a service system and a payment system. [Figure 21] FIG. 10 is a diagram for explaining the conditions for applying for a service provided by a service system using a mini appli 30. [Figure 22] 10 is a flowchart illustrating an example of the flow of an authentication process. [Figure 23] 10A and 10B are diagrams illustrating an example of transition of an interface screen when authentication is performed. [Figure 24] FIG. 17 is a diagram showing an example of the contents of user information 172A according to the second embodiment. [Figure 25] FIG. 10 is a diagram illustrating conditions under which a flag is set. [Figure 26] FIG. 10 is a diagram illustrating a part of the functional configuration of a payment server 100A according to a second embodiment. [Figure 27] FIG. 10 is a diagram for explaining the processing of another example (1). DETAILED DESCRIPTION OF THE INVENTION
[0009] A payment management device, a payment management system, an electronic payment application, a payment management method, and a program according to the present invention will be described below with reference to the drawings. Also, an information processing device, an information processing method, and a program will be described below with reference to the drawings.
[0010] The service management device is realized by one or more processors. The service management device provides a service, and includes a control unit (e.g., a content providing unit) that executes processing to: when a user operates a button for starting a first service included in a first interface screen displayed on a display unit of a user terminal device while logged in to use a service app, and the first information, which is information required for the application including first information and second information, is not stored in a storage device managed by the service, display a second interface screen on the display unit for prompting the user to input the first information; and when the button is operated and the first information, which is information required for the application, is stored in the storage device, display a third interface screen on the display unit for prompting the user to input the second information into a first mini app running in the service app and providing the first service. The service may be any service, such as an electronic payment service, a chat app, or a social networking service. The following description will be given assuming an electronic payment service as an example.
[0011] The first information is, for example, information acquired by a user entering information on an interface screen provided by an electronic payment app. The second information is, for example, information acquired by a user entering information on an interface screen provided by a mini app. The first information is, for example, information required for using the service of the first mini app and for using a service of a mini app different from the first mini app. The second information is, for example, information required for using the service of the first mini app. The first interface screen may be a screen including a button for starting the service. The first interface screen may be a screen provided by an electronic payment app or a screen provided by a mini app. The button for starting the service of the first service is a button operated to start using the service, and is, for example, a button corresponding to an operation that triggers the user to use the service by providing user information to a service server when using the service. In other words, the button for starting the service can also be referred to as an application button for applying for the service.
[0012] The process of displaying the third interface screen on the display unit refers to displaying the third interface screen on the display unit in cooperation with the first mini app or a service server corresponding to the first mini app, for example, by the control unit instructing the first mini app or the service server to display the third interface screen.
[0013] A payment management device that provides electronic payment services, comprising: a control unit that displays a first interface screen on a display unit when a user is logged in to use an electronic payment app; when an application button included on the first interface screen for applying to use another service is operated, and when the user's usage of the electronic payment service meets the conditions set in the electronic payment service and the user's identity verification has been completed in the electronic payment service, provides completion information indicating that the identity verification has been completed to a service server that operates in the electronic payment app and provides the other service to the user in cooperation with a mini-app that provides the other service, and instructs the service server to proceed with processing related to the application; and when the application button is operated and the set conditions are not met or the user's identity verification has not been completed, causes the service server to at least temporarily suspend the application.
[0014] The above-mentioned "instructing the service server to proceed with the processing related to the application" means, for example, having the mini app or service server display an interface screen for application on a display unit or provide the service. "Temporarily suspending" means, for example, having the payment app, payment server, mini app, or service server display an interface screen on a display unit indicating that the service is unavailable, or providing information indicating that identity verification or predetermined processing, screening, etc. is required.
[0015] The information processing device includes a first acquisition unit that acquires user information, which is one or both of the user's usage pattern of the electronic payment service and information about the user provided by the user to use the electronic payment service; a second acquisition unit that acquires communication information, which is one or both of information about the device the user uses to use the electronic payment service and information about the network the user uses; a derivation unit that derives the user's trustworthiness based on the user information and the communication information; and a provision unit (e.g., a first management unit) that provides the trustworthiness to a service server that provides a service different from the electronic payment service (see second embodiment).
[0016] First Embodiment [Electronic payment service] FIG. 1 shows an example of a configuration for realizing an electronic payment service. The electronic payment service is realized mainly around a payment server 100. The payment server 100 communicates with, for example, one or more user terminal devices 10, one or more first store terminal devices 50, one or more second store terminal devices 70, and one or more service servers 200-1 to 200-3 via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, etc. Hereinafter, when there is no need to distinguish between the service servers 200-1 to 200-3, they will be referred to as service servers 200. The payment server 100 is an example of a "payment management device" or "service management device."
[0017] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input acceptance function, and a program execution function. In the following description, the components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as a CPU executes a payment application 20, which operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment application 20 controls the camera, communication device, touch panel, etc.
[0018] The first store terminal device 50 is installed, for example, in a store. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).
[0019] The second store terminal device 70 is used by the operator of the affiliated store. The second store terminal device 70 is a smartphone, tablet terminal, personal computer, etc. An interface for affiliated stores 72 runs on the second store terminal device 70. The interface for affiliated stores 72 may be an app for affiliated stores or a browser. The interface for affiliated stores 72 accepts coupon settings and the like from the operator of the affiliated store and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image and reading the code image displayed by the user terminal device 10 by executing the app for affiliated stores.
[0020] The payment server 100 performs electronic payment based on payment information received from the user terminal 10 or the first store terminal 50. The first store terminal 50 may include a POS device and a member store server. In this case, payment information is sent from the POS device to the payment server 100 via the member store server. In the following description, this distinction is not made and payment information is assumed to be sent from the first store terminal 50. The payment server 100 performs electronic payment, for example, by decreasing the charge balance managed in association with the user ID and increasing the item value of the member store's sales. The item value of the member store's sales is not used as electronic money itself, for example, but rather the amount corresponding to the item value of the sales is transferred to a bank account at a cycle determined by an agreement between the member store and the electronic payment service. Electronic payment may include methods such as revolving payments and credit payments that allow purchases of amounts greater than the charge balance at the time of purchase.
[0021] 2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns for electronic payment: Pattern 1 and Pattern 2.
[0022] In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 10, with the payment application 20 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is the domain of the electronic payment service to which store identification information has been added, and is associated with an affiliated store ID, store ID, etc. in the payment server 100 (described below). The payment application 20 sends first payment information including the store URL and account ID to the payment server 100 (S2). The payment server 100 searches for store information (described below) using the affiliated store ID and store ID corresponding to the store URL, acquires the affiliated store name and store name information (S3), and sends this to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen displaying the affiliated store name and store name (S5). The user terminal device 10 then generates second payment information including at least the payment amount and transmits it to the payment server 100 (S6). The payment server 100 completes the electronic payment as described above based on the received second payment information (S7). The payment server 100 then transmits a payment completion notice (information for displaying a payment completion screen) to the payment app 20 (S8), and the payment app 20 displays the payment completion screen (S9). Note that the store code image 60 may include not only the store URL but also information on the payment amount. In this case, the step of the user inputting the payment amount is omitted. For example, the payment app 20 displays a screen on which the payment amount has been input on the display unit, so the above-mentioned S5 is omitted. When the user confirms the amount and performs a predetermined operation, first payment information including the payment amount is transmitted to the payment server 100. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.
[0023] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, when the payment app 20 is launched, when a payment operation is performed using the payment app 20, or when the automatic update timing arrives, the payment app 20 sends a request to issue a one-time code (corresponding to user identification information) to the payment server 100 (S11). The payment server 100 generates the one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image, such as a QR code or barcode, generated based on the one-time code (S14). The user holds (presents) the display surface of the user terminal device 10 over the first in-store terminal device 50, and the first in-store terminal device 50 decodes the code image using its optical reading function and acquires the one-time code (S15). The first in-store terminal device 50 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode, manually entering it, etc. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and completes the electronic payment as described above (S17). Then, the payment server 100 sends a payment completion notice to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).
[0024] Note that electronic payment may be performed using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuing a one-time code may be omitted in store scanning, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.
[0025] [Payment server] 4 is a configuration diagram of the payment server 100. The payment server 100 includes, for example, a communication unit 110, a login status management unit 120, a content providing unit 122, a payment processing unit 124, an information processing unit 126, a first management unit 128, and a second management unit 130. The components other than the communication unit 110 and the storage unit 170 are realized by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a GPU (Graphics Processing Unit), or may be realized by a combination of software and hardware. The program may be stored in advance in a storage device (a storage device having a non-transitory storage medium) such as an HDD (Hard Disk Drive) or a flash memory, or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device. Note that part of the processing executed by the payment app 20 may be executed by the payment server 100, and part of the processing executed by the payment server 100 may be executed by the payment app 20. Some of the functional configurations included in the payment server 100 may be included in other devices. For example, the first management unit 128 and the second management unit 130 may be included in other devices different from the payment server 100. In the present embodiment, as an example, the first management unit 128 and the second management unit 130 are described as being included in the payment server 100.
[0026] The storage unit 170 is a HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device that the payment server 100 can access via a network. The storage unit 170 stores information such as user information 172, payment content information 174, and affiliated store / shop information 176.
[0027] The communication unit 110 is a communication interface for connecting to the network NW, and is, for example, a network interface card.
[0028] The login status management unit 120 manages the login status of each user. For example, the login status management unit 120 permits login based on the phone number and password entered by the user, and transitions the status from the login status to the logout status based on the logout operation by the user.
[0029] The content providing unit 122 has, for example, a function of a web server, and provides information (content and interface screens) for displaying various screens of the electronic payment service to the user terminal device 10. The content providing unit 122 reads out necessary content from the payment content information 174 as appropriate and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs from the user while content is being played by the payment application 20, and transmits the above-mentioned payment information and the like to the payment server 100.
[0030] The payment processing unit 124 performs payment processing based on the payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 124 performs payment processing while referring to the user information 172.
[0031] The information processing unit 126 searches for information managed in the user information 172 and determines whether desired information is managed. The processing of the first management unit 128 and the second management unit 130 will be described in detail later.
[0032] FIG. 5 is a diagram showing an example of the contents of user information 172. User information 172 is an example of user registration information. User information 172 includes, for example, a user URL, account ID, phone number, and password, as well as email address, user ID, name, address, date of birth, registration date, charge balance, bank account, credit card number, other service link information, radio wave authentication settings, carrier payment settings, chat friend list, charge history information, payment history information, and chat history information. When registering for an electronic payment service, registration of a phone number and password is required. The account ID is issued to the user by the payment server 100, and the user ID can be set arbitrarily by the user (or does not have to be set). All other information, other than the user URL, account ID, phone number, password, registration date, charge balance, charge history information, and payment history information, can be set arbitrarily by the user. Hereinafter, a user instance (electronic payment account) associated with this information is referred to as an account. The user URL is used for remittance processing between users. The registration date is the date on which the user registered with the electronic payment service (the date on which the account was created).
[0033] The charge balance is information indicating the balance of electronic money set by a user by transferring funds to the account in advance. Transfer methods include transfers from an ATM (Automatic Teller Machine) of a designated service provider (bank) or from a registered bank account. The bank account and credit card number are information (account number, card number) of a bank account or credit card number that can be used to deposit funds into the electronic payment service. The other service link information is the login ID of another service that links with the electronic payment service (for example, operated by an operator belonging to the same business group). The radio wave authentication setting is setting information for authentication through communication with a specific telecommunications carrier. The carrier payment setting is setting information for transferring at least a portion of payments made using the electronic payment service to a telecommunications carrier. The chat friend list is a list of other users who can chat with the user using the chat function provided by the electronic payment service. The charge history information is a history of the user's transfers to the electronic payment service in advance to increase the charge balance. The payment history information is information that indicates the details of the payment made by the user (date and time, store ID of the store where the purchase was made, payment amount, etc.) for each payment. The chat history information is a history of the content of the chats that the user has had.
[0034] 6 is a diagram showing an example of the contents of affiliated store / store information 176. Store information 176 includes, for example, a first table 176A in which affiliated store IDs and store IDs are associated with store URLs, a second table 176B in which affiliated store IDs are associated with affiliated store names and sales amounts (described above), and a third table 176C in which store IDs are associated with store names. In addition to this information, affiliated store / store information 176 may also include information such as affiliated store or store categories, store locations, and payment patterns.
[0035] Information processing unit 126 manages various types of information. Information processing unit 126 manages information obtained from payment application 20 and information obtained from service server 200, and provides information held by payment server 100 to payment application 20 and service server 200.
[0036] [Service Server] Service server 200 is a server device that provides a service different from the electronic payment service provided in the electronic payment service. Service server 200 cooperates with payment application 20 and payment server 100 to provide a service to the user within the electronic payment service. Service server 200 provides a service in response to, for example, a user's operation on mini app 30, which will be described later.
[0037] [Processing Overview] The payment server 100 collects information from other services (service servers 200), aggregates the collected information, and manages it. The payment server 100 provides some or all of the aggregated information to other services. Figure 7 is a conceptual diagram (part 1) of the process. Through this process, for example, when a user applies for a service as described below, the payment server 100 provides information to the service. The service can accept the application by using the provided information. For example, pre-filling is expanded because the user can pre-fill user information based on aggregated information in fields to be entered. Pre-filling means that user information is entered into an input field in advance without user operation. The payment server 100 can also perform various analyses using the aggregated information to optimize marketing.
[0038] Furthermore, the payment server 100 can provide the service server 200 with either or both of the result of identity verification (so-called eKYC: electronic Know Your Customer) performed at the start of a predetermined transaction in the payment service and information provided by the user for identity verification. This allows the service server 200 to avoid having to newly perform identity verification or receive the same information.
[0039] FIG. 8 is a conceptual diagram of the process (part 2). For example, when using an electronic payment service, a user provides customer information to the electronic payment service, as well as documents for identity verification and an image capturing the required facial features. The electronic payment service then uses the provided information to verify the user's identity, allowing the user to use the electronic payment service. Identity verification is a process of verifying whether the information entered by the user matches the information provided by the user for identity verification (e.g., an identity verification document or an image captured by the user). For example, identity verification is complete when the information entered by the user matches the information on a driver's license, which is an identity verification document, and the image on the driver's license matches the user's appearance in the captured image. Identity verification may be performed automatically by computer processing, or part or all of the process may be performed by staff. Identity verification may also be performed using public personal authentication. For example, identity verification may be performed using electronic information from a My Number card.
[0040] When identity verification is complete, the payment server 100 acquires information indicating that identity verification has been completed. If the user subsequently wishes to use deferred payment, asset management, or banking services provided in the electronic payment service, the user must apply separately for the use of these services.
[0041] For example, if the processing of this embodiment is not performed, a user must input customer information, provide documents for identity verification, and an image of the required appearance to service server 200 when applying for each service, and service server 200 must then perform screening, authentication, etc. In this way, inputting and providing information when applying for each service places a heavy burden on the user. Furthermore, it is inconvenient for the service provider because users are more likely to abandon the application process midway.
[0042] Therefore, in this embodiment, the payment server 100 provides the user's information, the authentication result of the identity verification, etc. to the other service servers 200, thereby helping the user to use the services without the user having to provide information to each service. This will be explained in detail below.
[0043] [Explanation of the functional configuration of the first management unit (information providing unit) and the second management unit (acquiring unit)] 9 is a diagram illustrating the functional configuration of the first management unit 128 and the second management unit 130. The first management unit 128 provides user information and information managed by the payment server 100 (e.g., authentication results for identity verification) in response to a request from the service server 200. For example, when a user applies for a service, the service server 200 requests the payment server 100 to provide user information necessary for the application, and obtains information in response to the request from the first management unit 128.
[0044] The second management unit 130 receives information provided by a user via the service server 200 from the service server 200 and information managed by the service server 200, and acquires this information. The second management unit 130 stores the provided information in the storage unit 170. For example, when the second management unit 130 receives information about a specific user, the second management unit 130 registers the provided information in association with the identification information of the user in the storage unit 170. One or both of the first management unit 128 and the second management unit 130 are interfaces that function as APIs (Application Programming Interfaces).
[0045] For example, the second management unit 130 can acquire information acquired by the asset management service server 200, and the first management unit 128 can provide the information acquired by the asset management service server 200 to the bank service server 200. This allows the payment server 100 to act as a hub for different services, allowing information acquired by each service to be shared among the different services. The above process is an example of a process in which "the second information acquired by the acquisition unit (information acquired by the asset management service server 200) is provided to a second service server (e.g., a bank service server) corresponding to a second mini-app that runs in the electronic payment app and provides another service."
[0046] FIG. 10 is a diagram showing an example of information registered by second management unit 130. This information is, for example, information included in user information 172. This user information 172 is, for example, information in which information IF1 (first information) and information IF2 (second information) are associated with a user ID (or account ID). Information IF1 is user information acquired by payment application 20 and payment server 100. Information IF1 includes, for example, information indicating the user's name, address, date of birth, occupation, status, confirmation date and time, confirmation method, and confirmation subject. The status is information indicating whether or not a predetermined confirmation has been performed. In the example of FIG. 10, for example, the information indicates that identity verification has been completed. The confirmation date and time is the date and time when identity verification was performed. The verification method is information indicating the document used for identity verification. The document is, for example, a driver's license or a My Number card. The verification subject is the party that performed identity verification. In the example of FIG. 10, identity verification is performed by the administrator of the electronic payment service.
[0047] Information IF2 is information (information registered by the second management unit 130) provided by the mini app 30 and service server 200, which will be described later. Information IF2 is, for example, information entered by the user into an interface screen that the mini app 30 and service server 200 cause to be displayed on the display unit of the user terminal device 10.
[0048] As described above, the types of information IF1 (first information) and information IF2 (second information) may be predetermined or may be dynamically changed. For example, payment server 100 may define stored user information as information IF1 and other information as information IF2. For example, the user's name, attributes, contact information, and place of employment may be defined as information IF1, and the rest may be defined as information IF2. In this case, whether payment server 100 defines information IF2 or not, mini app 30 may provide the user with an interface screen (e.g., interface screen IM7 in FIG. 13 or interface screen IM10 in FIG. 15, which will be described later) and define the information entered by the user as information IF2. Furthermore, if payment server 100 defines information IF2, payment application 20 may display an interface screen including information IF2 on the display unit of user terminal device 10 and request the user to confirm the information.
[0049] As described above, the user information 172 of the payment server 100 manages information provided within the electronic payment service and information provided in other services.
[0050] [Interface image including a launch button to launch the mini-app] The payment app includes one or more mini apps 30. FIG. 11 is a diagram showing the mini apps 30 included in the payment app 20. The mini app 30 is, for example, an app that uses the payment app 20 as a platform. The mini app 30 is, for example, an application program developed by a service provider that provides the service of the service server 200 to run within the payment app 20. The service provider develops the mini app 30 by referencing an SDK (Software Development Kit), which is a program and technical documentation for app development provided by the administrator of the payment app 20. The mini app 30 is, for example, an app that runs while the payment app 20 is running. For example, some or all of the mini app 30 may be installed when the payment app 20 is installed, or some or all of the mini app 30 may be installed from the service server 200 that corresponds to the mini app 30.
[0051] The content provider 122 or the payment application 20 causes the display unit of the user terminal device 10 to display an interface image including a launch button for launching the mini application 30. For example, the content provider 122 causes the payment application 20 to display an interface image IM1, which will be described later.
[0052] FIG. 12 is a diagram showing an example of interface image IM1. Interface screen IM1 (an example of a first interface screen) is content provided in the electronic payment service, and includes QR codes (registered trademark) and barcodes used in electronic payments, as well as information about various electronic payment-related services. Area AR1 of interface image IM1 includes one or more buttons for launching mini app 30. When launch button B1 is operated, the bank's mini app 30 is launched. The mini app 30 provides a service to the user in cooperation with, for example, the bank's service server 200.
[0053] [Processing related to the use of Mini Apps (Part 1)] FIG. 13 is a diagram illustrating the process of opening a bank account using the mini appli 30. In response to a user operation, the mini appli 30 cooperates with the service server 200 to display an interface screen IM2 (another example of a first interface screen) on the display unit. When a button for opening a bank account on the interface screen IM2 (for example, B2 or B3 in FIG. 13) is operated, the information processing unit 126 of the payment server 100 acquires information indicating that the operation has been performed, and determines whether the user's name, attributes (for example, date of birth, nationality, occupation, etc.), contact information, place of employment, and other information is registered in the user information 172. This information is acquired or managed by the payment server 100. Note that the information processing unit 126 may perform this determination in response to a request from the service server 200. B2 or B3 in FIG. 13 is an example of a "start button" or an "apply button." Also, button B1 in FIG. 12 is another example of a "start button" or an "apply button." For example, if operating button B1 in FIG. 12 starts the process of applying for use of the service, button B1 may be a "start button" or an "application button."
[0054] For example, if the user's name, attributes, contact information, and place of employment information are not registered (if the first information is not stored in the storage device managed by the electronic payment service), the payment server 100 and the payment application 20 display interface screens IM3, IM4, IM5, and IM6 on the display unit (interface screens for registered information are omitted). The interface screens IM3, IM4, IM5, and IM6 are examples of "second interface screens."
[0055] Interface screen IM3 is a screen for the user to input their name, interface screen IM4 is a screen for the user to input their attributes, interface screen IM5 is a screen for the user to input their contact information, and interface screen IM6 is a screen for the user to input their place of employment. For example, information indicating that the information input on the interface screen will be registered in the user information 172 of the electronic payment service and will also be used in mini appli 30 (other services) is displayed. For example, information such as "This information will be registered in the user information of the electronic payment service and will also be used in mini appli 30" is displayed. When a predetermined button is operated, the user is deemed to have consented to the input information being used in mini appli 30.
[0056] If the information entered or provided by the user requires review or authentication, the payment server 100 and the payment app 20 display an interface screen (not shown) for the review or authentication. For example, an interface screen for attaching or capturing an image of a driver's license, My Number card, or the user is provided. When the image is attached to the interface screen and sent to the payment server 100, the payment server 100 performs a predetermined review or authentication, and processing is performed according to the results of the review or authentication. For example, if the review or authentication is positive, the information used for the review or authentication and the results of the review or authentication are registered in user information 172. If the review or authentication is negative, the payment server 100 requests the user to provide other information. Note that the review and authentication may take a certain amount of time. If this takes time, the user may stop inputting information here, wait for the review, and resume inputting after the review. Alternatively, if the service providing the mini app 30 allows this, the user may continue inputting information other than that awaiting review.
[0057] After acquiring the predetermined information, payment server 100 associates the acquired information with the user identification information in user information 172, stores the associated information in storage unit 170, and provides the stored information to service server 200. Payment server 100 may provide service server 200 with the acquired information in response to acquiring the predetermined information, or may provide service server 200 with the acquired information in response to a request from service server 200. Mini app 30 and service server 200 display interface screen IM7 on the display unit. Interface screen IM7 contains information required for the service provided by service server 200. For example, this information is information required by a service administrator when a user applies for a service. This information is preset for each service and is, for example, information that is not registered in user information 172.
[0058] When service server 200 acquires the information required for the service, service server 200 and mini appli 30 display interface screen IM8 on the display unit. FIG. 14 is a diagram showing an example of interface screen IM8. Interface screen IM8 is a confirmation screen for the input information. For example, as described above, mini appli 30 and service server 200 display interface screen IM8 on the display unit, which includes content in which the information acquired by payment server 100 and the information acquired by service server 200 are arranged in predetermined positions. This allows the user to check their own information.
[0059] [Processing related to the use of Mini Apps (Part 2)] 15 is a diagram for explaining the process when applying for use of a predetermined service using the mini app 30. In this process, it is assumed that the user's name, attributes, contact information, and place of employment information are registered in the user information 172 (the first information is stored in the storage device).
[0060] In response to a user operation, the mini app 30 works in conjunction with the service server 200 to display an interface screen IM9 on the display unit. When a button for entering customer information on the interface screen IM9 is operated, the payment server 100 skips the process of acquiring information, and the mini app 30 and the service server 200 display an interface screen IM10 on the display unit for acquiring information (My Number) required to use the service. The interface screen IM10 is an example of a "third interface screen." If the payment server 100 holds the required information, the payment server 100 provides the required information to the service server 200.
[0061] When service server 200 acquires the information required for the service, service server 200 and mini app 30 display interface screen IM11 on the display unit, which includes content in which the information acquired by payment server 100 and the information acquired by service server 200 are arranged in predetermined positions, similar to interface screen IM8 in Fig. 14 described above. This allows the user to check information such as name and attributes entered at the start of a predetermined transaction for the payment service, and to check the information entered at the start of a predetermined transaction for the service. The process for correcting this information will be described later.
[0062] Furthermore, if multiple types of information IF1 (for example, the user's name, attributes, contact information, and workplace information) are not stored in the user information 172, the payment server 100 displays an interface screen on the display unit to prompt the user to input the not-stored type of information IF1, registers the information IF1 input on the interface screen in the user information 172 in association with the user's identification information, and provides the multiple types of information IF1 associated with the user's identification information to the service server 200. In this way, even if the payment server 100 does not store some of the information IF1, it can acquire some of the information IF1 and provide the information IF1 to the service server 200.
[0063] Note that even when information IF1 is stored in the storage unit 170, the payment server 100 may display an interface screen on the display unit of the user terminal device 10 to prompt the user to confirm the stored information IF1. This interface screen may be prefilled with, for example, the user's information IF1 stored in the storage unit 170. For example, if some of the information IF1 is not stored in the payment server 100, the payment server 100 may display an interface screen on the display unit of the user terminal device 10 to prompt the user to input the unstored information IF1, and may also display an interface screen on the display unit of the user terminal device 10 with the stored information IF1 prefilled, to prompt the user to confirm the stored information IF1. For example, if the user's name is not stored, the payment server 100 may display interface screen IM3 on the user terminal device 10. If other information IF1 is stored, the payment server 100 may display interface screens IM4-IM6 on the display unit of the user terminal device 10 with the stored information IF1 prefilled.
[0064] The above information IF1 (first information) may be information that satisfies a predetermined standard. The predetermined standard may be, for example, a standard required for applying for a service. For example, the predetermined standard may be that the name is registered in kanji, hiragana, or katakana, or that the address number is registered. When the payment server 100 stores information IF1 (first information) that does not satisfy the predetermined standard, the payment server 100 may display an interface screen (such as interface screen IM3-6) with this information prefilled on the display unit of the user terminal device 10, and may request the user to correct the information so that it satisfies the predetermined standard.
[0065] [Sequence diagram for using Mini Apps] 16 is a sequence diagram showing an example of the flow of processing executed by the service system and the payment system. The service system is one or both of mini appli 30 and service server 200, and the payment system is one or both of payment appli 20 and payment server 100. The service system and the payment system share identification information for identifying the user.
[0066] First, the user launches mini app 30 via operation of payment app 20, and when the user performs an operation to make a predetermined application provided by the service system, the service system requests the payment system to provide user information (S50). The payment system searches user information 172 (S52) and sends the search results to the service system (S54). For example, if payment server 100 holds information (first information, information IF1) that payment server 100 acquires or manages, it provides this information to the service system.
[0067] If the payment server 100 does not hold the information to be acquired or managed by the payment server 100, the payment system executes a process for inputting the information (for example, providing an interface screen) (S56). Next, the payment system provides the input information to the service system (S58). The input information is also registered in association with the user's identification information in the user information 172.
[0068] Next, the service system executes a process to have the user input information required by the service (S60). Next, the service system provides the input information to the payment system (S62). Next, the payment system registers the information in association with the user's identification information in the provided user information 172 (S64). Note that the processes of S62 and S64 may be omitted, or information for which the user has consented to sharing information with the payment system may be provided to the payment system. Furthermore, whether to omit the processes of S62 and S64 may be determined depending on the type of service system.
[0069] As described above, the service system can perform processing related to the user's use of the service using information obtained by or managed by the payment server 100. FIG. 17 is a conceptual diagram of information sharing. For example, when a user logs in to the payment application 20 and starts a transaction for another service, the service server 200 can perform screening and procedures for the start of the transaction by using information entered at the start of a predetermined transaction in the payment service, an identification document, an image of the user's appearance, etc.
[0070] This reduces the load on the service server 200 for acquiring information. In addition, the user does not need to input the same information multiple times, which reduces the load on the user.
[0071] In the above description, it has been explained that information acquired by payment server 100 is provided to service server 200. However, in addition to (or instead of) this, the result of identity verification by payment server 100 may be provided to service server 200. FIG. 18 is a conceptual diagram of providing identity verification results. For example, when a user is logged in to payment app 20 and the user starts a transaction for another service, service server 200 provides service server 200 with the result of identity verification (so-called eKYC) performed at the start of a predetermined transaction in the payment service, the result of other screening, and the like. Service server 200 can use or refer to the provided result of identity verification and the result of other screening to perform screening and procedures for the start of the transaction.
[0072] [Processing for correction of information] FIG. 19 is a diagram for explaining the process of correcting information on the input content confirmation screen. When a user operates a button for correcting information on interface screen IM11 (input content confirmation screen), payment application 20 and payment server 100 cause interface screens IM12, IM13, and IM14 (examples of "fourth interface screen") to be displayed on the display unit. Interface screen IM12 includes information indicating that updating of personal identification information is necessary to edit the user information, an update button for performing the update, and the like. Updating personal identification information means, for example, updating information associated with the user's identification information managed in payment server 100. For example, this means that personal identification processing, such as sending a captured image of the driver's license again, is necessary.
[0073] For example, when editing an email address, interface screen IM13 for inputting the email address by a predetermined operation is displayed, and once the email address is edited and the predetermined operation is performed, the screen transitions to interface screen IM14. An authentication email is sent to the input email address, and once the user performs an operation for authentication using the authentication email on interface screen IM14, the email address is updated.
[0074] As described above, when user information acquired by the payment system or user information acquired by the service system is modified, the payment system executes an interface screen and process for modifying the information, and updates the user's user information 172 (updates the first information). In this way, the payment system updates the user's user information 172 and registers the updated information in user information 172, so that when providing information to another service, it can provide information that reflects the modification. This process is an example of a process in which "after the first information is updated, when a start button for starting a second service included in the first interface screen is operated, the control unit provides the modified first information to a second service server corresponding to second mini app 30 that runs in the electronic payment app and provides the second service."
[0075] When an operation to modify information (second information) required for the mini app 30 and the service server 200 to use the service, which information was acquired on the interface screen IM10, is performed on the interface screen IM11, the payment server 100 and the payment application 20 do not provide an interface screen for the modification, but instead display an interface screen (an example of a "fifth interface screen") on the display unit for changing the required information in accordance with the operation for modification performed by the mini app 30 and the service server 200.
[0076] [Sequence diagram for modifying information] 20 is a sequence diagram showing an example of the flow of processing executed by the service system and the payment system. First, when a user performs an operation to correct information on interface screen IM11, the service system transmits information indicating that the operation to correct has been performed to the payment system (S100). Next, the payment system executes processing for the correction (S102). For example, an interface screen for inputting the information to be corrected may be provided, and the information input or provided by the user may be examined or authenticated.
[0077] Next, the payment server 100 updates the registered information in the user's user information 172 to information corresponding to the correction (S104). As a result, the information updated according to the correction is registered in the user's user information 172. Next, the payment system provides the corrected information to the service system (S106). Next, the service system displays an interface screen including information reflecting the correction on the display unit (S108). For example, if the address is changed, an interface screen in which the address before the change is corrected to the address after the change is displayed on the interface screen IM11.
[0078] As described above, when the user information is modified by an operation on the interface screen provided by the service system, the payment system performs processing according to the operation to accept the modification and updates the user information 172 according to the modification. This allows the payment server 100 to acquire and store the latest information and provide the latest information to other services.
[0079] [Conditions for applying for services provided by the service system using the mini app] 21 is a diagram illustrating the conditions for applying for a service provided by the service system using the mini app 30. For example, some or all of conditions 1 to 8 are conditions for applying using information managed in the payment service described above.
[0080] For example, when the user is logged in to use payment app 20 (condition 2), an interface screen is displayed on the display unit, an application button included on the interface screen for applying to use other services is operated, and if the user's usage of the electronic payment service meets the conditions set in the electronic payment service (e.g., condition 7) and the user's identity verification has been completed in the electronic payment service (e.g., conditions 1 and 5), completion information indicating that identity verification has been completed is provided to service server 200, which operates in payment app 20 and provides other services to the user in cooperation with mini app 30, and instructs service server 200 to proceed with processing related to the application, and if button B1 is operated and the set conditions are not met or the user's identity verification has not been completed, service server 200 is instructed to at least temporarily suspend the application.
[0081] When processing the application, payment server 100 executes the processes described above with reference to Figures 13 to 15. For example, payment server 100 causes payment application 20 to display an interface screen for inputting information (first information input) and causes mini application 30 to display an interface screen for inputting information (second information input) according to the information it holds.
[0082] Furthermore, when an application button for applying for use of the first service or an operation button for starting use of the first service included in an interface screen displayed on the display unit is operated while the user is logged in to use payment application 20, payment server 100 causes the display unit to display an interface screen for executing authentication using a biometric authentication function installed in user terminal device 10 of the user, and when biometric authentication (condition 6) is established in response to the user's operation on the interface screen, causes the display unit to display an interface screen in response to the operation. In other words, when biometric authentication is established, use of a predetermined service provided by service server 200 is permitted.
[0083] (Condition 1) The administrator of the electronic payment service has performed a predetermined confirmation of the user, and the predetermined confirmation has been completed. For example, the confirmation items performed at the start of use of the electronic payment service have been completed. For example, if the predetermined confirmation has been completed, a flag indicating whether or not identity verification has been completed is assigned to the user's identification information in the user information 172, and by sharing this flag, the payment server 100 or the service server 200 can determine whether or not condition 1 is met (see FIG. 10).
[0084] (Condition 2) The user must be logged in to the payment application 20. By logging in to the payment application 20, the user can use the mini app 30 and apply for a service using the mini app 30.
[0085] (Condition 3) The user's identification information is shared between the payment service and the service system. This is because the service server 200 can acquire information managed by the payment server 100 by cooperating with the second management unit 130 using the user's identification information as a key (see FIG. 9 mentioned above). It is assumed that consent to providing the user's information to the service server 200 has been obtained from the user.
[0086] (Condition 4) The service is capable of acquiring information on the identity verification date and time and verification method of the target user via the second management unit 130 (for example, an API). For example, the service is capable of acquiring the identity verification date and verification method managed by the payment server 100 as shown in FIG. 10 above. For example, the service is capable of acquiring the above information by cooperating with the second management unit 130.
[0087] (Condition 5) The entity that confirms the transaction must be the administrator of the electronic payment service. Transaction confirmation is a confirmation for the use of electronic payment services. The entity that confirms this must be the administrator of the electronic payment service.
[0088] (Condition 6) The electronic payment service performs predetermined authentication when a specific transaction is made using the mini appli 30. This will be described later (see FIGS. 22 and 23).
[0089] (Condition 7) The user must not have conducted a transaction with a user suspected of impersonating another user or a customer suspected of misrepresenting another user in the electronic payment service. For example, the payment server 100 may use predetermined criteria to identify users who meet the above conditions and suspend the identified users. The suspend process means suspending or stopping the identified users' use of the electronic payment service and related services.
[0090] (Condition 8) The user is not a user that satisfies the use prohibition conditions. Whether or not the use prohibition conditions are satisfied is determined, for example, based on information associated with the user's identification information in the user information 172. The use prohibition conditions include various conditions, such as a predetermined user.
[0091] [Explanation regarding (Condition 6)] When a button for starting the first service included in a first interface screen displayed on the display unit while the user is logged in to use payment app 20 or an operation button for starting use of the first service is operated after processing for receiving the service in response to operation of the button for starting the service has been completed (e.g., after application has been completed), payment server 100 causes the display unit to display an interface screen for executing authentication using a biometric authentication function installed in user terminal device 10 of the user, and when biometric authentication is established in response to the user's operation on the interface screen, causes the display unit to display an interface screen for proceeding with processing in response to the operation. The interface screen in response to the operation is, for example, an interface screen for proceeding with the application or an interface screen for starting the service.
[0092] FIG. 22 is a flowchart showing an example of the flow of authentication processing. First, the payment application 20 determines whether an operation for performing a specific transaction has been performed on the mini application 30 (S200). If an operation has been performed, the payment application 20 displays an interface screen requesting predetermined authentication on the display unit (S202). The predetermined authentication is, for example, authentication realized by a function (e.g., an OS (operating system) or an application program) installed in the user terminal device 10. For example, it is authentication for unlocking the user terminal device 10. The authentication may be, for example, biometric authentication or authentication using a password. The biometric authentication is, for example, authentication using face authentication, fingerprint, iris, etc. The biometric information used for authentication is information registered by the user using the functions of the user terminal device 10.
[0093] Next, the user terminal device 10 determines whether or not authentication has been successful (S204). If authentication is successful, the mini appli 30 and service server 200 provide a service (S206). For example, the process to start a transaction with the user may continue, or the transaction may be started. If authentication is not successful, the mini appli 30 and service server 200 do not provide a service, and this routine of the process ends.
[0094] 23 is a diagram showing an example of the transition of interface screens when authentication is performed. For example, when an operation to start a transaction is performed on an interface screen for starting a transaction provided by mini app 30, payment application 20 causes the display unit to display an interface screen including information indicating that authentication will be performed. If the user agrees to this, user terminal device 10 performs authentication. If authentication is successful, mini app 30 causes the display unit to display an interface screen for starting the transaction.
[0095] For example, assuming that the above authentication is not used, the user needs to provide images of the driver's license taken from multiple angles, images of the back of the driver's license, images of the user's appearance, etc. to the payment server 100 or the service server 200. In contrast, in this embodiment, authentication is performed as described above, and therefore the above processing is omitted, improving user convenience.
[0096] In the above process, authentication is performed when applying for use of the service, but in addition (or instead), authentication may be performed each time use of the service is started after application is completed (however, authentication may be omitted for a certain period after authentication), which improves security.
[0097] According to the first embodiment described above, the payment server 100 executes appropriate processing depending on the information stored therein or the result of identity verification. This allows the user to easily use the service, and the service server 200 can provide the service to the user by utilizing the information managed by the payment server 100 or the result of identity verification. As a result, user convenience is improved and the processing load on the service server 200 is reduced.
[0098] Second Embodiment The second embodiment will be described below. In the second embodiment, information indicating the risk associated with a transaction with a user is associated with the user identification information in the user information, and this information is provided to the service server 200. The following description will focus on the differences from the first embodiment.
[0099] Fig. 24 is a diagram expressing part of the functional configuration of the payment server 100A of the second embodiment. The payment server 100A, for example, includes a first acquisition unit 132, a second acquisition unit 134, and a flag generation unit (derivation unit) 136 in addition to the functional configuration of the payment server 100 of the first embodiment. Some of these functional configurations may be included in other devices. The payment server 100A is an example of an "information processing device".
[0100] The first acquisition unit 132 acquires user information, including either or both of the user's usage pattern of the electronic payment service and information about the user provided by the user in order to use the electronic payment service. The usage pattern is, for example, the user's history of using the electronic payment service, such as the payment amount and information about the store where the payment was made. The information about the user is information provided to the electronic payment service when the user applies to use the electronic payment service. For example, this is information IF1 in FIG. 10 mentioned above.
[0101] The second acquisition unit 134 acquires communication information, which is one or both of information about the device the user is using to use the electronic payment service and information about the network the user is using. The device information includes information about the device type of the user terminal device 10 and information about the IP address (Internet Protocol Address). The network information includes information about the Internet service provider accessed by the user terminal device 10 and information about the network used for communication. For example, this information is acquired by the payment application 20 and provided to the payment server 100.
[0102] The flag generation unit 136 derives the trustworthiness of the user based on the user information and the communication information. For example, the flag generation unit 136 generates a risk flag according to the trustworthiness and derives a score according to the trustworthiness. This information is provided to the service server 200. For example, the second management unit 130 provides the service server 200 with information indicating the trustworthiness, user information held by the payment server 100, and information indicating the result of identity verification in response to a request from the service server 200. For example, when a user operates an application button for applying for use of another service included in an interface screen displayed on the display unit while logged in to use the payment app 20, the second management unit 130 may provide the service server 200 with information indicating the trustworthiness, user information, and information indicating the result of identity verification in response to a request from the service server 200.
[0103] The flag generation unit 136 sets the flag based on, for example, user information, communication information, and also conditions associated with the user (conditions based on user information) and conditions not associated with the user (conditions based on communication information). Fig. 25 is a diagram for explaining the conditions under which a flag is set. Conditions associated with the user include, for example, that the user satisfies a predetermined condition, that a condition in the user's usage mode of the electronic payment service is satisfied, or that there is a defect in the information managed in the payment server 100.
[0104] A user meeting a predetermined condition means that the user is a user who has been registered in advance on a list. For example, high-risk users are registered on this list. A user meeting a condition in their usage of the electronic payment service means, for example, that the electronic payment service is being used in a predetermined manner, such as making a predetermined number of large payments. A user having incomplete information means, for example, that the information is inconsistent (for example, a mismatch between the prefecture and city / ward / town / village of the address) or that the necessary information is incomplete (for example, necessary information is missing).
[0105] Conditions that are not linked to a user include, for example, access from a pre-set device, access from a pre-set IP address, and access via a pre-set Internet service provider. For example, if a device, IP address, or Internet service provider that is deemed to be high risk is used, it is deemed to be high risk.
[0106] The flag generation unit 136 sets a flag when the user satisfies the above-described conditions for setting a flag. The generated flag is provided to the service server 200. For example, when the second management unit 130 provides user information to the service server 200, the second management unit 130 provides the flag to the service server 200 in association with the user information. This enables the service server 200 to recognize that the target user is a high-risk user and to determine whether or not to provide the service in consideration of the recognition result.
[0107] In the above example, a flag is assigned to a high-risk user, but instead, a flag may be assigned according to the level of risk. For example, a flag may be assigned according to the level of risk, such as a high-risk flag, a medium-risk flag, or a low-risk flag. Furthermore, instead of a flag, a score indicating the high or low level of risk may be assigned. The flag generation unit 136 derives a score by referring to a criterion based on the above-mentioned conditions, and associates the derived score with the user's identification information.
[0108] 26 is a diagram showing an example of the contents of the user information 172A according to the second embodiment. In the user information 172A, in addition to the information described in the user information 172, a risk flag is associated with the user's identification information.
[0109] Furthermore, for example, the flag generation unit 136 may assign a flag to the user's identification information according to the risk from among predetermined types of flags including a gray flag, a black flag, and a white flag. A black flag is a flag set for a user who falls under a condition not linked to the user. A black flag may also be set for a user who satisfies a predetermined condition among conditions linked to the user. A black flag is a flag indicating that the reliability is less than a second threshold.
[0110] A gray flag is a flag set for a user whose user information satisfies predetermined conditions among the conditions associated with the user (for example, a user who satisfies conditions related to electronic payment or whose information is incomplete) and does not fall under any conditions not associated with the user. A gray flag is a flag indicating that the reliability is less than a first threshold and greater than or equal to a second threshold.
[0111] A white flag is assigned to a user who does not meet the conditions associated with the user and the conditions not associated with the user.
[0112] For example, when a white flag user performs an operation to apply for use of the mini app 30 service, the payment server 100 allows the user to use the service without having to go through the same procedures as a gray flag user, which will be described later.
[0113] For example, when a user with a gray flag performs an operation to apply for use of the mini app 30 service, the payment server 100 requests the user to perform identity verification again, which is performed by the electronic payment service. For example, the payment server 100 causes the display unit to display an interface screen for performing identity verification again. Note that this interface screen may be displayed by the service server 200 that obtained the gray flag.
[0114] For example, when a user with a black flag performs an operation to apply for use of the service of mini app 30, payment server 100 causes the display unit to display an interface screen including information indicating that the service is unavailable. Note that this interface screen may be displayed by service server 200 that has acquired the black flag.
[0115] According to the second embodiment described above, the payment server 100 generates information regarding the risk of the user and provides the generated information to the service server 200. This allows the service server 200 to refer to the acquired information indicating the risk and determine whether to provide a service to the user. As a result, a more accurate determination regarding the provision of a service is made.
[0116] <Other examples (1)> In the above example, it was explained that when a user operates the mini-app 30 while logged in to the payment app 20, the information held in the payment server 100 is shared with the service server 200. However, instead of (or in addition to) this, the information may be shared when the user's user terminal device 10 accesses the service server 200 without using the mini-app 30.
[0117] FIG. 27 is a diagram illustrating the processing of another example (1). For example, the user terminal device 10 accesses the bank service server 200 without using the mini app 30, and the user attempts to open a bank account. For example, when an operation to open a bank account is performed on an interface screen provided by the service server 200, the service server 200 inquires of the user as to whether or not to log in to an electronic payment service and link the electronic payment service with the bank service server 200. When the user selects linkage and performs a predetermined operation to log in and enter the user's identification information and password used in the electronic payment service, the bank service server 200 obtains from the payment server 100 the user information managed by the payment server 100 and the results of identity verification. The bank service server 200 can proceed with the process of opening the bank account using the obtained information and the results of identity verification.
[0118] As described above, the user can make his / her own information stored in the payment server 100 available to other service servers 200 even without going through the mini app 30, thereby improving user convenience and reducing the processing load on the service server 200.
[0119] <Other examples (2)> When the payment server 100 updates the information associated with the user's identification information in the user information 172 in response to a user's operation, the payment server 100 may provide information indicating that the update has been made or the contents of the update to the predetermined service server 200. For example, when a user updates their address on an interface screen provided by the payment server 100 while applying for a bank account, information indicating that the address has been updated may be provided to, for example, the service server 200 of a credit card company (predetermined service server 200). For example, since it is necessary to obtain the latest information in credit card approval, payment, etc., when information is updated in applying for another service, the payment server 100 provides the service server 200 of the credit card company with information indicating that the update has been made and the contents of the update.
[0120] As described above, when the user information is updated, the payment server 100 provides information about the update to the other service servers 200, thereby enabling the service servers 200 and the payment server 100 to maintain the latest information. Furthermore, the user does not need to update information for all services, which improves user convenience.
[0121] <Other examples (3)> When a user updates the user information on an interface screen provided by the service server 200 and the service server 200 updates the user information, the service server 200 may provide the payment server 100 with information indicating that the user information has been updated and the details of the update. The payment server 100 may update the user information in the user information 172 based on this information. Furthermore, the payment server 100 may provide other service servers 200 with the information indicating that the information has been updated and the details of the update.
[0122] As described above, when the user information is updated in the service server 200, the payment server 100 can obtain information about the update from the service server 200, thereby holding the latest information.
[0123] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention. [Explanation of symbols]
[0124] 10 User terminal device 20. Payment App 30 Mini Apps 50 First store terminal device 60 Store Code Image 70 Second store terminal device 100 Payment Server 121 Service information acquisition unit 122 Contents Provider 124 Payment processing unit 126 Information Processing Department 128 1st Management Department 130 2nd Management Department 132 First acquisition part 134 Second Acquisition Department 136 Flag Generation Unit 170 Storage section 172 User information 174 Payment Content Information
Claims
1. A first acquisition unit that acquires user information, which is information about a user who makes an electronic payment using an electronic payment service, and is information about the amount of the electronic payment made by the user at a store; a second acquisition unit that acquires communication information, which is one or both of information about a device that the user uses to use the electronic payment service and information about a network that the user uses; a flag generation unit that generates a risk flag indicating a risk associated with a transaction with the user, the risk flag being used by a service server that provides a service different from the electronic payment service to determine whether or not to provide the service to the user, based on the user information and the communication information; a providing unit that provides the risk flag to the service server, When an application button for applying for use of another service included in the first interface screen displayed on the display unit is operated, the providing unit provides the risk flag to the service server in response to a request from the service server. Information processing device.
2. the first acquisition unit acquires provided information provided by the user when applying to use an electronic payment service; When a user operates an application button for applying for use of another service included in a first interface screen displayed on the display unit while the user is logged in to use the electronic payment app, the providing unit provides the service server with the provided information and information indicating a result of identity verification based on the provided information and an identity verification document in response to a request from the service server. The information processing device according to claim 1 .
3. A first acquisition unit that acquires user information, which is information about a user who makes an electronic payment using an electronic payment service, and is information about the amount of the electronic payment made by the user at a store; a second acquisition unit that acquires communication information, which is one or both of information indicating the type of device used by the user to use the electronic payment service and information regarding the Internet service provider used by the user; a flag generation unit that generates a risk flag indicating a risk associated with a transaction with the user, the risk flag being used by a service server that provides a service different from the electronic payment service to determine whether or not to provide the service to the user, based on the user information and the communication information; a providing unit that provides the risk flag to a service server that provides a service different from the electronic payment service; An information processing device comprising:
4. If the indicator indicated by the risk flag is less than a first threshold and equal to or greater than a second threshold that is lower than the first threshold, a display control unit that displays information prompting the user to perform identity verification in the electronic payment service on a display unit of the user's terminal device; The information processing device according to claim 1 .
5. the flag generation unit sets the risk flag according to an index that is less than the first threshold and greater than or equal to the second threshold when the user information satisfies a predetermined first criterion and the communication information does not satisfy a predetermined second criterion. The information processing device according to claim 4 .
6. the first acquisition unit acquires provided information provided by the user when applying to use the electronic payment service and the user's electronic payment usage history of the electronic payment service; the flag generation unit sets the risk flag to be less than the first threshold and equal to or greater than the second threshold when the user's electronic payment usage history of the electronic payment service meets a preset standard, when there is an inconsistency in the information included in the provided information, or when there is insufficient information in the provided information; The information processing device according to claim 5 .
7. If the indicator indicated by the risk flag is less than a second threshold, a display control unit that displays information indicating that the user cannot use the service provided by the service server on a display unit of the user's terminal device; The information processing device according to claim 1 .
8. the flag generation unit sets the risk flag to be less than the second threshold value when the communication information satisfies a predetermined criterion. The information processing device according to claim 7 .
9. the first acquisition unit acquires information about the user provided by the user in order to use an electronic payment service; the providing unit provides the service server with the risk flag, information about the user stored in a storage device, and a result of identity verification based on the information about the user and an identity verification document, in order to have the service server provide the service provided by the service server to the user. The information processing device according to claim 1 .
10. If the risk flag is equal to or greater than a first threshold, the service server provides a service to the user in response to acquisition of information about the user and a result of the identity verification. The information processing device according to claim 9 .
11. The computer Acquire user information, which is information about a user who makes an electronic payment using an electronic payment service and is information about the amount of the electronic payment made by the user at the store; Acquire communication information, which is one or both of information about a device used by the user to use the electronic payment service and information about a network used by the user; generating a risk flag indicating a risk associated with a transaction with the user, the risk flag being used by a service server that provides a service different from the electronic payment service to determine whether or not to provide the service to the user, based on the user information and the communication information; In the process of providing the risk flag to the service server, When an application button for applying for use of another service included in the first interface screen displayed on the display unit is operated, providing information indicating the risk flag to the service server in response to a request from the service server; Information processing methods.
12. On the computer, acquire user information, which is information about a user who makes an electronic payment using an electronic payment service and is information about the amount of the electronic payment made by the user at the store; acquires communication information, which is one or both of information regarding a device used by the user to use the electronic payment service and information regarding a network used by the user; generating a risk flag indicating a risk associated with a transaction with the user, the risk flag being used by a service server that provides a service different from the electronic payment service to determine whether or not to provide the service to the user, based on the user information and the communication information; In the process of causing the service server to provide the risk flag, When an application button for applying for use of another service included in the first interface screen displayed on the display unit is operated, causing the service server to provide information indicating the risk flag in response to a request from the service server; program.
13. The computer Acquire user information, which is information about a user who makes an electronic payment using an electronic payment service and is information about the amount of the electronic payment made by the user at the store; Acquire communication information, which is one or both of information indicating the type of device used by the user to use the electronic payment service and information regarding the Internet service provider used by the user; generating a risk flag indicating a risk associated with a transaction with the user, the risk flag being used by a service server that provides a service different from the electronic payment service to determine whether or not to provide the service to the user, based on the user information and the communication information; providing the risk flag to a service server that provides a service different from the electronic payment service; Information processing methods.
14. On the computer, acquire user information, which is information about a user who makes an electronic payment using an electronic payment service and is information about the amount of the electronic payment made by the user at the store; acquires communication information, which is one or both of information indicating the type of device used by the user to use the electronic payment service and information regarding the Internet service provider used by the user; generating a risk flag indicating a risk associated with a transaction with the user, the risk flag being used by a service server that provides a service different from the electronic payment service to determine whether or not to provide the service to the user, based on the user information and the communication information; providing the risk flag to a service server that provides a service different from the electronic payment service; program.
Citation Information
Patent Citations
Method and system for electronic commerce and storage medium
JP2002123726A
Credibility computation method, information processing device, and credibility computation program
JP2020021268A
JPP7060747B
Secure execution of enterprise applications on mobile devices
US20140007222A1
Location-based device and authentication system
US20180108003A1