JP7349691B2 - 情報提供方法 - Google Patents

情報提供方法 Download PDF

Info

Publication number
JP7349691B2
JP7349691B2 JP2023082509A JP2023082509A JP7349691B2 JP 7349691 B2 JP7349691 B2 JP 7349691B2 JP 2023082509 A JP2023082509 A JP 2023082509A JP 2023082509 A JP2023082509 A JP 2023082509A JP 7349691 B2 JP7349691 B2 JP 7349691B2
Authority
JP
Japan
Prior art keywords
information
restaurant
menu
user
order
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2023082509A
Other languages
English (en)
Other versions
JP2023096132A (ja
Inventor
洋 矢羽田
孝啓 西
正真 遠間
敏康 杉尾
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Publication of JP2023096132A publication Critical patent/JP2023096132A/ja
Application granted granted Critical
Publication of JP7349691B2 publication Critical patent/JP7349691B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0641—Shopping interfaces

Landscapes

  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Health & Medical Sciences (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Description

本開示は、端末機器の制御方法、及び、情報管理システムにおける情報提供方法に関する。
特許文献１には、飲食店においてメニューの中から顧客が自身の好みに合う料理を探し出す手間を軽減するために、顧客の注文履歴を取得し、取得した注文履歴に関する情報に基づいて、飲食品に係る注文案を通知するオーダーシステムが開示されている。
特開２００９－６４３４８号公報
上記の従来技術では、更なる改善が必要とされていた。
本開示の一態様における制御方法は、第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する第１サーバとネットワークを介して通信する端末機器の制御方法であって、前記端末機器のユーザを識別するユーザＩＤ及び前記第１レストランと系列が異なる第２レストランを示す店舗ＩＤを、前記端末機器の入力デバイスを介して受け付け、前記店舗ＩＤが示す前記第２レストランに関連する第２サーバから、前記第２レストランのメニュー情報を取得し、前記メニュー情報は、第１メニュー内容と、前記第２レストランによって指定された第２メニュー内容とを含み、前記ユーザＩＤを、前記第1サーバに送信し、前記第1サーバが、前記ユーザＩＤに関連する前記識別情報に基づいて、前記端末機器の前記ユーザによる前記嗜好情報へのアクセスが許諾されていると判断した場合に、前記識別情報に対応する嗜好情報を前記第１サーバから取得し、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれる前記第１メニュー内容を配列し、前記端末機器の表示画面内の第１表示領域に、前記順序にて配列された前記第１メニュー内容を表示し、かつ、前記表示画面内の第２表示領域に、前記第２レストランによって指定された前記第２メニュー内容を表示する。
上記態様により、更なる改善を実現できる。
本開示の情報提供システムの全体像の一例を示す図である。 本実施の形態に係る情報提供システムの具体的な構成の一例を示す図である。 飲食品を注文するユーザがマッチングアプリを起動した直後に情報端末に表示される認証画面の一例を示す図である。 他の一例に係る認証画面を示す図である。 マッチングアプリによるユーザ認証が終わった直後に表示されるホーム画面の一例を示す図である。 情報端末に表示されるマップ画面の一例を示す図である。 情報端末に表示される個別メニュー情報の表示画面の一例である個別メニュー画面を示す図である。 情報端末に表示される個別メニュー情報の表示画面の別の一例である個別メニュー画面を示す図である。 情報端末に表示される標準メニュー情報の表示画面の一例である標準メニュー画面を示す図である。 図７に示す個別メニュー画面において、ユーザが飲食品を注文する様子を示した図である。 図１０で選択した飲食品の注文を確定する際に表示される注文確定画面の一例を示す図である。 注文履歴を記憶する注文履歴データベースのデータ構成の一例を示す図である。 標準メニュー情報のデータ構成の一例を示す図である。 あるユーザについて、標準メニュー情報に含まれる各飲食品に対して注文回数を纏めた表である。 行きつけの系列の店舗に来店したユーザにより飲食品が注文される際の情報提示システムの処理の一例を示すシーケンス図である。 初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。 図１６のシーケンス図のステップＳ３０における処理に着目したときの処理の一例を示す図である。 本実施の形態における情報提供システムの具体的な実装形態の一例を示す図である。 マッチングアプリが起動してから個別メニュー画像を表示するまでのファイルに対するマッチングアプリの処理の一例を示すフローチャートである。 実施の形態２において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。 実施の形態３において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。 実施の形態３において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の他の一例を示すシーケンス図である。 実施の形態３において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理のさらに他の一例を示すシーケンス図である。 実施の形態４における情報提供システムの処理の一例を示すシーケンス図である。 実施の形態５における情報提供システムの処理の一例を示すシーケンス図である。 実施の形態５における情報提供システムの処理の変形例を示す図である。 実施の形態６における第１例の個別メニュー画面を示す図である。 実施の形態６における第２例の個別メニュー画面を示す図である。 実施の形態６における第３例の個別メニュー画面を示す図である。 実施の形態６における第４例の個別メニュー画面を示す図である。 実施の形態６における第４例の個別メニュー画面を示す図である。 実施の形態６における第５例の個別メニュー画面を示す図である。
（本開示に至る経緯）
近年、外食産業の発達により、例えば、ファミリーレストラン、ハンバーガーショップ、コーヒーショップ、中華レストラン等の飲食品を提供する様々なチェーンストアが全国規模で展開されている。同一系列のチェーンストアであれば、異なる店舗であってもメニュー表は同じであることが多い。そのため、はじめて来店した店舗が、ユーザの行きつけのチェーンストアの店舗であれば、ユーザは見慣れたメニュー表を参照して効率よく飲食品の注文を行うことができる。
しかしながら、利用したことのないチェーンストアが運営する店舗にユーザがはじめて来店した場合、ユーザは見慣れていないメニュー表を参照して飲食品を注文することになり、注文に手間がかかってしまう。
上述の特許文献１の技術では、注文履歴データベースからユーザの注文履歴に関する情報が取得され、その注文履歴に関する情報に基づいてユーザに提案する注文案が生成されている。しかしながら、特許文献１の技術では、ユーザが来店している店舗における注文履歴のみを用いて注文案が作成されている。したがって、特許文献１の技術では、ユーザが店舗に例えば初めて来店した場合、その店舗の注文履歴がないため、注文案の生成ができなくなる。そのため、特許文献１の技術では、上述の手間を解消することはできない。
ここで、注文案の生成ができなかった場合に、店舗において一般客に用いられる汎用メニューを携帯端末に通知することが考えられる。しかしながら、携帯端末は表示面積に制約があるため、ユーザが関心のない飲食品が優先的に表示される可能性がある。この場合、ユーザはスクロール操作等により希望する飲食品を探し出すことが要求され、注文に手間がかかってしまう。
本開示は、このような課題を解決するためになされたものであり、表示面積に制約がある端末機器において効率的に自己の嗜好に合った飲食品を選択することが可能な技術を提供することである。
（１－１）本開示の一態様における情報提供方法は、第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する情報管理システムにおける情報提供方法であって、端末機器から前記識別情報及び前記第１レストランと系列が異なる第２レストランを示す店舗ＩＤを取得し、前記識別情報に対応する前記嗜好情報、及び前記店舗ＩＤが示す前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれる第１メニュー内容を配列し、前記メニュー情報は、前記第１メニュー内容と、前記第２レストランによって指定された第２メニュー内容とを含み、かつ、前記店舗ＩＤが示す前記第２レストランに関連するサーバからネットワークを介して取得され、前記順序にて配列された前記第１メニュー内容と、前記第２メニュー内容とを含むメニュー情報を前記端末機器に送信し、前記端末機器の表示画面内の第１表示領域に、前記順序にて配列された前記第１メニュー内容を表示させ、かつ、前記表示画面内の第２表示領域に、前記第２レストランによって指定された前記第２メニュー内容を表示させる。
本態様によると、第１レストランにて注文した注文履歴を含むユーザの嗜好情報が、前記ユーザを特定する識別情報と対応して情報管理システムにおいて管理されている。前記ユーザが利用する端末機器から前記第１レストランと異なる第２レストランを示す店舗ＩＤが取得される。そして、ユーザの嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容が配列され、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報が表示される。
このことにより、ユーザは、例え前記第２レストランを初めて利用する場合であっても、それまで利用したことがある前記第１レストランでの注文履歴などを含む嗜好情報に基づいて、表示面積に制約がある前記端末機器の表示画面において、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を優先的に表示できる。
従って、ユーザは、例え前記第２レストランを初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
さらに、本態様によれば、嗜好情報に対応した順序で配列された第１メニュー内容が第１表示領域に表示され、第２レストランによって指定された第２メニュー内容が第２表示領域に表示されるので、ユーザの嗜好と第２レストランの指定との双方が反映されたメニュー内容を表示できる。さらに、嗜好情報のみに基づいてメニュー内容を表示させると表示されるメニュー内容は固定化されていくが、第２レストランが指定するメニュー内容を表示することで、例えば第２レストランが指定する商品を第２メニュー内容に含ませることが可能となり、表示されるメニュー内容に変化をもたらせることができる。
（１－２）上記情報提供方法において、前記第２表示領域内における前記第２メニュー内容の配列が、前記第２レストランによって指定されていてもよい。
本態様によれば、第２レストランが指定した配列で第２メニュー内容が表示されるので、第２レストランは第２メニュー内容の配列順序をコントロールできる。これにより、例えば第２レストランがユーザに選択してほしい料理を優先的に第２表示領域に表示することができる。
（１－３）上記情報提供方法において、前記第１メニュー内容は、前記嗜好情報に対応した順序が第１順序である場合には前記第１順序に配列されて前記第１表示領域に表示され、かつ、前記嗜好情報に対応した順序が前記第１順序とは異なる第２順序である場合には前記第２順序に配列されて前記第１表示領域に表示され、前記第２メニュー内容は、前記嗜好情報に対応した順序が前記第１順序または前記第２順序のいずれの場合でも同じ形態で前記第２表示領域に表示されてもよい。
本態様によれば、第１表示領域に表示される第１メニュー内容は嗜好情報に応じて変動し得るが、第２表示領域に表示される第２メニュー内容は嗜好情報に依存することなく表示される。
（１－４）上記情報提供方法において、前記第２レストランは、前記第１レストランとは異なる系列のコーヒーショップであってもよい。
本態様によれば、ある系列のコーヒーショップにおいて、別の系列のコーヒーショップの注文履歴を含む嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報が表示される。そのため、例えば、ある系列のコーヒーショップを初めて利用する場合であっても、ユーザは効率的に自己の嗜好に合った飲食品を選択できる。
（１－５）上記情報提供方法において、前記第２レストランは、前記第１レストランとは異なる系列のハンバーガーショップであってもよい。
本態様によれば、ある系列のハンバーガーショップにおいて、別の系列のハンバーガーショップの注文履歴を含む嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報が表示される。そのため、例えば、ある系列のハンバーガーショップを初めて利用する場合であっても、ユーザは効率的に自己の嗜好に合った飲食品を選択できる。
（１－６）上記情報提供方法において、前記ユーザの端末機器の位置情報を取得し、前記位置情報に基づき、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報を前記端末機器に提供し、前記店舗ＩＤは前記端末機器において前記レストラン情報に基づき選択されてもよい。
本態様によれば、ユーザが居る地点の周囲に存在するレストランの中から希望のレストランをユーザは選択できる。そして、選択したレストランにおけるメニュー情報がユーザの嗜好情報に対応する順序でメニュー内容が配列されて表示される。そのため、選択したレストランが例えば初めて利用するレストランであっても、ユーザは効率的に自己の嗜好にあった飲食品を選択できる。
（１－７）上記情報提供方法において、前記ユーザの端末機器の位置情報を、ＧＰＳシステムを用いて取得してもよい。
本態様によれば、ＧＰＳシステムを用いて端末機器の位置情報が取得されるため、ユーザの位置を正確に特定し、ユーザの周囲に存在するレストランをユーザに提示できる。
（１－８）上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴がない場合、前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
本態様によれば、第２レストランにおいてユーザの注文履歴がない場合、第１レストランの注文履歴を含む嗜好情報に基づいたメニュー情報が表示される。これにより、ユーザは、第２レストランの系列が初めて利用する系列である場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
（１－９）上記情報提供方法において、前記情報管理システムに、前記ユーザによる前記第２レストランでの注文履歴がある場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
第２レストランが初めて利用するレストランではない場合、第１レストランの注文履歴を含む嗜好情報よりも第２レストランの注文履歴に基づいてメニュー情報を生成した方がユーザにとって都合がよい場合がある。本態様によれば、第２レストランにおいてユーザの注文履歴がある場合、第２レストランの注文履歴を含む嗜好情報に対応する順序にてメニュー内容が配列されたメニュー情報が表示される。したがって、ユーザは、第２レストランを過去に利用したことがある場合、第２レストランの注文履歴が反映されたメニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
（１－１０）上記情報提供方法において、前記情報管理システムにて、前記ユーザによる前記第２レストランでの注文履歴が所定量に満たない場合、前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
第２レストランを利用するのが初めてではない場合であっても利用回数が少なければ、第２レストランの注文履歴に基づいてユーザのメニュー情報を生成すると、ユーザの嗜好が十分に反映されたメニュー情報が生成できない可能性がある。本態様によれば、第２レストランでの注文履歴が所定量に満たない場合、第２レストランでの注文履歴だけでなく、他のレストランの注文履歴も含む嗜好情報に基づいてメニュー内容が配列されたメニュー情報が表示される。そのため、第２レストランにおいて、ユーザの嗜好が十分に反映されていないメニュー情報が表示されることを防止できる。
（１－１１）上記情報提供方法において、前記情報管理システムにて、前記ユーザによる前記第２レストランでの注文履歴が前記所定量以上である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
第２レストランをある程度利用している場合、第１レストランの注文履歴を含む嗜好情報よりも第２レストランの注文履歴に基づいてメニュー情報を生成した方がユーザにとって都合がよい場合がある。本態様によれば、第２レストランでの注文履歴が所定量以上の場合、第２レストランの注文履歴に基づいてメニュー内容が配列されたメニュー情報が表示される。したがって、ユーザは、第２レストランをある程度利用したことがある場合、第２レストランの注文履歴が反映されたメニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
（１－１２）上記情報提供方法において、前記情報管理システムにて、前記ユーザによる前記第２レストランでの直近の注文履歴が所定期間より前である場合、前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
第２レストランの利用が初めてではない場合であっても、久しく利用していない場合、例えば利用していない期間にユーザの嗜好が変化するというようなケースも想定され、第２レストランのメニュー情報の表示が妥当でないこともある。本態様によれば、このような場合において、第１レストランの注文履歴を含む嗜好情報が反映されたメニュー情報が表示されるため、ユーザは自己の嗜好に合った飲食品を効率よく選択できる。
（１－１３）上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの直近の注文履歴が前記所定期間内である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
第２レストランの利用が初めてではなく、久しぶりに利用するものでもない場合、第１レストランの注文履歴に基づく嗜好情報よりも第２レストランの注文履歴が反映されたメニュー情報を表示した方がユーザにとって都合がよいこともある。本態様では、このような場合において、第２レストランの注文履歴が反映されたメニュー情報が表示されるため、ユーザは自己の嗜好に合った飲食品を効率よく選択できる。
（１－１４）本開示の別の一態様における情報提供方法は、第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する情報管理システムにおける情報提供方法であって、前記ユーザの端末機器の位置情報を取得し、前記位置情報に基づき、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報を前記端末機器に提供し、前記端末機器から前記識別情報及び前記一以上のレストランの中で前記第１レストランと系列が異なる第２レストランを示す店舗ＩＤを取得し、前記識別情報に対応する嗜好情報及び前記店舗ＩＤが示す前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれる第１メニュー内容を配列し、前記メニュー情報は、前記第１メニュー内容と、前記第２レストランによって指定された第２メニュー内容とを含み、かつ、前記店舗ＩＤが示す前記第２レストランに関連するサーバからネットワークを介して取得され、前記順序にて配列された前記第１メニュー内容と、前記第２メニュー内容とを含むメニュー情報を前記端末機器に送信し、前記端末機器の表示画面内の第１表示領域に、前記順序にて配列された前記第１メニュー内容を表示させ、かつ、前記表示画面内の第２表示領域に、前記第２レストランによって指定された前記第２メニュー内容を表示させる。
本態様によると、第１レストランにて注文した注文履歴を含むユーザの嗜好情報が、前記ユーザを特定する識別情報と対応して情報管理システムにおいて管理されている。ユーザの端末機器の位置情報に基づき、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報が提供される。前記端末機器から前記一以上のレストランの中で前記第１レストランと系列の異なる第２レストランを示す店舗ＩＤが取得される。そして、ユーザの嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容が配列され、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報が表示される。
このことにより、ユーザは、例え前記第２レストランを未だ利用したことがない場合であっても、それまで利用したことがある前記第１レストランでの注文履歴などを含む嗜好情報に基づいて、表示面積に制約がある前記端末機器の表示画面において、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を優先的に表示できる。
従って、ユーザは、例え前記第２レストランを未だ利用したことがない場合であっても、効率的に自己の嗜好に合ったメニューがあるかを確認して選択できる。
さらに、本態様によれば、嗜好情報に対応した順序で配列された第１メニュー内容が第１表示領域に表示され、第２レストランによって指定された第２メニュー内容が第２表示領域に表示されるので、ユーザの嗜好と第２レストランの指定との双方が反映されたメニュー内容を表示できる。さらに、嗜好情報のみに基づいてメニュー内容を表示させると表示されるメニュー内容は固定化されていくが、第２レストランが指定するメニュー内容も表示することで、例えば第２レストランが指定する商品を第２メニュー内容に含ませることが可能となり、表示されるメニュー内容に変化をもたらせることができる。
（１－１５）上記情報提供方法において、設定期間内の前記第２レストランでの注文回数が一定以下である場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれる前記第１メニュー内容を配列してもよい。
本態様によれば、第２レストランでの注文回数が一定回数以下である場合、第２レストランでの注文履歴だけでなく、他のレストランの注文履歴も含む嗜好情報に基づいてメニュー内容が配列されたメニュー情報が表示される。そのため、第２レストランにおいて、ユーザの嗜好が十分に反映されていないメニュー情報が表示されることを防止できる。
（１－１６）上記情報提供方法において、設定期間内の前記第２レストランでの注文回数が一定以下である場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（１－１７）上記（１－１）の情報提供方法では、前記情報管理システムにおいて、前記第１レストランにて注文した前記注文履歴が前記第１レストランを示す店舗ＩＤと対応付けて記憶されていてもよい。
本態様によれば、第１レストランにて注文した注文履歴が第１レストランを示す店舗ＩＤと対応付けて記憶されている。このため、第１レストランを示す店舗ＩＤを用いることにより、第１レストランにて注文した注文履歴を参照することが容易になる。
（１－１８）上記（１－１４）の情報提供方法では、前記情報管理システムにおいて、前記第１レストランにて注文した前記注文履歴が前記第１レストランを示す店舗ＩＤと対応付けて記憶されていてもよい。
（１－１９）上記（１－１）の情報提供方法において、前記店舗ＩＤは前記端末機器において選択されてもよい。
本態様によれば、ユーザは端末機器において店舗ＩＤを選択できる。
（１－２０）上記（１－１４）の情報提供方法において、前記店舗ＩＤは前記端末機器において選択されてもよい。
（２－１）本開示の別の一態様における制御方法は、第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する第１サーバとネットワークを介して通信する端末機器の制御方法であって、前記識別情報及び前記第１レストランと系列が異なる第２レストランを示す店舗ＩＤの選択を、前記端末機器の入力デバイスを介して受け付け、前記識別情報に対応する嗜好情報を前記第１サーバから取得し、前記店舗ＩＤが示す前記第２レストランに関連する第２サーバから、前記第２レストランのメニュー情報を取得し、前記メニュー情報は、第１メニュー内容と、前記第２レストランによって指定された第２メニュー内容とを含み、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれる前記第１メニュー内容を配列し、前記端末機器の表示画面内の第１表示領域に、前記順序にて配列された前記第１メニュー内容を表示し、かつ、前記表示画面内の第２表示領域に、前記第２レストランによって指定された前記第２メニュー内容を表示する。
本態様によれば、メニュー内容の配列が端末機器で行われる態様においても、（１－１）と同様の効果が得られる。さらに、本態様によると、第２レストランのメニュー情報は第２サーバから取得されているものの、嗜好情報は第１サーバから取得されている。これにより、ユーザの許諾がない事業者に対して嗜好情報が渡らないようにしながらも、ユーザが初めて利用する第２レストランにおいて、ユーザの嗜好情報が考慮されたメニュー情報を表示できる。
（２－２）上記制御方法において、前記第2表示領域内における前記第２メニュー内容の配列が、前記第２レストランによって指定されてもよい。
（２－３）上記制御方法において、前記第１メニュー内容は、前記嗜好情報に対応した順序が第１順序である場合には前記第１順序に配列されて前記第１表示領域に表示され、かつ、前記嗜好情報に対応した順序が前記第１順序とは異なる第２順序である場合には前記第２順序に配列されて前記第１表示領域に表示され、前記第２メニュー内容は、前記嗜好情報に対応した順序が前記第１順序または前記第２順序のいずれの場合でも同じ形態で前記第２表示領域に表示されてもよい。
（２－４）上記制御方法において、前記第２レストランは、前記第１レストランとは異なる系列のコーヒーショップであってもよい。
（２－５）上記制御方法において、前記第２レストランは、前記第１レストランとは異なる系列のハンバーガーショップであってもよい。
（２－６）上記制御方法において、ネットワークを介して前記第１レストラン及び前記第２レストランに関連する情報を管理する第３サーバに、前記ユーザの端末機器の位置情報を出力し、前記位置情報に基づき前記第３サーバから、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報を取得し、前記レストラン情報に基づき前記店舗ＩＤの選択を受け付けてもよい。
（２－７）上記制御方法において、前記ユーザの端末機器の位置情報は、ＧＰＳシステムを用いて取得されてもよい。
（２－８）上記制御方法において、前記第１サーバから、前記ユーザによる前記第２レストランでの注文履歴を示す注文履歴情報を取得し、前記ユーザによる前記第２レストランでの注文履歴がない場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（２－９）上記制御方法において、前記ユーザによる前記第２レストランでの注文履歴がある場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（２－１０）上記制御方法において、前記第１サーバから、前記ユーザによる前記第２レストランでの注文履歴を示す注文履歴情報を取得し、前記ユーザによる前記第２レストランでの注文履歴が所定量に満たない場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（２－１１）上記制御方法において、前記ユーザによる前記第２レストランでの注文履歴が前記所定量以上である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（２－１２）上記制御方法において、前記第１サーバから、前記ユーザによる前記第２レストランでの注文履歴を示す注文履歴情報を取得し、前記ユーザによる前記第２レストランでの直近の注文履歴が所定期間より前である場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（２－１３）上記制御方法において、前記ユーザによる前記第２レストランでの直近の注文履歴が前記所定期間内である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（２－１４）上記制御方法において、前記第１サーバから、前記ユーザによる前記第２レストランでの注文履歴を示す注文履歴情報を取得し、設定期間内の前記第２レストランでの注文回数が一定回数以下である場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（２－１５）上記制御方法において、前記第１サーバにおいて、前記第１レストランにて注文した前記注文履歴が前記第１レストランを示す店舗ＩＤと対応付けて記憶されていてもよい。
（２－１６）本開示の別の一態様における端末機器は、（２－１）～（２－１５）のいずれかに記載の制御方法を実行するものでる。
（２－１７）本開示の別の一態様におけるプログラムは、（２－１）～（２－１５）のいずれかに記載の制御方法を前記端末機器のコンピュータに実行させるものである。
（２－１８）上記プログラムにおいて、前記ユーザを特定する識別情報は、前記プログラムに付与された情報端末毎のシリアルコードを含んでもよい。
本態様によれば、プログラムに付与された情報端末毎のシリアルコードが識別情報として用いられているため、人が見て無意味な文字列情報を識別情報として設定することができ、秘匿性がより高められた個人情報の通信が可能となる。
（２－１９）本開示の別の一態様における記録媒体は、（２－１）～（２－１５）のいずれかに記載の制御方法を前記端末機器のコンピュータに実行させるためのプログラムを記録したものである。
（３－１）本開示の別の一態様における情報提供方法は、第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する第１サーバと通信する第２サーバであって前記第１レストランと系列が異なる第２レストランと関連する第２サーバを含む情報管理システムにおける情報提供方法であって、端末機器から前記識別情報及び前記第２レストランを示す店舗ＩＤを取得し、前記第１サーバから前記識別情報に対応する前記嗜好情報を取得し、前記識別情報に関する前記嗜好情報は、前記第１サーバにおいて前記識別情報が特定する前記ユーザによって許諾されていると判断した場合に前記第１サーバから取得され、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれる第１メニュー内容を配列し、前記メニュー情報は、前記第１メニュー内容と、前記第２レストランによって指定された第２メニュー内容とを含み、かつ、前記第２サーバに保持され、前記順序にて配列された前記第１メニュー内容と、前記第２メニュー内容とを含むメニュー情報を前記端末機器に送信し、前記端末機器の表示画面内の第１表示領域に、前記順序にて配列された前記第１メニュー内容を表示させ、かつ、前記表示画面内の第２表示領域に、前記第２レストランによって指定された前記第２メニュー内容を表示させる。
本態様によれば、メニュー内容の配列が第２サーバで行われる態様においても、（１－１）と同様の効果が得られる。
（３－２）上記情報提供方法において、前記第２表示領域内における前記第２メニュー内容の配列が、前記第２レストランによって指定されていてもよい。
（３－３）上記情報提供方法において、前記第１メニュー内容は、前記嗜好情報に対応した順序が第１順序である場合には前記第１順序に配列されて前記第１表示領域に表示され、かつ、前記嗜好情報に対応した順序が前記第１順序とは異なる第２順序である場合には前記第２順序に配列されて前記第１表示領域に表示され、前記第２メニュー内容は、前記嗜好情報に対応した順序が前記第１順序または前記第２順序のいずれの場合でも同じ形態で前記第２表示領域に表示されてもよい。
（３－４）上記情報提供方法において、前記第２レストランは、前記第１レストランとは異なる系列のコーヒーショップであってもよい。
（３－５）上記情報提供方法において、前記第２レストランは、前記第１レストランとは異なる系列のハンバーガーショップであってもよい。
（３－６）上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴がない場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（３－７）上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴がある場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（３－８）上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴が所定量に満たない場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（３－９）上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴が前記所定量以上である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（３－１０）上記情報提供方法において、前記情報管理システムにて、前記ユーザによる前記第２レストランでの直近の注文履歴が所定期間より前である場合、前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（３－１１）上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの直近の注文履歴が前記所定期間内である場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴に対応した順序にて前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（３－１２）上記情報提供方法において、設定期間内の前記第２レストランでの注文回数が一定回数以下である場合、前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれる前記第１メニュー内容を配列してもよい。
（３－１３）上記情報提供方法において、前記第１サーバにおいて、前記第１レストランにて注文した前記注文履歴が前記第１レストランを示す店舗ＩＤと対応付けて記憶されていてもよい。
（３－１４）上記情報提供方法において、前記店舗ＩＤは前記端末機器において選択されてもよい。
（実施の形態１）
我々の社会は、今後もさらにインターネットが普及し、各種センサーが身近になることが予想される。これにより、我々の社会は、個人の状態及び活動等に関する情報から建造物及び交通網等を含む街全体の情報までもがデジタル化されて、コンピューターシステムで利用できる状態になっていくと予想される。デジタル化された個人に関するデータ（個人情報）は、通信ネットワークを介してクラウドに蓄積され、ビッグデータとして本人許諾に基づき第三者もアクセスできる仕組みを持つ情報銀行に管理され、個人や社会のために様々な用途に利用されていくことが期待される。
このような高度情報化社会は、日本ではＳｏｃｉｅｔｙ５．０と呼ばれる。高度情報化社会は、現実空間（フィジカル空間）と仮想空間（サイバー空間）とを高度に融合させた情報基盤（サイバーフィジカルシステム）により、経済発展と社会的課題の解決とが期待される社会である。
そうした高度情報化社会では、個人が日常の様々なシーンで意思決定を行う際に、蓄積された個人情報を含むビッグデータを分析して、その時の状況に応じた、その個人にとって最適と思われる選択肢を、その個人が知ることが可能になる。
以降では、そのようなサイバーフィジカルシステムが稼働する高度情報化社会において、個人の食事をテーマとして、経済効率化と個人最適化（パーソナライゼーション）とを実施する様態について説明していく。
Ｓｏｃｉｅｔｙ５．０では、ユーザの嗜好を示す嗜好情報のような個人情報は、情報銀行と称される個人情報を管理する事業者のサーバによって、本人許諾のない第三者にはアクセスできないように暗号化、秘匿化された上で一元管理される。これらの個人情報の多くはユーザの意識的な入力操作を必要とせず、情報銀行の管理の下、収集が継続され随時更新される。
個人最適化された飲食品の注文システムの一例としては、レストランのサーバから個人の情報端末にメニュー情報を送信し、ユーザの嗜好に即した飲食品からなるメニューを推奨メニューとして情報端末上に提示するものが考えられる。
図１は、本開示の情報提供システムの全体像の一例を示す図である。図１の情報提供システムは、Ｓｏｃｉｅｔｙ５．０を踏まえて構成されたシステムであり、個人情報を利用する一消費者であるユーザに適した商品又はサービスをユーザに提案し、商品又はサービスのユーザによる選択を支援する選択支援サービスを提供するシステムである。本実施の形態では選択支援サービスとして飲食品の注文を支援するサービスを主眼としている。具体的には情報提供システムは、外食時にユーザが飲食品を注文するために閲覧するメニュー情報を、そのユーザの個人情報とマッチングさせ、そのユーザにとって最適なメニューを提示するシステムである。
この情報提供システムは大きく３つの機器群から構成される。１つ目の機器群はユーザが保有するスマートフォン等の情報端末１００（端末機器の一例）を含む機器群である。情報端末１００にはマッチングアプリケーションがインストールされている。マッチングアプリケーション（以下、マッチングアプリと称する。）は、ユーザに適した商品又はサービスを、そのユーザの個人情報を用いて選別又は推薦するためのアプリケーションである。ここで言う個人情報とは、個人に関する公開又は非公開の情報が広く包含される。例えば、個人情報は、氏名、生年月日、住所、年収、所有する動産／不動産情報、身長／体重等の身体情報、遺伝子情報、アレルギー情報、病歴／診断カルテ等の医療情報、歩数／消費カロリーなどの活動量情報、食事履歴情報、心拍／血圧等のバイタルサイン情報、店舗／ＥＣサイトなどを介した購買情報、Ｗｅｂ検索エンジン／ＡＩスピーカーで検索した単語情報、メール／ＳＮＳで送受信された文章／映像音声情報、並びに移動履歴情報等のうちの少なくとも一つを含む。情報端末１００は、例えば、４Ｇ、５Ｇと称される移動体通信網により携帯基地局４００を介して、インターネットに接続可能である。
２つ目の機器群は第１サーバ２００を含む機器群である。
第１サーバ２００は、ユーザの個人情報を複数箇所に分散し、分散した個人情報をさらに暗号化して記憶する個人情報サーバである。例えば、第１サーバ２００は、クラウド上にある複数のストレージ装置にユーザの個人情報を断片化及び暗号化して記憶することで個人情報を管理する。これにより、高いセキュリティが確保され、個人情報の漏洩等が防止される。さらに、第１サーバ２００は、第三者からの問い合わせに応じて必要なデータをユーザ本人の許諾に応じて返信する機能を持つ。さらに、第１サーバ２００は、ユーザが許諾した事業者に対してユーザが許諾した個人情報をセキュアに共有する機能を持つ。すなわち、第１サーバ２００は情報銀行としての機能を持つ。この場合、第１サーバ２００は、例えば１つのデータを複数のストレージ装置に分散して記録する。１つのデータの一例は個人情報を記録した１つのファイルである。
本実施の形態では、第１サーバ２００は、ユーザの許諾に基づき、特定の事業者に対して特定の個人情報を共有させる。さらに、第１サーバ２００は、以下で説明する選択支援サービスを提供するための機能を持つ。
上述のマッチングアプリは、例えば第１サーバ２００の運営会社によって開発及び／または配布される。この運営会社はユーザが利用する可能性のある商品又はサービスに対するユーザの適合度合いを、ユーザの個人情報を用いて評価する。第１サーバ２００の運営会社、マッチングアプリの開発会社、及びマッチングアプリの配布会社は、それぞれ同一であってもよいし、異なっていてもよい。図１に示す情報提供システムは、上述したマッチングアプリを用いて選択支援サービスを実現するが、これは一例である。例えば、マッチングアプリ以外のアプリ又は一般的なブラウザ等を用いて選択支援サービスを実現してもよい。ユーザの個人情報をセキュアに扱うためには、マッチングアプリ等の専用のアプリによって選択支援サービスを提供することが好ましい。但し、これは一例であり、例えば公開されている個人情報などのセキュリティの重要度が低い個人情報を扱う場合、又はインターネットブラウザを用いてＨＴＴＰＳ通信のようにセキュリティを確保するための機能が提供される場合は、マッチングアプリ以外の手段で選択支援サービスが提供されてもよい。
マッチングアプリは、情報端末１００の内部でのみ個人情報を取り扱う。マッチングアプリは、時間、場所、及び状況等の任意の条件下において、ユーザに最も適すると思われる商品又はサービスをユーザに提示する。例えば、マッチングアプリは、ユーザの購買等の経済活動における仲介斡旋機能を提供する。
マッチングアプリは、これまでサービス事業者ごとにサイロ化されていたリコメンド機能をオープンに開放したアプリである。例えば、ＥＣサイト等の電子商取引市場で有名なある１つのサービス事業者の例で説明する。当該サービス事業者のサイトには数多くの商品が掲載されている。特定の商品が検索又は購入されると、その商品と関連性が高い他の商品（例えば、よく一緒に購入される商品）がユーザに推薦される。このような購買に対するリコメンド機能は、当該サービス事業者のＥＣサイトの中でしか有効にならない。したがって、当該リコメンド機能は、他のサービス事業者が運営するＥＣサイトにおいて商品を購入する時、レストランで食事を注文する時、又は休暇の家族旅行を計画する時において、何ら効果を発揮しない。
今後、情報銀行に個人情報が集約され、膨大かつ多種多様で長期間に渡る正確な個人情報が所定の条件下で誰でもアクセスできる仕組みが整うことが予想されている。この場合、ある１つのサービス事業者のＥＣサイトにおける検索又は購入履歴、及び様々なユーザの個人情報を用いて、当該サービス事業者の商品だけなく、あらゆる商品又はサービスを対象として適合度合いを推定することが可能となる。これにより、様々な選択肢の中からユーザにとってより価値の高い商品又はサービスを推薦することが可能となる。
本実施の形態が想定する第１サーバ２００は、上記のような思想又は機能を実現するために、個人情報を分散化及び暗号化してストレージ装置に記憶し、外部との個人情報のアクセスを管理、制御するクラウドサーバである。
３つ目の機器群は、各事業者が各事業者固有のデータを管理する第２サーバ３００を含む機器群である。各事業者は、第２サーバ３００を所有又はレンタルし、自社の商品及び／又は自社のサービスに関する情報を管理及び／又は提供している。本実施の形態では、事業者として、チェーンストアを運営する会社が該当する。図１の例では、レストランＡ系列が運用する第２サーバ３００、レストランＢ系列が運用する第２サーバ３００、及びレストランＣ系列が運用する第２サーバ３００の３つの第２サーバ３００が例示されている。レストランＡ系列は、例えば、Ａ社が経営するＡ系列のチェーンストアであり、レストランＢ系列は、例えば、Ｂ社が経営するＢ系列のチェーンストアであり、レストランＣ系列は、例えば、Ｃ社が経営するＣ系列のチェーンストアである。チェーンストアは、ブランド、経営方針、サービスの内容、及び外観などに統一性を持たせ、多数の店舗の運営や管理を行う経営形態を指す。チェーンストアが展開するレストランとしては、ファミリーレストラン、コーヒーショップ及びハンバーガーショップなどが含まれる。なお、事業者は、お弁当屋又はファストフード店のように調理済み料理のテイクアウトが可能な中食事業者であってもよい。さらに、事業者は、スーパーマーケットのように自宅で調理することを主眼においた内食向けの食材販売を行う事業者であってもよい。第２サーバ３００は例えばクラウドサーバで構成される。
図１の例では、レストランＡ系列、レストランＢ系列、レストランＣ系列はそれぞれ異なる会社が経営するものとして説明したが、これは一例であり、同一の会社が経営してもよい。また、図１の例では、第２サーバ３００は３つとして説明したが、これは一例であり、４つ以上であってもよいし、１つ又は２つであってもよい。
本実施の形態の情報提供システムの効果の１つとしては、個人情報が不特定多数の事業者に渡らないことが挙げられる。第１サーバ２００の情報銀行が、本人許諾に基づき、特定の事業者に対してのみ、特定の個人情報を共有することが許可されているためである。
しかしながら、この運用を個々にユーザに判断させるのはとても面倒である。データ運用ポリシーを定める信託業者がいても、具体的にどのデータが誰に渡ったのかをユーザは把握できず、ユーザは不安に感じる可能性がある。
そこで、本実施の形態は、第１サーバ２００を運営している事業者が、保管している個人情報を利用すること、例えば、暗号を解き解釈することを、ユーザの許諾が無い限り、禁止又は制限してもよい。
さらに、プライバシーに厳密な運営ポリシーの下で、個人情報の管理及びマッチングアプリを提供する情報銀行又は情報仲介業者が市場に参入している場合、ユーザは当該情報銀行又は情報仲介業者との間でそのサービスの提供を受ける契約を結んでもよい。これにより、本人許諾がない事業者に対して個人情報が渡らないようにすることが可能となる。
本実施の形態の情報提供システムは、本人以外の第三者にセンシティブな情報を含む個人情報が知られる可能性を低減し、時々刻々と変化する膨大な個人情報を様々なサービスとのマッチングのために本人許諾のもとに利用することができる次世代情報社会の運用システムの一形態である。以降、この想定の下で情報提供システムを説明する。
図１に示す情報提供システムは、さらに生体センサー６００及びパブリック情報サーバ５００を含んでいる。
パブリック情報サーバ５００は、レストランに関する情報及び個人情報とは異なる公共情報を管理する。パブリック情報サーバ５００はインターネットに接続されている。例えば、公共情報には、地図情報、天気情報、及び交通情報などが含まれる。これらの情報はマッチングにおいて必要があれば、適宜利用される。
生体センサー６００は、スマートウォッチなどの生体センサーである。生体センサー６００は、情報端末１００を所有するユーザにより装着されている。生体センサー６００は、継続的にユーザのバイタルサイン情報及び／又は活動量情報を計測する。生体センサー６００が計測した各種のバイタルサイン情報及び／又は活動量情報は、Ｂｌｕｅｔｏｏｔｈ（登録商標）のような近距離通信によって、生体センサー６００から情報端末１００に送信される。バイタルサイン情報及び／又は活動量情報は、情報端末１００にインストールされたセンサーアプリによって、保管及び／又は管理される。センサーアプリは、収集したバイタルサイン情報及び／又は活動量情報とその測定時刻を示す時刻情報とを、ユーザアカウント情報にしたがって第１サーバ２００へアップロードする。これによりバイタルサイン情報及び／又は活動量情報が蓄積される。
センサーアプリは、保管及び／又は管理するデータに対するアクセス権をマッチングアプリ又は情報端末１００のＯＳ（Ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）に付与してもよい。この場合、バイタルサイン情報及び／又は活動量情報はマッチングアプリ又はＯＳを介して、第１サーバ２００へアップロードされる。センサーアプリは、バイタルサイン情報及び／又は活動量情報を、情報端末１００のメモリに保管してもよいし、第１サーバ２００にアップロードすることによって保管してもよい。
図２は、本実施の形態に係る情報提供システムの具体的な構成の一例を示す図である。図２に示す情報提供システムは、図１で説明した情報端末１００、第１サーバ２００、及び第２サーバ３００を含む。なお、図２においては、携帯基地局４００、生体センサー６００の図示は説明の便宜上省かれている。情報端末１００、第１サーバ２００、及び第２サーバ３００はネットワークＮＴを介して相互に通信可能に接続されている。ネットワークＮＴは携帯電話通信網及びインターネットを含む広域通信網である。
情報端末１００は、スマートフォン又はタブレット端末等の携帯型の情報処理装置で構成されている。本実施の形態において、情報端末１００は、レストラン系列の店舗で飲食品を注文するユーザによって携帯される。情報端末１００は、通信部１０１、メモリ１０２、カメラ１０３、演算部１０４、ディスプレイ１０５、操作部１０６、及びＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）センサー１０７を含む。
通信部１０１は、情報端末１００をネットワークＮＴに接続する通信回路で構成されている。通信部１０１は、ユーザが操作部１０６を操作して選択した第１レストランとは系列の異なる第２レストランの店舗ＩＤをユーザの識別情報と対応付けて第１サーバ２００に送信する。第１レストランは、ユーザの行きつけのレストランチェーンのレストランである。第２レストランとは、第１レストランとは系列が異なるレストランである。
通信部１０１は、第２サーバ３００から送信された後述するメニュー情報を受信する。演算部１０４は通信部１０１が受信したメニュー情報をディスプレイ１０５に表示させる。通信部１０１は、演算部１０４の制御の下、ユーザが注文した飲食品を示す注文情報を第２サーバ３００に送信する。メモリ１０２は、フラッシュメモリ等の不揮発性のストレージ装置で構成されている。通信部１０１は、ＧＰＳセンサー１０７が検出した情報端末１００の地点の周辺地域の地図情報である周辺地図情報を受信する。この周辺地図情報はディスプレイ１０５に表示される。
メモリ１０２は、ユーザを特定するための識別情報を予め記憶する。
カメラ１０３は、ＣＭＯＳセンサー等で構成される撮像装置である。カメラ１０３は、例えば顔認証を行う際にユーザの顔を撮影するために用いられる。
演算部１０４は、ＣＰＵ等のプロセッサで構成されている。演算部１０４は、情報端末１００のＯＳ、上述のマッチングアプリ、及びブラウザ等を実行する。ＧＰＳセンサー１０７は、ＧＰＳ衛生からの信号に基づいて情報端末１００の位置を検出する。
ディスプレイ１０５は、例えば液晶表示パネルまたは有機ＥＬパネル等で構成され、種々の画像を表示する。例えば、ディスプレイ１０５は、上述のメニュー情報を表示する。さらに、ディスプレイ１０５は、周辺地図情報を表示する。
操作部１０６は、例えばタッチパネル等の入力装置で構成される。操作部１０６は、周辺地図情報に表示されたレストランのうち、ユーザが来店を希望するレストランを選択する操作を受け付ける。操作部１０６は、メニュー情報の中からユーザが希望する飲食品を選択する指示を受け付ける。
以上が情報端末１００の構成である。
次に、第１サーバ２００の構成について説明する。第１サーバ２００は、通信部２０１、演算部２０２、及びメモリ２０３を含む。通信部２０１は、第１サーバ２００をネットワークＮＴに接続するための通信回路で構成されている。通信部２０１は、情報端末１００から情報端末１００のユーザを特定する識別情報及び第１レストランと系列が異なる第２レストランを示す店舗ＩＤを受信する。この店舗ＩＤは、情報端末１００を操作するユーザが選択した店舗の識別情報である。通信部２０１は、演算部２０２が生成した後述する個別メニュー情報を第２レストランを選択したユーザの情報端末１００に送信する。
演算部２０２はＣＰＵ等のプロセッサで構成されている。演算部２０２は、メモリ２０３が記憶するユーザの個人情報を処理する。
演算部２０２は、第２レストランを選択したユーザの情報端末１００の周辺に存在する１以上のレストランを表す店舗情報を情報端末１００に提供する。情報端末１００のユーザはこの提供された店舗情報から第２レストランを選択することになる。この選択により情報端末１００からユーザが選択した第２レストランの店舗ＩＤとユーザの識別情報とが第１サーバ２００に送信される。
演算部２０２は、情報端末１００から店舗ＩＤと対応付けて送信されたユーザの識別情報に対応する嗜好情報をメモリ２０３から抽出する。演算部２０２は、抽出した嗜好情報及び店舗ＩＤが示す第２レストランのメニュー情報に基づき、嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報である個別メニュー情報を生成する。この個別メニュー情報は、店舗を選択したユーザの情報端末１００のディスプレイ１０５に表示される。第２レストランのメニュー情報は、第２レストランが属する系列において一般の顧客向けに生成された標準メニュー情報である。この標準メニュー情報には、第２レストランが属する系列が定めた所定の順序にてメニュー内容が配列されている。メニュー内容とは、第２レストランが提供する飲食品のことを指す。
ここで、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴がない場合、メモリ２０３から抽出した嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランが属する系列を初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
一方、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴がある場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランを過去に利用したことがある場合、第２レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
なお、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量に満たない場合、当該ユーザの識別情報に対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。
この場合、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量以上である場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。
さらに、演算部２０２は、第２レストランを選択したユーザによる第２レストランでの直近の注文履歴が所定期間より前である場合、当該ユーザの識別情報に対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。
演算部２０２は、例えば、通信部２０１が、許諾ユーザについての個人情報の取得を要求する信号を受信したとする。許諾ユーザとは、情報端末１００又は第２サーバ３００から要求された第１サーバ２００に記憶された個人情報の読み出しを、直接的に許可したユーザ又は信託した第三者を経由して間接的に許諾したユーザである。この場合、演算部２０２は、情報端末１００又は第２サーバ３００からの要求に応じて、メモリ２０３に記憶されている許諾ユーザの個人情報を読み出して通信部２０１に返信させる。なお、読み出される個人情報は、管理されている個人情報の全体であってもよいし、又は、管理されている個人情報のうち、要求された特定項目に関連する情報だけ（個人情報の一部のみ）であってもよい。
メモリ２０３は、ハードディスクドライブ等の不揮発性の複数のストレージ装置で構成されている。メモリ２０３は、１以上のユーザの個人情報を記憶する。個人情報には各ユーザの嗜好情報が含まれる。嗜好情報は、各ユーザの飲食物に対する嗜好を示す情報である。嗜好情報には、各ユーザの飲食品の注文履歴、購入履歴、検索履歴、嗜好予測値（協調フィルタリングなどを用いた嗜好の予測情報）などが含まれてもよい。本実施の形態では、嗜好情報のことを端的に注文履歴として表現することもある。嗜好情報（注文履歴）はユーザ毎に生成された図１２に示す注文履歴データベースＤ２によって管理され、メモリ２０３に記憶されている。
行動履歴情報は、各ユーザの行動履歴を示す情報である。個人情報は、複数のストレージ装置において分散化及び暗号化された上で記憶される。メモリ２０３が記憶する個人情報には、嗜好情報の他、生体情報と、購買履歴情報と、行動履歴情報とが含まれていてもよい。生体情報は心拍数等の各ユーザの生体に関する情報である。購買履歴情報は、各ユーザの商品（物品）又はサービスの購買履歴を示す情報である。行動履歴情報は、例えば、ユーザの位置情報と時刻情報とが対応付けられた時系列データで構成される。
次に、第２サーバ３００の構成について説明する。第２サーバ３００は、各レストラン系列に対応して１又は複数存在する。第２サーバ３００は、通信部３０１、演算部３０２、及びメモリ３０３を含む。通信部３０１は第２サーバ３００をネットワークＮＴに接続するための通信回路で構成される。通信部３０１は、情報端末１００からの要求に応じて標準メニュー情報を第１サーバ２００に送信する。演算部３０２は、ＣＰＵ等のプロセッサで構成される。演算部３０２は、メモリ３０３が記憶する標準メニュー情報を処理する。メモリ３０３はハードディスクドライブ等の不揮発性のストレージ装置で構成されている。メモリ３０３は、標準メニュー情報を記憶する。
（個別メニュー情報による飲食品の注文）
個別メニュー情報による飲食品の注文は、マッチングアプリの起動をトリガーに開始される。図３は、飲食品を注文するユーザがマッチングアプリを起動した直後に情報端末１００に表示される認証画面Ｇ１の一例を示す図である。認証画面Ｇ１は、指紋認証によりユーザ認証を行うための画面である。認証画面Ｇ１には、中央に指紋を模式的に示す指紋画像１２０１が表示され、指紋画像１２０１の下部には「指紋認証してください」とのメッセージが表示されている。これらにより、認証画面Ｇ１は、ユーザに対して指紋認証を行うよう促している。認証画面Ｇ１の上部には「パーソナルマッチング」と記載されている。これにより、認証画面Ｇ１はマッチングアプリの画面であることをユーザに確認させることができる。このことは、後述する図４及び図５においても同じである。
図４は、他の一例に係る認証画面Ｇ２を示す図である。認証画面Ｇ２は、顔認証によりユーザ認証を行うための画面の一例である。認証画面Ｇ２には、情報端末１００がユーザの正面からの顔の画像を適当なサイズで捉えられるよう、中央に顔の輪郭を模式的に示す点線１３０１が表示されている。ユーザは点線１３０１に収まるように自身の正面からの顔が表示されるように情報端末１００の向き及び位置を調整する。
上記のユーザ認証の方法に比べて必要な認証精度をより少ないユーザの負担で実現できるユーザ認証の方法があれば、その方法が採用されてもよい。ユーザ認証の方法としては、一般的にセキュリティ強度が高いと言われる２段階認証が採用されてもよいし、ユーザＩＤとパスワードとを入力する方法が採用されてもよい。
図５は、マッチングアプリによるユーザ認証が終わった直後に表示されるホーム画面Ｇ３の一例を示す図である。ホーム画面Ｇ３には、上段にアプリ名称「パーソナルマッチング」が表示され、中段に複数のタイルオブジェクト１４０１がマトリックス状に表示されている。各タイルオブジェクト１４０１には、マッチングアプリが取り込んだ連携機能又は別アプリが対応付けられている。別アプリは、例えば、マッチングアプリ内で起動するアプリである。この例では、ａ、ｂ、ｃ、ｄ、ｅと記載された５つのタイルオブジェクト１４０１が表示されている。これらのタイルオブジェクト１４０１には、マッチングアプリに連携して自社商品又は自社サービスのマッチングを行う専用機能（例えば、マッチングアプリ内で利用可能なあるレストランのアプリ）が対応付けられている。これにより、ユーザは、ａ、ｂ、ｃ、ｄ、ｅで示される５種類の連携機能が利用可能である。グレイアウトされたタイルオブジェクト１４０１は、連携機能がインストールされていない空きのタイルオブジェクトである。ホーム画面の下段には、左よりスキャンボタン１４０２、マップボタン１４０３、アカウントボタン１４０４、及びホームボタン１４０５が表示されている。こら４つのボタンはユーザに共通して提供される固定ボタンである。スキャンボタン１４０２は、上述したレストラン等の事業者が提供するサービスに連携したＱＲコード（登録商標）、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）タグ、ＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ ＩＤｅｎｔｉｆｉｅｒ）タグ等を読み取る場合に使用されるボタンである。マップボタン１４０３は、情報端末１００の現在の地点の周辺にあるマッチングアプリに対応する店舗情報及び／又はその店舗にて提供される商品又はサービス情報を含むマップ画面を表示させるボタンである。アカウントボタン１４０４は、ユーザのアカウント情報を登録及び編集するためのボタンである。アカウント情報の登録及び編集には、例えば、個人認証の設定及び第１サーバ２００との連携機能の設定等が含まれる。ホームボタン１４０５は、画面表示をこの図に示されるホーム画面Ｇ３に戻すためのボタンである。
ホーム画面Ｇ３では、上述のようにマッチングアプリを介して他の事業者のサービスと連携するための専用機能を示すタイルオブジェクト１４０１が中段に集約して配置されている。これらのタイルオブジェクト１４０１はユーザの好みに応じて、表示の有無及び配置する場所が設定可能である。よって、ユーザは、１つのマッチングアプリを用いて、数多くの事業者（例えば、家電量販店、ＤＶＤ／Ｂｌｕ－ｒａｙ（登録商標）レンタル店、本屋、コーヒーショップ、タクシー等）が提供する商品又はサービスのうち、個人情報をもとにそのユーザに適合する商品及び／又はサービスを取得できる。
図６は、情報端末１００に表示されるマップ画面Ｇ４の一例を示す図である。このマップ画面Ｇ４は、ホーム画面Ｇ３においてマップボタン１４０３を選択する操作が入力された場合に表示される。マップ画面Ｇ４には、情報端末１００の現在の地点を含む地域の地図が含まれる。さらに、マップ画面Ｇ４には、この地域内にあるマッチングアプリに対応した店舗情報が表示されている。ここでは、ユーザの現在の地点を示すアイコン３２００に加えて、レストランＡ系列の店舗Ａ１、レストランＡ系列の店舗Ａ２、本屋Ｋ系列の店舗Ｋ１、及びレストランＢ系列の店舗Ｂ１が表示されている。
ユーザはこのマップ画面Ｇ４を見ながら、来店を希望する店舗を選択する。この例では、アイコン３２１０で示される、現在の地点から一番近いレストランＢ系列の店舗Ｂ１が選択される。ユーザは、例えば、アイコン３２１０を指でタッチすることで、レストランＢ系列の店舗Ｂ１を選択することができる。アイコン３２１０がタッチされると、マッチングアプリは、アイコン３２１０が示すレストランＢ系列の店舗Ｂ１の接続先情報及び店舗ＩＤを取得する。さらに、マッチングアプリはユーザの識別情報（ユーザＩＤ）をメモリ１０２から取得する。ユーザＩＤは、図１８で後述するように、情報端末１００の「ａｃｃｏｕｎｔ」ディレクトリ下のｕｓｅｒ＿ａｃｃｏｕｎｔ．ｘｍｌファイルに格納されている。接続情報は例えばレストランＢ系列の第２サーバ３００と通信するためのアドレス情報（例えば、ＵＲＬ等）である。
マッチングアプリは、取得した店舗ＩＤとユーザＩＤとをもとに、第１サーバ２００とレストランＢ系列の第２サーバ３００と連携して、当該ユーザの個別メニュー情報を取得する。
具体的には、マッチングアプリは、店舗ＩＤとユーザＩＤとを含む個別メニューの取得要請を第１サーバ２００に送信する。この取得要請を受信した第１サーバ２００は、店舗ＩＤをもとに、その店舗が提供可能な標準メニュー情報の取得要請をレストランＢ系列の第２サーバ３００に送信する。この取得要請を受信した第２サーバ３００は、レストランＢ系列の標準メニュー情報を第１サーバ２００に送信する。標準メニュー情報は図１８で後述する第２サーバ３００の「ＲｅｓＢ．ｈｔｍｌ」ファイル及び「ＲｅｓＢ．ｃｓｓ」ファイルに記憶されている。
レストランＢ系列の標準メニュー情報を受信した第１サーバ２００は、取得した標準メニュー情報を、このユーザＩＤを持つユーザに対して最適化するために、このユーザのレストランＢ系列での過去の注文履歴をメモリ２０３から取得する。ここでは、このユーザについてレストランＢ系列の注文履歴がメモリ２０３になかったとする。
この場合、第１サーバ２００は、このユーザについて、例えば他のレストラン系列の注文履歴をメモリ２０３から取得する。そして、第１サーバ２００は、他のレストラン系列の注文履歴の中からユーザによりよく注文されている飲食品の表示順序が上位になるように、レストランＢ系列の標準メニューの飲食品の順序を変更する。例えば、このユーザについて他のレストランの注文履歴から「カフェモカ」がよく注文されていたとする。この場合、第１サーバ２００は、レストランＢ系列の個別メニュー情報において、カフェモカの注文がより容易になるように、「カフェモカ」の表示順序を上位に配列する。さらに、この場合、第１サーバ２００は、「カフェモカ」の表示サイズ及び／又は色使いの識別が容易になるように、「カフェモカ」の表示態様をデフォルトの表示態様から変更してもよい。
上記のようにして生成されたレストランＢ系列の個別メニュー情報は、第１サーバ２００から情報端末１００へ送信される。
図７は、情報端末１００に表示される個別メニュー情報の表示画面の一例である個別メニュー画面Ｇ５を示す図である。この個別メニュー画面Ｇ５は、マップ画面Ｇ４でユーザが選択したレストランＢ系列の個別メニュー画面である。個別メニュー画面Ｇ５の上部には「レストランＢ Ｂ１店 カスタムメニュー」と記載されている。これは、この個別メニュー画面Ｇ５に掲載されているメニューが、ユーザが選択した店舗Ｂ１が属するレストランＢ系列の標準メニュー情報と、メモリ２０３に記憶されたユーザの注文履歴とを考慮してパーソナライズされたメニューであることを意味している。
この例では、このユーザについてレストランＢ系列の注文履歴はメモリ２０３に記憶されていなかったものの、このユーザについて他のレストラン系列の注文履歴がメモリ２０３に記憶されていた。そして、このユーザについて他のレストラン系列の注文履歴が示す各飲食品に対する注文回数がアイスクリーム、カプチーノ、カフェモカ、タピオカヨーグルト、アイスコーヒー、チョコクッキーの順であった。そのため、個別メニュー画面Ｇ５ではこの順で、各飲食品を示すタイルオブジェクト７０１が配列されている。
これにより、ユーザの嗜好に合う飲食品がより注文しやすい位置に表示される結果、ユーザは、自己の嗜好に合う飲食品を効率よく選択することができる。図７の例では、各タイルオブジェクト７０１の表示順位は、左上に向かうほど上位であり、右下に向かうほど下位という順位である。但し、これは一例であり、右上に向かうほど上位であり、左下に向かうほど下位という順位であってもよい。
図７の例では、タイルオブジェクト７０１は、３行２列でマトリックス状に表示されているが、これは一例であり、３行１列或いは４行２列というように他の行列数で表示されてもよい。さらに、図７の例において、初期画面に表示できなかった飲食品のタイルオブジェクト７０１は、スクロール操作により表示可能である。初期画面とは個別メニュー画面Ｇ５が表示された際に最初に表示される画面である。
ユーザが注文しやすいような個別メニュー画面Ｇ５のデザインは、さらに、下記のようなものであってもよい。例えば、注文回数が上位の飲食品をタイルオブジェクト７０１が個別メニュー画面Ｇ５の初期画面内に優先的に配列されたり、その初期画面の中で注文回数が多い飲食品ほどタイルオブジェクト７０１が画面中央に配列されたりしてもよい。さらに、このような配列がされたうえで、注文回数が多い飲食品ほどタイルオブジェクト７０１のサイズが大きく表示されたり、注文回数が多い飲食品ほど他の飲食品と区別しやすいように異なる色使い又は境界線の太さでタイルオブジェクト７０１が表示されたり、注文回数が多い飲食品ほど商品名、価格、及び／又は商品の画像が装飾されたりしてもよい。
図８は、情報端末１００に表示される個別メニュー情報の表示画面の別の一例である個別メニュー画面Ｇ６を示す図である。この個別メニュー画面Ｇ６では、注文回数が上位から所定数（ここでは、上位２つ）の飲食品（ここでは、アイスクリーム、カプチーノ）のタイルオブジェクト７０１１が他の飲食品（ここでは、カフェモカ、タピオカヨーグルト）のタイルオブジェクト７０１２よりも上側に配置されている。カフェモカ及びタピオカヨーグルトのタイルオブジェクト７０１２は、個別メニュー画面Ｇ６の３行目に配置されている。
さらに、タイルオブジェクト７０１１は、タイルオブジェクト７０１２よりもサイズが大きく表示されている。さらに、タイルオブジェクト７０１１は、タイルオブジェクト７０１２よりも枠８０１が太くされると共に枠８０１に装飾が施されている。枠８０１に対する装飾は、例えば、枠８０１を金色、赤色などの目立つ色で表示させる態様が採用できる。さらに、タイルオブジェクト７０１１は、タイルオブジェクト７０１２よりも飲食品を示す画像８０２が大きくされている。さらに、タイルオブジェクト７０１１は、飲食品を示す画像８０２の周囲にデフォルメするマーク８０３（ここでは、星マーク）が表示されている。さらに、タイルオブジェクト７０１１は、タイルオブジェクト７０１２よりも飲食品名の文字列８０４のサイズが大きく表示されている。この文字列８０４は、影付き文字などで表示することによってデフォルメされていてもよい。さらに、タイルオブジェクト７０１１は、お気に入りであることを示すマーク８０５（ここでは、ハートマーク）が表示されている。
図８において、アイスクリームのタイルオブジェクト７０１１がカプチーノのタイルオブジェクト７０１１よりも上側に配置されているのは、アイスクリームに対するユーザの注文回数がカプチーノに対するユーザの注文回数よりも多かったからである。図８において、初期画面に表示できなかった飲食品のタイルオブジェクト７０１２はスクロール操作によって表示されてもよい。この場合、個別メニュー画面Ｇ６が縦方向にスクロール操作されることで、全タイルオブジェクトが縦方向にスクロールされてもよい。或いは、タイルオブジェクト７０１２の表示欄を横方向にスクロール操作することで、タイルオブジェクト７０１１の表示は維持されたまま、タイルオブジェクト７０１２のみがスクロールされてもよい。
図９は、情報端末１００に表示される標準メニュー情報の表示画面の一例である標準メニュー画面Ｇ７を示す図である。標準メニュー画面Ｇ７では、ユーザごとに最適化されていないレストランＢ系列の店舗Ｂ１の標準メニュー情報が示されている。
標準メニュー画面Ｇ７の上部には「レストランＢ Ｂ１店 標準メニュー」と記載されている。これは、この標準メニュー画面Ｇ７に掲載されているメニューが、レストランＢ系列の標準メニューあることを意味している。標準メニュー画面Ｇ７には、例えば３行２列のマトリックス状にタイルオブジェクト７０１が配置されている。ここでは、例えばレストランＢ系列において人気が高い飲食品ほど注文しやすい位置にタイルオブジェクト７０１が配置されている。具体的には、左上側ほど人気が高く、右下側ほど人気が低くなるようにタイルオブジェクト７０１が配置されている。標準メニュー画面Ｇ７は、スクロール操作により、初期画面で表示されなかったタイルオブジェクト７０１が表示可能に構成されている。
標準メニュー画面Ｇ７では、ユーザ個別の嗜好情報が考慮されることなくタイルオブジェクト７０１が配置されているため、ユーザは希望する飲食品のタイルオブジェクト７０１を探し出すのに手間がかかる。
これに対して、個別メニュー画面Ｇ５，Ｇ６ではユーザの嗜好に合う飲食品が注文し易い位置に配置されているため、ユーザは希望する飲食品のタイルオブジェクト７０１を容易に探し出せる可能性が高くなる。さらに、個別メニュー画面Ｇ５，Ｇ６では第１サーバ２００が記憶しているユーザの注文履歴に基づいて、ユーザの注文回数が多い飲食品のタイルオブジェクト７０１ほどより上位に配置されている。そのため、ユーザが選択した店舗Ｂ１はもとより、その店舗Ｂ１が属するレストランＢ系列のいずれの店舗にもユーザが来店したことがない場合であっても、個別メニュー画面Ｇ５，Ｇ６には、ユーザの嗜好が考慮された順序でタイルオブジェクト７０１が配列されている。
例えば、ユーザはレストランＡ系列の店舗Ａ１が行きつけの店舗であり、その店舗Ａ１においてユーザは自己の情報端末１００に自己の注文履歴が考慮された個別メニュー画面を表示させて、飲食品を注文していたとする。この場合、ユーザはレストランＢ系列の店舗Ｂ１に初めて来店したにもかかわらず、自己の情報端末１００において行きつけのレストランＡ系列の個別メニュー画面と同様の順序で飲食品が配列された個別メニュー画面Ｇ５，Ｇ６を表示させることが可能となる。これにより、ユーザは希望する飲食品を速やかに探し出すことが可能になると共に安心感も与えることが可能となる。さらに、ユーザに対して初めて来店した系列の店舗であるにもかかわらず見慣れた順序で飲食品が配置された個別メニュー画面が表示されるため、ユーザに驚きを与え、注文に対する関心を向上させることも可能となる。
図１０は、図７に示す個別メニュー画面Ｇ５において、ユーザが飲食品を注文する様子を示した図である。ここでは、カプチーノのタイルオブジェクト７０１３とチョコクッキーのタイルオブジェクト７０１４とが選択されている。そのため、タイルオブジェクト７０１３，７０１４の色がデフォルトの第１色から選択されたことを示す第２色に変更されている。さらに、タイルオブジェクト７０１３，７０１４がそれぞれ１回タッチされたため、タイルオブジェクト７０１３，７０１４のそれぞれに注文した個数を示す文字列である「１」が表示されている。
図１１は、図１０で選択した飲食品の注文を確定する際に表示される注文確定画面Ｇ８の一例を示す図である。注文確定画面Ｇ８は、図１０に示す個別メニュー画面Ｇ５において、図略の「注文に進む」ボタンを押すことで表示される。注文確定画面Ｇ８には、個別メニュー画面Ｇ５で選択されたカプチーノのタイルオブジェクト７０１３と、チョコクッキーのタイルオブジェクト７０１４とが表示されている。タイルオブジェクト７０１３，７０１４の下側には注文した飲食品の合計金額を示す合計金額表示欄７０１５が表示されている。ここでは、「カプチーノ」と「チョコクッキー」とが１つずつであり合計金額が５００円であったため、合計金額表示欄７０１５には「５００円」が表示されている。合計金額表示欄７０１５の下側には注文を確定するための注文ボタン７０１６が表示されている。注文確定画面Ｇ８に表示された注文内容に納得したユーザは注文ボタン７０１６をタッチする。これにより、注文が完了する。
（注文処理）
図１５は、行きつけの系列の店舗に来店したユーザにより飲食品が注文される際の情報提示システムの処理の一例を示すシーケンス図である。
ステップＳ１において情報端末１００はユーザからマッチングアプリの起動指示を受け付けてマッチングアプリを起動し、マップ画面Ｇ４をディスプレイ１０５に表示する。具体的には、マッチングアプリが起動すると、マッチングアプリは認証画面Ｇ１又は認証画面Ｇ２を表示してユーザ認証を行い、ユーザ認証ができた場合、ホーム画面Ｇ３を表示する。このホーム画面Ｇ３においてマップボタン１４０３がタッチされると、マッチングアプリはマップ画面Ｇ４を表示する。
ステップＳ２において、マッチングアプリは、ＧＰＳセンサー１０７が検知した情報端末１００の現在の地点を示す位置情報を取得し、当該地点を含む周辺地域の地図情報である周辺地図情報の取得要請をパブリック情報サーバ５００に送信する。
この取得要請を受信したパブリック情報サーバ５００は、この取得要請に含まれる位置情報から情報端末１００の現在の地点を取得し、その地点を基準に所定範囲の地域の地図情報を周辺地図情報として地図データベースから抽出し、マッチングアプリに送信する。周辺地図情報を受信したマッチングアプリは、周辺地図情報が示す地図を含むマップ画面Ｇ４を表示する（ステップＳ３）。地域を示す所定範囲は、例えば現在の地点から半径１ｋｍ又は２ｋｍの範囲等、今から外食をしようとするユーザが徒歩又は車によって来店することが可能な範囲である。
マップ画面Ｇ４を表示したマッチングアプリは、受信した周辺地図情報が示す地図内に含まれる店舗であって、第１サーバ２００に登録された店舗の店舗情報の取得要請を第１サーバ２００に送信する（ステップＳ４）。
この取得要請を受信した第１サーバ２００はメモリ２０３から該当する地図内に含まれる店舗の店舗情報を抽出し、マッチングアプリに送信する。メモリ２０３には、例えば各店舗の店舗情報を含む店舗データベースが記憶されている。各店舗情報には店舗の店舗ＩＤ、店舗名、系列、位置情報、及び接続情報が含まれている。したがって、第１サーバ２００は、店舗情報の取得要請が示す地図の地域内に含まれる店舗を、店舗データベースに記憶された各店舗の位置情報から特定すればよい。
抽出された店舗情報を受信したマッチングアプリは、その店舗情報をマップ画面Ｇ４の地図上に表示する（ステップＳ５）。これにより、図６のマップ画面Ｇ４に示されるように、ユーザの現在の地点の周辺地域に含まれる店舗がその周辺地域を示す地図上に表示される。
ステップＳ６において、マッチングアプリは、マップ画面Ｇ４に表示された店舗のうちレストランＡ系列の店舗Ａ１を選択するユーザの指示を受け付ける。ここで、店舗Ａ１はユーザが行きつけの店舗である。
ステップＳ７において、マッチングアプリは、店舗Ａ１の個別メニュー情報の取得要請を第１サーバ２００に送信する。この取得要請には店舗Ａ１の店舗ＩＤ、接続情報、及び情報端末１００のユーザＩＤ等が含まれる。
この取得要請を受信した第１サーバ２００は、店舗Ａ１が属するレストランＡ系列の標準メニュー情報の取得要請をレストランＡ系列又は店舗Ａ１の第２サーバ３００に送信する（ステップＳ８）。
この取得要請を受信したレストランＡ系列又は店舗Ａ１の第２サーバ３００は、店舗Ａ１の標準メニュー情報を第１サーバ２００に送信する。これにより、第１サーバ２００は店舗Ａ１の標準メニュー情報を受信する（ステップＳ９）。ここで送信される店舗Ａ１の標準メニュー情報は、レストランＡ系列の各店舗で共通のメニュー情報であってもよいし、レストランＡ系列の各店舗で一部分が異なるメニュー情報であってもよい。
店舗Ａ１の標準メニュー情報を受信した第１サーバ２００は、メモリ２０３に記憶された該当するユーザのレストランＡ系列の各店舗での注文履歴を集計して、店舗Ａ１向けの個別メニュー情報を生成する（ステップＳ１０）。生成された店舗Ａ１向けの個別メニュー情報は第１サーバ２００により情報端末１００（マッチングアプリ）へ送信され、マッチングアプリは、この個別メニュー情報を受信する（ステップＳ１１）。
ステップＳ１１までの処理において、情報端末１００に表示される各種画面は第１サーバ２００の管理者（情報銀行）のスタイルでデザインされたものが使用される。一方、ステップＳ１２からの処理においては、情報端末１００に表示される各種画面はレストランＡ系列のスタイルでデザインされたものが使用される。
尚、ステップＳ１２からの処理において、情報端末１００に表示される各種画面は、レストランＡ系列が用意する素材（料理を説明する文字、料理の写真など）が第１サーバ２００の管理者（情報銀行）のスタイルでレイアウトされた画面であっても良い。このようにすることで、マッチングアプリを利用するユーザに対して統一的なユーザエクスペリエンスを提供することができる。
ステップＳ１２において、マッチングアプリは、受信した店舗Ａ１向けの個別メニュー情報を示す個別メニュー画面を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップＳ１３において、マッチングアプリは、注文された飲食品を示す注文情報を第１サーバ２００に送信する。ここの注文情報を受信した第１サーバ２００は、この注文情報をレストランＡ系列の第２サーバ３００に送信する（ステップＳ１４）。この注文情報を受信した第２サーバ３００は、例えば店舗Ａ１の店舗端末のディスプレイに注文情報を表示する等して、店舗Ａ１のスタッフに調理の開始を通知する（ステップＳ１５）。
ステップＳ１６において、第１サーバ２００は、注文情報をメモリ２０３に記憶することで、該当するユーザの注文履歴を更新する（ステップＳ１６）。
図１５のシーケンス図では、周辺地図情報の取得以外の処理ではマッチングアプリが通信するサーバは第１サーバ２００であるとして説明したが、本開示はこれに限定されない。例えば、マッチングアプリは、店舗情報の取得に関して第１サーバ２００以外の第三のサーバにアクセスしてもよい。
図１６は、初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。
ステップＳ２１～Ｓ２５の処理は図１５のステップＳ１～Ｓ５の処理と同じである。ステップＳ２６において、マッチングアプリは、マップ画面Ｇ４に表示された店舗のうちレストランＢ系列の店舗Ｂ１を選択するユーザの指示を受け付ける。
ステップＳ２７において、マッチングアプリは、店舗Ｂ１の個別メニュー情報の取得要請を第１サーバ２００に送信する。この取得要請には店舗Ｂ１の店舗ＩＤ、接続情報、及び情報端末１００のユーザＩＤ等が含まれる。
この取得要請を受信した第１サーバ２００は、店舗Ｂ１が属するレストランＢ系列の標準メニュー情報の取得要請をレストランＢ系列の第２サーバ３００に送信する（ステップＳ２８）。
この取得要請を受信したレストランＢ系列の第２サーバ３００は、店舗Ｂ１の標準メニュー情報を第１サーバ２００に送信する。これにより、第１サーバ２００はレストランＢ系列の標準メニュー情報を受信する（ステップＳ２９）。ここで送信されるレストランＢ系列の標準メニュー情報は、レストランＢ系列の各店舗で共通のメニュー情報であってもよいし、レストランＢ系列の各店舗で一部分が異なるメニュー情報であってもよい。
レストランＢ系列の標準メニュー情報を受信した第１サーバ２００は、該当するユーザの注文履歴に基づいて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する（ステップＳ３０）。具体的には、第１サーバ２００は、レストランＢ系列での該当するユーザの注文履歴が後述する参照条件Ｃ１を満たさない場合、レストランＢ系列の店舗Ｂ１が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗Ｂ１における個別メニュー情報を生成する。一方、第１サーバ２００は、レストランＢ系列での該当するユーザの注文履歴が参照条件Ｃ１を満たしている場合、レストランＢ系列での該当するユーザの注文履歴を用いて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。ステップＳ３０の処理の詳細は図１７に示すフローチャートを用いて後述する。
生成された店舗Ｂ１の個別メニュー情報は第１サーバ２００により情報端末１００（マッチングアプリ）へ送信され、マッチングアプリは、この個別メニュー情報を受信する（ステップＳ３１）。
ステップＳ３１までの処理において、情報端末１００に表示される各種画面は第１サーバ２００の管理者（情報銀行）のスタイルでデザインされたものが使用される。一方、ステップＳ３２からの処理においては、情報端末１００に表示される各種画面はレストランＢ系列のスタイルでデザインされたものが使用される。
尚、ステップＳ３２からの処理において、情報端末１００に表示される各種画面は、レストランＢ系列が用意する素材（料理を説明する文字、料理の写真など）が第１サーバ２００の管理者（情報銀行）のスタイルでレイアウトされた画面であっても良い。このようにすることで、マッチングアプリを利用するユーザに対して統一的なユーザエクスペリエンスを提供することができる。
ステップＳ３２において、マッチングアプリは、受信した店舗Ｂ１の個別メニュー情報を示す個別メニュー画面Ｇ５，Ｇ６を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップＳ３３～ステップＳ３６の処理は、店舗Ａ１ではなく店舗Ｂ１に対して飲食品の注文が行われること以外は、図１５に示すステップＳ１２～Ｓ１６と同じである。
図１７は、図１６のシーケンス図のステップＳ３０における処理に着目したときの情報提供システムの処理の一例を示す図である。
ステップＳ１０１において、第１サーバ２００は、指定されたレストラン系列の標準メニュー情報を第２サーバ３００から取得する。この処理は、図１６のステップＳ２９に相当する。指定されたレストラン系列とは、マップ画面Ｇ４においてユーザが選択した店舗が属しているレストラン系列である。
図１３は、標準メニュー情報Ｄ１のデータ構成の一例を示す図である。標準メニュー情報Ｄ１には、１以上の飲食品のそれぞれについて、料理名、価格、及び期間限定が対応付けて記憶されている。飲食品名は「ブレンドコーヒー」、「アメリカンコーヒー」等、提供される飲食品の名称を示す。価格は各飲食品の価格を示す。期間限定は、期間限定で提供される飲食品であるか否かを示す。ＹＥＳは期間限定の飲食品であることを示し、ＮＯは年間を通じて提供される飲食品であることを示す。例えば、「スペシャルモンブランホワイトカフェラテ」は特定の期間に提供される飲食品であるため、期間限定が「ＹＥＳ」になっている。
図１７に参照を戻す。ステップＳ１０２において、第１サーバ２００は、メモリ２０３に記憶された該当するユーザの注文履歴の中から、指定されたレストラン系列における該当するユーザの注文履歴を検索する。
ステップＳ１０３において、第１サーバ２００は、検索にヒットした注文履歴が参照条件Ｃ１を満たすか否かを判定する。参照条件Ｃ１は、第１サーバ２００の運営会社、マッチングアプリの開発会社、マッチングアプリの配布会社、サービス提供会社（この場合、レストランＢ系列）、又はユーザが設定した期間において、下記の（ａ）～（ｄ）のうち少なくとも１つの条件を含むようにしてもよい。設定された期間とは、例えば、現在から過去３年、２年、１年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。
（ａ）指定されたレストラン系列における飲食品の注文回数が閾値Ｔａ以上
（ｂ）指定されたレストラン系列で注文した日の回数（来店回数）が閾値Ｔｂ以上
（ｃ）指定されたレストラン系列で注文した飲食品の個数（注文皿数）が閾値Ｔｃ以上
（ｄ）指定されたレストラン系列で注文した飲食品の合計金額（注文額）が閾値Ｔｄ以上
閾値Ｔａ～閾値Ｔｄは、例えば、それぞれ、ユーザが指定されたレストラン系列に行きつけているとみなせる予め定められた値が採用される。或いは、閾値Ｔａ～閾値Ｔｄはユーザが指定されたレストラン系列に実質的に初めて来店したとみなせる予め定められた値が採用されてもよい。
設定された期間内の条件を設けたのは、指定されたレストラン系列にユーザが久しく来店しておらず、その間にユーザの嗜好が変化する可能性や、店舗がメニューを更新する可能性を考慮したためである。例えば、ユーザの嗜好は健康意識が高くなると変化する可能性がある。
ヒットした注文履歴が参照条件Ｃ１を満たす場合（ステップＳ１０３でＹＥＳ）、第１サーバ２００は、ヒットした注文履歴を優先指標として用いて、指定された店舗での該当するユーザの個別メニュー情報を生成する（ステップＳ１０４）。指定された店舗とは、マップ画面Ｇ４においてユーザが選択した店舗である。例えば、指定された店舗が店舗Ｂ１であり、ユーザが店舗Ｂ１に行きつけている、或いは、ユーザがレストランＢ系列のいずれかの店舗に行きつけているような場合、ステップＳ１０３でＹＥＳと判定される。この場合、第１サーバ２００は、例えば、ヒットした注文履歴の注文回数から、より多く注文された飲食品の優先順位を高くするように決定してもよい。また、注文時のユーザの周辺状況も加味して、注文される可能性が高い順に、飲食品を順位付けするようにしてもよい。例えば、今回の注文時の周辺状況（曜日、季節、気温、湿度、天気、場所、利用店舗、ユーザの生体情報、ユーザの活動量の内の少なくとも１つ）と類似の周辺状況だった時の注文回数から、個別メニューでの飲食品の訴求優先順位を決定するようにしてもよい。これによって、単に注文回数が最も多いという理由だけで、常にどのような状況でも特定の飲食品が推薦されるということを回避できる利点がある。そして、第１サーバ２００は、上位の飲食品ほど注文し易くなるようにレストランＢ系列の標準メニュー情報のメニュー内容を並び替え、個別メニュー情報を生成すればよい。この個別メニュー情報は情報端末１００に送信される。
図１２は、注文履歴を記憶する注文履歴データベースＤ２のデータ構成の一例を示す図である。図１２では、店舗を指定したユーザの注文履歴データベースＤ２が示されている。注文履歴データベースＤ２の各レコードには、例えば該当するユーザの店舗への１回の来店に対する注文履歴が記憶されている。注文履歴データベースＤ２には、注文した日時情報、店舗ＩＤ、店舗名、及び注文した飲食品名が対応付けて記憶されている。この注文履歴データベースＤ２は、後述する図１８に示す「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿１．ｊｓｏｎ」ファイル～「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿Ｎ．ｊｓｏｎ」ファイルに暗号化されたうえで分散管理されている。
注文した日時情報は、ユーザが飲食品を注文した日時を示している。店舗ＩＤはユーザが来店した店舗の識別情報である。店舗名はユーザが来店した店舗の名称である。ここでは、店舗名にはその店舗が属しているレストラン系列の名称が含まれている。注文した飲食品名は、ユーザが注文した飲食品の名称である。例えば、１行目のレコードには、２０２０年１月３日１３時１５分４５秒にレストランＡ系列の門真店でユーザがカプチーノとアイスクリームとを注文した注文履歴が記憶されている。
なお、ここでは上記の周辺状況については図示していないが、周辺状況の情報もこの注文履歴に一緒に記憶されるようにしてもよい。曜日は注文した日の曜日、季節は注文した日の季節、気温は注文した時のユーザ近辺の気温、湿度は注文した時のユーザ近辺の湿度、天気は注文した時のユーザ近辺の天気（晴れ、雨、くもりなど）、場所は注文をした場所を示す情報（住所、ＧＰＳ情報など）、利用店舗は注文をした店舗の特定情報、ユーザの生体情報は注文をした時のユーザの生体情報（血圧、心拍数など）、ユーザの活動量は注文をした日のユーザの活動量情報（歩数、消費カロリーなど）をそれぞれ示している。
指定されたレストラン系列がレストランＢ系列であるとすると、第１サーバ２００は、レストランＢ系列の標準メニュー情報Ｄ１に含まれる各飲食品の注文回数を注文履歴データベースＤ２を参照して集計し、集計結果から当該標準メニュー情報に含まれる各飲食品を順位付けして個別メニュー情報を生成すればよい。
ステップＳ１０５において、情報端末１００は、個別メニュー情報を示す個別メニュー画面を表示する。ステップＳ１０６において、情報端末は、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップＳ１０３において、ヒットした注文履歴が参照条件Ｃ１を満たしていない場合（ステップＳ１０３でＮＯ）、第１サーバ２００は、該当するユーザの注文履歴が参照条件Ｃ２を満たすか否かを判定する（ステップＳ１０７）。
参照条件Ｃ２は、第１サーバ２００の運営会社、マッチングアプリの開発会社、マッチングアプリの配布会社、サービス提供会社（この場合、レストランＢ系列）、又はユーザが設定した期間において、下記（ｅ）、（ｆ）、（ｇ）のうち少なくとも１つの条件を含むようにしてもよい。設定された期間は、３年、２年、１年等の有限期間であってもよいし、無制限の期間であってもよい。
（ｅ）カウント値の合計値が閾値Ｔｅ以上
（ｆ）カウント値が閾値Ｔｆ以上の飲食品の数が所定個数以上
（ｇ）注文金額の合計金額が閾値Ｔｇ以上
カウント値とは、指定されたレストラン系列の標準メニュー情報に含まれる各飲食品について、注文履歴データベースＤ２の「注文した飲食品名」のフィールドにおける出現回数である。カウント値は、検索する文字列が検索対象の文字列に含まれる回数を計測するというようなテキストマッチングにより計測される。例えば、設定された期間（例えば、３年間）において、標準メニュー情報に含まれる「カプチーノ」という文字列が注文履歴データベースＤ２の「注文した飲食品名」のフィールドに２９回出現した場合、「カプチーノ」のカウント値は２９となる。また、標準メニュー情報に、例えば、「担々麺」及び「餃子」が別々にある場合において、注文履歴データベースＤ２の「注文した飲食品名」のフィールドに「担々麺餃子セット」がある場合、「担々麺」及び「餃子」のそれぞれが１カウントアップされるようにしてもよい。
カウント値の合計値は、該当するユーザにおいて、各飲食品のカウント値の合計値である。図１４の例では、「ブレンドコーヒー」から「スペシャルモンブランホワイトカフェラテ」までの例示された範囲だけで、該当するユーザの各飲食品のカウント値の合計値は、２＋２９＋１１＋３＝４５となる。
また、標準メニューに含まれる各飲食品について、名称を示す文字列が一致又は類似する飲食品が注文履歴データベースＤ２の「注文した飲食品名」のフィールドに含まれていれば、出現回数がカウントアップされる。例えば、ブレンドコーヒーとオリジナルブレンドコーヒーとは一方の文字列が他方の文字列に含まれるため、類似すると判定される。カウント値の合計値とは、各飲食品のカウント値を合計した値である。
カウント値が閾値Ｔｆ以上の飲食品とは、注文履歴データベースＤ２の例において、閾値Ｔｆが「１０」とすると、「カプチーノ」及び「カフェモカ」が該当する。この場合、条件（ｆ）の所定個数が「２」であるとすると、該当するユーザの注文履歴は条件（ｆ）を満たすと判定される。
注文履歴が参照条件Ｃ２を満たす場合（ステップＳ１０７でＹＥＳ）、第１サーバ２００は該当するユーザの注文履歴を用いて、指定された店舗における個別メニュー情報を生成する（ステップＳ１０８）。この場合、第１サーバ２００は、カウント値、すなわち注文回数が多い飲食品ほど注文し易くなるように個別メニュー情報を生成すればよい。ステップＳ１０８が終了すると、処理はステップＳ１０５に進められ、ステップＳ１０５以降の処理が実施される。
注文金額の合計金額とは、個々の飲食品の価格に注文回数を掛けて、それを全ての飲食品に対して合計した金額のことである。図１３と図１４の例示された範囲では、注文金額の合計金額は、２＊３５０＋２９＊３５０＋１１＊３５０＋３＊１５０＝１５１５０円と計算される。
図１４は、あるユーザについて、標準メニュー情報に含まれる各飲食品に対して注文回数を纏めた表である。この表において、「全ての注文回数」は指定されたレストラン系列を含む全てのレストラン系列における各飲食品の注文回数を示す。「指定されたレストラン系列での注文回数」はユーザがマップ画面Ｇ４にて選択した店舗が属するレストラン系列における当該ユーザの各飲食品の注文回数を示す。
例えば、指定されたレストラン系列での注文回数は全て０であるため、該当するユーザはこのレストラン系列を過去に来店していないことが分かる。そのため、このレストラン系列の注文履歴からユーザの嗜好に合った個別メニュー情報を生成することはできない。しかしながら、「全ての注文回数」には、「カプチーノ」、及び「カフェモカ」の注文回数が多く、ユーザの嗜好性が見えてくる。
そこで、第１サーバ２００は、「全ての注文回数」を参照することで、個別メニュー情報を生成する。これにより、第１サーバ２００は、ユーザの嗜好に合った個別メニュー情報を生成できる。図１４の例では、「カプチーノ」及び「カフェモカ」における「全ての注文回数」が他の飲食品より多い。そのため、これらの飲食品は指定されたレストラン系列の利用が初めてであっても、その個別メニュー画面の初期画面に表示され、注文がし易いように表示されることになる。また、「アメリカンコーヒー」のような「全ての注文回数」が少ない飲食品は、個別メニュー画面の初期画面から省かれてもよい。或いは、個別メニュー画面の初期画面において、「全ての注文回数」が多い例えば「カプチーノ」及び「カフェモカ」のような飲食品のタイルオブジェクト７０１が表示可能である場合、アメリカンコーヒーが表示されてもよい。この場合、アメリカンコーヒーのような「全ての注文回数」が少ない飲食品のタイルオブジェクト７０１は、「カプチーノ」及び「カフェモカ」よりも小さな面積で表示されてもよい。
なお、注文履歴が参照条件Ｃ２を満たしている場合、図１４に示す「全ての注文回数」から、指定されたレストラン系列の注文回数を除外して、各飲食品のカウント値が算出されてもよい。または、注文履歴が参照条件Ｃ２を満たしている場合、図１４に示す「全ての注文回数」の中で、指定されたレストラン系列での注文回数とそれ以外での注文回数とに異なる重みづけをして（例えば、指定されたレストラン系列での注文回数をそれ以外での注文回数より重要視した重みづけをして）、各飲食品のカウント値が算出されてもよい。或いは、注文履歴が参照条件Ｃ２を満たしている場合、図１４に示す「全ての注文回数」において指定されたレストラン系列以外の特定の１又は複数のレストラン系列の「全ての注文回数」を用いて各飲食品のカウント値が算出されてもよい。特定の１又は複数のレストラン系列とは、ユーザが行きつけのレストラン系列である。
図１７に参照を戻す。ステップＳ１０７において、該当するユーザの注文履歴が参照条件Ｃ２を満たしていない場合（ステップＳ１０７でＮＯ）、第１サーバ２００は、マップ画面Ｇ４にてユーザが選択した店舗が属するレストラン系列の標準メニュー画面を情報端末１００に表示させる（ステップＳ１０９）。
ステップＳ１０７の分岐処理を設けることにより、例えば注文履歴データベースＤ２に記憶されたユーザの注文履歴が少なく、この注文履歴データベースＤ２からユーザの嗜好をくみ取ることができないケースにおいて、個別メニュー情報が生成されることを防止できる。ステップＳ１１０において、情報端末１００は、標準メニュー画面を閲覧したユーザから注文する飲食品を選択する指示を受け付ける。
（個別メニューから注文をする際の情報処理の実装例）
次に、個別メニュー画面から飲食品を注文する場合の情報処理の実装例について説明する。情報通信のインターフェース及び取り扱うデータ構造がレストラン系列又は店舗に固有である場合、情報提供システムで取り扱われる各種データが、例えば、レストランＡ系列の店舗Ａ１では利用可能だが、レストランＢ系列では使用できないといった事態、又はレストランＡ系列の別店舗及びレストランＢ系列の両方で使用できないという事態が生じ得る。このような事態を回避するために、多くのユーザが多くのレストランで個別メニューを用いた飲食品の注文を実施するめの汎用的なソリューションについて、以下説明する。
図１８は、本実施の形態における情報提供システムの具体的な実装形態の一例を示す図である。情報端末１００のメモリ１０２には、マッチングアプリの実行に必要となるファイルの格納場所である「ｍａｔｃｈｉｎｇ＿ａｐｐ」ディレクトリがある。「ｍａｔｃｈｉｎｇ＿ａｐｐ」ディレクトリの下には、「ａｃｃｏｕｎｔ」ディレクトリ、「ｍａｉｎ」ディレクトリ、及び「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリがある。「ａｃｃｏｕｎｔ」ディレクトリにはユーザのアカウント及び／又はユーザ認証に必要な情報が格納される。「ｍａｉｎ」ディレクトリには、マッチングアプリがホーム画面の描画などの基本機能を実現するために必要な情報が格納される。「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリには、マッチングに必要な情報が一時的に格納される。
「ａｃｃｏｕｎｔ」ディレクトリには、アカウント及び／又はユーザ認証に必要な情報を記述した「ｕｓｅｒ＿ａｃｃｏｕｎｔ．ｘｍｌ」ファイルが格納される。「ｕｓｅｒ＿ａｃｃｏｕｎｔ．ｘｍｌ」ファイルには、例えばユーザを特定するための情報として、ユニークなアカウント名（例えば、ユーザが指定するユーザＩＤ）とその認証情報（例えば、パスワード、指紋の特徴量、及び／又は顔の特徴量）とが暗号化されて記録されている。
アカウント名としてはユーザが指定するユーザＩＤに限定されず、マッチングアプリを利用するユーザを個別に識別可能な情報が採用されればよい。例えば、マッチングアプリのプログラムに埋め込まれた、又はマッチングアプリに付随して配布された、マッチングアプリの個体別にユニークなシリアルコードが採用されてもよい。個体別にユニークなシリアルコードとは、マッチングアプリをインストールする情報端末１００毎にユニークに付与されたシリアルコードである。或いは、アカウント名としては、マッチングアプリの初回起動時又は初回登録時に、マッチングアプリが乱数に基づいて生成したユニークなアカウント名が採用されてもよい。この場合、マッチングアプリは、例えば、既に登録済みアカウント名と重複していないことを第１サーバ２００に確認することで、アカウント名を自動生成すればよい。
このようにアカウント名として人が見て無意味な文字列情報が設定されることにより、秘匿性がより高められた個人情報の通信が可能となる。
「ｍａｉｎ」ディレクトリには、マッチングアプリの基本機能を実現するために必要なコンテンツ情報を記述した「ｍａｉｎ．ｈｔｍｌ」ファイルと、その画面表示のスタイル（例えば、ＵＩデザイン）を記述した「ｍａｉｎ．ｃｓｓ」ファイルとが格納されている。
レストランＢ系列の第２サーバ３００には、返信するコンテンツ情報を記述した「ＲｅｓＢ．ｈｔｍｌ」ファイルと、そのコンテンツ情報の画面表示のスタイル（例えば、ＵＩデザイン）を記述した「ＲｅｓＢ．ｃｓｓ」ファイルとがある。例えば図１３に示す標準メニュー情報Ｄ１は「ＲｅｓＢ．ｈｔｍｌ」ファイルに含まれてもよい。または、標準メニュー情報Ｄ１は、「ＲｅｓＢ．ｈｔｍｌ」ファイルにて参照される外部ファイルに格納されてもよい。
第１サーバ２００には、このユーザの多種多様で膨大な個人情報が分散暗号化されて蓄積されている。例えば、本開示で利用したユーザの注文履歴データベースＤ２は、「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿１．ｊｓｏｎ」ファイル、「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿２．ｊｓｏｎ」ファイル、．．．、「ｕｓｅｒＩＤ＿ＦｏｏｄＨｉｓｔｏｒｙ＿Ｎ．ｊｓｏｎ」ファイルというＮ個のＪＳＯＮフォーマットのファイルとして、第１サーバ２００内の物理的に異なるストレージ装置に保管されていてもよい。Ｎ個のファイルにおいて、ファイル名の先頭部分の「ｕｓｅｒＩＤ」はユーザを特定するための識別情報であり、続く「ＦｏｏｄＨｉｓｔｏｒｙ」は図１２で説明した注文履歴データベースＤ２を特定するための識別情報であり、最後の数字は分断したファイルの識別番号である。
第１サーバ２００は、ユーザの注文履歴のリクエストを適切なパーミッション（例えば、アクセス許可情報）と共に受信できれば、これらＮ個のファイルから正しくデータを復元し、所定の記述フォーマット（．ｊｓｏｎ）に変換して暗号化し、情報端末１００へ返信できる。
以下、図１９のフローチャートに従いながら、マッチングアプリがＨＴＭＬを用いて画面制御を行う場合のファイルの取り扱いについて説明する。図１９は、マッチングアプリが起動してから個別メニュー画像を表示するまでのファイルに対するマッチングアプリの処理の一例を示すフローチャートである。
ステップＳ２０１において、マッチングアプリが起動し、ホーム画面を描画する。マッチングアプリは、起動直後に「ｍａｉｎ」ディレクトリにある「ｍａｉｎ．ｈｔｍｌ」ファイルと「ｍａｉｎ．ｃｓｓ」ファイルとを用いてホーム画面を描画する。これにより、図５に示すホーム画面Ｇ３が描画される。
ステップＳ２０２において、マッチングアプリは、ホーム画面Ｇ３を閲覧するユーザからマップ画面Ｇ４を表示させる指示を受け付ける。
ステップＳ２０３において、マッチングアプリは、パブリック情報サーバ５００に対して現在の地点の周辺地図情報の取得要請を行い、周辺地図情報を示すマップ画面Ｇ４を表示する。
ステップＳ２０４において、マッチングアプリは、第１サーバ２００に対して周辺地図情報が示す地域内の店舗情報の取得要請を行い、店舗情報をマップ画面Ｇ４に表示する。これにより、店舗を示すアイコン３２１０等が表示される。
ステップＳ２０５において、マッチングアプリは、ユーザからレストランＢ系列の店舗Ｂ１を選択する指示を受け付ける。
ステップＳ２０６において、マッチングアプリは、第１サーバ２００に対してレストランＢ系列の個別メニュー情報の取得要請を行う。
ステップＳ２０７において、第１サーバ２００は、レストランＢ系列の第２サーバ３００に対して、レストランＢ系列の標準メニュー情報（ＲｅｓＢ．ｈｔｍｌ、ＲｅｓＢ．ｃｓｓ）の取得要請を行う。
ステップＳ２０８において、第１サーバ２００は、該当するユーザの注文履歴からレストランＢ系列の個別メニュー情報を生成する。生成された個別メニュー情報は、「Ｃｕｓｔｏｍ＿ＲｅｓＢ．ｈｔｍｌ」ファイルとして、新規に「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリの下に記録される。
ステップＳ２０９において、第１サーバ２００は、マッチングアプリに対してレストランＢ系列の個別メニュー情報を送信する。
このようにＨＴＭＬ／ＣＳＳファイルを用いて各種画面が描画されている。そのため、単一のマッチングアプリから、不特定多数の事業者が提供する商品又はサービスのうち、ユーザの膨大且つ多様な個人情報と適合する商品又はサービスを提示する場合において、当該事業者が期待する情報を、当該事業者が期待するスタイル（例えば、ＵＩデザイン）で表示させることができる。
個別メニューからの飲食品の注文が終了したユーザによって、表示画面がマッチングアプリのホーム画面に戻された時、又は個別メニューからの飲食品の注文が終了してから所定時間が経過した時、「ｍａｔｃｈｉｎｇ＿ｔｅｍｐ」ディレクトリに一時保管されていたファイルは安全のため全て消去されてもよい。
（実施の形態２）
実施の形態１は、個別メニュー情報の生成主体が第１サーバ２００であった。実施の形態２は、個別メニュー情報の生成主体が情報端末１００であることを特徴とする。
なお、実施の形態２において、実施の形態１と同一の構成要素については同一の符号を付し、説明を省く。
まず、図２を参照して、実施の形態２の構成について説明する。実施の形態２では、個別メニュー情報が情報端末１００で生成されるため、以下、情報端末１００の構成を中心に説明する。
情報端末１００のＧＰＳセンサー１０７は情報端末１００の位置情報を取得する。通信部１０１は、取得した位置情報をパブリック情報サーバ５００（第３サーバ）に送信する。パブリック情報サーバ５００は、受信した位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報（店舗情報）を取得する。
ディスプレイ１０５は、店舗情報を含むマップ画面Ｇ４を表示する。
情報端末１００の操作部１０６（入力デバイスの一例）は、マップ画面Ｇ４を通じて、第２レストランを示す店舗ＩＤを選択する操作を受け付ける。
演算部１０４は、通信部１０１を用いて店舗ＩＤが示す第２レストランに関連する第２サーバ３００から、第２レストランのメニュー情報（標準メニュー情報）を取得する。
情報端末１００の演算部１０４は、通信部１０１を用いて、ユーザのユーザＩＤに対応する嗜好情報を第１サーバ２００から取得する。
演算部１０４は、嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にてメニュー内容を配列する。
演算部１０４は、配列されたメニュー内容のメニュー情報（個別メニュー情報）をディスプレイ１０５に表示する。
演算部１０４は、第２レストランを選択したユーザによる第２レストランでの注文履歴がない場合、嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランが属する系列を初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
一方、演算部１０４は、第２レストランを選択したユーザによる第２レストランでの注文履歴がある場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランを過去に利用したことがある場合、第２レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
なお、演算部１０４は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量に満たない場合、当該ユーザのユーザＩＤに対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第２レストランでの注文履歴が所定量に満たない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所定量は、ユーザが第２レストランに行きつけているとみなされる予め定められた値、又は第２レストランに初めて来店したとみなせる予め定められた値を有する。
一方、演算部１０４は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量以上である場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第２レストランでの注文履歴が所定量以上の場合、ユーザは、第２レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
さらに、演算部１０４は、第２レストランを選択したユーザによる第２レストランでの直近の注文履歴が所定期間より前である場合、当該ユーザのユーザＩＤに対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第２レストランに久しく来店していない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所期間は、例えば、現在から過去３年、２年、１年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。
さらに、演算部１０４は、該当するユーザの設定期間内での第２レストランでの注文回数が一定回数以下である場合、該当するユーザのユーザＩＤに対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、設定期間内の第２レストランにおける注文回数が一定回数以下の場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。設定期間は、例えば、現在から過去３年、２年、１年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。一定回数は、ユーザが第２レストランに行きつけているとみなされる予め定められた値、又は第２レストランに実質的に初めて来店したとみなせる予め定められた値を有する。
図２０は、実施の形態２において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。図２０において図１６と同一の処理については同一の符号を付し、説明を省略する。ステップＳ２１～Ｓ２６は、図１６と同じである。
ステップＳ２６に続くステップＳ３０１において、情報端末１００（マッチングアプリ）は、店舗Ｂ１の個別メニュー情報の取得要請を第２サーバ３００に送信する。この取得要請には店舗Ｂ１の店舗ＩＤ及び情報端末１００のユーザＩＤ等が含まれる。
この取得要請を受信したレストランＢ系列の第２サーバ３００は、店舗Ｂ１の標準メニュー情報を情報端末１００に送信する。これにより、情報端末１００はレストランＢ系列の標準メニュー情報を受信する（ステップＳ３０２）。ここで送信されるレストランＢ系列の標準メニュー情報は、レストランＢ系列の各店舗で共通のメニュー情報であってもよいし、レストランＢ系列の各店舗で一部分が異なるメニュー情報であってもよい。
ステップＳ３０３において、レストランＢ系列の標準メニュー情報を受信した情報端末１００は、該当するユーザの注文履歴（嗜好情報の一例）の取得要請を第１サーバ２００に送信する。この取得要請を受信した第１サーバ２００は、該当するユーザの注文履歴をメモリ２０３から読み出し、情報端末１００に送信する。ここで、第１サーバ２００は、ユーザＩＤが示すユーザが許諾ユーザであるか否か判断しても良い。そして、第１サーバ２００は、許諾ユーザと判断した場合、メモリ２０３から該当するユーザの注文履歴を読み出して、情報端末１００に送信すればよい。一方、第１サーバ２００は、ユーザＩＤが示すユーザが許諾ユーザでないと判定した場合、個人情報のアクセスが不可能であることを示す情報を情報端末１００に送信すればよい。
なお、第１サーバ２００は、許諾ユーザではないと判定した場合、個人情報の読み出しを許可するか否かを確認するメッセージを情報端末１００に送信してもよい。このメッセージに応じて情報端末１００から許可する旨の情報が送信された場合、第１サーバ２００は、該当するユーザの注文履歴をメモリ２０３から読み出し、情報端末１００に送信すればよい。
ステップＳ３０４において、情報端末１００は、注文履歴を受信する。
ステップＳ３０５において、情報端末１００は、該当するユーザの注文履歴に基づいて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。
具体的には、第１サーバ２００は、レストランＢ系列での該当するユーザの注文履歴が上述の参照条件Ｃ１を満たさない場合（例えば該当するユーザがレストランＢ系列に初めて来店したとみなせる場合）、レストランＢ系列の店舗Ｂ１が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗Ｂ１における個別メニュー情報を生成する。
一方、第１サーバ２００は、レストランＢ系列での該当するユーザの注文履歴が参照条件Ｃ１を満たしている場合（例えば該当するユーザがレストランＢ系列に行きつけているとみなせる場合）、レストランＢ系列での該当するユーザの注文履歴を用いて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。この処理の詳細は、図１７に示すフローチャートを用いて上述した。
ステップＳ３０５までの処理において、情報端末１００に表示される各種画面は第１サーバ２００の管理者（情報銀行）のスタイルでデザインされたものが使用される。一方、ステップＳ３０６からの処理においては、情報端末１００に表示される各種画面はレストランＢ系列のスタイルでデザインされたものが使用される。
ステップＳ３０６において、情報端末１００は、受信した店舗Ｂ１の個別メニュー情報を示す個別メニュー画面Ｇ５，Ｇ６を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップＳ３０７において、情報端末１００は、注文された飲食品を示す注文情報を第２サーバ３００に送信する。この注文情報を受信した第２サーバ３００は、例えば店舗Ｂ１の店舗端末のディスプレイに注文情報を表示する等して、店舗Ｂ１のスタッフに調理の開始を通知する（ステップＳ３６）。
ステップＳ３０８において、情報端末１００は、注文情報をさらに第１サーバ２００に送信する。
注文情報を受信した第１サーバ２００は、注文情報をメモリ２０３に記憶することで、該当するユーザの注文履歴を更新する（ステップＳ３５）。
このように、実施の形態２によれば、情報端末１００が個別メニュー情報を生成する場合であっても、ユーザの許諾がない事業者に対して嗜好情報が渡らないようにしながらも、ユーザが初めて利用する第２レストランにおいて、ユーザの嗜好情報が考慮されたメニュー情報を表示できる。
（変形例）
上記の説明は一例に過ぎず、本開示は当該技術者による様々な応用が適用されてもよい。以下の変形例は後述の実施の形態３～６にも適用可能である。
（１）第１サーバ２００は、ユーザがマップ画面Ｇ４から選択したレストランＢ系列の店舗Ｂ１に対する注文情報を取得した場合、情報端末１００の現在の地点をモニタし、情報端末１００と店舗Ｂ１との距離が一定距離以下になった場合、注文情報をレストランＢ系列の第２サーバ３００に送信してもよい。これにより、店舗Ｂ１はユーザが来店するタイミングに飲食品を提供することが可能となる。
（２）上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されても良い。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されても良い。
（３）図１３の標準メニュー情報Ｄ１に示される期間限定の飲食品については、カウント値は算出されなくてもよい。すなわち、標準メニュー情報において、「期間限定」がＮＯの飲食品についてのみカウント値を算出し、その結果に基づいて個別メニュー情報が生成されてもよい。
（４）本開示では、過去に注文をしたことがない、または注文の回数が少ない第２レストラン系列の店での個別メニュー情報の作成のために、過去に注文を行ったことがある第１レストラン系列の店における注文履歴などの個人情報と、第２レストラン系列の店で提供している飲食品の名称と第１レストラン系列の店で提供している飲食品の名称との比較結果を利用する場合を例に挙げて説明した。しかしながら、第１サーバ２００が個別メニュー情報の作成のために個人情報と組み合わせて利用する情報は、上記の例に限られない。
例えば、第１サーバ２００は、第１レストラン系列の店と第２レストラン系列の店の両方で注文したことがある複数のユーザの購入履歴などを集めたビッグデータから推測される統計情報を用いて、個別メニュー情報を生成してもよい。この場合、第１サーバ２００は、例えば、サービスを利用中のユーザの個人情報から、当該ユーザが第１レストラン系列の店で飲食品Ａの注文頻度が高いと判定された場合に、ビッグデータの分析で得られた「第１レストラン系列の店で飲食品Ａを注文するユーザは、第２レストラン系列の店で飲食品Ｘを注文する頻度が高い」という統計情報に基づいて、飲食品Ｘの表示順序を上位にするなど、飲食品Ｘが優先的に表示される個別メニュー情報を生成する。
なお、ここではビッグデータを分析して得られた情報を統計情報と呼んでいるが、名称はこれに限定されない。例えば、第１レストラン系列の店で提供される飲食品と、第２レストラン系列の店で提供される飲食品との相関関係を示す相関関係情報と呼んでもよいし、単にビッグデータを用いて生成された情報などと呼んでもよい。また、ビッグデータとして用いられる他のユーザから取得された情報は、例えば、ユーザを特定できない状態の匿名情報に変換してから分析などに用いられてもよい。また、第１サーバ２００は、上記の統計情報の生成する際に、個別メニューの生成に用いられるサービスを利用中のユーザに対応付けられた個人情報を匿名化して用いてもよい。
（５）本開示では、第１サーバ２００が、ユーザの購買履歴などから推定されたユーザの嗜好情報に応じた順序で飲食品を配列した個別メニュー情報を生成する例を挙げて説明した。以下では、第１サーバ２００が、端末機器において個別メニューとして表示される飲食品の順序を、個別メニュー情報を介して制御または指定する方法について、いくつか例を挙げて説明する。すなわち、第１サーバ２００が、第１レストランにて注文した注文履歴を含むユーザの嗜好情報及び第２レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第２レストランのメニュー情報に含まれるメニュー内容を端末機器の表示画面において配列するための個別メニュー情報を生成し、前記個別メニュー情報を前記端末機器に送信し、前記端末機器の前記表示画面において前記順序にて配列されたメニュー内容のメニュー情報を表示させる、情報提供方法について、いくつか例を挙げて説明する。ただし、上記実施の形態において適用可能な、第１サーバ２００が個別メニューとして表示される飲食品の順序を制御または指定する方法は、以下の例に限定されるものではない。すなわち、第１サーバ２００が、注文履歴などの個人情報から推定された嗜好情報に応じて個別メニューとして表示される飲食品の順序を変更することができる方法であれば、どのような方法を用いてもよい。
第１の例では、第１サーバ２００は、個別メニュー情報を生成する際に、メニュー内容である各飲食品を表示する順序で個別メニュー情報に格納する。
第２の例では、第１サーバ２００は、個別メニュー情報を生成する際に、個別メニューとして表示する飲食品ごとに、当該飲食品の画面上での表示位置を直接指定する。
第３の例では、第１サーバ２００は、個別メニューとして表示する飲食品ごとに、当該飲食品の表示順序を対応付けて個別メニュー情報に格納しておく。この場合、個別メニュー情報を受信した端末機器側のアプリ又はブラウザは、例えば、個別メニューを表示する領域の大きさ又はユーザによって指定されたフォントの表示サイズなどに応じて表示する飲食品の数と、各表示順序に対応する飲食品の表示サイズと、各表示順序に対応する飲食品の表示位置などを所定の表示画面生成ルールに基づいて決定し、個別メニュー情報に含まれる表示順序に従って各飲食品を示すオブジェクトを配置して個別メニューの表示画面を生成すればよい。
第４の例では、第１サーバ２００は、個別メニュー情報に飲食品の表示順序を直接格納するのではなく、ユーザの個人情報に基づいて生成され、且つ飲食品の表示順序を決定するために利用可能な一または複数のパラメータを飲食品ごとに個別メニュー情報に格納してもよい。この場合、個別メニュー情報を受信した端末機器側のアプリ又はブラウザは、上記の一または複数のパラメータから、所定の表示順序導出ルール又はユーザが複数の候補の中から指定した表示順序導出ルールに従って、飲食品の表示順序を導出する。本構成によると、生成された個別メニュー情報に従って端末機器側のアプリ又はブラウザが単純に個別メニューの表示画面を表示するのではなく、ユーザが利用する端末機器の種類又はユーザによる設定に従って、個別メニューの表示方法又は表示する飲食品の表示順序を調整することが可能になるため、より柔軟なサービスの提供を促進することができる。
（６）本開示では、マッチングアプリの画面表示でスタイルを変更する例として、例えば拡張子が「．ｃｓｓ」などであるＵＩデザインを規定したファイルを複数準備して、表示に用いるＵＩデザインを規定したファイルを切り替えることでスタイルを変更する態様を例に挙げて説明した。しかしながら、スタイルの変更は表示に用いるＵＩデザインを規定したファイルを切り替える態様以外の方法で実現されてもよい。例えば、スタイルの変更は、マッチングアプリ内の表示においてレストランＡ系列、レストランＢ系列がそれぞれ独自にメニュー画面に用いる文字のフォントやサイズ、背景および文字の色、ロゴ、メニュー画像、ボタンのデザイン、メニューの配置、メニューの表示サイズ、並びに料理の選択や注文の確定などを行うためのＵＩなどのいずれか一つまたは複数の組み合わせを独自に設定することで実現されてもよい。上述した、メニュー画面に用いる文字のフォントやサイズ、背景および文字の色、ロゴ、メニュー画像、ボタンのデザイン、メニューの配置、メニューの表示サイズ、並びに料理の選択や注文の確定などを行うためのＵＩなどは、例えばレストランＡ系列、レストランＢ系列などのマッチングアプリを利用してサービスを提供する各事業者が提供しているＨＴＭＬファイルで設定することができる。このとき、マッチングアプリの個別メニュー表示画面において、ＣＳＳファイルはマッチングアプリが指定したものを用いるが、個別メニューの表示に提供される画面領域に表示するＨＴＭＬファイルはサービスを提供する事業者が提供するファイルを利用する。これにより、マッチングアプリのウィンドウやフレームのデザインはマッチングアプリの他の表示画面と共通となり、個別メニューが表示される画面領域のデザインはサービスを提供する事業者毎に設定することが可能となる。その結果、ユーザは注文を行おうとするサービスの提供事業者がレストランＡ系列であるのかレストランＢ系列であるのかを容易に判別できるようになる。さらに、個別メニュー画面のスタイルはサービス提供事業者が設定できるにもかかわらず、管理者（情報銀行）が管理する異なるレストラン系列での注文履歴を含む嗜好情報に基づいて、表示するメニューの位置や順番を変更することが可能となり、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
（７）本開示では、マッチングアプリが系列の異なるレストランでの注文履歴を含む嗜好情報を用いると説明したが、系列が異なるレストランは複数のチェーンストアを有するレストランである必要はない。例えば、マッチングアプリが利用する注文履歴は、複数のチェーンストアを有さない１店舗だけのレストランの注文履歴であってもよい。すなわち、本開示によると、異なるメニューを提供する複数のレストラン間で、他のレストランにおける注文履歴を含む嗜好情報に基づいて、表示するメニューの位置や順番を変更することが可能となり、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
以上の（１）～（７）の変形例は、情報端末１００が個別メニュー情報を生成する態様を採用した場合についても適用可能である。
以上、１つまたは複数の態様に係る情報提供システム及び情報提供方法について、実施の形態に基づいて説明したが、本開示は、この実施の形態に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本開示の範囲に含まれても良い。
（実施の形態３）
実施の形態１は、個別メニュー情報の生成主体が第１サーバ２００であった。実施の形態３は、個別メニュー情報の生成主体が第２サーバ３００であることを特徴とする。実施の形態３の情報提供システムは第２サーバ３００を含む情報管理システムを含む。
なお、実施の形態３において、実施の形態１と同一の構成要素については同一の符号を付し、説明を省く。
まず、図２を参照して、実施の形態３の構成について説明する。実施の形態３では、個別メニュー情報が第２サーバ３００で生成されるため、以下、第２サーバ３００の構成を中心に説明する。
第２サーバ３００の通信部３０１は、情報端末１００から情報端末１００のユーザを特定する識別情報を受信する。加えて第１レストランと系列が異なる第２レストランを示す店舗ＩＤを受信しても良い。この店舗ＩＤは、情報端末１００を操作するユーザが選択した店舗の識別情報（レストランの系列情報かつ／または店舗を特定する情報を含む）である。通信部３０１は、演算部３０２が生成した個別メニュー情報を第２レストランを選択したユーザの情報端末１００に送信する。
第２サーバ３００の演算部３０２は、受信したユーザＩＤに対応する嗜好情報を第１サーバ２００から取得する。ここで、嗜好情報は、第２サーバ３００に対してユーザが嗜好情報のアクセスを許可している場合に第１サーバ２００から送信される。これにより、ユーザの個人情報がユーザの許可なく第１サーバ２００の外部に漏洩することを防止できる。一方、第２サーバ３００又は第２サーバ３００を利用するレストラン系列に対してユーザが嗜好情報のアクセスを不許可にしている場合、嗜好情報は第１サーバ２００から送信されない。この場合、第２サーバ３００は、第２レストランの標準メニューを情報端末１００に送信してもよい。
演算部３０２は、メモリ３０３から第２レストランの標準メニュー情報を取得し、嗜好情報及び標準メニュー情報に基づき、嗜好情報に対応した順序にてメニュー内容を配列する。
演算部３０２は、配列されたメニュー内容のメニュー情報（個別メニュー情報）を通信部３０１を用いて情報端末１００に送信する。これにより、情報端末１００のディスプレイ１０５に個別メニューが表示される。
演算部３０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴がない場合、嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランが属する系列を初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
一方、演算部３０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴がある場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第２レストランを過去に利用したことがある場合、第２レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
なお、演算部３０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量に満たない場合、当該ユーザのユーザＩＤに対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第２レストランでの注文履歴が所定量に満たない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所定量は、ユーザが第２レストランに行きつけているとみなされる予め定められた値、又は第２レストランに初めて来店したとみなせる予め定められた値を有する。
一方、演算部３０２は、第２レストランを選択したユーザによる第２レストランでの注文履歴が所定量以上である場合、第２レストランでの注文履歴及び第２レストランの標準メニュー情報に基づき、第２レストランでの注文履歴に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第２レストランでの注文履歴が所定量以上の場合、ユーザは、第２レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
さらに、演算部３０２は、第２レストランを選択したユーザによる第２レストランでの直近の注文履歴が所定期間より前である場合、当該ユーザのユーザＩＤに対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第２レストランに久しく来店していない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所定期間は、例えば、現在から過去３年、２年、１年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。
さらに、演算部３０２は、該当するユーザの設定期間内での第２レストランでの注文回数が一定回数以下である場合、該当するユーザのユーザＩＤに対応する嗜好情報及び第２レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第２レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、設定期間内の第２レストランにおける注文回数が一定回数以下の場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。設定期間は、例えば、現在から過去３年、２年、１年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。一定回数は、ユーザが第２レストランに行きつけているとみなされる予め定められた値、又は第２レストランに初めて来店したとみなせる予め定められた値を有する。
続いて、第１サーバ２００について説明する。第１サーバ２００のメモリ２０３は、各ユーザに対するアクセス情報を記憶する。アクセス情報は、ユーザが第２サーバ３００に対して自身の嗜好情報のアクセスを許可するか否かを示す情報である。アクセス情報は、アクセス許可、アクセス不許可、及び未設定のいずれかを含む。
ある１のユーザの第２サーバ又は第２サーバ３００を利用する事業者へのアクセス情報がアクセス許可に設定されている場合、通信部２０１が第２サーバ３００又は第２サーバ３００を利用する事業者から当該１のユーザについての嗜好情報の取得要請を受信すると、演算部２０２は、当該１のユーザの嗜好情報を第２サーバ３００又は第２サーバ３００を利用する事業者に送信する。ある１のユーザの第２サーバ３００又は第２サーバ３００を利用する事業者へのアクセス情報がアクセス不許可に設定されている場合、通信部２０１が第２サーバ３００又は第２サーバ３００を利用する事業者から当該１のユーザについての嗜好情報の取得要請を受信すると、演算部２０２は、当該１のユーザの嗜好情報を第２サーバ３００に送信しない。ある１のユーザのアクセス情報が未設定の場合、通信部２０１が第２サーバ３００又は第２サーバを利用する事業者からの当該１のユーザについての嗜好情報の取得要請を受信すると、演算部２０２は、通信部２０１を用いて、嗜好情報に対するアクセスを許可するか否かの問い合わせメッセージを情報端末１００に送信する。
図２１は、実施の形態３において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。図２１において図１６と同一の処理については同一の符号を付し、説明を省略する。なお、図２１では、ユーザは自身の嗜好情報（注文履歴）に対する第２サーバ３００又は第２サーバ３００を利用するレストランＢ系列のアクセス情報を未設定にしているものとする。
ステップＳ２１～Ｓ２６は、図１６と同じである。
ステップＳ２６に続くステップＳ３０１において、情報端末１００（マッチングアプリ）は、店舗Ｂ１の個別メニュー情報の取得要請を第２サーバ３００に送信する。この取得要請には店舗Ｂ１の店舗ＩＤ及び情報端末１００のユーザＩＤ等が含まれる。
ステップＳ３０２において、第２サーバ３００はメモリ３０３からレストランＢ系列の標準メニュー情報を取得する。ここで取得されるレストランＢ系列の標準メニュー情報は、レストランＢ系列の各店舗で共通のメニュー情報であってもよいし、レストランＢ系列の各店舗で一部分が異なるメニュー情報であってもよい。
ステップＳ３０３において、第２サーバ３００は、該当するユーザの注文履歴（嗜好情報の一例であって、嗜好情報を表現した情報であれば良い）の取得要請を第１サーバ２００に送信する。
ステップＳ３０４において、第１サーバ２００は、メモリ２０３から該当するユーザのアクセス情報を読み出し、該当するユーザに関してレストランＢ系列に対するアクセス情報が未設定であることを確認する。
ステップＳ３０５において、第１サーバ２００は、レストランＢ系列に対して注文履歴のアクセスを許可するか否かの問い合わせメッセージを情報端末１００に送信する。問い合わせメッセージは情報端末１００のディスプレイ１０５に表示される。
ステップＳ３０６において、情報端末１００は、問い合わせメッセージを確認したユーザからアクセス情報をアクセス許可に選択する操作を受け付ける。
ステップＳ３０７において、情報端末１００は、アクセス情報がアクセス許可に選択されたことを示す通知情報を第１サーバ２００に送信する。
ステップＳ３０８において、アクセス許可が選択されたことを示す通知情報を受信した第１サーバ２００は、メモリ２０３に記憶された該当するユーザのレストランＢ系列に対するアクセス情報をアクセス許可に設定する。これにより、第１サーバ２００は、該当するユーザの注文履歴をメモリ２０３から読み出し、第２サーバ３００に送信する。
ステップＳ３０９において、第２サーバ３００は、該当するユーザの注文履歴を受信する。
ステップ３１０において、第２サーバ３００は、該当するユーザの注文履歴に基づいて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。
具体的には、第２サーバ３００は、レストランＢ系列での該当するユーザの注文履歴が上述の参照条件Ｃ１を満たさない場合（例えば、該当するユーザがレストランＢ系列に初めて来店したとみなせる場合）、レストランＢ系列の店舗Ｂ１が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗Ｂ１における個別メニュー情報を生成する。
一方、第２サーバ３００は、レストランＢ系列での該当するユーザの注文履歴が参照条件Ｃ１を満たしている場合（例えば、該当するユーザがレストランＢ系列に行きつけているとみなせる場合）、レストランＢ系列での該当するユーザの注文履歴を用いて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。この処理の詳細は、図１７に示すフローチャートを用いて上述した。第２サーバ３００は、生成された個別メニュー情報を情報端末１００に送信する。
ステップＳ３１１において、情報端末１００は、個別メニュー情報を受信する。
ステップＳ３１１までの処理において、情報端末１００に表示される各種画面は第１サーバ２００の管理者（情報銀行）のスタイルでデザインされたものが使用される。一方、ステップＳ３１２からの処理においては、情報端末１００に表示される各種画面はレストランＢ系列のスタイルでデザインされたものが使用される。または、レストランＢ系列の料理を説明する文字及び写真を第１サーバ２００の管理者のスタイルでレイアウトしたものが使用されても良い。
ステップＳ３１２において、情報端末１００は、受信した店舗Ｂ１の個別メニュー情報を示す個別メニュー画面Ｇ５，Ｇ６を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップＳ３１３において、情報端末１００は、注文された飲食品を示す注文情報を第２サーバ３００に送信する。この注文情報を受信した第２サーバ３００は、例えば店舗Ｂ１の店舗端末のディスプレイに注文情報を表示する等して、店舗Ｂ１のスタッフに調理の開始を通知する（ステップＳ３６）。なお、この処理は次のステップＳ３１４により注文情報を受信した第１サーバ２００が、第２サーバ３００へ送信することで代替しても良い。
ステップＳ３１４において、情報端末１００は、注文情報をさらに第１サーバ２００に送信する。
注文情報を受信した第１サーバ２００は、注文情報をメモリ２０３に記憶することで、該当するユーザの注文履歴を更新する（ステップＳ３５）。
図２２は、実施の形態３において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の他の一例を示すシーケンス図である。
図２２において図２１と同一の処理については同一の符号を付し、説明を省略する。なお、図２２では、ユーザは自身の嗜好情報（注文履歴）に対するレストランＢ系列のアクセス情報をアクセス許可に設定しているものとする。
ステップＳ２１～Ｓ２６、ステップＳ３０１～Ｓ３０３までの処理は、図２１と同じである。
ステップＳ３０３に続くステップＳ４０１において、該当するユーザの注文履歴の取得要請を受信した第１サーバ２００は、メモリ２０３から該当するユーザのアクセス情報を読み出し、該当するユーザに関してレストランＢ系列（又はレストランＢ系列が利用する第２サーバ３００）に対するアクセス情報がアクセス許可に設定されていることを確認する。これにより、第１サーバ２００は、該当するユーザの注文履歴をメモリ２０３から読み出し、第２サーバ３００に送信する。
ステップＳ３０９以降の処理は図２１と同じである。
図２３は、実施の形態３において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理のさらに他の一例を示すシーケンス図である。
図２３において図２１と同一の処理については同一の符号を付し、説明を省略する。なお、図２３では、ユーザは自身の嗜好情報（注文履歴）に対するレストランＢ系列のアクセス情報を未設定にしているものとする。
ステップ２１～Ｓ２６及びステップＳ３０１～Ｓ３０５の処理は図２１と同じである。ステップＳ３０５に続くステップＳ５０１において、情報端末１００は、問い合わせメッセージを確認したユーザからアクセス情報をアクセス不許可に選択する操作を受け付ける。
ステップＳ５０２において、情報端末１００は、アクセス情報がアクセス不許可に選択されたことを示す通知情報を第１サーバ２００に送信する。
ステップＳ５０３において、アクセス不許可が選択されたことを示す通知情報を受信した第１サーバ２００は、メモリ２０３に記憶された該当するユーザのレストランＢ系列又はレストランＢ系列が利用する第２サーバ３００へのアクセス情報をアクセス不許可に設定する。これにより、第１サーバ２００は、第２サーバ３００に対して要求エラーを送信する。要求エラーは第２サーバ３００に対して、注文履歴の取得要求に応答することができないことを通知するための情報である。
ステップＳ５０４において、第２サーバ３００は、要求エラーを受信する。要求エラーを受信した第２サーバ３００は、メモリ３０３からレストランＢ系列の標準メニュー情報を読み出し、読み出した標準メニュー情報と要求エラーとを情報端末１００に送信する。
ステップＳ５０５において、情報端末１００は、標準メニュー情報と要求エラー（レストランＢ系列がユーザの嗜好情報（注文履歴）へのアクセス不許可と設定されたことを示す情報）とを受信する。
ステップＳ５０６において、情報端末１００は、個別メニューが生成できなかったことを示す情報と、標準メニュー画面Ｇ７とをディスプレイ１０５に表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップＳ３１３以降の処理は図２１と同じである。
このように、実施の形態３によれば、第２サーバ３００が個別メニュー情報を生成する場合であっても、ユーザの許諾がない事業者に対して嗜好情報が渡らないようにしながらも、ユーザが初めて利用する第２レストランにおいて、ユーザの嗜好情報が考慮されたメニュー情報を表示できる。
（実施の形態４）
実施の形態４は、個別メニュー情報の生成主体が第１サーバ２００である場合において、第１サーバ２００が標準メニュー情報を事前取得することを特徴とする。
なお、実施の形態４において、実施の形態１～３と同一の構成要素については同一の符号を付し、説明を省く。
まず、図２を参照して、実施の形態４の構成について説明する。実施の形態４では、個別メニュー情報が第１サーバ２００で生成されるため、以下、第１サーバ２００の構成を中心に説明する。
演算部２０２は、情報端末１００から店舗ＩＤが取得される前に、店舗ＩＤが示す第２レストランに関連する第２サーバ３００からネットワークを介してメニュー情報を取得し、取得したメニュー情報をメモリ２０３に記憶する。
次に、実施の形態４の処理について説明する。図２４は、実施の形態４における情報提供システムの処理の一例を示すシーケンス図である。図２４において図１６と同一の処理については同一の符号を付し、説明を省略する。ステップＳ２１～Ｓ２７、Ｓ３１～Ｓ３６の処理は、図１６と同じである。
実施の形態４は、第１サーバ２００が、店舗ＩＤを取得（ステップＳ２７）する前に標準メニュー情報を事前取得するものである。そのため、図２４では、図１６の標準メニュー情報を取得する処理（ステップＳ２８、Ｓ２９）が省かれ、その代わりに先頭にステップＳ６０１、Ｓ６０２の処理が設けられている。
ステップＳ６０１において、第２サーバ３００は、標準メニュー情報を更新し、更新した標準メニュー情報を第１サーバ２００へ送信する。ステップＳ６０２において、第１サーバ２００は標準メニュー情報を受信し、その標準メニュー情報をメモリ２０３に記憶する。
これにより、第１サーバ２００は、個別メニュー情報の取得要請を受信すると速やかに個別メニュー情報を生成できる。
ステップＳ３０ａにおいて、店舗Ｂ１の個別メニュー情報の取得要請を受信した第１サーバ２００は、メモリ２０３から店舗Ｂ１の標準メニュー情報を読み出し、読み出した標準メニュー情報と、該当するユーザの注文履歴とに基づいて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。
具体的には、第１サーバ２００は、レストランＢ系列での該当するユーザの注文履歴が上述の参照条件Ｃ１を満たさない場合（例えば該当するユーザがレストランＢ系列に初めて来店したとみなせる場合）、レストランＢ系列の店舗Ｂ１が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗Ｂ１における個別メニュー情報を生成する。
一方、第１サーバ２００は、レストランＢ系列での該当するユーザの注文履歴が参照条件Ｃ１を満たしている場合（例えば該当するユーザがレストランＢ系列に行きつけているとみなせる場合）、レストランＢ系列での該当するユーザの注文履歴を用いて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。この処理の詳細は、図１７に示すフローチャートを用いて上述した。
なお、図２４に示すステップＳ６０２に示す標準メニュー情報を送信するタイミングは、個別メニュー情報の取得要請が送信されるタイミング（ステップＳ２７）よりも前であれば、どのようなタイミングであってもよい。
例えば、標準メニュー情報の送信タイミングは、ステップＳ２１以前であっても良いし、ステップＳ２４以後且つステップＳ２７以前、であっても良い。
図２４では、標準メニュー情報が更新されたタイミングで標準メニュー情報が送信されているが、これは一例である。例えば、第１サーバ２００は、情報端末１００から店舗情報の取得要請を受信したときに（ステップＳ２４）、情報端末１００で表示され得る店舗の標準メニュー情報を取得してもよい。ここで、表示され得る店舗の一例は、図６に示すマップ画面Ｇ４に表示される店舗である。なお、第１サーバ２００は、マップ画面Ｇ４に表示された各店舗に対応する第２サーバ３００に標準メニュー情報の取得リクエストを送信することで、各店舗の標準メニュー情報を取得すればよい。
（実施の形態５）
実施の形態５は、個別メニュー情報の生成主体が情報端末１００である場合において、情報端末１００が標準メニュー情報を事前取得することを特徴とする。
なお、実施の形態４において、実施の形態１～４と同一の構成要素については同一の符号を付し、説明を省く。
まず、図２を参照して、実施の形態５の構成について説明する。実施の形態５では、個別メニュー情報が情報端末１００で生成されるため、以下、情報端末１００の構成を中心に説明する。
演算部１０４は、ユーザによる店舗ＩＤの選択を受け付ける前に店舗ＩＤが示す第２レストランに関連する第２サーバ３００からネットワークを介してメニュー情報を取得し、取得したメニュー情報をメモリ１０２に記憶する。
次に、実施の形態５の処理について説明する。図２５は、実施の形態５における情報提供システムの処理の一例を示すシーケンス図である。図２５において図２０と同一の処理については同一の符号を付し、説明を省略する。ステップＳ２１～Ｓ２６、Ｓ３０３～Ｓ３０４、Ｓ３０６～Ｓ３０８、Ｓ３５、Ｓ３６の処理は、図２０と同じである。
実施の形態５は、情報端末１００がユーザから店舗Ｂ１の選択を受け付ける前に（ステップＳ２６）、標準メニュー情報を事前取得するものである。そのため、図２５では、図２０の標準メニュー情報を取得する処理（ステップＳ３０１、Ｓ３０２）が省かれ、その代わりに先頭にステップＳ７０１、Ｓ７０２の処理が設けられている。
ステップＳ７０１において、第２サーバ３００は、標準メニュー情報を更新し、更新した標準メニュー情報を情報端末１００へ送信する。ステップＳ７０２において、情報端末１００は標準メニュー情報を受信し、その標準メニュー情報をメモリ１０２に記憶する。
これにより、情報端末１００は、ユーザにより店舗Ｂ１が選択されると速やかに個別メニュー情報を生成できる。
ステップＳ３０５ａにおいて、ユーザの注文履歴を受信した情報端末１００は、メモリ１０２から店舗Ｂ１の標準メニュー情報を読み出し、読み出した標準メニュー情報と、該当するユーザの注文履歴とに基づいて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。
具体的には、情報端末１００は、レストランＢ系列での該当するユーザの注文履歴が上述の参照条件Ｃ１を満たさない場合（例えば該当するユーザがレストランＢ系列に初めて来店したとみなせる場合）、レストランＢ系列の店舗Ｂ１が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗Ｂ１における個別メニュー情報を生成する。
一方、情報端末１００は、レストランＢ系列での該当するユーザの注文履歴が参照条件Ｃ１を満たしている場合（例えば該当するユーザがレストランＢ系列に行きつけているとみなせる場合）、レストランＢ系列での該当するユーザの注文履歴を用いて店舗Ｂ１における該当するユーザの個別メニュー情報を生成する。この処理の詳細は、図１７に示すフローチャートを用いて上述した。
なお、図２５に示すステップＳ７０２に示す標準メニュー情報を送信するタイミングは、情報端末１００がユーザから店舗Ｂ１の選択を受け付ける前であれば（ステップＳ２６）、どのようなタイミングであってもよい。
例えば、標準メニュー情報の送信タイミングは、ステップＳ２１以前であっても良いし、ステップＳ２４以後かつステップＳ３０３以前、であっても良い。
図２５では、標準メニュー情報が更新されたタイミングで標準メニュー情報が送信されているが、これは一例である。例えば、情報端末１００のマッチングアプリが店舗情報の取得要請を送信したときに（ステップＳ２４）、情報端末１００上で表示され得る店舗の標準メニュー情報を取得してもよい。ここで、表示され得る店舗の一例は、図６に示すマップ画面Ｇ４に表示される店舗である。なお、情報端末１００は、マップ画面Ｇ４に表示された各店舗に対応する第２サーバ３００に標準メニュー情報の取得リクエストを送信することで、各店舗の標準メニュー情報を取得すればよい。
さらに、情報端末１００のマッチングアプリは、情報端末１００の現在位置をＧＰＳ信号などから捕捉し、近隣地域にある店舗の標準メニュー情報を第２サーバ３００に予めリクエストして取得することで、標準メニュー情報を更新するようにしてもよい。
図２６は、実施の形態５における情報提供システムの処理の変形例を示す図である。図２６において図２０と同一の処理については同一の符号を付し、説明を省略する。この変形例では、標準メニュー情報の取得タイミングは図２０と同じである。また、この変形例では、嗜好情報である注文情報は第１サーバ２００に加えて情報端末１００も記憶している。そのため、図２６では、情報端末１００が第１サーバ２００にユーザの注文履歴を取得する処理（ステップＳ３０３、Ｓ３０４）は省かれている。
ステップＳ３０５ｂにおいて、標準メニュー情報を取得した情報端末１００は、ユーザの注文履歴をメモリ１０２から読み出し、読み出した注文履歴と標準メニュー情報とを用いてユーザの個別メニュー情報を生成する。
以下、図２０と同様、ステップＳ３０６、Ｓ３０７、Ｓ３０８、Ｓ３５、Ｓ３６の処理が行われる。そして、ステップＳ３０９において、情報端末１００は、今回の注文情報をメモリ１０２に記憶することによって、メモリ１０２に記憶されている注文履歴を更新する。
ユーザの注文履歴の一部（過去の所定期間分など）若しくは全て、又はユーザの食事選択における嗜好情報の一部（注文回数が上位の商品識別情報のみなど）若しくは全てが、情報端末１００のメモリ１０２にセキュアにキャッシュされたり、セキュアに記録・蓄積されたりする、ことも考えられる。これは個人情報が一カ所に集中管理されている集中型ＰＤＳ（Ｃｅｎｔｒａｌｉｚｅｄ Ｐｅｒｓｏｎａｌ Ｄａｔａ Ｓｔｏｒｅ）とは異なり、分散型ＰＤＳ（Ｄｅｃｅｎｔｒａｌｉｚｅｄ Ｐｅｒｓｏｎａｌ Ｄａｔａ Ｓｔｏｒｅ）とも呼ばれる。この場合は、ステップＳ３０６で注文が確定した後に、情報端末１００は、メモリ１０２上にセキュアに注文履歴を蓄積していく（ステップＳ３０９）。これによって情報端末１００のメモリ１０２に個人情報（嗜好情報）が蓄積されていき、次回のマッチングにその個人情報が利用することができる。
嗜好情報（注文履歴）を必要とする度に、外部サーバから外部通信ネットワークを介して取得するのではなく、情報端末１００内にセキュアに格納された嗜好情報を利用することで、通信経路での嗜好情報の漏洩リスクの回避、外部との通信量（通信料金）の削減、及び個別メニュー情報の生成時間の短縮、といったメリットが期待できる。
尚、図２６においても、図２５と同様、情報端末１００が標準メニュー情報を予め取得しておく特徴を有していてもよい。この場合、情報端末１００（マッチングアプリ）は個別メニューを生成する際に必要となるユーザの嗜好情報（注文履歴）と、レストランＢ系列の標準メニュー情報との両方をメモリ１０２から取得して、ステップＳ３０５ａにおいて個別メニューを生成することができる。
（実施の形態６）
実施の形態６は、個別メニュー画面がユーザの嗜好情報に対応した順序で配列された第１メニュー内容を表示する第１表示領域と、第２レストランが指定する第２メニュー内容を表示する第２表示領域とを含むことを特徴とする。
なお、実施の形態６において、実施の形態１と同一の構成要素については同一の符号を付し、説明を省く。
まず、図２を参照して、実施の形態６の構成について説明する。実施の形態６では、個別メニュー情報が第１サーバ２００で生成されるため、以下、第１サーバ２００の構成を中心に説明する。
第１サーバ２００の演算部２０２は、ユーザの識別情報に対応する嗜好情報、及びユーザが選択した第２レストランの店舗ＩＤが示す第２レストランのメニュー情報に基づき、嗜好情報に対応した順序にてメニュー情報に含まれる第１メニュー内容を配列する。
メニュー情報は、ユーザの嗜好情報に対応した順序で配列された第１メニュー内容と、第２レストランによって指定された第２メニュー内容とを含み、かつ、店舗ＩＤが示す第２レストランに関連する第２サーバ３００からネットワークを介して取得される。
演算部２０２は、嗜好情報に対応した順序にて配列された第１メニュー内容と、第２メニュー内容とを含むメニュー情報を情報端末１００に送信し、情報端末１００の表示画面内の第１表示領域に、嗜好情報に対応する順序にて配列された第１メニュー内容を表示させ、かつ、表示画面内の第２表示領域に、第２レストランによって指定された第２メニュー内容を表示させる。
ここで、第２表示領域内における第２メニュー内容の配列は、嗜好情報を使わずに固定されていてもよいし、嗜好情報を使って変動されてもよい。例えば、第２メニュー内容は、第２レストランが指定する商品がユーザの嗜好にしたがって配列されたものであってもよい。
第１メニュー内容は、嗜好情報に対応した順序が第１順序である場合には第１順序に配列されて第１表示領域に表示され、かつ、嗜好情報に対応した順序が第１順序とは異なる第２順序である場合には第２順序に配列されて第１表示領域に表示されてもよい。
第２メニュー内容は、嗜好情報に対応した順序が第１順序または第２順序のいずれの場合でも同じ形態で第２表示領域に表示されてもよい。
図２７は、実施の形態６における第１例の個別メニュー画面Ｇ１１を示す図である。個別メニュー画面Ｇ１１は、個別メニュー情報の一部の商品（料理）として、ユーザにより指定されたレストラン又は店舗が指定した商品が採用されている。
個別メニュー画面Ｇ１１において、画面上部に目を引くように表示された「プレミアムランチセット」は特別にレストランＢの店舗Ｂ１がユーザにオファーした商品であって、それ以外の「アイスクリーム」、「カプチーノ」、「カフェモカ」、「タピオカヨーグルト」は、過去によくユーザが注文していた商品である。
この個別メニュー画面Ｇ１１では、「アイスクリーム」、「カプチーノ」、「カフェモカ」、「タピオカヨーグルト」の４つの商品は、ユーザの過去の注文履歴（図１２又は図１４の表）から計算されたユーザの嗜好情報に従った順序で表示されている。例えば、「アイスクリーム」、「カプチーノ」、「カフェモカ」、「タピオカヨーグルト」は、過去の注文回数の多い順に配列されている。この表示順は、上から下の順序であり、上下位置が同じ場合には左から右の順序である。
一方で、「プレミアムランチセット」はこれら４つの商品と比べて過去の注文回数に基づいても、基づかなくても良く、店舗の指定によりこれら４つの商品よりも優先的に個別メニュー画面Ｇ１１に表示されている。つまり、ユーザの嗜好情報に対応した順序で商品が表示されると説明したが、これは個別メニュー画面Ｇ１１で表示される商品全体に対してではなく、一部の商品に対してのみ適用されても良い。これによって店舗が販売、宣伝したい商品を任意の表示位置や表示形態にて訴求することができるようになる。また、嗜好情報が一定量たまることで個別メニュー画面に表示される商品が固定化している場合に、アイキャッチーな商品を加えることで新たにユーザの興味を引くことができるようになる。
商品の表示順は、個別メニュー画面Ｇ１１のトップ画面（初期表示画面）が表示されてから、その商品が情報端末１００のディスプレイ上に表示されるために必要となるユーザの操作回数（ページ送りなど）又は商品を表示するために必要となるユーザの操作量（画面スクロールの移動量など）が多くなるほど、順位が低くされてもよい。
優先度が高い表示順を有する商品は、トップ画面からの操作回数又は操作量がより少なくなる画面に表示されても良い。逆に優先度が低い表示順を有する商品は、トップ画面からより多くの操作回数又は操作量を行わなければ表示されない画面に表示されるようにしても良い。
このように個別メニュー情報を情報端末１００に表示する場合、ユーザの過去の注文回数、かつ／または、ユーザが商品に対する嗜好情報に応じて、個別メニュー情報のすべての商品がユーザの嗜好情報に対応した順序で表示される必要はない。
個別メニュー画面に少なくとも第１の商品と、第２の商品とが含まれる場合、ユーザが第１の商品を第２の商品よりも嗜好している（例えば過去の注文回数が多い）ことが判明した場合、個別メニュー画面Ｇ１１では、そのユーザにより嗜好されている第１の商品が、第２の商品よりも優先して表示されるようにしても良い。優先して表示されるとは、例えばより少ない操作回数又は操作量で表示されることを意味する。嗜好情報に従った順序での表示は、個別メニュー情報の全部の商品に適用されてもよいし、一部（少なくとも２つ以上）の商品に適用されてもよい。
なお、嗜好情報の一例は注文履歴であったが、これに限定されず、嗜好の予測値であってもよい。嗜好の予測値は、多くのユーザの嗜好情報を例えば協調フィルタリングにより分析することで得られる。
図２８は、実施の形態６における第２例の個別メニュー画面Ｇ１２を示す図である。図２９は、実施の形態６における第３例の個別メニュー画面Ｇ１３を示す図である。個別メニュー画面Ｇ１２、Ｇ１３は、ユーザの嗜好情報に対応した順序で商品をレイアウトすると同時に、店舗が指定する商品をレイアウトする。ここでは、店舗が個別メニュー情報に加えた商品は、「プレミアムランチセット」と「チョコドーナッツ」との２商品である。それ以外の商品はユーザの嗜好情報に対応した順序で表示されている。
例えば、個別メニュー画面Ｇ１２では、２行目に店舗が加えた「プレミアムランチセット」が表示されている。例えば、個別メニュー画面Ｇ１３では、２行１列目に店舗が加えた「プレミアムランチセット」と、３行２列目に店舗が加えた「チョコドーナッツ」とが表示されている。
個別メニュー画面Ｇ１２に示す「プレミアムランチセット」のように、店舗が指定した商品のタイルオブジェクト２８０１の枠は他のタイルオブジェクトの枠よりも太く表示されてもよいし、デフォルメマーク２８０２を含めてもよい。また、個別メニュー画面Ｇ１３に示す「プレミアムランチセット」及び「チョコドーナッツ」のように、店舗が指定した商品のタイルオブジェクト２９０１は、ハートマーク２９０２と「お勧め」のメッセージとを含めてもよい。このように、店舗は、指定した商品のタイルオブジェクトを視覚的に識別ができるようにデザインすることができる。これにより、店舗は、指定した商品が、ユーザに宣伝したい商品であることを示すことができる。
このように、個別メニュー画面Ｇ１２、Ｇ１３は、ユーザの嗜好情報に対応した順序でレイアウトされる商品群（第１メニュー内容）と、店舗の指定によりレイアウトされる商品群（第２メニュー内容）とを、自由に組み合わされた商品を表示することができる。なお、第１メニュー内容及び第２メニュー内容の表示サイズ、表示レイアウト、１表示領域での商品表示数、などは第１メニュー内容がユーザの嗜好情報に対応した順序でレイアウトされる限りにおいて、任意である。
個別メニュー画面Ｇ１１、Ｇ１２、Ｇ１３を生成する処理は、図１７のステップＳ１０４の処理に含まれる。
図３０及び図３１は、実施の形態６における第４例の個別メニュー画面Ｇ１４を示す図である。個別メニュー画面Ｇ１４は、タブによってメニュー画面の表示が切り替えられるようにデザインされている。図３０の個別メニュー画面Ｇ１４は、ユーザの嗜好情報に対応した順序で商品が表示される「注文履歴（嗜好順）」タブが選択されている際に表示される画面の一例である。図３１の個別メニュー画面Ｇ１４は、店舗が指定する商品が表示される「お店のお勧め」タブが選択されている際に表示される画面の一例である。タブは他に、ドリンクだけの商品を表示する「ドリンク」タブ、及びランチの時間帯に注文することができる商品を表示する「ランチ」タブ等があってもよい。但し、これは一例であり、「ドリンク」タブ及び「ランチ」タブはなくても良い。
「注文履歴（嗜好順）」タブが選択された場合、情報端末１００は図３０に示すように、ユーザの嗜好情報に対応した順序で商品を表示する。一方、「お店のお勧め」タブが選択された場合、情報端末１００は図３１に示すように、店舗が指定するユーザに宣伝したい商品を表示する。
このように、タブによって情報端末１００の画面に表示される商品の属性を切り替えることで、ユーザはより容易に所望の商品を探し出すことができる。
図３２は、実施の形態６における第５例の個別メニュー画面Ｇ１５を示す図である。個別メニュー画面Ｇ１５は、図６のマップ画面Ｇ４においてレストランＢ系列の店舗Ｂ１を示すアイコン３２１０が選択された場合、画面を切り替えることなく、マップ画面Ｇ４と、マップ画面Ｇ４に表示された店舗の位置と、選択された店舗Ｂ１の個別メニュー情報とを表示する。
これまでの説明においては、マップ画面Ｇ４及び個別メニュー画面Ｇ５、Ｇ６、Ｇ１１～Ｇ１４は夫々が画面全体を占有して表示されていたが、本開示はこれに限らない。
個別メニュー画面Ｇ１５に示すように、マップ画面Ｇ４上にレストランの店舗が配置され、同時に選択した店舗のメニューとユーザの嗜好情報とがマッチングされた個別メニュー情報が表示されるようにしてもよい。
この場合、ユーザはマップ画面Ｇ４を見ながら店舗の位置を確認しつつ、店舗ごとの個別メニュー情報を確認することができるため、画面を切り替えることなく、複数の店舗の個別メニュー情報を素早く確認することが可能となる。
また、実施の形態６では、個別メニュー画面Ｇ１１～Ｇ１５は、第１サーバ２００が生成したが、本開示はこれに限定されず、情報端末１００が生成してもよいし、第２サーバ３００が生成してもよい。または、第１サーバ２００、情報端末１００、第２サーバ３００の内、少なくとも２つ以上を用いて生成してもよい。情報端末１００が個別メニュー画面Ｇ１１～Ｇ１５を生成する場合、情報端末１００は実施の形態２又は実施の形態５の処理を用いて個別メニュー画面Ｇ１１～Ｇ１５を生成すればよい。第２サーバ３００が個別メニュー画面Ｇ１１～Ｇ１５を生成する場合、第２サーバ３００は、実施の形態３又は実施の形態４の処理を用いて個別メニュー画面Ｇ１１～Ｇ１５を生成すればよい。また、第１サーバ２００または情報端末１００が個別メニュー画面Ｇ１１～Ｇ１５を生成する場合、第１サーバ２００または情報端末１００は、標準メニュー情報を事前取得してもよい。
（補足）
（Ａ－１）本開示において、ＩＤ（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）とは、該当対象物を識別するために用いられる記号、番号、文字列、ＵＲＬなどで表現された識別情報であれば形式を問わない。
（Ａ－２）本開示において、店舗ＩＤの選択はユーザの手入力に限定されず、自動で選択されても良い。例えば、情報端末１００の現在位置をＧＰＳ、ＵＷＢ、Ｂｌｕｅｔｏｏｔｈのような無線通信技術により特定することで、ユーザが入店した店舗の店舗ＩＤを自動的に選択するようにしても良いし、情報端末１００の現在位置から近い店舗だけに候補を絞り込みユーザに音声又はタッチ操作で店舗を選択させるようにしても良い。
（Ａ－３）本開示において、「嗜好情報に対応した順序」は、個別メニューの全ての料理（商品）の順序が嗜好情報に応じた順序である必要はない。例えば、少なくとも個別メニューにて表示される第１料理と第２料理とがある場合、第１料理と第２料理とが夫々のユーザの嗜好情報に対応した、または加味した、順序にて配列、表示されていれば良い。
すなわち、個別メニューで表示される少なくとも２つ以上の料理が夫々の嗜好情報に対応した順序で配列されていれば良い。例えば、季節料理、レストランがお勧めする料理、ユーザと類似の嗜好情報を持つ人達がよく注文する料理、などはユーザの嗜好情報に対応した順序で配列しなくても良い。そういった料理は、個別メニューの最初の画面や、比較的高い優先順序にて、個別メニューの中で表示させるようにしても良い。
（Ａ－４）本開示において、「前記メニュー情報に含まれる第１メニュー内容を配列し」は、個別メニューの中で嗜好情報に対応した順序で料理を並び替える態様に限定されない。例えば、図８の個別メニュー画面Ｇ６のように、他の料理とは異なる表現方法であって嗜好情報に対応した表現方法を各料理に施すだけで、並び替えを伴わなくても良い。表現方法の一例は、料理の選択枠（タイルオブジェクト）の面積・太さ・色・点滅、料理画像のサイズ・デフォルメ、料理名と料理の特徴とを示す文字情報のサイズ・デフォルメ、ユーザの嗜好情報との合致・合致度合いを示すマーク・数字を付与する等である。
（Ａ－５）本開示において、「第２レストランに関連するサーバ」は、第２レストランがメニュー情報を記録、配信するサーバ（又はコンピュータ）に対してネットワークで接続された全てのサーバを含む。例えば、「第２レストランに関連するサーバ」は、メニュー情報を保持する第２サーバ３００と、第２サーバ３００及び第１サーバ２００に介在する１又は複数のサーバ（またはコンピュータ）とを含むものであってもよい。データ取引市場で定義される「データ取引市場運営事業者」のように、「第２レストランに関連するサーバ」は、データ提供者とデータ提供先との間を仲介し、データと対価の交換、決済などの機能を提供するデータ取引市場運営事業者と、データ取引市場運営事業者が運営するサーバ（又はコンピュータ）とを含んでもよい。
（Ｂ－１）本開示において、「位置情報が示す地点を含む地域」は、人が経済活動を行い、位置情報が示す地点を含む任意の地域を意味する。「位置情報が示す地点を含む地域」の一例は、地球、国、都道府県や市区町村といった行政単位、所定半径の円状区画、又は任意形状の区画等である。このように、「位置情報が示す地点を含む地域」は、ユーザが認知可能な所定の限定された範囲内であれば良い。
（Ｂ－２）本開示では、「前記第２レストランによって指定された前記第２メニュー内容を表示させる」について、図１０の例では個別メニューが情報端末１００のディスプレイ１０５の全面に表示されているとして説明したが、これに限定されない。「前記第２レストランによって指定された前記第２メニュー内容を表示させる」は、図３２の例のように、地図と、選択した店舗と、その店舗の個別メニューとのうち、少なくとも２つ以上を同時に表示する態様を含んでもよい。こうすることで、画面遷移が削減され、ユーザは素早く、店舗のお勧め料理を確認することができる。
（Ｂ－３）第１サーバ２００が個人情報の一部又は全部を外部へ提供する場合、その個人情報を利用する側（例えば、情報端末１００のアプリ又は第２サーバ３００）が解読できない仕組みを利用して個人情報を提供してもよい。この仕組みは、秘密計算と呼ばれる。秘密計算では、個人情報は暗号化された状態で利用する側へ提供され、利用する側は、暗号化された状態の個人情報に対して必要な演算を行う。つまり、保存データを暗号化したり、通信データを暗号化したりする従来の手法とは異なり、秘密計算は、暗号化されたデータのままで必要な演算を行う暗号技術である。本開示が示す情報端末１００、第２サーバ３００での個人情報のセキュアな利活用を実現するために、秘密計算が利用されるようにしても良い。
（Ｂ－４）本開示では個人の属性、嗜好、行動といった個人情報を個人ごとに名寄せして蓄積し、個人の意思のもとで個人情報を管理するサービスを提供する事業者を情報銀行として説明したが、これは一例である。情報銀行は、同様の機能を提供する、ＰＤＳ（Ｐｅｒｓｏｎａｌ Ｄａｔａ Ｓｔｏｒｅ）、ＰＩＭＳ（Ｐｅｒｓｏｎａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）、データ共有事業者、又はデータ処理業者等と解釈されてもよい。
（Ｃ－１）本開示において、「入力デバイス」は指によるタッチ操作を行う情報端末１００のディスプレイ１０５に限定されない。「入力デバイス」は、情報端末１００のマイクセンサー（図略）からユーザの音声による店舗の選択指示を受け付けても良いし、情報端末１００のカメラ１０３からユーザの視線により店舗の選択指示を受け付けても良い。例えば、ユーザの視線方向上にある店舗のアイコンを検知し、そのアイコンが示す店舗をユーザが選択した店舗と判定すればよい。或いは、「入力デバイス」は、情報端末１００のＧＰＳセンサー１０７であってもよい。この場合、情報端末１００は、ＧＰＳセンサー１０７が検知した現在位置情報に基づいてユーザが選択した店舗を自動的に判定してもよい。例えば、情報端末１００は、現在位置情報に基づいてユーザが店舗内に進入したことを検知した場合、その店舗をユーザが選択した店舗として判定すればよい。また、これらの入力デバイスにより得られる情報を組み合わせて店舗の選択指示を受け付けるようにしても良い。
（Ｃ－２）本開示において、「前記識別情報に対応する嗜好情報を前記第１サーバから取得し」は、第１サーバとネットワーク接続された１又は複数のサーバ（又はコンピュータ）を経由して嗜好情報を取得することも勿論含む。尚、第１サーバにて管理されているユーザの嗜好情報の一部又は全部が情報端末１００のメモリ１０２にセキュアにキャッシュ又は保管されていて、情報端末１００のメモリ１０２からセキュアに利用が可能な場合には、第１サーバ２００から取得せずに、情報端末１００からユーザの嗜好情報を取得するようにしてもよい。この場合、第１サーバ２００の処理負荷の軽減、ネットワーク又は第１サーバ２００における処理の遅延の防止等の利点が得られる。さらに、この場合、情報端末１００内のデータ保護アーキテクチャが十分高度で信頼できる場合に第１サーバ２００との通信による情報漏洩のリスクを回避するといった利点もある。
（Ｄ－１）本開示において、「ユーザによって許諾されている」とは、ユーザの嗜好情報の一部又は全部を、第２レストラン（又は第２レストランと関連する第２サーバ）が利用することを、ユーザからの直接的指示又は予めの取り決めに基づき許諾することを含む。
（Ｄ－２）本開示において、「第２サーバに保持され」は、第２サーバがネットワークを介して取得可能な第２サーバ以外のサーバ、又はコンピュータがメニュー情報を保持する態様を含む。
本開示にかかる情報提供方法の一例によれは、ユーザが飲食品を効率よく注文することが可能であるため、飲食品をユーザに提供する外食産業に提供される技術として有用である。
１００ ：情報端末
１０１ ：通信部
１０２ ：メモリ
１０３ ：カメラ
１０４ ：演算部
１０５ ：ディスプレイ
１０６ ：操作部
１０７ ：ＧＰＳセンサー
２００ ：第１サーバ
２０１ ：通信部
２０２ ：演算部
２０３ ：メモリ
３００ ：第２サーバ
３０１ ：通信部
３０２ ：演算部
３０３ ：メモリ
４００ ：携帯基地局
５００ ：パブリック情報サーバ
６００ ：生体センサー
７０１ ：タイルオブジェクト
１４０１ ：タイルオブジェクト
１４０３ ：マップボタン
ＮＴ ：ネットワーク

Claims (21)

  1. 第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応づけて、前記ユーザ本人の許諾に基づいて管理する情報管理システムにおける情報提供方法であって、
    端末機器から前記識別情報及び前記第１レストランと系列が異なる第２レストランを示す店舗ＩＤを取得し、
    前記店舗ＩＤが示す前記第２レストランに関連するサーバからネットワークを介して、前記第２レストランのメニュー情報を取得し、
    前記識別情報に対応する前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記ユーザによる前記第２レストランでの注文履歴が所定量に満たない場合に、前記ユーザの嗜好情報を前記サーバに渡すことなく、前記情報管理システムにおいて前記ユーザ本人の許諾に基づき前記第１レストランでの注文履歴を含む前記嗜好情報が反映された順序にて前記第２レストランのメニュー情報に含まれる第１メニュー内容を配列するための順序情報を生成し、前記メニュー情報は、前記第１メニュー内容と、前記第２レストランによって指定された第２メニュー内容とを含み、
    前記順序情報と前記第２メニュー内容とを前記端末機器に送信し、前記端末機器の表示画面内の第１表示領域に、前記順序情報に基づく順序にて配列された前記第１メニュー内容を表示させ、かつ、前記表示画面内の第２表示領域に、前記第２レストランによって指定された前記第２メニュー内容を表示させる、
    情報提供方法。
  2. 前記端末機器において、
    前記第１メニュー内容の各オブジェクトが前記順序情報に基づく順序にて配列された表示情報が生成され、
    生成された前記表示情報が、前記第１メニュー内容の表示として、前記第１表示領域に表示される、
    請求項１に記載の情報提供方法。
  3. 前記表示情報の生成において、前記各オブジェクトの表示位置および表示サイズの少なくとも一方は、前記端末機器のアプリまたはブラウザにおける所定の表示画面生成ルールと、前記順序情報とに基づいて決定される、
    請求項２に記載の情報提供方法。
  4. 前記表示情報の生成において、前記各オブジェクトの表示位置および表示サイズの少なくとも一方は、前記端末機器の種類または前記端末機器の前記ユーザによる設定と、前記順序情報に含まれる一または複数のパラメータとに基づいて決定される、
    請求項２に記載の情報提供方法。
  5. 前記第２表示領域内における前記第２メニュー内容の配列が、前記第２レストランによって指定されている、
    請求項１に記載の情報提供方法。
  6. 前記第１メニュー内容は、前記嗜好情報に対応した順序が第１順序である場合には前記第１順序に配列されて前記第１表示領域に表示され、かつ、前記嗜好情報に対応した順序が前記第１順序とは異なる第２順序である場合には前記第２順序に配列されて前記第１表示領域に表示され、
    前記第２メニュー内容は、前記嗜好情報に対応した順序が前記第１順序または前記第２順序のいずれの場合でも同じ形態で前記第２表示領域に表示される、
    請求項１に記載の情報提供方法。
  7. 前記第２レストランは、前記第１レストランとは異なる系列のコーヒーショップである、
    請求項１記載の情報提供方法。
  8. 前記第２レストランは、前記第１レストランとは異なる系列のハンバーガーショップである、
    請求項１記載の情報提供方法。
  9. 前記ユーザの端末機器の位置情報を取得し、
    前記位置情報に基づき、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報を前記端末機器に提供し、
    前記店舗ＩＤは前記端末機器において前記レストラン情報に基づき選択される、
    請求項１記載の情報提供方法。
  10. 前記ユーザの端末機器の位置情報を、ＧＰＳシステムを用いて取得する、
    請求項９記載の情報提供方法。
  11. 前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴がない場合、前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記第１レストランでの注文履歴を含む前記嗜好情報が反映された順序にて、前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列するための前記順序情報を生成する、
    請求項１記載の情報提供方法。
  12. 前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴がある場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴が反映された順序にて、前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列するための前記順序情報を生成する、
    請求項１１記載の情報提供方法。
  13. 前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの注文履歴が前記所定量以上であると判定された場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴が反映された順序にて、前記第２レストランのメニュー情報に含まれる前記第１メニュー内容を配列するための前記順序情報を生成する、
    請求項１記載の情報提供方法。
  14. 第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応づけて、前記ユーザ本人の許諾に基づいて管理する情報管理システムにおける情報提供方法であって、
    端末機器から前記識別情報及び前記第１レストランと系列が異なる第２レストランを示す店舗ＩＤを取得し、
    前記店舗ＩＤが示す前記第２レストランに関連するサーバからネットワークを介して、前記第２レストランのメニュー情報を取得し、
    前記識別情報に対応する前記嗜好情報及び前記第２レストランのメニュー情報に基づき、前記ユーザによる前記第２レストランでの直近の注文履歴が所定期間より前である場合に、前記ユーザの嗜好情報を前記サーバに渡すことなく、前記情報管理システムにおいて前記ユーザ本人の許諾に基づき前記第１レストランでの注文履歴を含む前記嗜好情報が反映された順序にて前記第２レストランのメニュー情報に含まれる第１メニュー内容を配列するための順序情報を生成し、前記メニュー情報は、前記第１メニュー内容と、前記第２レストランによって指定された第２メニュー内容とを含み、
    前記順序情報と前記第２メニュー内容とを前記端末機器に送信し、前記端末機器の表示画面内の第１表示領域に、前記順序情報に基づく順序にて配列された前記第１メニュー内容を表示させ、かつ、前記表示画面内の第２表示領域に、前記第２レストランによって指定された前記第２メニュー内容を表示させる、
    情報提供方法。
  15. 前記情報管理システムにおいて、前記ユーザによる前記第２レストランでの直近の注文履歴が前記所定期間内であると判定された場合、前記第２レストランでの注文履歴及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴が反映された順序にて、前記第２レストランの前記メニュー情報に含まれる前記第１メニュー内容を配列するための前記順序情報を生成する、
    請求項１４記載の情報提供方法。
  16. 第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応づけて、前記ユーザ本人の許諾に基づいて管理する情報管理システムにおける情報提供方法であって、
    前記ユーザの端末機器の位置情報を取得し、
    前記位置情報に基づき、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報を前記端末機器に提供し、
    前記端末機器から前記識別情報及び前記一以上のレストランの中で前記第１レストランと系列が異なる第２レストランを示す店舗ＩＤを取得し、
    前記店舗ＩＤが示す前記第２レストランに関連するサーバからネットワークを介して、前記第２レストランのメニュー情報を取得し、
    前記識別情報に対応する嗜好情報及び前記第２レストランのメニュー情報に基づき、前記第２レストランでの注文履歴が所定量に満たない場合に、前記ユーザの嗜好情報を前記サーバに渡すことなく、前記情報管理システムにおいて前記ユーザ本人の許諾に基づき前記第１レストランでの注文履歴を含む前記嗜好情報が反映された順序にて前記第２レストランのメニュー情報に含まれる第１メニュー内容を配列するための順序情報を生成し、前記メニュー情報は、前記第１メニュー内容と、前記第２レストランによって指定された第２メニュー内容とを含み、
    前記順序情報と前記第２メニュー内容とを前記端末機器に送信し、前記端末機器の表示画面内の第１表示領域に、前記順序情報に基づく順序にて配列された前記第１メニュー内容を表示させ、かつ、前記表示画面内の第２表示領域に、前記第２レストランによって指定された前記第２メニュー内容を表示させる、
    情報提供方法。
  17. 第１レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応づけて、前記ユーザ本人の許諾に基づいて管理する情報管理システムにおける情報提供方法であって、
    端末機器から前記識別情報及び前記第１レストランと系列が異なる第２レストランを示す店舗ＩＤを取得し、
    前記店舗ＩＤが示す前記第２レストランに関連するサーバからネットワークを介して、前記第２レストランのメニュー情報を取得し、
    前記識別情報に対応する前記嗜好情報及び前記第２レストランのメニュー情報に基づき、設定期間内の前記第２レストランでの注文回数が閾値以下である場合に、前記ユーザの嗜好情報を前記サーバに渡すことなく、前記情報管理システムにおいて前記ユーザ本人の許諾に基づき前記第１レストランでの注文履歴を含む前記嗜好情報が反映された順序にて前記第２レストランのメニュー情報に含まれる第１メニュー内容を配列するための順序情報を生成し、前記メニュー情報は、前記第１メニュー内容と、前記第２レストランによって指定された第２メニュー内容とを含み、
    前記順序情報と前記第２メニュー内容とを前記端末機器に送信し、前記端末機器の表示画面内の第１表示領域に、前記順序情報に基づく順序にて配列された前記第１メニュー内容を表示させ、かつ、前記表示画面内の第２表示領域に、前記第２レストランによって指定された前記第２メニュー内容を表示させる、
    情報提供方法。
  18. 前記情報管理システムにおいて、前記第１レストランにて注文した前記注文履歴が前記第１レストランを示す店舗ＩＤと対応付けて記憶されている、
    請求項１記載の情報提供方法。
  19. 前記情報管理システムにおいて、前記第１レストランにて注文した前記注文履歴が前記第１レストランを示す店舗ＩＤと対応付けて記憶されている、
    請求項１６記載の情報提供方法。
  20. 前記店舗ＩＤは前記端末機器において選択される、
    請求項１記載の情報提供方法。
  21. 前記店舗ＩＤは前記端末機器において選択される、
    請求項１６記載の情報提供方法。
JP2023082509A 2021-08-04 2023-05-18 情報提供方法 Active JP7349691B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2021128609 2021-08-04
JP2021128609 2021-08-04
JP2023505426A JP7289093B1 (ja) 2021-08-04 2022-06-20 制御方法、及び、情報提供方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2023505426A Division JP7289093B1 (ja) 2021-08-04 2022-06-20 制御方法、及び、情報提供方法

Publications (2)

Publication Number Publication Date
JP2023096132A JP2023096132A (ja) 2023-07-06
JP7349691B2 true JP7349691B2 (ja) 2023-09-25

Family

ID=85155524

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2023505426A Active JP7289093B1 (ja) 2021-08-04 2022-06-20 制御方法、及び、情報提供方法
JP2023082509A Active JP7349691B2 (ja) 2021-08-04 2023-05-18 情報提供方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2023505426A Active JP7289093B1 (ja) 2021-08-04 2022-06-20 制御方法、及び、情報提供方法

Country Status (4)

Country Link
US (1) US20240054581A1 (ja)
JP (2) JP7289093B1 (ja)
CN (1) CN116529747A (ja)
WO (2) WO2023013087A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030097451A1 (en) 2001-11-16 2003-05-22 Nokia, Inc. Personal data repository
JP2003281244A (ja) 2002-03-20 2003-10-03 Axbomber:Kk 個人専用メニュー作成システム
US20100161432A1 (en) 2008-12-15 2010-06-24 Just Enjoy, Llc Patron experience management system
US20130325640A1 (en) 2012-06-04 2013-12-05 American Express Travel Related Services Company, Inc. Systems and Methods for Delivering Tailored Menu Content Based Upon a Consumer Profile
WO2021106232A1 (ja) 2019-11-27 2021-06-03 パナソニックＩｐマネジメント株式会社 制御方法、情報端末、プログラム、及び記録媒体

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003141337A (ja) * 2001-10-31 2003-05-16 Nec Corp 食生活管理システム
US9129289B2 (en) * 2005-10-03 2015-09-08 Drew Vaughn Systems and methods for providing remote ordering capabilities
JP2009070188A (ja) * 2007-09-13 2009-04-02 Ricoh Co Ltd メニュー配信システム、メニューサーバ、読書装置、方法、およびプログラム
US20130339163A1 (en) * 2012-06-18 2013-12-19 Christian Dumontet Food Recommendation Based on Order History
JP6025464B2 (ja) * 2012-09-10 2016-11-16 株式会社マイオーダー パーソナライズメニューによるセルフオーダーシステム
US20160012513A1 (en) * 2014-07-08 2016-01-14 Martinez Management, Inc. Systems and methods for food and restaurant recommendations
CN106651524A (zh) * 2016-12-27 2017-05-10 杭州火小二科技有限公司 一种智能生成推荐菜单的方法
JP6257822B1 (ja) * 2017-03-29 2018-01-10 株式会社リクルートホールディングス 情報処理システム及びプログラム
CN107862542A (zh) * 2017-09-28 2018-03-30 北京三快在线科技有限公司 一种菜品推荐方法和装置
CN109035633A (zh) * 2018-07-11 2018-12-18 上海国兆电子科技有限公司 一种基于图像识别的菜单推送方法及系统
WO2020219462A1 (en) * 2019-04-23 2020-10-29 The Mewah Corporation Methods and systems for generating restaurant recommendations
JP2020181491A (ja) * 2019-04-26 2020-11-05 ソフトバンクグループ株式会社 システム、プログラム、及び方法
US20210073768A1 (en) * 2019-09-11 2021-03-11 Toast, Inc. Multichannel apparatus and method for patron identification
JP2021106232A (ja) 2019-12-26 2021-07-26 パナソニックＩｐマネジメント株式会社 部品圧着装置及び部品圧着方法
CN114730447A (zh) * 2020-02-10 2022-07-08 松下知识产权经营株式会社 信息提供方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030097451A1 (en) 2001-11-16 2003-05-22 Nokia, Inc. Personal data repository
JP2003281244A (ja) 2002-03-20 2003-10-03 Axbomber:Kk 個人専用メニュー作成システム
US20100161432A1 (en) 2008-12-15 2010-06-24 Just Enjoy, Llc Patron experience management system
US20130325640A1 (en) 2012-06-04 2013-12-05 American Express Travel Related Services Company, Inc. Systems and Methods for Delivering Tailored Menu Content Based Upon a Consumer Profile
WO2021106232A1 (ja) 2019-11-27 2021-06-03 パナソニックＩｐマネジメント株式会社 制御方法、情報端末、プログラム、及び記録媒体

Also Published As

Publication number Publication date
CN116529747A (zh) 2023-08-01
WO2023013263A1 (ja) 2023-02-09
JP2023096132A (ja) 2023-07-06
JP7289093B1 (ja) 2023-06-09
US20240054581A1 (en) 2024-02-15
WO2023013087A1 (ja) 2023-02-09
JPWO2023013263A1 (ja) 2023-02-09

Similar Documents

Publication Publication Date Title
JP7142305B2 (ja) 情報提供方法
US12094016B2 (en) Method, information terminal, and non-transitory computer-readable recording medium
US12094015B2 (en) Method, information terminal, and non-transitory computer-readable recording medium
JP7349691B2 (ja) 情報提供方法
JP7203402B1 (ja) 情報提供方法
JP7296564B1 (ja) 情報提供方法
JP7113345B2 (ja) 制御方法、通信端末、プログラム、記憶媒体及び情報提供方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230519

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20230519

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230822

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230904

R151 Written notification of patent or utility model registration

Ref document number: 7349691

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151