WO2021192322A1 - 制御方法、情報端末、プログラム、記録媒体、及び情報提供方法 - Google Patents

Abstract

制御方法は、情報端末に格納された識別情報を第１サーバに送信し、識別情報に基づき、第１サーバからユーザの生体情報を取得し、ユーザの生体情報に基づき、ユーザの病気の進行による食事制限の程度を示す情報を生成し、メニュー情報及び食事制限の程度を示す情報に基づいて、食事制限の程度を示す情報に対応したユーザの個別メニューを生成し、ユーザの情報端末のディスプレイに表示されたレストランにおける料理の注文を受け付けるための第２操作画面を介して、個別メニューを表示し、個別メニューにて選択された料理を示す注文料理情報及び席ＩＤを第２サーバに送信する。

Description

制御方法、情報端末、プログラム、記録媒体、及び情報提供方法

　本開示は、情報端末の制御方法等に関する。

　特許文献１は、ユーザの嗜好情報及び摂取が禁止された食材を表す危険食材情報、及び摂取量管理のための健康管理情報を含む個人データに基づいて、個人データに適合したメニューを提案する技術を開示する。

　特許文献２は、飲食店に設置され、メニューのオーダー情報等を入力して接客業務を支援するための飲食店用注文受付装置を開示する。特許文献２の飲食店用注文受付装置は、メニューのオーダー情報を入力できるオーダー入力画面を表示デバイスに表示させる手段を備えている。前記オーダー入力画面において、テーブルに設定されている個々の座席毎にメニューのオーダー情報が入力される。

特開２００５－２２２１９１号公報 特開２００８－２９９８２１号公報

　上記の従来技術では、更なる改善が必要とされていた。

　本開示の一態様に係る制御方法は、ユーザを特定する識別情報に対応させて前記ユーザの生体情報を管理する第１サーバとネットワークを介して通信する情報端末の制御方法であって、前記ユーザの前記情報端末のディスプレイに表示される第１操作画面を介して、レストランＩＤ及び前記ユーザの座席を示す席ＩＤを取得し、前記レストランＩＤに基づき、前記レストランＩＤに対応するレストランに関連する第２サーバからネットワークを介して前記レストランが提供する１以上の料理を示すメニュー情報を取得し、前記情報端末に格納された前記識別情報を前記第１サーバに送信し、前記識別情報に基づき、前記第１サーバから前記ユーザの生体情報を取得し、前記メニュー情報及び前記ユーザの生体情報に基づき、前記ユーザの病気の進行による食事制限の程度を示す情報を生成し、前記食事制限の程度を示す情報に対応した前記ユーザの個別メニューを生成し、前記ユーザの情報端末のディスプレイに表示された前記レストランにおける料理の注文を受け付けるための第２操作画面を介して、前記個別メニューを表示し、前記個別メニューにて選択された料理を示す注文料理情報及び前記席ＩＤを前記第２サーバに送信することを含む。

　上記態様により、更なる改善を実現できる。

一般的な料理の注文システムの構成を示す図である。 本開示の情報処理システムの情報基盤の全体像の一例を示す図である。 本実施の形態の情報処理システムの全体像をより詳しく示す図である。 本実施の形態に係る情報処理システムの具体的な構成の一例を示す図である。 レストランのある店舗のレイアウトを示した図である。 座席に対するＱＲコード（登録商標、以下同様）の設置例を示す図である。 座席に対するＱＲコードの設置例を示す図である。 座席に対するＱＲコードの設置例を示す図である。 座席に対するＱＲコードの設置例を示す図である。 ユーザがＱＲコードを情報端末に読み取らせる場合に情報端末に表示される操作画面の一例を示す図である。 ＱＲコードリーダーがＱＲコードを読み取った直後の情報端末に表示される操作画面の一例を示す図である。 レストランＡ社の標準メニューを含む操作画面の一例を示す図である。 ユーザが操作画面を操作して標準メニューから料理を注文するシーンの一例を示した図である。 標準メニューから注文する料理を最終的に決定する際に表示される操作画面の一例を示す図である。 料理を注文するユーザがマッチングアプリを起動した直後に情報端末に表示される認証画面の一例を示す図である。 認証画面の他の一例を示す図である。 マッチングアプリによるユーザ認証が終わった直後に表示されるホーム画面の一例を示す図である。 マッチングアプリを起動したユーザが自席に対応するＱＲコードを情報端末に読み取らせる場合に情報端末に表示される操作画面の一例を示す図である。 ＮＦＣによりレストランＩＤ及び席ＩＤを取得する場合に情報端末に表示される操作画面の一例を示す図である。 マッチングアプリが個別メニューを生成している際に情報端末に表示される表示画面の一例を示す図である。 個別メニューを含む操作画面の一例を示す図である。 ユーザが操作画面を操作して個別メニューから料理を注文するシーンを示した図である。 個別メニューから注文する料理を最終的に決定する際に表示される操作画面の一例を示す図である。 これまでの注文履歴をユーザが確認する時に表示される注文履歴画面の一例を示す図である。 糖尿病患者に課される食事制限の一例を纏めた表である。 今回の食事でのカロリーの摂取許容量を算出する例を説明するためのグラフである。 高血圧症患者の血圧と塩分摂取量との関係を示すグラフである。 第１サーバで管理されているユーザの定期健康診断の診断結果を含む情報のデータ構成の一例を示す図である。 第１サーバで管理されているユーザの病気診断書の記載内容を含む情報のデータ構成の一例を示す図である。 第１サーバで管理される生体情報を含む情報のデータ構成の一例を示す図である。 食材情報のデータ構成の一例を示す図である。 減塩ラーメンと野菜餃子の食材情報の一例を示す図である。 本実施の形態における情報処理システムの処理の全体像の一例を示すシーケンス図である。 標準メニューから料理が注文される場合の情報端末の処理の一例を示すフローチャートである。 個別メニューから料理が注文される場合の情報端末の処理の一例を示すフローチャートである。 図３２のステップＳ１の処理の詳細を示すフローチャートである。 図３２のステップＳ２の処理の詳細を示すフローチャートである。 図３２のステップＳ３の処理の詳細を示すフローチャートである。 図３２のステップＳ４の処理の詳細を示すフローチャートである。 食事制限の程度を示す情報を算出するための式（１）を示す図である。 各料理の優先度を算出するための式（２）を示す図である。 本実施の形態における情報処理システムの具体的な実装形態の一例を示す図である。 マッチングアプリが起動してから個別メニューを表示するまでのファイルに対するマッチングアプリの処理の一例を示すフローチャートである。 個別メニューの１つ目のバリエーションを含む操作画面の一例を示す図である。 個別メニューの２つ目のバリエーションを含む操作画面の一例を示す図である。 グレイアウト表示されたタイルオブジェクトを含む操作画面の一例を示す図である。 個別メニューの３つ目のバリエーションを含む操作画面の一例を示す図である。 個別メニューが第２サーバで生成される形態が採用された場合において、第１サーバに生体情報がアップロードされる際の処理の一例を示すシーケンス図である。 個別メニューが第２サーバで生成される形態が採用された場合において、第１サーバが病気情報を取得する際の処理の一例を示すシーケンス図である。 ユーザが第２サーバに対して病気情報のアクセスが許可された場合の情報処理システムの処理の一例を示すシーケンス図である。 ユーザが第２サーバに対して病気情報のアクセスが不許可にされた場合の情報処理システムの処理の一例を示すシーケンス図である。 個別メニューが第２サーバで生成される形態が採用された場合において、個別メニューが生成される際の情報処理システムの処理の一例を示すシーケンス図である。 個別メニューが第２サーバで生成される形態が採用された場合において、個別メニューの生成が拒否された場合の情報処理システムの処理の一例を示すシーケンス図である。

　（本開示に至る経緯）
　近年、糖尿病、高血圧、高脂血症等の生活習慣病に罹患している患者が増大している。このような患者は、カロリー摂取量又はアルコール摂取量等を控えるよう食事制限が課されており、この食事制限を遵守するように日々の食事に注意を払うことが要求されている。しかしながら、自宅では食材の量を任意に調整して料理を作ることができるため、このような食事制限を遵守することは比較的容易であるが、外食時ではレストラン側が定めたメニューの中から患者は料理を注文せざるを得ないため、このような食事制限を遵守することは容易ではない。したがって、レストランは、このような食事制限を考慮に入れて患者にとって適切な料理を主に含むメニューを提案できれば、顧客満足度が向上して他のレストランとの差別化を図ることが可能となる。

　しかしながら、食事制限の内容は、病気ごとに異なるとともに、病気に対する患者の改善度合いに応じても異なるため、ユーザにとって適切なメニューを作成することは容易ではない。

　さらに、患者である客と同じテーブルに座っている別の客が注文した料理が間違えて患者である客に配膳されると、当該客に不快感を与えてしまう。さらに、間違えて配膳された料理が当該客の食事制限に対応しておらず、しかもその料理を当該客が食してしまった場合、当該客の健康を害するおそれもある。したがって、このような配膳ミスは回避しなければならない。

　上述した特許文献１には、下記の技術が開示されている。ある店舗においてテーブルごとに設けられたメニュー端末にユーザＩＤ及びパスワードをユーザに入力させ、データセンターからそのユーザの個人データとその店舗の店舗データとを店舗サーバが取得し、個人データ及び店舗データに基づいて問題食材（危険食材及び苦手食材）が除かれたメニュー及びお勧めメニュー（そのユーザの好物が多く含まれているメニュー等）を店舗サーバが決定し、決定されたメニューをメニュー端末が表示する。

　しかしながら、特許文献１では、メニュー端末にはテーブル毎にユニークなテーブル番号が設定されていることからも明らかなように、テーブル単位での料理の注文のみが考慮されており、座席単位での料理の注文は何ら考慮されていない。そのため、特許文献１は、患者である客と同一テーブルに座っている別の客が注文した料理であって、当該患者の食事制限に対応していない料理が間違えて患者の座席に配膳されるといった配膳ミスが発生する可能性がある。

　一方、ユーザの個人データはセンシティブな情報であるため、その情報がユーザの許諾なしに第三者に提供されることは妥当ではない。

　しかしながら、特許文献１では、ユーザの個人データはデータセンターから店舗サーバへ送信されているため、ユーザの許諾なしに個人データが店舗側に提供されるという課題もある。

　特許文献２においては、個々のテーブルに設定されている個々の座席毎に料理のオーダー情報が入力デバイスによって入力及び登録指示可能にするオーダー入力画面が開示されている。このオーダー入力画面には、複数の座席を示す座席オブジェクトを含む座席位置画像と、各料理品目に対応する複数の料理特定画像とが含まれている。例えば、店員は座席位置画像から所望の座席の座席オブジェクトをタッチした後、所望の料理品目に対応する料理特定画像をタッチする。これにより、タッチされた座席に着席する客が個別にオーダーする料理品目が選択される。

　このように、特許文献２では、座席と料理品目との対応付けはオーダー入力画面を介した店員の手入力により行われている。そのため、座席と料理品目との対応付けに際して誤入力が生じる可能性がある。特に、店の混雑時においてはこのような誤入力が生じ易い。さらに、特許文献２のオーダー入力画面には、特許文献２の第３８図に示されるように座席位置画像及び料理特定画像以外にも様々な情報及びオブジェクトが含まれている。このことからも、特許文献２のオーダー入力画面においてはこのような誤入力が生じる可能性が高いことが分かる。そのため、特許文献２も特許文献１と同様、上述の配膳ミスを防止することはできない。

　本開示は、上記の課題を解決するためになされたものであり、食事制限が課されるユーザの席に食事制限に対応していない料理が配膳されることを防止することを第１の目的とする。

　さらに、本開示は、第１サーバが記憶するセンシティブな情報がユーザの許諾なしに第１サーバの外部に漏洩することを防止することを第２の目的とする。

　本開示の一態様に係る制御方法は、ユーザを特定する識別情報に対応させて前記ユーザの生体情報を管理する第１サーバとネットワークを介して通信する情報端末の制御方法であって、前記ユーザの前記情報端末のディスプレイに表示される第１操作画面を介して、レストランＩＤ及び前記ユーザの座席を示す席ＩＤを取得し、前記レストランＩＤに基づき、前記レストランＩＤに対応するレストランに関連する第２サーバからネットワークを介して前記レストランが提供する１以上の料理を示すメニュー情報を取得し、前記情報端末に格納された前記識別情報を前記第１サーバに送信し、前記識別情報に基づき、前記第１サーバから前記ユーザの生体情報を取得し、前記ユーザの生体情報に基づき、前記ユーザの病気の進行による食事制限の程度を示す情報を生成し、前記メニュー情報及び前記食事制限の程度を示す情報に基づいて、前記食事制限の程度を示す情報に対応した前記ユーザの個別メニューを生成し、前記ユーザの情報端末のディスプレイに表示された前記レストランにおける料理の注文を受け付けるための第２操作画面を介して、前記個別メニューを表示し、前記個別メニューにて選択された料理を示す注文料理情報及び前記席ＩＤを前記第２サーバに送信することを含む。

　上記の態様によると、例えば、料理を注文するに際して、ユーザの情報端末のディスプレイには第１操作画面が表示され、この第１操作画面を介してレストランＩＤ及びユーザの座席を示す席ＩＤが取得される。取得されたレストランＩＤからそのレストランＩＤに対応するレストランが提供する１以上の料理を示すメニュー情報が第２サーバから取得される。さらに、情報端末に格納された識別情報が第１サーバに送信され、当該情報端末のユーザの生体情報が取得される。

　取得されたユーザの生体情報に基づいて当該ユーザの病気の進行による食事制限の程度を示す情報が生成される。生成された食事制限の程度を示す情報と取得されたメニュー情報とに基づいて、食事制限の程度を示す情報に対応するユーザの個別メニューが生成される。この個別メニューは、第２操作画面を介して情報端末のディスプレイに表示される。表示された個別メニューの中から料理が選択され、その料理を示す注文料理情報が席ＩＤと対応付けられて第２サーバに送信される。

　このように、本態様では、ユーザが料理を注文する一連の過程の中で、個別メニューからユーザにより選択された料理を示す注文料理情報とユーザの座席との対応付けが人手を介することなく自動的に行われている。これにより、例えば、食事制限が課されるユーザの座席に、当該ユーザと同一テーブルに別のユーザが注文した料理であって、食事制限に対応していない料理が配膳される配膳ミスを防止できる。その結果、食事制限が課されるユーザに不快感を与えることを防止できる。さらに、このような配膳ミスが防止されるため、食事制限が課されるユーザが間違えて配膳された料理を食したことにより、当該ユーザの健康を害することを防止できる。

　さらに、本態様では、生体情報が第２サーバに送信されていないため、生体情報がレストラン側に漏洩することが防止される。さらに、本態様では、注文料理情報はユーザを特定する識別情報ではなく席ＩＤと対応付けられて送信されているため、識別情報がレストラン側に漏洩することが防止される。

　上記制御方法において、前記個別メニューは、前記メニュー情報及び前記食事制限の程度を示す情報に基づき、前記メニュー情報に含まれる各料理において前記食事制限の程度を示す情報が示す前記ユーザが避けるべき食材を減少させて生成された料理を含んでもよい。

　本態様によれば、個別メニューには、食事制限の程度を示す情報が示すユーザが避けるべき食材が減少された料理が含まれる。これにより、ユーザの健康に甚大な悪影響を及ぼすことが防止される。

　上記制御方法において、前記食材を減少させることには、前記食材の量をゼロにすることを含んでもよい。

　本態様によれば、個別メニューには、食事制限の程度を示す情報が示すユーザが避けるべき食材がゼロにされた料理が含まれる。これにより、ユーザの健康に甚大な悪影響を及ぼすことがより確実に防止される。

　上記制御方法において、前記個別メニューは、前記メニュー情報及び前記食事制限の程度を示す情報に基づき、前記メニュー情報に含まれる各料理において前記食事制限の程度を示す情報が示す前記ユーザが避けるべき食材を含む料理を除外またはグレイアウトさせて生成されてもよい。

　本態様によれば、食事制限の程度を示す情報が示すユーザが避けるべき食材を含む料理が除外又はグレイアウトされた個別メニューが生成されるため、当該ユーザは、避けるべき食材を含む料理を意識せずに、或いはそのような料理を容易に確認でき、料理の注文をスムーズに行うことができる。

　上記制御方法において、前記個別メニューは、前記１以上の料理において、前記ユーザの病気の進行に対応する不足しやすい栄養成分を含む食材を追加した一の料理を含んでもよい。

　本態様によれば、個別メニューには、ユーザの病気の進行に対応する不足しやすい栄養成分を含む食材が追加された一の料理が含まれている。そのため、専門知識が要求されるために食事制限のあるユーザが特定することが困難な不足しがちな栄養成分を補うことが可能な料理を当該ユーザに提案できる。

　上記制御方法において、前記個別メニューは、前記ユーザの病気の進行に対応する不足しやすい栄養成分を補うための料理の組合せを示す表示を含んでもよい。

　本態様によれば、個別メニューには、ユーザの病気の進行に対応する不足しやすい栄養成分を補うための料理の組み合わせを示す表示が含まれている。そのため、専門知識が要求されるために食事制限のあるユーザが特定することが困難な不足しがちな栄養成分を補うことが可能な料理の組み合わせを当該ユーザに提案できる。

　上記制御方法において、前記個別メニューは、前記１以上の料理において、所定期間における前記ユーザの過去の食事において、前記ユーザが不足していた栄養成分を含む食材を追加した一の料理を含んでもよい。

　本態様によれば、個別メニューには、１以上の料理において、所定期間におけるユーザの過去の食事において、ユーザが不足していた栄養成分を含む食材を追加した一の料理が含まれている。そのため、専門知識が要求されるために食事制限のあるユーザにとって特定することが困難な栄養成分を補うことが可能な料理を当該ユーザに提案できる。

　上記制御方法において、前記個別メニューは、所定期間における前記ユーザの過去の食事において、前記ユーザが不足していた栄養成分を補うための料理の組合せを示す表示を含んでもよい。

　本態様によれば、個別メニューには、所定期間におけるユーザの過去の食事において、ユーザが不足していた栄養成分を補うための料理の組合せを示す表示が含まれる。そのため、専門知識が要求されるために食事制限のあるユーザにとって特定することが困難な不足しがちな栄養成分を、補うことが可能な料理の組み合わせを当該ユーザに提案できる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、前記個別メニューは、前記１以上の料理の中で、前記今回の食事での摂取許容量を超える前記特定の栄養成分を含む一の料理において、前記特定の栄養成分の量を前記今回の食事での摂取許容量以下にしたものを含んでもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間における摂取許容量から所定期間における過去の食事での累積摂取量を引いた量以下を示す情報が、今回の食事での摂取許容量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事での摂取許容量を超える料理については、摂取許容量以下にされた上で個別メニューに含まれる。これにより、食事制限のあるユーザは、病気を悪化させる特定の栄養成分の量を意識せずに料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取目標量を示す情報を含み、前記今回の食事での摂取目標量を示す情報は、所定期間における摂取目標量から前記所定期間における過去の食事での累積摂取量を引いた量以上を示し、前記個別メニューは、前記１以上の料理の中で、前記今回の食事での摂取目標量未満の前記特定の栄養成分を含む一の料理において、前記特定の栄養成分の量を前記今回の食事での摂取目標量以上にしたものを含んでもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間における摂取目標量から所定期間における過去の食事での累積摂取量を引いた量以上を示す情報が、今回の食事での摂取目標量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事での摂取目標量未満の料理については、摂取目標量以上にされた上で個別メニューに含まれる。これにより、食事制限のあるユーザは、病気を改善させる特定の栄養成分の量を意識せずに料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に対応する今回の食事でのカロリーの摂取許容量を示す情報を含み、前記今回の食事でのカロリーの摂取許容量を示す情報は、所定期間におけるカロリーの摂取許容量から前記所定期間における過去の食事でのカロリーの累積摂取量を引いた量以下を示し、前記個別メニューは、前記１以上の料理の中で、前記今回の食事でのカロリーの摂取許容量を超えるカロリーを含む一の料理において、前記今回の食事でのカロリーの摂取許容量以下にしたものを含んでもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間におけるカロリーの摂取許容量から所定期間における過去の食事でのカロリーの累積摂取量を引いた量以下を示す情報が、今回の食事でのカロリーの摂取許容量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事でのカロリーの摂取許容量を超える料理については、カロリーの摂取許容量以下にされた上で個別メニューに含まれる。これにより、食事制限のあるユーザは、カロリーの摂取量を意識せずに料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、前記個別メニューは、前記１以上の料理において、前記今回の食事での摂取許容量を超える前記特定の栄養成分を含む一の料理を除外又はグレイアウトさせて生成されてもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間における摂取許容量から所定期間における過去の食事での累積摂取量を引いた量以下を示す情報が、今回の食事での摂取許容量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事での摂取許容量を超える料理については、除外又はグレイアウト表示された上で個別メニューに含まれる。これにより、食事制限のあるユーザは、病気を悪化させる特定の栄養成分を多く含む料理を意識せずに或いはそのような栄養成分を多く含む料理を容易に確認でき、料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取目標量を示す情報を含み、前記今回の食事での摂取目標量を示す情報は、所定期間における摂取目標量から前記所定期間における過去の食事での累積摂取量を引いた量以上を示し、前記個別メニューは、前記１以上の料理の中で、前記今回の食事での摂取目標量未満の前記特定の栄養成分を含む一の料理を除外又はグレイアウトさせて生成されてもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間における摂取目標量から所定期間における過去の食事での累積摂取量を引いた量以上を示す情報が、今回の食事での摂取目標量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事での摂取目標量未満の料理については、除外又はグレイアウト表示された上で個別メニューに含まれる。これにより、食事制限のあるユーザは、病気を改善させる特定の栄養成分が不足する料理を意識せずに或いはそのような栄養成分が不足する料理を容易に確認でき、料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に対応する今回の食事でのカロリーの摂取許容量を示す情報を含み、前記今回の食事でのカロリーの摂取許容量を示す情報は、所定期間におけるカロリーの摂取許容量から前記所定期間における過去の食事でのカロリーの累積摂取量を引いた量以下を示し、前記個別メニューは、前記１以上の料理において、前記今回の食事でのカロリーの摂取許容量を超える料理を除外又はグレイアウトさせて生成されてもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間におけるカロリーの摂取許容量から所定期間における過去の食事でのカロリーの累積摂取量を引いた量以下を示す情報が、今回の食事でのカロリーの摂取許容量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事でのカロリーの摂取許容量を超える料理については、除外又はグレイアウト表示された上で個別メニューに含まれる。これにより、食事制限のあるユーザは、カロリーの摂取量が摂取許容量を超える料理を意識せずに或いはそのような料理を容易に確認でき、料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、前記個別メニューは、前記１以上の料理の中で、前記今回の食事での摂取許容量を超える前記特定の栄養成分を含む一の料理において、前記特定の栄養成分と同時に摂取することで前記摂取許容量を超える前記特定の栄養成分による悪影響を中和させる効果がある栄養成分を含む食材を追加したものを含んでもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間における摂取許容量から所定期間における過去の食事での累積摂取量を引いた量以下を示す情報が、今回の食事での摂取許容量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事での摂取許容量を超える料理については、特定の栄養成分による悪影響を中和させる効果がある栄養成分を含む食材が追加される。これにより、食事制限のあるユーザは、病気に関わる特定の栄養成分による悪影響を中和させる食材を意識せずに料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、前記個別メニューは、前記今回の食事での摂取許容量を超える前記特定の栄養成分を含む料理と、前記特定の栄養成分と同時に摂取することで前記摂取許容量を超える前記特定の栄養成分による悪影響を中和させる効果がある栄養成分を含む料理との組み合わせを示す表示を含んでもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間における摂取許容量から所定期間における過去の食事での累積摂取量を引いた量以下を示す情報が、今回の食事での摂取許容量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事での摂取許容量を超える料理については、特定の栄養成分による悪影響を中和させる効果がある栄養成分を含む料理の組み合わされた上で個別メニューに表示される。これにより、食事制限のあるユーザは、病気に関わる特定の栄養成分による悪影響を中和させる食材を意識せずに料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、前記個別メニューは、前記今回の食事での摂取許容量以下となる料理の組合せを示す表示を含んでもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間における摂取許容量から所定期間における過去の食事での累積摂取量を引いた量以下を示す情報が、今回の食事での摂取許容量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事での摂取許容量以下となる料理の組み合わせが個別メニューに表示される。これにより、食事制限のあるユーザは、病気を悪化させる特定の栄養成分の量を意識せずに、組み合わせに係る料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取目標量を示す情報を含み、前記今回の食事での摂取目標量を示す情報は、所定期間における摂取目標量から前記所定期間における過去の食事での累積摂取量を引いた量以上を示し、前記個別メニューは、前記今回の食事での摂取目標量以上となる料理の組合せを示す表示を含んでもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間における摂取目標量から所定期間における過去の食事での累積摂取量を引いた量以上を示す情報が、今回の食事での摂取目標量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事での摂取目標量以上となる料理の組み合わせが個別メニューに表示される。これにより、食事制限のあるユーザは、病気を改善させる特定の栄養成分の量を意識せずに、組み合わせに係る料理の注文をスムーズに行うことができる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気に対応する今回の食事でのカロリーの摂取許容量を示す情報を含み、前記今回の食事でのカロリーの摂取許容量を示す情報は、所定期間におけるカロリーの摂取許容量から前記所定期間における過去の食事でのカロリーの累積摂取量を引いた量以下を示し、前記個別メニューは、前記今回の食事でのカロリーの摂取許容量以下となる料理の組合せを示す表示を含んでもよい。

　本態様によれば、病気に関わる特定の栄養成分に関して、所定期間におけるカロリーの摂取許容量から所定期間における過去の食事での累積摂取量を引いた量以下を示す情報が、今回の食事でのカロリーの摂取許容量を示す情報として採用される。そして、特定の栄養成分に関し、今回の食事でのカロリーの摂取許容量以下となる料理の組み合わせが個別メニューに表示される。これにより、食事制限のあるユーザは、カロリーの摂取量を意識せずに、組み合わせに係る料理の注文をスムーズに行うことができる。

　上記制御方法において、前記個別メニューは、第１料理と、前記第１料理よりも優先度を下げて表示する第２料理とを含み、前記第２料理に含まれる前記ユーザの病気に関わる摂取が制限される栄養成分の量は、前記第１料理に含まれる前記ユーザの病気に関わる前記摂取が制限される栄養成分の量よりも多くてもよい。

　本態様によれば、摂取が制限される栄養成分を多く含む料理ほど優先度を下げて個別メニューに表示されるため、ユーザは病気の改善効果の高い料理を容易に確認できる。

　上記制御方法において、前記個別メニューは、第１料理と、前記第１料理よりも優先度を下げて表示する第２料理とを含み、前記第２料理に含まれる前記ユーザの病気に関わる摂取が推奨される栄養成分の量は、前記第１料理に含まれる前記ユーザの病気に関わる前記摂取が推奨される栄養成分の量よりも少なくてもよい。

　本態様によれば、摂取が推奨される栄養成分を多く含む料理ほど優先度を上げて個別メニューに表示されるため、ユーザは病気の改善効果の高い料理を容易に確認できる。

　上記制御方法において、前記優先度を下げて表示することには、前記第２料理の表示順序を前記第１料理の表示順序よりも下位にすること、前記第２料理の表示サイズを前記第１料理の表示サイズよりも小さくすること、又は前記第２料理の表示の濃さを前記第１料理の表示の濃さよりも薄くすること、の少なくともいずれか１つを含んでもよい。

　本態様によれば、優先度が低い料理ほど表示順序が下位にされる、優先度が低い料理ほど表示サイズが小さくされる、或いは優先度が低い料理ほど薄く表示されるため、ユーザは病気の改善効果の高い料理を容易に確認できる。

　上記制御方法において、前記食事制限の程度を示す情報は、前記ユーザの病気の進行に対応して逐次更新されてもよい。

　本態様によれば、食事制限の程度を示す情報はユーザの病気の進行に対応して逐次更新されるため、病気の進行度合いに応じて適切な食事制限の程度を示す情報を生成できる。その結果、ユーザの病気の進行度合いに応じて適切な料理を含む個別メニューを表示できる。

　上記制御方法において、前記食事制限の程度を示す情報は、健康診断の結果の取得、診断時のカルテ情報の取得、又は前記ユーザの生体情報を検知する生体センサーによる前記ユーザの生体情報の取得、の少なくともいずれか１つに基づいて、逐次更新されてもよい。

　本態様によれば、健康診断の結果、診断時のカルテ情報、及びユーザの生体情報の少なくとも１つの取得に基づいて食事制限の程度を示す情報が更新されるため、これらの最新の情報を踏まえてユーザにとって適切な食事制限の程度を示す情報を生成できる。

　上記制御方法において、さらに、前記個別メニューにて選択された料理の料理名を示す情報、前記個別メニューにて選択された料理の価格を示す情報、前記個別メニューにて選択された料理が注文された日時を示す情報、及び前記個別メニューにて選択された料理に含まれる栄養成分を示す情報、を前記第１サーバに送信してもよい。

　個別メニューにてユーザにより選択された料理に関して、料理名を示す情報、価格を示す情報、注文日時を示す情報、栄養成分を示す情報が第１サーバに送信されるため、第１サーバは、ユーザの食事履歴を取得できる。

　上記制御方法において、前記識別情報は、ユーザＩＤを含んでもよい。

　本態様によれば、識別情報にはユーザＩＤが含まれるため、第１サーバからユーザに対応する生体情報を確実に取得できる。

　上記制御方法において、前記第１サーバは、前記第２サーバと異なっていてもよい。

　第１サーバにはユーザの生体情報というようなユーザのセンシティブな情報が記憶されている。このようなセンシティブな情報はユーザの許諾なしに第１サーバの外部に提供されることは好ましくない。本態様では、第１サーバは第２サーバとは異なるサーバで構成されている。そのため、ユーザのセンシティブな情報が第１サーバの外部に漏洩することが防止される。

　上記制御方法において、前記レストランＩＤ及び前記席ＩＤは、前記第１操作画面を介して、前記ユーザが着席したテーブルの対応位置に用意された識別コードを読み取ることで、取得されてもよい。

　本態様によれば、レストランＩＤ及び席ＩＤは、ユーザが着席したテーブルの対応位置に用意された識別コードを読み取ることで取得される。これにより、レストランＩＤ及び席ＩＤをユーザに手入力させずに取得できる。

　上記制御方法において、前記識別コードは、ＱＲコードを含んでもよい。

　本態様によれば、識別コードがＱＲコードであるため、この情報をユーザに手入力させることなく取得できる。

　上記制御方法において、前記識別コードは、ＮＦＣ（Ｎｅａｒ　Ｆｉｅｌｄ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を用いて読み取られたものであってもよい。

　本態様によれば、識別コードはＮＦＣを用いて読み取られるため、この情報をユーザに手入力させることなく取得できる。

　上記制御方法において、前記第１サーバは、生体情報、前記ユーザの物品の購買履歴情報又は料理の注文履歴情報を含む嗜好情報、及び前記ユーザの位置情報を含む行動履歴情報を分散管理してもよい。

　本態様によれば、第１サーバは、生体情報、ユーザの物品の購買履歴情報又は料理の注文履歴情報を含む嗜好情報、及び前記ユーザの位置情報を含む行動履歴情報を分散管理する。そのため、本態様は、これらの個人情報が外部に漏洩することを防止できる。

　上記制御方法は情報端末において実行されてもよい。上記制御方法は情報端末のコンピュータにおいて実行されるプログラム又はそのプログラムを記録する記録媒体であってもよい。

　これらの構成によれば、上述の制御方法を実行する情報端末、プログラム及びそのプログラムを記録する記録媒体を提供できる。

　上記プログラムにおいて、前記ユーザを特定する識別情報は、前記プログラムに付与された情報端末毎のシリアルコードを含んでもよい。

　この構成によれば、プログラムに付与された情報端末毎のシリアルコードが採用されるため、秘匿性がより高められた情報で識別情報を構成できる。

　本開示の別の一態様に係る制御方法は、ユーザを特定する識別情報に対応させて前記ユーザの生体情報を管理する第１サーバと通信し、一のレストランに対応する１以上の料理を示すメニュー情報を格納する第２サーバを含む健康管理システムにおける情報提供方法であって、前記ユーザの情報端末からネットワークを介して前記ユーザの座席を示す席ＩＤを取得し、前記席ＩＤは、前記情報端末のディスプレイに表示される操作画面を介して取得されたものであり、前記情報端末に格納された前記識別情報を前記情報端末からネットワークを介して取得し、前記第１サーバから、ネットワークを介して前記ユーザの生体情報を取得し、前記ユーザの生体情報に基づき、前記ユーザの病気の進行による食事制限の程度を示す情報を生成し、前記メニュー情報及び前記食事制限の程度を示す情報に基づいて、前記食事制限の程度を示す情報に対応した前記ユーザの個別メニューを生成し、前記個別メニューを前記情報端末に送信し、前記情報端末において前記個別メニューに基づき料理を選択される。

　上記の態様によると、料理を注文するに際して、ユーザの情報端末のディスプレイに表示された操作画面を介してユーザの座席を示す席ＩＤが取得されると共に、ユーザの情報端末に記憶されたユーザを特定するための識別情報がネットワークを介して取得される。さらに、第１サーバからユーザの生体情報がネットワークを介して取得され、取得された生体情報及び第２サーバが記憶するメニュー情報に基づいて、ユーザの病気の進行による食事制限の程度を示す情報に対応したユーザの個別メニューが生成される。この個別メニューは情報端末に送信され、この個別メニューの中から料理が選択される。

　このように、本態様では、ユーザが料理を注文する一連の過程の中で、健康管理システムにおいて、一のレストランにおいてユーザの座席を示す席ＩＤが取得されると共に、個別メニューを通じて料理が選択される。この個別メニューは、食事制限の程度を示す情報に対応している。そのため、注文料理情報とユーザの座席との対応付けが人手を介することなく自動的に行われる。これにより、例えば、食事制限が課されるユーザの座席に、当該ユーザと同一テーブルに別のユーザが注文した料理であって、食事制限に対応していない料理が配膳される配膳ミスを防止できる。その結果、食事制限が課されるユーザに不快感を与えることを防止できる。さらに、このような配膳ミスが防止されるため、食事制限が課されるユーザが間違えて配膳された料理を食したことにより、当該ユーザの健康を害することを防止できる。

　（実施の形態）
　我々の社会は、今後もさらにインターネットが普及し、各種センサーが身近になることが予想される。これにより、我々の社会は、個人の状態及び活動等に関する情報から建造物及び交通網等を含む街全体の情報までもが、デジタル化されてコンピューターシステムで利用できる状態になっていくと予想される。デジタル化された個人に関するデータ（個人情報）は、通信ネットワークを介してクラウドに蓄積され、ビッグデータとして情報銀行に管理され、個人のために様々な用途に利用されていく。

　このような高度情報化社会は、日本ではＳｏｃｉｅｔｙ５．０と呼ばれる。高度情報化社会は、現実空間（フィジカル空間）と仮想空間（サイバー空間）とを高度に融合させた情報基盤（サイバーフィジカルシステム）により、経済発展と社会的課題の解決とが期待される社会である。

　そうした高度情報化社会では、個人が日常の様々なシーンで意思決定を行う際に、蓄積された個人情報を含むビッグデータを分析して、その時の状況に応じた、その個人にとって最適と思われる選択肢を、その個人が知ることが可能になる。

　以降では、そのようなサイバーフィジカルシステムが稼働する高度情報化社会において、個人の食事をテーマとして、経済効率化と個人最適化（パーソナライゼーション）とを実施する様態について説明していく。

　個人最適化された料理の注文システムの一例としては、レストランの店舗端末から個人の情報端末にメニュー情報を送信し、食事制限のあるユーザが避けるべき食材を含んでいない料理からなるメニューを推奨メニューとして携帯端末上に提示するものが考えられる。まず、上述の高度情報化社会が提案される以前の社会において構築されることが予想される一般的な料理の注文システムを説明する。

　図１は、一般的な料理の注文システムの構成を示す図である。注文システムは、店舗端末１１００及び携帯端末１２００を含む。店舗端末１１００及び携帯端末１２００は、レストランの店舗１０００内に設置されている。店舗端末１１００は、メニュー情報を発信するコンピュータである。店舗端末１１００は、外部機器との通信を行うための通信部、演算処理を行うための演算部、データを記憶するためのメモリ、情報を表示及び操作するためのＵＩ部を含む。メモリはメニュー情報１１０１を記憶する。メニュー情報１１０１にはレストランが提供する料理に関する情報が含まれている。具体的には、メニュー情報１１０１には、料理の名前、料理に使用される材料、及び料理の価格が含まれている。図１の例では、メニュー情報１１０１には、エビハンバーグ、シーフードパスタ、シーフードカレー、及びほうれん草のグラタンの４つの料理が含まれている。

　携帯端末１２００は、店舗１０００を訪れたユーザが保有するスマートフォン等の携帯端末である。携帯端末１２００は、外部機器との通信を行うための通信部、演算処理を行うための演算部、データを記億するためのメモリ、情報を表示及び操作するためのＵＩ部を含む。メモリは、携帯端末１２００を保有するユーザの病気情報及び食事履歴情報等を記憶する。

　ユーザが店舗１０００に入店すると、店舗端末１１００と携帯端末１２００とは自動又は手動で通信を開始する。通信を開始した携帯端末１２００は店舗端末１１００からメニュー情報１１０１を取得する。メニュー情報１１０１を取得した携帯端末１２００はメニュー情報とメモリに記憶された病気情報及び食事履歴情報とを照合し、ユーザが避けるべき食材を含まない料理を抽出する。携帯端末１２００は、抽出した料理に基づいて推奨メニュー１２１１を生成し、ＵＩ部に表示する。図１の例では、ユーザの避けるべき食材が牛肉であるため、牛肉を含まない料理であるほうれん草のグラタンが推奨メニュー１２１１として表示されている。

　上記の構成によると、ユーザは表示された推奨メニューから、避けるべき食材の入っていない料理を選択することができる。

　Ｓｏｃｉｅｔｙ５．０では、病気情報及び食事履歴情報のような個人情報は、情報銀行と称される個人情報を管理する事業者のサーバによって第三者に個人が特定されないように秘匿化された上で一元管理される。この個人情報は末端のユーザの手入力に依存することなく、情報銀行の管理の下、随時更新される。

　しかしながら、図１に示す注文システムでは、病気情報及び食事履歴情報は携帯端末１２００で管理されており、サーバで管理されていない。そのため、図１に示す注文システムは、病気情報及び食事履歴情報を更新することが容易ではない。例えば、病気情報及び食事履歴情報を更新するには、ユーザは病気情報及び食事履歴情報を携帯端末１２００に手入力させることが要求され、ユーザにとって手間である。さらに、病気情報及び食事履歴情報は秘匿化されていないため、店舗端末１１００に病気情報及び食事履歴情報が漏洩する可能性もある。そのため、図１に示す注文システムをＳｏｃｉｅｔｙ５．０が標榜する高度情報化社会に適合させるためには、更なる改善が必要である。そこで、本実施の形態では、Ｓｏｃｉｅｔｙ５．０を踏まえた情報処理システムを提案する。以下、本開示の実施の形態に係る情報処理システムを、図面を参照しながら説明する。

　図２は、本開示の情報処理システムの情報基盤の全体像の一例を示す図である。図２の情報処理システムは、Ｓｏｃｉｅｔｙ５．０を踏まえて構成されたシステムであり、個人情報を利用して一消費者であるユーザに適した商品又はサービスをユーザに提案し、商品又はサービスのユーザによる選択を支援する選択支援サービスを提供するシステムである。本実施の形態では選択支援サービスとして料理の注文を支援するサービスを主眼としているが、このサービスを説明する前に、図２を用いて本実施の形態を実現するための情報基盤の全体像を説明する。この情報処理システムは大きく３つの機器群から構成される。

　１つ目の機器群はユーザが保有するスマートフォン等の情報端末１００を含む機器群である。情報端末１００にはマッチングアプリケーションがインストールされている。マッチングアプリケーション（以下、マッチングアプリと称する。）は、ユーザに適した商品又はサービスを、そのユーザの個人情報を用いて選別又は推薦するためのアプリケーションである。ここで言う個人情報とは、個人に関する公開又は非公開の情報が広く包含される。例えば、個人情報は、氏名、生年月日、住所、年収、所有する動産／不動産情報、身長／体重等の身体情報、遺伝子情報、病歴／診断カルテ等の医療情報、歩数／消費カロリーなどの活動量情報、食事履歴情報、心拍／血圧等のバイタルサイン情報、店舗／ＥＣサイトなどを介した購買情報、Ｗｅｂ検索エンジン／ＡＩスピーカーで検索した単語情報、メール／ＳＮＳで送受信された文章／映像音声情報、並びに移動履歴情報等のうちの少なくとも一つを含む。情報端末１００は、例えば、４Ｇ、５Ｇと称される移動体通信網により携帯基地局４００を介して、インターネットに接続可能である。

　２つ目の機器群は第１サーバ２００を含む機器群である。第１サーバ２００は、ユーザの個人情報を複数箇所に分散し、分散した個人情報をさらに暗号化して記憶する個人情報サーバである。例えば、第１サーバ２００は、クラウド上にある複数のストレージ装置にユーザの個人情報を断片化及び暗号化して記憶することで個人情報を管理する。これにより、高いセキュリティが確保され、個人情報の漏洩等が防止される。さらに、第１サーバ２００は、第三者からの問い合わせに応じて必要なデータをユーザ本人の許諾に応じて返信する機能を持つ。さらに、第１サーバ２００は、ユーザが許諾した事業者に対してユーザが許諾した個人情報をセキュアに共有する機能を持つ。すなわち、第１サーバ２００は情報銀行としての機能を持つ。この場合、第１サーバ２００は、例えば１つのデータを複数のストレージ装置に分散して記録する。１つのデータの一例は個人情報を記録した１つのファイルである。

　本実施の形態では、第１サーバ２００は、ユーザの許諾に基づき、特定の事業者に対して特定の個人情報を共有させる。さらに、第１サーバ２００は、以下で説明する選択支援サービスを提供するための機能を持つ。

　上述のマッチングアプリは、例えば第１サーバ２００の運営会社によって開発及び／または配布される。この運営会社はユーザが利用する可能性のある商品又はサービスに対するユーザの適合度合いを、ユーザの個人情報を用いて評価する。第１サーバ２００の運営会社、マッチングアプリの開発会社、及びマッチングアプリの配布会社は、それぞれ同一であってもよいし、異なっていてもよい。図２に示す情報処理システムは、上述したマッチングアプリを用いて選択支援サービスを実現するが、これは一例である。例えば、マッチングアプリ以外のアプリ又は一般的なブラウザ等を用いて選択支援サービスを実現してもよい。ユーザの個人情報をセキュアに扱うためには、マッチングアプリ等の専用のアプリによって選択支援サービスを提供することが好ましい。但し、これは一例であり、例えば公開されている個人情報などのセキュリティの重要度が低い個人情報を扱う場合、又はセキュリティを確保するための機能が提供される場合は、マッチングアプリ以外の手段で選択支援サービスが提供されてもよい。

　マッチングアプリは、情報端末１００の内部でのみ個人情報を取り扱う。例えば、マッチングアプリは、時間、場所、及び状況等の任意の条件下において、ユーザに最も適すると思われる商品又はサービスをユーザに提示する。例えば、マッチングアプリは、ユーザの購買等の経済活動における仲介斡旋機能を提供する。

　マッチングアプリは、これまでサービス事業者ごとにサイロ化されていたリコメンド機能をオープンに開放したアプリである。例えば、ＥＣサイト等の電子商取引市場で有名なある１つのサービス事業者の例で説明する。当該サービス事業者のサイトには数多くの商品が掲載されている。特定の商品が検索又は購入されると、その商品と関連性が高い他の商品（例えば、よく一緒に購入される商品）がユーザに推薦される。このような購買に対するリコメンド機能は、当該サービス事業者のＥＣサイトの中でしか有効にならない。したがって、当該リコメンド機能は、他のサービス事業者が運営するＥＣサイトにおいて商品を購入する時、レストランで食事を注文する時、又は休暇の家族旅行を計画する時において、何ら効果を発揮しない。

　今後、情報銀行に個人情報が集約され、膨大かつ多種多様で長期間に渡る正確な個人情報が所定の条件下で誰でもアクセスできる仕組みが整うことが予想されている。この場合、ある１つのサービス事業者のＥＣサイトにおける検索又は購入履歴、及び様々なユーザの個人情報を用いて、当該サービス事業者の商品だけなく、あらゆる商品又はサービスを対象として適合度合いを推定することが可能となる。これにより、様々な選択肢の中からユーザにとってより価値の高い商品又はサービスを推薦することが可能となる。

　本実施の形態が想定する第１サーバ２００は、上記のような思想又は機能を実現するために、個人情報を分散化及び暗号化して管理するクラウド上に設けられた汎用のストレージ装置である。

　３つ目の機器群は、各事業者が各事業者固有のデータを管理する第２サーバ３００を含む機器群である。図２では事業者Ｘ、事業者Ｙ、事業者Ｚの３社がそれぞれ第２サーバ３００を所有又はレンタルし、自社の商品及び／又は自社のサービスに関する情報を管理及び／又は提供している。事業者は、本開示で詳細に述べる外食事業者だけに限定されない。例えば、事業者は、お弁当屋又はファストフード店のように調理済み料理のテイクアウトが可能な中食事業者であってもよい。さらに、事業者は、スーパーマーケットのように自宅で調理することを主眼においた内食向けの事業者であってもよい。さらに、事業者は、自動車メーカ、不動産会社、病院、学校、勉強又はスポーツなどの塾、弁護士事務所、並びに一般消費者に対して商品及び／又はサービスを提供する事業者であってもよい。

　本実施の形態の情報処理システムの効果の１つとしては、個人情報が事業者に渡らないことが挙げられる。情報銀行では本人許諾に基づき、特定の事業者に対して個人情報の共有を許可することが想定されている。

　しかしながら、この運用を個々にユーザに判断させるのはとても面倒である。データ運用ポリシーを定める信託業者がいても、具体的にどのデータが誰に渡ったのかをユーザは把握できず、ユーザは不安に感じる可能性がある。

　そこで、本実施の形態は、第１サーバ２００を運営している事業者が、保管している個人情報を利用すること、例えば、暗号を解き解釈することを、ユーザの許諾が無い限り、禁止又は制限する。

　さらに、プライバシーに厳密な運営ポリシーの下で、個人情報の管理及びマッチングアプリを提供する情報銀行又は情報仲介業者が市場に参入している場合、ユーザは当該情報銀行又は情報仲介業者との間でそのサービスの提供を受ける契約を結んでもよい。これにより、個人情報が他の事業者に渡らないようにすることが可能となる。

　本実施の形態の情報処理システムは、本人以外の第三者にセンシティブな情報を含む個人情報が知られる可能性を低減し、時々刻々と変化する膨大な個人情報を様々なサービスとのマッチングのために利用することができる次世代情報社会の運用システムの一形態である。以降、この想定の下で情報処理システムが説明される。

　図３は、本実施の形態の情報処理システムの全体像をより詳しく示す図である。図３に示す情報処理システムは、外食時にユーザが料理を注文するために閲覧するメニュー情報を、そのユーザの個人情報とマッチングさせ、そのユーザにとって最適なメニューを提示するシステムである。図３に示す情報処理システムは、図２に示す情報処理システムに対してさらに生体センサー６００及び医療機関情報サーバ５００を含んでいる。

　サービス提供側の事業者としては、外食産業の会社であるレストランＡ社、レストランＢ社、レストランＣ社が想定されている。レストランＡ社，Ｂ社，Ｃ社は、それぞれ別会社である。図３に示す情報処理システムは、レストランＡ社が運用する第２サーバ３００、レストランＢ社が運用する第２サーバ３００、レストランＣ社が運用する第２サーバ３００を含む。各レストランのメニュー情報及び各店舗に関する情報はこれらの第２サーバ３００によって管理されている。第２サーバ３００は例えばクラウドサーバで構成される。

　医療機関情報サーバ５００は、病院及び診療所等の医療機関によって管理されるサーバである。医療機関情報サーバ５００は、ユーザの定期健康診断の診断結果を示す情報及び病院における診断書を示す情報等を管理する。医療機関情報サーバ５００はインターネットに接続されている。医療機関情報サーバ５００によって管理される情報はマッチングにおいて必要があれば、適宜利用される。

　生体センサー６００は、生体情報を取得するためのセンサーである。取得される生体情報としては、例えば、心拍、血圧、血中酸素濃度、血糖（グルコース）、ＨｂＡｌｃ、呼吸、体温、水分量、摂取カロリー、加速度、歩数、活動量／消費カロリー、嗅覚、筋電、脳波、睡眠状態、生体インピーダンス、及び尿内塩分等が挙げられる。これらの生体情報が可能な生体センサーは既に実用化されている。

　例えば、摂取カロリー及び消費カロリーは、複数のセンサーの組み合わせ、たとえば、加速度センサーで取得された加速度、心拍センサーで取得された心拍数、及び血糖値センサーで取得された血糖値から推定可能である。

　例えば、痛風又は糖尿病など、総摂取カロリー量が制約されるユーザについては、生体センサー６００からの取得値からユーザのリアルタイムな摂取カロリーが推定可能である。これにより、当該ユーザに対して、食事を制限（これ以上、食べるのをやめさせたり）、低カロリー料理を勧めたりすることが可能である。

　血糖値又はＨｂＡ１ｃは、皮下の間質液の糖濃度をリアルタイムに測定するセンサーを用いて測定可能である。或いは、または、血糖値又はＨｂＡ１ｃは、ユーザの指先等から少量の血液を採血するセンサーを用いて測定可能である。または、ＨｂＡ１ｃは薬局又は駅等に設置されているＨｂＡ１ｃ測定器により測定可能である。

　尿内塩分は、尿内塩分センサーにより取得可能である。尿内塩分センサーは、早朝の尿の塩分濃度を測定することで、前日の塩分摂取量を測ることが可能である。尿内塩分は、高血圧症又は糖尿病等の塩分摂取量が制約されるユーザについて測定される。

　臭覚センサーは皮膚から出るわずかなアルコールを検出することで、ユーザが飲酒したか否かを検知可能である。アルコールの検出は、痛風患者等のアルコールを避ける食事制約が課されるユーザに適用される。

　生体センサー６００から取得されたデータ、または取得されたデータの組み合わせにより推定された血圧、摂取カロリー量、摂取塩分量、又は血糖値等を示す情報は、生体情報として第１サーバ２００に逐次アップロードされて蓄積される。アップロードされた生体情報は、食事又は運動等のユーザの生活習慣改善に利用される。

　生体センサー６００は、スマートウォッチで構成されていてもよい。生体センサー６００は、情報端末１００を所有するユーザにより装着されていてもよい。生体センサー６００は、継続的にユーザの生体情報を計測する。生体センサー６００が計測した生体情報は、Ｂｌｕｅｔｏｏｔｈ（登録商標）のような近距離無線通信によって、生体センサー６００から情報端末１００に送信される。生体情報は、情報端末１００にインストールされたセンサーアプリによって、保管及び／又は管理される。センサーアプリは、収集した生体情報と生体情報の測定時刻を示す時刻情報とを、ユーザアカウント情報にしたがって第１サーバ２００へアップロードする。これにより生体情報が第１サーバ２００に蓄積される。

　センサーアプリは、保管及び／又は管理するデータに対するアクセス権をマッチングアプリ又は情報端末１００のＯＳ（Ｏｐｅｒａｔｉｎｇ　ｓｙｓｔｅｍ）に付与してもよい。この場合、生体情報はマッチングアプリ又はＯＳを介して、第１サーバ２００へアップロードされる。センサーアプリは、生体情報を、情報端末１００のメモリに保管してもよい。

　図４は、本実施の形態に係る情報処理システムの具体的な構成の一例を示す図である。図４に示す情報処理システムは、図２及び図３で説明した情報端末１００、第１サーバ２００、第２サーバ３００、及び生体センサー６００を含む。なお、図４においては、携帯基地局４００、及び医療機関情報サーバ５００の図示は説明の便宜上省かれている。情報端末１００、第１サーバ２００、第２サーバ３００、及び生体センサー６００はネットワークＮＴを介して相互に通信可能に接続されている。ネットワークＮＴは携帯電話通信網及びインターネットを含む広域通信網である。

　情報端末１００は、スマートフォン又はタブレット端末等の携帯型の情報処理装置で構成されている。本実施の形態において、情報端末１００は、レストランの店舗で料理を注文するユーザによって携帯される。情報端末１００は、通信部１０１、メモリ１０２、カメラ１０３、演算部１０４、ディスプレイ１０５、操作部１０６、及び近接通信部１０７を含む。

　通信部１０１は、情報端末１００をネットワークＮＴに接続する通信回路で構成されている。通信部１０１は、第２サーバ３００から送信された後述するメニュー情報を受信して、メモリ１０２に記憶させる。演算部１０４はメモリ１０２に記憶されたメニュー情報を読み出し処理を行う。また、通信部１０１は、第１サーバ２００から送信された後述する生体情報及び／又は病気情報を受信して、メモリ１０２に記憶させる。さらに、通信部１０１は、演算部１０４の制御の下、後述する注文料理情報及び後述する席ＩＤを対応付けて第２サーバ３００に送信する。

　メモリ１０２は、フラッシュメモリ等の不揮発性のストレージ装置で構成されている。メモリ１０２は、図２５に例示される定期健康診断の診断結果を含む情報２５００と、図２６及び図２７に例示される病気診断書の記載内容を含む情報２６００とを記憶する。情報２５００及び情報２６００は、第１サーバ２００から送信される病気情報を構成する。さらに、メモリ１０２は、第１サーバ２００から送信された図２７に示す生体情報を含む情報２７００を記憶する。さらに、メモリ１０２は、図２８に示す、第２サーバ３００から送信された食材情報２８００を記憶する。

　１つの食材情報２８００は１つの料理に対応しており、料理に使用される食材に関する情報である。メニュー情報は１以上の食材情報２８００によって構成される。情報２５００、情報２６００、情報２７００、及び食材情報２８００の詳細は後述する。さらに、メモリ１０２はユーザを特定する識別情報を記憶する。識別情報はユーザＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）が含まれる。ユーザＩＤはユーザの識別子である。

　カメラ１０３は、ＣＭＯＳセンサー等で構成される撮像装置である。カメラ１０３は、レストランの店舗の座席に取り付けられたＱＲコードを撮影するため等に用いられる。

　演算部１０４は、ＣＰＵ等のプロセッサで構成されている。演算部１０４は、情報端末１００のＯＳ、上述のマッチングアプリ、ＱＲコードリーダー、及びブラウザ等を実行する。

　演算部１０４は、ディスプレイ１０５に表示される第１操作画面を介して、レストランＩＤ及びユーザの座席を示す席ＩＤを取得する。第１操作画面は例えば図１５に示すようにマッチングアプリが提供するＱＲコードを読み取るための操作画面Ｇ１０４或いは図１６に示すようにＮＦＣにより情報を読み取るための操作画面Ｇ１０１１である。レストランＩＤは、レストランの識別子である。レストランが複数の店舗を持つ場合、レストランＩＤにはレストランの識別子と店舗の識別子とが含まれてもよい。席ＩＤは店舗に配置された座席の識別子である。演算部１０４は、ユーザが操作部１０６に対して撮影指示を入力した時にカメラ１０３が撮影したＱＲコードを解析することでレストランＩＤ及び席ＩＤを取得してもよい。或いは、演算部１０４は、マッチングアプリの起動中に、情報端末１００がレストランの各座席に配置されたＮＦＣのＩＣチップに近接された場合、近接通信部１０７を介してＩＣチップからレストランＩＤ及び席ＩＤを取得してもよい。

　演算部１０４は、レストランＩＤに対応するレストランの第２サーバ３００からネットワークＮＴを介してレストランが提供する１以上の料理を示すメニュー情報を取得し、メモリ１０２に記憶する。例えば、レストランＩＤがレストランＡ社の識別子を含む場合、レストランＡ社の第２サーバ３００からメニュー情報が取得される。

　演算部１０４は、メモリ１０２に記憶されたユーザを特定するための識別情報を第１サーバ２００に送信し、識別情報に基づき、第１サーバ２００からユーザの生体情報及び／又は病気情報を取得し、メモリ１０２に記憶する。

　演算部１０４は、取得したメニュー情報並びに取得したユーザの生体情報及び／又は病気情報に基づき、ユーザの病気の進行による食事制限の程度を示す情報を生成する。

　演算部１０４は、生成した食事制限の程度を示す情報に対応したユーザの個別メニューを生成する。個別メニューには、例えば演算部１０４が取得したメニュー情報に含まれる各料理において、食事制限の程度を示す情報が示すユーザが避けるべき食材を減少させた料理が含まれる。これにより、ユーザは避けるべき食材を含まない料理をスムーズに注文できる。

　演算部１０４は、ディスプレイ１０５に表示された、レストランにおける料理の注文を受け付けるための第２操作画面を介して、個別メニューを表示する。第２操作画面は、例えば図１８に示すようにレストランがユーザから料理の注文を受け付けるための操作画面Ｇ１０６であり、レストランのデザイン指定に基づき、マッチングアプリを介して提供される。ユーザはこの第２操作画面に表示された個別メニューの中から希望の料理を選択する操作を入力し、料理を注文する。

　演算部１０４は、個別メニューにて選択された料理を示す注文料理情報及び席ＩＤを対応付けて通信部１０１を介して第２サーバ３００に送信する。第２サーバ３００に送信された注文料理情報及び席ＩＤは、送信先の第２サーバ３００に対応するレストランの店舗に設置されたディスプレイに表示される。この店舗の従業員は表示された内容にしたがってユーザが注文した料理を調理し、ユーザの座席に運ぶ。これにより、ユーザは注文した料理を食することができる。

　ディスプレイ１０５は、例えば液晶表示パネルまたは有機ＥＬパネル等で構成され、種々の画像を表示する。例えば、ディスプレイ１０５は、上述の第１操作画面及び第２操作画面を表示する。

　操作部１０６は、例えばタッチパネル等の入力装置で構成される。操作部１０６は、個別メニューの中からユーザが希望する料理を選択する指示を受け付ける。

　近接通信部１０７は、ＮＦＣの通信機能を備える通信回路を含み、ＮＦＣの通信機能を有するＩＣチップから情報を読み込んだり、当該ＩＣチップに情報を書き込んだりすることができる。さらに、近接通信部１０７は、Ｂｌｕｅｔｏｏｔｈ（登録商標）の通信機能を備える通信回路を含み、生体センサー６００と通信する。

　以上が情報端末１００の構成である。

　次に、第１サーバ２００の構成について説明する。第１サーバ２００は、通信部２０１、演算部２０２、及びメモリ２０３を含む。通信部２０１は、第１サーバ２００をネットワークＮＴに接続するための通信回路で構成されている。通信部２０１は、情報端末１００からの要求に応じて情報端末１００に対して生体情報及び／又は病気情報を送信する。演算部２０２はＣＰＵ等のプロセッサで構成されている。演算部２０２は、メモリ２０３が記憶するユーザの個人情報を処理する。

　メモリ２０３は、ハードディスクドライブ等の不揮発性の複数のストレージ装置で構成されている。メモリ２０３は、１以上のユーザの個人情報を記憶する。個人情報には各ユーザの生体情報及び／又は病気情報が含まれる。個人情報は、複数のストレージ装置において分散化及び暗号化された上で記憶される。

　メモリ２０３が記憶する個人情報には、生体情報と、嗜好情報と、行動履歴情報とが含まれていてもよい。生体情報は、上述したように生体センサー６００によって取得された各ユーザの生体情報である。嗜好情報は購買履歴情報及び／又は注文履歴情報を含む。購買履歴情報は、各ユーザの商品（物品）又はサービスの購買履歴を示す情報である。注文履歴情報は、各ユーザの料理の注文履歴を示す情報である。行動履歴情報は、各ユーザの行動履歴を示す情報である。行動履歴情報は、例えば、ユーザの位置情報と時刻情報とが対応付けられた時系列データで構成される。

　次に、第２サーバ３００の構成について説明する。第２サーバ３００は、各レストラン会社に対応して１又は複数存在する。第２サーバ３００は、通信部３０１、演算部３０２、及びメモリ３０３を含む。通信部３０１は第２サーバ３００をネットワークＮＴに接続するための通信回路で構成される。通信部３０１は、情報端末１００からの要求に応じてメニュー情報を情報端末１００に送信する。演算部３０２は、ＣＰＵ等のプロセッサで構成される。演算部３０２は、メモリ３０３が記憶するメニュー情報を処理する。メモリ３０３はハードディスクドライブ等の不揮発性のストレージ装置で構成されている。メモリ３０３は、メニュー情報を記憶する。

　次に、生体センサー６００の構成について説明する。生体センサー６００は、通信部６０７、メモリ６０２、センサー部６０３、演算部６０４、ディスプレイ６０５、及び操作部６０６を含む。通信部６０７は、生体センサー６００を情報端末１００の近接通信部１０７と近距離無線通信によって通信させるための通信回路で構成されている。近距離無線通信としては、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）が採用できる。通信部６０７は、センサー部６０３が測定した生体情報を近距離無線通信を用いて情報端末１００に送信する。

　メモリ６０２は、フラッシュメモリ等の書き換え可能な不揮発性のメモリで構成され、例えばセンサー部６０３が計測した生体情報を記憶する。センサー部６０３は、血圧センサー、加速度センサー、心拍センサー、生体インピーダンスセンサー、血糖値センサー、及び尿内塩分濃度センサー、生体ガスセンサー、赤外線センサー、中赤外線レーザーセンサー、臭いセンサー、圧電センサー（ピエゾセンサー）等で構成される。

　演算部６０４は、ＣＰＵ等のプロセッサで構成され、生体センサー６００の全体制御を司る。ディスプレイ６０５は、例えば液晶パネル、有機ＥＬパネルで構成され、センサー部６０３が測定した生体情報等を表示する。操作部６０６は、ユーザからの種々の操作を受け付ける。

　図５は、レストランのある店舗のレイアウトを示した図である。図５の例ではレストランＡ社の店舗４０のレイアウトが示されている。店舗４０には４つのテーブル４１０が設置されている。各テーブル４１０には４つの椅子４１１，４１２，４１３，４１４が設置されている。

　１つのテーブル４１０に２名以上のユーザが着席した場合において、これらのユーザの中に食事制限のあるユーザが含まれていることがある。この場合、食事制限のないユーザが注文した料理が間違って食事制限のあるユーザに配膳されることは避けなければならい。これは、食事制限のあるユーザが避けるべき食材が含まれている料理が間違って食事制限のあるユーザに配膳されると、当該ユーザに不快感を与える可能性があるからである。さらに、食事制限のあるユーザが間違って配膳された料理を食すると、食事制限のあるユーザの病気の改善が阻害され、当該ユーザの健康を害する可能性があるからである。

　このような間違いを避けるためには、ユーザとそのユーザが注文した料理とを対応づける適切な仕組みが必要である。しかしながら、現在そのような間違いを避けるためのソリューションは限定的であった。特に、図５に示すような一般的なレストランの店舗に適用可能なソリューションは存在していない。現在、１席１席ごとに番号が付けられたカウンターが設置された小規模店舗において、このような対応付けが試みられているが、この対応付けは、注文伝票又は注文入力端末を用いて人為的に行われているため、配膳の間違いを解消するには不十分である。

　本実施の形態は、ユーザとそのユーザが注文した料理とをより確実に対応付けて管理するための仕組みを提供する。以下、この仕組みを実現するための具体例について説明する。本実施の形態では、店舗４０の各座席にＱＲコードを設置する。図６Ａ，図６Ｂ，図６Ｃ，図６Ｄは、座席に対するＱＲコード６０１の設置例を示す図である。図６Ａの例では、ＱＲコード６０１は店舗の各椅子の背もたれ部の上面に配置されている。ＱＲコード６０１には、上述したようにレストランＩＤ及び各座席の席ＩＤが含まれている。ここでは、ＱＲコードが用いられているが、これは一例でありバーコード等、レストランＩＤ及び席ＩＤが識別可能な情報であればどのような情報が採用されてもよい。

　図６Ｂの例では、ＱＲコード６０１は、各椅子の座部の側面に配置されている。ＱＲコード６０１を座部の側面に配置することで、ＱＲコード６０１を読み取らせる際のユーザの操作が容易となる。

　図６Ｃの例では、ＱＲコード６０１は、椅子ではなくテーブルの側面（例えば、椅子に向いた面）に配置されている。この例ではテーブルは４人用であるため、テーブルの側面には各座席に対応する４つのＱＲコード６０１が配置されている。

　図６Ｄの例では、ＱＲコード６０１は、テーブルの天板の上面に配置されている。この例ではテーブルは４人用であるため、天板の上面には各座席に対応する４つのＱＲコード６０１が配置されている。天板の上面にＱＲコード６０１を配置することで、ＱＲコード６０１の存在をユーザに容易に気づかせることができる。

　座席毎に準備されたＱＲコードは、料理を注文したユーザの情報端末１００が、店舗のメニュー情報を取得するために利用される。以下、順を追ってＱＲコードと情報端末１００とを使った料理の注文方法について詳細に説明する。本実施の形態において、料理の注文は、標準メニューから行うケースと、個別メニューから行うケースとがある。

　なお、図６Ａ～図６Ｄでは、各座席にはＱＲコード６０１が配置されているが、ＮＦＣによってレストランＩＤ及び席ＩＤを取得する態様が採用される場合、ＱＲコード６０１に代えて、ＮＦＣの通信機能を有するＩＣチップが採用される。

　（標準メニューからの注文）
　標準メニューは、食事制限のないユーザが料理を注文する場合に用いられる。標準メニューは、ユーザが店舗で提供される一般的な料理を含むメニューである。以下、標準メニューにより料理が注文される処理を、情報端末１００に表示される各種画面を用いて説明する。

　この標準メニューからの注文処理は、図３１のフローチャートに相当しているため、以下の説明では、適宜図３１のフローチャートが参照される。まず、ＱＲコードリーダーが起動され、ＱＲコードリーダーが、ユーザが着席した座席に対応するＱＲコードを読み取る。この処理は図３２のステップＳ１１に相当する。

　図７は、ユーザがＱＲコードを情報端末１００に読み取らせる場合に情報端末１００に表示される操作画面Ｇ１の一例を示す図である。操作画面Ｇ１は、レストランの店舗に入店して着席したユーザが、着席した座席（自席）に対応するＱＲコードを情報端末１００に読み取らせるシーンにて表示される。自席に対応するＱＲコードは、図６Ａ～図６Ｄに示す何れかの様態で配置されている。着席したユーザは、情報端末１００を取り出し、レストランの店舗の標準メニューを取得するために、自席に対応するＱＲコードを情報端末１００に読み取らせる。ＱＲコードの読み取りは情報端末１００に予めインストールされた「ＱＲコードリーダー」という汎用のＱＲコード読み取りアプリを用いて実現される。図７では、自席に対応するＱＲコードに情報端末１００のピントを合わせる操作をユーザが行っている最中の操作画面Ｇ１が表されている。ユーザはＱＲコードリーダーのガイド線７０１（図中の破線四角）内にＱＲコード６０１が収まるように、情報端末１００の向き及び位置を調整する。座席ごとに配置されたＱＲコード６０１の近くには、ユーザ又は店舗のスタッフが座席を特定するための情報である「席番号１８」と、このＱＲコード６０１の用途の説明（図中では「パーソナルマッチング用ＱＲコード」）も配置されている。そのため、操作画面Ｇ１には、「席番号１８」を示す画像と、「パーソナルマッチング用ＱＲコード」を示す画像も表示されている。

　次に、ＱＲコードリーダーが読み取ったＱＲコードからレストランＡ社のメニュー情報が取得され、メニュー情報に基づいて標準メニューが生成され、情報端末１００に表示される。

　この処理は図３１のステップＳ１２に相当する。図８は、ＱＲコードリーダーがＱＲコードを読み取った直後の情報端末１００に表示される操作画面Ｇ２の一例を示す図である。この操作画面Ｇ２には、ＱＲコードリーダーによる読み取りが成功されたＱＲコードの読み取り結果である文字列が表示されている。この例では、「ｈｔｔｐ：／／ｒｅｓｔａｕｒａｎｔＡ．ｃｏｍ／ＱＲｏｒｄｅｒ－１８」という文字列がＱＲコードの読取結果として得られている。操作画面Ｇ２には、「ブラウザで開く」と記載されたボタン８０１と、「メールを送る」と記載されたボタン８０２とが含まれている。ボタン８０１は、ＱＲコードの読み取り結果である文字列がＵＲＬであるとユーザが解釈した場合に選択されるボタンである。ボタン８０１がタッチされると、インターネットのブラウザが起動し、このＵＲＬで示されるウェブページが情報端末１００に表示される。

　ボタン８０２は、ＱＲコードの読み取り結果である文字列がメールアドレスであるとユーザが解釈した場合に選択されるボタンである。ボタン８０２がタッチされると、メールアプリが起動される。ここでは、標準メニューを閲覧するためにボタン８０１がタッチされている。

　この標準メニューからの料理を注文するに際して、特定のアプリを情報端末１００にインストールする必要はなく、ＱＲコードリーダー及びブラウザがあれば足りる。そのため、標準メニューを用いた料理の注文は多数のユーザによって容易に行われる。

　ブラウザは、ＱＲコードリーダーが読み取った文字列（例えば、ＵＲＬ）に含まれる接続先情報（例えば、ドメイン名、ｒｅｓｔａｕｒａｎｔＡ．ｃｏｍの部分）から接続先がレストランＡ社であること、すなわちレストランＩＤを特定できる。第２サーバ３００は、リクエストされたＵＲＬの末尾の数字が１８であるため、このリクエストが席番号「１８」の座席のＱＲコードを読み込んだ情報端末１００のブラウザからのリクエストであることを特定できる。図８に示す文字列には、店舗４０の店舗ＩＤは含まれていないが、明示的に店舗４０（Ｓｔｏｒｅ－Ａ）が含まれてもよい。この場合は、ＱＲコードが意味する文字列は、例えば、「ｈｔｔｐ：／／ｒｅｓｔａｕｒａｎｔＡ．ｃｏｍ／Ｓｔｏｒｅ－Ａ／ＱＲｏｒｄｅｒ－１８」のように表現される。情報端末１００のブラウザは、このようにしてリクエストする接続先情報を取得する。

　図９は、レストランＡ社の標準メニューを含む操作画面Ｇ３の一例を示す図である。この操作画面Ｇ３は、メニュー情報が情報端末１００によって受信された場合に表示される。標準メニューには、メニュー情報に含まれる料理がそのまま含まれており、ユーザの食事制限の程度を示す情報には対応していない。メニュー情報は個別メニューを生成する際に使用されるメニュー情報と同じ情報であってもよいし、異なる情報であってもよい。

　この操作画面Ｇ３には、複数のタイルオブジェクト９０１がマトリックス状に配置されている。標準メニューはこれら複数のタイルオブジェクト９０１によって構成される。１つのタイルオブジェクト９０１は標準メニューに含まれる１つの料理に対応している。各タイルオブジェクト９０１には、料理の料理名、料理の価格、及び料理の画像が含まれている。操作画面Ｇ３において標準メニューはユーザのスクロール操作に応じてスクロールする。これにより、操作画面Ｇ３内で一度に表示仕切れなかった他の料理が表示される。このように、ユーザは、スクロール操作をすることで、標準メニューに含まれる全ての料理を閲覧できる。

　操作画面Ｇ３は、ＱＲコードの読み取り結果である文字列が示すＵＲＬ（例えば、ｈｔｔｐ：／／ｒｅｓｔａｕｒａｎｔＡ．ｃｏｍ／ＱＲｏｒｄｅｒ－１８）にブラウザが接続し、ブラウザがレストランＡ社の第２サーバ３００からメニュー情報を受信することで表示される。

　例えば、情報端末１００のブラウザは上記ＵＲＬに接続し、レストランＡ社の標準メニューを描画するためのＨＴＭＬファイルをＨＴＴＰリクエストし、レストランＡ社の第２サーバ３００からＨＴＴＰレスポンスを受信し、受信したＨＴＴＰレスポンスに従って標準メニューを含む操作画面Ｇ３を描画する。但し、この実装形態は一例であり、操作画面Ｇ３の描画は、他の技術手段で実現されてもよい。

　次に、表示された標準メニューからユーザにより料理が選択される。この処理は図３１のステップＳ１３に相当する。

　図１０は、ユーザが操作画面Ｇ３を操作して標準メニューから料理を注文するシーンの一例を示した図である。この図のように、ユーザは指等の指示体１００１を用いたタッチ操作で注文する料理を決定できる。例えば、情報端末１００は、「ラーメンＢセット」の料理に対応するタイルオブジェクト９０１Ａが１回タッチされたことを検知すると、タイルオブジェクト９０１Ａの色をデフォルトの第１色から選択されたことを示す第２色に変更する。このとき、情報端末１００は、「ラーメンＢセット」の注文数を示す「１」をタイルオブジェクト９０１Ａの例えば右上に表示する。以上より、この例では標準メニューの中から、「ラーメンＢセット」の料理が選択されていることが分かる。ユーザは、各料理に対応するタイルオブジェクト９０１をタッチすることで料理を注文できるため、慣れた操作感覚で料理の注文を直感的且つ簡単に行うことができる。

　尚、ここではユーザが注文する料理を選択した際にタイルオブジェクト９０１の色を変更するとしたが、これに限らない。例えば、ユーザにより選択された際に、タイルオブジェクト９０１の模様を第１模様から、第２模様に変更してもよい。または、ユーザにより選択された際に、タイルオブジェクト９０１の色及び模様を第１の色及び模様から、第２の色及び模様に変更してもよい。

　図１１は、標準メニューから注文する料理を最終的に決定する際に表示される操作画面Ｇ４の一例を示す図である。操作画面Ｇ４は、操作画面Ｇ３において、注文する料理を決定したユーザにより注文ボタン（図９に図示せず）がタッチされた場合に表示される。操作画面Ｇ４には、操作画面Ｇ３で選択された料理に対応するタイルオブジェクト９０１Ａと、注文した料理の合計金額（例えば、１，１００円）を示す合計金額欄１０１１と、注文を最終的に決定する注文ボタン１０１２とが含まれている。このように、操作画面Ｇ４には、注文する料理の一覧と、各料理の数量と、注文する料理の合計金額とが表示されているため、ユーザは１画面で効率的に注文内容を確認できる。注文内容に問題がないことを確認したユーザは操作画面Ｇ４の下部にある注文ボタン１０１２をタッチする。これにより、料理の注文が確定する。さらに、注文ボタンには席番号「１８」が記載されているため、ユーザは自身の座席に配膳されることを確認した上で料理を注文できる。注文ボタン１０１２がタッチされると、情報端末１００は、ＱＲコードから読み取った席ＩＤ（図１１の例では席番号「１８」）と、選択された料理を示す注文料理情報とを対応付けた注文リクエストを、レストランＡ社の第２サーバ３００に送信する。以上により、標準メニューにおける注文処理が完了する。この処理は、図３１のステップＳ１４に相当する。

　一般向けである標準メニューからの注文処理は、上記の説明のように実施される。この注文処理では、料理を注文するユーザは、情報端末１００にＱＲコードを読み取らせ、ブラウザによりレストランＡ社の標準メニューを表示させ、この標準メニューを通じて料理を注文できる。そのため、レストランＡ社が配布するような特定のアプリを情報端末１００に事前にインストールする手間が省かれる。よって、ユーザは情報端末１００を用いてすぐにこのサービスを利用でき、このサービスはより多くのユーザにより利用される。また、ユーザは、標準メニューを通じて好きな料理を直感的な操作で簡単に選択して注文することができる。さらに、操作画面Ｇ３は、ピンチ操作によってズーム倍率が調節可能である。そのため、老眼のユーザでも操作メニューに含まれる料理を容易に確認できる。さらに、ユーザは、操作画面Ｇ３を縮小表示することによって、より多くの情報を同時に閲覧できる。さらに、注文リクエストは、注文料理情報と席ＩＤ（例えば席番号「１８」）とが対応付けられたＨＴＴＰリクエストであるため、レストランＡ社の第２サーバ３００は、このＨＴＴＰリクエストを通じて席番号「１８」のユーザが注文した料理を認識し、認識した席番号「１８」と注文した料理とを店舗内のディスプレイに表示することができる。

　これにより、レストランの従業員は席番号「１８」に注文された料理を間違わずに配膳することができる。さらに、標準メニューは紙媒体ではないため、レストランＡ社は、紙媒体からなる標準メニューを採用した場合に必要となる標準メニューの更新又は管理に要する手間を省くことができる。その結果、注文を取るための人的リソース及び注文を間違って受け付けるクレームリスクが低減され、コストダウン及び経営の効率化が図られる。

　（個別メニューからの注文）
　次に、個別メニューからの料理の注文について説明する。標準メニューはレストランが提供する一般向けのメニューであるが、個別メニューは食事制限のあるユーザの食事制限の程度を示す情報に対応した料理を含むメニューである。この個別メニューから料理を注文する処理は、後述する図３２のフローチャートによって示される。以下、図３２のフローチャートを適宜参照しながら、個別メニューから料理を注文する処理について説明する。

　個別メニューによる料理の注文は、マッチングアプリの起動をトリガーに開始される。図１２は、料理を注文するユーザがマッチングアプリを起動した直後に情報端末１００に表示される認証画面Ｇ１０１の一例を示す図である。認証画面Ｇ１０１は、指紋認証によりユーザ認証を行うための画面である。認証画面Ｇ１０１には、中央に指紋を模式的に示す指紋画像１２０１が表示され、指紋画像１２０１の下部には「指紋認証してください」とのメッセージが表示されている。これらにより、認証画面Ｇ１０１は、ユーザに対して指紋認証を行うよう促している。認証画面Ｇ１０１の上部には「パーソナルマッチング」と記載されている。これにより、認証画面Ｇ１０１はマッチングアプリの画面であることをユーザに確認させることができる。このことは、後述する図１３～図１７においても同じである。

　図１３は、認証画面Ｇ１０２の他の一例を示す図である。認証画面Ｇ１０２は、顔認証によりユーザ認証を行うための画面の一例である。認証画面Ｇ１０２には、情報端末１００がユーザの正面からの顔の画像を適当なサイズで捉えられるよう、中央に顔の輪郭を模式的に示す点線１３０１が表示されている。ユーザは点線１３０１に収まるように自身の正面からの顔が表示されるように情報端末１００の向き及び位置を調整する。

　上記のユーザ認証の方法に比べて必要な認証精度をより少ないユーザの負担で実現できるユーザ認証の方法があれば、その方法が採用されてもよい。ユーザ認証の方法としては、一般的にセキュリティ強度が高いと言われる２段階認証が採用されてもよいし、ユーザＩＤとパスワードとを入力する方法が採用されてもよい。

　図１４は、マッチングアプリによるユーザ認証が終わった直後に表示されるホーム画面Ｇ１０３の一例を示す図である。ホーム画面Ｇ１０３には、上段にアプリ名称「パーソナルマッチング」が表示され、中段に複数のタイルオブジェクト１４０１がマトリックス状に表示されている。各タイルオブジェクト１４０１には、マッチングアプリが取り込んだ連携機能又は別アプリが対応付けられている。別アプリは、例えば、マッチングアプリ内で起動するアプリである。この例では、ａ、ｂ、ｃ、ｄ、ｅと記載された５つのタイルオブジェクト１４０１が表示されている。これらのタイルオブジェクト１４０１には、マッチングアプリに連携して自社商品又は自社サービスのマッチングを行う専用機能（例えば、マッチングアプリ内のアプリ）が対応付けられている。これにより、ユーザは、ａ、ｂ、ｃ、ｄ、ｅで示される５種類の連携機能が利用可能である。グレイアウトされたタイルオブジェクト１４０１は、連携機能がインストールされていない空きのタイルオブジェクトである。ホーム画面の下段には、左よりスキャンボタン１４０２、マップボタン１４０３、アカウントボタン１４０４、及びホームボタン１４０５が表示されている。こら４つのボタンは固定ボタンである。スキャンボタン１４０２は、上述したレストラン等の事業者が提供するサービスに連携したＱＲコード等を読み取る場合に使用されるボタンである。マップボタン１４０３は、情報端末１００の現在地の周辺にあるマッチングアプリ対応店舗を地図画面を用いて表示させるボタンである。アカウントボタン１４０４は、ユーザのアカウント情報を登録及び編集するためのボタンである。アカウント情報の登録及び編集には、例えば、個人認証の設定及び第１サーバ２００との連携機能の設定等が含まれる。ホームボタン１４０５は、画面表示をこの図に示されるホーム画面Ｇ１０３に戻すためのボタンである。

　ホーム画面Ｇ１０３では、連携機能、別アプリ、又は他の事業者のサービスと連携するためのタイルオブジェクト１４０１が中段に集約して配置されている。これらのタイルオブジェクト１４０１はユーザの好みに応じて、表示の有無及び配置する場所が設定可能である。よって、ユーザは、１つのマッチングアプリを用いて、数多くの事業者（例えば、家電量販店、ＤＶＤ／Ｂｌｕ－ｒａｙ（登録商標）レンタル店、本屋、コーヒーショップ、タクシー等）が提供する商品又はサービスのうち、個人情報をもとにそのユーザに適合する商品及び／又はサービスを取得できる。

　図１５は、マッチングアプリを起動したユーザが自席に対応するＱＲコードを情報端末１００に読み取らせる場合に情報端末１００に表示される操作画面Ｇ１０４の一例を示す図である。操作画面Ｇ１０４（第１操作画面の一例）は、図７の操作画面Ｇ１とほぼ同様である。操作画面Ｇ１０４では上段にアプリの名称表示が「パーソナルマッチング」である点が操作画面Ｇ１と相違する。

　マッチングアプリは、ＱＲコードから読み取った文字列（例えば、ＵＲＬ）の接続先情報（例えば、ドメイン名、ｒｅｓｔａｕｒａｎｔＡ．ｃｏｍ）から接続先がレストランＡ社であることを特定できる。このリクエストを受信した第２サーバ３００は、マッチングアプリからリクエストされたＵＲＬの末尾の番号が「１８」であることから、このリクエストが席番号「１８」の座席のＱＲコードを読み取った情報端末１００から送信されたリクエストであることを識別できる。本実施の形態は、レストランＡ社の店舗４０に対して、店舗４０の席番号「１８」に着席したユーザが料理を注文することを例示する。このリクエストにおいてマッチングアプリは明示的に店舗４０（Ｓｔｏｒｅ－Ａ）を指定してもよい。この場合、ＱＲコードが意味する文字列は、例えば、ｈｔｔｐ：／／ｒｅｓｔａｕｒａｎｔＡ．ｃｏｍ／Ｓｔｏｒｅ－Ａ／ＱＲｏｒｄｅｒ－１８と設定される。マッチングアプリは、このようにして接続先を特定する情報（例えば、レストランＩＤ）を取得できる。

　以上、説明したマッチングアプリを起動し、ユーザ認証を行い、ＱＲコードを読み取る処理は、図３２のステップＳ１に対応する。

　ＱＲコードに代えてＮＦＣによりレストランＩＤ及び席ＩＤが取得される態様が採用される場合、以下の第１操作画面が用いられる。図１６は、ＮＦＣによりレストランＩＤ及び席ＩＤを取得する場合に情報端末１００に表示される操作画面Ｇ１０１１の一例を示す図である。この操作画面Ｇ１０１１も操作画面Ｇ１０４と同様、ホーム画面Ｇ１０３においてスキャンボタン１４０２がタッチされた場合に表示される。

　操作画面Ｇ１０１１には、上部に「パーソナルマッチング」と表示され、この画面がマッチングアプリの画面であることが示されている。画面の中央には、ＮＦＣをシンボリックに表すＮＦＣマーク１６０１と、情報端末１００をＮＦＣマーク１６０１が付された物体へ近接させることを促すメッセージ（例えば「ＮＦＣマークに近づけてください」）が表示されている。

　ＮＦＣによりレストランＩＤ及び席ＩＤが取得される場合、レストランの各座席には、レストランＩＤ及び席ＩＤを記憶するメモリと、ＮＦＣの通信機能とを有するＩＣチップが配置されている。このＩＣチップにはＮＦＣマーク１６０１が表示されていてもよい。これにより、操作画面Ｇ１０１１でＮＦＣマーク１６０１を確認したユーザは情報端末１００を自身の座席に配置されたＩＣチップに近接させればよいことを容易に確認できる。ＩＣチップのメモリは、上述のＱＲコードで説明したように、レストランＩＤ及び席ＩＤが特定可能なレストランのＵＲＬを記憶すればよい。

　次に、マッチングアプリがレストランＡ社の第２サーバ３００へアクセスし、メニュー情報を取得する処理を説明する。この処理は、図３２のステップＳ２に対応する。

　図１７は、マッチングアプリが個別メニューを生成している際に情報端末１００に表示される表示画面Ｇ１０５の一例を示す図である。表示画面Ｇ１０５では、円形状の矢印オブジェクト１５０１が回転表示される。さらに、矢印オブジェクト１５０１の下側には、「レストランＡのメニューとマッチングしています」と表示されている。これにより、マッチングアプリが処理中であることをユーザは認識できる。

　表示画面Ｇ１０５の表示中において、情報端末１００のマッチングアプリはレストランＡ社の第２サーバ３００と第１サーバ２００と連携して個別メニューを生成する。具体的には、マッチングアプリは、ＱＲコード６０１又はＮＦＣで読み取ったＵＲＬに基づいてレストランＡ社の第２サーバ３００にアクセスして、メニュー情報を取得する。メニュー情報を取得したマッチングアプリは、メニュー情報のデータ属性を検出する。メニュー情報は食に関する情報であるため、ここで検出されるデータ属性は食属性となる。

　メニュー情報は、例えばＨＴＭＬファイルである。メニュー情報には、例えば、データ属性が食属性であることが、所定のフォーマットで記述されている。マッチングアプリはこのフォーマットに基づいて、メニュー情報のデータ属性が食属性であることを検出すればよい。或いは、マッチングアプリは、例えば、ＱＲコードが示すＵＲＬのドメイン名からメニュー情報のデータ属性が食属性であることを検出してもよい。ここでは、ドメイン名「ｒｅｓｔａｕｒａｎｔＡ．ｃｏｍ」がレストランＡ社を示すため、メニュー情報のデータ属性が食属性であると判断される。或いは、マッチングアプリは、取得したメニュー情報を解析し、食に関するデータであるとの解析結果が得られた場合、メニュー情報のデータ属性が食属性であると判定してもよい。或いは、マッチングアプリは、第２サーバ３００からメニュー情報のデータ属性を示す補足情報を取得することで、メニュー情報のデータ属性が食属性であることを検出してもよい。メニュー情報のデータ属性を検出する実装形態は、データ属性が識別できる手法であれば他の手法が採用されてもよい。

　次に、マッチングアプリが第２サーバ３００から、病気情報及び／又は生体情報を取得する処理を説明する。この処理は、図３２のステップＳ３に対応する。

　メニュー情報のデータ属性が食属性であると判断したマッチングアプリは、食属性に分類される最新の病気情報及び／又は生体情報の取得を第１サーバ２００に要求する。この要求には、ユーザＩＤが含まれる。この要求を受信した第１サーバ２００は、分散暗号化された個人情報の中から最新の病気情報及び／又は生体情報をユーザＩＤに基づいて抽出する。抽出された病気情報及び／又は生体情報は、第１サーバ２００から情報端末１００へ送信される。これにより、マッチングアプリは、病気情報及び／又は生体情報を取得する。

　情報端末１００は、取得した病気情報及び／又は生体情報に基づいてユーザの食事制限の程度を示す情報を生成する。食事制限の程度を示す情報を生成した情報端末１００は、レストランＡ社のメニュー情報と食事制限の程度を示す情報とを照合し、個別メニューを生成する処理を実行する。この処理は図３２のステップＳ４に対応する。このとき、情報端末１００には依然、図１７に示す表示画面Ｇ１０５が表示されているが、マッチングアプリは、メニュー情報と食事制限の程度を示す情報とを照合し、食事の制限の程度を示す情報に対応する個別メニューを生成する処理を実行している。

　ここで、生成される個別メニューは、以下のバリエーションがある。

　１つ目のバリエーションでは、演算部１０４は、メニュー情報及び食事の制限の程度を示す情報に基づき、メニュー情報に含まれる各料理において食事の制限の程度を示す情報が示すユーザが避けるべき食材を含む料理を減少させて生成された料理を含む個別メニューを生成する。

　例えば、痛風に罹患したユーザにおいては、エビ又はレバー等のプリン体を含む食材が避けるべき食材となる。この場合、プリン体を含む食材を含む料理がメニュー情報に含まれていれば、その料理についてプリン体を含む食材の量が摂取許容量未満に減少される。避けるべき食材を減少させることには、その食材をゼロにすることが含まれる。例えば、痛風に罹患したユーザにおいては、メニュー情報において、エビ又はレバー等のプリン体を含む食材を含む料理があれば、その料理は当該食材がゼロにされる。

　なお、食材情報２８００には、各料理に含まれる食材の量が含まれているため、演算部１０４は、各料理についてユーザが避けるべき食材があるか否か及び避けるべき食材の量を特定することが可能となる。そして、食材情報２８００において避けるべき食材を摂取許容量未満にする又はゼロに変更した上で個別メニューを生成すればよい。

　２つ目のバリエーションでは、演算部１０４は、メニュー情報及び食事制限の程度を示す情報に基づき、メニュー情報に含まれる各料理において食事制限の程度を示す情報が示すユーザが避けるべき食材を含む料理を除外またはグレイアウトさせて個別メニューを生成する。

　例えば、ユーザの避けるべき食材がエビであり、メニュー情報にエビハンバーグが含まれていたとする。この場合、エビハンバーグを示すタイルオブジェクト９０１が個別メニューから除外される、或いはグレイアウトされる。グレイアウトとは、エビハンバーグのタイルオブジェクト９０１を例えばグレイ色で半透明表示させる表示方法である。

　３つ目のバリエーションでは、演算部１０４は、ユーザの病気の進行に対応する不足しやすい栄養成分を含む食材を追加した一の料理を含む個別メニューを生成する。例えば、演算部１０４は、病気情報及び／又は生体情報からユーザの病気の進行に対応する不足しやすい栄養成分を特定し、その栄養成分を含む食材を含む料理を個別メニューに追加すればよい。例えば、あるユーザについて、生体情報及び／又は病気情報から不足しがちな栄養成分として食物繊維が特定されたとする。この場合、食物繊維を多く含む料理（例えば、納豆）が個別メニューに追加される。この一例としては、図４４で後述するように、個別メニューにおいてユーザがある料理を選択すると、その料理に加えて不足しやすい栄養成分を含む料理の注文をユーザに促す画面をディスプレイ１０５に表示することが挙げられる。この場合、演算部１０４は、料理ごとに予め定められた不足しやすい栄養成分を含む料理を、ユーザに注文を促す料理として決定すればよい。

　４つ目のバリエーションでは、演算部１０４は、ユーザの病気の進行に対応する不足しやすい栄養成分を補うための料理の組合せを示す表示を含む個別メニューを生成する。例えば、３つ目のバリエーションと同様、病気情報及び／又は生体情報からユーザの病気の進行に対応する不足しやすい栄養成分として食物繊維が特定されたとする。この場合、例えば納豆を含むセット料理が個別メニューに含まれる。

　５つ目のバリエーションでは、演算部１０４は、所定期間におけるユーザの過去の食事において、ユーザにとって不足していた栄養成分を含む食材を追加した一の料理を含む個別メニューを生成する。所定期間とは、１日、２日、５日、１週間、又は１か月等の期間である。例えば、演算部１０４は、所定期間における料理の注文履歴情報を第１サーバ２００から取得し、その注文履歴情報から該当するユーザにとって不足している栄養成分を特定すればよい。例えば、注文履歴情報には、ユーザが過去に注文した料理に関する情報が含まれている。料理に関する情報には、例えば料理名に加えて各料理に使用される食材及びその量が含まれる。食材及び食材の量が分かれば、食材に含まれる各栄養成分及び各栄養成分の量も特定可能である。そこで、演算部１０４は、注文履歴情報に含まれる料理毎にユーザが摂取した栄養成分と各栄養成分の量とを特定し、特定した各栄養成分の量の所定期間における累計値を算出する。そして、演算部１０４は、その累積値が栄養成分毎に予め定められた閾値を下回るか否かを判定し、下回ると判定した栄養成分を不足する栄養成分として特定すればよい。例えば、食物繊維が不足していた栄養成分として特定されたとすると、食物繊維を多く含む料理（例えば、納豆）が個別メニューに追加される。

　６つ目のバリエーションでは、演算部１０４は、所定期間におけるユーザの過去の食事において、ユーザが不足していた栄養成分を補うための料理の組合せを含む個別メニューを生成する。所定期間は、５つ目のバリエーションと同じである。この場合、演算部１０４は、５つ目のバリエーションで説明した手法を用いて、不足していた栄養成分を特定すればよい。例えば、不足していた栄養成分として食物繊維が特定されたとすると、食物繊維を多く含む料理（例えば、納豆）を含むセット料理が個別メニューに含まれる。

　７つ目のバリエーションでは、食事制限の程度を示す情報は、ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含んでいる。そして、演算部１０４は、メニュー情報に含まれる１以上の料理の中で、今回の食事での摂取許容量を超える特定の栄養成分を含む一の料理において、特定の栄養成分の量を今回の食事での摂取許容量以下にした個別メニューを生成する。

　今回の食事での摂取許容量は、所定期間における摂取許容量から所定期間における過去の食事での累積摂取量を引いた量又は引いた量から所定のマージンを引いた値を示す。所定期間は、例えば、本日（０時から現在まで）、１日、２日、５日、１週間、１か月等の期間であり、特に限定はされない。このことは以下のバリエーションにおいても同じである。糖尿病患者は例えばアルコールが避けるべき食材として定められているため、特定の栄養成分としては、例えばアルコールが挙げられる。所定期間におけるアルコールの摂取許容量は、例えば、図３７で後述する式（１）を用いて算出可能である。所定期間における過去の食事でのアルコールの累積摂取量は、生体情報及び／又は料理注文履歴情報に基づいて算出可能である。演算部１０４は、メニュー情報に含まれる各料理のうち、アルコールの量が今回の食事での摂取許容量以上の料理については、アルコールの量を今回の食事での摂取許容量以下にする又はゼロになるようにその料理の食材情報２８００を変更した上で個別メニューを生成すればよい。

　８つ目のバリエーションでは、食事制限の程度を示す情報は、ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取目標量を示す情報を含んでいる。演算部１０４は、メニュー情報に含まれる１以上の料理の中で、今回の食事での摂取目標量未満の特定の栄養成分を含む一の料理において、特定の栄養成分の量を今回の食事での摂取目標量以上にした個別メニューを生成する。

　今回の食事での摂取目標量は、所定期間における摂取目標量から所定期間における過去の食事での累積摂取量を引いた量又は引いた量に所定のマージンを加えた値を示す。糖尿病患者は例えば食物繊維の摂取が推奨されているため、特定の栄養成分としては例えば食物繊維が挙げられる。所定期間における食物繊維の摂取目標量は、図３７で後述する式（１）を用いて算出可能である。所定期間における過去の食事での食物繊維の累積摂取量は、生体情報及び／又は料理注文履歴情報に基づいて算出可能である。演算部１０４は、メニュー情報に含まれる各料理のうち、食物繊維の量が今回の食事での摂取目標量未満の料理については、食物繊維の量を今回の食事での摂取目標量以上になるようにその料理の食材情報２８００を変更した上で個別メニューを生成すればよい。

　９つ目のバリエーションは、食事制限の程度を示す情報は、ユーザの病気に対応する今回の食事でのカロリーの摂取許容量を示す情報を含む。そして、演算部１０４は、１以上の料理の中で、今回の食事でのカロリーの摂取許容量を超えるカロリーを含む一の料理において、今回の食事でのカロリーの摂取許容量以下にした個別メニューを生成する。今回の食事でのカロリーの摂取許容量は、所定期間におけるカロリーの摂取許容量から所定期間における過去の食事でのカロリーの累積摂取量を引いた量又は引いた量から所定のマージンを差し引いた値を示す。所定期間におけるカロリーの摂取許容量は、図３７で後述する式（１）を用いて算出可能である。所定期間における過去の食事でのカロリーの累積摂取量は、生体情報及び／又は料理注文履歴情報に基づいて算出可能である。演算部１０４は、メニュー情報に含まれる各料理のうち、カロリーが今回の食事でのカロリーの摂取許容量以下の料理については、カロリーを今回の食事での摂取許容量以下になるようにその料理の食材情報２８００を変更した上で個別メニューを生成すればよい。

　１０個目のバリエーションは、７つ目のバリエーションにおいて、メニュー情報に含まれる１以上の料理において、今回の食事での摂取許容量を超える特定の栄養成分を含む一の料理を除外又はグレイアウトさせた個別メニューを生成するものである。例えば、演算部１０４は、メニュー情報に含まれる各料理のうち、アルコールの量が今回の食事での摂取許容量以上の料理については、その料理を除外又はグレイアウトさせた個別メニューを生成すればよい。除外又はグレイアウトは２つ目のバリエーションと同じである。

　１１個目のバリエーションは、８つ目のバリエーションにおいて、メニュー情報に含まれる１以上の料理において、今回の食事での摂取目標量未満の特定の栄養成分を含む一の料理を除外又はグレイアウトさせた個別メニューを生成するものである。演算部１０４は、メニュー情報に含まれる各料理のうち、例えば食物繊維の量が今回の食事での摂取目標量未満の料理については、その料理を除外又はグレイアウトさせた個別メニューを生成すればよい。

　１２個目のバリエーションは、９つ目のバリエーションにおいて、個別メニューに含まれる１以上の料理において、今回の食事でのカロリーの摂取許容量を超える料理を除外又はグレイアウトさせて個別メニューを生成するものである。演算部１０４は、メニュー情報に含まれる各料理のうち、例えばカロリーが今回の食事でのカロリーの摂取許容量以上の料理については、その料理を除外又はグレイアウトさせた個別メニューを生成すればよい。

　１３個目のバリエーションは、７つ目のバリエーションにおいて、メニュー情報に含まれる１以上の料理の中で、今回の食事での摂取許容量を超える特定の栄養成分を含む一の料理において、特定の栄養成分と同時に摂取することで摂取許容量を超える特定の栄養成分による悪影響を中和させる効果がある栄養成分を含む食材を追加した個別メニューを生成するものである。例えば、糖尿病患者は糖質の摂取量及びカロリーの摂取量が制限される。食物繊維はゆっくり噛んで食べることが要求されるため、噛んでいるうちに糖尿病患者に対して満腹感を与え、糖尿病患者のカロリーの摂取量を減少させたり、血糖値の急上昇を抑えたりする効果がある。したがって、特定の栄養成分としては食物繊維が挙げられる。食物繊維を多く含む料理は納豆、海藻等である。したがって、本バリエーションでは、例えば、メニュー情報に含まれる各料理のうち、例えば、糖質の量が今回の食事での摂取許容量以上の料理については、納豆及び海藻サラダといった料理が個別メニューに追加されることになる。

　１４個目のバリエーションは、７つ目のバリエーションにおいて、今回の食事での摂取許容量を超える特定の栄養成分を含む料理と、特定の栄養成分と同時に摂取することで摂取許容量を超える特定の栄養成分による悪影響を中和させる効果がある栄養成分を含む料理との組み合わせを示す表示を含む個別メニューを生成するものである。このバリエーションでは、例えば、１３個目のバリエーションで例示した納豆及び海藻サラダといった料理が、糖質の量が今回の食事での摂取許容量を超える料理に追加されたセット料理が個別メニューに含まれることになる。

　１５個目のバリエーションは、７つ目のバリエーションにおいて、今回の食事での摂取許容量以下となる料理の組合せを示す表示を含む個別メニューを生成するものである。このバリエーションでは、例えば、糖尿病患者においては、糖質の量の合計値が今回の食事での摂取許容量以下となる料理の組み合わせが個別メニューに含まれることになる。例えば、演算部１０４は、メニュー情報においてセット料理が含まれている場合、セット料理における糖質の量の合計値が今回の食事での摂取許容量以下となるセット料理を個別メニューに含ませればよい。或いは、演算部１０４は、糖質の量の合計値が今回の食事での摂取許容量以下となる料理の組み合わせをメニュー情報からピックアップし、ピックアップした料理の組み合わせをセット料理として個別メニューに含ませればよい。

　１６個目のバリエーションは、８つ目のバリエーションにおいて、今回の食事での摂取目標量以上となる料理の組合せを示す表示を個別メニューに含ませるものである。このバリエーションでは、例えば、糖尿病患者においては、食物繊維の量の合計値が今回の食事での摂取目標量以上となる料理の組み合わせが個別メニューに含まれることになる。例えば、演算部１０４は、メニュー情報においてセット料理が含まれている場合、セット料理における食物繊維の量の合計値が今回の食事での摂取目標量以上となるセット料理を個別メニューに含ませればよい。或いは、演算部１０４は、食物繊維の量の合計値が今回の食事での摂取目標量以上となる料理の組み合わせをメニュー情報からピックアップし、ピックアップした料理の組み合わせをセット料理として個別メニューに含ませればよい。

　１７個目のバリエーションは、９つ目のバリエーションにおいて、今回の食事でのカロリーの摂取許容量以下となる料理の組合せを示す表示を個別メニューに含ませるものである。このバリエーションでは、例えば、糖尿病患者においては、カロリーの合計値が今回の食事でのカロリーの摂取許容量以下となる料理の組み合わせが個別メニューに含まれることになる。例えば、演算部１０４は、メニュー情報においてセット料理が含まれている場合、セット料理におけるカロリーの量の合計値が今回の食事でのカロリーの摂取許容量以下となるセット料理を個別メニューに含ませればよい。或いは、演算部１０４は、カロリーの量の合計値が今回の食事でのカロリーの摂取許容量以下となる料理の組み合わせをメニュー情報からピックアップし、ピックアップした料理の組み合わせをセット料理として個別メニューに含ませればよい。

　これら、１７個のバリエーションは適宜組み合わされてもよい。

　個別メニューを生成したマッチングアプリは、個別メニューを標準メニューからの注文時と同じように、ブラウザを用いて、情報端末１００に表示する。個別メニューに掲載された料理は、全て最新の生体情報及び／又は病気情報が考慮された料理である。そのため、ユーザは料理の注文をスムーズに行うことができる。

　図１８は、個別メニューを含む操作画面の一例を示す図である。操作画面Ｇ１０６（第２操作画面の一例）は、操作画面Ｇ３と同様、複数のタイルオブジェクト９０１がマトリックス状に配置されている。操作画面Ｇ１０６において、個別メニューはユーザのスクロール操作に応じてスクロール可能に構成されている。これら複数のタイルオブジェクト９０１により個別メニューが構成される。操作画面Ｇ１０６の個別メニューにおいては、図９の標準メニューに含まれていた「ステーキセット」、「ラーメンＡセット」、「ラーメンＢセット」、「エビバーガー」、及び「ラーメンＣセット」等の料理を示すタイルオブジェクト９０１が、「減塩ラーメンと野菜餃子」、「ベジタブルカレーとウーロン茶」、「トマトソースパスタ」、「焼き魚定食」、及び「そば」等の料理を示すタイルオブジェクト９０１に変更されている。これは、ステーキセットはカロリーが高く、ラーメンＡセットは塩分及び糖質が多くカロリーも高く、ラーメンＢセットは塩分及び糖質が多くカロリーも高く、エビバーガーはプリン体が多く、ラーメンＣセットは、塩分及び糖質が多くアルコールも多く含まれているからである。これらの料理は標準メニューでは表示されるが、個別メニューでは優先度が下げられたり（つまり、個別メニューが初期表示された状態から、より多くのスクロール操作をしなければディスプレイ１０５に表示されない位置に表示されたり）、表示されなかったり、グレイレイアウト表示されて選択不可にされたりする。

　操作画面Ｇ１０６の上部には「レストランＡのカスタムメニュー」と表記されており、操作画面Ｇ１０６に掲載された個別メニューがユーザに対してカスタマイズされたメニューであることが明示されている。これにより、操作画面Ｇ１０６に含まれる個別メニューが安心して食べて貰える料理からなるメニューであることがユーザに訴求されている。

　操作画面Ｇ１０６において、タイルオブジェクト９０１の上部には、注文切替ボタン１８０１及び標準メニューボタン１８０２が表示されている。注文切替ボタン１８０１は、タイルオブジェクト９０１の選択後に図２０に示す操作画面Ｇ１０７に画面表示を切り替えるためのボタンである。標準メニューボタン１８０２は、個別メニューではなく標準メニュー（一般メニューの一例）に画面表示を切り替えるためのボタンである。例えば、食事制限のあるユーザの中には友人と食するときは食事制限をしないといった者も存在する。標準メニューボタン１８０２はこのようなユーザの要望に応えるために設けられている。標準メニューボタン１８０２がタッチされると、図９に示すような標準メニューを含む操作画面Ｇ１０６がディスプレイ１０５表示される。

　個別メニューを表示したマッチングアプリは、ユーザから注文する料理の選択を受け付ける処理を実行する。この処理は、図３２のステップＳ５に対応する。図１９は、ユーザが操作画面Ｇ１０６を操作して個別メニューから料理を注文するシーンを示した図である。

　この操作画面Ｇ１０６の例では、個別メニューから、「減塩ラーメンと野菜餃子」の料理のタイルオブジェクト９０１Ｂが１回タッチされている。そのため、タイルオブジェクト９０１Ｂの色が第１色から第２色に変更され且つ右上に注文数「１」が表示されている。このようにユーザは指等の指示体１００１を用いたタッチ操作で簡単且つ直感的に料理を注文できる。

　なお、ここではユーザが注文する料理を選択した際にタイルオブジェクト９０１の色を変更するとしたが、これに限らない。例えば、ユーザにより選択された際に、タイルオブジェクト９０１の模様を第１模様から、第２模様に変更してもよい。または、ユーザにより選択された際に、タイルオブジェクト９０１の色及び模様を第１色及び模様から、第２色及び模様に変更してもよい。

　操作画面Ｇ１０６を通じて料理の注文を受け付けたマッチングアプリは、注文料理情報と席ＩＤと対応付けた注文リクエストを第２サーバ３００に送信する。図２０は、個別メニューから注文する料理を最終的に決定する際に表示される操作画面Ｇ１０７の一例を示す図である。操作画面Ｇ１０７は、操作画面Ｇ１０６において、注文切替ボタン１８０１がタッチされた場合に表示される。

　操作画面Ｇ１０７には、操作画面Ｇ１０６で選択された料理に対応するタイルオブジェクト９０１Ｂと、注文した料理（減塩ラーメンと野菜餃子）の合計金額（１，０００円）を示す合計金額欄２００１とが含まれている。さらに、操作画面Ｇ１０７には、注文ボタン２０００が含まれている。この操作画面Ｇ１０７の内容は、標準メニューにおける操作画面Ｇ４と同じである。注文ボタン２０００がタッチされると、注文料理情報と席ＩＤとを対応付けた注文リクエストがレストランＡ社の第２サーバ３００に送信される。注文リクエストはレストランＡ社の店舗に設置されたディスプレイに表示される。これにより、レストランスタッフは、表示された席番号「１８」及び注文料理情報から注文内容を把握し、調理を開始し、注文された料理を席番号「１８」に配膳することができる。

　図２１は、これまでの注文履歴をユーザが確認する時に表示される注文履歴画面の一例を示す図である。注文履歴画面Ｇ１０８には、画面左側に設けられた調理中枠２１０１と画面右側に設けられた配膳済枠２１０２とを含む。調理中枠２１０１内には注文を受けて現在調理中である料理を示すタイルオブジェクト９０１Ｂが配列される。配膳済枠２１０２内には配膳済みの料理を示すタイルオブジェクト９０１が配列されている。図２０の例では未だ配膳された料理はないため、配膳済枠２１０２内にタイルオブジェクト９０１は配列されていない。現在、調理中枠２１０１には「減塩ラーメンと野菜餃子」のタイルオブジェクト９０１Ｂが配列されている。注文履歴画面Ｇ１０８において画面下段には、マッチングアプリを介して行われたこれまでの注文料理の合計金額（１，０００円）が分かり易く表示されている。ユーザは注文履歴画面Ｇ１０８を確認することで、現在までの注文した料理及び数量と支払金額とを一目で確認できる。なお、「注文履歴」ボタン（図略）を操作画面Ｇ１０６に設け、この「注文履歴」ボタンがタッチされたときに注文履歴画面Ｇ１０８が表示されてもよい。

　このレストランＡ社における個別メニューからの注文処理は、上記のように実施される。料理を注文するユーザは、第１サーバ２００が配信するマッチングアプリを使って、レストランの自席のＱＲコードを情報端末１００に読み取らせるだけで、自身の生体情報及び／又は病気情報が配慮された個別メニューを取得し、その個別メニューから料理を注文できる。これはこれまでに前例のない手軽で間違いのない個別の料理の注文方法である。これを実行するために、ユーザは予めマッチングアプリを情報端末１００にインストールしておけばよい。

　（食事制限について）
　図２２は、糖尿病患者に課される食事制限の一例を纏めた表である。まず、「食事のとり方」としてゆっくり、よく噛んで食べることが推奨される。これは、糖尿病患者にとって重要な血糖値の急上昇を抑えることができるとともに、噛んでいるうちに満腹感が得られ、カロリー及び糖質の摂取量が抑制されるからである。

　糖尿病患者は、摂取カロリー、塩分、アルコールについて一日の最大摂取量が制限される。

　一日の適正摂取カロリーは例えば下記のように算出される。

　適正摂取カロリー［Ｋｃａｌ／日］＝標準体重［Ｋｇ］＊活動量［Ｋｃａｌ／日／Ｋｇ］＝（身長［ｍ］＊身長［ｍ］＊２２）［Ｋｇ］＊活動量［Ｋｃａｌ／日／Ｋｇ］
　活動量は例えば下記のように設定される。

　活動量＝２５～３０（デスクワークの人など軽度の活動量）、又は３０～３５（立ち仕事が多い人など中度の活動量）、又は３５～（力仕事が多い人など高度の活動量）
　例えば、身長が１７１ｃｍ、デスクワークの職業従事者で軽度の活動量である日のユーザの適正摂取カロリーは、（１．７１＊１．７１＊２２）＊２５～３０＝１６０８～１９３０Ｋｃａｌと計算される。

　なお、本実施の形態は、上記の手法で算出した適正摂取カロリーを所定期間におけるカロリーの摂取許容量として算出してもよいし、図３７で後述する式（１）を用いて所定期間におけるカロリーの摂取許容量を算出してもよい。

　アルコールの一日の最大摂取量は例えば２５ｇ／日以下が推奨されている。この場合、本実施の形態は、飲酒により摂取されるアルコール量を個別メニューに表示することが可能である。これにより、ユーザはアルコールの摂取量を管理することが可能になる。また、糖尿病患者は休肝日を設定されるように医師から言われる場合もある。この場合、本実施の形態は、ユーザにより予め設定された週に１度の休肝日にはアルコールを含む料理を一切個別メニューに表示させないことが可能である。

　塩分の摂取が制限されるのは、塩分の摂取量が多いと血圧が上がり、腎臓に負担をかけるからである。高血圧でない人では、塩分の一日の最大摂取量は、成人男性なら８ｇ／日、成人女性なら７ｇ／日以下に制限することが推奨されている。高血圧の人の場合は、さらに厳しく５ｇ／日以下の制限が課されることもある。本実施の形態は、料理に含まれる塩分の量を個別メニューに表示させておくこと、患者の血圧状態に応じて減塩された料理のみを個別メニューに表示したりすることが可能である。これにより、ユーザは食事により摂取される塩分量を把握して、塩分摂取量を管理することが可能となる。

　また、糖尿病患者は、摂取カロリー及び血糖値に対して厳しい制限が課されるため、食べる量が減り、満腹感を得にくいという課題がある。そのため、糖尿病患者がボリュームのある食事を食べたい場合、食物繊維を多く含む食材を料理に使うことで満腹感を与えることが可能である。さらに、食物繊維をとることで、血糖値の上昇を抑制する効果も期待できる。本実施の形態は、食物繊維を多く含む料理を個別メニューで推奨することが可能である。或いは、本実施の形態は、食物繊維を多く含む料理を追加したセット料理を個別メニューに表示することが可能である。

　このような食事に関する制約条件及び推奨事項は、糖尿病以外の病気にも適用可能である。食事制限が必要な他の病気としては、高脂血症が挙げられる。コレステロールが高い高脂血症の患者に対しては、摂取カロリーの制限、コレステロール摂取量の制限、多価不飽和脂肪（植物油や魚油に多く含まれる）の多量摂取、食物繊維の多量摂取等が一般的に推奨される。コレステロールを多く含む食品は、鶏、豚、及び牛等のレバー、いか、すじこ、並びに卵黄等である。本実施の形態は、コレステロールの高い高脂血症のユーザに対してこれらの食材が減少或いは除外された料理を個別メニューに表示可能である。

　中性脂肪が高い高脂血症の患者に対しては、摂取カロリーの制限、糖質の制限、及びアルコールの制限等が一般的に推奨される。本実施の形態は、中性脂肪の高い高脂血症の患者に対しては、カロリー、糖質、及びアルコールが減少或いは除外された料理を個別メニューに表示可能である。

　さらに、食事制限が必要な他の病気としては、痛風が挙げられる。痛風の患者に対しては、肥満の是正（減量）、摂取カロリーの制限、プリン体の制限、アルコールの制限、水分の多量摂取等が一般的に推奨される。プリン体を多く含む食材は、エビ、するめ、レバー等である。本実施の形態は、痛風のユーザに対しては、これらの食材が減少或いは除外された料理を個別メニューに表示可能である。

　さらに、食事制限が必要な他の病気としては、高血圧症が挙げられる。高血圧症の患者に対しては、塩分摂取の制限、肥満の是正（減量）、及びアルコールの制限等が一般的に推奨される。本実施の形態は、高血圧症のユーザに対しては、塩分、アルコール、及びカロリー等が少ない料理が個別メニューに表示可能である。

　なお、これらの食事制限は一例であり、これとは異なる食事制限が課せられてもよい。また、これらの病気も一例であり、本実施の形態は他の食事制約がある病気にも同様に適用可能である。

　本実施の形態は、病気の進行に応じて、上記以外の食事制限を適宜変化させながら加えることが可能である。例えば、図２２では糖尿病患者に対してアルコールの一日の最大摂取量は２５ｇ／日以下にされているが、これは一般的な数値であり、個々の患者の病気進行度合いは考慮されていない。糖尿病が進行すれば、アルコールの一日の最大摂取量は下がり、最終的は禁酒が求められる場合もある。このように糖尿病が悪化した場合、本実施の形態は、アルコール量が基準値未満の酒だけを選択可能に個別メニューを表示したり、アルコール類を個別メニューに一切表示しないようにしたりすることも考えられる。

　また、高血圧症では、高血圧予防時には１０ｇ／日以下であった塩分摂取量が、高血圧治療中には７ｇ／日以下となり、さらに重症化すると５ｇ／日以下になることがある。このように、高血圧症では高血圧の進行度に応じて塩分の一日の最大摂取量が下げられることもある。本実施の形態は、高血圧症の患者に対しては、高血圧症が悪化した場合、塩分を多く含む料理ほど優先度を下げて個別メニューに表示する。これにより、塩分を多く含む料理は、個別メニューにおいて、目立たなく表示されたり、選択しにくい所に表示されたり、非表示にされたりする。さらに、本実施の形態は、料理を選択した際に、その料理の塩分の合計値を表示したり、組み合わせて食べることが推奨される料理を表示したりする。

　次に、カロリーを例に挙げて、上述の７つ目～１７個目のバリエーションで示した今回の食事での摂取許容量の算出方法について説明する。図２３は、今回の食事でのカロリーの摂取許容量を算出する例を説明するためのグラフである。このグラフにおいて、縦軸は摂取カロリー及び消費カロリーを示し、横軸は時間を示している。このグラフにおいて、バーはユーザの１時間ごとの消費カロリーを示し、白丸はユーザの１時間ごとの摂取カロリーを示している。消費カロリーはユーザに装着された加速度センサー及び／又は心拍センサーを用いて計測してもよい、摂取カロリーは生体インピーダンスセンサー及び／又は血糖値センサーを用いて計測してもよい。

　１日の適正摂取カロリーは、図３７で後述する式（１）を用いて算出可能である。例えば、１日の適正摂取カロリーは、２月１１日では１９００Ｋｃａｌ、２月１２日では１８８０Ｋｃａｌ、本日である２月１３日では１８５０Ｋｃａｌと算出されている。現在までの摂取カロリーは１日における現在までの摂取カロリーである。図中の「現在」の矢印が示す時刻は例えば個別メニューの算出タイミングである。本日における現在までの摂取カロリーは７１０Ｋｃａｌである。今回の食事でのカロリーの摂取許容量は、１日の適正摂取カロリーから現在までの摂取カロリーを減じることで算出される。したがって、２月１３日において今回の食事でのカロリーの摂取許容量は、１８５０Ｋｃａｌ－７１０Ｋｃａｌ＝１１４０Ｋｃａｌと算出される。

　この場合、情報端末１００の演算部１０４は、メニュー情報からカロリーが１１４０Ｋｃａｌ以下の料理の優先度が高くなるように個別メニューを生成する。

　図２３では、カロリーを例に挙げたが、特定の食材における、今回の食事での摂取目標量及び今回の食事での摂取許容量も図２３のカロリーの例と同様の手法により算出可能である。例えば、特定の食材における今回の食事での摂取目標量は、特定の食材について、本日の摂取目標量から、本日における現在までの累積摂取量を減じることで算出される。そして、演算部１０４は、メニュー情報から、特定の食材の量が今回の食事での摂取目標量以上の料理の優先度が高くなるように個別メニューを生成する。

　一方、特定の食材における今回の食事での摂取許容量は、特定の食材について、本日の摂取許容量から、本日における現在までの累積摂取量を減じることで算出される。そして、演算部１０４は、メニュー情報から、特定の食材の量が今回の食事での摂取許容量以下の料理の優先度が高くなるように個別メニューを生成する。特定の食材は例えば病気に応じて予め定められた栄養成分を含む食材が採用されてもよい。或いは、特定の食材は、図３７で後述する式（１）に示す食事制約条件のうち、摂取が制限される栄養成分に対応するベクトル（例えば塩分量ベクトル）のうち、推奨量を超える栄養成分を含む食材が採用されてもよい。また、特定の食材は、摂取が推奨される栄養成分に対応するベクトル（例えば食物繊維量ベクトル）のうち、推奨量を下回る栄養成分を含む食材が採用されてもよい。

　次に、高血圧症患者について血圧と塩分摂取量との関係について説明する。図２４は、高血圧症患者の血圧と塩分摂取量との関係を示すグラフである。図２４において、縦軸はユーザの血圧の測定値を示し、横軸は時間を示している。

　血圧の測定値は、ユーザが装着するリストバンドに内蔵された血圧センサーにより取得してもよい。このグラフでは１時間ごとの血圧の測定値が示されている。１つのバーの上端はその時刻での収縮期血圧の測定値であり、１つのバーの下端はその時刻での拡張期血圧の測定値である。

　この例では、２月１１日の最高血圧は１４５／９９である。この最高血圧は、「Ｉ度高血圧」と呼ばれる最も軽い高血圧症として分類される。２月１２日の最高血圧は、１４８／９９であり、前日と同様、「Ｉ度高血圧」に分類される。２月１３日の最高血圧は１３６／８９である。この最高血圧は、高血圧症ではない「正常高値血圧」として分類される。２月１４日の最高血圧は１３９／８９である。この高血圧は、前日と同様、「正常高値血圧」に分類される。

　横軸の最下段に示す「翌日の塩分摂取量」において、２月１３日の以降の塩分摂取量が、それまでの７ｇ／日以下から、１０ｇ／日以下へと緩和されている。これは、２月１２日まではＩ度高血圧であったのが、２月１３日からは正常高値血圧になり、高血圧症が改善しているからである。本実施の形態は、疾病の主要マーカーの値を生体センサー６００でリアルタイムに測定し、その改善（もしくは悪化）に応じて、食事制限を緩和（もしくは強化）することが可能である。このように、時々刻々と変化するユーザの生体情報の推移に基づいて、ユーザが摂るべき食事や行うべき運動の内容を更新して、ユーザに情報端末１００などを通じて、提案することができる。

　例えば、演算部１０４は、前日の血圧値分類が「Ｉ度高血圧」である２月１３日までは、１日の塩分の摂取許容量を７ｇに設定して個別メニューを生成し、前日の血圧測定結果が「正常高値血圧」である２月１４日以降では、塩分の摂取許容量を１０ｇに緩和して個別メニューを生成する。

　上記の例では、最高血圧のみが参照されたが、最低血圧も含めて塩分の摂取許容量が設定されてもよいし、血圧値の平均又は分散を加味して塩分の摂取許容量が設定されてもよい。また、一日ごとではなく、それより長いまたは短い時間ごとの血圧状況に基づいて塩分の摂取許容量が設定されてもよい。また、運動中の血圧測定結果を除外するため、心拍数又は活動量などの他の情報を加味して塩分の摂取許容量が設定されてもよい。

　（データ構成）
　次に、本実施の形態で使用される各種データのデータ構成について説明する。図２５は、第１サーバ２００で管理されているユーザの定期健康診断の診断結果を含む情報２５００のデータ構成の一例を示す図である。この情報２５００は、演算処理が容易にできるようにフィールドとバリューとが対応付けて記載されている。情報２５００は、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標）　Ｏｂｊｅｃｔ　Ｎｏｔａｔｉｏｎ）フォーマットにて１ファイルが構成されている。

　「情報カテゴリ」フィールドは、情報２５００がどういう種類の個人情報であるかを示すフィールドである。情報２５００は健康に関するデータであるため、「情報カテゴリ」フィールドに対するバリューには「健康」が記載されている。「情報カテゴリ」フィールドは情報２３００の先頭に記載されている。なお、「情報カテゴリ」が「健康」である情報は食属性を持つものとして取り扱われる。

　「発行元」フィールドは、この情報２５００を取得した法人を識別するためのフィールドである。ここでは、ＡＢＣクリニックにより定期健康診断の診断結果が作成されたため、「発行元」フィールドに対応するバリューには、ＡＢＣクリニックが記載されている。

　「発行日」フィールドは、この情報２５００の発行元による発行日時を示すフィールドである。ここでは、「発行日」フィールドに対応するバリューには、２０２０年２月１５日が記載されている。このバリューには発行日に加えて時刻が含まれていてもよい。また、このバリューにはタイムゾーン情報が含まれていてもよい。

　「データ種別」フィールドは、この情報２５００の内容を具体的に特定するフィールドである。ここでは、「データ種別」フィールドに対応するバリューには、例えば、「健康診断情報」が記載されている。これにより、以下のフィールドに記載されたデータがユーザの定期健康診断の診断結果に関する情報であることが示される。

　なお、情報端末１００は、「情報カテゴリ」フィールド及び「データ種別」フィールドのそれぞれに対応するバリューの記載内容に基づいて、情報２５００に定期健康診断の診断結果が含まれていると解釈すればよい。或いは、情報端末１００は、情報２５００に関連する情報（例えば、情報２５００のファイル名）に基づいて情報２５００に定期健康診断の診断結果が含まれていると解釈してもよい。

　「データ測定日」フィールドは、先行する「データ種別」フィールドに対応するバリュー「健康診断情報」で示される定期健康診断が実施された日時情報を示すフィールドである。ここでは、「データ測定日」フィールドに対応するバリューは２０２０年２月１４日と記載されている。このバリューには測定日に加えて時刻が含まれていてもよい。また、このバリューにはタイムゾーン情報が含まれていてもよい。なお、第１サーバ２００に該当するユーザについて複数の定期健康診断の診断結果が記憶されている場合、「データ測定日」フィールドに記載された日付が最新の情報２５００が使用されるようにしてもよい。

　「データ測定日」以降のフィールド及びバリューにはユーザの、身長、体重、収縮期血圧、拡張期血圧、赤血球数、へモグロビン数、ＨＤＬコレステロール、ＬＤＬコレステロール、空腹時血糖、及び尿酸のそれぞれについての診断結果が記載されている。

　図２６は、第１サーバ２００で管理されているユーザの病気診断書の記載内容を含む情報２６００のデータ構成の一例を示す図である。病気診断書はユーザが通院する医療機関により発行されたものである。病気診断書には、ユーザが罹患する病気に関する情報が記載されている。情報２６０１は糖尿病に対する病気診断書の記載内容を含み、情報２６０２は高血圧症に対する病気診断書の記載内容を含んでいる。

　情報カテゴリ、発行元、発行日、データ測定日は、情報２５００と同じである。「データ種別」フィールドに対応するバリューには情報２６００が病気診断書であることを示す「診断書」が記載されている。

　「疾病名」フィールドに対応するバリューにはユーザが罹患している病気の名称が記載されている。「疾病名」フィールドに対するバリューが「糖尿病」の場合、それに続くフィールド及びバリューには糖尿病に関する疾病度合いを示すデータが記述されている。具体的には、情報２６０１には、「疾病発生日」、「病型」、「ＨｂＡ１ｃ（ＮＧＳＰ）［％］」、及び「空腹血糖値」が記載されている。

　「ＨｂＡ１ｃ（ＮＧＳＰ）［％］」は、糖化ヘモグロビンの存在割合を表す国際基準であり、過去２ヶ月間ほどの血糖値の平均を反映した値を有している。例えば、正常値は５．６未満、要注意が５．６～５．９、予備軍が６．０～６．４、陽性が６．５以上である。ここでは、バリューに「６．９」が記載されているため、このユーザの「ＨｂＡ１ｃ（ＮＧＳＰ）［％］」の測定値は糖尿病の陽性判定域に属している。

　「空腹時血糖値［ｍｇ／ｄｌ］」は、１０時間以上絶食した状態で測定された最低血糖値である。例えば、正常値は８０～９９、予備軍は１００～１２５、陽性は１２６以上である。ここでは、バリューに「１３１」が記載されているため、このユーザの「空腹時血糖値［ｍｇ／ｄｌ］」の測定値は、糖尿病の陽性判定域に属している。

　「疾病名」フィールドに対するバリューが「高血圧症」の場合、それに続くフィールド及びバリューには、高血圧症に関する疾病度合いを示すデータが記述されている。

　具体的には、情報２６０２には、「疾病発生日」、「分類」、「収縮期血圧［ｍｍＨｇ］」、及び「拡張期血圧［ｍｍＨｇ］」が記載されている。

　「分類」は、血圧値による高血圧の分類を示している。血圧値が低い方から順に、至適血圧、正常血圧、及び正常高値血圧の３つがあり、これらは正常域血圧に分類される。さらに「分類」は、Ｉ度高血圧、ＩＩ度高血圧、ＩＩＩ度高血圧、収縮期高血圧の４つがあり、これらは高血圧に分類される。ここでは、バリューに「Ｉ度高血圧症」が記載されているため、ユーザが最も軽度な高血圧症と分類されていることがわかる。

　「収縮期血圧［ｍｍＨｇ］」フィールドと「拡張期血圧［ｍｍＨｇ］」フィードとのバリーのそれぞれには、血圧値が記載されている。ここでは、バリューに「１５５」及び「９２」が記載されているため、このユーザの血圧は、Ｉ度高血圧に分類される。

　このように、医療機関（この例ではＡＢＣクリニック）が発行する病気診断書の診断内容を含む情報２６００は、測定日及び発行日を含む形式で第１サーバ２００に蓄積されている。そのため、「データ測定日」フィードのバリューに記載された日付を比較することで、ユーザの過去の病歴及びその進行度合いを正しく把握することが可能となる。また、最新の病気診断結果を参照することも可能である。

　この例では、ユーザのデータであることは、フィールドに記載されていないが、例えばファイル名としてユーザの識別情報を採用することで特定可能である。

　図２７は、第１サーバ２００で管理される生体情報を含む情報２７００のデータ構成の一例を示す図である。

　情報２７００には、測定日時、収縮期血圧、拡張期血圧、摂取カロリー、消費カロリー、塩分摂取量、アルコール摂取量、ＨｂＡ１ｃ、及び血糖値等が含まれている。測定日時は年月日時分秒が日本標準時間にて表現されている。収縮期血圧、拡張期血圧、ＨｂＡ１ｃ、及び血糖値は、対応する測定日時における測定値が記録されている。摂取カロリー、消費カロリー、及びアルコールのそれぞれは、対応する測定日時における一時間当たりに換算された測定値が記録されている。塩分摂取量は、対応する測定日の前日一日当たりに換算された測定値が記録されている。

　これらの測定値は１つ以上の生体センサー６００の測定値から直接的又は間接的に導きだされた値が記録されている。

　例えば、収縮期血圧及び拡張期血圧は血圧センサーで測定してもよい。摂取カロリーは生体インピーダンスセンサー及び／又は血糖値センサーで測定してもよい。消費カロリーは加速度センサー及び／又は心拍センサーで測定してもよい。塩分摂取量は尿内塩分濃度センサーで測定してもよい。アルコールは生体ガスセンサーで測定してもよい。ＨｂＡ１ｃは近赤外線及び／又は中赤外線レーザーセンサーで測定してもよい。血糖値は血糖値センサー及び／又は皮下組織のブドウ糖センサーで測定してもよい。

　同一種類の生体情報の測定値が２つ以上の生体センサー６００によって測定された場合、それら複数のセンサーの精度に応じて重み付けされた測定値の平均値が情報２７００に記録されてもよい。

　ここでは、生体センサー６００の測定値は時系列に記録されているが、本開示はこれに限らない。例えば、ユーザの食事の注文履歴情報が取得できる場合には、その注文履歴情報が示す注文した料理のカロリー量、塩分量、アルコール量、食物繊維量、及びコレステロール量等を用いて、情報２７００に記録される測定値は補完又は補正されてもよい。

　例えば、生体ガスセンサーにより、皮膚から放出される揮発性ガスの濃度分布からアルコール量を測定した場合は、精度が低いと予測される。この場合、注文履歴情報から摂取したお酒の量と度数とが読み取れる場合には、下記の計算式によってアルコール量が算出されてもよい。

　アルコール量［ｇ］＝お酒の量［ｍｌ］＊アルコール度数［％］／１００＊０．８　食物繊維量も、同様に注文履歴情報の内容から読み取れる場合には、それを用いて測定データを補完又は補正されてもよい。この例では、情報２７００において、ユーザのデータであることは記載されていないが、例えばファイル名としてユーザの識別情報を採用することで特定可能である。

　図２８は、食材情報２８００のデータ構成の一例を示す図である。食材情報２８００は、演算処理が容易にできるようにフィールドとバリューとが対応付けて記載されている。食材情報２８００は、レストラン各社の第２サーバ３００から取得される、例えばＨＴＭＬファイル形式のメニュー情報の中に食材情報を示すタグと共に埋め込まれている。但し、これは一例であり、食材情報２８００はＪＳＯＮフォーマットで構成され、料理毎に準備された別ファイルで構成されていてもよい。

　「料理名」フィールドは、この情報がどの料理に関する食材情報であるかを示すフィールドである。食材情報２８０１の例では「料理名」フィールドに対応するバリューにはラーメンＢセットが記載され、食材情報２８０２の例では「料理名」フィールドに対応するバリューには醤油ラーメンが記載され、食材情報２８０３の例では「料理名」フィールドに対応するバリューには小籠包が記載されている。

　「料理名」フィールドに続くフィールド及びバリューには、使用される食材の一覧が記載されている。例えば、食材情報２８０１は、一杯の醤油ラーメンと３個の小籠包とで構成されているため、「醤油ラーメン」フィールド及び「小籠包」フィールドが含まれており、醤油ラーメンに対応するバリューには「１」が記載され、小籠包に対応するバリューには「３」が記載されている。食材情報２８０１はセット料理の食材情報２８００であるため、料理を構成する食材に関するフィールド及びバリューは設けられていない。

　食材情報２８０２には、醤油ラーメン単品の食材情報２８００であるため、「小麦粉」は「５０ｇ」、「食塩」は「５ｇ」というように醤油ラーメンを構成する各食材と各食材の量とが対応付けて記載されている。食材情報２８０３も食材情報２８０２と同様、小籠包単品の食材情報２８００であるため、小籠包を構成する各食材と各食材の量とが対応付けて記載されている。

　ラーメンＢセットには、食材情報２８０２に示されるように、「食塩」の量が８ｇであり、糖尿病患者にとって過剰である。また、食材情報２８０３に示されるように、小籠包は野菜が少ないため食物繊維が不足する。そのため、糖尿病のユーザはラーメンＢセットをそのまま食することは妥当ではない。そこで、情報端末１００の演算部１０４は、例えばラーメンＢセットに代えて、図２９に示す減塩ラーメンと野菜餃子の料理セットを個別メニューを通じてユーザに提案する。

　図２９は、減塩ラーメンと野菜餃子の食材情報２８０４の一例を示す図である。減塩ラーメンと野菜餃子は、食材情報２８０５及び食材情報２８０６に示すように、食塩が８ｇから３ｇに下げられ、豚チャーシューに代えてチンゲンサイが使用され、豚ひき肉に代えてニラが使用され、はちみつ及び鶏ガラスープに代えてキャベツ及び砂糖が使用されている。これにより、個別メニューには、糖尿病のユーザが食することが可能な「減塩ラーメンと野菜餃子」が個別メニューに表示され、このユーザは自身が食することが可能な料理の中からスムーズに注文できる。

　料理を差し替えるにあたり、情報端末１００は、図２８に示す食材情報２８０２及び食材情報２８０３と、該当するユーザの食事制限の程度を示す情報が示す該当するユーザの摂取制限食材（例えば、アルコール、塩分等）とを照合し、食材情報２８０２及び食材情報２８０３の中から置換対象の食材を抽出する。

　次に、情報端末１００は、食事制限の程度を示す情報に基づいて、置換対象の食材の今回の摂取許容量を算出し、置換対象の食材の量が今回の摂取許容量以上であれば、その置換対象の食材の量を今回の摂取許容量以下に下げる。また、情報端末１００は、置換対象の食材の量が今回の摂取許容量以上である場合において、代替食材及びその代替食材の量が予め定められている場合は、代替食材及び代替食材の量で置換対象の食材及び量を置換することで、食材情報２８０２及び食材情報２８０３を差し替える。さらに、情報端末１００は、食材情報２８００の料理名も置換後の食材に応じて予め定められた料理名に差し替える。これにより、図２９に示す食材情報２８００が得られる。情報端末１００は、この処理を、取得したメニュー情報に含まれる各料理のそれぞれについて適用することで、料理を差し替えればよい。

　尚、上記では情報端末１００にて料理の食材を、ユーザの食事制限の程度を示す情報に基づいて変更したが、本開示はこれに限らない。例えば、第２サーバ３００から単品料理の食材情報（２８０２、２８０３、２８０５、２８０６）を受信し、第１サーバ２００からユーザの食事制限の程度を示す情報を受信し、情報端末１００がユーザの食事制限の程度を示す情報に沿う料理を、単品料理もしくは複数料理が含まれるセットメニューとして提案するようにしてもよい。

　（処理の全体像）
　次に、本実施の形態における情報処理システムの処理の全体像について説明する。図３０は、本実施の形態における情報処理システムの処理の全体像の一例を示すシーケンス図である。

　レストランＡ社に入店及び着席したユーザの操作にしたがって情報端末１００により起動されたマッチングアプリは、ユーザ認証を行う（ステップＳ５０１）。ユーザ認証に成功したマッチングアプリは、ホーム画面Ｇ１０３（図１４参照）を表示する。

　ホーム画面Ｇ１０３においてユーザによりスキャンボタン１４０２がタッチされると、マッチングアプリは、スキャン機能を起動し、ユーザの座席に対応するＱＲコードを取得する（ステップＳ５０２）。これにより、マッチングアプリは、接続先であるレストランＡ社の第２サーバ３００（ＨＴＴＰサーバ）のＵＲＬを取得する。

　ＵＲＬを取得したマッチングアプリは、ＵＲＬに基づいてレストランＡ社の第２サーバ３００に対してメニュー情報を取得するための要求（例えばＨＴＴＰリクエスト）を送信する（ステップＳ５０３）。この際、マッチングアプリは、上述したようにＱＲコードに含まれる席ＩＤを第２サーバ３００に送信してもよい。

　その要求を受信した第２サーバ３００は、ＨＴＴＰサーバ機能を用いて、メニュー情報を返信するＨＴＴＰレスポンスを送信する。これにより、マッチングアプリは、レストランＡ社のメニュー情報を受信する（ステップＳ５０４）。

　メニュー情報を受信したマッチングアプリは、受信したメニュー情報を解析し、受信したメニュー情報のデータ属性が食属性であることを検出する。この場合、マッチングアプリは、メニュー情報を内部解析することで食属性であることを検出すればよい。或いは、マッチングアプリは、メニュー情報とは別に送信された補足情報から食属性であることを検出してもよい。そして、マッチングアプリは、受信したメニュー情報のデータ属性が食属性であるため、病気情報及び／又は生体情報をマッチングを行うためのデータとして決定する（ステップＳ５０５）。

　次に、マッチングアプリは、ユーザ認証が行われたユーザのユーザＩＤに基づいて、当該ユーザの病気情報及び／又は生体情報の取得を要求するためのＨＴＴＰリクエストを第１サーバ２００に送信する（ステップＳ５０６）。このＨＴＴＰリクエストをＨＴＴＰサーバの機能を用いて受信した第１サーバ２００は、ユーザＩＤに基づいて当該ユーザの病気情報及び／又は生体情報をメモリ２０３から抽出し、抽出した病気情報及び／又は生体情報を返信するＨＴＴＰレスポンスをマッチングアプリに送信する。これにより、マッチングアプリは、当該ユーザの病気情報及び／又は生体情報を受信する（ステップＳ５０７）。

　病気情報及び／又は生体情報を受信したマッチングアプリは、受信した病気情報及び／又は生体情報に基づいて食事制限の程度を示す情報を算出し、算出した食事制限の程度を示す情報と受信したメニュー情報とに基づいて、上述した１７個のバリエーションで示される方法のいずれかを用いて、当該ユーザの食事制限の程度を示す情報に対応した個別メニューを生成する（ステップＳ５０８）。

　マッチングアプリは、ステップＳ５０１からステップＳ５０８までの処理において表示される各種画面のスタイルＵＩ（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）デザインをマッチングアプリのスタイルに則って生成するが、個別メニューから注文完了までの各種画面のスタイル（例えばＵＩデザイン）については、レストランＡ社が提供するスタイルに則って生成する。言い換えると、サービス提供会社である各事業者（例えば、各レストラン）は、他社（例えば、情報銀行又は情報仲介業者）が開発したマッチングアプリ上でありながら、自らの好むスタイル（例えばＵＩデザイン）でユーザ（例えば、顧客）とコミュニケーションをとることができる。これは、上述した標準メニューと個別メニューとのそれぞれを、レストランＡ社が指定するスタイル（例えばＵＩデザイン）で表現し、さらには一貫性を持たせることが可能であることを意味する。

　個別メニューを生成したマッチングアプリは、生成した個別メニューを含む操作画面Ｇ１０６をレストランＡ社が指定するスタイルで表示し、個別メニューの中から料理を注文するユーザによる選択指示を受け付ける（ステップＳ５０９）。

　選択指示を受け付けたマッチングアプリは、ユーザの席ＩＤと注文する料理を示す注文料理情報とを対応付けた注文リクエストをレストランＡ社の第２サーバ３００へ送信する（ステップＳ５１０）。注文された料理の食材情報２８００が第２サーバ３００から受信したメニュー情報から変更されている場合、マッチングアプリは変更後の食材情報２８００を注文料理情報に含めて第２サーバ３００に送信すればよい。これにより、レストランＡの店舗は、置換食材及び置換食材の量が反映された料理をユーザに提供することが可能になる。尚、この食材情報２８００がステップＳ５０４で受信した情報と異なる場合、マッチングアプリは、ステップＳ５０８で個別メニューを生成する際に、その食材変更が対応可能か否かを第２サーバ３００に問い合わせておくようにしてもよい。

　注文リクエストを受信した第２サーバ３００は、マッチングアプリへ注文を受信したことを示す応答確認（ＡＣＫ）と、必要に応じて現在の注文状況（例えば、注文履歴画面Ｇ１０８に関する情報）とを返信する。これにより、マッチングアプリは、現在の注文状況を受信する（ステップＳ５１１）。

　マッチングアプリは、レストランＡ社の第２サーバ３００に対して、注文料理情報をユーザＩＤと対応付けて第１サーバ２００にも送付し（ステップＳ５１２）、当該ユーザの食事履歴情報に追加又は更新するように要請する。注文料理情報を受信した第１サーバ２００は、当該ユーザの食事履歴情報を受信した注文料理情報に従って更新する（ステップＳ５１３）。この場合、食事履歴情報には注文料理情報が示す料理の注文時刻を示すタイムスタンプも付与される。

　ステップＳ５１２において送信される注文料理情報には、個別メニューにて選択された料理の料理名を示す情報、個別メニューにて選択された料理の価格を示す情報、個別メニューにて選択された料理が注文された日時を示す情報、個別メニューにて選択された料理に含まれる栄養成分を示す情報、及び注文を行ったレストラン会社（及びその店舗）を示す情報、が含まれていてもよい。

　注文リクエストを受信したレストランＡ社の第２サーバ３００は店舗内のディスプレイに注文リクエストを表示する（ステップＳ５１４）。これにより店舗の従業員は料理を注文した座席のユーザに対して間違いなく注文された料理を配膳できる。

　このようにユーザの個人情報の一部でもある食事履歴情報が、きめ細かく、正確、且つ時系列的に第１サーバ２００に蓄積されていく。これにより、次の料理の注文の際に、そのビッグデータが活用され、適合度の高い料理の選択肢がより高精度にユーザに提示される。

　図３０に示される制御方法によれば、食事制限のあるユーザに対して、当該ユーザが避けるべき食材を含む料理が間違って配膳されるリスクを低減できる。さらに、図３０に示される制御方法によれば、避けるべき食材及び調理方法等の細かな確認が必要なユーザであっても、そのような確認をレストラン側に行わせることなく、そのユーザは簡易に料理を注文することができ、さらに、レストラン側もそのようなユーザからの料理の注文を簡易に対応することができる。また、図３０に示される制御方法によれば、病気情報及び／又は生体情報というユーザのプライバシーに関わる個人情報がレストランのスタッフに伝わるユーザの不安、及びプライバシーに関わる個人情報が店舗端末に蓄積されることに関するユーザの不安が低減される。

　さらに、図３０に示される制御方法によれば、正確且つ時間的に連続した病気情報及び／又は生体情報、及び食事履歴情報（例えば、注文履歴情報）等を含む個人情報が効率的且つ安全に管理される。さらに、図３０に示される制御方法によれば、個人情報がユーザにより許諾された事業者以外に漏洩することが防止される。さらに、図３０に示される制御方法によれば、ユーザも自らの病気情報及び／又は生体情報の詳細やその経緯に注意又は配慮する煩わしさなく、安心して注文を行うことができる。

　（注文処理のフローチャート）
　次に、本実施の形態における情報端末１００の処理について説明する。図３１は、標準メニューから料理が注文される場合の情報端末１００の処理の一例を示すフローチャートである。このフローチャートは、情報端末１００においてユーザによりＱＲコードリーダーが起動されたことをトリガーに開始される。

　ステップＳ１１において、ＱＲコードリーダーは、自席に対応するＱＲコードを読み取り、読み取った文字列（例えば、ＵＲＬ）をブラウザに渡す。この処理では、図７に示す操作画面Ｇ１を用いてＱＲコードが読み取られ、図８に示すＱＲコードの読み取り結果が操作画面Ｇ２に表示される。

　ステップＳ１２において、ブラウザは、ＵＲＬに従ってレストランＡ社の第２サーバ３００にアクセスし、メニュー情報を取得し、標準メニューを情報端末１００のディスプレイ１０５に表示する。この処理では、図９に示す標準メニューを含む操作画面Ｇ３が表示される。

　ステップＳ１３において、ブラウザは標準メニューの中から注文する料理を選択する指示をユーザから受け付ける。この処理では、図１０に示す操作画面Ｇ３に含まれる標準メニューがユーザによって操作され、注文する料理が選択される。

　ステップＳ１４において、ブラウザは、レストランＡ社の第２サーバ３００に対して、ユーザの席ＩＤとユーザが注文した料理を示す注文料理情報とを対応付けた注文リクエストを送信する。以上により標準メニューからの注文処理が終了される。

　このように、レストランにて、自身の食事制限の程度を示す情報が考慮された適切なメニューを注文したいユーザは、マッチングアプリを使って個別メニューを表示して料理を注文する。一方で、自身の食事制限の程度を示す情報が考慮されることなくレストランの標準メニューから料理を選択したいユーザは、汎用的なＱＲコードリーダーを使って標準メニューを表示し、料理を注文する。

　いずれのケースにおいても、ユーザが着席した座席に対応したＱＲコードから読み取られた席ＩＤが注文料理情報と対応付けて第２サーバ３００に送信されているため、注文した料理は間違いなく配膳される。

　図３２は、個別メニューから料理が注文される場合の情報端末１００の処理の一例を示すフローチャートである。このフローチャートは、レストランに入店して料理を注文するユーザがマッチングアプリを起動させたことをトリガーに開始される。

　ステップＳ１において、マッチングアプリは、ユーザの自席に対応するＱＲコードを取得する処理を実行する。この処理の詳細は図３３を用いて後述する。この処理においては、図１５に示す操作画面Ｇ１０４を通じてＱＲコードが読み取られ、席ＩＤ及びレストランＩＤが取得される。この処理は、図３０のステップＳ５０１，Ｓ５０２に対応している。

　ステップＳ２において、マッチングアプリは、取得したＱＲコードが示すＵＲＬにブラウザ機能を使ってアクセスし、レストランＡ社の第２サーバ３００からレストランＡ社のメニュー情報を取得する処理を実行する。この処理の詳細は図３４を用いて後述する。この処理において、メニュー情報のデータ属性が食属性であることも検出される。この処理においては、図１７に示す表示画面Ｇ１０５が情報端末１００に表示される。この処理は、図３０のステップＳ５０３，Ｓ５０４に対応している。

　ステップＳ３において、マッチングアプリは、第１サーバ２００から、ユーザの個人情報の中から、食属性に関する個人情報である病気情報及び／又は生体情報を取得する処理を実行する。この処理の詳細は図３５を用いて後述する。この処理により、ステップＳ１で取得された席ＩＤが示す座席に着席したユーザの病気情報及び／又は生体情報が取得される。この処理は、図３０のステップＳ５０５，Ｓ５０６，Ｓ５０７に対応している。

　ステップＳ４において、マッチングアプリは、レストランＡ社のメニュー情報と、ユーザの食事制限の程度を示す情報とを照合し、分類に対応した料理を含む個別メニューを生成する処理を実行する。この処理により、個別メニューを含む操作画面Ｇ１０６が表示される。この処理は、図３０のステップＳ５０８に対応している。

　ステップＳ５において、マッチングアプリは、個別メニューを閲覧したユーザにより注文する料理の選択指示を受け付ける。この場合、図１９の操作画面Ｇ１０６に示されるように料理が選択される。この処理は、図３０のステップＳ５０９に対応している。

　ステップＳ６において、マッチングアプリは、ステップＳ５で選択された料理を示す注文料理情報をステップＳ１で取得した席ＩＤと対応付けた注文リクエストをレストランＡ社の第２サーバ３００に送信する。この処理は、図３０のステップＳ５１０に対応している。

　以下、個別メニューから料理が注文されるケースの詳細を説明する。図３３は、図３２のステップＳ１の処理の詳細を示すフローチャートである。ステップＳ１０１において、ユーザにより起動されたマッチングアプリは、ユーザに対してユーザ認証を要求する。この場合、図１２に示す認証画面Ｇ１０１又は図１３に示す認証画面Ｇ１０２を用いたユーザ認証が行われる。

　ステップＳ１０２において、マッチングアプリは、ユーザの認証に成功したか否かを判定する。ここで、ユーザ認証に失敗した場合（ステップＳ１０２でＮＯ）、処理はステップＳ１０１に戻る。ユーザ認証に成功した場合（ステップＳ１０２でＹＥＳ）、処理はステップＳ１０３に進む。ステップＳ１０３において、マッチングアプリは、図１４に示すマッチングアプリのホーム画面Ｇ１０３を表示する。

　ステップＳ１０４において、マッチングアプリは、ホーム画面Ｇ１０３のスキャンボタン１４０２をタッチするユーザの操作を受け付け、ＱＲコードの読取機能を起動する。これにより、図１５に示す操作画面Ｇ１０４が表示される。なお、ＮＦＣでレストランＩＤ及び席ＩＤを読み取る態様が採用される場合、図１６に示す操作画面Ｇ１０１１が表示される。

　ステップＳ１０５において、ユーザにより情報端末１００の向きと位置とが調整され、マッチングアプリは、ユーザが着席した座席に対応するＱＲコードを読み取る。

　図３４は、図３２のステップＳ２の処理の詳細を示すフローチャートである。ステップＳ２０１において、マッチングアプリは、ＱＲコードに記述された文字列（例えば、ＵＲＬ）に基づき、レストランＡ社の第２サーバ３００にアクセスする。このアクセスは、例えば、ＨＴＴＰリクエストにより行われる。

　ステップＳ２０２において、レストランＡ社の第２サーバ３００は、ＨＴＴＰサーバ機能を用いて、最新のメニュー情報を、マッチングアプリへ返信する。この返信は例えばＨＴＴＰレスポンスにより行われる。

　ステップＳ２０３において、マッチングアプリは、レストランＡ社の最新のメニュー情報を取得する。

　ステップＳ２０４において、マッチングアプリは、取得したメニュー情報から、メニュー情報のデータ属性が食属性であることを検出する。この検出は、例えば、メニュー情報を構成するＨＴＭＬファイル内に記載されたデータ種類又はデータ属性識別情報（ＨＴＭＬタグ）に基づいて判定されてもよい。

　図３５は、図３２のステップＳ３の処理の詳細を示すフローチャートである。ステップＳ３０１において、マッチングアプリは、取得したメニュー情報のデータ属性が食属性であるため、ユーザの病気情報及び／又は生体情報をマッチングを行うためのデータとして決定する。

　ステップＳ３０２において、マッチングアプリは、第１サーバ２００に対して、マッチングの対象となるユーザの病気情報及び／又は生体情報の取得を要求する。この場合、マッチングアプリは、ユーザＩＤを指定して、病気情報及び／又は生体情報を所定の暗号化状態で返信するよう要求する。

　ステップＳ３０３において、第１サーバ２００は、分散暗号化されて管理されている膨大な個人情報の中から、ユーザＩＤに基づいて病気情報及び／又は生体情報を抽出し、この病気情報及び／又は生体情報を所定のフォーマットに成形した後、所定の暗号化を行い、マッチングアプリへ返信する。

　ステップＳ３０４において、マッチングアプリは、取得した最新の病気情報及び／又は生体情報を復号する。これにより、ユーザの病気情報及び／又は生体情報が取得される。

　図３６は、図３２のステップＳ４の処理の詳細を示すフローチャートである。ステップＳ４０１において、マッチングアプリは、ユーザの病気情報及び／又は生体情報に基づき、ユーザの食事制限の程度を示す情報を新たに算出する。この処理の詳細は、図３７を用いて後述する。

　ステップＳ４０２において、マッチングアプリは、レストランＡ社のメニュー情報と、ユーザの食事制限の程度を示す情報とを照合し、ユーザの食事制限に対応したユーザの個別メニューを生成する。メニュー情報には前述したように各料理に含まれる１以上の食材と食材の量とが含まれる。メニュー情報には、各料理の調理方法を示す調理方法情報が含まれていてもよい。ここでは、上述した１７個のバリエーションのいずれかの方法を用いて個別メニューが生成される。

　ステップＳ４０３において、マッチングアプリは、ブラウザ機能を用いて、生成した個別メニューを含む操作画面Ｇ１０６を生成し、情報端末１００のディスプレイ１０５に表示する。この場合、個別メニューは、例えばレストランＡ社のメニュー情報に含まれる表示スタイル情報が適用されて表示される。

　（食事制限の程度を示す情報）
　次に、食事制限の程度を示す情報が算出される処理について説明する。図３７は、食事制限の程度を示す情報を算出するための式（１）を示す図である。

　式（１）において、食事制約条件と名付けられた行列は食事制限の程度を示す情報に相当する。食事制約条件の行列は、カロリー量ベクトル、アルコール量ベクトル、塩分量ベクトル、及び食物繊維量ベクトルを含む。これらのベクトルはそれぞれＮ×１の行列である。

　カロリー量ベクトル及び塩分量ベクトルは、それぞれ、禁止量、注意量、推奨量、及び必須量で構成される。禁止量は、これ以上摂取すると病気が悪化する可能性が極めて高い量である。注意量は禁止量よりも少ない量であり、これ以上摂取すると、病気が悪化する可能性が高い量である。禁止量は上述した所定期間における摂取許容量の一例に該当する。推奨量は注意量よりも少ない量であり、最適な最も過不足がない摂取量である。必須量は推奨量よりも少ない量であり、例えば生命を維持するために最低限摂取する必要がある量である。アルコール量ベクトルは、禁止量、注意量、及び許可量で構成される。許可量は注意量よりも少ない量であり、摂取量がこれ以下であれば、病気が改善に向かう又は病気がこれ以上悪化しない可能性が高い量である。食物繊維量ベクトルは推奨量及び必須量から構成される。推奨量は最も過不足がない摂取量であり、これ以上摂取すると病気が改善に向かう可能性が高い量である。推奨量は上述した所定期間における摂取目標量の一例に該当する。必須量は最低限摂取する必要がある量であり、これ以下であれば病気が改善しない又は病気が悪化する可能性が高い量である。

　行列Ｃは、病気情報＋生体情報で示される行列から食事制約条件を求めるための変換行列であり、統計的にもしくはユーザ毎に予め算出された行列である。

　病気情報＋生体情報で示される行列は、健康診断ベクトル、収縮期血圧ベクトル、拡張期血圧ベクトル、血糖値ベクトル、摂取カロリーベクトル、及び消費カロリーベクトルを含む。健康診断ベクトルは、情報２５００（定期健康診断の診断結果）に含まれる測定日、身長、体重、収縮期血圧、拡張期血圧などで構成される。健康診断ベクトルには情報２６００（病気診断書の診断内容）に含まれる各種データを含んでもよい。

　収縮期血圧ベクトル、拡張期血圧ベクトル、血糖値ベクトル、摂取カロリーベクトル、及び消費カロリーベクトルは、それぞれ、情報２７００に記録された生体情報において、最新から７２時間前までの１時間ごとの収縮期血圧、拡張期血圧、血糖値、摂取カロリー、及び消費カロリーの測定値により構成される。ここでは、情報２７００に記録された直近３日間の測定値が採用されたが、これは一例であり、より長期間（４日、１週間、及び１か月等）の測定値が採用されてもよいし、より短期間（１日及び２日等）の測定値が採用されてもよい。また、病気情報＋生体情報の行列に採用される生体情報は図３７に例示した生体情報以外の生体情報が採用されてもよい。

　行列Ｃは、例えば以下のように算出される。第１サーバ２００のメモリ２０３には、各ユーザが食事をしたときの、収縮期血圧、拡張期血圧、血糖値、摂取カロリー、及び消費カロリーと、食事がユーザに与える影響内容と、ユーザの身体情報とが対応付けられた食事履歴情報が大量に蓄積されている。影響内容には、カロリー量、アルコール量、塩分量、及び食物繊維量のそれぞれの変化量が含まれている。身体情報には、最新の定期健康診断により得られた、身長、体重、収縮期血圧、及び拡張期血圧等が含まれる。

　一方、カロリー量、アルコール量、塩分量、及び食物繊維量の少なくとも１つにはユーザの病気を改善するために要求される変化量の基準条件がユーザ毎に予め定められている。第１サーバ２００は、この大量に蓄積された個々の食事履歴情報について、カロリー量、アルコール量、塩分量、及び食物繊維量の変化量が対応する基準条件を満たすために要求されるカロリー量ベクトル、アルコール量ベクトル、塩分量ベクトル、及び食物繊維量ベクトルを算出する。そして、第１サーバ２００は、算出したカロリー量ベクトル、アルコール量ベクトル、塩分量ベクトル、及び食物繊維量ベクトルと、収縮期血圧、拡張期血圧、血糖値、摂取カロリー、及び消費カロリーとの関係を学習することで行列Ｃを算出する。

　または、行列Ｃは、当該ユーザ又は不特定多数のユーザの病気情報＋生体情報の行列が、既知の食材を含む各食事の前後で夫々どのように変化したかの相関データを第１サーバ２００のメモリ２０３に多量に蓄積することで、当該ユーザ又は不特定多数のユーザ向けに、摂取する食事と生体情報の変化量との相関関係を求めて算出するようにしてもよい。

　ここで説明の簡略化のために一例として、血糖値と行列Ｃのカロリー量ベクトル成分だけに注目して説明する。あるユーザがカロリー量がＸ１、Ｘ２、Ｘ３［Ｋｃａｌ］の食事を摂り続けた場合に、血糖値が長期的に高くなっていく可能性が夫々１０％、５０％、８０％あるという予測が当該ユーザ又は不特定多数ユーザの大量な食事と生体情報の解析から成り立つとする。この場合、カロリー量ベクトルの推奨量、注意量、禁止量は、それぞれＸ１、Ｘ２、Ｘ３［Ｋｃａｌ］と設定できる。

　また、行列Ｃは第１サーバ２００ではなく情報端末１００で算出されてもよい。この場合、第１サーバ２００は、情報端末１００から行列Ｃの算出通知を取得したときに、行列Ｃの算出に必要なデータを情報端末１００に送信すればよい。

　ここでは、食事制約条件を構成する各種ベクトル及び病気情報＋生体情報を構成する各種ベクトルとして糖尿病で要求される各種ベクトルを示したが、実際には本開示が対象とするあらゆる病気を考慮して、各種ベクトルは設定される。例えば、痛風を考慮して、食事制約条件にプリン体ベクトルが含まれてもよい。このように、行列Ｃはどのような病気にも適用可能な成分値で構成されている。例えば、糖尿病であるが、痛風でないユーザにおいては、上述の学習を通じてプリン体に寄与する行列Ｃの成分値は０又は０に近い値に設定される。そのため、図３７の式（１）によって個々のユーザの病気に応じた食事制約条件が算出可能となる。さらに、図３７の式（１）によれば、病気情報＋生体情報からなる行列は現在のユーザの状態を示しているため、ユーザの病気の進行の程度に応じて適切な食事制約条件が算出可能である。ここでは、行列Ｃは本実施の形態が対象とするあらゆる病気を考慮して設定されているが、これは一例であり、糖尿病、痛風等、病気別に算出されたものであってもよい。この場合、第１サーバ２００及び情報端末１００は、病気毎に食事履歴情報を使い分けて行列Ｃを算出すればよい。

　行列Ｃを第１サーバ２００が算出する場合、図３０のステップＳ５０６において情報端末１００から病気情報及び／又は生体情報の取得要求を取得した場合、第１サーバ２００は病気情報にユーザに対応する最新の行列Ｃを含めて情報端末１００に送信すればよい。これにより、情報端末１００は最新の行列Ｃを用いて食事制約条件を算出することができる。

　行列Ｃは、ユーザの病気の進行に対応して逐次更新されてもよい。例えば、病気診断書の診断内容を含む情報２６００において、病気の段階を示す情報（例えば病型又は分類）が更新されたときに行列Ｃは更新されてもよい。さらに、食事制限の程度を示す情報は行列Ｃの更新と合わせて更新されてもよい。この場合、情報端末１００は上記の更新により算出済みの最新の食事制限の程度を示す情報を用いて個別メニューを生成すればよい。

　行列Ｃは健康診断の結果が取得されたとき、定期健康診断の診断結果（カルテ情報）が取得されたとき、又はユーザの生体センサー６００によりユーザの生体情報が取得されたとき、の少なくともいずれか１つのタイミングにおいて、逐次更新されてもよい。例えば、１日、２日、１週間、１か月等の所定期間において行列Ｃは算出されてもよいし、個別メニューを生成する際に行列Ｃは算出されてもよい。さらに、食事制限の程度を示す情報は行列Ｃの更新と合わせて更新されてもよい。この場合、情報端末１００は上記の更新により算出済みの最新の食事制限の程度を示す情報を用いて個別メニューを生成すればよい。

　図３８は、メニュー情報に含まれる各料理の優先度を算出するための式（２）を示す図である。この式（２）において、ｃ１、ｃ２、ｃ３、ｃ４はそれぞれ、カロリー、アルコール、塩分、食物繊維に対する料理評価の重み付け係数である。

　ｆ１（），ｆ２（），ｆ３（），ｆ４（）は、それぞれ、カロリー、アルコール、塩分、食物繊維に対して、メニュー情報に含まれる各料理とユーザの食事制約条件との合致度合いを求める関数である。カロリー量を例に挙げてこれらの関数について説明すると、ｆ１（カロリー量、カロリー量ベクトル）は、対象となる料理の食材情報２８００に含まれるカロリー量と、式（１）で算出したカロリー量ベクトルとの合致度合いを示す。カロリー量の合致度合いは、対象となる料理のカロリー量がカロリー量ベクトルの推奨量に近い値になるほど大きくなる。このことは塩分量についても同じである。アルコール量の合致度合いは、対象となる料理のアルコール量が許可量に近づく又は禁止量より小さくなるにつれて大きくなる。食物繊維量の合致度合いは対象となる料理の食物繊維量が推奨量に近づくにつれて又は必要量よりも増大するにつれて大きくなる。料理の栄養ベクトルは、対象となる料理のカロリー量、アルコール量、塩分量、及び食物繊維量を含む。これらの値は対象となる料理の食材情報２８００から特定可能である。

　情報端末１００は、式（１）で算出した食事制約条件を式（２）に適用することで、メニュー情報に含まれる各料理の優先度スコアを算出し、この優先度スコアが大きい料理ほど優先して表示されるように個別メニューを生成する。

　なお、図２３で説明した手法により今回の食事でのカロリーの摂取許容量が算出された場合、この今回の食事でのカロリーの摂取許容量からカロリー量ベクトルを算出し、算出したカロリー量ベクトルを式（２）に適用して各料理の優先度を算出してもよい。また、図２３で説明した手法を用いて、特定の食材における今回の食事での摂取許容量及び摂取目標量が算出された場合、情報端末１００は、今回の食事での摂取許容量及び今回の食事での摂取目標量から特定の食材に対応するベクトル（例えばアルコール量ベクトル、塩分量ベクトル、及び食物繊維量ベクトル）を算出する。そして、情報端末１００は算出した特定の食材に対応するベクトルを式（２）に代入して各料理の優先度を算出してもよい。

　これにより、情報端末１００は、ユーザの病気に関わる摂取が制限される栄養成分の量が少ない料理を、当該栄養成分の量が多い料理よりも優先して表示する個別メニューを生成できる。

　また、情報端末１００は、ユーザの病気に関わる摂取が推奨される栄養成分の量が多い料理を、当該栄養成分の量が少ない料理よりも優先して表示する個別メニューを生成できる。

　ここで、優先度を下げて表示することには、優先度が低い料理がディスプレイ１０５に表示されるまでのユーザの操作部１０６への操作又は操作回数を優先度が高い料理がディスプレイ１０５に表示されるまでのユーザの操作部１０６への操作又は操作回数よりも多くすること、優先度が低い料理の表示順序を優先度が高い料理の表示順序よりも下位にすること、優先度が低い料理の表示サイズを優先度が高い料理の表示サイズよりも小さくすること、優先度が低い料理の表示の濃さを優先度が高い料理の表示の濃さよりも薄くすること、の少なくともいずれか１つが含まれる。

　（個別メニューから注文をする際の情報処理の実装例）
　次に、個別メニューから料理を注文する場合の情報処理の実装例について説明する。情報通信のインターフェース及び取り扱うデータ構造がレストラン店舗に固有である場合、情報処理システムで取り扱われる各種データが、例えば、レストランＡ社の店舗４０では利用可能だが、レストランＢ社では使用できないといった事態、又はレストランＡ社の別店舗及びレストランＢ社の両方で使用できないという事態が生じ得る。このような事態を回避するために、多くのユーザが多くのレストランで個別メニューを用いた料理の注文を実施するめの汎用的なソリューションについて、以下説明する。

　図３９は、本実施の形態における情報処理システムの具体的な実装形態の一例を示す図である。情報端末１００のメモリ１０２には、マッチングアプリの実行に必要となるファイルの格納場所である「ｍａｔｃｈｉｎｇ＿ａｐｐ」ディレクトリがある。「ｍａｔｃｈｉｎｇ＿ａｐｐ」ディレクトリの下には、「ａｃｃｏｕｎｔ」ディレクトリ、「ｍａｉｎ」ディレクトリ、及び「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリがある。「ａｃｃｏｕｎｔ」ディレクトリにはユーザのアカウント及び／又はユーザ認証に必要な情報が格納される。「ｍａｉｎ」ディレクトリには、マッチングアプリがホーム画面の描画及びＱＲコードスキャンなどの基本機能を実現するために必要な情報が格納される。「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリには、マッチングに必要な情報が一時的に格納される。

　「ａｃｃｏｕｎｔ」ディレクトリには、アカウント及び／又はユーザ認証に必要な情報を記述した「ｕｓｅｒ＿ａｃｃｏｕｎｔ．ｘｍｌ」ファイルが格納される。「ｕｓｅｒ＿ａｃｃｏｕｎｔ．ｘｍｌ」ファイルには、例えばユーザを特定するための情報として、ユニークなアカウント名（例えば、ユーザが指定するユーザＩＤ）とその認証情報（例えば、パスワード、指紋の特徴量、及び／又は顔の特徴量）とが暗号化されて記録されている。

　アカウント名としてはユーザが指定するユーザＩＤに限定されず、マッチングアプリを利用するユーザを個別に識別可能な情報が採用されればよい。例えば、マッチングアプリのプログラムに埋め込まれた、又はマッチングアプリに付随して配布された、マッチングアプリの個体別にユニークなシリアルコードが採用されてもよい。個体別にユニークなシリアルコードとは、マッチングアプリをインストールする情報端末１００毎にユニークに付与されたシリアルコードである。或いは、アカウント名としては、マッチングアプリの初回起動時又は初回登録時に、マッチングアプリが乱数に基づいて生成したユニークなアカウント名が採用されてもよい。この場合、マッチングアプリは、例えば、既に登録済みアカウント名と重複していないことを第１サーバ２００に確認することで、アカウント名を自動生成すればよい。

　このようにアカウント名として人が見て無意味な文字列情報が設定されることにより、秘匿性がより高められた個人情報の通信が可能となる。個人情報に含まれる病気情報及び／又は生体情報のそれぞれは、後述するように複数のファイルに断片化されて管理される。上述したアカウント名は、断片化された各ファイルにおいてファイル名のｕｓｅｒＩＤ部分に採用されてもよい。或いは、上述したアカウント名と１対１にペアリングされた別の情報が、断片化された各ファイルのファイル名の一部（例えば、ユーザＩＤの部分）に採用されてもよい。

　「ｍａｉｎ」ディレクトリには、マッチングアプリの基本機能を実現するために必要なコンテンツ情報を記述した「ｍａｉｎ．ｈｔｍｌ」ファイルと、その画面表示のスタイル（例えば、ＵＩデザイン）を記述した「ｍａｉｎ．ｃｓｓ」ファイルとが格納されている。

　レストランＡ社の第２サーバ３００には、ＱＲコードの読み取りで得られた文字列が表すＵＲＬ（例えば、ｈｔｔｐ：／／ｒｅｓｔａｕｒａｎｔＡ．ｃｏｍ／ＱＲｏｒｄｅｒ－１８）にアクセスされた際に返信するファイル群が予め格納されている。このファイル群には、返信するコンテンツ情報を記述した「ＲｅｓＡ．ｈｔｍｌ」ファイルと、そのコンテンツ情報の画面表示のスタイル（例えば、ＵＩデザイン）を記述した「ＲｅｓＡ．ｃｓｓ」ファイルとがある。例えば図２８及び図２９に示す食材情報２８００は「ＲｅｓＡ．ｈｔｍｌ」ファイルに含まれてもよい。または「ＲｅｓＡ．ｈｔｍｌ」ファイルにて参照される外部ファイルに格納してもよい。

　第１サーバ２００には、このユーザの多種多様で膨大な個人情報が分散暗号化されて蓄積されている。例えば、本開示で利用したユーザの生体情報は、「ｕｓｅｒＩＤ＿ｈｅａｌｔｈｃａｒｅ＿ｂｉｏｌｏｇｉｃａｌ＿１．ｊｓｏｎ」ファイル、「ｕｓｅｒＩＤ＿ｈｅａｌｔｈｃａｒｅ＿ｂｉｏｌｏｇｉｃａｌ＿２．ｊｓｏｎ」ファイル、．．．、「ｕｓｅｒＩＤ＿ｈｅａｌｔｈｃａｒｅ＿ｂｉｏｌｏｇｉｃａｌ＿Ｎ．ｊｓｏｎ」ファイルというＮ個のＪＳＯＮフォーマットのファイルとして、第１サーバ２００内の物理的に異なるストレージ装置に保管されている。Ｎ個のファイルにおいて、ファイル名の先頭部分の「ｕｓｅｒＩＤ」は対象ユーザを特定するための識別情報であり、続く「ｈｅａｌｔｈｃａｒｅ」は健康に関する属性を有することを特定するための識別情報であり、続く「ｂｉｏｌｏｇｉｃａｌ」は生体情報を特定するための識別情報であり、最後の数字は分断したファイルの識別番号である。なお、病気情報も、上述の生体情報と同様に分散暗号化されており、ファイル名としてはｂｉｏｌｏｇｉｃａｌに代えて例えば病気情報であることを示すｓｉｃｋが採用される。

　第１サーバ２００は、ユーザの生体情報のリクエストを適切なパーミッション（例えば、アクセス許可情報）と共に受信できれば、これらＮ個のファイルから正しくデータを復元し、所定の記述フォーマット（．ｊｓｏｎ）に変換して「ｂｉｏｌｏｇｉｃａｌ．ｊｓｏｎ」ファイルを取得し、この「ｂｉｏｌｏｇｉｃａｌ．ｊｓｏｎ」ファイルを暗号化した「ｂｉｏｌｏｇｉｃａｌ．ｊｓｏｎ．ｅｎｃ」ファイルを、マッチングアプリへ返信できる。以上のことは、病気情報についても同じである。

　以下、図４０のフローチャートに従いながら、マッチングアプリがＨＴＭＬを用いて画面制御を行う場合のファイルの取り扱いについて説明する。図４０は、マッチングアプリが起動してから個別メニューを表示するまでのファイルに対するマッチングアプリの処理の一例を示すフローチャートである。

　ステップＳ６０１において、マッチングアプリが起動し、ホーム画面を描画する。マッチングアプリは、起動直後に「ｍａｉｎ」ディレクトリにある「ｍａｉｎ．ｈｔｍｌ」ファイルと「ｍａｉｎ．ｃｓｓ」ファイルとを用いてホーム画面を描画する。これにより、図１４に示すホーム画面Ｇ１０３が描画される。

　ステップＳ６０２において、マッチングアプリは、レストランＡ社の第２サーバ３００からメニュー情報を受信する。受信されたメニュー情報は、「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリの下に、「ＲｅｓＡ．ｈｔｍｌ」ファイルと「ＲｅｓＡ．ｃｓｓ」ファイルとして記録される。

　ステップＳ６０３において、マッチングアプリは、第１サーバ２００からユーザの暗号化された病気情報及び／又は生体情報を受信する。受信された病気情報及び／又は生体情報は、マッチングアプリにより復号され、「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリの下に、「ｂｉｏｌｏｇｉｃａｌ．ｊｓｏｎ」ファイル及び／又は「ｓｉｃｋ．ｊｓｏｎ」として記録される。

　ステップＳ６０４において、マッチングアプリは、このユーザの病気情報及び／又は生体情報から算出される食事制限の程度を示す情報に対応する個別メニューを、ＲｅｓＡ．ｈｔｍｌファイルを編集することで生成する。生成された個別メニューは、「Ｃｕｓｔｏｍ＿ＲｅｓＡ．ｈｔｍｌ」ファイルとして、新規に「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリの下に記録される。以上により、図３９に示されるように、「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリの下に「ｂｉｏｌｏｇｉｃａｌ．ｊｓｏｎ」ファイル、「ＲｅｓＡ．ｈｔｍｌ」ファイル、「Ｃｕｓｔｏｍ＿ＲｅｓＡ．ｈｔｍｌ」ファイル、及び「ＲｅｓＡ．ｃｓｓ」ファイルが記録される。さらに、図３９では図示が省略されているが、「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリの下に「ｓｉｃｋ．ｊｓｏｎ」ファイルが記録される。

　ステップＳ６０５において、マッチングアプリは、生成した個別メニューを、レストランＡ社が指定するスタイルで描画するために、「Ｃｕｓｔｏｍ＿ＲｅｓＡ．ｈｔｍｌ」ファイルと「ＲｅｓＡ．ｃｓｓ」ファイルとを用いて描画する。

　このようにＨＴＭＬ／ＣＳＳファイルを用いて各種画面が描画されている。そのため、単一のマッチングアプリから、不特定多数の事業者が提供する商品又はサービスのうち、ユーザの膨大且つ多様な個人情報と適合する商品又はサービスを提示する場合において、当該事業者が期待する情報を、当該事業者が期待するスタイル（例えば、ＵＩデザイン）で表示させることができる。

　個別メニューからの料理の注文が終了したユーザによって、表示画面がマッチングアプリのホーム画面に戻された時、又は個別メニューからの料理の注文が終了してから所定時間が経過した時、「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリに一時保管されていたファイルは安全のため全て消去されてもよい。

　（個別メニューのバリエーション）
　個別メニューは図１８に示したものに代えて下記のバリエーションが採用できる。図４１は、個別メニューの１つ目のバリエーションを含む操作画面Ｇ１０６の一例を示す図である。この個別メニューでは、各料理を示すタイルオブジェクト９０１について、表示順、サイズ、枠の太さ、枠の装飾、料理を示す画像のサイズ、料理を示す画像の周囲にその料理をデフォルメするマーク３５０１、料理名の文字列のサイズ、料理名の文字列に対するデフォルメ、及びお気に入りであることを示すハートマーク３５０２が設定されている。

　この個別メニューに対する設定は、後述する優先度にしたがって行われる。図４１の例では、レタスサンドウィッチとコーンスープの料理の優先度が最大であり、次に、減塩ラーメンと野菜餃子であった。そのため、個別メニューの初期表示画面において、レタスサンドウィッチのタイルオブジェクト９０１Ｃが１番上に配置され、減塩ラーメンと野菜餃子のタイルオブジェクト９０１Ｃは上から２番目に表示されている。ベジタブルカレーとウーロン茶は優先度が３番目であり、トマトソースパスタは優先度が４番目であるため、これらのタイルオブジェクト９０１Ｄは、タイルオブジェクト９０１Ｃの下に表示されている。なお、優先度が５番目以降の料理のタイルオブジェクト９０１はスクロール操作によりディスプレイ１０５内に表示させることが可能である。

　上位２つの料理のタイルオブジェクト９０１Ｃには、サイズがデフォルトのタイルオブジェクト９０１Ｄより大きく（例えば２倍）設定されて、枠を太くする装飾が施され、料理名を示す文字列を太くする装飾が施され、デフォルメするマーク３５０１が表示され、料理を示す画像のサイズがタイルオブジェクト９０１Ｄより大きく（例えば２倍）設定され、ハートマーク３５０２が表示されている。さらに、１行目のタイルオブジェクト９０１Ｃには、「４３０Ｋｃａｌ　塩分２ｇ未満」といったユーザにこの料理が相対的に低カロリーであり、且つ、塩分も相対的に少なめであることを伝えるメッセージが表示されている。これにより、食事制限のあるこの料理を注文することに対するユーザの不安を打ち消すことができる。２行目のタイルオブジェクト９０１Ｃには、「糖尿病・高血圧に苦しむ人へ」といったメッセージが表示されている。これにより、この料理が糖尿病及び高血圧のユーザに適した料理であることをユーザに訴求されている。これらのメッセージは、料理毎に予め定められた文言が採用されればよい。

　ここでは、タイルオブジェクト９０１Ｃの形式で表示される料理は上位２位までであったが、上位３位まで或いは上位４位までというように、タイルオブジェクト９０１Ｃの形式で表示される料理は上位２位までの料理に限定されない。

　図４１の例では、タイルオブジェクト９０１Ｃの横幅は操作画面Ｇ１０６の横幅とほぼ同じ大きさに設定されている。一方、タイルオブジェクト９０１Ｄの横幅はタイルオブジェクト９０１Ｃの横幅の約半分の大きさに設定されている。そのため、優先度が３位、４位のタイルオブジェクト９０１Ｄは同じ行に表示されている。優先度が５位以降のタイルオブジェクトも優先度が３位及び４位のタイルオブジェクト同様、２つのタイルオブジェクト９０１Ｄが同一行に位置するように、２つずつ優先度の順で配置されている。このとき、同一行において優先度が高いタイルオブジェクト９０１Ｄが例えば左、優先度が低いタイルオブジェクト９０１Ｄが例えば右に位置するように各タイルオブジェクト９０１Ｄが配置される。タイルオブジェクト９０１Ｃ及びタイルオブジェクト９０１Ｄの縦幅は同じサイズに設定されている。

　優先度に応じた個別メニューの表示を実現するために、演算部１０４は、メニュー情報を構成する各料理に対して式（２）を適用して優先度スコアを算出する。そして、演算部１０４は、予め定められた個別メニューのレイアウト情報にしたがって優先度スコアの大きい順に各料理のタイルオブジェクト９０１を配置することで個別メニューを含む操作画面Ｇ１０６の画像データを生成する。レイアウト情報としては、例えば、各料理について、優先度スコアに応じたタイルオブジェクト９０１の配置位置及び優先度スコアに応じた上述の装飾内容を規定する情報等が採用できる。

　生成された個別メニューの画像データのうち、先頭からディスプレイ１０５の表示エリア内の画像データが初期画面としてディスプレイ１０５に表示される。そして、演算部１０４は、ディスプレイをスクロールする操作が入力されると、個別メニューの表示エリアを下側にスライドさせていくことで、個別メニューをスクロール表示させればよい。

　図４１では、タイルオブジェクト９０１Ｃに対して、表示順、サイズ、枠の太さ、枠の装飾、料理を示す画像のサイズ、料理を示す画像の周囲にその料理をデフォルメするマーク３５０１、料理名の文字列のサイズ、料理名の文字列に対するデフォルメ、及びお気に入りであることを示すハートマーク３５０２が設定されているが、これらのうち少なくとも１つの設定が採用されてもよい。

　図４２は、個別メニューの２つ目のバリエーションを含む操作画面Ｇ１０６の一例を示す図である。この例では、優先度スコアが下位の料理における表示方法が示されている。図４２において、左側はユーザがタイルオブジェクト９０１を選択する前の操作画面Ｇ１０６を示し、右側はユーザがタイルオブジェクト９０１を選択した後の操作画面Ｇ１０６を示している。この個別メニューではユーザの病気を悪化させる可能性が高い料理については、その料理のタイルオブジェクト９０１内に注意を促す注意マーク３６０２が表示されている。そして、注意マーク３６０２を含むタイルオブジェクト９０１Ｅが指示体１００１によりタッチされると、注意点を説明する吹き出し枠３６０１がタッチされたタイルオブジェクト９０１Ｅに対応付けて表示される。ここでは、ラーメンＡセットのタイルオブジェクト９０１Ｅが選択され、この料理には、カロリー及び塩分が多量に含まれている。そのため、吹き出し枠３６０１には、この料理の総カロリー（１５００Ｋｃａｌ）と本日におけるこの料理を食する前の摂取可能な残りカロリー（１４００Ｋｃａｌ）とが含まれている。さらに、この吹き出し枠３６０１には、この料理の塩分（５ｇ）と、本日におけるこの料理を食する前の摂取可能な塩分の残り量（４．７ｇ）とが含まれている。これにより、この料理を注文すべきか否かの判断材料がユーザに提示される。その結果、ユーザは料理の注文をスムーズに行うことができる。

　これを実現するために、演算部１０４は、各料理について、式（２）で算出した優先度スコアが所定の第１閾値以下の料理については、そのタイルオブジェクト９０１に注意マーク３６０２を表示させる。そして、演算部１０４は、このタイルオブジェクト９０１がタッチされると、該当する料理の食材情報２８００から式（２）のｆ１（）～ｆ４（）に示す合致度合いが所定の基準合致度合い以下のパラメータを抽出し、抽出したパラメータに応じたメッセージを、吹き出し枠３６０１内に表示させればよい。さらに、演算部１０４は、図２３で説明した手法を用いて抽出したパラメータに対する現時点での本日の摂取許容量を算出し、吹き出し枠３６０１内に表示させればよい。

　演算部１０４は、注意マーク３６０２を個別メニューでのみ表示してもよいし、標準メニューにおいて表示してもよい。標準メニューにおいて、注意マーク３６０２を表示させる場合、演算部１０４は、個別メニューにおいて、標準メニューとは異なる表示態様で注意マーク３６０２を表示すればよい。例えば、個別メニューで表示される注意マーク３６０２は標準メニューで表示される注意マーク３６０２に対して大きなサイズで表示されてもよいし、目立つ色で表示されてもよいし、目立つ図柄で表示されてもよい。

　なお、式（２）で算出された優先度スコアが第１閾値より小さい第２閾値以下の料理について、演算部１０４は、その料理のタイルオブジェクト９０１に注意マーク３６０２に代えて図４３に示す禁止マーク３６０３を表示してもよい。或いは、式（２）で算出された優先度スコアが第１閾値より小さい第２閾値以下の料理について、演算部１０４は、その料理のタイルオブジェクト９０１を非表示にしてもよい。

　或いは、式（２）で算出された優先度スコアが第２閾値以下の料理について、演算部１０４は、その料理のタイルオブジェクト９０１に禁止マーク３６０３を表示した上で、指示体１００１による選択を禁止させてもよい。このとき、この料理のタイルオブジェクト９０１はグレイアウト表示されてもよい。図４３は、グレイアウト表示されたタイルオブジェクト９０１を含む操作画面Ｇ１０６の一例を示す図である。ここでは、タイルオブジェクト９０１Ｅに付された禁止マーク３６０３Ａは、グレイアウト表示されていないタイルオブジェクト９０１に付された禁止マーク３６０３を示している。タイルオブジェクト９０１Ｆに付された禁止マーク３６０３Ｂは、グレイアウト表示されたタイルオブジェクト９０１に付された禁止マーク３６０３を示している。禁止マーク３６０３Ａは禁止マーク３６０３Ｂよりも薄い色で表示されている。これは、タイルオブジェクト９０１Ｅ内に表示された料理を示す画像と禁止マーク３６０３Ａとの区別を容易にするためである。図４３では、禁止マーク３６０３Ａと禁止マーク３６０３Ｂとが両方同時に表示されているが、いずれか一方を表示する態様が採用されてもよい。

　タイルオブジェクト９０１Ｆは料理を示す画像が半透明表示されることで、グレイアウト表示されている。ここでは、料理名の文字列は半透明表示されていないが、この文字列も半透明表示されてもよい。

　注意マーク３６０２及び禁止マーク３６０３が表示されたタイルオブジェクト９０１が指示体１００１によってタッチされた場合、演算部１０４は、情報端末１００が備えるバイブレータを駆動して情報端末１００を振動させてもよい。これにより、ユーザに対して避けるべき食材が含まれている料理を選択したことをより分かりやすく伝えることが可能となる。

　図４４は、個別メニューの３つ目のバリエーションを含む操作画面Ｇ１０６の一例を示す図である。この個別メニューは、ユーザがある料理のタイルオブジェクト９０１を指示体１００１でタッチしたとき、そのユーザに対して不足しやすい栄養成分を含む料理の注文を提案するものである。図３８において、左側はユーザがタイルオブジェクト９０１を選択する前の操作画面Ｇ１０６を示し、右側はユーザがタイルオブジェクト９０１を選択した後の操作画面Ｇ１０６を示している。

　例えば、不足しやすい栄養成分として食物繊維が挙げられる。納豆は食物繊維を多く含んでいる。そこで、この例では、演算部１０４は、「きのこパスタ」のタイルオブジェクト９０１Ｇが指示体１００１によりタッチされたとき、納豆の追加注文を促す吹き出し枠３８０１をタイルオブジェクト９０１Ｇに対応付けて表示する。この吹き出し枠３８０１内には、「食物繊維が不足していますよ」とのメッセージに加えて、納豆を食することにより摂取される食物繊維量（＋３ｇ）と、納豆を食する前における本日における食物繊維の摂取目標量（あと７ｇ）とが表示されている。これにより、納豆を追加注文することで食物繊維が効率的に補えることがユーザに訴求される。

　さらに、この吹き出し枠３８０１内には、ＮＯボタン３８０４とＹＥＳボタン３８０５とが含まれている。ＹＥＳボタン３８０５が指示体１００１によりタッチされると、演算部１０４は、納豆が追加注文されたと判定し、注文内容を「きのこパスタ」単品から「きのこパスタ」と「納豆」との組み合わせに変更する。このような吹き出し枠３８０１が表示可能な料理はタイルオブジェクト９０１内に情報マーク３８０２が表示されていてもよい。

　一方、ＮＯボタン３８０４が指示体１００１によりタッチされると、演算部１０４は、注文内容を変更しない。

　演算部１０４は、例えば、ユーザの病気に応じて予め定められた食物繊維等のユーザが不足しがちな栄養成分の量が第３閾値を下回る料理であるか否かをその料理の食材情報２８００を参照することで判定し、第３閾値を下回ると判定した料理に対して情報マーク３８０２を付与すればよい。このように、情報マーク３８０２が付された料理が選択された場合、栄養バランスを高め病気の改善を支援するための提案が個別メニューを通じて行われる。

　（サーバでの個別メニューの生成）
　上記実施の形態では、個別メニューの生成は情報端末１００で行われたが、本開示はこれに限定されず第２サーバ３００で行われてもよい。以下、個別メニューが第２サーバ３００で生成される形態について詳細に説明する。

　図４５は、個別メニューが第２サーバ３００で生成される形態が採用された場合において、第１サーバ２００に生体情報がアップロードされる際の処理の一例を示すシーケンス図である。ステップＳ４５０１において、生体センサー６００は、第１サーバ２００との生体情報の共有を許可する設定を情報端末１００に送信する。以下の情報端末１００の処理は情報端末１００にインストールされた生体センサーアプリによって実行される。ステップＳ４５０２において、生体センサー６００は生体情報を取得する。この場合、生体センサー６００は生体情報の取得を繰り返し実行する。ステップＳ４５０３において、生体センサー６００は、繰り返し取得した生体情報を順次、情報端末１００に送信する。

　ステップＳ４５０４において、情報端末１００は生体センサー６００から順次送信された生体情報をメモリ６０２に順次蓄積する。ステップＳ４５０５において、情報端末１００は、生体センサー６００から順次送信された生体情報を順次第１サーバ２００へ送信する。ステップＳ４５０６において、第１サーバ２００は、受信した生体情報を生体情報の測定日時を示す測定日時情報と対応付けてメモリ２０３に蓄積する。以上により、ユーザにより生体情報の共有が許可された場合、生体センサー６００により測定された生体情報が繰り返し第１サーバ２００に蓄積されることになる。

　図４６は、個別メニューが第２サーバ３００で生成される形態が採用された場合において、第１サーバ２００が病気情報を取得する際の処理の一例を示すシーケンス図である。

　ステップＳ４６０１において、医療機関情報サーバ５００は、医師等の診断結果に基づいてユーザの病気情報を生成する。病気情報には、上述した定期健康診断の診断結果及び／又は病気診断の診断内容が含まれる。

　ステップＳ４６０２において、医療機関情報サーバ５００は、病気情報を第１サーバ２００に送信する。ステップＳ４６０３において、病気情報を受信した第１サーバ２００は、病気情報をメモリ２０３に記憶し、病気情報が追加されたことを情報端末１００に通知する。以上により医療機関情報サーバ５００において病気情報が生成される都度、生成された病気情報が第１サーバ２００に蓄積されることになる。

　図４７は、ユーザが第２サーバ３００に対して病気情報のアクセスが許可された場合の情報処理システムの処理の一例を示すシーケンス図である。

　ステップＳ４７０１において、レストランＡ社の第２サーバ３００は、第１サーバ２００に対して病気情報へのアクセス許可を申請する。ステップＳ４７０２において、第１サーバ２００はアクセス許可を情報端末１００に問い合わせる。ステップＳ４７０３において、情報端末１００は、問い合わせに対してアクセスを許可するユーザの選択指示を受け付ける。ステップＳ４７０４において、情報端末１００は、第１サーバ２００に対して、病気情報のアクセスがユーザに許可されたことを示すアクセス許可を通知する。

　ステップＳ４７０５において、第１サーバ２００は、第２サーバ３００に対してアクセス許可を通知する。ステップＳ４７０６において、第２サーバ３００は第１サーバ２００に対して病気情報を要求する。ステップＳ４７０７において、第１サーバ２００は病気情報を第２サーバ３００に送信する。

　図４８は、ユーザが第２サーバ３００に対して病気情報のアクセスが不許可にされた場合の情報処理システムの処理の一例を示すシーケンス図である。図４８において図４７と同一の処理には同一の処理番号が付されている。ステップＳ４７０２に続くステップＳ４８０１において、情報端末１００は、問い合わせに対してアクセスを不許可にするユーザの選択指示を受け付ける。ステップＳ４８０２において、情報端末１００は、第１サーバ２００に対して、病気情報のアクセスがユーザに不許可にされたことを示すアクセス不許可を第１サーバ２００に通知する。

　ステップＳ４８０３において、第１サーバ２００は、第２サーバ３００に対してアクセス不許可を通知する。ステップＳ４７０６に続くステップＳ４８０４において、第１サーバ２００は、第２サーバ３００に対して病気情報が送信できないことを示す要求エラーを送信する。

　図４９は、個別メニューが第２サーバ３００で生成される形態が採用された場合において、個別メニューが生成される際の情報処理システムの処理の一例を示すシーケンス図である。

　ステップＳ４９０１において、情報端末１００はユーザ認証を行う。この処理の詳細は図３０のステップＳ５０１と同じである。ステップＳ４９０２において、情報端末１００は、座席に配置されたＱＲコードを読み取る。この処理の詳細は図３０のステップＳ５０２と同じである。ステップＳ４９０３において、情報端末１００は、ＱＲコードを解析することで取得された第２サーバ３００の接続先情報を用いて第２サーバ３００に対して個別メニューの表示を要請する。

　ステップＳ４９０４において、第２サーバ３００は、第１サーバ２００に対して病気情報及び／又は生体情報を要求する。ステップＳ４９０５において、第１サーバ２００は、病気情報への第２サーバ３００のアクセス許可を確認する。ここでは、図４７の処理を通じてユーザにより第２サーバ３００による病気情報へのアクセスが許可されたものとする。ステップＳ４９０６において、第１サーバ２００は、該当するユーザの病気情報及び／又は生体情報をメモリ２０３から抽出し、第２サーバ３００に送信する。

　ステップＳ４９０７において、第２サーバ３００は、受信した病気情報及び／又は生体情報を式（１）に代入し、食事制約条件を算出する。ステップＳ４９０８において、第２サーバ３００は、算出した食事制約条件を式（２）に代入し、メニュー情報に含まれる各料理の優先度スコアを算出し、算出した優先度スコアにしたがって各料理のタイルオブジェクト９０１が配置された個別メニューを生成する。

　ステップＳ４９０９において、第２サーバ３００は生成した個別メニューを情報端末１００に送信する。ステップＳ４９１０において、情報端末１００は個別メニューを含む第２操作画面を表示し、注文する料理の選択指示を受け付ける。

　ステップＳ４９１１において、情報端末１００は、注文された料理を示す注文料理情報及びユーザの座席を示す席ＩＤを含む注文リクエストを第２サーバ３００に送信する。

　ステップＳ４９１２において、第２サーバ３００は、注文リクエストをレストランＡ社の店舗に設けられたディスプレイに表示する。これにより、店舗の従業員はディスプレイに表示された料理と席ＩＤとを確認して、注文された料理をユーザの座席に間違いなく配膳できる。

　ステップＳ４９１３において、第２サーバ３００は、現在の注文状況を情報端末１００に送信する。ステップＳ４９１４において、第２サーバ３００は、受信した注文リクエストに含まれる注文料理情報を第１サーバ２００に送信する。ステップＳ４９１５において、第１サーバ２００は、受信した注文料理情報にしたがって該当するユーザの食事履歴情報を更新する。

　図５０は、個別メニューが第２サーバ３００で生成される形態が採用された場合において、個別メニューの生成が拒否された場合の情報処理システムの処理の一例を示すシーケンス図である。図５０において図４９と同一の処理については同一の符号を付し、説明を省略する。

　ステップＳ４９０４に続くステップＳ５００１において、第１サーバ２００は、病気情報への第２サーバ３００のアクセス許可を確認する。ここでは、図４８の処理を通じてユーザにより第２サーバ３００による病気情報へのアクセスが不許可にされたものとする。ステップＳ５００２において、第１サーバ２００は病気情報及び／又は生体情報の要求が拒否されたことを示す要求エラーを第２サーバ３００に通知する。ステップＳ５００３において、第２サーバ３００は標準メニューを情報端末１００に送信する。ステップＳ５００４において、情報端末１００は標準メニューを表示し、注文する料理の選択指示を受け付ける。以後、図４９と同様、ステップＳ４９１１～ステップＳ４９１５の処理が実行され、注文した料理がユーザの座席に配膳される。

　上述した形態によれば、第２サーバ３００において個別メニューが生成されるため、情報端末１００の処理負担の軽減を図りつつ、ユーザが注文した料理を間違いなくユーザの座席に配膳できる。

　上記の説明は一例に過ぎず、本開示は当該技術者による様々な応用が適用されてもよい。

　上記実施の形態において、ユーザの座席とは椅子が想定されているが、本開示はこれに限定されず、立食形式のレストランにおいては、例えばユーザが料理を食べるテーブルの１区画が該当する。

　上記実施の形態において、食事制限の程度を示す情報は生体情報及び／又は病気情報に基づいて生成されているとした通り、生体情報のみから、もしくは病気情報のみから、生成されてもよい。

　上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されても良い。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されても良い。

　本開示の範囲は、上述の実施の形態に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本開示の範囲に含まれても良い。

　本開示にかかる制御方法の一例によれは、食事制限のあるユーザが避けるべき食材が考慮されて個別メニューが生成されるため、レストランに適用される料理の注文システムにおいて有用である。

１００　　　：情報端末
１０１　　　：通信部
１０２　　　：メモリ
１０３　　　：カメラ
１０４　　　：演算部
１０５　　　：ディスプレイ
１０６　　　：操作部
１０７　　　：近接通信部
２００　　　：第１サーバ
２０１　　　：通信部
２０２　　　：演算部
２０３　　　：メモリ
３００　　　：第２サーバ
３０１　　　：通信部
３０２　　　：演算部
３０３　　　：メモリ
５００　　　：医療機関情報サーバ
６００　　　：生体センサー

Claims (36)

1. 　ユーザを特定する識別情報に対応させて前記ユーザの生体情報を管理する第１サーバとネットワークを介して通信する情報端末の制御方法であって、
   　前記ユーザの前記情報端末のディスプレイに表示される第１操作画面を介して、レストランＩＤ及び前記ユーザの座席を示す席ＩＤを取得し、
   　前記レストランＩＤに基づき、前記レストランＩＤに対応するレストランに関連する第２サーバからネットワークを介して前記レストランが提供する１以上の料理を示すメニュー情報を取得し、
   　前記情報端末に格納された前記識別情報を前記第１サーバに送信し、前記識別情報に基づき、前記第１サーバから前記ユーザの生体情報を取得し、
   　前記ユーザの生体情報に基づき、前記ユーザの病気の進行による食事制限の程度を示す情報を生成し、
   　前記メニュー情報及び前記食事制限の程度を示す情報に基づいて、前記食事制限の程度を示す情報に対応した前記ユーザの個別メニューを生成し、
   　前記ユーザの情報端末のディスプレイに表示された前記レストランにおける料理の注文を受け付けるための第２操作画面を介して、前記個別メニューを表示し、
   　前記個別メニューにて選択された料理を示す注文料理情報及び前記席ＩＤを前記第２サーバに送信することを含む、
   　制御方法。
2. 　前記個別メニューは、前記メニュー情報及び前記食事制限の程度を示す情報に基づき、前記メニュー情報に含まれる各料理において前記食事制限の程度を示す情報が示す前記ユーザが避けるべき食材を減少させて生成された料理を含む、
   　請求項１記載の制御方法。
3. 　前記食材を減少させることには、前記食材の量をゼロにすることを含む、
   　請求項２記載の制御方法。
4. 　前記個別メニューは、前記メニュー情報及び前記食事制限の程度を示す情報に基づき、前記メニュー情報に含まれる各料理において前記食事制限の程度を示す情報が示す前記ユーザが避けるべき食材を含む料理を除外またはグレイアウトさせて生成される、
   　請求項１記載の制御方法。
5. 　前記個別メニューは、前記１以上の料理において、前記ユーザの病気の進行に対応する不足しやすい栄養成分を含む食材を追加した一の料理を含む、
   　請求項１に記載の制御方法。
6. 　前記個別メニューは、前記ユーザの病気の進行に対応する不足しやすい栄養成分を補うための料理の組合せを示す表示を含む、
   　請求項１に記載の制御方法。
7. 　前記個別メニューは、前記１以上の料理において、所定期間における前記ユーザの過去の食事において、前記ユーザが不足していた栄養成分を含む食材を追加した一の料理を含む、
   　請求項１に記載の制御方法。
8. 　前記個別メニューは、所定期間における前記ユーザの過去の食事において、前記ユーザが不足していた栄養成分を補うための料理の組合せを示す表示を含む、
   　請求項１に記載の制御方法。
9. 　前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、
   　前記個別メニューは、前記１以上の料理の中で、前記今回の食事での摂取許容量を超える前記特定の栄養成分を含む一の料理において、前記特定の栄養成分の量を前記今回の食事での摂取許容量以下にしたものを含む、
   　請求項１記載の制御方法。
10. 　前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取目標量を示す情報を含み、前記今回の食事での摂取目標量を示す情報は、所定期間における摂取目標量から前記所定期間における過去の食事での累積摂取量を引いた量以上を示し、
    　前記個別メニューは、前記１以上の料理の中で、前記今回の食事での摂取目標量未満の前記特定の栄養成分を含む一の料理において、前記特定の栄養成分の量を前記今回の食事での摂取目標量以上にしたものを含む、
    　請求項１記載の制御方法。
11. 　前記食事制限の程度を示す情報は、前記ユーザの病気に対応する今回の食事でのカロリーの摂取許容量を示す情報を含み、前記今回の食事でのカロリーの摂取許容量を示す情報は、所定期間におけるカロリーの摂取許容量から前記所定期間における過去の食事でのカロリーの累積摂取量を引いた量以下を示し、
    　前記個別メニューは、前記１以上の料理の中で、前記今回の食事でのカロリーの摂取許容量を超えるカロリーを含む一の料理において、前記今回の食事でのカロリーの摂取許容量以下にしたものを含む、
    　請求項１記載の制御方法。
12. 　前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、
    　前記個別メニューは、前記１以上の料理において、前記今回の食事での摂取許容量を超える前記特定の栄養成分を含む一の料理を除外又はグレイアウトさせて生成される、
    　請求項１記載の制御方法。
13. 　前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取目標量を示す情報を含み、前記今回の食事での摂取目標量を示す情報は、所定期間における摂取目標量から前記所定期間における過去の食事での累積摂取量を引いた量以上を示し、
    　前記個別メニューは、前記１以上の料理の中で、前記今回の食事での摂取目標量未満の前記特定の栄養成分を含む一の料理を除外又はグレイアウトさせて生成される、
    　請求項１記載の制御方法。
14. 　前記食事制限の程度を示す情報は、前記ユーザの病気に対応する今回の食事でのカロリーの摂取許容量を示す情報を含み、前記今回の食事でのカロリーの摂取許容量を示す情報は、所定期間におけるカロリーの摂取許容量から前記所定期間における過去の食事でのカロリーの累積摂取量を引いた量以下を示し、
    　前記個別メニューは、前記１以上の料理において、前記今回の食事でのカロリーの摂取許容量を超える料理を除外又はグレイアウトさせて生成される、
    　請求項１記載の制御方法。
15. 　前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、
    　前記個別メニューは、前記１以上の料理の中で、前記今回の食事での摂取許容量を超える前記特定の栄養成分を含む一の料理において、前記特定の栄養成分と同時に摂取することで前記摂取許容量を超える前記特定の栄養成分による悪影響を中和させる効果がある栄養成分を含む食材を追加したものを含む、
    　請求項１に記載の制御方法。
16. 　前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、
    　前記個別メニューは、前記今回の食事での摂取許容量を超える前記特定の栄養成分を含む料理と、前記特定の栄養成分と同時に摂取することで前記摂取許容量を超える前記特定の栄養成分による悪影響を中和させる効果がある栄養成分を含む料理との組み合わせを示す表示を含む、
    　請求項１に記載の制御方法。
17. 　前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取許容量を示す情報を含み、前記今回の食事での摂取許容量を示す情報は、所定期間における摂取許容量から前記所定期間における過去の食事での累積摂取量を引いた量以下を示し、
    　前記個別メニューは、前記今回の食事での摂取許容量以下となる料理の組合せを示す表示を含む、
    　請求項１記載の制御方法。
18. 　前記食事制限の程度を示す情報は、前記ユーザの病気に関わる特定の栄養成分に対応する今回の食事での摂取目標量を示す情報を含み、前記今回の食事での摂取目標量を示す情報は、所定期間における摂取目標量から前記所定期間における過去の食事での累積摂取量を引いた量以上を示し、
    　前記個別メニューは、前記今回の食事での摂取目標量以上となる料理の組合せを示す表示を含む、
    　請求項１記載の制御方法。
19. 　前記食事制限の程度を示す情報は、前記ユーザの病気に対応する今回の食事でのカロリーの摂取許容量を示す情報を含み、前記今回の食事でのカロリーの摂取許容量を示す情報は、所定期間におけるカロリーの摂取許容量から前記所定期間における過去の食事でのカロリーの累積摂取量を引いた量以下を示し、
    　前記個別メニューは、前記今回の食事でのカロリーの摂取許容量以下となる料理の組合せを示す表示を含む、
    　請求項１記載の制御方法。
20. 　前記個別メニューは、第１料理と、前記第１料理よりも優先度を下げて表示する第２料理とを含み、前記第２料理に含まれる前記ユーザの病気に関わる摂取が制限される栄養成分の量は、前記第１料理に含まれる前記ユーザの病気に関わる前記摂取が制限される栄養成分の量よりも多い、
    　請求項１に記載の制御方法。
21. 　前記個別メニューは、第１料理と、前記第１料理よりも優先度を下げて表示する第２料理とを含み、前記第２料理に含まれる前記ユーザの病気に関わる摂取が推奨される栄養成分の量は、前記第１料理に含まれる前記ユーザの病気に関わる前記摂取が推奨される栄養成分の量よりも少ない、
    　請求項１に記載の制御方法。
22. 　前記優先度を下げて表示することには、前記第２料理の表示順序を前記第１料理の表示順序よりも下位にすること、前記第２料理の表示サイズを前記第１料理の表示サイズよりも小さくすること、又は前記第２料理の表示の濃さを前記第１料理の表示の濃さよりも薄くすること、の少なくともいずれか１つを含む、
    　請求項２０又は２１に記載の制御方法。
23. 　前記食事制限の程度を示す情報は、前記ユーザの病気の進行に対応して逐次更新される、
    　請求項１～２２のいずれか１項に記載の制御方法。
24. 　前記食事制限の程度を示す情報は、健康診断の結果の取得、診断時のカルテ情報の取得、又は前記ユーザの生体情報を検知する生体センサーによる前記ユーザの生体情報の取得、の少なくともいずれか１つに基づいて、逐次更新される、
    　請求項１～２３のいずれか１項に記載の制御方法。
25. 　さらに、前記個別メニューにて選択された料理の料理名を示す情報、前記個別メニューにて選択された料理の価格を示す情報、前記個別メニューにて選択された料理が注文された日時を示す情報、及び前記個別メニューにて選択された料理に含まれる栄養成分を示す情報、を前記第１サーバに送信する、
    　請求項１～２４のいずれか１項に記載の制御方法。
26. 　前記識別情報は、ユーザＩＤを含む、
    　請求項１記載の制御方法。
27. 　前記第１サーバは、前記第２サーバと異なる、
    　請求項１記載の制御方法。
28. 　前記レストランＩＤ及び前記席ＩＤは、前記第１操作画面を介して、前記ユーザが着席したテーブルの対応位置に用意された識別コードを読み取ることで、取得される、
    　請求項１記載の制御方法。
29. 　前記識別コードは、ＱＲコードを含む、
    　請求項２８記載の制御方法。
30. 　前記識別コードは、ＮＦＣ（Ｎｅａｒ　Ｆｉｅｌｄ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を用いて読み取られる、
    　請求項２８記載の制御方法。
31. 　前記第１サーバは、生体情報、前記ユーザの物品の購買履歴情報又は料理の注文履歴情報を含む嗜好情報、及び前記ユーザの位置情報を含む行動履歴情報を分散管理する、
    　請求項１～３０のいずれか１項に記載の制御方法。
32. 　請求項１～３１のいずれか１項に記載の制御方法を実行する情報端末。
33. 　請求項１～３１のいずれか１項に記載の制御方法を前記情報端末のコンピュータに実行させるためのプログラム。
34. 　前記ユーザを特定する識別情報は、前記プログラムに付与された情報端末毎のシリアルコードを含む、
    　請求項３３に記載のプログラム。
35. 　請求項１～３１のいずれか１項に記載の制御方法を前記情報端末のコンピュータに実行させるためのプログラムを記録した記録媒体。
36. 　ユーザを特定する識別情報に対応させて前記ユーザの生体情報を管理する第１サーバと通信し、一のレストランに対応する１以上の料理を示すメニュー情報を格納する第２サーバを含む健康管理システムにおける情報提供方法であって、
    　前記ユーザの情報端末からネットワークを介して前記ユーザの座席を示す席ＩＤを取得し、前記席ＩＤは、前記情報端末のディスプレイに表示される操作画面を介して取得されたものであり、
    　前記情報端末に格納された前記識別情報を前記情報端末からネットワークを介して取得し、
    　前記第１サーバから、ネットワークを介して前記ユーザの生体情報を取得し、
    　前記ユーザの生体情報に基づき、前記ユーザの病気の進行による食事制限の程度を示す情報を生成し、
    　前記メニュー情報及び前記食事制限の程度を示す情報に基づいて、前記食事制限の程度を示す情報に対応した前記ユーザの個別メニューを生成し、
    　前記個別メニューを前記情報端末に送信し、前記情報端末において前記個別メニューに基づき料理を選択される、
    　情報提供方法。

Images