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

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

Info

Publication number
JP2001520486A
JP2001520486A JP2000516468A JP2000516468A JP2001520486A JP 2001520486 A JP2001520486 A JP 2001520486A JP 2000516468 A JP2000516468 A JP 2000516468A JP 2000516468 A JP2000516468 A JP 2000516468A JP 2001520486 A JP2001520486 A JP 2001520486A
Authority
JP
Japan
Prior art keywords
message
field
database
data
communication device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2000516468A
Other languages
English (en)
Other versions
JP3274131B2 (ja
Inventor
バン・デア・ヘイデン、エクサンダー
デブリエル、ロベルト
ブランク、チップ
Original Assignee
エックス − ウエイ・ライツ・ビー・ブイ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by エックス − ウエイ・ライツ・ビー・ブイ filed Critical エックス − ウエイ・ライツ・ビー・ブイ
Publication of JP2001520486A publication Critical patent/JP2001520486A/ja
Application granted granted Critical
Publication of JP3274131B2 publication Critical patent/JP3274131B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • H04L51/066—Format adaptation, e.g. format conversion or compression
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]

Abstract

(57)【要約】 フレキシブルメッセージフォーマット（ＩＬＭＦ）を有するメッセージにより送信者（ＳＲＶ（ｍ））と受信者（ＳＲＶ（ｍ））との間の地点間を結ぶ通信用の方法および装置であり、ここで任意の前記メッセージは、少なくともメッセージ定義基準（ＭＳＧ ＩＤ，ＭＳＧ クラス，ＭＳＧ バージョン，ＭＳＧ クリエイタ）と送信者識別子（送信者 ＩＤ）と目的地アドレス（目的地 アドレス）とを有するヘッダと、フィールド番号（フィールド カウント）と任意のフィールドの内容（フィールド（１），…）とに関するメッセージ内容と、オブジェクト番号（オブジェクト カウント）および任意のオブジェクトの内容（オブジェクト（１），…）と、フィールドマッピング番号（マップ カウント）および予め定められたフィールドにより使用可能な任意のフィールドマッピングの内容（マップ（１），…）と、動作番号（アクション カウント）および予め定められたフィールドにより少なくとも使用可能な任意のアクション内容（アクション（１），…）とを含んでいる。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、電子データ通信、組織化されたデータベース、フレキシブルなフォ
ーマットの電子データメッセージ管理、クライアント−サーバおよび分散された
ソフトウェアアプリケーションの分野に関する。
【０００２】 特に、本発明は、生成、通信、解釈、フレキシブルなフォーマットの電子デ ータメッセージに対する表示および実時間応答、１以上の電子データ回路網上の
１以上のコンピュータシステムを横切って選択的に分散されてもよいフレキシブ
ルなフォーマットの電子データメッセージの集合として組織されるアプリケーシ
ョンとを説明し管理するための合理的なデータベースを使用する。
【０００３】
【従来の技術】
一般目的およびビジネス用の特定の電子データ通信は４つの異なる問題に直面
しており、それらはそれぞれさらに多数の問題を有している。以下の点は電子デ
ータ通信のほとんどのカテゴリに適用されることができるが、ビジネスの通信要
件に関するこれらの問題を説明する。４つの問題とは、 １）送信され受信される電子データはそれが意味するものが明白に認識されなけ
ればならない。各企業は例えばほとんどの基本的なビジネス情報、出荷の注文書
または請求書でさえそれらを表すために種々の異なる方法を有する。 ２）一度、別の企業から電子データが受信され、正確に認識されると、受信され
た企業のデータベースおよびビジネス処理プログラムに集積されなければならな
い。各企業はそれらのデータベース構造、即ちコンピュータシステムに電子デー
タを表し記憶する方法は多数存在し、異なっている。 ３）電子データはエンドユーザに表示され、エンドユーザの対話を可能にしなけ
ればならないならば、各企業は種々のタイプのディスプレイソフトウェア、種々
のシステム要件、ビジネス要件を有する異なるタイプのコンピュータディスプレ
イ端末を使用している可能性がある。カスタム化されたグラフィックユーザイン
ターフェイスを有する非常に高価な電子データディスプレイプログラムを構築す
ることが非常に頻繁に必要とされる。 ４）特定のビジネス機能を実現するために特定化されたシステムサービスおよび
関連するデータとの組合わせを使用することが必要とされるために、１以上のコ
ンピュータシステムを横切って分散された、調整された方法でコンピュータ化さ
れたビジネス機能の処理を実行する必要がある。このことはコンピュータ化され
たビジネスシステムが１以上の位置に存在し、１以上の位置で異なる動作を行う
が、基本的には１つの単一システムのように機能することを必要とすることを意
味している。この問題に対する解決策は、分散されたアプリケーション、または
最近では“ミドルウェア”として分類される分散されたオブジェクト管理システ
ムとして区別される。
【０００４】 ４つの問題に関する２つの異なる主な問題が存在する。第１に、企業が多数 の異なるシステムで同一のビジネスアプリケーションを使用し、動作を必要とす
る各異なるシステムにおけるビジネス理論、ユーザインターフェイス、ネットワ
ーク通信インターフェイスを再度書込む必要をなくすことを要求し、所望するこ
とである。第２の問題は、通信回路網を横切って１以上のシステムにわたり１つ
のアプリケーションの機能を分割し、十分に調整された方法で動作させる必要性
である。
【０００５】 これらの全ての４つの問題を解決できる単一システムは現在存在しない。ビ ジネスは電子データ通信および記憶システムを販売、構築、再構築、メンテタン
スに毎年、数百万ドルを浪費しており、これらの４つの問題の種々の組合わせを
実効的および完全に解決していない。
【０００６】 問題１ 第１の問題を解決するため、特定のタイプの情報の１組の電子データフォーマ
ットは通信が実際に行われる前に全ての通信企業により同意されなければならな
い。さらに、フォーマットについての同意は、これらの同一の丁度同意されたフ
ォーマットを使用する通信ソフトウェアの使用によって実現されなければならな
い。ＥＤＩ（Electronic Data Interchange ）はこの問題を解決する１方法であ
る。ＥＤＩは多数のタイプのビジネストランザクションに対する１組の電子デー
タメッセージフォーマットである。フォーマットはフレキシブルではなく、これ
らはユーザにより変更されることができないことを意味し、ほんの少し異なるＥ
ＤＩメッセージのバージョンが存在する。企業はＥＤＩメッセージビジネス通信
システムを構成し、異なるバージョンのＥＤＩメッセージセットを使用して他の
企業と電子データを交換することが依然として可能ではない。既存のビジネスシ
ステムをＥＤＩに変換するのにかかる時間量および金額は莫大であり、別のフォ
ーマットが必要になるならば、それに変更または付加することは困難であり高価
である。
【０００７】 ハードコード（即ちソフトウェアで限定された）メッセージフォーマットを 使用する方法および解決策はＥＤＩに関連する全ての問題を有し、異なる固定メ
ッセージフォーマットのみについての基本的に同一の解決策である。固定メッセ
ージフォーマットが変更されなければならない度毎に、これはソフトウェアとデ
ータベースおよびユーザインターフェイスを同様に変更することを必要とする。
非常に小さい変更でさえも、時折数か月かかる。勿論、この電子メッセージフォ
ーマットは将来の電子通信が正確に継続することを確実にするため、特定のフォ
ーマットを使用してビジネス毎のコンピュータで変更されなければならない。
【０００８】 基本的に、共通のデータフォーマット幾つかの方法で送信者および受信者に より同意されなければならない必要性が常に存在する。これは現在または将来有
効な方法に存在する。カスタマに対して臨界的な問題は、方法（即ちＥＤＩ）に
ついてのシステムの構築がどの程度高速度で廉価であり、システムのあらゆる部
分（データベース、ソフトウェア、ユーザインターフェイス）において、先に同
意された電子データフォーマットの変更がどの程度容易であるかである。
【０００９】 問題２ 第２の問題は、解決がさらに困難な問題である。通常、ほとんどの企業は多数
のデータエントリ人員を使用し、彼等は印刷物を読取り、読取られたデータを処
理して端末で作動するコンピュータプログラムへ読出し、これを正確なフォーマ
ットへ変換し、企業のデータベースに位置する。ＥＤＩまたは類似の共通の電子
メッセージフォーマットを使用する企業は、非常に多額の費用をカスタム化ソフ
トウェアに費やし、カスタム化ソフトウェアはこれらの共通の電子メッセージフ
ォーマットを自動的に処理して変換し、データ記憶および検索の目的で既存のデ
ータベース構造と対話する。共通のメッセージフォーマットに対して変更または
付加が必要であるならば、またはデータベース構造の変更または拡張が必要であ
るならば、この電子メッセージフォーマットデータベースインターフェイスプロ
グラムを変更させ再度書込ませるために時間と多額の費用を費やさなければなら
ない。
【００１０】 １つの新しい公共ドメインの通常目的の解決方法は、カスタマのデータベー スまたは記憶装置の特定位置への特定データアイテムの“マッピング”を中心と
している。このマッピングはソフトウェアでは生成されないで、幾つかのさらに
容易に変更可能でフレキシブルの表示中に存在し、これはソフトウェアアプリケ
ーションおよびソフトウェアアプリケーションが読取る独立したフラットファイ
ル等のカスタマのデータベースとは分離されている。これはデータベース構造ま
たはデータ表示が変更する度にソフトウェアアプリケーションを再プログラムお
よび再構築する必要性を除去する。データフィールドマッピング技術はProgress
、Oracle、SQLBase （SQL ＝Standard Query Language ）等の多数のデータベー
ス企業により共通して使用される。よく知られた方法のバージョンは本発明の通
信装置に構成される機能および方法論の一部である。
【００１１】 問題３ 第３の問題は、容易に動作可能な通常目的の幾つかの解決策を持つことである
。解決策の１つのカテゴリはＸウィンドウズまたはマイクロソフトウィンドウズ
等の種々のウィンドウ（グラフィックユーザインターフェイス）管理システムに
対して相当の量のソフトウェアコードを書込むことを必要とする。大きい多機能
ビジネスアプリケーションでは、この方法は莫大な量の時間、費用、労力を必要
とし、ユーザインターフェイスに対する変更または付加は非常に時間を消費し、
価格的にも問題になる。
【００１２】 新しく有望な解決策のカテゴリはＨＴＭＬ（Hyper Text Markup Language） およびウェブブラウザの使用を中心とし、これはワールドワイドウェブおよびイ
ンターネットで使用されるため“ウェブページ”と通常呼ばれている非常に見掛
けの良いグラフィックユーザインターフェイスをダイナミックを生成することが
できる。これには多数の企業が興味を示している。企業は、ＨＴＭＬを使用して
いかに迅速で廉価に非常に見掛けの良いグラフィックユーザインターフェイスを
作成されることができるかを観察し、電子データ通信および処理プログラム用の
ユーザインターフェイスがウェブブラウザシステムと同一方法で生成され同じ回
路網で通信するか否かの疑問をもつ。実際、企業は全ての範囲のビジネスおよび
パーソナルデータおよびメッセージを送信および受信するためにインターネット
を使用することができることを好む。
【００１３】 現時点では、ＨＴＭＬおよびウェブブラウザを使用して、インターネットに わたる限定された範囲のビジネスおよび汎用のデータ通信を可能にする有効な幾
つかのシステムが存在する。データ通信のタイプが限定される理由は、ウェブサ
ーバ／ウェブブラウザシステムが十分なデータ通信サービスを行うように設計さ
れていなかったことである。それらはダイナミックなドキュメントの検索および
ディスプレイシステムとして設計された。それらはユーザからのリクエストとし
て最初に初期化される情報を検索できる。それらは広範囲の付加的なプログラミ
ングによることを除いて、１以上の目的地へ情報を送信する能力をユーザに与え
ない。送信能力はシステムに固有ではない。このタイプの例は、Progress' WebS
peed、IBM's WebEDI、SapphireGroup's PageBlazerである。
【００１４】 いわゆる“プッシュ”技術を構成するウェブブラウザおよびウェブサーバの “新しい”特徴でさえも送信をすることはできずデータ受信のみを可能にする
。この“受信”は、ウェブブラウザおよびウェブサーバシステムにより実際はシ
ミュレートされた放送受信機として情報（ポーリング）の隠れた反復リクエスト
が設定される。この“プッシュ”技術を拡張するための計画は、真の放送および
マルチキャスト通信技術の使用だけを含んでいる。“プッシュ”技術の例は、Ma
rimba のCastanetおよびTibco のＴＩＢ ＡＰＩである。このいわゆる“プッシ
ュ”技術は新しい方法で大市場まで広げることを要求する広告業者には大きな関
心事であるが、既存のデータベースおよびビジネスシステムに容易に集積される
ことができる地点間のプロトコルを使用した十分に集積された双方向情報通信の
内容で、ＨＴＭＬおよびインターネットの進んだドキュメントディスプレイ特性
を使用することを要求または必要とする企業または個人にはほとんど使用されな
い。
【００１５】 インターネットのウェブサーバとウェブブラウザインターフェイスは、ウェ ブページのリクエストとしてメッセージをエンドユーザへ送信することを可能に
するように設定される。電子メールを除いてウェブブラウザユーザはメッセージ
を別のウェブブラウザユーザへ送信し、またはウェブページを別のウェブブラウ
ザユーザへ送信できることはなかった。ウェブブラウザユーザは最初に求められ
ていなかった特定のメッセージを受信したことはなく、いわゆる“プッシュ”技
術情報でさえもポーリングおよび情報特性によりリクエストされることはなく、
カスタム化されたときでさえもテレビジョン放送または大量のメーリングと比較
されることができない。情報は１つの特定の受信者に対して送信されてはいない
。これは例えば電子メール（ｅメール）と対照的である。ｅメールサービスを使
用すると、最初に、送信者に要求せずに、任意の数の特別な私用メッセージを受
信することができる。最初に要求せずに、任意の数の特別な私用メッセージを特
定の受信者へ送信することができる。これはメッセージの一般的な必要な特性で
ある。インターネットのウェブサーバシステムはこのような通信を行うように設
計されていなかった。
【００１６】 企業および個人がこのようにこれらを使用することに関心をもつ理由は何で あろうか？。彼等は単にｅメールを使用したらどうか？。その答えはｅメールが （ＨＴＭＬが行うように）それに組込まれたデータフォーマットサービスをも
たず（ウェブブラウザが行うように）それに組込まれたユーザインターフェイス
生成をもたないからである。ｅメールメッセージはまたその目的地に到達するた
めに不確定の時間量（数秒から数日）かかり、時には失われなくなることもある
。これは標準的なビジネス電子データ通信に対しては許容できない。この理由で
企業および個人は、それに組込まれた非常に良好なデータディスプレイ能力と、
適度に高速度の通信を有するウェブサーバ／ウェブブラウザシステムを好む。し
かしながら、前述したように、地点間通信能力またはデータ表示およびマッピン
グ能力をもたない。
【００１７】 本発明では、公共ドメインＨＴＭＬ標準は非常に容易に構築され、高速度で フレキシブルなグラフィックユーザインターフェイスを生成するための解決手段
として組込まれてもよい。
【００１８】 問題４ 歴史的に、問題４は、非常に最近まで関係型データベース管理システム（ＲＤ
ＢＭＳ）だけによって一般的な方法でアドレスされてきた。このクラスの解決策
は分散された問合わせおよび分散されたデータベース管理の適切な機能を解決す
るように限定されており、先に説明した問題４の主要な２つの問題をアドレスし
ない。
【００１９】 第２の、新しいクラスの解決策は“ミドルウェア”または分散されたオブジ ェクト管理システムと現在呼ばれているシステムで見られる。これの良い例はＣ
ＯＲＢＡ（Common Object Request Broker Architecture ）と呼ばれるシステム
である。ＣＯＲＢＡの開発経歴、目的、ＣＯＲＢＡ 2.0の現在の機能および欠点
における優秀な文献セットは、Warren Kayffill 、“CORBA masterminds object
management ”、42頁、ＤＢＭＳマガジン10巻、No.3、1997年３月と、同じＤＢ
ＭＳ出版のT.J.Hart“Questioning CORBA. Bringing Corba-based designs to l
ife faces a multitude of obstacles”、52頁で見られる。
【００２０】 このクラスの解決策はデータベースの共同使用可能性問題と、アプリケーシ ョンレベルの共通のデータフォーマット問題またはユーザインターフェイス問題
をアドレスする。これは通信レベルで標準的な通信インターフェイスおよび標準
的なデータによりアプリケーションを書込む能力だけをアドレスする。基本的に
、このタイプのシステムは開発環境と、実行時の環境と、１組のソフトウェアラ
イブラリを供給し、これによってプログラマは任意のシステムで実行するアプリ
ケーションを生成することができ、コードのデータ構造（いわゆるオブジェクト
）を定めた後にこれらのデータ構造は、これらの特定のデータ構造を認識し、使
用するようにコード化されているその他のソフトウェアプログラムと交換される
ことができる。
【００２１】 この能力および機能は、根本的にJavaにおいてメッセージ通信システムを書 込むプログラマとは異なっておらず、これはほとんど任意のシステムで動作し、
ＥＤＩメッセージまたは通信媒体等の幾つかのその他の同意された固定フォーマ
ットを使用する。ＣＯＲＢＡシステムはメッセージを何等解釈しない。プログラ
マにより書込まれたアプリケーションはメッセージを認識できなければならない
。これはＣＯＲＢＡアプリケーションに、ＥＤＩまたは固定されたメッセージフ
ォーマットアプリケーションシステムと同様の開発、変更、メンテナンスの価格
および時間についての全ての問題を残す。ＣＯＲＢＡによって可能な分散された
機能でさえも、ＣＯＲＢＡで固有ではなく、アプリケーションを設計およびコー
ド化するプログラマの技能とＣＯＲＢＡ通信ライブラリの使用が基本的に必要で
ある。根本的に、ＣＯＲＢＡの唯一の明白な利点は、多数の実行時の環境にわた
ってアプリケーションシステムの部分の共同使用可能性であり、これは恐らくJa
vaのようなその他の手段により良好に得られることができる。
【００２２】 基本的に、ほとんどのケースの“ミドルウェア”は実際には標準的な通信環 境と幾つかの標準化されたソフトウェア機能を多数のコンピュータで与える丁度
別の電子データ通信環境であるように見えるが、ソフトウェアアプリケーション
構築の全ての特徴をアドレスすることはできず、データベースインターフェイス
およびユーザインターフェイスに対するシステム依存コードの使用を必要とし、
それによってＣＯＲＢＡ等のシステムを使用する主要な目的を無効にする。
【００２３】 ＣＯＲＢＡ機能をJavaに吸収し、ＯＤＢＣと呼ばれる標準化されたデータベ ースインターフェイスを含むシステム、またはJavaシステムＪＤＢＣに存在する
幾つかのシステムが存在する。これは興味深い開発であるが、ＯＤＢＣデータベ
ースインターフェイスのように、読取り専用の問い合わせにのみ有効であり、十
分なデータベースアクセスを必要とする標準的なビジネストランザクションシス
テムは適切に生成されることができない。また、この組合わせは問題１または２
を全くアドレスしない。さらに、ＯＤＢＥＣの使用とＣＯＲＢＡオブジェクトブ
ローカーシステムの不適切なオーバーヘッドのために、これは本発明を構築する
ための所望のプラットフォームではない。
【００２４】 さらに従来技術は、以下簡単に説明する幾つかの特許明細書にも記載されて いる。米国特許第5,257,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 、EP0,747,843 A1 、EP-0,747,844 A1 、EP-0,747,845 A1 明細書（全てInternational Business M
achines Corporation ）では幾つかの形態のデータベースアクセスにより現在の
ウェブサーバ機能を強化することに焦点を置き、それ故、前述したウェブサーバ
の通信限界により制限される。それ故、これらの発明は問題１と４を全く解決で
きず、限定された方法でのみ問題２と３を解決する。さらに、Progress Databas
e Corporation からのWebSpeedのようなウェブサーバ強化において同じまたはさ
らに多くの機能を与えるように見える幾つかの市場で入手可能なシステムが存在
する。
【００２８】 WO 95/11560 号明細書（Sybase社）には、使用されるコンピュータハードウ ェアまたはオペレーティングシステムにかかわりなく、アプリケーションが構築
される一貫した電子データ通信ソフトウェアインターフェイスを生成する問題だ
けを解決する“ミドルウェア”のカテゴリについて記載されている。この明細書
は任意の方法で通信される電子データのフォーマットをアドレスせず、この問題
はＣＯＲＢＡに非常に類似し、本発明によりアドレスされる４つの問題の視点か
ら全ての同一の制限を有する。
【００２９】 EP 0 421 624 A2 号明細書（Texas Instruments Incorporated）はＣＯＲＢ Ａ等の“ミドルウェア”システムと、アプリケーション開発環境の組合わせにつ
いて記載されている。データベース制御され管理されたソフトウェア開発環境を
使用して、ここで記述された発明はプログラマがＣ、ＣＯＢＯＬ、ＳＱＬのアプ
リケーションを開発することを可能にする。データベースは、大きいグループの
プログラマが複雑なデータベーストランザクションアプリケーションのソースコ
ード制御技術を開発し、変更し、使用することを可能にする情報を含んでいる。
この明細書では、多くはＩＢＭメインフレームシステムおよび幾つかのＵｎｉｘ
システムについて説明しているが、データベースはまたアプリケーションが別の
ハードウェアシステムで再度コンパイルされ、各タイプのコンピュータで同一方
法で機能することを可能にする情報も含んでいる。最終結果は一連のハードコー
ド化されコンパイルされたアプリケーションであり、全ての問題が問題１および
２で説明されているのと同一であり、部分的にのみ問題３、４を解決する。
【００３０】 EP 0,456,249 A2 号明細書（Hewlett-Packard Company ）はＣＯＲＢＡ等の “ミドルウェア”システムと、主要な能力が異なった高レベルのプログラミン
グ言語で開発されている既存のアプリケーションと連結している部分的なアプリ
ケーション開発環境の組合わせである。本発明で述べる高レベルの言語はそれら
のデータの異なる実行時間メモリ内組織を有し、１つの言語組織から別の言語組
織へデータを変換しなければならない。結局、中間データ表示およびデータ転送
命令は、データ表示をコンパイルし、命令を転送した後、その発明が１つの言語
の実時間表示からの識別されたデータ構造を別の言語の実時間表示からの識別さ
れたデータ構造へ変換することを可能にする。この発明はアプリケーションとし
て独立して実行するために必要な全てのデータおよび命令を含んでいるメッセー
ジフォーマットを任意の方法でアドレスせず、２つの予め存在するアプリケーシ
ョン間の特定されたデータ構造を変換するのに必要なデータおよび命令のみをア
ドレスする。それ故、この発明は問題２と３で説明されている問題を全くアドレ
スせず、ここで説明しているようなアプリケーションレベルではなくプログラミ
ング言語のレベルで問題１と４の問題を部分的にのみアドレスする。対照的に、
本発明では、アプリケーションは全体的にメッセージから構成され、それ故、１
つの言語からのデータを別の言語のデータへ変換することはなく、メッセージフ
ォーマットまたは命令のコンパイルは必要とされず、全てのデータはそれが送信
されてもコンピュータメモリ中に残っていても、メッセージフォーマットに残留
する。
【００３１】
【発明が解決しようとする課題】
前述したように、各これらの４つの問題を解決でき解決策を１つの一体化され
た統一体に結合することができる１つのコンピュータおよび通信方法が緊急に必
要とされる。複雑な電子データ通信システムを構築しなければならない個人およ
び企業と、日常ベースでこれらの問題に直面しなければならない人にはこれは有
効である。このようなシステムおよび通信方法は、電子データ通信システムを構
築し、維持する時間、価格、複雑性を劇的に減少する。
【００３２】
【課題を解決するための手段】
前述のオブジェクトを獲得するため、本発明はフレキシブルなメッセージフォ
ーマットを有するメッセージにより送信機と受信機との間の地点間通信方法にお
いて、そのメッセージは、 少なくともメッセージ定義基準と、送信者識別子と、目的地アドレスからなる
ヘッダと、 ＊フィールド番号および任意のフィールドの内容と、 ＊オブジェクト番号および任意のオブジェクトの内容と、 ＊マッピング番号および、予め定められたフィールドにより使用可能な任意の
フィールドマッピングの内容と、 ＊アクション番号および、少なくとも予め定められたフィールドにより使用可
能な任意のアクションの内容を含んでいることを特徴とする。
【００３３】 結果として、定められたアプリケーションレベル機能の全ての素子がメッセ ージフォーマット中に存在し、これは既に回路網通信システムの文脈中にあり、
それ故単に位置および目的地アドレスを変更することによって容易に分配される
ことができる。
【００３４】 さらに、本発明によれば、処理手段とデータベースを具備し、フレキシブル なメッセージフォーマットを有するメッセージによって別の通信装置との地点間
通信を行うように構成された通信装置が提供され、そのメッセージは、 少なくともメッセージ定義基準と、送信者識別子と、目的地アドレスからなる
ヘッダと、 ＊フィールド番号および任意のフィールドの内容と、 ＊オブジェクト番号および任意のオブジェクトの内容と、 ＊マッピング番号および、予め定められたフィールドにより使用可能な任意の
フィールドマッピングの内容と、 ＊アクション番号および、少なくとも予め定められたフィールドにより使用可
能な任意のアクションの内容を含んでおり、 処理手段は予め定められたメッセージ定義表を参照としてメッセージ定義基準を
使用してデータベースに記憶されている予め定められたメッセージ定義表を調べ
るように構成されている。
【００３５】 したがって、本発明においては、任意のタイプのデータを含むことができ、 メッセージ自体内のデータを十分に記述するのに十分な情報を含んだフレキシブ
ルなメッセージフォーマットが規定される。任意のメッセージは、データベース
に予めロードされたメッセージ定義を識別するためメッセージを受信する上記の
通信装置により使用されるメッセージ定義基準を含んでいる。しかしながら、予
めロードされたメッセージ定義は一度も全く固定されないので技術はフレキシブ
ルである。メッセージを受信する通信装置内では、メッセージを十分に記述しそ
れを特有の識別子と参照する関連するデータベース表中にエントリを挿入し、更
新し、または消去することによって、メッセージフォーマットの特定インスタン
スが生成され、編集されまたは消去される。さらに、メッセージ定義が所望の位
置に存在しないならば、全体的なデータベースメッセージ定義は特定のメッセー
ジまたはメッセージのグループに対して自動的に交換されてもよく、それによっ
て多数のユーザの容易に交換される共通のフォーマットメッセージを生成する。
本発明のさらに別の利点は必要なオーバーヘッド量が少いことである。
【００３６】 メッセージ定義基準内のフィールドの例は、任意のメッセージを識別するた めのメッセージ識別子と、メール、ビジネスメッセージ、注文または発送等の任
意のメッセージのメッセージクラスを識別するメッセージクラス識別子と、任意
のメッセージのバージョン番号を識別するメッセージバージョン識別子と、任意
のメッセージのクリエイタを識別するメッセージクリエイタ識別子である。メッ
セージ定義基準内の任意のこれらのフィールドは上述の通信装置のメッセージ定
義表内に対応するフィールドを有する。
【００３７】 さらに、メッセージのヘッダは使用される暗号化および／または圧縮タイプ の基準を含んでいる。またこれらの基準は通信装置のメッセージ定義表中に対応
部分を有している。
【００３８】 好ましくはメッセージの内容はデジタル署名により保護される。
【００３９】 好ましくは通信装置のデータベースは幾つかの表で組織され、その表に対し てメッセージ定義表から参照を行う。予め定められたメッセージ定義表はデータ
ベースのさらに別の表の参照として使用するためのメッセージシステム識別子を
含んでいる。
【００４０】 このようなさらに別の表のうちの１つはメッセージの任意のフィールドの主 な定義を保持するためのフィールド定義表であってもよい。
【００４１】 好ましくは、さらにこのような表のうちの１つは、例えばハイパーテキスト マークアップ言語フィールド、データベースフィールド、フラットファイルフィ
ールドおよびその他のメッセージフィールドにマップするための、予め定められ
たフィールドにより使用可能なマッピング指令を含むフィールドマッピング表で
あり、前記データベースフィールドとフラットファイルフィールドはカスタマデ
ータベース中に記憶されている。本発明にしたがったメッセージフォーマットは
、データだけではなく、ユーザインターフェイス、カスタマデータベースフィー
ルド、計算および条件論理を含むアクションシーケンスのマッピング命令を含ん
でいる。結果として、アプリケーションレベル機能を規定する全ての要素はメッ
セージフォーマットに存在し、それは既に回路網通信システムの文脈中にあり、
それ故位置および目的地アドレスを単に変更することにより容易に分布されても
よい。さらに、このようにＨＴＭＬ標準は、非常に容易に構築され、高速度でフ
レキシブルなグラフィックユーザインターフェイスを生成し、上述の通信装置に
より管理され、規定され、制御され、マイクロプロセッサ等のユーザ端末と対話
され通信装置へ接続されるように、本発明により限定されたメッセージフォーマ
ットへのマッピングおよびそこからの直接的なマッピングを可能にするために設
けられてもよい。
【００４２】 さらに、このような表のうちの１つは予め定められたフィールドにより使用 可能なアクション情報を含むフィールド動作表であってもよい。
【００４３】 好ましくは、さらに別の表は、受信または送信されるメッセージの前処理と して実行されるアクションリストを含むメッセージ前処理表、および受信される
メッセージの後処理として実行されるアクションのリストを含むメッセージ後処
理表である。
【００４４】 フィールドアクション表、メッセージ前処理表、メッセージ後処理表は以下 のアクションのグループ、即ちアクションのデータベースタイプと、数学的演算
、割当、論理演算、条件演算、命令を含むアクションの論理タイプから選択され
たアクションのタイプの基準を含んでいる。
【００４５】 好ましくは、本発明においては、アプリケーションは１以上のメッセージの 名前を付けられたグループとして定められる。すなわち、メッセージ定義表は受
信されたメッセージがアプリケーションの最初のメッセージであるか否かを示す
アプリケーションフィールドと、アプリケーションの名称を参照するためのアプ
リケーション名称フィールドとを含んでいる。
【００４６】 本発明によると、通信装置は、受信されたメッセージがそのデータベース中 に存在しないメッセージ定義を参照した場合には、送信者からの新しいメッセー
ジ定義をリクエストし、前記送信者から前記新しいメッセージ定義を受信し、前
記データベースの前記メッセージ定義表にこれを記憶するように構成されること
が好ましい。
【００４７】 通信装置の処理手段は、指定されたＨＴＭＬファイルで受信されたメッセー ジをマージするか、または指定されたＨＴＭＬファイルが処理手段により発見さ
れなかった場合には、デフォルトダイナミックＨＴＭＬファイルを生成するよう
に構成されてもよい。しかしながら、その代わりに、通信装置の処理手段は、接
続された端末にこれらの機能を実行するように指令してもよい。それ故、本発明
は先に規定したような通信装置と、通信装置に接続され端末プロセッサを有する
端末とを具備するシステムにも関し、端末は端末プロセッサと、ディスプレイ装
置と、ユーザによるデータを入力するための入力手段とを具備し、通信装置は、
端末がメッセージ中で目的地アドレスであることを示されたならば、受信された
メッセージを端末に送るように構成され、端末プロセッサは指定されたＨＴＭＬ
ファイルでメッセージをマージするか、または指定されたＨＴＭＬファイルが端
末プロセッサにより発見されなかった場合にはデフォルトダイナミックＨＴＭＬ
を生成するように構成される。
【００４８】 したがって、端末プロセッサが対応するメッセージ定義をもたないメッセー ジを受信するユーザ端末は、システムの自動解釈とディスプレイに依存すること
ができ、これは受信されたメッセージ内に含まれる自己記述情報に基づいている
。この同じ自己記述情報は、メッセージによって参照されたデータベースメッセ
ージ定義が発見されることができる場合には端末プロセッサによりデフォルトデ
ータベースメッセージ定義を自動的に生成するために使用されることができる。
このようなデフォルトデータベースメッセージ定義は端末ユーザにより編集され
、ローカルシステムに適合されることができる。
【００４９】 本発明は、問題１および４に対する完全に新しい解決策を有する特有の方法 で組合わされて問題２および３に対する現在知られているの解決策を含んでおり
、全てはフレキシブルメッセージフォーマットおよび通信装置からなる特有のフ
レキシブルフォーマット電子データメッセージ管理システムを中心として構築さ
れる。
【００５０】 関連データベース表に記憶された詳細な情報により規定され制御される本発 明のメッセージ管理システムは、最も効率的で、完全で、簡単に、フレキシブル
フォーマットで電子データを通信する方法を使用することを可能にする。フレキ
シブルメッセージフォーマットは、任意の形態の電子データを含むことを可能に
する。フレキシブルメッセージフォーマットは、メッセージが先に受信されてい
なくても、受信機がメッセージの内容を解釈し、理解し、表示することを可能に
する情報を含んでいる。受信機はまたソフトウェアを書込みまたは変更せずに、
この未知のメッセージフォーマットをその固有のメッセージデータベースへ付加
しこれをそのビジネスデータベースおよびＨＴＭＬユーザインターフェイスに非
常に容易に素早く連結することができる。ＨＴＭＬユーザインターフェイスは、
また特定化され先に生成されたＨＴＭＬファイルが存在しない場合に端末のソフ
トウェアによりダイナミックに生成されることもできる。これは第１の問題を解
決する。
【００５１】 本発明では、主要な合理的データベースへのＡＮＳＩ標準ＳＱＬインターフ ェイスが設けられてもよい。このインターフェイスは後で記憶または検索のため
に関連データベース表中のフィールドへユーザが選択したデータメッセージのフ
ィールドを自動的に連結するサービスを行う。このデータマッピングインターフ
ェイスは固定した長さのフィールドおよびＣＳＶ（カンマで分離された値）ファ
イルのようなフラットファイルフォーマットへ連結することもできる。このデー
タマッピングインターフェイスは、メッセージデータフィールドをＳＮＭＰおよ
び自動処理制御用の製造プロトコルのような多数の他のフォーマットに連結する
ように拡張されることができる。このデータマッピングインターフェイスはＩＬ
ＭＤＢ中のエントリにより規定され、ＩＬＭＳにより制御される。これは第２の
問題を解決する。
【００５２】 本発明では、メッセージ制御ユーザインターフェイス端末が設けられ、ここ でユーザはメッセージを生成し、編集し、受信し、送信し、観察する。メッセー
ジ制御ユーザインターフェイスは本発明にしたがって構成された回路網およびメ
ッセージ管理サーバと通信する。本質的に、本発明は十分なデータ通信能力を必
要とする個人または企業に対する現在のウェブサーバ／ウェブブラウザ技術を置
換し、任意のデータ通信回路網を含むようにシステムドメインを拡張する。これ
はＨＴＭＬ、ＶＲＭＬ、Ｊａｖａアプレット、ならびにユーザが特定のメッセー
ジ中で規定された任意の特定データの十分な送信および受信を可能にする。先に
示した特徴と組合わせるとき、これは十分な、データベース制御されたメッセー
ジ中のデータ間の連結と、検索されるまたは記憶しなければならないカスタマデ
ータソースと、表示されなければならないグラフィックユーザインターフェイス （ＨＴＭＬ等）を与える。
【００５３】 前述の問題を解決することに加えて、本発明は自動的な、システムが実行す るアクションを規定する能力を付加し、これはメッセージの前処理および後処理
として組織され、またはグラフィックユーザインターフェイスと連結したメッセ
ージの場合、フィールド選択アクションを規定する能力を付加してもよい。これ
らのアクションはＳＱＬまたは“InterLingua （商標名）スクリプト”として限
定される。InterLingua （商標名）スクリプト”（ＩＳ）は本発明において規定
され、簡単でしかも強力なセットの計算、実行および条件論理制御ステートメン
トであり、これはダイナミックに解釈され実時間で実行され、全てのメッセージ
データフィールドと対話できる。アクションは新しいメッセージと、システム機
能と外部プログラムに作られた呼びとを生成し、またはデータベースの問合わせ
を送信および受信することができる。これらのアクションは例えば自動メッセー
ジ応答と自動フィールド確認を生成し、計算を実行し、Ｊａｖａアプレットまた
は複雑なデータベーストランザクションを実行する。
【００５４】 本発明では、１組のメッセージおよびそれらの関連したアクションとして定 義されているアプリケーションの非常に特有の方法を含んでいる。メッセージ間
の対話の豊富さとフレキシブル性のために、データベーストランザクションを実
行する能力はグラフィックユーザインターフェイスとマージ（合体）またはそれ
を生成するか、または背景プロセスとしてシステムで静かに実行し、データメッ
セージの集合およびそれらの関連アクションとして複雑なアプリケーションを十
分に限定することができる。これらのメッセージはそれらの特性によってシステ
ムの基本的な機能として非常に容易に送信され受信され理解され組織化されるの
で、これは分散されたアプリケーション処理の範囲で大きな内包を有する。この
ことは、最初に、任意のソフトウェアコードを変更または付加せずに、分配され
たアプリケーションシステムが同一のアプリケーション（メッセージセット）を
使用しながら、各位置においてローカルユーザインターフェイスと（ビジネスデ
ータベースのような）カスタマデータソースインターフェイスを容易にフレキシ
ブルに限定できることを意味する。
【００５５】
【発明の実施の形態】
本発明を幾つかの図面を参照して説明するが、それは本発明を例示することの
みを目的とし、本発明の技術的範囲を限定するものではない。 図１では、複数のサーバＳＲＶ（ｍ）（ｍ＝１，…，Ｍ）が示されている。任
意のサーバＳＲＶ（ｍ）は１以上の端末に接続されてもよい。サーバＳＲＶ（１
）に接続する端末はＩＬＭＣ（ｎ）（ｎ＝１，…，Ｎ）と呼ばれる。頭文字“Ｉ
ＬＭＣ”はInterLingua （商標名）Message Clientから得られる。接続は参照符
号４、５で示されている。
【００５６】 さらに、サーバＳＲＶ（１）はカスタマデータベースＣＤＢ（１）に接続さ れている。１つのカスタマデータベースＣＤＢ（１）が示されているが、必要な
らば１よりも多数のカスタマデータベースが与えられることができる。
【００５７】 端末ＩＬＭＣ（１）は図１でさらに詳細に示されている。端末ＩＬＭＣ（１ ）はモニタスクリーン６、処理装置１、キーボード12、マウス13を含んで示され
ている。キーボード12とマウス13は処理装置１に接続されている。勿論、ユーザ
によりデータを処理装置１に入力するためのその他の既知の手段が、キーボード
12とマウス13の代わりにまたはそれらに加えて可能である。
【００５８】 モニタスクリーン６は幾つかの“ボタン”７、８、９、10、11を示している 。これらのボタンは処理装置１に予め定められたタスクを実行するように指令す
るためにマウス13によりユーザにより付勢されることができる。このような予め
定められたタスクはオプションを開くこと、接続の設定、メッセージの送信、メ
ッセージの受信および／またはデータを処理装置１のメモリに負荷することなど
である。
【００５９】 サーバＳＲＶ（１）には本発明の方法にしたがってメッセージを受信、通過 または送信するためのInterLingua （商標名）メッセージサーバＩＬＭＳと呼ば
れるプロセッサが設けられている。ＩＬＭＳプロセッサの部分はＩＳ（＝InterL
ingua （商標名）Script）で示され、その機能を以下説明する。
【００６０】 サーバＳＲＶ（１）はまた後述するように、本発明による幾つかの表を記憶 するためのデータベースＩＬＭＤＢ（＝InterLingua （商標名）Message Databa
se）を具備している。
【００６１】 サーバＳＲＶ（１）は通信路２を経て相互のサーバとの地点間の通信のため に配置されている。通信路２は任意の既知の方法、即ち有線または無線により設
定されることができる。
【００６２】 図１は１以上の端末ＩＬＭＣに接続された幾つかのその他のサーバＳＲＶ（ ｍ）を示している。これらのさらに別のサーバＳＲＶ（ｍ）は本発明にしたがっ
て組織され、以下さらに詳細に説明する。
【００６３】 図２および図３のａ、ｂ、ｃ、ｄはメッセージフォーマットを示している。 図２では、メッセージフォーマットは、メッセージを受信する任意の装置により
メッセージ定義参照として使用される４つのフィールド、即ちＭＳＧ ＩＤ、Ｍ
ＳＧ クラス、ＭＳＧ バージョン、ＭＳＧ クリエイタを含むように示されて
いる。
【００６４】 フィールドＭＳＧ ＩＤはメッセージを識別する。
【００６５】 ＭＳＧ クラスは、メール、ビジネスメッセージ、注文または発送のような メッセージのカテゴリまたはタイプを指定するために使用される。
【００６６】 フィールドＭＳＧ バージョンは関係するメッセージのバージョン番号を識 別するためのメッセージバージョン識別子を有している。
【００６７】 第４のフィールドＭＳＧ クリエイタは関係するメッセージのクリエイタを 識別するためのメッセージクリエイタ識別子を具備している。
【００６８】 ＭＳＧ ＩＤ、クラス、バージョンフィールドは整数値である。例えばＭＳ Ｇ クラス当たり1,000,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 フィールド動作定義（フィールド当り１動作） msgpre メッセージ事前処理（メッセージアクションのシーケンス） 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.msghtml）のフィールド
を特定する。 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 は同一構造を有する。表“msgpre”は特定のメッセ
ージの事前処理としてサーバプロセッサＩＬＭＳにより実行されるアクションの
リストを保持する。これは任意のディスプレイまたはフィールドアクションが行
われる前に、サーバプロセッサＩＬＭＳがリストまたは事前処理機能を完了する
ことを意味する。表“msgpost ”は特定のメッセージの事後処理としてサーバプ
ロセッサＩＬＭＳにより実行されるアクションのリストを保持する。これは全て
のその他のメッセージアクションおよびディスプレイの終了後に、サーバプロセ
ッサＩＬＭＳが主メモリからメッセージを削除する前に事後処理機能のリストを
完了することを意味する。このプロセスのシーケンス番号はアクションのリスト
の制御された実行を生成するために使用される。先のシーケンス番号は次のシー
ケンス番号が開始できる前に完了しなければならない。同一のシーケンス番号を
有する動作が１よりも多数存在するならば、これらは同一の時間、または多数の
ＣＰＵ内、または真の並列処理として多数の並列環境で開始される。
【００９０】 表：msgore フィールド名称 タイプ 説明 msysid 整数 メッセージシステムＩＤ procseq 整数 処理シーケンス 次のフィールドは動作タイプ、即ちＳＱＬまたはＩＳ、ファイルまたはローカ
ルを限定する。 proctype char 事前処理のタイプ 次のフィールドはＳＱＬ、ＩＳまたは内容がＳＱＬまたはＩＳであるファイル
名を含んでいる。 procscript char 事前処理スクリプト 表：msgpost フィールド名称 タイプ 説明 msysid 整数 メッセージシステムＩＤ procseq 整数 処理シーケンス 次のフィールドは動作タイプ、即ちＳＱＬまたはＩＳ、ファイルまたはローカ
ルを限定する。 proctype char 事後処理タイプ 次のフィールドはＳＱＬ、ＩＳまたは内容がＳＱＬまたはＩＳであるファイル
名を含んでいる。 procscript char 事後処理スクリプト InterLingua （商標名）Script（アクションの定義および制御言語） メッセージ事前処理、事後処理用の動作またはフィールド動作はＳＱＬ動作ま
たはＩＳ動作である。ＳＱＬ（構成された問合わせ言語）は合理的なデータベー
ス用のＡＮＳＩ標準インターフェイス言語である。ＩＳ（InterLingua （商標名
）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><parameter I> …<parameter n> メッセージの実行： ILMP://<host-name>/<message id> 内部機能の実行（これはほとんどユーザインターフェイス事象で使用される） ILMP://<host-name>/<message id>/<field id>[UI-ACT ｜MSG-END ｜APP-END] ILMP://<host-name>/<message id>/<field id>[ADD-DATA ｜DEL-DATA｜CHG-DA
TA]<data> アプリケーション InterLingua （商標名）メッセージの集合は共にグループ化され、特有の名称
を付けられ、InterLingua （商標名）アプリケーションとして使用されることが
できる。この説明の目的で、任意のプログラミング言語またはシステムプラット
フォームに対して、アプリケーションは１以上の機能であるとして定義され、そ
の動作シーケンスは入力データとユーザとシステム事象とに基づいて変化し、こ
れは外部記憶装置をアクセスして、それと対話することができ、ユーザインター
フェイスを経てユーザと対話できる。
【００９５】 この名称を付けられたメッセージのセットの全てまたはその一部は１以上の 位置の１以上のサーバＳＲＶ（ｍ）に存在してもよい。この名称を付けられたメ
ッセージのセットまたはアプリケーションは、 ａ）指示された一連の機能と、 ｂ）ローカルおよび共有データと、 ｃ）ユーザインターフェイススクリーンと、 ｄ）回路網にされた分配アプリケーション機能とを実行する。
【００９６】 指示された一連の機能は、データベースの問合わせ、計算および付加的なメ ッセージの付勢等の任意の動作タイプを含んでもよい。この文脈のメッセージの
付勢はアプリケーション機能の呼出しと、次のユーザインターフェイススクリー
ンの表示、または勿論ローカルまたは外部回路網目的地へのメッセージの送信に
匹敵するものに使用されることができる。動作順序の実時間の構成されたフロー
、換言すると、指示された一連の機能は、メッセージアクションのリストと、フ
ィールドまたはボタンのマウス選択のようなユーザインターフェイスにより生成
される事象アクションにより決定される。
【００９７】 ローカルおよび共有データは任意の許容されたデータタイプを含んでいる。 これらのデータタイプはデータ構造にグループ化されてもよい。このメッセージ
データはユーザデータベースとユーザインターフェイスへまたはそれらからマッ
プされ、その他のメッセージへ通過されてもよい。この概念はその固有のローカ
ルデータを有する機能としてメッセージを使用し、任意のローカルデータを通過
するその他の機能（メッセージ）を呼出すこともできる。このローカルデータは
共有データになる２以上のメッセージ間を通過される。
【００９８】 ネットワークで結ばれた分散されたアプリケーション機能は、InterLingua （商標名）クライアントＩＬＭＣ（ｎ）とメッセージ送信者および受信者とし てのサーバの固有の能力を使用して実行される。アプリケーションセットが１人
のサーバの１つのアプリケーションと対照的に、幾つかのサーバを横切って分散
された方法で作用されるように生成されるならば、主な差は、アプリケーション
機能として動作する１以上のメッセージがローカルサーバではなく目的地として
遠隔サーバを有することである。これは以前には見られなかった簡潔性とフレキ
シブル性で、ネットワークにされた分配アプリケーションの生成を非常に簡単に
する。
【００９９】 InterLingua （商標名）Message Client（ILMC）とサーバＳＲＶ InterLingua （商標名）Message Client（ILMC）のソフトウェアは好ましくは
Ｊａｖａにおいて全体的に書込まれ、したがって、これはほとんど全ての最も共
通して使用されるコンピュータを含むＪａｖａエネーブルコンピュータシステム
で動作できることを確実にする。ＩＬＭＣは、ＨＴＭＬ／ＶＲＭＬ／Ｊａｖａア
プレットディスプレイコンソールとして、およびサーバＳＲＶ（ｍ）への回路網
通信インターフェイスとして機能する。
【０１００】 ユーザインターフェイススクリーンは、メッセージをＨＴＭＬ定義に関連づ けメッセージとＨＴＭＬディスプレイとの間にデータをマップする能力を使用す
る。これは選択された機能（メッセージ）が必要なときにユーザインターフェイ
スを有することを可能にする。ユーザキーボードとマウス事象はフィールドアク
ションに連結される。
【０１０１】 １つのサーバから別のサーバへ、サーバと端末ＩＬＭＣ間でメッセージの送 信／受信機能を実行する通信サブシステムは高度に最適化され、マルチスレッド
方法で動作するように設計され、メッセージの完全性を監視するチェックサムの
使用をデジタル署名の使用と置換する。これは受信されたメッセージの崩壊され
ていない状態の完全な確認を可能にし、同時に送信者のアイデンティティのセキ
ュリティ確証と認証を可能にする。通信サブシステムはサーバＳＲＶと端末ＩＬ
ＭＣとの両方に存在する。通信サブシステムは回路網プロトコル独立であるよう
に設計される。現在のバージョンではＴＣＰ／ＩＰ、ＸＴＰ／ＩＰ、ＸＴＰ／Ａ
ＴＭ／ＡＡＬ５で動作するがＡｐｐｌｅＴａｌｋ、ＩＰＸ、ＳＮＡ、Ｘ．25、Ｄ
ＥＣＮＥＴ、ＯＳＩまたはソケットインターフェイスと地点を結ぶアドレススキ
ームを使用できるその他の任意のプロトコルで丁度同じように容易に動作する。
【０１０２】 通信サブシステムは本発明の臨界的な部分ではない。本発明の進歩は多数の 異なるタイプの通信サブシステムにわたって実行されることができる。当業者は
、通信サブシステムが高速度の転送の成功とデータの完全性を保証できる信頼性
のある転送プロトコルを有する限り、選択された回路網通信サブシステムのタイ
プおよび構成の詳細が本発明の機能を変更しないことを認識するであろう。
【０１０３】 欧州特許出願第97202945号明細書に記載されているようなメッセージ優先ス ケジューリングおよびサービス機構が通信サブシステムに付加されてもよい。こ
の機構は全てのメッセージ優先順位レベルに対して公平なサービスを自動的に保
証するために、個々の優先順位レベルと簡単な回路網とシステムバッファリング
アルゴリズムに対する別々の接続を使用する。この機構は、メッセージサイズを
監視し、または低い優先順位のメッセージのロックアウトを防止するために複雑
なスケジューリングアルゴリズムを必要とすることなく、高い優先順位のメッセ
ージをさらに高速度で一貫して転送する。
【０１０４】 メッセージの受信 メッセージがサーバＳＲＶ（ｍ）により受信されるとき、これは通信サブシス
テムを通過する。デジタル署名は確認され、転送層ヘッダはストリップされる。
メッセージが暗号化または圧縮されているならば、それはこのとき解読され圧縮
から復元される。メッセージは、データベースソフトウェアＩＬＭＤＢに送られ
る。
【０１０５】 メッセージ定義が所望位置にないならば、全体的なデータベースメッセージ 定義は特定のメッセージまたはメッセージグループで自動的に交換されてもよく
、それによって多数のユーザの容易に交換された共通のフォーマットメッセージ
を生成する。
【０１０６】 その代わりに、メッセージ定義が受信されたメッセージに存在しないならば 、システム管理者のインボックスに送信される。システム管理者はその後、端末
ＩＬＭＣを使用してメッセージを検査し、自動的に基本的なメッセージ定義を付
加し、必要なときにメッセージフィールドをローカルデータベースフィールドと
ＨＴＭＬディスプレイフィールドに連結することができる。システム管理者はま
た、メッセージの送信者が完全なメッセージ定義を送信することを自動的にリク
エストしてもよく、完全なメッセージ定義はローカルデータベースＩＬＭＤＢに
自動的に位置付けられる。このリクエストは１つのサーバから別のサーバへのメ
ッセージとして送出される。
【０１０７】 メッセージ定義が受信されたメッセージに存在するならば、これはデータベ ースＩＬＭＤＢから読取られる。メッセージ事前処理のアクションリストはサー
バＳＲＶ（ｍ）により実行され、メッセージフィールドの確認、データベースの
問合わせ、計算およびその他のメッセージ等の機能を定める。メッセージが表示
のためにユーザに送信されたならば、端末ＩＬＭＣのプロセッサ１はそのメッセ
ージを指示されたＨＴＭＬファイルに組込むか、または指示されたＨＴＭＬファ
イルがプロセッサ１により発見されないならば、デフォルトダイナミックＨＴＭ
Ｌを生成する。フィールドアクションはこれらがメッセージで規定されているな
らば、特別なマウスおよびキーボード事象により付勢されてもよい。フィールド
アクションは標準的なＨＴＴＰ ＵＲＬを呼出し、ローカルイメージの表示のリ
クエストを送信し、ＳＱＬデータベーストランザクションを付勢し、ローカルデ
ィスプレイデータを更新し、またはInterLingua （商標名）Script（ＩＳ）命令
を動作する。メッセージが限定されたユーザインターフェイスをもたないならば
、“サイレント”として呼ばれ、システム中のその存在はシステム管理者によっ
てのみ観察されることができる。
【０１０８】 サイレントメッセージの事前処理の終了ときに、およびＥＮＤ−ＭＳＧ命令 または端末メッセージに遭遇したとき、ユーザインターフェイスはＥＮＤ−ＭＳ
Ｇ命令を送信しメッセージ事後処理アクションのリストがサーバＳＲＶ（ｍ）に
より実行される。メッセージがアプリケーションセットの一部であるならば、こ
れはサーバＳＲＶ（ｍ）がＥＮＤ−ＡＰＰに遭遇または受信するまで、アクティ
ブで、メモリ中に残される。アプリケーションセットが終了したとき、これらが
まだ実行されていないならば、全てのメンバメッセージ事後処理リストはサーバ
ＳＲＶ（ｍ）により実行される。この機能はまたトランザクション文脈とアプリ
ケーションデータおよび状態の自動メンテナンスを保証する。１つのメッセージ
またはアプリケーションセットが完了したとき、システムメモリはクリーンにさ
れ、他のメッセージおよびアプリケーションにより使用されるように戻される。
【０１０９】 メッセージの送信 端末ＩＬＭＣから： メッセージフォーマット（ＩＬＭＦ）がリクエストされ、ＩＬＭＤＢ／−ＩＬ
ＭＳから受信される。メッセージの内容およびアドレスは端末ユーザにより付加
される。端末ユーザはユーザインターフェイス動作により、ユーザが登録されて
いるサーバへのメッセージの送信を開始する。
【０１１０】 サーバＳＲＶ（ｍ）から： メッセージは、InterLingua （商標名）Script（ＩＳ）によりサーバＳＲＶ
（ｍ）上のメッセージを付勢するため直接的な呼出しの結果として自動的に開始
されてもよく、またはサーバＳＲＶ（ｍ）により最初に受信および処理される接
続された端末のリクエストであってもよい。サーバは任意のメッセージが定めら
れているならば、メッセージの事前処理を実行する。目的地アドレスがサーバ自
体のためのものであるならば、ＥＮＤ−ＭＳＧに遭遇後または受信後にメッセー
ジの事後処理が実行され、メッセージが完了される。目的地アドレスが別のサー
バのためのものであるならば、メッセージは通信サブシステムに送られ、圧縮さ
れまたは暗号化され、デジタル署名が与えられ、地点間を結ぶ接続により受信サ
ーバへ送信される。
【０１１１】 頭文字のリスト ＡＮＳＩ＝American National Standard Institute ＣＯＲＢＡ＝Common Object Request Broker Architecture ＣＳＶ＝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
【図面の簡単な説明】
【図１】 本発明によるシステムの概観ブロック図。
【図２】 本発明によるメッセージフォーマット図。
【図３】 本発明によるメッセージフォーマット図。
【手続補正書】
【提出日】平成１２年４月１４日（２０００．４．１４）
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正内容】
【発明の名称】 オブジェクト指向地点間通信方法およびその方法を行う通
信装置
【特許請求の範囲】
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】 本発明は請求項１、10、28の前提部分にそれぞれ記載されている方法、装置、
システムに関する。これらの請求項はEP-A-0 456 249号明細書に基づいて限定さ
れている。本発明は電子データ通信、組織されたデータベース、フレキシブルフ
ォーマット電子データメッセージ管理、クライアント−サーバおよび分配された
ソフトウェアアプリケーションの分野に関する。
【０００２】 特に、本発明は、生成、通信、解釈、フレキシブルなフォーマットの電子デ ータメッセージに対する表示および実時間応答、１以上の電子データ回路網上の
１以上のコンピュータシステムを横切って選択的に分散されてもよいフレキシブ
ルなフォーマットの電子データメッセージの集合として組織されるアプリケーシ
ョンとを説明し管理するための合理的なデータベースを使用する。
【０００３】
【従来の技術】 一般目的およびビジネス用の特定の電子データ通信は４つの異なる問題に直面
しており、それらはそれぞれさらに多数の問題を有している。以下の点は電子デ
ータ通信のほとんどのカテゴリに適用されることができるが、ビジネスの通信要
件に関するこれらの問題を説明する。４つの問題とは、 １）送信され受信される電子データはそれが意味するものが明白に認識されなけ
ればならない。各企業は例えばほとんどの基本的なビジネス情報、出荷の注文書
または請求書でさえそれらを表すために種々の異なる方法を有する。 ２）一度、別の企業から電子データが受信され、正確に認識されると、受信され
た企業のデータベースおよびビジネス処理プログラムに集積されなければならな
い。各企業はそれらのデータベース構造、即ちコンピュータシステムに電子デー
タを表し記憶する方法は多数存在し、異なっている。 ３）電子データはエンドユーザに表示され、エンドユーザの対話を可能にしなけ
ればならないならば、各企業は種々のタイプのディスプレイソフトウェア、種々
のシステム要件、ビジネス要件を有する異なるタイプのコンピュータディスプレ
イ端末を使用している可能性がある。カスタム化されたグラフィックユーザイン
ターフェイスを有する非常に高価な電子データディスプレイプログラムを構築す
ることが非常に頻繁に必要とされる。 ４）特定のビジネス機能を実現するために特定化されたシステムサービスおよび
関連するデータとの組合わせを使用することが必要とされるために、１以上のコ
ンピュータシステムを横切って分散された、調整された方法でコンピュータ化さ
れたビジネス機能の処理を実行する必要がある。このことはコンピュータ化され
たビジネスシステムが１以上の位置に存在し、１以上の位置で異なる動作を行う
が、基本的には１つの単一システムのように機能することを必要とすることを意
味している。この問題に対する解決策は、分散されたアプリケーション、または
最近では“ミドルウェア”として分類される分散されたオブジェクト管理システ
ムとして区別される。
【０００４】 ４つの問題に関する２つの異なる主な問題が存在する。第１に、企業が多数 の異なるシステムで同一のビジネスアプリケーションを使用し、動作を必要とす
る各異なるシステムにおけるビジネス理論、ユーザインターフェイス、ネットワ
ーク通信インターフェイスを再度書込む必要をなくすことを要求し、所望するこ
とである。第２の問題は、通信回路網を横切って１以上のシステムにわたり１つ
のアプリケーションの機能を分割し、十分に調整された方法で動作させる必要性
である。
【０００５】 これらの全ての４つの問題を解決できる単一システムは現在存在しない。ビ ジネスは電子データ通信および記憶システムを販売、構築、再構築、メンテタン
スに毎年、数百万ドルを浪費しており、これらの４つの問題の種々の組合わせを
実効的および完全に解決していない。
【０００６】 問題１ 第１の問題を解決するため、特定のタイプの情報の１組の電子データフォーマ
ットは通信が実際に行われる前に全ての通信企業により同意されなければならな
い。さらに、フォーマットについての同意は、これらの同一の丁度同意されたフ
ォーマットを使用する通信ソフトウェアの使用によって実現されなければならな
い。ＥＤＩ（Electronic Data Interchange ）はこの問題を解決する１方法であ
る。ＥＤＩは多数のタイプのビジネストランザクションに対する１組の電子デー
タメッセージフォーマットである。フォーマットはフレキシブルではなく、これ
らはユーザにより変更されることができないことを意味し、ほんの少し異なるＥ
ＤＩメッセージのバージョンが存在する。企業はＥＤＩメッセージビジネス通信
システムを構成し、異なるバージョンのＥＤＩメッセージセットを使用して他の
企業と電子データを交換することが依然として可能ではない。既存のビジネスシ
ステムをＥＤＩに変換するのにかかる時間量および金額は莫大であり、別のフォ
ーマットが必要になるならば、それに変更または付加することは困難であり高価
である。
【０００７】 ハードコード（即ちソフトウェアで限定された）メッセージフォーマットを 使用する方法および解決策はＥＤＩに関連する全ての問題を有し、異なる固定メ
ッセージフォーマットのみについての基本的に同一の解決策である。固定メッセ
ージフォーマットが変更されなければならない度毎に、これはソフトウェアとデ
ータベースおよびユーザインターフェイスを同様に変更することを必要とする。
非常に小さい変更でさえも、時折数か月かかる。勿論、この電子メッセージフォ
ーマットは将来の電子通信が正確に継続することを確実にするため、特定のフォ
ーマットを使用してビジネス毎のコンピュータで変更されなければならない。
【０００８】 基本的に、共通のデータフォーマット幾つかの方法で送信者および受信者に より同意されなければならない必要性が常に存在する。これは現在または将来有
効な方法に存在する。カスタマに対して臨界的な問題は、方法（即ちＥＤＩ）に
ついてのシステムの構築がどの程度高速度で廉価であり、システムのあらゆる部
分（データベース、ソフトウェア、ユーザインターフェイス）において、先に同
意された電子データフォーマットの変更がどの程度容易であるかである。
【０００９】 問題２ 第２の問題は、解決がさらに困難な問題である。通常、ほとんどの企業は多数
のデータエントリ人員を使用し、彼等は印刷物を読取り、読取られたデータを処
理して端末で作動するコンピュータプログラムへ読出し、これを正確なフォーマ
ットへ変換し、企業のデータベースに位置する。ＥＤＩまたは類似の共通の電子
メッセージフォーマットを使用する企業は、非常に多額の費用をカスタム化ソフ
トウェアに費やし、カスタム化ソフトウェアはこれらの共通の電子メッセージフ
ォーマットを自動的に処理して変換し、データ記憶および検索の目的で既存のデ
ータベース構造と対話する。共通のメッセージフォーマットに対して変更または
付加が必要であるならば、またはデータベース構造の変更または拡張が必要であ
るならば、この電子メッセージフォーマットデータベースインターフェイスプロ
グラムを変更させ再度書込ませるために時間と多額の費用を費やさなければなら
ない。
【００１０】 １つの新しい公共ドメインの通常目的の解決方法は、カスタマのデータベー スまたは記憶装置の特定位置への特定データアイテムの“マッピング”を中心と
している。このマッピングはソフトウェアでは生成されないで、幾つかのさらに
容易に変更可能でフレキシブルの表示中に存在し、これはソフトウェアアプリケ
ーションおよびソフトウェアアプリケーションが読取る独立したフラットファイ
ル等のカスタマのデータベースとは分離されている。これはデータベース構造ま
たはデータ表示が変更する度にソフトウェアアプリケーションを再プログラムお
よび再構築する必要性を除去する。データフィールドマッピング技術はProgress
、Oracle、SQLBase （SQL ＝Standard Query Language ）等の多数のデータベー
ス企業により共通して使用される。よく知られた方法のバージョンは本発明の通
信装置に構成される機能および方法論の一部である。
【００１１】 問題３ 第３の問題は、容易に動作可能な通常目的の幾つかの解決策を持つことである
。解決策の１つのカテゴリはＸウィンドウズまたはマイクロソフトウィンドウズ
等の種々のウィンドウ（グラフィックユーザインターフェイス）管理システムに
対して相当の量のソフトウェアコードを書込むことを必要とする。大きい多機能
ビジネスアプリケーションでは、この方法は莫大な量の時間、費用、労力を必要
とし、ユーザインターフェイスに対する変更または付加は非常に時間を消費し、
価格的にも問題になる。
【００１２】 新しく有望な解決策のカテゴリはＨＴＭＬ（Hyper Text Markup Language） およびウェブブラウザの使用を中心とし、これはワールドワイドウェブおよびイ
ンターネットで使用されるため“ウェブページ”と通常呼ばれている非常に見掛
けの良いグラフィックユーザインターフェイスをダイナミックを生成することが
できる。これには多数の企業が興味を示している。企業は、ＨＴＭＬを使用して
いかに迅速で廉価に非常に見掛けの良いグラフィックユーザインターフェイスを
作成されることができるかを観察し、電子データ通信および処理プログラム用の
ユーザインターフェイスがウェブブラウザシステムと同一方法で生成され同じ回
路網で通信するか否かの疑問をもつ。実際、企業は全ての範囲のビジネスおよび
パーソナルデータおよびメッセージを送信および受信するためにインターネット
を使用することができることを好む。
【００１３】 現時点では、ＨＴＭＬおよびウェブブラウザを使用して、インターネットに わたる限定された範囲のビジネスおよび汎用のデータ通信を可能にする有効な幾
つかのシステムが存在する。データ通信のタイプが限定される理由は、ウェブサ
ーバ／ウェブブラウザシステムが十分なデータ通信サービスを行うように設計さ
れていなかったことである。それらはダイナミックなドキュメントの検索および
ディスプレイシステムとして設計された。それらはユーザからのリクエストとし
て最初に初期化される情報を検索できる。それらは広範囲の付加的なプログラミ
ングによることを除いて、１以上の目的地へ情報を送信する能力をユーザに与え
ない。送信能力はシステムに固有ではない。このタイプの例は、Progress' WebS
peed、IBM's WebEDI、SapphireGroup's PageBlazerである。
【００１４】 いわゆる“プッシュ”技術を構成するウェブブラウザおよびウェブサーバの “新しい”特徴でさえも送信をすることはできずデータ受信のみを可能にする
。この“受信”は、ウェブブラウザおよびウェブサーバシステムにより実際はシ
ミュレートされた放送受信機として情報（ポーリング）の隠れた反復リクエスト
が設定される。この“プッシュ”技術を拡張するための計画は、真の放送および
マルチキャスト通信技術の使用だけを含んでいる。“プッシュ”技術の例は、Ma
rimba のCastanetおよびTibco のＴＩＢ ＡＰＩである。このいわゆる“プッシ
ュ”技術は新しい方法で大市場まで広げることを要求する広告業者には大きな関
心事であるが、既存のデータベースおよびビジネスシステムに容易に集積される
ことができる地点間のプロトコルを使用した十分に集積された双方向情報通信の
内容で、ＨＴＭＬおよびインターネットの進んだドキュメントディスプレイ特性
を使用することを要求または必要とする企業または個人にはほとんど使用されな
い。
【００１５】 インターネットのウェブサーバとウェブブラウザインターフェイスは、ウェ ブページのリクエストとしてメッセージをエンドユーザへ送信することを可能に
するように設定される。電子メールを除いてウェブブラウザユーザはメッセージ
を別のウェブブラウザユーザへ送信し、またはウェブページを別のウェブブラウ
ザユーザへ送信できることはなかった。ウェブブラウザユーザは最初に求められ
ていなかった特定のメッセージを受信したことはなく、いわゆる“プッシュ”技
術情報でさえもポーリングおよび情報特性によりリクエストされることはなく、
カスタム化されたときでさえもテレビジョン放送または大量のメーリングと比較
されることができない。情報は１つの特定の受信者に対して送信されてはいない
。これは例えば電子メール（ｅメール）と対照的である。ｅメールサービスを使
用すると、最初に、送信者に要求せずに、任意の数の特別な私用メッセージを受
信することができる。最初に要求せずに、任意の数の特別な私用メッセージを特
定の受信者へ送信することができる。これはメッセージの一般的な必要な特性で
ある。インターネットのウェブサーバシステムはこのような通信を行うように設
計されていなかった。
【００１６】 企業および個人がこのようにこれらを使用することに関心をもつ理由は何で あろうか？。彼等は単にｅメールを使用したらどうか？。その答えはｅメールが
（ＨＴＭＬが行うように）それに組込まれたデータフォーマットサービスをも
たず（ウェブブラウザが行うように）それに組込まれたユーザインターフェイス
生成をもたないからである。ｅメールメッセージはまたその目的地に到達するた
めに不確定の時間量（数秒から数日）かかり、時には失われなくなることもある
。これは標準的なビジネス電子データ通信に対しては許容できない。この理由で
企業および個人は、それに組込まれた非常に良好なデータディスプレイ能力と、
適度に高速度の通信を有するウェブサーバ／ウェブブラウザシステムを好む。し
かしながら、前述したように、地点間通信能力またはデータ表示およびマッピン
グ能力をもたない。
【００１７】 本発明では、公共ドメインＨＴＭＬ標準は非常に容易に構築され、高速度で フレキシブルなグラフィックユーザインターフェイスを生成するための解決手段
として組込まれてもよい。
【００１８】 問題４ 歴史的に、問題４は、非常に最近まで関係型データベース管理システム（ＲＤ
ＢＭＳ）だけによって一般的な方法でアドレスされてきた。このクラスの解決策
は分散された問合わせおよび分散されたデータベース管理の適切な機能を解決す
るように限定されており、先に説明した問題４の主要な２つの問題をアドレスし
ない。
【００１９】 第２の、新しいクラスの解決策は“ミドルウェア”または分散されたオブジ ェクト管理システムと現在呼ばれているシステムで見られる。これの良い例はＣ
ＯＲＢＡ（Common Object Request Broker Architecture ）と呼ばれるシステム
である。ＣＯＲＢＡの開発経歴、目的、ＣＯＲＢＡ 2.0の現在の機能および欠点
における優秀な文献セットは、Warren Kayffill 、“CORBA masterminds object
management ”、42頁、ＤＢＭＳマガジン10巻、No.3、1997年３月と、同じＤＢ
ＭＳ出版のT.J.Hart“Questioning CORBA. Bringing Corba-based designs to l
ife faces a multitude of obstacles”、52頁で見られる。
【００２０】 このクラスの解決策はデータベースの共同使用可能性問題と、アプリケーシ ョンレベルの共通のデータフォーマット問題またはユーザインターフェイス問題
をアドレスする。これは通信レベルで標準的な通信インターフェイスおよび標準
的なデータによりアプリケーションを書込む能力だけをアドレスする。基本的に
、このタイプのシステムは開発環境と、実行時の環境と、１組のソフトウェアラ
イブラリを供給し、これによってプログラマは任意のシステムで実行するアプリ
ケーションを生成することができ、コードのデータ構造（いわゆるオブジェクト
）を定めた後にこれらのデータ構造は、これらの特定のデータ構造を認識し、使
用するようにコード化されているその他のソフトウェアプログラムと交換される
ことができる。
【００２１】 この能力および機能は、根本的にJavaにおいてメッセージ通信システムを書 込むプログラマとは異なっておらず、これはほとんど任意のシステムで動作し、
ＥＤＩメッセージまたは通信媒体等の幾つかのその他の同意された固定フォーマ
ットを使用する。ＣＯＲＢＡシステムはメッセージを何等解釈しない。プログラ
マにより書込まれたアプリケーションはメッセージを認識できなければならない
。これはＣＯＲＢＡアプリケーションに、ＥＤＩまたは固定されたメッセージフ
ォーマットアプリケーションシステムと同様の開発、変更、メンテナンスの価格
および時間についての全ての問題を残す。ＣＯＲＢＡによって可能な分散された
機能でさえも、ＣＯＲＢＡで固有ではなく、アプリケーションを設計およびコー
ド化するプログラマの技能とＣＯＲＢＡ通信ライブラリの使用が基本的に必要で
ある。根本的に、ＣＯＲＢＡの唯一の明白な利点は、多数の実行時の環境にわた
ってアプリケーションシステムの部分の共同使用可能性であり、これは恐らくJa
vaのようなその他の手段により良好に得られることができる。
【００２２】 基本的に、ほとんどのケースの“ミドルウェア”は実際には標準的な通信環 境と幾つかの標準化されたソフトウェア機能を多数のコンピュータで与える丁度
別の電子データ通信環境であるように見えるが、ソフトウェアアプリケーション
構築の全ての特徴をアドレスすることはできず、データベースインターフェイス
およびユーザインターフェイスに対するシステム依存コードの使用を必要とし、
それによってＣＯＲＢＡ等のシステムを使用する主要な目的を無効にする。
【００２３】 ＣＯＲＢＡ機能をJavaに吸収し、ＯＤＢＣと呼ばれる標準化されたデータベ ースインターフェイスを含むシステム、またはJavaシステムＪＤＢＣに存在する
幾つかのシステムが存在する。これは興味深い開発であるが、ＯＤＢＣデータベ
ースインターフェイスのように、読取り専用の問い合わせにのみ有効であり、十
分なデータベースアクセスを必要とする標準的なビジネストランザクションシス
テムは適切に生成されることができない。また、この組合わせは問題１または２
を全くアドレスしない。さらに、ＯＤＢＥＣの使用とＣＯＲＢＡオブジェクトブ
ローカーシステムの不適切なオーバーヘッドのために、これは本発明を構築する
ための所望のプラットフォームではない。
【００２４】 さらに従来技術は、以下簡単に説明する幾つかの特許明細書にも記載されて いる。米国特許第5,257,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 、EP0,747,843 A1 、EP-0,747,844 A1 、EP-0,747,845 A1 明細書（全てInternational Business M
achines Corporation ）では幾つかの形態のデータベースアクセスにより現在の
ウェブサーバ機能を強化することに焦点を置き、それ故、前述したウェブサーバ
の通信限界により制限される。それ故、これらの発明は問題１と４を全く解決で
きず、限定された方法でのみ問題２と３を解決する。さらに、Progress Databas
e Corporation からのWebSpeedのようなウェブサーバ強化において同じまたはさ
らに多くの機能を与えるように見える幾つかの市場で入手可能なシステムが存在
する。
【００２８】 WO 95/11560 号明細書（Sybase社）には、使用されるコンピュータハードウ ェアまたはオペレーティングシステムにかかわりなく、アプリケーションが構築
される一貫した電子データ通信ソフトウェアインターフェイスを生成する問題だ
けを解決する“ミドルウェア”のカテゴリについて記載されている。この明細書
は任意の方法で通信される電子データのフォーマットをアドレスせず、この問題
はＣＯＲＢＡに非常に類似し、本発明によりアドレスされる４つの問題の視点か
ら全ての同一の制限を有する。
【００２９】 EP 0 421 624 A2 号明細書（Texas Instruments Incorporated）はＣＯＲＢ Ａ等の“ミドルウェア”システムと、アプリケーション開発環境の組合わせにつ
いて記載されている。データベース制御され管理されたソフトウェア開発環境を
使用して、ここで記述された発明はプログラマがＣ、ＣＯＢＯＬ、ＳＱＬのアプ
リケーションを開発することを可能にする。データベースは、大きいグループの
プログラマが複雑なデータベーストランザクションアプリケーションのソースコ
ード制御技術を開発し、変更し、使用することを可能にする情報を含んでいる。
この明細書では、多くはＩＢＭメインフレームシステムおよび幾つかのＵｎｉｘ
システムについて説明しているが、データベースはまたアプリケーションが別の
ハードウェアシステムで再度コンパイルされ、各タイプのコンピュータで同一方
法で機能することを可能にする情報も含んでいる。最終結果は一連のハードコー
ド化されコンパイルされたアプリケーションであり、全ての問題が問題１および
２で説明されているのと同一であり、部分的にのみ問題３、４を解決する。
【００３０】 EP 0,456,249 A2 号明細書（Hewlett-Packard Company ）はＣＯＲＢＡ等の “ミドルウェア”システムと、主要な能力が異なった高レベルのプログラミン
グ言語で開発されている既存のアプリケーションと連結している部分的なアプリ
ケーション開発環境の組合わせである。本発明で述べる高レベルの言語はそれら
のデータの異なる実行時間メモリ内組織を有し、１つの言語組織から別の言語組
織へデータを変換しなければならない。結局、中間データ表示およびデータ転送
命令は、データ表示をコンパイルし、命令を転送した後、その発明が１つの言語
の実時間表示からの識別されたデータ構造を別の言語の実時間表示からの識別さ
れたデータ構造へ変換することを可能にする。この発明はアプリケーションとし
て独立して実行するために必要な全てのデータおよび命令を含んでいるメッセー
ジフォーマットを任意の方法でアドレスせず、２つの予め存在するアプリケーシ
ョン間の特定されたデータ構造を変換するのに必要なデータおよび命令のみをア
ドレスする。それ故、この発明は問題２と３で説明されている問題を全くアドレ
スせず、ここで説明しているようなアプリケーションレベルではなくプログラミ
ング言語のレベルで問題１と４の問題を部分的にのみアドレスする。対照的に、
本発明では、アプリケーションは全体的にメッセージから構成され、それ故、１
つの言語からのデータを別の言語のデータへ変換することはなく、メッセージフ
ォーマットまたは命令のコンパイルは必要とされず、全てのデータはそれが送信
されてもコンピュータメモリ中に残っていても、メッセージフォーマットに残留
する。
【００３１】
【発明が解決しようとする課題】 前述したように、各これらの４つの問題を解決でき解決策を１つの一体化され
た統一体に結合することができる１つの通信システムおよび方法が緊急に必要と
される。複雑な電子データ通信システムを構築しなければならない個人および企
業と、日常ベースでこれらの問題に直面しなければならない人にはこれは有効で
ある。このようなシステムおよび通信方法は電子データ通信システムを構築し、
維持する時間、価格、複雑性を劇的に減少する。
【００３２】
【課題を解決するための手段】 前述の目的を獲得するために、本発明は請求項１の前提部分で限定され、特徴
部分によって特徴付けられている送信機と受信機との間の地点間通信方法を特徴
とする。
【００３３】 結果として、定められたアプリケーションレベル機能の全ての素子がメッセ ージフォーマット中に存在し、これは既に回路網通信システムの文脈中にあり、
それ故単に位置および目的地アドレスを変更することによって容易に分配される
ことができる。
【００３４】 さらに、本発明によれば、通信装置は請求項10にしたがって限定されている 。
【００３５】 したがって、本発明においては、任意のタイプのデータを含むことができ、 メッセージ自体内のデータを十分に記述するのに十分な情報を含んだフレキシブ
ルなメッセージフォーマットが規定される。任意のメッセージは、データベース
に予めロードされたメッセージ定義を識別するためメッセージを受信する上記の
通信装置により使用されるメッセージ定義基準を含んでいる。しかしながら、予
めロードされたメッセージ定義は一度も全く固定されないので技術はフレキシブ
ルである。メッセージを受信する通信装置内では、メッセージを十分に記述しそ
れを特有の識別子と参照する関連するデータベース表中にエントリを挿入し、更
新し、または消去することによって、メッセージフォーマットの特定インスタン
スが生成され、編集されまたは消去される。さらに、メッセージ定義が所望の位
置に存在しないならば、全体的なデータベースメッセージ定義は特定のメッセー
ジまたはメッセージのグループに対して自動的に交換されてもよく、それによっ
て多数のユーザの容易に交換される共通のフォーマットメッセージを生成する。
本発明のさらに別の利点は必要なオーバーヘッド量が少いことである。
【００３６】 メッセージ定義基準内のフィールドの例は、任意のメッセージを識別するた めのメッセージ識別子と、メール、ビジネスメッセージ、注文または発送等の任
意のメッセージのメッセージクラスを識別するメッセージクラス識別子と、任意
のメッセージのバージョン番号を識別するメッセージバージョン識別子と、任意
のメッセージのクリエイタを識別するメッセージクリエイタ識別子である。メッ
セージ定義基準内の任意のこれらのフィールドは上述の通信装置のメッセージ定
義表内に対応するフィールドを有する。
【００３７】 さらに、メッセージのヘッダは使用される暗号化および／または圧縮タイプ の基準を含んでいる。またこれらの基準は通信装置のメッセージ定義表中に対応
部分を有している。
【００３８】 好ましくはメッセージの内容はデジタル署名により保護される。
【００３９】 好ましくは通信装置のデータベースは幾つかの表で組織され、その表に対し てメッセージ定義表から参照を行う。予め定められたメッセージ定義表はデータ
ベースのさらに別の表の参照として使用するためのメッセージシステム識別子を
含んでいる。
【００４０】 このようなさらに別の表のうちの１つはメッセージの任意のフィールドの主 な定義を保持するためのフィールド定義表であってもよい。
【００４１】 好ましくは、さらにこのような表のうちの１つは、例えばハイパーテキスト マークアップ言語フィールド、データベースフィールド、フラットファイルフィ
ールドおよびその他のメッセージフィールドにマップするための、予め定められ
たフィールドにより使用可能なマッピング指令を含むフィールドマッピング表で
あり、前記データベースフィールドとフラットファイルフィールドはカスタマデ
ータベース中に記憶されている。本発明にしたがったメッセージフォーマットは
、データだけではなく、ユーザインターフェイス、カスタマデータベースフィー
ルド、計算および条件論理を含むアクションシーケンスのマッピング命令を含ん
でいる。結果として、アプリケーションレベル機能を規定する全ての要素はメッ
セージフォーマットに存在し、それは既に回路網通信システムの文脈中にあり、
それ故位置および目的地アドレスを単に変更することにより容易に分布されても
よい。さらに、このようにＨＴＭＬ標準は、非常に容易に構築され、高速度でフ
レキシブルなグラフィックユーザインターフェイスを生成し、上述の通信装置に
より管理され、規定され、制御され、マイクロプロセッサ等のユーザ端末と対話
され通信装置へ接続されるように、本発明により限定されたメッセージフォーマ
ットへのマッピングおよびそこからの直接的なマッピングを可能にするために設
けられてもよい。
【００４２】 さらに、このような別の表のうちの１つは予め定められたフィールドにより 使用可能なメッセージアクションリストを含むフィールドアクション表であって
もよい。
【００４３】 好ましくは、さらに別の表は、受信または送信されるメッセージの前処理と して実行されるアクションリストを含むメッセージ前処理表、および受信される
メッセージの後処理として実行されるアクションのリストを含むメッセージ後処
理表である。
【００４４】 フィールドアクション表、メッセージ前処理表、メッセージ後処理表は以下 のアクションのグループ、即ちアクションのデータベースタイプと、数学的演算
、割当、論理演算、条件演算、命令を含むアクションの論理タイプから選択され
たアクションのタイプの基準を含んでいる。
【００４５】 好ましくは、本発明においては、アプリケーションは１以上のメッセージの 名前を付けられたグループとして定められる。すなわち、メッセージ定義表は受
信されたメッセージがアプリケーションの最初のメッセージであるか否かを示す
アプリケーションフィールドと、アプリケーションの名称を参照するためのアプ
リケーション名称フィールドとを含んでいる。
【００４６】 本発明によると、通信装置は、受信されたメッセージがそのデータベース中 に存在しないメッセージ定義を参照した場合には、送信者からの新しいメッセー
ジ定義をリクエストし、前記送信者から前記新しいメッセージ定義を受信し、前
記データベースの前記メッセージ定義表にこれを記憶するように構成されること
が好ましい。
【００４７】 通信装置の処理手段は、指定されたＨＴＭＬファイルで受信されたメッセー ジをマージするか、または指定されたＨＴＭＬファイルが処理手段により発見さ
れなかった場合には、デフォルトダイナミックＨＴＭＬファイルを生成するよう
に構成されてもよい。しかしながら、その代わりに、通信装置の処理手段は、接
続された端末にこれらの機能を実行するように指令してもよい。それ故、本発明
は先に規定したような通信装置と、通信装置に接続され端末プロセッサを有する
端末とを具備するシステムにも関し、端末は端末プロセッサと、ディスプレイ装
置と、ユーザによるデータを入力するための入力手段とを具備し、通信装置は、
端末がメッセージ中で目的地アドレスであることを示されたならば、受信された
メッセージを端末に送るように構成され、端末プロセッサは指定されたＨＴＭＬ
ファイルでメッセージをマージするか、または指定されたＨＴＭＬファイルが端
末プロセッサにより発見されなかった場合にはデフォルトダイナミックＨＴＭＬ
を生成するように構成される。
【００４８】 したがって、端末プロセッサが対応するメッセージ定義をもたないメッセー ジを受信するユーザ端末は、システムの自動解釈とディスプレイに依存すること
ができ、これは受信されたメッセージ内に含まれる自己記述情報に基づいている
。この同じ自己記述情報は、メッセージによって参照されたデータベースメッセ
ージ定義が発見されることができない場合には端末プロセッサによりデフォルト
データベースメッセージ定義を自動的に生成するために使用されることができる
。このようなデフォルトデータベースメッセージ定義は、端末ユーザにより編集
され、ローカルシステムに適合されることができる。
【００４９】 本発明は、問題１および４に対する完全に新しい解決策を有する特有の方法 で組合わされて問題２および３に対する現在知られているの解決策を含んでおり
、全てはフレキシブルメッセージフォーマットおよび通信装置からなる特有のフ
レキシブルフォーマット電子データメッセージ管理システムを中心として構築さ
れる。
【００５０】 関連データベース表に記憶された詳細な情報により規定され制御される本発 明のメッセージ管理システムは、最も効率的で、完全で、簡単に、フレキシブル
フォーマットで電子データを通信する方法を使用することを可能にする。フレキ
シブルメッセージフォーマットは、任意の形態の電子データを含むことを可能に
する。フレキシブルメッセージフォーマットは、メッセージが先に受信されてい
なくても、受信機がメッセージの内容を解釈し、理解し、表示することを可能に
する情報を含んでいる。受信機はまたソフトウェアを書込みまたは変更せずに、
この未知のメッセージフォーマットをその固有のメッセージデータベースへ付加
しこれをそのビジネスデータベースおよびＨＴＭＬユーザインターフェイスに非
常に容易に素早く連結することができる。ＨＴＭＬユーザインターフェイスは、
また特定化され先に生成されたＨＴＭＬファイルが存在しない場合に端末のソフ
トウェアによりダイナミックに生成されることもできる。これは第１の問題を解
決する。
【００５１】 本発明では、主要な合理的データベースへのＡＮＳＩ標準ＳＱＬインターフ ェイスが設けられてもよい。このインターフェイスは後で記憶または検索のため
に関連データベース表中のフィールドへユーザが選択したデータメッセージのフ
ィールドを自動的に連結するサービスを行う。このデータマッピングインターフ
ェイスは固定した長さのフィールドおよびＣＳＶ（カンマで分離された値）ファ
イルのようなフラットファイルフォーマットへ連結することもできる。このデー
タマッピングインターフェイスは、メッセージデータフィールドをＳＮＭＰおよ
び自動処理制御用の製造プロトコルのような多数の他のフォーマットに連結する
ように拡張されることができる。このデータマッピングインターフェイスはＩＬ
ＭＤＢ中のエントリにより規定され、ＩＬＭＳにより制御される。これは第２の
問題を解決する。
【００５２】 本発明では、メッセージ制御ユーザインターフェイス端末が設けられ、ここ でユーザはメッセージを生成し、編集し、受信し、送信し、観察する。メッセー
ジ制御ユーザインターフェイスは本発明にしたがって構成された回路網およびメ
ッセージ管理サーバと通信する。本質的に、本発明は十分なデータ通信能力を必
要とする個人または企業に対する現在のウェブサーバ／ウェブブラウザ技術を置
換し、任意のデータ通信回路網を含むようにシステムドメインを拡張する。これ
はＨＴＭＬ、ＶＲＭＬ、Ｊａｖａアプレット、ならびにユーザが特定のメッセー
ジ中で規定された任意の特定データの十分な送信および受信を可能にする。先に
示した特徴と組合わせるとき、これは十分な、データベース制御されたメッセー
ジ中のデータ間の連結と、検索されるまたは記憶しなければならないカスタマデ
ータソースと、表示されなければならないグラフィックユーザインターフェイス
（ＨＴＭＬ等）を与える。
【００５３】 前述の問題を解決することに加えて、本発明は自動的な、システムが実行す るアクションを規定する能力を付加し、これはメッセージの前処理および後処理
として組織され、またはグラフィックユーザインターフェイスと連結したメッセ
ージの場合、フィールド選択アクションを規定する能力を付加してもよい。これ
らのアクションはＳＱＬまたは“InterLingua （商標名）スクリプト”として限
定される。InterLingua （商標名）スクリプト”（ＩＳ）は本発明において規定
され、簡単でしかも強力なセットの計算、実行および条件論理制御ステートメン
トであり、これはダイナミックに解釈され実時間で実行され、全てのメッセージ
データフィールドと対話できる。アクションは新しいメッセージと、システム機
能と外部プログラムに作られた呼びとを生成し、またはデータベースの問合わせ
を送信および受信することができる。これらのアクションは例えば自動メッセー
ジ応答と自動フィールド確認を生成し、計算を実行し、Ｊａｖａアプレットまた
は複雑なデータベーストランザクションを実行する。
【００５４】 本発明では、１組のメッセージおよびそれらの関連したアクションとして定 義されているアプリケーションの非常に特有の方法を含んでいる。メッセージ間
の対話の豊富さとフレキシブル性のために、データベーストランザクションを実
行する能力はグラフィックユーザインターフェイスとマージ（合体）またはそれ
を生成するか、または背景プロセスとしてシステムで静かに実行し、データメッ
セージの集合およびそれらの関連アクションとして複雑なアプリケーションを十
分に限定することができる。これらのメッセージはそれらの特性によってシステ
ムの基本的な機能として非常に容易に送信され受信され理解され組織化されるの
で、これは分散されたアプリケーション処理の範囲で大きな内包を有する。この
ことは、最初に、任意のソフトウェアコードを変更または付加せずに、分配され
たアプリケーションシステムが同一のアプリケーション（メッセージセット）を
使用しながら、各位置においてローカルユーザインターフェイスと（ビジネスデ
ータベースのような）カスタマデータソースインターフェイスを容易にフレキシ
ブルに限定できることを意味する。
【００５５】
【発明の実施の形態】 本発明を幾つかの図面を参照して説明するが、それは本発明を例示することの
みを目的とし、本発明の技術的範囲を限定するものではない。 図１では、複数のサーバＳＲＶ（ｍ）（ｍ＝１，…，Ｍ）が示されている。任
意のサーバＳＲＶ（ｍ）は１以上の端末に接続されてもよい。サーバＳＲＶ（１
）に接続する端末はＩＬＭＣ（ｎ）（ｎ＝１，…，Ｎ）と呼ばれる。頭文字“Ｉ
ＬＭＣ”はInterLingua （商標名）Message Clientから得られる。接続は参照符
号４、５で示されている。
【００５６】 さらに、サーバＳＲＶ（１）はカスタマデータベースＣＤＢ（１）に接続さ れている。１つのカスタマデータベースＣＤＢ（１）が示されているが、必要な
らば１よりも多数のカスタマデータベースが与えられることができる。
【００５７】 端末ＩＬＭＣ（１）は図１でさらに詳細に示されている。端末ＩＬＭＣ（１ ）はモニタスクリーン６、処理装置１、キーボード12、マウス13を含んで示され
ている。キーボード12とマウス13は処理装置１に接続されている。勿論、ユーザ
によりデータを処理装置１に入力するためのその他の既知の手段が、キーボード
12とマウス13の代わりにまたはそれらに加えて可能である。
【００５８】 モニタスクリーン６は幾つかの“ボタン”７、８、９、10、11を示している 。これらのボタンは処理装置１に予め定められたタスクを実行するように指令す
るためにマウス13によりユーザにより付勢されることができる。このような予め
定められたタスクはオプションを開くこと、接続の設定、メッセージの送信、メ
ッセージの受信および／またはデータを処理装置１のメモリに負荷することなど
である。
【００５９】 サーバＳＲＶ（１）には本発明の方法にしたがってメッセージを受信、通過 または送信するためのInterLingua （商標名）メッセージサーバＩＬＭＳと呼ば
れるプロセッサが設けられている。ＩＬＭＳプロセッサの部分はＩＳ（＝InterL
ingua （商標名）Script）で示され、その機能を以下説明する。
【００６０】 サーバＳＲＶ（１）はまた後述するように、本発明による幾つかの表を記憶 するためのデータベースＩＬＭＤＢ（＝InterLingua （商標名）Message Databa
se）を具備している。
【００６１】 サーバＳＲＶ（１）は通信路２を経て相互のサーバとの地点間の通信のため に配置されている。通信路２は任意の既知の方法、即ち有線または無線により設
定されることができる。
【００６２】 図１は１以上の端末ＩＬＭＣに接続された幾つかのその他のサーバＳＲＶ（ ｍ）を示している。これらのさらに別のサーバＳＲＶ（ｍ）は本発明にしたがっ
て組織され、以下さらに詳細に説明する。
【００６３】 図２および図３のａ、ｂ、ｃ、ｄはメッセージフォーマットを示している。 図２では、メッセージフォーマットは、メッセージを受信する任意の装置により
メッセージ定義参照として使用される４つのフィールド、即ちＭＳＧ ＩＤ、Ｍ
ＳＧ クラス、ＭＳＧ バージョン、ＭＳＧ クリエイタを含むように示されて
いる。
【００６４】 フィールドＭＳＧ ＩＤはメッセージを識別する。
【００６５】 ＭＳＧ クラスは、メール、ビジネスメッセージ、注文または発送のような メッセージのカテゴリまたはタイプを指定するために使用される。
【００６６】 フィールドＭＳＧ バージョンは関係するメッセージのバージョン番号を識 別するためのメッセージバージョン識別子を有している。
【００６７】 第４のフィールドＭＳＧ クリエイタは関係するメッセージのクリエイタを 識別するためのメッセージクリエイタ識別子を具備している。
【００６８】 ＭＳＧ ＩＤ、クラス、バージョンフィールドは整数値である。例えばＭＳ Ｇ クラス当たり1,000,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 フィールド動作定義（フィールド当り１動作） msgpre メッセージ事前処理（メッセージアクションのシーケンス） 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.msghtml）のフィールド
を特定する。 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 は同一構造を有する。表“msgpre”は特定のメッセ
ージの事前処理としてサーバプロセッサＩＬＭＳにより実行されるアクションの
リストを保持する。これは任意のディスプレイまたはフィールドアクションが行
われる前に、サーバプロセッサＩＬＭＳがリストまたは事前処理機能を完了する
ことを意味する。表“msgpost ”は特定のメッセージの事後処理としてサーバプ
ロセッサＩＬＭＳにより実行されるアクションのリストを保持する。これは全て
のその他のメッセージアクションおよびディスプレイの終了後に、サーバプロセ
ッサＩＬＭＳが主メモリからメッセージを削除する前に事後処理機能のリストを
完了することを意味する。このプロセスのシーケンス番号はアクションのリスト
の制御された実行を生成するために使用される。先のシーケンス番号は次のシー
ケンス番号が開始できる前に完了しなければならない。同一のシーケンス番号を
有する動作が１よりも多数存在するならば、これらは同一の時間、または多数の
ＣＰＵ内、または真の並列処理として多数の並列環境で開始される。
【００９０】 表：msgore フィールド名称 タイプ 説明 msysid 整数 メッセージシステムＩＤ procseq 整数 処理シーケンス 次のフィールドは動作タイプ、即ちＳＱＬまたはＩＳ、ファイルまたはローカ
ルを限定する。 proctype char 事前処理のタイプ 次のフィールドはＳＱＬ、ＩＳまたは内容がＳＱＬまたはＩＳであるファイル
名を含んでいる。 procscript char 事前処理スクリプト 表：msgpost フィールド名称 タイプ 説明 msysid 整数 メッセージシステムＩＤ procseq 整数 処理シーケンス 次のフィールドは動作タイプ、即ちＳＱＬまたはＩＳ、ファイルまたはローカ
ルを限定する。 proctype char 事後処理タイプ 次のフィールドはＳＱＬ、ＩＳまたは内容がＳＱＬまたはＩＳであるファイル
名を含んでいる。 procscript char 事後処理スクリプト InterLingua （商標名）Script（アクションの定義および制御言語） メッセージ事前処理、事後処理用の動作またはフィールド動作はＳＱＬ動作ま
たはＩＳ動作である。ＳＱＬ（構成された問合わせ言語）は合理的なデータベー
ス用のＡＮＳＩ標準インターフェイス言語である。ＩＳ（InterLingua （商標名
）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><parameter I> …<parameter n>
メッセージの実行： ILMP://<host-name>/<message id> 内部機能の実行（これはほとんどユーザインターフェイス事象で使用される）
ILMP://<host-name>/<message id>/<field id>[UI-ACT ｜MSG-END ｜APP-END]
ILMP://<host-name>/<message id>/<field id>[ADD-DATA ｜DEL-DATA｜CHG-DA
TA]<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 Architecture ＣＳＶ＝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
【図面の簡単な説明】
【図１】 本発明によるシステムの概観ブロック図。
【図２】 本発明によるメッセージフォーマット図。
【図３】 本発明によるメッセージフォーマット図。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ， ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，Ｌ Ｕ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ， ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，Ｕ Ｇ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 ブランク、チップ オランダ国、エヌエル − 4823 イーイ ー・ブレダ、グローテ・ディーク 55 Ｆターム(参考） 5K034 AA10 AA14 FF01 GG02 HH63 KK27 SS03

Claims (27)

    【特許請求の範囲】
  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. 【請求項２７】 端末は端末プロセッサ（１）と、ディスプレイ装置（６）
    と、ユーザによりデータを入力するための入力手段（12、13）とを具備し、通信
    装置は、前記端末が目的地アドレスをメッセージで示されたとき前記端末で受信
    されるメッセージを通過するように構成され、前記端末プロセッサ（１）はメッ
    セージを指示されたＨＴＭＬファイルへ組込み、また、指示されたＨＴＭＬファ
    イルが端末プロセッサ（１）により発見されなかった場合にはデフォルトダイナ
    ミックＨＴＭＬを生成するように構成されている請求項１０乃至２５記載のいず
    れか１項記載の通信装置（ＳＲＶ（ｍ））および前記通信装置に接続される端末
    （ＩＬＭＣ）を具備しているシステム。
JP2000516468A 1997-10-13 1998-10-13 オブジェクト指向地点間通信方法およびその方法を行う通信装置 Expired - Fee Related JP3274131B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP97203174A EP0909068B1 (en) 1997-10-13 1997-10-13 Method and apparatus for structured communication
EP97203174.4 1997-10-13
PCT/NL1998/000586 WO1999020025A2 (en) 1997-10-13 1998-10-13 Method and apparatus for structured communication

Publications (2)

Publication Number Publication Date
JP2001520486A true JP2001520486A (ja) 2001-10-30
JP3274131B2 JP3274131B2 (ja) 2002-04-15

Family

ID=8228820

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000516468A Expired - Fee Related JP3274131B2 (ja) 1997-10-13 1998-10-13 オブジェクト指向地点間通信方法およびその方法を行う通信装置

Country Status (22)

Country Link
US (1) US6880016B1 (ja)
EP (2) EP0909068B1 (ja)
JP (1) JP3274131B2 (ja)
KR (1) KR20010024487A (ja)
CN (1) CN1276123A (ja)
AT (1) ATE200373T1 (ja)
AU (1) AU729456B2 (ja)
BR (1) BR9812919A (ja)
CA (1) CA2305462C (ja)
DE (1) DE69704489T2 (ja)
DK (1) DK0909068T3 (ja)
ES (1) ES2158445T3 (ja)
GR (1) GR3036076T3 (ja)
HU (1) HUP0101695A3 (ja)
ID (1) ID24180A (ja)
IL (1) IL135612A (ja)
IS (1) IS5427A (ja)
NO (1) NO20001803L (ja)
PL (1) PL340333A1 (ja)
PT (1) PT909068E (ja)
TR (1) TR200000985T2 (ja)
WO (1) WO1999020025A2 (ja)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0909068B1 (en) * 1997-10-13 2001-04-04 X-Way Rights B.V. Method and apparatus for structured communication
AU2000241369A1 (en) * 2000-04-20 2001-11-07 Nokia Corporation A communication terminal
US7418254B2 (en) * 2001-02-20 2008-08-26 Microsoft Corporation Mobile communication device dynamic service application and dynamic service application scripting
DE10120369A1 (de) * 2001-04-25 2002-11-07 Axit Ag Verfahren zur Verarbeitung von Daten über das Internet
US7185105B2 (en) * 2001-05-11 2007-02-27 Bea Systems, Inc. Application messaging system with flexible message header structure
KR100491660B1 (ko) * 2001-08-31 2005-05-27 유티스타콤코리아 유한회사 에이티엠 시스템에서 데이터 전송 방법
CN100409238C (zh) * 2002-09-03 2008-08-06 Sap股份公司 中央主数据管理
KR20040063302A (ko) * 2003-01-06 2004-07-14 타이거솔루션 주식회사 비지니스 어플리케이션과 운영체제 층 사이에 논리적인통신수단을 포함하는 컴퓨터시스템 및 컴퓨터시스템의제어방법
CN100359865C (zh) * 2004-12-13 2008-01-02 华为技术有限公司 一种检测方法
US20070094278A1 (en) * 2005-10-21 2007-04-26 Andreas Huppert Data transfer services
US8015061B2 (en) * 2005-10-21 2011-09-06 Sap Ag File export channel
US8214439B2 (en) * 2005-12-06 2012-07-03 Microsoft Corporation Document object model API for MIME
EP1826715A1 (en) * 2005-12-30 2007-08-29 BRITISH TELECOMMUNICATIONS public limited company Generating data messages
TWI386817B (zh) * 2006-05-24 2013-02-21 Kofax Inc 提供電腦軟體應用程式之使用者介面的系統及其方法
US7925783B2 (en) * 2007-05-23 2011-04-12 Microsoft Corporation Transparent envelope for XML messages
US9066316B2 (en) 2007-11-19 2015-06-23 Qualcomm Incorporated Diagnostic monitoring by a wireless device
EP2157517A1 (en) * 2008-08-19 2010-02-24 Siemens Aktiengesellschaft A process and a system for updating a data structure in a relational database used within a manufacturing execution system
US9178842B2 (en) * 2008-11-05 2015-11-03 Commvault Systems, Inc. Systems and methods for monitoring messaging applications for compliance with a policy
GB2466994B (en) * 2009-01-17 2013-08-14 Henry Mcguire Flexible messaging
US9367595B1 (en) * 2010-06-04 2016-06-14 Software AG USA Inc. Method and system for visual wiring tool to interconnect apps
US8626568B2 (en) 2011-06-30 2014-01-07 Xrs Corporation Fleet vehicle management systems and methods
CN102594788A (zh) * 2011-12-02 2012-07-18 曙光信息产业(北京)有限公司 一种面向对象的数据通信协议结构的实现方法
JP6006113B2 (ja) * 2012-12-28 2016-10-12 株式会社日立製作所 カーナビケーション装置用地図配信サーバ、地図データ配信システム及び道路差分データ生成方法
US9762637B2 (en) 2014-03-21 2017-09-12 Ptc Inc. System and method of using binary dynamic rest messages
US10313410B2 (en) 2014-03-21 2019-06-04 Ptc Inc. Systems and methods using binary dynamic rest messages
US9560170B2 (en) 2014-03-21 2017-01-31 Ptc Inc. System and method of abstracting communication protocol using self-describing messages
US9961058B2 (en) 2014-03-21 2018-05-01 Ptc Inc. System and method of message routing via connection servers in a distributed computing environment
US9462085B2 (en) * 2014-03-21 2016-10-04 Ptc Inc. Chunk-based communication of binary dynamic rest messages
US20160218935A1 (en) * 2015-01-27 2016-07-28 Bank Of America Corporation User interface and dashboard for holistic data transmission throughout an enterprise
WO2017062594A1 (en) 2015-10-06 2017-04-13 Casbu, LLC Multi-level constrained communication system
EP3398091B1 (en) * 2016-02-19 2022-05-11 Huawei Technologies Co., Ltd. System and method for unified access control on federated database

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5257369A (en) * 1990-10-22 1993-10-26 Skeen Marion D Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
EP0456249B1 (en) * 1990-05-10 1998-12-09 Hewlett-Packard Company System for integrating application programs in a heterogeneous network enviroment
WO1992022033A1 (en) * 1991-05-24 1992-12-10 Bell Communications Research, Inc. Active messaging system
IL111154A0 (en) * 1993-10-21 1994-12-29 Martino Ii John A Systems and methods for electronic messaging
US5467472A (en) * 1994-04-15 1995-11-14 Microsoft Corporation Method and system for generating and maintaining property sets with unique format identifiers
US5530806A (en) * 1994-12-15 1996-06-25 At&T Corp. Method and apparatus for storing and retrieving routing information in a network node
US5867603A (en) * 1995-07-10 1999-02-02 Iterated Systems, Inc. Method for transmitting fractal transform data to support different compressor/decompressor designs
US5920822A (en) * 1996-01-18 1999-07-06 Telefonaktiebolaget Lm Ericsson (Publ) Formatting of short message service messages in a cellular telephone network
US5822523A (en) * 1996-02-01 1998-10-13 Mpath Interactive, Inc. Server-group messaging system for interactive applications
US5758126A (en) * 1996-03-19 1998-05-26 Sterling Commerce, Inc. Customizable bidirectional EDI translation system
US6101543A (en) * 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
JP3697831B2 (ja) * 1997-04-18 2005-09-21 株式会社日立製作所 コンピュータシステム
US6023467A (en) * 1997-05-08 2000-02-08 Ericsson, Inc. Operations and maintenance data flows over a point to multipoint broadband access network
US5960178A (en) * 1997-08-08 1999-09-28 Bell Communications Research, Inc. Queue system and method for point-to-point message passing having a separate table for storing message state and identifier of processor assigned to process the message
EP0909068B1 (en) * 1997-10-13 2001-04-04 X-Way Rights B.V. Method and apparatus for structured communication
US6141686A (en) * 1998-03-13 2000-10-31 Deterministic Networks, Inc. Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control

Also Published As

Publication number Publication date
NO20001803L (no) 2000-06-06
ID24180A (id) 2000-07-13
ATE200373T1 (de) 2001-04-15
WO1999020025A3 (en) 1999-09-30
IL135612A (en) 2004-09-27
HUP0101695A3 (en) 2002-08-28
CA2305462C (en) 2005-05-03
GR3036076T3 (en) 2001-09-28
EP0909068A1 (en) 1999-04-14
JP3274131B2 (ja) 2002-04-15
DE69704489T2 (de) 2001-09-20
TR200000985T2 (tr) 2000-07-21
IS5427A (is) 2000-04-03
BR9812919A (pt) 2000-08-08
PT909068E (pt) 2001-09-28
ES2158445T3 (es) 2001-09-01
DK0909068T3 (da) 2001-05-07
CA2305462A1 (en) 1999-04-22
EP1025682A2 (en) 2000-08-09
CN1276123A (zh) 2000-12-06
AU9652898A (en) 1999-05-03
NO20001803D0 (no) 2000-04-07
IL135612A0 (en) 2001-05-20
PL340333A1 (en) 2001-01-29
WO1999020025A2 (en) 1999-04-22
KR20010024487A (ko) 2001-03-26
US6880016B1 (en) 2005-04-12
AU729456B2 (en) 2001-02-01
DE69704489D1 (de) 2001-05-10
HUP0101695A2 (hu) 2001-09-28
EP0909068B1 (en) 2001-04-04

Similar Documents

Publication Publication Date Title
JP3274131B2 (ja) オブジェクト指向地点間通信方法およびその方法を行う通信装置
US6847974B2 (en) Method and apparatus for intelligent data assimilation
EP0412232B1 (en) Apparatus and method for providing high performance communication between software processes
EP1330739B1 (en) Accessing data stored at an intermediary from a service
US7350184B2 (en) System and method for enterprise application interactions
EP1330736B1 (en) Providing content from multiple services
EP1332439B1 (en) Developing applications online
US7089295B2 (en) Customizing content provided by a service
KR100877942B1 (ko) 동적 데이터 구동 애플리케이션 통합 어댑터
US20030115366A1 (en) Asynchronous message delivery system and method
AU2002258640A1 (en) Method and apparatus for intelligent data assimilation
AU2001293254A1 (en) Accessing data stored at an intermediary from a service
AU2001291300A1 (en) Providing content from multiple services
EP1896939A2 (en) Data centric workflows
Myerson The complete book of middleware
US20060047781A1 (en) Method and system for providing remote portal service modules
CZ20001322A3 (cs) Způsob objektově orientované komunikace typu bod-bod a komunikační zařízení k provádění tohoto způsobu
WebLogic Integration
WO2002075474A2 (en) Computer application framework
JP2002215537A (ja) 電子メール環境情報の取得方法、電子メール送信方法およびシステム、サーバ、記録媒体とプログラム

Legal Events

Date Code Title Description
R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees