JPWO2019039604A1 - 情報処理装置 - Google Patents

Abstract

移動体の最適なルートとして、運転手に課せられるコンプライアンスの制限も加味したルートを逐次決定し、物品をユーザから預かるサービス等を効率的に運営することができる技術を提供すること。拠点情報取得部８０が、複数の拠点毎に、当該拠点の存在位置と所定単位時間あたりの物品の入出量とを含む拠点情報を取得し、倉庫情報取得部８１が、複数の倉庫毎に、当該倉庫の存在位置と所定単位時間あたりの空き状況とを含む倉庫情報を取得し、運転手情報取得部８５が、所定のコンプライアンスの制限を含む運転手に関する運転手情報を取得し、ルート決定部８２が、複数の拠点毎の拠点情報と、複数の倉庫毎の倉庫情報と、運転手情報とに基づいて、１以上の移動体の夫々が移動するルートであって運転手の休息場所を含むルートを決定する。

Description

本発明は、情報処理装置に関する。

従来から、物流を効率的に行う方法には高い需要があり、そのための技術も数多く提案されている（例えば、特許文献１参照）。
上述の特許文献１に記載の技術によれば、荷物物流システムの円滑な運用を図るとともに、ユーザの問合せに対して荷物の運搬状況（現在位置等）を知らせることが出来る。このため、物品をユーザに配達するというようなサービスを行う場合には、非常に有用である。

特開２００７−３３４９０１号公報

しかしながら、例えば、タイヤ等の物品をユーザから預かるようなサービスを行う場合、荷物の運搬状況をユーザに知らせるだけではサービスを効率的に運用することは難しい。
このような場合には、ユーザがサービス提供者に対して効率的に物品を引き渡し、また、効率的に物品を受け取る必要がある。
特に、ユーザが引き渡すことを希望する物品が、タイヤのように重量のある物品であれば、物品を一度倉庫等に収納することも多く、複雑な経路を取る必要がある。
また、物品を輸送するための移動体（例えばトラック）を運転する運転手には、コンプライアンスの制限（例えば、１日の運転時間の制限）が課せれられる場合も多い。

本発明は、このような状況に鑑みてなされたものであり、物品を輸送する移動体の最適なルートとして、運転手に課せられるコンプライアンスの制限も加味したルートを逐次決定し、物品をユーザから預かるサービス等を効率的に運営することができる技術を提供することを目的とする。

上記目的を達成するため、本発明の一態様の情報処理装置は、
物品をユーザから引き取るか又はユーザに受け渡す複数の拠点と、物品を保管する複数の倉庫のうち、１の拠点と１の倉庫を少なくとも含むルートを経由して、１以上の物品を運搬する移動体のスケジュールを立案する情報処理装置であって、
前記移動体は、所定のコンプライアンスの制限が課されている運転手により運転され、
前記複数の拠点毎に、当該拠点の存在位置と所定単位時間あたりの物品の入出量とを含む拠点情報を取得する拠点情報取得手段と
前記複数の倉庫毎に、当該倉庫の存在位置と所定単位時間あたりの空き状況とを含む倉庫情報を取得する倉庫情報取得手段と、
前記所定のコンプライアンスの制限を含む前記運転手に関する運転手情報を取得する運転手情報取得手段と、
前記複数の拠点毎の前記拠点情報と、前記複数の倉庫毎の前記倉庫情報と、前記運転手情報とに基づいて、１以上の前記移動体の夫々が移動するルートであって前記運転手の休息場所を含むルートを決定するルート決定手段と、
を備える。

本発明によれば、移動体の最適なルートとして、運転手に課せられるコンプライアンスの制限も加味したルートを逐次決定し、物品をユーザから預かるサービス等を効率的に運営することができる技術を提供することができる。

本発明の一実施形態に係る情報処理システムの構成を示すブロック図である。 図１の情報処理システムのうち、本発明の一実施形態のサーバのハードウェア構成を示すブロック図である。 図１のサーバ、拠点端末、倉庫端末、ユーザ端末、及び運転手端末の機能的構成例を示す機能ブロック図である。 図３のサーバが実行するルート決定処理の結果の具体例を示す図である。 図３のユーザ端末に表示される、利用情報を提示する画面の一例を示す図である。 図３のサーバが実行するコンプライアンス付加型ルート決定処理の流れを説明するフローチャートである。 ユーザが荷物の輸送を依頼する際の入力フォームの具体例を示す図である。 ユーザが荷物の輸送を依頼する際の入力フォームの具体例を示す図である。 ユーザが荷物の輸送を依頼する際の入力フォームの具体例を示す図である。 入力フォームに入力された内容に基づき演算され表示された運行計画の具体例を示す図である。 入力フォームに入力された内容に基づき演算され表示された運行計画の具体例を示す図である。

以下、本発明の実施形態について、図面を用いて説明する。

図１は、本発明の一実施形態に係る情報処理システムの構成を示している。

図１に示す情報処理システムは、次のようなサービスを提供する際に適用される。
即ち、本発明に係る情報処理システムが適用されるサービスとは、ユーザのタイヤ等の物品を一定期間預かるサービス、換言すると、所定の物品を任意の拠点に引き渡し、その所定の物品を任意の拠点で引き取ることが出来るサービスである。
物品は特に限定されないが、説明の便宜上、タイヤであるとして以下の説明を行う。この場合、拠点とはディーラーやガソリンスタンド等、数日程度タイヤを一時保管できる場所である。
ユーザにより拠点に引き渡されたタイヤは、任意の倉庫まで輸送されて格納され、ユーザが引き取りを希望する場合には、その倉庫から任意の拠点に輸送され、その拠点でユーザに引き取られる。
なお、ユーザは、物品を引き渡した拠点と同一の拠点でタイヤを引き取ることも可能であるが、別の拠点でタイヤを引き取ることも可能である。
物品の輸送担当者は、所定の移動体（以下の例ではトラックであるとする）を用いて、１以上の拠点及び１以上の倉庫を含む所定のルートを回り、１以上のタイヤを運搬し、これらのタイヤの荷積み及びタイヤの荷卸しを行う。
また、物品の輸送担当者（以下の例ではトラックの運転手であるとし、単に運転手ということがある）には、所定のコンプライアンスの制限（例えば、１日の運転時間の制限）が課せられる。このため、上記ルートとしては、運転手が長時間の運転を行わないように、運転手の休息場所（例えば、宿泊所）を含むルートが決定される。
本実施形態の情報処理システムは、このようなサービスのもとで、運転手のコンプライアンスの制限を加味したうえで、移動体（トラック）の取るべき最適ルート（運転手の休息場所を含むルート）を決定することができる。

本実施形態の情報処理システムは、図１に示すように、上述のサービスの提供者により管理されるサーバ１と、ｍ箇所（ｍは１以上の任意の整数値）の拠点Ｋ−１乃至Ｋ−ｍの夫々において拠点管理者により使用される拠点端末２−１乃至２−ｍと、ｎ箇所（ｎは、ｍとは異なる１以上の任意の整数値）の倉庫Ｓ−１乃至Ｓ−ｎの夫々において倉庫管理者により使用される倉庫端末３−１乃至３−ｎと、ｐ人の（ｐは、ｍともｎとも異なる１以上の任意の整数値）ユーザの夫々により使用されるユーザ端末４−１乃至４−ｐと、ｑ箇所（ｑは、ｍともｎともｐとも異なる１以上の任意の整数値）のトラックＴ−１乃至Ｔ−ｑの夫々において当該トラックを運転する運転手により使用される運転手端末５−１乃至５−ｑとを含むように構成される。
サーバ１と、拠点端末２−１乃至２−ｍの夫々と、倉庫端末３−１乃至３−ｎの夫々と、ユーザ端末４−１乃至４−ｐの夫々と、運転手端末５−１乃至５−ｑの夫々とはインターネット等の所定のネットワークＮを介して相互に接続されている。

なお、以下、拠点端末２−１乃至２−ｍの夫々を個々に区別する必要がない場合、これらをまとめて「拠点端末２」と呼ぶ。
さらに、以下、倉庫端末３−１乃至３−ｎの夫々を個々に区別する必要がない場合、これらをまとめて「倉庫端末３」と呼ぶ。
そして、以下、ユーザ端末４−１乃至４−ｐの夫々を個々に区別する必要がない場合、これらをまとめて「ユーザ端末４」と呼ぶ。
そして、以下、運転手端末５−１乃至５−ｑの夫々を個々に区別する必要がない場合、これらをまとめて「運転手端末５」と呼ぶ。
同様に、以下、拠点Ｋ−１乃至Ｋ−ｍの夫々を個々に区別する必要がない場合、これらをまとめて「拠点Ｋ」と呼び、倉庫Ｓ−１乃至Ｓ−ｎの夫々を個々に区別する必要がない場合、これらをまとめて「倉庫Ｓ」と呼び、トラックＴ−１乃至Ｔ−ｑの夫々を個別に区別する必要がない場合、これらをまとめて「トラックＴ」と呼ぶ。

図２は、図１の情報処理システムのうちサーバ１のハードウェア構成を示すブロック図である。

サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

出力部１６は、各種液晶ディスプレイ等で構成され、各種情報を出力する。
入力部１７は、各種ハードウェア鉛等で構成され、各種情報を入力する。
記憶部１８は、ハードディスクやＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（図１の例では、拠点端末２、倉庫端末３、ユーザ端末４、運転手端末５等）との間で行う通信を制御する。

ドライブ２０は、必要に応じて設けられる。ドライブ２０には磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア２１が適宜装着される。ドライブ２０によってリムーバブルメディア２１から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。またリムーバブルメディア２１は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することが出来る。

拠点端末２、倉庫端末３、ユーザ端末４、及び運転手端末５の構成は、サーバ１の構成と基本的に同様であるので、ここではそれらの説明は省略する。

このような図２のサーバ１、拠点端末２、倉庫端末３、ユーザ端末４、及び運転手端末５の各種ハードウェアと各種ソフトウェアとの協働により、次のような一連の処理（以下、「コンプライアンス付加型ルート決定処理」と呼ぶ）の実行が可能となる。

即ち、拠点端末２−１乃至２−ｍの夫々は、単位時間（例えば１日）毎に、各拠点Ｋ−１乃至Ｋ−ｍの夫々におけるタイヤの入出量の情報（預かり／受け渡しの情報）や拠点の存在位置等の情報を取得し、サーバ１へと送信する。
このような拠点Ｋから得られる情報、例えば、拠点Ｋの位置情報、単位時間（例えば１日）毎のタイヤの預かり予定の時間帯別情報、単位時間（例えば１日）毎のタイヤの受け渡し予定の時間帯別情報等といった情報をまとめて、以下「拠点情報」と呼ぶ。
サーバ１は、単位時間（例えば１日）毎に、拠点端末２−１乃至２−ｍの夫々からの拠点情報を取得する。

倉庫端末３−１乃至３−ｎの夫々は、単位時間（例えば１日）毎に、各倉庫Ｓ−１乃至Ｓ−ｎの夫々における空き状況の情報（入庫／出庫の情報）や倉庫の存在位置等の情報を取得し、サーバ１へと送信する。
このような倉庫Ｓから得られる情報、例えば、倉庫Ｓの位置情報、単位時間（例えば１日）毎のタイヤの入庫予定の時間帯別情報、単位時間（例えば１日）毎のタイヤの出庫予定の時間帯別情報等の情報をまとめて、以下「倉庫情報」と呼ぶ。
サーバ１は、単位時間（例えば１日）毎に、倉庫端末３−１乃至３−ｎの夫々からの倉庫情報を取得する。

運転手端末５−１乃至５−ｑの夫々は、単位時間（例えば１日）毎に、各トラックＴ−１乃至Ｔ−ｑの夫々を運転する運転手のＩＤ情報や、当該運転手に課せられたコンプライアンスの制限の情報を取得し、サーバ１へと送信する。
なお、コンプライアンスの制限の情報は、運転手の運転に関して設けられる種々の制限情報であり、例えば、１日の運転時間に関する制限情報（例えば、８時間以内）や、深夜の連続運転時間に関する制限情報（例えば、２時間以内）や、連続勤務日数に関する制限情報（例えば、４日以内）が挙げられる。
このようなトラックＴから得られる当該トラックＴを運転する運転手に関する情報、例えば、運転手のＩＤ情報や、運転手に課せられたコンプライアンスの制限の情報をまとめて、以下「運転手情報」と呼ぶ。
サーバ１は、単位時間（例えば１日）毎に、運転手端末５−１乃至５−ｑの夫々からの運転手情報を取得する。

なお、上記では、運転手端末５−１乃至５−ｑの夫々から（つまり、トラックＴ−１乃至Ｔ−ｑの夫々から）運転手情報が取得されるものとしたが、運転手を管理する管理会社（本サービスの提供者と同じであってもよいし、異なってもよい）のサーバから、全ての運転手毎の運転手情報が単位時間（例えば１日）毎にサーバ１へ送信されるものとしてもよい。また、運転手にかかわらず、同一のコンプライアンスの制限の情報である場合には、当該制限の情報をサーバ１が予め記憶しているものとしてもよい。

サーバ１は、拠点端末２−１乃至２−ｍの夫々からの拠点情報、倉庫端末３−１乃至３−ｎの夫々からの倉庫情報、及び運転手端末５−１乃至５−ｑの夫々からの運転手情報を取得すると、これらの情報に基づいて、１以上のタイヤを１以上のトラックが運搬するための最適なルートであって、運転手情報（コンプライアンスの制限の情報）に基づいて運転手の休息場所を含む最適ルート（以下、「コンプライアンス付加型最適ルート」と呼ぶ）を決定する。
なお、ここで言うコンプライアンス付加型最適ルートは、運転手の休息場所を含んで決定可能であるため、長時間の移動を要するルートであってもよく、したがって、複数の地域（例えば複数の都道府県に跨った地域）の情報から決定される。

ユーザ端末４は、タイヤの預かりのサービスが可能か否かの情報（以下、「利用情報」と呼ぶ）をユーザに提示する。
具体的には例えば「利用情報」は、ある拠点Ｋのある時間帯において、ユーザがタイヤの引き渡しが可能か否かといった情報や、ある拠点Ｋのある時間帯において、ユーザがタイヤの引き取りを可能か否かの情報を含む。
この利用情報は、上述のコンプライアンス付加型最適ルートが決定された際に、単位時間（例えば１日）毎の各拠点Ｋや各倉庫Ｓの空き情報に基づいて、サーバ１により生成される。

このような一連の処理がコンプライアンス付加型ルート決定処理である。
このコンプライアンス付加型ルート決定処理を実現すべく、サーバ１、拠点端末２、倉庫端末３、ユーザ端末４、及び運転手端末５は、図３に示すような機能的構成を有している。
図３は、図１のサーバ１、拠点端末２、倉庫端末３、ユーザ端末４、及び運転手端末５の機能的構成例を示す機能ブロック図である。

拠点端末２のＣＰＵ４０においては、拠点情報管理部５０と、拠点情報送信制御部５１とが機能する。
倉庫端末３のＣＰＵ６０においては、倉庫情報管理部７０と、倉庫情報送信制御部７１とが機能する。
サーバ１のＣＰＵ１１においては、拠点情報取得部８０と、倉庫情報取得部８１とルート決定部８２と、利用情報要求取得部８３と、利用情報通知部８４と、運転手情報取得部８５が機能する。
運転手端末５のＣＰＵ３００においては、運転手情報管理部３１０と、運転手情報送信制御部３２０とが機能する。
ユーザ端末４のＣＰＵ１０２においては、利用情報要求受付部１２０と、利用情報要求送信制御部１２１と、利用情報取得部１２２と、利用情報提示部１２３とが機能する。

拠点端末２−Ｍ（Ｍは、１乃至ｍのうち任意の整数値）の拠点情報管理部５０は、拠点Ｋ―Ｍについての、単位時間（例えば１日）当たりのタイヤの入出量と拠点の位置情報とを含む拠点情報を取得し、管理する。
拠点情報送信制御部５１は、拠点情報管理部５０により管理されている拠点情報を、単位時間（例えば１日）毎に、通信部４１を介してサーバ１へ送信するための制御を実行する。

倉庫端末３―Ｎ（Ｎは、１乃至ｎのうち任意の整数値）の倉庫情報管理部７０は、倉庫Ｓ−Ｎについて、単位時間（例えば１日）当たりの空き状況と倉庫の位置情報とを含む倉庫情報を取得し、管理する。
倉庫情報送信制御部７１は、倉庫情報管理部７０により取得された倉庫情報を、単位時間（例えば１日）毎に、通信部６１を介してサーバ１へ送信するための制御を実行する。

運転手端末５―Ｑ（Ｑは、１乃至ｑのうち任意の整数値）の運転手情報管理部３１０は、トラックＴ−Ｑを運転する運転手について、当該運転手に課せられたコンプライアンスの制限の情報を含む運転手情報を取得し、管理する。
運転手情報送信制御部３２０は、運転手情報管理部３１０により取得された運転手情報を、単位時間（例えば１日）毎に、通信部３０１を介してサーバ１へ送信するための制御を実行する。

ユーザ端末４の利用情報要求受付部１２０は、ユーザからの利用情報の要求を、タッチ操作入力部１００を介して受け付ける。
利用情報要求送信制御部１２１は、利用情報要求受付部１２０により受け付けられた利用情報要求を、通信部１０３を介してサーバ１へ送信するための制御を実行する。
サーバ１は、コンプライアンス付加型最適ルートに基づき決定された利用情報をユーザ端末４へ送信する。
すると、利用情報取得部１２２は、サーバ１から送信されてきた利用情報を取得する。
そして、利用情報提示部１２３は、利用情報取得部１２２により取得された利用情報を表示部１０１に表示させる制御を実行することで、ユーザに提示する。

サーバ１の拠点情報取得部８０は、複数の拠点Ｋ−１乃至Ｋ−ｍ毎に、単位時間（例えば１日）あたりのタイヤの入出量と拠点の位置情報とを含む拠点情報を取得する。即ち、所定の拠点端末２から拠点情報が送信されてくる毎に、拠点情報取得部８０は、その拠点情報を取得する。
また、倉庫情報取得部８１は、複数の倉庫Ｓ−１乃至Ｓ−ｎ毎に、単位時間（例えば１日）あたりの空き状況と倉庫の位置情報とを含む倉庫情報を取得する。即ち、所定の倉庫端末３から倉庫情報が送信されてくる毎に、倉庫情報取得部８１は、その倉庫情報を取得する。
また、運転手情報取得部８５は、複数のトラックＴ−１乃至Ｔ−ｑ毎に、単位時間（例えば１日）あたりの運転手情報を取得する。即ち、所定の運転手端末５から運転手情報が送信されてくる毎に、運転手情報取得部８５は、その運転手情報を取得する。

ルート決定部８２は、単位時間（例えば１日）毎に、複数の拠点Ｋ−１乃至Ｋ−ｍ毎の拠点情報と、複数の倉庫Ｓ−１乃至Ｓ−ｎ毎の倉庫情報と、複数のトラックＴ−１乃至Ｔ−ｑ毎の運転手情報に基づいて、１以上のトラックの夫々が移動するルートとして、コンプライアンス付加型最適ルートを決定する。
ルート決定部８２はまた、コンプライアンス付加型最適ルートに基づいて利用情報を生成する。

利用情報要求取得部８３は、ユーザ端末４から送信されてきた利用情報の要求を取得する。
そして、利用情報通知部８４は、利用情報要求取得部８３により利用情報の要求が取得されると、ルート決定部８２により生成された利用情報を、通信部１９を介して、当該要求をしてきたユーザ端末４へ通知する。

図４は、図３のサーバ１が実行するコンプライアンス付加型ルート決定処理の結果の具体例を示す図である。
図４の例では、ディーラーの拠点ＫＡと、ディーラーの拠点ＫＢと、ガソリンスタンドの拠点ＫＧＳと、倉庫Ｓａと、倉庫Ｓｂと、倉庫Ｓｃとを含む所定範囲（例えば東京と大阪とを含む広域）においてトラックＭ１が移動する際のコンプライアンス付加型最適ルートの決定の様子が表されている。

図４の例では、拠点ＫＡの拠点端末２は、次の単位時間（例えば１日）ではタイヤＴ１とＴ２を引き取る予定がある旨を示す拠点情報Ａをサーバ１に送信する。拠点ＫＢの拠点端末２は、次の単位時間（例えば１日）ではタイヤの引き取りと受け取りは無い旨を示す拠点情報Ｂをサーバ１に送信する。拠点ＫＧＳの拠点端末２は、次の単位時間（例えば１日）ではタイヤの引き取りと受け取りは無い旨を示す拠点情報ＧＳをサーバ１に送信する。
サーバ１の拠点情報取得部８０（図３参照）は、これらの拠点情報Ａ,Ｂ，ＧＳの夫々を通信部１９を介して取得する。

図４の例では、倉庫Ｓａの倉庫端末３は、次の単位時間（例えば１日）では空きが無い旨と当該倉庫Ｓａの位置情報とを示す倉庫情報ａをサーバ１に送信する。倉庫Ｓｂの倉庫端末３は、次の単位時間（例えば１日）では空きが１つある旨と倉庫Ｓｂの位置情報（例えば東京）とを示す倉庫情報ｂをサーバ１に送信する。倉庫Ｓｃの倉庫端末３は、次の単位時間（例えば１日）では空きが１つある旨と倉庫Ｓｃの位置情報（例えば大阪）を示す倉庫情報ｃをサーバ１に送信する。
サーバ１の倉庫情報取得部８１（図３参照）は、これらの倉庫情報ａ,ｂ，ｃの夫々を通信部１９を介して取得する。
なお、サーバ１に送信される倉庫情報には、所定単位時間あたりの空き状況と倉庫の位置情報が含まれているものとしているが、所定単位時間あたりの空き状況として空きが無い旨の情報が送信される場合には、倉庫の位置情報は送信されないものとしてもよい。空きが無い倉庫では、物品（タイヤ）を保管することができないため、当該倉庫を経由するルートが決定されることはなく、そのため、当該倉庫の位置情報は不要となるためである。

図４の例では、トラックＭ１の運転手端末５は、当該トラックＭ１を運転する運転手に課せられたコンプライアンスの制限の情報として、１日の運転時間が８時間以内であることを示す運転手情報ｍ１をサーバ１に送信する。
サーバ１の運転手情報取得部８５（図３参照）は、この運転手情報ｍ１を通信部１９を介して取得する。

サーバ１のルート決定部８２（図３参照）は、これらの拠点情報Ａ,Ｂ，ＧＳ、倉庫情報ａ,ｂ，ｃ、及び運転手情報ｍ１に基づいて、図４に示す様なルートを、次の単位時間（例えば１日）におけるトラックＭ１のコンプライアンス付加型最適ルートとして決定する。
即ち、トラックＭ１は、最初に拠点ＫＡにてタイヤＴ１とＴ２を積み込み、倉庫Ｓｂ（東京）まで運搬してタイヤＴ１を積み下ろし、その後、そのまま倉庫Ｓｃ（大阪）に向かうとコンプライアンスの制限の情報（１日の運転時間が８時間以内）に違反してしまうので、倉庫Ｓｃに向かう経路途上の所定位置（例えば浜松）において休息をとり（例えば宿泊し）、その後、倉庫ＳｃまでタイヤＴ２を運搬して積み下ろす、といったルートがコンプライアンス付加型最適ルートとして決定される。

なお、休息場所をどのように決定するかは種々の方法が考えられる。例えば、所望の休息場所として、複数の位置情報（例えば、浜松、名古屋、京都）をサーバ１に送信することで、サーバ１が休息場所を記憶管理し、倉庫Ｓｂ（東京）から倉庫Ｓｃ（大阪）に向かう経路上で最も近い休息場所を第１候補として決定する。そして、サーバ１は、この第１候補に到着するまでに要する運転時間がコンプライアンスの制限の情報（例えば８時間以内）に違反しているか否かを判定し、違反していなければ、当該第１候補を休息場所として決定し、違反していれば、第１候補の次に経路上に近い休息場所を第２候補として決定する。このように、第ｋ候補（ｋは１以上の整数）に到着するまでに要する運転時間がコンプライアンスの制限の情報に違反していれば、第ｋ候補の次に経路上に近い第ｋ＋１候補がコンプライアンスの制限の情報に違反していないかを確認するというステップを、コンプライアンスの制限の情報に違反しない第ｍ候補（ｍは１以上の整数）が見つかるまで繰り返し、第ｍ候補を休息場所として決定する。

また、サーバ１は、休息場所の決定のみならず、運転手情報に基づいて休息場所での休息期間も決定するものとしてもよい。例えば、コンプライアンスの制限の情報に、連続運転時間が４時間を超えると最低１時間休息するという情報が含まれているときに、到着までに４時間以上の運転時間を要する休息場所が決定された場合には、当該休息場所において１時間以上の休息期間を決定するものとする。

また、図４の例では、特定のトラックＭ１の運転手に課せられたコンプライアンスの制限の情報（運転手情報ｍ１）に基づいて、特定のトラックＭ１のコンプライアンス付加型最適ルートが決定されるものとした。しかし、全てのトラックＴ−１乃至Ｔ−ｑのうちいずれのトラックをタイヤ運搬の対象車両とするかの決定を含めて、コンプライアンス付加型最適ルートが決定されるものとしてもよい。具体的には、トラックＴ−１乃至Ｔ−ｑの夫々の運転手端末５から送信される運転手情報ｍ−１乃至ｍ−ｑには、各運転手の現在の運転状況に関する情報（例えば、現在の運転時間に関する情報）が含まれているものとして、それぞれの運転手情報に基づいて、どの運転手のトラックを対象車両とするかが決定されるものとしてもよい。例えば、対象車両の決定の優先順位としては、現在の連続運転時間が少ない運転手のトラックが対象車両として決定され易いものとしてもよいし、月あたりの稼働が低い運転手のトラックが対象車両として決定され易いものとしてもよいし、目的地に近い運転手のトラックが対象車両として決定され易いものとしてもよい。このようにして、複数のトラックのうち、特定のトラックが対象車両として決定され、当該特定のトラックに対してコンプライアンス付加型最適ルートが決定される。

そして、ルート決定部８２は、このようにして決定したコンプライアンス付加型最適ルートに基づいて、図５に示す様な利用情報を決定する。
図５は、図３のユーザ端末に表示される、利用情報を提示する画面の一例を示す図である。

図５に示すように、次の単位時間（例えば今日）における、タイヤの引き取りが可能か否か、タイヤの受け渡しが可能か否かを各拠点Ｋ毎に時間帯別に示す利用情報が、ユーザ端末４の表示部１０１（図３参照）に表示されることで、ユーザに提示される。
具体的には例えば、図４の例の利用情報を示す画面１０１には、拠点Ｋ毎に、ユーザがタイヤを預けること（各拠点ｋにとっては引き取り）が可能な時間帯を示す領域２０１と、ユーザがタイヤを返却してもらうこと（各拠点ｋによっては受け渡し）が可能な時間帯を示す領域２０２とが表示される。

例えば、ユーザは、拠点ＫＡでは１３時から１６時の時間帯であれば余裕をもってタイヤを預けることが可能であり、１０時から１３時の時間帯であれば、わずかにタイヤを預けることが可能であることを容易に視認できる。
さらにユーザは、図４の例では、タイヤを預けることが可能な時間帯であれば、領域２０１の右部に表示されている予約ボタンを押下することで、タイヤの予約をすることもできる。

同様に例えば、ユーザは、拠点ＫＡでは１３時から１６時の間であればわずかにタイヤを返却してもうらことが可能であり、それ以外の時間帯では、タイヤを返却してもらうことが不可能であることを容易に視認できる。
そのため、ユーザは、タイヤを返却してもらうことが可能な１３時から１６時の時間帯であれば、右部に表示されている予約ボタンを押下することで、タイヤの受け取りの予約をすることができる。

このように、ユーザは、タイヤを引き取ってもらいたい場合や受け取りたい場合に、引き取りが可能な拠点や受け渡しが可能な拠点を容易かつ即座に知ることができ、必要に応じてその場で引き取りや受け渡しの予約をすることもできる。

次に、図６を参照して、図３の機能的構成を有するサーバ１が実行するコンプライアンス付加型ルート決定処理について説明する。
図６は、サーバ１が実行するルート決定処理の流れを説明するフローチャートである。

ステップＳ１において、拠点情報取得部８０は、拠点情報が送信されてきたか否かを判定する。
拠点端末２−１乃至２−ｍの何れからも拠点情報が送信されてこなければ、ステップＳ１においてＮＯであると判定されて、処理はステップＳ３に進む。
これに対して、拠点端末２−Ｍ（Ｍは１乃至ｍのうち何れかの整数値）から拠点情報が送信されてきていれば、ステップＳ１においてＹＥＳであると判定されて、処理はステップＳ２に進む。
ステップＳ２において、拠点情報取得部８０は、拠点端末２−Ｍからの拠点情報を取得する。

ステップＳ３において、倉庫情報取得部８１は、倉庫情報が送信されてきたか否かを判定する。
倉庫端末３−１乃至３−ｎの何れからも倉庫情報が送信されてこなければ、ステップＳ３においてＮＯであると判定されて、処理はステップＳ１に戻される。
これに対して、倉庫端末３−Ｎ（Ｎは１乃至ｎのうち何れかの整数値）から倉庫情報が送信されてきていれば、ステップＳ３においてＹＥＳであると判定されて、処理はステップＳ４に進む。
ステップＳ４において、倉庫情報取得部８１は、倉庫端末３−Ｎからの倉庫情報を取得する。

ステップＳ５において、運転手情報取得部８５は、運転手情報が送信されてきたか否かを判定する。
運転手端末５−１乃至５−ｑの何れからも運転手情報が送信されてこなければ、ステップＳ５においてＮＯであると判定されて、処理はステップＳ１に戻される。
これに対して、運転手端末５−Ｑ（Ｑは１乃至ｑのうち何れかの整数値）から倉庫情報が送信されてきていれば、ステップＳ５においてＹＥＳであると判定されて、処理はステップＳ６に進む。
ステップＳ６において、運転手情報取得部８５は、運転手端末５−Ｑからの運転手情報を取得する。

ステップＳ７において、ルート決定部８２は、所定の時間（例えば、１日等の単位時間）が経過したか否かを判定する。
所定の時間が経過していなければ、ステップＳ７においてＮＯであると判定されて、処理はステップＳ１に戻される。即ち、所定の時間が経過するまでの間、ステップＳ１乃至Ｓ７のループ処理が繰り返されて、各拠点Ｋからは拠点情報が、各倉庫Ｓからは倉庫情報が、各トラックＴからは運転手情報が、夫々取得されていく。
所定の時間が経過すると、ステップ７においてＹＥＳと判定されて、処理はステップＳ８に進む。

ステップＳ８において、ルート決定部８２は、ステップＳ２で取得された拠点情報とステップＳ４で取得された倉庫情報とステップＳ６で取得された運転手情報とから、タイヤを輸送するトラックのコンプライアンス付加型最適ルートを決定する。

以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。
また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙に過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。

上述の実施形態では、物品としてタイヤを、物品を輸送するための移動体としてトラックを用いて説明を行ったが、これらは説明のための例時に過ぎず、特にこれに限定されない。
例えば、ユーザが引き渡す物品としては置物や家具等、発明の目的を達成するための範囲で、いかなる物品でも構わない。
また、例えば、物品を輸送するための移動体としてはバイクや乗用車等、いかなる輸送車両を用いても構わない。

また、上述の実施形態では、ルート決定部８２がコンプライアンス付加型最適ルートを決定する方法及び利用情報を決定する方法については、特に規定していないが、いかなる方法を用いることも出来る。
即ち、本発明の目的を達成するための範囲において、どのような手段やアルゴリズムを用いることも可能である。

また、上述の実施形態では、拠点情報と倉庫情報と運転手情報のみを考慮してコンプライアンス付加型最適ルートを決定していたが、移動体の移動距離をさらに考慮してもよい。
即ち、ルート決定部８２は、複数の拠点及び複数の倉庫の夫々の２点間の距離に基づいて、１以上の移動体の夫々が移動するルートを決定してもよい。
これにより、より精度よく、移動体のコンプライアンス付加型最適ルート及びユーザの利用情報を決定することが出来る。

また、上述の実施形態では、季節や天気の情報を考慮することなくコンプライアンス付加型最適ルートを決定していたが、季節や天気の情報をさらに考慮してもよい。
例えば、雨の日には運転手に課せられたコンプライアンスの制限の情報よりも厳しい制限の情報が課せられるものとし、当該制限の情報に基づいてコンプライアンス付加型最適ルートが決定されるものとしてもよい。
これにより、より精度よく、移動体のコンプライアンス付加型最適ルート及びユーザの利用情報を決定することが出来る。

また、上述の実施形態では、使用する移動体の取得可否の情報や貸与の形態（賃料等）の情報を考慮することなくコンプライアンス付加型最適ルートを決定していたが、使用する移動体の取得可否や貸与の形態（賃料等）の情報をさらに考慮してもよい。
これにより、より実用的に、移動体のコンプライアンス付加型最適ルート及びユーザの利用情報を決定することが出来る。

また、上述の実施形態では、使用する移動体の数や容量の情報を考慮することなくコンプライアンス付加型最適ルートを決定していたが、使用する移動体の数や容量の情報をさらに考慮してもよい。
これにより、より精度よく、移動体のコンプライアンス付加型最適ルート及びユーザの利用情報を決定することが出来る。

また、本発明の情報処理装置によれば、以下のような処理を行うことで、コンプライアンス遵守が考慮された最適な運行計画を立案することもできる。
即ち、従来からある運送システムでは、出発地から到着地までの距離と荷物の重量とに基づいて荷物を輸送する車両を決定するのが一般的であった。これは、従来からある運送システムが、荷主と運送会社との間の物流契約に基づいて処理を行う仕様になっていたことが理由の１つになっている。
これにより、従来からある運送システムでは、運転手の労働時間に関するコンプライアンスを考慮できないため、運送会社の配車スタッフが、運送会社の事情、運転手の事情等を考慮して、配車業務を行っていた。
しかしながら、物流量が激増するとともに、コンプライアンス遵守が常識となった今日では、コンプライアンスの考慮をすべて配車スタッフ任せにすることは適切ではない。
そこで、本発明の情報処理装置によれば、コンプライアンス遵守が考慮された最適な運行計画を決定することができる。これにより、例えばコンプライアンス遵守の有無に関する官公庁（例えば日本の労働基準監督署）による抜き打ちの巡回調査等に容易に対応することもできる。具体的には、コンプライアンス遵守を証明するための書面等のエビデンスを容易に生成することもできる。

さらに、国際的な視点でコンプライアンスを遵守することもできる。具体的には、運転手の労働時間だけではなく、労働条件についても考慮した運行計画を決定することができる。例えば、ヨーロッパでは、運転手が１人で持つことができる最大重量が決まっているが、これに対応することもできる。つまり、労働条件として、運転手が１人で持つことができる最大重量を考慮することにより、運転手の体力や健康状態が考慮された運行計画を決定することができる。

さらに、運転手の残業時間が考慮された運行計画の決定を行うこともできる。従来は、例えば今月の残業可能時間等の情報が共有されないまま配車業務が行われていたため、コンプライアンス上問題があったが、残業可能時間等が考慮された運行計画を決定することができる。

図７乃至図９は、ユーザが荷物の輸送を依頼する際の入力フォームの具体例を示す図である。

図７乃至図９に示す入力フォームに各種情報が入力されると、運転手の労働時間、休憩、休息期間、睡眠時間、及び労働負荷等についてのコンプライアンスが考慮された、運行計画が決定される。

図７に示すように、（１）の入力項目には、「荷物情報」として、輸送する荷物の重量（ｋｇ）を入力する欄が設けられている。この欄に、「４９００」（ｋｇ）と入力すると、荷物の輸送に使用できるトラックの候補が表示される。トラックの候補は、「車番」、「車格」、「積載重量」、「荷物重量」、「可能重量」、及び「重量判定」の各情報で表示される。具体的には、車番（車両番号）が「山梨１００か ＸＸ−ＸＸ」、車格が「１３ｔウイング車」、積載重量が「１３０００」（ｋｇ）、荷物重量が「４９００」（ｋｇ）、可能重量が「８１００」（ｋｇ）、重量判定が「●」（即ち合格）であるトラックと、その他２台のトラックが候補として表示されている。なお、その他２台のトラックを示す各情報は、図７に記載のとおりである。
ユーザは、候補として表示されたトラックの中から、所望のトラックを選択する。具体的には、「選択」欄にチェックを入れる操作を行うことで選択する。

また、図７に示すように、（２）の入力項目には、「配達情報」として、輸送する荷物の「出発地」と「到着地」とを入力する欄が設けられている。「出発地」を入力する欄に、「東京都小平市」と入力し、「到着地」を入力する欄に、「愛知県名古屋市」と入力すると、輸送する総距離が自動計算されて表示される。具体的には、「距離」の欄に「３４７ｋｍ」と表示される。
また、輸送する総距離とともに、輸送条件を示す情報が自動計算されて表示される。表示される輸送条件には、行きの輸送条件として、「行き運転時間」、「休憩」、「休息期間」、「待機」、及び「積込」が表示されるとともに、帰りの輸送条件として、「帰り運転時間」、「休憩」、「休息期間」、及び「拘束時間」の各種情報が含まれる。具体的には、行きの輸送条件として、行き運転時間が「２４０」（分）、休憩が「３０」（分）、休息期間が「０」（分）、待機が「３０」（分）、積込が「６０」（分）と表示されている。また、帰りの輸送条件として、帰り運転時間が「２４０」（分）、休憩が「３０」（分）、休息期間が「０」（分）、拘束時間が「６３０」（分）と表示されている。
さらに、「作業時間」と「手待ち時間」からなる「労働時間」と、「休憩時間」の各種情報が表示される。具体的には、作業時間が「５４０」（分）、手待ち時間が「３０」（分）、休憩時間が「６０」（分）と表示されている。なお、「手待ち時間」とは、労働時間に含められるものの、実際には作業を行っていない待機時間のことをいう。

また、図８に示すように、（３）の入力項目には、納品時刻を指定するために、輸送する荷物の「到着時刻」を入力する欄が設けられている。「到着時刻」を入力する欄に、例えば「９：３０」と入力すると、出発時刻が自動計算されて表示される。具体的には、「出発時刻」の欄に「４：３０」と表示されるとともに、運転手の候補者が表示される。即ち、到着時刻が入力されると、（２）で自動計算された輸送条件に基づいて出発時刻が自動計算される。そして、出発時刻が自動計算されると、輸送条件のうち後述する休息期間、睡眠時間、及び免許の条件を満たす運転手の候補が表示される。即ち、表示される運転手の候補は、「帰社時刻」、「判定」、「休息期間」、「名前」、「年齢」、「免許」、及び「運転歴」の各種情報で表示される。具体的には、直近の帰社時刻が「１８：００」、判定が「○」（即ち輸送条件を満たす）、休息期間が「１０時間３０分」、名前が「山田太郎」、年齢が「３５歳」、免許が「大型」、及び運転歴が「１３年」である運転手と、その他２人が運転手の候補として表示されている。なお、その他２人の候補を示す各情報は、図８に記載のとおりである。

ここで、画面には表示されないが、輸送条件を満たさないために運転手の候補から外れた者として、４人を例に挙げて説明する。
即ち、直近の帰社時刻が「２１：００」、休息期間が「７時間３０分」、名前が「秋山六郎」、年齢が「２５歳」、免許が「大型」、及び運転歴が「５年」である者は、休息期間の判定が「×」（即ち輸送条件を満たさない）となっている。また、直近の帰社時刻が「２３：００」、休息期間が「５時間３０分」、名前が「羽田七郎」、年齢が「２７歳」、免許が「大型」、及び運転歴が「７年」である者は、休息期間の判定が「×」（即ち輸送条件を満たさない）となっている。これは、いずれの者についても、休息期間が継続して８時間以上必要とされる休息期間の輸送条件を満たさないからである。
これに対して、直近の帰社時刻が「１８：００」、休息期間が「１０時間３０分」、名前が「佐藤四郎」、年齢が「２５歳」、免許が「中型」、及び運転歴が「３年」である者は、休息期間の判定が「○」（即ち輸送条件を満たす）となっている。また、直近の帰社時刻が「１８：００」、休息期間が「１０時間３０分」、名前が「林五郎」、年齢が「１８歳」、免許が「準中型」、及び運転歴が「１年」である者も、休息期間の判定が「○」（即ち輸送条件を満たす）となっている。しかしながら、この２人は、免許が適合しないため、運転手の候補から外れている。

また、図９に示すように、（４）の入力項目には、作業負荷や作業の難度を演算するために、「荷物情報」として、具体的な荷物の内容を入力する欄が設けられている。「荷物情報」を入力する欄に、例えば「飲料（紙パック）」、「９８０ケース」と入力又は選択すると、荷物重量（４９００ｋｇ）が自動表示されるとともに、「難度」、「作業条件」、「作業量」、「作業重量」の各情報で表示される、作業負荷や作業の難度が自動的に演算されて表示される。具体的には、難度が「Ａ」、作業条件が「手積み手卸」、作業量が「１９６０ケース」、作業重量が「９８００ｋｇ」である作業と、難度が「Ｂ」、作業条件が「パレット積手卸」、作業量が「９８０ケース」、作業重量が「４９００ｋｇ」である作業と、難度が「Ｃ」、作業条件が「パレット積パレット卸」、作業量が「０ケース」、作業重量が「０ｋｇ」である作業とが選択できるように表示される。

ここで、図９に示すように難度Ｂが選択されると、作業条件としての「パレット積手卸」を行うことができる者が運転手の候補として表示される。即ち、運転手の候補は、「帰社時刻」、「自宅待機時間（睡眠時間目安）」、「名前」、「年齢」、「健康状態」、及び「労働負荷」の各種情報で表示される。具体的には、直近の帰社時刻が「１８：００」、自宅待機時間（睡眠時間目安）が「１０時間３０分」、名前が「山田太郎」、年齢が「３５歳」、健康状態が「◎」、及び労働負荷が「手積み可能」である者と、直近の帰社時刻が「１９：００」、自宅待機時間（睡眠時間目安）が「９時間３０分」、名前が「木村次郎」、年齢が「４５歳」、健康状態が「○」、及び労働負荷が「手積み可能」である者と、直近の帰社時刻が「１７：３０」、自宅待機時間（睡眠時間目安）が「１１時間」、名前が「鈴木三郎」、年齢が「５５歳」、健康状態が「△」、及び労働負荷が「腰痛持ち本人確認」である者との３人が選択できるように表示されている。
ここで、候補者の健康状態を示す記号のうち、「◎」は、難度Ａ、Ｂ、及びＣのいずれの作業も行うことができることを示している。また、「○」は、難度Ｂ、Ｃのどちらの作業も行うことができることを示し、「△」は、難度Ｃの作業のみを行うことができることを示している。つまり、運転手の候補として表示された３人のうち、名前が「鈴木三郎」である候補者については、腰痛持ちであることについて本人の確認がとれているとして、難度Ｃの作業（パレット積パレット卸）のみを行うことができるということになる。
このように、コンプライアンス付加型ルート決定処理によれば、コンプライアンス遵守はもちろんのこと、運転手個人の健康状態の管理を含めた労務管理を適切に運営することができる。

図７乃至図９に示す入力フォームへの入力が完了すると、その入力内容に基づく運行計画が自動的に演算されて表示される。
図１０及び図１１は、入力フォームに入力された内容に基づき演算され表示された運行計画の具体例を示す図である。

図１０に示すように、（５）運行計画は、「運転手の名前」、「車番」及び「車格」からなる「車両情報」の各種情報で表示されるとともに、「出発時刻」、「休憩開始」、「休憩終了」、「到着時刻」、「待機開始」、「待機終了」、「積込開始」、「積込終了」、「出発時刻」、「休憩開始」、「休憩終了」、及び「帰社時刻」の各種情報で表示される。
具体的には、まず出発から現地に到着するまでの具体的な運行計画として、「出発時刻」には「１０月２８日」の「４：３０」に「東京都小平市」を出発することが表示されており、「休憩開始」には「１０月２８日」の「７：３０」から「○○パーキング」で休憩を開始することが表示されており、「休憩終了」には「１０月２８日」の「８：００」に「○○パーキング」での休憩が終了することが表示されており、「到着時刻」には「１０月２８日」の「９：００」に「愛知県名古屋市」に到着することが表示されている。
続いて、現地に到着してから積込作業が完了するまでの具体的な運行計画として、「待機開始」には「１０月２８日」の「９：００」から「愛知県名古屋市」で待機を開始することが表示されており、「待機終了」には「１０月２８日」の「９：３０」に「愛知県名古屋市」での待機が終了することが表示されており、「積込開始」には「１０月２８日」の「９：３０」から「愛知県名古屋市」で積込作業を開始することが表示されており、「積込終了」には「１０月２８日」の「１０：３０」に「愛知県名古屋市」での積込作業が終了することが表示されている。
さらに続いて、積込作業が完了してから帰社するまでの具体的な運行計画として、「出発時刻」には「１０月２８日」の「１０：３０」に「愛知県名古屋市」を出発することが表示されており、「休憩開始」には「１０月２８日」の「１３：３０」から「○○パーキング」で休憩を開始することが表示されており、「休憩終了」には「１０月２８日」の「１４：００」に「○○パーキング」での休憩が終了することが表示されており、「帰社時刻」には「１０月２８日」の「１５：３０」に「東京都小平市」に到着することが表示されている。また、運転手を拘束する時間の合計を示す「拘束時間」が「１１時間」であることと、運転手が行うこととなる残業の時間を示す「残業時間」が「３時間」であることとが表示されている。

また、図１１には、仮に図１０に示す運行計画が実行された場合、その後どのような影響があるのかについての演算結果が示されている。
即ち、図１１に示すように、運転手の今月の残業時間の累計を示す「運転手山田太郎の１０月の累計残業時間」が「３８時間」になることと、運転手の今月の残業可能時間を示す「運転手山田太郎の１０月の残業時間残り」が「１時間」になることとが表示されている。
また、図１０に示す運行計画が実行された後の定期便への影響が表示されている。具体的には、「山田太郎定期便運行」が、「運行日」及び「判定」の夫々の情報で表示されている。即ち、「１０月２９日」の定期便、及び「１０月３０日」の定期便について、いずれも「×」（即ち運行不可能）であることが表示されている。
ここで、図１１に示す「判定」の内容は、労働条件、月間運行スケジュール、及びタイムカードからの各種情報に基づいて決定される。労働条件には、例えば労働基準法第３６条の規定に基づく労使協定からの情報を含めることができる。具体的には、延長できる時間が１日あたり３時間、２週間の合計が２５時間、１ケ月の合計が４２時間、１年の合計が３２０時間、といった情報を含めることができる。月間運行スケジュールには、例えば運転手の定期便に関する情報を含めることができる。具体的は、１日の拘束時間が１０時間、残業時間が２時間、といった情報を含めることができる。タイムカードには、例えば運転手の労働時間の実績に関する情報を含めることができる。このような情報に基づいて、上述の例の場合であれば、運転手「山田太郎」は、定期便の運行について、１日あたり２時間残業するルート設定がなされている。即ち、運転手「山田太郎」が、図１０に示す運行計画に従って１０月２８日の運行を実行すると、今月の残業可能時間は１時間になる。その結果、１日あたり２時間残業する必要がある１０月２９日の定期便と１０月３０日の定期便とをいずれも運行することができなくなる。つまり、山田太郎が１０月２８日の運行を実行した場合には、翌日（１０月２９日）、及び翌々日（１０月３０日）の山田太郎の定期便についての判定は「×」となり、誰か別の運転手が応援に入るか、外部に業務委託して対応する必要があるということが示される。
このように、運行計画とともに、その運行計画を実行することによるその後の影響についても表示されるので、コンプライアンスを遵守した計画的な運行を実現させることができる。また、図１０に示す運行計画は、１日分の運行計画であるが、この運行計画に基づいて、１週間分、１ケ月分、１年分といった長期の運行計画を立案することもできる。

また、上述の実施形態では、本発明の情報処理システムは、サーバ１、拠点端末２、倉庫端末３、ユーザ端末４、運転手端末５により構成されていたが、本発明の目的を達成するための例時に過ぎず、特に限定されない。

また、図２に示す各ハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。

また、図３に示す機能ブロック図は、例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行出来る機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは、特に図３の例に限定されない。すなわち、コンプライアンス付加型最適ルートを決定するための一連の処理は、単一の情報処理装置（例えばサーバ１）によって実現されてもよいし、複数の情報処理装置（サーバ１、運転手端末５等）からなる情報処理システムによって実現されてもよい。

また、機能ブロックの存在場所も、図３に限定されず、任意で良い。例えばサーバ１側の機能ブロックの少なくとも一部を拠点端末２、倉庫端末３、ユーザ端末４、運転手端末５のいずれかの側に設けても良いし、その逆でも良い。
そして、１つの機能ブロックは、ハードウェア単体で構成しても良いし、ソフトウェア単体との組み合わせで構成しても良い。

また、上述の実施形態では拠点端末２、倉庫端末３、ユーザ端末４、及び運転手端末５はスマートフォンで構成されていたが、スマートフォンだけでなく、タブレットや今後の新しいデバイスを含めた任意の装置で構成することも出来る。

各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであっても良い。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであっても良い。

このようなプログラムを含む記録媒体は、各ユーザにプログラムを提供するために装置本体とは別に配布される、リムーバブルメディアにより構成されるだけではなく、装置本体に予め組み込まれた状態で各ユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に添って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。

以上まとめると、本発明が適用される情報処理装置は、次のような構成を取れば足り、各種各様な実施形態を取ることが出来る。
即ち、本発明が適用される情報処理装置は、
物品をユーザから引き取るか又はユーザに受け渡す複数の拠点と、物品を保管する複数の倉庫のうち、１の拠点と１の倉庫を少なくとも含むルートを経由して、１以上の物品を運搬する移動体のスケジュールを立案する情報処理装置（サーバ１）であって、
前記移動体は、所定のコンプライアンスの制限が課されている運転手により運転され、
前記複数の拠点毎に、当該拠点の存在位置と所定単位時間あたりの物品の入出量とを含む拠点情報を取得する拠点情報取得手段（例えば、図３の拠点情報取得部８０）と、
前記複数の倉庫毎に、当該倉庫の存在位置と所定単位時間あたりの空き状況とを含む倉庫情報を取得する倉庫情報取得手段（例えば、図３の倉庫情報取得部８１）と、
前記所定のコンプライアンスの制限を含む前記運転手に関する運転手情報を取得する運転手情報取得手段（例えば、図３の運転手情報取得部８５）と、
前記複数の拠点毎の前記拠点情報と、前記複数の倉庫毎の前記倉庫情報と、前記運転手情報とに基づいて、１以上の前記移動体の夫々が移動するルートであって前記運転手の休息場所を含むルートを決定するルート決定手段（例えば、図３のルート決定部８２）と、
を備える情報処理装置であれば足りる。
このような情報処理装置を適用することで、物品預かりサービス等において、移動体の最適なルートとして、運転手のコンプライアンスの制限も加味したルートを逐次決定し、その結果として、物品をユーザから預かるサービス等を効率的に運営することができる技術を提供することが出来る。

１・・・サーバ、２、２−１乃至２−ｍ・・・拠点端末、３、３−１乃至３−ｎ・・・倉庫端末、４、４−１乃至４−ｐ・・・ユーザ端末、５−１乃至５−ｑ・・・運転手端末、１１・・・ＣＰＵ、４０・・・ＣＰＵ、５０・・・拠点情報管理部、５１・・・拠点情報送信制御部、６０・・・ＣＰＵ、７０・・・倉庫情報管理部、７１・・・倉庫情報送信制御部、８０・・・拠点情報取得部、８１・・・倉庫情報取得部、８２・・・ルート決定部、８３・・・利用情報要求取得部、８４・・・利用情報通知部、８５・・・運転手情報取得部、１０２・・・ＣＰＵ、１２０・・・利用情報要求受付部、１２１・・・利用情報要求送信制御部、１２２・・・利用情報取得部、１２３・・・利用情報提示部、３００・・・ＣＰＵ、３１０・・・運転手情報管理部、３２０・・・運転手情報送信制御部

Claims (1)

1. 物品をユーザから引き取るか又はユーザに受け渡す複数の拠点と、物品を保管する複数の倉庫のうち、１の拠点と１の倉庫を少なくとも含むルートを経由して、１以上の物品を運搬する移動体のスケジュールを立案する情報処理装置であって、
   前記移動体は、所定のコンプライアンスの制限が課されている運転手により運転され、
   前記複数の拠点毎に、当該拠点の存在位置と所定単位時間あたりの物品の入出量とを含む拠点情報を取得する拠点情報取得手段と
   前記複数の倉庫毎に、当該倉庫の存在位置と所定単位時間あたりの空き状況とを含む倉庫情報を取得する倉庫情報取得手段と、
   前記所定のコンプライアンスの制限を含む前記運転手に関する運転手情報を取得する運転手情報取得手段と、
   前記複数の拠点毎の前記拠点情報と、前記複数の倉庫毎の前記倉庫情報と、前記運転手情報とに基づいて、１以上の前記移動体の夫々が移動するルートであって前記運転手の休息場所を含むルートを決定するルート決定手段と、
   を備える情報処理装置。

Images