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