(57)【要約】【解決手段】コンピュータ間でトランザクションを交換するためのシステムであって、ソフトウェアが異なるデータフォーマットでデータを交換することができるようにする。このシステムは、各関係者が利用するデータフォーマット等、そのトランザクションのすべての関係者のプロフィールを保持している。トランザクションが開始されると、システムはそのセッションに固有の暗号化キーを生成し、すべてのデータ転送はその新たに生成された暗号化キーを用いてエンコードされる。【特許請求の範囲】
【請求項１】
送信元のコンピュータと送信先のコンピュータとの間のトランザクションの通信をするための方法であって、
前記送信元のコンピュータのアプリケーションスイートからのトランザクションデータを処理し、
所定の定義をもとに標準化されたデータトランザクションを生成し、
前記送信元のコンピュータから前記送信先のコンピュータに前記標準化されたトランザクションデータを送信し、
前記送信先のコンピュータにより前記標準化されたトランザクションデータを受信し、
前記送信先コンピュータの特性に基づいてトランザクションデータを生成し、前記送信先のコンピュータにて前記トランザクションデータを保存し、
前記送信先のコンピュータにて目的のアプリケーションスイートにより前記トランザクションデータを処理する。
【請求項２】
請求項１に記載のトランザクションの通信のための方法であって、トランザクションデータの生成ステップは、前記トランザクションデータを送信元のフォーマットから標準化されたフォーマットへ変換することを備えている。
【請求項３】
請求項２に記載のトランザクションの通信のための方法であって、トランザクションデータの生成ステップは、データを標準化されたフォーマットから目的のアプリケーションスイートによって読み取り可能なフォーマットに変換する。
【請求項４】
請求項１に記載のトランザクションの通信のための方法であって、標準化されたデータトランザクションの生成は、トランザクションデータをエンコード及びデコードするための固有の暗号化キーの作成を備えている。
【請求項５】
送信元コンピュータと送信先コンピュータとの間のトランザクションの通信のためのシステムであって、
前記送信元コンピュータは、コンピュータで読み取り可能な命令コード手段をその中に保存して保持している、コンピュータで使用できる媒体を備え、
前記送信先コンピュータは、コンピュータで読み取り可能な命令コード手段をその中に保存して保持している、コンピュータで使用できる媒体を備えており、
前記送信元コンピュータのアプリケーションスイートからのトランザクションデータの処理のためのコンピュータで読み取り可能な命令コード手段と、
所定の定義をもとに標準化されたデータトランザクションを生成するためのコンピュータで読み取り可能な命令コード手段と、
前記送信元コンピュータから前記送信先コンピュータに前記標準化されたトランザクションデータを送信するためのコンピュータで読み取り可能な命令コード手段と、
前記送信先コンピュータによって前記標準化されたトランザクションデータの受信をするためのコンピュータで読み取り可能な命令コード手段と、
前記送信先コンピュータの特性に基づくトランザクションデータの生成し、前記送信先コンピュータに前記トランザクションデータを保存するためのコンピュータで読み取り可能な命令コード手段と、
前記送信先コンピュータの目的のアプリケーションスイートによって前記トランザクションデータを処理するためのコンピュータで読み取り可能な命令コード手段と、
を備えている。
【請求項６】
イニシエータとレスポンダとの間のデータ交換のための方法であって、
前記イニシエータから前記レスポンダにセッション要求パッケージを送信し、
前記レスポンダから前記イニシエータにセッション確認を送信し、
前記イニシエータから前記レスポンダにセッション要求を送信し、
前記レスポンダによって前記イニシエータのキー要求が正しくエンコードされていることを確認し、
前記レスポンダから前記イニシエータにキー確認を送信し、
前記イニシエータによって前記レスポンダのキー確認が正しくエンコードされていることを確認し、
前記イニシエータによって前記レスポンダにデータパッケージを送信し、
前記レスポンダによって前記イニシエータにパッケージ確認とともに応答し、
前記イニシエータが終了要求を送信するまでデータパッケージ送信ステップと応答ステップを繰り返す。
【請求項７】
請求項６に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション要求パッケージは、前記イニシエータのIPアドレスとプロフィールデータを備えている。
【請求項８】
請求項７に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション確認ステップは、前記レスポンダの公開セッションキーを保持している新規セッションキーの組を生成するステップを備えている。
【請求項９】
請求項６に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション確認は、セッションキーの組と、前記レスポンダの公開セッションキーと、前記レスポンダのプロフィールデータと、を備えている。
【請求項１０】
請求項６に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、キー要求は、前記イニシエータの公開セッションキーと、前記イニシエータのプロフィールデータと、を備えている。
【請求項１１】
請求項１０に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション確認は、前記レスポンダの公開セッションキーを備えている。
【請求項１２】
請求項１１に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、キー要求は、前記レスポンダの公開セッションキーとともにエンコードされている。
【請求項１３】
請求項６に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、前記イニシエータのキー要求を確認するステップは、キー要求をデコードして、前記キー要求が適切にフォーマットされていることを検査すること、を備えている。
【請求項１４】
請求項６に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、前記レスポンダのキー確認を確認するステップは、キー確認のデコードをして、前記キー確認が適切にフォーマットされていることを検査すること、を備えている。
【請求項１５】
請求項６に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、データパッケージの送信ステップは、その最初のフォーマットから標準化されたフォーマットにそのデータを変換することをさらに備える。
【請求項１６】
請求項１５に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、応答ステップは、標準化されたフォーマットから前記レスポンダによって使用されているフォーマットにデータを変換することをさらに備える。
【請求項１７】
請求項１５に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、標準化されたフォーマットはEDIである。
【請求項１８】
イニシエータコンピュータとレスポンダコンピュータとの間のデータ交換のためのシステムであって、
前記イニシエータコンピュータは、コンピュータで読み取り可能な命令コード手段をその中に保存して保持する、コンピュータで使用できる媒体を備え、
前記レスポンダコンピュータは、コンピュータで読み取り可能な命令コード手段をその中に保存して保持する、コンピュータで使用できる媒体を備え、
前記イニシエータから前記レスポンダにセッション要求パッケージを送信するためのコンピュータで読み取り可能な命令コード手段と、
前記レスポンダから前記イニシエータにセッション確認を送信するためのコンピュータで読み取り可能な命令コード手段と、
前記イニシエータから前記レスポンダにキー要求を送信するためのコンピュータで読み取り可能な命令コード手段と、
前記レスポンダによって前記イニシエータのキー要求が正しくエンコードされたことを確認するためのコンピュータで読み取り可能な命令コード手段と、
前記レスポンダから前記イニシエータにキー確認を送信するためのコンピュータで読み取り可能な命令コード手段と、
前記イニシエータによって前記レスポンダのキー確認が正しくエンコードされていることを確認するためのコンピュータで読み取り可能な命令コード手段と、
前記イニシエータによって前記レスポンダのキー確認が正しくエンコードされていることを確認するためのコンピュータで読み取り可能な命令コード手段と、
前記イニシエータによって前記レスポンダにデータパッケージを送信するためのコンピュータで読み取り可能な命令コード手段と、
前記レスポンダのパッケージ確認によって前記イニシエータに応答するためのコンピュータで読み取り可能な命令コード手段と、
前記イニシエータが終了要求を送信するまで、データパッケージ送信ステップと応答ステップを繰り返す。
【請求項１９】
請求項１８に記載のイニシエータコンピュータとレスポンダコンピュータとの間のデータ交換のためのシステムであって、セッション要求パッケージは前記イニシエータのIPアドレスとプロフィールデータを備えている。
【請求項２０】
請求項１８に記載のイニシエータコンピュータとレスポンダコンピュータとの間のデータ交換のためのシステムであって、セッション確認ステップは、さらに前記レスポンダの公開セッションキーを保持している新規セッションキーの組を生成するためにコンピュータで読み取り可能な命令コード手段を備えている。
【請求項２１】
請求項２０に記載のイニシエータコンピュータとレスポンダコンピュータとの間のデータ交換のためのシステムであって、セッションキーは、セッションキーの組と、レスポンダの公開セッションキーと、レスポンダのプロフィールデータと、を備えている。
【請求項２２】
請求項１８に記載のイニシエータコンピュータとレスポンダコンピュータとの間のデータ交換のためのシステムであって、キー要求は、イニシエータの公開セッションキーと、イニシエータのプロフィールデータと、を備えている。
【請求項２３】
請求項１８に記載のイニシエータコンピュータとレスポンダコンピュータとの間のデータ交換のためのシステムであって、セッション確認はレスポンダの公開セッションキーを備えている。
【請求項２４】
請求項１８に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、キー要求は前記レスポンダの公開セッションキーとともにエンコードされている。
【請求項２５】
請求項１８に記載のイニシエータコンピュータとレスポンダコンピュータとの間のデータ交換のためのシステムであって、キー要求をデコードするためのコンピュータで読み取り可能な命令コード手段と、キー要求が適切にフォーマットされていることを検査するためのコンピュータで読み取り可能な命令コード手段とを、備えている。
【請求項２６】
請求項１８に記載のイニシエータコンピュータとレスポンダコンピュータとの間のデータ交換のためのシステムであって、キー確認をデコードするためのコンピュータで読み取り可能な命令コード手段と、キー確認が適切にフォーマットされていることを検査するためのコンピュータで読み取り可能な命令コード手段と、を備えている。
【請求項２７】
イニシエータとレスポンダとの間のデータ交換のための方法であって、前記イニシエータのステップは、
セッション要求パッケージの送信と、
セッション確認の受信と、
キー要求の送信と、
キー確認の受信と、
前記キー確認が正しくエンコードされたことの確認と、
データパッケージの送信と、
パッケージ確認の受信と、
セッション終了要求の送信と、
を備えている。
【請求項２８】
請求項２７に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション要求パッケージは前記イニシエータのIPアドレスとプロフィールデータを備えている。
【請求項２９】
請求項２７に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション確認ステップはさらに前記イニシエータがセッションキーの組と前記レスポンダの公開セッションキーを受信することを備えている。
【請求項３０】
請求項２９に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション確認は、セッションキーの組と、前記レスポンダの公開セッションキーと、前記レスポンダのプロフィールデータと、を備えている。
【請求項３１】
請求項２７に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、キー要求は、前記イニシエータの公開セッションキーと、前記イニシエータのプロフィールデータと、を備えている。
【請求項３２】
請求項３１に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション確認はさらに前記レスポンダの公開セッションキーを備えている。
【請求項３３】
請求項３２に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、キー要求は前記レスポンダの公開セッションキーとともにエンコードされている。
【請求項３４】
請求項３３に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、キー確認が正しくエンコードされていることの確認ステップはさらに、前記キー確認を前記レスポンダの公開セッションキーとともにデコードし、前記キー確認が正しくフォーマットされていることを検査すること、を備えている。
【請求項３５】
コンピュータがトランザクションを別のコンピュータと交換することを可能にするため、コンピュータで読み取り可能な命令コード手段を保存し保持しているコンピュータで使用可能な媒体であって、
前記コンピュータにセッション要求パッケージを送信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにセッション確認を受信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにキー要求を送信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにキー確認を受信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータに前記キー確認が正しくエンコードされていることを確認させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにデータパッケージを送信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにパッケージ確認を受信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにセッション終了要求を送信させるためのコンピュータで読み取り可能な命令コード手段と、
を備えている。
【請求項３６】
請求項３５に記載のコンピュータで使用可能な媒体であって、セッション要求パッケージはIPアドレスとプロフィールデータを備えている。
【請求項３７】
請求項３５に記載のコンピュータで使用可能な媒体であって、セッション確認はさらに公開セッションキーを備えている。
【請求項３９】
請求項３５に記載のコンピュータで使用可能な媒体であって、セッション確認は、セッションキーの組と、公開セッションキーと、プロフィールデータと、を備えている。
【請求項４０】
請求項３５に記載のコンピュータで使用可能な媒体であって、キー要求は、別のコンピュータのための公開セッションキーと、前記別のコンピュータのためのプロフィールと、を備えている。
【請求項４１】
請求項３５に記載のコンピュータで使用可能な媒体であって、さらに公開セッションキーでキー要求をデコードするためのコンピュータで読み込み可能な命令コード手段を備えている。
【請求項４２】
請求項３５に記載のコンピュータで使用可能な媒体であって、キー確認が正しくエンコードされていることを確認するためのコンピュータで読み込み可能な命令コード手段はさらに、前記キー確認をデコードするためのコンピュータで読み込み可能な命令コード手段と、前記キー確認が適切にフォーマットされていることを検査するためのコンピュータで読み込み可能な命令コード手段と、を備えている。
【請求項４３】
イニシエータとレスポンダとの間のデータ交換のための方法であって、前記レスポンダのステップは、
セッション要求パッケージを受信し、
セッション確認を送信し、
キー要求を受信し、
前記イニシエータのキー要求が正しくエンコードされていることを確認し、
キー確認を送信し、
データパッケージを受信し、
パッケージ確認とともに応答し、
終了セッション要求を受信するまでデータパッケージの受信のステップと応答のステップを繰り返すこと、
を備えている。
【請求項４４】
請求項４３に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション要求パッケージは前記イニシエータのIPアドレスとプロフィールデータを備えている。
【請求項４５】
請求項４３に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション確認ステップは、公開セッションキーを保持している新規セッションキーの組を生成するステップを備えている。
【請求項４６】
請求項４３に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション確認は、セッションキーの組と、公開セッションキーと、プロフィールデータと、を備えている。
【請求項４７】
請求項４３に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、キー要求は、前記イニシエータの公開セッションキーと、前記イニシエータのプロフィールデータと、を備えている。
【請求項４８】
請求項４３に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、セッション確認はさらに公開セッションキーを備えている。
【請求項４９】
請求項４８に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、キー要求は公開セッションキーによってエンコードされている。
【請求項５０】
請求項４３に記載のイニシエータとレスポンダとの間のデータ交換のための方法であって、確認ステップは、キー要求をデコードして、前記キー要求が適切にフォーマットされていることを検査すること、を備えている。
【請求項５１】
コンピュータがトランザクションを別のコンピュータと交換することを可能にするため、コンピュータで読み取り可能な命令コード手段を保存し保持しているコンピュータで使用可能な媒体は、
前記コンピュータに前記イニシエータからセッション要求パッケージを受信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにセッション確認を送信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにキー要求を受信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータに前記キー要求が正しくエンコードされていることを確認させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにキー確認を送信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにデータパッケージを受信させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータにパッケージ確認によって応答させるためのコンピュータで読み取り可能な命令コード手段と、
前記コンピュータが終了セッション要求を受信するまで、前記コンピュータにデータパッケージを受信させ、パッケージ確認によって応答させるためのコンピュータで読み取り可能な命令コード手段と、
を備えている。
【請求項５２】
請求項５１に記載のコンピュータで使用可能な媒体であって、セッション要求パッケージはイニシエータのIPアドレスとプロフィールデータを備えている。
【請求項５３】
請求項５１に記載のコンピュータで使用可能な媒体であって、さらに前記コンピュータに公開セッションキーを保持している新規セッションキーの組を生成させるためのコンピュータで読み取り可能な命令コード手段を備えている。
【請求項５４】
請求項５３に記載のコンピュータで使用可能な媒体であって、セッション確認は、セッションキーの組と、公開セッションキーと、プロフィールデータと、を備えている。
【請求項５５】
請求項５４に記載のコンピュータで使用可能な媒体であって、キー要求は、イニシエータの公開セッションキーと、前記イニシエータのプロフィールデータと、を備えている。
【請求項５６】
請求項５５に記載のコンピュータで使用可能な媒体であって、セッション確認はさらに公開セッションキーを備えている。
【請求項５７】
請求項５６に記載のコンピュータで使用可能な媒体であって、キー要求は公開セッションキーによってエンコードされている。
【請求項５８】
請求項５１に記載のコンピュータで使用可能な媒体であって、確認ステップは、キー要求をデコードし、前記キー要求が適切にフォーマットされていることを検査すること、を備えている。
【請求項５９】
データ交換のためのシステムであって、
a)サードパーティサーバと、
b)ウェブホストサーバと、
c)取引相手プロフィールテーブルを保持しているコマースサーバと、
d)顧客コンピュータ、ウェブホストサーバ、及びコマースサーバを接続する第１のネットワークと、
e)第２のネットワークによってコマースサーバに接続され、コマースサーバからの遠隔手順コールに応答するアプリケーションサーバと、
を備えている。
【請求項６０】
請求項５９に記載のデータ交換のためのシステムであって、第１のネットワークは複数の区分を備えている。
【請求項６１】
請求項６０に記載のデータ交換のためのシステムであって、第１のネットワークの少なくとも一の区分は、ワイヤレス、光ファイバ、赤外線、ハンドヘルドコンピュータ、及び音声認識装置からなるグループから選択される。
【請求項６２】
請求項５９に記載のデータ交換のためのシステムであって、第２のネットワークは複数の区分を備えている。
【請求項６３】
請求項６２に記載のデータ交換のためのシステムであって、第２のネットワークの少なくとも一の区分は、ワイヤレス、光ファイバ、赤外線、ハンドヘルドコンピュータ、及び音声認識装置からなるグループから選択される。
【請求項６４】
請求項６３に記載のデータ交換のためのシステムであって、イニシエータはさらにウェブブラウザを備えている。
【請求項６５】
データ交換のための方法であって、
a)アプリケーションサーバ、サードパーティサーバ、ウェブホストサーバ、及びコマースサーバからなるグループから選択されるデータを含むトランザクションを始動するイニシエータと、
b)アプリケーションサーバ、サードパーティサーバ、ウェブホストサーバ、及びコマースサーバからなるグループから選択された前記トランザクションを受信するレスポンダと、
c)前記トランザクションを送受信するために高水準の暗号化を使用するポイントツーポイントの安全な転送プロトコルとを備え、前記プロトコルは、
１）イベント待ち状態経由でアクティブリスナを確立するためのコンピュータで読み取り可能な命令コード手段と、
２）取引相手プロフィールテーブルにアクセスしたりイニシエータの識別を判断し、どのようなトランザクションであれば前記イニシエータとレスポンダは相互に許可することに同意し、前記トランザクションのためのデータの場所とフォーマットを判断し許容できる値を判断するためコンピュータで読み取り可能な命令コード手段と、
３）前記イニシエータが許可されてない場合、セキュリティエラーを生成してコードを終了させるためのコンピュータで読み取り可能な命令コード手段と、
４）アクティビティログにアクティビティを書き込むためのコンピュータで読み取り可能な命令コード手段と、
５）イベント状態の処理と判断のためのコンピュータで読み取り可能な命令コード手段であって、イベント状態は、アクティビティ停止中、セッション要求、セッション確認、キー要求、キー確認、データパッケージ、次のデータパッケージ、パッケージ確認、終了要求、及び終了確認からなるグループから選択される手段と、
６）取引相手間で設定するビジネス対話であって、特定の時間とイベント式のトランザクションセットを備えているものと、
７）イベント状態に適切なヘッダとカーゴを構築するためのコンピュータで読み取り可能な命令コード手段と、
８）それぞれの伝送のために固有の暗号化キーの組を生成するためのコンピュータで読み取り可能な命令コード手段と、
９）前記固有の暗号化キーの組を使用してデータを圧縮して暗号化するためのコンピュータで読み取り可能な命令コード手段と、
１０）データが前記イニシエータと前記レスポンダとの間で転送されている間、データがサーバのハードドライブ上に保存されるのを防ぐ、データを前記レスポンダに送信するためのコンピュータで読み取り可能な命令コード手段と、
１１）データを受信、解読、復元するためのコンピュータで読み取り可能な命令コード手段と、
を備えている。
【請求項６６】
請求項６５に記載のデータ交換のための方法であって、データはテキスト、２進オブジェクト、画像、音声レコード、データストリーム、EDI、XML、及びEDIFACTからなるグループの少なくとも一つを備えている。
【請求項６７】
請求項６５に記載のデータ交換のための方法であって、ホスティングシステム上で生成する固有の署名キーは、ユーザ入力から生成されたパスフレーズと、事後否認防止を容易にする固有のシステムＩＤとから派生する。
【請求項６８】
請求項６５に記載のデータ交換のための方法であって、公開キーの共有は、直接取引相手間だけで一つのセッションの間に限って使用される。
【請求項６９】
請求項６５に記載のデータ交換のための方法であって、イニシエータとレスポンダの公開キーは、文字列値を任意に選ばれた場所に挿入することによって固有に作成される。
【請求項７０】
請求項６５に記載のデータ交換のための方法であって、送信者と受信者のＩＤの二方向性の検証は、あらゆるデータの交換の事前に遂行される。
【請求項７１】
請求項６５に記載のデータ交換のための方法であって、取引相手の確認のために使われる公開署名キーと、データのエンコード／デコードのために使われる公開交換キーは、別個に交換される。
【請求項７２】
請求項６５に記載のデータ交換のための方法であって、イニシエータは有効とされた相手に提供されたデータを完全に管理し続ける。
【請求項７３】
請求項６５に記載のデータ交換のための方法であって、データパッケージ全体は伝送の前にエンコードされる。
【請求項７４】
請求項６５に記載のデータ交換のための方法であって、指定受信者がデータを受け取ったことが確認される。
【請求項７５】
ビジネス対話を始動して管理するためのキューを基にした方法であって、
インバウンド伝送はウェブホストとサードパーティサーバからなるグループから発生しており、
ビジネス対話は少なくとも一つのトランザクションとコマースサーバを備え、
前記コマースサーバは取引相手プロフィールテーブル、トランザクションエンジンキュー、応答要求キュー、トランザクションエンジンアウトバウンドキュー、SDSトランザクションキュー、移送プロトコルアウトバウンドキューを備え、第１のネットワークによってウェブホストサーバとサードパーティサーバの少なくとも一つに対話的に接続し、第２のネットワークによってアプリケーションサーバに対話的に接続し、
a)インバウンド要求を受信し、イニシエータとレスポンダを決定し、要求のデコードと復元を行い、出力の送信先を決定し、前記トランザクションエンジンキューに追加し、
b) 前記インバウンド伝送を少なくとも一つのトランザクションに分解し、前記イニシエータに許可を与え、それぞれのトランザクションのためのデータ構造を準備し、前記トランザクションエンジンキューに前記トランザクションを返し、
c)ビジネストランザクションマップを利用することによって前記ビジネス対話を構築及び管理し、前記応答要求キー、前記移送プロトコルアウトバウンドキュー、及び前記SDSトランザクションキューから選択された適切なキューに前記トランザクションを転送する、
ステップを備えている。
【請求項７６】
請求項７５に記載のビジネス対話を始動するためのキューを基にした方法であって、インバウンド伝送は、第１のネットワークに対話的に接続しているウェブホストサーバとサードパーティサーバからなるグループから受信される。
【請求項７７】
請求項７５に記載のビジネス対話を始動するためのキューを基にした方法であって、トランザクションの最終送信先はアプリケーションサーバである。
【請求項７８】
請求項７５に記載のビジネス対話を始動するためのキューを基にした方法であって、ステップ（c）はさらに、少なくとも一つの未来の対話的なトランザクションを構築及び管理し、応答要求キューにその未来のトランザクションを転送する。
【請求項７９】
請求項７５に記載のビジネス対話を始動するためのキューを基にした方法であって、ステップ（c）はさらに、移送プロトコルアウトバウンドキューにアウトバウンドトランザクションを送信する。
【請求項８０】
請求項７５に記載のビジネス対話を始動するためのキューを基にした方法であって、ステップ（c）はさらに、SDSトランザクションキューからその最終送信先であるアプリケーションサーバにトランザクションを送信する。
【請求項８１】
ビジネス対話を始動して管理するためのキューを基にした方法であって、
アウトバウンド伝送はアプリケーションサーバから発生している、
ビジネス対話は少なくとも一つのトランザクションを備え、コマースサーバを備えており、
前記コマースサーバは取引相手プロフィールテーブル、トランザクションエンジンキュー、応答要求キュー、トランザクションエンジンアウトバウンドキュー、SDSトランザクションキュー、及び移送プロトコルアウトバウンドキューを備え、第１のネットワークによってウェブホストサーバとサードパーティサーバの少なくとも一つに対話的に接続し、第２のネットワークによって前記アプリケーションサーバに対話的に接続し、
a)アウトバウンドトランザクションを受信し、前記トランザクションを読み込み、分解し、フォーマットし、前記トランザクションエンジンアウトバウンドキューに追加し、
b)全体データベース構造マップを基にした受取人の所定のフォーマットに前記トランザクションを分解し、
c)少なくとも一つのトランザクションの受取人を決定し、前記アウトバウンドトランザクションを構築し、前記トランザクションエンジンキューへ転送し、
d)少なくとも一つの未来の対話的なトランザクションを構築及び管理し、応答要求キューに未来のトランザクションを転送し、
e)前記アウトバウンドトランザクションを圧縮し、記録し、エンコードし、
f)前記トランザクションをその最終転送先に伝送する、
ステップを備えている。
【請求項８２】
請求項８１に記載のビジネス対話のアウトバウンド伝送を送信するためのキューを基にした方法であって、前記アウトバウンド伝送の最終送信先は、第１のネットワーク上のウェブホストサーバとサードパーティサーバのグループから選択される。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明の分野は、一つのシステムに保管され使用された一以上の形式のデータを、他のシステムによって保管され使用された一以上の形式に変換して情報を共有する方法とシステムの使用に関係している。この発明の他の態様は、コンピュータシステムにエンコードされたデジタル署名形式のデータの送受信を許可することにより、公共または私的ネットワーク上へ安全にそのデータの送受信をすることが可能となることに関係している。その他の態様として、コンピュータにより生み出されたキー操作を使用して人のデータ入力を模擬することにより、保存されたデータをソフトウェアアプリケーションのグラフィカル・ユーザ・インターフェイスによって入力可能とすることに関係している。
【背景技術】
【０００２】
長年にわたって、財務、会計、統計、その他の種類のエンコードされたデータは保存、操作、配信され、最終的には一以上の私設システムから一以上の送信先の私設システムに転送されてきた。これらエンコードされたデータを使用するシステムは、単純で手動方式のカードカタログシステムから難解なアルゴリズムを伴った大型汎用コンピュータシステムに及んでいる。これらエンコードされたデータを使うシステムが直面している一つの重要な問題として、二つのシステムが異なるデータ形式を使用している時は、一つのシステムからもう一つのシステムにデータを転送する能力が欠けていることがある。例えば、カードカタログシステムは文章化されたテキストデータの索引カードを使い、特にメインフレームは、磁気媒体を使ってデータを保存するため、二つのシステムのオペレーターは文章化されたデータを持って大型汎用コンピュータシステムに移し替えるという方法をとるしかなかった。
【０００３】
この従来的なシステムの下で、データを変換しそのデータを送信先のシステムに送るというタスクは、手動でデータ入力したり、相違するデータを使って二つの固有のコンピュータを導入したシステムの場合、どちらかのシステムのデータを変換し他のシステムでも使用可能にするため、アプリケーションプログラマーのチームを採用し、特定のソフトウェア・インターフェイス・アプリケーションを設計するというような物理的な方法によって通常達成している。この方法は、固有のデータ形式が新しく導入されるか修正される度に、それぞれのシステムの個々の調整が必要となってくる。
【０００４】
従来の方法のアプリケーションとその関連データの統合は、リモート・プロシージャー・コール(RPC)の構造に関係している。RPCはアプリケーションが送信先のコンピュータで動いている関数呼び出しをしてコード化する時に起こる。このアクティビティは特別なプロトコルサポートをまとめることが必要で、適切なメッセージを協同しているコンピュータ間を往復して送受信し要望に応える。RPC技術の例として、マイクロソフト・コンポーネント・オブジェクト・モデル（COM）の一部としてDCOM、COBRAの一部としてIIOP、Javaの一部としてRMIが挙げられる。これら分散化オブジェクトシステムは、分散化が進むほど統合することが難しいことが知られている。これらのシステムは、システム間の互換性の情報を得るために、送信先システムの深い知識に依存している。
【０００５】
そのようなシステムの例として、標準ネットワーク接続を通してユニシス1100オペレーティングシステムと通信できるタンデムシステムがある。これらのシステムはしばしば小さな機能のセットとして、それぞれ個々のアプリケーションが書き込まれ導入された後だけにユーザが変数を変えたり、データを変換することを許可している。その上、メインフレームシステムのような専用のコンピュータシステムは、時間がかかる、プロジェクトごとに異なるやり方という犠牲を払って限られたプログラミング能力を提供している。
【０００６】
最近では、新たなる技術でコンピュータファイルという形式でデータを保存、流通、操作、検索することを実現化し人気が高まっている。これらのファイルは、複数の形式で、ハードディスク、CD-R、CD-RWディスク、DVDディスク、ランダム・アクセス・メモリ(RAM)、そしてフラッシュメモリを含む多数の形式のデジタルメディアに保存することができる。これらのデータファイルは、各種サーバ上で保存され取り扱われる。サーバとは、多数のユーザによってネットワーク上で共有して使用されるコンピュータであったり、またサーバはハードウェアやソフトウェア両方、もしくは単にサービスを提供するソフトウェアのことを指していることもある。例えば、ウェブサーバはコンピュータ内で他のアプリケーションを走らせるウェブサーバソフトウェアのことを指すこともあり、またウェブサーバ・アプリケーションだけに特化したコンピュータシステムの場合もある。広大なウェブサイトには幾つかの特化したウェブサーバが存在すると考えられる。その他特定のサーバの例として、アプリケーションサーバ、音声サーバ、コマースサーバ、ファックスサーバ、ファイルサーバ、企業内サーバ、メールサーバ、商業サーバ、モデムサーバ、ネットワークアクセスサーバ、プリントサーバ、プロキシサーバ、そして遠隔アクセスサーバがある。
【０００７】
データベースは、データベース管理システム(DBMS)によって作られ管理されている関連したファイルのセットである。今日、DBMSはテキスト、画像、音声、ビデオを含むどんな形式のデータも管理できる。データベースとファイル構造は、常にソフトウェアによって決定され、これらのデータベースは一般的に一以上のサーバ上にある。同じく一以上のサーバに位置するソフトウェアアプリケーションも、データベース内のデータや、指定された、または規定のプロトコルを基準としてフォーマットされたソフトウェアによって使用されたデータを使っている。
【０００８】
「バックオフィス」は、クライアントのビジネスシステムを構成するソフトウェア製品スイートである。バックオフィスは、通常フォーマット方式を使ってデジタルデータをフォーマットし、そのデータはアプリケーションによって保存され、使用されることが可能となる。最も人気の高い「バックオフィス」タイプのシステムは、MYOB、Accubooks、そしてQuickbooksである。これらのソフトウェアアプリケーションはデータのフォーマットをこれから使用可能であるフォーマットとして認識するであろう。バックオフィスは、TCP/IP、FTP、SMTPのようなプロトコルを使って、ネットワーク上で理想的に通信するであろう。
【０００９】
一般的に一以上のこれらのプロトコルを使用する企業間のソリューションとして、通常核となる企業運営や物流設備と連結した注文処理を可能にする完全に統合したシステムが挙げられるだろう。この完全に統合されたシステムはまた、電子データ交換(EDI)規格を基準としたものでもあるかもしれない。EDI規格は、全国的に統合され、全国と国際規格のために交換所やインフォメーションセンターの役目をするアメリカ全国規格協会(ANSI)によって管理されている。規格は、唯一の公式規格文書の情報源であるデータ交換規格協会(DISA)によって著作権を保護され流通している。EDI取引の例としては、EDI838取引相手プロフィール、EDI850注文、EDI810請求がある。
【００１０】
多くの会社が、自社のフロントオフィス機能とバックオフィス機能間の連結の確立を困難と考えている。一般的な製品は、企業独自のeコマースとコールセンターのモジュールをその会社の生産、財務会計、営業のモジュールと連携させる。フロントオフィスアプリケーションの例として、営業の人達を補佐するために設計された、リードタイム、顧客、注文、製品情報の記録をとる現場サービスや営業支援活動アプリケーションが挙げられる。バックオフィスアプリケーションの例としては、会計アプリケーションがある。
【００１１】
別の例を挙げると、現在のeコマースソリューションは、通常バックオフィス製品と通信、またはデータの変換のやりとりができない特定のパッケージソフトウェアと関係している。例としては、eコマースが可能なウェブサイトや、QuickBooksのようなバックオフィス製品の会計アプリケーションが、直接適合することができないショッピングカート付きのウェブサイトがある。
【００１２】
フロントオフィスがバックオフィスと互換性がない状態では、典型的なユーザは安全なサーバからデータを受信し、手動で移送するフォーマットにダウンロードし、クライアントのバックオフィスアプリケーションにアップロードする。同様に、クライアントのバックオフィスアプリケーションのデータもファイルに転送され、それからフロントオフィスや他の会社のシステムに読み込まれたり、提示されたりすることもあり得る。
【００１３】
企業間の場合では、化学薬品の交換を行っている会社は、ベンゼンの見積価格の要望を提示して、５つの入札があったとする。買い手は一番低い付け値を選択するだろうが、ほとんどの場合は二社のシステムが電子的に通信不能なので、買い手は仕入れ先に電話をしてオフラインで取引を処理する。この発明は、会社のバックオフィス・ビジネス・アプリケーションから外部の会社内に位置する既存の外部標準プログラムへのデータの送受信を、この会社に許可することでこの問題に対処している。この発明は、内部登録かネットワークを基盤とした登録なのか確認することを可能にすることもでき、ある意味では売り手のコンピュータが使用しているデータ形式を買い手のバックオフィス購入システムが自動的に調べることを許可している。買い手のシステムは、その後電子注文書を適切なフォーマットにて送付することによって、オンラインで商談を成立させることができる。
【００１４】
その他のより大規模な事業として、企業資源計画、またの名をERPがある。これは、統合された情報システムを企業内全ての部門に提供するものと関係がある。製造業から発展したERPは、一顧客によって、またはそのために開発された独自のソフトウェアよりもパッケージソフトウェアの使用を意味している。ERPのモジュールは、組織独自のソフトウェアとさまざまな度合いでの努力によって連結することが可能になることもあり、ソフトウェアによっては、ベンダー独自のツールだけでなく、独自仕様もしくは標準のプログラミング言語でERPモジュールを修正できる可能性がある。ERPシステムは、生産、受注、債権債務、総勘定元帳、購買、倉庫保管、配送、人的資源のソフトウェアを取り込むことが可能である。主要なベンダーとしては、SAP、PeopleSoft、Oracle、Baan、J.D.Edwardsがある。重ねて、それぞれのシステムの各々のモジュールは相互運用性を発生させるため、それぞれ目的のシステムと個別に同調し統合されてなければならない。
【００１５】
流通しているビジネスコンピュータをもとに統合する方法は、難しいタスクであり組織間やコンピュータシステム間であってもしばしば法外に高価になる。多くの主要会社が高価な独自仕様のシステムを使って業務プロセスの統合を促進している。そういう次第なので、同じような統合タスクを成し遂げることが、中小企業にも大いに必要とされている。
【００１６】
故に、今のところ一つのバックオフィスシステムからのデータ、そのデータとフロントオフィスシステムや他のコンピュータのバックオフィスシステムとの連携を十分に活用することができない。
【発明の開示】
【課題を解決するための手段】
【００１７】
システムの間で使用されるデータの変換及び経路設定に使用されるいくつかのオブジェクトが本明細書に説明されている。本発明の一つの目的は、一つのフォーマットのデータを別のフォーマットのデータに変換して、データを一つ以上のアプリケーションで使用するための方法及び装置に関する。特に、本発明はビジネス文書、及びEDIや他の公知の標準的なデータフォーマットを使用するデータを、自動交換することを容易にする。
【００１８】
本発明のいくつかの特徴としては、本発明は私設システムと比べて比較的安価であり、本発明はLANともWANとも使用できて、本発明はEDIはもちろん、ASCII、XML、或いはネイティブデータベースのデータフォーマットを使用する能力も兼ね備えている。本発明はスタンドアローンアプリケーションとして、顧客のコマースサーバと共に使用するか、或いはASPを通じて使用方法に基づいた機能を提供するように使用されることができる。
【００１９】
本発明の一つの目的は、コンピュータネットワークにおいて分散されたビジネスコンピュータに基づいた処理を統合する方法及び装置に関する。本発明の別の目的は、データを標準化してコンピュータネットワークに於ける二つ以上の異なるシステムの間で交換可能にするための方法及び装置に関する。他の発明の目的は、安全なプロトコルを使用して、データがコンピュータネットワークのシステムの間を移動するときに、データをエンコードし、デジタル署名し、そして圧縮して最適化することに関する。
【００２０】
本発明の一つの態様は、異なるコンピュータアプリケーションの間でデータを共有するためのソリューションを提供することに関する。本発明の別の態様は、データを一意にエンコードする一つ以上の識別子を使用して、データ送信を安全にすることに関する。
【００２１】
別の発明の態様は、データ変換及び経路設定を自動化及び標準化することで、コンピュータネットワークに於ける二つ以上のシステムの間でデータを交換することを可能にすることに関する。
【００２２】
もう一つの発明の態様は、本発明が、既存のオペレーティングシステムと、移送機構と、ビジネス文書と、データフォーマットを交換可能に使用する能力に関する。もう一つの発明の態様は、経済的にデータを交換可能に提供することに関する。
【００２３】
別の発明の態様は、本発明の、ビジネス対話を完了するために必要な全てのトランザクションの作成、追跡、及び完了の保証をする能力に関する。
【００２４】
また別の発明の態様は、それぞれのフォーマットに関係なく、様々な既製のソフトウェアアプリケーションで使用できるデータを作成することに関する。
【００２５】
本発明の別の態様は、様々なフォーマットのデータを組み合わせて一つの一貫してフォーマットされたデータベースを設置することに関する。
【００２６】
別の発明の態様は、「確認」という形で、コンピュータネットワークに提出されたデータの精度及び保全性のチェックを行うことに関する。
【００２７】
更には、他の発明の態様は、本発明が保持する既存のデータベースとデータプロパティを確認して、データの保全性及び適切なフォーマッティングを確認して、外部のデータソースの精度のチェックを行うことに関する。
【発明を実施するための最良の形態】
【００２８】
ここの記載される複数の実施態様は、変換に関連した用途や、一以上のコンピュータネットワークで使用する電子ビジネスデータのための方法と装置に関係する。しかしながら、その方法と装置はどんな適切な種類のデータやファイルに関連しても等しく応用できることは明らかであろう。
【００２９】
一つの実施態様では、システムが４つのモジュールからできている。第１のモジュールは主要な部分で、起動機能から成っている。第２のモジュールは、販売機能から成り立っている。それはさらに進んで、購買、請求、承認のトランザクションから構成されている。第３のモジュールは、出荷機能である。  それは出荷状態と製品返却のトランザクションから構成されている。第４のモジュールは、支払許可、掛売り、そして勘定残高のトランザクションからなる売掛金機能である。
【００３０】
使用されるビジネスインフォメーションデータについては、この実施態様は、クライアントによって使用された特定の会計ソフトウェアアプリケーションのようなソフトウェアを含む、取引相手や第三者のコンピュータシステムからクライアントのバックオフィスに十分なeコマースの機能性を提供するシステムである。  機能性に関しては、システムは多種多様な変化に富んだフロントオフィスシステムばかりでなく、多種多様な数のバックオフィスシステムとも一緒に機能することができる。
【００３１】
この発明は、一群のデータを、さもなければ互換性を有しない一以上のアプリケーションで利用する手段を提供している。バックオフィスシステムは、通常一以上のサーバから構成されており、ソフトウェアアプリケーションスイートは、クライアントの内部企業運営のバックボーンを提供する。コマースサーバの業務システムは、普段はバックオフィスの業務システムを支えるであろうものであり、例としてはマイクロソフトのWindows 98がある。バックオフィスで見かけるであろうソフトウェアアプリケーションスイートの幾つかの例として、PeopleSoft、MYOB、そしてPeachtreeが挙げられる。
【００３２】
遠隔ホストデータベース上でビジネスインフォメーションデータを識別するために、様々な方法とシステムも公開されている。
【００３３】
概して言えば、システム方法論には以下のステップを含む。(1)送信元コンピュータで、アプリケーションスイートからのトランザクションデータを処理、(2)データのあるべき形の初期定義に基づいて、標準化されたデータトランザクションの生成、(3)送信元コンピュータから送信先のコンピュータへ、標準化されたトランザクションデータを送信、(4)送信先コンピュータにおいて、送信元コンピュータからのトランザクションデータを受信、(5)送信先コンピュータの特性に基づくトランザクションデータを生成し、送信先コンピュータ上のファイルにトランザクションデータを保存、(6)送信先のコンピュータにて、データファイルからのトランザクションデータを目的のアプリケーションスイートへ処理。
【００３４】
公開された実施態様は、ユーザがコンピュータネットワーク上の様々なサーバにあるビジネスと財務情報を管理する手段を提供している。見返りとして、一般消費者向きeコマースサービス会社（B2C）のようなeビジネス会社は、フロントオフィス、具体的にはその会社のウェブサイトからバックオフィスソフトウェアアプリケーションスイートへ（その逆もまた同様に）、もっと動的なインターフェイスをもった価値のあるサービスをクライアントに提供する機会に恵まれている。その上、コンピュータは、企業間（B2B）の状態として他の企業、または企業間（B2E）の状態としても知られる同じビジネス内で地理的には異なった事務所間で、自動的にデータ交換をすることに使用されている。コンピュータやその他のインテリジェントな装置がデータの共有と管理のために必要になってきており、この発明は、様々なデータ形式を管理、仕分け、共有、交換、そして相互作用のよりよい方法を作成する、インテリジェントかつフレキシブルなこれらの装置を巧みに利用している。
【００３５】
仮定的な状況では、クライアントは製品および／またはサービスを販売するベンダーにアプローチして、同じ製品および／またはサービスを要求する。ベンダーは、物理的なハードウェアをインストールするか、今のハードウェアを適応させるためこの発明の必要条件に適合させる必要がある。例えば、クライアントは通常Microsoft Windows NT オペレーティングシステムを走らせているIBM Pentium IIIを基にしたシステムのようなアプリケーションサーバのネットワークシステムを保持している。このアプリケーションサーバは、それ以降、財務、販売、売掛金、買掛金、出荷のソフトウェアモジュール、またはパッケージに関係しているクライアントのビジネスアプリケーションを保持することになる。これらのソフトウェアパッケージの例として、PeachtreeのAccountingソフトウェアや、IntuitのQuickbooksソフトウェアパッケージ、その他レガシーのソフトウェアシステムが含まれる。
【００３６】
様々なソフトウェアアプリケーションを使って、クライアントは対象とするビジネス機能の完了につなげるため情報の交換を始める。このビジネス機能は通常、場所、連絡先名、製品カタログ、為替レートを含むビジネスインフォメーションの交換から始まる。クライアントはその後、ベンダーから製品および／またはサービスを購入する意向を記述する「注文書」を送付する。注文書に引き続き、値段、手数料、費用、そして容認された支払方法を含む製品および／またはサービスが購入されたことが詳しく述べられている「請求書」である。請求書に続いては、支払方法、口座情報と資金が引き落とされる金融機関を識別する「支払承諾」がある。ベンダーは支払を受け取ってシステム内のクライアントの口座が清算されたら、ビジネス機能を締めくくる。
【００３７】
より詳細な解説が、いかにしてこの発明の最良の態様を構成し使用するか当業者に教えるために、提供されている。１段階目は発明がインストールされ構成情報が確立される起動フェーズ、それはこの発明の機能性として関係してくる。２段階目はビジネスの話し合いや交換をとりなす個々の取引が執り行なわれる処理フェーズである。
【００３８】
図１は、一以上のネットワーク104と105を通してつながっている複数のサーバを含むシステム100のブロック線図を示している。図１に表されているように、コンピュータシステム100は、ウェブホストサーバ101、サードパーティサーバ102、コマースサーバ103、そしてアプリケーションサーバ106を含む。図１に表示されているそれぞれのサーバは、単一サーバに対応する複数のサーバを含むかもしれず、それらすべてがシステム100の中において機能する。例えば、アプリケーションサーバ106は、一以上の「コントロール」サーバと一以上の「データベース」サーバを含むこともある。もしインターネットが、一以上のネットワーク104として使用されたら、この図には載っていないが、ウェブサーバはネットワーク104内の中継サーバとして使われることもある。
【００３９】
図１はさらに、起動、初期化して稼働するこの発明の今の実施態様に使う基本的な部品間の相互関係も説明してある。コマースサーバ103は、どれにも適合し直接接続もできるネットワーク105を経てアプリケーションサーバ106に接続する。コマースサーバ103は、装置間で最高の相互接続を提供するために、この発明の他の要素と一緒に設置することができ、クライアントが所有している設備と同じ場所に設置することも可能である。複数のコマースサーバ103のみならず複数のアプリケーションサーバ106が存在することも可能である。システム100内の全てのサーバは、コマースサーバ103の物理的な配置に関してローカル、リモートのいずれであってもよい。直接キーボード入力とその結果の表示を通してするユーザとのやりとりに加えて、図１のシステム100のそれぞれのサーバは、適切に接続された遠隔ユーザワークステーションから処理を始めたり資源を指示することができるようにしてもよい。
【００４０】
この発明は、コマースサーバが接続しているどの標準ネットワーク（この場合はネットワーク104と105）上でも機能するトランザクションを生成する。サーバ103は、ネットワーク105上でRPCを使ってサーバ106上の資源を指示する。
【００４１】
この発明が機能する一般的なネットワーク104や105の例として、地域や国のような広い地理上の区域を含むコミュニケーションネットワークである広域ネットワーク(WAN)、ビルや施設の中だけを一般的に含むネットワークであるローカルエリア・ネットワーク(LAN)、都市や郊外を通常範囲とするネットワークの都市規模ネットワーク(MAN)が挙げられる。一歩進んだ例として、多数の小規模ネットワークから成る大規模ネットワーク、100以上の国の何百万というコンピュータから成るインターネットがある。
【００４２】
図２は、図１のウェブホストサーバ101の線図で、一以上の他のウェブホストサーバの代表であってよい。ウェブホストサーバ101は、中央演算処理装置(CPU)201、ランダムアクセスメモリ(RAM)202、読み出し専用メモリ(ROM)203、コミュニケーションポート204、そしてデータ記憶装置206を含む。CPU201はコミュニケーションポート204と対になっているので、ユーザはネットワーク104上で通信できる。図示されていないが、ウェブホストサーバ101はユーザのためのキーボード、マウス、視覚的ディスプレイ、オーディオスピーカーなどの多彩な入出力(I/O)装置を含んでよい。ウェブホストサーバ101は、UNIX、Linux、それ以外の適切なオペレーティングシステムなどのオペレーティングシステムも実行させている。データ記憶装置206は、ハードディスクドライブ、CD-RWドライブ、FLASHアレイ、その他大容量記憶装置などであり、ローカルデータベースファイル207、ローカルプログラム208、プラグインコミュニケーションと一般ファイル209を含む。
【００４３】
図３は、図１のサードパーティサーバの図で、一以上の他のサードパーティサーバの代表でありうる。サードパーティサーバ102は、中央演算処理装置(CPU)、読み出し専用メモリ(ROM)303、ランダムアクセスメモリ302、コミュニケーションポート304、そしてデータ記憶装置306を含む。CPU301はコミュニケーションポート304と対になっているので、サードパーティサーバ102はネットワーク104上で通信できる。図示されていないが、サードパーティサーバ102はユーザのためのキーボード、マウス、視覚的ディスプレイ、オーディオスピーカーなどの多彩な入出力(I/O)装置を含むことができる。サードパーティサーバ102は、UNIX、Linux、それ以外の適切なオペレーティングシステムなどのオペレーティングシステムも実行させている。データ記憶装置306は、ハードディスクドライブ、CD-RWドライブ、FLASHアレイ、その他大容量記憶装置などであってよく、ローカルデータベースファイル307、ローカルプログラム308、コミュニケーションと一般ファイル309を含む。コミュニケーション及び一般ファイル309は、この発明の他の完全にインストールされ設定したバージョンで構成されたものが望まれるが、単に適応したプラグインコミュニケーションオブジェクトと具体化されたデータで構成することもある。
【００４４】
図４は、図１のコマースサーバ103の図で、一以上の他のコマースサーバの代表でありうる。コマースサーバ103は、中央演算処理装置(CPU)401、ランダムアクセスメモリ402、読み出し専用メモリ403、コミュニケーションポート404、コミュニケーションポート405、そしてデータ記憶装置406を含む。CPU401はコミュニケーションポート404と対になっているので、コマースサーバ103はネットワーク104上で通信でき、そしてCPU401はコミュニケーションポート405と対になっているので、コマースサーバ103はネットワーク105上で通信できる。図示されていないが、コマースサーバ103はユーザのためのキーボード、マウス、視覚的ディスプレイ、オーディオスピーカーなどの多彩な入出力(I/O)装置を含むかもしれない。コマースサーバ103は、Windows NT、Windows 98、それ以外の適切なオペレーティングシステムなどのオペレーティングシステムも実行させている。データ記憶装置406は、ハードディスクドライブ、CD-RWドライブ、FLASHアレイ、その他大容量記憶装置などであり、ローカルプログラム407、ローカルデータベースファイルとテーブル408、そしてトランザクションキューとログ409をできれば含む。
【００４５】
ローカルプログラム407には、実行可能プログラム410、プログラムファイル411のスイート、そして初期化ファイル412が含まれている。ローカルデータベースとテーブル408は、取引相手プロフィールテーブル413、全体データベース構造414、ビジネストランザクションマップ415、顧客SQLデータテーブル416を含む。トランザクションキューとアクティビティログ409は、トランザクションエンジンキュー417、応答要求キュー418、トランザクションエンジンアウトバウンドキュー419、記号データストリーム(SDS)トランザクションキュー420、移送プロトコルアウトバウンドキュー421、そしてアクティビティログ422を含む。
【００４６】
図５は、図１のアプリケーションサーバ106の図で、一以上の他のアプリケーションサーバの代表でありうる。アプリケーションサーバ106は、中央演算処理装置501、ランダムアクセスメモリ502、読み出し専用メモリ503、コミュニケーションポート504、そしてデータ記憶装置506を含む。CPU501はコミュニケーションポート504と対になっているので、アプリケーションサーバ106はネットワーク105上で通信できる。図示されていないが、アプリケーションサーバ101はユーザのためのキーボード、マウス、視覚的ディスプレイ、オーディオスピーカーなどの多彩な入出力(I/O)装置を含むかもしれない。アプリケーションサーバ101は、Windows NT、Windows 98、それ以外の適切なオペレーティングシステムなどのオペレーティングシステムも実行させている。データ記憶装置506は、ハードディスクドライブ、CD-RWドライブ、FLASHアレイ、その他大容量記憶装置などであり、ローカルデータベースファイル507、ローカルプログラム508、バックオフィスアプリケーション509をできれば含む。
【００４７】
通常、ビジネストランザクションデータが入ったファイルは、ローカルのコマースサーバ103かリモートのアプリケーションサーバ106に存在することができる。ビジネスデータファイルの一般的な例として、請求形式、注文形式、勘定残高形式、そして支払送金通知形式が挙げられる。
【００４８】
この中で述べられた多数の実施態様が、デジタルファイルに保存されたビジネス情報のデータと関係している。この中のデータ、レコード、テーブル、フィールド、特性、ユーザによって決められた特性のような多くの用語は、コンピュータソフトアプリケーションにあるような技術的アプリケーションのコンテクストのもとで解釈されなければならず、いかなるものであっても精神的な、または「紙と鉛筆」タイプの対象と同じように読み込まれるべきではないことに注意を喚起しておく。フィールドは、ローカルデータベースとテーブル408の中にあるデータを、（構造とファイルに応じて）別々にもしくは一緒に固有のものとして識別する。
【００４９】
テーブルの一つに取引相手プロフィールテーブル413があり、クライアントと取引先のネットワークの両方の場所だけでなく、クライアントと取引先の正式なビジネス構造を定義化した情報である。このフィールドの例として、プロフィール名、インターネットプロトコル(IP)アドレス、許可された取引、トランザクションフォーマットを含む。トランザクションフォーマットの例としては、EDI、XML、EDIFACTがある。
【００５０】
その他のローカルデータベースとテーブル408のテーブルとして、全体データベース構造414があり、他のサーバによってどのようにデータがアクセスされたかの情報やどこでデータが使用されたかの情報を含む、コマースサーバ103にある全てのデータのソースの定義情報が含まれている。全体データベース構造414フィールドの例として、フィールド名、ソース、アクセス方法、許容量、データタイプ、データサイズ、必須か任意かの選択を含む。
【００５１】
その他のローカルデータベースとテーブル408のテーブルとして、ビジネストランザクションマップ415があり、コマースサーバ103に必要なインターフェイスの種類によって、システム100のトランザクションフローと個々のトランザクションを管理するための定義情報を含む。バックオフィスとのコミュニケーションに必要な特定のトランザクションのマップは整備されている。ビジネストランザクションマップ415フィールドの例として、トランザクション識別子、追加ビジネス会話トランザクション、ビジネストランザクション基準を含む。ビジネストランザクション基準の例としては、システム100内で完了したクレジットカードでの買い物はどれも、出荷には三日間の保留が必要といったことがある。
【００５２】
その他のローカルデータベースとテーブル408のテーブルとして、アウトバウンドトランザクションのデータ蓄積のための情報源とインバウンドトランザクションのための確認情報源である顧客SQLデータテーブル416がある。テーブル416は、顧客データ、会計データ、出荷データ、製品データを含む、一以上の種類のデータを保持していることがある。
【００５３】
図６は、システム100の方法、システム、装置の起動概要を図示したものである。望ましくは、すでに構築された設定によって、図示されていない幾つかの初期設定後に単独でステップ601は実行され、図１に図示されているコマースサーバ103への電源供給として、周期的に実行されるかもしれない。もう一方で、ステップ601は、コマースサーバ103（または、ネットワーク105に接続した適切なワークステーション）へのstartup.exeのような実行可能ソフトウェアファイルを「実行」するための選択のようなユーザ入力に応じて、実行されるかもしれない。
【００５４】
図６の開始ブロック600から始まり、ステップ601は初期化ファイルの存在を判断する。ステップ601は、ファイル内にある記述ファイルヘッダーを読み込んだり他の手段によって、ファイルがコマースサーバ103の記憶媒体406の所定の場所に物理的に存在するか、「システムコール」の使用を通してコマースサーバ103のオペレーティングシステムに尋ねる。ステップ601は、サーバ103上にローカルファイル412が存在しないと判断した場合、ステップ602は、図７により詳細に図示してあるインタビュー処理を始動して有効にする。
【００５５】
図７は、インタビュー処理の概要のフロー図である。図７の開始ブロック700から始まり、ステップ701はもう一度初期化ファイル412がローカルプログラムと実行407に存在するかどうか確認する。このステップで図７のインタビュー処理が他の処理によって開始されたかもしれないので、もう一度確認することは必要であり、もしそのような場合は、ステップ703を実行して初期化ファイル412を実装する必要がある。
【００５６】
ステップ701で初期化ファイル412が存在しないと判断すると、ステップ702はあらかじめ決められた初期設定値をコマースサーバ103上の入力画面に取り込み、図８により完全に図示してあるステップ704を開始する。
【００５７】
図８は、インタビュービジネス機能の概要を図示したフロー図である。図８の開始ブロック800から始まり、ステップ801はコマースサーバ103の一以上のインタビュー入力フォーマットを表示している。ステップ802で、ユーザはサーバ103でユーザが応答したことと関連したフィールドの質問に答え、適宜データ806を入力する。サーバ103のユーザによって入力される、データや識別子からなるデータ806の例として、クライアントがウェブサイトを使用するかどうか、クライアントの会社名と連絡先、クライアントの職種、クライアントのバックオフィスで使われているソフトウェアのＩＤ、その他EDI838トランザクションにできれば収まっているデータが含まれる。ステップ803は、必須データ806が完了しているかどうか判断し、もし完了していない場合は、コントロールはステップ801に戻る。この処理は、ユーザが全ての処理を取り消して終了するか、もしくはステップ803によって必須データが完了とみなされるまで繰り返される。一旦ステップ803が完了すると、データ806はステップ804で使用されて、取引相手プロフィールテーブル413、全体データベース構造414、ビジネストランザクションマップ415、そして顧客SQLデータテーブル416を実装する。一旦ステップ804が完了すると、終了ブロック805に到着し、図７のステップ704が完了する。
【００５８】
次の、図９により詳細に図示されている図７のステップ705は、情報の応用と利用のためにユーザにインタビューする。図９の開始ブロック900から始まる、ステップ901は、コマースサーバ103における一以上のインタビュー入力画面を表示する。ステップ902では、ユーザはユーザが応答する関連フィールドの一以上の質問に答え、適宜データ907を入力する。データ907の例として、認められて使用されたEDIトランザクション、使用された特定データ要素、許容された値、EDI868に収容されているようなその他のデータが含まれる。ステップ903は、必須データが完了しているかどうか判断し、もし完了していない場合は、コントロールはステップ901に戻る。  この処理は、ユーザが全ての処理を取り消して終了するか、もしくはステップ903によって必須データが完了とみなされるまで繰り返される。  一旦ステップ903によってデータ907が完了とみなされると、ステップ904ではデータ907を使用して、取引相手プロフィールテーブル413、全体データベース構造414、ビジネストランザクションマップ415、そして顧客SQLデータテーブル416に実装する。
【００５９】
一旦ステップ904が完了すると、ステップ905がキューとアクティビティログを初期化することにより、それらはきれいでいつでも使える状態になる。ステップ905が完了すると、終了ブロック906に到着し、図７のステップ705が完了する。図７の次のステップ、ステップ706は、全ての初期化データを初期化ファイル412に保存する。ステップ706が完了すると終了ブロック707に到着し、図６のステップ602が完了する。
【００６０】
図１０により完全に図示されている図６のステップ603は、それからオブジェクトをロードして起動する。図１０はオブジェクトのロードと起動の概要図である。図１０は直線的にフロー図が表示されているが、ステップ1001から1006は同時に走っており、お互いに依存していない。ステップ1001を発端に、リソースセンターオブジェクトがロードされ、起動する。ステップ1001、リソースセンターオブジェクトは、図１１によりいっそう完全に図示してある。図１１の開始ブロック1100から、ステップ1101はコマースサーバ103のタスク一覧を列挙することにより、どんな取り残された処理も確認して消去し、走っているオブジェクトを探し出してコマースサーバ103オペレーティングシステムにそのような処理を停止するように要求する。次の、ステップ1102は、TCP/IPポート割当を取得して接続を検査するために、登録されたURLプロキシに接続する。ステップ1103は、コマースサーバ103の表示メモリにユーザインターフェイスフォームをロードし、フォームを隠す。ステップ1104は、もしコマースサーバ103のオペレーティングシステムがこの機能を許可するのであれば、システムトレイにプログラムのアイコンをロードする。一旦ステップ1101から1104まで完了すると、ステップ1105はリソースセンターをイベント待ち状態に位置づける。
【００６１】
イベント待ち状態では、リソースセンターオブジェクトは３つのメニューイベントの内、１つが起こることを待っている。１つの状態は、リソースセンターのアクティブ化イベント1107はユーザインターフェイスフォームを開き（ステップ1110）、コマースサーバ103のユーザに初期化ファイル412に含まれる初期化と構成データが変化に影響することを許可している。２つめの状態は、更新マップイベント1108が、コマースサーバ103のユーザに初期化データ（ステップ1111）を初期化ファイル412に保存することを許可している。リソースセンターのアクティブ化と更新マップイベントは、イベント待ち状態に戻る結果となる。終了処理イベント（ステップ1106）は、コマースサーバ103のユーザに全てのアプリケーション（ステップ1109）を停止させることを許可し、終了ブロック1112にて処理を終了する。
【００６２】
リソースセンターがステップ1105のイベント待ち状態を確立すると、図１２により詳細に図示されている図１０のステップ1002が、バックオフィスコミュニケーションオブジェクトを取り込んで起動する。開始ブロック1200に始まり、初期化データ412は検索される（ステップ1201）。次はステップ1202で、バックオフィスクライアントが始まり、プロセスハンドルが将来使えるようにアクティブメモリに保存される。ステップ1203は顧客SQLデータテーブル416からのデータを使って、アプリケーションサーバ106のローカルデータベースファイル507が優先環境であることを確実にする。
【００６３】
次のステップ1204は、SDSトランザクションキュー420から通過中のトランザクションを処理する。ローカルデータベースファイル507（ステップ1205）の顧客と製品データのために、バックオフィスアプリケーション509から要望が出される。最後に、ステップ1206は求められたデータを使用して、終了ブロック1207にて終える前に現存する顧客SQLデータテーブル416と比較し、必要であれば修正する。図１０のステップ1002もここにて完了する。
【００６４】
EDIトランスレータオブジェクトは、ステップ1003にて次に始動する。ステップ1003は図１３にてより詳細に図示されている。開始ブロック1300にて始まり、EDIトランスレータオブジェクトはイベント待ち状態（ステップ1301）を想定する。ステップ1302は、イベントがこのトランスレータオブジェクトから変換サービスを要求した時、できれば他の処理からEDIデータへの変換の要求の時に起こる。一旦イベント1302が起こると、イベント待ち状態が終了して、ステップ1303でその要求内のデータ解析に使われるヘッダー情報を抽出する。ステップ1304は、できれば、その要求内に含まれる情報を保持するためトランスレータにデータ構造を構築することを許可している、EDI標準トランザクションやEDI868からの電子的形態データを取り込む。ステップ1305は、要求からのデータを抽出してEDIデータ構造を構築し、抽出したデータを要求処理1306に返還する。この処理は終了ブロック1307にて終了し、図１０のステップ1003も同様に完了する。XMLトランスレータはステップ1004にて始まり、図１４により詳細が図示されている。
【００６５】
図１４は、XMLトランスレータオブジェクトの取り込みと起動の図である。図１４の開始ブロック1400にて始まり、XMLトランスレータオブジェクトはイベント待ち状態1401を想定する。ステップ1402のイベントは、他の処理がこのトランスレータオブジェクトの変換サービスの要求をすることから起こる。イベントがステップ1402をいったん引き起こすと、ステップ1403で、その要求から要求内のデータ解析に使用するためにヘッダー情報を抽出する。ステップ1404は、その要求内に含まれる情報を保持するためにトランスレータにデータ構造を構築することを許可するXMLヘッダーからの解析情報を取り込む。ステップ1405は、その要求からのデータを抽出し、XMLデータ構造の構築を行い、抽出したデータを要求処理1406に返還する。この処理は終了ブロック1407にて終了し、図１０のステップ1004も同様に完了する。
【００６６】
次に、図１０のステップ1005は、企業間（B2B）コミュニケーションオブジェクトを初期化する。ステップ1005は、図１５により詳細に図示されている。開始ブロック1500にて始まり、B2Bオブジェクトは、初めに現存するポートの接続が有効かどうか（ステップ1501）を判断する。もし割り当てられたポートが有効でない場合は、ステップ1502は、新しいポート接続を要求し、その間にポート接続が要求された回数を把握し続ける。ステップ1503は、なされた要求が多すぎるかどうか（好ましくは10回かそれ以上）判断して、もしそうなら、コミュニケーションは確立せず、終了ブロック1509に到達する。
【００６７】
もし要求回数がステップ1503の限度を超えなければ、ステップ1501にて処理を継続して再び割り当てられたポートが有効かどうか判断する。一旦ステップ1501が割り当てられたポートが有効であると判断した場合、ステップ1504と1505が同時に始動される。
【００６８】
ステップ1504は、バックオフィスアプリケーション509から製品および／またはカタログ情報を要求して、ステップ1506はデータをできればEDIフォーマットに変換する。ステップ1505は、バックオフィスアプリケーション509から顧客とその他関係する情報を要求し、ステップ1507でそのデータをできればEDIフォーマットに変換する。
【００６９】
ステップ1506と1507の並行処理を完了する時に、ステップ1508はイニシエータとレスポンダイベント状態を起動させ、インバウンドとアウトバウンド企業間トランザクションが起こることが許可されたことを知らせる環境変数の設定をする。一旦ステップ1508が完了すると、終了ブロック1509に到達し、図１０のステップ1005が完了し、そしてB2B企業間相互接続性が設定される。
【００７０】
次の図１０のステップ1006は、初期化ファイル412からのデータを使い企業と消費者間（B2C）コミュニケーションオブジェクトが初期化されるべきかどうか判断し、もし初期化されるのであれば、図１６により詳細に図示してあるステップ1007がウェブホストコミュニケーションオブジェクトを開始する。
【００７１】
図１６の開始ブロック1600にて始まり、ステップ1601は現存するポート接続が有効かどうか判断する。もし現存するポート接続が割り当てられていない場合、ステップ1602は新しいポート接続を要求し、その間にポート接続が要求された回数を把握し続ける。ステップ1603は要求回数が事前に設定した限度を超えていないかどうか判断する。もし要求回数が限度を超えていた場合、ステップ1611は、それからフラグを設定しウェブホストがオフラインでコミュニケーションが設定されていないことを知らせ、終了ブロック1615に到達する。
【００７２】
もし要求回数がステップ1603で限度を超えていない場合、再びポートが有効かどうか判断するために、ブロックステップ1601にて処理は続く。一旦ステップ1601でポートが割り当てられたと判断すると、次ステップのステップ1604、ステップ1605、そしてステップ1606が同時に処理される。
【００７３】
ステップ1604は、ウェブホストサーバ101に、ここに図示されていないコミュニケーション初期化パケットを送信し、ステップ1607で応答を待つ。ステップ1605は、バックオフィスアプリケーション509から製品および／またはカタログ情報を要求し、ステップ1608はステップ1605からのデータをできればEDIフォーマットに変換する。ステップ1606は、バックオフィスアプリケーション509から顧客とその他関係情報を要求し、ステップ1609はステップ1606からのデータをできればEDIフォーマットに変換する。
【００７４】
一旦ステップ1607、1608、1609がタイムアウトとともに完了すると、必要に応じて完了の同期をとり、ステップ1610でウェブサイトサーバ101が有効な応答を送信したかどうか判断する。もし応答が有効でないと判断された場合、または応答がない場合、ステップ1611はフラグを設定しウェブホストサーバ101がオフラインであることを知らせ、終了ブロック1615にて処理が終わる。もしステップ1610がウェブホストサーバの応答が有効であると判断した場合、ステップ1612はテーブル414からのデータを使用して、ステップ1608と1609でフォーマット済みのデータをウェブホストサーバ101に適応した、できればXMLにフォーマットを変換する。変換されたデータは、それからステップ1613でウェブホストサーバ101に送信される。
【００７５】
ステップ1614で、インバウンドやアウトバウンドビジネスから消費者取引までの処理手続きを許可したイニシエータやレスポンダイベント状態を設定する。この処理は、終了ブロック1615で終了し、図10のステップ1007はこれと同時に完了する。
【００７６】
図１０の終了ブロック1008に到達して、図６のステップ603も完了する。次は図１７でより詳細に図示されている図６のステップ604で、環境と接続性を初期化する。開始ブロック1700にて始まり、ステップ1701は、現在起動している全ての処理が一覧に置かれて照会番号を与えられ、コマースサーバ103の処理一覧に列挙している。ステップ1702は、それからバックオフィスアプリケーション509の処理が存在しているかどうか判断するため、処理一覧を確認する。もしステップ1702がその処理が存在していることを見つけたなら、ステップ1703は照会番号を使用して処理を終えるための要求を送信し、コントロールはステップ1701に戻る。
【００７７】
もしステップ1702がバックオフィスアプリケーション509の処理が起動していないと判断した場合、コントロールはステップ1704に続く。ステップ1704では、アプリケーションサーバ106がオンラインであることを知らせる状態フラグを設定する。ステップ1707はステップ1706に到達した回数を数え続け、それからバックオフィスアプリケーション509を開始する。ステップ1705は、オペレーティングシステムによって割り当てられた処理ID（PID）を取り込む。
【００７８】
ステップ1706は、それからバックオフィスアプリケーション509が応答していることを確実にする。もしバックオフィスアプリケーション509の応答が確認されたら、コントロールはステップ1709に続く。そうでなければ、ステップ1707は、ステップ1706で数えた数が回数制限を超えていないかどうか判断する。もしステップ1707の限度を超えていると判断された場合は、ステップ1708はバックオフィスアプリケーションがオフラインであることを知らせるフラグを設定し、コントロールはステップ1709に続く。もしステップ1707が限度を超えていないと判断された場合、コントロールはステップ1701に戻る。
【００７９】
ステップ1709は、もし存在するなら、全体データベース構造414からのデータを使ってウェブホストサーバのフラグをオンラインに設定し、ウェブホストサーバ101へのネットワーク設定を確立することにより、ウェブホストサーバ101からの確実な応答か、タイムアウトによる応答なし、またはクライアントがウェブホストサーバ101の使用選択をしていない場合として、接続が有効でないという判断の結果になる。
【００８０】
ステップ1710は、ウェブホストサーバ101からの応答を有効にする。もしステップ1710でタイムアウトや無効な応答を発見した場合、その後ステップ1711で要求回数が事前に設定した限度、できれば10回を超えていないかどうか判断する。もし限度を超えていない場合、コントロールはステップ1709へと続く。そうでなければ、ステップ1712は、ウェブホストサーバがオフラインであることを知らせるフラグを設定し、コントロールはステップ1721に続く。
【００８１】
ステップ1710は、ウェブホストサーバ101からの応答が有効であると判断した場合、ステップ1713は、ウェブホストサーバ101の処理待ちのためのトランザクションがあるかどうか判断するために、トランザクションエンジンキュー417を確認する。もしそのようなトランザクションが処理待ちであるなら、ステップ1714でそのトランザクションを読み込む。
【００８２】
ステップ1715は、アクティビティログ422にトランザクションを書き込み、データの必須要素と値を確認する。ステップ1716は、トランザクションが有効であるかどうか判断する。もしステップ1716で、そのトランザクションが有効でない場合、ステップ1719がトランザクションエンジンキュー417からそのトランザクションを消去し、コントロールはステップ1713に戻る。
【００８３】
もしステップ1716のトランザクションが有効であるなら、ステップ1717は、正しいモジュールの存在のために実行可能プログラム410にインストールされたモジュールを確認する。ステップ1717は、実行可能プログラム410がこのトランザクションを処理することが可能かどうか判断するために、この確認を実行する。もしステップ1717が容認できるモジュールがインストールされていることを見つけた場合、ステップ1718は、このトランザクションをトランザクションエンジンアウトバウンドキュー419に送信することによって、有効なアウトバウンドトランザクションという結果になる。ステップ1719は、それからトランザクションエンジンキュー417からこのトランザクションを消去し、コントロールはステップ1713に戻る。
【００８４】
もしステップ1717が実行可能プログラム410はトランザクションを処理するのに必要なモジュールを保持していないと判断した場合は、ステップ1719でトランザクションエンジンキュー417からこのトランザクションを消去し、コントロールはステップ1713に戻る。
【００８５】
一旦ステップ1713が、トランザクションエンジンキュー417からこれ以上処理するトランザクションがないと判断した場合、ステップ1720はキュー417を初期化し準備状態にする。ステップ1721は、それから環境フラグを設定し、図３４により詳細に図示されているトランザクションフローを開始する。一旦ステップ1721が完了すると、終了ブロック1722に到達し、図６のステップ604も完了し、そして図６の終了ブロック605に到達する。
【００８６】
これまでのところ、取引相手間の情報の交換は、SMTP、FTP、そしてHTTPのような利用できる移送方法を使用する。これらの方法は、その方法に特定の種類のサードパーティサーバをその交換を促進する役割をさせるために組み込む。例えば、SMTP(Simple Mail Transport Protocol)を使用して取引相手に情報を送信する時は、データはSMTPサーバ上に一時的に留まる。この多様なサーバ上に存在するデータの複数コピーの結果は、情報の盗難の危険性や不本意な開示を受ける。この発明は、これら従来のプロトコルを使用しないで情報を取引相手に移送する方法を盛り込んでいる。この方法は、ポイントツーポイント、高度な水準の暗号化を使用して情報を直接対象とするレスポンダに送信する安全な移送プロトコルを含む。これはサードパーティサーバの使用を除外するので、結果として今までの方法固有の不具合を回避する。
【００８７】
図１８は、移送プロトコルのインストールのフロー図である。好ましくは、ステップ1801はコマースサーバ103の入力を受けて実行され、ユーザは移送プロトコルがコマースサーバ103上のどこにインストールされるべきか導く。図１８の開始ブロック1800にて始まり、ステップ1801は、初めにプログラムとサポートするファイルを解凍し、それからこれらのファイルをコマースサーバ103上の一時的な場所にコピーする。ステップ1802は、それからプログラムとファイルをインストールする場所でインストールし、そのプログラムをコマースサーバ103のオペレーティングシステムと一緒に登録する。
【００８８】
図１９により詳細に図示してあるステップ1803は、ローカルファイルレコードを取引相手プロフィールテーブル413に作成する。図１９はローカルプロフィールファンクションの作成のフロー図である。図１９の開始ブロック1900にて始まり、ステップ1901は  コマースサーバ103のオペレーティングシステムからローカルIPアドレスを請求する。ステップ1902は、それからIPポート設定についての情報を集める。ステップ1903は、次にどんなローカルプロフィールが存在しているか取引相手プロフィールテーブル413を確認する。ステップ1904はオペレーティングシステムからIPポート割当を要求し、そしてステップ1905は、ユーザに名前、Eメールアドレス、登録番号といった登録情報を尋ねる。ステップ1906は、それから取引相手プロフィールテーブル413に登録とローカルプロファイル情報を書き込む。一旦ステップ1906が完了すると、終了ブロック1907に到達し、図１８のステップ1803が完了する。
【００８９】
次に、ステップ1804は、ここには図示されていないが、登録サーバにコミュニケーションセッションを設定し、そして一旦設定されるとサーバに現在の登録情報を送信する。好ましくは、登録サーバは移送プロトコルが完全に機能することを許可する使用許諾情報を返信する。もし登録ステップが完了していない場合、使用許諾情報の欠落は移送プロトコルがデモンストレーションモードで機能して、次にはこの発明が許容できる取引相手プロフィールの決まった数、好ましくは５に制限し、そしてこの場合、取引相手プロフィールデータテーブル413はリモートシステム上に位置しているかもしれないが、ネットワーク上で使用されるこの発明の能力を機能できないようにする。ステップ1805は次に、該当する場合には取引相手プロフィールテーブル413のデータを更新し、それから移送プロトコルが完全に機能するようになる。
【００９０】
次のステップ1806は、システム起動グループと一緒にレスポンダサーバ処理を登録する。好ましくは、このステップによって、コマースサーバ103が起動する度にこのレスポンダ処理が開始される。次のステップ1807は、図２０にさらに詳細に図示されているレスポンダサーバ処理を開始する。
【００９１】
図２０はレスポンダ処理のフロー図である。図２０の開始ブロックにて始まり、ステップ2001は取引相手プロフィールテーブル413が存在するかどうか判断する。もしテーブル413が存在しないのであれば、新規テーブルが作成され（ステップ2002）、コントロールはステップ2003に続く。もしステップ2001でテーブル413が確かに存在すると判断した場合は、ステップ2003は取引相手プロフィールテーブル413内にローカルプロフィールが存在するかを確認する。もしローカルプロフィールレコードが存在しない場合は、ステップ2004は、図１９により詳細に図示しているローカルプロフィール作成処理を開始することによってローカルプロフィールレコードを作成する。
【００９２】
一旦ステップ2004が完了すると、ステップ2005は、コマースサーバ103のユーザにローカルプロフィールレコードを取引相手プロフィールテーブル413に書き込まれるかどうか尋ねる。もしユーザがローカルプロフィールレコードは書き込むのに有効であると知らせたなら、ローカルプロフィールレコードは取引相手プロフィールテーブル413に保存され、コントロールはステップ2003に戻る。もし、ステップ2005で、ユーザがそのレコードを保存しないと知らせた場合は、ローカルプロフィールは処分され、移送プロトコル使用許諾処理の開始を回避して、コントロールは終了ブロック2007に導かれる。一旦ステップ2003でローカルプロフィールレコードがあると判断されると、コントロールは図２３に図示されている移送プロトコル使用許諾処理が起動されるステップ2006へと続く。一旦ステップ2006が完了すると、図２０の終了ブロック2007に到達し、そして図１８の終了ブロック1808に到達する。
【００９３】
図２１と図２２は、それぞれデータ交換のイニシエータとレスポンダを表すイベント状態遷移図である。これらの図は、図を通して進展してセッションを完了にするために、イベント待ち状態からイベント待ち状態への進行、必要なイベントの順序、そしてそれぞれのイベントの結果として実行された行動を表している。セッションは、イニシエータが図２１の状態ブロック2101にありレスポンダが図２２の状態ブロック2201にあるところから始まる。同じセッションは、図をどのようにたどるかに関係なく、イニシエータが状態ブロック2101に戻り、レスポンダが状態ブロック2201に戻って終了する。
【００９４】
通常のセッションでは、図２１の状態ブロック2101から始まるイニシエータは、イニシエータのIP／ポート情報と署名データを含むセッション要求パッケージを送信する。一旦セッション要求パッケージが送信されると、コントロールはそれから状態ブロック2102に移動する。
【００９５】
レスポンダはセッション要求を受信後、イニシエータのプロフィールを取引相手プロフィールテーブル413で確認する。もしプロフィールが見つからない場合は、レスポンダはレスポンダの取引相手プロフィールテーブル413にデータの初期交換を容易にするため一時ファイルを作成する。もしプロフィールが見つかれば、レスポンダはそれから一組の新規セッションキーを生成し、レスポンダの公開セッションキー、署名、そしてプロフィールデータを含むセッション確認を一緒に返信する。レスポンダはそれから状態ブロック2202に移動する。この交換は初期情報を設定し、エンコードされたデータを交換するためにTCP/IPコミュニケーション経路を開く。
【００９６】
イニシエータが、レスポンダのセッション確認からTCP/IP接続の確認を受信した後、イニシエータは一組のセッションキーを生成してイニシエータの公開セッションキー、署名、そしてプロフィールデータを含むキー要求を生成する。キー要求は、それからレスポンダの公開セッションキーと一緒にエンコードされレスポンダに送信される。なお、もしレスポンダの取引相手プロフィールがイニシエータの取引相手プロフィールテーブル413に見つからないか、情報が古い場合、イニシエータの取引相手プロフィールテーブル413のプロフィールは、セッション確認に含まれているレスポンダの新規プロフィールと一緒に更新される。イニシエータはそれから状態ブロック2103に移動する。
【００９７】
レスポンダはキー要求を受信後、キー要求が正しくエンコードされていることを確認する。正しいキー要求は、好ましくはレスポンダの公開セッションキーと一緒にエンコードされて到着して、レスポンダはそれからキー要求がデコード後正しくフォーマットされているかどうか判断する。なお、もしイニシエータの取引相手プロフィールがレスポンダの取引相手プロフィールテーブル413で見つからないか、情報が古い場合、レスポンダの取引相手プロフィールテーブル413のプロフィールは、キー要求に含まれているイニシエータの新規プロフィールと一緒に更新される。レスポンダはそれからキー確認を送信して、状態ブロック2203に移動する。
【００９８】
この時点で、このセッションのために作成された公開暗号化キーの交換を通じて高度に保護されたTCP/IP接続を確立すると共に、交換に関係している取引相手が識別される。この交換を通じてそれぞれの状態において、もし確立された通信プロトコルが維持されていたら、ボトルネッキング、フラッディング、そしてサービス不能（DOS）攻撃のような一般的な問題は排除される。また、セッション内のコミュニケーションの安全な経路が確保される。もし移送プロトコルがどちらかの相手からどこかのイベント待ち状態にて破られたら、侵害を感知した相手から中止パッケージが送信され、両方とも各自のアクティビティ停止状態に戻り、セッションを終了する。
【００９９】
イニシエータは、今は状態ブロック2103にて待ち状態であり、それからキー確認を受信し、それによってデータパッケージの交換が進むのを許可する。イニシエータは、送信待ちのトランザクションを含むデータパッケージを送信し、状態ブロック2104に移動する。もし追加データパッケージが送信待ち状態である場合、イニシエータは状態ブロック2104にとどまる。そうでなければ、イニシエータは状態ブロック2105に進む。
【０１００】
データパッケージを受信した後、レスポンダはパッケージ確認と一緒に応答し、状態ブロック2104にとどまる。もしイニシエータが追加データを送信した場合、次にそれぞれの送信されたパッケージはレスポンダから対応するパッケージ確認を受信する。このアクティビティは、イニシエータが終了要求をするまで続き、状態ブロック2105に移動する。イニシエータとレスポンダの両方とも、それぞれのアクティビティ停止状態に戻り、セッションは終了する。
【０１０１】
図２３は、要求が届いた時レスポンダ処理を確立する移送プロトコルリスナーのフロー図である。図２３の状態プログラムにて始まり、ステップ2301は、イベント待ち状態の移送プロトコルリスナーを図示している。ステップ2302、新しい要求の到着は、ステップ2303の処理を起動する。ステップ2303では、インバウンドセッション要求が受信される。ステップ2304は、次にキューの限度計数器で要求が処理できるかどうか判断できることの確認をする。
【０１０２】
もしキューの限度を超えていた場合、コントロールはステップ2311に続き、そこでアクティビティログ422にエラーメッセージが書き込まれ、インバウンド要求が取り下げられ、リスナー処理はステップ2312のイベント待ち状態に戻る。もしステップ2304でキュー限度を超えていない場合、コントロールはステップ2305で続き、そこでキュー限度計数器はインクリメントされる。
【０１０３】
ステップ2306は、テーブル413からのデータを使用して、その要求のイニシエータが最新の取引相手プロフィールレコードを保持しているかどうか判断する。もし、イニシエータのプロフィールレコードがテーブル413で見つからない場合、一時的プロフィールレコードがこのセッションを持続して処理することを許可するためにテーブル413に追加され、もっと詳細な取引相手プロフィール情報の交換を容易にする。一旦ステップ2307が完了するか、一旦ステップ2306で、プロフィールレコードが取引相手プロフィールテーブル413に存在すると判断した場合、コントロールはステップ2308に続き、そこで図２５により詳細に図示されている移送プロトコルシェルが、現在の取引相手との残りのコミュニケーション交換に対応するために始動される。ステップ2309は、取引相手プロフィールテーブル413のイニシエータのプロフィールデータを更新し、ステップ2310でそのアクティビティをアクティビティログ422に書き込む。ステップ2312は移送プロトコルリスナーをイベント待ち状態に戻す。
【０１０４】
図２４は、移送プロトコルのユーザインターフェイスのフロー図である。開始ブロック2400にて始まり、アウトバウンド要求がブロック2401に到着し、アウトバウンド要求を受信するステップ2402を引き起こして、送信される情報を有効にする。ステップ2403は、その要求のレスポンダを判断するために取引相手プロフィールテーブル413を確認する。もしその要求にレスポンダが特定できない場合、コントロールはステップ2404に続き、そこでユーザに取引相手プロフィールテーブル413からプロフィールを選択するように問い合わせる。その後、コントロールはステップ2403に戻る。
【０１０５】
ステップ2403がレスポンダを特定した場合、コントロールはステップ2405に続き、そこで日付や時間といったセッション情報が取引相手プロフィールテーブル413に記録される。ステップ2406は、それから要求構造を作成し、ステップ2407では図２６でより詳細に図示されているセッション要求を始動する。一旦セッション要求が終了すると、終了ブロック2408に到達する。
【０１０６】
図２５は、図２３の移送プロトコルリスナーから毎回インバウンド要求を受信する度に始動される移送プロトコルシェルのフロー図である。移送プロトコルシェルは、セッションが完了するまでアクティブのままである。図２５の開始ブロック2500にて始まり、セッション中にインバウンド要求を受信する度に、ステップ2501はその要求がプロトコルパッケージを含んでいるかどうか判断するために確認する。もしプロトコルパッケージがその要求で受信されたならば、ステップ2524はプロトコルパッケージ処理を始動する。ステップ2524は図３３により詳細に図示されている。もし要求がプロトコルパッケージを含んでいない場合、ステップ2502でテーブル413からのデータを使用して、その要求を送信している取引相手のために現在のセッション情報を判断する。
【０１０７】
もしステップ2502でセッションが始まっていないと判断した場合、ステップ2503でその要求がセッション要求かどうか判断するために検査する。ステップ2503で、その要求がセッション要求を含んでいないと判断された場合、その要求は無視され、コントロールは終了ブロック2525に移動する。もしステップ2503で、セッション要求があると判断された場合は、コントロールはステップ2515に続き、そこでセッション要求が始動される。ステップ2515は図２６により詳細に図示されている。一旦ステップ2515でセッション要求が終了すると、終了ブロック2525に到達する。
【０１０８】
もしステップ2502でセッションが開始されたと判断された場合、コントロールはステップ2504へ続き、そこでどの相手がセッションを始動させたか判断する。ステップ2504でシステム100がイニシエータでないと判断した場合、コントロールはステップ2505に続く。
【０１０９】
ステップ2505は、セッション要求があるかどうか判断する。もしセッション要求が見つかれば、コントロールはステップ2515に続き、図２６でより詳細に図示されているように、セッション要求が始動される。もしセッション要求がステップ2505で見つからない場合は、コントロールはステップ2507に続く。
【０１１０】
ステップ2507はキー要求が存在しているかどうか判断する。もしキー要求が見つかる場合は、コントロールはステップ2517に続き、そこでキー要求は始動される。ステップ2517は、図２７により詳細に図示されている。もしステップ2507でキー要求が見つからない場合は、コントロールはステップ2509に続く。
【０１１１】
ステップ2509は、データパッケージが存在するかどうか判断する。もしデータパッケージが見つかる場合、コントロールはステップ2519に続き、そこで送信データパッケージが始動される。ステップ2519は、図２８により詳細に図示されている。もしデータパッケージがステップ2509で見つからない場合、コントロールはステップ2511に続く。
【０１１２】
ステップ2511はセッション終了が存在するか判断する。もしセッション終了が見つかる場合、コントロールはステップ2521に続き、そこでセッション終了が始動される。ステップ2521は、図２９により詳細に図示されている。もしステップ2511でセッション終了要求が見つからない場合、コントロールはステップ2513に続く。
【０１１３】
もしステップ2504でシステム100がイニシエータであると判断した場合、コントロールはステップ2506に続く。
【０１１４】
ステップ2506は、パッケージがセッション確認を含んでいるかどうか判断する。もしセッション確認が見つかる場合、コントロールはステップ2516に続き、そこでキー要求が処理される。ステップ2516は図２７により詳細に図示されている。もしセッション確認がステップ2506で見つからない場合、コントロールはステップ2508に続く。
【０１１５】
ステップ2508はキー確認が存在するかどうか判断する。もしキー確認が見つかる場合、コントロールはステップ2518に続き、そこで送信データパッケージが始動される。ステップ2518は図２８により詳細に図示されている。もしキー確認がステップ2508で見つからない場合、コントロールはステップ2510に続く。
【０１１６】
ステップ2510はパッケージ確認が存在するかどうか判断する。もしパッケージ確認が見つかる場合、コントロールはステップ2514に続く。ステップ2514はそれ以上のパッケージを送信するかどうか判断する。もしステップ2514でそれ以上のデータパッケージが送信されると判断した場合、コントロールはステップ2518に続き、そこで次のデータパッケージの送信が始動される。もしそれ以上のデータパッケージが送信されない場合、コントロールはステップ2520に続き、セッション終了が始動される。ステップ2520は、図２９により詳細に図示されている。もしパッケージ確認がステップ2510で見つからない場合、コントロールはステップ2512に続く。
【０１１７】
ステップ2512は、終了確認が存在するかどうか判断する。もし終了確認が見つかる場合、コントロールはステップ2522に続き、図３１でより詳細に図示されているようにクローズセッションが始動される。もし終了確認がステップ2512で見つからない場合、コントロールはステップ2513に続く。
【０１１８】
ステップ2513はセッション中止／エラーが存在するかどうか判断する。もしセッション中止／エラーが見つかる場合、コントロールはステップ2523に続き、そこでセッション中止／エラー報告が始動される。ステップ2523は、図３０により詳細に図示されている。もしセッション中止／エラーがステップ2513でみつからない場合、コントロールはステップ2522に続き、そこでクローズセッションが始動される。ステップ2522は図３１により詳細に図示されている。
【０１１９】
図２６の開始ブロック2600にて始まると、ステップ2601は予めセッションイニシエータの識別を判断する。もしコマースサーバ103がイニシエータである場合、コントロールはステップ2602に続き、そこでレスポンダが確認される。ステップ2603はセッション要求ヘッダー情報を構築する。ステップ2604でセッション要求カーゴを構築し、コントロールはステップ2608に続く。
【０１２０】
ステップ2601で、セッションがテーブル413で見つかった取引相手によって始動されたかどうか判断し、コントロールはステップ2605に続き、そこでイニシエータが特定される。ステップ2606でセッション確認ヘッダーを構築し、ステップ2607でセッション確認カーゴを構築する。コントロールはそれからステップ2608に続く。
【０１２１】
ステップ2608は、アウトバウンド要求を生成し、移送プロトコルアウトバウンドキュー421に要求を書き込む。ステップ2609は送信アウトバウンド要求を始動し、図３２にその詳細が図示されている。ステップ2609で送信アウトバウンド要求を終了した後、終了ブロック2610に到達する。
【０１２２】
図２７はキー要求処理のフロー図である。図２７の開始ブロック2700にて始まり、ステップ2701でキー要求イニシエータの識別を判断する。もしコマースサーバ103がイニシエータの場合、コントロールはステップ2702に続き、そこでそのメッセージの特有のレスポンダを特定する。ステップ2703で、キー要求ヘッダー情報を構築して、ステップ2704でキー要求カーゴを構築し、コントロールはステップ2708に続く。
【０１２３】
ステップ2701で、そのセッションがその取引相手によって始動されたと判断されれば、コントロールはステップ2705に続き、そこでイニシエータが特定される。ステップ2706は、それからキー確認ヘッダーを構築する。ステップ2707は次にキー確認カーゴを構築して、コントロールはステップ2708に続く。
【０１２４】
ステップ2708はアウトバウンド要求を生成し、移送プロトコルアウトバウンドキュー421にそれを書き込む。ステップ2709は、図３２に詳細に図示されている送信アウトバウンド要求を始動する。一旦その要求がステップ2709で送信されると、終了ブロック2701に到達する。
【０１２５】
図２８は送信データパッケージのフロー図である。図２８の開始ブロック2800にて始まり、ステップ2801は送信データパッケージイニシエータが何かを判断する。もしコマースサーバ103がイニシエータの場合、コントロールはステップ2802に続き、そこでレスポンダが特定される。ステップ2803はデータパッケージヘッダー情報を構築し、ステップ2804はデータカーゴを構築して、そしてコントロールはステップ2808に続く。
【０１２６】
もしステップ2801で、セッションが取引相手によって始動されたのであれば、それからコントロールはステップ2805に続き、そこで特有のイニシエータが特定される。ステップ2806はデータパッケージ確認ヘッダーを構築し、ステップ2807はデータパッケージ確認カーゴを構築し、そしてコントロールはステップ2808に続く。
【０１２７】
ステップ2808はアウトバウンド要求を生成し、移送プロトコルアウトバウンドキュー421にそれを書き込む。ステップ2809は、図３２により詳細に図示されている送信アウトバウンド要求を始動する。一旦その要求が取引相手に送信されると、終了ブロック2810に到達する。
【０１２８】
図２９は、セッション終了のフロー図である。図２９の開始ブロック2900にて始まり、ステップ2901はセッションイニシエータが何であるかを判断する。もしコマースサーバ103がイニシエータの場合、コントロールはステップ2902に続き、そこで特有のレスポンダが特定される。ステップ2903はセッション終了要求ヘッダーを構築し、ステップ2904はセッション終了要求カーゴを構築する。ステップ2904が完了した後、コントロールはステップ2908に続く。
【０１２９】
もしステップ2901でセッションが取引相手によって始動されたと判断した場合、コントロールは特有のイニシエータが特定されたステップ2905に続く。ステップ2906でセッション終了確認ヘッダーを構築し、ステップ2907でセッション終了確認カーゴを構築する。一旦ステップ2907が完了すると、コントロールはステップ2908に続く。
【０１３０】
ステップ2908でアウトバウンド要求を生成し、移送プロトコルアウトバウンドキュー421にそれを書き込む。図３２により詳細に図示されているステップ2909は、送信アウトバウンド要求を始動する。一旦ステップ2909が完了すると、終了ブロック2910に到達する。
【０１３１】
図３０は中止／エラーメッセージのフロー図である。図３０の開始ブロック3000にて始まり、ステップ3001は中止／エラーイニシエータが何か判断する。もしコマースサーバ103がイニシエータの場合、コントロールはステップ3002に続き、そこで中止／エラーの種類が判断される。ステップ3003はそれからエラーか中止メッセージを構築し、図３１により詳細に図示されているステップ3004で、クローズセッションを始動する。ステップ3005は、エラー要求をもう一度待ち行列に入れるため、新規要求を移送プロトコルアウトバウンドキュー421に書き込む。ステップ3005が完了した後、コントロールはステップ3009に続く。
【０１３２】
もしステップ3001でセッションが取引相手によって始動されたと判断した場合、ステップ3006はエラーまたは中止の種類を判断し、ステップ3007はエラーまたは中止の応答メッセージを構築する。図31により詳細に図示されているステップ3008は、それから現在のセッションのクローズを始動する。一旦ステップ3008が完了すると、コントロールはステップ3009に続く。
【０１３３】
ステップ3009で中止／エラーメッセージを生成し、移送プロトコルアウトバウンドキュー421にそれを書き込む。次の図３２でより詳細に図示されているステップ3010は、そのメッセージを取引相手に送信する。一旦ステップ3010が完了すると、終了ブロック3011に到達する。
【０１３４】
図３１はクローズセッションのフロー図である。図３１の開始ブロック3100にて始まり、ステップ3101は取引相手プロフィールテーブル413からのデータを使用してセッションを特定する。次のステップ3102で、セッションがクローズしたことを知らせる情報をテーブル413に書き込む。一旦ステップ3102が完了すると、終了ブロック3103に到達する。
【０１３５】
図３２は送信アウトバウンド要求のフロー図である。図３２の開始ブロック3200にて始まり、ステップ3201はイベント待ち状態の送信アウトバウンド要求を表している。ステップ3202では、移送プロトコルアウトバウンドキューのアウトバウンド要求の到着が、ステップ3203の処理を引き起こす。一旦生起されると、ステップ3203はそれからアウトバウンド要求を受信し、ステップ3204は要求がデータパッケージを含んでいるかどうか判断する。もしステップ3204でデータパッケージが送信されたと判断した場合、ステップ3205はパッケージ内容構造2811に基づいてパッケージを組み立てる。もしステップ3204でデータパッケージが存在していないと判断した場合、コントロールはステップ3206に続く。
【０１３６】
ステップ3206は、要求がセッション要求かセッション確認であるか判断する。もしその要求がセッション要求でもセッション確認でもない場合、ステップ3207では、（レスポンダのための）セッション確認または（イニシエータのための）キー要求の時に取得した公開キーを使用してパッケージカーゴを圧縮して、エンコードする。もしステップ3206で、その要求がセッション要求かセッション確認であると判断した場合、コントロールはステップ3208に続く。
【０１３７】
それからステップ3208で、アウトバウンド要求をネットワーク104を介して取引相手に送信し、そしてステップ3209はその送信の結果をアクティビティログ422に書き込む。ステップ3209が完了した後、終了ブロック3210に到達する。
【０１３８】
図３３は、プロトコルパッケージのフロー図である。図３３の開始ブロック3300から始まり、ステップ3301は、取引相手プロフィールテーブル413からのデータを使用してイニシエータの権限を確認する。ステップ3302はそれからイニシエータが許可されているかどうか判断する。もしイニシエータが許可されていない場合、コントロールはセキュリティエラーメッセージがアクティビティログ422に書き込まれるステップ3308に続き、それから処理は終了ブロック3309にて終了する。
【０１３９】
もしステップ3302でイニシエータが進行することを許可されると、それからステップ3303はプロトコルパッケージがデータの要求を含んでいるかどうか判断する。もしプロトコルパッケージがデータの要求を含んでいる場合、ステップ3306は取引相手プロフィールテーブル413から要求されたデータを収集し、ステップ3307で送信アウトバウンド要求を始動する。ステップ3307は図３２でより詳細に図示されている。一旦アウトバウンド要求が送信されると、終了ブロック3309に到達する。
【０１４０】
もしステップ3303で、プロトコルパッケージにデータの要求が見つからない場合、コントロールはステップ3304に続く。ステップ3304はそれからプロトコルパッケージが取引相手プロフィール更新を含んでいるかどうか判断する。もしそのパッケージが更新を含んでいない場合、その処理は終了ブロック3309にて終了する。もしステップ3304でプロフィール更新がプロトコルパッケージに含まれていると判断した場合、ステップ3305はテーブル413の情報を更新し、その処理は終了ブロック3309にて終了する。
【０１４１】
ビジネス環境では、全てのビジネス取引の種は情報の交換によって播種される。この取引相手との交換は「ビジネス協定」として知られており、一般にEDI838取引相手プロフィールやEDI868電子的フォーム構造のようなEDI標準に述べられた情報と類似したものを含む。一旦これら二つの重要な情報源が交換されたら、全ての将来ののトランザクション交換の基準が確立される。
【０１４２】
取引相手プロフィールと電子的フォームデータは、ネットワーク接続を容易にする他のデータとともに、図４の取引相手プロフィールテーブル413に保存される。要するに、取引相手プロフィールテーブル413により、この発明は以下のことが可能となる。1)  それぞれの取引相手のビジネス識別を認識する、2)  相互に合意されたトランザクションのどのようなものが交換されるかを判断する、3)  それぞれのトランザクション内のどこにデータが位置しているかを判断する、そして4)  取引相手とデータの交換が発生する度に、それらのトランザクションのそれぞれの要素のために許可できる値を判断する。
【０１４３】
図３４はインバウンドとアウトバウンドトランザクションフローの概要であり、図１のコマースサーバ103上で並行して起こる。トランザクションの流れは、インバウンドとアウトバウンドの二方向性であり、サブプロセスを通して移動し、図４のビジネストランザクションマップ415にある指示に従って、所定の経路を完成する。
【０１４４】
図３４の開始ブロック3400より、ネットワーク104から来るインバウンドトランザクションは、図３６でより詳細に図示されているステップ3401にて受信され、そこでそれらのトランザクションは復元、デコード、そして有効化される。インバウンドトランザクションは、それから図３７でより詳細に図示されているステップ3402に個別に送られ、そこで各々のトランザクションが特定され、内部データ構造に分解される。それが終わると、ステップ3402からのデータはステップ3403に送られ、それからどんな追加トランザクションがビジネス対話を完了させるのに必要か判断する。ステップ3403もまた適切な送信先へこれらのトランザクションを経路設定する。ステップ3403のこれらのトランザクションの内いくつかは、図３９により詳細に図示されているステップ3404に続くであろう。終了ブロック3405は、インバウンドトランザクションフローを終了する。
【０１４５】
また図３４の開始ブロック3406より、好ましくはアプリケーションサーバ106からの出力データ形式のアウトバウンドトランザクションが、ステップ3407で受信される。図４０により詳細に図示されているステップ3407では、データが内部データ構造に分解され、ステップ3408に送られる。図４１により詳細に図示されているステップ3408は、必要であれば顧客SQLテーブル416を作成し、そのテーブル416を更新する。次の図３８により詳細図示されているステップ3403で、どんな追加トランザクションがビジネス対話を完了させるのに必要か判断し、適切な送信先へこれらのトランザクションを経路設定する。ステップ3403のこれらのトランザクションの内いくつかは、図４２により詳細が図示されているステップ3409に続き、そこでトランザクションはパッケージ化、およびエンコードされネットワーク104を介して最終送信先へ送信される。アウトバウンドトランザクションフローは、終了ブロック3410にて終了する。
【０１４６】
トランザクションのインバウンドとアウトバウンドフローは、キューを使用することを通じて発生する。キューは、データが順次保存され、保存されたデータが通常先入れ先出し規則として知られている順序で検索されるファイルである。これにより、各々のサブプロセスがそれぞれのデータの処理を行い、それをこのデータのためにアクティブ状態で待っている受信サブプロセスの必要性から独立に、次のサブプロセスに渡すことが可能とされている。この方法の一つの利点として、それぞれのサブプロセスが、必要なデータが無かったり、タイミングのせいでトランザクションの処理が可能でない時、トランザクションを再びキューに加えることができる。この取り組み方法の重要な利点として、それぞれの構成要素のサブプロセスは、データがこの発明のどこの特有な点において使用され保存されても、失われたり破損しないことを保障する。これら他からはそれぞれ独立したサブプロセスは、各々のキューファイルの管理を想定し、それぞれのファイルの内容やサイズの両方を認識している。イベントは、新規要求がそれぞれのサブプロセスキューに到達した時に引き起こされる。それぞれのサブプロセスは、それからその本来の役割を実行し、データは引き続き与えられたトランザクションフローに沿って移動する。
【０１４７】
図３４はこの発明を通したトランザクションの全体的な流れのフロー図であり、図３５は個々のサブプロセスを通したトランザクションの流れのフロー図である。それぞれのサブプロセスはトランザクションエンジンフローの独立した部分なので、それぞれのサブプロセスは以下互いに別々に記述されている。
【０１４８】
図３５に図示された最初の処理フローは、インバウンド要求3501にて始まる。インバウンド要求3501は、ステップ3502のイベントトリガで、その結果としてステップ3401を始動する。ステップ3401は図３６により詳細に図示されている。このステップ3401の処理フローは、インバウンド要求を用いてトランザクションエンジンキュー417の更新をする結果となる。
【０１４９】
図３６の開始ブロック3600から、ステップ3601はインバウンド要求を受信して復元し、そしてアクティビティログ422にその要求を記録する。次はステップ3602で、イニシエータとレスポンダが、取引相手プロフィールテーブル413を使用して、判断される。ステップ3603は、それからその要求を事前に設定され交換された暗号化キーの組を使ってデコードして復元する。次はステップ3604で、全体データベース構造414を使ってインバウンド要求の内容の出力送信先を判断する。その内容の送信先はどこか許可されたディレクトリに位置付けされ、ネットワーク105に接続しているどれか互換性のある装置で、ASCIIテキストファイルや、電子的にDDE（動的なデータ交換）を許可するプログラムのどれかに送信され、そのようなファイルを実行する権利を与えられている動的なデータ交換を含むが、それらだけに限られない。それ以上に、もしインバウンド要求がEDI構造の場合、ステップ3605は規格EDI997の機能的な応答をトランザクションエンジンキュー417にその要求の受取を確認するために送信する。それからステップ3606で、その内容はブロック3606に図示されているファイル形式か、ブロック3607に図示されているDDE形式のどちらか決定された送信先に出力される。このサブプロセスは終了ブロック3608で終了する。図３７により詳細に図示されているトランザクションエンジンインバウンド処理は、インバウンドトランザクションの優先送信先である。
【０１５０】
次の図３５のサブプロセスは、イベントトリガとなる移送プロトコルアウトバウンドキュー421のインバウンド要求3503の受取りとともに始まる。ステップ3503は、図３７により詳細に図示されているステップ3402のトランザクションエンジンインバウンド処理を発生させる。このサブプロセスはトランザクションエンジンキュー417の更新という結果になる。
【０１５１】
開始ブロック3700から、インバウンド要求3503は、その要求が個々のトランザクションに分解され、インバウンド要求の記録がアクティビティログ422に書き込まれるステップ3701を引き起こす。ステップ3702は、それからイニシエータの既存のプロフィールデータのために取引相手プロフィールテーブル413を検索する。次のステップ3703は、分解されたトランザクションを取引相手プロフィールレコードに対してチェックする。もしステップ3703で取引相手プロフィール情報がトランザクションに含まれていないと判断した場合、その次にコントロールはステップ3705に続く。もしステップ3703で、取引相手プロフィールレコードがトランザクションに含まれている場合、それからステップ3704はイニシエータのプロフィールと許可された内容と形式などの全ての必要な情報が存在するかどうか判断し、その情報を使って取引相手プロフィールテーブル413を更新する。それからコントロールはステップ3705に続く。
【０１５２】
ステップ3705は、テーブル413からのデータを使ってイニシエータが既存のプロフィールを保持しているか判断する。もしステップ3705で、イニシエータが有効な、または完全な取引相手プロフィールを提供していないと判断した場合、コントロールはステップ3708に続く。有効でない、もしくは完全でない取引相手プロフィールのプロフィール例として、EDI868に格納されている情報を有しないプロフィールがあり、その情報とはインバウンド要求に含まれているトランザクションの内容と構造を述べるものである。エラーメッセージが、ステップ3708でトランザクションエンジンキュー417に送信された後、その処理は終了ブロック3710にて終了する。もしステップ3705で、イニシエータが有効で完全な取引相手プロフィールをテーブル413に保持していると判断した場合、ステップ3706はそれぞれのトランザクションのデータ構造を用意する。ステップ3707は、それから分解されたトランザクションをあらかじめ定義されたデータ構造とその内容を比較することによって、有効で完全かどうかの判断をする。もしステップ3707で、トランザクションのどれか１つでも有効でないもしくは不完全と判断した場合、その後にステップ3708でエラー対応メッセージを用意し、トランザクションエンジンキュー417にエラーメッセージを送信する。一旦ステップ3708でエラーメッセージを送信すると、その処理は終了ブロック3710にて終了する。もしステップ3707で、全ての分解されたトランザクションが有効で完全と判断した場合、ステップ3709はあらかじめ定義されたデータ構造にそのデータをフォーマットし、トランザクションエンジンキュー417にそのトランザクションを送信する。一旦トランザクションがキュー417に送信されると、その処理は終了ブロック3710にて終了する。
【０１５３】
次の図３５に図示されているサブプロセスは、トランザクションがトランザクションエンジンキュー417に到着するとともに始まる。イベントトリガとなるインバウンドトランザクション3504は、図３８により詳細に図示されているステップ3403を始動する。
【０１５４】
図３８はトランザクションエンジンシェルのフロー図である。開始ブロック3800にて始まり、トランザクションはトランザクションエンジンキュー417か応答要求キュー419のどちらかに到着し、ステップ3801を引き起こす。ステップ3801は、最初にトランザクションをアクティビティログ422に書き込み、その後ステップ3801で、ビジネストランザクションマップ415、顧客SQLデータテーブル416と応答要求キュー419からのデータを使って、トランザクション（インバウンドではバックオフィスアプリケーションまたはアウトバウンドでは取引相手）の送信先、どんな追加のトランザクションがビジネス対話を完了するために必要であるか判断する。例えば、注文トランザクションはその後に請求トランザクションが続いて、請求トランザクションは支払許可トランザクションが続くことになる。その上、ビジネス対話はそれぞれ上記の例のトランザクションのために確認の交換を含むかもしれない。
【０１５５】
ステップ3801で処理される追加の要件は、アプリケーションサーバ106によって処理されていないトランザクション、取引相手に発信する準備ができたと判断されたトランザクション、将来処理させられると判断されたトランザクション、不完全なトランザクションから構成されている。必要に応じて、ステップ3801の結果は送信されて、ステップ3802、3803、そして3804で並行して処理される。
【０１５６】
ステップ3802で、処理待ちをしなければならなかったり、必須データが欠如しているせいで不完全と考えられているどんなトランザクションも、この先の処理のため応答要求キュー418に書き込まれる。ステップ3803で、アプリケーションサーバ106に送信されたどのトランザクションも、SDSトランザクションキュー420にフォーマットされ書き込まれる。ステップ3804で、取引相手に送信する準備ができているどのトランザクションも、移送プロトコルアウトバウンドキュー421にフォーマットされ書き込まれる。ステップ3802、3803、そして3804は、終了ブロック3805にて同時に終了する。
【０１５７】
次の図３５に図示されているサブプロセスは、応答要求キュー418にトランザクションが到着するとともに始まる。イベントトリガとなるステップ3505は、図３８により詳細に図示されているステップ3403を始動する。
【０１５８】
次の図３５に図示されているサブプロセスは、SDSトランザクションキュー420にトランザクションが到着するとともに始まる。イベントトリガとなるステップ3506は、図３９により詳細に図示されているステップ3404を始動する。
【０１５９】
図３９はSDSインバウンドのフロー図である。開始ブロック3900から、ステップ3901はトランザクションを受信して読み込み、全体データベース構造414からのデータを使って、そのトランザクションの処理のための設定経路とトランザクション処理の提示方法を判断する。提示方法は、好ましくは一以上の選択方法を含み、それは、特定されたデータベースにデータの直接応用、他のアプリケーションと動的データ交換（DDE）、テキストからファイルへのデータの出力、および／またはデータのバックオフィスアプリケーション509のグラフィカルユーザインターフェイスにキー入力を模擬した形態でデータを提示、である。ステップ3902は、全体データベース構造414からのデータを使って、判断された方法によってトランザクションをフォーマットし、ステップ3903で判断された方法によって、アプリケーションサーバ106にトランザクションを送信する。一旦ステップ3903が完了すると、その処理は終了ブロック3904にて終了する。
【０１６０】
次の図３５に図示されているサブプロセスは、ステップ3508のアプリケーションサーバ106によって作成されたアウトバウンドトランザクション3508の受信とともに始まる。アウトバウンドトランザクション3508は、イベントトリガ3509で図４０により詳細に図示されているステップ3407を始動する。また、バックオフィスアプリケーション509によって作成されたファイルは、アウトバウンドトランザクション3508になることも可能でイベントトリガとしての役割を果たす。バックオフィスアプリケーション509からのこれらのファイルは、できればあらかじめ定義された時間間隔でステップ3407を始動する。
【０１６１】
図４０はSDSアウトバウンドのフロー図である。開始ブロック4000から、ステップ4001は、アウトバウンドトランザクション3509に存在しているアウトバウンドデータ3508を、全体データベース構造414を使用してデータの構造と位置を判断し、受信して読み込み、解析する。次のステップ4002はトランザクションをフォーマットし、トランザクションエンジンアウトバウンドキュー419にそのトランザクションを書き込む。この処理は終了ブロック4003で終了する。
【０１６２】
次の図３５に図示されているサブプロセスは、トランザクションエンジンアウトバウンドキュー419にアウトバウンドトランザクション3510が到着するとともに始まる。アウトバウンドトランザクション3510は、図４１でより詳細に図示されているステップ3408を始動する。
【０１６３】
図４１はトランザクションエンジンアウトバウンドのフロー図である。開始ブロック4100にて始まり、トランザクションエンジンアウトバウンドキュー419にアウトバウンドトランザクション3510が到着して、ステップ4101を始動する。ステップ4101は全体データベース構造マップ414からのデータを使って、顧客SQLデータテーブル416にアウトバウンドデータを分解する。ステップ4102は、現在顧客SQLデータテーブル416に存在するアウトバウンドトランザクション3510からと応答要求キュー418からの両方のデータを使って、このトランザクションが応答要求キュー418の先行する将来要件と関係するかどうか判断する。もしステップ4102で、どのデータも現在のアウトバウンドトランザクションを処理する必要があると判断した場合、その次にステップ4103が、トランザクションエンジンキュー417に必要条件はすでに満たされている新規アウトバウンド要求を構築する。ステップ4104は、それから応答要求キュー418に、このトランザクションに関係するビジネス対話を完了するために必要となるどんな将来のトランザクション要求も書き込む。この処理は、終了ブロック4105にて終了する。
【０１６４】
次の図３５に図示されているサブプロセスは、移送プロトコルアウトバウンドキュー421にアウトバウンド要求3511の到着とともに始まり、ステップ3409の始動という結果になる。ステップ3511で、アウトバウンド要求が到着して、図４２により詳細に図示されているステップ3409を始動する。
【０１６５】
図４２は移送プロトコルアウトバウンドのフロー図である。開始ブロック4200から、アウトバウンド要求3511は移送プロトコルアウトバウンドキュー421に到着して、ステップ4202の要求の受取りを引き起こす。ステップ4203は取引相手プロフィールテーブル413からのデータを使って、それからレスポンダと転送経路の詳細を判断する。ステップ4204は、次にレスポンダが取引相手プロフィールテーブル413に存在するかどうか判断する。もしレスポンダがテーブル413に存在しない場合、ステップ4205でその製品の使用許諾状況を判断する。もしその製品が使用許諾されていた場合、ステップ4207は、取引相手プロフィールテーブル413に新規レスポンダ情報を保存し、ステップ4206に続く。もしその製品が使用許諾されていない場合、ステップ4208はエラーメッセージを生成し、その親に当たる処理にそのメッセージを送信して、この処理は終了ブロック4211にて終了する。もしステップ4204で、レスポンダが取引相手プロフィールテーブル413に存在していた場合、ステップ4206はそれからパッケージを圧縮してエンコードし、ステップ4209はそのアウトバウンド要求をアクティビティログ422に書き込み、ステップ4210で、その要求をネットワーク104上のレスポンダに送信する。この処理は、終了ブロック4211にて終了する。
【図面の簡単な説明】
【０１６６】
【図１】図１は、コンピュータネットワークを通して接続されている複数のサーバでトランザクションエンジン環境の起動、初期化、作用に使用する基本的な構成要素の相互関係を説明する、システムのブロック図である。
【図２】図２は、図１のウェブホストサーバ１０１の関連構成要素のブロック図である。
【図３】図３は、図１のサードパーティサーバ１０２の関連構成要素のブロック図である。
【図４】図４は、図１のコマースサーバ１０３の関連構成要素のブロック図である。
【図５】図５は、図１のクライアントアプリケーションサーバ１０６の関連構成要素のブロック図である。
【図６】図６は、システム１００の起動の概要のフロー図である。
【図７】図７は、インタビュー処理の概要のフロー図である。
【図８】図８は、インタビュービジネス機能のフロー図である。
【図９】図９は、情報の応用と利用のためのインタビューの詳細のフロー図である。
【図１０】図１０は、オブジェクトのロードと起動の概要フロー図である。
【図１１】図１１は、リソースセンターオブジェクトのロードと起動の概略のフロー図である。
【図１２】図１２は、バックオフィス通信オブジェクトのロードと起動の概略のフロー図である。
【図１３】図１３は、ＥＤＩトランスレータオブジェクトのロードと起動の概略のフロー図である。
【図１４】図１４は、ＸＭＬトランスレータオブジェクトのロードと起動の詳細のフロー図である。
【図１５】図１５は、ビジネスツービジネス（企業間）コミュニケーションオブジェクトのロードと起動の概略のフロー図である。
【図１６】図１６は、ウェブホストコミュニケーションオブジェクトのロードと起動の詳細の概要フロー図である。
【図１７】図１７は、システム１００の環境及び接続性の初期化のフロー図である。
【図１８】図１８は、移送プロトコルのインストールのフロー図である。
【図１９】図１９は、ローカルプロフィールファンクションの作成のフロー図である。
【図２０】図２０は、レスポンダ処理のフロー図である。
【図２１】図２１は、ネットワークを介して情報を移送するために使用されるイニシエータのイベント状態のフロー図である。
【図２２】図２２は、ネットワークを介して情報を移送するために使用されるレスポンダのイベント状態のフロー図である。
【図２３】図２３は、移送プロトコルリスナーのフロー図である。
【図２４】図２４は、移送プロトコルのユーザインターフェイスのフロー図である。
【図２５】図２５は、移送プロトコルシェルのフロー図である。
【図２６】図２６は、セッション要求のフロー図である。
【図２７】図２７は、キー要求処理のフロー図である。
【図２８】図２８は、送信データパッケージのフロー図である。
【図２９】図２９は、セッション終了のフロー図である。
【図３０】図３０は、中止／エラー報告のフロー図である。
【図３１】図３１は、クローズセッションのフロー図である。
【図３２】図３２は、送信アウトバウンド要求のフロー図である。
【図３３】図３３は、プロトコルパッケージのフロー図である。
【図３４】図３４は、トランザクションフローの概要のフロー図である。
【図３５】図３５は、キュー処理関係の概要図である。
【図３６】図３６は、移送プロトコルインバウンドのフロー図である。
【図３７】図３７は、トランザクションエンジンインバウンドのフロー図である。
【図３８】図３８は、トランザクションエンジンシェルのフロー図である。
【図３９】図３９は、ＳＤＳインバウンドのフロー図である。
【図４０】図４０は、ＳＤＳアウトバウンドのフロー図である。
【図４１】図４１は、トランザクションエンジンアウトバウンドのフロー図である。
【図４２】図４２は、移送プロトコルアウトバウンドのフロー図である。
【図１】
2004538547.tif 000002
【図２】
2004538547.tif 000003
【図３】
2004538547.tif 000004
【図４】
2004538547.tif 000005
【図５】
2004538547.tif 000006
【図６】
2004538547.tif 000007
【図７】
2004538547.tif 000008
【図８】
2004538547.tif 000009
【図９】
2004538547.tif 000010
【図１０】
2004538547.tif 000011
【図１１】
2004538547.tif 000012
【図１２】
2004538547.tif 000013
【図１３】
2004538547.tif 000014
【図１４】
2004538547.tif 000015
【図１５】
2004538547.tif 000016
【図１６】
2004538547.tif 000017
【図１７】
2004538547.tif 000018
【図１８】
2004538547.tif 000019
【図１９】
2004538547.tif 000020
【図２０】
2004538547.tif 000021
【図２１】
2004538547.tif 000022
【図２２】
2004538547.tif 000023
【図２３】
2004538547.tif 000024
【図２４】
2004538547.tif 000025
【図２５】
2004538547.tif 000026
【図２６】
2004538547.tif 000027
【図２７】
2004538547.tif 000028
【図２８】
2004538547.tif 000029
【図２９】
2004538547.tif 000030
【図３０】
2004538547.tif 000031
【図３１】
2004538547.tif 000032
【図３２】
2004538547.tif 000033
【図３３】
2004538547.tif 000034
【図３４】
2004538547.tif 000035
【図３５】
2004538547.tif 000036
【図３６】
2004538547.tif 000037
【図３７】
2004538547.tif 000038
【図３８】
2004538547.tif 000039
【図３９】
2004538547.tif 000040
【図４０】
2004538547.tif 000041
【図４１】
2004538547.tif 000042
【図４２】
2004538547.tif 000043
【国際公開パンフレット】
2004538547.tif 000044
2004538547.tif 000045
2004538547.tif 000046
2004538547.tif 000047
2004538547.tif 000048
2004538547.tif 000049
2004538547.tif 000050
2004538547.tif 000051
2004538547.tif 000052
2004538547.tif 000053
2004538547.tif 000054
2004538547.tif 000055
2004538547.tif 000056
2004538547.tif 000057
2004538547.tif 000058
2004538547.tif 000059
2004538547.tif 000060
2004538547.tif 000061
2004538547.tif 000062
2004538547.tif 000063
2004538547.tif 000064
2004538547.tif 000065
2004538547.tif 000066
2004538547.tif 000067
2004538547.tif 000068
2004538547.tif 000069
2004538547.tif 000070
2004538547.tif 000071
2004538547.tif 000072
2004538547.tif 000073
2004538547.tif 000074
2004538547.tif 000075
2004538547.tif 000076
2004538547.tif 000077
2004538547.tif 000078
2004538547.tif 000079
2004538547.tif 000080
2004538547.tif 000081
2004538547.tif 000082
2004538547.tif 000083
2004538547.tif 000084
2004538547.tif 000085
2004538547.tif 000086
2004538547.tif 000087
2004538547.tif 000088
2004538547.tif 000089
2004538547.tif 000090
2004538547.tif 000091
2004538547.tif 000092
2004538547.tif 000093
2004538547.tif 000094
2004538547.tif 000095
2004538547.tif 000096
2004538547.tif 000097
2004538547.tif 000098
2004538547.tif 000099
2004538547.tif 000100
2004538547.tif 000101
2004538547.tif 000102
2004538547.tif 000103
2004538547.tif 000104
2004538547.tif 000105
2004538547.tif 000106
2004538547.tif 000107
2004538547.tif 000108
2004538547.tif 000109
2004538547.tif 000110
2004538547.tif 000111
2004538547.tif 000112
2004538547.tif 000113
2004538547.tif 000114
2004538547.tif 000115
2004538547.tif 000116
2004538547.tif 000117
2004538547.tif 000118
2004538547.tif 000119
2004538547.tif 000120
2004538547.tif 000121
2004538547.tif 000122
2004538547.tif 000123
2004538547.tif 000124
2004538547.tif 000125
2004538547.tif 000126
2004538547.tif 000127
2004538547.tif 000128
2004538547.tif 000129
2004538547.tif 000130
2004538547.tif 000131
2004538547.tif 000132
2004538547.tif 000133
2004538547.tif 000134
2004538547.tif 000135
2004538547.tif 000136
2004538547.tif 000137
2004538547.tif 000138
2004538547.tif 000139
2004538547.tif 000140
【国際公開パンフレット（コレクトバージョン）】
2004538547.tif 000141
【国際調査報告】
2004538547.tif 000142