JP7294703B2 - 管理方法 - Google Patents

Description

本発明は、管理方法、管理装置、記録媒体に関する。

サービスの発注などを管理する管理装置が知られている。

このような管理装置の一例として、例えば、特許文献１がある。特許文献１には、例えば、受付部と、取得部と、格納部と、出力部と、を有する注文管理装置が記載されている。特許文献１によると、受付部は、建物内の共用スペースに表示された注文可能な商品の一覧のなかからユーザが注文した商品の入力を受け付ける。また、取得部は、受付部によって商品の入力を受け付けた場合に、ユーザの認証に関する認証情報とユーザの住所情報とを取得する。そして、格納部は、ユーザの認証が成功した場合に、ユーザが注文した商品と住所情報とを記憶装置に格納する。その後、出力部は、記憶装置に格納された情報を外部の配送業者装置に出力する。

特開２０１９－１３３４４４号公報

特許文献１に記載の技術の場合、記憶装置に格納された情報を配送業者装置などの受注先装置に出力することで発注を行っているが、発注のタイミングについては特に限定されていない。そのため、特許文献１に記載の技術の場合、発注するサービスの内容や発注のタイミングによっては、必ずしも適切なタイミングで発注することが出来なかった。その結果、効率的なサービスの提供ができなくなるおそれがあった。

このように、適切なタイミングで発注することが難しく、効率的なサービスの提供ができないおそれがある、という課題が生じていた。

そこで、本発明の目的は、適切なタイミングで発注することが難しく、効率的なサービスの提供ができないおそれがある、という課題を解決する管理方法、管理装置、プログラムを提供することにある。

かかる目的を達成するため本発明の一形態である管理方法は、
管理装置が、
ユーザからの注文を受け付け、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する
という構成をとる。

また、本発明の他の形態である管理装置は、
ユーザからの注文を受け付ける受付部と、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部と、
を有する
という構成をとる。

また、本発明の他の形態である記録媒体は、
管理装置に、
ユーザからの注文を受け付ける受付部と、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部と、
を実現するためのプログラムを記録した、コンピュータが読み取り可能な記録媒体である。

本発明は、以上のように構成されることにより、適切なタイミングで発注することが難しく、効率的なサービスの提供ができないおそれがある、という課題を解決する管理方法、管理装置、記録媒体を提供することが可能となる。

本発明の第１の実施形態におけるシェアリングシステムの全体の構成の一例を示すブロック図である。 図１で示す管理装置の構成の一例を示すブロック図である。 図２で示す行先・運賃情報の一例を示す図である。 図２で示す発注待ち情報の一例を示す図である。 図２で示す発注先情報の一例を示す図である。 図１で示す画面表示装置の構成の一例を示すブロック図である。 本発明の第１の実施形態における管理装置の動作の一例を示すフローチャートである。 管理装置の他の構成の一例を示すブロック図である。 図８で示す注文まとめ部の処理の一例を説明するための図である。 管理装置の他の構成の一例を示すブロック図である。 シェアリングシステムの他の構成の一例を示すブロック図である。 図１０で示す端末の構成の一例を示すブロック図である。 管理装置の他の構成の一例を示すブロック図である。 仮想始点を生成する処理の一例を説明するための図である。 運賃算出処理の一例を説明するための図である。 本発明の第２の実施形態におけるシェアリングシステムの全体の構成の一例を示すブロック図である。 本発明の第２の実施形態における管理装置の構成の一例を示すブロック図である。 本発明の第３の実施形態におけるシェアリングシステムの全体の構成の一例を示すブロック図である。 管理装置の構成の一例を示すブロック図である。 管理装置の他の構成例を示すブロック図である。 画面表示装置の他の構成例を示すブロック図である。 管理装置の構成の一例を示すブロック図である。

［第１の実施形態］
本発明の第１の実施形態を図１から図１５までを参照して説明する。図１は、シェアリングシステム１００の全体の構成の一例を示すブロック図である。図２は、管理装置２００の構成の一例を示すブロック図である。図３は、行先・運賃情報２２１の一例を示す図である。図４は、発注待ち情報２２２の一例を示す図である。図５は、発注先情報２２３の一例を示す図である。図６は、画面表示装置３００の構成の一例を示すブロック図である。図７は、管理装置２００の動作の一例を示すフローチャートである。図８は、管理装置２００の他の構成の一例を示すブロック図である。図９は、注文まとめ部２３５の処理の一例を説明するための図である。図１０は、管理装置２００の他の構成の一例を示すブロック図である。図１１は、シェアリングシステム１００の他の構成の一例を示すブロック図である。図１２は、図１１で示す端末５００の構成の一例を示すブロック図である。図１３は、管理装置２００の他の構成の一例を示すブロック図である。図１４は、仮想始点を生成する処理の一例を説明するための図である。図１５は、運賃算出処理の一例を説明するための図である。

本発明の第１の実施形態では、広告などを表示する画面表示装置３００を利用してタクシーや貸し切りバスなどの移動手段をシェアするシステムであるシェアリングシステム１００について説明する。後述するように、本実施形態において説明するシェアリングシステム１００では、ユーザによる行先の選択（つまり、行先への移動手段の手配を行うサービスの注文）を受け付けると、注文の状況を示す注文状況が予め定められた条件を満たすまで発注を行わず待機する。換言すると、シェアリングシステム１００は、注文状況が条件を満たすまで注文の取りまとめを行う。そして、シェアリングシステム１００は、注文状況が条件を満たした後に、発注処理を行う。

なお、広告などを表示する画面表示装置３００は、デジタルサイネージ、電子看板、などとも呼ばれる。そのため、シェアリングシステム１００は、デジタルサイネージを活用して移動手段を効率的にシェアするためのシステムである、ということもできる。

図１は、シェアリングシステム１００の全体の構成の一例を示している。図１を参照すると、シェアリングシステム１００は、例えば、管理装置２００と、画面表示装置３００と、業者端末４００と、を有している。図１で示すように、管理装置２００と画面表示装置３００とは、互いに通信可能なよう接続されている。また、管理装置２００と業者端末４００とは、互いに通信可能なよう、例えばネットワークなどを介して接続されている。

図１で示す装置のうち、管理装置２００と画面表示装置３００（または、少なくとも画面表示装置３００）は、例えば、コンビニエンスストアやスーパーなどの商業施設、公共施設、オフィスや集合住宅の共用部などに設置される。また、図１で示す装置のうち、業者端末４００は、例えば、タクシー会社やバス会社などの移動手段を管理する管理業者に設置される。管理装置２００、画面表示装置３００、業者端末４００は、上記例示した以外の箇所に設置されても構わない。

なお、シェアリングシステム１００が有する管理装置２００、画面表示装置３００、業者端末４００の数は、図１で例示した場合に限定されない。シェアリングシステム１００は、１以上の任意の数の管理装置２００、画面表示装置３００、業者端末４００を有して構わない。

管理装置２００は、ユーザによる注文の取りまとめを行うなど、発注を管理する情報処理装置である。図２は、管理装置２００の構成の一例を示している。図２を参照すると、管理装置２００は、主な構成要素として、例えば、通信Ｉ／Ｆ部２１０と、記憶部２２０と、演算処理部２３０と、を有している。また、管理装置２００は、画面表示装置３００と接続されている。

通信Ｉ／Ｆ部２１０は、データ通信回路からなる。通信Ｉ／Ｆ部２１０は、通信回線を介して接続された業者端末４００などとの間で、データ通信を行う。

記憶部２２０は、ハードディスクやメモリなどの記憶装置である。記憶部２２０は、演算処理部２３０における各種処理に必要な処理情報やプログラム２２５を記憶する。プログラム２２５は、演算処理部２３０に読み込まれて実行されることにより各種処理部を実現する。プログラム２２５は、通信Ｉ／Ｆ部２１０などのデータ入出力機能を介して外部装置や記録媒体から予め読み込まれ、記憶部２２０に保存されている。記憶部２２０で記憶される主な情報としては、例えば、行先・運賃情報２２１、発注待ち情報２２２、発注先情報２２３、発注元情報２２４、などがある。

行先・運賃情報２２１は、例えば、行先、人数ごとの料金である運賃を示している。行先・運賃情報２２１は、例えば、予め定められて記憶部２２０に格納されている。

図３は、行先・運賃情報２２１の一例を示している。図３を参照すると、行先・運賃情報２２１では、例えば、行先と、人数と、運賃と、が対応づけられている。例えば、図３の１行目は、行先「ＡＡＡ」に行く人数が「１名」である場合、運賃が「１，０００円」であることを示している。また、例えば、図３の２行目は、行先「ＡＡＡ」に行く人数が「２名」である場合、運賃が「８００円」であることを示している。つまり、一人あたりの運賃が１，０００円から８００円に抑えられることを示している。

このように、行先・運賃情報２２１には、画面表示装置３００の設置場所に応じて予め選択された行先を示す情報が含まれている。また、行先・運賃情報２２１には、人数に応じて例えば予め定められた運賃を示す情報が含まれている。

なお、行先・運賃情報２２１には、複数の管理業者の情報を含むことが出来る。例えば、行先・運賃情報２２１には、タクシー会社の行先・運賃を示す情報と、バス会社の行先・運賃を示す情報と、など複数の管理業者の行先・運賃を示す情報を含めることが出来る。

発注待ち情報２２２は、後述する判断部２３３により注文の取りまとめを行っている最中の注文状況を示す情報である。発注待ち情報２２２は、受付部２３２や送信部２３４などにより適宜更新される。

図４は、発注待ち情報２２２の一例を示している。図４を参照すると、発注待ち情報２２２では、例えば、行先と、発注待ち中の注文のうち最初の注文が行われた時刻を示す注文時刻と、発注待ちの人数と、が対応付けられている。例えば、図４の１行目は、行先「ＡＡＡ」に対する注文が最初に行われた時刻（つまり、発注待ちが開始された時刻）が「ｘｘ：ｙｙ：ｚｚ」であり、現在「２名」が注文して発注待ちを行っている状況であることを示している。

発注先情報２２３は、送信部２３４による注文の送信先を示す情報である。発注先情報２２３は、例えば、予め定められて記憶部２２０に格納されている。

図５は、発注先情報２２３の一例を示している。図５を参照すると、発注先情報２２３では、例えば、行先ごとに、発注先となる業者端末４００の情報などが含まれる発注先情報が対応づけられている。例えば、図５の１行目は、行先「ＡＡＡ，ＢＢＢ，ＣＣＣ」の発注先情報が「αααα」であることを示している。

なお、発注先情報２２３は、発注先となる業者端末４００の情報などが含まれる発注先情報のみを含むなど、上記例示した一部のみを有していても構わない。また、発注先情報２２３には、１社のみの情報が含まれていても構わないし、２以上の任意の数の情報が含まれていても構わない。

発注元情報２２４には、画面表示装置３００が置かれた場所の住所など発注元となる画面表示装置３００の設置場所を示す情報が含まれている。発注元情報２２４は、例えば、予め定められて記憶部２２０に格納されている。

演算処理部２３０は、ＭＰＵなどのマイクロプロセッサとその周辺回路を有する。演算処理部２３０は、記憶部２２０からプログラム２２５を読み込んで実行することにより、上記ハードウェアとプログラム２２５とを協働させて各種処理部を実現する。演算処理部２３０で実現される主な処理部として、例えば、画面表示部２３１と、受付部２３２と、判断部２３３と、送信部２３４と、がある。

画面表示部２３１は、行先・運賃情報２２１が示す行先や運賃、発注待ち情報２２２が示す注文状況、注文状況に応じて算出される値（例えば、注文時刻に後述する経過時間閾値を足した発注予定時刻や後述する人数閾値から発注待ちの人数を引いた注文可能人数）などを画面表示装置３００に表示させる。画面表示部２３１は、記憶部２２０に予め記憶されている行先などに応じた画像などを、上記情報とともに画面表示装置３００に表示させても構わない。

画面表示部２３１による制御により、画面表示装置３００上には、例えば、行先ごとの発注予定時刻、注文可能人数、運賃、などを表示することが出来る換言すると、画面表示部２３１による制御により、画面表示装置３００上には、行先「ＡＡＡ」への手配というサービス、行先「ＢＢＢ」への手配というサービス、などサービスごとに各種情報を表示することが出来る。なお、画面表示部２３１は、受付部２３２が新たな注文を受け付けた際や、送信部２３４が新たな発注を行った際など注文状況に変化が生じた際に、画面表示装置３００上の表示を新たな注文状況に対応するよう制御する。

なお、画面表示部２３１は、上記例示した以外の情報を画面表示装置３００上に表示させても構わない。例えば、画面表示部２３１は、現在の人数に応じた運賃や次に新たに注文が入った場合の運賃などを画面表示装置３００上に表示させても構わない。また、画面表示部２３１は、例えば、各種広告画面などを画面表示装置３００上に表示させることが出来る。画面表示部２３１は、例えば、表示する内容が時間の経過に応じて変化するなど、経時的な制御を行っても構わない。

受付部２３２は、ユーザによる新たな注文を受け付ける。例えば、ユーザが画面表示装置３００のタッチパネル３１０をタッチしたとする。すると、受付部２３２は、ユーザがタッチした場所に関連付けられた行先を示す情報と、注文を受け付けた時刻を示す情報（例えば、ユーザがタッチした時刻を示す情報）と、を画面表示装置３００から受け付ける。

具体的には、例えば、ユーザが行先「ＡＡＡ」に関連づけられた枠をタッチしたとする。この場合、受付部２３２は、タッチした場所に関連付けられた行先「ＡＡＡ」への移動手段の手配を希望する旨を示す注文を、画面表示装置３００から受け付ける。なお、上記注文には、行先「ＡＡＡ」を示す情報と、注文を受け付けた時刻を示す情報と、が含まれている。

また、受付部２３２は、受け付けた注文に応じて発注待ち情報２２２を更新する。例えば、受け付けた行先への発注待ちの注文がない場合、受付部２３２は、発注待ち情報２２２のうち受け付けた行先に対応づけられた注文時刻を、注文を受け付けた時刻とする。また、受付部２３２は、発注待ちの人数を１とする。一方、受け付けた行先への発注待ちの注文が既にある場合、受付部２３２は、受け付けた行先に対応する人数を１加算する。例えば、図４で示す場合、行先「ＡＡＡ」への発注待ちの注文が既にある。そのため、受付部２３２は、行先「ＡＡＡ」に対応する人数を１加算する。

このように、受付部２３２は、行先への移動手段の手配を希望する旨を示す注文をユーザから受け付ける。そして、受付部２３２は、受け付けた情報に応じて、発注待ち情報２２２を更新する。なお、受付部２３２により発注待ち情報２２２の更新が行われると、画面表示部２３１により画面表示装置３００上の表示も更新された発注待ち情報２２２に応じたものに更新される。

判断部２３３は、発注待ち情報２２２が示す注文状況などに基づいて、発注するか否かなどを判断する。

例えば、判断部２３３は、発注待ち中の注文のうち最初の注文が行われた時刻を示す注文時刻からの経過時間の上限を示す経過時間閾値（例えば、１０分や３０分など）や、人数の上限を示す人数閾値（例えば、タクシーに乗車可能な人数の値。４人など）を予め有している。そして、判断部２３３は、発注待ち情報２２２が示す注文状況と、経過時間閾値と、人数閾値と、に基づいて、発注するか否か判断する。

具体的には、例えば、判断部２３３は、発注待ち情報２２２中の注文時刻からの経過時間が経過時間閾値を超える場合、経過時間閾値を超える注文時刻に対応する行先の注文を発注すると判断する。また、判断部２３３は、発注待ち情報２２２中の人数が人数閾値以上である場合、注文時刻からの経過時間が経過時間閾値を超えていなくても、対応する行先の注文を発注すると判断する。

また、判断部２３３は、例えば、発注先情報２２３などに基づいて、発注先の判断を行うことが出来る。例えば、判断部２３３は、発注先情報２２３において、発注すると判断した注文の行先に対応付けられている発注先に発注すると判断する。なお、発注先情報２２３に１社の情報しか含まれない場合、判断部２３３は、発注先の判断を行わなくても構わない。

このように、判断部２３３は、発注するか否か判断するとともに、発注先を判断することが出来る。そして、判断部２３３は、判断の結果を送信部２３４に通知する。

なお、判断部２３３は、発注先情報２２３以外の情報などを参照して、発注先の判断を行うよう構成しても構わない。

例えば、画面表示装置３００の設置場所周辺でイベントが開催される場合、画面表示装置３００の設置場所周辺に駅があり電車に運休が生じている場合、荒天や猛暑など天候に問題がある場合、などの諸事情がある場合、通常時よりも移動手段のシェアを希望する人数が増えることが想定される。このような場合、単にタクシー会社に対して発注を行っていると、タクシーが不足することが想定される。そこで、判断部２３３は、例えば、画面表示装置３００の設置場所周辺で行われるイベントや天候などを示す状況情報を外部装置から取得する。そして、判断部２３３は、取得した状況情報が予め定められた状況を示す場合、発注先をタクシー会社にするかバス会社にするか判断することが出来る。

具体的には、例えば、判断部２３３は、上述したような諸事情を示す状況情報を取得した場合において、単位時間あたりの発注数が閾値を超えた場合や単位時間当たりの人数の増加量が閾値を超えた場合、発注待ち情報２２２中の人数が人数閾値以上でも発注を行わない。そして、判断部２３３は、人数が第２人数閾値（例えば、マイクロバスの定員など）以上となる場合、バス会社が有する業者端末４００に対して発注する旨を判断する。一方、単位時間あたりの発注数が閾値を超えない場合や単位時間当たりの人数の増加量が閾値を超えない場合、判断部２３３は、発注待ち情報２２２中の人数が人数閾値以上になると、タクシー会社が有する業者端末４００に対して発注する旨を判断する。なお、人数が人数閾値以上であるものの第２人数閾値よりも小さい状況で注文時刻からの経過時間が経過時間閾値を超えた場合、判断部２３３は、例えば、タクシー会社とバス会社のうちより運賃が安くなる方に発注するよう判断することが出来る。

例えば、以上のように、判断部２３３は、状況情報などを参照して、発注先をタクシー会社にするかバス会社にするか判断することが出来る。なお、判断部２３３は、単位時間あたりの発注数が閾値を超えた場合や単位時間当たりの人数の増加量が閾値を超えた場合に、状況情報にかかわらず発注先の判断を行うよう構成しても構わない。また、判断部２３３は、上述したような諸事情を示す状況情報を取得した場合、原則として常に発注先の判断を行うよう構成しても構わない。

送信部２３４は、判断部２３３からの通知に応じて、発注情報を発注先の管理業者が有する業者端末４００に対して送信する。つまり、送信部２３４は、判断部２３３による判断の結果に応じて、移動手段の手配（発注）を行う。また、送信部２３４は、発注待ち情報２２２を更新する。

例えば、送信部２３４は、発注先情報２２３を参照して、判断部２３３が判断した発注先となる業者端末４００の情報を確認する。そして、送信部２３４は、確認した結果に基づいて、発注先となる業者端末４００に対して、行先を示す情報、人数を示す情報、発注元情報２２４に含まれる発注元となる画面表示装置３００の設置場所を示す情報、などの発注情報を送信する。

また、送信部２３４は、発注待ち情報２２２のうち発注を行った行先に対応する、注文時刻や人数などの情報を削除する。このように、送信部２３４は、発注待ち情報２２２のうち発注に応じた情報を更新する。

以上が、管理装置２００の構成の一例である。

画面表示装置３００は、上述したように、デジタルサイネージ、電子看板などと呼ばれる表示装置である。図６は、画面表示装置３００の主な構成の一例を示している。図６を参照すると、画面表示装置３００は、例えば、時計機能などの一般的な機能のほかに、タッチパネル３１０と、送受信部３２０と、を有している。

タッチパネル３１０は、例えば、上述したように、画面表示部２３１からの指示に応じて、行先・運賃情報２２１が示す行先や運賃、発注待ち情報２２２が示す注文状況、注文状況に応じて算出される値などを画面表示することが出来る。また、タッチパネル３１０は、画面表示部２３１からの指示に応じて、画面表示の内容を適宜更新する。また、タッチパネル３１０は、ユーザによるタッチパネル３１０へのタッチに応じて、タッチした場所に関連付けられた行先を示す情報を取得する。

送受信部３２０は、管理装置２００との間で情報の送受信を行う。例えば、送受信部３２０は、管理装置２００から、タッチパネル３１０上に表示する画面を制御するための情報を受信する。また、送受信部３２０は、管理装置２００に対して、ユーザがタッチした場所に関連付けられた行先を示す情報と、ユーザがタッチパネル３１０にタッチした時刻を示す情報と、を送信する。このように、送受信部３２０は、管理装置２００から情報を受信するとともに管理装置２００に対して情報を送信する。

業者端末４００は、移動手段を管理する管理業者に置かれた情報処理装置である。業者端末４００は、例えば、管理装置２００から、行先を示す情報、人数を示す情報、発注元情報２２４に含まれる発注元となる画面表示装置３００の設置場所を示す情報、などを受信する。業者端末４００は、受信した情報に基づいて、画面表示装置３００の設置場所にタクシーなどの移動手段が向かうようタクシーなどの指示対象に対して指示することが出来る。業者端末４００は、当該業者端末４００が有する画面表示部などに受信した情報を表示するよう構成しても構わない。

以上が、シェアリングシステム１００の構成の一例である。続いて、図７を参照して、管理装置２００の動作の一例について説明する。

図７は、管理装置２００の動作の一例を示している。図７を参照すると、受付部２３２は、ユーザによる新たな注文を受け付ける（ステップＳ１０１）。例えば、ユーザが画面表示装置３００のタッチパネルをタッチすると、受付部２３２は、ユーザがタッチした場所に関連付けられた行先を示す情報と、注文を受け付けた時刻を示す情報（例えば、ユーザがタッチした時刻を示す情報）と、を画面表示装置３００から受け付ける。

また、受付部２３２は、受け付けた注文に応じて発注待ち情報２２２を更新する（ステップＳ１０２）。例えば、受け付けた行先への発注待ちの注文がない場合、受付部２３２は、発注待ち情報２２２のうち受け付けた行先に対応づけられた注文時刻を、注文を受け付けた時刻とする。また、受付部２３２は、発注待ちの人数を１とする。一方、受け付けた行先への発注待ちの注文が既にある場合、受付部２３２は、受け付けた行先に対応する人数を１加算する。

判断部２３３は、発注待ち情報２２２が示す注文状況などに基づいて、発注するか否かを判断する（ステップＳ１０３）。例えば、判断部２３３は、発注待ち情報２２２中の注文時刻からの経過時間が経過時間閾値を超える場合、経過時間閾値を超える注文時刻に対応する行先の注文を発注すると判断する。また、判断部２３３は、発注待ち情報２２２中の人数が人数閾値以上となる場合、注文時刻からの経過時間が経過時間閾値を超えていなくても、対応する行先の注文を発注すると判断する。

このように、判断部２３３は、予め定められた条件を満たす場合（ステップＳ１０３、Ｙｅｓ）、発注すると判断する。また、判断部２３３は、発注先を判断する（ステップＳ１０４）。例えば、判断部２３３は、発注先情報２２３や状況情報などに基づいて、発注先を判断する。そして、判断部２３３は、判断の結果を送信部２３４に通知する。なお、発注先の判断を行わないよう構成する場合、ステップＳ１０４の処理は省略して構わない。

送信部２３４は、判断部２３３からの通知に応じて、発注情報を発注先の管理業者が有する業者端末４００に対して送信する（ステップＳ１０５）。例えば、送信部２３４は、行先を示す情報、人数を示す情報、発注元情報２２４に含まれる発注元となる画面表示装置３００の設置場所を示す情報、などの発注情報を、送信先となる業者端末４００に対して送信する。また、送信部２３４は、発注待ち情報２２２のうち発注を行った行先に対応する、注文時刻や人数などの情報を削除する。このように、送信部２３４は、発注待ち情報２２２のうち発注に応じた情報を更新する。

以上が、管理装置２００の動作の一例である。

このように、管理装置２００は、判断部２３３と、送信部２３４と、を有している。このような構成によると、判断部２３３は、発注待ち情報２２２が示す注文時刻からの経過時間や人数などの注文状況が条件を満たすことで、発注すると判断する。つまり、上記構成によると、注文状況が条件を満たすまで発注する旨の判断を遅らせることが出来る。これにより、適切なタイミングまで注文の取りまとめを行うことが可能となり、その結果、移動手段のシェアを効率的に行うことが可能となる。つまり、本実施形態において説明したシェアリングシステム１００によると、移動手段の手配などが過度に集中することを抑制することが出来るとともに、移動手段の効率的なシェアにより移動手段を利用する際の料金などを抑制することが可能となる。

また、本実施形態で説明した方法によると、発注待ちの注文状況を画面表示装置３００に表示させる。このように発注待ちの注文状況を表示させることで、画面表示を確認したユーザなどが発注までどれくらいの時間がかかるかなどの目途をつけることが可能となり、その結果として、例えば、注文までの敷居を下げることが可能となる。つまり、より気軽にタクシーなどの移動手段を用いることが可能となる。

なお、シェアリングシステム１００の構成は、本実施形態で例示した場合に限定されない。例えば、管理装置２００と画面表示装置３００とは、それぞれが別の装置であっても構わないし、一体的に構成されていても構わない。また、管理装置２００は、例えば、ネットワークを介して接続された複数台の情報処理装置により構成されても構わない。

また、管理装置２００は、例えば、ユーザの年齢、性別、たばこを吸うか否か、などを示すユーザの属性を示す属性情報を取得するよう構成することが出来る。管理装置２００を上記のように構成する場合、判断部２３３は、例えば、発注待ち情報２２２を、属性ごとに分けて管理することなどにより、属性ごとに注文の取りまとめを行うよう構成しても構わない。なお、属性情報は、ユーザの入力に応じて取得するよう構成しても構わないし、画面表示装置３００の設置場所周辺に設置された監視カメラが取得した画像データなどに基づいて取得するよう構成しても構わない。

また、送信部２３４は、判断部２３３が発注の判断を行う前に、発注待ち情報２２２などを業者端末４００に対して送信するよう構成しても構わない。例えば、送信部２３４は、注文時刻からの経過時間が所定時間（例えば、２０分など）を過ぎた、注文可能な人数が残り１人である、など、予め定義された状況（もう少しで発注される状況）である場合に、発注待ち情報２２２に含まれる情報などを業者端末４００に対して送信するよう構成することが出来る。送信部２３４は、予め定められた時間ごとに定期的に発注待ち情報２２２を業者端末４００に対して送信するよう構成しても構わない。

また、一度に一人が注文を出すのではなく、複数の人数を含むグループで注文を出すことも想定される。このような場合に対応するため、画面表示装置３００や受付部２３２は、行先を示す情報を取得するとともに、一度に注文する人数を示す情報を取得するよう構成しても構わない。また、上記のように構成する場合、管理装置２００は、例えば、１グループを一人とみなして、行先・運賃情報２２１が示す運賃を適用するよう構成しても構わない。

また、行先・運賃情報２２１は、必ずしも人数ごとの運賃を示していなくても構わない。例えば、行先・運賃情報２２１には、行先ごとの運賃を示す情報が含まれていても構わない。つまり、行先・運賃情報２２１が示す運賃は、人数にかかわらず同額（つまり、乗客が１名の場合でも２名の場合でもそれぞれに同じ料金がかかる）であっても構わない。

また、シェアリングシステム１００や管理装置２００は、本実施形態で例示した以外の構成を有することが出来る。

例えば、図８、管理装置２００の他の構成例を示している。図８を参照すると、演算処理部２３０は、プログラム２２５を読み込んで実行することにより、図２で例示した場合に加えて、例えば、注文まとめ部２３５を実現することが出来る。

注文まとめ部２３５は、行先などに応じて、取りまとめ中の複数の注文をまとめる。図９は、注文まとめ部２３５による処理の一例を示している。例えば、図９で示すように、予め定められた行先によっては、他の行先を経由する場合がある。具体的には、図９で示す場合、画面表示装置３００の設置場所から行先である「降車地Ｃ」へと向かう間に、「降車地Ｂ」がある。そのため、行先「降車地Ｃ」は行先「降車地Ｂ」を経由する。このように、行先までの間に他の行先が存在する場合などにおいて、注文まとめ部２３５は、複数の注文をまとめる。例えば、図９で示す場合、注文まとめ部２３５は、行先が「降車地Ｂ」である注文１と行先が「降車地Ｃ」である注文２とをまとめる。その結果、注文まとめ部２３５は、最終的な行先が「降車地Ｃ」であり、「降車地Ｂ」を経由する新たな注文（注文１＆２）を生成するとともに、生成処理に応じた発注待ち情報２２２の更新などを行う。

なお、注文まとめ部２３５が複数の注文をまとめた場合、判断部２３３は、注文まとめ部２３５がまとめた結果生成した新たな注文について、まとめられた人数などに基づいて、発注するか否か判断する。また、送信部２３４は、発注情報を発注先の管理業者が有する業者端末４００に対して送信する際、業者端末４００に対して、「降車地Ｂ」を経由した上で「降車地Ｃ」に向かう旨を示すなど、まとめたそれぞれの注文の行先を示す情報を送信する。

例えば、以上のように、管理装置２００は注文まとめ部２３５を有することが出来る。なお、上述したように、本実施形態で説明する管理装置２００の場合、例えば、画面表示装置３００ごとに（または、設置場所ごとに）行先が予め定められている。そのため、どの行先の注文とどの行先の注文とを取りまとめるか、つまり、注文まとめ部２３５によるまとめ対象となる行先の組み合わせについては、例えば、予め定めておくことが出来る。

また、注文まとめ部２３５は、出来る限り常に注文をまとめるよう構成しても構わないし、例えば予め定められた条件を満たす場合のみ注文をまとめるよう構成しても構わない。例えば、注文まとめ部２３５は、注文時刻からの経過時間が所定の時間を過ぎる、まとめることでまとめた後の人数が人数閾値となるなど人数が所定の条件を満たす、などの予め定められた条件を満たす場合に、注文をまとめるよう構成することが出来る。

また、例えば、図１０は、管理装置２００の他の構成例を示している。図１０を参照すると、管理装置２００の記憶部２２０は、図２で例示した場合に加えて、駐車場情報２２６を有することが出来る。また、演算処理部２３０は、プログラム２２５を読み込んで実行することにより、図２や図８で例示した場合に加えて、駐車場状況取得部２３６を実現することが出来る。

駐車場情報２２６は、画面表示装置３００の設置場所周辺の駐車場の情報を示している。例えば、画面表示装置３００がコンビニエンスストアに設置されている場合、駐車場情報２２６は、コンビニエンスストアが有する駐車場の広さなどを示している。なお、駐車場情報２２６は、駐車場が混雑する時間帯など混雑状況を示す情報や、画面表示装置３００の設置場所周辺の道路の状況などを示す情報などを含んでも構わない。

駐車場状況取得部２３６は、画面表示装置３００の設置場所周辺の駐車場の状況を示す駐車場状況情報を取得する。例えば、駐車場状況取得部２３６は、通信Ｉ／Ｆ部２１０を介して接続された、画面表示装置３００の設置場所周辺の駐車場を撮影する監視カメラが取得した画像データを取得する。そして、駐車場状況取得部２３６は、取得した画像データに基づいて、駐車場が混んでいるか否かなどの駐車場の状況を示す駐車場状況情報を取得する。また、駐車場状況取得部２３６は、駐車場の空き情報を管理する外部装置などから、駐車場状況情報を取得しても構わない。

管理装置２００が上述したような駐車場情報２２６や駐車場状況取得部２３６などを有する場合、送信部２３４は、駐車場情報２２６や駐車場状況取得部２３６が取得した駐車場状況情報を業者端末４００に送信することが出来る。例えば、送信部２３４は、発注情報を送信する際などに、発注情報とともに、駐車場情報２２６や駐車場状況情報を送信することが出来る。送信部２３４は、上記例示したタイミング以外で、駐車場情報２２６や駐車場状況情報を業者端末４００に対して送信しても構わない。

このように構成することで、移動手段の管理業者は、事前に駐車場などの混雑具合を把握することが可能となる。これにより、より効率的なシェアを実現することが出来る。

また、図１１は、シェアリングシステム１００の変形例を示している。図１１を参照すると、シェアリングシステム１００は、管理装置２００と画面表示装置３００と業者端末４００とに加えて、端末５００を有することが出来る。図１１で示すように、端末５００は、管理装置２００と無線通信などにより互いに通信可能なよう接続されている。

端末５００は、行先の指定を管理装置２００に対して行うことが可能なスマートフォンなどの携帯型の情報処理装置である。図１２は、端末５００の構成の一例を示している。図１２を参照すると、端末５００は、例えば、スマートフォンとしての一般的な構成の他に、行先指定部５１０と、位置情報取得部５２０と、送受信部５３０と、を有している。なお、端末５００が有する処理部としての機能は、例えば、端末５００が有するＣＰＵ（Central Processing Unit）などの演算装置が記憶装置に格納されたプログラムを実行することで実現される。

行先指定部５１０は、ユーザの操作に応じて、ユーザが移動手段の手配を希望する行先を示す情報を取得する。例えば、端末５００は、送受信部５３０を介して管理装置２００から行先の候補を示す情報を取得しており、画面表示している。行先指定部５１０は、ユーザの操作に応じて、表示した行先候補のうちユーザが移動手段の手配を希望する行先を示す情報を取得する。

位置情報取得部５２０は、ＧＰＳなどを利用して、端末５００の位置を示す情報である位置情報を取得する。位置情報取得部５２０は、ＧＰＳ以外の既知の方法を用いて端末５００の位置を示す情報を取得しても構わない。

送受信部５３０は、アンテナなどを有しており、管理装置２００との間で情報の送受信を行う。例えば、送受信部５３０は、管理装置２００から、行先の候補を示す情報を受信する。また、送受信部５３０は、管理装置２００に対して、ユーザが選択した行先を示す情報などを送信する。送受信部５３０は、行先を示す情報を送信する際などに、位置情報取得部５２０が取得した位置情報などを送信することが出来る。

このように、端末５００は、行先指定部５１０を有している。このような構成によると、行先指定部５１０により行先を示す情報を管理装置２００に対して送信することが出来る。これにより、例えば、画面表示装置３００をタッチしなくても行先を指定することが可能となる。その結果、例えば、画面表示装置３００の設置場所に行く前に注文を行うことが可能となり、より効率的に移動手段のシェアを行うことが可能となる。

また、シェアリングシステム１００が端末５００を有する場合、管理装置２００は、図１３で示すような構成を有しても構わない。図１３は、管理装置２００の他の構成例を示している。図１３を参照すると、管理装置２００の演算処理部２３０は、プログラム２２５を読み込んで実行することにより、図２、図８、図１０で例示した場合に加えて、仮想始点生成部２３７と、運賃算出部２３８と、を実現することが出来る。

仮想始点生成部２３７は、仮想始点を生成するか否か判断する。また、仮想始点生成部２３７は、タクシーなどの移動手段を呼び出す場所である始点を生成する。

例えば、仮想始点生成部２３７は、所定範囲内に存在する端末５００の数に基づいて、仮想始点を生成するか否か判断する。具体的には、例えば、図１４で示すように、所定範囲内に予め定められた数以上の端末５００が存在する場合、仮想始点生成部２３７は、仮想始点を生成すると判断する。なお、所定範囲の値や数は任意の値・数で構わない。

また、仮想始点生成部２３７は、仮想始点を生成する際に状況情報を参照するよう構成しても構わない。例えば、仮想始点生成部２３７は、状況情報により画面表示装置３００の設置場所周辺の公園でイベントが開催されると判断される場合など人が集まると判断される状況である場合、仮想始点を生成すると判断することが出来る。

また、仮想始点生成部２３７は、所定範囲内に存在する端末５００の位置情報や状況情報などに基づいて、始点となる場所を決定する。これにより、仮想始点生成部２３７は、仮想始点を生成する。例えば、仮想始点生成部２３７は、所定範囲内に存在する端末５００の位置の中央、付近に存在する駐車場など、所定範囲内に存在する端末５００の位置に応じた場所などを始点とする。

運賃算出部２３８は、仮想始点生成部２３７が生成した始点から予め定められた行先まで移動手段で移動した場合の運賃を算出する。例えば、運賃算出部２３８は、図１５で示すように、仮想始点と行先との間の距離に基づいて、運賃を算出する。また、運賃算出部２３８は、算出した運賃に予め定められた係数などをかけることなどにより、人数ごとの運賃を算出することが出来る。

このように、運賃算出部２３８は、仮想始点生成部２３７が仮想始点を生成した場合に、仮想始点を用いた場合の運賃を算出する。運賃算出部２３８は、行先・運賃情報２２１などを参照して、運賃を算出するよう構成しても構わない。

本実施形態においては、原則として、画面表示装置３００の設置場所にタクシーなどの移動手段を向かわせる場合について説明した。つまり、移動手段の始点は原則として画面表示装置３００の設置場所である。管理装置２００が仮想始点生成部２３７と運賃算出部２３８とを有することで、タクシーを向かわせる場所（つまり、始点）を変更することが可能となる。また、仮想始点生成部２３７が仮想始点を生成するか否か判断することで、始点が過度に変更されることを防ぐことが出来る。

［第２の実施形態］
次に、本発明の第２の実施形態について、図１６、図１７を参照して説明する。図１６は、シェアリングシステム７００の全体の構成の一例を示すブロック図である。図１７は、管理装置２００の構成の一例を示すブロック図である。

本発明の第２の実施形態においては、お弁当の手配をシェアするシステムであるシェアリングシステム７００について説明する。第１の実施形態においては、移動手段の手配をシェアするシェアリングシステム１００について説明した。しかしながら、本発明は、移動手段をシェアする以外のシェアリングシステムにも適用可能である。そこで、第２の実施形態においては、移動手段の手配（サービスの手配）以外のシェアの一例として、商品の手配の一例であるお弁当の手配をシェアする場合について説明する。

図１６は、シェアリングシステム７００の全体の構成の一例を示している。図１６を参照すると、シェアリングシステム７００は、例えば、管理装置２００と、画面表示装置３００と、業者端末４００と、の他に、認証端末６００を有している。図１６で示すように、管理装置２００と認証端末６００とは、互いに通信可能なよう接続されている。

シェアリングシステム７００の場合、画面表示装置３００は、例えば、パブリックビューイングなどのイベント会場、オフィスや介護施設など、に設置することが想定される。画面表示装置３００は、集合住宅など上記例示した場所以外に設置しても構わない。

認証端末６００は、ユーザの認証を行う。認証端末６００は、例えば、社員証などのカードに含まれる認証情報や、監視カメラなどが撮影した顔画像などに基づいて、ユーザが予め登録されているか否かを確認する認証を行う。そして、認証端末６００は、ユーザが予め登録されている場合、認証の結果を管理装置２００に対して送信する。

図１７は、シェアリングシステム７００における管理装置２００の構成の一例を示している。図１７を参照すると、管理装置２００は、第１の実施形態で説明した構成の他に、認証受付部２３９を有している。また、管理装置２００の記憶部２２０は、行先・運賃情報２２１の代わりに、商品・価格情報２２７を有している。

商品・価格情報２２７は、第１の実施形態で説明した行先・運賃情報２２１に相当する情報である。シェアリングシステム７００では、第１の実施形態で説明した移動手段のシェアではなく、お弁当などの商品の手配をシェアする。そのため、記憶部２２０は、行先と、人数と、運賃と、を対応づけた行先・運賃情報２２１の代わりに、商品・価格情報２２７を有している。例えば、商品・価格情報２２７では、商品と、注文数と、価格（料金）と、が対応づけられている。

認証受付部２３９は、認証端末６００から認証の結果を受け付ける。そして、認証受付部２３９は、認証されたユーザによる注文を受け付けるよう受付部２３２に指示する。これにより、受付部２３２は、ユーザによる注文を受け付けるようになる。認証受付部２３９が認証を受け付けていない場合、受付部２３２は、ユーザによる注文を受け付けない。

なお、認証受付部２３９は、認証の結果に応じて、予め記憶部２２０に格納されたユーザのクレジットカード情報などの支払い情報を取得するよう構成しても構わない。

例えば、以上のような構成により、シェアリングシステム７００を実現することが出来る。上述したような構成により、シェアリングシステム７００は、第１の実施形態と同様に、適切なタイミングまで注文の取りまとめを行うことが可能となる。その結果、商品手配のシェアを効率的に行うことが可能となる。また、本実施形態で説明した方法によると、発注待ちの商品の注文状況を画面表示装置３００に表示することが出来る。その際、例えば、後ｘｘ個の注文が集まればディスカウントされる、などのゲーム性のある情報も画面表示装置３００に表示させることで、例えば、より楽しみながら買い物を行うことが出来るようになる。

なお、シェアリングシステム７００には、第１の実施形態で説明した場合と同様に、様々な変形例を採用することが出来る。

また、お弁当の手配を行う場合、判断部２３３は、例えば、１０時３０分など予め定められた時刻になった場合に発注すると判断するよう構成しても構わない。また、判断部２３３は、例えば、お店の方向が同一となる複数のお店の注文をまとめた数が所定数を超えた場合に発注すると判断するよう構成しても構わない。このように、判断部２３３は、第１の実施形態で例示した以外の様々な条件に基づいて、発注すると判断することが出来る。

また、判断部２３３は、例えば、予め定められた所定の確率でお弁当の代金を割り引く、無料とする、など、費用面における判断を行うよう構成しても構わない。

なお、シェアリングシステム７００は、お弁当以外の商品の手配をシェアするよう構成しても構わない。例えば、シェアリングシステム７００は、各種特産品などの商品の手配をシェアするよう構成しても構わない。このように、シェアリングシステム７００では、様々な商品やサービスの手配をシェアするよう構成することが出来る。

［第３の実施形態］
次に、本発明の第３の実施形態について、図１８から図２０までを参照して説明する。図１８は、シェアリングシステム７１０の全体の構成の一例を示すブロック図である。図１９は、管理装置９００の構成の一例を示すブロック図である。図２０は、管理装置９００の他の構成例を示すブロック図である。

本発明の第３の実施形態においては、所定のエリア単位でお弁当、商品、移動手段の手配、配送などの注文を取りまとめるシェアリングシステム７１０について説明する。後述するように、本実施形態において説明するシェアリングシステム７１０は、複数の画面表示装置３００を有している。また、各画面表示装置３００は、ユーザから注文を受け付けると、受け付けた注文を示す情報を管理装置９００に対して送信する。そして、管理装置９００は、所定のエリア内に設置された画面表示装置３００が受け付けた注文をまとめて取りまとめる。

なお、注文を取りまとめるエリアは、例えば、同一町内、同一市内などであり、予め定められている。注文を取りまとめるエリアは、例えば、お弁当や商品などを各画面表示装置３００の設置場所に配送する際にかかる時間の合計である配送時間などに応じて定めても構わない。例えば、注文を取りまとめるエリアは、各画面表示装置３００の設置場所に商品などを配送する時間が所定時間（任意の値で構わない）以下になるように、定めることが出来る。なお、配送時間は、各画面表示装置３００の設置位置と、配送を行う配送業者の位置と、などに基づいて算出することが出来る。

図１８は、シェアリングシステム７１０の全体の構成の一例を示している。図１８を参照すると、シェアリングシステム７１０は、例えば、管理装置９００と、画面表示装置３００と、業者端末４００と、を含んでいる。図１８で示すように、管理装置９００と画面表示装置３００とは、ネットワークを介して互いに通信可能なよう接続されている。また、管理装置９００と業者端末４００とは、ネットワークを介して互いに通信可能なよう接続されている。

なお、図１８では図示していないが、シェアリングシステム７１０は、管理装置２００を有しても構わない。つまり、シェアリングシステム７１０では、画面表示装置３００と管理装置２００とを互いに通信可能なよう接続するとともに、管理装置２００と管理装置９００とを互いに通信可能なよう接続することが出来る。また、シェアリングシステム７１０が上記のような構成を有する場合、管理装置２００は、第１の実施形態や第２の実施形態で説明した構成のうちの一部の機能から構成されていても構わない。例えば、シェアリングシステム７１０が有する管理装置２００は、画面表示部２３１としての機能を有する装置であっても構わない。また、シェアリングシステム７１０が管理装置２００を有さない場合、画面表示装置３００が画面表示部２３１としての機能などを有していても構わない。なお、シェアリングシステム７１０は、認証端末６００など上記例示した以外の構成を有しても構わない。

画面表示装置３００は、第１の実施形態、第２の実施形態と同様に、デジタルサイネージ、電子看板などと呼ばれる表示装置である。画面表示装置３００は、例えば、商業施設、公共施設、オフィスや集合住宅の共用部、大学の構内など、人が集まる場所に設置されている。本実施形態の場合、画面表示装置３００は、ユーザからの注文を受け付けると、受け付けた注文を示す情報を管理装置９００に対して送信する。

業者端末４００は、第１の実施形態、第２の実施形態と同様に、業者に置かれた情報処理装置である。業者端末４００は、例えば、お弁当や商品の販売を行う業者、タクシーやバスなどの移動手段の手配・管理を行う業者、お弁当や商品の配送を行う業者、などの事業所などに設置されている。

管理装置９００は、エリア単位でユーザによる注文の取りまとめを行うなど、発注を管理する情報処理装置である。管理装置９００は、例えば、シェアリングシステム７１０を運営・管理する運営・管理会社に設置されている。図１９は、管理装置９００の構成の一例を示している。図１９を参照すると、管理装置９００は、主な構成要素として、例えば、通信Ｉ／Ｆ部９１０と、記憶部９２０と、演算処理部９３０と、を有している。

通信Ｉ／Ｆ部９１０は、データ通信回路からなる。通信Ｉ／Ｆ部９１０は、通信回線を介して接続された画面表示装置３００や業者端末４００などとの間で、データ通信を行う。

記憶部９２０は、ハードディスクやメモリなどの記憶装置である。記憶部９２０は、演算処理部９３０における各種処理に必要な処理情報やプログラム９２５を記憶する。プログラム９２５は、演算処理部９３０に読み込まれて実行されることにより各種処理部を実現する。プログラム９２５は、通信Ｉ／Ｆ部９１０などのデータ入出力機能を介して外部装置や記録媒体から予め読み込まれ、記憶部９２０に保存されている。記憶部９２０で記憶される主な情報としては、例えば、注文数・配送料情報９２１、発注待ち情報９２２、発注先情報９２３、発注元情報９２４、などがある。

注文数・配送料情報９２１は、第１の実施形態や第２の実施形態で説明した行先・運賃情報２２１や商品・価格情報２２７に相当する情報である。注文数・配送料情報９２１では、例えば、注文数と配送料とが対応づけられている。例えば、注文数・配送料情報９２１では、注文数が多くなるほど配送料が安くなるように上記対応付けがされている。注文数・配送料情報９２１は、例えば、予め定められて記憶部９２０に格納されている。

なお、注文数・配送料情報９２１では、商品ごとや商品の種類ごとに注文数と配送料とを対応付けても構わない。また、注文数・配送料情報９２１には、複数の配送業者の配送料を示す情報が含まれても構わない。

また、記憶部９２０には、注文数・配送料情報９２１の代わりに、または、注文数・配送料情報９２１とともに、行先・運賃情報２２１や商品・価格情報２２７などが格納されていても構わない。なお、商品・価格情報２２７は、例えば、注文数が多くなるほど商品の価格が安くなることを示す情報であることが出来る。

発注待ち情報９２２は、後述する判断部９３２により注文の取りまとめを行っている最中の注文状況を示す情報である。本実施形態の場合、発注待ち情報９２２には、エリア内の各画面表示装置３００において受け付けた注文の注文状況を示す情報が含まれている。例えば、発注待ち情報９２２では、発注待ち中の注文のうち最初の注文が行われた時刻を示す注文時刻と、発注待ちの人数（または、発注待ちの注文数や発注待ちの商品数など）と、が対応付けられている。発注待ち情報９２２では、注文を受け付けた画面表示装置３００を判別可能なように、上記対応付けを行っても構わない。なお、本実施形態の場合、管理装置９００から各画面表示装置３００に対して送信される情報などにより、各画面表示装置３００における注文状況の同期を行うことが出来る。そのため、発注待ち情報９２２に含まれる注文時刻は、例えば、最初に注文を受け付けた画面表示装置３００における最初の注文の時刻を示している。また、発注待ちの人数は、各画面表示装置３００において受け付けた注文数の例えば合計を示している。

発注先情報９２３は、例えば、発注先情報２２３などと同様の情報であり、注文の送信先を示している。発注先情報９２３では、お弁当や商品ごと、お弁当や商品の種類ごとに、発注先情報が対応づけられていても構わない。

なお、発注先情報９２３には、注文の送信先を示す情報のほかに、お弁当や商品の配送を行う配送会社の情報が含まれていても構わない。

発注元情報９２４は、例えば、発注元情報２２４などと同様の情報であり、各画面表示装置３００が置かれた場所の住所などを示している。例えば、発注元情報９２４では、画面表示装置３００を識別するための識別情報と、画面表示装置３００の住所を示す情報などと、が対応づけられている。

演算処理部９３０は、ＭＰＵなどのマイクロプロセッサとその周辺回路を有する。演算処理部９３０は、記憶部９２０からプログラム９２５を読み込んで実行することにより、上記ハードウェアとプログラム９２５とを協働させて各種処理部を実現する。演算処理部９３０で実現される主な処理部として、例えば、管理部９３１と、判断部９３２と、送信部９３３と、がある。演算処理部９３０は、第２の実施形態で説明した認証受付部２３９など上記例示した以外の構成を有しても構わない。

管理部９３１は、各画面表示装置３００から受信した情報に基づいて、注文待ちの状況などを管理する。例えば、管理部９３１は、画面表示装置３００から、当該画面表示装置３００が受け付けた注文を示す情報を取得する。例えば、管理部９３１は、画面表示装置３００から、画面表示装置３００を識別するための識別情報と、画面表示装置３００が受け付けた注文を示す情報と、を取得する。そして、管理部９３１は、受け付けた情報に基づいて、発注待ち情報９２２を更新する。

また、管理部９３１は、画面表示装置３００から注文を示す情報を取得した場合、注文を示す情報を取得した旨を他の画面表示装置３００に対して送信することが出来る。これにより、各画面表示装置３００において注文状況の同期を行うことができ、他の画面表示装置３００で受け付けた注文も含む注文状況を画面表示することが出来る。

判断部９３２は、第１の実施形態で説明した判断部２３３と同様に、発注待ち情報９２２が示す注文状況などに基づいて、発注するか否かなどを判断する。例えば、判断部９３２は、発注待ち情報２２２が示す注文状況と、経過時間閾値と、人数閾値と、に基づいて、発注するか否か判断する。判断部９３２は、人数閾値の代わりに、または、人数閾値とともに、注文数の上限を示す注文数閾値を用いて発注するか否か判断しても構わない。なお、判断部９３２による具体的な判断方法は、第１の実施形態で説明した判断部２３３などと同様で構わない。また、判断部９３２は、注文数・配送料情報９２１や商品・価格情報２２７などを参照して、発注した際の人数に基づいて、配送料や商品の価格などを決定することが出来る。

送信部９３３は、判断部９３２による発注の判断に応じて、お弁当や商品の販売を行う業者に設置された業者端末４００に対して、注文するお弁当や商品などを示す情報が含まれる発注情報を送信する。また、送信部９３３は、商品などの配送を行う業者に設置された業者端末４００に対して、商品などの販売を行う業者の位置を示す情報と、画面表示装置３００の設置場所など配送先の位置を示す情報と、を含む発注情報を送信することが出来る。

また、送信部９３３は、発注の後、発注した旨を示す情報を各画面表示装置３００に対して送信することが出来る。

このように、シェアリングシステム７１０は、管理装置９００を有している。このような構成によると、管理装置９００は、所定のエリア内に設置された画面表示装置３００が受け付けた注文をまとめて取りまとめることが出来る。その結果、例えば、１箇所の画面表示装置３００だけでは十分な注文が集まらない状況などでも、十分な注文を集めることなどが可能となる。これにより、より多くの注文を集めることが可能となり、例えば、仕入れコストや配送コストなどを下げることが可能となる。

なお、本実施形態では、管理装置９００が予め定められたエリア内の画面表示装置３００が受け付けた注文をまとめて取りまとめる場合について説明した。しかしながら、注文をまとめて取りまとめる対象は、例えば、エリア内の画面表示装置３００の中から動的に絞り込むなど、可変であっても構わない。例えば、図２０で示すように、管理装置９００の演算処理部９３０は、記憶部９２０に格納されたプログラムを実行することで、選択部９３４としての機能を実現することが出来る。

選択部９３４は、注文数、最初の注文からの経過時間、注文数の増え具合などの注文状況に応じて、エリア内に属する複数の画面表示装置３００のうち注文を取りまとめる画面表示装置３００を選択、絞り込むことが出来る。例えば、選択部９３４は、注文数や注文数の増え方などに基づいて、より少ない画面表示装置３００が受け付ける注文でも注文数が注文数閾値に達すると判断される場合、注文をまとめて取りまとめる画面表示装置３００を選択、絞り込むことが出来る。選択部９３４は、上記例示した以外にまとめて取りまとめる画面表示装置３００の選択、絞り込みを行っても構わない。

このように、選択部９３４を用いて、まとめて取りまとめる画面表示装置３００を選択、絞り込むことで、配送にかかる時間などをより絞りこむことが可能となる。なお、選択部９３４によりまとめて取りまとめる画面表示装置３００を選択、絞り込むか否かは、例えば、商品などの注文対象の性格やシェアリングシステム７１０を利用する目的などに応じて判断しても構わない。例えば、買い物代行などの目的でシェアリングシステム７１０を利用する場合、配送時間よりも配送コストなどのコストが優先されることが想定される。そのため、選択部９３４による絞り込みを行わない。一方、お弁当の手配などの目的でシェアリングシステム７１０を利用する場合、配送時間がより短い方が好ましい。そのため、選択部９３４を用いた絞り込みを行う。例えば、以上のように、選択部９３４による絞り込みを行うか否かは、商品の性格やシェアリングシステム７１０を利用する目的などに応じて判断するよう構成しても構わない。

なお、図１９、図２０では、１台の情報処理装置を用いて管理装置９００としての機能を実現する場合について例示した。しかしながら、管理装置９００としての機能は、ネットワークを介して接続された複数台の情報処理装置を用いて実現されても構わない。例えば、管理装置９００としての機能は、クラウドコンピューティングなどを利用して実現されても構わない。

［第４の実施形態］
次に、本発明の第４の実施形態について、図２１を参照して説明する。図２１は、画面表示装置３００の他の構成例を示している。

本発明の第４の実施形態においては、各実施形態において説明したデジタルサイネージである画面表示装置３００の他の構成例について説明する。図２１を参照すると、画面表示装置３００は、例えば、記憶装置に格納されたプログラムを演算装置が実行することで、タッチパネル３１０と送受信部３２０とに加えて、配信部３３０としての機能を有することが出来る。

配信部３３０は、ビーコンを用いることで、デジタルサイネージである画面表示装置３００の周辺に存在するユーザに対して、所定の情報を送信する。本実施形態の場合、例えば、配信部３３０は、発注待ちの商品についての値引き額などの情報や、移動手段の手配や商品などの注文を行うための注文画面へとユーザを誘導するための情報を、画面表示装置３００の周辺に存在するユーザに対して送信する。

例えば、以上のように、画面表示装置３００が配信部３３０としての機能を有することで、ユーザの興味を引くことやユーザがより手軽に注文することなどが可能となる。

［第５の実施形態］
次に、図２２を参照して、本発明の第５の実施形態について説明する。第５の実施形態では、管理装置８０の構成の概要について説明する。

図２２は、管理装置８０の構成の一例を示している。図２２を参照すると、管理装置８０は、例えば、受付部８１と、発注部８２と、を有している。なお、上記各処理部は、例えば、管理装置８０が有するＣＰＵなどの演算装置が記憶装置に格納されたプログラムを実行することで実現される。

受付部８１は、ユーザからの注文を受け付ける。

発注部８２は、注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する。

このように、管理装置８０は、受付部８１と発注部８２とを有している。このような構成により、発注部８２は、受付部８１が受け付けた注文を、注文の状況を示す注文状況が所定の条件を満たすまで取りまとめたのち、外部端末に対して発注することが出来る。その結果、適切なタイミングで発注することが可能となり、効率的なサービスの提供を行うことが可能となる。

また、上述した管理装置８０は、当該管理装置８０に所定のプログラムが組み込まれることで実現できる。具体的に、本発明の他の形態であるプログラムは、管理装置８０に、
ユーザからの注文を受け付ける受付部８１と、注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部８２と、を実現するためのプログラムである。

また、上述した管理装置８０により実行される管理方法は、管理装置８０が、ユーザからの注文を受け付け、注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する、という方法である。

上述した構成を有する、プログラム（記録媒体）、又は、管理方法、の発明であっても、上記管理装置８０と同様の作用・効果を有するために、上述した本発明の目的を達成することが出来る。

＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明における管理方法などの概略を説明する。但し、本発明は、以下の構成に限定されない。

（付記１）
管理装置が、
ユーザからの注文を受け付け、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する
管理方法。
（付記２）
付記１に記載の管理方法であって、
所定のタイミングからの経過時間と、発注前の注文した人数である発注待ちの人数と、に基づいて、前記外部端末に対して発注するか否か判断する
管理方法。
（付記３）
付記２に記載の管理方法であって、
注文からの経過時間が経過時間閾値を超える場合、発注すると判断する
管理方法。
（付記４）
付記２または付記３に記載の管理方法であって、
発注待ちの人数が人数閾値以上となる場合、発注すると判断する
管理方法。
（付記５）
付記１から付記４までのいずれか１項に記載の管理方法であって、
予め定められた商品またはサービスの注文を受け付け、
前記商品または前記サービスごとに注文の取りまとめを行う
管理方法。
（付記６）
付記５に記載の管理方法であって、
前記商品または前記サービスと発注する際の人数ごとに、予め料金が定められている
管理方法。
（付記７）
付記５または付記６に記載の管理方法であって、
前記商品または前記サービスごとに、注文からの経過時間に応じた情報と、発注待ちの人数に応じた情報を画面表示させる
管理方法。
（付記８）
付記７に記載の管理方法であって、
前記商品または前記サービスごとに、注文からの経過時間に応じた情報と、発注待ちの人数に応じた情報と広告を画面に表示させる
管理方法。
（付記９）
付記１から付記８までのいずれか１項に記載の管理方法であって、
発注先となる前記外部端末を選択し、
選択した前記外部端末に対して発注する
管理方法。
（付記１０）
付記９に記載の管理方法であって、
発注待ちの人数を示す情報に基づいて、前記外部端末を選択する
管理方法。
（付記１１）
付記１から付記１０までのいずれか１項に記載の管理方法であって、
複数の画面表示装置から注文を受け付け、
注文の状況を示す注文状況が所定の条件を満たすまで注文をまとめて取りまとめたのち、外部端末に対して発注する
管理方法。
（付記１２）
付記１１に記載の管理方法であって、
注文を受け付ける対象の画面表示装置が、商品を配送する際にかかる配送時間に基づいて定められている
管理方法。
（付記１３）
付記１１または付記１２に記載の管理方法であって、
注文状況に基づいて、まとめて取りまとめる対象となる画面表示装置を選択する
管理方法。
（付記１４）
付記１３に記載の管理方法であって、
注文対象の性格に基づいて、まとめて取りまとめる対象となる画面表示装置を選択するか否か判断する
管理方法。
（付記１５）
ユーザからの注文を受け付ける受付部と、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部
を有する
管理装置。
（付記１６）
管理装置に、
ユーザからの注文を受け付ける受付部と、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部
を実現するためのプログラム。
（付記１７）
デジタルサイネージを利用して移動手段のシェアを行うシェアリングシステムであって、
ユーザから、予め定められた行先への移動手段の手配を希望する旨を示す注文を受け付ける受付部と、
前記行先ごとに、注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち、外部端末に対して発注する発注部と、
を有する
シェアリングシステム。
（付記１８）
デジタルサイネージを利用して移動手段のシェアを行うシェアリングシステムにおいてユーザの注文を管理する管理装置が、
ユーザからの注文を受け付け、
注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する
管理方法。

なお、上記各実施形態及び付記において記載したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されていたりする。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。

以上、上記各実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることが出来る。例えば、第１の実施形態で説明したシェアリングシステム１００が認証端末６００を有するなど、第１の実施形態から第５の実施形態までのいずれかで説明した内容を組み合わせても構わない。

なお、本発明は、日本国にて２０１９年１１月２５日に特許出願された特願２０１９－２１２１０５の特許出願に基づく優先権主張の利益、２０２０年６月２６日に特許出願された特願２０２０－１１０１３７の特許出願に基づく優先権主張の利益を享受するものであり、当該特許出願に記載された内容は、全て本明細書に含まれるものとする。

１００ シェアリングシステム
２００ 管理装置
２１０ 通信Ｉ／Ｆ部
２２０ 記憶部
２２１ 行先・運賃情報
２２２ 発注待ち情報
２２３ 発注先情報
２２４ 発注元情報
２２５ プログラム
２２６ 駐車場情報
２２７ 商品・価格情報
２３０ 演算処理部
２３１ 画面表示部
２３２ 受付部
２３３ 判断部
２３４ 送信部
２３５ 注文まとめ部
２３６ 駐車場状況取得部
２３７ 仮想始点生成部
２３８ 運賃算出部
２３９ 認証受付部
３００ 画面表示装置
３１０ タッチパネル
３２０ 送受信部
４００ 業者端末
５００ 端末
５１０ 行先指定部
５２０ 位置情報取得部
５３０ 送受信部
６００ 認証端末
７００ シェアリングシステム
８０ 管理装置
８１ 受付部
８２ 発注部
７１０ シェアリングシステム
９００ 管理装置
９１０ 通信Ｉ／Ｆ部
９２０ 記憶部
９２１ 注文数・配送料情報
９２２ 発注待ち情報
９２３ 発注先情報
９２４ 発注元情報
９２５ プログラム
９３０ 演算処理部
９３１ 管理部
９３２ 判断部
９３３ 送信部
９３４ 選択部
３３０ 配信部

Claims (8)

1. 管理装置が、
   ユーザからの注文を受け付け、
   注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注し、
   複数の画面表示装置から注文を受け付け、
   注文の状況を示す注文状況が所定の条件を満たすまで注文をまとめて取りまとめたのち、外部端末に対して発注し、
   注文状況に基づいて、まとめて取りまとめる対象となる画面表示装置を選択する
   管理方法。
2. 請求項１に記載の管理方法であって、
   所定のタイミングからの経過時間と、発注前の注文した人数である発注待ちの人数と、に基づいて、前記外部端末に対して発注するか否か判断する
   管理方法。
3. 請求項２に記載の管理方法であって、
   注文からの経過時間が経過時間閾値を超える場合、発注すると判断する
   管理方法。
4. 請求項２または請求項３に記載の管理方法であって、
   発注待ちの人数が人数閾値以上となる場合、発注すると判断する
   管理方法。
5. 請求項１から請求項４までのいずれか１項に記載の管理方法であって、
   予め定められた商品またはサービスの注文を受け付け、
   前記商品または前記サービスごとに注文の取りまとめを行う
   管理方法。
6. 請求項１から請求項５までのいずれか１項に記載の管理方法であって、
   発注先となる前記外部端末を選択し、
   選択した前記外部端末に対して発注する
   管理方法。
7. ユーザからの注文を受け付ける受付部と、
   注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部と、
   を有し、
   前記受付部は、複数の画面表示装置から注文を受け付け、
   前記発注部は、注文の状況を示す注文状況が所定の条件を満たすまで注文をまとめて取りまとめたのち、外部端末に対して発注し、
   注文状況に基づいて、まとめて取りまとめる対象となる画面表示装置を選択する選択部を有する
   管理装置。
8. 管理装置に、
   ユーザからの注文を受け付ける受付部と、
   注文の状況を示す注文状況が所定の条件を満たすまで注文を取りまとめたのち外部端末に対して発注する発注部と、
   を実現させ、
   前記受付部は、複数の画面表示装置から注文を受け付け、
   前記発注部は、注文の状況を示す注文状況が所定の条件を満たすまで注文をまとめて取りまとめたのち、外部端末に対して発注し、
   注文状況に基づいて、まとめて取りまとめる対象となる画面表示装置を選択する選択部を実現させるプログラム。

Images