(57)【要約】【課題】特に求貨求車システムにおいて機会損失の低減と業務負荷の軽減を実現できる求貨求車サーバ等の提供する。【解決手段】荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバであって、前記サーバは車主端末から受信した空車情報を記憶する空車情報記憶手段と、荷主端末から受信した荷物情報を記憶する荷物情報記憶手段と、前記荷物情報が登録された場合に、車主端末に当該荷物情報の登録を通知するための通知条件を記憶する通知条件記憶手段と、前記荷物情報が登録された場合に前記荷物情報と前記通知条件に基づいて車主端末に通知するか否かを判定する判定手段と、前記判定手段が、通知すべき車主端末が少なくとも１つあると判定した場合に各通知先車主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、前記申込先情報を特定するための情報を含む各通知先車主端末に対応した一意の通知情報を生成する通知情報生成手段とを備えた。【選択図】　図３
2004070823.tif 000002
【特許請求の範囲】
【請求項１】
一方当事者端末と他方当事者端末と通信回線を介して接続したマッチングシステムのサーバであって、
一方当事者端末から受信した第一情報を記憶する第一情報記憶手段と、
他方当事者端末から受信した第二情報を記憶する第二情報記憶手段と、
前記第一情報が登録された場合に、他方当事者端末に当該第一情報の登録を通知するための通知条件を記憶する通知条件記憶手段と、
前記第一情報が登録された場合に、前記第一情報と前記通知条件に基づいて他方当事者端末に通知するか否かを判定する通知判定手段と、
前記通知判定手段が、通知すべき他方当事者端末が少なくとも１つあると判定した場合に各通知先他方当事者端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先他方当事者端末に対応した一意の通知情報を生成する通知情報生成手段と
を備えることを特徴とするサーバ。
【請求項２】
荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバであって、
車主端末から受信した空車情報を記憶する空車情報記憶手段と、
荷主端末から受信した荷物情報を記憶する荷物情報記憶手段と、
前記荷物情報が登録された場合に、車主端末に当該荷物情報の登録を通知するための通知条件を記憶する通知条件記憶手段と、
前記荷物情報が登録された場合に、前記荷物情報と前記通知条件に基づいて車主端末に通知するか否かを判定する判定手段と、
前記判定手段が、通知すべき車主端末が少なくとも１つあると判定した場合に各通知先車主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先車主端末に対応した一意の通知情報を生成する通知情報生成手段と
を備えることを特徴とする求貨求車サーバ。
【請求項３】
前記申込先情報は前記求貨求車サーバ内の各通知先車主端末に対応した一意の申込専用ホームページであり、
前記申込先情報を特定するための情報は前記申込専用ホームページを特定するためのＵＲＬであることを特徴とする請求項２に記載の求貨求車サーバ。
【請求項４】
前記通知条件は通知先の電子メールアドレスを含み、前記通知情報は電子メールによって通知するための情報であることを特徴とする請求項２又は請求項３に記載の求貨求車サーバ。
【請求項５】
荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバであって、
車主端末から受信した空車情報を記憶する空車情報記憶手段と、
荷主端末から受信した荷物情報を記憶する荷物情報記憶手段と、
前記空車情報が登録された場合に、荷主端末に当該空車情報の登録を通知するための通知条件を記憶する第二の通知条件記憶手段と、
前記空車情報が登録された場合に、前記空車情報と前記通知条件に基づいて荷主端末に通知するか否かを判定する第二の判定手段と、
前記第二の判定手段が、通知すべき荷主端末が少なくとも１つあると判定した場合に各通知先荷主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先荷主端末に対応した一意の通知情報を生成する通知情報生成手段と
を備えることを特徴とする求貨求車サーバ。
【請求項６】
一方当事者端末と他方当事者端末と通信回線を介して接続したマッチングシステムのサーバの制御方法であって、
一方当事者端末から受信した第一情報を記憶する第一情報記憶ステップと、
他方当事者端末から受信した第二情報を記憶する第二情報記憶ステップと、
前記第一情報が登録された場合に、他方当事者端末に当該第一情報の登録を通知するための通知条件を記憶する通知条件記憶ステップと、
前記第一情報が登録された場合に、前記第一情報と前記通知条件に基づいて他方当事者端末に通知するか否かを判定する通知判定ステップと、
前記通知判定ステップにおいて、通知すべき他方当事者端末が少なくとも１つあると判定された場合に各通知先他方当事者端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成ステップと、
前記申込先情報を特定するための情報を含む各通知先他方当事者端末に対応した一意の通知情報を生成する通知情報生成と
を備えることを特徴とするサーバの制御方法。
【請求項７】
荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバの制御方法であって、
車主端末から受信した空車情報を記憶する空車情報記憶ステップと、
荷主端末から受信した荷物情報を記憶する荷物情報記憶ステップと、
前記荷物情報が登録された場合に、車主端末に当該荷物情報の登録を通知するための通知条件を記憶する通知条件記憶手ステップと、
前記荷物情報が登録された場合に、前記荷物情報と前記通知条件に基づいて車主端末に通知するか否かを判定する判定ステップと、
前記判定ステップにおいてが、通知すべき車主端末が少なくとも１つあると判定された場合に各通知先車主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成ステップと、
前記申込先情報を特定するための情報を含む各通知先車主端末に対応した一意の通知情報を生成する通知情報生成ステップと
を備えることを特徴とする求貨求車サーバの制御方法。
【請求項８】
コンピュータが読み込み実行することで、一方当事者端末と他方当事者端末と通信回線を介して接続したマッチングシステムのサーバとして機能するコンピュータプログラムであって、
一方当事者端末から受信した第一情報を記憶する第一情報記憶手段と、
他方当事者端末から受信した第二情報を記憶する第二情報記憶手段と、
前記第一情報が登録された場合に、他方当事者端末に当該第一情報の登録を通知するための通知条件を記憶する通知条件記憶手段と、
前記第一情報が登録された場合に、前記第一情報と前記通知条件に基づいて他方当事者端末に通知するか否かを判定する通知判定手段と、
前記通知判定手段が、通知すべき他方当事者端末が少なくとも１つあると判定した場合に各通知先他方当事者端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先他方当事者端末に対応した一意の通知情報を生成する通知情報生成手段
として機能することを特徴とするコンピュータプログラム。
【請求項９】
コンピュータが読み込み実行することで、荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバとして機能するコンピュータプログラムでって、
車主端末から受信した空車情報を記憶する空車情報記憶手段と、
荷主端末から受信した荷物情報を記憶する荷物情報記憶手段と、
前記荷物情報が登録された場合に、車主端末に当該荷物情報の登録を通知するための通知条件を記憶する通知条件記憶手段と、
前記荷物情報が登録された場合に、前記荷物情報と前記通知条件に基づいて車主端末に通知するか否かを判定する判定手段と、
前記判定手段が、通知すべき車主端末が少なくとも１つあると判定した場合に各通知先車主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先車主端末に対応した一意の通知情報を生成する通知情報生成手段
として機能することを特徴とするコンピュータプログラム。
【請求項１０】
コンピュータが読み込み実行することで、荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバとして機能するコンピュータプログラムあって、
車主端末から受信した空車情報を記憶する空車情報記憶手段と、
荷主端末から受信した荷物情報を記憶する荷物情報記憶手段と、
前記空車情報が登録された場合に、荷主端末に当該空車情報の登録を通知するための通知条件を記憶する第二の通知条件記憶手段と、
前記空車情報が登録された場合に、前記空車情報と前記通知条件に基づいて荷主端末に通知するか否かを判定する第二の判定手段と、
前記第二の判定手段が、通知すべき荷主端末が少なくとも１つあると判定した場合に各通知先荷主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先荷主端末に対応した一意の通知情報を生成する通知情報生成手段と
として機能することを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、一方当事者からの第一情報に基づいて他方当事者に情報を提供するマッチングシステム全般、特に荷主からの荷物情報に基づいて車主である運送会社などに求車情報を提供する求貨求車のサーバ及びこのサーバにおける処理方法及びそのプログラムと記憶媒体に関するものである。
【０００２】
【従来の技術】
一方当事者からの第一情報に基づいて他方当事者に情報を提供するマッチングシステムは広く利用されている。その一例として例えば求貨求車システムは、トラックを探している荷主の荷物情報と、荷物を探している運送会社の空車情報をインターネット上でお見合いをさせ、マッチングすることで、トラックの運行率を向上させ、その見返りとして安価に荷物を運ぶことが出来るマーケットプレイス型のビジネスを実現している。
【０００３】
このビジネスは、求貨求車システムという市場を作り、市場にならぶ荷物情報、空車情報をマッチングさせ、運営事業者は、その市場の使用料として、一定のマッチング手数料を双方、もしくは片方から徴収することを収益とするものである。求貨求車システムを利用する最大のメリットは、これまで荷物情報・空車情報を必要とした配車センター・営業所など配車を実施するマッチング拠点が、各拠点に対し個別に電話やＦａｘを用いて情報収集を行っていたものが、インターネットシステムを利用することで、情報を登録することで全拠点の情報が一元化できることである。
【０００４】
【発明が解決しようとする課題】
しかしながら、こうした荷物情報・空車情報の登録件数が多くなる程、自分の望む情報を探し出すことが困難になる。検索機能を実装することで、こうした課題の解決は可能であるが、常に、画面を確認する必要が出てくる。また、情報が登録された後、一定時間を置かなければ、登録した荷物情報・空車情報に対する入札がなされない事から、リアルタイムの配車が困難である。登録した情報は、配車がなされるまで凍結される事になり、その間、他の会社から引き合いがあったとしても、断らざるを得ない。結果的に、求貨求車システム上でマッチングがなされれば問題ないが、成約がなされなかった場合、登録した情報に関しては、機会損失を被ることとなる。
【０００５】
マッチング業務を行う幹事会社にとっても、登録された荷物情報を確実に配車することは、幹事会社の評価を向上させる事になるが、成約率を高める為には、登録された荷物情報・空車情報を常に監視し、場合によっては、電話・Ｆａｘなどにより個別の連絡措置を取る必要も出てくる。こうした事から、求貨求車システムを導入することで、業務効率化を図ったにも関わらず、業務負荷が増すこともありえた。
【０００６】
以上は、求貨求車システムの例であるが、これに限らず、例えばオークションサイトに特定の品物を探している旨の「買いたし」情報を登録した場合でも、この条件に合う品物が「売りたし」に登録される場合が少なくない。しかし、上述の場合と同様に「売りたし」の情報を頻繁に見ていないと欲しい品物を逃してしまう場合が少なくない。特に外出先では自宅のＰＣからオークションサイトをアクセスできないし、携帯電話等の携帯端末からオークションサイトにアクセスするのも出品点数が多数に上る場合煩雑な操作と多額の通信費を要するという問題があった。
【０００７】
本発明は上記従来例に鑑みてなされたもので、マッチングサーバにおけるマッチング率の向上と操作負担の軽減を目的とし、特に求貨求車システムにおける機会損失の低減と業務負荷の軽減を実現するために、登録される荷物情報・空車情報に対して、自分の望む情報がＰＵＳＨ型で携帯電話等の携帯端末に配信され、更に条件の合致する情報であれば、極めて簡易な操作で入札可能な求貨求車サーバとその処理方法とプログラムと記憶媒体の提供を主たる目的とするものである。
【０００８】
【課題を解決するための手段】
上記目的を達成するために本発明のサーバは以下のような構成を備える。即ち、
一方当事者端末と他方当事者端末と通信回線を介して接続したマッチングシステムのサーバであって、
一方当事者端末から受信した第一情報を記憶する第一情報記憶手段と、
他方当事者端末から受信した第二情報を記憶する第二情報記憶手段と、
前記第一情報が登録された場合に、他方当事者端末に当該第一情報の登録を通知するための通知条件を記憶する通知条件記憶手段と、
前記第一情報が登録された場合に、前記第一情報と前記通知条件に基づいて他方当事者端末に通知するか否かを判定する通知判定手段と、
前記通知判定手段が、通知すべき他方当事者端末が少なくとも１つあると判定した場合に各通知先他方当事者端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先他方当事者端末に対応した一意の通知情報を生成する通知情報生成手段と
を備えることを特徴とする。
【０００９】
上記目的を達成するために本発明の求貨求車システムのサーバは以下のような構成を備える。即ち、
荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバであって、
車主端末から受信した空車情報を記憶する空車情報記憶手段と、
荷主端末から受信した荷物情報を記憶する荷物情報記憶手段と、
前記荷物情報が登録された場合に、車主端末に当該荷物情報の登録を通知するための通知条件を記憶する通知条件記憶手段と、
前記荷物情報が登録された場合に、前記荷物情報と前記通知条件に基づいて車主端末に通知するか否かを判定する判定手段と、
前記判定手段が、通知すべき車主端末が少なくとも１つあると判定した場合に各通知先車主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先車主端末に対応した一意の通知情報を生成する通知情報生成手段と
を備えることを特徴とする。
【００１０】
また、好ましくは、本発明の求貨求車システムのサーバにおいて、前記申込先情報は前記求貨求車サーバ内の各通知先車主端末に対応した一意の申込専用ホームページであり、前記申込先情報を特定するための情報は前記申込専用ホームページを特定するためのＵＲＬであることを特徴とする。
【００１１】
また、好ましくは、本発明の求貨求車システムのサーバにおいて、前記通知条件は通知先の電子メールアドレスを含み、前記通知情報は電子メールによって通知するための情報であることを特徴とする。
【００１２】
上記目的を達成するために本発明のサーバは以下のような構成を備える。即ち、
荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバであって、
車主端末から受信した空車情報を記憶する空車情報記憶手段と、
荷主端末から受信した荷物情報を記憶する荷物情報記憶手段と、
前記空車情報が登録された場合に、荷主端末に当該空車情報の登録を通知するための通知条件を記憶する第二の通知条件記憶手段と、
前記空車情報が登録された場合に、前記空車情報と前記通知条件に基づいて荷主端末に通知するか否かを判定する第二の判定手段と、
前記第二の判定手段が、通知すべき荷主端末が少なくとも１つあると判定した場合に各通知先荷主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先荷主端末に対応した一意の通知情報を生成する通知情報生成手段と
を備えることを特徴とする。
【００１３】
上記目的を達成するために本発明のサーバの制御方法は以下のような構成を備える。即ち、
一方当事者端末と他方当事者端末と通信回線を介して接続したマッチングシステムのサーバの制御方法であって、
一方当事者端末から受信した第一情報を記憶する第一情報記憶ステップと、
他方当事者端末から受信した第二情報を記憶する第二情報記憶ステップと、
前記第一情報が登録された場合に、他方当事者端末に当該第一情報の登録を通知するための通知条件を記憶する通知条件記憶ステップと、
前記第一情報が登録された場合に、前記第一情報と前記通知条件に基づいて他方当事者端末に通知するか否かを判定する通知判定ステップと、
前記通知判定ステップにおいて、通知すべき他方当事者端末が少なくとも１つあると判定された場合に各通知先他方当事者端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成ステップと、
前記申込先情報を特定するための情報を含む各通知先他方当事者端末に対応した一意の通知情報を生成する通知情報生成とを備える。
【００１４】
上記目的を達成するために本発明のサーバの制御方法は以下のような構成を備える。即ち、
荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバの制御方法であって、
車主端末から受信した空車情報を記憶する空車情報記憶ステップと、
荷主端末から受信した荷物情報を記憶する荷物情報記憶ステップと、
前記荷物情報が登録された場合に、車主端末に当該荷物情報の登録を通知するための通知条件を記憶する通知条件記憶手ステップと、
前記荷物情報が登録された場合に、前記荷物情報と前記通知条件に基づいて車主端末に通知するか否かを判定する判定ステップと、
前記判定ステップにおいてが、通知すべき車主端末が少なくとも１つあると判定された場合に各通知先車主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成ステップと、
前記申込先情報を特定するための情報を含む各通知先車主端末に対応した一意の通知情報を生成する通知情報生成ステップとを備える。
【００１５】
上記目的を達成するために本発明のサーバのコンピュータプログラムは以下のような構成を備える。即ち、
コンピュータが読み込み実行することで、一方当事者端末と他方当事者端末と通信回線を介して接続したマッチングシステムのサーバとして機能するコンピュータプログラムであって、
一方当事者端末から受信した第一情報を記憶する第一情報記憶手段と、
他方当事者端末から受信した第二情報を記憶する第二情報記憶手段と、
前記第一情報が登録された場合に、他方当事者端末に当該第一情報の登録を通知するための通知条件を記憶する通知条件記憶手段と、
前記第一情報が登録された場合に、前記第一情報と前記通知条件に基づいて他方当事者端末に通知するか否かを判定する通知判定手段と、
前記通知判定手段が、通知すべき他方当事者端末が少なくとも１つあると判定した場合に各通知先他方当事者端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先他方当事者端末に対応した一意の通知情報を生成する通知情報生成手段として機能することを特徴とする。
【００１６】
上記目的を達成するために本発明のサーバのコンピュータプログラムは以下のような構成を備える。即ち、
コンピュータが読み込み実行することで、荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバとして機能するコンピュータプログラムであって、
車主端末から受信した空車情報を記憶する空車情報記憶手段と、
荷主端末から受信した荷物情報を記憶する荷物情報記憶手段と、
前記荷物情報が登録された場合に、車主端末に当該荷物情報の登録を通知するための通知条件を記憶する通知条件記憶手段と、
前記荷物情報が登録された場合に、前記荷物情報と前記通知条件に基づいて車主端末に通知するか否かを判定する判定手段と、
前記判定手段が、通知すべき車主端末が少なくとも１つあると判定した場合に各通知先車主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先車主端末に対応した一意の通知情報を生成する通知情報生成手段
として機能することを特徴とする。
【００１７】
上記目的を達成するために本発明のサーバのコンピュータプログラムは以下のような構成を備える。即ち、
コンピュータが読み込み実行することで、荷主端末と車主端末と通信回線を介して接続した求貨求車システムのサーバとして機能するコンピュータプログラムであって、
車主端末から受信した空車情報を記憶する空車情報記憶手段と、
荷主端末から受信した荷物情報を記憶する荷物情報記憶手段と、
前記空車情報が登録された場合に、荷主端末に当該空車情報の登録を通知するための通知条件を記憶する第二の通知条件記憶手段と、
前記空車情報が登録された場合に、前記空車情報と前記通知条件に基づいて荷主端末に通知するか否かを判定する第二の判定手段と、
前記第二の判定手段が、通知すべき荷主端末が少なくとも１つあると判定した場合に各通知先荷主端末に対応した一意の申込先情報を前記サーバ内に生成する申込先情報生成手段と、
前記申込先情報を特定するための情報を含む各通知先荷主端末に対応した一意の通知情報を生成する通知情報生成手段として機能することを特徴とする。
【００１８】
【発明の実施の形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳細に説明する。図１は、本実施の形態に係る求貨求車システムの全体構成を示す概念図である。図において、１００はインターネット等のネットワーク（通信回線）を示し、このインターネット１００を介して幹事会社、車主、荷主の各端末１０２〜１０６及び求貨求車システムのサーバ１０１が接続されている。
【００１９】
図１では車主端末１０３と荷主端末１０４と車主携帯端末１０５は各々１つだけ記されているが、実際は各々が複数台ずつ接続されている。なお、通信回線はインターネットに限らず例えば衛星回線や専用回線で荷主の端末と車主の端末とサーバを接続しても良いことは言うまでもない。
【００２０】
そして、この求貨求車サーバ１０１は、車主より通知された空車情報を記憶する空車テーブル、荷主より通知された荷物情報を記憶する荷物テーブル、及びこれら車主、荷主の間での取引を管理している幹事会社の端末１０２が管理している会員に関する会員情報を記憶している会員テーブル、会員間の契約を記憶する契約テーブルをハードディスクに記憶している。
【００２１】
尚、会員情報は、例えばサーバ１０１がサービスする対象の車主及び荷主が正会員であるか否かを確認するため等に使用される。会員テーブルのフィールドとしては、会社名、住所、連絡先電話番号、会員ＩＤ、条件合致時の通知先メールアドレス（車主端末１０３用や荷主端末１０４用）などを持つ。
【００２２】
荷物テーブルのフィールドとしては、荷物会員ＩＤ、荷物番号、契約番号、商品名、積地、降地、積日、降日、重量、積込条件、荷降条件、指定車種、登録金額などを持つ。空車テーブルのフィールドとしては、空車会員ＩＤ、空車番号、契約番号、空車地、希望行き先、空車日、戻り日、車種、積載量、登録金額などを持つ。契約テーブルのフィールドとしては、荷物会員ＩＤ、空車会員ＩＤ、契約番号などを持つ。
【００２３】
通知条件テーブルのフィールドとしては、会員ＩＤ、荷物情報検索条件、空車情報検索条件、条件合致時の通知先メールアドレス（車主携帯端末１０５用）などを持つ。なお、通知条件テーブルの内容全部を会員テーブルに記憶しても良いし、通知条件テーブルの内容の一部を会員テーブルに記憶しても良い。つまり、本発明における「通知条件記憶手段」は、通知条件テーブル兼用の会員テーブルでも良いし、会員テーブルとは別個の通知条件テーブル用いても良い。
【００２４】
同様に、通知条件の共通部分は会員テーブルに記憶し、荷物情報や空車情報毎の個別で異なる通知条件部分は空車テーブルや荷物テーブルに記憶させてもよくこれらはいずれも本発明に含まれることは言うまでもない。このように構成することにより、車主が有している積載量が異なる複数の種類のトラックや、複数の同一積載量のトラックの個別の空車スケジュールを実車に変えられる荷物情報をきめ細かく検索することが可能になる。
【００２５】
次に、図２を参照して、サーバ１０１及び各端末１０２〜１０４等の通信端末のハードウェア構成について説明する。なお、車主携帯端末１０５と幹事会社携帯端末１０６は典型的には携帯電話であり、ＰＤＡ（パーソナルデータアシスタント）やハンディターミナル等のいわゆるモバイル端末でもよい。図２は、本発明の実施の形態に係る通信端末（サーバ１０１及び各端末１０２〜１０４）のハードウェア構成を示すブロック図である。
【００２６】
図２において、ＣＰＵ２１、ＲＡＭ２２、ＲＯＭ２３、ＬＡＮアダプタ２４、ビデオアダプタ２５、キーボード２６、マウス２７、ハードディスク２８、ＣＤ−ＲＯＭドライブ２９のそれぞれは、システムバス２０を介して互いに接続されている。このシステムバス２０は、例えば、ＰＣＩバス、ＡＧＰバス、メモリバス等を意味する。また、図２では、各バス間の接続用チップやキーボードインタフェースや、いわゆるＳＣＳＩやＡＴＡＰＩのような入出力用インタフェースは省略して示している。
【００２７】
ＣＰＵ２１は、ＲＡＭ２２に記憶されたプログラムに従って四則演算や比較演算等の各種の演算や、ハードウェアやソフトウェアの制御を行う。ＲＡＭ２２には、ハードディスク２８やＣＤ−ＲＯＭドライブ２９に装着されたＣＤ−ＲＯＭやＣＤ−Ｒ等の記憶媒体から読み出されたオペレーションシステムのプログラムやアプリケーションプログラム等が記憶され、これらはＣＰＵ２１の制御の下に実行される。ここでいうアプリケーションプログラムとは、各端末においてはブラウザであり、求貨求車サーバ１０１では、本発明における荷物情報登録プログラムや、通知条件の検索プログラムやホームページ生成プログラム等を指す。
【００２８】
ＲＯＭ２３は、オペレーションシステムと協働してハードディスク等への入出力を司るいわゆるＢＩＯＳ等が記憶されている。ＬＡＮアダプタ２４は、ＣＰＵ２１によって制御されるオペレーションシステムの通信プログラムと協働して、ネットワーク（インターネット）を介して外部端末との通信を行う。ビデオアダプタ２５は、表示部３０に出力する画像信号を生成し、入力部（キーボード）２６や入力部（マウス）２７は、この端末への各種指示コマンドやデータを入力するために用いられる。ハードディスク２８は、オペレーションシステムや上述のアプリケーションプログラムを記憶しており、これらプログラムは、サーバや端末の起動時に、または必要に応じてＲＡＭ２２にロードされる。また、求貨求車サーバ１０１のハードディスク２８は会員テーブル等の各テーブルや申込専用ホームページや通知ログも記録する。
【００２９】
ＣＤ−ＲＯＭドライブ２９は、ＣＤ−ＲＯＭやＣＤ−ＲやＣＤ−Ｒ／Ｗ等の記憶媒体を装着してアプリケーションプログラムをハードディスク２８にインストールするのに用いられる。尚、ＣＤ−ＲＯＭドライブの代わりにＣＤ−ＲドライブやＣＤ−Ｒ／ＷドライブやＭＯドライブ等を用いても良い。
【００３０】
次に、この求貨求車システムにおける処理の詳細について説明する。図３は、この求貨求車システムにおける全体処理の概要を説明するフローチャートである。
【００３１】
尚、この図３において、ステップＳ３１１乃至ステップＳ３１２の処理は荷主端末１０４における処理を示し、ステップＳ３２０乃至ステップＳ３３６の処理は求貨求車サーバ１０１における処理を示し、ステップＳ３０１の処理は車主端末１０３における処理を示し、ステップＳ３０５乃至ステップＳ３１０の処理は車主携帯端末１０５における処理を示しており、これらの各処理はそれぞれのサーバ又は端末のＣＰＵの制御のもとで実行される。
【００３２】
この図３の処理に先立って、車主端末から空車情報及び会員情報が求貨求車サーバの空車テーブルと会員テーブルに既に登録されているものとする。又、求貨求車サーバ１０１はステップＳ３２０で各端末からの情報の受信待ちにある。まずステップＳ３０１では、車主端末１０３において、ログインＩＤ、パスワードの入力後、図５に示すような画面から空車情報と通知条件が入力され、これらは求貨求車サーバ１０１に送信される。以下詳細を説明する。
【００３３】
まず、図５の画面左上の「情報通知設定」ボタンが押下されると、条件合致情報が登録された際の通知送信先メールアドレスを登録画面が表示される。この通知送信先メールアドレスは、共通メールアドレスと個別メールアドレスの２つを登録可能であり共通メールアドレスは、条件合致情報が登録された際に荷主端末１０４や車主端末１０３に常に通知される。個別メールアドレスは、特定の車両に関連つけられたアドレスであり、特定の車両に関して条件合致情報が登録された際に車主携帯端末１０５に通知するためのアドレスである。
【００３４】
次に、送信して欲しい、荷物情報・空車情報の条件登録を行う。この条件テーブルの内容は、例えば荷物情報であれば、荷物テーブルとして有している、情報のうち、商品名、積地、降地、積日、降日、重量、積込条件、荷降条件、指定車種、登録金額などの登録を可能とする。この内、積地、降地などは、市区町村・都道府県・ブロック別の登録が出来ると同時に、隣接地域の条件設定も可能とする。この時、積地条件として、”神奈川県”を設定し、条件設定として、同一ブロックとした場合、関東ブロック内に所属する都県が積地の荷物情報が登録されれば、通知対象となる。
同時に、同一ブロックではないが、隣接県である、静岡県、山梨県なども、そ
の対象となる。この条件設定には、例えば、同一ブロック、隣接ブロック、同一都道府県、隣接都道府県、同一市区町村、隣接市区町村などがあり、降地も同様である。次に、積日、降日などは、日付を単日で登録出来ると同時に、一定期間の条件設定も可能とする。条件設定には、例えば、当日のみ、同週内、同月内、同年内などがあり、降日も同様である。
【００３５】
重量は、数値登録項目と、条件設定などを有する。この条件設定には、例えば、以上、以下、のみなどがある。積込条件、荷降条件には、事前にマスタで登録されている各種条件の選択が可能となっていると同時に、条件設定が可能である。この条件設定には、例えば、を含む、を含まないなどがある。
【００３６】
指定車種には、事前にマスタで登録されている車種の選択が可能となっていると同時に、条件設定が可能である。この条件設定には、例えば、を含む、を含まない、のみなどがある。希望金額は、数値登録項目と、条件設定などを有する。この条件設定には、例えば、以上、以下、より多い、未満などがある。
【００３７】
以上、各項目の条件設定について触れてきたが、各項目は、一つに限らず、更にこうした各項目自体に条件設定をかけることができる。すなわち、必須（ＡＮＤ）条件か選択（ＯＲ）条件かを決定することで、会員が望む情報の絞込要望に柔軟に応えることが可能となる。
【００３８】
例えば、ある車主会員に、大阪から東京へ戻る１０ｔの空車便が発生したとする。この車輌は、冷凍車であり標準運賃は￥１００，０００であったとする。この車主会員は、完全な空車で帰ってくるぐらいであれば、多少なりとも荷物を運んで帰ってきた方が良いと考える。
【００３９】
しかし、通常の運搬のように、大阪／東京の隣接地域の運搬も可能とすると、赤字運行となってしまうため、ピンポイントでの輸送を実施したいと考えた。そこで、この車主会員は、以下のような条件設定を行った。
【００４０】
積地・・・大阪府（設定条件：同一都道府県）
積地（ＯＲ条件）・・・静岡県（設定条件：隣接都道府県）
降地・・・東京都（設定条件：同一都道府県）
降地（ＯＲ条件）・・・静岡県（設定条件：隣接都道府県）
重量・・・１０ｔ（設定条件：以下）
車種・・・冷凍車（設定条件：のみ）
車種（ＯＲ条件）・・・チルド車（設定条件：のみ）
希望金額・・・￥５０，０００（設定条件：以上）
このように、各項目に具体的な数値／名称を登録するだけでなく、各項目ごとに個別の設定条件を付加する事で、要望どおりの情報を獲得することができるようになる。それではここで、具体的な例（設例）について示したい。
【００４１】
＜前提条件＞
幹事会社・・・サノン物流（以下、サノン社）
荷主会員・・・イクサデジタル株式会社（以下、イクサ社）
車主会員・・・関東倉庫株式会社（以下、関東倉庫社）
大阪からの帰り便が頻繁に発生する関東倉庫社では、その大半が空車で帰ってきており、実車率を少しでも向上させるため、求貨求車システム上に登録された大阪発、関東着の荷物情報を獲得すべく、情報通知機能を利用することにした。同社が設定した、情報通知条件は以下のとおりである。
【００４２】
積地・・・大阪府（設定条件：隣接都道府県）
降地・・・東京都（設定条件：隣接都道府県）
積日・・・条件なし
降日・・・条件なし
重量・・・条件なし
車種・・・条件なし
積込条件・・・条件なし
荷降条件・・・条件なし
希望金額・・・￥５０，０００（設定条件：以上）
これらの情報がステップＳ３０１で通知条件として車主端末１０３から求貨求車サーバ１０１に送信される。
【００４３】
次に、ステップＳ３２１において、求貨求車サーバ１０１これらの通知条件を受信し、ステップＳ３２２において、通知条件テーブルに記憶する。
【００４４】
次に、ステップＳ３１１において、荷主会員である、イクサ社の担当者は、荷主端末１０４の図６に示す画面から、以下のような、荷物情報を入力し、入力された荷物情報は、荷主端末１０４求貨求車サーバ１０１に送信された。
【００４５】
積地・・・滋賀県
降地・・・神奈川県
積日・・・８／１
降日・・・８／２
重量・・・４ｔ
車種・・・ウイング車
積込条件・・・手積み
荷降条件・・・近隣待機不可
希望金額・・・￥５５，０００
この荷物情報は、ステップＳ３２３において、求貨求車サーバ１０１が受信し、ＲＡＭ２２に記憶される。更に受信した荷物情報はステップＳ３２４において、荷物テーブルに登録される。
【００４６】
次に、ステップＳ３２５において、ＲＡＭ２２に記憶されている荷物情報に基づいて通知条件テーブルが検索される。ステップＳ３２６において、通知条件に合致する荷物情報であるか否か、いくつの通知条件に合致しているか（合致数Ｎ）が判定される。
【００４７】
通知条件に合致しない場合（ステップＳ３２６でＮｏの場合）は、処理はステップＳ３２０に戻る。上述の例では、関東倉庫社が登録した荷物条件の、積地／降地／金額を満たしている為（ステップＳ３２６でＮｏ）、処理はステップＳ３２７に進み、通知メールに先立って、合致数Ｎ個分の一意の英数字が生成され、この一意の英数字に対応した一意のＵＲＬを持つ申込専用ホームページが生成される。この一意の英数字は登録された荷物情報／空車情報を特定する情報を含む他、各通知メール送信相手毎に異なる英数字部分も含まれており、通知ログにＵＲＬと共に記録される。
【００４８】
この一意のＵＲＬを持つ申込専用ホームページが生成されるのは、通知メールにこのＵＲＬを含めることで、認証も含め、登録された荷物情報へ携帯電話等から直接入札出来るようにするためである。通常、荷物情報に入札をする為には、パソコン上で、空車情報が未登録の場合、詳細な空車情報を登録しなければならないし、本実施形態のように空車情報が登録済みでも入札用ＵＲＬの入力、ＩＤ／パスワードの登録による認証、メニュー選択といった操作をする必要があるが、携帯電話上で、こうした一連の作業を行うには作業負荷がかかるからである。
【００４９】
次にステップＳ３２８では、登録された荷物情報／空車情報の概要と前述の申込ホームページのＵＲＬを含む通知メールの情報が合致数Ｎだけ生成され通知メールは求貨求車サーバ１０１から通知先（本設例では関東倉庫社の端末）に送信される。通知メールの例を図７に示す。本フローチャートでは、車主携帯端末１０５に送信されるが、これに限るものではなく、車主端末１０３にも送信される。
【００５０】
又、反対に荷主端末１０４から条件に合致した空車情報が登録された場合に通知するように登録されている場合であれば、登録された空車情報の概要と申込ホームページのＵＲＬを含む通知メールが荷主端末１０４に送信される。
【００５１】
通知メールに記されたＵＲＬに含まれる一意の英数字は登録された荷物情報／空車情報を特定する情報を含む他、各通知メール送信相手毎に異なる英数字部分も含まれているので、どの会員が、どの情報にアクセスしているかを判別できる。
【００５２】
なお、セキュリティを強化する場合、ここにアクセスした後、ＩＤ、パスワードの登録を要求させることは容易に考えられる。また、各通知メール送信相手毎に異なる英数字部分を乱数等を用いて多目の桁数を生成すれば、他者が出鱈目のＵＲＬを指定してもヒットすることも事実上なくなる。
【００５３】
次にステップＳ３０５では、（関東倉庫社の）車主携帯端末１０５がこの通知メールを受信する。たまたま、外出していた配車担当者は、携帯電話上で、この情報を見ることができる（図４に示すように、表示画面が限られているので、単純な内容とした）。
【００５４】
次にステップＳ３０６では、この関東倉庫社の配車担当者は、このメールに付加されたＵＲＬを選択することで、登録された荷物情報の詳細を要求する情報を送信する。ステップＳ３２９では、求貨求車サーバ１０１がこの要求を受信し、ステップＳ３３０では荷物情報の詳細が車主携帯端末１０５に送信される。
【００５５】
ステップＳ３０６では、車主携帯端末１０５が荷物情報の詳細を受信する。このようにして例えば携帯電話上から、直接、インターネットに接続し、登録された荷物情報の詳細を表示させることが出来る。その後、端末上に表示されたこの荷物に対する入札を行うか否かのボタン（エントリーボタン）を押下することで、直接、荷物に対する空車のエントリーが可能となる。
【００５６】
エントリーボタンを押下した場合（ステップＳ３０８でＹｅｓの場合）、処理はステップＳ３０９に進み、車主携帯端末１０５エントリー情報が送信され、ステップＳ３３２では、求貨求車サーバ１０１がこのエントリー情報を受信し、ステップＳ３３３では、エントリー登録が行われる。このエントリー登録は求貨求車サーバ１０１のエントリーテーブルに記録される。
【００５７】
ここで、通知情報に対応する空車情報が未登録であった場合を説明する。この場合、携帯電話による、各種データの登録は困難であり、とりあえず、簡易情報の入札のみを済ませ、後ほど、詳細データを修正する使われ方も容易に想像できる。そこで、携帯電話で入札のボタンを押下した後は、図８に示すような画面において、車番の入力欄と、希望金額の入力欄と、登録ボタンの三種類の操作のみを行うようにするようにすればよい。
【００５８】
ここで、車番の入力欄は、予め車種をマスタ登録することで、その情報を呼び出すことが出来るものであり、例えば、ナンバープレートの数値を個別の認識キーとする事ができる。車番のマスタ登録は、例えば、車種、車番、運転手名、携帯電話番号などが考えられる。車番の入力、希望金額の入力ともに、数値入力となるため、携帯電話からの登録も容易に出来る。最後に登録ボタンを押下することで、荷物情報への入札が完了となる。このように構成することで、たとえ空車情報が未登録の場合であっても、通知条件に合致する荷物情報の登録があれば、直ちに簡易な操作で入札を行うことができ、機会損失を防止することができる。
【００５９】
登録された荷物情報についてのエントリーが求貨求車サーバ１０１のエントリーテーブルに登録されると、処理はステップＳ３３４に進み、マッチング業務を行う幹事会社端末１０２又は幹事会社携帯端末１０６（設例ではサノン社配車担当者の端末）あるいはその両方へ、入札があった旨のエントリー通知メールが送信される。このメール上には、荷物情報等の登録通知メール同様、ユニークなＵＲＬが付加されており、ここにアクセスすることで、直接マッチング画面を表示させることが出来る。
【００６０】
このマッチング画面には、１つ以上のエントリー情報が表示されており複数のエントリーがあった場合は特定の一つのエントリーを選択することで契約が確定する。このエントリー通知メールはエントリー１件づつに大して１回送信しても良いし、一定時間に特定の荷物情報に対して複数件の車主からのエントリーがあった場合、複数件をまとめて通知しても良い。特定の空車情報に対して複数件の荷主からのエントリーがあった場合、も同様に考えることができる。
【００６１】
処理はステップＳ３１５に進み、幹事会社端末１０２又は幹事会社携帯端末１０６がエントリー通知メールを受信する。次にメールに付加されたユニークなＵＲＬが指定されると、処理はステップＳ３１６に進み、幹事会社端末１０２又は幹事会社携帯端末１０６にマッチング情報の画面が表示される。マッチング担当者は、登録された荷物情報、入札された空車情報を確認し、相互の条件に問題がないと判断すれば、特定のエントリーを指定し契約完了ボタンを押下する。するとマッチング情報が求貨求車サーバ１０１に送信される。
【００６２】
処理はステップＳ３３５に進み、求貨求車サーバ１０１で受信したマッチング情報に基づいてマッチング処理が行われ契約が確定する。このとき、ステップＳ３２７で生成された申込専用ホームページは、契約当事者分を除き削除される。ついで処理はステップＳ３３５に進み、求貨求車サーバ１０１から図９に示すような契約通知メールが、車主携帯端末１０５及び車主端末１０３（フローチャート上は不図示）及び荷主端末１０４に送信され、各々の端末が受信する（ステップＳ３１０及びステップＳ３１２）。設例では、契約が完了した時点で、荷物情報を登録した、イクサ社、空車情報を入札した関東倉庫社には、契約完了メールが送信され、この時点で、配車完了を確認することが出来る。
【００６３】
以上が、配車業務にいたるまでの一連の業務であるが、このようなＰＵＳＨ型の情報通知機能を利用することで、配車完了後の業務にも活用することができる。
【００６４】
例えば、情報登録後、急遽、運転手が変わる、重量が変わるなどの、情報変更が発生した場合、修正情報を登録した時点で、荷主（イクサ社）、車主（関東倉庫社）、幹事会社（サノン社）各社の担当者へ上変更の通知を出すことが出来る。
【００６５】
また、契約完了メールに、図９の下部に示すような積込完了／配送完了の通知を指定するためのＵＲＬを付加することで、車主携帯端末１０５からそのＵＲＬにアクセスすると、例えば、求貨求車サーバ１０１の契約テーブルに積込完了、配送完了のフラグを立てることができる。これは、配送完了メールを直接、運転手の携帯電話に送信したり、或いは、配車担当者が、運転手に転送することで実現が可能である。運転手は、荷物の積込／配送が完了した時点で、携帯電話からＵＲＬにアクセスし、積込完了／配送完了ボタンを押下する。
【００６６】
この時点で、荷主端末１０４（イクサ社）、幹事会社端末１０２や幹事会社携帯端末１０６（サノン社）に、図１０に示すような、空車情報及び荷物情報と積込完了や配送完了などの進捗を通知する内容が記されたメールが送信され、荷主や幹事会社側も輸送の進捗の確認を取ることができるようになる。
【００６７】
本実施形態では、各種通知手段として、電子メールを用いて説明したが、これに限るものではなく、例えばボイスメール＋メール読み上げ機能により、走行中の運転手に各種通知を音声で行う実施形態も考えられる。又、携帯電話のｉアプリ等で音声やアニメーションで情報の登録を通知しても良いし、いわゆるメッセージングソフトウェアで通知しても良いことは言うまでもない。
【００６８】
又、車を１台だけ保有している車主であれば、車の登録番号を予め求貨求車サーバ１０１の会員テーブルに登録しておけば、金額の入力だけで仮入札ができるように構成することもできる。あるいは、車種と積日と降日によって料金が決まる場合であれば、車の登録番号の入力だけで仮入札ができるように構成することもできる。
【００６９】
さらには、荷主端末１０４と車主端末１０３や幹事会社端末１０２や車主携帯端末１０５や幹事会社携帯端末１０６をピアツーピアで接続する構成も考えられる。この場合各テーブル等は幹事会社端末１０２のハードディスクに記憶される。
【００７０】
なお本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【００７１】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれる。
【００７２】
【発明の効果】
以上説明したように本発明によれば、マッチングサーバにおけるマッチング率を向上させ操作負担を軽減することができる。特に求貨求車システムにおいて登録される荷物情報・空車情報に対して、自分の望む情報がＰＵＳＨ型で携帯電話等の車主携帯端末や幹事会社携帯端末に配信され、更に条件の合致する情報であれば、極めて簡易な操作で入札可能なので、機会損失の低減と業務負荷の軽減を実現することができる。
【００７３】
又、本発明によれば、通知情報に対応する空車情報が未登録であった場合にも通知条件に合致する荷物情報の登録があれば、直ちに簡易な操作で入札を行うことができ、機会損失を防止することができる。
【００７４】
また本発明によれば、運転手が、荷物の積込／配送が完了した時点で、携帯電話からＵＲＬにアクセスし、積込完了／配送完了ボタンを押下するだけで、荷主端末１０４や幹事会社端末１０２や幹事会社携帯端末１０６に、空車情報及び荷物情報と積込完了や配送完了などの進捗を通知する内容が記されたメールが送信されるので、荷主や幹事会社側も輸送の進捗の確認を容易に取ることができるようになる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る求貨求車システムの全体的な構成を示す概念図である。
【図２】本発明の実施の形態に係る求貨求車システムのサーバ及び車主携帯端末を除く各端末のハードウェア構成を示すブロック図である。
【図３】本発明の実施の形態に係る求貨求車システムにおける処理の詳細を示すフローチャートである。
【図４】本発明の実施の形態に係る携帯端末の表示例を示す図である。
【図５】本発明の実施の形態に係る求貨求車サーバに荷物情報検索条件及び情報通知先登録するための画面を示す図である。
【図６】本発明の実施の形態に係る求貨求車サーバに荷物情報を登録するための画面を示す図である。
【図７】本発明の実施の形態に係る求貨求車サーバから車主端末に送信される荷物情報登録通知メールを車主端末で受信したときの画面を示す図である。
【図８】本発明の実施の形態に係る求貨求車サーバから車主携帯端末に送信される荷物情報登録通知メールを車主端末で受信したときの画面（空車情報未登録時）を示す図である。
【図９】本発明の実施の形態に係る求貨求車サーバから荷主端末及び車主携帯端末に送信される契約通知メールをこれら端末で受信したときの画面を示す図である。
【図１０】本発明の実施の形態に係る求貨求車サーバから荷主端末及び幹事会社端末に送信される配送完了通知メールをこれら端末で受信したときの画面を示す図である。
【符号の説明】
２０　　システムバス
２１　　ＣＰＵ
２２　　ＲＡＭ
２３　　ＲＯＭ
２４　　ＬＡＮアダプタ
２５　　ビデオアダプタ
２６　　キーボード
２７　　マウス
２８　　ハードディスク
２９　　ＣＤ−ＲＯＭドライブ
３０　　システムバス
３１　　ＣＰＵ
３２　　ＲＡＭ
３３　　ＲＯＭ
３４　　ＬＡＮアダプタ
３５　　ビデオアダプタ
３６　　キーボード
３７　　マウス
３８　　ハードディスク
３９　　ＣＤ−ＲＯＭドライブ
１００　通信回線
１０１　求貨求車サーバ
１０２　幹事会社端末
１０３　車主端末
１０４　荷主端末
１０５　車主携帯端末
１０６　幹事会社携帯端末
１１０　携帯端末Ａ
１２０　携帯端末Ｂ
１３０　印刷装置
１５０　通信回線
【図１】
2004070823.tif 000003
【図２】
2004070823.tif 000004
【図３】
2004070823.tif 000005
【図４】
2004070823.tif 000006
【図５】
2004070823.tif 000007
【図６】
2004070823.tif 000008
【図７】
2004070823.tif 000009
【図８】
2004070823.tif 000010
【図９】
2004070823.tif 000011
【図１０】
2004070823.tif 000012