本開示は、クライアントが定義した規則(14)に基づいて外部定義されたデータを操作する新規性のある計算型アーキテクチャ(10)に関して実行される計算型システムに関する。一回の実行において、アーキテクチャは、請求及び顧客サービスプログラムで使用される。アーキテクチャは、特定のアプリケーションからは独立した一般データユニットで内部的に機能する複数の処理モジュール(12)を含むエンジンユニットを含む。メタデータエンジン(14)は、外部で定義されたデータを受信し、この外部定義データを一般データユニットに関連付け、エンジンユニットで使用する。規則に基づくエンジンは、エンジンユニットに、クライアントが定義した規則に関する情報を提供する。このようにして、エンジンユニットは、広範囲な種々の環境において大部分が再利用できる。091,270号に関連し、両出願は本出願に組み込まれる。本発明は、一般的には計算型システム、すなわち、ソフト、ハード及び/またはファームウェアを含む論理で実行されるコンピュータベースの処理システムに関する。本発明は、クライアント定義による規則及びメタデータに基づいて、ビジネス環境で作成された記録などの外部定義のデータ内容またはデータ形式(以後「外部定義データ」と称す)で動作する計算型システムに関する。本発明は、種々の動作環境で種々の機能、たとえば、種々のビジネス環境に適用できる請求プログラムなどを実行するために簡単に適応する計算型システムの開発と操作に特に有用である。データ、環境データ、その他の外部または実世界の出来事に関連して内容及び/または形式が決定される情報といった、外部定義データで動作する必要がある。演算システムは、データと、データに伴う環境と同程度に多様である外部定義データで動作を実行する。該動作は、クライアント・ベースの規則、すなわちデータの処理を制御するクライアント(たとえば、当事者のために演算システムが開発された場合のその当事者あるいは当事者のために演算システムが動作される場合のその当事者)によって定義された規則に一部依存する。このようにして、コンピュータシステムと、該コンピュータシステムによって実行されるアルゴリズムは、ケースバイケースで開発され、開発された特定アプリケーションに制限される。近年、プログラマは種々の状況に多少適応自在のプログラムを開発し、ソースコードの作成と再プログラムの必要を少なくするよう多大な努力を続けてきた。code.かかる適応自在のプログラミングの例としては、構成自在なシステムとオブジェクト志向プログラミング(OOP)がある。典型的に、構成自在なシステムにより、ユーザは種々の選択肢、たとえば選択肢のメニューから選択し、システムを任意の状況にカスタマイズできる。関連構成ファイルは、たとえば該任意の状況に関連する特定ユーザ、特定コンピュータ、もしくは特定プログラムに関する情報を含むことができる。OOPは、一般的に、オブジェクト、すなわち独立した構築ブロックとして利用できる自立ソフトモジュールを利用して、プログラミングを行なう。各オブジェクトは、他のオブジェクトまたはシステムからの適切なメッセージに応答して、特定の機能を実行しなければならないコマンドとデータを含む。一般的に、特定の類の新たなオブジェクトは、現存のオブジェクトの特定の特徴を受け継ぐ。該オブジェクトは、プログラミングの状況の変化に対応するため再利用または修正でき、それにより、特定の場合に、ソフトルーチンを最初から作成する必要性を軽減する。かかるプログラミングによって調整される適応性の程度は、一般的に多少制限される。option,あるいはあらかじめプログラムされた選択肢フィールドからのカスタマイズのみを典型的に支援する。同様に、OOPのオブジェクトは、構築ブロックとして使用し、再利用できるが、一般的に特定の動作文脈内にある。その結果、構成自在なシステムとOOPによって得られる適応性を利用するプログラマでさえ、一般的に、アプリケーション固有のプログラムの書き込みに制限される。2進コード内のかかるプログラムの一点において、プログラムの種々の機能を実行するエンジンは、アプリケーション固有の要素を含む。engine,多大な適応性を恐らく提供するが、アプリケーション固有のエンジンであり、他のアプリケーションで再利用するためには、実質的なコード改訂を必要とする。ビジネス用ソフト及び特に請求プログラムの場合を例証する。該プログラムは、何かが見積もられ、請求される特定のビジネス環境に請求情報を提供するよう設計される。特定のビジネス環境は、ビジネス環境が存在する会社及び業界と同様に多様である。その際は業界に関連する要因や組織に関連する要因などがある。業界関連要因は、請求される物と、利用できるビジネス記録の形式に関連することがある。請求される物は、分(たとえば放送時間、オンライン時間、プロジェクトに費やされた労働者の時間)、材料または物品の量または数(立方フィートの天然ガス、消費キロワット時、取引されるセキュリティ数など)、もしくは通貨単位(手数料、ロイヤリティまたはサービス料がかかる取引の規模)に関して測定してもよい。使用法その他の請求情報は、産業基準または私有形式、たとえば遠隔通信ネットワークの通話詳細記録や同様の記録などで提供できる。したがって、請求プログラムは、一般的にケースバイケースで設計され、特定の種類のデータと特定のデータ形式を処理する。組織に関連する要因は、組織またはクライアントに特有の種々の請求規則に関連する。時間帯または曜日によって変動する請求額;取引の種類と規模によって変動する手数料構造;数量または手数料規則;個人とビジネスに関する経費をつかさどる社則;組織の部門間またはその他の単位間などの支出と受け取りの配分に関する社内簿記規則などである。program,産業によって(あるいは会社によって)異なるデータのタイプとデータ形式に対応するだけでなく、会社によって変動する組織関連要因にも対処しなければならない。同様の変動が、広範な他のプログラミング環境にも存在する。請求プログラムの文脈において、企業は、一般的に標準請求プログラムを使用するか、特別に作成したプログラムを有する。program,一般的に、前述のような産業関連及び組織関連の変動に対処する能力に乏しい。above.かかる利用できるプログラムのいくつかは、ユーザインターフェース画面または請求報告書をカスタマイズする機能が一部備わっているが、一般的には、プログラムは、プログラム内にあらかじめコード化された特定のアルゴリズムに対応するあらかじめ定義された少数のビジネスモデルのみを支援する。標準プログラムの制限に不満を持ついくつかの企業は、特定のアプリケーション用にカスタム開発された請求プログラムを所有し、クライアント定義の規則にしたがって外部定義データを支援する。顧客に請求する際に使用する請求プログラムを開発したいと考える遠隔通信会社は、社外のソフト開発者と契約するだろう。開発者は時間をかけて、遠隔通信会社から受け取ったデータ内容とデータ形式を理解する。通話者を識別するMIN/ESN、その他の情報を含む。ソフト開発者は時間をかけて、時間帯や曜日によって異なる料金、顧客の請求計画によって異なる料金、通話の請求領域(たとえば地域コード)によって異なる料金、通話時間の関数としての変動料金を含む会社の請求規則を把握する。該情報すべてに基づいて、開発者は請求プログラムを設計し、関連するデータ、データ形式、請求規則を考慮した特定のアルゴリズムをコードに書き込む。予備プログラム版をコードに書き込んだ後、会社の通常の請求システムでプログラムを実行して、会社がプログラムを充分に信頼できると判断するまで、一般的にコードは、典型的に長い試験期間中に試験、改定、バグ除去、あるいは開発される。アプリケーションごとにカスタムコードを開発するプロセスであると、プロセスが広範囲にわたり、会社の業務に支障をきたし、信頼性に欠ける。開発者は、会社の経費で、会社の業務内容を把握し、基本原理からコードを書き、コードを機能製品に発展させるために、多大な時間を費やさねばならない。開発者の教育、試験データの提供、試験結果の分析及びプログラムのトラブルシュートに、莫大な会社の資源がしばしば費やされる。基本原理からカスタムコードを開発するのは複雑であるため、その結果得られるプログラムはエラーの発生や性能が不充分となる傾向があり、満足できる製品を開発するには膨大な時間がかかることがある。請求プログラムは企業の利益性と顧客との関係の心臓部に近いため、企業にとって重大な関心事である。該開発プロセスは、特定動作環境のニーズに完全に対応し、複数の会社や個人が要求するレベルのサービスを提供する能力がある演算システムを得ることが本質的に困難であると考えられてきた。種々の設定において、外部定義データを支援し、及び/またはクライアント定義規則にしたがってデータ処理を支援する、高信頼性で簡単に開発できる演算システムに対する需要があることは認識されていた。";2)外部定義データ及び/またはクライアント定義規則を受信し、該アプリケーション固有の入力に基づいてエンジンを操作し、アプリケーション固有の内容または形式を有する演算ずみデータを出力するアプリケーション固有のモジュールと;組み合わせたものを含む演算システムによって対処できることを理解したことに一部基づいている。このようにして、開発時間フレームは対応するコスト削減と実質的に関連付けられ、汎用プラットホームの再利用機能により、システムの信頼性が大幅に向上する。system,量的に異なる適応性を含むことが以下の説明から明らかである。本発明の演算システムは、いかなるアプリケーション固有の要素からも独立して機能する機能エンジンを含む。したがって、該エンジンは、かかるアプリケーションに依存する要素を再プログラミングすることなく、一アプリケーションから他のアプリケーションに転送できる。同様に、アプリケーション固有のモジュールは、従来のメッセージ伝達関連の対話とは異なる方法で機能エンジンと対話する。メッセージ伝達は、特定のアプリケーションにおいて何度も使用できるか、あるいは1アプリケーションの特徴に基づいて他の記録の特定の属性を受け継ぐ新しい記録を作成するために使用できる特定の種類のあらかじめプログラムされた機能を効果的に呼び出すために使用されてきたが、本発明のアプリケーション固有モジュールは、エンジンが動作するアプリケーションのタイプを決定するような方法で、エンジンと対話する。アプリケーション固有モジュールは、アプリケーションがどのような種類のものになるかをエンジンに「伝える」。ある場合では、特定のアプリケーション固有モジュールにより、エンジンは形態電話通信ネットワークの請求システムの一部として機能する。別の場合では、他のアプリケーション固有モジュールにより、同じエンジンが原油価格決定アプリケーションとして機能する。この機能変動は、外部定義データとクライアント定義データの両方に基づくことができる。input,処理装置が、アプリケーション固有入力に基づいて、一般データユニットで演算ベース機能を実行でき、演算処理データを生成するためのメモリと;演算処理データに基づいてアプリケーション固有出力を提供するための、処理装置に付属の出力装置とを備える。該処理装置は、汎用プラットホームの演算ベース機能に対応するアルゴリズムを実行するネットワークサービスに組み込んでもよい。入力装置は、処理装置で使用するために、外部定義メタデータを一般データユニット及び/またはクライアント定義規則に関連付ける格納データ(たとえば参照用テーブル)にアクセスするためのグラフィカル・ユーザインターフェース装置を含む。該メモリは、処理装置で使用するためにアプリケーション固有入力を格納するよう構成されたコンピュータメモリを含む。該出力装置は、演算処理データをアプリケーション固有出力に関連付ける1ないし複数のGUI、その他の処理装置を含むことがある。本発明の別の側面において、システムは多層構造に配されている。多層構造は、ユーザに最も近い層でより多くのアプリケーション固有プロセスを実行する機能を提供し、同時に、より抽象的な機能は基底に近い中心位置で実行される。基底に位置するのは、データベースを含む中央サーバでもよい。基底サーバは、中間層に位置する少なくとも1個のアプリケーションサーバに接続される。アプリケーションサーバは、それが機能を果たす場所に関連した機能を実行し、中央サーバは、システムのすべての部分にサービスを提供する。最上層は、システムとシステムユーザの間のインターフェースとして機能するクライアントノードを含む。user,規則データと定義などのアプリケーション固有データに入り、そこで実行されたプロセスに関連した出力を受け取る。多層システムの一部として、高い確率でクライアントノードに近い層で使用される情報のサブセットを格納する機能を含むデータ同期化機構を使用してもよい。特定の遭遇中に高需要となる情報を特定化し、該遭遇中に基底層から中間層へ該情報を埋め戻す、あらかじめ決められたあるいは順応性をもった規則が提供される。本発明のさらに別の側面において、ここに記述される本発明は、クライアントノードと基底層との間で種々の抽象概念のレベルでデータを処理するさまざまなオブジェクトを採用するオブジェクト志向システムとして実行できる。最上層の提示オブジェクトは、クライアントの実現に非常に特有の1ないし複数のビジネスオブジェクトに対応できる。該オブジェクトは、ユーザインターフェース、報告書ライターなどの支援に重点を置くこともできる。提示オブジェクトと、中間層に位置するビジネスオブジェクトとの間にマッピングを提供することもできる。ビジネスオブジェクトは、システムの特定の実現によって支援される主要な抽象化ビジネス論理を含む。該オブジェクトには、処理エンジンを駆動するのに必要なメタデータと規則が含まれる。マッピングは、ビジネスオブジェクトと、基底層に位置するドメインオブジェクトの間にもさらに含まれる。ドメインオブジェクトは、データモデル実体または外部ソースを介して得られる実体に緊密に対応する。ドメインオブジェクトにより、データベース内の提示オブジェクトとビジネスオブジェクトによって必要とされるデータの位置確定が容易になる。本発明の別の側面において、装置は種々の請求及び顧客サービス関連機能を実行する。アプリケーション固有モジュールからの指示の下で、機能エンジンは顧客定義規則を使用して、種々の機能を実行する。請求要約に関する複数のプロセスを含む。本発明の別の側面において、汎用処理プラットホームを、特定の処理アプリケーションを支援するために使用できるようにするために方法が提供される。該方法は、一般データユニットで計算機ベース機能を実行するための汎用プラットホームを、特定のデータ処理アプリケーションを支援するための演算プログラムの一部として提供する。一般表現データユニットは、特定のデータ処理アプリケーションからは独立して表現される。請求及び顧客サービス用のビジネス用途の場合、汎用プラットホームは、見積もりと請求機能を実行する機能コンポーネントを含む。environment,見積もりパラメータと顧客使用パラメータなどの規模で測れないパラメータとして定義できる。該方法では、さらに特定データ処理アプリケーションに対してアプリケーション固有入力を受信し、アプリケーション固有入力に基づいて汎用プラットホームを操作して演算処理データを生成し、演算処理データに基づいてアプリケーション固有出力を提供する。受信されたアプリケーション固有入力は、外部定義データ(たとえば業界基準または会社の形式で提供された請求記録)とクライアント定義規則(たとえば請求見積もり情報)のうち少なくとも一方を含む。アプリケーション固有出力は、特定のデータ処理アプリケーションに固有のデータ内容とデータ形式の少なくとも一方を含む。該出力は、組織の請求形式の請求アプリケーションに適切に表現された請求情報を含むことができる。該出力は、送信されたデータ信号、印刷された請求書、または電子的に送信された請求書の形態で提供できる。本発明の別の側面によると、汎用処理プラットホームによって使用するために、外部定義された請求及び顧客サービス関連データを処理するための方法が提供される。データを一般ユニットに翻訳するステップを含む。data,外部定義データ内容(たとえば請求されるもののユニットで)及び/または外部定義データ形式(業界基準または私有形式)を含む。該方法により、かかる外部定義情報が、特定の請求アプリケーションに特に順応しない、あるいは特定の請求アプリケーションに限定されない汎用処理プラットホームで利用できるようになる。本発明の方法と装置は、以下に詳述するアーキテクチャと関連して実行されるように、外部定義データを処理する、またはクライアント定義規則に基づいてデータを処理する広範囲な用途に適用自在である。本発明は、特定の機能類似性を共有するが、特定のデータタイプ、データ形式、組織の詳細及び特定の事へのその他のアプリケーションという点で異なる、複数のさまざまなアプリケーション用の演算システムの開発、カスタマイズ及び操作という文脈において有用である。該アーキテクチャにより、特定の一般要素または処理エンジンを使用して、さまざまな異なる計算が実行される環境を支援できる。図示したアーキテクチャの重要な利点は、かかるビジネス環境のほとんどいかなるものも支援できる点にある。その結果、開発のリスクが最小限に抑えられ、カスタマイズされたシステムの開発と配置に要する時間が短縮される。所定のビジネスモデルに基づいたアプリケーションに順応するか、あるいは甘んずることを会社に要求するのではなく、特定の企業またはその業界のニーズに合わせて特定のアプリケーションを作成できる。図示したアーキテクチャは、一般機能要素すなわちエンジン12と、規則/メタデータエンジン14と、メッセージ送信システム16の3つのコンポーネントを含むと理解できる。アーキテクチャで処理される情報は、データソース18または他の外部サービスから検索できる。各エンジン12は、充分に定義された機能の性能に重点を置いた自律コンポーネントである。各エンジンは、他のすべてのエンジンと共有する資源へのアクセスを容易にする共通枠組みを導入する。各エンジンはそれぞれ固有の機能を提供するよう設計されているが、その実現は一般的である。エンジンの一つが、特定の船積みプロセス、たとえばサービス利用の料金決定を実行するために作成されたとする。該コンポーネントに関して、可変用法は見積もり中の実体を表わし、ユニットとして定義され、一ユニットの定義がメタデータモデル内に提供される。特定のアプリケーションの測定単位が毎秒メガビットと定義されると、メタデータモデルは、毎秒あたりに転送されるメガバイト数を見積もると定義される。別の例で、測定される単位が放送時間の秒数であるとすると、メタデータモデルは単純に変更されて、測定単位を秒に再定義する。規則/メタデータエンジン14は、一般計算型エンドを実際のビジネスまたは科学機能に関連付けるために使用される。規則とメタデータは、図1に開示される計算型アーキテクチャを特定のアプリケーションにカスタマイズできるようにする2個の個別のツールである。規則は、データの評価及び格納、処理エンジン内での計算の実行、及びグラフィカル・ユーザインターフェース(GUI)を介したシステムユーザへの情報提供に関するガイドラインを提供する。規則の採用については以下にさらに詳細に説明する。メタデータは、エンジン内で処理されるデータのユニットを記述するために用いられる。以下に説明するように、これは測定単位あるいは他の数量、または顧客が測定したいと考える記述などの項目でもよい。該機能は、特定の業界、企業、部門またはその他の作業単位に固有のものとなる場合がある。規則/メタデータエンジンは、システムの種々の機能を管理するための複数の処理モジュールも含む。最後に、メッセージ送信システム16は規則/メタデータエンジンの指示の下で動作し、システムを介したデータ信号のルートを提供する。メッセージ送信エンジン16は、処理エンジン12と、規則/メタデータエンジン14と、他のアプリケーションまたはシステムとの間の通信を容易にする。図2に開示されるのは、前述の計算型アーキテクチャを組み込む多層処理システムのブロック図である。多層構造により、システムのユーザに近い層で、よりアプリケーションに固有のプロセスを実行する機能を提供し、さらに抽象的な機能は規定に近い中心位置で実行される。最下層は、記録22のデータベースに接続された基底サーバ20である。該サーバ内には、処理エンジンと、処理動作を実行するために必要な規則/メタデータエンジンの一部が含まれる。network,データベースサーチ能力を備えたユニックスサーバのような、現在利用できるタイプのものでよい。主データベースは、複数の異なるタイプのデータを格納するために利用できる関連データベースである。metadata,システムデータ、実データとして特徴付けられる。説明したように、メタデータは、処理エンジンによって内部で使用される独立したユニットのアプリケーションである。実データは、顧客用法データ及び、それに基づいて計算を行なう他の外部定義された、あるいは実世界のデータを指す。システムデータは、クライアント定義規則データ及び翻訳定義データを含む特定のプログラムによって使用するために格納された他のすべてのデータを含む。該データベースは、オラクル関連データベースソフトを使用して実現できる。基底サーバは、システム全体に関して、中間層に位置する少なくとも1個のアプリケーションサーバに接続される。該接続は、メッセージバスを介して確立される。多層システムの利点の1つは、基底サーバが中心位置にあり、中間サーバがそれから離れて位置している点にある。(LAN)を介して、またはWWW上で確立できる。中間層には、それが機能する場所に関連した複数の動作を実行する少なくとも1個のアプリケーションオブジェクトサーバ24がある。該サーバの動作については以下にさらに詳細に説明する。アプリケーションオブジェクトサーバは、該特定位置での処理機能の実行に関連する情報を含むデータベース26に接続される。(LAN)などのようなデータネットワークから、複数のグラフィカル・ユーザインターフェース(GUI)デバイス30に接続できる。GUI30は、システムユーザが、規則データと定義などのアプリケーション固有データを入力でき、グラフィカルインターフェースと出力を必要に応じて提供できる入出力デバイスである。インターフェースは、キーボードと、マウスと、モニタ、もしくは同様のユーザインターフェース・デバイスを備えることができる。インターフェースはまた、電話システム、外部または外部会計システム、もしくは他の実データソースとネットワーク接続を確立するための入力ポートを含むことができる。顧客の送り状などを印刷するために、出力デバイスも含むことができる。network,多数の顧客に送り状または請求書を電子送信するための装置も提供される。このため、ネットワークインターフェースは、専用通信線などのインターフェースハードと、形式化のための論理と、電子送信とインターネットプロトコル支援のためのデータと、送信されるデータのプライバシーを守るための暗号化またはその他のセキュリティ論理を含む。対応する暗号解読またはその他のセキュリティ論理は顧客ノード30に常駐できる。本発明の一側面において、システムは、顧客サービス機能を提供するようになっており、クライアントまたは顧客代表者が、複数の中間サーバ24の1つを介してシステムと対話する。クライアントまたは顧客の対話の結果、中間サーバが遭遇要約情報を作成し、捕捉し、該情報が基底サーバ20に送られる。このように操作するため、階層間のデータ転送は、所定機構にしたがって実行されなければならない。該データ同期化機構は、システムユーザに近い層に情報のサブセットを格納する機能を含む。システムは、多数のデータベースをわたって情報が水平に同期化されることも保証する。システムは該条件を支援し、システム全体のデータの整合性を保証する。データの整合性を保証するため、すべてのデータベースの更新は、記録22の中央データベースに行なわれる。データベース同期化には動的と半静的の2種類のデータがある。動的データは、クライアントノードまたはビジネス規則に入力が行なわれた結果頻繁に変動するデータを指す。半静的データとは、ほとんど変動せず、変動する場合は通常予定されているというデータである。以上は、順応層データ同期化機構として知られ、2個のコンポーネントにより表わされる。第1のコンポーネントは、前述の規則ベースのメッセージサービスである。いかなる適応層アーキテクチャ内においても、ビジネスオブジェクトはいずれの層に常駐してもよく、他の層のいずれに常駐するオブジェクトとも通信する能力を必要とする。service,簡単に構成できる規則セットによって制御されるため、他のコンポーネントをアーキテクチャ層のいずれかに自由にマッピングするフレキシビリティを該サービスはシステムアーキテクチャに与える。システムコンポーネントの適応層アーキテクチャの層へのすべての割当を支援する際に、コンポーネント間の通信は、メッセージルート決定規則を単純に操作することで適応できる。システムによって利用できるようにされる適応層支援の2番目のコンポーネントは、データステージングサービスである。該サービスは、適応層アーキテクチャの中間層内の、関心が高く高需要であるデータをキャッシュ処理する能力を提供する。該キャッシュデータは、クライアントノードで必要とされる初期画面を占有するために用いられる。データステージングサービスは、中間層内ではキャッシュ処理されなかったクライアントノードで必要とされるデータを基底層から情報処理によって「埋め戻す」能力も提供する。任意のユーザ遭遇の代わりに、データが中間層に常駐する順序が、該埋め戻しプロセスによって目標とされ、遭遇時に特定の顧客とサービス提供者との関係などによって駆動される。推論埋め戻し機構は、キャッシュ処理されていないデータの遭遇固有の条件を予測するために効果的に用いられ、遭遇を支援する必要がある基底層データが、データがクライアントノードで要求される時点までに、中間層内に実際に存在する。特定のデータが1回の遭遇中に要求される確率に関して規則が提供される。データの埋め戻しに用いられる該規則は、所定の確率に基づくか、あるいは順応する。システムの動作は連続して監視され、過去の性能に基づいて、特定の遭遇中に埋め戻しに使用されるデータタイプに関連して、更新確率が生成される。図3に開示されるのは、データを提供するための適応層システムの様子を示した図である。主データベース40は、ユーザとの遭遇のために検索される必要なデータをすべて備えている。遭遇が開始すると、該ユーザの関連情報が、通信システムを開始、中間層41に提供され、キャッシュデータ44に格納される。次に該情報は、クライアントノード46でアクセス可能となる。遭遇が、開いた関与が存在するユーザとの間で開始されると、データステージングサービスが直ちに埋め戻しプロセスを開始し、基底層から中間層へ適切な詳細関与状態データを処理し、該データがクライアントノード46で要求される確率に基づいて、埋め戻されたデータ42に格納される。前述のように多層システムを実現するため、さらに必要な性能を提供するため、クライアントノードと基底層との間の種々の抽象レベルでデータを処理する種々のオブジェクトを採用するオブジェクト志向システムを開示する。具体的には、ドメイン、ビジネス、及び提示オブジェクトにより、ユーザインターフェースまたは種々のエンジンからのデータモデル関係の抽象化を容易にする。図4で、多層オブジェクト志向システムの高レベル図を開示する。これは、提示オブジェクト(ユーザインターフェース)、ビジネスオブジェクト及びドメインオブジェクトを3つの明確な階層に分割するアーキテクチャである。各階層または層は異なる仮想機械上に常駐できる。提示オブジェクト階層33は、ビジネスオブジェクト階層とともにクライアントノード31との通信を提供する。クライアントノード31とのインターフェースは、提示論理32を介して提供される。オブジェクトマッピング34が、提示オブジェクト33とビジネスオブジェクト35との間に提供される。ビジネスオブジェクト階層は、ビジネスオブジェクト35を含み、データアクセス階層すなわちドメインオブジェクト37へ通信を提供する。ビジネスオブジェクトは、システムの特定の実現によって支援される主要な抽象化ビジネス論理を含む。該オブジェクトには、処理エンジンを駆動するのに必要なメタデータと規則が含まれる。マッピング36は、ビジネスオブジェクト35と、ドメインオブジェクト37の間にも提供される。sourcePIを介して得られる実体に緊密に対応している。ドメインオブジェクトにより、提示オブジェクトとビジネスオブジェクトによって必要とされるデータの位置確定が容易となる。39において情報の位置を決定するために提供される。システムのオブジェクト間に生じることがあるマッピングの簡略図も図4に示す。前述したように提示オブジェクトは、情報が提示されるタイプを制御し、特定のクライアントノード固有である。特定の顧客に現在の料金を提示するという要求がクライアントノードで行なわれた場合、少なくとも1個の提示オブジェクト33を使用して、該情報を提供する。該情報を生成するために必要な操作を実行するため、複数のビジネスオブジェクト(1−N)35にマッピングが提供される。規則とメタデータを使用することで、ビジネスオブジェクトは処理エンジンの動作を指示する。該機能の実行において処理エンジンが使用する一般ユニットの位置を決定するため、ビジネスオブジェクトとドメインオブジェクトの間にさらなるマッピングが提供される。ドメインオブジェクトは、複数の機能の一部として、データベースの適切なテーブルから必要な一般ユニットの位置を規定し、検索を行なう。(1-N)間に提供される。図5に開示されるのは、ここに説明される多層システム用のシステム図である。図5は、基底層とクライアントノードとの間の単一通信路を開示するという説明上の目的により簡略化してある。開示したように、基底サーバは、複数の中間サーバと接続でき、該中間サーバは、次に複数のクライアントノードと接続できる。各クライアントノードは、前述したように、システムユーザによってシステムに入力されたデータを表示、受信するための機能を含む。クライアントノード50は、提示取引コントローラ(PRT)51と、アプリケーションサーバ52から受信したデータを一時的に局所格納するためのキャッシュ55とを含む。PTR51は、その文脈と状態においてオブジェクトを管理する義務がある専用オブジェクトである。PTRは、大量のオブジェクトの処理を容易にする。該オブジェクトは、集合体として、いくつかのビジネス論理を満たすために利用できる。集合体として、オブジェクトの変化は、集団として行なわれるか、あるいは集合として元に戻る。controller,コントローラの実例の提示、オブジェクト管理、取引管理及びオブジェクトのロックを含む。クライアントノードは、さらに任意アクセス制御(DAC)デバイス53を含む。DAC53は、登録されたオブジェクトに関して、その実例提示、削除、アクセス、更新及び挙動を制御するためのフィルタを翻訳コントローラ内に提供する。クライアントノードには、提示オブジェクトファクトリ57を含む中間アプリケーションサーバ52が接続されている。57,アプリケーション固有オブジェクトのタイプ用に、アプリケーションプログラミング・インターフェース(API)を提供する。該ファクトリは特定のオブジェクトのタイプの実例を提示する能力を提供する知識を含む。提示オブジェクトは、クライアントの実現に高度に特有の1ないし複数のビジネスオブジェクトに対応する。該オブジェクトは、ユーザインターフェース、報告書ライターなどの支援に重点を置いている。提示オブジェクトを利用するビジネス論理は、支援ビジネスオブジェクト内に維持される。該オブジェクトは、配備によって異なる。56内のビジネス及びドメインオブジェクトにマッピングを提供するオブジェクトマッピングモジュール59が接続されている。クライアントノードの場合と同様に、アプリケーションサーバ52は、提示取引コントローラと、DACと、データキャッシュとを含む。メッセージバス61を介してアプリケーションサーバ52とオブジェクトサーバ56との間には、通信ラインが確立される。オブジェクトサーバには、ビジネスオブジェクトファクトリ58が含まれる。ビジネスオブジェクトファクトリは、ビジネスオブジェクトを作成するに必要なAPIを提供できる。オブジェクトファクトリは、大量のドメインオブジェクトを基本として使用して該動作を実行する方法を把握している。ドメインオブジェクトとビジネスオブジェクトとの間のマッピングは、データモデル内に維持される。該マッピングは属性と関係の両方を含む。該マッピングをデータベース内に定義することで、配置ごとにシステムを構成する機能が容易になる。該オブジェクトは、そのデータと支援データサービスからその挙動を本質的に引き出す。ドメインオブジェクトと同様に、ビジネスオブジェクトは、配置ごとに変動するとは予想されない。ビジネスオブジェクトファクトリ58も、提示取引コントローラと、DACと、データキャッシュとを含む。ビジネスオブジェクトファクトリはメッセージバスを介し、ドメインオブジェクトファクトリ60と接続される。ドメインオブジェクトは、データモデル実体、または外部ソースからAPIを介して得られる実体に緊密に対応する。ドメインオブジェクトは、必ずしもビジネス挙動を有してはいない。ドメインオブジェクトは、データ格納装置からのドメインオブジェクトの作成、読み出し及び削除方法を単に把握している。65へのオブジェクトからの関連マッピングが容易になる。ドメインオブジェクトは、配置ごとに変動するとは予想されない。ドメインオブジェクトファクトリには主データ格納装置65が接続されている。該データソースは、記録のデータベースまたは、外部データソースとのアプリケーションプログラミング・インターフェースでよい。いずれの場合でも、記録のデータベース、外部データソースまたはそのインターフェースへの変更はオブジェクトサーバに限定され、その外のシステムコンポーネントからは分離される。主データベースは、関連データベースを介してアクセス自在の、格納されたドメインオブジェクトを含む。前述の計算型アーキテクチャの一部を含むエンジン/アプリケーションサービス62がオブジェクトサーバに接続されるか、あるいはオブジェクトサーバ内に含まれる。該サービス内で、処理エンジンは、ビジネスオブジェクトファクトリから受理したオブジェクト(規則/メタデータを含む)を採用する個々の機能を実行する。図1に開示したアーキテクチャに戻ると、処理エンジンに関して、規則/メタデータによって実行される機能は、図5のシステムで開示した複数の層にわたって広がる。規則/メタデータエンジンには、システムの動作を指示する複数の処理モジュールが含まれる。該モジュールは、システムマネージャ66と、規則サービスマネージャ67と、出来事マネージャ68と、データサービスとを含む。service.該サービスは、アプリケーションが中心位置と状態を対話及び通信する方法を提供するとともに、アプリケーションを構築する共通枠組を提供する。該モジュールの各々については以下に詳述する。システムマネージャ66との通信ラインを示すシステム図を図6に詳細に示す。システムマネージャ66は、他のアプリケーションに管理制御を提供するアーキテクチャ内の専用アプリケーションである。アプリケーションは、システムマネージャ66と信号を送受信するエンジンユニット内のエンジンのいずれかを表わす。メモリ100は、システムマネージャによって維持される登録されたエンジンのリストを含む。システムマネージャは、ユーザ変更要求に基づいて該集合体を更新する。modules,アプリケーションの開始と停止の責任を有する。アプリケーションの多くは、連続して機能するよう開発できるが、システムマネージャは該アプリケーションを最初に始動しなければならず、あるいは変則事態が生じた場合は、アプリケーションを再起動する必要がある。システムマネージャは、アプリケーションの更新が要求されたような場合にも、アプリケーションを停止させる。最後に、システムマネージャは、メッセージ送信サービス86を介して継続機構でアプリケーションを監視し、これは、通常の出来事の通信を介して、アプリケーションがその動作状態をシステムマネージャに通知することを意味する。アプリケーションが所定時間中反応しない場合、システムマネージャは、応答を要求するアプリケーションのポーリングを実行する。アプリケーションが応答しない場合、システムマネージャはアプリケーションを停止し、再始動する。該機能はすべてGUIを介して監視されるか手動制御される。図7に開示される規則サービス67は、システム挙動、特定アプリケーション挙動、データ解釈、アプリケーション間のデータルート決定の集中管理機構を提供し、システム全体に規則を提供する。規則マネージャは、エンジンによる規則の評価において、エンジンを支援するゲートウェイとして機能する。規則サービスは、登録された規則のリストを格納する。101によって維持される規則の初期リストを形成する。規則サービスは、ユーザ変更要求に基づいて該集合体を更新し、規則を採用する種々のアプリケーションに該情報を提供する。規則は、メッセージサービス86を介して種々のアプリケーションに伝達される。図6〜9で参照されたメッセージ送信サービスは、アプリケーション間でメッセージオブジェクトを移送する機構を提供する。タイプ(たとえば、公表/契約、仲間から仲間へ)、移送プロトコル及びオブジェクトタイプに基づく移送セキュリティなどの属性を有する。該属性により、該属性に基づいてルートを確立できる。実際のアプリケーション数はさまざまであるが、追加アプリケーションの対話は、本文書で示したものと同じである。アプリケーションは、メッセージ送信サービスを介して多数の接続を有してもよい。負荷バランスを容易にするために、多数のメッセージオブジェクトサービスがあってもよい。このようにして、アプリケーションは多数のメッセージサービスに接続されるか、メッセージタイプが、伝達前に複数のメッセージサービスを移動させる。図8に開示されるのは、出来事マネージャ68のシステム図である。出来事マネージャ68は、システム全体にわたって、複雑な出来事を管理する機構を提供する。該出来事は、一般的に状態保持を必要とし、他のシステムコンポーネントからの出来事と組み合わされる。time,特定出来事外で定期的に実行できる出来事は該サービス内で管理される。出来事マネージャは、特定の複雑なあるいは時間重視の出来事用に構成されるよう設計された規則エンジンである。格納装置102には、出来事マネージャによって維持される出来事リストが含まれる。出来事マネージャは、ユーザ変更要求に基づいて該集合体を更新する。node,特定の出来事を追加、削除、修正あるいは表示できる。出来事マネージャは、メッセージサービス86を介して、種々のアプリケーションに対して出来事発生を調整する。図9に、データ管理サービス69との通信ラインを示すシステム図を示す。データ管理サービスは、オブジェクトではないデータをアプリケーションの1つが使用するオブジェクトに変換する機構を提供する。オブジェクトでは内外データは、ディスクファイル、データベース関係、その他のメッセージなどである。該状況において、サービスは、接続の開始、読み出し及び終了を行なう機構を提供する。データ管理サービス69は、ディスクファイル格納装置116上のファイルへのアクセス、あるいは、データベース118からの他の情報の検索を提供する。オブジェクトマッピングデータを、データベース120によって表わされる他のデータソースから検索できる。し、提供するプロセスとシステムとを含む。本実施例では、前述のアーキテクチャは、種々の請求環境を支援する複数の請求プログラムを開発、カスタマイズ、及び操作するシステムである。かかる請求プログラムは特定の機能類似性を共有する。多くの詳細はアプリケーションごとに異なる。請求プログラムは、外部定義データ(たとえば電話システム、会計システム)とクライアント・ベースの規則(たとえば通話プラン、セキュリティ条件)の性質によって異なる。請求システム実施例は、遠隔ネットワークに関した特定の例で、請求及び顧客サービスプログラムの文脈で説明している。本発明の種々の側面は、前述したように、アプリケーションがさらに広く、以下の説明は、添付の特許請求の範囲を制限することは意図しない。図10では、請求システムに関連する処理アーキテクチャの一実施例を示す。請求システムにおける該モジュールの動作を以下に詳述する。図11〜18は、請求システム計算型アーキテクチャにおける種々の処理エンジンの動作に関する。該エンジンは、特定の環境から独立した一般的なユニットで動作することで、請求及び顧客サービス関連の機能を実行する複数のオブジェクト志向ソフトモジュールである。エンジンの内部動作は、見積もられる、あるいは請求される物の性質や、提供される顧客サービスには依存しない。該エンジンは、多数の請求及び顧客サービスに関連した機能が、規則に基づいた論理によって支援される一般データモデルを用いて実行できるという概念に基づいている。この考え方により、一般データモデルを使用して実行できるいかなる請求及び顧客サービスに関連した機能も、エンジンとして実行できる。このため、エンジンの数と機能はさまざまなものがあることが分かる。したがって、以下に説明する特定のエンジンは例示のみを目的とする。particular,システム内の他のコンポーネントとの種々の通信ラインを示している。該顧客要約エンジンは、顧客との通信時に、該顧客とサービス提供者との関係の性質を直ちに確認する機能を、顧客サービス代表者に提供する。顧客情報は、アカウントに関連する人々の氏名と住所、顧客のハード構成、アカウントの支払方法、サービス提供者との該顧客の過去の接触履歴などを含む。さらなる情報としては、サービス提供者と顧客間に確立された関係のタイプなどがある。is,データサービス90を介してアクセス自在の外部データベース内に格納される。database.該エンジンは、通信確立時に、顧客サービス代表者のデスクトップが、特定顧客に関するすべての所要情報を表示することを確実にするための機能を提供する。customer.顧客要約情報の提供と、一旦受信された情報の送信の命令は、メッセージサービスを介して行なわれる。該エンジンには、主要機能を実行する複数の一般処理モジュールが含まれる。functions.エンジン実行部92は、メッセージサービス86から送られてくるメッセージを処理し、エンジンを構成する機能コンポーネントを介して制御信号流を監視する。エンジン実行部は、処理後の遭遇後要約機能96を起動し、該顧客の代わりに、最近の顧客遭遇が、システムによって維持される顧客要約情報に与える影響を評価する。98が、顧客要約情報の適切な部分を再生する。94が起動され、必要な計算を行なう。最後に、該エンジン実行部は、評価された関与影響機能99を使用して、いずれかの顕著な関与が顧客遭遇によって影響を受けたかどうかを判断し、それにしたがって関与マネージャに通知を発行する。図12に開示される関与管理エンジン72は、種々の顧客インターフェースから生成された多数の関与を支援するよう設計されている。関与には、情報に対する顧客の要求、解決しなければならない問題チケット、新しいまたはアップグレード順番、システム起動、システムのインストールの予定の決定などを含むことができる。該関与は、要求、約束または取引として表わされる。要求は、関与目標(たとえば顧客の機器の修理など)のステートメントを表わす。該要求に関連する1組の約束は、該要求が完了したと宣言できる前に完了していなければならない該タスクを表わす。promise,各移行状態による関与の追跡、関与の遂行時における、システムの他のコンポーネントの通知などを提供する。図12に戻ると、関与マネージャ内の種々のモジュールから、メッセージサービス86とデータサービス90との間で接続が確立される。関与マネージャ実行部100は、メッセージサービスからの入力要求を処理し、関与マネージャエンジンを構成する機能コンポーネントを介して制御の流れを監視する。関与に関連する該メッセージに関して、関与マネージャエンジン実行部はプロセス関与機能を起動し、支持された関与情報をデータサービスから獲得し、メッセージによって指定された処理を変更する(たとえば、関与の状態のチェック、または関与からの状態移行の駆動など)。関与通知の発行モジュール104は、関与状態の変更の結果、他のシステムコンポーネントの調整を開始するという機能を果たす。components.新しい関与の作成108と現行関与の管理106のための機能も関与マネージャに含まれる。最後に、遺産システム調整の機能102は、特定の関与上で状態の報告を支援するために必要とされる遺産関与管理システムとの対話を管理する機能を果たす。翻訳エンジン74のシステム図を図13に示す。翻訳エンジンは、EFTやクレジットカード情報などの外部ソースからの複素データ形式を、本文書で説明されるシステムによって使用される標準形式に変換するよう設計されている。反対に、翻訳エンジンは、内部システムデータを外部ソース120に送られるよう形式化できる。本翻訳機能は、種々の変換ルーチンを含む1組のツールによって実行される。mode,複数個を組み合わせて使用される。業界プロトコルに基づいた外部データ形式は、他のエンジンによる処理のため、簡略データ形式に翻訳でき、あるいは、エンジンからの出力データは、産業プロトコルまたは、操作会社によって決定される請求パラメータに基づいて外部データ形式に変換できる。該特定エンジンは形式化ルーチンと、形式化規則と、処理システムサービスとを含む。該エンジンによって実行される翻訳は、規則と密接に結びついている。rules.構成規則118は、データサービス86を介して適用でき、指定外部データソースとやり取りするデータの形式化という唯一のタスクを有する翻訳エンジンを起動する。これらの例において、翻訳エンジンは、単一の外部データソース用のデータゲートウェイとなる。tasks,あるいは個々のエンジンが、システムの各機能領域の性能を最大限に引き出す指定翻訳タスクに適用できるようにしてもよい。gateway,特定の目的でのエンジンの目的の作成を行なうオブジェクトから成る仮想翻訳処理モジュールを含む。構成モデル112は、翻訳エンジン例での再を設定する機能を含む。形式翻訳用のデータパターン規則と機能規則を使って、システム内でのエンジン挙動を制御できる。114は、構成モジュール172からのデータパターン規則によって設定された過負荷機能である。各エンジンには、外部データソースからのデータをシステム形式に形式化する形式モジュールと、データをシステム形式から外部データ形式に翻訳する形式モジュールとがある。該モジュールは両方とも同じデータ形式規則を使用してもよく、主な相違点は、各形式モジュールがそれぞれのスレッドで機能し、本質的に一方向のデータゲートである点にある。図14に開示される見積もりエンジン76は、特定のサービス出来事に関連する料金データのリアルタイムの計算を行なうよう設計されている。該エンジンは、該料金に特定の顧客も結びつける。サービス出来事は、サービスしようの単一例を表わし、接続、インストールのような1度限りのサービス、あるいは製品の購入などの一時的に制限された出来事である。見積もりエンジンは、メッセージサービス86を介して、システムの他の部分と通信する。顧客、価格及び地理情報に関する情報は、データベース124内に格納される。further,選択基準に基づいて、出来事を顧客及び請求プランに結びつける方法を含む。type,搬送媒体、及びデータ転送方向を含むパラメータによって異なる。122を介して、システムプロセスの集中開始と終了を行なう。メッセージ送信サービスは、システムマネージャと見積もりプロセスとの間で双方向メッセージ流を提供する。初期化された見積もり機能126は、見積もり状態装置とサービス出来事列を初期化するという機能を果たす。予備初期化タスクが実行されると、エンジン登録要求がシステムマネージャに送られる。終了メッセージが受信されると、エンジン登録要求がシステムマネージャに送られる。見積もりオブジェクトの検索130には3つの主要な機能がある。第1の機能は、持続性格納装置に対して列を実行することである。2番目は、関連からオブジェクトへのデータマッピングである。3番目は、オブジェクトの組立と分解である。エンジンキャッシュマネージャ134は、キャッシュ見積もりオブジェクトの管理という機能を果たす。該マネージャはオブジェクト日付変更の格納、検索及び管理を行なう機構を提供する。サービス記録処理機能128は、内部のサービス出来事列の監視を行なう。見積もり記録機能132は、見積もりプロセスのその他の部分のために単一または多数の実行スレッドを確立する機能を果たすプロセスを実行する。サービス出来事記録要求を処理するために必要なスレッド数は動的に変化できる。サービス出来事特徴の検査モジュール136は、複数の異なる機能を提供する。該機能としては、サービスの種類の決定、記録の有効性確認サービス、アドレスで呼び出し自在のユニットマッピングサービスへのサービス出来事の記録、料金プランサービスへのアドレスで呼び出し自在のユニット、昼間の時間の正規化、サービス出来事の開始と終了の決定、及びサービス提供者の決定を含む。適用見積もり規則の適用モジュール138は見積もり計算機にとって必要不可欠である。該プロセスは、適用可能なすべての見積もり規則を入力として利用し、特徴を決定し、検査し、その結果得られた料金をサービス出来事記録に適用する。最後に、送り出し記録の処理モジュール140が出力サービス記録の処理を行なう。該モジュールは、見積もられたサービス出来事のルート決定と、サービス記録の例外処理と、拒否されたサービス出来事とを処理する機構を提供する。図15で、請求エンジン78は、集合レベルでのサービス利用を見積もる。要約利用記録を見積もり、サービス利用記録の集合に適用するために、該請求エンジンを利用できる。管理下にある請求の特徴としては、数量割引スケジュールと、取引集計に基づく層状コストと、特別促進と、団体と個人ユーザの会社との間の料金の分離を特定化し、適用する能力と、課税された税金の支払能力などを含む。該さまざまな機能に情報を検索するために、複数の異なるデータベースが請求システムに接続される。1つのデータベースはシステム情報186を含み、他のデータベースは外部データゲートウェイ情報198を含み、さらに他のデータベースは請求可能な項目列196を含む。請求モジュールは、他のデータベースを介して規則と送り状のセットにアクセスする。図15で、顧客料金モジュール204の集合は、請求エンジンの顧客料金を集金し、割当計算モジュール206に適用する。請求プロセスの前に、エンジンは、指示された請求サイクルの全料金を読み出し、顧客及び料金タイプによってグループ分けを行なうことで、プロセスを開始する。集金が行なわれると、割引モジュール208が分離の前後に割引を適用する。192によって提供される一連の規則にしたがって適用される。208は論理的に組み合わされ、より複雑な割引機構を形成し、個々の料金または料金群に適用できる。分離モジュール202により、請求を目的として契約者をグループ分けできる。次に、グループは任意の階層に配される。具体的には、規則ベース分離が該階層に重畳される。さまざまな分離規則がさまざまなサービス料金のコンポーネントに適用される。分離規則は、論理的に組み合わされ、より複雑な分離規則を形成し、たとえば企業が月の均一サービス料金を支払う。通貨交換後など、いつでも適用できる。四捨五入は、切り上げ、切り捨て、四捨五入を含む規則セットにしたがって適用される。送り状作成モジュール212は、すべての割引と分離が実行され、適切な税金が加算された後に送り状を作成する。各送り状のすべての回線項目には、送り状番号がタグ付けされ、出力管理84に送られる。通貨交換が必要な場合は、該情報は通貨交換モジュール200から提供される。繰り返し料金エンジンが図16に示され、毎月のサービス料金など、定期的に繰り返される料金の発生を処理する。繰り返し料金エンジンは、直線的、または変動規則のセットにしたがって、サービスの開始及び終了の割当計算を実行する。出来事マネージャは、料金発生のスケジュール決定を管理する。出来事マネージャによって信号を受けると、繰り返し料金エンジンは、必要な顧客情報、請求サイクル情報、パッケージ価格情報をロードし、各顧客に関して回線項目料金の発生を開始する。各料金が発生すると、料金の周期に基づいて、繰り返し料金エンジンが次の料金発生の予定を立てる。図16で、繰り返し料金エンジンは、データサービス90を介して、請求可能な項目列、規則セット及びシステム情報などの項目にアクセスできる。繰り返し料金エンジン内には、料金作成機能220が含まれる。繰り返し料金エンジンは、出来事マネージャからの外部信号に基づいて、料金算出を開始する。パッケージ価格情報をロードする。次に、回線項目料金の作成を開始する。各料金が発生すると、繰り返し料金エンジンは次の料金発生の予定を決定する。割当機能222が、規則による定義にしたがって標準または非標準の方法のいずれかで適用される。規則に基づいて、四捨五入機能224が、指定された通りに料金を切り上げ、切り下げ、または四捨五入する。図17では、歳入管理エンジン82が開示される。分配に関する滞納を含むビジネス機能を提供する。歳入管理エンジンはメッセージサービスとインターフェース接続され、種々の財務ゲートウェイと会計情報のやり取りを行ない、アドレス呼び出し可能性ゲートウェイに停止及び起動要求を送る。送金ゲートウェイから送金要求を受信する。データ格納分配規則の優先順位決定と対話する。図17で、滞納及び集金モジュール234は会計規則と時間効果規則を管理する。参照先から集金機関に出力が生成される。会計管理モジュール232は、未払いの収支と開放項目に支払いを一致させる。会計管理モジュール232は、送金を適用する歳入アカウントを特定化し、それにしたがって送金を割り当てる。歳入認識モジュールは、適切な歳入アカウントに前払いの資金を適切に適用する。勤労所得と不労所得を正しく認識、管理する。最後に、料金処理モジュール236により、単一の取引に基づく歳入が多数の取引先に分配される。図18は、出力管理エンジン84のシステム図である。メッセージサービスを介して規則エンジンから規則を組み込み、異なる複数のソースからの要求に応じて、報告書が作成できる。CSRまたは顧客は、データネットワークを直接介して、出力管理エンジンに命令を送り、特定の顧客に単一の報告書240を発行する。システムユーザはGUIを介してバッチ報告書24を請求し、バッチ報告書244は、その後、所望の形式で、データサービスを介して出力される。最後に、システム管理者は、データベースに格納された報告書を作成、修正及び削除できる。請求要約エンジン85を図19に示し、これは、請求と歳入管理によって作成された顧客データを収集し、顧客送り状に変形できる形態に顧客データを提示するという機能を果たす。請求要約エンジンはすべてのアカウントデータを読み出し、分類し、送り状に必要な全情報を作成し、データベースの1つに格納された形式使用にしたがって、出力データファイルを作成する。その結果得られた出力データファイルは、適切な代理人に転送され、印刷及び郵送される。図19では、メッセージサービスとデータサービスを介して、種々のシステムデータベースに接続が確立される。250は、指定請求サイクルで各アカウントの全請求情報を読み込む。これには、アカウント料金、クレジット、調整、合計、ならびにアカウントの請求アドレスも含まれる。料金の分類と注文モジュール252は、どの報告書がそれぞれのアカウントの送り状であるかを探し、該報告書のための料金種別マッピングをロードする。次に該料金種別マッピングを使用して、各送り状に関して全アカウント料金を指示する。追加/送金/返送アドレスモジュール254は、各送り状の送金及び返送アドレスを発見する。通知の追加モジュール256は、送り状に特別な通知を配するか、送り状に特別な通知を含める。最後に、送り状データの形式化モジュール258が送り状を印刷に適切な形式にする。本発明の以上の説明は、例示と説明を目的として提示された。説明は、本文書に開示された形態に本発明を制限することは意図しない。Therefore,上記の開示と同様の変更及び修正、ならびに関連技術または知識は本発明の範囲内にある。上記の実施例はさらに、本発明を実施するために知られた最良の形態を説明し、本発明の特定の適用例または使用例によって必要とされる種々の修正を行なって、かかる実施例と他の実施例で他の当業者が本発明を利用できるようにすることをさらに意図する。本発明の特許請求の範囲は、先行技術によって許容される範囲で他の実施例も含むと解釈されることを意図する。計算型アーキテクチャの図。ネットワーク化システムにおける計算型アーキテクチャの一実施例。適応性層支援の特徴を示すブロック図。オブジェクト志向多層システムの全体像を示すブロック図。サーバの構成と層構成のカスタムインターフェースを特に示した詳細ブロック図。システムマネージャの動作を説明するブロック図。規則サービスの動作を説明するブロック図。出来事マネージャの動作を説明するブロック図。データ管理サービスの動作を説明するブロック図。請求システム実施例における計算型アーキテクチャのブロック図。顧客要約エンジンのシステム図。関与管理エンジンのシステム図。翻訳エンジンのシステム図。見積もりエンジンのシステム図。請求エンジンのシステム図。繰り返し料金エンジンのシステム図。歳入管理エンジンのシステム図。出力管理エンジンのシステム図。請求要約エンジンのシステム図。成る多層構造をさらに備えた請求項1に記載の装置。unitに記載の装置。システムサービス装置が、処理装置の操作と、ユーザインターフェースとデータ格納手段との間のデータ交換を支持する複数個の処理モジュールを含む請求項1に記載の装置。中間層が、ユーザインターフェース上に提示されるオブジェクトの関連データ格納デバイスへのオブジェクト・関連データベースマッピングを含む請求項2に記載の装置。中間層とクライアント層との通信がジャバRMIを介して行なわれる請求項2に記載の装置。中間層が提示オブジェクトファクトリを含む請求項2に記載の装置。基底層がビジネス及びドメインオブジェクトファクトリを含む請求項2に記載の装置。請求システムにアーキテクチャが組み込まれる請求項1に記載の装置。unitに記載の装置。システムサービス装置が、処理装置の操作と、ユーザインターフェースとデータ格納手段との間のデータ交換を指示する複数個のシステムサービスモジュールを含む請求項9に記載の装置。処理モジュールが:顧客要約エンジン、関与管理エンジン、翻訳エンジン、見積もりエンジン、請求エンジン、繰り返し料金エンジン、歳入管理エンジン、出力管理及び請求要約エンジンの少なくとも1個を含む請求項11に記載の装置。システムサービスモジュールが:システムマネージャ、規則サービス、出来事管理サービス、メッセージ送信サービス、データ管理サービス、ログサービスの少なくとも1個を含む請求項11に記載の装置。該システムが、少なくとも1台のユニックスサーバ上で実行される請求項14に記載の装置。該インターフェース手段が、計算型プラットホームと、メモリと、出力デバイスとの間で情報を搬送するためのメッセージ送信サービスを含む請求項14に記載の装置。計算型プラットホームが、該特定データ処理アプリケーションに固有の要素から独立して、該計算型ベース機能を実行する少なくとも1個の処理エンジンを含む請求項14に記載の装置。特定アプリケーションが請求及び顧客サービスに関する請求項14に記載の装置。少なくとも1つを含む請求項18に記載の装置。インターフェースが、情報の入力と受信に少なくとも1個のグラフィカルユーザインターフェースを使用する請求項16に記載の装置。中央サーバと、該中央サーバと少なくとも1個のグラフィカルユーザインターフェースとの間に位置する少なくとも1個の中間サーバとからさらに成り、該中間サーバがメモリと接続され、グラフィカルユーザインターフェース上で受理された情報に基づいて、メモリから関連情報を検索し、ローカルメモリに該関連情報を格納する請求項20に記載の装置。ローカルエリアネットワーク上で、該少なくとも1個のグラフィカルユーザインターフェースと接続が確立される請求項20に記載の装置。WWWを介して、該少なくとも1個のグラフィカルユーザインターフェースと接続が確立される請求項20に記載の装置。該基底層が関連データベースを含む請求項24に記載のシステム。中間サーバが、提示オブジェクトを、基底サーバ内のビジネス及びドメインオブジェクトにマッピングするオブジェクト・関連マッピングを提供する請求項24に記載のシステム。データネットワークを介して中間サーバとユーザインターフェース間に接続が確立できる請求項24に記載のシステム。データネットワークがWWWである請求項27に記載のシステム。データネットワークがローカルエリアネットワークである請求項27に記載のシステム。中間サーバが基底サーバから離れて位置し、通信ネットワークを介してメッセージバスが提供される請求項24に記載のシステム。容とデータ形式の一方を含む各ステップから成る方法。アプリケーション固有情報が顧客サービスと請求に関する請求項31に記載の方法。少なくとも1つを含む請求項31に記載の方法。該入出力ステップがデータネットワークを使用して実行される請求項31に記載の方法。該データネットワークがWWWである請求項31に記載の方法。システムユーザに関連する出力情報が、該システムユーザがシステムにアクセスした際に、中間層に提供される請求項31に記載の方法。management。