JP7305420B2 - Payment Method - Google Patents

Description

The present disclosure relates to payments for boarding-passed passengers.

2. Description of the Related Art Conventionally, payment by credit card has been carried out not only in the purchase of goods or services but also in various aspects such as payment of public utility bills. Payment by credit card is convenient for users because it does not require carrying cash. Various techniques have been proposed for settlement by credit card. For example, Japanese Patent Laying-Open No. 06-176249 (Patent Document 1) discloses a technique for inquiring about the validity of a credit card using credit card information read from the credit card.

JP-A-06-176249

In recent years, while the number of settlements using credit cards has increased, the damage caused by credit card information theft and abuse such as credit card information skimming has also increased. In particular, when a passenger of an airplane makes a payment for purchasing a product, the passenger needs to manage cash and credit cards while managing a boarding pass. Therefore, it is expected that the risk of loss of cash and theft of credit card information will increase. Therefore, techniques to reduce risk are needed.

The present disclosure has been conceived in view of such circumstances, and its purpose is to provide technology for reducing the risk of passengers issued boarding passes.

According to one aspect of the present disclosure, a computer-implemented payment method includes the steps of obtaining an order from a passenger; obtaining information entered by the passenger for authentication; a step of authenticating a passenger by comparing passenger information, which is information registered in advance about the passenger and is described in a boarding pass issued to the passenger; and registering the payment information with the passenger information.

Passenger information may include at least one of a reservation number, seat number, and passenger name.

Passenger information may appear on the boarding pass as a machine-readable code.
The passenger information may further include information that is pre-registered about the passenger and is not written on the boarding pass. The step of authenticating the passenger may include matching the authentication information with a combination of boarding pass information and non-boarding pass information in the passenger information.

The method may further comprise executing a payment with an external device based on the payment information.

The method may further comprise obtaining a token for the passenger issued by an external device. The step of executing the payment based on the payment information may include using the token to request authorization of the payment based on the payment information from the external device.

The method may further comprise updating product information based on the order, with or without approval of payment authorization by the external device.

The method may further comprise the step of reverting the update of the product information based on the order if the external device denies the authorization of the payment.

The computer may be onboard the aircraft of the flight associated with the boarding pass. Obtaining the order may be performed while the aircraft is in flight. Requesting payment authorization from the external device based on the payment information may be performed after landing of the aircraft.

The orders may include orders for goods on board the aircraft of the flight associated with the boarding pass.
Merchandise may include at least one of items sold onboard a flight, seat changes onboard a flight, and tickets for after-disembarkation transportation, events, or lodging.

According to another aspect of the present disclosure, there is provided a program that causes a computer to execute the payment method.

According to still another aspect of the present disclosure, an information processing device is provided that includes a storage device that stores the program and one or more processors that execute the program.

According to yet another aspect of the present disclosure, a reservation server that manages flight reservation information, a check-in machine that issues a flight boarding pass according to the reservation information managed by the reservation server, and a passenger order for the boarding pass. A payment system is provided, comprising an information processing device that processes The information processing device includes a storage device that stores the program, and one or more processors that execute the program.

According to the present disclosure, the information for authentication input by the passenger is collated with the passenger information, which is the information registered in advance about the passenger and described in the boarding pass issued to the passenger. Passengers are authenticated by If the passenger authentication is successful, the payment information regarding the order is registered in the passenger information. This may reduce the passenger's risk when ordering, as the passenger may be authenticated with the information on the boarding pass without having to enter credit card information when ordering.

1 is a diagram schematically showing the configuration of a settlement system; FIG. FIG. 10 is a diagram showing an example of a screen displayed on the terminal 100 when making a flight reservation; FIG. FIG. 4 is a diagram showing an example of a scene in which a user 700 stands in front of a check-in machine 400 to output a boarding pass; FIG. 3 is a diagram showing an example of a scene in which a user 700 uses the terminal 100 to order merchandise on an airplane. FIG. 4 is a diagram schematically showing a scene in which an aircraft with on-board server 300 has landed at an airport; 2 is a diagram showing an example of a hardware configuration of terminal 100. FIG. 2 is a diagram showing an example of a hardware configuration of reservation server 200. FIG. 3 is a diagram showing an example of a hardware configuration of on-board server 300. FIG. 4 is a diagram showing an example of the hardware configuration of the check-in machine 400; FIG. It is a figure which shows typically an example of the data structure of reservation information and passenger information. It is a figure which shows an example of the data structure of product information. It is a flowchart of flight reservation processing ((1) in FIG. 1). It is a flow chart of preparation processing. FIG. 10 is a diagram showing an example of an ordering screen displayed on the terminal 100 of a user 700 who purchases products on board. 4 is a flowchart of provisional settlement processing; It is an example of a screen requesting input of authentication information displayed on the terminal 100 . It is a figure which shows an example of the merchandise information after an update. It is a figure which shows an example of the passenger information after an update. 4 is a flowchart of authorization processing for payment information; It is a figure which shows an example of the passenger information after an update. FIG. 10 is a diagram showing a modified example of an order screen displayed on the terminal 100. FIG. FIG. 10 is a diagram showing a modified example of an order screen displayed on the terminal 100. FIG. FIG. 10 is a diagram showing a modified example of an order screen displayed on the terminal 100. FIG.

An embodiment of a payment system will be described below with reference to the drawings. In the following description, identical parts and components are given identical reference numerals. Their names and functions are also the same. Therefore, these descriptions will not be repeated.

[1. Explanation of the overview of the payment system]
FIG. 1 is a diagram schematically showing the configuration of a settlement system. As shown in FIG. 1, the settlement system includes a terminal 100, a reservation server 200, an onboard server 300, a check-in machine 400, a settlement service server 500, a payment server 510, and a product management server 600. including.

Terminal 100 is configured by a general-purpose information terminal such as a personal computer or a smart phone.

The reservation server 200 manages flights. The reservation server 200 may be operated by an airline company or by a travel agency. In FIG. 1, the information of each passenger's flight is indicated as "reservation information".

The in-flight server 300 is an example of an information processing device that performs processing related to payment without handling highly secure information such as credit card information. In-flight server 300, for example, when installed in an aircraft (hereinafter also simply referred to as “in-flight”), performs provisional settlement for purchases of products during the flight of the aircraft. After the aircraft lands, the in-flight server 300 requests authorization of the provisional payment from the entity that executes the payment, such as a credit card company, by communicating with the external device.

The check-in machine 400 outputs a boarding pass based on the reservation information.
When the payment service server 500 receives payment information such as credit card information from the user, it issues a token corresponding to the payment information to the user. In one implementation, the token is a string of characters generated, such as by encrypting credit card information. The payment server 510 is operated by an entity such as a credit card company that executes credit settlement. In the payment system of FIG. 1, the payment agency service server 500 and the payment server 510 are used for so-called "token payment".

Merchandise management server 600 manages information on merchandise for which on-board server 300 is subject to settlement.

FIG. 1 shows the flow of processing performed between elements in the order of steps (1) to (18). With reference to FIG. 1, the flow of processing in the settlement system will be schematically described.

Step (1) Flight Reservation The user 700 accesses the reservation server 200 using the terminal 100 and reserves a flight. FIG. 2 is a diagram showing an example of a screen displayed on the terminal 100 when making a flight reservation. Screen 20 in FIG. 2 is displayed on the display of terminal 100, for example, when the processor of terminal 100 executes a given application.

In the screen 20 of FIG. 2, a column 21 shows information such as the flight number of the flight. A column 22 shows information for designating a seat after change. A column 23 shows information for registering whether or not payment should be made on board. The necessity can be switched by clicking the software button 23A, for example. Information displayed on the screen 20 is appropriately updated by operating the input device of the terminal 100 . The software button 24 is operated to confirm the flight reservation information displayed on the screen 20 . The confirmed reservation information is transmitted to the reservation server 200 .

Step (2) Token Request When the user needs to make an in-flight payment for a reserved flight, the user 700 is requested to enter a token corresponding to credit card information. The token input request may be made by the reservation application on the terminal 100 or by the reservation server 200 .

Step (3) Send Payment Information When a token is requested, user 700 uses terminal 100 to send payment information (for example, credit card information) to payment service server 500 .

Step (4) Token Issuance The server for payment agency service 500 issues a token to the terminal 100 using the payment information received from the terminal 100 .

Step (5) Token transmission The terminal 100 transmits the token received from the payment agency service server 500 to the reservation server 200 . As a result, the reservation server 200 associates the flight reservation information with the token and stores them in the storage device. Note that when a user registers information that does not require in-flight payment for a flight reservation, a token may not be associated with the flight reservation information.

Step (6) Transmission of reservation number When the flight reservation is completed, the reservation server transmits the reservation number to the terminal 100 .

Step (7) Downloading Extracted Reservation Information Passenger information of the flight on which the in-flight server 300 is installed is downloaded from the reservation server 200 to the in-flight server 300 . For example, when the flight number of the flight on which the in-flight server 300 is installed is input, the reservation server 200 extracts the passenger information of the corresponding flight from the reservation information. The reservation server 200 downloads the extracted information to the in-flight server 300 as passenger information. As the passenger information, only the token registered passengers among the passengers of the flight may be extracted.

Step (8) Product Information Downloading Product information to be sold in-flight is extracted from the product information registered in the product management server 600 and downloaded to the in-flight server 300 . For example, upon receiving an input of a flight number of a flight on which on-board server 300 is loaded, product management server 600 extracts product information based on the flight number. The selection of products may be extracted according to destination and/or estimated time of arrival. Product management server 600 downloads the extracted product information to onboard server 300 .

An example of a product is an in-flight meal. Other examples are articles such as towels and key chains. Yet another example is a seat change on an airplane. Yet another example is the modification of information on a computer, such as a web reservation, without the issuance of tangible transportation, event, or accommodation tickets (tickets, entrance tickets, or accommodation tickets) ).

In-flight server 300 may not be able to communicate with product management server 600 during flight. For such a case, the above products, such as so-called "last minute" event tickets or lodging services, are intended to be sold out onboard the aircraft on which the in-flight server 300 is installed, It may not be intended for sale off-aircraft.

Steps (9) to (12) Input Reservation Number to Boarding Pass Output The user 700 inputs the reservation number to the check-in machine 400 (step (9)). The check-in machine 400 queries the reservation server 200 for the entered reservation number (step (10)). The reservation server 200 transmits reservation information corresponding to the inquired reservation number to the check-in machine 400 (step (11)). The check-in machine 400 outputs a boarding pass corresponding to the reservation number transmitted from the reservation server 200 (step (12)).

FIG. 3 is a diagram showing an example of a scene where a user 700 stands in front of a check-in machine 400 to output a boarding pass. FIG. 3 shows an example of a boarding pass output from the check-in machine 400, enlarged to the left.

The check-in machine 400 includes a touch monitor 440 , a boarding pass printer 432 and a two-dimensional code scanner 433 . Touch monitor 440 includes a touch panel 441 and a display 442 . User 700 inputs a reservation number on touch panel 441 . The reservation number may be provided graphically, such as a barcode or two-dimensional code, and user 700 may enter the reservation number into two-dimensional code scanner 433 . The check-in machine 400 outputs a boarding pass corresponding to the boarding pass corresponding to the input reservation number from the boarding pass printer 432 . When the reservation number is provided as a two-dimensional code, the type of code employed is not limited to that described in FIG. 3, and may be another type such as a QR (registered trademark) code.

The boarding pass 30 describes various information related to the reservation of the user 700 . On the boarding pass 30, the two-dimensional code represents the reservation number and/or information related to the reservation number. The boarding pass 30 further includes flight number, departure time, boarding gate, seat number, date of departure, reservation number, and name of the person making the reservation.

The boarding pass 30 may include a field for displaying a message according to the passenger information, such as a message "Happy Birthday!" for passengers whose birthday coincides with one or more dates on the boarding pass. Also, the boarding pass 30 may include an advertising space. Advertisements displayed in the advertisement column may be selected according to passenger information.

Steps (13) to (15) Order, Authentication Request, Preliminary Settlement User 700 outputs a product order and authentication request to in-flight server 300 on the plane. FIG. 4 is a diagram showing an example of a scene in which a user 700 uses the terminal 100 to order products on board an airplane. As shown in FIG. 4, a user 700 operates a terminal 100 on a seat in an airplane. Terminal 100 communicates with onboard server 300 via repeater 800 .

In one implementation, upon receiving an access from the terminal 100, the terminal 100 is provided with a product purchase web page. The user 700 inputs a product order to the terminal 100 on the web page. The order is sent to onboard server 300 . Upon receiving the order, the in-flight server 300 requests the terminal 100 to input information for authenticating the passenger (authentication information). In response to the request, the terminal 100 displays a message prompting the user to enter authentication information.

In response to the message, user 700 uses terminal 100 to send authentication information to on-board server 300 , thereby requesting on-board server 300 for authentication. An example of information for authentication is a reservation number and an email address.

In-flight server 300 authenticates user 700 by matching the authentication information input by user 700 with the passenger information in in-flight server 300 .

When the user 700 is successfully authenticated, the on-board server 300 temporarily settles the order. In other words, the on-board server 300 performs the payment only at the on-board server 300 without final payment at the payment server 510 . In one implementation, the onboard server 300 updates the merchandise information and passenger information described below according to the order. In-flight server 300 may execute processing for providing products to users (passengers) according to orders. An example of the processing is to display to the flight attendant an instruction to provide a product to the user (passenger). The instruction is displayed, for example, on a terminal carried by the flight attendant and/or on a monitor for the flight attendant.

Step (16) to Step (17) Authorization Request The on-board server 300 requests the provisional payment authorization by transmitting the token and the amount of the provisional payment to the payment agency service server 500 .

FIG. 5 is a diagram schematically showing a scene in which an aircraft with on-board server 300 has landed at an airport. In the example of FIG. 5, on-board server 300 is located on board aircraft 900 . In one implementation, the onboard server 300, as shown in FIG. The server 500 is requested to authorize provisional settlement.

In response to a request from the on-board server 300, the payment agency service server 500 extracts the payment information used at the time of token issuance transmitted from the on-board server 300, and sends the payment information and the amount to the payment server. 510, the payment server 510 is requested to authorize provisional settlement.

(18)-(19) Transmission of Authorization Result The payment server 510 authorizes the provisional payment based on the payment information and the amount, and sends the result (success/failure) to the payment agency service server 500. Send. The settlement agent service server 500 transmits the result received from the payment server 510 to the on-board server 300 .

(20) Post-Processing On-board server 300 performs post-processing for the provisional payment according to the result of the provisional payment authorization.

An example of post processing is to display on a given monitor information for instructing flight attendants to provide products that have not yet been provided to users (passengers) when the result is successful. be.

Another example is registering with an external server additional information for providing goods to passengers if the result is successful. For example, if a towel and a key ring are ordered on board and the authorization for provisional payment of the order is successful, the on-board server 300 sends information instructing delivery of the towel and key ring to the address registered for the passenger. Send to the server that manages shipping.

Yet another example is sending passenger information as event participant information or hotel guest information to an external server if the result is successful.

Yet another example is to instruct the flight attendants to request the return of the goods already to the passenger if the result is unsuccessful.

Yet another example may be to output an alert if the result is a failure and the authorization result from payment server 510 is accompanied by information regarding credit card fraud. If the onboard server 300 receives an authorization result after the aircraft has landed and before the "doors open", it may output the above alert to a server administered by an appropriate authority such as the airport police. As a result, when a user (passenger) who attempts to use credit card information illegally exits the aircraft, the body can be securely secured by the institution.

[2. Hardware configuration]
The hardware configuration of the devices constituting the settlement system will be described below with reference to FIGS. 6 to 9. FIG.

(Terminal 100)
FIG. 6 is a diagram showing an example of a hardware configuration of terminal 100. As shown in FIG. As shown in FIG. 6, the terminal 100 includes a processor 101, a RAM (Random Access Memory) 102, a storage device 103, a microphone 104, a speaker 105, a display 106, an input device 107, It has a communication interface 108 , a camera 109 and a near field communication interface 110 . Each element in terminal 100 is connected to each other by an internal bus. The processor 101 is composed of at least one CPU (Central Processing Unit), at least one ASIC (Application Specific Integrated Circuit), at least one FPGA (Field-Programmable Gate Array), or a combination thereof.

The RAM 102 functions as a work area when the processor 101 executes processing. Storage device 103 is realized by, for example, a flash memory, and non-temporarily stores programs (including application programs) executed by processor 101 and data used for executing the programs.

Microphone 104 outputs a signal corresponding to the input voice to processor 101 . Speaker 105 outputs sound according to the signal output from processor 101 . A display 106 displays an image showing the processing result of the program executed by the processor 101 . The input device 107 receives input operations on the terminal 100 . Input devices 107 are, for example, hardware buttons and/or touch sensors located on display 106 .

Communication interface 108 is implemented by, for example, a network card. Processor 101 transmits and receives data to and from other devices via communication interface 108 . The camera 109 includes a CMOS (Complementary Metal-Oxide Semiconductor) image sensor or the like, captures an image, and outputs the captured image to the processor 101 . The short-range communication interface 110 allows the terminal 100 to communicate with other devices in accordance with a short-range communication standard such as Bluetooth (registered trademark).

(Reservation server 200)
FIG. 7 is a diagram showing an example of the hardware configuration of the reservation server 200. As shown in FIG. As shown in FIG. 7, reservation server 200 includes processor 201 , communication interface 203 , and storage device 205 . Processor 201 uses communication interface 203 to transmit and receive information to and from other devices such as on-board server 300 . Processor 201 is implemented, for example, by at least one CPU.

The storage device 205 is implemented by, for example, a hard disk, SSD (Solid State Drive), or the like, but is not limited to this. Storage device 205 includes a program storage area 260 and a data storage area 270 . The program storage area 260 non-temporarily stores programs executed by the processor 201 . The program executed by processor 201 may be stored in a recording medium that is detachable from or separate from the main body of reservation server 200 . Storage device 205 includes RAM that functions as a work area for processor 201 to execute programs. The data storage area 270 stores various data including reservation information.

(In-flight server 300)
FIG. 8 is a diagram showing an example of the hardware configuration of on-board server 300. As shown in FIG. As shown in FIG. 8 , onboard server 300 includes processor 301 , communication interface 303 , and storage device 305 . Processor 301 uses communication interface 303 to transmit and receive information with reservation server 200 , product management server 600 , and other devices such as terminal 100 . Transmission and reception of information to and from other devices may be accomplished via a repeater (such as repeater 800 in FIG. 4). Processor 301 is implemented, for example, by at least one CPU.

The storage device 305 is implemented by, for example, a hard disk, SSD, or the like, but is not limited to this. Storage device 305 includes program storage area 360 and data storage area 270 . The program storage area 360 non-temporarily stores programs executed by the processor 301 . The program executed by processor 301 may be stored in a recording medium that is detachable from or separate from the main body of on-board server 300 . Storage device 305 includes RAM that functions as a work area for processor 301 to execute programs. Data storage area 370 stores various data including passenger information and product information.

Onboard server 300 may be configured to be detachable from an aircraft. For example, when part of the communication with reservation server 200 and/or product management server 600 is performed, onboard server 300 may be located outside the aircraft and connected to a telephone line by wire. In this sense, the on-board server 300 may have a sensor for detecting whether it is attached to the aircraft.

(Check-in machine 400)
FIG. 9 is a diagram showing an example of the hardware configuration of the check-in machine 400. As shown in FIG. As shown in FIG. 9, check-in machine 400 includes processor 401 , communication interface 403 and storage device 405 . Processor 401 uses communication interface 403 to send and receive information to and from other devices such as reservation server 200 . Processor 401 is implemented, for example, by at least one CPU.

The storage device 405 is implemented by, for example, a hard disk, SSD, or the like, but is not limited to this. Storage device 405 includes program storage area 360 and data storage area 270 . The program storage area 360 non-temporarily stores programs executed by the processor 401 . A program executed by the processor 401 may be stored in a recording medium that is detachable from or separate from the body of the check-in machine 400 .

As described with reference to FIG. 3, check-in machine 400 includes touch monitor 440 , boarding pass printer 432 and two-dimensional code scanner 433 . Touch monitor 440 includes a touch panel 441 and a display 442 . The touch panel 441 can be implemented by any touch sensor such as a capacitive touch sensor. The display 442 is superimposed on the touch panel 441 and can be realized by any display such as a liquid crystal display and/or an organic EL (Electro Luminescence) display.

The boarding pass printer 432 prints information on a recording paper and outputs the recording paper as a boarding pass. Two-dimensional code scanner 433 outputs the read image to processor 401 .

[3. data structure]
An example of the data configuration of reservation information, passenger information, and product information will be described with reference to FIGS. 10 and 11. FIG.

(reservation information and passenger information)
FIG. 10 is a diagram schematically showing an example of the data structure of reservation information and passenger information. As shown in the upper part of FIG. 10, the reservation information includes information regarding dates, flight numbers, passenger names, email addresses, reservation numbers, seat numbers, and tokens. In FIG. 10, each user's token is schematically indicated by a character string composed of five characters such as "TK001". The reservation information managed by reservation server 200 may include information for each passenger on two or more flights.

As shown in the lower part of FIG. 10, the passenger information is configured by extracting, from the reservation information, information on passengers on flights on which the in-flight server 300 is installed. In the example of FIG. 10, the passenger information is a passenger on a flight with flight number MM225 on April 27, 2019 from the contents stored in the reservation information, and it is registered that in-flight payment is required. It is extracted from the information of the passengers who are

Processor 301 generates passenger information when reservation information is downloaded from reservation server 200 to onboard server 300 . In passenger information, payment information is further defined for each passenger. The payment information includes three items (amount, product ID, and authorization result). The amount represents the amount provisionally settled for the passenger. The product ID indicates the product purchased by provisional payment. The authorization result indicates the result of authorization by the payment server 510 for the provisional payment. The value of each item can be updated as appropriate after passenger information is generated.

(product information)
FIG. 11 is a diagram showing an example of the data configuration of product information. The product information includes four items (product ID, product name, price, and remaining quantity). The product ID represents an ID assigned to the product. The product name represents the name of the product. The price represents the price of the product. The remaining quantity represents the quantity of products that can be sold. For example, in the example of FIG. 11, there are 20 remaining products with the product name “mackerel curry”. This means that the quantity of the product that can be sold onboard is 20 meals. The value of each item can be updated as appropriate after passenger information is generated.

[4. Process flow]
Next, four processes (“flight reservation processing”, “preparation processing”, “temporary payment processing”, and “payment information authorization processing”) in the payment system will be described with reference to FIGS. 12 to 20. FIG.

(Flight reservation processing)
FIG. 12 is a flowchart of flight reservation processing ((1) in FIG. 1). In one implementation, the flight reservation process is implemented by processor 201 of reservation server 200 executing a given program. The flight reservation process is a process for accepting information registered as reservation information.

At step S10, the processor 201 determines whether or not information required for flight reservation has been input to the terminal 100. FIG. Information required to book a flight includes, for example, the passenger's name and email address. When processor 201 determines that the information has not been input (NO at step S10), processor 201 waits for a certain period of time, executes the process of step S10 again, and determines that the information has been input (YES at step S10). , the control proceeds to step S20.

At step S20, the processor 201 registers the input information in the reservation information (FIG. 10). The processor 201 refers to the vacant seat information according to a known technique, and registers the input information in the reservation information on condition that the flight reservation corresponding to the input information is possible. Further, the processor 201 may register the input information in the reservation information as a condition that the payment for the flight reservation has been confirmed.

In step S30, the processor 201 determines whether or not the information input by the user (passenger) for the flight to be processed requires in-flight payment. If the processor determines that the input information requires in-flight payment (YES at step S30), the process proceeds to step S40, otherwise (NO at step S30), the process proceeds to step S60. Advance control.

At step S40, the processor 201 requests the user for a token corresponding to the payment information. In one implementation, the processor 201 sends a message to the terminal 100 operated by the user requesting entry of a token. The processor 201 may further transmit, to the terminal 100, a description of the token acquisition method and/or information on the access destination for acquiring the token. In response to this, the user acquires a token using terminal 100 and transmits it to reservation server 200 .

At step S50, the processor 201 registers the token transmitted from the terminal 100 in the reservation information.

In step S60, processor 201 assigns a new reservation number to the reservation registered in accordance with the information input in steps S10 to S50, registers the reservation number in the reservation information, and sends the reservation information to terminal 100. Send. After that, the processor 201 ends the processing of FIG.

In the flight reservation process described above with reference to FIG. 12, when the flight reservation includes information requiring in-flight payment, a token corresponding to the payment information of the user who reserved the flight is additionally registered.

Note that the flight reservation process may be implemented as a process of a reservation application stored in the terminal 100 . In this case, the processor 101 of the terminal 100 transmits the information and token required for the reservation information to the reservation server 200 in steps S20 and S50. In response to this, the processor 201 registers the information transmitted from the terminal 100 in the reservation information.

(Preparation processing)
FIG. 13 is a flow chart of preparation processing. The preparatory processing consists of downloading reservation information (passenger information) to the on-board server 300, indicated by (7) in FIG. 1, and downloading product information to the on-board server 300, indicated by (8) in FIG. This is processing for downloading. In one implementation, the preparatory process is implemented by processor 301 of onboard server 300 executing a given program.

At step S100, the processor 301 requests the reservation server 200 for passenger information. The request may be accompanied by information identifying the date and flight number of the flight on which onboard server 300 including processor 301 is on board. The processor 201 of the reservation server 200 extracts, from the reservation information, information associated with the date and flight number of the flight on which the in-flight server 300 is installed, and further associated with the passenger requiring in-flight payment, and sends the information to the in-flight server. 300.

At step S<b>110 , processor 301 stores the passenger information transmitted from reservation server 200 in storage device 305 .

In step S120, processor 301 requests product information from product management server 600. FIG. In one implementation, the product management server 600 registers product information for each flight. Merchandise management server 600 , in response to a request from in-flight server 300 , transmits to in-flight server 300 merchandise information associated with a flight on which in-flight server 300 is installed.

In step S<b>130 , processor 301 stores the product information transmitted from product management server 600 in storage device 305 . After that, the processor 301 terminates the processing of FIG.

The preparation processing described above corresponds to processing for in-flight server 300 to pull reservation information (passenger information) and product information from reservation server 200 and product management server 600, respectively. By pushing reservation information (passenger information) and product information from reservation server 200 and product management server 600 to in-flight server 300, reservation information (passenger information) and product information are sent to in-flight server 300. may be registered.

(Provisional payment processing)
The provisional settlement process will be described with reference to FIGS. 14 to 17. FIG. FIG. 14 is a diagram showing an example of an order screen displayed on the terminal 100 of the user 700 who purchases products onboard. FIG. 15 is a flowchart of provisional settlement processing. FIG. 16 is an example of a screen displayed on the terminal 100 requesting input of information for authentication. FIG. 17 is a diagram illustrating an example of updated product information.

As shown in FIG. 14, the screen 1400 includes a field 1401 for displaying the product name, a field 1403 for displaying the quantity of the product, and a button 1405 for confirming purchase of the product. The quantity of items to order can be changed by touching the upper or lower triangle in field 1403 . In one implementation, the provisional payment process is started in response to transmission of information indicating that button 1405 has been operated from terminal 100 to on-board server 300 . In one implementation, the provisional payment process is implemented by processor 301 of on-board server 300 executing a given program. “Temporary” means that the provisional settlement process is not a settlement at payment server 510 but a process for reserving settlement at payment server 510 . In one implementation, the pre-payment process is a process of obtaining an on-board order for user 700 during the flight of an aircraft on which on-board server 300 is installed.

Referring to FIG. 15, processor 301 acquires an order corresponding to button 1405 from terminal 100 at step S200. More specifically, the processor 301 determines that the order corresponding to the button 1405 means the order for the product displayed on the screen 1400 including the button 1405 .

In step S210, processor 301 requests terminal 100 for authentication information. In response to the request, terminal 100 displays a screen requesting user 700 to enter authentication information.

Here, referring to FIG. 16, screen 1600 includes areas 1601 and 1602 . Area 1601 accepts input of information for authentication. Information for authentication includes a reservation number and an e-mail address. Your booking number is printed on your boarding pass. Therefore, user 700 can enter the reservation number in area 1601 by referring to the boarding pass. Area 1602 displays the price of the product to be purchased, that is, the price to be settled in payment server 510 in the future.

Screen 1600 includes a send button 1603 . In response to touch of send button 1603 , terminal 100 sends authentication information to on-board server 300 in area 1601 .

Referring to FIG. 15 again, processor 301 acquires authentication information transmitted from terminal 100 in step S220.

In step S230, processor 301 determines whether or not the authentication information acquired in step S220 is correct. In one implementation, the processor 301 determines that the authentication information (combination of reservation number and email address) acquired in step S220 is correct if it matches the information registered in the passenger information, If they do not match, they are determined to be incorrect. When processor 301 determines that the authentication information acquired in step S220 is correct, processor 301 advances control to step S240 (YES in step S230), and advances control to step S260 when processor 301 determines that it is incorrect (step S230). NO).

In step S240, processor 301 updates product information for the ordered product (product displayed in area 1602). Here, referring to FIG. 17, when the product "mackerel curry" is purchased in quantity 1, the product information shown in FIG. 11 is updated as shown in FIG. In FIG. 17, compared to FIG. 11, the remaining number of the product "mackerel curry" is reduced by 1 (20→19).

Referring to FIG. 15 again, in step S250, processor 301 updates passenger information so that payment information based on the ordered product is registered in user 700's passenger information. After that, the processor 301 terminates the processing of FIG. 15 .

FIG. 18 is a diagram showing an example of updated passenger information. For example, if the product "mackerel curry" is ordered in quantity 1, the passenger information shown in FIG. 10 is updated as shown in FIG. In FIG. 18, compared to FIG. 10, in the payment information for the name "TARO YAMADA", the value in the amount column is increased by 800 yen for the product name "mackerel curry", and the product ID column shows the product name "mackerel curry". Curry” product ID (00100) is added. In the example of FIG. 18, the settlement by the payment server 510 for the order has not been completed, so "not completed" is registered as the value of "authorization result".

The processor 301 can determine whether or not an order can be placed by referring to the numerical value of the remaining number of product information. For example, assume that 20 pieces of "mackerel curry" are to be ordered when the product information is in the state shown in FIG. The order quantity (20) exceeds the remaining quantity (19). Therefore, processor 301 determines that the order is not possible. In such a case, the processor 301 may execute step S260 without executing step S210 at the start of FIG. 15 to end the process of FIG.

The processor 301 may perform control for providing merchandise to passengers along with updating merchandise information in step S240. An example of control for providing merchandise to passengers is displaying information instructing the provision of merchandise to passengers on a display visible to flight attendants. In one implementation, the display includes the message "Please provide quantity '1' of product 'mackerel curry' to customer seat number '23F'."

According to the provisional settlement process described above, the product information is updated according to the order without waiting for the final settlement by the payment server 510 . In addition, in the payment information authorization processing described below, if the result of the payment authorization for the order is "failed", the processor 301 may restore the product information, or the product information has already been processed. If merchandise has been provided to the passenger, the flight attendant may be instructed to request the return of the merchandise to the passenger.

(Authorization processing of payment information)
FIG. 19 is a flow chart of authorization processing for payment information. In one implementation, the payment information authorization process is implemented by processor 301 of onboard server 300 executing a given program. In one implementation, the processor 301 initiates the authorization process for payment information upon landing of the aircraft on which the onboard server 300 is installed and connectivity to the ground network.

In step S300, the processor 301 attempts to access the payment agency service server 500, and determines whether or not the access was successful. When processor 301 determines that the access has failed (NO in step S300), processor 301 executes step S300 again after a certain interval until a predetermined timeout limit. When processor 301 determines that the access has succeeded (YES in step S300), the control proceeds to step S310.

In step S310, the processor 301 identifies passengers whose payment information is registered in the passenger information. Registering the payment information means that the numerical value in the amount column in the payment information is other than 0 yen. In the example of FIG. 18, the numerical value in the column of the amount of money for the passenger with the name "TARO YAMADA" is 800 yen, and the numerical value in the column of the amount of money for the passenger with the name "HANAKO SUZUKI" is 0 yen. In this case, it is determined that the passenger with the name "HANAKO SUZUKI" has no payment information registered. That is, in step S310, the passenger whose name is "TARO YAMADA" is identified as the passenger whose payment information is registered.

At step S320, processor 301 transmits a request for authorization for the passenger identified at step S310 to server for payment agency service 500. FIG. The request includes the amount and token of payment information for the passenger. In response to the request, the payment agency service server 500 replaces the transmitted token with payment information corresponding to the token. After that, the settlement agent service server 500 transmits the settlement information and the transmitted amount to the payment server 510 . As a result, the payment server 510 is requested to authorize payment for the passenger. The payment server 510 transmits the authorization result to the payment agency service server 500 . The settlement agent service server 500 transmits the result to the on-board server 300 .

In step S<b>330 , processor 301 receives the authorization result transmitted from server for payment agency service 500 .

At step S340, the processor 301 registers the authorization result in the passenger information. FIG. 20 is a diagram showing an example of updated passenger information. In comparison with FIG. 18, in FIG. 20, the value "success" is registered in the authorization result column for the name "TARO YAMADA".

Returning to FIG. 19, post-processing is performed in step S350. The control in step S350 corresponds to "(20) post-processing" in FIG. An example of post-processing is to instruct the flight attendants to provide products that have not yet been provided to the user (passenger) if the result is "success". As post-processing, the passenger information may be transmitted to an external device such as the reservation server 200 or the like. Thereby, the purchase history of the user's products can be managed in the external device. Another example is to restore the product information (for example, restore the value of the "remaining quantity" that was reduced in the provisional payment process) when the result is "failure". After that, the processor 301 terminates the processing of FIG.

[5. Variations of products sold on board]
21 to 23 are diagrams showing modified examples of the order screen displayed on the terminal 100. FIG.

(seat change)
Screen 2100 of FIG. 21 is a screen for the passenger to purchase a new seat assignment in order to change the seat number assigned to the passenger. The screen 2100 includes a column 2101 for displaying selectable seat numbers, a column 2103 for displaying the seat numbers to be ordered, and a button 2105 for confirming the order. In one implementation, upon receiving information indicating that button 2105 has been operated from terminal 100, processor 301 of on-board server 300 initiates provisional payment processing.

Processor 301 may transmit to terminal 100 information specifying the selectable seat numbers displayed in field 2103 . More specifically, the processor 301 may extract the purchased seat number on the target flight from the reservation information (FIG. 10), and select a seat number other than the purchased seat number. In-flight server 300 may be instructed to display it as a seat number. If the weight is balanced for each block in the aircraft, the processor 301 provides the terminal 100 with the blocks already assigned to the passenger as the "selectable seat numbers" displayed for the passenger. It may be instructed to display only the seat numbers within the same block.

A column 2101 in FIG. 21 shows four types of seats (fast seat, smart seat, pleasure seat, standard seat), and the seat type is assigned to each seat number. The amount required for seat selection differs depending on the type of seat.

In the example of FIG. 21, the processor 301 notifies the terminal 100 of the new seat number along with updating the product information in the provisional payment process (step S240). Processor 301 also changes the passenger's seat number to the new seat number in the passenger information.

(Event after disembarkation)
Screen 2200 in FIG. 22 is a screen for the passenger to purchase the right to participate in the event after disembarkation. The screen 2200 includes a column 2201 for displaying event information, a column 2103 for displaying the content and amount of the event, and a button 2205 for deciding to purchase the right. In one implementation, upon receiving information indicating that button 2205 has been operated from terminal 100, processor 301 of on-board server 300 initiates provisional payment processing.

In the example of FIG. 22, when the provisional payment authorization by the payment server 510 succeeds, the processor 301 of the on-board server 300 transmits information about the passenger as an event participant to the device that manages event participants.

Similarly, on board, the right to stay in a hotel can be sold. After completion of the provisional payment processing for hotel accommodation, when the payment server 510 successfully authorizes the provisional payment, the processor 301 of the in-flight server 300 sends passenger information as a guest to the device for managing hotel guests. Send.

(Means of transportation after disembarking)
A screen 2300 in FIG. 23 is a screen for the passenger to purchase a ticket for transportation after getting off the plane. The screen 2300 includes a field 2301 for displaying an overview of the means of transportation, a field 2303 for displaying specific contents and prices of the means of transportation, and a button 2305 for deciding to purchase a ticket. In one implementation, processor 301 of on-board server 300 initiates provisional payment processing upon receiving information from terminal 100 indicating that button 2305 has been operated.

When the preliminary payment is completed, the processor 301 displays an instruction to provide the ticket to the passenger on a display visible to the cabin crew.

[6. Other Modifications]
A payment using a “token payment” described in this disclosure is an example of a payment mode in a payment system. When payment using "token payment" is adopted, the business operator operating the on-board server 300 is authenticated as an institution for handling credit card information (for example, PCI-DSS (Payment Card Industry Data Security Standard) authentication). ) is not required. On the other hand, the settlement agent service server 500 may be omitted in the settlement system. That is, credit card information may be input (registered) in on-board server 300 instead of the token. Onboard server 300 may directly request payment authorization from payment server 510 using credit card information.

The boarding pass does not have to be output as a tangible object such as paper. In another implementation, the check-in machine 400 may transmit the information necessary to output the boarding pass to the terminal 100 when the reservation number is entered. Thereby, the terminal 100 can display information corresponding to the boarding pass 30 . The user 700 may present a display of information corresponding to the boarding pass 30 to the attendant at the boarding gate.

For ordering and/or inputting information for authentication to the in-flight server 300, a terminal (in-flight terminal) installed in the plane may be used instead of the terminal 100 brought into the plane by the user. The terminal may be communicably connected to on-board server 300 by wire or wirelessly. A communication format is not particularly limited. The input of information for authentication may be realized by inputting a figure such as a two-dimensional code instead of inputting the numerical value of the reservation number. Graphic input is realized by, for example, user 700 photographing the two-dimensional code of boarding pass 30 with camera 109 .

In the present disclosure, a boarding pass that the passenger is sure to have with them for boarding is used to authenticate the passenger. Information for authentication may be anything other than "combination of reservation number and email address". The authentication information may be, for example, reservation information only, seat number, passenger name, or two-dimensional code written on the boarding pass. Alternatively, it may be a sequence number (a number assigned in order of check-in for each flight) or a ticket number (so-called "e-ticket number" or airline ticket number).

The "e-mail address" in the authentication information is an example of information that is not written on the boarding pass. Security of passenger authentication can be improved by using not only information written on the boarding pass but also information not written on the boarding pass for passenger authentication. That is, even if a third party obtains a boarding pass, it is possible to avoid a situation in which the third party is authenticated as the original passenger based only on the information written on the boarding pass.

In the present disclosure, the user 700 (passenger) can use the terminal 100 to purchase merchandise on the plane without having to talk directly to the cabin crew. As a result, passengers can purchase products more easily, and the willingness to purchase products can be improved for passengers such as those seated by the window, who are conscious of the passengers sitting next to them and find it difficult to talk to the cabin crew. .

The location of passenger authentication using a boarding pass is not limited to the cabin. It may be a shop in an airport, a bus or train boarded by passengers after arrival, or a shop in town visited by passengers (users) after arrival. In this case, the server in the shop, in the car, or in the store functions as the "in-flight server 300".

Each embodiment disclosed this time should be considered as an illustration and not restrictive in all respects. The scope of the present invention is indicated by the scope of the claims rather than the above description, and is intended to include all modifications within the scope and meaning equivalent to the scope of the claims. In addition, the inventions described in the embodiments and modifications are intended to be implemented either singly or in combination as much as possible.

30 Boarding pass 100 Terminal 200 Reservation server 300 In-flight server 400 Check-in machine 432 Boarding pass printer 433 Dimensional code scanner 440 Touch monitor 441 Touch panel 500 Settlement service server 510 Payment server 600 Merchandise management server, 700 users, 800 repeaters, 900 aircraft.

Claims (9)

A computer-implemented payment method comprising:
obtaining an order from a passenger;
obtaining information for authentication entered by the passenger;
a step of authenticating the passenger by comparing the information for authentication with passenger information which is information registered in advance about the passenger and which is information described in a boarding pass issued to the passenger; ,
registering payment information related to the order in the passenger information if the authentication is successful ;
obtaining a token for the passenger issued by an external device in association with passenger information;
a step of executing payment based on the payment information with the external device;
The payment method, wherein the step of executing payment based on the payment information includes requesting the external device for payment authorization based on the payment information using the token. 2. The settlement method according to claim 1, wherein said passenger information includes at least one of reservation number, seat number and passenger name. 3. The payment method according to claim 1, wherein the passenger information is written on the boarding pass as a machine-readable code. The passenger information further includes information that is pre-registered for the passenger and is not described in the boarding pass,
2. The step of authenticating the passenger includes collating the information for authentication with a combination of information written on the boarding pass and information not written on the boarding pass in the passenger information. The settlement method according to any one of claims 1 to 3. The payment method according to any one of claims 1 to 4, further comprising a step of updating product information based on the order regardless of whether or not the payment authorization is approved by the external device. 6. The payment method according to claim 5 , further comprising the step of undoing the update of the product information based on the order if the external device denies the authorization of the payment. The computer is installed in the aircraft of the flight pertaining to the boarding pass,
obtaining the order is performed while the aircraft is in flight;
The payment method according to any one of claims 1 to 6 , wherein requesting the external device for payment authorization based on the payment information is executed after the aircraft lands. The settlement method according to any one of claims 1 to 7 , wherein the order includes an order for goods on board the flight related to the boarding pass. 9. The merchandise comprises at least one of merchandise sold onboard the flight's aircraft, seat changes on the flight's aircraft, and tickets for transportation, events, or lodging after disembarkation. Payment method described in.

Images