JP2009520267A - 電子データ交換（ｅｄｉ）のためのｘｍｌ仕様 - Google Patents

Abstract

電子データ交換（ＥＤＩ）取引を変換するための拡張可能マークアップ言語（ＸＭＬ）仕様。ＥＤＩデータの集合はバッチとして受信される。ＥＤＩデータのバッチには、複数のＥＤＩドキュメントが含まれる。こうした複数のＥＤＩドキュメントの各々は、取引タイプに対応する少なくとも１つのＥＤＩ取引を有している。ＥＤＩドキュメントに含まれるＥＤＩ取引は、受信したＥＤＩデータをＥＤＩ標準にしたがって復号化することにより識別される。ＥＤＩデータのバッチ内の複数のＥＤＩドキュメントから、１つの統合化されたＥＤＩドキュメントが生成される。この統合化されたＥＤＩドキュメントには、取引タイプにしたがって編成された、識別したＥＤＩ取引が含まれている。

Description

取引の処理を容易にするために、事業体は、一般的な通信ネットワークを介して、厳密なフォーマットで電子的に企業取引データを頻繁に送信する。たとえば、電子データ交換（ＥＤＩ）は、企業が絶えず拡張している自動化されたコンピューティングシステムの領域を利用する方法の１つである。

ＥＤＩでは、ＡＮＳＩ Ｘ１２またはＥＤＩＦＡＣＴといった１つまたは複数の既知の承認された標準にしたがって、企業データがフォーマットされる。たとえば、さまざまな取引を表すＥＤＩデータは、明確に記述された（ｄｅｌｉｎｅａｔｅｄ）ドキュメントのバッチとして送信され、このような記述されたドキュメントの各々が、厳密なフォーマットルールにしたがって符号化され、こうしたドキュメントを受信する送信先のアプリケーションが、ダウンストリーム処理のために、その情報を正常に解析でき、その情報を使用できることが確実になる。

ＥＤＩメッセージを解析および処理する際に、既存のシステムは、ＥＤＩデータを送信する。また、既存のシステムには、交換するときに、明確に記述された各ドキュメントにおけるフォーマットルールまたはスキーマが含まれる。たとえば、発注（ｐｕｒｃｈａｓｅ ｏｒｄｅｒ）取引を表すＥＤＩデータには、発注取引用のスキーマが含まれる。したがって、個々のＥＤＩ取引ドキュメントには、ＥＤＩデータと、その取引に固有のスキーマとが含まれている。こうした仕組みまたは構成によって、ＥＤＩデータの解析は容易になるが、これは静的であり、各取引ドキュメントのドキュメントサイズは増大する。さらに、含まれるスキーマは、共有することができない。すなわち、２つの発注取引ドキュメントＡおよびＢが存在する場合、たとえ各発注取引ドキュメントのスキーマが同一だったとしても、ドキュメントごとに発注スキーマを含める必要がある。また、ＥＤＩ取引は有料であり、特に、行数またはドキュメント数、およびＥＤＩデータの送信に必要な帯域幅に応じて課金される。事業体は、ＥＤＩを用いて、日常的に膨大な数の取引を送信するので、このようにスキーマ情報が重複して含まれる大量のＥＤＩ取引ドキュメントによって、冗長なスキーマ情報を保持するための無駄なコストが発生する。

ＥＤＩ取引ドキュメントが受信されると、送信先のアプリケーションは通常、このＥＤＩ取引ドキュメントをメモリ領域に記憶する。次いで、送信先のアプリケーションは、取引が受信されたことを示す受信確認応答（ｒｅｃｅｉｐｔ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を送信元に送信する。その後、アプリケーションは、記憶されたＥＤＩ取引の有効性を検査して、取引ドキュメントに含まれるＥＤＩデータが、該当する取引タイプのスキーマ用のフォーマットルールに準拠しているか否かを判定する。こうした有効性検査を実行している間、送信元（たとえば、販売者または顧客）は、取引データがフォーマットに準拠することを示す有効性確認応答を待つ必要がある。１つまたは複数の取引のフォーマットが適切でないと判定された場合、代替のＥＤＩ取引ドキュメントを再送信して処理する必要がある。こうした有効性検査の待機によって発生する遅延により、ＥＤＩ取引の処理効率はさらに低下する。

本発明の実施形態は、さまざまなＥＤＩ取引タイプを識別するネスト構造またはサブドキュメントを使用して複数のＥＤＩ取引ファイルを１つのＥＤＩドキュメントに変換することにより、ＥＤＩ取引の処理における既存のシステムのこうした欠点を克服する。さらに、本発明の態様によって、ＥＤＩ取引がランタイムに処理されるときに、スキーマのインスタンスを使用できるようにすることにより、ＥＤＩドキュメントでスキーマが参照できるようになる。本発明の実施形態は、ＥＤＩ取引が受信されたときに、取引タイプに関連付けられたスキーマを自動的に認識して、ＥＤＩ取引を処理するという点で有効である。本発明の別の実施形態にしたがうと、ＥＤＩ取引が受信されたときに、ＥＤＩ取引の有効性が検査される。

本発明のさらに別の実施形態では、複数のスキーマを表す、統合化されたメタスキーマ（ｕｎｉｔａｒｙ ｍｅｔａ−ｓｃｈｅｍａ）が定義される。統合化されたメタスキーマが提供されると、エンドユーザは、スキーマのプロパティを変更することができる。

この要約は、詳細な説明において以下でさらに記載するいくつかの概念を簡略化した形で紹介するために提供されたものである。この要約は、特許請求される主題事項の重要な特徴または本質的な特徴を示すものでも、特許請求される主題事項の範囲を決定するための助けとして使用するものでもない。

その他の特徴については、一部は明らかであり、一部は本明細書の以下の部分で説明する。

付録Ａは、図１０Ａに示すＸＭＬスキーマの全体を説明するものである。

付録Ｂは、発注スキーマを表す、ＸＭＬフォーマットで記述された例示的な統合化されたメタスキーマを示している。

すべての図面を通して、対応する参照番号は対応する要素を表している。

図１は、ＥＤＩ取引の処理の実装を示すブロック図である。図１に示すように、まず、送信元（たとえば、ビジネスパートナ）１０２は、一般的な通信ネットワーク１０８を介して、請求書（ｉｎｖｏｉｃｅ）２０２を含めることができるＥＤＩメッセージ１０６を、送信先１０４（たとえば、企業の顧客）に送信する。

送信元１０２は、一般的な通信ネットワーク１０８を介して、スキーマおよびＥＤＩ取引データを含むＥＤＩメッセージ１０６を、送信先１０４に送信する。一例では、送信コストまたは帯域幅コストを節約するために、ＥＤＩメッセージ１０６には、複数のＥＤＩ取引データがバッチとして含まれる。別の例では、一般的な通信ネットワーク１０８は、イントラネットなどの専用プライベートネットワークでもよいし、インターネットなどのパブリックネットワークでもよい。別の例では、パートナ間でのＥＤＩメッセージの送信を円滑にするために、一般的な通信ネットワーク１０８には、ＦＴＰ、ＨＴＴＰ、カーミット（Ｋｅｒｍｉｔ）、Ｘｍｏｄｅｍ、Ｆｒａｍｅ Ｄｅｌａｙ、ＥＤＩＩＮＴ、３７８０ Ｂｉｓｙｎｃ（登録商標）など、１つまたは複数のネットワークプロトコルが含まれる。

送信元１０２は、送信先１０４との接続セッション（たとえば、セキュアソケット接続セッション）をオープンすることにより、一般的な通信ネットワーク１０８を介して、ＥＤＩメッセージ１０６の送信を開始する。接続セッションがオープンになると、送信元１０２は、ＥＤＩメッセージ１０６を送信先１０４に送信する。送信先１０４におけるＥＤＩトランスレータ（ｔｒａｎｓｌａｔｏｒ）システムのセット１１０がＥＤＩメッセージ１０６を受信すると、ＥＤＩトランスレータシステム１１０は、一般的な通信ネットワーク１０８を介して、ＥＤＩメッセージを受信したことを示す受信確認応答１１２を、送信元１０２に送信する。受信確認応答は、送信元１０２が接続セッションをクローズする前に送信元１０２に送信されるか、または返信されるのが一般的である。

ＥＤＩメッセージ１０６が受信されると、ＥＤＩ取引に関連付けられたＥＤＩデータが、ＥＤＩトランスレータシステム１１０によって解析されて処理される。当業者にとっては周知であるように、ＥＤＩ取引の解析および／または復号化には、さまざまなＥＤＩ標準、スキーマ仕様などを識別するための１つまたは複数のステップが含まれる。これを実行する際、ＥＤＩトランスレータシステム１１０は、解析または復号化したＥＤＩデータを、ダウンストリームアプリケーション（ｄｏｗｎｓｔｒｅａｍ ａｐｐｌｉｃａｔｉｏｎ）１１４に送信して、解析または復号化したＥＤＩデータを処理する。たとえば、ダウンストリームアプリケーション１１４は、請求書を処理する会計アプリケーションであってもよいし、発注データを処理するソフトウェアであってもよい。このように、ダウンストリームアプリケーション１１４は、受信したＥＤＩデータを解析および復号化した後で、スキーマに指定されたフォーマットルールに準拠しているか否かを判定することができる。受信したＥＤＩデータがスキーマルールに準拠していた場合、ダウンストリームアプリケーション１１４は、有効性確認応答１１６を送信元１０２に送信する。一方、受信したＥＤＩデータにエラーが含まれる場合、またはＥＤＩデータが無効な場合、ダウンストリームアプリケーション１１４は、受信したＥＤＩデータのエラーを示すエラー通知を、送信元に送信することができる。

有効性確認応答１１６は通常、受信確認応答の送信後、遅延を伴って送信元１０２に送信される。他の実装では、解析したＥＤＩデータは、データベースまたはデータストア（図示せず）に記憶され、有効性が検査されるまで待機する。したがって、送信元１０２は、送信先１０４によってＥＤＩデータを適切に処理できることが確認されるまで、有効性確認応答１１６を待つよう頻繁に要求される。

図２Ａ〜図２Ｃは、本発明の一実施形態にしたがう、電子データ交換（ＥＤＩ）を使用した取引データの構造を示す図である。図２Ａは、ＡＮＳＩ Ｘ１２フォーマットを使用した請求書のＥＤＩ取引ドキュメント２０２の例を示している。この例では、請求書２０２には、機能グループ（ｆｕｎｃｔｉｏｎａｌ ｇｒｏｕｐ）２０４セクションなどの複数のセグメントまたは複数のセクションが含まれている（Ｘ１２ ＥＤＩ交換の構造２１８の概要については、図２Ｃを参照されたい）。こうしたセグメントまたはセクションには、請求書２０２の追加の情報を含めることができる。たとえば、図２Ｃに示すように、サプライチェーンセクタでは、当業者にとっては周知であるように、機能グループ２０４内の情報または値は、交換セクション（たとえば、交換制御ヘッダ）内の情報または値に等しい。別の例では、機能グループ２０４内の情報または値には、比較的大規模な企業の事業単位または作業単位を識別する値または識別子が含まれる。

また、請求書２０２には、企業の顧客の情報といった情報が記載されるヘッダ部分２０６も含まれている。この例では、ヘッダ部分２０６には、企業の顧客の名前「ＡＢＣ Ｃｏｍｐａｎｙ」と、住所「０８８７ Ｓｉｘｔｈ Ｓｔｒｅｅｔ，Ｓａｉｎｔ Ｌｏｕｉｓ，ＭＯ ６３１０１」とが含まれている。一実施形態では、ヘッダ部分２０６には、有効性確認応答を受信するための送信先情報が含まれている（以下の図８、図９Ａ、および図９Ｂに関する説明を参照されたい）。また、請求書２０２には、ループ２１０内に構成された１つまたは複数のデータセグメント２１２を示す詳細テーブルセクション２０８も含まれている。たとえば、ループ２１０には、意味的に関連するデータセグメントのグループが含まれている。当業者にはよく知られているように、これらのセグメントは、ＡＮＳＩ Ｘ１２．６にしたがって、範囲が制限されてもよいし、制限されなくてもよい。

ＥＤＩ取引ドキュメントには、ＡＮＳＩ Ｘ１２フォーマットまたはＥＤＩＦＡＣＴフォーマットにしたがって、本発明の範囲から逸脱することなく、追加のセグメントタイプ、セクション、および、それに対応する情報を含めることができる。たとえば、図２Ｂは、同一のＥＤＩメッセージ１０６に含まれており、かつ送信先１０４にて処理される１つまたは複数の取引タイプを示している。請求書２１４および発注書２１６は、同じ顧客「ＡＢＣ Ｃｏｍｐａｎｙ」に関連するため、請求書２１４および発注書２１６のＥＤＩ取引ドキュメントは、ＥＤＩメッセージ１０６に含まれている。関連する取引ドキュメントの追加のグループを、ＥＤＩメッセージ１０６として、交換に含めることもできる。一実施形態では、１つの送信先または１つの顧客に対するＥＤＩドキュメントを、バッチとして送信することができる。

ＥＤＩ取引タイプの各々は、その取引タイプに関連付けられたスキーマに準拠する必要があることも理解されたい。たとえば、請求取引スキーマでは、特に販売者または購入者の名前を表す文字列の最大長または最小長に関する所定の制限を課すことができる。発注取引スキーマでは、小数点以下の最大桁数を指定することもできる。別の例では、さまざまな取引タイプに関するスキーマでは、特定のフィールドは必須であるが、別のフィールドはオプションであるように指定することもできる。

既存の実装では、送信先１０４といった顧客にＥＤＩ取引を送信するときに、ＥＤＩ取引ドキュメントに取引スキーマを含める。このような実装によってＥＤＩ取引の復号化は容易になるが、スキーマ設計者は、ビジネスパートナにＥＤＩ取引を送信する前に、かなりの時間をかけてスキーマの設計と設定とを行う必要がある。また、後にパートナ間の業務契約の変更に伴ってスキーマが変更された場合、スキーマの再設計が必要になる。

したがって、本発明の実施形態では、取引タイプにしたがって１つまたは複数のＥＤＩ取引を編成するネスト構造またはサブドキュメントを使用してＥＤＩメッセージを１つの統合されたＥＤＩドキュメントに変換することにより、既存の実装のそのような欠点を克服する。また、ＥＤＩドキュメントには、取引タイプに関連付けられた複数のスキーマを表す超スキーマ（ｕｂｅｒ−ｓｃｈｅｍａ）も含まれる。別の実施形態では、ランタイムスキーママップ（ｒｕｎｔｉｍｅ ｓｃｈｅｍａ ｍａｐ）によって、送信先１０４において、複数のスキーマをランタイムに処理するように変換する。

次に図３を参照すると、本発明の実施形態にしたがう、ＥＤＩ取引を変換するシステム３０２のブロック図が示されている。システム３０２には、送信元３０４が含まれる。送信元３０４は、送信先３０６すなわち顧客と業務取引を行う販売者とすることができる。たとえば、送信元３０４は、コンピュータ機器を購入する企業顧客に大量の商品を販売する家電小売業者などの販売者であってもよい。別の例では、送信元３０４は、病院または薬局などのヘルスケア提供者とすることができ、送信元３０４は、請求を提出するため、または医療保険の相互運用性と責任に関する法律（ＨＩＰＡＡ：Ｈｅａｌｔｈ Ｉｎｓｕｒａｎｃｅ Ｐｏｒｔａｂｉｌｉｔｙ ａｎｄ Ａｃｃｏｕｎｔａｂｉｌｉｔｙ Ａｃｔ）にしたがうために、医療保険会社または交換所（ｃｌｅａｒｉｎｇ ｈｏｕｓｅ）にＥＤＩデータを送信する。

一実施形態では、送信元３０４および送信先３０６には、図１２のコンピュータ１３０などの１つまたは複数のコンピューティングデバイスが含まれており、こうしたコンピューティングデバイスが、ＥＤＩドキュメントをバッチとして送信する。最初に、送信元３０４が、複数のＥＤＩドキュメントを含むＥＤＩメッセージ３１０を送信する。ＥＤＩドキュメントの各々には、取引タイプ（たとえば、請求、発注、支払勘定（ａｃｃｏｕｎｔ ｐａｙａｂｌｅ）など）に対応する少なくとも１つのＥＤＩ取引が含まれる。

さらに図４Ａを参照すると、本発明の実施形態にしたがってＥＤＩ取引を変換する方法の流れ図が示されている。送信元３０４が、送信先３０６と通信するために通信ネットワーク３０８上で接続セッションをオープンした後、送信元３０４は、送信先３０６のＥＤＩエンジン３１２にＥＤＩメッセージ３１０を送信する。一実施形態では、ＥＤＩエンジン３１２には、コンピュータ実行可能な命令、ルーチン、または機能を実行する１つまたは複数のコンピューティングデバイス（たとえば、コンピュータ１３０）が含まれている。４０２で、ＥＤＩエンジン３１２は、複数のＥＤＩドキュメントを含むＥＤＩメッセージ３１０を受信する。４０４で、ＥＤＩエンジン３１２は、複数のＥＤＩドキュメントに含まれるＥＤＩ取引を識別する。上述したＡＮＳＩ Ｘ１２の例を使用すると、ＥＤＩエンジン３１２は、図２Ｃに示したさまざまなデータヘッダおよびデータセグメント（たとえば、ＩＳＡ、ＧＳなど）を識別することにより、Ｘ１２請求書の復号化または解析を行って、取引に含まれるＥＤＩデータを判別する。別の実施形態では、ＥＤＩエンジン３１２はさらに、複数のＥＤＩドキュメントに含まれるさまざまなスキーマも識別して、その取引タイプに固有のフォーマットルールを判別する。

４０６で、ＥＤＩエンジン３１２は、複数のＥＤＩドキュメントをバッチとして統合化したＥＤＩドキュメント３１４を生成する。一例では、ＥＤＩエンジン３１２は、統合化したＥＤＩドキュメント３１４を、ＸＭＬ構造マークアップタグ付きのＸＭＬドキュメントとして生成する（４１０）。たとえば、各取引が１つのドキュメントとして編成される既存の実装とは異なり、本発明の実施形態では、複数のＥＤＩドキュメント内のＥＤＩ取引を１つのＸＭＬドキュメントとして編成する。このＸＭＬドキュメントは、個々の取引セットを定義するだけでなく、セグメント、ループ、フィールド、デリミタなどを含めて、ＥＤＩデータのすべての特徴を取得することによって、交換を定義する。一例として、図６Ａに、「ＰＯ（発注書）」などの、１つまたは複数のＥＤＩ取引を含む統合化された例示的なＸＭＬドキュメントを示す。

さらに別の実施形態では、統合化したＥＤＩドキュメント３１４には、ＥＤＩ取引によって参照される複数のスキーマを表す超スキーマが含まれる。たとえば、超スキーマは、ＥＤＩ取引セットに含まれており、各ＥＤＩ取引の機能グループおよびエンベロープセグメント（ｅｎｖｅｌｏｐｅ ｓｅｇｍｅｎｔｓ）内に埋め込まれているか、または組み込まれている。したがって、エンドユーザは、ＥＤＩメッセージ３１０に含まれていると想定される取引セットごとに固有のスキーマを作成する必要がない。一例として、図６Ｂに、本発明の一実施形態にしたがって統合化されたＥＤＩドキュメント３１４に含まれるＸＭＬフォーマットの超スキーマのスクリーンショットを示す。このような設計では、統合化したＥＤＩドキュメント３１４の交換により、それぞれがＥＤＩドキュメント内の取引タイプに対応する１つまたは複数のスキーマを含める必要性が低減する。また、本発明の実施形態では、送信を行う前のスキーマの設計時間およびスキーマの開発時間も短縮される。

別の実施形態では、図４Ｂの４１２で、ＥＤＩエンジン３１２は、ランタイムスキーママップまたはペイロードスキーマ（ｐａｙｌｏａｄ ｓｃｈｅｍａ）を使用して、統合化されたＥＤＩドキュメントを変換する。４１４で、ＥＤＩエンジン３１２は、統合化されたＥＤＩドキュメント３１４に含まれるＥＤＩ取引を表すサブドキュメントまたはネスト構造を作成する（さらなる説明は、表１および表２を参照されたい）。代替実施形態では、統合化されたＥＤＩドキュメント３１４は、ペイロードスキーマ（たとえば、ランタイムスキーママップ）によって変換され、さらに構造上変換されてもよい（４１６）。あるいは、統合化されたＥＤＩドキュメント３１４は、構造上の変換を行わずに、ダウンストリームアプリケーション３１６に送信されて処理されてもよい（４１８）。４２０で、サブドキュメントまたはネスト構造を伴う統合化されたＥＤＩドキュメント３１４は、ダウンストリームアプリケーション３１６に送信されて処理される。

ＥＤＩ取引を識別可能な構造によって定義して編成する統合化されたＥＤＩドキュメント３１４を表すＸＭＬ以外のマークアップタグ付きフォーマットを、本発明の範囲から逸脱することなく、使用できることを理解されたい。

別の実施形態では、上述した本発明の態様を記憶可能なコンピュータ読み取り可能な媒体１１０２（図１１Ａ）が提供される。たとえば、上述した１つまたは複数の動作を実行するＥＤＩエンジン３１２には、インターフェースコンポーネント１１０４、識別コンポーネント１１０６、および変換コンポーネント１１０８を含めることができる。

さらに、図４Ａに示した方法を送信元３０４により実行することができるので、送信元３０４は、送信前に交換のサイズを低減できることも理解されたい。このように、統合化されたＥＤＩドキュメント３１４のネスト構造またはサブドキュメントによって、行数が減少するため、行数にしたがって課金される場合、ＥＤＩデータの送信コストを削減することもできる。

たとえば、表１は、統合化されたＥＤＩドキュメント内でネスト構造をとる３つのＥＤＩ取引と、当該ネスト構造をとる３つのＥＤＩ取引の各々に対応する３つの取引の１つを含むオリジナルの３つのＥＤＩドキュメントとを示している。

業務において、ヘルスケアスポンサ（たとえば、雇用主Ａ）は、支払人（たとえば、ヘルスケア提供者Ｂ）にＥＤＩメッセージ（たとえば、ＨＩＰＡＡ ８３４ドキュメント）を送信する必要があると仮定する。このような交換のスキーマでは、雇用主Ａが、ヘルスケア受益者／受給者（たとえば、従業員らおよび従業員らの扶養家族）の利益の詳細を提示する必要がある。したがって、雇用主Ａは一般に、スポンサおよび支払人の詳細情報を含める。このスポンサおよび支払人の詳細情報は、すべての受益者に共通であり、雇用主Ａが提供する利益を受け取る従業員または扶養家族ごとに繰り返されることになる。既存のＥＤＩの実装のように、数千人の従業員および扶養家族について同一のスポンサおよび支払人情報を繰り返すのではなく、本発明の実施形態では、ネスト構造を作成することによって、１つのＥＤＩドキュメント内でループと同様のロジックを使用して、スポンサおよび支払人の詳細情報のコピーとともに、各メンバを作成できるようにする。

図５Ａは、本発明の実施形態にしたがうＥＤＩ取引のネストを示すブロック図である。たとえば、５０２で、送信元（たとえば、送信元３０４）から送信されたＥＤＩメッセージ（たとえば、ＥＤＩメッセージ３１０）が、送信先（たとえば、送信先３０６）にて受信される。５０４で、複数のＥＤＩ取引がネスト構造またはサブドキュメントとして含まれる統合化されたＥＤＩドキュメントが生成される。一例では、エンベロープ／制御セグメント（たとえば、ＡＮＳＩ Ｘ１２フォーマットのＩＳＡ／ＧＳ／ＧＥ／ＩＥＡセグメント）が除去され、受信パイプラインによって取引セット（ＳＴ／ＳＥ）が解析されて、取引セットごとに複数のＸＭＬサブドキュメントが生成される。一実施形態では、複数のＸＭＬサブドキュメントがメッセージボックスに格納される。５０６で、送信先の受信パイプラインが、受信した交換の有効性検査を実行し、適切な有効性確認応答を生成する（図８、図９Ａ、および図９Ｂを用いて詳細に説明する）。一実施形態では、受信パイプラインはさらに、チェックサムおよび事業総計（ｂｕｓｉｎｅｓｓ ｔｏｔａｌｓ）の更新も行う。

上述したように、統合化されたＥＤＩドキュメント３１４は、ダウンストリームアプリケーション３１６によって処理することができる。したがって、統合化されたＥＤＩドキュメントは、送信ポートに送信され、５０８で、送信ポートは、ＥＤＩ取引をＥＤＩサブドキュメントとして送信する。一実施形態では、送信ポートに関連付けられた送信パイプラインは、ＸＭＬサブドキュメントをシリアライズして（ｓｅｒｉａｌｉｚｅ）、セグメントの数が送信パイプラインにて更新された「ｎ」個の交換を送信する。

一実施形態では、ＥＤＩ交換が受信されると、その有効性が検査される。有効性検査でエラーがない場合、各取引セットは、そのスキーマにしたがって、ＸＭＬフォーマットに変換される。このようにして、ＥＤＩ交換には、発注ドキュメントと請求ドキュメントとを含めることができる。発注書は、発注スキーマに準拠するＸＭＬに変換される。同様に、請求書は、請求書ＸＭＬに変換される。

図５Ｂは、ＥＤＩ交換による例示的な発注書をＸＭＬフォーマットで示している。図５Ａで、この発注ドキュメントが送信側で処理される場合は、エンベロープセグメントの処理後に、ＥＤＩフォーマット５１４に変換される。図５Ｃは、図５ＢのＸＭＬフォーマットから送信ポートによって生成される例示的なドキュメントを示している。一実施形態では、ＥＤＩフォーマット５１４には、２つのエンベロープセグメント（すなわち、ＩＳＡで始まる行およびＧＳで始まる行）が含まれる。同様に、ＥＤＩフォーマット５１４には、ドキュメントの終わりに２つのエンベロープセグメントＧＥおよびＩＥＡが含まれる。図示されているように、ＳＴセグメントとＳＥセグメントとの間に含まれるデータは、オリジナルの取引セットのデータである。

図５Ｂおよび図５Ｃに示した上述の例では、ＳＥ０１の値（矢印５１２を参照）は「１４」であり、送信ポートによって動的に計算される。ＥＤＩドキュメントをシリアライズする際に、ＥＤＩエンジン（たとえば、ＥＤＩエンジン３１２）の送信側は、取引セット内に存在するセグメント数を追跡する。この値に基づいて、ＳＥ０１の値が決定される。

送信元３０４が、統合化されたＥＤＩドキュメント３１４を生成して複数のＥＤＩドキュメントのＥＤＩ取引を含める場合、本発明の実施形態には、含まれるＥＤＩ取引をネスト構造で編成することが含まれる。別の例では、本発明の実施形態により、統合化されたＥＤＩドキュメント３１４を送信元から受信する送信先３０６は、後方互換性を提供するために、すなわち、ドキュメントごとに単一の取引を含むＥＤＩドキュメント以外を処理することができないダウンストリームアプリケーション３１６に対応するために、統合化されたＥＤＩドキュメント３１４から複数のＥＤＩドキュメントを復元することができる。本発明の代替実施形態では、ネスト構造のＥＤＩ取引を伴う統合化されたＥＤＩドキュメントが、オリジナルの複数のＥＤＩドキュメントを追跡するか、オリジナルの複数のＥＤＩドキュメントと相関させることができる。

たとえば、表２は、統合化されたＥＤＩドキュメント３１４から複数のＥＤＩドキュメントにＥＤＩ取引を変換する方法を示している。

表２に示す例では、ネスト構造をとるＥＤＩ取引の処理は、予め定められたＳｕｂＤｏｃｕｍｅｎｔＣｒｅａｔｉｏｎＢｒｅａｋＰｏｉｎｔ（たとえば、親ドキュメント内で子ドキュメントの始まる位置を示すマーカ「＼」）を識別することによって開始して、複数のサブドキュメントを生成する。

表２によると、列Ａ１に示された統合化されたＥＤＩドキュメントは、スキーマ内のＢＢループにて定義されるサブドキュメント作成のブレークポイント（ｂｒｅａｋ）にしたがって、３つの取引、すなわち、ＢＢ１＊１〜ＢＢ２＊１、ＢＢ１＊２、およびＢＢ１＊３〜ＢＢ２＊３に分割することができる。列Ａ２では、取引セットＢＢ１＊１〜ＢＢ２＊１が独立したドキュメントに編成または分割され（太字のテキストで示されている）、列Ａ３では、取引ＢＢ１＊２が２番目のドキュメントに編成される（下線付きのテキストで示されている）。同様に、取引セットＢＢ１＊３〜ＢＢ２＊３は、ダウンストリームアプリケーション３１６によって処理される３番目のＥＤＩドキュメントに編成される（斜体のテキストで示されている）。

本発明の実施形態では、複数のＥＤＩドキュメントに含まれるＥＤＩ取引を、統合化されたＥＤＩドキュメント３１４に変換することにより、送信先３０６または送信元３０４は、各ＥＤＩドキュメントに含まれる複数のスキーマを、変換中に効率的に識別できるようにする。さらに、本発明の少なくとも１つの態様では、送信先３０６が、統合化されたＥＤＩドキュメントを変換した後に、有効性確認応答を生成し、接続セッションが引き続きオープンである間に、送信元３０４に返信できるようにしている。すなわち、本発明の態様では、送信先３０６は、ＥＤＩ取引を受信している間に複数のスキーマを自動的に識別してＥＤＩ取引の有効性を検査するように構成されている。

次に、図７Ａ〜図７Ｄを参照すると、本発明の実施形態にしたがって、ＥＤＩスキーマを自動的に識別することを表す一連のスクリーンショットが示されている。図７Ａは、ＡＮＳＩ Ｘ１２による一般的な発注スキーマを示している。スキーマは、当該スキーマに関連付けられたＤｏｃＴｙｐｅによって識別される。ＤｏｃＴｙｐｅは、ネームスペースおよびルートノード名などの、設定項目（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｔｅｍｓ）の組合せである。図７Ａに示すように、このスクリーンショットの左の列７０２は、スキーマの階層構造を表している。この例では、左の列７０２はスキーマ構造を示している。中央の列７０４はスキーマのＸＭＬコードを示している。右の列７０６は、スキーマに含まれるプロパティまたはターゲットネームスペースを示している。

一実施形態では、ＤｏｃＴｙｐｅは、Ｘ１２フォーマットにおいて、「ＤｏｃＴｙｐｅ＝ＴａｒｇｅｔＮａｍｅｓｐａｃｅ‘＃’ＲｏｏｔＮｏｄｅＮａｍｅ」である。これについては、以下で詳細に説明する。図７Ａに示すＸ１２スキーマについて説明するが、ＥＤＩＦＡＣＴスキーマなどの他のスキーマフォーマットも、本発明の範囲から逸脱することなく、使用できることを理解されたい。

ＤｏｃＴｙｐｅのルートノードは、Ｘ１２フォーマット、「Ｘ１２＿｛Ｖｅｒｓｉｏｎ｝＿｛ＴｓＩｄ｝」の１つを有している。この例では、ボックス７０８によって示されるように、設定項目「ｒｏｏｔ ｎｏｄｅ」の値は、「Ｘ１２＿００４０１＿８５０」である。すなわち、「００４０１」は、ドキュメントのバージョンであり、ランタイム処理中に設定またはインスタンスを決定する動的な情報である。同様に、「８５０」は、ＴｓＩｄ、すなわち、処理中のスキーマの取引識別子（ＩＤ）であり、入力インスタンスから決定される。この例では、取引ＩＤ「８５０」は、ボックス７１０によって示されるように、発注を表している。また、ターゲットネームスペースは、右の列７０６にボックス７１２によって示されている。

別の例では、ＥＤＩＦＡＣＴフォーマットのスキーマを復号化または識別するために、現在、ＥＤＩＦＡＣＴスキーマのフォーマットは、「Ｅｆａｃｔ＿｛Ｖｅｒｓｉｏｎ｝＿｛Ｔｓｉｄ｝」である。すなわち、すべてのＥＤＩＦＡＣＴスキーマは、「Ｅｆａｃｔ」で始まるルートノード名を有し、ＶｅｒｓｉｏｎおよびＴｓｉｄの定義は、Ｘ１２フォーマットの場合と同一である。

一例として図３を使用すると、送信先３０６が送信元３０４からＥＤＩドキュメントを受信したときに、ＥＤＩ取引には、取引ＩＤ「８５０」とドキュメントとを含めることができる。しかし、バージョン情報またはターゲットネームスペース情報は、ランタイムに決定される。こうした設定項目の値は、別々のレベルで設定されてもよい。このように、ＥＤＩ標準（たとえば、Ｘ１２またはＥＤＩＦＡＣＴ）にしたがったルールを適用して、対応する取引タイプ（たとえば、発注、請求など）にしたがってＥＤＩ取引を復号化した後、ＥＤＩエンジン３１２は、復号化したＥＤＩ取引に含まれる設定項目を識別する。一実施形態では、ＥＤＩエンジン３１２は、パートナレベルおよび送信アプリケーションレベル、グローバルレベル、パイプラインレベル、またはデフォルトレベルなどの、１つまたは複数の設定レベルから設定項目を識別する。

たとえば、図７Ｂは、パーティ（ｐａｒｔｙ）レベルの設定における設定項目を表すスクリーンショットを示している。この例では、図７Ａに示した上述のパートナの取引ＩＤ「８５０」は、上述のターゲットネームスペースおよびバージョン情報を使用するように設定されている。ボックス７１４によって示されるように、デフォルトのフラグまたはパラメータがオンであるため、その他のすべてのドキュメントタイプについてデフォルト値が使用される。別の例では、業務取引パートナ間で締結された業務契約に基づいて、別の取引パートナが、パーティレベルの設定における他の特定の設定項目を設定することもできる。設定項目の値を静的に決定する代わりに、本発明の実施形態では、スキーマを自動的に識別するときに、取引パートナにより１つまたは複数の設定レベルから設定された特定の値を決定することによって、設定項目の値を識別する。

一実施形態では、パーティレベルの設定における設定項目の値は、送信側ＩＤと取引ＩＤとの特定の組合せにより、図７ＡのＤｏｃＴｙｐｅに示した値とは異なる値に設定されてもよい。たとえば、Ｘ１２では、各送信側ＩＤは企業内の所定の部門を表していてもよい。したがって、ある企業における１つの送信側ＩＤは、「ハードウェア製品」部門を意味し、別の送信側ＩＤは、同一企業内の「ソフトウェア製品」部門を意味することもできる。このようにして、本発明の実施形態では、こうした異なる設定が認識され、それに応じてスキーマが識別される。その結果、１つの企業が発行した同一の発注は、異なるスキーマ識別プロセスにより処理されることになり、たとえば、設定項目の値にしたがって、統合化されたＥＤＩドキュメント３１４内に、適切であり、かつ異なるＥＤＩデータが、ＸＭＬで生成されてもよい。

また、特定のビジネスパートナによって、本発明の範囲から逸脱することなく、１つまたは複数の追加の設定項目を設定または指定できることも理解されたい。たとえば、１つのパートナが最小限の設定を行い、別のパートナが、そのパーティレベルの設定において詳細な設定項目を定義することもできる。

次に図７Ｃを参照すると、ＥＤＩＦＡＣＴスキーマとそのパーティレベルの設定とを表示したスクリーンショットが示されている。この例では、Ｘ１２スキーマとは異なり、送信側アプリケーションＩＤ（オプション）（７１６のＵＮＧ２．１および７１８のＵＮＧ２．２など）、バージョン７２０（ＵＮＧ８）、および取引セットＩＤ７２２の特定の組合せに基づいて、ターゲットネームスペースを設定することができる。すなわち、１つの請求ＥＤＩドキュメントに対して、それぞれ一意のアプリケーションＩＤを伴う複数の設定が可能である。この場合では、ランタイムに特定のアプリケーションに一致するターゲットネームスペースが使用される。送信側アプリケーションＩＤが設定されていない場合では、送信側アプリケーションＩＤの値は、同一の取引ＩＤを有する既存のレコード（たとえば、ログファイル）に含まれるいずれかの値と照合される。一致するものが複数存在する場合には、デフォルトのターゲットネームスペースが使用され、曖昧性があるときには、適切なデフォルト値が使用されることが保証される。

図７Ｄは、Ｘ１２スキーマのグローバルレベルの設定を示すスクリーンショットである。この例では、取引パートナがターゲットネームスペースまたはバージョンなどの設定項目を設定していないため、グローバルレベルの設定による設定項目の値が使用されることになる。この例では、ボックス７２４が、バージョンおよびターゲットネームスペースに値が設定されていないことを示している。したがって、設定項目の値は、ランタイムには変更されない。

グローバルレベルにおいて欠落した（ｍｉｓｓｉｎｇ）設定項目のいくつかが設定されていない場合は、パイプラインレベルの設定またはランタイムレベルの設定における設定項目の値が使用されることになる。したがって、ターゲットネームスペースがグローバルレベルで設定されていない場合、パイプラインレベルの設定における値が使用されることになる。一実施形態では、パイプラインレベルの設定における値は、ユーザが設定することもできる。

別の実施形態において、図１１Ｂは、本発明の態様を記憶できるコンピュータ読み取り可能な媒体１１１０を示している。たとえば、インターフェースコンポーネント１１１２は、送信元からＥＤＩドキュメントをバッチとして受信する。ここで、各ＥＤＩドキュメントには、取引タイプに対応する少なくとも１つのＥＤＩ取引が含まれる。取引コンポーネント１１１４は、ＥＤＩ標準（たとえば、Ｘ１２またはＥＤＩＦＡＣＴ）にしたがうルールを適用することにより、対応する取引タイプにしたがってＥＤＩ取引を復号化する。設定コンポーネント１１１６は、復号化したＥＤＩ取引に含まれるＥＤＩ取引の各々について、１つまたは複数の設定項目の値を識別する。スキーマコンポーネント１１１８は、設定項目の値に基づいて、１つまたは複数のスキーマタイプを判別する。

代替実施形態では、前述の各セクションで説明した設定項目の値を、ランタイムに変更することができる。したがって、ＥＤＩエンジン３１２がＥＤＩドキュメントを処理した後（すなわち、スキーマを自動的に識別した後）に、取引タイプ、ターゲットネームスペース、バージョンの値を変更することができる。このような実施形態では、変更は、これから処理されることになる後続のドキュメントに対して反映される。本発明のこうした動的な実装により、送信先３０６のユーザは、ＥＤＩドキュメントが送信元３０４から送信される前のスキーマ設計／設定を行う間ではなく、ランタイムに値を設定することができる。

動作中に、スキーマを自動的に識別することにより、ＥＤＩパートナは、ＥＤＩドキュメントの処理をストリームライン処理（ｓｔｒｅａｍｌｉｎｅ ｐｒｏｃｅｓｓｉｎｇ）することができる。すべてのパートナおよびすべてのドキュメントタイプに対して受信接続および送信接続を設定しなければならない既存の実装とは異なり、ＥＤＩエンジン３１２では、ランタイムに設定項目の値を識別して判別する形で自動的にスキーマを識別できるので、ＥＤＩビジネスパートナは、ＥＤＩデータを柔軟に処理することができるようになる。

少なくとも本発明の別の態様には、ＥＤＩデータを受信したときに、有効性確認応答を生成することが含まれていることについて再考する。図８Ａは、こうした機能を示す流れ図である。８０２で、ＥＤＩメッセージ（たとえば、ＥＤＩメッセージ３１０）が、送信元（たとえば、送信元３０４）から送信先（たとえば、送信先３０６）へ送信される。８０４で、ＥＤＩ取引を含むＥＤＩメッセージが送信先で受信される。次いで、８０６で、ＥＤＩメッセージが適切な受信者に宛てられたものであるか否かを判定することにより、ＥＤＩメッセージの送信が、有効か否かが判定される。ＥＤＩメッセージの送信が無効と判定された場合、ＥＤＩメッセージの処理が保留され、交換失敗確認応答（ｉｎｔｅｒｃｈａｎｇｅ ｆａｉｌｕｒｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）が生成される（８０８）。ＥＤＩメッセージの交換が有効と判定された場合、次に、ＥＤＩ取引のグループにエラーが含まれるか否かが判定される（８１０）。

グループにエラーが含まれる場合、ＥＤＩ取引のグループの処理が保留され、機能失敗確認応答（ｆｕｎｃｔｉｏｎａｌ ｆａｉｌｕｒｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）が生成される（８１２）。たとえば、ＥＤＩ仕様では、グループレベルおよび取引セットレベルで検出可能な複数のエラーを定義することができる。表３に、Ｘ１２ ＥＤＩ交換に適用可能な一般的なエラーのリストを示す。

たとえば、ＥＤＩエンジン３１２は、ＥＤＩメッセージ内の行／セグメントＧＳの６番目の値を識別することによって、エラーコード４、すなわち、「機能グループのヘッダ内とトレーラ内のグループ制御番号が一致しない」というエラーを確認する。図８Ｂで、５３２に示すＧＳの行の６番目の値は「９」である（ボックス５２８によって示されている）。ＥＤＩ取引の有効性を検査する際に、本発明の実施形態では、５３４に示すＧＥの行の２番目の値に同一の値が存在するか否かを判定する。図８Ｂに示すように、５３４に示すＧＥの行の２番目の値は「１０」である（ボックス５３０によって示されている）。このような不一致により、このＥＤＩメッセージにはエラーがあることが確認される。

別の例では、ＧＳ−ＧＥセグメント間の取引セットを識別することにより、エラーコード５、すなわち、「含まれる取引セットの数が実際のカウントと一致しない」が検出される。図８Ｂに示すように、１つのＧＳ−ＧＥセグメントが存在するのに対して、ＧＥの行の最初の値は「０２」であり、２つの取引セットが存在することを示している。したがって、この機能グループはエラーになる。

しかし、グループ内にエラーが存在しないと判定された場合は、次に８１４で、Ｘ１２フォーマットまたはＥＤＩＦＡＣＴフォーマットにしたがうフォーマットルールを評価し、かつＥＤＩ取引に含まれるスキーマにしたがうルールを評価することにより、各ＥＤＩ取引が、有効か否かが判定される。ＥＤＩ取引が無効と判定された場合、ＥＤＩ取引の処理が保留され、８１６で、機能失敗確認応答が生成される。

たとえば、表４に、一般的な取引エラーのリストを示す。

一例として図８Ｂを使用すると、ＥＤＩエンジン（たとえば、ＥＤＩエンジン３１２）は、ＳＴとＳＥとの間のセグメント（行）の数を評価することにより、エラーコード４、すなわち、「含まれるセグメントの数が実際のカウントと一致しない」を識別する。この例では、数は「１２」であるのに対して、ＳＥの行の最初の値は「１４」である。したがって、この取引セットにはエラーが存在し、こうしたエラーコードを機能失敗確認応答に含めることができる。

一実施形態では、ＥＤＩエンジン（たとえば、ＥＤＩエンジン３１２）は、ＥＤＩ取引のさまざまなエラー条件またはルールを参照できるか、またはそうした情報を有することができる。ＥＤＩエンジン３１２は、ＥＤＩドキュメントを処理している間に、いずれのＥＤＩフォーマットルールにも違反しないことを確認する。違反がある場合には、ＥＤＩエンジン３１２は、交換または機能レベルの確認応答の形で、適切にレポートする。

一方、ＥＤＩ取引が有効な場合は、送信先のＥＤＩエンジン３１２が、ＥＤＩ取引の処理に進む（８１８）。８２０で、ＥＤＩ取引が有効であることを示す有効性確認応答が生成される。一実施形態では、ＥＤＩメッセージ、ＥＤＩグループ、および／またはＥＤＩ取引が受信されて有効性が確認された場合は、ＥＤＩエンジン３１２は、統合化した有効性確認応答をまとめて生成することができる。別の実施形態では、ＥＤＩメッセージ、ＥＤＩグループ、および／またはＥＤＩ取引が受信されて有効性が確認されるとほぼ同時に、ＥＤＩエンジンは、統合した有効性確認応答を生成する。

８２４で、生成された有効性確認応答が、送信元に返送され、８２６で、送信元が、有効性確認応答を受信する。一実施形態では、送信元は、接続セッションをオープンしてＥＤＩメッセージを送信し、有効性確認応答を受信した後に同じ接続セッションをクローズする。したがって、図３の矢印３１８によって示されるように、有効性検査のプロセスは、ＥＤＩ取引のランタイムに、またはＥＤＩ取引の受信中に処理されるため、ドキュメントの有効性検査中に、データベースまたはデータストアへのアクセスも、ディスクＩ／Ｏも、発生しない。さらに別の実施形態では、有効性検査のプロセスは、ランタイムにプラグインハンドラによって拡張することもできる。

代替実施形態では、ＥＤＩメッセージ／取引が受信されたときに、さまざまなタイプの有効性確認応答が生成され、別々の場所に送信されてもよい（こうした場所の情報は、ヘッダ部分１０６において検出可能である）。このように、本発明の実施形態では、１つまたは複数の段階（たとえば、交換の１つの態様における有効性を検査した後）で、有効性確認応答を生成して送信するか、または単一の段階で、統合化した確認応答を生成して送信する。さらに別の実施形態では、図３の矢印３２０によって示されるように、こうした確認応答は、同じソケット接続セッションまたは新たなソケット接続セッションを用いて、さまざまな送信先に配信するよう設定することができる。

たとえば、スキーマまたはフォーマットルールの指定により、発注書の有効性確認応答が、企業内の顧客サービス部門に送信されるよう設定され、請求書の有効性確認応答が、同じ企業内の経理部門に送信されるよう設定されていると想定する。本発明の態様では、新たな接続セッションをオープンすることにより、それぞれの確認応答を適切な送信先に送信することができる。図９Ａは、Ｘ１２フォーマットのＥＤＩ取引に関する有効性確認応答を示しており、図９Ｂは、ＥＤＩＦＡＣＴフォーマットのＥＤＩ取引に関する有効性確認応答を示している。

別の実施形態において、図１１Ｃは、本発明の態様を記憶できるコンピュータ読み取り可能な媒体１１２０を示している。たとえば、インターフェースコンポーネント１１２２、確認応答コンポーネント１１２４、および有効性検査コンポーネント１１２６は、図８Ａに示した１つまたは複数のステップを実行するＥＤＩエンジン３１２に組み込まれて、統合されてもよい。

本発明のさらなる態様では、エンドユーザにＥＤＩスキーマ開発者と同等の知識を要求することなく、ＥＤＩスキーマの変更が可能となる。たとえば、ある企業内で新たな部門が開設されたものの、その部門に適用するカスタマイズされたＥＤＩスキーマまたはルールはまだ存在していないと仮定する。本発明の実施形態により、ＥＤＩスキーマ開発者に対してその新たな部門に固有のＥＤＩスキーマの設計を要求するのではなく、エンドユーザが変更できるようにスキーマのプロパティを提示する形で、すべてのスキーマを表現するメタスキーマが定義される。

図１０Ａは、本発明の実施形態にしたがって、複数のＥＤＩスキーマを変更するための統合化されたメタスキーマを示すスクリーンショットである。ウィンドウペイン１００２において、統合化されたメタスキーマの構造が、エンドユーザに示される。エンドユーザがプロパティ（「ＭａｘＯｃｃｕｒｓ」を囲む破線によって示される）を強調表示すると、対応するプロパティコードセクションが、ウィンドウペイン１００４において直ちに強調表示され、エンドユーザは、プロパティの値を変更することができる。一実施形態では、図１０Ａに示すように、本発明の態様を具現化するユーザインターフェース（ＵＩ）が、エンドユーザに提供される。付録Ａは、図１０Ａに示すＸＭＬスキーマの全体を説明するものである。

図１０Ｂは、本発明の実施形態にしたがって、統合化されたメタスキーマを使用して複数のＥＤＩスキーマを変更する方法を示す流れ図である。１００６で、複数のＥＤＩスキーマ内のデータを復号化することにより、複数のＥＤＩスキーマを表す統合化された構造が識別される。一例では、図１１Ｄのデータ構造１１２８などの統合化された構造が、以下の１つまたは複数のデータを取得することにより、複数のＥＤＩスキーマを表す。
１．各ＥＤＩスキーマは、名前付きのルート要素（ｒｏｏｔ ｅｌｅｍｅｎｔ）から構成される。
２．ルート要素は、ループまたはセグメントとすることができるデータブロックの繰り返しから構成される。
３．各ループは以下の構造を有している。
ａ．Ｎａｍｅ−ループの名前
ｂ．Ｂｌｏｃｋ−データ要素の集合
ｃ．ＭｉｎＯｃｃｕｒｓ−出現回数の最小値
ｄ．ＭａｘＯｃｃｕｒｓ−出現回数の最大値
４．各セグメントは、さまざまなプロパティを有している。
ａ．Ｎａｍｅ−セグメントの名前
ｂ．ＴａｇＩｄ−セグメントのタグＩＤ
ｃ．ＭｉｎＯｃｃｕｒｓ−出現回数の最小値
ｄ．ＭａｘＯｃｃｕｒｓ−出現回数の最大値
ｅ．データ要素のリスト
５．各データ要素は、要素の集合から構成され、要素の集合の各々は、複合要素でも単一要素でもよい。
６．各単一要素はさまざまなプロパティを有している。
ａ．Ｎａｍｅ−要素の名前
ｂ．ＭｉｎＯｃｃｕｒｓ−出現回数の最小値
ｃ．ＭａｘＯｃｃｕｒｓ−出現回数の最大値
ｄ．ＭｉｎＬｅｎｇｔｈ−データ長の最小値
ｅ．ＭａｘＬｅｎｇｔｈ−データ長の最大値
ｆ．ＤａｔａＴｙｐｅ−データ型。使用可能な値は、Ａ、ＡＮ、ＩＤ、Ｒ、Ｎ、Ｄａｔｅ、Ｔｉｍｅ−各ＥＤＩデータ型につき１つ
ｇ．ＡｌｌｏｗｅｄＶａｌｕｅｓ−使用可能な値のセット。要素の型がＩＤの場合にのみ適用可能。

たとえば、データ構造１１２８には、第１のデータフィールド１１３０が含まれている。この第１のデータフィールド１１３０には、複数のＥＤＩスキーマの各々におけるルート要素に関連付けられたルートデータが含まれている。データ構造にはまた、１つまたは複数の第２のデータフィールド１１３２も含まれている。この第２のデータフィールド１１３２には、複数のＥＤＩスキーマの各々における１つまたは複数のデータブロックを表すデータが含まれている。１つまたは複数の第２のデータフィールドに含まれるデータは、第１のデータフィールド１１３０に含まれるルートデータの関数（ｆｕｎｃｔｉｏｎ）として定義される。

１００８では、統合化された構造に含まれるプロパティが決定される。こうしたプロパティは、複数のＥＤＩスキーマの特性を定義するものである。たとえば、ルート要素のプロパティ値が、「ｐｕｒｃｈａｓｅ ｏｒｄｅｒ」の場合、統合化された構造の特性が、図７Ａに示すような発注スキーマに対応することを示している。プロパティ値を伴う統合化された構造によって、統合化されたメタスキーマは、定義済みの特性、および統合化された構造に応じて、ユーザ用に定義される（１０１０）。定義されたメタスキーマは、複数のＥＤＩスキーマに対応する。図１０Ａに示すように、１０１２で、定義されたメタスキーマに含まれる決定されたプロパティがエンドユーザに提供され、エンドユーザは、複数のＥＤＩスキーマの各々における特性を変更することができる。

付録Ｂは、以下の構造を含む発注スキーマを表す、ＸＭＬフォーマットで記述された例示的な統合化されたメタスキーマを示している。
１．ＰｕｒｃｈａｓｅＯｒｄｅｒＤｅｔａｉｌセグメント
２．ＬｉｎｅＩｔｅｍおよびＳｈｉｐｐｉｎｇＡｄｄｒｅｓｓセグメントから構成されるループ
３．Ｎｏｔｅｓセグメント

図１２は、コンピュータ１３０の形態をとる汎用コンピューティングデバイスの一例を示している。本発明の一実施形態では、コンピュータ１３０などのコンピュータは、本明細書で示して説明した他の図面においても使用するのに適している。コンピュータ１３０は、１つまたは複数のプロセッサ、あるいは処理ユニット１３２と、システムメモリ１３４とを備えている。図示された実施形態では、システムバス１３６は、システムメモリ１３４を含むさまざまなシステムコンポーネントをプロセッサ１３２に接続している。システムバス１３６は、さまざまなバスアーキテクチャのいずれかを使用した、メモリバスまたはメモリコントローラ、周辺バス、アクセラレータグラフィックポート、およびプロセッサバスまたはローカルバスを含む様々なタイプのバス構造の任意の１つまたは複数を表している。こうしたバスアーキテクチャには、たとえば、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれるが、これらに限定されるものではない。

コンピュータ１３０は通常、少なくとも何らかの形態のコンピュータ読み取り可能な媒体を備えている。コンピュータ読み取り可能な媒体には、揮発性媒体および不揮発性媒体の両方、ならびに取り外し可能な媒体および取り外し不可能な媒体の両方を含めることができ、コンピュータ読み取り可能な媒体は、コンピュータ１３０によってアクセス可能な任意の使用可能な媒体とすることができる。たとえば、コンピュータ読み取り可能な媒体には、コンピュータ記憶媒体および通信媒体が含まれるが、これらに限定されるものではない。コンピュータ記憶媒体には、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶する任意の方法または技術を用いて実装された、揮発性媒体および不揮発性媒体、ならびに取り外し可能な媒体および取り外し不可能な媒体が含まれる。たとえば、コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、もしくはその他のメモリ技術、ＣＤ ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、もしくはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくはその他の磁気記憶装置、または必要な情報を記憶でき、かつコンピュータ１３０がアクセス可能なその他の任意の媒体が含まれる。通信媒体は一般に、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、またはその他のデータなどを、搬送波やその他の搬送メカニズムのような変調されたデータ信号内に具現化したものであり、通信媒体には任意の情報伝達媒体が含まれる。当業者にとっては周知であるが、変調されたデータ信号は、信号内の情報を符号化するようにその１つまたは複数の特性が設定または変更された信号である。通信媒体の例として、有線ネットワークや直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、またはその他の無線媒体などの無線媒体とがある。前述した媒体の任意の組合せも、コンピュータ読み取り可能な媒体の範囲に含まれる。

システムメモリ１３４には、取り外し可能なメモリおよび／または取り外し不可能なメモリ、揮発性メモリおよび／または不揮発性メモリの形態をとるコンピュータ記憶媒体が含まれる。図示された実施形態では、システムメモリ１３４には、ＲＯＭ１３８とＲＡＭ１４０とが含まれる。起動時などにコンピュータ１３０内の要素間の情報転送を支援する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１４２は通常、ＲＯＭ１３８に記憶されている。ＲＡＭ１４０には通常、処理ユニット１３２が直ちにアクセスでき、かつ／または処理ユニット１３２が現在操作しているデータおよび／またはプログラムモジュールが記憶される。たとえば、図１２には、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０が示されているが、これらに限定されるものではない。

コンピュータ１３０には、その他の取り外し可能／取り外し不可能な揮発性／不揮発性のコンピュータ記憶媒体を含めてもよい。例えば、図１２には、取り外し不可能な不揮発性の磁気媒体に対して読み書きを行うハードディスクドライブ１５４が示されている。図１２にはさらに、取り外し可能な不揮発性の磁気ディスク１５８に対して読み書きを行う磁気ディスクドライブ１５６、ＣＤ ＲＯＭや他の光媒体などの取り外し可能な不揮発性の光ディスク１６２に対して読み書きを行う光ディスクドライブ１６０も示されている。例示的な動作環境で使用できるその他の取り外し可能／取り外し不可能な揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれるが、これらに限定されるものではない。ハードディスクドライブ１５４、磁気ディスクドライブ１５６、および光ディスクドライブ１６０は通常、インターフェース１６６などの不揮発性メモリインターフェースを介して、システムバス１３６に接続される。

図１２に示して前述したドライブまたはその他の大容量記憶装置、およびこれらに関連するコンピュータ記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、およびその他のデータのための記憶領域を、コンピュータ１３０に提供する。たとえば、図１２において、ハードディスクドライブ１５４は、オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６を記憶するものとして示されている。こうしたコンポーネントは、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０と同じであってもよいし、異なっていてもよいことに留意されたい。ここでは、オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６には異なる番号を付けて、少なくとも異なるコピーであることを示している。

ユーザは、キーボード１８０やポインティングデバイス１８２（たとえば、マウス、トラックボール、ペン、またはタッチパッド）などの入力装置またはユーザインターフェース選択装置を介して、コンピュータ１３０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信用アンテナ（ｓａｔｅｌｌｉｔｅ ｄｉｓｈ）、スキャナなどを含めることができる。これらの入力装置および他の入力装置は、システムバス１３６に接続されたユーザ入力インターフェース１８４を介して処理ユニット１３２に接続されているが、パラレルポート、ゲームポート、またはＵＳＢなどの他のインターフェースやバス構造を介して接続されてもよい。モニタ１８８または他のタイプの表示装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１３６に接続されている。コンピュータには、モニタ１８８に加えて、出力周辺インターフェース（図示せず）を介して接続できるプリンタやスピーカなどの出力周辺装置（図示せず）が備えられていることが多い。

コンピュータ１３０は、リモートコンピュータ１９４などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境において動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常は、コンピュータ１３０に関連して上述した要素の多くまたはすべてを備えている。図１２に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）１９６とワイドエリアネットワーク（ＷＡＮ）１９８とが含まれるが、その他のネットワークを含めてもよい。ＬＡＮ１９６および／またはＷＡＮ１９８は、有線ネットワーク、無線ネットワーク、およびそれらの組合せなどとすることができる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびグローバルなコンピュータネットワーク（たとえば、インターネット）において一般的である。

コンピュータ１３０は、ローカルエリアネットワーキング環境で使用される場合、ネットワークインターフェースまたはネットワークアダプタ１８６を介して、ＬＡＮ１９６に接続される。コンピュータ１３０は一般に、ワイドエリアネットワーキング環境で使用される場合、インターネットなどのＷＡＮ１９８を介して通信を確立するためのモデム１７８またはその他の手段を備えている。内蔵型でも外付け型でもよいモデム１７８は、ユーザ入力インターフェース１８４または他の適切な機構を介して、システムバス１３６に接続される。ネットワーク環境では、コンピュータ１３０またはその一部に関連して説明したプログラムモジュールを、リモートメモリ記憶装置（図示せず）に記憶することができる。たとえば、図１２には、メモリ装置に存在するものとしてリモートアプリケーションプログラム１９２を示したが、これに限定されるものではない。図示されたネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を使用してもよい。

一般に、コンピュータ１３０のデータプロセッサは、コンピュータに備えられたさまざまなコンピュータ読み取り可能な記憶媒体に、さまざまな時間において記憶された命令によって、プログラミングされている。プログラムおよびオペレーティングシステムは、一般的には、たとえば、フロッピー（登録商標）ディスクやＣＤ−ＲＯＭによって配布される。さらに、それら命令が、こうしたフロッピー（登録商標）ディスクやＣＤ−ＲＯＭから、コンピュータの２次メモリにインストールまたはロードされる。実行時に、それら命令の少なくとも一部が、コンピュータの１次電子メモリにロードされる。上記およびその他のさまざまなタイプのコンピュータ記憶媒体に、以下でマイクロプロセッサまたはその他のデータプロセッサに関連して説明するステップを実装する命令またはプログラムが記憶されている場合、本明細書で説明した本発明の態様には、こうした媒体が含まれる。さらに、本明細書で説明した方法および技術にしたがってプログラミングされている場合、本発明の態様には、こうしたコンピュータ自体も含まれる。

例示の目的上、オペレーティングシステムなどの、プログラムおよびその他の実行可能なプログラムコンポーネントは、本明細書では別個のブロックとして示されている。しかし、こうしたプログラムおよびコンポーネントは、さまざまな時間において、コンピュータのさまざまな記憶コンポーネントに記憶され、コンピュータの（１つまたは複数の）データプロセッサによって実行されることが理解されよう。

コンピュータ１３０を含む例示的なコンピューティングシステム環境に関して説明したが、本発明の実施形態は、他のさまざまな汎用または専用のコンピューティングシステム環境またはコンピューティングシステム構成とともに動作可能である。こうしたコンピューティングシステム環境は、本発明のいかなる態様についても、その使用または機能の範囲に関していかなる限定を示すものではない。さらに、こうしたコンピューティングシステム環境は、例示的な動作環境において図示されたコンポーネントの任意の１つ、またはそれらコンポーネントの組合せに関して、いかなる依存関係または要件を有するものとして解釈されるべきではない。

本発明の態様とともに使用するのに適した周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電子機器、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、前述の任意のシステムまたはデバイスを含む分散コンピューティング環境などが含まれるが、これらに限定されるものではない。

本発明の実施形態は、１つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令といった一般的なコンテキストにおいて説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造が含まれるが、これらに限定されるものではない。本発明の態様は、通信ネットワークを介して接続されるリモート処理デバイスによってタスクが実行される分散コンピューティング環境においても実施することができる。分散コンピューティング環境では、メモリ記憶装置を含むローカルのコンピュータ記憶媒体とリモートのコンピュータ記憶媒体との両方に、プログラムモジュールを配置することができる。

インターフェースは、たとえば、Ｊａｖａ（登録商標）２ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）、ＣＯＭ、またはＤＣＯＭなどの密結合（ｔｉｇｈｔｌｙ ｃｏｕｐｌｅｄ）による同期の実装とすることができる。代替として、またはこれに加えて、インターフェースは、（たとえば、ＳＯＡＰを使用した）ウェブサービスなどの疎結合による非同期の実装であってもよい。一般に、インターフェースには、密結合、疎結合、同期、および非同期といった特性の任意の組合せが含まれる。さらに、インターフェースは、標準プロトコル、専用プロトコル、または標準プロトコルと専用プロトコルとの任意の組合せにしたがってもよい。

本明細書で説明したすべてのインターフェースは、単一のインターフェースの一部であってもよいし、別々のインターフェースとして実装されてもよいし、それらの任意の組合せとして実装されてもよい。インターフェースは、ローカルまたはリモートで実行して、機能を提供してもよい。さらに、このインターフェースが備える機能は、本明細書で図示した機能または説明した機能より多くてもよいし、少なくてもよい。

コンピュータ１３０は、動作中に、図面に示した命令などのコンピュータ実行可能命令を実行して、本発明の態様を実現する。

本明細書で図示または説明した本発明の実施形態における動作の実行順序または実現順序は、特に指定されない限り、本質的なものではない。すなわち、特に指定されない限り、動作は、任意の順序で実行できる。また、本発明の実施形態には、本明細書で開示した動作より多くの動作を含めてもよいし、本明細書で開示した動作より少ない動作を含めてもよい。たとえば、特定の動作の実行または実現が、別の動作より前、別の動作と同時、または別の動作より後であっても、本発明の態様の範囲内にあることが意図されている。

本発明の実施形態は、コンピュータ実行可能命令を使用して実装することができる。コンピュータ実行可能命令は、１つまたは複数のコンピュータ実行可能なコンポーネントまたはコンピュータ実行可能なモジュールに構成することができる。本発明の態様は、こうしたコンポーネントまたはモジュールを任意の数だけ任意に構成して実装することができる。たとえば、本発明の態様は、図面に示して本明細書で説明した特定のコンピュータ実行可能命令、特定のコンポーネント、または特定のモジュールに限定されるものではない。本発明の他の実施形態には、本明細書で図示または説明した機能より多いか、または少ない機能を備える別のコンピュータ実行可能命令またはコンピュータ実行可能なコンポーネントが含まれてもよい。

本発明の態様またはその実施形態の要素を説明した際に、「１つの（ａ，ａｎ）」、「その（ｔｈｅ，ｓａｉｄ）」、および「前記（ｔｈｅ，ｓａｉｄ）」という冠詞は、１つまたは複数の要素を意味するものと意図されている。用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、および「有する（ｈａｖｉｎｇ）」は、包括的であるものとして意図されており、列挙した要素以外の要素が追加されてもよいことを意味している。

本発明の態様の範囲を逸脱することなく、前述の構成、製品、および方法に対してさまざまな変更を加えることができるので、前述の説明に含まれる事項、および添付の図面に示される内容は、すべて例示的なものとして理解すべきであり、限定的な意味として解釈すべきではない。

（付録Ａ）
セクション１：ＸＭＬフォーマットにおいてＥＤＩスキーマを表すメタスキーマ

（付録Ｂ）
セクション２：メタスキーマの統合化された構造を使用した発注スキーマの例

ＥＤＩ取引の処理の実装を示すブロック図である。 本発明の一実施形態にしたがう電子データ交換（ＥＤＩ）を使用した取引データの構造を示す図である。 本発明の一実施形態にしたがう電子データ交換（ＥＤＩ）を使用した取引データの構造を示す図である。 本発明の一実施形態にしたがう電子データ交換（ＥＤＩ）を使用した取引データの構造を示す図である。 本発明の一実施形態にしたがってＥＤＩ取引を変換するシステムを示す例示的なブロック図である。 本発明の一実施形態にしたがうＥＤＩ取引の変換を示す流れ図である。 本発明の一実施形態にしたがうＥＤＩ取引の変換を示す流れ図である。 本発明の一実施形態にしたがうＥＤＩ取引のネストを示すブロック図である。 本発明の一実施形態にしたがうＥＤＩ取引のシリアライズを示すブロック図である。 本発明の一実施形態にしたがうＥＤＩ取引のシリアライズを示すブロック図である。 本発明の一実施形態にしたがう、拡張可能マークアップ言語（ＸＭＬ）ドキュメントフォーマットの統合化されたＥＤＩドキュメントに含まれる変換されたＥＤＩ取引を示すスクリーンショットである。 本発明の一実施形態にしたがう、拡張可能マークアップ言語（ＸＭＬ）ドキュメントフォーマットの統合化されたＥＤＩドキュメントに含まれる変換されたＥＤＩ取引を示すスクリーンショットである。 本発明の一実施形態にしたがうＥＤＩスキーマの自動的な識別を示すスクリーンショットである。 本発明の一実施形態にしたがうＥＤＩスキーマの自動的な識別を示すスクリーンショットである。 本発明の一実施形態にしたがうＥＤＩスキーマの自動的な識別を示すスクリーンショットである。 本発明の一実施形態にしたがうＥＤＩスキーマの自動的な識別を示すスクリーンショットである。 本発明の一実施形態にしたがってＥＤＩ取引の有効性を検査する方法を示す流れ図である。 本発明の一実施形態にしたがうＥＤＩ取引のエラーの検出を示す図である。 本発明の一実施形態にしたがうＥＤＩ有効性確認応答の構造を示す図である。 本発明の一実施形態にしたがうＥＤＩ有効性確認応答の構造を示す図である。 本発明の一実施形態にしたがう、複数のＥＤＩスキーマを変更するための統合化されたメタスキーマを示すスクリーンショットである。 本発明の一実施形態にしたがって、統合化されたメタスキーマを使用して、複数のＥＤＩスキーマを変更するための方法を示す流れ図である。 本発明の態様を記憶できる例示的なコンピュータ読み取り可能な媒体を示すブロック図である。 本発明の態様を記憶できる例示的なコンピュータ読み取り可能な媒体を示すブロック図である。 本発明の態様を記憶できる例示的なコンピュータ読み取り可能な媒体を示すブロック図である。 本発明の態様を記憶できる例示的なコンピュータ読み取り可能な媒体を示すブロック図である。 本発明を実装できる適切なコンピューティングシステム環境の一例を示すブロック図である。

Claims (20)

1. 少なくとも一部はコンピューティングデバイスによって実装される、電子データ交換（ＥＤＩ）取引を変換する方法であって、
   ＥＤＩデータをバッチとして受信するステップであって、前記ＥＤＩデータの前記バッチは、複数のＥＤＩドキュメントを含み、該複数のＥＤＩドキュメントの各々は、１つの取引タイプに対応する少なくとも１つのＥＤＩ取引を有する、受信するステップと、
   該受信したＥＤＩデータを、ＥＤＩ標準にしたがって復号化することにより、前記ＥＤＩドキュメントに含まれる前記ＥＤＩ取引を識別するステップと、
   前記バッチ内の前記複数のＥＤＩドキュメントから、１つの統合化されたＥＤＩドキュメントを生成するステップであって、前記１つの統合化されたＥＤＩドキュメントは、前記取引タイプにしたがって編成された、前記識別したＥＤＩ取引のＥＤＩデータを含む、生成するステップと
   を備えることを特徴とする方法。
2. 前記統合化されたＥＤＩドキュメントは、拡張可能マークアップ言語（ＸＭＬ）ドキュメントである
   ことを特徴とする請求項１に記載の方法。
3. 前記統合化されたＥＤＩドキュメントに含まれる前記ＥＤＩ取引を、ＸＭＬタグによって構造化するステップ
   をさらに備え、
   前記ＸＭＬタグは、前記ＥＤＩ取引の前記取引タイプを示している
   ことを特徴とする請求項２に記載の方法。
4. 前記統合化されたＥＤＩドキュメントは、超スキーマを含んでおり、
   該超スキーマは、前記ＥＤＩ取引が参照する複数のスキーマを表す
   ことを特徴とする請求項１に記載の方法。
5. 前記複数のスキーマをランタイムに処理するように変換するためのランタイムスキーママップを定義するステップ
   をさらに備えることを特徴とする請求項４に記載の方法。
6. 前記統合化されたＥＤＩドキュメント内の前記ＥＤＩ取引を、前記ＥＤＩ取引に含まれる１つまたは複数の情報にしたがってサブドキュメントとして編成するステップ
   をさらに備え、
   前記サブドキュメント内の前記ＥＤＩ取引は、前記複数のＥＤＩドキュメント内の前記ＥＤＩ取引と相互に関連する
   ことを特徴とする請求項１に記載の方法。
7. 請求項１に記載の方法を実行するためのコンピュータ実行可能命令を有することを特徴とする１つまたは複数のコンピュータ読み取り可能な媒体。
8. 送信元と受信側デバイスとの間における電子データ交換（ＥＤＩ）取引を変換するシステムであって、
   ＥＤＩデータをバッチとして送信する送信元であって、前記ＥＤＩデータの前記バッチは、複数のＥＤＩドキュメントを含み、該複数のＥＤＩドキュメントの各々は、１つの取引タイプに対応する少なくとも１つのＥＤＩ取引を有する、送信元と、
   前記ＥＤＩデータを前記バッチとして受信するインターフェースと、
   
   前記受信したＥＤＩデータを、ＥＤＩ標準にしたがって復号化することにより、前記複数のＥＤＩドキュメントに含まれる前記ＥＤＩ取引を識別し、
   前記ＥＤＩデータの前記バッチ内の前記複数のＥＤＩドキュメントから、前記取引タイプにしたがって編成された、前記識別したＥＤＩ取引のＥＤＩデータを含む１つの統合されたＥＤＩドキュメントを定義する
   ためのコンピュータ実行可能命令を実行するプロセッサと
   を備えたことを特徴とするシステム。
9. 前記統合化されたＥＤＩドキュメントは、拡張可能マークアップ言語（ＸＭＬ）ドキュメントである
   ことを特徴とする請求項８に記載のシステム。
10. 前記プロセッサは、前記統合化されたＥＤＩドキュメントに含まれる前記ＥＤＩ取引を、ＸＭＬタグによって構造化するようにさらに構成されており、
    前記ＸＭＬタグは、前記ＥＤＩ取引の前記取引タイプを示している
    ことを特徴とする請求項９に記載のシステム。
11. 前記統合化されたＥＤＩドキュメントは、超スキーマを含んでおり、
    該超スキーマは、前記ＥＤＩ取引が参照する複数のスキーマを表す
    ことを特徴とする請求項８に記載のシステム。
12. 前記インターフェースは、前記複数のスキーマを前記プロセッサにより処理するように変換するためのランタイムスキーママップをさらに受信する
    ことを特徴とする請求項１１に記載のシステム。
13. 前記プロセッサは、前記ランタイムスキーママップを適用して、前記複数のスキーマをランタイムに照合するように構成されている
    ことを特徴とする請求項１２に記載のシステム。
14. 前記プロセッサは、前記統合化されたＥＤＩドキュメント内のＥＤＩ取引を、該ＥＤＩ取引に含まれる１つまたは複数の情報にしたがってサブドキュメントとして編成するようにさらに構成されており、
    前記サブドキュメント内の前記ＥＤＩ取引は、前記複数のＥＤＩドキュメント内の前記ＥＤＩ取引と相互に関連する
    ことを特徴とする請求項８に記載のシステム。
15. 電子データ交換（ＥＤＩ）取引を変換するためのコンピュータ実行可能なコンポーネントを有する１つまたは複数のコンピュータ読み取り可能な媒体であって、
    前記コンピュータ実行可能なコンポーネントは、
    送信元からのＥＤＩデータをバッチとして受信し、該受信したＥＤＩデータを受信側に送信するためのインターフェースコンポーネントであって、前記ＥＤＩデータの前記バッチは、複数のＥＤＩドキュメントを含み、該複数のＥＤＩドキュメントの各々は、１つの取引タイプに対応する少なくとも１つのＥＤＩ取引を有する、インターフェースコンポーネントと、
    前記受信したＥＤＩデータを、ＥＤＩ標準にしたがって復号化することにより、前記複数のＥＤＩドキュメントに含まれる前記ＥＤＩ取引を識別するための識別コンポーネントと、
    前記ＥＤＩデータの前記バッチ内の前記複数のＥＤＩドキュメントから、１つの統合化されたＥＤＩドキュメントを定義するための変換コンポーネントであって、前記統合化されたＥＤＩドキュメントは、前記取引タイプにしたがって編成された、前記識別したＥＤＩ取引を含む、変換コンポーネントと
    を備えたことを特徴とするコンピュータ読み取り可能な媒体。
16. 前記統合化されたＥＤＩドキュメントは、拡張可能マークアップ言語（ＸＭＬ）ドキュメントである
    ことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。
17. 前記統合化されたＥＤＩドキュメントに含まれる前記ＥＤＩ取引を、ＸＭＬタグによって構造化するためのドキュメントコンポーネント
    をさらに備え、
    前記ＸＭＬタグは、前記ＥＤＩ取引の前記取引タイプを示している
    ことを特徴とする請求項１６に記載のコンピュータ読み取り可能な媒体。
18. 前記ドキュメントコンポーネントは、前記統合化されたＥＤＩドキュメント内のＥＤＩ取引を、該ＥＤＩ取引に含まれる１つまたは複数の情報にしたがってサブドキュメントとしてさらに編成し、
    前記サブドキュメント内の前記ＥＤＩ取引は、前記複数のＥＤＩドキュメント内の前記ＥＤＩ取引と相互に関連する
    ことを特徴とする請求項１７に記載のコンピュータ読み取り可能な媒体。
19. 前記統合化されたＥＤＩドキュメントは、超スキーマを含んでおり、
    該超スキーマは、前記ＥＤＩ取引が参照する複数のスキーマを表す
    ことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。
20. 前記インターフェースコンポーネントは、前記複数のスキーマをランタイムにプロセッサにより処理するように変換するためのランタイムスキーママップをさらに受信する
    ことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。

Images