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

Abstract

制御方法は、レストランＩＤに基づき、レストランＩＤに対応するレストランに関連する第２サーバからネットワークを介して前記レストランが提供する１以上の料理を示すメニュー情報を取得し、情報端末に格納された識別情報を第１サーバに送信し、識別情報に基づき、第１サーバから分類情報を取得し、メニュー情報及び分類情報に基づき、分類情報に対応したユーザの個別メニューを生成し、ユーザの情報端末のディスプレイに表示されたレストランにおける料理の注文を受け付けるための第２操作画面を介して、個別メニューを表示し、個別メニューにて選択された料理を示す注文料理情報及び席ＩＤを第２サーバに送信する。

Description

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

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

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

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

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

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

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

一般的な料理の注文システムの構成を示す図である。 本開示の情報処理システムの情報基盤の全体像の一例を示す図である。 本実施の形態の情報処理システムの全体像をより詳しく示す図である。 本実施の形態に係る情報処理システムの具体的な構成の一例を示す図である。 レストランのある店舗のレイアウトを示した図である。 座席に対するＱＲコード（登録商標、以下同様）の設置例を示す図である。 座席に対するＱＲコードの設置例を示す図である。 座席に対するＱＲコードの設置例を示す図である。 座席に対するＱＲコードの設置例を示す図である。 ユーザがＱＲコードを情報端末に読み取らせる場合に情報端末に表示される操作画面の一例を示す図である。 ＱＲコードリーダーがＱＲコードを読み取った直後の情報端末に表示される操作画面の一例を示す図である。 レストランＡ社の標準メニューを含む操作画面の一例を示す図である。 ユーザが操作画面を操作して標準メニューから料理を注文するシーンの一例を示した図である。 標準メニューから注文する料理を最終的に決定する際に表示される操作画面の一例を示す図である。 料理を注文するユーザがマッチングアプリを起動した直後に情報端末に表示される認証画面の一例を示す図である。 認証画面の他の一例を示す図である。 マッチングアプリによるユーザ認証が終わった直後に表示されるホーム画面の一例を示す図である。 マッチングアプリを起動したユーザが自席に対応するＱＲコードを情報端末に読み取らせる場合に情報端末に表示される操作画面の一例を示す図である。 ＮＦＣによりレストランＩＤ及び席ＩＤを取得する場合に情報端末に表示される操作画面の一例を示す図である。 マッチングアプリが個別メニューを生成している際に情報端末に表示される表示画面の一例を示す図である。 個別メニューを含む操作画面の一例を示す図である。 ユーザが操作画面を操作して個別メニューから料理を注文するシーンを示した図である。 個別メニューから注文する料理を最終的に決定する際に表示される操作画面の一例を示す図である。 これまでの注文履歴をユーザが確認する時に表示される注文履歴画面の一例を示す図である。 ベジタリアンの分類と、各分類に応じたユーザの避けるべき食材をまとめた表である。 第１サーバからマッチングアプリへ返信されるユーザの分類情報を含む情報のデータ構成の一例を示す図である。 第２サーバから返信されるメニュー情報を構成する食材情報のデータ構成の一例を示す図である。 ラーメンと野菜餃子の食材情報の一例を示す図である。 本実施の形態における情報処理システムの処理の全体像の一例を示すシーケンス図である。 標準メニューから料理が注文される場合の情報端末の処理の一例を示すフローチャートである。 個別メニューから料理が注文される場合の情報端末の処理の一例を示すフローチャートである。 図２８のステップＳ１の処理の詳細を示すフローチャートである。 図２８のステップＳ２の処理の詳細を示すフローチャートである。 図２８のステップＳ３の処理の詳細を示すフローチャートである。 図２８のステップＳ４の処理の詳細を示すフローチャートである。 本実施の形態における情報処理システムの具体的な実装形態の一例を示す図である。 マッチングアプリが起動してから個別メニューを表示するまでのファイルに対するマッチングアプリの処理の一例を示すフローチャートである。 個別メニューの１つ目のバリエーションを含む操作画面の一例を示す図である。 個別メニューの２つ目のバリエーションを含む操作画面の一例を示す図である。 グレイアウト表示されたタイルオブジェクトを含む操作画面の一例を示す図である。 個別メニューの３つ目のバリエーションを含む操作画面の一例を示す図である。

（本開示に至る経緯）
近年、食及び健康に対する意識の高まり並びに動物愛護に対する意識の高まり等から菜食主義者（ベジタリアン）と称される人達が増加している。レストランはベジタリアンの客に対しては、ベジタリアンが食することが可能な料理を主に含むメニューを提案すれば、顧客満足度が向上し、他のレストランとの差別化を図ることが可能となる。

しかしながら、一口にベジタリアンといっても、植物性食品のみを食するヴィーガン、植物性食品に加えて乳及び乳製品を食するラクトベジタリアン、並びに植物性食品、乳、及び乳製品に加えて卵を食するラクトオボベジタリアン等、様々である。したがって、このような多様な分類を持つベジタリアンに応じたメニューを提案することは容易ではない。

さらに、ベジタリアンでない客が注文した料理であってベジタリアンが避けるべき食材を含む料理が間違えて、同じテーブルに座っているベジタリアンの客の席に配膳されると、ベジタリアンの客に不快感を与えてしまう。さらに、ベジタリアンである客がそのような料理であることを気付かず、その料理を食してしまった場合、普段食べ慣れていない食材を食したために、その客の健康を害するおそれもある。したがって、このような配膳ミスは回避しなければならない。

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

しかしながら、特許文献１では、メニュー端末にはテーブル毎にユニークなテーブル番号が設定されていることからも明らかなように、テーブル単位での料理の注文のみが考慮されており、座席単位での料理の注文は何ら考慮されていない。そのため、特許文献１は、ベジタリアンでない客が注文した食肉等を含む料理が同一テーブルに座っているベジタリアンの座席に間違って配膳される配膳ミスが発生する可能性がある。

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

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

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

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

本開示は、上記の課題を解決するためになされたものであり、ベジタリアンが避けるべき食材を含む料理が間違ってベジタリアンの席に配膳されることを防止することを第１の目的とする。

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

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

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

取得されたメニュー情報及びユーザの分類情報に基づいて分類情報に対応するユーザの個別メニューが生成される。この個別メニューは、第２操作画面を介して情報端末のディスプレイに表示される。表示された個別メニューの中から料理が選択され、その料理を示す注文料理情報が席ＩＤと対応付けられて第２サーバに送信される。

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

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

上記制御方法において、前記個別メニューは、前記メニュー情報及び前記分類情報に基づき、前記メニュー情報に含まれる各料理において前記分類情報に対応する避けるべき食材を含む料理を除外又はグレイアウトさせて生成されてもよい。

本態様によれば、菜食主義者であるユーザが避けるべき食材（例えば、食肉）を含む料理が除外又はグレイアウトされた個別メニューが生成されるため、当該ユーザは、避けるべき食材を含む料理を意識せずに、或いはそのような料理を容易に確認でき、料理の注文をスムーズに行うことができる。

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

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

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

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

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

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

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

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

上記制御方法において、前記個別メニューは、前記１以上の料理において、前記菜食主義者の分類に対応する避けるべき食材を別の食材に置換した料理を含んでもよい。

本態様によれば、菜食主義者の分類情報に対応する避けるべき食材が別の食材に置換された料理を含む個別メニューが生成されるため、個別メニューにおいて、菜食主義者であるユーザが食することが可能な料理のバリエーションを増やすことができる。

上記制御方法において、前記別の食材は、植物由来の材料を用いた代替肉、又は動物細胞を培養して食品として加工された培養肉の少なくともいずれか一つを含んでもよい。

本態様によれば、置換された別の食材として、植物由来の材料を用いた代替肉又は培養肉が用いられるため、代替肉の摂取を許容する菜食主義者であるユーザ又は動物愛護の観点から菜食主義者になったユーザが食することが可能な料理を提案できる。

上記制御方法において、前記別の食材は、前記菜食主義者の分類に対応する不足しやすい栄養成分を含んでもよい。

本態様によれば、置換された別の食材として、菜食主義者の分類情報に対応する不足しやすい栄養成分を含む食材が用いられるため、菜食主義者の健康を気遣った料理を提案できる。

上記制御方法において、前記分類情報は、前記ユーザが属する菜食主義者の分類、及び、前記菜食主義者の分類に対応する避けるべき食材に関して前記避けるべき食材の程度を示すレベル情報を含んでもよい。

本態様によれば、分類情報には、ユーザが属する菜食主義者の分類、及び、菜食主義者の分類情報に対応する避けるべき食材に関して避けるべき食材の程度を示すレベル情報が含まれている。そのため、菜食主義者の分類及び避けるべき食材の程度を考慮に入れて、メニュー情報に含まれる各料理の優先度をきめ細かく決定し、個別メニューを生成できる。

上記制御方法において、前記個別メニューの表示から前記レストランの一般メニューの表示に切り替える指示を受け付けると、前記第２操作画面を介して前記一般メニューを表示してもよい。

菜食主義者であるユーザによっては、例えば友人と食事する場合は菜食主義をやめたり、週末だけ菜食主義者になったりする者もいる。本態様によれば、第２操作画面は個別メニューから一般メニューへ切り替え可能に構成されるため、このようなユーザのニーズに柔軟に対応することができる。

上記制御方法において、前記個別メニューは、前記ユーザが可能な限り避けるべき食材を含む料理、を含んでもよい。

本態様によれば、個別メニューにはユーザが可能な限り避けるべき食材を含む料理が含まれているため、菜食主義を厳格に貫かないユーザのニーズに応じた個別メニューを生成できる。

上記制御方法において、前記菜食主義者の分類は、ヴィーガン、ラクトベジタリアン、オボベジタリアン、及びラクトオボベジタリアンを含んでもよい。

本態様によれば、菜食主義者の分類としてヴィーガン、ベジタリアン、オボベジタリアン、及びラクトオボベジタリアンが採用されるため、これらの分類に応じて適切な個別メニューをきめ細かに生成できる。

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

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

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

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

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

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

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

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

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

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

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

本態様によれば、第１サーバは、生体情報、分類情報、及び行動履歴情報を分散管理するため、ユーザの個人情報が随時取得可能である。その結果、本態様は、第１サーバに記憶される個人情報の鮮度を保つことが可能となり、これにより、過去の分類情報に基づいて個別メニューが作成されることを防止できる。

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

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

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

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

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

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

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

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

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

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

携帯端末１２００は、店舗１０００を訪れたユーザが保有するスマートフォン等の携帯端末である。携帯端末１２００は、外部機器との通信を行うための通信部、演算処理を行うための演算部、データを記億するためのメモリ、情報を表示及び操作するためのＵＩ部を含む。メモリは、携帯端末１２００を保有するユーザが属するベジタリアンの分類を示す分類情報及び食事履歴情報等を記憶する。この分類情報には分類に応じてユーザが避けるべき食材に関する情報が含まれている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パブリック情報サーバ５００は、レストランに関する情報及び個人情報とは異なる公共情報を管理する。パブリック情報サーバ５００はインターネットに接続されている。例えば、公共情報には、天気情報、及び交通情報などが含まれる。これらの情報はマッチングにおいて必要があれば、適宜利用される。

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

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

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

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

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

メモリ１０２は、フラッシュメモリ等の不揮発性のストレージ装置で構成されている。メモリ１０２は、図２３に例示される分類情報を含む情報２３００と、図２４及び図２５に例示される食材情報２４００を記憶する。１つの食材情報２４００は１つの料理に対応しており、料理に使用される食材に関する情報である。メニュー情報は１以上の食材情報２４００によって構成される。情報２３００及び食材情報２４００の詳細は後述する。さらに、メモリ１０２はユーザを特定する識別情報を記憶する。識別情報はユーザＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）が含まれる。ユーザＩＤはユーザの識別子である。

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

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

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

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

演算部１０４は、メモリ１０２に記憶された識別情報を第１サーバ２００に送信し、識別情報に基づき、第１サーバ２００からユーザの分類情報を取得し、メモリ１０２に記憶する。

演算部１０４は、取得したメニュー情報及び取得した分類情報に基づき、分類情報に対応したユーザの個別メニューを生成する。個別メニューには、演算部１０４が取得したメニュー情報に含まれる各料理において、分類情報に対応する避けるべき食材を含む料理を除外またはグレイアウトさせて生成される。これにより、ユーザは避けるべき食材を含まない料理をスムーズに注文できる。

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

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

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

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

近接通信部１０７は、ＮＦＣの通信機能を備える通信回路で構成され、ＮＦＣの通信機能を有するＩＣチップから情報を読み込んだり、当該ＩＣチップに情報を書き込んだりすることができる。

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

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

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

メモリ２０３が記憶する個人情報には、生体情報と、購買履歴情報と、嗜好情報、及び行動履歴情報が含まれていてもよい。生体情報は心拍数等の各ユーザの生体に関する情報である。生体情報には、ユーザのアレルギー情報等が含まれる。購買履歴情報は、各ユーザの商品（物品）又はサービスの購買履歴を示す情報である。嗜好情報は、各ユーザの嗜好を示す情報である。嗜好情報には、各ユーザの料理の注文履歴を示す注文履歴情報が含まれる。行動履歴情報は、各ユーザの行動履歴を示す情報である。行動履歴情報は、例えば、ユーザの位置情報と時刻情報とが対応付けられた時系列データで構成される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、マッチングアプリが第２サーバ３００から、分類情報を取得する処理を説明する。この処理は、図２８のステップＳ３に対応する。

メニュー情報のデータ属性が食属性であると判断したマッチングアプリは、食属性に分類されるユーザの食事制約条件である最新の分類情報の取得を第１サーバ２００に要求する。この要求には、ユーザＩＤが含まれる。この要求を受信した第１サーバ２００は、分散暗号化された個人情報の中から最新の分類情報をユーザＩＤに基づいて抽出する。抽出された分類情報は、第１サーバ２００から情報端末１００へ送信される。これにより、マッチングアプリは、分類情報を取得する。分類情報の詳細については、図２３を用いて後述する。

分類情報を取得した情報端末１００は、レストランＡ社のメニュー情報と分類情報とを照合し、個別メニューを生成する処理を実行する。この処理は図２８のステップＳ４に対応する。このとき、情報端末１００には依然、図１７に示す表示画面Ｇ１０５が表示されているが、マッチングアプリは、メニュー情報と分類情報とを照合し、分類情報に対応する個別メニューを生成する処理を実行している。

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

１つ目のバリエーションでは、演算部１０４は、メニュー情報及び分類情報に基づき、メニュー情報に含まれる各料理において分類情報に対応する避けるべき食材を含む料理を除外又はグレイアウトする個別メニューを生成する。例えばユーザの避けるべき食材が牛肉であるユーザであり、メニュー情報にビーフカレーが含まれていたとする。この場合、ビーフカレーを示すタイルオブジェクト９０１が個別メニューから除外される、或いはグレイアウトされる。グレイアウトとは、ビーフカレーのタイルオブジェクト９０１を例えばグレイ色で半透明表示させる表示方法である。なお、分類情報には図２３で後述するように避けるべき食材に関する情報が含まれているため、演算部１０４は、この分類情報から避けるべき食材を特定できる。

２つ目のバリエーションでは、演算部１０４は、ベジタリアンの分類に対応する不足しやすい栄養成分を含む食材を追加した一の料理を含む個別メニューを生成する。ベジタリアンは図２２に示すようにヴィーガン及びオボベジタリアン等に分類され、各分類において不足する栄養成分はおよそ推定できる。したがって、演算部１０４は、分類に応じて不足しやすい栄養成分を予めメモリ１０２に記憶させておき、その栄養成分を含む料理を個別メニューに含めればよい。一の料理とはある一つの料理のことを意味する。不足しやすい栄養成分を含む食材を追加する一例としては、ビタミンＢ１２が不足しやすいヴィーガン向けのパスタに、藻類（味付けのり）を刻んで加えておくことが挙げられる。

３つ目のバリエーションでは、演算部１０４は、ベジタリアンの分類に対応する不足しやすい栄養成分を補うための料理の組合せを示す表示を含む個別メニューを生成する。図２２に示すようにベジタリアンはいずれの分類においても鉄分が不足しがちである。小松菜のおひたし及び納豆は鉄分を多く含んでいる。したがって、このバリエーションの一例としては、小松菜のおひたしの小鉢又は納豆の小鉢を含むセット料理を個別メニューに含ませることが挙げられる。或いは、この一例としては、図３８で後述するように、個別メニューにおいてユーザがある料理を選択すると、その料理に加えて不足する栄養成分を含む料理の注文をユーザに促す画面をディスプレイ１０５に表示することが挙げられる。この場合、演算部１０４は、料理ごとに予め定められた不足しやすい栄養成分を含む料理を、ユーザに注文を促す料理として決定すればよい。

その他、不足しやすい栄養成分を補うための料理の組み合わせの一例としては、鉄分摂取量を高めるためにビタミンＣを多く含む料理を、鉄分を含む料理と合わせて食するセット料理が挙げられる。

さらに、不足しやすい栄養成分を補うために料理の調理法が変更されてもよい。例えば、演算部１０４は、ビタミン摂取量を高めるために食材の加熱温度と加熱時間とを抑えるように料理の調理法を変更するよう対応するレストランの第２サーバ３００に指示してもよい。

４つ目のバリエーションでは、演算部１０４は、所定期間におけるユーザの過去の食事において、ユーザにとって不足していた栄養成分を含む食材を追加した一の料理を含む個別メニューを生成する。所定期間とは、現在から１週間又は１か月等の期間である。ベジタリアンが不足しやすい栄養成分は、分類に応じておよそ推定できることは２つ目のバリエーションで上述したとおりである。この推定は、所定期間における不足しやすい栄養成分の推定についても同様に適用可能である。したがって、演算部１０４は、分類に応じて所定期間における不足しやすい栄養成分を予めメモリ１０２に記憶させておき、その栄養成分を含む料理を個別メニューに含めればよい。

或いは、演算部１０４は、所定期間における料理の注文履歴情報を第１サーバ２００から取得し、その注文履歴情報から該当するユーザにとって不足している栄養成分を特定してもよい。例えば、注文履歴情報には、ユーザが過去に注文した料理に関する情報が含まれている。料理に関する情報には、例えば料理名に加えて各料理に使用される食材及びその量が含まれる。食材及び食材の量が分かれば、食材に含まれる各栄養成分及び各栄養成分の量も特定可能である。そこで、演算部１０４は、注文履歴情報に含まれる料理毎にユーザが摂取した栄養成分と各栄養成分の量とを特定し、特定した各栄養成分の量の所定期間における累計値を算出する。そして、演算部１０４は、その累積値が栄養成分毎に予め定められた閾値を下回るか否かを判定し、下回ると判定した栄養成分を不足する栄養成分として特定すればよい。

５つ目のバリエーションでは、演算部１０４は、所定期間におけるユーザの過去の食事において、ユーザが不足していた栄養成分を補うための料理の組合せを示す表示を含む個別メニューを生成する。このバリエーションでは、４つ目のバリエーションで説明した手法を用いて所定期間におけるユーザにとって不足していた栄養成分が特定される。そして、３つ目のバリエーションで示した手法を用いて不足していた栄養成分を補うための料理の組み合わせが表示される。

６つ目のバリエーションでは、演算部１０４は、ベジタリアンの分類情報に対応する避けるべき食材を別の食材に置換した料理を含む個別メニューを生成する。このバリエーションにおいて演算部１０４は、１つ目のバリエーションで説明した手法によりユーザが避けるべき食材を特定すればよい。別の食材としては、例えば、植物由来の材料を用いた代替肉及び動物細胞を培養して食品として加工された培養肉の少なくとも一つが含まれる。代替肉は植物が原材料であるため、ベジタリアンの分類を問わず有効な食材である。培養肉は、例えば動物を殺すことに嫌悪感を抱いてベジタリアンになったユーザにおいて有効な食材である。例えば、演算部１０４は、牛肉、豚肉、及び鶏肉等の食肉を食材として使用する料理については、その食肉を代替肉に置き換えた料理に修正すればよい。このとき、培養肉を許容するユーザであれば、演算部１０４は、食肉を含む料理を培養肉に置き換えた料理に修正すればよい。培養肉を許容するユーザであるか否かの情報は例えば後述する分類情報に記憶される。

さらに、別の食材としては、例えばベジタリアンの分類情報に対応する不足しやすい栄養成分が採用されてもよい。２つ目のバリエーションで説明したように、不足しやすい栄養成分は、ベジタリアンの分類に応じておよそ推定可能である。或いは、不足しやすい栄養成分は４つ目のバリエーションで示したように、所定期間において不足しやすい栄養成分であってもよい。そこで、演算部１０４は、分類に応じて予め定められた不足しやすい栄養成分を含む食材を別の食材として決定すればよい。或いは、演算部１０４は、所定期間で特定された分類に応じた不足しやすい栄養成分を含む食材を別の食材として決定すればよい。

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

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

図１８は、個別メニューを含む操作画面の一例を示す図である。操作画面Ｇ１０６（第２操作画面の一例）は、操作画面Ｇ３と同様、複数のタイルオブジェクト９０１がマトリックス状に配置されている。操作画面Ｇ１０６において、個別メニューはユーザのスクロール操作に応じてスクロール可能に構成されている。これら複数のタイルオブジェクト９０１により個別メニューが構成される。操作画面Ｇ１０６の個別メニューにおいては、図８の標準メニューに含まれていた「ステーキセット」、「ラーメンＡセット」、「ラーメンＢセット」、及び「ハンバーガー」等の料理を示すタイルオブジェクト９０１が、食肉を含む等の理由により、「ラーメンと野菜餃子」、「ベジタブルカレーとウーロン茶」、「トマトソースパスタ」、及び「代替肉カレー」等のベジタリアンが食することが可能な料理を示すタイルオブジェクト９０１に変更されている。なお、図１８の例は上述の６つ目のバリエーションにおいて、ユーザが避けるべき食材を別の食材に置き換えるに際して、不足しやすい栄養成分を含む食材を採用する態様に対応している。或いは、図１８の例は、１つ目のバリエーションと２つ目のバリエーションとを組み合わせた態様に対応している。

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

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

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

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

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

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

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

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

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

（ベジタリアンについて）
次に、ベジタリアンの内容について説明する。図２２は、ベジタリアンの分類と、各分類に応じたユーザの避けるべき食材をまとめた表である。この表に示すように、ベジタリアンは、大きく「ヴィーガン」、「ラクトベジタリアン」、「ラクトオボベジタリアン」、及び「オボベジタリアン」に分類される。この表において、「Ｘ」は該当するベジタリアンが避けるべき食材を示している。

ヴィーガンは、牛肉、豚肉、鶏肉、魚、卵、乳製品、及び蜂蜜が避けるべき食材として挙げられているように、動物性の食材を除外するベジタリアンである。

ラクトベジタリアンは、牛肉、豚肉、鶏肉、魚、及び卵が避けるべき食材として挙げられているように、乳製品及び蜂蜜を除く動物性の食材を除外するベジタリアンである。

ラクトオボベジタリアンは、牛肉、豚肉、鶏肉、及び魚が避けるべき食材として挙げられているように、卵、乳製品、及び蜂蜜を除く動物性の食材を除外するベジタリアンである。

オボベジタリアンは、牛肉、豚肉、鶏肉、魚、及び乳製品が避けるべき食材として挙げられているように、卵及び蜂蜜を除く動物性の食材を除外するベジタリアンである。

また、昨今、フレキシタリアン及びリデュースタリアンと称される上記の分類に当てはまらないベジタリアンも増えてきている。フレキシタリアンは、セミベジタリアンとも称されており、食事をする時間帯、曜日、及び誰と食事をとるのかといった食事の状況応じて、動物性の食材を除外するベジタリアンである。例えば、朝食のみラクトオボベジタリアンとなったり、週に１度だけヴィーガンとなったり、友人と食事するときはベジタリアンをやめるといったベジタリアンである。

リデュースタリアンは、動物性食品を減らす食事法とされる。例えば、チャーハンに少量含まれる肉であれば食べるが、ステーキは選択しないというようなベジタリアンである。

さらに、この表では、各分類に応じて不足しがちな栄養成分がまとめられている。ヴィーガンの食事法を続けると、ビタミンＢ１２、ビタミンＤ、亜鉛、カルシウム、必須脂肪酸、たんぱく質、鉄等が不足しがちになる。

ラクトベジタリアンは、鉄、ｎ－３系脂肪酸等が不足しがちになる。ラクトオボベジタリアンとオボベジタリアンとは、鉄等が不足しがちになる。

ベジタリアンは特定の食品を長期間に渡り継続して摂取しないため、健康維持に必要な特定の栄養成分及びミネラルが慢性的に不足しがちになりやすい。

したがって、ベジタリアンは自身の分類に応じた不足しがちな栄養成分を多く含む植物性の食材を用いて調理された料理を摂取して、不足しがちな栄養成分をバランス良く摂取することが望まれる。

例えば、ビタミンＢ１２を多く含む植物性の食材は、藻類（ほしのり、味付けのり、焼きのり）である。ビタミンＤを多く含む植物性の食材は、干しシイタケ、きくらげ等である。亜鉛を多く含む植物性の食材は、藻類（焼きのり、わかめ）、野菜類（切り干し大根、枝豆）、豆類（きな粉、納豆）等である。カルシウムを多く含む植物性の食材は、野菜類（小松菜、乾燥ひじき、チンゲンサイ）、豆類（豆腐、納豆）等である。鉄を多く含む植物性の食材は、野菜類（小松菜、ほうれん草）、豆類（納豆、厚揚げ）等である。

ベジタリアンの分類に応じて、不足しがちな栄養成分をユーザが十分に考慮して料理を選択することはこのような知識が必要であり、また面倒でもあるため、長続きしにくいと思われる。

そこで、本実施の形態では、上述した２つ目～６つ目のバリエーションで説明したように、情報端末１００が自動的に、不足しがちな栄養成分を含む食材が追加された料理、不足しがちな栄養成分が壊されないように調理法が変更された料理、不足しがちな栄養成分を補うことが可能な料理の組み合わせを個別メニューを通じてユーザに提案する。

（データ構成）
次に、分類情報及び食材情報２４００のデータ構成について説明する。図２３は、第１サーバ２００からマッチングアプリへ返信されるユーザの分類情報を含む情報２３００のデータ構成の一例を示す図である。この情報２３００は、演算処理が容易にできるようにフィールドとバリューとが対応付けて記載されている。情報２３００は、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）フォーマットにて１ファイルが構成されている。

「情報カテゴリ」フィールドは、情報２３００がどういう種類の個人情報であるかを示すフィールドである。情報２３００は食事に関するデータであるため、「情報カテゴリ」フィールドに対するバリューには「食事」が記載されている。「情報カテゴリ」フィールドは情報２３００の先頭に記載されている。

「発行元」フィールドは、マッチングアプリを介してユーザに質問をしてこの情報２３００を取得した法人を識別するためのフィールドである。ここでは、ＡＢＣマッチング株式会社により質問が行われて情報２３００が取得されたため、「発行元」フィールドに対応するバリューには、ＡＢＣマッチングが記載されている。

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

「データ種別」フィールドは、この情報２３００の内容を具体的に特定するフィールドである。ここでは、「データ種別」フィールドに対応するバリューには、例えば、「ベジタリアン属性」が記載されている。これにより、以下のフィールドに記載されたデータがユーザであるベジタリアンに関する分類情報であることが示される。

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

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

「ベジタリアン分類」は、ユーザが属するベジタリアンの分類を示している。「ベジタリアン分類」としては、図２２に示したヴィーガン、ラクトベジタリアン、ラクトオボベジタリアン、及びオボベジタリアンの他、フレキシタリアン及びリデュースタリアンがある。「ベジタリアン分類」は、例えば、上述の質問時にユーザによって選択された分類が採用される。ここでは、該当するユーザはラクトオボベジタリアンであるため、「ベジタリアン分類」に対応するバリューには、「ラクトオボベジタリアン」が記載されている。

「ベジタリアン分類」フィールド以降には、牛肉、豚肉、鶏肉、魚、卵、乳製品、及び蜂蜜の食材のそれぞれに対して、ユーザが食することへの抵抗感の度合いを示す抵抗値が記載されている。抵抗値は例えば０～５の６段階で表され、数値が増大するほど抵抗感が低いことを示している。例えば、抵抗値「０」の食材は絶対に避けるべき食材であり、抵抗値「５」の食材は食することに抵抗がない食材である。抵抗値は、主にリデュースタリアンの料理の選定に用いられる。

このユーザは、「ベジタリアン分類」がラクトオボベジタリアンであり、牛肉、豚肉、及び魚は避けるべき食材であるため、これらの食材の抵抗値は「０」が設定されている。一方、卵、乳製品、及び蜂蜜は食することが可能な食材であるため、これらの抵抗値は「３」、「５」、「５」が設定されている。卵の抵抗値が「３」であるのは、このユーザは卵については食することに多少の抵抗感を抱いているからである。図２２の表に示すように食することを避けるべき食材はベジタリアンの分類に応じて予め定められている。そのため、各食材のバリューには、分類に応じて予め定められた避けるべき食材には「０」、分類に応じて予め定められた、食することが可能な食材には「５」の抵抗値がデフォルトで設定される。但し、ユーザは、食することが可能な食材であっても食することに対して抵抗感を感じる食材については、マッチングアプリを通じて「５」未満の抵抗値を入力することが可能である。

なお、リデュースタリアンのユーザは、マッチングアプリを通じて、各食材に対する抵抗値を入力することが要求される。情報２３００は、フレキシタリアンのユーザについて、ベジタリアンになるときにビィーガン、ラクトベジタリアン、ラクトオボベジタリアン、オボベジタリアンのいずれのベジタリアンになるかを示す情報を含んでもよい。さらに、情報２３００は、フレキシタリアンのユーザについて、いつどの時間帯の食事においてベジタリアンになるかに関するスケジュール情報を含んでいてもよい。

抵抗値は、ユーザが属するベジタリアンの分類、及びベジタリアンの分類に対応する避けるべき食材に関して避けるべき食材の程度を示すレベル情報の一例である。

一方で、レストランＡ社の第２サーバ３００から取得されるメニュー情報において、料理毎の食材情報が記述されなければ、情報端末１００はベジタリアンが避けるべき食材を含む料理を特定することが不可能になる。図２４は、第２サーバ３００から返信されるメニュー情報を構成する食材情報２４００のデータ構成の一例を示す図である。図２４では、ラーメンＢセットの食材情報２４０１を示している。ラーメンＢセットは醤油ラーメンと小籠包とが含まれている。そのため、情報端末１００は、ラーメンＢセットにユーザが避けるべき食材が含まれているか否かを判定するに際して、醤油ラーメンの食材情報２４０２と、小籠包の食材情報２４０３とを参照する。

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

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

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

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

ラーメンＢセットには、食材情報２４０２及び食材情報２４０３に示されるように、「豚チャーシュー」、「豚ひき肉」、「蜂蜜」、及び「鶏ガラスープ」が食材として含まれている。しかしながら、ヴィーガンのユーザの情報２３００には、豚肉、蜂蜜、及び鶏肉の抵抗値がそれぞれ「０」に設定されており、「豚チャーシュー」、「豚ひき肉」、「蜂蜜」、及び「鶏ガラスープ」はヴィーガンのユーザにとって避けるべき食材である。そのため、ヴィーガンのユーザはラーメンＢセットをそのまま食することは望まない。そこで、情報端末１００の演算部１０４は、例えばラーメンＢセットに代えて、図２５に示すラーメンと野菜餃子の料理セットを個別メニューを通じてユーザに提案する。

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

料理を差し替えるにあたり、情報端末１００は、図２４に示す食材情報２４０２及び食材情報２４０３と該当するユーザの情報２３００に含まれる分類情報とを照合し、食材情報２４０２及び食材情報２４０３の中から置換対象の食材を抽出する。例えば、情報２３００において抵抗値が「０」又は「１」の食材が食材情報２４０２及び食材情報２４０３において置換対象の食材として抽出される。食材情報２４０２及び食材情報２４０３に「ＮＧ」で示される置換対象の食材として抽出された食材を示している。そして、情報端末１００は、抽出した置換対象の食材に対して料理ごとに予め定められた代替食材及びその代替食材の量で置換対象の食材及び量を置換することで、食材情報２４０２及び食材情報２４０３を差し替える。さらに、情報端末１００は、食材情報の料理名も置換後の食材に応じて予め定められた料理名に差し替える。これにより、図２５に示す食材情報２４００が得られる。情報端末１００は、この処理を、取得したメニュー情報に含まれる各料理のそれぞれについて適用することで、料理を差し替えればよい。

或いは、情報端末１００は、置換対象の食材を含む料理に対して、ベジタリアンの分類に応じた代替料理が予め定められているのであれば、その料理をその代替料理に差し替えてもよい。

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

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

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

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

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

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

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

分類情報を受信したマッチングアプリは、受信したメニュー情報と受信した分類情報とから、上述した６つのバリエーションで示される方法のいずれかを用いて、当該ユーザの分類情報に対応した個別メニューを生成する（ステップＳ５０８）。

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

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

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

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

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

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

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

さらに、図２６に示される制御方法によれば、正確且つ時間的に連続した分類情報、食事履歴情報（例えば、注文履歴情報）、活動量、及びバイタルサイン情報等を含む個人情報が効率的且つ安全に管理される。さらに、図２６に示される制御方法によれば、個人情報がユーザにより許諾された事業者以外に漏洩することが防止される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図３２は、図２８のステップＳ４の処理の詳細を示すフローチャートである。ステップＳ４０１において、マッチングアプリは、レストランＡ社のメニュー情報と、ユーザの最新の分類情報とを照合し、ユーザの分類に対応した料理のみが含まれる個別メニューを生成する。メニュー情報には後述するように各料理に含まれる１以上の食材と食材の量とが含まれる。メニュー情報には、各料理の調理方法を示す調理方法情報が含まれていてもよい。ここでは、上述した６つのバリエーションのいずれかの方法を用いて個別メニューが生成される。

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

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

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

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

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

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

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

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

第１サーバ２００には、このユーザの多種多様で膨大な個人情報が分散暗号化されて蓄積されている。例えば、本開示で利用したユーザの分類情報は、「ｕｓｅｒＩＤ＿ｈｅａｌｔｈｃａｒｅ＿ｃｌａｓｓｉｆｉｃａｔｉｏｎ＿１．ｊｓｏｎ」ファイル、「ｕｓｅｒＩＤ＿ｈｅａｌｔｈｃａｒｅ＿ｃｌａｓｓｉｆｉｃａｔｉｏｎ＿２．ｊｓｏｎ」ファイル、．．．、「ｕｓｅｒＩＤ＿ｈｅａｌｔｈｃａｒｅ＿ｃｌａｓｓｉｆｉｃａｔｉｏｎ＿Ｎ．ｊｓｏｎ」ファイルというＮ個のＪＳＯＮフォーマットのファイルとして、第１サーバ２００内の物理的に異なるストレージ装置に保管されている。Ｎ個のファイルにおいて、ファイル名の先頭部分の「ｕｓｅｒＩＤ」は対象ユーザを特定するための識別情報であり、続く「ｈｅａｌｔｈｃａｒｅ」は図２３で説明した情報カテゴリ（例えば、食事）を特定するための識別情報であり、続く「ｃｌａｓｓｉｆｉｃａｔｉｏｎ」は図２３で説明したデータ種別（例えば、ベジタリアン属性）を特定するための識別情報であり、最後の数字は分断したファイルの識別番号である。

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

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

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

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

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

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

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

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

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

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

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

上位２つの料理のタイルオブジェクト９０１Ｃには、サイズがデフォルトのタイルオブジェクト９０１Ｄより大きく（例えば２倍）設定されて、枠を太くする装飾が施され、料理名を示す文字列を太くする装飾が施され、デフォルメするマーク３５０１が表示され、料理を示す画像のサイズがタイルオブジェクト９０１Ｄより大きく（例えば２倍）設定され、ハートマーク３５０２が表示されている。さらに、タイルオブジェクト９０１Ｃには、「大豆で不足しがちな鉄分をチャージ」といったユーザにこの料理を食することへのメリットを伝えるメッセージ、及び「動物由来の原料は一切含まれていません」といったユーザにこの料理を食することへの不安を打ち消すメッセージが表示されている。これらのメッセージは、料理毎に予め定められた文言が採用されればよい。

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

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

図３５の例では、ヴィーガンに対する個別メニューであるため、ベジバーガーに対して「ヴィーガン向け」とのメッセージが表示されている。

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

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

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

図３６は、個別メニューの２つ目のバリエーションを含む操作画面Ｇ１０６の一例を示す図である。この例では、優先度が下位の料理における表示方法が示されている。図３６において、左側はユーザがタイルオブジェクト９０１を選択する前の操作画面Ｇ１０６を示し、右側はユーザがタイルオブジェクト９０１を選択した後の操作画面Ｇ１０６を示している。この個別メニューではユーザが避けるべき食材を含む料理については、その料理のタイルオブジェクト９０１内に注意を促す注意マーク３６０２が表示されている。そして、注意マーク３６０２を含むタイルオブジェクト９０１Ｅが指示体１００１によりタッチされると、注意点を説明する吹き出し枠３６０１がタッチされたタイルオブジェクト９０１Ｅに対応付けて表示される。ここでは、ラーメンＡセットのタイルオブジェクト９０１Ｅが選択され、この料理には、避けるべき食材である、豚ひき肉、豚チャーシュー、及び卵が含まれている。そのため、吹き出し枠３９０１には、「この料理には次の食材が含まれています」のメッセージに下に、これらの避けるべき食材と、各食材の量とが対応付けて表示されている。これにより、この料理を注文すべきか否かの判断材料がユーザに提示される。その結果、ユーザは料理の注文をスムーズに行うことができる。

これを実現するために、演算部１０４は、各料理について、食材情報２４００及び分類情報を参照して、ユーザが避けるべき食材が含まれているか否かを判定し、避けるべき食材が含まれている料理についてはそのタイルオブジェクト９０１に注意マーク３６０２を表示させる。そして、演算部１０４は、このタイルオブジェクト９０１がタッチされると、該当する料理の食材情報２４００から避けるべき食材とその食材の量とを抽出し、吹き出し枠３６０１内に表示させればよい。

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

演算部１０４は、フレキシタリアン及びリデュースタリアンについては、個別メニューにおいてのみ注意マーク３６０２を表示し、標準メニューでは注意マーク３６０２を表示しなくてもよい。

なお、抵抗値が０のユーザが絶対に避けるべき食材を含む料理について、演算部１０４は、その料理のタイルオブジェクト９０１に注意マーク３６０２に代えて図３７に示す禁止マーク３６０３を表示してもよい。或いは、抵抗値が０の食材を含む料理について、演算部１０４は、ベジタリアンの分類に拘わらず、その料理のタイルオブジェクト９０１を非表示にしてもよい。

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

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

演算部１０４は、抵抗値が所定値（例えば１～３）の食材を含む料理についてのみ、その料理のタイルオブジェクト９０１に注意マーク３６０２を表示し、抵抗値が所定値以外（例えば４～５）の食材を含む料理については注意マーク３６０２を表示させなくてもよい。さらに、注意マーク３６０２及び禁止マーク３６０３が表示されたタイルオブジェクト９０１が指示体１００１によってタッチされた場合、演算部１０４は、情報端末１００が備えるバイブレータを駆動して情報端末１００を振動させてもよい。これにより、ユーザに対して避けるべき食材が含まれている料理であることをより分かりやすく伝えることが可能となる。

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

例えば、ベジタリアンの不足しやすい栄養成分として鉄分が挙げられる。納豆は鉄分を豊富に含んでいる。そこで、この例では、演算部１０４は、「きのこパスタ」のタイルオブジェクト９０１Ｇが指示体１００１によりタッチされたとき、納豆の追加注文を促す吹き出し枠３８０１をタイルオブジェクト９０１Ｇに対応付けて表示する。この吹き出し枠３８０１内には、「納豆で鉄分をチャージしませんか？」とのメッセージに加えて、納豆を追加することにより摂取可能な鉄分の量の増加量（＋１．５ｍｇ）が表示されている。これにより、納豆を追加注文することで鉄分が効率的に補えることがユーザに訴求される。

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

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

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

（優先度の算出）
次に、優先度の算出について説明する。本実施の形態では、情報端末１００の演算部１０４は、メニュー情報に含まれる各料理の優先度を算出し、その優先度にしたがった表示態様で各料理が表示された個別メニューを生成する。なお、優先度の値が大きい料理ほど、優先して表示される。以下、優先度の算出方法について説明する。まず、演算部１０４は、ある料理の食材情報２４００を参照し、その料理を構成する食材及び各食材の量を特定する。次に、演算部１０４は、その料理を構成する食材のうち、図２３に示す分類情報に列挙され食材に該当するものについては、それぞれ（０．２＊抵抗値－１）で計算される係数を食材の量に乗じて、その合計値が小さい程、個別メニューでの表示優先度を下げる処理を行ってもよい。

例えば、図２４に示すラーメンＢセット（醤油ラーメンと小籠包３個）については、醤油ラーメンの豚チャーシュー１８ｇ、小籠包の豚ひき肉１０ｇ、はちみつ１ｇ、鶏ガラスープ１０ｇが、図２３に示す分類情報の食材リストの豚肉「０」、鶏肉「０」、蜂蜜「５」に対して、次のように計算される。

１８＊（０．２＊０－１）＋３＊（１０＊（０．２＊０－１）＋１＊（０．２＊５－１）＋１０＊（０．２＊０－１））＝－７８
したがって、この料理の優先度は、－７８と算出される。このようにして、演算部１０４はメニュー情報に含まれる各料理の優先度を算出する。

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

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

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

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

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

１００ ：情報端末
１０１ ：通信部
１０２ ：メモリ
１０３ ：カメラ
１０４ ：演算部
１０５ ：ディスプレイ
１０６ ：操作部
１０７ ：近接通信部
２００ ：第１サーバ
２０１ ：通信部
２０２ ：演算部
２０３ ：メモリ
３００ ：第２サーバ
３０１ ：通信部
３０２ ：演算部
３０３ ：メモリ
２４００ ：食材情報

Claims (23)

1. ユーザを特定する識別情報に対応して、ユーザが属する菜食主義者の分類を示す分類情報を管理する第１サーバとネットワークを介して通信する前記ユーザの情報端末の制御方法であって、
   前記ユーザの前記情報端末のディスプレイに表示されるマッチングアプリが指定する共通スタイルに即した第１操作画面を介して、レストランＩＤ及び前記ユーザの座席を示す席ＩＤを取得し、
   前記レストランＩＤに基づき、前記レストランＩＤに対応するレストランに関連する第２サーバからネットワークを介して前記レストランが提供する１以上の料理を示すメニュー情報を取得し、
   前記情報端末に格納された前記識別情報を前記第１サーバに送信し、前記識別情報に基づき、前記第１サーバから前記分類情報を取得し、
   前記メニュー情報及び前記分類情報に基づき、前記分類情報に対応した前記ユーザの個別メニューを前記情報端末にて生成し、
   前記レストランが指定する個別スタイルの第２操作画面であって前記レストランにおける料理の注文を受け付けるための第２操作画面を介して、前記個別メニューを表示し、
   前記第２操作画面を用いて前記個別メニューにて選択された料理を示す注文料理情報及び前記席ＩＤを、前記情報端末から前記第２サーバに送信することを含む、
   制御方法。
2. 前記個別メニューは、前記メニュー情報及び前記分類情報に基づき、前記メニュー情報に含まれる各料理において前記分類情報に対応する避けるべき食材を含む料理を除外又はグレイアウトさせて生成される、
   請求項１記載の制御方法。
3. 前記個別メニューは、前記１以上の料理において、前記菜食主義者の分類に対応する不足しやすい栄養成分を含む食材を追加した一の料理を含む、
   請求項１に記載の制御方法。
4. 前記個別メニューは、前記菜食主義者の分類に対応する不足しやすい栄養成分を補うための料理の組合せを示す表示を含む、
   請求項１～３のいずれか１項に記載の制御方法。
5. 前記個別メニューは、前記１以上の料理において、所定期間における前記ユーザの過去の食事において、前記ユーザが不足していた栄養成分を含む食材を追加した一の料理を含む、
   請求項１に記載の制御方法。
6. 前記個別メニューは、所定期間における前記ユーザの過去の食事において、前記ユーザが不足していた栄養成分を補うための料理の組合せを示す表示を含む、
   請求項１に記載の制御方法。
7. 前記個別メニューは、前記１以上の料理において、前記菜食主義者の分類に対応する避けるべき食材を別の食材に置換した料理を含む、
   請求項１に記載の制御方法。
8. 前記別の食材は、植物由来の材料を用いた代替肉、又は動物細胞を培養して食品として加工された培養肉の少なくともいずれか一つを含む、
   請求項７に記載の制御方法。
9. 前記別の食材は、前記菜食主義者の分類に対応する不足しやすい栄養成分を含む、
   請求項７に記載の制御方法。
10. 前記分類情報は、前記ユーザが属する菜食主義者の分類、及び、前記菜食主義者の分類に対応する避けるべき食材に関して前記避けるべき食材の程度を示すレベル情報を含む、
    請求項１～９のいずれか１項に記載の制御方法。
11. 前記個別メニューの表示から前記レストランの一般メニューの表示に切り替える指示を受け付けると、前記第２操作画面を介して前記一般メニューを表示する、
    請求項１記載の制御方法。
12. 前記個別メニューは、
    前記ユーザが可能な限り避けるべき食材を含む料理、を含む、
    請求項１に記載の制御方法。
13. 前記菜食主義者の分類は、ヴィーガン、ラクトベジタリアン、オボベジタリアン、及びラクトオボベジタリアンを含む、
    請求項１～１２のいずれかに記載の制御方法。
14. 前記識別情報は、ユーザＩＤを含む、
    請求項１記載の制御方法。
15. 前記第１サーバは、前記第２サーバと異なる、
    請求項１記載の制御方法。
16. 前記レストランＩＤ及び前記席ＩＤは、前記第１操作画面を介して、前記ユーザが着席したテーブルの対応位置に用意された識別コードを読み取ることで、取得される、
    請求項１記載の制御方法。
17. 前記識別コードは、ＱＲコードを含む、
    請求項１６記載の制御方法。
18. 前記識別コードは、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を用いて読み取られる、
    請求項１６記載の制御方法。
19. 前記第１サーバは、生体情報、前記分類情報、及び前記ユーザの位置情報を含む行動履歴情報を分散管理する、
    請求項１～１８のいずれか１項に記載の制御方法。
20. 請求項１～１９のいずれか１項に記載の制御方法を実行する情報端末。
21. 請求項１～１９のいずれか１項に記載の制御方法を前記情報端末のコンピュータに実行させるためのプログラム。
22. 前記ユーザを特定する識別情報は、前記プログラムに付与された情報端末毎のシリアルコードを含む、
    請求項２１に記載のプログラム。
23. 請求項１～１９のいずれか１項に記載の制御方法を前記情報端末のコンピュータに実行させるためのプログラムを記録した記録媒体。

Images