JP2007526862A - 到着予定時刻（ｅｔａ）システムおよび方法 - Google Patents

Abstract

ネットワーク上のシステムが、そのネットワーク上のクライアントに対して、到着予定時刻情報を提供する。このシステムは、製品番号を含む製品照会を引き出すため、クライアントに対して、ウェブ・ページを提示する。また、このシステムは、製品番号を含む製品照会を受け付けると、その製品番号を持つ少なくとも１つの輸送中のユニットについて、様々な宛先への到着予定時刻を決定し、クライアントに対し、その到着予定時刻を送信する。

Description

本発明は、一般にコンピュータ・ソフトウェア・システムに関するものであり、より詳しくは、製品の到着予定時刻を決定するコンピュータ・システムに関するものである。

ディーラが購入注文を検討するとき、製品の入手可能性および運送費が重要な要素である。製品が在庫切れで入手できない場合は、ディーラは、別の製造業者の製品を注文することに決めるかもしれない。製品を入手できるとしても運送費が高すぎる場合は、ディーラはやはり、製品を別の業者に注文することに決める可能性がある。

製造業者は、ディーラへの運送費を下げるよう戦略的に配置された様々な保管倉庫を使用する。各ディーラはデフォルトの倉庫を割り当てられるが、２次的（代替）倉庫に注文する選択肢もある。しかし、デフォルト倉庫は通常、２次的倉庫よりディーラに近い場所にある。従って、２次的倉庫に注文するときは、ディーラはたいてい、より高い運送費を払うことを覚悟する。

時にはデフォルト倉庫が在庫切れで、ディーラは、２次的倉庫に注文するか、または恐らく他の製造業者が製造する別の製品を注文する以外に選択肢がないこともある。時間が最も重要な要素であり、且つ買い方が追加の運送費を払う気がない場合、製造業者は結局販売に失敗することになるだろう。どのような注文オプションが利用可能か見つけるために製造業者の販売代理人と話さなければならないのでは、ディーラもわずらわしくなる。さらに、ディーラが急ぎで、製品が２次的倉庫からだけしか入手できないという理由で、運送費が高いことを理解しないまま製品を注文すると、その後に紛争が起こる可能性がある。製品がどの倉庫から出荷されるか管理することなく、ディーラは追加の運送費にたいてい驚き不快になる。いずれにしても、製造業者の製品が常に在庫切れか、またはデフォルト倉庫から入手できない場合、顧客は、製造業者の注文サービスに不便を感じ、不満を抱くだろう。

早い時期に一般に行われたビジネスモデルでは、電話または電子メール通信のどちらかにより要求者に推定入手可能日を回答することを含んでいる。そのようなモデルでは、到着予定時刻の計算が、運送中のコンテナの日程および過去のデータを使い生成された到着時刻表の推定時刻を調べることにより、手作業で実施された。手作業により、どの倉庫が商品を供給できるか決定し運送費の差額を計算するのは、非常に効率が悪かった。ネットワーク化されたコンピュータ・システムが、この効率の悪さを改善し始めている。

データ交換システムは広く知られている。このシステムは、発注データなどの商取引に関するデータを交換する。周知のデータ交換システムの１つは、ディーラと納入業者との間で商用通信を転送するのに電子データ交換（ＥＤＩ）法を使用する。ＥＤＩシステムは、合意されたメッセージ標準を使用し、１つのコンピュータ・システムから別のコンピュータ・システムへ構造化方法でデータを転送する。異なるデータ交換フォーマットを持つ他の発注システムもまた、商用通信を行うのに使用できる。例えば、企業独自のネットワーク・アクセス・システムは、様々な特殊なインタフェースおよび交換方法を使用し、遠隔のディーラ（あるいはイントラネット・ユーザまたはエクストラネット・ユーザ）が注文システムにアクセスできるようにする。

特許文献１（米国特許６、６０９、１０８号）は、消費者が発注または購入する前に、製品の製造並びに配達プロセスすなわち「流通経路」について、入手可能性および設計された製品の状態に関する情報をリアルタイムに提供する、オンラインの方法とシステムを提供することを意図している。消費者への製品の配達期間は、計画および未計画の製造ライン、最終組み立て、構内在庫、輸送中在庫、およびディーラ在庫を含む製品流通経路の様々な段階で使用可能な製品を捜し出し、「タグをつける」ことにより短縮される。個別製品の特徴またはオプションに、価格設定および比較データがリアルタイムで提供される。

輸送中コンテナの位置データをリアルタイムに取得するため、追跡システムも、衛星や他の電子技術を使用するシステムを含み、十分に開発されている。非常に大きな倉庫の保管物をいつでも十分詳細に確定する棚卸資産会計および管理システムも、申し分なく開発されている。コンテナおよび在庫を監視する方法およびシステムは、特許文献２（米国特許６、１４８、２９１号）に開示されている。

フェデラル・エクスプレス(登録商標)などの運送会社は、発送人が正式に認めるとき、積み荷を別の経路に変更する能力がある。しかし、一般に特別の取扱手数料が、各経路変更された荷物に対して顧客に請求される。顧客は、積み荷が最終仕向け地に到着する前に、積み荷を止めることを決定してもよい。言い換えると、荷物を経路変更する代わりに、荷物を途中の特定の仕向け地に預ける。このためには、権限を持った人が、手元に適切な情報を持って運送会社に電話することが必要である。運送会社は、配達を促進するため（他の運送会社を使用することも含めて）、積み荷の進路を変更することもできる。

さらに、注文受付、処理、調達、物流、倉庫機能、製品追跡の管理は、コンピュータ化され統合されている。特許文献３（米国特許５、９８７、４２３号）は、受け付けた販売注文を追跡しそれを倉庫の在庫と照合する注文管理メカニズム、販売注文を処理する販売注文メカニズム、購買注文を処理する購買注文メカニズムを含むオブジェクト指向プログラミング（ＯＯＰ）フレームワークを開示している。その‘４２３号特許は、経理、倉庫管理、売買注文追跡などの基礎をなすビジネス機能を連結することを、さらに開示している。

米国特許６、６０９、１０８号 米国特許６、１４８、２９１号 米国特許５、９８７、４２３号

コンピュータ化され統合された注文処理システムの将来性にもかかわらず、そのような現在の商業ソフトウェアは、通常は能力が限られている。在庫費用は、企業にとって絶えず気にかかる分野である。在庫が多すぎると、企業の運転資金を使い果たし、資金繰りの問題を引起すだけでなく、それを管理するために追加の場所と人も必要とする。在庫が少なすぎるという反対の問題は、生産の遅延や顧客サービスの悪化を引起すことがある。今まで、現在の積み荷の状況または進路変更の選択肢などの常に変化する要因に基づき、到着予定時刻情報および運送費情報の少なくとも１つを動的に提供するシステムは、記述されていないし、利用することもできない。積み荷配達時間の遅れ、緊急要求、倉庫在庫、ベンダの状況、契約要件などの様々な要因に基づきコンテナの進路を変更する自動システムを含むシステムもない。さらに、現在のシステムは、情報に基づき経済的な注文決定をするため、ディーラが望んでいる情報も提供しない。

本発明の目的は、ディーラが製品の到着予定時刻をリアルタイムに得ることができる、効果的なシステムを提供することである。本発明の目的は、ディーラに代替倉庫の中から選択する能力と推定運送費情報を提供することでもある。本発明のもう１つの目的は、製品を最適配分できるようにするため、輸送中製品の進路を変更する能力を提供することである。さらにもう１つの本発明の目的は、製品輸送中に変わる可能性のある要因のため、積み荷の進路を変更する能力を提供することである。

本発明の１つの実施形態によれば、ネットワーク上のシステムが、そのネットワーク上に配置されるクライアントに到着予定時刻情報を提供する。本システムは、製品番号を含む製品照会を引き出すためのウェブ・ページをクライアントに表示するよう改造される。本システムは、製品照会を受け付け、製品番号を持つ少なくとも１つの輸送中のユニットに対し、様々な送付先に対する到着予定時刻を決定する。本システムは、クライアントに到着予定時刻を送信することもできる。

本発明の別の実施形態によれば、ネットワーク上のサーバに製造番号を含む製品照会情報を送信するよう改善されたシステムが提供される。システムは、その製造番号を持つ少なくとも１つの輸送中のユニットに対する、少なくとも１つの宛先への到着予定時刻を受信する。

本発明のまた別の実施形態では、少なくとも１つの２次的倉庫に注文する場合の追加費用を含む運送費情報を提供するシステムが提供される。システムは、製品番号を含む製品に関する照会を引き出すため、ネットワーク上のクライアントに改作された１ページまたは複数のページを提示し、製品照会を受け付けるよう改造される。システムは、対応する製品重量を製品重量表データベースから、ディーラの住所をディーラ所在地データベースから、およびディーラの住所に基づき少なくとも１つの運送費を運送費表データベースから受け取り、製品重量データベース、運送費データベース、およびディーラ所在地データベースに蓄えられた情報に基づき、少なくとも１つの運送費の差額を計算する。システムは、クライアントに少なくとも１つの輸送費の差額を送信もする。

本発明のさらに別の実施形態では、システムとサーバを結ぶネットワーク上に、サーバに製品番号および顧客識別名を含む製品照会情報を送信するよう改造されているシステムが提供される。システムは、製品照会に基づき、少なくとも１つの２次的倉庫への注文に対する少なくとも１つの運送費の差額を受信する。

本発明のさらに別の実施形態では、ネットワーク上のシステムは、製品番号を持つ複数の輸送中ユニットの１つを、複数の宛先の１つに自動的に進路変更する。システムは、複数の輸送中ユニットに関し複数の宛先のそれぞれに対する到着予定時刻を決定するよう改造される。システムは、複数の倉庫のそれぞれの販売履歴情報、宛先のそれぞれに対する最新の在庫情報および輸送中情報、バックオーダ・データを含む最新の在庫情報、複数の輸送中ユニットの位置を含む輸送中情報に基づき、進路変更計画を立てるようさらに改造される。進路変更計画に基づき、システムは１つのユニットを宛先の１つに進路変更する。

以下の説明で用いられる単語中、「ユーザ」、「オペレータ」、「顧客」、「消費者」、「ディーラ」、「ベンダ」等は、本発明から便宜を受けるあらゆる人を意味する。「製造業者」は、製品を製造し販売する人またはエンティティを意味する。「製品」は、この世に存在するあらゆる生産物を意味する。単語「品目」および「ユニット」は、製品番号を持つ１つの製品を識別するため使用される。

「コンピュータ」は、コンピュータ単体または複数のコンピュータと接続しているシステムを指すことがある。一般的に言えば、コンピュータは、ハードウェア・システム、ソフトウェア・オペレーティング・システム、および多分１つまたは複数のソフトウェア・アプリケーション・プログラムの組み合わせである。コンピュータの例には、ＤＯＳ、Ｗｉｎｄｏｗｓ（登録商標）、ＯＸ／２、またはＬｉｎｕｘなどのオペレーティング・システムで動作するＩＢＭタイプ・パーソナル・コンピュータ（ＰＣ）、マッキントッシュ・コンピュータ、ＪＡＶＡ（登録商標）−ＯＳオペレーティング・システムで動作するハードウェア、ＵＮＩＸ（登録商標）オペレーティング・システムで動作するサン・マイクロシステムズおよびシリコングラフィックス社のワークステーションなどのグラフィカル・ワークステーション、ＰａｌｍＰｉｌｏｔ、およびＰｉｌｏｔＰＣを含むが、これに限られない。

「ネットワーク」は、データの伝達を可能にする、２台以上のコンピュータ間の接続を意味する。ネットワークの１例はインターネットである。「クライント／サーバ」アーキテクチャは、ネットワーク上の各コンピュータまたはプロセスが「クライアント」または「サーバ」のどちらかであるネットワーク・アーキテクチャである。「サーバ」は、ネットワーク・リソースを管理し、ネットワーク上の第三者からの要求を受信し、その要求に応答することができるネットワーク上のコンピュータまたは装置である。要求はクライアントからサーバに送られる。クライアントは通常、パーソナル・コンピュータまたはワークステーション上で稼動し、オペレーションを実施するのにサーバを当てにしているアプリケーションである。

「ウェブ・ページ」は、ＨＴＭＬ（ハイパーテキスト・マークアップ言語）またはＶＲＭＬ（仮想現実モデリング言語）、ダイナミックＨＴＭＬ、ＸＭＬ（拡張可能マークアップ言語）、またはその関係するコンピュータ言語を含みそれに限られないマークアップ言語で書かれた文書、並びにワールド・ワイド・ウェブ（「ウェブ」）上の１つの特定のインターネット・アドレス若しくは１つの特定のサイトを通じて取得できる書類の集合、または特定のユーアールエル（ＵＲＬ）を通じて取得できる文書を意味する。「ウェブ・サイト」は、少なくとも１つのウェブ・ページ、なるべくなら論理的なグループを形成する仮想的に接続された複数のページを意味する。

「ウェブ・ブラウザ」は、ウェブ・サイト上のウェブ・ページから得たテキストまたはグラフィックあるいは両方を表示することができるコンピュータ上で動作するクライアント・ソフトウェア・プログラムを意味する。ウェブ・ブラウザの例には、Ｎｅｔｓｃａｐｅ ＮａｖｉｇａｔｏｒおよびＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒを含むがこれに限られない。

語句「ウェブ・ページの表示」は、コンピュータ・ユーザが入手できるウェブ・ページ上の情報の少なくとも１部を表現するのに必要なすべての行為を含む。従って、その語句は、静的なグラフィカル情報の静的な画像表示、オーディオ情報の音の再現、アニメーションの生き生きした画像表示、ビデオ・ストリーム・データの画像表示を含むがこれに限られない。「ウェブ・サーバ」は、少なくとも１つのウェブ・ページをウェブ・ブラウザに配信できるサーバである。

「デフォルト倉庫」は、ディーラが製品を受取る第一順位の倉庫として、ディーラに割り当てられた倉庫を意味する。「代替倉庫」は、ディーラに割り当てられていないが、ディーラが製品を受取るために選択できる２次的な供給源の倉庫を意味する。「配分する」は、特定の目的のため、または個別の人若しくは物に、割り当てることを意味する。「バックオーダ」は、注文された特定の品目が倉庫に一時的に在庫がないことを意味する。「コンテナ」は、商品を収容するものである。本明細書の中では、コンテナは、その中に当初詰め込まれた内容物の全部または一部を収容することができる。「物流」は、製造業者の製品の調達、維持、配分、輸送、配達を扱う事業のあらゆる面を意味する。「進路変更する」は、１つのコースから進路を変えるまたは別のコースを使用することを意味する。「進路変更」は、コース、活動、または使用を方向転換する行為または場合を意味する。「ＥＴＡ」は、到着予定時刻を意味する。

「手動操作」は、処理装置でなく手動により実施または実行されるステップを意味する。手動操作の１例は、処理装置が前以って蓄積したデータを保有するデータベースにアクセスするのとは対照的に、処理装置が使用するデータを入力することを含むが、それに限られない。

本発明のためのソフトウェア・アプリケーションは、実質上適切などのようなプログラミング言語で書くこともでき、当業者は容易にプログラミング言語を選ぶことができる。選ばれるプログラミング言語は、ソフトウェア・アプリケーションを実行するコンピュータと互換性があるべきであり、特にコンピュータのオペレーティング・システムと互換性があるべきである。適切なプログラミング言語の例には、Ｃ、Ｃ＋＋、ＣＧＩ、Ｊａｖａ（登録商標）、およびＪａｖａ（登録商標） Ｓｃｒｉｐｔを含むがこれに限られない。さらに、本発明の機能は、方法を一連のステップで記載するとき、データ処理装置が処理する一連のソフトウェア命令により実現することができる。従って、本発明はソフトウェア、ファームウェア、またはハードウェア、あるいはそれらの組み合わせとして実装可能である。

以下に記載するクライアント・コンピュータはそれぞれ、インターネットとの接続のため通信用ハードウェアおよびグラフィカル・ユーザ・インタフェース（ＧＵＩ）機能を持つオペレーティング・システムを備えているのが好ましい。各クライアント・コンピュータは、ウェブ上のハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバとの間で、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）フォームの読み出しまたは送信ができるように、コンピュータ上にロードされるＮｅｔｓｃａｐｅ ＮａｖｉｇａｔｏｒまたはＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒなどのグラフィカル・ウェブ・ブラウザ・ソフトウェアをインストールしてあるのが好ましい。クライアント・コンピュータは、ブラウザがサーバからダウンロードしたＪａｖａ（登録商標） ａｐｐｌｅｔなどを実行する仮想マシンの機能を果たすよう使用できるのが好ましい。サーバは、入力照会およびデータ源と連結するため、ハードウェア、ＨＴＴＰ準拠のソフトウェア、オペレーティング・システム、およびコモン・ゲートウェイ・インタフェース（ＣＧＩ）ソフトウェアを含むのが好ましい。すべてのクライアントとサーバ間の通信は、例えばインターネットなどのワイド・エリア・ネットワーク（すなわちＷＡＮ、不図示）を介するのが好ましい。

本発明を実装する基本的なシステム構成の１つを図１に示す。発注クライアント１は、ＥＴＡ顧客注文データベース２に商用データを伝達する。発注クライアント１は、異なるデータ交換方法を使用する様々な発注システム１ｃ、１ｄ、および１ｅから構成できる。ネットワークにアクセスするのに、顧客の１人は、例えば周知のＥＤＩデータ交換方法１ａを使用してもよく、別の顧客は独自のエクストラネット交換方法１ｂを使用してもよい。様々な発注システム１ｃ、１ｄ、および１ｅ（集合的に発注クライアント１）が、ＥＴＡ顧客注文データベース２およびシステムの残りの部分と適切に伝達できるようにするため、発注画面サーバ４は、種々の情報源からデータを受信し、ＥＴＡ顧客注文データベース２にフォーマット化されたデータを伝達する。

ＥＴＡ顧客注文データベース２は、データベース・サーバ上に保有され、リレーショナル・データベース管理システム（ＲＤＢＭＳ）を含むのが好ましいがそうでなくてもよい。ＲＤＢＭＳに蓄積された情報は、所定の機能により互いに関連した行と列からなる表に配列され、例えば構造化問合せ言語（ＳＱＬ）などのデータベース問合せプロトコルでアクセスできる。また、ＥＴＡ顧客注文データベース２は、実際は、例えばエクストラネット注文データベースまたはＥＤＩ注文データベースなどの、いくつかのデータベースのことがあり、そのおのおのは個別のデータベース・サーバ上で維持される。

ＥＴＡ顧客注文データベース２は、ＥＴＡ計算サーバ３に顧客注文を伝達する。ＥＴＡ計算サーバ３は、配分された製品積み荷および配分されていない製品積み荷の到着予定時刻情報を確定する。配分されていない製品の積み荷は、最終仕向け倉庫がまだ指定されていない製品を含む積み荷である。配分された製品積み荷は、特定の倉庫を指定されている。予約製品は、さらに顧客を指定されている配分された製品である。計算結果は、ＥＴＡ結果データベース５に伝達され、前述のようにさらにフォーマットにするため発注画面サーバ４に供給される。

輸送中情報源６は、輸送中の貨物および積み荷に関係するデータを収集し、ＥＴＡ配達注文データベース１０にこのデータを蓄える。輸入インボイス情報源６ａは、特定の積み荷に対する指定された最終仕向け倉庫の識別名を含む情報を送信する。輸送中倉庫転送情報源６ｂは、倉庫間を輸送中の積み荷の現在位置を含む情報を収集する。同様に、国内輸送情報源６ｃは、ディーラに輸送中の積み荷の情報を収集する。輸送中情報源６ａ、６ｂ、６ｃがＥＴＡ配達注文データベース１０にアップロードすることができる他の情報には、インボイス情報、宛先、船名、コンテナ情報、および（可能なら）到着予定時刻を含む。最新倉庫在庫情報システム９も、ＥＴＡ配達注文データベース１０にアップロードする。このデータは、積み荷のＥＴＡの計算に使用するためＥＴＡ計算サーバ３に伝達される。

倉庫在庫情報源９および輸送中情報源６からの情報は、１日１回または複数回ＥＴＡ配達注文データベースにアップロードするか、あるいは在庫情報または輸送中積み荷情報が更新されるときリアルタイムでアップロードすることができる。更新情報は、荷送り人（例えば、貨物船会社、トラック運送会社）から直接、または履歴データを使用し生成された表を使い受信できる。ＥＴＡ配達注文データベース１０からの配達注文アップロードが、例えば午前中１度だけ行われる場合、日中の製品入手可能情報およびＥＴＡ情報は、その時点で蓄積したデータに基づく。

進路変更制御サーバ７は、最新の在庫および輸送中の積み荷の配分を管理し、必要により進路を変更する。このサーバ７は、輸送中の積み荷の進路を変更すべきかどうかを決定し、ＥＴＡ配達注文データベース１０にその決定を伝達し、積み荷のＥＴＡに影響を及ぼしかねない進路変更をＥＴＡ計算サーバ３に知らせる。さらに、サーバ７は、現在在庫の品目をどこに出荷すべきかを決定することができる。進路変更制御サーバ７は、図８を参照して以下でより詳細に記述される。

運送費マトリクス・サーバ８は、代替倉庫注文オプションを表示するのに使用するデータを、発注画面サーバ４に伝達する。このオプションは、デフォルト倉庫に在庫がないとき、ディーラに他の倉庫から在庫を運び出す能力を提供する。運送費マトリクス・サーバ８は、代替倉庫に注文するときかかる追加の運送費を含む情報も（発注画面サーバ４を介して）提供する。運送費マトリクス・システム８は、図９を参照して後でより詳細に記述される。

運送費マトリクス・システム、ＥＴＡ計算システム、進路変更制御システムを統合することにより、顧客に役立つ情報を提供するだけでなく、総合的システムが積み荷を最適配分することも可能にする。リアルタイムで正確な役立つデータを、ウェブ・サイトを通じて常に提供することができる。さらに、情報は、販売チャネルまたは発注方法に関係なくすべての顧客に配信される。ディーラは、遠くの入手可能な倉庫から取り寄せるオプションを得て、何を注文するかについて知識に基づいた決定ができ、ＥＴＡ情報を精査することができ、追加運送費がいくらかかるかについてはっきりと理解することができる。進路変更能力を持つことにより、輸送中に製品の最適保管場所および量を計算することで、様々な倉庫の在庫バランスを管理することも可能になる。

図１に示されている構成以外の構成も可能であることは、もちろん理解されるべきである。例えば、発注画面サーバ４は、サーバ上でデータをフォーマットしないで、発注クライアント１に直接伝達してもよい。あるいは、通信はすべて、ＬＡＮまたはインターネット以外のＷＡＮあるいは専用接続を介して行ってもよい。他の構成もまた可能である。

図８は、図１に関連して前述した進路変更制御サーバ７の詳細ブロック図である。輸送中のコンテナ位置およびその収容する品目を含む現在輸送中情報を、輸送中情報源６が収集する。この情報は、様々な運送サービスが積み荷の配達に要する期間に関する情報を提供するため、リードタイム表９０と組み合わされる。リードタイム表９０は、輸送中情報源６から受信したデータと自身のリードタイム・データとを組み合わせ、それをデータベースの中に蓄積できるデータベース・サーバでもよい。図７Ｅは、様々な運送サービスが積み荷を配達するのにどのくらい要するかを表すリードタイム表（リードタイム算出式を使用した計算の結果と見ることもできる）の例である。出発地列は、原輸出地であり、この例では日本または中国である。輸送時間算出式は、輸送時間を計算するための算出式（すなわち論理）を供給する。

前述のように、計算式は大幅に変わってもよい。例えば、１つの式は船の平均速度、現在および予想天候並びに荷降ろし時間のような変数を考慮に入れるが、別の式は天候を考慮しないこともある。さらに、式に使われるデータは船舶運送業者または輸送サービスから直接受信（すなわち入力）することができ、従って本発明では、その式にそのデータを加えるだけでよい。正確な輸送時間算出式は重要ではなく、そのような式は本発明の範囲内である。

さらに、どの海運会社および輸送サービス会社が使用されるかによる様々のシナリオも、リードタイム表に蓄積される。この例では、コンテナが倉庫に到着するのに要する現在の輸送時間は、倉庫への現行輸送時間算出式行に示されている。また、宛先列に示されているのは、コンテナが特定の仕向け地である鉄道駅または倉庫に到着するのに要する輸送時間である。ここでは５棟の倉庫があり、５つの異なる地域、ロサンゼルス、ダラス、シカゴ、アトランタ、ニュージャージーに設置されている。上記では、２、３のシナリオの寸描を例示したが、他にも多くの例があり得る。

いずれにしろ、輸送中情報データはリードタイム表データと組み合わされ、進路変更制御表９５に伝達される。進路変更制御表９５は、データを保有し、それを他のデータベースに伝達する単なるデータベース・サーバであってもよい。代わりに、組み合わせたデータを処理し、他のサーバまたはデータベースが使用できるフォーマットに変換するサーバであってもよい。後者の方が好ましい。

様々な倉庫の販売履歴は、販売履歴情報源９１が収集し、進路変更制御表９５に伝達する。在庫情報源９２が収集した最新庫情報およびバックオーダ情報源９３が収集した倉庫のバックオーダ情報も、進路変更制御表９５に供給される。好ましい実施形態では、受信したデータをすべて集めた後、進路変更制御表９５は、データをＥＴＡ進路変更計画サーバ９４に伝達できるフォーマットに処理する。

結果に基づき、進路変更計画サーバは、コンテナの進路変更またはコンテナの中身の変更を行う命令を自動的に通知する。この命令は、例えば海運会社、積み降ろしドック、または製品の発送若しくは保管にかかわる他の誰かに伝達できる。

進路変更制御表９５は、データをＥＴＡ配達注文データベース１０に伝達できるフォーマットにも処理する。次に、発注クライアント１は、進路変更を手作業で実行することができる。

さらに、ＥＴＡ配達注文データベース１０は、この情報をＥＴＡ計算サーバ３（図１に表示）に提供することができる。次にＥＴＡ計算サーバ３は、どの進路変更に対してもＥＴＡを計算するために、この情報を使用することができる。

製品輸送中のコンテナが進路変更される場合、コンテナが再配分されないよう、その進路変更は進路変更制御表９５に記録される。しかし、優先状態に基づき、コンテナが別の倉庫に再び配分される場合があってもよい。さらに、進路変更制御計画は、実行前に許可を得るため、権限保有者に送信されてもよい。例えば、製造業者の物流部門はすべての進路変更を承認することを望む可能性がある。

都合の好いことに、本発明は製造業者の製品を動的に配分する。倉庫への配達のためユニットに荷札を付けるのが早過ぎると、効率的でない場合があるだろう。あるいは、配分された積み荷が予定の前後になることがあり、義務を果たすため、代わりの配分を行うことが必要となる場合もある。

例えば、図６を参照して、同じタイプの２つのユニットが、一方は船６２ａで発送され、他方は船６２ｂで発送され、港６３への到着が異なるＥＴＡ日付を持つとしよう。日本からの船６２ａは港６３へ２００４年１月１日に到着予定であり、台湾からの船６２ｂは同港に２００４年１月５日到着予定である。大洋を航海中、貨物船６２ａは荒れ模様の天候のために遅れ、当初予定していた（つまり２００４年１月１日）より遅く港６３に到着することとする。本発明により、配達注文義務を果たすため、他の船６２ｂ上の貨物のどの部分でも宛先を変更することができる。従ってこの例では、進路変更計画が先着順モデルに基づいている場合、このタイプのユニットを最初に注文した顧客が、港６３に最初に到着するユニットを受取る。たとえ、そのユニットが、元々はどこか他に行くように配分されていたとしても。

言い換えると、どの船上にあるユニットも、以前の宛先倉庫配分をくつがえし、宛先を変更することができる。ディーラは、２、３日の間に購入注文を満たすために別のユニットが配分されたことを知らない。ディーラが知っているのは、自分が注文した製品番号を持つユニットが時間通りに到着し、予想した運送費を請求されたことだけである。他の要因により、貨物の配分を決定してもよい。特定の製品の大量のバックオーダを抱える倉庫は、その製品の在庫を持っている倉庫に優先してもよい。または、優先順位の高いオペレータを優先し、積み荷の宛先を変更してもよい。

進路変更計画を作成するために使用する各要因は、特定の優先度を指定でき、次に計量表に蓄積される。計量表は、次に輸送の優先順位を計算するため使用できる。発送優先順位を計算する方法は、簡単な式を基にすることができるが、もっと複雑な決定理論を使用することもできる。例えば、ニューラル・ネットワーク理論を、最善の発送経路戦略を決定するため、履歴データを操作するのに実装できる。ニューラル・ネットワークは、カテゴリ型変数および連続型変数の両方でうまく働き、予測変数と従属変数間に線形関係を必要としない。ニューラル・ネットワークの周知のアプリケーションには、予測、予報、パターン認識、および問題処理の少なくとも１つがあり、その全部が多変量でデータ集約的である。

図９は、図１に関連して前述した運送費マトリクス・サーバ８の実施形態の詳細ブロック図である。前述のように、デフォルト倉庫に在庫がないとき、入手可能な他の倉庫の在庫を運び出すことができる。

注文が一旦発注クライアント１を介して発出されると、運送費マトリクス・サーバ１０８は、製品重量、運送費、特定の倉庫所在地とディーラの所在地との間の距離を含む様々な要因に基づき、運送費の増加額を計算する。製品重量は、特定の品目番号とそれに対応する重量を単に組み合わせる製品重量表データベース１００に格納される。運送費も、特定の倉庫所在地とディーラの所在地との間の距離に基づき計算される。この決定は、ディーラ出荷場所データベース１０４に格納できるディーラ住所情報を使用して行われる。在庫の入手可能性は、在庫情報データベース１０６から得られる。在庫情報データベース１０６には、図１に関連して前述された在庫情報源９が在庫情報を供給できる。

本発明による発送プロセスの概観が、今度は輸送メカニズムの観点から提示される。図６は、製造工場を出た後の製品の行程を表している。

製造後、製品ユニットは運送用コンテナに積み込まれる。図に示されるように、コンテナ輸送船６２ａおよび６２ｂは、コンテナを（ある国の）港６１ａおよび（別の国の）港６１ｂから米国内の特定の港６３に輸送する。コンテナは、港６３で降ろされ、次に５棟の倉庫６５ａ〜６５ｅの１つに鉄道、トラック、または飛行機で輸送される。各コンテナを追跡し、リアルタイムに輸送中の位置データを取得することができる。さらに、内容物（すなわち製品）は、いずれの時点でもかなり詳細に確定できる。コンテナの中身が変わっても、本発明は、正しい配分決定、到着時刻推定、および運送費計算を行うため、変更を観察する。

普通、積出港６１ａおよび６１ｂを出発する輸送用コンテナは、出発時、最終仕向け地が指定される。しかし、配分されないものもある。配分されていないコンテナ、換言すると「進路変更コンテナ」は、輸送中に様々な最終仕向け地を配分することができる。言い換えると、進路変更コンテナの最終宛先（例えば、最終仕向け港または倉庫）は、仕向け港６３で積み下ろしを開始する前のいつの時点でも決定することができる。

（例えば、バックオーダを解消するため）コンテナの進路を変更しなければならない場合、配達注文を混乱させないため、配分されたコンテナより進路変更コンテナを配分するほうが通常は好ましい。しかし時には、例えば契約要件を満たすのに、配分されたコンテナを進路変更したほうがより効率的で経済的なこともある。

進路変更コンテナまたは配分されたコンテナのどのコンテナからも、輸送中にいつでも一部取り出し他のコンテナに詰め、最終宛先を割り当てることができる。

本発明は、どの製品のどの倉庫へのＥＴＡ情報も都合よく提供する。前述のように、製品の中には、港６３に到着する前のいつかの時点で倉庫６５ａ〜６５ｅに配分されるものがある。進路変更コンテナに収容された製品は、配分されていない。さらに、どのコンテナの一部または全部の内容物（すなわち製品）も、種々の理由で進路変更することができる。さらにまた、配分されたおよび配分されていない製品のＥＴＡは、進路変更制御サーバ７で決定され、それから入手できる。ＥＴＡ情報は、配分されていない輸送中の製品に関してさえも提供してよい。

従って、本発明は、デフォルトまたは代替倉庫でどの製品が入手できるかだけでなく、どこかを輸送中の積み荷にも基づいて、ディーラが購入注文を決定することを都合よく可能にする。本発明は、ディーラが製造業者の倉庫の在庫を確認することを基本的に可能にすることで、顧客の運送費を節約する。本発明は最低限でも、製造業者が運転資金を管理し、資金繰りを生み出し、効率的に倉庫の在庫を管理するのも支援する。さらに、本発明は顧客サービスも改善する。

図２〜５は、本発明によるデータ入力と閲覧用のウェブ・ページの例示である。図２は、基本顧客情報および発送情報の入力を可能にする初期発注画面の説明図である。各購入注文には、発注番号２０が割り当てられる。オペレータは、共通の発送および顧客情報を２１ａ〜ｋの適切な欄に入力するか、または以前保存した注文を閲覧し修正するため、保存注文閲覧ボタンを選択する。また別の方法として、注文アップロード・ボタン２３を選択して、エディタまたは表計算ソフトを使用して以前作成した注文データ・ファイルをアップロードしてもよい。保存されている注文や以前作成された注文を使用すると、まったく同じまたはほぼ同じ商品を頻繁に注文するディーラは時間を節約することができる。オペレータは、次に継続ボタン２４を選択し注文処理を継続するか、注文取消ボタン２５を選択し注文を取り消す。

図３は、上記初期発注画面で継続ボタン２４が押された場合に、オペレータに表示される補充注文詳細画面の説明図である。入力またはロードされた品目番号が品目番号列に示され、その相当する説明が商品説明列３１ｂに表示される。ディーラは、数量列３１ｄに要求する品目の数量を入力する。積み荷分割チェックボックス３１ｅ使用し、注文品目は１回の出荷で配達されるべきかどうか、または選択した品目の数量がすぐに入手できない場合、その品目は別々の出荷で配達されるべきかどうかを選択できる。単価および各品目の合計金額は、価格取得ボタン３２を選択することにより、単価列３１ｆおよび金額列３１ｇにそれぞれ表示される。あるいはまた、この情報はデータを入力すると自動的に更新でき、それによって価格取得ボタン３２の必要性を除いている。

カタログ・ボタン３３は、オペレータが特定の製品またはその製品についての情報を探すのを支援するのに利用できる。オペレータは、行追加ボタン３４および行削除ボタン３５を押すことにより、品目行をそれぞれ追加または削除することもできる。さらに、オペレータは、ヘッダ編集ボタン３６を使いヘッダをカスタマイズしてもよい。一旦品目を入力すると、注文情報は、注文保存ボタン３７を押すことにより保存できる。オペレータが継続ボタン２４を押すと、ＥＴＡシステムは図４に示される状態画面に進む。

図４は、デフォルト倉庫の入手可能在庫情報および運送費情報を提供し、代替倉庫情報および選択画面にハイパーリンクする注文状態画面の説明図である。この画面は、前述の初期発注画面（図２）および注文詳細画面（図３）でオペレータが入力した情報を表示する。倉庫列４０で示されているように、このディーラは、デフォルト倉庫をニュージャージー倉庫に指定する契約を結んでいる。入手可能列は、一番目の品目は入手可能であるが、二番目は入手不可能であることを表している。追加の品目を、品目追加ボタン４２を押すことにより尋ねることができる。

次にユーザは、提出ボタン４３を押して注文を提出する選択肢があり、選択すると要求を続行する。代わりに、オペレータは、デフォルト倉庫がその品目をいつ在庫に持つかを確かめ、他の入手可能オプションを閲覧する選択肢がある。これは、在庫のない品目を選ぶことにより行われる。図４では、これは入手可能列４１の「Ｎｏ」ハイパーリンクを選択することにより行われ、オペレータを図５に示される別の画面に連れてゆく。

図５は、デフォルトおよび代替倉庫の配達注文オプションを閲覧し選択するための、到着予定時刻情報および注文オプション画面の説明図の例示である。この画面は、図４に関して前述した注文入手可能画面から飛び出す、（図に示すように）ポップアップ画面でもよい。情報の中には、前の画面（図２〜４）で提示されたのと同じものがある。画面の残りの部分は２つの区画５２と５４に分けられている。区画５２は、ディーラのデフォルト倉庫に関する情報を表示し、区画５４は、ディーラの代替（すなわち２次的な）倉庫に関する情報を表示する。

数量列５５および５８は、ディーラが要求した製品の数量を表す場合とそうでない場合がある。少ししか入手できない場合、それらの列は少ない数量を表示する。製品が入手可能でない場合、状態列４１および５６は、それに応じて表示する。デフォルト倉庫が在庫切れの場合は、入庫日列５３が、次の積み荷がいつ到着予定かを示す。要求された注文に一部応じられる場合（図に示されていない）は、入手可能なユニット量が数量列５５に表示され、残りがいつ入庫するかが入庫日列５３に表示される。同様に、要求された注文に代替倉庫で一部応じられる場合（図に示されていない）は、数量列５８に対応できるユニット量を表示し、残りがいつ入荷するかが入庫日列（図に示されていない）に表示される。

代替倉庫区画５４は、運送費差列５７に示す、特定の２次的倉庫に対応する運送費の差額をさらに含む。運送費の増加は、パーセントで表示される。

図７Ａは、特定の製品の最新および計画在庫並びにバックオーダ状態を閲覧するウェブ・ページの例示である。製品は、製品番号欄７７で識別され、商品説明欄７８に説明がある。一旦製品番号を入力すると、オペレータは照会ボタン７９選択し、その製品の最新在庫状況を受信する。

各倉庫は、倉庫列８０に示される数値を指定されている。各倉庫の対応する最新在庫総数が、在庫列８１に一覧で表示される。輸送中列８２で確認されるのは、各倉庫８０に輸送中のユニット数である。バックオーダ列８３では、バックオーダのユニット数が確認される。従って、例えば倉庫２２（倉庫列８０の中）は、その対応する在庫列８１に示されるように、製品番号「６３７８Ａ００２３ＢＡ」を現在在庫として持っていない。倉庫２２は、輸送中列８２に示されるように、製品の比較的大きな積み荷、正確には４３２ユニットを受入れる予定である。倉庫２２は、その特定の製品について３３ユニットのバックオーダも抱えている。

特定の倉庫向けの製品積み荷のより詳細な情報は、輸送中列８２のハイパーリンク（下線付きの数字で表示されている）の１つを選択することで見ることができる。例えば、オペレータが倉庫２２の情報に関心がある場合、輸送中列８２にある「４３２」を選択することができる。その場合には、図７Ｂに示される画面が表示される。

図７Ｂは、倉庫２２の特に製品の在庫状況に関連する情報を表示するウェブ・ページの例示である。列７０は、３つのカテゴリに属する情報を含んでいる。区画７０ｂに指定されている１つのカテゴリは、特定の時点における倉庫の在庫状況を表している。この例では、この特定の倉庫に関する在庫情報は、午前中のものである。倉庫は午前中、数量列７２に表示されているように、９４ユニットが入手可能であった。しかし、その時に配分数量列７４に表示されているように、９４ユニット全部が配分された。

区画７０ａに指定されている別のカテゴリでは、配達注文番号列７０が製品を倉庫２２に輸送する５つの配達注文があることを示している。特にコンテナ番号列７５で確認される５つのコンテナがあり、数量列７２に表示されるように、それぞれ７２ユニットを収容している。配分数量列７４に示されているように、「ＮＹＫＵ６０５７９７５］として識別される１つのコンテナは、その７２ユニットのうち３３ユニットが、その倉庫に配分されている。これは、図７Ａのバックオーダ列８３に関連して前述した倉庫２２の製品のバックオーダと一致する。これにより、オペレータ（または自動的に配分を制御するサーバ）が、どの積み荷を最初に配分または進路変更すべきか優先順位付けするのを可能にする。倉庫へのＥＴＡ日付は倉庫ＥＴＡ日列７３で確認される。コンテナ「ＮＹＫＵ６０５７９７５］が、倉庫２２への到着日が一番早いと確認され、従ってそのコンテナのユニットが最初に配分される。

区画７０ｃは、倉庫間を輸送中の積み荷の状況を示す。これは、コンテナ番号列およびインボイス番号列の「ＸＦＥＲ」指定により表されている。インボイス列７６は、可能な場合、特定の積み荷のインボイス番号を表示する。発送方法などのこの転送積み荷に関する詳細は、ＸＦＥＲボタン（図に示されていない）を押すことで見ることができる。

図７Ｃは、特定の製品に対する起こりうる輸送中コンテナの進路変更シナリオについての情報を表示するウェブ・ページの例示である。製品番号欄７０１に特定の製品を入力した後、オペレータは、情報を閲覧するため照会ボタン７０３選択する。船番号列７００が、現在製品を運んでいる全部の船を表示する。数量列は、各船が何ユニットの製品を運搬しているかを表示する。コンテナ数列７０４は、船がその製品を何個の異なるコンテナに入れて運搬しているかを表示する。締切日列７０６は、オペレータがそれまでに配分を完了しなければならない日付を表示する。この日付は、運送会社および荷受人にコンテナを荷造りし直すか、または港で商品を受取るために輸送トラックの手配をするかのどちらかの時間を提供する。その日付に応じて、この場合オペレータは、「１１月１５日」以前にだけ製品の積み荷を進路変更することができる。

ＥＴＤ列７０８は、船の推定出発時刻を表示している。ロサンゼルスＥＴＡ列は、ロサンゼルス倉庫への到着予定時刻を表示する。配達情報は、海運会社または他の情報源のどちらかで確認することができる。積み荷が確認できた場合、確認列７１２に現れる。倉庫ＥＴＡ、コンテナ数、および数量の情報は、７１４で表されているように単に画面を右に移動するだけで、製品のコンテナを配達可能な他の利用できる宛先倉庫すべてにも提供される。この情報により、権限のあるオペレータ（または自動的にサーバ）は、必要なコンテナを進路変更することができる。これは、船番号ハイパーリンク（例えば「１Ｘ９３ＪＦ」）を選択することで遂行される。例えば船「１Ｘ９３ＪＦ」が選ばれた場合、図７Ｄに示される画面が現れる。

図７Ｄは、本発明による、倉庫の過去と現在の販売および在庫配分を閲覧するため、並びに手動操作により進路変更命令を入力するための、ウェブ・ページの例示である。図７Ｃに示されている画面と同じ情報のいくらかは、この画面にも表示されている。製品番号は製品番号欄７０１に表示されている。選択された船番号が、船番号欄７１１ａに表示される。この船のコンテナ数はコンテナ数欄７０４ａに表示される。ユニットの合計数量は、数量欄７０２ａに表示される。配分が完了されていなければならない日付は、締切日欄７０６ａに表示される。

追加情報も提供される。この船で輸送中の製品の合計数が、輸送中合計欄７２０に表示される。港への到着予定時刻は、港へのＥＴＡ欄７１０ａに表示される。

オペレータが詳細な情報を得た上で決定できるように、倉庫に関連する情報が提供される。倉庫番号が倉庫列７２２に表示される。対応する販売履歴情報、この場合は過去６か月間が、販売履歴（６か月）列７２４に表示される。各倉庫に対する現在の在庫が、最新在庫列７２６に表示され、倉庫の現在のバックオーダが最新バックオーダ列７２８に表示される。

オペレータは、進路変更コンテナ数列７３０に進路変更するコンテナ数量を入力することにより、船上のコンテナを特定の倉庫に進路変更する。この列は、各コンテナが収容するユニット数も表示する。オペレータの便宜のために、輸送先変更を提案されたユニット数量が推奨進路変更計画列７３２に表示される。この情報は、履歴情報または他の情報に基づき決定される。決定するための特定の式または論理は変わってもよい。

承認ボタン７３７が選択されると、入力されたデータの処理を開始する。ＥＴＡ応答列７３４は、顧客に配分されたとすでに報告されている製品ユニットの数量を示す。ＥＴＡ列７３６は倉庫への推定配達時刻を示す。図７Ｄの倉庫へのＥＴＡ列７３６に表示されるＥＴＡ日付は、列７１０に表示されているＥＴＡ情報および図７Ｃに表されているＥＴＡ情報照会画面の他の倉庫のＥＴＡ情報列（図に示されていない）と同じであることが好ましい。しかし、海運会社または地元の運送会社が配達を確認していない場合、日付が異なることがある。

大洋海運会社が仕向け港への到着を確認しているが、地元の運送業者（例えば、トラック運送業者または鉄道会社）が確認できない場合がある。この場合は、図７Ｃのオペレータに表示されるＥＴＡ情報は、過去のデータに基づき、地元の運送会社は時間通りであると決めてかかる。関係するデータがすべて入手でき且つ最新であれば、図７Ｃおよび７Ｄに描かれている画面上に表示されるＥＴＡ情報は同じになる。

配分は、推奨進路変更計画または推奨進路変更計画算出に使用するデータに基づき、手動操作を行う必要なしに自動的にできる。例えば、進路変更は、倉庫の最新のバックオーダ、最新の在庫、販売履歴などに基づき、自動的に決定することができる。

図１０および１１は、本発明の実施形態の詳細ブロック図である。図１０はデータ・フローを表し、図１１は図１０に相当するシステム図を説明している。どの時間の言及も単に例示であり、各データ転送間隔は、更新をリアルタイムに変更するかまたは定期的に実施することができる。リアルタイム・データが使用されるのが好ましいが、情報によっては、リアルタイムに入手できない場合もある。そのような状況では、本発明は、データベースに蓄積されている入手できた最新の情報を使用することができる。

図１０に示されているように、３タイプのクライアント発注システムが使用されており、それらはエクストラネット・クライアント２３５、ＥＤＩクライアント２３０、および自社クライアント２２５である。これらの各クライアントは、注文を入力する発注端末２３５ａ、２３０ａ、２２５ａを持っている。図に示すように、エクストラネット発注端末２３５ａは、デフォルト倉庫および入手可能情報を受信でき、自社発注端末２２５ａは、注文要求を送信し注文に対する入庫通知を受信することができる。しかし、ＥＤＩクライアント２３０は、発注だけができる。より一般的には、すべてのオペレータが、システムが有する機能のすべてを実行する許可を持っているわけではない。それは、例えばディーラは、船番号またはコンテナ番号のような輸送の詳細などのある種の詳細を知る必要はないが、他のオペレータ、例えば物流や調達業務を担当している業者は知る必要があるからである。さらに、製造業者は、貨物位置、顧客優先状態、運送会社情報、運送料などのある種の情報を秘密にしておきたいこともある。ディーラは通常、特定の製品をいついくらで入手できるかのみ知る必要がある。

データ（自社クライアント２２５のデータを除く）は、顧客注文表データベース２５０にロードされる。自社発注システム２２５は、それ自体のデータベースにデータをロードし、次にＥＴＡ顧客注文データベース２６０に直接ロードする。さらに、顧客注文表データベースに添えられている端末を介して内部から注文することもできる。

物流データベース２４０は、輸入インボイス、国内購入注文、最新在庫を格納するデータベースを含む。インボイスは、製造業者２００が作成し、輸入インボイス情報源２０５ａに送信される。インボイス・データは、船番号、積み荷数量、コンテナ数、推定出発時刻、港への到着予定時刻、特定の倉庫へのＥＴＡ、特定の倉庫へ配達されるコンテナ数、および配達を必要とする倉庫の合計数などの情報を含む。さらに、インボイスは、例えば進路変更コンテナに対する、配分が完了しなければならない締切日を含んでもよい。従って、輸入インボイスは配分されていることもあり、そうでないこともある。

同様に、国内購入注文情報は国内購入注文情報源２０５ｂが受信する。一般に、購入注文は特定の顧客のためであるが、配達輸送中に注文を取り消すことは可能である。この場合は、その品目を別の倉庫に配達するか、または配分できるまで輸送機関にとどめておくのが最適なこともある。同様に倉庫間転送情報は、倉庫転送情報源２０５ｃが取ってくる。全部で３つの輸送中情報源（すなわち、輸入インボイス２０５ａ、国内購入注文２０５ｂ、倉庫転送２０５ｃ）からのデータは、物流データベースに供給される。

物流データベース２４０ａ、２４０ｂ、２４０ｃは、輸送中情報および最新在庫情報のすべてを格納する。在庫および輸送中積み荷情報のすべてを、ＥＴＡサーバ２２０が引き出す。

積み荷状況データベース２１０は、運送会社からＥＴＡの更新を受信する。インボイスの写しが運送会社に提供されるので、運送会社は、ブロック２１０で示されているように、貨物船とインボイスを照合し、ＥＴＡデータを更新することができる。次に運送会社は、相当するＥＴＡデータをＥＴＡ配達注文データベース２２０に送信することができる。次に、ＥＴＡ配達注文データベース２２０およびＥＴＡ顧客注文データベース２６０からのデータは、前述のように配分処理装置２５５が処理する。

進路変更制御は、図８に関連して前述したように、ＥＴＡ配達注文データベース２２０を運用するサーバが実行することができる。従って、図のように進路変更制御および配分の両方を、配達注文および顧客注文データに基づき実行することができる。

ブロック２７０は、最新の顧客バックオーダに対する製品ユニットの自動予約要求を表している。ここでは、顧客注文が最新の在庫データと対にされる。ユニットが入手可能になると、バックオーダを解消するため配達される。

ＥＴＡおよび注文状況の照会は、卸売りイントラネット・アプリケーション２４５を使用し行うことができ、オペレータは、すべての注文の状態および進路変更コンテナの詳細を含む配分を閲覧できる。

図１１は、本発明による実施形態を実現するコンピュータ・ネットワーク・システムを描いている。輸送中データは、インボイス情報源２０５ａ、国内購入注文情報源２０５ｂ、倉庫転送情報源２０５ｃが収集する。配分されたおよび配分されていない（すなわち進路変更コンテナ）積み荷データを含むこれらの情報源が収集したデータは、物流処理２４０データベースに供給され、次にＥＴＡサーバ・システムの中にある配達注文データベースＥＴＡ＿ＤＯに送信され格納される。最新在庫データは入庫データ情報源２０５ｄから在庫データベースに供給される。在庫データベースのデータもまたＥＴＡ＿ＤＯデータベースに供給される、さらに、輸送状況情報源２１０が提供する輸送状況に関するデータもまた、ＥＴＡ＿ＤＯデータベースに格納される。輸送状況情報源２１０は、輸送中積み荷の位置状況を提供する。このデータは、情報源の運送会社から直接受信できる。場合によっては、運送会社は、対応する積み荷の情報を提供するのにインボイスの写しも必要とすることがある。その場合は、必要なインボイス情報の要求は、物流処理装置に要求でき、同装置は、輸送状況情報源２１０に関係するインボイス、購入注文、または他の転送関連情報を供給することで応える。

物流および最新在庫データベースからのデータ並びに運送会社状態データは、１日１回またはもっと頻繁にＥＴＡ＿ＤＯデータベースに収集できる。このデータはリアルタイムに収集されるのが好ましい。しかし、データ源（例えば運送会社状態情報源２１０等）が運転休止中またはリアルタイム更新要件を満たすことができない場合がある。これらの場合は、最後に更新できたデータが使用される。図１１に示されるように、この例のデータの多くが「一度」ブロックで示されているように、１日１回送信される。しかし、それらのブロックのどれも、入手できしだいデータを情報源からその対応するデータベースに送信できることを示す「リアルタイム」ブロックと交換できる。その直後に、処理を行うことができる。

自動配分処理装置２２０ａおよび手動配分処理装置２２０ｂは、ＥＴＡ＿ＤＯデータベースに格納されているデータを処理する。これらの処理装置は、顧客注文データベースＥＴＡ＿ＣＯに格納されているデータも処理する。ＥＴＡ＿ＣＯは、エクストラネット２３５、ＥＤＩ２３０、自社注文システム２２５からの顧客注文をすべて収集する。処理装置２２０ａおよび２２０ｂの処理結果は、続いてＥＴＡ＿ＤＯＣＯデータベースに格納される。上述のように、配分処理装置は、どの論理式にでも従ってデータを処理することができる。

進路変更制御は、図８および１０に関連して前述のように、進路変更処理装置２２０ｃが処理する。この処理装置は、ＥＴＡ配達注文データベースＥＴＡ＿ＤＯを実行するサーバの一部を使用することができる。

ＥＴＡ＿ＤＯＣＯは、種々のアプリケーションが参照することができる。発注端末２３５ａ、２３０ａ、２２５ａ、および内部卸売りイントラネット・アプリケーション端末２４５は、ＥＴＡの時刻および状態を閲覧するためデータを参照することができる。さらに、前述のように、適切な権限のあるそれらのシステムは、次に注文を発し、進路を変更し、費用を見ることができる。

ブロック２７０は、（在庫データベースに格納された）最新在庫状況とエクストラネットおよびＥＤＩからの発注を結び付け、要求者に配分するため注文された品目を予約する。エクストラネットおよびＥＤＩからの注文は、自動配分処理装置２２０ａまたは手動配分処理装置２２０ｂが予約でき、自社注文システム２２５からの顧客注文に対しても同様に行われる。

ＥＴＡ処理装置２２０は、配分されたまたは配分されていない輸送中の各品目を指定し、配分された品目を再配分できるかどうか指定することができる。対応する品目レコードにコードを付与することにより、ＥＴＡサーバ２２０が物流データをフィルタできるようにする。ユーザ（または自動処理装置）が何を見るかの例が、図７Ｂに示されている例の中に描かれている。図７Ｂの７４列に示されているように、３３ユニットがバックオーダを解消するため倉庫２２に配分されている。ＥＴＡ処理装置は、それらのユニットが最後に再配分されるように、３３ユニットの品目レコードを配分されているとコードを付与する。同じモデルのユニットを持つ、配分されていないユニットの早い積み荷が予想されている場合、フィルタ・コードを変更し、以前配分されていた品目を、配分されていないかまたは異なる最終仕向け地へ再配分して、取り替えを行うことができる。

本発明は、本文中に開示されている構成に関して記述されているが、述べられている詳細に制限されるものではなく、本願は、改善の目的内または下記の特許請求の範囲の範囲内に来るような改造または変更を網羅することを意図している。

本発明の方法およびシステムを実装するハイレベル・ブロック図である。 基本顧客情報および発送情報の入力を可能にする初期発注画面の説明図である。 製品補充注文情報の入力を可能にする注文詳細画面の説明図である。 入手可能性および費用情報を提供し、代替倉庫の情報および選択画面にハイパーリンクする注文可能性画面の説明図である。 デフォルトおよび代替倉庫の配達注文オプションを閲覧し選択する、到着予定時刻情報および注文オプション画面の例示的説明図である。 製造業者の製品が、製造工場から倉庫への輸送中に通る可能性がある配達経路の説明図である。 本発明による、特定の製品に関する倉庫の最新および計画在庫並びにバックオーダ状態を閲覧する、ＥＴＡ照会画面の例示的説明図である。 本発明による、特定の製品に関するより詳細なＥＴＡ情報および倉庫配分情報を閲覧する、ＥＴＡ照会画面の例示的説明図である。 特定の製品に関する起こりうる輸送中コンテナの進路変更シナリオについての情報を示す、ＥＴＡ情報照会画面の例示的説明図である。 本発明による、倉庫の過去および現在の販売および在庫配分を閲覧し、手動操作で進路変更指示を入力する、倉庫情報および進路変更入力画面の例示的説明図である。 様々な運送サービスが積み荷配達に要する期間を示すリードタイム表である。 本発明による進路変更制御システムの実施形態の詳細ブロック図である。 本発明による運送費計算システムの実施形態の詳細ブロック図である。 本発明の方法およびシステムを実行するデータ・フローの概観を示す詳細ブロック図である。 図１０で示されるデータ・フロー図に合わせた、本発明の実施形態の詳細ブロック図である。

Claims (92)

1. ネットワーク上にあるクライアントに到着予定時刻情報を提供する、ネットワーク上のシステムであって、
   製品番号を含む製品照会を促す１以上のページをクライアントに提供し、
   製品照会を受け取り、
   製品番号を有する少なくとも１つの輸送中のユニットが、複数の宛先に到着する複数の予定時刻を決定し、
   決定した到着予定時刻を前記クライアントに送信することを特徴とするシステム。
2. 少なくとも一つの宛先に進路変更すべき製品番号の推奨される量のユニットを含む転送推奨情報を、前記クライアントに送信し、
   前記進路変更推奨情報は、在庫情報と輸送中情報に基づいており、
   現在庫情報は、少なくとも一つの宛先毎に販売履歴と入荷待ちデータとを含み、輸送中情報は、少なくとも一つの輸送中のユニットのそれぞれの位置を含むことを特徴とする請求項１に記載のシステム。
3. 更に、運送業者ＩＤ、製品番号、数量、及び宛先ＩＤを含む製品進路変更要求をクライアントから引き出す１以上のページをクライアントに提供し、
   前記製品進路変更要求を受け取り、
   少なくとも１つの輸送中ユニットの１つを、前記宛先ＩＤに対応する最終宛先に、進路変更することを特徴とする請求項１に記載のシステム。
4. 前記少なくとも一つの輸送中のユニットの１つについて、在庫情報と輸送中情報とを処理する進路変更計画プロセッサの結果に基づいて、進路変更を行ない、
   現在の在庫情報は、少なくとも１つの宛先の販売履歴と、少なくとも１つの宛先の入荷待ちデータとを含み、
   輸送中情報は、少なくとも１つの前記輸送中のユニットを搬送する少なくとも一つの輸送車両の場所を含むことを特徴とする請求項３に記載のシステム。
5. 更に、最終的な宛先に進路変更されたその製品番号のユニットの製品番号と量とを含む、確認情報をクライアントに送信することを特徴とする請求項３に記載のシステム。
6. 輸送中のユニットの１つを最終的な宛先に進路変更する進路変更指示を、運送業者に与え、
   前記進路変更指示は、運送業者の輸送手段に製品を配置するために十分な情報を含む、宛先ＩＤ及びコンテナＩＤを含むことを特徴とする請求項３に記載のシステム。
7. 前記輸送手段とは、貨物船であることを特徴とする請求項６に記載のシステム。
8. 前記輸送手段とは、貨物列車であることを特徴とする請求項６に記載のシステム。
9. 前記輸送手段とは、陸上交通車両であることを特徴とする請求項６に記載のシステム。
10. 進路変更対象となる前記輸送中のユニットは、前記宛先の何れにも割り当てられなかったものであることを特徴とする請求項３に記載のシステム。
11. 前記輸送中のユニットは、かつて１つの宛先を割り当てられたことを特徴とする請求項３に記載のシステム。
12. ネットワークを介してサーバにリンクするシステムであって、製品番号を含む製品問い合わせ情報をサーバに送信し、
    製品番号を有する少なくとも１つの輸送中のユニットについて、複数の宛先への複数の到着予定時刻を受信することを特徴とするシステム。
13. 前記サーバに、輸送手段ＩＤと、製品番号と、数量と、宛先ＩＤとを含む進路変更要求を送信し、
    少なくとも１つの輸送中のユニットの１つを、宛先ＩＤに対応する最終的な宛先に進路変更したことを示す通知を、サーバから受け取ることを特徴とする請求項１２に記載のシステム。
14. 更に、
    製品番号、数量及び顧客ＩＤを含む製品購入オーダを、サーバに送信し、
    製品購入オーダが、受け付けられたことを示す通知をサーバから受け取り、
    サーバは、その製品番号の少なくとも１つの輸送中ユニットを、顧客ＩＤに基づく最終的な宛先に進路変更することを特徴とする請求項１２に記載のシステム。
15. 少なくとも１つの二次的な宛先からオーダすることによる超過料金を含む超過運賃情報を提供するネットワーク上のシステムであって、
    製品番号を含む製品照会を促す１以上のページをクライアントに提供し、
    製品照会を受信し、
    製品重量テーブルデータベースから、対応する製品重量を受信し、
    ディーラ所在地データベースから、ディーラのアドレスを受信し、
    運送料テーブルデータベースから、ディーラアドレスに基づいて、少なくとも１つの送料を受信し、
    製品重量データベース、運送料データベース及びディーラ所在地データベースに格納された情報に基づいて、少なくとも１つの送料の相違を計算し、
    前記少なくとも１つの送料の相違をクライアントに送信することを特徴とするシステム。
16. ネットワークを介してサーバとリンクするシステムであって、
    製品番号及び顧客ＩＤを含む製品情報をサーバに送信し、
    少なくとも１つの二次的な宛先からのオーダに対して、少なくとも１つの送料の違いを受信することを特徴とするシステム。
17. 製品番号を有する複数の輸送中のユニットの１つを、複数の宛先に自動的に進路変更する、ネットワーク上のシステムであって、
    複数の輸送中のユニットについて、複数の宛先のそれぞれへの到着予定時刻を決定し、
    複数の宛先のそれぞれについての販売歴情報、それぞれの宛先についての現在庫情報、及び輸送中情報に基づいて、進路変更計画を決定し、
    前記現在庫情報は入荷待ちデータを含み、前記輸送中情報は、複数の輸送中ユニットの場所を含み、
    進路変更計画に基づいて、１つの宛先に対して１つのユニットを進路変更することを特徴とするシステム。
18. 更に、１つのユニットを１つの宛先に進路変更するための進路変更指示を運送業者に送信し、
    この進路変更指示は、進路変更計画に基づく１つの宛先に対応する宛先ＩＤと、１つのユニットを運送業者の輸送手段上に１つのユニットを配置するのに十分な情報を含むコンテナＩＤとを含むことを特徴とする請求項１７に記載のシステム
19. 前記輸送手段とは、貨物船であることを特徴とする請求項１８に記載のシステム。
20. 前記輸送手段とは、貨物列車であることを特徴とする請求項１８に記載のシステム。
21. 前記輸送手段とは、陸上交通車両であることを特徴とする請求項１８に記載のシステム。
22. 進路変更対象となる前記１つのユニットは、前記宛先の何れにも割り当てられなかったユニットであることを特徴とする請求項１８に記載のシステム。
23. 輸送対象となる前記１つのユニットは、以前に１つの宛先を割り当てられたユニットであることを特徴とする請求項１８に記載のシステム。
24. ネットワーク上にあるクライアントに到着予定時刻情報を提供する方法であって、
    製品番号を含む製品照会を促す１以上のページをクライアントに提供するステップと、
    製品照会を受け取るステップと、
    製品番号を有する少なくとも１つの輸送中のユニットが、複数の宛先に対する到着予定時刻を決定するステップと、
    決定した到着予定時刻を前記クライアントに送信するステップと、
    を有することを特徴とする方法。
25. 少なくとも一つの宛先に進路変更するべき製品番号の、推奨される量のユニットを含む進路変更推奨情報を、前記クライアントに送信するステップを更に有し、
    前記進路変更推奨情報は、在庫情報と輸送中情報に基づいており、
    現在庫情報は、少なくとも一つの宛先毎に販売履歴と入荷待ちデータとを含み、輸送中情報は、少なくとも一つの輸送中のユニットのそれぞれの位置を含むことを特徴とする請求項２４に記載の方法。
26. 運送業者ＩＤ、製品番号、数量、及び宛先ＩＤを含む製品進路変更要求をクライアントから引き出す１以上のページをクライアントに提供するステップと、
    前記製品進路変更要求を受け取るステップと、
    少なくとも１つの輸送中ユニットの１つを、前記宛先ＩＤに対応する最終宛先に、進路変更するステップと、
    を更に含むことを特徴とする請求項２４に記載の方法。
27. 在庫情報と輸送中情報とを処理する進路変更計画プロセッサの結果に基づいて、前記少なくとも一つの輸送中のユニットの１つを進路変更するステップと、
    前記在庫情報は、少なくとも１つの宛先の販売履歴と、少なくとも１つの宛先の入荷待ちデータとを含み、
    前記輸送中情報は、少なくとも１つの前記輸送中のユニットを搬送する少なくとも一つの輸送車両の場所を含むことを特徴とする請求項２６に記載の方法。
28. 更に、最終的な宛先に進路変更されたその製品番号のユニットの製品番号と量とを含む、確認情報をクライアントに送信するステップを含むことを特徴とする請求項２６に記載の方法。
29. 輸送中のユニットの１つを最終的な宛先に進路変更する進路変更指示を、運送業者に与えるステップを更に含み、、
    前記進路変更指示は、宛先ＩＤと、運送業者の輸送手段に製品を配置するために十分な情報を含むコンテナＩＤと、を含むことを特徴とする請求項２６に記載の方法
    。
30. 前記輸送手段とは、貨物船であることを特徴とする請求項２９に記載の方法。
31. 前記輸送手段とは、貨物列車であることを特徴とする請求項２９に記載の方法。
32. 前記輸送手段とは、陸上交通車両であることを特徴とする請求項２９に記載の方法。
33. 進路変更対象となる前記輸送中のユニットは、前記宛先の何れにも割り当てられなかったユニットであることを特徴とする請求項２６に記載の方法。
34. 前記輸送中のユニットは、以前に１つの宛先を割り当てられたユニットであることを特徴とする請求項２６に記載の方法。
35. ネットワーク上のサーバから、到着予定時刻を取得する方法であって、
    製品番号を含む製品問い合わせ情報をサーバに送信し、
    製品番号を有する少なくとも１つの輸送中のユニットについて、複数の宛先への複数の到着予定時刻を受信することを特徴とする方法。
36. 輸送手段ＩＤと、製品番号と、数量と、宛先ＩＤとを含む進路変更要求を前記サーバに送信するステップと、
    少なくとも１つの輸送中のユニットの１つを、前記宛先ＩＤに対応する最終的な宛先に進路変更したことを示す通知を、サーバから受け取るステップと、
    を更に含むことを特徴とする請求項３５に記載の方法。
37. 製品番号、数量及び顧客ＩＤを含む製品購入オーダを、サーバに送信するステップと、
    前記製品購入オーダを受け付けたことを示す通知をサーバから受け取るステップと、
    を更に含み、
    前記サーバは、その製品番号の少なくとも１つの輸送中ユニットを、顧客ＩＤに基づく最終的な宛先に進路変更することを特徴とする請求項３５に記載の方法。
38. 少なくとも１つの第２の倉庫からのオーダによる超過料金を含む超過運賃情報を提供する方法であって、
    製品番号を含む製品照会を促す１以上のページをクライアントに提供するステップと、
    製品照会を受信するステップと、
    製品重量テーブルデータベースから、対応する製品重量を受信するステップと、
    ディーラ所在地データベースから、ディーラのアドレスを受信するステップと、
    運送料テーブルデータベースから、ディーラアドレスに基づいて、少なくとも１つの送料を受信するステップと、
    製品重量データベース、運送料データベース及びディーラ所在地データベースに格納された情報に基づいて、運賃における少なくとも１つの相違を計算するステップと、
    少なくとも１つの送料の違いをクライアントに送信するステップと、
    を含むことを特徴とする方法。
39. 少なくとも１つの二次的な宛先からのオーダによる超過料金を含む超過運賃情報を、ネットワーク上のサーバから受け取る方法であって、
    製品番号及び顧客ＩＤを含む製品照会情報をサーバに送信するステップと、
    少なくとも１つの二次的な宛先からのオーダのための送料の、少なくとも１つの違いを受信するステップと、
    を含むことを特徴とする方法。
40. 製品番号を有する複数の輸送中のユニットの１つを、複数の宛先に自動的に進路変更する方法であって、
    複数の輸送中のユニットについて、複数の宛先のそれぞれへの到着予定時刻を決定するステップと、
    複数の宛先のそれぞれについての販売歴情報、それぞれの倉庫についての現在庫情報、及び輸送中情報に基づいて、進路変更計画を決定するステップと、
    進路変更計画に基づいて、１つの宛先に対して１つのユニットを進路変更するステップと、
    を含み、
    前記現在庫情報は入荷待ちデータを含み、前記輸送中情報は、複数の輸送中ユニットの場所を含むことを特徴とする方法。
41. １つのユニットを１つの宛先に進路変更するための進路変更指示を運送業者に送信するステップを含み、
    この進路変更指示は、前記進路変更計画に基づく１つの宛先に対応する宛先ＩＤと、１つのユニットを運送業者の輸送手段上に１つのユニットを配置するのに十分な情報を含むコンテナＩＤとを含むことを特徴とする請求項４０に記載の方法。
42. 前記輸送手段とは、貨物船であることを特徴とする請求項４１に記載の方法。
43. 前記輸送手段とは、貨物列車であることを特徴とする請求項４１に記載の方法。
44. 前記輸送手段とは、陸上交通車両であることを特徴とする請求項４１に記載の方法。
45. 進路変更対象となる前記１つのユニットは、前記宛先の何れにも割り当てられなかったユニットであることを特徴とする請求項４１に記載の方法。
46. 輸送対象となる前記１つのユニットは、以前に１つの宛先を割り当てられたユニットであることを特徴とする請求項４１に記載の方法。
47. ネットワーク上にあるクライアントに到着予定時刻情報を提供する、ネットワーク上のシステムであって、
    製品番号を含む製品照会を促す１以上のページをクライアントに提供する手段と、
    製品照会を受け取る手段と、
    製品番号を有する少なくとも１つの輸送中のユニットが、複数の宛先に対する到着予定時刻を決定する手段と、
    決定した到着予定時刻を前記クライアントに送信する手段と、
    を備えたことを特徴とするシステム。
48. 少なくとも一つの宛先に進路変更するべき製品番号の、推奨される量のユニットを含む進路変更推奨情報を、前記クライアントに送信する手段と、
    前記進路変更推奨情報は、在庫情報と輸送中情報に基づいており、
    前記在庫情報は、少なくとも一つの宛先毎に販売履歴と入荷待ちデータとを含み、輸送中情報は、少なくとも一つの輸送中のユニットのそれぞれの位置を含むことを特徴とする請求項４７に記載のシステム。
49. 更に、運送業者ＩＤ、製品番号、数量、及び宛先ＩＤを含む製品進路変更要求をクライアントから引き出す１以上のページをクライアントに提供する手段と、
    前記製品進路変更要求を受け取る手段と、
    少なくとも１つの輸送中ユニットの１つを、前記宛先ＩＤに対応する最終宛先に、進路変更する手段と、
    を有することを特徴とする請求項４７に記載のシステム。
50. 在庫情報と輸送中情報とを処理する進路変更計画プロセッサの結果に基づいて、前記少なくとも一つの輸送中のユニットの１つを進路変更する手段を更に備え、
    前記在庫情報は、少なくとも１つの宛先の販売履歴と、少なくとも１つの宛先の入荷待ちデータとを含み、
    前記輸送中情報は、少なくとも１つの前記輸送中のユニットを搬送する少なくとも一つの輸送車両の場所を含むことを特徴とする請求項４９に記載のシステム。
51. 更に、最終的な宛先に進路変更されたその製品番号のユニットの製品番号と量とを含む、確認情報をクライアントに送信する手段を備えたことを特徴とする請求項４９に記載のシステム。
52. 輸送中のユニットの１つを最終的な宛先に進路変更する進路変更指示を、運送業者に与える手段を更に備え、
    前記進路変更指示は、宛先ＩＤと、運送業者の輸送手段に製品を配置するために十分な情報を含むコンテナＩＤと、を含むことを特徴とする請求項４９に記載のシステム。
53. 前記輸送手段とは、貨物船であることを特徴とする請求項５２に記載のシステム。
54. 前記輸送手段とは、貨物列車であることを特徴とする請求項５２に記載のシステム。
55. 前記輸送手段とは、陸上交通車両であることを特徴とする請求項５２に記載のシステム。
56. 進路変更対象となる前記輸送中のユニットは、前記宛先の何れにも割り当てられなかったものであることを特徴とする請求項４９に記載のシステム。
57. 前記輸送中のユニットは、かつて１つの宛先を割り当てられたことを特徴とする請求項４９に記載のシステム。
58. ネットワーク上のサーバから、到着予定時刻を取得するシステムであって、
    製品番号を含む製品問い合わせ情報をサーバに送信する手段と、
    製品番号を有する少なくとも１つの輸送中のユニットについて、複数の宛先への複数の到着予定時刻を受信する手段とを備えたことを特徴とするシステム。
59. 輸送手段ＩＤと、製品番号と、数量と、宛先ＩＤとを含む進路変更要求を前記サーバに送信する手段と、
    少なくとも１つの輸送中のユニットの１つを、前記宛先ＩＤに対応する最終的な宛先に進路変更したことを示す通知を、サーバから受け取る手段と、
    を更に含むことを特徴とする請求項５８に記載のシステム。
60. 製品番号、数量及び顧客ＩＤを含む製品購入オーダを、サーバに送信する手段と、
    前記製品購入オーダを受け付けたことを示す通知をサーバから受け取る手段と、
    を更に含み、
    前記サーバは、その製品番号の少なくとも１つの輸送中ユニットを、顧客ＩＤに基づく最終的な宛先に進路変更することを特徴とする請求項５８に記載のシステム。
61. 少なくとも１つの二次的な宛先からのオーダによる超過料金を含む超過運賃情報を提供するシステムであって、
    製品番号を含む製品照会を促す１以上のページをクライアントに提供する手段と、
    製品照会を受信する手段と、
    製品重量テーブルデータベースから、対応する製品重量を受信する手段と、
    ディーラ所在地データベースから、ディーラのアドレスを受信する手段と、
    運送料テーブルデータベースから、ディーラアドレスに基づいて、少なくとも１つの送料を受信する手段と、
    製品重量データベース、運送料データベース及びディーラ所在地データベースに格納された情報に基づいて、運賃における少なくとも１つの相違を計算する手段と、
    少なくとも１つの送料の違いをクライアントに送信する手段と、
    を含むことを特徴とするシステム。
62. 少なくとも１つの第２の倉庫からのオーダによる超過料金を含む超過運賃情報を、ネットワーク上のサーバから受け取るシステムであって、
    製品番号及び顧客ＩＤを含む製品照会情報をサーバに送信する手段と、
    少なくとも１つの二次的な宛先からのオーダのための送料の、少なくとも１つの違いを受信する手段と、
    を備えたことを特徴とするシステム。
63. 製品番号を有する複数の輸送中のユニットの１つを、複数の宛先に自動的に進路変更する、システムであって、
    複数の輸送中のユニットについて、複数の宛先のそれぞれへの到着予定時刻を決定する手段と、
    複数の宛先のそれぞれについての販売歴情報、それぞれの宛先についての現在庫情報、及び輸送中情報に基づいて、進路変更計画を決定する手段と、
    進路変更計画に基づいて、１つの宛先に対して１つのユニットを進路変更する手段と、
    を含み、
    前記現在庫情報は入荷待ちデータを含み、前記輸送中情報は、複数の輸送中ユニットの場所を含むことを特徴とするシステム。
64. １つのユニットを１つの宛先に進路変更するための進路変更指示を運送業者に送信する手段を更に含み、
    この進路変更指示は、前記進路変更計画に基づく１つの宛先に対応する宛先ＩＤと、１つのユニットを運送業者の輸送手段上に１つのユニットを配置するのに十分な情報を含むコンテナＩＤとを含むことを特徴とする請求項６３に記載のシステム。
65. 前記輸送手段とは、貨物船であることを特徴とする請求項６４に記載のシステム。
66. 前記輸送手段とは、貨物列車であることを特徴とする請求項６４に記載のシステム。
67. 前記輸送手段とは、陸上交通車両であることを特徴とする請求項６４に記載のシステム。
68. 進路変更対象となる前記１つのユニットは、前記宛先の何れにも割り当てられなかったユニットであることを特徴とする請求項６４に記載のシステム。
69. 輸送対象となる前記１つのユニットは、以前に１つの宛先を割り当てられたユニットであることを特徴とする請求項６４に記載のシステム。
70. ネットワーク上にあるクライアントに到着予定時刻情報を提供するコードを含むコンピュータ可読記憶媒体であって、
    製品番号を含む製品照会を促す１以上のページをクライアントに提供するステップと、
    製品照会を受け取るステップと、
    製品番号を有する少なくとも１つの輸送中のユニットが、複数の宛先に対する到着予定時刻を決定するステップと、
    決定した到着予定時刻を前記クライアントに送信するステップと、
    のコードを含むことを特徴とする記憶媒体。
71. 前記コードは、
    少なくとも一つの宛先に進路変更するべき製品番号の、推奨される量のユニットを含む進路変更推奨情報を、前記クライアントに送信するステップを更に有し、
    前記進路変更推奨情報は、在庫情報と輸送中情報に基づいており、
    現在庫情報は、少なくとも一つの宛先毎に販売履歴と入荷待ちデータとを含み、輸送中情報は、少なくとも一つの輸送中のユニットのそれぞれの位置を含むことを特徴とする請求項７０に記載の記憶媒体。
72. 前記コードは、
    更に、運送業者ＩＤ、製品番号、数量、及び宛先ＩＤを含む製品進路変更要求をクライアントから引き出す１以上のページをクライアントに提供するステップと、
    前記製品進路変更要求を受け取るステップと、
    少なくとも１つの輸送中ユニットの１つを、前記宛先ＩＤに対応する最終宛先に、進路変更するステップと、
    を更に実行させることを特徴とする請求項７０に記載の記憶媒体。
73. 在庫情報と輸送中情報とを処理する進路変更計画プロセッサの結果に基づいて、前記少なくとも一つの輸送中のユニットの１つを進路変更するステップのコードを更に含み、
    前記在庫情報は、少なくとも１つの宛先の販売履歴と、少なくとも１つの宛先の入荷待ちデータとを含み、
    前記輸送中情報は、少なくとも１つの前記輸送中のユニットを搬送する少なくとも一つの輸送車両の場所を含むことを特徴とする請求項７２に記載の記憶媒体。
74. 更に、最終的な宛先に進路変更されたその製品番号のユニットの製品番号と量とを含む、確認情報をクライアントに送信するコードを含むことを特徴とする請求項７０に記載の記憶媒体。
75. 輸送中のユニットの１つを最終的な宛先に進路変更する進路変更指示を、運送業者に与えるコードを更に含み、、
    前記進路変更指示は、宛先ＩＤと、運送業者の輸送手段に製品を配置するために十分な情報を含むコンテナＩＤと、を含むことを特徴とする請求項７０に記載の記憶媒体
    。
76. 前記輸送手段とは、貨物船であることを特徴とする請求項７５に記載の記憶媒体。
77. 前記輸送手段とは、貨物列車であることを特徴とする請求項７５に記載の記憶媒体。
78. 前記輸送手段とは、陸上交通車両であることを特徴とする請求項７５に記載の記憶媒体。
79. 進路変更対象となる前記輸送中のユニットは、前記宛先の何れにも割り当てられなかったユニットであることを特徴とする請求項７２に記載の記憶媒体。
80. 前記輸送中のユニットは、以前に１つの宛先を割り当てられたユニットであることを特徴とする請求項７２に記載の記憶媒体。
81. コードを含むコンピュータ可読記憶媒体であって、
    ネットワークを介してサーバにリンクするシステムであって、製品番号を含む製品問い合わせ情報をサーバに送信するコードと、
    製品番号を有する少なくとも１つの輸送中のユニットについて、複数の宛先への複数の到着予定時刻を受信するコードとを含むことを特徴とする記憶媒体。
82. 輸送手段ＩＤと、製品番号と、数量と、宛先ＩＤとを含む進路変更要求を前記サーバに送信するコードと、
    少なくとも１つの輸送中のユニットの１つを、前記宛先ＩＤに対応する最終的な宛先に進路変更したことを示す通知を、サーバから受け取るコードと、
    を更に含むことを特徴とする請求項８１に記載の記憶媒体。
83. 製品番号、数量及び顧客ＩＤを含む製品購入オーダを、サーバに送信するコードと、
    前記製品購入オーダを受け付けたことを示す通知をサーバから受け取るコードと、
    を更に含み、
    前記サーバは、その製品番号の少なくとも１つの輸送中ユニットを、顧客ＩＤに基づく最終的な宛先に進路変更することを特徴とする請求項８１に記載の記憶媒体。
84. 少なくとも１つの第２の倉庫からのオーダによる超過料金を含む超過運賃情報を提供するコードと、
    製品番号を含む製品照会を促す１以上のページをクライアントに提供するコードと、
    製品照会を受信するコードと、
    製品重量テーブルデータベースから、対応する製品重量を受信するコードと、
    ディーラ所在地データベースから、ディーラのアドレスを受信するコードと、
    運送料テーブルデータベースから、ディーラアドレスに基づいて、少なくとも１つの送料を受信するコードと、
    製品重量データベース、運送料データベース及びディーラ所在地データベースに格納された情報に基づいて、運賃における少なくとも１つの相違を計算するコードと、
    少なくとも１つの送料の違いをクライアントに送信するコードと、
    を含むことを特徴とするコンピュータ可読記憶媒体。
85. 少なくとも１つの二次的な宛先からのオーダによる超過料金を含む超過運賃情報を、ネットワーク上のサーバから受け取るコードと、
    製品番号及び顧客ＩＤを含む製品照会情報をサーバに送信するコードと、
    少なくとも１つの二次的な宛先からのオーダのための送料の、少なくとも１つの違いを受信するコードと、
    を含むことを特徴とするコンピュータ可読記憶媒体。
86. 製品番号を有する複数の輸送中のユニットの１つを、複数の宛先に自動的に進路変更するコードと、
    複数の輸送中のユニットについて、複数の宛先のそれぞれへの到着予定時刻を決定するコードと、
    複数の宛先のそれぞれについての販売歴情報、それぞれの倉庫についての現在庫情報、及び輸送中情報に基づいて、進路変更計画を決定するコードと、
    進路変更計画に基づいて、１つの宛先に対して１つのユニットを進路変更するコードと、
    を含み、
    前記現在庫情報は入荷待ちデータを含み、前記輸送中情報は、複数の輸送中ユニットの場所を含むことを特徴とするコンピュータ可読記憶媒体。
87. １つのユニットを１つの宛先に進路変更するための進路変更指示を運送業者に送信するコードを含み、
    この進路変更指示は、前記進路変更計画に基づく１つの宛先に対応する宛先ＩＤと、１つのユニットを運送業者の輸送手段上に１つのユニットを配置するのに十分な情報を含むコンテナＩＤとを含むことを特徴とする請求項８６に記載のコンピュータ可読記憶媒体。
88. 前記輸送手段とは、貨物船であることを特徴とする請求項８７に記載のコンピュータ可読記憶媒体。
89. 前記輸送手段とは、貨物列車であることを特徴とする請求項８７に記載のコンピュータ可読記憶媒体。
90. 前記輸送手段とは、陸上交通車両であることを特徴とする請求項８７に記載のコンピュータ可読記憶媒体。
91. 進路変更対象となる前記１つのユニットは、前記宛先の何れにも割り当てられなかったユニットであることを特徴とする請求項８７に記載のコンピュータ可読記憶媒体。
92. 輸送対象となる前記１つのユニットは、以前に１つの宛先を割り当てられたユニットであることを特徴とする請求項８７に記載のコンピュータ可読記憶媒体。

Images