JP2001508905A

JP2001508905A - インテリジェントメッセージ通信

Info

Publication number: JP2001508905A
Application number: JP50430999A
Authority: JP
Inventors: バーランダー、クリスター; スコグ、アンデルス; ニルソン、ミカエル
Original assignee: ビューロシティー・エービー
Priority date: 1997-06-25
Filing date: 1998-06-18
Publication date: 2001-07-03
Also published as: WO1998059480A1; EP0992143A1; IL133664A0; HK1027460A1; AU727293B2; EP0992143B1; DE69802932D1; AU7949698A

Abstract

(57)【要約】本発明は、電子データ交換メッセージ通信のための、つまり事前に定義され、好ましくは標準化されている構造または形式で提供されているデータを含み、前記データが、受信システムまたはアプリケーションによるそれ以降の処理機能においてデータ要素値または文字列として識別、使用できるように、それを転送する電子メッセージの交換のためのシステムおよび方法に関する。本発明に従って、コンピュータシステムで実行され、電子データ交換を含むプロセスは対応するデータ定義に関係して定義され、無事に交換されるか、あるいは前記プロセスの各実行で処理される電子データのデータ要素の集合を含み、そこでは前記プロセスは、受信電子データ交換メッセージ内に含まれているデータを、前記プロセスの実行中にデータ定義のデータ例の事前定義されているデータ要素に自動的に書き込み、前記プロセスの実行中にデータ定義のデータ例の事前定義されているデータ要素から送信する電子データ交換メッセージのためのデータを読み取るように装置されている。

Description

【発明の詳細な説明】インテリジェントメッセージ通信発明の分野本発明は、電子データ交換メッセージ通信のための、すなわち事前に定義され、好ましくは標準化されている構造または形式で提供されているデータを含み、それを前記データが、受信システムまたはアプリケーションによるそれ以降の処理機能においてデータ要素値または文字列として識別、使用できるように転送する、電子メッセージの交換のためのシステムおよび方法に関する。技術的な背景および従来の技術長い間コンピュータ化が進められてきたにも関わらず、今日、企業間での大量の情報の転送は、依然として用紙文書の使用により行われている。本質的には、すべての情報は、当初、コンピュータシステム内にあるが、それが取引先等に転送されなければならないとき、それは紙に書かれ、ファクシミリ、手紙または配送サービスにより受取人に送られる。後者は、受信された情報を、自社のコンピュータシステムに手作業で入力する。この手順は、分散チェーン内の多くのリンクを通じて繰り返され、基本的には同じ情報が、各ステップで手作業で入力される。電子データ交換を使用することにより、異なる企業間の情報の流れは自動化される。その場合、注文、保管、請求処理、生産、運送およびそれ以外の機能用の企業のコンピュータシステムまたはアプリケーションは、自動的に情報を交換することができる。これには、通信網を介して、相手方に送られる標準化または構造化されている電子メッセージが必要とされ、相手方は、その後、自分の内部コンピュータシステムでさらに自動的に情報を処理することができる。電子データ交換（ＥＤＩ）の正確な定義は存在していない。しかしながら、電子データ交換通信には以下の条件が満たされる必要があると言われる場合がある。ａ）コンピュータシステム間の通信は、通信網を介して、すなわち書かれている紙、ディスケット、または磁気テープを介してではなく、直接的、内部的、または外部的でなければならない；ｂ）情報は、構造化されなければならない；ｃ）情報は、望ましくはＥＤＩＦＡＣＴまたはＸ．１２などの通信規格、あるいは通信関係者により合意されている類似する定義済み構造を利用しなければならない；および、ｄ）情報は、それがコンピュータであろうと、アプリケーションであろうと、すなわち本質的には、受信人において情報を入力するための手作業による動作の必要無しに、受信人において直接的にコンピュータにより処理可能でなければならない。このような電子データ交換規格の２つの例がＸ．１２およびＥＤＩＦＡＣＴ（管理、商業および運送用電子データ交換）(ｔｈｅＥｌｅｃｔｒｏｎｉｃＤａｔａＩｎｔｅｒｃｈａｎｇｅＦｏｒＡｄｍｉｎｉｓｔｒａｔｉｏｎ，ＣｏｍｍｅｒｃｅａｎｄＴｒａｎｓｐｏｒｔ)である。ＥＤＩＦＡＣＴは、ヨーロッパでは十分に確立されており、電子データ交換システム、ＥＤＩＦＡＣＴは、例えばＥＤＩＦＡＣＴシステム内で使用されている構文およびメッセージ意味／文用の規則群を提供する。Ｘ．１２は、米国で使用されている類似した標準化システムである。ただし、ＥＤＩの使用は、メッセージ通信を含むプロセスの自動化における本質的な飛躍であるが、依然として、ＥＤＩメッセージ通信に、さらに高速、かつさらに簡易な管理を提供するためには、システムおよび／またはシステムプロセスがどのように設計、実現されるものとするのかに関する新しい技法に対するニーズがある。発明の概要本発明の目的は、電子データ交換システムおよびプロセスの設訃、構造、実現、管理、保守および使用の速度および簡略さを高めることである。本発明のさまざまな態様に従って、前述された目的およびその他の目的は、電子データ交換メッセージ通信、電子データ交換メッセージ通信システム、電子データ交換メッセージ通信プロセスを設計するためのシステム、および添付クレームに定められているような製品のための方法によって達成される。したがって、本発明に従ったコンピュータソフトウェアアプリケーションは、好ましくは以下を備える。すなわち、アプリケーションによって成功裏に格納され、リコールされなければならない情報を定義するデータ定義であって、入信／発信メッセージに関するデータマッピング用に使用されている前記データ定義と、メッセージの予測シーケンス、一定の条件の検出のためにメッセージデータに適用されるイベント規則、一定のイベントまたは更新の期日を監督するタイマ、およびタイマ満了またはその他の条件により発行されるイベントを記述するプロセスと、メッセージデータからアプリケーションデータ（ＩＭＡデータ）へのデータマッピングと、およびイベント発行時のアプリケーションデータ（ＩＭＡデータ）からイベントデータへのデータマッピングとを備える。このコンテキストにおいて、および本発明によれば、電子データ交換、電子データ交換メッセージ等の用語は、データが、受信システムまたはアプリケーションによるさらなる処理機能におけるデータ要素値または文字列として識別、使用できるように、事前に定義され、好ましくは標準化されている構造または形式で提供されているデータを含み、それを転送する電子メッセージを指す。プロセス実行という用語は、本発明のコンテキストでは、その最初の開始から最後まで通してプロセスの実行を指す。すなわち、イベントがプロセスに実行を再開させた後、またはイベントが、実行中、プロセスに一時停止させる前のプロヤスによってなされる実行のステップは、プロセス実行とは見なされず、単にその一部としてだけ見なされる。その結果、例えば、標準的な電子メールテキスト本体は、受信システムまたはアプリケーションが、そこから前記データを引き出すまたは抽出することができるように事前定義されている構造で配列されているデータを本体が含まない限り、本発明に従った電子データ交換メッセージを構成しない。しかしながら、これは、このような未構造化テキスト本体の送信／受信が、本発明に従ったプロセスに、真の電子データ交換メッセージの送受に対する付加物として含ることができないことを意味しているわけではないことに注意する。本発明に従ったコンピュータアブリケーションは、特定のプロセスに関連しているデータ定義のデータ例と密接に対話して作業している電子データ交換プロセスを提供する。プロセスのデータ定義は事前に定義され、おもに、プロセスの下流ステップで必要とされているこのようなデータを主として含むように設定されている。一般的には、全体としてのプロセスは、電子データ交換メッセージに関して、またはプロセス自体で派生する、および／または使用されている処理データだけではなく、ＳＱＬ（標準照会言語）データベースなどのリレーショナルデータベースまたはその他のフォーマットに関して、大量の入信データまたは発信データを取り扱うことができる。これらのデータのいくらかは、多くの場合、プロセスの下流ステップで使用するために必要とされている。これは前記下流ステップで使用するために必要とされるときにデータを検索する際にさらに多くのアクセス時間を必要とするため、本発明に従って、このようなデータを少なくとも非独占的に、ＳＱＬデータベースに格納しないことが好ましい。ＳＱＬリレーショナルデータベースを使用すると、所望の情報の検索に関する問い合わせステップの一連の要求の実行が必要となる。代りに、本発明の好適実施例によれば、このようなデータは、プロセス実行のために容易かつ高速な検索を可能にするように、好ましくは事前定義されているインデックスを使用して、好ましくはシーケンシャルファイルシステムに格納されているプロセスデータ定義の、プロセスに固有の、シーケンシャルに収集されたデータ例に格納されるのが好ましい。したがって、プロセス全体の便宜的な実行に必要とされているデータを提供されるデータ要素群を含むデータ定義は、事前に、プロセスの定義に関して定義される。好ましくは、データ定義の新規データ例が、プロセスの実行のたびに作成される。また、データ例で順次に提供されている情報のすべてまたは一部は、例えば、プロセスの最後にリレーショナルデータベース内に格納され、それによってリアルタイムプロセスデータベース対話に対するニーズを削減する。前記データ例を格納するためのタイムシーケンシャルファイルシステムを使用した結果、データのデータベースへのマッピング、およびデータベースからのマッピングの必要性は無く、特定のブロセスの場合にデータを見つけるためにＳＱＬ検索を行う必要もない。前述されたように、従来の技術においては、例えば運送注文メッセージで受信されるデータは、データベース内の１つまたは複数のテーブルの中に連続して格納され、各テーブルは、すべての受信運送注文に対応する行のリストを含む。後で受信される配達確認に提供されているデータは、データベース内の１つまたは複数のテーブルに関する１つまたは複数の行に連続して格納され、各テーブルは、すべての受信配達確認に対応する行のリストを含む。この従来の技術によれば、前記テーブルのどれも、全体的な処理済みのケースに関する情報を提供せず、単に全体的なプロセスケースの一部に関する情報を提供する。また、格納のためにリレーショナルデータベースを使用することは、プロセスとデータベースとを仲介する要求プログラムおよびデータマッピングプログラムを必要とする。これらの機能は、データベースプロセス対話の効率を低減させる結果となる。好ましくはシーケンシャルファイルシステムに格納されているデータ例には、プロセスが進むにつれて電子データ交換メッセージ通信データが連続して提供されるため、データ例は、時間の流れという観点でプロセス全体を表すと言われることがある。本発明は、特定のプロセスケースにおいて一連の事前に定義された活動に関係するデータをどのように格納し、検索するかという問題を解決する。本発明の他の観点によれば、上述した種類の電子データ交換プロセスは、ここに開示されている種類の限定された機能ブロック群を使用して構築される。好ましい観点によれば、前記機能ブロックは、記号という形でコンピュータモニタ上で視覚化可能であり、各記号はそれぞれの機能ブロックに関連している。電子データ交換プロセスの構築、管理、再構築、または使用というタスクを実行するとき、このようなシステムのユーザは、ユーザインタフェースを介して画面上で所望の記号を関連付け、それによってコンピュータシステムに同様に対応する機能ブロックを関連付けるように指示し、その結果、アセンブルされているプロセスを形成することができる。プロセス全体またはその一部を形成している２つ以上の機能ブロックは、元の機能ブロックよりはるかに複雑である複合機能ブロックにグループ化することができるのが好ましい。ユーザは、各記号がそれぞれの機能ブロックに関連付けられている少なくとも２つの既存の記号を、好ましくはシステムの既存の記号定義リソースとともに格納される新規記号定義にグループ化することによってユーザインタフェースを介してこれを達成する。また、ユーザは、１つ以上のデータ要素群を含む１つ以上のデータ定義を、新規記号定義に追加するという可能性も持つ。このようにして、複雑な問題に対する解決策、およびその設計は、電子データ交換メッセージ通信プロセスを設計することに関連して、将来の分散および修正用の保管庫に格納することができる。図面を参照して後述されるような機能ブロック群を使用することにより、非常に容易に理解可能かつ容易に実現可能であるプロセスモデルを提供することが判明した。本発明は、プロセスをどのように実現するか、およびプロセスをどのようにしてさらに効率的に変更可能かに関するより良い理解を提供する。したがって、本発明の１つの利点は、プロセス設計を技術的な実装に簡単に変換可能にすることであり、一方、従来技術ではこの変換が非常に困難である。本発明の他の利点は、プロセス設計、技術的な実装、システムの保守および処理だに関して時間および費用を節約することである。本発明は、またプロセス設計活動およびプロセス実装活動を接続することをさらに容易にする。本発明の他の観点によれば、以下を含む同期機能が提供されている。すなわち、予想される数のイベントを定義すること、発生したイベントの数を計数すること、および以下のａ）前記発生したイベントの数が、前記イベントの予想されている数に等しいこと、およびｂ）同期タイマが満了していることという２つの条件の内のｌつが達成されるとすぐに、前記機能を終了することである。同期機能は、好ましくは、以下の機能ブロックの１つまたは複数を含む。すなわち、どちらが先に来ようと、待ち状態にあるプロセスを停止する機能を実行する待ブロック、所定数の予測されるイベントの発生、またはタイマの満了、電子データ交換メッセージの送信および続く同期ブロックで使用されているタイマの設定の機能を実行するメッセージ送信ブロックであって、前記メッセージは、前記データ定義のデータ例の少なくとも１つのデータ要素に記憶されている情報を含むメッセージ送信ブロックとから構成される。その他の好ましい機能ブロックは、以下を含む。すなわち、電子データ交換メッセージの受信を待機し、前記データ定義のデータ例の少なくとも１つの指定されているデータ要素に、前記メッセージに含まれているデータを格納する機能を実行する開始ブロック、およびプロセスの実行のためにデータ定義のデータ例を割り当てる機能を実行する開始ブロックである。この種の機能ブロックは、電子データ交換プロセスを設計、構築する際に好ましい代替策を提供する。また、この同期機能を実行する前述した種類の機能ブロックは、さらに図面を参照して説明するように、アプリケーション設計を簡略化し、電子データ交換プロセスの同期を達成することを可能にする。したがって、本発明は、電子データ交換メッセージ活動を同期するための有利な手段も提供する。コンピュータプログラミングの当業者によって理解されるように、ここに開示されているプロセス、システムおよび機能は、本発明の特徴よって提供される知識およびここに開示されている実施形態を例示することによりコンピュータソフトウェアアプリケーションとして容易に実施、実現され、それによりさらにその詳細な説明を除外する。この発明のさらなる観点、目的、利点および特徴は以下の例示実施例の説明および添付クレームから明らかになるだろう。図面の簡単な説明本発明の例示実施形態は、以下の添付図面を参照して説明される。図１は、本発明に従ってインテリジェントメッセージ通信アプリケーション（ＩＭＡ）の表象を示す。図２は、本発明によるインテリジェントメッセージ通信データの表象を示す。図３は、電子データ交換プロセスを実現することに関して、データ定義およびそのデータ例の一例を示す。図４ａ乃至図４ｈは、本発明に従った電子データ交換プロセスで使用される異なる機能ブロックを示す。図５ａ、図５ｂおよび図５ｃは、複数の応答のプロセス管理の３つの異なる例を示す。図６ａおよび図６ｂは、並列電子データ交換プロセスの同期および管理を提供する２つの異なった方法を示す。図７ａおよび図７ｂは、本発明による２つの電子データ交換実現プロセス例を示す。図８は、ＳＤＬ記号および言語を使用する図７ａのプロセスを示す。図９ａ乃至図９ｅは、本発明による電子データ交換の別の例を示す。図１０ａおよび図１０ｂは、インテリジェントメッセージ通信アプリケーションＩＭＡプロセスにより受信されるメッセージの例示を示す。図１１は、シーケンシャルファイルシステムのシーケンシャルタイムテーブルに格納されている２つのＩＭＡデータ例実現の形で表されている、図１０ａおよび図１０ｂのメッセージで受信されるＥＤＩメッセージデータを示す。図１２は、ＳＱＬデータベースのＳＱＬテーブルに格納されている図１０ａおよび１０ｂのメッセージで受信されているＥＤＩメッセージデータを示す。図１３は、本発明の実施形態によるコンピュータシステムを示す。図１４は、電子データ交換メッセージ通信プロセスを設計するためのシステムの実施形態を示す。好ましい実施形態の詳細な説明図１は、インテリジェントメッセージ通信アプリケーション、ＩＭＡの表象を表している。アプリケーションは、プロセスに続くＩＭＡプロセスデータ例に関連付けられている、電子データ交換を含む、潜在的なメッセージ通信プロセスとして見ることができる。インテリジェントメッセージ通信アプリケーションとは、ＥＤＩメッセージ活動（アプリケーションへの／アプリケーションからの、および人への／人からのメッセージ）を１つの管理可能なプロセスに同期するのに役立つ特別な種類のアプリケーションである。インテリジェントメッセージ通信アプリケーションでの活動の大部分は、単独のケースでの処理には手動対話が含まれることがあるが、自動化された情報処理である。したがつて、本発明によれば、電子データ交換プロセスを含むインテリジェントメッセージ通信アプリケーションは、異なるコンビュータシステム間またはアプリケーション間の１つ以上の電子データ交換メッセージダイアログを含む。図２は、本発明によるインテリジェントメッセージ通信アプリケーションデータ例（ＩＭＡデータ例）の表象を示す。データ例とは、ビジネスプロセス、運送プロセスまたは技術プロセスなどの、プロセス内の特殊なケースに関係しているデータの集合体のことである。例えば、データ例は、請求の制御および証明、生産工場または機械の作業の流れの制御等に関係し、それらにとって必須であり、このような制御は電子データ交換を含む。請求制御および証明のケースでは、データ例は、請求データ、請求に関係している注文データ、支払い権限データ、署名データ、および請求を証明する人によって作られるメモを含むことができる。本発明によれば、後述されるように、データ例は、フロー、っまりインテリジェントメッセージ通信アプリケーションでのプロセスに従う。アプリケーションは、好ましくは、同時に複数のデータ例を取り扱うことができるように設計される。ＩＭＡデータ例は、電子データ交換メッセージ、あるいはタイマの満了、クロック信号の受信、またはモニタされている状態の変更などの別の種類のイベントが電子データ交換プロセスを開始するたびに、好ましくは、潜在的なデータ定義に基づいて作成される。いくつかの種類のプロセスでは、プロセス作業フローは、プロセス内で取られる決定に応じて動的に変化する。したがって、データ例のデータは、ＩＭＡデータ例ごとに相応じて変化する。プロセス実行中、アプリケーションは、データ例への／データ例からの情報を追加、変更および削除することができる。好ましくは、あらゆるデータ例には一意の参照番号が指定される。本発明によるインテリジェントメッセージ通信の利点は、作業フローの一定のパターンに従ってデータを管理する能力である。図３は、プロセスの電子データ交換メッセージで受信または送信されるデータ、データマッピング、プロセスのためのデータ定義、および本発明に従ったデータ定義のデータ例との間の関係例を示す。図３では、ＩＭＡプロセスデータ定義１０５は、事前に定義されている電子データ交換プロセス(図示されていない)、このケースでは、購入トランザクシヨンプロセスに関係する。プロセスの１つのステップでは、アプリケーションは、電子データ交換メッセージという形で買い手から買い注文を受信する。このメッセージは、買い注文メッセージデータ定義１００に従った事前に定義されている構造での買い注文データを含む。したがって、購入データは、構造化され、所定の態様で購入メッセージに提供され、このようにしてアプリケーションがメッセージから購入データを得ることを可能にする。図３に示されている例では、買い注文メッセージデータ定義１００は、事前に定義されている構造に従って、買い注文参照(ＰＯＲＥＦ)、買い注文日付(ＰＯ日付)、指定されている買い手（買い手）(このケースではメッセージの送信者)、指定されている売り手（売り手）(このケースではメッセージの受取人)、注文された品物(品物)、およびその量（量）を含む。プロセスを構築するとき、買い注文データ定義のＰＯ参照、買い手、売り手、品物および量データだけが、ＩＭＡプロセスデータ定義１０５のデータ例１０５ａ、１０５ｂ、１０５ｃであって、プロセスのそれぞれの実行に対応する各データ例１０５ａ、１０５ｂ、１０５ｃに格納される必要があると判断された。したがって、これら５つのエンティティは、図３で線を繋いでいるボックスによって示されるように、ＩＭＡプロセスデータ定義１０５のデータ例の中にマッピングされなければならない。プロセスの後のステップでは、売り手が配達田こ注文されている量を配達できない場合には、アプリケーションは、やはり電子データ交換メッセージの形を取る買い手に未完全配達メッセージを送信する。したがって、未完全配達データは、また、事前定義されている未完全配達メッセージデータ定義１０１に基づく未完全配達メッセージで、構造化され、事前に定義されている方法で提供される。図３に示されている例では、未完全配達メッセージデータ定義は、買い注文参照 (ＰＯＲＥＦ)、朱完全であった注文されている品物(品物)、および計算されてた差分を含む。未完全配達メッセージデータ定義のこれらの３つのエンティティが、ＩＭＡデータ例から未完全配達メッセージに取り込まれる前に、図４ｃに関して後述される自動化されている機能ブロックが、どのくらいの数の品物を実際に配達できるのかを決定してから、ＩＭＡデータ例をこのようなデータ、すなわち品物の契約されている数(契約済み)、契約されている配達日(配達)、および合意されている価格（価格）で更新する。更新されたＩＭＡデータ例に基づき、未完全配達メッセージに含まれるデータは、このケースでは前記差分を計算するためにプロセスロジックを使用して、ＩＭＡデータ定義１０５のデータ例から得ることができ、ＥＤＩメッセージへマッピングすることができる。全体的なプロセス、および関係するＩＭＡプロセスデータ定義１０５、つまり、例えば前述されているものよりさらに進んだステップを含む全体的なプロセスを構築するとき、図３で示されている例では、ＩＭＡプロセスデータ定義が、ＰＯｒｅｆ、ステータス、買い手、売り手、品物、予想、契約、配達および価格を含むものとすることが決定されていた。したがって、ＩＭＡプロセスデータ定義は、好ましくは、プロセスの後のステップでのアプリケーションによってリコールされる必要のあるこのような情報を定義する。さらに、図３では、プロセスの実行の３つの例が示されている。第１の例（ａ）では、３０００個の１５ｗの電球の注文を指定する買い注文１００ａがアプリケーションによって受け取られた。ＩＭＡプロセスデータ定義１０５のデータ例１０５ａは、単にこの買い注文メッセージを受信したときの状況を示す。したがって、契約されている配達は行われず、ＩＭＡデータインスタンスのステータスは「注文済み」である。（ＩＭＡプロセスは完了していない）。第２の例（ｂ）では、１００００個の４０ｗの電球の注文を指定する買い注文１００ｂがアプリケーションによって受け取られた。ＩＭＡプロセスデータ定義１０５のＩＭＡデータ例１０５ｂは、この注文を受諾したときの状況を示す。このケースでは、プロセスにおいて、配達を指定日に行うことができると決定されたため、注文は、未完全配達メッセージを送信する必要なく受諾された。したがって、＄１．７９という値段での１９９７年１月１３日の１０００個の配達の契約がかわされたこと、およびデータ例のステータスが「受諾済み」である（ＩＭＡプロセスは完了している）ことが分かる。第３の例（ｃ）では、２０００個の２０ｗの電球の注文を指定する、買い注文１００ｃが、アプリケーションによって受け取られた。ＩＭＡプロセスデータ定義１０５のＩＭＡデータ例１０５ｃは、この注文を受諾したときの状況を示す。このケースでは、プロセスにおいて、完全配達をその時点で行うことができないと決定されたため、注文は、未完全配達メッセージ１０１ｃの形での但し書き付きで受諾された。したがって、＄１．７９という値段での１９９７年２月１日の１２００個の配達の契約がかわされ、その結果、８０個の６０ｗの電球という差分を指定する未完全配達メッセージが生じること、およびデータ例のステータスが「受諾済み」である（ＩＭＡプロセスが完了している）ことが分かる。図３の例から理解されるように、プロセスの各実行、つまり各購入トランザクションは、ＩＭＡプロセスデータ定義のそれぞれのデータ例と関連付けられている。また、プロセスが進むにつれて、各ＩＭＡデータ例は、後の処理ステップで好ましくは使用される情報を成功裏に提供され、そこでは、データインスタンスのいくつかのデータ要素でのデータが、そのプロセス中に変化することができる。図４ａから図４ｈは、本発明に従った電子データ交換プロセスで使用される異なった機能オブジェクト、記号またはブロックを示す。図４ａから図４ｈに示されている機能ブロックのセットは、完全な電子データ交換プロセスを形成するために使用されるときに非常に有利であることが判明している。したがって、インテリジェントメッセージ通信アプリケーションおよびプロセスは、好ましくは、後述される機能ブロックを使用して開発、構築される。図４ａから図４ｈの機能ブロックは、包括的な機能性を有しており、特定のプロセスまたはアプリケーションに入れられると特殊化する。図４ａは、自動化活動機能ブロックを示す。自動化活動機能ブロックは、プロセスの現在の実行に関連しているＩＭＡデータ例に関して、少なくとも１つの事前定義されている機能を実行する。事前定義されている機能は、例えば、ＩＭＡデータ例で自動化論理動作を実行すること、例えば何らかの種類のプログラミングコード（Ｃ、Ｃ＋＋，Ｊａｖａ）を使用すること、別のルーチンのアドレス指定、およびＩＭＡデータ例の作成等を含むことができる。図４ｂは、自動化アクティヴィティ、タイマ機能開始ブロックを示す。自動化活動、タイマ機能開始ブロックは、図４ａに関して前述されているように、プロセスの現在の実行に関連しているＩＭＡデータ例に関して、少なくとも１つの事前定義されている機能を実行し、タイマ（図４ｂではタイマｙ１）を開始する。自動化活動、タイマ開始機能は、例えば、自動化活動、タイマ開始機能が最初にプロセスに置かれると、ＩＭＡデータ例を作成し、イベントを宣言し、（以下の図４ｈに関してさらに説明されるだろう）一定の時間枠内で特定のイベントが発生することになっていることを告げるタイマを開始することができる。図４ｃは、自動化決定機能ブロックを示す。自動化決定機能ブロックは、プロセスを通したデータ例のフローを動的に変化する。フローの変化は、事前定義されている規則に基づいており、例えば、フローは、ＩＭＡデータ例に対する自動化論理演算または算術演算の結果に関して変化するだろう。規則は、自動化判断機能ブロックでセットアップされ、好ましくはプロセスの現在の実行に関連しているＩＭＡデータ例のデータを使用する。３つの結果または自動化決定機能ブロックからの発信プロセスパスが図４ｃに示されているが、結果または出力プロセスパスの真の数は任意であり、所望のプロセスに依存して設定することができる。各出力プロセスパスにより、新規イベントが発行されることになる。図４ｄは、受信および待機メッセージ機能ブロックを示す。受信および待機メッセージ機能ブロックは、電子データ交換メッセージを待機し、これが受信されると、プロセスの現在の実行に関連付けられているＩＭＡデータ例に、メッセージで受信されているデータをロードする。受信および待機メッセージ機能ブロックは、多くの場合、好ましくは、本発明に従った電子データ交換プロセスに最初に置かれる。プロセスに最初に置かれると、受信および待機メッセージ機能ブロックは、好ましくは、プロセスの現在の実行に関連付けられているＩＭＡデータインスタンスも作成する。図４ｅは、メッセージ受信、タイマ開始機能ブロックを示す。メッセージ受信、タイマ開始機能は、事前定義されている時間枠（図４ｅではタイマｙ１）に設定されているタイマを開始し、指定されている時間枠内で電子データ交換メッセージを受信することを予想する。したがって、メッセージ受信、タイマ開始機能ブロックは、ＥＤＩメッセージの予想されている受信を宣言し、指定されている時間枠内で、メッセージが受信されることになっていることを告げるタイマを開始する。メッセージが指定されている時間枠内で受信されない場合、以下の図４ｈに関してさらに説明されるように、解除イベントが生成される。ここに開示されているその他のブロックだけではなく、メッセージ受信、タイマ開始機能ブロックも、ＩＭＡデータ例にメッセージからのメッセージデータを転送するために必要とされているマッピング規則を提供する。図４ｆは、メッセージ送信機能ブロックを示す。メッセージ送信機能ブロックは、電子データ交換メッセージを送信し、好ましくは、プロセスの現在の実行に関連しているＩＭＡデータ例の格納されているデータを使用し、送信されるメッセージを作成する。したがって、前述されたように、機能ブロックは、ＩＭＡデータ例からのメッセージデータをメッセージに転送するために必要とされているマッピング規則を提供する。図４ｇは、メッセージ送信と受信、タイマ開始機能ブロックを示す。メッセージ送信と受信、タイマ開始機能ブロックは、一緒にしたメッセージブロック送信（図４ｆ）とメッセージ受信、タイマ開始機能ブック（図４ｅ）とまったく同じ機能を実行する。したがって、メッセージ送信と受信、タイマ開始機能ブックは、電子データ交換メッセージを送信し、事前定義されている時間枠に設定されているタイマ（図４ｇではタイマｙ１）を開始し、指定されている時間枠内で電子データ交換メッセージの形での応答を受信することを予想する。したがって、メッセージ送信と受信、タイマ開始機能ブロックは、ＥＤＩメッセージを送信し、ＥＤＩメッセージ応答の予想されている受信を宣言し、指定されている時間枠内に応答が受信されることになっている旨を告げるタイマを開始する。応答が指定されている時間枠内に受信されない場合には、以下の図４ｈに関してさらに説明されるように、解除イベントが生成される。図４ｄ、図４ｅ、図４ｆおよび図４ｇに関して説明された機能ブロックは、データベースから読み取られる情報を提供するために使用され、電子メールを介して受信され、ユーザインタフェースを介して入力／送信されるか、データ例から／データ例へ、つまり真の意味でＥＤＩメッセージを独占的に使用するのではなくＪａｖａ、Ｃ＋＋、Ｃまたはその他のプログラミング言語を介して入力／送信されてもよいことが理解される。図４ｈは、本発明に従って（ｎ）個のイベント機能待機ブロックを示す。（ｎ）個のイベント待機機能ブロックは、プロセスを停止し、イベントの事前定義されている予想されている数の発生または前述された機能ブロックの１つ以上の事前定義されているタイマセットアップの満了を待機する。発生する可能性のある２種類のイベントがある。自動化活動、タイマ開始機能ブロック（図４ｂ）で初期にセットアップ／宣言されたイベント、あるいはメッセージ受信、タイマ開始機能ブロック（図４ｅ）またはメッセージ送信と受信、タイマ開始機能ブロック（図４ｇ）で初期にセットアップ／宣言された１つ以上のメッセージの受信である。したがって、プロセスは、（ｎ）個のイベント待機機能ブロックに指定されているタイマが満了するか、あるいは（ｎ）個のイベント待機機能ブロックに指定されている予想イベントの数が発生するとすぐに続行する。したがって、この機能ブロックには２つの考えられる結果がある。つまり、すべての予想イベントが、指定タイマによって指定されている時間枠内で発生し、プロセスが、結果的にタイマの満了前に続行する、あるいはイベントの予想数より少ないイベントが、指定タイマによって指定されている時間枠内で発生し、プロセスは、すべての予想イベントが発生したわけではないという事実にも関わらず、タイマが満了するため、プロセスが続行する。後者の結果の１つの特定の可能性とは、指定タイマによって指定されている時間枠内でイベントが発生せず、プロセスが、イベントは発生しなかったという事実にも関わらず、タイマが満了するため、プロセスが続行する。所望のプロセスフローに応じて、タイマー満了ー結果は、この結果がいくつかのケースでは複数の異なる可能性に対応することがあるため、１つの単独フローパスまたは複数のフローパスとして設計することができる。図５ａ、図５ｂ、および図５ｃは、複数の応答のプロセス管理の３つの異なる例を示す。図５ａ、図５ｂおよび図５ｃの両方において、３つのメッセージ送信と受信、タイマ開始機能ブロックが、それぞれメッセージＡ、メッセージＢおよびメッセージＣとして受信される３つの回答を要求するために、およびタイマ「デモ１」を開始するために使用されると仮定する。図５ａにおいては、（ｎ）個のイベント待機機能ブロックは、３つすべてのイベント、つまりタイマ「デモ１」を考慮した３つすべてのメッセージ受信を待機するように設定される。プロセスは、２つの異なるパス、つまりタイマが満了する前に３つすべてのメッセージが受信される場合には、第１パス、３つすべてのメッセージが受信される前にタイマが満了する場合には第２パスに続く。したがって、第２パスは、以下の３つの可能性に対処する。つまり、タイマが２つのメッセージの受信後に満了する、タイマが１つのメッセージの受信後に満了する、あるいはこれらの３つの可能性は１つの単独の結果として説明されていても、タイマがメッセージの受信の前に満了する。図５ｂでは、（ｎ）個のイベント待機機能ブロックは、３つのイベントの内の１つのイベントだけ、つまりタイマ「デモ１」を考慮した１つのメッセージだけの受信を待機するように設定される。したがって、プロセスは、４つの異なるパスに従う。メッセージＡが最初に、タイマの満了前に受信される場合は第１パス、メッセージＢが最初にタイマの満了前に受信される場合は第２パス、メッセージＣが最初にタイマの満了前に受信される場合は第３パス、およびタイマが満了する前にメッセージが受信されない場合には第４パスである。図５ｃでは、（ｎ）個のイベント待機機能ブロックは、３つのイベントの内の２つのイベントだけ、つまりタイマ「デモ１」を考慮した２つのメッセージだけの受信を待機するように設定される。したがって、プロセスは４つの異なるパスに従うだろう。つまり、メッセージＡおよびＢが最初に、タイマの満了の前に受信される場合は第１パス、メッセージＢおよびＣが最初に、タイマの満了前に受信される場合は第２パス、メッセージＣとＡが最初に、タイマの満了前に受信される場合には第３パス、およびタイマの満了前に、メッセージが受信されないか、あるいは１つのメッセージしか受信されない場合には第４パスである。図５ａおよび図５ｂの例により理解されるように、（ｎ）個のイベント待機機能ブロックによって、多くの異なった方法で複数のイベントを管理できるようにし、異なる種類のプロセスパスおよび構成を作成する。図６ａおよび図６ｂは、本発明に従って並列電子データ交換プロセスの同期および管理を提供する２つの異なった方法を示す。図６ａでは、２つの開始メッセージをそれらに送信することにより、第１電子データ交換プロセスＩＭＡｘが、２つの並列電子データ交換プロセスＩＭＡｙおよびＩＭＡｚを開始する。したがって、プロセスＩＭＡｙおよびＩＭＡｚは、好ましくは、図４ｄ、図４ｅまたは図４ｇに示されているもののようなメッセージ受信ブロックを使用して、第１プロセスＩＭＡｚによって開始されるか、第１プロセスＩＭＡｚと同期が取られる。他の例をず６ｂに示す。この例では、メッセージの送信と受信、タイマ開始機能ブロックは、１イベント待機機能ブロックとともに第２プロセスＩＭＡｙで使用され、第２プロセスＩＭＡｙを第１プロセスＩＭＡｘに同期させる。（ｎ）個のイベント待機機能ブロックは、プロセスフローを同期したり制御するときに非常に有益であるので、このブロックは同期ブロックとも呼ばれる。また、図６ａおよび図６ｂから明らかであるように、本発明による電子データ交換プロセスは、２以上のサブプロセスに分割され、２以上のプロセスを一緒にして全体プロセスを形成することもできる。同様に、ＩＭＡデータ例は、２以上のサブデータ例に分割され、２以上のＩＭＡデータ例は、すべて実際のアプリケーションおよび状況に依存して、一緒にして全体ＩＭＡデータ例を形成することもできる。電子データ交換プロセスの例を図７ａを参照して説明する。図７ａでは、「請求制御」プロセスは、第１ブロックでの請求メッセージの受信によって開始され、これにより、請求制御プロセスの現在の実行のためのＩＭＡデータ例が作成され、ＩＭＡデータ例は、例えば、関連請求データを備えている。その次の２つのブロックにおいては、現在の請求メッセージに関係する注文メッセージが、タイマ「注文待機」により設定されている時間枠内で受信される注文アプリケーションから要求される。指定されている時間内に注文が受けられない場合、人物１は次のブロックで知らされ、注文待機ステップが繰り返される。注文が受けられる場合は、プロセスは自動化決定ブロックまで続行し、プロセス規則に基づいて、請求の内容が注文に一致しているかどうかを判断する。一致している場合には、「証明」プロセスが証明開始メッセージを送ることにより開始される。ただし、注文の内容が請求に一致しない場合「非受諾請求」メッセージが供給者に送付され、人物２は電子メール経由で知らされる。両方のケースとも、作成されたデータ例は、プロセスが終了される前に格納される。図７ａに示されているブロックの大部分では、プロセスは、第１ブロックおよび最後のブロックでのようにＩＭＡデータ例の中にデータを書き込むことによって、または請求内容が注文内容に等しいかどうかを決定するブロックでのようにＩＭＡデータ例からデータを読み取ることによって、ＩＭＡデータ例を利用する。図７ａのプロセスを図８を参照して説明する。電子データ交換プロセスの他の例を図７ｂを参照して説明する。図７ｂでは、「証明」プロセスが、図７ａに示されている証明開始メッセージを受信することによって開始される。このケースでは、新規ＩＭＡデータ例が、好ましくは証明開始メッセージに提供されている請求情報を使用して、図７ｂの第１ブロックで作成される。証明開始メッセージを受信した後、図７ｂのプロセスは自動化決定ブロックまで続行し、そこでは請求が＄１０００を超えるまでになるか、それとも未満に達するかどうかが決定される。請求が＄１０００未満を指す場合、すでに実行されている請求制御に依存する一方で、証明は必要とされず、プロセスは支払いメッセージブロックまで直接続行する。ただし、請求が＄１０００を超えるものを指す場合は、プロセスは、人物３に電子メールを送信し、一定の時間枠内で証明を続行するように要求するブロックに移動する。証明メッセージがこの時間枠内に受信されない場合、プロセスは、人物４に電子メールを送信し、証明メッセージを要求する類似ブロックに移動する。証明メッセージが受信されると、プロセスは前述された支払いメッセージブロックまで移動し、そこではメッセージが、請求を支払うために計算システムに送信される。同時に、受諾メッセージが指定されている時間枠内で必要とされ、この受諾メッセージは、受信されるまで監視される。最後に、プロセスの最後で、データ例からの情報が格納される。本出願に開示されている機能ブロックが、コンピュータプログラミングの当業者によって容易に実現でき、このようにして追加の詳しい説明に対するニーズを無視する（ｓｅｔｔｉｎｇａｓｉｄｅ）ことを強調するために、図８は、ＳＤＬ（仕様記述言語）記号および言語を使用して説明されるときの図７ａの請求制御プロセスを示す。ＳＤＬは、ＩＴＵ−Ｔ（旧ＣＣＩＴＴ）によって発行されている国際規格であり、並列アクティヴィティとのシステムの動作を格納、定義するための指示を含む。請求証明プロセスは、すでに図７ａに関して前述されているため、および図８で使用されている記号は当業者に周知であるため、その追加説明は省略されるだろう。しかしながら、図８の初期の３つのステップＳ１１、Ｓ１２、およびＳ３は、本来、図７ａの第１の請求メッセージ受信ブロックに対応していることがよく理解され、図８の続く３つのステップＳ１４、Ｓ１５およびＳ１６が、本来、図７ａの第２の注文メッセージ要求ブロックに対応していること、図８の続く３つのステップＳ１７、Ｓ１８およびＳ１９が、本来、例えば、図７ａの第３の１イベント待機ブロックに対応していることがよく理解される。このようにして、当業者によって、例えばメッセージ通信、同期ブロック、および本発明に従ったタイマ機能を実現する方法が容易に理解され、本発明に従った機能ブロックの使用が、電子データ交換プロセスの説明および構築を簡略化することも明らかである。電子データ交換プロセスの別の例は、ここでは、運送実行プロセスに関する図９ａから図９ｅに関して説明されるだろう。図１９ａは、含まれている主要パートナー（供給者、受取人、および運搬人）および交換されているのがどのＥＤＩメッセージなのか（２０４，２１４，８５６，９９０）の概要を示す。図９ｂからず９ｅに示されている実現されている手順は、供給者で実行されることは明らかである。プロセスは、外部パートナーへの／外部パートナーからのすべての電子データ交換メッセージ通信を取り扱うだろう。機能ブロックは、図７ａおよび７ｂに関するその使用だけではなく、図４ａから図４ｈに関して前記に詳細に説明されているので、および図９ｂから図９ｅのプロセスに、説明文が備えられているので、図面は自明であると解釈され、その追加説明は省略されるだろう。理解されるように、生産プロセス、医療システム等の制御および監視などの多くの異なる種類の技術的に関係しているプロセスは、図９ａから図９ｅの運送実行プロセスに説明されている機能に類似した機能を使用し、本発明に従って構築されてよい。図１０ａ、図１０ｂおよび図１１に関しては、本発明に従った順ファイルシステムが説明されている。図１０ａは、例えば、図７ａに関して前記に説明された請求制御プロセスによって受信されるメッセージである可能性がある２つのＥＤＩメッセージを示すため、それらはそれぞれ請求１および注文１と名前が付けられている。例えば、請求制御プロセスのフローに対するＡと示されているＩＭＡデータの作成を引き起こす、例図７ａの第１ブロックによって受信される請求メッセージには、請求データを含む請求データ要素Ａ１...Ｄ１が含まれる。例えば、図７ａの第２ブロックまたは第４ブロックのどちらかにより受信される注文メッセージには、注文データが含まれる注文データ要素Ｅ１...Ｇ１が含まれる。図１１で分かるように、作成されたＩＭＡデータ例Ａは、１つの単一テーブルだけを使用して格納される。つまり、すべてのデータ要素は、一次順次テーブルに順次に格納される。第１に、請求メッセージからの請求データ要素Ａ１...Ｄ１が格納され、注文メッセージの受信後、これらの要素の後には、注文データ要素Ｅ１...Ｇ１が続く。ＩＭＡプロセスは、同時に複数のＩＭＡデータ例を取り扱うことができるので、それはＩＭＡデータ例Ａが依然としてプロセスフローにより取り扱われている間に、第２注文メッセージが後に続く第２請求メッセージを受信してよい。図１０ｂに示され、それぞれ請求２および注文２と示されているこれらの後者の受信メッセージは、ＩＭＡデータ例Ｂの作成を生じさせる。ＩＭＡデータ例Ｂは、別のテーブルにＩＭＡデータ例Ａと同じ順次にではあるが、ＩＭＡデータ例Ａのテーブルとは分離されているテーブルに格納される。図１１は、ＩＭＡデータ例Ｂの時間順次テーブルも示し、時間軸は、さらに、データ例Ｂの作成がデータ例Ａの作成より後に発生するが、データ要素の格納は、２つのデータ例にとって同時に、部分的に行われることを示す。図１２は、データを編成、格納する別の方法である、ＳＱＬデータベースのテーブルを示す。ＥＤＩメッセージデータをＳＱＬデータテーブルに格納するとき、データは、メッセージ中のフィールドまたはデータ要素の種類に従って、テーブル内で並べ替えられる。メッセージ、請求１からのフィールドＡ１、およびメッセージ、請求２からのフィールドＡ２は、１つのテーブルに格納される。請求１からのフィールドＢ１および請求２からのフィールドＢ２は、正しい請求Ａ１またはＡ２等に対するキー付きの別のテーブルに格納される。その結果、図１１および図１２は、ＥＤＩメッセージデータをどのよにして編成、格納するのかに関する２つの異なる方式を示す。図１１に従って順次メモリファイルを活用するとき、各ＩＭＡデータ例は１つの準じＩＭＡデータ例テーブルだけに格納されるが、ＳＱＬデータベースを図１２に従って活用するときは、各メッセージ中のデータのセット体が複数のＳＱＬテーブルに格納される。これらの方式を比較すると、データが複数のテーブルに分割されるため、ＳＱＬテーブルの活用には、さらに多くのコンピュータリソースが必要になることが容易に理解される。例えば、図７ａからのプロセスが、請求フィールドＢ１と中ＭンフィールドＧ１を比較することを希望していると仮定する。ＩＭＡデータ例テーブルを使用するとき、Ｂ１とＧ１の両方を含む１つの単一テーブルだけの位置が突き止められ、トランザクション機能でロックされる必要があり、後者はテーブル中のデータを矛盾しないようにしておくためである。ＳＱＬテーブルを使用すると、この特定の例は、Ｂ１を含む１つとＧ１を含む１つの２つのテーブルがＳＱＬトランザクション機能によって位置を突き止められ、ロックされることを必要とする。この事情？は、前記例の中のものだけより、処理、格納するはるかに多くのメッセージおよびＩＭＡデータ例があるときになおいっそう明白になる。図１３は、本発明のある実施形態に従ったコンピュータシステムを示す。コンピュータシステムは、以下を含むコンピュータ１を備える。つまり、電子データ交換プロセス３を実行するため(図１３では、１つのプロセスが示されているが、理解されるように、複数の異なるプロセスが処理手段により実行されてよい)、およびプロセス実行中にデータ例のデータ要素からデータを読み取り、その中にデータを書き込むためのＣＰＵという形を取る処理手段２と、異なるプロセスに属する異なるデータ定義のデータ例（図１３では、プロセス３に対応しているデータ例５が示されている）を格納するための順次メモリファイル付きのメモリという形を取る格納手段４と、受信機から／受信機への電子データ交換メッセージ８を受信および送信７するためのインタフェース回路上のポートという形を取る通信手段６と、プロセスの最後でデータ例を格納するためのリレーショナルデータベース９とである。システムは、電子データ交換プロセスと対話するためにスタッフによって活用されている端末またはコンピュータ１０も備える。図１３では、電子データ交換メッセージ８または別の種類のイベントが、最初に、データ定義に対応するプロセス３を開始すると、根元的なデータ定義に基づくデータ例５が作成され、順次メモリファイル４に格納される。ポート６によって受信されている電子データ交換メッセージに含まれているデータは、プロセス３によって前記プロセス３に対応するデータ例５のデータ要素の中に書き込まれ、ポート６から送信される電子データ交換メッセージ中に含まれるデータは対応するデータ例５のデータ要素からプロセス３により読み取られる。プロセス３の実行中、情報は、順次メモリファイル４のデータ例５に／から、追加、変更、および削除することができ、データ例中のプロセス情報の最後で、リレーショナルデータベース９に格納されてよい。端末またはその他のコンピュータ１０の助けを借りて、スタッフは電子データ交換プロセス３と対話することができる。スタッフ一員は、例えば、プロセス３にコマンドまたはデータを与えてよいか、スタッフは、例えば、プロセス３から端末またはコンピュータ１０に送られる電子メールの形で情報を受信してよい。図１４は、電子データ交換メッセージ通信プロセスを設計するためのシステムの実施形態を示す。図１３に関してすでに説明されている要素は、同じ番号で示されており、その追加説明は、説明を容易にするために省略されている。したがって、図１３に関して説明されたことに加えて、図１４のシステムは、さらに、以下を備える。つまり、電子データ交換プロセスブロックを表す記号１１を表示するためのコンピュータ画面という形の表示手段１０と、前記画面１０上で所望のシーケンス１３で互いに対して前記記号を関連付けることにより、ユーザが記号のシーケンスを設計するための、キーボードおよびマウスという形を取るインタフェース手段１２と、記号の前記シーケンス１３を解釈し、それに基づき、前記関連付けられている記号により表されている電子データ交換プロセスブロックに基づく電子データ交換プロセス３を定義するための、実行可能ソフトウェアモジュールとして実現されているインタプリタという形を取る解釈およびデータ定義定義手段１４とである。画面１０上に表示されている記号は、図４ａから図４ｈに関して前述されたように、自動化アクティヴィティ機能ブロック、自動化活動、タイマ開始機能ブロック、自動化決定機能ブロック、メッセージ受信と待機機能ブロックメッセージ受信、タイマ開始機能ブロック、メッセージ送信機能ブロック、メッセージ送信と受信、タイマ開始機能ブロック、（ｎ）個のイベント待機機能ブロック、および異なる複雑な複合機能ブロック等の、電子データ交換プロセスが含むことができるすべてのそれぞれの機能ブロックを表し、それらに関連付けられている。キーボードおよび／またはマウス１２の助けを借りて、ユーザは、一定の所望の動作のプロセスを設計するために必要とされるそれらの機能ブロックを表す記号を選択する。キーボードおよび／またはマウス１２を介して、ユーザは、設計されたプロセスに関係していなければならない１つまたは複数のデータ定義を定義することもできる。選択されている記号は、プロセスの一部または完全なプロセスを構成している一定の所望のシーケンス１３で互いに関連付けられている。各記号は特定の機能ブロックと関連しているため、記号のシーケンスは、おそらく定義されているデータ定義とともに、記号のシーケンスに従って機能ブロックおよびその相対的な位置に基づいた電子データ交換プロセスを定義するためにインタプリタ１４により解釈される。インタプリタ１４は、電子データ交換プロセスに関連付けられる所望の種類のデータに関して、ユーザがキーボードおよび／またはマウスを使って入力することができる内容に基づいたデータ定義を定義する。電子データ交換プロセスは、作成直後に、またはコンピュータシステム１に転送された後のどちらかである。コンピュータ読取り可能ディスクという形を取る製品１５は、システムまたはコンピュータが、記号を表示することができる、記号のシーケンスを設計することができる、記号のシーケンスを解釈することができる、電子データ交換プロセスを記号のセットから定義することができる、および電子データ交換プロセスを実行することができるようにするために必要とされている任意のソフトウェア手段を格納してよい。ディスク上に格納されているこれらの手段のすべては、ディスクに格納されているソフトウェアをロードすることによりシステムまたはコンピュータによって利用できるようになる。本発明は、その特定の実施形態に関して、および特定の状況に関して説明されてきたが、多くの修正および改変が、以下のクレームによって定められるように発明の範囲内で加えられてよいことは明らかである。

【手続補正書】特許法第１８４条の８第１項【提出日】平成１１年７月３日（１９９９．７．３）【補正内容】請求の範囲１．電子データ交換プロセスが、前記プロセスの実行で無事に転送または処理されるべき電子データに関して実行される電子データ交換メッセージのための方法において、電子データが、事前定義されているデータ定義のプロセスに特殊なデータ例に格納され、前記データ定義が、プロセスによって無事に格納、リコールされる電子データのデータ要素のセットを定義し、前記プロセスが、自動的に、受信電子データ交換メッセージに含まれるデータを、前記プロセスの実行中にデータ定義の前記データ例の事前定義されているデータ要素に書き込み、前記プロセスの実行中にデータ定義の前記データ例の事前定義されているデータ要素から電子データ交換メッセージ用データを読み取り、前記電子データ交換プロセスが、事前定義されている機能ブロックのセットを含み、前記ブロックが、予想されているイベントの事前定義されている数の発生またはタイマの満了のどちらか先に来る方を待つ機能を実行する待機ブロックを含むことを特徴とする方法。２．プロセスの各実行が、前記データ定義のそれぞれのデータ例に関連付けられている、請求項１に記載の方法。３．前記プロセス中に順次メモリファイルに準じに前記データ例の前記データ要素を格納することを含む、請求項１または２に記載の方法。４．前記プロセスの最後で前記データ例に含まれているデータのサブセットを格納することを含む、請求項１、２、または３に記載の方法。５．前記イベントが、電子データ交換メッセージの受信を含む、請求項１、２、３または４に記載の方法。６．プロセスの書く実行が電子データを転送または処理する処理手段と、電子データ交換メッセージを受信、送信するための手段と、を備える電子データ交換メッセージ通信システムおいて、前記システムが、プロセスによって無事に格納、リコールされる電子データのデータ要素の事前定義されているセットを含む事前定義されているデータ定義のプロセスに特殊なデータ例を格納するための格納手段と、自動的に、受信電子データ交換メッセージに含まれているデータを、プロセスの実行中にデータ例のそれぞれのデータ要素に書き込み、プロセスの実行中にデータ例のそれぞれのデータ要素から、送信する電子データ交換メッセージ用のデータを読み取るための手段と、を含み、前記処理手段がタイマを含み、事前定義されている機能ブロックのセットを実行することにより前記プロセスを実行するように装置され、前記ブロックが、予想されているイベントの事前定義されている数の発生または前記タイマの満了のどちらか先に来る方を待機する機能を実行する待機ブロックを含むことを特徴とする、システム。７．プロセスの各実行が、前記データ定義のそれぞれのデータ例と関連している、請求項６に記載のシステム。８．前記プロセス中前記データ例の前記データ要素を順次に格納するための順次メモリファイルを備える、請求項６または７に記載のシステム。９．前記プロセスの最後で前記データ例に含まれているデータのサブセットを格納するための手段を備える、請求項６、７、または８に記載のシステム。１０．前記処理手段が、事前定義されている電子データ交換メッセージを受信するときに、前記プロセスの実行を開始するように装置されている、請求項６から９のいずれか１つに記載のシステム。１１．前記処理手段が、タイマの満了時、または前記処理手段により監視されている状態の変化時に前記プロセスの実行を開始するように装置されている、請求項６から９のいずれかに記載のシステム。１２．前記イベントが、電子データ交換メッセージの受信を含む、請求項６から１１のいずれか１つに記載のシステム。１３．電子データ交換プロセスブロックを表す記号を表示するための表示手段と、ユーザが、前記ディスプレイ上で所望のシーケンスで前記記号を互いに関連付けることによって記号のシーケンスを設計するためのインタフェース手段と、前記記号のシーケンスを解釈し、それに基づき、前記関連付けられている記号により表される電子データ交換プロセスブロックに基づいた電子データ交換プロヤスを定義するための解釈手段と、設計された電子データ交換プロセスに関してデータ定義を定義するためのデータ定義手段であって、前記データ定義が、前記プロセスの各実行で交換されるデータ要素のセットを含み、前記プロセスの事前定義されている入出力電子データ交換メッセージデータに基づき、前記データ定義を自動的に定義するように配置されているデータ定義手段と、を備える、電子データ交換メッセージ通信プロセスを設計するためのシステム。１４．前記インタフェース手段が、前記ユーザが前記データ定義を定義できるように装置されている、請求項１３に記載のシステム。１５．前記電子データ交換プロセスを実行するための処理手段を備える、請求項１３または１４に記載のシステム。１６．前記データ交換プロセスの各実行が、プロセスのデータ定義のデータ例に関連している、請求項１５に記載のシステム。１７．前記プロセス中に前記データ例の前記データ要素を順次に記憶するための順次メモリファイルを備える、請求項１６に記載のシステム。１８．設計されているプロセスが、自動的に、電子データ交換メッセージに含まれているデータを、プロセスの実行中に前記データ定義のデータ例のそれぞれのデータ要素に書き込み、プロセスの実行中に前記データ定義のデータ例のそれぞれのデータ要素から、電子データ交換用データを読み取るように配置されている、請求項１３から１７のいずれか１つに記載のシステム。１９．前記記号が、予想されているイベントの事前定義されている数の発生またはタイマの満了のどちらか先に来る方を待つ機能を実行する待機ブロックに対応する記号を含む、請求項１３から１８のいずれか１つに記載のシステム。２０．前記プロセスの最後で前記データ例に含まれているデータのサブセットを格納するための格納手段を備える、請求項１４から１９のいずれか１つに記載のシステム。２１．コンピュータに、電子データ交換プロセスブロックを表す記号をディスプレイ上に表示させ、ユーザに、前記記号を前記ディスプレイ上でそれぞれに関連付けることにより、記号のシーケンスを設計するための手段を提供させ、前記ユーザによって設計された記号のシーケンスを解釈させ、それに基づき、前記関連付けられている記号により表されている電子データ交換ブロックに基づいた電子データ交換プロセスを定義させる手段で構成される製品。２２．コンピュータに前記電子データ交換プロセスを実行さえるための手段を備える、請求項２１に記載の製品。２３．前記コンピュータに、前記プロセスの各実行のためにデータ定義のデータ例を割り当てさせるための手段を含む、請求項２２に記載の製品。２４．前記コンピュータに、事前定義されている電子データ交換メッセージの受信によって前記プロセスの実行を開始させる、請求項２１から２３のいずれか１つに記載の製品。２５．設計されたプロセスが、自動的に、電子メッセージデータを、プロセスの実行中にデータ定義のデータ例のそれぞれのデータ要素に書き込み、プロセスの実行中にデータ定義のデータ例のそれぞれのデータ要素から電子メッセージデータを読み取るように装置されている、請求項２１から２４のいずれか１つに記載の製品。２６．前記コンピュータに、前記プロセスの実行の最後にデータ定義の前記データ例に含まれているデータのサブセットを格納させるための手段を備える、請求項２１から２５のいずれか１つに記載の製品。２７．前記製品が、コンピュータ読取り可能メモリの形を取る、請求項２１から２６のいずれか１つに記載の製品。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＣＺ，ＤＥ，ＤＥ，ＤＫ，ＤＫ，ＥＥ，ＥＥ，ＥＳ，ＦＩ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者ニルソン、ミカエルスウェーデン国、211 41 マルモ、マヨルスガタン９

Claims

【特許請求の範囲】１．電子データ交換メッセージ通信のための方法であって、電子データ交換プロセスが、事前定義されているデータ定義の対応するデータ例に関して実行され、前記データ定義は前記プロセスの実行中に連続して転送または処理される電子データのデータ要素のセットを定義し、そして前記プロセスが、受信電子データ交換メッセージに含まれているデータを、自動的に、前記プロセスの実行中、データ定義の前記データ例の事前定義されているデータ要素に書き込み、前記プロセスの実行中、データ定義の前記データ例の事前定義されているデータ要素から電子データ交換用データを読み取る方法。２．プロセスの各実行が、前記データ定義のそれぞれのデータ例に関連している、請求項１に記載の方法。３．前記データ例の前記データ要素を、前記プロセス中に順次メモリファイルに順次に格納することを含む、請求項１または２に記載の方法。４．前記プロセスの最後で前記データ例に含まれているデータのサブセットを記憶することを含む、請求項１、２または３に記載の方法。５．前記電子データ交換プロセスが、事前定義されている機能ブロックのセットを含む、請求項１、２、３、または４に記載の方法。６．前記機能ブロックが、予想されているイベントの事前定義されている数の発生またはタイマの満了のどちらか先に来るほうを待つ機能を実行する待機ブロックを含む、請求項５に記載の方法。７．前記イベントが、電子データ交換メッセージの受信を含む、請求項６に記載の方法。８．電子データ交換プロセスを実行するための処理手段と、前記プロセスに対応しているデータ定義のデータ例を格納するための、前記プロセスの各実行で転送または処理される電子データのデータ要素の事前定義されているセットを含む格納手段と、電子データ交換メッセージを受信し、送信するための手段と、受信電子データ交換メッセージに含まれているデータを、プロセスの実行中にデータ例のそれぞれのデータ要素に自動的に書き込み、プロセスの実行中にデータ例のそれぞれのデータ要素から送信する電子データ交換メッセージ用データを読み取るための手段と、を備える、データ交換メッセージシステム。９．プロセスの各実行が、前記データ定義のそれぞれのデータ例に関連している、請求項８に記載のシステム。１０．前記プロセス中に前記データ例の前記データ要素を順次に格納するための順次メモリファイルを備える、請求項８または９に記載のシステム。１１．前記プロセスの最後で前記データ例に含まれているデータのサブセットを格納するための手段を備える、請求項８、９、または１０に記載のシステム。１２．前記処理手段が、事前定義されているデータ交換メッセージを受信するときに、前記プロセスの実行を開始するように装置されている、請求項８から１１のいずれかに記載のシステム。１３．前記処理手段が、タイマの満了時または前記処理手段によって監視されている状態の変化時に前記プロセスの実行を開始するように装置されている、請求項８から１１のいずれかに記載のシステム。１４．前記処理手段が、事前定義されている機能ブロックのセットを実行することにより前記プロセスを実行するように装置されている、請求項８から１３のいずれかに記載されているシステム。１５．前記処理手段がタイマを備え、前記機能ブロックが、予想されているイベントの事前定義されている数の発生または前記タイマの満了のどちらか先に来る方を待つ機能を実行する待機ブロックを含む、請求項１４に記載のシステム。１６．前記イベントが、電子データ交換メッセージの受信を含む、請求項１５に記載のシステム。１７．電子データ交換プロセスブロックを表す記号を表示するための表示手段と、前記記号を前記ディスプレイ上に所望のシーケンスで互いに関連付けることによって、ユーザが記号のシーケンスを設計するためのインタフェース手段と、記号の前記シーケンスを解釈し、それに基づき、前記関連付けられている記号により表されている電子データ交換プロセスブロックに基づいた電子データ交換プロセスを定義するための解釈手段と、を備える、電子データ交換メッセージ通信プロセスを設計するためのシステム。１８．設計された電子データ交換プロセスに監視データ定義を定義するための手段を備え、前記データ定義が、前記プロセスの各実行で交換されるデータ要素のセットを含む、請求項１７に記載のシステム。１９．前記インタフェース手段が、前記ユーザが前記データ定義を定義できるようにするために装置されている、請求項１８に記載のシステム。２０．前記データ定義手段が、前記プロセスの事前定義されている入出力電子データ交換メッセージデータに基づき、前記データ定義を自動的に定義するように装置されている、請求項１８に記載のシステム。２１．前記電子データ交換プロセスを事項するための処理手段を備える、請求項１７、１８、１９、または２０に記載のシステム。２２．前記データ交換プロセスの各実行が、プロセスのデータ定義のデータ例に関連している、請求項２１に記載のシステム。２３．前記プロセス中に、前記データ例の前記データ要素を順次に格納するための順次メモリファイルを備える、請求項２２に記載のシステム。２４．設計されたプロセスが、自動的に、電予データ交換メッセージに含まれているデータを、プロセスの実行中にデータ例のそれぞれのデータ要素に書き込み、プロセスの実行中にデータ例のそれぞれのデータ要素から電子データ交換用データを読み取るように装置されているシステム、請求項１８から２３のいずれか１つに記載されているシステム。２５．前記記号が、予想されているイベントの事前定義されている数の発生またはタイマの満了のどちらか先に来る方を待つ機能を実行する待機ブロックに対応する記号を含む、請求項１７から２４のいずれか１つに記載のシステム。２６．前記プロセスの最後で前記データ例に含まれているデータのサブセットを格納主棚を備える、請求項１８から２５のいずれか１つに記載のシステム。２７．コンピュータに、電子データ交換プロセスブロックを表している記号をディスプレイ上に表示させ、前記記号を前記ディスプレイ上で互いに関連付けることによって、ユーザに、記号のシーケンスを設計するための手段を提供させ、前記ユーザによって設計された記号のシーケンスを解釈させ、それに基づき、前記関連付けられている記号により表されている電子データ交換ブロックに基づいた電子データ交換プロセスを定義させる、ための手段を備える製品。２８．前記コンピュータに、設計された電子データ交換プロセスに関してデータ定義を定義させる手段を備え、前記プロセスの各実行中に交換される定義されているデータ要素型であるデータ要素のセットを含む、請求項２７に記載の製品。２９．コンピュータに前記電子データ交換プロセスを実行させるための手段を備える、請求項２７または２８に記載の製品。３０．前記コンピュータに、前記プロセスの各実行のためにデータ定義のデータ例を割り当てさせるための手段を備える、請求項２９に記載の製品。３１．前記コンピュータに、事前定義されている電子データ交換メッセージの受信により前記プロセスの実行を開始させるための手段を含む、請求項２７から３０のいずれか１つに記載の製品。３２．設計されたプロセスが、自動的に、電子メッセージデータを、プロセスの実行中にデータ定義のデータ例のそれぞれのデータ要素に書き込み、プロセスの実行中にデータ定義のデータ例のそれぞれのデータ要素から電子メッセージデータを読み取るように装置されている、請求項２７から３１のいずれか１つに記載の製品。３３．前記コンピュータに、前記プロセスの実行の最後でデータ定義の前記データ例に含まれているデータのサブセットを格納させるための手段を備える、請求項２７から３２のいずれか１つに記載の製品。３４．前記製品が、コンピュータ読み取り可能メモリの形を取る、請求項２７から３３のいずれか１つに記載の製品。