JP7786000B1 - Service providing device, management method, and program - Google Patents

Abstract

The present invention provides a method for appropriately managing the login status when a terminal device is lost.
[Solution] A service providing device that provides network services via an application program running on a terminal device that is a mobile phone, comprising: a loss processing unit that, in response to notification that the terminal device has been lost, puts the application program into a logged-out state, issues a temporary password, and stores the temporary password in a memory unit in association with the telephone number of the terminal device; and a restart processing unit that, when the temporary password is entered, puts the application program into a logged-in state if the entered temporary password matches the temporary password stored in the memory unit.
[Selected Figure] Figure 10

Description

Article 30, paragraph 2 of the Patent Act applies. (1) Implementation date: June 11, 2025. Internal documents when the function related to the claimed invention was put into operation (Service Launch Date: 2025/06/11 is stated on page 9).

The present invention relates to a service providing device, a management method, and a program.

Traditionally, network services provided via application programs running on terminal devices such as smartphones have become widespread. Network services are often provided when a user logs in (by putting the application program into a logged-in state). As a result, managing the login state when the terminal device is lost has become an issue. Patent Document 1 describes a system in which, when a communication terminal such as a smartphone is lost or damaged, a user can request the creation of a new private key for the individual from an independent corporation. The independent corporation then verifies the individual's identity, and if the individual's identity is confirmed, a new private key for the individual can be created from two other private keys.

Japanese Patent Application Laid-Open No. 2023-102725

With conventional technology, when a terminal device is lost, complicated procedures may be required, raising concerns that users may abandon network services. As such, conventional technology may not be able to properly manage login status when a terminal device is lost.

The present invention was made in consideration of these circumstances, and one of its objectives is to provide a service providing device, management method, and program that can optimally manage login status when a terminal device is lost.

One aspect of the present invention is a service providing device that provides network services via an application program running on a terminal device that is a mobile phone. The service providing device includes: a loss processing unit that, in response to notification that the terminal device has been lost, places the application program in a logged-out state, issues a temporary password, and stores the telephone number of the terminal device and the temporary password in a memory unit in association with each other; and a restart processing unit that, when the temporary password is entered, places the application program in a logged-in state if the entered temporary password matches the temporary password stored in the memory unit.

One aspect of the present invention makes it possible to optimally manage login status when a terminal device is lost.

FIG. 1 illustrates basic aspects of brick-and-mortar electronic payment. FIG. 1 is a diagram illustrating an example of a configuration for performing electronic payment (terminal payment) using a payment application. FIG. 10 is a diagram showing an example of the contents of user information 172. FIG. 10 is a diagram showing an example of the contents of affiliated store/store information 174. FIG. 10 is a diagram showing an outline of a processing flow when a user scan is performed. FIG. 10 is a diagram showing an outline of the processing flow when a store scan is performed. FIG. 1 is a diagram showing an example of a configuration for performing electronic payment (card payment) using a payment card. FIG. 2 is a diagram showing an example of the configuration and surrounding environment for login management in case of loss performed by the payment server 100. FIG. 10 is a diagram showing an example of the contents of temporary password correspondence information 176. FIG. 10 is a sequence diagram showing an example of the flow of a process for login management in case of loss. FIG. 10 is a diagram illustrating an example of a temporary password input screen. FIG. 10 is a sequence diagram illustrating an example of a processing flow for requesting reissue of a temporary password. FIG. 10 is a diagram illustrating another example of the configuration and surrounding environment for login management in case of loss performed by the payment server 100.

[overview]
Hereinafter, with reference to the drawings, embodiments of a service providing device, a management method, and a program according to the present invention will be described. The service providing device is realized by one or more processors. The service providing device provides network services via an application program running on a terminal device (hereinafter referred to as a user terminal device) that is a mobile phone, and manages the login status of users to the network service. In the following description, the network service is assumed to be an electronic payment service. The application program, a payment server, and a credit card server cooperate to provide the electronic payment service. In the following description, the application program is referred to as a payment app, and the service providing device is referred to as a payment server. An electronic payment service is a service that supports payments for the purchase of goods and services at a store. A store is, for example, a physical store (real store) existing in real space, but may also include a virtual store for e-commerce transactions. A virtual store may also include a store operated by an entity other than the operator of the electronic payment service. In such a case, when making a payment for a purchase at the virtual store, the user is controlled to transition to an interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and electronic payments when a purchase is made at the store are primarily made between the user and the affiliated store. Alternatively, electronic payment may be made between the user and the store.

[Physical store-based electronic payment methods]
FIG. 1 illustrates the basic aspects of brick-and-mortar electronic payments. Electronic payments are generally carried out by three parties: a medium M held by a user U, store equipment E, and a payment system S. The medium M may be a portable computer device such as a smartphone or a credit card. The store equipment E resides in a physical store (hereinafter simply referred to as the store) in real space and may include a POS device, a wireless communication device, a credit card reader, a printed code image such as a QR code (registered trademark), or a display device displaying the code image. In brick-and-mortar electronic payments, information that can identify the user and information about the payment amount are first shared unidirectionally or bidirectionally between the medium M and the store equipment E. At this time, one of the medium M or the store equipment E optically reads various information from a code image displayed by the other, provides information via near-field communication (NFC), or reads a primary account number (PAN) using a credit card reader. Then, one of the medium M or the store equipment E (the party that receives information from the other) transmits the payment information required for the payment to the payment system S via a network NW. Note that both the medium M and the store equipment E may transmit some information to the payment system S. The payment system S manages various information about the user U and performs electronic payments between the store and the user U in various ways. Electronic payments may be performed using either or both of a prepaid system and a postpaid system, or by other methods. In addition, electronic payments may also include so-called online shopping, which is performed between the user's terminal device and the payment system. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, etc. The various devices described below that communicate via the network NW are assumed to have communication devices such as network cards and wireless communication modules.

[Configuration (terminal payment)]
2 is a diagram showing an example of the configuration for performing electronic payment (terminal payment) using a payment app. This electronic payment is performed mainly by a payment app 20 running on a user terminal device 10, which is one of the media M, one or more store payment terminals 30 and one or more store code images 40, which are one of the store facilities E, and a payment server 100, which constitutes part of a payment system S. The payment server 100 communicates with the user terminal device 10, the store payment terminal 30, and one or more information terminals 50 via a network NW.

The user terminal device 10 is a portable terminal device such as a smartphone or tablet. The user terminal device 10 is a computer device having at least optical reading, communication, display, input acceptance, and program execution functions. In the following description, the components that realize these functions are referred to as the camera, communication device, touch panel, CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as the CPU executes the payment app 20, which operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment app 20 is installed on the user terminal device 10 from, for example, an application distribution server (not shown) and controls the camera, communication device, touch panel, etc. of the user terminal device 10. In the following description, the terms "send information to the user terminal device 10 (or receive/acquire information from the user terminal device 10)" and "send information to the payment app 20 (or receive/acquire information from the payment app 20)" may be used interchangeably, but these are merely differences in expression and are not intended to distinguish between them.

The store payment terminal 30 is installed, for example, in a store. The store payment terminal 30 is a computer device (or a collection of such devices) that has at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The store payment terminal 30 includes a so-called POS (Point of Sale) device, and the POS device may have a product price acquisition function and an optical reading function.

The store code image 40 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 40 may also be displayed on a display placed in the store (or on the display of a terminal device such as a smartphone or tablet).

The information terminal 50 is used by the operator of the affiliated store who oversees the stores. In electronic payment services, customers who provide goods or services are treated as affiliated stores (brands), and one or more stores exist under the affiliated store. An affiliated store may operate only one store. The information terminal 50 is a smartphone, tablet terminal, personal computer, etc. The information terminal 50 runs an affiliated store interface 55. The affiliated store interface 55 may be an affiliated store app or a web page displayed by a general-purpose browser. The affiliated store interface 55 accepts coupon settings, etc., from the affiliated store operator and transmits them to the payment server 100. By executing the affiliated store interface 55, the information terminal 50 may have the function of displaying a code image equivalent to the store code image 40 or reading a code image displayed by the user terminal device 10 (in the latter case, an optical reading function is required).

The payment server 100 communicates with the credit card server 200 via a network NW. The payment server 100 includes, for example, a content provider 110, an information management unit 120, a payment processing unit 130, and a storage unit 170. The components other than the storage unit 170 are realized by a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented using a large scale integration (LSI), an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA).
The program may be realized by hardware (including circuitry) such as a Gate Array or a Graphics Processing Unit (GPU), 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 with a non-transitory storage medium) such as a hard disk drive (HDD) or 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.

The storage unit 170 is a hard disk drive (HDD), flash memory, RAM (Random Access Memory), etc. The storage unit 170 may also 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 and affiliated store/shop information 174.

The content providing unit 110 has, for example, the functionality of a web server, and provides the user terminal device 10 with information (content) for displaying various screens for electronic payment services. The content providing unit 110 provides the user terminal device 10 with content in the form of a web page, and provides the user terminal device 10 with parameters necessary for the payment app 20 to render images.

The information management unit 120 edits, adds, deletes, etc. user information 172 and affiliated store/store information 174, and manages them.

Figure 3 is a diagram showing an example of the contents of user information 172. User information 172 is a collection of information such as a user URL, account ID, phone number, password, registration date, charge balance, electronic money type, terminal payment method, card payment method, various history information, identity verification flag, name, address, date of birth, email address, bank account, deferred payment settings, deferred payment condition information, and a login status flag indicating login status, all of which are associated with one another. Hereinafter, a user instance (electronic payment account) to which this information is associated may be referred to as an account. In the figure, items marked with "-" indicate that they are not set. The login status flag is set to, for example, "logged in," "logged out," or "login restricted."

The user URL is used for transferring money between users. When registering for the 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. The registration date is the date the user registered for the electronic payment service (the date the account was created). The charge balance is information indicating the balance of electronic money set by the user by transferring money to the account in advance. Transfer methods include depositing money into an ATM (Automatic Teller Machine) of a designated service provider (bank) or transferring money from a registered bank account. The type of electronic money is information indicating, for example, whether the electronic money can be withdrawn or can only be used for electronic payments. The terminal payment method is setting information indicating whether the user will make electronic payment using the charge balance (balance payment) or by deferred payment in terminal payment. The card payment method is setting information indicating whether the user will make electronic payment using the charge balance (balance payment) or by deferred payment in card payment. The various historical information includes a charge history, which is a record of when the user has previously transferred funds to the electronic payment service to increase their charge balance, and a payment history, which shows the breakdown of payments made by the user for each payment (date and time, store ID of the store where the purchase was made, affiliated store ID, payment amount, payment method, etc.).

The identity verification flag indicates whether the user has completed identity verification using identification. Deferred payment can be selected once identity verification has been completed. The user with account ID "002" in the figure has not completed identity verification, and can only select balance payment as the terminal payment method. The bank account is the account number of a bank account that can be used to deposit funds into the electronic payment service. Deferred payment settings indicate whether the settings have been completed to make deferred payment available. Deferred payment conditions information indicates various conditions, such as the deferred payment limit and the amount used for the current month.

Figure 4 is a diagram showing an example of the contents of affiliated store/store information 174. Affiliated store/store information 174 includes, for example, a first table 174A in which affiliated store IDs and store IDs are associated with store URLs, a second table 174B in which affiliated store IDs are associated with affiliated store names and sales amounts (described above), and a third table 174C in which store IDs are associated with store IDs. In addition to this information, affiliated store/store information 174 may also include information such as affiliated store or store categories, store locations, and payment patterns.

The payment processing unit 130 performs various processes for electronic payments. There are two methods for terminal payments: Method 1 (user scan) and Method 2 (store scan), which are described below.

Figure 5 shows an overview of the processing flow when a user scan is performed. First, the user terminal device 10, with the payment app 20 running, reads and decodes the store code image 40 using its optical reading function (S1). The store code image 40 contains store URL information. The payment app 20 sends first payment information, including the store URL and the user's account ID, to the payment server 100 (S2). The payment server 100 searches the member store/store information 174 using the member store ID and store ID corresponding to the store URL, obtains information on the member store name and store name (S3), and sends this to the payment app 20 (S4). The user enters the payment amount into the payment app 20 on the screen displaying the member store name and store name (S5). The payment app 20 then generates second payment information including at least the payment amount and sends it to the payment server 100 (S6).

If the "Terminal Payment Method" in the user information 172 for the user is set to "Balance Payment," the payment processing unit 130 of the payment server 100 performs electronic payment based on the received second payment information (S7-1). At this time, the payment processing unit 130 performs electronic payment, for example, by decreasing the charge balance managed in association with the user ID and increasing the affiliated store sales amount item value. The affiliated store sales amount item value is not used as electronic money itself, for example, but rather the amount corresponding to the sales amount item value is transferred to a bank account on a cycle dictated by the agreement between the affiliated store and the electronic payment service. On the other hand, if the "Terminal Payment Method" is set to "Deferred Payment," the payment processing unit 130 sends the first payment information and the second payment information to the credit card server 200 to request electronic payment (S7-2). Based on the received information, the credit card server 200 adds the payment amount to the user's monthly usage amount and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date (S7-3).

Then, the payment processing unit 130 sends a payment completion notification (information for displaying a payment completion screen) to the payment app 20 via the content providing unit 110 (S8), and the payment app 20 displays the payment completion screen (S9). Note that when the store code image 40 is displayed on a display installed in the store, the store code image 40 may include information on the payment amount in addition to the store URL. In this case, the step in which the user inputs the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.

Figure 6 shows an overview of the processing flow when a store scan is performed. First, the payment app 20 sends a request to issue a one-time code to the payment server 100 (S11) when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when an automatic update occurs (e.g., every minute), and at other times. The payment processing unit 130 of the payment server 100 generates a 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 store payment terminal 30, and the store payment terminal 30 reads and decodes the code image using its optical reading function to obtain the one-time code, etc. (S15). The store payment terminal 30 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). Payment amount information is obtained in advance by reading a barcode or manually entering it.

The payment processing unit 130 of the payment server 100 identifies the user corresponding to the one-time code based on the received information, and if the "Terminal Payment Method" in the user information 172 of that user is set to "Balance Payment," it performs electronic payment based on the received second payment information (S17-1). The processing content at this time is the same as the processing of S7-1 in Figure 5. On the other hand, if the "Terminal Payment Method" is set to "Deferred Payment," the payment server 100 sends the first payment information and second payment information to the credit card server 200 to request electronic payment (S17-2). The credit card server 200 adds the payment amount to the user's monthly usage amount based on the received information, and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date (S17-3).

Then, the payment processing unit 130 sends a payment completion notification to the payment app 20 via the content providing unit 110 (S18), and the payment app 20 displays a payment completion screen (S19).

Note that electronic payment may be made 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 during store scanning, and the payment app 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.

Note that "post-payment" payments may be performed within the payment server 100 rather than under the management of the credit card server 200. In this case, components such as the payment card 60 and credit card server 200 may be omitted.

[Configuration (card payment)]
7 shows an example of a configuration for electronic payment (card payment) using a payment card. This electronic payment is carried out mainly using a payment card 60, which is one of the media M, a credit card processing terminal 70, which is one of the store facilities E, a payment server 100, and a credit card server 200, which constitute part of a payment system S. The credit card server 200 communicates with the credit card processing terminal 70 via a network NW.

The credit processing terminal 70 is installed in the store, similar to the store payment terminal 30. The credit processing terminal 70 includes, for example, a credit card reader and a POS device. The credit card terminal reads the PIN (Personal Identification Number) from an inserted or held-up credit card and compares it with the PIN entered by the user. It also transmits the PAN (Primary Account Number) read from the credit card to the credit card server 200 via the POS device. The POS device cooperates with the credit card terminal to transmit information such as the payment amount to the credit card server 200. A payment acquisition agent server may be interposed between the credit card processing terminal 70 and the credit card server 200; however, for simplicity, the following description omits the explanation of the payment acquisition agent server. The payment card 60 is, for example, similar to a commonly used credit card, with a communication chip embedded in the card substrate. The communications chip contains a storage medium that stores a PIN and communicates with an external device via a contactor (or wireless antenna). Alternatively, the payment card 60 may be a magnetic card. The information (messages) sent and received when using a credit card include an authorization message for authentication and a sales message for communicating the payment amount, but a detailed explanation of the distinction between these will be omitted below.

The credit card server 200 communicates with the payment server 100 via the network NW. The credit card server 200 includes, for example, an information management unit 210, a credit interface 220, a payment allocation unit 230, a credit payment processing unit 240, and a memory unit 270. The components other than the memory unit 270 are implemented by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented by hardware (including circuitry) such as an LSI, ASIC, FPGA, or GPU, or by a combination of software and hardware. The program may be stored in advance in a storage device such as an HDD or flash memory (a storage device with a non-transitory storage medium), 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. Information such as card user information 272 is stored in the memory unit 270.

The information management unit 210 edits, adds, deletes, etc., and manages card user information 272. Card user information 272 is information that associates, for example, information unique to the user (e.g., PAN), the card payment method, and the user's account ID (used by the payment server 100). The card payment method is setting information that indicates whether the user will make an electronic payment using the remaining balance (balance payment) or a deferred payment when making a card payment.

The credit interface 220 determines whether the BIN (Bank Identification Number) in the PAN included in the message received from the credit processing terminal 70 is a code for the company, and if it is a code for the company, passes the message received from the credit processing terminal 70 to the payment allocation unit 230, and if it is not a code for the company, discards the received message.

The payment allocation unit 230 references the card user information 272 of the user corresponding to the message obtained from the credit interface 220 and determines whether the "card payment method" is set to "postpaid." If the "card payment method" is set to "postpaid," the payment allocation unit 230 notifies the credit interface 220 of this and passes the message obtained from the credit interface 220 to the credit payment processing unit 240. On the other hand, if the "card payment method" is set to "balance payment," the payment allocation unit 230 adds the user's account ID to the message obtained from the credit interface 220 and sends it to the payment server 100, requesting electronic payment. When requested to make electronic payment, the payment server 100 performs processing similar to S7-1 in Figure 5 and S17-1 in Figure 6.

The credit interface 220 checks the PAN and expiration date, and verifies whether the cumulative payment amount exceeds the current month's limit. The credit payment processing unit 240 adds the payment amount to the user's monthly usage amount based on the information contained in the message obtained from the payment allocation unit 230, and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date.

[Login Management in Case of Lost]
8 is a diagram showing an example of the configuration and surrounding environment for login management in the event of loss performed by the payment server 100. For example, the payment server 100 communicates with an automated response system 300. The automated response system 300 is a system that automatically responds to telephone inquiries by voice and is also called an IVR (Interactive Voice Response) system. The automated response system 300 may acquire a number entered by a user as a response into the telephone 80, or may have a voice recognition function and acquire the meaning of the user's voice inquiries and responses.

In addition to the configuration shown in FIG. 2, the payment server 100 also includes a loss processing unit 140 and a restart processing unit 150 as a configuration for managing logins in the event of loss. These components are implemented, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented by hardware such as an LSI, ASIC, FPGA, or GPU, or may be implemented by a combination of software and hardware. The configuration including the loss processing unit 140 and the restart processing unit 150 may be a device separate from the payment server 100. In this case, a device having these configurations may be referred to as a management device.

User U shown in Figure 8 is a user who lost and later found their user terminal device 10. Temporary password correspondence information 176, for example, is further stored in the storage unit 170. Figure 9 is a diagram showing an example of the contents of the temporary password correspondence information 176. The temporary password correspondence information 176 associates, for example, the user's telephone number with a temporary password (described below), the date and time (or date) when the user terminal device 10 was lost, and other information. The temporary password is set, for example, as a four-digit number.

Figure 10 is a sequence diagram showing an example of the processing flow for login management in the event of loss. First, a user U who has lost their user terminal device 10 calls a specified phone number using any telephone 80. The automated response system 300 handles calls made to the specified phone number, and the user U notifies the automated response system 300 that they have lost their user terminal device 10 (S20). The automated response system 300 requests the telephone number, date and time of loss, and other information from the telephone 80 (S21). In response, the user U contacts the automated response system 300 with the phone number, date and time of loss, and other information by inputting the information or by voice (through their own actions) (S22).

The automatic response system 300 transmits the telephone number, date and time of loss, and other information to the payment server 100 (S23). The loss event processing unit 140 of the payment server 100 simultaneously logs out all payment apps 20 corresponding to the telephone number (including those logged in via a browser) (S24). At this time, the loss event processing unit 140 changes the login information flag in the user information 172 corresponding to the payment app 20 corresponding to the telephone number to flag information indicating "login restricted" rather than "logged out." The loss event processing unit 140 then issues a temporary password (temp-pw in the figure), associates it with the telephone number, date and time of loss, and other information, and registers and stores it in the temporary password association information 176 (S25). The loss event processing unit 140 transmits the temporary password to the automatic response system 300 (S26), and the automatic response system 300 communicates the temporary password to the telephone 80 by voice or other means, and contacts the user U (S27).

If the user terminal device 10 is subsequently found, user U, who has memorized or saved the temporary password in a memo or other location, performs operations to resume login to the electronic payment service using the user terminal device 10. First, user U opens the non-login screen of the payment app 20 and enters their phone number and password (S30). This password is the same as that described with reference to Figure 3 and is different from the temporary password. The payment app 20 sends the entered phone number and password to the payment server 100 (S31). The resumption processing unit 150 of the payment server 100 compares the phone number and password with the information registered in the user information 172 (S32). Here, it is assumed that the comparison is successful. Alternatively, a login request linked to another service may be made. When a login request linked to another service is made, the information sent in S30-S31 is login information for the other service (e.g., user identification information such as account name or username, and password). In this case, the payment server 100 compares the user by sharing information with the other linked service (S32).

If the match is successful, the restart processing unit 150 references the login status flag in the user information 172, and if the login status flag is set to "login restricted," it sends information requesting a temporary password to the payment app 20 (S33). The payment app 20 displays a screen for entering a temporary password and accepts the entry of the temporary password (S34). The payment app 20 sends the entered temporary password to the payment server 100 (S35). When the temporary password is acquired and entered from the payment app 20, the restart processing unit 150 compares the entered temporary password with the temporary password stored in the memory unit 170 (registered in the temporary password correspondence information 176). (S36) If they match, the restart processing unit 150 changes the login status flag to "logged in" and sends a login permission notification to the payment app 20, putting the payment app 20 into a logged-in state (S37). When verifying the temporary password, the corresponding temporary password is obtained from the temporary password correspondence information 176 using the telephone number associated with the payment application 20, which is the destination of the processes in S30 to S35. This telephone number is recognized through communication with the payment application 20 and is known to the payment server 100.

If the entered temporary password does not match the temporary password registered in the temporary password correspondence information 176, up to n errors are allowed, but if more than n errors occur, the temporary password will be invalidated. Figure 11 is a diagram showing an example of a temporary password input screen. When the user enters the temporary password in area A1 and operates button B1, the temporary password is sent to the payment server 100. When link L1 is operated, for example, a phone number for requesting a temporary password reissue is displayed. The left image of Figure 11 is the input screen when k errors or less (n > k), and the right image of Figure 11 is the input screen when more than k errors but less than n errors. For example, n is set to a value of approximately 10 and k is set to a value of approximately 5. As shown in the figure, if more than k errors occur, the number of remaining errors before the temporary password is invalidated is displayed.

If user U has memorized the temporary password or saved it in a memo or similar, the process for re-login is completed with the processing in the flowchart of Figure 10. On the other hand, if user U has not memorized the temporary password or saved it in a memo or similar (if they have forgotten it), or if they have entered the wrong temporary password more than n times, they must call a specified phone number (which may be the same phone number as when the password was lost, or a different phone number) and request (ask) that the automatic answering system 300 reissue the temporary password.

Figure 12 is a sequence diagram showing an example of the processing flow for requesting the reissue of a temporary password. The processes of S20 to S27 will not be illustrated or described again. First, user U notifies the automatic response system 300 that he or she requests the reissue of a temporary password (S40). This notification is an example of a "user action." Here, it is assumed that the lost user terminal device 10 has been found, and that user U is to call a specified telephone number using the found user terminal device 10.

The automatic response system 300 transmits to the payment server 100 a notification that a temporary password reissue request has been made (S41). The restart processing unit 150 of the payment server 100 executes processing to confirm whether the user terminal device 10 that made the temporary password reissue request is the same as the lost user terminal device 10 (S42). For example, the restart processing unit 150 performs SMS authentication. That is, the restart processing unit 150 sends a short message to the phone number registered in the user information 172, and when the PIN number included in the short message is entered into the payment app 20 or the URL included in the short message is operated, it determines that the user terminal device 10 that made the temporary password reissue request is the same as the lost user terminal device 10. The "processing to confirm whether they are the same" is not limited to this, and any processing may be performed.

If it is determined that the user terminal device 10 that requested the reissue of the temporary password is the same as the lost user terminal device 10, the restart processing unit 150 requests the automatic response system 300 to verify the user's identity and accepts input of identity verification information from the automatic response system 300 (S43). The automatic response system 300 requests the user U to input identity verification information (S44). The identity verification information required is more detailed information than that required when notifying the user of the loss, such as telephone number, name, date of birth, postal code, address, email address, and secret password. In response, the user U contacts the automatic response system 300 with the identity verification information by inputting the information or by voice (S45).

The automated response system 300 transmits the personal identification information to the payment server 100 (S46). The restart processing unit 150 of the payment server 100 compares the acquired (input) personal identification information with the user's previously acquired personal information, i.e., the information registered as user information 172 (S47). If they match, the restart processing unit 150 reissues the temporary password and associates the reissued temporary password with the phone number, date and time of loss, and other information, and registers and saves it in the temporary password correspondence information 176 (S48). Note that "matching" may mean an exact match, or may include only differences that are considered to be the same, such as differences between the old and new character styles. The restart processing unit 150 transmits the reissued temporary password to the automated response system 300 (S49), and the automated response system 300 communicates the temporary password to the user terminal device 10 by voice or other means, and contacts user U (S50).

The processing entity for S40 to S48 may be the loss processing unit 140. Furthermore, if it is not specified that the discovered user terminal device 10 should be used to make a call to a specific telephone number, the terminal confirmation process of S42 may include processing to request that some information for identifying the user terminal device 10 be sent to the payment server 100 (for example, by performing some operation on the payment app 20 in a logged-out state).

For login management in the event of loss, a call center staffed by an operator may be used instead of the automatic response system 300. Figure 13 shows another example of the configuration and surrounding environment for login management in the event of loss performed by the payment server 100. The call center 400 is equipped with a telephone 410 and a CS terminal 420. The operator OP answers calls made to the telephone 410 corresponding to a specified telephone number and asks questions similar to those asked by the automatic response system 300. The operator OP then inputs the user U's answers, requests, and requests into the CS terminal 420. The CS terminal 420 transmits the input content to the payment server 100.

In the configuration shown in Figure 8 or Figure 13, the loss processing unit 140 and resumption processing unit 150 of the payment server 100 each acquire the voice uttered by the user U from the automatic response system 300 or call center 400, and the resumption processing unit 150 may allow login of an account that is currently under login restriction, on the further condition that the voice acquired by the loss processing unit 140 and the voice acquired by the resumption processing unit 150 are determined to be the voice of the same person through voiceprint analysis or the like.

The above-described embodiment allows for optimal management of login status in the event that a terminal device is lost.

The above describes the form for carrying out the present invention using an embodiment, but the present invention is in no way limited to such an embodiment, and various modifications and substitutions can be made without departing from the spirit of the present invention.

E Store equipment M Medium S Payment system 10 User terminal device 20 Payment application 30 Store payment terminal 40 Store code image 60 Payment card 70 Credit card processing terminal 80 Telephone 100 Payment server 130 Payment processing unit 140 Loss processing unit 150 Restart processing unit 170 Storage unit 172 User information 176 Temporary password correspondence information 200 Credit card server 300 Automatic response system 400 Call center

Claims (10)

A service providing device that provides a network service via an application program that runs on a terminal device that is a mobile phone,
a loss processing unit that, in response to a notification that the terminal device has been lost, puts the application program into a logout state, issues a temporary password, and stores the telephone number of the terminal device and the temporary password in a storage unit in association with each other;
a restart processing unit that, when the temporary password is input, puts the application program into a login state if the input temporary password matches the temporary password stored in the storage unit;
A service providing device comprising: the loss event processing unit acquires a telephone number of the terminal device together with a notification that the terminal device has been lost;
The service providing device according to claim 1. the loss event processing unit acquires a notification that the terminal device has been lost and the telephone number of the terminal device based on an action taken by a user to an automated answering system that responds to telephone calls made to a predetermined telephone number;
The service providing device according to claim 2. the restart processing unit executes a process of confirming that the other party of the telephone call made to the predetermined telephone number is the lost terminal device in response to an action by the user made to an automatic answering system that handles telephone calls made to the predetermined telephone number.
The service providing device according to claim 1. the restart processing unit, when it is confirmed that the terminal device is the lost terminal device, accepts an input for identity verification to the automatic answering system, and when the content of the input for identity verification matches the personal information of the user that has been acquired in advance, requests the input of the temporary password.
The service providing device according to claim 4. the restart processing unit is configured to request that the user's action be a reissue of the temporary password;
6. The service providing device according to claim 4 or 5. the restart processing unit accepts input for identity verification when it is confirmed that the destination of a telephone call made to a predetermined telephone number is the lost terminal device, and requests input of the temporary password when the content of the input for identity verification matches the personal information of the user that has been acquired in advance;
The service providing device according to claim 1. the loss event processing unit receives a notification from a user that the terminal device has been lost,
the restart processing unit acquires the user's voice when acquiring the temporary password, and puts the application program into a login state when it is determined that the voice acquired by the loss processing unit and the voice acquired by the restart processing unit are the same person.
The service providing device according to claim 1. A service providing device that provides a network service via an application program that runs on a terminal device that is a mobile phone,
a process of putting the application program into a logout state, issuing a temporary password, and storing the telephone number of the terminal device and the temporary password in a storage unit in association with each other in response to a notification that the terminal device has been lost;
a process of putting the application program into a login state when the input temporary password matches the temporary password stored in the storage unit;
Management method to carry out. A processor of a service providing device that provides a network service via an application program running on a terminal device that is a mobile phone,
a process of putting the application program into a logout state, issuing a temporary password, and storing the telephone number of the terminal device and the temporary password in a storage unit in association with each other in response to a notification that the terminal device has been lost;
a process of putting the application program into a login state when the input temporary password matches the temporary password stored in the storage unit;
A program to execute.