WO2022224780A1 - Dispositif de traitement d'informations, système de traitement d'informations, procédé et programme - Google Patents

Dispositif de traitement d'informations, système de traitement d'informations, procédé et programme Download PDF

Info

Publication number
WO2022224780A1
WO2022224780A1 PCT/JP2022/016199 JP2022016199W WO2022224780A1 WO 2022224780 A1 WO2022224780 A1 WO 2022224780A1 JP 2022016199 W JP2022016199 W JP 2022016199W WO 2022224780 A1 WO2022224780 A1 WO 2022224780A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
payment
processing
information
user
Prior art date
Application number
PCT/JP2022/016199
Other languages
English (en)
Japanese (ja)
Inventor
良雄 小田
Original Assignee
フェリカネットワークス株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by フェリカネットワークス株式会社 filed Critical フェリカネットワークス株式会社
Priority to JP2023516406A priority Critical patent/JPWO2022224780A1/ja
Publication of WO2022224780A1 publication Critical patent/WO2022224780A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
    • G07G1/00—Cash registers
    • G07G1/12—Cash registers electronically operated
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • the present disclosure relates to an information processing device, an information processing system, a method, and a program. More specifically, the present invention relates to an information processing device, an information processing system, a method, and a program that enable secure cashless payment without imposing a heavy burden on stores and users.
  • code information such as bar codes and QR codes (registered trademark).
  • code information such as a barcode or QR code (registered trademark) presented by the store is read by a user terminal such as a camera-equipped smartphone (smartphone), and the read data is sent to a payment server to make a payment. can be done.
  • a payment processing system that uses this code information only requires the store to prepare paper on which the code information such as a barcode or QR code (registered trademark) is printed, which has the advantage of significantly reducing costs and labor on the store side. be.
  • the user when performing payment processing using such code information, the user is required to perform the following series of processing.
  • the user activates the camera of the camera-equipped smartphone and photographs code information such as a bar code or QR code (registered trademark) at the store.
  • the user inputs the payment amount into the smartphone and asks the store clerk to show the smartphone screen for confirmation.
  • the user communicates with the payment server to perform payment processing, and when the payment completion screen is displayed on the smartphone, the smartphone screen is shown to the store clerk to have the salesclerk confirm the payment completion.
  • the settlement process using code information has a problem that many processes are required of the user and the burden is heavy. Also, in this process, it is possible for an unauthorized user to display a "fake payment completion screen" on the smartphone, and in this case, there is a possibility that the product will be taken away without the actual payment being made. have a nature.
  • Patent Document 1 Japanese Unexamined Patent Application Publication No. 2014-075038 discloses one configuration for preventing such fraudulent processing.
  • Patent Document 1 makes it possible to confirm the settlement amount by transmitting bar code information in which the settlement amount is coded from the settlement server to a user terminal such as a smartphone at the time of executing the settlement process, and reading this by the store terminal. configuration is disclosed.
  • a user terminal such as a smartphone
  • the store clerk needs to take a smartphone image in order to read the barcode on the smartphone screen, which increases the burden on the store side.
  • the present disclosure has been made, for example, in view of the above-described problems, and an information processing device and an information processing device that enable reliable cashless payment processing that does not cause a large burden on stores and users.
  • An object is to provide a system, a method, and a program.
  • a first aspect of the present disclosure includes: a data processing unit that generates payment data; Having a communication unit that transmits the payment data, The data processing unit generating payment data that has undergone security ensuring processing according to a security ensuring algorithm determined in advance with a payment server that executes payment processing according to the payment data; Further, the information processing device generates payment data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the payment data is added.
  • a second aspect of the present disclosure is It has a communication section and a data processing section that execute communication between the store side terminal and the payment server,
  • the data processing unit A configuration in which user data is added to payment data received from the store-side terminal to generate transmission data to the payment server,
  • the data processing unit generating user data subjected to security ensuring processing according to a security ensuring algorithm predetermined with the payment server;
  • the information processing apparatus generates transmission data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the user data is added.
  • a third aspect of the present disclosure is An information processing system having a payment data processing device connected to or integrated with a store terminal for inputting a payment amount, a user terminal, and a payment server,
  • the payment data processing device generating payment data subjected to security ensuring processing according to a security ensuring algorithm predetermined with the payment server; generating payment data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the payment data is added, and transmitting the payment data to the user terminal;
  • the user terminal is A memory of flag-added user data obtained by adding a data format identification flag indicating a data format corresponding to a security ensuring algorithm applied to said user data to user data subjected to security ensuring processing according to a security ensuring algorithm determined by said settlement server.
  • the payment server a configuration for executing data verification processing for each of the payment data and the user data;
  • the verification processing of the payment data includes: Execute data verification processing by applying a data verification algorithm corresponding to the security ensuring algorithm determined in advance with the payment data processing device;
  • the user data verification process includes: The information processing system executes data verification processing by applying a data verification algorithm corresponding to the security ensuring algorithm determined in advance with the user terminal.
  • a fourth aspect of the present disclosure is An information processing method executed in an information processing device,
  • the information processing device has a data processing unit that generates payment data and a communication unit that transmits the payment data,
  • the data processing unit generating payment data that has undergone security ensuring processing according to a security ensuring algorithm determined in advance with a payment server that executes payment processing according to the payment data;
  • the information processing method includes generating payment data to which a data format identification flag indicating a data format corresponding to a security ensuring algorithm applied to the payment data is added.
  • a fifth aspect of the present disclosure is An information processing method executed in an information processing device,
  • the information processing device has a communication unit that executes communication between the store-side terminal and the payment server, and a data processing unit,
  • the data processing unit executing a transmission data generation step of adding user data to the payment data received from the store terminal to generate transmission data to the payment server;
  • the transmission data generation step includes: generating user data subjected to security ensuring processing according to a security ensuring algorithm predetermined with the payment server;
  • the information processing method includes the step of generating transmission data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the user data is added.
  • a sixth aspect of the present disclosure is An information processing method executed in an information processing system having a payment data processing device connected to or integrated with a store terminal for inputting a payment amount, a user terminal, and a payment server,
  • the payment data processing device generating payment data that has undergone security ensuring processing according to a security ensuring algorithm determined by the payment server; generating payment data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the payment data is added, and transmitting the payment data to the user terminal;
  • the user terminal A memory of flag-added user data obtained by adding a data format identification flag indicating a data format corresponding to a security ensuring algorithm applied to said user data to user data subjected to security ensuring processing according to a security ensuring algorithm determined by said settlement server.
  • the payment server executing the payment data verification process by applying a data verification algorithm corresponding to the security ensuring algorithm predetermined with the payment data processing device;
  • the verification processing of the user data is executed by applying a data verification algorithm corresponding to the security ensuring algorithm determined in advance with the user terminal.
  • a seventh aspect of the present disclosure is A program for executing information processing in an information processing device,
  • the information processing device has a data processing unit that generates payment data and a communication unit that transmits the payment data
  • the program causes the data processing unit to: a process of generating payment data that has undergone security ensuring processing according to a security ensuring algorithm determined in advance with a payment server that executes payment processing according to the payment data;
  • the program executes processing for generating payment data to which a data format identification flag indicating a data format corresponding to a security ensuring algorithm applied to the payment data is added.
  • an eighth aspect of the present disclosure is A program for executing information processing in an information processing device,
  • the information processing device has a communication unit that executes communication between the store-side terminal and the payment server, and a data processing unit,
  • the program causes the data processing unit to: executing a transmission data generation step of adding user data to the payment data received from the store-side terminal to generate transmission data to the payment server;
  • a transmission data generation step a process of generating user data that has undergone security ensuring processing according to a security ensuring algorithm predetermined with the payment server;
  • the program executes a process of generating transmission data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the user data is added.
  • the program of the present disclosure is, for example, a program that can be provided in a computer-readable format to an information processing device or computer system capable of executing various program codes via a storage medium or communication medium.
  • processing according to the program is realized on the information processing device or computer system.
  • a system is a logical collective configuration of a plurality of devices, and the devices of each configuration are not limited to being in the same housing.
  • the payment data processing device generates payment data to which a security ensuring algorithm predetermined by the payment server is applied, adds a data format identification flag, and transmits the data to the user terminal.
  • the user terminal acquires from the memory data obtained by adding a data format identification flag to the user data to which the security ensuring algorithm determined by the settlement server is applied, and transmits the acquired data to the settlement server together with the settlement data.
  • the payment server performs data verification processing on each of the payment data and the user data by applying a data verification algorithm corresponding to the security ensuring algorithm determined between the respective devices.
  • a data verification algorithm corresponding to the security ensuring algorithm determined between the respective devices.
  • FIG. 4 is a diagram illustrating a general sequence of cashless payment using code information
  • FIG. 4 is a diagram illustrating a general sequence of cashless payment using code information
  • FIG. 4 is a diagram illustrating a general sequence of cashless payment using code information
  • It is a figure explaining the example of composition of the information processing system of this indication.
  • FIG. 5 is a diagram illustrating sharing processing of data format information of transmission/reception data executed in the information processing system of the present disclosure
  • FIG. 5 is a diagram illustrating sharing processing of data format information of transmission/reception data executed in the information processing system of the present disclosure
  • FIG. 5 is a diagram illustrating sharing processing of data format information of transmission/reception data executed in the information processing system of the present disclosure
  • FIG. 5 is a diagram illustrating sharing processing of data format information of transmission/reception data executed in the information processing system of the present disclosure
  • FIG. 5 is a diagram illustrating sharing processing of data format information of transmission/reception data executed in the information processing system of the present disclosure
  • FIG. 4 is a diagram illustrating an example of a data format of transmission/reception data used in the information processing system of the present disclosure
  • FIG. 5 is a diagram illustrating sharing processing of data format information of transmission/reception data executed in the information processing system of the present disclosure
  • FIG. 5 is a diagram illustrating sharing processing of data format information of transmission/reception data executed in the information processing system of the present disclosure
  • FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed
  • FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed
  • FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed
  • FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed
  • FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed
  • FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 4 is a diagram illustrating an example of processing executed
  • FIG. 4 is a diagram illustrating an example of processing executed in settlement processing using the information processing system of the present disclosure
  • FIG. FIG. 5 is a diagram illustrating sharing processing of data format information of transmission/reception data executed in the information processing system of the present disclosure
  • FIG. 5 is a diagram illustrating sharing processing of data format information of transmission/reception data executed in the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 4 is a sequence diagram illustrating a processing sequence of payment processing using the information processing system of the present disclosure
  • FIG. 2 is a diagram illustrating a configuration example of a user terminal used for processing of the present disclosure
  • FIG. It is a figure explaining an example of composition of a store terminal and a payment data processor which are used for processing of this indication.
  • It is a figure explaining the hardware configuration example of a user terminal, a store terminal, a payment data processing apparatus, and a payment server used for the process of this disclosure.
  • code information such as bar codes and QR codes (registered trademark).
  • code information such as a barcode or QR code (registered trademark) presented by the store is read by a user terminal such as a camera-equipped smartphone (smartphone), and the read data is sent to a payment server to make a payment. can be done.
  • a payment processing system that uses this code information only requires the store to prepare paper on which the code information such as a barcode or QR code (registered trademark) is printed, which has the advantage of significantly reducing costs and labor on the store side. be.
  • FIG. 1 to 3 show, from left to right, a user 10, a user terminal (such as a smartphone) 11 owned by the user 10, code information 21 of a store 20, and a settlement server 30.
  • FIG. Processing of each step in the sequence diagram will be described in order.
  • Step S11 First, in step S ⁇ b>11 , the user 10 activates a pre-installed payment application on the user terminal 11 .
  • the payment application activated here is a payment application compatible with the payment server 30 in which the payment server 30 performs payment processing.
  • step S12 the user 10 activates the camera of the user terminal 11 in order to read the code information 21 provided in the store 20 using the activated payment application.
  • Step S13 Next, the user 10 uses the camera of the user terminal 11 to read the code information 21 provided in the store 20 in step S13. That is, the code information 21 is photographed. Store information and the like are recorded in the code information 21 .
  • Step S14 the user terminal 11 displays data corresponding to the code information 21 read in step S13. For example, the store name of the store 20 is displayed.
  • Step S15 the user 10 inputs the payment amount to the user terminal 11 in step S15.
  • Payment amount ⁇ 1,250 Enter
  • Step S16 Next, in step S ⁇ b>16 , the user 10 presents the display screen of the user terminal 11 to the store clerk so that the store clerk can confirm the payment amount input to the user terminal 11 .
  • Step S17 the store clerk at the store 20 confirms and accepts the payment amount input to the user terminal 11 .
  • Step S18 Next, the user 10 starts payment processing using the payment application in step S18.
  • Step S19 When the user operates (touches) the payment icon of the payment application displayed on the user terminal 11 in step S ⁇ b>19 , a payment request is transmitted from the user terminal 11 to the payment server 30 .
  • the payment request sent from the user terminal 11 to the payment server 30 includes the user ID or user terminal ID, information (such as the name of the store) read from the code information 21 of the store 20, and the settlement amount entered by the user 10. included.
  • Step S20 the payment server 30 analyzes the data received from the user terminal 11, and registers the user ID (or user terminal ID), shop information, etc. in the database in advance as users and shops that can use the payment service. In addition, the balance of the user is confirmed to determine whether or not the payment is possible.
  • step S21 If payment is not possible, an error message is sent to the user terminal. If it is determined that settlement is possible, the process proceeds to step S21.
  • Step S21 the payment server 30 executes payment processing according to the payment request from the user terminal 11 .
  • the payment server 30 acquires data received from the user terminal 11, that is, code information and payment amount information included in the payment request, and performs payment processing according to these pieces of information.
  • the payment amount is, for example, transferred to a store account or the like registered in association with the store information included in the code information.
  • Step S22 When the payment processing is completed in step S21, the payment server 30 transmits a payment completion notice to the user terminal 11 in step S22.
  • a payment completion notification message is displayed on the user terminal 11, and the user asks the store clerk at the store 20 to confirm the payment completion notification message, and the payment is completed.
  • this method requires the user to perform the following processing.
  • (a) Activate the camera of the user terminal 11 to photograph the code information 21 at the store 20 .
  • (b) Enter the payment amount into the user terminal 11 and have the store clerk at the store 20 show the screen for confirmation.
  • (c) After the payment processing by the payment server 30, when the payment completion screen is displayed on the user terminal 11, the screen is shown to the store clerk at the store 20 to confirm the payment completion.
  • the information processing system of the present disclosure is a system that reduces the burden on the user and the store side, and is a system that can prevent fraud. It enables payment processing.
  • FIG. 4 is a diagram showing a configuration example of an information processing system 50 of the present disclosure. It is assumed that the user 10 goes shopping, eats and drinks at the store 20, and makes a cashless payment using the user terminal 100 such as a smart phone. Cashless payment is, for example, cashless payment such as electronic money, xx pay, code payment, credit card, bank account payment, etc. Actual payment processing is executed by one of the plurality of payment servers 400 shown in FIG. be.
  • Each of the plurality of payment servers 400 is a server that performs cashless payment such as electronic money, xx pay, code payment, credit card, and bank account payment.
  • the payment server A 400a is a payment server that performs cashless payment processing using A-pay, which is one of the cashless payment methods.
  • the payment server B 400b is a payment server that performs cashless payment processing using B-pay, which is one of the cashless payment methods different from A-pay.
  • the user 10 performs usage registration in advance for the cashless payment means that the user wants to use.
  • the user terminal 100 is used to communicate with a payment server that manages cashless payment or a management server, and register a user ID, a user terminal ID, other necessary information, and the like for usage registration.
  • a communication terminal (not shown) of the store 20 is used to communicate with a settlement server or a management server that manages cashless settlement, store information such as store ID (store code) and store name, and settlement shown in the figure.
  • store information such as store ID (store code) and store name, and settlement shown in the figure.
  • Use registration is performed by registering the ID of the data processing device 300 and other necessary information.
  • a user terminal 100 such as a smartphone owned by a user 10 can communicate with a payment server 400 via a communication network.
  • the store terminal 200 and the payment data processing device 300 installed in the store 20 do not need to have a communication function with the payment server 400 .
  • the store terminal 200 is wired or wirelessly connected to the payment data processing device 300 and is capable of writing data to the payment data processing device 300 and reading data recorded in the payment data processing device 300 .
  • Payment data processing device 300 is a device having a short-range wireless communication function such as RF (Radio Frequency) communication, NFC (Near Field Communication) communication, or the like. Alternatively, other short-range wireless communication such as Bluetooth (registered trademark) (BT) communication may be performed.
  • the payment data processing device 300 executes short-range wireless communication with the user terminal 100 such as a smartphone owned by the user 10 .
  • the shop terminal 200 and the payment data processing device 300 are connected by wire using a communication cable. It may be configured to perform wireless communication. Alternatively, the payment data processing device 300 may be integrated into the store terminal 200 .
  • the payment data processing device 300 performs short-range wireless communication with the user terminal 100 such as a smartphone owned by the user 10 .
  • the user terminal 100 also has a short-range wireless communication unit such as NFC, and the user terminal 100 can read data recorded in the memory of the payment processing device 300 by short-range wireless communication. It is also possible to write data to the memory of the payment processing device 300 .
  • Cashless payment is, for example, cashless payment such as electronic money, xx pay, code payment, credit card, bank account payment, etc. Actual payment processing is executed in any of the payment servers 400 shown in FIG.
  • Settlement processing is assumed to be executed in settlement server A 400a shown in FIG.
  • the input amount is displayed on the display section of the store terminal 200 .
  • the settlement amount is 1250 yen.
  • the cashless payment method is A Pay. Note that this cashless payment means (A pay) is a cashless payment means registered in advance by the store 20 and a cashless payment means already registered in the user terminal 100 .
  • cashless payment means registered in the user terminal 100 means that a cashless payment application has been downloaded to the user terminal 100 and the application can be used in the user terminal 100 .
  • a Pay which is one of the cashless payment methods. Note that this is just an example, and any cashless payment means such as electronic money, xx pay, code payment, credit card, and bank account payment may be used.
  • the rough sequence of payment processing is as follows.
  • FIG. ( S ⁇ b>02 ) The payment amount information input to the store terminal 200 is transferred to the payment data processing device 300 .
  • (S03) When the user 10 brings the user terminal 100 closer to the payment data processing device 300, proximity communication is performed between the user terminal 100 and the payment data processing device 300, and payment amount information is transmitted to the user terminal 100 together with store information. be.
  • the user terminal 100 generates data by adding the user ID (or user terminal ID) to the input information (settlement amount information, etc.) from the payment data processing device 300, and transmits the data to the payment server A 400a.
  • the settlement server A 400a verifies the information received from the user terminal 100, executes confirmation processing that the user 10 is a registered user, and that the shop is a registered shop. The amount (balance) is checked, and if it is confirmed that the payment can be made, the payment processing is executed and a payment completion notice is transmitted to the user terminal 100 .
  • the user terminal 100 displays payment completion information on the user terminal 100 upon receipt of the payment completion notice from the payment server A 400a.
  • S07 When the user 10 brings the user terminal 100 close to the payment data processing device 300, the payment completion notification received by the user terminal 100 from the payment server A 400a is transmitted to the payment data processing device 300, and furthermore, the shop terminal 200 , and the settlement completion information is displayed on the shop terminal 200 .
  • the rough sequence of the payment processing is the processing of steps S01 to S07 described above with reference to FIG.
  • the data format of data that has undergone security ensuring processing according to the algorithm is defined in advance. Furthermore, data format information defined between devices is held in the storage unit as shared information by each device that transmits and receives data.
  • a security ensuring algorithm is an algorithm for processing to be applied to transmitted and received data in order to ensure the security of data transmitted and received between devices. It is a data processing algorithm such as cryptographic processing. A specific example of the security ensuring algorithm applied in the processing of the present disclosure will be described later.
  • FIG. 5 is a diagram showing an example of how the data format of payment data to be transmitted from the user terminal 100 to the payment server 400 is determined.
  • the user terminal 100 when the user terminal 100 uses A-pay, the user terminal 100 communicates with the payment server A 400a to ensure the security of the data transmitted from the user terminal 100 to the payment server 400.
  • the data format of the data subjected to the security ensuring process is determined according to the security ensuring algorithm, and this determination information is held as shared information between each device (user terminal 100, settlement server A, 400a).
  • the data format of payment data transmitted from the user terminal 100 to the payment server A 400a (1) A pay 1, (2) A pay 2
  • a pay 1 This is an example when a decision is made to use one of these two data formats.
  • the user terminal 100 when transmitting payment data from the user terminal 100 to the payment server A 400a, the user terminal 100 selects one of two data formats (A pay 1 and A pay 2). Payment data is generated and transmitted to the payment server A, 400a. At this time, a payment data format identification flag indicating which data format is used is added to the transmission data and transmitted.
  • the payment data format identification flag is a flag for identifying the data format of data transmitted and received between devices. Based on the value of the payment data format identification flag, it is possible to determine, for example, the type of security ensuring algorithm applied to the transmitted/received data, the data configuration of the transmitted/received data, and the like. A specific example will be described later in detail.
  • B Pay 1 This is an example of a case where a decision to use this one data format is made.
  • the user terminal 100 when transmitting payment data from the user terminal 100 to the payment server B, 400b, the user terminal 100 always selects the data format (B Pay 1) to generate payment data and send it to the payment server B, 400b. will be sent to
  • FIG. 6 is a diagram showing an example of how the data format of payment data generated by the payment data processing device 300 and transmitted to the payment server 400 is determined. Since the payment data processing device 300 cannot directly transmit data to the payment server 400, the data generated by the payment data processing device 300 is once transmitted to the user terminal 100, and then the user terminal 100 is is transmitted to the settlement server 400 via the
  • the payment data processing device 300 and the payment server A 400a transmit from the payment data processing device 300 to the payment server 400 A security ensuring algorithm for payment data and a data format of data subjected to security ensuring processing according to the security ensuring algorithm are determined, and this decision information is shared among each device (payment data processing device 300, payment server A, 400a). hold as
  • the data format of the payment data transmitted from the payment data processing device 300 to the payment server A 400a via the user terminal 100 is (1) A pay 2, (2) A pay 3 This is an example when a decision is made to use one of these two data formats.
  • the payment data processing device 300 selects one of two data formats (A pay 2 and A pay 3). is selected to generate payment data and transmit it to the payment server A, 400a. At this time, a payment data format identification flag indicating which data format is used is added to the transmission data and transmitted. A specific example will be described later in detail.
  • B Pay 1 This is an example of a case where a decision to use this one data format is made.
  • the payment data processing device 300 when the payment data is transmitted from the payment data processing device 300 to the payment server B, 400b, the payment data processing device 300 always selects the data format (B pay 1) to generate the payment data and make the payment. It will be sent to server B, 400b.
  • the security ensuring algorithm of the transmission data and the data format of the data subjected to the security ensuring processing according to the security ensuring algorithm are determined.
  • the configuration may be such that data is transmitted in accordance with the determined data format.
  • a security ensuring algorithm is an algorithm for processing sent/received data in order to ensure the security of data sent/received between devices. processing, or data processing algorithms such as cryptographic processing.
  • FIG. 8 shows a specific example of a security ensuring algorithm for data transmitted and received between devices and a data format of data subjected to security ensuring processing according to the security ensuring algorithm.
  • Various processes are possible as processes for ensuring the security of data sent and received between devices. Specifically, for example, processing of adding secure information such as a hash value that enables falsification verification of transmitted and received data, signature data, or encryption processing is possible.
  • FIG. 8 shows an example of security schemes corresponding to a plurality of different data formats of data transmitted and received between devices of the information processing system 50 of the present disclosure.
  • the payment server A 400a that handles A-pay which is one of the cashless payment methods, uses four types of data formats corresponding to payment data format identification flags 1 to 4. It is specified as a possible data format. These four types of data formats are settings using different security methods.
  • the payment data format identification flag is a flag for identifying the data format of data transmitted and received between devices. Based on the value of the payment data format identification flag, it is possible to determine, for example, the type of security ensuring algorithm applied to the transmitted/received data, the data configuration of the transmitted/received data, and the like.
  • Payment server B 400b which handles B-pay, which is one of the cashless payment methods, defines two types of data formats corresponding to payment data format identification flags 1 and 2 as available data formats. ing. These two types of data formats also have different security scheme settings.
  • a payment server that handles Cash-X which is one of the cashless payment methods, defines one type of data format of payment data format identification flag 1 as a usable data format. In other words, it defines only the data format conforming to one security method as a method that can be used.
  • the payment server that handles Z payment which is one of the cashless payment methods, also defines one type of data format of payment data format identification flag 1 as a usable data format. In other words, it defines only the data format conforming to one security method as a method that can be used.
  • the data format of the payment data format identification flag 1 of A-pay (A-pay) shown in FIG. 8 has a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • a salt value which is the first control information for generating secure information shown in (4) of FIG. It is a data format with a hash value added.
  • the salt value insertion position is defined as the salt insertion position of the second control information for generating secure information shown in (5) of FIG.
  • the salt value is not included in the transmission data.
  • the data receiving side retains the same salt value, inserts this salt value into the received data, calculates the hash value, and determines whether the calculated hash value matches the hash value added to the received data. Verify the presence or absence of tampering. A specific processing example of this processing will be described later.
  • payment data format identification flags 1 and 2 for A-pay payment data format identification flags 1 and 2 for B-pay
  • cash-X cash-X
  • the security method of the payment data format identification flag 1 is a security method using SHA-2, which is one of hash value calculation methods, but the salt value and salt insertion position are set differently.
  • the security method of the payment data format identification flag 3 of A-pay (A-pay) shown in FIG. 8 is a security method using AES encryption processing. ) is encrypted using the encryption key A, which is the first control information for generating secure information, and the encrypted data is transmitted. The data receiving side holds a decryption key, and decrypts the received data using the decryption key.
  • the security method of the payment data format identification flag 4 of A-pay (A-pay) shown in FIG. 8 is a security method using an RSA signature.
  • signature data is generated using the RSA private key, which is the first control information for generating secure information shown in , and the generated signature data is added to the data string to be tamper-prevented and transmitted.
  • the data receiving side has the same RSA private key for signature, applies the same RSA private key for signature to the received data to generate signature data, and adds it to the generated signature data and the received data.
  • the presence or absence of data falsification is verified by checking whether the signature data match.
  • a security ensuring algorithm for the transmitted and received data and a data format of data subjected to security ensuring processing according to the security ensuring algorithm are set in advance between the devices. to decide.
  • Each device generates and transmits data subjected to security ensuring processing according to a predetermined data format.
  • data verification processing is performed by applying a data verification algorithm corresponding to a security ensuring algorithm determined in advance between data transmitting/receiving devices.
  • the pre-processing performed between the user terminal 100 and the payment server 400 will be described with reference to FIG. 9, and the pre-processing performed between the payment data processing device 300 and the payment server 400 will be described with reference to FIG.
  • the user 10 performs usage registration in advance with the payment server 400 that executes payment processing for the cashless payment method that the user 10 wants to use.
  • the user terminal 100 is used to communicate with a payment server that manages cashless payment or a management server, and register a user ID, a user terminal ID, other necessary information, and the like for usage registration.
  • the store 20 is the same, and the cashless payment method that you want to use is registered in advance.
  • a communication terminal (not shown) of the store 20 is used to communicate with a settlement server or a management server that manages cashless settlement, store information such as store ID and store name, and settlement data processing device 300 shown in the figure. ID, other necessary information, etc. are registered to register for use.
  • the pre-processing described with reference to FIGS. 9 and 10 is processing after these usage registrations are executed.
  • a specific example using the payment server A 400a that performs A-pay payment processing will be described.
  • FIG. 9 is a diagram explaining a specific example of pre-processing executed between the user terminal 100 and the settlement server A, 400a.
  • FIG. 9 is a diagram showing an example of how the data format of payment data transmitted and received between the user terminal 100 and the payment server A 400a is determined.
  • the user terminal 100 determines the data format of payment data to be transmitted and received between the user terminal 100 and the payment server 400 with the payment server A 400a. Then, this determination information is held as shared information between each device (user terminal 100, settlement server A, 400a).
  • the data format of the payment data format identification flag 1 of A-pay is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • SHA-2 which is one of hash value calculation methods.
  • a salt value which is the first control information for generating secure information shown in the data column (4) of the table in FIG. is calculated and the calculated hash value is added.
  • the salt value insertion position is specified in the salt insertion position of the second control information for generating secure information shown in the data column (5) of the table in FIG.
  • the salt value is not included in the transmission data.
  • the data receiving side retains the same salt value, inserts this salt value into the received data, calculates the hash value, and determines whether the calculated hash value matches the hash value added to the received data. Verify the presence or absence of tampering. A specific processing example of this processing will be described later.
  • the user terminal 100 and the settlement server A 400a store the determined data format information as shared information in the storage unit.
  • FIG. 10 is a diagram explaining a specific example of pre-processing executed between the payment data processing device 300 and the payment server A, 400a.
  • the payment data processing device 300 uses A-pay
  • the payment data processing device 300 communicates with the payment server A 400a.
  • the data format of the data is determined, and this determination information is held as shared information between each device (payment data processing device 300, payment server A, 400a).
  • the data format of the payment data format identification flag 2 of A-pay is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • a salt value which is the first control information for generating secure information shown in the data column (4) of the table in FIG. is calculated and the calculated hash value is added.
  • the insertion position of the salt value is specified in the salt insertion position, which is the second control information for generating secure information shown in the data column (5) of the table in FIG.
  • the payment data processing device 300 and the payment server A 400a store the determined data format information as shared information in the storage unit.
  • FIG. 11 shows the data structure generated by the payment data processing device 300 and transmitted to the user terminal 100 .
  • the data generated by the payment data processing device 300 and transmitted to the user terminal 100 consists of the following data.
  • (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount (16) Payment data security information
  • the payment data processing device 300 generates payment data composed of these data, and transmits the generated data to the user terminal 100 brought close to the payment data processing device 300 using short-range communication.
  • a series of processing (steps S11 to S14) of data generation and data transmission processing executed by the payment data processing device 300 will be described with reference to FIGS. 12 to 15.
  • FIG. 12 to 15 A series of processing (steps S11 to S14) of data generation and data transmission processing executed by the payment data processing device 300 will be described with reference to FIGS. 12 to 15.
  • Step S11 First, the payment data processing device 300 generates payment data as shown in FIG. As shown in FIG. 12, the payment data consists of the following data. (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount
  • “(11) payment data format identification flag for payment data processing device” is a flag indicating the data format of the transmission/reception data described above with reference to FIG. 8 and the like. As described above, when the payment data processing device 300 uses A-pay, the payment data processing device 300 sends and receives payment data to and from the payment server A, 400a. Decide on a data format. “(11) payment data format identification flag for payment data processing device” is a flag indicating this data format, and is a flag for identifying the data format of transmission data.
  • the data format of the payment data format identification flag 2 of A-pay uses SHA-2, which is one of hash value calculation methods. It is a data format that uses a security method that This data format inserts a salt value, which is the first control information for generating secure information, shown in the data column (4) in the tables of FIGS. , is a data format in which a hash value is calculated and the calculated hash value is added.
  • the salt value insertion position is specified in the salt insertion position of the second control information for generating secure information shown in the data column (5) in the tables of FIGS. 8 and 10 .
  • the payment data processing device 300 when the payment data processing device 300 uses A-pay, the payment data processing device 300 communicates with the payment server A 400a between the payment data processing device 300 and the payment server.
  • the data format of payment data to be transmitted and received between 400 is determined, and this decision information is held as shared information between each device (payment data processing device 300, payment server A, 400a).
  • “(12) Merchant Code”, “(13) Store Code”, and “(14) Store Terminal (Registrar) Code” are the member stores of the store 20 where the payment data processing device 300 using A-pay is installed. They are an identification code, a store identification code, and a store terminal identification code. Note that the identification code of the payment data processing device 300 may be included in “(14) store terminal (register) code”. In a configuration in which one store terminal 200 is associated with one payment data processing device 300 , “(14) store terminal (register) code” can be used as the identification code of the payment data processing device 300 .
  • identification information are stored in the internal storage unit ( memory). Alternatively, it is stored in a storage unit (memory) inside the shop terminal 200 and transferred from the shop terminal 200 to the payment data processing device 300 .
  • Steps S12-S13 Next, in steps S12 and S13 shown in FIGS. 13 and 14, the payment data processing device 300 performs secure information generation processing for the payment data generated in step S11.
  • This secure information generation process is generated according to the security method corresponding to the data format corresponding to "(11) payment data format identification flag for payment data processing device" set in the transmission data.
  • the data format of the payment data format identification flag 2 is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • This data format inserts a salt value, which is the first control information for generating secure information, shown in the data column (4) in the tables of FIGS. , is a data format in which a hash value is calculated and the calculated hash value is added.
  • the salt value insertion position is specified in the salt insertion position of the second control information for generating secure information shown in the data column (5) in the tables of FIGS. 8 and 10 .
  • the payment data processing device 300 when the payment data processing device 300 uses A-pay, the payment data processing device 300 communicates with the payment server A 400a between the payment data processing device 300 and the payment server.
  • the data format of payment data to be transmitted and received between 400 is determined, and this decision information is held as shared information between each device (payment data processing device 300, payment server A, 400a). That is, the shared information shown in FIG. 13( a ) is information shared between the payment data processing device 300 and the payment server 400 .
  • step S13 the payment data processing device 300 executes hash value calculation processing for (b) payment data secure information generation data generated in step S12 shown in FIG. "(16) Payment data secure information (hash value)" is generated.
  • This hash value calculation process is executed according to the hash value calculation algorithm SHA-2.
  • step S14 payment data processing device 300 converts "(16) payment data secure information (hash value)" generated in step S13 shown in FIG. is added to the payment data generated in step 2, and data to be transmitted to the user terminal 100 is generated. This data is transmitted to the settlement server A 400a via the user terminal 100.
  • FIG. 15 payment data processing device 300 converts "(16) payment data secure information (hash value)" generated in step S13 shown in FIG. is added to the payment data generated in step 2, and data to be transmitted to the user terminal 100 is generated. This data is transmitted to the settlement server A 400a via the user terminal 100.
  • Payment server A 400a holds the salt value that payment data processing device 300 applied to hash value calculation as shared information with payment data processing device 300, and payment server A 400a stores the salt value is used to verify the hash value. This processing will be described later.
  • (1) at the bottom of FIG. 16 shows the data configuration that the user terminal 100 transmits to the settlement server A, 400a.
  • the data that the user terminal 100 transmits to the settlement server A 400a consists of the following data. (21) Settlement data format identification flag for user (22) User ID (23) User data secure information (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount (16) Payment data secure information
  • the user terminal 100 generates data composed of these data and transmits it to the settlement server A, 400a.
  • (11) payment data format identification flag for payment data processing device to (16) payment data secure information these data are data input from payment data processing device 300 to user terminal 100. .
  • the user terminal 100 inputs data from the payment data processing device 300 as follows: (21) Settlement data format identification flag for user (22) User ID (23) User data secure information
  • the above data (21 to 23) are added and transmitted to the settlement server A 400a.
  • a series of processing (steps S21 to S24) of data generation and data transmission processing executed by the user terminal 100 will be described with reference to FIGS. 17 to 20.
  • Step S21 First, the user terminal 100 generates user data as shown in FIG. As shown in FIG. 17, user data consists of the following data. (21) Settlement data format identification flag for user (22) User ID
  • “(21) user payment data format identification flag” is a flag indicating the data format of the transmission/reception data described above with reference to FIG. 8 and the like. As described above, when the user terminal 100 uses A-pay, the user terminal 100 determines the data format of payment data to be transmitted and received between the user terminal 100 and the payment server 400 with the payment server A 400a. “(21) User payment data format identification flag” is a flag indicating this data format, and is a flag for identifying the data format of transmission data.
  • the data format of the payment data format identification flag 1 of A-pay uses SHA-2, which is one of hash value calculation methods. It is a data format that uses a security method that This data format inserts a salt value, which is the first control information for generating secure information, shown in the data column (4) in the tables of FIGS. , is a data format in which a hash value is calculated and the calculated hash value is added.
  • the salt value insertion position is specified in the salt insertion position of the second control information for generating secure information shown in the data column (5) in the tables of FIGS. 8 and 9 .
  • the user terminal 100 when the user terminal 100 uses A-pay, the user terminal 100 communicates with the settlement server A 400a.
  • the data format of the data is determined, and this determination information is held as shared information between each device (user terminal 100, settlement server A, 400a).
  • “(22) User ID” is the identifier of the user 10 using the user terminal 100 using A-pay.
  • “(22) User ID” is stored, for example, in the internal storage unit (memory) of the user terminal 100, and when the user 10 performs user registration for A pay, the payment server A, 400a , and is data registered in the database (DB) of the settlement server A, 400a.
  • the user ID is registered in the DB in association with, for example, a user account (account for settlement, credit card information for settlement, debit card information for settlement, etc.).
  • Steps S22-S23 Next, in steps S22 and S23 shown in FIGS. 18 and 19, the user terminal 100 performs secure information generation processing for the user data generated in step S21.
  • This secure information generation process is generated according to the security method corresponding to the data format corresponding to "(21) user-supported payment data format identification flag" set in the transmission data.
  • the setting of “(21) User-supported payment data format identification flag” is 1.
  • the data format of the payment data format identification flag 1 is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • This data format inserts a salt value, which is the first control information for generating secure information, shown in the data column (4) in the tables of FIGS. , is a data format in which a hash value is calculated and the calculated hash value is added.
  • the salt value insertion position is specified in the salt insertion position of the second control information for generating secure information shown in the data column (5) in the tables of FIGS. 8 and 9 .
  • the user terminal 100 when the user terminal 100 uses A-pay, the user terminal 100 communicates with the settlement server A 400a.
  • the data format of the data is determined, and this determination information is held as shared information among the devices (user terminal 100, settlement server A, 400a). That is, the shared information shown in FIG. 18(a) is information shared between the user terminal 100 and the payment server 400.
  • FIG. 18(a) is information shared between the user terminal 100 and the payment server 400.
  • step S23 the user terminal 100 executes hash value calculation processing for the (b) user data secure information generation data generated in step S22 shown in FIG. Generate secure information (hash value).
  • This hash value calculation process is executed according to the hash value calculation algorithm SHA-2.
  • Step S24 the user terminal 100 adds the user data secure information calculated in step S23 to the user data generated in step S21, and further adds the payment data received from the payment data processing device 300.
  • data to be transmitted to settlement server A 400a is generated and transmitted to settlement server A 400a.
  • the data that the user terminal 100 transmits to the settlement server A 400a consists of the following data.
  • (21) Settlement data format identification flag for user (22) User ID (23) User data secure information
  • (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount (16) Payment data secure information
  • the user terminal 100 generates data composed of these data and transmits it to the settlement server A, 400a.
  • (11) payment data format identification flag for payment data processing device to (16) payment data secure information these data are data input from payment data processing device 300 to user terminal 100. .
  • the data sent to the settlement server A 400a does not include the salt value used for hash value calculation.
  • the settlement server A 400a holds the salt value that the user terminal 100 applied to calculate the hash value as shared information with the user terminal 100, and the settlement server A 400a uses the held salt value Perform hash value verification processing. This processing will be described later.
  • the user terminal 100 needs to hold a salt value, salt insertion position information, and the like for generating secure information.
  • a third party may use the information to impersonate the user and perform unauthorized processing.
  • the salt value, salt insertion position information, and the like are highly confidential information that must be prevented from being leaked to third parties.
  • FIGS. 21 to 25 a processing example of the second step of the payment processing in which the user terminal 100 does not need to hold the salt value, salt insertion position information, etc. will be described with reference to FIGS. 21 to 25. do.
  • the processing described with reference to FIGS. 21 to 25 is an example of processing of the second step of the settlement processing that can be executed in place of the processing described with reference to FIGS. 17 to 20.
  • FIG. 21 to 25 is an example of processing of the second step of the settlement processing that can be executed in place of the processing described with reference to FIGS. 17 to 20.
  • steps S25 to S29 A series of processes (steps S25 to S29) in this processing example will be described with reference to FIGS.
  • Step S25 First, as shown in FIG. 21, the user terminal 100 accesses the payment server A 400a and makes a user data acquisition request.
  • this user data acquisition request can be executed as a pre-processing before settlement processing. For example, it is executed in conjunction with (preprocessing 1) described above with reference to FIG. 9, or in conjunction with user registration processing.
  • the settlement server A 400a Upon receiving the user data acquisition request from the user terminal 100, the settlement server A 400a generates user data of the requester. If the user 10 has been registered as a user in advance, user information is acquired from the registered user database in the settlement server A 400a. If the user 10 is not registered as a user, user registration processing is first performed with respect to the database, and then user information is acquired from the database to generate user data as shown in FIG. This user data is the same as the data described with reference to FIG. 17, and is composed of the following data. (21) Settlement data format identification flag for user (22) User ID
  • “(21) user payment data format identification flag” is a flag indicating the data format of the transmission/reception data described above with reference to FIG. 8 and the like. As described above, when the user terminal 100 uses A-pay, the user terminal 100 determines the data format of payment data to be transmitted and received between the user terminal 100 and the payment server 400 with the payment server A 400a. “(21) User payment data format identification flag” is a flag indicating this data format, and is a flag for identifying the data format of transmission data.
  • the payment server A 400a can independently determine the payment data format.
  • Settlement server A 400a may perform a process of randomly selecting a data format using, for example, random numbers.
  • the data format of the payment data format identification flag 1 of A-pay uses SHA-2, which is one of hash value calculation methods. It is a data format that uses a security method that This data format inserts a salt value, which is the first control information for generating secure information, shown in the data column (4) in the tables of FIGS. , is a data format in which a hash value is calculated and the calculated hash value is added.
  • the salt value insertion position is specified in the salt insertion position of the second control information for generating secure information shown in the data column (5) in the tables of FIGS. 8 and 9 .
  • the user terminal 100 when the user terminal 100 uses A-pay, the user terminal 100 sends and receives data to and from the payment server A 400a.
  • the data format of the payment data to be used is determined, and this decision information is held as shared information between each device (user terminal 100, payment server A, 400a).
  • the data format of payment data to be transmitted and received between servers 400 is determined independently by payment server A 400a.
  • “(22) User ID” is the identifier of the user 10 using the user terminal 100 using A-pay.
  • “(22) User ID” is stored, for example, in the internal storage unit (memory) of the user terminal 100, and when the user 10 performs user registration for A pay, the payment server A, 400a , and is data registered in the database (DB) of the settlement server A, 400a.
  • the user ID is registered in the DB in association with, for example, a user account (account for settlement, credit card information for settlement, debit card information for settlement, etc.).
  • Steps S26-S27 Next, in steps S26 and S27 shown in FIGS. 22 and 23, the settlement server A 400a performs secure information generation processing for the user data generated in step S26.
  • This secure information generation process is generated according to the security method corresponding to the data format corresponding to "(21) user-supported payment data format identification flag" set in the transmission data.
  • the setting of “(21) User-supported payment data format identification flag” is 1.
  • the data format of the payment data format identification flag 1 is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • This data format inserts a salt value, which is the first control information for generating secure information, shown in the data column (4) in the tables of FIGS. , is a data format in which a hash value is calculated and the calculated hash value is added.
  • the salt value insertion position is specified in the salt insertion position of the second control information for generating secure information shown in the data column (5) in the tables of FIGS. 8 and 9 .
  • the data for generating user data secure information shown in FIG. 22(b) is generated.
  • the information held by the payment server in FIG. 22A is information stored in the storage unit of the payment server A 400a, and is not held by the user terminal 100. Therefore, a situation such as leakage from the user terminal 100 to the outside does not occur.
  • step S27 payment server A 400a executes hash value calculation processing for (b) user data secure information generation data generated in step S26 shown in FIG. Generate user data secure information (hash value).
  • This hash value calculation process is executed according to the hash value calculation algorithm SHA-2.
  • Step S28a-S28b Next, in step S28a shown in FIG. 24, payment server A 400a sends "secure information-added user data" obtained by adding the user data secure information calculated in step S27 to the user data generated in step S25. Send to
  • the user terminal 100 stores the "secure information added user data" received from the settlement server A 400a in the memory of the user terminal 100 in step S28b.
  • the user terminal 100 can obtain the "secure information-added user data" shown in FIG. (21) Settlement data format identification flag for user (22) User ID (23) User Data Secure Information It is possible to hold "secure information added user data" composed of these data in the memory. Confidential information such as salt values and salt insertion positions is not stored in the memory of the user terminal 100, and such information will not be leaked to a third party.
  • steps S25 to S28b up to this point is performed before the settlement processing at the store, for example, (preprocessing 1) described above with reference to FIG. 9, or in conjunction with the user registration processing.
  • steps S29 shown in FIG. 25 is performed during the settlement process.
  • Step S29 The process of step S29 shown in FIG. 25 is performed when the settlement process is executed.
  • the user terminal 100 executes the process shown in step S29 of FIG. 25 during the payment process. That is, the "secure information-added user data" received from the payment server A 400a and stored in the memory according to the processing of steps S25 to S28b described above is read from the memory, Settlement data ((11) to (16)) are added to generate data to be transmitted to settlement server A 400a, and the generated data is transmitted to settlement server A 400a.
  • the data that the user terminal 100 transmits to the settlement server A 400a consists of the following data.
  • (21) Settlement data format identification flag for user (22) User ID (23) User data secure information
  • (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount (16) Payment data secure information
  • the user terminal 100 generates data composed of these data and transmits it to the settlement server A, 400a.
  • (11) payment data format identification flag for payment data processing device to (16) payment data secure information these data are data input from payment data processing device 300 to user terminal 100. .
  • the data sent to the settlement server A 400a does not include the salt value used for hash value calculation.
  • the settlement server A 400a holds the salt value applied to the hash value calculation stored in the user terminal 100 as its own information. verification processing. This processing will be described later.
  • FIG. 26 shows data received from the user terminal 100 by the payment server A 400a.
  • data received by the settlement server A 400a from the user terminal 100 consists of the following data.
  • (21) Settlement data format identification flag for user (22) User ID (23) User data secure information
  • (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount (16) Payment data secure information
  • Payment server A 400a verifies the received data before executing payment processing.
  • a series of processes (steps S31 to S34) of the received data verification process executed by the settlement server A 400a will be described with reference to FIGS. 27 to 30.
  • FIG. 1 A series of processes (steps S31 to S34) of the received data verification process executed by the settlement server A 400a will be described with reference to FIGS. 27 to 30.
  • FIG. 1 A series of processes (steps S31 to S34) of the received data verification process executed by the settlement server A 400a will be described with reference to FIGS. 27 to 30.
  • Steps S31 and S32 are verification processes for data generated by the user terminal 100 included in the data received from the user terminal 100 (data (21) to (23) in the received data shown in FIG. 26).
  • Steps S33 and S34 are verification processes for the data generated by the payment data processing device 300 (data (11) to (16) in the received data shown in FIG. 26). Either of these data verification processes may be performed first, or they may be performed as parallel processes.
  • the settlement server A 400a verifies data generated by the user terminal 100 in the received data (data (21) to (23) in the received data shown in FIG. 26). First, the settlement server A 400a selects and acquires the following data from the data received from the user terminal 100 in step S31 shown in FIG. (21) Settlement data format identification flag for user (22) User ID
  • the settlement server A 400a checks the value of "(21) user-supported settlement data format identification flag".
  • the setting of “(21) User-supported payment data format identification flag” is 1.
  • the data format of the payment data format identification flag 1 is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • the user terminal 100 when the user terminal 100 uses A-pay, the user terminal 100 communicates with the settlement server A 400a.
  • the data format of the data is determined, and this determination information is held as shared information among the devices (user terminal 100, settlement server A, 400a). That is, the shared information shown in FIG. 27(a) is information shared between the user terminal 100 and the settlement server A, 400a.
  • Settlement server A 400a first inserts a salt value into the following data selectively acquired from the data received from user terminal 100 in step S31 shown in FIG. (21) Settlement data format identification flag for user (22) User ID
  • the user data verification data shown in FIG. 27(b) is generated.
  • step S32 the settlement server A 400a executes hash value calculation processing for the (b) user data verification data generated in step S31 shown in FIG. Generates user data secure information (hash value) that is a value.
  • This hash value calculation process is executed according to the hash value calculation algorithm SHA-2.
  • the settlement server A 400a compares the user data secure information (hash value), which is a calculated value for verification, with the user data secure information included in the data received from the user terminal 100, and determines whether or not they match. If they match, the user data included in the received data from the user terminal 100, that is, (21) Settlement data format identification flag for user (22) User ID It is determined that these data are valid data that have not been falsified. However, if they do not match, it is determined that the data has been falsified, and subsequent settlement processing is not executed. In this case, the settlement server A 400a sends an error message to the user terminal 100, for example.
  • the settlement server A 400a sends an error message to the user terminal 100, for example.
  • Steps S33-S34 In steps S33 and S34, payment server A 400a converts data generated by payment data processing device 300 (data (11) to (16) in the received data shown in FIG. 26) included in the data received from user terminal 100. Execute the verification process. First, the settlement server A 400a selects and acquires the following data from the data received from the user terminal 100 in step S33 shown in FIG. (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount
  • payment server A 400a checks the value of "(11) payment data format identification flag for payment data processing device".
  • the setting of “(11) Settlement data format identification flag for settlement data processing device” is 2.
  • the data format of the payment data format identification flag 2 is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • the payment data processing device 300 communicates with the payment server A 400a between the payment data processing device 300 and the payment server.
  • the data format of payment data to be transmitted and received between 400 is determined, and this decision information is held as shared information between each device (payment data processing device 300, payment server A, 400a). That is, the shared information shown in FIG. 29(a) is information shared between the payment data processing device 300 and the payment server A, 400a.
  • the payment data verification data shown in FIG. 29(b) is generated.
  • step S34 the payment server A 400a executes hash value calculation processing for the (b) payment data verification data generated in step S33 shown in FIG. Generate payment data secure information (hash value).
  • This hash value calculation process is executed according to the hash value calculation algorithm SHA-2.
  • the payment server A 400a compares the payment data secure information (hash value), which is a calculated value for verification, with the payment data secure information included in the data received from the user terminal 100, and determines whether or not they match. If they match, the payment data included in the data received from the user terminal 100, that is, (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount Determine that there is. However, if they do not match, it is determined that the data has been falsified, and subsequent settlement processing is not executed. In this case, the settlement server A 400a sends an error message to the user terminal 100, for example.
  • Verification processing for data (21) to (23)) and verification processing for payment data generated by the payment data processing device 300 are executed.
  • payment server A 400a next performs payment processing.
  • FIG. 31 shows settlement result data generated by settlement server A 400a and transmitted to user terminal 100 after settlement processing in settlement server A 400a.
  • the payment server A 400a generates this payment result data according to the result of the payment processing and transmits it to the user terminal 100.
  • FIG. 31 shows settlement result data generated by settlement server A 400a and transmitted to user terminal 100 after settlement processing in settlement server A 400a.
  • the payment server A 400a generates this payment result data according to the result of the payment processing and transmits it to the user terminal 100.
  • FIG. 32 A series of processes (steps S41 to S44) of the payment processing executed by the payment server A 400a and the payment result data generation and transmission processing will be described with reference to FIGS. 32 to 35.
  • FIG. 32 A series of processes (steps S41 to S44) of the payment processing executed by the payment server A 400a and the payment result data generation and transmission processing will be described with reference to FIGS. 32 to 35.
  • Step S41 First, the payment server A 400a executes payment processing based on data received from the user terminal.
  • the data received by the settlement server A 400a from the user terminal 100 is composed of the following data as described above. (21) Settlement data format identification flag for user (22) User ID (23) User data secure information (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount (16) Payment data secure information
  • Settlement server A 400a checks whether the user has an account registered as an A-pay user based on the user ID included in these data, and further checks the balance of the user account. Furthermore, it confirms whether the member store code, store code, store terminal (register) code, etc. have been registered as an A-pay user. When it is confirmed that both the user and the store are properly registered, settlement processing is performed to subtract the amount corresponding to the settlement amount from the user account.
  • settlement result data is generated in (step S41) shown in FIG.
  • the settlement result data is composed of the following data. (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information
  • “(41) Settlement transaction identifier” is an ID for each set of settlement transactions.
  • “(42) Settlement result” is result data indicating whether the settlement was successful or unsuccessful. If the balance is insufficient, a payment error will occur.
  • “(43) Balance information” is the balance of the user account after settlement processing.
  • settlement server A 400a executes the following processing in (step S42) shown in FIG.
  • the settlement server A 400a selects and acquires the following data from the data received from the user terminal 100. (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount
  • the settlement server A 400a sets up the configuration data of the settlement result data generated in (step S41) described with reference to FIG. (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information Data is generated by linking these settlement result data to the above settlement data.
  • Settlement server A 400a checks the value of "(11) Settlement data format identification flag for settlement data processing device".
  • the setting of “(11) Settlement data format identification flag for settlement data processing device” is 2.
  • the data format of the payment data format identification flag 2 is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • the payment data processing device 300 communicates with the payment server A 400a between the payment data processing device 300 and the payment server.
  • the data format of payment data to be transmitted and received between 400 is determined, and this decision information is held as shared information between each device (payment data processing device 300, payment server A, 400a). That is, the shared information shown in FIG. 33(a) is the information shared between the payment data processing device 300 and the payment server A, 400a.
  • the settlement result data secure information generating data shown in FIG. 33(b) is generated.
  • Step S43 Next, in (step S43) shown in FIG. 34, payment server A 400a executes hash value calculation processing for (b) payment result data secure information generation data generated in step S42 shown in FIG. (44) Settlement result data secure information (hash value) to generate This hash value calculation process is executed according to the hash value calculation algorithm SHA-2.
  • step S44 payment server A 400a converts "(44) payment result data secure information (hash value)" generated in step S43 shown in FIG.
  • Data to be transmitted to the user terminal 100 is generated by adding it to the settlement result data (data (41) to (43)) generated in S41.
  • the data transmitted to the user terminal 100 does not include the salt value used for hash value calculation.
  • the user terminal 100 receives, from the settlement server A 400a, transmission data generated by the settlement server A 400a described above with reference to FIG. (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information (44) Settlement Result Data Secure Information
  • the user terminal 100 uses these received data to output the display data of the settlement result as shown in FIG. 36, for example, to the display unit.
  • the user 10 can see this display and confirm that the payment has been made.
  • the user terminal 100 receives, from the settlement server A 400a, transmission data generated by the settlement server A 400a described above with reference to FIG. (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information (44) Settlement Result Data Secure Information
  • the user 10 brings the user terminal 100 close to the payment data processing device 300 to execute proximity communication, and transmits these received data to the payment data processing device 300 as they are.
  • FIG. 38 shows data received by the payment data processing device 300 from the payment server A 400a via the user terminal 100.
  • FIG. This is the settlement result data generated by the settlement server A 400a described above with reference to FIG. 35, that is, settlement result data consisting of the following data.
  • Payment data processing device 300 verifies the validity of this received data. Verification processing of the settlement result data will be described with reference to FIGS. 39 and 40. FIG.
  • Step S71 First, the payment data processing device 300 executes the following process in (step S71) shown in FIG.
  • the payment data processing device 300 receives payment result data from the payment server A 400a via the user terminal 100, that is, (41) Settlement transaction identifier (42) Settlement result (43) Balance information Acquire these settlement result data.
  • the data generated by the payment data processing device 300 at the start of payment that is, the payment data generated in the first step of the payment processing described with reference to FIG. 12 is acquired from the storage unit. That is, the following data are acquired.
  • (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount
  • the payment data processing device 300 stores these payment data (data (11) to (15)) and the payment result data (data (41) to (43) received from the payment server A 400a via the user terminal 100). ) are concatenated.
  • the payment data processing device 300 checks the value of "(11) payment data format identification flag for payment data processing device".
  • the setting of “(11) Settlement data format identification flag for settlement data processing device” is 2.
  • the data format of the payment data format identification flag 2 is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • the payment data processing device 300 communicates with the payment server A 400a between the payment data processing device 300 and the payment server.
  • the data format of payment data to be transmitted and received between 400 is determined, and this decision information is held as shared information between each device (payment data processing device 300, payment server A, 400a). That is, the shared information shown in FIG. 39(a) is information shared between the payment data processing device 300 and the payment server A, 400a.
  • the payment data processing device 300 inserts a salt value into the data in which the payment result data is linked to the payment data, as shown in FIG.
  • the settlement result data verification data shown in FIG. 39(b) is generated.
  • Step S72 Next, in (step S72) shown in FIG. 40, the payment data processing device 300 executes hash value calculation processing for the (b) payment result data verification data generated in step S71 shown in FIG. User data secure information (hash value), which is a calculated value, is generated. This hash value calculation process is executed according to the hash value calculation algorithm SHA-2.
  • the payment data processing device 300 compares the payment result data secure information (hash value), which is a calculated value for verification, with the payment result data secure information included in the data received from the payment server A 400a via the user terminal 100. It is determined whether or not the If they match, the payment result data received from the payment server A 400a via the user terminal 100, that is, (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information It is determined that these data are valid data that have not been falsified. However, if they do not match, it is determined that the data has been falsified. In this case, there is a possibility that some kind of data manipulation has been performed on the user terminal 100, and that fact is output to the shop terminal 200 to output an alarm or the like. If they match, proceed to the next step.
  • the payment result data secure information (hash value)
  • FIG. 41 is an example of a case where the payment processing is correctly executed in the payment server A, 400a. That is, this is an example of a case where the settlement amount is deducted from the user's account in the settlement server A 400a and the settlement process is successful.
  • payment result data received from the payment server A 400a via the user terminal 100 that is, (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information Settlement completion data is recorded as "(43) Settlement Result" in the received data.
  • the payment data processing device 300 Based on this payment completion data, the payment data processing device 300 notifies the shop terminal 200 that the payment has been successfully completed.
  • the store terminal 200 displays a settlement processing completion message as shown in FIG. 41, for example, on the display unit based on this notification data.
  • the payment data processing device 300 Based on this payment error data, the payment data processing device 300 notifies the shop terminal 200 that the payment has not been executed.
  • the store terminal 200 displays a settlement processing error message as shown in FIG. 42 on the display unit based on this notification data.
  • the data format conforming to a specific security method is determined between the devices in advance for the data transmitted and received between the devices, and each device uses the data format determined in advance.
  • Generate and transmit data that has undergone security assurance processing according to A device that has received data from another device performs data verification processing according to the security method according to the predetermined data format.
  • a salt value is inserted into the data transmitted and received, and a hash value is calculated using the SHA-2 algorithm. This is an example of processing in which a calculated hash value is added as secure information to transmission/reception data.
  • the security method applicable in the processing of the present disclosure is not limited to hash value calculation processing using this SHA-2 algorithm.
  • the data string to be prevented is encrypted using the encryption key A, which is the first control information for generating secure information shown in (4) of FIG. 8, and the encrypted data is transmitted.
  • the data receiving side holds a decryption key, and decrypts the received data using the decryption key.
  • FIG. 43 is a diagram showing an example of payment data encryption processing executed in the payment data processing device 300. As shown in FIG. 43
  • the payment data processing device 300 first generates payment data in (step S101).
  • Payment data consists of the following data. (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount
  • “(11) payment data format identification flag for payment data processing device” is a flag indicating the data format of the transmission/reception data described above with reference to FIG. 8 and the like.
  • the data portion excluding "(11) Payment data format identification flag for payment data processing device", that is, (12) Merchant Code (13) Store Code (14) Store Terminal (Registrar) Code (15) Settlement Amount
  • "(11) Settlement data format identification flag for settlement data processing device” is transmitted as unencrypted plaintext data. This is a process for enabling the receiving side to confirm the set value of "(11) payment data format identification flag for payment data processing device". On the receiving side, the set value of "(11) Settlement data format identification flag for payment data processing device" is confirmed to be 3, and it is determined that the received data has been subjected to AES encryption processing. Decryption processing is performed and subsequent processing is performed using the decrypted data.
  • FIG. 44 is a diagram showing an example of user data encryption processing executed in the user terminal 100.
  • the user terminal 100 first generates user data in (step S111).
  • User data consists of the following data. (21) Settlement data format identification flag for user (22) User ID
  • “(21) user payment data format identification flag” is a flag indicating the data format of the transmission/reception data described above with reference to FIG. 8 and the like.
  • the data portion excluding "(21) user-supported payment data format identification flag", that is, (22) User ID This data is encrypted and transmitted.
  • FIG. 44 has been described as a processing example in which the user terminal 100 generates user data and executes encryption processing, these processing may be executed by the payment processing server 400.
  • settlement server A 400a first generates user data in (step S116).
  • User data consists of the following data. (21) Settlement data format identification flag for user (22) User ID
  • step S117 payment server A 400a determines the data portion excluding "(21) user-supported payment data format identification flag", that is, (22) User ID This data is encrypted and transmitted to the user terminal 100 .
  • the user terminal 100 stores this data in memory. By performing these processes, the user terminal 100 does not need to hold the encryption key, and the possibility of leakage of the encryption key can be reduced.
  • FIG. 46 is a diagram showing an example of encryption processing of settlement result data executed in settlement server A 400a.
  • Settlement server A 400a first generates concatenated data of settlement result data and settlement data in step S121.
  • Consolidated data consists of the following data. (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount (41) Payment transaction identifier (42) Payment result ( 43) Balance information
  • ((11) payment data format identification flag for payment data processing device” is a flag indicating the data format of the transmission/reception data described above with reference to FIG. 8 and the like.
  • "(11) Settlement data format identification flag for settlement data processing device” is transmitted as unencrypted plaintext data. This is a process for enabling the receiving side to confirm the set value of "(11) payment data format identification flag for payment data processing device". On the receiving side, the set value of "(11) Settlement data format identification flag for payment data processing device" is confirmed to be 3, and it is determined that the received data has been subjected to AES encryption processing. Decryption processing is performed and subsequent processing is performed using the decrypted data.
  • the signature data is generated using the RSA private key, which is the first control information for generating secure information, and the generated signature data is added to the data string to be tamper-prevented for transmission.
  • the data receiving side has the same RSA private key for signature, applies the same RSA private key for signature to the received data to generate signature data, and adds it to the generated signature data and the received data.
  • the presence or absence of data falsification is verified by checking whether the signature data match.
  • the RSA public key is placed in the payment data processing device 300, and for signature verification, the secure information transmitted from the payment server A 400a, that is, the value obtained by decrypting the signature value, and the tamper-proof object acquired by the payment data processing device 300 It is also possible to compare hash values of different data strings and determine that the signature verification is successful, that is, that the transmitted data has not been tampered with, based on the match.
  • FIG. 47 is a diagram showing an example of signature data generation processing for payment data executed in the payment data processing device 300.
  • FIG. 47 is a diagram showing an example of signature data generation processing for payment data executed in the payment data processing device 300.
  • the payment data processing device 300 first generates payment data in (step S151).
  • Payment data consists of the following data. (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount
  • “(11) payment data format identification flag for payment data processing device” is a flag indicating the data format of the transmission/reception data described above with reference to FIG. 8 and the like.
  • the configuration data of the payment data that is, (11) Payment data format identification flag for payment data processing device (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount Execute RSA signature calculation processing based on these data. Then, add the generated signature as secure information and send it.
  • the set value of "(11) Settlement data format identification flag for payment data processing device" is confirmed to be 4, it is determined that the received data is data to which an RSA signature is added, and signature verification processing is performed. Execute to verify whether or not data has been tampered with, and execute subsequent processing when it is confirmed that there has been no tampering.
  • FIG. 48 is a diagram showing an example of signature data generation processing for user data executed in the user terminal 100.
  • the user terminal 100 first generates user data in (step S161).
  • User data consists of the following data. (21) Settlement data format identification flag for user (22) User ID
  • “(21) user payment data format identification flag” is a flag indicating the data format of the transmission/reception data described above with reference to FIG. 8 and the like.
  • user data that is, (21) user-supported payment data format identification flag; (22) User ID RSA signature calculation processing is performed on these data, and the generated signature is added as secure information and transmitted.
  • FIG. 48 has been described as a processing example in which the user terminal 100 generates user data and executes signature processing, these processing may be executed by the payment processing server 400.
  • settlement server A 400a first generates user data in (step S166).
  • User data consists of the following data. (21) Settlement data format identification flag for user (22) User ID
  • settlement server A 400a uses user data, that is, (21) user-supported payment data format identification flag; (22) User ID RSA signature calculation processing is performed on these data, the generated signature is added as secure information, and the resulting data is transmitted to the user terminal 100 .
  • the user terminal 100 stores this data in memory. By performing these processes, the user terminal 100 does not need to hold the signature key, and the possibility of the signature key being leaked can be reduced.
  • FIG. 50 is a diagram showing an example of signature data generation processing for settlement result data executed in settlement server A 400a.
  • Settlement server A 400a first generates concatenated data of settlement result data and settlement data in step S171.
  • Consolidated data consists of the following data. (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount (41) Payment transaction identifier (42) Payment result ( 43) Balance information
  • ((11) payment data format identification flag for payment data processing device” is a flag indicating the data format of the transmission/reception data described above with reference to FIG. 8 and the like.
  • the set value of "(11) Settlement data format identification flag for payment data processing device" is confirmed to be 4, it is determined that the received data is data to which an RSA signature is added, and signature verification processing is performed. Execute to verify whether or not data has been tampered with, and execute subsequent processing when it is confirmed that there has been no tampering.
  • a configuration may be adopted in which a plurality of data formats are selected and changed at any time. It is possible to determine which format is selected in the actual transmission/reception data based on the set value of the payment data format identification flag set in the received data. Verification processing and decryption processing of received data can be performed based on.
  • a processing sequence executed in the information processing system of the present disclosure will be described with reference to the sequence diagrams of FIG. 53 and subsequent figures. From the left, in the sequence diagrams in FIG. user terminal 100, payment data processing device 300, store terminal 200, payment server 400, These are shown. Hereinafter, the processing from step S301 onward shown in FIG. 53 will be sequentially described.
  • Steps S301 and S302 are the pre-processing described above with reference to FIGS. 9 and 10.
  • the user 10 performs usage registration in advance with the payment server 400 that executes payment processing for the cashless payment method that the user 10 wants to use.
  • the user terminal 100 is used to communicate with a payment server that manages cashless payment or a management server, and register a user ID, a user terminal ID, other necessary information, and the like for usage registration.
  • the store 20 is the same, and the cashless payment method that you want to use is registered in advance.
  • a communication terminal (not shown) of the store 20 is used to communicate with a settlement server or a management server that manages cashless settlement, store information such as store ID and store name, and settlement data processing device 300 shown in the figure.
  • User registration is performed by registering the ID and other necessary information.
  • Step S301a First, in step S301a, the user terminal 100 communicates with the settlement server 400, determines the data format of settlement data to be transmitted and received between the user terminal 100 and the settlement server 400, and shares the determined data format information among the devices. do.
  • the data format identified by The data format of the payment data format identification flag 1 of A-pay (A-pay) is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • Step S301b is a process in which the payment server 400 generates "secure information-added user data" in advance and transmits it to the user terminal 100, and the user terminal 100 stores this data in the memory. This process corresponds to the process previously described with reference to FIGS. When performing this process, since there is no need to store secret information such as salt values and salt insertion position information in the user terminal 100, the possibility of these data being leaked can be reduced, and safety can be improved.
  • Step S302 The process of step S302 is a process of determining the data format of payment data to be transmitted and received between the payment data processing device 300 and the payment server 400 and sharing the determined data format information between the devices.
  • the payment data processing device 300 may or may not be configured to directly communicate with the payment server 400.
  • the clerk of the store uses a terminal such as a smartphone to mediate communication and perform the processing of step S302.
  • the data format of the payment data format identification flag 2 of A-pay is a data format using a security method using SHA-2, which is one of hash value calculation methods.
  • the payment data processing device 300 is generated in which the data format information of the payment data to be transmitted and received between the payment data processing device 300 and the payment server 400 is stored in advance in the storage unit, and the payment data processing device 300 is stored in the cache for payment processing by the payment server A 400a.
  • a configuration may be adopted in which an administrator of the payment system performs processing provided to the store 20 . In this case, the process of step S302 can be omitted.
  • step S301 and S302 shown in FIG. 53 When the pre-processing of steps S301 and S302 shown in FIG. 53 is completed, the actual settlement process of step S321 and subsequent steps shown in FIG. 54 can be executed.
  • Step S321 is started when the user 10 goes shopping or eats and drinks at the store 20 and requests payment at the register for payment.
  • the store clerk of the store 20 inputs payment data for shopping and eating and drinking of the user 10 to the store terminal 200 in step S321. Enter the payment amount. This input data is transferred to the payment data processing device 300 in step S322.
  • Step S323 The payment data processing device 300, having input the payment amount and the like from the shop terminal 200, generates payment data in step S323.
  • the payment data processing device 300 generates payment data composed of the following data. (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount
  • (11) payment data format identification flag for payment data processing device is a flag indicating the data format of the transmission/reception data previously described with reference to FIG. A flag indicating the data format of transmission/reception data shared between the device 300 and the settlement server 400 .
  • Step S324 payment data processing device 300 adds payment data secure information to the generated payment data in step S324.
  • FIG. 13 The secure information is generated according to the security method corresponding to the data format corresponding to the "(11) settlement data format identification flag compatible with the settlement data processing device" set in the transmission data.
  • Step S325) the payment data processing device 300 transmits the payment data to which the secure information is added to the user terminal 100 in step S325.
  • close proximity communication is performed with the user terminal 100 brought close to the payment data processing device 300, and payment data to which secure information is added is transmitted to the user terminal 100.
  • Step S331 User terminal 100, which has received payment data with secure information added from payment data processing device 300, reads out from memory "secure information added user data" in which user data secure information is added to user data in step S331.
  • This "secure information-added user data” is data generated by settlement server 400, received from settlement server 400, and stored in the memory of user terminal 100 in step S301b described above with reference to FIG. , consisting of the following data: (21) Settlement data format identification flag for user (22) User ID (23) User data security information
  • This data is data that is generated by the payment server 400 according to the process described above with reference to FIGS. 21 to 25, received from the payment server 400, and stored in the memory of the user terminal 100. As described above, by performing the processing described with reference to FIGS. 21 to 25, confidential information such as salt values and salt insertion position information is not stored in the user terminal 100, and these data are leaked. Possibilities are reduced and safety can be increased.
  • Step S332 Next, in step S332, the user terminal 100 transmits the concatenated data of the user data to which the secure information is added and the payment data to which the secure information is added to the payment server 400.
  • Step S341 The payment server 400 receives from the user terminal 100 the user data to which the secure information is added and the concatenated data of the payment data to which the secure information is added, and executes verification processing of the user data included in the received data in step S341.
  • step S341a the settlement server 400 confirms the value of "(21) user settlement data format identification flag" included in the received data, and determines the user data verification method based on the value of the flag.
  • step S341b data verification of user data is performed according to the data verification method determined based on the flag in step S341a.
  • step S341c a process of transmitting an error message to the user terminal 100 may be performed as in step S341c shown in FIG. If the verification is successful, the process of the next step S342 is executed.
  • Step S342 the payment server 400 verifies the payment data included in the received data.
  • step S342a the payment server 400 checks the value of "(11) payment data format identification flag for payment data processing device" included in the received data, and selects a payment data verification method based on the value of the flag. decide.
  • step S342b the payment data is verified according to the data verification method determined based on the flag in step S342a.
  • step S342c a process of transmitting an error message to the user terminal 100 may be performed as in step S342c shown in FIG. If the verification is successful, the process of the next step S343 is executed.
  • Step S343 the settlement server 400 executes settlement processing and further generates settlement result data indicating the result of the settlement processing.
  • the payment server 400 generates payment data including the following data in step S343. (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information
  • “(41) Settlement transaction identifier” is an ID for each set of settlement transactions.
  • “(42) Settlement result” is result data indicating whether the settlement was successful or unsuccessful. If the balance is insufficient, a payment error will occur.
  • “(43) Balance information” is the balance of the user account after settlement processing.
  • step S344 payment server 400 generates data for generating payment result data secure information.
  • the settlement server 400 selects and acquires the following data from the data received from the user terminal 100 .
  • Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount
  • the payment server 400 stores the configuration data of the payment result data generated in step S343, that is, (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information Data is generated by linking these settlement result data to the above settlement data.
  • step S345 the payment server 400 adds secure information to the payment result data secure information generation data generated in step S344.
  • the secure information is generated according to the value of "(11) payment data format identification flag for payment data processing device". For example, as described with reference to FIGS. 33 and 34, the concatenated data of the payment data and the payment result data is salted according to the value of "(11) Payment data format identification flag for payment data processing device". is calculated based on the inserted data, and the calculated hash value is used as secure information.
  • data for transmission to the user terminal 100 is generated by adding secure information to the settlement result data.
  • the transmission data consists of the following data. (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information (44) Settlement Result Data Secure Information
  • Step S345 payment server 400 receives the data generated in step S344, that is, (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information (44) Settlement Result Data Secure Information Settlement result data to which set of settlement result secure information is added is transmitted to the user terminal 100.
  • Step S351 The user terminal 100 that receives the payment result data to which the payment result secure information is added from the payment server 400 outputs the payment result to the user terminal 100 based on the received data in step S351.
  • This process corresponds to the process previously described with reference to FIG.
  • the user terminal 100 transfers this received data to the payment data processing device 300, and the result decrypted by the payment data processing device 300 is It is transferred to the user terminal, and settlement result information based on this decoded data is output to the user terminal 100 .
  • Step S352 the user terminal 100 brings the user terminal 100 closer to the payment data processing device 300 to perform proximity communication between the devices, and transfers the data received from the payment server 400 to the payment data processing device 300. .
  • Step S361 The payment data processing device 300, which has received the transmission data of the payment server 400 via the user terminal 100, verifies the received payment result data in step S361.
  • This process is a process corresponding to the process previously described with reference to FIGS.
  • the payment data processing device 300 first generates (b) payment result data verification data in accordance with FIG. 39(a) shared information described with reference to FIG.
  • the payment data processing device 300 receives payment result data from the payment server 400 via the user terminal 100, that is, (41) Settlement transaction identifier (42) Settlement result (43) Balance information Acquire these settlement result data. Further, the data generated by the payment data processing device 300 at the start of payment, ie, the payment data generated in step S323, is acquired from the storage unit. That is, the following data are acquired. (11) Payment data format identification flag for payment data processor (12) Merchant code (13) Store code (14) Store terminal (register) code (15) Payment amount
  • the payment data processing device 300 converts these payment data (data (11) to (15)) and payment result data (data (41) to (43)) received from the payment server 400 via the user terminal 100 into Generate concatenated data.
  • security information generation processing corresponding to the value of "(11) Settlement data format identification flag for settlement data processing device" is performed on this concatenated data.
  • the verification value of secure information is calculated based on a security method using SHA-2, which is one of hash value calculation methods, and verification processing is performed to compare the calculated value with the secure information contained in the received data. do.
  • the payment result data received from the payment server 400 via the user terminal 100 that is, (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information It is determined that these data are valid data that have not been falsified. If they do not match, it is determined that the data has been falsified.
  • Step S362 The payment data processing device 300 transmits the verification result information of the payment result data executed in step S361 to the shop terminal 200 in step S362.
  • Step S371 is an example of the case where the settlement server 400 correctly executes the settlement process. In other words, this is an example of a case where the payment amount is deducted from the user's account in the payment server 400 and the payment processing is successful.
  • payment result data received from the payment server 400 via the user terminal 100 that is, (41) Settlement Transaction Identifier (42) Settlement Result (43) Balance Information Settlement completion data is recorded as "(43) Settlement Result" in the received data.
  • the payment data processing device 300 Based on this payment completion data, the payment data processing device 300 notifies the shop terminal 200 that the payment has been successfully completed.
  • the store terminal 200 displays a settlement processing completion message as shown in FIG. 61, for example, on the display unit based on this notification data.
  • Step S372 is an example of processing when settlement processing is not correctly executed in settlement server 400 .
  • a message such as that shown in FIG. 62, that is, a message indicating that the settlement process has not been executed is displayed.
  • the payment data processing device 300 Based on this payment error data, the payment data processing device 300 notifies the shop terminal 200 that the payment has not been executed.
  • the store terminal 200 displays a settlement processing error message as shown in FIG. 62, for example, on the display unit based on this notification data.
  • the data format conforming to a specific security method is determined between the devices in advance for the data transmitted and received between the devices, and each device uses the data format determined in advance.
  • Generate and transmit data that has undergone security assurance processing according to A device that has received data from another device performs data verification processing according to the security method according to the predetermined data format.
  • the user terminal 100 is, for example, a smartphone (smartphone), and has the configuration shown in FIG. 63, for example.
  • the user terminal 100 includes a control unit (data processing unit) 101, an operation unit 102, a display unit 103, a secure element 104, a storage unit (memory) 105, a clock 106, a first communication unit 110, a 2 communication unit 120 .
  • the first communication unit 110 includes a Wi-Fi communication unit 111 and other communication units 112.
  • the second communication unit 120 includes an NFC-CLF 121 , a Bluetooth (registered trademark) communication unit 122 and other communication unit 123 .
  • a control unit (data processing unit) 101 controls processing executed in the user terminal 100 . Specifically, it executes data write processing and data read processing control for the payment data processing device 300, communication control with the payment server 400, and the like. Note that control programs, applications, and the like executed by the control unit (data processing unit) 101 are stored in a storage unit (memory) 105 .
  • a control unit (data processing unit) 101 has a processor such as a CPU having a program execution function.
  • the operation unit 102 is an operation unit that can be operated by the user, and includes various switches, a touch panel on the display unit 103, and the like. A user can input various information via the operation unit 102 .
  • the display unit 103 is a display unit such as a liquid crystal display, for example, and is used to display execution information of various applications.
  • the secure element 104 is an IC chip configured as an element having a secure memory and memory control section.
  • the secure memory in the secure element 104 stores a cashless payment function providing application and the like.
  • a storage unit (memory) 105 records control programs executed by the control unit 101, applications, ID information, user account information, and the like. In addition, shared information with the settlement server 400, that is, data format specification information for transmission/reception data, etc., is also recorded.
  • a clock 106 is clock information and outputs clock information to each processing unit.
  • the first communication unit 110 includes a Wi-Fi communication unit 111 and other communication unit 112, and is used for communication with external devices such as servers, PCs, smartphones, wearable devices, and the like.
  • Other communication unit 112 is a communication unit having a long-distance communication function such as a telephone line and the Internet.
  • the second communication unit 120 includes an NFC-CLF 121, a Bluetooth (registered trademark) communication unit 122, and another communication unit 123, and performs communication processing with the payment processing device 300, for example.
  • the other communication unit 123 is a communication unit such as an RF communication unit that performs short-range wireless communication.
  • the NFC-CLF 121 is NFC (Near Field Communication)-CLF (Contactless Front End) and is a type of IC chip for near field communication.
  • FIG. 64 is a block diagram showing a configuration example of the shop terminal 200 and the payment data processing device 300. As shown in FIG.
  • the store terminal 200 and the payment data processing device 300 may be configured separately, or may be integrated.
  • the configuration example shown in FIG. 64 is an example in which the store terminal 200 and the payment data processing device 300 are individually configured.
  • the store terminal 200 has a control section (data processing section) 201 , a payment data processing device IF (data input/output section) 202 , an input section (operation section) 203 , an output section 204 and a storage section (memory) 205 .
  • the payment data processing device 300 has a control section (data processing section) 301 , a shop terminal IF (data input/output section) 302 , a storage section (memory) 303 and a short-range wireless communication section 304 .
  • a control unit (data processing unit) 201 performs overall control of processing executed in the store terminal 200 .
  • a control unit (data processing unit) 201 has a processor such as a CPU having a program execution function.
  • the payment data processing device IF (data input/output unit) 202 is an interface for outputting recorded data to the payment data processing device 300 and reading data from the payment data processing device 300 .
  • An input unit (operation unit) 203 is an input unit for a user.
  • the output unit 204 is composed of, for example, a display unit, a voice output unit, and the like, and displays the settlement amount and outputs various messages, warnings, and the like.
  • a storage unit (memory) 205 records programs to be executed in the control unit (data processing unit) 201, parameters applied to program execution, and the like. Furthermore, it is also used as an information recording area for member store code, store code, store terminal code, other store terminal information, settlement amount, and the like.
  • a control unit (data processing unit) 301 performs overall control of processing executed in the payment data processing device 300 .
  • a control unit (data processing unit) 301 has a processor such as a CPU having a program execution function.
  • a store terminal IF (data input/output unit) 302 is used for output processing to the store terminal 200 of data received by the payment data processing device 300 from the user terminal and analysis results of the received data, and for input processing of data input from the store terminal 200. interface.
  • a storage unit (memory) 303 records programs to be executed in the control unit (data processing unit) 301, parameters applied to program execution, and the like. Furthermore, it is also used as an information recording area for the ID of the payment data processing device 300, the member store code, the store code, the store terminal code, other store terminal information, and the settlement amount. In addition, shared information with the settlement server 400, that is, data format specification information for transmission/reception data, etc., is also recorded.
  • the short-range wireless communication unit 304 is a communication unit that performs short-range wireless communication with the user terminal 100, for example.
  • it is composed of an NFC communication unit, a Bluetooth (registered trademark) communication unit, and other RF communication units.
  • FIG. 65 is a diagram showing an example of a hardware configuration that can be used as the user terminal 100, the store terminal 200, the payment data processing device 300, and the payment server 400. As shown in FIG.
  • a CPU (Central Processing Unit) 501 functions as a control unit and a data processing unit that execute various processes according to programs stored in a ROM (Read Only Memory) 502 or a storage unit 508 . For example, the process according to the sequence described in the above embodiment is executed.
  • a RAM (Random Access Memory) 503 stores programs and data executed by the CPU 501 .
  • These CPU 501 , ROM 502 and RAM 503 are interconnected by a bus 504 .
  • the CPU 501 is connected to an input/output interface 505 via a bus 504.
  • the input/output interface 505 is connected to an input section 506 including various switches, a keyboard, a mouse, a microphone, etc., and an output section 507 including a display, a speaker, and the like.
  • the CPU 501 executes various types of processing in response to commands input from the input unit 506 and outputs processing results to the output unit 507, for example.
  • a storage unit 508 connected to the input/output interface 505 consists of, for example, a flash memory, a hard disk, etc., and stores programs executed by the CPU 501 and various data.
  • the necessary configuration of the communication unit 509 differs between the user terminal 100, the store terminal 200, the payment data processing device 300, and the payment server 400, respectively.
  • the user terminal 100 has a communication unit capable of both short-range wireless communication and long-distance communication.
  • the payment data processing device 300 has a short-range wireless communication configuration with the user terminal 100 and a configuration capable of communicating with the store terminal 200 .
  • the settlement server 400 does not need a short-distance wireless communication function, so long as it is capable of long-distance communication.
  • the store terminal 200 may be configured to be able to write data to and read data from the payment data processing device 300 .
  • a drive 510 connected to the input/output interface 505 drives a removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory such as a memory card to record or read data.
  • a removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory such as a memory card to record or read data.
  • the removable media 511 and the drive 510 not all of the user terminal 100, the store terminal 200, the payment data processing device 300, and the payment server 400 have the removable media 511 and the drive 510 as essential components.
  • the technique disclosed in this specification can take the following configurations.
  • a data processing unit that generates payment data; Having a communication unit that transmits the payment data, The data processing unit generating payment data that has undergone security ensuring processing according to a security ensuring algorithm determined in advance with a payment server that executes payment processing according to the payment data; Further, an information processing device for generating payment data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the payment data is added.
  • the security algorithm is A secure information generation algorithm for inserting a salt, which is a data string defined in advance, into the payment data, calculating a hash value, and adding the calculated hash value to the payment data as secure information,
  • the data processing unit The information processing apparatus according to (1), which generates payment data to which secure information generated according to the secure information generating algorithm is added.
  • the security ensuring algorithm includes: A secure information generation algorithm for calculating signature data for the payment data and adding the calculated signature data as secure information to the payment data,
  • the data processing unit The information processing apparatus according to any one of (1) to (3), which generates payment data to which secure information generated according to the secure information generating algorithm is added.
  • the information processing device A device connected to or integrated with a store terminal for inputting payment amounts, The data processing unit generating payment data including the payment amount entered into the store terminal; The information processing device according to any one of (1) to (5), wherein the communication unit transmits the payment data to the user terminal by proximity communication.
  • the payment data is The information processing device according to (6), which is data to be transmitted to the settlement server via the user terminal.
  • the data processing unit A configuration for inputting payment result data generated by the payment server and executing data verification processing for the input payment result data,
  • the information processing apparatus according to any one of (1) to (7), wherein data verification processing is performed by applying a data verification algorithm corresponding to the security ensuring algorithm determined in advance with the settlement server.
  • the data verification algorithm includes: An algorithm that calculates a hash value by inserting a salt, which is a data string defined in advance, into the payment result data, and executes matching processing between the calculated hash value and the hash value added to the payment result data ( The information processing device according to 8).
  • the data processing unit A configuration in which user data is added to payment data received from the store-side terminal to generate transmission data to the payment server, The data processing unit generating user data subjected to security ensuring processing according to a security ensuring algorithm predetermined with the payment server; Further, an information processing apparatus for generating transmission data added with a data format identification flag indicating a data format corresponding to a security ensuring algorithm applied to the user data.
  • the security ensuring algorithm includes: A secure information generation algorithm that inserts a salt, which is a data string defined in advance, into the user data, calculates a hash value, and adds the calculated hash value to the payment data as secure information,
  • the data processing unit The information processing apparatus according to (11), which generates user data to which secure information generated according to the secure information generating algorithm is added.
  • An information processing system having a payment data processing device connected to or integrated with a store terminal for inputting a payment amount, a user terminal, and a payment server,
  • the payment data processing device generating payment data subjected to security ensuring processing according to a security ensuring algorithm predetermined with the payment server; generating payment data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the payment data is added, and transmitting the payment data to the user terminal;
  • the user terminal is A memory of flag-added user data obtained by adding a data format identification flag indicating a data format corresponding to a security ensuring algorithm applied to said user data to user data subjected to security ensuring processing according to a security ensuring algorithm determined by said settlement server.
  • the payment server a configuration for executing data verification processing for each of the payment data and the user data;
  • the verification processing of the payment data includes: Execute data verification processing by applying a data verification algorithm corresponding to the security ensuring algorithm determined in advance with the payment data processing device;
  • the user data verification process includes: An information processing system that executes data verification processing by applying a data verification algorithm corresponding to the security ensuring algorithm determined in advance with the user terminal.
  • the data verification algorithm executed by the payment server is A hash value is calculated by inserting a salt, which is a predetermined data string, into the payment data or the user data, and the calculated hash value is compared with the hash value added to the payment data or the user data.
  • An information processing method executed in an information processing device has a data processing unit that generates payment data and a communication unit that transmits the payment data, The data processing unit generating payment data that has undergone security ensuring processing according to a security ensuring algorithm determined in advance with a payment server that executes payment processing according to the payment data; Further, an information processing method for generating payment data to which a data format identification flag indicating a data format corresponding to a security ensuring algorithm applied to the payment data is added.
  • An information processing method executed in an information processing device has a communication unit that executes communication between the store-side terminal and the payment server, and a data processing unit, The data processing unit executing a transmission data generation step of adding user data to the payment data received from the store terminal to generate transmission data to the payment server;
  • the transmission data generation step includes: generating user data subjected to security ensuring processing according to a security ensuring algorithm predetermined with the payment server;
  • the information processing method is a step of generating transmission data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the user data is added.
  • the payment data processing device generating payment data subjected to security ensuring processing according to a security ensuring algorithm predetermined with the payment server; generating payment data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the payment data is added, and transmitting the payment data to the user terminal;
  • the user terminal A memory of flag-added user data obtained by adding a data format identification flag indicating a data format corresponding to a security ensuring algorithm applied to said user data to user data subjected to security ensuring processing according to a security ensuring algorithm determined by said settlement server.
  • the payment server executing the payment data verification process by applying a data verification algorithm corresponding to the security ensuring algorithm predetermined with the payment data processing device;
  • a program for executing information processing in an information processing device has a data processing unit that generates payment data and a communication unit that transmits the payment data,
  • the program causes the data processing unit to: a process of generating payment data that has undergone security ensuring processing according to a security ensuring algorithm determined in advance with a payment server that executes payment processing according to the payment data;
  • a program for executing information processing in an information processing device has a communication unit that executes communication between the store-side terminal and the payment server, and a data processing unit, The program causes the data processing unit to: executing a transmission data generation step of adding user data to the payment data received from the store-side terminal to generate transmission data to the payment server; In the transmission data generating step, a process of generating user data that has undergone security ensuring processing according to a security ensuring algorithm predetermined with the payment server; Furthermore, a program for executing a process of generating transmission data to which a data format identification flag indicating a data format corresponding to the security ensuring algorithm applied to the user data is added.
  • the series of processes described in the specification can be executed by hardware, software, or a composite configuration of both.
  • a program recording the processing sequence is installed in the memory of a computer built into dedicated hardware and executed, or the program is loaded into a general-purpose computer capable of executing various processing. It can be installed and run.
  • the program can be pre-recorded on a recording medium.
  • the program can be received via a network such as a LAN (Local Area Network) or the Internet and installed in a recording medium such as an internal hard disk.
  • a system is a logical collective configuration of a plurality of devices, and the devices of each configuration are not limited to being in the same housing.
  • the payment data processing device generates payment data to which a security ensuring algorithm predetermined by the payment server is applied, adds a data format identification flag, and transmits the data to the user terminal.
  • the user terminal acquires from the memory data obtained by adding a data format identification flag to the user data to which the security ensuring algorithm determined by the settlement server is applied, and transmits the acquired data to the settlement server together with the settlement data.
  • the payment server performs data verification processing on each of the payment data and the user data by applying a data verification algorithm corresponding to the security ensuring algorithm determined between the respective devices.
  • Control Unit (Data Processing Unit) 102 operation unit 103 display unit 104 secure element 105 storage unit (memory) 106 clock 110 first communication unit 111 Wi-Fi communication unit 112 other communication unit 120 second communication unit 121 NFC-CLF 122 Bluetooth (registered trademark) communication unit 123 Other communication units 200 Store terminal 201 Control unit (data processing unit) 202 payment data processing device IF (data input/output unit) 203 input unit (operation unit) 204 output unit 205 storage unit (memory) 300 payment data processing device 301 control unit (data processing unit) 302 store terminal IF (data input/output unit) 303 storage unit (memory) 304 Near Field Communication Unit 501 CPU 502 ROMs 503 RAM 504 bus 505 input/output interface 506 input unit 507 output unit 508 storage unit 509 communication unit 510 drive 511 removable media

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention met en œuvre une configuration qui permet de traiter un règlement sécurisé grâce à la transmission de données dans lesquelles un indicateur indiquant un algorithme de sécurisation de sécurité est défini, grâce à l'application d'un algorithme correspondant à l'indicateur au niveau d'un côté réception, et grâce à l'exécution d'un traitement de vérification. Un dispositif de traitement de données de règlement génère des données de règlement auxquelles est appliqué un algorithme de sécurisation de sécurité déterminé à l'avance avec un serveur de règlement, ajoute un indicateur d'identification de format de données, et transmet les données de règlement ajoutées à l'indicateur d'identification de format de données à un terminal d'utilisateur. Le terminal d'utilisateur acquiert, à partir de la mémoire, des données obtenues en ajoutant un indicateur d'identification de format de données à des données d'utilisateur auxquelles est appliqué l'algorithme sécurisé de sécurité déterminé par le serveur de règlement, et transmet les données acquises au serveur de règlement conjointement avec les données de règlement. Le serveur de règlement applique, à chacune des données de règlement et aux données d'utilisateur, un algorithme de vérification de données correspondant à l'algorithme sécurisé de sécurité déterminé entre les dispositifs et exécute un traitement de vérification de données.
PCT/JP2022/016199 2021-04-22 2022-03-30 Dispositif de traitement d'informations, système de traitement d'informations, procédé et programme WO2022224780A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023516406A JPWO2022224780A1 (fr) 2021-04-22 2022-03-30

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-072591 2021-04-22
JP2021072591 2021-04-22

Publications (1)

Publication Number Publication Date
WO2022224780A1 true WO2022224780A1 (fr) 2022-10-27

Family

ID=83722236

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/016199 WO2022224780A1 (fr) 2021-04-22 2022-03-30 Dispositif de traitement d'informations, système de traitement d'informations, procédé et programme

Country Status (2)

Country Link
JP (1) JPWO2022224780A1 (fr)
WO (1) WO2022224780A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014011762A (ja) * 2012-07-03 2014-01-20 Felica Networks Inc 情報処理装置、端末装置、情報処理システム、情報処理方法およびコンピュータプログラム
WO2021033477A1 (fr) * 2019-08-16 2021-02-25 フェリカネットワークス株式会社 Dispositif de traitement d'informations, système de traitement de règlements, procédé et programme

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014011762A (ja) * 2012-07-03 2014-01-20 Felica Networks Inc 情報処理装置、端末装置、情報処理システム、情報処理方法およびコンピュータプログラム
WO2021033477A1 (fr) * 2019-08-16 2021-02-25 フェリカネットワークス株式会社 Dispositif de traitement d'informations, système de traitement de règlements, procédé et programme

Also Published As

Publication number Publication date
JPWO2022224780A1 (fr) 2022-10-27

Similar Documents

Publication Publication Date Title
US11978051B2 (en) Authenticating remote transactions using a mobile device
CN109328445B (zh) 唯一令牌认证验证值
CN113507377B (zh) 用于使用基于交易特定信息的令牌和密码的交易处理的装置和方法
CN113014400B (zh) 用户和移动装置的安全认证
US10135614B2 (en) Integrated contactless MPOS implementation
US11157905B2 (en) Secure on device cardholder authentication using biometric data
AU2022202599A1 (en) Authentication systems and methods using location matching
US20160217461A1 (en) Transaction utilizing anonymized user data
US8186586B2 (en) System, method, and apparatus for smart card pin management via an unconnected reader
AU2016219306A1 (en) Peer forward authorization of digital requests
KR20150026233A (ko) 디지털 카드 기반의 결제 시스템 및 방법
KR102574524B1 (ko) 원격 거래 시스템, 방법 및 포스단말기
US20160300220A1 (en) System and method for enabling a secure transaction between users
US20230388104A1 (en) System and method for using dynamic tag content
CN112970234B (zh) 账户断言
US20230052901A1 (en) Method and system for point of sale payment using a mobile device
WO2022224780A1 (fr) Dispositif de traitement d'informations, système de traitement d'informations, procédé et programme
US20220300943A1 (en) Information processing apparatus, payment processing system, method, and program
US11711217B2 (en) Token processing with selective de-tokenization for proximity based access device interactions
US20240193250A1 (en) Efficient interaction processing using secret
EP3761247A1 (fr) Transactions de paiement sécurisées
EP4396707A1 (fr) Traitement efficient d'interactions à l'aide d'un secret

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22791555

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023516406

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22791555

Country of ref document: EP

Kind code of ref document: A1