米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> ヒューレット・パッカード・カンパニー

発明の名称 注文処理方法と注文履行処理システム
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2001−134677(P2001−134677A)
公開日 平成13年5月18日(2001.5.18)
出願番号 特願2000−321291(P2000−321291)
出願日 平成12年10月20日(2000.10.20)
代理人 【識別番号】100078053
【弁理士】
【氏名又は名称】上野 英夫
発明者 カロル・エル・ヘニング / メロディ・ピーターズ / ゲイリー・ブラント / カロリン・エム・ニッケイ / エリック・プライス / マージィ・スラデク
要約 目的


構成
特許請求の範囲
【請求項1】製品に対し顧客が行った注文を処理する方法であって、前記顧客注文が、少なくとも1つのサーバを介してネットワークにより複数のサプライヤに動作可能に接続された少なくとも1つのクライアントによって受取られる方法において、前記クライアントが、好適なサプライヤについて注文イベントを作成するステップと、前記サーバが、前記好適なサプライヤに前記注文イベントをルーティングするステップと、前記サーバが、前記好適なサプライヤからの前記注文イベントの状態を監視するステップと、前記好適なサプライヤが前記注文イベントを処理するステップと、前記サーバが、上記ステップとは無関係に前記クライアントと前記複数のサプライヤとの間で在庫を周期的に同期させるステップと、を含むことを特徴とする注文処理方法。
【請求項2】少なくとも1つのクライアントにより顧客が行った注文を履行するシステムであって、前記顧客注文が,少なくとも1つのサーバを介してネットワークにより複数のサプライヤに動作可能に接続された少なくとも1つのクライアントによって受取られるシステムにおいて、前記クライアントにおいて好ましいサプライヤについて注文イベントを作成する手段と、前記好適なサプライヤに該注文イベントをルーティングする手段と、前記好適なサプライヤからの該注文イベントの状態を監視する手段と、該注文イベントを処理する手段と、前記クライアントと前記複数のサプライヤとの間で在庫を周期的に同期させる手段と、を具備することを特徴とするシステム。
発明の詳細な説明
【0001】
【発明の属する技術分野】本発明は、一般に、複数の製品のうちのいずれかに対し顧客が行った注文を処理する方法およびシステムに関する。より詳細には、本発明は、大規模ネットワークを介してサーバに接続された1つまたは複数のクライアントコンピュータと、顧客注文の受領から購入された製品の引渡しおよび代金の請求までの必要なすべてのステップを通して、顧客が行った注文を事実上自動的に処理する複数のサプライヤコンピュータと、を有する方法およびシステムに関する。
【0002】
【従来の技術】最も知られた従来からの顧客注文調達プロセスは、概して、複雑な内部分配システムと、ウェアハウス(倉庫)プロセスと、調達プロセスと、顧客注文配置システムと、を含み、在庫水準を予測する機能は含んでいてもいなくてもよい。これらプロセスの大半は、少なくとも部分的には、かなり人間の介入を伴って行われるため、マニュアルで行われる。人間の介入は、効率が悪く、コストがかかり、時間もかかる。これらプロセスの中には、顧客の注文の受領から出荷の時間まで数日かかるものもある。
【0003】かかる複雑なマニュアルによる調達プロセスのうちの種々のステップにおいて、人間の介入を低減しようとする、コンピュータが実現するシステムがある。しかしながら、それらのアーキテクチャおよび方法論は不十分であり、処理中のある時点でマニュアルによる介入を必要とするため、完全に成功はしていない。例えば、大量の注文の処理に現在使用されている周知のコンピュータが実現するシステムには、最初に注文を受取りそれをシステム内に配置する際に人間の介入を必要とするものがある。しかしながら、顧客の注文を履行するためにサプライヤによって購入注文を配置するためにも、人間の介入が必要とされる。更に、サプライヤから注文された製品を受取り、それをウェアハウス(倉庫)に配置し、その後それを顧客に出荷するために人間の介入が必要である場合がある。人間の介入が必要である処理の各時点において、追加の非効率性、費用および時間の遅延がもたらされる。
【0004】
【発明が解決しようとする課題】従って、製品に対し顧客が行った注文を、注文がシステムに入力された時に注文された製品の引渡しまで自動的かつ効率的に処理する改良された方法および装置を提供することが本発明の第1の目的である。
【0005】本発明の関連する目的は、従来からの分配システム、ウェアハウス(倉庫)プロセスおよび調達処理の使用と、在庫水準の予測の必要と、を効率的にバイパスするようにして、顧客注文を処理することができるアーキテクチャおよび方法論を有する、かかる改良された方法およびシステムを提供することである。
【0006】本発明の他の目的は、インターネット等の大規模ネットワークを用いて世界的な規模で動作することができる、完全に自動化されたエンド・ツー・エンドのサプライチェインまたは顧客注文履行処理を生成するための改良された方法およびシステムを提供することである。
【0007】本発明の更に他の目的は、すべて人間の介入無しに、顧客注文を受取り、注文された製品を引渡すサプライヤを決定し、直ちに製品を出荷し顧客に代金を請求することにより注文を処理し、すべてのサプライヤの入手可能な在庫を周期的に同期させるよう設計された、かかる改良された方法およびシステムを提供することである。
【0008】本発明の更に他の目的は、小規模の企業と同様に大規模な多国籍会社によって使用される、かかる改良された方法およびシステムであって、そのシステムの利点に、(i)製品の引渡しおよび製品に対する代金の請求を通して顧客注文を処理するために必要な人間の数を実質的に低減することと、(ii)製品の引渡しおよび代金の請求を通してかかる顧客注文を処理するスピードを実質的に上昇させることと、(iii)かかる処理に関連する総コストを実質的に低減することと、が含まれる、方法およびシステムを提供することである。
【0009】
【課題を解決するための手段】本発明は、大規模な多国籍会社または小規模の会社によって市場に出される多くの製品に対し顧客が行う注文を処理する方法およびシステムに関する。本方法およびシステムは、顧客注文をその受領から製品の引渡しおよび代金の請求を通して処理する。
【0010】より詳細には、本方法およびシステムは、インターネット等の大規模ネットワークを介してサーバおよび複数のサプライヤコンピュータに接続された1つまたは複数のクライアントコンピュータを利用して、世界的ベースで顧客が行う注文を履行するよう適応されている。クライアントコンピュータとサプライヤコンピュータは、アクティビティのボリュームに応じて、パーソナルコンピュータ、ミニコンピュータ、メインフレームコンピュータおよび他の種類のコンピュータであってもよく、本願明細書ではそれぞれをクライアントとサプライヤと呼ぶことにする。
【0011】本発明によれば、1つまたは複数の製品に対する顧客注文をクライアントが顧客から受取った後、クライアントは、好ましいサプライヤについて注文イベントを作成し、サーバがその注文イベントを好ましいサプライヤにルーティングする。そして、サーバは、周期的にサプライヤを監視して、それが好ましいサプライヤによって処理されている時にその注文イベントの状態を判断する。サプライヤは、購入イベントを受取ると、製品を出荷してその動作をクライアントに通知し、クライアントはその後、顧客に対する請求書を用意する。サーバは、クライアントと明らかに好ましいサプライヤを含むすべてのサプライヤとの間の在庫水準を周期的に同期させる。
【0012】本発明は、システムの一部であるすべてのクライアントおよびすべてのサプライヤで、しばしば、好ましくはインターネットである大規模ネットワークに亙って通信するよう適応されている。これは、好ましくは1つのクライアントを含むが、複数のクライアントおよび幾百ものサプライヤが企図されている。システム機能を作成するために必要な情報の構造は、適切に定義され、予め定義されていない突発的な通信を許可しない。通信は、所望の情報を伝達するために多数の選択肢から選択され、かかる顧客注文の処理の経過において発生する可能性のあるよくある緊急事態およびまれな緊急事態すべてに対する要求および応答を定義すること、好ましいサプライヤを決定すること、出荷を行うこと、入手可能な在庫を決定すること、および注文された製品について顧客に代金を請求することに対し注意が払われる。業務を行う過程において通信しなければならない情報を慎重に構成することにより、ほんのわずかな例を除いていかなる人間の介入も無しに、処理を自動的に実行することが可能となる。
【0013】一般的な注文に対するかかる処理は、数秒間で完了することができ、会社の販売アクティビティの大部分に対して計画されている場合、総費用および経常的支出が大幅に低減されることになる。
【0014】
【発明の実施の形態】一般に、本発明は、市場に出されている多数の特定製品に対し、人間の介入無しに顧客が行った注文を自動的に処理する方法およびシステムに関する。クライアントは、顧客が行った注文に対して好ましいサプライヤにについて注文イベントを作成し、その注文イベントを好ましいサプライヤにルーティングする。更に、サーバはしばしば、好ましいサプライヤが注文イベントを処理している時にそのサプライヤから注文イベントの状態を監視する。最後に、サーバは、クライアントとすべてのサプライヤとの間の在庫を周期的に同期させる。
【0015】ここで図1を参照すると、本発明が実現されているシステムは、概して、好ましくは広域のネットワーク8の一部として示されている。クライアントコンピュータ(クライアント)10は、ネットワーク8を介してネットワークサーバ(サーバ)12に接続されており、サーバ12もまた、ネットワーク8を介して複数のサプライヤコンピュータ(サプライヤ)14およびサプライヤハブ15と通信する。クライアント10、サプライヤ14およびサプライヤハブ15は、実行されているアクティビティのボリュームにより、パーソナルコンピュータ、ミニコンピュータ、メインフレームコンピュータまたは他のタイプのコンピュータとすることができる。顧客は、クライアントと通信して製品を注文することにより、本システムを使用している会社によって市場に出される、商品および/またはサービスであり得るあらゆる製品を注文することができる。顧客注文は、電話により、自分で、インターネットを介して、または他の手段で行うことができ、唯一必要なことはそれがクライアントにおいてシステムに入力されなければならない、ということである。
【0016】サプライヤハブ15は、ハブ在庫に保持されている供給製品である多数の非サブスクライビング(non−subscribing)供給エンティティ15aに接続されているように示されている。かかる供給エンティティは、本システムを使用する会社の競合者であってよく、従って、サプライヤ14と同じようには接続されていない。この点で、本発明のシステムは、サブスクライビングサプライヤすなわちサプライヤ14と同じようにサプライヤハブ15と通信するが、供給エンティティは、サプライヤハブ15自体に供給される情報に対し制限されたアクセスしか行うことができない。言い換えれば、ハブは、供給エンティティによってある機密および/またはプロプライエタリな(独自の)情報がアクセスされるのを防止する。情報のフィルタリングの程度を変更してもよいが、供給エンティティが顧客の身元および場所、価格情報またはあらゆる製品のインストールベース等かかる情報にアクセスすることができないことが好ましい。供給エンティティがアクセスすることができる情報は、それがハブおよび出荷アクティビティに提供している製品の現在の在庫である。また、在庫または他の問題に関して、電話または電子メール等により供給エンティティに対するフィードバックがあってもよい。ハブに存在する在庫について最大限度および最小限度が確立されていることが好ましく、製品在庫が限度内に無い時、フラグまたは他の警告がトリガされることが可能である。
【0017】次に、ネットワーク8は、事実上世界のどこに位置していてもよい顧客およびサプライヤによってアクセスが可能であることから、好ましくはインターネットである。かかる世界のほとんどあらゆる場所からのアクセス可能性は、インターネットを使用することの非常に望ましい面であり、本発明の利用の規模に対して重要である。しかしながら、他の種類のネットワークをインターネットと共にあるいはその代りに使用することが確かに可能である。例えば、ネットワークコネクションは、仮想インターネットホスト、ダイアルアップコネクションまたはルータから構成されていてもよく、クライアント10とサプライヤ14とがサーバ12を介して情報を交換することができるようにするものである。
【0018】好ましい実施の形態が通信コネクションとしてインターネットを使用するものである場合、本発明は目下、webMethods,Inc.のビジネス・ツー・ビジネス・インテグレーションサーバ(Business−To−Business Integration Server)(webMethods B2Bウェブサーバ)で実現される。なお、これはwebMethods.comで見つけることができる。しかしながら、プログラミング言語に対してハイパーテキスト・マークアップ言語(HTML)のマッピングを提供する他の同様のウェブサーバプロダクトを用いてもよく、それは本発明の範囲内にある。webMEthods B2Bウェブサーバのマッピング機能は、本発明が使用している基本的な特徴であり、HTMLコードを変数のカスタムJavaクラスメンバにマッピングするというものである。これは、クライアント10とサプライヤ14との間の通信のための現行プロトコルである。しかしながら、本発明に対しエクステンシブル・マークアップ言語(XML)が好ましいプロトコルであるため、ネットワークにおいてXMLがより一般的になるに従いwebMethodsB2Bは重要な役割を果たさなくなってくる。
【0019】本発明の実現に必要なネットワークシステムは複雑性およびサイズが大きく変化するため、ネットワークトポロジの目下好ましい実施の形態の説明は、本発明を明確にする目的で行う。図1に示すシステムは、1つのクライアントを有しているが、互いに接続されたいくつかのクライアントコンポーネントコンピュータを有していてもよい。その場合には、各クライアントコンポーネントは、別個の機能を有していてもよい。例えば、あるクライアントコンポーネントはウェアハウスの課金のみを扱う。他のクライアントコンポーネントは財務用に使用される。各クライアントコンポーネントは、ネットワークの単一層になり、システムを定義するためにすべての複数層が共に作用する。かかるシステムにおいて、1つのクライアントコンポーネントはメッセージブローカ層またはコンポーネントとしての役割を果たさなければならない。メッセージブローカクライアントコンポーネントは、データ変換、データフォーマット、ビジネスルールの実施、ネットワーク構成およびメッセージゲートウェイを提供することができる。
【0020】いくつかのクライアントコンポーネントコンピュータが使用される場合、1つのクライアントコンポーネントから他のクライアントコンポーネントにデータおよび情報を適応させるかまたはインタフェースする必要があり、そうするためのアダプタが図2に示されている。この図は、他のクライアントコンポーネントがメッセージブローカクライアントコンポーネント(メッセージブローカ)に対してネイティブファイルフォーマットを作成することができるようにする汎用ファイルアダプタの論理フローを示している。アダプタは、クライアントコンポーネントのいずれにも常駐するソフトウェアから構成することができる。
【0021】目下、本発明の好ましい実施の形態では、メッセージブローカクライアントコンポーネントとしてActive Software,Inc.のActiveWorks3.0を使用する。Active Software,Inc.は、activesw.comで見つけることができる。この場合も、標準メッセージング機能をサポートする他の同様のメッセージングプロダクトを使用してもよく、それは本発明の範囲内にある。データ変換およびフォーマットのActiveWorksの機能を利用することにより、本発明においてActiveWorksに接続されたクライアントコンポーネントは、異なるクライアントコンポーネント間での通信を可能にするためにデータを1つのネイティブファイルフォーマットに変換するよう適応されている。
【0022】図2を参照すると、終了したタイムアウトかまたは外部処理がサブスクライビングアダプタをトリガし(ブロック16)、サブスクライビングアダプタはメッセージブローカに接続する(ブロック18)。アダプタは、クライアントにおいてサブスクライブキューを探す(ブロック20)。サブスクライブキューが存在しない場合、サブスクライビングアダプタはイベントに対し「サブスクリプション(subscription)」を確立する(ブロック22)。「サブスクリプション」という語は、それ自体をメッセージブローカのサブクライバ(subscriber)としてセットアップするクライアントコンポーネントを言う。サブスクライブキューが見つかると(ブロック20)、サブスクライビングアダプタは、入手可能であれば(ブロック26)メッセージブローカからイベントを取得しようとする(ブロック24)。しかしながら、キューにイベントが見つからない場合、サブスクライビングアダプタは、後に自身を再びトリガするためにタイムアウトを開始する(ブロック28)。
【0023】好ましくは、タイムアウトの持続時間は、何のオペレーションが実行されているかおよびいずれのサプライヤが含まれているかによって構成可能である。在庫同期イベントまたは状態チェックイベントに関連するタイムアウトは、短時間に何千もの製品を提供するサプライヤについては非常に短くすることができる。その場合、タイムアウトは、1分以下程度に短くしてもよい。例えば、ボリュームが更に小さいサプライヤの場合、およそ15分のタイムアウト時間としてもよい。たまにしか製品を提供しないサプライヤは、数時間のタイムアウト時間でもよい。重要な点は、信頼性のある動作を保証するために、システムの動作に関連する適当な情報がクライアント、サーバおよび個々のサプライヤ間で通信される、ということを確実にするために十分短い持続時間である、ということである。
【0024】イベントが見つかると、サブスクライビングアダプタはそのイベントをピックアップし(ブロック30)、情報をネイティブフォーマットにフォーマットし(ブロック34)、メッセージブローカに対しすべてのサブクライバクライアントコンポーネントが読むことができるネイティブファイル(ブロック36)を作成する。このようにして、メッセージブローカにより、すべてのクライアントコンポーネントがネットワーク上でデータおよび情報を共有することができる。更に、クライアントコンポーネントが探すイベントのタイプは、クライアントコンポーネントのタイプが何であるかによって大きく決まる。例えば、購入注文メンテナンスクライアントコンポーネントは、注文イベントのみを取得する。同様に、ネットワーク注文ルータマネージャクライアントコンポーネントは、注文イベント、確認イベントおよび拒否イベントを取得する。サブスクライビングアダプタは、サブルーチンを再スタートするためにタイムアウトをセットすることで終了する(ブロック38)。
【0025】本発明の重要な態様に従って、クライアント10が好ましいサプライヤ14について注文イベントを作成する方法を、図3に示す。受取られる各顧客注文について、クライアント10は、注文された製品に対する好ましいサプライヤ14を決定する(ブロック40)。好ましい実施の形態では、好ましいサプライヤ14には、製品の在庫が入手可能なサプライヤが決定され、それは好ましくは、顧客注文によって指定される出荷先と地理的に同じエリアに位置している(出荷の時間および/またはコストを最小化すべきである)が、好ましい状態を決定するために他の点を考慮してもよい。例えば、そのサプライヤが他のサプライヤより出荷先から地理的に遠く離れていても、輸送効率により特定のサプライヤを好ましいサプライヤとして指示してもよい。
【0026】また、顧客注文は、1つのサプライヤでは入手することができない大量の製品に対するものか、または、単一のサプライヤに対しては都合の悪いいくつかの異なる出荷先を指定するものであってもよい、ということも認められるべきである。いずれの場合も、複数の好ましいサプライヤが、入手可能性の制限または要求された出荷先に適応するよう決定されてもよい。
【0027】好ましいサプライヤ14が決定された後、クライアント10は次に、かかる情報の妥当性をベンダ番号および/または部品番号としてチェックすることにより、顧客注文からの情報の妥当性を検査する(ブロック42)。そして、クライアント10は、一意の購入注文番号を割当て(ブロック44)、顧客注文からのすべての情報および割当てられた購入注文番号により注文イベントを作成する(ブロック46)。注文イベントに含まれる好ましいフォーマットおよび情報は、表1に示されている。
【0028】本発明の他の態様によれば、図4は、いかにしてサーバ12が注文イベントを好ましいサプライヤ14にルーティングするかを定義するサブルーチンのステップを示している。まず、サーバ12は、注文イベントに対してクライアント10を監視する(ブロック48)。このステップを実現するためにはいくつかの方法があるが、1つの方法は、入ってくる注文イベントに対しクライアント10への永続的なコネクションを使用するというものである。サーバ12は、入手可能な注文イベントがある場合、クライアント10からその注文イベントを取得する(ブロック50)。次に、サーバ12は、例えば空フィールドおよび/またはそのフィールドで使用される誤ったタイプのデータがあるかをチェックすることにより、注文イベントの妥当性を検査する(ブロック52)。
【0029】注文イベントから、サーバ12は好ましいサプライヤ14の識別を決定し(ブロック54)、この好ましいサプライヤ14が実際に存在することを確かめる(ブロック56)。サプライヤ14が見つからない場合、サーバ12は、クライアント10に対して拒否イベントを送信する(ブロック58)。拒否イベントに含まれる好ましいフォーマットおよび情報は、添付の表3に示されている。
【0030】一方、サーバ12は、サプライヤ14がある場合その好ましいサプライヤ14に注文イベントを送信する(ブロック60)。そして、サプライヤ14は、直ちに注文を拒否するかまたは受入れる(ブロック62)。サプライヤ14が注文を受入れた場合、製品は即時にサプライヤから顧客に直接出荷される。本発明のコンテキストにおいて、即時の出荷は、注文が行われた同じ日における出荷を意味する。サプライヤ14が注文イベントを拒否した場合、サーバ12はクライアント10に対して拒否イベントを送信する(ブロック64)。サプライヤ14は、サーバ12からの注文イベントを受入れた場合、注文イベントに対しトラッキング番号を割当てる(ブロック66)。そして、サーバ12は、そのトラッキング番号により注文イベントをオープン状態として保存する(ブロック68)。
【0031】次に、サーバ12が注文イベントの状態を監視するサブルーチンを、図5に示す。サーバ12は、終了したタイムアウトによりトリガされると(ブロック74)、そのデータベース内に配置されたオープン状態のすべての注文イベントのリストを作成する(ブロック76)。そのリストの各注文イベントから、サーバ12は注文イベントに列挙された好ましいサプライヤ14を識別し(ブロック78)、その好ましいサプライヤ14から状態メッセージを要求する(ブロック80)。サプライヤ14は、注文イベントに対して最も新しい情報を有する状態メッセージを送信する(ブロック82)。例えば、状態メッセージは、注文イベントがオープンか、クローズドか、または拒否されているかを示す(ブロック84)。注文イベントがオープンである場合、サーバ12は、この状態監視サブルーチンを再スタートするためにタイムアウトを再び開始する(ブロック86)。
【0032】拒否された状態の注文イベントに対し、サーバ12は、クライアント10に拒否イベントを送信する(ブロック88)。そして、サーバ12は、注文イベントの状態をオープンから拒否に変更し(ブロック90)、このサブルーチンを再スタートするためにタイムアウトを開始する(ブロック92)。一方、注文イベントがサプライヤ14によってクローズされている場合、サーバ12は、クライアント10に確認イベントを送信する(ブロック94)。サーバ12は再び、注文イベントの状態を変更するが、この場合オープンからクローズドに変更し(ブロック96)、タイムアウトを開始する(ブロック98)。注文がクローズされたことを示す確認イベントを受取った後、クライアントは顧客に対してインヴォイスを送信する(ブロック99)。確認イベントに含まれる好ましいフォーマットおよび情報は、表2に示されている。
【0033】好ましいサプライヤ14がいかにして注文イベントを処理するかのサブルーチンを図6に示す。好ましいサプライヤ14は、注文イベントの処理に対して準備を行う(ブロック100)。この準備には、出荷ラベルの印刷、パッケージの準備または出荷受領書の作成等が含まれる。好ましいサプライヤ14は、顧客に対して製品を出荷した後(ブロック102)、確認イベントを作成する(ブロック104)。
【0034】本発明の他の重要な態様によれば、図7に示すように、サーバはクライアントとすべてのサプライヤとの間の在庫を同期させる。このサブルーチンは、終了したタイムアウトによってトリガされ(ブロック106)、タイムアウトは、再スタートするためにこのサブルーチンの終了時に再びセットされる。まず、サーバ12は、すべてのサプライヤ14へのコネクションを作成することにより、好ましいサプライヤ14を含むすべてのサプライヤから最も新しく更新された在庫水準を検索する(ブロック108)。そして、サーバ12は、更新された在庫と共に在庫同期イベントをクライアント10に送信する(ブロック110)。クライアント10は、それ自体のデータベースにおいて、好ましいサプライヤを含むすべてのサプライヤに対し現在の在庫を更新する。この情報は、後に、所定の注文イベントに対し好ましいサプライヤ14を選ぶために使用される。サーバは、タイムアウトを開始することによってサブルーチンを終了する(ブロック114)。在庫同期イベントに含まれる好ましいフォーマットおよび情報は、表4に示されている。
【0035】上述した説明から、製品に対する顧客が行った注文を処理する改良された方法およびシステムが示され説明され、それらが多くの望ましい特徴および利点を有しているということが理解されるべきである。本方法およびシステムにより、顧客注文は注文履行および引渡しを行うためにサプライヤに対して直接ルーティングされ、完全に自動化された顧客注文履行処理が生成される。システムの設計が優れているため、顧客注文の処理全体を完了し、代金を請求し、出荷することが可能であり、処理の決定が、人間の介入無しに数秒以内で行われる。
【0036】本発明のあらゆる実施の形態を示し説明したが、当業者には、他の変更態様、代用態様および代替態様が明らかであることは理解されるべきである。かかる変形態様、代用態様および代替態様は、本発明の精神および範囲から逸脱することなく行うことができ、その精神および範囲は、添付の特許請求の範囲から決定されるべきである。
【0037】次の表において、サイズ欄の項目は、フィールドにおける文字型と文字の数を示す。例えば、以下のとおりである。
(1)X6は、6個の文字を含む英数字項目を示す。左寄せし後続ブランクでフォーマットする。
(2)9(2)は、2文字を含む数字項目を示す。右寄せし先行ゼロでフォーマットする。例えば、1は01として入力される。
(3)9(7)v99は、7文字長までの数字項目を示し、固定小数点であり小数点以下の桁数が2である。このため、項目199は1.99として解釈される。
【0038】
【表1】

【0039】
【表2】

【0040】
【表3】

【0041】
【表4】

【0042】
【表5】

【0043】
【表6】

【0044】
【表7】

【0045】
【表8】

【0046】
【表9】

【0047】
【表10】

【0048】
【表11】

【0049】
【表12】

【0050】本発明のあらゆる特徴は、添付の特許請求の範囲に示されている。
【0051】以上、本発明の実施例について詳述したが、以下、本発明の各実施態様の礼を示す。
(実施態様1)製品に対し顧客が行った注文を処理する方法であって、前記顧客注文が、少なくとも1つのサーバを介してネットワークにより複数のサプライヤに動作可能に接続された少なくとも1つのクライアントによって受取られる方法において、前記クライアントが、好適なサプライヤについて注文イベントを作成するステップと、前記サーバが、前記好適なサプライヤに前記注文イベントをルーティングするステップと、前記サーバが、前記好適なサプライヤからの前記注文イベントの状態を監視するステップと、前記好適なサプライヤが前記注文イベントを処理するステップと、前記サーバが、上記ステップとは無関係に前記クライアントと前記複数のサプライヤとの間で在庫を周期的に同期させるステップと、を含むことを特徴とする方法。
(実施態様2)前記クライアントが好適なサプライヤについて注文イベントを作成する前記ステップは、前記クライアントが、サプライヤの地理的位置と在庫の入手可能性とに従って好ましいサプライヤを決定するステップと、前記クライアントが、前記顧客が行った注文からの情報の妥当性を検査するステップと、前記クライアントが、前記注文イベントに対し購入注文番号を割当てるステップと、を更に含むことを特徴とする前項(1)記載の方法。
(実施態様3)好適なサプライヤについて注文イベントを作成する前記ステップは、入手可能な製品の在庫を有し、前記顧客に対する製品の出荷の時間および費用を最小限にするように地理的に有利に配置されている第1の好ましいサプライヤを決定するステップと、第1の好適なサプライヤの入手可能な製品の前記在庫が前記顧客の注文を満たすために十分でない場合、入手可能な製品の在庫を有する第2の好ましいサプライヤを決定するステップと、を更に含むことを特徴とする前項(2)記載の方法。
(実施態様4)前記サーバが前記好適なサプライヤに前記注文イベントをルーティングする前記ステップは、前記サーバが、注文イベントについて前記クライアントを監視するステップと、前記サーバが、前記注文イベントを取得するステップと、前記サーバが、前記製品の前記好適なサプライヤの識別に先立ち、注文イベントの妥当性を検査するステップと、前記サーバがその後、前記製品の好適なサプライヤの存在および識別を決定するステップと、前記サーバがその後、前記好適なサプライヤが存在する場合に存在し識別された好適なサプライヤに対し前記注文イベントを送信するステップと、前記サーバが、いずれのサプライヤも識別されない場合に前記購入注文を生成したクライアントに拒否イベントを送信するステップと、を更に含むことを特徴とする前項(1)記載の方法。
(実施態様5)前記サーバがその後、前記存在し識別された好ましいサプライヤに対し前記注文イベントを送信する前記ステップは、前記好適なサプライヤが、注文イベントを受入れた場合に前記注文イベントに対してトラッキング番号を割当てるステップと、前記サーバが、前記好適なサプライヤが前記注文イベントを受入れなかった場合に前記クライアントに拒否イベントを返信するステップと、を更に含むことを特徴とする前項(4)記載の方法。
(実施態様6)前記好適なサプライヤが前記注文イベントに対してトラッキング番号を割当てる前記ステップは、前記サーバが、該トラッキング番号が付された該注文イベントをオープン状態として保存するステップを更に含むことを特徴とする前項(5)記載の方法。
(実施態様7)前記サーバが、前記好適なサプライヤからの前記注文イベントの状態を監視する前記ステップは、前記サーバが、オープン状態である注文イベントのリストを作成するステップと、前記サーバが、オープン状態である各注文イベントに対して前記好適なサプライヤを決定するステップと、前記サーバが、前記好適なサプライヤからのオープン状態である各注文イベントに対し状態メッセージを要求するステップと、前記好適なサプライヤが、前記サーバに対し前記注文イベントについての最も新しい状態を有する状態メッセージを送信するステップと、前記サーバが、前記注文イベントがオープンである場合にタイムアウトを開始するステップと、前記サーバが、前記注文イベントがクローズドである場合に前記クライアントに対し確認イベントを送信するステップと、前記サーバが、前記注文イベントが拒否されている場合に前記クライアントに拒否イベントを送信するステップと、を更に含むことを特徴とする前項(1)記載の方法。
(実施態様8)前記サーバが前記クライアントに確認イベントを送信する前記ステップは、前記サーバが、前記注文イベントをオープン状態からクローズド状態に変更するステップと、前記サーバが、タイムアウトを開始するステップと、前記クライアントが、出荷のために前記顧客に請求書を送信するステップと、を更に含むことを特徴とする前項(7)記載の方法。
(実施態様9)前記タイムアウトは、各サプライヤに対して構成可能であり、好ましくは、当該処理方法の動作に関連する信頼性のある通信が維持されることを確実にするために十分に短い持続時間であることを特徴とする前項(8)記載の方法。
(実施態様10)前記サーバが前記クライアントに拒否イベントを送信する前記ステップは、前記サーバが、前記注文イベントをオープン状態からクローズド状態に変更するステップと、該サーバが、タイムアウトを開始するステップと、を更に含むことを特徴とする前項(7)記載の方法。
(実施態様11)前記好ましいサプライヤが前記注文イベントを処理する前記ステップは、前記好適なサプライヤが、前記顧客に対して前記製品を出荷するステップと、該好ましいサプライヤが、確認イベントを作成するステップと、を更に含むことを特徴とする前項(1)記載の方法。
(実施態様12)前記サーバが、前記注文イベントをルーティングした前記クライアントと前記好ましいサプライヤとの間の在庫を同期させる前記ステップは、該サーバが、該好ましいサプライヤから最も新しく更新された在庫を検索するステップと、前記サーバが、該更新された在庫を含む在庫同期イベントを前記クライアントに送信するステップと、前記クライアントが、前記好適なサプライヤに対する現在庫を更新するステップと、前記サーバが、前記サーバを起動するためにタイムアウトを開始するステップと、を更に含むことを特徴とする前項(1)記載の方法。
(実施態様13)前記サーバは、前記タイムアウトの終了時に起動されることを特徴とする前項(12)記載の方法。
(実施態様14)前記ネットワークは、インターネットであることを特徴とする前項(1)記載の方法。
(実施態様15)複数の製品のうちの少なくとも1つの製品をある量購入すしその購入された量に対して引渡し位置を指定する顧客が行った注文を処理する方法であって、該顧客注文が、少なくとも1つのサーバを介してインターネット等のネットワークにより地理的に広い領域に亙って配置された複数のサプライヤに動作可能に接続された少なくとも1つのクライアントによって受取られる方法において、前記クライアントが、第1のサプライヤについて注文イベントを作成し、前記第1のサプライヤが、前記購入された1つの製品の入手可能な在庫を有することの関数として決定されるものであり、前記第1のサプライヤの位置が、該製品の引渡しの時間およびコストの少なくとも一方を最小限にするよう前記顧客によって指定された引渡し位置に近いものであるステップと、前記サーバが、前記第1のサプライヤに対し前記注文イベントを前記第1のサプライヤによって処理されるようルーティングするステップと、前記サーバが、前記第1のサプライヤによって処理されている前記注文イベントの状態を監視するために前記第1のサプライヤと周期的に通信するステップと、前記第1のサプライヤが、前記注文イベントの受入れおよび拒否のうちの一方を行うことにより前記注文イベントを処理するステップと、前記サーバが、上記ステップとは無関係に前記クライアントと前記複数のサプライヤとの間で周期的に在庫を同期させるステップと、を含むことを特徴とする方法。
(実施態様16)前記地理的に広い領域は、前記インターネットによってアクセス可能な世界のあらゆる場所であることを特徴とする前項(15)記載の方法。
(実施態様17)前記第1のサプライヤが前記購入された1つの製品の在庫を十分に有していない場合に、前記クライアントが、第2のサプライヤについて注文イベントを作成し、前記第2のサプライヤが、前記製品の引渡しの時間およびコストの少なくとも一方を最小限にするよう前記顧客によって指定された引渡し位置に近い前記第2のサプライヤの位置の関数として決定されるものであるステップを更に含むことを特徴とする前項(15)記載の方法。
(実施態様18)前記第1のサプライヤとの前記周期的な通信は、構成可能であり、好ましくは、当該処理方法の信頼性のある動作に関連する適当な情報が提供されることを確実にするように十分に短い間隔で発生することを特徴とする前項(15)記載の方法。
(実施態様19)前記第1のサプライヤが前記注文イベントを処理する前記ステップは、前記第1のサプライヤが、該注文イベントに対しトラッキング番号を割当てるステップと、前記サーバが、該トラッキング番号を有する該注文イベントをオープン状態として保存するステップと、を更に含むことを特徴とする前項(15)記載の方法。
(実施態様20)前記第1のサプライヤが前記注文イベントを処理し該注文イベントを拒否する前記ステップは、前記サーバが、該注文イベントをオープン状態から拒否状態に変更するステップと、該サーバが、タイムアウトを開始するステップと、を更に含むことを特徴とする前項(15)記載の方法。
(実施態様21)在庫を同期させる前記ステップは、前記顧客によって購入された製品の量により入手可能な在庫の量を低減させた後に、前記第1のサプライヤの該入手可能な在庫を更新するステップを含むことを特徴とする前項(15)記載の方法。
(実施態様22)少なくとも1つのクライアントにより顧客が行った注文を履行するシステムであって、該顧客注文が,少なくとも1つのサーバを介してネットワークにより複数のサプライヤに動作可能に接続された少なくとも1つのクライアントによって受取られるシステムにおいて、前記クライアントにおいて好ましいサプライヤについて注文イベントを作成する手段と、前記好適なサプライヤに該注文イベントをルーティングする手段と、前記好適なサプライヤからの該注文イベントの状態を監視する手段と、該注文イベントを処理する手段と、前記クライアントと前記複数のサプライヤとの間で在庫を周期的に同期させる手段と、を具備することを特徴とするシステム。
(実施態様23)少なくとも1つのクライアントにより顧客が行った注文を履行するシステムであって、該顧客注文が、少なくとも1つのサーバを介してネットワークにより複数のサプライヤに動作可能に接続された少なくとも1つのクライアントによって受取られるシステムにおいて、前記クライアントが、前記クライアントにおける好適なサプライヤについて注文イベントを作成するよう適応されており、前記サーバが、前記好適なサプライヤに前記注文イベントをルーティングするよう適応されており、前記サーバが、前記好適なサプライヤからの前記注文イベントの状態を監視するよう適応されており、前記好適なサプライヤが、前記注文イベントを処理するよう適応されており、前記サーバが、前記クライアントと前記複数のサプライヤとの間で在庫を周期的に同期させるよう適応されていることを特徴とするシステム。
(実施態様24)前記サプライヤが、前記注文イベントが処理された直後に前記顧客によって注文された前記製品を出荷することを特徴とする前項(22)記載の方法。




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013