Application program and service providing system

Abstract

To more reliably prevent fraudulent use. [Solution] An application program that runs on a user terminal device and performs the following processes: displaying a service provision screen on the user terminal device; detecting that the user terminal device is making a call; and, when a screen sharing operation is performed while the user terminal device is making a call, concealing at least some of the information on the service provision screen from the other party of the call.

Description

[Technical Field]

[0001] The present invention relates to an application program and a service providing system. [Background technology]

[0002] A prior art service providing device has been disclosed that provides a service to a user in cooperation with an app running on the user's terminal device, and includes a service providing unit that provides the service to a user who presents a code image via the app, a management unit that manages the validity of the code image, and a detection unit that detects fraudulent use of the service based on code information read from the code image presented by the user. When the management unit receives a duplication notification from the app indicating that an operation to duplicate the code image has been performed on the terminal device, it invalidates the code image that was the target of duplication by the operation. When the code information received when using the service has been invalidated, the detection unit determines that the use of the service is fraudulent (Patent Document 1). [Prior art documents] [Patent documents]

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

[0004] Unauthorized use of services, such as copying code images, can be achieved not only by simple operations such as screen capture, but also by other operations. Conventional technologies have not addressed preventing unauthorized use from a broader perspective.

[0005] The present invention has been made in consideration of the above circumstances, and one of its objects is to provide an application program and a service providing system that can more reliably prevent unauthorized use. [Means for solving the problem]

[0006] One aspect of the present invention is an application program that runs on a user terminal device and performs the following processes: displaying a service provision screen on the user terminal device; detecting that the user terminal device is making a call; and, when a screen sharing operation is performed while the user terminal device is making a call, concealing at least some of the information on the service provision screen from the other party of the call. [Effects of the Invention]

[0007] According to one aspect of the present invention, fraudulent use can be prevented more reliably. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates basic aspects of brick-and-mortar electronic payment. [Figure 2] FIG. 1 is a diagram illustrating an example of a configuration for performing electronic payment (terminal payment) using a payment application. [Figure 3] FIG. 10 is a diagram showing an example of the contents of user information 172. [Figure 4] FIG. 10 is a diagram showing an example of the contents of affiliated store / shop information 174. [Figure 5] FIG. 10 is a diagram showing an outline of a processing flow when a user scan is performed. [Figure 6] FIG. 10 is a diagram showing an outline of the processing flow when a store scan is performed. [Figure 7] FIG. 1 is a diagram showing an example of a configuration for performing electronic payment (card payment) using a payment card. [Figure 8]FIG. 10 is a diagram showing an example of a display screen displayed by each of the old user terminal device 10-1 and the new user terminal device 10-2 when an account is taken over. [Figure 9] FIG. 10 is a diagram showing an example of a display screen on which the user terminal device 10 displays a code image for payment. [Figure 10] FIG. 10 is a diagram showing an example of a display screen on which the user terminal device 10 displays a code image for verifying the other party when a remittance is made between users. [Figure 11] FIG. 10 is a diagram illustrating an example of a screen in which a code image is not displayed. [Figure 12] FIG. 10 is a sequence diagram showing an example of a flow of processing executed mainly by the authentication device. [Figure 13] FIG. 10 is a diagram for explaining the processing of payment application 20 to prevent fraudulent use. [Figure 14] FIG. 10 is a diagram illustrating a specific method of mask processing. [Figure 15] 10 is a flowchart showing an example of the flow of processing executed by payment application 20. DETAILED DESCRIPTION OF THE INVENTION

[0009] [overview] Hereinafter, with reference to the drawings, an embodiment of an application program and a service providing system according to the present invention will be described. The application program runs on a user terminal device and cooperates with a service server to provide a service to a user. The service may be an electronic payment service, an electronic commerce service, a user-to-user remittance service, or any of a variety of other services provided via a network. In the following description, the service is referred to as an electronic payment service, the service server as a payment server, and the application program as a payment app.

[0010] An electronic payment service is provided, for example, through cooperation between an application program, a payment server, and a credit card 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) that exists in real space, but may also include a virtual store for e-commerce. A virtual store may also include one provided by an entity different from the operator of the electronic payment service. In such cases, when paying for purchases at the virtual store, the user is controlled to transition to the 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 processing such as payment when a purchase is made at a store is mainly conducted between the user and the affiliated store. Alternatively, processing such as payment may be conducted between the user and the store.

[0011] [Electronic payment methods at brick-and-mortar stores] 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, either 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 the PAN (primary account number) using a credit card reader. Then, either the medium M or the store equipment E (the party that obtains information from the other) transmits the payment information required for the payment to the payment system S via a network NW. Both the medium M and the store equipment E may send 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 are 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 that communicate via the network NW, which will be described below, are assumed to have communication devices such as network cards and wireless communication modules.

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

[0013] 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 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 central processing unit (CPU), etc. In the user terminal device 10, a processor such as a CPU executes a payment application 20, which operates in cooperation with a payment server 100 to provide electronic payment services to users. The payment application 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 application 20 (or receive / acquire information from the payment application 20)" may be used interchangeably, but these terms are merely different expressions and are not intended to distinguish between them.

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

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

[0016] 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. An affiliated store interface 55 runs on the information terminal 50. 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 and the like 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 corresponding 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).

[0017] The payment server 100 communicates with the credit card server 200 via a network NW. The payment server 100 includes, for example, a content providing unit 110, an information management unit 120, a payment processing unit 130, a code image providing unit 140, an authentication unit 150, and a storage unit 170. The code image providing unit 140 may be included in other functional units such as the content providing unit 110 and the authentication unit 150.

[0018] The components of the payment server 100 other than the storage unit 170 are realized by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented using a large scale integration (LSI), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or the like. The program may be realized by hardware (including circuitry) such as a Gate Array (GPU) 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.

[0019] The storage unit 170 is a HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device that can be accessed by the payment server 100 via a network. The storage unit 170 stores information such as user information 172 and affiliated store / shop information 174.

[0020] The content providing unit 110 has, for example, a function of a web server, and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The content providing unit 110 provides the content to the user terminal device 10 in the form of a web page, and provides the user terminal device 10 with parameters required for the payment application 20 to render an image.

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

[0022] 3 is a diagram showing an example of the contents of user information 172. User information 172 is information in which, for example, 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, authentication information, and other information are associated with one another. Hereinafter, a user instance (electronic payment account) in which this information is associated may be referred to as an account. In the figure, items marked with "-" indicate that they are not set.

[0023] The user URL is used for remittance processing 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 on which the user registered for the electronic payment service (the date on which the account was created). The charge balance is information indicating the balance of electronic money that the user has set by transferring money to the account in advance. Remittance 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 charge history, which is a record of the user transferring money to the electronic payment service in advance to increase the charge balance, and payment history, which shows the details of the 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.).

[0024] The identity verification flag is information indicating whether or not the user has completed identity verification using an ID document. Deferred payment can be selected if identity verification has been completed, and 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 is information indicating whether or not the setting operations to make deferred payment selectable have been completed. Deferred payment condition information is information indicating various conditions such as the deferred payment limit and the amount used in the current month. Authentication information will be described later.

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

[0026] The payment processing unit 130 performs various processes for electronic payment. There are two methods for terminal payment: a first method (user scan) and a second method (store scan), which will be explained below.

[0027] FIG. 5 shows an overview of the process flow when a user scan is performed. First, the user terminal device 10, with the payment application 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 application 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 affiliated store / store information 174 using the affiliated store ID and store ID corresponding to the store URL, acquires information about the affiliated store name and store name (S3), and sends this to the payment application 20 (S4). The user enters the payment amount into the payment application 20 on the screen displaying the affiliated store name and store name (S5). The payment application 20 then generates second payment information including at least the payment amount and sends it to the payment server 100 (S6).

[0028] If the "Terminal Payment Method" in the user information 172 of 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 by, for example, 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 used as electronic money itself, for example, but rather the amount corresponding to the item value of the sales proceeds is transferred to a bank account in a cycle determined by an 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 transmits the first payment information and the second payment information to the credit card server 200 to request electronic payment (S7-2). The credit card server 200 performs electronic payment by adding the payment amount to the user's monthly usage amount based on the received information and deducting the monthly usage amount from the user's bank account after the closing date (S7-3).

[0029] Then, the payment processing unit 130 sends a payment completion notice (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). 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 procedure for the user to input the payment amount is omitted, and the information on the payment amount 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.

[0030] FIG. 6 is a diagram showing an overview of the processing flow when a store scan is performed. First, when the payment app 20 is launched, when a payment operation is performed using the payment app 20, when an automatic update timing (e.g., every minute) occurs, and at other timings, the payment app 20 sends a request to issue a one-time code to the payment server 100 (S11). The code image providing unit 140 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). The payment amount information is acquired in advance by reading a barcode or manually entering it.

[0031] 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 the 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 FIG. 5. On the other hand, if the "terminal payment method" is set to "post-payment," the payment server 100 transmits the first payment information and the 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).

[0032] Then, the payment processing unit 130 transmits a payment completion notification to the payment application 20 via the content providing unit 110 (S18), and the payment application 20 displays a payment completion screen (S19).

[0033] Note that electronic payment may be performed using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuing a one-time code may be omitted in store scanning, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0034] It should be noted that the "post-payment" settlement may be performed within the settlement server 100, rather than being managed by the credit card server 200. In this case, the components such as the settlement card 60 and the credit card server 200 may be omitted.

[0035] [Configuration (Card Payment)] 7 is a diagram showing an example of a configuration for performing electronic payment (card payment) using a payment card. This electronic payment is performed 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, which constitutes part of a payment system S, and a credit card server 200. The credit card server 200 communicates with the credit card processing terminal 70 via a network NW.

[0036] The credit processing terminal 70 is installed in the store, similar to the in-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 a personal identification number (PIN) from an inserted or held-up credit card and compares it with the PIN entered by the user. It also transmits a primary account number (PAN) 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 agent (acquirer) 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 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 communication chip incorporates a storage medium storing the PIN and communicates with an external device via a contactor (or a 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 conveying the payment amount, but detailed explanations distinguishing between these will be omitted below.

[0037] The credit card server 200 communicates with the payment server 100 via a 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 may be implemented 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 device. The memory unit 270 stores information such as card user information 272.

[0038] The information management unit 210 edits, adds, deletes, etc., and manages the card user information 272. The card user information 272 is information in which, for example, information unique to a user (e.g., PAN), a card payment method, and the user's account ID (used by the payment server 100) are associated with one another. The card payment method is setting information that indicates whether the user will make electronic payment using the charged balance (balance payment) or deferred payment when making a card payment.

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

[0040] The payment allocating unit 230 refers to 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 "post-payment." If the "card payment method" is set to "post-payment," the payment allocating 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 allocating 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 the same processes as S7-1 in Figure 5 and S17-1 in Figure 6.

[0041] The credit interface 220 checks the PAN and expiration date, and verifies whether the cumulative payment amount exceeds the current month's upper limit, etc. 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.

[0042] [Unauthorized use prevention] The operation of the payment server 100 to prevent fraudulent use will be described below. As described in relation to Fig. 6, the code image providing unit 140 generates a one-time code, which is an example of information for displaying a code image, and transmits it to the payment application 20. The code image is used for user authentication in various situations in order to receive electronic payment services.

[0043] When authentication unit 150 receives notification information from payment application 20 indicating that a predetermined operation (described later) that enables copying of a predetermined screen of payment application 20 has been performed while the predetermined screen of payment application 20 is displayed, authentication unit 150 grants permission to provide electronic payment services based on the results of checking multiple check items, including whether or not the notification information has been acquired. The predetermined screen includes a screen on which a code image is displayed.

[0044] For example, when the authentication unit 150 acquires decoded information based on information obtained by decoding a code image from the new user device 10-2 that has read a code image for login authentication to transfer an account from the old user terminal device 10-1 to the new user terminal device 10-2, the authentication unit 150 permits the provision of services to the new user terminal device 10-2 (account transfer) based on the decoded information and the results of confirmation of multiple confirmation items. The contents of the decoded information will be described later. FIG. 8 is a diagram showing an example of a display screen displayed by each of the old user terminal device 10-1 and the new user terminal device 10-2 when the account transfer is performed. As shown in the figure, when an account transfer operation is first performed on the old user terminal device 10-1, a one-time code request is made from the payment application 20 to the code image providing unit 140, and a login authentication code image is displayed based on the one-time code provided by the code image providing unit 140. By reading this with the new user terminal device 10-2, login using the new user terminal device 10-2 becomes possible.

[0045] Furthermore, when the authentication unit 150 acquires decoded information based on information obtained by decoding a code image for payment using an electronic payment service from a device that reads the code image, the authentication unit 150 may authorize the provision of a service (in this case, making a payment) based on the decoded information and the confirmation results of multiple confirmation items. FIG. 9 is a diagram showing an example of a display screen on which the user terminal device 10 displays a code image for payment. On this display screen, the code image is displayed in area A1, and payment is made according to the flow described in FIG. 6. The available balance at this time and other information are also displayed. The code image is displayed not only when a payment operation is performed, but also on the home screen of the payment app 20. Like the code image for payment, the home screen is also treated as a target for permission / prohibition of service provision.

[0046] Furthermore, electronic payment services include remittance services between users. When the authentication unit 150 acquires decoded information based on information obtained by decoding a code image from another user terminal device 10 that has read a code image for verifying the recipient of a remittance between users (including both the sender and the receiver), the authentication unit 150 may authorize the provision of the service (in this case, the registration of the user associated with the user terminal device 10 that displayed the code image as the recipient of the remittance, or the remittance itself) based on the decoded information and the results of confirmation of multiple confirmation items. FIG. 10 is a diagram showing an example of a display screen on which the user terminal device 10 displays a code image for verifying the recipient of a remittance between users. On this display screen, the code image is displayed in area A1, along with a link to a screen for entering the user's username (if registered) and the requested amount.

[0047] Without being limited to this, the predetermined screen of the payment app 20 may include various screens that are not desirable to be shared with third parties, such as a charge screen, wallet screen, and payment confirmation screen. The predetermined screen may also include an image that does not display a code image. The charge screen accepts input or selection of the charge amount and selection of the fund source (source of charge funds), and displays the charge balance. The wallet screen displays various values ​​held by the user, such as the charge balance, point amount, and investment amount. The payment confirmation screen is displayed as a final confirmation just before payment, and displays details of the transaction to be settled (e.g., merchant name, payment amount) and the source of payment (e.g., charge balance, points, deferred payment limit, etc.).

[0048] The multiple confirmation items include at least whether or not notification information has been received, as well as authentication information (Figure 3) such as decoding information, the device ID of the user terminal device 10, the device name, the client type, the language, the time zone, the IP address, the IP address location (latitude), the IP address location (longitude), the effective radius of the IP address location, the name of the IP address location, the name of the ISP (Internet Service Provider), the OS, the OS version, and the emulator.

[0049] Here, the decoded information may include only the one-time code (the payment information described above is considered separate from the decoded information), or may include some or all of the authentication information described above. Alternatively, the authentication information may be shared by communication between payment app 20 and authentication unit 150, separate from the decoded information, for example, when payment app 20 is started or at regular intervals. In either case, some or all of the authentication information is shared between, for example, the OS of user terminal device 10 and payment app 20, and then transmitted from payment app 20 to authentication unit 150.

[0050] The authentication unit 150 then calculates a score that increases (becomes more desirable) as the degree of match between the most recently acquired multiple check items and the multiple check items acquired at any time before that, and restricts the provision of services if the score is undesirable (for example, lower than a threshold value). For example, the authentication unit 150 restricts the provision of services by prohibiting login for a certain period of time or the execution of specific services (payment, remittance, receipt, etc.).

[0051] The "predetermined operation" includes, for example, an operation of sharing a predetermined screen during a video call. A video call is a function of services provided under various names, such as Zoom (registered trademark), Teams (registered trademark), and SKYPE (registered trademark). The predetermined operation may also include an operation of taking a screenshot of a predetermined screen, or may include other operations. The score SC may also include a parameter indicating that a video call is in progress.

[0052] In addition, if a transfer between users is attempted before or after screen sharing, the score SC may be adjusted according to the characteristics of the recipient's account (such as the date of account creation and whether or not KYC is present), or the score SC may be adjusted according to the payment recipient's usage history (electronic payment may be prohibited if there is no past usage history).

[0053] The payment application 20, in cooperation with the operating system (OS) of the user terminal device 10, has a function of hiding the code image when the above-mentioned predetermined operation is performed on a specific screen on which the code image is displayed. FIG. 11 is a diagram showing an example of a screen on which the code image is hidden. This screen is transitioned to by taking a screenshot from the image on which the code image was displayed. A notice urging the user not to save the code image is displayed in area A3, and the code image is blacked out or otherwise filled in. Furthermore, the authentication device of the embodiment calculates the score SC as described above and approves the provision of electronic payment services based on the results of confirmation of multiple confirmation items, thereby advantageously achieving both prevention of fraudulent use and maintenance of convenience.

[0054] 12 is a flowchart showing an example of the flow of processing executed mainly by the authentication device. First, at a certain timing, payment application 20 transmits authentication information to the authentication device (integrated with payment server 100 in this embodiment) (S20), and the authentication device registers the authentication information in user information 172 (S21).

[0055] Thereafter, payment application 20 sends a one-time code request to the authentication device (S22), and the authentication device sends the one-time code to payment application 20 (S23). Using this, payment application 20 displays a code image (S24). If a predetermined operation is detected in this state (S25), payment application 20 sends notification information to the authentication device (S26). Additionally, payment application 20 also sends authentication information to the authentication device (S27).

[0056] The authentication device compares the authentication information registered in S21 with the authentication information transmitted in S27 and calculates a score as described above (S28). The authentication device determines whether the score is equal to or greater than a threshold (S29), and permits provision of the service if the score is equal to or greater than the threshold (S30), or restricts provision of the service if the score is less than the threshold (S31). Information regarding the restriction on service provision is transmitted to the payment processing unit 130, etc., and is reflected in subsequent processing by the payment server 100.

[0057] [Screen sharing behavior in payment apps] The payment application 20 further performs the following process to prevent fraudulent use. FIG. 13 is a diagram illustrating the process of the payment application 20 to prevent fraudulent use. First, in the first stage ((1) in the diagram), a user of the user terminal device 10 (hereinafter referred to as user A) and a user of another terminal device 300 (hereinafter referred to as user B) are engaged in a video call. User B is a person who is attempting to fraudulently obtain a code image or the like from user A.

[0058] In the second stage ((2) in the figure), user A operates button B1 in response to guidance from user B to start screen sharing.

[0059] In the third stage ((3) in the figure), User A selects the icon of the payment app 20 in response to guidance from User B to launch the payment app 20. The same process is performed when User A selects the payment app 20 from a list of apps running in the background. The launched payment app 20 then queries the operating system (OS) to determine whether User A is on a call, using the operating system's (OS) API (Application Programming Interface), etc., to detect that User A is on a call and that screen sharing (or screen recording) is occurring. This query is executed repeatedly, for example. "On a call" here may include both a voice-only call (such as a telephone call) and a video call. The payment app 20 running in the background may make the above query when it is displayed full-screen on the user terminal device 10, or may make the query repeatedly while in the background.

[0060] In the fourth stage ((4) in the figure), the payment app 20 screen (service provision screen) is displayed on the user terminal device 10. However, the entire payment app 20 screen is not shared with the other terminal devices 300, and at least images for realizing important functions, such as code images, are concealed (masked). This prevents user B from fraudulently obtaining code images, etc. from user A. Furthermore, even if user B attempts to induce user A to perform operations on the payment app 20 that would benefit him in addition to the fraudulent acquisition of code images, user B cannot fully confirm the status of the payment app 20, making such manipulation difficult. On the other hand, because the payment app 20 screen is displayed to user A, it is also prevented user A from suspecting that the user terminal device 10 has malfunctioned. In the fourth stage, a warning screen informing user A of the possibility of fraudulent use may be displayed on the user terminal device 10 and / or the other terminal devices 300.

[0061] Here, the screen that is hidden on the other terminal device 300 during screen sharing may not only be a predetermined screen (described above) of the payment app 20, but may be the entire screen of the payment app 20. Also, although part of the screen of the payment app 20 is displayed on the other terminal device 300 in FIG. 13, the entire screen of the payment app 20 may be hidden on the other terminal device 300.

[0062] The following methods, for example, are employed as specific methods for the payment application 20 to perform masking. FIG. 14 is a diagram illustrating specific methods of masking. Method (A) is a method in which the payment application 20 stores the concealed image in a display screen storage area in memory such as RAM referenced by the operating system (OS), and the operating system (OS) reads the image from the display screen storage area. Method (B) is a method in which the payment application 20 directly issues a masking instruction to the operating system (OS).

[0063] FIG. 15 is a flowchart showing an example of the flow of the process executed by the payment app 20 described above. The process of this flowchart is repeatedly executed while the payment app 20 is running. First, the payment app 20 determines whether a call is taking place on the user terminal device 10 (S40). A call includes, for example, both an audio-only call and a video call, but for the application of the present invention, it is sufficient to detect that at least a video call is taking place. If a call is not taking place, one routine of this flowchart ends. If a call is taking place on the user terminal device 10, the payment app 20 determines whether screen sharing (or screen recording) is taking place as a result of a screen sharing operation performed by user A (S41). If a screen sharing operation is not taking place, the process returns to the determination process of S40. Note that screen sharing is generally performed during a video call, so the determination process of S40 may be omitted. In this case, if a screen sharing operation is not taking place, the determination process of S41 is repeatedly performed.

[0064] When the screen sharing operation is performed, the payment application 20 displays the screen on the user terminal device 10 and also performs a process of hiding part of the screen from the other party of the video call (S42).

[0065] Instead of the payment application 20 making an inquiry to the operating system (OS) to obtain the presence or absence of a call and the screen sharing status, the operating system (OS) may automatically notify the payment application 20 of the same information. Furthermore, if the payment application 20 is not running when a call is started, the determination processes of S40 and S41 may be performed by resident software in the payment application 20.

[0066] As shown in the determination processes of S40 and S41, instead of detecting both a call and screen sharing (or screen recording) separately, it is also possible to detect that "a video call is in progress and the screen is being shared" based on an inquiry to the operating system (OS) or a notification from the operating system (OS). In other words, the payment application 20 may simultaneously detect that the user terminal device 10 is in a state of both a video call and screen sharing.

[0067] In this way, when a call (especially a video call that allows screen sharing) is made on user terminal device 10 and the screen is shared, payment application 20 of the embodiment conceals at least part of the information on the display screen from the terminal device of the other party of the call. This makes it possible to more reliably prevent fraudulent use.

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

[0069] E. Store Facilities M medium S payment system 10 User terminal device 20. Payment App 30 Store payment terminal device 40 Store code image 100 Payment Server 140 Code Image Provided by 150 Authentication Department 172 User information 300 Other terminal devices

Claims

1. An application program that operates on a user terminal device and cooperates with a payment server to provide an electronic payment service to a user, The user terminal device A process of displaying a service provision screen used for electronic payment; A process of detecting that the user terminal device is making a call; When a screen sharing operation is performed when it is detected in the detecting process that the user terminal device is making a call, a process of hiding at least a portion of the code image on a screen displaying a code image used for the electronic payment among the plurality of service provision screens from the other party of the call, and displaying the service provision screen on the user terminal device; An application program for executing

2. The user terminal device causing an operating system to provide an image in which at least a portion of the code image is hidden as a screen for screen sharing, thereby performing a process of hiding at least a portion of the code image from the other party of the call; 2. The application program according to claim 1.

3. The user terminal device outputting an instruction to an operating system to conceal at least the part of the code image from the other party of the call, thereby causing the operating system to perform a process of concealing at least the part of the code image from the other party of the call; 2. The application program according to claim 1.

4. An application program that operates on a user terminal device and cooperates with a payment server to provide an electronic payment service to a user, The user terminal device A process of displaying a service provision screen used for electronic payment; A process of detecting that the user terminal device is in a call and screen sharing state; When it is detected in the detecting process that the user terminal device is in a state of making a call and sharing a screen, at least a portion of the code image on a screen displaying a code image used for the electronic payment among the plurality of service provision screens is hidden from the other party of the call, and the service provision screen is displayed on the user terminal device; An application program for executing

5. The application program according to claim 1; a service server that cooperates with the application program to provide a service to a user, and that limits the provision of the service based on a confirmation result of a plurality of confirmation items including whether or not the screen sharing operation is performed; A service providing system comprising:

6. the service server calculates a score based on the check results of the plurality of check items, and if the score is unfavorable, restricts the provision of the service. The service providing system according to claim 5.

Images