JP7178828B2 - オーダー端末、セルフ決済方法、及びプログラム - Google Patents

Description

本発明は、オーダーを行なう端末及び決済を行なうサーバ間においてオーダーと決済との間の連携を行なうオーダー端末、セルフ決済方法、及びプログラムに関する。

近年、飲食店などにおいては、テーブルに置かれたオーダー端末、あるいは店員が携帯するハンディ端末により、客からの飲食における商品の注文を受けるセルフオーダーが増えてきている（例えば、特許文献１参照）。
一方、テーブルの席に座ったままで、飲食の代金をクレジットカードや電子マネーカードなどを用いた決済により支払う方法もある。

この場合、客のクレジットカードや電子マネーカードなどのカードを店員が一旦預かり、店員がこのカードを会計場所に設置された決済端末まで携行して、この決済端末により支払の決済処理を行なっている。
しかし、客からみると、クレジットカードや電子マネーのカードが、店員により客自身の目に見えない場所に持って行かれることは、カードに対して不正な処理が行なわれるのではないかと不安を感じる場合がある。
このため、決済端末で会計を行なう客のテーブルの席まで携帯して、クレジットカードや電子マネーのカードによる決済を行なう飲食店もある。

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

しかしながら、店員が決済端末を席まで携帯して、客の目の前で会計を行う場合にも、結果的に店員が客からクレジットカードや電子マネーカードのカードを受取り、決済端末による決済を行なう。
このため、客はクレジットカードや電子マネーカードなどのカードが自身の手から離れ、店員により決済端末で処理されることに不安を感じる場合もある。

また、決済端末を客の席まで携帯するためには、客の会計時の決済処理における待ち時間を短縮するため、複数の決済端末が必要となる。
このため、飲食店にとっては、導入コストなどの運用コストや、各決済端末の物品管理が煩雑になる。

本発明は、このような事情に鑑みてなされたもので、オーダーと飲食代などの代金の決済との連携を可能とし、オーダー端末によりオーダー及び代金の決済の処理が客自身でも行うことができるオーダー端末、セルフ決済方法、及びプログラムを提供することを目的とする。

この発明は上述した課題を解決するためになされたもので、本発明のオーダー端末は、注文を行なうためのオーダー端末であり、オーダーアプリケーションで実行される、注文を入力する注文処理を行なう注文処理部と、決済アプリケーションで実行される、代金の決済処理を行なう決済処理部と、前記オーダーアプリケーションと前記決済アプリケーションとの連携処理の可否を、決済認証アプリケーションで実行される判定の処理により行なう認証部とを備え、前記オーダーアプリケーションが、前記決済処理を行なう決済方法の種類である決済種類を選択する選択画面を表示し、前記オーダーアプリケーションを認証するための認証情報とともに前記決済種類及び前記代金の情報を有する決済情報を、前記決済アプリケーションへ出力し、前記認証部は、前記決済アプリケーションへ出力された前記認証情報に基づき、前記オーダーアプリケーションが決済連携可能なアプリケーションであるか否かの判定を行なうことを特徴とする。

本発明のオーダー端末は、前記オーダーアプリケーションが、前記オーダーアプリケーションを認証するための認証情報である自身の認証情報とともに前記決済処理を行なう前記代金の情報を有する決済情報を、前記決済アプリケーションへ出力する連携アプリケーションを備え、前記決済アプリケーションが、前記オーダー端末に対して決済方法の種類である決済種類を選択する選択画面を表示させ、決済に用いられる前記決済種類を取得することを特徴とする。

本発明のオーダー決済連携システムは、注文を入力するオーダーアプリケーションと、代金の決済要求を行なう決済アプリケーションとを有するオーダー端末と、前記オーダー端末からの前記代金の決済要求に対応して、前記代金の決済処理を行なうオーダー決済連携サーバとを備え、前記オーダー決済連携サーバが前記決済要求に対する連携の可否を、前記オーダー端末から送信される認証情報に基づいて判定する決済認証アプリケーションを備えることを特徴とする。

本発明のオーダー決済連携システムは、前記オーダー決済連携サーバが、前記オーダーアプリケーションを認証するための認証情報に基づいて、当該オーダーアプリケーションとの決済の連携処理の可否を判定することを特徴とする。

本発明のセルフ決済方法は、注文を入力するオーダーアプリケーションと、代金の決済要求を行なう決済アプリケーションとを有するオーダー端末を用いたセルフ決済方法であり、前記オーダーアプリケーションが注文を入力する注文処理過程と、前記決済アプリケーションが代金の決済処理を行なう決済処理過程と、前記オーダーアプリケーションと前記決済アプリケーションとの連携処理の可否を、決済認証アプリケーションで実行される判定の処理により行なう認証過程とを備え、前記オーダーアプリケーションが、前記決済処理を行なう決済方法の種類である決済種類を選択する選択画面を表示し、前記オーダーアプリケーションを認証するための認証情報とともに前記決済種類及び前記代金の情報を有する決済情報を、前記決済アプリケーションへ出力し、前記認証過程において、前記決済アプリケーションへ出力された前記認証情報に基づき、前記オーダーアプリケーションが決済連携可能なアプリケーションであるか否かの判定を行なうことを特徴とする。

本発明のオーダー決済連携方法は、注文を行なうためのオーダー端末にオーダーアプリケーション及び決済アプリケーションの各々が備えられており、前記オーダーアプリケーションが注文を入力する過程と、前記決済アプリケーションが代金の決済要求をオーダー決済連携サーバに対して行なう過程と、前記オーダー決済連携サーバが、前記オーダー端末からの前記代金の決済要求に対応して、前記代金の決済処理を行なう過程とを有し、前記オーダー決済連携サーバが前記決済要求に対する連携の可否を、前記オーダー端末から送信される認証情報に基づいて判定する過程を備えることを特徴とする。

本発明のオーダー決済連携サーバは、注文を行なうための端末であり、注文を入力するオーダーアプリケーションと、代金の決済要求を行なう決済アプリケーションとを備えるオーダー端末を有するオーダー決済連携システムに備えられるオーダー決済連携サーバであり、前記オーダー端末からの前記代金の決済要求に対応して、前記代金の決済処理を行なう際に、前記オーダー端末の前記決済要求に対する連携の可否を、前記オーダー端末から送信される認証情報に基づいて判定する決済認証アプリケーションを備えることを特徴とする。

本発明のプログラムは、注文を行なうためのオーダー端末としてコンピュータを機能させるためのプログラムであり、前記コンピュータを、注文を入力するオーダーアプリケーション手段、代金の決済処理を行なう決済アプリケーション手段、前記オーダーアプリケーション手段と前記決済アプリケーション手段との連携処理の可否の判定の処理を行なう決済認証アプリケーション手段として機能させ、前記オーダーアプリケーション手段が、前記決済処理を行なう決済方法の種類である決済種類を選択する選択画面を表示し、前記オーダーアプリケーション手段を認証するための認証情報とともに前記決済種類及び前記代金の情報を有する決済情報を、前記決済アプリケーション手段へ出力し、前記決済認証アプリケーション手段が、前記決済アプリケーション手段へ出力された前記認証情報に基づき、前記オーダーアプリケーション手段が決済連携可能なアプリケーション手段であるか否かの判定を行なうためのプログラムである。

本発明のプログラムは、注文を行なうための端末であり、注文を入力するオーダーアプリケーションと、代金の決済要求を行なう決済アプリケーションとを有するオーダー端末を有するオーダー決済連携システムに備えられるオーダー決済連携サーバとしてコンピュータを機能させるためのプログラムであり、前記コンピュータを、前記代金の決済要求に対応して、前記代金の決済処理を行なう前記決済手段、前記決済要求に対する連携の可否を、前記オーダー端末から送信される認証情報に基づいて判定する決済認証手段として機能させるためのプログラムである。

この発明によれば、オーダーと飲食代などの代金の決済との連携を可能とし、オーダー端末によりオーダー及び代金の決済の処理が客自身でも行うことができるオーダー端末、セルフ決済方法、及びプログラムを提供することができる。

本発明の第１の実施形態による決済サービス連携システムの構成例を示す図である。 第１の実施形態による管理データベース４＿２に予め書き込まれて記憶されているダウンロード管理テーブルの構成例を示す図である。 第１の実施形態における決済サービス連携システムの決済アプリケーション及び非決済アプリケーションの各々の連携関係を説明する概念図である。 照合データベース３２に予め書き込まれて記憶されている連携処理対応付テーブルの構成例を示す。 第１の実施形態の決済サービス連携システム１００における決済連携、デバイス連携及び非決済連携の各々の処理の動作例を示すフローチャートである。 本実施形態による決済サービス連携システムの応用例を説明する概念図である。 第１の実施形態による決済サービス連携システムの他の応用例を説明する概念図である。 本発明の第１の実施形態による決済サービス連携システムの変形例を示す図である。 本発明の第２の実施形態によるオーダー決済連携システムの構成例を示す図である。 第２の実施形態における照合データベース３２に予め書き込まれて記憶されている連携処理対応付テーブルの構成例を示す。 第２の実施形態のオーダー決済連携システムにおけるオーダー及び決済の連携処理の動作例を示すフローチャートである。 テーブルに配置されたオーダー端末１Ａでセルフオーダーを行ない、セルフ決済を行なう処理を説明する概念図である。 連携処理におけるオーダー端末１Ａの表示画面の遷移を説明する概念図である。 キオスク券売機から本実施形態によるオーダー端末への置き換えを説明する概念図である。

＜第１の実施形態＞
以下、図面を参照して、本発明の第１の実施形態について説明する。図１は、本発明の第１の実施形態による決済サービス連携システムの構成例を示す図である。図１において、本実施形態における決済サービス連携システム１００は、決済アプリケーション端末１－１、決済アプリケーション端末１－２、決済アプリケーション端末１－３、連携データ照合サーバ３及びダウンロードサーバ４の各々を備えている。

決済アプリケーション端末１－１、決済アプリケーション端末１－２、決済アプリケーション端末１－３、連携データ照合サーバ３及びダウンロードサーバ４の各々は、インターネットを含む情報通信網１０５により接続されている。決済アプリケーション端末１－１、決済アプリケーション端末１－２、決済アプリケーション端末１－３を総称する場合、決済アプリケーション端末１と示す。また、本実施形態においては、決済サービス連携システム１００が３台の決済アプリケーション端末１を備える構成として説明するが、１台または２台以上の複数台を備える構成でも良い。

決済アプリケーション端末１は、シンクライアント端末（例えば、ＣＡＦＩＳ Ａｒｃｈ（登録商標）端末など）であり、例えばクレジットカードによりクレジットカード会社に対する代金の支払の決済の処理を行なう決済アプリケーション１０が備えられている端末である。また、決済アプリケーション端末１には、上述した決済アプリケーション１０の他に、決済認証アプリケーション１１及び非決済アプリケーション２０の各々が備えられている。図１において、非決済アプリケーション２０は、１個が示されているが、２個以上の複数個が備えられていても良い。
決済認証アプリケーション１１は、非決済アプリケーション２０からの情報処理の連携依頼に含まれる認証情報により、非決済アプリケーション２０からの連携依頼の可否を判定する。

非決済アプリケーション２０は、決済アプリケーション１０などの決済に関する処理以外の情報処理を行なうアプリケーションであり、例えば、売上管理に関する情報処理を行なうＰＯＳアプリケーションや、代金の支払額に応じたてポイントを付与するポイント付与アプリケーション、顧客の注文を管理する注文（商品選択）アプリケーションなどである。なお、非決済アプリケーション２０は決済アプリケーション１０と区別するために非決済アプリケーションとして説明しているが、プリペイド支払や、独自通貨などの決済アプリケーションを非決済アプリケーション２０とすることもできる。非決済アプリケーション２０は、自身が決済アプリケーション１０に対して連携依頼を行なう際、自身を認証させるための上記認証情報を出力する連携ＡＰＩ（application programming interface）モジュール２１（後述）が含まれている。

連携データ照合サーバ３は、決済アプリケーション端末１から供給される認証情報と連携処理の内容を示す連携情報とに基づき、この認証情報により特定される決済アプリケーション端末１に対して、上記連携情報の示す連携処理の内容が対応付けられているか否かの照合を行ない照合結果を通知する。
また、決済認証アプリケーション１１は、連携データ照合サーバ３からの照合結果により、非決済アプリケーション２０からの連携依頼に対して、対応可能か否かの判定を行なう。

ダウンロードサーバ４は、非決済アプリケーション２０のダウンロードに関する処理を管理するサーバであり、例えば決済アプリケーション１０に対する非決済アプリケーション２０を供給するダウンロードセンタ４００に設けられている。
また、ダウンロードサーバ４は、アプリケーションデータベース４＿１及び管理データベース４＿２の各々を備えている。

アプリケーションデータベース４＿１には、決済アプリケーション端末１が備える決済アプリケーション１０と連携することが許可されている、サードパーティが作成した非決済アプリケーション２０の各々が蓄積されている。
管理データベース４＿２は、決済アプリケーション端末１の各々と、それぞれの決済アプリケーション端末１がダウンロードした上記非決済アプリケーション２０とが対応付けられて記憶されている。

本実施形態においては、決済アプリケーション端末１は、それぞれコンピュータにより構成され、これらコンピュータの各々に搭載されたＯＳにより、プログラムである決済アプリケーション１０、決済認証アプリケーション１１、非決済アプリケーション２０それぞれが起動及び起動されて、上記コンピュータのハードウェア資源（ＣＰＵ（central processing unit）、メモリ、表示装置、プリンタ、カードリーダなどのハードウェア機器）を使用した情報処理を行なう。

図２は、本実施形態による管理データベース４＿２に予め書き込まれて記憶されているダウンロード管理テーブルの構成例を示す図である。
図２のダウンロード管理テーブルにおいて、レコード毎に、端末シリアル番号、ユーザ識別情報、ダウンロードアプリケーション情報、使用可能アプリケーション情報の各々の欄が設けられている。

端末シリアル番号は、製造時にそれぞれの端末の各々に固有に付与される製造番号に対応する番号であり、決済アプリケーション端末１それぞれを一意に識別することができる。ユーザ識別情報は、非決済アプリケーション２０を運用するユーザの各々に付与される識別情報であり、ユーザそれぞれを一意に識別することができる。ダウンロードアプリケーション情報は、端末シリアル番号の示す決済アプリケーション端末１がすでにダウンロードした非決済アプリケーションの情報が記載されている。使用可能アプリケーション情報は、ユーザ識別情報の示すユーザが使用可能な非決済アプリケーションの情報が記載されている。

また、ダウンロードサーバ４は、決済アプリケーション端末１からダウンロードの問い合せが通知された場合、問い合せに付加されている端末シリアル番号を読み込む。そして、ダウンロードサーバ４は、端末シリアル番号に対応した使用可能アプリケーション情報を読み込み、ダウンロードアプリケーション情報に記載されていない非決済アプリケーションを選択し、決済アプリケーション端末１に対して、選択した非決済アプリケーションを使用可能な非決済アプリケーションとして通知する。
また、ダウンロードサーバ４は、新たにメーカに認証された非決済アプリケーションを、この非決済アプリケーションを使用可能とするユーザ識別情報に対応した使用可能アプリケーション情報の欄に新たに書き込んで記憶させる。

上述したダウンロードの処理において、決済アプリケーション端末１は、使用可能な非決済アプリケーションが通知された場合、この使用可能な非決済アプリケーションをユーザに対して提示する。ユーザが選択した非決済アプリケーションを示す情報をダウンロードサーバ４に通知する。
これにより、ダウンロードサーバ４は、決済アプリケーション端末１から通知された非決済アプリケーションのデータを、決済アプリケーション端末１に対して送信する。
そして、決済アプリケーション端末１は、ダウンロードした非決済アプリケーションのインストールを行ない、インストールした非決済アプリケーションの活性化を行なう。

図３は、本実施形態における決済サービス連携システム（図１）の決済アプリケーション及び非決済アプリケーションの各々の連携関係を説明する概念図である。
図３において、決済認証アプリケーション１１は、決済アプリケーション連携インターフェースモジュール１１１、デバイス連携インターフェースモジュール１１２、非決済アプリケーション連携インターフェースモジュール１１３、認証モジュール１１４、決済アプリケーション連携モジュール１１５及び非決済アプリケーション連携モジュール１１６の各々を備えている。また、以下の説明において、決済アプリケーション端末１には、非決済アプリケーション２０＿１及び非決済アプリケーション２０＿２の各々を含んでいる。非決済アプリケーション２０＿１及び非決済アプリケーション２０＿２を総称する場合、非決済アプリケーション２０と示す。本実施形態において、決済アプリケーション端末１には、非決済アプリケーション２０＿１及び非決済アプリケーション２０＿２の２個が備えられているが、１個あるいは複数個が備えられていても良い。

非決済アプリケーション２０は、連携ＡＰＩモジュール２１を含んで構成されている。この連携ＡＰＩモジュール２１は、決済アプリケーション１０を作成したメーカが生成したプログラムモジュールであり、この決済アプリケーション１０と連携させるサードパーティの各々に配給されている。サードパーティの各々は、この決済アプリケーション１０と連携させる非決済アプリケーション２０にこの連携ＡＰＩモジュール２１を組み込む必要がある。

そして、上記メーカ（決済アプリケーション１０を配給するメーカ）は、サードパーティが提供する非決済アプリケーション２０が、決済サービス連携システム（決済アプリケーションシステム１０を含む）に悪影響を与えず、かつ、正常に機能するかを確認し、問題がない場合には非決済アプリケーション２０を許可する。これにより、サードパーティ、メーカまたはダウンロードセンタ４００の管理者は、メーカにより許可された非決済アプリケーション２０を、ダウンロードセンタ４００におけるアプリケーションデータベース４＿１（図１）に格納し、管理データベース４＿２（図１）に上記非決済アプリケーション２０を使用可能アプリケーション（使用可能アプリケーション情報）として登録する。そして、ダウンロードサーバ４は、アプリケーションデータベース４＿１に蓄積される非決済アプリケーション２０を、決済アプリケーション端末１からのダウンロードの要求に対応して供給を行なう。

連携ＡＰＩモジュール２１は、プログラムライブラリとして、読出関数である決済アプリケーション連携呼出モジュール２１１、デバイス連携呼出モジュール２１２及び非決済アプリケーション連携呼出モジュール２１３の各々が備えられている。
決済アプリケーション連携呼出モジュール２１１は、連携する際の連携処理が決済アプリケーション１０が処理するデータである決済データを使用する決済連携処理か否かの判定を行なう。そして、決済アプリケーション連携呼出モジュール２１１は、決済アプリケーション１０と連携する連携処理が決済連携処理である場合、決済連携処理であることを示す連携情報（連携可能な決済処理であること及び決済処理における業務種類）と、非決済アプリケーション２０との連携の可否の判定に用いる認証情報とを、決済認証アプリケーション１１に対して連携依頼情報として出力する。

ここで、認証情報は、非決済アプリケーション２０を識別するアプリケーション識別情報、例えば、決済アプリケーション端末１のＯＳがＡｎｄｒｏｉｄ（登録商標）の場合、ｐａｃｋａｇｅ（パッケージ）名であり、ＯＳがＷｉｎｄｏｗｓ（登録商標）の場合、ＵＲＩ（uniform resource identifier）であり、ＯＳがｉＯＳ（登録商標）の場合、ＵＲＩ（uniform resource identifier）Ｓｃｈｅｍｅ（スキーム）を含む。

また、認証情報は、非決済アプリケーション２０を識別するアプリケーション識別情報のみではなく、決済アプリケーション端末１を識別する端末シリアル番号（例えば、工場出荷時に付与される端末固有の番号）、決済アプリケーション端末１を運用するユーザのユーザ識別情報、あるいはメーカが払い出す認証（許可）コードなどを用いても良い。
また、認証情報は、アプリケーション識別情報、端末シリアル番号、ユーザ識別情報及び認証（許可）コードのいずれか、あるいは組合せ、または全てを用いても良い。
また、認証情報は、アプリケーション識別情報、端末シリアル番号、ユーザ識別情報、認証コードのいずれか、あるいは組合せ、または全てを、所定のハッシュ関数により求めたハッシュ値を用いても良い。
本実施形態においては、一例として、認証情報をアプリケーション識別情報、端末シリアル番号、ユーザ識別情報、認証コードの全てを用いた場合で説明する。

デバイス連携呼出モジュール２１２は、連携する際の連携処理が決済アプリケーション端末１が備えているデバイスを使用する処理であるデバイス連携処理か否かの判定を行なう。そして、デバイス連携呼出モジュール２１２は、連携処理がデバイス連携処理である場合、デバイス連携処理であることを示す連携情報と、非決済アプリケーション２０との連携の可否の判定に用いる認証情報とを、決済認証アプリケーション１１に対して連携依頼情報として出力する。ここで、デバイスとは、決済アプリケーション端末１に搭載されているデバイスのなかで、決済アプリケーション１０が決済処理に対応して用いるデバイスであり、例えばクレジットカードのクレジットカード番号の読取りを行なうカード番号磁気カードリーダ、ＩＣカードリーダやバーコードリーダなどである。

非決済アプリケーション連携呼出モジュール２１３は、連携する際の連携処理が決済アプリケーション端末１が備えている他の非決済アプリケーションが処理するデータである非決済データを使用する非決済連携処理か否かの判定を行なう。そして、非決済アプリケーション連携呼出モジュール２１３は、連携処理が非決済連携処理である場合、非決済連携処理であることを示す連携情報と、非決済アプリケーション２０との連携の可否の判定に用いる認証情報と、連携する非決済アプリケーションを示す連携先情報とを、決済アプリケーション１１に対して連携依頼情報として出力する。

決済アプリケーション連携インターフェースモジュール１１１は、非決済アプリケーション２０から入力される連携依頼情報が、決済連携処理か否かの判定を行なう。そして、決済アプリケーション連携インターフェースモジュール１１１は、連携依頼情報が、決済連携処理である場合、連携依頼情報から認証情報を抽出し、抽出した認証情報を認証モジュール１１４に出力し、認証情報の認証を行わせて、決済連携処理の実行が可能か否かの認証（判定）を依頼する。

デバイス連携インターフェースモジュール１１２は、非決済アプリケーション２０から入力される連携依頼情報が、デバイス連携処理か否かの判定を行なう。そして、デバイス連携インターフェースモジュール１１２は、連携依頼情報が、デバイス連携処理である場合、連携依頼情報から認証情報を抽出し、抽出した認証情報を認証モジュール１１４に出力し、認証情報の認証（判定）を行わせて、デバイス連携処理の実行が可能か否かの認証（判定）を依頼する。

非決済アプリケーション連携インターフェースモジュール１１３は、非決済アプリケーション２０から入力される連携依頼情報が、非決済連携処理か否かの判定を行なう。そして、非決済アプリケーション連携インターフェースモジュール１１３は、連携依頼情報が、非決済連携処理である場合、連携依頼情報から認証情報を抽出し、抽出した認証情報を認証モジュール１１４に出力し、認証情報の認証を行わせて、非決済連携処理の実行が可能か否かの認証（判定）を依頼する。

認証モジュール１１４は、決済アプリケーション連携インターフェースモジュール１１１、デバイス連携インターフェースモジュール１１２及び非決済アプリケーション連携インターフェースモジュール１１３の各々から供給される照合の依頼に対応し、認証情報に基づく照合処理を行なう。

すなわち、認証モジュール１１４は、決済アプリケーション連携インターフェースモジュール１１１からの決済連携処理の認証の依頼に対応して、連携データ照合サーバ３に対して、認証情報に対応した決済連携処理が利用可能サービスとして対応付けられているかと、決済連携処理における指定された業務に対応付けられているかとの照合の依頼を出力する。
そして、認証モジュール１１４は、認証情報に対応した決済連携処理が利用可能サービスとして対応付けられ、かつ決済連携処理における指定された業務が利用可能業務として対応付けられているか否かの照合結果を連携データ照合サーバ３から入力する。

このとき、認証モジュール１１４は、認証情報に対応して利用可能サービスとして決済連携処理が、かつ決済連携処理における指定された業務が対応付けられているという照合結果が得られた場合、決済アプリケーション連携モジュール１１５に対して、決済アプリケーション１０に対する連携処理を行なわせる。
一方、認証モジュール１１４は、認証情報に対して利用可能サービスとして決済連携処理、または決済連携処理における指定された業務のいずれかあるいは双方が対応付けられてないという照合結果が得られた場合、非決済アプリケーション２０に対して、連携不可能を示す情報の通知処理を行なう。

すなわち、認証モジュール１１４は、デバイス連携インターフェースモジュール１１２からのデバイス連携処理の認証の依頼に対して、連携データ照合サーバ３に対して、認証情報に対応したデバイス連携処理が利用可能デバイスとして対応付けられているかの照合の依頼を出力する。
そして、認証モジュール１１４は、認証情報に対応したデバイス連携処理が利用可能サービスとして対応付けられているか否かの照合結果を連携データ照合サーバ３から入力する。

このとき、認証モジュール１１４は、認証情報に対して利用可能サービスとしてデバイス連携処理が対応付けられているという照合結果が得られた場合、対応するデバイスに対して、デバイス連携処理を行なう。
一方、認証モジュール１１４は、認証情報に対して利用可能サービスとして決済処理、が対応付けられてないという照合結果が得られた場合、非決済アプリケーション２０に対して、連携不可能を示す情報の通知処理を行なう。

すなわち、認証モジュール１１４は、非決済アプリケーション連携インターフェースモジュール１１３からの非決済連携処理の認証の依頼に対して、連携データ照合サーバ３に対して、認証情報に対応した非決済連携処理が利用可能サービスとして対応付けられているかの照合の依頼を出力する。
そして、認証モジュール１１４は、認証情報に対応した非決済連携処理が利用可能サービスとして対応付けられているか否かの照合結果を連携データ照合サーバ３から入力する。

このとき、認証モジュール１１４は、認証情報に対して利用可能サービスとして非決済連携処理が対応付けられているという照合結果が得られた場合、他の非決済アプリケーション２０（例えば、非決済アプリケーションが非決済アプリケーション２０＿１である場合、非決済アプリケーション連携モジュール１１６を介して他の非決済アプリケーションとして非決済アプリケーション２０＿２）に対して非決済連携処理を行わせる。
一方、認証モジュール１１４は、認証情報に対して利用可能サービスとして非決済連携処理が対応付けられてないという照合結果が得られた場合、非決済アプリケーション２０（２０＿１）に対して、連携不可能を示す情報の通知処理を行なう。

決済アプリケーション連携モジュール１１５は、認証モジュール１１４からの決済連携処理の依頼に対応し、非決済アプリケーション２０から連携情報に対応して決済処理及び決済処理における業務の連携処理を、決済アプリケーション１０に対して行なわせる。
非決済アプリケーション連携モジュール１１６は、認証モジュール１１４からの非決済連携処理の依頼に対応し、非決済アプリケーション２０＿１から連携情報に対応して非決済処理を、他の非決済アプリケーション２０＿２の非決済アプリケーション２０に対して行なわせる。非決済アプリケーション２０＿２の応答は、非決済アプリケーション連携モジュール１１６を介して非決済アプリケーション２０＿１に対して行なわれる。

連携データ照合サーバ３は、連携可否照合部３１と照合データベース３２との各々を備えている。
連携可否照合部３１は、認証モジュール１１４から照合の依頼が供給された場合、認証情報に対して、認証情報とともに供給される連携情報における連携処理（決済連携処理、デバイス連携処理及び非決済連携処理）が対応付けられているか否かの照合を、照合データベース３２を参照して行なう。

図４は、照合データベース３２に予め書き込まれて記憶されている連携処理対応付テーブルの構成例を示す。
図４の連携処理対応付テーブルにおいて、レコード毎に、アプリケーション識別情報、端末シリアル番号、ユーザ識別情報、利用可能サービス種別、利用可能業務種別及び利用可能デバイス種別の各々の欄が設けられている。
アプリケーション識別情報は、非決済アプリケーションを識別する識別情報である。端末シリアル番号は、製造時にそれぞれの端末の各々に固有に付与される製造番号に対応する番号であり、決済アプリケーション端末１それぞれを一意に識別することができる。ユーザ識別情報は、非決済アプリケーション２０を運用するユーザの各々に付与される識別情報であり、ユーザそれぞれを一意に識別することができる。

上述したアプリケーション識別情報、端末シリアル番号及びユーザ識別情報の各々の組合せ、または事前に払い出された情報の組み合わせが認証情報である。
利用可能サービス種別は、決済連携処理の場合において、例えばクレジット決済、電子マネー決済、バーコード決済、口座振替などの種別が記載され、対応付けがされていない場合、決済アプリケーション連携不可能を示す情報が記載されている。また、利用可能デバイス種別は、デバイス連携処理の場合において、連携可能（利用可能）なデバイス名が記載され、対応付けがされていない場合、デバイス連携不可能を示す情報が記載されている。また、利用可能業務種別は、決済連携処理の場合において、例えばクレジットの売り上げなどであり、非決済連携処理の場合において、例えばポイント付与、注文に対応した指示、業務管理などであり、対応付けがされていない場合、非決済アプリケーション連携不可能を示す情報が記載されている。

例えば、この他のアプリケーションと連携しない非決済アプリケーションは、例えば、従業員の勤怠を管理する勤怠管理アプリケーション、任意の日や任意の時間帯における売上を管理する日時売上管理アプリケーション、従業員に対する業務連絡を行なう業務連絡アプリケーション、監視カメラの撮像管理を行なう監視カメラ映像管理アプリケーションなどがある。また、他のアプリケーションと連携しない非決済アプリケーションも、インストールする際、すでに説明したダウンロードサーバ４からメーカの認証を受けた非決済アプリケーションのなかからダウンロードしてインストールする必要がある。

また、上述した実施形態においては、連携データ照合サーバ３を異なる場所、例えば、連携を管理する管理センタに配置する例を示したが、連携可否照合部３１の機能を、認証モジュール１１４に持たせ、管理センタに照合データベース３２のみを配置する構成としても良い。この構成の場合、認証モジュール１１４は、決済連携処理、デバイス連携書処理及び非決済連携処理の各々における非決済アプリケーション２０の連携処理の可否の認証を行う場合、照合データベース３２を直接参照して、それぞれの処理が非決済アプリケーション２０に対して対応付けられているか否かの照合を行なう。

また、上述した実施形態においては、決済アプリケーション端末１に対して決済認証アプリケーション１１を配置したが、決済認証アプリケーション１１の機能を有する決済認証サーバを設け、非決済アプリケーション２０からの連携依頼を受け、連携データ照合サーバ３との間で認証の処理を行ない、決済アプリケーション端末１の決済アプリケーション１０を動作させるように構成しても良い。

図５は、本実施形態の決済サービス連携システム１００における決済連携、デバイス連携及び非決済連携の各々の処理の動作例を示すフローチャートである。
ステップＳ１０１：
非決済アプリケーション２０（例えば、非決済アプリケーション２０＿１）は、内部の処理過程あるいは入力手段（例えば、タッチパッド）による外部からの制御により、連携ＡＰＩモジュール２１に対して、連携処理に対応するコマンドを出力する。

ステップＳ１０２：
連携ＡＰＩモジュール２１において、決済アプリケーション連携呼出モジュール２１１、デバイス連携呼出モジュール２１２及び非決済アプリケーション連携呼出モジュール２１３の各々は、コマンドの連携処理がそれぞれ自身に対応しているか否かの判定を行なう。
このとき、決済アプリケーション連携呼出モジュール２１１は、連携処理が決済連携処理である場合（ケースＡ）、処理をステップＳ１０３Ａへ進める。
また、デバイス連携呼出モジュール２１２は、連携処理がデバイス連携処理である場合（ケースＢ）、処理をステップＳ１０３Ｂへ進める。
また、非決済アプリケーション連携呼出モジュール２１３は、連携処理がデバイス連携処理である場合（ケースＢ）、処理をステップＳ１０３Ｂへ進める。

ステップ１０３Ａ：
決済アプリケーション連携呼出モジュール２１１は、決済連携準備として、例えば、非決済アプリケーション２０から供給されるコマンドを、決済アプリケーション１０における決済コマンドに変換する。

ステップ１０４Ａ：
決済アプリケーション連携呼出モジュール２１１は、非決済アプリケーション２０及び決済アプリケーション端末１の各々から認証情報（例えば、アプリケーション識別情報、端末シリアル番号及びユーザ識別情報など）を取得する。

ステップ１０５Ａ：
決済アプリケーション連携呼出モジュール２１１は、連携処理が決済連携処理であることを示す連携情報（ここで、決済連携処理は決済コマンドなどを含む）と、取得した認証情報とを連携依頼情報として決済アプリケーション端末１における決済認証アプリケーション１１に対して出力する（決済連携依頼）。

ステップ１０６Ａ：
決済認証アプリケーション１１における決済アプリケーション連携インターフェースモジュール１１１は、決済連携処理及び認証情報の各々を抽出する。
そして、決済アプリケーション連携インターフェースモジュール１１１は、抽出した決済連携処理、認証情報それぞれを認証モジュール１１４に対して出力し、この決済連携処理が連携可能か否かの認証を依頼する。

ステップ１０７Ａ： 認証モジュール１１４は、決済アプリケーション連携インターフェースモジュール１１１からの認証の依頼に対応し、連携データ照合サーバ３に対して、依頼された決済連携処理が認証情報に対応付けられているか否かの照合を依頼する。
これにより、連携データ照合サーバ３において、連携可否照合部３１は、照合データベース３２における連携処理対応付テーブルを参照し、依頼された決済連携処理が認証情報に対応付けられているか否かの照合を行ない、照合結果を認証モジュール１１４に対して送信する。

ステップ１０８Ａ：
認証モジュール１１４は、連携データ照合サーバ３からの照合結果に基づき、依頼された決済連携処理が実行可能か否かの判定を行なう。
このとき、認証モジュール１１４は、照合結果が決済連携処理に対応付けられていることを示す場合、処理をステップＳ１０９Ａに進め、一方、照合結果が決済連携処理に対応付けられていないことを示す場合、処理をステップＳ１１０に進める。

ステップ１０９Ａ：
認証モジュール１１４は、決済連携処理が認証情報に対応付けられているという照合結果により、決済アプリケーション連携モジュール１１５に対して、決済連携処理の実行を依頼する。
これにより、決済アプリケーション連携モジュール１１５は、決済アプリケーション１０に対して、非連携アプリケーション２０が依頼する連携処理を実行させる。

ステップ１０３Ｂ： デバイス連携呼出モジュール２１２は、決済連携準備として、例えば、非決済アプリケーション２０から供給されるコマンドを、決済アプリケーション１０が決済アプリケーション端末１のデバイスを制御する際のデバイスコマンドに変換する。

ステップ１０４Ｂ：
デバイス連携呼出モジュール２１２は、非決済アプリケーション２０及び決済アプリケーション端末１の各々から認証情報（例えば、アプリケーション識別情報、端末シリアル番号及びユーザ識別情報など）を取得する。

ステップ１０５Ｂ：
デバイス連携呼出モジュール２１２は、連携処理がデバイス連携処理であることを示す連携情報（ここで、デバイス連携処理はデバイスコマンドなどを含む）と、取得した認証情報とを連携依頼情報として決済アプリケーション端末１における決済認証アプリケーション１１に対して出力する（デバイス連携依頼）。

ステップ１０６Ｂ：
決済認証アプリケーション１１におけるデバイス連携インターフェースモジュール１１２は、デバイス連携処理及び認証情報の各々を抽出する。
そして、デバイス連携インターフェースモジュール１１２は、抽出したデバイス連携処理、認証情報それぞれを認証モジュール１１４に対して出力し、このデバイス連携処理が連携可能か否かの認証を依頼する。

ステップ１０７Ｂ：
認証モジュール１１４は、デバイス連携インターフェースモジュール１１２からの認証の依頼に対応し、連携データ照合サーバ３に対して、依頼されたデバイス連携処理が認証情報に対応付けられているか否かの照合を依頼する。
これにより、連携データ照合サーバ３において、連携可否照合部３１は、照合データベース３２における連携処理対応付テーブルを参照し、依頼されたデバイス連携処理が認証情報に対応付けられているか否かの照合を行ない、照合結果を認証モジュール１１４に対して送信する。

ステップ１０８Ｂ：
認証モジュール１１４は、連携データ照合サーバ３からの照合結果に基づき、依頼されたデバイス連携処理が実行可能か否かの判定を行なう。
このとき、認証モジュール１１４は、照合結果がデバイス連携処理に対応付けられていることを示す場合、処理をステップＳ１０９Ｂに進め、一方、照合結果がデバイス連携処理に対応付けられていないことを示す場合、処理をステップＳ１１０に進める。

ステップ１０９Ｂ：
認証モジュール１１４は、デバイス連携処理が認証情報に対応付けられているという照合結果により、連携処理が示すデバイスに対して、デバイスコマンドを出力し、非決済アプリケーション２０が依頼するデバイス操作を行なう連携処理を実行させる。

ステップ１０３Ｃ：
非決済アプリケーション連携呼出モジュール２１３は、決済連携準備として、例えば、非決済アプリケーション２０（２０＿１）から供給されるコマンドを、連携を行なう他の非決済アプリケーション（２０＿２）における非決済コマンドに変換する。

ステップ１０４Ｃ：
非決済アプリケーション連携呼出モジュール２１３は、非決済アプリケーション２０及び決済アプリケーション端末１の各々から認証情報（例えば、アプリケーション識別情報、端末シリアル番号及びユーザ識別情報など）を取得する。

ステップ１０５Ｃ：
非決済アプリケーション連携呼出モジュール２１３は、連携処理が非決済連携処理であることを示す連携情報（ここで、非決済連携処理は非決済コマンドなどを含む）と、取得した認証情報とを連携依頼情報として決済アプリケーション端末１における決済認証アプリケーション１１に対して出力する（非決済連携依頼）。

ステップ１０６Ｃ：
決済認証アプリケーション１１における非決済アプリケーション連携インターフェースモジュール１１３は、非決済連携処理及び認証情報の各々を抽出する。
そして、非決済アプリケーション連携インターフェースモジュール１１３は、抽出した非決済連携処理、認証情報それぞれを認証モジュール１１４に対して出力し、この非決済連携処理が連携可能か否かの認証を依頼する。

ステップ１０７Ｃ：
認証モジュール１１４は、非決済アプリケーション連携インターフェースモジュール１１３からの認証の依頼に対応し、連携データ照合サーバ３に対して、依頼された非決済連携処理が認証情報に対応付けられているか否かの照合を依頼する。
これにより、連携データ照合サーバ３において、連携可否照合部３１は、照合データベース３２における連携処理対応付テーブルを参照し、依頼された非決済連携処理が認証情報に対応付けられているか否かの照合を行ない、照合結果を認証モジュール１１４に対して送信する。

ステップ１０８Ｃ：
認証モジュール１１４は、連携データ照合サーバ３からの照合結果に基づき、依頼された非決済連携処理が実行可能か否かの判定を行なう。
このとき、認証モジュール１１４は、照合結果が非決済連携処理に対応付けられていることを示す場合、処理をステップＳ１０９Ｃに進め、一方、照合結果が決済連携処理に対応付けられていないことを示す場合、処理をステップＳ１１０に進める。

ステップ１０９Ｃ：
認証モジュール１１４は、非決済連携処理が認証情報に対応付けられているという照合結果により、非決済アプリケーション連携モジュール１１６に対して、非決済連携処理の実行を依頼する。
これにより、非決済アプリケーション連携モジュール１１６は、他の非決済アプリケーション（例えば、図３における非決済アプリケーション２０＿２）に対して、非決済アプリケーション２０＿１が依頼する連携処理を実行させる。

ステップ１１０：
認証モジュール１１４は、決済連携処理が認証情報に対応付けられていない、あるいはデバイス連携処理が認証情報に対応付けられていない、または非決済連携処理が認証情報に対応付けられていない場合、非決済アプリケーション２０＿１に対して、それぞれの依頼した連携処理が連携不可能であることを示す通知を出力する。

・応用例＃１
図６は、本実施形態による決済サービス連携システムの応用例を説明する概念図である。
すでに述べたように、例えば、非決済アプリケーション２０であるＰＯＳアプリケーション５１や個別業務である売上管理アプリケーション５２を起動させ、または起動させた状態において、顧客の代金の支払金額を入力する。これにより、非決済アプリケーション２０は、決済連携処理の依頼を、連携ＡＰＩモジュール２１に対して出力され、連携ＡＰＩモジュール２１が起動される。

このとき、連携ＡＰＩモジュール２１は、決済連携処理の準備を行なう際、いずれの決済サービス（利用可能サービス）を顧客が用いるかを、決済アプリケーション端末１のメニュー画面５３から入力される決済サービスの種類により決定する。このメニュー画面５３には、店舗（ユーザ識別情報で識別されるユーザ）における利用可能な決済サービスの種類が全て表示される。
そして、メニュー画面５３において、顧客がクレジットカードを選択すれば、クレジットカードが支払方法とされ、電子マネーを選択すれば、電子マネーが代金の支払方法とされる。

そして、連携ＡＰＩモジュール２１は、選択された決済サービスを用いた決済連携処理であることを示す連携依頼情報及び認証情報の各々を、決済アプリケーション端末１に対して出力する。
これにより、決済認証アプリケーション１１は、決済連携処理が認証情報に対応付けられており、決済サービスが実行できることを認証する。決済認証アプリケーション１１は、決済アプリケーション連携モジュール１１５を介して、決済サービス５４に対応した決済アプリケーション１０により決済処理を行なう。
決済処理の完了を決済アプリケーション１０からの通知により検出した後、決済認証アプリケーション１１は、処理を非決済アプリケーション２０であるＰＯＳアプリケーション５１または売上管理アプリケーション５２に戻す。

・応用例＃２
図７は、本実施形態による決済サービス連携システムの他の応用例を説明する概念図である。
図６と同様に、例えば、非決済アプリケーション２０である商品選択アプリケーションを起動させ、または起動させた状態において、顧客の注文した商品の種類、商品の種類毎の個数及び商品の金額を入力する。これにより、商品選択アプリケーション５５は、決済アプリケーション端末１の表示画面５５Ｓに商品の種類、種類毎の個数及び金額を表示した後、連携処理の依頼を、連携ＡＰＩモジュール２１に対して出力され、連携ＡＰＩモジュール２１が起動される。
そして、連携ＡＰＩモジュール２１連携が可能な連携処理をメニュー画面５６として表示する。

このとき、連携ＡＰＩモジュール２１は、店舗における利用可能な決済サービスの種類が全てと、利用可能な他の非決済アプリケーションの種類が表示される。図７においては、他の非決済アプリケーションをＰＯＳアプリケーションとしている。
そして、連携ＡＰＩモジュール２１は、選択されたＰＯＳアプリケーションを用いた非決済連携処理であることを示す連携依頼情報及び認証情報の各々を、決済アプリケーション端末１に対して出力する。

これにより、決済認証アプリケーション１１は、非決済連携処理が認証情報に対応付けられており、非決済サービスとしてＰＯＳアプリケーションが実行できることを認証する。決済認証アプリケーション１１は、非決済アプリケーション連携モジュール１１６を介して、ＰＯＳアプリケーション５７を起動する。
次に、ＰＯＳアプリケーション５７は、商品の種類、商品毎の個数及び金額の各々の売上管理を行なった後、決済連携処理の依頼を、連携ＡＰＩモジュール２１に対して出力され、連携ＡＰＩモジュール２１が起動される。

このとき、連携ＡＰＩモジュール２１は、決済連携処理の準備を行なう際に、いずれの決済サービスを顧客が用いるかを、決済アプリケーション端末１のメニュー画面（不図示）から入力される決済サービスの種類により決定する。決済アプリケーション端末１のメニュー画面には、店舗における利用可能な決済サービスの種類が全て表示される。
そして、決済アプリケーション端末１のメニュー画面において、顧客がクレジットカードを選択すれば、クレジットカードが代金の支払方法とされ、電子マネーを選択すれば、電子マネーが代金の支払方法とされる。

そして、連携ＡＰＩモジュール２１は、選択された決済サービスを用いた決済連携処理であることを示す連携依頼情報及び認証情報の各々を、決済アプリケーション端末１に対して出力する。
これにより、決済認証アプリケーション１１は、決済連携処理が認証情報に対応付けられており、決済サービスが実行できることを認証する。決済認証アプリケーション１１は、決済アプリケーション連携モジュール１１５を介して、決済サービス５８に対応した決済アプリケーション１０により決済処理を行なう。
決済処理の完了を決済アプリケーション１０からの通知により検出した後、決済認証アプリケーション１１は、処理を非決済アプリケーション２０であるＰＯＳアプリケーション５７に戻す。

上述したように、本実施形態によれば、決済アプリケーション１０と非決済アプリケーション２０との間で連携を行う際、非決済アプリケーション２０から決済アプリケーション１０を連携のために起動させる場合、決済を行なう顧客の個人情報を取得せずに、決済連携処理を行なうことと決済の金額のみを決済アプリケーション１０に対して出力して、決済アプリケーション１０に決済を行なわせるため、非決済アプリケーション２０に対して代金の支払のための個人情報が入力されることがなく、個人情報が盗み取られることを防止し、セキュリティ機能を向上させることができる。

すなわち、決済アプリケーション１０との連携を行なう非決済アプリケーション２０には、このアプリケーションを作成するサードパーティが、決済アプリケーション１０を作製したメーカの指定する連携ＡＰＩモジュール２１を組み込ませる必要がある。この連携ＡＰＩモジュール２１は、非決済アプリケーション２０が決済アプリケーション１０を起動させるための連携依頼情報を決済認証アプリケーション１１に出力する。この認証情報が、非決済アプリケーション２０を認証する認証情報と、連携処理の種別とであり、顧客の個人情報を含まず、余計な顧客の個人情報が非決済アプリケーション２０に入力されないため、顧客の個人情報が非決済アプリケーションに対して与えられることがなく、セキュリティ機能を向上させることができる。

また、本実施形態においては、決済アプリケーション端末１に（あるいは後述するように非決済アプリケーション端末２に）インストールして、決済アプリケーション１０と連携処理を行なう非決済アプリケーション２０や、決済アプリケーション１０と同一の端末にインストールされる非決済アプリケーション２０が、決済アプリケーションを作成しているメーカの許可を受けたアプリケーションに限定されるため、動作が不明なアプリケーションではないため、上述した構成に加えて、セキュリティ機能を向上させることができる。

また、上述した実施形態においては、決済アプリケーション端末１に決済アプリケーション１０及び非決済アプリケーション２０の各々を備える構成として説明したが、図８に示す様に、決済アプリケーション端末１に決済アプリケーション１０をインストールし、非決済アプリケーション２０を他の端末である非決済アプリケーション端末にインストールして用いる構成としても良い。図８は、本発明の一実施形態による決済サービス連携システムの変形例を示す図である。

図８において、本実施形態における決済サービス連携システム１００は、決済アプリケーション端末１、非決済アプリケーション端末２＿１、非決済アプリケーション端末２＿２、連携データ照合サーバ３及びダウンロードサーバ４の各々を備えている。
決済アプリケーション端末１、非決済アプリケーション端末２＿１、非決済アプリケーション端末２＿２、連携データ照合サーバ３及びダウンロードサーバ４の各々は、インターネットを含む情報通信網２００により接続されている。非決済アプリケーション端末２＿１及び非決済アプリケーション端末２＿２を総称する場合、非決済アプリケーション端末２と示す。また、図８の変形例においては、決済サービス連携システム１００が２台の非決済アプリケーション端末２を備える構成として説明するが、１台または複数台を備える構成でも良い。

この構成において、決済認証アプリケーション１１は、非決済アプリケーション端末２からの情報処理の連携依頼に含まれる認証情報により、非決済アプリケーション２０からの連携依頼の可否を判定する。図８の変形例においては、認証情報としての端末シリアル番号は、製造時にそれぞれの非決済アプリケーション端末２の各々に固有に付与される製造番号に対応する番号であり、非決済アプリケーション端末２それぞれを一意に識別することができる番号である。

非決済アプリケーション端末２は、図１において説明した決済アプリケーション１０などの決済に関する処理以外の情報処理を行なう非決済アプリケーション２０が備えられている。
また、図８に示す構成とした場合、非決済アプリケーション２０を非決済アプリケーション端末２にインストールする場合、決済アプリケーション１０や他の非決済アプリケーション２０と連携処理を行なわない機能を有する非決済アプリケーションをインストールして用いても良い。

また、本実施形態においては、決済アプリケーションと非決済アプリケーションとの連携処理について記載しているが、決済アプリケーション（第１決済アプリケーション）が非決済アプリケーションのみではなく他の決済アプリケーション（第２決済アプリケーション）との連携処理を行なう構成としても良い。例えば、第２決済アプリケーションがラインペイによる決済方法の決済処理を行い、第１決済アプリケーションが電子マネーによる決済方法の決済処理を行なう場合、第２決済アプリケーションによるラインペイによる決済が行なわれた際、ラインペイの残高が代金に対して少ないと、第１決済アプリケーションにより電子マネーの残高を照会するような決済処理を連携する連携処理が行なわれる構成としても良い。ここで、第２決済アプリケーションが第１決済アプリケーションに対して連携処理を行なう場合、上述した本実施形態における非決済アプリケーションの場合と同様に、第２決済アプリケーションの連携可否の判定が行なわれる。

＜第２の実施形態＞
次に、図面を参照して、本発明の第２の実施形態について説明する。本発明の第２の実施形態は、すでに説明した第１の実施形態による決済サービス連携システムをオーダー端末でセルフオーダー処理と決済処理との連携を行なうオーダー決済連携システムとして運用する構成である。図９は、本発明の第２の実施形態によるオーダー決済連携システムの構成例を示す図である。図９において、本実施形態におけるオーダー決済連携システム１００Ａは、オーダー端末１Ａ－１からオーダー端末１Ａ－ｍと、オーダー決済連携サーバ４０と、連携データ照合サーバ３０との各々を備えている。オーダー端末１Ａ－１からオーダー端末１Ａ－ｍと、オーダー決済連携サーバ４０と、連携データ照合サーバ３０との各々は、インターネットやＬＡＮを含む情報通信網１０５により接続されている。以下、オーダー端末１Ａ－１からオーダー端末１Ａ－ｍを総称する場合、単にオーダー端末１Ａと記載する。オーダー端末１Ａは、第１の実施形態における決済アプリケーション端末１に対応している。また、ダウンロードセンター４００の記載は省略されている。

オーダー端末１Ａは、レストランなどの飲食店のテーブルの各々に配置されたり、あるいは飲食店の店員が携帯して客から商品の注文（オーダー）を受ける端末であり、第１の実施形態における決済アプリケーション端末１に対応している。
また、本実施形態におけるオーダー端末１Ａには、例えば、決済アプリケーション１０、決済認証アプリケーション１１及びオーダーアプリケーション２０Ａの各々が備えられている。オーダーアプリケーション２０Ａは、第１の実施形態における非決済アプリケーション２０に対応している。

本実施形態においては、オーダー端末１Ａは、コンピュータにより構成され、このコンピュータに搭載されたＯＳにより、プログラムである決済アプリケーション１０及びオーダーアプリケーション２０Ａのそれぞれが起動されて、上記コンピュータのハードウェア資源（ＣＰＵ、メモリ、表示装置、プリンタ、カードリーダなどのハードウェア機器）を使用した情報処理を行なう。

ここで、オーダーアプリケーション２０Ａは、例えば、オーダー端末１Ａがテーブルに配置されている場合、表示画面に対してその飲食店で提供している商品を表示し、かつ注文を行なうよう促す指示を表示する処理とを行なう。
そして、客は、オーダー端末１Ａの表示画面に表示された商品から、自身の注文対象となる商品を選択することにより、飲食するために選択した商品の注文を自身が注文ボタンを押下するなどの入力処理により行なう（セルフオーダー処理）。

また、オーダーアプリケーション２０Ａは、店員がオーダー端末１Ａを携帯している場合、表示画面に商品の一覧を表示する。
そして、店員は、オーダー端末１Ａの表示画面に表示される商品一覧から、客がテーブルに配置されている印刷物としてのメニューを見て選択した商品を、表示画面から選択することにより注文をオーダーアプリケーション２０Ａに対して入力する。

また、上記オーダーアプリケーション２０Ａは、自身が決済アプリケーション１０に対して、決済の連携依頼を行なう際、自身を認証させるために用いる認証情報を出力する連携ＡＰＩ（application programming interface）モジュール２１（後述）を備えている。
この連携ＡＰＩモジュール２１は、オーダーアプリケーション２０Ａに埋め込まれており、オーダーアプリケーション２０Ａやオーダー端末１Ａから、オーダーアプリケーション２０Ａを認証するための認証情報を読み込む。
決済認証アプリケーション１１は、第１の実施形態と同様に、上記認証情報に基づき、オーダーアプリケーション２０Ａが決済連携が可能なアプリケーションであるか否かの判定を行なうため、連携可否照合部３１に対して問合せを行なう（認証処理）。

ここで、認証情報は、第１の実施形態と同様に、例えば、オーダーアプリケーション２０Ａを識別するアプリケーション識別情報、例えば、オーダー端末１ＡのＯＳがＡｎｄｒｏｉｄ（登録商標）の場合、ｐａｃｋａｇｅ（パッケージ）名であり、ＯＳがＷｉｎｄｏｗｓ（登録商標）の場合、ＵＲＩであり、ＯＳがｉＯＳ（登録商標）の場合、ＵＲＩＳｃｈｅｍｅである。
また、認証情報は、非決済アプリケーション２０を識別するアプリケーション識別情報のみではなく、決済アプリケーション端末１を識別する端末シリアル番号（例えば、工場出荷時に付与される端末固有の番号）、決済アプリケーション端末１を運用するユーザのユーザ識別情報、あるいはメーカが払い出す認証（許可）コードなどを用いても良い。

また、認証情報は、アプリケーション識別情報、端末シリアル番号、ユーザ識別情報及び認証（許可）コードのいずれか、あるいは組合せ、または全てを用いても良い。
また、認証情報は、アプリケーション識別情報、端末シリアル番号、ユーザ識別情報、認証コードのいずれか、あるいは組合せ、または全てを、所定のハッシュ関数により求めたハッシュ値を用いても良い。
本実施形態においては、一例として、認証情報をアプリケーション識別情報、端末シリアル番号、ユーザ識別情報、認証コードの全てを用いた場合で説明する。

連携ＡＰＩモジュール２１は、第１の実施形態と同様に、プログラムライブラリとして、読出関数である決済アプリケーション連携呼出モジュール２１１、デバイス連携呼出モジュール２１２及び非決済アプリケーション連携呼出モジュール２１３の各々が備えられている。
決済アプリケーション連携呼出モジュール２１１は、連携する際の連携処理が決済アプリケーション１０が処理するデータである決済データを使用する決済連携処理であるか否かの判定を行なう。

そして、決済アプリケーション連携呼出モジュール２１１は、決済アプリケーション１０と連携する連携処理が決済連携処理である場合、決済連携処理であることを示す連携情報（連携可能な決済処理であること及び決済処理における業務種類）と、他アプリケーションとの連携の可否の判定に用いる認証情報とを、決済認証アプリケーション１１に対して連携依頼情報として出力する。

デバイス連携呼出モジュール２１２は、連携する際の連携処理が決済アプリケーション端末１が備えているデバイスを使用する処理であるデバイス連携処理か否かの判定を行なう。そして、デバイス連携呼出モジュール２１２は、連携処理がデバイス連携処理である場合、デバイス連携処理であることを示す連携情報と、非決済アプリケーション２０との連携の可否の判定に用いる認証情報とを、決済認証アプリケーション１１に対して連携依頼情報として出力する。

非決済アプリケーション連携呼出モジュール２１３は、連携する際の連携処理が決済アプリケーション端末１が備えている他の非決済アプリケーションが処理するデータである非決済データを使用する非決済連携処理か否かの判定を行なう。そして、非決済アプリケーション連携呼出モジュール２１３は、連携処理が非決済連携処理である場合、非決済連携処理であることを示す連携情報と、非決済アプリケーション２０との連携の可否の判定に用いる認証情報と、連携する非決済アプリケーションを示す連携先情報とを、決済認証アプリケーション１１に対して連携依頼情報として出力する。

また、決済アプリケーション１０は、飲食の代金の会計時に、オーダーアプリケーション２０Ａからの連携依頼に対応して、オーダーアプリケーション２０Ａとの間において代金の決済の連携処理を行なう。
この連携処理の際、第１の実施形態と同様に、オーダーアプリケーション２０Ａは、決済アプリケーション１０と連携可能であるかを検証するため、連携ＡＰＩモジュール２１を通じて、決済認証アプリケーション１１に連携する。決済認証アプリケーション１１は、連携可否照合部３１による連携可否の判断結果を、連携ＡＰＩモジュール２１を通じてオーダーアプリケーション２０Ａに送信する。
また、なお、オーダーアプリケーション２０Ａが決済アプリケーションとの連携可との結果を受領後、決済アプリケーション１０と連携を行なう。

また、この連携処理の際、決済アプリケーション１０は、オーダーアプリケーション２０Ａからの連携依頼に、決済方法が含まれていない場合、決済認証アプリケーション１１を介して、連携データ照合サーバ３０に対してオーダーアプリケーション２０Ａが連携可能な決済方法の決済種類を問い合わせる。
これにより、連携データ照合サーバ３０は、決済認証アプリケーション１１から供給される認証情報に基づき、この認証情報により認証されるオーダーアプリケーション２０Ａが利用可能な決済方法を決済アプリケーション１０に対して通知する。
決済アプリケーション１０は、利用可能な決済方法をオーダー端末１Ａの表示画面に表示して、客に対して利用可能な決済方法を選択させる。
そして、オーダーアプリケーション２０Ａとの決済の連携処理を行なうことが可能とする決済方法（客が選択した決済方法）により、飲食の代金の決済の連携処理として、オーダー決済連携サーバ４０に対して、決済処理を要求する決済要求を送信する。
また、上述した構成においては、決済アプリケーション１０が利用可能な決済方法をオーダー端末１Ａの表示画面に表示しているが、決済アプリケーション１０がオーダーアプリケーション２０Ａに利用可能な決済方法を通知し、オーダーアプリケーション２０Ａが利用可能な決済方法をオーダー端末１Ａの表示画面に表示する構成としても良い。

一方、オーダーアプリケーション２０Ａから連携処理を受けた際、決済アプリケーション１０は、オーダーアプリケーション２０Ａからの連携依頼に、決済方法が含まれている場合、その決済方法（客が選択した決済方法）により、飲食の代金の決済の連携処理として、オーダー決済連携サーバ４０に対して、決済処理を要求する決済要求を送信する。
この場合、オーダーアプリケーション２０Ａは、オーダー端末１Ａで利用可能な決済方法を、オーダー端末１Ａの表示画面に表示して、客に対して利用可能な決済方法を選択させる。

オーダー決済連携サーバ４０は、飲食の代金の支払の決済処理において、実際にクレジット会社などの決済処理を行なう会社に対する決済を実行するサーバである。
また、オーダー決済連携サーバ４０は、決済処理アプリケーション４１が備えられている。

決済処理アプリケーション４１は、決済方法に対応した会社、例えばクレジット会社の処理サーバにアクセスし、客の使用するカードの認証に用いる情報（例えば、クレジットカードであればカード番号及びパスワード（ＰＩＮ（personal identification number）コード）による認証処理）の結果に対応して決済を実行する。
また、決済方法が、ＱＲコード（登録商標）決済などの２次元バーコードを用いた決済や、電子マネーカード決済、電子マネーを用いるアプリケーション決済などの場合、決済処理を実行する会社に対して、オーダー決済連携サーバ４０から決済が依頼される。

連携データ照合サーバ３０は、決済認証アプリケーション１１から供給される認証情報と連携処理の内容を示す連携情報とに基づき、この認証情報により認証されるオーダーアプリケーション２０Ａに対して、決済認証アプリケーション１１及び連携ＡＰＩモジュール２１を通して、上記連携情報の示す連携処理の内容が対応付けられているか否かの照合を行ない、認証結果を通知する。

連携データ照合サーバ３０は、第１の実施形態における連携データ照合サーバ３に対応している。連携データ照合サーバ３０は、例えば、連携可否照合部３１と照合データベース３２との各々を備えている。
連携可否照合部３１は、決済認証アプリケーション１１から照合の依頼が供給された場合、認証情報に対して、認証情報とともに供給される連携情報における連携処理（決済連携処理、デバイス連携処理及び他アプリケーション連携処理）が対応付けられているか否かの照合を、照合データベース３２を参照して行なう。

また、決済処理アプリケーション４１は、クレジット会社のサーバにおける決済の結果（正常終了した、あるいは正常終了しない）を示す通知を、このサーバから供給された際、この決済の結果の通知を、オーダー端末１Ａの決済アプリケーション１０に対して出力する。
決済処理アプリケーション４１は、供給される決済の結果の通知を、オーダーアプリケーション２０Ａに対して出力する。

また、オーダーアプリケーション２０Ａは、自身の有する決済終了報告アプリケーションに対して、上記決済の結果の通知を、連携ＡＰＩモジュール２１を通して、飲食店にある会計サーバ（店舗サーバ）、または飲食店を管理する本部の本部サーバに対して出力する。
本実施形態によれば、上記「決済の結果の通知」の内容が、正常に決済処理が完了したことを示す通知の場合、飲食店にある会計サーバに対して通知の結果を出力することにより、客２００の支払いが終わり店から出て帰宅することを従業員に知らせ、従業員が店の出口において客２００の見送りを行なうように促す画面をリアルタイムに表示することで顧客満足度を高めることができる。

また、本実施形態によれば、上述したように、客２００の支払いが終わり店から出て帰宅することを従業員に知らせることにより、テーブルを片付けて清掃する指示を従業員にリアルタイムで出すことが可能となり、客２００が利用していたテーブルの片付け処理を早く行なえ、飲食店におけるテーブルの回転率を高め、売上を向上させることができる。

また、本実施形態によれば、飲食店の店舗を管理する本部のサーバに対して、店舗における売上金の金額や決済した商品等を出力することにより、リアルタイムに各店舗の売り上げや、店舗毎の売れ筋商品を把握することが可能になり、当該店舗に対して客単価を上げるために、接客の際のアクション（挨拶や注文時における声だし、店内での客に対するお勧め商品案内など）を行うように従業員に指示を出したり、所定の店舗における本日の売れ筋商品を他店舗に対して紹介し、店舗間における情報共有により、各店舗の売り上げを向上させることが可能となる。

図１０は、本実施形態における照合データベース３２に予め書き込まれて記憶されている連携処理対応付テーブルの構成例を示す。
図１０の連携処理対応付テーブルにおいて、レコード毎に、アプリケーション識別情報、端末シリアル番号、ユーザ識別情報、連携可能な決済処理種類、連携可能デバイス及び連携可能他アプリケーションの各々の欄が設けられている。
アプリケーション識別情報は、オーダーアプリケーションを識別する識別情報である。端末シリアル番号は、製造時にそれぞれの端末の各々に固有に付与される製造番号に対応する番号であり、オーダー端末１Ａそれぞれを一意に識別することができる。

ユーザ識別情報は、オーダー端末１Ａを運用するユーザ（飲食店）の各々に付与される識別情報であり、ユーザそれぞれを一意に識別することができる。
上述したアプリケーション識別情報、端末シリアル番号及びユーザ識別情報の各々の組合せが認証情報である。
決済処理種類は、決済連携処理において、例えばクレジットカード決済、電子マネーカード決済、ＱＲコード（登録商標）決済などの種類（それぞれの決済種類の運営会社の種類などの決済ブランドも含む）の決済方法が記載され、対応付けがされていない場合、決済の連携が不可能であることを示す。

また、連携可能デバイスは、オーダー端末１Ａの搭載されているバーコードリーダなどのハードウェアデバイスのなかで、オーダーアプリケーション２０Ａが連携可能（連携して処理が可能）なハードウェアデバイスを示している。
また、連携可能他アプリケーションは、オーダー端末１Ａが備えている、オーダーアプリケーション２０Ａ及び決済アプリケーション１０以外のアプリケーションのなかで、オーダーアプリケーション２０Ａが連携可能なアプリケーション（例えば、代金の割り勘を行なうアプリケーションやポイント付与のアプリケーションなど）を示している。

また、オーダー端末１Ａが備えるオーダーアプリケーション２０Ａには、すでに述べたように、決済アプリケーション１０を配給するメーカが配給する連携ＡＰＩモジュール２１が組み込まれている。
連携ＡＰＩモジュール２１は、プログラムライブラリとして、読出関数である決済アプリケーション連携呼出モジュールが備えられている。

オーダーアプリケーション２０Ａは、連携ＡＰＩモジュール２１の決済アプリケーション連携呼出モジュールを介して、会計を行なう際に決済処理と連携するため、飲食の代金と、テーブル番号とを含む会計情報を読み出し、決済認証アプリケーション１１に対して出力する。これにより、決済認証アプリケーション１１は、オーダーアプリケーション２０Ａから認証情報として、オーダーアプリケーション２０Ａのアプリケーション識別情報などを読み込む。

また、オーダーアプリケーション２０Ａは、連携ＡＰＩモジュール２１のデバイス連携呼出モジュールを介して、オーダー端末１Ａが搭載する決済処理に用いるハードウェアデバイスを使用する場合、使用するハードウェアデバイスの情報を、連携ＡＰＩモジュール２１を介して決済認証アプリケーション１１に対して出力する。決済認証アプリケーション１１は、オーダーアプリケーション２０Ａから認証情報を読み込み、認証情報とともにハードウェアデバイスの情報を、連携データ照合サーバ３０に対して出力し、連携可能であるかの認証を依頼する。

また、オーダーアプリケーション２０Ａが連携ＡＰＩモジュール２１の非決済アプリケーション連携呼出モジュール２１３を介して他アプリケーションを使用する依頼を行なった場合も、決済認証アプリケーション１１は、上述した連携データ照合サーバ３０を用いたオーダーアプリケーション２０Ａの認証処理を行ない、オーダーアプリケーション２０Ａが他アプリケーションと連携可能か否かの判定を行なう。すなわち、決済認証アプリケーション１１からの連携データ照合サーバ３０に対する認証の依頼は、決済アプリケーション１０や他のアプリケーションとの連携毎に行なわれる。

以下、図１１、図１２及び図１３の各々を用いて、本実施形態のオーダー決済連携システムにおけるオーダー及び決済の連携処理を説明する。図１２は、テーブルに配置されたオーダー端末１Ａでセルフオーダーを行ない、セルフ決済を行なう処理を説明する概念図である。図１３は、連携処理におけるオーダー端末１Ａの表示画面の遷移を説明する概念図である。
図１１は、本実施形態のオーダー決済連携システムにおけるオーダー及び決済の連携処理の動作例を示すフローチャートである。以下の説明において、オーダーアプリケーション２０Ａの認証に用いる認証情報を、オーダーアプリケーション２０Ａのアプリケーション識別情報のみとする。

ステップＳ２０１：
図１２に示す様に、例えば、客２００は、入店して、店員２５０の座席案内によりテーブル２６０の席に着席する。
そして、客２００は、テーブル２６０の各々に配置されているタブレット端末であるオーダー端末１Ａにより、自身により飲食する商品を選択して注文を行なう（セルフオーダー）。このとき、図１３に示す様に、オーダー端末１Ａにおけるオーダーアプリケーション２０Ａは、オーダー端末１Ａの表示画面１０Ｓに対し、飲食する商品のメニューを表示する（図１３のＦ１）。

ここで、客２００は、表示画面１０Ｓに表示されたメニューから飲食する商品を選択し、表示画面１０Ｓに表示されるメニュー選択画面から、メニューから選択した商品の注文を行なう（図１３のＦ２）。
また、客２００は、飲食する商品の追加注文なども、オーダー端末１Ａを用いたセルフオーダーにより行なう。

ステップＳ２０２：
客２００は、飲食が終了した後、オーダー端末１Ａの表示画面１０Ｓに表示されている会計ボタンを選択してタッチするなどし、飲食の代金（飲食した商品の合計金額）の会計を指示する処理を行なう（会計処理：図１３のＦ３）。
これにより、オーダーアプリケーション２０Ａは、決済処理との連携を行なう処理（連携処理）を開始する。すなわち、オーダーアプリケーション２０Ａは、連携ＡＰＩモジュール２１に対して、連携処理を行なう命令を出力する。

また、オーダー端末１Ａがテーブル２６０に配置されておらず、店員２５０がオーダー端末１Ａを携帯している場合、客２００は会計の際に店員２５０を呼ぶ。
そして、店員２５０が携帯するオーダー端末１Ａを借りて、テーブル２６０に配置されたオーダー端末１Ａと同様にセルフ決済の処理を行なう。
このとき、オーダーアプリケーション２０Ａは、オーダー端末１Ａにおいて決済可能な決済方法の決済種類を、表示画面１０Ｓに表示し、客２００に対して利用したい決済の決済種類の選択を行なうように促す表示を行なう（図１３のＦ４）。
そして、客２００は、表示画面１０Ｓに表示された決済方法の決済種類から、自身の利用する決済方法を選択する。
これにより、オーダーアプリケーション２０Ａは、連携ＡＰＩモジュール２１に対して、飲食の代金の決済方法を出力する。

連携ＡＰＩモジュール２１は、オーダーアプリケーション２０Ａから、このオーダーアプリケーション２０Ａの認証に用いる認証情報としてアプリケーション識別情報、客２００の飲食の代金及び選択された利用したい決済の種類の各々の供給を受ける。

ステップＳ２０３：
連携ＡＰＩモジュール２１は、オーダーアプリケーション２０Ａの認証情報であるアプリケーション識別情報及び飲食の代金の各々を、連携処理依頼情報をして出力する。
このとき、連携ＡＰＩモジュール２１は、オーダーアプリケーション２０Ａが決済種類を選択する機能を有している場合、決済方法も上記連携処理依頼情報に含めて、決済アプリケーション１０に対して出力する。一方、連携ＡＰＩモジュール２１は、オーダーアプリケーション２０Ａが決済種類を選択する機能を有していない場合、決済方法を上記連携処理依頼情報に含めず、この連携処理依頼情報を決済アプリケーション１０に対して出力する。

そして、決済アプリケーション１０は、連携処理依頼情報に決済方法の決済種類（決済種別）が含まれているか否かの判定を行なう。
このとき、決済アプリケーション１０は、連携処理依頼情報に決済方法の決済種類が含まれている場合、処理をステップＳ２０７へ進める。一方、決済アプリケーション１０は、連携処理依頼情報に決済方法の決済種類が含まれていない場合、処理をステップＳ２０４へ進める。

ステップＳ２０４：
決済アプリケーション１０は、決済認証アプリケーション１１を介して連携データ照合サーバ３０に対してオーダーアプリケーション２０Ａの認証情報であるアプリケーション識別情報を送信する。
そして、決済アプリケーション１０は、オーダーアプリケーション２０Ａが連携処理として利用可能な決済方法の決済種類を、決済認証アプリケーション１１を通して、連携データ照合サーバ３０へ問い合わせる。

ステップＳ２０５：
これにより、連携データ照合サーバ３０において、連携可否照合部３１は、照合データベース３２における連携処理対応付テーブルを参照し、問い合せのオーダーアプリケーション２０Ａに応付けられている（使用可能とされている）決済方法の決済種類を抽出する。
そして、連携可否照合部３１は、抽出した決済種類の各々を（決済種類が一つの場合も含む）を、照合結果として決済認証アプリケーション１１及び連携ＡＰＩモジュール２１を通してオーダーアプリケーション２０Ａに対して返信する。
なお、決済アプリケーション１０は、オーダー端末１Ａで決済が可能な決済方法の各々を、表示画面１０Ｓに表示し（図１３のＦ５）、客２００に対して、そのなかから使用したい決済方法を選択することを促す。

ステップＳ２０６：
そして、客２００は、表示画面１０Ｓに表示されている決済方法のなかから、自身が利用を希望する決済方法を選択する。
決済アプリケーション１０は、客が選択した決済方法を決済種類として一時的に記憶する。あわせて、オーダーアプリケーション２０Ａは、照会結果と共に決済アプリケーション１０を連携ＡＰＩモジュール２１を通して起動する。

ステップＳ２０７：
決済アプリケーション１０は、決済種類に対応したカードの読取りのハードウェアを起動し、客２００に対してカード情報の入力を促す。
例えば、決済アプリケーション１０は、クレジットカードであれば、オーダー端末１Ａに設けられたＩＣ（integrated circuit ）カードリーダを起動し、表示画面１０Ｓに対して、「クレジットカードをどうぞ」などの文字情報を表示して、クレジットカードをＩＣカードリーダに近接させることを促す（図１３のＦ６）。

そして、決済アプリケーション１０は、ＩＣカードリーダを介してクレジットカード２７から、ＩＣチップに記録されているカード番号を読み込む（図１２）。
また、決済アプリケーション１０は、客２００に対して、クレジットカードに対して設定しているパスワード（ＰＩＮコード）を入力するように促す。
客２００は、オーダー端末１Ａの表示画面１０Ｓに表示されるテンキーから、自身がクレジットカードに対して設定しているパスワードを入力する。

ステップＳ２０８：
決済アプリケーション１０は、アプリケーション識別情報を認証情報として、また飲食の代金、決済種類（クレジットカード決済）、カード番号及びパスワードの各々を決済情報として、オーダー決済連携サーバ４０に対して送信する。
このとき、決済種類としてＱＲコード（登録商標）決済を選択した場合、決済情報としては、飲食の代金、決済種類（ＱＲコード（登録商標）決済）及びＱＲコード（登録商標）の各々である。また、決済種類として電子マネー決済を選択した場合、決済情報としては、飲食の代金、決済種類（電子マネー決済）及びカード番号（カード裏面の暗証番号）の各々である。

ステップＳ２０９：
決済認証アプリケーション１１は、オーダー端末１Ａから供給された連携依頼における認証情報を読み込む。
そして、決済認証アプリケーション１１は、読み込んだ認証情報を連携データ照合サーバ３０へ送信し、オーダー端末１Ａの備えるオーダーアプリケーション２０Ａが、決済処理と連携可能か否かの判定を依頼する。

ステップＳ２１０：
連携データ照合サーバ３０において、連携可否照合部３１は、照合データベース３２における連携処理対応付テーブルを参照し、依頼された認証情報に対応して連携可能として設定されている決済種類のなかに、依頼された決済方法があるか否かの判定を行なう。
そして、連携可否照合部３１は、認証情報に対応した決済種類のなかに依頼された決済方法が検出されれば、認証結果がＯＫであることを示す照合結果をオーダー決済連携サーバ４０に対して返信し、処理をステップＳ１１１へ進める。
一方、連携可否照合部３１は、認証情報に対応した決済種類のなかに依頼された決済方法が検出されなければ、認証結果がＮＧであることを示す照合結果を、オーダー決済連携サーバ４０に対して返信する。

ステップＳ２１１：
決済認証アプリケーション１１は、連携データ照合サーバ３０から認証情報に対する連携処理が可能であるとの照合結果を得た場合、決済処理を決済処理アプリケーション４１に対して指示する。
決済処理アプリケーション４１は、決済方法に対応して、例えば所定のクレジット会社のサーバに対して、飲食の代金、カード番号及びパスワードを出力し、飲食の代金の決済を依頼する。

そして、クレジット会社のサーバは、オーダー決済連携サーバ４０から入力されるカード番号及びパスワードの各々が自身のデータベースに登録されているか否か、すなわち決済を行なっても良いか否かの判定を行なう。
このとき、クレジット会社のサーバは、カード番号及びパスワードの各々が自身のデータベースに登録されている場合、入力された飲食の代金の決済を行なった後、決済が正常に完了したことを示す通知（決済ＯＫ）をオーダー決済連携サーバ４０に対して送信する。一方、クレジット会社のサーバは、カード番号及びパスワードの各々が自身のデータベースに登録されていない場合、入力された飲食の代金の決済を行なわずに、決済を正常に行なえないことを示す通知（決済ＮＧ）をオーダー決済連携サーバ４０に対して送信する。

ステップＳ２１２：
決済処理アプリケーション４１は、クレジット会社のサーバから供給される通知が、決済ＯＫかあるいは決済ＮＧかの判定を行なう。
そして、決済処理アプリケーション４１は、クレジット会社のサーバから供給される通知が決済ＯＫの場合、処理をステップＳ２１３へ進める。
一方、決済処理アプリケーション４１は、クレジット会社のサーバから供給される通知が決済ＮＧの場合、表示画面１０Ｓに再度、決済情報の入力を促す表示を行ない、処理をステップＳ２０７へ進める。

ステップＳ２１３：
決済処理アプリケーション４１は、オーダー端末１Ａに対して、決済処理が正常に完了したことを示す正常完了通知（決済の結果の通知）を出力する。

ステップＳ２１４：
オーダー端末１Ａにおいて、決済アプリケーション１０は、自身が決済種類の表示を行った場合、表示画面１０Ｓに対して、正常に決済処理が終了したことを表示する（図１３のＦ７）。
これにより、客２００は、セルフ決済により、飲食の代金の支払が終了したことを確認する。

また、決済アプリケーション１０は、連携ＡＰＩモジュール２１を介して、オーダーアプリケーション２０Ａに対して、正常完了通知を出力する。
そして、オーダーアプリケーション２０Ａにおける決済終了報告アプリケーションは、飲食店の会計場所にある会計サーバ（店舗サーバ）、及び飲食店を管理する本部の本部サーバに対して出力する。

また、オーダー端末１Ａにおいて、決済アプリケーション１０は、自身が決済種類の表示を行わなかった場合、正常に決済処理が終了したことを、連携ＡＰＩモジュール２１を介して、オーダーアプリケーション２０Ａに対して通知する。
そして、オーダーアプリケーション２０Ａは、自身が決済種類の表示を行った場合、表示画面１０Ｓに対して、正常に決済処理が終了したことを表示する（図１３のＦ８）。
この場合にも、オーダーアプリケーション２０Ａにおける決済終了報告アプリケーションは、飲食店の会計場所にある会計サーバ（店舗サーバ）、及び飲食店を管理する本部の本部サーバに対して出力する。

ステップＳ２１５：
決済アプリケーション１０は、オーダーアプリケーション２０Ａに対してのみではなく、飲食店の現金で会計管理を行なう会計管理コンピュータに対して、テーブル２６０を識別する情報を付加して、飲食の代金及び決済が終了したことを通知する。
これにより、飲食店の店員２５０は、会計サーバにより、テーブル２６０の各々における、客２００によるオーダー端末１Ａを用いたセルフ決済の処理が終了したか否かの確認が行なえる。

そして、店員２５０は、客２００に対する支払処理を行なうことなく、通知されたテーブル２６０の皿やコップなどの片付けを行い、次の客に対応する準備を行なうことができる。
そのため、会計に人の手が必要なくなり、店員２５０の作業が料理を運んだり、テーブル２６０の片付けを行なうのみとすることが可能となり、飲食店における店員２５０の作業の効率化を図ることができる。

また、飲食店がチェーン店である場合、決済アプリケーション１０は、オーダーアプリケーション２０Ａに対してのみではなく、チェーン店を統括する本部の売上管理サーバなどに対して、飲食した商品の種類と、それぞれの商品の単価及び注文数と、その合計金額である飲食の代金との各々を出力する。
これにより、チェーン店の本部において、飲食店の店舗毎において、売上の管理、商品の種類毎の数量の在庫管理、新しい商品の開発などの統計的な処理を行なうことができる。

上述したように、本実施形態によれば、オーダー端末１Ａ一台にオーダー機能と決済機能とを備えたため、飲食店などでテーブル毎にオーダー端末１Ａを配置することにより、客がテーブルの席に座った状態で、商品のセルフオーダー及び飲食の代金のセルフ決済を行なうことができる。
また、本実施形態によれば、客自身が決済処理を行なうため、決済の媒体であるクレジットカードや電子マネーのカードを店員に渡すことなく、客自身がカードを携帯して決済を行なうことができるので、セキュリティを向上させることができ、客の安心感を満足させることができる。

また、本実施形態によれば、テーブルにオーダー端末１Ａを一台配置することにより、客がセルフオーダー及びセルフ決済が行えるため、テーブル上における端末が占有する領域を少なくすることができ、テーブル面における利用効率を向上させることができる。
また、本実施形態によれば、オーダーアプリケーション２０Ａを従来のアプリケーションを、連携ＡＰＩモジュールを埋め込むことにより、ほぼそのまま使用できるため、新たに作成する必要が無いため、オーダー端末１Ａに対して簡易にオーダー機能と決済機能とを備えさせることができる。

図１４は、キオスク券売機から本実施形態によるオーダー端末への置き換えを説明する概念図である。
図１４（ａ）は、駅などにあるキオスクが運営する飲食店で現在用いられているキオスク券売機３００の外観を示している。このキオスク券売機３００は、前面において、領域３０１に商品の写真などが貼付され、領域３０２に各商品の購入に用いる選択ボタンが配設され、領域３０３に選択する商品の代金を入金したり、商品と引き替える引換券やおつりを出力したりする機能が配設されている。

キオスク券売機３００は、客がお金を入れて商品の選択ボタンを押下した場合、選択された商品（料理や飲み物）の引換券を出力するとともに、作成指示を厨房のエントリーシステムに出力する。そして、厨房の調理する担当者が料理を作成し、客が作成された商品と引換券とを交換して商品を取得する。
しかしながら、飲食店において料理や飲み物などの商品を入れ替える場合、キオスク券売機３００のボタンに取り付けられている商品名や商品の価格などを交換したり、商品の写真を差し替える手間がかかる。また、飲食店で販売する商品の価格が変更となった場合も同様に、ボタンに表示されている価格を交換する必要がある。

図１４（ｂ）は、本実施形態によるオーダー端末１Ａを用いたキオスク券売機を示している。この場合、オーダー端末１Ａの表示画面１０Ｓに商品及び価格とを表示して運用する。このため、飲食店の商品を入れ替えたり、商品の価格を変更したりした場合、オーダー端末１Ａにおける商品のデータベースを変更するのみで、商品の入れ替えや価格変更の処理が行える。このため、オーダー端末１Ａを用いることにより、上述したキオスク券売機３００における商品の入れ替えや価格変更の処理を容易に行なうことが可能となる。
また、客はクレジットカードや電子マネーカードなどの決済方法により、容易にセルフ決済の処理を行なうことができ、現金を所持していない場合でも、飲食を行なうことが可能となる。

また、第１の実施形態と同様に、図１に示すダウンロードセンター４００のダウンロードサーバ４を経由して、オーダーアプリケーション２０Ａや非決済アプリケーション２０をダウンロードして、これらのアプリケーションのインストール及び活性化を行なって使用しても良い。
また、本実施形態においては、飲食店の商品の注文を行なうオーダー端末を一例として説明したが、例えば被服、靴などの商品を販売する商業施設などにおけるオーダー端末として用いても良い。

また、図９に示すオーダー決済連携システム１００Ａのオーダー端末１Ａにおける決済アプリケーション１０、決済認証アプリケーション１１及びオーダーアプリケーション２０と、オーダー決済連携サーバ４０における決済処理アプリケーション４１と、連携データ照合サーバ３０との各々の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、オーダー端末１Ａ及びオーダー決済連携サーバ４０間における決済処理の連携を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１Ａ，１Ａ－１，１Ａ－ｎ…オーダー端末
３…連携データ照合サーバ
４…ダウンロードサーバ
４＿１…アプリケーションデータベース
４＿２…管理データベース
１０Ｓ…表示画面
１０…決済アプリケーション
１１…決済認証アプリケーション
２０…非決済アプリケーション
２０Ａ…オーダーアプリケーション
２１…連携ＡＰＩモジュール
３０…連携データ照合サーバ
３１…連携可否照合部
３２…照合データベース
４０…オーダー決済連携サーバ
４１…決済処理アプリケーション
１００…決済サービス連携システム
１００Ａ…オーダー決済連携システム
１０５…情報通信網
１１１…決済アプリケーション連携インターフェースモジュール
１１２…デバイス連携インターフェースモジュール
１１３…非決済アプリケーション連携インターフェースモジュール
１１４…認証モジュール
１１５…決済アプリケーション連携モジュール
１１６…非決済アプリケーション連携モジュール
２１１…決済アプリケーション連携呼出モジュール
２１２…デバイス連携呼出モジュール
２１３…非決済アプリケーション連携呼出モジュール
４００…ダウンロードセンタ

Claims (4)

1. 注文を行なうためのオーダー端末であり、
   オーダーアプリケーションで実行される、注文を入力する注文処理を行なう注文処理部と、
   決済アプリケーションで実行される、代金の決済処理を行なう決済処理部と、
   前記オーダーアプリケーションと前記決済アプリケーションとの連携処理の可否を、決済認証アプリケーションで実行される判定の処理により行なう認証部と
   を備え、
   前記オーダーアプリケーションが、前記決済処理を行なう決済方法の種類である決済種類を選択する選択画面を表示し、前記オーダーアプリケーションを認証するための認証情報とともに前記決済種類及び前記代金の情報を有する決済情報を、前記決済アプリケーションへ出力し、
   前記認証部は、前記決済アプリケーションへ出力された前記認証情報に基づき、前記オーダーアプリケーションが決済連携可能なアプリケーションであるか否かの判定を行なう
   ことを特徴とするオーダー端末。
2. 前記オーダーアプリケーションが、前記オーダーアプリケーションを認証するための認証情報である自身の認証情報とともに前記決済処理を行なう前記代金の情報を有する決済情報を、前記決済アプリケーションへ出力する連携アプリケーションを備え、
   前記決済アプリケーションが、前記オーダー端末に対して決済方法の種類である決済種類を選択する選択画面を表示させ、決済に用いられる前記決済種類を取得する
   ことを特徴とする請求項１に記載のオーダー端末。
3. 注文を入力するオーダーアプリケーションと、代金の決済要求を行なう決済アプリケーションとを有するオーダー端末を用いたセルフ決済方法であり、
   前記オーダーアプリケーションが注文を入力する注文処理過程と、
   前記決済アプリケーションが代金の決済処理を行なう決済処理過程と、
   前記オーダーアプリケーションと前記決済アプリケーションとの連携処理の可否を、決済認証アプリケーションで実行される判定の処理により行なう認証過程と
   を備え、
   前記オーダーアプリケーションが、前記決済処理を行なう決済方法の種類である決済種類を選択する選択画面を表示し、前記オーダーアプリケーションを認証するための認証情報とともに前記決済種類及び前記代金の情報を有する決済情報を、前記決済アプリケーションへ出力し、
   前記認証過程において、前記決済アプリケーションへ出力された前記認証情報に基づき、前記オーダーアプリケーションが決済連携可能なアプリケーションであるか否かの判定を行なう
   ことを特徴とするセルフ決済方法。
4. 注文を行なうためのオーダー端末としてコンピュータを機能させるためのプログラムであり、
   前記コンピュータを、
   注文を入力するオーダーアプリケーション手段、
   代金の決済処理を行なう決済アプリケーション手段、
   前記オーダーアプリケーション手段と前記決済アプリケーション手段との連携処理の可否の判定の処理を行なう決済認証アプリケーション手段
   として機能させ、
   前記オーダーアプリケーション手段が、前記決済処理を行なう決済方法の種類である決済種類を選択する選択画面を表示し、前記オーダーアプリケーション手段を認証するための認証情報とともに前記決済種類及び前記代金の情報を有する決済情報を、前記決済アプリケーション手段へ出力し、
   前記決済認証アプリケーション手段が、前記決済アプリケーション手段へ出力された前記認証情報に基づき、前記オーダーアプリケーション手段が決済連携可能なアプリケーション手段であるか否かの判定を行なう
   ためのプログラム。

Images