Operating system

The operating system and authentication system address the inconvenience and fraud risks of conventional phone number authentication by verifying and registering the device-linked number, offering a more efficient and secure authentication process.

JP2026034396APending Publication Date: 2026-02-27PAYPAY CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2025133261
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-08-08
Publication Date
2026-02-27

AI Technical Summary

Technical Problem

Conventional user authentication methods, such as SMS authentication, impose a heavy burden on service providers and require users to authenticate for each service, being inconvenient and prone to fraudulent use due to the inability to verify the authenticity of input phone numbers.

Method used

An operating system and authentication system that authenticates users based on a telephone number linked to the terminal device, including a telephone number authentication program that registers and verifies the authenticity of the linked number, allowing applications to determine successful authentication without constant server verification.

Benefits of technology

Provides a more convenient authentication method for both service providers and users by reducing the need for constant server verification and preventing fraudulent use, enhancing security and efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026034396000001_ABST
    Figure 2026034396000001_ABST
Patent Text Reader

Abstract

To provide an operating system and an authentication system capable of providing an authentication means more convenient for both a service provider and a service user.SOLUTION: An operating system installed in a terminal of a user, the operating system comprising: a phone-number authenticating program that authenticates the user based on a phone number associated with the terminal in response to an authenticating request from an application installed in the terminal, A first process of registering the phone numbers associated with the terminal in the terminal as authenticated phone numbers when a predetermined condition is satisfied, and a second process of receiving an authenticating request based on the phone numbers from the application and notifying the application of successful authenticating by returning the authenticated phone numbers when the authenticated phone numbers are registered.SELECTED DRAWING: Figure 8
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to operating systems and authentication systems. [Background technology]

[0002] Conventionally, from the viewpoint of protecting personal information, some types of terminal devices have specifications that prevent registered telephone numbers from being obtained from an application running on the terminal device. Therefore, many of these types of terminal devices have conventionally adopted a method in which a user inputs a telephone number when an application requires a telephone number. However, in this case, the application cannot determine whether the input telephone number matches the telephone number registered in the terminal device, which raises the possibility of the application being fraudulently used with a telephone number different from the telephone number registered in the terminal device. To prevent such fraudulent use, conventionally, the telephone number input into the application is notified to a server, and the server authenticates the user using the notified telephone number, thereby enhancing the security of the service (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6259536 Summary of the Invention [Problem to be solved by the invention]

[0004] In conventional technology, one method of authenticating a user by phone number is SMS (Short Message Service) authentication. SMS authentication involves sending a one-time code via SMS to a specified phone number, and having the user reply with that one-time code via the Internet. In addition to SMS authentication, there are various other methods for authenticating a user by phone number, such as authenticating by making a call to a specified phone number. However, many of these methods require the service provider to build a system, placing a heavy burden on the service provider. Furthermore, users must be authenticated for each service they use, which can be inconvenient.

[0005] The present invention has been made in consideration of the above circumstances, and one of its objects is to provide an operating system and authentication system that can provide a more convenient authentication means for both service providers and service users. [Means for solving the problem]

[0006] One aspect of the present invention is an operating system that is installed in a user's terminal device and determines the basic operation of the terminal device, and includes a telephone number authentication program that authenticates the user based on a telephone number linked to the terminal device in response to an authentication request from an application program installed in the terminal device, and the telephone number authentication program includes a first process that registers the telephone number linked to the terminal device as an authenticated telephone number in the terminal device when predetermined conditions are met with respect to the telephone number linked to the terminal device, and a second process that accepts an authentication request based on the telephone number from the application program and, if the authenticated telephone number is registered, notifies the application program of successful authentication by returning the authenticated telephone number.

[0007] One aspect of the present invention is an authentication system comprising a user's terminal device and a management server capable of communicating with the terminal device, wherein the terminal device has a telephone number authentication unit that authenticates the user based on a telephone number linked to the terminal device in response to an authentication request from an application program installed on an operating system that defines the basic operation of the terminal device, and the telephone number authentication unit executes a first process of registering the telephone number linked to the terminal device as an authenticated telephone number in the terminal device when specified conditions are met with respect to the telephone number linked to the terminal device, and a second process of accepting an authentication request based on the telephone number from the application program and, if the authenticated telephone number is registered, notifying the application program of successful authentication by returning the authenticated telephone number, and the management server determines the specified conditions in the first process in cooperation with the application program. [Effects of the Invention]

[0008] According to one aspect of the present invention, it is possible to provide an operating system and an authentication system that can provide authentication means that is more convenient for both service providers and service users. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] 1 is a configuration diagram of a payment server 100 according to an embodiment. [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]1 is a configuration diagram of a user terminal device 200 according to an embodiment. [Figure 8] FIG. 10 is a diagram illustrating an example of a processing flow in which the user terminal device 200 of the embodiment authenticates a user by phone number authentication. [Figure 9] FIG. 10 is a diagram illustrating an example of the flow of an authenticated phone number registration process. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, with reference to the drawings, embodiments of the operating system and authentication system of the present invention will be described. Various devices, such as a "server," a "management device," and an "information providing device," that provide services to users and perform internal analysis, may be implemented as a group of distributed devices, and each device may be operated by a different business. Furthermore, the hardware owner (the cloud server provider) and the business that actually operates the device may also be different. An application program and a payment server work together to provide an electronic payment service. In the following description, the application program is referred to as a "payment app." 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-world store) existing in real space, but may also include a virtual store for e-commerce transactions. Virtual stores may also include stores operated by entities other than the operator of the electronic payment service. In such cases, the user may be controlled to transition to an interface screen for the electronic payment service when making a payment for a purchase at the virtual store. In an electronic payment service, a store is treated as belonging to, for example, a member store (brand), and when a purchase is made at a store, processing such as payment is primarily conducted between the user and the member store. Alternatively, processing such as payment may be conducted between the user and the store.

[0011] [Electronic payment service] FIG. 1 shows an example of a configuration for realizing an electronic payment service. The electronic payment service is realized mainly by a payment server 100. The payment server 100 communicates with, for example, one or more user terminal devices 200, one or more first store terminal devices 50, and one or more second store terminal devices 70 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. Note that the management server 300 is not directly involved in providing the electronic payment service, but can communicate with other devices via the network NW. The management server 300 cooperates with the user terminal device 200 to realize the "phone number authentication" described below.

[0012] User terminal device 200 is, for example, a portable terminal device such as a smartphone or tablet terminal. User terminal device 200 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, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In user terminal device 200, a processor such as a CPU executes payment app 220, which operates in cooperation with payment server 100 to provide electronic payment services to users. Payment app 220 is installed on user terminal device 200 from, for example, an application store, and controls the camera, communication device, touch panel, etc.

[0013] 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).

[0014] 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 200 by executing the app for affiliated stores.

[0015] The payment server 100 realizes electronic payment based on payment information received from the user terminal device 200 or the first store terminal device 50. The first store terminal device 50 may include a POS device and an affiliated store server, in which case payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, this distinction will not be made and it is assumed that payment information is sent from the first store terminal device 50.

[0016] 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.

[0017] In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 200, with the payment application 220 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 220 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 220 (S4). The user enters the payment amount into the user terminal device 200 on the screen displaying the affiliated store name and store name (S5). Then, the user terminal device 200 generates second payment information including at least the payment amount and sends it to the payment server 100 (S6). The payment server 100 makes the electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notice (information for displaying a payment completion screen) to the payment application 220 (S8), and the payment application 220 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 may include information on the payment amount in addition to the store URL. In this case, the step of the user inputting 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.

[0018] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, the payment app 220 sends a request to issue a one-time code to the payment server 100 when the payment app 220 is launched, when a payment operation is performed using the payment app 220, at the automatic update timing (e.g., every minute), and at other timings (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment app 220 (S13). The payment app 220 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 200 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 obtains the one-time code, etc. (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 or manually entering it. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs electronic payment (S17). The payment server 100 then sends a payment completion notice to the payment application 220 (S18), and the payment application 220 displays a payment completion screen (S19).

[0019] Note that electronic payment may be performed using only one of the above patterns. The "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Issuance of a one-time code may be omitted in store scanning, and the payment application 220 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 the one-time code.

[0020] [Payment server] FIG. 4 is a configuration diagram of a payment server 100 according to an embodiment. The payment server 100 includes, for example, a communication unit 110, a payment content providing unit 120, a payment processing unit 130, an information management unit 140, and a storage unit 170. The components other than the communication unit 110 and the storage unit 170 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 a large-scale integration (LSI), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a graphics processing unit (GPU), or may be implemented 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.

[0021] The storage unit 170 is a hard disk drive (HDD), a flash memory, a random access memory (RAM), etc. The storage unit 170 may be a network attached storage (NAS) 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.

[0022] The communication unit 110 is a communication interface for connecting to the network NW, and is, for example, a network interface card.

[0023] The payment content providing unit 120 has, for example, a function of a web server, and provides information (content) for displaying various screens for electronic payment services to the user terminal device 200. The payment content providing unit 120 reads out necessary content from the payment content information 174 as appropriate and provides it to the user terminal device 200. The user terminal device 200 accepts various inputs from the user while content is being played by the payment application 220, and transmits the above-mentioned payment information and the like to the payment server 100.

[0024] The payment processing unit 130 performs payment processing based on the payment information transmitted by the user terminal device 200 or the first store terminal device 50. The payment processing unit 130 performs payment processing while referring to the user information 172.

[0025] 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, telephone number, and password, as well as associated information such as email address, user ID, name, address, date of birth, registration date, charge balance, credit card payment settings, credit card limit, credit card payment amount, available credit card payment amount, payment method settings, bank account, credit card number, charge history information, and payment history information. The user URL is used for remittance processing between users. Registration of a telephone number and password is required when registering for an electronic payment service. The account ID is issued to the user by the payment server 100, and the user ID can be set by the user (or does not have to be set). Similarly, the email address, name, address, and date of birth can be set by the user (or do not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Hereinafter, the user's instance (electronic payment account) to which this information is associated will be referred to as an account.

[0026] The charge balance indicates the balance of electronic money set by the user by transferring funds to the account in advance. Transfer methods include transfers from a designated bank's ATM (Automatic Teller Machine) or from a registered bank account. The credit payment setting indicates whether the settings for electronic credit payment have been completed and is set to either "Completed" or "Not Completed." The credit payment limit is the monthly credit payment limit. The credit payment amount is the amount of credit payment already used in the current month. The available credit payment amount is the amount of credit payment available in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the figure shows only one credit payment limit, in reality, there may also be daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be discussed later. The payment method setting indicates whether the user will currently make electronic payments using the charge balance or by credit payment. The bank account and credit card number are information on the bank account or credit card number (account number, card number) that can be used to deposit funds into the electronic payment service. The charge history information is a history of the user's previous transfers to the electronic payment service to increase the charge balance. The payment history information is information that 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, payment amount, payment method, etc.).

[0027] 6 is a diagram showing an example of the contents of affiliated store / store information 176. The affiliated store / store information 176 includes, for example, a first table 176A in which an affiliated store ID and a store ID are associated with a store URL, a second table 176B in which an affiliated store ID is associated with an affiliated store name and sales amount (described above), and a third table 176C in which a store ID is associated with a store name. In addition to this information, the affiliated store / store information 176 may also include information such as the category of the affiliated store or store, the store's location, and payment patterns.

[0028] The information management unit 140 manages the user information 172 and the affiliated store / store information 176 based on information acquired from the user terminal device 200 and the second store terminal device 70. The information management unit 140 adds new records to, edits, deletes, etc. the user information 172 and the affiliated store / store information 176.

[0029] [Electronic Payment] When payment information is acquired from the user terminal device 200 or the first store terminal device 50, the payment processing unit 130 references the user information 172 to acquire the "payment method setting" of the user. For users whose "payment method setting" is set to "charge balance," the payment processing unit 130 performs electronic payment as follows: For example, the payment processing unit 130 performs electronic payment by decreasing the charge balance managed in association with the user ID and increasing the item value of the affiliated store's sales proceeds. The item value of the affiliated store's sales proceeds is not itself used as electronic money, for example, but rather the amount corresponding to the item value of the sales proceeds is transferred to a bank account in a cycle according to an agreement between the affiliated store and the electronic payment service.

[0030] The payment processing unit 130 performs electronic payments for users whose "setting information" is set to "credit card payment" as follows. Credit card payment is a payment method in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service. The operator of the electronic payment service acts as the creditor, allowing electronic payments within the credit card payment limit and independent of the remaining balance. To receive the credit card payment service, a user may be required to obtain a credit card provided by the operator of the electronic payment service. The monthly amount used for credit card payment is settled on the following month's payment date, for example, by debit from a bank account. In this case, the payment processing unit 130 makes a provisional settlement by adding the settlement amount to the credit card payment amount and subtracting the same amount from the available credit card balance. On the closing date, the payment processing unit 130 performs the process described above to debit the current month's payment on the following month's payment date, or requests the credit card company operator to perform this process. If the settlement amount exceeds the available credit card balance at the time of provisional settlement, an error notification is returned to the payment app 220.

[0031] [User terminal device] FIG. 7 is a configuration diagram of a user terminal device 200 according to an embodiment. The user terminal device 200 includes, for example, a communication unit 210, a payment application 220, a phone number authentication unit 230, and a storage unit 240. The components other than the communication unit 210 and the storage unit 240 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 a large-scale integration (LSI), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a graphics processing unit (GPU), or may be implemented 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.

[0032] The storage unit 240 is a hard disk drive (HDD), flash memory, RAM (Random Access Memory), etc. A part of the storage unit 240 may be a NAS (Network Attached Storage) device that can be accessed by the user terminal device 200 via a network. The storage unit 240 stores information such as an operating system 242 and a payment application program 244.

[0033] The operating system 242 is installed in the user terminal device 200 and is basic software required for the operation of the user terminal device 200. The operating system 242 is loaded and executed by the CPU and memory of the user terminal device 200 when the user terminal device 200 is powered on. The operating system 242 defines basic operations for connecting hardware and users when operating a computer, such as file management, memory management, process management such as multitasking, user interface, and networking. In the user terminal device 200 of this embodiment, the operating system 242 is executed to generate the telephone number authentication unit 230 described below. The telephone number authentication unit 230 may be configured as a resident process of the activated operating system 242, or may be configured as an API that is called and executed each time the device is used.

[0034] The payment application program 244 is a program for running the payment application 220 on the user terminal device 200. The payment application 220 is generated when the payment application program 244 is executed by a start-up operation by the user.

[0035] The communication unit 210 is a communication interface for connecting the user terminal device 200 to the network NW. The communication unit 210 is, for example, a network interface card. For example, the communication unit 210 includes a first interface including a SIM (Subscriber Identity Module) linked to a telephone number. The communication unit 210 transmits and receives SMS messages via the first interface. The communication unit 210 may also include a LAN interface (second interface) such as Wi-Fi (registered trademark) or Bluetooth (registered trademark).

[0036] The telephone number authentication unit 230 provides a function (phone number authentication) for authenticating telephone numbers registered in the user terminal device 200. More specifically, when the telephone number authentication unit 230 receives an authentication request from outside, it attempts to verify the validity of the telephone number linked to its own device (user terminal device 200), and if the validity is verified, it returns the telephone number to the requestor. If the validity is not verified, the telephone number authentication unit 230 may return an error to the requestor. Details of verifying the validity of a telephone number will be described later. The program for realizing the telephone number authentication unit 230 is an example of a "phone number authentication program."

[0037] [Phone number verification] FIG. 8 is a diagram showing an example of the process flow when user terminal device 200 of the embodiment authenticates a user through phone number authentication. First, in user terminal device 200, phone number authentication unit 230 receives an authentication request through phone number authentication from a requesting application program (S101). Here, as an example, payment application 220 is assumed as the requesting application program, but the requesting application program may be any application program. Furthermore, phone number authentication is not limited to an authentication method for a specific purpose, and may be used as an authentication method for any purpose. Here, it is assumed that phone number authentication is used as an authentication method when a user logs in to payment application 220. In this case, payment application 220 requests phone number authentication from phone number authentication unit 230 when the user performs a login operation.

[0038] Next, the telephone number authentication unit 230 determines whether an authenticated telephone number is registered for the user of the own device (S102). The authenticated telephone number is a telephone number that has been registered as authenticated by the authenticated telephone number registration process described below. The authenticated telephone number may be registered in the user terminal device 200, or may be registered in another device (such as the management server 300) that can communicate with the user terminal device 200.

[0039] If it is determined in S102 that the authenticated phone number is registered, the phone number authentication unit 230 then determines whether the registered authenticated phone number has been tampered with (S103). For example, if the user's authenticated phone number is managed by an external management server 300, such as when user information (including the phone number) of an Android (registered trademark) device is managed by a Google (registered trademark) server, the phone number authentication unit 230 can determine whether the authenticated phone number managed by the management server 300 for the user matches the authenticated phone number registered in the phone number authentication unit 230 by inquiring of the management server 300. If it is determined in S103 that the authenticated phone number is "not tampered with," the phone number authentication unit 230 returns the authenticated phone number to the payment application 220 that made the request and ends the series of processes (S104: authentication successful). As another mode of phone number authentication, the phone number authentication unit 230 may be configured to receive a phone number to be authenticated from the requester and determine that the authentication is successful if the phone number matches the authenticated phone number. In this case, the telephone number authentication unit 230 may be configured to return only the authentication result to the request source instead of returning the authenticated telephone number. Also, in this case, the telephone number authentication unit 230 may be configured to return the authentication result after confirming that the authenticated telephone number has not been tampered with.

[0040] On the other hand, if it is determined in S103 that the authenticated phone number has been tampered with, the phone number authentication unit 230 returns an error to the payment application 220 that made the request, and ends the series of processes (S105: authentication failed). If it is determined in S102 that the authenticated phone number has not been registered, the phone number authentication unit 230 then executes an authenticated phone number registration process (S106). The authenticated phone number registration process is a process of registering the phone number used in the user terminal device 200 as an authenticated phone number in the user terminal device 200. The authenticated phone number may be registered in the management server 300. Upon completing the authenticated phone number registration process, the phone number authentication unit 230 returns the registered authenticated phone number to the payment application 220 that made the request, and ends the series of processes (S104: authentication successful). The phone number authentication unit 230 may be configured to accept a phone number to be registered from the requestor, and register the phone number as an authenticated phone number. In this case, the phone number authentication unit 230 may be configured to return only the authentication result to the requestor instead of returning the authenticated phone number after registration. If an error occurs in the authenticated phone number registration process, the phone number authentication unit 230 may proceed to S105, return an error to the requestor's payment application 220, and end the series of processes. The authenticated phone number registration process is an example of a "first process," and the process of responding to authentication success by returning the authenticated phone number to the requestor when the authenticated phone number has been registered is an example of a "second process."

[0041] FIG. 9 illustrates an example of the flow of the authenticated phone number registration process. As described in FIG. 8, the authenticated phone number registration process is executed when an authenticated phone number is not registered for the user of the user terminal device 200. In the authenticated phone number registration process, the phone number authentication unit 230 performs processing to verify the validity of the phone number associated with the user terminal device 200. If the validity is verified, the phone number is associated with the user's identification information and managed. This management information may be stored by the operating system 242 of the user terminal device 200, or by the management server 300 or the payment server 100. In the example of FIG. 8, the authenticated phone number registration process is executed as part of the flow when an authentication request is generated. However, the authenticated phone number registration process may be executed at any time as needed by the user or the payment application 220. First, in the user terminal device 200, the phone number authentication unit 230 acquires a phone number and carrier information from an active SIM configured for calling among the SIMs installed in the communication unit 210 (S201).

[0042] As described above, the phone number authentication unit 230 is part of the operating system 242, and therefore the phone number authentication unit 230 can obtain information about the SIM by any method within the scope of the operating system's authority. For example, if the SIM's intended use can be set by the terminal user, the phone number authentication unit 230 can recognize the SIM for calls by referencing that setting information. In addition, since the SIM's status (normal, abnormal, valid, invalid, etc.) can generally be recognized at the operating system level, the phone number authentication unit 230 can recognize an active SIM through the operating system's functions.

[0043] Next, the telephone number authentication unit 230 checks the consistency of the carrier information acquired in S201 (S202). More specifically, the telephone number authentication unit 230 checks whether the content of the acquired carrier information matches the content set in the user terminal device 200. If the consistency of the carrier information is confirmed, the telephone number authentication unit 230 then notifies the management server 300 of the telephone number acquired in S201 (S203) and makes a call to the telephone number of the management server 300 (S204). After the call is received on the management server 300 side, the telephone number authentication unit 230 promptly disconnects the call line (S205). Note that if the consistency of the carrier information is not confirmed in S202, the telephone number authentication unit 230 may cancel subsequent processing and abnormally terminate the authenticated telephone number registration process.

[0044] Meanwhile, the telephone network accepts the call request in S204, and upon accepting the call request, the telephone network connects the call line between the user terminal device 200 and the management server 300 (S206). As a result, the call from the user terminal device 200 is received by the management server 300, and this is recorded in the management server 300's incoming call history. Next, the management server 300 confirms that the caller's telephone number of the call received in S206 (an example of a second call) matches the telephone number notified in advance by the user terminal device 200 in S203 (S207), and then makes a call back to the notified telephone number (S208). As in S205, the management server 300 promptly disconnects the call line after the call of S208 is received by the user terminal device 200 (S209).

[0045] Meanwhile, the call origination request of S208 is accepted by the telephone network, and upon accepting the call origination request, the telephone network connects the call line between the management server 300 and the user terminal device 200 (S210). As a result, the call origination from the management server 300 (an example of a first call) is received by the user terminal device 200, and this is recorded in the incoming call history of the user terminal device 200. After disconnecting the return call, the management server 300 subsequently notifies the telephone number authentication unit 230 of the call origination telephone number of the call (S211).

[0046] The management server 300 may be configured to select the caller's phone number to be used when making a call (calling back) in S208 from a plurality of phone numbers (e.g., 100) prepared in advance. The selection method is not limited to a specific method as long as it can enhance the confidentiality of the caller's phone number. For example, the selection method may be round robin or random. This increases the confidentiality of the caller's phone number when making a call back, thereby improving the security of the phone number.

[0047] Next, in the user terminal device 200, when the telephone number authentication unit 230 confirms that the caller telephone number of the outgoing call received in S210 matches the caller telephone number notified subsequently in S211 (S212), the telephone number authentication unit 230 registers the telephone number acquired from the SIM in S201 as an authenticated telephone number (S213). Note that the telephone number authentication unit 230 may be configured to notify the management server 300 of the authenticated telephone number registered in S213 (S214). In this case, the management server 300 may be configured to manage the notified authenticated telephone number in association with the user's identification information (S215).

[0048] According to the telephone number authentication of the embodiment described above, by verifying the validity of the telephone number linked to the user terminal device 200 in advance, it is not necessary to verify the validity of the telephone number via SMS each time authentication is performed. Furthermore, the telephone number authentication of the embodiment verifies the validity of the telephone number based on the success or failure of a call made via a telephone network. That is, in the telephone number authentication of the embodiment, an authenticated telephone number can be said to be a number whose call has been accepted by a communications carrier. Therefore, the telephone number authentication of the embodiment can prevent spoofing by phishing or the like and improve the security of telephone number-based authentication.

[0049] Furthermore, since the telephone number authentication in the embodiment is provided as part of the functions of the operating system 242 of the user terminal device 200, it is possible to realize a telephone number-based authentication mechanism without requiring special authority from the application program (in the embodiment, the payment application 220) requesting the authentication.

[0050] Furthermore, according to the telephone number authentication of the embodiment, if the validity of the telephone number has been verified, it is only necessary to return the pre-registered authenticated telephone number to the requestor, so that the authentication request can be processed independently by the user terminal device 200. Therefore, once the user has authenticated the telephone number, the time required for subsequent telephone number authentication can be reduced.

[0051] <Modification> The phone number authentication unit 230 may be configured to delete the registration of an authenticated phone number when a predetermined cancellation condition is met for the SIM associated with the authenticated phone number. For example, the cancellation condition may be that the SIM associated with the authenticated phone number has been inserted or removed from the communication unit 210, or that the SIM associated with the authenticated phone number has been inactive as a calling SIM for a predetermined period of time or more. For example, a state in which a SIM is inactive as a calling SIM may be a state in which the SIM's use has been changed from calling to another use. Furthermore, a state in which a SIM is inactive as a calling SIM may be a state in which the SIM itself has been disabled or is not operating normally due to a malfunction or the like. In this way, by setting a cancellation condition for the authenticated status of an authenticated phone number, it is possible to prevent unauthorized use of phone number authentication by a third party.

[0052] 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]

[0053] 100 Payment Server 110 Communications Department 120 Payment Contents Department 130 Payment processing unit 140 Information Management Department 170 Storage section 172 User information 174 Payment Content Information 176 Affiliated Stores / Store Information 200 User terminal device 210 Communications Department 220 Payment App 230 Phone Number Authentication Department 240 Storage section 242 Operating Systems 244 Payment App Program 300 Management Server 50 First store terminal device 60 Store Code Image 70 Second store terminal device 72 Merchant Interface

Claims

[Claim 1] An operating system that is installed in a user's terminal device and determines basic operations of the terminal device, a telephone number authentication program that authenticates the user based on a telephone number linked to the terminal device in response to an authentication request from an application program installed in the terminal device; The telephone number authentication program a first process of registering a telephone number associated with the terminal device as an authenticated telephone number when a predetermined condition is satisfied; a second process of receiving an authentication request based on the telephone number from the application program, and notifying the application program of successful authentication by returning the authenticated telephone number if the authenticated telephone number is registered; Operating systems, including:

Citation Information

Patent Citations

  • Production of quartz glass and apparatus therefor

    JP1987059536A