JP7065321B2 - 情報提供方法 - Google Patents

Description

本開示は、第１サーバと通信する第２サーバを含む情報管理システムにおける情報提供方法に関するものである。

特許文献１には、飲食店においてメニューの中から顧客が自身の好みに合う料理を探し出す手間を軽減するために、顧客の注文履歴を取得し、取得した注文履歴に関する情報に基づいて、飲食品に係る注文案を通知するオーダーシステムが開示されている。

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

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

本開示の一態様に係る情報提供方法は、第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する第１サーバと通信する第２サーバであって前記第１レストランと系列が異なる第２レストランと関連する第２サーバを含む情報管理システムにおける情報提供方法であって、端末機器から前記識別情報及び前記第２レストランを示す店舗ＩＤを取得し、前記店舗ＩＤは前記端末機器において選択され、前記第１サーバから前記識別情報に対応する前記嗜好情報を取得し、前記識別情報に関する前記嗜好情報は、前記第１サーバにおいて前記識別情報が特定する前記ユーザによって許諾されていると判断した場合に前記第１サーバから取得され、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列し、前記メニュー情報は、前記第２サーバに保持され、前記順序にて配列されたメニュー内容のメニュー情報を前記端末機器に送信し、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報を表示させる。

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

本開示の情報提供システムの全体像の一例を示す図である。 本実施の形態に係る情報提供システムの具体的な構成の一例を示す図である。 飲食品を注文するユーザがマッチングアプリを起動した直後に情報端末に表示される認証画面の一例を示す図である。 他の一例に係る認証画面を示す図である。 マッチングアプリによるユーザ認証が終わった直後に表示されるホーム画面の一例を示す図である。 情報端末に表示されるマップ画面の一例を示す図である。 情報端末に表示される個別メニュー情報の表示画面の一例である個別メニュー画面を示す図である。 情報端末に表示される個別メニュー情報の表示画面の別の一例である個別メニュー画面を示す図である。 情報端末に表示される標準メニュー情報の表示画面の一例である標準メニュー画面を示す図である。 図７に示す個別メニュー画面において、ユーザが飲食品を注文する様子を示した図である。 図１０で選択した飲食品の注文を確定する際に表示される注文確定画面の一例を示す図である。 注文履歴を記憶する注文履歴データベースのデータ構成の一例を示す図である。 標準メニュー情報のデータ構成の一例を示す図である。 あるユーザについて、標準メニュー情報に含まれる各飲食品に対して注文回数を纏めた表である。 行きつけの系列の店舗に来店したユーザにより飲食品が注文される際の情報提示システムの処理の一例を示すシーケンス図である。 初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。 図１６のシーケンス図のステップＳ３０における処理に着目したときの処理の一例を示す図である。 本実施の形態における情報提供システムの具体的な実装形態の一例を示す図である。 マッチングアプリが起動してから個別メニュー画像を表示するまでのファイルに対するマッチングアプリの処理の一例を示すフローチャートである。 実施の形態２において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。 実施の形態２において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の他の一例を示すシーケンス図である。 実施の形態２において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理のさらに他の一例を示すシーケンス図である。

（本開示に至る経緯）
近年、外食産業の発達により、例えば、ファミリーレストラン、ハンバーガーショップ、コーヒーショップ、中華レストラン等の飲食品を提供する様々なチェーンストアが全国規模で展開されている。同一系列のチェーンストアであれば、異なる店舗であってもメニュー表は同じであることが多い。そのため、はじめて来店した店舗が、ユーザの行きつけのチェーンストアの店舗であれば、ユーザは見慣れたメニュー表を参照して効率よく飲食品の注文を行うことができる。

しかしながら、利用したことのないチェーンストアが運営する店舗にユーザがはじめて来店した場合、ユーザは見慣れていないメニュー表を参照して飲食品を注文することになり、注文に手間がかかってしまう。

上述の特許文献１の技術では、注文履歴データベースからユーザの注文履歴に関する情報が取得され、その注文履歴に関する情報に基づいてユーザに提案する注文案が生成されている。しかしながら、特許文献１の技術では、ユーザが来店している店舗における注文履歴のみを用いて注文案が作成されている。したがって、特許文献１の技術では、ユーザが店舗に例えば初めて来店した場合、その店舗の注文履歴がないため、注文案の生成ができなくなる。そのため、特許文献１の技術では、上述の手間を解消することはできない。

ここで、注文案の生成ができなかった場合に、店舗において一般客に用いられる汎用メニューを携帯端末に通知することが考えられる。しかしながら、携帯端末は表示面積に制約があるため、ユーザが関心のない飲食品が優先的に表示される可能性がある。この場合、ユーザはスクロール操作等により希望する飲食品を探し出すことが要求され、注文に手間がかかってしまう。

本開示は、このような課題を解決するためになされたものであり、表示面積に制約がある端末機器において効率的に自己の嗜好に合った飲食品を選択することが可能な技術を提供することである。

本開示の一態様に係る情報提供方法は、第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する第１サーバと通信する第２サーバであって前記第１レストランと系列が異なる第２レストランと関連する第２サーバを含む情報管理システムにおける情報提供方法であって、端末機器から前記識別情報及び前記第２レストランを示す店舗ＩＤを取得し、前記店舗ＩＤは前記端末機器において選択され、前記第１サーバから前記識別情報に対応する前記嗜好情報を取得し、前記識別情報に関する前記嗜好情報は、前記第１サーバにおいて前記識別情報が特定する前記ユーザによって許諾されていると判断した場合に前記第１サーバから取得され、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列し、前記メニュー情報は、前記第２サーバに保持され、前記順序にて配列されたメニュー内容のメニュー情報を前記端末機器に送信し、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報を表示させる。

本態様によると、第１レストランにて注文した注文履歴を含むユーザの嗜好情報が、前記ユーザを特定する識別情報と対応して情報管理システムにおいて管理されている。前記ユーザが利用する端末機器において前記第１レストランと異なる第２レストランを示す店舗ＩＤが選択される。この選択によって、ユーザの嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容が配列され、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報が表示される。

このことにより、ユーザは、例え前記第２レストランを初めて利用する場合であっても、それまで利用したことがある前記第１レストランでの注文履歴などを含む嗜好情報に基づいて、表示面積に制約がある前記端末機器の表示画面において、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を優先的に表示できる。

従って、ユーザは、例え前記第２レストランを初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。

さらに、本態様によると、第２サーバは、ユーザに許諾されていると第１サーバに判断された場合に、嗜好情報を第１サーバから取得することができる。これにより、ユーザの許諾がない事業者に対して嗜好情報が渡らないようにしながらも、ユーザが初めて利用する第２レストランにおいて、ユーザの嗜好情報が考慮されたメニュー情報を表示できる。

上記情報提供方法において、前記第２レストランは、前記第１レストランとは異なる系列のコーヒーショップであってもよい。

本態様によれば、ある系列のコーヒーショップにおいて、別の系列のコーヒーショップの注文履歴を含む嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報が表示される。そのため、例えば、ある系列のコーヒーショップを初めて利用する場合であっても、ユーザは効率的に自己の嗜好に合った飲食品を選択できる。

上記情報提供方法において、前記第２レストランは、前記第１レストランとは異なる系列のハンバーガーショップであってもよい。

本態様によれば、ある系列のハンバーガーショップにおいて、別の系列のハンバーガーショップの注文履歴を含む嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報が表示される。そのため、例えば、ある系列のハンバーガーショップを初めて利用する場合であっても、ユーザは効率的に自己の嗜好に合った飲食品を選択できる。

上記制御方法において、前記第２レストランは、前記第１レストランとは異なる系列のレストランであってもよい。

本態様によれば、ある系列のレストランにおいて、別の系列のレストランの注文履歴を含む嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報が表示される。そのため、例えば、ある系列のレストランを初めて利用する場合であっても、ユーザは効率的に自己の嗜好に合った飲食品を選択できる。

尚、上記レストランとは、２種類以上の飲料及び／又は料理を提供する飲食店であれば良い。例えば、幅広い料理を提供するファミリーレストランまたは居酒屋であっても良いし、軽食や飲料を提供するカフェであっても良いし、各種のステーキを提供するステーキ専門店であっても良いし、酒類が多く取り揃えられたバーであっても良い。

尚、第２レストランは、第１レストランと同種類の料理を提供するような同じ形態の飲食店に限られない。例えば、第１レストランはファミリーレストランであって、第２レストランはカフェという組み合わせであっても良い。この場合はファミリーレストランでのユーザの過去の注文履歴に基づいてカフェのメニュー内容が配列されたメニュー情報が表示される。

尚、第１レストランはユーザの注文履歴がある飲食店の全てまたはその一部を指し示しても良い。この場合はユーザの過去の飲食店での注文履歴の全てまたは一部に基づいて、第２レストランのメニュー内容が配列されたメニュー情報が表示される。多くの注文履歴を用いることで第２レストランのメニュー内容の配列が最適化できる可能性がある。

上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴がない場合、前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列してもよい。

本態様によれば、第２レストランにおいてユーザの注文履歴がない場合、第１レストランの注文履歴を含む嗜好情報に基づいたメニュー情報が表示される。これにより、ユーザは、第２レストランの系列が初めて利用する系列である場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。

上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴がある場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列してもよい。

第２レストランが初めて利用するレストランではない場合、第１レストランの注文履歴を含む嗜好情報よりも第２レストランの注文履歴に基づいてメニュー情報を生成した方がユーザにとって都合がよい場合がある。本態様によれば、第２レストランにおいてユーザの注文履歴がある場合、第２レストランの注文履歴を含む嗜好情報に対応する順序にてメニュー内容が配列されたメニュー情報が表示される。したがって、ユーザは、第２レストランを過去に利用したことがある場合、第２レストランの注文履歴が反映されたメニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。

上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴が所定量に満たない場合、前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列してもよい。

第２レストランを利用するのが初めてではない場合であっても利用回数が少なければ、第２レストランの注文履歴に基づいてユーザのメニュー情報を生成すると、ユーザの嗜好が十分に反映されたメニュー情報が生成できない可能性がある。本態様によれば、第２レストランでの注文履歴が所定量に満たない場合、第２レストランでの注文履歴だけでなく、他のレストランの注文履歴も含む嗜好情報に基づいてメニュー内容が配列されたメニュー情報が表示される。そのため、第２レストランにおいて、ユーザの嗜好が十分に反映されていないメニュー情報が表示されることを防止できる。

上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴が前記所定量以上である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列してもよい。

第２レストランをある程度利用している場合、第１レストランの注文履歴を含む嗜好情報よりも第２レストランの注文履歴に基づいてメニュー情報を生成した方がユーザにとって都合がよい場合がある。本態様によれば、第２レストランでの注文履歴が所定量以上の場合、第２レストランの注文履歴に基づいてメニュー内容が配列されたメニュー情報が表示される。したがって、ユーザは、第２レストランをある程度利用したことがある場合、第２レストランの注文履歴が反映されたメニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。

上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの直近の注文履歴が所定期間より前である場合、前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列してもよい。

第２レストランの利用が初めてではない場合であっても、久しく利用していない場合、例えば利用していない期間にユーザの嗜好が変化するというようなケースも想定され、第２レストランのメニュー情報の表示が妥当でないこともある。本態様によれば、このような場合において、第１レストランの注文履歴を含む嗜好情報が反映されたメニュー情報が表示されるため、ユーザは自己の嗜好に合った飲食品を効率よく選択できる。

上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの直近の注文履歴が前記所定期間内である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列してもよい。

第２レストランの利用が初めてではなく、久しぶりに利用するものでもない場合、第１レストランの注文履歴に基づく嗜好情報よりも第２レストランの注文履歴が反映されたメニュー情報を表示した方がユーザにとって都合がよいこともある。本態様では、このような場合において、第２レストランの注文履歴が反映されたメニュー情報が表示されるため、ユーザは自己の嗜好に合った飲食品を効率よく選択できる。

上記情報提供方法において、設定期間内の前記第２レストランでの注文回数が一定回数以下である場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列してもよい。

本態様によれば、第２レストランでの注文回数が一定回数以下である場合、第２レストランでの注文履歴だけでなく、他のレストランの注文履歴も含む嗜好情報に基づいてメニュー内容が配列されたメニュー情報が表示される。そのため、第２レストランにおいて、ユーザの嗜好が十分に反映されていないメニュー情報が表示されることを防止できる。

上記情報提供方法において、前記第１サーバにおいて、前記第１レストランにて注文した前記注文履歴が前記第１レストランを示す店舗ＩＤと対応付けて記憶されていてもよい。

本態様によれば、第１レストランにて注文した注文履歴が第１レストランを示す店舗ＩＤと対応付けて記憶されている。このため、第１レストランを示す店舗ＩＤを用いることにより、第１レストランにて注文した注文履歴を参照することが容易になる。

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

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

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

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

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

Ｓｏｃｉｅｔｙ５．０では、ユーザの嗜好を示す嗜好情報のような個人情報は、情報銀行と称される個人情報を管理する事業者のサーバによって、本人許諾のない第三者にはアクセスできないように暗号化、秘匿化された上で一元管理される。これらの個人情報の多くはユーザの意識的な入力操作を必要とせず、情報銀行の管理の下、収集が継続され随時更新される。

個人最適化された飲食品の注文システムの一例としては、レストランのサーバから個人の情報端末にメニュー情報を送信し、ユーザの嗜好に即した飲食品からなるメニューを推奨メニューとして情報端末上に提示するものが考えられる。

図１は、本開示の情報提供システムの全体像の一例を示す図である。図１の情報提供システムは、Ｓｏｃｉｅｔｙ５．０を踏まえて構成されたシステムであり、個人情報を利用する一消費者であるユーザに適した商品又はサービスをユーザに提案し、商品又はサービスのユーザによる選択を支援する選択支援サービスを提供するシステムである。本実施の形態では選択支援サービスとして飲食品の注文を支援するサービスを主眼としている。具体的には情報提供システムは、外食時にユーザが飲食品を注文するために閲覧するメニュー情報を、そのユーザの個人情報とマッチングさせ、そのユーザにとって最適なメニューを提示するシステムである。

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

２つ目の機器群は第１サーバ２００を含む機器群である。

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

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

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

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

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

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

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

３つ目の機器群は、各事業者が各事業者固有のデータを管理する第２サーバ３００を含む機器群である。各事業者は、第２サーバ３００を所有又はレンタルし、自社の商品及び／又は自社のサービスに関する情報を管理及び／又は提供している。本実施の形態では、事業者として、チェーンストアを運営する会社が該当する。図１の例では、レストランＡ系列が運用する第２サーバ３００、レストランＢ系列が運用する第２サーバ３００、及びレストランＣ系列が運用する第２サーバ３００の３つの第２サーバ３００が例示されている。レストランＡ系列は、例えば、Ａ社が経営するＡ系列のチェーンストアであり、レストランＢ系列は、例えば、Ｂ社が経営するＢ系列のチェーンストアであり、レストランＣ系列は、例えば、Ｃ社が経営するＣ系列のチェーンストアである。チェーンストアは、ブランド、経営方針、サービスの内容、及び外観などに統一性を持たせ、多数の店舗の運営や管理を行う経営形態を指す。チェーンストアが展開するレストランとしては、ファミリーレストラン、コーヒーショップ及びハンバーガーショップなどが含まれる。なお、事業者は、お弁当屋又はファストフード店のように調理済み料理のテイクアウトが可能な中食事業者であってもよい。さらに、事業者は、スーパーマーケットのように自宅で調理することを主眼においた内食向けの食材販売を行う事業者であってもよい。第２サーバ３００は例えばクラウドサーバで構成される。

図１の例では、レストランＡ系列、レストランＢ系列、レストランＣ系列はそれぞれ異なる会社が経営するものとして説明したが、これは一例であり、同一の会社が経営してもよい。また、図１の例では、第２サーバ３００は３つとして説明したが、これは一例であり、４つ以上であってもよいし、１つ又は２つであってもよい。

本実施の形態の情報提供システムの効果の１つとしては、個人情報が不特定多数の事業者に渡らないことが挙げられる。第１サーバ２００の情報銀行が、本人許諾に基づき、特定の事業者に対してのみ、特定の個人情報を共有することが許可されているためである。

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

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

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

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

図１に示す情報提供システムは、さらに生体センサー６００及びパブリック情報サーバ５００を含んでいる。

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

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

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

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

情報端末１００は、スマートフォン又はタブレット端末等の携帯型の情報処理装置で構成されている。本実施の形態において、情報端末１００は、レストラン系列の店舗で飲食品を注文するユーザによって携帯される。情報端末１００は、通信部１０１、メモリ１０２、カメラ１０３、演算部１０４、ディスプレイ１０５、操作部１０６、及びＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）センサー１０７を含む。

通信部１０１は、情報端末１００をネットワークＮＴに接続する通信回路で構成されている。通信部１０１は、ユーザが操作部１０６を操作して選択した第１レストランとは系列の異なる第２レストランの店舗ＩＤをユーザの識別情報と対応付けて第１サーバ２００に送信する。第１レストランは、ユーザの行きつけのレストランチェーンのレストランである。第２レストランとは、第１レストランとは系列が異なるレストランである。

通信部１０１は、第２サーバ３００から送信された後述するメニュー情報を受信する。演算部１０４は通信部１０１が受信したメニュー情報をディスプレイ１０５に表示させる。通信部１０１は、演算部１０４の制御の下、ユーザが注文した飲食品を示す注文情報を第２サーバ３００に送信する。メモリ１０２は、フラッシュメモリ等の不揮発性のストレージ装置で構成されている。通信部１０１は、ＧＰＳセンサー１０７が検出した情報端末１００の地点の周辺地域の地図情報である周辺地図情報を受信する。この周辺地図情報はディスプレイ１０５に表示される。

メモリ１０２は、ユーザを特定するための識別情報を予め記憶する。

カメラ１０３は、ＣＭＯＳセンサー等で構成される撮像装置である。カメラ１０３は、例えば顔認証を行う際にユーザの顔を撮影するために用いられる。

演算部１０４は、ＣＰＵ等のプロセッサで構成されている。演算部１０４は、情報端末１００のＯＳ、上述のマッチングアプリ、及びブラウザ等を実行する。ＧＰＳセンサー１０７は、ＧＰＳ衛生からの信号に基づいて情報端末１００の位置を検出する。

ディスプレイ１０５は、例えば液晶表示パネルまたは有機ＥＬパネル等で構成され、種々の画像を表示する。例えば、ディスプレイ１０５は、上述のメニュー情報を表示する。さらに、ディスプレイ１０５は、周辺地図情報を表示する。

操作部１０６は、例えばタッチパネル等の入力装置で構成される。操作部１０６は、周辺地図情報に表示されたレストランのうち、ユーザが来店を希望するレストランを選択する操作を受け付ける。操作部１０６は、メニュー情報の中からユーザが希望する飲食品を選択する指示を受け付ける。

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

次に、第１サーバ２００の構成について説明する。第１サーバ２００は、通信部２０１、演算部２０２、及びメモリ２０３を含む。通信部２０１は、第１サーバ２００をネットワークＮＴに接続するための通信回路で構成されている。通信部２０１は、情報端末１００から情報端末１００のユーザを特定する識別情報及び第１レストランと系列が異なる第２レストランを示す店舗ＩＤを受信する。この店舗ＩＤは、情報端末１００を操作するユーザが選択した店舗の識別情報である。通信部２０１は、演算部２０２が生成した後述する個別メニュー情報を第２レストランを選択したユーザの情報端末１００に送信する。

演算部２０２はＣＰＵ等のプロセッサで構成されている。演算部２０２は、メモリ２０３が記憶するユーザの個人情報を処理する。

演算部２０２は、第２レストランを選択したユーザの情報端末１００の周辺に存在する１以上のレストランを表す店舗情報を情報端末１００に提供する。情報端末１００のユーザはこの提供された店舗情報から第２レストランを選択することになる。この選択により情報端末１００からユーザが選択した第２レストランの店舗ＩＤとユーザの識別情報とが第１サーバ２００に送信される。

演算部２０２は、情報端末１００から店舗ＩＤと対応付けて送信されたユーザの識別情報に対応する嗜好情報をメモリ２０３から抽出する。演算部２０２は、抽出した嗜好情報及び店舗ＩＤが示す第２レストランのメニュー情報に基づき、嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報である個別メニュー情報を生成する。この個別メニュー情報は、店舗を選択したユーザの情報端末１００のディスプレイ１０５に表示される。第２レストランのメニュー情報は、第２レストランが属する系列において一般の顧客向けに生成された標準メニュー情報である。この標準メニュー情報には、第２レストランが属する系列が定めた所定の順序にてメニュー内容が配列されている。メニュー内容とは、第２レストランが提供する飲食品のことを指す。

ここで、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴がない場合、メモリ２０３から抽出した嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランが属する系列を初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。

一方、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴がある場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランを過去に利用したことがある場合、第２レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。

なお、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量に満たない場合、当該ユーザの識別情報に対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。

この場合、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量以上である場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。

さらに、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの直近の注文履歴が所定期間より前である場合、当該ユーザの識別情報に対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。

演算部２０２は、例えば、通信部２０１が、許諾ユーザについての個人情報の取得を要求する信号を受信したとする。許諾ユーザとは、情報端末１００又は第２サーバ３００から要求された第１サーバ２００に記憶された個人情報の読み出しが直接的に許諾されたユーザ、又は信託された第三者を経由して間接的に許諾されたユーザである。この場合、演算部２０２は、情報端末１００又は第２サーバ３００からの要求に応じて、メモリ２０３に記憶されている許諾ユーザの個人情報を読み出して通信部２０１に返信させる。なお、読み出される個人情報は、管理されている個人情報の全体であってもよいし、管理されている個人情報のうち、要求された特定項目に関連する情報だけ（個人情報の一部のみ）であってもよい。

メモリ２０３は、ハードディスクドライブ等の不揮発性の複数のストレージ装置で構成されている。メモリ２０３は、１以上のユーザの個人情報を記憶する。個人情報には各ユーザの嗜好情報が含まれる。嗜好情報は、各ユーザの嗜好を示す情報である。嗜好情報には、各ユーザの飲食品の注文履歴が含まれる。本実施の形態では、注文履歴はユーザ毎に生成された図１２に示す注文履歴データベースＤ２によって管理され、メモリ２０３に記憶されている。

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

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

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

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

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

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

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

図６は、情報端末１００に表示されるマップ画面Ｇ４の一例を示す図である。このマップ画面Ｇ４は、ホーム画面Ｇ３においてマップボタン１４０３を選択する操作が入力された場合に表示される。マップ画面Ｇ４には、情報端末１００の現在の地点を含む地域の地図が含まれる。さらに、マップ画面Ｇ４には、この地域内にあるマッチングアプリに対応した店舗情報が表示されている。ここでは、ユーザの現在の地点を示すアイコン３２００に加えて、レストランＡ系列の店舗Ａ１、レストランＡ系列の店舗Ａ２、本屋Ｋ系列の店舗Ｋ１、及びレストランＢ系列の店舗Ｂ１が表示されている。

ユーザはこのマップ画面Ｇ４を見ながら、来店を希望する店舗を選択する。この例では、アイコン３２１０で示される、現在の地点から一番近いレストランＢ系列の店舗Ｂ１が選択される。ユーザは、例えば、アイコン３２１０を指でタッチすることで、レストランＢ系列の店舗Ｂ１を選択することができる。アイコン３２１０がタッチされると、マッチングアプリは、アイコン３２１０が示すレストランＢ系列の店舗Ｂ１の接続先情報及び店舗ＩＤを取得する。さらに、マッチングアプリはユーザの識別情報（ユーザＩＤ）をメモリ１０２から取得する。ユーザＩＤは、図１８で後述するように、情報端末１００の「ａｃｃｏｕｎｔ」ディレクトリ下のｕｓｅｒ＿ａｃｃｏｕｎｔ．ｘｍｌファイルに格納されている。接続情報は例えばレストランＢ系列の第２サーバ３００と通信するためのアドレス情報（例えば、ＵＲＬ等）である。

マッチングアプリは、取得した店舗ＩＤとユーザＩＤとをもとに、第１サーバ２００とレストランＢ系列の第２サーバ３００と連携して、当該ユーザの個別メニュー情報を取得する。

具体的には、マッチングアプリは、店舗ＩＤとユーザＩＤとを含む個別メニューの取得要請を第１サーバ２００に送信する。この取得要請を受信した第１サーバ２００は、店舗ＩＤをもとに、その店舗が提供可能な標準メニュー情報の取得要請をレストランＢ系列の第２サーバ３００に送信する。この取得要請を受信した第２サーバ３００は、レストランＢ系列の標準メニュー情報を第１サーバ２００に送信する。標準メニュー情報は図１８で後述する第２サーバ３００の「ＲｅｓＢ．ｈｔｍｌ」ファイル及び「ＲｅｓＢ．ｃｓｓ」ファイルに記憶されている。

レストランＢ系列の標準メニュー情報を受信した第１サーバ２００は、取得した標準メニュー情報を、このユーザＩＤを持つユーザに対して最適化するために、このユーザのレストランＢ系列での過去の注文履歴をメモリ２０３から取得する。ここでは、このユーザについてレストランＢ系列の注文履歴がメモリ２０３になかったとする。

この場合、第１サーバ２００は、このユーザについて、例えば他のレストラン系列の注文履歴をメモリ２０３から取得する。そして、第１サーバ２００は、他のレストラン系列の注文履歴の中からユーザによりよく注文されている飲食品の表示順序が上位になるように、レストランＢ系列の標準メニューの飲食品の順序を変更する。例えば、このユーザについて他のレストランの注文履歴から「カフェモカ」がよく注文されていたとする。この場合、第１サーバ２００は、レストランＢ系列の個別メニュー情報において、カフェモカの注文がより容易になるように、「カフェモカ」の表示順序を上位に配列する。さらに、この場合、第１サーバ２００は、「カフェモカ」の表示サイズ及び／又は色使いの識別が容易になるように、「カフェモカ」の表示態様をデフォルトの表示態様から変更してもよい。

上記のようにして生成されたレストランＢ系列の個別メニュー情報は、第１サーバ２００から情報端末１００へ送信される。

図７は、情報端末１００に表示される個別メニュー情報の表示画面の一例である個別メニュー画面Ｇ５を示す図である。この個別メニュー画面Ｇ５は、マップ画面Ｇ４でユーザが選択したレストランＢ系列の個別メニュー画面である。個別メニュー画面Ｇ５の上部には「レストランＢ Ｂ１店 カスタムメニュー」と記載されている。これは、この個別メニュー画面Ｇ５に掲載されているメニューが、ユーザが選択した店舗Ｂ１が属するレストランＢ系列の標準メニュー情報と、メモリ２０３に記憶されたユーザの注文履歴とを考慮してパーソナライズされたメニューであることを意味している。

この例では、このユーザについてレストランＢ系列の注文履歴はメモリ２０３に記憶されていなかったものの、このユーザについて他のレストラン系列の注文履歴がメモリ２０３に記憶されていた。そして、このユーザについて他のレストラン系列の注文履歴が示す各飲食品に対する注文回数がアイスクリーム、カプチーノ、カフェモカ、タピオカヨーグルト、アイスコーヒー、チョコクッキーの順であった。そのため、個別メニュー画面Ｇ５ではこの順で、各飲食品を示すタイルオブジェクト７０１が配列されている。

これにより、ユーザの嗜好に合う飲食品がより注文しやすい位置に表示される結果、ユーザは、自己の嗜好に合う飲食品を効率よく選択することができる。図７の例では、各タイルオブジェクト７０１の表示順位は、左上に向かうほど上位であり、右下に向かうほど下位という順位である。但し、これは一例であり、右上に向かうほど上位であり、左下に向かうほど下位という順位であってもよい。

図７の例では、タイルオブジェクト７０１は、３行２列でマトリックス状に表示されているが、これは一例であり、３行１列或いは４行２列というように他の行列数で表示されてもよい。さらに、図７の例において、初期画面に表示できなかった飲食品のタイルオブジェクト７０１は、スクロール操作により表示可能である。初期画面とは個別メニュー画面Ｇ５が表示された際に最初に表示される画面である。

ユーザが注文しやすいような個別メニュー画面Ｇ５のデザインは、さらに、下記のようなものであってもよい。例えば、注文回数が上位の飲食品をタイルオブジェクト７０１が個別メニュー画面Ｇ５の初期画面内に優先的に配列されたり、その初期画面の中で注文回数が多い飲食品ほどタイルオブジェクト７０１が画面中央に配列されたりしてもよい。さらに、このような配列がされたうえで、注文回数が多い飲食品ほどタイルオブジェクト７０１のサイズが大きく表示されたり、注文回数が多い飲食品ほど他の飲食品と区別しやすいように異なる色使い又は境界線の太さでタイルオブジェクト７０１が表示されたり、注文回数が多い飲食品ほど商品名、価格、及び／又は商品の画像が装飾されたりしてもよい。

図８は、情報端末１００に表示される個別メニュー情報の表示画面の別の一例である個別メニュー画面Ｇ６を示す図である。この個別メニュー画面Ｇ６では、注文回数が上位から所定数（ここでは、上位２つ）の飲食品（ここでは、アイスクリーム、カプチーノ）のタイルオブジェクト７０１１が他の飲食品（ここでは、カフェモカ、タピオカヨーグルト）のタイルオブジェクト７０１２よりも上側に配置されている。カフェモカ及びタピオカヨーグルトのタイルオブジェクト７０１２は、個別メニュー画面Ｇ６の３行目に配置されている。

さらに、タイルオブジェクト７０１１は、タイルオブジェクト７０１２よりもサイズが大きく表示されている。さらに、タイルオブジェクト７０１１は、タイルオブジェクト７０１２よりも枠８０１が太くされると共に枠８０１に装飾が施されている。枠８０１に対する装飾は、例えば、枠８０１を金色、赤色などの目立つ色で表示させる態様が採用できる。さらに、タイルオブジェクト７０１１は、タイルオブジェクト７０１２よりも飲食品を示す画像８０２が大きくされている。さらに、タイルオブジェクト７０１１は、飲食品を示す画像８０２の周囲にデフォルメするマーク８０３（ここでは、星マーク）が表示されている。さらに、タイルオブジェクト７０１１は、タイルオブジェクト７０１２よりも飲食品名の文字列８０４のサイズが大きく表示されている。この文字列８０４は、影付き文字などで表示することによってデフォルメされていてもよい。さらに、タイルオブジェクト７０１１は、お気に入りであることを示すマーク８０５（ここでは、ハートマーク）が表示されている。

図８において、アイスクリームのタイルオブジェクト７０１１がカプチーノのタイルオブジェクト７０１１よりも上側に配置されているのは、アイスクリームに対するユーザの注文回数がカプチーノに対するユーザの注文回数よりも多かったからである。図８において、初期画面に表示できなかった飲食品のタイルオブジェクト７０１２はスクロール操作によって表示されてもよい。この場合、個別メニュー画面Ｇ６が縦方向にスクロール操作されることで、全タイルオブジェクトが縦方向にスクロールされてもよい。或いは、タイルオブジェクト７０１２の表示欄を横方向にスクロール操作することで、タイルオブジェクト７０１１の表示は維持されたまま、タイルオブジェクト７０１２のみがスクロールされてもよい。

図９は、情報端末１００に表示される標準メニュー情報の表示画面の一例である標準メニュー画面Ｇ７を示す図である。標準メニュー画面Ｇ７では、ユーザごとに最適化されていないレストランＢ系列の店舗Ｂ１の標準メニュー情報が示されている。

標準メニュー画面Ｇ７の上部には「レストランＢ Ｂ１店 標準メニュー」と記載されている。これは、この標準メニュー画面Ｇ７に掲載されているメニューが、レストランＢ系列の標準メニューあることを意味している。標準メニュー画面Ｇ７には、例えば３行２列のマトリックス状にタイルオブジェクト７０１が配置されている。ここでは、例えばレストランＢ系列において人気が高い飲食品ほど注文しやすい位置にタイルオブジェクト７０１が配置されている。具体的には、左上側ほど人気が高く、右下側ほど人気が低くなるようにタイルオブジェクト７０１が配置されている。標準メニュー画面Ｇ７は、スクロール操作により、初期画面で表示されなかったタイルオブジェクト７０１が表示可能に構成されている。

標準メニュー画面Ｇ７では、ユーザ個別の嗜好情報が考慮されることなくタイルオブジェクト７０１が配置されているため、ユーザは希望する飲食品のタイルオブジェクト７０１を探し出すのに手間がかかる。

これに対して、個別メニュー画面Ｇ５，Ｇ６ではユーザの嗜好に合う飲食品が注文し易い位置に配置されているため、ユーザは希望する飲食品のタイルオブジェクト７０１を容易に探し出せる可能性が高くなる。さらに、個別メニュー画面Ｇ５，Ｇ６では第１サーバ２００が記憶しているユーザの注文履歴に基づいて、ユーザの注文回数が多い飲食品のタイルオブジェクト７０１ほどより上位に配置されている。そのため、ユーザが選択した店舗Ｂ１はもとより、その店舗Ｂ１が属するレストランＢ系列のいずれの店舗にもユーザが来店したことがない場合であっても、個別メニュー画面Ｇ５，Ｇ６には、ユーザの嗜好が考慮された順序でタイルオブジェクト７０１が配列されている。

例えば、ユーザはレストランＡ系列の店舗Ａ１が行きつけの店舗であり、その店舗Ａ１においてユーザは自己の情報端末１００に自己の注文履歴が考慮された個別メニュー画面を表示させて、飲食品を注文していたとする。この場合、ユーザはレストランＢ系列の店舗Ｂ１に初めて来店したにもかかわらず、自己の情報端末１００において行きつけのレストランＡ系列の個別メニュー画面と同様の順序で飲食品が配列された個別メニュー画面Ｇ５，Ｇ６を表示させることが可能となる。これにより、ユーザは希望する飲食品を速やかに探し出すことが可能になると共に安心感も与えることが可能となる。さらに、ユーザに対して初めて来店した系列の店舗であるにもかかわらず見慣れた順序で飲食品が配置された個別メニュー画面が表示されるため、ユーザに驚きを与え、注文に対する関心を向上させることも可能となる。

図１０は、図７に示す個別メニュー画面Ｇ５において、ユーザが飲食品を注文する様子を示した図である。ここでは、カプチーノのタイルオブジェクト７０１３とチョコクッキーのタイルオブジェクト７０１４とが選択されている。そのため、タイルオブジェクト７０１３，７０１４の色がデフォルトの第１色から選択されたことを示す第２色に変更されている。さらに、タイルオブジェクト７０１３，７０１４がそれぞれ１回タッチされたため、タイルオブジェクト７０１３，７０１４のそれぞれに注文した個数を示す文字列である「１」が表示されている。

図１１は、図１０で選択した飲食品の注文を確定する際に表示される注文確定画面Ｇ８の一例を示す図である。注文確定画面Ｇ８は、図１０に示す個別メニュー画面Ｇ５において、図略の「注文に進む」ボタンを押すことで表示される。注文確定画面Ｇ８には、個別メニュー画面Ｇ５で選択されたカプチーノのタイルオブジェクト７０１３と、チョコクッキーのタイルオブジェクト７０１４とが表示されている。タイルオブジェクト７０１３，７０１４の下側には注文した飲食品の合計金額を示す合計金額表示欄７０１５が表示されている。ここでは、「カプチーノ」と「チョコクッキー」とが１つずつであり合計金額が５００円であったため、合計金額表示欄７０１５には「５００円」が表示されている。合計金額表示欄７０１５の下側には注文を確定するための注文ボタン７０１６が表示されている。注文確定画面Ｇ８に表示された注文内容に納得したユーザは注文ボタン７０１６をタッチする。これにより、注文が完了する。

（注文処理）
図１５は、行きつけの系列の店舗に来店したユーザにより飲食品が注文される際の情報提示システムの処理の一例を示すシーケンス図である。

ステップＳ１において情報端末１００はユーザからマッチングアプリの起動指示を受け付けてマッチングアプリを起動し、マップ画面Ｇ４をディスプレイ１０５に表示する。具体的には、マッチングアプリが起動すると、マッチングアプリは認証画面Ｇ１又は認証画面Ｇ２を表示してユーザ認証を行い、ユーザ認証ができた場合、ホーム画面Ｇ３を表示する。このホーム画面Ｇ３においてマップボタン１４０３がタッチされると、マッチングアプリはマップ画面Ｇ４を表示する。

ステップＳ２において、マッチングアプリは、ＧＰＳセンサー１０７が検知した情報端末１００の現在の地点を示す位置情報を取得し、当該地点を含む周辺地域の地図情報である周辺地図情報の取得要請をパブリック情報サーバ５００に送信する。

この取得要請を受信したパブリック情報サーバ５００は、この取得要請に含まれる位置情報から情報端末１００の現在の地点を取得し、その地点を基準に所定範囲の地域の地図情報を周辺地図情報として地図データベースから抽出し、マッチングアプリに送信する。周辺地図情報を受信したマッチングアプリは、周辺地図情報が示す地図を含むマップ画面Ｇ４を表示する（ステップＳ３）。地域を示す所定範囲は、例えば現在の地点から半径１ｋｍ又は２ｋｍの範囲等、今から外食をしようとするユーザが徒歩又は車によって来店することが可能な範囲である。

マップ画面Ｇ４を表示したマッチングアプリは、受信した周辺地図情報が示す地図内に含まれる店舗であって、第１サーバ２００に登録された店舗の店舗情報の取得要請を第１サーバ２００に送信する（ステップＳ４）。

この取得要請を受信した第１サーバ２００はメモリ２０３から該当する地図内に含まれる店舗の店舗情報を抽出し、マッチングアプリに送信する。メモリ２０３には、例えば各店舗の店舗情報を含む店舗データベースが記憶されている。各店舗情報には店舗の店舗ＩＤ、店舗名、系列、位置情報、及び接続情報が含まれている。したがって、第１サーバ２００は、店舗情報の取得要請が示す地図の地域内に含まれる店舗を、店舗データベースに記憶された各店舗の位置情報から特定すればよい。

抽出された店舗情報を受信したマッチングアプリは、その店舗情報をマップ画面Ｇ４の地図上に表示する（ステップＳ５）。これにより、図６のマップ画面Ｇ４に示されるように、ユーザの現在の地点の周辺地域に含まれる店舗がその周辺地域を示す地図上に表示される。

ステップＳ６において、マッチングアプリは、マップ画面Ｇ４に表示された店舗のうちレストランＡ系列の店舗Ａ１を選択するユーザの指示を受け付ける。ここで、店舗Ａ１はユーザが行きつけの店舗である。

ステップＳ７において、マッチングアプリは、店舗Ａ１の個別メニュー情報の取得要請を第１サーバ２００に送信する。この取得要請には店舗Ａ１の店舗ＩＤ、接続情報、及び情報端末１００のユーザＩＤ等が含まれる。

この取得要請を受信した第１サーバ２００は、店舗Ａ１が属するレストランＡ系列の標準メニュー情報の取得要請をレストランＡ系列又は店舗Ａ１の第２サーバ３００に送信する（ステップＳ８）。

この取得要請を受信したレストランＡ系列又は店舗Ａ１の第２サーバ３００は、店舗Ａ１の標準メニュー情報を第１サーバ２００に送信する。これにより、第１サーバ２００は店舗Ａ１の標準メニュー情報を受信する（ステップＳ９）。ここで送信される店舗Ａ１の標準メニュー情報は、レストランＡ系列の各店舗で共通のメニュー情報であってもよいし、レストランＡ系列の各店舗で一部分が異なるメニュー情報であってもよい。

店舗Ａ１の標準メニュー情報を受信した第１サーバ２００は、メモリ２０３に記憶された該当するユーザのレストランＡ系列の各店舗での注文履歴を集計して、店舗Ａ１向けの個別メニュー情報を生成する（ステップＳ１０）。生成された店舗Ａ１向けの個別メニュー情報は第１サーバ２００により情報端末１００（マッチングアプリ）へ送信され、マッチングアプリは、この個別メニュー情報を受信する（ステップＳ１１）。

ステップＳ１１までの処理において、情報端末１００に表示される各種画面は第１サーバ２００の管理者（情報銀行）のスタイルでデザインされたものが使用される。一方、ステップＳ１２からの処理においては、情報端末１００に表示される各種画面はレストランＡ系列のスタイルでデザインされたものが使用される。

尚、ステップＳ１２からの処理において、情報端末１００に表示される各種画面は、レストランＡ系列が用意する素材（料理を説明する文字、料理の写真など）が第１サーバ２００の管理者（情報銀行）のスタイルでレイアウトされた画面であっても良い。このようにすることで、マッチングアプリを利用するユーザに対して統一的なユーザエクスペリエンスを提供することができる。

ステップＳ１２において、マッチングアプリは、受信した店舗Ａ１向けの個別メニュー情報を示す個別メニュー画面を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。

ステップＳ１３において、マッチングアプリは、注文された飲食品を示す注文情報を第１サーバ２００に送信する。ここの注文情報を受信した第１サーバ２００は、この注文情報をレストランＡ系列の第２サーバ３００に送信する（ステップＳ１４）。この注文情報を受信した第２サーバ３００は、例えば店舗Ａ１の店舗端末のディスプレイに注文情報を表示する等して、店舗Ａ１のスタッフに調理の開始を通知する（ステップＳ１５）。

ステップＳ１６において、第１サーバ２００は、注文情報をメモリ２０３に記憶することで、該当するユーザの注文履歴を更新する（ステップＳ１６）。

図１５のシーケンス図では、周辺地図情報の取得以外の処理ではマッチングアプリが通信するサーバは第１サーバ２００であるとして説明したが、本開示はこれに限定されない。例えば、マッチングアプリは、店舗情報の取得に関して第１サーバ２００以外の第三のサーバにアクセスしてもよい。

図１６は、初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。

ステップＳ２１～Ｓ２５の処理は図１５のステップＳ１～Ｓ５の処理と同じである。ステップＳ２６において、マッチングアプリは、マップ画面Ｇ４に表示された店舗のうちレストランＢ系列の店舗Ｂ１を選択するユーザの指示を受け付ける。

ステップＳ２７において、マッチングアプリは、店舗Ｂ１の個別メニュー情報の取得要請を第１サーバ２００に送信する。この取得要請には店舗Ｂ１の店舗ＩＤ、接続情報、及び情報端末１００のユーザＩＤ等が含まれる。

この取得要請を受信した第１サーバ２００は、店舗Ｂ１が属するレストランＢ系列の標準メニュー情報の取得要請をレストランＢ系列の第２サーバ３００に送信する（ステップＳ２８）。

この取得要請を受信したレストランＢ系列の第２サーバ３００は、店舗Ｂ１の標準メニュー情報を第１サーバ２００に送信する。これにより、第１サーバ２００はレストランＢ系列の標準メニュー情報を受信する（ステップＳ２９）。ここで送信されるレストランＢ系列の標準メニュー情報は、レストランＢ系列の各店舗で共通のメニュー情報であってもよいし、レストランＢ系列の各店舗で一部分が異なるメニュー情報であってもよい。

レストランＢ系列の標準メニュー情報を受信した第１サーバ２００は、該当するユーザの注文履歴に基づいて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する（ステップＳ３０）。具体的には、第１サーバ２００は、レストランＢ系列での該当するユーザの注文履歴が後述する参照条件Ｃ１を満たさない場合、レストランＢ系列の店舗Ｂ１が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗Ｂ１における個別メニュー情報を生成する。一方、第１サーバ２００は、レストランＢ系列での該当するユーザの注文履歴が参照条件Ｃ１を満たしている場合、レストランＢ系列での該当するユーザの注文履歴を用いて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。ステップＳ３０の処理の詳細は図１７に示すフローチャートを用いて後述する。

生成された店舗Ｂ１の個別メニュー情報は第１サーバ２００により情報端末１００（マッチングアプリ）へ送信され、マッチングアプリは、この個別メニュー情報を受信する（ステップＳ３１）。

ステップＳ３１までの処理において、情報端末１００に表示される各種画面は第１サーバ２００の管理者（情報銀行）のスタイルでデザインされたものが使用される。一方、ステップＳ３２からの処理においては、情報端末１００に表示される各種画面はレストランＢ系列のスタイルでデザインされたものが使用される。

尚、ステップＳ３２からの処理において、情報端末１００に表示される各種画面は、レストランＢ系列が用意する素材（料理を説明する文字、料理の写真など）が第１サーバ２００の管理者（情報銀行）のスタイルでレイアウトされた画面であっても良い。このようにすることで、マッチングアプリを利用するユーザに対して統一的なユーザエクスペリエンスを提供することができる。

ステップＳ３２において、マッチングアプリは、受信した店舗Ｂ１の個別メニュー情報を示す個別メニュー画面Ｇ５，Ｇ６を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。

ステップＳ３３～ステップＳ３６の処理は、店舗Ａ１ではなく店舗Ｂ１に対して飲食品の注文が行われること以外は、図１５に示すステップＳ１２～Ｓ１６と同じである。

図１７は、図１６のシーケンス図のステップＳ３０における処理に着目したときの情報提供システムの処理の一例を示す図である。

ステップＳ１０１において、第１サーバ２００は、指定されたレストラン系列の標準メニュー情報を第２サーバ３００から取得する。この処理は、図１６のステップＳ２９に相当する。指定されたレストラン系列とは、マップ画面Ｇ４においてユーザが選択した店舗が属しているレストラン系列である。

図１３は、標準メニュー情報Ｄ１のデータ構成の一例を示す図である。標準メニュー情報Ｄ１には、１以上の飲食品のそれぞれについて、料理名、価格、及び期間限定が対応付けて記憶されている。飲食品名は「ブレンドコーヒー」、「アメリカンコーヒー」等、提供される飲食品の名称を示す。価格は各飲食品の価格を示す。期間限定は、期間限定で提供される飲食品であるか否かを示す。ＹＥＳは期間限定の飲食品であることを示し、ＮＯは年間を通じて提供される飲食品であることを示す。例えば、「スペシャルモンブランホワイトカフェラテ」は特定の期間に提供される飲食品であるため、期間限定が「ＹＥＳ」になっている。

図１７に参照を戻す。ステップＳ１０２において、第１サーバ２００は、メモリ２０３に記憶された該当するユーザの注文履歴の中から、指定されたレストラン系列における該当するユーザの注文履歴を検索する。

ステップＳ１０３において、第１サーバ２００は、検索にヒットした注文履歴が参照条件Ｃ１を満たすか否かを判定する。参照条件Ｃ１は、第１サーバ２００の運営会社、マッチングアプリの開発会社、マッチングアプリの配布会社、サービス提供会社（この場合、レストランＢ系列）、又はユーザが設定した期間において、下記の（ａ）～（ｄ）のうち少なくとも１つの条件を含むようにしてもよい。設定された期間とは、例えば、現在から過去３年、２年、１年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。

（ａ）指定されたレストラン系列における飲食品の注文回数が閾値Ｔａ以上

（ｂ）指定されたレストラン系列で注文した日の回数（来店回数）が閾値Ｔｂ以上

（ｃ）指定されたレストラン系列で注文した飲食品の個数（注文皿数）が閾値Ｔｃ以上

（ｄ）指定されたレストラン系列で注文した飲食品の合計金額（注文額）が閾値Ｔｄ以上
閾値Ｔａ～閾値Ｔｄは、例えば、それぞれ、ユーザが指定されたレストラン系列に行きつけているとみなせる予め定められた値が採用される。或いは、閾値Ｔａ～閾値Ｔｄはユーザが指定されたレストラン系列に実質的に初めて来店したとみなせる予め定められた値が採用されてもよい。

設定された期間内の条件を設けたのは、指定されたレストラン系列にユーザが久しく来店しておらず、その間にユーザの嗜好が変化する可能性や、店舗がメニューを更新する可能性を考慮したためである。例えば、ユーザの嗜好は健康意識が高くなると変化する可能性がある。

ヒットした注文履歴が参照条件Ｃ１を満たす場合（ステップＳ１０３でＹＥＳ）、第１サーバ２００は、ヒットした注文履歴を優先指標として用いて、指定された店舗での該当するユーザの個別メニュー情報を生成する（ステップＳ１０４）。指定された店舗とは、マップ画面Ｇ４においてユーザが選択した店舗である。例えば、指定された店舗が店舗Ｂ１であり、ユーザが店舗Ｂ１に行きつけている、或いは、ユーザがレストランＢ系列のいずれかの店舗に行きつけているような場合、ステップＳ１０３でＹＥＳと判定される。この場合、第１サーバ２００は、例えば、ヒットした注文履歴の注文回数から、より多く注文された飲食品の優先順位を高くするように決定してもよい。また、注文時のユーザの周辺状況も加味して、注文される可能性が高い順に、飲食品を順位付けするようにしてもよい。例えば、今回の注文時の周辺状況（曜日、季節、気温、湿度、天気、場所、利用店舗、ユーザの生体情報、ユーザの活動量の内の少なくとも１つ）と類似の周辺状況だった時の注文回数から、個別メニューでの飲食品の訴求優先順位を決定するようにしてもよい。これによって、単に注文回数が最も多いという理由だけで、常にどのような状況でも特定の飲食品が推薦されるということを回避できる利点がある。そして、第１サーバ２００は、上位の飲食品ほど注文し易くなるようにレストランＢ系列の標準メニュー情報のメニュー内容を並び替え、個別メニュー情報を生成すればよい。この個別メニュー情報は情報端末１００に送信される。

図１２は、注文履歴を記憶する注文履歴データベースＤ２のデータ構成の一例を示す図である。図１２では、店舗を指定したユーザの注文履歴データベースＤ２が示されている。注文履歴データベースＤ２の各レコードには、例えば該当するユーザの店舗への１回の来店に対する注文履歴が記憶されている。注文履歴データベースＤ２には、注文した日時情報、店舗ＩＤ、店舗名、及び注文した飲食品名が対応付けて記憶されている。この注文履歴データベースＤ２は、後述する図１８に示す「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿１．ｊｓｏｎ」ファイル～「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿Ｎ．ｊｓｏｎ」ファイルに暗号化されたうえで分散管理されている。

注文した日時情報は、ユーザが飲食品を注文した日時を示している。店舗ＩＤはユーザが来店した店舗の識別情報である。店舗名はユーザが来店した店舗の名称である。ここでは、店舗名にはその店舗が属しているレストラン系列の名称が含まれている。注文した飲食品名は、ユーザが注文した飲食品の名称である。例えば、１行目のレコードには、２０２０年１月３日１３時１５分４５秒にレストランＡ系列の門真店でユーザがカプチーノとアイスクリームとを注文した注文履歴が記憶されている。

なお、ここでは上記の周辺状況については図示していないが、周辺状況の情報もこの注文履歴に一緒に記憶されるようにしてもよい。曜日は注文した日の曜日、季節は注文した日の季節、気温は注文した時のユーザ近辺の気温、湿度は注文した時のユーザ近辺の湿度、天気は注文した時のユーザ近辺の天気（晴れ、雨、くもりなど）、場所は注文をした場所を示す情報（住所、ＧＰＳ情報など）、利用店舗は注文をした店舗の特定情報、ユーザの生体情報は注文をした時のユーザの生体情報（血圧、心拍数など）、ユーザの活動量は注文をした日のユーザの活動量情報（歩数、消費カロリーなど）をそれぞれ示している。

指定されたレストラン系列がレストランＢ系列であるとすると、第１サーバ２００は、レストランＢ系列の標準メニュー情報Ｄ１に含まれる各飲食品の注文回数を注文履歴データベースＤ２を参照して集計し、集計結果から当該標準メニュー情報に含まれる各飲食品を順位付けして個別メニュー情報を生成すればよい。

ステップＳ１０５において、情報端末１００は、個別メニュー情報を示す個別メニュー画面を表示する。ステップＳ１０６において、情報端末は、ユーザから注文する飲食品を選択する指示を受け付ける。

ステップＳ１０３において、ヒットした注文履歴が参照条件Ｃ１を満たしていない場合（ステップＳ１０３でＮＯ）、第１サーバ２００は、該当するユーザの注文履歴が参照条件Ｃ２を満たすか否かを判定する（ステップＳ１０７）。

参照条件Ｃ２は、第１サーバ２００の運営会社、マッチングアプリの開発会社、マッチングアプリの配布会社、サービス提供会社（この場合、レストランＢ系列）、又はユーザが設定した期間において、下記（ｅ）、（ｆ）、（ｇ）のうち少なくとも１つの条件を含むようにしてもよい。設定された期間は、３年、２年、１年等の有限期間であってもよいし、無制限の期間であってもよい。

（ｅ）カウント値の合計値が閾値Ｔｅ以上

（ｆ）カウント値が閾値Ｔｆ以上の飲食品の数が所定個数以上

（ｇ）注文金額の合計金額が閾値Ｔｇ以上
カウント値とは、指定されたレストラン系列の標準メニュー情報に含まれる各飲食品について、注文履歴データベースＤ２の「注文した飲食品名」のフィールドにおける出現回数である。カウント値は、検索する文字列が検索対象の文字列に含まれる回数を計測するというようなテキストマッチングにより計測される。例えば、設定された期間（例えば、３年間）において、標準メニュー情報に含まれる「カプチーノ」という文字列が注文履歴データベースＤ２の「注文した飲食品名」のフィールドに２９回出現した場合、「カプチーノ」のカウント値は２９となる。また、標準メニュー情報に、例えば、「担々麺」及び「餃子」が別々にある場合において、注文履歴データベースＤ２の「注文した飲食品名」のフィールドに「担々麺餃子セット」がある場合、「担々麺」及び「餃子」のそれぞれが１カウントアップされるようにしてもよい。

カウント値の合計値は、該当するユーザにおいて、各飲食品のカウント値の合計値である。図１４の例では、「ブレンドコーヒー」から「スペシャルモンブランホワイトカフェラテ」までの例示された範囲だけで、該当するユーザの各飲食品のカウント値の合計値は、２＋２９＋１１＋３＝４５となる。

また、標準メニューに含まれる各飲食品について、名称を示す文字列が一致又は類似する飲食品が注文履歴データベースＤ２の「注文した飲食品名」のフィールドに含まれていれば、出現回数がカウントアップされる。例えば、ブレンドコーヒーとオリジナルブレンドコーヒーとは一方の文字列が他方の文字列に含まれるため、類似すると判定される。カウント値の合計値とは、各飲食品のカウント値を合計した値である。

カウント値が閾値Ｔｆ以上の飲食品とは、注文履歴データベースＤ２の例において、閾値Ｔｆが「１０」とすると、「カプチーノ」及び「カフェモカ」が該当する。この場合、条件（ｆ）の所定個数が「２」であるとすると、該当するユーザの注文履歴は条件（ｆ）を満たすと判定される。

注文履歴が参照条件Ｃ２を満たす場合（ステップＳ１０７でＹＥＳ）、第１サーバ２００は該当するユーザの注文履歴を用いて、指定された店舗における個別メニュー情報を生成する（ステップＳ１０８）。この場合、第１サーバ２００は、カウント値、すなわち注文回数が多い飲食品ほど注文し易くなるように個別メニュー情報を生成すればよい。ステップＳ１０８が終了すると、処理はステップＳ１０５に進められ、ステップＳ１０５以降の処理が実施される。

注文金額の合計金額とは、個々の飲食品の価格に注文回数を掛けて、それを全ての飲食品に対して合計した金額のことである。図１３と図１４の例示された範囲では、注文金額の合計金額は、２＊３５０＋２９＊３５０＋１１＊３５０＋３＊１５０＝１５１５０円と計算される。

図１４は、あるユーザについて、標準メニュー情報に含まれる各飲食品に対して注文回数を纏めた表である。この表において、「全ての注文回数」は指定されたレストラン系列を含む全てのレストラン系列における各飲食品の注文回数を示す。「指定されたレストラン系列での注文回数」はユーザがマップ画面Ｇ４にて選択した店舗が属するレストラン系列における当該ユーザの各飲食品の注文回数を示す。

例えば、指定されたレストラン系列での注文回数は全て０であるため、該当するユーザはこのレストラン系列を過去に来店していないことが分かる。そのため、このレストラン系列の注文履歴からユーザの嗜好に合った個別メニュー情報を生成することはできない。しかしながら、「全ての注文回数」には、「カプチーノ」、及び「カフェモカ」の注文回数が多く、ユーザの嗜好性が見えてくる。

そこで、第１サーバ２００は、「全ての注文回数」を参照することで、個別メニュー情報を生成する。これにより、第１サーバ２００は、ユーザの嗜好に合った個別メニュー情報を生成できる。図１４の例では、「カプチーノ」及び「カフェモカ」における「全ての注文回数」が他の飲食品より多い。そのため、これらの飲食品は指定されたレストラン系列の利用が初めてであっても、その個別メニュー画面の初期画面に表示され、注文がし易いように表示されることになる。また、「アメリカンコーヒー」のような「全ての注文回数」が少ない飲食品は、個別メニュー画面の初期画面から省かれてもよい。或いは、個別メニュー画面の初期画面において、「全ての注文回数」が多い例えば「カプチーノ」及び「カフェモカ」のような飲食品のタイルオブジェクト７０１が表示可能である場合、アメリカンコーヒーが表示されてもよい。この場合、アメリカンコーヒーのような「全ての注文回数」が少ない飲食品のタイルオブジェクト７０１は、「カプチーノ」及び「カフェモカ」よりも小さな面積で表示されてもよい。

なお、注文履歴が参照条件Ｃ２を満たしている場合、図１４に示す「全ての注文回数」から、指定されたレストラン系列の注文回数を除外して、各飲食品のカウント値が算出されてもよい。または、注文履歴が参照条件Ｃ２を満たしている場合、図１４に示す「全ての注文回数」の中で、指定されたレストラン系列での注文回数とそれ以外での注文回数とに異なる重みづけをして（例えば、指定されたレストラン系列での注文回数をそれ以外での注文回数より重要視した重みづけをして）、各飲食品のカウント値が算出されてもよい。或いは、注文履歴が参照条件Ｃ２を満たしている場合、図１４に示す「全ての注文回数」において指定されたレストラン系列以外の特定の１又は複数のレストラン系列の「全ての注文回数」を用いて各飲食品のカウント値が算出されてもよい。特定の１又は複数のレストラン系列とは、ユーザが行きつけのレストラン系列である。

図１７に参照を戻す。ステップＳ１０７において、該当するユーザの注文履歴が参照条件Ｃ２を満たしていない場合（ステップＳ１０７でＮＯ）、第１サーバ２００は、マップ画面Ｇ４にてユーザが選択した店舗が属するレストラン系列の標準メニュー画面を情報端末１００に表示させる（ステップＳ１０９）。

ステップＳ１０７の分岐処理を設けることにより、例えば注文履歴データベースＤ２に記憶されたユーザの注文履歴が少なく、この注文履歴データベースＤ２からユーザの嗜好をくみ取ることができないケースにおいて、個別メニュー情報が生成されることを防止できる。ステップＳ１１０において、情報端末１００は、標準メニュー画面を閲覧したユーザから注文する飲食品を選択する指示を受け付ける。

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

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

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

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

このようにアカウント名として人が見て無意味な文字列情報が設定されることにより、秘匿性がより高められた個人情報の通信が可能となる。

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

レストランＢ系列の第２サーバ３００には、返信するコンテンツ情報を記述した「ＲｅｓＢ．ｈｔｍｌ」ファイルと、そのコンテンツ情報の画面表示のスタイル（例えば、ＵＩデザイン）を記述した「ＲｅｓＢ．ｃｓｓ」ファイルとがある。例えば図１３に示す標準メニュー情報Ｄ１は「ＲｅｓＢ．ｈｔｍｌ」ファイルに含まれてもよい。または、標準メニュー情報Ｄ１は、「ＲｅｓＢ．ｈｔｍｌ」ファイルにて参照される外部ファイルに格納されてもよい。

第１サーバ２００には、このユーザの多種多様で膨大な個人情報が分散暗号化されて蓄積されている。例えば、本開示で利用したユーザの注文履歴データベースＤ２は、「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿１．ｊｓｏｎ」ファイル、「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿２．ｊｓｏｎ」ファイル、．．．、「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿Ｎ．ｊｓｏｎ」ファイルというＮ個のＪＳＯＮフォーマットのファイルとして、第１サーバ２００内の物理的に異なるストレージ装置に保管されていてもよい。Ｎ個のファイルにおいて、ファイル名の先頭部分の「ｕｓｅｒＩＤ」はユーザを特定するための識別情報であり、続く「ＦｏｏｄＨｉｓｔｏｒｙ」は図１２で説明した注文履歴データベースＤ２を特定するための識別情報であり、最後の数字は分断したファイルの識別番号である。

第１サーバ２００は、ユーザの注文履歴のリクエストを適切なパーミッション（例えば、アクセス許可情報）と共に受信できれば、これらＮ個のファイルから正しくデータを復元し、所定の記述フォーマット（．ｊｓｏｎ）に変換して暗号化し、情報端末１００へ返信できる。

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

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

ステップＳ２０２において、マッチングアプリは、ホーム画面Ｇ３を閲覧するユーザからマップ画面Ｇ４を表示させる指示を受け付ける。

ステップＳ２０３において、マッチングアプリは、パブリック情報サーバ５００に対して現在の地点の周辺地図情報の取得要請を行い、周辺地図情報を示すマップ画面Ｇ４を表示する。

ステップＳ２０４において、マッチングアプリは、第１サーバ２００に対して周辺地図情報が示す地域内の店舗情報の取得要請を行い、店舗情報をマップ画面Ｇ４に表示する。これにより、店舗を示すアイコン３２１０等が表示される。

ステップＳ２０５において、マッチングアプリは、ユーザからレストランＢ系列の店舗Ｂ１を選択する指示を受け付ける。

ステップＳ２０６において、マッチングアプリは、第１サーバ２００に対してレストランＢ系列の個別メニュー情報の取得要請を行う。

ステップＳ２０７において、第１サーバ２００は、レストランＢ系列の第２サーバ３００に対して、レストランＢ系列の標準メニュー情報（ＲｅｓＢ．ｈｔｍｌ、ＲｅｓＢ．ｃｓｓ）の取得要請を行う。

ステップＳ２０８において、第１サーバ２００は、該当するユーザの注文履歴からレストランＢ系列の個別メニュー情報を生成する。生成された個別メニュー情報は、「Ｃｕｓｔｏｍ＿ＲｅｓＢ．ｈｔｍｌ」ファイルとして、新規に「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリの下に記録される。

ステップＳ２０９において、第１サーバ２００は、マッチングアプリに対してレストランＢ系列の個別メニュー情報を送信する。

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

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

（実施の形態２）
実施の形態１は、個別メニュー情報の生成主体が第１サーバ２００であった。実施の形態２は、個別メニュー情報の生成主体が第２サーバ３００であることを特徴とする。実施の形態２の情報提供システムは第２サーバ３００を含む情報管理システムを含む。

なお、実施の形態２において、実施の形態１と同一の構成要素については同一の符号を付し、説明を省く。

まず、図２を参照して、実施の形態２の構成について説明する。実施の形態２では、個別メニュー情報が第２サーバ３００で生成されるため、以下、第２サーバ３００の構成を中心に説明する。

第２サーバ３００の通信部３０１は、情報端末１００から情報端末１００のユーザを特定する識別情報及び第１レストランと系列が異なる第２レストランを示す店舗ＩＤを受信する。この店舗ＩＤは、情報端末１００を操作するユーザが選択した店舗の識別情報である。通信部３０１は、演算部３０２が生成した個別メニュー情報を第２レストランを選択したユーザの情報端末１００に送信する。

第２サーバ３００の演算部３０２は、受信したユーザＩＤに対応する嗜好情報を第１サーバ２００から取得する。ここで、嗜好情報は、第２サーバ３００に対してユーザが嗜好情報のアクセスを許可している場合に第１サーバ２００から送信される。これにより、ユーザの個人情報がユーザの許可なく第１サーバ２００の外部に漏洩することを防止できる。一方、第２サーバ３００又は第２サーバ３００を利用するレストラン系列に対してユーザが嗜好情報のアクセスを不許可にしている場合、嗜好情報は第１サーバ２００から送信されない。この場合、第２サーバ３００は、第２レストランの標準メニューを情報端末１００に送信してもよい。

演算部３０２は、メモリ３０３から第２レストランの標準メニュー情報を取得し、嗜好情報及び標準メニュー情報に基づき、嗜好情報に対応した順序にてメニュー内容を配列する。

演算部３０２は、配列されたメニュー内容のメニュー情報（個別メニュー情報）を通信部３０１を用いて情報端末１００に送信する。これにより、情報端末１００のディスプレイ１０５に個別メニューが表示される。

演算部３０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴がない場合、嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランが属する系列を初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。

一方、演算部３０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴がある場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランを過去に利用したことがある場合、第２レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。

なお、演算部３０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量に満たない場合、当該ユーザのユーザＩＤに対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第２レストランでの注文履歴が所定量に満たない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所定量は、ユーザが第２レストランに行きつけているとみなされる予め定められた値、又は第２レストランに初めて来店したとみなせる予め定められた値を有する。

一方、演算部３０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量以上である場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第２レストランでの注文履歴が所定量以上の場合、ユーザは、第２レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。

さらに、演算部３０２は、第２レストランを選択したユーザによる第２レストランでの直近の注文履歴が所定期間より前である場合、当該ユーザのユーザＩＤに対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第２レストランに久しく来店していない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所定期間は、例えば、現在から過去３年、２年、１年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。

さらに、演算部３０２は、該当するユーザの設定期間内での第２レストランでの注文回数が一定回数以下である場合、該当するユーザのユーザＩＤに対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、設定期間内の第２レストランにおける注文回数が一定回数以下の場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。設定期間は、例えば、現在から過去３年、２年、１年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。一定回数は、ユーザが第２レストランに行きつけているとみなされる予め定められた値、又は第２レストランに初めて来店したとみなせる予め定められた値を有する。

続いて、第１サーバ２００について説明する。第１サーバ２００のメモリ２０３は、各ユーザに対するアクセス情報を記憶する。アクセス情報は、ユーザが第２サーバ３００に対して自身の嗜好情報のアクセスを許可するか否かを示す情報である。アクセス情報は、アクセス許可、アクセス不許可、及び未設定のいずれかを含む。

ある１のユーザの第２サーバ又は第２サーバ３００を利用する事業者へのアクセス情報がアクセス許可に設定されている場合、通信部２０１が第２サーバ３００又は第２サーバ３００を利用する事業者から当該１のユーザについての嗜好情報の取得要請を受信すると、演算部２０２は、当該１のユーザの嗜好情報を第２サーバ３００又は第２サーバ３００を利用する事業者に送信する。ある１のユーザの第２サーバ３００又は第２サーバ３００を利用する事業者へのアクセス情報がアクセス不許可に設定されている場合、通信部２０１が第２サーバ３００又は第２サーバ３００を利用する事業者から当該１のユーザについての嗜好情報の取得要請を受信すると、演算部２０２は、当該１のユーザの嗜好情報を第２サーバ３００に送信しない。ある１のユーザのアクセス情報が未設定の場合、通信部２０１が第２サーバ３００又は第２サーバを利用する事業者からの当該１のユーザについての嗜好情報の取得要請を受信すると、演算部２０２は、通信部２０１を用いて、嗜好情報に対するアクセスを許可するか否かの問い合わせメッセージを情報端末１００に送信する。

図２０は、実施の形態２において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。図２０において図１６と同一の処理については同一の符号を付し、説明を省略する。なお、図２０では、ユーザは自身の嗜好情報（注文履歴）に対する第２サーバ３００又は第２サーバ３００を利用するレストランＢ系列のアクセス情報を未設定にしているものとする。

ステップＳ２１～Ｓ２６は、図１６と同じである。

ステップＳ２６に続くステップＳ３０１において、情報端末１００（マッチングアプリ）は、店舗Ｂ１の個別メニュー情報の取得要請を第２サーバ３００に送信する。この取得要請には店舗Ｂ１の店舗ＩＤ及び情報端末１００のユーザＩＤ等が含まれる。

ステップＳ３０２において、第２サーバ３００はメモリ３０３からレストランＢ系列の標準メニュー情報を取得する。ここで取得されるレストランＢ系列の標準メニュー情報は、レストランＢ系列の各店舗で共通のメニュー情報であってもよいし、レストランＢ系列の各店舗で一部分が異なるメニュー情報であってもよい。

ステップＳ３０３において、第２サーバ３００は、該当するユーザの注文履歴（嗜好情報の一例）の取得要請を第１サーバ２００に送信する。

ステップＳ３０４において、第１サーバ２００は、メモリ２０３から該当するユーザのアクセス情報を読み出し、該当するユーザに関してレストランＢ系列に対するアクセス情報が未設定であることを確認する。

ステップＳ３０５において、第１サーバ２００は、レストランＢ系列に対して注文履歴のアクセスを許可するか否かの問い合わせメッセージを情報端末１００に送信する。問い合わせメッセージは情報端末１００のディスプレイ１０５に表示される。

ステップＳ３０６において、情報端末１００は、問い合わせメッセージを確認したユーザからアクセス情報をアクセス許可に選択する操作を受け付ける。

ステップＳ３０７において、情報端末１００は、アクセス情報がアクセス許可に選択されたことを示す通知情報を第１サーバ２００に送信する。

ステップＳ３０８において、アクセス許可が選択されたことを示す通知情報を受信した第１サーバ２００は、メモリ２０３に記憶された該当するユーザのアクセス情報をアクセス許可に設定する。これにより、第１サーバ２００は、該当するユーザの注文履歴をメモリ２０３から読み出し、第２サーバ３００に送信する。

ステップＳ３０９において、第２サーバ３００は、該当するユーザの注文履歴を受信する。

ステップ３１０において、第２サーバ３００は、該当するユーザの注文履歴に基づいて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。

具体的には、第２サーバ３００は、レストランＢ系列での該当するユーザの注文履歴が上述の参照条件Ｃ１を満たさない場合（例えば、該当するユーザがレストランＢ系列に初めて来店したとみなせる場合）、レストランＢ系列の店舗Ｂ１が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗Ｂ１における個別メニュー情報を生成する。

一方、第２サーバ３００は、レストランＢ系列での該当するユーザの注文履歴が参照条件Ｃ１を満たしている場合（例えば、該当するユーザがレストランＢ系列に行きつけているとみなせる場合）、レストランＢ系列での該当するユーザの注文履歴を用いて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。この処理の詳細は、図１７に示すフローチャートを用いて上述した。第２サーバ３００は、生成された個別メニュー情報を情報端末１００に送信する。

ステップＳ３１１において、情報端末１００は、個別メニュー情報を受信する。

ステップＳ３１１までの処理において、情報端末１００に表示される各種画面は第１サーバ２００の管理者（情報銀行）のスタイルでデザインされたものが使用される。一方、ステップＳ３１２からの処理においては、情報端末１００に表示される各種画面はレストランＢ系列のスタイルでデザインされたものが使用される。または、レストランＢ系列の料理を説明する文章及び写真を第１サーバ２００の管理者のスタイルでレイアウトしたものが使用されても良い。

ステップＳ３１２において、情報端末１００は、受信した店舗Ｂ１の個別メニュー情報を示す個別メニュー画面Ｇ５，Ｇ６を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。

ステップＳ３１３において、情報端末１００は、注文された飲食品を示す注文情報を第２サーバ３００に送信する。この注文情報を受信した第２サーバ３００は、例えば店舗Ｂ１の店舗端末のディスプレイに注文情報を表示する等して、店舗Ｂ１のスタッフに調理の開始を通知する（ステップＳ３６）。

ステップＳ３１４において、情報端末１００は、注文情報をさらに第１サーバ２００に送信する。

注文情報を受信した第１サーバ２００は、注文情報をメモリ２０３に記憶することで、該当するユーザの注文履歴を更新する（ステップＳ３５）。

図２１は、実施の形態２において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の他の一例を示すシーケンス図である。

図２１において図２０と同一の処理については同一の符号を付し、説明を省略する。なお、図２１では、ユーザは自身の嗜好情報（注文履歴）に対するレストランＢ系列のアクセス情報をアクセス許可に設定しているものとする。

ステップＳ２１～Ｓ２６、ステップＳ３０１～Ｓ３０３までの処理は、図２０と同じである。

ステップＳ３０３に続くステップＳ４０１において、該当するユーザの注文履歴の取得要請を受信した第１サーバ２００は、メモリ２０３から該当するユーザのアクセス情報を読み出し、該当するユーザに関してレストランＢ系列（又はレストランＢ系列が利用する第２サーバ３００）に対するアクセス情報がアクセス許可に設定されていることを確認する。これにより、第１サーバ２００は、該当するユーザの注文履歴をメモリ２０３から読み出し、第２サーバ３００に送信する。

ステップＳ３０９以降の処理は図２０と同じである。

図２２は、実施の形態２において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理のさらに他の一例を示すシーケンス図である。

図２２において図２０と同一の処理については同一の符号を付し、説明を省略する。なお、図２２では、ユーザは自身の嗜好情報（注文履歴）に対するレストランＢ系列のアクセス情報を未設定にしているものとする。

ステップ２１～Ｓ２６及びステップＳ３０１～Ｓ３０５の処理は図２０と同じである。ステップＳ３０５に続くステップＳ５０１において、情報端末１００は、問い合わせメッセージを確認したユーザからアクセス情報をアクセス不許可に選択する操作を受け付ける。

ステップＳ５０２において、情報端末１００は、アクセス情報がアクセス不許可に選択されたことを示す通知情報を第１サーバ２００に送信する。

ステップＳ５０３において、アクセス不許可が選択されたことを示す通知情報を受信した第１サーバ２００は、メモリ２０３に記憶された該当するユーザのレストランＢ系列又はレストランＢ系列が利用する第２サーバ３００へのアクセス情報をアクセス不許可に設定する。これにより、第１サーバ２００は、第２サーバ３００に対して要求エラーを送信する。要求エラーは第２サーバ３００に対して、注文履歴の取得要求に応答することができないことを通知するための情報である。

ステップＳ５０４において、第２サーバ３００は、要求エラーを受信する。要求エラーを受信した第２サーバ３００は、メモリ３０３からレストランＢ系列の標準メニュー情報を読み出し、読み出した標準メニュー情報と要求エラーとを情報端末１００に送信する。

ステップＳ５０５において、情報端末１００は、標準メニュー情報と要求エラー（レストランＢ系列がユーザの注文履歴へのアクセス不許可と設定されたことを示す情報）とを受信する。

ステップＳ５０６において、情報端末１００は、個別メニューが生成できなかったことを示す情報と、標準メニュー画面Ｇ７とをディスプレイ１０５に表示し、ユーザから注文する飲食品を選択する指示を受け付ける。

ステップＳ３１３以降の処理は図２０と同じである。

このように、実施の形態２によれば、第２サーバ３００が個別メニュー情報を生成する場合であっても、ユーザの許諾がない事業者に対して嗜好情報が渡らないようにしながらも、ユーザが初めて利用する第２レストランにおいて、ユーザの嗜好情報が考慮されたメニュー情報を表示できる。

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

（１）第１サーバ２００は、ユーザがマップ画面Ｇ４から選択したレストランＢ系列の店舗Ｂ１に対する注文情報を取得した場合、情報端末１００の現在の地点をモニタし、情報端末１００と店舗Ｂ１との距離が一定距離以下になった場合、注文情報をレストランＢ系列の第２サーバ３００に送信してもよい。これにより、店舗Ｂ１はユーザが来店するタイミングに飲食品を提供することが可能となる。

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

（３）図１３の標準メニュー情報Ｄ１に示される期間限定の飲食品については、カウント値は算出されなくてもよい。すなわち、標準メニュー情報において、「期間限定」がＮＯの飲食品についてのみカウント値を算出し、その結果に基づいて個別メニュー情報が生成されてもよい。

（４）本開示では、過去に注文をしたことがない、または注文の回数が少ない第２レストラン系列の店での個別メニュー情報の作成のために、過去に注文を行ったことがある第１レストラン系列の店における注文履歴などの個人情報と、第２レストラン系列の店で提供している飲食品の名称と第１レストラン系列の店で提供している飲食品の名称との比較結果を利用する場合を例に挙げて説明した。しかしながら、第１サーバ２００が個別メニュー情報の作成のために個人情報と組み合わせて利用する情報は、上記の例に限られない。

例えば、第１サーバ２００は、第１レストラン系列の店と第２レストラン系列の店の両方で注文したことがある複数のユーザの購入履歴などを集めたビッグデータから推測される統計情報を用いて、個別メニュー情報を生成してもよい。この場合、第１サーバ２００は、例えば、サービスを利用中のユーザの個人情報から、当該ユーザが第１レストラン系列の店で飲食品Ａの注文頻度が高いと判定された場合に、ビッグデータの分析で得られた「第１レストラン系列の店で飲食品Ａを注文するユーザは、第２レストラン系列の店で飲食品Ｘを注文する頻度が高い」という統計情報に基づいて、飲食品Ｘの表示順序を上位にするなど、飲食品Ｘが優先的に表示される個別メニュー情報を生成する。

なお、ここではビッグデータを分析して得られた情報を統計情報と呼んでいるが、名称はこれに限定されない。例えば、第１レストラン系列の店で提供される飲食品と、第２レストラン系列の店で提供される飲食品との相関関係を示す相関関係情報と呼んでもよいし、単にビッグデータを用いて生成された情報などと呼んでもよい。また、ビッグデータとして用いられる他のユーザから取得された情報は、例えば、ユーザを特定できない状態の匿名情報に変換してから分析などに用いられてもよい。また、第１サーバ２００は、上記の統計情報の生成する際に、個別メニューの生成に用いられるサービスを利用中のユーザに対応付けられた個人情報を匿名化して用いてもよい。

（５）本開示では、第１サーバ２００が、ユーザの購買履歴などから推定されたユーザの嗜好情報に応じた順序で飲食品を配列した個別メニュー情報を生成する例を挙げて説明した。以下では、第１サーバ２００が、端末機器において個別メニューとして表示される飲食品の順序を、個別メニュー情報を介して制御または指定する方法について、いくつか例を挙げて説明する。すなわち、第１サーバ２００が、第１レストランにて注文した注文履歴を含むユーザの嗜好情報及び第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を端末機器の表示画面において配列するための個別メニュー情報を生成し、前記個別メニュー情報を前記端末機器に送信し、前記端末機器の前記表示画面において前記順序にて配列されたメニュー内容のメニュー情報を表示させる、情報提供方法について、いくつか例を挙げて説明する。ただし、上記実施の形態において適用可能な、第１サーバ２００が個別メニューとして表示される飲食品の順序を制御または指定する方法は、以下の例に限定されるものではない。すなわち、第１サーバ２００が、注文履歴などの個人情報から推定された嗜好情報に応じて個別メニューとして表示される飲食品の順序を変更することができる方法であれば、どのような方法を用いてもよい。

第１の例では、第１サーバ２００は、個別メニュー情報を生成する際に、メニュー内容である各飲食品を表示する順序で個別メニュー情報に格納する。

第２の例では、第１サーバ２００は、個別メニュー情報を生成する際に、個別メニューとして表示する飲食品ごとに、当該飲食品の画面上での表示位置を直接指定する。

第３の例では、第１サーバ２００は、個別メニューとして表示する飲食品ごとに、当該飲食品の表示順序を対応付けて個別メニュー情報に格納しておく。この場合、個別メニュー情報を受信した端末機器側のアプリ又はブラウザは、例えば、個別メニューを表示する領域の大きさ又はユーザによって指定されたフォントの表示サイズなどに応じて表示する飲食品の数と、各表示順序に対応する飲食品の表示サイズと、各表示順序に対応する飲食品の表示位置などを所定の表示画面生成ルールに基づいて決定し、個別メニュー情報に含まれる表示順序に従って各飲食品を示すオブジェクトを配置して個別メニューの表示画面を生成すればよい。

第４の例では、第１サーバ２００は、個別メニュー情報に飲食品の表示順序を直接格納するのではなく、ユーザの個人情報に基づいて生成され、且つ飲食品の表示順序を決定するために利用可能な一または複数のパラメータを飲食品ごとに個別メニュー情報に格納してもよい。この場合、個別メニュー情報を受信した端末機器側のアプリ又はブラウザは、上記の一または複数のパラメータから、所定の表示順序導出ルール又はユーザが複数の候補の中から指定した表示順序導出ルールに従って、飲食品の表示順序を導出する。本構成によると、生成された個別メニュー情報に従って端末機器側のアプリ又はブラウザが単純に個別メニューの表示画面を表示するのではなく、ユーザが利用する端末機器の種類又はユーザによる設定に従って、個別メニューの表示方法又は表示する飲食品の表示順序を調整することが可能になるため、より柔軟なサービスの提供を促進することができる。

（６）本開示では、マッチングアプリの画面表示でスタイルを変更する例として、例えば拡張子が「．ｃｓｓ」などであるＵＩデザインを規定したファイルを複数準備して、表示に用いるＵＩデザインを規定したファイルを切り替えることでスタイルを変更する態様を例に挙げて説明した。しかしながら、スタイルの変更は表示に用いるＵＩデザインを規定したファイルを切り替える態様以外の方法で実現されてもよい。例えば、スタイルの変更は、マッチングアプリ内の表示においてレストランＡ系列、レストランＢ系列がそれぞれ独自にメニュー画面に用いる文字のフォントやサイズ、背景および文字の色、ロゴ、メニュー画像、ボタンのデザイン、メニューの配置、メニューの表示サイズ、並びに料理の選択や注文の確定などを行うためのＵＩなどのいずれか一つまたは複数の組み合わせを独自に設定することで実現されてもよい。上述した、メニュー画面に用いる文字のフォントやサイズ、背景および文字の色、ロゴ、メニュー画像、ボタンのデザイン、メニューの配置、メニューの表示サイズ、並びに料理の選択や注文の確定などを行うためのＵＩなどは、例えばレストランＡ系列、レストランＢ系列などのマッチングアプリを利用してサービスを提供する各事業者が提供しているＨＴＭＬファイルで設定することができる。このとき、マッチングアプリの個別メニュー表示画面において、ＣＳＳファイルはマッチングアプリが指定したものを用いるが、個別メニューの表示に提供される画面領域に表示するＨＴＭＬファイルはサービスを提供する事業者が提供するファイルを利用する。これにより、マッチングアプリのウィンドウやフレームのデザインはマッチングアプリの他の表示画面と共通となり、個別メニューが表示される画面領域のデザインはサービスを提供する事業者毎に設定することが可能となる。その結果、ユーザは注文を行おうとするサービスの提供事業者がレストランＡ系列であるのかレストランＢ系列であるのかを容易に判別できるようになる。さらに、個別メニュー画面のスタイルはサービス提供事業者が設定できるにもかかわらず、管理者（情報銀行）が管理する異なるレストラン系列での注文履歴を含む嗜好情報に基づいて、表示するメニューの位置や順番を変更することが可能となり、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。

（７）本開示では、マッチングアプリが系列の異なるレストランでの注文履歴を含む嗜好情報を用いると説明したが、系列が異なるレストランは複数のチェーンストアを有するレストランである必要はない。例えば、マッチングアプリが利用する注文履歴は、複数のチェーンストアを有さない１店舗だけのレストランの注文履歴であってもよい。すなわち、本開示によると、異なるメニューを提供する複数のレストラン間で、他のレストランにおける注文履歴を含む嗜好情報に基づいて、表示するメニューの位置や順番を変更することが可能となり、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。

以上の（１）～（７）の変形例は、第２サーバ３００が個別メニュー情報を生成する態様を採用した場合についても適用可能である。

以上、１つまたは複数の態様に係る情報提供システム及び情報提供方法について、実施の形態に基づいて説明したが、本開示は、この実施の形態に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本開示の範囲に含まれても良い。

本開示にかかる情報提供方法の一例によれは、ユーザが飲食品を効率よく注文することが可能であるため、飲食品をユーザに提供する外食産業に提供される技術として有用である。

Claims (11)

1. 第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する第１サーバと通信する第２サーバであって前記第１レストランと系列が異なる第２レストランと関連する第２サーバを含む情報管理システムにおける情報提供方法であって、
   端末機器から前記識別情報及び前記第２レストランを示す店舗ＩＤを取得し、前記店舗ＩＤは前記端末機器において選択され、
   前記第１サーバから前記識別情報に対応する前記嗜好情報を取得し、前記識別情報に関する前記嗜好情報は、前記第１サーバにおいて前記第１サーバに記憶された第２サーバによる前記嗜好情報へのアクセスを前記ユーザが許可するか否かを示すアクセス情報に基づいて前記識別情報が特定する前記ユーザによって許諾されていると判断した場合に前記第１サーバから取得され、
   前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記メニュー情報に含まれるメニュー内容と同一または類似する前記第１レストランのメニュー内容に対応する前記ユーザの注文履歴を用いて、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列し、前記メニュー情報は、前記第２サーバに保持され、
   前記順序にて配列されたメニュー内容のメニュー情報を前記端末機器に送信し、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報を表示させる、
   情報提供方法。
2. 前記第２レストランは、前記第１レストランとは異なる系列のコーヒーショップである、
   請求項１記載の情報提供方法。
3. 前記第２レストランは、前記第１レストランとは異なる系列のハンバーガーショップである、
   請求項１記載の情報提供方法。
4. 前記情報管理システムは、前記第２レストランにおける注文履歴を、前記ユーザを特定する識別情報と対応して管理しており、
   前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴がない場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列する、
   請求項１記載の情報提供方法。
5. 前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴がある場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列する、
   請求項４記載の情報提供方法。
6. 前記情報管理システムは、前記第２レストランにおける注文履歴を、前記ユーザを特定する識別情報と対応して管理しており、
   前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴が所定量に満たない場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列する、
   請求項１記載の情報提供方法。
7. 前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴が前記所定量以上である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列する、
   請求項６記載の情報提供方法。
8. 前記情報管理システムは、前記第２レストランにおける注文履歴を、前記ユーザを特定する識別情報と対応して管理しており、
   前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの直近の注文履歴が所定期間より前である場合、前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列する、
   請求項１記載の情報提供方法。
9. 前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの直近の注文履歴が前記所定期間内である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を配列する、
   請求項８記載の情報提供方法。
10. 前記情報管理システムは、前記第２レストランでの注文履歴を示す注文履歴情報を、前記ユーザを特定する識別情報と対応して管理しており、前記注文履歴は注文回数を含み、
    設定期間内の前記第２レストランでの注文回数が一定回数以下であると判断した場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列する、
    請求項１記載の情報提供方法。
11. 前記第１サーバにおいて、前記第１レストランにて注文した前記注文履歴が前記第１レストランを示す店舗ＩＤと対応付けて記憶されている、
    請求項１記載の情報提供方法。

Images