JP4479985B2 - 求貨求車サーバ及びそのプログラム - Google Patents
求貨求車サーバ及びそのプログラム Download PDFInfo
- Publication number
- JP4479985B2 JP4479985B2 JP2001401515A JP2001401515A JP4479985B2 JP 4479985 B2 JP4479985 B2 JP 4479985B2 JP 2001401515 A JP2001401515 A JP 2001401515A JP 2001401515 A JP2001401515 A JP 2001401515A JP 4479985 B2 JP4479985 B2 JP 4479985B2
- Authority
- JP
- Japan
- Prior art keywords
- credit
- information
- shipper
- primary
- amount
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Traffic Control Systems (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、荷主が使用する荷主端末及び車主が使用する車主端末とを通信回線を介して接続し、前記荷主と前記車主間の配送依頼を支援する求貨求車サーバ及びその制御方法、求貨求車システム、プログラムに関するものである。
【０００２】
【従来の技術】
従来の求貨求車システムでは、荷主の荷物情報の登録時点でその荷物の搬送を行う運送会社が決まっている場合、荷物情報中にその運送会社も指定する。これにより、この荷物は、指定の運送会社にのみ公開され、その後、運送会社（車主）が自身の搬送可能な運送車の空車情報の登録を行ない、求貨求車システムを運営する幹事会社がその荷物情報と空車情報とのマッチング処理を行うことによって、荷主と車主間の契約が成立する。
【０００３】
このような求貨求車システムには、第三者の金融機関が審査する与信決済機能を付加させたシステムは無く、幹事会社が自社で持つ与信枠にて運賃の決済を行っているのが現状である。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来の求貨求車システムでは、以下のような課題があった。
【０００５】
（イ）幹事会社の独自の与信による運賃決済
幹事会社が荷主から荷物を受注し受託運賃を決済する場合、通常は今までの取引慣習を鑑み、独自の与信枠と信頼関係に基づいて幹事会社の責任において決済を行っていた。信用取引が成立している間は問題は無いが、荷主からの支払いが滞ることで、幹事会社は自社の責任においてキャッシュフローを調整し、傭車に対して運賃を支払っていたのが現状である。また、荷主によって様々な支払いサイトを求貨求車システム上で提供し、幹事会社のキャッシュフロー調整能力によって吸収し決済を行っていた。
（ロ）荷主（債務者）のリアルタイムな信用状況の把握
現状は、月単位などで荷主（債務者）の与信状況を確認しており、たとえ与信枠を超えた決済が行われていようとしても、リアルタイムで荷主の輸送依頼に与信枠オーバーの事由から幹事会社が受託拒否を行うことが不可能とされていた。
【０００６】
本発明は上記の課題を解決するためになされたものであり、信頼性があり、かつ容易にかつ安全にシステムを利用することができる求貨求車サーバ及びその制御方法、求貨求車システム、プログラムを提供することを目的とする。
【００１２】
上記の目的を達成するための本発明による求貨求車サーバは以下の構成を備える。即ち、
荷主が使用する荷主端末及び与信管理サーバと通信可能な求貨求車サーバであって、
前記荷主端末から受信したログイン時の荷主の会員番号及びパスワードにより前記荷主を特定する認証処理を行い、前記認証処理に引き続き前記与信管理サーバに前記会員番号で特定された前記荷主の与信を照会するための一次与信照会情報を送信する一次与信照会手段と、
前記一次与信枠照会情報に応じて、前記与信管理サーバの与信情報記憶手段から読み出された与信枠と、前記与信枠照会情報に応じて、少なくとも荷主の会員番号と取引口座の残高金額と入出金予定金額を含む取引明細情報を記憶する取引明細情報記憶手段から読み出された取引口座の残高金額と入出金予定金額と、を含む一次与信情報を受信する一次与信情報受信手段と、
前記ログイン時点にて、前記与信枠と前記取引口座の残高金額との差が所定値以上であるか否かにより前記荷主端末の荷主の一次与信判定を行なう一次与信判定手段と、
前記一次与信判定結果が与信可の場合に、荷物登録画面情報を前記荷主端末に送信し、前記一次与信判定結果が与信不可の場合に、一次与信が不可のためログインできないことを示す画面情報を前記荷主端末に送信する画面情報送信手段と、
前記荷物登録画面情報に応じて前記荷主端末で入力された希望運賃額を含む荷物情報を受信する荷物情報受信手段と、
前記荷主の会員番号を用いて前記与信サーバから該荷主の該取引口座の残高金額に前記入金予定金額を取得するための二次与信照会情報を前記与信管理サーバに送信する二次与信照会情報送信手段と、
前記二次与信照会情報に応じて前記与信管理サーバで読み出された前記荷主の取引口座の残高金額と前記入金予定金額を含む二次与信情報を受信する二次与信情報受信手段と、
前記荷物情報の受信に応じて、前記希望運賃額が前記取引口座の残高金額を超えると判定した場合には、該取引口座の残高金額に前記入金予定金額を加算して、前記荷主の二次与信の可否を判定する二次与信判定手段と
を備える。
【００１３】
上記の目的を達成するための本発明によるプログラムは以下の構成を備える。即ち、
荷主が使用する荷主端末及び与信管理サーバと通信可能な求貨求車サーバの制御をコンピュータに実行させるためのプログラムであって、
前記求貨求車サーバを、
前記荷主端末から受信したログイン時の荷主の会員番号及びパスワードにより前記荷主を特定する認証処理を行い、前記認証処理に引き続き前記与信管理サーバに前記会員番号で特定された前記荷主の与信を照会するための一次与信照会情報を送信する一次与信照会手段と、
前記一次与信枠照会情報に応じて、前記与信管理サーバの与信情報記憶手段から読み出された与信枠と、前記与信枠照会情報に応じて、少なくとも荷主の会員番号と取引口座の残高金額と入出金予定金額を含む取引明細情報を記憶する取引明細情報記憶手段から読み出された取引口座の残高金額と入出金予定金額と、を含む一次与信情報を受信する一次与信情報受信手段と、
前記ログイン時点にて、前記与信枠と前記取引口座の残高金額との差が所定値以上であるか否かにより前記荷主端末の荷主の一次与信判定を行なう一次与信判定手段と、
前記一次与信判定結果が与信可の場合に、荷物登録画面情報を前記荷主端末に送信し、前記一次与信判定結果が与信不可の場合に、一次与信が不可のためログインできないことを示す画面情報を前記荷主端末に送信する画面情報送信手段と、
前記荷物登録画面情報に応じて前記荷主端末で入力された希望運賃額を含む荷物情報を受信する荷物情報受信手段と、
前記荷主の会員番号を用いて前記与信サーバから該荷主の該取引口座の残高金額に前記入金予定金額を取得するための二次与信照会情報を前記与信管理サーバに送信する二次与信照会情報送信手段と、
前記二次与信照会情報に応じて前記与信管理サーバで読み出された前記荷主の取引口座の残高金額と前記入金予定金額を含む二次与信情報を受信する二次与信情報受信手段と、
前記荷物情報の受信に応じて、前記希望運賃額が前記取引口座の残高金額を超えると判定した場合には、該取引口座の残高金額に前記入金予定金額を加算して、前記荷主の二次与信の可否を判定する二次与信判定手段として機能させるためのプログラム。
【００１４】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００１５】
本発明の求貨求車システムは、従来の求貨求車システムの概念に以下の機能を追加している。
【００１６】
● 第三者金融機関の提供するe-Marketplace向け与信決済機能
● 第三者金融機関の提供するe-Marketplace向け代行決済機能
● 求貨求車サイトへのログイン時の自動与信認証
● 荷主の荷物登録時のリアルタイム与信シミュレーション
● 荷主の荷物登録時の残高不足による登録不可の際の、残高報告及び取引再開時期の告知機能
＜概要＞
現在までの求貨求車システムにおいては、原則決済機能は幹事会社の持つ勘定系のシステムが司っており、幹事会社のキャッシュフロー及び資金調整力に大きく依存していたと言える。おのずと荷主から受託する運賃と、車主に支払う運賃との支払サイトに時間、種類（手形、小切手、現金等）にずれが生じる際は、幹事会社はそれなりにリスクを受ける可能性が出てくる。
【００１７】
そういったリスクを分散、回避し、健全な荷物と車の取引を行い、且つ契約に基づく幹事会社の健全なキャッシュフロー体制を構築していくことで、契約と金融の２つの流れが幹事会社の管理化におかれ、より健全で取引高の高いマーケットを構成することが可能となる。具体的には次の２点が大きい発明となる。
【００１８】
▲１▼ ログイン時認証
荷主会員が幹事会社に運送委託（発注）を行う際、求貨求車システムが提供する求貨求車サイトにログインし荷物を登録することとなる。その際、会員番号とパスワードを入力し、ログインをすることになるが、ログインと同時にその会員の番号とパスワードが自動的に与信決済シミュレーション機能を有する与信管理サーバへと接続し、リアルタイムなデータでログインを認証するか否かを求貨求車サーバが判断する。ログイン時点にて、あらかじめ金融機関が設定する荷主会員の与信枠が不足している場合は、求貨求車サイトへのログインが拒否される。この機能により、求貨求車サイトにアクセスする会員は全てリアルタイムで与信上信頼のおける会員のみということになり、その後の取引も当然ながら健全な取引が行われることになる。
【００１９】
▲２▼ 荷物登録時認証
ログインが許可された荷主会員であっても残高次第では、荷物の登録時の希望運賃に満たず、決済時になってからトラブルを起こす可能性も出てくる。そういった仕組みでは、リアルタイムでの与信決済機能とは言えない。そこで、本発明では、荷主が荷物を登録する際にも与信決済シミュレーション機能が働き、荷主が登録する希望運賃と、その会員の現時点での与信残高の差を求貨求車サーバが判断し、荷物登録の可否を判断し画面で告知する。その際、残高不足の金額と取引再開時期の案内を同画面にて会員に案内を行う。
【００２０】
次に、上述した本発明を実現する実施形態の求貨求車システムの構成について、図１を用いて説明する。
【００２１】
図１は本実施形態の求貨求車システムの構成を示す図である。
【００２２】
本実施形態の求貨求車システムは、荷主の荷主端末１２０、車主の車主端末１３０、求貨求車システムを実現する幹事会社が運営管理する求貨求車サーバ１１０、金融期間が運営管理する与信管理サーバ１００間を通信回線１７０を介して相互に接続して求貨求車システムを構築する。特に、この求貨求車システムでは、第三者金融機関が提供する与信決済機能を実現する与信管理サーバ１００を構成することで、荷主、車主といったサプライヤー及びバイヤーを広く集めてマーケットを活性化させ、かつ代行与信決済による信用取引の実現から、信頼のおけるマーケットを形成することができる。
【００２３】
幹事会社は、ＷＥＢサーバ機能を含む求貨求車サーバ１１０を有し、通信回線１７０を介して、荷主端末１２０、車主端末１３０から送信されてくる各種情報を登録し、管理する。また、求貨求車サーバ１１０には、各種情報を管理するためのテーブルとして、空車テーブル１１５、荷物テーブル１１６、会員テーブル１１７、契約テーブル１１８を有している。これらの各テーブルの構成の詳細については、後述する。
【００２４】
尚、求貨求車サーバ１１０は、幹事会社の管理下でなくても良く、例えば、ＩＳＰ、ＡＳＰ等の他のベンダーの管理下であっても良い。
【００２５】
金融機関は、ＷＥＢサーバ機能を含む与信管理サーバ１００を有し、通信回線１７０を介して、求貨求車サーバ１１０から送信されてくる荷主の会員情報に基づいて、その荷主の与信決済を行う。また、与信管理サーバ１００には、各種情報を管理するためのテーブルとして、与信テーブル１０５及び取引明細管理テーブル１０６を有している。これらの各テーブルの構成の詳細については、後述する。
【００２６】
尚、図１の各テーブルは別々に構成されているが、１つの記憶媒体上の異なる記憶領域にそれぞれのテーブルが構成されていても、もちろん構わない。
【００２７】
荷主は、通信回線１７０を介して求貨求車サーバ１１０に接続する荷主端末１２０を有し、少なくともＷＥＢブラウザ機能を有する。荷主端末１２０では、配送依頼対象の荷物の荷物情報を入力して求貨求車サーバ１１０へ送信し、その荷物情報に対応する空車情報がある場合には、その荷主と車主間での契約成立に関する情報を受信する。
【００２８】
車主は、通信回線１７０を介して求貨求車サーバ１１０に接続する車主端末１３０を有し、少なくともＷＥＢブラウザ機能を有する。この車主端末１３０は、運送可能な運送車の空車情報を入力して求貨求車サーバ１１０へ送信し、その空車情報に対応する荷物情報がある場合には、その車主と荷主間での契約成立に関する情報を受信する。
【００２９】
１７０は通信回線であり、典型的にはインターネットであるが、ＬＡＮ／ＷＡＮや電話回線、専用デジタル回線、ＡＴＭ（非同期転送モード）やフレームリレー回線でも良い。そして、この通信回線１７０によって、荷主端末１２０、車主端末１３０、求貨求車サーバ１１０、与信管理サーバ１００が相互に接続される。
【００３０】
次に、上述の求貨求車サーバ１１０に構築されている各テーブルについて説明する。
【００３１】
求貨求車サーバ１１０のハードディスク２８（図２）には、車主の空車情報を管理する空車テーブル１１５、荷主の荷物情報を管理する荷物テーブル１１６、本求貨求車サーバ１１０を利用する会員（荷主／車主）の会員情報を管理する会員テーブル１１７、荷主と車主間の契約の契約情報を管理する契約テーブル１１８がそれぞれ構築されている。
【００３２】
空車テーブル１１５は、空車情報として、例えば、空車会員番号、空車番号、契約番号、空車地、希望行き先、空車日、戻り日、車種（幌付き／パネル、保冷／保温設備有無、パワーゲート有無）、積載量、登録金額、積地、降地を有する。
【００３３】
荷物テーブル１１６は、荷物情報として、例えば、荷物会員番号、荷物番号、契約番号、商品名、積地、降地、積日、降日、重量、積込条件、荷降条件、指定車種、登録金額を有する。
【００３４】
会員テーブル１１７は、会員情報として、例えば、会社名、住所、連絡先、会員番号（番号）、パスワードを有する。
【００３５】
会員属性とは、求貨求車システムの会員、つまり、荷主会員、車主会員、その両方の会員を示すフラグが存在する。
【００３６】
契約テーブル１１８は、契約情報として、例えば、配送契約が成立した荷主の荷物会員番号と車主の空車会員番号、その配送契約を示す固有の契約番号を有する。
【００３７】
求貨求車サーバ１１０は、荷物テーブル１１６及び空車テーブル１１５それぞれに登録されている荷物情報及び空車情報とのマッチング処理を実行し、マッチングする荷物情報及び空車情報があると、この荷物情報の荷主及び空車情報の車主間での配送契約を成立させる。そして、この配送契約に関する契約情報を作成し、この契約情報、荷物情報、空車情報の３つの情報を対応づけて契約テーブル１１８に記憶する。
【００３８】
次に、上述の与信管理サーバ１００に構築されている各テーブルについて説明する。
【００３９】
与信管理サーバ１００のハードディスク２８には、荷主の与信状況を管理する与信テーブル１０５、各荷主の取引明細を管理する取引明細管理テーブル１０６が構築されている。
【００４０】
与信テーブル１０５は、与信情報として、例えば、荷主の会員番号、荷主の与信枠（与信限度額）、一次与信フラグ及び二次与信フラグを有する。
【００４１】
この一次与信フラグ及び二次与信フラグはそれぞれ、後述する一次与信及び二次与信それぞれの可否を示すフラグであり、可である場合には「ＯＮ」が、否である場合には「ＯＦＦ」がそれぞれ設定される。
【００４２】
取引明細管理テーブル１０６は、取引明細情報として、荷主の会員番号、荷主の取引口座の残高金額、入出金額、入出金日、入出金予定金額、入出金予定日を有する。
【００４３】
次に、本実施形態の求貨求車システムを構成する各種端末、サーバのハードウェア構成について、図２を用いて説明する。
【００４４】
図２は本実施形態の求貨求車システムを構成する各種端末、サーバそれぞれのハードウェア構成を示す図である。
【００４５】
図２において、ＣＰＵ２１、ＲＡＭ２２、ＲＯＭ２３、ＬＡＮアダプタ２４、ビデオアダプタ２５、入力部（キーボード）２６、入力部（マウス）２７、ハードディスク２８、ＣＤ−ＲＯＭドライブ２９はそれぞれシステムバス２０を介して互いに接続されている。システムバス２０は、例えば、ＰＣＩバス、ＡＧＰバス、メモリバス等を意味する。また、図２では、各バス間の接続用チップやキーボードインタフェースや、いわゆるＳＣＳＩやＡＴＡＰＩのような入出力用インタフェースは省略されている。
【００４６】
ＣＰＵ２１は四則演算や比較演算等の各種の演算や、ハードウェアやソフトウェアの制御を行う。ＲＡＭ２２には、ハードディスク２８やＣＤ−ＲＯＭドライブ２９に装着されたＣＤ−ＲＯＭやＣＤ−Ｒ等の記憶媒体から読み出されたオペレーションシステムのプログラムやアプリケーションプログラム（後述する各端末やサーバで実行されるフローチャートを実行する各プログラム）等が記憶され、これらはＣＰＵ２１の制御の元に実行される。
【００４７】
ＲＯＭ２３は、オペレーションシステムと協働してハードディスク等への入出力を司るいわゆるＢＩＯＳ等が記憶される。ＬＡＮアダプタ２４は、ＣＰＵ２１によって制御されるオペレーションシステムの通信プログラムと協働してネットワークを介した外部との通信を行う。ビデオアダプタ２５は、ディスプレイ装置（不図示）に出力する画像信号を生成し、入力部（キーボード）２６や入力部（マウス）２７は端末への指示を入力するために用いられる。
【００４８】
ハードディスク２８は、オペレーションシステムや上述のアプリケーションプログラムを記憶しており、端末の起動時に、または必要に応じてＲＡＭ２２にロードされる。
【００４９】
ＣＤ−ＲＯＭドライブ２９は、ＣＤ−ＲＯＭやＣＤ−ＲやＣＤ−Ｒ／Ｗ等の記憶媒体を装着してアプリケーションプログラムをハードディスク２８にインストールするのに用いる。
【００５０】
尚、ＣＤ−ＲＯＭドライブ２９の代わりにＣＤ−ＲドライブやＣＤ−Ｒ／ＷドライブやＭＯドライブ等を用いても良いのは言うまでもない。
【００５１】
次に、本実施形態の求貨求車システムで実行される処理について説明する。
【００５２】
図３及び図４は本実施形態の求貨求車システムで実行される処理を示すフローチャートである。
【００５３】
尚、本実施形態の求貨求車システムは、求貨求車サーバ１１０によって実現される求貨求車システムＷＥＢサイトに対し、荷主及び車主、幹事会社の各オペレータが自身の端末を用いてそのサイトにアクセスし、ＷＥＢブラウザを介して各種処理を行う。
【００５４】
まず、ステップＳ４０１で、荷主は、荷主端末１２０を用いて、求貨求車サーバ１１０へのアクセス要求を行い、求貨求車システムログイン画面（図６）を表示する。ステップＳ４０２で、その求貨求車システムログイン画面を用いて、会員番号及びパスワードからなるユーザ情報を入力する。この入力されたユーザ情報は求貨求車サーバ１１０へ送信される。
【００５５】
尚、図６の求貨求車システムログイン画面７０００は、例えば、会員番号及びパスワードを入力する各種入力領域７０１及び７０２を有している。７０３は接続ボタンであり、入力領域７０１及び７０２の内容を確定する場合に押下する。接続ボタン７０３が押下されると、入力領域７０１及び７０２の内容がユーザ情報として求貨求車サーバ１１０へ送信される
一方、ステップＳ４２１で、求貨求車サーバ１１０は、荷主端末１２０からユーザ情報を受信する。ステップＳ４２２で、会員テーブル１１７を参照して、受信したユーザ情報中の会員番号に対応する会員（荷主）を特定する。そして、その特定した会員の与信を照会するための一次与信照会情報を生成して、与信管理サーバ１００へ送信する。
【００５６】
尚、この一次与信照会情報は、ユーザ情報中の会員番号から構成される。
【００５７】
一方、ステップＳ４４１で、与信管理サーバ１００は、求貨求車サーバ１１０から一次与信照会情報を受信する。次に、ステップＳ４４２で、一次与信照会情報に基づいて、与信テーブル１０５及び取引明細管理テーブル１０６を参照して、照会対象の会員の一次与信判定を行う。
【００５８】
この一次与信判定は、受信した一次与信照会情報中の会員番号に対応する与信情報を与信テーブル１０５から取得し、また、取引明細管理テーブル１０６から取引明細情報を取得する。次に、与信情報中の与信枠と取引明細情報中の荷主の取引口座の残高金額との差が所定値以上であるかを判定する。そして、差が所定値未満である場合には一次与信フラグを「ＯＮ」、差が所定値以上である場合には一次与信フラグを「ＯＦＦ」に設定する。
【００５９】
尚、この所定値は、与信管理サーバ１００の管理者によって適宜設定可能であり、荷主の取引実績や入出金予定金額等の情報に基づいて、荷主毎に個別の所定値を設定することも可能である。また、与信枠に関係なく、単に荷主の取引口座の残高金額に基づいて、与信フラグを設定するようにしても良い。
【００６０】
そして、ステップＳ４４３で、一次与信判定結果（一次与信フラグ）を求貨求車サーバ１１０へ送信する。
【００６１】
一方、ステップＳ４２４で、求貨求車サーバ１１０は、与信管理サーバ１００から一次与信判定結果を受信する。ステップＳ４２５で、一次与信判定結果に基づいて、一次与信の可否を判定する。一次与信が否である（一次与信フラグがＯＦＦである）場合（ステップＳ４２５でＮＯ）、ステップＳ４２６に進み、一次与信不可通知を生成して、荷主端末１２０へ送信する。その後、ステップＳ４０３で、荷主端末１２０は、一次与信不可通知を受信する。
【００６２】
尚、この一次与信不可通知は、例えば、図６の求貨求車システムログイン画面７０００上に対し、例えば、図７に示すように、一次与信が不可である旨を示す内容を領域７０４で表示することで実現する。
【００６３】
一方、一次与信が可である（一次与信フラグがＯＮである）場合（ステップＳ４２５でＹＥＳ）、ステップＳ４２７に進み、求貨求車サーバ１１０は、荷物登録画面情報を生成する。ステップＳ４２８で、生成した荷物登録画面情報を荷主端末１２０へ送信する。
【００６４】
ステップＳ４０４で、荷主端末１２０は、求貨求車サーバ１１０から荷物登録画面情報を受信して、その荷物登録画面情報に基づく荷物登録画面（図８）を表示する。そして、この荷物登録画面を用いて、配送依頼対象の荷物の荷物情報を入力する。この入力された荷物情報は求貨求車サーバ１１０へ送信され、一旦、求貨求車サーバ１１０のＲＡＭ２２に記憶される。
【００６５】
尚、図８の荷物登録画面は、例えば、商品名、物量、希望運賃、積日、降日を入力する各種入力領域８００１〜８００５を有している。また、８００６は登録ボタンであり、各種入力領域の内容を確定する場合に押下する。そして、登録ボタン８００６が押下されると、各種入力領域の内容が荷物情報として求貨求車サーバ１１０へ送信される。また、８００７は削除ボタンであり、各種入力領域の内容を取り消す場合に押下する。
【００６６】
ステップＳ４２９で、求貨求車サーバ１１０は、荷主端末１２０から荷物情報を受信し、一旦ＲＡＭ２２に記憶する。ステップＳ４３１で、会員テーブル１１７を参照して、受信した荷物情報中の会員番号に対応する会員（荷主）を特定する。そして、その特定した会員の与信を照会するための二次与信照会情報を生成して、与信管理サーバ１００へ送信する。
【００６７】
尚、この二次与信照会情報は、既に受信したユーザ情報中の会員番号及び荷物情報中の希望運賃から構成される。
【００６８】
一方、ステップＳ４４４で、与信管理サーバ１００は、求貨求車サーバ１１０から二次与信照会情報を受信する。次に、ステップＳ４４５で、二次与信照会情報に基づいて、与信テーブル１０５及び取引明細管理テーブル１０６を参照して、照会対象の会員の二次与信判定を行う。
【００６９】
この二次与信判定は、単純に行う場合には、二次与信照会情報中の会員番号に対応する取引明細情報を取引明細管理テーブル１０６から取得して、その取引明細情報中の荷主の取引口座の残高金額と、二次与信照会情報中の希望運賃を比較する。比較の結果、希望運賃が残高金額未満である場合には二次与信フラグを「ＯＮ」、希望運賃が残高金額以上である場合には二次与信フラグを「ＯＦＦ」に設定する。
【００７０】
より厳密に行う場合には、更に、受信した二次与信照会情報中の会員番号に対応する与信情報を与信テーブル１０５から取得し、その与信情報中の与信枠と、取引明細情報中の荷主の取引口座の残高金額と、二次与信照会情報中の希望運賃を比較する。比較の結果、希望運賃が与信枠以上である場合には二次与信フラグを「ＯＦＦ」、希望運賃が与信枠未満かつ残高金額以上である場合あるいは希望運賃が残高金額未満である場合には二次与信フラグを「ＯＮ」に設定する。
【００７１】
尚、上述の一次与信判定及び二次与信判定の方法は、一例であって、用途や目的等に応じて与信情報及び取引明細情報に基づく与信判定を行うことができる。例えば、荷主の取引口座への入金予定金額がわかっていて、その入金によって与信が可となるような場合には、与信フラグを「ＯＮ」に設定するような構成であっても良い。
【００７２】
ステップＳ４４６で、与信管理サーバ１００は、二次与信判定結果を求貨求車サーバ１１０へ送信する。
【００７３】
一方、ステップＳ４３２で、求貨求車サーバ１１０は、与信管理サーバ１００から二次与信判定結果を受信する。図４のステップＳ５３３で、二次与信判定結果に基づいて、二次与信の可否を判定する。二次与信が否である（二次与信フラグがＯＦＦである）場合（ステップＳ５３３でＮＯ）、ステップＳ５３４に進み、ＲＡＭに記憶した荷物情報を削除し、更に、二次与信不可通知を生成して、荷主端末１２０へ送信する。その後、ステップＳ５０６で、荷主端末１２０は、二次与信不可通知を受信する。
【００７４】
一方、二次与信が可である（二次与信フラグがＯＮである）場合（ステップＳ５３３でＹＥＳ）、ステップＳ５３５に進む。次に、ステップＳ５３５で、求貨求車サーバ１１０は、登録確認画面情報を生成する。ステップＳ５３６で、生成した登録確認画面情報を荷主端末１２０へ送信する。
【００７５】
ステップＳ５０７で、荷主端末１２０は、求貨求車サーバ１１０から登録確認画面情報を受信して、その登録確認画面情報に基づく登録確認画面を表示する。そして、その登録確認画面を用いて、配送依頼対象の荷物の荷物情報の登録の可否を示す登録確認情報を入力する。この入力された登録確認情報は求貨求車サーバ１１０へ送信される。
【００７６】
ステップＳ５３７で、求貨求車サーバ１１０は、荷主端末１２０から登録確認情報を受信する。次に、ステップＳ５３８で、受信した登録確認情報に基づいて、ＲＡＭ２２に記憶された荷物情報の登録の可否を判定する。登録が否である場合（ステップＳ５３８でＮＯ）、ステップＳ４２７に戻る。一方、登録が可である場合（ステップＳ５３８でＹＥＳ）、ステップＳ５３９に進み、ＲＡＭ２２に記憶された荷物情報を正式な荷物情報として荷物テーブル１１６に登録する。
【００７７】
以上説明したように、本実施形態によれば、荷主端末１２０を利用する荷主の与信の可否をログイン時及び荷物情報登録時にと２段階で判定し、その判定結果に基づいて荷物情報を求貨求車サーバ１１０の荷物テーブル１１６に正式に登録する。これにより、信頼のおける荷主からの荷物情報だけを登録することができ、より信頼性が向上した求貨求車システムを実現することができる。
【００７８】
つまり、現行の求貨求車システムと、第三者金融機関が提供する与信決済機能が連携することで、幹事会社が荷主から輸配送依頼を受注する際、タイミング良く与信情報を取得することで、より確実性の高い、信用取引が成立することになる。また、信頼のおける第三者金融機関が与信を設定することで、幹事会社の債権上のリスク負担を軽減させることになり、さらには第三者金融機関が幹事会社に代わって代行決済を行うことで、幹事会社のキャッシュフローが安定し、運賃支払い先である、運送会社の経営安定化にも繋がる。
【００７９】
また、現行の求貨求車システム上では、バッチでの与信情報のため、リアルタイムでの与信情報がマーケットプレイスでの決済には反映されず、結果としてリスク波動の吸収を幹事会社の責任において行っていた。これに対し、本発明の求貨求車システムでは、リアルタイムで与信枠を超えている荷主は求貨求車システムＷＥＢサイトへログインを試みる段階ですでに、同サイトへの受け付けが拒否され、荷物の登録さえ不可能な状態となる。また、本実施形態のようなe-Marketplaceという信頼条件に裏付けされる取引においては、信用力の低下した荷主は与信が正常に復帰できるまでは、求貨求車システムを利用できないこととするのが、外部から求貨求車システムを見た際に、非常に信頼のおける求貨求車システムであることを認知させることができる。
【００８０】
尚、上記実施形態では、二次与信が否である場合には、荷物情報の登録を拒否する構成としているが、荷主端末１０２を利用する荷主の与信状況は、日々変化するものである。特に、荷主の取引口座への小額の入金によって与信が可となるような場合には、その旨を荷主へ伝えて、荷物情報の内容の修正を行う機会を与えたり、荷主への入金を促すようなことが可能である。
【００８１】
以下、本実施形態の応用例について、図５を用いて説明する。
【００８２】
図５は本実施形態の求貨求車システムで実行される処理の応用例を示すフローチャートである。
【００８３】
尚、図５のフローチャートは、図３のステップＳ４３２以降で実行される処理を示すものである。
【００８４】
ステップＳ４３２で、求貨求車サーバ１１０は、与信管理サーバ１００から二次与信判定結果を受信する。ステップＳ６３３で、二次与信判定結果に基づいて、二次与信の可否を判定する。二次与信が可である（二次与信フラグがＯＮである）場合（ステップＳ６３３でＹＥＳ）、図４のステップＳ５３６に進み、上述の処理を実行する。一方、二次与信が否である（二次与信フラグがＯＦＦである）場合、ステップＳ６３４に進み、荷主の与信枠に関する与信枠通知情報を生成して、荷主端末１２０へ送信する。
【００８５】
その後、ステップＳ６０６で、荷主端末１２０は、与信枠通知を受信して、与信枠を表示する。
【００８６】
尚、この与信枠通知情報は、例えば、図８の荷物登録画面８０００に対し、例えば、図９に示すように、与信枠の内容を領域８００６で表示することで実現する。荷主は、この領域８００６の内容に応じて、登録内容を変更するか、あるいは登録対象の荷物情報を削除するかの判断を行うことになる。登録対象の荷物情報の変更を依頼する場合には、変更ボタン８００９を押下する。また、登録対象の荷物情報の削除を依頼する場合には、削除ボタン８００７を押下する。
【００８７】
この変更ボタン８００９／削除ボタン８００７の押下によって、ステップＳ６０７で、荷主端末１２０は変更情報／削除情報を生成し、求貨求車サーバ１１０へ送信する。
【００８８】
一方、ステップＳ６３５で、求貨求車サーバ１１０は、変更情報／削除情報のどちらを受信したかを判定する。削除情報を受信した場合（ステップＳ６３５でＹＥＳ）、ステップＳ６３６に進み、ＲＡＭ２２に記憶された荷物情報を削除して、処理を終了する。
【００８９】
一方、変更情報を受信した場合（ステップＳ６３５でＮＯ）、ステップＳ６３７に進む。ステップＳ６３７で、ＲＡＭ２２に記憶された荷物情報の内容を荷物登録画面情報に反映した登録修正画面情報を生成する。ステップＳ６３８で、登録修正画面情報を荷主端末１２０へ送信する。
【００９０】
ステップＳ６０８で、荷主端末１２０は、求貨求車サーバ１１０から登録修正画面情報を受信して、その登録修正画面情報に基づく登録修正画面を表示する。そして、この登録修正画面を用いて、配送依頼対象の荷物の荷物情報を修正した登録修正情報を入力する。この入力された登録修正情報は求貨求車サーバ１１０へ送信され、一旦、求貨求車サーバ１１０のＲＡＭ２２に記憶される。
【００９１】
一方、ステップＳ６３９で、求貨求車サーバ１１０は、荷主端末１２０から登録修正情報を受信する。その後、図４のステップＳ４２９に進み、登録修正情報を荷物情報としてＲＡＭ２２に記憶する。
【００９２】
尚、上記実施形態では、与信管理サーバ１００で、荷主の与信の可否を判定する構成としたが、与信管理サーバ１００より荷主の取引口座の残高や入金予定金額を求貨求車サーバ１１０が受信して、求貨求車サーバ１１０上で荷主の与信の可否を判定する構成であっても良い。
【００９３】
また、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図３乃至図５に示すフローチャートに対応したプログラム）を、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。
【００９４】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【００９５】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【００９６】
プログラムを供給するための記録媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【００９７】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【００９８】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００９９】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１００】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【０１０１】
【発明の効果】
以上説明したように、本発明によれば、信頼性があり、かつ容易にかつ安全にシステムを利用することができる求貨求車サーバ及びその制御方法、求貨求車システム、プログラムを提供できる。
【図面の簡単な説明】
【図１】本実施形態の求貨求車システムの構成を示す図である。
【図２】本実施形態の求貨求車システムを構成する各種端末、サーバそれぞれのハードウェア構成を示す図である。
【図３】本実施形態の求貨求車システムで実行される処理を示すフローチャートである。
【図４】本実施形態の求貨求車システムで実行される処理を示すフローチャートである。
【図５】本実施形態の求貨求車システムで実行される処理の応用例を示すフローチャートである。
【図６】本実施形態の求貨求車システムの操作画面の一例を示す図である。
【図７】本実施形態の求貨求車システムの操作画面の一例を示す図である。
【図８】本実施形態の求貨求車システムの操作画面の一例を示す図である。
【図９】本実施形態の求貨求車システムの操作画面の一例を示す図である。
【符号の説明】
１００ 与信管理サーバ
１０５ 与信テーブル
１０６ 取引明細管理テーブル
１１０ 求貨求車サーバ
１１５ 空車テーブル
１１６ 荷物テーブル
１１７ 会員テーブル
１１８ 契約テーブル
１２０ 荷主端末
１３０ 車主端末
１７０ 通信回線
【発明の属する技術分野】
本発明は、荷主が使用する荷主端末及び車主が使用する車主端末とを通信回線を介して接続し、前記荷主と前記車主間の配送依頼を支援する求貨求車サーバ及びその制御方法、求貨求車システム、プログラムに関するものである。
【０００２】
【従来の技術】
従来の求貨求車システムでは、荷主の荷物情報の登録時点でその荷物の搬送を行う運送会社が決まっている場合、荷物情報中にその運送会社も指定する。これにより、この荷物は、指定の運送会社にのみ公開され、その後、運送会社（車主）が自身の搬送可能な運送車の空車情報の登録を行ない、求貨求車システムを運営する幹事会社がその荷物情報と空車情報とのマッチング処理を行うことによって、荷主と車主間の契約が成立する。
【０００３】
このような求貨求車システムには、第三者の金融機関が審査する与信決済機能を付加させたシステムは無く、幹事会社が自社で持つ与信枠にて運賃の決済を行っているのが現状である。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来の求貨求車システムでは、以下のような課題があった。
【０００５】
（イ）幹事会社の独自の与信による運賃決済
幹事会社が荷主から荷物を受注し受託運賃を決済する場合、通常は今までの取引慣習を鑑み、独自の与信枠と信頼関係に基づいて幹事会社の責任において決済を行っていた。信用取引が成立している間は問題は無いが、荷主からの支払いが滞ることで、幹事会社は自社の責任においてキャッシュフローを調整し、傭車に対して運賃を支払っていたのが現状である。また、荷主によって様々な支払いサイトを求貨求車システム上で提供し、幹事会社のキャッシュフロー調整能力によって吸収し決済を行っていた。
（ロ）荷主（債務者）のリアルタイムな信用状況の把握
現状は、月単位などで荷主（債務者）の与信状況を確認しており、たとえ与信枠を超えた決済が行われていようとしても、リアルタイムで荷主の輸送依頼に与信枠オーバーの事由から幹事会社が受託拒否を行うことが不可能とされていた。
【０００６】
本発明は上記の課題を解決するためになされたものであり、信頼性があり、かつ容易にかつ安全にシステムを利用することができる求貨求車サーバ及びその制御方法、求貨求車システム、プログラムを提供することを目的とする。
【００１２】
上記の目的を達成するための本発明による求貨求車サーバは以下の構成を備える。即ち、
荷主が使用する荷主端末及び与信管理サーバと通信可能な求貨求車サーバであって、
前記荷主端末から受信したログイン時の荷主の会員番号及びパスワードにより前記荷主を特定する認証処理を行い、前記認証処理に引き続き前記与信管理サーバに前記会員番号で特定された前記荷主の与信を照会するための一次与信照会情報を送信する一次与信照会手段と、
前記一次与信枠照会情報に応じて、前記与信管理サーバの与信情報記憶手段から読み出された与信枠と、前記与信枠照会情報に応じて、少なくとも荷主の会員番号と取引口座の残高金額と入出金予定金額を含む取引明細情報を記憶する取引明細情報記憶手段から読み出された取引口座の残高金額と入出金予定金額と、を含む一次与信情報を受信する一次与信情報受信手段と、
前記ログイン時点にて、前記与信枠と前記取引口座の残高金額との差が所定値以上であるか否かにより前記荷主端末の荷主の一次与信判定を行なう一次与信判定手段と、
前記一次与信判定結果が与信可の場合に、荷物登録画面情報を前記荷主端末に送信し、前記一次与信判定結果が与信不可の場合に、一次与信が不可のためログインできないことを示す画面情報を前記荷主端末に送信する画面情報送信手段と、
前記荷物登録画面情報に応じて前記荷主端末で入力された希望運賃額を含む荷物情報を受信する荷物情報受信手段と、
前記荷主の会員番号を用いて前記与信サーバから該荷主の該取引口座の残高金額に前記入金予定金額を取得するための二次与信照会情報を前記与信管理サーバに送信する二次与信照会情報送信手段と、
前記二次与信照会情報に応じて前記与信管理サーバで読み出された前記荷主の取引口座の残高金額と前記入金予定金額を含む二次与信情報を受信する二次与信情報受信手段と、
前記荷物情報の受信に応じて、前記希望運賃額が前記取引口座の残高金額を超えると判定した場合には、該取引口座の残高金額に前記入金予定金額を加算して、前記荷主の二次与信の可否を判定する二次与信判定手段と
を備える。
【００１３】
上記の目的を達成するための本発明によるプログラムは以下の構成を備える。即ち、
荷主が使用する荷主端末及び与信管理サーバと通信可能な求貨求車サーバの制御をコンピュータに実行させるためのプログラムであって、
前記求貨求車サーバを、
前記荷主端末から受信したログイン時の荷主の会員番号及びパスワードにより前記荷主を特定する認証処理を行い、前記認証処理に引き続き前記与信管理サーバに前記会員番号で特定された前記荷主の与信を照会するための一次与信照会情報を送信する一次与信照会手段と、
前記一次与信枠照会情報に応じて、前記与信管理サーバの与信情報記憶手段から読み出された与信枠と、前記与信枠照会情報に応じて、少なくとも荷主の会員番号と取引口座の残高金額と入出金予定金額を含む取引明細情報を記憶する取引明細情報記憶手段から読み出された取引口座の残高金額と入出金予定金額と、を含む一次与信情報を受信する一次与信情報受信手段と、
前記ログイン時点にて、前記与信枠と前記取引口座の残高金額との差が所定値以上であるか否かにより前記荷主端末の荷主の一次与信判定を行なう一次与信判定手段と、
前記一次与信判定結果が与信可の場合に、荷物登録画面情報を前記荷主端末に送信し、前記一次与信判定結果が与信不可の場合に、一次与信が不可のためログインできないことを示す画面情報を前記荷主端末に送信する画面情報送信手段と、
前記荷物登録画面情報に応じて前記荷主端末で入力された希望運賃額を含む荷物情報を受信する荷物情報受信手段と、
前記荷主の会員番号を用いて前記与信サーバから該荷主の該取引口座の残高金額に前記入金予定金額を取得するための二次与信照会情報を前記与信管理サーバに送信する二次与信照会情報送信手段と、
前記二次与信照会情報に応じて前記与信管理サーバで読み出された前記荷主の取引口座の残高金額と前記入金予定金額を含む二次与信情報を受信する二次与信情報受信手段と、
前記荷物情報の受信に応じて、前記希望運賃額が前記取引口座の残高金額を超えると判定した場合には、該取引口座の残高金額に前記入金予定金額を加算して、前記荷主の二次与信の可否を判定する二次与信判定手段として機能させるためのプログラム。
【００１４】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００１５】
本発明の求貨求車システムは、従来の求貨求車システムの概念に以下の機能を追加している。
【００１６】
● 第三者金融機関の提供するe-Marketplace向け与信決済機能
● 第三者金融機関の提供するe-Marketplace向け代行決済機能
● 求貨求車サイトへのログイン時の自動与信認証
● 荷主の荷物登録時のリアルタイム与信シミュレーション
● 荷主の荷物登録時の残高不足による登録不可の際の、残高報告及び取引再開時期の告知機能
＜概要＞
現在までの求貨求車システムにおいては、原則決済機能は幹事会社の持つ勘定系のシステムが司っており、幹事会社のキャッシュフロー及び資金調整力に大きく依存していたと言える。おのずと荷主から受託する運賃と、車主に支払う運賃との支払サイトに時間、種類（手形、小切手、現金等）にずれが生じる際は、幹事会社はそれなりにリスクを受ける可能性が出てくる。
【００１７】
そういったリスクを分散、回避し、健全な荷物と車の取引を行い、且つ契約に基づく幹事会社の健全なキャッシュフロー体制を構築していくことで、契約と金融の２つの流れが幹事会社の管理化におかれ、より健全で取引高の高いマーケットを構成することが可能となる。具体的には次の２点が大きい発明となる。
【００１８】
▲１▼ ログイン時認証
荷主会員が幹事会社に運送委託（発注）を行う際、求貨求車システムが提供する求貨求車サイトにログインし荷物を登録することとなる。その際、会員番号とパスワードを入力し、ログインをすることになるが、ログインと同時にその会員の番号とパスワードが自動的に与信決済シミュレーション機能を有する与信管理サーバへと接続し、リアルタイムなデータでログインを認証するか否かを求貨求車サーバが判断する。ログイン時点にて、あらかじめ金融機関が設定する荷主会員の与信枠が不足している場合は、求貨求車サイトへのログインが拒否される。この機能により、求貨求車サイトにアクセスする会員は全てリアルタイムで与信上信頼のおける会員のみということになり、その後の取引も当然ながら健全な取引が行われることになる。
【００１９】
▲２▼ 荷物登録時認証
ログインが許可された荷主会員であっても残高次第では、荷物の登録時の希望運賃に満たず、決済時になってからトラブルを起こす可能性も出てくる。そういった仕組みでは、リアルタイムでの与信決済機能とは言えない。そこで、本発明では、荷主が荷物を登録する際にも与信決済シミュレーション機能が働き、荷主が登録する希望運賃と、その会員の現時点での与信残高の差を求貨求車サーバが判断し、荷物登録の可否を判断し画面で告知する。その際、残高不足の金額と取引再開時期の案内を同画面にて会員に案内を行う。
【００２０】
次に、上述した本発明を実現する実施形態の求貨求車システムの構成について、図１を用いて説明する。
【００２１】
図１は本実施形態の求貨求車システムの構成を示す図である。
【００２２】
本実施形態の求貨求車システムは、荷主の荷主端末１２０、車主の車主端末１３０、求貨求車システムを実現する幹事会社が運営管理する求貨求車サーバ１１０、金融期間が運営管理する与信管理サーバ１００間を通信回線１７０を介して相互に接続して求貨求車システムを構築する。特に、この求貨求車システムでは、第三者金融機関が提供する与信決済機能を実現する与信管理サーバ１００を構成することで、荷主、車主といったサプライヤー及びバイヤーを広く集めてマーケットを活性化させ、かつ代行与信決済による信用取引の実現から、信頼のおけるマーケットを形成することができる。
【００２３】
幹事会社は、ＷＥＢサーバ機能を含む求貨求車サーバ１１０を有し、通信回線１７０を介して、荷主端末１２０、車主端末１３０から送信されてくる各種情報を登録し、管理する。また、求貨求車サーバ１１０には、各種情報を管理するためのテーブルとして、空車テーブル１１５、荷物テーブル１１６、会員テーブル１１７、契約テーブル１１８を有している。これらの各テーブルの構成の詳細については、後述する。
【００２４】
尚、求貨求車サーバ１１０は、幹事会社の管理下でなくても良く、例えば、ＩＳＰ、ＡＳＰ等の他のベンダーの管理下であっても良い。
【００２５】
金融機関は、ＷＥＢサーバ機能を含む与信管理サーバ１００を有し、通信回線１７０を介して、求貨求車サーバ１１０から送信されてくる荷主の会員情報に基づいて、その荷主の与信決済を行う。また、与信管理サーバ１００には、各種情報を管理するためのテーブルとして、与信テーブル１０５及び取引明細管理テーブル１０６を有している。これらの各テーブルの構成の詳細については、後述する。
【００２６】
尚、図１の各テーブルは別々に構成されているが、１つの記憶媒体上の異なる記憶領域にそれぞれのテーブルが構成されていても、もちろん構わない。
【００２７】
荷主は、通信回線１７０を介して求貨求車サーバ１１０に接続する荷主端末１２０を有し、少なくともＷＥＢブラウザ機能を有する。荷主端末１２０では、配送依頼対象の荷物の荷物情報を入力して求貨求車サーバ１１０へ送信し、その荷物情報に対応する空車情報がある場合には、その荷主と車主間での契約成立に関する情報を受信する。
【００２８】
車主は、通信回線１７０を介して求貨求車サーバ１１０に接続する車主端末１３０を有し、少なくともＷＥＢブラウザ機能を有する。この車主端末１３０は、運送可能な運送車の空車情報を入力して求貨求車サーバ１１０へ送信し、その空車情報に対応する荷物情報がある場合には、その車主と荷主間での契約成立に関する情報を受信する。
【００２９】
１７０は通信回線であり、典型的にはインターネットであるが、ＬＡＮ／ＷＡＮや電話回線、専用デジタル回線、ＡＴＭ（非同期転送モード）やフレームリレー回線でも良い。そして、この通信回線１７０によって、荷主端末１２０、車主端末１３０、求貨求車サーバ１１０、与信管理サーバ１００が相互に接続される。
【００３０】
次に、上述の求貨求車サーバ１１０に構築されている各テーブルについて説明する。
【００３１】
求貨求車サーバ１１０のハードディスク２８（図２）には、車主の空車情報を管理する空車テーブル１１５、荷主の荷物情報を管理する荷物テーブル１１６、本求貨求車サーバ１１０を利用する会員（荷主／車主）の会員情報を管理する会員テーブル１１７、荷主と車主間の契約の契約情報を管理する契約テーブル１１８がそれぞれ構築されている。
【００３２】
空車テーブル１１５は、空車情報として、例えば、空車会員番号、空車番号、契約番号、空車地、希望行き先、空車日、戻り日、車種（幌付き／パネル、保冷／保温設備有無、パワーゲート有無）、積載量、登録金額、積地、降地を有する。
【００３３】
荷物テーブル１１６は、荷物情報として、例えば、荷物会員番号、荷物番号、契約番号、商品名、積地、降地、積日、降日、重量、積込条件、荷降条件、指定車種、登録金額を有する。
【００３４】
会員テーブル１１７は、会員情報として、例えば、会社名、住所、連絡先、会員番号（番号）、パスワードを有する。
【００３５】
会員属性とは、求貨求車システムの会員、つまり、荷主会員、車主会員、その両方の会員を示すフラグが存在する。
【００３６】
契約テーブル１１８は、契約情報として、例えば、配送契約が成立した荷主の荷物会員番号と車主の空車会員番号、その配送契約を示す固有の契約番号を有する。
【００３７】
求貨求車サーバ１１０は、荷物テーブル１１６及び空車テーブル１１５それぞれに登録されている荷物情報及び空車情報とのマッチング処理を実行し、マッチングする荷物情報及び空車情報があると、この荷物情報の荷主及び空車情報の車主間での配送契約を成立させる。そして、この配送契約に関する契約情報を作成し、この契約情報、荷物情報、空車情報の３つの情報を対応づけて契約テーブル１１８に記憶する。
【００３８】
次に、上述の与信管理サーバ１００に構築されている各テーブルについて説明する。
【００３９】
与信管理サーバ１００のハードディスク２８には、荷主の与信状況を管理する与信テーブル１０５、各荷主の取引明細を管理する取引明細管理テーブル１０６が構築されている。
【００４０】
与信テーブル１０５は、与信情報として、例えば、荷主の会員番号、荷主の与信枠（与信限度額）、一次与信フラグ及び二次与信フラグを有する。
【００４１】
この一次与信フラグ及び二次与信フラグはそれぞれ、後述する一次与信及び二次与信それぞれの可否を示すフラグであり、可である場合には「ＯＮ」が、否である場合には「ＯＦＦ」がそれぞれ設定される。
【００４２】
取引明細管理テーブル１０６は、取引明細情報として、荷主の会員番号、荷主の取引口座の残高金額、入出金額、入出金日、入出金予定金額、入出金予定日を有する。
【００４３】
次に、本実施形態の求貨求車システムを構成する各種端末、サーバのハードウェア構成について、図２を用いて説明する。
【００４４】
図２は本実施形態の求貨求車システムを構成する各種端末、サーバそれぞれのハードウェア構成を示す図である。
【００４５】
図２において、ＣＰＵ２１、ＲＡＭ２２、ＲＯＭ２３、ＬＡＮアダプタ２４、ビデオアダプタ２５、入力部（キーボード）２６、入力部（マウス）２７、ハードディスク２８、ＣＤ−ＲＯＭドライブ２９はそれぞれシステムバス２０を介して互いに接続されている。システムバス２０は、例えば、ＰＣＩバス、ＡＧＰバス、メモリバス等を意味する。また、図２では、各バス間の接続用チップやキーボードインタフェースや、いわゆるＳＣＳＩやＡＴＡＰＩのような入出力用インタフェースは省略されている。
【００４６】
ＣＰＵ２１は四則演算や比較演算等の各種の演算や、ハードウェアやソフトウェアの制御を行う。ＲＡＭ２２には、ハードディスク２８やＣＤ−ＲＯＭドライブ２９に装着されたＣＤ−ＲＯＭやＣＤ−Ｒ等の記憶媒体から読み出されたオペレーションシステムのプログラムやアプリケーションプログラム（後述する各端末やサーバで実行されるフローチャートを実行する各プログラム）等が記憶され、これらはＣＰＵ２１の制御の元に実行される。
【００４７】
ＲＯＭ２３は、オペレーションシステムと協働してハードディスク等への入出力を司るいわゆるＢＩＯＳ等が記憶される。ＬＡＮアダプタ２４は、ＣＰＵ２１によって制御されるオペレーションシステムの通信プログラムと協働してネットワークを介した外部との通信を行う。ビデオアダプタ２５は、ディスプレイ装置（不図示）に出力する画像信号を生成し、入力部（キーボード）２６や入力部（マウス）２７は端末への指示を入力するために用いられる。
【００４８】
ハードディスク２８は、オペレーションシステムや上述のアプリケーションプログラムを記憶しており、端末の起動時に、または必要に応じてＲＡＭ２２にロードされる。
【００４９】
ＣＤ−ＲＯＭドライブ２９は、ＣＤ−ＲＯＭやＣＤ−ＲやＣＤ−Ｒ／Ｗ等の記憶媒体を装着してアプリケーションプログラムをハードディスク２８にインストールするのに用いる。
【００５０】
尚、ＣＤ−ＲＯＭドライブ２９の代わりにＣＤ−ＲドライブやＣＤ−Ｒ／ＷドライブやＭＯドライブ等を用いても良いのは言うまでもない。
【００５１】
次に、本実施形態の求貨求車システムで実行される処理について説明する。
【００５２】
図３及び図４は本実施形態の求貨求車システムで実行される処理を示すフローチャートである。
【００５３】
尚、本実施形態の求貨求車システムは、求貨求車サーバ１１０によって実現される求貨求車システムＷＥＢサイトに対し、荷主及び車主、幹事会社の各オペレータが自身の端末を用いてそのサイトにアクセスし、ＷＥＢブラウザを介して各種処理を行う。
【００５４】
まず、ステップＳ４０１で、荷主は、荷主端末１２０を用いて、求貨求車サーバ１１０へのアクセス要求を行い、求貨求車システムログイン画面（図６）を表示する。ステップＳ４０２で、その求貨求車システムログイン画面を用いて、会員番号及びパスワードからなるユーザ情報を入力する。この入力されたユーザ情報は求貨求車サーバ１１０へ送信される。
【００５５】
尚、図６の求貨求車システムログイン画面７０００は、例えば、会員番号及びパスワードを入力する各種入力領域７０１及び７０２を有している。７０３は接続ボタンであり、入力領域７０１及び７０２の内容を確定する場合に押下する。接続ボタン７０３が押下されると、入力領域７０１及び７０２の内容がユーザ情報として求貨求車サーバ１１０へ送信される
一方、ステップＳ４２１で、求貨求車サーバ１１０は、荷主端末１２０からユーザ情報を受信する。ステップＳ４２２で、会員テーブル１１７を参照して、受信したユーザ情報中の会員番号に対応する会員（荷主）を特定する。そして、その特定した会員の与信を照会するための一次与信照会情報を生成して、与信管理サーバ１００へ送信する。
【００５６】
尚、この一次与信照会情報は、ユーザ情報中の会員番号から構成される。
【００５７】
一方、ステップＳ４４１で、与信管理サーバ１００は、求貨求車サーバ１１０から一次与信照会情報を受信する。次に、ステップＳ４４２で、一次与信照会情報に基づいて、与信テーブル１０５及び取引明細管理テーブル１０６を参照して、照会対象の会員の一次与信判定を行う。
【００５８】
この一次与信判定は、受信した一次与信照会情報中の会員番号に対応する与信情報を与信テーブル１０５から取得し、また、取引明細管理テーブル１０６から取引明細情報を取得する。次に、与信情報中の与信枠と取引明細情報中の荷主の取引口座の残高金額との差が所定値以上であるかを判定する。そして、差が所定値未満である場合には一次与信フラグを「ＯＮ」、差が所定値以上である場合には一次与信フラグを「ＯＦＦ」に設定する。
【００５９】
尚、この所定値は、与信管理サーバ１００の管理者によって適宜設定可能であり、荷主の取引実績や入出金予定金額等の情報に基づいて、荷主毎に個別の所定値を設定することも可能である。また、与信枠に関係なく、単に荷主の取引口座の残高金額に基づいて、与信フラグを設定するようにしても良い。
【００６０】
そして、ステップＳ４４３で、一次与信判定結果（一次与信フラグ）を求貨求車サーバ１１０へ送信する。
【００６１】
一方、ステップＳ４２４で、求貨求車サーバ１１０は、与信管理サーバ１００から一次与信判定結果を受信する。ステップＳ４２５で、一次与信判定結果に基づいて、一次与信の可否を判定する。一次与信が否である（一次与信フラグがＯＦＦである）場合（ステップＳ４２５でＮＯ）、ステップＳ４２６に進み、一次与信不可通知を生成して、荷主端末１２０へ送信する。その後、ステップＳ４０３で、荷主端末１２０は、一次与信不可通知を受信する。
【００６２】
尚、この一次与信不可通知は、例えば、図６の求貨求車システムログイン画面７０００上に対し、例えば、図７に示すように、一次与信が不可である旨を示す内容を領域７０４で表示することで実現する。
【００６３】
一方、一次与信が可である（一次与信フラグがＯＮである）場合（ステップＳ４２５でＹＥＳ）、ステップＳ４２７に進み、求貨求車サーバ１１０は、荷物登録画面情報を生成する。ステップＳ４２８で、生成した荷物登録画面情報を荷主端末１２０へ送信する。
【００６４】
ステップＳ４０４で、荷主端末１２０は、求貨求車サーバ１１０から荷物登録画面情報を受信して、その荷物登録画面情報に基づく荷物登録画面（図８）を表示する。そして、この荷物登録画面を用いて、配送依頼対象の荷物の荷物情報を入力する。この入力された荷物情報は求貨求車サーバ１１０へ送信され、一旦、求貨求車サーバ１１０のＲＡＭ２２に記憶される。
【００６５】
尚、図８の荷物登録画面は、例えば、商品名、物量、希望運賃、積日、降日を入力する各種入力領域８００１〜８００５を有している。また、８００６は登録ボタンであり、各種入力領域の内容を確定する場合に押下する。そして、登録ボタン８００６が押下されると、各種入力領域の内容が荷物情報として求貨求車サーバ１１０へ送信される。また、８００７は削除ボタンであり、各種入力領域の内容を取り消す場合に押下する。
【００６６】
ステップＳ４２９で、求貨求車サーバ１１０は、荷主端末１２０から荷物情報を受信し、一旦ＲＡＭ２２に記憶する。ステップＳ４３１で、会員テーブル１１７を参照して、受信した荷物情報中の会員番号に対応する会員（荷主）を特定する。そして、その特定した会員の与信を照会するための二次与信照会情報を生成して、与信管理サーバ１００へ送信する。
【００６７】
尚、この二次与信照会情報は、既に受信したユーザ情報中の会員番号及び荷物情報中の希望運賃から構成される。
【００６８】
一方、ステップＳ４４４で、与信管理サーバ１００は、求貨求車サーバ１１０から二次与信照会情報を受信する。次に、ステップＳ４４５で、二次与信照会情報に基づいて、与信テーブル１０５及び取引明細管理テーブル１０６を参照して、照会対象の会員の二次与信判定を行う。
【００６９】
この二次与信判定は、単純に行う場合には、二次与信照会情報中の会員番号に対応する取引明細情報を取引明細管理テーブル１０６から取得して、その取引明細情報中の荷主の取引口座の残高金額と、二次与信照会情報中の希望運賃を比較する。比較の結果、希望運賃が残高金額未満である場合には二次与信フラグを「ＯＮ」、希望運賃が残高金額以上である場合には二次与信フラグを「ＯＦＦ」に設定する。
【００７０】
より厳密に行う場合には、更に、受信した二次与信照会情報中の会員番号に対応する与信情報を与信テーブル１０５から取得し、その与信情報中の与信枠と、取引明細情報中の荷主の取引口座の残高金額と、二次与信照会情報中の希望運賃を比較する。比較の結果、希望運賃が与信枠以上である場合には二次与信フラグを「ＯＦＦ」、希望運賃が与信枠未満かつ残高金額以上である場合あるいは希望運賃が残高金額未満である場合には二次与信フラグを「ＯＮ」に設定する。
【００７１】
尚、上述の一次与信判定及び二次与信判定の方法は、一例であって、用途や目的等に応じて与信情報及び取引明細情報に基づく与信判定を行うことができる。例えば、荷主の取引口座への入金予定金額がわかっていて、その入金によって与信が可となるような場合には、与信フラグを「ＯＮ」に設定するような構成であっても良い。
【００７２】
ステップＳ４４６で、与信管理サーバ１００は、二次与信判定結果を求貨求車サーバ１１０へ送信する。
【００７３】
一方、ステップＳ４３２で、求貨求車サーバ１１０は、与信管理サーバ１００から二次与信判定結果を受信する。図４のステップＳ５３３で、二次与信判定結果に基づいて、二次与信の可否を判定する。二次与信が否である（二次与信フラグがＯＦＦである）場合（ステップＳ５３３でＮＯ）、ステップＳ５３４に進み、ＲＡＭに記憶した荷物情報を削除し、更に、二次与信不可通知を生成して、荷主端末１２０へ送信する。その後、ステップＳ５０６で、荷主端末１２０は、二次与信不可通知を受信する。
【００７４】
一方、二次与信が可である（二次与信フラグがＯＮである）場合（ステップＳ５３３でＹＥＳ）、ステップＳ５３５に進む。次に、ステップＳ５３５で、求貨求車サーバ１１０は、登録確認画面情報を生成する。ステップＳ５３６で、生成した登録確認画面情報を荷主端末１２０へ送信する。
【００７５】
ステップＳ５０７で、荷主端末１２０は、求貨求車サーバ１１０から登録確認画面情報を受信して、その登録確認画面情報に基づく登録確認画面を表示する。そして、その登録確認画面を用いて、配送依頼対象の荷物の荷物情報の登録の可否を示す登録確認情報を入力する。この入力された登録確認情報は求貨求車サーバ１１０へ送信される。
【００７６】
ステップＳ５３７で、求貨求車サーバ１１０は、荷主端末１２０から登録確認情報を受信する。次に、ステップＳ５３８で、受信した登録確認情報に基づいて、ＲＡＭ２２に記憶された荷物情報の登録の可否を判定する。登録が否である場合（ステップＳ５３８でＮＯ）、ステップＳ４２７に戻る。一方、登録が可である場合（ステップＳ５３８でＹＥＳ）、ステップＳ５３９に進み、ＲＡＭ２２に記憶された荷物情報を正式な荷物情報として荷物テーブル１１６に登録する。
【００７７】
以上説明したように、本実施形態によれば、荷主端末１２０を利用する荷主の与信の可否をログイン時及び荷物情報登録時にと２段階で判定し、その判定結果に基づいて荷物情報を求貨求車サーバ１１０の荷物テーブル１１６に正式に登録する。これにより、信頼のおける荷主からの荷物情報だけを登録することができ、より信頼性が向上した求貨求車システムを実現することができる。
【００７８】
つまり、現行の求貨求車システムと、第三者金融機関が提供する与信決済機能が連携することで、幹事会社が荷主から輸配送依頼を受注する際、タイミング良く与信情報を取得することで、より確実性の高い、信用取引が成立することになる。また、信頼のおける第三者金融機関が与信を設定することで、幹事会社の債権上のリスク負担を軽減させることになり、さらには第三者金融機関が幹事会社に代わって代行決済を行うことで、幹事会社のキャッシュフローが安定し、運賃支払い先である、運送会社の経営安定化にも繋がる。
【００７９】
また、現行の求貨求車システム上では、バッチでの与信情報のため、リアルタイムでの与信情報がマーケットプレイスでの決済には反映されず、結果としてリスク波動の吸収を幹事会社の責任において行っていた。これに対し、本発明の求貨求車システムでは、リアルタイムで与信枠を超えている荷主は求貨求車システムＷＥＢサイトへログインを試みる段階ですでに、同サイトへの受け付けが拒否され、荷物の登録さえ不可能な状態となる。また、本実施形態のようなe-Marketplaceという信頼条件に裏付けされる取引においては、信用力の低下した荷主は与信が正常に復帰できるまでは、求貨求車システムを利用できないこととするのが、外部から求貨求車システムを見た際に、非常に信頼のおける求貨求車システムであることを認知させることができる。
【００８０】
尚、上記実施形態では、二次与信が否である場合には、荷物情報の登録を拒否する構成としているが、荷主端末１０２を利用する荷主の与信状況は、日々変化するものである。特に、荷主の取引口座への小額の入金によって与信が可となるような場合には、その旨を荷主へ伝えて、荷物情報の内容の修正を行う機会を与えたり、荷主への入金を促すようなことが可能である。
【００８１】
以下、本実施形態の応用例について、図５を用いて説明する。
【００８２】
図５は本実施形態の求貨求車システムで実行される処理の応用例を示すフローチャートである。
【００８３】
尚、図５のフローチャートは、図３のステップＳ４３２以降で実行される処理を示すものである。
【００８４】
ステップＳ４３２で、求貨求車サーバ１１０は、与信管理サーバ１００から二次与信判定結果を受信する。ステップＳ６３３で、二次与信判定結果に基づいて、二次与信の可否を判定する。二次与信が可である（二次与信フラグがＯＮである）場合（ステップＳ６３３でＹＥＳ）、図４のステップＳ５３６に進み、上述の処理を実行する。一方、二次与信が否である（二次与信フラグがＯＦＦである）場合、ステップＳ６３４に進み、荷主の与信枠に関する与信枠通知情報を生成して、荷主端末１２０へ送信する。
【００８５】
その後、ステップＳ６０６で、荷主端末１２０は、与信枠通知を受信して、与信枠を表示する。
【００８６】
尚、この与信枠通知情報は、例えば、図８の荷物登録画面８０００に対し、例えば、図９に示すように、与信枠の内容を領域８００６で表示することで実現する。荷主は、この領域８００６の内容に応じて、登録内容を変更するか、あるいは登録対象の荷物情報を削除するかの判断を行うことになる。登録対象の荷物情報の変更を依頼する場合には、変更ボタン８００９を押下する。また、登録対象の荷物情報の削除を依頼する場合には、削除ボタン８００７を押下する。
【００８７】
この変更ボタン８００９／削除ボタン８００７の押下によって、ステップＳ６０７で、荷主端末１２０は変更情報／削除情報を生成し、求貨求車サーバ１１０へ送信する。
【００８８】
一方、ステップＳ６３５で、求貨求車サーバ１１０は、変更情報／削除情報のどちらを受信したかを判定する。削除情報を受信した場合（ステップＳ６３５でＹＥＳ）、ステップＳ６３６に進み、ＲＡＭ２２に記憶された荷物情報を削除して、処理を終了する。
【００８９】
一方、変更情報を受信した場合（ステップＳ６３５でＮＯ）、ステップＳ６３７に進む。ステップＳ６３７で、ＲＡＭ２２に記憶された荷物情報の内容を荷物登録画面情報に反映した登録修正画面情報を生成する。ステップＳ６３８で、登録修正画面情報を荷主端末１２０へ送信する。
【００９０】
ステップＳ６０８で、荷主端末１２０は、求貨求車サーバ１１０から登録修正画面情報を受信して、その登録修正画面情報に基づく登録修正画面を表示する。そして、この登録修正画面を用いて、配送依頼対象の荷物の荷物情報を修正した登録修正情報を入力する。この入力された登録修正情報は求貨求車サーバ１１０へ送信され、一旦、求貨求車サーバ１１０のＲＡＭ２２に記憶される。
【００９１】
一方、ステップＳ６３９で、求貨求車サーバ１１０は、荷主端末１２０から登録修正情報を受信する。その後、図４のステップＳ４２９に進み、登録修正情報を荷物情報としてＲＡＭ２２に記憶する。
【００９２】
尚、上記実施形態では、与信管理サーバ１００で、荷主の与信の可否を判定する構成としたが、与信管理サーバ１００より荷主の取引口座の残高や入金予定金額を求貨求車サーバ１１０が受信して、求貨求車サーバ１１０上で荷主の与信の可否を判定する構成であっても良い。
【００９３】
また、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図３乃至図５に示すフローチャートに対応したプログラム）を、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。
【００９４】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【００９５】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【００９６】
プログラムを供給するための記録媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【００９７】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【００９８】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００９９】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１００】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【０１０１】
【発明の効果】
以上説明したように、本発明によれば、信頼性があり、かつ容易にかつ安全にシステムを利用することができる求貨求車サーバ及びその制御方法、求貨求車システム、プログラムを提供できる。
【図面の簡単な説明】
【図１】本実施形態の求貨求車システムの構成を示す図である。
【図２】本実施形態の求貨求車システムを構成する各種端末、サーバそれぞれのハードウェア構成を示す図である。
【図３】本実施形態の求貨求車システムで実行される処理を示すフローチャートである。
【図４】本実施形態の求貨求車システムで実行される処理を示すフローチャートである。
【図５】本実施形態の求貨求車システムで実行される処理の応用例を示すフローチャートである。
【図６】本実施形態の求貨求車システムの操作画面の一例を示す図である。
【図７】本実施形態の求貨求車システムの操作画面の一例を示す図である。
【図８】本実施形態の求貨求車システムの操作画面の一例を示す図である。
【図９】本実施形態の求貨求車システムの操作画面の一例を示す図である。
【符号の説明】
１００ 与信管理サーバ
１０５ 与信テーブル
１０６ 取引明細管理テーブル
１１０ 求貨求車サーバ
１１５ 空車テーブル
１１６ 荷物テーブル
１１７ 会員テーブル
１１８ 契約テーブル
１２０ 荷主端末
１３０ 車主端末
１７０ 通信回線
Claims (3)
- 荷主が使用する荷主端末及び与信管理サーバと通信可能な求貨求車サーバであって、
前記荷主端末から受信したログイン時の荷主の会員番号及びパスワードにより前記荷主を特定する認証処理を行い、前記認証処理に引き続き前記与信管理サーバに前記会員番号で特定された前記荷主の与信を照会するための一次与信照会情報を送信する一次与信照会手段と、
前記一次与信枠照会情報に応じて、前記与信管理サーバの与信情報記憶手段から読み出された与信枠と、前記与信枠照会情報に応じて、少なくとも荷主の会員番号と取引口座の残高金額と入出金予定金額を含む取引明細情報を記憶する取引明細情報記憶手段から読み出された取引口座の残高金額と入出金予定金額と、を含む一次与信情報を受信する一次与信情報受信手段と、
前記ログイン時点にて、前記与信枠と前記取引口座の残高金額との差が所定値以上であるか否かにより前記荷主端末の荷主の一次与信判定を行なう一次与信判定手段と、
前記一次与信判定結果が与信可の場合に、荷物登録画面情報を前記荷主端末に送信し、前記一次与信判定結果が与信不可の場合に、一次与信が不可のためログインできないことを示す画面情報を前記荷主端末に送信する画面情報送信手段と、
前記荷物登録画面情報に応じて前記荷主端末で入力された希望運賃額を含む荷物情報を受信する荷物情報受信手段と、
前記荷主の会員番号を用いて前記与信サーバから該荷主の該取引口座の残高金額に前記入金予定金額を取得するための二次与信照会情報を前記与信管理サーバに送信する二次与信照会情報送信手段と、
前記二次与信照会情報に応じて前記与信管理サーバで読み出された前記荷主の取引口座の残高金額と前記入金予定金額を含む二次与信情報を受信する二次与信情報受信手段と、
前記荷物情報の受信に応じて、前記希望運賃額が前記取引口座の残高金額を超えると判定した場合には、該取引口座の残高金額に前記入金予定金額を加算して、前記荷主の二次与信の可否を判定する二次与信判定手段と
を備えることを特徴とする求貨求車サーバ。 - 前記二次与信判定結果が可である場合、前記荷物情報の登録の可否を確認する登録確認画面情報を、該荷主端末に送信する登録確認画面情報送信手段と、
前記二次与信判定結果が否である場合、前記荷主端末の荷主の与信枠に関する与信枠通知情報を、該荷主端末へ送信する与信枠通知情報送信手段と、
前記与信枠通知情報に対して前記荷物情報の変更依頼を示す変更情報を受信した場合、
前記荷主端末において該荷物情報を修正するための登録修正画面情報を該荷主端末へ送信する登録修正画面情報送信手段と
を更に備えることを特徴とする請求項１に記載の求貨求車サーバ。 - 荷主が使用する荷主端末及び与信管理サーバと通信可能な求貨求車サーバの制御をコンピュータに実行させるためのプログラムであって、
前記求貨求車サーバを、
前記荷主端末から受信したログイン時の荷主の会員番号及びパスワードにより前記荷主を特定する認証処理を行い、前記認証処理に引き続き前記与信管理サーバに前記会員番号で特定された前記荷主の与信を照会するための一次与信照会情報を送信する一次与信照会手段と、
前記一次与信枠照会情報に応じて、前記与信管理サーバの与信情報記憶手段から読み出された与信枠と、前記与信枠照会情報に応じて、少なくとも荷主の会員番号と取引口座の残高金額と入出金予定金額を含む取引明細情報を記憶する取引明細情報記憶手段から読み出された取引口座の残高金額と入出金予定金額と、を含む一次与信情報を受信する一次与信情報受信手段と、
前記ログイン時点にて、前記与信枠と前記取引口座の残高金額との差が所定値以上であるか否かにより前記荷主端末の荷主の一次与信判定を行なう一次与信判定手段と、
前記一次与信判定結果が与信可の場合に、荷物登録画面情報を前記荷主端末に送信し、前記一次与信判定結果が与信不可の場合に、一次与信が不可のためログインできないことを示す画面情報を前記荷主端末に送信する画面情報送信手段と、
前記荷物登録画面情報に応じて前記荷主端末で入力された希望運賃額を含む荷物情報を受信する荷物情報受信手段と、
前記荷主の会員番号を用いて前記与信サーバから該荷主の該取引口座の残高金額に前記入金予定金額を取得するための二次与信照会情報を前記与信管理サーバに送信する二次与信照会情報送信手段と、
前記二次与信照会情報に応じて前記与信管理サーバで読み出された前記荷主の取引口座の残高金額と前記入金予定金額を含む二次与信情報を受信する二次与信情報受信手段と、
前記荷物情報の受信に応じて、前記希望運賃額が前記取引口座の残高金額を超えると判定した場合には、該取引口座の残高金額に前記入金予定金額を加算して、前記荷主の二次与信の可否を判定する二次与信判定手段として機能させるためのプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001401515A JP4479985B2 (ja) | 2001-12-28 | 2001-12-28 | 求貨求車サーバ及びそのプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001401515A JP4479985B2 (ja) | 2001-12-28 | 2001-12-28 | 求貨求車サーバ及びそのプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003196479A JP2003196479A (ja) | 2003-07-11 |
| JP4479985B2 true JP4479985B2 (ja) | 2010-06-09 |
Family
ID=27605434
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001401515A Expired - Fee Related JP4479985B2 (ja) | 2001-12-28 | 2001-12-28 | 求貨求車サーバ及びそのプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4479985B2 (ja) |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001195534A (ja) * | 2000-01-07 | 2001-07-19 | Sti:Kk | 輸送者決定システムおよびその方法 |
| JP2001256377A (ja) * | 2000-03-09 | 2001-09-21 | Digital Garage Inc | オークションプラットフォーム及びこれを用いた売買契約の執行方法、宅配業者プラットフォーム及びこれを用いた販売商品宅配方法 |
| JP2001344452A (ja) * | 2000-03-30 | 2001-12-14 | Nippon Digicom:Kk | 荷物運送仲介システム |
| JP3232295B1 (ja) * | 2000-04-25 | 2001-11-26 | 株式会社ファーストドリームトレイン | 特定企業情報提供収集システム |
| JP3407801B2 (ja) * | 2000-05-02 | 2003-05-19 | 康彦 三浦 | 売掛債権担保融資方法およびシステム |
| JP2001338029A (ja) * | 2000-05-25 | 2001-12-07 | Nec Corp | 郵便受付システム及び郵便受付方法 |
| JP2001351034A (ja) * | 2000-06-05 | 2001-12-21 | Card Commerce Service Kk | 携帯電話によるクレジットカード決済システム |
| JP2000331095A (ja) * | 2000-07-31 | 2000-11-30 | Sumitomo Credit Service Co Ltd | 決済システムにおける取引要求情報の振分サーバ、決済システムおよび決済方法 |
| JP2001188864A (ja) * | 2001-02-14 | 2001-07-10 | Esuka Corporation:Kk | 商品の発注管理システム |
-
2001
- 2001-12-28 JP JP2001401515A patent/JP4479985B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003196479A (ja) | 2003-07-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6507826B1 (en) | Remote electronic invoice entry and validation system and method therefor | |
| US6446048B1 (en) | Web-based entry of financial transaction information and subsequent download of such information | |
| US7693787B2 (en) | System and method for account reconciliation | |
| US7249069B2 (en) | International cash-on-delivery system and method | |
| US6873974B1 (en) | System and method for use of distributed electronic wallets | |
| JP4252159B2 (ja) | 小口経費処理システム，同システムを構成するクライアント・コンピュータおよび同コンピュータのためのプログラム記録媒体 | |
| JP2003524220A (ja) | 取引書類の作成、処理、及びトラッキングを含む取引活動を統合するためのシステム及び方法 | |
| EP1213678A1 (en) | Gift intermediating system and method therefor | |
| US8645225B1 (en) | Organic supplier enablement based on a business transaction | |
| US20020174070A1 (en) | Transaction system | |
| KR100360682B1 (ko) | 인터넷을 이용한 티켓 발행 시스템 및 그 제어방법 | |
| JP2001028025A (ja) | 決済管理システム、決済管理方法及び記録媒体 | |
| JP2005267618A (ja) | 電子商取引支援装置及びプログラム | |
| KR20020006868A (ko) | 인터넷을 기반으로 하는 수출통관 서비스 제공 방법 및시스템 | |
| US7788185B2 (en) | Electronic payment system, a recording medium recording an electronic payment program and an electronic payment apparatus | |
| JP4479985B2 (ja) | 求貨求車サーバ及びそのプログラム | |
| KR100798278B1 (ko) | 제3자에 의한 대행 결제 방법 및 그 시스템 | |
| JP2002352170A (ja) | 決済仲介システム及び決済仲介方法 | |
| US20020007344A1 (en) | Settlement apparatus, method, and program | |
| JP2002216039A (ja) | 決済管理システム、決済管理方法、決済管理プログラムを記録した記録媒体及び決済管理プログラム | |
| JP2003256739A (ja) | 一括精算・管理システム | |
| JP2002056069A (ja) | 貿易取引支援装置、方法及び記録媒体 | |
| JP2003115023A (ja) | 決済仲介システム及び決済仲介方法 | |
| AU2002242463B2 (en) | Electronic financial instrument | |
| WO2002075618A1 (en) | Data storage system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041220 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070524 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070528 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070727 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070921 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071120 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080118 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080319 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20080326 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20080425 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100311 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130326 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4479985 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130326 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140326 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |