JP2021182293A - 配送マッチングシステム - Google Patents

Abstract

【課題】 荷主と配送者とをマッチングさせる方法を提供する。【解決手段】 荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムであって、同一料金で配送可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶する拠点データベースと、前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付ける配送依頼受付部と、前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応答を受けた場合には、両者をマッチングさせるマッチング処理部とを備えることを特徴とする。【選択図】 図１

Description

本発明は、配送サービスにおいて、荷主と配送者とをマッチングさせる方法に関する。

荷物の配送サービスにおいて、種々の求貨求車システム、すなわち配送マッチングシステムが知られ、現に利用されている。主なものとして、空車を探す荷物の荷物情報と荷物を探す配送会社の空車情報をインターネット上でマッチングさせるものがある。例えば、特許文献１は、車主が受け付け可能な荷物の条件を登録しておき、荷主が配送を希望する荷物について名称、積地、降地などの荷物情報を登録すると、この荷物を受け付け可能な車主に、荷物情報が配信されることで、両者のマッチングを行う技術を開示する。特許文献２は、タクシーの共同配車システムにおいて、顧客から配車要求を受け付けると、まず、これに合致する自社のタクシーを検索し、見つからなかった場合は、他社のタクシーを検索するという技術を開示する。

特許４１６３４６５号公報 特許４２６７８５０号公報

しかし、従来の配送マッチングシステムでは、荷主は、荷物の情報を詳細に入力しなければ配送依頼をすることができず、利便性に欠けていた。
本発明の課題は、上記従来の実情に鑑み、配送依頼を行う際の入力を軽減し、配送マッチングシステムの利便性を向上させることを目的とする。

本発明は、荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムであって、
同一料金で配送可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶する拠点データベースと、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付ける配送依頼受付部と、
前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応諾を受けた場合には、両者をマッチングさせるマッチング処理部と、
前記荷物の配送に関して、前記基準料金に基づいて前記荷主への課金処理と、前記配送者への支払い処理とを行う精算処理部とを備えることを特徴とする。

本発明は、配送元、配送先が各拠点内にある限り、拠点間の配送については、荷物に依らず基準料金に基づいて課金がなされる。従って、本発明によれば、荷主は、荷物ごとの重量および寸法を入力するまでなく、配送元と配送先などの必要最小限の情報を登録して配送依頼を行うことができる。荷物ごとの重量および寸法は、重量、サイズなど、荷物の計測を伴う情報が求められることが多いため、荷物ごとの重量および寸法を省略できるということは、配送依頼を行う際の手間を軽減し、非常に簡便に配送者を探すことができる。
なお、本発明において、例えば、配送を依頼する荷物に、重量物、貴重品、特大サイズ物品が含まれるか否かといった情報を含めることは、差し支えない。かかる情報を含めたとしても、荷物ごとの計測をする必要はないため、配送依頼の負担を増やすものではないからである。

本発明において、拠点とは、ある特定の営業所などを意味するのではなく、一定の広さを有する範囲を意味する。例えば、東京都、名古屋市などのように行政界に基づいて設定してもよい。この場合は、東京都内から名古屋市内への配送であれば、配送元、配送先がどの住所であっても、基準料金が適用されることになる。拠点は、特定の地点から半径○ｋｍの円内というように定めても良い。その他、任意の方法で決めることができる。また、複数の拠点の広さは、同一である必要はない。
拠点が３以上存在する場合、いずれの拠点間でも共通の基準料金としてもよいし、拠点に応じて異なる基準料金としてもよい。同じ拠点間に対して、往復で異なる基準料金を用いてもよい。
また、基準料金は固定料金とは異なる。基準料金に対して、後述する通り、所定の条件で割増、割引を適用してもよい。

引受拠点は荷物を発送する拠点内の住所地、納品拠点は荷物を届ける住所地を意味する。
配送依頼には、この他、集荷日時や配送日時などの情報を含めても良い。日常的に繰り返し荷物を発送するような場合には、集荷日時を指定することを省略可能としてもよい。

また、本発明は、前記配送マッチングシステムにおいて、
前記マッチング処理部は、予め登録された車両情報または配送者の属性が配送依頼に応じた条件に合致する配送者にのみ前記配送依頼を送信するシステムとすることもできる。

そうすることにより、一部の配送者に絞って配送依頼を送信することができる。例えば、荷主に有利となる配送者に絞って配信すれば、荷主に有利にマッチングさせることができる。また、それぞれの配送者にとって有利な条件の配送依頼のみを配信すれば、応諾率を向上させることができ、結果として荷主の選択の余地を広げることができる。

また、本発明において、前記マッチング処理部は、時間の経過とともに段階に前記条件を緩和して前記配送依頼を送信するシステムとすることもできる。

そうすることにより、一部の配送者を優先してマッチングさせるとともに、優先して配送依頼を通知した配送者により受諾の応答がなかった場合においても、配送契約を成立させる可能性を高めるという効果を合わせもつことができる。
上記態様において、条件を緩和するタイミングは、種々の設定が可能である。例えば、予め定めた時間を経過してもマッチングが成立していないときに、条件を緩和してもよい。また、応諾件数が所定数に達してもマッチングが成立していないときに、条件を緩和してもよい。その他、種々のタイミングをとり得る。

また、本発明は、前記配送者を絞り込む条件として、帰り便という条件を用いるシステムとすることもできる。

帰り便とは、ある拠点まで配送を終えた後、自身の拠点に帰ろうとする配送者を利用することを言う。帰り便は、配送者にとっては、復路においても荷物を積載して無駄なく配送することが可能となる利点がある。また、その分、配送料を安価にできれば、荷主にとっても利点がある。上記態様では、このように利点の高い帰り便を優先してマッチングさせることが可能となる。

また、本発明は、さらに、前記マッチング処理部は、前記配送依頼に応諾した配送者のいずれかを制限時間内に荷主が選定しない場合には、所定の条件に基づいて応諾した配送者のいずれかを選定して前記荷主とマッチングさせるシステムとすることもできる。

そうすることにより、荷主が任意の配送者を選定することができ、何らかの理由により選定しない場合においてもマッチングさせることが可能となり、マッチングの成立可能性を向上させることができる。
配送者を選定するための条件は、種々の設定が可能である。例えば、料金が安い配送者、応諾が早かった配送者などとしてもよい。また、過去の配送依頼に対する評価が高い配送者としてもよい。
上記態様は、逆に言えば、制限時間に至るまでは、荷主は、応諾してきた複数の配送者から任意に相手を選択可能であることになる。このように制限時間を設けることにより、荷主は、配送者が応諾してきた時点で速やかに依頼するか否かを判断する必要がなくなり、自身にとって、より有利な配送者が応諾するのを待つことが可能となる。

また、本発明は、前記精算処理部は、帰り便の条件によりマッチングさせた場合は、前記基準料金よりも割り引いた料金を適用するシステムとすることもできる。

上記態様において、割引率は、配送システムが設定してもよいし、配送者が任意に設定してもよい。
また、割引率は、拠点にかかわらず一定としてもよいし、配送元、配送先の拠点に応じて変化させてもよい。

本発明は、さらに、前記精算処理部は、荷主が、配送に利用される車種を限定した場合は、限定に応じて基準料金よりも割り増した料金を適用するシステムとすることもできる。

上記態様において、割増率は、配送システムが設定してもよいし、配送者が任意に設定してもよい。
また、割増率は、車種にかかわらず一定としてもよいし、車種ごとに変化させてもよい。

そして、本発明は、さらに、前記精算処理部は、荷主が配送者を選定した後に配送者がキャンセルした場合の再配送依頼に対しては、基準料金よりも割り引いた料金を適用するシステムとすることもできる。

配送者によって配送がキャンセルされることは、荷主に不利益を与えるとともに、配送サービスに対する信頼喪失にもつながるおそれがある。上記態様では、かかる事態に、荷主に割り引いた料金を提示することができるため、キャンセルによって荷主が受けた不利益を緩和することができる。
配送料を割り引くことによる損失は、新たな配送者が負うものとしてもよいが、配送をキャンセルした配送者に負わせても良い。本発明では、配送システムが、荷主に対する課金と、配送者に対する支払いとを実行するため、例えば、配送をキャンセルした時点で、配送者から制裁金を徴収し、これを割り引いた分の配送料に補填するようにすればよい。こうすれば、荷主には割引料金を適用しつつ、新たな配送者には、正規料金で支払いを行うことが可能となる。

また、本発明は、前記マッチング処理部は、前記配送依頼に応諾した配送者の属性を前記荷主に提示するシステムとすることもできる。

こうすれば、荷主は、配送者の属性を確認して、配送を依頼する配送者を選択することができる。属性としては、配送者が使用している車種の情報、配送者の自己ＰＲ情報などを含めることができる。

本発明は、さらに、前記配送者の属性には、過去に配送依頼を行った荷主による該配送者に対する評価が含まれるシステムとすることもできる。

こうすれば、過去の実績に対する客観的な情報を踏まえて配送者を選定することが可能となる。

そして、本発明は、さらに、
前記配送者の属性の登録内容を前記配送者から受け付けて反映させるためのプロフィール登録部を有し、
前記精算処理部は、前記登録内容に応じて、該配送者への支払い条件を変動させるシステムとすることもできる。

そうすることにより、荷主側がよりよいサービス提供を求めて、依頼したい配送者を選定することが可能となる。配送者側は、よりよいサービスの提供を掲げることにより、全体として、本システムにより提供される配送サービスの向上が図られる。

また、本発明は、前記配送者の車両の位置情報に基づき、該車両が前記引受住所地に至った後、所定の距離以上ずれたことを検出した場合に、前記荷物の前記配送者による引受完了として、前記配送を管理する配送管理部を備えるシステムとすることもできる。

本発明においては、荷主と配送者とをマッチングさせた後、荷物の引渡から配送が完了するまでの配送管理を行うことが好ましい。このとき、荷主の配送者への引渡を適切に管理するためには、その旨の入力を、配送者ではなく荷主に行わせることが好ましいと言える。
しかし、この場合、今度は、荷主が、引渡完了の操作を失念した場合、配送管理に支障が生じることになる。上記態様では、配送者の位置情報に基づいて、荷物の引受場所に訪れた後、所定の距離離れたという事実を検出したときは、引渡が完了したものと扱うため、荷主が操作を失念した場合でも、配送管理に支障が生じることを回避できる。

本発明においては、以上で説明した種々の特徴を必ずしも全て備えている必要はなく、適宜、その一部を省略したり組み合わせたりすることができる。
また、本発明は、システムとしての態様に限らず、荷主と配送者とをマッチングさせる方法として構成することもできる。
その場合、
コンピュータにより、荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせるマッチング方法であって、
コンピュータが実行するステップとして、
同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶するステップと、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付けるステップと、
前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応答を受けた場合には、両者をマッチングさせるステップとを備えるマッチング方法と構成することができる。

さらに、本発明は、荷主側端末機あるいは配送者側端末機に用いられるコンピュータプログラムと構成することもできる。
この場合、
荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記荷主が利用する荷主側端末機に用いられるコンピュータプログラムであって、
同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを参照する機能と、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を送信する機能と、
前記配送依頼に対する前記配送者とのマッチングの結果を受信して表示する機能とを実現するコンピュータプログラム、
あるいは、
荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記配送者が利用する配送者側端末機に用いられるコンピュータプログラムであって、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を受信して表示する機能と、
前記配送依頼を受諾する旨の指示を送信する機能とを実現するコンピュータプログラムと構成することができる。

さらに、本発明は、上述のコンピュータプログラムを記録したコンピュータで読み取り可能な記録媒体として構成してもよい。

配送マッチングシステム全体の構成を示す説明図である。 拠点データベースの構造を示す説明図である。 荷主データベース、依頼データベース及び配送者データベースの各構造とそれらの結びつきを示す説明図である。 本システムにおけるシステムサーバ、荷主側端末及び配送者側端末での処理の流れを示すフローチャートである。 プロフィール登録処理のフローチャートである。 配送依頼処理のフローチャート（１）である。 配送依頼処理のフローチャート（２）である。 マッチング処理のフローチャート（１）である。 マッチング処理のフローチャート（２）である。 応諾処理のフローチャートである。 キャンセル処理のフローチャートである。 荷物引受処理のフローチャートである。 配送完了処理のフローチャートである。 料金計算処理のフローチャートである。

以下、本発明の実施形態の一例としての配送マッチングシステムを添付の図面を参照して、以下の順序で説明する。
Ａ．全体構成：
Ｂ．データベース構造：
Ｃ．配送サービスの全体処理：
Ｃ−１．プロフィール登録処理：
Ｃ−２．配送依頼処理：
Ｃ−３．マッチング処理：
Ｃ−４．応諾処理：
Ｃ−５．キャンセル処理：
Ｃ−６．荷物引受処理：
Ｃ−７．配送完了処理：
Ｃ−８．料金計算処理：
Ｄ．効果および変形例：

Ａ．全体構成：
図１は、配送マッチングシステム全体の構成を示す説明図である。本システム全体は、システムサーバ１００、荷主側端末２００、配送者側端末３００及びこれらを繋ぐインターネットなどのネットワークで構成される。
荷主側端末２００、配送者側端末３００は、インターネットを介した情報の授受が可能な携帯電話、スマートフォン、タブレットなどの携帯端末を利用できる。携帯性を重視しない場合は、コンピュータを用いても良い。
配送マッチングシステムは、荷主が、荷物の配送を希望するときに、荷主側端末２００から配送依頼をシステムサーバ１００に送信すると、システムサーバ１００が、その配送依頼を配送者側端末３００に送信し、荷主と配送者とをマッチングさせるシステムである。図の例では、荷主側端末２００、配送者側端末３００をそれぞれ１つだけ示しているが、これらは、荷主、配送者ともに利用者の数だけ存在する。

システムサーバ１００、荷主側端末２００、配送者側端末３００には、それぞれ図示する機能部が構成されている。本実施例では、これらの機能部は、それぞれの機能を実現するためのコンピュータプログラムを、インストールすることによりソフトウェア的に構成した。機能部の一部または全部は、ハードウェア的に構成するものとしてもよい。
以下、各機能部の内容について説明する。

（１）システムサーバ１００の機能部：
システムサーバ１００には、図示する通り以下の４種類のデータベースが用意されている。
拠点データベース１２１は、配送マッチングシステムにおける拠点の情報、および拠点間の基準料金の情報などを記憶するデータベースである。拠点の意味については、後述する。
荷主データベース１２２は、荷物の配送を依頼する荷主の名称その他の情報を記憶するデータベースである。
配送者データベース１２３は、荷物を配送する配送者の名称その他の情報を記憶するデータベースである。
依頼データベース１２４は、荷主が登録した荷物の配送依頼を記憶するデータベースである。
荷主データベース１２２、配送者データベース１２３、依頼データベース１２４の構造は、後述する。

主制御部１１０は、配送マッチングシステムにおいて荷主と配送者とをマッチングするサービス（以下、「配送サービス」と呼ぶ）の全体の処理を制御する。
送受信部１３０は、インターネットを介して、荷主側端末２００、配送者側端末３００と配送依頼その他の情報を授受する機能を奏する。
配送依頼受付部１３１は、荷主側端末２００から送信された配送依頼を受け付け、依頼データベース１２４に登録する。
マッチング処理部１３２は、依頼データベース１２４に登録されている配送依頼について、荷主と配送者とをマッチングする処理を実行する。
キャンセル処理部１３３は、配送依頼について、荷主または配送者からキャンセルがされたときの処理を実行する。
配送管理部１３４は、マッチングが成立した後の配送の実施状況を管理する。
プロフィール登録部１３５は、配送者側端末３００からプロフィールを受け取り、これを配送者データベース１２３に登録する。
精算処理部１３６は、配送依頼について費用の精算を行う。

上述の機能部の構成は、一例に過ぎず、これらの一部を省略したり、一部の機能部を複数の細分化した機能部で構成したり、逆に複数の機能部を統合してもよい。図１に示した以外の機能部を設けることも差し支えない。また、本実施例では、上述の各機能部は、１台のシステムサーバ１００によって提供される例を示したが、各機能部をネットワークで接続された複数のサーバによる分散システムとして構築することも可能である。

（２）荷主側端末２００の機能部：
荷主側端末２００の機能部について説明する。
送受信部２０１は、インターネットを介してシステムサーバ１００との間で配送依頼その他の情報を授受する。
ブラウザ２０２は、配送サービスに関する種々の情報のインタフェース画面を提供する。本実施例では、インタフェース画面は、ＨＴＭＬその他の形式でシステムサーバ１００から提供され、これをブラウザ２０２で表示する方法をとった。こうすることにより、汎用的な携帯端末を荷主側端末２００として利用することができる。ブラウザ２０２は、汎用のものでもよいし、配送サービス専用のアプリとして構成してもよい。
コマンド入力部２０３は、キーボード、タッチパネル等の操作を介して荷主の入力を受け付ける。
送受信部２０１、コマンド入力部２０３は、荷主側端末２００にインストールされているＯＳの機能を用いることができる。

（３）配送者側端末３００の機能部：
配送者側端末３００の機能部について説明する。
送受信部３０１は、インターネットを介してシステムサーバ１００との間で配送依頼その他の情報を授受する。
コマンド入力部３０２は、キーボード、タッチパネル等の操作を介して配送者の入力を受け付ける。
送受信部３０１、コマンド入力部３０２は、配送者側端末３００にインストールされているＯＳの機能を用いることができる。

また、配送者側端末３００には、配送者用アプリ３１０がインストールされている。配送者用アプリ３１０は、以下の機能部を構築する。これらの機能は、ブラウザを利用して提供してもよい。
位置情報送信部３１１は、配送者側端末３００の位置情報をＧＰＳ等で検出し、これをシステムサーバ１００に送信する。この位置情報は、例えば、配送状況の管理などに利用される。
プロフィール管理部３１２は、配送者が、システムサーバ１００に登録するためのプロフィール情報の作成、管理、システムサーバ１００への登録を行う。
配送依頼管理部３１３は、配送者が応諾した配送依頼を管理する。

図２は、拠点データベースの構造を示す説明図である。拠点とは、配送サービスにおいて、荷物の配送元、配送先として受け付け可能な領域を意味する。本実施例では、東京、名古屋、大阪の３つを拠点としたが、拠点数、拠点の場所は、任意に決めることができる。荷物の配送料金は、配送元、配送先の住所、荷物の内容にかかわらず、拠点間で統一の基準料金が適用される。拠点とは、このように統一料金を適用する範囲という意味も有している。拠点データベース１２１は、拠点についてのデータを図示する形式で記憶する。

拠点情報とは、拠点の範囲を特定する情報である。本実施例では、それぞれの拠点を円形の範囲としており、その中心の緯度経度および半径で特定している。この半径は、同一料金で配送する範囲を定めるものであるから、道路状況、配送に要する所要時間などを考慮して、設定すればよい。半径は、拠点ごとに異なっていても良い。図の例では、東京については半径５０ｋｍとし、名古屋については半径５５ｋｍとした。東京の混雑する道路状況を踏まえ、若干狭く設定してある。

配送基準データは、各拠点間の配送について、基準料金および基準の配送時間を記憶する。図の例では、東京から名古屋に配送する場合の基準料金は「○○○円」、基準の配送時間は７時間と設定されている。東京から大阪に配送する場合についても図示する通り設定されている。また、名古屋から東京に配送する場合の基準料金は「△△△円」、基準の配送時間は７．５時間と設定されている。このように、東京〜名古屋間であっても、どちらを配送元、配送先にするかで、基準料金、基準の配送時間を変えても良い。もちろん、両者共通の基準料金、配送時間としても差し支えない。

図３は、荷主データベース、依頼データベース及び配送者データベースの各構造とそれらの結びつきを示す説明図である。
荷主データベース１２２において、荷主ＩＤは、新たに登録をしたときにシステムサーバ１００によって与えられる荷主に固有の識別情報である。荷主データベース１２２には、荷主ＩＤと紐付けて、名称、連絡先などの情報が登録される。支払情報は、費用の支払いに利用する金融機関、クレジットカードなどの情報である。依頼履歴は、配送サービスの利用履歴が記憶される。本実施例では、依頼データベース１２４において配送依頼ごとに付与される依頼ＩＤを記憶するものとした。
課金情報は、配送依頼に対する課金処理の結果を記憶している。日時、依頼ＩＤに紐付けて配送依頼で課金された金額、および支払いが完了したか否かの「支払」情報が記憶されている。

依頼データベース１２４は、配送依頼を記憶するデータベースである。新たに配送依頼がなされるごとに、システムサーバ１００によって、固有の識別情報としての依頼ＩＤが付され、図示する一連のレコードが生成される。
レコードには、依頼ＩＤに紐付けて配送依頼をした荷主を特定するための荷主ＩＤが記憶される。また、依頼内容が登録される。本実施例では、「荷物引受」とは配送元の住所、「配送先」は配送先の住所である。また、「３０ｋｇ以上の荷物」とは、重量物の有無の情報である。「車種」は、冷蔵など、荷物を配送する際の車種を指定する情報である。「マッチングタイム」とは、詳しくは後述するが、配送依頼を登録した後、配送者からの応諾を待つ許容時間を表している。
「配送者ＩＤ」は、配送者データベース１２３において配送者ごとに付される固有の識別情報である。依頼データベース１２４では、配送依頼に対してマッチングされた配送者の配送者ＩＤが記憶されることになる。
ステータスは、配送依頼の処理状況を表す情報である。本実施例では、図示する通り、マッチング待ち、マッチング済などのステータスごとに定められたコードを記憶するものとした。
「評価」、「レビュー」は、配送者に対する荷主の評価および荷主の自由記載によるコメントである。
「課金結果」は、配送依頼に対する課金の金額を記憶する。

配送者データベース１２３は、配送者に関する情報を記憶する。配送者ＩＤは、新たに配送者が登録をしたときに、システムサーバ１００によって付される配送者固有の識別情報である。配送者ＩＤに紐付けて、配送者の名称、連絡先などが登録される。
車種は、配送者が配送に利用する車輌の分類を、図示する分類コードで記憶する。
口座情報は、配送者の金融機関の情報である。本実施例では、配送料金の精算は、荷主と配送者との間で直接に行うのではなく、荷主から配送サービスの運用者が受領し、これを配送者に仲介することで行っている。従って、配送者データベース１２３には、このための口座情報が記憶されているのである。
プロフィールは、配送者が自身に対して登録する種々の情報である。この情報を記入することにより、配送者は、自身を荷主にアピールでき、荷主から選択してもらう可能性を向上させることができる。
評価は、配送者に対する種々の荷主からの総合評価である。
依頼履歴は、配送者が担当した配送依頼の履歴を記憶する。本実施例では、依頼データベース１２４における依頼ＩＤを記憶する方法をとっている。
ステータスは、配送者の現状を表す情報である。本実施例では、待機、配送、帰還、ＯＦＦなどのステータスを、それぞれのコードで記憶するものとした。この情報は、随時上書きで更新されるものとしてもよいし、履歴の形で記憶するものとしてもよい。また、ステータスとして、本実施例では、ＧＰＳ、即ち配送者の位置情報も記憶している。ＧＰＳについても、随時更新してもよいし、履歴として記憶してもよい。
報酬情報は、配送者に対して支払われた金銭の情報である。日時、配送依頼の依頼ＩＤ、および支払われた金額、その支払い状況が記憶されている。

荷主データベース１２２、配送者データベース１２３、および依頼データベース１２４には、それぞれ図示した以外の情報を記憶させてもよいし、図示した情報の一部を省略してもよい。
また、データベース全体の構造についても、図示した例に限らず、種々の構造をとり得る。

Ｃ．配送サービスの全体処理：
次に、配送サービスの全体処理の概要について説明する。それぞれの処理の詳細な内容は後述する。
図４は、本システムにおけるシステムサーバ１００、荷主側端末２００及び配送者側端末３００での処理の流れを示すフローチャートである。

配送者は、配送者側端末３００に組み込まれた配送者アプリ３１０を起動させて、コマンド入力部３０２の操作により、名称、連絡先、車種、口座情報、プロフィール等の配送者情報を入力し、プロフィール登録操作を行う（ステップｃ１）。配送者情報は送受信部３０１よりネットワークを介して、システムサーバ１００内の配送者データベース１２３に送信され、システムサーバ１００は、配送者のプロフィール登録処理を行う（ステップｂ１）。

荷主は、荷主側端末２００のブラウザ２０２を通じてコマンド入力部２０３の操作により、名称、連絡先、支払情報等の荷主情報を入力した後、送受信部２０１よりネットワークを介して、システムサーバ１００内の荷主データベース１２２にプロフィール登録を行うことにより、配送サービスを利用することができるようになる。

荷物の配送を依頼するときは、荷主は、荷主側端末２００を用いて配送依頼処理を行う（ステップａ１）。配送依頼処理により、配送依頼の情報は、ネットワークを介してシステムサーバ１００内の配送依頼受付部１３１で受信される。

システムサーバ１００は、配送依頼を依頼データベース１２４に登録し、以下に示す手順で、マッチング処理を行う（ステップｂ２）。まず、システムサーバ１００は、配送依頼を配送者側端末３００に送信する。配送者が、配送依頼を確認し、これに応じるために配送者側端末３００で応諾処理を行うと、配送者側端末３００は、応諾の通知をシステムサーバ１００に送信する（ステップｃ２）。システムサーバ１００は、応諾した配送者の情報を荷主側端末２００に送信する。依頼者である荷主が、荷主側端末２００において、該配送依頼に対して応諾した複数の配送者一覧を見て、任意の配送者を選定し、正式に依頼する操作を行うと、荷主側端末２００は、正式依頼通知をシステムサーバ１００に送信する（ステップａ２）。これによって、荷主と配送者のマッチングが完了する。

マッチングが完了した後、荷主または配送者が、配送依頼をキャンセルする場合もある。荷主からのキャンセル指示（ステップａ３）、または配送者からのキャンセル指示（ステップｃ３）がなされると、システムサーバ１００は、それぞれの指示に応じたキャンセル処理を行う。

双方からキャンセルがなされない場合、配送者は配送依頼で指定された配送元に集荷し、荷物の引受を行う。集荷にあたっては、配送者側端末３００は、配送者の操作に従って引受開始情報をシステムサーバ１００に送信する（ステップｃ４）。また、荷物の引受が完了すると、荷主側端末２００は引受完了情報をシステムサーバ１００に送信する（ステップａ４）。システムサーバ１００は、これらの情報に基づいて、荷物引受処理を実行して（ステップｂ４）、配送依頼のステータスを更新する。

配送者が配送している間（ステップｃ５）、システムサーバ１００は、ＧＰＳなどの情報によって、配送者の位置情報を検出する（ステップｂ５）。この間、荷主はシステムサーバ１００に問い合わせることにより、配送状況を確認することができる（ステップａ５）。

配送が完了し、配送者が、配送者側端末３００によって、配送完了情報をシステムサーバ１００に送信すると（ステップｃ６）、システムサーバ１００は、配送完了情報を荷主側端末２００に送信する。荷主が配送を完了したことを確認し、承諾すると（ステップａ６）、システムサーバ１００は、配送完了処理を実行し（ステップｂ６）、配送依頼のステータスを更新する。

配送が完了すると、システムサーバ１００は、配送依頼について、課金、報酬処理を行い（ステップｂ７）、料金を計算する。
また、荷主は、配送についてレビューをシステムサーバ１００に送信することができる（ステップａ７）。このレビューは、配送者情報の一部として登録され、以後、新たな荷主が、配送者を選択するために参照される。
以上が配送サービスの概要であるが、以下、システムサーバ１００内における各処理について説明する。

Ｃ−１．プロフィール登録処理：
図５は、プロフィール登録処理のフローチャートである。図４のステップｂ１の処理に相当する。主としてプロフィール登録部１３５（図１）が実行する処理であり、ハードウェア的にはシステムサーバ１００が実行する処理である。
この処理は、配送者が、荷主にアピールするために、自身のプロフィールを登録するための処理である。配送者は、予めシステムサーバ１００に登録されており、自身の識別情報としての配送者ＩＤが付与されているものとする。
処理を開始すると、システムサーバ１００は、配送者ＩＤを配送者側端末３００から読み込む（ステップＳ１）。

そして、システムサーバ１００は、配送者側端末３００に、プロフィール入力画面を表示する（ステップＳ２）。配送者が既に登録済みのプロフィールがある場合、システムサーバ１００は、その情報も読み込み、入力画面に表示する。
図中に入力画面の例を示した。配送者は、氏名、年齢、血液型、写真などを登録できる。また、趣味や自己ＰＲなども登録できる。これらの情報は、配送依頼をした荷主が閲覧できるため、荷主の関心をひく内容を記載すれば、依頼を受けられる可能性を高めることができる。
また、配送者は、車種、車検証、荷室サイズなど、自身が使用する車輌の情報も入力する。車種は、軽バン、軽幌車、軽冷蔵車、その他のように予め定められた分類（図３参照）から選択する方法をとっている。車両の名称を入力するようにしても差し支えないが、このように分類を入力することにより、荷主は、自身の要求に応じた車両か否かを判断しやすくなる利点がある。
配送者は、「割引」を登録することもできる。先に図２で説明した通り、配送サービスでは、拠点に応じて設定された基準料金が適用されるが、配送者が「割引」を設定すると、配送料金は、設定に応じて割り引いた金額となる。
プロフィールは、この他にも、種々の情報を登録可能としてもよい。配送者のプロフィールは、既存の情報を更新することも可能である。

配送者がプロフィールを入力すると、システムサーバ１００は、配送者側端末３００から、プロフィールを受け付け（ステップＳ３）、入力された項目あるいは更新された項目に応じて配送者にポイントを付与する（ステップＳ４）。このポイントは、たとえば自動換金により配送者に対する報酬となる。本実施例では、ポイント付与することにより、配送者に、プロフィールを更新する動機付けを与えているのである。
システムサーバ１００は、配送者データベース１２３に記憶された情報を更新し（ステップＳ５）、プロフィール登録処理を終了する。

Ｃ−２．配送依頼処理：
図６、図７は、配送依頼処理のフローチャートである。図４のステップａ１の処理に相当する。主としてシステムサーバ１００の配送依頼受付部１３１（図１）が提供する画面に従って、荷主側端末２００が実行する処理である。この処理は、例えば、荷主が荷主側端末２００によって配送サービスのＷＥＢページにアクセスし、基本メニューから「配送依頼」を選択することによって開始する方法をとることができる。

処理を開始すると、荷主側端末２００は、過去の配送依頼の再利用か否かを判断する（ステップＳ１０）。荷主側端末２００に過去の配送依頼を利用するか否かの問合わせ画面を表示するようにしてもよい。また、配送依頼を開始するためのメニューを、通常の「配送依頼」および「配送依頼（再利用）」のように分けて用意しておいてもよい。

過去の配送依頼の再利用の場合、荷主側端末２００は、システムサーバ１００から、荷主からの過去の配送依頼を受信し、これをリスト表示し、その選択を受け付ける（ステップＳ１１）。
図に、リストの例を示した。この例では、配送者がキャンセルした配送依頼、配送済みのものを含め、過去に依頼した配送依頼が表示されており、配送者がキャンセルした配送依頼が選択されている。リスト表示の内容を、拠点、依頼日などの条件で絞り込み可能としてもよい。このように、いまだ配送が完了していない荷物がある場合には、過去の依頼情報を利用して再送を依頼することができる。さらに、配送先など過去の配送依頼と共通する項目が多いときには、過去の配送依頼を利用することにより迅速かつ簡便に配送依頼を行うことが可能となる。
過去の配送依頼を利用しないと判断される場合（ステップＳ１０）、荷主側端末２００は、上述のリスト表示をスキップする。

次に、荷主側端末２００は、荷物引受および配送先の情報を入力する（ステップＳ１２）。図中に、この入力のための画面例を示した。荷物引受としては、住所、引渡日時、３０ｋｇ以上の荷物の有無、車種の指定を入力する。
配送サービスでは、拠点間で基準料金を適用するため、荷物自体の重量、サイズ、数量は入力する必要がない。重量物を含むか否かの情報を入力するのは、重量物の配送には、配送者によって対応可否が分かれるからである。
また、荷主がマッチングタイムを任意に設定できるものとした。マッチングタイムとは、配送依頼に対する配送者からの応諾の受付時間である。仮に、マッチングタイムを設けず、応諾の早い順に配送者をマッチングさせるものとすると、荷主は、配送者を選択する余地がなくなってしまう。本実施例では、荷主が配送者を選択することができるよう、一定のマッチングタイム中は、配送者からの応諾を受付可能としたのである。荷主にとっては、マッチングタイムを長くすれば、それだけ配送者の選択肢が増えることになる。一方、マッチングタイムを長くすると、配送者としては、配送依頼を受注できるか否か不確定な時期が長くなることになってしまう。このことは、配送者に応諾を躊躇させる要因ともなる。マッチングタイムは、このような両面を考えて設定すればよい。マッチングタイムは、システムサーバ１００が予め設定するものとしてもよいが、本実施例では、上述の通り、荷主が任意に設定できるようにした。

荷主側端末２００は、配送依頼の入力が完了すると、拠点データベース１２１に記憶された各種情報との照合により配送条件を判定する（ステップＳ１３）。本実施例では、次の３つの条件を判定するものとした。条件１は、荷物の引受地または配送先が拠点内か否かである。配送サービスは、拠点間で荷物を配送するサービスであり、拠点以外の引受地、配送先については受け付けられないからである。条件２は、荷物の引渡日時が現在時刻とマッチングタイムに荷物引受に要する時間として２時間を加えた時刻より後となっているかである。引渡日時の指定が早すぎる場合、集荷することができなくなるからである。引受の所要時間は、２時間に限られるものではない。また、配送依頼ごとに拠点の外縁から荷物の引受地までの移動に要する最大の所要時間を用いるようにしてもよい。条件３は、荷物の引渡日時と配達日時との間の時間が基準配送時間より大きいことである。基準配送時間よりも短い時間での配送を要求されても対応できない可能性があるからである。
条件１〜３の判断は、荷主側端末２００で行うようにしてもよいし、配送依頼をシステムサーバ１００に送信し、システムサーバ１００で条件１〜３の判断を行った上、その結果を荷主側端末２００に返信するようにしてもよい。

条件１〜３のいずれか一つでも満たされない場合には（ステップＳ１４）、荷主側端末２００は、ステップ１２の依頼情報入力手順に戻り、条件の修正を促す。
配送条件を満たす場合は（ステップＳ１４）、荷主側端末２００は、配送費用見積り結果の表示を行う（ステップＳ１５）。配送費用も、荷主側端末２００が見積もるようにしてもよいし、システムサーバ１００で見積もった結果を荷主側端末２００が表示するようにしてもよい。
荷主は、配送費用見積り結果を確認し、配送を依頼するか否かを決める。荷主側端末２００は、配送を依頼する旨を入力したときは（ステップＳ１６）、システムサーバ１００に対して配送依頼の送信を行う（ステップＳ１７）。既にステップＳ１３、Ｓ１５などで配送依頼をシステムサーバ１００に送信済みの場合は、ステップＳ１７では、配送依頼が確定した旨の情報を送信するようにしてもよい。
配送を依頼しない旨の入力があったときは（ステップＳ１６）、配送依頼を送信することなく、配送依頼処理を終了する。
以上が、配送依頼処理の流れである。

Ｃ−３．マッチング処理：
図８および図９は、マッチング処理のフローチャートである。図４のステップｂ２の処理に相当する。主としてマッチング処理部１３２（図１）が実行する処理であり、ハードウェア的にはシステムサーバ１００が実行する処理である。この処理は、システムサーバ１００が荷主側端末２００から配送依頼を受け付けると開始される。

処理を開始すると、システムサーバ１００は、配送依頼を依頼データベース１２４に保存する（ステップＳ２０）。
システムサーバ１００は、この配送依頼を応諾する可能性のある配送者を検索する処理を行う（ステップＳ２１）。本実施例では、３種類の条件を設定し、検索範囲を段階的に広げられるようにした。
通常マッチング条件の条件（１）は、荷主が指定した車種の条件を満たすことである。条件（２）は、配送者のステータスが、待機または帰還であること、即ち配送依頼に応じることが可能なステータスにあることである。

非マッチング条件は、配送依頼を受注させるべきではないと判断され、検索の対象から除外される配送者を特定するための条件である。非マッチング条件の条件（１）は、配送者のステータスが、配送中またはＯＦＦとなっていることである。条件（２）は、荷物の引受時刻が配送後１２時間以内であることである。条件（２）は、一人の配送者が、立て続けに過剰に配送依頼を受任することを回避し、不慮の事故を予防する目的、および、多くの配送者に均等に機会を与える目的で設けられた条件である。条件（２）は、配送先から帰ろうとする配送者、いわゆる帰り便の場合には、適用除外としている。拠点Ａから拠点Ｂに配送を完了した配送者が、拠点Ａに帰ろうとしている場合には、この配送者に配達依頼を受注させた方が、車両を有効活用することができ、荷主にも安い料金で配送サービスを提供可能となる点で利点があるからである。条件（３）は、荷物の引受時刻が応諾済み配送依頼に要する時間の前後２時間以内（図中に非マッチング期間として示した期間）であること、である。新たな配送依頼の引受時刻が、既に応諾済みの他の配送依頼の直前である場合には、既に応諾済みの配送依頼の荷物の引受に支障が生じることがある。また、新たな配送依頼の配送時刻が、既に応諾済みの配送依頼の直後である場合も、２つの配送依頼のいずれかの配送に支障が生じることがある。かかる点を考慮し、非マッチング期間に引受時刻または配送時刻が入る配送依頼は受注できないようにしているのである。

帰り便マッチング条件とは、１回目の配送者検索処理においては、配送依頼が配送者にとって帰り便となる配送者を優先するための条件である。帰り便マッチング条件の条件（１）は、配送者が帰還ステータスであることである。帰り便は、以下の条件（２）〜（４）によって判断することもできる。条件（２）は、配送者の配送場所が、新たな配送依頼における荷物の引渡場所であること、である。この条件は、住所地ではなく、拠点単位で判断する。条件（３）は、配送者の拠点が、荷物の配送場所であること、である。この条件も、拠点単位で判断する。条件（４）は、荷物の引受時刻が、配送者の納品時刻より２〜８時間以内であること、である。この条件は、配送者が、配送をした後に荷物の引受ができるための条件である。帰り便マッチング条件では、条件（１）を満たす配送者、または条件（２）〜（４）を全て満たす配送者が、検索されることになる。

配送者検索処理（ステップＳ２１）が、１回目に行われるときは、通常マッチング条件、非マッチング条件、および帰り便マッチング条件の全てを適用して配送者を検索する。この結果、帰り便に該当する配送者が検索されることになる。
システムサーバ１００は、検索した配送者の配送者側端末３００に配送依頼を配信し（ステップＳ２２）、応諾申請および正式依頼の受付を行う（ステップＳ２３）。
つまり、配送者は、配送者側端末３００に配信された依頼情報を確認し、応諾したい配送依頼があれば、配送者側端末３００を操作して、応諾申請を行う。この応諾申請は、システムサーバ１００が荷主側端末２００に送信する。このための処理は、後述する。
一方、荷主は、応諾申請を確認して、正式依頼を行う場合には、荷主側端末２００を操作することにより、システムサーバ１００に正式依頼を送信する。応諾申請および正式依頼のための時間が、マッチングタイムである。荷主は、応諾申請があった場合に、その配送者に対して、直ちに正式依頼をしてもよいし、マッチングタイムに至るまでは、他の配送者からの応諾を待ってもよい。

応諾申請、正式依頼受付（ステップＳ２３）において、正式依頼がなされた場合（ステップＳ２４）、システムサーバ１００は、マッチングされた配送者の情報を依頼データベース１２４に登録するとともに、成約を荷主および配送者に通知する（ステップＳ２７）。

一方、荷主がマッチングタイム内に正式依頼を行わない場合（ステップＳ２４）、システムサーバ１００は、任意マッチングが完了したか否かを判断する（ステップＳ２５）。本実施例では、先にステップＳ２１で説明した通り、配送者の検索範囲を段階的に広げることができるように配送者の検索条件が設定されている。従って、１回目の検索結果に対して、マッチングが成立しなかったときは、検索範囲を広げて再度、配送者の検索を行うものとした。つまり、ステップＳ２１〜Ｓ２４の処理を２回繰り返すのである。従って、ステップＳ２５では、２回のマッチング処理が完了したか否かを判断することになる。もちろん、３段階以上で検索範囲を広げられるようにし、マッチング処理を３回以上行うようにしても構わない。

配送者の検索が１回目しか行われておらず、任意マッチングが完了していないと判断される場合（ステップＳ２５）、システムサーバ１００は、再度、ステップＳ２１〜Ｓ２４の処理を繰り返し実行する。
この場合、ステップＳ２１では、２回目の配送者の検索を行うことになるため、帰り便マッチング条件は用いず、通常マッチング条件および非マッチング条件を用いることになる。こうすることにより、１回目よりも検索範囲を広げることができ、帰り便以外の配送者にも配送依頼が配信されることになる。
２回目の処理で、正式依頼が成立すれば（ステップＳ２４）、システムサーバ１００は、マッチングされた配送者の情報を依頼データベース１２４に登録するとともに、成約を荷主および配送者に通知する（ステップＳ２７）。

２回目でも任意のマッチングが成立しなかったときは（ステップＳ２５）、システムサーバ１００は、自動マッチング処理を行って（ステップＳ２６）、応諾されている配送者の中から受注する配送者を自動的に決定する。このマッチングは、複数の条件に対して優先度を設定し、優先度の高い条件が合致する配送者が一つ選定される。たとえば、提示価格の安さを第一に、評価の高さを第二に、応諾の早さを第三に、というように複数の条件に対して優先度を設定して配送者が選定される。なお、複数の条件に対して優先度が設定されるものの、応諾申請が１以上あることが前提となっていることから、必ず一つの配送者が選定される。この優先度は、システムサーバ１００が決めてもよいし、荷主が、設定可能としてもよい。
自動マッチングによって、配送者が選定されると、システムサーバ１００は、マッチングされた配送者の情報を依頼データベース１２４に登録するとともに、成約を荷主および配送者に通知する（ステップＳ２７）。

Ｃ−４．応諾処理：
図１０は、応諾処理のフローチャートである。図４のステップｃ２の処理、およびマッチング処理（図９）のステップＳ２３における処理に相当する。主として配送者用アプリ３１０（図１）が実行する処理であり、ハードウェア的には配送者側端末３００が実行する処理である。
この処理では、配送者側端末３００がシステムサーバ１００から配送依頼を受信する（ステップＳ３０）。配送依頼は一つだけでなく複数を随時受信することもある。そして、配信者側端末３００は、配送者受信した複数の配送依頼を一覧として表示する（ステップＳ３１）。図中には、名古屋から東京への配送依頼、名古屋から大阪への配送依頼を例示した。

配送者側端末３００は、このリスト画面で、詳細を確認したい配送依頼を表示するとともに、応諾するか否かの指示を受け付ける（ステップＳ３２）。
応諾する場合には（ステップＳ３３）、配送者応諾情報をシステムサーバ１００に送信する（ステップＳ３４）。
応諾しない場合には（ステップＳ３３）、ステップＳ３０に戻り、改めて受信した最新の配送依頼に基づいて配送依頼一覧を表示させて確認する。
こうすることにより、配送者は、自身の希望する内容に近い配送依頼を選択して、応諾することが可能となる。

Ｃ−５．キャンセル処理：
図１１は、キャンセル処理のフローチャートである。図４のステップｂ３の処理に相当する。主としてキャンセル処理部１３３（図１）が実行する処理であり、ハードウェア的にはシステムサーバ１００が実行する処理である。なお、当然のことであるが、一つの配送依頼に対してキャンセル処理がなされない場合もある。

処理を開始すると、システムサーバ１００は、荷主または配送者からのキャンセル指示を受け付ける（ステップＳ４０）。次に、システムサーバ１００は、指示に対応する配送依頼を検索し、キャンセルの対象となる配送依頼を特定する（ステップＳ４１）。そして、荷主からのキャンセル指示か、配送者からのキャンセル指示かに応じて、以下のそれぞれの処理を実行する（ステップＳ４２）。

荷主からのキャンセルの場合（ステップＳ４２）、システムサーバ１００は、キャンセルがなされた時刻から引受日時までの時間に応じて定まるキャンセル料率を配送料金に乗じることで、荷主に対して課金されるキャンセル料を計算する（ステップＳ４３）。たとえば、引受日時までの時間が長い場合にはキャンセル料率を低く設定し、引受日時までの時間が短い場合にはキャンセル料率を高く設定してもよい。

次に、システムサーバ１００は、該配送依頼がキャンセルされたことに応じて、荷主データベース１２２及び配送者データベース１２３のステータス等の情報を更新する（ステップＳ４４）。荷主データベース１２２には、キャンセル料が記録されることになる。配送者データベース１２３のステータスの更新に併せて、ステータスが更新された旨、または配信依頼がキャンセルされた旨を配送者側端末３００に送信してもよい。

続いて、システムサーバ１００は、依頼データベースの情報も更新する（ステップＳ４５）。このとき配送依頼のステータスとして荷主都合キャンセルとの情報が加わる。

一方、配送者からのキャンセルの場合（ステップＳ４２）、たとえば、配送者の過去３０日分の報酬に対して一定の制裁金料率を乗じることで、配送者に対して課金される制裁金を計算する（ステップＳ４６）。また、配送者に制裁金を課すほかに、一定期間、本システムを利用できないペナルティを与えるものとすることもできる。
次に、システムサーバ１００は、該配送依頼がキャンセルされたことに応じて、配送者データベース１２３のステータス等の情報を更新し（ステップＳ４７）、依頼データベースの情報も更新する（ステップＳ４８）。このときステータスとして配送者都合キャンセルとの情報が加わる。

Ｃ−６．荷物引受処理：
図１２は、荷物引受処理のフローチャートである。図４のステップｂ４の処理に相当する。主として配送管理部１３４（図１）が実行する処理であり、ハードウェア的にはシステムサーバ１００が実行する処理である。この処理は、所定のタイミングで繰り返し実行される。

処理を開始すると、システムサーバ１００は、荷物引受が完了していない配送依頼を検索し（ステップＳ５０）、配送者側端末３００にリマインダーを送信して、配送者に荷物引受が完了していない配送依頼を知らせる（ステップＳ５１）。
また、システムサーバ１００は、配送者が配送者側端末３００から荷物引受開始の指示を受け付けた場合は、依頼データベース１２４のステータスを更新する（ステップＳ５２）。続いて、システムサーバ１００は、ＧＰＳによって配送者の位置情報を検出する（ステップＳ５３）。この位置情報は、配送者側端末３００内の位置情報送信部３１１から送信される。そして、システムサーバ１００は、ＧＰＳによって配送者が荷物の引受場所に到着したか否かを判定する（ステップＳ５４）。
配送者が、荷物の引受場所に到着していない場合は（ステップＳ５４）、何も処理をすることなく荷物引受処理を終了する。荷物引受処理は、繰り返し実行されるため、何度目かの処理では、予定通りであれば、引受場所に到着したものと判定されるはずである。

荷物の引受場所に到着したものと判定される場合（ステップＳ５４）、システムサーバ１００は、荷物の引受完了判定を行う（ステップＳ５５）。すなわち、（１）荷主から荷主側端末２００の操作により荷物の引受が完了した旨の情報を受け付けたとき、あるいは、（２）配送者が荷物の引受場所に到着後、引受場所から１キロメートル以上離れたことを位置情報によって検出したときは、荷物の引受が完了したものと判定する。
荷物の引受が完了したものと判定された場合は、引受完了日時の情報を反映するよう、また、ステータスを配送中にするよう依頼データベース１２４を更新する（ステップＳ５６）。
また、引受完了日時が依頼時に指定していた引受日時よりも３０分を超える超過時間が生じた場合には（ステップＳ５７）、超過時間に応じて、課金、報酬を計算し、計算結果の情報を反映するよう荷主データベース１２２と配送者データベース１２３を更新する（ステップＳ５８）。

Ｃ−７．配送完了処理：
図１３は、配送完了処理のフローチャートである。図４のステップｂ６の処理に相当する。主として配送管理部１３４（図１）が実行する処理であり、ハードウェア的にはシステムサーバ１００が実行する処理である。
システムサーバ１００は、配送者側端末３００から配送完了の情報を受け付けると（ステップＳ６０）、荷主側端末２００に配送完了の情報を送信する（ステップＳ７０）。
次に、荷主が荷主側端末２００を操作して、配送完了の情報を確認したうえで承諾の可否を確認し（ステップＳ７１）、配送者に配送完了の通知を送信する（ステップＳ７２）。
続いて、システムサーバ１００は、荷主側端末２００に評価やレビューの入力画面を表示させ、荷主に評価やレビューの入力を促す（ステップＳ７３）。荷主によって必ず評価やレビューの入力がなされるわけではないが、なされた場合には、入力された情報を反映するよう依頼データベース１２４を更新するとともに（ステップＳ７４）、入力された情報に基づいて配送者データベース１２３も更新する（ステップＳ７５）。ここで、荷主の評価に応じて配送者にポイントが付与されるものとすれば、サービス向上に寄与する。

Ｃ−８．料金計算処理：
図１４は、料金計算処理のフローチャートである。図４のステップｂ７の処理に相当する。主として精算処理部１３６（図１）が実行する処理であり、ハードウェア的にはシステムサーバ１００が実行する処理である。
配送完了処理が終わると、システムサーバ１００は、依頼データベース１２４から配送依頼の情報を読み込む（ステップＳ８０）。同様に、システムサーバ１００は、拠点データベース１２１から拠点間の基本料金などの情報を読み込む（ステップＳ８１）。
次に、システムサーバ１００は、配送依頼の情報と拠点間の基本料金などの情報に基づいて、減額分や割増分の計算処理を行う（ステップＳ８２）。すなわち、たとえば、帰り便の場合や配送者キャンセルの場合には、基本料金に対して任意に定められた割引率Ｒ１、Ｒ２を乗ずることにより減額分を算出する。冷凍車などの車種指定がある場合には、基本料金に対して任意に定められた割増率Ｒ３を乗ずることにより増額分を算出する。また、配送者による任意の割引設定がある場合には、基本料金に対して配送者が設定した割引率Ｒ４を乗ずることにより減額分を算出する。さらに、荷物引受処理において、荷物引受の超過時間が生じた場合には、その分、配送者を待たせたことになるため、超過料金を増額分として算出する。
さいごに、システムサーバ１００は、基本料金に対して、増額分や減額分を加減することにより配送料金を計算する（ステップＳ８３）。このようにして計算された配送料金が荷主に課金される。

Ｄ．効果および変形例：
以上、本発明の実施形態の一つを説明した。本実施例の配送サービスによれば、荷主が、荷物の詳細な情報を入力することなく簡便に配送依頼をすることができる。また、拠点間で基準料金を適用することにより、予測可能な配送料金のもと、より簡便に配送を依頼することができる。さらに、空車状態の帰り便を有効に活用し、経済的な無駄を軽減することができる。さらに、配送者は、より安価に、またより高い配送サービスを提供しようとし、このことは荷主に対する本発明による配送サービス利用の動機付けとなる。

本発明は、実施形態に限らず、種々の構成とすることができる。必要に応じて、システムの機能を簡素化して、より単純なシステムとすることもできる。

本発明は、荷主と配送者とをマッチングさせる配送サービスにおいて利用することができる。

１００ システムサーバ
１１０ 主制御部
１２１ 拠点データベース
１２２ 荷主データベース
１２３ 配送者データベース
１２４ 依頼データベース
１３０ 送受信部
１３１ 配送依頼受付部
１３２ マッチング処理部
１３３ キャンセル処理部
１３４ 配送管理部
１３５ プロフィール登録部
１３６ 精算処理部
２００ 荷主側端末
２０１ 送受信部
２０２ ブラウザ
２０３ コマンド入力部
３００ 配送者側端末
３０１ 送受信部
３０２ コマンド入力部
３１０ 配送者用アプリ
３１１ 位置情報送信部
３１２ プロフィール管理部
３１３ 配送依頼管理部

Claims (15)

1. 荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムであって、
   同一料金で配送可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶する拠点データベースと、
   前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付ける配送依頼受付部と、
   前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応諾を受けた場合には、両者をマッチングさせるマッチング処理部と、
   前記荷物の配送に関して、前記基準料金に基づいて前記荷主への課金処理と、前記配送者への支払い処理とを行う精算処理部とを備える配送マッチングシステム。
2. 前記マッチング処理部は、予め登録された車両情報または配送者の属性が配送依頼に応じた条件に合致する配送者にのみ前記配送依頼を送信する請求項１記載の配送マッチングシステム。
3. 前記マッチング処理部は、時間の経過とともに段階に前記条件を緩和して前記配送依頼を送信する請求項２記載の配送マッチングシステム。
4. 前記配送者を絞り込む条件として、帰り便という条件を用いる請求項２または３記載の配送マッチングシステム。
5. 前記マッチング処理部は、前記配送依頼に応諾した配送者のいずれかを制限時間内に荷主が選定しない場合には、所定の条件に基づいて応諾した配送者のいずれかを選定して前記荷主とマッチングさせる請求項２〜４いずれか記載の配送マッチングシステム。
6. 前記精算処理部は、帰り便の条件によりマッチングさせた場合は、前記基準料金よりも割り引いた料金を適用する請求項１〜５いずれか記載の配送マッチングシステム。
7. 前記精算処理部は、荷主が、配送に利用される車種を限定した場合は、限定に応じて基準料金よりも割り増した料金を適用する請求項１〜６いずれか記載の配送マッチングシステム。
8. 前記精算処理部は、荷主が配送者を選定した後に配送者がキャンセルした場合の再配送依頼に対しては、基準料金よりも割り引いた料金を適用する請求項１〜７いずれか記載の配送マッチングシステム。
9. 前記マッチング処理部は、前記配送依頼に応諾した配送者の属性を前記荷主に提示する請求項１〜８いずれか記載の配送マッチングシステム。
10. 前記配送者の属性には、過去に配送依頼を行った荷主による該配送者に対する評価が含まれる請求項９記載の配送マッチングシステム。
11. 前記配送者の属性の登録内容を前記配送者から受け付けて反映させるためのプロフィール登録部を有し、
    前記精算処理部は、前記登録内容に応じて、該配送者への支払い条件を変動させる請求項９または１０記載の配送マッチングシステム。
12. 前記配送者の車両の位置情報に基づき、該車両が前記引受住所地に至った後、所定の距離以上ずれたことを検出した場合に、前記荷物の前記配送者による引受完了として、前記配送を管理する配送管理部を備える請求項１〜１１いずれか記載の配送マッチングシステム。
13. コンピュータにより、荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせるマッチング方法であって、
    コンピュータが実行するステップとして、
    同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶するステップと、
    前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付けるステップと、
    前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応諾を受けた場合には、両者をマッチングさせるステップと、
    前記荷物の配送に関して、前記基準料金に基づいて前記荷主への課金処理と、前記配送者への支払い処理とを行うステップとを備えるマッチング方法。
14. 荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記荷主が利用する荷主側端末機に用いられるコンピュータプログラムであって、
    同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを参照する機能と、
    前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を送信する機能と、
    前記配送依頼に対する前記配送者とのマッチングの結果を受信して表示する機能とを実現するコンピュータプログラム。
15. 荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記配送者が利用する配送者側端末機に用いられるコンピュータプログラムであって、
    前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を受信して表示する機能と、
    前記配送依頼を受諾する旨の指示を送信する機能とを実現するコンピュータプログラム。
    

Images