(57)【特許請求の範囲】
【請求項１】
運送の所要時間と運送する運送距離と運賃との入力を受け付け、
所要時間と運送距離とに応じた運賃に関する情報を保持するテーブルを参照し、入力された前記運賃が適正か否かを判定して出力する
処理をコンピュータに実行させることを特徴とする運賃判定プログラム。
【請求項２】
車両を運行した際の所要時間と運送距離と運賃との実績情報の登録を受け付け、
登録された実績情報から算出される時間、距離の少なくとも一方に関する単金を前記運賃に関する情報として前記テーブルに格納する処理をコンピュータにさらに実行させ、
前記出力する処理は、入力された前記所要時間と前記運送距離とに、前記テーブルに保持された単金を乗算して算出された運賃を基準とした所定範囲に、入力された前記運賃が含まれるか否かを出力する
ことを特徴とする請求項１に記載の運賃判定プログラム。
【請求項３】
前記出力する処理は、前記実績情報の提供元である事業者については、前記実績情報の提供元ではない事業者に比べて、前記所定範囲を広くして、入力された運賃が当該所定範囲に含まれるか否かを判定し出力する
ことを特徴とする請求項２に記載の運賃判定プログラム。
【請求項４】
元請事業者から前記実績情報の提供を受け付ける
ことを特徴とする請求項３に記載の運賃判定プログラム。
【請求項５】
前記入力を受け付ける処理は、前記運送の所要時間と運送する運送距離と運賃とが、運送の元請け業者により実行される運送についての入力と下請け業者により実行される運送についての入力とのいずれであるかに関する入力をさらに受け付け、
前記出力する処理は、下請けにより実行される運送についての入力である場合は、元請けである場合に比べて、前記所定範囲を広くして、入力された運賃が当該所定範囲に含まれるか否かを出力する
ことを特徴とする請求項２に記載の運賃判定プログラム。
【請求項６】
前記入力を受け付ける処理は、運送の出発地、到着地、到着時刻の入力をさらに受け付け、
前記出力する処理は、到着時刻別に、出発地および到着地に対応する運賃に関する情報を保持するテーブルを参照し、入力された到着時刻別に、出発地および到着地に対応する運賃に関する情報に基づいて、入力された運賃が適正か否かを判定し出力する
ことを特徴とする請求項１に記載の運賃判定プログラム。
【請求項７】
運送の所要時間と運送する運送距離と運賃との入力を受け付け、
所要時間と運送距離とに応じた運賃に関する情報を保持するテーブルを参照し、入力された前記運賃が適正か否かを判定して出力する
処理をコンピュータが実行することを特徴とする運賃判定方法。
【請求項８】
運送の所要時間と運送する運送距離と運賃との入力を受け付ける受付部と、
所要時間と運送距離とに応じた運賃に関する情報を保持するテーブルを参照し、入力された前記運賃が適正か否かを判定して出力する出力部と、
を有することを特徴とする運賃判定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、運賃判定プログラム、運賃判定方法および運賃判定装置に関する。
【背景技術】
【０００２】
従来から、トラック事業者などによる物流業界では、生産性や安全性の向上のための施策がとられてきている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−２７３４１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、物流業界では、様々な要因が運賃に影響を与える。このため、運賃の妥当性を客観的に評価し難い。【０００５】
一つの側面では、運賃の妥当性を判定できる運賃判定プログラム、運賃判定方法および運賃判定装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
第１の案では、運賃判定プログラムは、コンピュータに、運送の所要時間と運送する運送距離と運賃との入力を受け付ける処理を実行させる。運賃判定プログラムは、コンピュータに、所要時間と運送距離とに応じた運賃に関する情報を保持するテーブルを参照し、入力された運賃が適正か否かを判定して出力する処理を実行させる。
【発明の効果】
【０００７】
本発明の一の実施態様によれば、運賃の妥当性を判定できるという効果を奏する。
【図面の簡単な説明】
【０００８】
【図１】図１は、運行支援の一例を説明する説明図である。
【図２】図２は、物流業界の階層構造の一例を示す図である。
【図３】図３は、システムの概略的な構成の一例を示す図である。
【図４】図４は、サーバ装置の機能的な構成を概略的に示した図である。
【図５】図５は、運行実績情報のデータ構成の一例を示す図である。
【図６】図６は、距離・所要時間テーブルのデータ構成の一例を示す図である。
【図７】図７は、運送基本契約情報のデータ構成の一例を示す図である。
【図８】図８は、請負情報のデータ構成の一例を示す図である。
【図９】図９は、運送事業者情報のデータ構成の一例を示す図である。
【図１０】図１０は、最適なルートの一例を示す図である。
【図１１】図１１は、受け付ける情報の一例を示す図である。
【図１２】図１２は、標準の運賃を算出する流れの一例を説明する図である。
【図１３】図１３は、標準の運賃を基準とした所定範囲を示す図である。
【図１４】図１４は、運賃が適正か否かの判定の一例を説明する図である。
【図１５】図１５は、単金更新処理の手順の一例を示すフローチャートである。
【図１６】図１６は、運賃判定処理の手順の一例を示すフローチャートである。
【図１７】図１７は、運賃判定プログラムを実行するコンピュータの構成の一例を示す図である。
【発明を実施するための形態】
【０００９】
以下に、本発明にかかる運賃判定プログラム、運賃判定方法および運賃判定装置の実施例を図面に基づいて詳細に説明する。なお、本実施例により、開示技術が限定されるものではない。また、以下に示す実施例は、矛盾を起こさない範囲で適宜組み合わせてもよい。以下では、移動体を車両とした場合を例に説明する。
【実施例１】
【００１０】
最初に、実施例１に係る物流業界における車両の運行を支援するシステムの一例を説明する。図１は、運行支援の一例を説明する説明図である。運行支援システム１０は、例えば、クラウドシステムである。運行支援システム１０には、物流業界における車両の運行を支援する物流プローブプラットフォームが構築されている。【００１１】
例えば、運行支援システム１０には、トラック、バスなどの業務車両に設けられたデジタルタコグラフなどの運行監視装置から、現在位置や時刻、車両の速度などがプローブ情報として送信される。【００１２】
運行支援システム１０は、プローブ情報などの各種の情報に基づき、各種のサービスを提供する。例えば、運行支援システム１０は、物流プローブプラットフォームを用いて、業務車両の運送ルートの策定を支援する最適ルート探索サービスを提供する。業務車両を運行する事業者は、運行支援システム１０の提供する最適ルート探索サービスを利用して運送ルートを策定する。例えば、運行支援システム１０は、出発点、到着点、到着時刻などの運送ルートの条件の入力を受け付ける。事業者は、出発点、到着点、到着時刻などの運送ルートの条件を運行支援システム１０に入力する。運行支援システム１０は、プローブ情報を物流プローブプラットフォームで解析して、過去に運行されたルートから、受け付けた運送ルートの条件に沿ったルートを抽出する。運行支援システム１０は、抽出したルートから、所定の条件を満たしたルートを最適なルートとして提示する。例えば、運行支援システム１０は、所定以上走行され、走行時間が短いルートを最適なルートとして提示する。業務車両を運転する運転手は、過去の経験などから実際の道路状況を把握しており、一般的に走り難いルートを避ける。このため、所定以上走行されたルートは、走り難いルートや混雑したルートなどの不適切なルートを避けた適切な運送ルートである。よって、運行支援システム１０は、適切な運送ルートを提示できる。なお、最適なルートを抽出する所定の条件は、適宜定めることが可能であるものとする。また、運行支援システム１０は、抽出したルートを提示して、最適なルートを選択させてもよい。【００１３】
また、例えば、運行支援システム１０は、運賃の妥当性を判定する運賃判定サービスを提供する。例えば、運行支援システム１０は、最適ルート探索サービスを利用して、全国の主要な各地点間の曜日・時刻別の標準距離・到着所要時間の算出処理を実行する（図１（１））。主要な各地点は、例えば、全国を対象に市区町村を幾つかに分割したゾーン単位（例えば、道路交通センサスのＢゾーン）とするが、これに限定されるものではない。主要な各地点は、運送ルートの出発点、到着点とされる主要なエリアごとに全国を区切ったものであればよい。例えば、主要な各地点は、１次メッシュ、２次メッシュ、３次メッシュ、地域メッシュなど地図をメッシュで区切ったメッシュコードの単位であってもよく、マップコードの単位であってもよい。例えば、運行支援システム１０は、直線距離で所定距離（例えば、２００ｋｍ）以上離れた主要な各地点について、それぞれを出発点（Ｏ）、到着点（Ｄ）として組み合わせを求める。運行支援システム１０は、求めた組み合わせごとに、最適ルート探索サービスを利用して、出発点から到着点（Ｏ→Ｄ）に対する曜日・到着時刻毎に最適なルートを探索して、距離・所要時間を求める。運行支援システム１０は、曜日・到着時刻別に、主要な任意の２地点間の距離・所要時間を格納した標準距離・所要時間テーブルを作成する。【００１４】
運行支援システム１０は、標準的な元請けの運賃を算出する元請標準運賃算出処理を実行する（図１（２））。この元請標準運賃算出処理では、過去の運賃の実績を用いて、距離・所要時間・運賃最適化処理を行う（図１（２）ａ）。例えば、運行支援システム１０は、業務車両を運行する元請事業者から、業務車両を運行した際の出発点、到着地、到着した曜日、到着時刻、運賃などの運行の実績情報を受け付ける。運行支援システム１０は、実績情報に基づき、曜日・到着時刻別に、主要な２地点間を走行した実際の運賃を求め、運賃に関する情報を算出する。例えば、運行支援システム１０は、元請けの２地点の過去の運賃の実績を用いて、当該２地点の運賃に関する情報として、時間、距離の少なくとも一方に関する単金を算出する。そして、元請標準運賃算出処理では、曜日・到着時刻別の主要な２地点間の運賃に関する情報を用いて、拠点間曜日・時刻別標準運賃算出処理を行う（図１（２）ｂ）。例えば、運行支援システム１０は、曜日・到着時刻別の主要な２地点間の時間、距離の少なくとも一方に関する単金を用いて、曜日・到着時刻別の主要な２地点間の標準的な運賃を算出する。【００１５】
運行支援システム１０は、運送の所要時間と運送距離と運賃の入力を事業者から受け付ける。例えば、事業者は、最適ルート探索サービスを利用して、運送を行う出発点、到着点、到着曜日、到着時刻に関する最適なルートを検索し、運送の所要時間、運送距離を求める。そして、事業者は、所要時間、運送距離に対する運賃を入力する。運行支援システム１０は、運送の所要時間と運送距離と運賃の入力を事業者から受け付ける。運行支援システム１０は、運送を行う出発点、到着点、到着曜日、到着時刻に対応した標準的な運賃を用いて、入力された運賃の妥当性を判定する。【００１６】
ここで、物流業界は、運送依頼を受け付ける元請事業者と、元請事業者などの上位の事業者から運送の請負を受け付ける２次請け、３次請けなどの請負事業者による階層構造がある。図２は、物流業界の階層構造の一例を示す図である。元請事業者は、例えば、荷主や大手、中堅の宅配会社などの運送サービス事業者、所謂、みず屋と呼ばれる利用運送事業者などが該当する。請負事業者は、例えば、中小、零細な運送事業者が該当する。【００１７】
物流業界は、階層構造により、上位と下位の事業者間で各種制度・規制の遵守の度合いや、運賃の高低差における格差が拡大している。例えば、図２に示すように元請事業者から５次請けの請負事業者まで階層構造がある場合、上位の事業者は、運賃から利益を差し引いて下位の事業者に運送を依頼するため、運送を請け負う下位の事業者ほど運賃が低下する傾向がある。なお、事業者は、赤字でも運送を請け負うことがある。このため、上位の事業者の運賃は、下位の事業者の運賃よりも必ずしも高いわけではない。一方、需給の調整や運賃の自由競争を確保する為には、元請事業者の存在は経済全体としては有効に機能している。しかしながら、上位と下位の事業者間で格差が拡大した場合、物流の生産性・安全性が低下する虞がある。そこで、制度や規制などによって上位と下位の事業者間で格差を抑制することも考えられる。しかし、制度や規制によって格差を抑制した場合、物流業界の正常な自由競争を阻害する虞があり、好ましくない。【００１８】
そこで、運行支援システム１０では、標準的な運賃を基準とした所定範囲に、入力された運賃が含まれるか否かにより、運賃の妥当性を判定する。ここで、請負事業者の運賃は、元請事業者の運賃よりも低い傾向がある。そこで、運行支援システム１０は、階層構造に応じた実勢運賃管理処理を実行する（図１（３））。例えば、運行支援システム１０は、下請けについては、元請けに比べて、所定範囲を広くして、入力された運賃が当該所定範囲に含まれるかを判定する。【００１９】
また、運行支援システム１０では、単金を算出するために、元請事業者から、業務車両を運行した際の出発点、到着点、到着曜日、到着時刻、運賃などの運行の実績情報の提供を受ける。運行支援システム１０では、実績情報を提供する元請事業者にはインセンティブを付与するインセンティブ処理を実行する（図１（４））。例えば、運行支援システム１０は、実績情報を提供する元請事業者については、実績情報の提供しない事業者に比べて、所定範囲を広くして、入力された運賃が当該所定範囲に含まれるかを判定する。【００２０】
これにより、運行支援システム１０は、運賃の妥当性を判定できる。ひいては、客観的な運賃の妥当性に関する情報を出力することができる。また、運行支援システム１０は、生産性向上・安全性を担保して自由競争を実現できる。【００２１】
［システム構成］
次に、図１に示した運行支援システム１０を実現するシステム構成の一例を説明する。図３は、システムの概略的な構成の一例を示す図である。図３に示すように、運行支援システム１０は、サーバ装置１１と、事業者端末１２とを有する。サーバ装置１１および事業者端末１２は、ネットワークＮに通信可能に接続されている。かかるネットワークＮの一態様としては、有線又は無線を問わず、携帯電話などの移動体通信網、インターネット（Internet）、ＬＡＮ（Local  Area  Network）やＶＰＮ（Virtual  Private  Network）などの任意の種類の通信網を採用できる。【００２２】
サーバ装置１１は、サーバコンピュータなどのコンピュータである。サーバ装置１１は、プローブ情報などの各種の情報に基づき、上述した最適ルート探索サービス、運賃判定サービスを含む各種のサービスを提供する。なお、本実施例では、サーバ装置１１を１台のコンピュータとした場合を例として説明するが、複数台のコンピュータによるコンピュータシステムとして実装してもよい。例えば、サーバ装置１１は、提供するサービスや機能ごとに複数のコンピュータに分けて実装してもよい。本実施例では、サーバ装置１１が、運賃判定装置に対応する。【００２３】
事業者端末１２は、例えば、トラック、バスなどの業務車両を運行する事業者に配置された、パソコン等の端末装置である。なお、図３の例では、事業者端末１２を２台とした場合を例示したが、これに限定されず、事業者端末１２を任意の数とすることができる。事業者は、事業者端末１２を用いてサーバ装置１１にアクセスし、サーバ装置１１が提供する各種のサービスを利用する。【００２４】
［サーバ装置の構成］
次に、サーバ装置１１の構成について説明する。図４は、サーバ装置の機能的な構成を概略的に示した図である。図４に示すサーバ装置１１は、通信部２０と、記憶部２１と、制御部２２とを有する。【００２５】
通信部２０は、例えば、ネットワークＮとの間で無線通信又は有線通信を行う通信インタフェースである。【００２６】
記憶部２１は、ハードディスク、ＳＳＤ（Solid  State  Drive）、光ディスクなどの記憶装置である。なお、記憶部２１は、ＲＡＭ（Random  Access  Memory）、フラッシュメモリ、ＮＶＳＲＡＭ（Non  Volatile  Static  Random  Access  Memory）などのデータを書き換え可能な半導体メモリであってもよい。記憶部２１は、制御部２２で実行されるＯＳ（Operating  System）や、各種プログラムを記憶する。さらに、記憶部２１は、各種情報を記憶する。例えば、記憶部２１は、運行実績情報３０と、距離・所要時間テーブル３１と、運送基本契約情報３２と、請負情報３３と、運送事業者情報３４とを記憶する。なお、記憶部２１は、その他の各種の情報を記憶してもよい。【００２７】
運行実績情報３０は、業務車両の運行監視装置から送信されたプローブ情報など業務車両の運行実績に関する各種の情報を記憶したデータである。図５は、運行実績情報のデータ構成の一例を示す図である。図５に示すように、運行実績情報３０は、機器ＩＤ、事業者ＩＤ、日時、位置の各項目を有する。なお、運行実績情報３０は、上記以外にも各種の情報を記憶してもよい。【００２８】
機器ＩＤの項目は、プローブ情報を送信した運行監視装置の識別情報を記憶する領域である。運行監視装置には、識別情報として、例えば、ユニークな機器ＩＤ（identification）が付与される。機器ＩＤの項目には、プローブ情報を送信した運行監視装置の機器ＩＤが格納される。事業者ＩＤの項目には、運行監視装置が搭載された業務車両を運行する事業者の識別情報を記憶する領域である。サーバ装置１１が提供するサービスを利用する事業者には、識別情報として、例えば、ユニークな事業者ＩＤが付与される。事業者ＩＤの項目には、機器ＩＤの運行監視装置が搭載された業務車両を運行する事業者の事業者ＩＤが格納される。日時の項目は、運行監視装置で位置などの各種の情報を検出した日時を記憶する領域である。位置の項目は、運行監視装置で検出された業務車両の位置を示す位置情報を記憶する領域である。本実施例では、位置情報を、日本測地系や世界測地系など所定の測地系により緯度、経度などで位置を示した情報としている。なお、位置情報は、位置を特定できればその他の情報でもよい。例えば、位置情報は、１次メッシュ、２次メッシュ、３次メッシュ、地域メッシュなど地図をメッシュで区切ったメッシュコードや、道路交通センサスのＢゾーンのコード、マップコードであってもよい。【００２９】
図５の例では、機器ＩＤ「１２３４５６７」の運行監視装置を搭載した業務車両は、運行元の事業者の事業者ＩＤが「０００１」であり、６月１日８時２分の位置が北緯３５．ＸＸ、東経１３９．ＸＸであることを示す。【００３０】
図４に戻り、距離・所要時間テーブル３１は、主要な任意の２地点間の距離・所要時間を記憶したデータである。距離・所要時間テーブル３１は、曜日・到着時刻毎に、生成される。図６は、距離・所要時間テーブルのデータ構成の一例を示す図である。図６に示すように、距離・所要時間テーブル３１は、縦方向に出発点（Ｏ）とされた地点の項目が設けられ、横方向に到着点（Ｄ）とされた地点の項目が設けられている。また、距離・所要時間テーブル３１は、出発点と到着点に対応する領域に、出発点から到着点への運送ルートの距離と所要時間が記憶されている。【００３１】
図６の例では、出発点「仙台市青葉区」から到着点「大阪市中央区」への運送ルートの距離が８６０ｋｍであり、所要時間が１２：３０であることを示す。また、出発点「大阪市中央区」から到着点「仙台市青葉区」への運送ルートの距離が８８０ｋｍであり、所要時間が１２：３０であることを示す。ここで、出発点と到着点が同じでも、曜日や到着時刻により道路の混雑状況などが変わるため、適切な運送ルートが変化する。このため、出発点と到着点が同じでも、曜日、到着時刻毎に、距離、所要時間が変化する。また、出発点と到着点が入れ替わった場合も、適切な運送ルートが変化する場合がある。このため、図６の例では、「仙台市青葉区」から「大阪市中央区」へ運送する場合と、「大阪市中央区」から「仙台市青葉区」へ運送する場合とで距離が異なっている。【００３２】
図４に戻り、運送基本契約情報３２は、運送の契約に関する各種の情報を記憶したデータである。例えば、荷主から運送の依頼を受けた元請事業者は、荷主と運送基本契約など各種の契約を結ぶ。運送基本契約情報３２には、荷主と契約した運送に関する運送基本契約の内容が記憶される。図７は、運送基本契約情報のデータ構成の一例を示す図である。図７に示すように、運送基本契約情報３２は、契約ＩＤ、荷主、元請、運送品目、到着目標、出発点、到着点、運送ルート、距離、時間、契約金額の各項目を有する。なお、運送基本契約情報３２は、上記以外にも各種の情報を記憶してもよい。【００３３】
契約ＩＤの項目は、運送基本契約の識別情報を記憶する領域である。登録された運送基本契約には、識別情報として、例えば、ユニークな契約ＩＤが付与される。契約ＩＤの項目には、登録された運送基本契約の契約ＩＤが格納される。荷主の項目は、運送する荷物の荷主を記憶する領域である。元請の項目は、運送の元請けとなった事業者を記憶する領域である。運送品目の項目は、運送する荷物の品目を記憶する領域である。到着目標の項目は、到着点に到着する目標の日時を記憶する領域である。出発点の項目は、運送の出発地とする地点を記憶する領域である。到着点の項目は、運送の到着地とする地点を記憶する領域である。運送ルートの項目は、運送する際の運送ルートに関する情報を記憶する領域である。距離は、運送ルートに沿って運送する場合の距離を記憶する領域である。時間は、運送ルートに沿って運送する場合の所要時間を記憶する領域である。契約金額の項目は、運送について荷主と元請事業者間で契約された金額を記憶する領域である。荷主、元請、運送品目、到着目標、出発点、到着点、運送ルート、距離、時間、契約金額の各項目のデータは、必要に応じて登録、更新される。【００３４】
図７の例では、契約ＩＤ「０１２３４５６」の運送基本契約は、荷主Ｘと元請けの事業者Ａとの間で契約されたことを示す。また、契約ＩＤ「０１２３４５６」の運送基本契約は、運送品目が「ＸＸＸ」であり、到着点への到着目標が「７／１３（水）  ６：００」であり、出発点が「仙台市青葉区」であり、到着点が「大阪市中央区」であることを示す。契約ＩＤ「０１２３４５６」の運送基本契約は、運送ルートが「ルートα」であり、距離が８５０ｋｍであり、所要時間が１２：００であり、契約金額が９７８００円であることを示す。【００３５】
図４に戻り、請負情報３３は、運送基本契約が契約された運送を下請けした際の運送に関する各種の情報を記憶したデータである。例えば、元請事業者は、荷主から運送の依頼を受けた運送を請負事業者に依頼する。請負情報３３は、請け負った運送に関する情報が記憶される。図８は、請負情報のデータ構成の一例を示す図である。図８に示すように、請負情報３３は、契約ＩＤ、階層、事業者、依頼元、到着目標、運送ルート、距離、時間、契約金額の各項目を有する。なお、請負情報３３は、上記以外にも各種の情報を記憶してもよい。例えば、請負情報３３も、運送の出発点、到着点などの情報を記憶してもよい。【００３６】
契約ＩＤの項目は、下請けした運送の運送基本契約の契約ＩＤを記憶する領域である。階層の項目は、下請けが何階層目であるかを記憶する領域である。事業者の項目は、運送を下請けした事業者を記憶する領域である。依頼元の項目は、運送を依頼した事業者を記憶する領域である。到着目標の項目は、到着点に到着する目標の日時を記憶する領域である。運送ルートの項目は、運送する際の運送ルートに関する情報を記憶する領域である。距離は、運送ルートに沿って運送する場合の距離を記憶する領域である。時間は、運送ルートに沿って運送する場合の所要時間を記憶する領域である。契約金額の項目は、運送を請け負った金額を記憶する領域である。【００３７】
図８の例では、運送基本契約の契約ＩＤが「０１２３４５６」の運送は、２次請けとして、事業者Ａが事業者Ｂに依頼したことを示す。また、２次請けの運送では、到着点への到着目標が「７／１３（水）  ６：００」であり、運送ルートが「ルートβ」であり、距離が８６０ｋｍであり、所要時間が１１：５０であり、契約金額が９２８００円であることを示す。運送基本契約の契約ＩＤが「０１２３４５６」の運送は、３次請けとして、事業者Ｂが事業者Ｃに依頼したことを示す。また、３次請けの運送では、到着点への到着目標が「７／１３（水）  ６：００」であり、運送ルートが「ルートβ」であり、距離が８６０ｋｍであり、所要時間が１１：５０であり、契約金額が８７５００円であることを示す。なお、階層は、事業者が入力してもよい。また、階層は、運送基本契約情報３２の元請の項目に記憶された事業者と、請負情報３３の事業者、依頼元の項目に記憶された事業者から階層関係をシステムで特定して登録してもよい。【００３８】
図４に戻り、運送事業者情報３４は、業務車両を運行する事業者に関する各種の情報を記憶したデータである。図９は、運送事業者情報のデータ構成の一例を示す図である。図９に示すように、運送事業者情報３４は、事業者、インセンティブの各項目を有する。なお、運送事業者情報３４は、上記以外にも各種の情報を記憶してもよい。【００３９】
事業者の項目は、業務車両を運行する事業者を記憶する領域である。インセンティブの項目は、事業者に対してインセンティブの有無を記憶する領域である。例えば、運賃の実績情報を提供する元請事業者には、インセンティブが有りと登録される。【００４０】
図９の例では、事業者Ａは、インセンティブが有ることを示す。また、事業者Ｂおよび事業者Ｃは、インセンティブが無いことを示す。【００４１】
図４に戻り、制御部２２は、サーバ装置１１全体を制御するデバイスである。制御部２２としては、ＣＰＵ（Central  Processing  Unit）、ＭＰＵ（Micro  Processing  Unit）等の電子回路や、ＡＳＩＣ（Application  Specific  Integrated  Circuit）、ＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路を採用できる。制御部２２は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部２２は、各種のプログラムが動作することにより各種の処理部として機能する。例えば、制御部２２は、ルート検索部４０と、算出部４１と、格納部４２と、受付部４３と、出力部４４とを有する。【００４２】
ルート検索部４０は、最適ルート探索サービスに関する処理を実行する。例えば、ルート検索部４０は、出発点、到着点、到着時刻などの運送ルートの条件の入力を受け付ける。ルート検索部４０は、運行実績情報３０に記憶されたプローブ情報など業務車両の運行実績に基づいて、過去に運行されたルートから、受け付けた運送ルートの条件に沿ったルートを抽出する。ルート検索部４０は、抽出したルートから、所定の条件を満たしたルートを最適なルートとして抽出する。例えば、ルート検索部４０は、所定以上走行され、かつ、走行時間が短いルートを最適なルートとして抽出する。運行実績からルートを検索する手法としては、例えば、本出願人による特願2016-031483の技術を用いてもよい。【００４３】
算出部４１は、所定の処理タイミングで、運行実績情報３０に登録された実績情報から、所要時間と運送距離に応じた運賃に関する情報を算出する。処理タイミングは、例えば、月末の月次処理のタイミングなど、所定期間ごとのタイミングであってもよく、管理者から指示されたタイミングであってもよい。【００４４】
例えば、最初に、算出部４１は、ルート検索部４０が提供する最適ルート探索サービスを利用して、全国の主要な各地点について、主要な１つの地点を出発点とし、主要な他の１つの地点を到着点とし、２地点間の曜日・時刻別の標準距離・所要時間を求める。例えば、算出部４１は、直線距離で、所定距離（例えば、２００ｋｍ）以上離れた主要な各地点について、それぞれを出発点、到着点として組み合わせを求める。算出部４１は、求めた組み合わせごとに、最適ルート探索サービスを利用して、曜日別に、一定時間間隔を到着時刻として、到着時刻毎に最適なルートを探索し、距離・所要時間を求める。一定時間は、例えば、１０分とするが、これに限定されない。一定時間は、最適なルートに変化が生じると考えられる時間であればよく、例えば、１時間としてもよい。すなわち、算出部４１は、曜日および一定時間間隔の到着時刻別に、所定距離以上離れた主要な各地点間の距離・所要時間を求める。図１０は、最適なルートの一例を示す図である。例えば、出発点（Ｏ）を仙台市青葉区とし、到着点（Ｄ）を大阪市中央区とし、到着を水曜日の６時とした場合、最適ルート探索サービスにより、運送ルート６０が検索される。運送ルート６０は、距離が８６０ｋｍ、所要時間が１２：００であるものとする。そして、算出部４１は、曜日・到着時刻別に、主要な任意の２地点間の距離・所要時間を格納した距離・所要時間テーブル３１を作成する。【００４５】
次に、算出部４１は、運送基本契約情報３２から、曜日・到着時刻別に、主要な各地点間を走行した実際の運賃を求める。例えば、算出部４１は、運送事業者情報３４から、インセンティブの項目が有りとされた、運賃の実績情報を提供する事業者を特定する。算出部４１は、運送基本契約情報３２から、運賃の実績情報を提供する事業者が元請けになっている各運送基本契約の情報を読み出し、曜日・到着時刻別に、主要な各地点間を走行した実際の運賃を求める。なお、算出部４１は、直近の期間の運賃のみを求めてもよい。例えば、処理タイミングが所定期間ごとのタイミングである場合、算出部４１は、前回の処理タイミングから今回の処理タイミングまでの期間に到着日時が含まれる運行の運賃を求めてもよい。また、算出部４１は、今回の処理タイミングから一定期間（例えば、３か月）の間に到着日時が含まれる運行の運賃を求めてもよい。【００４６】
そして、算出部４１は、曜日・到着時刻別に主要な各地点間について、所要時間と運送距離に応じた運賃に関する情報を求める。例えば、算出部４１は、運賃に関する情報として、時間単金、距離単金を算出する。例えば、算出部４１は、曜日、到着時刻、出発点から到着点（Ｏ→Ｄ）別に、実際の運賃と、曜日・到着時刻別の距離・所要時間テーブル３１に記憶された出発点と到着点間の距離、所要時間とを用いて重回帰分析を行い、時間単金、距離単金を算出する。【００４７】
なお、算出部４１は、曜日、到着時刻、地点間別の時間単金、距離単金が既に記憶されている場合、時間単金、距離単金の急激な変動を避けるため、既に記憶されている時間単金、距離単金も加味して時間単金、距離単金を算出してもよい。例えば、既にｎ回目の単金として記憶された時間単金をLn、距離単金をMnとする。ｎ＋１回目の単金の算出において算出された時間単金をL`n+1、距離単金をM`n+1とする。この場合、算出部４１は、以下の式（１）に示すように時間単金Ln、距離単金Mnと、時間単金L`n+1、距離単金M`n+1を平均して、ｎ＋１回目の時間単金Ln+1、距離単金Mn+1を算出する。【００４８】
(Ln+1，Mn+1)＝((Ln，Mn)＋(L`n+1，M`n+1))/2        （１）【００４９】
これにより、算出部４１は、時間単金、距離単金の急激な変動を避けて、時間単金、距離単金を実際の実勢値に近づけることができる。【００５０】
格納部４２は、算出部４１により算出された時間単金、距離単金を距離・所要時間テーブル３１に格納する。これにより、例えば、図６の距離・所要時間テーブル３１には、出発点、到着点に対応してそれぞれ時間単金、距離単金が格納される。なお、算出部４１は、曜日、到着時刻、地点間別の時間単金、距離単金を別なテーブルとして記憶させてもよい。【００５１】
受付部４３は、元請事業者や請負事業者から、運送に関する各種の情報の入力を受け付ける。例えば、受付部４３は、運送依頼を受け付ける元請事業者から、受け付けた運送依頼に関する運送基本契約の内容の入力を受け付ける。また、受付部４３は、運送を下請けした請負事業者から、下請けした運送に関する各種の情報の入力を受け付ける。図１１は、受け付ける情報の一例を示す図である。例えば、元請事業者は、荷主企業から運送が依頼され、運送基本契約を結んだ場合、荷主情報、元請情報、運送品目情報、到着目標、出発点、到着点、運送ルート、距離、時間、契約金額などの運送基本契約情報を入力する。なお、運送ルート、距離、時間については、元請事業者が、最適ルート探索サービスを利用して運送ルートを検索して入力する。受付部４３は、入力された運送基本契約に対して契約ＩＤを付与し、受け付けた運送基本契約の内容を運送基本契約情報３２に格納する。また、受付部４３は、運送基本契約に対して付与した契約ＩＤを元請事業者に通知する。元請事業者は、荷主から依頼された運送を請負事業者に依頼する。請負事業者への運送の依頼は、運行支援システム１０を介して行ってもよく、メールや電話など他の手段を用いて行ってもよい。請負事業者が依頼された運送を請け負った場合、元請事業者は、依頼した運送の契約ＩＤを請負事業者に通知する。請負事業者は、通知された契約ＩＤと共に、下請けした運送に関する事業者、依頼元、到着目標、運送ルート、距離、時間、契約金額などの請負情報を入力する。なお、運送ルート、距離、時間については、請負事業者が、最適ルート探索サービスを利用して運送ルートを検索して入力する。受付部４３は、入力された請負情報を請負情報３３に格納する。【００５２】
出力部４４は、入力された運賃が適正か否かを出力する。例えば、出力部４４は、距離・所要時間テーブル３１を参照して、運送する曜日、到着時刻、出発点、到着点に対応した時間単金、距離単金を求める。出力部４４は、運送の所要時間と運送距離に、求めた時間単金、距離単金を乗算して標準の運賃を算出する。図１２は、標準の運賃を算出する流れの一例を説明する図である。図１２の例では、出発点が「仙台市青葉区」であり、到着点が「大阪市中央区」であり、到着点への到着目標が水曜日の６：００であるものとする。また、初期の単金は、時間単金が４０円／分、距離単金が８０円／ｋｍであるものとする。また、入力された運送の距離が８６０ｋｍであり、所要時間が１２：００であるものとする。この場合、出力部４４は、標準の運賃を９７６００円（＝８６０×８０＋１２×６０×４０）と算出する。ここで、例えば、時間単金、距離単金が更新される場合を説明する。例えば、出発点「仙台市青葉区」、到着点「大阪市中央区」、到着点への到着目標が水曜日の６：００について、実績１、実績２の２つの実績情報があるものとする。実績１は、運送の距離が８５０ｋｍであり、所要時間が１２：００であり、運賃が９７６００円であるものとする。実績２は、運送の距離が８６０ｋｍであり、所要時間が１１：５０であり、運賃が９７５００円であるものとする。この場合、算出部４１は、実績１、実績２から重回帰分析により、時間単金を３８円／分、距離単金を８２円／ｋｍと算出する。そして、算出部４１は、初期の時間単金、距離単金と、算出した時間単金、距離単金を平均して時間単金、距離単金を算出する。格納部４２は、算出した時間単金、距離単金に時間単金、距離単金を更新する。図１２の例では、更新後の時間単金が３９円／分（＝（４０＋３８）／２）となり、更新後の距離単金が８１円／ｋｍ（＝（８０＋８２）／２）となっている。この場合、出力部４４は、標準の運賃を９７７４０円（＝８６０×８１＋１２×６０×３９）と算出する。【００５３】
出力部４４は、算出した標準の運賃を基準とした所定範囲に、入力された運賃が含まれるか否かを判定する。例えば、出力部４４は、インセンティブ無しの元請事業者からの元請けの運賃については、標準の運賃を基準とした±３％の範囲に、入力された運賃が含まれるか否かを判定する。また、出力部４４は、インセンティブ有り元請事業者からの元請けの運賃については、標準の運賃を基準とした±５％の範囲に、入力された運賃が含まれるか否かを判定する。出力部４４は、下請けの運賃については、標準の運賃を基準とした±１０％の範囲に、入力された運賃が含まれるか否かを判定する。図１３は、標準の運賃を基準とした所定範囲を示す図である。図１３の例では、標準の運賃を基準とした±３％の範囲が標準元請運賃として示されている。また、標準の運賃を基準とした±５％の範囲がインセンティブ有り標準元請運賃として示されている。標準の運賃を基準とした±１０％の範囲が標準許容運賃として示されている。例えば、標準の運賃が９７６００円である場合、標準元請運賃は、９４６７２円〜１００５２８円の範囲となる。インセンティブ有り標準元請運賃は、９２７２０円〜１０２４８０円の範囲となる。標準許容運賃は、８７８４０円〜１０７３６０円の範囲となる。また、標準の運賃が９７７４０円である場合、標準元請運賃は、９４８０８円〜１００６７２円の範囲となる。また、インセンティブ有り標準元請運賃は、９２８５３円〜１０２６２７円の範囲となる。また、標準許容運賃は、８７９６６円〜１０７５１４円の範囲となる。なお、標準元請運賃、インセンティブ有り標準元請運賃、標準許容運賃とする範囲は、一例であり、これに限定されるものではない。例えば、出力部４４は、標準元請運賃を、標準の運賃に対して、−４％〜＋２％の範囲などと、高い金額側よりも低い金額側を広く範囲を定めてもよい。標準元請運賃、インセンティブ有り標準元請運賃、標準許容運賃とする範囲は、外部から設定可能としてもよい。【００５４】
出力部４４は、入力された運賃が標準の運賃を基準とした範囲に含まれる場合、運賃が適正と出力し、入力された運賃が標準の運賃を基準とした範囲に含まれない場合、運賃が不適正と出力する。図１４は、運賃が適正か否かの判定の一例を説明する図である。図１４の例は、図１０のように運賃が入力された場合の判定の一例を示している。標準の運賃は、９７６００円とする。例えば、元請けの運賃である９７８００円は、標準元請運賃である９４６７２円〜１００５２８円の範囲に含まれる。よって、運賃が適正と出力される。また、２次請けの運賃である９２８００円は、標準許容運賃である８７８４０円〜１０７３６０円の範囲に含まれる。よって、運賃が適正と出力される。一方、３次請けの運賃である８７５００円は、標準許容運賃である８７８４０円〜１０７３６０円の範囲に含まれない。よって、運賃が不適正と出力される。【００５５】
このように、サーバ装置１１は、運賃の妥当性を判定できる。ひいては、客観的な運賃の妥当性に関する情報を出力することができる。これにより、サーバ装置１１は、事業者の運賃が不当に低く抑えられることを抑制でき、運賃が不当に低く抑えられることによる安全性の低下を抑制できる。また、サーバ装置１１は、運賃の妥当性を提供するのみであり、料金の範囲を規制するものではいため、物流業界の正常な自由競争を阻害せず、物流業界の生産性向上を阻害しない。よって、サーバ装置１１は、生産性向上・安全性を担保して自由競争を実現できる。【００５６】
［処理の流れ］
次に、本実施例に係るサーバ装置１１が実行する各種の処理の流れを説明する。最初に、サーバ装置１１が実行する単金更新処理の流れについて説明する。図１５は、単金更新処理の手順の一例を示すフローチャートである。この単金更新処理は、所定のタイミング、例えば、月末の月次処理のタイミングで実行される。【００５７】
図１５に示すように、算出部４１は、最適ルート探索サービスを利用して、全国の主要な各地点について、主要な１つ地点を出発点とし、主要な他の１つ地点を到着点とし、２地点間の曜日・時刻別の標準距離・所要時間を検索する（Ｓ１０）。算出部４１は、曜日・到着時刻別に、主要な任意の２地点間の距離・所要時間を格納した距離・所要時間テーブル３１を作成する（Ｓ１１）。【００５８】
算出部４１は、運送事業者情報３４から、インセンティブの項目が有りとされた、運賃の実績情報を提供する事業者を特定する（Ｓ１２）。算出部４１は、運送基本契約情報３２から、運賃の実績情報を提供する事業者が元請になっている各運送基本契約の情報を読み出し、曜日・到着時刻別に、主要な各地点間を走行した実際の運賃を特定する（Ｓ１３）。【００５９】
算出部４１は、曜日・到着時刻別に主要な各地点間について、所要時間と運送距離に応じた時間単金、距離単金を算出する（Ｓ１４）。格納部４２は、算出された時間単金、距離単金を距離・所要時間テーブル３１に格納し（Ｓ１５）、処理を終了する。【００６０】
次に、サーバ装置１１が実行する運賃判定処理の流れについて説明する。図１６は、運賃判定処理の手順の一例を示すフローチャートである。この運賃判定処理は、所定のタイミング、例えば、元請事業者や請負事業者から運送基本契約情報や請負情報が入力されたタイミングや、判定対象とする運送基本契約情報や請負情報が指定されて運賃判定の開始を指示する操作が行われたタイミングで実行される。【００６１】
図１６に示すように、出力部４４は、距離・所要時間テーブル３１を参照して、運送する曜日、到着時刻、出発点、到着点に対応した時間単金、距離単金を読み出す（Ｓ５０）。出力部４４は、運送の所要時間と運送距離に、求めた時間単金、距離単金を乗算して標準の運賃を算出する（Ｓ５１）。【００６２】
出力部４４は、算出した標準の運賃を基準とした所定範囲に、入力された運賃が含まれるか否かを判定する（Ｓ５２）。例えば、出力部４４は、インセンティブ無しの元請事業者からの元請けの運賃については、標準の運賃を基準とした±３％の範囲に、入力された運賃が含まれるか否かを判定する。また、出力部４４は、インセンティブ有り元請事業者からの元請けの運賃については、標準の運賃を基準とした±５％の範囲に、入力された運賃が含まれるか否かを判定する。出力部４４は、下請けの運賃については、標準の運賃を基準とした±１０％の範囲に、入力された運賃が含まれるか否かを判定する。【００６３】
入力された運賃が標準の運賃を基準とした範囲に含まれる場合（Ｓ５２肯定）、出力部４４は、運賃が適正と出力し（Ｓ５３）、処理を終了する。【００６４】
一方、入力された運賃が標準の運賃を基準とした範囲に含まれない場合（Ｓ５２否定）、出力部４４は、運賃が不適正と出力し（Ｓ５４）、処理を終了する。【００６５】
［効果］
上述してきたように、本実施例に係るサーバ装置１１は、運送の所要時間と運送する運送距離と運賃との入力を受け付ける。サーバ装置１１は、所要時間と運送距離とに応じた運賃に関する情報を保持するテーブルを参照し、入力された前記運賃が適正か否かを判定して出力する。これにより、サーバ装置１１は、運賃の妥当性を判定できる。【００６６】
また、本実施例に係るサーバ装置１１は、車両を運行した際の所要時間と運送距離と運賃との実績情報の登録を受け付ける。サーバ装置１１は、登録された実績情報から算出される時間、距離の少なくとも一方に関する単金を運賃に関する情報としてテーブルに格納する。サーバ装置１１は、入力された所要時間と運送距離とに、テーブルに保持された単金を乗算して算出された運賃を基準とした所定範囲に、入力された運賃が含まれるか否かを出力する。これにより、サーバ装置１１は、入力された運賃の適正な範囲かの妥当性を判定できる。【００６７】
また、本実施例に係るサーバ装置１１は、実績情報の提供元である事業者については、実績情報の提供元ではない事業者に比べて、所定範囲を広くして、入力された運賃が当該所定範囲に含まれるか否かを判定し出力する。これにより、サーバ装置１１は、実績情報の提供する事業者に対して実績情報を提供するインセンティブを付与できるため、多くの事業者から実績情報を多く収集できる。【００６８】
また、本実施例に係るサーバ装置１１は、元請事業者から実績情報の提供を受け付ける。これにより、サーバ装置１１は、元請の標準的な運賃を精度よく算出できるようになる。また、サーバ装置１１は、元請の標準的な運賃を基準として下請けの適正な運賃も精度よく算出できるようになる。【００６９】
また、本実施例に係るサーバ装置１１は、運送の所要時間と運送する運送距離と運賃とが、運送の元請け業者により実行される運送についての入力と下請け業者により実行される運送についての入力とのいずれであるかに関する入力をさらに受け付ける。サーバ装置１１は、下請けにより実行される運送についての入力である場合は、元請けである場合に比べて、前記所定範囲を広くして、入力された運賃が当該所定範囲に含まれるか否かを出力するすなわち、サーバ装置１１は、運送の元請けか下請けかに関する入力をさらに受け付ける。そして、サーバ装置１１は、下請けについては、元請けに比べて、所定範囲を広くして、入力された運賃が当該所定範囲に含まれるか否かを出力する。下請けは元請けと比較して運賃の変動幅が大きい。サーバ装置１１は、元請けと下請けについての運賃の妥当性を適切に判定できる。【００７０】
また、本実施例に係るサーバ装置１１は、運送の出発地、到着地、到着時刻の入力をさらに受け付ける。サーバ装置１１は、到着時刻別に、出発地および到着地に対応する運賃に関する情報を保持するテーブルを参照し、入力された到着時刻別に、出発地および到着地に対応する運賃に関する情報に基づいて、入力された運賃が適正か否かを判定し出力する。出発地および到着地が同じであっても到着時刻ごとに、単金などの運賃に関する情報の適正値は変化する。サーバ装置１１は、運送の出発地、到着地、到着時刻に応じて運賃が適正であるかの妥当性を判定できる。
【実施例２】
【００７１】
さて、これまで開示の装置に関する実施例について説明したが、開示の技術は上述した実施例以外にも、種々の異なる形態にて実施されてもよい。そこで、以下では、本発明に含まれる他の実施例を説明する。【００７２】
例えば、上記実施例では、運送基本契約の運賃を実際の運賃とする場合を例示した。しかしながら、これらに限定されるものではない。例えば、サーバ装置１１は、事業者から運送後に、実際の運賃や運送ルート、到着曜日、到着時刻、出発点、到着点などの実績情報を入力させ、入力された実績情報に基づいて時間単金、距離単金を算出してもよい。【００７３】
また、上記実施例では、運賃に関する情報として、時間単金および距離単金を算出する場合を例示した。しかしながら、これらに限定されるものではない。例えば、サーバ装置１１は、時間単金、距離単金の何れか一方のみを算出してもよい。また、サーバ装置１１は、時間単金、距離単金以外に、その他の運賃に影響を与える各種の付帯料金などの運賃に関する情報を算出してもよい。【００７４】
また、上記実施例では、インセンティブ有りの事業者にインセンティブを付与する場合を例示した。しかしながら、これらに限定されるものではない。例えば、サーバ装置１１は、インセンティブを付与する有効期限を定め、有効期限まではインセンティブを付与するものとしてもよい。【００７５】
また、上記実施例では、運賃が適正か否かを出力する場合を例示した。しかしながら、これらに限定されるものではない。例えば、サーバ装置１１は、運賃が適正か否かの判定に用いた、標準運賃を基準とした範囲を合わせて出力してもよい。【００７６】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的状態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。例えば、ルート検索部４０、算出部４１、格納部４２、受付部４３および出力部４４の各処理部が適宜統合されてもよい。また、各処理部の処理が適宜複数の処理部の処理に分離されてもよい。さらに、各処理部にて行なわれる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。【００７７】
［運賃判定プログラム］
また、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することもできる。そこで、以下では、運行を支援する運賃判定プログラムを実行するコンピュータシステムの一例を説明する。図１７は、運賃判定プログラムを実行するコンピュータの構成の一例を示す図である。【００７８】
図１７に示すように、コンピュータ４００は、ＣＰＵ（Central  Processing  Unit）４１０、ＨＤＤ（Hard  Disk  Drive）４２０、ＲＡＭ（Random  Access  Memory）４４０を有する。これら４００〜４４０の各部は、バス５００を介して接続される。【００７９】
ＨＤＤ４２０には上記の算出部４１、格納部４２、受付部４３および出力部４４と同様の機能を発揮する運賃判定プログラム４２０Ａが予め記憶される。なお、運賃判定プログラム４２０Ａについては、適宜分離してもよい。【００８０】
また、ＨＤＤ４２０は、各種情報を記憶する。例えば、ＨＤＤ４２０は、記憶部２１と同様に、ＯＳや運行の支援に用いる各種データを記憶する。【００８１】
そして、ＣＰＵ４１０が、運賃判定プログラム４２０ＡをＨＤＤ４２０から読み出して実行することで、実施例の各処理部と同様の動作を実行する。すなわち、運賃判定プログラム４２０Ａは、算出部４１、格納部４２、受付部４３および出力部４４と同様の動作を実行する。【００８２】
なお、上記した運賃判定プログラム４２０Ａについては、必ずしも最初からＨＤＤ４２０に記憶させることを要しない。また、例えば、運賃判定プログラム４２０Ａは、コンピュータ４００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に記憶させてもよい。そして、コンピュータ４００がこれらからプログラムを読み出して実行するようにしてもよい。【００８３】
さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ４００に接続される「他のコンピュータ（又はサーバ）」などにプログラムを記憶させておく。そして、コンピュータ４００がこれらからプログラムを読み出して実行するようにしてもよい。
【符号の説明】
【００８４】
１０  運行支援システム
１１  サーバ装置
１２  事業者端末
２０  通信部
２１  記憶部
２２  制御部
３０  運行実績情報
３１  距離・所要時間テーブル
３２  運送基本契約情報
３３  請負情報
３４  運送事業者情報
４０  ルート検索部
４１  算出部
４２  格納部
４３  受付部
４４  出力部
【図１】
0006642707.tif 000002
【図２】
0006642707.tif 000003
【図３】
0006642707.tif 000004
【図４】
0006642707.tif 000005
【図５】
0006642707.tif 000006
【図６】
0006642707.tif 000007
【図７】
0006642707.tif 000008
【図８】
0006642707.tif 000009
【図９】
0006642707.tif 000010
【図１０】
0006642707.tif 000011
【図１１】
0006642707.tif 000012
【図１２】
0006642707.tif 000013
【図１３】
0006642707.tif 000014
【図１４】
0006642707.tif 000015
【図１５】
0006642707.tif 000016
【図１６】
0006642707.tif 000017
【図１７】
0006642707.tif 000018