(57)【要約】【課題】格納装置を用いた荷物の一時保管が適切に行えるかを判定する。【解決手段】荷物を所定領域に格納可能であり、前記所定領域を施解錠可能な格納装置に対する、前記荷物の格納可否を判定するサーバ装置であって、前記格納装置内の前記所定領域の大きさに関する情報である格納装置情報を取得する格納装置情報取得手段と、前記所定領域に格納される荷物の大きさに関する情報である荷物情報を取得する荷物情報取得手段と、前記荷物情報および前記格納装置情報に基づいて、前記荷物が前記所定領域に格納可能であるか否かを判定する判定手段と、を有する。【選択図】図２
2019159644.tif 000002
【特許請求の範囲】
【請求項１】
荷物を所定領域に格納可能であり、前記所定領域を施解錠可能な格納装置に対する、前記荷物の格納可否を判定するサーバ装置であって、
前記格納装置内の前記所定領域の大きさに関する情報である格納装置情報を取得する格納装置情報取得手段と、
前記所定領域に格納される荷物の大きさに関する情報である荷物情報を取得する荷物情報取得手段と、
前記荷物情報および前記格納装置情報に基づいて、前記荷物が前記所定領域に格納可能であるか否かを判定する判定手段と、を有する、
サーバ装置。
【請求項２】
前記判定手段が、前記荷物が前記所定領域に格納可能であると判定した場合に、前記所定領域を解錠するための鍵情報を、前記荷物を格納するユーザが所持する携帯端末に送信する鍵送信手段をさらに有する、
請求項１に記載のサーバ装置。
【請求項３】
前記判定手段は、前記所定領域に前記荷物が格納できないと判定した場合に、所定の装置に通知を行う、
請求項２に記載のサーバ装置。
【請求項４】
前記格納装置情報取得手段は、前記格納装置情報として、前記所定領域の大きさをセンシングした結果を前記格納装置から取得する、
請求項１から３のいずれかに記載のサーバ装置。
【請求項５】
前記格納装置に対する前記荷物の格納履歴を取得する履歴取得手段をさらに有し、
前記判定手段は、前記格納履歴にさらに基づいて前記判定を行う、
請求項１から３のいずれかに記載のサーバ装置。
【請求項６】
前記格納装置から前記荷物を取り出した旨の受領情報を荷受人から取得する受領情報取得手段をさらに有し、
前記判定手段は、前記受領情報にさらに基づいて前記判定を行う、
請求項５に記載のサーバ装置。
【請求項７】
前記格納装置は車両であり、
前記格納装置情報取得手段は、車種ごとに定義された前記格納装置情報を取得する、
請求項１から６のいずれかに記載のサーバ装置。
【請求項８】
携帯端末から取得した認証情報に基づいて施解錠を行い、荷物を所定領域に格納可能な格納装置と、前記格納装置に対する前記荷物の格納可否を判定するサーバ装置と、からなる配送システムであって、
前記格納装置は、
前記格納装置内の前記所定領域の大きさに関する情報である格納装置情報を送信する格納装置情報送信手段を有し、
前記サーバ装置は、
前記格納装置情報を取得する格納装置情報取得手段と、
前記所定領域に格納される荷物の大きさに関する情報である荷物情報を取得する荷物情報取得手段と、
前記荷物情報および前記格納装置情報に基づいて、前記荷物が前記所定領域に格納可能であるか否かを判定する判定手段と、
を有する、配送システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、格納装置を用いて荷物の格納を行うシステムに関する。
【背景技術】
【０００２】
受取人が配達先として指定した荷受用車両のトランクで、配達物の受け渡しを行う技術が提案されている（例えば、特許文献１を参照）。当該技術によれば、受取人は、自身が所有する車両を配達先として指定することで、配達物を受け取るための宅配ロッカー等を設置することなく、不在時であっても配達物を受け取ることができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２０６２２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一方、駐車中の車両内の空間は限られているため、必ずしも配送される荷物が格納できるとは限らない。例えば、荷物のサイズによっては、トランクに収納できず、持ち戻りが発生してしまうおそれがある。
【０００５】
本発明は上記の課題を考慮してなされたものであり、格納装置を用いた荷物の一時保管が適切に行えるかを判定する技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係るサーバ装置は、荷物を所定領域に格納可能であり、前記所定領域を施解錠可能な格納装置に対する、前記荷物の格納可否を判定するサーバ装置である。
具体的には、前記格納装置内の前記所定領域の大きさに関する情報である格納装置情報を取得する格納装置情報取得手段と、前記所定領域に格納される荷物の大きさに関する情報である荷物情報を取得する荷物情報取得手段と、前記荷物情報および前記格納装置情報に基づいて、前記荷物が前記所定領域に格納可能であるか否かを判定する判定手段と、を有することを特徴とする。
【０００７】
所定領域とは、荷物の保管および施解錠が可能な施設の領域であり、例えば、自動車の車室やトランクなどが一例であるが、必ずしもこれらに限らない。以下、自動車の例で説明するが、自動車以外にも適用可能である。
格納装置情報は、格納装置が有する所定領域の大きさに関する情報であり、例えば、格納装置が車両である場合、車室やトランクの大きさに関する情報である。なお、格納装置情報は、所定領域の大きさに関する情報であれば、必ずしもサイズそのものを表す情報でなくてもよい。
荷物情報は、車両への格納が予定されている荷物の大きさに関する情報である。荷物情報は、例えば、荷物の三辺の大きさなどを表す情報を含んでいてもよい。
また、判定手段は、格納装置情報と、当該車両に格納される予定の荷物に対応する荷物情報に基づいて、当該荷物を適切に格納できるか否かを判定する。例えば、所定領域のサイズに対して、荷物の三辺のサイズのうち少なくともいずれかが超過していた場合、当該荷物を適切に格納できない旨を判定する。
かかる構成によると、格納装置を解錠した後で、荷物を格納できないことが判明するといったトラブルを防止することができる。
【０００８】
また、前記判定手段が、前記荷物が前記所定領域に格納可能であると判定した場合に、前記所定領域を解錠するための鍵情報を、前記荷物を格納するユーザが所持する携帯端末に送信する鍵送信手段をさらに有することを特徴としてもよい。
【０００９】
鍵情報は、所定領域を解錠するための電子データである。例えば、携帯端末が当該鍵情報を格納装置に伝送して認証を行うことで、荷物を格納する領域の施解錠が可能になる。当該鍵情報を、荷物の格納が適切に行えると判定した場合にのみ送信することで、配送出発後に発生するトラブルを避けることができる。
【００１０】
また、前記判定手段は、前記所定領域に前記荷物が格納できないと判定した場合に、所定の装置に通知を行うことを特徴としてもよい。
【００１１】
荷物の格納が適切に行えないと判定した場合、例えば、配送担当者などが所持する携帯端末、配送業者などが管理するサーバ装置、荷受人が所持する携帯端末などに通知を行うようにしてもよい。かかる構成によると、受取方法や配送日時の変更を迅速に行うことができるようになる。
【００１２】
また、前記格納装置情報取得手段は、前記格納装置情報として、前記所定領域の大きさをセンシングした結果を前記格納装置から取得することを特徴としてもよい。
【００１３】
既に格納装置内に荷物が存在する場合、利用できるスペースが減少するため、後から到着する荷物が格納できなくなるおそれがある。そこで、利用できるスペースをセンシングした結果に基づいて、荷物の格納可否を判定するようにしてもよい。センシングは、例えば、距離などの物理量を取得するセンサを用いて行ってもよいし、装置内を撮像した結果を解析することで行ってもよい。
【００１４】
また、前記格納装置に対する前記荷物の格納履歴を取得する履歴取得手段をさらに有し、前記判定手段は、前記格納履歴にさらに基づいて前記判定を行うことを特徴としてもよい。
【００１５】
かかる構成によると、複数の荷物が配送される場合において、格納可否判定を適切に行うことができる。
【００１６】
また、前記格納装置から前記荷物を取り出した旨の受領情報を荷受人から取得する受領情報取得手段をさらに有し、前記判定手段は、前記受領情報にさらに基づいて前記判定を行うことを特徴としてもよい。
【００１７】
格納装置から荷物を取り出した旨の情報を取得することで、今現在格納装置内にある荷物を特定することができる。すなわち、複数の荷物が配送される場合において、格納可否判定をより正確に行うことができるようになる。
【００１８】
また、前記格納装置は車両であり、前記格納装置情報取得手段は、車種ごとに定義された前記格納装置情報を取得することを特徴としてもよい。
【００１９】
このように、格納装置が車両である場合、車種ごとに所定領域のサイズを推定することができる。
【００２０】
また、本発明に係る配送システムは、
携帯端末から取得した認証情報に基づいて施解錠を行い、荷物を所定領域に格納可能な格納装置と、前記格納装置に対する前記荷物の格納可否を判定するサーバ装置と、からな
る配送システムであって、前記格納装置は、前記格納装置内の前記所定領域の大きさに関する情報である格納装置情報を送信する格納装置情報送信手段を有し、前記サーバ装置は、前記格納装置情報を取得する格納装置情報取得手段と、前記所定領域に格納される荷物の大きさに関する情報である荷物情報を取得する荷物情報取得手段と、前記荷物情報および前記格納装置情報に基づいて、前記荷物が前記所定領域に格納可能であるか否かを判定する判定手段と、を有することを特徴とする。
【００２１】
なお、本発明は、上記手段の少なくとも一部を含むサーバ装置として特定することができる。また、前記サーバ装置を含む配送システムとして特定することもできる。上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。
【発明の効果】
【００２２】
本発明によれば、格納装置を用いた荷物の一時保管が適切に行えるかを判定することができる。
【図面の簡単な説明】
【００２３】
【図１】第一の実施形態に係る配送システムのシステム概要図である。
【図２】配送システムが有する構成要素の一例を概略的に示したブロック図である。
【図３】車両情報および荷物情報の例。
【図４】第一の実施形態におけるデータフローを説明する図。
【図５】第一の実施形態におけるデータフローを説明する図。
【図６】ステップＳ１２における処理の詳細を示した図。
【図７】車室内における既存荷物を説明する図。
【図８】第二の実施形態における既存荷物情報を説明する図。
【発明を実施するための形態】
【００２４】
（第一の実施形態）
<システム概要>
本実施形態に係る配送システムの概要について、図１を参照しながら説明する。本実施形態に係る配送システムは、施解錠装置１００、携帯端末２００、配送管理サーバ３００、鍵管理サーバ４００を含んで構成される。
本実施形態に係る配送システムでは、車両１０に搭載された施解錠装置１００が、車外にある携帯端末２００と無線通信を行い、当該通信の結果に基づいて車両１０の施解錠を行う。すなわち、システムのユーザは、物理的な鍵を用いずに、携帯端末２００のみを用いて車両１０の施解錠を行うことができる。
本実施形態に係る配送システムでは、荷物の配送を行う配送担当者が携帯端末２００を所持しており、必要に応じて荷受人が指定した車両１０の施解錠を行うことができる。これにより、車両１０を配送先（宅配ボックス）として利用することができる。
【００２５】
鍵管理サーバ４００は、施解錠装置１００が携帯端末２００を認証するための情報（認証情報）を発行するサーバ装置である。鍵管理サーバ４００は、配送管理サーバ３００を経由して携帯端末２００に第一の認証情報を発行し、同様に、配送管理サーバ３００を経由して施解錠装置１００に第二の認証情報を発行する。施解錠装置１００は、これらの認証情報を照合することで、携帯端末２００が正当なものであることを認証する。
【００２６】
配送管理サーバ３００は、荷物の配送状況と、当該荷物を配送する配送担当者が所持する複数の携帯端末２００を管理するサーバ装置である。なお、図１には携帯端末２００および車両１０を一つずつ図示しているが、配送管理サーバ３００が管理する携帯端末２００は複数であってもよい。また、携帯端末２００がアクセス可能な車両１０は複数であっ
てもよい。
【００２７】
<システム構成>
システムの構成要素について、詳しく説明する。
図２は、図１に示した施解錠装置１００、携帯端末２００、配送管理サーバ３００、鍵管理サーバ４００の構成の一例を概略的に示したブロック図である。このうち、施解錠装置１００が、施解錠（施錠および解錠）の対象である車両１０に搭載される。
【００２８】
施解錠装置１００は、車両のドアを施錠および解錠するための装置である。具体的には、車両のユーザが所持する電子キー（携帯機）から、高周波帯の電波を介して送信される施錠信号および解錠信号に応じて、車両１０のドアを施錠および解錠する。
本実施形態では、施解錠装置１００が、上述した機能に加え、携帯端末２００と行った通信の結果に基づいてドアの施解錠を行う機能を有している。
【００２９】
施解錠装置１００は、近距離通信部１０１、照合ＥＣＵ１０２、ボディＥＣＵ１０３、ドアロックモータ１０４、通信部１０５を含んで構成される。施解錠装置１００は、車両１０に搭載される不図示の補機バッテリから供給される電力で動作する。なお、本例では、電子キーと通信を行う手段については図示を省略している。
【００３０】
近距離通信部１０１は、ユーザが所持する携帯端末２００と通信を行うモジュールである。近距離通信部１０１は、所定の無線通信規格を用いて、近距離（車室内と車室外で通信が行える程度）における通信を行う。
【００３１】
本実施形態では、近距離通信部１０１は、Ｂｌｕｅｔｏｏｔｈ（登録商標）ＬｏｗＥｎｅｒｇｙ規格（以下、ＢＬＥ）によるデータ通信を行う。ＢＬＥとは、Ｂｌｕｅｔｏｏｔｈによる低電力通信規格であり、機器同士のペアリングを必要とせず、相手を検知することですぐに通信を開始できるという特徴を有する。
なお、本実施形態ではＢＬＥを例示するが、他の無線通信規格も利用可能である。例えば、ＮＦＣ（Near Field Communication）、ＵＷＢ（Ultra Wideband）、ＷｉＦｉ（登録商標）などを利用することもできる。
【００３２】
照合ＥＣＵ１０２は、近距離通信部１０１を介して携帯端末２００と近距離無線通信を行い、携帯端末２００を認証する制御と、認証の結果に基づいて、車両１０のドアを施錠および解錠する制御を行うコンピュータである。照合ＥＣＵ１０２は、例えば、マイクロコンピュータによって構成される。
なお、以下の説明において、施錠信号と解錠信号を施解錠信号と総称する。施解錠信号という語は、施錠信号と解錠信号の少なくともいずれかを表す。
【００３３】
照合ＥＣＵ１０２は、機能モジュールとして通信処理部１０２１、認証部１０２２および鍵制御部１０２３を有している。各機能モジュールは、ＲＯＭ（Read Only Memory）等の記憶手段に記憶されたプログラムをＣＰＵ（Central Processing Unit）（いずれも不
図示）によって実行することで実現してもよい。
【００３４】
通信処理部１０２１は、近距離通信部１０１を介して行う携帯端末２００との通信を処理する。具体的には、携帯端末２００から施錠要求または解錠要求（以下、施解錠要求と総称する）を受信し、受信した要求に応じて、施解錠信号を生成する。
なお、生成された施解錠信号は、一時的に記憶され、後述する認証部１０２２が携帯端末２００の認証に成功したタイミングで出力される。
【００３５】
認証部１０２２は、携帯端末２００から送信された施解錠要求に含まれる認証情報に基
づいて、携帯端末２００の認証を行う。具体的には、不図示の記憶手段に記憶された認証情報と、携帯端末２００から送信された認証情報とを比較し、これらが一致した場合に、認証成功と判断する。双方の認証情報が一致しない場合、認証失敗と判断する。認証部１０２２が携帯端末２００の認証に成功した場合、通信処理部１０２１が生成した施解錠信号が、後述する鍵制御部１０２３へ送信される。
なお、認証部１０２２が行う認証の方式は、認証情報同士を単純に比較して同一性を検証する方式であってもよいし、非対称暗号を用いた方式であってもよい。前述した「一致」とは、二つの認証情報が互いに対応するものであることを確認できればよく、必ずしも両者が同一である必要はない。
以降、説明の必要に応じて、施解錠装置１００に記憶される認証情報を装置認証情報、携帯端末２００から送信される認証情報を端末認証情報と称するものとする。なお、両者を区別する必要がない場合は単に認証情報と称する。
なお、認証部１０２２が記憶する装置認証情報は、後述する鍵管理サーバ４００で生成され、ネットワーク経由で受信および格納される。
【００３６】
鍵制御部１０２３は、認証部１０２２が行った認証の結果に基づいて、後述するボディＥＣＵ１０３に解錠指令または施錠指令を送信する。当該信号は、ＣＡＮ（Controller Area Network）等の車内ネットワークを介して送信される。
【００３７】
ボディＥＣＵ１０３は、車両のボディ制御を行うコンピュータである。ボディＥＣＵ１０３は、受信した解錠指令または施錠指令に基づいて、後述するドアロックモータ１０４を制御することで、車両のドアの解錠および施錠を行う機能を有している。なお、ボディＥＣＵ１０３は、パワーウインドウ制御、シート調節、盗難防止、シートベルト制御、ヘッドライト制御など、車体に関連付いたコンポーネントの制御を行う機能をさらに有していてもよい。
【００３８】
ドアロックモータ１０４は、車両１０のドア（乗降用ドアやリアゲートのほか、トランクも含む）を施錠および解錠するアクチュエータである。ドアロックモータ１０４は、ボディＥＣＵ１０３から送信された信号に基づいて動作する。
【００３９】
通信部１０５は、施解錠装置１００をネットワークに接続するための通信インタフェースである。本実施形態では、３ＧやＬＴＥ等の移動体通信サービスを利用して、ネットワーク経由で他の装置と通信を行うことができる。
【００４０】
次に、携帯端末２００について説明する。
携帯端末２００は、例えばスマートフォン、携帯電話、タブレットコンピュータ、個人情報端末、ノートブックコンピュータ、ウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。携帯端末２００は、近距離通信部２０１、通信部２０２、制御部２０３を有して構成される。
【００４１】
近距離通信部２０１は、近距離通信部１０１と同一の通信規格によって、施解錠装置１００との間で通信を行う手段である。
通信部２０２は、通信部１０５と同様の、ネットワーク接続を行うための通信インタフェースである。
【００４２】
制御部２０３は、携帯端末２００の制御を司る手段である。制御部２０３は、例えば、施解錠要求を生成する処理、前述した端末認証情報を取得する処理、施解錠要求および端末認証情報を施解錠装置１００に送信する処理などを行う。制御部２０３は、例えば、マイクロコンピュータによって構成される。制御部２０３は、記憶手段（ＲＯＭ等）に記憶されたプログラムをＣＰＵ（いずれも不図示）によって実行することでこれらの機能を実
現してもよい。
【００４３】
制御部２０３は、ユーザとのインタラクションを行う入出力部（不図示）と接続されている。入出力部は、例えば、タッチパネルとその制御手段、液晶ディスプレイとその制御手段から構成される。タッチパネルおよび液晶ディスプレイは、本実施形態では一つのタッチパネルディスプレイからなる。
【００４４】
制御部２０３は、入出力部を介して操作画面を表示し、ユーザが行った操作に基づいて、解錠要求または施錠要求を生成する。例えば、制御部２０３は、タッチパネルディスプレイに、解錠を行うためのアイコン、施錠を行うためのアイコン等を出力し、ユーザによって行われた操作に基づいて、解錠要求ないし施錠要求を生成する。
なお、ユーザが行う操作は、タッチパネルディスプレイを介したものに限られない。例えば、ハードウェアスイッチ等によるものであってもよい。
【００４５】
また、制御部２０３は、端末認証情報を取得する処理を行う。本実施形態では、端末認証情報は、後述する鍵管理サーバ４００において生成され、後述する配送管理サーバ３００を介して携帯端末２００へ伝送される。
なお、携帯端末２００が端末認証情報を有していない場合、操作画面からの施錠操作および解錠操作は不可能となる。
携帯端末２００が取得する端末認証情報は、不変のキーであってもよいし、ワンタイムキーであってもよい。いずれの場合も、端末認証情報に対応する装置認証情報が、施解錠装置１００に事前に記憶される。
【００４６】
次に、配送管理サーバ３００について説明する。
配送管理サーバ３００は、配送を行う荷物、および、複数の配送担当者が所持する携帯端末２００を管理するサーバ装置である。配送管理サーバ３００は、対象となる荷物に関する情報を記憶しており、その配送場所として車両１０が指定されている場合に、当該荷物を格納する車両１０を施解錠するための端末認証情報を鍵管理サーバ４００から取得し、携帯端末２００へ転送する。この処理は、配送担当者が配送に出発する前に行われる。
【００４７】
また、配送管理サーバ３００は、車両１０（施解錠装置１００）に対応する装置認証情報を鍵管理サーバ４００から取得し、施解錠装置１００（照合ＥＣＵ１０２）へ転送する。この処理は、荷物の配送が発生するごとに行ってもよいし、荷物の配送とは関係のないタイミングで行ってもよい。本実施形態では、装置認証情報は、システムのセットアップ時に取得され、施解錠装置１００へ転送されるものとする。
【００４８】
配送管理サーバ３００は、通信部３０１と、記憶部３０２と、制御部３０３を有して構成される。
通信部３０１は、通信部１０５と同様の、ネットワーク接続を行うための通信インタフェースである。
【００４９】
記憶部３０２は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。記憶部３０２には、荷物を車両に配送するための情報が保存される。
【００５０】
図３を参照して、荷物を車両に配送するための情報について説明する。本実施形態では、記憶部３０２には、荷物情報、車両情報、荷受人情報の三種類の情報が記憶される。
荷物情報は、荷物の識別子（以下、荷物ＩＤ）と、当該荷物のサイズに関する情報が関連付けられた情報である。本実施形態では、荷物のサイズに関する情報として、縦サイズ、横サイズ、高さがそれぞれ記憶される。荷物情報は、荷物の配送が発生するたびに配送
業者によって更新される。なお、荷物情報は、荷物の発送者が入力した情報に基づいて更新してもよい。
【００５１】
車両情報は、荷受人の識別子（以下、利用者ＩＤ）と、荷物の配送先となる車両１０の識別子（以下、車両ＩＤ）と、当該車両の車室のサイズに関する情報が関連付けられた情報（本発明における格納装置情報）である。なおここでは、車室とは、車内における荷物を格納可能な領域（例えば乗車空間やトランク）を表す。本実施形態では、荷物を配置できる空間の縦サイズ、横サイズ、高さがそれぞれ記憶される。車両情報は、荷受人がサービスの利用を開始する際に当該荷受人によって登録される。記憶部３０２に車両情報が登録されていることは、当該車両への荷物の配送が許可されていることを意味する。なお、車両１０の車種と車室サイズを関連付ける情報が別に存在する場合、車両情報は、車両１０の車種のみを表す情報であってもよい。
荷受人情報は、荷物ＩＤと利用者ＩＤとが関連付けられた情報である。荷受人情報は、荷物の配送が発生するたびに配送業者によって更新される。
【００５２】
制御部３０３は、配送管理サーバ３００の制御を司る手段である。制御部３０３は、例えば、ＣＰＵによって構成される。
制御部３０３は、機能モジュールとして配送管理部３０３１および配送可否判定部３０３２を有している。当該機能モジュールは、ＲＯＭ等の記憶手段に記憶されたプログラムをＣＰＵ（いずれも不図示）によって実行することで実現してもよい。
【００５３】
配送管理部３０３１は、携帯端末２００からの要求を受け、車両１０を解錠するための認証情報の発行を鍵管理サーバ４００に要求する手段である。
配送管理部３０３１は、配送予定の荷物に関する情報を携帯端末２００から受信すると、記憶部３０２に記憶された荷受人情報および車両情報に基づいて配送先となる車両１０を特定し、当該車両１０を施解錠するための端末認証情報の発行を鍵管理サーバ４００に依頼する。また、鍵管理サーバ４００によって発行された端末認証情報を携帯端末２００に転送する。
なお、端末認証情報の発行依頼は、後述する配送可否判定部３０３２が、車両１０への荷物の配送が可能であると判定した場合にのみ行われる。
【００５４】
配送可否判定部３０３２は、配送予定の荷物が、対応する車両１０（荷受人の管理下にある車両）に格納できるか否かを判定する。配送可否判定部３０３２は、配送管理部３０３１が特定した車両１０に対応する車両情報と、当該車両１０に配送予定の荷物に対応する荷物情報とに基づいて、当該荷物が当該車両１０の車室に格納可能であるか否かを判定する。例えば、車室サイズによって特定された大きさの立方体が、荷物サイズによって特定された大きさの立方体を含むことができるかを判定する。この結果、含むことができる場合、荷物が車両１０に格納可能であり、そうでない場合、荷物が車両１０に格納不可能であると判定することができる。
【００５５】
次に、鍵管理サーバ４００について説明する。
鍵管理サーバ４００は、配送管理サーバ３００からの求めに応じて、携帯端末２００が利用する端末認証情報と、施解錠装置１００が利用する装置認証情報を発行する装置である。鍵管理サーバ４００は、通信部４０１、制御部４０２、記憶部４０３を有して構成される。
【００５６】
通信部４０１は、通信部３０１と同様の、ネットワーク接続を行うための通信インタフェースである。
【００５７】
制御部４０２は、鍵管理サーバ４００の制御を司る手段である。制御部４０２は、例え
ば、ＣＰＵによって構成される。
制御部４０２は、機能モジュールとして鍵発行部４０２１を有している。当該各機能モジュールは、ＲＯＭ等の記憶手段に記憶されたプログラムをＣＰＵ（いずれも不図示）によって実行することで実現してもよい。
【００５８】
鍵発行部４０２１は、配送管理サーバ３００からの求めに応じて端末認証情報および装置認証情報を発行する。端末認証情報は、前述したように、携帯端末２００が、施解錠装置１００を介して車両１０の施錠および解錠を行うための認証情報である。また、装置認証情報は、端末認証情報と対をなす認証情報である。
【００５９】
端末認証情報および装置認証情報は、予め記憶されたものを取得してもよいし、動的に生成してもよい。例えば、所定の時間帯においてのみ有効な認証情報や、使用回数が指定された認証情報、所定の携帯端末２００においてのみ使用できる認証情報などを生成することもできる。
なお、車両１０が、車室やトランクなど、独立して施解錠可能な複数の領域を有している場合、いずれかの領域のみを施解錠可能な認証情報を生成してもよい。
【００６０】
記憶部４０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。記憶部４０３には、施解錠装置１００に対応する装置認証情報や、当該装置認証情報と対をなす端末認証情報、これらの認証情報を生成するための各種のデータが保存される。
【００６１】
次に、前述した各構成要素が行う処理について説明する。処理は、携帯端末２００が端末認証情報を取得するフェーズ（第一のフェーズ）と、携帯端末２００が、取得した端末認証情報を用いて施解錠装置１００にアクセスし、車両を施解錠するフェーズ（第二のフェーズ）に分けることができる。図４が第一のフェーズにおけるデータの流れを表した図であり、図５が第二のフェーズにおけるデータの流れを表した図である。
【００６２】
図４を参照して第一のフェーズについて説明する。ステップＳ１１〜Ｓ１６の処理は、携帯端末２００から端末認証情報の発行要求があった場合に実行される。
まず、ステップＳ１１で、携帯端末２００が、配送管理サーバ３００に対して端末認証情報の発行を要求する。当該ステップでは、携帯端末２００を識別する情報と、配送される荷物を一意に識別する荷物ＩＤ（例えば伝票番号）が認証情報要求として同時に送信される。
【００６３】
ステップＳ１２では、配送管理サーバ３００が、配送先となる車両１０を特定し、配送予定荷物の配送可否判定を行う。本ステップでは、配送管理部３０３１が、記憶部３０２に記憶された荷受人情報および車両情報を参照し、これらの情報に基づいて、配送先となる車両１０を特定する。また、配送可否判定部３０３２が、記憶部３０２に記憶された荷物情報および車両情報を参照し、荷物サイズと車両１０の車室サイズに基づいて、当該荷物が車両１０に格納できるか否かを判定する。
【００６４】
図６は、ステップＳ１２における処理をより詳細に示したものである。
まず、ステップＳ１２１で、配送管理部３０３１が、認証情報要求に含まれる荷物の識別子と、記憶部３０２に予め記憶された情報に基づいて、当該荷物の配送先として車両１０が利用可能であるか否かを判定する。この結果、利用可能である場合、対応する車両１０を選択し（ステップＳ１２２）、ステップＳ１２４へ進む。
【００６５】
一方、荷物の配送先として車両１０が利用できない場合（利用が許可されていない場合や、車両１０に関する情報が存在しない場合）、配送先として車両１０が利用できない旨
の通知を生成し、携帯端末２００に送信する（ステップＳ１２３）。この場合、図４に示した処理は終了する。
なお、荷物の配送先として複数の車両１０が利用可能である場合、いずれかの車両を選択して処理を進めることができる。車両の選択は、配送担当者が行ってもよいし、装置が自動的に行ってもよい。また、配送管理部３０３１が、荷物に関する情報を参照したうえで車両の選択を行ってもよい。例えば、荷物のサイズに応じた荷室サイズを有する車両を自動的に選択するようにしてもよい。
【００６６】
車両１０が選択されると、ステップＳ１２４で、配送可否判定部３０３２が、記憶された荷物情報と車両情報に基づいて、当該荷物が車両１０の車室に格納可能であるか否かを判定する。なお、配送を行う荷物が複数個である場合、全ての荷物が格納可能であるかを判定する。
この結果、格納可能である場合、処理はステップＳ１３へ進む。格納できない場合、ステップＳ１２３へ進み、前述したように、配送先として車両１０が利用できない旨の通知を生成し、携帯端末２００に送信する（ステップＳ１２３）。この場合、図４に示した処理は終了する。なお、ステップＳ１２３では、車両１０が利用できない理由を提示してもよい。
【００６７】
図４に戻って説明を続ける。
ステップＳ１３では、配送管理部３０３１が、当該車両の識別子を認証情報要求に追加して、鍵管理サーバ４００へ送信する。
【００６８】
ステップＳ１４では、鍵発行部４０２１が、携帯端末２００および車両１０（車両１０に搭載された施解錠装置１００）に固有な端末認証情報を生成（ないし取得）する。
【００６９】
次に、ステップＳ１５で、生成した端末認証情報を配送管理サーバ３００に送信する（ステップＳ１５）。また、配送管理サーバ３００は、当該端末認証情報を携帯端末２００に転送する（ステップＳ１６）。これにより、携帯端末２００上において、車両１０を解錠する操作が可能になる。なお、ステップＳ１５およびＳ１６では、端末認証情報に付随する情報として、配送先となる車両１０を識別するための情報をさらに送信することが好ましい。例えば、車種やナンバープレートに関する情報、車両１０の位置情報などを同時に送信することで、配送担当者が対象の車両を発見しやすくなる。
【００７０】
なお、本例では配送管理サーバ３００を介して端末認証情報を転送したが、鍵管理サーバ４００から携帯端末２００に端末認証情報を直接送信するようにしてもよい。
また、本例では、装置認証情報は、鍵管理サーバ４００が発行して予め施解錠装置１００に記憶しておくものとしたが、ステップＳ１４と同一のタイミングで鍵管理サーバ４００が発行し、配送管理サーバ３００を介して施解錠装置１００に転送するようにしてもよい。
【００７１】
なお、ステップＳ１１〜Ｓ１６の処理は、施解錠を行うための準備処理であるため、事前に行っておくことが好ましい。例えば、配送の準備段階において実行してもよい。
【００７２】
図５を参照して第二のフェーズについて説明する。ステップＳ２１〜Ｓ２２は、携帯端末２００を用いて車両１０を解錠するための処理である。
携帯端末２００のユーザ（すなわち配送担当者）が、入出力部を介して車両１０を解錠する操作を行うと、携帯端末２００と施解錠装置１００との間でＢＬＥによるリンクが確立され、ステップＳ２１で、携帯端末２００が、施解錠装置１００に対して解錠要求および端末認証情報を送信する。
【００７３】
ステップＳ２２では、施解錠装置１００が有する認証部１０２２が、携帯端末２００から送信された端末認証情報と、事前に記憶された装置認証情報とを照合し、認証処理を行う。認証に成功した場合、鍵制御部１０２３が車両１０のドアを解錠する。
【００７４】
ステップＳ３１〜Ｓ３４は、携帯端末２００を用いて車両１０を施錠するための処理である。
携帯端末２００のユーザが、入出力部（例えばタッチパネルスクリーン）を介して車両１０を施錠する操作を行うと、ステップＳ３１で、携帯端末２００が、施解錠装置１００に対して施錠要求および端末認証情報を送信する。
【００７５】
ステップＳ３２では、施解錠装置１００が有する認証部１０２２が、携帯端末２００から送信された端末認証情報と、事前に記憶された装置認証情報とを照合し、認証処理を行う。認証に成功した場合、鍵制御部１０２３が車両１０のドアを施錠する。
【００７６】
また、施解錠装置１００が有する通信処理部１０３１は、施錠を行った後で、携帯端末２００に対して施錠が完了した旨の通知（施錠通知）を送信する（ステップＳ３３）。これにより、携帯端末２００のタッチパネルスクリーン上に、施錠が完了した旨の通知が出力される。なお、端末認証情報がワンタイムキーである場合、ステップＳ３３のタイミングで当該ワンタイムキーを無効化してもよい。最後に、携帯端末２００が、配送管理サーバ３００に対して施錠通知を送信する（ステップＳ３４）。
なお、配送管理サーバ３００は、荷受人に関連付いた端末（例えば、荷受人が所持する携帯端末など）に、配送が完了した旨のメッセージを送信してもよい。
【００７７】
前述した実施形態によると、車両に対して荷物の配送を行う前に、当該荷物が当該車両に格納できるか否かを事前に知ることができる。
【００７８】
なお、図６の例では、車両１０が利用できないと判定された場合に、携帯端末２００のみに通知を送信したが、荷受人が有する携帯端末（不図示）に同様の通知を行ってもよい。これにより、配送時間帯や受け取り場所の変更などを促すことができる。
また、図６の例では、車両１０が利用できないと判定された場合に、通知のみを行ったが、荷物を配送するための施策を講じてもよい。例えば、配送対象の荷物が複数個であって、そのうちの一部を格納可能である場合、配送を分割するように予定を変更してもよい。
【００７９】
（第二の実施形態）
第一の実施形態では、車両情報に定義されている車室サイズが確保されていることを前提として荷物の格納可否を判断した。しかし、荷物の配送が同日に複数回ある場合や、車室内に荷受人の私物が置かれている場合、利用できる車室内のスペースが想定よりも狭くなる場合がある。例えば、図７に示したように、配送済みの荷物が既に存在する場合、利用できるスペースが狭くなるため、新たな荷物が格納できないケースが発生しうる。
第二の実施形態は、これに対応するため、車室内のスペースをセンシングし、車室内に既に置かれている荷物（以下、既存荷物）に関する情報を生成し利用する実施形態である。
【００８０】
第二の実施形態では、車両１０が、車室内に置かれている既存荷物のサイズを取得する手段（不図示）をさらに有している。既存荷物のサイズは、例えば、センサが行ったセンシングの結果に基づいて、既に置かれている物体の体積を推定することで求めてもよい。既に置かれている物体の体積は、車室内に設置された複数の距離センサなどを用いて取得してもよいし、車室内の距離画像を取得し、取得した距離画像に基づいて推定してもよい。
【００８１】
車両１０は、車室内にある既存荷物のサイズに関する情報を、所定の周期で配送管理サーバ３００に送信する。送信は、例えば、車室内の荷物が増減したと推定できるタイミングで行うようにしてもよい。例えば、車両１０のドアやゲートが閉められるごとに実行してもよい。
【００８２】
第二の実施形態では、記憶部３０２に、既存荷物のサイズに関する情報（既存荷物情報）が記憶される。また、配送管理サーバ３００が、車両１０から情報を取得した場合に、記憶されている既存荷物情報を更新する。図８は既存荷物情報の例である。また、ステップＳ１２４において、既存荷物のサイズを加味して、新規に配送される荷物の格納可否を判定する。
【００８３】
このように、第二の実施形態によると、車両１０の車室内に荷物が存在する場合であっても、新た荷物が格納可能であるかを判定できるようになる。
【００８４】
なお、図８の例では、既存荷物情報を単一のレコードで表したが、車室内に複数の荷物があることが推定される場合、荷物ごとに複数のレコードを生成してもよい。また、複数の既存荷物を考慮して、新規に配送される荷物の格納可否を判定してもよい。
また、ステップＳ１２４において、既存荷物の置き場所や向きを変更することで新規の荷物が格納できるようになるか否かを判定するようにしてもよい。
【００８５】
（第三の実施形態）
第二の実施形態では、車室内をセンシングした結果に基づいて既存荷物のサイズを検出したが、車室内に私物が置かれていない場合、荷物の配送履歴に基づいて既存荷物のサイズを取得することができる。第三の実施形態は、車室内に私物が置かれていないことを前提とし、荷物の配送履歴に基づいて既存荷物を推定する実施形態である。
【００８６】
第三の実施形態では、車両１０に荷物が配送されたタイミング（例えば、ステップＳ３４で配送管理サーバ３００に施錠を通知したタイミング）で、配送管理サーバ３００が、当該荷物が格納されたものと推定して、図８に示した既存荷物情報（本発明における格納履歴に相当）を更新する。かかる形態によると、車室内をセンシングする手段を設けることなく、既に存在する荷物の影響を考慮して格納可否判定を行うことができる。
【００８７】
なお、第三の実施形態では、車室内のセンシングを行わないため、配送管理サーバ３００は、車室内にある荷物が取り出されたことを把握することができない。そこで、荷受人が所持する端末（以下、荷受人端末）から、荷物を取り出した旨の情報（本発明における受領情報）を取得するようにしてもよい。例えば、荷受人が車両１０から荷物を取り出す際に、荷受人端末が荷物ＩＤを取得し（例えば、カメラによって、荷物に付された識別用のバーコードを読み取ってもよいし、伝票番号を認識してもよい）、配送管理サーバ３００に送信する。また、配送管理サーバ３００は、対応する荷物が取り出されたものとして、既存荷物情報を更新する。これにより配送管理サーバ３００は、車両１０から荷物が取り出されたことを把握することができる。
【００８８】
（変形例）
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、実施形態の説明では、荷物の保管および施解錠が可能な領域として自動車の車室やトランクを例示したが、必ずしもこれらに限らない。本発明は、携帯端末を用いて施解錠可能な領域を有するものであれば、施設や格納装置など、自動車以外にも適用可能である。
【００８９】
また、実施形態の説明では、荷物および車室のサイズとして縦、横、高さを表す情報を用いたが、荷物および車室のサイズは、これ以外によって表されてもよい。また、荷物が格納可能であるかの判断は、例示した方法以外の既知の方法によって行ってもよい。
【００９０】
また、実施形態の説明では、荷物の配送を行う業者の要求によって配送可否判定を行ったが、これとは異なるタイミングで配送可否判定を行うようにしてもよい。例えば、荷物の配送が依頼されたタイミングや、荷物が配送拠点に到着する前のタイミングにおいて図６に示した処理を実行し、荷物の格納が不可能である場合（ステップＳ１２４で否定判定となった場合）に、その旨を荷受人に通知するようにしてもよい。すなわち、荷物の配送先として車両が指定されているにもかかわらず、荷物の格納が行えない場合、その旨を通知してもよい。これにより、配送方法の変更や、車室内の片付けなどを荷受人に促すことができる。
【符号の説明】
【００９１】
１０・・・車両
１００・・・施解錠装置
１０１，２０１・・・近距離通信部
１０２・・・照合ＥＣＵ
１０３・・・ボディＥＣＵ
１０４・・・ドアロックモータ
１０５，２０２，３０１，４０１・・・通信部
２００・・・携帯端末
２０３，３０２，４０２・・・制御部
３００・・・配送管理サーバ
４００・・・鍵管理サーバ
４０３・・・記憶部
【図１】
2019159644.tif 000003
【図２】
2019159644.tif 000004
【図３】
2019159644.tif 000005
【図４】
2019159644.tif 000006
【図５】
2019159644.tif 000007
【図６】
2019159644.tif 000008
【図７】
2019159644.tif 000009
【図８】
2019159644.tif 000010