JP3274131B2 - オブジェクト指向地点間通信方法およびその方法を行う通信装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は請求項１、10、28の
前提部分にそれぞれ記載されている方法、装置、システ
ムに関する。これらの請求項はEP-A-0 456 249号明細書
に基づいて限定されている。本発明は電子データ通信、
組織されたデータベース、フレキシブルフォーマット電
子データメッセージ管理、クライアント−サーバおよび
分配されたソフトウェアアプリケーションの分野に関す
る。

【０００２】特に、本発明は、生成、通信、解釈、フレ
キシブルなフォーマットの電子データメッセージに対す
る表示および実時間応答、１以上の電子データ回路網上
の１以上のコンピュータシステムを横切って選択的に分
散されてもよいフレキシブルなフォーマットの電子デー
タメッセージの集合として組織されるアプリケーション
とを説明し管理するための合理的なデータベースを使用
する。

【０００３】

【従来の技術】一般目的およびビジネス用の特定の電子
データ通信は４つの異なる問題に直面しており、それら
はそれぞれさらに多数の問題を有している。以下の点は
電子データ通信のほとんどのカテゴリに適用されること
ができるが、ビジネスの通信要件に関するこれらの問題
を説明する。４つの問題とは、 １）送信され受信される電子データはそれが意味するも
のが明白に認識されなければならない。各企業は例えば
ほとんどの基本的なビジネス情報、出荷の注文書または
請求書でさえそれらを表すために種々の異なる方法を有
する。 ２）一度、別の企業から電子データが受信され、正確に
認識されると、受信された企業のデータベースおよびビ
ジネス処理プログラムに集積されなければならない。各
企業はそれらのデータベース構造、即ちコンピュータシ
ステムに電子データを表し記憶する方法は多数存在し、
異なっている。 ３）電子データはエンドユーザに表示され、エンドユー
ザの対話を可能にしなければならないならば、各企業は
種々のタイプのディスプレイソフトウェア、種々のシス
テム要件、ビジネス要件を有する異なるタイプのコンピ
ュータディスプレイ端末を使用している可能性がある。
カスタム化されたグラフィックユーザインターフェイス
を有する非常に高価な電子データディスプレイプログラ
ムを構築することが非常に頻繁に必要とされる。 ４）特定のビジネス機能を実現するために特定化された
システムサービスおよび関連するデータとの組合わせを
使用することが必要とされるために、１以上のコンピュ
ータシステムを横切って分散された、調整された方法で
コンピュータ化されたビジネス機能の処理を実行する必
要がある。このことはコンピュータ化されたビジネスシ
ステムが１以上の位置に存在し、１以上の位置で異なる
動作を行うが、基本的には１つの単一システムのように
機能することを必要とすることを意味している。この問
題に対する解決策は、分散されたアプリケーション、ま
たは最近では“ミドルウェア”として分類される分散さ
れたオブジェクト管理システムとして区別される。

【０００４】４つの問題に関する２つの異なる主な問題
が存在する。第１に、企業が多数の異なるシステムで同
一のビジネスアプリケーションを使用し、動作を必要と
する各異なるシステムにおけるビジネス理論、ユーザイ
ンターフェイス、ネットワーク通信インターフェイスを
再度書込む必要をなくすことを要求し、所望することで
ある。第２の問題は、通信回路網を横切って１以上のシ
ステムにわたり１つのアプリケーションの機能を分割
し、十分に調整された方法で動作させる必要性である。

【０００５】これらの全ての４つの問題を解決できる単
一システムは現存存在しない。ビジネスは電子データ通
信および記憶システムを販売、構築、再構築、メンテタ
ンスに毎年、数百万ドルを浪費しており、これらの４つ
の問題の種々の組合わせを実効的および完全に解決して
いない。

【０００６】問題１ 第１の問題を解決するため、特定のタイプの情報の１組
の電子データフォーマットは通信が実際に行われる前に
全ての通信企業により同意されなければならない。さら
に、フォーマットについての同意は、これらの同一の丁
度同意されたフォーマットを使用する通信ソフトウェア
の使用によって実現されなければならない。ＥＤＩ（El
ectronic Data Interchange ）はこの問題を解決する１
方法である。ＥＤＩは多数のタイプのビジネストランザ
クションに対する１組の電子データメッセージフォーマ
ットである。フォーマットはフレキシブルではなく、こ
れらはユーザにより変更されることができないことを意
味し、ほんの少し異なるＥＤＩメッセージのバージョン
が存在する。企業はＥＤＩメッセージビジネス通信シス
テムを構成し、異なるバージョンのＥＤＩメッセージセ
ットを使用して他の企業と電子データを交換することが
依然として可能ではない。既存のビジネスシステムをＥ
ＤＩに変換するのにかかる時間量および金額は莫大であ
り、別のフォーマットが必要になるならば、それに変更
または付加することは困難であり高価である。

【０００７】ハードコード（即ちソフトウェアで限定さ
れた）メッセージフォーマットを使用する方法および解
決策はＥＤＩに関連する全ての問題を有し、異なる固定
メッセージフォーマットのみについての基本的に同一の
解決策である。固定メッセージフォーマットが変更され
なければならない度毎に、これはソフトウェアとデータ
ベースおよびユーザインターフェイスを同様に変更する
ことを必要とする。非常に小さい変更でさえも、時折数
か月かかる。勿論、この電子メッセージフォーマットは
将来の電子通信が正確に継続することを確実にするた
め、特定のフォーマットを使用してビジネス毎のコンピ
ュータで変更されなければならない。

【０００８】基本的に、共通のデータフォーマット幾つ
かの方法で送信者および受信者により同意されなければ
ならない必要性が常に存在する。これは現在または将来
有効な方法に存在する。カスタマに対して臨界的な問題
は、方法（即ちＥＤＩ）についてのシステムの構築がど
の程度高速度で廉価であり、システムのあらゆる部分
（データベース、ソフトウェア、ユーザインターフェイ
ス）において、先に同意された電子データフォーマット
の変更がどの程度容易であるかである。

【０００９】問題２ 第２の問題は、解決がさらに困難な問題である。通常、
ほとんどの企業は多数のデータエントリ人員を使用し、
彼等は印刷物を読取り、読取られたデータを処理して端
末で作動するコンピュータプログラムへ読出し、これを
正確なフォーマットへ変換し、企業のデータベースに位
置する。ＥＤＩまたは類似の共通の電子メッセージフォ
ーマットを使用する企業は、非常に多額の費用をカスタ
ム化ソフトウェアに費やし、カスタム化ソフトウェアは
これらの共通の電子メッセージフォーマットを自動的に
処理して変換し、データ記憶および検索の目的で既存の
データベース構造と対話する。共通のメッセージフォー
マットに対して変更または付加が必要であるならば、ま
たはデータベース構造の変更または拡張が必要であるな
らば、この電子メッセージフォーマットデータベースイ
ンターフェイスプログラムを変更させ再度書込ませるた
めに時間と多額の費用を費やさなければならない。

【００１０】１つの新しい公共ドメインの通常目的の解
決方法は、カスタマのデータベースまたは記憶装置の特
定位置への特定データアイテムの“マッピング”を中心
としている。このマッピングはソフトウェアでは生成さ
れないで、幾つかのさらに容易に変更可能でフレキシブ
ルの表示中に存在し、これはソフトウェアアプリケーシ
ョンおよびソフトウェアアプリケーションが読取る独立
したフラットファイル等のカスタマのデータベースとは
分離されている。これはデータベース構造またはデータ
表示が変更する度にソフトウェアアプリケーションを再
プログラムおよび再構築する必要性を除去する。データ
フィールドマッピング技術はProgress、Oracle、SQLBas
e （SQL ＝Standard Query Language ）等の多数のデー
タベース企業により共通して使用される。よく知られた
方法のバージョンは本発明の通信装置に構成される機能
および方法論の一部である。

【００１１】問題３ 第３の問題は、容易に動作可能な通常目的の幾つかの解
決策を持つことである。解決策の１つのカテゴリはＸウ
ィンドウズまたはマイクロソフトウィンドウズ等の種々
のウィンドウ（グラフィックユーザインターフェイス）
管理システムに対して相当の量のソフトウェアコードを
書込むことを必要とする。大きい多機能ビジネスアプリ
ケーションでは、この方法は莫大な量の時間、費用、労
力を必要とし、ユーザインターフェイスに対する変更ま
たは付加は非常に時間を消費し、価格的にも問題にな
る。

【００１２】新しく有望な解決策のカテゴリはＨＴＭＬ
（Hyper Text Markup Language) およびウェブブラウ
ザの使用を中心とし、これはワールドワイドウェブおよ
びインターネットで使用されるため“ウェブページ”と
通常呼ばれている非常に見掛けの良いグラフィックユー
ザインターフェイスをダイナミックを生成することがで
きる。これには多数の企業が興味を示している。企業
は、ＨＴＭＬを使用していかに迅速で廉価に非常に見掛
けの良いグラフィックユーザインターフェイスを作成さ
れることができるかを観察し、電子データ通信および処
理プログラム用のユーザインターフェイスがウェブブラ
ウザシステムと同一方法で生成され同じ回路網で通信す
るか否かの疑問をもつ。実際、企業は全ての範囲のビジ
ネスおよびパーソナルデータおよびメッセージを送信お
よび受信するためにインターネットを使用することがで
きることを好む。

【００１３】現時点では、ＨＴＭＬおよびウェブブラウ
ザを使用して、インターネットにわたる限定された範囲
のビジネスおよび汎用のデータ通信を可能にする有効な
幾つかのシステムが存在する。データ通信のタイプが限
定される理由は、ウェブサーバ／ウェブブラウザシステ
ムが十分なデータ通信サービスを行うように設計されて
いなかったことである。それらはダイナミックなドキュ
メントの検索およびディスプレイシステムとして設計さ
れた。それらはユーザからのリクエストとして最初に初
期化される情報を検索できる。それらは広範囲の付加的
なプログラミングによることを除いて、１以上の目的地
へ情報を送信する能力をユーザに与えない。送信能力は
システムに固有ではない。このタイプの例は、Progres
s' WebSpeed、IBM's WebEDI、SapphireGroup's PageBla
zerである。

【００１４】いわゆる“プッシュ”技術を構成するウェ
ブブラウザおよびウェブサーバの“新しい”特等でさえ
も送信をすることはできずデータ受信のみを可能にす
る。この“受信”は、ウェブブラウザおよびウェブサー
バシステムにより実際はシミュレートされた放送受信機
として情報（ポーリング）の隠れた反復リクエストが設
定される。この“プッシュ”技術を拡張するための計画
は、真の放送およびマルチキャスト通信技術の使用だけ
を含んでいる。“プッシュ”技術の例は、Marimba のCa
stanetおよびTibco のＴＩＢ ＡＰＩである。このいわ
ゆる“プッシュ”技術は新しい方法で大市場まで広げる
ことを要求する広告業者には大きな関心事であるが、既
存のデータベースおよびビジネスシステムに容易に集積
されることができる地点間のプロトコルを使用した十分
に集積された双方向情報通信の内容で、ＨＴＭＬおよび
インターネットの進んだドキュメントディスプレイ特性
を使用することを要求または必要とする企業または個人
にはほとんど使用されない。

【００１５】インターネットのウェブサーバとウェブブ
ラウザインターフェイスは、ウェブページのリクエスト
としてメッセージをエンドユーザへ送信することを可能
にするように設定される。電子メールを除いてウェブブ
ラウザユーザはメッセージを別のウェブブラウザユーザ
へ送信し、またはウェブページを別のウェブブラウザユ
ーザへ送信できることはなかった。ウェブブラウザユー
ザは最初に求められていなかった特定のメッセージを受
信したことはなく、いわゆる“プッシュ”技術情報でさ
えもポーリングおよび情報特性によりリクエストされる
ことはなく、カスタム化されたときでさえもテレビジョ
ン放送または大量のメーリングと比較されることができ
ない。情報は１つの特定の受信者に対して送信されては
いない。これは例えば電子メール（ｅメール）と対照的
である。ｅメールサービスを使用すると、最初に、送信
者に要求せずに、任意の数の特別な私用メッセージを受
信することができる。最初に要求せずに、任意の数の特
別な私用メッセージを特定の受信者へ送信することがで
きる。これはメッセージの一般的な必要な特性である。
インターネットのウェブサーバシステムはこのような通
信を行うように設計されていなかった。

【００１６】企業および個人がこのようにこれらを使用
することに関心をもつ理由は何であろうか？。彼等は単
にｅメールを使用したらどうか？。その答えはｅメール
が （ＨＴＭＬが行うように）それに組込まれたデータ
フォーマットサービスをもたず（ウェブブラウザが行う
ように）それに組込まれたユーザインターフェイス生成
をもたないからである。ｅメールメッセージはまたその
目的地に到達するために不確定の時間量（数秒から数
日）かかり、時には失われなくなることもある。これは
標準的なビジネス電子データ通信に対しては許容できな
い。この理由で企業および個人は、それに組込まれた非
常に良好なデータディスプレイ能力と、適度に高速度の
通信を有するウェブサーバ／ウェブブラウザシステムを
好む。しかしながら、前述したように、地点間通信能力
またはデータ表示およびマッピング能力をもたない。

【００１７】本発明では、公共ドメインＨＴＭＬ標準は
非常に容易に構築され、高速度でフレキシブルなグラフ
ィックユーザインターフェイスを生成するための解決手
段として組込まれてもよい。

【００１８】問題４ 歴史的に、問題４は、非常に最近まで関係型データベー
ス管理システム（ＲＤＢＭＳ）だけによって一般的な方
法でアドレスされてきた。このクラスの解決策は分散さ
れた問合わせおよび分散されたデータベース管理の適切
な機能を解決するように限定されており、先に説明した
問題４の主要な２つの問題をアドレスしない。

【００１９】第２の、新しいクラスの解決策は“ミドル
ウェア”または分散されたオブジェクト管理システムと
現在呼ばれているシステムで見られる。これの良い例は
ＣＯＲＢＡ（Common Object Request Broker Architect
ure ）と呼ばれるシステムである。ＣＯＲＢＡの開発経
歴、目的、ＣＯＲＢＡ 2.0の現在の機能および欠点にお
ける優秀な文献セットは、Warren Kayffill 、“CORBA
masterminds object management ”、42頁、ＤＢＭＳマ
ガジン10巻、No.3、1997年３月と、同じＤＢＭＳ出版の
T.J.Hart“Questioning CORBA. Bringing Corba-based
designs to life faces a multitude of obstacles”、
52頁で見られる。

【００２０】このクラスの解決策はデータベースの共同
使用可能性問題と、アプリケーションレベルの共通のデ
ータフォーマット問題またはユーザインターフェイス問
題をアドレスする。これは通信レベルで標準的な通信イ
ンターフェイスおよび標準的なデータによりアプリケー
ションを書込む能力だけをアドレスする。基本的に、こ
のタイプのシステムは開発環境と、実行時の環境と、１
組のソフトウェアライブラリを供給し、これによってプ
ログラマは任意のシステムで実行するアプリケーション
を生成することができ、コードのデータ構造（いわゆる
オブジェクト）を定めた後にこれらのデータ構造は、こ
れらの特定のデータ構造を認識し、使用するようにコー
ド化されているその他のソフトウェアプログラムと交換
されることができる。

【００２１】この能力および機能は、根本的にJavaにお
いてメッセージ通信システムを書込むプログラマとは異
なっておらず、これはほとんど任意のシステムで動作
し、ＥＤＩメッセージまたは通信媒体等の幾つかのその
他の同意された固定フォーマットを使用する。ＣＯＲＢ
Ａシステムはメッセージを何等解釈しない。プログラマ
により書込まれたアプリケーションはメッセージを認識
できなければならない。これはＣＯＲＢＡアプリケーシ
ョンに、ＥＤＩまたは固定されたメッセージフォーマッ
トアプリケーションシステムと同様の開発、変更、メン
テナンスの価格および時間についての全ての問題を残
す。ＣＯＲＢＡによって可能な分散された機能でさえ
も、ＣＯＲＢＡで固有ではなく、アプリケーションを設
計およびコード化するプログラマの技能とＣＯＲＢＡ通
信ライブラリの使用が基本的に必要である。根本的に、
ＣＯＲＢＡの唯一の明白な利点は、多数の実行時の環境
にわたってアプリケーションシステムの部分の共同使用
可能性であり、これは恐らくJavaのようなその他の手段
により良好に得られることができる。

【００２２】基本的に、ほとんどのケースの“ミドルウ
ェア”は実際には標準的な通信環境と幾つかの標準化さ
れたソフトウェア機能を多数のコンピュータで与える丁
度別の電子データ通信環境であるように見えるが、ソフ
トウェアアプリケーション構築の全ての特徴をアドレス
することはできず、データベースインターフェイスおよ
びユーザインターフェイスに対するシステム依存コード
の使用を必要とし、それによってＣＯＲＢＡ等のシステ
ムを使用する主要な目的を無効にする。

【００２３】ＣＯＲＢＡ機能をJavaに吸収し、ＯＤＢＣ
と呼ばれる標準化されたデータベースインターフェイス
を含むシステム、またはJavaシステムＪＤＢＣに存在す
る幾つかのシステムが存在する。これは興味深い開発で
あるが、ＣＤＢＣデータベースインターフェイスのよう
に、読取り専用の問い合わせにのみ有効であり、十分な
データベースアクセスを必要とする標準的なビジネスト
ランザクションシステムは適切に生成されることができ
ない。また、この組合わせは問題１または２を全くアド
レスしない。さらに、ＯＤＢＥＣの使用とＣＯＲＢＡオ
ブジェクトブローカーシステムの不適切なオーバーヘッ
ドのために、これは本発明を構築するための所望のプラ
ットフォームではない。

【００２４】さらに従来技術は、以下簡単に説明する幾
つかの特許明細書にも記載されている。米国特許第5,25
7,369 号明細書(Tibco 社）は先に示した“ミドルウェ
ア”を開示している。さらに、この明細書は放送機能を
与え、放送機能に基づいている。これは実時間在庫見積
もり、市場情報のような実時間データを伝送する問題に
対する解決策を一度に多数の受信者に主に与え、地点間
通信または問題２、３を全くアドレスしない。メッセー
ジフォーマットは変更されることが可能でありまた先の
ＣＯＲＢＡに説明されているように、データ構造または
オブジェクトとして限定される。しかしながら、この能
力はアプリケーションコードを変更せずにメッセージフ
ォーマットを変更または付加する能力をアドレスせず、
またはメッセージフォーマットのデータをユーザインタ
ーフェイスまたはデータベースフィールドのいずれかに
マップする能力をアドレスしない。

【００２５】WO 96/20553 (Alphanet Telecom社）明細
書は音声メールおよびファクシミリ（ファックス）情報
を含むような電子メール（ｅメール）サービスの強化に
焦点を置いている。このシステムは、ユーザが音声メー
ル、インターネットによるｅメール、またはファック
ス、同一のサービスに接続する電話またはファックス機
械に受信のために接続することができる中央化されたサ
ービスを行う。この本発明は問題１、２、３または４を
アドレスしないが、ｅメールを通信視野からさらに効率
的にする方法をアドレスする。

【００２６】WO 96/34341 （Charles Bobo II）は中央
化サービスに焦点を置き、これは接続されたユーザのデ
ータを集収し、記憶し、これらのアクセスを可能にす
る。これはほとんどのタイプの標準的なビジネス通信に
おける問題１乃至４を解決するのに必要な地点間通信と
は全く異なる。さらに、多年にわたって存在している市
場で入手可能なシステムが多数存在し、これは２のみを
示すためＧＥＩＳ、ＩＢＭ私用データ回路網等に、既に
丁度このように機能する。

【００２７】EP-0,747,840 A1、EP-0,747,841 A1、EP-
0,747,842 A1、EPO,747,843 A1 、EP-0,747,844 A1、EP
-0,747,845 A1 明細書（全てInternational Business M
achines Corporation ）では幾つかの形態のデータベー
スアクセスにより現在のウェブサーバ機能を強化するこ
とに焦点を置き、それ故、前述したウェブサーバの通信
限界により制限される。それ故、これらの発明は問題１
と４を全く解決できず、限定された方法でのみ問題２と
３を解決する。さらに、Progress Database Corporatio
n からのWebSpeedのようなウェブサーバ強化において同
じまたはさらに多くの機能を与えるように見える幾つか
の市場で入手可能なシステムが存在する。

【００２８】WO 95/11560 号明細書(Sybase社）には、
使用されるコンピュータハードウェアまたはオペレーテ
ィングシステムにかかわりなく、アプリケーションが構
築される一貫した電子データ通信ソフトウェアインター
フェイスを生成する問題だけを解決する“ミドルウェ
ア”のカテゴリについて記載されている。この明細書は
任意の方法で通信される電子データのフォーマットをア
ドレスせず、この問題はＣＯＲＢＡに非常に類似し、本
発明によりアドレスされる４つの問題の視点から全ての
同一の制限を有する。

【００２９】EP 0 421 624 A2 号明細書（Texas Instru
ments Incorporated）はＣＯＲＢＡ等の“ミドルウェ
ア”システムと、アリケーション開発環境の組合わせに
ついて記載されている。データベース制御され管理され
たソフトウェア開発環境を使用して、ここで記述された
発明はプログラマがＣ、ＣＯＢＯＬ、ＳＱＬのアプリケ
ーションを開発することを可能にする。データベース
は、大きいグループのプログラマが複雑なデータベース
トランザクションアプリケーションのソースコード制御
技術を開発し、変更し、使用することを可能にする情報
を含んでいる。この明細書では、多くはＩＢＭメインフ
レームシステムおよび幾つかのＵｎｉｘシステムについ
て説明しているが、データベースはまたアプリケーショ
ンが別のハードウェアシステムで再度コンパイルされ、
各タイプのコンピュータで同一方法で機能することを可
能にする情報も含んでいる。最終結果は一連のハードコ
ード化されコンパイルされたアプリケーションであり、
全ての問題が問題１および２で説明されているのと同一
であり、部分的にのみ問題３、４を解決する。

【００３０】EP 0,456,249 A2 号明細書(Hewlett-Packa
rd Company ）はＣＯＲＢＡ等の“ミドルウェア”シス
テムと、主要な能力が異なった高レベルのプログラミン
グ言語で開発されている既存のアプリケーションと連結
している部分的なアプリケーション開発環境の組合わせ
である。本発明で述べる高レベルの言語はそれらのデー
タの異なる実行時間メモリ内組織を有し、１つの言語組
織から別の言語組織へデータを変換しなければならな
い。結局、中間データ表示およびデータ転送命令は、デ
ータ表示をコンパイルし、命令を転送した後、その発明
が１つの言語の実時間表示からの識別されたデータ構造
を別の言語の実時間表示からの識別されたデータ構造へ
変換することを可能にする。この発明はアプリケーショ
ンとして独立して実行するために必要な全てのデータお
よび命令を含んでいるメッセージフォーマットを任意の
方法でアドレスせず、２つの予め存在するアプリケーシ
ョン間の特定されたデータ構造を変換するのに必要なデ
ータおよび命令のみをアドレスする。それ故、この発明
は問題２と３で説明されている問題を全くアドレスせ
ず、ここで説明しているようなアプリケーションレベル
ではなくプログラミング言語のレベルで問題１と４の問
題を部分的にのみアドレスする。対照的に、本発明で
は、アプリケーションは全体的にメッセージから構成さ
れ、それ故、１つの言語からのデータを別の言語のデー
タへ変換することはなく、メッセージフォーマットまた
は命令のコンパイルは必要とされず、全てのデータはそ
れが送信されてもコンピュータメモリ中に残っていて
も、メッセージフォーマットに残留する。

【００３１】

【発明が解決しようとする課題】前述したように、各こ
れらの４つの問題を解決でき解決策を１つの一体化され
た統一体に結合することができる１つの通信システムお
よび方法が緊急に必要とされる。複雑な電子データ通信
システムを構築しなければならない個人および企業と、
日常ベースでこれらの問題に直面しなければならない人
にはこれは有効である。このようなシステムおよび通信
方法は電子データ通信システムを構築し、維持する時
間、価格、複雑性を劇的に減少する。

【００３２】

【課題を解決するための手段】前述の目的を獲得するた
めに、本発明は請求項１の前提部分で規定され、特徴部
分によって特徴付けられている送信機と受信機との間の
地点間通信方法を特徴とする。

【００３３】結果として、定められたアプリケーション
レベル機能の全ての素子がメッセージフォーマット中に
存在し、これは既に回路網通信システムの文脈中にあ
り、それ故単に位置および目的地アドレスを変更するこ
とによって容易に分配されることができる。

【００３４】さらに、本発明によれば、通信装置は請求
項10にしたがって限定されている。

【００３５】したがって、本発明においては、任意のタ
イプのデータを含むことができ、メッセージ自体内のデ
ータを十分に記述するのに十分な情報を含んだフレキシ
ブルなメッセージフォーマットが規定される。任意のメ
ッセージは、データベースに予めロードされたメッセー
ジ定義を識別するためメッセージを受信する上記の通信
装置により使用されるメッセージ定義基準を含んでい
る。しかしながら、予めロードされたメッセージ定義は
一度も全く固定されないので技術はフレキシブルであ
る。メッセージを受信する通信装置内では、メッセージ
を十分に記述しそれを特有の識別子と参照する関連する
データベース表中にエントリを挿入し、更新し、または
消去することによって、メッセージフォーマットの特定
インスタンスが生成され、編集されまたは消去される。
さらに、メッセージ定義が所望の位置に存在しないなら
ば、全体的なデータベースメッセージ定義は特定のメッ
セージまたはメッセージのグループに対して自動的に交
換されてもよく、それによって多数のユーザの容易に交
換される共通のフォーマットメッセージを生成する。本
発明のさらに別の利点は必要なオーバーヘッド量が少い
ことである。

【００３６】メッセージ定義基準内のフィールドの例
は、任意のメッセージを識別するためのメッセージ識別
子と、メール、ビジネスメッセージ、注文または発送等
の任意のメッセージのメッセージクラスを識別するメッ
セージクラス識別子と、任意のメッセージのバージョン
番号を識別するメッセージバージョン識別子と、任意の
メッセージのクリエイタを識別するメッセージクリエイ
タ識別子である。メッセージ定義基準内の任意のこれら
のフィールドは上述の通信装置のメッセージ定義表内に
対応するフィールドを有する。

【００３７】さらに、メッセージのヘッダは使用される
暗号化および／または圧縮タイプの基準を含んでいる。
またこれらの基準は通信装置のメッセージ定義表中に対
応部分を有している。

【００３８】好ましくはメッセージの内容はデジタル署
名により保護される。

【００３９】好ましくは通信装置のデータベースは幾つ
かの表で組織され、その表に対してメッセージ定義表か
ら参照を行う。予め定められたメッセージ定義表はデー
タベースのさらに別の表の参照として使用するためのメ
ッセージシステム識別子を含んでいる。

【００４０】このようなさらに別の表のうちの１つはメ
ッセージの任意のフィールドの主な定義を保持するため
のフィールド定義表であってもよい。

【００４１】好ましくは、さらにこのような表のうちの
１つは、例えばハイパーテキストマークアップ言語フィ
ールド、データベースフィールド、フラットファイルフ
ィールドおよびその他のメッセージフィールドにマップ
するための、予め定められたフィールドにより使用可能
なマッピング指令を含むフィールドマッピング表であ
り、前記データベースフィールドとフラットファイルフ
ィールドはカスタマデータベース中に記憶されている。
本発明にしたがったメッセージフォーマットは、データ
だけではなく、ユーザインターフェイス、カスタマデー
タベースフィールド、計算および条件論理を含むアクシ
ョンシーケンスのマッピング命令を含んでいる。結果と
して、アプリケーションレベル機能を規定する全ての要
素はメッセージフォーマットに存在し、それは既に回路
網通信システムの文脈中にあり、それ故位置および目的
地アドレスを単に変更することにより容易に分布されて
もよい。さらに、このようにＨＴＭＬ標準は、非常に容
易に構築され、高速度でフレキシブルなグラフィックユ
ーザインターフェイスを生成し、上述の通信装置により
管理され、規定され、制御され、マイクロプロセッサ等
のユーザ端末と対話され通信装置へ接続されるように、
本発明により限定されたメッセージフォーマットへのマ
ッピングおよびそこからの直接的なマッピングを可能に
するために設けられてもよい。

【００４２】さらに、このような別の表のうちの１つは
予め定められたフィールドにより使用可能なメッセージ
アクションリストを含むフィールドアクション表であっ
てもよい。

【００４３】好ましくは、さらに別の表は、受信または
送信されるメッセージの前処理として実行されるアクシ
ョンリストを含むメッセージ前処理表、および受信され
るメッセージの後処理として実行されるアクションのリ
ストを含むメッセージ後処理表である。

【００４４】フィールドアクション表、メッセージ前処
理表、メッセージ後処理表は以下のアクションのグルー
プ、即ちアクションのデータベースタイプと、数学的演
算、割当、論理演算、条件演算、命令を含むアクション
の論理タイプから選択されたアクションのタイプの基準
を含んでいる。

【００４５】好ましくは、本発明においては、アプリケ
ーションは１以上のメッセージの名前を付けられたグル
ープとして定められる。すなわち、メッセージ定義表は
受信されたメッセージがアプリケーションの最初のメッ
セージであるか否かを示すアリケーションフィールド
と、アプリケーションの名称を参照するためのアプリケ
ーション名称フィールドとを含んでいる。

【００４６】本発明によると、通信装置は、受信された
メッセージがそのデータベース中に存在しないメッセー
ジ定義を参照した場合には、送信者からの新しいメッセ
ージ定義をリクエストし、前記送信者から前記新しいメ
ッセージ定義を受信し、前記データベースの前記メッセ
ージ定義表にこれを記憶するように構成されることが好
ましい。

【００４７】通信装置の処理手段は、指定されたＨＴＭ
Ｌファイルで受信されたメッセージをマージするか、ま
たは指定されたＨＴＭＬファイルが処理手段により発見
されなかった場合には、デフォルトダイナミックＨＴＭ
Ｌファイルを生成するように構成されてもよい。しかし
ながら、その代わりに、通信装置の処理手段は、接続さ
れた端末にこれらの機能を実行するように指令してもよ
い。それ故、本発明は先に規定したような通信装置と、
通信装置に接続され端末プロセッサを有する端末とを具
備するシステムにも関し、端末は端末プロセッサと、デ
ィスプレイ装置と、ユーザによるデータを入力するため
の入力手段とを具備し、通信装置は、端末がメッセージ
中で目的地アドレスであることを示されたならば、受信
されたメッセージを端末に送るように構成され、端末プ
ロセッサは指定されたＨＴＭＬファイルでメッセージを
マージするか、または指定されたＨＴＭＬファイルが端
末プロセッサにより発見されなかった場合にはデフォル
トダイナミックＨＴＭＬを生成するように構成される。

【００４８】したがって、端末プロセッサが対応するメ
ッセージ定義をもたないメッセージを受信するユーザ端
末は、システムの自動解釈とディスプレイに依存するこ
とができ、これは受信されたメッセージ内に含まれる自
己記述情報に基づいている。この同じ自己記述情報は、
メッセージによって参照されたデータベースメッセージ
定義が発見されることができない場合には端末プロセッ
サによりデフォルトデータベースメッセージ定義を自動
的に生成するために使用されることができる。このよう
なデフォルトデータベースメッセージ定義は、端末ユー
ザにより編集され、ローカルシステムに適合されること
ができる。

【００４９】本発明は、問題１および４に対する完全に
新しい解決策を有する特有の方法で組合わされて問題２
および３に対する現在知られているの解決策を含んでお
り、全てはフレキシブルメッセージフォーマットおよび
通信装置からなる特有のフレキシブルフォーマット電子
データメッセージ管理システムを中心として構築され
る。

【００５０】関連データベース表に記憶された詳細な情
報により規定され制御される本発明のメッセージ管理シ
ステムは、最も効率的で、完全で、簡単に、フレキシブ
ルフォーマットで電子データを通信する方法を使用する
ことを可能にする。フレキシブルメッセージフォーマッ
トは、任意の形態の電子データを含むことを可能にす
る。フレキシブルメッセージフォーマットは、メッセー
ジが先に受信されていなくても、受信機がメッセージの
内容を解釈し、理解し、表示することを可能にする情報
を含んでいる。受信機はまたソフトウェアを書込みまた
は変更せずに、この未知のメッセージフォーマットをそ
の固有のメッセージデータベースへ付加しこれをそのビ
ジネスデータベースおよびＨＴＭＬユーザインターフェ
イスに非常に容易に素早く連結することができる。ＨＴ
ＭＬユーザインターフェイスは、また特定化され先に生
成されたＨＴＭＬファイルが存在しない場合に端末のソ
フトウェアによりダイナミックに生成されることもでき
る。これは第１の問題を解決する。

【００５１】本発明では、主要な合理的データベースへ
のＡＮＳＩ標準ＳＱＬインターフェイスが設けられても
よい。このインターフェイスは後で記憶または検索のた
めに関連データベース表中のフィールドへユーザが選択
したデータメッセージのフィールドを自動的に連結する
サービスを行う。このデータマッピングインターフェイ
スは固定した長さのフィールドおよびＣＳＶ（カンマで
分離された値）ファイルのようなフラットファイルフォ
ーマットへ連結することもできる。このデータマッピン
グインターフェイスは、メッセージデータフィールドを
ＳＮＭＰおよび自動処理制御用の製造プロトコルのよう
な多数の他のフォーマットに連結するように拡張される
ことができる。このデータマッピングインターフェイス
はＩＬＭＤＢ中のエントリにより規定され、ＩＬＭＳに
より制御される。これは第２の問題を解決する。

【００５２】本発明では、メッセージ制御ユーザインタ
ーフェイス端末が設けられ、ここでユーザはメッセージ
を生成し、編集し、受信し、送信し、観察する。メッセ
ージ制御ユーザインターフェイスは本発明にしたがって
構成された回路網およびメッセージ管理サーバと通信す
る。本質的に、本発明は十分なデータ通信能力を必要と
する個人または企業に対する現在のウェブサーバ／ウェ
ブブラウザ技術を置換し、任意のデータ通信回路網を含
むようにシステムドメインを拡張する。これはＨＴＭ
Ｌ、ＶＲＭＬ、Ｊａｖａアプレット、ならびにユーザが
特定のメッセージ中で規定された任意の特定データの十
分な送信および受信を可能にする。先に示した特徴と組
合わせるとき、これは十分な、データベース制御された
メッセージ中のデータ間の連結と、検索されるまたは記
憶しなければならないカスタマデータソースと、表示さ
れなければならないグラフィックユーザインターフェイ
ス（ＨＴＭＬ等）を与える。

【００５３】前述の問題を解決することに加えて、本発
明は自動的な、システムが実行するアクションを規定す
る能力を付加し、これはメッセージの前処理および後処
理として組織され、またはグラフィックユーザインター
フェイスと連結したメッセージの場合、フィールド選択
アクションを規定する能力を付加してもよい。これらの
アクションはＳＱＬまたは“InterLingua （商標名）ス
クリプト”として限定される。InterLingua （商標名）
スクリプト”（ＩＳ）は本発明において規定され、簡単
でしかも強力なセットの計算、実行および条件論理制御
ステートメントであり、これはダイナミックに解釈され
実時間で実行され、全てのメッセージデータフィールド
と対話できる。アクションは新しいメッセージと、シス
テム機能と外部プログラムに作られた呼びとを生成し、
またはデータベースの問合わせを送信および受信するこ
とができる。これらのアクションは例えば自動メッセー
ジ応答と自動フィールド確認を生成し、計算を実行し、
Ｊａｖａアプレットまたは複雑なデータベーストランザ
クションを実行する。

【００５４】本発明では、１組のメッセージおよびそれ
らの関連したアクションとして定義されているアプリケ
ーションの非常に特有の方法を含んでいる。メッセージ
間の対話の豊富さとフレキシブル性のために、データベ
ーストランザクションを実行する能力はグラフィックユ
ーザインターフェイスとマージ（合体）またはそれを生
成するか、または背景プロセスとしてシステムで静かに
実行し、データメッセージの集合およびそれらの関連ア
クションとして複雑なアプリケーションを十分に限定す
ることができる。これらのメッセージはそれらの特性に
よってシステムの基本的な機能として非常に容易に送信
され受信され理解され組織化されるので、これは分散さ
れたアプリケーション処理の範囲で大きな内包を有す
る。このことは、最初に、任意のソフトウェアコードを
変更または付加せずに、分配されたアプリケーションシ
ステムが同一のアプリケーション（メッセージセット）
を使用しながら、各位置においてローカルユーザインタ
ーフェイスと（ビジネスデータベースのような）カスタ
マデータソースインターフェイスを容易にフレキシブル
に限定できることを意味する。

【００５５】

【発明の実施の形態】本発明を幾つかの図面を参照して
説明するが、それは本発明を例示することのみを目的と
し、本発明の技術的範囲を限定するものではない。図１
では、複数のサーバＳＲＶ（ｍ）（ｍ＝１，…，Ｍ）が
示されている。任意のサーバＳＲＶ（ｍ）は１以上の端
末に接続されてもよい。サーバＳＲＶ（１）に接続する
端末はＩＬＭＣ（ｎ）（ｎ＝１，…，Ｎ）と呼ばれる。
頭文字“ＩＬＭＣ”はInterLingua （商標名）Message
Clientから得られる。接続は参照符号４、５で示されて
いる。

【００５６】さらに、サーバＳＲＶ（１）はカスタマデ
ータベースＣＤＢ（１）に接続されている。１つのカス
タマデータベースＣＤＢ（１）が示されているが、必要
ならば１よりも多数のカスタマデータベースが与えられ
ることができる。

【００５７】端末ＩＬＭＣ（１）は図１でさらに詳細に
示されている。端末ＩＬＭＣ（１）はモニタスクリーン
６、処理装置１、キーボード12、マウス13を含んで示さ
れている。キーボード12とマウス13は処理装置１に接続
されている。勿論、ユーザによりデータを処理装置１に
入力するためのその他の既知の手段が、キーボード12と
マウス13の代わりにまたはそれらに加えて可能である。

【００５８】モニタスクリーン６は幾つかの“ボタン”
７、８、９、10、11を示している。これらのボタンは処
理装置１に予め定められたタスクを実行するように指令
するためにマウス13によりユーザにより付勢されること
ができる。このような予め定められたタスクはオプショ
ンを開くこと、接続の設定、メッセージの送信、メッセ
ージの受信および／またはデータを処理装置１のメモリ
に負荷することなどである。

【００５９】サーバＳＲＶ（１）には本発明の方法にし
たがってメッセージを受信、通過または送信するための
InterLingua （商標名）メッセージサーバＩＬＭＳと呼
ばれるプロセッサが設けられている。ＩＬＭＳプロセッ
サの部分はＩＳ（＝InterLingua （商標名）Script）で
示され、その機能を以下説明する。

【００６０】サーバＳＲＶ（１）はまた後述するよう
に、本発明による幾つかの表を記憶するためのデータベ
ースＩＬＭＤＢ（＝InterLingua （商標名）Message Da
tabase）を具備している。

【００６１】サーバＳＲＶ（１）は通信路２を経て相互
のサーバとの地点間の通信のために配置されている。通
信路２は任意の既知の方法、即ち有線または無線により
設定されることができる。

【００６２】図１は１以上の端末ＩＬＭＣに接続された
幾つかのその他のサーバＳＲＶ（ｍ）を示している。こ
れらのさらに別のサーバＳＲＶ（ｍ）は本発明にしたが
って組織され、以下さらに詳細に説明する。

【００６３】図２および図３のａ、ｂ、ｃ、ｄはメッセ
ージフォーマットを示している。図２では、メッセージ
フォーマットは、メッセージを受信する任意の装置によ
りメッセージ定義参照として使用される４つのフィール
ド、即ちＭＳＧ ＩＤ、ＭＳＧ クラス、ＭＳＧ バー
ジョン、ＭＳＧ クリエイタを含むように示されてい
る。

【００６４】フィールドＭＳＧ ＩＤはメッセージを識
別する。

【００６５】ＭＳＧ クラスは、メール、ビジネスメッ
セージ、注文または発送のようなメッセージのカテゴリ
またはタイプを指定するために使用される。

【００６６】フィールドＭＳＧ バージョンは関係する
メッセージのバージョン番号を識別するためのメッセー
ジバージョン識別子を有している。

【００６７】第４のフィールドＭＳＧ クリエイタは関
係するメッセージのクリエイタを識別するためのメッセ
ージクリエイタ識別子を具備している。

【００６８】ＭＳＧ ＩＤ、クラス、バージョンフィー
ルドは整数値である。例えばＭＳＧ クラス当たり1,00
0,000 ＭＳＧ ＩＤが存在し、10,000のＭＳＧ クラス
が存在する。ＭＳＧ ＩＤ毎に、ＭＳＧ クラス対は例
えば100 ＭＳＧ バージョンを有することができる。Ｍ
ＳＧ クラスは例えば、以下のように整列されてもよ
い。ＭＳＧ クラス１乃至２０はＩＬＭＳ用に保留され
る。ＭＳＧ クラス21乃至100 は発注、発送等のような
予め定められたカテゴリである。9900の残りのＭＳＧ
クラスはユーザ定義用である。ＭＳＧ クリエイタは例
えば８０個の文字符号を有する。これは自動転送を容易
にするために特定のユーザまたは企業により生成された
全体的なメッセージセットを識別することを目的とす
る。

【００６９】５つ以上のさらに別のフィールドと共に、
これらのメッセージ定義基準はメッセージへのヘッダを
形成する。これらの５つのさらに別のフィールドは送信
者 ＩＤ、目的地 アドレス、暗号 タイプ、圧縮 タ
イプ、アプリケーション 名称である。

【００７０】送信者 ＩＤは例えばｅメールアドレス
（即ちuser-xyz＠ilserver.com）に類似の方法で付加さ
れたサーバＳＲＶ（ｍ）の名称によりサーバＳＲＶ
（ｍ）により認識されるようなユーザ名称である。フィ
ールド 目的地 アドレスは関連するメッセージが送信
されるアドレスを識別するためのものである。目的地ア
ドレスは送信者 ＩＤと同一のフォーマットでもよい。

【００７１】フィールド 暗号 タイプは必要ならば与
えられた暗号化のタイプを参照するためのものである。
フィールド 圧縮 タイプは必要ならば、使用される圧
縮のタイプを示す。

【００７２】フィールドアプリケーション 名称は関連
するメッセージが、共に１つのアプリケーションを形成
する一連のメッセージのメンバであるか否かを示すため
に使用される。

【００７３】フィールド カウントは例えばメッセージ
で０から２５６のようにフィールド番号を与える。“フ
ィールド”とその内容はデータの特定のタイプとデータ
自体を意味する。カウントが０よりも大きいならば、実
際のフィールドデータはこのフィールドに従う。図３の
ａを参照して、フィールドはタイプ識別子、サイズ値、
内部識別用のフィールド名称、デフォルト表示用のフィ
ールドラベル、および同様にデフォルト表示用のフィー
ルド記述により限定される。後続するデータの長さはタ
イプおよびサイズフィールドの情報を結合することによ
り知られる。１つのフィールド定義は付加的なセパレー
タなしで直接的に相次いで後続する。

【００７４】特にＨＴＭＬタイプのデータでは非常に頻
繁に、２進イメージ、音響またはプログラムデータを含
んだローカルファイルの参照が存在する。これらの参照
された外部オブジェクトの正確な転送および参照を確実
にするために、これらは図２で示されているようにメッ
セージの端部で自動的にグループ化される。これらを参
照するフィールドはオブジェクトを指すように作られ
る。メッセージが受信されたとき、これらのオブジェク
トは自動的に局部的に記憶され、フィールド基準はそれ
らの新しい位置におけるオブジェクトをアクセスするよ
うに自動的に調節される。オブジェクト カウントフィ
ールドは０から２５６までメッセージのオブジェクトの
番号を与える。カウントが０よりも大きいならば、オブ
ジェクトデータはこのフィールドに従う。オブジェクト
は図３のｂで示されているように、好ましくはＭＩＮＥ
タイプ／内容識別子と、サイズ値と、実際のオブジェ
クト データにより限定される。１つのオブジェクト定
義は付加的なセパレータなしで直接的に相次いで後続す
る。

【００７５】図３のｃを参照すると、フィールドマッピ
ングは例えばフィールド 識別子、マッピング タイ
プ、マッピング データにより限定される。図３のｄが
示しているように、アクションは単にアクション デー
タが後続するアクション タイプにより限定されること
ができる。

【００７６】サーバＳＲＶキーを使用してデジタル署名
が全メッセージについて生成され、オブジェクトリスト
の最後に付加されることが好ましい。

【００７７】図２および図３のａ、ｂ、ｃ、ｄで定めら
れているような可能にされたデータタイプは例えば、 １）ユニコード文字符号ストリング、 ２）任意のサイズのコンピュータハードウェア独立整
数、 ３）ＩＥＥＥ ８バイトのフォーマット浮動小数点番
号、 ４）ユニバーサルリソースロケータ（ＵＲＬ）、 ５）ＧＩＦまたはＪＰＥＧフォーマットのイメージデー
タ、 ６）ＭＩＭＥ特定データ表示である。

【００７８】実際に、ＧＩＦとＪＰＥＧデータはまたＭ
ＩＭＥタイプとして含まれる。これらのフォーマットの
イメージに対する特定データタイプを生成するための決
定はディスプレイシステムのＨＴＭＬタイプでの使用頻
度により駆動された。最も普通に使用されるデータタイ
プはそれらの固有の定義を有する。付加的なデータタイ
プが、存在するＭＩＭＥタイプまたは特定のＭＩＭＥ拡
張として含まれることができる。これらのデータタイプ
は例によってのみ特定される。本発明の技術的範囲は好
ましいデータタイプにより限定されることを意図してい
ない。

【００７９】各メッセージは、その固有のデジタル署名
と任意選択的な暗号化および／または圧縮を有し、これ
はサーバＳＲＶ（ｍ）により自動的に管理される。

【００８０】メッセージデータベース フレキシブルなメッセージフォーマット定義と、管理
と、制御システムは以下のホルダとしての合理的なデー
タベースとしてデータベースＩＬＭＤＢを使用して設け
られる。即ち、 ａ）詳細なメッセージ定義； ｂ）メッセージマッピング命令： b.1 ）カスタマデータベースフィールドへのマッピン
グ、 b.2 ）フラットファイルフォーマットへのマッピング、 b.3 ）カスタマユーザインターフェイス（ＨＴＭＬ）フ
ィールドへのマッピング、 b.4 ）その他のメッセージフィールドへのマッピング ｃ）メッセージアクションリスト： （ＳＱＬ、Ｊａｖａ、計算、論理フロー、メッセージ
呼、外部プログラム呼） c.1 ）メッセージ事前処理動作、 c.2 ）メッセージ事後処理動作、 c.3 ）メッセージフィールドユーザインターフェイス事
象動作。

【００８１】この情報は合理的なデータベースＩＬＭＤ
Ｂの表に保持され、システムが任意のメッセージを十分
に解釈し処理することを可能にする。新しいメッセージ
定義が付加され、古い定義が変更されてもよい。メッセ
ージ定義は、直後にメッセージデータベースＩＬＭＤＢ
へ組込まれるように１つのサーバＳＲＶ（ｍ）から別の
サーバへ送信されてもよい。あらゆるフレキシブルメッ
セージフォーマットは、サーバＳＲＶ（ｍ）が以前に見
られていないメッセージを解釈してそのＩＬＭＤＢ中に
新しいメッセージ定義エントリを自動的に生成するのに
十分な自己記述情報をそれ自体に含んでいる。この新し
いメッセージ定義はシステム管理者により編集され、強
化されてもよく、それによって受信機システムへのマッ
ピングを完了する。

【００８２】メッセージデータはデータベースＩＬＭＤ
Ｂに維持されず、定義のみ維持される。メッセージデー
タはディスク記憶システム上の圧縮ファイルに維持され
る。これらのファイルはシステム管理者により選択され
る選択期間にサーバメッセージにしたがって周期的にア
ーカイブされるか消去される。

【００８３】受信されたまたは送信されるメッセージを
限定し、制御するために必要とされるデータベースＩＬ
ＭＤＢ内の主な関連表を以下示す。 表の名称 説明 msgdef InterLingua （商標名）メッセージ定義 flddef メッセージフィールド定義 fldmap フィールドマッピング fldact フィールド動作定義（フィールド当り１動作） magpre メッセージ事前処理（メッセージアクションのシーケンス） msgpost メッセージ事後処理（メッセージアクションのシーケンス） システムディベロッパは、システム全体をさらに容易に
使用可能にし、二次的なシステム特性を制御するために
必要な関連情報についてのその他の表が多数存在するこ
とを認識するであろう。その例にはユーザの口座および
ユーザ情報、システム管理およびシステムセキュリティ
に関連する全ての表が含まれる。ここで示した表は、好
ましい実施形態にしたがって本発明を実行するのに必要
なコアとなる表であり、拡張および強化は同様に本発明
の技術的範囲内であると考慮される。

【００８４】表：msgdef この表は主なメッセージの定義を保持する役目を行う。
メッセージはこの表の第１の４つのフィールドにより完
全に識別され、これはまたメッセージヘッダ （図２参
照）にも存在する。第５のフィールド（msysid）はサー
バプロセッサＩＬＭＳにより内部的に割り当てられる識
別子であり、データベース内のその他の表の識別とその
迅速なアクセスとして使用される。

【００８５】 フィールド名称 タイプ 説明 msgid 整数 メッセージ識別子 msgver 整数 メッセージバージョン msgclass 整数 メッセージクラス creatid char クリエイタ識別子 msysid 整数 メッセージシステムＩＤ creatdate 日付 作成した日付 usedate 日付 使用した日付 これらの２つのフィールドはメッセージがどの程度長く
ＩＬＭＳにより記憶されたかを制御する。 durdays 整数 継続日数 durmins 整数 継続した分数 これらの２つのフィールドは暗号化およびデジタル署名
アルゴリズムのタイプを識別する。 encrtype char 暗号化タイプ sigtype char デジタル署名タイプ このフィールドはメッセージが表示するためのものであ
るか否かを示す。 silent ブール メッセージサイレントフラグ このフィールドはメッセージがアクションを初期化また
はそれに応答できるか否かを示す。 active ブール 処理エネーブルフラグ msgicon char （ILMC表示用の）メッセージアイコン ファイル msghtml char （ILMC表示用の）メッセージＨＴＭＬ ファイル このフィールドはメッセージがアプリケーションの最初
にあるか否かを示す。 appmain ブール アプリケーションメインフラグ このフィールドはメッセージがアプリケーションの一部
であるならば名称を含んでいる。 appname char アプリケーション名称 descr char メッセージ記述 表：flddef この表は全てのメッセージの全てのフィールドの主な定
義を保持する役目を行う。フィールドは“msgdef”表で
割当てられた“msysid”によって、特別に識別され、フ
ィールドシーケンス番号（fldseq）またはフィールド名
称（fldname ）である。

【００８６】 フィールド名称 タイプ 説明 msysid 整数 メッセージシステムＩＤ fldseq 整数 フィールドシーケンス fldname char フィールド名称 これらの３つのフィールドは１、２（表）または３次元
アレイの生成に使用される。 ar１ 整数 アレイディメンション１ ar２ 整数 アレイディメンション２ ar３ 整数 アレイディメンション３ fldtype char フィールドデータタイプ フィールドサイズはデータタイプに基づいて異なる解釈
をされる。 fldsize 整数 フィールドサイズ このフィールドはこれがデータ構造として別のメッセー
ジに対する基準である場合に使用される。 smsysid 整数 サブメッセージシステムＩＤ これらの２つのフィールドはフィールドがＭＩＭＥデー
タを含んでいる場合に使用される。 mimecont char ＭＩＭＥ内容識別子 mimetype char ＭＩＭＥタイプ識別子 fldlabel char （ILMC表示用の）フィールドラベル fldcom char （ILMC表示用の）フィールドコメント 表：fldmap この表はフィールドが使用するマッピング情報を保持す
る役目を行う。この表はデータベースフィールド、フラ
ットファイルフィールド、その他のメッセージフィール
ドに対するマッピングを規定できる。フィールドは表
“flddef”と同じ方法で識別される。フィールドがアレ
イとして規定される場合を除いて、各フィールドで可能
にされたデータ用の１つのマッピングと表示用の１つの
マッピングが存在する。データおよびディスプレイマッ
ピングは１以上の素子またはアレイの行ディメンション
に割当てられることができる。

【００８７】 フィールド名称 タイプ 説明 msysid 整数 メッセージシステムＩＤ fldseq 整数 フィールドシーケンス fldname char フィールド名称 これらの３つのフィールドは特定のアレイ素子または行
寸法へのマッピングを可能にする。 ar１ 整数 アレイディメンション１ ar２ 整数 アレイディメンション２ ar３ 整数 アレイディメンション３ このフィールドはデータが同じメッセージ文脈内の最も
最近のアクティブな先のメッセージから転送されること
を可能にし、これは特定のユーザ接続の現在アクティブ
なメッセージのセットである。 cpyfld char （Msg からの）コピーフィールド 次の３つのフィールドはＳＱＬアクセス可能な合理的デ
ータベースの特定のフィールドを特定するために使用さ
れる。 dbnam char データベース名称 tbInam char 表の名称 fldnam char フィールド名称 このフィールドは表示用のＨＴＭＬファイル（msgdef.m
sghtml）のフィールドを特定する。 tagnam char ＨＴＭＬタグ名称 次の２つのフィールドは固定した長さのフィールドのフ
ラットファイルまたはカンマで分離された値を特定す
る。 flatfile char フラットファイル名称 filetype char ファイルタイプ（固定した、ＣＳＶ） 次の４つのフィールドはフラットファイルのフィールド
位置を特定する。

【００８８】 rowbegin 整数 行の開始 colbegin 整数 列の開始（またはＣＳＶのフィールド＃） rowend 整数 行の終了 colend 整数 列の終了 表：fldact この表はフィールドが使用する動作情報を保持する役目
を行う。アクションは動作のデータベースタイプと動作
の論理タイプであってもよい。フィールドが１つのアレ
イとして規定される場合を除いて、フィールド当たり１
つのアクションが存在する。アクションは１以上の素子
または１つのアレイの行ディメンションに対して割当て
られることができる。

【００８９】 フィールド名称 タイプ 説明 msysid 整数 メッセージシステムＩＤ fldseq 整数 フィールドシーケンス fldname char フィールド名称 ar１ 整数 アレイディメンション１ ar２ 整数 アレイディメンション２ ar３ 整数 アレイディメンション３ このフィールドは動作タイプ、即ちＳＱＬまたはＩＳ、
ファイルまたはローカルを限定する。 acttype char アクションタイプ このフィールドはＳＱＬ、ＩＳまたは内容がＳＱＬまた
はＩＳであるファイル名を含んでいる。 actscript char アクションスクリプト 表：msgpreとmsgpost ２つの表msgpreとmsgpostは同一構造を有する。表“msg
pre”は特定のメッセージの事前処理としてサーバプロ
セッサＩＬＭＳにより実行されるアクションのリストを
保持する。これは任意のディスプレイまたはフィールド
アクションが行われる前に、サーバプロセッサＩＬＭＳ
がリストまたは事前処理機能を完了することを意味す
る。表“msgpost ”は特定のメッセージの事前処理とし
てサーバプロセッサＩＬＭＳにより実行されるアクショ
ンのリストを保持する。これは全てのその他のメッセー
ジアクションおよびディスプレイの終了後に、サーバプ
ロセッサＩＬＭＳが主メモリからメッセージを削除する
前に事後処理機能のリストを完了することを意味する。
このプロセスのシーケンス番号はアクションのリストの
制御された実行を生成するために使用される。先のシー
ケンス番号は次のシーケンス番号が開始できる前に完了
しなければならない。同一のシーケンス番号を有する動
作が１よりも多数存在するならば、これらは同一の時
間、または多数のＣＰＵ内、または真の並列処理として
多数の並列環境で開始される。

【００９０】表：msgore フィールド名称 タイプ 説明 msysid 整数 メッセージシステムＩＤ procseq 整数 処理シーケンス 次のフィールドは動作タイプ、即ちＳＱＬまたはＩＳ、
ファイルまたはローカルを限定する。 proctype char 事前処理のタイプ 次のフィールドはＳＱＬ、ＩＳまたは内容がＳＱＬまた
はＩＳであるファイル名を含んでいる。 procscript char 事前処理スクリプト 表：msgpost フィールド名称 タイプ 説明 msysid 整数 メッセージシステムＩＤ procseq 整数 処理シーケンス 次のフィールドは動作タイプ、即ちＳＱＬまたはＩＳ、
ファイルまたはローカルを限定する。 proctype char 事後処理タイプ 次のフィールドはＳＱＬ、ＩＳまたは内容がＳＱＬまた
はＩＳであるファイル名を含んでいる。 procscript char 事後処理スクリプト InterLingua （商標名）Script（アクションの定義およ
び制御言語） メッセージ事前処理、事後処理用の動作またはフィール
ド動作はＳＱＬ動作またはＩＳ動作である。ＳＱＬ（構
成された問合わせ言語）は合理的なデータベース用のＡ
ＮＳＩ標準インターフェイス言語である。ＩＳ（InterL
ingua （商標名）Script）はサーバプロセッサＩＬＭＳ
（図１参照）の予め定められた部分であり、小さいが、
強力な計算、実行、メッセージに対するアプリケーショ
ンレベルの機能を与える条件論理ステートメントのセッ
トである。好ましい実施形態では、ＩＳ定義は以下のよ
うになる。

【００９１】計算 加算（＋）、減算（−）、乗算（＊）、除算（／）の動
作は整数と浮動小数点値で可能にされる。括弧“（）”
は数学的動作のグループ化を可能にする。

【００９２】割当 割当（＝）は整数、浮動小数点値、ストリングおよびＵ
ＲＬに対して可能にされる。

【００９３】論理および条件 （ＡＮＤ）または（ＯＲ）、よりも大きい（＞）、より
も小さい（＜）、以上（＞＝）、以下（＜＝）、等しい
（＝）、等しくない（！＝）、否定（！）は整数、浮動
小数点値、ストリングおよびＵＲＬに対して可能にされ
る。

【００９４】制御フロー END-MSG− メッセージの終了。それに固有の事前処理
リストからの最後の命令でなければならない。 END-APP− アプリケーションの終了。メンバメッセー
ジ事後処理リストからの最後の命令でなければならな
い。 Ｆｏｒ Ｌｏｏｐ： FOR i=x TO y BEGIN ＜ステートメント＞ END Ｗｈｉｌｅ Ｌｏｏｐ： WHILE＜条件＞ BEGIN ＜ステートメント＞ END Ｉｆ−Ｔｈｅｎ−Ｅｌｓｅ： IF ＜条件＞THEN BEGIN ＜ステートメント＞ END ELSE BEGIN ＜statements＞ END 命令 マップされたフィールドデータのロード： LOAD{WHERE＜external field name＞=＜value＞} マップされたフィールドデータの記憶： STORE{WHERE＜external field name＞=value＞} 外部プログラムの実行： CALL{JAVA ｜EXEC｜SHELL}＜program name＞＜paramete
r I＞ …＜parameter n＞ メッセージの実行： ILMP://＜host-name＞/＜message id＞ 内部機能の実行（これはほとんどユーザインターフェイ
ス事象で使用される） ILMP://＜host-name＞/＜message id＞/＜field id＞[U
I-ACT ｜MSG-END ｜APP-END] ILMP://＜host-name＞/＜message id＞/＜field id＞[A
DD-DATA ｜DEL-DATA｜CHG-DATA]＜data＞ アプリケーション InterLingua （商標名）メッセージの集合は共にグルー
プ化され、特有の名称を付けられ、InterLingua （商標
名）アプリケーションとして使用されることができる。
この説明の目的で、任意のプログラミング言語またはシ
ステムプラットフォームに対して、アプリケーションは
１以上の機能であるとして定義され、その動作シーケン
スは入力データとユーザとシステム事象とに基づいて変
化し、これは外部記憶装置をアクセスして、それと対話
することができ、ユーザインターフェイスを経てユーザ
と対話できる。

【００９５】この名称を付けられたメッセージのセット
の全てまたはその一部は１以上の位置の１以上のサーバ
ＳＲＶ（ｍ）に存在してもよい。この名称を付けられた
メッセージのセットまたはアプリケーションは、 ａ）指示された一連の機能と、 ｂ）ローカルおよび共有データと、 ｃ）ユーザインターフェイススクリーンと、 ｄ）回路網にされた分配アプリケーション機能とを実行
する。

【００９６】指示された一連の機能は、データベースの
問合わせ、計算および付加的なメッセージの付勢等の任
意の動作タイプを含んでもよい。この文脈のメッセージ
の付勢はアプリケーション機能の呼出しと、次のユーザ
インターフェイススクリーンの表示、または勿論ローカ
ルまたは外部回路網目的地へのメッセージの送信に匹敵
するものに使用されることができる。動作順序の実時間
の構成されたフロー、換言すると、指示された一連の機
能は、メッセージアクションのリストと、フィールドま
たはボタンのマウス選択のようなユーザインターフェイ
スにより生成される事象アクションにより決定される。

【００９７】ローカルおよび共有データは任意の許容さ
れたデータタイプを含んでいる。これらのデータタイプ
はデータ構造にグループ化されてもよい。このメッセー
ジデータはユーザデータベースとユーザインターフェイ
スへまたはそれらからマップされ、その他のメッセージ
へ通過されてもよい。この概念はその固有のローカルデ
ータを有する機能としてメッセージを使用し、任意のロ
ーカルデータを通過するその他の機能（メッセージ）を
呼出すこともできる。このローカルデータは共有データ
になる２以上のメッセージ間を通過される。

【００９８】ネットワークで結ばれた分散されたアプリ
ケーション機能は、InterLingua （商標名）クライアン
トＩＬＭＣ（ｎ）とメッセージ送信者および受信者とし
てのサーバ固有の能力を使用して実行される。アプリケ
ーションセットが１人のサーバの１つのアプリケーショ
ンと対照的に、幾つかのサーバを横切って分散された方
法で作用されるように生成されるならば、主な差は、ア
プリケーション機能として動作する１以上のメッセージ
がローカルサーバではなく目的地として遠隔サーバを有
することである。これは以前には見られなかった簡潔性
とフレキシブル性で、ネットワークにされた分配アプリ
ケーションの生成を非常に簡単にする。

【００９９】InterLingua （商標名）Message Client
（ILMC）とサーバＳＲＶ InterLingua （商標名）Message Client（ILMC）のソフ
トウェアは好ましくはＪａｖａにおいて全体的に書込ま
れ、したがって、これはほとんど全ての最も共通して使
用されるコンピュータを含むＪａｖａエネーブルコンピ
ュータシステムで動作できることを確実にする。ＩＬＭ
Ｃは、ＨＴＭＬ／ＶＲＭＬ／Ｊａｖａアプレットディス
レイコンソールとして、およびサーバＳＲＶ（ｍ）への
回路網通信インターフェイスとして機能する。

【０１００】ユーザインターフェイススクリーンは、メ
ッセージをＨＴＭＬ定義に関連づけメッセージとＨＴＭ
Ｌディスプレイとの間にデータをマップする能力を使用
する。これは選択された機能（メッセージ）が必要なと
きにユーザインターフェイスを有することを可能にす
る。ユーザキーボードとマウス事象はフィールドアクシ
ョンに連結される。

【０１０１】１つのサーバから別のサーバへ、サーバと
端末ＩＬＭＣ間でメッセージの送信／受信機能を実行す
る通信サブシステムは高度に最適化され、マルチスレッ
ド方法で動作するように設計され、メッセージの完全性
を監視するチェックサムの使用をデジタル署名の使用と
置換する。これは受信されたメッセージの崩壊されてい
ない状態の完全な確認を可能にし、同時に送信者のアイ
デンティティのセキュリティ確証と認証を可能にする。
通信サブシステムはサーバＳＲＶと端末ＩＬＭＣとの両
方に存在する。通信サブシステムは回路網プロトコル独
立であるように設計される。現在のバージョンではＴＣ
Ｐ／ＩＰ、ＸＴＰ／ＩＰ、ＸＴＰ／ＡＴＭ／ＡＡＬ５で
動作するがＡｐｐｌｅＴａｌｋ、ＩＰＸ、ＳＮＡ、Ｘ．
25、ＤＥＣＮＥＴ、ＯＳＩまたはソケットインターフェ
イスと地点を結ぶアドレススキームを使用できるその他
の任意のプロトコルで丁度同じように容易に動作する。

【０１０２】通信サブシステムは本発明の臨界的な部分
ではない。本発明の進歩は多数の異なるタイプの通信サ
ブシステムにわたって実行されることができる。当業者
は、通信サブシステムが高速度の転送の成功とデータの
完全性を保証できる信頼性のある転送プロトコルを有す
る限り、選択された回路網通信サブシステムのタイプお
よび構成の詳細が本発明の機能を変更しないことを認識
するであろう。

【０１０３】欧州特許出願第97202945号明細書、即ち本
発明の優先日後に公開されたEP-A-0905949号明細書に記
載されているようなメッセージ優先スケジューリングお
よびサービス機構が通信サブシステムに付加されてもよ
い。この機構は全てのメッセージ優先順位レベルに対し
て公平なサービスを自動的に保証するために、個々の優
先順位レベルと簡単な回路網とシステムバッファリング
アルゴリズムに対する別々の接続を使用する。この機構
は、メッセージサイズを監視し、または低い優先順位の
メッセージのロックアウトを防止するために複雑なスケ
ジューリングアルゴリズムを必要とすることなく、高い
優先順位のメッセージをさらに高速度で一貫して転送す
る。

【０１０４】メッセージの受信 メッセージがサーバＳＲＶ（ｍ）により受信されると
き、これは通信サブシステムを通過する。デジタル署名
は確認され、転送層ヘッダはストリップされる。メッセ
ージが暗号化または圧縮されているならば、それはこの
とき解読され圧縮から復元される。メッセージは、デー
タベースソフトウェアＩＬＭＤＢに送られる。

【０１０５】メッセージ定義が所望位置にないならば、
全体的なデータベースメッセージ定義は特定のメッセー
ジまたはメッセージグループで自動的に交換されてもよ
く、それによって多数のユーザの容易に交換された共通
のフォーマットメッセージを生成する。

【０１０６】その代わりに、メッセージ定義が受信され
たメッセージに存在しないならば、システム管理者のイ
ンボックスに送信される。システム管理者はその後、端
末ＩＬＭＣを使用してメッセージを検査し、自動的に基
本的なメッセージ定義を付加し、必要なときにメッセー
ジフィールドをローカルデータベースフィールドとＨＴ
ＭＬディスプレイフィールドに連結することができる。
システム管理者はまた、メッセージの送信者が完全なメ
ッセージ定義を送信することを自動的にリクエストして
もよく、完全なメッセージ定義はローカルデータベース
ＩＬＭＤＢに自動的に位置付けられる。このリクエスト
は１つのサーバから別のサーバへのメッセージとして送
出される。

【０１０７】メッセージ定義が受信されたメッセージに
存在するならば、これはデータベースＩＬＭＤＢから読
取られる。メッセージ事前処理のアクションリストはサ
ーバＳＲＶ（ｍ）により実行され、メッセージフィール
ドの確認、データベースの問合わせ、計算およびその他
のメッセージ等の機能を定める。メッセージが表示のた
めにユーザに送信されたならば、端末ＩＬＭＣのプロセ
ッサ１はそのメッセージを指示されたＨＴＭＬファイル
に組込むか、または指示されたＨＴＭＬファイルがプロ
セッサ１により発見されないならば、デフォルトダイナ
ミックＨＴＭＬを生成する。フィールドアクションはこ
れらがメッセージで規定されているならば、特別なマウ
スおよびキーボード事象により付勢されてもよい。フィ
ールドアクションは標準的なＨＴＴＰ ＵＲＬを呼出
し、ローカルイメージの表示のリクエストを送信し、Ｓ
ＱＬデータベーストランザクションを付勢し、ローカル
ディスプレイデータを更新し、またはInterLingua （商
標名）Script（ＩＳ）命令を動作する。メッセージが限
定されたユーザインターフェイスをもたないならば、
“サイレント”として呼ばれ、システム中のその存在は
システム管理者によってのみ観察されることができる。

【０１０８】サイレントメッセージの事前処理の終了と
きに、およびＥＮＤ−ＭＳＧ命令または端末メッセージ
に遭遇したとき、ユーザインターフェイスはＥＮＤ−Ｍ
ＳＧ命令を送信しメッセージ事後処理アクションのリス
トがサーバＳＲＶ（ｍ）により実行される。メッセージ
がアプリケーションセットの一部であるならば、これは
サーバＳＲＶ（ｍ）がＥＮＤ−ＡＰＰに遭遇または受信
するまで、アクティブで、メモリ中に残される。アプリ
ケーションセットが終了したとき、これらがまだ実行さ
れていないならば、全てのメンバメッセージ事後処理リ
ストはサーバＳＲＶ（ｍ）により実行される。この機能
はまたトランザクション文脈とアプリケーションデータ
および状態の自動メンテナンスを保証する。１つのメッ
セージまたはアプリケーションセットが完了したとき、
システムメモリはクリーンにされ、他のメッセージおよ
びアプリケーションにより使用されるように戻される。

【０１０９】メッセージの送信 端末ＩＬＭＣから： メッセージフォーマット（ＩＬＭＦ）がリクエストさ
れ、ＩＬＭＤＢ／−ＩＬＭＳから受信される。メッセー
ジの内容およびアドレスは端末ユーザにより付加され
る。端末ユーザはユーザインターフェイス動作により、
ユーザが登録されているサーバへのメッセージの送信を
開始する。

【０１１０】サーバＳＲＶ（ｍ）から： メッセージは、InterLingua （商標名）Script（ＩＳ）
によりサーバＳＲＶ（ｍ）上のメッセージを付勢するた
め直接的な呼出しの結果として自動的に開始されてもよ
く、またはサーバＳＲＶ（ｍ）により最初に受信および
処理される接続された端末のリクエストであってもよ
い。サーバは任意のメッセージが定められているなら
ば、メッセージの事前処理を実行する。目的地アドレス
がサーバ自体のためのものであるならば、ＥＮＤ−ＭＳ
Ｇに遭遇後または受信後にメッセージの事後処理が実行
され、メッセージが完了される。目的地アドレスが別の
サーバのためのものであるならば、メッセージは通信サ
ブシステムに送られ、圧縮されまたは暗号化され、デジ
タル署名が与えられ、地点間を結ぶ接続により受信サー
バへ送信される。

【０１１１】頭文字のリスト ＡＮＳＩ＝American National Standard Institute ＣＯＲＢＡ＝Common Object Request Broker Architect
ure ＣＳＶ＝Comma Separated Value ＥＤＩ＝Electronic Data Interchange ＧＩＦ＝Graphics Interchange Format ＨＴＭＬ＝Hyper Text Markup Language ＨＴＴＰ＝Hyper Text Transfer Protocol ＩＬＭＣ＝InterLingua （商標名）Message Client ＩＬＭＤＢ＝InterLingua （商標名）Message Database ＩＬＭＦ＝InterLingua （商標名）Message Format ＩＬＭＰ＝InterLingua （商標名）Message Protocol ＩＬＭＳ＝InterLingua （商標名）Message Server ＩＳ＝InterLingua （商標名）Message Script ＪＤＢＣ＝Java DataBase Connectivity ＪＰＥＧ＝Joint Photographers Expert Group ＭＩＭＥ＝Muli-purpose Ineternet Mail Extensions ＯＤＢＣ＝Open DataBase Connectivity ＲＤＢＭＳ＝Relational DataBase Managment Systems ＳＮＭＰ＝Simple Network Management Protocol ＳＱＬ＝Structured Query Language ＵＲＬ＝Universal Resource Locator ＶＲＭＬ＝Virtual Reality Markup Language ［図面の簡単な説明］

【図１】本発明によるシステムの概観ブロック図。

【図２】本発明によるメッセージフォーマット図。

【図３】本発明によるメッセージフォーマット図。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ブランク、チップ オランダ国、エヌエル − 4823 イー イー・ブレダ、グローテ・ディーク 55 (56)参考文献 特開 平９−23224（ＪＰ，Ａ) 特開 平９−23225（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 29/06

Claims (28)

(57)【特許請求の範囲】
1. 【請求項１】 フレキシブルなメッセージフォーマット
   （ＩＬＭＦ）を有するメッセージにより送信側（ＳＲＶ
   （ｍ））と受信側（ＳＲＶ（ｍ））との間の地点間通信
   方法において、メッセージはそれぞれ、 少なくともメッセージ定義基準（ＭＳＧ ＩＤ，ＭＳＧ
   クラス．ＭＳＧバージョン，ＭＳＧクリエイタ）と、送
   信者識別子と、目的地アドレスからなるヘッダと、 ＊フィールド番号（フィールドカウント）および任意の
   フィールドの内容（フィールド（１），…）とを含み、 さらにメッセージ内容は、 ＊１以上のフィールドにより参照されるオブジェクトの
   番号（オブジェクトカウント）および任意のオブジェク
   トの内容（オブジェクト（１），…）と、 ＊フィールドマッピング番号および予め定められたフィ
   ールドにより使用可能な任意のフィールドマッピングの
   内容と、 ＊アクション番号および、少なくとも予め定められたフ
   ィールドにより使用可能な任意のアクションの内容を有
   することを特徴とし、 通信方法はさらに、 メッセージ定義表（ｍｓｇｄｅｆ）とフィールド定義表
   （ｆｌｄｄｅｆ）とマッピング指令（ｆｌｄｍａｐ）と
   メッセージアクションリスト（ｆｌｄａｃｔ，ｍｓｇｐ
   ｒｅ，ｍｓｇｐｏｓｔ）とを記憶するデータベース（Ｉ
   ＬＭＤＢ）を使用して前記メッセージを解釈し処理する
   ステップをさらに含んでいることを特徴とする通信方
   法。
2. 【請求項２】 前記メッセージ定義基準は任意のメッセ
   ージを識別するためのメッセージ識別子（ＭＳＧ Ｉ
   Ｄ）を含んでいる請求項１記載の方法。
3. 【請求項３】 前記メッセージ定義基準は、メール、ビ
   ジネスメッセージ、注文または発注のような任意のメッ
   セージに対するメッセージのクラスを識別するためのメ
   ッセージクラス識別子（ＭＳＧクラス）を含んでいる請
   求項１または２記載の方法。
4. 【請求項４】 前記メッセージ定義基準は任意のメッセ
   ージのバージョン番号を識別するためのメッセージバー
   ジョン識別子（ＭＳＧバージョン）を含んでいる請求項
   １乃至３のいずれか１項記載の方法。
5. 【請求項５】 前記メッセージ定義基準は任意のメッセ
   ージのクリエイタを識別するためのメッセージクリエイ
   タ識別子（ＭＳＧ クリエイタ）を具備している請求項
   １乃至４のいずれか１項記載の方法。
6. 【請求項６】 前記ヘッダは、与えられたタイプの暗号
   化（暗号タイプ）の基準を含んでいる請求項１乃至５の
   いずれか１項記載の方法。
7. 【請求項７】 前記ヘッダは、与えられたタイプの圧縮
   （圧縮タイプ）の基準を含んでいる請求項１乃至６のい
   ずれか１項記載の方法。
8. 【請求項８】 前記ヘッダは、任意のメッセージが前記
   アプリケーションを共に形成する一連のメッセージのメ
   ンバであるか否かを示すためのアプリケーション（アプ
   リケーション名称）の基準を含んでいる請求項１乃至７
   のいずれか１項記載の方法。
9. 【請求項９】 任意の前記メッセージはデジタル署名を
   具備している請求項１乃至８のいずれか１項記載の方
   法。
10. 【請求項１０】 フレキシブルなメッセージフォーマッ
    ト（ＩＬＭＦ）を有するメッセージにより別の通信装置
    （ＳＲＶ（ｍ））との地点間通信を行うように配置され
    ている処理手段（ＩＬＭＳ）およびデータベース（ＩＬ
    ＭＤＢ）を具備する通信装置において、 前記メッセージは、 少なくともメッセージ定義基準（ＭＳＧ ＩＤ，ＭＳＧ
    クラス．ＭＳＧバージョン，ＭＳＧクリエイタ）と、送
    信者識別子と、目的地アドレスとからなるヘッダと、 ＊フィールド番号（フィールドカウント）および任意の
    フィールドの内容（フィールド（１），…）と、 ＊１以上のフィールドにより参照されるオブジェクトの
    番号（オブジェクトカウント）および任意のオブジェク
    トの内容（オブジェクト（１），…）と、 ＊フィールドマッピング番号および予め定められたフィ
    ールドにより使用可能な任意のフィールドマッピングの
    内容と、 ＊アクション番号および、少なくとも予め定められたフ
    ィールドにより使用可能な任意のアクションの内容とを
    少なくとも含んでいるメッセージ内容を含み、 前記データベース（ＩＬＭＤＢ）は、予め定められたメ
    ッセージ定義表（ｍｓｇｄｅｆ）とフィールド定義表
    （ｆｌｄｄｅｆ）とマッピング指令（ｆｌｄｍａｐ）と
    メッセージアクションリスト（ｆｌｄａｃｔ，ｍｓｇｐ
    ｒｅ，ｍｓｇｐｏｓｔ）とを記憶し、 前記処理手段（ＩＬＭＳ）は、前記予め定められたメッ
    セージ定義表を参照して前記メッセージ定義基準を使用
    して前記データベース（ＩＬＭＤＢ）中に記憶されてい
    る前記予め定められたメッセージ表と、マッピング情報
    （ｆｌｄｍａｐ）と、メッセージアクションリストを調
    べながらメッセージを解釈し処理するように構成されて
    いることを特徴とする装置。
11. 【請求項１１】 前記予め定められたメッセージ定義表
    （ｍｓｇｄｅｆ）は任意のメッセージを識別するための
    メッセージ識別子（ｍｓｇｉｄ）を含んでいる請求項１
    ０記載の通信装置。
12. 【請求項１２】 前記予め定められたメッセージ定義表
    （ｍｓｇｄｅｆ）はメール、ビジネスメッセージ、注文
    または発注のような任意のメッセージのメッセージクラ
    スを識別するためのメッセージクラス識別子（ｍｓｇｃ
    ｌａｓｓ）を含んでいる請求項１０または１１記載の通
    信装置。
13. 【請求項１３】 前記予め定められたメッセージ定義表
    （ｍｓｇｄｅｆ）は任意のメッセージのバージョン番号
    を識別するためのメッセージバージョン識別子（ｍｓｇ
    ｖｅｒ）を含んでいる請求項１０乃至１２のいずれか１
    項記載の通信装置。
14. 【請求項１４】 前記予め定められたメッセージ定義表
    （ｍｓｇｄｅｆ）は任意のメッセージのクリエイタを識
    別するためのメッセージクリエイタ識別子（ｃｒｅａｔ
    ｉｄ）を含んでいる請求項１０乃至１３のいずれか１項
    記載の通信装置。
15. 【請求項１５】 前記予め定められたメッセージ定義表
    （ｍｓｇｄｅｆ）は与えられたタイプの暗号化（ｅｎｃ
    ｒｔｙｐｅ）の基準を含んでいる請求項１０乃至１４の
    いずれか１項記載の通信装置。
16. 【請求項１６】 前記予め定められたメッセージ定義表
    （ｍｓｇｄｅｆ）は与えられたデジタル署名タイプ（ｓ
    ｉｇｔｙｐｅ）の基準を含んでいる請求項１０乃至１５
    のいずれか１項記載の通信装置。
17. 【請求項１７】 前記予め定められたメッセージ定義表
    （ｍｓｇｄｅｆ）は前記データベース（ＩＬＭＤＢ）中
    のさらに別の表を基準として使用するためのメッセージ
    システム識別子（ｍｓｙｓｉｄ）を含んでいる請求項１
    ０乃至１６のいずれか１項記載の通信装置。
18. 【請求項１８】 前記さらに別の表は前記メッセージの
    任意のフィールドの主要な定義を保持するためのフィー
    ルド定義表（ｆｌｄｄｅｆ）を有している請求項１７記
    載の通信装置。
19. 【請求項１９】 前記さらに別の表は、例えばハイパー
    テキストマークアップ言語フィールド、データベースフ
    ィールド、フラットファイルフィールドおよびその他の
    メッセージフィールドヘマッピングするための予め定め
    られたフィールドにより使用可能な前記マッピング指令
    を含むフィールドマッピング表（ｆｌｄｍａｐ）を有し
    ており、前記データベースフィールドおよびフラットフ
    ァイルフィールドはカスタマのデータベース（ＣＤＢ）
    中に記憶される請求項１７または１８記載の通信装置。
20. 【請求項２０】 前記さらに別の表は、予め定められた
    フィールドにより使用可能なアクション情報を含むフィ
    ールドアクション表（ｆｌｄａｃｔ）を有している請求
    項１７乃至１９のいずれか１項記載の通信装置。
21. 【請求項２１】 前記さらに別の表は、受信または送信
    されたメッセージの前処理として実行されるアクション
    のリストを含むメッセージ前処理表（ｍｓｇｐｒｅ）
    と、受信されたメッセージに対する後処理として実行さ
    れるアクションのリストを含むメッセージ後処理表（ｍ
    ｓｇｐｏｓｔ）とを有している請求項１７乃至２０のい
    ずれか１項記載の通信装置。
22. 【請求項２２】 前記フィールドアクション表（ｆｌｄ
    ａｃｔ）と、前記メッセージ前処理表（ｍｓｇｐｒｅ）
    と、前記メッセージ後処理表（ｍｓｇｐｏｓｔ）は、数
    学的計算、割当、論理演算、条件演算、命令を含むアク
    ションのデータベースタイプおよびアクションの論理タ
    イプのグループから選択されたアクションタイプの基準
    を含んでいる請求項２１記載の通信装置。
23. 【請求項２３】 前記メッセージ定義表（ｍｓｇｄｅ
    ｆ）は受信されたメッセージがアプリケーションの第１
    のメッセージであるか否かを示すアプリケーションフィ
    ールド（ａｐｐｍａｉｎ）と前記アプリケーションの名
    称を参照するためのアプリケーション名称フィールド
    （ａｐｐｎａｍｅ）とを含んでおり、それによってデー
    タメッセージおよびそれらの関連するアクションの集収
    としてアプリケーションを規定する請求項１０乃至２２
    のいずれか１項記載の通信装置。
24. 【請求項２４】 前記アプリケーションは複数の通信装
    置にわたって分配された分配アプリケーションである請
    求項２３記載の通信装置。
25. 【請求項２５】 受信されたメッセージがデータベース
    （ＩＬＭＤＢ）に存在しないメッセージ定義を参照にす
    る場合には、前記装置は送信者からの新しいメッセージ
    定義をリクエストし、前記送信者から前記新しいメッセ
    ージ定義を受信し、これを前記データベース（ＩＬＭＤ
    Ｂ）中の前記メッセージ定義表（ｍｓｇｄｅｆ）に記憶
    する請求項１０乃至２４のいずれか１項記載の通信装
    置。
26. 【請求項２６】 先に見えなかったメッセージを解釈
    し、前記データベース（ＩＬＭＤＢ）中に新しいメッセ
    ージ定義エントリを生成するように構成されている請求
    項１０乃至２４のいずれか１項記載の通信装置。
27. 【請求項２７】 前記処理手段（ＩＬＭＳ）は受信され
    たメッセージを指示されたＨＴＭＬファイルに組込み、
    また、指示されたＨＴＭＬファイルが前処理手段（ＩＬ
    ＭＳ）により発見されない場合には、デフォルトダイナ
    ミックＨＴＭＬファイルを生成するように構成されてい
    る請求項１０乃至２６のいずれか１項記載の通信装置。
28. 【請求項２８】 端末は端末プロセッサ（１）と、ディ
    スプレイ装置（６）と、ユーザによりデータを入力する
    ための入力手段（12、13）とを具備し、通信装置は、前
    記端末が目的地アドレスをメッセージで示されたとき前
    記端末で受信されるメッセージを通過するように構成さ
    れ、前記端末プロセッサ（１）はメッセージを指示され
    たＨＴＭＬファイルへ組込み、また、指示されたＨＴＭ
    Ｌファイルが端末プロセッサ（１）により発見されなか
    った場合にはデフォルトダイナミックＨＴＭＬを生成す
    るように構成されている請求項１０乃至２６記載のいず
    れか１項記載の通信装置（ＳＲＶ（ｍ））および前記通
    信装置に接続される端末（ＩＬＭＣ）を具備しているシ
    ステム。