(57)【要約】種々のソースの相異なる種別のデータを収容している金融サービスシステムのデータベースプールなどの分散データベースシステムへのアクセスを調整するための方法およびシステムであって、金融取引処理の状況に関するクエリなどのユーザクエリを入力として受信する。クエリを処理して、このクエリを満たすために必要とされるデータの種別およびこのようなデータを収容しているターゲットとなるデータソースを判定する。離散的なサブクエリが編成され、特定されたターゲットとなるデータソースに対して発行される。取り出されたデータは、組み合わされて、クエリに対する応答を生成する。この応答は、好ましくは、インターネットのウェブページの形態にフォーマット設定され、要求した者に返される。【特許請求の範囲】
【請求項１】
複数のデータソースをその中に有するデータベースプールと通信しているシステムにおいて、前記各データソースにはそれぞれの種別の情報が入っており、前記システムに対するユーザのクエリを処理する方法は、
ユーザのクエリを電子的ネットワーク経由で受信するステップと、
前記クエリを満たすために必要とされるデータの種別を判定するステップと、
前記判定された種別の情報を収容する前記複数のデータソースから目標のデータソースを識別するステップと、
前記目標のデータソースからデータを取り出すステップと、
前記取り出されたデータを組み合わせて、前記クエリに対する応答を生成するステップと、
前記ユーザへ前記応答を返すステップと
を備えることを特徴とする方法。
【請求項２】
前記識別されたソースからデータを取り出す前記ステップは、
前記目標の各データソース向けのサブクエリを生成するステップと、
前記それぞれの目標のデータソースに対してサブクエリを発行するステップと、
前記発行されたサブクエリについて前記それぞれの目標のデータソースから応答を受信するステップと
を備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記各データソースは、それぞれのデータクエリフォーマット有し、
前記サブクエリは、実質的に共通のクエリフォーマットを有し、
前記サブクエリを発行する前記ステップは、前記各サブクエリを前記共通のデータクエリフォーマットから前記それぞれの目標のデータソース向けの前記データクエリフォーマットへ変換するステップを備えることを特徴とする請求項２に記載の方法。
【請求項４】
前記発行されたサブクエリの状況をモニターするステップをさらに備え、
前記取り出されたデータを組み合わせる前記ステップは、前記発行された各サブクエリについて応答を受信した後に行われることを特徴とする請求項２に記載の方法。
【請求項５】
前記各サブクエリは、別個の処理スレッドによって発行され、前記各処理スレッドは、前記それぞれのサブクエリが対応する前記目標のデータソースによって満たされた時に通知を出すことを特徴とする請求項２に記載の方法。
【請求項６】
前記システムは、金融取引処理システムを備え、
前記ユーザクエリは、前記金融取引処理の状況に関することを特徴とする請求項１に記載の方法。
【請求項７】
前記金融取引処理は通貨両替取引処理を備えることを特徴とする請求項６に記載の方法。
【請求項８】
前記データベースプールは、
参照情報向けのデータソースと、
口座情報向けのデータソースと、
取引情報向けのデータソースと、
取引支払い指示情報向けのデータソースと
を備えることを特徴とする請求項７に記載の方法。
【請求項９】
各データソースがそれぞれの種別の情報を収容する複数のデータソースにアクセスを要求するクエリを処理するためにコンピュータで実施されたシステムにおいて、該システムは、
前記複数のデータソースと通信しているデータアクセスモジュールであって、
入力として所定のフォーマットでクエリオブジェクトを受信し、
前記クエリオブジェクトのクラスに従って一組の目標のデータソースを識別し、
前記目標のデータソースからデータを取り出し、
前記取り出されたデータを集約し、
前記集約されたデータを出力として提供するように構成された前記データアクセスモジュールと、
前記データアクセスモジュールと通信しているデータリクエストハンドラモジュールであって、
入力としてデータクエリを受信し、
前記データクエリから前記所定のフォーマットで前記クエリオブジェクトを生成し、
前記クエリオブジェクトを前記データアクセスモジュールへ提供し、
前記データアクセスモジュールから前記集約されたデータを受信し、
前記集約されたデータを処理して、前記クエリに対する応答を作成し、
前記応答を出力として提供するように構成された前記データリクエストハンドラモジュールと
を備えたことを特徴とするシステム。
【請求項１０】
入力としてユーザからネットワーク経由でデータリクエストを受信し、
前記データリクエストに従ってデータクエリを生成し、
前記データクエリを前記データリクエストハンドラモジュールに提供し、
前記データリクエストハンドラモジュールから前記応答を受信し、
前記応答を前記ネットワーク経由で前記ユーザに出力するように構成されたプレゼンテーションモジュールをさらに備えたことを特徴とする請求項９に記載のシステム。
【請求項１１】
前記プレゼンテーションモジュールは、
各データサーブレットが特定の種別のデータリクエストに応答して適切なデータクエリを作り出すように構成された複数のデータサーブレットと、
前記データリクエストの前記種別を判定し、前記データリクエストを前記適切なデータサーブレットに転送するように構成されたコントローラサーブレットと
を備えたことを特徴とする請求項１０に記載のシステム。
【請求項１２】
前記各データサーブレットは、転送されたデータリクエストに対するそれぞれの応答を受信するようにさらに構成されたことを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記プレゼンテーションモジュールは、各サーバページがそれぞれのデータサーブレットと関連付けられており、該関連付けられたデータサーブレットから前記それぞれの応答を受信し、前記それぞれの応答を含む対応するドキュメントを生成するように構成された複数のサーバページを備えたことを特徴とする請求項１２に記載のシステム。
【請求項１４】
特定のサーブレットは、複数の関連するサーバページを有し、前記特定のサーブレットは、前記応答のデータ種別に従って前記関連するサーバページの１つに対して前記それぞれの応答を提供するように構成されたことを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記ドキュメントはインターネットのウェブページを備えたことを特徴とする請求項１３に記載のシステム。
【請求項１６】
前記データアクセスモジュールは、
各データマネージャがそれぞれのデータソースからデータを取り出すように構成された複数のデータマネージャと、
クエリのクラス分類データを格納した記憶領域と、
入力として前記クエリオブジェクトを受信するデータソースマネージャであって、
前記クエリのクラス分類データに従ってそこから取り出されるべき前記複数のデータソースの内の前記特定のデータソースを識別し、
前記識別されたデータソースからデータを取り出すように構成された前記特定のデータマネージャオブジェクトに対して前記クエリオブジェクトから導き出されたそれぞれのデータ取り出しリクエストを発送するように構成された前記データソースマネージャと
を備えたことを特徴する請求項９に記載のシステム。
【請求項１７】
前記それぞれのデータマネージャオブジェクトから取り出されたデータを集約するように構成された同期化モジュールをさらに備えたことを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記各データマネージャオブジェクトは、共通のフォーマットで前記データソースマネージャからデータ取り出しリクエストを受信するように構成されたそれぞれのデータマネージャインターフェイスを備えたことを特徴とする請求項１６に記載のシステム。
【請求項１９】
前記クラス分類データは、クエリの特定の種別を特定のデータソースと関連付けるクエリマッピングデータを備えたことを特徴とする請求項１６に記載のシステム。
【請求項２０】
前記クラス分類データは、複数の部分を有する複合的なクエリについて、特定のクエリ部分を特定のデータソースと関連付けるクエリ分配データをさらに備えたことを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記データソースには金融取引処理に関する種々の情報を収容しており、前記クエリは、少なくとも１つの前記金融取引処理の状況に関係していることを特徴とする請求項９に記載のシステム。
【請求項２２】
前記金融取引処理は、通貨両替取引処理を備えたことを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記複数のデータソースは、
参照情報向けのデータソースと、
口座情報向けのデータソースと、
取引情報向けのデータソースと
取引支払い指示情報向けのデータソースと
を備えたことを特徴とする請求項２２に記載のシステム。
【請求項２４】
金融取引処理システムに対するユーザクエリを処理するための方法であって、前記クエリを満たすために必要とされるデータが、各データソースにそれぞれの種別の情報を収容する複数のデータソースをその中に有するデータベースプールに格納されていて、前記データソースが、参照情報と、口座情報と、取引情報と、取引支払い指示情報向けのデータソースを含んでいる方法において、該方法は、
前記金融取引処理システムによって管理された金融取引処理の状況に関するユーザクエリをネットワーク経由で受信するステップと、
前記クエリを満たすために必要とされるデータの種別を判定するステップと、
前記判定された種別の情報を収容する前記複数のデータソースから目標のデータソースを識別するステップと、
前記目標のデータソースからデータを取り出すステップと、
前記取り出されたデータを組み合わせて、前記クエリに対する応答を生成するステップと、
前記応答を前記ユーザに返すステップと
を備えることを特徴とする方法。
【請求項２５】
前記識別されたソースからデータを取り出す前記ステップは、
前記目標の各データソース向けにサブクエリを生成するステップと、
前記サブクエリを前記それぞれの目標のデータソースに発行するステップと、
前記発行されたサブクエリについて前記それぞれの目標のデータソースから応答を受信するステップと
を備えることを特徴とする請求項２４に記載の方法。
【請求項２６】
前記各データソースは、それぞれのデータクエリフォーマットを有し、
前記サブクエリは、実質的に共通のデータクエリフォーマットを有し、
前記サブクエリを発行する前記ステップは、前記各サブクエリを前記共通のデータクエリフォーマットから前記それぞれの目標のデータソース向けの前記データクエリフォーマットへ変換するステップを備えることを特徴とする請求項２５に記載の方法。
【請求項２７】
前記発行されたサブクエリの状況をモニターするステップをさらに備え、
前記取り出されたデータを組み合わせる前記ステップは、前記発行された各サブクエリについて応答を受信した後に実行されることを特徴とする請求項２５に記載の方法。
【請求項２８】
前記各サブクエリは、別個の処理スレッドによって発行され、前記各処理スレッドは、前記それぞれのサブクエリが対応する前記目標のデータソースによって満たされた時に通知を出すことを特徴とする請求項２５に記載の方法。
【請求項２９】
金融取引処理の状況に関して金融取引処理システムに対して発行されたクエリを処理するためのコンピュータで実施されたシステムであって、前記クエリは、各データソースにそれぞれの種別の情報を収容する複数のデータソースにアクセスを要求し、前記データソースは、参照情報と、口座情報と、取引情報と、取引支払い指示情報向けのデータソースを含んでいるシステムにおいて、該システムは、
前記複数のデータソースと通信しているデータアクセスモジュールであって、
入力として所定のフォーマットでクエリオブジェクトを受信し、
前記クエリオブジェクトのクラスに従って一組の目標のデータソースを識別し、
前記目標のデータソースからデータを取り出し、
前記取り出されたデータを集約し、
前記集約されたデータを出力として提供するように構成された前記データアクセスモジュールと、
前記データアクセスモジュールと通信しているデータリクエストハンドラモジュールであって、
入力としてデータクエリを受信し、
前記データクエリから前記所定のフォーマットで前記クエリオブジェクトを生成し、
前記データアクセスモジュールに前記クエリオブジェクトを提供し、
前記データアクセスモジュールから前記集約されたデータを受信し、
前記集約されたデータを処理して、前記クエリに対する応答を作り出し、
前記応答を出力として提供するように構成された前記データリクエストハンドラモジュールと
を備えたことを特徴とするシステム。
【請求項３０】
入力としてユーザからデータリクエストをネットワーク経由で受信し、
前記データリクエストに従ってデータクエリを生成し、
前記データクエリを前記データリクエストハンドラモジュールに提供し、
前記データリクエストハンドラモジュールから前記応答を受信し、
前記応答を前記ユーザに前記ネットワーク経由で出力するように構成されたプレゼンテーションモジュールをさらに備えたことを特徴とする請求項２９のシステム。
【請求項３１】
前記データアクセスモジュールは、
各データマネージャがそれぞれのデータソースからデータを取り出すように構成された複数のデータマネージャオブジェクトと、
クエリのクラス分類データを格納した記憶領域と、
入力として前記クエリオブジェクトを受信するデータソースマネージャであって、
前記クエリのクラス分類データに従ってそこから取り出されるべき前記複数のデータソースの前記特定のデータソースを識別し、
前記識別されたデータソースからデータを取り出すように構成された前記特定のデータマネージャオブジェクトに前記クエリオブジェクトから導き出されたそれぞれのデータ取り出しリクエストを発送するように構成された前記データソースマネージャと
を備えたことを特徴とする請求項２９に記載のシステム。
【請求項３２】
前記それぞれのデータマネージャオブジェクトから取り出されたデータを集約するように構成された同期化モジュールをさらに備えたことを特徴とする請求項３１に記載のシステム。
【請求項３３】
各データマネージャオブジェクトは、共通のフォーマットで前記データソースマネージャからデータ取り出しリクエストを受信するように構成されたそれぞれのデータマネージャインターフェイスを備えたことを特徴とする請求項３１に記載のシステム。
【請求項３４】
前記クラス分類データは、クエリの特定の種別を特定のデータソースと関連付けるクエリマッピングデータを備えたことを特徴とする請求項３１に記載のシステム。
【請求項３５】
前記クラス分類は、複数の部分を有する複合的なクエリについて、特定のクエリ部分を特定のデータソースと関連付けるクエリ分配データをさらに備えたことを特徴とする請求項３４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データクエリ処理システムの分野に関する。より詳細には、本発明は、要求を満たすために複数の相異なるデータソースにアクセスする必要のあるクエリ（照会）を処理するための方法およびシステムに関する。
【背景技術】
【０００２】
金融有価証券、通貨、および他の金融商品の電子取引は、広く実践されている。投資家が電子的に売買を行うために、投資家は、通例、適当なオンラインの仲買人または他の金融サービス提供者に登録しなければならない。多くの種類の金融取引では、複数のステップを含み、こうした取引の開始から確認そして決済までには、比較的長期の時間がかかることがある。この時間の間に、トレーダーは、既に設定され、完了までの種々の段階にある可能性のある取引の種々の側面の状況を判断したいと思う場合がある。
【０００３】
現在のところ、この情報を提供する能力は限られている。このことは、国際通貨を取引している金融サービス提供者などのサービス提供者にとって特にそうであり、こうしたサービス提供者は、取引業務の種々の段階で使われていくつかの別個のシステムを有し、それらシステムのそれぞれが異なるデータベースを利用することがある。例えば、ある顧客が、いろいろな日付で、それぞれがおそらくは異なる決済指示を有する、いくつかの相異なる通貨の両替を実行したいと希望することがある。各両替には、いくつかの別々に規定された割当の確認を必要とし、金融サービス提供者は、各割当について金融および決済の細目を確認するために、複数の個人と連絡を取る必要があるかもしれない。中央のシステムへ単一もしくは少数の関連する照会を発行することによって、取引の確認状況および当該取引の種々の部分要素を含めて、こうした顧客の未済の取引処理のすべてに関する情報を、素早くそして簡単に入手することができることは顧客にとって好都合であろう。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来型のオンラインシステムは、顧客によって為された照会にオンディマンドで応答してこの種の何らかの情報を返すための機能を含むこともあるが、現行のシステムは限定的である。ひとつの問題は、照会を完全に満たすために必要とされる情報が金融サービス提供者の様々なシステムの全体に渡って分散しているので、顧客に返される情報は、一般に完全ではないということである。結果的に、顧客は、いくつかの異なる照会をサービス提供者の様々なグループまたは部門に発行して、所望の情報を収集しなければならない。この問題は、所望のデータが直接オンラインでアクセスできない場合にさらに悪化する。この問題に対する従来の解決策は、顧客の紹介を仕向けることのできる中央のサイトを提供することである。照会は人の手で処理され、その結果が顧客に返される。このシステムでは、一般的な顧客の紹介に十分に対処することができるようになるけれども、これは時間がかかり、非効率的である。
【０００５】
本発明の１つの目的は、顧客が１つまたは２つ以上の取引または他の金融取引処理の状況を直接モニターできるようにする改良された機能を備えるシステムを提供することである。
【０００６】
本発明の更なる目的は、顧客がこのシステムを通じて、金融サービス提供者または関係者によって使用中の複数の別個のデータベースから得られる、未済取引に関する情報を受けることができるシステムを提供することである。
【課題を解決するための手段】
【０００７】
上記およびその他の目的は、顧客の照会を処理し、分散したデータベースに対するアクセスを調整して、この照会を満たすために必要とされるデータを取り出すように構成されているシステムによって対処される。ある特定の実施形態は、種々の金融取引処理の状況に関する顧客の照会を処理するために金融サービス提供者による使用に適している。このシステムは、複数のデータソースをその中に持つデータベースプールにアクセスする。各データソースには、それぞれの種別のデータが入っている。ひとつの実施形態において、データプールは、顧客参照情報、口座情報、取引情報、取引支払い指示について別個のデータソースを収容している。種々の取引処理に関する顧客の照会に答えるためには、通例、いくつかのデータソースから情報を取り出し、これらソースからのデータをこの顧客の照会にとって適した応答に組み合わせる必要があるであろう。
【０００８】
本発明の１つの態様によれば、顧客のクエリ（照会）を、例えば、電子的なネットワーク経由で、受け取ると、このクエリを分析して、クエリを満たすために必要とされるデータの種別を判定し、このクエリを一連の個々のサブクエリに分解する。関連表を使って、各サブクエリについて目標のデータソースを特定し、それぞれの目標のデータソースに対してこれらのサブクエリを発行する。取り出したデータを組み合わせ、受け取ったクエリにふさわしいフォームにフォーマット設定し、このデータをクエリの発行者に返す。
【０００９】
明らかなように、相異なるデータソースには、相異なるクエリのフォーマットが必要になることがある。ある特定の実施形態においては、各データソースまたはデータソースの種別のそれぞれに対して別個のデータオブジェクトが与えられている。各データマネージャは、関連するデータソースに見合うフォーマットでクエリを発行するように構成されている。各データマネージャは、標準のインターフェイスをも有して、上流のシステムコンポーネントがすべてのデータマネージャを同等に扱えるようにする。データソースマネージャは、入力としてクエリオブジェクトを受け取り、適切なデータマネージャにサブクエリを発行するように構成され、提供されている。データマネージャから受け取った応答を処理する。このデータは、すべての未解決のサブクエリに対する応答を受け取るまで、各サブクエリを処理しつつ、集約することができるのが好ましい。
【００１０】
クエリ応答データは、顧客に返される前に、種々の方法でフォーマット設定することができる。ひとつの実施形態においては、顧客とデータリクエスト処理モジュールとの間のインターフェイスとして機能するプレゼンテーションモジュールが提供される。プレゼンテーションモジュールは、複数のデータサーブレットを備え、その各々がデータリクエストの特定の種別に応答して適切なデータクエリを作り出し、このクエリに対する応答を受け取るように構成されている。プレゼンテーションモジュールはさらに、複数のサーバページを備え、それら各々がそれぞれのデータサーブレットと関連付けられている。各サーバページは、関連するデータサーブレットから応答を受け取り、顧客への配信に向けて、インターネットウェブページなどの対応するドキュメントを生成するように構成されている。ここで、この生成されたドキュメントはそれぞれの応答を含んでいる。
【００１１】
本発明によるシステムおよび方法によれば、多様な相異なるデータソースにアクセスを必要とする顧客のクエリに、自動化された方法でサービスすることができる利点がある。これにより、例えば、金融サービス提供者の顧客が１つまたは複数の金融取引処理の状況を、こうした取引処理に相異なる金融商品が含まれ、異なるシステムによって処理されている場合であっても、直接モニターすることができるようにする。このシステムはまた、モジュール化されており、簡単に構成できるので、追加のデータソースにリンクを加えることは比較的簡単である。
【発明を実施するための最良の形態】
【００１２】
本発明の前述およびその他の特徴は、本明細書の詳細な説明および本発明の例示となる実施形態の図面からさらに容易に明らかとなるであろう。
【００１３】
図１を参照すると、本発明を組み込んでいるシステム１０の高次のブロック図が示されている。システム１０は、電子金融サービス提供者２０によって運営することができる。サービス提供者２０は、一般に、金融取引処理の種々の態様を実現するための相異なる処理システムを有することになる。様々な通貨の両替に適したある特定の実施形態において、提供者２０は、取引システム２２、取引処理システム２４、そして確認および決済システム２６を備えている。これらのシステム２２、２４、２６は、典型的には提供者２０の雇用者である種々の取引支援要員によってアクセスすることができる。
【００１４】
これらの様々なシステム２２〜２６は、金融取引業務を処理し、複数の別個のデータベースの中に関連したデータを格納するために使われている。これらのデータベースは、総合して、データベースプール３０を構成するものとみなすことができる。ある特定の例においては、参照データ３２、口座データ３４、取引データ３６、取引支払い指示３８、ならびに種々のその他の種別のデータ４０用に別個のデータベースが備えられている。種々のシステム２２〜２６によってデータベースプール３０においてアクセスされるデータ間に何らかの重複があるかもしれないが、一般に、各システムは、プール３０にあるデータベースの総数のせいぜい一部にアクセスするように設計されている。結果として、単一のシステムがある顧客の未済の取引処理の状況の全体像を提供するために必要とされるデータのすべてに直接アクセスすることは一般的ではないであろう。
【００１５】
多数の機構を通して金融サービス提供者に売買取引を設定することができる。例えば、顧客４２は、電話、ファクシミリ、または他の手段によって取引支援要員２８の一人と直接的にコンタクトすることができる。ある特定の実施形態において、サービス提供者２０はさらに、インターネットなどのネットワーク５０に接続されているオンライン取引モジュール５２を含み、こうしたネットワークを通して、顧客４２が売買取引を行うためにシステムにアクセスすることができる。
【００１６】
本発明のひとつの態様によれば、データベースプール３０およびネットワーク５０の間で接続され、顧客４２がゲートウェイを通して自身の未済の取引処理の１つ、いくつか、または全部についての包括的な情報を入手することができるゲートウェイを提供するように構成されている、本明細書にて（「Ｗｅｂ  ＳＴＰ」）と称される、ウェブに基づいた「直通」処理システム１００が提供される。下記でより十全に検討するように、Ｗｅｂ  ＳＴＰシステム１００は、顧客のクエリを処理し、データベースプール３０にある該当するデータベースから適切な情報を取り出し、動的に生成されたウェブページのフォームなどで、顧客に情報を届けるように構成された機能を収容する。システム１００は、いろいろな方法で実現することができる。好ましくは、このシステムは、データベースプール３０またはそのコピーに接続されているアプリケーションサーバ上で実行する一連のプログラムモジュールとして実現される。アプリケーションサーバは、サービス提供者２０によって使用される１つまたは複数のシステムをホストすることもできるし、独立型のシステムとすることもできる。
【００１７】
図２を参照すると、Ｗｅｂ  ＳＴＰシステム１００の機能図が示されている。システム１００は、直接データベースプール３０に接続することができる。あるいはまた、特にプール３０を構成するデータベースが、１つまたは２つ以上の、多分遠隔地に設置されている場合、該当するデータベースのコンポーネントをシステム１００の近くに複製して、図示したようにローカルのデータベースプール３０’を形成することができる。従来からあるサイベース（Ｓｙｂａｓｅ）の複製ツールを使用するなどして、種々の手法を使って、データベースを複製することができる。システム１００は、直接データベースプール３０、３０’に接続することができる。しかし、この接続は、適切なファイアウォール（図示せず）を通じて為されるのが好ましい。明らかなように、データベースプールのローカルのバージョンを保持することにより、種々のデータベースのコンポーネントへのアクセスが速くなる一方で、システム１００は、代替として、当業者に知られている従来のネットワークに基づく技術を使用して、遠隔地に設置した種々のデータベースのコンポーネントに接続することもできる。
【００１８】
好ましい実施例において、システム１００は、データアクセスオブジェクトモジュール１１０、ビジネスロジックオブジェクトモジュール１２０、プレゼンテーションオブジェクトモジュール１３０の３つの主要素から構成される。データアクセスオブジェクトモジュール１１０は、プール３０’にあるデータベースに対するデータアクセスおよび取り出しを調整し、データソースマネージャ１１２および１つまたは２つ以上のデータアクセスモジュール１１４から構成されている。モジュール１１４は、静的な命令セット、ソフトウェア手順、アクティブプログラムもしくはアプレット、またはその他の変形形態とすることができ、入力として与えられる適切にフォーマット設定された一般機能のデータリクエストを処理し、データベースプール３０’にある適切なデータベースからデータを取り出すように命じられる１つまたは２つ以上の派生的なリクエストを生成するために使用される。
【００１９】
データベース３０’へのアクセスは、いろいろな方法で行うことができる。好ましくは、この接続は、データベースに対するある一定数のコネクションを異なるプログラム実行スレッド間で共有するためのメカニズムを提供するデータベースプールコネクション１１６を介して為される。各スレッドがデータベースにアクセスする必要があるときには、コネクションプールマネージャからの接続がリクエストされ、そのデータベースクエリが実行され、プールがスレッドに返される。このシステムによれば、一方でデータベースに対して過度に多くのコネクションを確立するリスクを回避しつつ、複数の顧客からの同時リクエストを効率的に取り扱うことができる。データベースコネクションプール１１６は、当業者に知られているウェブロジック（Ｗｅｂ  Ｌｏｇｉｃ）技術を使って実現するのが好ましい。当然、データベース３０’へのアクセスを提供する他の方法を、代替的に使うことができる。
【００２０】
ビジネスロジックオブジェクト１２０は、データリクエストハンドラ１２２から構成され、さらにデータキャッシュ１２４を含んでもよい。データリクエストハンドラ１２２は、オープンなインターフェイスを提供して、顧客が発したデータクエリを処理し、これらを適切なフォーマットでデータアクセスオブジェクトモジュール１１０に転送するように構成される。好ましくは、データリクエストハンドラは、顧客の行為によって発せられたデータリクエストを表す（そしてシステム１００の他の部分によって処理することもできるように）、ＸＭＬドキュメントなどのドキュメントを受け取るように構成される。データリクエストハンドラは、入力ドキュメントを構文解析し、そのコンテンツに基づいて、適したフォーマットでクエリまたはリクエストオブジェクトを作成し、そのリクエストをデータアクセスオブジェクトモジュール１１０にあるデータソースマネージャ１１２に転送する。データソースマネージャは、クエリへの応答として１つまたは二つ以上のデータを返すことになる。これらのオブジェクトは、データリクエストハンドラ１２２によって、元のデータリクエストに対して適切に処理され、組み合わされる。データは、次に、ＸＭＬドキュメントなどの適したフォーマットに変換され、依頼者に返される。取り出されたデータの一部または全部を、データキャッシュ１２４に格納して、将来の取出しを簡単化することができる。データリクエストハンドラ１２２はおよびデータソースマネージャ１１２については、下記でより詳細に検討する。
【００２１】
プレゼンテーションオブジェクトモジュール１３０は、顧客からの入力リクエストを管理し、ＨＴＭＬドキュメントなどの適したフォーマットで適切なデータが入っている応答を転送する任を受け持つ１つまたは２つ以上のサーブレットまたはモジュールから構成される。ある特定の実施形態において、コントローラサーブレット１３２は顧客から入力を受け取り、適切なデータベース（図示せず）から顧客の口座リストを取り出し、種々のリクエストパラメータの有効性を確認するように構成される。コントローラサーブレット１３２は、次に、リクエストされたデータの種別などのリクエストの種別に従って爾後の取り扱いのために有効性の認められたリクエストを適切なデータサーブレットに転送する。好ましい実施形態においては、取引データサーブレット１３４および標準決済指示データサーブレット１４０が提供される。リクエストが、すべての未済取引処理の要約などの未済の取引に関するデータを取り出すことであれば、このリクエストは、コントローラサーブレット１３２によって取引データサーブレット１３４に転送される。同様に、リクエストが決済指示に向けられる場合には、コントローラサーブレット１３２は、そのリクエストを標準決済指示データサーブレット１４０へ転送する。
【００２２】
当業者には明らかなように、システム１００が処理するように構成されているリクエストの種別に従って、追加のデータサーブレットを含めることもできる。さらに、リクエスト処理機能を、取引データおよび決済指示サーブレットなどの種々のサーブレットに区分することは、単に好ましい実施例であり、種々の機能が実装されるそれら機能間の境界は、変更することができる。他の実施形態において、種々のデータサーブレットの機能は、他のシステム要素間に配分することができる。例えば、データサーブレットの機能は、コントローラサーブレット１３２、またはデータリクエストの全種別に対して提供される単一のデータサーブレットと組み合せることができる。
【００２３】
各データサーブレットは、顧客の選択に従って適切なリクエストを生成し、このリクエストをデータリクエストハンドラ１２２に提起し、リクエストされたデータを含む応答を受け取るように構成される。明らかなように、提出されたリクエストは、データリクエストハンドラ１２２によって認識されるフォーマットであるべきである。好ましくは、リクエストは、ＸＭＬドキュメントとしてフォーマット設定される。
【００２４】
データサーブレットは、次にデータリクエストハンドラ１２２から受け取ったデータを適切な下流のモジュールへ転送する。このモジュールは、その（部分的に処理された）データを、そのとき顧客に返すことのできるＨＴＭＬドキュメントに変換する。このようなフォーマット設定を行うことのできるいろいろな方法があり、フォーマット設定を必要としない可能性のある実施形態もいくつかある。好ましい実施形態においては、種々の「ＪＳＰ」（Ｊａｖａ(登録商標)  Ｓｅｒｖｅｒ  Ｐａｇｅ）が提供され、それらの各々がデータのある特定の種別をフォーマット設定するように構成される。ＪＳＰ技術は、「ウェブ」ページにおいて指定され、ページをリクエストした顧客にそのページを送る前に「ウェブ」ページを修正するために「ウェブ」サーバ上で実行される小さなプログラムの使用を通して、「ウェブ」ページのコンテンツや外観を制御するために使われる。マイクロソフトの「ＡＳＰ」（Ａｃｔｉｖｅ  Ｓｅｒｖｅｒ  Ｐａｇｅ）技術に基づいてページをフォーマット設定するなどの代案を使用することもできる。
【００２５】
ある特定の実施例においては、３つの別個のＪＳＰが提供されている。トップレベル取引ＪＳＰ１３６は、取引データサーブレット１３４を介して取り出した高次の取引データをフォーマット設定するために使われる。割当ＪＳＰ１３８は、ある所与の取引についての割当の詳細に関する取引データサーブレット１３４からのデータを処理するために使われる。最後に、標準決済指示ＪＳＰ１４２は、決済指示に関する決済指示データサーブレット１４０を介して取り出されたデータをフォーマット設定するために提供される。ＪＳＰモジュール１３６〜１４２の一般的な構造を示す図が図３に示されている。ＪＳＰ技術は、当業者にはよく知られており、具体的な実施例の詳細は、本明細書の記述から明らかとなるであろう。
【００２６】
上記で検討したように、システム１００のデータ取り出しコンポーネントは、「データリクエストハンドラ」１２２および「データソースマネージャ」１１２の２つの主要オブジェクトを中心としている。それらオブジェクトの各々については、今からより詳細に検討することになる。
【００２７】
「データリクエストハンドラ」１２２は、オープンなインターフェイスを提供して、顧客によって生成されたクエリなどのデータクエリに、直接もしくは中間のデータサーブレットを介して、または他のソースから応答するように構成される。ＷｅｂＳＴＰシステム１００にあるすべてのデータクエリは、「データリクエストハンドラ」１２２によって取り扱われるのが好ましく、このデータリクエストハンドラは、その入力としてデータのリクエストを表すＸＭＬドキュメントを受け入れ、その応答としてリクエストされたデータを表すＸＭＬドキュメントを提供する。データサーブレットなどの上流機能は、入力データが正しいフォーマットであることを確実なものにする任を受け持っている。
【００２８】
「データリクエストハンドラ」１２２は、入力ドキュメントを構文解析し、「データソースマネージャ」１１２によって引き続いて処理されるデータリクエストオブジェクトを作成するように構成される。「データソースマネージャ」は、１つまたは２つ以上データオブジェクトを「データリクエストハンドラ」１２２に返すことになり、このデータリクエストハンドラは、次いで、これらのオブジェクトを従来の手法を用いてＸＭＬベースのフォーマットに変換し、これらのオブジェクトをＸＭＬドキュメントの形態で依頼者に返す。
【００２９】
「データソースマネージャ」１１２は、（所定のリクエストオブジェクトの形態などで）一般機能のデータリクエストを「データリクエストハンドラ」１２２から受け取り、それをデータベースプール３０’の中の適切なデータソースに向けられる１つまたは２つ以上のデータ取り出しクエリに翻訳するように構成される。この好ましい実施例においては、図４に示したとおり、プール３０’にあるデータベースおよび場合によってはプール３０’の外のデータソースなどの各別個のデータソース２０４．１〜２０４．ｎが、対応する「データマネージャ」オブジェクト２００．１〜２００．ｎによって代表されている。各データマネージャオブジェクト２００．ｘは、好ましくは、標準のインターフェイスを介してアクセスすることができる。システム１００のこの好ましい実施例においては、Ｊａｖａ（登録商標）インターフェイスシンタックスが、「データマネージャ」オブジェクト２００．ｘに対して「データマネージャ」インターフェイス２０２．ｘを定義するために使われる。
【００３０】
インターフェイス２０２．ｘは、データソースマネージャ１１２によってアクセスされ、データソースを代表する各クラス（データマネージャオブジェクト）がサポートする必要のある一般的なデータ取り出し方法の標準セットを含む。結果的に、「データソースマネージャ」１１２は、ある意味で匿名的に種々の「データマネージャ」オブジェクトクラスを取り扱うことができ、データソースマネージャが交渉しているクラスの正確な詳細、またはそのクラスがどのようにそれぞれのデータソース２０４．ｘにアクセスしなければならないかを知る必要なく、適切なインターフェイス２０２．ｘの標準方法を呼び出すことによってこれらのクラスにアクセスすることができる。
【００３１】
データソースマネージャ１１２は、単一のデータソースで充足することのできるクエリを受け取るときは、データソースマネージャは、そのリクエストを発送する。クエリが２つ以上のソースからデータを取り出すことになる場合は、データソースマネージャ１１２は、データを得るためにデータマネージャオブジェクトのどのクラスを呼び出す必要があるかを判断しなければならない。これは、「データリクエストハンドラ」１２２から受け取るリクエストオブジェクトの性質に基づくファクトリデザインパターン２０６を用いることによって、そしてリクエストの処理に使われるだけでなく、そのリクエストのどの側面がどのクラスに向けられるべきかを処理するためにも使われる具体的な１つまたは２つ以上のクラスに特定種別のリクエストをマップする一組の所定のクエリマップ構造２０８を用いることによって行われる。あるいはまた、クエリマップは、動的にまたは周期に基づいて生成することもできる。データリクエストオブジェクトの適切なデータマネージャへのマッピングについてのある特定の実施例については、下記でより詳細に検討する。
【００３２】
マッピングが行われると、「データソースマネージャ」１１２は、例えば、ファクトリパターンを使うことによって、要求されたクラスのそれぞれのインスタンスを動的に作成する。次に、適切なデータ取り出し方法が、作成されたオブジェクトのそれぞれに対して実行される。好ましくは、性能を最適化するために、「データソースマネージャ」１１２は、オブジェクトのそれぞれについて新たな実行スレッドを作成し、データリクエストを同時並行的に各オブジェクトに発送する。その結果、全体としての取り出しのための時間は、返すのが最も遅いデータソースの時間と等しくなるであろう。
【００３３】
データ取り出しスレッドのそれぞれの完了を調整するために、同期化オブジェクト２５０を作成することができる（図５参照）。このオブジェクトは、現行の取り出しに関与するデータソースの総数を示す情報で初期化される。各データソースアクセスが完了すると、同期化オブジェクトは、通知を受け、データ取り出しの結果を渡される。同期化オブジェクトは、受け取ったデータを、例えば、つなぎ合わせることによって、組み合わせる。未決のデータマネージャオブジェクトの実行スレッドのすべてが完了すると、同期化オブジェクトは、主となるリクエストスレッドに、すべての作業が完了し、全体としての結果一式を返すことを通知する。「データソースマネージャ」１１２は、この通知を受けて、データオブジェクトの集合としてこの結果一式を「データリクエストハンドラ」１２２に返し、このデータリクエストハンドラは、次いで、このオブジェクトを代表するＸＭＬドキュメントを生成し、このＸＭＬオブジェクトは、そのままで、または適切なＨＴＭＬドキュメントにフォーマット設定して、その顧客に返すことができる。
【００３４】
上記で検討したとおり、リクエストの処理にあたって、データリクエストオブジェクトが分析されて、そのリクエストを満たすためにクエリが仕向けられなければならない適切なデータマネージャを判定する。「データソースマネージャ」１１２が、データリクエストを受け取るとき、そのリクエストが分析されて、データマネージャインターフェイスのどれがそのリクエストを扱うためにインスタンス化されるべきかを判定する。典型的な実施例においては、考えられるデータリクエストの世界は、閉じている。データを特定のデータマネージャに仕向けるために入ってくるデータリクエストを１つまたは２つ以上の具体的なリクエストにマップするために使うことのできる一組のデータベーステーブルが用意される。ある具体的な実施例においては、３つのデータテーブルが使われている。
【００３５】
第１のテーブルは、すべての定義済みのリクエストのリストを収容する「リクエストキー」テーブルである。各リクエストには、固有のＩＤを割り当てられ、一組の属性を有している。これらの属性は、「取引データの取得」または「決済指示の取得」などの一般的なリクエスト種別、およびそのリクエストが適用される可能性のある、株式、債券、または「為替オプション」などの製品種別が含まれる。ある場合においては、ある所与のリクエストおよび製品種別に対する情報が、例えば、金融サービス提供者のどの支店がこのある顧客にサービスを提供しているかに応じて異なるデータベースに格納されることがある。したがって、具体的なリクエストおよび製品種別に関するデータが格納されている可能性のある様々な「場所」を指定するために「実体」属性が用意されることもある。
【００３６】
受け取られたデータリクエストオブジェクトは、データリクエストオブジェクトの中の一般的なリクエスト情報から検索キーを抽出することによって処理され、これらの検索キーは、次いで、対応する属性を有する「リクエストキー」テーブルの中のレコードを特定するために使われる。一般的なリクエストについて、抽出されたキーは、ワイルドカードの値であってもよい。したがって、例えば、未決の米国株式取引の状況についての具体的なリクエストでは、単に１つの適合レコードのみという結果になる可能性がある一方で、すべての製品種別に関する取引データのリクエストのような、より一般的なリクエストからのキーを用いる検索では、「株式取引データの取得」、「債券取引データの取得」などの複数の適合エントリを返す可能性がある。
【００３７】
第２のテーブルは、「データマネージャクラス情報」テーブルである。これは、「リクエストキー」テーブルにおいて指定した固有の「リクエストキー」ＩＤを、そのリクエストを満たすために必要とされるデータへアクセスする「データマネージャ」に対するインターフェイスの名前にマップする機能を提供する。ひとつの実施例においては、これらのインターフェイスは、Ｊａｖａ（登録商標）クラスとして実装され、このテーブルは、「リクエストキー」ＩＤの値を適切な「データマネージャ」に対するインターフェイスを実現するＪａｖａ（登録商標）クラスと関連付ける。
【００３８】
第３のテーブルは、リクエストを取り扱う「データマネージャ」によって使われることになる追加情報を格納するために用意することができる。このような「データマネージャリクエスト構成」テーブルに格納される典型的な情報には、そのリクエストを取り扱うために「データマネージャ」によって使われるべきデータコネクションプールの名前を含むことができる。その他の情報には、特定のデータベースにアクセスするために必要とされるパスワードおよびＩＤ情報などのリクエストを取り扱うために「データマネージャ」によって必要とされるデフォルトの構成情報を含むことができる。
【００３９】
入来する「データリクエスト」を処理する際、「データソースマネージャ」は、先ず、この入ってくるリクエストからキーとなるリクエストの属性を抽出し、これらを検索基準として使い、「リクエストキー」テーブルにアクセスする。上記で検討したとおり、検索の結果は、（種々のデータソースへ向けられるサブクエリを生成するために最終的に使われることになる）１つまたは２つ以上の個々のデータリクエストとなるであろう。「データマネージャクラス情報」テーブルは、次に、特定されたエントリのこれらリクエストＩＤを用いてアクセスされ、各個別のデータリクエストを取り扱うことになるデータマネージャを特定する。そのリクエストを取り扱うためにデータマネージャによって必要とされる可能性のある追加の構成情報は、「データマネージャリクエスト構成」テーブルから取り出される。
【００４０】
次に、各離散的なデータリクエストについて、「データソースマネージャ」は、適切なデータマネージャインターフェイスをインスタンス化するか、呼び出すか、あるいはそうでなければ、アクセスし、それに離散的なデータリクエスト情報（例えば、関連する「リクエストキー」テーブルエントリの属性の一部または全部）を渡す。顧客ＩＤ、口座番号、日付範囲、取引ＩＤ、などの入来するリクエストの中にある具体的なリクエストのパラメータも渡される。さらに、個別の「データマネージャ」クラスがそれら自体の構成データを管理する必要がないように、「データマネージャリクエスト構成」テーブルから取り出された構成データを提供することができる。各「データマネージャ」は、依頼者によって提供された「一般的な」離散的なデータリクエストおよび具体的なリクエストパラメータを備える、受け取り情報を処理し、適切なデータクエリを生成するように構成される。この生成されたクエリは、次に、要求に応じてこの構成データを使って対応するデータソースに発行される。
【００４１】
この全体のプロセスフローを図５に要約する。図６は、データソースマネージャ１１２に関してこのフローをより詳細に図示している。図５および図６を参照すると、先ず顧客（または他の依頼者）が「データリクエストハンドラ」１２４にＸＭＬクエリを送る（ステップ１）。次に、「データリクエストハンドラ」１２４がクエリを構文解析し、その有効性を確認し、適切なクエリオブジェクトを作成し、「データソースマネージャ」１１２へ転送する（ステップ２）。「データソースマネージャ」１１２は、次に、このクエリオブジェクトを取り扱うためにどのデータソースが必要とされるかを、例えば、リクエスト種別のデータマネージャのマッピングを参照して、判定する（ステップ３）。「データソースマネージャ」は、「データマネージャ」インターフェイス２０２．ｘを介して、適切な「データ」マネージャオブジェクト２００．ｘにリクエストを（好ましくは非同期的に）発送する（ステップ４）。これは、データマネージャの各要求される種別の１つをインスタンス化し、データを取り出すための関数を呼び出す新たなプログラムスレッドを作成することによって果たすことができる。
【００４２】
呼び出されたデータマネージャオブジェクト２００．ｘは、適切なデータベースに接続し、データベースからデータを取り出し（ステップ５）、そして完了すると同期化オブジェクト２５０に通知する（ステップ６）。同期化オブジェクト２５０はそれら結果を組み合わせ、データマネージャオブジェクトのリクエストが完了した時に「データソースマネージャ」１１２に通知する（ステップ７）。「データソースマネージャ」は、データオブジェクトを「データリクエストハンドラ」１２４に返し（ステップ８）、データリクエストハンドラは、次に、データオブジェクトをＸＭＬに翻訳し、ＸＭＬオブジェクトを「依頼者」に返す（ステップ９）。
【００４３】
同じ一般的なプロセスフローを使って、システムに対して為される多種多様のデータリクエスト種別を取り扱うことができる。データマネージャ１１２は、要求されるデータアクセスの各種別の細目にアドレスする必要がなく、しかしその代わり、共通のデータマネージャインターフェイス２０２．ｘを使って、データマネージャオブジェクト２００．ｘにアクセスするので、データアクセスモジュール１１０をアップグレードして、異なるデータ種別およびデータリクエストの種別を管理することが容易である利点を有する。新たな種別のリクエストは、そのリクエスト種別を、例えば、「ファクトリ」デザインパターンテーブル２０６によって定義される、データソースマッピングテーブルに付け加えることによって実現することができる。新規のデータソースへのアクセスは、このデータソースにアクセスするための適切なデータマネージャオブジェクトを作成し、クエリマッピングデータ２０８を更新して、このオブジェクトを必要に応じて参照することによって追加することができる。
【００４４】
図７〜１０は、システム１００のある特定の実施例において生成され、顧客の視点から見たシステムの動作を説明するために使われることになるサンプルのＨＴＭＬページである。図７を参照すると、ある所与の限定の範囲内に入るすべての取引をリストアップしているある特定の会社の取引情報画面が示されている。顧客は、画面上のフォーム３００からこれらの限定を選択することができる。好ましくは、デフォルトの一連の限定が提供される。ひとつの実施形態においては、取引情報が表として表示され、その表では、各取引が単一の行で取引の固有の識別子３０４および該当する取引データの要約３０６を含んでいる。実施例の洗練度合いに応じて、顧客が要約の内容および要約データが提示される順番を定めることができるようにすることもできる。さらに、各取引に関連する状況のアイコン３０２を表示し、使用して、例えばその色によって、その所与の取引についての処理の段階および顧客によって更なるアクションが必要とされるかどうかを表すことができる。
【００４５】
実際には、顧客がシステム１００にアクセスする場合（適切なログオンおよび検証手続きが完了した後）、コントローラサーブレット１３２は、例えば取引の要約について、顧客のリクエストを取引データサーブレット１３４に渡し、この取引データサーブレットは、顧客によって為された選択および場合によってはこの顧客が追跡している種々の口座を示している顧客プロファイルから取り出されたデータなどのその他のデータに基づいてクエリを生成する。４つの口座をもつ顧客についてサーブレット１３４により生成されたサンプルクエリは、次のようになることがある。
【００４６】
【数１】
2004530977.tif 000002
【００４７】
データリクエストハンドラ１２２および「データソースマネージャ」１１２は、このリクエストを処理し、この所与のデータ範囲内で特定された口座についての様々なデータソースから取り出されたデータが入っているＸＭＬドキュメントを返し、このデータは次いで、例えばトップレベル取引ＪＳＰ１３６によって、ＨＴＭＬドキュメントの中に配置され、顧客に返される。
【００４８】
提供されたページには、さらなる詳細を得るために顧客によって選択することのできるアクティブ領域を持たせることができる。例えば、顧客は、固有の取引ＩＤを（例えば、マウスを使用して）選択し、図８に示すように、その取引について様々な割当の詳細３１０を得ることができる。顧客がそのような選択をする場合、コントローラサーブレット１３２は、この選択をさらなるデータのクエリと解釈し、上記のようにそのクエリを処理する。（実施例に応じて、種々のレベルの詳細なデータをシステムによって先取りし、データキャッシュ１２４またはその他の記憶装置に保持して、このデータを顧客に返すことを簡単化することができる。）同様に、割当一覧３１０（図８）は、固有の割当ＩＤ３１２のような、さらなるアクティブ領域を収容することができ、それは、選択されると、図９に示すような、またはその他の情報など、選択された割当を完全なものにするために必要とされる具体的な確認に関する詳細の取り出しおよび表示をトリガーすることができる。
【００４９】
さらに、種々のページが、相異なる種別またはクラスのデータ取り出しリクエストへのリンク３０８を収容することができる。例えば、継続中の決済指示を得る（場合によっては、変更する）ためのリンクを備えることができる。このリンクがリクエストされるときに、コントローラサーブレット１３２は、この選択をクエリとして処理し、このクエリは、標準決済指示データサーブレット１４０に仕向けられ、上述のように処理される。返されたデータは、次に、図１０に示した表３３０のように、適したフォーマットで表示することができる。
【００５０】
本発明をその好ましい実施形態という点から上記に説明してきた。しかし、これらの方法およびシステムは、例として考えられるべきであり、本発明の精神および範囲から逸脱することなくシステムの形態および範囲において種々の変更を為すことができる。用語「顧客」は、本明細書においてクエリの発行に関して使われているが、この用語は、単に便宜上および説明の簡略化のために使われており、金融サービス提供者の顧客である関係者からのみのクエリを満たすことに本発明を限定するものと考えられるべきではないことに留意されたい。むしろ、本発明は、金融サービスプロバイダのクライアントや、このサービスプロバイダの従業員などのこのサービスプロバイダのために活動している関係者を含めて、いかなる人物、実在者、またはその他のユーザからのクエリを満たすのに使用するのに適しているが、これらに限定されない。
【図面の簡単な説明】
【００５１】
【図１】本発明によるシステムを組み込んでいる取引環境の高次のブロック図である。
【図２】本発明のシステムの機能図である。
【図３】図２のＪＳＰモジュールの一般的な構造の図である。
【図４】データソースマネージャの環境の図である。
【図５】データ取り出しプロセス全体を示す流れ図である。
【図６】データソースマネージャのデータ取り出しプロセスを示す流れ図である。
【図７】顧客の視点から見た本発明のシステムのある特定の実施形態の動作を説明する一例のＨＴＭＬ画面の図である。
【図８】顧客の視点から見た本発明のシステムのある特定の実施形態の動作を説明する一例のＨＴＭＬ画面の図である。
【図９】顧客の視点から見た本発明のシステムのある特定の実施形態の動作を説明する一例のＨＴＭＬ画面の図である。
【図１０】顧客の視点から見た本発明のシステムのある特定の実施形態の動作を説明する一例のＨＴＭＬ画面の図である。
【図１】
2004530977.tif 000003
【図２】
2004530977.tif 000004
【図３】
2004530977.tif 000005
【図４】
2004530977.tif 000006
【図５】
2004530977.tif 000007
【図６】
2004530977.tif 000008
【図７】
2004530977.tif 000009
【図８】
2004530977.tif 000010
【図９】
2004530977.tif 000011
【図１０】
2004530977.tif 000012
【国際公開パンフレット】
2004530977.tif 000013
2004530977.tif 000014
2004530977.tif 000015
2004530977.tif 000016
2004530977.tif 000017
2004530977.tif 000018
2004530977.tif 000019
2004530977.tif 000020
2004530977.tif 000021
2004530977.tif 000022
2004530977.tif 000023
2004530977.tif 000024
2004530977.tif 000025
2004530977.tif 000026
2004530977.tif 000027
2004530977.tif 000028
2004530977.tif 000029
2004530977.tif 000030
2004530977.tif 000031
2004530977.tif 000032
2004530977.tif 000033
2004530977.tif 000034
2004530977.tif 000035
2004530977.tif 000036
2004530977.tif 000037
2004530977.tif 000038
2004530977.tif 000039
2004530977.tif 000040
2004530977.tif 000041
2004530977.tif 000042
2004530977.tif 000043
2004530977.tif 000044
2004530977.tif 000045
2004530977.tif 000046
2004530977.tif 000047
2004530977.tif 000048
2004530977.tif 000049
2004530977.tif 000050
【国際調査報告】
2004530977.tif 000051
2004530977.tif 000052