"受信したメッセージについて、当該メッセージに関連する業務に応じた所定の処理を施し転送するメッセージ処理装置において、予め、業務手順が同一とみなせるまで各業務パターンに細分化した機能項目を、記憶しておく手段と、記憶された前記各機能項目とこれを指示するメッセージの論理的構造およびメッセージの各部の取るべき値のパターンとの対応を付けて記憶する手段と、前記機能項目に対応するメッセージの論理的構造およびメッセージの各部の取るべき値のパターンである入力定義をを記憶しておく手段と、前記機能項目毎に業務として行うべき処理手順をルール化した個別ルールを記憶しておく手段と、前記メッセージを受信する手段と、受信されたメッセージに対応する業務としてなすべき機能項目群についての前記個別ルールを選択し、選択された個別ルールに従って業務処理を制御する手段とを有することを特徴とするメッセージ処理装置。請求項1に記載のメッセージ処理装置において、前記業務処理が変化した場合、前記個別ルールの選択を変更することのより前記変化に対応する手段をさらに有することを特徴とするメッセージ処理装置。請求項1または2のいずれかに記載のメッセージ処理装置において、前記個別ルールは,業務処理を制御する業務ロジックと次段に送信するメッセージを作成するためにメッセージ変換規則からなることを特徴とするメッセージ処理装置。請求項1乃至3のいずれかに記載のメッセージ処理装置において、前記処理パターン毎にメッセージの構造および前記メッセージの各部の値の範囲を入力定義として記憶する手段と、複数の前記処理パターンに対応する前記入力定義を統合して得られたメッセージ仕様をもちいて,前記メッセージの妥当性を検証する手段とをさらに有することを特徴とするメッセージ処理装置。請求項4に記載のメッセージ処理装置において、前記業務処理が変化した場合においては,前記入力定義の選択を変えて,再統合することのより,メッセージの妥当性の検証を行うためのメッセージ仕様を更新する手段をさらに有することを特徴と刷るメッセージ処理装置。また、CA業務としてなすべき機能項目群の入力定義を統合することによりメッセージサブ仕様を作成することも本発明の一態様である。また、CA業務としてなすべき機能項目が変わって場合には,前記ルールを該当する機能項目のものに入れ替え,また,入力定義も該当する機能項目のもので統合し直すことによりメッセージサブ仕様を作成することも本発明の一態様である。国を跨るコーポレートアクションは通常,CSD,ローカルカストディ,グローバルカストディ等が連携して発行者と運用者に対してコーポレートアクション支援サービスを提供している。STP化されたコーポレートアクションにおいては,社会状況の変化等により連携者間で役割分担が変化した場合や新たな国の発行会社や運用者へサービスを開始する場合など,比較的頻繁にローカルカストディやグローバルカストディでの業務内容とメッセージサブ仕様が変更になり,システムやメッセージサブ仕様の保守作業が必要となる。特にメッセージサブ仕様の保守作業には,標準メッセージ仕様に関する専門的な知識が必要であり,継続的に専門家を確保しておくことが難しい。また,処理モジュールにおいても,市場慣行の違いにより,処理に様々なバリエーションが存在するために,市場慣行ついてのある程度の専門的知識が必要となる。前記特許文献1においては,コーポレートアクションの1つである配当処理について,様々なバリーションに対応できるように,簡単に機能を拡張できる特徴があるが,メッセージ仕様については言及されていない。上記の課題を解決するために、本発明では、CA業務において、業務パターンを予め定めた粒度である機能項目に細分化し、これらそれぞれについて個別ルールを設定し、CA業務を受付けた場合、当該CA業務の機能項目を特定し、これに対応する個別ルールに従って処理を実行するものである。このように細分化された機能項目は、処理手順の変化を抑制できるものである。より詳細には、カストディにおけるCA業務処理において下記手順で処理を実行する。予め、業務手順が同一とみなせるまで業務パターンに細分化し,業務パターンの1つ1つを機能項目として定義し、記憶しておく。そして、個々の機能項目とこれを指示するメッセージの論理的構造およびメッセージの各部の取るべき値のパターンとの対応を付け記憶しておく。また、機能項目に対応するメッセージの論理的構造およびメッセージの各部の取るべき値のパターンを定義し記憶しておく。なお、これを入力定義と呼ぶ。また、機能項目毎に業務として行うべき処理手順をルール化して定義し記憶しておく。なお、これを個別ルールと呼ぶ。そして、これら定義されたものを利用して、CA業務としてなすべき機能項目群についての前記個別ルールを選択することにより業務処理を制御する。また、CA業務としてなすべき機能項目群の入力定義を統合することによりメッセージサブ仕様を作成することも本発明の一態様である。また、CA業務としてなすべき機能項目が変わって場合には,前記ルールを該当する機能項目のものに入れ替え,また,入力定義も該当する機能項目のもので統合し直すことによりメッセージサブ仕様を作成することも本発明の一態様である。カストディ間の役割分担が変わる,あるいは新たな国の発行会社や運用者へサービスを開始する場合など,コーポレートアクション業務として受付けるべき機能項目が変化した場合には,機能項目に対応する個別ルールおよび入力定義に入れ替えることにより,業務に対応できる他,入力定義を再統合してメッセージサブ仕様を作成することができる。このため,メッセージ仕様に対する深い知識が必要なメッセージサブ仕様の保守を自動化できる。また機能項目を選択するだけなので,市場慣行に関する知識も殆ど必要とせずに保守が可能となる。本発明の一実施形態を説明する前にコーポレートアクションに関するメッセージの標準化について簡単に説明する。前記のメッセージの標準仕様として,メッセージのフィールド毎に文字数や記載内容が規定されたSWIFTMTメッセージ標準仕様やメッセージとしてXML形式を採用したSWIFTMXメッセージ標準仕様がある。MXメッセージ標準仕様においては,メッセージのデータ形式としてXML形式を採用しているために,必要となるデータ項目のみに限定して送信することが容易であり,メッセージの内容を階層的に表現可能なこと,また,スキーマ定義を用いることによりメッセージの論理的構造やデータ形式や値が妥当であるかのバリデーションが容易である特徴がある。なお,SWIFTMTメッセージ標準仕様ついては,例えば,SWIFT2010年刊,StandardMTNovember2010GeneralInformationSWIFTMXメッセージ標準仕様については,SWIFT2008年刊,SWIFTStandardsMXGeneralInformationを参照されたい。SWIFTMTおよびSWIFTMXメッセージ標準仕様では金融関係の業務,本発明の対象であるコーポレートアクションを取り扱う証券のイベントの他,証券取引,証券決済,資金の清算と決済,外為取引などに特化した業務特定メッセージ標準仕様が策定されている。前記のように国の市場慣行が異なるために,これらのメッセージ標準仕様はこれらを全て包含した非常に広範囲な仕様となっている。このため,SWIFTの関連機関であるSecuritiesMarketPracticeGroupが国ごとの市場慣行によるメッセージの仕様の定義を推進している。この他,先に述べたように,連携者間でメッセージサブ仕様,すなわち,標準メッセージ仕様のサブセットを取り決めてこれを用いてメッセージ授受を行っている。以上のメッセージの標準化動向についての説明を基に、以下本発明の一実施形態を説明する。図3に、コーポレートアクション業務と同業務において選択的な項目の例3を示す。前記業務例としては配当処理,権利行使,通知一般があり,配当処理の選択的な項目として,現金配当,株式配当,現物配当などの配当方法,円,ドル,ユーロなどの現金配当通貨,現金化あるいは分散保有かの株式配当における端株の取扱,円,ドル,ユーロなどの端株現金化通貨がある。このように配当処理などのCA業務においては,様々な選択的項目があり,これらの組み合わせを考えると,業務にバリエーションが多いことを理解されたい。図4に、配当処理に関する機能階層および機能項目4を示す。図4は配当処理を選択的な項目に基づいて階層的に表現したもので,401から411までが機能項目である。機能項目1401は,配当処理で,配当方法が現金配当,配当通貨が円である場合であり,機能項目2402および機能項目3403は,配当通貨がそれぞれドルあるいはユーロである以外は機能項目1401と同じである。機能項目4404は,配当処理で,配当方法が株式配当,端株の取扱が端株現金化で,現金化する通貨が円である。機能項目5405および機能項目6406は,現金化する通貨がそれぞれドルあるいはユーロである以外は,機能項目4404と同じである。機能項目7407は配当処理で,配当方法が株式配当で,端株の取扱が端株分散所有である。機能項目8408は,配当処理で,配当方法が現物配当,円に現金化する場合である。機能項目9409および機能項目10410は,現金化する通貨が,それぞれドルあるいはユーロである以外,機能項目8408と同じである。機能項目11411は,配当処理で,配当方法が現物である場合である。ここで,機能項目が同一である場合には同一の手順で処理が可能となること,該当するメッセージについてもメッセージの論理的構成および機能を規定する部分の値は同一となる。また,機能階層における選択的項目の順位について見方により変り,上記以外も考えられるが,得られる機能項目は同一となる。次に、図1の本実施形態のシステム構成を用いて,本実施形態の動作手順の概要について説明する。発行会社901から機能項目5,すなわち,配当方法が株式配当,端株の取扱が端株現金化,通貨がドルである配当処理を実施したいが,運用者905側では,機能項目1,円による現金配当しか受け付けず,ローカルカストディ903において円による現金配当,機能項目1に変換してグローバルカストディ904に伝達する場合を想定する。まず,ローカルカストディ903のCA業務システム1の構成について説明する。CA業務システム1は主にシステムの制御をおこなう制御部110と実際の処理を実行する実行部からなる。制御部110は,メッセージの検証等を行うメッセージ検証部111,メッセージサブ仕様の維持を行うメッセージサブ仕様制御部114,ルールによって機能項目毎のCA業務処理を制御する個別ルール112,機能項目毎のメッセージ仕様である入力定義113からなる。なお、これら各部は、プログラムに従って処理を行うCPUの如き演算装置で実現される。実行部120は個別ルール112の指示に基づいて業務処理を実行する業務ロジック実行部122,送信先へのメッセージを組み立てるメッセージ変換実行部121からなる。次に、機能項目5のメッセージが処理される動作手順の概要を示す。発行会社901のCA業務システム81から送信され,CSD902のCA業務システム82を経由してきた機能項目5の株式配当通知メッセージ21がローカルカストディ903のCA業務システム1に受信される。メッセージ検証部111において,メッセージサブ仕様制御部114内のメッセージサブ仕様図示せずを参照して受信メッセージ21がメッセージサブ仕様通りか検証し,検証されたメッセージに該当する機能項目を判定して,該当する機能項目についてのルールである個別ルール112を選択し,選択された個別ルール112が,CA業務処理を実行する実行部120を制御する。業務ロジック122が配当された株式を証券会社にて現金化し,現金化して得られたドルを為替銀行16で円に両替する。一方,メッセージ変換実行部では,機能項目1のメッセージ22を組み立てグローバルカストディ904に送信する。送信されたメッセージ22はグローバルカストディ904から運用者905へ送られることになる。図5のカストディにおけるCA業務システム詳細構成を用いて本実施形態の各部の詳細および動作手順の詳細を説明する。まず、メッセージ検証部111は受信したメッセージの検証を実行するメッセージ検証部本体1111受信メッセージに該当する機能項目を判定する機能項目判定ロジック1112,機能項目から該当する個別ルールを検索する機能項目―個別ルール変換部1113から構成される。個別ルール112は,業務ロジック実行部122を制御する業務ロジック部1121,メッセージ変換実行部121を制御するメッセージ変換部1122からなる。個別ルール112に付随する形で,機能項目単位でのXMLスキーマと拡張規則からなる該当機能項目の入力定義113が記憶される。メッセージサブ仕様制御部114は,XMLスキーマと拡張規則からメッセージサブ仕様1141,入力定義113からメッセージサブ仕様を作成するメッセージサブ仕様編成部1142,メッセージ標準仕様のフルセットのXMLスキーマと拡張規則からなる標準メッセージ仕様1143からなる。図6に、機能項目5に対応するメッセージ構成21を示す。メッセージはXML形式で,ルート211から木構造で構成される。ルート211の直下としては,部分木メッセージID2111にはメッセージを識別する情報を含む。部分木CA一般情報2112にメセージに関する一般的な情報を含み,メッセージの目的とする業務の情報である配当通知を含む。部分木アカウント情報2113にはアカウント情報,例えばCSDにおけるローカルカストディのアカウント情報を含む。部分木CA移動詳細2114には配当処理において株式や現金の移動に関する情報を含む。部分木CA移動詳細2114の下位としては,要素配当種別2115は配当方法を示す配当種別情報を含み,機能項目5の場合は株式配当となる。部分木端株取扱2116は端株の取扱を示し,現金化から分散所有の何れかを選択する,機能項目5では現金化となる。部分木証券移動2117には,株式配当における配当株式の権利者への移動に関する情報を含む。部分木現金移動2118には,端株を現金化することよって発生した現金を権利者に移動することに関する情報を含む。部分木AmDetls2119は現金化した金額に関する情報を含む。要素EntitildAmtに確定金額の情報を含み,その属性として通貨を含む。ここでは日本円が指定されている。以上の詳細なシステム構成および機能項目5のメッセージの説明を基に,詳細な動作手順を説明する。ローカルカストディ903のCA業務システム1において受信された機能項目5のメッセージ21はメッセージ検証部111のメッセージ検証部本体1111において,メッセージサブ仕様のXMLスキーマによって妥当性の検証が行われる。拡張規則管理テーブル7において拡張規則が定義されている場合には,拡張規則での検証を行う。この詳細についてはメッセージサブ仕様の作成手順の説明の中で述べる。機能項目判定部1112は、図16の機能項目判定テーブル11121によってメッセージの機能項目を判定する。機能項目判定テーブル11121は,機能項目111211XMLパス111212,値111213の3つの欄から構成されており,機能項目を規定するXMLパスとその要素の値が記憶されている。メッセージが機能項目1であるかの判定は,機能項目判定テーブル11121において機能項目が機能項目1となっている各行のXMLパスの値が機能項目判定テーブル11121に記憶されている値と一致した場合に,機能項目1と判定する。すなわち,機能項目1であるかの判定は次のように行う。行111214の規定,すなわち,メッセージのXMLパスがCA一般情報/イベントタイプ/での値が配当通知であることを確認する。行111215の規定,すなわち,メッセージのXMLパスがCA一般情報/オプションタイプ/での値が現金配当であることを確認する。行111216の規定,すなわち,メッセージのXMLパスがCA移動詳細/現金移動/AmtDtls/EntitldAmt/Ccyでの値がJPYであることを確認。以上のように機能項目1の行のそれぞれを確認できた時に機能項目1と判定する。機能項目―個別ルール変換部1113において,機能項目に対応する個別ルール112を検索する。個別ルール112内の業務ロジック部1121記述された配当株式現金指令およ通貨の両替指令を参照して,実行部120の業務ロジック実行部122に指令を出すことにより,配当株式の現金化および通貨の両替を実行する。メッセージ変換部1122に記述された配当種別を株式配当から現金配当に切り替えること,通貨をUSDからJPYに切り替えること,不要な部分木や要素,部分木端株取扱2116や部分木証券移動2117を削除することをメッセージ変換実行部に指示して,図7に示した機能項目1に対応するメッセージ22を構成する。すなわち,部分木CA移動詳細2214においては,機能項目5において存在していた,部分木端株取扱2216および部分木証券移動2217は削除される。部分木現金移動2218においては,株式を現金化して現金配当としての配当額に関する情報を設定する。また,部分木AmtDetls2219には配当金額についての情報を設定する。さらに,要素EntileAmt2220には現金配当額を設定し,通貨の属性CcyにJPYを設定する。この他,ルールには記述されていなくとも行う処理として,部分木メッセージID2211にメッセージ識別子を入れる。部分木CA一般情報2212に配当通知,部分木アカウント情報2212には,ローカルカストディ903における送信先のグローバルカストディ904のアカウントについての情報を設定する。以下に、メッセージサブ仕様の編成について説明する。本実施形態のメッセージサブ仕様の作成方法の特徴を明らかにするために,まず,従来のメッセージサブ仕様の作成について簡単に説明する。図8にメッセージサブ仕様の例および従来の作成手順を示す。メッセージサブ仕様50は,メッセージの論理的な構造を示すXMLスキーマと拡張規則からなる。XMLスキーマはルート要素の型定義501とその下位の要素の型定義5001~5010,図には示されていないが,これらのさらに下位の型定義からなる。拡張規則としてはCcy属性値5014があり,通貨の属性値として取り得る値,USDとJPYを記憶する。型定義5011~5013は標準メッセージ仕様において規定されているが,メッセージサブ仕様では削除されているものである。型定義は下位の要素の名前および型定義,場合によっては属性の定義を含む。下位の要素をもたない場合は,要素の名前およびデータ型,場合によっては属性の定義を含む。これらの他にデータ型の定義を含む。なお,型定義などXMLスキーマの詳細については,WWWコンソーシアムXMLスキーマについてのホームページhttp://wwww3org/XML/Schemaを参照されたい。以上のメッセージサブ仕様の構成についての説明に基づいて,その作成手順を述べる。配当方法に関する機能階層および機能項目4から必要となるメッセージを構成する要素とその値を抜き出して,XMLスキーマと要素の値あるいは属性の値として規定すべき内容を拡張規則として定義する。例えば,機能項目1および機能項目5のでは,配当処理で型定義CA一般情報5002の下位の型を含めて配当通知のみの値とする。同様に型定義配当種別においては,現金配当と株式配当のみの値とする。配当に関する通貨は,EntildAmt要素の属性がUDSとJPYのみであることを,拡張規則5014に登録する。型定義端株取扱5006では現金化のみの値とする。このようにメッセージサブ仕様を作成するためにはメッセージの各要素や属性の意味を十分に理解している必要がある。次に、本実施形態におけるメッセージサブ仕様の作成手順を説明する。機能項目毎の入力定義,すなわち対象の機能項目のみを伝えるために必要な最小限のXMLスキーマと拡張規則を個別ルールと対応付けて作成して置く。ローカルカストディとして取り扱う各機能項目分の入力定義を統合する,すなわち,1つの機能項目の入力定義に,残りの機能項目の入力定義を順次追加して行くことによりメッセージサブ仕様を作成する。図9から図11を用いて、メッセージサブ仕様の作成手順の概要を説明する。図9に、追加する入力定義51を示す。これは機能項目5の入力定義である。図10に追加先の入力定義,この場合は機能項目1の入力定義を示す。図11にこれらが統合された結果を示す。図9の追加処理対象外型定義512は,追加先にも同一の型定義が存在するので,追加が不要なものである。追加対象型定義514は追加処理が必要な型定義および拡張規則である。例えば追加する型定義配当種別5142の値株式配当と追加先の型定義配当種別5242の値現金配当を統合すると,追加結果の型定義配当種別5342の値は株式配当あるいは現金配当となる。型定義端株取扱5143は追加先に存在しないので,この型定義を追加先の型定義CA移動詳細5241に登録する。同じく,型定義証券移動5144は追加先に存在しないので,下位の型定義を含めて追加する。型定義EntildAmt5347の属性である通貨については,拡張規則Ccy属性値5148としUSDのみが規定されている。これに対して追加先拡張規則Ccy属性値5245のではJPYが規定されており,これらを統合すると,拡張規則Ccy属性値5348はUSDあるいはJPYとなる。この様な要領処理で入力定義の統合処理を実現する。次に,型定義同士の統合処理については説明する。図12に型定義の統合処理,すなわち,ある型定義をそれに該当する型定義へ追加する処理の概要を示す。今,機能項目5に対応する追加元の型定義である型定義CA移動詳細5141を追加先である機能項目1の型定義CA移動詳細5241に追加することを考える。双方の型定義内の要素定義を比較して追加すべき要素定義を探して追加する。すなわち,追加元にあって追加先にないもの,すなわち,要素定義端株取扱51411と要素定義証券移動51411を追加先に追加する。この際,XMLスキーマとしてSequenceが指定されているので,標準メッセージ仕様を参照して要素定義の並ぶ追加位置を判定して,要素の並ぶ順番が標準メッセージ仕様と同じになるようにする。追加結果は型定義CA移動詳細5341に,要素定義配当種別53411,要素定義端株取扱53412および要素定義証券移動53413の順で並べる。一方,列挙型の統合処理を図12に下の部分に示す。追加元の列挙型定義配当種別5241を追加先の列挙型定義配当種別5242に統合する。追加元には株式配当51411,追加先には現金配当52411が規定されており,追加結果では,現金配当53411と株式配当53412との両方が規定されることになる。なお,図12では,図面や説明を簡略にするために,XMLスキーマの表記を正式なものでなく,簡略化した表記を用いている。以下,入力定義の統合処理についての概要説明を基に,入力定義の統合処理の手順の詳細を図13~図15を用いて説明する。図13に、入力定義の統合処理の処理フロー6を示す。図14要素定義の処理フロー605を示す。図15に拡張規則管理テーブル7を示す。まず,拡張規則管理テーブルについて説明する。拡張規則管理テーブル7には拡張規則が定義されるXMLの要素の値や属性を指定するXMLパス71,拡張規則の対象の種別,ここでは属性の値および要素の値の区別,値7には,該属性や要素の値として許容される値を記憶する。例えば,XMLパスCA移動詳細/現金移動/AmtDtls/EntitldAmt/Ccy711の例では,Ccyは要素EntitldAmtの属性で,その値としてUSD,JPYが許容されることを示している。同様に,XMLパスCA移動詳細/現金移動/712AmtDtls/CshInLieuOfShr/Ccy712では,Ccyは要素CshInLieuOfShrの属性で,その値としてUSD,JPYが許容されることを示している。次に、入力定義の統合処理フロー6を用いて,統合処理手順を説明する。ステップ601においては,入力定義のXMLスキーマについて,追加側および被追加側のルートすなわち,Documentの直下の型定義を検索する。ステップ602においては,型定義がXML文書として下位ノードをもつ複合型の型定義かを判定する。複合型の場合,ステップ603ヘ進み,下位ノードを持たない単純型の場合にはステップ612にジャンプする。ステップ603においては,追加側と被追加側の型定義の要素定義を比較する。ステップ604においては,追加側の要素定義の全てが被追加側に存在するかを判定する。存在しない場合にはステップ605ヘ進み,存在した場合にはステップ606にジャンプする。ステップ605においては,要素定義の追加処理を行う。処理の詳細は図14を用いて説明する。ステップ606においては,該型定義に拡張規則が定義されていないか,該型定義のXMLパスをキーにして拡張規則管理テーブル7を検索する。ステップ607においては,検索結果を判定する。拡張規則が定義されている場合にはステップ608に進み,定義されていない場合には,ステップ609にジャンプする。ステップ608では,拡張規則の追加処理が行われる。例えば,XMLパスCA移動詳細/現金移動/AmtDtls/EntitldAmtの属性Ccyの通貨が追加側が{USD}で,被追加側が{JPY}の場合には,値の欄731にあるように{USD,JPY}とする。なお,拡張規則によるメッセージ検証の場合には,該当する属性や要素の値が,拡張規則管理テーブル7の値73の欄の値となっているかを判定すれは良い。ステップ609においては,追加側の型定義について各ツリーを辿ったから判定する。未完の場合にはステップ610に進み,完了の場合にはステップ611にジャンプして処理終了となる。ステップ610では,ツリーを辿って次の追加側の型定義を得る。同時に被追加側の該当型定義を得る。なお,ステップ609の処理も含めて,木構造の全ノード辿るアルゴリズムで一般的によく知られているものであり,詳細な説明は省略する。ステップ612からステップ614は,ステップ606からステップ608と同様であり,詳細な説明は省略する。ステップ615において,型定義に含まれる要素が列挙型であるかを判定する。具体的には,要素の型定義がEnumeration型かを判定する。ステップ616において,先に述べたようにして追加処理を行う。次に、要素定義の追加処理を図14を、用いて説明する。ステップ6051においては,追加側の該型定義から追加する要素定義を取り出す。ステップ6052においては,該要素はsequence指定されているかを判定する。sequenceの場合はステップ6053へ進む。choiceなどその他の場合にはステップ6058へジャンプする。ステップ6053においては,標準メッセージ仕様の該型定義を検索する。これは該型定義のパスに該当する型定義を検索すれば良い。ステップ6054においては,該要素定義の追加位置を求める。すなわち,標準メッセージ仕様における要素定義の順番を守る位置を求めれば良い。ステップ6055においては,得られた位置に該要素定義を埋め込めば良い。ステップ6058においては,要素定義の順番は問題にならないので,デフォルトの追加位置,例えば被追加型定義の最後に該要素定義を追加すれば良い。ステップ6056においては,追加型定義内の要素定義で追加すべきものが残っているかを判定する。未完の場合いは,ステップ6057に進む。完了した場合には,ステップ6059ヘリンクして処理を終了する。ステップ6057においては,該型定義で追加すべき要素定義で残っているものを取り出す。"