(57)【要約】サプライチェーン管理システムは、商品の効率的な振り分けおよび出荷を促進する。利用者所在地を有する少なくとも１人の利用者は、少なくとも１人の取引業者と通信する。当該少なくとも１人の取引業者は、前記利用者に代わり、注文を出す。当該注文は、少なくとも１つの商品に対応する商品データと、前記利用者所在地に対応する所在地データとを含む。在庫確認エンジンは、前記少なくとも１人の取引業者および複数の倉庫と通信し、前記利用者所在地に対応する所在地データに部分的に基づいて前記複数の倉庫の中から出荷倉庫を特定する。当該出荷倉庫は、前記利用者所在地に最も近く、前記少なくとも１つの商品を前記少なくとも１人の利用者へ指定期間内に出荷可能な倉庫である。【特許請求の範囲】
【請求項１】
利用者所在地を有する少なくとも１人の利用者と、
少なくとも１つの品目に対応する品目データと前記利用者所在地に対応する所在地データとを含む注文を発生する、前記少なくとも１人の利用者に関連した少なくとも１人の取引業者と、
少なくとも１つの倉庫が少なくとも他の１つの倉庫と離れて存在し、各々が前記利用者所在地から地理的に距離を置いて存在する、複数の倉庫と、
前記少なくとも１人の取引業者および前記複数の倉庫と通信し、前記利用者所在地に対応する所在地データに部分的に基づいて前記複数の倉庫の中から出荷倉庫を特定する、在庫確認エンジンとを備え、
前記出荷倉庫は、前記利用者所在地に最も近く、前記少なくとも１つの品目を前記少なくとも１人の利用者へ指定期間内に出荷可能な倉庫である、品目の効率的な振り分けおよび出荷を促進するサプライチェーン管理システム。
【請求項２】
前記在庫確認エンジンは、前記複数の倉庫の中から、前記利用者所在地に最も近く、前記少なくとも１つの品目を前記少なくとも１人の利用者へ指定期間内に出荷可能な倉庫だけを、前記所在地データに部分的に基づき出荷倉庫として選択する、請求項１記載のシステム。
【請求項３】
前記出荷倉庫は、前記利用者所在地に最も近く、前記少なくとも１つの品目を在庫している倉庫である、請求項１記載のシステム。
【請求項４】
前記指定期間は、前記少なくとも１人の利用者が決定する、請求項１記載のシステム。
【請求項５】
前記少なくとも１人の取引業者は、前記複数の倉庫の少なくとも１つに、前記少なくとも１つの品目を供給する、請求項１記載のシステム。
【請求項６】
前記取引業者は、広域ネットワークを介して前記在庫確認エンジンと通信する、請求項１記載のシステム。
【請求項７】
前記所在地データは、郵便番号、州、区域、市、国の中から選択したデータである、請求項１記載のシステム。
【請求項８】
前記少なくとも１つの品目を前記少なくとも１人の利用者へ輸送するため、前記在庫確認エンジンに提携した輸送業者をさらに備える、請求項１記載のシステム。
【請求項９】
少なくとも１つの品目に対応する品目データと利用者所在地に対応する所在地データとを含む少なくとも１つの注文を発生し、
前記少なくとも１つの注文を調査し、前記利用者所在地に対応する所在地データに部分的に基づいて複数の倉庫の中から出荷倉庫を特定し、
前記出荷倉庫が前記少なくとも１つの品目を前記利用者へ出荷するための十分な在庫を有しているかを決定することを備える、品目の効率的な振り分けおよび出荷を促進する方法。
【請求項１０】
前記少なくとも１つの品目を前記利用者へ出荷するよう前記出荷倉庫に指示することをさらに備える、請求項９記載の方法。
【請求項１１】
前記出荷倉庫は、前記利用者所在地に最も近く、前記少なくとも１つの品目を前記少なくとも１人の利用者へ指定期間内に出荷可能な倉庫である、請求項１０記載の方法。
【請求項１２】
前記最も近い倉庫と前記利用者所在地との関係に基づき選択した前記出荷倉庫は、前記少なくとも１つの品目を前記少なくとも１人の利用者へ指定期間内に出荷可能である、請求項９記載の方法。
【請求項１３】
取引業者から在庫確認エンジンへ前記少なくとも１つの注文を送信し、前記在庫確認エンジンにおいて前記少なくとも１つの注文を調査することをさらに備える、請求項９記載の方法。
【請求項１４】
前記取引業者から前記在庫確認エンジンへの前記少なくとも１つの注文の送信は、インターネットを介する、請求項１３記載の方法。
【請求項１５】
前記品目データは、利用者出荷条件を含む、請求項９記載の方法。
【請求項１６】
前記利用者出荷条件は、配送日を含む、請求項１５記載の方法。
【請求項１７】
前記少なくとも１つの品目の出荷を前記利用者に通知応答することをさらに備える、請求項９記載の方法。
【請求項１８】
前記出荷倉庫は、品目出荷指示の受け取り順に品目を出荷する、請求項９記載の方法。
【発明の詳細な説明】
【０００１】
（関連出願）
本発明は、２０００年６月２９日出願の米国特許仮出願第６０／２１４，９１０号「リアルタイムサプライチェーン管理の方法、システム、およびコンピュータプログラム製品」について優先権を主張すると共に、その全内容を参照によって組み込む。
【０００２】
（技術分野）
本発明は、広くサプライチェーン管理システムに関し、さらに詳しくは注文を履行しサプライチェーンを管理するシステムにおいて、品目を効率的に振り分けて利用者に配送し、コスト効果を高めることに関する。
【０００３】
（背景技術）
従来から認識されてきたように、遠隔地間取引を行う企業にとって、効率的な配送システムは必須である。現在の一般的な遠隔取引は、例えば利用者とデパートとの間の電話カタログ注文である。このような小売りシステムを快適に円滑に行うには、利用者は注文能力を持たねばならず、小売業者は利用者に商品を送る機能を果たさねばならない。この機能を長年にわたって果たしてきたのが、配送システムであり、様々なレベルの成功や失敗を経験してきた。例えば、大型の従来企業が運営する自社配送システムは、大量の注文処理には適するが、頻度の低い少量の出荷には適さない。一方、より少ない注文を扱う例えばインターネット小売業者（電子小売業者）等の小さな企業は、配送に関する専門知識を持たないため、第三者の配送システムに頼っている。企業規模にかかわらず、あるいは商品の注文量や利用者への配送量にかかわらず、効率的で利益を生む遠隔取引を行う上で、１つの共通項は、倉庫から利用者への注文処理を効率化することである。
【０００４】
インターネットは、この５年間、遠隔取引を急増させた。今日の消費者は、インターネットに接続することで、ほぼあらゆる商品やサービスを世界中のどこへでも注文できる。小売業者は、インターネットを介して、電子店舗を創設し商品を宣伝できる。参入の障壁が低いため、インターネットには多数の中小企業が存在する。中小企業にとってインターネット参入の利点は、消費者から大量のアクセスを期待できることであり、消費者にとっては、煉瓦やモルタル造りの従来店舗から商品を購入するのと同じくらい簡単に、インターネット店舗にアクセスできることである。このようにインターネットは、あらゆる規模の企業に対し、消費者に製品を提示し販売する手段を提供する。しかしながらいずれの企業も、その規模に関わりなく、その製品をオンライン消費者へ出荷する手段を確立しなければならない。製品を消費者の手に渡す問題は、従来の店頭売り店舗にも電子店舗にも存在する。倉庫から消費者へ、すなわち遠隔地から消費者への物流問題は、どのような環境においても存在する。この物流問題は、特に電子商取引分野において大きい。その理由は、インターネットビジネスモデルに対する電子小売業者の経験が不足している上、大量の消費者がオンラインで商品を購入するからである。
【０００５】
中小企業は、競争力を維持するため、期限内に効率的に最小のコストで配送を行う必要がある。現在、この流通問題は、中小企業の成功にとって最大障壁の一つである。インターネット小売分野において、配送は必ずしも適時に行われていない。その理由は、インターネットウエブサイトを介して利用者が注文した商品に対し、それを出荷するための企業の配送基盤が無いからである。多くの企業が配送等の後方サービス（例えばクレジットカード処理）を提供し始めたため、電子小売業者は本来の業務に専念できるようになった。企業は、配送を外部に任せることで、社内配送に伴う従業員、倉庫設備保守、配送コスト等の間接費から解放される。
【０００６】
多くの第三者流通業者が、配送の解決策を小売業者に提供している。第三者流通業者のほとんどは、そのために設立した倉庫からの出荷を提供している。第三者流通業者は、当該流通業者に関係する輸送業者を使い、その倉庫から電子小売業者の商品を消費者へ輸送する。倉庫配送提供業者は、独自の効率基準を設け、商品の扱い時間を短縮し、商品出荷に伴うコストを最小にし、商品の紛失や盗難を減らす等のことを行っている。しかしながら倉庫は、輸送業者を介して商品を出荷することに関するコスト管理を怠っていることが多い。
【０００７】
倉庫管理および注文履行を企業に提供するシステムが求められている。すなわち、迅速に費用効果を高めて電子ビジネスを立ち上げるためのエンド・ツー・エンドサプライチェーン管理サービスシステムが求められている。このようなシステムは、中小規模のインターネット新規事業者ばかりでなく、インターネット配送に真剣に取り組みつつある従来の建物を構えた事業者にも有益である。かかるシステムが、複数の倉庫のうち消費者の近くに位置する１倉庫から、２日以内に全国の９０パーセントへ製品を輸送できれば、有益であり輸送コストを下げることができよう。かかるシステムは、消費者の所在地と倉庫の注文処理能力とに基づき、出荷倉庫を選択することになろう。
【０００８】
（発明の開示）
本発明のシステムは、製造業者、卸売業者、小売業者、販売業者等を含む取引業者のために、利用可能な在庫を確保する。そして利用者は、それら取引業者に対し、品目の引き合いや注文を行う。取引業者は、利用者からの引き合いを様々な形で受け取ることができる。例えば、取引業者が設定したウエブページ、専用ネットワーク等を介して送る標準電子データ交換フォーマット、その他取引業者が利用者とあらかじめ設定した媒体を利用できる。取引業者は、利用者と対話して利用者の希望を確認すると、在庫確認依頼または注文依頼を在庫確認エンジンへ送り、利用者が希望した品目の在庫がありそれを希望期日までに宛先住所へ配送できるかを決定する。在庫確認エンジンの役割は、利用者からの依頼を受け取って回答し、取引業者のために利用可能な在庫を確保し、１つまたはそれ以上の配送センタ（ここでは倉庫と呼ぶ）に対し、取引業者から受け取った注文を履行するよう指示することである。本発明の一形態において、在庫確認エンジンは、利用者所在地に対応する所在地データに部分的に基づき、複数の倉庫の中から出荷倉庫を特定する。この出荷倉庫は、利用者所在地に最も近く、少なくとも１つの品目を少なくとも１人の利用者へ指定期間内に出荷可能な倉庫である。このように本発明システムは、品目を確保し、最も適した１つまたはそれ以上の倉庫からその品目を利用者へ確実に配送する。
【０００９】
本発明の一実施例は、商品（あるいは品目と呼ぶ）の効率的振り分けおよび配送を促進するサプライチェーン管理システムを開示する。このサプライチェーン管理システムは、利用者所在地を有する少なくとも１人の利用者と、少なくとも１人の取引業者とを含む。この取引業者は、前記少なくとも１人の利用者に関連しており、少なくとも１つの品目に対応する品目データと前記利用者所在地に対応する所在地データとを含む注文を発生する。前記システムは、複数の倉庫をさらに含む。これら倉庫は、少なくとも１つが少なくとも他の１つと離れて存在し、各々が前記利用者所在地から地理的に距離を置いて存在する。前記システムは、在庫確認エンジンをさらに含む。この在庫確認エンジンは、前記少なくとも１人の取引業者および前記複数の倉庫と通信し、前記利用者所在地に対応する所在地データに部分的に基づき、前記複数の倉庫の中から出荷倉庫を特定する。本サプライチェーン管理システムにおいて、前記出荷倉庫とは、前記利用者所在地に最も近く、前記少なくとも１つの品目を前記少なくとも１人の利用者へ指定期間内に出荷可能な倉庫である。
【００１０】
本発明の一態様において、前記在庫確認エンジンは、前記複数の倉庫の中から、前記利用者所在地に最も近く、前記少なくとも１つの品目を前記少なくとも１人の利用者へ指定期間内に出荷可能な倉庫だけを、前記所在地データに部分的に基づいて出荷倉庫として選択する。本発明の別の態様において、前記指定期間は、前記少なくとも１人の利用者が決定する。本発明のさらに別の態様において、前記出荷倉庫は、前記利用者所在地に最も近く、前記少なくとも１つの品目を在庫している倉庫である。前記所在地データは、郵便番号、州、区域、市、国の中から選択する。一般に前記在庫確認エンジンは、前記少なくとも１つの品目を前記少なくとも１人の利用者へ輸送するための１またはそれ以上の輸送業者に関連付ける。本発明のさらに別の態様において、前記少なくとも１人の取引業者は、前記複数の倉庫の少なくとも１つに、前記少なくとも１つの品目を供給する。また前記取引業者は、広域ネットワークを介して前記在庫確認エンジンと通信する。
【００１１】
本発明の別の実施例は、品目の効率的な振り分けおよび出荷を促進する方法を開示する。この方法は、少なくとも１つの品目に対応する品目データと利用者所在地に対応する所在地データとを含む少なくとも１つの注文を発生し、前記少なくとも１つの注文を調査し、前記利用者所在地に対応する所在地データに部分的に基づいて複数の倉庫の中から出荷倉庫を特定し、前記出荷倉庫が前記少なくとも１つの品目を前記利用者へ出荷するための十分な在庫を有しているかを決定することを含む。
【００１２】
本発明の一態様において、前記方法は、前記少なくとも１つの品目を前記利用者へ出荷するよう前記出荷倉庫に指示することをさらに含む。前記出荷倉庫は、前記利用者所在地に最も近く、前記少なくとも１つの品目を前記少なくとも１人の利用者へ指定期間内に出荷可能な倉庫である。あるいは前記出荷倉庫は、前記最も近い倉庫と前記利用者所在地との関係に基づき、前記少なくとも１つの品目を前記少なくとも１人の利用者へ指定期間内に出荷可能である倉庫として選択する。
【００１３】
本発明の別の態様において、前記方法は、取引業者から在庫確認エンジンへ前記少なくとも１つの注文を送信し、前記在庫確認エンジンにおいて前記少なくとも１つの注文を調査することを含んでも良い。前記取引業者から前記在庫確認エンジンへの前記少なくとも１つの注文の送信は、インターネットを介しても良い。本発明のさらに別の態様において、前記品目データは、配送日、所望配送タイプ等の利用者出荷条件を含むことができる。利用者が少なくとも１つの注文を送った後、前記方法は、前記少なくとも１つの品目が出荷されることを前記利用者に通知応答することを含んでも良い。最後に、前記出荷倉庫は、先入れ先出し方式を用いることができる。すなわち、品目出荷指示の受け取り順に品目を出荷することができる。
【００１４】
本発明の他の特徴および利点は、添付図面および詳細説明を参照することにより、当業者に明らかとなろう。これら特徴および利点は、請求項に記載した本発明範囲に含まれると理解すべきである。
【００１５】
（発明を実施するための最良の形態）
以上に概要を説明した本発明につき、添付図面を参照しながら詳細に説明する。これら図面は、必ずしも正確な縮尺を示していない。
【００１６】
添付図面を参照しながら本発明をより詳細に説明する。添付図面は、本発明の好適実施例を示している。しかしながら本発明は、他の多くの形態でも実施可能であり、以下の実施例に限定されるものではない。むしろこれら実施例は、本開示を完全にするために提供するものであり、当業者に本発明の範囲を遺漏なく提供することを意図している。全図面において同一番号は同一要素を示す。
【００１７】
当業者には明らかな通り、本発明は方法、データ処理システム、あるいはコンピュータプログラム製品として実施しても良い。従って本発明は、ハードウエアだけの実施形態、ソフトウエアだけの実施形態、あるいはソフトウエアとハードウエアの組合せによる実施形態を取ることができる。さらに本発明は、コンピュータ読み取り可能記録媒体上のコンピュータプログラム製品でも良い。この記録媒体は、コンピュータ読み取り可能プログラムコード手段を含む。さらに本発明は、ウエブで実行するコンピュータソフトウエアの形態を取ることもできる。使用可能なコンピュータ読み取り可能記録媒体は、ハードディスク、ＣＤ−ＲＯＭ、光学的記録装置、磁気的記録装置を含む。
【００１８】
以下において、ブロック図およびフローチャートを参照しながら、本発明の実施例に基づくシステム、装置、およびコンピュータプログラム製品を説明する。これらブロック図およびフローチャートにおける各ブロックおよびブロックの組合せは、コンピュータプログラム命令によって実現可能である。このようなコンピュータプログラム命令は、汎用コンピュータ、特定用途コンピュータ、あるいは他のプログラム可能データ処理装置にロードし、コンピュータ等において前記フローチャートのブロックに記載した機能を実行する手段を形成する。
【００１９】
これらコンピュータプログラム命令は、コンピュータ読み取り可能メモリに格納し、コンピュータあるいは他のプログラム可能データ処理装置を特定の方法で機能させることができる。例えば、コンピュータ読み取り可能メモリに格納した命令は、フローチャートの各ブロックに記載した機能を実現する命令手段を含む製品を形成できる。またコンピュータプログラム命令は、コンピュータあるいは他のプログラム可能データ処理装置にロードし、当該コンピュータあるいは他のプログラム可能データ処理装置において一連の動作ステップを実行してコンピュータ処理を形成し、フローチャートの各ブロックに記載した機能を遂行するステップを提供する。
【００２０】
従ってブロック図およびフローチャートの各ブロックは、指定機能を実行する手段の組合せと、指定機能を実行するステップの組合せと、指定機能を実行するプログラム命令手段とを支援する。ブロック図およびフローチャートの各ブロックおよびそれらの組合せは、指定機能またはステップを実行する特定目的ハードウエアに基づくコンピュータシステム、あるいは特定目的ハードウエアとコンピュータ命令との組合せによって実現できる。
【００２１】
図１を参照すると、本発明のサプライチェーン管理システム１００は、利用者１１０からの品目に関する引き合いや注文（一括して依頼とも呼ぶ）の受け取りを促進する。これら品目は、在庫確認エンジン１３０に関係した輸送業者（図示せず）が利用者１１０へ配送する。利用者は、取引業者１２０と対話し、品目の注文または引き合いを行う。取引業者１２０は、利用者の引き合いや注文に関する依頼を、利用者に代わって在庫確認エンジン１３０へ送る。在庫確認エンジン１３０は、利用者からの依頼を受け取りそれに応答する。例えば、利用可能な在庫を取引業者のために確保し、１つまたはそれ以上の倉庫に取引業者１２０から受け取った注文を履行するよう指示する。このようにシステム１００は、品目の確保、その品目出荷に最適な１つまたはそれ以上の倉庫から利用者１１０への品目配送等を可能にする。
【００２２】
取引業者１２０は、様々な方法で利用者からの引き合いを受け取る。その方法は、取引業者が設定したウエブページ、専用ネットワーク等を経由する標準電子データ交換フォーマット、取引業者が利用者に対してあらかじめ準備する他の媒体などを利用する。取引業者１２０は、利用者１１０と対話して利用者の希望を確認すると、在庫確認依頼または注文依頼を在庫確認エンジン１３０へ送り、利用者が求める品目の在庫はあるか、その品目を希望期日までに希望地へ配送できるか、を確認する。在庫確認依頼および注文依頼の詳細は後述する。図１に示すように、取引業者１２０は、ウエブインタフェース１４０を介して在庫確認エンジン１３０と直接通信するか、バッチ・オーダ・シンギュレータ１５０を経由して通信する。
【００２３】
ウエブインタフェース１４０は、少なくとも１つの取引業者ウエブページを含むことが好ましい。それにより、利用者１１０または取引業者１２０は、利用者１１０への品目配送を依頼でき、詳細を後述するように、在庫確認エンジン１３０に対し、品目の暫定期間だけの確保または振り分けを依頼できる。例えば、インターネット小売環境において、ウエブインタフェース１４０は、インターネット小売業者が設定するインターネットウエブページを含むことができる。それを通じて利用者は、１つまたはそれ以上の購入品目の配送を依頼できる。当業者には明らかな通り、ウエブインタフェース１４０はサーバを含み、少なくとも１つの販売業者ウエブページとの通信を確立するようにできる。ウエブインタフェース１４０は、拡張マークアップ言語（ＸＭＬ）フォーマットにおいて通信を受信することが好ましい。しかしながらウエブインタフェース１４０は、取引業者１２０からの引き合いおよび注文を識別するデータを、それに適した様々なフォーマットで受け取る可能性がある。ただしシステム１００の好適実施例においては、ＸＭＬを使用する。なぜならＸＭＬは、非構造化データレコードの送信に、とりわけ有用であり、非構造化データレコードはシステム１００の好適フォーマットだからである。本発明の一態様において、在庫確認エンジン１３０は、データの送受信をＸＭＬフォーマットで行う。従って在庫確認エンジン１３０からの応答は、ＸＭＬフォーマットである。このデータフォーマットは、複合データレコードの形でデータをウエブインタフェース１４０へ送ることができ、複数の引き合いや注文を識別するデータ、利用者識別情報、宛先情報、希望配送日等を含むことができる。このデータは、１つまたはそれ以上の注文に関連させることができ、各注文は１つまたは複数のラインによりデータレコードを構成する。
【００２４】
取引業者の依頼は、ウエブインタフェース１４０を介してリアルタイムに受信することも、あるいはバッチ・オーダ・シンギュレータ１５０を経由して受信することもできる。またその依頼は、様々なフォーマットで受信する可能性がある。例えば、カンマ区切り値を有する電子データ交換（ＥＤＩ）フォーマットである。ウエブインタフェース１４０は、依頼を受信すると、それをＸＭＬ文書（受信した注文のフォーマットに関わりなく）に変換する。依頼のＸＭＬフォーマットへの変換およびＸＭＬフォーマットした依頼は、当業者に良く知られているため、その詳細は省略する。この変換により、在庫確認エンジン１３０は、取引業者１２０が提供する依頼フォーマットに関係なく、ＸＭＬフォーマットした依頼のみを受信する。
【００２５】
図１に示すように、取引業者１２０は、直接リンク１４５またはバッチ・オーダ・シンギュレータ１５０を経由して在庫確認エンジン１３０と通信することもできる。取引業者は、直接リンク１４５を経由して在庫確認エンジン１３０と通信する場合、広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、専用線、従来のダイヤルアップ接続、あるいは当業者に良く知られた方法を使う。本発明の一態様において、取引業者から在庫確認エンジン１３０への直接通信は、ＸＭＬフォーマットで行うことが好ましい。このフォーマットは、複合データレコードを送信するのに都合がよい。また在庫確認エンジン１３０から取引業者１２０への直接リンク１４５を経由する通信も、ＸＭＬフォーマット（図１にはＸＭＬ応答と示した）で行うことが好ましい。これにより、取引業者や在庫確認エンジンは、変換ソフトウエアを省略できる。さもないと、ウエブインタフェース１４０またはバッチ・オーダ・シンギュレータ１５０を経由する通信は、変換ソフトウエアを使用しなければならない。しかしながら、当業者に良く知られた他のフォーマットを利用して、直接リンク１４５経由のデータ送信を行っても良い。
【００２６】
直接リンク１４５を経由して在庫確認エンジン１３０へ送信するデータは、前記実施例においてウエブインタフェース１４０を経由して在庫確認エンジン１３０へ送信したデータと同じ内容を有する。しかしながらウエブインタフェース１４０から在庫確認エンジン１３０への通信は、厳格なハイパー転送テキストプロトコルであるのに対し、直接リンク１４５を経由する通信は、当業者に公知のファイル転送プロトコル（ＦＴＰ）の形式を取る。販売業者と在庫確認エンジン１３０との間で直接リンク１４５を使用する場合、インターネット通信に頼る必要はない。インターネット通信は、インターネットサービスプロバイダ（ＩＳＰ）を必要とする上、直接通信よりも信頼性が低い。従って直接リンク１４５は、インターネット、広域ネットワーク等の接続が利用できない時、望ましいものである。しかしながら直接リンク１４５は、快適なグラフィカルユーザインタフェースや常時接続を提供できないことがある。また、在庫確認エンジン１３０がＸＭＬ等の指定フォーマットにおける通信を必要とする場合、取引業者１２０または在庫確認エンジン１３０は、すべての通信をＸＭＬフォーマットに変換しなければならない。この機能は、前記実施例の場合、ウエブインタフェース１４０が提供できる。
【００２７】
取引業者１２０が在庫確認エンジン１３０と通信するための第３の方法は、バッチ・オーダ・シンギュレータ１５０を経由することである。このバッチ・オーダ・シンギュレータ１５０は、取引業者１２０と在庫確認エンジン１３０との間の通信路に位置する。従ってバッチ・オーダ・シンギュレータ１５０は、ＬＡＮ、ＷＡＮ等に配置でき、取引業者１２０および在庫確認エンジン１３０の一方または両方に配置できる。バッチ・オーダ・シンギュレータ１５０の目的は、取引業者が在庫確認エンジン１３０に対し、複数の品目の出荷をひとまとめにして同時依頼した時、その依頼を識別し分離することである。従って取引業者１２０が複数の依頼を在庫確認エンジン１３０へ送る場合、それらはバッチ・オーダ・シンギュレータを経由して在庫確認エンジン１３０へ送ることが好ましい。バッチ・オーダ・シンギュレータ１５０は、在庫確認エンジン１３０から取引業者１２０への応答をそのまま送ったり、在庫確認エンジン１３０から複数のＸＭＬ応答を集め、それらを一つにまとめて取引業者１２０へ送ることもできる。当業者には明らかな通り、バッチ・オーダ・シンギュレータ１５０の機能は、取引業者１２０または在庫確認エンジン１３０が実行しても良い。また、ウエブインタフェース１４０は、インターネット経由で在庫確認エンジン１３０へ送る依頼に関し、バッチ・オーダ・シンギュレータと同様の機能を実行しても良い。また、バッチ・オーダ・シンギュレータを経由して取引業者１２０から在庫確認エンジン１３０へ送る依頼は、在庫確認エンジン１３０から取引業者１２０への応答を発生する。この応答は、前記方法のいずれを経由しても良い。例えば直接リンク１４５やウエブインタフェース１４０を経由できる。
【００２８】
前記したように、在庫確認エンジン１３０は、利用者からの依頼を受け取りそれに応答し、取引業者のために利用可能在庫を確保し、１つまたはそれ以上の倉庫に対して取引業者１２０からの依頼を実行するよう指示する。さらに詳しくは、在庫確認エンジン１３０は、在庫確認依頼および注文依頼を受け取り、利用者が依頼した品目が在庫しているかを確認し、それを希望期日までに宛先住所へ配送できるかを決定する。在庫確認依頼は、在庫確認エンジン１３０からの確認を求めるものであり、品目があるか、それを利用者へ出荷できるか、利用者や取引業者の配送条件を満たすか、について確認を求めるものである。在庫確認依頼は、取引業者を拘束するものではない。在庫確認エンジン１３０は、予定期間に関して品目を予約するが、出荷倉庫に対して利用者への品目出荷は指示しない。在庫確認エンジン１３０は、予約期間が過ぎると、出荷倉庫に対し、品目の予約がもはや必要ないことを知らせる。
【００２９】
注文依頼は、在庫確認依頼と似ている。しかしながら在庫確認エンジン１３０は、その注文が履行可能であればそれを履行する。在庫確認エンジン１３０は、注文依頼を履行可能であると応答した場合、注文品を供給する義務がある。ただし利用者または取引業者が、その注文に関わる品目の出荷開始前にその依頼を変更した時はその限りでない。従って在庫確認エンジン１３０は、利用者あるいは取引業者の配送条件を遵守できる場合、出荷倉庫に対して注文履行を指示する。
【００３０】
在庫確認依頼および注文依頼は、同一の汎用フォーマットを有し、同一データを有する。ただし注文依頼は、その注文依頼に先行する在庫確認に関する識別子を含むことができる。これにより、在庫確認依頼の後に続く注文依頼は、配送条件や品目に関して注文依頼と先行在庫確認依頼との間に変更がなければ、データ再送の必要がない。在庫確認エンジン１３０は、依頼識別データ、例えば依頼に関連付けたフラグによって依頼の性質（在庫確認か注文か）を識別できる。１つの依頼は、品目、品目の数量、利用者位置データ、配送オプション、配送日、利用者郵便番号、住所、取引業者識別コード等の注文に関する代表的なデータを含む。１つの依頼は、複数の品目を含むことができる。この場合、各品目は、対応する配送日および宛先を含む。利用者は、所在地を入力しなければならない。システムがそれを必要とするからである。すなわち所在地は、発注の際、在庫確認エンジン１３０が依頼品目の出荷倉庫を決定するために必要である。
【００３１】
依頼は、品目および住所に対応するデータに加え、所望の付加価値サービス（ＶＡＳ）を識別するデータを含んでも良い。付加価値サービスは、例えば贈答用包装紙である。このデータは、依頼品目データと共に、在庫確認エンジン１３０へ送る必要がある。在庫確認エンジン１３０は、そのデータを確認すると、在庫を調べると共に、実際の品目と贈答用包装紙とを処理できるか確認する。注文が複数の品目を含み、その一部だけが贈答用包装を求めることもある。この場合、贈答用包装を必要とする品目だけを、贈答用包装紙付き出荷セット（出荷製品グループ）に含め、在庫確認エンジン１３０は、その条件を満たせる倉庫を選択する。挿入広告やカタログのように、注文には含むものの、在庫チェックや履行能力チェックに関係しない付加価値サービスもある。このようなタイプのサービスは、数量不足だったり、それらを同梱する能力がなくとも、注文品出荷には支障を来さない。かかるサービスは、注文に乗せておき、注文の履行段階（倉庫）で挿入すればよい。
【００３２】
図１のシステム１００を再び参照すると、在庫確認エンジン１３０は、ＡＰＳ（高度計画スケジューリング）アプリケーション１６０との組合せで実現する。このＡＰＳアプリケーションは、注文履行システム１００において、在庫・注文管理、売掛金追跡、および高度計画スケジューリングを提供する。在庫確認エンジン１３０は、ＡＰＳアプリケーション１６０の機能を内蔵してもよい。この場合、独立したＡＰＳアプリケーション１６０は必要ない。しかしながら本発明の好適実施例は、従来のＡＰＳアプリケーション１６０を使用することに力点を置く。本発明の一態様において、ＡＰＳアプリケーション１６０は、オレクルＩＩｉ（登録商標）ＡＰＳアプリケーションであり、システム１００が必要とする多くの機能を提供する。これら機能は、広域納期回答（ＡＴＰ）と高度サプライチェーン計画とを含む。これらは当業者に公知の機能である。ＡＰＳアプリケーションは、追加の機能を支援することもできる。例えば、需要計画、製造スケジューリングであるが、これらは本発明の好適実施例にとって必須ではない。
【００３３】
ＡＰＳアプリケーション１６０の広域納期回答機能（ＧＡＴＰ）は、広域納期回答アプリケーションまたはサーバを含むことができ、特定時点のシステム在庫状況を解釈するためのデータベース呼び出しを管理し、特定時点においてシステム１００が確認可能な全在庫のスナップショットを保持する。従って在庫確認エンジン１３０は、広域納期回答機能に問い合わせ、倉庫在庫状況を確認する。供給在庫等に関するデータの更新は、データベースアプリケーション１７０からＡＰＳアプリケーション１６０へ提供する。このデータベースアプリケーション１７０は、従来の既製品で良く、例えばオレクル８Ｉ（登録商標）データベースアプリケーションである。さらに、１つまたはそれ以上のコアモジュールを用いることもできる。例えば、在庫および注文管理アプリケーションを用いても良い。データベースアプリケーション１７０は、倉庫レベルで存在する１つまたはそれ以上のデータベース１８０に基づき、広域納期回答の在庫を更新する。各倉庫は、倉庫管理システム１９０を有する。この倉庫管理システムは、注文の受け取り、履行、および確認応答を行い、倉庫に関連する１つまたはそれ以上のデータベース１９０を更新する。ＡＰＳアプリケーションの広域納期回答機能（またはアプリケーション）は、データベースアプリケーション１７０の機能を使い、オープン注文（未実施の注文）とクローズド注文（出荷した注文）の全体像を、倉庫管理システム１９０からの出荷確認に基づいて保守する。このようにＡＰＳアプリケーション１６０は、需要供給情報の格納場所として単純に機能する。
【００３４】
前記したように、在庫確認エンジン１３０は、システム１００の頭脳部であり、広域納期回答機能に問い合わせ、システム１００が特定品目の出荷を特定日に特定倉庫から行えるかを決定する。注文の場合、在庫確認エンジン１３０は、利用者の所在地に基づいて各倉庫の在庫を調べるが、その詳細は後述する。在庫確認エンジン１３０は、広域納期回答機能から回答を受け取ると、その回答を調べ、１つの倉庫によって注文を履行できるかを決定する。それができなければ、在庫確認エンジンは、別の倉庫がそれを履行できるかを決定する。そして在庫確認エンジン１３０は、図３に示すように、利用者からの依頼に対しＸＭＬ応答を返す。利用者からの依頼が注文依頼であり、ある倉庫がその注文を履行可能であれば、在庫確認エンジン１３０は、ＡＰＳアプリケーション１６０を介して倉庫管理システム１９０に命令を出し、注文品目を出荷させる。
【００３５】
図２は、図１のシステムで説明した本発明に基づく在庫確認エンジンの一実施例２３０を示すブロック図である。在庫確認エンジン２３０は、プロセッサ２６０と、記憶装置２８０と、メモリ２４０と、入出力装置２７０と、ネットワークインタフェース２９０とを備える。在庫確認エンジンプロセッサ２６０内の各要素は、バス２１０を介して互いに通信する。ネットワークインタフェース２９０は、在庫確認エンジン２３０がコンピュータネットワークの他の要素とインタフェースし通信することを可能にする。コンピュータネットワークとは、例えばＷＡＮ、ＬＡＮ、ＰＳＴＮ，パケット交換ネットワーク、インターネット等、既知のハードウエアを使用するものである。
【００３６】
メモリ２４０は、オペレーティングシステム２５０と、在庫確認エンジン制御モジュール２２０とを含む。在庫確認エンジン制御モジュール２２０は、在庫確認エンジンの動作を制御するためのソフトウエアを備える。この詳細は、図３〜５を参照して後述する。在庫確認エンジン制御モジュール２２０は、オペレーティングシステム２５０とプロセッサ２６０とに支援されて動作する。このオペレーティングシステムは、公知のもので良く、例えばウインドウズＮＴであり、在庫確認エンジン制御モジュール２２０の命令を実行し、在庫確認エンジン制御モジュール２２０と他の在庫確認エンジン要素や在庫確認エンジン２３０の外部にあって在庫確認エンジン２３０と通信するネットワーク要素との間の通信をネットワークインタフェース２９０を介して支援する。
【００３７】
記憶装置２８０は、少なくとも１つの記憶装置を代表し、例えばハードディスク装置、フロッピーディスク装置、ＣＤ−ＲＯＭ装置、光ディスク装置であり、様々なコンピュータ読み取り可能媒体に情報を格納する。これら媒体は例えば、ハードディスク、取り出し可能磁気ディスク、ＣＤ−ＲＯＭ等である。記憶装置２８０およびそれに関連するコンピュータ読み取り可能媒体は、不揮発性記憶を在庫確認エンジンに提供する。ここで重要なことは、コンピュータ読み取り可能媒体は、当業者に公知の他のタイプのコンピュータ読み取り可能媒体に置き換えることができることである。このような媒体は、例えば磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌイカートリッジである。
【００３８】
当業者には明らかな通り、１つまたはそれ以上の在庫確認エンジン２３０の構成部品を互いに離れた場所に設置することもできる。また、１つまたはそれ以上のそれら構成部品を組み合わせたり、本明細書に記載の機能を実行する追加部品を在庫確認エンジン２３０に含めることも可能である。
【００３９】
図３を参照すると、取引業者３２０が在庫確認依頼（ＲＦＰ）３４０を在庫確認エンジン３３０へ送ると、特定配送日について品目の確認が始まる。在庫確認依頼３４０は、依頼品目の利用可能性を評価するために必要な情報を含む。例えば、１つまたはそれ以上の依頼品目に対応する品目データ、利用者の所在地に対応する位置データ、配送条件、および当該依頼を処理するために必要な他のデータを含む。品目が利用可能であり、配送オプションを考慮した上で希望配送日までに取引業者の利用者にその品目を供給可能であれば、在庫確認エンジン３３０は、確認３５０を取引業者３２０へ返信する。確認３５０は、品目の仮予約である。取引業者は、依頼条件および関連する確認条件を決定（確約）したければ、注文依頼（ＲＦＯ）３６０を在庫確認エンジン３３０へ送る。注文依頼３６０は、取引業者が依頼条件を遵守する意思を表明するものである。この注文依頼３６０は識別子を有し、それに基づいて在庫確認エンジンは注文依頼３６０と先行確認３５０とを結び付けることができる。この識別子により在庫確認エンジン３３０は、先行在庫確認依頼から取引業者が求めた品目を特定できるので、同じ情報を在庫確認エンジン３３０に対して再送しないでよい。在庫確認エンジン３３０は、注文依頼３６０と確認３５０とを結び付けると、確約３７０を取引業者へ送り、取引を完了し、取引業者と在庫確認エンジン３３０との双方を注文依頼３６０の条件に拘束する。注文依頼を送信しなければ、確認は期限切れとなり、在庫確認エンジン３３０は拘束されない。
【００４０】
図４に示すように、取引業者４２０は、先に在庫確認依頼を送ることなく、注文依頼４６０を在庫確認エンジン４３０へ送ることもできる。この場合、取引業者４２０は、在庫確認エンジン４３０が受諾すれば、注文依頼４６０の条件を確約する。当然ながら対応する先行確認はないので、在庫確認エンジン４３０は、品目の利用可能性を決定することを始める。在庫確認エンジン４３０は、注文依頼４６０通りの品目が利用可能であれば、確約４７０を取引業者４２０へ送り、取引業者と在庫確認エンジンとの双方を注文依頼４２０の条件を遵守するように拘束する。すなわち注文が確定する。
【００４１】
図４の流れは、図３において確認が期限切れになった場合の注文依頼処理と似ている。この場合、先行する在庫確認依頼が無かったものとして、注文依頼４６０を処理する。そして品目が利用可能であれば、注文を確定し、確約４７０を取引業者へ返す。在庫確認エンジン４３０は、先行確認の識別子を伴っていながら先行在庫確認依頼とは異なる条件を有する注文依頼を受け取った場合、先行確認が存在しなかったものとして図４のように利用可能性を決定する。しかしながら在庫確認エンジン４３０は、前記識別子を利用して取引を識別できれば、注文依頼に対して、取引識別の新たな送信を求めない。このため図４に示す処理フローは、図３における最後の２ステップのフロートは異なる場合がある。その理由は、図３のフローの場合、期限切れとなった在庫確認に対応する注文依頼は識別子を含むからである。
【００４２】
図５Ａは、本発明の好適実施例に基づく在庫確認エンジンの基本規則を示す。この規則に基づき在庫確認エンジンは、配送システムの中から依頼履行倉庫を決定する。在庫確認エンジン１３０は、取引業者から依頼を受け取ると、まずその依頼を調査し、利用者に最も近い倉庫を決定する（ブロック５００）。在庫確認エンジン１３０、すなわち在庫確認エンジン制御モジュール２２０は、最も近い倉庫を決定するにあたり、在庫確認エンジンが保持する配送ネットワークデータを調べ、前記依頼の利用者所在地データに地理的に最も近い倉庫を決定する。このため前記配送ネットワークデータは、各倉庫の位置情報を有する。このデータは、在庫確認エンジンの記憶装置２８０、あるいは在庫確認エンジン制御モジュール２２０に格納する。在庫確認エンジン１３０は、利用者所在地に最も近い倉庫を主倉庫と指定し、その倉庫から依頼品目を出荷するものとする。なぜなら主倉庫は、利用者所在地に最も近く、品目を利用者へ輸送する際のコストが最低と見込まれるからである。在庫確認エンジン１３０は、主倉庫を決定すると、その主倉庫に関連付けると共に順番付けした２次倉庫のリストを参照（探索）する（ブロック５０５）。これら２次倉庫は、依頼の宛先住所に関わりなく優先順位を有し、主倉庫に続いてリストアップされている。２次倉庫は、主倉庫からの距離に基づいて優先順位が決まる。すなわち２次倉庫は、必ずしも宛先住所に最も近いわけではなく、主倉庫に対する位置に依存して優先順位が決まる。
【００４３】
在庫確認エンジン制御モジュール２２０は、倉庫リストを決定すると、最も近い倉庫（主倉庫）が依頼を履行できるかを決定する（ブロック５１０）。在庫確認エンジン１３０は、この決定にあたり、ＡＰＳアプリケーション１６０と通信する。このアプリケーションは、システム内の各倉庫の最新在庫を保持している。すなわち在庫確認エンジンは、ＡＰＳアプリケーションに問い合わせ、主倉庫は依頼条件を満たせるか、例えば依頼品目を有するか、利用者または取引業者が指定する輸送条件を満たせるか、その他依頼条件を満たせるかを検討する。ＡＰＳアプリケーションは、在庫確認エンジンの質問に対応するデータを返し、在庫確認エンジンは、主倉庫が依頼を履行できるかを決定する。履行できるなら、主倉庫を依頼履行倉庫として選択する（ブロック５５０）。
【００４４】
主倉庫が依頼を履行できない場合、在庫確認エンジン１３０は、主倉庫に関連する別の倉庫があるかを決定する（ブロック５１５）。一般にシステム内の全倉庫は、個々のリストにおいて他の倉庫に関係付けられており、そのリストにおいては各倉庫が主倉庫となっている。また各倉庫は、主倉庫に近いものから遠いものへと順位が付いている。在庫確認エンジン１３０は、最も近い倉庫が依頼を履行できるかを決定した後、主倉庫に関連した倉庫のリストだけを参照しても良い。この場合、図５Ａのフローチャートにおけるブロック５０５は、ブロック５１０と５１５との間に入る。依頼を履行できる倉庫がなければ、在庫確認エンジンは、そのことを利用者あるいは取引業者に知らせる（ブロック５４０）。在庫確認エンジン１３０は、注文の履行を必要に応じて２つまたはそれ以上の倉庫に分割し、１つの倉庫で履行できなかった依頼の履行を試みても良い。この詳細は後述する。あるいは在庫確認エンジン１３０は、前記ステップを繰り返し、次の倉庫が依頼を履行できるかを決定する（ブロック５２０，５２５，５３０）。一連の処理を続行して倉庫を選択する（ブロック５５０）か、あるいはいずれの倉庫も依頼を履行できない（ブロック５４０）。図５Ａのフローチャートは、在庫確認エンジンが各倉庫の依頼履行能力を順次決定することにより、依頼履行倉庫決定における処理量を減らしている。これとは逆に、在庫確認エンジンは、全倉庫に対して同時に情報を求めても良い。この場合、１つの依頼をＡＰＳアプリケーションへ送るだけである。そして在庫確認エンジンは、ＡＰＳアプリケーションからの応答を前記したような方法で処理する。
【００４５】
図５Ｂは、本発明の別の実施例に基づく、在庫確認エンジンの別の規則を示す。この規則に基づき在庫確認エンジンは、依頼を履行する倉庫を配送システム内に探す。この実施例が図５Ａの実施例と異なるのは、在庫確認エンジンが常に利用者に最も近い倉庫を利用して各依頼を履行しようとすることである。図５Ａのブロック５００と同様、利用者に最も近い倉庫（主倉庫）を決定すると（ブロック５５２）、在庫確認エンジンは、図５Ａのブロック５１０のように、主倉庫が依頼を履行できるかを決定する（ブロック５５５）。履行できれば、その倉庫を選択する（ブロック５８０）。履行できなければ、在庫確認エンジンは、依頼を履行できる倉庫で利用者に次に近い倉庫を決定する。これは図５Ａの処理と異なる。なぜなら在庫確認エンジンは、次に近い倉庫を決定するにあたり、互いからの距離を記載した倉庫リストを保持する配送ネットワークデータを参照しない。問い合わせ可能な倉庫が存在する限りこの処理を続ける（ブロック５６０，５６５，５７０）。そしてどの倉庫も依頼を履行できないか（ブロック５７５）、あるいは１つの履行できる倉庫を選択する（ブロック５８０）。
【００４６】
図５Ｃは、４つの倉庫の位置と２つの利用者の位置とを示すブロック図である。これら利用者は、配送システム５００を介して品目を求める。本図は、第１倉庫（Ａ）５８６と、第２倉庫（Ｂ）５８８と、第３倉庫（Ｃ）５９０と、第４倉庫（Ｄ）５９２とを示す。図において倉庫Ａ５８６は、倉庫Ｂ５８８よりも倉庫Ｃ５９０に近く、地理的にＢよりもＣに近いことを示す。図において、第１利用者５９６は第１所在地にあり、第２利用者５９４は第２所在地にある。図５Ｃは、図５Ａおよび５Ｂとは別の処理を示す。
【００４７】
図５Ａの処理に基づき、第１利用者５９６および第２利用者５９４からの依頼は、両利用者５９６，５９４に関連する取引業者から在庫確認エンジンへ送る。これら依頼に基づき、在庫確認エンジンは、可能であれば倉庫Ａ５８６を利用して両依頼を履行することを決定する。その理由は、当該倉庫が第１利用者５９６および第２利用者５９４に地理的に最も近いからである。以下に示す仮定表１を参照し、倉庫Ａ５８６を主倉庫と決定した場合、２次倉庫は、第１利用者の所在地にかかわらず、倉庫Ｃ５９０，Ｂ５８８，Ｄ５９２の順である。これは、Ｃ５９０がＢ５８８およびＤ５９２よりもＡ５８６に近く、Ｄ５９２がＡ５８６から最も遠いからである。倉庫Ｃ５９０は、第１依頼に関しては次に近い倉庫であるが、第２依頼に関してはそうではない。第２依頼に関しては、Ｃ５９０よりもＢ５８８の方が近い。このため倉庫Ａ５８６が両依頼を履行できず、倉庫Ｃ５９０およびＢ５８８のいずれもが両依頼を履行できる場合、在庫確認エンジン、すなわち在庫確認エンジン制御モジュールは、倉庫Ｃ５９０に対して両依頼を履行するよう指示する。これは、表１に示す配送ネットワークデータおいて、倉庫Ｃ５９０が２次倉庫だからである。本例は、各倉庫について１つの遡上規則を設け、合計４つの異なる遡上規則がある。すなわち常にシステムの倉庫の数だけ遡上規則がある。
【００４８】
【表１】
2004501851.tif 000002
在庫確認エンジンは、図５Ａの処理を使用する場合、まず利用可能な最も近い倉庫から依頼を履行しようとする。次に、あらかじめ設定した地理的関係を使用し、依頼履行倉庫を探す順番を決定する。この処理は、処理エンジンの処理を最小にするので、図５Ｂの処理よりも好ましい。
【００４９】
図５Ｂの処理は、異なる結果を導く。図５Ｂの処理は、常に利用者に最も近い倉庫を探すため、倉庫Ａ５８６が両依頼（第１利用者からの依頼と第２利用者からの依頼）を履行できない場合、第１利用者の依頼は倉庫Ｃ５９０で履行し、第２利用者の依頼は倉庫Ｂ５８８で履行しようとする（先の例ではＣ５９０が履行）。ただし倉庫Ｂ５８８およびＣ５９０が依頼を履行できることが条件である。このように在庫確認エンジンは、利用者に最も近い倉庫は最低の輸送コストを有するという前提、および結果導出処理に関わりなく次に近い倉庫を常に選択するという前提で動作する。
【００５０】
Ａ．依頼タイプ
在庫確認エンジン１３０への依頼は、在庫確認依頼と注文依頼であると説明した。さらに詳細には、取引業者が在庫確認または注文のために行う依頼には、４つのタイプがある。すなわち非拘束、日付拘束、サービス拘束、および至急（サービス拘束の例外）である。これらは、１つまたはそれ以上の依頼品目に対応する品目データ、輸送条件、あるいは処理用追加データによって指定する。在庫確認エンジン制御モジュール２２０は、これら４つの依頼タイプの全てについて、前記した在庫確認規則を実行する。しかしながら各依頼タイプ用に個別の規則も存在する。これら規則も在庫確認エンジン制御モジュール２２０が管理する。
【００５１】
一般に非拘束、日付拘束、およびサービス拘束は、標準タイプの注文または依頼である。これら依頼または注文は、倉庫の標準処理能力を使用し、以下に詳述する標準的手順に従う。在庫確認エンジン１３０が受け取る注文または依頼は、至急の指定がない限り、標準タイプ（既定）の注文と見なす。標準タイプの注文または依頼は、特別に至急注文として在庫確認エンジン１３０へ送らない限り、決して至急注文としての確認はしない。言い換えれば、在庫確認エンジン１３０は、標準依頼手順から特別依頼手順へ切り替わらない。この詳細は、至急注文に関連して説明する。
【００５２】
標準依頼を識別するため、１つの標準処理項目を生成し、それを全ての倉庫において標準タイプの注文に対して有効にする。在庫確認エンジン１３０は、ＡＰＳアプリケーションに対して最初の問い合わせを行うに当たり、１つの標準処理項目を標準タイプの注文の各品目に添付する。この標準処理項目は、各倉庫において一意の供給形態を有し、全ての標準タイプの注文に使用される。在庫確認エンジン１３０は、標準処理項目が添付されていれば、至急（プレミアムサービス）注文との明示がない限り、既定の標準タイプ注文であると理解する。このタイプの注文は、それが標準タイプの注文であることを示すために、それ以上のパラメータを必要としない。
【００５３】
一方、至急注文は、特別注文であり、サービス拘束注文または依頼の特別な形である。至急注文は、独自の倉庫短縮時間と供給処理（詳細は後述）とを有する。至急注文または至急依頼は、取引業者あるいは利用者の輸送条件によって定義し、在庫確認エンジン１３０に対して、輸送業者による翌日配送サービスおよび倉庫によるプレミアム扱いサービスを使って出荷することを求める。他の全ての注文および依頼は、標準タイプ注文が既定値である（すなわち依頼が単に翌日配送サービスとして入力された場合、それは標準タイプ注文である）。在庫確認エンジン制御モジュール２２０の規則は、利用者は依頼を至急とする前にまず標準タイプの翌日配送サービスとするであろうと推定する。なぜならその方が同一サービスをより低いコストで受けられるからである。利用者は、その依頼が標準タイプとして履行不可能であり、プレミアムを支払う用意があれば、在庫確認エンジン１３０から依頼履行不可の応答を受け取った後、その依頼を至急注文として再送信できる。本発明の一態様において、至急注文または至急依頼の指定は、翌日配送を保証するものではない。十分な処理能力または在庫が無ければ、たとえ至急注文であってもそれを受諾することはできない。
【００５４】
ある依頼が至急であることを識別するため、１つの至急処理項目を形成し、全倉庫において至急タイプの注文に対して有効にする。在庫確認エンジン１３０、すなわち在庫確認エンジン制御モジュール２２０は、至急処理項目（または識別子）を至急注文の各品目に添付してから、ＡＰＳアプリケーションに最初の問い合わせを行い、その依頼を確認または履行するために利用可能な倉庫を決定する。在庫確認エンジン１３０は、至急処理項目を添付すべき注文を判断できる。取引業者は、そのような注文に対し、翌日配送サービスおよびプレミアムサービスを指定する。従って、そのような指定のある注文は、至急注文として定義する。単に翌日配送サービスとのみ指定したものは、既定値として標準タイプサービスに設定し、標準処理項目を添付する。
【００５５】
Ｂ．在庫確認および在庫確認限界
在庫確認エンジン１３０は、倉庫内に物理的に存在し出荷可能な在庫だけを確認（確約）する。従って取引業者に返信する在庫確認は、利用可能な在庫および処理能力に基づいており、利用可能在庫は倉庫が実際に所有する在庫を含む。しかしながら在庫確認エンジン１３０は、取引業者１２０が設定する標準リードタイムに対する在庫も確認することができる。ただし取引業者１２０がそれを容認することが条件である。取引業者がリードタイムを設定する場合、不定の供給量が想定される。なぜなら在庫確認エンジン１３０は、供給チャネルへの見通しを持たないからである。また在庫確認エンジン１３０は、在庫確認限界を供給チェーンまで拡大し、倉庫への輸送段階や他の段階にある品目についても在庫確認できる。この場合、事前出荷通知等を品目利用可能性の指標として頼ることになる。従って、本発明の一態様における在庫確認エンジン１３０は、事前出荷通知（ＡＳＮ）および購入注文（ＰＯ）を正当な在庫と見なしても良い。注文確約用の購入注文とは、当該倉庫へ搬入される品目に対する購入注文のことである。このような購入注文は、取引業者が所有し処理するものである。さらに在庫確認エンジン１３０は、再確認機能を使用することもできる。これは、出荷品目を格納し検品した後、利用可能条件が変化したら（例えば品目確認後の破損や紛失）、依頼を再確認することである。
【００５６】
在庫確認エンジン１３０は、注文履行の優先付けや最適化を行わない。ただし至急注文は別である。これは前記した通りであるが、詳細は後述する。標準タイプの依頼は、一般に先入れ先出し（ＦＩＦＯ）方式で処理する。つまり在庫確認エンジン１３０は、受け取り順に注文を予約し、利用者の身元や同一利用者による別注文を考慮しない。例えば、第１利用者が１０個の品目を注文し、その直後に第２利用者が百万個の品目を注文したとする。この場合、在庫確認エンジン１３０は、ちょうど１００万個の品目が在庫していても、１０個の注文を先に履行する。従って第２利用者の注文は、その規模が大きいからと言って（あるいはより好ましい利用者だからと言って）第１利用者の注文を横取りしない。在庫確認エンジン１３０は、第１利用者の注文を履行し、第２注文を確約しない。しかしながら在庫確認エンジン１３０は、取引業者が複数配送を認め、第２利用者が希望すれば、残余の在庫を第２利用者へ出荷できる。もちろん在庫確認エンジン１３０は、前述の通り、取引業者が注文品の出荷を可能にするようなリードタイムを提示すれば、第２注文の全品目を確約できる。
【００５７】
Ｃ．倉庫の依頼履行可否を決定するための在庫確認エンジン規則
在庫確認エンジン１３０、すなわち在庫確認エンジン制御モジュール２４０は、多くの規則を有し、それを用いて取引業者の依頼履行可否を決定する。その時在庫確認エンジン１３０は、ＡＰＳアプリケーション１６０、正確にはＡＰＳアプリケーション１６０の広域納期回答機能（ＧＡＴＰ）から送られるデータを参照する。前記したように、広域納期回答機能は、各倉庫の品目状況を保持し、各倉庫が各品目を特定日までに出荷できるか否かを保持する。この広域納期回答機能による検索は、在庫確認エンジン１３０からＡＰＳアプリケーション１６０への問い合わせであり、在庫確認エンジン１３０は、在庫と倉庫処理能力とを依頼し、倉庫が取引業者の依頼を履行できるか否かを決定する。
【００５８】
在庫確認エンジン制御モジュール２４０は、多くの前提条件を設定し、ＡＰＳアプリケーション１６０に問い合わせを行い、広域納期回答機能による検索を行い、依頼を履行しようとする。第１に、在庫確認エンジン１３０は、一括出荷は主倉庫からの調達より優先するとの前提条件を設定する。すなわち在庫確認エンジン１３０は、注文全体を主倉庫において履行しようとする。そして注文全体をその倉庫において履行できなければ、注文全体を２次倉庫で履行しようとする。たとえ主倉庫において品目の一部が利用可能であっても、他の全ての倉庫において注文の一括履行を調べ終えるまでは、注文を分割しない。第２に、至急注文については、翌日配送が一括出荷より優先する。言い換えれば、一括出荷を維持するために出荷を遅らせるより、出荷をいくつかの倉庫に分割して翌日配送することの方が好ましい。
【００５９】
第３に、日付拘束注文については、期日通りの配送が一括出荷より優先する。言い換えれば、一括出荷を維持するために出荷を遅らせるより、出荷をいくつかの倉庫に分割して注文品を希望配送日に配送することの方が好ましい。第４に、日付拘束注文については、一括出荷注文用の最も安い配送サービスレベルを維持することが、主倉庫から調達することより優先する。しかしながらこれは、サービスレベルが既に決まっているサービス拘束依頼および至急依頼には適用しない。言い換えれば、在庫確認エンジン１３０は、最も安い配送サービスを使って主倉庫から一括で依頼を履行しようとする。主倉庫がその依頼を約束できなければ、最も安い配送サービスを使用する２次倉庫を見つける。最も安い配送サービスを使用する全ての倉庫において依頼を一括で履行できるものが見つからなければ、主倉庫を優先させる。そして再び２次倉庫へ移る前に、注文のサービス種別に関わりなく、主倉庫においてその注文を一括で履行しようとする。この時、最も安いサービスの検索が失敗した後であるから、主倉庫におけるどのようなサービスも、２次倉庫におけるどのようなサービスより優先させる。
【００６０】
第５に、納期回答のための検索は、いずれの依頼タイプに対しても、依頼に関係する在庫品目と処理能力品目とを検索する。在庫品目または処理能力品目を１つの出荷依頼に結び付ける場合、納期回答検索は、同一日および同一倉庫において両方を満足しなければならない。しかしならが、１つの依頼を複数の日付または倉庫に分割することも可能である。１つの依頼（単一品目または複数品目）を分割する必要がある場合、出荷セットの比率を維持する必要がある。さらに在庫確認エンジン１３０は、複数倉庫にわたる複数出荷、および同一倉庫における複数日付の出荷を認識できなければならない。最大分割数を設定し、一つの倉庫からの出荷数を制限する必要もあろう。
【００６１】
第６に、在庫確認エンジン１３０は、在庫は累積的（使われなかった在庫は翌日に繰り越し可能）だが処理能力はそうではない、との前提に基づく。この前提の下で、在庫は、複数の日付において複数の数量が検索される。そして最新在庫検索日あるいはその日以降において、その在庫を単一または複数の出荷に使用できる。この場合、出荷日となるその最新在庫検索日において、全量の処理能力が利用可能であることを確認する必要がある。「出荷日」の例を挙げる。日付「ｎ」において主倉庫の在庫が利用可能であり、日付「ｎ＋１」において主倉庫における処理能力が利用可能である場合、出荷日は日付「ｎ＋１」である。
【００６２】
Ｄ．在庫確認評価の実行
出荷セット（すなわち出荷する品目のグループ）をＡＰＳアプリケーション１６０の広域納期回答機能アプリケーション（またはサーバ）へ送る前に、全品目を希望出荷日に主倉庫から出荷できるかを調べる。出荷セット全体を希望出荷日に主倉庫から出荷できるなら、数量および日付を回答する。依頼の全てを希望日付に主倉庫において処理できれば、それが最適回答であるから、検索を続行する必要はない。供給限界内のある日付において主倉庫に全量が見つからなければ、広域納期回答機能は、調達規則に定義した２次倉庫の各々を探索する。各倉庫を探して全量を見つけることができなければ、その全量は、主倉庫から標準リードタイムの日付において不定供給として利用可能となる。
【００６３】
例えば、主倉庫において、注文の５０％を希望出荷日に準備でき、注文の１０％を希望出荷日から５日間毎日準備できれば、広域納期回答機能は、１００％を第５日（最終日）に準備可能と回答する。他の例を挙げると、希望日には０％しか準備できず、１００％を標準リードタイム内のある日に準備可能であれば、回答は、ある１日と数量との組合せである。ある１日とは、依頼を満足できる最終日、あるいは累積数量が希望数量となって利用可能になる日である。依頼を満足できる日付と部分数量との組合せは、納期回答機能の需要供給像から取得できる。
【００６４】
日付と部分数量との組合せによっても、主倉庫が出荷セットを一括で満足できず、１つの２次倉庫においても全量を満足できなければ、不定リードタイム供給バケットにおけるある日付と数量とを有する回答となる。注文の一部が指定日にまたは標準リードタイム内に満足できても、不定供給バケットに入れる。しかしながら、取引業者が分割出荷を認めれば、在庫確認エンジン１３０は、倉庫および日付にわたって出荷セットを分割し、依頼に応えようとする。リードタイムバケット内における日付および部分数量の組合せは、納期回答機能の需要供給像から取得できよう。
【００６５】
在庫確認エンジン１３０は、取引業者が分割出荷を認めるなら、納期回答機能の需要供給像から取得できるデータ（回答には含めない）があれば、それを利用して分割出荷を決定する。在庫確認エンジン１３０の特有の論理および選択処理を、各依頼フロー毎に説明する。在庫確認エンジン１３０は、許可された最大出荷数「２ｎ＋１」に基づき、分割数量を選択する。ここで「ｎ」は、当該依頼に使用する調達規則における倉庫数である。在庫確認エンジン１３０は、需要供給像を使って利用可能分割数量を決定する時、まず調達規則が定義するいずれかの倉庫から出荷セットを一括で満足しようとする。在庫確認エンジン１３０は、出荷セットをリードタイム内に一括出荷できない場合、取引業者が認めれば、出荷を分割する。この時、在庫確認エンジン１３０は、必要に応じて優先順位の高い倉庫から順に希望日および数量を提示し、各倉庫から供給限度日における利用可能累積数量を集め、最後に残量を主倉庫（最高優先順位）に対し不定出荷として要求する。
【００６６】
依頼の全てが希望日において主倉庫に見つかれば、納期回答機能は終了する。それが最適回答だからである。依頼の全てが希望日において主倉庫に見つからなければ、主倉庫および２次倉庫の各々に対して納期回答検索を続行する。２次倉庫は、調達規則に基づき広域納期回答機能にあらかじめ定義し設定する。調達規則は、納期回答機能に対し、２次倉庫の検索順序を知らせる。この検索は、主倉庫に関連して説明した検索と同様である。主倉庫が（またはいずれかの倉庫が）全量を満たせば、検索は終了する。在庫確認エンジン１３０は、可能な全ての回答を求めると動作が重くなるため、それをしない。この在庫確認エンジン１３０の機能の詳細は、個々の依頼フローに関連して後述する。
【００６７】
Ｅ．依頼タイプ別の在庫確認フロー
４つの依頼タイプ（非拘束、日付拘束、サービス拘束、サービス拘束の特殊ケースである至急）の各々について説明する。在庫確認エンジンは、詳細を既に説明したように、処理しようとする依頼のタイプを知っており、その依頼タイプに基づいて広域納期回答機能アプリケーションへ渡す希望出荷日を決定する。
【００６８】
１．非拘束依頼
非拘束タイプの依頼は、期日やサービスレベルを指定しない。在庫確認エンジンは、希望出荷日を当日とし、午後３時（または他の所定時間）で注文の受諾を締め切る。時間に余裕を持たせ、最終発送前にシステムが注文を入手し、在庫確認を行い、注文を作成し、処理できるようにすることが好ましい。倉庫およびタイムゾーン毎に独自の締め切り時間を設けることができる。各倉庫は、異なる締め切り時間を持つことができる。
【００６９】
２．サービス拘束依頼
サービスレベルで拘束するタイプの依頼は、所望の配送サービス（翌日配送や地上輸送等）を有する。この場合、在庫確認エンジンは、希望出荷日を当日にする。すなわち午後３時（または他の所定時間）の締め切り時間に基づき、注文を受け付ける。時間に余裕を持たせ、最終配送前にシステムが注文を受け取り、確認し、作成し、処理できるようにすることが好ましい。倉庫毎、タイムゾーン毎に異なる締め切り時間を設定できる。従って各倉庫は、異なる締め切り時間を持つことができる。
【００７０】
サービス拘束依頼に関する前提として、取引業者は配送に適したサービスレベルを送信し、システムはそれを正しいと見なす。例えば、品目が空輸してはならない危険物であれば、取引業者は適正な輸送方法をシステムに指示するものとし、システムはそれに依存する。サービス拘束依頼は、重量および体積の確認を伴わない。
【００７１】
３．日付拘束依頼
日付拘束タイプの依頼は、それが在庫確認エンジンに到着した時点で、輸送業者を明示しなければならない。すなわち、その依頼について取引業者が利用する輸送業者は、本発明の在庫確認エンジンおよびシステムに関係した輸送業者、例えばユナイテッドパーセルサービス社（ＵＰＳ）であるか否かを、在庫確認エンジンに明示しなければならない。取引業者が例えばＵＰＳ等の本システムに関係する輸送業者を利用する場合、その輸送業者に希望配送日を提示する。例えば、利用可能な最も安いサービスが陸送であり、その輸送期間が５日間であり、希望配送日が依頼受領後３日であれば、その最も安いサービスを選択できない。従って在庫確認エンジン１３０は、それを考慮して配送ネットワークを呼び出し、検索を開始する必要がある。使用する希望出荷日は、当日である。一方、本システムに提携していない輸送業者を使用する場合、在庫確認エンジン１３０は、希望配送日をその輸送業者に提示せず、取引業者からの出荷日を依頼しなければならない。
【００７２】
４．至急依頼
依頼タイプが至急注文であれば、取引業者または利用者は、その注文品を翌日に受け取るため、プレミアムを支払う。取引業者は、システムに対し、翌日（一夜）サービスおよびプレミアム扱いサービスの依頼を送る。プレミアム扱いサービスによる至急注文は、他の全ての通常タイプ注文から区別される。全ての至急注文には、至急処理能力が必要である。至急処理能力は、標準の倉庫締め切り時間を超えた時間帯であり、その倉庫の至急締め切り時間に対応する。例えば、ある倉庫の通常の営業時間が午前７時から午後３時であれば、その倉庫の標準能力は、１日８時間である（または１日に処理する通常注文「ｘ」個）。至急締め切り時間が午後７時であれば、至急処理能力は午後３時から午後７時までの１日４時間、または１日あたり至急注文「Ｘ」個の処理能力である。至急依頼は、常に至急処理能力に当てはめる。処理能力状況を綿密に監視し、必要に応じて、一般処理能力と至急処理能力とを手動で移動できるようにする。
【００７３】
本発明の一態様において、１日に受諾できる至急注文数（至急処理能力）に上限を設ける。この最大限度を超えた場合、依頼を拒否する。至急注文専用の締め切り時間を設定し、システムは、その時間内においてその倉庫の標準締め切り時間を超えて至急注文を受け入れる。至急注文は、手持ち在庫に対してだけ在庫確認を行い、事前出荷通知または購入注文については在庫確認しない。手持ち在庫がなければ、確認をしない、あるいは在庫無しの確認を回答する。これは、広域納期回答機能における標準機能ではないため、在庫確認エンジンにおいて実行する必要がある。
【００７４】
Ｆ．在庫確認エンジンの注文管理機能
注文管理処理は、注文作成、注文変更、注文キャンセル、繰り越し注文処理を含む。販売注文は、対話方式あるいは非対話方式にかかわらず、取引業者から受け取り、在庫確認エンジンへ渡す。在庫確認エンジン１３０は、在庫確認に対応する販売注文を有効にし、注文管理システム（ＯＭＳ）へ渡す。注文管理システムは、その注文を倉庫管理システム１９０へ送って履行させる。注文管理システムは、図１のシステム１００には示していないが、従来の既製品でも良い。あるいはシステム構成部品の一部としてシステム１００に含めても良い。注文管理システムを使用すれば、取引業者から受け取る販売注文の処理のほとんどを自動化できる。
【００７５】
本明細書および添付図面から利益を受ける当業者には明らかな通り、本発明は多くの変更や別実施例が可能である。従って本発明は、開示した特定の実施例に制限されるものではなく、その請求範囲は多くの変更や別実施例を包含すると理解すべきである。本明細書に使用した特定用語は、包括的および記述的にのみ使用しており、限定的であることを意図していない。
【図面の簡単な説明】
【図１】
本発明の一実施例に基づくシステムを示すブロック図である。
【図２】
本発明の一実施例に基づく在庫確認エンジンを示すブロック図である。
【図３】
本発明の一態様に基づく、取引業者と在庫確認エンジンとの間の通信処理フローを示す図である。
【図４】
本発明の別の態様に基づく、取引業者と在庫確認エンジンとの間の通信処理を示す図である。
【図５Ａ】
本発明の好適実施例に基づく倉庫決定規則を示すフローチャートであり、この規則に基づいて在庫確認エンジンは、配送システムの中から依頼履行倉庫を選択する。
【図５Ｂ】
本発明の別の実施例に基づく倉庫決定規則を示すフローチャートであり、この規則に基づいて在庫確認エンジンは、配送システムの中から依頼履行倉庫を選択する。
【図５Ｃ】
本発明の一例として、本発明のシステムを利用して商品を依頼する２人の利用者の位置と、４つの倉庫の位置とを示す図である。
【図１】
2004501851.tif 000003
【図２】
2004501851.tif 000004
【図３】
2004501851.tif 000005
【図４】
2004501851.tif 000006
【図５Ａ】
2004501851.tif 000007
【図５Ｂ】
2004501851.tif 000008
【図５Ｃ】
2004501851.tif 000009
【国際公開パンフレット】
2004501851.tif 000010
2004501851.tif 000011
2004501851.tif 000012
2004501851.tif 000013
2004501851.tif 000014
2004501851.tif 000015
2004501851.tif 000016
2004501851.tif 000017
2004501851.tif 000018
2004501851.tif 000019
2004501851.tif 000020
2004501851.tif 000021
2004501851.tif 000022
2004501851.tif 000023
2004501851.tif 000024
2004501851.tif 000025
2004501851.tif 000026
2004501851.tif 000027
2004501851.tif 000028
2004501851.tif 000029
2004501851.tif 000030
2004501851.tif 000031
2004501851.tif 000032
2004501851.tif 000033
2004501851.tif 000034
2004501851.tif 000035
2004501851.tif 000036
2004501851.tif 000037
2004501851.tif 000038
2004501851.tif 000039
2004501851.tif 000040
2004501851.tif 000041
2004501851.tif 000042
2004501851.tif 000043
2004501851.tif 000044
2004501851.tif 000045
2004501851.tif 000046
2004501851.tif 000047
2004501851.tif 000048
2004501851.tif 000049
【国際公開パンフレット（コレクトバージョン）】
2004501851.tif 000050
2004501851.tif 000051
2004501851.tif 000052