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

Abstract

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

Description

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

特許文献１は、所定の目的に応じて過去の食事内容を参酌して、その後の食事のメニューを決定できるパーソナル食事管理システム用携帯端末を開示する。特許文献１のパーソナル食事管理システム用携帯端末は、通信手段によって外部からメニュー情報を取得し、取得したメニュー情報と、記憶手段に記憶された食事履歴、ユーザ状態、及び食事ルールとから推奨すべき食事のメニューを選択し、選択した食事のメニューを提示する。

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

特開２００４−３１０２０５号公報 特開２００８−２９９８２１号公報

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

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

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

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

（本開示に至る経緯）
レストランにおいて、アレルギーを有する客に対してアレルゲンである食材を抑制した料理が提供される場合、前記客のアレルゲンである食材を抑制した料理は、当該料理を注文した前記客に提供される必要がある。ここで、アレルゲンである食材を抑制した料理とは、例えば、アレルゲンである食材が含まれていないか、アレルゲンである食材を減少させた料理である。以降、注文を行った前記客に対するアレルゲンである食材を抑制した料理を、アレルギーに対応した料理と呼ぶ。同じテーブルに座っている他の客が注文したアレルギーに対応していない料理が、前記客に提供されることは、前記客の健康に甚大な悪影響を及ぼすため、確実に回避することが求められる。

前述した特許文献１においては、食事ルールにアレルギー食材が含まれている場合、推奨する料理のメニュー情報からそのアレルギー食材を含む料理が除外される。

しかしながら、特許文献１では、アレルギー食材を含む料理が除外されたメニュー情報を提示することが開示されているに過ぎず、メニュー情報を介して客が選択した料理をその客の座席に提供することは何ら開示されていない。そのため、特許文献１は、アレルギー食材が除外されていない料理が間違って客の座席に提供される可能性がある。その結果、特許文献１は、アレルギー食材が除外されていない料理を客が摂取してしまい、前記客の健康に甚大な悪影響を及ぼす可能性がある。

また、アレルギー食材に関する情報はセンシティブな情報であるため、その情報がユーザの許諾なしに第三者に提供されることも防止する必要もある。

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

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

本開示は、上記の課題を解決するためになされたものであり、アレルギーに対応していない料理が間違って注文されることを防止し、それによって、アレルギーに対応していない料理をユーザが摂取してしまい、ユーザの健康に甚大な悪影響を及ぼすことを防止することを第１の目的とする。

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

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

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

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

このように、本態様では、ユーザが料理を注文する一連の過程の中で、個別メニューからユーザにより選択された料理を示す注文料理情報とユーザの座席との対応付けが人手を介することなく自動的に行われている。これにより、例えば、同一のテーブルに複数のユーザが座って、各ユーザが料理を注文した場合であっても、同一のテーブルに座っている他のユーザが注文したアレルギーに対応していない料理が、食材に関するアレルギーを持つユーザの座席に運ばれることを防止できる。その結果、食材に関するアレルギーを持つユーザは、自身の健康への甚大な悪影響を心配することなく、注文した料理を食べることができる上、料理の注文を簡単に実施できる。

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

上記制御方法において、前記個別メニューは、前記メニュー情報及び前記アレルギー情報に基づき、前記メニュー情報に含まれる各料理において前記アレルギー情報が示すアレルギーの原因となる食材を減少させて生成された料理を含んでもよい。

本態様によれば、個別メニューには、アレルギーの原因となる食材が減少された料理が含まれる。これにより、ユーザの健康に甚大な悪影響を及ぼすことが防止される。

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

本態様によれば、個別メニューには、アレルギーの原因となる食材がゼロにされた料理が含まれる。これにより、ユーザの健康に甚大な悪影響を及ぼすことがより確実に防止される。

上記制御方法において、前記個別メニューは、前記メニュー情報及び前記アレルギー情報に基づき、前記メニュー情報に含まれる各料理において前記アレルギー情報が示すアレルギーの原因となる食材を含む料理を除外させて生成されてもよい。

本態様によれば、個別メニューには、アレルギーの原因となる食材を含む料理が省かれる。これにより、ユーザの健康に甚大な悪影響を及ぼすことが確実に防止される。

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

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

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

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

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

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

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

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

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

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

上記制御方法において、前記メニュー情報は、各料理に含まれる１以上の食材を示す情報と各食材の量とを含み、前記アレルギー情報は、各食材に対する前記ユーザのアレルギー反応量を含み、前記個別メニューの生成では、前記メニュー情報から前記アレルギー反応量が基準値以上の食材を前記アレルギーの原因となる食材として特定してもよい。

本態様によれば、メニュー情報には、各料理に含まれる１以上の食材を示す情報と各食材の量とが含まれ、アレルギー情報には各食材に対するユーザのアレルギー反応量が含まれている。これにより、メニュー情報からアレルギー反応量が基準値以上の食材をアレルギーの原因となる食材として特定することが可能となる。よって、ユーザのアレルギーの原因となる食材が正確に特定される。

本開示は、このような制御方法に含まれる特徴的な各構成をコンピュータに実行させるプログラム、或いはこのプログラムによって動作する情報端末として実現することもできる。また、このようなコンピュータプログラムを、ＣＤ−ＲＯＭ等のコンピュータ読取可能な非一時的な記録媒体あるいはインターネット等の通信ネットワークを介して流通させることができるのは、言うまでもない。

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

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

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

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

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

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

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

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

上記の構成によると、ユーザは表示された推奨メニューから、自分のアレルゲンの入っていない料理を選択することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

演算部１０４は、取得したメニュー情報及び取得したアレルギー情報に基づき、アレルギー情報に対応したユーザの個別メニューを生成する。個別メニューには、演算部１０４が取得したメニュー情報に含まれる各料理においてアレルギー情報が示すアレルギーの原因となる食材を減少させて生成された料理が含まれている。ここで言う「食材を減少させる」ことには、アレルギーの原因となる食材をゼロにすることが含まれる。これにより、個別メニューにはアレルギーに対応した料理のみが含まれることになる。或いは、個別メニューは、メニュー情報に含まれる料理のうち、アレルギー情報が示すアレルギーの原因となる食材を含む料理が省かれて生成されたものであってもよい。

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

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

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

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

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

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

メモリ２０３は、ハードディスクドライブ等の不揮発性の複数のストレージ装置で構成されている。メモリ２０３は、１以上のユーザの個人情報を記憶する。個人情報には各ユーザのアレルギー情報が含まれる。個人情報は、複数のストレージ装置において分散化及び暗号化された上で記憶される。メモリ２０３が記憶する個人情報には、生体情報と、購買履歴情報と、嗜好情報、及び行動履歴情報が含まれていてもよい。生体情報は心拍数等の各ユーザの生体に関する情報である。生体情報には、上述のアレルギー情報が含まれる。購買履歴情報は、各ユーザの商品（物品）又はサービスの購買履歴を示す情報である。嗜好情報は、各ユーザの嗜好を示す情報である。嗜好情報には、各ユーザの料理の注文履歴を示す注文履歴情報が含まれる。行動履歴情報は、各ユーザの行動履歴を示す情報である。行動履歴情報は、例えば、ユーザの位置情報と時刻情報とが対応付けられた時系列データで構成される。

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

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

１つのテーブル４１０に２名以上のユーザが着席した場合において、これらのユーザの中に食物系アレルギーを抱えるユーザが含まれていることがある。この場合、各ユーザが注文した料理が間違って別のユーザに配膳されることは避けなければならい。食物系アレルギーは、アナフィラキシーショックのように生命活動上も重篤な症状も引き起こすリスクがあるためである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（個別メニューからの注文）
次に、個別メニューからの料理の注文について説明する。レストランが提供する一般向けのメニューであるが、個別メニューはユーザが健康上有害となるような強いアレルギー反応を引き起こす可能性のある食材が除外又は低減された料理を含むメニューである。或いは、個別メニューはユーザが健康上有害となるような強いアレルギー反応を引き起こす可能性のある食材を含む料理が除外されたメニューである。ここで言う、健康上有害となるような強いアレルギー反応とは、アレルギー検査により陽性として診断されるような、ユーザが認知し、生活上配慮すべきアレルギー反応のことを指す。そのため、アレルギー検査で陰性及び／又は擬陽性のような比較的弱いアレルギー反応を引き起こす可能性のある食材については、個別メニューの料理から除外されてもよいし、または、その影響を十分考慮したうえで、適量に低減されることがあってもよい。

この個別メニューから料理を注文する処理は、後述する図２６のフローチャートによって示される。以下、図２６のフローチャートを適宜参照しながら、個別メニューから料理を注文する処理について説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一つ目の方法は、ユーザがアレルギー反応を引き起こす可能性のある食材が少しでも含まれている料理を個別メニューからは除外するという方法である。食材に対するアレルギー反応は後述するように低い方から順にクラス０〜クラス６の７つのクラスに分類される。このうち、クラス０は、陰性、つまりアレルギー反応を引き起こす可能性がほぼゼロであり、クラス１は、偽陽性、つまりアレルギー反応を引き起こす可能性はあるもののその可能性は比較的低い。クラス２〜６はそれぞれ陽性であり、クラスが増すにつれてアレルギー反応を引き起こす可能性が高くなる。一つ目の方法では、例えば、クラス１以上の食材を少しでも含む料理が個別メニューから除外され、クラス０以下の食材のみからなる料理が個別メニューに含まれる。

二つ目の方法は、各料理において、ユーザがアレルギー反応を引き起こす可能性のある食材が含まれていても、その食材に対するユーザのアレルギー反応が比較的軽度である場合はその料理を個別メニューに残すという方法である。二つ目の方法では、例えば、クラス２以上の食材を含む料理は個別メニューから除外され、クラス１以下（陰性及び偽陽性）の食材を含む料理は個別メニューに残される。

三つ目の方法は、料理毎に、食材の量（単位はｇ）と、その食材に対するユーザのアレルギー反応量（単位はＩＵ／ｍＬ）とを掛け合わせた数値の合計値を計算し、この合計値に応じて個別メニューに含まれる料理を変更するという方法である。例えば、料理毎に計算された合計値が低／中／高の３段階に分類され、分類結果に応じて個別メニューに含まれる料理が変更される。

例えば、合計値が低段階の料理は、アレルギー反応が軽微であるため、調理方法は変更されずに個別メニューへ登録される。

合計値が中段階の料理は、アレルギー反応が多少あるため、合計値が低段階に収まるよう調理方が変更されたうえで個別メニューに登録される。この調理方法の変更では、例えば合計値が低段階に収まるようにアレルギーを引き起こす食材の量が少しずつ減らされる。或いは、合計値が中段階の料理は、アレルギー反応量（ＩＵ／ｍＬ）が基準値を超える食材の量がゼロになるように調理方法が変更されたうえで個別メニューに登録されてもよい。

例えば、合計値が高段階の料理は、アレルギー反応が強いため、個別メニューから省かれる。

アレルギー反応がある食材を一切食べないことは、特に成長段階にある子供の栄養摂取バランスにおいて大きな問題となる。そのため、アレルギー反応が全く無い又は極めて低い食材だけで料理を作るのではなく、ユーザごとのアレルギー反応の度合いに応じて調理方法を動的に変更する情報処理システムが重要となるのである。

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

図１７は、個別メニューを含む操作画面の一例を示す図である。操作画面Ｇ１０６（第２操作画面の一例）は、操作画面Ｇ３と同様、複数のタイルオブジェクト９０１がマトリックス状に配置されている。操作画面Ｇ１０６において、個別メニューはユーザのスクロール操作に応じてスクロール可能に構成されている。これら複数のタイルオブジェクト９０１により個別メニューが構成される。操作画面Ｇ１０６においては、図８の標準メニューから「ぼたん海老」及び「たまご」のタイルオブジェクト９０１が除外され、代わりに「いくら」及び「醤油ラーメン」のタイルオブジェクト９０１が掲載されている。これは、図２１に示すように、このユーザは、エビに対するアレルギー反応量が「６３２．３８」であり、卵に対するアレルギー反応量が「２５．４０」であり、これらの食材のアレルギー反応量が高かったからである。ここでは、「ぼたん海老」及び「たまご」の２つの料理が省かれたため、これら２つの料理を代替するために「いくら」及び「醤油ラーメン」の２つの料理が個別メニューに掲載されている。但し、これは一例であり、個別メニューは、代替料理を含んでいなくてもよい。この場合、メニュー情報からアレルギー反応量が高い食材を含む料理を削除することで個別メニューは生成される。

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

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

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

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

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

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

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

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

これを実行するために、ユーザは予めマッチングアプリを情報端末１００にインストールしておけばよい。

さらに、ユーザは、病院で診断されたアレルギーテスト結果の診断表を撮影し、その診断表の画像をマッチングアプリと共有する設定、又は診断表の画像のアクセスを許可する設定をしてもよい。第１サーバ２００は、共有された診断表の画像から機械的に記載情報を読み取り、アレルギー情報として登録すればよい。

或いは、アレルギー診断を行った病院が発行したアレルギーテスト結果及び付属情報を、マッチングアプリ又はそのマッチングアプリの開発会社若しくは運営会社と共有することを、ユーザがあらかじめ許諾しておいてもよい。この場合、病院により新たな診断結果がマッチングアプリと共有されると、マッチングアプリは第１サーバ２００に対して新たな診断結果を追加させる。そして、マッチングアプリは、新たな商品又はサービスとのマッチングに追加された診断結果を利用できる。

或いは、アレルギー診断を行った病院が発行したアレルギーテスト結果及び付属情報を、ユーザＩＤと対応付けて第１サーバ２００に保管することを、ユーザが許諾してもよい。この場合、病院は、新たな診断結果を第１サーバ２００に対して保管するリクエストを行うことができる。そして、マッチングアプリは、新たな商品又はサービスとのマッチングに保管された診断結果を利用できる。

ユーザのアレルギー情報は、ユーザ自らが情報端末１００に登録及び記録することも考えられる。時間的に変化がなく少量のデータであれば、ユーザ自らがアレルギー情報を情報端末１００に入力することが可能である。しかしながら、アレルギー情報が頻繁に更新され且つそのデータ量が膨大であるような場合、そのデータ入力の煩雑さから、アレルギー情報は、正確且つ時間的に継続して第１サーバ２００に登録されない可能性がある。これに対し、上述した方法によれば、アレルギー情報が適宜更新され且つそのデータ量が膨大であるような場合であっても正確且つ継続的に第１サーバ２００にアレルギー情報を保管できる。

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

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

「発行元」フィールドは、この情報２７００を発行した機関、法人、又は個人を識別するためのフィールドである。ここでは、ＡＢＣクリニックにより情報２７００は発行されたため、「発行元」フィールドに対応するバリューには、ＡＢＣクリニックが記載されている。

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

「データ種別」フィールドは、この情報２７００の内容を具体的に特定するフィールドである。ここでは、「データ種別」フィールドに対応するバリューには、例えば、アレルギー検査結果［ＩＵ／ｍＬ］が記載されている。これにより、以下のフィールドに記載されたデータがユーザのアレルギー反応の検査結果であることが示される。この例では、アレルギー反応量が非特異的ＩｇＥの単位であるＩＵ／ｍＬで記載されている。

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

「データ測定日」フィールドは、先行する「データ種別」フィールドに対応するバリュー「アレルギー検査結果」が測定された日時情報を示すフィールドである。ここでは、「データ測定日」フィールドに対応するバリューは２０１９年１１月１４日と記載されている。このバリューには測定日に加えて時刻が含まれていてもよい。また、このバリューにはタイムゾーン情報が含まれていてもよい。

「卵」フィールドは、卵に対するアレルギー反応量を示すフィールドである。ここでは、「卵」フィールドに対応するバリューには、ユーザの卵に対するアレルギー反応量をＩＵ／ｍＬ単位で示す２５．４０が記載されている。以降、「牛乳」、「小麦」、「ピーナッツ」、「エビ」、「カニ」、「マグロ」等の各種アレルゲンに対するアレルギー反応量の検査結果が卵の場合と同様に記載されている。

イムノキャップによる非特異的ＩｇＥの設定によれば、アレルギー反応は下から順に、０．３４ＩＵ／ｍＬまでがクラス０（陰性）、０．７０ＩＵ／ｍＬまでがクラス１（疑陽性）、３．５ＩＵ／ｍＬまでがクラス２の陽性、１７．５ＩＵ／ｍＬまでがクラス３の陽性、５０ＩＵ／ｍＬまでがクラス４の陽性、１００ＩＵ／ｍＬまでがクラス５の陽性、それ以上がクラス６の陽性と分類されている。

図２１の例では、卵がクラス４の陽性、エビ及びカニがそれぞれクラス６の陽性に属していることが分かる。図１７の個別メニューにおいて、標準メニューに含まれていた「ぼたん海老」及び「たまご」が除外されたのは、このアレルギー反応量が健康上有害となるほど強いレベルであると判断されたからである。

一方で、レストランＡ社の第２サーバ３００から取得されるメニュー情報には、料理毎の食材情報が記述されなければ、アレルギー反応のある料理を特定することが不可能になる。図２２は、第２サーバから返信されるメニュー情報を構成する食材情報２８００のデータ構成の一例を示す図である。

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

「料理名」フィールドは、この情報がどの料理に関する食材情報であるかを示すフィールドである。この例では、食材情報２８００は２貫のぼたん海老に関する食材情報であるため、「料理名」フィールドに対応するバリューにはぼたん海老（２貫）が記載されている。

続くフィールド及びバリューには、使用される食材の一覧が記載されている。例えば、「ぼたん海老」フィールドは、この料理の食材としてぼたん海老が使用されることを示すフィールドである。「ぼたん海老」フィールドに対応するバリューには、この料理で使用されるぼたん海老の量である２０ｇが記載されている。図２１の情報２７００の例では、エビのアレルギー反応量はクラス６の強い陽性である。そのため、図１７に示す個別メニューから「ぼたん海老（２貫）」は除外されている。

マッチングアプリは、食材情報２８００に記載された「ぼたん海老」が情報２７００の「アレルギー検査結果」フィールドに記載された「エビ」に該当することを、例えばマッチングアプリと関連して登録された辞書を参照することで判断すればよい。或いは、マッチングアプリは、Ｗｉｋｉｐｅｄｉａのような公開情報ソースを例えば、パブリック情報サーバ５００から取得し、取得した公開情報ソースに基づいて、ぼたん海老がエビの一種であることを判断してもよい。

図２３は、第２サーバ３００から返信されるメニュー情報を構成する食材情報２８００のデータ構成の他の一例を示す図である。この食材情報２８００では、醤油ラーメンの食材情報が示されている。そのため、「料理名」フィールドに対応するバリューには醤油ラーメンが記載されている。さらに、この食材情報２８００では、小麦粉が５０ｇ、食塩が５ｇというように、醤油ラーメンを構成する各食材と各食材の量とが対応付けて記載されている。醤油ラーメンの食材情報２８００には、情報２７００に記載されたアレルギー反応量が陽性となる食材は含まれていない。そのため、醤油ラーメンは図１７に示す個別メニューにおいて代替料理として表示されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ステップＳ１０４において、マッチングアプリは、ホーム画面Ｇ１０３のスキャンボタン１４０２をタッチするユーザの操作を受け付け、ＱＲコードの読取機能を起動する。これにより、図１５に示す操作画面Ｇ１０４が表示される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本開示にかかる制御方法の一例によれは、調理済み料理を提供する店舗において、ユーザのアレルギーに対応した料理が当該料理を注文したユーザに提供される技術として有用である。

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

Claims (14)

1. ユーザを特定する識別情報に対応するユーザのアレルギー情報を管理する第１サーバとネットワークを介して通信する情報端末の制御方法であって、
   前記ユーザの前記情報端末のディスプレイに表示される第１操作画面を介して、レストランＩＤ及び前記ユーザの座席を示す席ＩＤを取得し、
   前記レストランＩＤに基づき、前記レストランＩＤに対応するレストランに関連する第２サーバからネットワークを介して前記レストランが提供する１以上の料理を示すメニュー情報を取得し、
   前記情報端末に格納された前記識別情報を前記第１サーバに送信し、前記識別情報に基づき、前記第１サーバから前記ユーザのアレルギー情報を取得し、
   前記メニュー情報及び前記アレルギー情報に基づき、前記アレルギー情報に対応した前記ユーザの個別メニューを生成し、
   前記ユーザの情報端末のディスプレイに表示された前記レストランにおける料理の注文を受け付けるための第２操作画面を介して、前記個別メニューを表示し、
   前記個別メニューにて選択された料理を示す注文料理情報及び前記席ＩＤを前記第２サーバに送信することを含む、
   制御方法。
2. 前記個別メニューは、前記メニュー情報及び前記アレルギー情報に基づき、前記メニュー情報に含まれる各料理において前記アレルギー情報が示すアレルギーの原因となる食材を減少させて生成された料理を含む、
   請求項１記載の制御方法。
3. 前記食材を減少させることには、前記食材の量をゼロにすることを含む、
   請求項２記載の制御方法。
4. 前記個別メニューは、前記メニュー情報及び前記アレルギー情報に基づき、前記メニュー情報に含まれる各料理において前記アレルギー情報が示すアレルギーの原因となる食材を含む料理を除外させて生成される、
   請求項１記載の制御方法。
5. 前記識別情報は、ユーザＩＤを含む、
   請求項１記載の制御方法。
6. 前記第１サーバは、前記第２サーバと異なる、
   請求項１記載の制御方法。
7. 前記レストランＩＤ及び前記席ＩＤは、前記第１操作画面を介して、前記ユーザが着席したテーブルの対応位置に用意された識別コードを読み取ることで、取得される、
   請求項１記載の制御方法。
8. 前記識別コードは、ＱＲコードを含む、
   請求項７記載の制御方法。
9. 前記第１サーバは、前記アレルギー情報を含む生体情報、前記ユーザの物品の購買履歴情報又は料理の注文履歴情報を含む嗜好情報、及び前記ユーザの位置情報を含む行動履歴情報を分散管理する、
   請求項１〜８のいずれか１項に記載の制御方法。
10. 前記メニュー情報は、各料理に含まれる１以上の食材を示す情報と各食材の量とを含み、
    前記アレルギー情報は、各食材に対する前記ユーザのアレルギー反応量を含み、
    前記個別メニューの生成では、前記メニュー情報から前記アレルギー反応量が基準値以上の食材を前記アレルギーの原因となる食材として特定する、
    請求項２〜４のいずれか１項に記載の制御方法。
11. 請求項１〜１０のいずれか１項に記載の制御方法を実行する情報端末。
12. 請求項１〜１０のいずれか１項に記載の制御方法を前記情報端末のコンピュータに実行させるためのプログラム。
13. 前記ユーザを特定する識別情報は、前記プログラムに付与された情報端末毎のシリアルコードを含む、
    請求項１２に記載のプログラム。
14. 請求項１〜１０のいずれか１項に記載の制御方法を前記情報端末のコンピュータに実行させるためのプログラムを記録した記録媒体。

Images