WO2020129264A1 - 生成方法、プログラム、情報処理装置 - Google Patents

生成方法、プログラム、情報処理装置 Download PDF

Info

Publication number
WO2020129264A1
WO2020129264A1 PCT/JP2018/047865 JP2018047865W WO2020129264A1 WO 2020129264 A1 WO2020129264 A1 WO 2020129264A1 JP 2018047865 W JP2018047865 W JP 2018047865W WO 2020129264 A1 WO2020129264 A1 WO 2020129264A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
information
authentication
payment
user
Prior art date
Application number
PCT/JP2018/047865
Other languages
English (en)
French (fr)
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 KR1020207031642A priority Critical patent/KR102612064B1/ko
Priority to KR1020237007106A priority patent/KR102624941B1/ko
Priority to CN201880093541.XA priority patent/CN112119415A/zh
Publication of WO2020129264A1 publication Critical patent/WO2020129264A1/ja
Priority to US17/129,154 priority patent/US20210110383A1/en

Links

Images

Classifications

    • 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • 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
    • 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
    • G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4015—Transaction verification using location information
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
    • G07G1/00—Cash registers
    • G07G1/12—Cash registers electronically operated
    • G07G1/14—Systems including one or more distant stations co-operating with a central processing unit

Definitions

  • the present disclosure relates to a generation method, a program, and an information processing device.
  • Patent Document 1 discloses a method of performing authentication by collating the personal identification data input to the terminal with the personal identification data stored in advance in the terminal.
  • the usability is not good for the authentication of the terminal user in the settlement by electronic money.
  • a generation method for generating code information related to electronic money settlement by a terminal by an information processing device acquires information and, based on the information, generates information related to authentication of a user of the terminal. Including generating code information.
  • a program for causing a computer of an information processing device to generate code information relating to electronic money settlement by a terminal acquires the information and authenticates a user of the terminal based on the information.
  • an information processing apparatus that generates code information related to electronic money settlement by a terminal includes an acquisition unit that acquires information and information related to authentication of a user of the terminal based on the information. , And a control unit that performs control for generating code information.
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 1st Embodiment The figure which shows an example of the display screen
  • the flowchart which shows an example of the flow of a process of the terminal which concerns on 1st Embodiment, a shop code reader apparatus, and a server.
  • the flowchart which shows an example of the flow of a process of the terminal which concerns on 1st Embodiment, a shop code reader apparatus, and a server.
  • the flowchart which shows an example of the flow of a process of the terminal which concerns on 1st Embodiment, a shop code reader apparatus, and a server.
  • the flowchart which shows an example of the flow of a process of the terminal which concerns on 1st Embodiment, a shop code reader apparatus, and a server.
  • the flowchart which shows an example of the flow of the 1st authentication skip determination processing which concerns on 1st Embodiment.
  • the flowchart which shows an example of the flow of the process of the terminal which concerns on a 1st modification, a shop code reader device, and a server.
  • the flowchart which shows an example of the flow of a process of the terminal which concerns on 2nd Embodiment, a shop code reader apparatus, and a server.
  • the flowchart which shows an example of the flow of a process of the terminal which concerns on 2nd Embodiment, a shop code reader apparatus, and a server.
  • the flowchart which shows an example of the flow of a process of the terminal which concerns on 2nd Embodiment, a shop code reader apparatus, and a server.
  • the flowchart which shows an example of the flow of the process of the terminal which concerns on a 2nd modification, a shop code reader device, and a server.
  • the flowchart which shows an example of the flow of the process of the terminal which concerns on a 2nd modification, a shop code reader device, and a server.
  • the flowchart which shows an example of the flow of the process of the terminal which concerns on a 2nd modification, a shop code reader device, and a server.
  • the figure which shows an example of the function implement
  • the flowchart which shows an example of the process flow of the terminal which concerns on 3rd Embodiment, a shop code reader apparatus, and a server.
  • the flowchart which shows an example of the flow of a process of the terminal which concerns on a 3rd modification, a shop code reader device, and a server.
  • the flowchart which shows an example of the flow of a process of the terminal which concerns on a 3rd modification, a shop code reader device, and a server.
  • the figure which shows an example of the function implement
  • the figure which shows an example of the information memorize
  • the figure which shows an example of a data structure of the remittance payment management database which concerns on 4th Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 4th Embodiment The figure which shows an example of the display screen of the terminal which concerns on 4th Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 4th Embodiment The figure which shows an example of the display screen of the terminal which concerns on 4th Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 4th Embodiment The figure which shows an example of the display screen of the terminal which concerns on 4th Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 4th Embodiment The figure which shows an example of the display screen of the terminal which concerns on 4th Embodiment.
  • the figure which shows an example of the display screen of the terminal which concerns on 4th Embodiment The figure which shows an example of the display screen of the terminal which concerns on 4th Embod
  • FIG. 1 is a diagram showing an example of a configuration of a communication system 1 according to an embodiment of the present disclosure.
  • the server 10 the terminal 20 (terminal 20A, terminal 20B, terminal 20C,...) And the store POS system 40 are connected via the network 30. ..
  • the server 10 provides the terminal 20 owned by the user via the network 30 with a service for transmitting and receiving content including messages and the like between the terminals 20.
  • the server 10 provides a service (hereinafter, referred to as “payment service”) that communicates with the terminal 20 to realize electronic payment (an example of payment without limitation).
  • the number of terminals 20 connected to the network 30 is not limited.
  • the network 30 plays a role of connecting one or more terminals 20, one or more servers 10, and one or more store POS systems 40. That is, the network 30 means a communication network that provides a connection path so that data can be transmitted and received after the above various devices are connected.
  • the network 30 is, by way of example and not limitation, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless network.
  • VPN virtual private network
  • LAN local area network
  • the network 30 may include one or more networks 30.
  • What kind of terminal 20 is an information processing terminal that can realize the functions described in each embodiment. It may be a terminal.
  • the terminal 20 may be, for example and without limitation, a smartphone, a mobile phone (feature phone), a computer (for example, without limitation, a desktop, laptop, tablet, etc.), a media computer platform (for example, without limitation, cable, satellite set). Top boxes, digital video recorders), handheld computer devices (eg, without limitation, PDAs (personal digital assistants), email clients, etc.), wearable terminals (glasses-type devices, clock-type devices, etc.), or other types of computers. , Or including a communication platform. Further, the terminal 20 may be expressed as an information processing terminal.
  • a terminal used by the user X is expressed as a terminal 20X
  • user information in a predetermined service associated with the user X or the terminal 20X is expressed as a user information X as necessary.
  • the user information is user information associated with an account used by the user in a predetermined service.
  • the user information is, for example and without limitation, the user's name, the user's icon image, the user's age, the user's sex, the user's address, the user's hobby, which is input by the user or given by a predetermined service.
  • the information includes information associated with the user such as the taste and the user's identifier, and may be any one of them or a combination thereof, or may not be so.
  • the server 10 (without limitation, an example of a server, an information processing device, and an information management device) has a function of providing a predetermined service to the terminal 20.
  • the server 10 may be any device as long as it is an information processing device that can realize the functions described in each embodiment.
  • the server 10 includes, by way of example and not limitation, server devices, computers (eg, without limitation, desktops, laptops, tablets, etc.), media computer platforms (eg, without limitation, cables, satellite set top boxes, digital video recorders). ), handheld computing devices (eg, without limitation, PDAs, email clients, etc.), or other types of computers, or communication platforms.
  • the server 10 may be expressed as an information processing device. When it is not necessary to distinguish between the server 10 and the terminal 20, the server 10 and the terminal 20 may or may not be expressed as information processing devices.
  • the server 10 will be described as having a function of providing a messaging service (IMS (Instant Messaging Service)) and a function of providing a settlement service.
  • IMS Intelligent Messaging Service
  • server having the function of providing the IMS and the server having the function of providing the settlement service may be separately configured to form two servers, the IMS server and the settlement server. May be.
  • the company operating the server 10 is a company (for example, company “X”), and the stores (member stores) of affiliated stores affiliated with the IMS provider are “store S1” and “store S1”. Store S2”,...
  • the store POS system 40 is a POS system installed and used in a store affiliated with an IMS business.
  • the store POS system 40 includes a store code reader device 50, a code cash register 60, and a store server 70 by way of example and not limitation.
  • FIG. 1 shows an example of the HW configuration of the terminal 20.
  • the terminal 20 includes a control unit 21 (CPU: central processing unit (Central Processing Unit)), a storage unit 28, a communication I/F 22 (interface), an input/output unit 23, a display unit 24, a microphone 25, a speaker 26, a camera 27, A clock unit 29A and a position calculation information detection unit 29B are provided.
  • the components of the HW of the terminal 20 are connected to each other via the bus B by way of example and not limitation. Note that it is not essential that the HW configuration of the terminal 20 includes all the constituent elements.
  • the terminal 20 may or may not be configured to remove individual components, or multiple components, such as the microphone 25, camera 27, etc.
  • the communication I/F 22 transmits and receives various data via the network 30.
  • the communication may be performed by wire or wireless, and any communication protocol may be used as long as mutual communication can be performed.
  • the communication I/F 22 has a function of performing communication with various devices such as the server 10 via the network 30.
  • the communication I/F 22 transmits various data to various devices such as the server 10 according to an instruction from the control unit 21. Further, the communication I/F 22 receives various data transmitted from various devices such as the server 10 and transmits them to the control unit 21.
  • the communication I/F 22 may be simply referred to as a communication unit. Further, when the communication I/F 22 is composed of a physically structured circuit, it may be expressed as a communication circuit.
  • the input/output unit 23 includes a device that inputs various operations on the terminal 20 and a device that outputs a processing result processed by the terminal 20.
  • the input unit and the output unit may be integrated, or the input unit and the output unit may be separated or may not be separated.
  • the input unit is realized by any one or combination of devices of all types capable of receiving an input from a user and transmitting information related to the input to the control unit 21.
  • the input unit includes, by way of example and not limitation, a hardware key such as a touch panel, a touch display, a keyboard, a pointing device such as a mouse, a camera (operation input via a moving image), and a microphone (operation input by voice).
  • the output unit is realized by any one or combination of all types of devices that can output the processing result processed by the control unit 21.
  • the output unit includes, for example and without limitation, a touch panel, a touch display, a speaker (audio output), a lens (for example, without limitation, 3D (three dimensions) output, hologram output), a printer, and the like.
  • the display unit 24 is realized by any of all types of devices capable of displaying or a combination thereof according to the display data written in the frame buffer.
  • the display unit 24 includes, for example and without limitation, a touch panel, a touch display, a monitor (for example, without limitation, a liquid crystal display or OELD (organic electroluminescence display)), a head mounted display (HDM: Head Mounted Display), projection mapping, a hologram.
  • a device capable of displaying images, text information, etc. in the air may or may not be vacuum). Note that these display units 24 may or may not be able to display the display data in 3D.
  • the input/output unit 23 is a touch panel
  • the input/output unit 23 and the display unit 24 may be arranged to face each other with substantially the same size and shape.
  • the clock unit 29A is a built-in clock of the terminal 20, and outputs time information (timekeeping information).
  • the clock unit 29A is configured to include, for example and without limitation, a clock using a crystal oscillator, a clock using the NITZ (Network Identity and Time Zone) standard, and the like.
  • the clock unit 29A can also be expressed as a clock unit or a time information detection unit as an example without limitation.
  • the position calculation information detection unit 29B detects (measures) information necessary for the control unit 21 to calculate (measure) the position of its own terminal 20 (hereinafter, referred to as "position calculation information"). It is a department.
  • the position calculation information detection unit 29B can be expressed as a position calculation sensor unit as an example without limitation.
  • the position calculation information detection unit 29B is, for example, without limitation, a satellite positioning sensor (satellite positioning sensor) that is a sensor or unit for calculating the position of the terminal 20 using a satellite positioning system such as GPS (Global Positioning System). Unit), an inertial measurement sensor (inertial measurement unit (IMU)) which is a sensor or a unit for calculating the position of the terminal 20 using the inertial navigation system, and the like.
  • a satellite positioning sensor satellite positioning sensor
  • GPS Global Positioning System
  • IMU inertial measurement unit
  • the satellite positioning unit is, for example and without limitation, an RF receiving circuit for converting an RF (Radio Frequency) signal including a positioning satellite signal transmitted from a positioning satellite received by an antenna (not shown) into a digital signal, Information such as satellite orbit data and time data extracted from the positioning satellite signal is acquired as position calculation information by performing correlation calculation processing or the like on the digital signal output from the RF receiving circuit to capture the positioning satellite signal. It has a baseband processing circuit for outputting.
  • RF Radio Frequency
  • the inertial measurement unit has an inertial sensor that is a sensor that detects information necessary for calculating the position of the terminal 20 by inertial navigation calculation.
  • the inertial sensor includes, for example and without limitation, a three-axis acceleration sensor and a three-axis gyro sensor, and the acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor are used as position calculation information. Output.
  • the control unit 21 has a circuit physically structured to execute a function realized by a code or an instruction included in a program, and as an example and not a limitation, a data processing device incorporated in hardware. It is realized by. Therefore, the control unit 21 may or may not be expressed as a control circuit.
  • the control unit 21 includes, by way of example and not limitation, a central processing unit (CPU), a microprocessor (microprocessor), a processor core (processor), a multiprocessor (multiprocessor), an ASIC (application-specific integrated circuit), and an FPGA (field programmable). gate array) is included.
  • CPU central processing unit
  • microprocessor microprocessor
  • processor core processor
  • multiprocessor multiprocessor
  • ASIC application-specific integrated circuit
  • FPGA field programmable gate array
  • the storage unit 28 has a function of storing various programs and various data necessary for the terminal 20 to operate.
  • the storage unit 28 includes, for example and without limitation, various storage media such as an HDD (hard disk drive), an SSD (solid state drive), a flash memory, a RAM (random access memory), and a ROM (read only memory). Further, the storage unit 28 may or may not be expressed as a memory.
  • the terminal 20 stores the program P in the storage unit 28, and by executing the program P, the control unit 21 executes processing as each unit included in the control unit 21. That is, the program P stored in the storage unit 28 causes the terminal 20 to realize each function executed by the control unit 21.
  • the program P may or may not be expressed as a program module.
  • the microphone 25 is used to input voice data.
  • the speaker 26 is used to output audio data.
  • the camera 27 is used to acquire moving image data.
  • FIG. 1 shows an example of the HW configuration of the server 10.
  • the server 10 includes a control unit 11 (CPU), a storage unit 15, a communication I/F 14 (interface), an input/output unit 12, a display 13, and a clock unit 19.
  • the components of the HW of the server 10 are connected to each other via the bus B by way of example and not limitation.
  • the HW of the server 10 does not have to include all the constituent elements as the configuration of the HW of the server 10.
  • the HW of the server 10 may or may not be configured to remove the display 13.
  • the control unit 11 has a circuit physically structured to execute a function realized by a code or an instruction included in a program, and as an example and not a limitation, a data processing device incorporated in hardware. It is realized by.
  • the control unit 11 is typically a central processing unit (CPU), and may or may not be a microprocessor, processor core, multiprocessor, ASIC, FPGA. In the present disclosure, the control unit 11 is not limited to these.
  • the storage unit 15 has a function of storing various programs and various data necessary for the server 10 to operate.
  • the storage unit 15 is realized by various storage media such as HDD, SSD, and flash memory. However, in the present disclosure, the storage unit 15 is not limited to these.
  • the storage unit 15 may or may not be expressed as a memory.
  • the communication I/F 14 transmits and receives various data via the network 30.
  • the communication may be performed by wire or wireless, and any communication protocol may be used as long as mutual communication can be performed.
  • the communication I/F 14 has a function of performing communication with various devices such as the terminal 20 via the network 30.
  • the communication I/F 14 transmits various data to various devices such as the terminal 20 according to an instruction from the control unit 11. Further, the communication I/F 14 receives various data transmitted from various devices such as the terminal 20 and transfers them to the control unit 11. Further, the communication I/F 14 may be simply expressed as a communication unit. Further, when the communication I/F 14 is composed of a physically structured circuit, it may be expressed as a communication circuit.
  • the input/output unit 12 is realized by a device that inputs various operations on the server 10.
  • the input/output unit 12 is realized by any one or combination of devices of all types capable of receiving an input from a user and transmitting information related to the input to the control unit 11.
  • the input/output unit 12 is typically realized by a hardware key typified by a keyboard or the like, or a pointing device such as a mouse. It should be noted that the input/output unit 12 may or may not include a touch panel, a camera (operation input via a moving image), and a microphone (operation input by voice), for example and not by way of limitation. However, in the present disclosure, the input/output unit 12 is not limited to these.
  • the display 13 is typically realized by a monitor (a liquid crystal display or an OELD (organic electroluminescence display) as an example without limitation).
  • the display 13 may or may not be a head mounted display (HDM). Note that these displays 13 may or may not be capable of displaying display data in 3D. In the present disclosure, the display 13 is not limited to these.
  • the clock unit 19 is a built-in clock of the server 10 and outputs time information (timekeeping information).
  • the clock unit 19 is configured to have, for example and without limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, and the like.
  • the clock unit 19 can also be expressed as a clock unit or a time information detection unit as an example without limitation.
  • FIG. 2 shows an example of the system configuration of the store POS system 40.
  • the store POS system 40 is a POS system that is installed and used in a store that is affiliated with a business operator (IMS business operator) who operates the server 10.
  • IMS business operator business operator
  • a shop code reader device 50, The code cash register 60 and the store server 70 are included.
  • the store code reader device 50 is communicatively connected to the code cashier 60 and the store server 70 by a POS communication I/F 57 (for example, without limitation, wired communication I/F or wireless communication I/F in the store), and the code cashier 60 is used.
  • POS communication I/F 57 for example, without limitation, wired communication I/F or wireless communication I/F in the store
  • the code cashier 60 is used.
  • the terminal display code displayed on the display unit 24 of the terminal 20 is read.
  • information regarding payment at the terminal 20 (payment request information to be described later as an example without limitation) is transmitted to the server 10 via the communication I/F 54, and the server 10 transmits the information.
  • Information regarding the settlement result (for example, without limitation, settlement result information for a store, which will be described later) is received from the server 10 via the communication I/F 54.
  • the store code reader device 50 includes, as a non-limiting example, a control unit 51, an input/output unit 52, a display unit 53, a communication I/F 54, a storage unit 55, a sound output unit 56, and a POS communication I/F. It has an F57 and a code reader 58.
  • the code reader 58 is a code reader for reading a two-dimensional code, and in the present specification, a two-dimensional code (for example, QR code (registered trademark) displayed on the display unit 24 of the terminal 20 and presented by the user of the terminal 20. )) as a two-dimensional code reader (for example, a QR code reader) for reading a terminal display code.
  • a two-dimensional code for example, QR code (registered trademark) displayed on the display unit 24 of the terminal 20 and presented by the user of the terminal 20. )
  • a two-dimensional code reader for example, a QR code reader
  • the code cashier 60 is, for example and not by way of limitation, communicatively connected to the store code reader device 50 and the store server 70 by the POS communication I/F 57, and based on the payment result information for the store acquired by the store code reader device 50 from the server 10. , Issue a receipt with the total amount of products sold.
  • the code cash register 60 is a cash register configured to be compatible with a payment application, and can also be referred to as a stationary terminal compatible with a payment application.
  • the store server 70 stores information about the store, information about products sold at the store, information about services provided at the store, sales of products at the store, and provision of services. It manages various information such as related sales information.
  • the store server 70 is configured to be communicable with the store code reader device 50 and the code register 60 by the POS communication I/F 57, and is also configured to be communicable with an external device such as the server 10 via the network 30.
  • the store server 70 does not necessarily have to be directly communicable with the store code reader device 50, and may be communicable with the store code reader device 50 via the code register 60.
  • the shop settlement result information acquired by the shop code reader device 50 from the server 10 may be sent to the code cashier 60, and then sent from the code cashier 60 to the shop server 70.
  • the server 10 stores the program P in the storage unit 15 and executes the program P, so that the control unit 11 performs processing as each unit included in the control unit 11. That is, the program P stored in the storage unit 15 causes the server 10 to realize each function executed by the control unit 11.
  • This program P may or may not be expressed as a program module. The same applies to other devices.
  • the control unit 21 of the terminal 20 and/or the control unit 11 of the server 10 is formed not only in a CPU having a control circuit but also in an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)), or the like. Each process may or may not be implemented by a dedicated logic circuit (hardware) or a dedicated circuit. Further, these circuits may be realized by one or a plurality of integrated circuits, and the plurality of processes shown in each embodiment may or may not be realized by one integrated circuit. Further, the LSI may be referred to as VLSI, super LSI, ultra LSI, or the like depending on the degree of integration. Therefore, the control unit 21 may or may not be expressed as a control circuit. The same applies to other devices.
  • IC Integrated Circuit
  • LSI Large Scale Integration
  • the program P of each embodiment of the present disclosure may be provided in a state of being stored in a computer-readable storage medium, It does not have to be done.
  • the storage medium can store the program P in a “non-transitory tangible medium”.
  • the program P may or may not be a program for realizing a part of the function of each embodiment of the present disclosure.
  • the function of each embodiment of the present disclosure may be realized by a combination with the program P already recorded in the storage medium, that is, a so-called difference file (difference program) may or may not be provided.
  • the storage medium may be one or more semiconductor-based or other integrated circuits (ICs) such as, by way of example and not limitation, field programmable gate arrays (FPGAs) or application specific ICs (ASICs), hardware.
  • ICs semiconductor-based or other integrated circuits
  • FPGAs field programmable gate arrays
  • ASICs application specific ICs
  • HDD high-dimensional hard drive
  • HDD hybrid hard drive
  • ODD optical disk drive
  • magneto-optical disk magneto-optical drive
  • FDD floppy diskette
  • FDD floppy disk drive
  • magnetic tape solid state It may include a drive (SSD), RAM drive, secure digital card, or drive, any other suitable storage medium, or any suitable combination of two or more thereof.
  • SSD drive
  • RAM drive secure digital card
  • the storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.
  • the storage medium is not limited to these examples, and may be any device or medium as long as it can
  • the server 10 and/or the terminal 20 can realize the functions of the plurality of functional units shown in each embodiment by reading the program P stored in the storage medium and executing the read program P. The same applies to other devices.
  • the program P of the present disclosure may or may not be provided to the server 10 and/or the terminal 20 via any transmission medium (communication network, broadcast wave, etc.) capable of transmitting the program. ..
  • the server 10 and/or the terminal 20 execute the program P downloaded via the Internet or the like to realize the functions of the plurality of functional units described in each embodiment. The same applies to other devices.
  • Each embodiment of the present disclosure can also be realized in the form of a data signal embedded in a carrier wave in which the program P is embodied by electronic transmission.
  • At least a part of the processing in the server 10 and/or the terminal 20 may or may not be realized by cloud computing configured by one or more computers.
  • At least a part of the processing in the terminal 20 may or may not be performed by the server 10.
  • at least a part of the processing of each functional unit of the control unit 21 of the terminal 20 may or may not be configured to be performed by the server 10.
  • At least part of the processing in the server 10 may or may not be performed by the terminal 20.
  • at least part of the processing of each functional unit of the control unit 11 of the server 10 may or may not be configured to be performed by the terminal 20.
  • the configuration of the determination in the embodiment of the present disclosure is not essential, a predetermined process is operated when the determination condition is satisfied, or a predetermined process is performed when the determination condition is not satisfied. It may or may not be.
  • program of the present disclosure includes, for example and without limitation, script languages such as ActionScript and JavaScript (registered trademark), object-oriented programming languages such as Objective-C and Java (registered trademark), and markup languages such as HTML5. It is implemented using.
  • script languages such as ActionScript and JavaScript (registered trademark)
  • object-oriented programming languages such as Objective-C and Java (registered trademark)
  • markup languages such as HTML5. It is implemented using.
  • IMS Internet Services
  • SNS Social Networking Service
  • the first to third embodiments are, as an example and not a limitation, applications provided by an IMS business operator, and as one function of IMS application software (hereinafter simply referred to as “IMS application”).
  • IMS application IMS application software
  • electronic payment is performed using IMS payment application software (hereinafter simply referred to as “payment application”) that is an application for electronic payment that can be used by the user of the terminal 20 as an application that operates in conjunction with the IMS application. It is an embodiment.
  • the user of the terminal 20 purchases a product at a store or receives a service provided by the store
  • electronic payment is performed using a payment application. ..
  • the authentication for electronic payment requested to the user on the terminal 20 side is skipped when a specific condition is satisfied.
  • “payment” means “electronic payment” using a payment application unless otherwise specified.
  • authentication means authenticating that the user of the terminal 20 is a legitimate user in order to make payment
  • authentication processing means authentication for this payment.
  • the “authentication skip condition” means a condition for skipping the above-mentioned payment authentication process
  • “skipping the authentication process” means ignoring the processing command of the authentication process.
  • “IMS money” means electronic money managed by the IMS business operator on the server 10 and usable by the user of the terminal 20 in the payment application.
  • the "electronic money” is a payment means that is provided by a business operator (a business operator of IMS in the embodiment described below) and that uses information communication technology and that is a substitute for cash.
  • the electronic money in the present disclosure is not limited to IMS money, and can be a concept including all payment methods that can be used by a user as a substitute for cash.
  • the contents described in the first embodiment can be applied to any of the other embodiments.
  • FIG. 3-1 is a diagram showing an example of functions implemented by the control unit 11 of the server 10 in this embodiment.
  • the server 10 has a server main processing unit 111, an IMS processing unit 112, and a payment management processing unit 113 as functions implemented by the control unit 11.
  • the server main processing unit 111 has a function of executing a server main process, which is a process for centrally controlling the server 10, according to the server main processing program 151 stored in the storage unit 15.
  • the IMS processing unit 112 has a function of executing an IMS process, which is a process for realizing transmission and reception of content including an IMS message between the terminals 20 according to the IMS processing program 1512 stored in the storage unit 15.
  • the payment management processing unit 113 has a function of executing payment management processing, which is processing for executing and managing payment by IMS money, according to the payment management processing program 1513 stored in the storage unit 15.
  • the user of the terminal 20 uses the payment application stored in the terminal 20 to perform payment by two kinds of payment types, for example and without limitation, “display terminal code” and “read terminal code”. Will be described as possible.
  • terminal code display is a method in which when the user of the terminal 20 makes a payment at the store, the terminal display code displayed on the terminal 20 is displayed using the payment application stored in the terminal 20. It is a payment type for payment by presenting the terminal display code to the store clerk at 60 and having the store code reader device 50 read the code.
  • the payment type “read terminal code” is, for example, when a user of the terminal 20 makes a payment at a store, using a payment application stored in the terminal 20 and is sold at a store, around the code cashier 60, or at the store. It is a settlement type in which a terminal reading code posted in a display area (for example, a lunch area, a beverage area, a foodstuff area, etc.) corresponding to a product type of a product is read to make a payment.
  • a display area for example, a lunch area, a beverage area, a foodstuff area, etc.
  • the terminal display code and the terminal reading code are each represented by a two-dimensional code.
  • the two-dimensional code is a display type code having information in the horizontal direction and the vertical direction, and is a matrix type code in which small squares are arranged vertically and horizontally (hereinafter, referred to as “matrix code”) and a primary code.
  • matrix code a matrix type code in which small squares are arranged vertically and horizontally
  • primary code a primary code.
  • stack type code hereinafter, referred to as a “stack code” in which a plurality of original codes (barcodes as an example without limitation) are vertically stacked.
  • QR code registered trademark
  • a terminal display code and a terminal reading code for the sake of simplicity.
  • a code such as an SP code, a Veri code, a maxi code, a CP code, or a chameleon code may or may not be used as the matrix code other than the QR code. Further, instead of the matrix code, various stack codes may or may not be used.
  • the payment management processing unit 113 includes, for example and without limitation, the terminal display code generation processing unit 1131, the terminal display code transmission processing unit 1133, the store payment result information transmission processing unit 1136, and the terminal payment result information transmission.
  • the processing unit 1137 is included as a functional unit.
  • the terminal display code generation processing unit 1131 has a function of generating a terminal display code.
  • the terminal display code generation processing unit 1131 accesses at least the settlement page, which is one of the web pages provided by the server 10, based on the reception of the terminal display code generation request information transmitted from the terminal 20.
  • a QR code including access information for authentication and authentication information is generated as a terminal display code.
  • the access information includes, for example and without limitation, a URL (Uniform Resource Locator) for the store code reader device 50 that has read the terminal display code to access the payment page.
  • This access information can also be expressed as “link” or “link information”.
  • the URL of the payment page will be referred to as “payment page URL”.
  • the authentication information is, for example, without limitation, as the authentication information necessary for the server 10 to authenticate that the terminal 20 or the user of the terminal 20 is the legitimate terminal 20 or the user of the legitimate terminal 20.
  • a token randomly issued by the server 10 is included.
  • the authentication information is information issued by the certificate authority, and the token is authentication information issued by the server 10 as the certificate authority to authenticate the terminal 20 or the user of the terminal 20.
  • the token in this embodiment can also be expressed as, for example, a “random token”, an “access token”, or a “payment token”.
  • a “random token” an “access token”
  • a “payment token” a token that is randomly issued.
  • the tokens are randomly issued, each time a terminal display code is generated, it becomes a different token. Therefore, the token or the terminal display code including this token functions as a one-time password.
  • the terminal display code generation processing unit 1131 uses, as the terminal display code, a one-dimensional code (a bar code as an example, not a limitation) in addition to a two-dimensional code (a QR code as an example, not a limitation). Also generate. This is because some stores may not be able to read the two-dimensional code, but may be able to read the one-dimensional code.
  • a one-dimensional code a bar code as an example, not a limitation
  • a QR code as an example, not a limitation
  • the terminal display code generation processing unit 1131 associates the terminal display code with an effective period (for example, a period of “5 minutes” from the code generation time). And transmits it to the terminal 20.
  • an effective period for example, a period of “5 minutes” from the code generation time.
  • the terminal display code displayed on the terminal 20 is read by the store code reader device 50 within this valid period, payment is possible, but after the valid period elapses, the terminal display code is displayed on the store code reader device 50. If it is read by, it is necessary to reacquire the terminal display code. That is, the terminal display code in this embodiment functions as a time code.
  • the terminal reading code used in the payment type “read terminal code” includes at least the payment page URL for the terminal 20 that has read the terminal reading code to access the payment page as access information. Be done.
  • the terminal reading code will be described as including two types of terminal reading codes.
  • the first type of terminal reading code (hereinafter referred to as “first type terminal reading code”) is used in stores of various industries in Japan (typically, convenience stores in Japan). Is the code.
  • the code for reading the first-class terminal is, as an example of a usage mode, a code used to settle a product of a product type that is sold at a uniform price (fixed price) in a store, for example, a product such as a lunch box or a beverage.
  • a uniform price fixed price
  • the first-class terminal reading code is, for example, without limitation, a payment page URL corresponding to a product or a product type sold in the shop, which is associated with a store that operates the first-class terminal reading code. included.
  • the server 10 associates a store operating the first-class terminal reading code with a store ID (an example of store identification information without limitation) of the store as an example without limitation, and a product or a product type,
  • a store ID an example of store identification information without limitation
  • the sales amount and the settlement page URL are stored and managed.
  • the second type of terminal reading code (hereinafter referred to as the "second type terminal reading code”) is a special code and is used in a specific foreign store (typically a Chinese food stall) or the Internet. It is a code that is used in electronic commerce, etc. Unlike the code for reading the type 1 terminal, the code for reading the type 2 terminal does not manage the product type or the sales amount on the server 10 side as an example of a usage mode, and the user of the terminal 20 purchases the code. It can be a code used to enter the amount of money of the product to be paid by itself and make a payment.
  • the type 2 terminal reading code includes, as an example and without limitation, a payment page URL corresponding to the store that is associated with the store that operates the type 2 terminal reading code.
  • the server 10 stores and manages the payment page URL in association with, for example and without limitation, the store that operates the type 2 terminal reading code, with the store ID of the store.
  • only one type of code of the type 1 terminal reading code and the type 2 terminal reading code may be used as the terminal reading code. That is, it is possible to use only the first type terminal reading code as the terminal reading code without dividing the terminal reading code into two types, or to use only the second type terminal reading code as the terminal reading code. You can also In this case, in the functions, data, processing, etc. described in the present embodiment, the configuration relating to the type of terminal reading code that does not apply can be deleted.
  • FIG. 3-2 is a diagram showing an example of information stored in the storage unit 15 of the server 10 according to this embodiment.
  • the storage unit 15 stores, as a program, a server main processing program 151 that is read by the control unit 11 and executed as a server main processing.
  • the server main processing program 151 includes, as a subroutine program, an IMS processing program 1512 read by the control unit 11 and executed as an IMS processing, and a payment management processing program 1513 executed as a payment management processing.
  • the payment management process will be described later in detail using a flowchart.
  • the storage unit 15 also stores, as an example and without limitation, user registration data 153, store registration data 155, a payment management database 157, and a code management database 159.
  • the user registration data 153 is registration data of the terminal 20 using the payment service and the user of the terminal 20, and an example of the data structure is shown in FIG. 3-3.
  • a user name, a terminal telephone number, a terminal mail address, a user ID, an authentication password, and other registration information are stored in association with each other.
  • the user name is the name of the user of the terminal 20 who uses the payment service, and the name registered when the user of the terminal 20 uses the payment service is stored.
  • the terminal telephone number is the telephone number of the terminal 20 of the user having this user name, and the telephone number of the terminal 20 registered when the user of the terminal 20 uses the payment service is stored.
  • the terminal mail address is the mail address of the terminal 20 of the user having this user name, and the mail address of the terminal 20 registered when the user of the terminal 20 uses the payment service is stored.
  • the terminal telephone number and the terminal mail address are examples of identification information for identifying the terminal 20 (hereinafter referred to as “terminal identification information”).
  • the user ID is an ID that functions as identification information for identifying the user of the terminal 20, and is an ID that is set uniquely to the user who uses the payment application.
  • this user ID is not limited to a specific example, and the server 10 sets and stores a unique ID for each user.
  • the user ID is an example of identification information for identifying the user of the terminal 20 (hereinafter referred to as “user identification information”).
  • the authentication password is a password for authentication that is required to be input by the user when performing authentication processing for payment (hereinafter, simply referred to as “authentication processing”) on the terminal 20 of the user having this user name.
  • authentication processing authentication processing
  • the other registration information is other registration information of the user having this user name, and includes, for example and without limitation, a user icon image that is image data of an icon used by the user in the IMS application, a user profile, and the like. ..
  • the above various user information can be stored and managed on the server 10 side as common user information for the IMS application and the payment application.
  • the store registration data 155 is registration data of a store affiliated with an IMS business operator (payment service business operator), and an example of the data structure is shown in FIG. 3-4.
  • the store registration data 155 stores a business type, a store name, store position information, store POS system information, a store ID, a first specific business type flag, and a second specific business type flag in association with each other as store information. It
  • the type of business stores the type of business of the store.
  • This industry includes, by way of example and not limitation, various industries such as “convenience store”, “supermarket”, “pharmacy”, “tavern”, “department store”, “restaurant”, “bookstore”, “watch store”. Be done.
  • the store name stores the store name of a store included (belonging to) in each industry for each industry.
  • the location information of the location of the store with this store name (hereinafter referred to as “store location information”) is stored in the store location information.
  • This store position information may be a two-dimensional or three-dimensional position coordinate of the store location, or a latitude and longitude (latitude, longitude, and in some cases altitude) of the store location. ..
  • the store POS system information stores information about the store POS system 40 used in this store.
  • This store POS system information includes, for example and without limitation, information necessary for the server 10 to communicate with the store code reader device 50 and the store server 70.
  • the store POS system 40 Since the store POS system 40 performs processing in cooperation with the server 10, for example and without limitation, the store POS system 40 acquires a software package for a payment service provided (distributed) from the server 10 in advance and stores it in the store code reader device 50 or the store.
  • the software package can be stored in the server 70 and used by being called from a payment processing program in a store.
  • An application programming interface (API) is a typical example, and the store code reader device 50 can activate the API, for example, to transmit information to the server 10 and receive information from the server 10.
  • the server 10 receives, by way of example and not limitation, information such as the business type of the store, the store name, the store location information, and the store POS system information from the store server 70 of the store and stores it in the store registration data 155. Can be kept.
  • the store ID is an ID that functions as identification information for identifying the store with this store name.
  • the store ID is, without limitation, set and stored by the server 10 as a unique ID for each store.
  • the store ID is an example of identification information for identifying the store (hereinafter referred to as “store identification information”).
  • the first specific type of industry flag is a flag indicating whether or not this type of industry is a preset first type of specific type of industry (hereinafter referred to as “first specific type of industry”). “ON” is stored in the business category corresponding to “1”, and “OFF” is stored in the business category not corresponding to the first specific business category.
  • the first specific industry can be set in advance on the server 10 side by way of example and not limitation. In this example, “convenience store” and “supermarket”, which are businesses that many users use on a daily basis, are set as the first specific industry.
  • the second specific industry flag is a flag indicating whether or not this industry is the preset second type of specific industry (hereinafter, referred to as “second specific industry”). “ON” is stored in the business category corresponding to the above, and “OFF” is stored in the business category not corresponding to the second specific business category.
  • the second specific industry can also be set in advance on the server 10 side by way of example and not limitation. In this example, “Tavern”, which is a high-risk business type in which the user forgets to leave the terminal 20, is set as the second specific business type.
  • the payment management database 157 is a database that cumulatively stores data for managing information related to payment by the user of each terminal 20, and an example of the data structure is shown in FIG. 3-5.
  • the payment management database 157 stores payment management data generated for each terminal 20 or each user of the terminal 20.
  • each payment management data stores the user ID of the user of the terminal 20, the balance, the IMS points, the daily upper limit set amount, the auto charge setting, and the payment history data. ..
  • the user ID stored in the user registration data 153 is stored as the user ID.
  • the latest value of the balance (remaining amount) of the IMS money owned by the user with this user ID is stored in the balance.
  • IMS points are stored as points that can be accumulated at various IMS services and member stores affiliated with an IMS business.
  • the IMS point has a value equivalent to 1 yen per point, and can be exchanged for a gift certificate, a product, or the like, and can also be used for settlement by being cashed in a settlement application.
  • the daily maximum set amount stores the maximum daily amount of money that the user with this user ID can use for payment.
  • the auto charge setting is a setting for whether or not the IMS money is automatically replenished (auto charge) when the balance is low (for example, “500 yen”) or “0 yen”. If the user sets the auto charge, "ON" is stored, and in other cases, "OFF" is stored.
  • auto-charging can be performed from a bank account or the like registered by the user of the terminal 20.
  • the settlement history data is data relating to the settlement history of the user with this user ID, and as an example and without limitation, the settlement date and time that is the date and time when the server 10 performed the settlement and the store where the settlement was performed.
  • the store ID that is the ID of the store
  • the store name that is the name of the store having the store ID
  • the payment amount that is the payment amount are associated and stored in time series.
  • the code management database 159 is a database for managing the terminal display code and the terminal reading code, and includes the terminal display code management database 1591 and the terminal reading code management database 1593.
  • the terminal display code management database 1591 is a database for managing the terminal display code, and as a non-limiting example, the user ID stored in the user registration data 153 and the user identified by this user ID are stored. Data associated with the token included in the terminal display code generated for the terminal 20 is stored.
  • the terminal identification information such as the terminal telephone number stored in the user registration data 153 is stored in the terminal display code management database 1591. It may or may not be.
  • the terminal reading code management database 1593 is a database for managing the terminal reading code, and by way of example and not limitation, data for managing the first type terminal reading code and the second type terminal reading code. And data for managing the.
  • the code for reading the type 1 terminal for example, without limitation, the product or product type to be sold at the store, the sales amount, and the payment page URL are associated for each store ID.
  • the data is stored.
  • the sales amount and the payment page are not associated with each other or the product type. You may make it memorize
  • the second-class terminal reading code for example, without limitation, data in which a payment page URL is associated with each store ID is stored.
  • store POS system information stored in the store registration data 155 In addition to or in addition to the store ID that is the store identification information, store POS system information stored in the store registration data 155, contact information such as a store phone number, store email address, and the like are displayed. It may or may not be stored in the terminal reading code management database 1593.
  • FIG. 3-6 is a diagram showing an example of functions implemented by the control unit 21 of the terminal 20 in the present embodiment.
  • the terminal 20 has a terminal main processing unit 211, an IMS application processing unit 212, a payment application processing unit 213, and a position calculation processing unit 217 as the functions realized by the control unit 21.
  • the terminal main processing unit 211 has a function of executing a terminal main process that is a process for centrally controlling the terminal 20 according to the terminal main processing program 281 stored in the storage unit 28.
  • a terminal main process that is a process for centrally controlling the terminal 20 according to the terminal main processing program 281 stored in the storage unit 28.
  • control for performing a call with another mobile phone, a fixed phone, or the like via the communication I/F 22, or via the communication I/F 22 is performed.
  • Control for accessing various websites control for displaying various information on the display unit 24, processing for analyzing various sound data input from the microphone 25, or the camera 27.
  • a process of analyzing a still image or a moving image captured by is executed.
  • the IMS application processing unit 212 is a process for transmitting/receiving content to/from another user's terminal 20 via the server 10 based on the IMS application 282 stored in the storage unit 28. Has the function of executing.
  • the payment application processing unit 213 has a function of executing a payment application process, which is a process for performing payment by communicating with the server 10 based on the payment application 283 stored in the storage unit 28.
  • the payment application processing unit 213 has a terminal display code acquisition processing unit 2131, a code reading processing unit 2133, an authentication skip determination processing unit 2135, and an authentication processing unit 2137 as functional units.
  • the terminal display code acquisition processing unit 2131 has a function of executing a process for acquiring the terminal display code from the server 10 in the payment type “terminal code display”.
  • the code reading processing unit 2133 has a function of executing processing for reading a terminal reading code posted in a store in the payment type “terminal code reading”.
  • the authentication skip determination processing unit 2135 is a process for determining whether or not to skip the authentication processing executed by the authentication processing unit 2137 according to the authentication skip determination processing program 2845 stored in the storage unit 28. It has a function of executing a determination process.
  • the authentication skip determination processing unit 2135 receives the terminal display code from the server 10 based on the processing of the terminal display code acquisition processing unit 2131 in the payment type “terminal code display”, for example and not limitation.
  • the authentication skip determination process is executed at a later timing.
  • the authentication skip determination processing unit 2135 is, for example and not by way of limitation, in the payment type “terminal code reading”, the server 10 based on the information included in the terminal reading code read based on the processing of the code reading processing unit 2133.
  • the authentication skip determination process is executed at a timing after receiving information about a payment schedule (hereinafter, referred to as “payment schedule information”) from the.
  • payment schedule information hereinafter, referred to as “payment schedule information”
  • the authentication processing unit 2137 has a function of performing authentication processing according to the authentication processing program 2847 stored in the storage unit 28.
  • a process of displaying an authentication screen for allowing the user of the terminal 20 to enter the authentication password on the display unit 24 is performed as a display process related to the execution of the authentication of the user of the terminal 20. It is determined whether the authentication password entered on the screen matches the registered authentication password.
  • the position calculation processing unit 217 has a function of executing a position calculation process that is a process of calculating the position of the terminal 20 of itself based on the position calculation information output from the position calculation information detection unit 29B. ..
  • the position calculation processing unit 217 performs satellite positioning calculation based on, for example, satellite orbit data and time data output from a satellite positioning sensor (satellite positioning unit) included in the position calculation information detection unit 29B, and the self calculation The position of the terminal 20 is calculated.
  • the position calculation processing unit 217 performs inertial navigation calculation based on the information on the acceleration and the angular velocity output from the inertial measurement sensor (inertial measurement unit) included in the position calculation information detection unit 29B, and calculates its own terminal. Calculate 20 positions.
  • a processing device or a calculation device for example, a CPU or DSP
  • the position calculation is performed not by the control unit 21 of the terminal 20.
  • the usage information detection unit 29B may or may not calculate and output the position of the terminal 20.
  • a wireless device for enabling the terminal 20 to acquire position information for example, a beacon that transmits a beacon signal (typically, a Bluetooth signal) is installed in a member store, and the terminal 20 The position information may or may not be acquired based on the beacon signal transmitted from the beacon installed in the store.
  • a beacon that transmits a beacon signal typically, a Bluetooth signal
  • FIG. 3-7 is a diagram showing an example of information stored in the storage unit 28 of the terminal 20 in the present embodiment.
  • the storage unit 28 stores a terminal main processing program 281 read by the control unit 21 and executed as terminal main processing, and a position read by the control unit 21 and executed as position calculation processing.
  • the calculation processing program 287 is stored.
  • the storage unit 28 stores an IMS application 282 and a payment application 283 as application software acquired by being downloaded from the server 10 in advance.
  • the IMS application 282 and the payment application 283 may be one application or different applications.
  • the storage unit 28 also stores, as an example and without limitation, terminal data 286 and calculated position history data 288.
  • the terminal data 286 is data relating to the terminal 20, and for example and without limitation, terminal identification information such as a terminal telephone number and a terminal mail address, lock setting “ON/OFF” on the OS side of the terminal 20, and terminal 20 This includes information such as a terminal unlock password for unlocking the OS side and terminal side authentication setting “ON/OFF”.
  • the position calculation processing unit 217 performs position calculation processing on the calculated position history data 288 at predetermined time intervals (for example, "every 1 minute”, “every 5 minutes”, “every 10 minutes”).
  • the history of the calculated position of the terminal 20 (hereinafter, referred to as “calculated position”) is stored.
  • the payment application 283 includes a payment application program 284 read by the control unit 21 and executed as a payment application process, and payment application data 285 in which various data regarding the payment application are stored.
  • the payment application program 284 is, for example and without limitation, the authentication skip determination processing program 2845 read by the control unit 21 and executed as the authentication skip determination process, and the payment application program 284 read by the control unit 21 and executed as the authentication process.
  • the authentication processing program 2847 is included as a subroutine program.
  • the payment application data 285 includes, for example and without limitation, authentication skip condition data 2851, payment data 2853, and store data 2855.
  • the store data 2855 stores, for example and without limitation, store information in which the business type stored in the store registration data 155 of the server 10, the first specific business type flag, and the second specific business type flag are associated with each other.
  • the store data 2855 can be updated, for example, by distributing the latest store information from the server 10 to the terminal 20 at the timing of updating the IMS application 282 and the payment application 283.
  • the authentication skip condition data 2851 is data in which an authentication skip condition that is a condition for skipping the authentication process is defined, and an example of the data structure is shown in FIG. 3-8.
  • the authentication skip condition data 2851 includes a condition category No that is the number of the category of the authentication skip condition, a condition No that is the number of the authentication skip condition included in the category of this condition category No, and an authentication skip condition of this condition No.
  • the application presence/absence indicating whether or not to apply the authentication skip condition to make a determination and the importance (priority) of the authentication skip condition are stored in association with each other.
  • each authentication skip condition and its determination method will be described in detail.
  • condition category No. “SP1” is a category of “time”, and the authentication skip conditions of the condition Nos. “SP1-1” and “SP1-2” are included as an example without limitation.
  • the current date and time is within the set time from the final settlement date and time
  • the “final settlement date and time” is the date and time when the payment was made last (the latest date and time when the payment was made), regardless of whether the authentication process was skipped by the terminal 20. This means that the fact that the current date and time is within the set time (for example, “within 1 hour”) from the final settlement date and time means that the settlement will be performed again within a short time, so that the convenience of the user is improved. , Means omitting authentication.
  • the current date and time based on the time counted by the terminal unit 20 and the final settlement date and time stored in the settlement history data of the settlement data 2853. It is possible to determine whether or not the current date and time is within the set time from the final settlement date and time by acquiring and.
  • the current time is included in the set time zone is defined as the authentication skip condition for condition number “SP1-2”.
  • the set time zone can be set in advance by the user of the terminal 20 without limitation. Specifically, for example, the user of the terminal 20 can set the time zone in which he/she frequently makes payments as the set time zone, so that the authentication can be omitted when performing the payment in the set time zone. ..
  • the terminal 20 acquires the current time based on the time measured by the clock unit 29A, and determines whether the current time is included in the set time zone. It may be determined.
  • condition category No. “SP2” is a category of “store/place”, and includes, for example and without limitation, authentication skip conditions of condition Nos. “SP2-1” to “SP2-4”.
  • the “store to be settled” means a store to be settled (store in an unconfirmed state before settlement). In other words, if the store that is going to make payment has made payment or authentication for it in the past, it means omitting authentication for the convenience of the user.
  • the terminal 20 includes, by way of example and not limitation, the history of the calculated position stored in the calculated position history data 288 and the latest calculated position, and the settlement date and time stored in the settlement history data. Can be obtained, and it can be determined whether or not the calculated position corresponding to the latest calculated position exists in the calculated positions corresponding to the same date and time as the past settlement date and time.
  • the setting store can be basically set on the server 10 side.
  • the server 10 side may statistically total stores that are frequently used by users and set them as set stores. This means that authentication is omitted in stores that are frequently used by users to improve user convenience.
  • the user of the terminal 20 can cause the terminal 20 to set a store that the user frequently uses as a set store. Further, for example, the user of the terminal 20 sets a store near a home as a set store as a store set as a store in a specific type of industry (for example, a convenience store), but stores other stores as a risk store. It is also possible not to set as.
  • the terminal 20 is, for example, without limitation, the history of the calculated position stored in the calculated position history data 288, the payment store name stored in the payment history data, and the store data 2855.
  • the store information stored in the store is acquired, and it is determined whether or not the calculated position corresponding to the latest calculated position exists in the calculated positions corresponding to the same date and time as the settlement date and time at the set store in the past. You can
  • the store to be settled is a store of the first specific industry” is defined.
  • the first specific business category is defined as a business category that many users routinely use, such as “convenience store” and “supermarket”. When making payments at these stores, this means omitting authentication for the convenience of the user.
  • the terminal 20 is, for example, without limitation, the history of the calculated position stored in the calculated position history data 288, the payment store name stored in the payment history data, and the store data 2855.
  • the first specific industry flag stored in and matches the latest calculated position among the calculated positions corresponding to the same date and time as the past settlement date and time at the store with the first specific industry flag “ON”. It is possible to determine whether or not there is a calculated position to be calculated.
  • the terminal 20 is stored in the settlement history data of the settlement data 2853 in the storage unit 28 and the current date and time based on the clocked time counted by the clock unit 29A, as an example and not by way of limitation. Whether the settlement date and time that is present and the second specific industry flag stored in the store data 2855 are acquired, and whether the current date and time exceeds the set time from the settlement date and time at the store with the second specific industry flag “ON” Can be determined.
  • condition category No. “SP3” is a category of “amount of money”, and the authentication skip condition of the condition Nos. “SP3-1” to “SP3-3” is included as an example without limitation.
  • the “one day upper limit set amount” is an upper limit set amount which is a threshold for the total amount of the settlement amount (settled amount) already settled in the day. In other words, if the total amount of payment already settled in the day does not exceed the daily maximum set amount, it means that authentication is omitted for the convenience of the user.
  • the terminal 20 is, for example and not by way of limitation, the total amount of the daily upper limit set amount stored in the settlement data 2853 and the daily settlement amount specified from the settlement history data. It is possible to determine whether or not the total amount exceeds the daily upper limit set amount by acquiring and.
  • the balance is less than or equal to the set amount (or less than the set amount) and the auto charge setting is OFF" is defined as the authentication skip condition of the condition number "SP3-2".
  • the set amount of money can be set in advance by the user of the terminal 20 without limitation. This is because if the balance is less than or equal to the set amount (or less than the set amount), the user cannot purchase a high-priced product by payment, and the risk is low. Omit authentication.
  • the auto charge setting is “ON”, the IMS money is automatically replenished, and the user can purchase a large amount of merchandise by payment, which poses a risk. Therefore, in addition to the balance being less than or equal to the set amount (or less than the set amount), the auto-skip setting is “OFF” as a condition for the authentication skip.
  • the authentication process will not be skipped even if the balance is less than (or less than) the set amount.
  • the automatic charge setting OFF may be excluded from the authentication skip condition of the condition No. “SP3-2”, and the balance may be set to be equal to or less than the set amount (or less than the set amount). In other words, even if the auto charge setting is “ON”, the authentication process does not necessarily have to be required. If the auto charge is “ON”, the balance is equal to or less than the set amount (or less than the set amount). For example, the authentication process may be performed or the authentication process may not be performed.
  • the terminal 20 acquires the balance and the auto-charge setting stored in the payment data 2853 as an example and not a limitation, and the balance is equal to or less than the set amount (or less than the set amount). Moreover, it is possible to determine whether or not the auto charge setting is “OFF”.
  • the terminal 20 is, for example, without limitation, the settlement frequency and the settlement amount calculated from the settlement history data stored in the settlement data 2853, and the threshold stored in the storage unit 28. It is possible to acquire the frequency and the threshold amount and determine whether the settlement frequency exceeds the threshold frequency and whether the settlement amount exceeds the threshold amount.
  • the above authentication skip condition may or may not be based on the number of payments made by IMS money (the number of payments) instead of the condition based on the frequency of payments made by IMS money (settlement frequency). Good.
  • the payment frequency may be within a proper range
  • the number of times of settlement may be within a proper range
  • the payment amount may be within a proper range. May be.
  • the planned payment amount is less than or equal to the set amount (or less than the set amount)” is set.
  • the set amount of money is set in a range such as "10,000 yen” or "20,000 yen” that is not so high as the amount of money that is settled at once, in light of common sense and common sense. be able to.
  • “Scheduled payment amount” means an amount to be settled from now on (amount in an unconfirmed state before settlement). That is, when the amount of money to be settled is not so high, it means that the authentication is omitted for the convenience of the user.
  • the terminal 20 obtains the planned settlement amount from the server 10 as an example and not by way of limitation, and determines whether the planned settlement amount is less than (or less than) the set amount. You can
  • the terminal 20 executes the authentication skip determination process at the timing after receiving the terminal display code from the server 10. However, at this timing, the terminal 20 has not yet acquired the settlement schedule information from the server 10, and the planned settlement amount is unknown. Therefore, in the present embodiment, the authentication skip condition of condition No. “SP3-4” is not applicable to the payment type “display terminal code” and is applicable only to the payment type “read terminal code” “ ⁇ ”. And
  • condition category No. “SP4” is a “product” category, and includes, for example and without limitation, authentication skip conditions of condition Nos. “SP4-1” and “SP4-2”.
  • the planned purchase product is a daily consumer good
  • the “purchased product” means a product (a product in an undecided state before payment) that is scheduled to be purchased after payment. That is, if the product that is scheduled to be settled and purchased is a daily consumer product, it means that authentication is omitted for the convenience of the user.
  • the terminal 20 In order to determine these authentication skip conditions, the terminal 20 needs to acquire information about the product to be purchased. However, in the present embodiment, the information regarding the planned purchase product is not transmitted from the server 10 to the terminal 20 for both the payment types “display terminal code” and “read terminal code”. Therefore, the terminal 20 cannot determine the authentication skip condition included in the condition category No. “SP4 (product)”.
  • the success or failure of the authentication skip conditions of condition Nos “SP4-1” and “SP4-2” is determined using a method described below as an alternative method.
  • the terminal 20 reads the terminal reading code, and then accesses the settlement page based on the settlement page URL included in the terminal reading code,
  • the store ID and the sales amount associated with this payment page URL are acquired from the server 10.
  • the store identified by the store ID acquired from the server 10 is a store of the first specific industry and the sales amount is less than or equal to the threshold amount (or less than the threshold amount)
  • the terminal 20 purchases the planned product. Is a consumer product.
  • the terminal 20 reads the terminal reading code, then accesses the payment page in the same manner as above, and stores in the shop associated with the payment page URL.
  • the ID and the sales amount are acquired from the server 10.
  • the terminal 20 determines whether or not the payment store ID and the payment amount stored in the payment history data include the payment store ID and the payment amount that respectively match the store ID and the sales amount acquired from the server 10. It is determined that if there is a match, it is determined that there is a purchase history of the planned purchase product.
  • condition category No. “SP5” is a “security” category, and includes, for example and without limitation, the authentication skip condition of the condition No. “SP5-1”.
  • Terminal locked or payment application locked is defined as the authentication skip condition for condition number “SP5-1”. This is to unlock the terminal unlock password and payment in order to release these locked states when the OS (Operating System) side of the terminal 20 is locked or the payment application side is locked. Authentication is required by entering the application unlock password. Therefore, in order to improve the convenience of the user, it means that authentication for payment is unnecessary.
  • the terminal 20 includes, for example and without limitation, information on whether the OS of the terminal 20 is locked by the OS stored in the terminal data 286 and the payment application side stored in the payment application data 285. It is possible to determine whether or not the terminal is locked or the payment application is locked by acquiring the information regarding whether or not the lock is performed.
  • the condition category No. “SP6” is a category of “authentication setting”, and includes, for example and without limitation, the authentication skip condition of the condition No. “SP6-1”.
  • terminal side authentication setting OFF or payment application side authentication setting OFF is defined.
  • Authentication on the terminal side is various kinds of authentication required by the user on the terminal 20 side, including authentication of the user himself/herself.
  • the authentication on the payment application side is authentication required by the user when performing payment using the payment application. This means that the authentication is omitted if the user of the terminal 20 has set the terminal 20 to omit the authentication, or if the payment application side has made the setting to omit the authentication. ..
  • the terminal 20 stores, for example, without limitation, the terminal-side authentication setting stored in the terminal data 286 and the condition stored in the authentication skip condition user setting data of the payment data 2853.
  • the condition-specific setting flag of No "SP6-1" is acquired, and it is determined whether or not at least one of the terminal-side authentication setting and the payment application-side authentication setting is "OFF". can do.
  • condition skip conditions “SP3-3”, “SP3-4”, “SP4-1” and “SP4-2” are skipped. Is set to not applicable “x”, and is applied to other authentication skip conditions is set to " ⁇ ".
  • the reason why the authentication skip condition of condition No. "SP3-3" is not applied is "X".
  • the terminal 20 cannot acquire the information about the expected payment amount, and the expected payment amount is This is because it cannot be determined whether or not it is within the appropriate range.
  • the determination whether the planned settlement amount is within the proper range may be omitted or may be omitted. ..
  • the reason why the authentication skip condition of the condition number “SP3-4” is “not applicable” is that the terminal 20 cannot acquire information about the planned payment amount and the planned payment amount is less than or equal to the set amount (or set). This is because it cannot be determined whether or not the amount is less than the amount.
  • the authentication skip condition of condition Nos. "SP4-1" and “SP4-2” is not applied "X" in the payment type "terminal code display", as described above. Because it is not possible to obtain information about planned products, it is not possible to determine whether the purchased product is a consumer product or whether there is a purchase history of the planned product. is there.
  • the payment type “read terminal code” is not applicable to the authentication skip conditions of condition Nos. “SP4-1” and “SP4-2” in principle, but is not applicable. Since it can be applied by an alternative method, "x ( ⁇ )" is defined.
  • “importance” which is an index value indicating the degree of importance of the authentication skip condition (“priority indicating the degree to which the authentication skip condition is preferentially applied” It can be said that the “degree”) is set for each payment type.
  • the importance is not limited and is represented by three levels from “A” to “C”, and the importance is determined so that “A” has the highest importance and “C” has the lowest importance. Has been.
  • the payment type “display terminal code” is not limited to the condition numbers “SP1-1”, “SP2-1”, “SP2-4”, “SP3-1”, “SP3-”.
  • the importance level “A” is set for the authentication skip conditions of "2", “SP5-1”, and “SP6-1”, and the importance level is set for the authentication skip conditions of condition numbers "SP2-2" and "SP2-3”.
  • “B” is defined, and the importance level “C” is defined as the authentication skip condition of condition number “SP1-2”.
  • “- (none)” is set as the importance level. Has been.
  • the setting of the above importance is merely an example, and it goes without saying that the setting can be changed appropriately.
  • the application/non-application or importance is defined for each authentication skip condition (for each condition No), but instead of this, the application/non-application or importance for each authentication skip condition category (condition category No) is set. May or may not be set in advance.
  • the importance is set in association with the authentication skip condition, but the setting of the importance is not an indispensable requirement, and the importance may not be set. That is, in the above authentication skip condition data 2851, the column of importance may not be provided.
  • the authentication skip determination process by way of example and not limitation, the success or failure of the authentication skip condition is determined in an arbitrary order, and it is determined that the authentication process is skipped when any of the authentication skip conditions is satisfied. You can do it.
  • the information indicated by the category of the authentication skip condition in the above authentication skip condition data 2851 and the information used for the determination of each authentication skip condition included in each category are information related to IMS money (an example of electronic money, not limitation). include.
  • the category of “SP1 (time)” includes information about time when payment is made by IMS money, but this information can be said to be information about IMS money in a broad sense.
  • the category of “SP2 (store/place)” includes information about a place where payment is made with IMS money and information about a store where payment is made with IMS money. It can be said that the information is about IMS money.
  • the category of “SP3 (amount of money)” includes information about the amount of IMS money, but this information can be said to be information about IMS money in a broad sense.
  • the category of “SP4 (commodity)” includes information about a product purchased by IMS money, but this information can be said to be information about IMS money in a broad sense.
  • FIG. 3-9 is a diagram showing an example of the data structure of the payment data 2853.
  • the payment data 2853 includes a user ID, an authentication password, a payment application unlock password that is a password for unlocking the locked state of the payment application, an IMS point, a balance, a daily maximum set amount, and an auto.
  • the charge setting, the payment history data, the authentication skip condition setting, and the authentication skip condition user setting data are stored.
  • the payment history data stores the same data as the payment history data stored in the payment management data of this user ID, which is managed by the payment management database 157 of the server 10.
  • this payment history data includes the payment date and time, the payment shop ID, the payment shop name, and the payment amount after the payment is made by the server 10 from the server 10 to the terminal 20.
  • the history is stored as payment history data.
  • the authentication skip condition setting is a setting related to the authentication skip condition used by the own terminal 20 for the authentication skip determination.
  • the authentication skip condition setting includes, for example and without limitation, “user setting” and “automatic setting”.
  • the “user setting” is a setting for performing the authentication skip determination by applying the authentication skip condition determined based on the user's selection/determination operation of the terminal 20 from the authentication skip conditions defined in the authentication skip condition data 2851. is there.
  • the “automatic setting” is a setting for performing the authentication skip determination by using the authentication skip condition automatically determined by the terminal 20 from the authentication skip conditions defined in the authentication skip condition data 2851.
  • the authentication skip condition user setting data is setting data relating to the above authentication skip condition setting “user setting”, and an example of the data structure thereof is shown in FIG. 3-10.
  • a condition category No, a condition No, a setting type, a condition category-specific setting flag, and a condition-specific setting flag are stored in association with each other.
  • condition category No and condition No defined in the authentication skip condition data 2851 are stored in condition category No and condition No, respectively.
  • the setting type “by condition category” is a type for the user of the terminal 20 to set an authentication skip condition to be applied for each condition category. In other words, this setting type “by condition category” is used when making a setting to apply the authentication skip condition collectively for each category.
  • the setting type “by condition” is a type for the user of the terminal 20 to set an authentication skip condition to be applied for each condition. That is, when setting the authentication skip condition individually for each condition, this setting type “per condition” is used.
  • the setting flag by condition category is a flag indicating whether or not the authentication skip condition included in the condition category No is applied when the setting type is “by condition category”. “ON” is set in association with the condition category No, and “OFF” is set in association with the condition category No for condition categories that are not applicable.
  • the condition-specific setting flag is a flag indicating whether or not to apply the authentication skip condition of the condition No when the setting type is “condition-specific”, and the condition to be applied is associated with the condition No. “ON” is set, and for a condition that does not apply, “OFF” is set in association with the condition number.
  • the category for which the condition category-specific setting flag is set to “ON” all the condition-specific setting flags are also set to “ON”.
  • FIG. 2 shows an example of functions implemented by the control unit 51 of the store code reader device 50 in the present embodiment.
  • the store code reader device 50 has a store code reader device main processing unit 511 and a store settlement processing unit 513 as functions realized by the control unit 51.
  • the store code reader device main processing unit 511 is a process for centrally controlling the store code reader device 50 according to the store code reader device main processing program 551 stored in the storage unit 55. Has the function of executing.
  • the store payment processing unit 513 has a function of executing a store payment process, which is a process related to payment at its own store, according to the store payment processing program 5511 stored in the storage unit 55.
  • FIG. 2 shows an example of information stored in the storage unit 55 of the store code reader device 50 according to this embodiment.
  • the storage unit 55 stores a store code reader device main processing program 551 which is read by the control unit 51 and executed as the store code reader device main processing.
  • the store code reader device main processing program 551 includes, as a subroutine program, a store settlement processing program 5511 read by the control unit 51 and executed as store settlement processing.
  • the store settlement process will be described later in detail using a flowchart.
  • Payment method> A payment method using the payment application according to the present embodiment will be described with reference to a display screen example displayed on the display unit 24 of the terminal 20.
  • FIG. 3-11 to FIG. 3-14 are screen diagrams for explaining the flow of payment when there is no authentication skip in the payment type “display terminal code”.
  • FIG. 3-11 is a diagram showing an example of a payment application screen displayed on the display unit 24 of the terminal 20.
  • This payment application screen is a display screen that is displayed when the payment application is activated, and the name of the payment application, "IMS Pay,” is displayed at the top of the screen.
  • a balance here, “3000 yen” is displayed in the frame below it, and a charge button for charging the amount is displayed next to the balance. Further, below that, a plurality of function icons corresponding to various functions of the payment application are displayed.
  • the icon shown as “code” is a “code icon” for acquiring the terminal display code from the server 10 when making a payment with the payment type “terminal code display”.
  • the icon shown as “code reader” is a code reader provided as a function of the payment application so that the terminal 20 can read the terminal reading code when making a payment with the payment type “read terminal code”.
  • this is a code reader icon for activating "application code reader”.
  • FIG. 3-12 is a diagram showing an example of an authentication screen displayed when the “code icon” is touched by the user of the terminal 20 on the payment application screen.
  • This authentication screen is displayed when it is not determined to skip the authentication process in the authentication skip determination process described later.
  • the message "Enter the password you are currently using.” is displayed along with the words "password” (authentication password), and the entered password is displayed below it.
  • Password display The fields and the keyboard for entering the password are displayed.
  • FIG. 3-13 is a diagram showing an example of the terminal display code screen displayed when the authentication result is “OK” in the authentication process based on the password input on the authentication screen.
  • the word "code” is displayed at the top of the screen, and below that, there is an IMS point tab for setting the payment method and whether or not to make payment using IMS points. It is displayed.
  • a terminal display code represented by a bar code and a terminal display code represented by a QR code are displayed.
  • the valid period is set to these terminal display codes as described above, and the remaining valid period time is displayed in a countdown format in association with the terminal display code.
  • the user of the terminal 20 presents the above-described terminal display code screen to the store clerk at the code cashier 60, and has the shop code reader device 50 read the terminal display code to perform payment.
  • the shop code reader device 50 accesses the payment page based on the payment page URL included in the read terminal display code and transmits the information necessary for payment.
  • FIG. 3-14 is a diagram showing an example of a payment completion screen displayed on the terminal 20 when the payment by the server 10 is completed. On this payment completion screen, you can see the details from the "Payment history” along with the text "Payment completed” in the center of the screen of the terminal display code screen in Fig. 3-13. ", and a "confirmation icon” for confirming the payment history are displayed in a pop-up format.
  • FIG. 3-15 and FIG. 3-16 are screen diagrams for explaining the flow of payment when there is authentication skip in the payment type “display terminal code”.
  • FIG. 3-15 shows the same payment application screen as in FIG. 3-11
  • FIG. 3-16 shows the same terminal display code screen as in FIG. 3-13.
  • the terminal display of FIG. 3-16 is displayed.
  • the display switches to the code screen. In other words, the display is switched from the payment application screen to the terminal display code screen without displaying the authentication screen of FIG. 3-12.
  • the payment type “read terminal code” includes two types: a case of reading a code for reading a type 1 terminal and a case of reading a code for reading a type 2 terminal. Each of these will be described.
  • FIG. 3-17 shows the same payment application screen as that shown in FIG. 3-11, showing a state where the “code reader icon” of the function icons is tapped. ing. When the user taps the code reader icon, the application code reader is activated and a reading standby screen as shown in FIG. 3-18 is displayed on the display unit 24. In this state, when the terminal 20 is moved so that the two-dimensional code is included in the frame at the center of the screen, the two-dimensional code is read by the application code reader.
  • FIG. 3-19 is a diagram showing an example of a display screen displayed on the display unit 24 when the two-dimensional code is read by the application code reader, and the first-class terminal reading code is read by the application code reader. The state is shown.
  • the terminal 20 accesses the payment page based on the URL included in the read first-class terminal reading code, and transmits information necessary for payment. To do.
  • FIG. 3-20 is a diagram showing an example of a payment page screen displayed on the display unit 24 of the terminal 20.
  • a settlement target store here, “XXX SHOP”
  • a settlement date here, “2018/10/24”
  • a planned settlement amount here, “480”
  • a payment method and an IMS point tab for setting whether or not to make a payment using IMS points are displayed below it.
  • a payment execution icon for executing the payment indicated as “payment” is displayed on the screen.
  • FIG. 3-21 is a diagram showing an example of a payment completion screen displayed when the payment execution icon is tapped by the user of the terminal 20 on the payment page screen.
  • FIGS. 3-22 to 3-24 show display screens similar to those in FIGS. 3-17 to 3-19.
  • FIG. 3-25 is a diagram showing an example of a scheduled payment amount input setting screen displayed when the terminal 20 accesses the server 10 after reading the type 2 terminal reading code.
  • a scheduled payment store here, "XXX SHOP"
  • XXX SHOP a scheduled payment store
  • An amount display field, a current balance, and a keyboard for inputting a planned settlement amount are displayed.
  • the scheduled payment amount input setting screen as shown in, for example, FIG. 3-26, the scheduled payment amount is input by the user of the terminal 20 (here, “480 yen”), and the “completion icon” displayed below it.
  • the keyboard When is tapped, the keyboard is hidden and, for example, as shown in FIG. 3-27, a payment execution icon for executing the payment, which is “payment”, is displayed.
  • a settlement completion screen is displayed as shown in 3-28, for example.
  • FIG. 3-29 to FIG. 3-32 are flowcharts showing an example of the flow of processing executed by each device in this embodiment.
  • the first payment application process which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20
  • the store payment process executed by the store payment processing unit 513 of the store code reader device 50 in order from the left side, the first payment application process, which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20, and the store payment process executed by the store payment processing unit 513 of the store code reader device 50.
  • 3 illustrates a first store payment process, which is an example, and a first payment management process, which is an example of a payment management process executed by the payment management processing unit 113 of the server 10.
  • the payment application processing unit 213 of the terminal 20 receives a user's operation for terminal payment on the input/output unit 23 (A1). Then, the payment application processing unit 213 determines the payment type based on the received terminal payment operation (A3).
  • the terminal display code acquisition processing unit 2131 uses the communication I/F 22 to send the terminal display code generation request information including the user ID to the server. 10 (A5).
  • the server 10 determines whether or not the terminal display code generation request information is received from the terminal 20 by the communication I/F 14 (C1), and if it is determined that the terminal display code generation request information is received (C1; Yes), the terminal display code generation is performed.
  • the processing unit 1131 performs a terminal display code generation process (C3).
  • a terminal display code including the access information and the issued token is generated. More specifically, for example, data composed of a URL character string of a website provided by the server 10 and a token character string (eg, a parameter portion starting with a “?” symbol) is encoded. , And generate a terminal display code represented by a two-dimensional code image.
  • the user ID included in the received terminal display code generation request information and the issued token are associated and stored in the terminal display code management database 1591.
  • the terminal display code transmission processing unit 1133 transmits the generated terminal display code to the terminal 20 via the communication I/F 14 (C5).
  • the payment application processing unit 213 When the payment application processing unit 213 receives the terminal display code from the server 10 via the communication I/F 22 (A7), the payment application processing unit 213 executes the first authentication skip determination process according to the authentication skip determination processing program 2845 stored in the storage unit 28. Execute (A9).
  • FIG. 3-33 is a flowchart showing an example of the flow of the first authentication skip determination process. Note that, in order to distinguish it from the authentication skip determination process in the other embodiment, it is referred to as “first authentication skip determination process” for convenience.
  • the authentication skip determination processing unit 2135 determines the payment type (D1). If it is determined that the payment type is “display terminal code” (D1; display terminal code), the authentication skip determination processing unit 2135 determines the authentication skip condition setting stored in the payment data 2853 ( D3).
  • the authentication skip determination processing unit 2135 When it is determined that the authentication skip condition setting is the “user setting” (D3; user setting), the authentication skip determination processing unit 2135 causes the authentication skip condition user setting data stored in the payment data 2853 to be the authentication skip condition.
  • the authentication skip condition to be applied is determined based on the user setting and the application presence/absence defined in “payment type: terminal code display” of the authentication skip condition data 2851 (D5).
  • the authentication skip condition user setting In the data the “by condition category” is stored as the setting type, and the authentication skip condition included in the condition category in which “ON” is stored as the setting flag by condition category and the “by condition” as the setting type And the authentication skip condition in which “ON” is stored in the condition-based setting flag is determined as the authentication skip condition to be applied.
  • the authentication skip determination processing unit 2135 is set to “payment type: terminal code display” of the authentication skip condition data 2851.
  • the authentication skip condition to be applied is determined based on whether or not the application is applied and the degree of importance (priority) (D7).
  • the importance is “ The authentication skip condition associated with “A” or “B” is determined as the applicable authentication skip condition.
  • the authentication skip determination processing unit 2135 sets the authentication skip condition setting stored in the payment data 2853 of the storage unit 28. Is determined (D9).
  • the authentication skip determination processing unit 2135 causes the authentication skip condition user setting data authentication skip condition stored in the payment data 2853.
  • the authentication skip condition to be applied is determined based on the user setting and the payment type of the authentication skip condition data 2851: application/non-application defined for reading the terminal code (D11).
  • the authentication skip condition user setting In the data the “by condition category” is stored as the setting type, and the authentication skip condition included in the condition category in which “ON” is stored as the setting flag by condition category and the “by condition” as the setting type And the authentication skip condition in which “ON” is stored in the condition-based setting flag is determined as the authentication skip condition to be applied.
  • the authentication skip determination processing unit 2135 is set to “settlement type: read terminal code” of the authentication skip condition data 2851.
  • the authentication skip condition to be applied is determined based on whether or not the application is applied and the importance (priority) (D13).
  • the authentication skip condition associated with “B” is determined as the authentication skip condition to be applied.
  • the authentication skip determination processing unit 2135 acquires information necessary for determining each determined authentication skip condition (D15).
  • the information necessary for determining each authentication skip condition and its determination method are as described above.
  • the authentication skip determination processing unit 2135 determines whether or not the authentication skip condition is satisfied (D17). Specifically, the success or failure of each authentication skip condition determined in D5, D7, D11, or D13 is determined based on the information acquired in D15. Then, for example, when at least one authentication skip condition is satisfied, it is determined that the authentication processing is skipped, and in other cases, it is determined that the authentication processing is not skipped. Then, the authentication skip determination processing unit 2135 ends the first authentication skip determination processing.
  • the authentication skip condition in which “A” is associated with the degree of importance may or may not be determined as the authentication skip condition to be applied.
  • the authentication skip condition of importance “C” may or may not be included in the applied authentication skip condition.
  • the authentication skip condition associated with “A” in importance it is determined that the authentication process is skipped when at least one authentication skip condition is satisfied, but the importance is “B”.
  • the authentication skip condition associated with “” it may or may not be determined to skip the authentication process when all the authentication skip conditions are satisfied.
  • the payment application processing unit 213 determines whether or not it is determined to skip the authentication processing in the first authentication skip determination processing (A11). If it is determined to skip the authentication process (A11; Yes), the payment application processing unit 213 moves the process to A19.
  • the authentication processing unit 2137 performs the authentication process (A13). Specifically, the authentication screen is displayed on the display unit 24, and the user is prompted to enter the authentication password. Then, when the input authentication password matches the authentication password stored in the payment data 2853 of the storage unit 28, the authentication result is set to “OK”. On the other hand, if the authentication passwords do not match, the authentication result is set to “NG”.
  • the payment application processing unit 213 executes error processing (A17). Specifically, for example, a notification prompting the user to input the authentication password again is performed. Then, the payment application processing unit 213 returns the processing to A13.
  • the payment application processing unit 213 displays the terminal display code on the display unit 24 (A19).
  • the store settlement processing unit 513 of the store code reader device 50 accepts store settlement operation by the store clerk for the input/output unit 52 (B1). Then, the store payment processing unit 513 determines whether or not the payment type is “display terminal code” based on the received store payment operation (B3).
  • the store payment processing unit 513 performs a planned payment amount setting process (B5). Specifically, the amount of the product to be sold is set as the “scheduled payment amount” based on the amount input operation by the store clerk on the input/output unit 52.
  • the store payment processing unit 513 issues a terminal display code reading instruction notification (B7). Specifically, for example, a message instructing to read the terminal display code is displayed on the display unit 53, or a sound instructing to read the terminal display code is output from the sound output unit 56. , Inform the store clerk. In response to the terminal display code read instruction notification, the store clerk prompts the user of the terminal 20 to present the terminal display code.
  • the store settlement processing unit 513 When the terminal display code displayed on the display unit 24 of the terminal 20 in A19 is read by the code reader 58 of the store code reader device 50 (B9), the store settlement processing unit 513 performs a code information acquisition process (B11). .. Specifically, the data is decoded (decoded) from the read terminal display code to obtain various information included in the read terminal display code.
  • the store payment processing unit 513 accesses the payment page by the communication I/F 54 based on the payment page URL acquired from the read terminal display code, and as an example and without limitation, the store ID and the terminal display.
  • the second settlement request information including the token acquired from the use code and the planned settlement amount set in B5 is transmitted to the server 10 (B13).
  • the settlement management processing unit 113 When the settlement management processing unit 113 receives the second settlement request information from the store code reader device 50 via the communication I/F 14 (C9), it performs settlement processing (C11). Specifically, by way of example and not limitation, a user stored in the terminal display code management database 1591 of the storage unit 15 in association with the token included in the second payment request information received from the shop code reader device 50. Identify the ID. Then, based on the balance stored in the payment management data of the specified user ID in the payment management database 157 of the storage unit 15, it is determined whether or not the expected payment amount can be settled. Then, if the settlement is possible, the planned settlement amount is subtracted from the balance and updated, and the settlement history data is updated so that the settlement result is “success”. On the other hand, if payment is not possible, the payment result is set to “failure”. The settled amount is paid to the store directly from the IMS business operator (business operator of the payment service) or through an agent.
  • the payment management processing unit 113 determines the payment result (C13). If the settlement result is “success” (C13; success), the store settlement result information transmission processing unit 1136 uses the store I/F 14 as the store settlement success information as the store settlement result information, and the store code reader device. 50 (C15). Similarly, the terminal settlement result information transmission processing unit 1137 transmits the terminal settlement success information as the terminal settlement result information to the terminal 20 through the communication I/F 14 (C17). Then, the payment management processing unit 113 ends the first payment management processing.
  • the store settlement result information transmission processing unit 1136 uses the store settlement failure information as the store settlement result information by the communication I/F 14 and stores the store code. It is transmitted to the reader device 50 (C19). Similarly, the terminal payment result information transmission processing unit 1137 transmits the terminal payment failure information to the terminal 20 as the terminal payment result information by the communication I/F 14 (C21). Then, the payment management processing unit 113 ends the first payment management processing.
  • the store settlement processing unit 513 When the store settlement processing unit 513 receives the store settlement result information from the server 10 via the communication I/F 54 (B15), the store settlement processing unit 513 determines the settlement result (B17), and if the settlement result is “success” (B17). ; Success), and settlement success notification processing is performed (B19). Then, the shop settlement processing unit 513 ends the first shop settlement processing.
  • the store payment processing unit 513 performs payment failure notification processing (B21). Then, the shop settlement processing unit 513 ends the first shop settlement processing.
  • the settlement application processing unit 213 receives the settlement result information for the terminal from the server 10 through the communication I/F 22 (A21), it determines the settlement result (A23), and if the settlement result is “success” (A23). ; Success), and settlement success notification processing is performed (A25).
  • the payment application processing unit 213 determines whether to display the payment history (A27). Specifically, by way of example and not limitation, it is determined to display the payment history when the user's payment history confirmation operation on the input/output unit 23 is detected.
  • the payment application processing unit 213 performs the payment history display processing (A29). Then, the payment application processing unit 213 ends the first payment application processing.
  • the payment application processing unit 213 performs payment failure notification processing (A26). Then, the payment application processing unit 213 ends the first payment application processing.
  • the code reading processing unit 2133 activates the application code reader according to the user operation, and the code for reading the terminal is read.
  • a process for reading the (type 1 terminal reading code or the type 2 terminal reading code) is performed (A31).
  • the payment application processing unit 213 performs code information acquisition processing (A33). Specifically, the data is decoded (decoded) from the terminal reading code read by the application code reader to obtain various information included in the read terminal reading code.
  • the payment application processing unit 213 accesses the payment page by the communication I/F 22 based on the payment page URL acquired from the read terminal reading code (A35).
  • the settlement management processing unit 113 determines settlement schedule information according to the access to the settlement page from the terminal 20 (C33). Specifically, the terminal reading code management database 1593 is referred to, and the information stored in association with this payment page is acquired. Then, the payment management processing unit 113 transmits the payment schedule information according to the determination result to the terminal 20 via the communication I/F 14 (C35).
  • the payment management processing unit 113 when the information associated with the payment page is the information on the store that operates the first-class terminal reading code, the payment management processing unit 113 includes the planned payment store and the planned payment amount. The first-class settlement schedule information is transmitted to the terminal 20 via the communication I/14.
  • the payment management processing unit 113 when the information associated with the payment page is the information about the store that operates the second-class terminal reading code, the payment management processing unit 113 causes the second-class payment schedule information (including the scheduled payment shop). The planned settlement amount is not included.) is transmitted to the terminal 20 by the communication I/14.
  • the payment application processing unit 213 When the payment application processing unit 213 receives the payment schedule information from the server 10 via the communication I/F 22 (A37), it determines the type of the received payment schedule information (A39). Then, if the type of settlement schedule information is "second type settlement schedule information" (A39; second type), the scheduled settlement amount setting process is performed (A41). Specifically, based on the amount input operation by the user of his/her terminal 20 with respect to the input/output unit 23, the total amount of the products to be purchased is set as the “scheduled payment amount”.
  • the payment application processing unit 213 After A41, or if the type of the payment schedule information is “second type payment schedule information” (A39; first type), the payment application processing unit 213 skips the authentication skip stored in the storage unit 28. According to the determination processing program 2845, the first authentication skip determination processing is executed (A9). Then, the payment application processing unit 213 executes the processing of A11 to A17.
  • the payment application processing unit 213 transmits the first payment request information including the user ID and the payment confirmation information to the server 10 on the payment page as an example (A43). However, when the process of A41 is executed, the set estimated payment amount is also included in the first payment request information and transmitted to the server 10. Then, the payment application processing unit 213 performs the processing after A21.
  • the settlement management processing unit 113 When the settlement management processing unit 113 receives the first settlement request information from the terminal 20 via the communication I/F 14 (C37), it performs settlement processing (C11). Then, the payment management processing unit 113 shifts the processing to C13 and thereafter.
  • the store payment processing unit 513 shifts the processing to B15.
  • the case where the payment type is not “display terminal code” is the case where the payment type is “read terminal code”.
  • a store clerk instructs the user of the terminal 20 to read the terminal reading code, and the user of the terminal 20 activates the application code reader of the terminal 20 to read the terminal. Read the code for use.
  • the payment schedule information transmitted from the server 10 to the terminal 20 in step C35 of FIG. 3-31 is one type, and the type of the payment schedule information in the terminal 20 is not required to be determined.
  • the step A39 can be deleted. Further, if only the first-class terminal reading code is applied, it is not necessary to set the expected payment amount in the terminal 20, and therefore the step A41 in FIG. 3-31 can be deleted.
  • the first embodiment performs an authentication process (an example of a display process without limitation) for electronic payment (an example of payment without limitation) to a user of the terminal 20, and based on the result of the authentication process, the IMS money
  • the terminal 20 that receives the information regarding the payment by (without limitation, an example of electronic money) through the communication I/F 22 (without limitation, an example of a communication unit of the terminal) authenticates the authentication password (not limitation but the user of the terminal). Information that is different from the example of the authentication information for performing).
  • the terminal 20 performs the authentication skip determination based on the acquired information, and when the authentication skip condition is satisfied, the authentication processing is not performed, and information about the settlement result by the server 10 (not limited to, settlement related to electronic currency is related.
  • the terminal can easily receive the information about the payment by the electronic money without performing the display process regarding the execution of the authentication for the user of the terminal during the payment by the electronic money. ..
  • the terminal obtains information different from the authentication information for authenticating the user of the terminal at the time of payment by electronic money, so that the display processing is not necessary, and thus the processing load of the terminal can be reduced. ..
  • the payment since it is not necessary to perform the display process once for the payment by electronic money, the payment can be performed quickly and smoothly, and the convenience for the user can be improved.
  • the information different from the authentication password includes information about IMS money (one example of information relating to electronic money without limitation).
  • IMS money one example of information relating to electronic money without limitation.
  • the structure is shown.
  • the terminal obtains information about electronic money at the time of payment by electronic money, so that it is not necessary to perform display processing related to execution of authentication for the user of the terminal. The processing load can be reduced.
  • the above-mentioned information regarding the IMS money is information regarding the amount of the IMS money associated with the terminal 20 or the user of the terminal 20 (not limited to, but is associated with the terminal or the user of the terminal. It shows a configuration including an example of information about the amount of electronic money that is present.
  • the terminal when making a payment by electronic money, by acquiring information about the amount of electronic money, it is not necessary to perform a display process related to the execution of authentication to the user of the terminal, The processing load on the terminal can be reduced. Further, since the information regarding the amount of electronic money is associated with the terminal or the user of the terminal, the terminal can appropriately perform the processing regarding the settlement based on the information regarding the appropriate amount of electronic money.
  • the information regarding the amount of IMS money includes a configuration regarding the daily upper limit amount (an example of information regarding the setting amount of electronic money that has been set, not limitation). ..
  • the terminal does not perform the display process related to the execution of the authentication for the user of the terminal by acquiring the information about the set amount of the set electronic money when the electronic money is settled. Therefore, the processing load on the terminal can be reduced.
  • the first embodiment shows a configuration in which the terminal 20 does not perform the authentication process until the daily upper limit set amount (an example of a set amount, not a limitation) is exceeded.
  • the terminal does not display the authentication execution until the set amount of the electronic money that is set is set at the time of payment by electronic money, so that the processing load of the terminal is reduced. It is possible to improve the convenience of the user.
  • a display regarding execution of authentication may be displayed, so that the user can be alerted that the set amount of money has been exceeded.
  • the above-mentioned information about the amount of IMS money is information about the balance of IMS money associated with the terminal 20 or the user of the terminal 20 (not limited to, but is associated with the terminal or the user of the terminal. 1) showing an example of information about the balance of electronic money.
  • the terminal when making a payment by electronic money, by acquiring information about the balance of the electronic money, it is possible to avoid the display processing related to the execution of authentication for the user of the terminal, The processing load on the terminal can be reduced. Further, since the information regarding the balance of electronic money is associated with the terminal or the user of the terminal, the terminal can appropriately perform the processing regarding settlement based on the information regarding the proper balance of electronic money.
  • the first embodiment shows a configuration in which the terminal 20 does not perform the authentication process when the balance of the IMS money is less than or equal to the set amount of money or less than the set amount of money.
  • the terminal when the electronic money is settled, the terminal does not display the execution of authentication if the balance of the electronic money is less than or equal to the set amount or less than the set amount. Therefore, the processing load on the terminal can be reduced.
  • the balance of electronic money when the balance of electronic money is small, it is considered that the amount of money cannot be settled high and the risk is low. Therefore, by not displaying the execution of the authentication, it is possible to secure the security and improve the convenience of the user. It is possible to improve the sex.
  • the terminal 20 when the terminal 20 is set to auto-charge (not limited, the electronic money is automatically charged to the terminal 20), the balance of the IMS money is less than or equal to the set amount.
  • the terminal 20 shows a configuration in which the authentication process is performed when the amount is less than the set amount.
  • the electronic money of the terminal when the electronic money of the terminal is less than or equal to the set amount of money or less than the set amount of money, the electronic money is automatically deposited in the terminal. In this case, if the amount of money is small, electronic money is automatically deposited in the terminal, so that a large amount of money can be settled, which causes a risk. Therefore, it is possible to alert the user that a large amount of payment can be made by displaying a message regarding the execution of authentication.
  • the above-mentioned information about IMS money includes information about frequency or number of payments made by IMS money (not limited, information about frequency or number of payments made by electronic money). Shows.
  • the terminal when making a payment by electronic money, obtains information on the frequency or the number of payments made by electronic money, thereby performing a display process related to the execution of authentication for the user of the terminal. Since this is not necessary, the processing load on the terminal can be reduced. Further, for example, when the frequency of payment by electronic money is high or the number of times of payment is high, there is a high possibility that the same user is making payment by electronic money, and it is considered that the risk is low. By not performing this, it is possible to improve convenience for the user while ensuring safety.
  • the information about the IMS money includes the information about the final settlement date and time by the IMS money (not limited, but an example of the information about the time when the settlement is made by electronic money).
  • the terminal does not perform display processing related to the execution of authentication for the user of the terminal by acquiring information about the time when the payment is made by electronic money when making a payment by electronic money. Therefore, the processing load on the terminal can be reduced.
  • the first embodiment shows a configuration in which the terminal 20 does not perform the authentication process when it is within the set time from the final settlement date and time by the IMS money.
  • the terminal 20 does not perform the authentication process when it is within the set time from the final settlement date and time by the IMS money.
  • the terminal when the terminal is settled by electronic money, if it is within the set time from the time when the settlement by electronic money is performed, it is not necessary to display the authentication execution.
  • the processing load on the terminal can be reduced. Also, for example, if the time has not passed so much after making a payment by electronic money, the same user is likely to make a payment again, and it is considered that the risk is low, so the display regarding the execution of authentication is not performed. As a result, it is possible to improve convenience for the user while ensuring safety.
  • the information about the IMS money includes the information about the place where the settlement is made by the IMS money (not limited, the information about the place where the settlement is made by electronic money).
  • the terminal does not perform a display process related to the execution of the authentication for the user of the terminal by acquiring the information about the place where the electronic money is settled when the electronic money is settled. Therefore, the processing load on the terminal can be reduced.
  • the information about the place where the settlement is performed by the IMS money includes information about the store where the settlement is performed by the IMS money (not limited, information about the store where the settlement is performed by electronic money).
  • the structure is shown.
  • the terminal does not perform the display process related to the execution of the authentication to the user of the terminal by acquiring the information about the store that made the payment by the electronic money when the electronic money is settled. Therefore, the processing load on the terminal can be reduced.
  • the terminal 20 calculates the position information of the store where the payment is made by the IMS money (an example of information about the place where the payment is made by electronic money, not limitation), and the position calculation processing unit 217. It shows a configuration in which the authentication process is not performed based on the positional information of the terminal 20 (an example of information on the position of the terminal without limitation).
  • the terminal when making a payment by electronic money, the terminal performs a display regarding the execution of authentication based on the information about the store that made the payment by electronic money and the information about the position of the terminal. Therefore, the processing load on the terminal can be reduced.
  • the above-mentioned information about the IMS money is information about the place where the authentication for performing the settlement of the IMS money is performed (not limited to, the execution of the authentication for performing the electronic money settlement is performed. It shows a configuration including an example of the information about the place).
  • the terminal when the terminal makes a payment by electronic money, the terminal obtains information on the place where the authentication for making the electronic money payment is performed, and thus the terminal user can be authenticated. Since the display process regarding execution is not required, the processing load on the terminal can be reduced.
  • the first embodiment shows a configuration in which the information different from the authentication password includes information about a place.
  • the terminal obtains the information about the place when making a payment by electronic money, so that it is not necessary to perform the display processing related to the execution of the authentication for the user of the terminal. The load can be reduced.
  • the above-mentioned information regarding the location includes the information regarding the location of the store where the product is purchased.
  • the terminal obtains the information about the place to purchase the product at the time of payment by electronic money, so that it is not necessary to perform the display processing related to the execution of the authentication for the user of the terminal.
  • the processing load on the terminal can be reduced.
  • the information on the place where the product is purchased can be used as information for determining whether the place is a store that sells low-priced products such as daily necessities, and authentication for the user of the terminal is executed. You can use it as a guide to decide whether or not to do it.
  • the information about the place where the product is purchased includes the information about the store that sells the product.
  • the terminal obtains information about the store that sells the product at the time of payment by electronic money, so that it is not necessary to perform display processing related to the execution of authentication for the user of the terminal. The processing load on the terminal can be reduced.
  • the information about the store that sells the product can be used as information for determining whether the store sells a low-priced product such as daily necessities, and whether to authenticate the terminal user. It can be used as a guide.
  • the terminal 20 when the terminal 20 is the set store or the store of the first specific industry (an example of the first place, without limitation), the terminal 20 does not perform the authentication process.
  • the configuration is shown in which authentication processing is performed until the set time elapses from the settlement date and time at a store of a second specific industry (an example of a second place, not limited to the store) different from the store.
  • the terminal when the terminal obtains the information on the first place at the time of payment by electronic money, it does not display the execution of the authentication, but the first place different from the first place is displayed.
  • the display regarding the execution of the authentication is displayed until the set time elapses after the payment is made by the electronic currency at the second place. It is possible to prevent illegal settlement of payment by a third party who acquired the terminal when the terminal is left behind or when the user loses the terminal in the second place.
  • the first embodiment shows a configuration in which the information different from the authentication password includes information about the product.
  • the terminal obtains the information about the product at the time of payment by electronic money, so that it is not necessary to perform the display processing related to the execution of the authentication for the user of the terminal. The load can be reduced.
  • information different from the authentication password is information relating to the setting of the terminal 20 or the payment application stored in the terminal 20 (not limited to the setting of the terminal or the application stored in the terminal. It shows a configuration including an example of information).
  • the terminal acquires the information about the setting of the terminal or the application stored in the terminal at the time of payment by electronic money, thereby performing the display process regarding the execution of the authentication for the user of the terminal. Therefore, the processing load on the terminal can be reduced.
  • the information about the setting of the terminal or the application stored in the terminal is the information set by the user, the intention of the user can be respected and the convenience of the user can be improved.
  • the information different from the authentication password is the information set in the terminal 20 and indicating whether the terminal 20 is locked (not limited to, the terminal set in the terminal, 2 shows an example of a configuration including information regarding security of 1).
  • the terminal when making a payment by electronic money, obtains the information about the security of the terminal set in the terminal, thereby performing the display process regarding the execution of the authentication for the user of the terminal. Therefore, the processing load on the terminal can be reduced.
  • the information about the security of the terminal is the information related to the authentication of the user of the terminal, the convenience of the user can be improved by omitting the display process regarding the execution of the authentication of the user of the terminal.
  • information different from the above authentication password is the information of the terminal side authentication setting set in the terminal 20 or the authentication setting for payment set in the payment application stored in the terminal 20. It shows a configuration including information (including, but not limited to, an example of information regarding skipping execution of authentication, which is set in the terminal or an application stored in the terminal).
  • the terminal at the time of payment by electronic money, the terminal, or by being set to the application stored in the terminal by acquiring information about skipping the execution of authentication, Since it is not necessary to perform display processing related to the execution of authentication for the user of the terminal, the processing load on the terminal can be reduced.
  • the information different from the above authentication password includes information sent from the server 10 relating to settlement by IMS money (an example of a server that manages settlement by electronic money, without limitation). Is shown.
  • the terminal when making a payment by electronic money, obtains the information sent from the server related to the payment by electronic money, thereby performing a display process related to the execution of authentication for the user of the terminal. Since this is not necessary, the processing load on the terminal can be reduced.
  • the terminal 20 may not execute the payment process based on the information different from the authentication password, and the terminal display code for performing the payment by the IMS money (not limited, Based on the reading of the terminal display code by the code reader 58 of the store code reader device 50 (an example of a code reader without limitation) by displaying code information for performing payment by electronic money) on the display unit 24.
  • the terminal display code for performing the payment by the IMS money (not limited, Based on the reading of the terminal display code by the code reader 58 of the store code reader device 50 (an example of a code reader without limitation) by displaying code information for performing payment by electronic money) on the display unit 24.
  • a configuration in which the communication I/F 22 receives information on the settlement result by the IMS money As an example of the effect obtained by such a configuration, when the terminal makes a payment by electronic money, the code information for making a payment by electronic money displayed in the display area of the terminal is read by a code reader, You can easily receive information about payment.
  • the terminal 20 instructs the user of the terminal 20 to read the terminal display code by the code reader 58 of the shop code reader device 50 (including but not limited to reading code information).
  • a display example is displayed on the display unit 24, and information different from the authentication password is acquired based on the reading of the terminal reading code by the code reader 58 of the shop code reader device 50.
  • the terminal can notify the user of the terminal of information regarding the reading of the code information.
  • the terminal can easily acquire information different from the authentication information by the terminal only by causing the code reader to read the code information displayed in the display area of the terminal when making a payment by electronic money.
  • the first embodiment shows a configuration in which the information different from the authentication password includes a planned settlement amount (an example of information regarding the amount and total amount of products to be purchased, without limitation).
  • a planned settlement amount an example of information regarding the amount and total amount of products to be purchased, without limitation.
  • the first embodiment shows a configuration in which the terminal 20 does not perform the authentication process when the planned payment amount is less than or equal to the set amount or less than the set amount.
  • the terminal is related to execution of authentication. Since no display is performed, the convenience of the user can be improved. Further, if the total amount of purchased products is low, the risk is considered to be low. Therefore, by not displaying the execution of authentication, it is possible to improve the convenience of the user while ensuring safety. ..
  • the authentication process is performed. Shows no configuration.
  • the terminal matches the product purchased by the user of the terminal more than once during the payment by electronic money, the terminal does not display the execution of the authentication, which is convenient for the user. It is possible to improve the sex. Further, since it is considered that the risk is low if the same product is purchased, it is possible to improve the convenience of the user while ensuring safety by not displaying the authentication execution.
  • the first embodiment is different from the authentication password transmitted from the server 10 that manages the settlement by the IMS money by the terminal 20 based on the reading of the terminal display code (an example of code information without limitation).
  • the structure which receives and acquires information by communication I/F22 is shown.
  • the terminal simply reads the code information at the time of payment by electronic money, and easily transmits information different from the authentication information transmitted from the server managing the payment by electronic money. Can be obtained.
  • the information regarding the settlement by the IMS money includes the information transmitted from the server 10 (an example of an external server without limitation) indicating that the settlement by the IMS money has been performed.
  • the structure is shown. As an example of the effect obtained by such a configuration, it is possible for the terminal to obtain the effect that the information indicating that the settlement has been made by electronic money can be obtained from the external server.
  • the terminal 20 that authenticates the payment of the user of the terminal 20 acquires the information necessary for performing the authentication skip determination, and the acquired information does not satisfy the authentication skip condition
  • the terminal 20 Authentication processing is performed on the user and the information regarding the IMS money is received by the communication I/F 22 based on the result of the authentication processing.
  • the communication I/F 22 receives the information about the IMS money without performing the authentication process for the user of the terminal 20.
  • the type of authentication for the user of the terminal 20 is password authentication, and the display process relating to the execution of this authentication is the process of displaying the authentication screen for inputting the authentication password, but the present invention is not limited to this.
  • the type of authentication for the user of the terminal 20 is biometric authentication such as face authentication, fingerprint authentication, and voice authentication, and the process of displaying an authentication screen necessary for performing these biometric authentication is performed by the terminal. This may or may not be display processing related to the execution of authentication for the user.
  • the process of displaying the authentication screen in the authentication process for acquiring the account such as the user ID for using the payment service may be the display process related to the execution of the authentication for the user of the terminal. It may or may not be. Then, when the result of this authentication processing is “OK”, the terminal 20 may receive the information of the account for using the payment service from the server 10 as the information regarding the payment by electronic money. Good or not.
  • the terminal can easily display information related to payment by electronic currency without performing display processing related to execution of authentication to the user of the terminal in the same manner as for authentication different from authentication using an authentication password. Can be received.
  • the terminal can easily acquire the information necessary for using the payment service as information related to payment by electronic currency, without performing display processing related to execution of authentication for the user of the terminal.
  • IMS money In the first embodiment, electronic money is described as IMS money, but the present invention is not limited to this.
  • the electronic money is not limited to IMS money, and examples thereof include, but are not limited to, so-called virtual currency, in-game currency, gift codes sent (presented) from users of other terminals 20 as gifts, and various types of IMS points described above.
  • the terminal display code and the terminal reading code have been described as two-dimensional codes, but the present invention is not limited to this. At least one of the terminal display code and the terminal reading code may or may not be the above-mentioned one-dimensional code (barcode as an example, not limitation) as an example without limitation.
  • At least one of the terminal display code and the terminal reading code is a character code represented by a character string of information stored in the code, and the terminal display code is read by a camera in a store to perform character recognition.
  • the terminal reading code may or may not be acquired by performing character recognition by reading the terminal reading code with the camera 27 of the terminal 20 or the like.
  • the payment information transmitted from the server 10 is stored in the storage unit 28 of the terminal 20 as payment history data, and the terminal 20 determines whether to skip the authentication based on the payment information included in the payment history data.
  • the present invention is not limited to this.
  • the terminal 20 may or may not request the information necessary for the authentication skip determination from the server 10 and perform the authentication skip determination based on the information acquired from the server 10.
  • store location information is included in the store data 2855 delivered from the server 10 to the terminal 20, and the terminal 20 is calculated by the store location information included in the store data 2855 and the location calculation processing unit 217.
  • the authentication skip determination may or may not be performed based on the position information of the terminal 20 (hereinafter, referred to as “terminal position information”).
  • the latest calculated position of the terminal 20 is It is possible to determine whether or not the position matches the position of the set store stored in the store data 2855. The same applies to other authentication skip conditions regarding the store/place.
  • the terminal can easily determine the success or failure of the authentication skip condition based on the terminal position information calculated by the terminal 20 of itself and the store position information acquired from the outside. it can.
  • the one-day upper limit set amount is set as the upper limit set amount as a threshold value for the total amount of the settled amount (settlement amount) in the day, but the present invention is not limited to this.
  • the daily maximum set amount is the sum of the total amount of the amount settled (settled amount) in the day and the amount to be settled (settlement amount). It may or may not be the upper limit set amount of money as the threshold amount of money.
  • the upper limit setting amount does not necessarily have to be the upper limit setting amount for one day, and may be the upper limit setting amount for a predetermined period in the past (past 1 week, past 2 weeks, past 1 month, etc.). You don't have to.
  • the upper limit set amount is set as the amount to be settled (scheduled amount to be settled), that is, the amount to be settled at one time, and the skipped authentication is set as “the planned settled amount is less than (or less than) the set amount”.
  • the authentication skip determination may be performed based on the condition. By doing so, the authentication process can be skipped when the user of the terminal 20 purchases a low-priced product.
  • the convenience of the user can be improved by not displaying the authentication execution until the payment amount for one time exceeds the set amount.
  • the authentication skip condition of condition number “SP1-1” “current date and time is within set time from final settlement date and time” is “current date and time is within set time from final authentication date and time”.
  • condition number “SP1-1” “current date and time is within set time from final settlement date and time”
  • current date and time is within set time from final authentication date and time”.
  • final authentication date and time is not necessarily limited to the date and time when the settlement authentication was last performed, and is not limited to, for example, the inter-personal remittance of IMS money described later in the fourth embodiment.
  • the date and time when a different type of authentication from the payment authentication, such as the date and time when the authentication was performed, can be set as the “final authentication date and time” in the above authentication skip condition.
  • the “final settlement date and time” in the authentication skip condition of the condition number “SP1-1” is the latest date and time when the IMS money was charged by the user, and the settlement The date and time of the latest settlement-related operation, which is the latest date and time when a user operation related to settlement is performed in the application, can also be used. If the time has not passed so much since the IMS money was last charged, it is highly likely that the user has charged the IMS money for settlement, so it is reasonable to skip the authentication process. Also, if not much time has passed since the last user operation related to payment in the payment application, there is a high possibility that the user planned the payment and performed the operation. It is reasonable to skip.
  • the “set time zone” in the authentication skip condition of the condition number “SP1-2” can be a concept including a specific day of the week and a specific date. For example, without limitation, Saturday or Sunday may be set as the specific day of the week. This is because on Saturdays and Sundays, there are many users who go out for shopping or eating, and there is a tendency that there are more opportunities for payment. Moreover, as a specific date, three days of Christmas (including Christmas Eve) and New Year may be set. This is because there are many users who go out for the purchase of gifts or dinner at Christmas, and many users go out for the first sale on the day of Christmas, and there is a tendency that there are many opportunities for settlement.
  • the user of the terminal 20 may use his/her terminal 20 by a third party to purchase a high-priced product for payment and redeem it. Therefore, as an example and not by way of limitation, it is possible to add an authentication skip condition that "the settlement-scheduled store is not a store that sells highly-convertible products". Highly cash-convertible products are, for example, products such as jewelry and watches, and if payment is to be made at a store (jewelry store, watch store, etc.) selling such products, the terminal 20 is used. It is possible not to skip the authentication process.
  • weather and weather-related authentication skip conditions For example, on a rainy day or a snowy day, the number of users who use public transportation increases, and the risk of misplacement of the terminal 20 increases. Therefore, as a non-limiting example, it is possible to add an authentication skip condition that "the weather of the day is neither rain nor snow" so that the authentication process is not skipped on a rainy day or a snowy day.
  • the terminal is not limited to the case where the payment authentication is performed within the set time from the date and time when the payment authentication is last performed, Even when the different types of authentication are within the set time from the date and time when the authentication was last performed, by not displaying the execution of the authentication, the convenience of the user can be further improved.
  • the convenience of the user can be further improved by not displaying the authentication execution.
  • the terminal 20 performs the first authentication skip determination process at a timing before transmitting the terminal display code generation request information to the server 10 (before A5 in FIG. 3-29). It may or may not be.
  • the server 10 immediately transmits the terminal display code to the terminal 20.
  • the authentication skip determination process may or may not be performed before the terminal display code is transmitted from the server 10 to the terminal 20.
  • the server 10 After receiving the terminal display code generation request information transmitted from the terminal 20 (C1 in FIG. 3-29; Yes), the server 10 sends the terminal 20 the authentication request information for requesting the authentication. Send. Then, the terminal 20 performs the first authentication skip determination process at the timing after receiving the authentication request information from the server 10.
  • the terminal 20 skips the authentication process and sends authentication skip execution information indicating that the authentication process has been skipped to the server 10.
  • the terminal 20 performs the authentication process, and when the authentication result is “OK”, the authentication success information indicating that the authentication is successful is transmitted to the server 10.
  • the server 10 receives the authentication skip execution information or the authentication success information from the terminal 20, and then performs the terminal display code generation process to generate the terminal display code (C3 in FIG. 3-29). ), and transmits the generated terminal display code to the terminal 20 (C5 in FIG. 3-29).
  • the server 10 receives the terminal display code generation request information transmitted from the terminal 20 (C1 in FIG. 3-29; Yes)
  • the server display code generation processing is performed to execute the terminal display code. May be generated (C3 in FIG. 3-29), and then the authentication request information may be transmitted to the terminal 20.
  • the timing for performing the authentication skip determination process on the terminal 20 side can be roughly divided into any of three timings as described above.
  • the terminal at the time of any one of a plurality of timings, based on information different from the authentication information for authenticating the user of the terminal at the time of payment by electronic money. It is possible to determine whether or not to execute the display process related to the authentication of the user.
  • the information about the planned purchase product is not transmitted from the server 10 to the terminal 20, and the terminal 20 acquires the information about the planned purchase product.
  • the terminal 20 may acquire the information of the product to be purchased by the following method, for example.
  • a camera provided as a function of the payment application (hereinafter referred to as “application camera”), or an imaging device (or an imaging unit) such as the camera 27 provided in the terminal 20. )
  • the software for allowing the type of the product to be identified based on the captured image captured by the above) is stored in the storage unit 28 of the terminal 20.
  • the terminal 20 activates the application camera or the camera 27 according to the user operation, and purchases the product to be purchased. Take an image of. That is, the user of the terminal 20 shoots the image of the product to be purchased with the application camera or the camera 27 at the code register 60 of the store. Then, the terminal 20 performs product type identification processing for identifying the type of product from the captured image (hereinafter, referred to as “captured image”). Then, the terminal 20 performs the process of “A3; terminal code display to A7” and then performs the first authentication skip determination process (A9).
  • the terminal 20 activates the application camera or the camera 27 according to the user operation, and purchases. Take an image of the planned product. Then, the terminal 20 performs a product type identification process for identifying the product type from the captured image. Then, the terminal 20 performs the processing of “A3; terminal code reading to A41” and then performs the first authentication skip determination processing (A9).
  • FIG. 3-34 is a diagram showing an example of the authentication skip condition data 2851 in this case.
  • This data structure is the same as the authentication skip condition data 2851 in FIG. 3-8, but the part surrounded by a thick black frame is different.
  • the authentication skip condition “Condition No. SP4-1” “Product to be purchased is daily consumer goods” is set as “Applicable”.
  • ⁇ is defined. This is because it is possible to identify the type of product at the terminal 20 by using the above-described method. Therefore, it is possible to determine whether the planned purchase product is a daily consumer goods based on the identified product type. This is because it can be determined. Further, the importance level “B” is set for the payment type “display terminal code”, and the importance level “A” is set for the payment type “read terminal code”.
  • the success or failure of the authentication skip condition of condition Nos “SP4-1” and “SP4-2” is determined by an alternative method.
  • the terminal 20 can identify the type of the product to be purchased, and thus the success or failure of these authentication skip conditions can be determined based on the identification result.
  • the store code reader device 50 is provided with a camera, and the camera of the store code reader device 50 allows the user of the terminal 20 It is also possible to take an image of the product to be purchased.
  • the store code reader device 50 identifies the type of the planned purchase product based on the captured image captured by the camera, and transmits the identified type of the planned purchase product to the terminal 20. be able to.
  • the store code reader device 50 transmits a captured image captured by a camera to the terminal 20, and the terminal 20 determines the type of the product to be purchased based on the captured image received from the store code reader device 50. It is also possible to identify.
  • This modification shows a configuration in which the information different from the authentication password described above includes information on merchandise sold in a store (an example of information on merchandise, not limitation).
  • the terminal does not have to perform the display processing related to the execution of the authentication for the user of the terminal based on the information about the product, so that the processing load of the terminal can be reduced.
  • the terminal 20 acquires a captured image of a product to be purchased, which is captured by the application camera or the camera 27 of the terminal 20 (an example of an imaging device without limitation), and based on the acquired captured image.
  • the terminal does not perform the display related to the execution of the authentication based on the image of the product taken by the imaging device, so that the processing load of the terminal can be reduced.
  • the product identified by the image captured by the image capturing device is a product that has a purchase history in the past or a product of a specific type, by not displaying the authentication execution, The convenience can be improved.
  • the present modification shows a configuration in which the information different from the above-described authentication password includes information on products to be purchased (an example of information on products to be purchased by the user of the terminal, without limitation).
  • the terminal does not have to perform display processing related to the execution of authentication for the user of the terminal based on the information about the product that the user of the terminal purchases, thus reducing the processing load of the terminal. Can be reduced.
  • this modification shows a configuration in which the authentication process is not performed when the information of the purchase planned product of the user of the terminal 20 is acquired and it is determined that there is a purchase history of the purchase planned product.
  • the terminal does not display the execution of the authentication, and thus the processing load of the terminal can be reduced. it can. Further, since it is considered that the risk is low if the same product is purchased, it is possible to improve the convenience of the user while ensuring safety by not displaying the authentication execution.
  • the present modification shows a configuration in which the authentication process is not performed when the information of the purchase planned product of the user of the terminal 20 is acquired and it is determined that the purchase planned product is a daily consumer product.
  • the display regarding execution of authentication is not displayed, so that the processing load of the terminal can be reduced.
  • it is considered that the risk is low if the consumer goods are purchased, it is possible to improve the convenience of the user while ensuring the safety by not displaying the authentication execution. ..
  • a method of identifying the product purchased by the user of the terminal 20 and the product type thereof with the terminal 20 as an example without limitation, a method using short-range wireless communication or contactless communication is applied. You can also do it.
  • an RF tag for example, an IC tag
  • the terminal 20 is provided with a reader/writer compatible with an RF tag. Then, the terminal 20 scans the RF tag embedded in the product purchased by the user with a radio wave and acquires the product identification information and the product type identification information stored in the RF tag, thereby purchasing the product purchased by the user and the product purchased by the user. Identify the product type.
  • the shop side requests the server 10 to skip the authentication process of the terminal 20, and the server 10 causes the server 10 to skip the authentication process (hereinafter referred to as “authentication skip information”). May or may not be transmitted to the terminal 20.
  • the terminal 20 can be caused to skip the authentication processing based on the authentication skip information sent from the server 10. Therefore, for example, even when a person who purchases a product using another person's terminal 20 or makes a payment by a person who wants to be provided with the service makes a payment by skipping the authentication process at the terminal 20.
  • the problem of being broken can also occur.
  • FIG. 3-35 is a flowchart showing an example of the processing flow of each device in this case, and is a diagram showing a processing portion in the processing described in the first embodiment when the payment type is “read terminal code”. This is a processing portion extracted from 3-31. It should be noted that the same steps as those in the already-explained flowcharts are designated by the same reference numerals, and the description thereof will be omitted.
  • the store payment processing unit 513 determines that the payment type is not “display terminal code” in B5, that is, the payment type is “read terminal code” (B3; No), authentication is skipped by the communication I/F 54.
  • the request information is transmitted to the server 10 (B51).
  • the store settlement processing unit 513 associates the store ID with the type 1 terminal reading code by way of example and not limitation.
  • Authentication skip request information including the sales amount information of the product to be sold as a product is transmitted to the server 10.
  • the store payment processing unit 513 transmits the authentication skip request information including the store ID to the server 10 by way of example and not limitation.
  • the authentication skip request information is information that requests the server 10 to generate authentication skip information for causing the terminal 20 to skip the authentication process.
  • This authentication skip request information can be transmitted to the server 10 by the shop code reader device 50 based on the approval of the shop server 70, for example and without limitation.
  • the shop code reader device 50 will be described as transmitting authentication skip request information to the server 10, but instead of this, the shop server 70 may transmit authentication skip request information to the server 10. Good or not.
  • the settlement management processing unit 113 When the settlement management processing unit 113 receives the authentication skip request information from the store code reader device 50 via the communication I/F 14 (C51), it performs the terminal reading code generation determination process (C53).
  • the store from which the authentication skip request information is transmitted is a member store. Further, when the received authentication skip request information includes the sales amount information of the product to be sold in association with the type 1 terminal reading code, the sales amount indicated by the sales amount information is within an appropriate range (limited As an example, whether or not it is below a threshold amount of money (depending on the type of business of the store, the product to be sold, product type, etc., for example, “1000 yen or less”, “2000 yen or less”, “3000 yen or less”, etc.) If these conditions are satisfied, it is determined that the terminal reading code is to be generated, whereas if these conditions are not satisfied, it is determined that the terminal reading code is not to be generated.
  • the payment management processing unit 113 performs the terminal reading code generation processing (C57).
  • the payment management processing unit 113 In this terminal reading code generation processing, the payment management processing unit 113 generates a terminal reading code including access information. More specifically, for example, the character string of the payment page URL is encoded (encoded) and converted into a graphic to generate a terminal reading code represented by a two-dimensional code image. In addition, the payment management processing unit 113, in association with the store ID of this store, the sales amount (only for stores that operate the code for reading the first-class terminal), the payment page URL, and the presence or absence of authentication skip (authentication here). It is stored in the terminal reading code management database 1593 of the code management database 159 in association with the skip “present”).
  • the payment management processing unit 113 transmits the generated terminal reading code to the store code reader device 50 which is the transmission source of the authentication skip request information by the communication I/F 14 (C59).
  • the payment management processing unit 113 informs the store code reader device 50 by the communication I/F 14 that the terminal reading code cannot be generated. (C61). Then, the payment management processing unit 113 shifts the processing to C63.
  • the store payment processing unit 513 determines whether or not the terminal reading code is received from the server 10 by the communication I/F 54 (B53), and if it is determined (B53; Yes), the received terminal reading code is used. The code is displayed on the display unit 53 (B55).
  • the settlement application processing unit 213 of the terminal 20 reads the terminal reading code with the application code reader (A51). Specifically, one of the terminal reading code displayed on the shop and the terminal reading code displayed on the shop code reader device 50 at B55 is read. Then, the payment application processing unit 213 performs the processing of A33 and A35.
  • the payment management processing unit 113 determines the payment schedule information according to the access to the payment page from the terminal 20 (C63). Specifically, the terminal reading code management database 1593 is referred to, and the information stored in association with the payment page URL of this payment page is acquired. Then, the payment management processing unit 113 transmits the payment schedule information (authentication skip “yes” or “no”) according to the determination result to the terminal 20 through the communication I/F 14 (C65).
  • the payment management processing unit 113 transmits the payment schedule information that does not include the authentication skip information to the terminal 20.
  • the payment management processing unit 113 when the information stored in association with the payment page URL is the information of the authentication skip “present” (in the case of the processing flow of C59 ⁇ C63), the payment management processing unit 113 outputs the authentication skip information.
  • the payment schedule information including the information is transmitted to the terminal 20.
  • the payment management processing unit 113 when the information associated with the payment page URL is the information on the store that operates the first-class terminal reading code, the payment management processing unit 113 causes the planned payment store, the planned payment amount, and the authentication skip.
  • the first-class settlement schedule information including the information is transmitted to the terminal 20.
  • the payment management processing unit 113 when the information associated with the payment page URL is the information on the store that operates the second-class terminal reading code, the payment management processing unit 113 includes the second payment store and the authentication skip information.
  • the seed settlement schedule information (not including the planned settlement amount) is transmitted to the terminal 20 via the communication I/14.
  • the payment application processing unit 213 When the payment application processing unit 213 receives the payment schedule information (authentication skip “Yes” or “No”) from the server 10 via the communication I/F 22 (A53), the payment application processing unit 213 performs the processes of A39 and A41, and then performs the second authentication. Skip determination processing is performed (A55). Note that, in order to distinguish it from the authentication skip determination process in the other embodiment, it is referred to as "second authentication skip determination process" for convenience.
  • the authentication skip determination processing unit 2135 determines whether the payment schedule information received from the server 10 includes the authentication skip information. In A51, when the terminal reading code displayed on the shop code reader device 50 is read, it is determined that the received payment schedule information includes the authentication skip information, while the terminal reading code displayed in the shop is read. If the application code has been read, it is determined that the received payment schedule information does not include the authentication skip information. Then, when it is determined that the received payment schedule information includes the authentication skip information, it is determined that the authentication processing is skipped. Then, the payment application processing unit 213 shifts the processing to A11.
  • the second authentication skip determination process described above for example and without limitation, when the payment authentication setting on the payment application side of the terminal 20 is “ON” or when the terminal 20 does not skip the authentication process.
  • the mode is set or the like, it is possible to prevent the authentication processing from being skipped even if the payment schedule information includes the authentication skip information.
  • the above process is a process in the case of performing the authentication skip for each store, but as an example without limitation, it is possible to perform the authentication skip for each product or product type sold in the store. Is also possible.
  • FIG. 3-36 is a diagram showing an example of the terminal reading code management database 1593 stored in the storage unit 15 of the server 10 in this case.
  • the terminal-reading code management database 1593 includes terminal-reading code management data that is generated for a store that has agreed to skip the authentication process of the terminal 20.
  • the terminal-reading code management data of each store is stored in association with the store ID of the store, the product type, the sales amount, the payment page URL, and the presence or absence of authentication skip.
  • the product types include product types such as “lunch”, “beverage”, and “gift product”, and the sales amount, the payment page URL, and the presence or absence of authentication skip are associated with each product type.
  • the product types “bento” and “beverage” are set to have “authentication skip”, and the product type “gift product” is set to have “no authentication skip”. Therefore, when the user purchases a lunch or a drink at this store, the authentication process is skipped at the terminal 20, but when the user purchases a gift item at this store, the authentication process is not skipped at the terminal 20. Become.
  • the product type “bento” is classified into a lunch box with a sales price of “200 yen”, a lunch box with a sales price of “300 yen”, and a lunch box with a sales price of “500 yen”.
  • the payment page URL and the presence or absence of authentication skip can be associated with each other.
  • the settings of the above plurality of patterns can be appropriately changed on the server 10 side depending on how the store side operates.
  • the information different from the authentication password includes the authentication skip information.
  • the terminal can skip the authentication of the user of the terminal based on the skip information for the terminal to skip the authentication of the user of the terminal. Further, it is possible to determine whether or not to skip the authentication of the user of the terminal based on the skip information, and it is not necessary to determine whether or not other conditions are satisfied, so that the processing load of the terminal can be reduced.
  • the present modification shows a configuration in which the authentication skip information is generated by the server 10 based on the authentication skip request information transmitted from the shop code reader device 50.
  • the terminal can easily skip the authentication of the user of the terminal based on the skip information generated by the server based on the request from the store that manages the product.
  • it is possible to determine whether to skip the authentication of the user of the terminal based on the skip information generated by the server, and it is not necessary to determine the success or failure of other conditions, so the processing load on the terminal can be reduced.
  • the second embodiment is an embodiment that improves the convenience of payment. More specifically, as an example and not by way of limitation, when performing payment using a payment application in the terminal 20, the server 10 performs the authentication skip determination, and when the authentication skip condition is satisfied, the user of the terminal 20 is conventionally provided with the authentication skip determination. The requested authentication process is skipped.
  • the contents described in the second embodiment can be applied to any of the other embodiments. Further, the same components as those already described are designated by the same reference numerals, and the repeated description will be omitted.
  • FIG. 4A is a diagram illustrating an example of functions implemented by the control unit 11 of the server 10 according to this embodiment.
  • the payment management processing unit 113 includes, for example and without limitation, the terminal display code generation processing unit 1131, the terminal display code transmission processing unit 1133, the store payment result information transmission processing unit 1136, and the terminal payment result information transmission.
  • an authentication skip determination processing unit 1139 is included as a functional unit.
  • the authentication skip determination processing unit 1139 is a process for determining whether or not to skip the authentication processing executed by the terminal 20 according to the authentication skip determination processing program 1515 stored in the storage unit 15 Has the function of executing.
  • the authentication skip determination process can also be referred to as an authentication necessity determination process for determining whether or not the terminal 20 needs to perform the authentication process.
  • the authentication skip determination processing unit 1139 performs the authentication skip determination processing at the timing after receiving the terminal display code generation request information from the terminal 20 in the payment type “terminal code display”, for example and not by way of limitation. Execute. Further, as an example and not limitation, the authentication skip determination processing unit 1139 executes the authentication skip determination process at the timing after receiving the first payment request information from the terminal 20 in the payment type “read terminal code”. However, the execution timing of these authentication skip determination processes can be changed as appropriate.
  • FIG. 4-2 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
  • the payment management processing program 1513 includes, as a non-limiting example, an authentication skip determination processing program 1515 read by the control unit 11 and executed as an authentication skip determination processing as a subroutine program.
  • the store registration data 155, the payment management database 157, the code management database 159, and the authentication skip condition data 156 are stored.
  • the authentication skip condition data 156 is data that defines an authentication skip condition that is a condition for causing the terminal 20 to skip the authentication process for payment.
  • the credit score data 158 is data in which a credit score representing the social trust of the user of the terminal 20 by a numerical value, a rank, or the like is stored for each terminal 20 or each user of the terminal 20.
  • the credit score is calculated or determined based on, for example and without limitation, the payment record, age, work style, and annual income of the user of the terminal 20.
  • the credit score is digitized by a score system of “0 point” to “100 point”, and the credit score “100 point” has the highest social trust of the user and the credit score “ “0 point” means that the user has the lowest social credibility.
  • FIG. 4-3 is a diagram showing an example of the data configuration of the authentication skip condition data 156 in this embodiment. This data structure is similar to the authentication skip condition data 2851 of the terminal 20, but the contents are partially different. Hereinafter, description will be made focusing on different conditions.
  • the server 10 acquires the store position information of the store to be settled from the store information registered in the store registration data 155. Further, the server 10 requests the terminal position information from the terminal 20, and receives the latest calculated position calculated by the position calculation processing unit 217 as the terminal position information from the terminal 20 and acquires it. Then, the server 10 determines whether or not the store position and the terminal position are separated by a set distance or more.
  • the information of the area (area) in which each store exists is stored in the storage unit 15 of the server 10, and the server 10 determines that there is a planned store. After determining the area to be performed, whether or not the terminal position is included in the specified area may or may not be determined.
  • the terminal 20 acquires the credit score of the user of the terminal 20 who is scheduled to make a payment from the credit scores stored in the credit score data 158. Then, it is determined whether or not the acquired credit score is 80 points or more.
  • the server 10 performs the authentication skip determination process. Therefore, the server 10 is a server for user information stored in the user registration data 153 of the storage unit 15, store information stored in the store registration data 155, payment management information stored in the payment management database 157, and the like. Information required for authentication skip determination is acquired from the information stored and managed in 10 (hereinafter referred to as “server management information”). In addition, the server 10 requests the terminal 20 for information such as position information of the terminal 20 (terminal position information) that is not managed by the server 10 and acquires the information. Then, the server 10 performs the authentication skip determination based on the acquired information.
  • condition numbers “SP2-1” to “SP2-5” condition numbers included in condition category No “SP2”
  • “3”, “SP3-4”, condition Nos. “SP4-1”, “SP4-2” conditions included in condition category No. “SP4”.
  • the reason why the authentication skip condition included in the condition category No. “SP2” is not applied is “ ⁇ ”.
  • the server 10 selects the payment planned store at the timing of performing the authentication skip determination process. This is because it cannot be grasped.
  • the authentication skip conditions of condition numbers “SP3-3” and “SP3-4” are set to “not applicable” when the server 10 performs the authentication skip determination process in the payment type “display terminal code”. This is because the planned settlement amount cannot be grasped at.
  • the authentication skip condition included in the condition category No. “SP4” is set to “not applicable” in the payment type “display terminal code” when the server 10 purchases a planned product at the timing of performing the authentication skip determination process. This is because it cannot be grasped.
  • ⁇ Process> 4-4 to P4-6 are flowcharts showing an example of the flow of processing executed by each device in the present embodiment.
  • the second payment application process which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20, and the store payment executed by the store payment processing unit 513 of the store code reader device 50.
  • the second store payment processing which is an example of the processing
  • the second payment management processing which is an example of the payment management processing executed by the payment management processing unit 113 of the server 10 are shown.
  • the payment application processing unit 213 of the terminal 20 executes the processing of A1 to A3. If the payment type is “display terminal code” (A3: display terminal code), the terminal display code acquisition processing unit 2131 executes processing of A5.
  • the authentication skip determination processing unit 1139 causes the authentication skip determination processing unit 1139 to store the authentication stored in the storage unit 15. According to the skip determination processing program 1515, the third authentication skip determination processing is executed (G1). Note that, in order to distinguish it from the authentication skip determination process in the other embodiment, it is referred to as “third authentication skip determination process” for convenience.
  • the authentication skip determination processing unit 1139 uses various methods acquired from the storage unit 15 to determine whether the authentication skip condition included in the authentication skip condition data 156 of the storage unit 15 is satisfied, by the same method as in the first embodiment. The determination is made based on the server management information and the information obtained by requesting the terminal 20.
  • the payment management processing unit 113 determines whether the determination to skip the authentication process has been made (G3). When it is determined to skip the authentication processing (G3; Yes), the payment management processing unit 113 shifts the processing to C3.
  • the payment management processing unit 113 transmits the additional authentication request information to the terminal 20 via the communication I/F 14 (G5).
  • the payment application processing unit 213 determines whether or not the additional authentication request information is received from the server 10 by the communication I/F 22 (E1), and if it is determined not to be received (E1; No), the process proceeds to A7. Transfer. In this case, the authentication process is skipped at the terminal 20.
  • the payment application processing unit 213 executes the processing of A13 to A17. In this case, the authentication process is executed at the terminal 20.
  • the payment application processing unit 213 transmits the authentication success information to the server 10 via the communication I/F 22 (E3).
  • the settlement management processing unit 113 When the settlement management processing unit 113 receives the authentication success information from the terminal 20 via the communication I/F 14 (G7), it executes the processes of C3 and C5. That is, after receiving the information indicating that the authentication is successful from the terminal 20, the terminal display code is generated (C3), and the generated terminal display code is transmitted to the terminal 20 (C5).
  • the payment application processing unit 213 executes the processing of A31 to A43.
  • the authentication skip determination processing unit 1139 makes the first operation according to the authentication skip determination processing program 1515 stored in the storage unit 15.
  • the authentication skip determination process of No. 3 is executed (G1).
  • the payment management processing unit 113 determines whether the determination to skip the authentication process has been made (G3). When it is determined to skip the authentication processing (G3; Yes), the payment management processing unit 113 shifts the processing to C11.
  • the payment management processing unit 113 transmits the additional authentication request information to the terminal 20 via the communication I/F 14 (G5).
  • the payment application processing unit 213 determines whether or not the additional authentication request information is received from the server 10 by the communication I/F 22 (E1), and if it is determined not to be received (E1; No), the process proceeds to A21. Transfer. In this case, the authentication process is skipped at the terminal 20.
  • the settlement application processing unit 213 determines that the additional authentication request information is received from the server 10 by the communication I/F 22 (E1; Yes), it executes the processes of A13 to A17. In this case, the authentication process is executed at the terminal 20.
  • the server 10 receives the terminal display code generation request information from the terminal 20 (C1; after Yes) at the timing of the third.
  • the present invention is not limited to this.
  • the server 10 may perform the third authentication skip determination process at a timing after receiving the second payment request information from the store code reader device 50 (after C9). You don't have to.
  • the server 10 receives payment request information (an example of information on electronic money payment by the terminal, not limitation) from the terminal 20, and additional authentication request information (not limitation, but not limitation).
  • the information regarding the authentication of the user of the terminal) is transmitted to the terminal 20 by the communication I/F 14.
  • the server 10 also receives authentication success information (an example of information indicating that the user of the terminal has been authenticated) from the terminal 20 via the communication I/F 14, and makes payment based on the received authentication success information.
  • the result information (an example of payment information indicating that payment by electronic money has been made) is transmitted to the terminal 20 via the communication I/F 14.
  • the server 10 acquires additional authentication request information to the terminal 20 by the communication I/F 14 by acquiring information different from an authentication password (an example of authentication information without limitation,) for authenticating the user of the terminal 20.
  • an authentication password an example of authentication information without limitation,
  • the server obtains information different from the authentication information for authenticating the user of the terminal at the time of payment by electronic money, and thereby the information regarding the authentication of the user of the terminal is obtained. Since it is not sent to the server, the processing load on the server can be reduced.
  • the payment information can be transmitted to the terminal without transmitting the information regarding the authentication of the user of the terminal to the terminal, the convenience of the user can be improved.
  • the information different from the above authentication password is the terminal identification information of the terminal 20 or the information associated with the user identification information of the terminal 20 (including but not limited to identifying the terminal or the user of the terminal).
  • 2 shows a configuration including an example of information associated with identification information for performing the operation.
  • the server transmits information related to the authentication of the user of the terminal to the terminal by acquiring the information associated with the terminal or the identification information for identifying the user of the terminal.
  • the payment information can be transmitted to the terminal without performing the payment.
  • the terminal identification information of the terminal 20 or the information associated with the user identification information of the terminal 20 is the information about the IMS money associated with the terminal 20 or the user of the terminal 20 (limited).
  • information relating to a terminal or electronic money associated with a user of the terminal is included.
  • the server obtains the information about the terminal or electronic money associated with the user of the terminal, and thereby the settlement is performed without transmitting the information about the authentication of the user of the terminal to the terminal. Information can be sent to the terminal.
  • the information about the IMS money associated with the terminal 20 or the user of the terminal 20 is the information about the amount of the IMS money associated with the terminal 20 or the user of the terminal 20 (limited).
  • the configuration includes an example of information about the amount of electronic money associated with the terminal or the user of the terminal).
  • the server transmits the information regarding the authentication of the user of the terminal to the terminal by acquiring the information regarding the amount of electronic money associated with the terminal or the user of the terminal.
  • the payment information can be transmitted to the terminal without the need. For example, when the amount of electronic money is low, it becomes possible to omit the authentication at the terminal by not transmitting the information related to the authentication of the user of the terminal to the terminal, which improves the convenience of the user. be able to.
  • the information regarding the amount of IMS money associated with the terminal 20 or the user of the terminal 20 is set to the one-day upper limit amount (not limited to, the set amount of the electronic money set. 2 shows a configuration including an example of information regarding).
  • the server obtains the information about the set amount of electronic money that has been set, so that the payment information is sent to the terminal without transmitting the information about the authentication of the user of the terminal to the terminal. Can be sent.
  • the server 10 uses the communication I/F 14 to send additional authentication request information (an example of information about authentication of a user of a terminal, without limitation) until the above-mentioned one-day upper limit set amount is exceeded. It shows a configuration in which the settlement result information is transmitted to the terminal 20 by the communication I/F 14 without being transmitted to the terminal 20.
  • the server does not transmit the information regarding the authentication of the user of the terminal to the terminal until the set amount of set electronic money is exceeded, so that the communication amount of the server can be reduced. It is possible to reduce the load on the server.
  • the server sends information regarding the authentication of the user of the terminal to the terminal, so that the user of the terminal can be alerted that the set amount of money has been exceeded. ..
  • the information regarding the amount of the IMS money is information regarding the balance of the IMS money associated with the terminal 20 or the user of the terminal 20 (not limited to the terminal or the user of the terminal. 1) showing an example of information about the balance of electronic money.
  • the server transmits information regarding the authentication of the user of the terminal to the terminal by acquiring information regarding the terminal or the balance of electronic money associated with the user of the terminal. It is possible to send the payment information to the terminal without the need.
  • the server can appropriately perform the process related to the payment based on the information related to the balance of electronic money associated with the terminal or the user of the terminal.
  • the server 10 when the balance of the IMS money is equal to or less than the set amount of money or less than the set amount of money, the server 10 adds additional authentication request information (an example of information about authentication of a user of a terminal, without limitation). Is not transmitted to the terminal 20 via the communication I/F 14, but the settlement result information is transmitted to the terminal 20 via the communication I/F 14. As an example of the effect obtained by such a configuration, the server does not send the information about the authentication of the user of the terminal to the terminal when the balance of electronic money is less than or equal to the set amount or less than the set amount, The communication volume of the server can be reduced, and the load on the server can be reduced.
  • additional authentication request information an example of information about authentication of a user of a terminal, without limitation.
  • the server 10 communicates the additional authentication request information when the balance of the IMS money is less than or equal to the set amount or less than the set amount when the auto charge setting of the terminal 20 is “ON”. It shows a configuration in which the I/F 14 transmits the payment result information to the terminal 20 and the communication I/F 14 transmits the payment result information to the terminal 20.
  • the server is set to automatically deposit the electronic money to the terminal when the electronic money of the terminal becomes less than or equal to the set amount or less than the set amount. If so, electronic money is automatically deposited into the terminal if the amount of money becomes small, so that a large amount of payment can be made, which poses a risk. Therefore, the server can alert the user that a high-value payment can be made by transmitting information regarding the authentication of the user of the terminal to the terminal through the communication unit.
  • the above-mentioned information about the IMS money includes a configuration including the frequency or the number of times of settlement by the IMS money.
  • the server obtains the information on the frequency or the number of payments made by electronic money, and thus the payment information can be obtained without transmitting the information on the authentication of the user of the terminal to the terminal. Can be sent to the terminal.
  • the frequency of payment by electronic money is high or the number of times of payment is high, there is a high possibility that the same user makes payment by electronic money, and it is considered that the risk is low.
  • By not transmitting the information related to the authentication to the terminal it is possible to omit the authentication at the terminal, and it is possible to improve the convenience of the user while ensuring the safety.
  • the above-mentioned information about the IMS money includes the information about the time when the settlement is performed by the IMS money.
  • the server obtains the information about the time when the payment is made by electronic money, so that the payment information is sent to the terminal without transmitting the information about the authentication of the user of the terminal to the terminal. Can be sent.
  • the server 10 uses the communication I/F 14 to send additional authentication request information (an example of information relating to authentication of a user of a terminal, without limitation) to the terminal when the payment is within the set time.
  • 20 shows a configuration in which the settlement result information is transmitted to the terminal 20 by the communication I/F 14 without being transmitted to the terminal 20.
  • the server does not transmit the information related to the authentication of the user of the terminal to the terminal within the set time from the time when the settlement is performed, so that the communication volume of the server is reduced. Therefore, the load on the server can be reduced.
  • the above-mentioned information about the IMS money includes the information about the place where the settlement is performed by the IMS money.
  • the server obtains the information about the place where the payment is made by electronic money, and thus the payment information is sent to the terminal without transmitting the information about the authentication of the user of the terminal to the terminal. Can be sent.
  • the information regarding the place where the settlement is performed by the IMS money includes the information regarding the store where the settlement is performed by the IMS money.
  • the server obtains the information about the store that has made payment by electronic money, so that the payment information can be sent to the terminal without transmitting the information related to the authentication of the user of the terminal to the terminal. Can be sent.
  • the server 10 adds additional authentication request information (not limited to information on authentication of the user of the terminal, based on the position of the store where the payment is made by the IMS money and the position of the terminal 20). 1) is not transmitted to the terminal 20 via the communication I/F 14, but the settlement result information is transmitted to the terminal 20 via the communication I/F 14.
  • additional authentication request information not limited to information on authentication of the user of the terminal, based on the position of the store where the payment is made by the IMS money and the position of the terminal 20.
  • the terminal By not transmitting the information related to the user authentication to the terminal, it is possible to improve the convenience of the user while ensuring the safety.
  • the above-mentioned information about the IMS money includes a configuration including information about the location of the store that has performed the authentication to settle the IMS money.
  • the server transmits the information regarding the authentication of the user of the terminal to the terminal by acquiring the information regarding the place where the authentication for electronic money settlement is performed.
  • the payment information can be transmitted to the terminal without the need.
  • the authentication may be performed again for the same user, and the risk is considered to be low.
  • the second embodiment relates to the above-described terminal identification information of the terminal 20 or information associated with the user identification information of the terminal 20 (including but not limited to identification information for identifying the terminal or the user of the terminal.
  • the example of the information described above indicates a configuration including the information of the product purchased by the user of the terminal 20.
  • the server obtains the information about the product purchased by the user of the terminal, so that the payment information is sent to the terminal without transmitting the information about the authentication of the user of the terminal to the terminal. Can be sent.
  • the server 10 communicates the additional authentication request information with the communication I/F 14 based on the information on the product purchased by the user of the terminal 20 and the information on the product purchased by the user of the terminal 20.
  • the payment result information is transmitted to the terminal 20 by the communication I/F 14 instead of being transmitted to the terminal 20 by.
  • the server provides the information about the authentication of the user of the terminal based on the information about the product purchased by the user of the terminal and the information about the product purchased by the user of the terminal. Since the data is not transmitted to the terminal, the communication volume of the server can be reduced and the load on the server can be reduced.
  • the second embodiment shows a configuration in which the information different from the authentication password includes information about the store.
  • the server can transmit the settlement information to the terminal without transmitting the information regarding the authentication of the user of the terminal to the terminal by acquiring the information regarding the location.
  • the second embodiment shows a configuration in which the above-mentioned information about the store includes information about the store where the product is purchased, is transmitted from the store server 70, and is received by the server 10 by the communication I/F 14.
  • the server can be acquired by receiving the information about the store that purchases the product transmitted from the server of the store that manages the product.
  • the server 10 receives the position information of the terminal 20 from the terminal 20 via the communication I/F 14, and the user of the terminal 20 acquires the position information of the store and the position information of the terminal 20.
  • a configuration is shown in which the additional authentication request information is not transmitted to the terminal 20 by the communication I/F 14, but the settlement result information is transmitted to the terminal 20 by the communication I/F 14.
  • the server does not transmit the information regarding the authentication of the user of the terminal to the terminal based on the information regarding the position of the store where the product is purchased and the received information regarding the position of the terminal. Therefore, the communication volume of the server can be reduced and the load of the server can be reduced.
  • the user of the terminal By not transmitting the information related to the authentication to the terminal, the convenience of the user can be improved.
  • the second embodiment shows a configuration in which the information different from the authentication password includes information about the product.
  • the server can transmit the payment information to the terminal without transmitting the information regarding the authentication of the user of the terminal to the terminal by acquiring the information regarding the product.
  • the server 10 uses the communication I/F 14 to provide additional authentication request information (an example of information regarding user authentication of the terminal, without limitation).
  • 20 shows a configuration in which the settlement result information is transmitted to the terminal 20 by the communication I/F 14 without being transmitted to the terminal 20.
  • the server does not transmit the information regarding the authentication of the user of the terminal to the terminal when the information regarding the product matches the information regarding the preset product, and thus the server communication The amount can be reduced and the load on the server can be reduced.
  • the second embodiment shows a configuration in which the above-mentioned information regarding products includes information regarding the total amount of products to be purchased.
  • the server can transmit the payment information to the terminal without transmitting the information regarding the authentication of the user of the terminal to the terminal by acquiring the information regarding the total amount of the product. ..
  • the risk is considered to be low. Therefore, by not transmitting the information related to the authentication of the user of the terminal to the terminal, the safety and the convenience of the user are ensured. Can be improved.
  • the authentication skip determination on the terminal 20 side described in the first embodiment and the authentication skip determination on the server 10 side described in the second embodiment may be combined to perform a composite process, You don't have to.
  • FIG. 4-7 and FIG. 4-8 are flowcharts showing an example of the flow of processing executed by each device in this case.
  • the third payment application process which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20, and the store payment executed by the store payment processing unit 513 of the store code reader device 50.
  • the third store settlement process which is an example of the process
  • the third settlement management process which is an example of the settlement management process executed by the settlement management processing unit 113 of the server 10, are shown.
  • the payment application processing unit 213 determines that the payment type is “display terminal code” in A3 (A3; display terminal code), it performs the first authentication skip determination processing (H3). Then, the payment application processing unit 213 performs the processing of A11 to A17.
  • the payment application processing unit 213 uses the communication I/F 22.
  • the terminal display code generation request information including the user ID and the authentication skip status information, which is information indicating whether or not the authentication process is skipped, is transmitted to the server 10 (H15).
  • the settlement management processing unit 113 determines whether or not the terminal display code generation request information is received from the terminal 20 by the communication I/F 14 (J1). Then, if it is determined that it has been received (C1; Yes), after performing the processes of C3 to C9, the authentication skip determination processing unit 1139 executes the fourth authentication skip determination process (J3). In addition, in order to distinguish it from the authentication skip determination process in the other embodiment, it is referred to as “fourth authentication skip determination process” for convenience.
  • the authentication skip determination processing unit 1139 determines that additional authentication is not required. This is because the terminal 20 has already been authenticated. On the other hand, when the authentication process is skipped by the terminal 20, the authentication skip determination processing unit 1139 determines whether or not the authentication skip condition is satisfied based on the authentication skip condition included in the authentication skip condition data 156 of the storage unit 15. Then, if the authentication skip condition is satisfied, it is determined that additional authentication is not necessary, and if the authentication skip condition is not satisfied, it is determined that additional authentication is required. This is because the authentication process is skipped at the terminal 20, but it may be better to make the terminal 20 perform additional authentication depending on the result of the authentication skip determination by the server 10.
  • the terminal 20 skips the authentication process because the planned payment amount is not high.
  • the server 10 determines that there is a problem (with risk) in skipping the authentication process of the terminal 20 because the planned payment amount is high, and cancels the authentication skip of the terminal 20 to perform additional authentication. There are cases.
  • the server 10 may rely on the determination of the terminal 20 and determine that additional authentication is not required. In this case, it is not necessary to perform the authentication skip determination on the server 10 side.
  • the payment management processing unit 113 transmits additional authentication request information to the terminal 20 via the communication I/F 14 (G5). Then, the payment management processing unit 113 receives the authentication success information from the terminal 20 via the communication I/F 14 (G7), and then performs the payment process (C11). Then, the payment management processing unit 113 shifts the processing to C13.
  • the settlement application processing unit 213 performs the processes of E1, A13 to A17, and E3 after A19, and then moves the process to A21.
  • the terminal and the server can cooperate with each other to determine whether to execute the display process related to the authentication of the user of the terminal.
  • the server can easily determine whether or not the terminal additionally performs the display processing.
  • the store side may request the server 10 to cause the terminal 20 to skip the authentication process.
  • FIG. 4-9 is a flowchart showing an example of the processing flow of each device in this case, and is a diagram showing a processing part in the processing described in the second embodiment when the payment type is “read terminal code”. This is an extracted portion of 4-5. It should be noted that the same steps as those in the already-explained flowcharts are designated by the same reference numerals, and the description thereof will be omitted.
  • the settlement management processing unit 113 When the settlement management processing unit 113 receives the authentication skip request information from the store code reader device 50 via the communication I/F 14 (C51), it performs the processes of C53 to C65. After that, when the payment management processing unit 113 receives the first payment request information from the terminal 20 through the communication I/F 14 (C37), the authentication skip determination processing unit 1139 executes the fifth authentication skip determination process (G51). ). In addition, in order to distinguish it from the authentication skip determination process in the other embodiment, it is referred to as a “fifth authentication skip determination process” for convenience.
  • the authentication skip determination processing unit 1139 refers to the terminal reading code management database 1593 and associates the authentication skip “present” with the payment page URL accessed by the terminal 20. It is determined whether or not there is any, and if they are associated, it is determined to skip the authentication process. Then, the payment management processing unit 113 shifts the processing to G3 or later.
  • the information different from the authentication password includes the authentication skip information.
  • the server can easily cause the terminal to skip the authentication of the user of the terminal based on the skip information for skipping the authentication of the user of the terminal.
  • this modification shows a configuration in which the authentication skip information is generated by the server 10 based on the authentication skip request information transmitted from the shop code reader device 50.
  • the server can generate skip information for causing the terminal to skip the authentication of the user of the terminal based on the request from the store that manages the product.
  • the server 10 may or may not change the authentication skip condition based on the credit score of the user of the terminal 20.
  • the server 10 lengthens the “set time” in the authentication skip condition of the condition No. “SP1-1” of the authentication skip condition data 156 as the trust score of the user of the terminal 20 increases. It may or may not be done.
  • the set time when the credit score is 0 is set as “2 hours”.
  • a threshold value that is an integral multiple of 10 points (10 points, 20 points,..., 100 points) is set as the threshold value of the credit score. Then, each time the credit score of the user of the terminal 20 reaches the threshold value, the set time can be set to be longer by one hour.
  • the server 10 increases the “one day upper limit set amount” in the authentication skip condition of the condition No “SP3-1” of the authentication skip condition data 156 as the credit score of the user of the terminal 20 increases. It may or may not be done. More specifically, by way of example and not limitation, the daily upper limit set amount when the credit score is 0 is set to “0 yen”. In addition, a threshold value that is an integral multiple of 10 points (10 points, 20 points,..., 100 points) is set as the threshold value of the credit score. Then, each time the user's credit score of the terminal 20 reaches a threshold value, the daily maximum set amount can be set to increase by 5000 yen.
  • the authentication skip determination is performed only by the server 10 by the method described in the second embodiment.
  • the authentication skip determination may be performed by both the terminal 20 and the server 10 by the method described in the second modified example (1). You don't have to.
  • the skip condition can be changed based on the trust of the user of the terminal. For example, by increasing the credibility of the user of the terminal so that the authentication is more likely to be skipped, the convenience of the user can be improved.
  • the server 10 acquires the store location information from the mobile stores. Further, the server 10 acquires the terminal position information from the terminal 20. Then, the server 10 determines the location skip information acquired from the mobile store when determining the authentication skip condition “the location of the planned settlement store and the location of the terminal are not separated” of the condition number “SP2-5”, for example. And the terminal position information acquired from the terminal 20 may be used for the determination.
  • the third embodiment is an embodiment in which the authentication skip information described above is included in a payment code.
  • the shop is put at risk and the authentication processing of the terminal 20 is skipped.
  • the difference from ⁇ First Modification (10)> is that the authentication skip information is included in the terminal reading code.
  • the contents described in the third embodiment can be applied to any of the other embodiments. Further, the same components as those already described are designated by the same reference numerals, and the repeated description will be omitted.
  • FIG. 5A is a diagram illustrating an example of functions implemented by the control unit 11 of the server 10 according to this embodiment.
  • the payment management processing unit 113 includes a terminal display code generation processing unit 1131, a terminal display code transmission processing unit 1133, a store payment result information transmission processing unit 1136, a terminal payment result information transmission processing unit 1137, and authentication.
  • the skip determination processing unit 1139 it has a special terminal reading code generation processing unit 1134 and a special terminal reading code transmission processing unit 1135.
  • the special terminal reading code generation processing unit 1134 has a function of generating a special terminal reading code which is a special terminal reading code including authentication skip information.
  • the special terminal reading code transmission processing unit 1135 has a function of transmitting the special terminal reading code generated by the special terminal reading code generation processing unit 1134 to the terminal 20.
  • FIG. 5-2 is a flowchart showing an example of the flow of processing of each device in the present embodiment, which is a processing part in the processing described in the first embodiment when the payment type is “read terminal code”.
  • the processing portion of FIG. 3-29 is extracted. It should be noted that the same steps as those in the already-explained flowcharts are designated by the same reference numerals, and the description thereof will be omitted.
  • the store payment processing unit 513 determines that the payment type is not “display terminal code” in B5, that is, the payment type is “read terminal code” (B3; No), the special terminal by the communication I/F 54.
  • the read code generation request information is transmitted to the server 10 (M51).
  • the store settlement processing unit 513 associates the store ID with the type 1 terminal reading code by way of example and not limitation.
  • the special terminal reading code generation request information including the sales amount information of the product to be sold and the authentication skip request information is transmitted to the server 10.
  • the store settlement processing unit 513 as an example and not limitation, the special terminal reading code including the store ID and the authentication skip request information.
  • the generation request information is transmitted to the server 10.
  • the authentication skip request information is the same as the authentication skip request information described in ⁇ First modified example (10)>, and is information (request information) for requesting the server 10 to generate the authentication skip information.
  • This authentication skip request information can be transmitted from the store code reader device 50 to the server 10 based on the approval of the store server 70, for example and without limitation. That is, the authentication skip request information can also be said to be information requested by the server (store server 70) of the store that performs the settlement of the IMS money by the terminal 20.
  • the own store is a store that operates the code for reading the first-class terminal
  • the sales amount information of products such as lunch boxes and beverages that the store sells at a uniform amount of money
  • It can be included in the special terminal reading code generation request information.
  • the information that can be included in the special terminal reading code generation request information is not limited to the above information.
  • information a product name, a product type, etc.
  • a product to be sold in association with the special terminal reading code may or may not be included.
  • the information on the above-mentioned product is, for example, without limitation, a product that is less than or equal to the set amount of money or less than the set amount of money (depending on the type of business of the store, the product to be sold, the product type, etc., for example, "500 yen or less” or " It may or may not be information regarding a product of “less than 500 yen”, a product of “1,000 yen or less” or a product of “less than 1000 yen”.
  • the total amount of products that the user of the terminal 20 purchases with the IMS money is set by the store clerk of the store input to the store code reader device 50.
  • the information about the total amount of products purchased by the user of the terminal 20 with the IMS money may or may not be included in the special terminal reading code generation request information.
  • the store code reader device 50 replaces the store ID (store identification information) with or in addition to the area information of the location of the store (an example of information about a place without limitation) and a special terminal reading code. It may or may not be included in the generation request information and transmitted to the server 10.
  • the shop code reader device 50 is described here as transmitting special terminal reading code generation request information to the server 10, instead, the shop server 70 sends the special terminal reading code generation request information. It may or may not be transmitted to the server 10.
  • the settlement management processing unit 113 When the settlement management processing unit 113 receives the special terminal reading code generation request information from the store code reader device 50 through the communication I/F 14 (N51), it performs special terminal reading code generation determination processing (N53).
  • the store from which the special terminal reading code generation request information is transmitted is a member store. Further, when the received special terminal reading code generation request information includes sales amount information of the product to be sold in association with the first type terminal reading code, the sales amount indicated by the sales amount information is within an appropriate range.
  • Amount of money (as an example and not limitation, below a threshold amount of money (depending on the type of business in the store and the product/product type to be sold, for example, "1000 yen or less”, “2000 yen or less”, “3000 yen or less”, etc.) If these conditions are satisfied, it is determined that the special terminal reading code is to be generated, whereas if these conditions are not satisfied, the special terminal reading code is not generated. To do.
  • the special terminal reading code generation processing unit 1134 performs the special terminal reading code generation processing (N57).
  • the special terminal reading code generation processing unit 1134 generates a special terminal reading code including access information and authentication skip information, for example and without limitation. More specifically, for example, data composed of a character string of a payment page URL and a character string of a command instructing or requesting to skip the authentication process is encoded (encoded), converted into a graphic form, A special terminal reading code represented by a two-dimensional code image is generated.
  • the payment management processing unit 113 in association with the store ID of this store, the sales amount (only for stores that operate the code for reading the first-class special terminal), the payment page URL, and the presence or absence of authentication skip (here It is stored in the terminal reading code management database 1593 of the code management database 159 in association with the authentication skip “present”).
  • the authentication skip information do not include the command for instructing or requesting to skip the authentication process in the special terminal reading code, but include the token including the authentication skip information in the special terminal reading code. It may or may not be.
  • the special terminal reading code transmission processing unit 1135 transmits the special terminal reading code to the store code reader device 50 which is the transmission source of the special terminal reading code generation request information by the communication I/F 14 (N59).
  • the settlement management processing unit 113 informs the store code reader by the communication I/F 14 that the special terminal reading code cannot be generated. The device 50 is notified (N61). Then, the payment management processing unit 113 shifts the processing to N63.
  • the store payment processing unit 513 determines whether the special terminal reading code is received from the server 10 by the communication I/F 54 (M53), and if it is determined that the code has been received (M53; Yes), the received special terminal is received.
  • the reading code is displayed on the display unit 53 (M55).
  • the settlement application processing unit 213 of the terminal 20 uses either the terminal reading code displayed in the store or the special terminal reading code displayed on the display unit 53 of the store code reader device 50 at M55 as an application code reader. Read with (L51). Then, the payment application processing unit 213 performs the processing of A33 and A35.
  • the settlement management processing unit 113 determines the settlement schedule information according to the access to the settlement page from the terminal 20 (N63). Specifically, the terminal reading code management database 1593 is referred to, and the information stored in association with this payment page is acquired. Then, the payment management processing unit 113 transmits the payment schedule information according to the determination result to the terminal 20 via the communication I/F 14 (N65).
  • the payment management processing unit 113 sets the planned payment store and the planned payment amount.
  • the first type settlement schedule information including the information is transmitted to the terminal 20 by the communication I/14.
  • the payment management processing unit 113 causes the second-class payment schedule information including the planned payment shop. (The planned payment amount is not included.) is transmitted to the terminal 20 by the communication I/14.
  • the payment application processing unit 213 When the payment application processing unit 213 receives the payment schedule information from the server 10 via the communication I/F 22 (L53), the payment application processing unit 213 performs the processing of A39 and A41, and then performs the sixth authentication skip determination processing (L55).
  • the authentication skip determination processing unit 2135 determines whether or not the code information acquired by the code information acquisition processing of A33 includes the authentication skip information.
  • the special terminal reading code displayed on the shop code reader device 50 is read at L51, it is determined that the acquired code information includes the authentication skip information, while reading the terminal posted on the shop.
  • the business code is read, it is determined that the acquired code information does not include the authentication skip information.
  • the payment application processing unit 213 shifts the processing to A11.
  • the server 10 uses a terminal 20 to read a special terminal code related to settlement of IMS money (an example of electronic money without limitation). (An example of information) is generated.
  • the server 10 acquires information such as store information and sales amount information (an example of information without limitation) based on the special terminal reading code request information.
  • the server 10 generates a code for reading a special terminal based on the acquired information, including information related to the authentication processing executed by the terminal 20 (an example of information related to authentication of a user of the terminal, without limitation).
  • the structure is shown.
  • the information processing apparatus can easily generate the code information based on the acquired information, including the information regarding the authentication of the user of the terminal.
  • the terminal since it is possible for the terminal to acquire information regarding the authentication of the user of the terminal via the generated code information, it is possible to improve the convenience of the user.
  • the above-mentioned special terminal reading code includes information read by an application code reader of the terminal 20 (an example of code reader without limitation). Is shown.
  • the information processing device can generate code information including information read by the code reader of the terminal.
  • the third embodiment shows a configuration in which the information acquired by the server 10 includes information different from an authentication password (an example of authentication information for authenticating a user of a terminal without limitation).
  • the information processing device obtains information different from the authentication information for authenticating the user of the terminal, thereby including the code information including the information on the authentication of the user of the terminal. Can be generated.
  • the terminal since it is possible for the terminal to acquire information regarding the authentication of the user of the terminal via the generated code information, it is possible to improve the convenience of the user.
  • the third embodiment shows a configuration in which the information different from the authentication password includes information about a place.
  • the information processing apparatus can generate the code information including the information on the authentication of the user of the terminal by acquiring the information on the place.
  • the terminal since it is possible for the terminal to acquire information regarding the authentication of the user of the terminal via the generated code information, it is possible to improve the convenience of the user.
  • the third embodiment shows a configuration in which the information about the location includes shop identification information (an example of information about a shop where payment by electronic money is performed by a terminal without limitation).
  • the information processing apparatus generates code information including information related to the authentication of the user of the terminal by acquiring information related to the store in which payment by electronic money is performed by the terminal. can do.
  • the terminal since it is possible for the terminal to acquire information regarding the authentication of the user of the terminal via the generated code information, it is possible to improve the convenience of the user.
  • the special terminal reading code includes authentication skip information.
  • the configuration generated by including is shown.
  • the information processing device when the store is a specific store stored in the information processing device, the information processing device generates code information including information related to authentication of the user of the terminal. You can In addition, since it is possible for the terminal to acquire information regarding the authentication of the user of the terminal via the generated code information, it is possible to improve the convenience of the user.
  • the third embodiment shows a configuration in which the information different from the authentication password includes information about a product name and a product type (an example of information about a product, without limitation) sold in a store.
  • the information processing apparatus can generate the code information including the information on the authentication of the user of the terminal by acquiring the information on the product.
  • the terminal since it is possible for the terminal to acquire information regarding the authentication of the user of the terminal via the generated code information, it is possible to improve the convenience of the user.
  • the third embodiment shows a configuration in which the above-mentioned information about products includes information about products that are less than or equal to a set price or less than the set price.
  • the information processing device obtains information about a product that is less than or equal to the set amount of money or less than the set amount of money, thereby including the information about the authentication of the user of the terminal, and the code. Information can be generated.
  • code information including information related to authentication of the user of the terminal, it is possible to obtain information related to authentication of the user of the terminal via the generated code information while ensuring safety. Therefore, the convenience of the user can be improved.
  • the third embodiment shows a configuration in which the above-mentioned information about products includes information about the total amount of products purchased by the user of the terminal 20 with IMS money.
  • the information processing apparatus obtains information about the total amount of products purchased by electronic money by the user of the terminal, thereby including code information including authentication information of the user of the terminal. Can be generated.
  • the risk is considered to be low when the total amount of merchandise purchased by the user of the terminal with electronic money is low.
  • code information including information related to authentication of the user of the terminal it is possible to obtain information related to authentication of the user of the terminal via the generated code information while ensuring safety. Therefore, the convenience of the user can be improved.
  • the third embodiment shows a configuration in which the information acquired by the server 10 includes authentication skip request information (an example of request information for requesting generation of information regarding authentication of a user of a terminal, without limitation).
  • the information processing apparatus acquires the request information for requesting the generation of the information related to the authentication of the user of the terminal, thereby including the information related to the authentication of the user of the terminal and the code information. Can be generated.
  • the terminal since it is possible for the terminal to acquire information regarding the authentication of the user of the terminal via the generated code information, it is possible to improve the convenience of the user.
  • the information acquired by the server 10 includes authentication skip request information (an example of request information requested by a server of a store that performs electronic money settlement by a terminal, without limitation). Is shown.
  • the information processing apparatus acquires the request information requested by the server of the store that makes the electronic money settlement by the terminal, so that the user of the terminal can obtain the request information. It is possible to generate code information including information related to authentication of.
  • the terminal since it is possible for the terminal to acquire information regarding the authentication of the user of the terminal via the generated code information, it is possible to improve the convenience of the user.
  • the third embodiment shows a configuration in which the information including the special terminal reading code includes authentication skip information (an example of skip information for allowing the terminal to skip authentication of a user of the terminal). ing.
  • the information processing apparatus can generate code information including skip information for the terminal to skip the authentication of the user of the terminal.
  • the terminal can be made to skip the authentication of the user of the terminal through the generated code information.
  • the third embodiment shows a configuration in which the authentication skip information includes information in which the terminal 20 acquires the authentication skip information and thus the authentication processing by the terminal 20 is skipped.
  • the authentication skip information includes information in which the terminal 20 acquires the authentication skip information and thus the authentication processing by the terminal 20 is skipped.
  • the server 10 transmits a special terminal reading code (an example of code information without limitation) to the store code reader device 50 by the communication I/F 14, and the special code is read by the application code reader of the terminal 20.
  • a special terminal reading code an example of code information without limitation
  • the configuration in which the settlement request information is received from the terminal 20 by the communication I/F 14 based on the reading of the terminal reading code is shown.
  • the server can receive and acquire the information regarding the settlement of electronic money by the terminal based on the transmitted code information being read by the code reader of the terminal.
  • the third embodiment shows a configuration in which the information different from the authentication password includes authentication skip information associated with the special terminal reading code.
  • the server can associate the code information read by the code reader of the terminal with information different from the authentication information.
  • the third embodiment shows a configuration in which the authentication skip information includes information generated by the shop code reader device 50.
  • the server can associate the code information read by the code reader of the terminal with the information generated based on the store that manages the product.
  • the third embodiment shows a configuration in which the authentication skip information is generated based on request information transmitted from the store code reader device 50.
  • the server can generate the information associated with the code information based on the request from the store that manages the product.
  • the server 10 generates the special terminal reading code including the authentication skip information, but the present invention is not limited to this.
  • the server 10 includes information used by the terminal 20 to skip the authentication of the user of the terminal 20, that is, information required for the terminal 20 to perform the authentication skip determination, and read the special terminal. It is also possible to generate a code for use.
  • the server 10 uses the special terminal reading code generation process based on the request from the store to obtain information about the amount of the product that the user of the terminal 20 plans to purchase with the IMS money, the terminal 20.
  • Various information such as information about products that the user of the terminal will purchase with the IMS money, information about an area (area) in which the user of the terminal 20 makes payment with the IMS money, and information about a store where the user of the terminal 20 purchases the product with the IMS money. It is also possible to generate a special terminal reading code by including the information.
  • the store code reader device 50 includes the amount of goods planned to be purchased by the user of the terminal 20 and the total amount thereof in the special terminal reading code generation request information as the planned settlement amount based on the operation of the store clerk. And sends it to the server 10. Then, the server 10 generates the special terminal reading code including the planned settlement amount included in the special terminal reading code generation request information received from the shop code reader device 50.
  • the store code reader device 50 provides product identification information for identifying the product purchased by the user of the terminal 20 and product type identification information for identifying the product type based on the operation of the store clerk. , Is included in the special terminal reading code generation request information and transmitted to the server 10. Then, the server 10 generates the special terminal reading code by including the product identification information or the product type identification information included in the special terminal reading code generation request information received from the store code reader device 50.
  • the store code reader device 50 requests the special terminal reading code to store information such as area information of the location of the store itself and store identification information (store ID) of the store, which is stored in advance in the device itself.
  • the information is included and transmitted to the server 10.
  • the server 10 generates the special terminal reading code including the area information and the shop identification information included in the special terminal reading code generation request information received from the shop code reader device 50.
  • the special terminal reading code thus generated by the server 10 is transmitted to the shop code reader device 50 to be displayed and read by the terminal 20, as described above.
  • the terminal 20 can perform the authentication skip determination based on various information obtained by decoding the data from the read special terminal reading code.
  • the authentication skip determination method for the terminal 20 may or may not be performed based on the description of the above-described embodiment and modified examples.
  • the information included in the special terminal reading code includes the information used by the terminal 20 to skip the authentication of the user of the terminal 20.
  • the server can generate the code information including the information used by the terminal to skip the authentication of the user of the terminal.
  • the information included in the above-mentioned special terminal reading code includes a configuration in which the user of the terminal 20 includes information regarding a product purchased by the IMS money.
  • the server can generate the code information including the information about the product that the user of the terminal purchases with electronic money.
  • the above-mentioned information regarding the product purchased by the user of the terminal 20 with the IMS money includes the information regarding the amount of the product purchased by the user of the terminal 20 with the IMS money.
  • the server can generate the code information including the information about the price of the product. Further, it is possible to enable the terminal to obtain information regarding the price of the product via the generated code information, and for example, based on the price of the product purchased by the user, whether or not the authentication of the user is skipped can be performed by the terminal. It can be easily determined.
  • the information included in the above-mentioned special terminal reading code includes a configuration including information about an area (area) where the user of the terminal 20 makes a payment.
  • the server can generate code information including information about a place.
  • the information included in the above-mentioned special terminal reading code includes a configuration in which the user of the terminal 20 includes information about the store where the user purchases the product.
  • the server can generate the code information including the information about the store where the product is purchased.
  • the server 10 generates the special terminal reading code including the authentication skip information, but the present invention is not limited to this.
  • the terminal 20 is a terminal display code used in the payment type “terminal display code” and includes terminal skip code (hereinafter, “special terminal display code”). It is also possible to generate a "work code").
  • FIG. 5-3 and FIG. 5-4 are flowcharts showing an example of the processing flow of each device in this case. It should be noted that the same steps as those in the already-explained flowcharts are designated by the same reference numerals, and the description thereof will be omitted.
  • the payment application processing unit 213 determines that the payment type is “display terminal code” in A3 (A3; display terminal code), it performs the first authentication skip determination processing (H3). Then, the payment application processing unit 213 performs the processing of A11 to A17.
  • the payment application processing unit 213 uses the special terminal display code. Generation processing is performed (P15). Specifically, as a non-limiting example, the special terminal display code including the authentication skip status information, which is information on whether the terminal 20 skips the authentication process, is generated. Then, the payment application processing unit 213 displays the generated special terminal display code on the display unit 24 (P19).
  • the store payment processing unit 513 causes the code reader 58 to read the special terminal display code displayed on the display unit 24 of the terminal 20 (Q9). Then, after performing the code information acquisition process for acquiring the information included in the read special terminal display code (Q11), the store payment processing unit 513 transmits the second payment request information including the acquired information to the communication I/I. It is transmitted to the server 10 by F54 (Q13).
  • the authentication skip determination processing unit 1139 performs the seventh authentication skip determination process (R11). ). Note that, in order to distinguish it from the authentication skip determination process in the other embodiment, it is referred to as a “seventh authentication skip determination process” for convenience.
  • the authentication skip determination processing unit 1139 skips the authentication process in the terminal 20 based on the authentication skip status information included in the second payment request information received from the store code reader device 50. It is determined whether it has been done.
  • the authentication skip determination processing unit 1139 determines that additional authentication is not required. This is because the terminal 20 has already been authenticated. On the other hand, when the authentication process is skipped by the terminal 20, the authentication skip determination processing unit 1139 determines whether or not the authentication skip condition is satisfied based on the authentication skip condition included in the authentication skip condition data 156 of the storage unit 15. Then, if the authentication skip condition is satisfied, it is determined that additional authentication is not necessary, and if the authentication skip condition is not satisfied, it is determined that additional authentication is required. This is because the authentication process is skipped at the terminal 20, but it may be better to make the terminal 20 perform additional authentication depending on the result of the authentication skip determination by the server 10.
  • the terminal 20 skips the authentication process because the planned payment amount is not high.
  • the server 10 determines that there is a problem (with risk) in skipping the authentication process of the terminal 20 because the planned payment amount is high, and cancels the authentication skip of the terminal 20 to perform additional authentication. There are cases.
  • the server 10 may rely on the determination of the terminal 20 and determine that additional authentication is not required. In this case, it is not necessary to perform the authentication skip determination on the server 10 side.
  • the payment management processing unit 113 transmits additional authentication request information to the terminal 20 via the communication I/F 14 (G5). Then, the payment management processing unit 113 receives the authentication success information from the terminal 20 via the communication I/F 14 (G7), and then performs the payment process (C11). Then, the payment management processing unit 113 shifts the processing to C13.
  • the terminal 20 generates the special terminal display code including the authentication skip status information, but the present invention is not limited to this.
  • the terminal 20 includes information used by the server 10 to determine whether to skip the authentication of the user of the terminal 20, that is, information required for the server 10 to perform the authentication skip determination, It is also possible to generate a terminal display code.
  • the terminal 20 relates to information about the price of the product that the user of the terminal 20 plans to purchase, and the product that the user of the terminal 20 plans to purchase.
  • Information information about an area (area) where the user of the terminal 20 makes payment, information about a store where the user of the terminal 20 purchases a product, information about setting of the terminal 20 or a payment application, lock status of the OS side of the terminal 20 (lock For displaying the special terminal, including various kinds of information such as information regarding presence/absence) and lock setting (ON/OFF), information regarding the lock status (presence/absence of lock) and lock setting (ON/OFF) of the payment application side of the terminal 20. It is also possible to generate code.
  • the terminal 20 generates a special terminal display code by including the amount of goods planned to be purchased by the user of the terminal 20 and the total amount thereof as the planned payment amount based on the user operation.
  • the terminal 20 includes a special terminal display including product identification information for identifying a product purchased by the user of the terminal 20 and product type identification information for identifying the product type based on a user operation. Code for use.
  • the terminal 20 generates a special terminal display code including area information related to the area where the terminal 20 of itself is based on the latest calculated position stored in the calculated position history data 288.
  • the special terminal display code is generated based on the user operation, including the store identification information (store ID) of the store where the user of the terminal 20 purchases the product.
  • the terminal 20 displays the special terminal including the information of the authentication setting (ON/OFF) of the terminal 20 of itself and the information of the authentication setting (ON/OFF) of the payment application of the terminal 20 of itself. Code for use.
  • the terminal 20 has a lock status (whether or not locked) on the OS side of its own terminal 20, a lock status (whether or not locked) on the payment application side, and, for example, a lock setting on the OS side of its own terminal 20.
  • the special terminal display code is generated including (ON/OFF) and the lock setting (ON/OFF) on the payment application side.
  • the special terminal display code generated by the terminal 20 in this way is displayed on the display unit 24 of the terminal 20 and read by the store code reader device 50, as described above. Then, the second settlement request information including various information acquired by decoding the data from the read special terminal display code is transmitted from the shop code reader device 50 to the server 10. Then, the server 10 can perform the authentication skip determination based on the above-mentioned various kinds of information included in the second payment request information received from the shop code reader device 50.
  • the authentication skip determination method of the server 10 may or may not be executed based on the above-described embodiment and modification.
  • the terminal 20 (an example of an information processing apparatus, not a limitation) is a special terminal display code (not a limitation, code information) regarding settlement of IMS money (an example of electronic money, not limitation) by the terminal 20. Is generated).
  • the terminal 20 includes information regarding the price of the product that the user of the terminal 20 will purchase, information regarding products that the user of the terminal 20 will purchase, information regarding an area (area) in which the user of the terminal 20 will make payment, and
  • the user acquires information (an example of information, not limitation) about a store where the user purchases a product, information about whether or not the terminal 20 is locked, and information about whether or not the payment application of the terminal 20 is locked.
  • the terminal 20 generates the special terminal display code based on the acquired information, including the information regarding the authentication process executed by the terminal 20 (an example of information regarding the authentication of the user of the terminal without limitation).
  • the structure is shown.
  • a terminal which is a type of information processing apparatus, can easily generate code information based on the acquired information, including information regarding authentication of the user of the terminal. ..
  • the present modified example shows a configuration in which the terminal 20 generates a special terminal display code including the information regarding the authentication processing executed by the terminal 20.
  • a terminal which is a type of information processing apparatus, can easily generate code information including information related to authentication of a user of the terminal.
  • the present modification shows a configuration in which the information included in the above-mentioned special terminal display code includes authentication skip status information (an example of information indicating that the user of the terminal has been authenticated by the terminal, without limitation). ing.
  • a terminal which is a kind of information processing apparatus, can generate code information including information indicating that the user of the terminal has been authenticated by the terminal.
  • the present modification shows a configuration in which the information acquired by the terminal 20 includes information different from the authentication password (an example of authentication information for authenticating a user of the terminal without limitation).
  • a terminal which is a type of information processing apparatus, can generate code information including information different from authentication information for authenticating a user of the terminal.
  • the present modification shows a configuration in which the information different from the authentication password includes information about IMS money (an example of information about electronic money, not limitation).
  • the information different from the authentication password includes information about IMS money (an example of information about electronic money, not limitation).
  • a terminal which is a type of information processing device, can generate code information including information about electronic money.
  • the present modification shows a configuration in which the information different from the authentication password includes information on an area (area) in which the user of the terminal 20 makes a payment (an example of information on a place, not limitation).
  • a terminal which is a kind of information processing device, can generate code information including information about a place. For example, by including the information of the place where the user of the terminal makes a payment as the information about the place, the information of the place of the payment of the user of the terminal can be provided to another device via the generated code information.
  • the present modification shows a configuration in which the information different from the above authentication password includes information about an item to be purchased by the user of the terminal 20 (an example of information about an item without limitation).
  • a terminal which is a type of information processing device, can generate code information including information about a product.
  • information different from the authentication password is information related to authentication setting (ON/OFF) on the terminal 20 side or authentication setting (ON/OFF) on the payment application side (not limited to the terminal or It shows a configuration including an example of information about application settings stored in the terminal).
  • a terminal which is a type of information processing apparatus, can generate code information including information on the setting of the terminal or an application stored in the terminal.
  • the information different from the authentication password is information regarding the lock status and lock setting of the terminal 20, the lock status of the payment application of the terminal 20 and information regarding lock setting (not limited to the terminal or It shows a configuration including an example of information about the security of the application stored in the terminal).
  • a terminal which is a type of information processing apparatus, can generate code information including information regarding the security of the terminal or an application stored in the terminal.
  • the present modification shows a configuration in which the information included in the above-mentioned special terminal display code is acquired by the server 10 (an example of a server that manages the settlement of electronic money, without limitation).
  • a terminal which is a type of information processing apparatus, can provide information regarding authentication of a user of the terminal to a server that manages electronic money settlement.
  • the server 10 executes additional authentication request information (not limited to the authentication of the user of the terminal by the terminal when the authentication skip condition is satisfied based on the information included in the special terminal display code).
  • the communication I/F 14 of the server 10 does not send the example of the information about the payment) to the terminal 20, and the communication result information (including, but not limited to, an example of the information indicating that the payment by electronic money is performed) /F14 shows a configuration for transmitting to the terminal 20.
  • the server that manages the settlement of electronic money, based on the information about the authentication of the user of the terminal, the information about performing the authentication of the user of the terminal by the terminal, Since the communication unit transmits the payment information indicating that the payment is made in electronic money to the terminal without transmitting the communication unit to the terminal, the processing load of the server can be reduced.
  • ⁇ Third Modification (3)> The special terminal reading code described in the third embodiment can be generated for each store, and similarly to ⁇ First Modification (10)>, a product unit or a product sold at the store. It is also possible to carry out by type.
  • the store code reader device 50 if it is desired to skip authentication for product types “bento” and “beverage” on the store side, for example, the store code reader device 50 to the server
  • the special terminal reading code generation request information including the store ID, the product type (here, “bento”, “beverage”) identification information, the sales amount information thereof, and the authentication skip request information is transmitted to 10.
  • the server 10 receives the special terminal reading code generation request information from the shop code reader device 50, and based on the reception of the special terminal reading code generation request information, outputs the special terminal reading code including the authentication skip information for the product types “bento” and “beverage”. To generate.
  • the store side wants not to skip the authentication for the product type “gift product”, it is not the special terminal reading code including the authentication skip information
  • the terminal read code generation request information for requesting generation of a normal terminal read code that does not include authentication skip information is transmitted.
  • the server 10 generates the terminal reading code that does not include the authentication skip information for the product type “gift product” based on the reception of the terminal reading code generation request information from the shop code reader device 50.
  • the server 10 generates a special terminal reading code including the authentication skip information for the product for which the authentication is skipped, and generates a normal terminal reading code without the authentication skip information for the product for which the authentication is not skipped. To do so.
  • the information processing apparatus can generate code information including information related to authentication of a user of a terminal for each product sold by a store or for each product type.
  • code information including information related to authentication of a user of a terminal for each product sold by a store or for each product type.
  • the fourth embodiment is, for example and not by way of limitation, an embodiment in which the user of the terminal 20 uses the payment application to transfer the IMS money to the terminal 20 of the user who is registered as a friend in the IMS application. At this time, the remittance authentication required by the user is skipped when a specific condition is satisfied.
  • the “authentication” in the present embodiment means that the user of the terminal 20 authenticates that the user of the terminal 20 is a legitimate user, and the “authentication process” means the remittance. It means the process to realize the authentication of.
  • the “authentication skip condition” means a condition for skipping the authentication process for remittance, and “skipping the authentication process” means ignoring the processing command of the authentication process. , Means processing the next command, that is, omitting the authentication process.
  • FIG. 6-1 is a diagram showing an example of functions implemented by the control unit 11 of the server 10 in this embodiment.
  • the payment management processing unit 113 includes a remittance management processing unit 115 as a functional unit in addition to the server main processing unit 111 and the IMS processing unit 112.
  • the remittance management processing unit 115 remits IMS money to the terminal 20 of another user who is registered as a friend in the IMS application, or the terminal of another user. It has a function of executing a remittance management process that is a process for managing the deposit from 20.
  • the remittance management processing unit 115 includes, by way of example and not limitation, a remittance processing unit 1151, a remittance source remittance result information transmission processing unit 1153, and a remittance side deposit result information transmission processing unit 1155 as functional units.
  • the remittance processing unit 1151 is a process of transmitting the IMS money owned by the user of the first terminal 20 to the second terminal 20 based on the remittance request information transmitted from the first terminal 20. Has the function of executing.
  • the remittance source remittance result information transmission processing unit 1153 has a function of transmitting remittance result information that is information relating to the remittance result to the first terminal 20 that is the sender of the IMS money.
  • the deposit result information transmission processing unit 1155 for deposit side has a function of transmitting deposit result information that is information relating to deposit results to the second terminal 20 that is the deposit side of IMS money. There is.
  • FIG. 6B is a diagram showing an example of information stored in the storage unit 15 of the server 10 according to this embodiment.
  • the server main processing program 151 includes, in addition to the IMS processing program 1512, a remittance management processing program 1517 executed as remittance management processing as a subroutine program.
  • the storage unit 15 In addition to the user registration data 153 and the store registration data 155, the storage unit 15 also stores an IMS user management database 161, an IMS group management database 163, and a money transfer deposit management database 165.
  • the user information stored and registered in the user registration data 153 will be described as user information shared by the IMS application and the payment application.
  • the IMS user management database 161 is a database for managing data related to the use of the IMS of the user registered in the user registration data 153, and an example of the data structure is shown in FIG. 6C.
  • the IMS user management database 161 stores individual IMS user management data for each of a plurality of users.
  • the user content history data is stored in the IMS user management data of each user, for example, without limitation, in association with the user name and the user ID.
  • the user content history data is data relating to the history of the content transmitted and received between the terminal 20 of this user and the terminal 20 of another user, and as an example and without limitation, the content transmitted and received in the talk room of this user. Data that associates the date and time when the content was transmitted and received with the content number that is identification information for identifying the content is stored as a history.
  • the IMS group management database 163 is a database for managing data relating to the use of IMS of a group composed of a plurality of users registered in the user registration data 153, and an example of the data structure is shown in FIG. 6-4. Show.
  • the IMS group management database 163 stores individual IMS group management data for each of the plurality of groups.
  • the IMS group management data of each group includes, by way of example and not limitation, a group name that is the name of this group, a group ID, a group creation date and time, the number of groups, group user data, and group content history data.
  • the group ID is an ID that functions as identification information for identifying this group, and an ID for uniquely identifying each group is stored and registered.
  • the group creation date and time is the date and time when this group was created.
  • a group can be arbitrarily created by a user who uses IMS, and a user who has created a group or a user who has already joined the group can invite another user to the group to create another group. Users can join groups.
  • Group total number stores the total number of users included in this group. Each time a new user joins the group, the group number is added and updated, and each time a user who has joined the group withdraws from the group, the group number is subtracted and updated.
  • the group user data includes user names of users included in this group (hereinafter referred to as “group users”), user IDs of this group user, and this group user joins this group.
  • group users user names of users included in this group
  • user IDs of this group user user IDs of this group user
  • the date and time when the group is joined and the date and time when the group is joined are stored in association with each other.
  • the group content history data is data relating to the history of the content transmitted/received between the terminals 20 of the group users included in this group. For example, without limitation, the content transmitted/received with the content transmitted/received in the talk room of this group. Data that associates the date and time of the creation with the content number for identifying the content is stored as a history.
  • the remittance/receipt management database 165 is a database for managing data relating to remittance/receipt, and an example of the data structure is shown in FIG. 6-5.
  • the remittance payment management database 165 stores individual remittance management data for each of a plurality of users.
  • the remittance payment management data of each user stores a user ID, a balance, IMS points, a daily upper limit setting amount, auto charge setting, remittance history data, and deposit history data.
  • the remittance history data is history data relating to remittance from the user of this user ID, and for example and without limitation, the remittance date and time that is the date and time of remittance, the remittance destination user ID that is the user ID of the recipient user,
  • the remittance amount which is the amount of money, is stored in association with the remittance amount.
  • the payment history data is history data relating to the payment to the user of this user ID. For example, without limitation, the payment date and time that is the date and time when the payment was made, and the sender user who is the user ID of the user of the sender. The ID and the deposit amount which is the deposit amount are stored in association with each other.
  • the server 10 performs the remittance processing based on the remittance function (remittance) of the payment application. Specifically, as an example and not by way of limitation, the server 10 receives another remittance request information transmitted from the terminal 20 of the one user and is registered as a friend with the one user in the IMS application. A process of sending the IMS money to the user's terminal 20 is performed.
  • the server 10 receives another remittance request information transmitted from the terminal 20 of the one user and is registered as a friend with the one user in the IMS application. A process of sending the IMS money to the user's terminal 20 is performed.
  • the server 10 performs a remittance request process based on the remittance request function of the settlement application (requesting remittance). Specifically, by way of example and not limitation, the server 10 is registered as a friend in the IMS application with one user based on the fact that the remittance request request information transmitted from the terminal 20 of the one user has been received. The process of requesting the remittance to the terminal 20 of the one user is performed by the terminal 20 of the user.
  • the remittance request processing includes a bill sharing request processing based on the bill sharing function of the payment application.
  • the split bill request process is based on the receipt of split bill request information from the terminal 20 of one user, to the terminal 20 of one user and a plurality of other users who are registered as friends in the IMS application, or to the IMS. This is a process of requesting the terminal 20 of a plurality of other users included in the same group as one user in the application to pay an amount obtained by evenly dividing the amount designated by the one user by the total number of users.
  • the split bill function is used by one user who is the secretary when the users who are registered as friends in the IMS application or the users who form a group in the IMS application, for example, have a dinner party or a drinking party. It is used when charging the total amount of money evenly divided by the total number of participants to a plurality of users.
  • FIG. 6-6 is a diagram showing an example of functions implemented by the control unit 21 of the terminal 20 in the present embodiment.
  • the payment application processing unit 213 includes a remittance request processing unit 2138 as a functional unit in addition to the authentication skip determination processing unit 2135 and the authentication processing unit 2137.
  • the remittance request processing unit 2138 has a function of executing a process of requesting the server 10 to remit a user to another terminal 20 that is registered as a friend in the IMS application or to another terminal 20.
  • the IMS application 282 includes, by way of example and not limitation, an IMS application processing program 2821 executed as an IMS application processing, and IMS application data 2823.
  • the IMS application data 2823 includes, by way of example and not limitation, friend data 2825, group data 2826, user content history data 2827, and group content history data 2828.
  • the friend data 2825 is data relating to a user who is registered as a friend by the user of the terminal 20 of his or her own. For example, without limitation, information such as the user name, user ID, icon image, profile, etc. of the user who is registered as a friend is stored. Remembered.
  • the group data 2826 is data relating to a group to which the user of the own terminal 20 subscribes. For example, without limitation, the group name, the group ID, and the same group of the group to which the user of the own terminal 20 subscribes. Information such as user names, user IDs, icon images, and profiles of other included group users is stored.
  • the user content history data 2827 is data relating to the history of content transmitted and received between the terminal 20 of the user and the terminal 20 of another user who is registered as a friend, and as an example, without limitation, the talk room of the user. Data that associates the content transmitted and received in step 1, the date and time when the content was transmitted and received, and the content number, which is identification information for identifying the content, is stored as a history.
  • the group content history data 2828 is data relating to the history of content transmitted/received between the terminals 20 of the group users included in the group to which the user of the terminal 20 of his/her own belongs, and for example, without limitation, talk of this group. Data that associates the content transmitted and received in the room, the date and time when the content was transmitted and received, and the content number for identifying the content is stored as a history.
  • the payment application program 284 includes an authentication skip determination processing program 2845 and an authentication processing program 2847 as subroutine programs, as in the above-described embodiment.
  • the payment application data 285 includes, for example, without limitation, store data 2855, authentication skip condition data 2856, remittance payment data 2857, and location area registration data 2858.
  • control unit 21 stores information regarding various positions and areas based on the history of the calculated position of the terminal 20 of its own stored in the calculated position history data 288.
  • location information of the home location of the user of his/her terminal 20 is registered.
  • the control unit 21 displays the position information corresponding to the calculated position that is statistically most stored in the calculated position history data 288 during the time period from 22:00 on weekdays to 6:00 the next day. , Is registered as the home position information of the user of his/her terminal 20.
  • location area registration data 2858 for example, location information of the company (workplace) where the user of the terminal 20 of his/herself works is registered.
  • the control unit 21 determines, in the calculated position history data 288, the position information corresponding to the calculated position statistically most stored in the time zone from 9:00 to 17:00 on weekdays. It is registered as position information of the company (work) of the user of the terminal 20.
  • location information of a remittance safe area which is an area preset by the server 10 and which is safe to perform remittance is registered.
  • the server 10 can set in advance the position information of the rural or rural areas away from the city center as the position information of the remittance safety area.
  • control unit 21 may calculate the calculated position history data 288 with the calculated position history data 288 at a frequency equal to or higher than the set frequency or the set number of times.
  • the calculated position generated by the number of times described above can be registered as a place frequently visited by the user of his/her terminal 20 by including such position information in the remittance safety area.
  • the user of his/her terminal 20 can register the location and area by himself/herself.
  • the user of the terminal 20 of his/her own may register the home position information of his/her related persons (for example, relatives, close friends, and persons related to the company).
  • 6-8 is a diagram showing an example of the data configuration of the authentication skip condition data 2856 in the present embodiment.
  • the authentication skip condition data 2856 for example, without limitation, a condition category No, a condition No, an authentication skip condition, and an importance (priority) are stored in association with each other.
  • condition category No. “SP11” is a category of “time”, and the authentication skip condition of the condition Nos. “SP11-1” and “SP11-2” is included as an example without limitation.
  • the current date and time is within the set time from the last remittance date and time is defined as the authentication skip condition for condition number “SP11-1”. This means that the fact that the current date and time is within the set time from the date and time of the last remittance means that the remittance will be performed again within a short period of time, so authentication is omitted for the convenience of the user. To do.
  • the terminal 20 stores the current date and time based on the time measured by the clock unit 29A and the final money transfer history data stored in the money transfer money transfer data 2857. It is possible to acquire the date and time of remittance and determine whether or not the current date and time is within a set time from the last date and time of remittance.
  • the current time is included in the set time zone is defined as the authentication skip condition for condition number “SP1-2”.
  • the set time zone can be set in advance by the user of the terminal 20 without limitation. Specifically, for example, the user of the terminal 20 sets a time zone in which he/she frequently remits money or a time zone in which remittance is easily performed (for example, meal time zone) as the set time zone, Authentication can be omitted when remittance is performed during the set time period.
  • the terminal 20 acquires the current time based on the time measured by the clock unit 29A, and determines whether the current time is included in the set time zone. It can be determined.
  • condition category No. “SP12” is a category of “terminal/place”, and the authentication skip condition of the condition Nos. “SP12-1” to “SP12-4” is included therein as an example without limitation.
  • the terminal 20 acquires, as an example and without limitation, the latest calculated position stored in the calculated position history data 288 and the home position registered in the position area registration data 2858. Then, it is possible to determine whether or not the distance between the calculated position of the self terminal 20 and the position of the home is less than or equal to the set distance (or less than the set distance).
  • the terminal 20 acquires the latest calculated position stored in the calculated position history data 288 and the remittance safety area registered in the position area registration data 2858 as an example and not a limitation. Then, it is possible to determine whether or not the calculated position of the own terminal 20 is included in the remittance safety area.
  • the terminal 20 acquires the latest calculated position stored in the calculated position history data 288 and the position of the member store stored in the store data 2855 as a non-limiting example. Thus, it is possible to determine whether or not the distance between the calculated position of the terminal 20 of itself and the position of the member store is less than or equal to the set distance (or less than the set distance).
  • the terminal 20 acquires the latest calculated position stored in the calculated position history data 288 by way of example and not by way of limitation, and the position of the terminal 20 that has transmitted the split bill request is sent to the server 10. The position of the terminal 20 that made the request and transmitted the split bill request is received and acquired from the server 10. Then, it is possible to determine whether or not the distance between the calculated position of the own terminal 20 and the position of the terminal 20 that has transmitted the splitting request is less than or equal to the set distance (or less than the set distance).
  • condition category No. “SP13” is a category of “amount of money”, and the authentication skip conditions of the condition Nos. “SP13-1” to “SP13-4” are included in this as an example without limitation.
  • the “one day upper limit set amount” is an upper limit set amount which is a threshold for the total amount of remittance amounts (remittance amount) already remitted in the day. That is, if the total amount of remittances already remitted in the day does not exceed the daily maximum set amount, it means that authentication is omitted for the convenience of the user.
  • the terminal 20 is informed that the remittance is performed too much by performing authentication. Can be notified to the user, and overuse can be prevented. In addition, when a minor or a child sends money, a parent or guardian can restrict the use.
  • the terminal 20 indicates, by way of example and not limitation, the daily upper limit set amount stored in the remittance data 2857 and the remittance amount for the day specified from the remittance history data. It is possible to acquire the total amount and determine whether or not the total amount exceeds the daily upper limit setting amount.
  • the balance is less than or equal to the set amount (or less than the set amount) & auto charge setting is OFF” is defined as the authentication skip condition of the condition number “SP13-2”.
  • the set amount of money can be set in advance by the user of the terminal 20 without limitation. This is because if the balance is less than or equal to the set amount and the auto charge setting is “OFF”, the user cannot send a large amount of money and the risk is low, which is convenient for the user. Authentication is omitted to improve security.
  • the auto charge setting is “ON”, the IMS money is automatically replenished, so that the user can send a large amount of money, which causes a risk. Therefore, in addition to the balance being less than or equal to the set amount (or less than the set amount), the auto-skip setting is “OFF” as a condition for the authentication skip.
  • the authentication process will not be skipped even if the balance is less than (or less than) the set amount.
  • the authentication process can be skipped even when the auto charge setting is “ON”.
  • the auto-charge setting OFF may be excluded from the authentication skip condition of the condition No. “SP13-2” so that “the balance is equal to or less than the set amount (or less than the set amount)”.
  • the authentication process does not necessarily have to be required. If the auto charge is “ON”, the balance is equal to or less than the set amount (or less than the set amount).
  • the authentication process may be performed or the authentication process may not be performed.
  • the terminal 20 acquires the balance and the auto-charge setting stored in the remittance data 2857 by way of example and not limitation, and the balance is equal to or less than the set amount (or less than the set amount). In addition, it is possible to determine whether or not the auto charge setting is “OFF”.
  • “Within the proper range of remittance frequency or remittance amount per month” is defined as the authentication skip condition for condition number “SP13-3”.
  • the average value, the maximum value, and the mode value of the remittance frequency per month in the past predetermined period are used as the threshold frequency, and the average remittance amount per month in the same past past period.
  • the value, the maximum value, and the mode value are calculated as the threshold amount of money. Then, by performing remittance, if the remittance frequency exceeds the threshold frequency or the remittance amount exceeds the threshold amount, the authentication is performed, and in other cases, the authentication is omitted.
  • the terminal 20 stores the remittance frequency and the remittance amount calculated from the remittance history data stored in the remittance deposit data 2857 and the storage unit 28 by way of example and not limitation. It is possible to acquire the threshold frequency and the threshold amount of money, and determine whether the remittance frequency exceeds the threshold frequency and whether the remittance amount exceeds the threshold amount.
  • the above authentication skip condition may or may not be based on the number of times of remittance of IMS money (the number of remittances), instead of the frequency of remittance of IMS money (remittance frequency). Good.
  • the remittance frequency is within the proper range, the number of remittances is within the proper range, and the remittance amount is within the proper range as individual conditions. May be.
  • the expected remittance amount is less than or equal to the set amount (or less than the set amount)
  • the set amount of money can be set as a not so expensive amount, such as 10,000 yen or 20,000 yen.
  • the “scheduled remittance amount” means the amount of money to be retransmitted from now on (amount in an unconfirmed state before remittance). That is, if the amount of money to be remitted is not so high, it means that authentication is omitted for the convenience of the user.
  • the terminal 20 acquires the amount input by the user of the terminal 20 as the scheduled remittance amount, for example and without limitation, and the scheduled remittance amount is less than or equal to the set amount (or less than the set amount). It is possible to determine whether or not
  • condition category No. “SP14” is a “remittance partner” category, and includes, for example and without limitation, the authentication skip conditions of the condition Nos. “SP14-1” to “SP14-3”.
  • the terminal 20 is a user who is a friend registered based on the friend data 2825 of the IMS application 282 and the user content history data 2827 and the content of the content is not limited to the example.
  • a user whose transmission/reception frequency exceeds the threshold frequency or whose content transmission/reception frequency exceeds the threshold frequency is determined to be a close friend of the user of the terminal 20.
  • the group data 2826 of the IMS application 282 a group whose name includes characters such as “family”, “family”, “relative”, “relative”, etc. is specified, and the group user included in the group is identified. To be relatives. Then, when the remittance schedule partner is these users, it is determined that the authentication skip condition is satisfied.
  • the terminal 20 refers to the remittance history data stored in the remittance deposit data 2857, for example and not by way of limitation, and may have remitted at least once in the past to the remittance target. If it is determined that there is a remittance, it is determined that this authentication skip condition is satisfied.
  • condition category No. “SP15” is a category of “security”, and as an example and without limitation, the authentication skip condition of the condition No. “SP15-1” is included therein.
  • the terminal is locked or the payment application is locked is defined as the authentication skip condition for condition number “SP15-1”. This is because when the terminal 20 itself is locked or the payment application is locked, in order to cancel these locked states, such as inputting a terminal unlock password or a payment application unlock password. Since authentication is required, it means that re-authentication is unnecessary for the convenience of the user.
  • the terminal 20 stores, for example and without limitation, information on whether the terminal 20 is locked or not stored in the terminal data 286 and the payment application data stored in the payment application data 285. It is possible to acquire the information on the presence or absence of the lock and determine whether the terminal is locked or the payment application is locked.
  • condition category No. “SP16” is a category of “authentication setting”, and includes, for example and without limitation, the authentication skip condition of the condition No. “SP16-1”.
  • terminal side authentication setting OFF or payment application side authentication setting OFF is defined.
  • Authentication on the terminal side means authentication required for the user on the terminal 20 side, such as authentication for unlocking the terminal or user authentication.
  • the authentication on the payment application side means the authentication required by the user when performing money transfer using the payment application.
  • the terminal 20 side is set not to perform the authentication required for the user on the terminal 20 side, such as the terminal unlocking authentication or the user identity authentication (setting OFF), or the payment application side.
  • the setting that does not execute the authentication required by the user when performing the remittance using the payment application is made (setting OFF), it means that the authentication is omitted.
  • the terminal 20 is stored in the authentication setting of the terminal side stored in the terminal data 286 and the authentication skip condition user setting data of the remittance/remittance data 2857 by way of example and not limitation.
  • the condition-specific setting flag of the condition number “SP16-1” is acquired, and it is determined whether or not at least one of the terminal-side authentication setting and the payment application-side authentication setting is “OFF”. Can be
  • condition category No. “SP17” is a category of “situation determination”, and includes, for example and without limitation, the authentication skip condition of the condition No. “SP17-1”.
  • the authentication skip condition of the condition No. “SP17-1” “there are terminals that have received splitting requests at the same time, and authentication is completed by the set number of terminals or more” is defined. This is because when a plurality of terminals 20 including one's own terminal 20 receive split billing requests from other terminals 20 at the same time, the remittance is performed by a terminal 20 of a number equal to or more than the set number of terminals 20 other than the own terminal 20. Means that the authentication of its own terminal 20 is omitted.
  • the terminal 20 inquires, for example and without limitation, the information of the authentication status of the other terminal 20 that has received the same split request, to the server 10, and the server 10 verifies the authentication status of the other terminal 20. It is possible to determine whether or not the authentication has been completed with the set number of terminals 20 or more by acquiring information of
  • the importance is defined in association with each of the above authentication skip conditions.
  • the authentication skip conditions of condition numbers “SP12-1” to “SP12-4” (condition category number “SP12”) and condition numbers “SP14-1” to “SP14-3”.
  • the importance level “A” is set for the authentication skip condition of “(condition category No. “SP14”)” and the authentication skip condition of the condition number “SP16-1”.
  • the degree of importance "B" is set for each of the authentication skip condition and the authentication skip condition of the condition number "SP17-1".
  • importance level “C” is set for the authentication skip conditions of condition numbers “SP11-2” and “SP13-3”.
  • the importance is set in association with the authentication skip condition, but the setting of the importance is not an essential requirement, and the importance may not be set. That is, in the above authentication skip condition data 2856, the column of importance may not be provided.
  • the authentication skip determination process by way of example and not limitation, the success or failure of the authentication skip condition is determined in an arbitrary order, and it is determined that the authentication process is skipped when any of the authentication skip conditions is satisfied. You can do it.
  • FIG. 6-9 is a diagram showing an example of the data structure of the remittance payment data 2857.
  • the remittance payment data 2857 includes, by way of example and not limitation, the user ID of the payment application, an authentication password that is a password for authentication, and a payment application lock that is a password for unlocking the payment application.
  • a cancellation password, an IMS point, a balance, a daily maximum set amount, an auto charge setting, remittance history data, deposit history data, an authentication skip condition setting, and an authentication skip condition user setting data are stored. It Since the data other than the remittance history data and the deposit history data are the same as those in the above-described embodiment, the description thereof will be omitted.
  • the remittance history data is data relating to the remittance history of the user of this user ID, and as a non-limiting example, for the user of this user ID, the remittance date and time of the remittance and the user ID of the remittance destination user.
  • the remittance destination user ID and the remittance amount which is the amount of remittance are stored in association with each other.
  • the deposit history data is data relating to the deposit history of the user with this user ID, and for example and without limitation, for the user with this user ID, the deposit date and time and the deposit source user
  • the remittance source user ID, which is the user ID, and the deposit amount, which is the deposit amount, are associated and stored in time series.
  • FIG. 6-10 to FIG. 6-15 are screen diagrams for explaining the flow of remittance without authentication skip when performing normal remittance.
  • FIG. 6-10 is a diagram showing an example of the talk room screen in the IMS application displayed on the display unit 24 of the terminal 20.
  • this talk room screen by way of example and not limitation, the user "user AA" of his/her terminal 20 can talk with the user "user BB" of another terminal 20 who is registered as a friend.
  • the talk room screen for performing is shown.
  • a "remittance icon”, which indicates "remittance” is displayed as a function of the settlement application that works in conjunction with the IMS application.
  • FIGS. 6-11 are diagrams showing an example of a screen displayed when the user of the terminal 20 touches the “money transfer icon” on the talk room screen.
  • a “money transfer icon” that says “money transfer” and a “money transfer request icon” that says “get money” are displayed in a pop-up format. ..
  • the remittance icon is an icon used when “user A.A” sends money to “user BB”.
  • the remittance request icon is an icon used when “user AA” requests “user BB” for remittance.
  • FIG. 6-12 is a diagram showing an example of a remittance screen displayed when the user of the terminal 20 touches the “remittance icon” on the above screen.
  • the user name and icon image of the "user BB" who is the remittance-scheduled partner are displayed, and below that, the expected remittance amount display for displaying the entered remittance estimated amount together with the balance.
  • the column is displayed.
  • "3000 yen” is input and displayed as the planned remittance amount.
  • a "next icon” indicating "next” for advancing to the next screen is displayed.
  • FIG. 6-13 is a diagram showing an example of the remittance execution screen displayed when the “next icon” is touched by the user of the terminal 20 on the remittance screen.
  • the expected remittance amount here, “3000 yen”
  • the entered remittance is displayed below it.
  • a message display field for displaying a message to the other party is displayed. Further, below that, a candidate for an attached image to be sent to the remittance prospect is displayed together with the message. Then, at the bottom of the screen, a "remittance execution icon" for executing remittance is displayed.
  • FIG. 6-14 is a diagram showing an example of the authentication screen displayed when the “remittance execution icon” is touched by the user of the terminal 20 on the remittance execution screen.
  • this authentication screen is displayed.
  • the message "Enter the password you are currently using.” is displayed along with the words "password” (authentication password), and the entered password is displayed below it.
  • Password display The fields and the keyboard for entering the password are displayed.
  • FIG. 6-15 is a diagram showing an example of the remittance completion screen displayed when the authentication result is “OK” in the authentication process based on the password input on the authentication screen.
  • this remittance completion screen you can see the details from "Remittance history” along with the words “Remittance completed” in the center of the screen. ", and a "confirmation icon” for confirming the remittance history are displayed in a pop-up format.
  • 6-16 and 6-17 are screen diagrams for explaining the flow of remittance in the case where the authentication skip is performed.
  • 6-16 shows the same remittance execution screen as in FIG. 6-13
  • FIG. 6-17 shows the same remittance completion screen as in FIG. 6-15.
  • the remittance completion screen of FIG. 6-17 is displayed.
  • the display switches to. That is, the display is switched from the remittance execution screen to the remittance completion screen without displaying the authentication screen of FIG. 6-14.
  • FIG. 6-18 is a diagram showing an example of a group talk room screen in the IMS application displayed on the display unit 24 of the terminal 20.
  • This group talk room screen is a screen for transmitting and receiving contents between the terminals 20 of the group users included in the group, and "IMS Talk Room” is displayed at the top of the screen, and the group name (here "Group X") and the number of group members included in this group (here, "4" indicating "4") are displayed.
  • This group talk room screen is, for example, a group talk room screen displayed on the terminal 20 of “user BB” included in group X, and terminals of other group users included in the same group are displayed on the left side of the screen.
  • Content such as a message transmitted from 20 to its own terminal 20 is displayed, and content such as a message transmitted from its own terminal 20 to the terminal 20 of another group user is displayed on the right side of the screen.
  • FIG. 6-19 is a diagram showing an example of a remittance screen displayed when content is touched by the user of the terminal 20 on the group talk room screen.
  • the settlement application is activated, and FIG. A screen for remittance is displayed.
  • the amount of money requested for remittance by the split bill request here, “3000 yen”
  • the image transmitted from the terminal 20 of “user AA” are displayed, and below that, “ A "remittance icon” indicating "Send money” is displayed.
  • FIG. 6-20 is a diagram showing an example of the remittance execution screen displayed when the user of the terminal 20 touches the “remittance icon” on the remittance screen.
  • this remittance execution screen a user name and an icon image of "user A.A” who is the remittance partner, and a remittance estimated amount display field in which the input remittance estimated amount (here, "3000 yen") is displayed. , Balance and are displayed. Further, at the bottom of the screen, a "remittance execution icon" for executing remittance is displayed.
  • FIG. 6-21 is a diagram showing an example of the remittance completion screen displayed when the “remittance execution icon” is touched by the user of the terminal 20 on the remittance execution screen. If the authentication skip determination process does not determine to skip the authentication process, and if the “remittance execution icon” is touched on the above remittance execution screen, the display switches from the remittance execution screen of FIG. 6-20 to the authentication screen. .. On the other hand, when the authentication skip determination process determines to skip the authentication process, the remittance execution screen of FIG. 6-20 is switched to the remittance completion screen of FIG. 6-21 without displaying the authentication screen. ..
  • ⁇ Process> 6-22 and 6-23 are flowcharts showing an example of the flow of processing executed by each device in the present embodiment.
  • the fifth payment application process which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20A of the "user AA”
  • the remittance management processing unit 115 of the server 10 are shown in order. It shows the first remittance management process to be executed and the fifth payment application process which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20B of "user BB".
  • the same steps as those in the already-explained flowcharts are designated by the same reference numerals, and the description thereof will be omitted.
  • the payment application processing unit 213 of the terminal 20A receives a remittance operation for the input/output unit 23 (S1). Then, the payment application processing unit 213 of the terminal 20A determines the accepted operation type (S3).
  • the payment application processing unit 213 of the terminal 20A performs remittance setting, which is a remittance-related setting, according to a user operation on the input/output unit 23 (S5). Then, the authentication skip determination processing unit 2135 of the terminal 20A performs the eighth authentication skip determination processing (S7). Note that, in order to distinguish it from the authentication skip determination process in the modification and other embodiments, it is referred to as the “eighth authentication skip determination process” for convenience.
  • the authentication skip condition stored in the authentication skip condition data 2856 of the storage unit 28 is satisfied by the same method as the first authentication skip determination process described in the first embodiment. Or not.
  • the authentication skip determination processing unit 2135 of the terminal 20A performs the processing of A11 to A17 based on the determination result of the eighth authentication skip determination processing.
  • the remittance request processing unit 2138 of the terminal 20A uses the communication I/F 22 to make a remittance request including the user ID of the user of the terminal 20 of his/her own, the user ID of the remittance partner (the deposit side), and the remittance amount.
  • the information is transmitted to the server 10 (S19).
  • the remittance management processing unit 115 of the server 10 determines whether or not the remittance request information is received from the terminal 20A by the communication I/F 14 (T1), and if it is determined that the remittance request information is received (T1; Yes), the remittance processing is performed. Perform (T3). Specifically, by way of example and not limitation, it is determined whether or not the planned remittance amount can be remitted based on the balance of the user of the remittance source stored in the remittance and receipt management database 165 of the storage unit 15. To do.
  • the expected remittance amount is subtracted from the balance and updated, and the remittance history data is updated to set the remittance result to "success".
  • the amount of money to be transferred is added to the balance of the user on the deposit side and updated, and the deposit history data is updated.
  • the remittance result is set to “failure”.
  • the remittance management processing unit 115 determines the remittance result by the remittance processing (T5). If the remittance result is “success” (T5; success), the remittance source remittance result information transmission processing unit 1153 transmits the remittance source remittance success information to the terminal 20A by the communication I/F 14 (T7). ). Further, the deposit side deposit result information transmission processing unit 1155 transmits the deposit success information for deposit side to the terminal 20B through the communication I/F 14 (T9).
  • the remittance source remittance result information processing unit 1153 transmits the remittance source remittance failure information to the terminal 20A by the communication I/F 14 (T11). ). Further, the depositing side depositing result information transmission processing unit 1155 transmits the depositing depositing failure information to the terminal 20B through the communication I/F 14 (T13). Then, the remittance management processing unit 115 ends the first remittance management processing.
  • the payment application processing unit 213 of the terminal 20A When the payment application processing unit 213 of the terminal 20A receives the remittance source remittance result information from the server 10 via the communication I/F 22 (S21), the remittance according to the type (success/failure) of the received remittance source remittance result information. The result information is displayed on the display unit 24 (S23). Then, the payment application processing unit 213 of the terminal 20A ends the fifth payment application processing.
  • the settlement application processing unit 213 of the terminal 20B determines whether or not the receipt side deposit result information is received from the server 10 by the communication I/F 22 (U1), and if it is determined that the receipt result information is received (U1; Yes). ), display the deposit result information according to the type (success/failure) of the received deposit result information for deposit side (U3). Then, the payment application processing unit 213 of the terminal 20B ends the fifth payment application processing.
  • the payment application processing unit 213 of the terminal A makes settings relating to the remittance request according to the user operation on the input/output unit 23. Remittance request settings are made (S25).
  • the payment application processing unit 213 of the terminal 20A sends to the server 10 remittance request request information including the user ID of the user of the own terminal 20, the user ID of the remittance request partner, and the remittance request amount by the communication I/F 22. It is transmitted (S27).
  • the remittance management processing unit 115 determines whether or not the remittance request request information is received from the terminal 20A by the communication I/F 14 (T15), and if it is determined that the remittance request request information is received (T15; Yes), the remittance request request information is added.
  • the remittance request information including the included remittance request amount is transmitted by the communication I/F 14 to the terminal 20 (here, the terminal 20B) associated with the remittance request partner user ID included in the remittance request request information (T17).
  • the payment application processing unit 213 of the terminal 20B determines whether or not the remittance request information is received from the server 10 by the communication I/F 22 (U4), and if it is determined that it has been received (U4; Yes), the input/output unit Remittance settings, which are settings relating to remittance, are made in accordance with the user operation on 23 (U5). Then, the authentication skip determination processing unit 2135 of the terminal 20B performs the eighth authentication skip determination processing (S7).
  • the payment application processing unit 213 of the terminal 20B performs the processing of A11 to A17.
  • the remittance request processing unit 2138 of the terminal 20B sends the remittance request information including the user ID of the user of the own terminal 20, the user ID of the remittance-scheduled partner, and the remittance-scheduled amount to the server 10 by the communication I/F 22. It is transmitted (U19).
  • the remittance management processing unit 115 of the server 10 determines whether or not the remittance request information is received from the terminal 20B by the communication I/F 14 (T19), and if it is determined that the remittance request information is received (T19; Yes), the remittance processing is performed. Perform (T21). Then, the remittance management processing unit 115 performs the processing from T5 to T13.
  • the settlement application processing unit 213 of the terminal 20B When the settlement application processing unit 213 of the terminal 20B receives the remittance source remittance result information from the server 10 through the communication I/F 22 (U21), the remittance according to the type (success/failure) of the received remittance source remittance result information. The result information is displayed on the display unit 24 (U23). Then, the payment application processing unit 213 of the terminal 20B ends the fifth payment application processing.
  • the payment application processing unit 213 of the terminal 20A receives the deposit-side deposit result information from the server 10 through the communication I/F 22 (S29), the type of the received deposit-side deposit result information (success/failure). The deposit result information corresponding to is displayed on the display unit 24 (S31). Then, the payment application processing unit 213 of the terminal 20A ends the fifth payment application processing.
  • the display unit 24 of the terminal 20 performs an authentication process (an example of a display process, not a limitation) related to the execution of the authentication of the user of the terminal 20.
  • Information related to the remittance of IMS money is transmitted by the communication I/F 22 of the terminal 20 based on the authentication to the user, and is owned by another user (an example of the first user, without limitation) who is registered as a friend in the IMS application.
  • the terminal 20 that remits the IMS money to another terminal 20 acquires information.
  • the terminal 20 performs the authentication skip determination based on the acquired information, and when the authentication skip condition is satisfied, the authentication process is not performed and the remittance request information (an example of information about remittance of electronic money, without limitation). Is shown by the communication I/F 22.
  • the terminal when the electronic money is remitted, the terminal can easily transmit the information related to the electronic money transfer without performing a display process related to the authentication of the user of the terminal. ..
  • the terminal does not have to perform display processing based on the acquired information, so that the processing load on the terminal can be reduced.
  • the display process does not have to be performed once, so that the remittance can be performed quickly and smoothly, and the convenience of the user can be improved.
  • the fourth embodiment shows a configuration in which the information acquired by the terminal includes information different from the authentication password (an example of authentication information without limitation).
  • the terminal obtains information different from the authentication information for authenticating the user of the terminal at the time of remittance of electronic money, thereby displaying a message regarding execution of authentication for the user of the terminal. Since processing is not required, the processing load on the terminal can be reduced.
  • the fourth embodiment shows a configuration in which the information different from the authentication password includes information about IMS money (an example of information about electronic money, not limitation).
  • the terminal obtains information about electronic money at the time of remittance of electronic money, so that it is not necessary to perform display processing related to execution of authentication for the user of the terminal, The processing load can be reduced.
  • the information about the IMS money is information about the amount of the IMS money associated with the terminal 20 or the user of the terminal 20 (not limited to, the terminal or the user of the terminal. It shows a configuration including an example of information about the amount of electronic money that is present.
  • the terminal when remittance of electronic money, by acquiring information about the amount of electronic money, it is not necessary to perform a display process related to the execution of authentication to the user of the terminal, The processing load on the terminal can be reduced. Further, since the information regarding the amount of electronic money is associated with the terminal or the user of the terminal, the terminal can appropriately perform the process regarding remittance based on the information regarding the appropriate amount of electronic money.
  • the information on the amount of IMS money is the user of another terminal 20 (an example of the first terminal without limitation, which is an example of the first terminal) registered as a friend (an example of the first user without an limitation). )
  • To the first user of the first terminal is shown as an example of a configuration including information about an expected amount of money to be sent to the first user of the first terminal.
  • the terminal acquires the information on the remittance to the first user of the first terminal when remitting the electronic money, thereby performing the display process regarding the execution of the authentication for the user of the terminal. Since this is not necessary, the processing load on the terminal can be reduced.
  • the above-mentioned information regarding the expected remittance amount includes a remittance amount to another user of another terminal 20.
  • the terminal acquires the information on the remittance to the first user of the first terminal when remitting the electronic money, thereby performing the display process regarding the execution of the authentication for the user of the terminal. Since this is not necessary, the processing load on the terminal can be reduced. Further, for example, if the amount of money sent to the first user of the first terminal is low, the risk is considered to be low. Therefore, the display processing relating to the execution of authentication for the user of the terminal is not performed, so that the safety is ensured. At the same time, the convenience of the user can be improved.
  • the fourth embodiment shows a configuration in which the terminal 20 does not perform the authentication process until the daily upper limit setting amount (an example of a remittance amount that is set, not a limitation) is exceeded.
  • the terminal when the electronic money is remitted, the terminal does not display the execution of the authentication until the set remittance amount is exceeded, so that the processing load of the terminal can be reduced. At the same time, the convenience of the user can be improved.
  • the remittance amount of electronic money is exceeded, if the set remittance amount is exceeded, a message regarding execution of authentication may be displayed, so that the user can be alerted that the set remittance amount is exceeded.
  • the information about the amount of the IMS money is information about the balance of the IMS money associated with the terminal 20 or the user of the terminal 20 (not limited to, but is associated with the terminal or the user of the terminal. 1) showing an example of information about the balance of electronic money.
  • the terminal when remittance of the electronic money, by acquiring information about the balance of the electronic money, it is possible to avoid the display processing related to the execution of authentication for the user of the terminal, The processing load on the terminal can be reduced.
  • the terminal since the information regarding the balance of electronic money is associated with the terminal or the user of the terminal, the terminal can appropriately perform the processing regarding remittance based on the information regarding the proper balance of electronic money.
  • the fourth embodiment shows a configuration in which the terminal 20 does not perform the authentication process when the balance of the IMS money is less than or equal to the set amount of money or less than the set amount of money.
  • the terminal 20 when the electronic money is remitted, the terminal does not display the execution of the authentication when the balance of the electronic money is less than or equal to the set amount or less than the set amount.
  • the processing load on the terminal can be reduced.
  • the balance of electronic money is small, it is considered that the risk is low because it is not possible to transfer a large amount of money, so by not displaying the execution of authentication, while ensuring safety, it is convenient for the user. It is possible to improve the sex.
  • the terminal 20 is configured to automatically charge the terminal 20 (without limitation, when the electronic money is less than or equal to the set amount or less than the set amount, the electronic money is automatically deposited in the terminal 20).
  • the authentication process is performed.
  • the terminal automatically deposits the electronic money when the electronic money of the terminal becomes less than or equal to the set amount or less than the set amount.
  • the setting is made for the terminal, if the amount of money decreases, electronic money is automatically deposited in the terminal, so that a large amount of money can be remitted and a risk arises. Therefore, it is possible to alert the user that a large amount of money can be transferred by displaying a message regarding the execution of authentication.
  • the above-mentioned information about the IMS money includes information about the frequency or the number of times of remittance by the IMS money (not limited, information about the frequency or the number of times of remittance by electronic money). Shows.
  • the terminal when remitting electronic money, the terminal obtains information on the frequency or the number of times of remittance by electronic money, thereby performing a display process regarding execution of authentication for the user of the terminal. Since this is not necessary, the processing load on the terminal can be reduced.
  • the information about the IMS money includes the information about the terminal 20 or the other terminal 20 or the user of the other terminal 20 to which the user of the terminal 20 remits with the IMS money. Is shown.
  • the terminal when remittance of electronic money, the terminal by electronic money, or the user of the terminal performed the remittance, by acquiring information about the user of the terminal, Since it is not necessary to perform display processing related to the execution of authentication for the user of the terminal, the processing load on the terminal can be reduced. Also, if the user of the terminal has sent money to another terminal or the user of another terminal, the risk is considered to be low. At the same time, the convenience of the user can be improved.
  • the information about the IMS money includes a final remittance date and time (an example is not limited, but is an example of information about a time when the remittance is performed by electronic money).
  • a final remittance date and time an example is not limited, but is an example of information about a time when the remittance is performed by electronic money.
  • the fourth embodiment shows a configuration in which the terminal 20 does not perform the authentication process within the set time from the above-mentioned final remittance date and time.
  • the terminal when remittance of electronic money, within the set time from the time of remittance of electronic money, because there is no need to display the execution of authentication, The processing load on the terminal can be reduced.
  • the same amount of time has not passed since the remittance of electronic money, it is highly likely that the same user will remit, and it is considered that the risk is low. As a result, it is possible to improve convenience for the user while ensuring safety.
  • the fourth embodiment shows a configuration in which the above-mentioned information about IMS money includes information about a place where remittance is performed by IMS money (an example is not limited to information about a place where remittance is performed by electronic money).
  • the terminal obtains information about the place where the electronic money is remitted, without performing display processing related to the execution of authentication for the user of the terminal. Therefore, the processing load on the terminal can be reduced.
  • the fourth embodiment shows a configuration in which the terminal 20 does not perform the authentication process based on the information about the place where the remittance is performed by the IMS money and the information about the position of the terminal 20.
  • the terminal when the electronic money is remitted, the terminal performs a display process related to the execution of authentication based on the information about the place where the electronic money is remitted and the information about the position of the terminal. Since it is not performed, the processing load on the terminal can be reduced.
  • the above-mentioned information about the IMS money includes the information about the place where the authentication process for remitting the IMS money is performed.
  • the terminal when the electronic money is remitted, the terminal obtains information on the place where the authentication for electronic money remittance is performed, so that the terminal user can be authenticated. Since the display process regarding execution is not required, the processing load on the terminal can be reduced. In addition, for example, if it is a place where authentication for electronic money transfer was performed in the past, there is a high possibility that authentication will be performed again for the same user, and it is considered that the risk is low. By not performing the display process, it is possible to improve the convenience of the user while ensuring the safety.
  • the fourth embodiment shows a configuration in which the information different from the authentication password includes information about a place.
  • the terminal acquires the information about the location when remittance of electronic money, so that it is not necessary to perform the display processing related to the execution of the authentication for the user of the terminal. The load can be reduced.
  • the fourth embodiment shows a configuration in which the above-mentioned information regarding the location includes information regarding the remittance safety area (an example of information regarding a high security position without limitation).
  • the terminal when remittance of electronic money, by acquiring the information of the high security position, it is not necessary to perform a display process related to the authentication of the user of the terminal, The processing load on the terminal can be reduced. Further, by not performing the display process related to the execution of the authentication for the user of the terminal based on the information of the position with high security, it is possible to improve the convenience of the user while ensuring the safety.
  • the fourth embodiment shows a configuration in which the above-mentioned information regarding a place includes information about a place where the user of the terminal has visited a set number of times or more.
  • the terminal displays a display regarding execution of authentication for the user of the terminal by acquiring information of a place where the user of the terminal has visited more than a set number of times when remitting electronic money. Since processing is not required, the processing load on the terminal can be reduced.
  • display processing related to the execution of authentication for the user of the terminal based on the information of the place where the user of the terminal has visited more than the set number of times, it is possible to secure the safety and improve the convenience of the user. Can be improved.
  • the information on the above-mentioned place is at least one of the home position of the user of the terminal 20, the position of the company where the user of the terminal 20 works, and the home of the person concerned of the user of the terminal 20. It shows a configuration that includes one piece of information. As an example of the effect obtained by such a configuration, when the electronic money is remitted, the terminal is located at the home position of the user of the terminal, the position of the company in which the user of the terminal works, and the home of the person concerned of the terminal. By obtaining at least one piece of the information, it is not necessary to perform the display process related to the authentication of the user of the terminal, so that the processing load on the terminal can be reduced.
  • a display process regarding execution of authentication for the user of the terminal based on at least one of the position of the home of the user of the terminal, the position of the company where the user of the terminal works, and the home of the person concerned of the terminal user. By not performing this, it is possible to improve convenience for the user while ensuring safety.
  • the fourth embodiment shows a configuration in which the information about the location includes position information of the payment application compatible store (an example of information about the position of the store that can be settled by electronic money, without limitation).
  • position information of the payment application compatible store an example of information about the position of the store that can be settled by electronic money, without limitation.
  • the terminal when the electronic money is remitted, the terminal obtains information about the position of the store that can be settled by the electronic money, and causes the terminal user to perform a display process regarding execution of authentication. Therefore, the processing load on the terminal can be reduced.
  • the position of the store where payment can be made by electronic money and the position of the terminal are not separated, it is assumed that the user of the terminal exchanges money with his/her friends when paying at this store. Since it is considered that the security is low, it is possible to improve the convenience of the user while ensuring the safety by not performing the display process related to the execution of the authentication for the user of the terminal.
  • the fourth embodiment shows a configuration in which the information different from the authentication password includes information about the remittance partner (not limited to, but an example of information about the first user of the first terminal).
  • the terminal acquires the information about the first user of the first terminal at the time of remittance of electronic money, so that the terminal user does not perform the display processing related to the execution of the authentication. Therefore, the processing load on the terminal can be reduced.
  • the information regarding the remittance partner includes, for example, that the remittance partner is a close friend or relative, that the remittance partner has a past remittance history, and that the remittance partner has a past deposit history. It shows a configuration including information (not limited to, but an example of information related to the relationship with the user of the terminal).
  • the terminal acquires information related to the relationship with the user of the terminal at the time of remittance of electronic money, so that the terminal user does not perform display processing related to execution of authentication. Therefore, the processing load on the terminal can be reduced. Also, for example, if the user is closely related to the terminal user, the risk is considered to be low. Therefore, by not performing the display processing related to the execution of authentication for the terminal user, security is ensured. At the same time, the convenience of the user can be improved.
  • information indicating that the above-mentioned information regarding the remittance partner is included in the terminal 20 of the user of the terminal 20 and the group capable of transmitting and receiving the content in the IMS application (not limited to the terminal.
  • the example includes information indicating that the user terminal is included in a group capable of sending and receiving messages to and from the user terminal.
  • the terminal acquires the information indicating that the terminal is included in a group capable of transmitting and receiving a message with the terminal of the user of the terminal when the electronic money is remitted, Since it is not necessary to perform display processing related to the execution of authentication for the user, the processing load on the terminal can be reduced.
  • the first user included in the group capable of sending and receiving a message to and from the terminal user's terminal is considered to be at low risk, so display processing related to execution of authentication for the terminal user should be avoided By doing so, it is possible to improve convenience for the user while ensuring safety.
  • the group in the above-mentioned IMS application is a user of the terminal 20 (an example of the first terminal without limitation, which is an example of the first terminal) to which the user of the terminal 20 remits money (an example of the first user without limitation).
  • the terminal can send and receive a message to and from the second terminal of the second user included in the group.
  • information different from the authentication password is information relating to the setting of the terminal 20 or the payment application stored in the terminal 20 (not limited to, setting of the terminal or the application stored in the terminal. 2 shows a configuration including an example of information regarding).
  • the terminal acquires the information about the setting of the terminal or the application stored in the terminal at the time of remittance of electronic money, thereby performing the display process regarding the execution of the authentication for the user of the terminal. Therefore, the processing load on the terminal can be reduced.
  • the information about the setting of the terminal or the application stored in the terminal is the information set by the user, the intention of the user can be respected and the convenience of the user can be improved.
  • the information different from the authentication password is information set in the terminal 20 and indicating whether the terminal 20 is locked (not limited to, the terminal set in the terminal, 2 shows an example of a configuration including information regarding security of 1).
  • the terminal obtains the information about the security of the terminal set in the terminal, thereby performing the display process regarding the execution of the authentication for the user of the terminal. Therefore, the processing load on the terminal can be reduced.
  • the information about the security of the terminal is the information related to the authentication of the user of the terminal, the convenience of the user can be improved by omitting the display process regarding the execution of the authentication of the user of the terminal.
  • the fourth embodiment shows a configuration in which the terminal 20 receives, via the communication I/F 22, information relating to remittance of IMS money to the terminal 20 of another user (an example of the first terminal without limitation). ..
  • the terminal can receive and acquire information regarding the remittance of electronic money to the first terminal by the communication unit.
  • the fourth embodiment shows a configuration in which the terminals include a plurality of terminals 20 that have received splitting requests at the same time, and when the authentication is completed by the set number of terminals 20 or more, the authentication process is skipped.
  • the information sent from the server that manages the remittance of electronic money is based on the authentication of the user of the second terminal that has received the information regarding the remittance of electronic money to the first terminal. Sent. Therefore, the terminal can acquire the information sent from the server that manages the remittance of electronic money based on the authentication of the user of the second terminal.
  • the terminal 20 executes the authentication skip determination as to whether or not to skip the authentication process for remittance, but the present invention is not limited to this.
  • the configuration is shown in which the server 10 executes the authentication skip determination as to whether or not to cause the terminal 20 to skip the payment authentication process, but similarly to this, the remittance authentication process is performed in the terminal 20.
  • the authentication skip determination of whether or not to skip may be executed by the server 10.
  • FIG. 6-24 is a diagram showing an example of the data configuration of the authentication skip condition data 166 stored in the storage unit 15 of the server 10 in this modification.
  • the authentication skip condition data 166 is data in which an authentication skip condition that is a condition for causing the terminal 20 to skip the remittance authentication process is set.
  • This data structure is the same as the authentication skip condition data 2856 of the terminal 20, but the contents are partially different. Hereinafter, description will be made focusing on different conditions.
  • the terminal 20 acquires the credit score of the user of the terminal 20 who plans to remit from the credit scores stored in the credit score data 158. Then, it is determined whether or not the acquired credit score is 80 points or more.
  • the server 10 performs the authentication skip determination process for remittance. Therefore, the server 10 has the user information stored in the user registration data 153 of the storage unit 15, the store information stored in the store registration data 155, the IMS user management data stored in the IMS user management database 161, and the IMS.
  • the server management information such as the IMS group management data stored in the group management database 163 and the remittance payment management data stored in the remittance payment management database 165 is acquired.
  • the server 10 requests the terminal 20 for information such as position information of the terminal 20 (terminal position information) that is not managed by the server 10 and acquires the information. Then, the server 10 performs the authentication skip determination based on the acquired information.
  • FIG. 6-25 is a flowchart showing an example of the flow of processing executed by each device in the present modification.
  • a sixth payment application process which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20A
  • a second remittance management process executed by the remittance management processing unit 115 of the server 10.
  • sixth payment application processing which is an example of the payment application processing executed by the payment application processing unit 213 of the terminal 20B, respectively, and the portions corresponding to FIGS. 6-22 are extracted.
  • the same steps as those in the already-explained flowcharts are designated by the same reference numerals, and the description thereof will be omitted.
  • the settlement application processing unit 213 of the terminal 20A performs remittance setting in S5, and then transmits remittance request information to the server 10 via the communication I/F 22 (S19).
  • the remittance management processing unit 115 of the server 10 determines that the remittance request information has been received from the terminal 20A by the communication I/F 14 (T1; Yes), it performs the ninth authentication skip determination process (W1). Note that, in order to distinguish it from the authentication skip determination process according to the other embodiments, it is referred to as a “ninth authentication skip determination process” for convenience.
  • the remittance management processing unit 115 determines whether the determination to skip the authentication process has been made (W3). When it is determined to skip the authentication process (W3; Yes), the remittance management processing unit 115 moves the process to T3.
  • the remittance management processing unit 115 transmits the additional authentication request information to the terminal 20 via the communication I/F 14 (W5).
  • the settlement application processing unit 213 of the terminal 20A determines whether or not the additional authentication request information is received from the server 10 by the communication I/F 22 (V1), and if it is determined not to be received (V1; No), S21. Move to. In this case, the authentication process is skipped at the terminal 20.
  • the payment application processing unit 213 executes the processing of A13 to A17. In this case, the authentication process is executed at the terminal 20.
  • the payment application processing unit 213 sends the authentication success information to the server 10 via the communication I/F 22 (V3).
  • the remittance management processing unit 115 when receiving the authentication success information from the terminal 20 through the communication I/F 14 (W7), executes the processing of T3. That is, the remittance process is performed after receiving the information indicating that the authentication is successful from the terminal 20 (T3). Then, the remittance management processing unit 115 shifts the processing to T5.
  • the server 10 receives, via the communication I/F 14, remittance request information regarding the remittance of IMS money by the terminal 20 (an example of the first information regarding remittance of electronic money, without limitation), and additional authentication request information ( Without limitation, an example of information regarding the authentication of the user of the terminal) is transmitted to the terminal 20 via the communication I/F 14. Further, the server 10 receives the authentication success information (not limited to, an example of information indicating that the user of the terminal has been authenticated) through the communication I/F 14.
  • the server 10 transmits the remittance source remittance result information (an example of remittance information indicating that remittance by electronic money has been performed) to the terminal 20 by the communication I/F 14 based on the authentication success information. Then, based on the authentication success information and the remittance request information, the remittance side deposit result information (not limited, an example of the second information regarding remittance of electronic money) is sent to the remittance partner terminal 20 (not limited, The communication I/F 14 transmits the data to an example of a terminal different from the terminal).
  • the remittance source remittance result information an example of remittance information indicating that remittance by electronic money has been performed
  • the server 10 causes the communication I/F 14 to transmit the additional authentication request information to the terminal 20 based on the acquisition of the information different from the authentication password (an example of the authentication information for authenticating the user without limitation).
  • the remittance source remittance result information is transmitted to the terminal 20 by the communication I/F 14.
  • the server obtains information different from the authentication information for authenticating the user of the terminal at the time of remittance of electronic money, so that the information about the authentication of the user of the terminal can be obtained. Since it is not sent to the server, the processing load on the server can be reduced. Further, the remittance information can be transmitted to the terminal without transmitting information regarding the authentication of the user of the terminal to the terminal.
  • the server 10 may or may not change the authentication skip condition based on the credit score of the user of the terminal 20.
  • the server 10 lengthens the “set time” in the authentication skip condition of the condition No. “SP11-1” of the authentication skip condition data 166 as the trust score of the user of the terminal 20 increases. It may or may not be done.
  • the set time when the credit score is 0 is set as “2 hours”.
  • a threshold value that is an integral multiple of 10 points (10 points, 20 points,..., 100 points) is set as the threshold value of the credit score. Then, each time the credit score of the user of the terminal 20 reaches the threshold value, the set time can be set to be longer by one hour.
  • the server 10 increases the “one day upper limit set amount” in the authentication skip condition of the condition No “SP13-1” of the authentication skip condition data 166 as the credit score of the user of the terminal 20 increases. It may or may not be done. More specifically, by way of example and not limitation, the daily upper limit set amount when the credit score is 0 is set to “0 yen”. In addition, a threshold value that is an integral multiple of 10 points (10 points, 20 points,..., 100 points) is set as the threshold value of the credit score. Then, each time the user's credit score of the terminal 20 reaches a threshold value, the daily maximum set amount can be set to increase by 5000 yen.
  • the server can change the authentication skip condition based on the credibility of the user of the terminal.
  • the user's convenience can be improved by changing the authentication skip condition such that the authentication process is more easily skipped as the user's credibility of the terminal is higher.
  • the information about remittance transmitted from the server 10 is stored in the storage unit 28 of the terminal 20 as remittance history data, and the terminal 20 determines whether to skip the authentication based on the information about remittance included in the remittance history data.
  • the present invention is not limited to this.
  • the terminal 20 may or may not request the information necessary for the authentication skip determination from the server 10 and perform the authentication skip determination based on the information acquired from the server 10.
  • the daily upper limit set amount is set as the upper limit set amount which is a threshold for the total amount of remitted amounts (remittance amount) in the day, but the present invention is not limited to this.
  • the daily upper limit set amount is the sum of the total amount of remitted funds (remittance amount) and the amount of money to be remitted (scheduled remittance amount) in the day. It may or may not be the upper limit set amount of money as the threshold amount of money.
  • the upper limit setting amount does not necessarily have to be the upper limit setting amount for one day, and may be the upper limit setting amount for a predetermined period in the past (past 1 week, past 2 weeks, past 1 month, etc.). You don't have to.
  • the upper limit set amount is set to the amount to be remitted (scheduled amount to be remitted), that is, the amount to be remitted at one time, and the authentication skip is set to "the estimated amount to be remitted is less than (or less than) the set amount"
  • the authentication skip determination may be performed based on the condition. By doing so, the authentication process can be skipped when the user of the terminal 20 sends a small amount of money.
  • the convenience of the user can be improved by not displaying the authentication execution until the amount of money sent once exceeds the set amount.
  • the authentication skip condition that "the current date and time is within the set time from the last remittance date and time” may be "the current date and time is within the set time from the last authentication date and time”.
  • the “final authentication date and time” in this case is not necessarily limited to the date and time when the authentication for remittance was last performed, and is not limited to, for example, for settlement by the IMS money described in the first embodiment and the like.
  • Date and time when the last authentication was performed, the date and time when the authentication for unlocking the OS side of the terminal 20 was last performed, and the date and time when the authentication for unlocking the payment application side was last performed may be set as the “final authentication date and time” in the above authentication skip condition.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

端末による電子貨幣の決済に関するコード情報を情報処理装置によって生成する生成方法は、情報を取得することと、情報に基づいて、端末のユーザの認証に関する情報を含めて、コード情報を生成することとを含む。

Description

生成方法、プログラム、情報処理装置
　本開示は、生成方法、プログラム、情報処理装置に関する。
　昨今、携帯電話機等の端末を用いて電子決済を行うサービスが普及している。例えば特許文献１には、端末に操作入力された暗証データと、端末にあらかじめ格納された暗証データとを照合することにより認証を行う手法が開示されている。しかしながら、電子貨幣による決済における端末のユーザに対する認証に関して使い勝手が悪い場合があった。
特開２００２－１７６６７１号公報
　本発明の第１の態様によると、端末による電子貨幣の決済に関するコード情報を情報処理装置によって生成する生成方法は、情報を取得することと、情報に基づいて、端末のユーザの認証に関する情報を含めて、コード情報を生成することとを含む。
　本発明の第２の態様によると、端末による電子貨幣の決済に関するコード情報を情報処理装置のコンピュータによって生成するためのプログラムは、情報を取得することと、情報に基づいて、端末のユーザの認証に関する情報を含めて、コード情報を生成することとを含む。
　本発明の第３の態様によると、端末による電子貨幣の決済に関するコード情報を生成する情報処理装置は、情報を取得する取得部と、情報に基づいて、端末のユーザの認証に関する情報を含めて、コード情報を生成する制御を行う制御部とを備える。
実施形態の一態様における通信システムの構成の一例を示す図。 実施形態の一態様における店舗ＰＯＳシステムのシステム構成の一例を示す図。 第１実施形態に係るサーバの制御部により実現される機能の一例を示す図。 第１実施形態に係るサーバの記憶部に記憶される情報の一例を示す図。 第１実施形態に係るユーザ登録データの一例を示す図。 第１実施形態に係る店舗登録データの一例を示す図。 第１実施形態に係る決済管理データベースの一例を示す図。 第１実施形態に係る端末の制御部により実現される機能の一例を示す図。 第１実施形態に係る端末の記憶部に記憶される情報の一例を示す図。 第１実施形態に係る認証スキップ条件データの一例を示す図。 第１実施形態に係る端末ユーザデータの一例を示す図。 第１実施形態に係る認証スキップ条件ユーザ設定データの一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末の表示画面の一例を示す図。 第１実施形態に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第１実施形態に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第１実施形態に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第１実施形態に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第１実施形態に係る第１の認証スキップ判定処理の流れの一例を示すフローチャート。 第１変形例に係る認証スキップ条件データの一例を示す図。 第１変形例に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第１変形例に係る端末読み取り用コード管理データベースのデータ構成の一例を示す図。 第２実施形態に係るサーバの制御部により実現される機能の一例を示す図。 第２実施形態に係るサーバの記憶部に記憶される情報の一例を示す図。 第２実施形態に係る認証スキップ条件データの一例を示す図。 第２実施形態に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第２実施形態に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第２実施形態に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第２変形例に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第２変形例に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第２変形例に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第３実施形態に係るサーバの制御部により実現される機能の一例を示す図。 第３実施形態に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第３変形例に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第３変形例に係る端末、店舗コードリーダ装置、サーバの処理の流れの一例を示すフローチャート。 第４実施形態に係るサーバの制御部により実現される機能の一例を示す図。 第４実施形態に係るサーバの記憶部に記憶される情報の一例を示す図。 第４実施形態に係るＩＭＳユーザ管理データベースのデータ構成の一例を示す図。 第４実施形態に係るＩＭＳグループ管理データベースのデータ構成の一例を示す図。 第４実施形態に係る送金着金管理データベースのデータ構成の一例を示す図。 第４実施形態に係る端末の制御部により実現される機能の一例を示す図。 第４実施形態に係る端末の記憶部に記憶される情報の一例を示す図。 第４実施形態に係る認証スキップ条件データのデータ構成の一例を示す図。 第４実施形態に係る送金着金用データのデータ構成の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末の表示画面の一例を示す図。 第４実施形態に係る端末、サーバの処理の流れの一例を示すフローチャート。 第４実施形態に係る端末、サーバの処理の流れの一例を示すフローチャート。 第４変形例に係る認証スキップ条件データのデータ構成の一例を示す図。 第４実施形態に係る端末、サーバの処理の流れの一例を示すフローチャート。
＜法的事項の遵守＞
　本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
　本開示に係る認証方法等を実施するための実施形態について、図面を参照して説明する。
［システム構成］
　図１は、本開示の一実施形態に係る通信システム１の構成の一例を示す図である。
　図１に開示されるように、通信システム１では、ネットワーク３０を介してサーバ１０と、端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）と、店舗ＰＯＳシステム４０とが接続される。
　サーバ１０は、ネットワーク３０を介してユーザが所有する端末２０に、端末２０間でのメッセージ等を含むコンテンツの送受信を実現するサービスを提供する。また、サーバ１０は、端末２０と通信を行って電子決済（限定でなく、決済の一例）を実現するサービス（以下、「決済サービス」と称す。）を提供する。なお、ネットワーク３０に接続される端末２０の数は限定されない。
　ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０と、１以上の店舗ＰＯＳシステム４０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
　ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定でなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。
　端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）（限定でなく、端末、情報処理装置の一例）は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定でなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。
　端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は基本的には同一であるため、以下の説明においては、端末２０について説明する。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応付けられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応付けられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
　サーバ１０（限定でなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定でなく例として、サーバ装置、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
　以下説明する実施形態では、サーバ１０は、メッセージングサービス（ＩＭＳ（Instant Messaging Service））を提供する機能と、決済サービスを提供する機能とを有していることとして説明する。
　なお、ＩＭＳを提供する機能を有するサーバと、決済サービスを提供する機能を有するサーバとを別体として、ＩＭＳサーバと、決済サーバとの２つのサーバを構成するようにしてもよいし、しなくてもよい。
　また、限定でなく例として、サーバ１０を運用する事業者を企業（例えば企業「Ｘ」）とし、ＩＭＳの事業者と提携している加盟店の店舗（加盟店舗）を「店舗Ｓ１」、「店舗Ｓ２」、・・・、とする。
　店舗ＰＯＳシステム４０は、ＩＭＳの事業者と提携している店舗に導入されて使用されるＰＯＳシステムである。
　この店舗ＰＯＳシステム４０には、限定でなく例として、店舗コードリーダ装置５０と、コードレジ６０と、店舗サーバ７０とが含まれる。
［各装置のハードウェア（ＨＷ）構成］
　通信システム１に含まれる各装置のＨＷ構成について説明する。
（１）端末のＨＷ構成
　図１には、端末２０のＨＷ構成の一例を示している。
　端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、表示部２４、マイク２５、スピーカ２６、カメラ２７、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定でなく例として、端末２０は、マイク２５、カメラ２７等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
　通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
　入出力部２３は、端末２０に対する各種操作を入力する装置、および、端末２０で処理された処理結果を出力する装置を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
　入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定でなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。
　出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定でなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定でなく例として３D（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
　表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイやOELD（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。
　入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。
　時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定でなく例として、水晶発振器を利用したクロック、ＮＩＴＺ（Network Identity and Time Zone）規格を利用したクロック等を有して構成される。時計部２９Ａは、限定でなく例として、計時部や時刻情報検出部と表現することもできる。
　位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称す。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定でなく例として、位置算出用センサ部と表現することもできる。
　位置算出用情報検出部２９Ｂは、限定でなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））等を含む。
　衛星測位ユニットは、限定でなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
　慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定でなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
　制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
　制御部２１は、限定でなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。
　記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定でなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。
　端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
　マイク２５は、音声データの入力に利用される。スピーカ２６は、音声データの出力に利用される。カメラ２７は、動画像データの取得に利用される。
（２）サーバのＨＷ構成
　図１には、サーバ１０のＨＷ構成の一例を示している。
　サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、ディスプレイ１３、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定でなく例として、サーバ１０のＨＷは、ディスプレイ１３を取り外すような構成であってもよいし、そうでなくてもよい。
　制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
　制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。
　記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。
　通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
　入出力部１２は、サーバ１０に対する各種操作を入力する装置により実現される。入出力部１２は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部１２は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部１２、限定でなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部１２は、これらに限定されない。
　ディスプレイ１３は、代表的にはモニタ（限定でなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイ１３は、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイ１３は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイ１３は、これらに限定されない。
　時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定でなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定でなく例として、計時部や時刻情報検出部と表現することもできる。
（３）店舗ＰＯＳのシステム構成
　図２には、店舗ＰＯＳシステム４０のシステム構成の一例を示している。
　店舗ＰＯＳシステム４０は、サーバ１０を運用する事業者（ＩＭＳの事業者）と提携している店舗に導入されて使用されるＰＯＳシステムであり、限定でなく例として、店舗コードリーダ装置５０と、コードレジ６０と、店舗サーバ７０とを含む。
　店舗コードリーダ装置５０は、ＰＯＳ通信Ｉ／Ｆ５７（限定でなく例として、店舗内の有線通信Ｉ／Ｆや無線通信Ｉ／Ｆ）によってコードレジ６０や店舗サーバ７０と通信接続され、コードレジ６０での会計の際に、端末２０の表示部２４に表示される端末表示用コードを読み取る。そして、端末表示用コードを読み取ったことに基づいて、端末２０での決済に関する情報（限定でなく例として、後述する決済依頼情報）を通信Ｉ／Ｆ５４によってサーバ１０に送信し、サーバ１０での決済結果に関する情報（限定でなく例として、後述する店舗用決済結果情報）を通信Ｉ／Ｆ５４によってサーバ１０から受信する。
　店舗コードリーダ装置５０は、限定でなく例として、制御部５１と、入出力部５２と、表示部５３と、通信Ｉ／Ｆ５４と、記憶部５５と、音出力部５６と、ＰＯＳ通信Ｉ／Ｆ５７と、コードリーダ５８とを有する。
　コードリーダ５８は、二次元コードを読み取るためのコードリーダであり、本明細書では、端末２０の表示部２４に表示され、端末２０のユーザによって提示される二次元コード（例えばＱＲコード（登録商標））としての端末表示用コードを読み取るための二次元コードリーダ（例えばＱＲコードリーダ）を含む。
　コードレジ６０は、限定でなく例として、ＰＯＳ通信Ｉ／Ｆ５７によって店舗コードリーダ装置５０や店舗サーバ７０と通信接続され、店舗コードリーダ装置５０がサーバ１０から取得した店舗用決済結果情報に基づいて、販売した商品の総額を印字したレシートを発行する。コードレジ６０は、決済アプリケーションに対応可能に構成されたレジであり、決済アプリケーション対応の据置端末と言うこともできる。
　店舗サーバ７０は、限定でなく例として、自店舗に関する店舗情報や、自店舗で販売される商品に関する情報や自店舗で提供されるサービスに関する情報、自店舗での商品の販売やサービスの提供に伴う売上げに関する情報等の各種の情報を管理する。店舗サーバ７０は、ＰＯＳ通信Ｉ／Ｆ５７によって店舗コードリーダ装置５０やコードレジ６０と通信可能に構成されているとともに、ネットワーク３０を介してサーバ１０等の外部装置と通信可能に構成されている。
　なお、店舗サーバ７０は、必ずしも店舗コードリーダ装置５０と直接的に通信可能に構成されている必要はなく、コードレジ６０を介して店舗コードリーダ装置５０と通信可能に構成されていてもよい。例えば、店舗コードリーダ装置５０がサーバ１０から取得した店舗用決済結果情報はコードレジ６０に送られ、その後、コードレジ６０から店舗サーバ７０に送られるようにするなどすることもできる。
（４）その他
　サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
　他の装置についても同様である。
　本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。
　他の装置についても同様である。
　なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
　他の装置についても同様である。
　また、本開示の各実施形態のプログラムＰ(限定でなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。
　記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定でなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。
　サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
　他の装置についても同様である。
　また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定でなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
　他の装置についても同様である。
　また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
　サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
　端末２０における処理の少なくとも一部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
　サーバ１０における処理の少なくとも一部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
　明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
　なお、本開示のプログラムは、限定でなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装される。
＜第１実施形態＞
　近年、ＩＭＳやＳＮＳ（Social Networking Service）等のネットワークサービスが流行している。
　「ＩＭＳ」は、インターネットを利用して通信装置のユーザ間で会話を交わすために、ユーザの通信装置間でのメッセージの送受信を行わせるサービスである。本明細書では、インスタントメッセージングサービスの略称である「ＩＭＳ」の表現を用いるが、広義にはメッセージングサービス全般を意味するものであり、インスタントメッセージングサービスに限定されるものではない。
　「ＳＮＳ」とは、主として通信装置のユーザ間のコミュニケーションを行うことを目的として、インターネット上で社会的なネットワークやコミュニティを形成させるサービスである。なお、ＩＭＳはＳＮＳの１つの形態（一形態）であるとも言える。このため、ＩＭＳとＳＮＳとは区別してもよいし、区別しなくてもよい。
　また、これらのネットワークサービスに関連して、電子決済用のアプリケーション（アプリケーションソフトウェア）が普及しつつあり、端末２０のユーザが、電子決済用のアプリケーションを用いて、店舗での支払いを行うケースが増えてきている。
　第１実施形態～第３実施形態は、限定でなく例として、ＩＭＳの事業者によって提供されるアプリケーションであって、ＩＭＳアプリケーションソフトウェア（以下、簡単に「ＩＭＳアプリケーション」と称す。）の一機能として、または、ＩＭＳアプリケーションと連動するアプリケーションとして、端末２０のユーザが利用可能な電子決済用のアプリケーションであるＩＭＳ決済アプリケーションソフトウェア（以下、簡単に「決済アプリケーション」と称す。）を用いて電子決済を行う実施形態である。
　より具体的には、第１実施形態～第３実施形態では、端末２０のユーザが、店舗で商品を購入したり、店舗が提供するサービスを受ける場合に、決済アプリケーションを用いて電子決済を行う。この際、端末２０側でユーザに要求する電子決済用の認証を、特定の条件が成立する場合にスキップする。
　以下説明する実施形態において、「決済」とは、特に断りのない限り、決済アプリケーションを利用した「電子決済」を意味する。
　また、「認証」とは、特に断りのない限り、決済を行うために端末２０のユーザが正規のユーザであることを認証することを意味し、「認証処理」とは、この決済用の認証を実現するための処理を意味する。
　また、「認証スキップ条件」とは、特に断りのない限り、上記の決済用の認証処理をスキップする条件を意味し、「認証処理をスキップする」とは、認証処理の処理命令を無視して、次の命令を処理すること、つまり認証処理を省略することを意味する。
　また、「ＩＭＳマネー」とは、特に断りのない限り、ＩＭＳの事業者がサーバ１０で管理する電子貨幣であって、端末２０のユーザが決済アプリケーションで利用可能な電子貨幣を意味する。
　ここで、「電子貨幣」とは、事業者（以下説明する実施形態ではＩＭＳの事業者）により提供される、情報通信技術を利用した、現金の代替となる支払手段である。
　変形例で後述するが、本開示における電子貨幣は、ＩＭＳマネーに限らず、現金の代替としてユーザが利用可能な支払手段全般を含む概念とすることができる。
　第１実施形態に記載の内容は、他の各実施形態のいずれにも適用可能である。
＜機能構成＞
（１）サーバの機能構成
　図３－１は、本実施形態におけるサーバ１０の制御部１１により実現される機能の一例を示す図である。
　サーバ１０は、制御部１１により実現される機能として、サーバメイン処理部１１１と、ＩＭＳ処理部１１２と、決済管理処理部１１３とを有する。
　サーバメイン処理部１１１は、記憶部１５に記憶されているサーバメイン処理プログラム１５１に従って、サーバ１０を統括的に制御するための処理であるサーバメイン処理を実行する機能を有している。
　ＩＭＳ処理部１１２は、記憶部１５に記憶されているＩＭＳ処理プログラム１５１２に従って、端末２０間でのＩＭＳ用のメッセージ等を含むコンテンツの送受信を実現するための処理であるＩＭＳ処理を実行する機能を有している。
　決済管理処理部１１３は、記憶部１５に記憶されている決済管理処理プログラム１５１３に従って、ＩＭＳマネーによる決済を実行・管理するための処理である決済管理処理を実行する機能を有している。
　本実施形態では、端末２０のユーザが、端末２０に記憶されている決済アプリケーションを用いて、限定でなく例として、「端末コード表示」と「端末コード読み取り」との２種類の決済種別による決済が可能であることとして説明する。
　決済種別「端末コード表示」は、端末２０のユーザが店舗で支払いを行う際に、端末２０に記憶されている決済アプリケーションを用いて、端末２０に表示される端末表示用コードを店舗のコードレジ６０で店員に提示し、この端末表示用コードを店舗コードリーダ装置５０で読み取ってもらうことで、決済を行う決済種別である。
　決済種別「端末コード読み取り」は、端末２０のユーザが店舗で支払いを行う際に、端末２０に記憶されている決済アプリケーションを用いて、例えば店舗の店頭、コードレジ６０周辺、その店舗で販売される商品の商品種別に対応する陳列エリア（分かり易い例として、弁当エリア、飲料エリア、食材エリア）等の場所に掲示される端末読み取り用コードを読み取って、決済を行う決済種別である。
　本実施形態では、端末表示用コードと、端末読み取り用コードとが、それぞれ二次元コードで表されるものとする。二次元コードとは、水平方向と垂直方向とに情報を持つ表示方式のコードであり、小さな正方形を上下左右に配列させたマトリックス式のコード（以下、「マトリックスコード」と称す。）や、一次元コード（限定ではなく例としてバーコード）を上下に複数重ねたスタック式のコード（以下、「スタックコード」と称す。）等がある。
　本実施形態では、説明の簡明化のため、広く用いられているマトリックスコードの一例であるＱＲコード（登録商標）を、端末表示用コードおよび端末読み取り用コードの一例として説明する。
　なお、本実施形態とは異なり、ＱＲコード以外のマトリックスコードとして、ＳＰコードやベリコード、マキシコード、ＣＰコード、カメレオンコード等のコードを用いてもよいし、用いなくてもよい。また、マトリックスコードではなく、各種のスタックコードを用いてもよいし、用いなくてもよい。
　決済管理処理部１１３は、限定でなく例として、端末表示用コード生成処理部１１３１と、端末表示用コード送信処理部１１３３と、店舗用決済結果情報送信処理部１１３６と、端末用決済結果情報送信処理部１１３７とを機能部として含む。
　端末表示用コード生成処理部１１３１は、端末表示用コードを生成する機能を有している。端末表示用コード生成処理部１１３１は、端末２０から送信される端末表示用コード生成依頼情報を受信したことに基づいて、少なくとも、サーバ１０が提供するウェブページの１つである決済用ページにアクセスするためのアクセス情報と、認証情報とを含むＱＲコードを、端末表示用コードとして生成する。
　アクセス情報には、限定でなく例として、端末表示用コードを読み取った店舗コードリーダ装置５０が決済用ページにアクセスするためのＵＲＬ（Uniform Resource Locator）が含まれる。このアクセス情報は、「リンク」や「リンク情報」と表現することもできる。以下、決済用ページのＵＲＬを「決済用ページＵＲＬ」と称する。
　認証情報には、サーバ１０が、端末２０または端末２０のユーザが、正規の端末２０または正規の端末２０のユーザであることを認証するために必要となる認証情報として、限定でなく例として、サーバ１０によってランダムに発行されるトークンが含まれる。
　認証情報は、認証局が発行する情報であり、トークンは、サーバ１０が認証局となって、端末２０または端末２０のユーザを認証するために発行する認証情報である。
　本実施形態におけるトークンは、例えば「ランダムトークン」、「アクセストークン」、「決済用トークン」と表現することもできる。本実施形態において、トークンはランダムに発行されるため、端末表示用コードが生成される毎に異なるトークンとなる。このため、トークンまたはこのトークンを含む端末表示用コードは、ワンタイムパスワードとして機能する。
　また、本実施形態において、端末表示用コード生成処理部１１３１は、端末表示用コードとして、二次元コード（限定ではなく例としてＱＲコード）に加えて一次元コード（限定ではなく例としてバーコード）も生成する。これは、店舗によっては、二次元コードの読み取りには対応していないが、一次元コードの読み取りには対応可能な場合があるためである。
　また、本実施形態において、端末表示用コード生成処理部１１３１は、端末表示用コードを生成した場合、この端末表示用コードに有効期間（例えば、コード生成時から「５分間」の期間）を関連付けて、端末２０に送信する。この有効期間内に端末２０で表示される端末表示用コードが店舗コードリーダ装置５０で読み取られた場合は決済が可能となるが、有効期間が経過した後に端末表示用コードが店舗コードリーダ装置５０で読み取られた場合は、端末表示用コードの再取得が必要となる。つまり、本実施形態における端末表示用コードは、時限コードとして機能する。
　一方、決済種別「端末コード読み取り」で使用される端末読み取り用コードには、少なくとも、アクセス情報として、端末読み取り用コードを読み取った端末２０が決済用ページにアクセスするための決済用ページＵＲＬが含まれる。
　本実施形態では、端末読み取り用コードには、２つの種別の端末読み取り用コードが含まれることとして説明する。
　第１の種別の端末読み取り用コード（以下、「第１種端末読み取り用コード」と称す。）は、日本の各種の業種の店舗（典型例としては、日本のコンビニエンスストア）等で使用されるコードである。この第１種端末読み取り用コードは、利用態様の一例として、店舗で一律の金額（固定金額）で販売される商品種別の商品、例えば弁当や飲料等の商品の決済を行うために用いられるコードとすることができる。
　第１種端末読み取り用コードには、限定でなく例として、第１種端末読み取り用コードを運用する店舗に関連付けられた、その店舗で販売される商品または商品種別に対応する決済用ページＵＲＬが含まれる。
　サーバ１０は、第１種端末読み取り用コードを運用する店舗については、限定でなく例として、その店舗の店舗ＩＤ（限定でなく、店舗識別情報の一例）と関連付けて、商品または商品種別と、販売金額と、決済用ページＵＲＬとを記憶して管理している。
　第２の種別の端末読み取り用コード（以下、「第２種端末読み取り用コード」と称す。）は、特殊なコードであり、外国の特定の店舗（典型例としては、中国の屋台）やインターネットを利用した電子商取引等で運用されるコードである。この第２種端末読み取り用コードは、第１種端末読み取り用コードとは異なり、利用態様の一例として、サーバ１０側で商品種別や販売金額を管理しておらず、端末２０のユーザが、購入する商品の金額を自身で入力して決済を行うために用いられるコードとすることができる。
　第２種端末読み取り用コードには、限定でなく例として、第２種端末読み取り用コードを運用する店舗に関連付けられた、その店舗に対応する決済用ページＵＲＬが含まれる。
　サーバ１０は、第２種端末読み取り用コードを運用する店舗については、限定でなく例として、その店舗の店舗ＩＤと関連付けて、決済用ページＵＲＬを記憶して管理している。
　なお、本実施形態とは異なり、第１種端末読み取り用コードと第２種端末読み取り用コードとのうちの１種類のコードのみを、端末読み取り用コードとして用いるようにすることもできる。つまり、端末読み取り用コードを２種類に分けずに、第１種端末読み取り用コードのみを端末読み取り用コードとすることもできるし、第２種端末読み取り用コードのみを端末読み取り用コードとすることもできる。
　この場合、本実施形態で説明する機能やデータ、処理等において、適用しない種類の端末読み取り用コードに関する構成は削除することができる。
　図３－２は、本実施形態におけるサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
　記憶部１５には、限定でなく例として、プログラムとして、制御部１１により読み出され、サーバメイン処理として実行されるサーバメイン処理プログラム１５１が記憶される。
　また、サーバメイン処理プログラム１５１は、制御部１１により読み出され、ＩＭＳ処理として実行されるＩＭＳ処理プログラム１５１２と、決済管理処理として実行される決済管理処理プログラム１５１３とをサブルーチンプログラムとして含む。
　決済管理処理については、フローチャートを用いて詳細に後述する。
　また、記憶部１５には、限定でなく例として、データとして、ユーザ登録データ１５３と、店舗登録データ１５５と、決済管理データベース１５７と、コード管理データベース１５９とが記憶される。
　ユーザ登録データ１５３は、決済サービスを利用する端末２０および端末２０のユーザの登録データであり、そのデータ構成の一例を図３－３に示す。
　ユーザ登録データ１５３には、限定でなく例として、ユーザ名と、端末電話番号と、端末メールアドレスと、ユーザＩＤと、認証パスワードと、その他登録情報とが関連付けて記憶される。
　ユーザ名は、決済サービスを利用する端末２０のユーザの名称であり、端末２０のユーザが決済サービスを利用する際に登録する名称が記憶される。
　端末電話番号は、このユーザ名のユーザの端末２０の電話番号であり、端末２０のユーザが決済サービスを利用する際に登録する端末２０の電話番号が記憶される。
　端末メールアドレスは、このユーザ名のユーザの端末２０のメールアドレスであり、端末２０のユーザが決済サービスを利用する際に登録する端末２０のメールアドレスが記憶される。
　端末電話番号や端末メールアドレスは、端末２０を識別するための識別情報（以下、「端末識別情報」と称す。）の一例である。
　ユーザＩＤは、端末２０のユーザを識別するための識別情報として機能するＩＤであり、決済アプリケーションを利用するユーザに固有に設定されるＩＤである。このユーザＩＤは、限定でなく例として、サーバ１０によってユーザごとに固有のＩＤが設定されて記憶される。
　ユーザＩＤは、端末２０のユーザを識別するための識別情報（以下、「ユーザ識別情報」と称す。）の一例である。
　認証パスワードは、このユーザ名のユーザの端末２０において、決済用の認証処理（以下、単に「認証処理」と称す。）を行う際にユーザに入力が要求される認証用のパスワードであり、ユーザによって設定されたパスワードが記憶される。
　その他登録情報は、このユーザ名のユーザのその他の登録情報であり、限定でなく例として、ＩＭＳアプリケーションにおいてユーザが使用するアイコンの画像データであるユーザアイコン画像やユーザのプロフィール等がこれに含まれる。
　なお、上記の各種のユーザ情報は、ＩＭＳアプリケーションと決済アプリケーションとで共通のユーザ情報としてサーバ１０側で記憶・管理するようにすることができる。
　店舗登録データ１５５は、ＩＭＳの事業者（決済サービスの事業者）と提携している店舗の登録データであり、そのデータ構成の一例を図３－４に示す。
　店舗登録データ１５５には、業種と、店舗名と、店舗位置情報と、店舗ＰＯＳシステム情報と、店舗ＩＤと、第１特定業種フラグと、第２特定業種フラグとが店舗情報として関連付けて記憶される。
　業種には、店舗の業種が記憶される。この業種には、限定でなく例として、「コンビニエンスストア」、「スーパーマーケット」、「薬局」、「居酒屋」、「百貨店」、「レストラン」、「本屋」、「時計店」といった各種の業種が含まれる。
　店舗名には、各業種それぞれについて、その業種に含まれる（属する）店舗の店舗名が記憶される。
　店舗位置情報には、この店舗名の店舗の所在地の位置情報（以下、「店舗位置情報」と称す。）が記憶される。この店舗位置情報は、店舗の所在地を２次元または３次元の位置座標で表したものとしてもよいし、店舗の所在地を経緯度（緯度、経度、場合によっては高度）で表したものとしてもよい。
　店舗ＰＯＳシステム情報には、この店舗で使用される店舗ＰＯＳシステム４０に関する情報が記憶される。この店舗ＰＯＳシステム情報には、限定でなく例として、サーバ１０が、店舗コードリーダ装置５０や店舗サーバ７０と通信を行うために必要な情報が含まれる。
　店舗ＰＯＳシステム４０は、サーバ１０と連携して処理を行うため、限定でなく例として、サーバ１０から提供（配布）される決済サービス用のソフトウェアパッケージをあらかじめ取得して店舗コードリーダ装置５０や店舗サーバ７０に記憶させておき、このソフトウェアパッケージを、店舗での決済処理用のプログラムから呼び出して使用するようにすることができる。アプリケーションプログラミングインターフェース（ＡＰＩ）が典型例であり、店舗コードリーダ装置５０は、例えばＡＰＩを起動して、サーバ１０への情報の送信と、サーバ１０からの情報の受信とを実現することができる。
　また、サーバ１０は、限定でなく例として、店舗の業種、店舗名、店舗位置情報、店舗ＰＯＳシステム情報等の情報を、その店舗の店舗サーバ７０から受信して、店舗登録データ１５５に記憶させておくようにすることができる。
　店舗ＩＤは、この店舗名の店舗を識別するための識別情報として機能するＩＤである。この店舗ＩＤは、限定でなく例として、サーバ１０によって店舗ごとに固有のＩＤが設定されて記憶される。
　店舗ＩＤは、店舗を識別するための識別情報（以下、「店舗識別情報」と称す。）の一例である。
　第１特定業種フラグは、この業種が、あらかじめ設定された第１の種別の特定業種（以下、「第１特定業種」と称す。）であるか否かを示すフラグであり、第１特定業種に該当する業種には「ＯＮ」が記憶され、第１特定業種に該当しない業種には「ＯＦＦ」が記憶される。第１特定業種は、限定でなく例として、サーバ１０側であらかじめ設定しておくことができる。この例では、多くのユーザが日常的に利用する業種である「コンビニエンスストア」と「スーパーマーケット」とが、第１特定業種として設定されている。
　第２特定業種フラグは、この業種が、あらかじめ設定された第２の種別の特定業種（以下、「第２特定業種」と称す。）であるか否かを示すフラグであり、第２特定業種に該当する業種には「ＯＮ」が記憶され、第２特定業種に該当しない業種には「ＯＦＦ」が記憶される。第２特定業種も、限定でなく例として、サーバ１０側であらかじめ設定しておくことができる。この例では、ユーザが端末２０を置き忘れるリスクの高い業種である「居酒屋」が、第２特定業種として設定されている。
　決済管理データベース１５７は、各端末２０のユーザの決済に関する情報を管理するためのデータを蓄積的に記憶したデータベースであり、そのデータ構成の一例を図３－５に示す。
　決済管理データベース１５７には、端末２０毎または端末２０のユーザ毎に生成される決済管理データが記憶される。
　各決済管理データには、限定でなく例として、その端末２０のユーザのユーザＩＤと、残高と、ＩＭＳポイントと、１日上限設定金額と、オートチャージ設定と、決済履歴データとが記憶される。
　ユーザＩＤには、ユーザ登録データ１５３に記憶されているユーザＩＤが記憶される。
　残高には、このユーザＩＤのユーザが所有しているＩＭＳマネーの残高（残金）の最新の値が記憶される。
　ＩＭＳポイントには、ＩＭＳの各種サービスや、ＩＭＳの事業者と提携している加盟店舗で貯めることのできるポイントが記憶される。ＩＭＳポイントは、限定でなく例として、１ポイントあたり１円相当の価値を有し、ギフト券や商品等に交換することができる他、決済アプリケーションにおいて現金化して決済に利用することもできる。
　１日上限設定金額には、このユーザＩＤのユーザが決済に使用可能な金額の１日あたりの上限金額が記憶される。
　オートチャージ設定は、残高が残り少ない金額（例えば「５００円」）や「０円」となった場合に、ＩＭＳマネーを自動的に補充（オートチャージ）するか否かの設定であり、端末２０のユーザによってオートチャージの設定がなされた場合は「ＯＮ」が記憶され、それ以外の場合は「ＯＦＦ」が記憶される。オートチャージは、限定でなく例として、端末２０のユーザが登録している銀行口座等から行われるようにすることができる。
　決済履歴データは、このユーザＩＤのユーザの決済の履歴に関するデータであり、限定でなく例として、このユーザＩＤのユーザについて、サーバ１０によって決済が行われた日時である決済日時と、決済した店舗のＩＤである店舗ＩＤと、その店舗ＩＤの店舗の名称である決済店舗名と、決済した金額である決済金額とが関連付けて時系列に記憶される。
　コード管理データベース１５９は、端末表示用コードおよび端末読み取り用コードを管理するためのデータベースであり、端末表示用コード管理データベース１５９１と、端末読み取り用コード管理データベース１５９３とがこれに含まれる。
　端末表示用コード管理データベース１５９１は、端末表示用コードを管理するためのデータベースであり、限定でなく例として、ユーザ登録データ１５３に記憶されているユーザＩＤと、このユーザＩＤから識別されるユーザの端末２０用に生成した端末表示用コードに含まれるトークンとを関連付けたデータが記憶される。
　なお、ユーザ識別情報であるユーザＩＤに代えて、または、これに加えて、ユーザ登録データ１５３に記憶されている端末電話番号等の端末識別情報を端末表示用コード管理データベース１５９１に記憶させるようにしてもよいし、しなくてもよい。
　端末読み取り用コード管理データベース１５９３は、端末読み取り用コードを管理するためのデータベースであり、限定でなく例として、第１種端末読み取り用コードを管理するためのデータと、第２種端末読み取り用コードを管理するためのデータとが記憶される。
　具体的には、第１種端末読み取り用コードについては、限定でなく例として、店舗ＩＤ毎に、その店舗で販売される商品または商品種別と、販売金額と、決済用ページＵＲＬとを関連付けたデータが記憶される。
　なお、本実施形態では、第１種端末読み取り用コードを運用する店舗では、一律の金額（固定金額）で商品が販売されるため、商品または商品種別は関連付けず、販売金額と、決済用ページＵＲＬとを関連付けたデータを記憶させるようにしてもよい。
　また、第２種端末読み取り用コードについては、限定でなく例として、店舗ＩＤ毎に、決済用ページＵＲＬを関連付けたデータが記憶される。
　なお、店舗識別情報である店舗ＩＤに代えて、または、これに加えて、店舗登録データ１５５に記憶されている店舗ＰＯＳシステム情報や、店舗の電話番号、店舗のメールアドレス等の連絡先情報を端末読み取り用コード管理データベース１５９３に記憶させるようにしてもよいし、しなくてもよい。
（２）端末の機能構成
　図３－６は、本実施形態において端末２０の制御部２１により実現される機能の一例を示す図である。
　端末２０は、制御部２１により実現される機能として、端末メイン処理部２１１と、ＩＭＳアプリケーション処理部２１２と、決済アプリケーション処理部２１３と、位置算出処理部２１７とを有する。
　端末メイン処理部２１１は、記憶部２８に記憶されている端末メイン処理プログラム２８１に従って、端末２０を統括的に制御するための処理である端末メイン処理を実行する機能を有している。限定でなく例として、端末２０が携帯電話機である場合には、通信Ｉ／Ｆ２２を介して他の携帯電話機や固定電話機等との通話を行うための制御を行う、または通信Ｉ／Ｆ２２を介して各種のウェブサイトにアクセスするための制御を行う、または表示部２４に各種の情報を表示させる制御を行う、またはマイク２５から入力される各種の音データを解析する処理を行う、またはカメラ２７によって撮影された静止画像や動画像を解析する処理等を実行する。
　ＩＭＳアプリケーション処理部２１２は、記憶部２８に記憶されているＩＭＳアプリケーション２８２に基づいて、サーバ１０を介して他のユーザの端末２０との間でコンテンツの送受信を行うための処理であるＩＭＳアプリケーション処理を実行する機能を有している。
　決済アプリケーション処理部２１３は、記憶部２８に記憶されている決済アプリケーション２８３に基づいて、サーバ１０と通信を行って決済を行うための処理である決済アプリケーション処理を実行する機能を有している。
　決済アプリケーション処理部２１３は、端末表示用コード取得処理部２１３１と、コード読み取り処理部２１３３と、認証スキップ判定処理部２１３５と、認証処理部２１３７とを機能部として有する。
　端末表示用コード取得処理部２１３１は、決済種別「端末コード表示」において、サーバ１０から端末表示用コードを取得するための処理を実行する機能を有している。
　コード読み取り処理部２１３３は、決済種別「端末コード読み取り」において、店舗に掲示される端末読み取り用コードを読み取るための処理を実行する機能を有している。
　認証スキップ判定処理部２１３５は、記憶部２８に記憶されている認証スキップ判定処理プログラム２８４５に従って、認証処理部２１３７によって実行される認証処理をスキップさせるか否かを判定するための処理である認証スキップ判定処理を実行する機能を有している。
　本実施形態では、認証スキップ判定処理部２１３５は、限定でなく例として、決済種別「端末コード表示」では、端末表示用コード取得処理部２１３１の処理に基づきサーバ１０から端末表示用コードを受信した後のタイミングで認証スキップ判定処理を実行する。
　また、認証スキップ判定処理部２１３５は、限定でなく例として、決済種別「端末コード読み取り」では、コード読み取り処理部２１３３の処理に基づき読み取った端末読み取り用コードに含まれる情報に基づいて、サーバ１０から決済の予定に関する情報（以下、「決済予定情報」と称す。）を受信した後のタイミングで認証スキップ判定処理を実行する。
　ただし、これらの認証スキップ判定処理の実行タイミングは、適宜変更可能である。
　認証処理部２１３７は、記憶部２８に記憶されている認証処理プログラム２８４７に従って認証処理を行う機能を有している。
　認証処理では、限定でなく例として、端末２０のユーザに対する認証の実行に関する表示処理として、端末２０のユーザに認証パスワードを入力させるための認証画面を表示部２４に表示させる処理を行い、この認証画面で入力された認証パスワードが、登録されている認証パスワードと一致するか否かを判定する。
　位置算出処理部２１７は、位置算出用情報検出部２９Ｂから出力される位置算出用情報に基づいて、自己の端末２０の位置を算出する処理である位置算出処理を実行する機能を有している。位置算出処理部２１７は、例えば、位置算出用情報検出部２９Ｂに含まれる衛星測位センサ（衛星測位ユニット）から出力される衛星軌道データや時刻データ等に基づいて、衛星測位演算を行って、自己の端末２０の位置を算出する。また、位置算出処理部２１７は、位置算出用情報検出部２９Ｂに含まれる慣性計測センサ（慣性計測ユニット）から出力される加速度や角速度の情報に基づいて、慣性航法演算を行って、自己の端末２０の位置を算出する。
　なお、本実施形態とは異なり、限定でなく例として、処理装置や演算装置（例えばＣＰＵやＤＳＰ）を位置算出用情報検出部２９Ｂに設けるようにし、端末２０の制御部２１ではなく、位置算出用情報検出部２９Ｂが端末２０の位置を算出して出力するようにしてもよいし、しなくてもよい。
　また、限定でなく例として、位置情報を端末２０で取得可能とするための無線装置、例えばビーコン信号（典型例としてはブルートゥース信号）を発信するビーコンを加盟店舗に設置するようにし、端末２０が、店舗に設置されたビーコンから発信されるビーコン信号に基づいて、位置情報を取得するようにしてもよいし、しなくてもよい。
　図３－７は、本実施形態における端末２０の記憶部２８に記憶される情報の一例を示す図である。
　記憶部２８には、限定でなく例として、制御部２１により読み出され、端末メイン処理として実行される端末メイン処理プログラム２８１と、制御部２１により読み出され、位置算出処理として実行される位置算出処理プログラム２８７とが記憶される。
　また、記憶部２８には、限定でなく例として、サーバ１０からあらかじめダウンロードするなどして取得されるアプリケーションソフトウェアとして、ＩＭＳアプリケーション２８２と、決済アプリケーション２８３とが記憶される。
　なお、ＩＭＳアプリケーション２８２と決済アプリケーション２８３とは、１つのアプリケーションとしてもよいし、別のアプリケーションとしてもよい。
　また、記憶部２８には、限定でなく例として、端末データ２８６と、算出位置履歴データ２８８とが記憶される。
　端末データ２８６は、この端末２０に関するデータであり、限定でなく例として、端末電話番号や端末メールアドレス等の端末識別情報や、端末２０のＯＳ側のロック設定「ＯＮ／ＯＦＦ」、端末２０のＯＳ側のロックを解除するための端末ロック解除パスワード、端末側の認証設定「ＯＮ／ＯＦＦ」等の情報がこれに含まれる。
　算出位置履歴データ２８８には、限定でなく例として、位置算出処理部２１７が所定時間毎（例えば、「1分毎」や「５分毎」、「１０分毎」）で位置算出処理を行うことで算出した端末２０の位置（以下、「算出位置」と称す。）の履歴が記憶される。
　決済アプリケーション２８３は、制御部２１により読み出され、決済アプリケーション処理として実行される決済アプリケーションプログラム２８４と、決済アプリケーションに関する各種のデータが格納された決済アプリケーションデータ２８５とを含む。
　決済アプリケーションプログラム２８４は、限定でなく例として、制御部２１により読み出され、認証スキップ判定処理として実行される認証スキップ判定処理プログラム２８４５と、制御部２１により読み出され、認証処理として実行される認証処理プログラム２８４７とをサブルーチンプログラムとして含む。
　決済アプリケーションデータ２８５は、限定でなく例として、認証スキップ条件データ２８５１と、決済用データ２８５３と、店舗データ２８５５とを含む。
　店舗データ２８５５には、限定でなく例として、サーバ１０の店舗登録データ１５５に記憶されている業種と、第１特定業種フラグと、第２特定業種フラグとを関連付けた店舗情報が記憶される。
　この店舗データ２８５５は、例えば、ＩＭＳアプリケーション２８２や決済アプリケーション２８３のアップデートのタイミングで、サーバ１０から最新の店舗情報が端末２０に配信されて更新されるようにすることができる。
　認証スキップ条件データ２８５１は、認証処理をスキップするための条件である認証スキップ条件が定められたデータであり、そのデータ構成の一例を図３－８に示す。
　認証スキップ条件データ２８５１には、認証スキップ条件のカテゴリの番号である条件カテゴリＮｏと、この条件カテゴリＮｏのカテゴリに含まれる認証スキップ条件の番号である条件Ｎｏと、この条件Ｎｏの認証スキップ条件と、この認証スキップ条件を適用して判定を行うか否かを示す適用有無と、この認証スキップ条件の重要度（優先度）とが関連付けて記憶されている。以下、それぞれの認証スキップ条件、および、その判定方法について詳細に説明する。
＜条件カテゴリＮｏ「ＳＰ１」＞
　条件カテゴリＮｏ「ＳＰ１」は「時間」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ１－１」、「ＳＰ１－２」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ１－１」の認証スキップ条件として、「現在日時が最終決済日時から設定時間内」が定められている。
　「最終決済日時」は、端末２０で認証処理がスキップされたか否かに関わらず、最後に決済が行われた日時（決済が行われた最新の日時）である。これは、現在日時が最終決済日時から設定時間内（例えば「１時間内」）であるということは、それほど時間が経過しない間に再び決済を行うことになるため、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、限定でなく例として、端末２０が、時計部２９Ａで計時している計時時刻に基づく現在日時と、決済用データ２８５３の決済履歴データに記憶されている最終決済日時とを取得して、現在日時が最終決済日時から設定時間内であるか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ１－２」の認証スキップ条件として、「現在時刻が設定時間帯に含まれる」が定められている。設定時間帯は、限定でなく例として、端末２０のユーザがあらかじめ設定しておくようにすることができる。具体的には、例えば、端末２０のユーザが、自身が頻繁に決済を行う時間帯を設定時間帯として設定しておくことで、設定時間帯に決済を行う場合に認証を省略させることができる。
　この認証スキップ条件の判定では、限定でなく例として、端末２０が、時計部２９Ａで計時している計時時刻に基づく現在時刻を取得して、現在時刻が設定時間帯に含まれるか否かを判定するようにすればよい。
＜条件カテゴリＮｏ「ＳＰ２」＞
　条件カテゴリＮｏ「ＳＰ２」は「店舗・場所」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ２－１」～「ＳＰ２－４」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ２－１」の認証スキップ条件として、「決済予定店舗で過去に決済または決済用の認証を行ったことあり」が定められている。
　「決済予定店舗」とは、これから決済を行う予定の店舗（決済前の未確定の状態の店舗）を意味する。つまり、これから決済を行う店舗で過去に決済またはそのための認証を行ったことがある場合は、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、算出位置履歴データ２８８に記憶されている算出位置の履歴および最新の算出位置と、決済履歴データに記憶されている決済日時とを取得して、過去の決済日時と同じ日時に対応する算出位置の中に、最新の算出位置と一致する算出位置が存在するか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ２－２」の認証スキップ条件として、「決済予定店舗が設定店舗」が定められている。設定店舗は、基本的には、サーバ１０側で設定しておくようにすることができる。限定でなく例として、サーバ１０側で、統計的にユーザの利用頻度が高い店舗を集計して、設定店舗として設定しておくようにすることができる。これは、ユーザの利用頻度が高い店舗では、ユーザの利便性向上のため、認証を省略することを意味する。
　なお、サーバ１０側ではなく、端末２０側で設定店舗の設定を行うことを可能としてもよい。例えば、端末２０のユーザが、自身の利用頻度が高い店舗を設定店舗として端末２０に設定させることができる。また、例えば、端末２０のユーザが、特定の業種の店舗（例えばコンビニエンスストア）について、自宅の近くの店舗は安全であるとして設定店舗として設定するが、それ以外の店舗はリスクがあるとして設定店舗として設定しないようにすることもできる。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、算出位置履歴データ２８８に記憶されている算出位置の履歴と、決済履歴データに記憶されている決済店舗名と、店舗データ２８５５に記憶されている店舗情報とを取得して、過去の設定店舗での決済日時と同じ日時に対応する算出位置の中に、最新の算出位置と一致する算出位置が存在するか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ２－３」の認証スキップ条件として、「決済予定店舗が第１特定業種の店舗」が定められている。前述したように、第１特定業種は、前述したように、「コンビニエンスストア」や「スーパーマーケット」といった、多くのユーザが日常的に利用する業種が定められている。これらの店舗で決済を行う場合は、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、算出位置履歴データ２８８に記憶されている算出位置の履歴と、決済履歴データに記憶されている決済店舗名と、店舗データ２８５５に記憶されている第１特定業種フラグとを取得して、第１特定業種フラグ「ＯＮ」の店舗での過去の決済日時と同じ日時に対応する算出位置の中に、最新の算出位置と一致する算出位置が存在するか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ２－４」の認証スキップ条件として、「第２特定業種の店舗での決済日時から設定時間超」が定められている。第２特定業種は、前述したように、「居酒屋」といった、ユーザが端末２０を置き忘れるリスクが高い業種を設定しておくことができる。また、設定時間は、例えば「３時間」や「６時間」、「１２時間」といった時間を設定しておくことができる。端末２０を置き忘れるリスクが高い店舗で決済が行われた場合は、その決済日時から設定時間を超えるまでの間は認証を必須とするが、決済日時から設定時間を超えると、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、時計部２９Ａで計時している計時時刻に基づく現在日時と、記憶部２８の決済用データ２８５３の決済履歴データに記憶されている決済日時と、店舗データ２８５５に記憶されている第２特定業種フラグとを取得して、現在日時が第２特定業種フラグ「ＯＮ」の店舗での決済日時から設定時間を超えているか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ３」＞
　条件カテゴリＮｏ「ＳＰ３」は「金額」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ３－１」～「ＳＰ３－３」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ３－１」の認証スキップ条件として、「１日上限設定金額を超えていない」が定められている。
　「１日上限設定金額」は、その１日で既に決済された決済金額（決済済みの金額）の合計金額に対する閾値とされる上限の設定金額である。つまり、その１日で既に決済された決済金額の合計金額が１日上限設定金額を超えていない場合は、ユーザの利便性向上のため、認証を省略することを意味する。
　また、逆に、その１日で既に決済された決済金額の合計金額が１日上限設定金額を超えている場合は、認証を行うようにすることで、決済でお金を使い過ぎていることを注意喚起することができる。また、未成年者等が決済を行う場合に、保護者が利用に制限をかけるようにすることができる。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、決済用データ２８５３に記憶されている１日上限設定金額と、決済履歴データから特定されるその１日の決済金額の合計金額とを取得して、合計金額が１日上限設定金額を超えているか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ３－２」の認証スキップ条件として、「残高が設定金額以下（または設定金額未満）、かつ、オートチャージ設定ＯＦＦ」が定められている。設定金額は、限定でなく例として、端末２０のユーザがあらかじめ設定しておくようにすることができる。これは、残高が設定金額以下（または設定金額未満）であれば、ユーザは高額の商品を決済で購入することができず、危険性は低いと考えられるため、ユーザの利便性向上のため、認証を省略する。
　しかしながら、オートチャージ設定が「ＯＮ」であれば、ＩＭＳマネーが自動的に補充されるため、ユーザは高額の商品を決済で購入することが可能となり、リスクが生ずる。そこで、残高が設定金額以下（または設定金額未満）であることに加えて、オートチャージ設定が「ＯＦＦ」であることを、認証スキップの条件とする。
　なお、この場合、オートチャージ設定が「ＯＮ」であれば、残高が設定金額以下（または設定金額未満）であっても、原則的には認証処理がスキップされないことになる。しかしながら、上記のようにユーザの利便性向上を考え、オートチャージ設定が「ＯＮ」であっても、認証処理をスキップさせるようにすることもできる。この場合、限定でなく例として、上記の条件Ｎｏ「ＳＰ３－２」の認証スキップ条件からオートチャージ設定ＯＦＦを除外し、「残高が設定金額以下（または設定金額未満）」とすればよい。つまり、オートチャージ設定が「ＯＮ」であっても、必ずしも認証処理を必須としなければならないわけではなく、あくまでもオートチャージが「ＯＮ」の場合、残高が設定金額以下（または設定金額未満）であれば、認証処理を行う場合があってもよいし、認証処理を行わない場合があってもよい。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、決済用データ２８５３に記憶されている残高およびオートチャージ設定を取得して、残高が設定金額以下（または設定金額未満）であり、かつ、オートチャージ設定が「ＯＦＦ」であるか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ３－３」の認証スキップ条件として、「ひと月あたりの決済頻度または決済金額の適正範囲内」が定められている。例えば、過去所定期間（過去６か月間や過去１年間）における、ひと月あたりの決済頻度の平均値や最大値、最頻値を閾値頻度とし、同じく過去所定期間における、ひと月あたりの決済金額の平均値や最大値、最頻値を閾値金額として算出する。そして、これから決済を行うことで、決済頻度が閾値頻度を超える場合または決済金額が閾値金額を超える場合は、認証を行うこととし、それ以外の場合は、認証を省略する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、決済用データ２８５３に記憶されている決済履歴データから算出される決済頻度および決済金額と、記憶部２８に記憶されている閾値頻度および閾値金額とを取得して、決済頻度が閾値頻度を超えるか否か、決済金額が閾値金額を超えるか否かを判定するようにすることができる。
　なお、上記の認証スキップ条件を、ＩＭＳマネーによって決済を行った頻度（決済頻度）に基づく条件ではなく、ＩＭＳマネーによって決済を行った回数（決済回数）に基づく条件としてもよいし、しなくてもよい。また、決済頻度が適正範囲内であること、決済回数が適正範囲内であること、決済金額が適正範囲内であること、をそれぞれ個別の条件として定めておくようにしてもよいし、しなくてもよい。
　条件Ｎｏ「ＳＰ３－４」の認証スキップ条件として、「決済予定金額が設定金額以下（または設定金額未満）」が定められている。設定金額は、例えば「１万円」や「２万円」といった、常識的な考えや社会通念に照らして、一度に決済される金額としてそれほど高額とは言えない範囲の金額を設定しておくことができる。
　「決済予定金額」とは、これから決済を行う予定の金額（決済前の未確定の状態の金額）を意味する。つまり、これから決済を行う金額がそれほど高額ではない場合は、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、決済予定金額をサーバ１０から取得して、決済予定金額が設定金額以下（または設定金額未満）であるか否かを判定するようにすることができる。
　ただし、本実施形態において、決済種別「端末コード表示」では、端末２０は、サーバ１０から端末表示用コードを受信した後のタイミングで認証スキップ判定処理を実行するようにしている。しかしながら、このタイミングでは、端末２０はサーバ１０から決済予定情報を未だ取得しておらず、決済予定金額が不明の状態である。このため、本実施形態では、決済種別「端末コード表示」については条件Ｎｏ「ＳＰ３－４」の認証スキップ条件を適用不可「×」とし、決済種別「端末コード読み取り」についてのみ適用可能「〇」とする。
＜条件カテゴリＮｏ「ＳＰ４」＞
　条件カテゴリＮｏ「ＳＰ４」は「商品」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ４－１」、「ＳＰ４－２」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ４－１」の認証スキップ条件として、「購入予定商品が日用消費財」が定められている。
　「購入予定商品」は、これから決済を行って購入する予定の商品（決済前の未確定の状態の商品）を意味する。つまり、これから決済を行って購入する予定の商品が日用消費財である場合は、ユーザの利便性向上のため、認証を省略することを意味する。
　条件Ｎｏ「ＳＰ４－２」の認証スキップ条件として、「購入予定商品の購入履歴あり」が定められている。これは、購入予定商品が端末２０のユーザが一度以上購入した商品と一致した場合、ユーザの利便性向上のため、認証を省略することを意味する。
　これらの認証スキップ条件を判定するためには、端末２０が購入予定商品に関する情報を取得する必要がある。しかしながら、本実施形態では、決済種別「端末コード表示」、「端末コード読み取り」のいずれについても、購入予定商品に関する情報は、サーバ１０から端末２０に送信されない仕様となっている。このため、端末２０は、条件カテゴリＮｏ「ＳＰ４（商品）」に含まれる認証スキップ条件については判定不可となる。
　本実施形態では、決済種別「端末コード読み取り」について、代替的な手法として以下説明する手法を用いて、条件Ｎｏ「ＳＰ４－１」、「ＳＰ４－２」の認証スキップ条件の成否を判定する。
　まず、条件Ｎｏ「ＳＰ４－１」の認証スキップ条件について、端末２０は、端末読み取り用コードを読み取った後、この端末読み取り用コードに含まれる決済用ページＵＲＬに基づいて決済用ページにアクセスし、この決済用ページＵＲＬに関連付けられた店舗ＩＤおよび販売金額をサーバ１０から取得する。そして、端末２０は、サーバ１０から取得した店舗ＩＤから識別される店舗が第１特定業種の店舗であり、かつ、販売金額が閾値金額以下（または閾値金額未満）である場合に、購入予定商品が日用消費財であると判定する。
　次に、条件Ｎｏ「ＳＰ４－２」の認証スキップ条件について、端末２０は、端末読み取り用コードを読み取った後、上記と同様に決済用ページにアクセスして、決済用ページＵＲＬに関連付けられた店舗ＩＤおよび販売金額をサーバ１０から取得する。そして、端末２０は、決済履歴データに記憶されている決済店舗ＩＤおよび決済金額の中に、サーバ１０から取得した店舗ＩＤおよび販売金額とそれぞれ一致する決済店舗ＩＤおよび決済金額があるか否かを判定し、一致するものがあった場合は、購入予定商品の購入履歴ありと判定する。
＜条件カテゴリＮｏ「ＳＰ５」＞
　条件カテゴリＮｏ「ＳＰ５」は「セキュリティ」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ５－１」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ５－１」の認証スキップ条件として、「端末ロック中、または、決済アプリケーションロック中」が定められている。これは、端末２０のＯＳ（Operating System）側にロックがかかっている状態や、決済アプリケーション側にロックがかかっている状態では、これらのロック状態を解除するために、それぞれ端末ロック解除パスワードや決済アプリケーションロック解除パスワードの入力等による認証が必要となる。このため、ユーザの利便性向上のため、決済用の認証は不要とすることを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、端末データ２８６に記憶されている端末２０のＯＳ側のロック有無の情報と、決済アプリケーションデータ２８５に記憶されている決済アプリケーション側のロック有無の情報とを取得して、端末ロック中、または、決済アプリケーションロック中であるか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ６」＞
　条件カテゴリＮｏ「ＳＰ６」は「認証設定」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ６－１」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ６－１」の認証スキップ条件として、「端末側の認証設定ＯＦＦ、または、決済アプリケーション側の認証設定ＯＦＦ」が定められている。
　端末側の認証は、ユーザの本人認証等を含む端末２０側でユーザに要求される各種の認証である。決済アプリケーション側の認証は、決済アプリケーションを利用して決済を行う際にユーザに要求される認証である。
　これは、端末２０のユーザによって、端末２０側で認証を省略する設定がなされている場合、または、決済アプリケーション側で認証を省略する設定がなされている場合は、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、端末データ２８６に記憶されている端末側の認証設定と、決済用データ２８５３の認証スキップ条件ユーザ設定データに記憶されている条件Ｎｏ「ＳＰ６－１」の条件別設定フラグとを取得して、端末側の認証設定と、決済アプリケーション側の認証設定との少なくともいずれか一方が「ＯＦＦ」であるか否かを判定するようにすることができる。
　また、上記の認証スキップ条件それぞれについて、その認証スキップ条件を適用して認証スキップ判定を行うか否かの適用有無が、決済種別毎に定められている。
　具体的には、決済種別「端末コード表示」については、限定でなく例として、条件Ｎｏ「ＳＰ３－３」、「ＳＰ３－４」、「ＳＰ４－１」、「ＳＰ４－２」の認証スキップ条件には適用無し「×」が定められ、それ以外の認証スキップ条件には適用有り「〇」が定められている。
　条件Ｎｏ「ＳＰ３－３」の認証スキップ条件が適用無し「×」とされているのは、決済種別「端末コード表示」では、端末２０が決済予定金額に関する情報を取得できず、決済予定金額が適正範囲内であるか否かを判定することができないためである。ただし、決済頻度が適正範囲内であるか否かの判定は可能であるため、決済予定金額が適正範囲内であるか否かの判定は省略するようにしてもよいし、しなくてもよい。
　同様に、条件Ｎｏ「ＳＰ３－４」の認証スキップ条件が適用無し「×」とされているのは、端末２０が決済予定金額に関する情報を取得できず、決済予定金額が設定金額以下（または設定金額未満）であるか否かを判定することができないためである。
　また、条件Ｎｏ「ＳＰ４－１」、「ＳＰ４－２」の認証スキップ条件が適用無し「×」とされているのは、決済種別「端末コード表示」では、前述したように、端末２０が購入予定商品に関する情報を取得することができないため、購入予定商品が日用消費財であるか否かを判定することも、購入予定商品の購入履歴があるか否かを判定することもできないためである。
　一方、決済種別「端末コード読み取り」については、限定でなく例として、条件Ｎｏ「ＳＰ４－１」、「ＳＰ４－２」の認証スキップ条件には、原則的には適用不可であるが、前述した代替的な手法によって適用可能であるため、「×（〇）」が定められている。
　また、限定でなく例として、上記の認証スキップ条件それぞれについて、その認証スキップ条件の重要性の度合を示す指標値である「重要度」（認証スキップ条件を優先的に適用する度合を示す「優先度」とも言える。）が、決済種別毎に定められている。重要度は、限定でなく例として、「Ａ」～「Ｃ」の３段階で表され、「Ａ」が最も重要性が高く、「Ｃ」が最も重要性が低くなるように重要度が定められている。
　具体的には、決済種別「端末コード表示」については、限定でなく例として、条件Ｎｏ「ＳＰ１－１」、「ＳＰ２－１」、「ＳＰ２－４」、「ＳＰ３－１」、「ＳＰ３－２」、「ＳＰ５－１」、「ＳＰ６－１」の認証スキップ条件には重要度「Ａ」が定められ、条件Ｎｏ「ＳＰ２－２」、「ＳＰ２－３」の認証スキップ条件には重要度「Ｂ」が定められ、条件Ｎｏ「ＳＰ１－２」の認証スキップ条件には重要度「Ｃ」が定められている。また、条件Ｎｏ「ＳＰ３－３」、「ＳＰ３－４」、「ＳＰ４－１」、「ＳＰ４－２」の認証スキップ条件は適用不可であるため、重要度には「－（なし）」が定められている。
　また、決済種別「端末コード読み取り」については、限定でなく例として、条件Ｎｏ「ＳＰ２－１」、「ＳＰ２－４」、「ＳＰ３－４」、「ＳＰ４－１」、「ＳＰ４－２」、「ＳＰ６－１」の認証スキップ条件には重要度「Ａ」が定められ、条件Ｎｏ「ＳＰ１－１」、「ＳＰ２－２」、「ＳＰ２－３」、「ＳＰ３－１」、「ＳＰ３－２」、「ＳＰ５－１」の認証スキップ条件には重要度「Ｂ」が定められ、条件Ｎｏ「ＳＰ１－２」、「ＳＰ３－３」の認証スキップ条件には重要度「Ｃ」が定められている。
　なお、上記の重要度の設定はあくまでも一例を示したものに過ぎず、適宜設定変更可能であることは勿論である。また、上記では、認証スキップ条件毎（条件Ｎｏ毎）に適用有無や重要度が定められているが、これに代えて、認証スキップ条件のカテゴリ毎（条件カテゴリＮｏ）毎に適用有無や重要度を定めておくようにしてもよいし、しなくてもよい。
　また、本実施形態では、認証スキップ条件に関連付けて重要度を設定しているが、この重要度の設定は必須の要件ではなく、重要度を設定しないようにすることもできる。つまり、上記の認証スキップ条件データ２８５１において重要度の欄は設けられていなくてもよい。
　この場合は、認証スキップ判定処理において、限定でなく例として、任意の順序で認証スキップ条件の成否を判定していき、いずれかの認証スキップ条件が成立する場合に、認証処理をスキップさせると判定するようにすればよい。
　上記の認証スキップ条件データ２８５１における認証スキップ条件のカテゴリが示す情報や、各カテゴリに含まれる各認証スキップ条件の判定に使用される情報は、ＩＭＳマネー（限定でなく、電子貨幣の一例）に関する情報に含まれる。
　具体的には、例えば、「ＳＰ１（時間）」のカテゴリは、ＩＭＳマネーによって決済を行った時間に関する情報を含むが、この情報は、広義にはＩＭＳマネーに関する情報と言える。
　また、例えば、「ＳＰ２（店舗・場所）」のカテゴリは、ＩＭＳマネーによって決済を行った場所に関する情報や、ＩＭＳマネーによって決済を行った店舗に関する情報を含むが、これらの情報は、広義にはＩＭＳマネーに関する情報と言える。
　また、例えば、「ＳＰ３（金額）」のカテゴリは、ＩＭＳマネーの金額に関する情報を含むが、この情報は、広義にはＩＭＳマネーに関する情報と言える。
　また、例えば、「ＳＰ４（商品）」のカテゴリは、ＩＭＳマネーによって購入する商品に関する情報を含むが、この情報は、広義にはＩＭＳマネーに関する情報と言える。
　なお、「～に関する情報」という用語の意味合いは、他の例についても同様であるため、その都度の説明は省略する。
　図３－９は、決済用データ２８５３のデータ構成の一例を示す図である。
　決済用データ２８５３には、ユーザＩＤと、認証パスワードと、決済アプリケーションのロック状態を解除するためのパスワードである決済アプリケーションロック解除パスワードと、ＩＭＳポイントと、残高と、１日上限設定金額と、オートチャージ設定と、決済履歴データと、認証スキップ条件設定と、認証スキップ条件ユーザ設定データとが記憶される。
　決済履歴データには、サーバ１０の決済管理データベース１５７で管理される、このユーザＩＤの決済管理データに記憶される決済履歴データと同様のデータが記憶される。この決済履歴データは、限定でなく例として、サーバ１０によって決済が行われた後、決済日時と、決済店舗ＩＤと、決済店舗名と、決済金額とがサーバ１０から端末２０に送信され、その履歴が決済履歴データとして記憶される。
　認証スキップ条件設定は、自己の端末２０が認証スキップ判定に用いる認証スキップ条件に関する設定である。認証スキップ条件設定には、限定でなく例として、「ユーザ設定」と、「自動設定」とが含まれる。
　「ユーザ設定」は、認証スキップ条件データ２８５１に定められた認証スキップ条件の中から端末２０のユーザの選択・決定操作に基づいて決定した認証スキップ条件を適用して、認証スキップ判定を行う設定である。
　「自動設定」は、認証スキップ条件データ２８５１に定められた認証スキップ条件の中から端末２０が自動で決定した認証スキップ条件を用いて認証スキップ判定を行う設定である。
　認証スキップ条件ユーザ設定データは、上記の認証スキップ条件設定「ユーザ設定」に関する設定データであり、そのデータ構成の一例を図３－１０に示す。
　認証スキップ条件ユーザ設定データには、条件カテゴリＮｏと、条件Ｎｏと、設定種別と、条件カテゴリ別設定フラグと、条件別設定フラグとが関連付けて記憶される。
　条件カテゴリＮｏと条件Ｎｏとには、それぞれ認証スキップ条件データ２８５１に定められた条件カテゴリＮｏと条件Ｎｏとが記憶される。
　設定種別には、「条件カテゴリ別」と「条件別」とのうちのいずれかが記憶される。
　設定種別「条件カテゴリ別」は、端末２０のユーザが、条件カテゴリ別に、適用する認証スキップ条件を設定するための種別である。つまり、カテゴリ毎に一括して認証スキップ条件を適用する設定を行う場合に、この設定種別「条件カテゴリ別」が用いられる。
　設定種別「条件別」は、端末２０のユーザが、条件別に、適用する認証スキップ条件を設定するための種別である。つまり、条件毎に個別に認証スキップ条件を適用する設定を行う場合に、この設定種別「条件別」が用いられる。
　条件カテゴリ別設定フラグは、設定種別が「条件カテゴリ別」である場合に、その条件カテゴリＮｏに含まれる認証スキップ条件を適用するか否かを示すフラグであり、適用する条件カテゴリについては、その条件カテゴリＮｏに関連付けて「ＯＮ」が設定され、適用しない条件カテゴリについては、その条件カテゴリＮｏに関連付けて「ＯＦＦ」が設定される。
　条件別設定フラグは、設定種別が「条件別」である場合に、その条件Ｎｏの認証スキップ条件を適用するか否かを示すフラグであり、適用する条件については、その条件Ｎｏに関連付けて「ＯＮ」が設定され、適用しない条件については、その条件Ｎｏに関連付けて「ＯＦＦ」が設定される。限定でなく例として、条件カテゴリ別設定フラグが「ＯＮ」に設定されているカテゴリについては、条件別設定フラグも全て「ＯＮ」に設定される。
（３）店舗コードリーダ装置の機能構成
　図２には、本実施形態において店舗コードリーダ装置５０の制御部５１により実現される機能の一例を示している。
　店舗コードリーダ装置５０は、制御部５１により実現される機能として、店舗コードリーダ装置メイン処理部５１１と、店舗決済処理部５１３とを有する。
　店舗コードリーダ装置メイン処理部５１１は、記憶部５５に記憶されている店舗コードリーダ装置メイン処理プログラム５５１に従って、店舗コードリーダ装置５０を統括的に制御するための処理である店舗コードリーダ装置メイン処理を実行する機能を有している。
　店舗決済処理部５１３は、記憶部５５に記憶されている店舗決済処理プログラム５５１１に従って、自店舗での決済に関する処理である店舗決済処理を実行する機能を有している。
　図２には、本実施形態における店舗コードリーダ装置５０の記憶部５５に記憶される情報の一例を示している。
　記憶部５５には、限定でなく例として、制御部５１により読み出され、店舗コードリーダ装置メイン処理として実行される店舗コードリーダ装置メイン処理プログラム５５１が記憶される。また、店舗コードリーダ装置メイン処理プログラム５５１は、制御部５１により読み出され、店舗決済処理として実行される店舗決済処理プログラム５５１１をサブルーチンプログラムとして含む。
　店舗決済処理については、フローチャートを用いて詳細に後述する。
＜決済方法＞
　端末２０の表示部２４に表示される表示画面例を参照して、本実施形態における決済アプリケーションを利用した決済方法について説明する。
（１）決済種別「端末コード表示」
　図３－１１～図３－１４は、決済種別「端末コード表示」における認証スキップなしの場合の決済の流れを説明するための画面図である。
　図３－１１は、端末２０の表示部２４に表示される決済アプリケーション画面の一例を示す図である。
　この決済アプリケーション画面は、決済アプリケーションを起動した際に表示される表示画面であり、画面上部に、決済アプリケーションの名称である「ＩＭＳ　Ｐａｙ」が表示されている。その下の枠内には、残高（ここでは「３０００円」）が表示されており、その横に、金額をチャージするためのチャージボタンが表示されている。また、その下には、決済アプリケーションの各種の機能に対応する複数の機能アイコンが表示されている。
　これらの機能アイコンのうち、「コード」と示されたアイコンは、決済種別「端末コード表示」で決済を行う際に、サーバ１０から端末表示用コードを取得するための「コードアイコン」である。また、「コードリーダ」と示されたアイコンは、決済種別「端末コード読み取り」で決済を行う際に、端末２０で端末読み取り用コードを読み取るために、決済アプリケーションの機能として備えられたコードリーダ（以下、「アプリケーションコードリーダ」と称す。）を起動させるためのコードリーダアイコンである。
　図３－１２は、上記の決済アプリケーション画面において「コードアイコン」が端末２０のユーザによってタッチされた場合に表示される認証画面の一例を示す図である。
　後述する認証スキップ判定処理で認証処理をスキップする判定がなされなかった場合は、この認証画面が表示される。
　この認証画面には、「パスワード」（認証パスワード）という文字とともに、「現在使用中のパスワードを入力してください。」というメッセージが表示され、その下に、入力されたパスワードが表示されるパスワード表示欄と、パスワードを入力するためのキーボードとが表示されている。
　図３－１３は、上記の認証画面でのパスワード入力に基づく認証処理で認証結果が「ＯＫ」となった場合に表示される端末表示用コード画面の一例を示す図である。
　この端末表示用コード画面には、画面上部に「コード」の文字が表示され、その下に、決済方法と、ＩＭＳポイントを利用して決済を行うか否かを設定するためのＩＭＳポイントタブが表示されている。また、その下には、サーバ１０から送信されて端末２０が受信した端末表示用コードとして、バーコードで表される端末表示用コードと、ＱＲコードで表される端末表示用コードとが表示されている。また、これらの端末表示用コードには、前述したように有効期間が設定されており、端末表示用コードと関連付けて、有効期間の残り時間がカウントダウン形式で表示されている。
　端末２０のユーザは、上記の端末表示用コード画面をコードレジ６０で店舗の店員に提示し、店舗コードリーダ装置５０で端末表示用コードを読み取ってもらうことで決済を行う。この場合、店舗コードリーダ装置５０は、読み取った端末表示用コードに含まれる決済用ページＵＲＬに基づいて決済用ページにアクセスして、決済に必要な情報を送信する。
　図３－１４は、サーバ１０による決済が完了した場合に端末２０に表示される決済完了画面の一例を示す図である。
　この決済完了画面では、図３－１３の端末表示用コード画面の画面中央部に「決済完了」の文字とともに、「「決済履歴」から詳細が確認できます。」というメッセージと、決済履歴を確認するための「確認アイコン」とがポップアップ形式で表示されている。
　図３－１５、図３－１６は、決済種別「端末コード表示」における認証スキップありの場合の決済の流れを説明するための画面図である。
　図３－１５には図３－１１と同じ決済アプリケーション画面を示しており、図３－１６には図３－１３と同じ端末表示用コード画面を示している。
　図３－１５の決済アプリケーション画面において「コードアイコン」が端末２０のユーザによってタッチされた場合、後述する認証スキップ判定処理で認証処理をスキップする判定がなされた場合は、図３－１６の端末表示用コード画面に表示が切り替わる。つまり、図３－１２の認証画面が表示されることなく、決済アプリケーション画面から端末表示用コード画面に表示が切り替わる。
（２）決済種別「端末コード読み取り」
　前述したように、決済種別「端末コード読み取り」には、第１種端末読み取り用コードを読み取る場合と、第２種端末読み取り用コードを読み取る場合との２種類がある。このそれぞれについて説明する。
（２－１）第１種端末読み取り用コード
　図３－１７には、図３－１１と同じ決済アプリケーション画面を示しており、機能アイコンのうちの「コードリーダアイコン」がタップされた状態を示している。
　コードリーダアイコンがユーザによりタップされると、アプリケーションコードリーダが起動され、図３－１８に示すような読み取り待機画面が表示部２４に表示される。この状態で、画面中央部の枠内に二次元コードが含まれるように端末２０を移動させると、アプリケーションコードリーダによって二次元コードが読み取られる。
　図３－１９は、アプリケーションコードリーダによって二次元コードが読み取られた場合に表示部２４に表示される表示画面の一例を示す図であり、アプリケーションコードリーダによって第１種端末読み取り用コードが読み取られた状態を示している。
　端末２０により第１種端末読み取り用コードが読み取られると、端末２０は、読み取った第１種端末読み取り用コードに含まれるＵＲＬに基づいて決済用ページにアクセスして、決済に必要な情報を送信する。
　図３－２０は、端末２０の表示部２４に表示される決済用ページ画面の一例を示す図である。
　この決済用ページ画面には、画面上部に、決済予定店舗（ここでは「ＸＸＸ　ＳＨＯＰ」）と、決済を行う日付（ここでは「２０１８／１０／２４」）と、決済予定金額（ここでは「４８０円））とが表示されている。その下には、決済方法と、ＩＭＳポイントを使用して決済を行うか否かを設定するためのＩＭＳポイントタブとが表示されている。また、その下には、「決済を行う」と示された決済を実行するための決済実行アイコンが表示されている。
　図３－２１は、上記の決済用ページ画面において決済実行アイコンが端末２０のユーザによってタップされた場合に表示される決済完了画面の一例を示す図である。
　この決済完了画面では、決済用ページ画面の中央部に、「決済完了」の文字とともに、「「決済履歴」から詳細が確認できます。」というメッセージと、決済履歴を確認するための「確認アイコン」とがポップアップ形式で表示されている。
（２－２）第２種端末読み取り用コード
　図３－２２～図３－２４には、図３－１７～図３－１９と同様の表示画面を示している。
　図３－２５は、第２種端末読み取り用コードを読み取った後、端末２０がサーバ１０にアクセスした場合に表示される決済予定金額入力設定画面の一例を示す図である。
　この決済予定金額入力設定画面には、端末２０のユーザのアイコン画像とともに、決済予定店舗（ここでは「ＸＸＸ　ＳＨＯＰ」）が表示され、その下に、入力された決済予定金額が表示される決済予定金額表示欄と、現在の残高と、決済予定金額を入力するためのキーボードとが表示されている。
　この決済予定金額入力設定画面において、例えば図３－２６に示すように、端末２０のユーザによって決済予定金額が入力され（ここでは「４８０円」）、その下に表示されている「完了アイコン」がタップされると、キーボードが非表示とされ、例えば図３－２７に示すように、「決済を行う」と示された決済を実行するための決済実行アイコンが表示される。そして、決済実行アイコンが端末２０のユーザによってタップされると、例えば３－２８に示すように決済完了画面が表示される。
＜処理＞
　図３－２９～図３－３２は、本実施形態における各装置が実行する処理の流れの一例を示すフローチャートである。
　これらの図では、左側から順に、端末２０の決済アプリケーション処理部２１３が実行する決済アプリケーション処理の一例である第１決済アプリケーション処理、店舗コードリーダ装置５０の店舗決済処理部５１３が実行する店舗決済処理の一例である第１の店舗決済処理、サーバ１０の決済管理処理部１１３が実行する決済管理処理の一例である第１の決済管理処理をそれぞれ示している。
　各処理における各ステップをアルファベットの大文字と数字の組み合わせで示し、本明細書では、ステップの用語は省略する。
　また、以下説明するフローチャートは、あくまでも本実施形態における処理を例示するものであり、以下説明するフローチャートにおいて、一部のステップを実行しなくてもよいし、追加のステップを挿入してもよい。
　最初に、端末２０の決済アプリケーション処理部２１３は、入出力部２３に対するユーザの端末決済用操作を受け付ける（Ａ１）。そして、決済アプリケーション処理部２１３は、受け付けた端末決済用操作に基づいて、決済種別を判定する（Ａ３）。
　決済種別が「端末コード表示」であったならば（Ａ３：端末コード表示）、端末表示用コード取得処理部２１３１が、通信Ｉ／Ｆ２２によって、ユーザＩＤを含む端末表示用コード生成依頼情報をサーバ１０に送信する（Ａ５）。
　サーバ１０は、通信Ｉ／Ｆ１４によって端末２０から端末表示用コード生成依頼情報を受信したか否かを判定し（Ｃ１）、受信したと判定したならば（Ｃ１；Ｙｅｓ）、端末表示用コード生成処理部１１３１が、端末表示用コード生成処理を行う（Ｃ３）。
　具体的には、限定でなく例として、ランダムなトークンを発生させる手法（アルゴリズム）を用いて、ランダムなトークンを発行する。そして、アクセス情報と、発行したトークンとを含む端末表示用コードを生成する。より具体的には、例えば、サーバ１０が提供するウェブサイトのＵＲＬの文字列と、トークンの文字列（例えば“？”記号で始まるパラメータ部分）とで構成されるデータをエンコード（符号化）し、図形化して、二次元コードの画像で表される端末表示用コードを生成する。また、受信した端末表示用コード生成依頼情報に含まれるユーザＩＤと、発行したトークンとを関連付けて、端末表示用コード管理データベース１５９１に記憶させる。
　次いで、端末表示用コード送信処理部１１３３が、生成された端末表示用コードを、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｃ５）。
　決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から端末表示用コードを受信すると（Ａ７）、記憶部２８に記憶されている認証スキップ判定処理プログラム２８４５に従って、第１の認証スキップ判定処理を実行する（Ａ９）。
　図３－３３は、第１の認証スキップ判定処理の流れの一例を示すフローチャートである。なお、他の実施形態における認証スキップ判定処理と区別するため、便宜的に「第１の認証スキップ判定処理」と称する。
　最初に、認証スキップ判定処理部２１３５は、決済種別を判定する（Ｄ１）。そして、決済種別が「端末コード表示」であると判定したならば（Ｄ１；端末コード表示）、認証スキップ判定処理部２１３５は、決済用データ２８５３に記憶されている認証スキップ条件設定を判定する（Ｄ３）。
　認証スキップ条件設定が「ユーザ設定」であると判定したならば（Ｄ３；ユーザ設定）、認証スキップ判定処理部２１３５は、決済用データ２８５３に記憶されている認証スキップ条件ユーザ設定データにおける認証スキップ条件ユーザ設定と、認証スキップ条件データ２８５１の「決済種別：端末コード表示」に定められている適用有無とに基づいて、適用する認証スキップ条件を決定する（Ｄ５）。
　具体的には、限定でなく例として、認証スキップ条件データ２８５１の「決済種別：端末コード表示」の適用有無に「〇」が関連付けて記憶されている認証スキップ条件のうち、認証スキップ条件ユーザ設定データにおいて、設定種別に「条件カテゴリ別」が記憶されており、かつ、条件カテゴリ別設定フラグに「ＯＮ」が記憶されている条件カテゴリに含まれる認証スキップ条件と、設定種別に「条件別」が記憶されており、かつ、条件別設定フラグに「ＯＮ」が記憶されている認証スキップ条件とを、適用する認証スキップ条件として決定する。
　また、認証スキップ条件設定が「自動設定」であると判定したならば（Ｄ３；自動設定）、認証スキップ判定処理部２１３５は、認証スキップ条件データ２８５１の「決済種別：端末コード表示」に定められている適用有無および重要度（優先度）に基づいて、適用する認証スキップ条件を決定する（Ｄ７）。
　具体的には、限定でなく例として、認証スキップ条件データ２８５１の「決済種別：端末コード表示」の適用有無に「〇」が関連付けて記憶されている認証スキップ条件のうち、例えば重要度に「Ａ」または「Ｂ」が関連付けられている認証スキップ条件を、適用する認証スキップ条件として決定する。
　一方、決済種別が「端末コード読み取り」であると判定したならば（Ｄ１；端末コード読み取り）、認証スキップ判定処理部２１３５は、記憶部２８の決済用データ２８５３に記憶されている認証スキップ条件設定を判定する（Ｄ９）。
　認証スキップ条件設定が「ユーザ設定」であると判定したならば（Ｄ９；ユーザ設定）、認証スキップ判定処理部２１３５は、決済用データ２８５３に記憶されている認証スキップ条件ユーザ設定データの認証スキップ条件ユーザ設定と、認証スキップ条件データ２８５１の決済種別：端末コード読み取りについて定められている適用有無とに基づいて、適用する認証スキップ条件を決定する（Ｄ１１）。
　具体的には、限定でなく例として、認証スキップ条件データ２８５１の「決済種別：端末コード読み取り」の適用有無に「〇」が関連付けて記憶されている認証スキップ条件のうち、認証スキップ条件ユーザ設定データにおいて、設定種別に「条件カテゴリ別」が記憶されており、かつ、条件カテゴリ別設定フラグに「ＯＮ」が記憶されている条件カテゴリに含まれる認証スキップ条件と、設定種別に「条件別」が記憶されており、かつ、条件別設定フラグに「ＯＮ」が記憶されている認証スキップ条件とを、適用する認証スキップ条件として決定する。
　また、認証スキップ条件設定が「自動設定」であると判定したならば（Ｄ９；自動設定）、認証スキップ判定処理部２１３５は、認証スキップ条件データ２８５１の「決済種別：端末コード読み取り」に定められている適用有無および重要度（優先度）に基づいて、適用する認証スキップ条件を決定する（Ｄ１３）。
　具体的には、限定でなく例として、認証スキップ条件データ２８５１の決済種別：端末コード読み取りの適用有無に「〇」が関連付けて記憶されている認証スキップ条件のうち、例えば重要度に「Ａ」または「Ｂ」が関連付けられている認証スキップ条件を、適用する認証スキップ条件として決定する。
　Ｄ５、Ｄ７、Ｄ１１またはＤ１３の後、認証スキップ判定処理部２１３５は、決定したそれぞれの認証スキップ条件の判定に必要な情報を取得する（Ｄ１５）。それぞれの認証スキップ条件の判定に必要な情報およびその判定方法は、前述した通りである。
　その後、認証スキップ判定処理部２１３５は、認証スキップ条件成否判定を行う（Ｄ１７）。具体的には、Ｄ１５で取得した情報に基づいて、Ｄ５、Ｄ７、Ｄ１１またはＤ１３で決定した各認証スキップ条件それぞれについて成否を判定する。そして、例えば、少なくとも１つの認証スキップ条件が成立する場合は認証処理をスキップすると判定し、それ以外の場合は認証処理をスキップしないと判定する。そして、認証スキップ判定処理部２１３５は、第１の認証スキップ判定処理を終了する。
　なお、上記の認証スキップ条件の決定方法や、認証スキップ条件の成否の判定方法は、あくまでも一例に過ぎず、これらに限定されない。
　具体的には、限定でなく例として、重要度に「Ａ」が関連付けられている認証スキップ条件のみを、適用する認証スキップ条件として決定するようにしてもよいし、しなくてもよい。また、重要度「Ｃ」の認証スキップ条件についても、適用する認証スキップ条件に含めるようにしてもよいし、しなくてもよい。
　また、限定でなく例として、重要度に「Ａ」が関連付けられている認証スキップ条件については、少なくとも１つの認証スキップ条件が成立する場合に認証処理をスキップすると判定するが、重要度に「Ｂ」が関連付けられている認証スキップ条件については、全ての認証スキップ条件が成立する場合に認証処理をスキップすると判定するようにしてもよいし、しなくてもよい。
　メインの処理に戻り、決済アプリケーション処理部２１３は、第１の認証スキップ判定処理で認証処理をスキップする判定がなされたか否かを判定する（Ａ１１）。認証処理をスキップすると判定された場合（Ａ１１；Ｙｅｓ）、決済アプリケーション処理部２１３は、Ａ１９へと処理を移す。
　一方、認証処理をスキップしないと判定された場合（Ａ１１：Ｎｏ）、認証処理部２１３７が、認証処理を行う（Ａ１３）。具体的には、認証画面を表示部２４に表示させ、ユーザに認証パスワードを入力させる。そして、入力された認証パスワードが記憶部２８の決済用データ２８５３に記憶されている認証パスワードと一致する場合は、認証結果を「ＯＫ」とする。一方、認証パスワードが一致しない場合は、認証結果を「ＮＧ」とする。
　認証処理で認証結果が「ＮＧ」であると判定されたならば（Ａ１５；Ｎｏ）、決済アプリケーション処理部２１３は、エラー処理を実行する（Ａ１７）。具体的には、例えば、認証パスワードの再度の入力をユーザに促す報知を行う。そして、決済アプリケーション処理部２１３は、Ａ１３に処理を戻す。
　その後、決済アプリケーション処理部２１３は、端末表示用コードを表示部２４に表示させる（Ａ１９）。この際、決済アプリケーション処理部２１３は、端末表示用コードを店舗コードリーダ装置５０で読み取ってもらうことを端末２０のユーザに指示するメッセージ（コード読み取り指示表示）等を、端末表示用コードと併せて表示部２４に表示してもよいし、しなくてもよい。
　店舗コードリーダ装置５０の店舗決済処理部５１３は、入出力部５２に対する店舗の店員による店舗決済用操作を受け付ける（Ｂ１）。そして、店舗決済処理部５１３は、受け付けた店舗決済用操作に基づいて、決済種別が「端末コード表示」であるか否かを判定する（Ｂ３）。
　決済種別が「端末コード表示」であったならば（Ｂ３；Ｙｅｓ）、店舗決済処理部５１３は、決済予定金額設定処理を行う（Ｂ５）。具体的には、入出力部５２への店舗の店員による金額入力操作に基づいて、販売する商品の金額を「決済予定金額」として設定する。
　その後、店舗決済処理部５１３は、端末表示用コード読み取り指示報知を行う（Ｂ７）。具体的には、例えば、端末表示用コードを読み取るように指示するメッセージを表示部５３に表示させたり、端末表示用コードを読み取るように指示する音声を音出力部５６から音出力させるなどして、店舗の店員に報知する。この端末表示用コード読み取り指示報知に応じて、店舗の店員は、端末２０のユーザに端末表示用コードを提示するように促す。
　Ａ１９において端末２０の表示部２４に表示された端末表示用コードが店舗コードリーダ装置５０のコードリーダ５８によって読み取られると（Ｂ９）、店舗決済処理部５１３は、コード情報取得処理を行う（Ｂ１１）。具体的には、読み取った端末表示用コードからデータをデコード（復号）して、読み取った端末表示用コードに含まれる各種の情報を取得する。
　その後、店舗決済処理部５１３は、読み取った端末表示用コードから取得した決済用ページＵＲＬに基づいて、通信Ｉ／Ｆ５４によって決済用ページにアクセスし、限定でなく例として、店舗ＩＤと、端末表示用コードから取得したトークンと、Ｂ５で設定した決済予定金額とを含む第２の決済依頼情報をサーバ１０に送信する（Ｂ１３）。
　決済管理処理部１１３は、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から第２の決済依頼情報を受信すると（Ｃ９）、決済処理を行う（Ｃ１１）。具体的には、限定でなく例として、記憶部１５の端末表示用コード管理データベース１５９１において、店舗コードリーダ装置５０から受信した第２の決済依頼情報に含まれるトークンと関連付けて記憶されているユーザＩＤを特定する。そして、記憶部１５の決済管理データベース１５７における、特定したユーザＩＤの決済管理データに記憶されている残高に基づいて、決済予定金額の決済が可能であるか否かを判定する。そして、決済が可能であれば、残高から決済予定金額を減算して更新するとともに、決済履歴データを更新して、決済結果を「成功」とする。一方、決済が不可であれば、決済結果を「失敗」とする。
　なお、決済された金額は、ＩＭＳの事業者（決済サービスの事業者）から直接的に、または代理店を通じて、店舗に支払われる。
　次いで、決済管理処理部１１３は、決済結果を判定する（Ｃ１３）。決済結果が「成功」であったならば（Ｃ１３；成功）、店舗用決済結果情報送信処理部１１３６は、通信Ｉ／Ｆ１４によって店舗用決済成功情報を店舗用決済結果情報として、店舗コードリーダ装置５０に送信する（Ｃ１５）。同様に、端末用決済結果情報送信処理部１１３７は、通信Ｉ／Ｆ１４によって端末用決済成功情報を端末用決済結果情報として、端末２０に送信する（Ｃ１７）。そして、決済管理処理部１１３は、第１の決済管理処理を終了する。
　一方、決済結果が「失敗」であったならば（Ｃ１３；失敗）、店舗用決済結果情報送信処理部１１３６は、通信Ｉ／Ｆ１４によって店舗用決済失敗情報を店舗用決済結果情報として、店舗コードリーダ装置５０に送信する（Ｃ１９）。同様に、端末用決済結果情報送信処理部１１３７は、通信Ｉ／Ｆ１４によって端末用決済失敗情報を端末用決済結果情報として、端末２０に送信する（Ｃ２１）。そして、決済管理処理部１１３は、第１の決済管理処理を終了する。
　店舗決済処理部５１３は、通信Ｉ／Ｆ５４によってサーバ１０から店舗用決済結果情報を受信すると（Ｂ１５）、その決済結果を判定し（Ｂ１７）、決済結果が「成功」であったならば（Ｂ１７；成功）、決済成功報知処理を行う（Ｂ１９）。そして、店舗決済処理部５１３は、第１の店舗決済処理を終了する。
　一方、決済結果が「失敗」であったならば（Ｂ１７；失敗）、店舗決済処理部５１３は、決済失敗報知処理を行う（Ｂ２１）。そして、店舗決済処理部５１３は、第１の店舗決済処理を終了する。
　決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から端末用決済結果情報を受信すると（Ａ２１）、その決済結果を判定し（Ａ２３）、決済結果が「成功」であったならば（Ａ２３；成功）、決済成功報知処理を行う（Ａ２５）。
　その後、決済アプリケーション処理部２１３は、決済履歴を表示するか否かを判定する（Ａ２７）。具体的には、限定でなく例として、入出力部２３に対するユーザの決済履歴確認操作を検出した場合に、決済履歴を表示すると判定する。
　決済履歴を表示すると判定したならば（Ａ２７；Ｙｅｓ）、決済アプリケーション処理部２１３は、決済履歴表示処理を行う（Ａ２９）。そして、決済アプリケーション処理部２１３は、第１の決済アプリケーション処理を終了する。
　一方、決済結果が「失敗」であったならば（Ａ２３；失敗）、決済アプリケーション処理部２１３は、決済失敗報知処理を行う（Ａ２６）。そして、決済アプリケーション処理部２１３は、第１の決済アプリケーション処理を終了する。
　次に、Ａ３において決済種別が「端末コード読み取り」であると判定したならば（Ａ３；端末コード読み取り）、コード読み取り処理部２１３３は、ユーザ操作に従ってアプリケーションコードリーダを起動して、端末読み取り用コード（第１種端末読み取り用コードまたは第２種端末読み取り用コード）を読み取る処理を行う（Ａ３１）。
　その後、決済アプリケーション処理部２１３は、コード情報取得処理を行う（Ａ３３）。具体的には、アプリケーションコードリーダで読み取った端末読み取り用コードからデータをデコード（復号）して、読み取った端末読み取り用コードに含まれる各種の情報を取得する。
　その後、決済アプリケーション処理部２１３は、読み取った端末読み取り用コードから取得した決済用ページＵＲＬに基づいて、通信Ｉ／Ｆ２２によって決済用ページにアクセスする（Ａ３５）。
　決済管理処理部１１３は、端末２０からの決済用ページへのアクセスに応じて、決済予定情報を判定する（Ｃ３３）。具体的には、端末読み取り用コード管理データベース１５９３を参照して、この決済用ページに関連付けて記憶された情報を取得する。そして、決済管理処理部１１３は、その判定結果に応じた決済予定情報を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｃ３５）。
　この場合、決済用ページに関連付けられた情報が、第１種端末読み取り用コードを運用する店舗に関する情報であった場合は、決済管理処理部１１３は、決済予定店舗と、決済予定金額とを含む第１種決済予定情報を、通信Ｉ／１４によって端末２０に送信する。一方、決済用ページに関連付けられた情報が、第２種端末読み取り用コードを運用する店舗に関する情報であった場合は、決済管理処理部１１３は、決済予定店舗を含む第２種決済予定情報（決済予定金額は含まない。）を、通信Ｉ／１４によって端末２０に送信する。
　決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から決済予定情報を受信すると（Ａ３７）、受信した決済予定情報の種別を判定する（Ａ３９）。そして、決済予定情報の種別が「第２種決済予定情報」であったならば（Ａ３９；第２種）、決済予定金額設定処理を行う（Ａ４１）。具体的には、入出力部２３に対する自己の端末２０のユーザによる金額入力操作に基づいて、購入する予定の商品の総額を「決済予定金額」として設定する。
　Ａ４１の後、または、決済予定情報の種別が「第２種決済予定情報」であったならば（Ａ３９；第１種）、決済アプリケーション処理部２１３は、記憶部２８に記憶されている認証スキップ判定処理プログラム２８４５に従って、第１の認証スキップ判定処理を実行する（Ａ９）。そして、決済アプリケーション処理部２１３は、Ａ１１～Ａ１７の処理を実行する。
　その後、決済アプリケーション処理部２１３は、決済用ページにおいて、限定でなく例として、ユーザＩＤと、決済確認情報とを含む第１の決済依頼情報をサーバ１０に送信する（Ａ４３）。ただし、Ａ４１の処理を実行した場合は、設定した決済予定金額も第１の決済依頼情報に含めてサーバ１０に送信する。そして、決済アプリケーション処理部２１３は、Ａ２１以降の処理を行う。
　決済管理処理部１１３は、通信Ｉ／Ｆ１４によって端末２０から第１の決済依頼情報を受信すると（Ｃ３７）、決済処理を行う（Ｃ１１）。そして、決済管理処理部１１３は、Ｃ１３以降へと処理を移す。
　Ｂ５において決済種別が「端末コード表示」ではないと判定したならば（Ｂ３；Ｎｏ）、店舗決済処理部５１３は、Ｂ１５へと処理を移す。
　決済種別が「端末コード表示」ではない場合とは、決済種別が「端末コード読み取り」の場合である。この場合は、限定でなく例として、店舗の店員が、端末読み取り用コードを端末２０のユーザに読み取るように指示し、端末２０のユーザが、端末２０のアプリケーションコードリーダを起動して、端末読み取り用コードを読み取るようにすればよい。
　なお、前述したように、第１種端末読み取り用コードと第２種端末読み取り用コードとのうちの１種類のコードのみを端末読み取り用コードとして用いるようにすることもできる。
　この場合、図３－３１のＣ３５のステップでサーバ１０から端末２０に送信される決済予定情報は１種類となり、端末２０における決済予定情報の種別の判定は不要となるため、図３－３１のＡ３９のステップは削除することができる。
　また、第１種端末読み取り用コードのみを適用するのであれば、端末２０における決済予定金額の設定は不要となるため、図３－３１のＡ４１のステップも削除することができる。
＜第１実施形態の効果＞
　第１実施形態は、端末２０のユーザに対する電子決済（限定でなく、決済の一例）のための認証処理（限定でなく、表示処理の一例）を行い、認証処理の結果に基づいて、ＩＭＳマネー（限定でなく、電子貨幣の一例）による決済に関する情報を通信Ｉ／Ｆ２２（限定でなく、端末の通信部の一例）によって受信する端末２０が、認証パスワード（限定でなく、端末のユーザを認証するための認証情報の一例）とは異なる情報を取得する。そして、端末２０が、取得した情報に基づいて認証スキップ判定を行い、認証スキップ条件が成立する場合は、認証処理をせず、サーバ１０による決済結果の情報（限定でなく、電子貨幣による決済に関する情報の一例）を通信Ｉ／Ｆ２２によって受信する構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、端末のユーザに対する認証の実行に関する表示処理をすることなく、電子貨幣による決済に関する情報を簡単に受信することができる。また、端末は、電子貨幣による決済に際して、端末のユーザを認証するための認証情報とは異なる情報を取得することで、表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、電子貨幣による決済に際して、表示処理を１回１回行わずに済むため、手早く円滑に決済を行うことができ、ユーザの利便性を向上させることができる。
　また、第１実施形態は、上記の認証パスワードとは異なる情報（限定でなく、認証情報とは異なる情報の一例）は、ＩＭＳマネーに関する情報（限定でなく、電子貨幣に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第１実施形態は、上記のＩＭＳマネーに関する情報は、端末２０または、端末２０のユーザに関連付けられているＩＭＳマネーの金額に関する情報（限定でなく、端末または、端末のユーザに関連付けられている電子貨幣の金額に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣の金額に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、電子貨幣の金額に関する情報は、端末または、端末のユーザに関連付けられているため、端末は、適正な電子貨幣の金額に関する情報に基づいて、決済に関する処理を適切に行うことができる。
　また、第１実施形態は、上記のＩＭＳマネーの金額に関する情報は、１日上限設定金額に関する情報（限定でなく、設定された電子貨幣の設定金額に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、設定された電子貨幣の設定金額に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第１実施形態は、端末２０が、１日上限設定金額（限定でなく、設定金額の一例）を超えるまで認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、設定された電子貨幣の設定金額を超えるまで、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができるとともに、ユーザの利便性を向上させることができる。一方、電子貨幣による決済に際して、設定金額を超えた場合は、認証の実行に関する表示を行う場合があるため、設定金額を超えたことをユーザに注意喚起することができる。
　また、第１実施形態は、上記のＩＭＳマネーの金額に関する情報は、端末２０または、端末２０のユーザに関連付けられたＩＭＳマネーの残高に関する情報（限定でなく、端末または、端末のユーザに関連付けられた電子貨幣の残高に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣の残高に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、電子貨幣の残高に関する情報は、端末または、端末のユーザに関連付けられているため、端末は、適正な電子貨幣の残高に関する情報に基づいて、決済に関する処理を適切に行うことができる。
　また、第１実施形態は、端末２０が、ＩＭＳマネーの残高が設定金額以下または、設定金額未満の場合、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣の残高が設定された金額以下または、設定された金額未満であれば、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。また、例えば、電子貨幣の残高が少ない場合は、高額の決済ができず、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第１実施形態は、端末２０が、端末２０でオートチャージ設定（限定でなく、自動で電子貨幣の入金が端末に行われる設定）がなされている場合、ＩＭＳマネーの残高が設定金額以下または、設定金額未満の場合に、認証処理を行う構成を示している。
　このような構成により得られる効果の一例として、端末の電子貨幣が設定された金額以下または、設定された金額未満になった場合に自動で電子貨幣の入金が端末に行われる設定になっている場合、金額が少なくなれば自動で電子貨幣の入金が端末に行われるため、高額の決済が可能となり、リスクが生ずる。このため、認証の実行に関する表示を行うことで、高額の決済が可能になることをユーザに注意喚起することができる。
　また、第１実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーによって決済を行った頻度または回数に関する情報（限定でなく、電子貨幣によって決済を行った頻度または回数に関する情報）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣によって決済を行った頻度または回数に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、電子貨幣によって決済が行われた頻度が高い場合や回数が多い場合は、同じユーザが電子貨幣によって決済を行っている可能性が高く、危険性は低いと考えられるため、表示処理をしないようにすることで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第１実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーによる最終決済日時に関する情報（限定でなく、電子貨幣によって決済を行った時間に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣によって決済を行った時間に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第１実施形態は、端末２０が、ＩＭＳマネーによる最終決済日時から設定時間内である場合、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣による決済を行った時間から設定された時間内の場合、認証の実行に関する表示を行わずに済むため、端末の処理負荷を軽減することができる。また、例えば、電子貨幣による決済を行ってからそれほど時間が経過していなければ、同じユーザが再び決済を行う可能性が高く、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第１実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーによって決済を行った場所に関する情報（限定でなく、電子貨幣によって決済を行った場所に関する情報）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣によって決済を行った場所に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第１実施形態は、上記のＩＭＳマネーによって決済を行った場所に関する情報は、ＩＭＳマネーによって決済を行った店舗に関する情報（限定でなく、電子貨幣によって決済を行った店舗に関する情報）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣によって決済を行った店舗に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第１実施形態は、端末２０が、ＩＭＳマネーによって決済を行った店舗の位置情報（限定でなく、電子貨幣によって決済を行った場所に関する情報の一例）と、位置算出処理部２１７によって算出された端末２０の位置情報（限定でなく、端末の位置に関する情報の一例）とに基づいて、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣によって決済を行った店舗に関する情報と、端末の位置に関する情報とに基づいて、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。また、例えば、過去に電子貨幣によって決済を行った店舗から端末の位置が離れていなければ、ユーザが同じ店舗で決済を行おうとしている可能性が高く、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第１実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーの決済をするための認証の実行を行った場所に関する情報（限定でなく、電子貨幣の決済をするための認証の実行を行った場所に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣の決済をするための認証の実行を行った場所に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、過去に電子貨幣の決済をするための認証の実行を行った場所であれば、同じユーザについて再び認証の実行を行う場合である可能性が高く、危険性は低いと考えられるため、表示処理をしないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第１実施形態は、上記の認証パスワードとは異なる情報は、場所に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、場所に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第１実施形態は、上記の場所に関する情報は、商品を購入する店舗の場所に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、商品を購入する場所に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、商品を購入する場所に関する情報は、例えば、その場所が日用品などの値段の安い商品を販売している店舗であるかを判別する情報として利用することができ、端末のユーザに対する認証を実行するべきかどうかの目安にすることができる。
　また、第１実施形態は、上記の商品を購入する場所に関する情報は、商品を販売する店舗に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、商品を販売する店舗に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、商品を販売する店舗に関する情報は、例えば、その店舗が日用品などの値段の安い商品を販売しているかどうかを判別する情報として利用することができ、端末のユーザに対する認証を実行するべきかどうかの目安にすることができる。
　また、第１実施形態は、端末２０が、決済予定店舗が設定店舗や第１特定業種の店舗（限定でなく、第１の場所の一例）である場合、認証処理を行わないが、これらの店舗とは異なる第２特定業種の店舗（限定でなく、第２の場所の一例）での決済日時から設定時間が経過するまでは、認証処理を行う構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、第１の場所に関する情報を取得した場合、認証の実行に関する表示を行わないが、第１の場所とは異なる第２の場所に関する情報を取得した場合、電子貨幣によって第２の場所で決済を行ってから設定された時間が経過されるまで認証の実行に関する表示を行うため、例えば、ユーザが第２の場所に端末を置き忘れた場合や、ユーザが第２の場所で端末を紛失したような場合等に、その端末を取得した第三者によって不正に決済が行われることを防止できる。
　また、第１実施形態は、上記の認証パスワードとは異なる情報は、商品に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、商品に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、商品に関する情報によって、高額な商品を購入したか、低額な商品を購入したかを判別することができるため、端末のユーザに対する認証を実行するべきかどうかの目安にすることができる。
　また、第１実施形態は、上記の認証パスワードとは異なる情報は、端末２０または端末２０に記憶された決済アプリケーションの設定に関する情報（限定でなく、端末または、端末に記憶されたアプリケーションの設定に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、端末または、端末に記憶されたアプリケーションの設定に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、端末または、端末に記憶されたアプリケーションの設定に関する情報がユーザによって設定された情報である場合、ユーザの意思を尊重することができ、ユーザの利便性を向上させることができる。
　また、第１実施形態は、上記の認証パスワードとは異なる情報は、端末２０に設定された、端末２０がロック中であるか否かを示す情報（限定でなく、端末に設定された、端末のセキュリティに関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、端末に設定された、端末のセキュリティに関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、端末のセキュリティに関する情報が端末のユーザの認証に関連する情報である場合、端末のユーザに対する認証の実行に関する表示処理を省略することで、ユーザの利便性を向上させることができる。
　また、第１実施形態は、上記の認証パスワードとは異なる情報は、端末２０に設定された端末側の認証設定の情報または端末２０に記憶された決済アプリケーションに設定された決済用の認証設定の情報（限定でなく、端末または、端末に記憶されたアプリケーションに設定された、認証の実行をスキップすることに関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、端末または、端末に記憶されたアプリケーションに設定された、認証の実行をスキップすることに関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第１実施形態は、上記の認証パスワードとは異なる情報は、ＩＭＳマネーによる決済を関するサーバ１０（限定でなく、電子貨幣による決済を管理するサーバの一例）から送付された情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、電子貨幣による決済を関するサーバから送付される情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第１実施形態は、端末２０が、上記の認証パスワードとは異なる情報に基づいて、決済処理を実行しない場合があり、ＩＭＳマネーによる決済を行うための端末表示用コード（限定でなく、電子貨幣による決済を行うためのコード情報の一例）を表示部２４に表示し、店舗コードリーダ装置５０のコードリーダ５８（限定でなく、コードリーダの一例）による端末表示用コードの読み取りに基づいて、ＩＭＳマネーによる決済結果の情報を通信Ｉ／Ｆ２２によって受信する構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、端末の表示領域に表示した電子貨幣による決済を行うためのコード情報をコードリーダで読み取らせるだけで、電子貨幣による決済に関する情報を簡単に受信することができる。
　また、第１実施形態は、端末２０が、端末表示用コードを店舗コードリーダ装置５０のコードリーダ５８で読み取ってもらうことを端末２０のユーザに指示するメッセージ等（限定でなく、コード情報の読み取りに関する表示の一例）を表示部２４に表示し、店舗コードリーダ装置５０のコードリーダ５８による端末読み取り用コードの読み取りに基づき、認証パスワードとは異なる情報を取得する構成を示している。
　このような構成により得られる効果の一例として、端末は、コード情報の読み取りに関する情報を端末のユーザに報知することができる。また、端末は、電子貨幣による決済に際して、端末の表示領域に表示したコード情報をコードリーダで読み取らせるだけで、認証情報とは異なる情報を端末によって簡単に取得することができる。
　また、第１実施形態は、上記の認証パスワードとは異なる情報は、決済予定金額（限定でなく、購入する商品の金額、総額に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、端末の表示領域に表示したコード情報をコードリーダで読み取らせるだけで、購入する商品の金額や総額に関する情報を端末で簡単に取得することができる。
　また、第１実施形態は、端末２０が、決済予定金額が設定金額以下または設定金額未満の場合、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、購入する商品の総額が、端末によって設定された設定金額以下または設定された設定金額未満の場合、認証の実行に関する表示を行わないため、ユーザの利便性を向上させることができる。また、購入する商品の総額が低額であれば、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第１実施形態は、端末２０が、購入予定商品の購入履歴がある場合（限定でなく、商品が端末のユーザが１度以上購入した商品と一致した場合の一例）、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、商品が端末のユーザが一度以上購入した商品と一致した場合、認証の実行に関する表示を行わないため、ユーザの利便性を向上させることができる。また、同じ商品を購入するのであれば、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第１実施形態は、端末２０が、端末表示用コード（限定でなく、コード情報の一例）の読み取りに基づき、ＩＭＳマネーによる決済を管理するサーバ１０から送信された、認証パスワードとは異なる情報を通信Ｉ／Ｆ２２によって受信し、取得する構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣による決済に際して、コード情報を読み取るだけで、電子貨幣による決済を管理するサーバから送信された、認証情報とは異なる情報を簡単に取得することができる。
　また、第１実施形態は、上記のＩＭＳマネーによる決済に関する情報は、サーバ１０（限定でなく、外部のサーバの一例）から送信された、ＩＭＳマネーにより決済が行われたことを示す情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣により決済が行われたことを示す情報を、外部のサーバから取得することができるという効果が得られる。
　また、第１実施形態は、端末２０のユーザの決済に関する認証を行う端末２０が、認証スキップ判定を行うために必要な情報を取得し、取得した情報が認証スキップ条件を満たさない場合、端末２０のユーザに対する認証処理をし、認証処理の結果に基づいてＩＭＳマネーに関する情報を通信Ｉ／Ｆ２２によって受信する。一方、取得した情報が認証スキップ条件を満たす場合、端末２０のユーザに対する認証処理をせず、ＩＭＳマネーに関する情報を通信Ｉ／Ｆ２２によって受信する構成を示している。
　このような構成により得られる効果の一例として、端末によって取得した情報が条件を満たす場合は、条件を満たさない場合とは異なり、端末のユーザに対する認証に関する処理を実行しないため、端末の処理負荷を軽減することができる。また、端末のユーザは、認証に必要な操作等を行わずに済むため、ユーザの利便性を向上させることができる。
＜第１変形例（１）＞
　第１実施形態では、端末２０のユーザに対する認証の種類をパスワード認証とし、この認証の実行に関する表示処理を認証パスワード入力用の認証画面を表示する処理としたが、これに限定されない。この他にも、例えば、端末２０のユーザに対する認証の種類を顔認証、指紋認証、音声認証等の生体認証とし、これらの生体認証を行うために必要な認証画面を表示する処理を、端末のユーザに対する認証の実行に関する表示処理としてもよいし、しなくてもよい。
　また、限定でなく例として、決済サービスを利用するためのユーザＩＤ等のアカウントを取得するための認証処理における認証画面を表示する処理を、端末のユーザに対する認証の実行に関する表示処理とするようにしてもよいし、しなくてもよい。そして、この認証処理の結果が「ＯＫ」となった場合に、端末２０が、決済サービスを利用するためのアカウントの情報を、電子貨幣による決済に関する情報として、サーバ１０から受信するようにしてもよいし、しなくてもよい。
＜第１変形例（１）の効果＞
　本変形例による効果の一例として、端末は、認証パスワードを用いた認証とは異なる認証についても同様に、端末のユーザに対する認証の実行に関する表示処理をすることなく、電子貨幣による決済に関する情報を簡単に受信することができる。
　また、端末は、端末のユーザに対する認証の実行に関する表示処理をすることなく、決済サービスを利用するために必要な情報を、電子貨幣による決済に関する情報として簡単に取得することができる。
＜第１変形例（２）＞
　第１実施形態では、電子貨幣をＩＭＳマネーとして説明したが、これに限定されない。電子貨幣は、ＩＭＳマネーに限らず、限定でなく例として、いわゆる仮想通貨やゲーム内通貨、ギフトとして他の端末２０のユーザ等から送付（贈呈）されるギフトコード、前述したＩＭＳポイントを含む各種のポイントサービスによってユーザに送付（贈呈）されるポイントなど、現金の代替としてユーザが利用可能な支払手段全般を含む概念とすることができる。
＜第１変形例（２）の効果＞
　本変形例により得られる効果の一例として、端末は、ＩＭＳに関連付けられた電子貨幣とは異なる電子貨幣による決済に際して、端末のユーザに対する認証の実行に関する表示処理をすることなく、電子貨幣による決済に関する情報を簡単に受信することができる。
＜第１変形例（３）＞
　第１実施形態では、端末表示用コードと端末読み取り用コードとを、それぞれ二次元コードとして説明したが、これに限定されない。端末表示用コードと端末読み取り用コードとの少なくともいずれかを、限定でなく例として、前述した一次元コード（限定ではなく、例としてバーコード）としてもよいし、しなくてもよい。
　また、端末表示用コードと端末読み取り用コードとの少なくともいずれかを、コードに格納される情報の文字列で表される文字コードとし、端末表示用コードは店舗のカメラで読み取るなどして文字認識し、端末読み取り用コードは端末２０のカメラ２７で読み取るなどして文字認識して、それぞれのコードに含まれる情報を取得するようにしてもよいし、しなくてもよい。
＜第１変形例（３）の効果＞
　本変形例による効果の一例として、二次元コードとは異なる端末表示用コードや端末読み取り用コードに基づいて、端末の決済を実現することができる。また、端末や店舗コードリーダ装置が二次元コードに対応していない場合であっても、電子貨幣による決済を実現することができる。
＜第１変形例（４）＞
　第１実施形態では、サーバ１０から送信される決済に関する情報が端末２０の記憶部２８に決済履歴データとして記憶され、端末２０が、この決済履歴データに含まれる決済に関する情報に基づいて認証スキップ判定を行うこととしたが、これに限定されない。
　具体的には、端末２０の記憶部２８に決済履歴データを記憶させないようにすることもできる。この場合、端末２０は、認証スキップ判定に必要な情報をサーバ１０に要求し、サーバ１０から取得した情報に基づいて、認証スキップ判定を行うようにしてもよいし、しなくてもよい。
＜第１変形例（４）の効果＞
　本変形例により得られる効果の一例として、電子貨幣による決済の履歴に関する情報を端末に記憶させておく必要がないため、端末の記憶容量を節約することができる。
＜第１変形例（５）＞
　第１実施形態において、サーバ１０から端末２０に配信される店舗データ２８５５に店舗位置情報を含めることとし、端末２０が、店舗データ２８５５に含まれる店舗位置情報と、位置算出処理部２１７によって算出される端末２０の位置情報（以下、「端末位置情報」と称す。）とに基づいて、認証スキップ判定を行うようにしてもよいし、しなくてもよい。
　具体的には、例えば、条件カテゴリＮｏ「ＳＰ２」に含まれる条件Ｎｏ「ＳＰ２－２」の「決済予定店舗が設定店舗」の認証スキップ条件を判定する際に、端末２０の最新の算出位置が、店舗データ２８５５に記憶されている設定店舗の位置と一致するか否かを判定するようにすることができる。
　店舗・場所に関する他の認証スキップ条件についても同様である。
＜第１変形例（５）の効果＞
　本変形例により得られる効果の一例として、端末は、自己の端末２０で算出した端末位置情報と、外部から取得した店舗位置情報とに基づいて、認証スキップ条件の成否を簡単に判定することができる。
＜第１変形例（６）＞
　第１実施形態では、１日上限設定金額を、その１日における決済済みの金額（決済金額）の合計金額に対する閾値とする上限の設定金額としたが、これに限定されない。
　具体的には、限定でなく例として、１日上限設定金額を、その１日における決済済みの金額（決済金額）の合計金額と、これから決済しようとする金額（決済予定金額）との合算金額に対する閾値金額とする上限の設定金額としてもよいし、しなくてもよい。
　また、上限設定金額は、必ずしも１日の上限設定金額としなければならないわけではなく、過去所定期間（過去１週間、過去２週間、過去１か月等）の上限設定金額としてもよいし、しなくてもよい。
　また、上限設定金額を、これから決済しようとする金額（決済予定金額）、つまり１回で決済する金額に対する設定金額とし、「決済予定金額が設定金額以下（または設定金額未満）」とする認証スキップ条件に基づいて認証スキップ判定を行うようにすることもできる。このようにすることで、端末２０のユーザが低価格の商品を購入するような場合に、認証処理をスキップさせることができる。
＜第１変形例（６）の効果＞
　本変形例により得られる効果の一例として、過去に決済した金額（決済金額）ばかりでなく、これから決済しようとする金額（決済予定金額）をも考慮して、認証の実行に関する表示を行うかどうかを判定することができる。
　また、１回の決済金額が設定された金額を超えるまで、認証の実行に関する表示を行わないことで、ユーザの利便性を向上させることができる。
＜第１変形例（７）＞
　第１実施形態で説明した各種の認証スキップ条件はあくまでも一例に過ぎず、適宜、追加や削除、変更することが可能である。
　具体的には、限定でなく例として、条件Ｎｏ「ＳＰ１－１」の「現在日時が最終決済日時から設定時間内」とする認証スキップ条件を、「現在日時が最終認証日時から設定時間内」とすることもできる。これは、例えば、端末２０のユーザがある商品（例えば弁当）を購入する際に端末２０で認証を行った後、すぐに別の商品（例えばコーヒー）を購入するために端末２０での再度の認証が必要となるような場合が考えられるためである。
　また、上記の「最終認証日時」は、必ずしも決済用の認証が最後に行われた日時に限られるわけではなく、限定でなく例として、第４実施形態で後述するＩＭＳマネーの個人間送金を行う場合における送金用の認証が最後に行われた日時や、端末２０のＯＳ側のロックを解除するための認証が最後に行われた日時、決済アプリケーション側のロックを解除するための認証が最後に行われた日時といった、決済用の認証とは異なる種類の認証が最後に行われた日時を、上記の認証スキップ条件における「最終認証日時」とすることもできる。
　また、限定でなく例として、条件Ｎｏ「ＳＰ１－１」の認証スキップ条件における「最終決済日時」を、ユーザによってＩＭＳマネーのチャージが行われた最新の日時である「最終チャージ日時」や、決済アプリケーション内で決済に関連するユーザ操作が行われた最新の日時である「最終決済関連操作日時」とすることもできる。ＩＭＳマネーが最後にチャージされてからそれほど時間が経過していなければ、決済のためにユーザがＩＭＳマネーをチャージした可能性が高いため、認証処理をスキップさせるのは合理的である。また、決済アプリケーション内で決済に関連するユーザ操作が最後に行われてからそれほど時間が経過していなければ、ユーザが決済を行うことを予定して操作を行った可能性が高いため、認証処理をスキップさせるのは合理的である。
　また、条件Ｎｏ「ＳＰ１－２」の認証スキップ条件における「設定時間帯」は、特定の曜日や特定の日付を含む概念とすることができる。限定でなく例として、特定の曜日として、土曜日や日曜日を設定するなどしてもよい。土曜日や日曜日は、買い物や食事で外出するユーザが多く、決済が行われる機会が多くなる傾向があるためである。また、特定の日付として、クリスマス（クリスマスイブを含む。）や正月の三が日を設定するなどしてもよい。クリスマスは、プレゼントの購入やディナーで外出するユーザが多く、三が日は初売りで外出するユーザが多く、それぞれ決済が行われる機会が多くなる傾向があるためである。
　また、端末２０のユーザが、自身の端末２０を第三者に利用されて高額な商品を決済で購入され、それを換金されてしまうようなリスクも考えられる。そこで、限定でなく例として、「決済予定店舗が換金性の高い商品を販売する店舗ではない」とする認証スキップ条件を追加することもできる。換金性の高い商品とは、例えば、宝飾品や腕時計といった商品であり、このような商品を販売する店舗（宝飾品店や腕時計店等）で決済が行われる予定である場合は、端末２０で認証処理をスキップさせないようにすることができる。
　また、天気や天候に関連する認証スキップ条件を追加するようにすることもできる。例えば、雨の日や雪の日は、公共交通機関を利用するユーザが増えるため、端末２０の置き忘れが発生するリスクが高まる。このため、限定でなく例として、「当日の天気が雨または雪ではない」とする認証スキップ条件を追加し、雨の日や雪の日には認証処理をスキップさせないようにすることもできる。
＜第１変形例（７）の効果＞
　本変形例により得られる効果の一例として、端末は、電子貨幣による決済に際して、決済用の認証が最後に行われた日時から設定された時間内である場合ばかりでなく、決済用の認証とは異なる種類の認証が最後に行われた日時から設定された時間内である場合も、認証の実行に関する表示を行わないようにすることで、ユーザの利便性をより一層向上させることができる。
　また、電子貨幣による決済に際して、電子貨幣の入金が最後に行われた日時から設定された時間内である場合や、アプリケーション内での決済に関する操作が最後に行われた日時から設定された時間内である場合に、認証の実行に関する表示を行わないようにすることで、ユーザの利便性をより一層向上させることができる。
　また、特定の曜日や特定の日付である場合に、認証の実行に関する表示を行わないようにすることで、ユーザの利便性をより一層向上させることができる。
　また、ユーザのリスクを考慮した情報に基づいて、端末のユーザに対する認証の実行に関する表示処理を行わないようにすることで、ユーザの利便性とリスクとのバランスを考慮した適切な決済を実現することができる。
＜第１変形例（８）＞
　第１実施形態で説明した図３－２９の処理では、決済種別が「端末コード表示」である場合に、端末２０が、サーバ１０から端末表示用コードを受信した後（Ａ７の後）のタイミングで、第１の認証スキップ判定処理を行うこととしたが、これに限定されない。
　限定でなく例として、端末２０が、端末表示用コード生成依頼情報をサーバ１０に送信する前（図３－２９のＡ５の前）のタイミングで、第１の認証スキップ判定処理を行うようにしてもよいし、しなくてもよい。
　また、限定でなく例として、端末２０が、端末表示用コード生成依頼情報をサーバ１０に送信した後（図３－２９のＡ７）、サーバ１０から端末２０に端末表示用コードがすぐに送信されるようにするのではなく、サーバ１０から端末２０に端末表示用コードが送信される前に、認証スキップ判定処理を行うようにしてもよいし、しなくてもよい。
　具体的には、サーバ１０は、端末２０から送信された端末表示用コード生成依頼情報を受信した後（図３－２９のＣ１；Ｙｅｓ）、認証を要求するための認証要求情報を端末２０に送信する。そして、端末２０は、この認証要求情報をサーバ１０から受信した後のタイミングで、第１の認証スキップ判定処理を行う。
　認証処理をスキップする判定がなされた場合は、端末２０は、認証処理をスキップし、認証処理をスキップしたことを示す認証スキップ実行情報をサーバ１０に送信する。一方、認証処理をスキップしない判定がなされた場合は、端末２０は、認証処理を行い、認証結果が「ＯＫ」となったならば、認証が成功したことを示す認証成功情報をサーバ１０に送信する。そして、サーバ１０は、端末２０から認証スキップ実行情報と、認証成功情報とのいずれかを受信した後、端末表示用コード生成処理を行って端末表示用コードを生成し（図３－２９のＣ３）、生成した端末表示用コードを端末２０に送信する（図３－２９のＣ５）。
　なお、この場合、サーバ１０が、端末２０から送信された端末表示用コード生成依頼情報を受信した後（図３－２９のＣ１；Ｙｅｓ）、端末表示用コード生成処理を行って端末表示用コードを生成するようにし（図３－２９のＣ３）、その後に、認証要求情報を端末２０に送信するようにすることもできる。
　上記のように、端末２０側で認証スキップ判定処理を行うタイミングとしては、上記のように、大きく分けて３つのタイミングのうちのいずれかのタイミングとすることができる。
＜第１変形例（８）の効果＞
　本変形例により得られる効果の一例として、端末は、電子貨幣による決済に際して、端末のユーザを認証するための認証情報とは異なる情報に基づき、複数のタイミングのうちのいずれかのタイミングで、端末のユーザに対する認証の実行に関する表示処理を実行するか否かの判定を行うことができる。
＜第１変形例（９）＞
　上記の実施形態では、決済種別「端末コード表示」、「端末コード読み取り」のいずれについても、購入予定商品に関する情報がサーバ１０から端末２０に送信されず、端末２０は購入予定商品に関する情報を取得することはできないこととしたが、例えば以下の方法によって、端末２０が購入予定商品の情報を取得するようにすることもできる。
　具体的には、限定でなく例として、決済アプリケーションの機能として備えられたカメラ（以下、「アプリケーションカメラ」と称す。）、または、端末２０に備えられたカメラ２７等の撮像装置（または撮像部）によって撮影された撮影画像に基づいて、商品の種別を識別可能とするためのソフトウェアを、端末２０の記憶部２８に記憶させておく。
　決済種別「端末コード表示」では、例えば、図３－２９の第１の決済アプリケーション処理のＡ１の前に、端末２０は、ユーザ操作に従って、アプリケーションカメラまたはカメラ２７を起動して、購入予定の商品の画像を撮影する。つまり、端末２０のユーザは、店舗のコードレジ６０で、購入する商品の画像をアプリケーションカメラまたはカメラ２７で撮影する。そして、端末２０は、撮影した画像（以下、「撮影画像」と称す。）から商品の種別を識別する商品種別識別処理を行う。そして、端末２０は、「Ａ３；端末コード表示～Ａ７」の処理を行った後、第１の認証スキップ判定処理を行う（Ａ９）。
　決済種別「端末コード読み取り」についても同様に、例えば、図３－２９の第１の決済アプリケーション処理のＡ１の前に、端末２０は、ユーザ操作に従って、アプリケーションカメラまたはカメラ２７を起動して、購入予定の商品の画像を撮影する。そして、端末２０は、撮影画像から商品の種別を識別する商品種別識別処理を行う。そして、端末２０は、「Ａ３；端末コード読み取り～Ａ４１」の処理を行った後、第１の認証スキップ判定処理を行う（Ａ９）。
　図３－３４は、この場合における認証スキップ条件データ２８５１の一例を示す図である。このデータ構成は、図３－８の認証スキップ条件データ２８５１と同様であるが、黒色の太枠で囲った部分が異なっている。
　具体的には、条件Ｎｏ「ＳＰ４－１」の「購入予定商品が日用消費財」の認証スキップ条件について、決済種別「端末コード表示」、「端末コード読み取り」のいずれについても適用有無として「〇」が定められている。これは、上記の手法を用いることで、端末２０で商品の種別を識別することが可能となるため、識別した商品の種別に基づいて、購入予定商品が日用消費財であるか否かを判定することができるためである。また、決済種別「端末コード表示」については重要度「Ｂ」が、決済種別「端末コード読み取り」については重要度「Ａ」がそれぞれ定められている。
　また、条件Ｎｏ「ＳＰ４－２」の「購入予定商品の購入履歴あり」の認証スキップ条件について、決済種別「端末コード表示」について適用有無として「〇」が定められている。これは、上記の手法を用いることで、端末２０で商品の種別を識別することが可能となるため、識別した商品の種別の履歴を記憶部２８に記憶しておくことで、購入予定商品の購入履歴があるか否かを判定することができるためである。また、決済種別「端末コード表示」については重要度「Ｂ」が、決済種別「端末コード読み取り」については重要度「Ａ」がそれぞれ定められている。
　また、第１実施形態では、決済種別「端末コード読み取り」については、条件Ｎｏ「ＳＰ４－１」、「ＳＰ４－２」の認証スキップ条件の成否を代替的な手法で判定したが、上記のカメラを用いた手法では、端末２０で購入予定商品の種別を識別することができるため、その識別結果に基づいて、これらの認証スキップ条件の成否を判定することができる。
　また、上記のように端末２０のカメラで購入予定商品の画像を撮影する他にも、例えば店舗コードリーダ装置５０にカメラを備えておき、店舗コードリーダ装置５０のカメラで、端末２０のユーザの購入予定商品の画像を撮影するようにすることもできる。
　この場合は、１つの手法として、店舗コードリーダ装置５０が、カメラで撮影した撮影画像に基づいて購入予定商品の種別を識別し、識別した購入予定商品の種別を端末２０に送信するようにすることができる。
　また、他の手法として、店舗コードリーダ装置５０が、カメラで撮影した撮影画像を端末２０に送信し、端末２０が、店舗コードリーダ装置５０から受信した撮影画像に基づいて購入予定商品の種別を識別するようにすることもできる。
＜第１変形例（９）の効果＞
　本変形例は、前述した認証パスワードとは異なる情報は、店舗で販売される商品の情報（限定でなく、商品に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、商品に関する情報に基づいて、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、本変形例は、端末２０が、端末２０のアプリケーションカメラまたはカメラ２７（限定でなく、撮像装置の一例）によって撮影された購入予定商品の撮影画像を取得し、取得した撮影画像に基づいて、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、撮像装置によって撮影された商品の画像に基づいて、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。例えば、撮像装置によって撮影された画像から識別される商品が、過去に購入履歴がある商品であったり、特定の種別の商品である場合は、認証の実行に関する表示を行わないことで、ユーザの利便性を向上させることができる。
　また、本変形例は、前述した認証パスワードとは異なる情報は、購入予定商品の情報（限定でなく、端末のユーザが購入する商品に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、端末のユーザが購入する商品に関する情報に基づいて、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、本変形例は、端末２０のユーザの購入予定商品の情報を取得し、購入予定商品の購入履歴があると判定した場合に、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、商品が端末のユーザが一度以上購入した商品と一致した場合、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。また、同じ商品を購入するのであれば、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、本変形例は、端末２０のユーザの購入予定商品の情報を取得し、購入予定商品が日用消費財であると判定した場合に、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末が、ユーザが購入する商品が日用消費財である場合、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。また、日用消費財を購入するのであれば、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　なお、上記の他にも、端末２０のユーザが購入する商品やその商品種別を端末２０で識別する方法として、限定でなく例として、近距離無線通信や非接触式通信を用いた手法を適用することもできる。
　具体的には、限定でなく例として、店舗で販売される商品毎または商品種別毎に、商品識別情報または商品種別識別情報が格納されたＲＦタグ（例えばＩＣタグ）を埋め込んでおく。また、端末２０には、ＲＦタグ対応のリーダライタを備えておく。そして、端末２０は、ユーザが購入する商品に埋め込まれたＲＦタグを電波でスキャンし、ＲＦタグに格納された商品識別情報や商品種別識別情報を取得することで、ユーザが購入する商品やその商品種別を識別する。
＜第１変形例（１０）＞
　第１実施形態において、店舗側で、端末２０の認証処理をスキップさせることをサーバ１０に依頼し、サーバ１０が、認証処理をスキップさせるための情報（以下、「認証スキップ情報」と称す。）を端末２０に送信するようにしてもよいし、しなくてもよい。
　本変形例では、サーバ１０から送付される認証スキップ情報に基づいて、端末２０に認証処理をスキップさせることが可能となる。このため、例えば、他人の端末２０を利用して商品を購入したり、サービスの提供を受けようとする者が決済を行う場合であっても、端末２０で認証処理がスキップされて決済が行われてしまうという問題も生じ得る。本変形例は、このような問題が生じ得ることも承知の上で、店舗側にリスクを負わせ、端末２０の認証処理をスキップさせるものである。
　最初に、店舗単位で認証スキップを行わせる場合について説明する。これは、端末２０の認証処理をスキップさせるか否かを店舗の判断に委ね、リスクを承知の上で、端末２０の認証処理をスキップさせることを承諾した店舗を対象とする場合である。
　図３－３５は、この場合における各装置の処理の流れの一例を示すフローチャートであり、第１実施形態で説明した処理において、決済種別が「端末コード読み取り」である場合の処理部分である図３－３１の処理部分を抜き出したものである。なお、既出のフローチャートと同一のステップについては同一の符号を付して、再度の説明を省略する。
　店舗決済処理部５１３は、Ｂ５において、決済種別が「端末コード表示」ではない、つまり決済種別が「端末コード読み取り」であると判定したならば（Ｂ３；Ｎｏ）、通信Ｉ／Ｆ５４によって認証スキップ依頼情報をサーバ１０に送信する（Ｂ５１）。
　具体的には、自店舗が第１種端末読み取り用コードを運用する店舗である場合は、店舗決済処理部５１３は、限定でなく例として、店舗ＩＤと、第１種端末読み取り用コードに関連付けて販売する商品の販売金額情報とを含む認証スキップ依頼情報をサーバ１０に送信する。
　また、自店舗が第２種端末読み取り用コードを運用する店舗である場合は、店舗決済処理部５１３は、限定でなく例として、店舗ＩＤを含む認証スキップ依頼情報をサーバ１０に送信する。
　ここで、認証スキップ依頼情報は、端末２０に認証処理をスキップさせるための認証スキップ情報の生成をサーバ１０に依頼する情報である。この認証スキップ依頼情報は、限定でなく例として、店舗サーバ７０の承認に基づいて、店舗コードリーダ装置５０がサーバ１０に送信するようにすることができる。
　また、ここでは、店舗コードリーダ装置５０が認証スキップ依頼情報をサーバ１０に送信することとして説明するが、これに代えて、店舗サーバ７０が認証スキップ依頼情報をサーバ１０に送信するようにしてもよいし、しなくてもよい。
　決済管理処理部１１３は、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から認証スキップ依頼情報を受信すると（Ｃ５１）、端末読み取り用コード生成判定処理を行う（Ｃ５３）。
　具体的には、限定でなく例として、認証スキップ依頼情報の送信元の店舗が加盟店舗であるか否かを判定する。また、受信した認証スキップ依頼情報に第１種端末読み取り用コードに関連付けて販売する商品の販売金額情報が含まれる場合は、この販売金額情報が示す販売金額が適正な範囲内の金額（限定でなく例として、閾値金額以下（店舗の業種や販売される商品・商品種別等にもよるが、例えば「１０００円以下」、「２０００円以下」、「３０００円以下」等）であるか否かを判定する。そして、これらの条件を満たす場合は、端末読み取り用コードを生成すると判定する。一方、これらの条件を満たさない場合は、端末読み取り用コードを生成しないと判定する。
　端末読み取り用コードを生成すると判定したならば（Ｎ５５；Ｙｅｓ）、決済管理処理部１１３は、端末読み取り用コード生成処理を行う（Ｃ５７）。
　この端末読み取り用コード生成処理では、決済管理処理部１１３は、アクセス情報を含む端末読み取り用コードを生成する。より具体的には、例えば、決済用ページＵＲＬの文字列をエンコード（符号化）し、図形化して、二次元コードの画像で表される端末読み取り用コードを生成する。また、決済管理処理部１１３は、この店舗の店舗ＩＤに対応させて、販売金額（第１種端末読み取り用コードを運用する店舗のみ）と、決済用ページＵＲＬと、認証スキップ有無（ここでは認証スキップ「有」）とを関連付けて、コード管理データベース１５９の端末読み取り用コード管理データベース１５９３に記憶させる。
　その後、決済管理処理部１１３は、生成した端末読み取り用コードを、通信Ｉ／Ｆ１４によって認証スキップ依頼情報の送信元の店舗コードリーダ装置５０に送信する（Ｃ５９）。
　一方、端末読み取り用コードを生成しないと判定したならば（Ｃ５５；Ｎｏ）、決済管理処理部１１３は、端末読み取り用コードの生成が不可であることを、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０に通知する（Ｃ６１）。そして、決済管理処理部１１３は、Ｃ６３へと処理を移す。
　店舗決済処理部５１３は、通信Ｉ／Ｆ５４によってサーバ１０から端末読み取り用コードを受信したか否かを判定し（Ｂ５３）、受信したと判定したならば（Ｂ５３；Ｙｅｓ）、受信した端末読み取り用コードを表示部５３に表示させる（Ｂ５５）。
　端末２０の決済アプリケーション処理部２１３は、端末読み取り用コードをアプリケーションコードリーダで読み取る（Ａ５１）。具体的には、店舗に掲示されている端末読み取り用コードと、Ｂ５５で店舗コードリーダ装置５０に表示された端末読み取り用コードとのいずれかの端末読み取り用コードを読み取る。そして、決済アプリケーション処理部２１３は、Ａ３３、Ａ３５の処理を行う。
　Ｃ５９またはＣ６１の後、決済管理処理部１１３は、端末２０からの決済用ページへのアクセスに応じて、決済予定情報を判定する（Ｃ６３）。具体的には、端末読み取り用コード管理データベース１５９３を参照して、この決済用ページの決済用ページＵＲＬに関連付けて記憶されている情報を取得する。そして、決済管理処理部１１３は、その判定結果に応じた決済予定情報（認証スキップ「有」or「無」）を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｃ６５）。
　決済用ページＵＲＬに関連付けて記憶されている情報が、認証スキップ「無」の情報であった場合（Ｃ６１→Ｃ６３の処理の流れの場合）は、図３－３１のＣ３５と同様である。つまり、決済管理処理部１１３は、認証スキップ情報を含まない決済予定情報を端末２０に送信する。
　一方、決済用ページＵＲＬに関連付けて記憶されている情報が、認証スキップ「有」の情報であった場合（Ｃ５９→Ｃ６３の処理の流れの場合）、決済管理処理部１１３は、認証スキップ情報を含む決済予定情報を端末２０に送信する。
　この場合、決済用ページＵＲＬに関連付けられた情報が第１種端末読み取り用コードを運用する店舗に関する情報であった場合、決済管理処理部１１３は、決済予定店舗と、決済予定金額と、認証スキップ情報とを含む第１種決済予定情報を端末２０に送信する。
　一方、決済用ページＵＲＬに関連付けられた情報が第２種端末読み取り用コードを運用する店舗に関する情報であった場合、決済管理処理部１１３は、決済予定店舗と、認証スキップ情報とを含む第２種決済予定情報（決済予定金額は含まない。）を、通信Ｉ／１４によって端末２０に送信する。
　決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から決済予定情報（認証スキップ「有」or「無」）を受信すると（Ａ５３）、Ａ３９、Ａ４１の処理を行った後、第２の認証スキップ判定処理を行う（Ａ５５）。なお、他の実施形態における認証スキップ判定処理と区別するため、便宜的に「第２の認証スキップ判定処理」と称する。
　この第２の認証スキップ判定処理では、認証スキップ判定処理部２１３５は、サーバ１０から受信した決済予定情報に認証スキップ情報が含まれるか否かを判定する。Ａ５１で、店舗コードリーダ装置５０に表示された端末読み取り用コードが読み取られていた場合は、受信した決済予定情報に認証スキップ情報が含まれると判定される一方、店舗に掲示されている端末読み取り用コードが読み取られていた場合は、受信した決済予定情報に認証スキップ情報は含まれないと判定されることになる。そして、受信した決済予定情報に認証スキップ情報が含まれると判定した場合は、認証処理をスキップすると判定する。そして、決済アプリケーション処理部２１３は、Ａ１１へと処理を移す。
　なお、上記の第２の認証スキップ判定処理において、限定でなく例として、端末２０で決済アプリケーション側の決済用の認証設定が「ＯＮ」となっている場合や、端末２０で認証処理をスキップしないモード設定がなされている場合等には、決済予定情報に認証スキップ情報が含まれる場合であっても、認証処理をスキップさせないようにすることもできる。
　次に、上記の処理は、店舗単位で認証スキップを行わせる場合の処理であるが、限定でなく例として、店舗で販売される商品単位や商品種別単位で認証スキップを行わせるようにすることも可能である。
　図３－３６は、この場合にサーバ１０の記憶部１５に記憶される端末読み取り用コード管理データベース１５９３の一例を示す図である。
　この端末読み取り用コード管理データベース１５９３は、端末２０の認証処理をスキップさせることを承諾した店舗を対象として生成される端末読み取り用コード管理データを含む。
　各店舗の端末読み取り用コード管理データには、限定でなく例として、その店舗の店舗ＩＤと関連付けて、商品種別と、販売金額と、決済用ページＵＲＬと、認証スキップ有無とが関連付けて記憶される。
　この例では、商品種別には「弁当」、「飲料」、「ギフト商品」といった商品種別が含まれ、商品種別毎に、販売金額と、決済用ページＵＲＬと、認証スキップ有無とが関連付けられている。商品種別「弁当」、「飲料」には認証スキップ有無として「有」が定められているが、商品種別「ギフト商品」には認証スキップ有無として「無」が定められている。従って、ユーザがこの店舗で弁当や飲料を購入する場合は、端末２０で認証処理がスキップされるが、ユーザがこの店舗でギフト商品を購入する場合は、端末２０で認証処理がスキップされないことになる。
　また、さらには、１つの商品種別の中で、販売金額と、決済用ページＵＲＬと、認証スキップ有無とを分類して関連付けるようにすることも可能である。
　具体的には、限定でなく例として、商品種別「弁当」を、販売金額「２００円」の弁当と、販売金額「３００円」の弁当と、販売金額「５００円」の弁当とに分類し、それぞれの分類について、決済用ページＵＲＬと、認証スキップ有無とをそれぞれ関連付けるようにすることもできる。
　上記の複数のパターンは、店舗側がどのような運用を行うかに応じて、サーバ１０側で適宜設定変更するようにすることができる。
＜第１変形例（１０）の効果＞
　本変形例は、認証パスワードとは異なる情報は、認証スキップ情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、端末のユーザの認証を端末がスキップするためのスキップ情報に基づいて、端末のユーザの認証をスキップすることができる。また、端末のユーザの認証をスキップするか否かをスキップ情報に基づいて判定可能であり、他の条件の成否を判定せずに済むため、端末の処理負荷を軽減することができる。
　また、本変形例は、認証スキップ情報は、店舗コードリーダ装置５０から送信される認証スキップ依頼情報に基づいて、サーバ１０によって生成される構成を示している。
　このような構成により得られる効果の一例として、端末は、商品を管理する店舗による依頼に基づいてサーバによって生成されたスキップ情報に基づいて、端末のユーザの認証を簡単にスキップすることができる。また、端末のユーザの認証をスキップするか否かをサーバによって生成されたスキップ情報に基づいて判定可能であり、他の条件の成否を判定せずに済むため、端末の処理負荷を軽減することができる。
＜第２実施形態＞
　第２実施形態は、第１実施形態と同様に、決済の利便性を向上させる実施形態である。より具体的には、限定でなく例として、端末２０において決済アプリケーションを用いた決済を行う際に、サーバ１０において認証スキップ判定を行い、認証スキップ条件が成立する場合に、端末２０のユーザに従来要求していた認証処理をスキップさせる。
　第２実施形態に記載の内容は、他の各実施形態のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜機能構成＞
　図４－１は、本実施形態におけるサーバ１０の制御部１１により実現される機能の一例を示す図である。
　決済管理処理部１１３は、限定でなく例として、端末表示用コード生成処理部１１３１と、端末表示用コード送信処理部１１３３と、店舗用決済結果情報送信処理部１１３６と、端末用決済結果情報送信処理部１１３７とに加えて、認証スキップ判定処理部１１３９を機能部として含む。
　認証スキップ判定処理部１１３９は、記憶部１５に記憶されている認証スキップ判定処理プログラム１５１５に従って、端末２０で実行される認証処理をスキップさせるか否かを判定するための処理である認証スキップ判定処理を実行する機能を有している。この認証スキップ判定処理は、端末２０に認証処理を行わせる必要があるか否かを判定するための認証要否判定処理と言うこともできる。
　本実施形態では、認証スキップ判定処理部１１３９は、限定でなく例として、決済種別「端末コード表示」では、端末２０から端末表示用コード生成依頼情報を受信した後のタイミングで認証スキップ判定処理を実行する。
　また、認証スキップ判定処理部１１３９は、限定でなく例として、決済種別「端末コード読み取り」では、端末２０から第１の決済依頼情報を受信した後のタイミングで認証スキップ判定処理を実行する。
　ただし、これらの認証スキップ判定処理の実行タイミングは、適宜変更可能である。
　図４－２は、本実施形態におけるサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
　決済管理処理プログラム１５１３は、限定でなく例として、制御部１１により読み出され、認証スキップ判定処理として実行される認証スキップ判定処理プログラム１５１５をサブルーチンプログラムとして含む。
　また、記憶部１５には、限定でなく例として、データとして、ユーザ登録データ１５３と、店舗登録データ１５５と、決済管理データベース１５７と、コード管理データベース１５９とに加えて、認証スキップ条件データ１５６と、信用スコアデータ１５８とが記憶される。
　認証スキップ条件データ１５６は、端末２０に決済用の認証処理をスキップさせるための条件である認証スキップ条件が定められたデータである。
　信用スコアデータ１５８は、端末２０のユーザの社会的な信用を数値やランク等で表した信用スコアが、端末２０毎または端末２０のユーザ毎に記憶されたデータである。
　信用スコアは、限定でなく例として、端末２０のユーザの支払い実績、年齢、勤務形態、年収等をもとに算出または決定される。
　本実施形態では、限定でなく例として、信用スコアを「０点」～「１００点」の点数方式で数値化し、信用スコア「１００点」がユーザの社会的な信用が最も高く、信用スコア「０点」がユーザの社会的な信用が最も低いことを意味するものとする。
　図４－３は、本実施形態における認証スキップ条件データ１５６のデータ構成の一例を示す図である。このデータ構成は、端末２０の認証スキップ条件データ２８５１と同様であるが、内容が一部異なっている。以下、異なる条件に着目して説明する。
＜条件カテゴリＮｏ「ＳＰ２－５」＞
　条件カテゴリＮｏ「ＳＰ２（店舗・場所）」について、条件Ｎｏ「ＳＰ２－５」の認証スキップ条件として、「決済予定店舗の位置と端末の位置とが離れていない」が定められている。これは、決済予定店舗の位置と、決済予定の端末２０の位置とが、例えば設定距離以上離れていない場合に、端末２０の認証処理をスキップさせることを意味する。
　この判定では、限定でなく例として、サーバ１０は、認証スキップ判定処理において、店舗登録データ１５５に登録されている店舗情報から決済予定店舗の店舗位置情報を取得する。また、サーバ１０は、端末位置情報を端末２０に要求し、位置算出処理部２１７によって算出された最新の算出位置を端末位置情報として端末２０から受信して取得する。そして、サーバ１０は、店舗位置と端末位置とが設定距離以上離れているか否かを判定する。
　なお、上記の認証スキップ条件において、限定でなく例として、各店舗が存在する地域（エリア）の情報をサーバ１０の記憶部１５に記憶しておくようにし、サーバ１０が、決済予定店舗が存在する地域を特定した上で、端末位置が、特定した地域に含まれるか否かを判定するようにしてもよいし、しなくてもよい。
＜条件カテゴリＮｏ「ＳＰ５－２」＞
　条件カテゴリＮｏ「ＳＰ５（セキュリティ）」に含まれる条件Ｎｏ「ＳＰ５－２」の認証スキップ条件として、「端末のユーザの信用スコアが８０点以上」が定められている。これは、信用スコアデータ１５８に記憶されている端末２０のユーザの信用スコアが８０点以上、つまり端末２０のユーザの信用が一定の水準に達している場合に、端末２０の認証処理をスキップさせることを意味する。
　この判定では、端末２０は、信用スコアデータ１５８に記憶されている信用スコアの中から、決済予定の端末２０のユーザの信用スコアを取得する。そして、取得した信用スコアが８０点以上であるか否かを判定する。
　他の条件は、端末２０の認証スキップ条件データ２８５１と同様であるが、本実施形態では、第１実施形態とは異なり、サーバ１０が認証スキップ判定処理を行う。このため、サーバ１０は、記憶部１５のユーザ登録データ１５３に記憶されているユーザ情報、店舗登録データ１５５に記憶されている店舗情報、決済管理データベース１５７に記憶されている決済管理情報等のサーバ１０で記憶して管理している情報（以下、「サーバ管理情報」と称す。）から認証スキップ判定に必要な情報を取得する。また、サーバ１０は、端末２０の位置情報（端末位置情報）等のサーバ１０側で管理していない情報を端末２０に要求して取得する。そして、サーバ１０は、取得した情報に基づいて、認証スキップ判定を行う。
　次に、決済種別「端末コード表示」については、限定でなく例として、条件Ｎｏ「ＳＰ２－１」～「ＳＰ２－５」（条件カテゴリＮｏ「ＳＰ２」に含まれる条件）、条件Ｎｏ「ＳＰ３－３」、「ＳＰ３－４」、条件Ｎｏ「ＳＰ４－１」、「ＳＰ４－２」（条件カテゴリＮｏ「ＳＰ４」に含まれる条件）には適用無し「×」が定められている。
　条件カテゴリＮｏ「ＳＰ２」に含まれる認証スキップ条件が適用無し「×」とされているのは、決済種別「端末コード表示」では、サーバ１０が、認証スキップ判定処理を行うタイミングで決済予定店舗を把握することができないためである。
　条件Ｎｏ「ＳＰ３－３」、「ＳＰ３－４」の認証スキップ条件が適用無し「×」とされているのは、決済種別「端末コード表示」では、サーバ１０が、認証スキップ判定処理を行うタイミングで決済予定金額を把握することができないためである。
　条件カテゴリＮｏ「ＳＰ４」に含まれる認証スキップ条件が適用無し「×」とされているのは、決済種別「端末コード表示」では、サーバ１０が、認証スキップ判定処理を行うタイミングで購入予定商品を把握することができないためである。
　一方、決済種別「端末コード読み取り」については、限定でなく例として、条件Ｎｏ「ＳＰ５－１」の認証スキップ条件には適用無し「×（〇）」が定められ、それ以外の認証スキップ条件には適用有り「〇」が定められている。
　また、決済種別「端末コード表示」、「端末コード読み取り」のいずれについても、条件Ｎｏ「ＳＰ５－１」の認証スキップ条件には「×（〇）」が定められているが、これは、基本的な仕様上、端末２０のＯＳ側のロック状況と、決済アプリケーション側のロック状況とをサーバ１０側で把握することができないためである。
　ただし、これらのロック状況に関する情報をサーバ１０に通知するように端末２０側の仕様を変更すれば、サーバ１０側で端末２０のロック状況を把握することができるため、認証スキップ判定を行うことが可能となる。
＜処理＞
　図４－４～図Ｐ４－６は、本実施形態における各装置が実行する処理の流れの一例を示すフローチャートである。
　これらの図では、左側から順に、端末２０の決済アプリケーション処理部２１３が実行する決済アプリケーション処理の一例である第２の決済アプリケーション処理、店舗コードリーダ装置５０の店舗決済処理部５１３が実行する店舗決済処理の一例である第２の店舗決済処理、サーバ１０の決済管理処理部１１３が実行する決済管理処理の一例である第２の決済管理処理をそれぞれ示している。
　なお、以下説明するフローチャートは、あくまでも本実施形態における処理を例示するものであり、以下説明するフローチャートにおいて、一部のステップを実行しなくてもよいし、追加のステップを挿入してもよい。
　また、既出のフローチャートと同一のステップについては同一の符号を付して、再度の説明を省略する。
　最初に、端末２０の決済アプリケーション処理部２１３は、Ａ１～Ａ３の処理を実行する。決済種別が「端末コード表示」であったならば（Ａ３：端末コード表示）、端末表示用コード取得処理部２１３１が、Ａ５の処理を実行する。
　サーバ１０は、通信Ｉ／Ｆ１４によって端末２０から端末表示用コード生成依頼情報を受信したと判定したならば（Ｃ１；Ｙｅｓ）、認証スキップ判定処理部１１３９が、記憶部１５に記憶されている認証スキップ判定処理プログラム１５１５に従って、第３の認証スキップ判定処理を実行する（Ｇ１）。なお、他の実施形態における認証スキップ判定処理と区別するため、便宜的に「第３の認証スキップ判定処理」と称する。
　具体的には、認証スキップ判定処理部１１３９は、第１実施形態と同様の手法で、記憶部１５の認証スキップ条件データ１５６に含まれる認証スキップ条件の成否を、記憶部１５から取得した各種のサーバ管理情報と、端末２０に要求して取得した情報とに基づいて判定する。
　第３の認証スキップ判定処理を行った後、決済管理処理部１１３は、認証処理をスキップする判定がなされたか否かを判定する（Ｇ３）。認証処理をスキップすると判定された場合（Ｇ３；Ｙｅｓ）、決済管理処理部１１３は、Ｃ３へと処理を移す。
　一方、認証処理をスキップしないと判定された場合（Ｇ１：Ｎｏ）、決済管理処理部１１３が、通信Ｉ／Ｆ１４によって追加認証要求情報を端末２０に送信する（Ｇ５）。
　決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から追加認証要求情報を受信したか否かを判定し（Ｅ１）、受信しなかったと判定したならば（Ｅ１；Ｎｏ）、Ａ７へと処理を移す。この場合は、端末２０において認証処理がスキップされる。
　一方、通信Ｉ／Ｆ２２によってサーバ１０から追加認証要求情報を受信したと判定したならば（Ｅ１；Ｙｅｓ）、決済アプリケーション処理部２１３は、Ａ１３～Ａ１７の処理を実行する。この場合は、端末２０において認証処理が実行される。
　認証処理で認証結果が「ＯＫ」となった場合（Ａ１５；Ｙｅｓ）、決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によって認証成功情報をサーバ１０に送信する（Ｅ３）。
　決済管理処理部１１３は、通信Ｉ／Ｆ１４によって端末２０から認証成功情報を受信すると（Ｇ７）、Ｃ３、Ｃ５の処理を実行する。つまり、端末２０から認証が成功したことを示す情報を受信した後、端末表示用コードを生成し（Ｃ３）、生成した端末表示用コードを端末２０に送信する（Ｃ５）。
　一方、Ａ３において決済種別が「端末コード読み取り」であると判定したならば（Ａ３；端末コード読み取り）、決済アプリケーション処理部２１３は、Ａ３１～Ａ４３の処理を実行する。
　サーバ１０は、通信Ｉ／Ｆ１４によって端末２０から第１の決済依頼情報を受信すると（Ｃ３７）、認証スキップ判定処理部１１３９が、記憶部１５に記憶されている認証スキップ判定処理プログラム１５１５に従って、第３の認証スキップ判定処理を実行する（Ｇ１）。
　第３の認証スキップ判定処理を行った後、決済管理処理部１１３は、認証処理をスキップする判定がなされたか否かを判定する（Ｇ３）。認証処理をスキップすると判定された場合（Ｇ３；Ｙｅｓ）、決済管理処理部１１３は、Ｃ１１へと処理を移す。
　一方、認証処理をスキップしないと判定された場合（Ｇ１：Ｎｏ）、決済管理処理部１１３は、通信Ｉ／Ｆ１４によって追加認証要求情報を端末２０に送信する（Ｇ５）。
　決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から追加認証要求情報を受信したか否かを判定し（Ｅ１）、受信しなかったと判定したならば（Ｅ１；Ｎｏ）、Ａ２１へと処理を移す。この場合は、端末２０において認証処理がスキップされる。
　一方、決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から追加認証要求情報を受信したと判定したならば（Ｅ１；Ｙｅｓ）、Ａ１３～Ａ１７の処理を実行する。この場合は、端末２０において認証処理が実行される。
　なお、上記の処理では、決済種別が「端末コード表示」である場合に、サーバ１０が、端末２０から端末表示用コード生成依頼情報を受信した後（Ｃ１；Ｙｅｓの後）のタイミングで第３の認証スキップ判定処理を行うこととしたが、これに限定されない。
　限定でなく例として、サーバ１０が、店舗コードリーダ装置５０から第２の決済依頼情報を受信した後（Ｃ９の後）のタイミングで、第３の認証スキップ判定処理を行うようにしてもよいし、しなくてもよい。
＜第２実施形態の効果＞
　第２実施形態は、サーバ１０が、端末２０から決済依頼情報（限定でなく、端末による電子貨幣の決済に関する情報の一例）を通信Ｉ／Ｆ１４によって受信し、追加認証要求情報（限定でなく、端末のユーザの認証に関する情報）を通信Ｉ／Ｆ１４によって端末２０に送信する。また、サーバ１０は、端末２０から認証成功情報（限定でなく、端末のユーザが認証されたことを示す情報の一例）を通信Ｉ／Ｆ１４によって受信し、受信した認証成功情報に基づいて、決済結果情報（電子貨幣による決済が行われたことを示す決済情報の一例）を端末２０に通信Ｉ／Ｆ１４によって送信する。そして、サーバ１０は、端末２０のユーザを認証するための認証パスワード（限定でなく、認証情報の一例）とは異なる情報を取得することで、追加認証要求情報を通信Ｉ／Ｆ１４によって端末２０に送信せず、決済結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、電子貨幣による決済に際して、端末のユーザを認証するための認証情報とは異なる情報を取得することで、端末のユーザの認証に関する情報を端末に送信しないため、サーバの処理負荷を軽減することができる。また、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができるため、ユーザの利便性を向上させることができる。
　また、第２実施形態は、上記の認証パスワードとは異なる情報は、端末２０の端末識別情報または、端末２０のユーザ識別情報に関連付けられた情報（限定でなく、端末または、端末のユーザを識別するための識別情報に関連付けられた情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末または、端末のユーザを識別するための識別情報に関連付けられた情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。
　また、第２実施形態は、上記の端末２０の端末識別情報または、端末２０のユーザ識別情報に関連付けられた情報は、端末２０または、端末２０のユーザに関連付けられたＩＭＳマネーに関する情報（限定でなく、端末または、端末のユーザに関連付けられた電子貨幣に関連する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末または、端末のユーザに関連付けられた電子貨幣に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。
　また、第２実施形態は、上記の端末２０または、端末２０のユーザに関連付けられたＩＭＳマネーに関する情報は、端末２０または、端末２０のユーザに関連付けられているＩＭＳマネーの金額に関する情報（限定でなく、端末または、端末のユーザに関連付けられている電子貨幣の金額に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末または、端末のユーザに関連付けられている電子貨幣の金額に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。例えば、電子貨幣の金額が低い場合には、端末のユーザの認証に関する情報を端末に送信しないようにすることで、端末での認証を省略させるといったことが可能となり、ユーザの利便性を向上させることができる。
　また、第２実施形態は、上記の端末２０または、端末２０のユーザに関連付けられているＩＭＳマネーの金額に関する情報は、１日上限設定金額（限定でなく、設定された前記電子貨幣の設定金額に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、設定された電子貨幣の設定金額に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。
　また、第２実施形態は、サーバ１０は、上記の１日上限設定金額を超えるまで、追加認証要求情報（限定でなく、端末のユーザの認証に関する情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信せず、決済結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、設定された電子貨幣の設定金額を超えるまで、端末のユーザの認証に関する情報を端末に送信しないため、サーバの通信量を削減することができ、サーバの負荷を軽減することができる。また、サーバは、設定された電子貨幣の設定金額を超えた場合は、端末のユーザの認証に関する情報を端末に送信するため、設定金額を超えたことを端末のユーザに注意喚起することができる。
　また、第２実施形態は、上記のＩＭＳマネーの金額に関する情報は、端末２０または、端末２０のユーザに関連付けられたＩＭＳマネーの残高の情報（限定でなく、端末または、端末のユーザに関連付けられた電子貨幣の残高に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末または、端末のユーザに関連付けられた電子貨幣の残高に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。また、サーバは、端末または、端末のユーザに関連付けられた電子貨幣の残高に関する情報に基づいて、決済に関する処理を適正に行うことができる。
　また、第２実施形態は、サーバ１０は、上記のＩＭＳマネーの残高が、設定金額以下または、設定金額未満の場合、追加認証要求情報（限定でなく、端末のユーザの認証に関する情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信せず、決済結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、電子貨幣の残高が、設定された金額以下または、設定された金額未満の場合、端末のユーザの認証に関する情報を端末に送信しないため、サーバの通信量を削減することができ、サーバの負荷を軽減することができる。また、例えば、電子貨幣の残高が少ない場合は、高額の決済ができず、危険性は低いと考えられるため、端末のユーザの認証に関する情報を端末に送信しないようにすることで、端末での認証を省略させるといったことが可能となり、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第２実施形態は、サーバ１０が、端末２０のオートチャージ設定が「ＯＮ」となっている場合、ＩＭＳマネーの残高が設定金額以下または、設定金額未満の場合に追加認証要求情報を通信Ｉ／Ｆ１４によって端末２０に送信し、決済結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末の電子貨幣が設定された金額以下または、設定された金額未満になった場合に自動で電子貨幣の入金が端末に行われる設定になっている場合、金額が少なくなれば自動で電子貨幣の入金が端末に行われるため、高額の決済が可能となり、リスクが生ずる。このため、サーバは、端末のユーザの認証に関する情報を通信部によって端末に送信することで、高額の決済が可能になることをユーザに注意喚起することができる。
　また、第２実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーによって決済を行った頻度または回数の情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、電子貨幣によって決済を行った頻度または回数に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。例えば、電子貨幣によって決済が行われた頻度が高い場合や回数が多い場合は、同じユーザが電子貨幣によって決済を行っている可能性が高く、危険性は低いと考えられるため、端末のユーザの認証に関する情報を端末に送信しないようにすることで、端末での認証を省略させるといったことが可能となり、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第２実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーによって決済を行った時間の情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、電子貨幣によって決済を行った時間に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。
　また、第２実施形態は、サーバ１０は、決済を行った時間から設定時間内の場合、追加認証要求情報（限定でなく、端末のユーザの認証に関する情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信せず、決済結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、決済を行った時間から設定された時間内の場合、端末のユーザの認証に関する情報を端末に送信しないため、サーバの通信量を削減することができ、サーバの負荷を軽減することができる。また、例えば、決済を行ってからそれほど時間が経過していなければ、同じユーザが再び決済を行う可能性が高く、危険性は低いと考えられるため、端末のユーザの認証に関する情報を端末に送信しないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第２実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーによって決済を行った場所に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、電子貨幣によって決済を行った場所に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。
　また、第２実施形態は、上記のＩＭＳマネーによって決済を行った場所に関する情報は、ＩＭＳマネーによって決済を行った店舗に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、電子貨幣によって決済を行った店舗に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。
　また、第２実施形態は、サーバ１０は、ＩＭＳマネーによって決済を行った店舗の位置と、端末２０の位置とに基づいて、追加認証要求情報（限定でなく、端末のユーザの認証に関する情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信せず、決済結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、電子貨幣によって決済を行った店舗に関する情報と、端末の位置に関する情報とに基づいて、端末のユーザの認証に関する情報を端末に送信しないため、サーバの通信量を削減することができ、サーバの負荷を軽減することができる。また、例えば、過去に電子貨幣によって決済を行った店舗から端末の位置が離れていなければ、ユーザが同じ店舗で決済を行おうとしている可能性が高く、危険性は低いと考えられるため、端末のユーザの認証に関する情報を端末に送信しないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第２実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーの決済をするための認証の実行を行った店舗の場所に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、電子貨幣の決済をするための認証の実行を行った場所に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。また、例えば、過去に電子貨幣の決済をするための認証の実行を行った場所であれば、同じユーザについて再び認証の実行を行う場合であり、危険性は低いと考えられるため、端末のユーザの認証に関する情報を端末に送信しないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第２実施形態は、上記の端末２０の端末識別情報または、端末２０のユーザ識別情報に関連付けられた情報（限定でなく、端末または、端末のユーザを識別するための識別情報に関連付けられた情報の一例）は、端末２０のユーザによって購入された商品の情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末のユーザによって購入された商品に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。
　また、第２実施形態は、サーバ１０が、端末２０のユーザによって購入された商品の情報と、端末２０のユーザによって購入される商品の情報とに基づいて、追加認証要求情報を通信Ｉ／Ｆ１４によって端末２０に送信せず、決済結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末のユーザによって購入された商品に関する情報と、端末のユーザによって購入される商品に関する情報とに基づいて、端末のユーザの認証に関する情報を端末に送信しないため、サーバの通信量を削減することができ、サーバの負荷を軽減することができる。また、例えば、過去に同じ商品が購入されていれば、同じユーザが同じ商品を購入しようとしている可能性が高く、危険性は低いと考えられるため、端末のユーザの認証に関する情報を端末に送信しないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第２実施形態は、上記の認証パスワードとは異なる情報は、店舗に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、場所に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。
　また、第２実施形態は、上記の店舗に関する情報は、商品を購入する店舗に関する情報を含み、店舗サーバ７０から送信され、サーバ１０が、通信Ｉ／Ｆ１４によって受信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、商品を管理する店舗のサーバから送信される商品を購入する店舗に関する情報を受信することによって取得することができる。
　また、第２実施形態は、サーバ１０が、端末２０の位置情報を通信Ｉ／Ｆ１４によって端末２０から受信し、端末２０のユーザが商品を購入する店舗の位置情報と、端末２０の位置情報とに基づいて、追加認証要求情報を通信Ｉ／Ｆ１４によって端末２０に送信せず、決済結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、商品を購入する店舗の位置に関する情報と、受信した端末の位置に関する情報とに基づいて、端末のユーザの認証に関する情報を端末に送信しないため、サーバの通信量を削減することができ、サーバの負荷を軽減することができる。また、例えば、商品を購入する店舗の位置と端末の位置とが離れていなければ、ユーザがその店舗で決済を行おうとしている可能性が高く、危険性は低いと考えられるため、端末のユーザの認証に関する情報を端末に送信しないことで、ユーザの利便性を向上させることができる。
　また、第２実施形態は、上記の認証パスワードとは異なる情報は、商品に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、商品に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。
　また、第２実施形態は、サーバ１０が、購入予定商品が日用消費財である場合、追加認証要求情報（限定でなく、端末のユーザの認証に関する情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信せず、決済結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、商品に関する情報と、予め設定された商品に関する情報とが一致する場合、端末のユーザの認証に関する情報を端末に送信しないため、サーバの通信量を削減することができ、サーバの負荷を軽減することができる。
　また、第２実施形態は、上記の商品に関する情報は、購入する商品の総額に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、商品の総額に関する情報を取得することで、端末のユーザの認証に関する情報を端末に送信することなく決済情報を端末に送信することができる。また、例えば、商品の総額が低額である場合は、危険性は低いと考えられるため、端末のユーザの認証に関する情報を端末に送信しないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
＜第２変形例（１）＞
　第１実施形態で説明した端末２０側での認証スキップ判定と、第２実施形態で説明したサーバ１０側での認証スキップ判定とを組み合わせて、複合的な処理を行うようにしてもよいし、しなくてもよい。
　図４－７、図４－８は、この場合に各装置が実行する処理の流れの一例を示すフローチャートである。
　これらの図では、左側から順に、端末２０の決済アプリケーション処理部２１３が実行する決済アプリケーション処理の一例である第３の決済アプリケーション処理、店舗コードリーダ装置５０の店舗決済処理部５１３が実行する店舗決済処理の一例である第３の店舗決済処理、サーバ１０の決済管理処理部１１３が実行する決済管理処理の一例である第３の決済管理処理をそれぞれ示している。
　決済アプリケーション処理部２１３は、Ａ３において決済種別が「端末コード表示」であると判定したならば（Ａ３；端末コード表示）、第１の認証スキップ判定処理を行う（Ｈ３）。そして、決済アプリケーション処理部２１３は、Ａ１１～Ａ１７の処理を行う。
　Ａ１５において認証結果が「ＯＫ」であると判定した場合（Ａ１５；Ｙｅｓ）、または、Ａ１１において認証処理をスキップすると判定した場合（Ａ１１；Ｙｅｓ）、決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によって、ユーザＩＤと、認証処理をスキップしたか否かを示す情報である認証スキップ状況情報とを含む端末表示用コード生成依頼情報を、サーバ１０に送信する（Ｈ１５）。
　決済管理処理部１１３は、通信Ｉ／Ｆ１４によって端末２０から端末表示用コード生成依頼情報を受信したか否かを判定する（Ｊ１）。そして、受信したと判定したならば（Ｃ１；Ｙｅｓ）、Ｃ３～Ｃ９の処理を行った後、認証スキップ判定処理部１１３９が、第４の認証スキップ判定処理を実行する（Ｊ３）。なお、他の実施形態における認証スキップ判定処理と区別するため、便宜的に「第４の認証スキップ判定処理」と称する。
　この第４の認証スキップ判定処理では、認証スキップ判定処理部１１３９は、端末２０から受信した端末表示用コード生成依頼情報に含まれる認証スキップ状況情報に基づいて、端末２０で認証処理がスキップされたか否かを判定する。
　端末２０で認証処理がスキップされなかった場合、認証スキップ判定処理部１１３９は、追加認証不要と判定する。これは、端末２０で既に認証処理が済んでいるためである。
　一方、端末２０で認証処理がスキップされた場合、認証スキップ判定処理部１１３９は、記憶部１５の認証スキップ条件データ１５６に含まれる認証スキップ条件に基づいて、認証スキップ条件の成否を判定する。そして、認証スキップ条件が成立する場合は、追加認証不要と判定し、認証スキップ条件が成立しない場合は、追加認証必要と判定する。これは、端末２０では認証処理がスキップされたが、サーバ１０による認証スキップ判定の結果によっては、端末２０に追加認証を行わせた方がよい場合があるためである。
　具体例として、例えば、端末２０側での認証スキップに関する設定と、サーバ１０側での認証スキップに関する設定との相違により、端末２０では決済予定金額が高額ではないため認証処理をスキップさせると判定されたが、サーバ１０では決済予定金額が高額であるため端末２０の認証処理をスキップさせることに問題あり（リスクあり）と判断され、端末２０の認証スキップを取り消して、追加認証を行わせるような場合が挙げられる。
　なお、上記とは異なり、端末２０で認証処理がスキップされた場合、サーバ１０は端末２０の判断を信頼することとして、追加認証不要と判定してもよい。この場合は、サーバ１０側で認証スキップ判定を行わずに済む。
　第４の認証スキップ判定処理で追加認証必要と判定された場合（Ｇ３；Ｎｏ）、決済管理処理部１１３は、通信Ｉ／Ｆ１４によって追加認証要求情報を端末２０に送信する（Ｇ５）。そして、決済管理処理部１１３は、通信Ｉ／Ｆ１４によって端末２０から認証成功情報を受信した後（Ｇ７）、決済処理を行う（Ｃ１１）。そして、決済管理処理部１１３は、Ｃ１３へと処理を移す。
　決済アプリケーション処理部２１３は、Ａ１９の後、Ｅ１、Ａ１３～Ａ１７、Ｅ３の処理を行った後、Ａ２１へと処理を移す。
＜第２変形例（１）の効果＞
　本変形例により得られる効果の一例として、端末とサーバとで連携して、端末のユーザの認証に関する表示処理を実行するか否かを判定することができる。また、表示処理の実否に関する情報を端末からサーバに送信することで、サーバは、表示処理を追加的に端末に実行させるか否かを簡単に判定することができる。
＜第２変形例（２）＞
　＜第１変形例（１０）＞と同様に、店舗側で、端末２０に認証処理をスキップさせることをサーバ１０に依頼するようにすることもできる。
　図４－９は、この場合における各装置の処理の流れの一例を示すフローチャートであり、第２実施形態で説明した処理において、決済種別が「端末コード読み取り」である場合の処理部分である図４－５の処理部分を抜き出したものである。なお、既出のフローチャートと同一のステップについては同一の符号を付して、再度の説明を省略する。
　決済管理処理部１１３は、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から認証スキップ依頼情報を受信すると（Ｃ５１）、Ｃ５３～Ｃ６５の処理を行う。その後、決済管理処理部１１３は、通信Ｉ／Ｆ１４によって端末２０から第１の決済依頼情報を受信すると（Ｃ３７）、認証スキップ判定処理部１１３９が、第５の認証スキップ判定処理を実行する（Ｇ５１）。なお、他の実施形態における認証スキップ判定処理と区別するため、便宜的に「第５の認証スキップ判定処理」と称する。
　この第５の認証スキップ判定処理では、認証スキップ判定処理部１１３９は、端末読み取り用コード管理データベース１５９３を参照して、端末２０によってアクセスされた決済用ページＵＲＬに認証スキップ「有」が関連付けられているか否かを判定し、関連付けられている場合は、認証処理をスキップすると判定する。そして、決済管理処理部１１３は、Ｇ３以降へと処理を移す。
＜第２変形例（２）の効果＞
　本変形例は、認証パスワードとは異なる情報は、認証スキップ情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末のユーザの認証をスキップさせるためのスキップ情報に基づいて、端末のユーザの認証を端末に簡単にスキップさせることができる。
　また、本変形例は、認証スキップ情報は、店舗コードリーダ装置５０から送信される認証スキップ依頼情報に基づいて、サーバ１０が生成する構成を示している。
　このような構成により得られる効果の一例として、サーバは、商品を管理する店舗による依頼に基づいて、端末のユーザの認証を端末にスキップさせるためのスキップ情報を生成することができる。
＜第２変形例（３）＞
　サーバ１０が、端末２０のユーザの信用スコアに基づいて、認証スキップ条件を変更するようにしてもよいし、しなくてもよい。
　具体的には、限定でなく例として、サーバ１０は、端末２０のユーザの信用スコアが高くなるほど、認証スキップ条件データ１５６の条件Ｎｏ「ＳＰ１－１」の認証スキップ条件における「設定時間」を長くするようにしてもよいし、しなくてもよい。
　より具体的には、限定でなく例として、信用スコアが０点の場合の設定時間を「２時間」として設定しておく。また、信用スコアの閾値として１０点の整数倍の閾値（１０点、２０点、・・・、１００点）を設定しておく。そして、端末２０のユーザの信用スコアが閾値に達するごとに、設定時間を１時間ずつ長く設定するなどすることができる。
　また、限定でなく例として、サーバ１０は、端末２０のユーザの信用スコアが高くなるほど、認証スキップ条件データ１５６の条件Ｎｏ「ＳＰ３－１」の認証スキップ条件における「１日上限設定金額」を高くするようにしてもよいし、しなくてもよい。より具体的には、限定でなく例として、信用スコアが０点の場合の１日上限設定金額を「０円」として設定しておく。また、信用スコアの閾値として１０点の整数倍の閾値（１０点、２０点、・・・、１００点）を設定しておく。そして、端末２０のユーザの信用スコアが閾値に達するごとに、１日上限設定金額を５０００円ずつ高く設定するなどすることができる。
　また、限定でなく例として、端末２０のユーザの信用スコアが高くなるほど、認証処理をスキップすると判定され易くなるようにしてもよいし、しなくてもよい。例えば、信用スコアが「９０点以上」のユーザについては、他の種別の認証スキップ条件の成否に関わらず認証処理をスキップさせる。また、信用スコアが「８０点以上９０点未満」のユーザについては、他の種別の認証スキップ条件のうちのいずれか１つの認証スキップ条件が成立する場合に認証処理をスキップさせ、信用スコアが「７０点以上８０点未満」のユーザについては、他の種別の認証スキップ条件のうちのいずれか２つの認証スキップ条件が成立する場合に認証処理をスキップさせる。
　以下同様である。
　また、限定でなく例として、信用スコアが閾値スコア以上（例えば「６０点以上」）のユーザについては、第２実施形態で説明した手法でサーバ１０でのみ認証スキップ判定を行うが、信用スコアが閾値スコア未満（例えば「６０点未満」）のユーザについては、第２変形例（１）で説明した手法で端末２０とサーバ１０との両方で認証スキップ判定を行うようにしてもよいし、しなくてもよい。
＜第２変形例（３）の効果＞
　本変形例により得られる効果の一例として、端末のユーザの信用に基づいてスキップ条件を変更することができる。例えば、端末のユーザの信用が高いほど認証がスキップされ易くなるようにすることで、ユーザの利便性を向上させることができる。
＜第２変形例（４）＞
　端末２０が決済を行う場所として、例えば、新幹線の車内販売を利用して商品を購入するような場合や、移動する屋台で食事を行うような場合が想定される。この場合、端末２０の位置と店舗の位置とが、それぞれ変化することになる。
　そこで、移動型の店舗については、サーバ１０が移動型の店舗から店舗位置情報を取得するようにする。また、サーバ１０は、端末２０から端末位置情報を取得する。そして、サーバ１０は、例えば条件Ｎｏ「ＳＰ２－５」の認証スキップ条件「決済予定店舗の位置と端末の位置とが離れていない」を判定する際に、移動型の店舗から取得した店舗位置情報と、端末２０から取得した端末位置情報とに基づいて判定を行うようにするとよい。
＜第２変形例（４）の効果＞
　本変形例により得られる効果の一例として、店舗が移動する場合であっても、サーバは、端末から取得した位置情報と、店舗から取得した位置情報とに基づいて、端末のユーザの認証を適切にスキップさせることができる。
＜第３実施形態＞
　第３実施形態は、前述した認証スキップ情報を、決済用のコードに含める実施形態である。第３実施形態では、＜第１変形例（１０）＞と同様の思想に基づき、店舗側にリスクを負わせて、端末２０の認証処理をスキップさせる。＜第１変形例（１０）＞と異なるのは、認証スキップ情報を端末読み取り用コードに含める点である。
　第３実施形態に記載の内容は、他の各実施形態のいずれにも適用可能である。
　また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜機能構成＞
　図５－１は、本実施形態におけるサーバ１０の制御部１１により実現される機能の一例を示す図である。
　決済管理処理部１１３は、端末表示用コード生成処理部１１３１と、端末表示用コード送信処理部１１３３と、店舗用決済結果情報送信処理部１１３６と、端末用決済結果情報送信処理部１１３７と、認証スキップ判定処理部１１３９とに加えて、特別端末読み取り用コード生成処理部１１３４と、特別端末読み取り用コード送信処理部１１３５とを有する。
　特別端末読み取り用コード生成処理部１１３４は、認証スキップ情報を含む特別な端末読み取り用コードである特別端末読み取り用コードを生成する機能を有している。
　特別端末読み取り用コード送信処理部１１３５は、特別端末読み取り用コード生成処理部１１３４によって生成された特別端末読み取り用コードを、端末２０に送信する機能を有している。
＜処理＞
　図５－２は、本実施形態における各装置の処理の流れの一例を示すフローチャートであり、第１実施形態で説明した処理において、決済種別が「端末コード読み取り」である場合の処理部分である図３－２９の処理部分を抜き出したものである。なお、既出のフローチャートと同一のステップについては同一の符号を付して、再度の説明を省略する。
　店舗決済処理部５１３は、Ｂ５において、決済種別が「端末コード表示」ではない、つまり決済種別が「端末コード読み取り」であると判定したならば（Ｂ３；Ｎｏ）、通信Ｉ／Ｆ５４によって特別端末読み取り用コード生成依頼情報をサーバ１０に送信する（Ｍ５１）。
　具体的には、自店舗が第１種端末読み取り用コードを運用する店舗である場合は、店舗決済処理部５１３は、限定でなく例として、店舗ＩＤと、第１種端末読み取り用コードに関連付けて販売する商品の販売金額情報と、認証スキップ依頼情報とを含む特別端末読み取り用コード生成依頼情報をサーバ１０に送信する。
　また、自店舗が第２種端末読み取り用コードを運用する店舗である場合は、店舗決済処理部５１３は、限定でなく例として、店舗ＩＤと、認証スキップ依頼情報とを含む特別端末読み取り用コード生成依頼情報をサーバ１０に送信する。
　ここで、認証スキップ依頼情報は、＜第１変形例（１０）＞で説明した認証スキップ依頼情報と同様であり、認証スキップ情報の生成をサーバ１０に依頼する情報（依頼情報）である。この認証スキップ依頼情報は、限定でなく例として、店舗サーバ７０の承認に基づいて、店舗コードリーダ装置５０からサーバ１０に送信するようにすることができる。つまり、認証スキップ依頼情報は、端末２０によるＩＭＳマネーの決済を行う店舗のサーバ（店舗サーバ７０）によって依頼される情報とも言える。
　具体的には、自店舗が第１種端末読み取り用コードを運用する店舗である場合は、限定でなく例として、店舗が一律の金額で販売する弁当や飲料等の商品の販売金額情報を、特別端末読み取り用コード生成依頼情報に含めるようにすることができる。
　ただし、特別端末読み取り用コード生成依頼情報に含めることのできる情報は、上記の情報に限定されない。上記の情報の他にも、限定でなく例として、特別端末読み取り用コードに関連付けて販売する商品に関する情報（商品名や商品種別等）を含めるようにしてもよいし、しなくてもよい。
　また、上記の商品に関する情報は、限定でなく例として、設定金額以下または設定金額未満の商品（店舗の業種や販売される商品・商品種別等にもよるが、例えば「５００円以下」または「５００円未満」の商品、「１０００円以下」または「１０００円未満」の商品）に関する情報としてもよいし、しなくてもよい。
　また、第１種端末読み取り用コードを運用する店舗では、限定でなく例として、端末２０のユーザがＩＭＳマネーによって購入する商品の総額を、店舗の店員が店舗コードリーダ装置５０に入力して設定するなどして、端末２０のユーザがＩＭＳマネーによって購入する商品の総額に関する情報を、特別端末読み取り用コード生成依頼情報に含めるようにしてもよいし、しなくてもよい。
　また、店舗コードリーダ装置５０が、店舗ＩＤ（店舗識別情報）に代えて、または、これに加えて、店舗の所在地のエリア情報（限定でなく、場所に関する情報の一例）を特別端末読み取り用コード生成依頼情報に含めて、サーバ１０に送信するようにしてもよいし、しなくてもよい。
　なお、ここでは店舗コードリーダ装置５０が、特別端末読み取り用コード生成依頼情報をサーバ１０に送信することとして説明するが、これに代えて、店舗サーバ７０が、特別端末読み取り用コード生成依頼情報をサーバ１０に送信するようにしてもよいし、しなくてもよい。
　決済管理処理部１１３は、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から特別端末読み取り用コード生成依頼情報を受信すると（Ｎ５１）、特別端末読み取り用コード生成判定処理を行う（Ｎ５３）。
　具体的には、限定でなく例として、特別端末読み取り用コード生成依頼情報の送信元の店舗が加盟店舗であるか否かを判定する。また、受信した特別端末読み取り用コード生成依頼情報に第１種端末読み取り用コードに関連付けて販売する商品の販売金額情報が含まれる場合は、この販売金額情報が示す販売金額が適正な範囲内の金額（限定でなく例として、閾値金額以下（店舗の業種や販売される商品・商品種別等にもよるが、例えば「１０００円以下」、「２０００円以下」、「３０００円以下」等）であるか否かを判定する。そして、これらの条件を満たす場合は、特別端末読み取り用コードを生成すると判定する。一方、これらの条件を満たさない場合は、特別端末読み取り用コードを生成しないと判定する。
　特別端末読み取り用コードを生成すると判定したならば（Ｎ５５；Ｙｅｓ）、特別端末読み取り用コード生成処理部１１３４が、特別端末読み取り用コード生成処理を行う（Ｎ５７）。
　この特別端末読み取り用コード生成処理では、特別端末読み取り用コード生成処理部１１３４は、限定でなく例として、アクセス情報と、認証スキップ情報とを含む特別端末読み取り用コードを生成する。より具体的には、例えば、決済用ページＵＲＬの文字列と、認証処理をスキップすることを指示または要求するコマンドの文字列とで構成されるデータをエンコード（符号化）し、図形化して、二次元コードの画像で表される特別端末読み取り用コードを生成する。
　また、決済管理処理部１１３は、この店舗の店舗ＩＤに対応させて、販売金額（第１種特別端末読み取り用コードを運用する店舗のみ）と、決済用ページＵＲＬと、認証スキップ有無（ここでは認証スキップ「有」）とを関連付けて、コード管理データベース１５９の端末読み取り用コード管理データベース１５９３に記憶させる。
　なお、認証スキップ情報として、認証処理をスキップすることを指示または要求するコマンドを特別端末読み取り用コードに含めるようにするのではなく、認証スキップ情報を含むトークンを特別端末読み取り用コードに含めるようにしてもよいし、しなくてもよい。
　その後、特別端末読み取り用コード送信処理部１１３５が、特別端末読み取り用コードを通信Ｉ／Ｆ１４によって特別端末読み取り用コード生成依頼情報の送信元の店舗コードリーダ装置５０に送信する（Ｎ５９）。
　一方、特別端末読み取り用コードを生成しないと判定したならば（Ｎ５５；Ｎｏ）、決済管理処理部１１３は、特別端末読み取り用コードの生成が不可であることを、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０に通知する（Ｎ６１）。そして、決済管理処理部１１３は、Ｎ６３へと処理を移す。
　店舗決済処理部５１３は、通信Ｉ／Ｆ５４によってサーバ１０から特別端末読み取り用コードを受信したか否かを判定し（Ｍ５３）、受信したと判定したならば（Ｍ５３；Ｙｅｓ）、受信した特別端末読み取り用コードを表示部５３に表示させる（Ｍ５５）。
　一方、店舗決済処理部５１３は、通信Ｉ／Ｆ５４によってサーバ１０から特別端末読み取り用コードを受信せずに、認証スキップ不可情報を受信したと判定したならば（Ｍ５３；Ｎｏ）、図３－３２のＢ１５へと処理を移す。
　端末２０の決済アプリケーション処理部２１３は、店舗に掲示されている端末読み取り用コードと、Ｍ５５で店舗コードリーダ装置５０の表示部５３に表示された特別端末読み取り用コードとのいずれかをアプリケーションコードリーダで読み取る（Ｌ５１）。そして、決済アプリケーション処理部２１３は、Ａ３３、Ａ３５の処理を行う。
　決済管理処理部１１３は、端末２０からの決済用ページへのアクセスに応じて、決済予定情報を判定する（Ｎ６３）。具体的には、端末読み取り用コード管理データベース１５９３を参照して、この決済用ページに関連付けて記憶された情報を取得する。そして、決済管理処理部１１３は、その判定結果に応じた決済予定情報を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｎ６５）。
　この場合、決済用ページに関連付けられた情報が、第１種特別端末読み取り用コードを運用する店舗に関する情報であった場合は、決済管理処理部１１３は、決済予定店舗と、決済予定金額とを含む第１種決済予定情報を、通信Ｉ／１４によって端末２０に送信する。一方、決済用ページに関連付けられた情報が、第２種特別端末読み取り用コードを運用する店舗に関する情報であった場合は、決済管理処理部１１３は、決済予定店舗を含む第２種決済予定情報（決済予定金額は含まない。）を、通信Ｉ／１４によって端末２０に送信する。
　決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から決済予定情報を受信すると（Ｌ５３）、Ａ３９、Ａ４１の処理を行った後、第６の認証スキップ判定処理を行う（Ｌ５５）。
　この第６の認証スキップ判定処理では、認証スキップ判定処理部２１３５は、Ａ３３のコード情報取得処理で取得したコード情報に認証スキップ情報が含まれるか否かを判定する。Ｌ５１で、店舗コードリーダ装置５０に表示された特別端末読み取り用コードが読み取られていた場合は、取得したコード情報に認証スキップ情報が含まれると判定される一方、店舗に掲示されている端末読み取り用コードが読み取られていた場合は、取得したコード情報に認証スキップ情報は含まれないと判定されることになる。そして、取得したコード情報に認証スキップ情報が含まれると判定した場合は、認証処理をスキップすると判定する。そして、決済アプリケーション処理部２１３は、Ａ１１へと処理を移す。
＜第３実施形態の効果＞
　第３実施形態は、サーバ１０（限定でなく、情報処理装置の一例）が、端末２０によるＩＭＳマネー（限定でなく、電子貨幣の一例）の決済に関する特別端末読み取り用コード（限定でなく、コード情報の一例）を生成する。サーバ１０は、特別端末読み取り用コード依頼情報に基づいて、店舗情報や販売金額情報等の情報（限定でなく、情報の一例）を取得する。そして、サーバ１０は、取得した情報に基づいて、端末２０で実行される認証処理に関する情報（限定でなく、端末のユーザの認証に関する情報の一例）を含めて、特別端末読み取り用コードを生成する構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、取得した情報に基づいて、端末のユーザの認証に関する情報を含めて、コード情報を簡単に生成することができる。また、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記の特別端末読み取り用コード（限定でなく、コード情報の一例）は、端末２０のアプリケーションコードリーダ（限定でなく、コードリーダの一例）によって読み取られる情報を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、端末のコードリーダによって読み取られる情報を含むコード情報を生成することができる。
　また、第３実施形態は、上記のサーバ１０が取得する情報は、認証パスワード（限定でなく、端末のユーザを認証するための認証情報の一例）とは異なる情報を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、端末のユーザを認証するための認証情報とは異なる情報を取得することで、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記の認証パスワードとは異なる情報は、場所に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、場所に関する情報を取得することで、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記の場所に関する情報は、店舗識別情報（限定でなく、端末によって電子貨幣による決済が行われる店舗に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、端末によって電子貨幣による決済が行われる店舗に関する情報を取得することで、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記の特別端末読み取り用コードは、店舗がサーバ１０に記憶されている第１特定業種の店舗（限定でなく、特定の店舗の一例）の場合、認証スキップ情報を含めて生成される構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、店舗が情報処理装置に記憶されている特定の店舗の場合、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記の認証パスワードとは異なる情報は、店舗で販売される商品名や商品種別（限定でなく、商品に関する情報の一例）に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、商品に関する情報を取得することで、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記の商品に関する情報は、設定金額以下または設定金額未満の商品に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、設定された金額以下または設定された金額未満の商品に関する情報を取得することで、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。この場合、例えば、ユーザが購入する商品の金額が低い場合は、危険性は低いと考えられる。このため、端末のユーザの認証に関する情報を含めてコード情報を生成することで、安全性を確保しつつ、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記の商品に関する情報は、端末２０のユーザがＩＭＳマネーによって購入する商品の総額に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、端末のユーザが電子貨幣によって購入する商品の総額に関する情報を取得することで、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。この場合、例えば、端末のユーザが電子貨幣によって購入する商品の総額が低い場合は、危険性は低いと考えられる。このため、端末のユーザの認証に関する情報を含めてコード情報を生成することで、安全性を確保しつつ、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記のサーバ１０が取得する情報は、認証スキップ依頼情報（限定でなく、端末のユーザの認証に関する情報の生成を依頼する依頼情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、端末のユーザの認証に関する情報の生成を依頼する依頼情報を取得することで、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記のサーバ１０が取得する情報は、認証スキップ依頼情報（限定でなく、端末による電子貨幣の決済を行う店舗のサーバによって依頼された依頼情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、端末による電子貨幣の決済を行う店舗のサーバによって依頼された依頼情報を取得することで、店舗の意向に応じて、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザの認証に関する情報を端末で取得可能とすることができるため、ユーザの利便性を向上させることができる。
　また、第３実施形態は、上記の特別端末読み取り用コードを含める情報は、認証スキップ情報（限定でなく、端末のユーザの認証を端末がスキップするためのスキップ情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置は、端末のユーザの認証を端末がスキップするためのスキップ情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザの認証を端末にスキップさせることができる。
　また、第３実施形態は、上記の認証スキップ情報は、端末２０が認証スキップ情報を取得することで、端末２０による認証処理がスキップされる情報を含む構成を示している。
　このような構成により得られる効果の一例として、コード情報に含めたスキップ情報に基づいて、端末のユーザの認証を端末に簡易かつ確実にスキップさせることができる。
　また、第３実施形態は、サーバ１０が、特別端末読み取り用コード（限定でなく、コード情報の一例）を通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０に送信し、端末２０のアプリケーションコードリーダにより特別端末読み取り用コードが読み取られることに基づいて、端末２０から決済依頼情報を通信Ｉ／Ｆ１４によって受信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、送信したコード情報が端末のコードリーダに読み取られることに基づいて、端末による電子貨幣の決済に関する情報を受信して取得することができる。
　また、第３実施形態は、上記の認証パスワードとは異なる情報は、上記の特別端末読み取り用コードに関連付いた認証スキップ情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末のコードリーダに読み取られるコード情報に、認証情報とは異なる情報を関連付けることができる。
　また、第３実施形態は、上記の認証スキップ情報は、店舗コードリーダ装置５０によって生成された情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末のコードリーダに読み取られるコード情報に、商品を管理する店舗に基づき生成された情報を関連付けることができる。
　また、第３実施形態は、上記の認証スキップ情報は、店舗コードリーダ装置５０から送信される依頼情報に基づき生成される構成を示している。
　このような構成により得られる効果の一例として、サーバは、商品を管理する店舗による依頼に基づいて、コード情報に関連付ける情報を生成することができる。
＜第３変形例（１）＞
　第３実施形態では、サーバ１０が、認証スキップ情報を含む特別端末読み取り用コードを生成することとしたが、これに限定されない。限定でなく例として、サーバ１０が、端末２０のユーザの認証をスキップするために端末２０が利用する情報、つまり、端末２０が認証スキップ判定を行うために必要な情報を含めて、特別端末読み取り用コードを生成するようにすることもできる。
　具体的には、限定でなく例として、サーバ１０は、店舗の依頼に基づき、特別端末読み取り用コード生成処理において、端末２０のユーザがＩＭＳマネーによって購入する予定の商品の金額に関する情報、端末２０のユーザがＩＭＳマネーによって購入する予定の商品に関する情報、端末２０のユーザがＩＭＳマネーによる決済を行う地域（エリア）に関する情報、端末２０のユーザがＩＭＳマネーによって商品を購入する店舗に関する情報といった各種の情報を含めて、特別端末読み取り用コードを生成するようにすることもできる。
　例えば、店舗コードリーダ装置５０は、店舗の店員の操作に基づいて、端末２０のユーザが購入する予定の商品の金額やそれらの総額を、決済予定金額として特別端末読み取り用コード生成依頼情報に含めてサーバ１０に送信する。そして、サーバ１０は、店舗コードリーダ装置５０から受信した特別端末読み取り用コード生成依頼情報に含まれる決済予定金額を含めて、特別端末読み取り用コードを生成する。
　また、例えば、店舗コードリーダ装置５０は、店舗の店員の操作に基づいて、端末２０のユーザが購入する商品を識別するための商品識別情報やその商品種別を識別するための商品種別識別情報を、特別端末読み取り用コード生成依頼情報に含めてサーバ１０に送信する。そして、サーバ１０は、店舗コードリーダ装置５０から受信した特別端末読み取り用コード生成依頼情報に含まれる商品識別情報または商品種別識別情報を含めて、特別端末読み取り用コードを生成する。
　また、例えば、店舗コードリーダ装置５０は、自装置にあらかじめ記憶されている、自店舗の所在地のエリア情報や自店舗の店舗識別情報（店舗ＩＤ）等の情報を、特別端末読み取り用コード生成依頼情報に含めてサーバ１０に送信する。そして、サーバ１０は、店舗コードリーダ装置５０から受信した特別端末読み取り用コード生成依頼情報に含まれるエリア情報や店舗識別情報を含めて、特別端末読み取り用コードを生成する。
　このようにしてサーバ１０によって生成された特別端末読み取り用コードは、前述したように、店舗コードリーダ装置５０に送信されて表示され、端末２０によって読み取られる。端末２０は、読み取った特別端末読み取り用コードからデータをデコードすることで取得した各種の情報に基づいて、認証スキップ判定を行うようにすることができる。
　なお、端末２０の認証スキップの判定方法については、上述の実施形態および変形例の記載に基づき実行してもよいし、しなくてもよい。
＜第３変形例（１）の効果＞
　本変形例は、上記の特別端末読み取り用コードに含める情報は、端末２０のユーザの認証をスキップするために端末２０が利用する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末のユーザの認証をスキップするために端末が利用する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザの認証をスキップするために端末が利用する情報を端末で取得可能とすることができ、この情報に基づいて、ユーザの認証をスキップさせるか否かを端末で容易に判定可能とすることができる。
　また、本変形例は、上記の特別端末読み取り用コードに含める情報は、端末２０のユーザがＩＭＳマネーによって購入する商品に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、端末のユーザが電子貨幣によって購入する商品に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して端末のユーザが電子貨幣によって購入する商品に関する情報を端末で取得可能とすることができ、例えば、ユーザが購入する商品に基づいて、ユーザの認証をスキップさせるか否かを端末で容易に判定可能とすることができる。
　また、本変形例は、上記の端末２０のユーザがＩＭＳマネーによって購入する商品に関する情報は、端末２０のユーザがＩＭＳマネーによって購入する商品の金額に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、商品の金額に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して商品の金額に関する情報を端末で取得可能とすることができ、例えば、ユーザが購入する商品の金額に基づいて、ユーザの認証をスキップさせるか否かを端末で容易に判定可能とすることができる。
　また、本変形例は、上記の特別端末読み取り用コードに含める情報は、端末２０のユーザが決済を行う地域（エリア）に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、場所に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して場所に関する情報を端末で取得可能とすることができ、例えば、ユーザが決済を行うエリアや店舗の場所に基づいて、ユーザの認証をスキップさせるか否かを端末で容易に判定可能とすることができる。
　また、本変形例は、上記の特別端末読み取り用コードに含める情報は、端末２０のユーザが商品を購入する店舗に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、サーバは、商品を購入する店舗に関する情報を含めて、コード情報を生成することができる。また、生成したコード情報を介して商品を購入する店舗に関する情報を端末で取得可能とすることができ、例えば、ユーザが商品を購入する店舗に基づいて、ユーザの認証をスキップさせるか否かを端末で容易に判定可能とすることができる。
＜第３変形例（２）＞
　第３実施形態では、サーバ１０が、認証スキップ情報を含む特別端末読み取り用コードを生成することとしたが、これに限定されない。具体的には、限定でなく例として、端末２０が、決済種別「端末表示用コード」で用いられる端末表示用コードであって、認証スキップ情報を含む端末表示用コード（以下、「特別端末表示用コード」と称す。）を生成するようにすることもできる。
　図５－３、図５－４は、この場合における各装置の処理の流れの一例を示すフローチャートである。なお、既出のフローチャートと同一のステップについては同一の符号を付して、再度の説明を省略する。
　決済アプリケーション処理部２１３は、Ａ３において決済種別が「端末コード表示」であると判定したならば（Ａ３；端末コード表示）、第１の認証スキップ判定処理を行う（Ｈ３）。そして、決済アプリケーション処理部２１３は、Ａ１１～Ａ１７の処理を行う。
　Ａ１５において認証結果が「ＯＫ」であると判定した場合（Ａ１５；Ｙｅｓ）、または、Ａ１１において認証処理をスキップすると判定した場合（Ａ１１；Ｙｅｓ）、決済アプリケーション処理部２１３は、特別端末表示用コード生成処理を行う（Ｐ１５）。具体的には、限定でなく例として、端末２０で認証処理をスキップしたか否かの情報である認証スキップ状況情報を含む特別端末表示用コードを生成する。そして、決済アプリケーション処理部２１３は、生成した特別端末表示用コードを表示部２４に表示させる（Ｐ１９）。
　店舗決済処理部５１３は、端末２０の表示部２４に表示された特別端末表示用コードを、コードリーダ５８に読み取らせる（Ｑ９）。そして、店舗決済処理部５１３は、読み取った特別端末表示用コードに含まれる情報を取得するコード情報取得処理を行った後（Ｑ１１）、取得した情報を含む第２の決済依頼情報を通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｑ１３）。
　決済管理処理部１１３は、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から第２の決済依頼情報を受信すると（Ｒ９）、認証スキップ判定処理部１１３９が、第７の認証スキップ判定処理を行う（Ｒ１１）。なお、他の実施形態における認証スキップ判定処理と区別するため、便宜的に「第７の認証スキップ判定処理」と称する。
　この第７の認証スキップ判定処理では、認証スキップ判定処理部１１３９は、店舗コードリーダ装置５０から受信した第２の決済依頼情報に含まれる認証スキップ状況情報に基づいて、端末２０で認証処理がスキップされたか否かを判定する。
　端末２０で認証処理がスキップされなかった場合、認証スキップ判定処理部１１３９は、追加認証不要と判定する。これは、端末２０で既に認証処理が済んでいるためである。
　一方、端末２０で認証処理がスキップされた場合、認証スキップ判定処理部１１３９は、記憶部１５の認証スキップ条件データ１５６に含まれる認証スキップ条件に基づいて、認証スキップ条件の成否を判定する。そして、認証スキップ条件が成立する場合は、追加認証不要と判定し、認証スキップ条件が成立しない場合は、追加認証必要と判定する。これは、端末２０では認証処理がスキップされたが、サーバ１０による認証スキップ判定の結果によっては、端末２０に追加認証を行わせた方がよい場合があるためである。
　具体例として、例えば、端末２０側での認証スキップに関する設定と、サーバ１０側での認証スキップに関する設定との相違により、端末２０では決済予定金額が高額ではないため認証処理をスキップさせると判定されたが、サーバ１０では決済予定金額が高額であるため端末２０の認証処理をスキップさせることに問題あり（リスクあり）と判断され、端末２０の認証スキップを取り消して、追加認証を行わせるような場合が挙げられる。
　なお、上記とは異なり、端末２０で認証処理がスキップされた場合、サーバ１０は端末２０の判断を信頼することとして、追加認証不要と判定してもよい。この場合は、サーバ１０側で認証スキップ判定を行わずに済む。
　第７の認証スキップ判定処理で追加認証必要と判定された場合（Ｇ３；Ｎｏ）、決済管理処理部１１３は、通信Ｉ／Ｆ１４によって追加認証要求情報を端末２０に送信する（Ｇ５）。そして、決済管理処理部１１３は、通信Ｉ／Ｆ１４によって端末２０から認証成功情報を受信した後（Ｇ７）、決済処理を行う（Ｃ１１）。そして、決済管理処理部１１３は、Ｃ１３へと処理を移す。
　なお、上記の処理では、端末２０が、認証スキップ状況情報を含む特別端末表示用コードを生成することとしたが、これに限定されない。
　例えば、端末２０が、端末２０のユーザの認証をスキップさせるか否かを判定するためにサーバ１０が利用する情報、つまり、サーバ１０が認証スキップ判定を行うために必要な情報を含めて、特別端末表示用コードを生成するようにすることもできる。
　具体的には、限定でなく例として、端末２０は、特別端末表示用コード生成処理において、端末２０のユーザが購入する予定の商品の金額に関する情報、端末２０のユーザが購入する予定の商品に関する情報、端末２０のユーザが決済を行う地域（エリア）に関する情報、端末２０のユーザが商品を購入する店舗に関する情報、端末２０または決済アプリケーションの設定に関する情報、端末２０のＯＳ側のロック状況（ロックの有無）やロック設定（ＯＮ／ＯＦＦ）に関する情報、端末２０の決済アプリケーション側のロック状況（ロックの有無）やロック設定（ＯＮ／ＯＦＦ）に関する情報といった各種の情報を含めて、特別端末表示用コードを生成するようにすることもできる。
　例えば、端末２０は、ユーザ操作に基づいて、端末２０のユーザが購入する予定の商品の金額やそれらの総額を決済予定金額として含めて、特別端末表示用コードを生成する。
　また、例えば、端末２０は、ユーザ操作に基づいて、端末２０のユーザが購入する商品を識別するための商品識別情報やその商品種別を識別するための商品種別識別情報を含めて、特別端末表示用コードを生成する。
　また、例えば、端末２０は、算出位置履歴データ２８８に記憶されている最新の算出位置に基づき、自己の端末２０が位置しているエリアに関するエリア情報を含めて、特別端末表示用コードを生成したり、ユーザ操作に基づいて、端末２０のユーザが商品を購入する店舗の店舗識別情報（店舗ＩＤ）を含めて、特別端末表示用コードを生成する。
　また、例えば、端末２０は、自己の端末２０側の認証設定（ＯＮ／ＯＦＦ）の情報や、自己の端末２０の決済アプリケーション側の認証設定（ＯＮ／ＯＦＦ）の情報を含めて、特別端末表示用コードを生成する。
　また、例えば、端末２０は、自己の端末２０のＯＳ側のロック状況（ロックの有無）や決済アプリケーション側のロック状況（ロックの有無）、また、例えば、自己の端末２０のＯＳ側のロック設定（ＯＮ／ＯＦＦ）や決済アプリケーション側のロック設定（ＯＮ／ＯＦＦ）を含めて、特別端末表示用コードを生成する。
　このようにして端末２０によって生成された特別端末表示用コードは、前述したように、端末２０の表示部２４に表示され、店舗コードリーダ装置５０によって読み取られる。そして、読み取られた特別端末表示用コードからデータをデコードすることで取得された各種の情報を含む第２の決済依頼情報が、店舗コードリーダ装置５０からサーバ１０に送信される。そして、サーバ１０は、店舗コードリーダ装置５０から受信した第２の決済依頼情報に含まれる上記の各種の情報に基づいて、認証スキップ判定を行うようにすることができる。
　なお、サーバ１０の認証スキップの判定方法については、上述の実施形態および変形例に基づいて実行してもよいし、しなくてもよい。
＜第３変形例（２）の効果＞
　本変形例は、端末２０（限定でなく、情報処理装置の一例）が、端末２０によるＩＭＳマネー（限定でなく、電子貨幣の一例）の決済に関する特別端末表示用コード（限定でなく、コード情報の一例）を生成する。端末２０は、端末２０のユーザが購入する予定の商品の金額に関する情報、端末２０のユーザが購入する予定の商品に関する情報、端末２０のユーザが決済を行う地域（エリア）に関する情報、端末２０のユーザが商品を購入する店舗に関する情報、端末２０のロックの有無や端末２０の決済アプリケーションのロックの有無に関する情報等の情報（限定でなく、情報の一例）を取得する。そして、端末２０は、取得した情報に基づいて、端末２０で実行される認証処理に関する情報（限定でなく、端末のユーザの認証に関する情報の一例）を含めて、特別端末表示用コードを生成する構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、取得した情報に基づいて、端末のユーザの認証に関する情報を含めて、コード情報を簡単に生成することができる。また、生成したコード情報を介して端末のユーザの認証に関する情報を他の装置に提供することができる。
　また、本変形例は、端末２０が、上記の端末２０で実行される認証処理に関する情報を含めて、特別端末表示用コードを生成する構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、端末のユーザの認証に関する情報を含めて、コード情報を簡単に生成することができる。
　また、本変形例は、上記の特別端末表示用コードに含める情報は、認証スキップ状況情報（限定でなく、端末によって、端末のユーザが認証されたことを示す情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、端末によって、端末のユーザが認証されたことを示す情報を含めて、コード情報を生成することができる。
　また、本変形例は、上記の端末２０が取得する情報は、認証パスワード（限定でなく、端末のユーザを認証するための認証情報の一例）とは異なる情報を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、端末のユーザを認証するための認証情報とは異なる情報を含めて、コード情報を生成することができる。
　また、本変形例は、上記の認証パスワードとは異なる情報は、ＩＭＳマネーに関する情報（限定でなく、電子貨幣に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、電子貨幣に関する情報を含めて、コード情報を生成することができる。
　また、本変形例は、上記の認証パスワードとは異なる情報は、端末２０のユーザが決済を行う地域（エリア）に関する情報（限定でなく、場所に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、場所に関する情報を含めて、コード情報を生成することができる。例えば、場所に関する情報として、端末のユーザが決済を行う場所の情報を含めることで、生成したコード情報を介して端末のユーザが決済を行う場所の情報を他の装置に提供することができる。
　また、本変形例は、上記の認証パスワードとは異なる情報は、端末２０のユーザが購入する予定の商品に関する情報（限定でなく、商品に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、商品に関する情報を含めて、コード情報を生成することができる。
　また、本変形例は、上記の認証パスワードとは異なる情報は、端末２０側の認証設定（ＯＮ／ＯＦＦ）や決済アプリケーション側の認証設定（ＯＮ／ＯＦＦ）に関する情報（限定でなく、端末または、端末に記憶されたアプリケーションの設定に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、端末または、端末に記憶されたアプリケーションの設定に関する情報を含めて、コード情報を生成することができる。
　また、本変形例は、上記の認証パスワードとは異なる情報は、端末２０のロック状況、ロック設定に関する情報や、端末２０の決済アプリケーションのロック状況、ロック設定に関する情報（限定でなく、端末または、端末に記憶されたアプリケーションのセキュリティに関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、端末または、端末に記憶されたアプリケーションのセキュリティに関する情報を含めて、コード情報を生成することができる。
　また、本変形例は、上記の特別端末表示用コードに含める情報は、サーバ１０（限定でなく、電子貨幣の決済を管理するサーバの一例）に取得される構成を示している。
　このような構成により得られる効果の一例として、情報処理装置の一種である端末は、端末のユーザの認証に関する情報を、電子貨幣の決済を管理するサーバに提供することができる。
　また、本変形例は、サーバ１０は、特別端末表示用コードに含まれる情報に基づき、認証スキップ条件が成立する場合は、追加認証要求情報（限定でなく、端末のユーザの認証を端末により実行することに関する情報の一例）を、サーバ１０の通信Ｉ／Ｆ１４によって端末２０に送信せず、決済結果情報（限定でなく、電子貨幣による決済が行われたことを示す情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、電子貨幣の決済を管理するサーバは、端末のユーザの認証に関する情報に基づいて、端末のユーザの認証を端末により実行することに関する情報を、サーバの通信部によって端末に送信せずに、電子貨幣による決済が行われたことを示す決済情報を通信部によって端末に送信するため、サーバの処理負荷を軽減することができる。
＜第３変形例（３）＞
　第３実施形態で説明した特別端末読み取り用コードの生成は、店舗単位で行うようにすることができる他、＜第１変形例（１０）＞と同様に、店舗で販売される商品単位や商品種別単位で行うようにすることもできる。
　限定でなく例として、図３－３６で示した例と同様に、例えば店舗側で商品種別「弁当」、「飲料」について認証をスキップさせることを希望する場合は、店舗コードリーダ装置５０からサーバ１０に、店舗ＩＤと、商品種別（ここでは「弁当」、「飲料」）の識別情報と、その販売金額情報と、認証スキップ依頼情報とを含む特別端末読み取り用コード生成依頼情報を送信する。そして、サーバ１０は、店舗コードリーダ装置５０から特別端末読み取り用コード生成依頼情報を受信したことに基づいて、商品種別「弁当」、「飲料」について、認証スキップ情報を含む特別端末読み取り用コードを生成する。
　一方、図３－３６で示した例と同様に、例えば店舗側で商品種別「ギフト商品」については認証をスキップさせないことを希望する場合は、認証スキップ情報を含む特別端末読み取り用コードではなく、認証スキップ情報を含まない通常の端末読み取り用コードの生成を依頼する端末読み取り用コード生成依頼情報を送信する。そして、サーバ１０は、店舗コードリーダ装置５０から端末読み取り用コード生成依頼情報を受信したことに基づいて、商品種別「ギフト商品」について、認証スキップ情報を含まない端末読み取り用コードを生成する。
　また、＜第１変形例（１０）＞と同様に、１つの商品種別の中で、認証をスキップさせる商品と、認証をスキップさせない商品とを分類するようにすることもできる。前述したように、商品種別「弁当」を、販売金額「２００円」の弁当と、販売金額「３００円」の弁当と、販売金額「５００円」の弁当とに分類するような例である。そして、サーバ１０は、認証をスキップさせる商品については、認証スキップ情報を含む特別端末読み取り用コードを生成し、認証をスキップさせない商品については、認証スキップ情報を含まない通常の端末読み取り用コードを生成するようにする。
＜第３変形例（３）の効果＞
　本変形例により得られる効果の一例として、情報処理装置は、店舗で販売される商品単位や商品種別単位で、端末のユーザの認証に関する情報を含めて、コード情報を生成することができる。また、店舗で販売される商品や商品種別に応じて、端末のユーザの認証に関する情報をコード情報に含める場合と含めない場合とがあるため、店舗の意向に沿ったコード情報の生成を実現することができる。
＜第４実施形態＞
　第４実施形態は、限定でなく例として、端末２０のユーザが、決済アプリケーションを用いて、ＩＭＳアプリケーションにおいて友だちとして登録されているユーザの端末２０に、ＩＭＳマネーを送金する実施形態である。この際、ユーザに要求される送金用の認証を、特定の条件が成立する場合にスキップする。
　本実施形態における「認証」とは、特に断りのない限り、送金を行うために端末２０のユーザが正規のユーザであることを認証することを意味し、「認証処理」とは、この送金用の認証を実現するための処理を意味する。
　また、「認証スキップ条件」とは、特に断りのない限り、上記の送金用の認証処理をスキップする条件を意味し、「認証処理をスキップする」とは、認証処理の処理命令を無視して、次の命令を処理すること、つまり認証処理を省略することを意味する。
　第４実施形態に記載の内容は、他の各実施形態のいずれにも適用可能である。
＜機能構成＞
（１）サーバの機能構成
　図６－１は、本実施形態におけるサーバ１０の制御部１１により実現される機能の一例を示す図である。
　決済管理処理部１１３は、サーバメイン処理部１１１と、ＩＭＳ処理部１１２とに加えて、送金管理処理部１１５を機能部として含む。
　送金管理処理部１１５は、記憶部１５に記憶されている送金管理処理プログラム１５１７に従って、ＩＭＳアプリケーションにおいて友だち登録されている他のユーザの端末２０へのＩＭＳマネーの送金や、この他のユーザの端末２０からの着金を管理するための処理である送金管理処理を実行する機能を有している。
　送金管理処理部１１５は、限定でなく例として、送金処理部１１５１と、送金元用送金結果情報送信処理部１１５３と、着金側用着金結果情報送信処理部１１５５とを機能部として含む。
　送金処理部１１５１は、第１の端末２０から送信される送金依頼情報に基づいて、この第１の端末２０のユーザが所有するＩＭＳマネーを、第２の端末２０に送信する処理である送金処理を実行する機能を有している。
　送金元用送金結果情報送信処理部１１５３は、ＩＭＳマネーの送金元である第１の端末２０に対して、送金結果に関する情報である送金結果情報を送信する機能を有している。
　着金側用着金結果情報送信処理部１１５５は、ＩＭＳマネーの着金側である第２の端末２０に対して、着金結果に関する情報である着金結果情報を送信する機能を有している。
　図６－２は、本実施形態におけるサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
　サーバメイン処理プログラム１５１は、ＩＭＳ処理プログラム１５１２に加えて、送金管理処理として実行される送金管理処理プログラム１５１７をサブルーチンプログラムとして含む。
　また、記憶部１５には、ユーザ登録データ１５３と、店舗登録データ１５５とに加えて、ＩＭＳユーザ管理データベース１６１と、ＩＭＳグループ管理データベース１６３と、送金着金管理データベース１６５とが記憶される。
　本実施形態では、ユーザ登録データ１５３に記憶されて登録されているユーザ情報は、ＩＭＳアプリケーションと決済アプリケーションとで共有されるユーザ情報であるものとして説明する。
　ＩＭＳユーザ管理データベース１６１は、ユーザ登録データ１５３に登録されているユーザのＩＭＳの利用に関するデータを管理するためのデータベースであり、そのデータ構成の一例を図６－３に示す。
　ＩＭＳユーザ管理データベース１６１には、複数のユーザそれぞれについて、個別のＩＭＳユーザ管理データが記憶される。
　各ユーザのＩＭＳユーザ管理データには、限定でなく例として、ユーザ名およびユーザＩＤと関連付けて、ユーザコンテンツ履歴データが記憶される。
　ユーザコンテンツ履歴データは、このユーザの端末２０と他のユーザの端末２０との間で送受信されたコンテンツの履歴に関するデータであり、限定でなく例として、このユーザのトークルームで送受信されたコンテンツと、コンテンツが送受信された日時と、コンテンツを識別するための識別情報であるコンテンツ番号とを関連付けたデータが履歴として記憶される。
　ＩＭＳグループ管理データベース１６３は、ユーザ登録データ１５３に登録されている複数のユーザで構成されるグループのＩＭＳの利用に関するデータを管理するためのデータベースであり、そのデータ構成の一例を図６－４に示す。
　ＩＭＳグループ管理データベース１６３には、複数のグループそれぞれについて、個別のＩＭＳグループ管理データが記憶される。
　各グループのＩＭＳグループ管理データには、限定でなく例として、このグループの名称であるグループ名と、グループＩＤと、グループ作成日時と、グループ人数と、グループユーザデータと、グループコンテンツ履歴データとが記憶される。
　グループＩＤは、このグループを識別するための識別情報として機能するＩＤであり、各グループそれぞれを固有に識別するためのＩＤが記憶されて登録される。
　グループ作成日時は、このグループが作成された日時である。限定でなく例として、グループは、ＩＭＳを利用するユーザが任意に作成することができ、グループを作成したユーザまたはグループに加入済みのユーザが、他のユーザをグループに招待することで、他のユーザをグループに加入させることができる。
　グループ人数には、このグループに含まれるユーザの合計人数が記憶される。新たなユーザがグループに加入するごとに、グループ人数が加算更新され、加入済みのユーザがグループから脱退するごとに、グループ人数が減算更新される。
　グループユーザデータには、限定でなく例として、このグループに含まれるユーザ（以下、「グループユーザ」と称す。）のユーザ名と、このグループユーザのユーザＩＤと、このグループユーザがこのグループに加入した日時であるグループ加入日時とが関連付けて記憶される。
　グループコンテンツ履歴データは、このグループに含まれるグループユーザの端末２０間で送受信されたコンテンツの履歴に関するデータであり、限定でなく例として、このグループのトークルームで送受信されたコンテンツと、コンテンツが送受信された日時と、コンテンツを識別するためのコンテンツ番号とを関連付けたデータが履歴として記憶される。
　送金着金管理データベース１６５は、送金・着金に関するデータを管理するためのデータベースであり、そのデータ構成の一例を図６－５に示す。
　送金着金管理データベース１６５には、複数のユーザそれぞれについて、個別の送金着金管理データが記憶される。
　各ユーザの送金着金管理データには、ユーザＩＤと、残高と、ＩＭＳポイントと、１日上限設定金額と、オートチャージ設定と、送金履歴データと、着金履歴データとが記憶される。
　送金履歴データは、このユーザＩＤのユーザからの送金に関する履歴データであり、限定でなく例として、送金した日時である送金日時と、送金先のユーザのユーザＩＤである送金先ユーザＩＤと、送金した金額である送金金額とが関連付けて記憶される。
　着金履歴データは、このユーザＩＤのユーザへの着金に関する履歴データであり、限定でなく例として、着金した日時である着金日時と、送金元のユーザのユーザＩＤである送金元ユーザＩＤと、着金した金額である着金金額とが関連付けて記憶される。
　本実施形態では、サーバ１０は、決済アプリケーションの送金機能（送金する）に基づく送金処理を行う。具体的には、限定でなく例として、サーバ１０は、一のユーザの端末２０から送信される送金依頼情報を受信したことに基づいて、一のユーザとＩＭＳアプリケーションにおいて友だち登録されている他のユーザの端末２０に、ＩＭＳマネーを送金する処理を行う。
　また、サーバ１０は、決済アプリケーションの送金要求機能（送金してもらう）に基づく送金要求処理を行う。具体的には、限定でなく例として、サーバ１０は、一のユーザの端末２０から送信される送金要求依頼情報を受信したことに基づいて、一のユーザとＩＭＳアプリケーションにおいて友だち登録されている他のユーザの端末２０に、一のユーザの端末２０への送金を要求する処理を行う。
　また、送金要求処理には、決済アプリケーションの割り勘機能に基づく割り勘要求処理が含まれる。割り勘要求処理とは、一のユーザの端末２０から割り勘要求依頼情報を受信したことに基づいて、一のユーザとＩＭＳアプリケーションにおいて友だち登録されている他の複数のユーザの端末２０に、または、ＩＭＳアプリケーションにおいて一のユーザと同じグループに含まれる他の複数のユーザの端末２０に、一のユーザによって指定された金額を総人数で均等に割った金額を要求する処理である。割り勘機能は、ＩＭＳアプリケーションにおいて友だち登録されているユーザ同士や、ＩＭＳアプリケーションにおいてグループ形成されているユーザ同士で、例えば食事会や飲み会を行うような場合に、幹事である一のユーザが他の複数のユーザに、合計金額を参加総人数で均等に割った金額を請求する際に利用される。
（２）端末の機能構成
　図６－６は、本実施形態における端末２０の制御部２１により実現される機能の一例を示す図である。
　決済アプリケーション処理部２１３は、認証スキップ判定処理部２１３５と、認証処理部２１３７とに加えて、送金依頼処理部２１３８を機能部として含む。
　送金依頼処理部２１３８は、ＩＭＳアプリケーションにおいて友だち登録されている他の端末２０または、他の端末２０へのユーザへの送金を、サーバ１０に依頼する処理を実行する機能を有している。
　図６－７は、本実施形態における端末２０の記憶部２８に記憶される情報の一例を示す図である。
　ＩＭＳアプリケーション２８２は、限定でなく例として、ＩＭＳアプリケーション処理として実行されるＩＭＳアプリケーション処理プログラム２８２１と、ＩＭＳアプリケーションデータ２８２３とを含む。
　ＩＭＳアプリケーションデータ２８２３は、限定でなく例として、友だちデータ２８２５と、グループデータ２８２６と、ユーザコンテンツ履歴データ２８２７と、グループコンテンツ履歴データ２８２８とを含む。
　友だちデータ２８２５は、自己の端末２０のユーザが友だち登録しているユーザに関するデータであり、限定でなく例として、友だち登録しているユーザのユーザ名、ユーザＩＤ、アイコン画像、プロフィール等の情報が記憶される。
　グループデータ２８２６は、自己の端末２０のユーザが加入しているグループに関するデータであり、限定でなく例として、自己の端末２０のユーザが加入しているグループのグループ名、グループＩＤ、同じグループに含まれる他のグループユーザのユーザ名、ユーザＩＤ、アイコン画像、プロフィール等の情報が記憶される。
　ユーザコンテンツ履歴データ２８２７は、自己の端末２０と、友だち登録されている他のユーザの端末２０との間で送受信されたコンテンツの履歴に関するデータであり、限定でなく例として、このユーザのトークルームで送受信されたコンテンツと、コンテンツが送受信された日時と、コンテンツを識別するための識別情報であるコンテンツ番号とを関連付けたデータが履歴として記憶される。
　グループコンテンツ履歴データ２８２８は、自己の端末２０のユーザが加入しているグループに含まれるグループユーザの端末２０間で送受信されたコンテンツの履歴に関するデータであり、限定でなく例として、このグループのトークルームで送受信されたコンテンツと、コンテンツが送受信された日時と、コンテンツを識別するためのコンテンツ番号とを関連付けたデータが履歴として記憶される。
　決済アプリケーションプログラム２８４は、前述した実施形態と同様に、認証スキップ判定処理プログラム２８４５と、認証処理プログラム２８４７とをサブルーチンプログラムとして含む。
　また、決済アプリケーションデータ２８５は、限定でなく例として、店舗データ２８５５に加えて、認証スキップ条件データ２８５６と、送金着金用データ２８５７と、位置エリア登録データ２８５８とを含む。
　位置エリア登録データ２８５８には、制御部２１によって、算出位置履歴データ２８８に記憶されている自己の端末２０の算出位置の履歴に基づいて、各種の位置やエリアに関する情報が記憶される。
　位置エリア登録データ２８５８には、例えば、自己の端末２０のユーザの自宅の位置の位置情報が登録される。制御部２１は、限定でなく例として、算出位置履歴データ２８８において、平日の２２時から翌日の朝６時までの時間帯に統計的に最も多く記憶されている算出位置に対応する位置情報を、自己の端末２０のユーザの自宅の位置情報として登録する。
　また、位置エリア登録データ２８５８には、例えば、自己の端末２０のユーザが勤めている会社（勤務先）の位置情報が登録される。制御部２１は、限定でなく例として、算出位置履歴データ２８８において、平日の９時から１７時までの時間帯に統計的に最も多く記憶されている算出位置に対応する位置情報を、自己の端末２０のユーザの会社（勤務先）の位置情報として登録する。
　また、位置エリア登録データ２８５８には、例えば、サーバ１０によってあらかじめ設定されるエリアであって、送金を行うことが安全なエリアである送金安全エリアの位置情報が登録されている。サーバ１０は、限定でなく例として、都心部から離れた地方や田舎のエリアの位置情報を、送金安全エリアの位置情報としてあらかじめ設定しておくことができる。
　また、自己の端末２０のユーザが頻繁に訪れる場所、例えば自己の端末２０のユーザが設定回数以上訪れた場所の位置情報を、送金安全エリアとして登録するようにすることもできる。この場合、制御部２１は、限定でなく例として、上記の自宅や会社（勤務先）に加えて、算出位置履歴データ２８８において、設定頻度以上の頻度で発生している算出位置や、設定回数以上の回数で発生している算出位置を、自己の端末２０のユーザが頻繁に訪れる場所として、それらの位置情報を送金安全エリアに含めて登録することができる。
　また、位置エリア登録データ２８５８には、自己の端末２０のユーザが自身で位置やエリアを登録するようにすることもできる。例えば、自己の端末２０のユーザが、自身の関係者（例えば親族や親しい友人、会社関係の人）の自宅の位置情報等を登録するようにすることもできる。
　図６－８は、本実施形態における認証スキップ条件データ２８５６のデータ構成の一例を示す図である。
　この認証スキップ条件データ２８５６には、限定でなく例として、条件カテゴリＮｏと、条件Ｎｏと、認証スキップ条件と、重要度（優先度）とが関連付けて記憶されている。
＜条件カテゴリＮｏ「ＳＰ１１」＞
　条件カテゴリＮｏ「ＳＰ１１」は「時間」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ１１－１」、「ＳＰ１１－２」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ１１－１」の認証スキップ条件として、「現在日時が最終送金日時から設定時間内」が定められている。これは、現在日時が最終送金日時から設定時間内であるということは、それほど時間が経過しない間に再び送金を行うことになるため、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、限定でなく例として、端末２０が、時計部２９Ａで計時している計時時刻に基づく現在日時と、送金着金用データ２８５７の送金履歴データに記憶されている最終送金日時とを取得して、現在日時が最終送金日時から設定時間内であるか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ１－２」の認証スキップ条件として、「現在時刻が設定時間帯に含まれる」が定められている。設定時間帯は、限定でなく例として、端末２０のユーザがあらかじめ設定しておくようにすることができる。具体的には、例えば、端末２０のユーザが、自身が頻繁に送金を行う時間帯や、送金が行われやすい時間帯（例えば食事の時間帯）を設定時間帯として設定しておくことで、設定時間帯に送金を行う場合に認証を省略することができる。
　この認証スキップ条件の判定では、限定でなく例として、端末２０が、時計部２９Ａで計時している計時時刻に基づく現在時刻を取得して、現在時刻が設定時間帯に含まれるか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ１２」＞
　条件カテゴリＮｏ「ＳＰ１２」は「端末・場所」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ１２－１」～「ＳＰ１２－４」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ１２－１」の認証スキップ条件として、「自端末の位置と自宅の位置とが離れていない」が定められている。これは、自己の端末２０の位置が、自己の端末２０のユーザの自宅の位置から離れていない場合は、送金は安全である（送金を行うことに問題はない）と推定されるため、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、算出位置履歴データ２８８に記憶されている最新の算出位置と、位置エリア登録データ２８５８に登録されている自宅の位置とを取得して、自己の端末２０の算出位置と自宅の位置との間の距離が設定距離以下（または設定距離未満）であるか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ１２－２」の認証スキップ条件として、「自端末の位置が送金安全エリアに含まれる」が定められている。これは、自己の端末２０の位置が送金安全エリアに含まれる場合は、送金は安全である（送金を行うことに問題はない）と推定されるため、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、算出位置履歴データ２８８に記憶されている最新の算出位置と、位置エリア登録データ２８５８に登録されている送金安全エリアとを取得して、自己の端末２０の算出位置が送金安全エリアに含まれるか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ１２－３」の認証スキップ条件として、「自端末の位置と決済アプリケーション対応店舗の位置とが離れていない」が定められている。これは、自己の端末２０の位置が決済アプリケーションを用いた決済に対応可能な店舗（加盟店舗）の位置から離れていない場合は、送金を行う必要性がある場合であると推定されるため、ユーザの利便性向上のため、認証を省略することを意味する。例えば、端末２０のユーザが仲間同士で、決済アプリケーション対応店舗で飲食等を行った後、決済アプリケーションを利用して決済を行うような場合がある。この場合、決済アプリケーションに割り勘処理を行う機能が備えられている場合は、仲間同士で割り勘を行う可能性が高い。このため、自己の端末２０の位置と決済アプリケーション対応店舗の位置とが離れていない場合は、割り勘の実施を促進させるなどの目的で、認証をスキップさせることができる。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、算出位置履歴データ２８８に記憶されている最新の算出位置と、店舗データ２８５５に記憶されている加盟店舗の位置とを取得して、自己の端末２０の算出位置と加盟店舗の位置との間の距離が設定距離以下（または設定距離未満）であるか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ１２－４」の認証スキップ条件として、「自端末の位置と割り勘要求を送信した端末の位置とが離れていない」が定められている。これは、自己の端末２０の位置が、割り勘要求を送信した端末の位置から離れていない場合は、他の端末２０のユーザから割り勘要求を受けた自己の端末２０のユーザがすぐに送金を行う場合であると推定されるため、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、算出位置履歴データ２８８に記憶されている最新の算出位置を取得するとともに、割り勘要求を送信した端末２０の位置をサーバ１０に要求して、割り勘要求を送信した端末２０の位置をサーバ１０から受信して取得する。そして、自己の端末２０の算出位置と割り勘要求を送信した端末２０の位置との間の距離が設定距離以下（または設定距離未満）であるか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ１３」＞
　条件カテゴリＮｏ「ＳＰ１３」は「金額」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ１３－１」～「ＳＰ１３－４」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ１３－１」の認証スキップ条件として、「１日上限設定金額を超えていない」が定められている。
　「１日上限設定金額」は、その１日で既に送金された送金金額（送金済みの金額）の合計金額に対する閾値とされる上限の設定金額である。つまり、その１日で既に送金された送金金額の合計金額が１日上限設定金額を超えていない場合は、ユーザの利便性向上のため、認証を省略することを意味する。
　また、逆に、その１日で既に送金された送金金額の合計金額が１日上限設定金額を超えている場合は、認証を行うようにすることで、送金を行い過ぎていることを端末２０のユーザに報知することができ、使い過ぎを防止できる。また、未成年者や子供が送金を行う場合に、保護者が利用に制限をかけるようにすることができる。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、送金着金用データ２８５７に記憶されている１日上限設定金額と、送金履歴データから特定されるその１日の送金金額の合計金額とを取得して、合計金額が１日上限設定金額を超えているか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ１３－２」の認証スキップ条件として、「残高が設定金額以下（または設定金額未満）＆オートチャージ設定ＯＦＦ」が定められている。設定金額は、限定でなく例として、端末２０のユーザがあらかじめ設定しておくようにすることができる。これは、残高が設定された金額以下であり、かつ、オートチャージ設定が「ＯＦＦ」であれば、ユーザは高額の送金を行うことができず、危険性は低いと考えられるため、ユーザの利便性向上のため、認証を省略する。
　しかしながら、オートチャージ設定が「ＯＮ」であれば、ＩＭＳマネーが自動的に補充されるため、ユーザは高額の送金を行うことが可能となり、リスクが生ずる。そこで、残高が設定金額以下（または設定金額未満）であることに加えて、オートチャージ設定が「ＯＦＦ」であることを、認証スキップの条件とする。
　なお、この場合、オートチャージ設定が「ＯＮ」であれば、残高が設定金額以下（または設定金額未満）であっても、原則的には認証処理がスキップされないことになる。しかしながら、上記のようにユーザの利便性向上を考え、オートチャージ設定が「ＯＮ」であっても、認証処理をスキップさせるようにすることもできる。この場合、限定でなく例として、上記の条件Ｎｏ「ＳＰ１３－２」の認証スキップ条件からオートチャージ設定ＯＦＦを除外して、「残高が設定金額以下（または設定金額未満）」とすればよい。つまり、オートチャージ設定が「ＯＮ」であっても、必ずしも認証処理を必須としなければならないわけではなく、あくまでもオートチャージが「ＯＮ」の場合、残高が設定金額以下（または設定金額未満）であれば、認証処理を行う場合があってもよいし、認証処理を行わない場合があってもよい。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、送金着金用データ２８５７に記憶されている残高およびオートチャージ設定を取得して、残高が設定金額以下（または設定金額未満）であり、かつ、オートチャージ設定が「ＯＦＦ」であるか否かを判定するようにすることができる。
　条件Ｎｏ「ＳＰ１３－３」の認証スキップ条件として、「ひと月あたりの送金頻度または送金金額の適正範囲内」が定められている。例えば、過去所定期間（過去６か月間や過去１年間）における、ひと月あたりの送金頻度の平均値や最大値、最頻値を閾値頻度とし、同じく過去所定期間における、ひと月あたりの送金金額の平均値や最大値、最頻値を閾値金額として算出する。そして、これから送金を行うことで、送金頻度が閾値頻度を超える場合または送金金額が閾値金額を超える場合は、認証を行うこととし、それ以外の場合は、認証を省略する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、送金着金用データ２８５７に記憶されている送金履歴データから算出される送金頻度および送金金額と、記憶部２８に記憶されている閾値頻度および閾値金額とを取得して、送金頻度が閾値頻度を超えるか否か、送金金額が閾値金額を超えるか否かを判定するようにすることができる。
　なお、上記の認証スキップ条件を、ＩＭＳマネーの送金を行った頻度（送金頻度）に基づく条件ではなく、ＩＭＳマネーの送金を行った回数（送金回数）に基づく条件としてもよいし、しなくてもよい。また、送金頻度が適正範囲内であること、送金回数が適正範囲内であること、送金金額が適正範囲内であること、をそれぞれ個別の条件として定めておくようにしてもよいし、しなくてもよい。
　条件Ｎｏ「ＳＰ３－４」の認証スキップ条件として、「送金予定金額が設定金額以下（または設定金額未満）」が定められている。設定金額は、例えば１万円や２万円といった、それほど高額ではない金額として設定しておくことができる。
　「送金予定金額」とは、これから送金を行う予定の金額（送金前の未確定の状態の金額）を意味する。つまり、これから送金を行う金額がそれほど高額でない場合は、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、端末２０のユーザにより入力された金額を送金予定金額として取得して、この送金予定金額が設定金額以下（または設定金額未満）であるか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ１４」＞
　条件カテゴリＮｏ「ＳＰ１４」は「送金相手」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ１４－１」～「ＳＰ１４－３」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ１４－１」の認証スキップ条件として、「送金予定相手が親しい友人または親族」が定められている。これは、送金を予定している相手が、端末２０のユーザの親しい友人や親族である場合は、送金を行うことに合理的な理由があるため、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、ＩＭＳアプリケーション２８２の友だちデータ２８２５と、ユーザコンテンツ履歴データ２８２７とに基づいて、友だち登録されているユーザであり、かつ、コンテンツの送受信の頻度が閾値頻度を超えている、または、コンテンツの送受信の回数が閾値回数を超えているユーザを、端末２０のユーザの親しい友人と判定する。また、ＩＭＳアプリケーション２８２のグループデータ２８２６を参照して、グループ名に「家族」、「ファミリー」、「親族」、「親戚」等の文字が含まれるグループを特定し、そのグループに含まれるグループユーザを親族と判定する。そして、送金予定相手がこれらのユーザである場合は、この認証スキップ条件を満たすと判定する。
　条件Ｎｏ「ＳＰ１４－２」の認証スキップ条件として、「送金予定相手に過去に送金履歴あり」が定められている。これは、送金を予定している相手に過去に送金したことがある場合は、お金の貸し借りがある相手であると推定されるため、ユーザの利便性向上のため、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、送金着金用データ２８５７に記憶されている送金履歴データを参照して、送金予定相手に過去に１回以上送金したことがあるかを判定し、送金したことがあると判定した場合は、この認証スキップ条件を満たすと判定する。
　条件Ｎｏ「ＳＰ１４－３」の認証スキップ条件として、「送金予定相手から過去に着金履歴あり」が定められている。これは、送金を予定している相手から過去に着金したことがある場合は、お金の貸し借りがある相手であると推定されるため、ユーザの利便性向上のため、認証を省略することを意味する。
　＜条件カテゴリＮｏ「ＳＰ１５」＞
　条件カテゴリＮｏ「ＳＰ１５」は「セキュリティ」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ１５－１」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ１５－１」の認証スキップ条件として、「端末ロック中、または、決済アプリケーションロック中」が定められている。これは、端末２０自体にロックがかかっている状態や、決済アプリケーションにロックがかかっている状態では、これらのロック状態を解除するために、端末ロック解除パスワードや決済アプリケーションロック解除パスワードの入力等の認証が必要となるため、ユーザの利便性向上のため、再度の認証を不要とすることを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、端末データ２８６に記憶されている自己の端末２０のロックの有無の情報と、決済アプリケーションデータ２８５に記憶されている決済アプリケーションのロックの有無の情報とを取得して、端末ロック中、または、決済アプリケーションロック中であるか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ１６」＞
　条件カテゴリＮｏ「ＳＰ１６」は「認証設定」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ１６－１」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ１６－１」の認証スキップ条件として、「端末側の認証設定ＯＦＦ、または、決済アプリケーション側の認証設定ＯＦＦ」が定められている。
　端末側の認証とは、端末ロック解除用の認証やユーザの本人認証といった端末２０側でユーザに要求される認証を意味する。
　それに対し、決済アプリケーション側の認証とは、決済アプリケーションを利用して送金を行う際にユーザに要求される認証を意味する。
　これは、端末２０側で、端末ロック解除用の認証やユーザの本人認証といった端末２０側でユーザに要求される認証を実行しない設定がなされている場合（設定ＯＦＦ）、または、決済アプリケーション側で、決済アプリケーションを利用して送金を行う際にユーザに要求される認証を実行しない設定がなされている場合（設定ＯＦＦ）は、認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、端末データ２８６に記憶されている端末側の認証設定と、送金着金用データ２８５７の認証スキップ条件ユーザ設定データに記憶されている条件Ｎｏ「ＳＰ１６－１」の条件別設定フラグとを取得して、端末側の認証設定と、決済アプリケーション側の認証設定との少なくともいずれかが「ＯＦＦ」であるか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ１７」＞
　条件カテゴリＮｏ「ＳＰ１７」は「状況判断」のカテゴリであり、限定でなく例として、条件Ｎｏ「ＳＰ１７－１」の認証スキップ条件がこれに含まれる。
　条件Ｎｏ「ＳＰ１７－１」の認証スキップ条件として、「同時に割り勘要求を受けた端末があり、設定数以上の端末で認証完了」が定められている。
　これは、他の端末２０から自己の端末２０を含む複数の端末２０に同時に割り勘要求を受けた場合に、自己の端末２０以外の他の端末２０のうちの設定数以上の端末２０で送金のための認証が完了した場合は、自己の端末２０の認証を省略することを意味する。
　この認証スキップ条件の判定では、端末２０は、限定でなく例として、同じ割り勘要求を受けた他の端末２０の認証状況の情報をサーバ１０に問い合わせて、サーバ１０から他の端末２０の認証状況の情報を取得し、設定数以上の端末２０で認証が完了しているか否かを判定するようにすることができる。
　また、上記の認証スキップ条件それぞれに関連付けて重要度（優先度）が定められている。具体的には、限定でなく例として、条件Ｎｏ「ＳＰ１２－１」～「ＳＰ１２－４」（条件カテゴリＮｏ「ＳＰ１２」）の認証スキップ条件と、条件Ｎｏ「ＳＰ１４－１」～「ＳＰ１４－３」（条件カテゴリＮｏ「ＳＰ１４」）の認証スキップ条件と、条件Ｎｏ「ＳＰ１６－１」の認証スキップ条件には、それぞれ重要度「Ａ」が定められている。
　また、限定でなく例として、条件Ｎｏ「ＳＰ１１－１」と、条件Ｎｏ「ＳＰ１３－１」、「ＳＰ１３－２」、「ＳＰ１３－４」の認証スキップ条件と、条件Ｎｏ「ＳＰ１５－１」の認証スキップ条件と、条件Ｎｏ「ＳＰ１７－１」の認証スキップ条件とには、それぞれ重要度「Ｂ」が定められている。
　また、限定でなく例として、条件Ｎｏ「ＳＰ１１－２」、「ＳＰ１３－３」の認証スキップ条件には、重要度「Ｃ」が定められている。
　なお、本実施形態では、認証スキップ条件に関連付けて重要度が設定されているが、この重要度の設定は必須の要件ではなく、重要度は設定されていなくてもよい。つまり、上記の認証スキップ条件データ２８５６において重要度の欄は設けられていなくてもよい。
　この場合は、認証スキップ判定処理において、限定でなく例として、任意の順序で認証スキップ条件の成否を判定していき、いずれかの認証スキップ条件が成立する場合に、認証処理をスキップさせると判定するようにすればよい。
　図６－９は、送金着金用データ２８５７のデータ構成の一例を示す図である。
　送金着金用データ２８５７には、限定でなく例として、決済アプリケーションのユーザＩＤと、認証を行うためのパスワードである認証パスワードと、決済アプリケーションのロック状態を解除するためのパスワードである決済アプリケーションロック解除パスワードと、ＩＭＳポイントと、残高と、１日上限設定金額と、オートチャージ設定と、送金履歴データと、着金履歴データと、認証スキップ条件設定と、認証スキップ条件ユーザ設定データとが記憶される。
　送金履歴データおよび着金履歴データ以外のデータは、前述した実施形態と同様であるため、再度の説明を省略する。
　送金履歴データは、このユーザＩＤのユーザの送金の履歴に関するデータであり、限定でなく例として、このユーザＩＤのユーザについて、送金した日時である送金日時と、送金先のユーザのユーザＩＤである送金先ユーザＩＤと、送金した金額である送金金額とが関連付けて記憶される。
　着金履歴データは、このユーザＩＤのユーザの着金の履歴に関するデータであり、限定でなく例として、このユーザＩＤのユーザについて、着金した日時である着金日時と、送金元のユーザのユーザＩＤである送金元ユーザＩＤと、着金した金額である着金金額とが関連付けて時系列に記憶される。
＜送金方法＞
　端末２０の表示部２４に表示される表示画面例を参照して、本実施形態における決済アプリケーションを利用した送金方法について説明する。
（１）通常の送金
　図６－１０～図６－１５は、通常の送金を行う場合における認証スキップなしの場合の送金の流れを説明するための画面図である。
　図６－１０は、端末２０の表示部２４に表示されるＩＭＳアプリケーションにおけるトークルーム画面の一例を示す図である。
　このトークルーム画面は、限定でなく例として、自己の端末２０のユーザである「ユーザＡ．Ａ」が、友だち登録されている他の端末２０のユーザである「ユーザＢ．Ｂ」とトークを行うためのトークルーム画面を示している。トークルーム画面の下部には、ＩＭＳアプリケーションと連動する決済アプリケーションの機能として、「送金」と示された「送金用アイコン」が表示されている。
　図６－１１は、上記のトークルーム画面において端末２０のユーザにより「送金用アイコン」がタッチされた場合に表示される画面の一例を示す図である。
　この画面では、トークルーム画面の画面中央部に「送金する」と示された「送金アイコン」と、「送金してもらう」と示された「送金要求アイコン」とがポップアップ形式で表示されている。
　送金アイコンは、「ユーザＡ．Ａ」が「ユーザＢ．Ｂ」に送金を行う場合に使用されるアイコンである。それに対し、送金要求アイコンは、「ユーザＡ．Ａ」が「ユーザＢ．Ｂ」に送金を要求する場合に使用されるアイコンである。
　図６－１２は、上記の画面において端末２０のユーザにより「送金アイコン」がタッチされた場合に表示される送金用画面の一例を示す図である。
　この送金用画面には、送金予定相手である「ユーザＢ．Ｂ」のユーザ名およびアイコン画像が表示され、その下に、残高とともに、入力された送金予定金額を表示するための送金予定金額表示欄が表示されている。ここでは、送金予定金額として「３０００円」が入力されて表示されている。また、画面下部には、次の画面に進むための「次へ」と示された「次へアイコン」が表示されている。
　図６－１３は、上記の送金用画面において端末２０のユーザにより「次へアイコン」がタッチされた場合に表示される送金実行画面の一例を示す図である。
　この送金実行画面には、送金予定相手である「ユーザＢ．Ｂ」のユーザ名およびアイコン画像に関連付けて送金予定金額（ここでは「３０００円」）が表示され、その下に、入力された送金予定相手へのメッセージを表示するためのメッセージ表示欄が表示されている。また、その下には、メッセージとともに送金予定相手に送る添付画像の候補が表示されている。そして、画面下部には、送金を実行するための「送金実行アイコン」が表示されている。
　図６－１４は、上記の送金実行画面において端末２０のユーザにより「送金実行アイコン」がタッチされた場合に表示される認証画面の一例を示す図である。
　認証スキップ判定処理で認証処理をスキップする判定がなされなかった場合は、この認証画面が表示される。
　この認証画面には、「パスワード」（認証パスワード）という文字とともに、「現在使用中のパスワードを入力してください。」というメッセージが表示され、その下に、入力されたパスワードが表示されるパスワード表示欄と、パスワードを入力するためのキーボードとが表示されている。
　図６－１５は、上記の認証画面でのパスワード入力に基づく認証処理で認証結果が「ＯＫ」となった場合に表示される送金完了画面の一例を示す図である。
　この送金完了画面には、画面中央部に、「送金完了」の文字とともに、「「送金履歴」から詳細が確認できます。」というメッセージと、送金履歴を確認するための「確認アイコン」とがポップアップ形式で表示されている。
　図６－１６、図６－１７は、認証スキップありの場合の送金の流れを説明するための画面図である。
　図６－１６には図６－１３と同じ送金実行画面を示しており、図６－１７には図６－１５と同じ送金完了画面を示している。
　図６－１６の送金実行画面において「送金実行アイコン」が端末２０のユーザによってタッチされた場合、認証スキップ判定処理で認証処理をスキップする判定がなされた場合は、図６－１７の送金完了画面に表示が切り替わる。つまり、図６－１４の認証画面が表示されることなく、送金実行画面から送金完了画面に表示が切り替わることになる。
（２）割り勘要求を受けた場合の送金
　図６－１８は、端末２０の表示部２４に表示されるＩＭＳアプリケーションにおけるグループトークルーム画面の一例を示す図である。
　このグループトークルーム画面は、グループに含まれるグループユーザの端末２０間でコンテンツの送受信を行うための画面であり、画面上部には「ＩＭＳトークルーム」と表示され、その下に、グループ名（ここでは「グループＸ」）と、このグループに含まれるグループメンバーの人数（ここでは「４人」を示す（４））とが表示されている。
　このグループトークルーム画面は、例えばグループＸに含まれる「ユーザＢ．Ｂ」の端末２０に表示されるグループトークルーム画面であり、画面の左側には、同じグループに含まれる他のグループユーザの端末２０から自己の端末２０に送信されたメッセージ等のコンテンツが表示され、画面の右側には、自己の端末２０から他のグループユーザの端末２０に送信されるメッセージ等のコンテンツが表示される。
　ここでは、同じグループに含まれる「ユーザＡ．Ａ」の端末２０から送信された「［ＩＭＳ　Ｐａｙ］Ａ．Ａさんが割り勘で３０００円を依頼しました。」というメッセージと、「ユーザＡ．Ａ」の端末２０から送信された添付画像とを含むコンテンツが表示されている。
　図６－１９は、上記のグループトークルーム画面において端末２０のユーザによりコンテンツがタッチされた場合に表示される送金用画面の一例を示す図である。
　上記のグループトークルーム画面における「ユーザＡ．Ａ」の端末２０から送信されたコンテンツが、自己の端末２０の「ユーザＢ．Ｂ」によってタッチされると、決済アプリケーションが起動され、図６－１９のような送金用画面が表示される。
　この送金用画面には、割り勘要求で送金を依頼された金額（ここでは「３０００円」）と、「ユーザＡ．Ａ」の端末２０から送信された画像とが表示され、その下に、「送金する」と示された「送金用アイコン」が表示されている。
　図６－２０は、上記の送金用画面において端末２０のユーザにより「送金用アイコン」がタッチされた場合に表示される送金実行画面の一例を示す図である。
　この送金実行画面には、送金予定相手である「ユーザＡ．Ａ」のユーザ名およびアイコン画像と、入力された送金予定金額（ここでは「３０００円」）が表示される送金予定金額表示欄と、残高とが表示されている。また、画面下部には、送金を実行するための「送金実行アイコン」が表示されている。
　図６－２１は、上記の送金実行画面において端末２０のユーザにより「送金実行アイコン」がタッチされた場合に表示される送金完了画面の一例を示す図である。
　認証スキップ判定処理で認証処理をスキップする判定がなされなかった場合は、上記の送金実行画面において「送金実行アイコン」がタッチされた場合、図６－２０の送金実行画面から認証画面に表示が切り替わる。
　それに対し、認証スキップ判定処理で認証処理をスキップする判定がなされた場合は、認証画面が表示されることなく、図６－２０の送金実行画面から図６－２１の送金完了画面に表示が切り替わる。
　この送金完了画面には、画面中央部に、「送金完了」の文字とともに、「「送金履歴」から詳細が確認できます。」というメッセージと、送金履歴を確認するための「確認アイコン」とがポップアップ形式で表示されている。
＜処理＞
　図６－２２、図６－２３は、本実施形態における各装置が実行する処理の流れの一例を示すフローチャートである。
　これらの図では、左側から順に、「ユーザＡ．Ａ」の端末２０Ａの決済アプリケーション処理部２１３が実行する決済アプリケーション処理の一例である第５の決済アプリケーション処理、サーバ１０の送金管理処理部１１５が実行する第１の送金管理処理、「ユーザＢ．Ｂ」の端末２０Ｂの決済アプリケーション処理部２１３が実行する決済アプリケーション処理の一例である第５の決済アプリケーション処理をそれぞれ示している。
　なお、既出のフローチャートと同一のステップについては同一の符号を付して、再度の説明を省略する。
　最初に、端末２０Ａの決済アプリケーション処理部２１３は、入出力部２３に対する送金用操作を受け付ける（Ｓ１）。そして、端末２０Ａの決済アプリケーション処理部２１３は、受け付けた操作種別を判定する（Ｓ３）。
　操作種別が「送金操作」であったならば（Ｓ３；送金）、端末２０Ａの決済アプリケーション処理部２１３は、入出力部２３に対するユーザ操作に従って、送金に関する設定である送金設定を行う（Ｓ５）。そして、端末２０Ａの認証スキップ判定処理部２１３５が、第８の認証スキップ判定処理を行う（Ｓ７）。なお、変形例や他の実施形態における認証スキップ判定処理と区別するため、便宜的に「第８の認証スキップ判定処理」と称する。
　この第８の認証スキップ判定処理では、第１実施形態で説明した第１の認証スキップ判定処理と同様の手法で、記憶部２８の認証スキップ条件データ２８５６に記憶されている認証スキップ条件が成立するか否かを判定する。
　次いで、端末２０Ａの認証スキップ判定処理部２１３５は、第８の認証スキップ判定処理の判定結果に基づいて、Ａ１１～Ａ１７の処理を行う。
　その後、端末２０Ａの送金依頼処理部２１３８が、通信Ｉ／Ｆ２２によって、自己の端末２０のユーザのユーザＩＤと、送金予定相手（着金側）のユーザＩＤと、送金予定金額とを含む送金依頼情報をサーバ１０に送信する（Ｓ１９）。
　サーバ１０の送金管理処理部１１５は、通信Ｉ／Ｆ１４によって端末２０Ａから送金依頼情報を受信したか否かを判定し（Ｔ１）、受信したと判定したならば（Ｔ１；Ｙｅｓ）、送金処理を行う（Ｔ３）。具体的には、限定でなく例として、記憶部１５の送金着金管理データベース１６５に記憶されている送金元のユーザの残高に基づいて、送金予定金額の送金が可能であるか否かを判定する。そして、送金が可能であれば、残高から送金予定金額を減算して更新するとともに、送金履歴データを更新して、送金結果を「成功」とする。また、着金側のユーザの残高に送金予定金額を加算して更新するとともに、着金履歴データを更新する。一方、送金が不可であれば、送金結果を「失敗」とする。
　次いで、送金管理処理部１１５は、送金処理による送金結果を判定する（Ｔ５）。そして、送金結果が「成功」であったならば（Ｔ５；成功）、送金元用送金結果情報送信処理部１１５３が、通信Ｉ／Ｆ１４によって送金元用送金成功情報を端末２０Ａに送信する（Ｔ７）。また、着金側用着金結果情報送信処理部１１５５が、通信Ｉ／Ｆ１４によって着金側用着金成功情報を端末２０Ｂに送信する（Ｔ９）。
　一方、送金結果が「失敗」であったならば（Ｔ５；失敗）、送金元用送金結果情報送信処理部１１５３が、通信Ｉ／Ｆ１４によって送金元用送金失敗情報を端末２０Ａに送信する（Ｔ１１）。また、着金側用着金結果情報送信処理部１１５５が、通信Ｉ／Ｆ１４によって着金側用着金失敗情報を端末２０Ｂに送信する（Ｔ１３）。そして、送金管理処理部１１５は、第１の送金管理処理を終了する。
　端末２０Ａの決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から送金元用送金結果情報を受信すると（Ｓ２１）、受信した送金元用送金結果情報の種別（成功／失敗）に応じた送金結果情報を表示部２４に表示させる（Ｓ２３）。そして、端末２０Ａの決済アプリケーション処理部２１３は、第５の決済アプリケーション処理を終了する。
　端末２０Ｂの決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から着金側用着金結果情報を受信したか否かを判定し（Ｕ１）、受信したと判定したならば（Ｕ１；Ｙｅｓ）、受信した着金側用着金結果情報の種別（成功／失敗）に応じた着金結果情報を表示部２４に表示させる（Ｕ３）。そして、端末２０Ｂの決済アプリケーション処理部２１３は、第５の決済アプリケーション処理を終了する。
　一方、Ｓ３において操作種別が「送金要求」であると判定したならば（Ｓ３；送金要求）、端末Ａの決済アプリケーション処理部２１３は、入出力部２３に対するユーザ操作に従って、送金要求に関する設定である送金要求設定を行う（Ｓ２５）。
　その後、端末２０Ａの決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によって自己の端末２０のユーザのユーザＩＤと、送金要求相手のユーザＩＤと、送金要求金額とを含む送金要求依頼情報をサーバ１０に送信する（Ｓ２７）。
　送金管理処理部１１５は、通信Ｉ／Ｆ１４によって端末２０Ａから送金要求依頼情報を受信したか否かを判定し（Ｔ１５）、受信したと判定したならば（Ｔ１５；Ｙｅｓ）、送金要求依頼情報に含まれる送金要求金額を含む送金要求情報を、通信Ｉ／Ｆ１４によって、送金要求依頼情報に含まれる送金要求相手のユーザＩＤが関連付けられた端末２０（ここでは端末２０Ｂ）に送信する（Ｔ１７）。
　端末２０Ｂの決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から送金要求情報を受信したか否かを判定し（Ｕ４）、受信したと判定したならば（Ｕ４；Ｙｅｓ）、入出力部２３に対するユーザ操作に従って、送金に関する設定である送金設定を行う（Ｕ５）。そして、端末２０Ｂの認証スキップ判定処理部２１３５が、第８の認証スキップ判定処理を行う（Ｓ７）。
　その後、端末２０Ｂの決済アプリケーション処理部２１３は、Ａ１１～Ａ１７の処理を行う。そして、端末２０Ｂの送金依頼処理部２１３８が、通信Ｉ／Ｆ２２によって、自己の端末２０のユーザのユーザＩＤと、送金予定相手のユーザＩＤと、送金予定金額とを含む送金依頼情報をサーバ１０に送信する（Ｕ１９）。
　サーバ１０の送金管理処理部１１５は、通信Ｉ／Ｆ１４によって端末２０Ｂから送金依頼情報を受信したか否かを判定し（Ｔ１９）、受信したと判定したならば（Ｔ１９；Ｙｅｓ）、送金処理を行う（Ｔ２１）。そして、送金管理処理部１１５は、Ｔ５～Ｔ１３の処理を行う。
　端末２０Ｂの決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から送金元用送金結果情報を受信すると（Ｕ２１）、受信した送金元用送金結果情報の種別（成功／失敗）に応じた送金結果情報を表示部２４に表示させる（Ｕ２３）。そして、端末２０Ｂの決済アプリケーション処理部２１３は、第５の決済アプリケーション処理を終了する。
　端末２０Ａの決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から着金側用着金結果情報を受信すると（Ｓ２９）、受信した着金側用着金結果情報の種別（成功／失敗）に応じた着金結果情報を表示部２４に表示させる（Ｓ３１）。そして、端末２０Ａの決済アプリケーション処理部２１３は、第５の決済アプリケーション処理を終了する。
＜第４実施形態の効果＞
　第４実施形態は、端末２０の表示部２４（限定でなく、表示領域の一例）に端末２０のユーザに対する認証の実行に関する認証処理（限定でなく、表示処理の一例）を行い、端末２０のユーザに対する認証に基づいて、ＩＭＳマネーの送金に関する情報を端末２０の通信Ｉ／Ｆ２２によって送信し、ＩＭＳアプリケーションにおいて友だち登録されている他のユーザ（限定でなく、第１ユーザの一例）が所有する他の端末２０（限定でなく、第１端末の一例）にＩＭＳマネーを送金する端末２０が情報を取得する。そして、端末２０が、取得した情報に基づいて認証スキップ判定を行い、認証スキップ条件が成立する場合は、認証処理をせず、送金依頼情報（限定でなく、電子貨幣の送金に関する情報の一例）を通信Ｉ／Ｆ２２によって送信する構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、端末のユーザに対する認証の実行に関する表示処理をすることなく、電子貨幣の送金に関する情報を簡単に送信することができる。また、端末は、取得した情報に基づいて、表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、電子貨幣の送金に際して、表示処理を１回１回行わずに済むため、手早く円滑に送金を行うことができ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記の端末が取得する情報は、認証パスワード（限定でなく、認証情報の一例）とは異なる情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、端末のユーザを認証するための認証情報とは異なる情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第４実施形態は、上記の認証パスワードとは異なる情報は、ＩＭＳマネーに関する情報（限定でなく、電子貨幣に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第４実施形態は、上記のＩＭＳマネーに関する情報は、端末２０または、端末２０のユーザに関連づけられているＩＭＳマネーの金額に関する情報（限定でなく、端末または、端末のユーザに関連付けられている電子貨幣の金額に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣の金額に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、電子貨幣の金額に関する情報は、端末または、端末のユーザに関連付けられているため、端末は、適正な電子貨幣の金額に関する情報に基づいて、送金に関する処理を適切に行うことができる。
　また、第４実施形態は、上記のＩＭＳマネーの金額に関する情報は、友だち登録されている他の端末２０（限定でなく、第１端末の一例）のユーザ（限定でなく、第１ユーザの一例）への送金予定金額に関する情報（限定でなく、第１端末の第１ユーザへの送金に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、第１端末の第１ユーザへの送金に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第４実施形態は、上記の送金予定金額に関する情報は、他の端末２０の他のユーザへの送金金額を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、第１端末の第１ユーザへの送金に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、第１端末の第１ユーザへの送金金額が低額であれば、危険性は低いと考えられるため、端末のユーザに対する認証の実行に関する表示処理をしないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、端末２０は、１日上限設定金額（限定でなく、設定された送金金額の一例）を超えるまで、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、設定された送金金額を越えるまで、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができるとともに、ユーザの利便性を向上させることができる。一方、電子貨幣の送金に際して、設定された送金金額を超えた場合は、認証の実行に関する表示を行う場合があるため、設定された送金金額を超えたことをユーザに注意喚起することができる。
　また、第４実施形態は、上記のＩＭＳマネーの金額に関する情報は、端末２０または、端末２０のユーザに関連付けられたＩＭＳマネーの残高に関する情報（限定でなく、端末または、端末のユーザに関連付けられた電子貨幣の残高に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣の残高に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、電子貨幣の残高に関する情報は、端末または、端末のユーザに関連付けられているため、端末は、適正な電子貨幣の残高に関する情報に基づいて、送金に関する処理を適切に行うことができる。
　また、第４実施形態は、端末２０は、ＩＭＳマネーの残高が設定金額以下または、設定金額未満の場合、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣の残高が設定された金額以下または、設定された金額未満の場合、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。また、例えば、電子貨幣の残高が少ない場合は、高額の送金ができず、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、端末２０は、端末２０のオートチャージ設定（限定でなく、電子貨幣が設定された金額以下または設定された金額未満になった場合に自動で電子貨幣の入金が端末に行われる設定の一例）が「ＯＦＦ」になっている場合、ＩＭＳマネーの残高が設定金額以下または、設定金額未満の場合に、認証処理を行う構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、端末の電子貨幣が設定された金額以下または、設定された金額未満になった場合に自動で電子貨幣の入金が端末に行われる設定になっている場合、金額が少なくなれば自動で電子貨幣の入金が端末に行われるため、高額の送金が可能となり、リスクが生ずる。このため、認証の実行に関する表示を行うことで、高額の送金が可能になることをユーザに注意喚起することができる。
　また、第４実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーによって送金を行った頻度または回数に関する情報（限定でなく、電子貨幣によって送金を行った頻度または回数に関する情報）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣によって送金を行った頻度または回数に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、電子貨幣によって送金を行った頻度が高い場合や回数が多い場合は、同じユーザが電子貨幣によって送金を行っている可能性が高く、危険性は低いと考えられるため、表示処理をしないようにすることで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーによって端末２０または、端末２０のユーザが送金を行った、他の端末２０または、他の端末２０のユーザに関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣によって端末または、端末のユーザが送金を行った、端末または、端末のユーザに関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、端末のユーザが送金を行ったことのある他の端末または、他の端末のユーザであれば、危険性は低いと考えられるため、表示処理をしないようにすることで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記のＩＭＳマネーに関する情報は、最終送金日時（限定でなく、電子貨幣によって送金を行った時間に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣によって送金を行った時間に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第４実施形態は、端末２０が、上記の最終送金日時から設定時間内の場合、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣の送金を行った時間から設定された時間内の場合、認証の実行に関する表示を行わずに済むため、端末の処理負荷を軽減することができる。また、例えば、電子貨幣の送金を行ってからそれほど時間が経過していなければ、同じユーザが再び送金を行う可能性が高く、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーによって送金を行った場所に関する情報（限定でなく、電子貨幣によって送金を行った場所に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣によって送金を行った場所に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第４実施形態は、端末２０が、ＩＭＳマネーによって送金を行った場所に関する情報と、端末２０の位置に関する情報とに基づいて、認証処理を行わない構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣によって送金を行った場所に関する情報と、端末の位置に関する情報とに基づいて、認証の実行に関する表示処理を行わないため、端末の処理負荷を軽減することができる。また、例えば、過去に電子貨幣の送金を行った場所から端末の位置が離れていなければ、ユーザが同じ場所で送金を行おうとしている可能性が高く、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記のＩＭＳマネーに関する情報は、ＩＭＳマネーの送金をするための認証処理を行った場所に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣の送金をするための認証の実行を行った場所に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、過去に電子貨幣の送金をするための認証の実行を行った場所であれば、同じユーザについて再び認証の実行を行う場合である可能性が高く、危険性は低いと考えられるため、表示処理をしないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記の認証パスワードとは異なる情報は、場所に関する情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、場所に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第４実施形態は、上記の場所に関する情報は、送金安全エリアに関する情報（限定でなく、セキュリティが高い位置の情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、セキュリティが高い位置の情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、セキュリティが高い位置の情報に基づいて、端末のユーザに対する認証の実行に関する表示処理をしないようにすることで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記の場所に関する情報は、端末のユーザが設定回数以上訪れた場所の情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、端末のユーザが設定された回数以上訪れた場所の情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、端末のユーザが設定された回数以上訪れた場所の情報に基づいて、端末のユーザに対する認証の実行に関する表示処理をしないようにすることで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記の場所に関する情報は、端末２０のユーザの自宅の位置、端末２０のユーザが勤めている会社の位置、および端末２０のユーザの関係者の自宅のうち少なくとも１つの情報を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、端末のユーザの自宅の位置、端末のユーザが勤めている会社の位置、および端末のユーザの関係者の自宅のうち少なくとも１つの情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、端末のユーザの自宅の位置、端末のユーザが勤めている会社の位置、および端末のユーザの関係者の自宅のうち少なくとも１つの情報に基づいて、端末のユーザに対する認証の実行に関する表示処理をしないようにすることで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記の場所に関する情報は、決済アプリケーション対応店舗の位置情報（限定でなく、電子貨幣によって決済可能な店舗の位置に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、電子貨幣によって決済可能な店舗の位置に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、電子貨幣によって決済可能な店舗の位置と端末の位置とが離れていなければ、この店舗での支払いに際して端末のユーザが仲間同士でお金のやり取りを行うようなことが想定され、危険性は低いと考えられるため、端末のユーザに対する認証の実行に関する表示処理をしないようにすることで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記の認証パスワードとは異なる情報は、送金相手に関する情報（限定でなく、第１端末の第１ユーザに関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、第１端末の第１ユーザに関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
　また、第４実施形態は、上記の送金相手に関する情報は、例えば、送金相手が親しい友人や親族であること、送金相手に過去に送金履歴があること、送金相手から過去に着金履歴があることの情報（限定でなく、端末のユーザとの関係に関連する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、端末のユーザとの関係に関連する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、端末のユーザと密接な関係のあるユーザであれば、危険性は低いと考えられるため、端末のユーザに対する認証の実行に関する表示処理をしないようにすることで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記の送金相手に関する情報は、端末２０のユーザの端末２０と、ＩＭＳアプリケーションにおいてコンテンツの送受信が可能なグループに含まれていることを示す情報（限定でなく、端末のユーザの端末とメッセージの送受信が可能なグループに含まれていることを示す情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、端末のユーザの端末とメッセージの送受信が可能なグループに含まれていることを示す情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、端末のユーザの端末とメッセージの送受信が可能なグループに含まれる第１ユーザであれば、危険性は低いと考えられるため、端末のユーザに対する認証の実行に関する表示処理をしないようにすることで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記のＩＭＳアプリケーションにおけるグループは、端末２０のユーザが送金する端末２０（限定でなく、第１端末の一例）のユーザ（限定でなく、第１ユーザの一例）とは別の端末２０（限定でなく、第２端末の一例）の別のユーザ（限定でなく、第２ユーザ）を含み、この別のユーザの端末２０とコンテンツの送受信が可能である構成を示している。
　このような構成により得られる効果の一例として、端末は、グループに含まれる第２ユーザの第２端末とメッセージの送受信をすることができる。
　また、第４実施形態は、上記の認証パスワードとは異なる情報は、端末２０または、端末２０に記憶された決済アプリケーションの設定に関する情報（限定でなく、端末または、端末に記憶されたアプリケーションの設定に関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、端末または、端末に記憶されたアプリケーションの設定に関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、端末または、端末に記憶されたアプリケーションの設定に関する情報がユーザによって設定された情報である場合、ユーザの意思を尊重することができ、ユーザの利便性を向上させることができる。
　また、第４実施形態は、上記の認証パスワードとは異なる情報は、端末２０に設定された、端末２０がロック中であるか否かを示す情報（限定でなく、端末に設定された、端末のセキュリティに関する情報の一例）を含む構成を示している。
　このような構成により得られる効果の一例として、端末は、電子貨幣の送金に際して、端末に設定された、端末のセキュリティに関する情報を取得することで、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。また、例えば、端末のセキュリティに関する情報が端末のユーザの認証に関連する情報である場合、端末のユーザに対する認証の実行に関する表示処理を省略することで、ユーザの利便性を向上させることができる。
　また、第４実施形態は、端末２０は、他のユーザの端末２０（限定でなく、第１端末の一例）へのＩＭＳマネーの送金に関する情報を通信Ｉ／Ｆ２２によって受信する構成を示している。
　このような構成により得られる効果の一例として、端末は、第１端末への電子貨幣の送金に関する情報を通信部によって受信して取得することができる。
　また、第４実施形態は、端末は、同時に割り勘要求を受けた複数の端末２０があり、設定数以上の端末２０で認証が完了した場合に、認証処理をスキップする構成を示している。
　このような構成により得られる効果の一例として、電子貨幣の送金を管理するサーバから送付された情報は、第１端末への電子貨幣の送金に関する情報を受信した第２端末のユーザの認証に基づき送信される。このため、端末は、第２端末のユーザが認証されたことに基づいて、電子貨幣の送金を管理するサーバから送付された情報を取得することができる。
＜第４変形例（１）＞
　第４実施形態では、送金用の認証処理をスキップするか否かの認証スキップ判定を端末２０が実行することとしたが、これに限定されない。第２実施形態では、決済用の認証処理を端末２０にスキップさせるか否かの認証スキップ判定をサーバ１０で実行する構成を示したが、これと同様に、送金用の認証処理を端末２０にスキップさせるか否かの認証スキップ判定をサーバ１０で実行するようにすることもできる。
　図６－２４は、本変形例においてサーバ１０の記憶部１５に記憶される認証スキップ条件データ１６６のデータ構成の一例を示す図である。この認証スキップ条件データ１６６は、端末２０に送金用の認証処理をスキップさせるための条件である認証スキップ条件が定められたデータである。このデータ構成は、端末２０の認証スキップ条件データ２８５６と同様であるが、内容が一部異なっている。以下、異なる条件に着目して説明する。
＜条件カテゴリＮｏ「ＳＰ１５－２」＞
　条件カテゴリＮｏ「ＳＰ１５（セキュリティ）」に含まれる条件Ｎｏ「ＳＰ１５－２」の認証スキップ条件として、「端末のユーザの信用スコアが８０点以上」が定められている。これは、信用スコアデータ１５８に記憶されている端末２０のユーザの信用スコアが８０点以上、つまり端末２０のユーザの信用が一定の水準に達している場合に、端末２０の認証処理をスキップさせることを意味する。
　この判定では、端末２０は、信用スコアデータ１５８に記憶されている信用スコアの中から、送金予定の端末２０のユーザの信用スコアを取得する。そして、取得した信用スコアが８０点以上であるか否かを判定する。
　他の条件は、端末２０の認証スキップ条件データ２８５６と同様であるが、本変形例では、第４実施形態とは異なり、サーバ１０が送金用の認証スキップ判定処理を行う。従って、サーバ１０は、記憶部１５のユーザ登録データ１５３に記憶されているユーザ情報、店舗登録データ１５５に記憶されている店舗情報、ＩＭＳユーザ管理データベース１６１に記憶されているＩＭＳユーザ管理データ、ＩＭＳグループ管理データベース１６３に記憶されているＩＭＳグループ管理データ、送金着金管理データベース１６５に記憶されている送金着金管理データ等のサーバ管理情報を取得する。また、サーバ１０は、端末２０の位置情報（端末位置情報）等のサーバ１０側で管理していない情報を端末２０に要求して取得する。そして、サーバ１０は、取得した情報に基づいて、認証スキップ判定を行う。
　図６－２５は、本変形例における各装置が実行する処理の流れの一例を示すフローチャートである。
　この図では、左側から順に、端末２０Ａの決済アプリケーション処理部２１３が実行する決済アプリケーション処理の一例である第６の決済アプリケーション処理、サーバ１０の送金管理処理部１１５が実行する第２の送金管理処理、端末２０Ｂの決済アプリケーション処理部２１３が実行する決済アプリケーション処理の一例である第６の決済アプリケーション処理をそれぞれ示しており、図６－２２に対応する部分を抜き出したものである。
　なお、既出のフローチャートと同一のステップについては同一の符号を付して、再度の説明を省略する。
　端末２０Ａの決済アプリケーション処理部２１３は、Ｓ５において送金設定を行った後、通信Ｉ／Ｆ２２によって送金依頼情報をサーバ１０に送信する（Ｓ１９）。
　サーバ１０の送金管理処理部１１５は、通信Ｉ／Ｆ１４によって端末２０Ａから送金依頼情報を受信したと判定したならば（Ｔ１；Ｙｅｓ）、第９の認証スキップ判定処理を行う（Ｗ１）。なお、他の実施形態における認証スキップ判定処理と区別するため、便宜的に、「第９の認証スキップ判定処理」と称する。
具体的には、第４実施形態と同様の手法で、記憶部１５に記憶されている不図示の認証スキップ条件データに含まれる認証スキップ条件の成否を、記憶部１５から取得した各種のサーバ管理情報と、端末２０に要求して取得した情報とに基づいて判定する。
　第９の認証スキップ判定処理を行った後、送金管理処理部１１５は、認証処理をスキップする判定がなされたか否かを判定する（Ｗ３）。認証処理をスキップすると判定された場合（Ｗ３；Ｙｅｓ）、送金管理処理部１１５は、Ｔ３へと処理を移す。
　一方、認証処理をスキップしないと判定された場合（Ｗ１：Ｎｏ）、送金管理処理部１１５は、通信Ｉ／Ｆ１４によって追加認証要求情報を端末２０に送信する（Ｗ５）。
　端末２０Ａの決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によってサーバ１０から追加認証要求情報を受信したか否かを判定し（Ｖ１）、受信しなかったと判定したならば（Ｖ１；Ｎｏ）、Ｓ２１へと処理を移す。この場合は、端末２０において認証処理がスキップされる。
　一方、通信Ｉ／Ｆ２２によってサーバ１０から追加認証要求情報を受信したと判定したならば（Ｖ１；Ｙｅｓ）、決済アプリケーション処理部２１３は、Ａ１３～Ａ１７の処理を実行する。この場合は、端末２０において認証処理が実行される。
　認証処理で認証結果が「ＯＫ」となった場合（Ａ１５；Ｙｅｓ）、決済アプリケーション処理部２１３は、通信Ｉ／Ｆ２２によって認証成功情報をサーバ１０に送信する（Ｖ３）。
　送金管理処理部１１５は、通信Ｉ／Ｆ１４によって端末２０から認証成功情報を受信すると（Ｗ７）、Ｔ３の処理を実行する。つまり、端末２０から認証が成功したことを示す情報を受信した後、送金処理を行う（Ｔ３）。そして、送金管理処理部１１５は、Ｔ５へと処理を移す。
＜第４変形例（１）の効果＞
　本変形例は、サーバ１０が、端末２０によるＩＭＳマネーの送金に関する送金依頼情報（限定でなく、電子貨幣の送金に関する第１情報の一例）を通信Ｉ／Ｆ１４によって受信し、追加認証要求情報（限定でなく、端末のユーザの認証に関する情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信する。また、サーバ１０は、認証成功情報（限定でなく、端末のユーザが認証されたことを示す情報の一例）を通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、認証成功情報に基づいて、送金元用送金結果情報（限定でなく、電子貨幣による送金が行われたことを示す送金情報の一例）を端末２０に通信Ｉ／Ｆ１４によって送信し、認証成功情報と、送金依頼情報とに基づき、着金側用着金結果情報（限定でなく、電子貨幣の送金に関する第２情報の一例）を、送金相手の端末２０（限定でなく、端末とは異なる端末の一例）に通信Ｉ／Ｆ１４によって送信する。この際、サーバ１０は、認証パスワード（限定でなく、ユーザを認証するための認証情報の一例）とは異なる情報の取得に基づいて、追加認証要求情報を通信Ｉ／Ｆ１４によって端末２０に送信せず、送金元用送金結果情報を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
　このような構成により得られる効果の一例として、サーバは、電子貨幣の送金に際して、端末のユーザを認証するための認証情報とは異なる情報を取得することで、端末のユーザの認証に関する情報を端末に送信しないため、サーバの処理負荷を軽減することができる。また、端末のユーザの認証に関する情報を端末に送信することなく送金情報を端末に送信することができる。
＜第４変形例（２）＞
　上記において、サーバ１０が、端末２０のユーザの信用スコアに基づいて、認証スキップ条件を変更するようにしてもよいし、しなくてもよい。
　具体的には、限定でなく例として、サーバ１０は、端末２０のユーザの信用スコアが高くなるほど、認証スキップ条件データ１６６の条件Ｎｏ「ＳＰ１１－１」の認証スキップ条件における「設定時間」を長くするようにしてもよいし、しなくてもよい。
　より具体的には、限定でなく例として、信用スコアが０点の場合の設定時間を「２時間」として設定しておく。また、信用スコアの閾値として１０点の整数倍の閾値（１０点、２０点、・・・、１００点）を設定しておく。そして、端末２０のユーザの信用スコアが閾値に達するごとに、設定時間を１時間ずつ長く設定するなどすることができる。
　また、限定でなく例として、サーバ１０は、端末２０のユーザの信用スコアが高くなるほど、認証スキップ条件データ１６６の条件Ｎｏ「ＳＰ１３－１」の認証スキップ条件における「１日上限設定金額」を高くするようにしてもよいし、しなくてもよい。より具体的には、限定でなく例として、信用スコアが０点の場合の１日上限設定金額を「０円」として設定しておく。また、信用スコアの閾値として１０点の整数倍の閾値（１０点、２０点、・・・、１００点）を設定しておく。そして、端末２０のユーザの信用スコアが閾値に達するごとに、１日上限設定金額を５０００円ずつ高く設定するなどすることができる。
＜第４変形例（２）の効果＞
　本変形例により得られる効果の一例として、サーバは、端末のユーザの信用度に基づいて、認証スキップ条件を変更することができる。例えば、端末のユーザの信用度が高いほど、認証処理がスキップされ易くなるように認証スキップ条件を変更することで、ユーザの利便性を向上させることができる。
＜第４変形例（３）＞
　第４実施形態では、サーバ１０から送信される送金に関する情報が端末２０の記憶部２８に送金履歴データとして記憶され、端末２０が、この送金履歴データに含まれる送金に関する情報に基づいて認証スキップ判定を行うこととしたが、これに限定されない。
　具体的には、端末２０の記憶部２８に送金履歴データを記憶させないようにすることもできる。この場合、端末２０は、認証スキップ判定に必要な情報をサーバ１０に要求し、サーバ１０から取得した情報に基づいて、認証スキップ判定を行うようにしてもよいし、しなくてもよい。
＜第４変形例（３）の効果＞
　本変形例により得られる効果の一例として、電子貨幣による送金の履歴に関する情報を端末に記憶させておく必要がないため、端末の記憶容量を節約することができる。
＜第４変形例（４）＞
　第４実施形態では、１日上限設定金額を、その１日における送金済みの金額（送金金額）の合計金額に対する閾値とする上限の設定金額としたが、これに限定されない。具体的には、限定でなく例として、１日上限設定金額を、その１日における送金済みの金額（送金金額）の合計金額と、これから送金しようとする金額（送金予定金額）との合算金額に対する閾値金額とする上限の設定金額としてもよいし、しなくてもよい。
　また、上限設定金額は、必ずしも１日の上限設定金額としなければならないわけではなく、過去所定期間（過去１週間、過去２週間、過去１か月等）の上限設定金額としてもよいし、しなくてもよい。
　また、上限設定金額を、これから送金しようとする金額（送金予定金額）、つまり１回で送金する金額に対する設定金額とし、「送金予定金額が設定金額以下（または設定金額未満）」とする認証スキップ条件に基づいて認証スキップ判定を行うようにすることもできる。このようにすることで、端末２０のユーザが少額を送金するような場合に、認証処理をスキップさせることができる。
＜第４変形例（４）の効果＞
　本変形例により得られる効果の一例として、過去に送金した金額（送金金額）ばかりでなく、これから送金しようとする金額（送金予定金額）をも考慮して、認証の実行に関する表示を行うかどうかを判定することができる。
　また、１回の送金金額が設定された金額を超えるまで、認証の実行に関する表示を行わないことで、ユーザの利便性を向上させることができる。
＜第４変形例（５）＞
　第４実施形態で説明した各種の認証スキップ条件はあくまでも一例に過ぎず、適宜、追加や削除、変更することが可能である。
　具体的には、限定でなく例として、「現在日時が最終送金日時から設定時間内」とする認証スキップ条件を、「現在日時が最終認証日時から設定時間内」とすることもできる。
　また、この場合における「最終認証日時」は、必ずしも送金用の認証が最後に行われた日時に限られるわけではなく、限定でなく例として、第１実施形態等で説明したＩＭＳマネーによる決済用の認証が最後に行われた日時や、端末２０のＯＳ側のロックを解除するための認証が最後に行われた日時、決済アプリケーション側のロックを解除するための認証が最後に行われた日時といった、送金用の認証以外の種類の認証が最後に行われた日時を、上記の認証スキップ条件における「最終認証日時」とすることもできる。
＜第４変形例（５）の効果＞
　本変形例により得られる効果の一例として、端末は、電子貨幣の送金に際して、送金用の認証が最後に行われた日時から設定された時間内である場合ばかりでなく、送金用の認証とは異なる種類の認証が最後に行われた日時から設定された時間内である場合も、認証の実行に関する表示を行わないため、ユーザの利便性をより一層向上させることができる。
　１　　通信システム
　１０　サーバ
　２０　端末
　３０　ネットワーク
　４０　店舗ＰＯＳシステム
　５０　店舗コードリーダ装置
　６０　コードレジ
　７０　店舗サーバ

Claims (29)

  1. 　端末による電子貨幣の決済に関するコード情報を情報処理装置によって生成する生成方法であって、
    　情報を取得することと、
    　前記情報に基づいて、前記端末のユーザの認証に関する情報を含めて、前記コード情報を生成することとを含む。
  2. 　請求項１に記載の生成方法であって、
    　前記コード情報は、前記端末のコードリーダによって読み取られる情報を含む。
  3. 　請求項２に記載の生成方法であって、
    　前記情報は、前記端末のユーザを認証するための認証情報とは異なる情報を含む。
  4. 　請求項３に記載の生成方法であって、
    　前記認証情報とは異なる情報は、場所に関する情報を含む。
  5. 　請求項４に記載の生成方法であって、
    　前記場所に関する情報は、前記端末によって前記電子貨幣による決済が行われる店舗に関する情報を含む。
  6. 　請求項５に記載の生成方法であって、
    　前記コード情報は、前記店舗が前記情報処理装置に記憶されている特定の店舗の場合、前記端末のユーザの認証に関する情報を含めて生成される。
  7. 　請求項３に記載の生成方法であって、
    　前記認証情報とは異なる情報は、商品に関する情報を含む。
  8. 　請求項７に記載の生成方法であって、
    　前記商品に関する情報は、設定された金額以下または設定された金額未満の商品に関する情報を含む。
  9. 　請求項７に記載の生成方法であって、
    　前記商品に関する情報は、前記端末のユーザが前記電子貨幣によって購入する商品の総額に関する情報を含む。
  10. 　請求項２に記載の生成方法であって、
    　前記情報は、前記端末のユーザの認証に関する情報の生成を依頼する依頼情報を含む。
  11. 　請求項１０に記載の生成方法であって、
    　前記情報は、前記端末による前記電子貨幣の決済を行う店舗のサーバによって依頼された前記依頼情報を含む。
  12. 　請求項２から請求項１１のいずれか一項に記載の生成方法であって、
    　前記端末のユーザの認証に関する情報は、前記端末のユーザの認証を前記端末がスキップするためのスキップ情報を含む。
  13. 　請求項１２に記載の生成方法であって、
    　前記スキップ情報は、前記端末が前記スキップ情報の取得に基づいて、前記端末による前記端末のユーザの認証がスキップされる情報を含む。
  14. 　請求項２から請求項１１のいずれか一項に記載の生成方法であって、
    　前記端末のユーザの認証に関する情報は、前記端末のユーザの認証をスキップするために前記端末が利用する情報を含む。
  15. 　請求項１４に記載の生成方法であって、
    　前記端末のユーザの認証に関する情報は、前記端末のユーザが前記電子貨幣によって購入する商品に関する情報を含む。
  16. 　請求項１５に記載の生成方法であって、
    　前記商品に関する情報は、前記商品の金額に関する情報を含む。
  17. 　請求項２から請求項１１のいずれか一項に記載の生成方法であって、
    　前記端末のユーザの認証に関する情報は、場所に関する情報を含む。
  18. 　請求項１７に記載の生成方法であって、
    　前記場所に関する情報は、商品を購入する店舗に関する情報を含む。
  19. 　請求項１に記載の生成方法であって、
    　前記情報処理装置は、前記端末であり、
    　前記コード情報は、前記端末によって生成される。
  20. 　請求項１９に記載の生成方法であって、
    　前記端末のユーザの認証に関する情報は、前記端末によって、前記端末のユーザが認証されたことを示す情報を含む。
  21. 　請求項１９または請求項２０に記載の生成方法であって、
    　前記情報は、前記端末のユーザを認証するための認証情報とは異なる情報を含む。
  22. 　請求項２１に記載の生成方法であって、
    　前記認証情報とは異なる情報は、前記電子貨幣に関する情報を含む。
  23. 請求項２１に記載の生成方法であって、
    　前記認証情報とは異なる情報は、場所に関する情報を含む。
  24. 　請求項２１に記載の生成方法であって、
    　前記認証情報とは異なる情報は、商品に関する情報を含む。
  25. 　請求項２１に記載の生成方法であって、
    　前記認証情報とは異なる情報は、前記端末または、前記端末に記憶されたアプリケーションの設定に関する情報を含む。
  26. 　請求項１９から請求項２５のいずれか一項に記載の生成方法であって、
    　前記端末のユーザの認証に関する情報は、前記電子貨幣の決済を管理するサーバに取得される。
  27. 　請求項２６に記載の生成方法であって、
    　前記電子貨幣の決済を管理するサーバは、前記端末のユーザの認証に関する情報に基づいて、前記端末のユーザの認証を前記端末により実行することに関する情報を、前記サーバの通信部によって前記端末に送信せず、前記電子貨幣による決済が行われたことを示す決済情報を前記通信部によって前記端末に送信する。
  28. 　端末による電子貨幣の決済に関するコード情報を情報処理装置のコンピュータによって生成するためのプログラムであって、
    　情報を取得することと、
    　前記情報に基づいて、前記端末のユーザの認証に関する情報を含めて、前記コード情報を生成することとを含む。
  29. 　端末による電子貨幣の決済に関するコード情報を生成する情報処理装置であって、
    　情報を取得する取得部と、
    　前記情報に基づいて、前記端末のユーザの認証に関する情報を含めて、前記コード情報を生成する制御を行う制御部とを備える。
PCT/JP2018/047865 2018-12-21 2018-12-26 生成方法、プログラム、情報処理装置 WO2020129264A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020207031642A KR102612064B1 (ko) 2018-12-21 2018-12-26 생성 방법, 프로그램, 정보처리 장치
KR1020237007106A KR102624941B1 (ko) 2018-12-21 2018-12-26 생성 방법, 프로그램, 정보처리 장치
CN201880093541.XA CN112119415A (zh) 2018-12-21 2018-12-26 生成方法、程序以及信息处理装置
US17/129,154 US20210110383A1 (en) 2018-12-21 2020-12-21 Generation method, program and information processing device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018240337A JP6585808B1 (ja) 2018-12-21 2018-12-21 生成方法、プログラム、情報処理装置
JP2018-240337 2018-12-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/129,154 Continuation US20210110383A1 (en) 2018-12-21 2020-12-21 Generation method, program and information processing device

Publications (1)

Publication Number Publication Date
WO2020129264A1 true WO2020129264A1 (ja) 2020-06-25

Family

ID=68095389

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/047865 WO2020129264A1 (ja) 2018-12-21 2018-12-26 生成方法、プログラム、情報処理装置

Country Status (5)

Country Link
US (1) US20210110383A1 (ja)
JP (1) JP6585808B1 (ja)
KR (2) KR102624941B1 (ja)
CN (1) CN112119415A (ja)
WO (1) WO2020129264A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7287243B2 (ja) * 2019-11-08 2023-06-06 トヨタ自動車株式会社 ウォレットシステムおよびウォレットプログラム
JP7022108B2 (ja) * 2019-11-27 2022-02-17 Kddi株式会社 決済処理方法及び決済処理装置
JP6754884B1 (ja) * 2019-12-04 2020-09-16 ＰａｙＰａｙ株式会社 提供装置、提供方法及び提供プログラム
WO2021137269A1 (ja) * 2019-12-30 2021-07-08 Ｌｉｎｅ株式会社 プログラム、情報処理方法、端末
JP7086923B2 (ja) 2019-12-30 2022-06-20 Ｌｉｎｅ株式会社 プログラム、情報処理方法、端末
JP7269188B2 (ja) * 2020-02-07 2023-05-08 ＰａｙＰａｙ株式会社 出力制御プログラム、出力制御装置及び出力制御方法
JP6910502B1 (ja) * 2020-05-08 2021-07-28 Kddi株式会社 決済処理方法及び決済処理装置
JP6924876B1 (ja) * 2020-06-12 2021-08-25 Kddi株式会社 決済処理方法
JP6924877B1 (ja) * 2020-06-12 2021-08-25 Kddi株式会社 決済処理方法
JP2022120337A (ja) * 2021-02-05 2022-08-18 セイコーエプソン株式会社 端末装置、端末装置の制御方法および記録媒体
JP7191156B2 (ja) * 2021-05-27 2022-12-16 ＰａｙＰａｙ株式会社 情報処理装置、サービス提供システム、情報処理システム、情報処理方法、およびプログラム
JP7223196B1 (ja) 2022-03-07 2023-02-15 ＰａｙＰａｙ株式会社 情報処理装置、情報処理方法、およびプログラム
JP7104259B1 (ja) 2022-03-07 2022-07-20 ＰａｙＰａｙ株式会社 情報処理装置、情報処理方法、およびプログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006268302A (ja) * 2005-03-23 2006-10-05 Xing Inc 決済方法及び決済システム
JP2010287250A (ja) * 2010-08-10 2010-12-24 Cyber Coin Kk キャッシュレス決済のための認証システム
JP2012216155A (ja) * 2011-04-01 2012-11-08 Japan Research Institute Ltd 決済サーバおよび決済システム
JP2017021742A (ja) * 2015-07-15 2017-01-26 株式会社デンソーウェーブ 情報読取装置および情報読取システム
WO2017029739A1 (ja) * 2015-08-19 2017-02-23 株式会社 東京メカトロニクス 携帯端末を利用したクレジット決済システムおよび方法
JP2017204109A (ja) * 2016-05-11 2017-11-16 東芝テック株式会社 決済システム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8699994B2 (en) * 2010-12-16 2014-04-15 Boku, Inc. Systems and methods to selectively authenticate via mobile communications
AU2012217606A1 (en) * 2011-02-16 2013-05-09 Visa International Service Association Snap mobile payment apparatuses, methods and systems
US20140095385A1 (en) * 2012-09-28 2014-04-03 Alex Ainslie Selecting merchants for automatic payments
CN104838399B (zh) * 2012-12-10 2019-08-27 维萨国际服务协会 使用移动设备认证远程交易
KR20160043340A (ko) * 2014-10-13 2016-04-21 에스케이플래닛 주식회사 통합 코드를 이용한 결제 서비스 제공 방법, 이를 위한 시스템 및 장치
KR20170041465A (ko) * 2015-10-07 2017-04-17 삼성전자주식회사 결제 서비스 제공 방법 및 이를 구현한 전자 장치
US20170109752A1 (en) * 2015-10-15 2017-04-20 Mastercard International Incorporated Utilizing enhanced cardholder authentication token
KR101681002B1 (ko) 2015-12-02 2016-11-29 (주)인더스웰 멀티전자지갑 선불카드와 허브코드 기반 전자지갑 간의 간편 결제 장치 및 그 방법
US11113687B2 (en) * 2015-12-15 2021-09-07 Mastercard International Incorporated System for performing cross card authentication using wallet transaction authentication history

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006268302A (ja) * 2005-03-23 2006-10-05 Xing Inc 決済方法及び決済システム
JP2010287250A (ja) * 2010-08-10 2010-12-24 Cyber Coin Kk キャッシュレス決済のための認証システム
JP2012216155A (ja) * 2011-04-01 2012-11-08 Japan Research Institute Ltd 決済サーバおよび決済システム
JP2017021742A (ja) * 2015-07-15 2017-01-26 株式会社デンソーウェーブ 情報読取装置および情報読取システム
WO2017029739A1 (ja) * 2015-08-19 2017-02-23 株式会社 東京メカトロニクス 携帯端末を利用したクレジット決済システムおよび方法
JP2017204109A (ja) * 2016-05-11 2017-11-16 東芝テック株式会社 決済システム

Also Published As

Publication number Publication date
JP2020102051A (ja) 2020-07-02
KR102612064B1 (ko) 2023-12-11
US20210110383A1 (en) 2021-04-15
CN112119415A (zh) 2020-12-22
KR20200139225A (ko) 2020-12-11
KR20230037675A (ko) 2023-03-16
JP6585808B1 (ja) 2019-10-02
KR102624941B1 (ko) 2024-01-15

Similar Documents

Publication Publication Date Title
WO2020129264A1 (ja) 生成方法、プログラム、情報処理装置
JP6681968B1 (ja) プログラム、認証方法、端末
US11669824B2 (en) Shared mobile payments
US11551214B2 (en) Fraud alerting using mobile phone location
JP6457095B2 (ja) ピア・ツー・ビジネスの支払いの送信および受信の促進
JP2015507248A (ja) ネットワークアクセス可能な販売時点情報管理デバイスインスタンス
JP7343258B2 (ja) プログラム、情報処理方法、情報処理装置
US20140143104A1 (en) Receipt retrieval based on location
JP2020102050A (ja) 認証方法、プログラム、サーバ
Liu The role of Alipay in China
JP7364311B2 (ja) プログラム、情報処理方法、端末
JP7506457B2 (ja) プログラム、情報処理方法、サーバ
JP7492942B2 (ja) プログラム、情報処理方法、情報処理装置
JP7417796B2 (ja) プログラム、情報処理方法、サーバ
JP7306772B2 (ja) プログラム、情報処理方法、サーバ
US20230069256A1 (en) White label merchant stored value account peer linking and funding system

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: 18943809

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20207031642

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18943809

Country of ref document: EP

Kind code of ref document: A1