JP6987957B1 - 決済装置、プログラム、及び情報処理方法 - Google Patents

Abstract

【課題】食事の記録を行う複数のサービスに対して飲食施設でのユーザの食事の記録を支援できる決済装置、プログラム及び情報処理方法を提供する。【解決手段】複数の飲食施設とネットワークを介して接続する決済装置１００は、食事を記録するサービスをユーザに提供する複数のサービスの中から、記録先条件に基づいて、第１ユーザの食事に関する食事データの記録先である少なくとも１つのサービスを特定する記録先特定部、飲食施設の施設端末から飲食施設での食事に対する代金の第１ユーザによる支払いの際、支払いの決済要求を受け付ける要求受付部、決済要求に基づいて、支払いの決済のための決済処理を行う決済処理部、施設端末から決済処理が行われた場合、飲食施設での食事に関する食事データを取得する食事データ取得部１１４１及び食事データを特定された少なくとも１つのサービスの、夫々のサービス提供装置に送信する食事データ送信部１３１を備える。【選択図】図５

Description

本発明は、決済装置、プログラム、及び情報処理方法に関する。

従来、健康管理などのためにユーザの食事の記録を行うサービスが存在する。このようなサービスの提供にあたっては、飲食施設での食事についても記録の対象となる。下記特許文献１には、複数の飲食施設の位置と飲食店それぞれで提供する料理名を飲食店データベースに保持し、ユーザが食事をした位置や日時に基づいて、この飲食施設データベースから料理名の候補を抽出する食事履歴システムが開示されている。この食事履歴システムは、抽出した料理名の候補をユーザに提示して、この候補の中からユーザが食事した料理名の選択を受け付けて、選択された料理名をユーザと対応付けて履歴データベースに蓄積する。このような構成によれば、食事の記録にあたり、食事の情報をユーザが入力する手間を軽減することができる。

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

ところで、近年、食事の記録を行うサービスについて、ダイエットを目的としたものや企業における社員の健康管理を目的としたものなど、様々なサービスが存在する。しかしながら、上記特許文献では、一つのサービス（データベース）で食事を記録することしか想定されておらず、ユーザが複数のサービスを利用する場合に対応することができないという課題がある。

そこで、本発明は、上記課題に鑑み、食事の記録を行う複数のサービスに対して飲食施設でのユーザの食事の記録を支援できる決済装置、プログラム、及び情報処理方法を提供することを目的とする。

本発明の一態様に係る決済装置は、食事を記録するサービスをユーザに提供する複数のサービスの中から、記録先条件に基づいて、第１ユーザの食事に関する食事データの記録先である少なくとも１つのサービスを特定する記録先特定部と、飲食施設の施設端末から、飲食施設での食事に対する代金の第１ユーザによる支払いの際、支払いの決済要求を受け付ける要求受付部と、決済要求に基づいて、支払いの決済のための決済処理を行う決済処理部と、施設端末から、決済処理が行われた場合、飲食施設での食事に関する食事データを取得する食事データ取得部と、食事データを、特定された少なくとも１つのサービスのそれぞれのサービス提供装置に送信する食事データ送信部と、を備える。

本発明の一態様に係るプログラムは、コンピュータに、食事を記録するサービスをユーザに提供する複数のサービスの中から、記録先条件に基づいて、第１ユーザの食事に関する食事データの記録先である少なくとも１つのサービスを特定する記録先特定機能と、飲食施設の施設端末から、前記飲食施設での食事に対する代金の前記第１ユーザによる支払いの際、前記支払いの決済要求を受け付ける要求受付機能と、前記決済要求に基づいて、前記支払いの決済のための決済処理を行う決済処理機能と、前記施設端末から、前記決済処理が行われた場合、前記飲食施設での食事に関する前記食事データを取得する食事データ取得機能と、前記食事データを、前記特定された少なくとも１つのサービスのそれぞれのサービス提供装置に送信する食事データ送信機能と、を実現させる。

本発明の一態様に係る情報処理方法は、食事を記録するサービスをユーザに提供する複数のサービスの中から、記録先条件に基づいて、第１ユーザの食事に関する食事データの記録先である少なくとも１つのサービスを特定し、飲食施設の施設端末から、飲食施設での食事に対する代金の第１ユーザによる支払いの際、支払いの決済要求を受け付け、決済要求に基づいて、支払いの決済のための決済処理を行い、施設端末から、決済処理が行われた場合、飲食施設での食事に関する食事データを取得し、食事データを、特定された少なくとも１つのサービスのそれぞれのサービス提供装置に送信する。

本発明によれば、食事の記録を行う複数のサービスに対して飲食施設でのユーザの食事の記録を支援できる決済装置、プログラム、及び情報処理方法を提供することができる。

本実施形態に係る統合決済システムのシステム構成例を説明するための図である。 本実施形態に係る統合決済システムの概要を説明するための図である。 本実施形態に係る統合決済システムの概要を説明するための図である。 本実施形態に係る統合決済システムの概要を説明するための図である。 本実施形態に係る決済装置の機能構成の一例を示す図である。 本実施形態に係る統合決済システムの画面例を示す図である。 本実施形態に係る統合決済システムの画面例を示す図である。 本実施形態に係る統合決済システムの画面例を示す図である。 本実施形態に係る統合決済システムのデータ構成例を示す図である。 本実施形態に係る統合決済システムのデータ構成例を示す図である。 本実施形態に係る統合決済システムの動作例を示す図である。 本実施形態に係る統合決済システムの動作例を示す図である。 本実施形態に係る統合決済システムの動作例を示す図である。 本実施形態に係る決済装置のハードウェア構成の一例を示す図である。 本実施形態に係る統合決済システムの食事データの連携方式の例を説明するための図である。

添付図面を参照して、本発明の好適な実施形態（以下、「本実施形態」という）について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

本実施形態において、「部」や「装置」、「システム」とは、単に物理的手段を意味するものではなく、その「部」や「手段」、「装置」、「システム」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や「装置」、「システム」が有する機能が２つ以上の物理的手段や装置により実現されても、２つ以上の「部」や「装置」、「システム」の機能が１つの物理的手段や装置により実現されてもよい。

＜１．概要＞
本実施形態では、ヘルスケア業界に属する複数の事業者から構成されるコンソーシアム（以下、「ヘルスケアコンソーシアム」ともいう）が、事業者の顧客に対して、以下の機能を提供する例を説明する。
・複数の事業者が所有する飲食施設を利用する顧客に対して、これらの事業者の電子決済手段を統合する機能（以下、「統合決済機能」ともいう）
・飲食施設を利用して上記電子決済手段で決済した際に、飲食施設が作成する顧客の食事データを、顧客の食事を記録するサービス等を提供するサービス（以下、「食事関連サービス」ともいう）に連携する機能（以下、「食事データ・ハブ（ＧＷ）機能」ともいう）

飲食施設とは、有料の飲食サービスを提供する施設であればどのような施設でもよく、例えば、飲食店や顧客が勤務する会社の社員食堂等であってもよい。

食事関連サービスは、顧客の食事データを記録するサービス（以下、「記録サービス」ともいう）を含んでいればどのようなサービスであってもよい。食事関連サービスは、例えば、顧客の食事を管理するためのサービス（以下、「食事管理サービス」ともいう）であってもよい。また、食事関連サービスは、例えば、顧客のヘルスケアに関するサービス（以下、「ヘルスケアサービス」ともいう）であってもよいし、顧客のダイエットをサポートするためのサービス（以下、「ダイエットサポートサービス」ともいう）であってもよい。

本実施形態では、ヘルスケアコンソーシアムが、統合決済機能を顧客に提供するにあたって、本実施形態に係る統合決済システム１を利用する例を説明する。統合決済システム１の適用に関して、電子決済手段を統合する対象の複数の事業者は、例えば、ヘルスケア業界以外の特定の業界に属する複数の事業者であってもよく、また、共通の業界に属さなくとも共通の目的や方針等を持つ複数の事業者であってもよい。

本実施形態に係る事業者（以下、単に「事業者」ともいう）は、ヘルスケアコンソーシアムに所属して、それぞれの顧客である統合決済システム１のユーザ（以下、単に「ユーザ」という）に対して飲食サービスを提供する飲食施設を所有する。ユーザは、第１ユーザと、第１ユーザとは異なる第２ユーザとを含む。第２ユーザは、第１ユーザに関連するユーザであってもよく、例えば、第１ユーザと第２ユーザとは同じ家族であってもよいし、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）における第１ユーザのアカウントに対して登録された友達やフォロワー等であってもよい。

＜１−１．システム構成＞
図１を参照して、統合決済システム１のシステム構成例を説明する。

統合決済システム１は、統合決済機能や食事データ・ハブ機能をユーザや食事関連サービスの提供者等に提供するためのシステムである。また、統合決済システム１は、自らもヘルスケアサービスをユーザに提供するためのシステムでもある。図１に示すように、統合決済システム１は、決済装置１００と、第１ユーザが使用する第１ユーザ装置２００ａと、第２ユーザが使用する第２ユーザ装置２００ｂと、第１飲食施設の第１施設端末３００ａと、第２飲食施設の第２施設端末３００ｂと、第１事業者が有する第１事業者サーバ４００ａと、第２事業者が有する第２事業者サーバ４００ｂと、を含む。第１事業者は第１飲食施設を所有し、第２事業者は第２飲食施設を所有する。

第１ユーザ装置２００ａと第２ユーザ装置２００ｂとは、ユーザ装置の一態様であり、特に区別の必要が無い場合は、まとめて「ユーザ装置２００」という。また、第１施設端末３００ａと第２施設端末３００ｂとは、施設端末の一態様であり、特に区別の必要が無い場合は、まとめて「施設端末３００」という。また、第１飲食施設と第２飲食施設とは、特に区別の必要が無い場合は、まとめて「飲食施設」という。また、第１事業者サーバ４００ａと第２事業者サーバ４００ｂとは、事業者サーバの一態様であり、特に区別の必要が無い場合は、まとめて「事業者サーバ４００」という。

決済装置１００とユーザ装置２００と事業者サーバ４００とは、ネットワークＮ１を介して互いに接続されている。また、事業者サーバ４００と施設端末３００とは、ネットワークＮ１又は事業者独自に構築したネットワークＮ２を介して互いに接続されている。

決済装置１００及びユーザ装置２００の少なくとも一つは、ユーザのヘルスケアデータを取得し食事データを連携するために、ネットワークＮ１を介してヘルスケアサービスを提供する第１外部システム５ａの第１サービス提供装置５００ａと接続されている。第１外部システム５ａが提供するヘルスケアサービスには、ユーザの食事を記録するサービスも含まれているものとする。また、決済装置１００及びユーザ装置２００の少なくとも一つは、ユーザの食事データを連携するために、ネットワークＮ１を介して食事管理サービスを提供する第２外部システム５ｂの第２サービス提供装置５００ｂと接続されている。

第１外部システム５ａと第２外部システム５ｂとは、特に区別の必要が無い場合は、まとめて「外部システム５」という。第１サービス提供装置５００ａと第２サービス提供装置５００ｂとは、サービス提供装置の一態様であり、特に区別の必要が無い場合は、まとめて「サービス提供装置５００」という。

ネットワークＮ１又はＮ２は、無線ネットワークや有線ネットワークにより構成される。ネットワークの一例としては、携帯電話網や、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ−ｐｈｏｎｅ Ｓｙｓｔｅｍ）網、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、４Ｇ（４ｔｈ Ｇｅｎｅｒａｔｉｏｎ）、５Ｇ（５ｔｈ Ｇｅｎｅｒａｔｉｏｎ）、ＷｉＭａｘ（登録商標）、赤外線通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）、有線ＬＡＮ、電話線、電灯線ネットワーク、ＩＥＥＥ１３９４等に準拠したネットワークがある。

「ヘルスケアデータ」とは、ユーザのヘルスケアに関するデータである。ヘルスケアデータは、例えば、ユーザの身体の状態を示す身体データ、又はユーザの活動量を示す活動データの少なくとも一つを含む。身体データは、例えば、ユーザの「体重」、「身長」、「体脂肪率」、「体温」、「血圧」、「心拍」、「体年齢」、「睡眠データ」又はユーザが受診した健康診断の結果を示す健康診断結果情報等を含んでもよい。活動データは、例えば、所定の期間あたりのユーザの「歩数」、「消費カロリー」又は「移動距離」等を含んでもよい。ヘルスケアデータは、例えば、ユーザの食事データを含んでもよい。「食事データ」とは、ユーザの食事に関するデータである。食事データの詳細は、図９を参照して後述する。

決済装置１００は、ユーザ装置２００、事業者サーバ４００及び外部システム５との通信や複数の事業者それぞれの電子決済手段を統合可能な情報処理装置である。決済装置１００は、所定のプログラムを実行することにより、ユーザ装置２００と連携して、飲食施設からユーザへの飲食サービスの提供により生じた代金の支払いの決済（以下、単に「支払いの決済」又は「決済」ともいう）のための処理を制御するサーバ機能を実現する。また、決済装置１００は、施設端末３００及びサービス提供装置５００と連携して、施設端末３００から取得したユーザの食事データを、サービス提供装置５００に提供する。

ユーザ装置２００は、スマートフォンやラップトップ等の端末装置であり、ユーザからの決済要求の受け付け等の入力や決済装置１００との通信を行う。ユーザ装置２００は、所定のプログラムを実行することにより、決済装置１００と連携して決済に関する情報や食事データを送受信したり決済や食事に関する画面を表示したりユーザの要求を受け付けたりする。この所定のプログラムは、例えば、ユーザ向けの統合決済システム１専用のネイティブアプリケーションプログラム（以下、「ユーザ用決済アプリ」という）であってもよい。

施設端末３００は、事業者が所有する飲食施設に設置された支払い決済のための端末装置である。施設端末３００は、例えば、バーコードリーダー機能を備えるＰＯＳレジ端末、タブレット端末、又はハンディ端末等である。

施設端末３００は、例えば、注文されたメニューの入力の受け付け、及び受け付けたメニューの代金（飲食代）の合計金額（決済金額）の算出等のＰＯＳレジ機能を備えてもよい。また、施設端末３００は、飲食施設向けの統合決済システム１専用のネイティブアプリケーションプログラムをインストールすることで、上記のＰＯＳレジ機能を実現させてもよい。また、施設端末３００は、上記のＰＯＳレジ機能を実現にあたって、飲食の売上に関する情報を管理するＰＯＳシステムに接続された端末として構成されてもよい。

第１外部システム５ａは、食事関連サービスの一つであるヘルスケアサービスをユーザに提供するためのシステムである。第１外部システム５ａは、決済装置１００又はユーザ装置２００と連携して、ユーザのヘルスケアデータを決済装置１００等に提供する。第１外部システム５ａは、第１サービス提供装置５００ａを含む。第１サービス提供装置５００ａは、例えば、ユーザのヘルスケアデータを測定する測定装置であってもよい。第１サービス提供装置５００ａは、例えば、ユーザに装着されて当該ユーザの歩数や心拍等を測定する、いわゆるウェアラブル・デバイスであってもよい。

第２外部システム５ｂは、食事関連サービスの一つである食事管理サービスをユーザに提供するためのシステムである。第２外部システム５ｂは、決済装置１００と連携して、決済装置１００から提供されたユーザの食事データを記録する。第２外部システム５ｂは、第２サービス提供装置５００ｂを含む。第２サービス提供装置５００ｂは、決済装置１００と通信可能な情報処理装置であり、例えば、サーバ装置であってもよい。

＜１−２．統合決済機能の概要＞
図２を参照して、本実施形態に係る統合決済機能の流れ（１）〜（５）の例を説明する。なお、本例では、説明を簡単にするため、ユーザ装置２００には、ユーザ用決済アプリが予めインストールされているものとする。また、本例では、説明を簡単にするため、ユーザＵが代金の支払い方法として登録するＱＲコード（登録商標）を用いるコード決済に、ユーザＵの銀行口座による銀行振込を対応付けているものとする。ここで「コード決済」とは、一次元バーコード又は二次元バーコード（ＱＲコードを含む）を用いたキャッシュレス決済をいう。

（１）先ず、統合決済機能において、統合決済システム１は、ユーザＵのヘルスケアデータを外部システム５又はユーザ装置２００から取得する。

（２）統合決済システム１は、取得したヘルスケアデータに応じて、ユーザＵに特典を付与する。ここで「特典」は、例えば、事業者の各飲食施設で利用可能なポイント（本例では、「マイル」とする）や電子クーポン等である。また、ここでいう「マイル」は、電子クーポン等に交換可能であってもよく、本例では、第１事業者（本例では、「野菜レストラン」とする）が所有する第１飲食施設Ｓ１（本例では、「野菜レストラン 新宿店」とする）で利用可能な電子クーポンＣ（飲食代を１０％割引する割引券とする）に交換されたものとする。統合決済システム１は、例えば、ユーザＵの一日の歩数が所定の閾値を超えた場合、予め設定した量のマイル（本例では、「５００マイル」と記載）をユーザＵに付与する。

（３−１）先ず、ユーザＵは、第１飲食施設Ｓ１における飲食にあたって、統合決済機能を利用する。具体的には、ユーザＵは、ユーザ装置２００のユーザ用決済アプリを起動させ、第１飲食施設Ｓ１が属する第１事業者を含む複数の事業者それぞれの電子決済手段を含む決済手段選択画面Ａ４（後述の図７（ａ）参照）を表示させる。

（４−１）ユーザＵは、決済手段選択画面Ａ４に表示された複数の電子決済手段の中から、野菜レストランの電子決済手段を選択する。統合決済システム１は、当該選択を受け付けると、選択された電子決済手段において、予め登録されている代金の支払い方法により決済するために、後述の第１識別コードの一態である第１ＱＲコードを生成する。ここでは、この「予め登録されている代金の支払い方法」を、利用者提示型（ＣＰＭ（Ｃｏｎｓｕｍｅｒ−Ｐｒｅｓｅｎｔｅｄ−Ｍｏｄｅ））の第１ＱＲコードを用いるコード決済とする。統合決済システム１は、生成した第１ＱＲコードをユーザ装置２００のコード決済画面Ａ５（後述の図７（ｂ）参照）に表示させる。

（５−１）ユーザＵは、第１飲食施設Ｓ１での飲食代の支払いにあたって、ユーザ装置２００のコード決済画面Ａ２に表示された第１ＱＲコードを第１施設端末３００ａに読み取らせる。また、ユーザＵは、第１飲食施設Ｓ１での飲食代の支払いにあたって、ユーザ用決済アプリで出力した電子クーポンＣを提示して、飲食代を１０％割引させることができる。第１施設端末３００ａは、読み取った第１ＱＲコードの情報を含めた支払いの決済のための決済要求を決済装置１００に送信する。決済装置１００は、この決済要求を受け付けると、飲食代の支払いの決済のための処理（以下、「決済処理」ともいう）を行う。具体的には、決済装置１００は、該当する銀行の銀行サーバに対して、ユーザＵの銀行口座を振込元に統合決済機能を提供する事業者（以下、「決済事業者」という）が保有する銀行口座を振込先に指定して振込処理を指示する。

（３−２）次に、ユーザＵは、第２飲食施設Ｓ２における飲食サービスを受けるにあたって、統合決済機能を利用する。具体的には、ユーザＵは、ユーザ装置２００のユーザ用決済アプリを起動させ、第２飲食施設Ｓ２が属する第２事業者（本例では、「健康カフェ」とする）の電子決済手段を含む決済手段選択画面Ａ４を表示させる。

（４−２）ユーザＵは、決済手段選択画面Ａ１に表示された複数の電子決済手段の中から、健康カフェの電子決済手段を選択する。統合決済システム１は、当該選択を受け付けると、選択された電子決済手段において予め登録されている代金の支払い方法により決済するために、後述の第２識別コードの一態様である第２ＱＲコードを生成する。ここでは、この「予め登録されている代金の支払い方法」を、飲食施設提示型（ＭＰＭ（Ｍｅｒｃｈａｎｔ−Ｐｒｅｓｅｎｔｅｄ−Ｍｏｄｅ））の第２ＱＲコードを用いるコード決済とする。統合決済システム１は、生成した第２ＱＲコードを第２施設端末３００ｂの画面に表示させる。なお、第１識別コードと第２識別コードとを、特に区別の必要が無い場合、総称して「識別コード」ともいう。

（５−２）ユーザＵは、第２飲食施設Ｓ２での飲食代の支払いにあたって、第２施設端末３００ｂの画面に表示された第２ＱＲコードをユーザ装置２００に読み取らせる。ユーザ装置２００は、読み取った第２ＱＲコードの情報を含めた支払いの決済のための決済要求を、決済装置１００に送信する。決済装置１００は、この決済要求を受け付けると、飲食代の決済処理を行う。具体的には、決済装置１００は、該当する銀行の銀行サーバに対して、ユーザＵの銀行口座を振込元に決済事業者が保有する銀行口座を振込先に指定して振込処理を指示する。

上記構成によれば、統合決済システム１は、ユーザＵに、飲食サービスの提供を行う飲食施設を有する野菜レストラン及び健康カフェそれぞれの電子決済手段をまとめて提供することができる。このため、ユーザＵは、野菜レストラン及び健康カフェそれぞれの電子決済手段を利用するために、それぞれのアプリをユーザ装置２００にインストールしセッティングする必要がなく、ユーザ用決済アプリをインストールしセッティングするだけでよい。このため、統合決済システム１は、ユーザＵが野菜レストラン及び健康カフェそれぞれの電子決済手段を利用するにあたって、ユーザＵの手間を低減させることができる。

＜１−２．食事データ・ハブ機能の概要＞
図３を参照して、本実施形態に係る食事データ・ハブ機能の概要を説明する。ユーザＵが、複数の飲食施設を利用し、また、ユーザＵの食事データを記録する複数の記録サービスを利用する例を説明する。本例では、図２で示したようにユーザＵが第１飲食施設Ｓ１で飲食をして、その飲食代を支払い決済した例を用いて説明する。

図３に示すように、（１）決済装置１００は、複数の飲食施設の中でユーザＵが飲食した第１飲食施設Ｓ１から、その飲食代の支払い決済の後に、その飲食における食事データを取得する。（２）決済装置１００は、記録先条件に基づいて、ユーザＵが利用する食事関連サービスの中から取得した食事データの記録先を特定する。この特定した食事関連サービスを、「特定サービス」ともいう。本例では、利用する複数の記録サービスの中で、第１外部システム５ａが提供するヘルスケアサービスと第２外部システム５ｂが提供する食事管理サービスを記録先として特定したとする。

「記録先条件」とは、食事データの記録先のサービスを特定するための条件である。記録先条件は、具体的には、複数の食事関連サービスの中から第１ユーザが利用する少なくとも１つの食事関連サービスを示す条件である。記録先条件は、例えば、ユーザごとに設定されてもよいし、複数のユーザ共通で一律同じ条件が設定されてもよい。

（３）決済装置１００は、特定サービスの仕様等に合わせるために食事データの少なくとも一部を変換してもよい。（４）決済装置１００は、取得・変換した食事データを特定サービスに送信する。

図４を参照して、統合決済システム１における食事データ・ハブ機能に関する処理の流れを説明する。本例では、支払い決済にＣＰＭ方式のコード決済を用いるものとする。

図４に示すように、先ず、昼〜夜の間にユーザＵが飲食施設で飲食した際の処理の流れの例を説明する。（１ａ）ユーザＵは、第１飲食施設での飲食代の支払いにあたって、ユーザ装置２００に第１ＱＲコードを表示させる。（２ａ）第１施設端末３００ａはユーザ装置２００に表示された第１ＱＲコードを読み取る。（３ａ）第１施設端末３００ａから読み取った第１ＱＲコードの情報を含めた決済要求を決済装置１００に送信すると、決済装置１００は、この決済要求に基づいて、飲食代の決済処理を行う。

次に、記録サービスに食事データを連携する処理の流れの例を説明する。（１ｂ）一日二回（例えば、昼：１５時、夜：２１時等）のタイミングで、第１施設端末３００ａは、連携対象の食事データをまとめて決済装置１００に送信する。（２ｂ）決済装置１００は、受信した食事データを食事関連サービスに中継する。（３ｂ）食事関連サービスは、決済装置１００から中継された食事データを記録する。

次に、ユーザＵが食事関連サービスを利用する処理の流れの例を説明する。（１ｃ）食事関連サービスに食事データが記録された後、任意のタイミングで、ユーザＵは、ユーザ装置２００から食事関連サービスが提供するアプリまたはＷｅｂサイトにログインして、記録した食事データの照会を要求する。（２ｃ）食事関連サービスは、この要求を受け付けると、照会の結果としてユーザＵの食事データをユーザ装置２００に提供する。

上記構成によれば、決済装置１００は、複数の食事関連サービスをユーザが利用していても、記録先として特定されたサービスに、飲食施設での食事データを連携することができる。このため、上記構成によれば、食事の記録を行う食事関連サービスのサービス提供者は、ユーザの食事データを取得するために、自身のシステム（外部システム５）に、ユーザが利用する複数の飲食施設（又はその事業者）それぞれとの間で食事データを連携する機能を一から実装させる必要がない。したがって、上記構成によれば、決済装置１００は、複数の食事関連サービスに対して、飲食施設でのユーザの食事の記録を支援することができる。

＜２．機能構成＞
図５を参照して、本実施形態に係る決済装置１００の機能構成を説明する。図５に示すように、決済装置１００は、制御部１１０と、通信部１３０と、記憶部１４０と、を備える。

制御部１１０は、記録先特定部１１１と、要求受付部１１２と、決済処理部１１３と、ヘルスケアデータ取得部１１４と、を備える。また、制御部１１０は、例えば、条件受付部１１５、利用情報取得部１１６、施設特定部１１７、蓄積部１１８、データ生成部１１９、算出部１２０、指定受付部１２１、表示部１２２、決済手段受付部１２３、コード生成部１２４、又は特典付与部１２５を備えてもよい。

−記録先特定部−
記録先特定部１１１は、記録サービスをユーザに提供する複数の食事関連サービスの中から、記録先条件に基づいて、第１ユーザの食事に関する食事データの記録先である少なくとも１つのサービスを特定する。

−要求受付部−
要求受付部１１２は、飲食施設の施設端末３００から、飲食施設での食事に対する代金（「飲食代」ともいう）の第１ユーザによる支払いの際、支払いの決済要求（以下、単に「決済要求」ともいう）を受け付ける。要求受付部１１２がユーザ装置２００又は施設端末３００から決済要求を受け付ける態様に関しては、どのような態様でもよく、例えば、決済要求を示すメッセージをユーザ装置２００等から通信部１３０を介して受信してもよい。

決済要求は、例えば、ユーザ装置２００で出力されて施設端末３００で読み取られた第１識別コードの事業者識別情報を含んでもよい。ここで「事業者識別情報」とは、事業者を識別するための情報であり、以下、「事業者ＩＤ」ともいう。

「第１識別コード」とは、ユーザが飲食施設に商品等の代金を支払う際にＣＰＭ方式のコード決済を行うための一次元バーコード又は二次元バーコードである。第１識別コードは、ユーザから選択された電子決済手段における事業者を識別するための事業者ＩＤ、支払いの決済を識別するための決済識別情報（以下、「決済ＩＤ」ともいう）を含む。

要求受付部１１２は、例えば、ユーザ装置２００から、決済要求を受け付けてもよい。この決済要求は、施設端末３００からユーザ装置２００で読み取られた第２識別コードの事業者ＩＤを含む。

「第２識別コード」とは、ユーザが飲食施設に飲食代を支払う際にＭＰＭ方式のコード決済を行うための一次元バーコード又は二次元バーコードである。第２識別コードは、施設端末３００が生成する識別コードであり、飲食施設が属する事業者の事業者ＩＤ、決済ＩＤを含む。

−決済処理部−
決済処理部１１３は、要求受付部１１２が受け付けた決済要求に基づいて、支払いの決済のための決済処理を行う。決済処理部１１３は、例えば、決済処理を行った場合に、当該決済処理の決済情報を生成してもよい。

「決済情報」は、決済処理部１１３により処理が行われた支払いの決済の内容を示す情報である。決済情報は、例えば、決済を行ったユーザを示すユーザＩＤ、決済対象のメニューを示すメニュー識別情報（例えば、メニュー名又はメニューＩＤ）、該当する決済が行われた日時を示す決済日時、決済金額、該当する支払いが行われた飲食施設を識別するための施設ＩＤ、決済処理部１１３による処理を含む一連の処理（トランザクション）を識別するためのトランザクションＩＤ、及び該当する支払いが行われた施設端末３００を示す端末番号を含んでもよい。

決済処理部１１３は、例えば、ユーザから選択された電子決済手段で決済処理を行ってもよい。決済処理部１１３は、例えば、選択された電子決済手段が銀行振込による支払いを利用する場合、仕向け先の銀行の銀行サーバに対して、銀行振込の振込処理を指示する。また、決済処理部１１３は、例えば、選択された電子決済手段がクレジットカード決済による支払いを利用する場合、該当するクレジットカードシステムにクレジットカード決済処理を指示する。

上記構成によれば、ユーザは、飲食施設での飲食において複数の事業者がそれぞれ提供する電子決済手段を利用するにあたって、飲食代の支払いの決済を行う電子決済手段を選択して決済要求すれば飲食代の支払いの決済をさせることができる。このため、複数の事業者がそれぞれ提供する電子決済手段を利用する際に、ユーザは、事業者別のアプリをそれぞれインストール等する必要がなく、その利用の手間を低減することができる。

決済処理部１１３は、例えば、要求受付部１１２が受け付けた決済要求に基づいて、ユーザから選択された電子決済手段において、後述の決済手段受付部１２３が登録した支払い方法及び認証情報により決済処理を行ってもよい。

上記構成によれば、決済処理部１１３は、決済要求があった際に、ユーザから選択された電子決済手段において、予め登録されている支払方法等を用いて支払いの決済を円滑に行うことができる。このため、上記構成によれば、決済処理部１１３は、ユーザにとって使い勝手のよい決済サービスを提供することができる。

決済処理部１１３は、例えば、要求受付部１１２が受け付けた決済要求に含まれる第１識別コードの事業者識別情報が示す事業者と当該決済要求の要求元の飲食施設が属する事業者とが一致する場合、コード決済による決済処理を行ってもよい。また、決済処理部１１３は、このような場合、例えば、ユーザから選択された電子決済手段でコード決済による決済処理を行ってもよい。決済処理部１１３は、この事業者が一致するか否かの判定の際に、飲食施設情報を参照してもよい。

「飲食施設情報」とは、各飲食施設を示す情報であり、例えば、飲食施設を識別するための施設識別情報（以下、「施設ＩＤ」ともいう）、飲食施設の名前を示す施設名、又は飲食施設が属する事業者の事業者ＩＤ等を含んでもよい。

上記構成によれば、決済処理部１１３は、飲食代の支払いの決済において、ＣＰＭ方式のコード決済を用いてユーザが飲食施設に飲食代を支払う際に、支払い先の飲食施設とユーザが選択した電子決済手段との整合性を図ることができる。

決済処理部１１３は、例えば、要求受付部１１２が受け付けた決済要求に含まれる第２識別コードの事業者ＩＤが示す事業者とユーザから選択された電子決済手段の事業者とが一致する場合、コード決済による決済処理を行ってもよい。

上記構成によれば、決済処理部１１３は、飲食代の支払いの決済において、ＭＰＭ方式のコード決済を用いてユーザが飲食施設に飲食代を支払う際に、支払い先の飲食施設とユーザが選択した電子決済手段との整合性を図ることができる。

−ヘルスケアデータ取得部−
ヘルスケアデータ取得部１１４は、外部システム５又はユーザ装置２００から、ユーザのヘルスケアデータの少なくともいずれか一つを取得する。ヘルスケアデータ取得部１１４がヘルスケアデータを取得する態様に関しては、どのような態様でもよく、例えば、外部システム５又はユーザ装置２００からヘルスケアデータのデータファイルを受信してもよい。また、ヘルスケアデータ取得部１１４がヘルスケアデータを取得する態様は、他の例として、外部システム５又はユーザ装置２００にリモートアクセスしてヘルスケアデータのデータファイルを取得してもよいし、外部システム５又はユーザ装置２００が実装するＡＰＩにヘルスケアデータの参照を指示してその結果としてヘルスケアデータを取得してもよい。ヘルスケアデータ取得部１１４は、食事データ取得部１１４１を備える。

−食事データ取得部−
食事データ取得部１１４１は、施設端末３００から、決済処理部１１３で決済処理が行われた場合、飲食施設での食事に関する食事データを取得する。食事データ取得部１１４１は、食事データの取得にあたって、施設端末３００から直接取得する他に、施設端末３００が属する事業者サーバ４００（施設端末３００と接続する事業者サーバ４００）を介して食事データを取得してもよい。

食事データ取得部１１４１は、例えば、決済処理部１１３で決済処理が行われた場合、施設特定部１１７により特定された飲食施設の施設端末３００から、食事データを取得してもよい。言い換えれば、食事データ取得部１１４１は、決済処理部１１３で決済処理が行われた場合でも、施設特定部１１７により特定されなかった飲食施設の施設端末３００から食事データを取得しなくてもよい。

例えば、ユーザにとって、機密性の観点等から、決済装置１００や食事関連サービスに連携したくない食事がある場合が考えられる。このような場合において、上記構成によれば、食事データ取得部１１４１は、取得元条件でフィルタされた飲食施設からは食事データを取得しないため、ユーザにとって使い勝手のよい食事データ・ハブ機能を提供することができる。

−条件受付部−
条件受付部１１５は、第１ユーザの第１ユーザ装置２００ａから、記録先条件を受け付ける。条件受付部１１５が記録先条件を受け付ける態様は、要求受付部１１２と同様で、どのような態様でもよい。条件受付部１１５は、例えば、第１ユーザ装置２００ａから、第１ユーザが利用する食事関連サービスとして、「第１外部システム５ａが提供するヘルスケアサービスであること」又は「第２外部システム５ｂが提供する食事管理サービスであること」とする記録先条件を受け付けてもよい。

上記構成によれば、条件受付部１１５は、ユーザに対して、記録先の食事関連サービスを手動で選択させることができる。このため、上記構成によれば、条件受付部１１５は、ユーザの意向にそった形で記録先の食事関連サービスを特定させることができる。

条件受付部１１５は、例えば、第１ユーザの第１ユーザ装置２００ａから、取得元条件を受け付けてもよい。

「取得元条件」とは、食事データの取得元の飲食施設を特定するための条件である。取得元条件は、具体的には、複数の飲食施設の中から第１ユーザが利用する少なくとも１つの飲食施設を示す条件であってもよい。取得元条件は、例えば、ユーザごとに設定されてもよいし、複数のユーザ共通で一律同じ条件が設定されてもよい。

−利用情報取得部−
利用情報取得部１１６は、ユーザ装置２００又はサービス提供装置５００から、記録先条件に含まれるサービス利用実績を示すサービス利用情報を取得する。ここで「サービス利用実績」とは、サービス提供装置５００の機能を第１ユーザが利用した実績である。利用情報は、例えば、サービス利用実績として、サービス提供装置５００の機能を利用した最終の日時を示す最終利用日時を含んでもよい。この場合、例えば、記録先条件に、「最終利用日時が所定期間（例えば、過去１年間等）以内であるサービス提供装置５００の食事関連サービスであること」とする条件を含めることができる。

上記構成によれば、利用情報取得部１１６は、記録先の食事関連サービスを利用情報に基づいて自動で特定させることができる。このため、上記構成によれば、利用情報取得部１１６は、ユーザの手間をかけずに利用実績に応じて記録先の食事関連サービスを特定させることができる。

利用情報取得部１１６は、例えば、ユーザ装置２００又はサービス提供装置５００から、取得元条件に含まれる施設利用実績を示す施設利用情報を取得してもよい。ここで「施設利用実績」とは、飲食施設を第１ユーザが利用した実績である。施設利用情報は、例えば、施設利用実績として、所定期間（例えば、過去５年間等）で飲食施設に支払った飲食代の平均金額を含んでもよい。この場合、例えば、取得元条件に、「平均金額が〇〇円以上である飲食施設であること」とする条件を含めることができる。

−施設特定部−
施設特定部１１７は、複数の飲食施設の中から、取得元条件に基づいて、食事データの取得元の飲食施設を特定する。

−蓄積部−
蓄積部１１８は、所定期間、食事データ取得部１１４１が取得した食事データを、食事データ記憶部１４１に蓄積する。

−データ生成部−
データ生成部１１９は、食事データ取得部１１４１により食事データが取得できない場合、蓄積された食事データに基づいて、取得できない食事データの代わりの仮の食事データを生成する。データ生成部１１９は、例えば、取得できなかった飲食施設（又はこの飲食施設と類似すると設定された他の飲食施設）における蓄積された食事データの統計値（例えば、最頻値や平均値等）を、仮の食事データとしてもよい。データ生成部１１９は、例えば、蓄積された食事データの中で最も出現頻度（注文頻度）の高いメニュー名を検索する。そして、データ生成部１１９は、検索の結果抽出されたメニュー名と、このメニュー名に紐づくカロリーやタンパク質等の摂取した栄養素の項目とを、仮の食事データとして設定してもよい。ここで「栄養素の項目」とは、具体的には、図９に示す食事データのＮｏ．４〜１０の項目等をいう。また、データ生成部１１９は、蓄積された食事データの各栄養素の項目の平均値を算出し、仮の食事データとして、各栄養素の項目にはこの算出した平均値を、メニュー名には「仮メニュー」等適当な文字列を設定してもよい。

−算出部−
算出部１２０は、食事データと利用人数とに基づいて、食事での一人当たりの食事量を算出する。算出部１２０は、例えば、利用人数が「３」の場合、各メニューにおいて、食事データの各栄養素の項目の値を３で割って、一人当たりの値を算出する。算出部１２０は、栄養素の項目ごとに、飲食したメニュー全てのこの一人当たりの値を合計して、食事での一人当たりの食事量を算出してもよい。例えば、一回の食事でメニューＡ〜Ｂを注文して、メニューＡのカロリーが３００ｋｃａｌ、メニューＢのカロリーが９００ｋｃａｌ、及びメニューＣのカロリーが１，２００ｋｃａｌとする場合、それぞれのカロリー値を利用人数「３」で割って、それらを合計した値、すなわち１００ｋｃａｌ＋３００ｋｃａｌ＋４００ｋｃａｌ＝８００ｋｃａｌを一人当たりの食事量（摂取カロリー）として算出してもよい。

−指定受付部−
指定受付部１２１は、第１ユーザ装置２００ａ又は第２ユーザ装置２００ｂから、食事データ送信部１３１による第２ユーザ装置２００ｂへの送信対象の食事の曜日、食事の日にち、又は食事の時間帯の少なくともいずれか一つの指定を受け付ける。指定受付部１２１が食事の曜日等の指定を受け付ける態様は、要求受付部１１２と同様で、どのような態様でもよい。ここでいう「食事の時間帯」とは、例えば、朝食（例えば、６：００〜１２：００）、昼食（例えば、１２：００〜１４：００）、又は夕食（例えば、１６：００〜２３：００）であってもよい。

−表示部−
表示部１２２は、決済手段対応情報を記憶する決済手段記憶部１４３を参照して、第１ユーザに対応する複数の電子決済手段を第１ユーザ装置２００ａに表示させる。具体的には、表示部１２２は、決済手段記憶部１４３を参照して、電子決済手段出力情報を生成する。表示部１２２は、生成した電子決済手段出力情報を、第１ユーザ装置２００ａに通信部１３０を介して送信する。このように、表示部１２２は、第１ユーザに対応する複数の電子決済手段を第１ユーザ装置２００ａに表示させる。

「決済対応手段情報」とは、ユーザと、当該ユーザに飲食サービスの提供を行う飲食施設を所有する複数の事業者それぞれの電子決済手段との対応関係を示す情報である。決済手段対応情報は、例えば、ユーザを識別するための「ユーザ識別情報（以下、「ユーザＩＤ」ともいう）」と、当該ユーザＩＤのユーザが利用可能な事業者ごとの電子決済手段を識別するための電子決済手段識別情報（以下、「電子決済手段ＩＤ」ともいう）と、を対応付ける情報である。この対応付けにあたって、ユーザＩＤと電子決済手段ＩＤとの関係は、１対Ｎ又はＮ対Ｎ（Ｎ：１以上の数）の関係となる。また、決済手段対応情報は、ユーザ情報と電子決済手段情報とを対応付ける情報であってもよい。また、決済手段対応情報におけるユーザと電子決済手段との上記の対応関係は変更可能である。例えば、ユーザ装置２００から、電子決済手段を新たに追加する指定を指定受付部１２１が受け付けた際に、ユーザに当該指定された電子決済手段を新たに対応付けるよう決済手段対応情報を指定受付部１２１が更新してもよい。

「ユーザ情報」とは、ユーザに関する情報である。ユーザ情報は、例えば、ユーザＩＤ、ユーザの氏名を示すユーザ名、及び／又はユーザが保有する口座を識別するための口座識別情報（例えば、口座ＩＤや口座番号等）等を含む。ユーザ情報は、例えば、ユーザのニックネーム、性別、生年月日、及び／又は各ユーザの体型を表す体型データ（例えば、身長、体重、腹囲、ウェスト、ヒップ、又は足のサイズ等）を含んでもよい。ユーザ情報は、例えば、サービス提供装置５００が発行するトークンを含んでもよい。このトークンは、サービス提供装置５００に対してユーザがアクセスした際のユーザ認証で発行されてもよい。

「電子決済手段情報」とは、事業者ごとの電子決済手段を示す情報である。電子決済手段情報は、例えば、該当する事業者を識別するための事業者識別情報（以下、「事業者ＩＤ」ともいう）、事業者の名称を示す事業者名、事業者の通称を示す事業者通称、事業者のロゴを示すロゴ画像データ、１以上の電子決済手段ＩＤ、後述の決済手段受付部１２３により登録されている支払い方法を示す支払い方法情報等を含んでもよい。

「電子決済手段出力情報」とは、ユーザに対応する複数の電子決済手段を示す情報である。電子決済手段出力情報は、例えば、この複数の電子決済手段を示す「電子決済手段名（例えば、「事業者通称」＋「Ｐａｙ」等）」を一覧で表示する画面であってもよい。

表示部１２２は、例えば、後述するホーム画面、食事データ画面、クーポン画面、決済手段選択画面、コード決済画面、取得元指定画面、記録先指定画面、及び／又は通知指定画面の各種画面をユーザ装置２００に表示させてもよい。

−決済手段受付部−
決済手段受付部１２３は、ユーザ装置２００から、表示部１２２により表示された複数の電子決済手段のうちユーザが利用する電子決済手段の選択を受け付ける。決済手段受付部１２３が電子決済手段の選択を受け付ける態様に関しては、要求受付部１１２と同様にどのような態様でもよく、例えば、ユーザ装置２００にインストールされたユーザ用決済アプリ経由で受け付けてもよい。

決済手段受付部１２３は、例えば、ユーザ装置２００から、ユーザが使用可能な支払い方法と認証情報の登録を受け付けてもよい。決済手段受付部１２３は、例えば、ユーザに対応する電子決済手段それぞれに対して、この支払い方法と認証情報の登録を受け付けてもよい。

「ユーザが使用可能な支払い方法」は、例えば、クレジットカードやデビットカード等によるカード払い、銀行振込による支払い、カードレス払い、プリペイド口座による支払い、及び／又は電子マネー（仮想通貨を含む）による支払い等の様々な方法が考えられる。また、ユーザが使用可能な支払い方法は、上記のカード払いや銀行振込による支払い等を対応付けたコード決済による方法であってもよい。決済手段受付部１２３は、ユーザが使用可能な代金の支払い方法の登録と併せて、当該支払い方法の利用に必要な口座管理情報の登録を受け付けてもよい。

「認証情報」とは、上記支払い方法を利用する際のユーザ認証を受けるための情報である。認証情報は、例えば、ユーザアカウントを識別するためのアカウントＩＤと、当該ユーザアカウントのパスワードと、を含んでもよい。

「口座管理情報」とは、各種口座を管理するための情報である。口座管理情報は、例えば、口座ＩＤ、ユーザ名、ユーザの生年月日、ユーザのＥ−Ｍａｉｌアドレス等を示すアドレス、ユーザの電話番号、口座残高、及び／又は口座の入出金履歴等を含む。また、口座管理情報は、例えば、銀行サーバ等が管理するユーザの口座の口座情報にアクセスするための認証情報を含んでもよい。

−コード生成部−
コード生成部１２４は、支払い方法情報を記憶する支払い方法記憶部１４４参照して、ユーザが使用可能な支払い方法がコード決済による方法の場合、決済手段受付部１２３が電子決済手段の選択を受け付けた際に、選択された電子決済手段における事業者識別情報を含むコード決済用の識別コードを生成する。ここで「支払い方法情報」とは、ユーザが使用可能な支払い方法を示す情報である。コード生成部１２４は、例えば、使用可能な支払い方法が第１識別コードを用いるコード決済による方法の場合、決済手段受付部１２３が電子決済手段の選択を受け付けた際に、第１識別コードを生成してもよい。

−特典付与部−
特典付与部１２５は、ヘルスケアデータ取得部１１４が取得したヘルスケアデータが特典条件を満たす場合、ユーザに、支払いに利用可能な特典を付与する。

「特典条件」とは、ユーザに特典を付与するための条件である。特典条件は、例えば、活動データであるユーザの一日の歩数の閾値（例えば、「３０００歩以上」等）であってもよい。例えば、特典条件が「一回の食事の食塩相当量が３．０ｇ以下であること」であれば、特典付与部１２５は、食事データに含まれる食塩相当量が３．０ｇ以下の場合、ユーザに１００マイルを付与してもよい。

特典付与部１２５は、ユーザのヘルスケアに資する行動以外のユーザの行動に対しても特典を付与してもよく、例えば、統合決済システム１の決済機能の利用の促進につながる行動に対してもユーザに特典を付与してもよい。例えば、特典条件に「ユーザ用決済アプリを起動すること」という条件を含め、特典付与部１２５は、ユーザ装置２００でユーザがユーザ用決済アプリを起動させる度に、当該ユーザに特典を付与してもよい。また、特典条件は、他の例として、「ユーザが特定の場所にチェックインすること」、及び／又は「第１識別コードを読み取ること」「第２識別コードを生成すること」等の条件を含めてもよい。

特典付与部１２５は、例えば、食事データ取得部１１４１が取得した食事データが特典条件を満たす場合、ユーザに、支払いに利用可能な特典を付与してもよい。このような構成によれば、特典付与部１２５は、特典を付与することによって、ユーザの食生活の改善を促進することができる。

−通信部−
通信部１３０は、ネットワークＮを介して、ユーザ装置２００、事業者サーバ４００又は外部システム５等と各種情報を送受信する。通信部１３０は、例えば、ネットワークＮを介して、ユーザ装置２００から決済要求を受信したり、当該決済要求による決済の処理結果を示す情報をユーザ装置２００に送信したりする。通信部１３０は、複数の電子決済手段のうちユーザが利用する電子決済手段を選択させるために、電子決済手段出力情報をユーザ装置２００に送信する。また、通信部１３０は、食事データ送信部１３１と、コード送信部１３２とを備える。

−食事データ送信部−
食事データ送信部１３１は、食事データを、記録先特定部１１１により特定された少なくとも１つのサービスのそれぞれのサービス提供装置５００に送信する。

上記構成によれば、食事データ送信部１３１は、複数の記録サービスを含む食事関連サービスをユーザが利用していても、記録先として特定された食事関連サービスに、飲食施設での食事データを連携することができる。このため、上記構成によれば、食事データ送信部１３１は、食事の記録を行う複数のサービスに対して、飲食施設でのユーザの食事の記録を支援することができる。

食事データ送信部１３１は、例えば、食事データ取得部１１４１により取得される食事データの代わりに、データ生成部１１９が生成した仮の食事データを、サービス提供装置５００に送信してもよい。また、食事データ送信部１３１は、他の例として、食事データ取得部１１４１により取得される食事データの代わりに、システム内共通のデフォルトの食事データを、サービス提供装置５００に送信してもよい。

飲食施設の中には、食事データ・ハブ機能に対応していないため食事データを取得できない施設があることが考えられる。このような飲食施設での飲食に関して、上記構成によれば、食事データ送信部１３１は、食事データを取得できなくとも、代わりに仮の食事データをサービス提供装置５００に送信することができる。食事管理サービスやヘルスケアサービス等において日々の食事の統計を分析する場合、食事データの記録が一切ないとその分析結果の精度に影響を及ぼしてしまうことが考えられる。このような場合において、上記構成によれば、食事データ送信部１３１は、食事データを取得できなくとも、仮の食事データを送信することで、分析結果の精度への影響を低減することができる。

食事データ送信部１３１は、例えば、算出部１２０が算出した一人当たりの食事量を含む食事データを送信してもよい。例えば、飲食施設において複数人で飲食をした場合、支払い決済対象の食事データそのままだと、実際には第１ユーザ一人が摂取していない量の食事量を示す食事データがサービス提供装置５００に送信されてしまうことになる。このような構成によれば、食事データ送信部１３１は、複数人で食事した場合においても一人当たりの食事量として算出された量を示す食事データをサービス提供装置５００に送信できるため、ユーザの食事管理やヘルスケアにおいてより適切な食事データの記録をすることができる。

食事データ送信部１３１は、例えば、第１ユーザと、第２ユーザと、を関連付けて記憶するユーザ記憶部１４２を参照して、第２ユーザの第２ユーザ装置２００ｂに、第１ユーザの食事データの少なくとも一部を送信してもよい。食事データ送信部１３１は、例えば、第２ユーザのＥ−Ｍａｉｌアドレス宛に食事データに含まれる食事内容（例えば、メニュー名等）を示すメッセージを送信してもよい。また、食事データ送信部１３１は、他の例として、第２ユーザ装置２００ｂのユーザ用決済アプリに食事データを含むプッシュ通知させてもよい。

上記構成によれば、食事データ送信部１３１は、第１ユーザの食事内容を、家族や友人等の第２ユーザに容易に共有させることができる。

食事データ送信部１３１は、例えば、指定受付部１２１が受け付けた指定にさらに基づいて、第２ユーザ装置２００ｂに、第１ユーザの食事データの少なくとも一部を送信してもよい。

第１ユーザの食事内容を第２ユーザに共有させるにあたって、統合決済システム１が扱う全ての第１ユーザの食事を対象とすると情報過多となる場合が考えられる。上記構成によれば、食事データ送信部１３１は、第１ユーザ又は第２ユーザが共有したいと考える食事だけを共有させることができる。

−コード送信部−
コード送信部１３２は、コード生成部１２４で生成された識別コードを、決済手段受付部１２３が電子決済手段の選択を受け付けた第１ユーザ装置２００ａに送信する。

−記憶部−
記憶部１４０は、認証情報、口座管理情報、飲食施設情報、及び／又は電子決済手段出力情報を記憶する。記憶部１４０は、食事データ記憶部１４１、ユーザ記憶部１４２、決済手段記憶部１４３、及び／又は支払い方法記憶部１４４を備えてもよい。食事データ記憶部１４１は、食事データを記憶する。ユーザ記憶部１４２は、第１ユーザのユーザ情報と第２ユーザのユーザ情報とを関連付けて記憶する。決済手段記憶部１４３は、決済情報及び決済手段対応情報を記憶する。支払い方法記憶部１４４は、支払い方法情報を記憶する。記憶部１４０は、データベースマネジメントシステム（ＤＢＭＳ）を利用して各情報を記憶してもよいし、ファイルシステムを利用して上記情報を記憶してもよい。ＤＢＭＳを利用する場合は、上記情報ごとにテーブルを設けて、当該テーブル間を関連付けて上記情報を管理してもよい。

＜３．画面例＞
図６〜９を参照して、統合決済システム１の画面例を説明する。

図６（ａ）に示すように、ホーム画面Ａ１は、ユーザが統合決済システム１に決済アプリを介してログインした際に、はじめに表示される画面である。ホーム画面Ａ１は、例えば、ユーザが保有する特典（本例では、「マイル」とする）の総量を示す総保有マイル表示領域ａ１１と、ユーザの活動データを表示する活動データ画面（不図示）を表示するための活動データ画面表示ボタンａ１２と、ユーザの食事データを表示する食事データ画面Ａ２を表示するための食事データ画面表示ボタンａ１３と、ユーザの身体データを表示する身体データ画面（不図示）を表示するための身体データ画面表示ボタンａ１４と、ユーザが保有するマイルと交換可能なクーポン一覧を示すクーポン一覧表示領域ａ１５と、を含む。

食事データ画面表示ボタンａ１２が押下されると、表示部１２２は、食事データ画面Ａ２に遷移させる。また、クーポン一覧表示領域ａ１５に表示されている各クーポンのボタンが指定（押下）されると、表示部１２２は、当該指定されたクーポンの内容を表示するクーポン画面Ａ３に遷移させる。

図６（ｂ）・（ｃ）に示すように、食事データ画面Ａ２は、ユーザの食事データを表示する。図６（ｂ）に示すように、食事データ画面Ａ２は、各栄養素の項目について一日（本例では、２０２０／１１／１８）の食事で摂取した合計値を表示してもよい。図６（ｃ）に示すように、食事データ画面Ａ２は、食事（朝食・昼食）ごとのメニュー名と各栄養素の項目を表示してもよい。また、図６（ｄ）に示すように、クーポン画面Ａ３は、上記クーポン一覧から指定されたクーポンの内容を表示する。

図７（ａ）に示すように、決済手段選択画面Ａ４は、ユーザに対応する複数の電子決済手段を表示する画面である。また、決済手段選択画面Ａ４は、ユーザから、飲食施設での飲食代の支払いの際に利用する電子決済手段の選択を受け付けるための画面でもある。決済手段選択画面Ａ４は、電子決済手段出力情報の一態様である。決済手段選択画面Ａ４は、電子決済手段（本例では、「加盟店Ｐａｙ」と記載）を新たに追加するための追加指定ボタンａ４１と、ユーザに対応する電子決済手段の一覧を表示する電子決済手段一覧表示領域ａ４２とを含む。

追加指定ボタンａ４１が押下されると、表示部１２２は、新たに電子決済手段を追加するための電子決済手段追加画面（不図示）に遷移させる。

電子決済手段一覧表示領域ａ４２は、ユーザに対応する第１事業者（野菜レストラン）の第１電子決済手段選択ボタンａ４２１と、第２事業者（健康カフェ）の第２電子決済手段選択ボタンａ４２２と、第３事業者（会社Ａ 社員食堂）の第３電子決済手段選択ボタンａ４２３と、を含む。

第１電子決済手段選択ボタンａ４２１が押下されると、表示部１２２は、野菜レストランの電子決済手段における支払い決済のためのコード決済画面Ａ５に遷移させる。

図７（ｂ）に示すように、コード決済画面Ａ５は、野菜レストランの電子決済手段における支払い決済を行うための画面である。なお、本例では、野菜レストランの電子決済手段には、支払い方法としてコード決済による銀行振込が登録されているものとする。コード決済画面Ａ５は、登録されている支払い方法を表示する支払い方法表示領域ａ５１と、コード生成部１２４により生成された第１識別コードを表示する第１識別コード表示領域ａ５２とを含む。図７（ｃ）に示すように、表示部１２２は、コード決済画面Ａ５に表示された第１識別コードが施設端末３００に読み取られて支払い決済のための処理が完了した際に、当該完了の旨を示す決済完了通知ダイアログａ５３を表示させてもよい。また、他の例として、支払い決済のための処理が完了した際に、表示部１２２は、決済完了通知ダイアログａ５３を表示させるのではなく、コード決済画面Ａ５から当該完了の旨を示す決済完了画面（不図示）に遷移させてもよい。

図８（ａ）に示すように、取得元指定画面Ａ７は、食事データの取得元の飲食施設を指定するための画面である。取得元選択画面Ａ７は、取得元から除外する飲食施設を指定入力するための取得元除外入力フォームａ７１と、取得元除外入力フォームａ７１で入力された内容を登録するための登録ボタンａ７２と、を含む。例えば、取得元除外入力フォームａ７１で「会社Ａ 社員食堂」が指定入力されて登録ボタン７２が押下されると、条件受付部１１５が、「会社Ａ 社員食堂」を取得元から除外する指定を受け付けて、「会社Ａ 社員食堂ではないこと」とする条件を取得元条件に追加設定する。

図８（ｂ）に示すように、記録先指定画面Ａ８は、食事データの記録先の食事関連サービスを指定するための画面である。記録先指定画面Ａ８は、記録先とする食事関連サービスを指定入力するための記録先指定入力フォームａ８１と、記録先指定入力フォームａ８１で入力された内容を登録するための登録ボタン８２と、を含む。例えば、記録先指定入力フォームａ８１で「ヘルスケアサービス」と「食事管理サービス」とが指定入力されて登録ボタンａ８２が押下されると、条件受付部１１５が、「ヘルスケアサービスであること」と「食事管理サービスであること」とする記録先条件を設定する。

図８（ｃ）に示すように、通知指定画面Ａ９は、第１ユーザの食事内容の第２ユーザに対する通知に関する指定をするための画面である。通知指定画面Ａ９は、通知先の第２ユーザ（本例では、ユーザＵ２ａ・ユーザＵ２ｂ）を指定入力するための通知先指定入力フォームａ９１と、通知対象の食事を指定入力するための通知対象指定入力フォームａ９２と、登録ボタンａ９３と、を含む。通知先指定入力フォームａ９１で新たにユーザＵ２ｃが指定入力されて登録ボタンａ８２が押下されると、指定受付部１２１は、通知先の第２ユーザにユーザＵ２ｃを加える。

＜５．データ構成例＞
図９〜図１０を参照して、統合決済システム１のデータ構成例を説明する。なお、本例で説明する各種情報において、図９〜図１０で例示する各種情報に含まれる項目が全て含まれる必要はなく、また、これら以外の項目が含まれてもよく、各種情報を用いた処理等に応じて適宜設定すればよい。

図９に示すように、食事データは、トランザクションＩＤと、利用人数と、メニューの名前を示すメニュー名と、そのメニューにおけるカロリーと、タンパク質と、炭水化物と、食物繊維と、脂質と、糖質と、食塩相当量と、トランザクションの実行日時を示す取引日時とを含む。なお、この取引日時を、第１ユーザが飲食施設で食事をした日時を示す食事日時とみなしてもよい。

図１０に示すように、ユーザ情報は、ユーザＩＤと、ユーザ名と、生年月日と、トークンと、を含む。また、決済手段対応情報は、ユーザＩＤと、電子決済手段名と、電子決済手段ＩＤと、事業者ＩＤと、広告ＩＤと、を含む。また、決済情報は、決済ＩＤと、決済日時（日付）と、決済日時（時分秒）と、事業者ＩＤと、事業者名と、決済金額と、ユーザＩＤと、トランザクションＩＤと、を含む。

＜６．動作例＞
図１１〜図１３を参照して、本実施形態に係る統合決済システム１の動作例を説明する。

＜６−１．フロー＞
図１１は、決済装置１００が、飲食施設で飲食代をユーザが支払う際に、当該ユーザから選択された電子決済手段において飲食代の支払い決済をするための処理を行い、また、支払い決済の後、その飲食施設での食事の食事データを食事関連サービスに連携する処理の流れの例を示すフロー図である。なお、本例で説明するコード決済は、ＣＰＭ方式とする。なお、以下に示す処理の順番は一例であって、適宜、変更されてもよい。

図１１に示すように、決済装置１００の表示部１２２は、電子決済出力情報を生成する（Ｓ１０）。通信部１３０は、複数の電子決済手段の中でユーザが利用する電子決済手段を選択させるために、生成された電子決済出力情報をユーザ装置２００に送信する（Ｓ１１）。決済手段受付部１２３は、ユーザ装置２００から、ユーザが利用する電子決済手段の選択を受け付ける（Ｓ１２）。

登録された支払い方法がコード決済による方法の場合（Ｓ１３のＹｅｓ）、決済手段受付部１２３が電子決済手段の選択を受け付けた際に、コード生成部１２４は、第１識別コードを生成する（Ｓ１４）。通信部１３０は、第１識別コードを、電子決済手段の選択を受け付けたユーザ装置２００に送信する（Ｓ１５）。

要求受付部１１２は、ユーザ装置２００で表示された第１識別コードを読み取った施設端末３００から、第１識別コードの事業者ＩＤを含む決済要求を受け付ける（Ｓ１６）。

決済処理部１１３は、第１識別コードの事業者ＩＤが示す事業者と決済要求の要求元の飲食施設が属する事業者とが一致する場合（Ｓ１７のＹｅｓ）、決済要求に応じて、選択された電子決済手段におけるコード決済による決済処理を行う（Ｓ１８）。決済処理部１１３は、通信部１３０を介して、当該決済の処理結果をユーザ装置２００及び施設端末３００に送信する（Ｓ１９）。

決済処理部１１３は、第１識別コードの事業者ＩＤが示す事業者と決済要求の要求元の飲食施設が属する事業者とが一致しない場合（Ｓ１７のＮｏ）、決済エラーを示すエラーメッセージを生成する（Ｓ２０）。通信部１３０は、当該エラーメッセージをユーザ装置２００及び施設端末３００に送信する（Ｓ２１）。

登録された支払い方法がコード決済による方法ではない場合（Ｓ１３のＮｏ）、要求受付部１１２は、ユーザ装置２００から決済要求を受け付ける（Ｓ２２）。決済処理部１１３は、決済要求に応じて、選択された電子決済手段で登録された支払い方法及び認証情報により支払いの決済のための決済処理を行う（Ｓ２３）。決済処理部１１３は、通信部１３０を介して、当該処理の結果をユーザ装置２００及び施設端末３００に送信する（Ｓ２４）。

記録先特定部１１１は、食事を記録するサービスをユーザに提供する複数の食事関連サービスの中から、記録先条件に基づいて、ユーザの食事に関する食事データの記録先である少なくとも１つのサービスを特定する（Ｓ２２）。食事データ取得部１１４１は、施設端末３００から、決済処理が行われた場合、飲食施設での食事に関する前記食事データを取得する（Ｓ２３）。食事データ送信部１３１は、食事データを、特定された少なくとも１つのサービスのそれぞれのサービス提供装置５００に送信する（Ｓ２４）。

＜６−２．インタラクション＞
図１２〜図１３は、統合決済システム１において、サービス提供装置５００にユーザ認証した際に発行されたトークンを用いてサービス提供装置５００にユーザが飲食施設で支払い決済した食事の食事データを連携する際の決済装置１００とユーザ装置２００と、施設端末３００と、サービス提供装置５００との相互作用を示すシーケンス図である。なお、本例では、支払い方法を、ＣＰＭ方式のコード決済による支払いとする。

図１２に示すように、サービス提供装置５００の食事関連サービスにユーザＵがアクセスした際に、ユーザＵのユーザ装置２００は、食事関連サービスに対するユーザ認証をするための認証要求をサービス提供装置５００に行う（Ｓ３０）。サービス提供装置５００は、この認証要求を受け付けると、ユーザ認証の処理を行い、決済装置１００との連携のためのトークンをユーザＵに対して発行する（Ｓ３１）。サービス提供装置５００は、発行したトークを送信してユーザ認証の結果を応答する（Ｓ３２）。

ユーザ装置２００は、サービス提供装置５００から受け付けたトークの登録要求を決済装置１００に行う（Ｓ３３）。決済装置１００は、登録要求されたトークンを、ユーザＵのユーザ情報に登録する（Ｓ３４）。

ユーザ装置２００は、飲食施設での飲食代の支払いの際に、第１識別コードを表示させる（Ｓ３５）。施設端末３００は、表示された第１識別コードを読み取る（Ｓ３６）。施設端末３００は、第１識別コードを読み取ると、決済要求を決済装置１００に送信する（Ｓ３７）。決済装置１００は、決済要求を受信すると、決済処理を実行する（Ｓ３８）。決済処理を実行した際、決済装置１００は、決済情報を生成する。決済装置１００は、生成した決済情報を施設端末３００に送信する（Ｓ３９）。施設端末３００は、受信した決済情報を支払い対象の食事データと関連付けて登録する（Ｓ４０）。この際、施設端末３００は、トランザクションＩＤを用いて、トランザクションごとにまとめた食事データを構成する。

図１３に示すように、施設端末３００は、連携対象のトランザクションごとの食事データを抽出する（Ｓ５０）。施設端末３００は、抽出されたトランザクションごとの食事データを決済装置１００に送信する（Ｓ５１）。

決済装置１００は、トランザクションごとの食事データを受信すると、トランザクションＩＤをトークンに変換、すなわちトランザクションＩＤをキーとして該当するユーザのトークンを導出する（Ｓ５２）。サービス提供装置５００に対してはトークンがユーザを識別する情報となるため、決済装置１００は、トークンごと（すなわちユーザごと）にまとめた食事データに変換する（Ｓ５３）。決済装置１００は、ユーザごとに、記録先として特定された食事関連サービスに対して、ユーザごとにまとめたトークンを含む食事データをサービス提供装置５００に送信する（Ｓ５４）。サービス提供装置５００は、送信された食事データを受け付けると、それをユーザＵの情報として自身の記憶部に登録する（Ｓ５５）。

食事関連サービスで食事内容をユーザが確認するために、ユーザ装置２００から、サービス提供装置５００に食事データの照会の要求を行う（Ｓ５６）。サービス提供装置５００は、照会の要求を受け付けると、ユーザＵの食事データを抽出する（Ｓ５７）。サービス提供装置５００は、抽出した食事データを送信して照会結果を応答する（Ｓ５８）。

＜７．ハードウェア構成＞
図１４を参照して、上述してきた決済装置１００をコンピュータ８００により実現する場合のハードウェア構成の一例を説明する。なお、それぞれの装置の機能は、複数台の装置に分けて実現することもできる。

図１４に示すように、コンピュータ８００は、プロセッサ８０１と、メモリ８０３と、記憶装置８０５と、入力Ｉ／Ｆ部８０７と、データＩ／Ｆ部８０９と、通信Ｉ／Ｆ部８１１、及び表示装置８１３を含む。

プロセッサ８０１は、メモリ８０３に記憶されているプログラムを実行することによりコンピュータ８００における様々な処理を制御する。例えば、決済装置１００の制御部１１０が備える各機能部は、メモリ８０３に一時記憶されたプログラムを、プロセッサ８０１が実行することにより実現可能である。

メモリ８０３は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の記憶媒体である。メモリ８０３は、プロセッサ８０１によって実行されるプログラムのプログラムコードや、プログラムの実行時に必要となるデータを一時的に記憶する。

記憶装置８０５は、例えばハードディスクドライブ（ＨＤＤ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶装置８０５は、オペレーティングシステムや、上記各構成を実現するための各種プログラムを記憶する。この他、記憶装置８０５は、食事データ、ユーザ情報、決済情報、電子決済手段情報、決済手段対応情報、口座管理情報、及び各種出力情報等を登録するテーブルと、当該テーブルを管理するＤＢを記憶することも可能である。このようなプログラムやデータは、必要に応じてメモリ８０３にロードされることにより、プロセッサ８０１から参照される。

入力Ｉ／Ｆ部８０７は、ユーザからの入力を受け付けるためのデバイスである。入力Ｉ／Ｆ部８０７の具体例としては、キーボードやマウス、タッチパネル、各種センサ、ウェアラブル・デバイス等が挙げられる。入力Ｉ／Ｆ部８０７は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）等のインタフェースを介してコンピュータ８００に接続されても良い。

データＩ／Ｆ部８０９は、コンピュータ８００の外部からデータを入力するためのデバイスである。データＩ／Ｆ部８０９の具体例としては、各種記憶媒体に記憶されているデータを読み取るためのドライブ装置等がある。データＩ／Ｆ部８０９は、コンピュータ８００の外部に設けられることも考えられる。その場合、データＩ／Ｆ部８０９は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００へと接続される。

通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部の装置と有線又は無線により、インターネットＮを介したデータ通信を行うためのデバイスである。通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部に設けられることも考えられる。その場合、通信Ｉ／Ｆ部８１１は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００に接続される。

表示装置８１３は、各種情報を表示するためのデバイスである。表示装置８１３の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ウェアラブル・デバイスのディスプレイ等が挙げられる。表示装置８１３は、コンピュータ８００の外部に設けられても良い。その場合、表示装置８１３は、例えばディスプレイケーブル等を介してコンピュータ８００に接続される。また、入力Ｉ／Ｆ部８０７としてタッチパネルが採用される場合には、表示装置８１３は、入力Ｉ／Ｆ部８０７と一体化して構成することが可能である。

なお、本実施形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施の形態を採用することが可能であり、かかる実施の形態も本発明の範囲に含まれる。

上記実施の形態で記載された決済装置１００が備える構成要素は、記憶装置８０５に格納されたプログラムがプロセッサ８０１によって実行されることで、定められた処理が他のハードウェアと協働して実現されるものとする。また、言い換えれば、これらの構成要素は、ソフトウェア又はファームウェアとしても、それと対応するハードウェアとしても想定され、その双方の概念において、「機能」、「手段」、「部」、「処理回路」、「ユニット」、又は「モジュール」等とも記載され、またそれぞれに読み替えることができる。

［変形例］
なお、本発明を上記実施の形態に基づいて説明してきたが、以下のような場合も本発明に含まれる。

［変形例１］
上記実施形態に係る決済装置１００における各構成の少なくとも一部は、ユーザ装置２００が備えていてもよい。例えば、決済装置１００の表示部１２２やコード生成部１２４の機能全てをユーザ装置２００のユーザ用決済アプリに備えさせてもよい。

［変形例２］
上記実施形態に係る食事データ記憶部、ユーザ記憶部、決済手段記憶部及び支払い方法記憶部は、いずれも決済装置１００の記憶部１４０が備える機能部とする例を説明したが、例えば、ユーザ装置２００の記憶部（不図示）が備えてもよい。また、上記実施形態に係る食事データ記憶部、ユーザ記憶部、決済手段記憶部及び支払い方法記憶部は、他の例として、事業者サーバ４００の記憶部（不図示）が備えてもよいし、外部システム５の記憶部（不図示）が備えてもよい。

［変形例３］
上記実施形態に係る決済装置１００がサービス提供装置５００に連携する食事データは、メニューごとに１件のレコードとし、メニュー名及びメニュー名に紐づく栄養素の項目を含んでいる例を説明したが、食事データの構成をこれに限る趣旨ではない。なお、本例は、図１５の左半分（食事データ連携方式）に示すように、事業者サーバ４００（又は施設端末３００）にメニューに関する情報（以下、「メニュー情報」ともいう）としてメニュー別の栄養素の項目が予め登録されて、施設端末３００から取得する食事データにもサービス提供装置５００に提供する食事データにもこの栄養素の項目も含まれている。

上記とは異なる例として、図１５の右半分（メニューＩＤ連携方式）に示すように、食事関連サービスのサービス提供装置５００にメニュー情報としてメニュー別の栄養素が予め登録されて、登録の際にサービス提供装置５００でメニューＩＤが発行されてもよい。この発行されたメニューＩＤは、事業者サーバ４００（又は施設端末３００）に提供された登録されてもよい。この登録されたメニューＩＤを利用して施設端末３００や決済装置１００においてメニューを識別し、メニューＩＤを食事データとしてサービス提供装置５００に連携してもよい。すなわち、決済装置１００が取得しサービス提供装置５００に送信する食事データにはメニューＩＤが含まれていればよく、メニューに含まれる栄養素の項目は食事データには含まれなくてもよくなる（不要となる）。このような構成によれば、汎用的な食事データ・ハブ機能を実現することができる。

１…統合決済システム、１００…決済装置、１１０…制御部、１１１…記録先特定部、１１２…要求受付部、１１３…決済処理部、１１４…ヘルスケアデータ取得部、１１５…条件受付部、１１６…利用情報取得部、１１７…施設特定部、１１８…蓄積部、１１９…データ生成部、１２０…算出部、１２１…指定受付部、１２２…表示部、１２３…決済手段受付部、１２４…コード生成部、１２５…特典付与部、１３０…通信部、１３１…食事データ送信部、１４０…記憶部、２００…ユーザ装置、３００…施設端末、４００…事業者サーバ、５…外部システム、５００…サービス提供装置、８００…コンピュータ、８０１…プロセッサ、８０３…メモリ、８０５…記憶装置、８０７…入力Ｉ／Ｆ部、８０９…データＩ／Ｆ部、８１１…通信Ｉ／Ｆ部、８１３…表示装置。

Claims (13)

1. 食事を記録するサービスをユーザに提供する複数のサービスの中から、記録先条件に基づいて、第１ユーザの食事のメニュー識別情報と、前記メニュー識別情報に紐づく栄養素の項目と、を含む食事データの記録先である少なくとも１つのサービスを特定する記録先特定部と、
   飲食施設の施設端末から、前記飲食施設での食事に対する代金の前記第１ユーザによる支払いの際、前記支払いの決済要求を受け付ける要求受付部と、
   前記決済要求に基づいて、前記支払いの決済のための決済処理を行う決済処理部と、
   前記決済処理が行われた場合、前記決済要求の要求元の施設端末から、前記飲食施設での食事に関する前記食事データであって前記決済処理に関する前記食事データを取得する食事データ取得部と、
   前記食事データを、前記特定された少なくとも１つのサービスのそれぞれのサービス提供装置に送信する食事データ送信部と、を備える、
   決済装置。
2. 前記決済処理部は、前記決済処理を実行した際、前記決済処理の決済情報であって前記決済処理を含む一連の処理を識別するための情報を含む決済情報を生成し、
   前記決済装置は、前記決済要求の要求元の施設端末に、前記決済情報を送信する送信部を備え、
   前記食事データ取得部は、前記施設端末から、前記一連の処理ごとにまとめた前記食事データを取得する、
   請求項１に記載の決済装置。
3. 前記決済装置は、前記第１ユーザの第１ユーザ装置から、前記複数のサービスの中から前記第１ユーザが利用する前記少なくとも１つのサービスを示す前記記録先条件を受け付ける条件受付部をさらに備える、
   請求項１または２に記載の決済装置。
4. 前記決済装置は、前記記録先条件に含まれる、前記サービス提供装置の機能の利用実績を示す利用情報を取得する利用情報取得部をさらに備える、
   請求項１または２に記載の決済装置。
5. 複数の飲食施設の中から、取得元条件に基づいて、前記食事データの取得元の前記飲食施設を特定する施設特定部をさらに備え、
   前記食事データ取得部は、前記決済処理が行われた場合、前記特定された前記飲食施設の前記施設端末から、前記食事データを取得する、
   請求項１から４のいずれか一項に記載の決済装置。
6. 所定期間、前記食事データを食事データ記憶部に蓄積する蓄積部と、
   前記食事データ取得部により前記食事データが取得できない場合、前記蓄積された食事データに基づいて、取得できない食事データの代わりの仮の食事データを生成するデータ生成部と、
   前記食事データ送信部は、前記食事データの代わりに、前記仮の食事データを、前記サービス提供装置に送信する、
   請求項１から５のいずれか一項に記載の決済装置。
7. 前記食事データは、前記食事での前記飲食施設の利用人数を含み、
   前記決済装置は、前記食事データと前記利用人数とに基づいて、前記食事での一人当たりの食事量を算出する算出部をさらに備え、
   前記食事データ送信部は、前記サービス提供装置に、前記一人当たりの食事量を含む前記食事データを送信する、
   請求項１から６のいずれか一項に記載の決済装置。
8. 前記食事データ送信部は、前記第１ユーザと、前記第１ユーザとは異なる第２ユーザと、を関連付けて記憶するユーザ記憶部を参照して、前記第２ユーザの第２ユーザ装置に、前記食事データの少なくとも一部を送信する、
   請求項１から７のいずれか一項に記載の決済装置。
9. 前記食事データは、前記食事の日時を含み、
   前記決済装置は、前記第１ユーザの第１ユーザ装置又は前記第２ユーザ装置から、前記食事データ送信部による前記第２ユーザ装置への送信対象の食事の曜日、日にち、又は時間帯の少なくともいずれか一つの指定を受け付ける指定受付部をさらに備え、
   前記食事データ送信部は、前記指定にさらに基づいて、前記第２ユーザ装置に、前記第１ユーザの前記食事データの少なくとも一部を送信する、
   請求項８に記載の決済装置。
10. 前記第１ユーザと、複数の前記飲食施設を所有する複数の事業者それぞれの電子決済手段と、の対応関係を示す決済手段対応情報を記憶する決済手段記憶部を参照して、前記第１ユーザに対応する複数の電子決済手段を前記第１ユーザの第１ユーザ装置に表示させる表示部と、
    前記第１ユーザ装置から、前記表示された前記複数の電子決済手段のうち前記ユーザが利用する電子決済手段の選択を受け付ける決済手段受付部と、
    前記第１ユーザが使用可能な支払い方法を示す支払い方法情報を記憶する支払い方法記憶部を参照して、前記支払い方法がコード決済による方法の場合、前記決済手段受付部が前記電子決済手段の選択を受け付けた際に、前記選択された前記電子決済手段における前記事業者を識別するための事業者識別情報を含む前記コード決済のための識別コードを生成するコード生成部と、
    前記識別コードを、前記電子決済手段の選択を受け付けた前記第１ユーザ装置に送信するコード送信部と、
    前記支払いの決済要求は、前記第１ユーザ装置で出力されて前記施設端末で読み取られた前記識別コードの前記事業者識別情報を含み、
    前記決済処理部は、前記決済要求に基づいて、前記識別コードの前記事業者識別情報が示す事業者と前記決済要求の要求元の前記飲食施設が属する前記事業者とが一致する場合、前記選択された前記電子決済手段で前記コード決済による前記支払いの決済のための処理を行う、
    請求項１から９のいずれか一項に記載の決済装置。
11. 前記決済装置は、前記取得した食事データが特典条件を満たす場合、前記第１ユーザに、前記支払いに利用可能な特典を付与する特典付与部、をさらに備える、
    請求項１から１０のいずれか一項に記載の決済装置。
12. コンピュータに、
    食事を記録するサービスをユーザに提供する複数のサービスの中から、記録先条件に基づいて、第１ユーザの食事のメニュー識別情報と、前記メニュー識別情報に紐づく栄養素の項目と、を含む食事データの記録先である少なくとも１つのサービスを特定する記録先特定機能と、
    飲食施設の施設端末から、前記飲食施設での食事に対する代金の前記第１ユーザによる支払いの際、前記支払いの決済要求を受け付ける要求受付機能と、
    前記決済要求に基づいて、前記支払いの決済のための決済処理を行う決済処理機能と、
    前記決済処理が行われた場合、前記決済要求の要求元の施設端末から、前記飲食施設での食事に関する前記食事データであって前記決済処理に関する前記食事データを取得する食事データ取得機能と、
    前記食事データを、前記特定された少なくとも１つのサービスのそれぞれのサービス提供装置に送信する食事データ送信機能と、を実現させる、
    プログラム。
13. コンピュータが、
    食事を記録するサービスをユーザに提供する複数のサービスの中から、記録先条件に基づいて、第１ユーザの食事のメニュー識別情報と、前記メニュー識別情報に紐づく栄養素の項目と、を含む食事データの記録先である少なくとも１つのサービスを特定し、飲食施設の施設端末から、前記飲食施設での食事に対する代金の前記第１ユーザによる支払いの際、前記支払いの決済要求を受け付け、
    前記決済要求に基づいて、前記支払いの決済のための決済処理を行い、
    前記決済処理が行われた場合、前記決済要求の要求元の施設端末から、前記飲食施設での食事に関する前記食事データであって前記決済処理に関する前記食事データを取得し、
    前記食事データを、前記特定された少なくとも１つのサービスのそれぞれのサービス提供装置に送信する、
    情報処理方法。
    

Images