JP2020173663A - 管理装置、管理方法および管理プログラム - Google Patents

Abstract

【課題】荷物の集配の依頼者や荷受用車両の提供者に予定変更が生じた場合に適切に対応することができる管理装置、管理方法および管理プログラムを提供する。【解決手段】集配システム１において、管理装置２は、荷物の配送の依頼者に対応付けられた依頼者端末または所定の領域内に駐停車している車両であって車室をその荷物の集配先として提供している車両の提供者に対応付けられた提供者端末から予定変更要求を受信した場合、集配対象の荷物に関する情報に基づいて予定変更の可否を判定し、判定結果を予定変更要求の送信元端末に送信する。【選択図】図２

Description

本発明は、管理装置、管理方法および管理プログラムに関する。

宅配業者が荷物を集配する際に、あらかじめ荷受用車両として登録された一般の乗用車のトランクを配達物の受け渡し場所として利用する技術が知られている（例えば、特許文献１を参照）。この技術では、荷物の集配を行う際に、集配事業者の集配用通信装置と指定車両に搭載された車両用通信装置との間で認証処理を行わせ、その認証に成功した場合、指定車両のトランクの施錠や解錠が可能となる。

特開２００６−２０６２２５号公報

しかしながら、上述した特許文献１の技術では、荷物の集配の依頼者や荷受用車両の提供者に予定変更が生じた場合にどう対応すべきかが考慮されていなかった。

本発明は、上記に鑑みてなされたものであって、荷物の集配の依頼者や荷受用車両の提供者に予定変更が生じた場合に適切に対応することができる管理装置、管理方法および管理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る管理装置は、メモリと、ハードウェアを有するプロセッサと、を備え、前記プロセッサは、荷物の配送の依頼者に対応付けられた依頼者端末または所定の領域内に駐停車している車両であって車室を前記荷物の集配先として提供する車両の提供者に対応付けられた提供者端末から予定変更要求を受信した場合、前記荷物に関する情報に基づいて予定変更の可否を判定し、判定結果を前記予定変更要求の送信元端末に送信する。

また、前記プロセッサは、前記提供者端末および前記依頼者端末の一方の端末から予定変更要求を受信した場合、他方の端末に予定変更可否の問合せを送信し、前記他方の端末から受信した前記問合せの回答をさらに用いて予定変更の可否を判定してもよい。

これによれば、依頼元ではない提供者または依頼者の意向もふまえて予定変更の可否を判定するため、よりきめ細かいサービスを提供することができる。

また、前記プロセッサは、前記荷物に関する情報および前記領域内で車室を他者の荷物の荷受用として提供可能な複数の車両の駐停車に関する情報を含む駐停車情報に基づいて前記荷物の移管候補の車両を選択し、選択した移管候補の車両の提供者に対応付けられた候補者端末に対して移管の可否を問い合わせ、前記候補者端末から移管を受託する回答を受信した場合、前記予定変更が可能と判定してもよい。

これによれば、所定の領域に駐停車する複数の荷受用車両が登録されている場合において、予定変更要求に応じて荷物の移管を行うことができるため、所定の領域内で荷受用に登録された車両を有効に活用して、依頼者または提供者の予定変更要求にも適切に対応することができる。

また、前記プロセッサは、前記複数の車両の提供者がそれぞれ登録したスケジュール情報をさらに参照して、前記移管候補の車両を選択してもよい。

これによれば、車両の提供者のスケジュールに応じて適切な車両を選択し、車両不在に起因する移管のミスを防止することができる。

また、前記メモリは、過去の移管の履歴情報を記憶し、前記プロセッサは、前記履歴情報をさらに参照して前記移管候補の車両を選択してもよい。

これによれば、過去の履歴情報をふまえて効率的に移管候補の車両を選択することができる。

また、前記プロセッサは、前記荷物の種類に応じて前記移管候補の車両を選択してもよい。

これによれば、荷物の種類に応じて適切な車両を選択することができる。

また、前記プロセッサは、前記候補者端末から移管受託通知を受信した場合、前記移管候補の車両の情報を含む移管指示を、前記荷物の集配者に対応付けられた集配者端末に送信してもよい。

これによれば、集配者端末に移管指示を送信することによって集配者に移管情報を確実に伝達することができる。

本発明に係る管理方法は、メモリと、ハードウェアを有するプロセッサとを備える管理装置が実行する管理方法であって、荷物の配送の依頼者に対応付けられた依頼者端末または所定の領域内に駐停車している車両であって車室を前記荷物の集配先として提供している車両の提供者に対応付けられた提供者端末から予定変更要求を受信した場合、前記荷物に関する情報をメモリから読み出して予定変更の可否を判定し、判定結果を前記予定変更要求の送信元端末に送信する。

本発明に係る管理プログラムは、メモリと、ハードウェアを有するプロセッサとを備える管理装置に実行させる管理プログラムであって、荷物の配送の依頼者に対応付けられた依頼者端末または所定の領域内に駐停車している車両であって車室を前記荷物の集配先として提供している車両の提供者に対応付けられた提供者端末から予定変更要求を受信した場合、前記荷物に関する情報に基づいて予定変更の可否を判定し、判定結果を前記予定変更要求の送信元端末に送信する。

本発明によれば、集配対象の荷物の配送の依頼者に対応付けられた依頼者端末またはその荷物の集配先として提供する車両の提供者に対応付けられた提供者端末から予定変更要求を受信した場合、その荷物に関する情報に基づいて予定変更の可否を判定して判定結果を予定変更要求の送信元端末に送信し、予定変更の可否を含む情報を予定変更の要求者に的確に伝えるため、荷物の集配の依頼者や荷受用車両の提供者に予定変更が生じた場合に適切に対応することができる。

図１は、実施の形態１に係る管理装置を備えた集配システムの概要を示す図である。 図２は、実施の形態１に係る管理装置を備えた集配システムの機能構成を示すブロック図である。 図３は、実施の形態１に係る管理装置が記憶する荷物情報を模式的に示す図である。 図４は、実施の形態１に係る管理装置を備えた集配システムが行う処理の概要を示すシーケンス図である。 図５は、実施の形態１の変形例に係る管理装置を備えた集配システムが行う処理の概要を示すシーケンス図である。 図６は、実施の形態２に係る管理装置を備えた集配システムの機能構成を示す図である。 図７は、実施の形態２に係る管理装置が記憶する駐停車情報を模式的に示す図である。 図８は、実施の形態２に係る管理装置を備えた集配システムが行う処理（第１例）の概要を示すシーケンス図である。 図９は、実施の形態２に係る管理装置が記憶する更新後の駐停車情報（第１例）を模式的に示す図である。 図１０は、実施の形態２に係る管理装置を備えた集配システムが行う別な処理（第２例）の概要を示すシーケンス図である。 図１１は、実施の形態２に係る管理装置が記憶する更新後の駐停車情報（第２例）を模式的に示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、「実施の形態」という）を説明する。

（実施の形態１）
図１は、実施の形態１に係る管理装置を備えた集配システムの概要を示す図である。同図に示す集配システム１は、所定の領域内で駐停車し、あらかじめ荷受用車両として登録された車両１１の車室を利用することによって荷物の集配を行うシステムである。車両１１の車室とは、車両１１のトランクや乗車スペースを含む。また、領域は、例えば車両１１が駐車する駐車場などの閉じた領域であるが、これに限定されるわけではない。

集配システム１は、荷物の集配を管理する管理装置２と、車両１１の車室の開閉を管理するセンタサーバ３と、集配者に対応付けられた集配者端末４と、車両１１に搭載された車載装置５と、荷物の集配の依頼者に対応付けられた依頼者端末６と、車両１１を所有し、車室を荷受用として提供する提供者に対応付けられた提供者端末７とを備える。管理装置２、センタサーバ３、集配者端末４、車載装置５、依頼者端末６、および提供者端末７は、通信ネットワークＮＷに通信接続されている。また、集配者端末４、依頼者端末６および提供者端末７は、近距離無線通信によって車載装置５とそれぞれ通信可能に接続されている。通信ネットワークＮＷは、例えばＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、公衆回線、ＶＰＮ（Virtual Private Network）、専用線などの一または複数の組み合わせからなる。通信ネットワークＮＷは、有線通信によるネットワークと無線通信によるネットワークとの組み合わせによって構成される。また、近距離無線通信規格として、例えばＢＬＥ（Bluetooth（登録商標） Low Energy）、ＮＦＣ（Near Field Communication）、ＵＷＢ（Ultra Wideband）、ＷｉＦｉ（登録商標）等を挙げることができる。

図２は、集配システム１の機能構成を示すブロック図である。以下、集配システム１の構成要素ごとに機能構成を説明する。

＜管理装置２＞
管理装置２は、通信部２１と、制御部２２と、記憶部２３とを有する。

通信部２１は、通信ネットワークＮＷを介してセンタサーバ３、集配者端末４、依頼者端末６、および提供者端末７と通信を行うインタフェースである。

制御部２２は、判定部２４を有する。判定部２４は、荷物の配送の依頼者に対応付けられた依頼者端末６または車両１１の提供者に対応付けられた提供者端末７から予定変更要求を受信した場合、集配対象の荷物に関する情報に基づいて予定変更の可否を判定し、判定結果を予定変更要求の送信元端末に送信する。

制御部２２は、例えばＣＰＵ（Central Processing Unit）等の汎用プロセッサや、ＦＰＧＡ（Field Programmable Gate Array）等の特定の機能を実行する専用集積回路等のハードウェアを単独でまたは組み合わせることによって構成されるプロセッサである。制御部２２は、記憶部２３が記憶する各種プログラムを読み込むことによって管理装置２を動作させるための各種演算処理を実行する。

記憶部２３は、集配対象の荷物に関する情報（以下、荷物情報という）を記憶する。図３は、記憶部２３が記憶する荷物情報を模式的に示す図である。同図に示すテーブル１００には、荷物ＩＤ、荷物の種類、集配車両ＩＤ、駐停車位置ＩＤ、駐停車状態、荷物収納状態、荷物の配送予定、荷物の受取予定、車両１１の出発および到着予定が車両ごとに記載されている。駐停車状態は、車載装置５から送られてくる位置情報に基づいて更新される。また、配送予定および受取予定は依頼者端末６から送られてくる情報に基づいて登録される。また、出発および到着予定は、提供者端末７から送られてくるスケジュール情報に基づいて登録される。例えば、荷物ＩＤ００１の荷物の種類は衣類であり、車両ＩＤ１５２の車両１１（以下、車両１５２という）の車室に配送される。この車両１５２は、駐停車位置ＩＤがＡ３２１４の位置に駐停車しており、現在車室に荷物が収納されている。車両１５２における荷物の受取予定は、２０１９年３月３０日１８：００である。また、車両１５２は、２０１９年３月３１日９：００に駐停車位置を出発し、同日の１９：３０に駐停車位置に到着する予定である。なお、駐停車情報を記憶部２３が記憶する代わりに、管理装置２とは異なる装置が記憶してもよい。

記憶部２３は、管理装置２の動作を実行するための各種プログラムをさらに記憶する。各種プログラムには、管理装置２が依頼者端末６または提供者端末７から予定変更要求を受信した場合、予定変更の可否を判定し、判定結果を予定変更要求の送信元端末に送信する管理プログラムも含まれる。

記憶部２３は、ＲＡＭ（Random Access Memory）等の揮発性メモリおよびＲＯＭ（Read Only Memory）等の不揮発性メモリを用いて構成される。なお、外部から装着可能なメモリカード等のコンピュータ読み取り可能な記録媒体を用いて記憶部２３を構成してもよい。記憶部２３が記憶する各種プログラムは、ハードディスク、フラッシュメモリ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、フレキシブルディスク等のコンピュータ読み取り可能な記録媒体に記録して広く流通させることも可能である。

＜センタサーバ３＞
センタサーバ３は、複数の車両１１の認証情報を管理する認証管理装置である。センタサーバ３は、通信部３１と、制御部３２と、記憶部３３とを有する。

通信部３１は、通信ネットワークＮＷを介して管理装置２と通信を行うインタフェースである。

制御部３２は、認証情報発行部３４を有する。認証情報発行部３４は、車両１１を施錠または解錠するための認証情報を発行する。認証情報発行部３４は、集配者端末４または依頼者端末６から管理装置２を介して、車両１１を施錠または解錠するための認証情報の発行要求を受信すると、キーユニット５２に対応する認証情報を、管理装置２を介して集配者端末４または依頼者端末６に送信する。認証情報発行部３４は、有効期間の情報を含む認証情報を生成してもよい。

制御部３２は、例えばＣＰＵやＦＰＧＡ等のハードウェアを単独でまたは組み合わせることによって構成されるプロセッサである。制御部３２は、記憶部３３が記憶する各種プログラムを読み込むことによってセンタサーバ３を動作させるための各種演算処理を実行する。

記憶部３３は、認証情報発行部３４が認証情報を発行する際に必要となる情報や、センタサーバ３の動作を実行するための各種プログラムを記憶する。記憶部３３は、ＲＡＭおよびＲＯＭ等を用いて構成される。

＜集配者端末４＞
集配者端末４は、通信部４１と、近距離通信部４２と、入力部４３と、出力部４４と、制御部４５と、記憶部４６と、を有する。集配者端末４は、荷物の集配者に対応付けられた端末であり、集配者が携帯している端末である。集配者端末４は、例えばスマートフォン、携帯電話、タブレット端末、個人情報端末、ウェアラブルコンピュータ等を用いて構成される。

通信部４１は、通信ネットワークＮＷを介して少なくとも管理装置２と通信を行うインタフェースである。

近距離通信部４２は、車載装置５と近距離無線通信を行うインタフェースである。近距離通信部４２は、上述したＢＬＥ、ＮＦＣ、ＵＷＢ、ＷｉＦｉ（登録商標）等のいずれかの規格に基づいた近距離無線通信を行う。

入力部４３は、キーボード、ボタン、レバー、出力部４４を構成するディスプレイに積層して設けられるタッチパネル、および音声入力用のマイクロフォン等のユーザインターフェースを用いて構成され、各種情報の入力を受け付ける。

出力部４４は、液晶または有機ＥＬ（Electro Luminescense）等を用いて構成される表示用のディスプレイ、音声出力用のスピーカ等を用いて構成される。

制御部４５は、集配者端末４の動作を制御する。制御部４５は、例えばＣＰＵやＦＰＧＡ等のハードウェアを単独でまたは組み合わせることによって構成されるプロセッサである。制御部４５は、記憶部４６が記憶する各種プログラムを読み込むことによって集配者端末４を動作させるための各種演算処理を実行する。

記憶部４６は、集配者端末４の動作を実行するための各種プログラムを記憶する。記憶部４６は、ＲＡＭおよびＲＯＭ等を用いて構成される。

なお、集配者端末４が、ＣＣＤまたはＣＭＯＳ等のイメージセンサを用いて構成される撮像部をさらに有してもよい。この場合には、集配者が集配者端末４を用いて車室の状態を撮像し、撮像した画像のデータを管理装置２へ送信する。管理装置２は、受信した画像のデータをもとに画像認識によって車室の空き状況を把握する。

また、集配者端末４がダウンロード可能なアプリとして、車両１１の駐停車情報を表示するアプリを提供してもよい。

＜車載装置５＞
車載装置５は、車両１１に搭載されている。車載装置５は、施解錠装置５１と、キーユニット５２と、制御装置５３とを有する。車載装置５は、集配者端末４、依頼者端末６または提供者端末７から受信した認証情報をもとに、キーユニット５２による認証処理を経て施解錠装置５１を作動させることにより、車両１１の車室を施錠または解錠する一連の処理を実行する。また、車載装置５は、制御装置５３が車両１１の位置や移動状態を検出し、検出した情報を通信ネットワークＮＷを介して管理装置２へ送信する。集配者端末４および依頼者端末６によって送信される認証情報には有効期限が設定されている。換言すれば、集配者端末４および依頼者端末６は、荷物の集配のたびに認証情報をセンタサーバ３から取得する必要がある。これに対し、提供者端末７は、期限設定のないマスタ認証情報を記憶している。

施解錠装置５１は、車両１１の車室のドアを施錠または解錠するための装置である。施解錠装置５１は、ＬＦ送信機５１１と、ＲＦ受信機５１２と、制御部５１３と、ドアロックアクチュエータ５１４と、記憶部５１５とを有する。なお、図２では、ドアロックアクチュエータを「ドアロックＡ」と記載している。

ＬＦ送信機５１１は、キーユニット５２を検索（ポーリング）するための低周波数帯（例えば、１００ＫＨｚ〜３００ＫＨｚ）の電波を送信する。ＬＦ送信機５１１は、例えば、車室内のセンターコンソールやハンドルの近傍に内蔵される。

ＲＦ受信機５１２は、キーユニット５２から送信された高周波数帯（例えば、１００ＭＨｚ〜１ＧＨｚ）の電波を受信する。ＲＦ受信機５１２は、車室内のいずれかの場所に内蔵される。

制御部５１３は、キーユニット５２から受信した施解錠信号に含まれるキーＩＤと、記憶部５１５が記憶するキーＩＤとを照合する。照合の結果、受信したキーＩＤを正当なものであると判定した場合、制御部５１３は、ドアロックアクチュエータ５１４に対して車両１１の荷受用の車室のドアを施錠または解錠する信号を送信する。

制御部５１３は、例えばＣＰＵやＦＰＧＡ等のハードウェアを単独でまたは組み合わせることによって構成される。制御部５１３を、ＣＡＮ（Controller Area Network）等の車内ネットワークを介して相互に通信可能に接続される複数のＥＣＵ（Electric Controll Unit）を用いて構成してもよい。以下の説明において、施錠信号と解錠信号を総称して施解錠信号ということがある。

ドアロックアクチュエータ５１４は、車両１１の車室のドアを施錠または解錠するアクチュエータである。ドアロックアクチュエータ５１４は、制御部５１３から送信された施解錠信号に基づいて動作する。なお、ドアロックアクチュエータ５１４は、車両１１のドアごとに独立して施解錠するようにしてもよい。例えば荷受用の車室としてトランクを使用する場合には、トランクのみを施解錠するようにしてもよい。

記憶部５１５は、車室のドアのキーＩＤを含む各種情報や施解錠装置５１を動作させるための各種プログラムを記憶する。記憶部５１５は、ＲＡＭおよびＲＯＭ等を用いて構成される。

キーユニット５２は、ＬＦ受信機５２１と、ＲＦ送信機５２２と、近距離通信部５２３と、制御部５２４と、記憶部５２５とを有する。キーユニット５２は、例えば車両１１の車室内のグローブボックス内等の所定の位置に配置される。

ＬＦ受信機５２１は、施解錠装置５１から、低周波数帯の電波を介して送信されたポーリング信号を受信する。ＬＦ受信機５２１は、低周波数帯の電波を受信するためのアンテナ（以下、ＬＦアンテナ）を有する。

ＲＦ送信機５２２は、高周波数帯の電波を介して、施解錠装置５１に対して施解錠信号を送信する。

近距離通信部５２３は、集配者端末４、依頼者端末６または提供者端末７と近距離無線通信を行う通信インタフェースである。

制御部５２４は、キーユニット５２の動作を制御する。制御部５２４は、集配者端末４、依頼者端末６または提供者端末７から受信した施錠要求または解錠要求に含まれる認証情報と、記憶部５２５が記憶する認証情報とを比較し、これらが所定の関係にある場合に、認証成功と判断する。ここでいう所定の関係とは、例えば記憶部５２５が記憶する認証情報と、集配者端末４、依頼者端末６または提供者端末７から受信した認証情報とが一致する関係、２つの認証情報を用いた所定の暗号化・複合化等の処理結果が一致する関係、２つの認証情報の一方に復号処理を行った結果が他方に一致する関係、のいずれかを含む。

制御部５２４が集配者端末４、依頼者端末６または提供者端末７の認証に成功した場合、制御部５２４は、ＲＦ送信機５２２を介して、集配者端末４、依頼者端末６または提供者端末７から受信した要求に応じて生成された施解錠信号を施解錠装置５１へ送信する。

制御部５２４は、例えばＣＰＵやＦＰＧＡ等のハードウェアを単独でまたは組み合わせることによって構成される。

記憶部５２５は、集配者端末４、依頼者端末６または提供者端末７を認証するための認証情報を記憶するとともに、キーＩＤを記憶する。なお、記憶部５２５は、キーＩＤを暗号化して記憶してもよい。記憶部５２５がキーＩＤを暗号化して記憶している場合には、制御部５２４が集配者端末４、依頼者端末６または提供者端末７から復号化の情報を受信し、この情報に基づいてキーＩＤを復号化する。

記憶部５２５は、キーユニット５２の動作を実行するための各種プログラムを記憶する。記憶部５２５は、ＲＡＭおよびＲＯＭ等を用いて構成される。以下、記憶部５２５が記憶する認証情報を装置認証情報といい、集配者端末４、依頼者端末６または提供者端末７が送信する認証情報を端末認証情報ということもある。

以上の構成を有するキーユニット５２は、車載装置５が有する施解錠装置５１と通信を行うことにより、物理的なキーを用いることなく車両１１の車室の施錠および解錠を行うことを可能にする。

制御装置５３は、通信部５３１と、位置検出部５３２と、速度検出部５３３と、入力部５３４と、出力部５３５と、制御部５３６と、記憶部５３７とを有する。

通信部５３１は、通信ネットワークＮＷを介して管理装置２と通信を行うインタフェースである。通信部５３１は、車両１１の位置情報および速度情報を管理装置２に送信する。

位置検出部５３２は、例えばＧＰＳ（Global Positioning System）衛星によって送信されるＧＰＳ信号を受信するＧＰＳセンサを用いて構成され、受信信号に基づいて車両１１の緯度、経度を含む車両１１の位置の情報を検出して制御部５３６に出力する。なお、位置検出部５３２が車両１１の位置情報を検出する方法として、ＬｉＤＡＲ（Light Detection and Ranging，Laser Imaging Detection and Ranging）と３次元デジタル地図とを組み合わせた方法を採用してもよい。

速度検出部５３３は、例えば車速センサ等を用いて構成され、車両１１の速度の情報を検出して制御部５３６に出力する。

なお、位置検出部５３２および速度検出部５３３は、３Ｇ、４Ｇ、５Ｇ、ＬＴＥ（Long Term Evolution）などの通信規格に従う移動体通信を行うことによって位置および速度の情報を検出するようにしてもよい。この場合には、例えば他の車両、走行中の道路周辺に設けられた各種センサ、およびこれらの車両や各種センサの情報を取得するサーバとの間で移動体通信を行うことによって、位置および速度の情報を検出してもよい。

入力部５３４および出力部５３５は、上述した入力部４３および出力部４４とそれぞれ同様の機能構成を有する。入力部５３４は、車両１１の提供者による車両１１のスケジュール情報の入力を受け付けることも可能である。ここでいう車両１１のスケジュール情報は、車両１１が領域を出発する日時と領域に到着する日時を含む。なお、スケジュール情報として、車両１１が領域に駐停車している状態の車室の使用可否に関する情報を含んでもよい。

制御部５３６は、制御装置５３の動作を制御する。制御部５３６は、例えばＣＰＵやＦＰＧＡ等のハードウェアを単独でまたは組み合わせることによって構成されるプロセッサであり、記憶部５３７が記憶する各種プログラムを読み込むことによって制御装置５３を動作させるための各種演算処理を実行する。

記憶部５３７は、位置検出部５３２および速度検出部５３３の検出結果や、制御装置５３の動作を実行するための各種プログラムを含む各種情報を記憶する。記憶部５３７は、ＲＡＭおよびＲＯＭ等を用いて構成される。

なお、車室の空き状況を確認するための手段として、車載装置５が車載カメラや重量センサをさらに備えてもよい。この場合、車載装置５は車載カメラが撮像した画像のデータを管理装置２へ送信する。管理装置２は、受信した画像のデータをもとに画像認識によって車室の空き状況を把握する。車載カメラは、車室のキーが解錠されている間だけ撮像するようにしてもよい。

また、車室に２次元コード等の記録媒体の情報を読み取り可能なリーダを設けておく一方、荷物の梱包材にリーダが読み取り可能な記録媒体を貼付しておき、荷物が車室内の所定位置に収納された場合にリーダが記録媒体の情報を読み取って車室内に収納されたことを管理装置２に送信するようにしてもよい。

＜依頼者端末６＞
依頼者端末６は、集配者端末４と同様の機能構成を有する。具体的には、依頼者端末６は、通信部６１と、近距離通信部６２と、入力部６３と、出力部６４と、制御部６５と、記憶部６６と、を有する。通信部６１、近距離通信部６２、入力部６３、出力部６４、制御部６５、および記憶部６６の機能構成は、それぞれ通信部４１、近距離通信部４２、入力部４３、出力部４４、制御部４５、および記憶部４６の機能構成と同様である。

＜提供者端末７＞
提供者端末７は、集配者端末４と同様の機能構成を有する。具体的には、提供者端末７は、通信部７１と、近距離通信部７２と、入力部７３と、出力部７４と、制御部７５と、記憶部７６と、を有する。通信部７１、近距離通信部７２、入力部７３、出力部７４、制御部７５、および記憶部７６の機能構成は、それぞれ通信部４１、近距離通信部４２、入力部４３、出力部４４、制御部４５、および記憶部４６の機能構成と同様である。このうち、入力部７３は、車両１１の提供者による車両１１のスケジュール情報の入力を受け付ける。記憶部７６は、キーユニット５２によって認証を受けることができるマスタ認証情報を記憶している。このため、提供者は、提供者端末７を用いて随時車両１１の車室の施解錠を行うことができる。

図４は、車両１１の提供者が予定変更を希望する場合の集配システム１の処理の概要を示すフローチャートである。図４では、荷物を保管している車両１１の提供者が予定変更を要求し、判定によって予定変更が可能である場合の処理の概要を示している。

まず、提供者端末７の入力部７３が提供者の操作による予定変更要求の入力を受け付ける（ステップＳ１）と、通信部７１は、制御部７５の制御のもと、予定変更要求を管理装置２へ送信する（ステップＳ２）。予定変更要求には、例えば車両１１の出発予定および到着予定の少なくとも一方の変更が含まれる。

予定変更要求を受信した管理装置２では、判定部２４が荷物情報を参照して予定変更の可否を判定する（ステップＳ３）。例えば、車両１５２の提供者に対応付けられた提供者端末７が、出発予定を２０１９年３月３１日の７：００に変更する要求を送信した場合、判定部２４は図３のテーブル１００を参照して、依頼者による荷物の受取予定（２０１９年３月３０日１８：００）よりも出発予定が後であることを確認し、予定変更可能と判定する。

この後、管理装置２の通信部２１は、制御部２２の制御のもと、判定結果を提供者端末７に送信する（ステップＳ４）。例えば、上述した車両１５２の提供者による予定変更要求の場合、通信部２１は予定変更可という判定結果を提供者端末７に送信する。

この後、制御部２２は、記憶部２３が記憶する荷物情報を更新する（ステップＳ５）。なお、判定部２４による判定の結果、予定変更が不可である場合、制御部２２は荷物情報を更新しない。

なお、荷物の配送の依頼者が依頼者端末６を用いて予定変更要求を管理装置２に送信する場合の処理は、上述した処理において提供者端末７を依頼者端末６に置き換えた処理に相当する。この場合、依頼者端末６が送信する予定変更要求には、例えば受取予定の変更が含まれる。

以上説明した実施の形態１によれば、集配対象の荷物の配送の依頼者に対応付けられた依頼者端末またはその荷物の集配先として提供する車両の提供者に対応付けられた提供者端末から予定変更要求を受信した場合、その荷物に関する情報に基づいて予定変更の可否を判定して判定結果を予定変更要求の送信元端末に送信し、予定変更の可否を含む情報を予定変更の要求者に的確に伝えるため、荷物の集配の依頼者や荷受用車両の提供者に予定変更が生じた場合に適切に対応することができる。

また、実施の形態１によれば、車両を所有していない人も車室を利用することができるとともに、車両を所有していて乗る機会が少ないような場合に車両を有効活用することができる。

（変形例）
図５は、車両１１の提供者が予定変更を希望する場合の集配システム１の処理の概要を示すフローチャートである。図５では、車室に荷物が収納された状態で駐停車している一つの車両１１（例えば、上述した車両００１）に関する処理の概要を示している。

ステップＳ１１およびＳ１２の処理は、上述したステップＳ１およびＳ２の処理とそれぞれ同じである。

ステップＳ１２の後、管理装置２の通信部２１は、制御部２２の制御のもと、依頼者端末６に変更可否の問合せを送信する（ステップＳ１３）。

変更可否の問合せを受信した依頼者端末６において、入力部６３が依頼者の操作による予定変更要求の入力を受け付ける（ステップＳ１４）と、通信部６１は、制御部６５の制御のもと、変更可否の回答を管理装置２へ送信する（ステップＳ１５）。

変更可否の回答を受信した管理装置２では、判定部２４が回答および荷物情報を参照して予定変更の可否を判定する（ステップＳ１６）。なお、受信した回答が予定変更不可である場合、判定部２４は、荷物情報を参照せずに予定変更が不可と判定してもよい。

ステップＳ１７、Ｓ１８の処理は、上述したステップＳ４、Ｓ５の処理とそれぞれ同じである。ここでも、判定部２４による判定の結果、予定変更不可である場合、制御部２２は荷物情報を更新しない。

なお、管理装置２が依頼者端末６から予定変更要求を受信した場合、提供者端末７に対して予定変更可否の問合せを行い、判定部２４が提供者端末７からの回答および荷物情報を参照して予定変更の可否を判定すればよい。

以上説明した実施の形態１の変形例によれば、依頼元ではない提供者または依頼者の意向もふまえて予定変更の可否を判定するため、よりきめ細かいサービスを提供することができる。

（実施の形態２）
図６は、実施の形態２に係る管理装置を備えた集配システムの機能構成を示す図である。図６では、管理装置２Ａをブロック図で記載している。図６に示す集配システム１Ａは、所定の領域Ｒ内に駐停車している複数の車両１１であってあらかじめ荷受用車両として登録された複数の車両１１の車室を利用することによって荷物の集配を行うシステムである。領域Ｒは、例えばあらかじめ登録された複数の車両１１が駐車する駐車場などの閉じた領域であるが、これに限定されるわけではない。

集配システム１Ａは、管理装置２Ａと、センタサーバ３と、集配者端末４と、複数の車両１１にそれぞれ搭載された複数の車載装置５と、依頼者端末６と、複数の車両１１をそれぞれ所有し、車室を荷受用として提供する複数の提供者に対応付けられた複数の提供者端末７と、を備える。以下の説明において、複数の車両１１のうち２つの車両を区別するために車両１１ａ、１１ｂと呼び、車両１１ａ、１１ｂにそれぞれ搭載された車載装置を車載装置５ａ、５ｂと呼ぶ。また、車載装置５ａ、５ｂにそれぞれ対応付けられる提供者端末を提供者端末７ａ、７ｂと呼ぶ。さらに、提供者端末７ａの構成要素を通信部７１ａなどと呼び、提供者端末７ｂの構成要素を通信部７１ｂなどと呼ぶ。

管理装置２Ａは、通信部２１と、制御部２２Ａと、記憶部２３とを有する。制御部２２Ａは、判定部２４と、選択部２５とを有する。選択部２５は、領域Ｒ内に駐停車可能であって車室を荷受用として提供可能な複数の車両１１の駐停車位置および駐停車期間と各車両１１に配送される荷物に関する情報とを含む駐停車情報に基づいて、集配対象の荷物を集配する車両を選択する。また、選択部２５は、提供者端末７からの予定変更要求に応じて、同じ領域Ｒ内で移管先の候補となる車両１１を選択する。

図７は、記憶部２３Ａが記憶する駐停車情報を模式的に示す図である。同図に示すテーブル２００には、集配車両ＩＤ、現在位置、領域Ｒ内の駐停車位置、荷物ＩＤ、荷物の種類、荷物収納状態、荷物の配送予定、荷物の受取予定、出発および到着予定が車両ごとに記載されている。現在位置および駐停車位置は、車載装置５から送られてくる位置情報に基づいて登録される。また、配送予定および受取予定は、依頼者端末６から送られてくる情報に基づいて登録される。また、出発および到着予定は、提供者端末７から送られてくるスケジュール情報に基づいて登録される。例えば、車両ＩＤ１０２の車両１１（以下、車両１０２という）の車室には、荷物ＩＤ１３７の荷物が配送済みである。この荷物の種類は食料品である。車両１０２は、領域Ｒ内の位置Ｂ−８に駐停車しており、依頼者による荷物の受取予定は２０１９年３月３０日２１：００である。車両１０２は、２０１９年３月３１日１０：００に領域Ｒを出発し、同日の１４：００に領域Ｒに到着する予定である。なお、駐停車情報を記憶部２３Ａが記憶する代わりに、管理装置２Ａとは異なる装置が記憶してもよい。

図８は、集配システム１Ａが行う処理の概要を示すシーケンス図である。図８では、提供者が予定変更を要求し、配送済みの荷物を移管することによって予定変更を実現する場合の処理の概要を示している。以下、予定変更を要求する提供者が所有する車両を車両１１ａとして説明する。

まず、提供者端末７ａの入力部７３ａが、提供者の操作により荷物の予定変更要求の入力を受け付ける（ステップＳ２１）と、通信部７１ａは、制御部７５ａの制御のもと、予定変更要求を管理装置２Ａに送信する（ステップＳ２２）。

予定変更要求を受信した管理装置２Ａでは、判定部２４が予定変更の可否を判定する（ステップＳ２３）。以下、判定部２４が予定変更可能と判定した場合の処理を説明する。この場合、領域Ｒ内に駐停車する複数の車両１１の駐停車情報を記憶部２３Ａから読み出して、この駐停車情報と予定変更要求に基づいて移管候補の車両を選択する（ステップＳ２４）。以下、選択した移管候補の車両を車両１１ｂとする。また、車両１１ｂの提供者を「候補者」といい、提供者端末７ｂを「候補者端末７ｂ」という。

続いて、通信部２１は、制御部２２Ａの制御のもと、選択部２５が選択した車両１１ｂに対応する候補者端末７ｂに、移管可否の問合せを送信する（ステップＳ２５）。

候補者端末７ｂの入力部７３ｂが候補者の操作によって移管受託通知の入力を受け付ける（ステップＳ２６）と、通信部７１ｂは管理装置２Ａに移管受託通知を送信する（ステップＳ２７）。

移管受託通知を受信した管理装置２Ａでは、駐停車情報を更新する（ステップＳ２８）。図９は、更新後の駐停車情報を模式的に示す図である。同図に示すテーブル３００は、図７のテーブル２００の駐停車情報が更新されたものである。具体的には、テーブル３００には、２つの項目「移管」と「移管予定」が追加されている。テーブル３００では、移管元の車両１１ａの車両ＩＤは１０２であり、移管先の車両１１ｂの車両ＩＤは１０３であり、移管予定が２０１９年３月３０日１９：００である場合を示している。また、テーブル３００では、テーブル２００と比較して、車両１１ａの受取予定がなくなり、車両１１ｂの受取予定が２０１９年３月３０日２１：００に設定されている。また、テーブル３００では、車両１１ａの出発予定が２０１９年３月３０日１９：３０に、到着予定が２０１９年３月３０日２３：００にそれぞれ変更となっている。

ステップＳ２８の後、通信部２１は、制御部２２の制御のもと、提供者端末７ａに移管先通知を送信（ステップＳ２９）し、依頼者端末６および候補者端末７ｂにそれぞれ移管通知を送信（ステップＳ３０、Ｓ３１）し、集配者端末４に移管指示を送信する（ステップＳ３２）。なお、ステップＳ２９〜Ｓ３２の処理の順序は任意である。

この後、集配者は、移管指示にしたがって、車両１１ａの車室に収納されている荷物を車両１１ｂの車室へ移動する。荷物の移動後に車両１１ｂの車室の施錠が完了した後、集配者端末４では、入力部４３が入力を受け付けた移管完了通知を、通信部４１が管理装置２Ａへ送信する。その後、管理装置２Ａは、制御部２２Ａが記憶部２３Ａの駐停車情報を更新し、通信部２１に依頼者端末６、提供者端末７ａおよび候補者端末７ｂへの移管完了報告を送信させる。

ステップＳ２３の判定の結果、予定変更不可の場合、管理装置２Ａは提供者端末７ａに対して予定変更不可の回答を送信する。ステップＳ２３の判定の結果、予定変更不可の場合、管理装置２Ａは提供者端末７ａに対して予定変更不可の回答を送信する。

なお、ここでは配送済みの荷物を他の車両１１へ移管する場合を説明したが、荷物が配送される前に管理装置２Ａが提供者端末７から予定変更要求を受信した場合には、選択部２５が集配先の車両１１を選択し直す。

図１０は、集配システム１Ａが行う別な処理の概要を示すシーケンス図である。図１０では、荷物の配送前に依頼者が予定変更を要求し、荷物の配送先を変更することによって予定変更を実現する場合の処理の概要を示している。

まず、依頼者端末６の入力部６３が、依頼者の操作により荷物の予定変更要求の入力を受け付ける（ステップＳ４１）と、通信部６１は、制御部６５の制御のもと、予定変更要求を管理装置２Ａに送信する（ステップＳ４２）。

予定変更要求を受信した管理装置２Ａでは、判定部２４が予定変更の可否を判定する（ステップＳ４３）。以下、判定部２４が予定変更可能と判定した場合の処理を説明する。領域Ｒ内に駐停車する複数の車両１１の駐停車情報を記憶部２３Ａから読み出して、この駐停車情報と予定変更要求に基づいて移管候補の車両を選択する（ステップＳ４４）。以下、移管元の車両を車両１１ａとし、選択した移管先候補の車両を車両１１ｂとする。また、ここでも車両１１ｂの提供者を「候補者」といい、提供者端末７ｂを「候補者端末７ｂ」という。

続いて、通信部２１は、制御部２２Ａの制御のもと、選択部２５が選択した車両１１ｂに対応する候補者端末７ｂに、移管可否の問合せを送信する（ステップＳ４５）。

候補者端末７ｂの入力部７３ｂが候補者の操作によって移管受託通知の入力を受け付ける（ステップＳ４６）と、通信部７１ｂは管理装置２Ａに移管受託通知を送信する（ステップＳ４７）。

移管受託通知を受信した管理装置２Ａでは、駐停車情報を更新する（ステップＳ４８）。図１１は、更新後の駐停車情報を模式的に示す図である。同図に示すテーブル４００は、図７のテーブル２００の駐停車情報が依頼者の予定変更要求に応じて更新されたものである。具体的には、テーブル４００には、１つの項目「移管」が追加されている。テーブル４００では、移管元の車両１１ａの車両ＩＤは１０１であり、移管先の車両１１ｂの車両ＩＤは１０３である。また、テーブル４００では、車両１１ｂの受取予定が２０１９年４月１日１０：００であり、当初の車両１１ａの受取予定（２０１９年３月３１日１４：００）から変更となっている。この場合、管理装置２Ａは、依頼者の受取予定の変更希望時刻には車両１１ａが領域Ｒを出発すると判断し、変更後の受取予定時刻に領域Ｒに駐停車している車両１１ｂを選択した。

ステップＳ４８の後、通信部２１は、制御部２２の制御のもと、提供者端末７ａに移管先通知を送信（ステップＳ４９）し、依頼者端末６および候補者端末７ｂにそれぞれ移管通知を送信（ステップＳ５０、Ｓ５１）し、集配者端末４に移管指示を送信する（ステップＳ５２）。なお、ステップＳ４９〜Ｓ５２の処理の順序は任意である。

この後、集配者は、移管指示にしたがって、車両１１ｂの車室に荷物を配送する。

なお、ここでは依頼者端末６から受信した予定変更要求に応じて荷物の配送先を変更する場合を説明したが、荷物の配送先を変更せずに予定変更することが可能であれば、ステップＳ４４〜Ｓ４７の処理は行わない。この場合、管理装置２Ａは、駐停車情報を更新した後、予定変更の完了通知を集配者端末４、依頼者端末６、および配送先の車両１１に対応する提供者端末７に送信する。

また、依頼者端末６から予定変更要求を受信した場合、まずは荷物の配送先として設定されている提供者端末７ａに予定変更の可否を問合せるようにしてもよい。この場合、提供者端末７ａから予定変更可の回答があれば、駐停車情報を更新して予定変更を依頼者端末６に通知する。一方、提供者端末７ａから予定変更不可の回答があった場合には、上記同様に候補者端末７ｂへ移管可否の問合せを行う。

また、判定部２４が判定した結果、予定変更が不可の場合、管理装置２Ａは依頼者端末６に判定結果を送信する。

以上説明した実施の形態２によれば、実施の形態１と同様に、荷物の保管期限が近づいた場合に適切に対応することができる。

また、実施の形態２によれば、実施の形態１と同様、車両の提供者や荷物の集配の依頼者に予定変更が生じた場合に適切に対応することができる。

また、実施の形態２によれば、所定の領域に駐停車する複数の荷受用車両が登録されている場合において、予定変更要求に応じて荷物の移管を行うことができるため、所定の領域内で荷受用に登録された車両を有効に活用して、依頼者または提供者の予定変更要求にも適切に対応することができる。

なお、選択部２５は、車両１１ごとにあらかじめ登録された集配条件の情報をさらに参照して、荷物を移管する車両１１を選択してもよい。集配条件としては、例えば荷物の種類、重量、集配時間帯等の条件を挙げることができる。

また、記憶部２３Ａに過去の移管の履歴情報を記憶させておき、選択部２５が駐停車情報とともに移管の履歴情報を参照して、例えば移管先となった回数が多い車両１１から順に荷物を移管する車両１１を選択するようにしてもよい。

また、一つの車室に複数の荷物を収納可能である場合には、記憶部２３Ａが同時に収納可能な荷物の種類の組み合わせをあらかじめ記憶しておき、その組み合わせに基づいて選択部２５が移管先の車両を選択するようにしてもよい。これにより、例えば匂いの発生源である食材と、食材の匂いが移らない方が好ましい衣服とが同じ車室に同時に収納される状況を未然に防止することができる。

また、移管先の車両１１に対して何らかの報酬を与えるようにしてもよい。これにより、車両１１の提供者は荷物の移管を積極的に受託するようになる。

（その他の実施の形態）
ここまで、本発明を実施するための形態を説明してきたが、本発明は、上述した実施の形態１、２によってのみ限定されるべきものではない。例えば、荷物を保管した状態の車両を受取前に車両を走行させたいという変更要求があった場合、管理装置は荷物の種類に応じて車両の走行可否を制御してもよい。具体的には、衣類のように走行しても問題がない荷物であれば車両の走行を可能とする一方、こわれものとして指定された荷物の場合には、受取が完了するまで車両が走行できないように制御するか、同じ領域内に駐停車する別の移管候補車両に移管する。車両が走行できない制御としては、例えばエンジンをロックする制御や、提供者端末によるマスタ認証を一時的に解除する制御を挙げることができる。

また、所定領域内に複数の車両が荷受用車両として登録されている場合において、荷物配送前に配送予定の車両のエンジンがオンとなったとき、管理装置は別の車両を選択して配送先を自動的に変更してもよい。なお、変更可能な車両の候補がない場合、管理装置は依頼者端末にキャンセル通知または受取予定の再設定を促す通知を送信する。

また、管理装置が認証情報発行部を有し、認証管理装置の機能を兼備する構成としてもよい。

また、管理装置およびセンタサーバを一つずつ備えた集配システムに代えて、集配者端末と物理的に近い場所に管理装置およびセンタサーバの一部の処理を実行可能な端末を分散して配置し、大量のデータを効率よく通信するとともに演算処理時間を短くすることが可能なエッジコンピューティングの技術を適用してもよい。

さらなる効果や変形例は、当業者によって容易に導き出すことができる。本発明のより広範な態様は、以上のように表しかつ記述した特定の詳細および代表的な実施の形態に限定されるものではない。したがって、添付のクレームおよびその均等物によって定義される総括的な発明の概念の精神または範囲から逸脱することなく、様々な変更が可能である。

１、１Ａ 集配システム
２、２Ａ 管理装置
３ センタサーバ
４ 集配者端末
５、５ａ、５ｂ 車載装置
６ 依頼者端末
７、７ａ、７ｂ 提供者端末
１１、１１ａ、１１ｂ、１０２、１５２ 車両
２１、３１、４１、６１、７１、５３１ 通信部
２２、２２Ａ、３２、４５、６５、７５、５１３、５２４、５３６ 制御部
２３、２３Ａ、３３、４６、６６、７６、５１５、５２５、５３７ 記憶部
２４ 判定部
２５ 選択部
３４ 認証情報発行部
４２、６２、７２、５２３ 近距離通信部
４３、６３、７３、５３４ 入力部
４４、６４、７４、５３５ 出力部
５１ 施解錠装置
５２ キーユニット
５３ 制御装置
１００、２００、３００、４００ テーブル
５１１ ＬＦ送信機
５１２ ＲＦ受信機
５１４ ドアロックアクチュエータ
５２１ ＬＦ受信機
５２２ ＲＦ送信機
５３２ 位置検出部
５３３ 速度検出部
ＮＷ 通信ネットワーク
Ｒ 領域

Claims (9)

1. メモリと、
   ハードウェアを有するプロセッサと、
   を備え、
   前記プロセッサは、
   荷物の配送の依頼者に対応付けられた依頼者端末または所定の領域内に駐停車している車両であって車室を前記荷物の集配先として提供する車両の提供者に対応付けられた提供者端末から予定変更要求を受信した場合、前記荷物に関する情報に基づいて予定変更の可否を判定し、判定結果を前記予定変更要求の送信元端末に送信する管理装置。
2. 前記プロセッサは、
   前記提供者端末および前記依頼者端末の一方の端末から予定変更要求を受信した場合、他方の端末に予定変更可否の問合せを送信し、
   前記他方の端末から受信した前記問合せの回答をさらに用いて予定変更の可否を判定する請求項１に記載の管理装置。
3. 前記プロセッサは、
   前記荷物に関する情報および前記領域内で車室を他者の荷物の荷受用として提供可能な複数の車両の駐停車に関する情報を含む駐停車情報に基づいて前記荷物の移管候補の車両を選択し、
   選択した移管候補の車両の提供者に対応付けられた候補者端末に対して移管の可否を問い合わせ、
   前記候補者端末から移管を受託する回答を受信した場合、前記予定変更が可能と判定する請求項１に記載の管理装置。
4. 前記プロセッサは、
   前記複数の車両の提供者がそれぞれ登録したスケジュール情報をさらに参照して、前記移管候補の車両を選択する請求項３に記載の管理装置。
5. 前記メモリは、
   過去の移管の履歴情報を記憶し、
   前記プロセッサは、
   前記履歴情報をさらに参照して前記移管候補の車両を選択する請求項３に記載の管理装置。
6. 前記プロセッサは、
   前記荷物の種類に応じて前記移管候補の車両を選択する請求項３に記載の管理装置。
7. 前記プロセッサは、
   前記候補者端末から移管受託通知を受信した場合、前記移管候補の車両の情報を含む移管指示を、前記荷物の集配者に対応付けられた集配者端末に送信する請求項３に記載の管理装置。
8. メモリと、ハードウェアを有するプロセッサとを備える管理装置が実行する管理方法であって、
   荷物の配送の依頼者に対応付けられた依頼者端末または所定の領域内に駐停車している車両であって車室を前記荷物の集配先として提供している車両の提供者に対応付けられた提供者端末から予定変更要求を受信した場合、前記荷物に関する情報をメモリから読み出して予定変更の可否を判定し、判定結果を前記予定変更要求の送信元端末に送信する管理方法。
9. メモリと、ハードウェアを有するプロセッサとを備える管理装置に実行させる管理プログラムであって、
   荷物の配送の依頼者に対応付けられた依頼者端末または所定の領域内に駐停車している車両であって車室を前記荷物の集配先として提供している車両の提供者に対応付けられた提供者端末から予定変更要求を受信した場合、前記荷物に関する情報に基づいて予定変更の可否を判定し、判定結果を前記予定変更要求の送信元端末に送信する管理プログラム。

Images