特許 6879967 運搬システム及び運搬情報提供方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6879967

(24)【登録日】2021年5月7日

(45)【発行日】2021年6月2日

(54)【発明の名称】運搬システム及び運搬情報提供方法

(51)【国際特許分類】

   G06Q 10/08 20120101AFI20210524BHJP

   G06Q 50/06 20120101ALI20210524BHJP

   G01C 21/26 20060101ALI20210524BHJP

   G08G 1/123 20060101ALI20210524BHJP

【ＦＩ】

   G06Q10/08 306

   G06Q50/06

   G01C21/26 A

   G08G1/123 A

【請求項の数】6

【全頁数】19

(21)【出願番号】特願2018-38413(P2018-38413)

(22)【出願日】2018年3月5日

(65)【公開番号】特開2019-153127(P2019-153127A)

(43)【公開日】2019年9月12日

【審査請求日】2020年2月4日

(73)【特許権者】

【識別番号】320011650

【氏名又は名称】大陽日酸株式会社

(74)【代理人】

【識別番号】110001634

【氏名又は名称】特許業務法人 志賀国際特許事務所

(72)【発明者】

【氏名】武藤 智宏

【審査官】 田付 徳雄

(56)【参考文献】

【文献】 特開２００８−０４６８５５（ＪＰ，Ａ）

【文献】 特開２００２−２９７７１２（ＪＰ，Ａ）

【文献】 特開２００４−２３８１４０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００６／００４７４１７（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

Ｇ０１Ｃ ２１／２６

Ｇ０８Ｇ １／１２３

(57)【特許請求の範囲】

【請求項1】

液化ガスを運搬する運搬システムであって、
貨物自動車が運搬しているガス種の情報を少なくとも含む複数の情報に基づいて前記貨物自動車の位置情報を特定する位置情報取得部と、
取得された前記位置情報で特定される現在地から目的地までの到着予測日時を算出する到着予測日時算出部と、
算出された前記到着予測日時と、前記目的地に対して事前に提供している到着予測日時と、前記目的地に対して到着予測日時の情報を提供した回数とを、記憶部に記憶されているデータテーブルに登録する登録部と、
前記データテーブルに登録されている前記目的地に対して事前に提供している到着予測日時と、前記目的地に対して到着予測日時の情報を提供した回数とを用いて、到着予測日時の情報提供の要否を判定する判定部と、
前記判定部により前記情報提供が必要であると判定された場合に、前記貨物自動車が運搬している前記ガス種及び前記目的地への到着予測日時を前記目的地に提供する提供部と、
を備える運搬システム。

【請求項2】

前記提供部は、前記到着予測日時算出部によって算出された到着予測日時と、前記目的地に対して事前に提供している到着予測日時との差が所定の閾値を超える場合には前記貨物自動車が遅延もしくは早着する旨を示す情報を提供する、請求項１に記載の運搬システム。

【請求項3】

前記提供部は、同一の目的地に対して複数の貨物自動車が、同一の日に同じガス種もしくは異なるガス種を運搬する場合において、前記ガス種と前記到着予測日時とを組み合わせて提供する、請求項１または２に記載の運搬システム。

【請求項4】

前記提供部は、前記目的地と前記貨物自動車の両方に対して前記ガス種と前記到着予測日時とを提供する、請求項１から３のいずれか一項に記載の運搬システム。

【請求項5】

前記提供部は、前記目的地に対して事前に到着予測日時を提供していない場合、算出された前記到着予測日時を、前記貨物自動車の前記目的地への到着予測日時として提供する、請求項１から４のいずれか一項に記載の運搬システム。

【請求項6】

液化ガスを運搬する運搬システムにおける運搬情報提供方法であって、
貨物自動車が運搬しているガス種の情報を少なくとも含む複数の情報に基づいて前記貨物自動車の位置情報を特定する位置情報取得ステップと、
取得された前記位置情報で特定される現在地から目的地までの到着予測日時を算出する到着予測日時算出ステップと、
算出された前記到着予測日時と、前記目的地に対して事前に提供している到着予測日時と、前記目的地に対して到着予測日時の情報を提供した回数とを、記憶部に記憶されているデータテーブルに登録する登録ステップと、
前記データテーブルに登録されている前記目的地に対して事前に提供している到着予測日時と、前記目的地に対して到着予測日時の情報を提供した回数とを用いて、到着予測日時の情報提供の要否を判定する判定ステップと、
前記判定ステップにおいて前記情報提供が必要であると判定された場合に、前記貨物自動車が運搬している前記ガス種及び前記目的地への到着予測日時を前記目的地に提供する提供ステップと、
を有する運搬情報提供方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、運搬システム及び運搬情報提供方法に関する。

【背景技術】

【0002】

従来、酸素や窒素等の低温液化ガスは、液体状態で保冷されたタンクローリーのような貨物自動車の積荷に格納されて運搬されている（例えば、特許文献１参照）。このような貨物自動車の引き入れ時には、法規制により納入先のお客様の立ち合いが必要となる。しかしながら、納入先のお客様は、立ち合い以外にも普段の業務があるため時間に余裕があるわけではない。そのため、納入先のお客様としても、貨物自動車がいつ到着するのかを把握しておきたい要望がある。そこで、低温液化ガスの注文時にお客様から納入の時間が指定される場合がある。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１３−１８９２８９号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ところで、低温液化ガスの配送においては、効率化のために、１回の配送で複数のお客様に対して納入することがある。それぞれのお客様から納入の時間が指定されている場合、遅延が起こらないように時間に余裕をもって納入先に向かう必要がある。そのため、運搬時の制限が多くなってしまい、時間が指定されていない場合に比べて運搬できるお客様の数が少なくなってしまう場合がある。
一方、納入の時間が指定されていない場合であっても、お客様から到着時間について問い合わせを受けることがある。この場合、貨物自動車の運転手に対して到着予定の時間を確認することになり、結果として運転手を急かしてしまうことになると、安全上の観点から好ましくない。以上のように、従来の運搬の方法では、効率的に運搬ができないという問題があった。

【0005】

上記事情に鑑み、本発明は、効率的に運搬することができる技術の提供を目的としている。

【課題を解決するための手段】

【0006】

本発明の一態様は、液化ガスを運搬する運搬システムであって、貨物自動車が運搬しているガス種の情報を少なくとも含む複数の情報に基づいて前記貨物自動車の位置情報を特定する位置情報取得部と、取得された前記位置情報で特定される現在地から目的地までの到着予測日時を算出する到着予測日時算出部と、算出された前記到着予測日時と、前記目的地に対して事前に提供している到着予測日時と、前記目的地に対して到着予測日時の情報を提供した回数とを、記憶部に記憶されているデータテーブルに登録する登録部と、前記データテーブルに登録されている前記目的地に対して事前に提供している到着予測日時と、前記目的地に対して到着予測日時の情報を提供した回数とを用いて、到着予測日時の情報提供の要否を判定する判定部と、前記判定部により前記情報提供が必要であると判定された場合に、前記貨物自動車が運搬している前記ガス種及び前記目的地への到着予測日時を前記目的地に提供する提供部と、を備える運搬システムである。

【0007】

本発明の一態様は、上記の運搬システムであって、前記提供部は、前記到着予測日時算出部によって算出された到着予測日時と、前記目的地に対して事前に提供している到着予測日時との差が所定の閾値を超える場合には前記貨物自動車が遅延もしくは早着する旨を示す情報を提供する。

【0008】

本発明の一態様は、上記の運搬システムであって、前記提供部は、同一の目的地に対して複数の貨物自動車が、同一の日に同じガス種もしくは異なるガス種を運搬する場合において、前記ガス種と前記到着予測日時とを組み合わせて提供する。

【0009】

本発明の一態様は、上記の運搬システムであって、前記提供部は、前記目的地と前記貨物自動車の両方に対して、前記ガス種と前記到着予測日時とを提供する。

【0010】

本発明の一態様は、上記の運搬システムであって、前記提供部は、前記目的地に対して事前に到着予測日時を提供していない場合、算出された前記到着予測日時を、前記貨物自動車の前記目的地への到着予測日時として提供する。

【0011】

本発明の一態様は、液化ガスを運搬する運搬システムにおける運搬情報提供方法であって、貨物自動車が運搬しているガス種の情報を少なくとも含む複数の情報に基づいて前記貨物自動車の位置情報を特定する位置情報取得ステップと、取得された前記位置情報で特定される現在地から目的地までの到着予測日時を算出する到着予測日時算出ステップと、算出された前記到着予測日時と、前記目的地に対して事前に提供している到着予測日時と、前記目的地に対して到着予測日時の情報を提供した回数とを、記憶部に記憶されているデータテーブルに登録する登録ステップと、前記データテーブルに登録されている前記目的地に対して事前に提供している到着予測日時と、前記目的地に対して到着予測日時の情報を提供した回数とを用いて、到着予測日時の情報提供の要否を判定する判定ステップと、前記判定ステップにおいて前記情報提供が必要であると判定された場合に、前記貨物自動車が運搬している前記ガス種及び前記目的地への到着予測日時を前記目的地に提供する提供ステップと、を有する運搬情報提供方法である。

【発明の効果】

【0012】

本発明により、効率的に運搬することが可能となる。

【図面の簡単な説明】

【0013】

【図1】運搬システムの構成を表すシステム構成図である。

【図2】本実施形態における運行管理システムの機能構成を表す概略ブロック図である。

【図3】本実施形態におけるサーバの機能構成を表す概略ブロック図である。

【図4】本実施形態における顧客向けサーバの機能構成を表す概略ブロック図である。

【図5】データ記憶部が記憶するデータテーブルの一例を示す図である。

【図6】通常時における運搬システムの処理の流れを説明するための図である。

【図7】通常メールの一例を示す図である。

【図8】遅延時における運搬システムの処理の流れを説明するための図である。

【図9】遅延メールの一例を示す図である。

【図10】顧客向けサーバの処理の流れを示すフローチャートである。

【発明を実施するための形態】

【0014】

以下、本発明の一実施形態を、図面を参照しながら説明する。
図１は、運搬システム１００の構成を表すシステム構成図である。
運搬システム１００は、運行管理システム１０、サーバ２０及び顧客向けサーバ３０を備える。運行管理システム１０と、サーバ２０との間及びサーバ２０と、顧客向けサーバ３０との間は、ネットワークを介して通信可能に接続され、データ連携が行われる。ネットワークは、どのように構成されたネットワークであってもよい。例えば、ネットワークは、インターネットである。データ連携とは、異なる装置やシステム間でデータを共有することを意味する。

【0015】

運行管理システム１０は、貨物自動車４０の運行を管理するシステムである。具体的には、運行管理システム１０は、貨物自動車４０を所有する配送会社によって登録された運行計画と、貨物自動車４０から得られる貨物自動車４０の位置情報とに基づいて、貨物自動車４０の現在地から目的地までの到着予測日時を算出し、算出した到着予測日時の情報と、運行計画とをサーバ２０との間でデータ連携する。運行計画とは、配送会社によって予め作成される貨物自動車４０の運行に関する計画である。運行計画には、例えば会社・事業者名、貨物自動車４０の種別、貨物自動車４０が運搬しているガス種に関する情報、出発地、目的地、運行計画予測日時等の情報が含まれる。

【0016】

ここで、貨物自動車４０の種別とは、運搬可能なガス種、送液ポンプの有無、最大積載量、貨物自動車４０が搭載している装備についての情報を含む。ガス種とは、窒素、酸素等のガスの名称、ガスの純度、ガスに含まれる不純物と含有量などを含む。また、ガス種の情報とは、運搬される低温液化ガスに関する情報である。例えば、低温液化ガスの種類に関したものであれば、窒素、酸素、アルゴン、二酸化炭素、水素等である。また、ガスの種類が同じであっても、例えば、ガスの純度や、含まれる不純物の種類と量など、お客様から予め指定されているガス種の情報が含まれる場合もある。運行計画予測日時は、貨物自動車４０がお客様の場所（目的地）に到着する日時として、事前に配送会社によって決められた日時を表す。

【0017】

また、運行管理システム１０は、貨物自動車４０の位置情報、貨物自動車４０が運搬している積荷の積載量情報等の情報もサーバ２０との間でデータ連携する。運行管理システム１０は、例えばパーソナルコンピュータ等の情報処理装置を用いて構成される。運行管理システム１０は、貨物自動車４０から得られる情報と、運行計画に含まれる会社・事業者名、貨物自動車４０の種別及びガス種の少なくとも２種類以上が一致する運行計画のうち、所定の時間後（例えば、３０分後）に目的地（お客様の場所）に到着予定の運行計画をデータ連携の対象とする。なお、運行管理システム１０は、いわゆるカーナビゲーションシステムで、その一部が代用されてもよい。

【0018】

サーバ２０は、運行管理システム１０との間でデータ連携により共有される情報を顧客向けサーバ３０との間でデータ連携する。また、サーバ２０は、お客様からガス種の注文を受け付け、受け付けた注文に応じて、配送会社に配送を依頼する。サーバ２０は、例えばパーソナルコンピュータ等の情報処理装置を用いて構成される。
顧客向けサーバ３０は、サーバ２０との間でデータ連携により共有される情報に基づいて、貨物自動車４０の到着予測日時に関する情報をお客様に提供する。例えば、顧客向けサーバ３０は、貨物自動車４０の到着予測日時に関する情報を、メール又はお客様専用のマイページにて提供する。顧客向けサーバ３０は、例えばパーソナルコンピュータ等の情報処理装置を用いて構成される。

【0019】

貨物自動車４０は、酸素や窒素等の低温液化ガスを、液体状態で格納する容器を運搬するための車両である。貨物自動車４０は、例えば、タンクローリーである。貨物自動車４０は、車載端末、ＧＰＳ（Global Positioning System）及びＬＩ（Load Indicator）を備える。車載端末は、運転手に対して目的地までの経路やサーバ２０から得られる情報を提供する。ＧＰＳは、貨物自動車４０の位置情報を取得する。車載端末は、貨物自動車４０のＧＰＳによって取得された位置情報と、会社・事業者名、貨物自動車４０の種別及び貨物自動車４０が運搬しているガス種に関する情報とを運行管理システム１０に送信する。ＬＩは、車載式重量計であり、貨物自動車４０が運搬している積荷の重量を計測し、計測結果を積載量である重量情報として運行管理システム１０に送信する。

【0020】

図２は、本実施形態における運行管理システム１０の機能構成を表す概略ブロック図である。運行管理システム１０は、バスで接続されたＣＰＵ（Central Processing Unit）やメモリや補助記憶装置などを備え、プログラムを実行する。プログラムの実行によって、運行管理システム１０は、取得部１１、記憶部１２、到着予測日時算出部１３、データ連携部１４を備える装置として機能する。なお、運行管理システム１０の各機能の全て又は一部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＰＬＤ（Programmable Logic Device）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを用いて実現されてもよい。また、プログラムは、コンピュータ読み取り可能な記録媒体に記録されてもよい。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。また、プログラムは、電気通信回線を介して送受信されてもよい。

【0021】

取得部１１は、各種情報を取得する。具体的には、取得部１１は、運行計画と、貨物自動車に関する情報（以下「貨物自動車情報」という。）とを取得する。貨物自動車に関する情報は、例えば、位置情報、積載量情報、会社・事業者名、貨物自動車４０の種別及び貨物自動車４０が運搬しているガス種に関する情報等である。

【0022】

取得部１１は、貨物自動車情報を貨物自動車４０から取得する。なお、取得部１１は、他の方法で貨物自動車情報を取得してもよい。例えば、取得部１１は、配送会社の社員が運行管理システム１０を直接操作して入力した貨物自動車情報を取得してもよいし、配送会社の社員が他の通信装置（例えば、タブレット端末、パーソナルコンピュータ等の情報処理装置）を運行管理システム１０に接続して他の通信装置から入力された貨物自動車情報を取得してもよいし、クラウド上のサーバに保存された貨物自動車情報を取得してもよい。また、取得部１１は、配送会社が所持している端末装置から入力によって運行計画を取得する。

【0023】

記憶部１２は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。記憶部１２は、各種情報を記憶する。具体的には、記憶部１２は、取得部１１によって取得された運行計画１２１及び貨物自動車情報１２２と、地図情報１２３とを記憶する。地図情報１２３は、予め運行管理システム１０に記憶されていてもよい。

【0024】

到着予測日時算出部１３は、記憶部１２に記憶されている情報に基づいて到着予測日時を算出する。具体的には、まず到着予測日時算出部１３は、運行計画１２１と、貨物自動車情報１２２に含まれる位置情報と、地図情報１２３とに基づいて、貨物自動車４０の現在地から目的地までのルートを決定する。なお、到着予測日時算出部１３は、現在地から目的地まで幹線道路で向かうことができるルートを決定する。次に、到着予測日時算出部１３は、決定したルートの距離と、予め設定された貨物自動車４０の速度とに基づいて目的地までの時間を算出する。そして、到着予測日時算出部１３は、算出した時間を、現在の時刻に加算することによって到着予測日時を算出する。

【0025】

データ連携部１４は、到着予測日時算出部１３によって算出された到着予測日時の情報と、記憶部１２に記憶されている情報（例えば、運行計画１２１及び貨物自動車情報１２２）とをサーバ２０との間で共有する。

【0026】

図３は、本実施形態におけるサーバ２０の機能構成を表す概略ブロック図である。サーバ２０は、バスで接続されたＣＰＵやメモリや補助記憶装置などを備え、プログラムを実行する。プログラムの実行によって、サーバ２０は、取得部２１、記憶部２２、データ連携部２３を備える装置として機能する。なお、サーバ２０の各機能の全て又は一部は、ＡＳＩＣやＰＬＤやＦＰＧＡ等のハードウェアを用いて実現されてもよい。また、プログラムは、コンピュータ読み取り可能な記録媒体に記録されてもよい。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。また、プログラムは、電気通信回線を介して送受信されてもよい。

【0027】

取得部２１は、各種情報を取得する。具体的には、取得部２１は、運行管理システム１０によって共有された情報と、お客様からの注文情報とを取得する。
記憶部２２は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。記憶部２２は、取得部２１によって取得された情報を記憶する。例えば、記憶部２２は、運行管理システム１０によって共有された情報（到着予測日時の情報と、運行計画１２１及び貨物自動車情報１２２）と、お客様からの注文情報とを記憶する。

【0028】

データ連携部２３は、記憶部２２に記憶されている情報を顧客向けサーバ３０との間で共有する。具体的には、データ連携部２３は、運行管理システム１０によって共有された情報を顧客向けサーバ３０との間で共有する。

【0029】

図４は、本実施形態における顧客向けサーバ３０の機能構成を表す概略ブロック図である。顧客向けサーバ３０は、バスで接続されたＣＰＵやメモリや補助記憶装置などを備え、プログラムを実行する。プログラムの実行によって、顧客向けサーバ３０は、取得部３１、データ登録部３２、データ記憶部３３、メール生成部３４、メール送信部３５、画面提供部３６を備える装置として機能する。なお、顧客向けサーバ３０の各機能の全て又は一部は、ＡＳＩＣやＰＬＤやＦＰＧＡ等のハードウェアを用いて実現されてもよい。また、プログラムは、コンピュータ読み取り可能な記録媒体に記録されてもよい。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。また、プログラムは、電気通信回線を介して送受信されてもよい。

【0030】

取得部３１は、サーバ２０によって共有された情報を取得する。
データ登録部３２は、取得部３１によって取得された情報に基づいて、データを登録することによってデータテーブルを生成する。

【0031】

図５は、データ記憶部３３が記憶するデータテーブルの一例を示す図である。
データテーブルは、お客様に関する情報を表すレコードを複数有する。レコードは、会社・事業所、ガス名、運行計画予測日時、到着予測日時、送信到着予測日時、送信状態及び送信回数の各値を有する。会社・事業所の値は、貨物自動車４０の目的地となるお客様の会社・事業所を表す。ガス名の値は、貨物自動車４０が運搬しているガス種の名称を表す。ガス名は、例えばＬＯ（Liquid Oxygen：液体酸素）、ＬＮ（Liquid Nitrogen：液体窒素）等である。到着予測日時の値は、運行管理システム１０において算出された貨物自動車４０がお客様の場所に到着する予測日時を表す。

【0032】

送信到着予測日時の値は、貨物自動車４０がお客様の場所に到着する予測日時としてお客様に対して提供した日時を表す。送信状態の値は、お客様に対するメールの送信状態を表す。送信状態は、例えば０、１及び２のいずれかで表される。送信状態の“０”は、お客様に対してメールを１度も送信していないことを表す。送信状態の“１”は、お客様に対して通常メールを送信したことを表す。送信状態の“２”は、お客様に対して遅延メールを送信したことを表す。送信回数の値は、お客様に対してメールの送信を行った合計の回数を表す。なお、お客様に対してメールの送信が行われていない場合には、送信到着予測日時の値は登録されない。

【0033】

図５において、データテーブルの最上段に登録されているレコードは、会社・事業所の値が“○○事業所”、ガス名の値が“ガスＡ”、運行計画予測日時の値が“２０ＸＸ／ＹＹ／ＺＺ １０：００”、到着予測日時の値が“２０ＸＸ／ＹＹ／ＺＺ １０：００”、送信到着予測日時の値が“２０ＸＸ／ＹＹ／ＺＺ １０：００”、送信状態の値が“１（通常）”、送信回数の値が“１”である。すなわち、“○○事業所”には“ガスＡ”が運搬され、運行計画予測日時が“２０ＸＸ／ＹＹ／ＺＺ １０：００”であり、到着予測日時が“２０ＸＸ／ＹＹ／ＺＺ １０：００”であり、送信到着予測日時が“２０ＸＸ／ＹＹ／ＺＺ １０：００”であり、お客様に対して通常メールを送信しており、お客様に対して合計１回のメールを送信したことが表されている。

【0034】

また、図５において、データテーブルの２段目に登録されているレコードは、会社・事業所の値が“△△事業所”、ガス名の値が“ガスＢ”、運行計画予測日時の値が“２０ＸＸ／ＹＹ／ＺＺ １０：００”、到着予測日時の値が“２０ＸＸ／ＹＹ／ＺＺ １０：４０”、送信到着予測日時の値が“２０ＸＸ／ＹＹ／ＺＺ １０：２０”、送信状態の値が“２（遅延）”、送信回数の値が“２”である。すなわち、“△△事業所”には“ガスＢ”が運搬され、運行計画予測日時が“２０ＸＸ／ＹＹ／ＺＺ １０：００”であり、到着予測日時が“２０ＸＸ／ＹＹ／ＺＺ １０：４０”であり、送信到着予測日時が“２０ＸＸ／ＹＹ／ＺＺ １０：２０”であり、お客様に対して遅延メールを送信しており、お客様に対して合計２回のメールを送信したことが表されている。

【0035】

また、図５において、データテーブルの３段目に登録されているレコードは、会社・事業所の値が“□□事業所”、ガス名の値が“ガスＣ”、運行計画予測日時の値が“２０ＸＸ／ＹＹ／ＺＺ １０：００”、到着予測日時の値が“２０ＸＸ／ＹＹ／ＺＺ １０：００”、送信到着予測日時の値が“−”、送信状態の値が“０（未）”、送信回数の値が“０”である。すなわち、“□□事業所”には“ガスＣ”が運搬され、運行計画予測日時が“２０ＸＸ／ＹＹ／ＺＺ １０：００”であり、到着予測日時が“２０ＸＸ／ＹＹ／ＺＺ １０：００”であり、“□□事業所”にはメールを一度も送信していないことが表されている。

【0036】

図４に戻って、顧客向けサーバ３０の説明を続ける。
データ記憶部３３は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。データ記憶部３３は、データ登録部３２によって生成されたデータテーブルを記憶する。
メール生成部３４は、データテーブルに基づいて、お客様に送信するメールを生成する。具体的には、メール生成部３４は、データテーブルの送信到着予定日時の項目を参照し、送信到着予定日時の項目に値が登録されておらず、かつ、送信回数が０の場合には通常メールを生成する。通常メールとは、お客様に対して貨物自動車４０の到着が近いことを通知するためのメールである。一方、メール生成部３４は、データテーブルの到着予測日時の項目と、送信到着予測日時の項目を参照し、到着予測日時と、送信到着予測日時との差が、所定の閾値を超えている場合であって、貨物自動車４０の遅延が生じている場合には遅延メールを生成する。より具体的には、メール生成部３４は、到着予測日時が送信到着予測日時に比べて所定の閾値を超えて日時が過ぎている場合に、貨物自動車４０の遅延が生じていると判断し、遅延メールを生成する。遅延メールとは、お客様に対して貨物自動車４０の到着が遅れていることを通知するためのメールである。ここで、所定の閾値は、例えば１５分である。なお、メール生成部３４は、到着予測日時と、送信到着予測日時との差が、所定の閾値以下であって、かつ、送信回数が１以上の場合にはメールを生成しない。

【0037】

メール送信部３５は、メール生成部３４によって生成されたメールをお客様に送信する。メール送信部３５は、提供部の一具体例である。
画面提供部３６は、お客様からの要求に応じて、お客様に対して提供する画面データを生成し、生成した画面データをお客様に提供する。画面提供部３６は、提供部の一具体例である。
こうして、お客様に対してメールが送信された場合、もしくは、お客様に対して画面提供部３６による画面データが提供された場合、貨物自動車４０の車載端末に同内容の情報が表示される。例えば、メール送信部３５及び画面提供部３６のいずれかは、お客様に対してメールを送信した場合、もしくは、お客様に対して画面提供部３６による画面データを提供した場合、サーバ２０を介して貨物自動車４０に対してガス種と到着予測日時とを提供する。これにより、貨物自動車４０の車載端末には、ガス種と到着予測日時とが表示される。このような表示により、貨物自動車４０の運転者は、貨物自動車４０の運行状況がお客様に提供されていることを確認することができ、安心して運搬に注力することができる。

【0038】

次に、図６〜図９を用いて、運搬システム１００の処理の流れについて説明する。
図６は、通常時における運搬システム１００の処理の流れを説明するための図である。図７は、通常メールの一例を示す図である。図８は、遅延時における運搬システム１００の処理の流れを説明するための図である。図９は、遅延メールの一例を示す図である。ここで、通常時とは、到着予定日時が所定の閾値を超えない場合、すなわち貨物自動車４０のお客様への到着に遅延が生じていない場合である。ここで、遅延時とは、到着予定日時が所定の閾値を超えている場合、すなわち貨物自動車４０のお客様への到着に遅延が生じている場合である。

【0039】

なお、図６及び図８の説明では、運行計画予測日時が“１１：００”であり、所定の閾値が１５分であり、運行計画予測日時の３０分前から５分毎にメール送信の有無の判定が行われるものとする。また、図６及び図８の説明では、説明の簡単化のため必要な部分のみ説明する。

【0040】

図６に示すように、配送会社より“１１：００”にお客様の場所に到着することを示す運行計画が、前日に運行管理システム１０に登録されたとする。運行管理システム１０は、運行計画で示される運行計画予測日時“１１：００”と、到着予測日時“１１：００”とをサーバ２０にデータ連携する。なお、前日には貨物自動車４０は実際に走行していないため、運行管理システム１０は運行計画予測日時と同じ日時の情報を到着予測日時とする。また、サーバ２０は、運行管理システム１０によりデータ連携された情報を顧客向けサーバ３０にデータ連携する。

【0041】

顧客向けサーバ３０のデータ登録部３２は、サーバ２０によりデータ連携された情報に基づいて、データテーブルのレコードを生成する。具体的には、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：００”）を対応する項目に登録することによって、データテーブルのレコードを生成する。なお、前日にはメールの送信は行われていないため、顧客向けサーバ３０のデータ登録部３２は初期状態としてデータテーブルの送信状態及び送信回数を“０”とする。

【0042】

運行管理システム１０の到着予測日時算出部１３は、運行計画予測日時“１１：００”の３０分前になると、貨物自動車４０の位置情報と、地図情報とに基づいて到着予測日時を算出する。ここでは、到着予測日時が“１１：０１”であるとする。そして、データ連携部１４は、運行計画で示される運行計画予測日時“１１：００”と、到着予測日時“１１：０１”とをサーバ２０にデータ連携する。サーバ２０は、運行管理システム１０によりデータ連携された情報を顧客向けサーバ３０にデータ連携する。

【0043】

顧客向けサーバ３０のデータ登録部３２は、データテーブルのレコードを参照し、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：０１”）を対応する項目に登録することによって、データテーブルのレコードを更新する。例えば、図６に示す例では、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：０１”）で、対応するデータテーブルの運行計画予測日時及び到着予測日時の値を更新する。

【0044】

その後、メール生成部３４は、データテーブルのレコードの到着予測日時と、送信到着予測日時と、送信回数とを参照し、メール生成の有無を判定する。“１０：３０”（到着予測３０分前）に示す例では、データテーブルのレコードの送信到着予測日時が“−”であり、送信回数が“０”である。そのため、メール生成部３４は、通常メールを生成すると判定する。メール生成部３４は、図７に示すような通常メールを生成して、メール送信部３５に出力する。図７に示すように、通常メール５０には、お客様に対する情報として、貨物自動車４０がもうすぐ到着する旨を示す情報と、ガス名と、到着予測日時の情報が含まれる。メール送信部３５は、通常メールをお客様に送信する。その後、メール送信部３５は、通常メールを送信した旨をデータ登録部３２に通知する。

【0045】

図６に戻って説明を続ける。
データ登録部３２は、メール送信部３５による通知に基づいてデータテーブルのレコードを更新する。具体的には、データ登録部３２は、データテーブルの送信到着予測日時の項目に通常メールに記載の到着予測日時を登録することによって更新し、送信状態を“１（通常）”に更新し、送信回数を“１”に更新する。

【0046】

運行管理システム１０の到着予測日時算出部１３は、さらに５分が経過すると、すなわち運行計画予測日時“１１：００”の２５分前になると、貨物自動車４０の位置情報と、地図情報とに基づいて到着予測日時を算出する。ここでは、到着予測日時が“１１：１６”であるとする。そして、データ連携部１４は、運行計画で示される運行計画予測日時“１１：００”と、到着予測日時“１１：１６”とをサーバ２０にデータ連携する。サーバ２０は、運行管理システム１０によりデータ連携された情報を顧客向けサーバ３０にデータ連携する。

【0047】

顧客向けサーバ３０のデータ登録部３２は、サーバ２０によりデータ連携された情報に基づいて、データテーブルのレコードを生成する。具体的には、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：１６”）を対応する項目に登録することによって、データテーブルのレコードを生成する。なお、データ登録部３２は、会社・事業所、ガス名及び運行計画予測日時が一致するレコードが既にデータテーブルにある場合には、既に登録されているレコードに上書きすることによってデータを更新する。例えば、図６に示す例では、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：１６”）で、対応するデータテーブルの運行計画予測日時及び到着予測日時の値を更新する。

【0048】

その後、メール生成部３４は、データテーブルのレコードの到着予測日時と、送信到着予測日時と、送信回数とを参照し、メール生成の有無を判定する。“１０：３５”に示す例では、データテーブルのレコードの到着予測日時が“１１：１６”であり、送信到着予測日時が“１１：０１”であり、送信回数が“１”である。この場合、到着予測日時と、送信到着予測日時との差が１５分以内であり、かつ、送信回数が１回以上であるため、メール生成部３４はメールを生成する必要が無いと判定する。

【0049】

運行管理システム１０の到着予測日時算出部１３は、さらに５分が経過すると、すなわち、運行計画予測日時“１１：００”の２０分前になると、貨物自動車４０の位置情報と、地図情報とに基づいて到着予測日時を算出する。ここでは、到着予測日時が“１１：１７”であるとする。そして、データ連携部１４は、運行計画で示される運行計画予測日時“１１：００”と、到着予測日時“１１：１７”とをサーバ２０にデータ連携する。サーバ２０は、運行管理システム１０によりデータ連携された情報を顧客向けサーバ３０にデータ連携する。

【0050】

顧客向けサーバ３０のデータ登録部３２は、サーバ２０によりデータ連携された情報に基づいて、データテーブルのレコードを生成する。具体的には、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：１７”）を対応する項目に登録することによって、データテーブルのレコードを生成する。なお、データ登録部３２は、会社・事業所、ガス名及び運行計画予測日時が一致するレコードが既にデータテーブルにある場合には、既に登録されているレコードに上書きすることによってデータを更新する。例えば、図７に示す例では、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：１７”）で、対応するデータテーブルの運行計画予測日時及び到着予測日時の値を更新する。

【0051】

その後、メール生成部３４は、データテーブルのレコードの到着予測日時と、送信到着予測日時と、送信回数とを参照し、メール生成の有無を判定する。“１０：４０”に示す例では、データテーブルのレコードの到着予測日時が“１１：１７”であり、送信到着予測日時が“１１：０１”であり、送信回数が“１”である。この場合、到着予測日時“１１：１７”と、送信到着予測日時“１１：０１”との差が１５分を超えている。そのため、メール生成部３４は、遅延メールを生成すると判定する。メール生成部３４は、図９に示すような遅延メールを生成して、メール送信部３５に出力する。図９に示すように、遅延メール６０には、お客様に対する情報として、貨物自動車４０が遅れている旨を示す情報と、ガス名と、新しい到着予測日時の情報が含まれる。メール送信部３５は、遅延メールをお客様に送信する。その後、メール送信部３５は、遅延メールを送信した旨をデータ登録部３２に通知する。

【0052】

データ登録部３２は、メール送信部３５による通知に基づいてデータテーブルのレコードを更新する。具体的には、データ登録部３２は、データテーブルの送信到着予測日時の項目に遅延メールに記載の新しい到着予測日時を登録することによって更新し、送信状態を“２（遅延）”に更新し、送信回数を“２”に更新する。

【0053】

運行管理システム１０の到着予測日時算出部１３は、さらに５分が経過すると、すなわち運行計画予測日時“１１：００”の２５分前になると、貨物自動車４０の位置情報と、地図情報とに基づいて到着予測日時を算出する。ここでは、到着予測日時が“１１：１６”であるとする。そして、データ連携部１４は、運行計画で示される運行計画予測日時“１１：００”と、到着予測日時“１１：１６”とをサーバ２０にデータ連携する。サーバ２０は、運行管理システム１０によりデータ連携された情報を顧客向けサーバ３０にデータ連携する。

【0054】

顧客向けサーバ３０のデータ登録部３２は、サーバ２０によりデータ連携された情報に基づいて、データテーブルのレコードを生成する。具体的には、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：１６”）を対応する項目に登録することによって、データテーブルのレコードを生成する。なお、データ登録部３２は、会社・事業所、ガス名及び運行計画予測日時が一致するレコードが既にデータテーブルにある場合には、既に登録されているレコードに上書きすることによってデータを更新する。例えば、図６に示す例では、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：１６”）で、対応するデータテーブルの運行計画予測日時及び到着予測日時の値を更新する。

【0055】

その後、メール生成部３４は、データテーブルのレコードの到着予測日時と、送信到着予測日時と、送信回数とを参照し、メール生成の有無を判定する。“１０：３５”に示す例では、データテーブルのレコードの到着予測日時が“１１：１６”であり、送信到着予測日時が“１１：０１”であり、送信回数が“１”である。この場合、到着予測日時“１１：１６”と、送信到着予測日時“１１：０１”との差が１５分以内であり、かつ、送信回数が１回以上であるため、メール生成部３４はメールを生成する必要が無いと判定する。

【0056】

次に、図８を用いて説明する。運行管理システム１０の到着予測日時算出部１３は、さらに５分が経過すると、すなわち、運行計画予測日時“１１：００”の１５分前になると、貨物自動車４０の位置情報と、地図情報とに基づいて到着予測日時を算出する。ここでは、到着予測日時が“１１：３２”であるとする。そして、データ連携部１４は、運行計画で示される運行計画予測日時“１１：００”と、到着予測日時“１１：３２”とをサーバ２０にデータ連携する。サーバ２０は、運行管理システム１０によりデータ連携された情報を顧客向けサーバ３０にデータ連携する。

【0057】

顧客向けサーバ３０のデータ登録部３２は、サーバ２０によりデータ連携された情報に基づいて、データテーブルのレコードを生成する。具体的には、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：３２”）を対応する項目に登録することによって、データテーブルのレコードを生成する。なお、データ登録部３２は、会社・事業所、ガス名及び運行計画予測日時が一致するレコードが既にデータテーブルにある場合には、既に登録されているレコードに上書きすることによってデータを更新する。例えば、図８に示す例では、データ登録部３２は、サーバ２０によりデータ連携された情報（例えば、運行計画予測日時“１１：００”と、到着予測日時“１１：３２”）で、対応するデータテーブルの運行計画予測日時及び到着予測日時の値を更新する。

【0058】

その後、メール生成部３４は、データテーブルのレコードの到着予測日時と、送信到着予測日時と、送信回数とを参照し、メール生成の有無を判定する。“１０：４５”に示す例では、データテーブルのレコードの到着予測日時が“１１：３２”であり、送信到着予測日時が“１１：１７”であり、送信回数が“２”である。この場合、到着予測日時と、送信到着予測日時との差が１５分以内であり、かつ、送信回数が１回以上であるため、メール生成部３４はメールを生成する必要が無いと判定する。

【0059】

もしも、到着予測日時と、送信到着予測日時との差が１５分以上である場合、メール生成部３４は、遅延メールを生成すると判定する。メール生成部３４は、遅延メールを生成して、メール送信部３５に出力する。メール送信部３５は、遅延メールをお客様に送信する。その後、メール送信部３５は、遅延メールを送信した旨をデータ登録部３２に通知する。この場合、データ登録部３２は、データテーブルの送信到着予測日時の項目に遅延メールに記載の新しい到着予測日時を登録することによって更新し、送信状態を“２（遅延）”に更新し、送信回数を“３”に更新する。

【0060】

図１０は、顧客向けサーバ３０の処理の流れを示すフローチャートである。なお、図１０の処理は、サーバ２０によってデータ連携がなされて到着予測日時が更新される度に実行される。
メール生成部３４は、データ記憶部３３に記憶されているデータテーブルに基づいて、メールを送信する必要があるか否かを判定する（ステップＳ１０１）。メール生成部３４は、データテーブルのレコードの到着予測日時と、送信到着予測日時と、送信回数とを参照し、送信到着予測日時が未登録、かつ、送信回数が“０”の場合、到着予測日時と、送信到着予測日時との時刻差が所定の閾値を超える場合にメールを送信する必要があると判定する。一方、メール生成部３４は、それ以外の場合にメールを送信する必要がないと判定する。

【0061】

メールを送信する必要がない場合（ステップＳ１０１−ＮＯ）、顧客向けサーバ３０は処理を終了する。
一方、メールを送信する必要がある場合（ステップＳ１０１−ＹＥＳ）、メール生成部３４は通常メール又は遅延メールのいずれのメールを送信するのかを判定する（ステップＳ１０２）。具体的には、メール生成部３４は、送信到着予測日時が未登録、かつ、送信回数が“０”の場合には、通常メールを送信すると判定する。一方、メール生成部３４は、到着予測日時と、送信到着予測日時との時刻差が所定の閾値を超えて遅延する場合には、遅延メールを送信すると判定する。

【0062】

通常メールを送信すると判定した場合（ステップＳ１０２−通常メール）、メール生成部３４は通常メールを生成する（ステップＳ１０３）。メール生成部３４は、生成した通常メールを、メール送信部３５に出力する。メール送信部３５は、生成された通常メールをお客様に送信する。

【0063】

一方、遅延メールを送信すると判定した場合（ステップＳ１０２−遅延メール）、メール生成部３４は遅延メールを生成する（ステップＳ１０５）。メール生成部３４は、生成した遅延メールを、メール送信部３５に出力する。メール送信部３５は、生成された遅延メールをお客様に送信する（ステップＳ１０６）。

【0064】

以上のように構成された運搬システム１００によれば、効率的な運搬が可能になる。具体的には、運搬システム１００では、運行計画に示されている到着予測日時から所定の時間前になると、お客様に対して通常メールを送信する。その後、運搬システム１００は、所定の間隔で、貨物自動車４０の位置情報に基づいて得られる目的地への到着予測日時と、通常メールにてお客様に対して提供している到着予測日時との差に基づいてメールの送信の有無を判定する。もし、貨物自動車４０の位置情報に基づいて得られる目的地への到着予測日時と、通常メールにてお客様に対して提供している到着予測日時との差が所定の閾値を超える場合には貨物自動車４０が遅延している旨を示す遅延メールをお客様に送信する。したがって、お客様は貨物自動車４０がどのくらいの時刻に到着するのかを把握することができる。これにより、お客様からの問い合わせを減少させることができる。その結果、貨物自動車４０の運転手に対する確認も必要が無くなる。そのため、効率的な運搬が可能になる。

【0065】

＜変形例＞
運行管理システム１０は、所定の期間（例えば、運行計画１２１の当日や前日）分の運行計画１２１を保持し、所定の期間以外（例えば、前々日以前）の運行計画１２１を削除するように構成されてもよい。
一般的に、ガス種に応じて運搬できる貨物自動車４０が限定される、又は、貨物自動車４０の車種が指定される場合がある。そこで、サーバ２０は、お客様から注文が入った場合に、お客様からの注文されたガス種、お客様からの注文された貨物自動車４０の車種及び資格のいずれかを条件として、運行計画を作成するように配送会社に依頼してもよい。そして、サーバ２０は、条件を満たす運行計画を作成した配送会社に依頼する。これにより、依頼がなされた配送会社は、運行計画を運行管理システム１０に登録し、運行管理システム１０によりデータ連携がなされる。

【0066】

運行管理システム１０の到着予測日時算出部１３は、貨物自動車４０の位置から目的地までのルートを、同じ目的地への過去のルートを学習することによって到着予測日時を算出するように構成されてもよい。
運行管理システム１０とサーバ２０とは１つのシステムとして構成されてもよい。また、サーバ２０と顧客向けサーバ３０とは１つの装置として構成されてもよい。

【0067】

本実施形態では、顧客向けサーバ３０のメール生成部３４は、貨物自動車４０の目的地への到着が遅れる場合、すなわち貨物自動車４０に遅延が生じている場合に遅延メールを生成する構成を示したが、貨物自動車４０の早着が見込まれる場合には早着メールを生成するように構成されてもよい。早着メールとは、お客様に対して貨物自動車４０の到着が到着予測日時より早まることを通知するためのメールである。このように構成される場合、メール生成部３４は、データテーブルの到着予測日時の項目と、送信到着予測日時の項目を参照し、到着予測日時と、送信到着予測日時との差が、所定の閾値を超えている場合であって、貨物自動車４０が目的地に早着する場合には早着メールを生成する。より具体的には、メール生成部３４は、到着予測日時が送信到着予測日時に比べて所定の閾値を超えて早い場合に、貨物自動車４０が目的地に早着すると判断し、早着メールを生成する。例えば、所定の閾値が１５分であり、到着予測日時が１２時であり、送信到着予測日時が１２時３０分であるとすると、到着予測日時が送信到着予測日時に比べて所定の閾値を超えて早いため、メール生成部３４は早着メールを生成する。メール送信部３５は、生成された早着メールをお客様に送信する。
このように構成されることによって、目的地へ早着する可能性がある場合にもお客様に事前に情報を通知することができる。

【0068】

顧客向けサーバ３０は、お客様に対して遅延メールを送信した場合、遅延メールを送信したことをサーバ２０に通知してもよい。このように構成される場合、顧客向けサーバ３０は、遅延メールを送信したことを示す情報と、遅延メールの送信先であるお客様に関する情報（例えば、会社・事業者名、ガス種、目的地等）とをサーバ２０に通知する。サーバ２０は、顧客向けサーバ３０からの通知に応じて、遅延メールの送信先であるお客様宛の運搬を行っている貨物自動車４０の車載端末に対して遅延メールを送信した旨を通知する。

【0069】

顧客向けサーバ３０は、お客様に対して通常メールを送信した場合、通常メールを送信したことをサーバ２０に通知してもよい。このように構成される場合、顧客向けサーバ３０は、通常メールを送信したことを示す情報と、通常メールの送信先であるお客様に関する情報（例えば、会社・事業者名、ガス種、目的地等）とをサーバ２０に通知する。サーバ２０は、顧客向けサーバ３０からの通知に応じて、通常メールの送信先であるお客様宛の運搬を行っている貨物自動車４０の車載端末に対して通常メールを送信した旨を通知する。

【0070】

顧客向けサーバ３０は、お客様に対して早着メールを送信した場合、早着メールを送信したことをサーバ２０に通知してもよい。このように構成される場合、顧客向けサーバ３０は、早着メールを送信したことを示す情報と、早着メールの送信先であるお客様に関する情報（例えば、会社・事業者名、ガス種、目的地等）とをサーバ２０に通知する。サーバ２０は、顧客向けサーバ３０からの通知に応じて、早着メールの送信先であるお客様宛の運搬を行っている貨物自動車４０の車載端末に対して早着メールを送信した旨を通知する。

【0071】

本実施形態では、メール生成部３４が、送信到着予測日時が未登録、かつ、送信回数が“０”の場合にメールを送信する必要があると判定する構成を示した。しかし、メール生成部３４は、送信到着予測日時が未登録の場合、又は、送信回数が“０”の場合のいずれかが満たされた場合にメールを送信する必要があると判定してもよい。

【0072】

サーバ２０は、貨物自動車４０の遅延の有無を判定するように構成されてもよい。このように構成される場合、サーバ２０は、遅延判定部を備える。遅延判定部は、運行計画に示されている到着予測日時が、運行管理システム１０によって算出された到着予測日時に比べて所定の閾値を超えて日時が過ぎている場合に遅延が発生していると判定する。一方、遅延判定部は、運行計画に示されている到着予測日時と、運行管理システム１０によって算出された到着予測日時との差が閾値以下である場合に遅延が発生していないと判定する。遅延が発生していると判定された場合、サーバ２０は遅延が発生している旨を示す通知を貨物自動車４０の車載端末に送信する。なお、この場合、サーバ２０は、どのくらい遅れて目的地に到着するのかを示す時刻情報を通知に含めて貨物自動車４０の車載端末に送信する。

【0073】

サーバ２０は、貨物自動車４０の早着の有無を判定するように構成されてもよい。このように構成される場合、サーバ２０は、早着判定部を備える。早着判定部は、運行計画に示されている到着予測日時が、運行管理システム１０によって算出された到着予測日時に比べて所定の閾値を超えて早い場合に早着すると判定する。一方、早着判定部は、運行計画に示されている到着予測日時と、運行管理システム１０によって算出された到着予測日時との差が閾値以下である場合に早着しないと判定する。早着すると判定された場合、サーバ２０は早着する旨を示す通知を貨物自動車４０の車載端末に送信する。なお、この場合、サーバ２０は、どのくらい早く目的地に到着するのかを示す時刻情報を通知に含めて貨物自動車４０の車載端末に送信する。

【0074】

＜その他の変形例＞
貨物自動車４０の容器の運搬においては、同一のお客様に対し、同一の日に２以上の貨物自動車４０が液化ガスを運搬する場合も想定される。そのような場合の動作について説明する。
サーバ２０は、所定の期間（例えば、１０分、１５分等）内に１つの目的地に複数の貨物自動車４０が到着する場合には、複数の貨物自動車４０それぞれの車載端末に対して到着を遅らせるように通知してもよい。なお、サーバ２０は、複数の貨物自動車４０それぞれの到着時間を指定してもよい。
このように構成されることによって、目的地となるお客様の場所が、１つの貨物自動車４０しか通れない場所であっても対応することが可能になる。そのため、利便性を向上させることができる。

【0075】

また、サーバ２０は、同一の貨物自動車４０で容器が同日に２以上運搬される場合、同一の貨物自動車４０の回順をカウントし、回順をもとにメール（通常メール、遅延メール、早着メール）の送信や画面データの提供が行われないように制御する。
また、サーバ２０は、運行計画を参照し、所定の期間（例えば、１０分、１５分等）内に１つの目的地に異なる貨物自動車４０が到着する場合、運行計画より事前に同一日・目的地であるものを抽出し、それぞれのガス種、車両番号、到着予測日時等の情報から次のいずれかを行う。
（１）：顧客向けサーバ３０のメール生成部３４又は画面提供部３６が、同一日、目的地事にガス種、到着予測日時、台数の一覧を生成し、目的地と貨物自動車４０に対して同時に情報を提供する。なお、同一ガス種で到着予測日時が同じ場合は、台数を加算する。
（２）：顧客向けサーバ３０のメール生成部３４又は画面提供部３６は、（１）と同様の方法で一覧化した際に、先に目的地に到着する貨物自動車４０と、その次に目的地に到着する貨物自動車４０の到着予測日時が、予めお客様と取り交わした時間の範囲内であれば、先に到着する貨物自動車４０のみの到着予測日時、ガス種を目的地と貨物自動車４０に対して同時に提供する。

【0076】

サーバ２０は、顧客向けサーバ３０と同様に、図１０に示す処理を行うように構成されてもよい。このように構成される場合、サーバ２０は、データ登録部、データ記憶部、メール生成部及びメール送信部を備える。データ登録部、データ記憶部、メール生成部及びメール送信部の具体的な処理については、顧客向けサーバ３０が備える同名の機能部と同様である。顧客向けサーバ３０が備える同名の機能部と異なる構成としては、データ登録部が、取得部１１によって取得された情報に基づいて、データを登録することによってデータテーブルを生成することである。このように構成される場合、顧客向けサーバ３０は、メール生成部３４及びメール送信部３５を備えなくてもよい。
以上の構成によって、サーバ２０においてメールの送信の有無を判定し、判定結果に応じてメールを送信することができる。

【0077】

なお、上記の例では、サーバ２０もしくは顧客向けサーバ３０で通常メール、遅延メール及び早着メールを生成する場合で説明したが、貨物自動車４０の車載端末が通常メール、遅延メール及び早着メールのいずれか又は全てを生成するように構成されてもよい。以下、複数の例示を示す。

【0078】

第１の例示として、車載端末が、サーバ２０からの通知に応じて遅延メール又は早着メールを生成し、生成した遅延メール又は早着メールをお客様宛に送信する場合について説明する。このように構成される場合、車載端末はメール生成部及びメール送信部を備える。
車載端末のメール生成部は、遅延が発生している旨又は早着する旨を示す通知をサーバ２０から受信した場合、受信した通知に応じたメールを生成する。例えば、遅延が発生している旨を示す通知が受信された場合、車載端末のメール生成部は貨物自動車４０の遅延が生じていると判断し、遅延メールを生成する。また、例えば、早着する旨を示す通知が受信された場合、車載端末のメール生成部は貨物自動車４０が目的地に早着すると判断し、早着メールを生成する。
メール送信部は、メール生成部によって生成された遅延メール又は早着メールをお客様に送信する。なお、送信先であるお客様に関する情報（例えば、アドレス、事業所等）は、車載端末に記憶されていてもよいし、サーバ２０からの通知に含まれていてもよい。このように構成される場合、顧客向けサーバ３０のメール生成部３４は、通常メールのみを送信するように構成されてもよい。

【0079】

第２の例示として、車載端末が、顧客向けサーバ３０と同様に、図１０に示す処理を行うように構成されてもよい。このように構成される場合、車載端末は、取得部、データ登録部、データ記憶部、メール生成部及びメール送信部を備える。取得部、データ登録部、データ記憶部、メール生成部及びメール送信部の具体的な処理については、顧客向けサーバ３０が備える同名の機能部と同様である。このように構成される場合、サーバ２０のデータ連携部２３は、顧客向けサーバ３０との間及び車載端末との間で情報を共有する。これにより、車載端末は、運行管理システム１０によってサーバ２０に共有された情報を取得する。なお、サーバ２０のデータ連携部２３は、車載端末に対しては、車載端末を備える貨物自動車４０に関する情報のみを共有してもよい。このように構成される場合、顧客向けサーバ３０は、メール生成部３４及びメール送信部３５を備えなくてもよい。
以上の構成によって、車載端末においてメールの送信の有無を判定し、判定結果に応じてメールを送信することができる。

【0080】

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

【符号の説明】

【0081】

１０…運行管理システム， ２０…サーバ， ３０…顧客向けサーバ， ４０…貨物自動車， １１…取得部， １２…記憶部， １３…到着予測日時算出部， １４…データ連携部， ２１…取得部， ２２…記憶部， ２３…データ連携部， ３１…取得部， ３２…データ登録部， ３３…データ記憶部， ３４…メール生成部，３５…メール送信部， ３６…画面提供部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】