(57)【要約】      （修正有）【課題】証券分野における国（あるいは地域）をまたがるコーポレートアクションの自動化に関するメッセージ処理技術を提供する。【解決手段】受信したメッセージに応じて業務処理を行う場合に，業務処理の処理パターンを処理手順に変化が発生しないレベルの細かさにパターン分けし機能項目として定義し，機能項目毎に処理手順を個別ルールとしてルール化して定義しておく，機能項目毎に該当メッセージの論的構造およびメッセージ各部の値の範囲を入力定義として定義しておく，CA業務として為すべき機能項目の個別ルールおよび該当入力定義を選択し，選択された入力定義を統合することによりメッセージサブ仕様を作成し，選択された個別ルールと作成されたメッセージサブ仕様によってCA業務システム１を制御して業務処理を実行する。【選択図】図１
2013041384.tif 000002
【特許請求の範囲】
【請求項１】
受信したメッセージについて、当該メッセージに関連する業務に応じた所定の処理を施し転送するメッセージ処理装置において、
予め、業務手順が同一とみなせるまで各業務パターンに細分化した機能項目を、記憶しておく手段と、
記憶された前記各機能項目とこれを指示するメッセージの論理的構造およびメッセージの各部の取るべき値のパターンとの対応を付けて記憶する手段と、
前記機能項目に対応するメッセージの論理的構造およびメッセージの各部の取るべき値のパターンである入力定義をを記憶しておく手段と、
前記機能項目毎に業務として行うべき処理手順をルール化した個別ルールを記憶しておく手段と、
前記メッセージを受信する手段と、
受信されたメッセージに対応する業務としてなすべき機能項目群についての前記個別ルールを選択し、選択された個別ルールに従って業務処理を制御する手段とを有することを特徴とするメッセージ処理装置。
【請求項２】
請求項１に記載のメッセージ処理装置において、
前記業務処理が変化した場合、前記個別ルールの選択を変更することのより前記変化に対応する手段をさらに有することを特徴とするメッセージ処理装置。
【請求項３】
請求項１または２のいずれかに記載のメッセージ処理装置において、
前記個別ルールは，業務処理を制御する業務ロジックと次段に送信するメッセージを作成するためにメッセージ変換規則からなることを特徴とするメッセージ処理装置。
【請求項４】
請求項１乃至３のいずれかに記載のメッセージ処理装置において、
前記処理パターン毎にメッセージの構造および前記メッセージの各部の値の範囲を入力定義として記憶する手段と、
複数の前記処理パターンに対応する前記入力定義を統合して得られたメッセージ仕様をもちいて，前記メッセージの妥当性を検証する手段とをさらに有することを特徴とするメッセージ処理装置。
【請求項５】
請求項４に記載のメッセージ処理装置において、
前記業務処理が変化した場合においては，前記入力定義の選択を変えて，再統合することのより，メッセージの妥当性の検証を行うためのメッセージ仕様を更新する手段をさらに有することを特徴と刷るメッセージ処理装置。
また、CA業務としてなすべき機能項目群の入力定義を統合することによりメッセージサブ仕様を作成することも本発明の一態様である。
また、CA業務としてなすべき機能項目が変わって場合には，前記ルールを該当する機能項目のものに入れ替え，また，入力定義も該当する機能項目のもので統合し直すことによりメッセージサブ仕様を作成することも本発明の一態様である。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、いわゆるメッセージを処理する技術に関する。その中でも特に証券分野における国（あるいは地域、以下、「国」）をまたがるコーポレートアクションの自動化に関するメッセージ処理技術に関する。
【背景技術】
【０００２】
株式の配当，株式分割，上場廃止，合併，議決権行使など発行会社と権利者間の事務処理であるコーポレートアクションは，国よる市場慣行の違い等により，業務の内容が多岐にわたるために人手で処理されることが多く，処理に時間がかかり，作業が不正確になりやすい問題があった。
【０００３】
この問題を解決するために，コーポレートアクションの自動化，すなわち，STP（Straight  Through  Processing）の試みがなされており，この一環しとして関連者間でコーポレートアクション情報の授受を行うためのメッセージの標準化が進められている。
【０００４】
本発明の説明に入る前に，本発明の主旨を理解し易くするために従来のコーポレートアクションのSTP化について述べる。図２に従来のコーポレートアクションのSTP化の試みとして想定される例を示す。
【０００５】
発行会社901から権利者905への株式の配当，権利行使などの通知を行う場合にについて述べる。
【０００６】
まず，発行会社901のCA業務システム81はコーポレートアクションに関するメッセージを証券の決済や証券の保管を行うCSD（Central Securities Depository）902に送信する。
CSD902のCA業務システム82は，受信したメッセージを解釈して，ここに権利者として登録されているローカルカストディ（LC)903用のメッセージを作成してローカルカストディ903へ送信する。
ローカルカストディ903のCA業務システム1は，受信メッセージを解釈して，必要な業務を行い，連携しているグローバルカストディ904用のメッセージを作成して送信する。ここで，ローカルカストディ903は，証券口座の維持，配当金の徴収，源泉課税にたいする還付申請などの業務を行うために発行会社の所在国の所在国の法令，税制，市場慣行に詳しい必要があり，所在国が発行会社と同一であることが普通である。
【０００７】
グローバルカストディ（GC)904のCA業務システム83は，メッセージ受信・解釈して必要な業務を行い，運用者用905へのメッセージを作成して運用者に送信する。グローバルカストディ904は，ローカルカストディ903と連携して，証券にかんする事務処理を運用者905に代わって実行する。このため，所在国は運用者と同一であることが普通である。
運用者905のCA業務システムは，グローバルカストディ904からのメッセージを解釈して，通知に対する判断や権利行使に関する支援業務を行う。議決権の行使など運用者905が権利行使を行う場合など，運用者905から発行会社901へ上記とは逆向きのメッセージが流れることになる。
このようにコーポレートアクションは一般に発行会社と権利者の間にローカルカスドディ903などのサービス提供者が介在することによって実現されている。
特に，ローカルカストディ903のCA業務サーバシステム1とグローバルカストディ904のCA業務サーバシステム83は相互に連携して，発行会社901と運用者905の所在国の違いによる市場慣行の違いを吸収する業務を行うことが必要となる。
【０００８】
また，メッセージの標準化が進められているが，各国の市場慣行を全て含むため，非常に広範囲なものになっておいるために，連携者間で標準メッセージから，必要とされる仕様を切り出したメッセージサブ仕様を取り決めて通信を行っている。システムの信頼性の向上のために，メッセージサブ仕様は連携者間でのメッセージの妥当性の検証に用いられている。
【０００９】
ローカルカストディのCA業務システムを例にとりCA業務システムについて簡単に説明する。
ローカルカストディ903のCA業務システム8は，CSD902およびグローバルカストディ904との間で取り決めた標準メッセージ仕様から切り出したメッセージサブ仕様801を保持して，メッセージ検証部802で，メッセージサブ仕様を用いて受信メッセージの検証を行う。次に，検証されたメッセージを解釈して該当する処理モジュール803を呼ぶ。
処理モジュール803は，前記市場慣行の違いを吸収するために株式の現金化や通貨の両替の処理など必要な処理を行う。この時，証券会社17や為替銀行16と連携して処理を実行する。
【００１０】
ここで、これらの技術に関する先行技術文献として、特許文献１がある。特許文献１では、コーポレートアクションの１つの業務である配当処理について，あらゆる種別の外国株式の権利配当情報に対応する権利配当管理装置が出願されている。ここでは，配当処理種別毎に処理パターンを前記装置に予め登録しておき，登録済みの配当種別の場合には，登録された処理パターンで前記装置により処理し，未登録の場合には，人手により処理パターンを前記装置に入力・登録をすることが開示されている。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開2009-48518号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
国を跨るコーポレートアクションは通常，CSD，ローカルカストディ，グローバルカストディ等が連携して発行者と運用者に対してコーポレートアクション支援サービスを提供している。
STP化されたコーポレートアクションにおいては，社会状況の変化等により連携者間で役割分担が変化した場合や新たな国の発行会社や運用者へサービスを開始する場合など，比較的頻繁にローカルカストディやグローバルカストディでの業務内容とメッセージサブ仕様が変更になり，システムやメッセージサブ仕様の保守作業が必要となる。
【００１３】
特にメッセージサブ仕様の保守作業には，標準メッセージ仕様に関する専門的な知識が必要であり，継続的に専門家を確保しておくことが難しい。また，処理モジュールにおいても，市場慣行の違いにより，処理に様々なバリエーションが存在するために，市場慣行ついてのある程度の専門的知識が必要となる。
前記特許文献１においては，コーポレートアクションの１つである配当処理について，様々なバリーションに対応できるように，簡単に機能を拡張できる特徴があるが，メッセージ仕様については言及されていない。
【課題を解決するための手段】
【００１４】
上記の課題を解決するために、本発明では、CA業務において、業務パターンを予め定めた粒度である機能項目に細分化し、これらそれぞれについて個別ルールを設定し、CA業務を受付けた場合、当該CA業務の機能項目を特定し、これに対応する個別ルールに従って処理を実行するものである。このように細分化された機能項目は、処理手順の変化を抑制できるものである。
より詳細には、カストディにおけるCA業務処理において下記手順で処理を実行する。
予め、業務手順が同一とみなせるまで業務パターンに細分化し，業務パターンの１つ１つを機能項目として定義し、記憶しておく。
そして、個々の機能項目とこれを指示するメッセージの論理的構造およびメッセージの各部の取るべき値のパターンとの対応を付け記憶しておく。
また、機能項目に対応するメッセージの論理的構造およびメッセージの各部の取るべき値のパターンを定義し記憶しておく。なお、これを入力定義と呼ぶ。
また、機能項目毎に業務として行うべき処理手順をルール化して定義し記憶しておく。なお、これを個別ルールと呼ぶ。
そして、これら定義されたものを利用して、CA業務としてなすべき機能項目群についての前記個別ルールを選択することにより業務処理を制御する。
【００１５】
また、CA業務としてなすべき機能項目群の入力定義を統合することによりメッセージサブ仕様を作成することも本発明の一態様である。
【００１６】
また、CA業務としてなすべき機能項目が変わって場合には，前記ルールを該当する機能項目のものに入れ替え，また，入力定義も該当する機能項目のもので統合し直すことによりメッセージサブ仕様を作成することも本発明の一態様である。
【発明の効果】
【００１７】
カストディ間の役割分担が変わる，あるいは新たな国の発行会社や運用者へサービスを開始する場合など，コーポレートアクション業務として受付けるべき機能項目が変化した場合には，機能項目に対応する個別ルールおよび入力定義に入れ替えることにより，業務に対応できる他，入力定義を再統合してメッセージサブ仕様を作成することができる。
このため，メッセージ仕様に対する深い知識が必要なメッセージサブ仕様の保守を自動化できる。また機能項目を選択するだけなので，市場慣行に関する知識も殆ど必要とせずに保守が可能となる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態のシステム構成図
【図２】従来コーポレートアクションのSTP化の方法を説明する図
【図３】CA業務および同業務において選択的な項目の例を示す図
【図４】配当処理に関する機能階層および機能項目を示す図
【図５】カストディにおけるCA業務システム詳細構成図
【図６】機能項目_５に対応するメッセージ構成図
【図７】機能項目_１に対応するメッセージ構成図
【図８】従来のメッセージサブ仕様作成手順を示す図
【図９】追加入力定義を示す図
【図１０】作成中のメッセージサブ仕様（追加先）を示す図
【図１１】追加結果（メッセージサブ仕様）を示す図
【図１２】型定義の統合処理を説明する図
【図１３】入力定義の統合処理フローを示す図
【図１４】要素定義の追加処理フローを示す図
【図１５】拡張規則管理テーブルを示す図
【図１６】機能項目判定テーブルを示す図
【発明を実施するための形態】
【００１９】
本発明の一実施形態を説明する前にコーポレートアクションに関するメッセージの標準化について簡単に説明する。
【００２０】
前記のメッセージの標準仕様として，メッセージのフィールド毎に文字数や記載内容が規定されたSWIFT MTメッセージ標準仕様やメッセージとしてXML形式を採用したSWIFT MXメッセージ標準仕様がある。
MXメッセージ標準仕様においては，メッセージのデータ形式としてXML形式を採用しているために，必要となるデータ項目のみに限定して送信することが容易であり，メッセージの内容を階層的に表現可能なこと，また，スキーマ定義を用いることによりメッセージの論理的構造やデータ形式や値が妥当であるかのバリデーションが容易である特徴がある。
なお，SWIFT MTメッセージ標準仕様ついては，例えば，SWIFT 2010年刊，”Standard MT November 2010 General Information”, SWIFT MXメッセージ標準仕様については，SWIFT  2008年刊，”SWIFT Standards MX General Information”を参照されたい。
【００２１】
SWIFT MTおよびSWIFT MXメッセージ標準仕様では金融関係の業務，本発明の対象であるコーポレートアクションを取り扱う「証券のイベント」の他，「証券取引」，「証券決済」，「資金の清算と決済」，「外為取引」などに特化した業務特定メッセージ標準仕様が策定されている。
【００２２】
前記のように国の市場慣行が異なるために，これらのメッセージ標準仕様はこれらを全て包含した非常に広範囲な仕様となっている。
このため，SWIFTの関連機関であるSecurities Market Practice Group(SMPG)が国ごとの市場慣行によるメッセージの仕様の定義を推進している。
この他，先に述べたように，連携者間でメッセージサブ仕様，すなわち，標準メッセージ仕様のサブセットを取り決めてこれを用いてメッセージ授受を行っている。
【００２３】
以上のメッセージの標準化動向についての説明を基に、以下本発明の一実施形態を説明する。
図３に、コーポレートアクション業務と同業務において選択的な項目の例3を示す。前記業務例としては配当処理，権利行使，通知一般があり，配当処理の選択的な項目として，現金配当，株式配当，現物配当などの配当方法，円，ドル，ユーロなどの現金配当通貨，現金化あるいは分散保有かの株式配当における端株の取扱，円，ドル，ユーロなどの端株現金化通貨がある。
このように配当処理などのCA業務においては，様々な選択的項目があり，これらの組み合わせを考えると，業務にバリエーションが多いことを理解されたい。
【００２４】
図４に、配当処理に関する機能階層および機能項目4を示す。図４は配当処理を選択的な項目に基づいて階層的に表現したもので，401から411までが機能項目である。
機能項目_1 401は，配当処理で，配当方法が現金配当，配当通貨が円である場合であり，機能項目_2 402および機能項目_3 403は，配当通貨がそれぞれドルあるいはユーロである以外は機能項目_1 401と同じである。
機能項目_4 404は，配当処理で，配当方法が株式配当，端株の取扱が端株現金化で，現金化する通貨が円である。
【００２５】
機能項目_5 405および機能項目_6 406は，現金化する通貨がそれぞれドルあるいはユーロである以外は，機能項目_4 404と同じである。
機能項目_7 407は配当処理で，配当方法が株式配当で，端株の取扱が端株分散所有である。
機能項目_8 408は，配当処理で，配当方法が現物配当，円に現金化する場合である。
機能項目_9 409および機能項目_10 410は，現金化する通貨が，それぞれドルあるいはユーロである以外，機能項目_8 408と同じである。
機能項目_11 411は，配当処理で，配当方法が現物である場合である。
【００２６】
ここで，機能項目が同一である場合には同一の手順で処理が可能となること，該当するメッセージについてもメッセージの論理的構成および機能を規定する部分の値は同一となる。
また，機能階層における選択的項目の順位について見方により変り，上記以外も考えられるが，得られる機能項目は同一となる。
【００２７】
次に、図１の本実施形態のシステム構成を用いて，本実施形態の動作手順の概要について説明する。
発行会社901から機能項目_５，すなわち，配当方法が株式配当，端株の取扱が端株現金化，通貨がドルである配当処理を実施したいが，運用者905側では，機能項目_1，円による現金配当しか受け付けず，ローカルカストディ903において円による現金配当，機能項目_1に変換してグローバルカストディ904に伝達する場合を想定する。
【００２８】
まず，ローカルカストディ903のCA業務システム１の構成について説明する。CA業務システム１は主にシステムの制御をおこなう制御部110と実際の処理を実行する実行部からなる。制御部110は，メッセージの検証等を行うメッセージ検証部111，メッセージサブ仕様の維持を行うメッセージサブ仕様制御部114，ルールによって機能項目毎のCA業務処理を制御する個別ルール112，機能項目毎のメッセージ仕様である入力定義113からなる。なお、これら各部は、プログラムに従って処理を行うＣＰＵの如き演算装置で実現される(以下、同様)。
【００２９】
実行部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へ送られることになる。
【００３２】
図５のカストディにおけるCA業務システム詳細構成を用いて本実施形態の各部の詳細および動作手順の詳細を説明する。
まず、メッセージ検証部111は受信したメッセージの検証を実行するメッセージ検証部本体1111,受信メッセージに該当する機能項目を判定する機能項目判定ロジック1112，機能項目から該当する個別ルールを検索する機能項目―個別ルール変換部1113から構成される。
個別ルール112は，業務ロジック実行部122を制御する業務ロジック部1121，メッセージ変換実行部121を制御するメッセージ変換部1122からなる。個別ルール112に付随する形で，機能項目単位でのXMLスキーマと拡張規則からなる該当機能項目の入力定義113が記憶される。
【００３３】
メッセージサブ仕様制御部114は，XMLスキーマと拡張規則からメッセージサブ仕様1141，入力定義113からメッセージサブ仕様を作成するメッセージサブ仕様編成部1142，メッセージ標準仕様のフルセットのXMLスキーマと拡張規則からなる標準メッセージ仕様1143からなる。
【００３４】
図６に、機能項目_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は、図１６の機能項目判定テーブル11121によってメッセージの機能項目を判定する。機能項目判定テーブル11121は，機能項目111211,
XMLパス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を削除することをメッセージ変換実行部に指示して，図７に示した機能項目_1に対応するメッセージ22を構成する。
すなわち，部分木CA移動詳細2214においては，機能項目_5において存在していた，部分木端株取扱2216および部分木証券移動2217は削除される。部分木現金移動2218においては，株式を現金化して現金配当としての配当額に関する情報を設定する。
また，部分木AmtDetls2219には配当金額についての情報を設定する。
さらに，要素EntileAmt2220には現金配当額を設定し，通貨の属性Ccyに”JPY”を設定する。
【００４０】
この他，ルールには記述されていなくとも行う処理として，部分木メッセージID2211にメッセージ識別子を入れる。部分木CA一般情報2212に配当通知，部分木アカウント情報2212には，ローカルカストディ903における送信先のグローバルカストディ904のアカウントについての情報を設定する。
【００４１】
以下に、メッセージサブ仕様の編成について説明する。
本実施形態のメッセージサブ仕様の作成方法の特徴を明らかにするために，まず，従来のメッセージサブ仕様の作成について簡単に説明する。図８にメッセージサブ仕様の例および従来の作成手順を示す。
【００４２】
メッセージサブ仕様50は，メッセージの論理的な構造を示すXMLスキーマと拡張規則からなる。XMLスキーマはルート要素の型定義501とその下位の要素の型定義5001〜5010，図には示されていないが，これらのさらに下位の型定義からなる。
【００４３】
拡張規則としてはCcy属性値5014があり，通貨の属性値として取り得る値，”USD”と”JPY”を記憶する。
型定義5011〜5013は標準メッセージ仕様において規定されているが，メッセージサブ仕様では削除されているものである。
型定義は下位の要素の名前および型定義，場合によっては属性の定義を含む。下位の要素をもたない場合は，要素の名前およびデータ型，場合によっては属性の定義を含む。これらの他にデータ型の定義を含む。
なお，型定義などXMLスキーマの詳細については，WWWコンソーシアムXMLスキーマについてのホームページ“http：／／www.w3.org／XML／Schema”を参照されたい。
【００４４】
以上のメッセージサブ仕様の構成についての説明に基づいて，その作成手順を述べる。
配当方法に関する機能階層および機能項目4から必要となるメッセージを構成する要素とその値を抜き出して，XMLスキーマと要素の値あるいは属性の値として規定すべき内容を拡張規則として定義する。
例えば，機能項目_１および機能項目_５のでは，配当処理で型定義CA一般情報5002の下位の型を含めて“配当通知”のみの値とする。
同様に型定義配当種別においては，”現金配当”と”株式配当”のみの値とする。
配当に関する通貨は，EntildAmt要素の属性が”UDS”と”JPY”のみであることを，拡張規則5014に登録する。型定義端株取扱5006では”現金化”のみの値とする。
このようにメッセージサブ仕様を作成するためにはメッセージの各要素や属性の意味を十分に理解している必要がある。
【００４５】
次に、本実施形態におけるメッセージサブ仕様の作成手順を説明する。
機能項目毎の入力定義，すなわち対象の機能項目のみを伝えるために必要な最小限のXMLスキーマと拡張規則を個別ルールと対応付けて作成して置く。
ローカルカストディとして取り扱う各機能項目分の入力定義を統合する，すなわち，１つの機能項目の入力定義に，残りの機能項目の入力定義を順次追加して行くことによりメッセージサブ仕様を作成する。
【００４６】
図９から図１１を用いて、メッセージサブ仕様の作成手順の概要を説明する。
図９に、追加する入力定義51を示す。これは機能項目_５の入力定義である。図１０に追加先の入力定義，この場合は機能項目_１の入力定義を示す。図１１にこれらが統合された結果を示す。
【００４７】
図９の追加処理対象外型定義512は，追加先にも同一の型定義が存在するので，追加が不要なものである。
追加対象型定義514は追加処理が必要な型定義および拡張規則である。
例えば追加する型定義配当種別5142の値”株式配当”と追加先の型定義配当種別5242の値”現金配当”を統合すると，追加結果の型定義配当種別5342の値は”株式配当”あるいは”現金配当”となる。
型定義端株取扱5143は追加先に存在しないので，この型定義を追加先の型定義CA移動詳細5241に登録する。同じく，型定義証券移動5144は追加先に存在しないので，下位の型定義を含めて追加する。
型定義EntildAmt5347の属性である通貨については，拡張規則Ccy属性値5148とし”USD”のみが規定されている。これに対して追加先拡張規則Ccy属性値5245のでは”JPY”が規定されており，これらを統合すると，拡張規則Ccy属性値5348は”USD”あるいは”JPY”となる。
この様な要領（処理）で入力定義の統合処理を実現する。
【００４８】
次に，型定義同士の統合処理については説明する。
図１２に型定義の統合処理，すなわち，ある型定義をそれに該当する型定義へ追加する処理の概要を示す。今，機能項目_５に対応する追加元の型定義である型定義CA移動詳細5141を追加先である機能項目_１の型定義CA移動詳細5241に追加することを考える。
双方の型定義内の要素定義を比較して追加すべき要素定義を探して追加する。
すなわち，追加元にあって追加先にないもの，すなわち，要素定義端株取扱51411と要素定義証券移動51411を追加先に追加する。
この際，XMLスキーマとしてSequenceが指定されているので，標準メッセージ仕様を参照して要素定義の並ぶ追加位置を判定して，要素の並ぶ順番が標準メッセージ仕様と同じになるようにする。
追加結果は型定義CA移動詳細5341に，要素定義配当種別53411，要素定義端株取扱53412および要素定義証券移動53413の順で並べる。
【００４９】
一方，列挙型の統合処理を図１２に下の部分に示す。
追加元の列挙型定義配当種別5241を追加先の列挙型定義配当種別5242に統合する。
追加元には株式配当51411，追加先には現金配当52411が規定されており，追加結果では，現金配当53411と株式配当53412との両方が規定されることになる。
なお，図１２では，図面や説明を簡略にするために，XMLスキーマの表記を正式なものでなく，簡略化した表記を用いている。
【００５０】
以下，入力定義の統合処理についての概要説明を基に，入力定義の統合処理の手順の詳細を図１３〜図１５を用いて説明する。
図１３に、入力定義の統合処理の処理フロー6を示す。図１４要素定義の処理フロー605を示す。図１５に拡張規則管理テーブル７を示す。
まず，拡張規則管理テーブルについて説明する。拡張規則管理テーブル7には拡張規則が定義されるXMLの要素の値や属性を指定するXMLパス71，拡張規則の対象の種別，ここでは属性の値および要素の値の区別，値７には，該属性や要素の値として許容される値を記憶する。
例えば，XMLパス”CA移動詳細／現金移動／AmtDtls／EntitldAmt／Ccy”711の例では，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においては，要素定義の追加処理を行う。処理の詳細は図１４を用いて説明する。
ステップ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において，先に述べたようにして追加処理を行う。
【００５８】
次に、要素定義の追加処理を図１４を、用いて説明する。
ステップ6051においては，追加側の該型定義から追加する要素定義を取り出す。
ステップ6052においては，該要素は”sequence”指定されているかを判定する。”sequence”の場合はステップ6053へ進む。”choice”などその他の場合にはステップ6058へジャンプする。
【００５９】
ステップ6053においては，標準メッセージ仕様の該型定義を検索する。これは該型定義のパスに該当する型定義を検索すれば良い。
ステップ6054においては，該要素定義の追加位置を求める。すなわち，標準メッセージ仕様における要素定義の順番を守る位置を求めれば良い。
ステップ6055においては，得られた位置に該要素定義を埋め込めば良い。
ステップ6058においては，要素定義の順番は問題にならないので，デフォルトの追加位置，例えば被追加型定義の最後に該要素定義を追加すれば良い。
【００６０】
ステップ6056においては，追加型定義内の要素定義で追加すべきものが残っているかを判定する。未完の場合いは，ステップ6057に進む。完了した場合には，ステップ6059ヘリンクして処理を終了する。
ステップ6057においては，該型定義で追加すべき要素定義で残っているものを取り出す。
【符号の説明】
【００６１】
１………CA業務システム
１６……為替銀行
１７……証券会社
１１０…制御部
１１１…メッセージ検証部
１１１２１…機能項目判定テーブル
１１２…個別ルール
１１３…入力定義
１１４…メッセージサブ仕様制御部
１２０…実行部
１２１…メッセージ変換実行部
１２２…業務ロジック部
２１……受信メッセージ
２２……送信メッセージ
３………CA業務および同業務において選択的な項目の例
４………配当処理に関する機能階層および機能項目
５０……メッセージサブ仕様
５１……追加入力定義
５２……作成中のメッセージサブ仕様（追加先）
５３……追加結果（メッセージサブ仕様）
５１４１…追加元の型定義
５２４１…追加先の型定義
５３４１…追加結果の型定義
５２４１…追加元の列挙型定義
５２４２…追加先の列挙型定義
５２４３…追加結果の列挙型定義
６………入力定義の統合処理フロー
６０５…要素定義の追加処理フロー
７………拡張規則管理テーブル
８１〜８４…CA業務システム
９０１…発行会社
９０２…CSD
９０３…ローカルカストディ
９０４…グローバルカストディ
【図１】
2013041384.tif 000003
【図２】
2013041384.tif 000004
【図３】
2013041384.tif 000005
【図４】
2013041384.tif 000006
【図５】
2013041384.tif 000007
【図６】
2013041384.tif 000008
【図７】
2013041384.tif 000009
【図８】
2013041384.tif 000010
【図９】
2013041384.tif 000011
【図１０】
2013041384.tif 000012
【図１１】
2013041384.tif 000013
【図１２】
2013041384.tif 000014
【図１３】
2013041384.tif 000015
【図１４】
2013041384.tif 000016
【図１５】
2013041384.tif 000017
【図１６】
2013041384.tif 000018