(本開示に至る経緯)
近年、外食産業の発達により、例えば、ファミリーレストラン、ハンバーガーショップ、コーヒーショップ、中華レストラン等の飲食品を提供する様々なチェーンストアが全国規模で展開されている。同一系列のチェーンストアであれば、異なる店舗であってもメニュー表は同じであることが多い。そのため、はじめて来店した店舗が、ユーザの行きつけのチェーンストアの店舗であれば、ユーザは見慣れたメニュー表を参照して効率よく飲食品の注文を行うことができる。
しかしながら、利用したことのないチェーンストアが運営する店舗にユーザがはじめて来店した場合、ユーザは見慣れていないメニュー表を参照して飲食品を注文することになり、注文に手間がかかってしまう。
上述の特許文献1の技術では、注文履歴データベースからユーザの注文履歴に関する情報が取得され、その注文履歴に関する情報に基づいてユーザに提案する注文案が生成されている。しかしながら、特許文献1の技術では、ユーザが来店している店舗における注文履歴のみを用いて注文案が作成されている。したがって、特許文献1の技術では、ユーザが店舗に例えば初めて来店した場合、その店舗の注文履歴がないため、注文案の生成ができなくなる。そのため、特許文献1の技術では、上述の手間を解消することはできない。
ここで、注文案の生成ができなかった場合に、店舗において一般客に用いられる汎用メニューを携帯端末に通知することが考えられる。しかしながら、携帯端末は表示面積に制約があるため、ユーザが関心のない飲食品が優先的に表示される可能性がある。この場合、ユーザはスクロール操作等により希望する飲食品を探し出すことが要求され、注文に手間がかかってしまう。
本開示は、このような課題を解決するためになされたものであり、表示面積に制約がある端末機器において効率的に自己の嗜好に合った飲食品を選択することが可能な技術を提供することである。
(1-1)本開示の一態様における情報提供方法は、第1レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する情報管理システムにおける情報提供方法であって、端末機器から前記識別情報及び前記第1レストランと系列が異なる第2レストランを示す店舗IDを取得し、前記識別情報に対応する前記嗜好情報、及び前記店舗IDが示す前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列し、前記メニュー情報は、前記端末機器から前記店舗IDが取得される前に、前記店舗IDが示す前記第2レストランに関連するサーバからネットワークを介して取得されて前記情報管理システムに管理され、前記順序にて配列されたメニュー内容のメニュー情報を前記端末機器に送信し、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報を表示させる。
本態様によると、第1レストランにて注文した注文履歴を含むユーザの嗜好情報が、前記ユーザを特定する識別情報と対応して情報管理システムにおいて管理されている。前記ユーザが利用する端末機器から前記第1レストランと異なる第2レストランを示す店舗IDが取得される。そして、ユーザの嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容が配列され、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報が表示される。
このことにより、ユーザは、例え前記第2レストランを初めて利用する場合であっても、それまで利用したことがある前記第1レストランでの注文履歴などを含む嗜好情報に基づいて、表示面積に制約がある前記端末機器の表示画面において、前記嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を優先的に表示できる。
従って、ユーザは、例え前記第2レストランを初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
さらに、メニュー情報は、端末機器から店舗IDが取得される前に、店舗IDが示す第2レストランに関連するサーバからネットワークを介して取得されて情報管理システムに管理されているので、情報管理システムは店舗IDを取得すると速やかにメニュー情報を端末機器に送信できる。
(1-2)上記情報提供方法において、前記第2レストランは、前記第1レストランとは異なる系列のコーヒーショッブであってもよい。
本態様によれば、ある系列のコーヒーショップにおいて、別の系列のコーヒーショップの注文履歴を含む嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報が表示される。そのため、例えば、ある系列のコーヒーショップを初めて利用する場合であっても、ユーザは効率的に自己の嗜好に合った飲食品を選択できる。
(1-3)上記情報提供方法において、前記第2レストランは、前記第1レストランとは異なる系列のハンバーガーショッブであってもよい。
本態様によれば、ある系列のハンバーガーショップにおいて、別の系列のハンバーガーショップの注文履歴を含む嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報が表示される。そのため、例えば、ある系列のハンバーガーショップを初めて利用する場合であっても、ユーザは効率的に自己の嗜好に合った飲食品を選択できる。
(1-4)上記情報提供方法において、前記ユーザの端末機器の位置情報を取得し、前記位置情報に基づき、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報を前記端末機器に提供し、前記店舗IDは前記端末機器において前記レストラン情報に基づき選択されてもよい。
本態様によれば、ユーザが居る地点の周囲に存在するレストランの中から希望のレストランをユーザは選択できる。そして、選択したレストランにおけるメニュー情報がユーザの嗜好情報に対応する順序でメニュー内容が配列されて表示される。そのため、選択したレストランが例えば初めて利用するレストランであっても、ユーザは効率的に自己の嗜好にあった飲食品を選択できる。
(1-5)上記情報提供方法において、前記ユーザの端末機器の位置情報を、GPSシステムを用いて取得してもよい。
本態様によれば、GPSシステムを用いて端末機器の位置情報が取得されるため、ユーザの位置を正確に特定し、ユーザの周囲に存在するレストランをユーザに提示できる。
(1-6)上記情報提供方法において、前記情報管理システムにて、前記ユーザによる前記第2レストランでの注文履歴がない場合、前記識別情報に対応する嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
本態様によれば、第2レストランにおいてユーザの注文履歴がない場合、第1レストランの注文履歴を含む嗜好情報に基づいたメニュー情報が表示される。これにより、ユーザは、第2レストランの系列が初めて利用する系列である場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
(1-7)上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第2レストランでの注文履歴がある場合、前記第2レストランでの注文履歴及び前記第2レストランのメニュー情報に基づき、前記第2レストランでの注文履歴に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
第2レストランが初めて利用するレストランではない場合、第1レストランの注文履歴を含む嗜好情報よりも第2レストランの注文履歴に基づいてメニュー情報を生成した方がユーザにとって都合がよい場合がある。本態様によれば、第2レストランにおいてユーザの注文履歴がある場合、第2レストランの注文履歴を含む嗜好情報に対応する順序にてメニュー内容が配列されたメニュー情報が表示される。したがって、ユーザは、第2レストランを過去に利用したことがある場合、第2レストランの注文履歴が反映されたメニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
(1-8)上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第2レストランでの注文履歴が所定量に満たない場合、前記識別情報に対応する嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
第2レストランを利用するのが初めてではない場合であっても利用回数が少なければ、第2レストランの注文履歴に基づいてユーザのメニュー情報を生成すると、ユーザの嗜好が十分に反映されたメニュー情報が生成できない可能性がある。本態様によれば、第2レストランでの注文履歴が所定量に満たない場合、第2レストランでの注文履歴だけでなく、他のレストランの注文履歴も含む嗜好情報に基づいてメニュー内容が配列されたメニュー情報が表示される。そのため、第2レストランにおいて、ユーザの嗜好が十分に反映されていないメニュー情報が表示されることを防止できる。
(1-9)上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第2レストランでの注文履歴が前記所定量以上である場合、前記第2レストランでの注文履歴及び前記第2レストランのメニュー情報に基づき、前記第2レストランでの注文履歴に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
第2レストランをある程度利用している場合、第1レストランの注文履歴を含む嗜好情報よりも第2レストランの注文履歴に基づいてメニュー情報を生成した方がユーザにとって都合がよい場合がある。本態様によれば、第2レストランでの注文履歴が所定量以上の場合、第2レストランの注文履歴に基づいてメニュー内容が配列されたメニュー情報が表示される。したがって、ユーザは、第2レストランをある程度利用したことがある場合、第2レストランの注文履歴が反映されたメニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
(1-10)上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第2レストランでの直近の注文履歴が所定期間より前である場合、前記識別情報に対応する嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
第2レストランの利用が初めてではない場合であっても、久しく利用していない場合、例えば利用していない期間にユーザの嗜好が変化するというようなケースも想定され、第2レストランのメニュー情報の表示が妥当でないこともある。本態様によれば、このような場合において、第1レストランの注文履歴を含む嗜好情報が反映されたメニュー情報が表示されるため、ユーザは自己の嗜好に合った飲食品を効率よく選択できる。
(1-11)上記情報提供方法では、前記情報管理システムにおいて、前記ユーザによる前記第2レストランでの直近の注文履歴が前記所定期間内である場合、前記第2レストランでの注文履歴及び前記第2レストランのメニュー情報に基づき、前記第2レストランでの注文履歴に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
第2レストランの利用が初めてではなく、久しぶりに利用するものでもない場合、第1レストランの注文履歴に基づく嗜好情報よりも第2レストランの注文履歴が反映されたメニュー情報を表示した方がユーザにとって都合がよいこともある。本態様では、このような場合において、第2レストランの注文履歴が反映されたメニュー情報が表示されるため、ユーザは自己の嗜好に合った飲食品を効率よく選択できる。
(1-12)本開示の別の一態様における情報提供方法は、第1レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する情報管理システムにおける情報提供方法であって、前記ユーザの端末機器の位置情報を取得し、前記位置情報に基づき、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報を前記端末機器に提供し、前記端末機器から前記識別情報及び前記一以上のレストランの中で前記第1レストランと系列が異なる第2レストランを示す店舗IDを取得し、前記識別情報に対応する嗜好情報及び前記店舗IDが示す前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列し、前記メニュー情報は、前記端末機器から前記店舗IDが取得される前に、前記店舗IDが示す前記第2レストランに関連するサーバからネットワークを介して取得されて前記情報管理システムに管理され、前記順序にて配列されたメニュー内容のメニュー情報を前記端末機器に送信し、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報を表示させる。
本態様によると、第1レストランにて注文した注文履歴を含むユーザの嗜好情報が、前記ユーザを特定する識別情報と対応して情報管理システムにおいて管理されている。ユーザの端末機器の位置情報に基づき、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報が提供される。前記端末機器から前記一以上のレストランの中で前記第1レストランと系列の異なる第2レストランを示す店舗IDが取得される。そして、ユーザの嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容が配列され、前記端末機器の表示画面において前記順序にて配列されたメニュー内容のメニュー情報が表示される。
このことにより、ユーザは、例え前記第2レストランを未だ利用したことがない場合であっても、それまで利用したことがある前記第1レストランでの注文履歴などを含む嗜好情報に基づいて、表示面積に制約がある前記端末機器の表示画面において、前記嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を優先的に表示できる。
従って、ユーザは、例え前記第2レストランを未だ利用したことがない場合であっても、効率的に自己の嗜好に合ったメニューがあるかを確認して選択できる。
(1-13)上記情報提供方法において、設定期間内の前記第2レストランでの注文回数が一定以下である場合、前記嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列してもよい。
本態様によれば、第2レストランでの注文回数が一定回数以下である場合、第2レストランでの注文履歴だけでなく、他のレストランの注文履歴も含む嗜好情報に基づいてメニュー内容が配列されたメニュー情報が表示される。そのため、第2レストランにおいて、ユーザの嗜好が十分に反映されていないメニュー情報が表示されることを防止できる。
(1-14)上記情報提供方法において、設定期間内の前記第2レストランでの注文回数が一定以下である場合、前記嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列してもよい。
(1-15)上記(1-1)の情報提供方法では、前記情報管理システムにおいて、前記第1レストランにて注文した前記注文履歴が前記第1レストランを示す店舗IDと対応付けて記憶されていてもよい。
本態様によれば、第1レストランにて注文した注文履歴が第1レストランを示す店舗IDと対応付けて記憶されている。このため、第1レストランを示す店舗IDを用いることにより、第1レストランにて注文した注文履歴を参照することが容易になる。
(1-16)上記(1-12)の情報提供方法では、前記情報管理システムにおいて、前記第1レストランにて注文した前記注文履歴が前記第1レストランを示す店舗IDと対応付けて記憶されていてもよい。
(1-17)上記(1-1)の情報提供方法において、前記店舗IDは前記端末機器において選択されてもよい。
(1-18)上記(1-12)の情報提供方法において、前記店舗IDは前記端末機器において選択されてもよい。
本態様によれば、ユーザは端末機器において店舗IDを選択できる。
(2-1)本開示の一態様における制御方法は、第1レストランにて注文した注文履歴を含むユーザの嗜好情報を、前記ユーザを特定する識別情報と対応して管理する第1サーバとネットワークを介して通信する端末機器の制御方法であって、前記識別情報及び前記第1レストランと系列が異なる第2レストランを示す店舗IDの選択を、前記端末機器の入力デバイスを介して受け付け、前記識別情報に対応する嗜好情報を前記第1サーバから取得し、前記店舗IDが示す前記第2レストランに関連する第2サーバから、前記第2レストランのメニュー情報を取得し、前記第2レストランのメニュー情報は前記店舗IDの選択を受け付ける前に前記第2サーバから取得され、前記嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列し、前記順序にて配列されたメニュー内容のメニュー情報を、前記端末機器の表示画面において表示する。
本態様によれば、メニュー内容の配列が端末機器で行われる態様においても、(1-1)と同様の効果が得られる。さらに、本態様によると、第2レストランのメニュー情報は第2サーバから取得されているものの、嗜好情報は第1サーバから取得されている。これにより、ユーザの許諾がない事業者に対して嗜好情報が渡らないようにしながらも、ユーザが初めて利用する第2レストランにおいて、ユーザの嗜好情報が考慮されたメニュー情報を表示できる。
(2-2)上記制御方法において、前記第2レストランは、前記第1レストランとは異なる系列のコーヒーショップであってもよい。
(2-3)上記制御方法において、前記第2レストランは、前記第1レストランとは異なる系列のハンバーガーショップであってもよい。
(2-4)上記制御方法において、ネットワークを介して前記第1レストラン及び前記第2レストランに関連する情報を管理する第3サーバに、前記ユーザの端末機器の位置情報を出力し、前記位置情報に基づき前記第3サーバから、前記位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報を取得し、前記レストラン情報に基づき前記店舗IDの選択を受け付けてもよい。
(2-5)上記制御方法において、前記ユーザの端末機器の位置情報は、GPSシステムを用いて取得されてもよい。
(2-6)上記制御方法において、前記第1サーバから、前記ユーザによる前記第2レストランでの注文履歴を示す注文履歴情報を取得し、前記ユーザによる前記第2レストランでの注文履歴がない場合、前記嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
(2-7)上記制御方法において、前記ユーザによる前記第2レストランでの注文履歴がある場合、前記第2レストランでの注文履歴及び前記第2レストランのメニュー情報に基づき、前記第2レストランでの注文履歴に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
(2-8)上記制御方法において、前記第1サーバから、前記ユーザによる前記第2レストランでの注文履歴を示す注文履歴情報を取得し、前記ユーザによる前記第2レストランでの注文履歴が所定量に満たない場合、前記嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
(2-9)上記制御方法において、前記ユーザによる前記第2レストランでの注文履歴が前記所定量以上である場合、前記第2レストランでの注文履歴及び前記第2レストランのメニュー情報に基づき、前記第2レストランでの注文履歴に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
(2-10)上記制御方法において、前記第1サーバから、前記ユーザによる前記第2レストランでの注文履歴を示す注文履歴情報を取得し、前記ユーザによる前記第2レストランでの直近の注文履歴が所定期間より前である場合、前記嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
(2-11)上記制御方法において、前記ユーザによる前記第2レストランでの直近の注文履歴が前記所定期間内である場合、前記第2レストランでの注文履歴及び前記第2レストランのメニュー情報に基づき、前記第2レストランでの注文履歴に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を配列してもよい。
(2-12)上記制御方法において、前記第1サーバから、前記ユーザによる前記第2レストランでの注文履歴を示す注文履歴情報を取得し、設定期間内の前記第2レストランでの注文回数が一定回数以下である場合、前記嗜好情報及び前記第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記メニュー情報に含まれるメニュー内容を配列してもよい。
(2-13)上記制御方法において、前記第1サーバにて、前記第1レストランにて注文した前記注文履歴が前記第1レストランを示す店舗IDと対応付けて記憶されていてもよい。
(2-14)本開示の別の一態様における端末機器は、(2-1)~(2-12)のいずれかの制御方法を実行する。
(2-15)本開示の別の一態様におけるプログラムは、(2-1)~(2-13)ののいずれかの制御方法を前記端末機器のコンピュータに実行させる。
(2-16)上記プログラムにおいて、前記ユーザを特定する識別情報は、前記プログラムに付与された情報端末毎のシリアルコードを含んでもよい。
本態様によれば、プログラムに付与された情報端末毎のシリアルコードが識別情報として用いられているため、人が見て無意味な文字列情報を識別情報として設定することができ、秘匿性がより高められた個人情報の通信が可能となる。
(2-17)本開示の別の一態様における記録媒体は、(2-1)~(2-13)のいずれかの制御方法を端末機器のコンピュータに実行させるためのプログラムを記録したものである。
(実施の形態1)
我々の社会は、今後もさらにインターネットが普及し、各種センサーが身近になることが予想される。これにより、我々の社会は、個人の状態及び活動等に関する情報から建造物及び交通網等を含む街全体の情報までもがデジタル化されて、コンピューターシステムで利用できる状態になっていくと予想される。デジタル化された個人に関するデータ(個人情報)は、通信ネットワークを介してクラウドに蓄積され、ビッグデータとして本人許諾に基づき第三者もアクセスできる仕組みを持つ情報銀行に管理され、個人や社会のために様々な用途に利用されていくことが期待される。
このような高度情報化社会は、日本ではSociety5.0と呼ばれる。高度情報化社会は、現実空間(フィジカル空間)と仮想空間(サイバー空間)とを高度に融合させた情報基盤(サイバーフィジカルシステム)により、経済発展と社会的課題の解決とが期待される社会である。
そうした高度情報化社会では、個人が日常の様々なシーンで意思決定を行う際に、蓄積された個人情報を含むビッグデータを分析して、その時の状況に応じた、その個人にとって最適と思われる選択肢を、その個人が知ることが可能になる。
以降では、そのようなサイバーフィジカルシステムが稼働する高度情報化社会において、個人の食事をテーマとして、経済効率化と個人最適化(パーソナライゼーション)とを実施する様態について説明していく。
Society5.0では、ユーザの嗜好を示す嗜好情報のような個人情報は、情報銀行と称される個人情報を管理する事業者のサーバによって、本人許諾のない第三者にはアクセスできないように暗号化、秘匿化された上で一元管理される。これらの個人情報の多くはユーザの意識的な入力操作を必要とせず、情報銀行の管理の下、収集が継続され随時更新される。
個人最適化された飲食品の注文システムの一例としては、レストランのサーバから個人の情報端末にメニュー情報を送信し、ユーザの嗜好に即した飲食品からなるメニューを推奨メニューとして情報端末上に提示するものが考えられる。
図1は、本開示の情報提供システムの全体像の一例を示す図である。図1の情報提供システムは、Society5.0を踏まえて構成されたシステムであり、個人情報を利用する一消費者であるユーザに適した商品又はサービスをユーザに提案し、商品又はサービスのユーザによる選択を支援する選択支援サービスを提供するシステムである。本実施の形態では選択支援サービスとして飲食品の注文を支援するサービスを主眼としている。具体的には情報提供システムは、外食時にユーザが飲食品を注文するために閲覧するメニュー情報を、そのユーザの個人情報とマッチングさせ、そのユーザにとって最適なメニューを提示するシステムである。
この情報提供システムは大きく3つの機器群から構成される。1つ目の機器群はユーザが保有するスマートフォン等の情報端末100(端末機器の一例)を含む機器群である。情報端末100にはマッチングアプリケーションがインストールされている。マッチングアプリケーション(以下、マッチングアプリと称する。)は、ユーザに適した商品又はサービスを、そのユーザの個人情報を用いて選別又は推薦するためのアプリケーションである。ここで言う個人情報とは、個人に関する公開又は非公開の情報が広く包含される。例えば、個人情報は、氏名、生年月日、住所、年収、所有する動産/不動産情報、身長/体重等の身体情報、遺伝子情報、アレルギー情報、病歴/診断カルテ等の医療情報、歩数/消費カロリーなどの活動量情報、食事履歴情報、心拍/血圧等のバイタルサイン情報、店舗/ECサイトなどを介した購買情報、Web検索エンジン/AIスピーカーで検索した単語情報、メール/SNSで送受信された文章/映像音声情報、並びに移動履歴情報等のうちの少なくとも一つを含む。情報端末100は、例えば、4G、5Gと称される移動体通信網により携帯基地局400を介して、インターネットに接続可能である。
2つ目の機器群は第1サーバ200を含む機器群である。
第1サーバ200は、ユーザの個人情報を複数箇所に分散し、分散した個人情報をさらに暗号化して記憶する個人情報サーバである。例えば、第1サーバ200は、クラウド上にある複数のストレージ装置にユーザの個人情報を断片化及び暗号化して記憶することで個人情報を管理する。これにより、高いセキュリティが確保され、個人情報の漏洩等が防止される。さらに、第1サーバ200は、第三者からの問い合わせに応じて必要なデータをユーザ本人の許諾に応じて返信する機能を持つ。さらに、第1サーバ200は、ユーザが許諾した事業者に対してユーザが許諾した個人情報をセキュアに共有する機能を持つ。すなわち、第1サーバ200は情報銀行としての機能を持つ。この場合、第1サーバ200は、例えば1つのデータを複数のストレージ装置に分散して記録する。1つのデータの一例は個人情報を記録した1つのファイルである。
本実施の形態では、第1サーバ200は、ユーザの許諾に基づき、特定の事業者に対して特定の個人情報を共有させる。さらに、第1サーバ200は、以下で説明する選択支援サービスを提供するための機能を持つ。
上述のマッチングアプリは、例えば第1サーバ200の運営会社によって開発及び/または配布される。この運営会社はユーザが利用する可能性のある商品又はサービスに対するユーザの適合度合いを、ユーザの個人情報を用いて評価する。第1サーバ200の運営会社、マッチングアプリの開発会社、及びマッチングアプリの配布会社は、それぞれ同一であってもよいし、異なっていてもよい。図1に示す情報提供システムは、上述したマッチングアプリを用いて選択支援サービスを実現するが、これは一例である。例えば、マッチングアプリ以外のアプリ又は一般的なブラウザ等を用いて選択支援サービスを実現してもよい。ユーザの個人情報をセキュアに扱うためには、マッチングアプリ等の専用のアプリによって選択支援サービスを提供することが好ましい。但し、これは一例であり、例えば公開されている個人情報などのセキュリティの重要度が低い個人情報を扱う場合、又はインターネットブラウザを用いてHTTPS通信のようにセキュリティを確保するための機能が提供される場合は、マッチングアプリ以外の手段で選択支援サービスが提供されてもよい。
マッチングアプリは、情報端末100の内部でのみ個人情報を取り扱う。マッチングアプリは、時間、場所、及び状況等の任意の条件下において、ユーザに最も適すると思われる商品又はサービスをユーザに提示する。例えば、マッチングアプリは、ユーザの購買等の経済活動における仲介斡旋機能を提供する。
マッチングアプリは、これまでサービス事業者ごとにサイロ化されていたリコメンド機能をオープンに開放したアプリである。例えば、ECサイト等の電子商取引市場で有名なある1つのサービス事業者の例で説明する。当該サービス事業者のサイトには数多くの商品が掲載されている。特定の商品が検索又は購入されると、その商品と関連性が高い他の商品(例えば、よく一緒に購入される商品)がユーザに推薦される。このような購買に対するリコメンド機能は、当該サービス事業者のECサイトの中でしか有効にならない。したがって、当該リコメンド機能は、他のサービス事業者が運営するECサイトにおいて商品を購入する時、レストランで食事を注文する時、又は休暇の家族旅行を計画する時において、何ら効果を発揮しない。
今後、情報銀行に個人情報が集約され、膨大かつ多種多様で長期間に渡る正確な個人情報が所定の条件下で誰でもアクセスできる仕組みが整うことが予想されている。この場合、ある1つのサービス事業者のECサイトにおける検索又は購入履歴、及び様々なユーザの個人情報を用いて、当該サービス事業者の商品だけなく、あらゆる商品又はサービスを対象として適合度合いを推定することが可能となる。これにより、様々な選択肢の中からユーザにとってより価値の高い商品又はサービスを推薦することが可能となる。
本実施の形態が想定する第1サーバ200は、上記のような思想又は機能を実現するために、個人情報を分散化及び暗号化してストレージ装置に記憶し、外部との個人情報のアクセスを管理、制御するクラウドサーバである。
3つ目の機器群は、各事業者が各事業者固有のデータを管理する第2サーバ300を含む機器群である。各事業者は、第2サーバ300を所有又はレンタルし、自社の商品及び/又は自社のサービスに関する情報を管理及び/又は提供している。本実施の形態では、事業者として、チェーンストアを運営する会社が該当する。図1の例では、レストランA系列が運用する第2サーバ300、レストランB系列が運用する第2サーバ300、及びレストランC系列が運用する第2サーバ300の3つの第2サーバ300が例示されている。レストランA系列は、例えば、A社が経営するA系列のチェーンストアであり、レストランB系列は、例えば、B社が経営するB系列のチェーンストアであり、レストランC系列は、例えば、C社が経営するC系列のチェーンストアである。チェーンストアは、ブランド、経営方針、サービスの内容、及び外観などに統一性を持たせ、多数の店舗の運営や管理を行う経営形態を指す。チェーンストアが展開するレストランとしては、ファミリーレストラン、コーヒーショップ及びハンバーガーショップなどが含まれる。なお、事業者は、お弁当屋又はファストフード店のように調理済み料理のテイクアウトが可能な中食事業者であってもよい。さらに、事業者は、スーパーマーケットのように自宅で調理することを主眼においた内食向けの食材販売を行う事業者であってもよい。第2サーバ300は例えばクラウドサーバで構成される。
図1の例では、レストランA系列、レストランB系列、レストランC系列はそれぞれ異なる会社が経営するものとして説明したが、これは一例であり、同一の会社が経営してもよい。また、図1の例では、第2サーバ300は3つとして説明したが、これは一例であり、4つ以上であってもよいし、1つ又は2つであってもよい。
本実施の形態の情報提供システムの効果の1つとしては、個人情報が不特定多数の事業者に渡らないことが挙げられる。第1サーバ200の情報銀行が、本人許諾に基づき、特定の事業者に対してのみ、特定の個人情報を共有することが許可されているためである。
しかしながら、この運用を個々にユーザに判断させるのはとても面倒である。データ運用ポリシーを定める信託業者がいても、具体的にどのデータが誰に渡ったのかをユーザは把握できず、ユーザは不安に感じる可能性がある。
そこで、本実施の形態は、第1サーバ200を運営している事業者が、保管している個人情報を利用すること、例えば、暗号を解き解釈することを、ユーザの許諾が無い限り、禁止又は制限してもよい。
さらに、プライバシーに厳密な運営ポリシーの下で、個人情報の管理及びマッチングアプリを提供する情報銀行又は情報仲介業者が市場に参入している場合、ユーザは当該情報銀行又は情報仲介業者との間でそのサービスの提供を受ける契約を結んでもよい。これにより、本人許諾がない事業者に対して個人情報が渡らないようにすることが可能となる。
本実施の形態の情報提供システムは、本人以外の第三者にセンシティブな情報を含む個人情報が知られる可能性を低減し、時々刻々と変化する膨大な個人情報を様々なサービスとのマッチングのために本人許諾のもとに利用することができる次世代情報社会の運用システムの一形態である。以降、この想定の下で情報提供システムを説明する。
図1に示す情報提供システムは、さらに生体センサー600及びパブリック情報サーバ500を含んでいる。
パブリック情報サーバ500は、レストランに関する情報及び個人情報とは異なる公共情報を管理する。パブリック情報サーバ500はインターネットに接続されている。例えば、公共情報には、地図情報、天気情報、及び交通情報などが含まれる。これらの情報はマッチングにおいて必要があれば、適宜利用される。
生体センサー600は、スマートウォッチなどの生体センサーである。生体センサー600は、情報端末100を所有するユーザにより装着されている。生体センサー600は、継続的にユーザのバイタルサイン情報及び/又は活動量情報を計測する。生体センサー600が計測した各種のバイタルサイン情報及び/又は活動量情報は、Bluetooth(登録商標)のような近距離通信によって、生体センサー600から情報端末100に送信される。バイタルサイン情報及び/又は活動量情報は、情報端末100にインストールされたセンサーアプリによって、保管及び/又は管理される。センサーアプリは、収集したバイタルサイン情報及び/又は活動量情報とその測定時刻を示す時刻情報とを、ユーザアカウント情報にしたがって第1サーバ200へアップロードする。これによりバイタルサイン情報及び/又は活動量情報が蓄積される。
センサーアプリは、保管及び/又は管理するデータに対するアクセス権をマッチングアプリ又は情報端末100のOS(Operating system)に付与してもよい。この場合、バイタルサイン情報及び/又は活動量情報はマッチングアプリ又はOSを介して、第1サーバ200へアップロードされる。センサーアプリは、バイタルサイン情報及び/又は活動量情報を、情報端末100のメモリに保管してもよいし、第1サーバ200にアップロードすることによって保管してもよい。
図2は、本実施の形態に係る情報提供システムの具体的な構成の一例を示す図である。図2に示す情報提供システムは、図1で説明した情報端末100、第1サーバ200、及び第2サーバ300を含む。なお、図2においては、携帯基地局400、生体センサー600の図示は説明の便宜上省かれている。情報端末100、第1サーバ200、及び第2サーバ300はネットワークNTを介して相互に通信可能に接続されている。ネットワークNTは携帯電話通信網及びインターネットを含む広域通信網である。
情報端末100は、スマートフォン又はタブレット端末等の携帯型の情報処理装置で構成されている。本実施の形態において、情報端末100は、レストラン系列の店舗で飲食品を注文するユーザによって携帯される。情報端末100は、通信部101、メモリ102、カメラ103、演算部104、ディスプレイ105、操作部106、及びGPS(Global Positioning System)センサー107を含む。
通信部101は、情報端末100をネットワークNTに接続する通信回路で構成されている。通信部101は、ユーザが操作部106を操作して選択した第1レストランとは系列の異なる第2レストランの店舗IDをユーザの識別情報と対応付けて第1サーバ200に送信する。第1レストランは、ユーザの行きつけのレストランチェーンのレストランである。第2レストランとは、第1レストランとは系列が異なるレストランである。
通信部101は、第2サーバ300から送信された後述するメニュー情報を受信する。演算部104は通信部101が受信したメニュー情報をディスプレイ105に表示させる。通信部101は、演算部104の制御の下、ユーザが注文した飲食品を示す注文情報を第2サーバ300に送信する。メモリ102は、フラッシュメモリ等の不揮発性のストレージ装置で構成されている。通信部101は、GPSセンサー107が検出した情報端末100の地点の周辺地域の地図情報である周辺地図情報を受信する。この周辺地図情報はディスプレイ105に表示される。
メモリ102は、ユーザを特定するための識別情報を予め記憶する。
カメラ103は、CMOSセンサー等で構成される撮像装置である。カメラ103は、例えば顔認証を行う際にユーザの顔を撮影するために用いられる。
演算部104は、CPU等のプロセッサで構成されている。演算部104は、情報端末100のOS、上述のマッチングアプリ、及びブラウザ等を実行する。GPSセンサー107は、GPS衛生からの信号に基づいて情報端末100の位置を検出する。
ディスプレイ105は、例えば液晶表示パネルまたは有機ELパネル等で構成され、種々の画像を表示する。例えば、ディスプレイ105は、上述のメニュー情報を表示する。さらに、ディスプレイ105は、周辺地図情報を表示する。
操作部106は、例えばタッチパネル等の入力装置で構成される。操作部106は、周辺地図情報に表示されたレストランのうち、ユーザが来店を希望するレストランを選択する操作を受け付ける。操作部106は、メニュー情報の中からユーザが希望する飲食品を選択する指示を受け付ける。
以上が情報端末100の構成である。
次に、第1サーバ200の構成について説明する。第1サーバ200は、通信部201、演算部202、及びメモリ203を含む。通信部201は、第1サーバ200をネットワークNTに接続するための通信回路で構成されている。通信部201は、情報端末100から情報端末100のユーザを特定する識別情報及び第1レストランと系列が異なる第2レストランを示す店舗IDを受信する。この店舗IDは、情報端末100を操作するユーザが選択した店舗の識別情報である。通信部201は、演算部202が生成した後述する個別メニュー情報を第2レストランを選択したユーザの情報端末100に送信する。
演算部202はCPU等のプロセッサで構成されている。演算部202は、メモリ203が記憶するユーザの個人情報を処理する。
演算部202は、第2レストランを選択したユーザの情報端末100の周辺に存在する1以上のレストランを表す店舗情報を情報端末100に提供する。情報端末100のユーザはこの提供された店舗情報から第2レストランを選択することになる。この選択により情報端末100からユーザが選択した第2レストランの店舗IDとユーザの識別情報とが第1サーバ200に送信される。
演算部202は、情報端末100から店舗IDと対応付けて送信されたユーザの識別情報に対応する嗜好情報をメモリ203から抽出する。演算部202は、抽出した嗜好情報及び店舗IDが示す第2レストランのメニュー情報に基づき、嗜好情報に対応した順序にてメニュー内容が配列されたメニュー情報である個別メニュー情報を生成する。この個別メニュー情報は、店舗を選択したユーザの情報端末100のディスプレイ105に表示される。第2レストランのメニュー情報は、第2レストランが属する系列において一般の顧客向けに生成された標準メニュー情報である。この標準メニュー情報には、第2レストランが属する系列が定めた所定の順序にてメニュー内容が配列されている。メニュー内容とは、第2レストランが提供する飲食品のことを指す。
ここで、演算部202は、第2レストランを選択したユーザによる第2レストランでの注文履歴がない場合、メモリ203から抽出した嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第2レストランが属する系列を初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
一方、演算部202は、第2レストランを選択したユーザによる第2レストランでの注文履歴がある場合、第2レストランでの注文履歴及び第2レストランの標準メニュー情報に基づき、第2レストランでの注文履歴に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第2レストランを過去に利用したことがある場合、第2レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
なお、演算部202は、第2レストランを選択したユーザによる第2レストランでの注文履歴が所定量に満たない場合、当該ユーザの識別情報に対応する嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。
この場合、演算部202は、第2レストランを選択したユーザによる第2レストランでの注文履歴が所定量以上である場合、第2レストランでの注文履歴及び第2レストランの標準メニュー情報に基づき、第2レストランでの注文履歴に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。
さらに、演算部202は、第2レストランを選択したユーザによる第2レストランでの直近の注文履歴が所定期間より前である場合、当該ユーザの識別情報に対応する嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。
演算部202は、例えば、通信部201が、許諾ユーザについての個人情報の取得を要求する信号を受信したとする。許諾ユーザとは、情報端末100又は第2サーバ300から要求された第1サーバ200に記憶された個人情報の読み出しを、直接的に許可したユーザ又は信託した第三者を経由して間接的に許諾したユーザである。この場合、演算部202は、情報端末100又は第2サーバ300からの要求に応じて、メモリ203に記憶されている許諾ユーザの個人情報を読み出して通信部201に返信させる。なお、読み出される個人情報は、管理されている個人情報の全体であってもよいし、又は、管理されている個人情報のうち、要求された特定項目に関連する情報だけ(個人情報の一部のみ)であってもよい。
メモリ203は、ハードディスクドライブ等の不揮発性の複数のストレージ装置で構成されている。メモリ203は、1以上のユーザの個人情報を記憶する。個人情報には各ユーザの嗜好情報が含まれる。嗜好情報は、各ユーザの飲食物に対する嗜好を示す情報である。嗜好情報には、各ユーザの飲食品の注文履歴、購入履歴、検索履歴、嗜好予測値(協調フィルタリングなどを用いた嗜好の予測情報)などが含まれてもよい。本実施の形態では、嗜好情報のことを端的に注文履歴として表現することもある。嗜好情報(注文履歴)はユーザ毎に生成された図12に示す注文履歴データベースD2によって管理され、メモリ203に記憶されている。
行動履歴情報は、各ユーザの行動履歴を示す情報である。個人情報は、複数のストレージ装置において分散化及び暗号化された上で記憶される。メモリ203が記憶する個人情報には、嗜好情報の他、生体情報と、購買履歴情報と、行動履歴情報とが含まれていてもよい。生体情報は心拍数等の各ユーザの生体に関する情報である。購買履歴情報は、各ユーザの商品(物品)又はサービスの購買履歴を示す情報である。行動履歴情報は、例えば、ユーザの位置情報と時刻情報とが対応付けられた時系列データで構成される。
次に、第2サーバ300の構成について説明する。第2サーバ300は、各レストラン系列に対応して1又は複数存在する。第2サーバ300は、通信部301、演算部302、及びメモリ303を含む。通信部301は第2サーバ300をネットワークNTに接続するための通信回路で構成される。通信部301は、情報端末100からの要求に応じて標準メニュー情報を第1サーバ200に送信する。演算部302は、CPU等のプロセッサで構成される。演算部302は、メモリ303が記憶する標準メニュー情報を処理する。メモリ303はハードディスクドライブ等の不揮発性のストレージ装置で構成されている。メモリ303は、標準メニュー情報を記憶する。
(個別メニュー情報による飲食品の注文)
個別メニュー情報による飲食品の注文は、マッチングアプリの起動をトリガーに開始される。図3は、飲食品を注文するユーザがマッチングアプリを起動した直後に情報端末100に表示される認証画面G1の一例を示す図である。認証画面G1は、指紋認証によりユーザ認証を行うための画面である。認証画面G1には、中央に指紋を模式的に示す指紋画像1201が表示され、指紋画像1201の下部には「指紋認証してください」とのメッセージが表示されている。これらにより、認証画面G1は、ユーザに対して指紋認証を行うよう促している。認証画面G1の上部には「パーソナルマッチング」と記載されている。これにより、認証画面G1はマッチングアプリの画面であることをユーザに確認させることができる。このことは、後述する図4及び図5においても同じである。
図4は、他の一例に係る認証画面G2を示す図である。認証画面G2は、顔認証によりユーザ認証を行うための画面の一例である。認証画面G2には、情報端末100がユーザの正面からの顔の画像を適当なサイズで捉えられるよう、中央に顔の輪郭を模式的に示す点線1301が表示されている。ユーザは点線1301に収まるように自身の正面からの顔が表示されるように情報端末100の向き及び位置を調整する。
上記のユーザ認証の方法に比べて必要な認証精度をより少ないユーザの負担で実現できるユーザ認証の方法があれば、その方法が採用されてもよい。ユーザ認証の方法としては、一般的にセキュリティ強度が高いと言われる2段階認証が採用されてもよいし、ユーザIDとパスワードとを入力する方法が採用されてもよい。
図5は、マッチングアプリによるユーザ認証が終わった直後に表示されるホーム画面G3の一例を示す図である。ホーム画面G3には、上段にアプリ名称「パーソナルマッチング」が表示され、中段に複数のタイルオブジェクト1401がマトリックス状に表示されている。各タイルオブジェクト1401には、マッチングアプリが取り込んだ連携機能又は別アプリが対応付けられている。別アプリは、例えば、マッチングアプリ内で起動するアプリである。この例では、a、b、c、d、eと記載された5つのタイルオブジェクト1401が表示されている。これらのタイルオブジェクト1401には、マッチングアプリに連携して自社商品又は自社サービスのマッチングを行う専用機能(例えば、マッチングアプリ内で利用可能なあるレストランのアプリ)が対応付けられている。これにより、ユーザは、a、b、c、d、eで示される5種類の連携機能が利用可能である。グレイアウトされたタイルオブジェクト1401は、連携機能がインストールされていない空きのタイルオブジェクトである。ホーム画面の下段には、左よりスキャンボタン1402、マップボタン1403、アカウントボタン1404、及びホームボタン1405が表示されている。こら4つのボタンはユーザに共通して提供される固定ボタンである。スキャンボタン1402は、上述したレストラン等の事業者が提供するサービスに連携したQRコード(登録商標)、NFC(Near Field Communication)タグ、RFID(Radio Frequency IDentifier)タグ等を読み取る場合に使用されるボタンである。マップボタン1403は、情報端末100の現在の地点の周辺にあるマッチングアプリに対応する店舗情報及び/又はその店舗にて提供される商品又はサービス情報を含むマップ画面を表示させるボタンである。アカウントボタン1404は、ユーザのアカウント情報を登録及び編集するためのボタンである。アカウント情報の登録及び編集には、例えば、個人認証の設定及び第1サーバ200との連携機能の設定等が含まれる。ホームボタン1405は、画面表示をこの図に示されるホーム画面G3に戻すためのボタンである。
ホーム画面G3では、上述のようにマッチングアプリを介して他の事業者のサービスと連携するための専用機能を示すタイルオブジェクト1401が中段に集約して配置されている。これらのタイルオブジェクト1401はユーザの好みに応じて、表示の有無及び配置する場所が設定可能である。よって、ユーザは、1つのマッチングアプリを用いて、数多くの事業者(例えば、家電量販店、DVD/Blu-ray(登録商標)レンタル店、本屋、コーヒーショップ、タクシー等)が提供する商品又はサービスのうち、個人情報をもとにそのユーザに適合する商品及び/又はサービスを取得できる。
図6は、情報端末100に表示されるマップ画面G4の一例を示す図である。このマップ画面G4は、ホーム画面G3においてマップボタン1403を選択する操作が入力された場合に表示される。マップ画面G4には、情報端末100の現在の地点を含む地域の地図が含まれる。さらに、マップ画面G4には、この地域内にあるマッチングアプリに対応した店舗情報が表示されている。ここでは、ユーザの現在の地点を示すアイコン3200に加えて、レストランA系列の店舗A1、レストランA系列の店舗A2、本屋K系列の店舗K1、及びレストランB系列の店舗B1が表示されている。
ユーザはこのマップ画面G4を見ながら、来店を希望する店舗を選択する。この例では、アイコン3210で示される、現在の地点から一番近いレストランB系列の店舗B1が選択される。ユーザは、例えば、アイコン3210を指でタッチすることで、レストランB系列の店舗B1を選択することができる。アイコン3210がタッチされると、マッチングアプリは、アイコン3210が示すレストランB系列の店舗B1の接続先情報及び店舗IDを取得する。さらに、マッチングアプリはユーザの識別情報(ユーザID)をメモリ102から取得する。ユーザIDは、図18で後述するように、情報端末100の「account」ディレクトリ下のuser_account.xmlファイルに格納されている。接続情報は例えばレストランB系列の第2サーバ300と通信するためのアドレス情報(例えば、URL等)である。
マッチングアプリは、取得した店舗IDとユーザIDとをもとに、第1サーバ200とレストランB系列の第2サーバ300と連携して、当該ユーザの個別メニュー情報を取得する。
具体的には、マッチングアプリは、店舗IDとユーザIDとを含む個別メニューの取得要請を第1サーバ200に送信する。この取得要請を受信した第1サーバ200は、店舗IDをもとに、その店舗が提供可能な標準メニュー情報の取得要請をレストランB系列の第2サーバ300に送信する。この取得要請を受信した第2サーバ300は、レストランB系列の標準メニュー情報を第1サーバ200に送信する。標準メニュー情報は図18で後述する第2サーバ300の「ResB.html」ファイル及び「ResB.css」ファイルに記憶されている。
レストランB系列の標準メニュー情報を受信した第1サーバ200は、取得した標準メニュー情報を、このユーザIDを持つユーザに対して最適化するために、このユーザのレストランB系列での過去の注文履歴をメモリ203から取得する。ここでは、このユーザについてレストランB系列の注文履歴がメモリ203になかったとする。
この場合、第1サーバ200は、このユーザについて、例えば他のレストラン系列の注文履歴をメモリ203から取得する。そして、第1サーバ200は、他のレストラン系列の注文履歴の中からユーザによりよく注文されている飲食品の表示順序が上位になるように、レストランB系列の標準メニューの飲食品の順序を変更する。例えば、このユーザについて他のレストランの注文履歴から「カフェモカ」がよく注文されていたとする。この場合、第1サーバ200は、レストランB系列の個別メニュー情報において、カフェモカの注文がより容易になるように、「カフェモカ」の表示順序を上位に配列する。さらに、この場合、第1サーバ200は、「カフェモカ」の表示サイズ及び/又は色使いの識別が容易になるように、「カフェモカ」の表示態様をデフォルトの表示態様から変更してもよい。
上記のようにして生成されたレストランB系列の個別メニュー情報は、第1サーバ200から情報端末100へ送信される。
図7は、情報端末100に表示される個別メニュー情報の表示画面の一例である個別メニュー画面G5を示す図である。この個別メニュー画面G5は、マップ画面G4でユーザが選択したレストランB系列の個別メニュー画面である。個別メニュー画面G5の上部には「レストランB B1店 カスタムメニュー」と記載されている。これは、この個別メニュー画面G5に掲載されているメニューが、ユーザが選択した店舗B1が属するレストランB系列の標準メニュー情報と、メモリ203に記憶されたユーザの注文履歴とを考慮してパーソナライズされたメニューであることを意味している。
この例では、このユーザについてレストランB系列の注文履歴はメモリ203に記憶されていなかったものの、このユーザについて他のレストラン系列の注文履歴がメモリ203に記憶されていた。そして、このユーザについて他のレストラン系列の注文履歴が示す各飲食品に対する注文回数がアイスクリーム、カプチーノ、カフェモカ、タピオカヨーグルト、アイスコーヒー、チョコクッキーの順であった。そのため、個別メニュー画面G5ではこの順で、各飲食品を示すタイルオブジェクト701が配列されている。
これにより、ユーザの嗜好に合う飲食品がより注文しやすい位置に表示される結果、ユーザは、自己の嗜好に合う飲食品を効率よく選択することができる。図7の例では、各タイルオブジェクト701の表示順位は、左上に向かうほど上位であり、右下に向かうほど下位という順位である。但し、これは一例であり、右上に向かうほど上位であり、左下に向かうほど下位という順位であってもよい。
図7の例では、タイルオブジェクト701は、3行2列でマトリックス状に表示されているが、これは一例であり、3行1列或いは4行2列というように他の行列数で表示されてもよい。さらに、図7の例において、初期画面に表示できなかった飲食品のタイルオブジェクト701は、スクロール操作により表示可能である。初期画面とは個別メニュー画面G5が表示された際に最初に表示される画面である。
ユーザが注文しやすいような個別メニュー画面G5のデザインは、さらに、下記のようなものであってもよい。例えば、注文回数が上位の飲食品をタイルオブジェクト701が個別メニュー画面G5の初期画面内に優先的に配列されたり、その初期画面の中で注文回数が多い飲食品ほどタイルオブジェクト701が画面中央に配列されたりしてもよい。さらに、このような配列がされたうえで、注文回数が多い飲食品ほどタイルオブジェクト701のサイズが大きく表示されたり、注文回数が多い飲食品ほど他の飲食品と区別しやすいように異なる色使い又は境界線の太さでタイルオブジェクト701が表示されたり、注文回数が多い飲食品ほど商品名、価格、及び/又は商品の画像が装飾されたりしてもよい。
図8は、情報端末100に表示される個別メニュー情報の表示画面の別の一例である個別メニュー画面G6を示す図である。この個別メニュー画面G6では、注文回数が上位から所定数(ここでは、上位2つ)の飲食品(ここでは、アイスクリーム、カプチーノ)のタイルオブジェクト7011が他の飲食品(ここでは、カフェモカ、タピオカヨーグルト)のタイルオブジェクト7012よりも上側に配置されている。カフェモカ及びタピオカヨーグルトのタイルオブジェクト7012は、個別メニュー画面G6の3行目に配置されている。
さらに、タイルオブジェクト7011は、タイルオブジェクト7012よりもサイズが大きく表示されている。さらに、タイルオブジェクト7011は、タイルオブジェクト7012よりも枠801が太くされると共に枠801に装飾が施されている。枠801に対する装飾は、例えば、枠801を金色、赤色などの目立つ色で表示させる態様が採用できる。さらに、タイルオブジェクト7011は、タイルオブジェクト7012よりも飲食品を示す画像802が大きくされている。さらに、タイルオブジェクト7011は、飲食品を示す画像802の周囲にデフォルメするマーク803(ここでは、星マーク)が表示されている。さらに、タイルオブジェクト7011は、タイルオブジェクト7012よりも飲食品名の文字列804のサイズが大きく表示されている。この文字列804は、影付き文字などで表示することによってデフォルメされていてもよい。さらに、タイルオブジェクト7011は、お気に入りであることを示すマーク805(ここでは、ハートマーク)が表示されている。
図8において、アイスクリームのタイルオブジェクト7011がカプチーノのタイルオブジェクト7011よりも上側に配置されているのは、アイスクリームに対するユーザの注文回数がカプチーノに対するユーザの注文回数よりも多かったからである。図8において、初期画面に表示できなかった飲食品のタイルオブジェクト7012はスクロール操作によって表示されてもよい。この場合、個別メニュー画面G6が縦方向にスクロール操作されることで、全タイルオブジェクトが縦方向にスクロールされてもよい。或いは、タイルオブジェクト7012の表示欄を横方向にスクロール操作することで、タイルオブジェクト7011の表示は維持されたまま、タイルオブジェクト7012のみがスクロールされてもよい。
図9は、情報端末100に表示される標準メニュー情報の表示画面の一例である標準メニュー画面G7を示す図である。標準メニュー画面G7では、ユーザごとに最適化されていないレストランB系列の店舗B1の標準メニュー情報が示されている。
標準メニュー画面G7の上部には「レストランB B1店 標準メニュー」と記載されている。これは、この標準メニュー画面G7に掲載されているメニューが、レストランB系列の標準メニューあることを意味している。標準メニュー画面G7には、例えば3行2列のマトリックス状にタイルオブジェクト701が配置されている。ここでは、例えばレストランB系列において人気が高い飲食品ほど注文しやすい位置にタイルオブジェクト701が配置されている。具体的には、左上側ほど人気が高く、右下側ほど人気が低くなるようにタイルオブジェクト701が配置されている。標準メニュー画面G7は、スクロール操作により、初期画面で表示されなかったタイルオブジェクト701が表示可能に構成されている。
標準メニュー画面G7では、ユーザ個別の嗜好情報が考慮されることなくタイルオブジェクト701が配置されているため、ユーザは希望する飲食品のタイルオブジェクト701を探し出すのに手間がかかる。
これに対して、個別メニュー画面G5,G6ではユーザの嗜好に合う飲食品が注文し易い位置に配置されているため、ユーザは希望する飲食品のタイルオブジェクト701を容易に探し出せる可能性が高くなる。さらに、個別メニュー画面G5,G6では第1サーバ200が記憶しているユーザの注文履歴に基づいて、ユーザの注文回数が多い飲食品のタイルオブジェクト701ほどより上位に配置されている。そのため、ユーザが選択した店舗B1はもとより、その店舗B1が属するレストランB系列のいずれの店舗にもユーザが来店したことがない場合であっても、個別メニュー画面G5,G6には、ユーザの嗜好が考慮された順序でタイルオブジェクト701が配列されている。
例えば、ユーザはレストランA系列の店舗A1が行きつけの店舗であり、その店舗A1においてユーザは自己の情報端末100に自己の注文履歴が考慮された個別メニュー画面を表示させて、飲食品を注文していたとする。この場合、ユーザはレストランB系列の店舗B1に初めて来店したにもかかわらず、自己の情報端末100において行きつけのレストランA系列の個別メニュー画面と同様の順序で飲食品が配列された個別メニュー画面G5,G6を表示させることが可能となる。これにより、ユーザは希望する飲食品を速やかに探し出すことが可能になると共に安心感も与えることが可能となる。さらに、ユーザに対して初めて来店した系列の店舗であるにもかかわらず見慣れた順序で飲食品が配置された個別メニュー画面が表示されるため、ユーザに驚きを与え、注文に対する関心を向上させることも可能となる。
図10は、図7に示す個別メニュー画面G5において、ユーザが飲食品を注文する様子を示した図である。ここでは、カプチーノのタイルオブジェクト7013とチョコクッキーのタイルオブジェクト7014とが選択されている。そのため、タイルオブジェクト7013,7014の色がデフォルトの第1色から選択されたことを示す第2色に変更されている。さらに、タイルオブジェクト7013,7014がそれぞれ1回タッチされたため、タイルオブジェクト7013,7014のそれぞれに注文した個数を示す文字列である「1」が表示されている。
図11は、図10で選択した飲食品の注文を確定する際に表示される注文確定画面G8の一例を示す図である。注文確定画面G8は、図10に示す個別メニュー画面G5において、図略の「注文に進む」ボタンを押すことで表示される。注文確定画面G8には、個別メニュー画面G5で選択されたカプチーノのタイルオブジェクト7013と、チョコクッキーのタイルオブジェクト7014とが表示されている。タイルオブジェクト7013,7014の下側には注文した飲食品の合計金額を示す合計金額表示欄7015が表示されている。ここでは、「カプチーノ」と「チョコクッキー」とが1つずつであり合計金額が500円であったため、合計金額表示欄7015には「500円」が表示されている。合計金額表示欄7015の下側には注文を確定するための注文ボタン7016が表示されている。注文確定画面G8に表示された注文内容に納得したユーザは注文ボタン7016をタッチする。これにより、注文が完了する。
(注文処理)
図15は、行きつけの系列の店舗に来店したユーザにより飲食品が注文される際の情報提示システムの処理の一例を示すシーケンス図である。
ステップS1において情報端末100はユーザからマッチングアプリの起動指示を受け付けてマッチングアプリを起動し、マップ画面G4をディスプレイ105に表示する。具体的には、マッチングアプリが起動すると、マッチングアプリは認証画面G1又は認証画面G2を表示してユーザ認証を行い、ユーザ認証ができた場合、ホーム画面G3を表示する。このホーム画面G3においてマップボタン1403がタッチされると、マッチングアプリはマップ画面G4を表示する。
ステップS2において、マッチングアプリは、GPSセンサー107が検知した情報端末100の現在の地点を示す位置情報を取得し、当該地点を含む周辺地域の地図情報である周辺地図情報の取得要請をパブリック情報サーバ500に送信する。
この取得要請を受信したパブリック情報サーバ500は、この取得要請に含まれる位置情報から情報端末100の現在の地点を取得し、その地点を基準に所定範囲の地域の地図情報を周辺地図情報として地図データベースから抽出し、マッチングアプリに送信する。周辺地図情報を受信したマッチングアプリは、周辺地図情報が示す地図を含むマップ画面G4を表示する(ステップS3)。地域を示す所定範囲は、例えば現在の地点から半径1km又は2kmの範囲等、今から外食をしようとするユーザが徒歩又は車によって来店することが可能な範囲である。
マップ画面G4を表示したマッチングアプリは、受信した周辺地図情報が示す地図内に含まれる店舗であって、第1サーバ200に登録された店舗の店舗情報の取得要請を第1サーバ200に送信する(ステップS4)。
この取得要請を受信した第1サーバ200はメモリ203から該当する地図内に含まれる店舗の店舗情報を抽出し、マッチングアプリに送信する。メモリ203には、例えば各店舗の店舗情報を含む店舗データベースが記憶されている。各店舗情報には店舗の店舗ID、店舗名、系列、位置情報、及び接続情報が含まれている。したがって、第1サーバ200は、店舗情報の取得要請が示す地図の地域内に含まれる店舗を、店舗データベースに記憶された各店舗の位置情報から特定すればよい。
抽出された店舗情報を受信したマッチングアプリは、その店舗情報をマップ画面G4の地図上に表示する(ステップS5)。これにより、図6のマップ画面G4に示されるように、ユーザの現在の地点の周辺地域に含まれる店舗がその周辺地域を示す地図上に表示される。
ステップS6において、マッチングアプリは、マップ画面G4に表示された店舗のうちレストランA系列の店舗A1を選択するユーザの指示を受け付ける。ここで、店舗A1はユーザが行きつけの店舗である。
ステップS7において、マッチングアプリは、店舗A1の個別メニュー情報の取得要請を第1サーバ200に送信する。この取得要請には店舗A1の店舗ID、接続情報、及び情報端末100のユーザID等が含まれる。
この取得要請を受信した第1サーバ200は、店舗A1が属するレストランA系列の標準メニュー情報の取得要請をレストランA系列又は店舗A1の第2サーバ300に送信する(ステップS8)。
この取得要請を受信したレストランA系列又は店舗A1の第2サーバ300は、店舗A1の標準メニュー情報を第1サーバ200に送信する。これにより、第1サーバ200は店舗A1の標準メニュー情報を受信する(ステップS9)。ここで送信される店舗A1の標準メニュー情報は、レストランA系列の各店舗で共通のメニュー情報であってもよいし、レストランA系列の各店舗で一部分が異なるメニュー情報であってもよい。
店舗A1の標準メニュー情報を受信した第1サーバ200は、メモリ203に記憶された該当するユーザのレストランA系列の各店舗での注文履歴を集計して、店舗A1向けの個別メニュー情報を生成する(ステップS10)。生成された店舗A1向けの個別メニュー情報は第1サーバ200により情報端末100(マッチングアプリ)へ送信され、マッチングアプリは、この個別メニュー情報を受信する(ステップS11)。
ステップS11までの処理において、情報端末100に表示される各種画面は第1サーバ200の管理者(情報銀行)のスタイルでデザインされたものが使用される。一方、ステップS12からの処理においては、情報端末100に表示される各種画面はレストランA系列のスタイルでデザインされたものが使用される。
尚、ステップS12からの処理において、情報端末100に表示される各種画面は、レストランA系列が用意する素材(料理を説明する文字、料理の写真など)が第1サーバ200の管理者(情報銀行)のスタイルでレイアウトされた画面であっても良い。このようにすることで、マッチングアプリを利用するユーザに対して統一的なユーザエクスペリエンスを提供することができる。
ステップS12において、マッチングアプリは、受信した店舗A1向けの個別メニュー情報を示す個別メニュー画面を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップS13において、マッチングアプリは、注文された飲食品を示す注文情報を第1サーバ200に送信する。ここの注文情報を受信した第1サーバ200は、この注文情報をレストランA系列の第2サーバ300に送信する(ステップS14)。この注文情報を受信した第2サーバ300は、例えば店舗A1の店舗端末のディスプレイに注文情報を表示する等して、店舗A1のスタッフに調理の開始を通知する(ステップS15)。
ステップS16において、第1サーバ200は、注文情報をメモリ203に記憶することで、該当するユーザの注文履歴を更新する(ステップS16)。
図15のシーケンス図では、周辺地図情報の取得以外の処理ではマッチングアプリが通信するサーバは第1サーバ200であるとして説明したが、本開示はこれに限定されない。例えば、マッチングアプリは、店舗情報の取得に関して第1サーバ200以外の第三のサーバにアクセスしてもよい。
図16は、初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。
ステップS21~S25の処理は図15のステップS1~S5の処理と同じである。ステップS26において、マッチングアプリは、マップ画面G4に表示された店舗のうちレストランB系列の店舗B1を選択するユーザの指示を受け付ける。
ステップS27において、マッチングアプリは、店舗B1の個別メニュー情報の取得要請を第1サーバ200に送信する。この取得要請には店舗B1の店舗ID、接続情報、及び情報端末100のユーザID等が含まれる。
この取得要請を受信した第1サーバ200は、店舗B1が属するレストランB系列の標準メニュー情報の取得要請をレストランB系列の第2サーバ300に送信する(ステップS28)。
この取得要請を受信したレストランB系列の第2サーバ300は、店舗B1の標準メニュー情報を第1サーバ200に送信する。これにより、第1サーバ200はレストランB系列の標準メニュー情報を受信する(ステップS29)。ここで送信されるレストランB系列の標準メニュー情報は、レストランB系列の各店舗で共通のメニュー情報であってもよいし、レストランB系列の各店舗で一部分が異なるメニュー情報であってもよい。
レストランB系列の標準メニュー情報を受信した第1サーバ200は、該当するユーザの注文履歴に基づいて店舗B1における該当するユーザの個別メニュー情報を生成する(ステップS30)。具体的には、第1サーバ200は、レストランB系列での該当するユーザの注文履歴が後述する参照条件C1を満たさない場合、レストランB系列の店舗B1が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗B1における個別メニュー情報を生成する。一方、第1サーバ200は、レストランB系列での該当するユーザの注文履歴が参照条件C1を満たしている場合、レストランB系列での該当するユーザの注文履歴を用いて店舗B1における該当するユーザの個別メニュー情報を生成する。ステップS30の処理の詳細は図17に示すフローチャートを用いて後述する。
生成された店舗B1の個別メニュー情報は第1サーバ200により情報端末100(マッチングアプリ)へ送信され、マッチングアプリは、この個別メニュー情報を受信する(ステップS31)。
ステップS31までの処理において、情報端末100に表示される各種画面は第1サーバ200の管理者(情報銀行)のスタイルでデザインされたものが使用される。一方、ステップS32からの処理においては、情報端末100に表示される各種画面はレストランB系列のスタイルでデザインされたものが使用される。
尚、ステップS32からの処理において、情報端末100に表示される各種画面は、レストランB系列が用意する素材(料理を説明する文字、料理の写真など)が第1サーバ200の管理者(情報銀行)のスタイルでレイアウトされた画面であっても良い。このようにすることで、マッチングアプリを利用するユーザに対して統一的なユーザエクスペリエンスを提供することができる。
ステップS32において、マッチングアプリは、受信した店舗B1の個別メニュー情報を示す個別メニュー画面G5,G6を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップS33~ステップS36の処理は、店舗A1ではなく店舗B1に対して飲食品の注文が行われること以外は、図15に示すステップS12~S16と同じである。
図17は、図16のシーケンス図のステップS30における処理に着目したときの情報提供システムの処理の一例を示す図である。
ステップS101において、第1サーバ200は、指定されたレストラン系列の標準メニュー情報を第2サーバ300から取得する。この処理は、図16のステップS29に相当する。指定されたレストラン系列とは、マップ画面G4においてユーザが選択した店舗が属しているレストラン系列である。
図13は、標準メニュー情報D1のデータ構成の一例を示す図である。標準メニュー情報D1には、1以上の飲食品のそれぞれについて、料理名、価格、及び期間限定が対応付けて記憶されている。飲食品名は「ブレンドコーヒー」、「アメリカンコーヒー」等、提供される飲食品の名称を示す。価格は各飲食品の価格を示す。期間限定は、期間限定で提供される飲食品であるか否かを示す。YESは期間限定の飲食品であることを示し、NOは年間を通じて提供される飲食品であることを示す。例えば、「スペシャルモンブランホワイトカフェラテ」は特定の期間に提供される飲食品であるため、期間限定が「YES」になっている。
図17に参照を戻す。ステップS102において、第1サーバ200は、メモリ203に記憶された該当するユーザの注文履歴の中から、指定されたレストラン系列における該当するユーザの注文履歴を検索する。
ステップS103において、第1サーバ200は、検索にヒットした注文履歴が参照条件C1を満たすか否かを判定する。参照条件C1は、第1サーバ200の運営会社、マッチングアプリの開発会社、マッチングアプリの配布会社、サービス提供会社(この場合、レストランB系列)、又はユーザが設定した期間において、下記の(a)~(d)のうち少なくとも1つの条件を含むようにしてもよい。設定された期間とは、例えば、現在から過去3年、2年、1年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。
(a)指定されたレストラン系列における飲食品の注文回数が閾値Ta以上
(b)指定されたレストラン系列で注文した日の回数(来店回数)が閾値Tb以上
(c)指定されたレストラン系列で注文した飲食品の個数(注文皿数)が閾値Tc以上
(d)指定されたレストラン系列で注文した飲食品の合計金額(注文額)が閾値Td以上
閾値Ta~閾値Tdは、例えば、それぞれ、ユーザが指定されたレストラン系列に行きつけているとみなせる予め定められた値が採用される。或いは、閾値Ta~閾値Tdはユーザが指定されたレストラン系列に実質的に初めて来店したとみなせる予め定められた値が採用されてもよい。
設定された期間内の条件を設けたのは、指定されたレストラン系列にユーザが久しく来店しておらず、その間にユーザの嗜好が変化する可能性や、店舗がメニューを更新する可能性を考慮したためである。例えば、ユーザの嗜好は健康意識が高くなると変化する可能性がある。
ヒットした注文履歴が参照条件C1を満たす場合(ステップS103でYES)、第1サーバ200は、ヒットした注文履歴を優先指標として用いて、指定された店舗での該当するユーザの個別メニュー情報を生成する(ステップS104)。指定された店舗とは、マップ画面G4においてユーザが選択した店舗である。例えば、指定された店舗が店舗B1であり、ユーザが店舗B1に行きつけている、或いは、ユーザがレストランB系列のいずれかの店舗に行きつけているような場合、ステップS103でYESと判定される。この場合、第1サーバ200は、例えば、ヒットした注文履歴の注文回数から、より多く注文された飲食品の優先順位を高くするように決定してもよい。また、注文時のユーザの周辺状況も加味して、注文される可能性が高い順に、飲食品を順位付けするようにしてもよい。例えば、今回の注文時の周辺状況(曜日、季節、気温、湿度、天気、場所、利用店舗、ユーザの生体情報、ユーザの活動量の内の少なくとも1つ)と類似の周辺状況だった時の注文回数から、個別メニューでの飲食品の訴求優先順位を決定するようにしてもよい。これによって、単に注文回数が最も多いという理由だけで、常にどのような状況でも特定の飲食品が推薦されるということを回避できる利点がある。そして、第1サーバ200は、上位の飲食品ほど注文し易くなるようにレストランB系列の標準メニュー情報のメニュー内容を並び替え、個別メニュー情報を生成すればよい。この個別メニュー情報は情報端末100に送信される。
図12は、注文履歴を記憶する注文履歴データベースD2のデータ構成の一例を示す図である。図12では、店舗を指定したユーザの注文履歴データベースD2が示されている。注文履歴データベースD2の各レコードには、例えば該当するユーザの店舗への1回の来店に対する注文履歴が記憶されている。注文履歴データベースD2には、注文した日時情報、店舗ID、店舗名、及び注文した飲食品名が対応付けて記憶されている。この注文履歴データベースD2は、後述する図18に示す「userID_FoodHistory_1.json」ファイル~「userID_FoodHistory_N.json」ファイルに暗号化されたうえで分散管理されている。
注文した日時情報は、ユーザが飲食品を注文した日時を示している。店舗IDはユーザが来店した店舗の識別情報である。店舗名はユーザが来店した店舗の名称である。ここでは、店舗名にはその店舗が属しているレストラン系列の名称が含まれている。注文した飲食品名は、ユーザが注文した飲食品の名称である。例えば、1行目のレコードには、2020年1月3日13時15分45秒にレストランA系列の門真店でユーザがカプチーノとアイスクリームとを注文した注文履歴が記憶されている。
なお、ここでは上記の周辺状況については図示していないが、周辺状況の情報もこの注文履歴に一緒に記憶されるようにしてもよい。曜日は注文した日の曜日、季節は注文した日の季節、気温は注文した時のユーザ近辺の気温、湿度は注文した時のユーザ近辺の湿度、天気は注文した時のユーザ近辺の天気(晴れ、雨、くもりなど)、場所は注文をした場所を示す情報(住所、GPS情報など)、利用店舗は注文をした店舗の特定情報、ユーザの生体情報は注文をした時のユーザの生体情報(血圧、心拍数など)、ユーザの活動量は注文をした日のユーザの活動量情報(歩数、消費カロリーなど)をそれぞれ示している。
指定されたレストラン系列がレストランB系列であるとすると、第1サーバ200は、レストランB系列の標準メニュー情報D1に含まれる各飲食品の注文回数を注文履歴データベースD2を参照して集計し、集計結果から当該標準メニュー情報に含まれる各飲食品を順位付けして個別メニュー情報を生成すればよい。
ステップS105において、情報端末100は、個別メニュー情報を示す個別メニュー画面を表示する。ステップS106において、情報端末は、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップS103において、ヒットした注文履歴が参照条件C1を満たしていない場合(ステップS103でNO)、第1サーバ200は、該当するユーザの注文履歴が参照条件C2を満たすか否かを判定する(ステップS107)。
参照条件C2は、第1サーバ200の運営会社、マッチングアプリの開発会社、マッチングアプリの配布会社、サービス提供会社(この場合、レストランB系列)、又はユーザが設定した期間において、下記(e)、(f)、(g)のうち少なくとも1つの条件を含むようにしてもよい。設定された期間は、3年、2年、1年等の有限期間であってもよいし、無制限の期間であってもよい。
(e)カウント値の合計値が閾値Te以上
(f)カウント値が閾値Tf以上の飲食品の数が所定個数以上
(g)注文金額の合計金額が閾値Tg以上
カウント値とは、指定されたレストラン系列の標準メニュー情報に含まれる各飲食品について、注文履歴データベースD2の「注文した飲食品名」のフィールドにおける出現回数である。カウント値は、検索する文字列が検索対象の文字列に含まれる回数を計測するというようなテキストマッチングにより計測される。例えば、設定された期間(例えば、3年間)において、標準メニュー情報に含まれる「カプチーノ」という文字列が注文履歴データベースD2の「注文した飲食品名」のフィールドに29回出現した場合、「カプチーノ」のカウント値は29となる。また、標準メニュー情報に、例えば、「担々麺」及び「餃子」が別々にある場合において、注文履歴データベースD2の「注文した飲食品名」のフィールドに「担々麺餃子セット」がある場合、「担々麺」及び「餃子」のそれぞれが1カウントアップされるようにしてもよい。
カウント値の合計値は、該当するユーザにおいて、各飲食品のカウント値の合計値である。図14の例では、「ブレンドコーヒー」から「スペシャルモンブランホワイトカフェラテ」までの例示された範囲だけで、該当するユーザの各飲食品のカウント値の合計値は、2+29+11+3=45となる。
また、標準メニューに含まれる各飲食品について、名称を示す文字列が一致又は類似する飲食品が注文履歴データベースD2の「注文した飲食品名」のフィールドに含まれていれば、出現回数がカウントアップされる。例えば、ブレンドコーヒーとオリジナルブレンドコーヒーとは一方の文字列が他方の文字列に含まれるため、類似すると判定される。カウント値の合計値とは、各飲食品のカウント値を合計した値である。
カウント値が閾値Tf以上の飲食品とは、注文履歴データベースD2の例において、閾値Tfが「10」とすると、「カプチーノ」及び「カフェモカ」が該当する。この場合、条件(f)の所定個数が「2」であるとすると、該当するユーザの注文履歴は条件(f)を満たすと判定される。
注文履歴が参照条件C2を満たす場合(ステップS107でYES)、第1サーバ200は該当するユーザの注文履歴を用いて、指定された店舗における個別メニュー情報を生成する(ステップS108)。この場合、第1サーバ200は、カウント値、すなわち注文回数が多い飲食品ほど注文し易くなるように個別メニュー情報を生成すればよい。ステップS108が終了すると、処理はステップS105に進められ、ステップS105以降の処理が実施される。
注文金額の合計金額とは、個々の飲食品の価格に注文回数を掛けて、それを全ての飲食品に対して合計した金額のことである。図13と図14の例示された範囲では、注文金額の合計金額は、2*350+29*350+11*350+3*150=15150円と計算される。
図14は、あるユーザについて、標準メニュー情報に含まれる各飲食品に対して注文回数を纏めた表である。この表において、「全ての注文回数」は指定されたレストラン系列を含む全てのレストラン系列における各飲食品の注文回数を示す。「指定されたレストラン系列での注文回数」はユーザがマップ画面G4にて選択した店舗が属するレストラン系列における当該ユーザの各飲食品の注文回数を示す。
例えば、指定されたレストラン系列での注文回数は全て0であるため、該当するユーザはこのレストラン系列を過去に来店していないことが分かる。そのため、このレストラン系列の注文履歴からユーザの嗜好に合った個別メニュー情報を生成することはできない。しかしながら、「全ての注文回数」には、「カプチーノ」、及び「カフェモカ」の注文回数が多く、ユーザの嗜好性が見えてくる。
そこで、第1サーバ200は、「全ての注文回数」を参照することで、個別メニュー情報を生成する。これにより、第1サーバ200は、ユーザの嗜好に合った個別メニュー情報を生成できる。図14の例では、「カプチーノ」及び「カフェモカ」における「全ての注文回数」が他の飲食品より多い。そのため、これらの飲食品は指定されたレストラン系列の利用が初めてであっても、その個別メニュー画面の初期画面に表示され、注文がし易いように表示されることになる。また、「アメリカンコーヒー」のような「全ての注文回数」が少ない飲食品は、個別メニュー画面の初期画面から省かれてもよい。或いは、個別メニュー画面の初期画面において、「全ての注文回数」が多い例えば「カプチーノ」及び「カフェモカ」のような飲食品のタイルオブジェクト701が表示可能である場合、アメリカンコーヒーが表示されてもよい。この場合、アメリカンコーヒーのような「全ての注文回数」が少ない飲食品のタイルオブジェクト701は、「カプチーノ」及び「カフェモカ」よりも小さな面積で表示されてもよい。
なお、注文履歴が参照条件C2を満たしている場合、図14に示す「全ての注文回数」から、指定されたレストラン系列の注文回数を除外して、各飲食品のカウント値が算出されてもよい。または、注文履歴が参照条件C2を満たしている場合、図14に示す「全ての注文回数」の中で、指定されたレストラン系列での注文回数とそれ以外での注文回数とに異なる重みづけをして(例えば、指定されたレストラン系列での注文回数をそれ以外での注文回数より重要視した重みづけをして)、各飲食品のカウント値が算出されてもよい。或いは、注文履歴が参照条件C2を満たしている場合、図14に示す「全ての注文回数」において指定されたレストラン系列以外の特定の1又は複数のレストラン系列の「全ての注文回数」を用いて各飲食品のカウント値が算出されてもよい。特定の1又は複数のレストラン系列とは、ユーザが行きつけのレストラン系列である。
図17に参照を戻す。ステップS107において、該当するユーザの注文履歴が参照条件C2を満たしていない場合(ステップS107でNO)、第1サーバ200は、マップ画面G4にてユーザが選択した店舗が属するレストラン系列の標準メニュー画面を情報端末100に表示させる(ステップS109)。
ステップS107の分岐処理を設けることにより、例えば注文履歴データベースD2に記憶されたユーザの注文履歴が少なく、この注文履歴データベースD2からユーザの嗜好をくみ取ることができないケースにおいて、個別メニュー情報が生成されることを防止できる。ステップS110において、情報端末100は、標準メニュー画面を閲覧したユーザから注文する飲食品を選択する指示を受け付ける。
(個別メニューから注文をする際の情報処理の実装例)
次に、個別メニュー画面から飲食品を注文する場合の情報処理の実装例について説明する。情報通信のインターフェース及び取り扱うデータ構造がレストラン系列又は店舗に固有である場合、情報提供システムで取り扱われる各種データが、例えば、レストランA系列の店舗A1では利用可能だが、レストランB系列では使用できないといった事態、又はレストランA系列の別店舗及びレストランB系列の両方で使用できないという事態が生じ得る。このような事態を回避するために、多くのユーザが多くのレストランで個別メニューを用いた飲食品の注文を実施するめの汎用的なソリューションについて、以下説明する。
図18は、本実施の形態における情報提供システムの具体的な実装形態の一例を示す図である。情報端末100のメモリ102には、マッチングアプリの実行に必要となるファイルの格納場所である「matching_app」ディレクトリがある。「matching_app」ディレクトリの下には、「account」ディレクトリ、「main」ディレクトリ、及び「matching_temp」ディレクトリがある。「account」ディレクトリにはユーザのアカウント及び/又はユーザ認証に必要な情報が格納される。「main」ディレクトリには、マッチングアプリがホーム画面の描画などの基本機能を実現するために必要な情報が格納される。「matching_temp」ディレクトリには、マッチングに必要な情報が一時的に格納される。
「account」ディレクトリには、アカウント及び/又はユーザ認証に必要な情報を記述した「user_account.xml」ファイルが格納される。「user_account.xml」ファイルには、例えばユーザを特定するための情報として、ユニークなアカウント名(例えば、ユーザが指定するユーザID)とその認証情報(例えば、パスワード、指紋の特徴量、及び/又は顔の特徴量)とが暗号化されて記録されている。
アカウント名としてはユーザが指定するユーザIDに限定されず、マッチングアプリを利用するユーザを個別に識別可能な情報が採用されればよい。例えば、マッチングアプリのプログラムに埋め込まれた、又はマッチングアプリに付随して配布された、マッチングアプリの個体別にユニークなシリアルコードが採用されてもよい。個体別にユニークなシリアルコードとは、マッチングアプリをインストールする情報端末100毎にユニークに付与されたシリアルコードである。或いは、アカウント名としては、マッチングアプリの初回起動時又は初回登録時に、マッチングアプリが乱数に基づいて生成したユニークなアカウント名が採用されてもよい。この場合、マッチングアプリは、例えば、既に登録済みアカウント名と重複していないことを第1サーバ200に確認することで、アカウント名を自動生成すればよい。
このようにアカウント名として人が見て無意味な文字列情報が設定されることにより、秘匿性がより高められた個人情報の通信が可能となる。
「main」ディレクトリには、マッチングアプリの基本機能を実現するために必要なコンテンツ情報を記述した「main.html」ファイルと、その画面表示のスタイル(例えば、UIデザイン)を記述した「main.css」ファイルとが格納されている。
レストランB系列の第2サーバ300には、返信するコンテンツ情報を記述した「ResB.html」ファイルと、そのコンテンツ情報の画面表示のスタイル(例えば、UIデザイン)を記述した「ResB.css」ファイルとがある。例えば図13に示す標準メニュー情報D1は「ResB.html」ファイルに含まれてもよい。または、標準メニュー情報D1は、「ResB.html」ファイルにて参照される外部ファイルに格納されてもよい。
第1サーバ200には、このユーザの多種多様で膨大な個人情報が分散暗号化されて蓄積されている。例えば、本開示で利用したユーザの注文履歴データベースD2は、「userID_FoodHistory_1.json」ファイル、「userID_FoodHistory_2.json」ファイル、...、「userID_FoodHistory_N.json」ファイルというN個のJSONフォーマットのファイルとして、第1サーバ200内の物理的に異なるストレージ装置に保管されていてもよい。N個のファイルにおいて、ファイル名の先頭部分の「userID」はユーザを特定するための識別情報であり、続く「FoodHistory」は図12で説明した注文履歴データベースD2を特定するための識別情報であり、最後の数字は分断したファイルの識別番号である。
第1サーバ200は、ユーザの注文履歴のリクエストを適切なパーミッション(例えば、アクセス許可情報)と共に受信できれば、これらN個のファイルから正しくデータを復元し、所定の記述フォーマット(.json)に変換して暗号化し、情報端末100へ返信できる。
以下、図19のフローチャートに従いながら、マッチングアプリがHTMLを用いて画面制御を行う場合のファイルの取り扱いについて説明する。図19は、マッチングアプリが起動してから個別メニュー画像を表示するまでのファイルに対するマッチングアプリの処理の一例を示すフローチャートである。
ステップS201において、マッチングアプリが起動し、ホーム画面を描画する。マッチングアプリは、起動直後に「main」ディレクトリにある「main.html」ファイルと「main.css」ファイルとを用いてホーム画面を描画する。これにより、図5に示すホーム画面G3が描画される。
ステップS202において、マッチングアプリは、ホーム画面G3を閲覧するユーザからマップ画面G4を表示させる指示を受け付ける。
ステップS203において、マッチングアプリは、パブリック情報サーバ500に対して現在の地点の周辺地図情報の取得要請を行い、周辺地図情報を示すマップ画面G4を表示する。
ステップS204において、マッチングアプリは、第1サーバ200に対して周辺地図情報が示す地域内の店舗情報の取得要請を行い、店舗情報をマップ画面G4に表示する。これにより、店舗を示すアイコン3210等が表示される。
ステップS205において、マッチングアプリは、ユーザからレストランB系列の店舗B1を選択する指示を受け付ける。
ステップS206において、マッチングアプリは、第1サーバ200に対してレストランB系列の個別メニュー情報の取得要請を行う。
ステップS207において、第1サーバ200は、レストランB系列の第2サーバ300に対して、レストランB系列の標準メニュー情報(ResB.html、ResB.css)の取得要請を行う。
ステップS208において、第1サーバ200は、該当するユーザの注文履歴からレストランB系列の個別メニュー情報を生成する。生成された個別メニュー情報は、「Custom_ResB.html」ファイルとして、新規に「matching_temp」ディレクトリの下に記録される。
ステップS209において、第1サーバ200は、マッチングアプリに対してレストランB系列の個別メニュー情報を送信する。
このようにHTML/CSSファイルを用いて各種画面が描画されている。そのため、単一のマッチングアプリから、不特定多数の事業者が提供する商品又はサービスのうち、ユーザの膨大且つ多様な個人情報と適合する商品又はサービスを提示する場合において、当該事業者が期待する情報を、当該事業者が期待するスタイル(例えば、UIデザイン)で表示させることができる。
個別メニューからの飲食品の注文が終了したユーザによって、表示画面がマッチングアプリのホーム画面に戻された時、又は個別メニューからの飲食品の注文が終了してから所定時間が経過した時、「matching_temp」ディレクトリに一時保管されていたファイルは安全のため全て消去されてもよい。
(実施の形態2)
実施の形態1は、個別メニュー情報の生成主体が第1サーバ200であった。実施の形態2は、個別メニュー情報の生成主体が情報端末100であることを特徴とする。
なお、実施の形態2において、実施の形態1と同一の構成要素については同一の符号を付し、説明を省く。
まず、図2を参照して、実施の形態2の構成について説明する。実施の形態2では、個別メニュー情報が情報端末100で生成されるため、以下、情報端末100の構成を中心に説明する。
情報端末100のGPSセンサー107は情報端末100の位置情報を取得する。通信部101は、取得した位置情報をパブリック情報サーバ500(第3サーバ)に送信する。パブリック情報サーバ500は、受信した位置情報が示す地点を含む地域に存在する一以上のレストランを表すレストラン情報(店舗情報)を取得する。
ディスプレイ105は、店舗情報を含むマップ画面G4を表示する。
情報端末100の操作部106(入力デバイスの一例)は、マップ画面G4を通じて、第2レストランを示す店舗IDを選択する操作を受け付ける。
演算部104は、通信部101を用いて店舗IDが示す第2レストランに関連する第2サーバ300から、第2レストランのメニュー情報(標準メニュー情報)を取得する。
情報端末100の演算部104は、通信部101を用いて、ユーザのユーザIDに対応する嗜好情報を第1サーバ200から取得する。
演算部104は、嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にてメニュー内容を配列する。
演算部104は、配列されたメニュー内容のメニュー情報(個別メニュー情報)をディスプレイ105に表示する。
演算部104は、第2レストランを選択したユーザによる第2レストランでの注文履歴がない場合、嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第2レストランが属する系列を初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
一方、演算部104は、第2レストランを選択したユーザによる第2レストランでの注文履歴がある場合、第2レストランでの注文履歴及び第2レストランの標準メニュー情報に基づき、第2レストランでの注文履歴に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第2レストランを過去に利用したことがある場合、第2レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
なお、演算部104は、第2レストランを選択したユーザによる第2レストランでの注文履歴が所定量に満たない場合、当該ユーザのユーザIDに対応する嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第2レストランでの注文履歴が所定量に満たない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所定量は、ユーザが第2レストランに行きつけているとみなされる予め定められた値、又は第2レストランに初めて来店したとみなせる予め定められた値を有する。
一方、演算部104は、第2レストランを選択したユーザによる第2レストランでの注文履歴が所定量以上である場合、第2レストランでの注文履歴及び第2レストランの標準メニュー情報に基づき、第2レストランでの注文履歴に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第2レストランでの注文履歴が所定量以上の場合、ユーザは、第2レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
さらに、演算部104は、第2レストランを選択したユーザによる第2レストランでの直近の注文履歴が所定期間より前である場合、当該ユーザのユーザIDに対応する嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第2レストランに久しく来店していない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所期間は、例えば、現在から過去3年、2年、1年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。
さらに、演算部104は、該当するユーザの設定期間内での第2レストランでの注文回数が一定回数以下である場合、該当するユーザのユーザIDに対応する嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、設定期間内の第2レストランにおける注文回数が一定回数以下の場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。設定期間は、例えば、現在から過去3年、2年、1年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。一定回数は、ユーザが第2レストランに行きつけているとみなされる予め定められた値、又は第2レストランに実質的に初めて来店したとみなせる予め定められた値を有する。
図20は、実施の形態2において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。図20において図16と同一の処理については同一の符号を付し、説明を省略する。ステップS21~S26は、図16と同じである。
ステップS26に続くステップS301において、情報端末100(マッチングアプリ)は、店舗B1の個別メニュー情報の取得要請を第2サーバ300に送信する。この取得要請には店舗B1の店舗ID及び情報端末100のユーザID等が含まれる。
この取得要請を受信したレストランB系列の第2サーバ300は、店舗B1の標準メニュー情報を情報端末100に送信する。これにより、情報端末100はレストランB系列の標準メニュー情報を受信する(ステップS302)。ここで送信されるレストランB系列の標準メニュー情報は、レストランB系列の各店舗で共通のメニュー情報であってもよいし、レストランB系列の各店舗で一部分が異なるメニュー情報であってもよい。
ステップS303において、レストランB系列の標準メニュー情報を受信した情報端末100は、該当するユーザの注文履歴(嗜好情報の一例)の取得要請を第1サーバ200に送信する。この取得要請を受信した第1サーバ200は、該当するユーザの注文履歴をメモリ203から読み出し、情報端末100に送信する。ここで、第1サーバ200は、ユーザIDが示すユーザが許諾ユーザであるか否か判断しても良い。そして、第1サーバ200は、許諾ユーザと判断した場合、メモリ203から該当するユーザの注文履歴を読み出して、情報端末100に送信すればよい。一方、第1サーバ200は、ユーザIDが示すユーザが許諾ユーザでないと判定した場合、個人情報のアクセスが不可能であることを示す情報を情報端末100に送信すればよい。
なお、第1サーバ200は、許諾ユーザではないと判定した場合、個人情報の読み出しを許可するか否かを確認するメッセージを情報端末100に送信してもよい。このメッセージに応じて情報端末100から許可する旨の情報が送信された場合、第1サーバ200は、該当するユーザの注文履歴をメモリ203から読み出し、情報端末100に送信すればよい。
ステップS304において、情報端末100は、注文履歴を受信する。
ステップS305において、情報端末100は、該当するユーザの注文履歴に基づいて店舗B1における該当するユーザの個別メニュー情報を生成する。
具体的には、第1サーバ200は、レストランB系列での該当するユーザの注文履歴が上述の参照条件C1を満たさない場合(例えば該当するユーザがレストランB系列に初めて来店したとみなせる場合)、レストランB系列の店舗B1が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗B1における個別メニュー情報を生成する。
一方、第1サーバ200は、レストランB系列での該当するユーザの注文履歴が参照条件C1を満たしている場合(例えば該当するユーザがレストランB系列に行きつけているとみなせる場合)、レストランB系列での該当するユーザの注文履歴を用いて店舗B1における該当するユーザの個別メニュー情報を生成する。この処理の詳細は、図17に示すフローチャートを用いて上述した。
ステップS305までの処理において、情報端末100に表示される各種画面は第1サーバ200の管理者(情報銀行)のスタイルでデザインされたものが使用される。一方、ステップS306からの処理においては、情報端末100に表示される各種画面はレストランB系列のスタイルでデザインされたものが使用される。
ステップS306において、情報端末100は、受信した店舗B1の個別メニュー情報を示す個別メニュー画面G5,G6を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップS307において、情報端末100は、注文された飲食品を示す注文情報を第2サーバ300に送信する。この注文情報を受信した第2サーバ300は、例えば店舗B1の店舗端末のディスプレイに注文情報を表示する等して、店舗B1のスタッフに調理の開始を通知する(ステップS36)。
ステップS308において、情報端末100は、注文情報をさらに第1サーバ200に送信する。
注文情報を受信した第1サーバ200は、注文情報をメモリ203に記憶することで、該当するユーザの注文履歴を更新する(ステップS35)。
このように、実施の形態2によれば、情報端末100が個別メニュー情報を生成する場合であっても、ユーザの許諾がない事業者に対して嗜好情報が渡らないようにしながらも、ユーザが初めて利用する第2レストランにおいて、ユーザの嗜好情報が考慮されたメニュー情報を表示できる。
(変形例)
上記の説明は一例に過ぎず、本開示は当該技術者による様々な応用が適用されてもよい。以下の変形例は後述の実施の形態3~6にも適用可能である。
(1)第1サーバ200は、ユーザがマップ画面G4から選択したレストランB系列の店舗B1に対する注文情報を取得した場合、情報端末100の現在の地点をモニタし、情報端末100と店舗B1との距離が一定距離以下になった場合、注文情報をレストランB系列の第2サーバ300に送信してもよい。これにより、店舗B1はユーザが来店するタイミングに飲食品を提供することが可能となる。
(2)上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されても良い。各構成要素は、CPUまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されても良い。
(3)図13の標準メニュー情報D1に示される期間限定の飲食品については、カウント値は算出されなくてもよい。すなわち、標準メニュー情報において、「期間限定」がNOの飲食品についてのみカウント値を算出し、その結果に基づいて個別メニュー情報が生成されてもよい。
(4)本開示では、過去に注文をしたことがない、または注文の回数が少ない第2レストラン系列の店での個別メニュー情報の作成のために、過去に注文を行ったことがある第1レストラン系列の店における注文履歴などの個人情報と、第2レストラン系列の店で提供している飲食品の名称と第1レストラン系列の店で提供している飲食品の名称との比較結果を利用する場合を例に挙げて説明した。しかしながら、第1サーバ200が個別メニュー情報の作成のために個人情報と組み合わせて利用する情報は、上記の例に限られない。
例えば、第1サーバ200は、第1レストラン系列の店と第2レストラン系列の店の両方で注文したことがある複数のユーザの購入履歴などを集めたビッグデータから推測される統計情報を用いて、個別メニュー情報を生成してもよい。この場合、第1サーバ200は、例えば、サービスを利用中のユーザの個人情報から、当該ユーザが第1レストラン系列の店で飲食品Aの注文頻度が高いと判定された場合に、ビッグデータの分析で得られた「第1レストラン系列の店で飲食品Aを注文するユーザは、第2レストラン系列の店で飲食品Xを注文する頻度が高い」という統計情報に基づいて、飲食品Xの表示順序を上位にするなど、飲食品Xが優先的に表示される個別メニュー情報を生成する。
なお、ここではビッグデータを分析して得られた情報を統計情報と呼んでいるが、名称はこれに限定されない。例えば、第1レストラン系列の店で提供される飲食品と、第2レストラン系列の店で提供される飲食品との相関関係を示す相関関係情報と呼んでもよいし、単にビッグデータを用いて生成された情報などと呼んでもよい。また、ビッグデータとして用いられる他のユーザから取得された情報は、例えば、ユーザを特定できない状態の匿名情報に変換してから分析などに用いられてもよい。また、第1サーバ200は、上記の統計情報の生成する際に、個別メニューの生成に用いられるサービスを利用中のユーザに対応付けられた個人情報を匿名化して用いてもよい。
(5)本開示では、第1サーバ200が、ユーザの購買履歴などから推定されたユーザの嗜好情報に応じた順序で飲食品を配列した個別メニュー情報を生成する例を挙げて説明した。以下では、第1サーバ200が、端末機器において個別メニューとして表示される飲食品の順序を、個別メニュー情報を介して制御または指定する方法について、いくつか例を挙げて説明する。すなわち、第1サーバ200が、第1レストランにて注文した注文履歴を含むユーザの嗜好情報及び第2レストランのメニュー情報に基づき、前記嗜好情報に対応した順序にて前記第2レストランのメニュー情報に含まれるメニュー内容を端末機器の表示画面において配列するための個別メニュー情報を生成し、前記個別メニュー情報を前記端末機器に送信し、前記端末機器の前記表示画面において前記順序にて配列されたメニュー内容のメニュー情報を表示させる、情報提供方法について、いくつか例を挙げて説明する。ただし、上記実施の形態において適用可能な、第1サーバ200が個別メニューとして表示される飲食品の順序を制御または指定する方法は、以下の例に限定されるものではない。すなわち、第1サーバ200が、注文履歴などの個人情報から推定された嗜好情報に応じて個別メニューとして表示される飲食品の順序を変更することができる方法であれば、どのような方法を用いてもよい。
第1の例では、第1サーバ200は、個別メニュー情報を生成する際に、メニュー内容である各飲食品を表示する順序で個別メニュー情報に格納する。
第2の例では、第1サーバ200は、個別メニュー情報を生成する際に、個別メニューとして表示する飲食品ごとに、当該飲食品の画面上での表示位置を直接指定する。
第3の例では、第1サーバ200は、個別メニューとして表示する飲食品ごとに、当該飲食品の表示順序を対応付けて個別メニュー情報に格納しておく。この場合、個別メニュー情報を受信した端末機器側のアプリ又はブラウザは、例えば、個別メニューを表示する領域の大きさ又はユーザによって指定されたフォントの表示サイズなどに応じて表示する飲食品の数と、各表示順序に対応する飲食品の表示サイズと、各表示順序に対応する飲食品の表示位置などを所定の表示画面生成ルールに基づいて決定し、個別メニュー情報に含まれる表示順序に従って各飲食品を示すオブジェクトを配置して個別メニューの表示画面を生成すればよい。
第4の例では、第1サーバ200は、個別メニュー情報に飲食品の表示順序を直接格納するのではなく、ユーザの個人情報に基づいて生成され、且つ飲食品の表示順序を決定するために利用可能な一または複数のパラメータを飲食品ごとに個別メニュー情報に格納してもよい。この場合、個別メニュー情報を受信した端末機器側のアプリ又はブラウザは、上記の一または複数のパラメータから、所定の表示順序導出ルール又はユーザが複数の候補の中から指定した表示順序導出ルールに従って、飲食品の表示順序を導出する。本構成によると、生成された個別メニュー情報に従って端末機器側のアプリ又はブラウザが単純に個別メニューの表示画面を表示するのではなく、ユーザが利用する端末機器の種類又はユーザによる設定に従って、個別メニューの表示方法又は表示する飲食品の表示順序を調整することが可能になるため、より柔軟なサービスの提供を促進することができる。
(6)本開示では、マッチングアプリの画面表示でスタイルを変更する例として、例えば拡張子が「.css」などであるUIデザインを規定したファイルを複数準備して、表示に用いるUIデザインを規定したファイルを切り替えることでスタイルを変更する態様を例に挙げて説明した。しかしながら、スタイルの変更は表示に用いるUIデザインを規定したファイルを切り替える態様以外の方法で実現されてもよい。例えば、スタイルの変更は、マッチングアプリ内の表示においてレストランA系列、レストランB系列がそれぞれ独自にメニュー画面に用いる文字のフォントやサイズ、背景および文字の色、ロゴ、メニュー画像、ボタンのデザイン、メニューの配置、メニューの表示サイズ、並びに料理の選択や注文の確定などを行うためのUIなどのいずれか一つまたは複数の組み合わせを独自に設定することで実現されてもよい。上述した、メニュー画面に用いる文字のフォントやサイズ、背景および文字の色、ロゴ、メニュー画像、ボタンのデザイン、メニューの配置、メニューの表示サイズ、並びに料理の選択や注文の確定などを行うためのUIなどは、例えばレストランA系列、レストランB系列などのマッチングアプリを利用してサービスを提供する各事業者が提供しているHTMLファイルで設定することができる。このとき、マッチングアプリの個別メニュー表示画面において、CSSファイルはマッチングアプリが指定したものを用いるが、個別メニューの表示に提供される画面領域に表示するHTMLファイルはサービスを提供する事業者が提供するファイルを利用する。これにより、マッチングアプリのウィンドウやフレームのデザインはマッチングアプリの他の表示画面と共通となり、個別メニューが表示される画面領域のデザインはサービスを提供する事業者毎に設定することが可能となる。その結果、ユーザは注文を行おうとするサービスの提供事業者がレストランA系列であるのかレストランB系列であるのかを容易に判別できるようになる。さらに、個別メニュー画面のスタイルはサービス提供事業者が設定できるにもかかわらず、管理者(情報銀行)が管理する異なるレストラン系列での注文履歴を含む嗜好情報に基づいて、表示するメニューの位置や順番を変更することが可能となり、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
(7)本開示では、マッチングアプリが系列の異なるレストランでの注文履歴を含む嗜好情報を用いると説明したが、系列が異なるレストランは複数のチェーンストアを有するレストランである必要はない。例えば、マッチングアプリが利用する注文履歴は、複数のチェーンストアを有さない1店舗だけのレストランの注文履歴であってもよい。すなわち、本開示によると、異なるメニューを提供する複数のレストラン間で、他のレストランにおける注文履歴を含む嗜好情報に基づいて、表示するメニューの位置や順番を変更することが可能となり、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
以上の(1)~(7)の変形例は、情報端末100が個別メニュー情報を生成する態様を採用した場合についても適用可能である。
以上、1つまたは複数の態様に係る情報提供システム及び情報提供方法について、実施の形態に基づいて説明したが、本開示は、この実施の形態に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本開示の範囲に含まれても良い。
(実施の形態3)
実施の形態1は、個別メニュー情報の生成主体が第1サーバ200であった。実施の形態3は、個別メニュー情報の生成主体が第2サーバ300であることを特徴とする。実施の形態3の情報提供システムは第2サーバ300を含む情報管理システムを含む。
なお、実施の形態3において、実施の形態1と同一の構成要素については同一の符号を付し、説明を省く。
まず、図2を参照して、実施の形態3の構成について説明する。実施の形態3では、個別メニュー情報が第2サーバ300で生成されるため、以下、第2サーバ300の構成を中心に説明する。
第2サーバ300の通信部301は、情報端末100から情報端末100のユーザを特定する識別情報を受信する。加えて第1レストランと系列が異なる第2レストランを示す店舗IDを受信しても良い。この店舗IDは、情報端末100を操作するユーザが選択した店舗の識別情報(レストランの系列情報かつ/または店舗を特定する情報を含む)である。通信部301は、演算部302が生成した個別メニュー情報を第2レストランを選択したユーザの情報端末100に送信する。
第2サーバ300の演算部302は、受信したユーザIDに対応する嗜好情報を第1サーバ200から取得する。ここで、嗜好情報は、第2サーバ300に対してユーザが嗜好情報のアクセスを許可している場合に第1サーバ200から送信される。これにより、ユーザの個人情報がユーザの許可なく第1サーバ200の外部に漏洩することを防止できる。一方、第2サーバ300又は第2サーバ300を利用するレストラン系列に対してユーザが嗜好情報のアクセスを不許可にしている場合、嗜好情報は第1サーバ200から送信されない。この場合、第2サーバ300は、第2レストランの標準メニューを情報端末100に送信してもよい。
演算部302は、メモリ303から第2レストランの標準メニュー情報を取得し、嗜好情報及び標準メニュー情報に基づき、嗜好情報に対応した順序にてメニュー内容を配列する。
演算部302は、配列されたメニュー内容のメニュー情報(個別メニュー情報)を通信部301を用いて情報端末100に送信する。これにより、情報端末100のディスプレイ105に個別メニューが表示される。
演算部302は、第2レストランを選択したユーザによる第2レストランでの注文履歴がない場合、嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第2レストランが属する系列を初めて利用する場合であっても、効率的に自己の嗜好に合った飲食品を選択できる。
一方、演算部302は、第2レストランを選択したユーザによる第2レストランでの注文履歴がある場合、第2レストランでの注文履歴及び第2レストランの標準メニュー情報に基づき、第2レストランでの注文履歴に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成する。これにより、ユーザは、第2レストランを過去に利用したことがある場合、第2レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
なお、演算部302は、第2レストランを選択したユーザによる第2レストランでの注文履歴が所定量に満たない場合、当該ユーザのユーザIDに対応する嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第2レストランでの注文履歴が所定量に満たない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所定量は、ユーザが第2レストランに行きつけているとみなされる予め定められた値、又は第2レストランに初めて来店したとみなせる予め定められた値を有する。
一方、演算部302は、第2レストランを選択したユーザによる第2レストランでの注文履歴が所定量以上である場合、第2レストランでの注文履歴及び第2レストランの標準メニュー情報に基づき、第2レストランでの注文履歴に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第2レストランでの注文履歴が所定量以上の場合、ユーザは、第2レストランの注文履歴が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。
さらに、演算部302は、第2レストランを選択したユーザによる第2レストランでの直近の注文履歴が所定期間より前である場合、当該ユーザのユーザIDに対応する嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、第2レストランに久しく来店していない場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。所定期間は、例えば、現在から過去3年、2年、1年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。
さらに、演算部302は、該当するユーザの設定期間内での第2レストランでの注文回数が一定回数以下である場合、該当するユーザのユーザIDに対応する嗜好情報及び第2レストランの標準メニュー情報に基づき、嗜好情報に対応した順序にて第2レストランの標準メニュー情報に含まれるメニュー内容が配列された個別メニュー情報を生成してもよい。これにより、設定期間内の第2レストランにおける注文回数が一定回数以下の場合であっても、ユーザは、嗜好情報が反映された個別メニュー情報を用いて自己の嗜好に合った飲食品を効率的に選択できる。設定期間は、例えば、現在から過去3年、2年、1年などの有限の期間が採用されてもよいし、無制限の期間であってもよい。一定回数は、ユーザが第2レストランに行きつけているとみなされる予め定められた値、又は第2レストランに初めて来店したとみなせる予め定められた値を有する。
続いて、第1サーバ200について説明する。第1サーバ200のメモリ203は、各ユーザに対するアクセス情報を記憶する。アクセス情報は、ユーザが第2サーバ300に対して自身の嗜好情報のアクセスを許可するか否かを示す情報である。アクセス情報は、アクセス許可、アクセス不許可、及び未設定のいずれかを含む。
ある1のユーザの第2サーバ又は第2サーバ300を利用する事業者へのアクセス情報がアクセス許可に設定されている場合、通信部201が第2サーバ300又は第2サーバ300を利用する事業者から当該1のユーザについての嗜好情報の取得要請を受信すると、演算部202は、当該1のユーザの嗜好情報を第2サーバ300又は第2サーバ300を利用する事業者に送信する。ある1のユーザの第2サーバ300又は第2サーバ300を利用する事業者へのアクセス情報がアクセス不許可に設定されている場合、通信部201が第2サーバ300又は第2サーバ300を利用する事業者から当該1のユーザについての嗜好情報の取得要請を受信すると、演算部202は、当該1のユーザの嗜好情報を第2サーバ300に送信しない。ある1のユーザのアクセス情報が未設定の場合、通信部201が第2サーバ300又は第2サーバを利用する事業者からの当該1のユーザについての嗜好情報の取得要請を受信すると、演算部202は、通信部201を用いて、嗜好情報に対するアクセスを許可するか否かの問い合わせメッセージを情報端末100に送信する。
図21は、実施の形態3において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の一例を示すシーケンス図である。図21において図16と同一の処理については同一の符号を付し、説明を省略する。なお、図21では、ユーザは自身の嗜好情報(注文履歴)に対する第2サーバ300又は第2サーバ300を利用するレストランB系列のアクセス情報を未設定にしているものとする。
ステップS21~S26は、図16と同じである。
ステップS26に続くステップS301において、情報端末100(マッチングアプリ)は、店舗B1の個別メニュー情報の取得要請を第2サーバ300に送信する。この取得要請には店舗B1の店舗ID及び情報端末100のユーザID等が含まれる。
ステップS302において、第2サーバ300はメモリ303からレストランB系列の標準メニュー情報を取得する。ここで取得されるレストランB系列の標準メニュー情報は、レストランB系列の各店舗で共通のメニュー情報であってもよいし、レストランB系列の各店舗で一部分が異なるメニュー情報であってもよい。
ステップS303において、第2サーバ300は、該当するユーザの注文履歴(嗜好情報の一例であって、嗜好情報を表現した情報であれば良い)の取得要請を第1サーバ200に送信する。
ステップS304において、第1サーバ200は、メモリ203から該当するユーザのアクセス情報を読み出し、該当するユーザに関してレストランB系列に対するアクセス情報が未設定であることを確認する。
ステップS305において、第1サーバ200は、レストランB系列に対して注文履歴のアクセスを許可するか否かの問い合わせメッセージを情報端末100に送信する。問い合わせメッセージは情報端末100のディスプレイ105に表示される。
ステップS306において、情報端末100は、問い合わせメッセージを確認したユーザからアクセス情報をアクセス許可に選択する操作を受け付ける。
ステップS307において、情報端末100は、アクセス情報がアクセス許可に選択されたことを示す通知情報を第1サーバ200に送信する。
ステップS308において、アクセス許可が選択されたことを示す通知情報を受信した第1サーバ200は、メモリ203に記憶された該当するユーザのレストランB系列に対するアクセス情報をアクセス許可に設定する。これにより、第1サーバ200は、該当するユーザの注文履歴をメモリ203から読み出し、第2サーバ300に送信する。
ステップS309において、第2サーバ300は、該当するユーザの注文履歴を受信する。
ステップ310において、第2サーバ300は、該当するユーザの注文履歴に基づいて店舗B1における該当するユーザの個別メニュー情報を生成する。
具体的には、第2サーバ300は、レストランB系列での該当するユーザの注文履歴が上述の参照条件C1を満たさない場合(例えば、該当するユーザがレストランB系列に初めて来店したとみなせる場合)、レストランB系列の店舗B1が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗B1における個別メニュー情報を生成する。
一方、第2サーバ300は、レストランB系列での該当するユーザの注文履歴が参照条件C1を満たしている場合(例えば、該当するユーザがレストランB系列に行きつけているとみなせる場合)、レストランB系列での該当するユーザの注文履歴を用いて店舗B1における該当するユーザの個別メニュー情報を生成する。この処理の詳細は、図17に示すフローチャートを用いて上述した。第2サーバ300は、生成された個別メニュー情報を情報端末100に送信する。
ステップS311において、情報端末100は、個別メニュー情報を受信する。
ステップS311までの処理において、情報端末100に表示される各種画面は第1サーバ200の管理者(情報銀行)のスタイルでデザインされたものが使用される。一方、ステップS312からの処理においては、情報端末100に表示される各種画面はレストランB系列のスタイルでデザインされたものが使用される。または、レストランB系列の料理を説明する文字及び写真を第1サーバ200の管理者のスタイルでレイアウトしたものが使用されても良い。
ステップS312において、情報端末100は、受信した店舗B1の個別メニュー情報を示す個別メニュー画面G5,G6を表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップS313において、情報端末100は、注文された飲食品を示す注文情報を第2サーバ300に送信する。この注文情報を受信した第2サーバ300は、例えば店舗B1の店舗端末のディスプレイに注文情報を表示する等して、店舗B1のスタッフに調理の開始を通知する(ステップS36)。なお、この処理は次のステップS314により注文情報を受信した第1サーバ200が、第2サーバ300へ送信することで代替しても良い。
ステップS314において、情報端末100は、注文情報をさらに第1サーバ200に送信する。
注文情報を受信した第1サーバ200は、注文情報をメモリ203に記憶することで、該当するユーザの注文履歴を更新する(ステップS35)。
図22は、実施の形態3において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理の他の一例を示すシーケンス図である。
図22において図21と同一の処理については同一の符号を付し、説明を省略する。なお、図22では、ユーザは自身の嗜好情報(注文履歴)に対するレストランB系列のアクセス情報をアクセス許可に設定しているものとする。
ステップS21~S26、ステップS301~S303までの処理は、図21と同じである。
ステップS303に続くステップS401において、該当するユーザの注文履歴の取得要請を受信した第1サーバ200は、メモリ203から該当するユーザのアクセス情報を読み出し、該当するユーザに関してレストランB系列(又はレストランB系列が利用する第2サーバ300)に対するアクセス情報がアクセス許可に設定されていることを確認する。これにより、第1サーバ200は、該当するユーザの注文履歴をメモリ203から読み出し、第2サーバ300に送信する。
ステップS309以降の処理は図21と同じである。
図23は、実施の形態3において、ユーザが初めて来店するレストラン系列の店舗であるか否かを考慮してユーザからの飲食品の注文を受け付ける場合の情報提供システムの処理のさらに他の一例を示すシーケンス図である。
図23において図21と同一の処理については同一の符号を付し、説明を省略する。なお、図23では、ユーザは自身の嗜好情報(注文履歴)に対するレストランB系列のアクセス情報を未設定にしているものとする。
ステップ21~S26及びステップS301~S305の処理は図21と同じである。ステップS305に続くステップS501において、情報端末100は、問い合わせメッセージを確認したユーザからアクセス情報をアクセス不許可に選択する操作を受け付ける。
ステップS502において、情報端末100は、アクセス情報がアクセス不許可に選択されたことを示す通知情報を第1サーバ200に送信する。
ステップS503において、アクセス不許可が選択されたことを示す通知情報を受信した第1サーバ200は、メモリ203に記憶された該当するユーザのレストランB系列又はレストランB系列が利用する第2サーバ300へのアクセス情報をアクセス不許可に設定する。これにより、第1サーバ200は、第2サーバ300に対して要求エラーを送信する。要求エラーは第2サーバ300に対して、注文履歴の取得要求に応答することができないことを通知するための情報である。
ステップS504において、第2サーバ300は、要求エラーを受信する。要求エラーを受信した第2サーバ300は、メモリ303からレストランB系列の標準メニュー情報を読み出し、読み出した標準メニュー情報と要求エラーとを情報端末100に送信する。
ステップS505において、情報端末100は、標準メニュー情報と要求エラー(レストランB系列がユーザの嗜好情報(注文履歴)へのアクセス不許可と設定されたことを示す情報)とを受信する。
ステップS506において、情報端末100は、個別メニューが生成できなかったことを示す情報と、標準メニュー画面G7とをディスプレイ105に表示し、ユーザから注文する飲食品を選択する指示を受け付ける。
ステップS313以降の処理は図21と同じである。
このように、実施の形態3によれば、第2サーバ300が個別メニュー情報を生成する場合であっても、ユーザの許諾がない事業者に対して嗜好情報が渡らないようにしながらも、ユーザが初めて利用する第2レストランにおいて、ユーザの嗜好情報が考慮されたメニュー情報を表示できる。
(実施の形態4)
実施の形態4は、個別メニュー情報の生成主体が第1サーバ200である場合において、第1サーバ200が標準メニュー情報を事前取得することを特徴とする。
なお、実施の形態4において、実施の形態1~3と同一の構成要素については同一の符号を付し、説明を省く。
まず、図2を参照して、実施の形態4の構成について説明する。実施の形態4では、個別メニュー情報が第1サーバ200で生成されるため、以下、第1サーバ200の構成を中心に説明する。
演算部202は、情報端末100から店舗IDが取得される前に、店舗IDが示す第2レストランに関連する第2サーバ300からネットワークを介してメニュー情報を取得し、取得したメニュー情報をメモリ203に記憶する。
次に、実施の形態4の処理について説明する。図24は、実施の形態4における情報提供システムの処理の一例を示すシーケンス図である。図24において図16と同一の処理については同一の符号を付し、説明を省略する。ステップS21~S27、S31~S36の処理は、図16と同じである。
実施の形態4は、第1サーバ200が、店舗IDを取得(ステップS27)する前に標準メニュー情報を事前取得するものである。そのため、図24では、図16の標準メニュー情報を取得する処理(ステップS28、S29)が省かれ、その代わりに先頭にステップS601、S602の処理が設けられている。
ステップS601において、第2サーバ300は、標準メニュー情報を更新し、更新した標準メニュー情報を第1サーバ200へ送信する。ステップS602において、第1サーバ200は標準メニュー情報を受信し、その標準メニュー情報をメモリ203に記憶する。
これにより、第1サーバ200は、個別メニュー情報の取得要請を受信すると速やかに個別メニュー情報を生成できる。
ステップS30aにおいて、店舗B1の個別メニュー情報の取得要請を受信した第1サーバ200は、メモリ203から店舗B1の標準メニュー情報を読み出し、読み出した標準メニュー情報と、該当するユーザの注文履歴とに基づいて店舗B1における該当するユーザの個別メニュー情報を生成する。
具体的には、第1サーバ200は、レストランB系列での該当するユーザの注文履歴が上述の参照条件C1を満たさない場合(例えば該当するユーザがレストランB系列に初めて来店したとみなせる場合)、レストランB系列の店舗B1が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗B1における個別メニュー情報を生成する。
一方、第1サーバ200は、レストランB系列での該当するユーザの注文履歴が参照条件C1を満たしている場合(例えば該当するユーザがレストランB系列に行きつけているとみなせる場合)、レストランB系列での該当するユーザの注文履歴を用いて店舗B1における該当するユーザの個別メニュー情報を生成する。この処理の詳細は、図17に示すフローチャートを用いて上述した。
なお、図24に示すステップS602に示す標準メニュー情報を送信するタイミングは、個別メニュー情報の取得要請が送信されるタイミング(ステップS27)よりも前であれば、どのようなタイミングであってもよい。
例えば、標準メニュー情報の送信タイミングは、ステップS21以前であっても良いし、ステップS24以後且つステップS27以前、であっても良い。
図24では、標準メニュー情報が更新されたタイミングで標準メニュー情報が送信されているが、これは一例である。例えば、第1サーバ200は、情報端末100から店舗情報の取得要請を受信したときに(ステップS24)、情報端末100で表示され得る店舗の標準メニュー情報を取得してもよい。ここで、表示され得る店舗の一例は、図6に示すマップ画面G4に表示される店舗である。なお、第1サーバ200は、マップ画面G4に表示された各店舗に対応する第2サーバ300に標準メニュー情報の取得リクエストを送信することで、各店舗の標準メニュー情報を取得すればよい。
(実施の形態5)
実施の形態5は、個別メニュー情報の生成主体が情報端末100である場合において、情報端末100が標準メニュー情報を事前取得することを特徴とする。
なお、実施の形態4において、実施の形態1~4と同一の構成要素については同一の符号を付し、説明を省く。
まず、図2を参照して、実施の形態5の構成について説明する。実施の形態5では、個別メニュー情報が情報端末100で生成されるため、以下、情報端末100の構成を中心に説明する。
演算部104は、ユーザによる店舗IDの選択を受け付ける前に店舗IDが示す第2レストランに関連する第2サーバ300からネットワークを介してメニュー情報を取得し、取得したメニュー情報をメモリ102に記憶する。
次に、実施の形態5の処理について説明する。図25は、実施の形態5における情報提供システムの処理の一例を示すシーケンス図である。図25において図20と同一の処理については同一の符号を付し、説明を省略する。ステップS21~S26、S303~S304、S306~S308、S35、S36の処理は、図20と同じである。
実施の形態5は、情報端末100がユーザから店舗B1の選択を受け付ける前に(ステップS26)、標準メニュー情報を事前取得するものである。そのため、図25では、図20の標準メニュー情報を取得する処理(ステップS301、S302)が省かれ、その代わりに先頭にステップS701、S702の処理が設けられている。
ステップS701において、第2サーバ300は、標準メニュー情報を更新し、更新した標準メニュー情報を情報端末100へ送信する。ステップS702において、情報端末100は標準メニュー情報を受信し、その標準メニュー情報をメモリ102に記憶する。
これにより、情報端末100は、ユーザにより店舗B1が選択されると速やかに個別メニュー情報を生成できる。
ステップS305aにおいて、ユーザの注文履歴を受信した情報端末100は、メモリ102から店舗B1の標準メニュー情報を読み出し、読み出した標準メニュー情報と、該当するユーザの注文履歴とに基づいて店舗B1における該当するユーザの個別メニュー情報を生成する。
具体的には、情報端末100は、レストランB系列での該当するユーザの注文履歴が上述の参照条件C1を満たさない場合(例えば該当するユーザがレストランB系列に初めて来店したとみなせる場合)、レストランB系列の店舗B1が提供する飲食品と同一または類似する飲食品に対する該当するユーザの注文履歴を用いて、店舗B1における個別メニュー情報を生成する。
一方、情報端末100は、レストランB系列での該当するユーザの注文履歴が参照条件C1を満たしている場合(例えば該当するユーザがレストランB系列に行きつけているとみなせる場合)、レストランB系列での該当するユーザの注文履歴を用いて店舗B1における該当するユーザの個別メニュー情報を生成する。この処理の詳細は、図17に示すフローチャートを用いて上述した。
なお、図25に示すステップS702に示す標準メニュー情報を送信するタイミングは、情報端末100がユーザから店舗B1の選択を受け付ける前であれば(ステップS26)、どのようなタイミングであってもよい。
例えば、標準メニュー情報の送信タイミングは、ステップS21以前であっても良いし、ステップS24以後かつステップS303以前、であっても良い。
図25では、標準メニュー情報が更新されたタイミングで標準メニュー情報が送信されているが、これは一例である。例えば、情報端末100のマッチングアプリが店舗情報の取得要請を送信したときに(ステップS24)、情報端末100上で表示され得る店舗の標準メニュー情報を取得してもよい。ここで、表示され得る店舗の一例は、図6に示すマップ画面G4に表示される店舗である。なお、情報端末100は、マップ画面G4に表示された各店舗に対応する第2サーバ300に標準メニュー情報の取得リクエストを送信することで、各店舗の標準メニュー情報を取得すればよい。
さらに、情報端末100のマッチングアプリは、情報端末100の現在位置をGPS信号などから捕捉し、近隣地域にある店舗の標準メニュー情報を第2サーバ300に予めリクエストして取得することで、標準メニュー情報を更新するようにしてもよい。
図26は、実施の形態5における情報提供システムの処理の変形例を示す図である。図26において図20と同一の処理については同一の符号を付し、説明を省略する。この変形例では、標準メニュー情報の取得タイミングは図20と同じである。また、この変形例では、嗜好情報である注文情報は第1サーバ200に加えて情報端末100も記憶している。そのため、図26では、情報端末100が第1サーバ200にユーザの注文履歴を取得する処理(ステップS303、S304)は省かれている。
ステップS305bにおいて、標準メニュー情報を取得した情報端末100は、ユーザの注文履歴をメモリ102から読み出し、読み出した注文履歴と標準メニュー情報とを用いてユーザの個別メニュー情報を生成する。
以下、図20と同様、ステップS306、S307、S308、S35、S36の処理が行われる。そして、ステップS309において、情報端末100は、今回の注文情報をメモリ102に記憶することによって、メモリ102に記憶されている注文履歴を更新する。
ユーザの注文履歴の一部(過去の所定期間分など)若しくは全て、又はユーザの食事選択における嗜好情報の一部(注文回数が上位の商品識別情報のみなど)若しくは全てが、情報端末100のメモリ102にセキュアにキャッシュされたり、セキュアに記録・蓄積されたりする、ことも考えられる。これは個人情報が一カ所に集中管理されている集中型PDS(Centralized Personal Data Store)とは異なり、分散型PDS(Decentralized Personal Data Store)とも呼ばれる。この場合は、ステップS306で注文が確定した後に、情報端末100は、メモリ102上にセキュアに注文履歴を蓄積していく(ステップS309)。これによって情報端末100のメモリ102に個人情報(嗜好情報)が蓄積されていき、次回のマッチングにその個人情報が利用することができる。
嗜好情報(注文履歴)を必要とする度に、外部サーバから外部通信ネットワークを介して取得するのではなく、情報端末100内にセキュアに格納された嗜好情報を利用することで、通信経路での嗜好情報の漏洩リスクの回避、外部との通信量(通信料金)の削減、及び個別メニュー情報の生成時間の短縮、といったメリットが期待できる。
尚、図26においても、図25と同様、情報端末100が標準メニュー情報を予め取得しておく特徴を有していてもよい。この場合、情報端末100(マッチングアプリ)は個別メニューを生成する際に必要となるユーザの嗜好履歴(注文履歴)と、レストランB系列の標準メニュー情報との両方をメモリ102から取得して、ステップS305aにおいて個別メニューを生成することができる。
(実施の形態6)
実施の形態6は、個別メニュー画面がユーザの嗜好情報に対応した順序で配列された第1メニュー内容を表示する第1表示領域と、第2レストランが指定する第2メニュー内容を表示する第2表示領域とを含むことを特徴とする。
なお、実施の形態6において、実施の形態1と同一の構成要素については同一の符号を付し、説明を省く。
まず、図2を参照して、実施の形態6の構成について説明する。実施の形態6では、個別メニュー情報が第1サーバ200で生成されるため、以下、第1サーバ200の構成を中心に説明する。
第1サーバ200の演算部202は、ユーザの識別情報に対応する嗜好情報、及びユーザが選択した第2レストランの店舗IDが示す第2レストランのメニュー情報に基づき、嗜好情報に対応した順序にてメニュー情報に含まれる第1メニュー内容を配列する。
メニュー情報は、ユーザの嗜好情報に対応した順序で配列された第1メニュー内容と、第2レストランによって指定された第2メニュー内容とを含み、かつ、店舗IDが示す第2レストランに関連する第2サーバ300からネットワークを介して取得される。
演算部202は、嗜好情報に対応した順序にて配列された第1メニュー内容と、第2メニュー内容とを含むメニュー情報を情報端末100に送信し、情報端末100の表示画面内の第1表示領域に、嗜好情報に対応する順序にて配列された第1メニュー内容を表示させ、かつ、表示画面内の第2表示領域に、第2レストランによって指定された第2メニュー内容を表示させる。
ここで、第2表示領域内における第2メニュー内容の配列は、嗜好情報を使わずに固定されていてもよいし、嗜好情報を使って変動されてもよい。例えば、第2メニュー内容は、第2レストランが指定する商品がユーザの嗜好にしたがって配列されたものであってもよい。
第1メニュー内容は、嗜好情報に対応した順序が第1順序である場合には第1順序に配列されて第1表示領域に表示され、かつ、嗜好情報に対応した順序が第1順序とは異なる第2順序である場合には第2順序に配列されて第1表示領域に表示されてもよい。
第2メニュー内容は、嗜好情報に対応した順序が第1順序または第2順序のいずれの場合でも同じ形態で第2表示領域に表示されてもよい。
図27は、実施の形態6における第1例の個別メニュー画面G11を示す図である。個別メニュー画面G11は、個別メニュー情報の一部の商品(料理)として、ユーザにより指定されたレストラン又は店舗が指定した商品が採用されている。
個別メニュー画面G11において、画面上部に目を引くように表示された「プレミアムランチセット」は特別にレストランBの店舗B1がユーザにオファーした商品であって、それ以外の「アイスクリーム」、「カプチーノ」、「カフェモカ」、「タピオカヨーグルト」は、過去によくユーザが注文していた商品である。
この個別メニュー画面G11では、「アイスクリーム」、「カプチーノ」、「カフェモカ」、「タピオカヨーグルト」の4つの商品は、ユーザの過去の注文履歴(図12又は図14の表)から計算されたユーザの嗜好情報に従った順序で表示されている。例えば、「アイスクリーム」、「カプチーノ」、「カフェモカ」、「タピオカヨーグルト」は、過去の注文回数の多い順に配列されている。この表示順は、上から下の順序であり、上下位置が同じ場合には左から右の順序である。
一方で、「プレミアムランチセット」はこれら4つの商品と比べて過去の注文回数に基づいても、基づかなくても良く、店舗の指定によりこれら4つの商品よりも優先的に個別メニュー画面G11に表示されている。つまり、ユーザの嗜好情報に対応した順序で商品が表示されると説明したが、これは個別メニュー画面G11で表示される商品全体に対してではなく、一部の商品に対してのみ適用されても良い。これによって店舗が販売、宣伝したい商品を任意の表示位置や表示形態にて訴求することができるようになる。また、嗜好情報が一定量たまることで個別メニュー画面に表示される商品が固定化している場合に、アイキャッチーな商品を加えることで新たにユーザの興味を引くことができるようになる。
商品の表示順は、個別メニュー画面G11のトップ画面(初期表示画面)が表示されてから、その商品が情報端末100のディスプレイ上に表示されるために必要となるユーザの操作回数(ページ送りなど)又は商品を表示するために必要となるユーザの操作量(画面スクロールの移動量など)が多くなるほど、順位が低くされてもよい。
優先度が高い表示順を有する商品は、トップ画面からの操作回数又は操作量がより少なくなる画面に表示されても良い。逆に優先度が低い表示順を有する商品は、トップ画面からより多くの操作回数又は操作量を行わなければ表示されない画面に表示されるようにしても良い。
このように個別メニュー情報を情報端末100に表示する場合、ユーザの過去の注文回数、かつ/または、ユーザが商品に対する嗜好情報に応じて、個別メニュー情報のすべての商品がユーザの嗜好情報に対応した順序で表示される必要はない。
個別メニュー画面に少なくとも第1の商品と、第2の商品とが含まれる場合、ユーザが第1の商品を第2の商品よりも嗜好している(例えば過去の注文回数が多い)ことが判明した場合、個別メニュー画面G11では、そのユーザにより嗜好されている第1の商品が、第2の商品よりも優先して表示されるようにしても良い。優先して表示されるとは、例えばより少ない操作回数又は操作量で表示されることを意味する。嗜好情報に従った順序での表示は、個別メニュー情報の全部の商品に適用されてもよいし、一部(少なくとも2つ以上)の商品に適用されてもよい。
なお、嗜好情報の一例は注文履歴であったが、これに限定されず、嗜好の予測値であってもよい。嗜好の予測値は、多くのユーザの嗜好情報を例えば協調フィルタリングにより分析することで得られる。
図28は、実施の形態6における第2例の個別メニュー画面G12を示す図である。図29は、実施の形態6における第3例の個別メニュー画面G13を示す図である。個別メニュー画面G12、G13は、ユーザの嗜好情報に対応した順序で商品をレイアウトすると同時に、店舗が指定する商品をレイアウトする。ここでは、店舗が個別メニュー情報に加えた商品は、「プレミアムランチセット」と「チョコドーナッツ」との2商品である。それ以外の商品はユーザの嗜好情報に対応した順序で表示されている。
例えば、個別メニュー画面G12では、2行目に店舗が加えた「プレミアムランチセット」が表示されている。例えば、個別メニュー画面G13では、2行1列目に店舗が加えた「プレミアムランチセット」と、3行2列目に店舗が加えた「チョコドーナッツ」とが表示されている。
個別メニュー画面G12に示す「プレミアムランチセット」のように、店舗が指定した商品のタイルオブジェクト2801の枠は他のタイルオブジェクトの枠よりも太く表示されてもよいし、デフォルメマーク2802を含めてもよい。また、個別メニュー画面G13に示す「プレミアムランチセット」及び「チョコドーナッツ」のように、店舗が指定した商品のタイルオブジェクト2901は、ハートマーク2902と「お勧め」のメッセージとを含めてもよい。このように、店舗は、指定した商品のタイルオブジェクトを視覚的に識別ができるようにデザインすることができる。これにより、店舗は、指定した商品が、ユーザに宣伝したい商品であることを示すことができる。
このように、個別メニュー画面G12、G13は、ユーザの嗜好情報に対応した順序でレイアウトされる商品群(第1メニュー内容)と、店舗の指定によりレイアウトされる商品群(第2メニュー内容)とを、自由に組み合わされた商品を表示することができる。なお、第1メニュー内容及び第2メニュー内容の表示サイズ、表示レイアウト、1表示領域での商品表示数、などは第1メニュー内容がユーザの嗜好情報に対応した順序でレイアウトされる限りにおいて、任意である。
個別メニュー画面G11、G12、G13を生成する処理は、図17のステップS104の処理に含まれる。
図30及び図31は、実施の形態6における第4例の個別メニュー画面G14を示す図である。個別メニュー画面G14は、タブによってメニュー画面の表示が切り替えられるようにデザインされている。図30の個別メニュー画面G14は、ユーザの嗜好情報に対応した順序で商品が表示される「注文履歴(嗜好順)」タブが選択されている際に表示される画面の一例である。図31の個別メニュー画面G14は、店舗が指定する商品が表示される「お店のお勧め」タブが選択されている際に表示される画面の一例である。タブは他に、ドリンクだけの商品を表示する「ドリンク」タブ、及びランチの時間帯に注文することができる商品を表示する「ランチ」タブ等があってもよい。但し、これは一例であり、「ドリンク」タブ及び「ランチ」タブはなくても良い。
「注文履歴(嗜好順)」タブが選択された場合、情報端末100は図30に示すように、ユーザの嗜好情報に対応した順序で商品を表示する。一方、「お店のお勧め」タブが選択された場合、情報端末100は図31に示すように、店舗が指定するユーザに宣伝したい商品を表示する。
このように、タブによって情報端末100の画面に表示される商品の属性を切り替えることで、ユーザはより容易に所望の商品を探し出すことができる。
図32は、実施の形態6における第5例の個別メニュー画面G15を示す図である。個別メニュー画面G15は、図6のマップ画面G4においてレストランB系列の店舗B1を示すアイコン3210が選択された場合、画面を切り替えることなく、マップ画面G4と、マップ画面G4に表示された店舗の位置と、選択された店舗B1の個別メニュー情報とを表示する。
これまでの説明においては、マップ画面G4及び個別メニュー画面G5、G6、G11~G14は夫々が画面全体を占有して表示されていたが、本開示はこれに限らない。
個別メニュー画面G15に示すように、マップ画面G4上にレストランの店舗が配置され、同時に選択した店舗のメニューとユーザの嗜好情報とがマッチングされた個別メニュー情報が表示されるようにしてもよい。
この場合、ユーザはマップ画面G4を見ながら店舗の位置を確認しつつ、店舗ごとの個別メニュー情報を確認することができるため、画面を切り替えることなく、複数の店舗の個別メニュー情報を素早く確認することが可能となる。
また、実施の形態6では、個別メニュー画面G11~G15は、第1サーバ200が生成したが、本開示はこれに限定されず、情報端末100が生成してもよいし、第2サーバ300が生成してもよい。または、第1サーバ200、情報端末100、第2サーバ300の内、少なくとも2つ以上を用いて生成してもよい。情報端末100が個別メニュー画面G11~G15を生成する場合、情報端末100は実施の形態2又は実施の形態5の処理を用いて個別メニュー画面G11~G15を生成すればよい。第2サーバ300が個別メニュー画面G11~G15を生成する場合、第2サーバ300は、実施の形態3又は実施の形態4の処理を用いて個別メニュー画面G11~G15を生成すればよい。また、第1サーバ200または情報端末100が個別メニュー画面G11~G15を生成する場合、第1サーバ200または情報端末100は、標準メニュー情報を事前取得してもよい。
(補足)
(A-1)本開示において、ID(identification)とは、該当対象物を識別するために用いられる記号、番号、文字列、URLなどで表現された識別情報であれば形式を問わない。
(A-2)本開示において、店舗IDの選択はユーザの手入力に限定されず、自動で選択されても良い。例えば、情報端末100の現在位置をGPS、UWB、Bluetoothのような無線通信技術により特定することで、ユーザが入店した店舗の店舗IDを自動的に選択するようにしても良いし、情報端末100の現在位置から近い店舗だけに候補を絞り込みユーザに音声又はタッチ操作で店舗を選択させるようにしても良い。
(A-3)本開示において、「嗜好情報に対応した順序」は、個別メニューの全ての料理(商品)の順序が嗜好情報に応じた順序である必要はない。例えば、少なくとも個別メニューにて表示される第1料理と第2料理とがある場合、第1料理と第2料理とが夫々のユーザの嗜好情報に対応した、または加味した、順序にて配列、表示されていれば良い。
すなわち、個別メニューで表示される少なくとも2つ以上の料理が夫々の嗜好情報に対応した順序で配列されていれば良い。例えば、季節料理、レストランがお勧めする料理、ユーザと類似の嗜好情報を持つ人達がよく注文する料理、などはユーザの嗜好情報に対応した順序で配列しなくても良い。そういった料理は、個別メニューの最初の画面や、比較的高い優先順序にて、個別メニューの中で表示させるようにしても良い。
(A-4)本開示において、「前記メニュー情報に含まれる第1メニュー内容を配列し」は、個別メニューの中で嗜好情報に対応した順序で料理を並び替える態様に限定されない。例えば、図8の個別メニュー画面G6のように、他の料理とは異なる表現方法であって嗜好情報に対応した表現方法を各料理に施すだけで、並び替えを伴わなくても良い。表現方法の一例は、料理の選択枠(タイルオブジェクト)の面積・太さ・色・点滅、料理画像のサイズ・デフォルメ、料理名と料理の特徴とを示す文字情報のサイズ・デフォルメ、ユーザの嗜好情報との合致・合致度合いを示すマーク・数字を付与する等である。
(A-5)本開示において、「第2レストランに関連するサーバ」は、第2レストランがメニュー情報を記録、配信するサーバ(又はコンピュータ)に対してネットワークで接続された全てのサーバを含む。例えば、「第2レストランに関連するサーバ」は、メニュー情報を保持する第2サーバ300と、第2サーバ300及び第1サーバ200に介在する1又は複数のサーバ(またはコンピュータ)とを含むものであってもよい。データ取引市場で定義される「データ取引市場運営事業者」のように、「第2レストランに関連するサーバ」は、データ提供者とデータ提供先との間を仲介し、データと対価の交換、決済などの機能を提供するデータ取引市場運営事業者と、データ取引市場運営事業者が運営するサーバ(又はコンピュータ)とを含んでもよい。
(B-1)本開示において、「位置情報が示す地点を含む地域」は、人が経済活動を行い、位置情報が示す地点を含む任意の地域を意味する。「位置情報が示す地点を含む地域」の一例は、地球、国、都道府県や市区町村といった行政単位、所定半径の円状区画、又は任意形状の区画等である。このように、「位置情報が示す地点を含む地域」は、ユーザが認知可能な所定の限定された範囲内であれば良い。
(B-2)本開示では、「前記第2レストランによって指定された前記第2メニュー内容を表示させる」について、図10の例では個別メニューが情報端末100のディスプレイ105の全面に表示されているとして説明したが、これに限定されない。「前記第2レストランによって指定された前記第2メニュー内容を表示させる」は、図32の例のように、地図と、選択した店舗と、その店舗の個別メニューとのうち、少なくとも2つ以上を同時に表示する態様を含んでもよい。こうすることで、画面遷移が削減され、ユーザは素早く、店舗のお勧め料理を確認することができる。
(B-3)第1サーバ200が個人情報の一部又は全部を外部へ提供する場合、その個人情報を利用する側(例えば、情報端末100のアプリ又は第2サーバ300)が解読できない仕組みを利用して個人情報を提供してもよい。この仕組みは、秘密計算と呼ばれる。秘密計算では、個人情報は暗号化された状態で利用する側へ提供され、利用する側は、暗号化された状態の個人情報に対して必要な演算を行う。つまり、保存データを暗号化したり、通信データを暗号化したりする従来の手法とは異なり、秘密計算は、暗号化されたデータのままで必要な演算を行う暗号技術である。本開示が示す情報端末100、第2サーバ300での個人情報のセキュアな利活用を実現するために、秘密計算が利用されるようにしても良い。
(B-4)本開示では個人の属性、嗜好、行動といった個人情報を個人ごとに名寄せして蓄積し、個人の意思のもとで個人情報を管理するサービスを提供する事業者を情報銀行として説明したが、これは一例である。情報銀行は、同様の機能を提供する、PDS(Personal Data Store)、PIMS(Personal Information Management System)、データ共有事業者、又はデータ処理業者等と解釈されてもよい。
(C-1)本開示において、「入力デバイス」は指によるタッチ操作を行う情報端末100のディスプレイ105に限定されない。「入力デバイス」は、情報端末100のマイクセンサー(図略)からユーザの音声による店舗の選択指示を受け付けても良いし、情報端末100のカメラ103からユーザの視線により店舗の選択指示を受け付けても良い。例えば、ユーザの視線方向上にある店舗のアイコンを検知し、そのアイコンが示す店舗をユーザが選択した店舗と判定すればよい。或いは、「入力デバイス」は、情報端末100のGPSセンサー107であってもよい。この場合、情報端末100は、GPSセンサー107が検知した現在位置情報に基づいてユーザが選択した店舗を自動的に判定してもよい。例えば、情報端末100は、現在位置情報に基づいてユーザが店舗内に進入したことを検知した場合、その店舗をユーザが選択した店舗として判定すればよい。また、これらの入力デバイスにより得られる情報を組み合わせて店舗の選択指示を受け付けるようにしても良い。
(C-2)本開示において、「前記識別情報に対応する嗜好情報を前記第1サーバから取得し」は、第1サーバとネットワーク接続された1又は複数のサーバ(又はコンピュータ)を経由して嗜好情報を取得することも勿論含む。尚、第1サーバにて管理されているユーザの嗜好情報の一部又は全部が情報端末100のメモリ102にセキュアにキャッシュ又は保管されていて、情報端末100のメモリ102からセキュアに利用が可能な場合には、第1サーバ200から取得せずに、情報端末100からユーザの嗜好情報を取得するようにしてもよい。この場合、第1サーバ200の処理負荷の軽減、ネットワーク又は第1サーバ200における処理の遅延の防止等の利点が得られる。さらに、この場合、情報端末100内のデータ保護アーキテクチャが十分高度で信頼できる場合に第1サーバ200との通信による情報漏洩のリスクを回避するといった利点もある。
(D-1)本開示において、「ユーザによって許諾されている」とは、ユーザの嗜好情報の一部又は全部を、第2レストラン(又は第2レストランと関連する第2サーバ)が利用することを、ユーザからの直接的指示又は予めの取り決めに基づき許諾することを含む。
(D-2)本開示において、「第2サーバに保持され」は、第2サーバがネットワークを介して取得可能な第2サーバ以外のサーバ、又はコンピュータがメニュー情報を保持する態様を含む。