[第1の実施形態]
本発明の第1の実施形態を図1から図15までを参照して説明する。図1は、シェアリングシステム100の全体の構成の一例を示すブロック図である。図2は、管理装置200の構成の一例を示すブロック図である。図3は、行先・運賃情報221の一例を示す図である。図4は、発注待ち情報222の一例を示す図である。図5は、発注先情報223の一例を示す図である。図6は、画面表示装置300の構成の一例を示すブロック図である。図7は、管理装置200の動作の一例を示すフローチャートである。図8は、管理装置200の他の構成の一例を示すブロック図である。図9は、注文まとめ部235の処理の一例を説明するための図である。図10は、管理装置200の他の構成の一例を示すブロック図である。図11は、シェアリングシステム100の他の構成の一例を示すブロック図である。図12は、図11で示す端末500の構成の一例を示すブロック図である。図13は、管理装置200の他の構成の一例を示すブロック図である。図14は、仮想始点を生成する処理の一例を説明するための図である。図15は、運賃算出処理の一例を説明するための図である。
本発明の第1の実施形態では、広告などを表示する画面表示装置300を利用してタクシーや貸し切りバスなどの移動手段をシェアするシステムであるシェアリングシステム100について説明する。後述するように、本実施形態において説明するシェアリングシステム100では、ユーザによる行先の選択(つまり、行先への移動手段の手配を行うサービスの注文)を受け付けると、注文の状況を示す注文状況が予め定められた条件を満たすまで発注を行わず待機する。換言すると、シェアリングシステム100は、注文状況が条件を満たすまで注文の取りまとめを行う。そして、シェアリングシステム100は、注文状況が条件を満たした後に、発注処理を行う。
なお、広告などを表示する画面表示装置300は、デジタルサイネージ、電子看板、などとも呼ばれる。そのため、シェアリングシステム100は、デジタルサイネージを活用して移動手段を効率的にシェアするためのシステムである、ということもできる。
図1は、シェアリングシステム100の全体の構成の一例を示している。図1を参照すると、シェアリングシステム100は、例えば、管理装置200と、画面表示装置300と、業者端末400と、を有している。図1で示すように、管理装置200と画面表示装置300とは、互いに通信可能なよう接続されている。また、管理装置200と業者端末400とは、互いに通信可能なよう、例えばネットワークなどを介して接続されている。
図1で示す装置のうち、管理装置200と画面表示装置300(または、少なくとも画面表示装置300)は、例えば、コンビニエンスストアやスーパーなどの商業施設、公共施設、オフィスや集合住宅の共用部などに設置される。また、図1で示す装置のうち、業者端末400は、例えば、タクシー会社やバス会社などの移動手段を管理する管理業者に設置される。管理装置200、画面表示装置300、業者端末400は、上記例示した以外の箇所に設置されても構わない。
なお、シェアリングシステム100が有する管理装置200、画面表示装置300、業者端末400の数は、図1で例示した場合に限定されない。シェアリングシステム100は、1以上の任意の数の管理装置200、画面表示装置300、業者端末400を有して構わない。
管理装置200は、ユーザによる注文の取りまとめを行うなど、発注を管理する情報処理装置である。図2は、管理装置200の構成の一例を示している。図2を参照すると、管理装置200は、主な構成要素として、例えば、通信I/F部210と、記憶部220と、演算処理部230と、を有している。また、管理装置200は、画面表示装置300と接続されている。
通信I/F部210は、データ通信回路からなる。通信I/F部210は、通信回線を介して接続された業者端末400などとの間で、データ通信を行う。
記憶部220は、ハードディスクやメモリなどの記憶装置である。記憶部220は、演算処理部230における各種処理に必要な処理情報やプログラム225を記憶する。プログラム225は、演算処理部230に読み込まれて実行されることにより各種処理部を実現する。プログラム225は、通信I/F部210などのデータ入出力機能を介して外部装置や記録媒体から予め読み込まれ、記憶部220に保存されている。記憶部220で記憶される主な情報としては、例えば、行先・運賃情報221、発注待ち情報222、発注先情報223、発注元情報224、などがある。
行先・運賃情報221は、例えば、行先、人数ごとの料金である運賃を示している。行先・運賃情報221は、例えば、予め定められて記憶部220に格納されている。
図3は、行先・運賃情報221の一例を示している。図3を参照すると、行先・運賃情報221では、例えば、行先と、人数と、運賃と、が対応づけられている。例えば、図3の1行目は、行先「AAA」に行く人数が「1名」である場合、運賃が「1,000円」であることを示している。また、例えば、図3の2行目は、行先「AAA」に行く人数が「2名」である場合、運賃が「800円」であることを示している。つまり、一人あたりの運賃が1,000円から800円に抑えられることを示している。
このように、行先・運賃情報221には、画面表示装置300の設置場所に応じて予め選択された行先を示す情報が含まれている。また、行先・運賃情報221には、人数に応じて例えば予め定められた運賃を示す情報が含まれている。
なお、行先・運賃情報221には、複数の管理業者の情報を含むことが出来る。例えば、行先・運賃情報221には、タクシー会社の行先・運賃を示す情報と、バス会社の行先・運賃を示す情報と、など複数の管理業者の行先・運賃を示す情報を含めることが出来る。
発注待ち情報222は、後述する判断部233により注文の取りまとめを行っている最中の注文状況を示す情報である。発注待ち情報222は、受付部232や送信部234などにより適宜更新される。
図4は、発注待ち情報222の一例を示している。図4を参照すると、発注待ち情報222では、例えば、行先と、発注待ち中の注文のうち最初の注文が行われた時刻を示す注文時刻と、発注待ちの人数と、が対応付けられている。例えば、図4の1行目は、行先「AAA」に対する注文が最初に行われた時刻(つまり、発注待ちが開始された時刻)が「xx:yy:zz」であり、現在「2名」が注文して発注待ちを行っている状況であることを示している。
発注先情報223は、送信部234による注文の送信先を示す情報である。発注先情報223は、例えば、予め定められて記憶部220に格納されている。
図5は、発注先情報223の一例を示している。図5を参照すると、発注先情報223では、例えば、行先ごとに、発注先となる業者端末400の情報などが含まれる発注先情報が対応づけられている。例えば、図5の1行目は、行先「AAA,BBB,CCC」の発注先情報が「αααα」であることを示している。
なお、発注先情報223は、発注先となる業者端末400の情報などが含まれる発注先情報のみを含むなど、上記例示した一部のみを有していても構わない。また、発注先情報223には、1社のみの情報が含まれていても構わないし、2以上の任意の数の情報が含まれていても構わない。
発注元情報224には、画面表示装置300が置かれた場所の住所など発注元となる画面表示装置300の設置場所を示す情報が含まれている。発注元情報224は、例えば、予め定められて記憶部220に格納されている。
演算処理部230は、MPUなどのマイクロプロセッサとその周辺回路を有する。演算処理部230は、記憶部220からプログラム225を読み込んで実行することにより、上記ハードウェアとプログラム225とを協働させて各種処理部を実現する。演算処理部230で実現される主な処理部として、例えば、画面表示部231と、受付部232と、判断部233と、送信部234と、がある。
画面表示部231は、行先・運賃情報221が示す行先や運賃、発注待ち情報222が示す注文状況、注文状況に応じて算出される値(例えば、注文時刻に後述する経過時間閾値を足した発注予定時刻や後述する人数閾値から発注待ちの人数を引いた注文可能人数)などを画面表示装置300に表示させる。画面表示部231は、記憶部220に予め記憶されている行先などに応じた画像などを、上記情報とともに画面表示装置300に表示させても構わない。
画面表示部231による制御により、画面表示装置300上には、例えば、行先ごとの発注予定時刻、注文可能人数、運賃、などを表示することが出来る換言すると、画面表示部231による制御により、画面表示装置300上には、行先「AAA」への手配というサービス、行先「BBB」への手配というサービス、などサービスごとに各種情報を表示することが出来る。なお、画面表示部231は、受付部232が新たな注文を受け付けた際や、送信部234が新たな発注を行った際など注文状況に変化が生じた際に、画面表示装置300上の表示を新たな注文状況に対応するよう制御する。
なお、画面表示部231は、上記例示した以外の情報を画面表示装置300上に表示させても構わない。例えば、画面表示部231は、現在の人数に応じた運賃や次に新たに注文が入った場合の運賃などを画面表示装置300上に表示させても構わない。また、画面表示部231は、例えば、各種広告画面などを画面表示装置300上に表示させることが出来る。画面表示部231は、例えば、表示する内容が時間の経過に応じて変化するなど、経時的な制御を行っても構わない。
受付部232は、ユーザによる新たな注文を受け付ける。例えば、ユーザが画面表示装置300のタッチパネル310をタッチしたとする。すると、受付部232は、ユーザがタッチした場所に関連付けられた行先を示す情報と、注文を受け付けた時刻を示す情報(例えば、ユーザがタッチした時刻を示す情報)と、を画面表示装置300から受け付ける。
具体的には、例えば、ユーザが行先「AAA」に関連づけられた枠をタッチしたとする。この場合、受付部232は、タッチした場所に関連付けられた行先「AAA」への移動手段の手配を希望する旨を示す注文を、画面表示装置300から受け付ける。なお、上記注文には、行先「AAA」を示す情報と、注文を受け付けた時刻を示す情報と、が含まれている。
また、受付部232は、受け付けた注文に応じて発注待ち情報222を更新する。例えば、受け付けた行先への発注待ちの注文がない場合、受付部232は、発注待ち情報222のうち受け付けた行先に対応づけられた注文時刻を、注文を受け付けた時刻とする。また、受付部232は、発注待ちの人数を1とする。一方、受け付けた行先への発注待ちの注文が既にある場合、受付部232は、受け付けた行先に対応する人数を1加算する。例えば、図4で示す場合、行先「AAA」への発注待ちの注文が既にある。そのため、受付部232は、行先「AAA」に対応する人数を1加算する。
このように、受付部232は、行先への移動手段の手配を希望する旨を示す注文をユーザから受け付ける。そして、受付部232は、受け付けた情報に応じて、発注待ち情報222を更新する。なお、受付部232により発注待ち情報222の更新が行われると、画面表示部231により画面表示装置300上の表示も更新された発注待ち情報222に応じたものに更新される。
判断部233は、発注待ち情報222が示す注文状況などに基づいて、発注するか否かなどを判断する。
例えば、判断部233は、発注待ち中の注文のうち最初の注文が行われた時刻を示す注文時刻からの経過時間の上限を示す経過時間閾値(例えば、10分や30分など)や、人数の上限を示す人数閾値(例えば、タクシーに乗車可能な人数の値。4人など)を予め有している。そして、判断部233は、発注待ち情報222が示す注文状況と、経過時間閾値と、人数閾値と、に基づいて、発注するか否か判断する。
具体的には、例えば、判断部233は、発注待ち情報222中の注文時刻からの経過時間が経過時間閾値を超える場合、経過時間閾値を超える注文時刻に対応する行先の注文を発注すると判断する。また、判断部233は、発注待ち情報222中の人数が人数閾値以上である場合、注文時刻からの経過時間が経過時間閾値を超えていなくても、対応する行先の注文を発注すると判断する。
また、判断部233は、例えば、発注先情報223などに基づいて、発注先の判断を行うことが出来る。例えば、判断部233は、発注先情報223において、発注すると判断した注文の行先に対応付けられている発注先に発注すると判断する。なお、発注先情報223に1社の情報しか含まれない場合、判断部233は、発注先の判断を行わなくても構わない。
このように、判断部233は、発注するか否か判断するとともに、発注先を判断することが出来る。そして、判断部233は、判断の結果を送信部234に通知する。
なお、判断部233は、発注先情報223以外の情報などを参照して、発注先の判断を行うよう構成しても構わない。
例えば、画面表示装置300の設置場所周辺でイベントが開催される場合、画面表示装置300の設置場所周辺に駅があり電車に運休が生じている場合、荒天や猛暑など天候に問題がある場合、などの諸事情がある場合、通常時よりも移動手段のシェアを希望する人数が増えることが想定される。このような場合、単にタクシー会社に対して発注を行っていると、タクシーが不足することが想定される。そこで、判断部233は、例えば、画面表示装置300の設置場所周辺で行われるイベントや天候などを示す状況情報を外部装置から取得する。そして、判断部233は、取得した状況情報が予め定められた状況を示す場合、発注先をタクシー会社にするかバス会社にするか判断することが出来る。
具体的には、例えば、判断部233は、上述したような諸事情を示す状況情報を取得した場合において、単位時間あたりの発注数が閾値を超えた場合や単位時間当たりの人数の増加量が閾値を超えた場合、発注待ち情報222中の人数が人数閾値以上でも発注を行わない。そして、判断部233は、人数が第2人数閾値(例えば、マイクロバスの定員など)以上となる場合、バス会社が有する業者端末400に対して発注する旨を判断する。一方、単位時間あたりの発注数が閾値を超えない場合や単位時間当たりの人数の増加量が閾値を超えない場合、判断部233は、発注待ち情報222中の人数が人数閾値以上になると、タクシー会社が有する業者端末400に対して発注する旨を判断する。なお、人数が人数閾値以上であるものの第2人数閾値よりも小さい状況で注文時刻からの経過時間が経過時間閾値を超えた場合、判断部233は、例えば、タクシー会社とバス会社のうちより運賃が安くなる方に発注するよう判断することが出来る。
例えば、以上のように、判断部233は、状況情報などを参照して、発注先をタクシー会社にするかバス会社にするか判断することが出来る。なお、判断部233は、単位時間あたりの発注数が閾値を超えた場合や単位時間当たりの人数の増加量が閾値を超えた場合に、状況情報にかかわらず発注先の判断を行うよう構成しても構わない。また、判断部233は、上述したような諸事情を示す状況情報を取得した場合、原則として常に発注先の判断を行うよう構成しても構わない。
送信部234は、判断部233からの通知に応じて、発注情報を発注先の管理業者が有する業者端末400に対して送信する。つまり、送信部234は、判断部233による判断の結果に応じて、移動手段の手配(発注)を行う。また、送信部234は、発注待ち情報222を更新する。
例えば、送信部234は、発注先情報223を参照して、判断部233が判断した発注先となる業者端末400の情報を確認する。そして、送信部234は、確認した結果に基づいて、発注先となる業者端末400に対して、行先を示す情報、人数を示す情報、発注元情報224に含まれる発注元となる画面表示装置300の設置場所を示す情報、などの発注情報を送信する。
また、送信部234は、発注待ち情報222のうち発注を行った行先に対応する、注文時刻や人数などの情報を削除する。このように、送信部234は、発注待ち情報222のうち発注に応じた情報を更新する。
以上が、管理装置200の構成の一例である。
画面表示装置300は、上述したように、デジタルサイネージ、電子看板などと呼ばれる表示装置である。図6は、画面表示装置300の主な構成の一例を示している。図6を参照すると、画面表示装置300は、例えば、時計機能などの一般的な機能のほかに、タッチパネル310と、送受信部320と、を有している。
タッチパネル310は、例えば、上述したように、画面表示部231からの指示に応じて、行先・運賃情報221が示す行先や運賃、発注待ち情報222が示す注文状況、注文状況に応じて算出される値などを画面表示することが出来る。また、タッチパネル310は、画面表示部231からの指示に応じて、画面表示の内容を適宜更新する。また、タッチパネル310は、ユーザによるタッチパネル310へのタッチに応じて、タッチした場所に関連付けられた行先を示す情報を取得する。
送受信部320は、管理装置200との間で情報の送受信を行う。例えば、送受信部320は、管理装置200から、タッチパネル310上に表示する画面を制御するための情報を受信する。また、送受信部320は、管理装置200に対して、ユーザがタッチした場所に関連付けられた行先を示す情報と、ユーザがタッチパネル310にタッチした時刻を示す情報と、を送信する。このように、送受信部320は、管理装置200から情報を受信するとともに管理装置200に対して情報を送信する。
業者端末400は、移動手段を管理する管理業者に置かれた情報処理装置である。業者端末400は、例えば、管理装置200から、行先を示す情報、人数を示す情報、発注元情報224に含まれる発注元となる画面表示装置300の設置場所を示す情報、などを受信する。業者端末400は、受信した情報に基づいて、画面表示装置300の設置場所にタクシーなどの移動手段が向かうようタクシーなどの指示対象に対して指示することが出来る。業者端末400は、当該業者端末400が有する画面表示部などに受信した情報を表示するよう構成しても構わない。
以上が、シェアリングシステム100の構成の一例である。続いて、図7を参照して、管理装置200の動作の一例について説明する。
図7は、管理装置200の動作の一例を示している。図7を参照すると、受付部232は、ユーザによる新たな注文を受け付ける(ステップS101)。例えば、ユーザが画面表示装置300のタッチパネルをタッチすると、受付部232は、ユーザがタッチした場所に関連付けられた行先を示す情報と、注文を受け付けた時刻を示す情報(例えば、ユーザがタッチした時刻を示す情報)と、を画面表示装置300から受け付ける。
また、受付部232は、受け付けた注文に応じて発注待ち情報222を更新する(ステップS102)。例えば、受け付けた行先への発注待ちの注文がない場合、受付部232は、発注待ち情報222のうち受け付けた行先に対応づけられた注文時刻を、注文を受け付けた時刻とする。また、受付部232は、発注待ちの人数を1とする。一方、受け付けた行先への発注待ちの注文が既にある場合、受付部232は、受け付けた行先に対応する人数を1加算する。
判断部233は、発注待ち情報222が示す注文状況などに基づいて、発注するか否かを判断する(ステップS103)。例えば、判断部233は、発注待ち情報222中の注文時刻からの経過時間が経過時間閾値を超える場合、経過時間閾値を超える注文時刻に対応する行先の注文を発注すると判断する。また、判断部233は、発注待ち情報222中の人数が人数閾値以上となる場合、注文時刻からの経過時間が経過時間閾値を超えていなくても、対応する行先の注文を発注すると判断する。
このように、判断部233は、予め定められた条件を満たす場合(ステップS103、Yes)、発注すると判断する。また、判断部233は、発注先を判断する(ステップS104)。例えば、判断部233は、発注先情報223や状況情報などに基づいて、発注先を判断する。そして、判断部233は、判断の結果を送信部234に通知する。なお、発注先の判断を行わないよう構成する場合、ステップS104の処理は省略して構わない。
送信部234は、判断部233からの通知に応じて、発注情報を発注先の管理業者が有する業者端末400に対して送信する(ステップS105)。例えば、送信部234は、行先を示す情報、人数を示す情報、発注元情報224に含まれる発注元となる画面表示装置300の設置場所を示す情報、などの発注情報を、送信先となる業者端末400に対して送信する。また、送信部234は、発注待ち情報222のうち発注を行った行先に対応する、注文時刻や人数などの情報を削除する。このように、送信部234は、発注待ち情報222のうち発注に応じた情報を更新する。
以上が、管理装置200の動作の一例である。
このように、管理装置200は、判断部233と、送信部234と、を有している。このような構成によると、判断部233は、発注待ち情報222が示す注文時刻からの経過時間や人数などの注文状況が条件を満たすことで、発注すると判断する。つまり、上記構成によると、注文状況が条件を満たすまで発注する旨の判断を遅らせることが出来る。これにより、適切なタイミングまで注文の取りまとめを行うことが可能となり、その結果、移動手段のシェアを効率的に行うことが可能となる。つまり、本実施形態において説明したシェアリングシステム100によると、移動手段の手配などが過度に集中することを抑制することが出来るとともに、移動手段の効率的なシェアにより移動手段を利用する際の料金などを抑制することが可能となる。
また、本実施形態で説明した方法によると、発注待ちの注文状況を画面表示装置300に表示させる。このように発注待ちの注文状況を表示させることで、画面表示を確認したユーザなどが発注までどれくらいの時間がかかるかなどの目途をつけることが可能となり、その結果として、例えば、注文までの敷居を下げることが可能となる。つまり、より気軽にタクシーなどの移動手段を用いることが可能となる。
なお、シェアリングシステム100の構成は、本実施形態で例示した場合に限定されない。例えば、管理装置200と画面表示装置300とは、それぞれが別の装置であっても構わないし、一体的に構成されていても構わない。また、管理装置200は、例えば、ネットワークを介して接続された複数台の情報処理装置により構成されても構わない。
また、管理装置200は、例えば、ユーザの年齢、性別、たばこを吸うか否か、などを示すユーザの属性を示す属性情報を取得するよう構成することが出来る。管理装置200を上記のように構成する場合、判断部233は、例えば、発注待ち情報222を、属性ごとに分けて管理することなどにより、属性ごとに注文の取りまとめを行うよう構成しても構わない。なお、属性情報は、ユーザの入力に応じて取得するよう構成しても構わないし、画面表示装置300の設置場所周辺に設置された監視カメラが取得した画像データなどに基づいて取得するよう構成しても構わない。
また、送信部234は、判断部233が発注の判断を行う前に、発注待ち情報222などを業者端末400に対して送信するよう構成しても構わない。例えば、送信部234は、注文時刻からの経過時間が所定時間(例えば、20分など)を過ぎた、注文可能な人数が残り1人である、など、予め定義された状況(もう少しで発注される状況)である場合に、発注待ち情報222に含まれる情報などを業者端末400に対して送信するよう構成することが出来る。送信部234は、予め定められた時間ごとに定期的に発注待ち情報222を業者端末400に対して送信するよう構成しても構わない。
また、一度に一人が注文を出すのではなく、複数の人数を含むグループで注文を出すことも想定される。このような場合に対応するため、画面表示装置300や受付部232は、行先を示す情報を取得するとともに、一度に注文する人数を示す情報を取得するよう構成しても構わない。また、上記のように構成する場合、管理装置200は、例えば、1グループを一人とみなして、行先・運賃情報221が示す運賃を適用するよう構成しても構わない。
また、行先・運賃情報221は、必ずしも人数ごとの運賃を示していなくても構わない。例えば、行先・運賃情報221には、行先ごとの運賃を示す情報が含まれていても構わない。つまり、行先・運賃情報221が示す運賃は、人数にかかわらず同額(つまり、乗客が1名の場合でも2名の場合でもそれぞれに同じ料金がかかる)であっても構わない。
また、シェアリングシステム100や管理装置200は、本実施形態で例示した以外の構成を有することが出来る。
例えば、図8、管理装置200の他の構成例を示している。図8を参照すると、演算処理部230は、プログラム225を読み込んで実行することにより、図2で例示した場合に加えて、例えば、注文まとめ部235を実現することが出来る。
注文まとめ部235は、行先などに応じて、取りまとめ中の複数の注文をまとめる。図9は、注文まとめ部235による処理の一例を示している。例えば、図9で示すように、予め定められた行先によっては、他の行先を経由する場合がある。具体的には、図9で示す場合、画面表示装置300の設置場所から行先である「降車地C」へと向かう間に、「降車地B」がある。そのため、行先「降車地C」は行先「降車地B」を経由する。このように、行先までの間に他の行先が存在する場合などにおいて、注文まとめ部235は、複数の注文をまとめる。例えば、図9で示す場合、注文まとめ部235は、行先が「降車地B」である注文1と行先が「降車地C」である注文2とをまとめる。その結果、注文まとめ部235は、最終的な行先が「降車地C」であり、「降車地B」を経由する新たな注文(注文1&2)を生成するとともに、生成処理に応じた発注待ち情報222の更新などを行う。
なお、注文まとめ部235が複数の注文をまとめた場合、判断部233は、注文まとめ部235がまとめた結果生成した新たな注文について、まとめられた人数などに基づいて、発注するか否か判断する。また、送信部234は、発注情報を発注先の管理業者が有する業者端末400に対して送信する際、業者端末400に対して、「降車地B」を経由した上で「降車地C」に向かう旨を示すなど、まとめたそれぞれの注文の行先を示す情報を送信する。
例えば、以上のように、管理装置200は注文まとめ部235を有することが出来る。なお、上述したように、本実施形態で説明する管理装置200の場合、例えば、画面表示装置300ごとに(または、設置場所ごとに)行先が予め定められている。そのため、どの行先の注文とどの行先の注文とを取りまとめるか、つまり、注文まとめ部235によるまとめ対象となる行先の組み合わせについては、例えば、予め定めておくことが出来る。
また、注文まとめ部235は、出来る限り常に注文をまとめるよう構成しても構わないし、例えば予め定められた条件を満たす場合のみ注文をまとめるよう構成しても構わない。例えば、注文まとめ部235は、注文時刻からの経過時間が所定の時間を過ぎる、まとめることでまとめた後の人数が人数閾値となるなど人数が所定の条件を満たす、などの予め定められた条件を満たす場合に、注文をまとめるよう構成することが出来る。
また、例えば、図10は、管理装置200の他の構成例を示している。図10を参照すると、管理装置200の記憶部220は、図2で例示した場合に加えて、駐車場情報226を有することが出来る。また、演算処理部230は、プログラム225を読み込んで実行することにより、図2や図8で例示した場合に加えて、駐車場状況取得部236を実現することが出来る。
駐車場情報226は、画面表示装置300の設置場所周辺の駐車場の情報を示している。例えば、画面表示装置300がコンビニエンスストアに設置されている場合、駐車場情報226は、コンビニエンスストアが有する駐車場の広さなどを示している。なお、駐車場情報226は、駐車場が混雑する時間帯など混雑状況を示す情報や、画面表示装置300の設置場所周辺の道路の状況などを示す情報などを含んでも構わない。
駐車場状況取得部236は、画面表示装置300の設置場所周辺の駐車場の状況を示す駐車場状況情報を取得する。例えば、駐車場状況取得部236は、通信I/F部210を介して接続された、画面表示装置300の設置場所周辺の駐車場を撮影する監視カメラが取得した画像データを取得する。そして、駐車場状況取得部236は、取得した画像データに基づいて、駐車場が混んでいるか否かなどの駐車場の状況を示す駐車場状況情報を取得する。また、駐車場状況取得部236は、駐車場の空き情報を管理する外部装置などから、駐車場状況情報を取得しても構わない。
管理装置200が上述したような駐車場情報226や駐車場状況取得部236などを有する場合、送信部234は、駐車場情報226や駐車場状況取得部236が取得した駐車場状況情報を業者端末400に送信することが出来る。例えば、送信部234は、発注情報を送信する際などに、発注情報とともに、駐車場情報226や駐車場状況情報を送信することが出来る。送信部234は、上記例示したタイミング以外で、駐車場情報226や駐車場状況情報を業者端末400に対して送信しても構わない。
このように構成することで、移動手段の管理業者は、事前に駐車場などの混雑具合を把握することが可能となる。これにより、より効率的なシェアを実現することが出来る。
また、図11は、シェアリングシステム100の変形例を示している。図11を参照すると、シェアリングシステム100は、管理装置200と画面表示装置300と業者端末400とに加えて、端末500を有することが出来る。図11で示すように、端末500は、管理装置200と無線通信などにより互いに通信可能なよう接続されている。
端末500は、行先の指定を管理装置200に対して行うことが可能なスマートフォンなどの携帯型の情報処理装置である。図12は、端末500の構成の一例を示している。図12を参照すると、端末500は、例えば、スマートフォンとしての一般的な構成の他に、行先指定部510と、位置情報取得部520と、送受信部530と、を有している。なお、端末500が有する処理部としての機能は、例えば、端末500が有するCPU(Central Processing Unit)などの演算装置が記憶装置に格納されたプログラムを実行することで実現される。
行先指定部510は、ユーザの操作に応じて、ユーザが移動手段の手配を希望する行先を示す情報を取得する。例えば、端末500は、送受信部530を介して管理装置200から行先の候補を示す情報を取得しており、画面表示している。行先指定部510は、ユーザの操作に応じて、表示した行先候補のうちユーザが移動手段の手配を希望する行先を示す情報を取得する。
位置情報取得部520は、GPSなどを利用して、端末500の位置を示す情報である位置情報を取得する。位置情報取得部520は、GPS以外の既知の方法を用いて端末500の位置を示す情報を取得しても構わない。
送受信部530は、アンテナなどを有しており、管理装置200との間で情報の送受信を行う。例えば、送受信部530は、管理装置200から、行先の候補を示す情報を受信する。また、送受信部530は、管理装置200に対して、ユーザが選択した行先を示す情報などを送信する。送受信部530は、行先を示す情報を送信する際などに、位置情報取得部520が取得した位置情報などを送信することが出来る。
このように、端末500は、行先指定部510を有している。このような構成によると、行先指定部510により行先を示す情報を管理装置200に対して送信することが出来る。これにより、例えば、画面表示装置300をタッチしなくても行先を指定することが可能となる。その結果、例えば、画面表示装置300の設置場所に行く前に注文を行うことが可能となり、より効率的に移動手段のシェアを行うことが可能となる。
また、シェアリングシステム100が端末500を有する場合、管理装置200は、図13で示すような構成を有しても構わない。図13は、管理装置200の他の構成例を示している。図13を参照すると、管理装置200の演算処理部230は、プログラム225を読み込んで実行することにより、図2、図8、図10で例示した場合に加えて、仮想始点生成部237と、運賃算出部238と、を実現することが出来る。
仮想始点生成部237は、仮想始点を生成するか否か判断する。また、仮想始点生成部237は、タクシーなどの移動手段を呼び出す場所である始点を生成する。
例えば、仮想始点生成部237は、所定範囲内に存在する端末500の数に基づいて、仮想始点を生成するか否か判断する。具体的には、例えば、図14で示すように、所定範囲内に予め定められた数以上の端末500が存在する場合、仮想始点生成部237は、仮想始点を生成すると判断する。なお、所定範囲の値や数は任意の値・数で構わない。
また、仮想始点生成部237は、仮想始点を生成する際に状況情報を参照するよう構成しても構わない。例えば、仮想始点生成部237は、状況情報により画面表示装置300の設置場所周辺の公園でイベントが開催されると判断される場合など人が集まると判断される状況である場合、仮想始点を生成すると判断することが出来る。
また、仮想始点生成部237は、所定範囲内に存在する端末500の位置情報や状況情報などに基づいて、始点となる場所を決定する。これにより、仮想始点生成部237は、仮想始点を生成する。例えば、仮想始点生成部237は、所定範囲内に存在する端末500の位置の中央、付近に存在する駐車場など、所定範囲内に存在する端末500の位置に応じた場所などを始点とする。
運賃算出部238は、仮想始点生成部237が生成した始点から予め定められた行先まで移動手段で移動した場合の運賃を算出する。例えば、運賃算出部238は、図15で示すように、仮想始点と行先との間の距離に基づいて、運賃を算出する。また、運賃算出部238は、算出した運賃に予め定められた係数などをかけることなどにより、人数ごとの運賃を算出することが出来る。
このように、運賃算出部238は、仮想始点生成部237が仮想始点を生成した場合に、仮想始点を用いた場合の運賃を算出する。運賃算出部238は、行先・運賃情報221などを参照して、運賃を算出するよう構成しても構わない。
本実施形態においては、原則として、画面表示装置300の設置場所にタクシーなどの移動手段を向かわせる場合について説明した。つまり、移動手段の始点は原則として画面表示装置300の設置場所である。管理装置200が仮想始点生成部237と運賃算出部238とを有することで、タクシーを向かわせる場所(つまり、始点)を変更することが可能となる。また、仮想始点生成部237が仮想始点を生成するか否か判断することで、始点が過度に変更されることを防ぐことが出来る。
[第2の実施形態]
次に、本発明の第2の実施形態について、図16、図17を参照して説明する。図16は、シェアリングシステム700の全体の構成の一例を示すブロック図である。図17は、管理装置200の構成の一例を示すブロック図である。
本発明の第2の実施形態においては、お弁当の手配をシェアするシステムであるシェアリングシステム700について説明する。第1の実施形態においては、移動手段の手配をシェアするシェアリングシステム100について説明した。しかしながら、本発明は、移動手段をシェアする以外のシェアリングシステムにも適用可能である。そこで、第2の実施形態においては、移動手段の手配(サービスの手配)以外のシェアの一例として、商品の手配の一例であるお弁当の手配をシェアする場合について説明する。
図16は、シェアリングシステム700の全体の構成の一例を示している。図16を参照すると、シェアリングシステム700は、例えば、管理装置200と、画面表示装置300と、業者端末400と、の他に、認証端末600を有している。図16で示すように、管理装置200と認証端末600とは、互いに通信可能なよう接続されている。
シェアリングシステム700の場合、画面表示装置300は、例えば、パブリックビューイングなどのイベント会場、オフィスや介護施設など、に設置することが想定される。画面表示装置300は、集合住宅など上記例示した場所以外に設置しても構わない。
認証端末600は、ユーザの認証を行う。認証端末600は、例えば、社員証などのカードに含まれる認証情報や、監視カメラなどが撮影した顔画像などに基づいて、ユーザが予め登録されているか否かを確認する認証を行う。そして、認証端末600は、ユーザが予め登録されている場合、認証の結果を管理装置200に対して送信する。
図17は、シェアリングシステム700における管理装置200の構成の一例を示している。図17を参照すると、管理装置200は、第1の実施形態で説明した構成の他に、認証受付部239を有している。また、管理装置200の記憶部220は、行先・運賃情報221の代わりに、商品・価格情報227を有している。
商品・価格情報227は、第1の実施形態で説明した行先・運賃情報221に相当する情報である。シェアリングシステム700では、第1の実施形態で説明した移動手段のシェアではなく、お弁当などの商品の手配をシェアする。そのため、記憶部220は、行先と、人数と、運賃と、を対応づけた行先・運賃情報221の代わりに、商品・価格情報227を有している。例えば、商品・価格情報227では、商品と、注文数と、価格(料金)と、が対応づけられている。
認証受付部239は、認証端末600から認証の結果を受け付ける。そして、認証受付部239は、認証されたユーザによる注文を受け付けるよう受付部232に指示する。これにより、受付部232は、ユーザによる注文を受け付けるようになる。認証受付部239が認証を受け付けていない場合、受付部232は、ユーザによる注文を受け付けない。
なお、認証受付部239は、認証の結果に応じて、予め記憶部220に格納されたユーザのクレジットカード情報などの支払い情報を取得するよう構成しても構わない。
例えば、以上のような構成により、シェアリングシステム700を実現することが出来る。上述したような構成により、シェアリングシステム700は、第1の実施形態と同様に、適切なタイミングまで注文の取りまとめを行うことが可能となる。その結果、商品手配のシェアを効率的に行うことが可能となる。また、本実施形態で説明した方法によると、発注待ちの商品の注文状況を画面表示装置300に表示することが出来る。その際、例えば、後xx個の注文が集まればディスカウントされる、などのゲーム性のある情報も画面表示装置300に表示させることで、例えば、より楽しみながら買い物を行うことが出来るようになる。
なお、シェアリングシステム700には、第1の実施形態で説明した場合と同様に、様々な変形例を採用することが出来る。
また、お弁当の手配を行う場合、判断部233は、例えば、10時30分など予め定められた時刻になった場合に発注すると判断するよう構成しても構わない。また、判断部233は、例えば、お店の方向が同一となる複数のお店の注文をまとめた数が所定数を超えた場合に発注すると判断するよう構成しても構わない。このように、判断部233は、第1の実施形態で例示した以外の様々な条件に基づいて、発注すると判断することが出来る。
また、判断部233は、例えば、予め定められた所定の確率でお弁当の代金を割り引く、無料とする、など、費用面における判断を行うよう構成しても構わない。
なお、シェアリングシステム700は、お弁当以外の商品の手配をシェアするよう構成しても構わない。例えば、シェアリングシステム700は、各種特産品などの商品の手配をシェアするよう構成しても構わない。このように、シェアリングシステム700では、様々な商品やサービスの手配をシェアするよう構成することが出来る。
[第3の実施形態]
次に、本発明の第3の実施形態について、図18から図20までを参照して説明する。図18は、シェアリングシステム710の全体の構成の一例を示すブロック図である。図19は、管理装置900の構成の一例を示すブロック図である。図20は、管理装置900の他の構成例を示すブロック図である。
本発明の第3の実施形態においては、所定のエリア単位でお弁当、商品、移動手段の手配、配送などの注文を取りまとめるシェアリングシステム710について説明する。後述するように、本実施形態において説明するシェアリングシステム710は、複数の画面表示装置300を有している。また、各画面表示装置300は、ユーザから注文を受け付けると、受け付けた注文を示す情報を管理装置900に対して送信する。そして、管理装置900は、所定のエリア内に設置された画面表示装置300が受け付けた注文をまとめて取りまとめる。
なお、注文を取りまとめるエリアは、例えば、同一町内、同一市内などであり、予め定められている。注文を取りまとめるエリアは、例えば、お弁当や商品などを各画面表示装置300の設置場所に配送する際にかかる時間の合計である配送時間などに応じて定めても構わない。例えば、注文を取りまとめるエリアは、各画面表示装置300の設置場所に商品などを配送する時間が所定時間(任意の値で構わない)以下になるように、定めることが出来る。なお、配送時間は、各画面表示装置300の設置位置と、配送を行う配送業者の位置と、などに基づいて算出することが出来る。
図18は、シェアリングシステム710の全体の構成の一例を示している。図18を参照すると、シェアリングシステム710は、例えば、管理装置900と、画面表示装置300と、業者端末400と、を含んでいる。図18で示すように、管理装置900と画面表示装置300とは、ネットワークを介して互いに通信可能なよう接続されている。また、管理装置900と業者端末400とは、ネットワークを介して互いに通信可能なよう接続されている。
なお、図18では図示していないが、シェアリングシステム710は、管理装置200を有しても構わない。つまり、シェアリングシステム710では、画面表示装置300と管理装置200とを互いに通信可能なよう接続するとともに、管理装置200と管理装置900とを互いに通信可能なよう接続することが出来る。また、シェアリングシステム710が上記のような構成を有する場合、管理装置200は、第1の実施形態や第2の実施形態で説明した構成のうちの一部の機能から構成されていても構わない。例えば、シェアリングシステム710が有する管理装置200は、画面表示部231としての機能を有する装置であっても構わない。また、シェアリングシステム710が管理装置200を有さない場合、画面表示装置300が画面表示部231としての機能などを有していても構わない。なお、シェアリングシステム710は、認証端末600など上記例示した以外の構成を有しても構わない。
画面表示装置300は、第1の実施形態、第2の実施形態と同様に、デジタルサイネージ、電子看板などと呼ばれる表示装置である。画面表示装置300は、例えば、商業施設、公共施設、オフィスや集合住宅の共用部、大学の構内など、人が集まる場所に設置されている。本実施形態の場合、画面表示装置300は、ユーザからの注文を受け付けると、受け付けた注文を示す情報を管理装置900に対して送信する。
業者端末400は、第1の実施形態、第2の実施形態と同様に、業者に置かれた情報処理装置である。業者端末400は、例えば、お弁当や商品の販売を行う業者、タクシーやバスなどの移動手段の手配・管理を行う業者、お弁当や商品の配送を行う業者、などの事業所などに設置されている。
管理装置900は、エリア単位でユーザによる注文の取りまとめを行うなど、発注を管理する情報処理装置である。管理装置900は、例えば、シェアリングシステム710を運営・管理する運営・管理会社に設置されている。図19は、管理装置900の構成の一例を示している。図19を参照すると、管理装置900は、主な構成要素として、例えば、通信I/F部910と、記憶部920と、演算処理部930と、を有している。
通信I/F部910は、データ通信回路からなる。通信I/F部910は、通信回線を介して接続された画面表示装置300や業者端末400などとの間で、データ通信を行う。
記憶部920は、ハードディスクやメモリなどの記憶装置である。記憶部920は、演算処理部930における各種処理に必要な処理情報やプログラム925を記憶する。プログラム925は、演算処理部930に読み込まれて実行されることにより各種処理部を実現する。プログラム925は、通信I/F部910などのデータ入出力機能を介して外部装置や記録媒体から予め読み込まれ、記憶部920に保存されている。記憶部920で記憶される主な情報としては、例えば、注文数・配送料情報921、発注待ち情報922、発注先情報923、発注元情報924、などがある。
注文数・配送料情報921は、第1の実施形態や第2の実施形態で説明した行先・運賃情報221や商品・価格情報227に相当する情報である。注文数・配送料情報921では、例えば、注文数と配送料とが対応づけられている。例えば、注文数・配送料情報921では、注文数が多くなるほど配送料が安くなるように上記対応付けがされている。注文数・配送料情報921は、例えば、予め定められて記憶部920に格納されている。
なお、注文数・配送料情報921では、商品ごとや商品の種類ごとに注文数と配送料とを対応付けても構わない。また、注文数・配送料情報921には、複数の配送業者の配送料を示す情報が含まれても構わない。
また、記憶部920には、注文数・配送料情報921の代わりに、または、注文数・配送料情報921とともに、行先・運賃情報221や商品・価格情報227などが格納されていても構わない。なお、商品・価格情報227は、例えば、注文数が多くなるほど商品の価格が安くなることを示す情報であることが出来る。
発注待ち情報922は、後述する判断部932により注文の取りまとめを行っている最中の注文状況を示す情報である。本実施形態の場合、発注待ち情報922には、エリア内の各画面表示装置300において受け付けた注文の注文状況を示す情報が含まれている。例えば、発注待ち情報922では、発注待ち中の注文のうち最初の注文が行われた時刻を示す注文時刻と、発注待ちの人数(または、発注待ちの注文数や発注待ちの商品数など)と、が対応付けられている。発注待ち情報922では、注文を受け付けた画面表示装置300を判別可能なように、上記対応付けを行っても構わない。なお、本実施形態の場合、管理装置900から各画面表示装置300に対して送信される情報などにより、各画面表示装置300における注文状況の同期を行うことが出来る。そのため、発注待ち情報922に含まれる注文時刻は、例えば、最初に注文を受け付けた画面表示装置300における最初の注文の時刻を示している。また、発注待ちの人数は、各画面表示装置300において受け付けた注文数の例えば合計を示している。
発注先情報923は、例えば、発注先情報223などと同様の情報であり、注文の送信先を示している。発注先情報923では、お弁当や商品ごと、お弁当や商品の種類ごとに、発注先情報が対応づけられていても構わない。
なお、発注先情報923には、注文の送信先を示す情報のほかに、お弁当や商品の配送を行う配送会社の情報が含まれていても構わない。
発注元情報924は、例えば、発注元情報224などと同様の情報であり、各画面表示装置300が置かれた場所の住所などを示している。例えば、発注元情報924では、画面表示装置300を識別するための識別情報と、画面表示装置300の住所を示す情報などと、が対応づけられている。
演算処理部930は、MPUなどのマイクロプロセッサとその周辺回路を有する。演算処理部930は、記憶部920からプログラム925を読み込んで実行することにより、上記ハードウェアとプログラム925とを協働させて各種処理部を実現する。演算処理部930で実現される主な処理部として、例えば、管理部931と、判断部932と、送信部933と、がある。演算処理部930は、第2の実施形態で説明した認証受付部239など上記例示した以外の構成を有しても構わない。
管理部931は、各画面表示装置300から受信した情報に基づいて、注文待ちの状況などを管理する。例えば、管理部931は、画面表示装置300から、当該画面表示装置300が受け付けた注文を示す情報を取得する。例えば、管理部931は、画面表示装置300から、画面表示装置300を識別するための識別情報と、画面表示装置300が受け付けた注文を示す情報と、を取得する。そして、管理部931は、受け付けた情報に基づいて、発注待ち情報922を更新する。
また、管理部931は、画面表示装置300から注文を示す情報を取得した場合、注文を示す情報を取得した旨を他の画面表示装置300に対して送信することが出来る。これにより、各画面表示装置300において注文状況の同期を行うことができ、他の画面表示装置300で受け付けた注文も含む注文状況を画面表示することが出来る。
判断部932は、第1の実施形態で説明した判断部233と同様に、発注待ち情報922が示す注文状況などに基づいて、発注するか否かなどを判断する。例えば、判断部932は、発注待ち情報222が示す注文状況と、経過時間閾値と、人数閾値と、に基づいて、発注するか否か判断する。判断部932は、人数閾値の代わりに、または、人数閾値とともに、注文数の上限を示す注文数閾値を用いて発注するか否か判断しても構わない。なお、判断部932による具体的な判断方法は、第1の実施形態で説明した判断部233などと同様で構わない。また、判断部932は、注文数・配送料情報921や商品・価格情報227などを参照して、発注した際の人数に基づいて、配送料や商品の価格などを決定することが出来る。
送信部933は、判断部932による発注の判断に応じて、お弁当や商品の販売を行う業者に設置された業者端末400に対して、注文するお弁当や商品などを示す情報が含まれる発注情報を送信する。また、送信部933は、商品などの配送を行う業者に設置された業者端末400に対して、商品などの販売を行う業者の位置を示す情報と、画面表示装置300の設置場所など配送先の位置を示す情報と、を含む発注情報を送信することが出来る。
また、送信部933は、発注の後、発注した旨を示す情報を各画面表示装置300に対して送信することが出来る。
このように、シェアリングシステム710は、管理装置900を有している。このような構成によると、管理装置900は、所定のエリア内に設置された画面表示装置300が受け付けた注文をまとめて取りまとめることが出来る。その結果、例えば、1箇所の画面表示装置300だけでは十分な注文が集まらない状況などでも、十分な注文を集めることなどが可能となる。これにより、より多くの注文を集めることが可能となり、例えば、仕入れコストや配送コストなどを下げることが可能となる。
なお、本実施形態では、管理装置900が予め定められたエリア内の画面表示装置300が受け付けた注文をまとめて取りまとめる場合について説明した。しかしながら、注文をまとめて取りまとめる対象は、例えば、エリア内の画面表示装置300の中から動的に絞り込むなど、可変であっても構わない。例えば、図20で示すように、管理装置900の演算処理部930は、記憶部920に格納されたプログラムを実行することで、選択部934としての機能を実現することが出来る。
選択部934は、注文数、最初の注文からの経過時間、注文数の増え具合などの注文状況に応じて、エリア内に属する複数の画面表示装置300のうち注文を取りまとめる画面表示装置300を選択、絞り込むことが出来る。例えば、選択部934は、注文数や注文数の増え方などに基づいて、より少ない画面表示装置300が受け付ける注文でも注文数が注文数閾値に達すると判断される場合、注文をまとめて取りまとめる画面表示装置300を選択、絞り込むことが出来る。選択部934は、上記例示した以外にまとめて取りまとめる画面表示装置300の選択、絞り込みを行っても構わない。
このように、選択部934を用いて、まとめて取りまとめる画面表示装置300を選択、絞り込むことで、配送にかかる時間などをより絞りこむことが可能となる。なお、選択部934によりまとめて取りまとめる画面表示装置300を選択、絞り込むか否かは、例えば、商品などの注文対象の性格やシェアリングシステム710を利用する目的などに応じて判断しても構わない。例えば、買い物代行などの目的でシェアリングシステム710を利用する場合、配送時間よりも配送コストなどのコストが優先されることが想定される。そのため、選択部934による絞り込みを行わない。一方、お弁当の手配などの目的でシェアリングシステム710を利用する場合、配送時間がより短い方が好ましい。そのため、選択部934を用いた絞り込みを行う。例えば、以上のように、選択部934による絞り込みを行うか否かは、商品の性格やシェアリングシステム710を利用する目的などに応じて判断するよう構成しても構わない。
なお、図19、図20では、1台の情報処理装置を用いて管理装置900としての機能を実現する場合について例示した。しかしながら、管理装置900としての機能は、ネットワークを介して接続された複数台の情報処理装置を用いて実現されても構わない。例えば、管理装置900としての機能は、クラウドコンピューティングなどを利用して実現されても構わない。
[第4の実施形態]
次に、本発明の第4の実施形態について、図21を参照して説明する。図21は、画面表示装置300の他の構成例を示している。
本発明の第4の実施形態においては、各実施形態において説明したデジタルサイネージである画面表示装置300の他の構成例について説明する。図21を参照すると、画面表示装置300は、例えば、記憶装置に格納されたプログラムを演算装置が実行することで、タッチパネル310と送受信部320とに加えて、配信部330としての機能を有することが出来る。
配信部330は、ビーコンを用いることで、デジタルサイネージである画面表示装置300の周辺に存在するユーザに対して、所定の情報を送信する。本実施形態の場合、例えば、配信部330は、発注待ちの商品についての値引き額などの情報や、移動手段の手配や商品などの注文を行うための注文画面へとユーザを誘導するための情報を、画面表示装置300の周辺に存在するユーザに対して送信する。
例えば、以上のように、画面表示装置300が配信部330としての機能を有することで、ユーザの興味を引くことやユーザがより手軽に注文することなどが可能となる。
[第5の実施形態]
次に、図22を参照して、本発明の第5の実施形態について説明する。第5の実施形態では、管理装置80の構成の概要について説明する。
図22は、管理装置80の構成の一例を示している。図22を参照すると、管理装置80は、例えば、受付部81と、発注部82と、を有している。なお、上記各処理部は、例えば、管理装置80が有するCPUなどの演算装置が記憶装置に格納されたプログラムを実行することで実現される。
受付部81は、ユーザからの注文を受け付ける。
発注部82は、注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する。
このように、管理装置80は、受付部81と発注部82とを有している。このような構成により、発注部82は、受付部81が受け付けた注文を、注文の状況を示す注文状況が所定の条件を満たすまで取りまとめたのち、外部端末に対して発注することが出来る。その結果、適切なタイミングで発注することが可能となり、効率的なサービスの提供を行うことが可能となる。
また、上述した管理装置80は、当該管理装置80に所定のプログラムが組み込まれることで実現できる。具体的に、本発明の他の形態であるプログラムは、管理装置80に、
ユーザからの注文を受け付ける受付部81と、注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部82と、を実現するためのプログラムである。
また、上述した管理装置80により実行される管理方法は、管理装置80が、ユーザからの注文を受け付け、注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する、という方法である。
上述した構成を有する、プログラム(記録媒体)、又は、管理方法、の発明であっても、上記管理装置80と同様の作用・効果を有するために、上述した本発明の目的を達成することが出来る。
<付記>
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明における管理方法などの概略を説明する。但し、本発明は、以下の構成に限定されない。
(付記1)
管理装置が、
ユーザからの注文を受け付け、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する
管理方法。
(付記2)
付記1に記載の管理方法であって、
所定のタイミングからの経過時間と、発注前の注文した人数である発注待ちの人数と、に基づいて、前記外部端末に対して発注するか否か判断する
管理方法。
(付記3)
付記2に記載の管理方法であって、
注文からの経過時間が経過時間閾値を超える場合、発注すると判断する
管理方法。
(付記4)
付記2または付記3に記載の管理方法であって、
発注待ちの人数が人数閾値以上となる場合、発注すると判断する
管理方法。
(付記5)
付記1から付記4までのいずれか1項に記載の管理方法であって、
予め定められた商品またはサービスの注文を受け付け、
前記商品または前記サービスごとに注文の取りまとめを行う
管理方法。
(付記6)
付記5に記載の管理方法であって、
前記商品または前記サービスと発注する際の人数ごとに、予め料金が定められている
管理方法。
(付記7)
付記5または付記6に記載の管理方法であって、
前記商品または前記サービスごとに、注文からの経過時間に応じた情報と、発注待ちの人数に応じた情報を画面表示させる
管理方法。
(付記8)
付記7に記載の管理方法であって、
前記商品または前記サービスごとに、注文からの経過時間に応じた情報と、発注待ちの人数に応じた情報と広告を画面に表示させる
管理方法。
(付記9)
付記1から付記8までのいずれか1項に記載の管理方法であって、
発注先となる前記外部端末を選択し、
選択した前記外部端末に対して発注する
管理方法。
(付記10)
付記9に記載の管理方法であって、
発注待ちの人数を示す情報に基づいて、前記外部端末を選択する
管理方法。
(付記11)
付記1から付記10までのいずれか1項に記載の管理方法であって、
複数の画面表示装置から注文を受け付け、
注文の状況を示す注文状況が所定の条件を満たすまで注文をまとめて取りまとめたのち、外部端末に対して発注する
管理方法。
(付記12)
付記11に記載の管理方法であって、
注文を受け付ける対象の画面表示装置が、商品を配送する際にかかる配送時間に基づいて定められている
管理方法。
(付記13)
付記11または付記12に記載の管理方法であって、
注文状況に基づいて、まとめて取りまとめる対象となる画面表示装置を選択する
管理方法。
(付記14)
付記13に記載の管理方法であって、
注文対象の性格に基づいて、まとめて取りまとめる対象となる画面表示装置を選択するか否か判断する
管理方法。
(付記15)
ユーザからの注文を受け付ける受付部と、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部
を有する
管理装置。
(付記16)
管理装置に、
ユーザからの注文を受け付ける受付部と、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部
を実現するためのプログラム。
(付記17)
デジタルサイネージを利用して移動手段のシェアを行うシェアリングシステムであって、
ユーザから、予め定められた行先への移動手段の手配を希望する旨を示す注文を受け付ける受付部と、
前記行先ごとに、注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち、外部端末に対して発注する発注部と、
を有する
シェアリングシステム。
(付記18)
デジタルサイネージを利用して移動手段のシェアを行うシェアリングシステムにおいてユーザの注文を管理する管理装置が、
ユーザからの注文を受け付け、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する
管理方法。
なお、上記各実施形態及び付記において記載したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されていたりする。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。
以上、上記各実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることが出来る。例えば、第1の実施形態で説明したシェアリングシステム100が認証端末600を有するなど、第1の実施形態から第5の実施形態までのいずれかで説明した内容を組み合わせても構わない。
なお、本発明は、日本国にて2019年11月25日に特許出願された特願2019-212105の特許出願に基づく優先権主張の利益、2020年6月26日に特許出願された特願2020-110137の特許出願に基づく優先権主張の利益を享受するものであり、当該特許出願に記載された内容は、全て本明細書に含まれるものとする。