JP7305420B2 - 決済方法 - Google Patents

Description

本開示は、搭乗券を発行された乗客のための決済に関する。

従来、商品またはサービスの購入だけでなく、公共料金の支払いなどのさまざまな局面において、クレジットカードによる決済が実施されている。クレジットカードによる決済は、現金の持ち歩きを必要としないことから、ユーザにとって便利なものと言える。クレジットカードによる決済については、種々の技術が提案されている。たとえば、特開平０６－１７６２４９号公報（特許文献１）は、クレジットカードから読み取られたクレジットカード情報を利用してクレジットカードの有効性を問い合わせるための技術を開示する。

特開平０６－１７６２４９号公報

近年、クレジットカードを利用した決済の局面が増加している一方で、クレジットカード情報のスキミングなど、クレジットカード情報の盗難および悪用による被害も増加している。特に、航空機の乗客が商品の購入などで決済を行う場合、乗客は、搭乗券を管理しながら、現金やクレジットカードを管理する必要がある。このため、現金の紛失やクレジットカード情報の盗難などのリスクが高まることが予測される。したがって、リスクを低減する技術が必要とされている。

本開示は、係る実情に鑑み考え出されたものであり、その目的は、搭乗券を発行された乗客のリスクを低減するための技術を提供することである。

本開示のある局面に従うと、コンピュータによって実施される決済方法であって、乗客からの注文を取得するステップと、乗客から入力された認証用の情報を取得するステップと、認証用の情報と、乗客について予め登録された情報であって乗客に対して発行された搭乗券に記載された情報である乗客情報とを照合して、乗客を認証するステップと、認証が成功した場合に、注文に関する決済情報を乗客情報に登録するステップとを備える、決済方法が提供される。

乗客情報は、予約番号、座席番号、および、搭乗者名の中の少なくとも１つを含んでいてもよい。

乗客情報は、機械読み取り可能なコードとして搭乗券に記載されていてもよい。
乗客情報は、乗客について予め登録された情報であって搭乗券に記載されていない情報をさらに含んでいてもよい。乗客を認証するステップは、認証用の情報と、乗客情報における搭乗券に記載された情報および搭乗券に記載されていない情報の組合せとを照合することを含んでいてもよい。

方法は、外部機器との間で、決済情報に基づく決済を実行するステップをさらに備えていてもよい。

方法は、外部機器によって発行された乗客についてのトークンを取得するステップをさらに備えていてもよい。決済情報に基づく決済を実行するステップは、トークンを利用して、外部機器に対して決済情報に基づく決済のオーソリゼーションを要求することを含んでいてもよい。

方法は、注文に基づいて、外部機器による決済のオーソリゼーションの承認の有無に拘わらず、商品情報を更新するステップをさらに備えていてもよい。

方法は、外部機器が決済のオーソリゼーションを否認した場合に、注文に基づいた商品情報の更新を元に戻すステップをさらに備えていてもよい。

コンピュータは、搭乗券に係るフライトの航空機内に搭載されてもよい。注文を取得するステップは、航空機の飛行中に実行されてもよい。外部機器に対して決済情報に基づく決済のオーソリゼーションを要求することは、航空機の着陸後に実行されてもよい。

注文は、搭乗券に係るフライトの航空機内における商品の注文を含んでいてもよい。
商品は、フライトの航空機内で販売される物品、フライトの航空機内における座席変更、および、降機後の交通、イベント、もしくは宿泊のチケットの中の少なくとも１つを含んでいてもよい。

本開示の他の局面に従うと、上記決済方法をコンピュータに実行させる、プログラムが提供される。

本開示のさらに他の局面に従うと、上記プログラムを格納した記憶装置と、プログラムを実行する１以上のプロセッサとを含む、情報処理装置が提供される。

本開示のさらに他の局面に従うと、フライトの予約情報を管理する予約サーバと、予約サーバによって管理される予約情報に従ってフライトの搭乗券を発行するチェックイン機と、搭乗券に係る乗客からの注文を処理する情報処理装置とを備える、決済システムが提供される。情報処理装置は、上記プログラムを格納した記憶装置と、プログラムを実行する１以上のプロセッサとを含む。

本開示によれば、乗客から入力された認証用の情報が、乗客について予め登録された情報であって乗客に対して発行された搭乗券に記載された情報である乗客情報と照合されることによって、乗客が認証される。乗客の認証が成功した場合に、注文に関する決済情報が乗客情報に登録される。これにより、乗客は、搭乗券に記載された情報で認証され得るため、注文の際にクレジットカード情報を入力する必要がなく、これにより、注文の際の乗客のリスクが低減され得る。

決済システムの構成を概略的に示す図である。 フライト予約において端末１００に表示される画面の一例を示す図である。 搭乗券の出力のためにユーザ７００がチェックイン機４００の前に立っている場面の一例を示す図である。 ユーザ７００が機内で商品の注文などのために端末１００を使用する場面の一例を示す図である。 機内サーバ３００を搭載する航空機が空港に着陸した場面を模式的に示す図である。 端末１００のハードウェア構成の一例を示す図である。 予約サーバ２００のハードウェア構成の一例を示す図である。 機内サーバ３００のハードウェア構成の一例を示す図である。 チェックイン機４００のハードウェア構成の一例を示す図である。 予約情報および乗客情報のデータ構成の一例を模式的に示す図である。 商品情報のデータ構成の一例を示す図である。 フライト予約処理（図１の（１））のフローチャートである。 準備処理のフローチャートである。 機内で商品を購入するユーザ７００の端末１００に表示される、注文用の画面の一例を示す図である。 仮決済処理のフローチャートである。 端末１００において表示される、認証用の情報の入力を要求する画面の一例である。 更新後の商品情報の一例を示す図である。 更新後の乗客情報の一例を示す図である。 決済情報のオーソリゼーション処理のフローチャートである。 更新後の乗客情報の一例を示す図である。 端末１００に表示される注文用の画面の変形例を示す図である。 端末１００に表示される注文用の画面の変形例を示す図である。 端末１００に表示される注文用の画面の変形例を示す図である。

以下に、図面を参照しつつ、決済システムの一実施の形態について説明する。以下の説明では、同一の部品および構成要素には同一の符号を付してある。それらの名称および機能も同じである。したがって、これらの説明は繰り返さない。

［１．決済システムの概要の説明］
図１は、決済システムの構成を概略的に示す図である。図１に示されるように、決済システムは、端末１００と、予約サーバ２００と、機内サーバ３００と、チェックイン機４００と、決済代行サービス用サーバ５００と、ペイメント用サーバ５１０と、商品管理サーバ６００とを含む。

端末１００は、たとえばパーソナルコンピュータやスマートフォンなどの、汎用の情報端末によって構成される。

予約サーバ２００は、フライトを管理する。予約サーバ２００は、航空会社によって運営されてもよいし、旅行代理店によって運営されてもよい。図１では、各乗客のフライトの情報が「予約情報」として示される。

機内サーバ３００は、クレジットカード情報などのセキュリティの高い情報を扱うことなく、決済に関する処理を実施する、情報処理装置の一例である。機内サーバ３００は、たとえば航空機内（以下、単に「機内」ともいう）に搭載された場合、航空機の飛行中に商品の購入などについて仮決済を実施する。航空機の着陸後、機内サーバ３００は、外部機器と通信することにより、クレジットカード会社などの決済を実行する主体に対して上記仮決済のオーソリゼーションを要求する。

チェックイン機４００は、予約情報に基づいて搭乗券を出力する。
決済代行サービス用サーバ５００は、クレジットカード情報などの決済用情報をユーザから受信すると、ユーザに対し、当該決済用情報に対応するトークンを発行する。一実現例では、トークンは、クレジットカード情報の暗号化などによって生成された文字列である。ペイメント用サーバ５１０は、クレジットカード会社などの、クレジット決済を実行する主体によって運営される。図１の決済システムにおいて、決済代行サービス用サーバ５００とペイメント用サーバ５１０とは、いわゆる「トークン決済」に利用される。

商品管理サーバ６００は、機内サーバ３００の決済の対象となる商品の情報を管理する。

図１には、ステップ（１）～ステップ（１８）の順に、要素間で実施される処理の流れが示される。図１を参照して、決済システムにおける処理の流れを概略的に説明する。

ステップ（１）フライト予約
ユーザ７００は、端末１００を利用して予約サーバ２００にアクセスし、フライトを予約する。図２は、フライト予約において端末１００に表示される画面の一例を示す図である。図２の画面２０は、たとえば端末１００のプロセッサが所与のアプリケーションを実行することによって、端末１００のディスプレイに表示される。

図２の画面２０において、欄２１には、フライトの便名などの情報が示される。欄２２には、変更後の座席を指定する情報が示される。欄２３には、機内での決済の要否を登録するための情報が示される。要否は、たとえばソフトウェアボタン２３Ａをクリックすることによって切り替えられる。端末１００の入力装置が操作されることによって、画面２０に表示される情報が適宜更新される。ソフトウェアボタン２４は、画面２０に表示されたフライトの予約情報を確定させるために操作される。確定された予約情報は、予約サーバ２００へ送信される。

ステップ（２）トークン要求
予約されたフライトにおいてユーザが機内での決済を必要とする場合、ユーザ７００に対してクレジットカード情報に対応するトークンの入力が要求される。トークンの入力の要求は、端末１００上の予約用のアプリケーションが実施してもよいし、予約サーバ２００が実施してもよい。

ステップ（３）決済用情報を送信
トークンを要求されると、ユーザ７００は、端末１００を利用して、決済代行サービス用サーバ５００へ決済用情報（たとえば、クレジットカード情報）を送信する。

ステップ（４）トークン発行
決済代行サービス用サーバ５００は、端末１００から受信した決済用情報を用いて、端末１００に対してトークンを発行する。

ステップ（５）トークン送信
端末１００は、決済代行サービス用サーバ５００から受信したトークンを予約サーバ２００へ送信する。これにより、予約サーバ２００は、フライト予約の情報とトークンとを関連付けて、記憶装置に格納する。なお、フライト予約において、ユーザが機内での決済を必要としない情報を登録した場合には、フライト予約の情報にはトークンは関連付けられなくてもよい。

ステップ（６）予約番号送信
フライトの予約が完了すると、予約サーバは、端末１００へ予約番号を送信する。

ステップ（７）抽出された予約情報のダウンロード
機内サーバ３００には、予約サーバ２００から、当該機内サーバ３００が搭載されるフライトの乗客情報がダウンロードされる。一例では、機内サーバ３００が搭載されるフライトの便名を入力されると、予約サーバ２００は、予約情報の中から該当するフライトの乗客の情報を抽出する。予約サーバ２００は、抽出された情報を、乗客情報として、機内サーバ３００へダウンロードする。乗客情報として、フライトの乗客の中の、トークンを登録された乗客のみの情報が抽出されてもよい。

ステップ（８）商品情報のダウンロード
商品管理サーバ６００において登録される商品情報から、機内で販売される商品の情報が抽出されて、機内サーバ３００へダウンロードされる。一例では、機内サーバ３００が搭載されるフライトの便名の入力を受け付けると、商品管理サーバ６００は、便名に基づいて、商品の情報を抽出する。商品の抽出は、到着地および／または到着予定時刻に従って抽出されてもよい。商品管理サーバ６００は、抽出された商品情報を機内サーバ３００へダウンロードする。

商品の一例は、機内食である。他の例は、タオルやキーホルダーなどの物品である。さらに他の例は、機内の座席変更である。さらに他の例は、到着地における、交通手段、イベント、または、宿泊のチケット（有体物である乗車券や入場券や宿泊券の発券を伴わない、ウェブ予約のようなコンピュータ上での情報の変更も含む）である。

飛行中、機内サーバ３００は商品管理サーバ６００と通信できない場合があり得る。このような場合のために、上記商品は、いわゆる「ラストミニッツ」のイベントチケットまたは宿泊サービスなどの、機内サーバ３００が搭載される航空機の機内で売り切られることを目的としたものであって、航空機外で販売されることが意図されていないものであってもよい。

ステップ（９）～ステップ（１２）予約番号の入力～搭乗券出力
ユーザ７００は、チェックイン機４００に予約番号を入力する（ステップ（９））。チェックイン機４００は、入力された予約番号を予約サーバ２００に照会する（ステップ（１０））。予約サーバ２００は、チェックイン機４００に対して、照会された予約番号に対応する予約情報を送信する（ステップ（１１））。チェックイン機４００は、予約サーバ２００から送信された予約番号に対応する搭乗券を出力する（ステップ（１２））。

図３は、搭乗券の出力のためにユーザ７００がチェックイン機４００の前に立っている場面の一例を示す図である。図３には、チェックイン機４００から出力される搭乗券の一例が、左方に拡大されて示されている。

チェックイン機４００は、タッチモニタ４４０と、搭乗券プリンタ４３２と、二次元コードスキャナ４３３とを含む。タッチモニタ４４０は、タッチパネル４４１と、ディスプレイ４４２とを含む。ユーザ７００は、タッチパネル４４１に予約番号を入力する。予約番号はバーコードまたは二次元コード等の図形で供給されていてもよく、ユーザ７００は、二次元コードスキャナ４３３に予約番号を入力してもよい。チェックイン機４００は、入力された予約番号に対応する搭乗券に対応する搭乗券を搭乗券プリンタ４３２から出力する。予約番号が二次元コードで提供される場合、採用されるコードの種類は、図３に記載されたものに限定されず、ＱＲ（登録商標）コードなどの他の種類であってもよい。

搭乗券３０には、ユーザ７００の予約に関する種々の情報が記載されている。搭乗券３０には、二次元コードは、予約番号および／または予約番号に関連する情報を表わす。搭乗券３０には、さらに、便名、出発時刻、搭乗口、座席番号、出発の日付、予約番号、および、予約者の氏名が記載されている。

搭乗券３０は、搭乗券に記載された１つ以上の日付が誕生日と一致する乗客に対するメッセージ「Happy Birthday！」など、乗客情報に応じたメッセージを表示する欄を含んでいても良い。また、搭乗券３０は、広告欄を含んでいても良い。当該広告欄に表示される広告は、乗客情報に従って選択されてもよい。

ステップ（１３）～ステップ（１５）注文、認証要求、仮決済
ユーザ７００は、機内で、機内サーバ３００へ、商品の注文および認証要求を出力する。図４は、ユーザ７００が機内で商品の注文などのために端末１００を使用する場面の一例を示す図である。図４に示されるように、ユーザ７００は、機内の座席で端末１００を操作する。端末１００は、中継器８００を経由して機内サーバ３００と通信する。

一実現例では、端末１００からのアクセスを受け付けると、端末１００に対して、商品購入のウェブページを提供する。当該ウェブページに対して、ユーザ７００は、端末１００に対して商品の注文を入力する。注文は、機内サーバ３００へと送信される。注文を受信すると、機内サーバ３００は、端末１００に対して、乗客を認証するための情報（認証用の情報）の入力を要求する。当該要求に応じて、端末１００には、認証用の情報の入力を促すメッセージが表示される。

上記メッセージに応じて、ユーザ７００は、端末１００を用いて、認証用の情報を機内サーバ３００へ送信することにより、機内サーバ３００に対して認証を要求する。認証用の情報の一例は、予約番号とメールアドレスである。

機内サーバ３００は、ユーザ７００から入力された認証用の情報を機内サーバ３００内の乗客情報と照合することにより、ユーザ７００を認証する。

ユーザ７００の認証に成功すると、機内サーバ３００は注文を仮決済する。すなわち、機内サーバ３００は、ペイメント用サーバ５１０における最終的な決済を伴わず、機内サーバ３００のみにおいて決済を実施する。一実現例では、機内サーバ３００は、注文に従って、後述する商品情報および乗客情報を更新する。機内サーバ３００は、注文に従って、ユーザ（乗客）に商品が提供されるための処理を実行してもよい。処理の一例は、客室乗務員に対して、ユーザ（乗客）への商品提供の指示を表示することである。当該指示は、たとえば、客室乗務員が携帯する端末および／または客室乗務員用のモニタに表示される。

ステップ（１６）～ステップ（１７）オーソリゼーション要求
機内サーバ３００は、決済代行サービス用サーバ５００に、トークンと仮決済の金額とを送信することにより、仮決済のオーソリゼーションを要求する。

図５は、機内サーバ３００を搭載する航空機が空港に着陸した場面を模式的に示す図である。図５の例では、機内サーバ３００は、航空機９００の機内に位置している。一実現例では、機内サーバ３００は、図５に示されるように、航空機９００が着陸したことによって地上の決済代行サービス用サーバ５００との通信が可能になったことに応じて、決済代行サービス用サーバ５００に仮決済のオーソリゼーションを要求する。

機内サーバ３００からの要求に応じて、決済代行サービス用サーバ５００は、機内サーバ３００から送信されたトークンの発行時に利用された決済用情報を抽出し、当該決済用情報と金額とをペイメント用サーバ５１０へ送信することにより、ペイメント用サーバ５１０に対して仮決済のオーソリゼーションを要求する。

（１８）～（１９）オーソリゼーション結果送信
ペイメント用サーバ５１０は、決済用情報と金額とに基づいて、上記仮決済のオーソリゼーションを実施し、その結果（成功／失敗）を決済代行サービス用サーバ５００へ送信する。決済代行サービス用サーバ５００は、ペイメント用サーバ５１０から受信した結果を機内サーバ３００へ送信する。

（２０）事後処理
機内サーバ３００は、仮決済のオーソリゼーションの結果に従って、仮決済に対する事後的な処理を実施する。

事後的な処理の一例は、結果が成功であった場合に、未だユーザ（乗客）へ提供されていない商品の提供を客室乗務員に対して指示ための情報を所与のモニタに表示することである。

他の例は、結果が成功であった場合に、外部のサーバに対して、乗客に商品を提供するための追加的な情報を登録することである。たとえば、機内でタオルとキーホルダーが注文され、当該注文の仮決済のオーソリゼーションが成功した場合、機内サーバ３００は、乗客について登録された住所へのタオルおよびキーホルダーの送付を指示する情報をこれらの商品の発送を管理するサーバへ送信する。

さらに他の例は、結果が成功であった場合に、外部のサーバに対して、イベント参加者の情報または宿泊者の情報として、乗客の情報を送信することである。

さらに他の例は、結果が失敗であった場合に、既に乗客に対して商品の返還を要求することを客室乗務員に対して指示することである。

さらに他の例は、結果が失敗であり、かつ、ペイメント用サーバ５１０からのオーソリゼーションの結果にクレジットカードの不正使用に関する情報が付与されている場合に、警報を出力することであってもよい。機内サーバ３００は、航空機の着陸後であって「ドアオープン」の前にオーソリゼーション結果を受信した場合、空港警察等の適切な機関によって管理されるサーバに上記警告を出力してもよい。これにより、クレジットカード情報を不正利用しようとしたユーザ（乗客）が航空機を出るときに、上記機関によって、その身柄が確実に確保され得る。

［２．ハードウェア構成］
以下、図６～図９を参照して、決済システムを構成する装置のハードウェア構成を説明する。

（端末１００）
図６は、端末１００のハードウェア構成の一例を示す図である。図６に示されるように、端末１００は、プロセッサ１０１と、ＲＡＭ（Random Access Memory）１０２と、記憶装置１０３と、マイクロフォン（マイク）１０４と、スピーカ１０５と、ディスプレイ１０６と、入力装置１０７と、通信インターフェース１０８と、カメラ１０９と、近距離通信インターフェース１１０とを備えている。端末１００内の各要素は、互いに内部バスで接続されている。プロセッサ１０１は、少なくとも１つのＣＰＵ（Central Processing Unit）、少なくとも１つのＡＳＩＣ（Application Specific Integrated Circuit）、少なくとも１つのＦＰＧＡ（Field-Programmable Gate Array）、またはそれらの組み合わせなどによって構成される。

ＲＡＭ１０２は、プロセッサ１０１における処理実行時の作業領域として機能する。記憶装置１０３は、たとえばフラッシュメモリによって実現され、プロセッサ１０１が実行するプログラム（アプリケーションプログラムを含む）および当該プログラムの実行に利用されるデータを非一時的に格納する。

マイク１０４は、入力された音声に応じた信号を、プロセッサ１０１へ出力する。スピーカ１０５は、プロセッサ１０１から出力される信号に従って、音声を出力する。ディスプレイ１０６は、プロセッサ１０１によって実行されるプログラムの処理結果を示す画像を表示する。入力装置１０７は、端末１００に対する入力操作を受け付ける。入力装置１０７は、たとえば、ハードウェアボタン、および／または、ディスプレイ１０６上に配置されたタッチセンサである。

通信インターフェース１０８は、たとえば、ネットワークカードによって実現される。プロセッサ１０１は、通信インターフェース１０８を介して他の装置とデータを送受信する。カメラ１０９は、ＣＭＯＳ（Complementary Metal-Oxide Semiconductor）イメージセンサ等を含み、画像を撮影し、撮影された画像をプロセッサ１０１へ出力する。近距離通信インターフェース１１０は、端末１００にBluetooth（登録商標）などの近距離通信規格に従った態様で他の機器と通信させる。

（予約サーバ２００）
図７は、予約サーバ２００のハードウェア構成の一例を示す図である。図７に示されるように、予約サーバ２００は、プロセッサ２０１と、通信インターフェース２０３と、記憶装置２０５とを含む。プロセッサ２０１は、通信インターフェース２０３を用いて、機内サーバ３００等の他の装置との間で情報を送受信する。プロセッサ２０１は、たとえば、少なくとも１つのＣＰＵによって実現される。

記憶装置２０５は、たとえば、ハードディスク、ＳＳＤ（Solid State Drive）等によって実現されるが、これに限定されない。記憶装置２０５は、プログラム格納領域２６０とデータ格納領域２７０とを含む。プログラム格納領域２６０は、プロセッサ２０１によって実行されるプログラムを非一時的に格納する。プロセッサ２０１によって実行されるプログラムは、予約サーバ２００の本体に対して着脱可能なまたは離間した記録媒体に格納されていてもよい。記憶装置２０５は、プロセッサ２０１のプログラムの実行における作業領域として機能するＲＡＭを含む。データ格納領域２７０は、予約情報を含む種々のデータを格納する。

（機内サーバ３００）
図８は、機内サーバ３００のハードウェア構成の一例を示す図である。図８に示されるように、機内サーバ３００は、プロセッサ３０１と、通信インターフェース３０３と、記憶装置３０５とを含む。プロセッサ３０１は、通信インターフェース３０３を用いて、予約サーバ２００、商品管理サーバ６００、および端末１００等の他の装置との間で情報を送受信する。他の装置との間の情報の送受信は、中継器（図４の中継器８００等）を介して実現されてもよい。プロセッサ３０１は、たとえば、少なくとも１つのＣＰＵによって実現される。

記憶装置３０５は、たとえば、ハードディスク、ＳＳＤ等によって実現されるが、これに限定されない。記憶装置３０５は、プログラム格納領域３６０とデータ格納領域２７０とを含む。プログラム格納領域３６０は、プロセッサ３０１によって実行されるプログラムを非一時的に格納する。プロセッサ３０１によって実行されるプログラムは、機内サーバ３００の本体に対して着脱可能なまたは離間した記録媒体に格納されていてもよい。記憶装置３０５は、プロセッサ３０１のプログラムの実行における作業領域として機能するＲＡＭを含む。データ格納領域３７０は、乗客情報および商品情報を含む種々のデータを格納する。

機内サーバ３００は、航空機に対して着脱可能に構成されてもよい。たとえば、予約サーバ２００および／または商品管理サーバ６００との通信の一部が実行される際には、機内サーバ３００は、航空機の外に配置され、電話回線に有線で接続されていてもよい。この意味において、機内サーバ３００は、航空機に装着されているか否かを検出するためのセンサを備えていても良い。

（チェックイン機４００）
図９は、チェックイン機４００のハードウェア構成の一例を示す図である。図９に示されるように、チェックイン機４００は、プロセッサ４０１と、通信インターフェース４０３と、記憶装置４０５とを含む。プロセッサ４０１は、通信インターフェース４０３を用いて、予約サーバ２００等の他の装置との間で情報を送受信する。プロセッサ４０１は、たとえば、少なくとも１つのＣＰＵによって実現される。

記憶装置４０５は、たとえば、ハードディスク、ＳＳＤ等によって実現されるが、これに限定されない。記憶装置４０５は、プログラム格納領域３６０とデータ格納領域２７０とを含む。プログラム格納領域３６０は、プロセッサ４０１によって実行されるプログラムを非一時的に格納する。プロセッサ４０１によって実行されるプログラムは、チェックイン機４００の本体に対して着脱可能なまたは離間した記録媒体に格納されていてもよい。

図３を参照して説明されたように、チェックイン機４００は、タッチモニタ４４０と、搭乗券プリンタ４３２と、二次元コードスキャナ４３３とを含む。タッチモニタ４４０は、タッチパネル４４１とディスプレイ４４２とを含む。タッチパネル４４１は、静電容量式タッチセンサなどのいかなるタッチセンサによっても実現され得る。ディスプレイ４４２は、タッチパネル４４１に重ねられて構成され、液晶ディスプレイおよび／または有機ＥＬ（Electro Luminescence）ディスプレイなどのいかなるディスプレイによっても実現され得る。

搭乗券プリンタ４３２は、記録用紙に情報を印刷し、当該記録用紙を搭乗券として出力する。二次元コードスキャナ４３３は、読み取った画像をプロセッサ４０１に向けて出力する。

［３．データ構造］
図１０および図１１を参照して、予約情報、乗客情報、および商品情報のデータ構成の一例を説明する。

（予約情報および乗客情報）
図１０は、予約情報および乗客情報のデータ構成の一例を模式的に示す図である。図１０の上方に示されるように、予約情報は、日付、便名、乗客の氏名、メールアドレス、予約番号、座席番号、およびトークンに関する情報を含む。図１０において、各ユーザのトークンは、「ＴＫ００１」等の５つの文字から構成される文字列によって模式的に示されている。予約サーバ２００によって管理される予約情報は、２以上のフライトのそれぞれの乗客の情報を含んでいても良い。

図１０の下方に示されるように、乗客情報は、予約情報の中から、機内サーバ３００が搭載されるフライトの乗客の情報が抽出されて構成される。図１０の例では、乗客情報は、予約情報に格納される内容から、２０１９年４月２７日の便名ＭＭ２２５に係るフライトの乗客であって、機内での決済が必要であることを登録している乗客の情報が抽出されたものである。

プロセッサ３０１は、予約サーバ２００から機内サーバ３００へ予約情報がダウンロードされる時点で乗客情報を生成する。乗客情報では、各乗客に対して、さらに決済情報が定義される。決済情報は、３つの項目（金額、商品ＩＤ、および、オーソリゼーション結果）を含む。金額は、乗客に対して仮決済された金額を表す。商品ＩＤは、仮決済によって購入された商品を表す。オーソリゼーション結果は、仮決済に対するペイメント用サーバ５１０によるオーソリゼーションの結果を表す。各項目の値は、乗客情報の生成後、適宜更新され得る。

（商品情報）
図１１は、商品情報のデータ構成の一例を示す図である。商品情報は、４つの項目（商品ＩＤ、商品名、価格、および残数）を含む。商品ＩＤは、商品に割り振られたＩＤを表す。商品名は、商品の名称を表す。価格は、商品の価格を表す。残数は、販売可能な商品の数量を表す。たとえば、図１１の例において、商品名「鯖カレー」の商品の残数は２０である。このことは、機内で販売可能な当該商品の数量が２０食であることを表す。各項目の値は、乗客情報の生成後、適宜更新され得る。

［４．処理の流れ］
次に、決済システム内の４つの処理（「フライト予約処理」「準備処理」「仮決済処理」および「決済情報のオーソリゼーション処理」）について、図１２～図２０を参照して説明する。

（フライト予約処理）
図１２は、フライト予約処理（図１の（１））のフローチャートである。一実現例では、フライト予約処理は、予約サーバ２００のプロセッサ２０１が所与のプログラムを実行することによって実現される。フライト予約処理は、予約情報として登録される情報を受け付けるため処理である。

ステップＳ１０にて、プロセッサ２０１は、端末１００においてフライトの予約に必要な情報が入力されたか否かを判断する。フライトの予約に必要な情報は、たとえば、乗客の氏名およびメールアドレスを含む。プロセッサ２０１は、当該情報が入力されていないと判断すると（ステップＳ１０にてＮＯ）、一定時間待機し、ステップＳ１０の処理を再び実行し、当該情報がされたと判断すると（ステップＳ１０にてＹＥＳ）、ステップＳ２０へ制御を進める。

ステップＳ２０にて、プロセッサ２０１は、入力された情報を予約情報（図１０）に登録する。なお、プロセッサ２０１は、公知の技術に従って空席情報を参照し、入力された情報に対応するフライト予約が可能であることを条件として、入力された情報を予約情報に登録する。また、プロセッサ２０１は、当該フライト予約に係る決済が確定したこと条件として、入力された情報を予約情報に登録してもよい。

ステップＳ３０にて、プロセッサ２０１は、処理対象のフライトにおいてユーザ（乗客）から入力された情報が、機内決済を必要としているものであるか否かを判断する。プロセッサーは、入力された情報が機内決済を必要としているものであると判断すると（ステップＳ３０にてＹＥＳ）、ステップＳ４０へ制御を進め、そうでなければ（ステップＳ３０にてＮＯ）、ステップＳ６０へ制御を進める。

ステップＳ４０にて、プロセッサ２０１は、ユーザに対して、決済用情報に対応するトークンを要求する。一実現例では、プロセッサ２０１は、ユーザが操作している端末１００に対して、トークンの入力を要求するメッセージを送信する。プロセッサ２０１は、さらに、端末１００に対して、トークンの取得方法の説明および／またはトークンを取得するためのアクセス先の情報を送信してもよい。これに応じて、ユーザは、端末１００を利用してトークンを取得し、予約サーバ２００へ送信する。

ステップＳ５０にて、プロセッサ２０１は、端末１００から送信されたトークンを予約情報に登録する。

ステップＳ６０にて、プロセッサ２０１は、ステップＳ１０～ステップＳ５０において入力された情報に従って登録した予約に新たな予約番号を割り当て、当該予約番号を予約情報に登録し、そして、当該予約情報を端末１００に送信する。その後、プロセッサ２０１は図１２の処理を終了する。

以上、図１２を参照して説明されたフライト予約処理では、フライト予約が機内決済を必要とする情報を含む場合、フライトを予約したユーザの決済用情報に対応するトークンがさらに登録される。

なお、フライト予約処理は、端末１００に格納された予約用のアプリケーションの処理として実現されることもあり得る。この場合、端末１００のプロセッサ１０１は、ステップＳ２０およびステップＳ５０において、予約情報に必要な情報およびトークンを予約サーバ２００に対して送信する。これに応じて、プロセッサ２０１は、端末１００から送信された情報を予約情報に登録する。

（準備処理）
図１３は、準備処理のフローチャートである。準備処理は、図１において（７）で示された、機内サーバ３００への予約情報（乗客情報）のダウンロード、および、図１において（８）で示された、機内サーバ３００への商品情報のダウンロードのための処理である。一実現例では、準備処理は、機内サーバ３００のプロセッサ３０１が所与のプログラムを実行することによって実現される。

ステップＳ１００にて、プロセッサ３０１は、予約サーバ２００へ乗客情報を要求する。当該要求は、プロセッサ３０１を含む機内サーバ３００が搭載されるフライトの日付および便名を特定する情報を伴っていても良い。予約サーバ２００のプロセッサ２０１は、予約情報から、機内サーバ３００が搭載されるフライトの日付および便名に関連付けられ、さらに、機内決済を必要としている乗客に関連付けられた情報を抽出して、機内サーバ３００へ送信する。

ステップＳ１１０にて、プロセッサ３０１は、予約サーバ２００から送信された乗客情報を記憶装置３０５に格納する。

ステップＳ１２０にて、プロセッサ３０１は、商品管理サーバ６００へ商品情報を要求する。一実現例では、商品管理サーバ６００では、フライトごとに商品情報が登録されている。商品管理サーバ６００は、機内サーバ３００からの要求に応じて、機内サーバ３００が搭載されるフライトに関連付けられた商品情報を、機内サーバ３００へ送信する。

ステップＳ１３０にて、プロセッサ３０１は、商品管理サーバ６００から送信された商品情報を記憶装置３０５に格納する。その後、プロセッサ３０１は図１３の処理を終了する。

以上説明された準備処理は、機内サーバ３００が、予約サーバ２００および商品管理サーバ６００のそれぞれから予約情報（乗客情報）および商品情報のそれぞれをプルするための処理に相当する。なお、予約サーバ２００および商品管理サーバ６００のそれぞれから機内サーバ３００へ、予約情報（乗客情報）および商品情報のそれぞれがプッシュされることによって、機内サーバ３００に予約情報（乗客情報）および商品情報が登録されてもよい。

（仮決済処理）
図１４～図１７を参照して、仮決済処理について説明する。図１４は、機内で商品を購入するユーザ７００の端末１００に表示される、注文用の画面の一例を示す図である。図１５は、仮決済処理のフローチャートである。図１６は、端末１００において表示される、認証用の情報の入力を要求する画面の一例である。図１７は、更新後の商品情報の一例を示す図である。

図１４に示されるように、画面１４００は、商品名を表示する欄１４０１と、商品の数量を表示する欄１４０３と、商品の購入を確定させるボタン１４０５とを含む。注文する商品の数量は、欄１４０３内の上側の三角形または下側の三角形がタッチされることによって変更され得る。一実現例では、仮決済処理は、端末１００から機内サーバ３００へ、ボタン１４０５を操作されたことを表す情報が送信されたことに応じて開始される。一実現例では、仮決済処理は、機内サーバ３００のプロセッサ３０１が所与のプログラムを実行することによって実現される。「仮」は、仮決済処理が、ペイメント用サーバ５１０における決済ではなく、ペイメント用サーバ５１０における決済を予約するための処理であることを意味する。一実現例では、仮決済処理は、機内サーバ３００を搭載する航空機の飛行中に、機内におけるユーザ７００の注文を取得する処理である。

図１５を参照して、ステップＳ２００にて、プロセッサ３０１は、端末１００から、ボタン１４０５に対応する注文を取得する。より具体的には、プロセッサ３０１は、ボタン１４０５に対応する注文とは、ボタン１４０５を含む画面１４００に表示された商品の注文を意味する。

ステップＳ２１０にて、プロセッサ３０１は、端末１００に対して、認証用の情報を要求する。当該要求に応じて、端末１００は、ユーザ７００に、認証用の情報の入力を要求する画面を表示する。

ここで、図１６を参照して、画面１６００は、領域１６０１と領域１６０２とを含む。領域１６０１は、認証用の情報の入力を受け付ける。認証用の情報は、予約番号とメールアドレスとを含む。予約番号は、搭乗券に記載されている。このため、ユーザ７００は、搭乗券を参照することにより、領域１６０１に予約番号を入力できる。領域１６０２は、購入される商品の金額、すなわち、将来のペイメント用サーバ５１０における決済の対象となる金額を表示する。

画面１６００は、送信ボタン１６０３を含む。送信ボタン１６０３がタッチされたことに応じて、端末１００は、領域１６０１に認証用の情報を機内サーバ３００へ送信する。

図１５を再び参照して、ステップＳ２２０にて、プロセッサ３０１は、端末１００から送信される認証用の情報を取得する。

ステップＳ２３０にて、プロセッサ３０１は、ステップＳ２２０にて取得された認証用の情報が正しいものであるか否かを判断する。一実現例では、プロセッサ３０１は、ステップＳ２２０にて取得された認証用の情報（予約番号とメールアドレスとの組合せ）が、乗客情報に登録されている情報と一致する場合に正しいと判断し、一致しない場合に正しくないと判断する。プロセッサ３０１は、ステップＳ２２０にて取得された認証用の情報が正しいと判断するとステップＳ２４０へ制御を進め（ステップＳ２３０にてＹＥＳ）、正しくないと判断するとステップＳ２６０へ制御を進める（ステップＳ２３０にてＮＯ）。

ステップＳ２４０にて、プロセッサ３０１は、注文の対象商品（領域１６０２に表示された商品）について、商品情報を更新する。ここで、図１７を参照して、商品「鯖カレー」が数量１だけ購入された場合、図１１に示された商品情報は、図１７に示されたように更新される。図１７では、図１１と比較して、商品「鯖カレー」の残数が１減少（２０→１９）している。

図１５を再び参照して、ステップＳ２５０にて、プロセッサ３０１は、注文の対象商品に基づく決済情報を、ユーザ７００の乗客情報に登録するように、乗客情報を更新する。その後、プロセッサ３０１は、図１５の処理を終了する。

図１８は、更新後の乗客情報の一例を示す図である。たとえば、商品「鯖カレー」が数量１だけ注文された場合、図１０に示された乗客情報は、図１８に示されたように更新される。図１８では、図１０と比較して、氏名「TARO YAMADA」の決済情報において、金額の欄の数値が商品名「鯖カレー」の代金８００円だけ増加し、商品ＩＤの欄に商品名「鯖カレー」の商品ＩＤ（00100）が追加されている。図１８の例では、当該注文についてのペイメント用サーバ５１０による決済は完了していないので、「オーソリゼーション結果」の値として「未」が登録されている。

プロセッサ３０１は、注文が可能か否かを商品情報の残数の数値を参照して判断することができる。たとえば、商品情報が図１７に示された状態にあるときに、２０個の「鯖カレー」が注文されようとした場合を想定する。注文数量（２０）は残数（１９）を超えている。このため、プロセッサ３０１は、当該注文は不可能であると判断する。このような場合、プロセッサ３０１は、図１５の開始時に、ステップＳ２１０を実行することなくステップＳ２６０を実行して、図１５の処理を終了させてもよい。

プロセッサ３０１は、ステップＳ２４０における商品情報の更新とともに、乗客に商品を提供するための制御を実施しても良い。乗客に商品を提供するための制御の一例は、客室乗務員が視認可能なディスプレイに、乗客に商品の提供を指示する情報を表示することである。一実現例では、当該表示は、メッセージ「座席番号『２３Ｆ』のお客様へ、商品『鯖カレー』を数量『１』提供してください。」を含む。

以上説明された仮決済処理によれば、ペイメント用サーバ５１０による最終的な決済を待たずに、注文に従って商品情報が更新される。なお、次に説明される決済情報のオーソリゼーション処理において、注文に対応する決済のオーソリゼーションの結果が「失敗」であった場合に、プロセッサ３０１は、商品情報を元に戻してもよく、また、既に商品が乗客に提供されている場合に、乗客へ商品の返還を要求するように客室乗務員に指示してもよい。

（決済情報のオーソリゼーション処理）
図１９は、決済情報のオーソリゼーション処理のフローチャートである。一実現例では、決済情報のオーソリゼーション処理は、機内サーバ３００のプロセッサ３０１が所与のプログラムを実行することによって実現される。一実現例では、プロセッサ３０１は、機内サーバ３００が搭載されている航空機が着陸して、地上のネットワークに接続可能な状態となったことを条件として、決済情報のオーソリゼーション処理を開始する。

ステップＳ３００にて、プロセッサ３０１は、決済代行サービス用サーバ５００へのアクセスを試み、当該アクセスが成功したか否かを判断する。プロセッサ３０１は、当該アクセスが失敗したと判断すると（ステップＳ３００にてＮＯ）、所定のタイムアウト制限まで一定間隔後にステップＳ３００を再び実行する。プロセッサ３０１は、当該アクセスが成功したと判断すると（ステップＳ３００にてＹＥＳ）、ステップＳ３１０へ制御を進める。

ステップＳ３１０にて、プロセッサ３０１は、乗客情報において決済情報を登録されている乗客を特定する。決済情報を登録されていることは、決済情報における金額の欄の数値が０円以外であることを意味する。図１８の例では、氏名「TARO YAMADA」の乗客の金額の欄の数値は８００円であり、氏名「HANAKO SUZUKI」の乗客の金額の欄の数値は０円である。この場合、氏名「HANAKO SUZUKI」の乗客は決済情報を登録されていないと判断される。すなわち、ステップＳ３１０において、氏名「TARO YAMADA」の乗客が決済情報を登録されている乗客として特定される。

ステップＳ３２０にて、プロセッサ３０１は、ステップＳ３１０にて特定された乗客についてのオーソリゼーションの要求を決済代行サービス用サーバ５００へ送信する。当該要求は、上記乗客についての決済情報の金額とトークンとを含む。当該要求に応じて、決済代行サービス用サーバ５００は、送信されたトークンを当該トークンに対応する決済用情報へ置き換える。その後、決済代行サービス用サーバ５００は、決済用情報と送信された金額とを、ペイメント用サーバ５１０へ送信する。これにより、ペイメント用サーバ５１０に対して、上記乗客についての決済のオーソリゼーションが要求される。ペイメント用サーバ５１０は、決済代行サービス用サーバ５００へオーソリゼーションの結果を送信する。決済代行サービス用サーバ５００は、当該結果を機内サーバ３００へ送信する。

ステップＳ３３０にて、プロセッサ３０１は、決済代行サービス用サーバ５００から送信されたオーソリゼーションの結果を受信する。

ステップＳ３４０にて、プロセッサ３０１は、オーソリゼーションの結果を乗客情報に登録する。図２０は、更新後の乗客情報の一例を示す図である。図１８と比較して、図２０では、氏名「TARO YAMADA」のオーソリゼーション結果の欄に値「成功」が登録されている。

図１９に戻って、ステップＳ３５０にて、事後処理を実施する。ステップＳ３５０の制御は、図１の「（２０）事後処理」に相当する。事後処理の一例は、結果が「成功」であった場合に、未だユーザ（乗客）へ提供されていない商品の提供を、客室乗務員に対して指示することである。事後処理として、乗客情報を予約サーバ２００等の外部の装置へ送信してもよい。これにより、当該外部の装置において、ユーザに関する商品の購入履歴が管理され得る。他の例は、結果が「失敗」であった場合に、商品情報を元に戻すこと（たとえば、仮決済処理で減らした「残数」の数値を元に戻すこと）である。その後、プロセッサ３０１は図１９の処理を終了させる。

［５．機内で販売される商品の変形例］
図２１～図２３のそれぞれは、端末１００に表示される注文用の画面の変形例を示す図である。

（座席変更）
図２１の画面２１００は、乗客が、当該乗客に割り当てられた座席番号を変更するために、新たな座席指定を購入するための画面である。画面２１００は、選択可能な座席番号を表示するための欄２１０１と、注文の対象となる座席番号を表示するための欄２１０３と、注文を決定するためのボタン２１０５とを含む。一実現例では、端末１００から、ボタン２１０５を操作されたことを示す情報を受信すると、機内サーバ３００のプロセッサ３０１は仮決済処理を開始する。

プロセッサ３０１は、端末１００へ、欄２１０３において表示される選択可能な座席番号を指定する情報を送信してもよい。より具体的には、プロセッサ３０１は、予約情報（図１０）から、対象のフライトにおいて購入済の座席番号を抽出していてもよく、当該購入済の座席番号以外の座席番号を、選択可能な座席番号として表示するように機内サーバ３００へ指示してもよい。航空機においてブロックごとに重量のバランスが調整されている場合、プロセッサ３０１は、ある乗客に対して表示される「選択可能な座席番号」として、端末１００に、当該乗客に既に割り当てられているブロックと同じブロック内の座席番号のみを表示することを指示しても良い。

図２１の欄２１０１では、４種類の座席の種類（ファストシート、スマートシート、プレジャーシート、スタンダードシート）が示され、座席番号ごとに座席の種類が割り当てられている。座席の種類によって、座席指定に要する金額が異なる。

図２１の例では、仮決済処理における商品情報の更新（ステップＳ２４０）とともに、プロセッサ３０１は、新たな座席番号を端末１００に通知する。プロセッサ３０１は、さらに、乗客情報において、乗客の座席番号を、新たな座席番号へと変更する。

（降機後のイベント）
図２２の画面２２００は、乗客が、降機後のイベントに参加する権利を購入するための画面である。画面２２００は、イベントの情報を表示する欄２２０１と、イベントの内容および金額を表示する欄２１０３と、当該権利の購入を決定するためのボタン２２０５とを含む。一実現例では、端末１００から、ボタン２２０５を操作されたことを示す情報を受信すると、機内サーバ３００のプロセッサ３０１は仮決済処理を開始する。

図２２の例では、ペイメント用サーバ５１０による仮決済のオーソリゼーションが成功すると、機内サーバ３００のプロセッサ３０１は、イベントの参加者を管理する装置へ、イベントの参加者として、乗客の情報を送信する。

同様に、機内では、ホテルで宿泊する権利が販売され得る。ホテルの宿泊の仮決済処理の終了後、ペイメント用サーバ５１０による仮決済のオーソリゼーションが成功すると、機内サーバ３００のプロセッサ３０１は、ホテルの宿泊客を管理する装置へ、宿泊客として、乗客の情報を送信する。

（降機後の交通手段）
図２３の画面２３００は、乗客が、降機後の交通手段のチケットを購入するための画面である。画面２３００は、交通手段の概要を表示する欄２３０１と、交通手段の具体的な内容および価格を表示する欄２３０３と、チケットの購入を決定するためのボタン２３０５とを含む。一実現例では、機内サーバ３００のプロセッサ３０１は、ボタン２３０５を操作されたことを示す情報を端末１００から受信すると、仮決済処理を開始する。

仮決済が完了すると、プロセッサ３０１は、客室乗務員が視認可能なディスプレイに、乗客にチケットを提供する指示を表示する。

［６．その他の変形例］
本開示において説明された「トークン決済」を用いた決済は、決済システムにおける決済態様の一例である。「トークン決済」を用いた決済が採用されると、機内サーバ３００を運用する事業者は、クレジットカード情報を扱うための機関としての認証（たとえば、ＰＣＩ－ＤＳＳ（Payment Card Industry Data Security Standard）認証）を必要とされない。一方で、決済システムにおいて決済代行サービス用サーバ５００は省略されてもよい。すなわち、機内サーバ３００に、トークンの代わりにクレジットカード情報が入力（登録）されてもよい。機内サーバ３００は、クレジットカード情報を用いて、ペイメント用サーバ５１０に、直接、決済のオーソリゼーションを要求してもよい。

搭乗券は紙等の有体物として出力されなくてもよい。他の実現例では、チェックイン機４００は、予約番号を入力されると、端末１００に対して、搭乗券を出力するために必要な情報を送信してもよい。これにより、端末１００は、搭乗券３０に相当する情報を表示することができる。ユーザ７００は、搭乗口で、搭乗券３０に相当する情報の表示を係員に提示してもよい。

機内サーバ３００への注文および／または認証用の情報の入力には、ユーザによって機内へ持ち込まれた端末１００の代わりに、機内に設置された端末（機内端末）が使用されてもよい。当該端末は、機内サーバ３００と、有線または無線により通信可能に接続され得る。通信形式は特に限られない。認証用の情報の入力は、予約番号の数値の入力の代わりに、二次元コードなどの図形の入力によって実現されてもよい。図形の入力は、たとえば、ユーザ７００が搭乗券３０の二次元コードをカメラ１０９で撮影することによって実現される。

本開示では、乗客が搭乗のために確実に持参している搭乗券が、乗客の認証に利用される。認証用の情報は、「予約番号とメールアドレスの組み合わせ」以外であってもよい。認証用の情報は、たとえば、予約情報のみであってもよいし、座席番号であってもよいし、乗客の氏名であってもよいし、搭乗券に記載された二次元コードであってもよいし、シーケンス番号（便毎にチェックインした順番に割り振られる番号）であってもよいし、チケット番号（いわゆる「ｅチケット番号」または航空券番号。）であってもよい。

認証用情報における「メールアドレス」は、搭乗券に記載されていない情報の一例である。乗客の認証に、搭乗券に記載された情報だけでなく、搭乗券に記載されていない情報も利用されることにより、乗客の認証のセキュリティが向上され得る。すなわち、万が一、第三者が搭乗券を取得しても、当該第三者が搭乗券に記載された情報のみによって、本来の乗客として認証される事態が回避され得る。

本開示では、ユーザ７００（乗客）は、機内で、客室乗務員に直接声をかける必要なく、端末１００を利用して、商品を購入できる。これにより、乗客は、より手軽に商品を購入できるようになり、窓側の座席の乗客など、隣席の乗客を意識して客室乗務員に声をかけにくかった乗客の、商品の購買意欲が向上され得る。

搭乗券を利用した乗客の認証の場所は、機内に限定されない。空港内の売店や、到着後に乗客が乗車するバスや電車の車内、または、到着後に乗客（ユーザ）が訪れた街の店舗であってもよい。この場合、売店、車内、または店舗のサーバが、「機内サーバ３００」として機能する。

今回開示された各実施の形態は全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内での全ての変更が含まれることが意図される。また、実施の形態および各変形例において説明された発明は、可能な限り、単独でも、組合わせても、実施することが意図される。

３０ 搭乗券、１００ 端末、２００ 予約サーバ、３００ 機内サーバ、４００ チェックイン機、４３２ 搭乗券プリンタ、４３３ 次元コードスキャナ、４４０ タッチモニタ、４４１ タッチパネル、５００ 決済代行サービス用サーバ、５１０ ペイメント用サーバ、６００ 商品管理サーバ、７００ ユーザ、８００ 中継器、９００ 航空機。

Claims (9)

1. コンピュータによって実施される決済方法であって、
   乗客からの注文を取得するステップと、
   乗客から入力された認証用の情報を取得するステップと、
   前記認証用の情報と、前記乗客について予め登録された情報であって前記乗客に対して発行された搭乗券に記載された情報である乗客情報とを照合して、前記乗客を認証するステップと、
   前記認証が成功した場合に、前記注文に関する決済情報を前記乗客情報に登録するステップと、
   外部機器によって発行された前記乗客についてのトークンを乗客情報と関連付けて取得するステップと、
   前記外部機器との間で、前記決済情報に基づく決済を実行するステップと、を備え、
   前記決済情報に基づく決済を実行するステップは、前記トークンを利用して、前記外部機器に対して前記決済情報に基づく決済のオーソリゼーションを要求することを含む、決済方法。
2. 前記乗客情報は、予約番号、座席番号、および、搭乗者名の中の少なくとも１つを含む、請求項１に記載の決済方法。
3. 前記乗客情報は、機械読み取り可能なコードとして前記搭乗券に記載される、請求項１または請求項２に記載の決済方法。
4. 前記乗客情報は、前記乗客について予め登録された情報であって前記搭乗券に記載されていない情報をさらに含み、
   前記乗客を認証するステップは、前記認証用の情報と、前記乗客情報における前記搭乗券に記載された情報および前記搭乗券に記載されていない情報の組合せとを照合することを含む、請求項１～請求項３のいずれか１項に記載の決済方法。
5. 前記注文に基づいて、前記外部機器による前記決済のオーソリゼーションの承認の有無に拘わらず、商品情報を更新するステップをさらに備える、請求項１～請求項４のいずれか１項に記載の決済方法。
6. 前記外部機器が前記決済のオーソリゼーションを否認した場合に、前記注文に基づいた前記商品情報の更新を元に戻すステップをさらに備える、請求項５に記載の決済方法。
7. 前記コンピュータは、前記搭乗券に係るフライトの航空機内に搭載されており、
   前記注文を取得するステップは、前記航空機の飛行中に実行され、
   前記外部機器に対して前記決済情報に基づく決済のオーソリゼーションを要求することは、前記航空機の着陸後に実行される、請求項１～請求項６のいずれか１項に記載の決済方法。
8. 前記注文は、前記搭乗券に係るフライトの航空機内における商品の注文を含む、請求項１～請求項７のいずれか１項に記載の決済方法。
9. 前記商品は、前記フライトの航空機内で販売される物品、前記フライトの航空機内における座席変更、および、降機後の交通、イベント、もしくは宿泊のチケットの中の少なくとも１つを含む、請求項８に記載の決済方法。

Images