JP2014167723A - 構造化電文処理方法 - Google Patents

Abstract

【課題】任意の構造化電文について、木構造の解析(パーシング)と、タグ間に囲まれた業務データの値検証(バリデーション)を並列的に実行できる方法を提供する。
【解決手段】処理方法は、(1)ホスト部が、外部インタフェースから非定型の構造化電文を受信するステップと、(2)ホスト部が、受信した構造化電文をデバイス部に転送するステップと、(3)ホスト部が、構造化電文の文書構造を解析(パーシング)し、同時並行的に、デバイス部が、前記構造化電文に含まれる値パターンを検証(バリデーション)するステップと、(4)デバイス部が、検証された値パターンと前記構造化電文中の位置とを含む値検証情報をホスト部に応答するステップと、(5)ホスト部が、前記文書構造の解析結果と前記値検証情報とを参照し、前記構造化電文の妥当性を判断するステップとを有する。
【選択図】図１

Description

本発明は、XML（eXtensible Markup Language)に代表される構造化電文を処理する方法に関する。

今日では、多数の業界で業務データを自動・高速で処理するオンラインシステムが使われている。オンラインシステムでは、企業を超えて複数のシステムを相互接続する必要がある。このため、オンラインシステムを流れる通信データの標準化と相互運用性の確保に多大な努力が払われてきた。通信データのデータ形式として、従来は、固定長のテキストデータが主に用いられてきた。しかし、近年、柔軟かつ相互運用性に優れた構造化電文（例えばXML(eXtensible Markup Language)形式の電文）が本格的に使われ始めている。なお、以下では、XMLを用いて記述された文書（電文やファイルを含む）をXML文書等と呼ぶ。

XML文書は、タグと呼ばれる特定の文字列で区切られたテキストで構成される。XMLは、フォーマットフリーであり、柔軟なデータ表現が可能である。

その反面、XMLは、構造解析（パーシングと呼ぶ）を最初に逐次的に実行する必要があり、構造解析を実行しないと、業務データの取り出しや値の検証(バリデーション)を行えないという、性能上の難点がある。

また、XML文書を処理するプログラムは、ＣＰＵやメモリに与える負荷が大きい。このため、該プログラムをオンラインシステムに単純に実装したのでは、多大なＣＰＵ時間およびメモリを消費する。結果的に、オンラインシステムの構築に、過剰なハードウェア投資が余儀なくされている。また、前述の通り、XMLの構造解析は逐次的な処理の性質を有するため、GPU(Graphics Processing Unit)に代表される、多数の演算コアを有するアクセラレータデバイスの活用が困難であった。

そこで従来より、XML電文の処理性能の向上および処理の並列化に向けて、複数の取り組みが行われてきた。これら取り組みに関する文献には、例えば特許文献１〜３がある。

特許文献１には、XMLファイルを空間的に分割し、部分ツリー毎にパーシングを並列実行し、後に結合する手段を提供する手法が開示されている。特許文献２には、タグ位置を検出する手段と、タグ間のテキスト(業務値)を処理する手段とを並行に動作させつつ、両手段の処理速度を調整する手段を有する構成が開示されている。特許文献３には、同タイプのXML電文が連続的に到着することを前提にパース処理を省略し、受信したXMLファイルのタイプを識別するステップと、タイプに従って評価テンプレートを選択するステップとを有する処理方法が開示されている。

特開２０１１−１６５１６０号公報 特開２０１０−２８２３４７号公報 特開２００８−２６２５４１号公報

NVIDIA(R) Tesla(TM) GPU Computing Technical Brief, version 1.0, http://www.nvidia.com/docs/IO/43395/tesla_technical_brief.pdf PFAC Library - GPU-based string matching algorithm, http://pfac.googlecode.com/files/PFAC_userGuide_r1.1.pdf

しかし、特許文献１の方法は、パーシングの並列化に資する一方で、値の検証（バリデーション）を加速する方法については示していない。特許文献２の方法は、タグ位置の検出の後に値の検証（バリデーション）を行う点で逐次的であり、パーシングとバリデーションを並列的に実行することは困難である。特許文献３は、同種類の電文が連続して到着しない限り、速度の向上が困難である。

そこで、本発明は、木構造の解析(パーシング)と、タグ間に囲まれた業務データの値の検証(バリデーション)を並列的に実行し、ＣＰＵ時間及びメモリ使用量の抑制と、高い処理スループットとの両立を図る。

本発明は、ＣＰＵと主記憶と外部インタフェースを有するホスト部と、複数の演算コアとデバイスメモリを有するデバイス部とを有する電文処理システムを用いた構造化電文処理方法であって、
ホスト部が、外部インタフェースから非定型の構造化電文を受信するステップと、
ホスト部が、受信した構造化電文をデバイス部に転送するステップと、
ホスト部が、構造化電文の文書構造を解析(パーシング)し、同時並行的に、デバイス部が、構造化電文に含まれる値パターンを検証(バリデーション)するステップと、
デバイス部が、検証された値パターンと構造化電文中の位置とを含む値検証情報をホスト部に応答するステップと、
ホスト部が、文書構造の解析結果と値検証情報とを参照し、構造化電文の妥当性を判断するステップと
を有する電文処理方法を提供する。

本発明により、ＣＰＵを有するホスト部によるパーシング処理と同時並行的に、複数の演算コアを有するデバイス部においてバリデーション処理を実行できる。本発明の場合、デバイス部は、ホスト部のパーシング結果に依存せず、構造化電文中の任意の位置(例えば任意のバイトオフセット位置)からバリデーションを開始するため、ホスト部とデバイス部間の同期を必要としない。このため、より高い処理並列性を提供することができる。また、本発明は、バリデーション処理をデバイス部側にオフロードするため、ホスト部におけるＣＰＵ時間及びメモリ使用量の両方を抑制することができる。

パーシングとバリデーションの並列実施手順を説明するフローチャート。 電文処理システムの構成例を示す図。 ホスト部とデバイス部間の通信路の構成及びデータ配置を説明する図。 処理対象とする構造化電文の例を示す図。 構造化電文の構造を規定するスキーマの例を示す図。 ホスト部からデバイス部に対して要求を発行する際の通信路に当たるキュー構造のフォーマット例を示す図。 デバイス部からホスト部に対してバリデーション結果を応答する際の通信路に当たるキュー構造のフォーマット及び値の具体例を示す図。 ホスト部によるパーシング処理の結果例を示す図。 ホスト部で得られるパーシング結果と、デバイス部で得られるバリデーション結果を照合し、文書の妥当性をチェックする処理手順の例を示す図。 デバイスプログラムが実行する文字単位での並列バリデーション処理とデータの流れを概念的に示す図。 デバイス部における文字コードのデコード処理コードの例を示す図。 有限長の正規表現によるマッチング処理に使用する内部データテーブルと処理対象データの例を説明する図。 有限長の正規表現によるマッチング処理手順の一例を示すフローチャート。 図１０に示す処理手順の一部分を詳細に示すフローチャート。 列挙型・固定長文字列のマッチング有向グラフの例を示す図。 XMLファイルに含まれる年月日を示す業務データのインスタンス例及びスキーマ例並びに“うるう年”判定処理概念を示す図。 図１３に示す“うるう年”判定に使用するデコード処理コードの例を示す図。 デバイス部で保持する値パターン情報のフォーマット例を示す図。 デバイス部で保持する値パターン情報のフォーマット例を示す図。 デバイス部で保持する値パターンの入れ替え(ロード／アンロード)処理の手順例を示す図。 ステップ１１５（図１）において実行される処理内容の詳細を示す図。 デバイスプログラム３１３（図３）において実行される処理内容の詳細を示す図。 ステップ１１３ａ（図１）において実行される処理内容の詳細を示す図。

以下、本発明の実施例を、図面を用いて説明する。なお、後述の実施例は、出願に係る発明を分かり易く説明する観点から記載している。従って、本発明は、後述の構成に限定されず、発明概念に含まれるあらゆる構成・処理を包含する。例えば不図示の構成・処理要素を追加した実施例、構成・処理要素の一部を他の構成・処理要素で置換した実施例を含んでも良い。また、ある実施例の構成・処理要素と他の実施例の構成・処理要素を組み合わせても良い。また、各実施例で説明する構成・処理要素は、発明を説明するための一例であり、記載した構成・処理要素の一部を搭載しない構成も考えられる。

（処理手順の概要）
図１に、実施例に係る構造化電文処理方法の基本的な処理手順を示す。図１に示す処理は、例えば図２に示す構成の電文処理システム（計算機システム）において実行される。本実施例で説明する構造化電文処理は、図１に示すように、ＣＰＵを有するホスト部２０４で実行する処理ステップ（１００〜１１４、１２１〜１２２)と、多数の演算コアを有するデバイス部２０５で実行する処理ステップ(１１５〜１１６)との間で処理を分担する点、特にホスト部２０４の解析（パーシング）を待つこと無くデバイス部２０５が値の検証（バリデーション）を並列的に実行する点を特徴とする。

本実施例では、構造化電文とXMLファイルとを同一視して説明するが、本発明は構造化電文をXMLファイルに限定するものでは無く、HTML(Hyper Text Markup Language)やSGML(Standard Generalized Markup Language)等で記述されたファイルに対しても同様に適用可能である。

ホスト部２０４は、最初にネットワークから構造化電文を受信し(ステップ１１１)、構造化電文のタイプを判定する(ステップ１１２)。XMLファイルのデータ構造及び許可される値に関しては、スキーマと呼ばれる文書によって別途指定される。一般に、XMLファイルのインスタンスには、スキーマを一意に特定するURI(Universal Resource Identifier)が含まれている。

次に、ホスト部２０４は、必要に応じ、デバイス部２０５に対して、XMLファイル処理に要する値パターンのロード／アンロードを指示する(ステップ１１３ａ)。本指示を受けてデバイス部２０５が実行する処理の内容については、図１７を用いて後述する。ロード／アンロードを必要とする典型例には、(1) 本システムの電源投入後に初めて受信したXMLファイルタイプに対応する値パターンをロードする場合、(2) パフォーマンスの最適化のために、より多数の値パターンをロードする場合、(3) デバイス部２０５に保持される値パターンの数がデバイス部２０５で保持可能な値パターンの最大数を超えてしまいアンロードを要する場合などが考えられる。勿論、これらは一例であり、必ずしも本例に限るものではない。

次に、ホスト部２０４は、受信した構造化電文をデバイス部２０５に送信し(ステップ１１３ｂ)、XMLファイルに含まれる業務値の検証（バリデーション）を依頼する。

その後、ホスト部２０４は、構造化電文に含まれるデリミタに着目して構造化電文の木構造の解析（パーシング）を実行する（ステップ１１４）。このホスト部２０４によるパーシングと並行して、デバイス部２０５は、構造化電文から所定の値パターンに合致する部分を抽出し(ステップ１１５)、値パターンと検出位置を対応付けて値検証情報を作成し、ホスト部に応答する(ステップ１１６)。

ステップ１１５による値パターンに合致する部分の抽出例については、図７〜１４を用いて後述する。また、ステップ１１６による応答情報の例については、図５Ｂを用いて後述する。本実施例の場合、値バリデーションは、ステップ１１５及びステップ１１６を総称する意味で使用する。

これらの処理の後、ホスト部２０４は、パーシング結果である木構造の解析結果と、バリデーション結果である値検証情報とを参照し、受信した構造化電文の妥当性を判断する(ステップ１２１)。すなわち、ホスト部２０４は、処理対象であるXMLのリーフノード(子要素を持たない末端のノード)の値領域のデータタイプ及び範囲(長さ情報)を、木構造の解析結果と値検証情報の両方についてつき合わせ、両者が合致する場合に「妥当」、両者が合致しない場合に「不適格」と判断する。

上記処理が完了した後、ホスト部２０４は、次の業務処理に進む(ステップ１２２)。次の業務処理の一例には、(1) XMLファイルを異なるファイル形式(例えばCSV: Comma Separated Value)に変換して他のシステムに連携する処理、(2) 業務上定義されるXMLノード間の値チェック(例；チェックサムにより振り込み金額の総計が合っているか検証する)、(3) 業務データをデータベースに格納する等がある。勿論、これらは一例であり、他にも多様な連携処理が考えられる。

（処理システムの概要）
図２に、前述したホスト部２０４及びデバイス部２０５を搭載する電文処理システム２０１の構成例を示す。電文処理システム２０１は、典型的にはサーバとして実現され、Intel（商標）社の汎用ＣＰＵを搭載したIA(Intel Architecture)サーバを用いる例が多い。電文処理システム２０１には、電文ネットワーク２０２、ネットワークストレージ２０３が接続される。

電文処理システム２０１の内部は、大別すると、ＣＰＵを含むホスト部２０４と、多数の演算コアを有するデバイス部２０５に分類できる。ホスト部２０４とデバイス部２０５は、内部Ｉ/Ｆ２１３経由で接続されており、一般に分離されたメモリ空間を有している。内部Ｉ/Ｆ２１３は、PCI express（商標）で実現されるケースが多い。

ホスト部２０４は、一般的なIAサーバと同一であり、ＣＰＵ２１４と主記憶２１６がメモリＩ/Ｆ２１５経由で接続されており、外部の電文ネットワーク２０２やネットワークストレージ２０３と接続するための外部Ｉ/Ｆ２１１、内部ストレージ２１２、及び前述の内部Ｉ/Ｆ２１３を有している。図２は、ＣＰＵ２１４として、内部に４つのＣＰＵコアを有する例を示しているが、ＣＰＵコアは必ずしも４つに限る必要は無い。

デバイス部２０５は、演算コア群２２１とデバイスメモリ２２２を広帯域メモリＩ/Ｆ２２３で接続した構成を有する。デバイス部２０５の典型例には、NVIDIA（商標）社のtesla（商標）GPUが挙げられる（例えば非特許文献１を参照）。勿論、デバイス部２０５は、必ずしも本製品に限るものではない。

デバイス部２０５は、１つ以上のデバイスカード２２４で構成される。デバイスカード２２４は、内部に演算コア群２２１、デバイスメモリ２２２を有し、それらを広帯域メモリＩ/Ｆ２２３で接続する構成を採る。デバイスカード２２４の典型例には、NVIDIA（商標）社のtesla（商標）GPUが挙げられる。勿論、デバイスカード２２４は、必ずしも本製品に限らない。また、デバイスカード２２４の実装形態はカードに限らない。

（ホスト部とデバイス部間の通信）
図３に、電文処理システム２０１の内部で実行される処理プログラムと、処理プログラム間を接続する通信路と、通信されるデータの配置の例を示す。なお、図３では、電文処理システム２０１にクライアント３００と他システム３０１が接続されている。

ホスト部２０４には、クライアント３００や他システム３０１から処理対象の電文を受け付けるサーバプログラム３０２、XMLファイルをパーシングするパーサプログラム３２３が配置される。サーバプログラム３０２とパーサプログラム３２３は、XMLインスタンス送付３２１及び構文解析結果応答３２２を通じ、相互に通信する。

一方、デバイス部２０５には、値検査(バリデーション)処理を行うデバイスプログラム３１３と、値検査に用いる値検査パターン３１４が配置される。

ホスト部２０４のプログラムの説明に戻る。サーバプログラム３０２は、その内部に、キュー及び流量の制御を実行するモジュール３０３、スキーマ解釈を実行するモジュール３０４を有する。キュー・流量制御モジュール３０３は、デバイス部２０５を構成するいずれのデバイスカード２２４に対して処理要求を発行すべきか判断する。スキーマ解釈モジュール３０４は、受信したXMLファイルのタイプを判定し、デバイス部２０５の値検査パターン３１４に格納されている内容のロード/アンロードを指示する。

サーバプログラム３０２がデバイスプログラム３１３に対して要求を送信する場合、サーバプログラム３０２は、ホスト値検査要求キュー３０７及びデバイス値検査要求キュー３１１を順に介し、XMLインスタンス及び値検査パターンの送付３０５を実行する。ホスト部２０４からデバイス部２０５への通信には、H2D(host to device) copy ３０９が用いられる。

反対に、サーバプログラム３０２がデバイスプログラム３１３から応答を受け取る際には、デバイス値検査応答キュー３１２、ホスト値検査応答キュー３０８を介して検査結果取得３０６を行う。デバイス部２０５からホスト部２０４への通信には、D2H(device to host) copy ３１０が用いられる。

（データ構造）
図４Ａに、実施例に係る電文処理システム２０１（図２）が処理対象とする構造化電文の例を示す。処理対象データ（XMLインスタンス）４０１には、主に金融業会で用いられる支払い指示電文(payment initiation)の例を示している。

本電文には、特定の文字列で区切られた部分文字列４０２が含まれている。部分文字列４０２には、開始トークン４１１としての”<MsgId>”と終了トークン４１２としての”</MsgId>”に囲まれた値領域４１３が格納されている。開始トークン４１１は、始まりを示す開始デリミタ４１４ａ(“<”)と終端を示す終端デリミタ４１５ａ(”>”)によりタグ名(“MsgId”)が囲まれている。終了トークン４１２は、同じく開始デリミタ４１４ｂ(“</”)と終了デリミタ４１５ｂ(“>”)で区切られている。

デバイス部２０５が、任意のタグの値領域４１３に対してバリデーションを行う場合、終端デリミタ及び開始デリミタに着目することで、値の存在場所（オフセット）及び長さを確認することができる。

図４Ｂに、実施例に係る電文処理システム２０１（図２）が処理対象とする構造化電文のスキーマの例を示す（XMLスキーマ定義４３１）。スキーマとは、構造化電文の種類毎に構造化電文が採り得る木構造の親子関係を定義する文書である。XMLスキーマ定義４３１は、スキーマが対象とする電文種類を特定するための識別子（ネームスペース定義４３２）と、構造化電文内部の要素および要素間の関係を示す部分（要素定義４３３）を有する。本実施例の場合、ネームスペース定義（スキーマ識別子）として“urn:iso:std:iso:20022:tech:xsd:pain.001.001.03”を有する構造化電文のデータ構造を要素定義４３３の部分に有している。

図５Ａに、ホスト値検査要求キュー３０７のデータフォーマット例を示す。本実施例では、デバイス値検査要求キュー３１１にも同様のデータが格納されることを想定する。ホスト値検査要求キュー３０７の典型的な実装方法には、固定長のエントリが連続的に配置されたリングバッファが挙げられる。もっとも、実装方法は、本フォーマットに限らない。

ホスト値検査要求キュー３０７は、Request Typeを示すフィールド５０１、引数の長さを示すArguments Length フィールド５０２、引数に当たるArgs[]フィールド５０３から構成される。Request Type５０１は、XMLの業務値検査を要求する値検査要求(＝1)、値検査パターンのロード／アンロードを要求する値検査パターンロード(＝2)、無効なエントリを示すinvalid(＝0)で構成される。

Request Type５０１の内容に従い、引数Args[]フィールド５０３の内容が指定される。Request Type＝1（値検査要求）の場合、引数Args[]フィールド５０３にはXMLインスタンスそのものが格納される。一方、Request Type＝2（値検査パターンロード）の場合、引数Args[]フィールド５０３には値検査パターンが格納される。値検査パターンの例を図１５及び図１６に示す。値検査パターンの詳細については後述する。

図５Ｂに、デバイス値検査応答キュー３１２のデータフォーマット例を示す。本実施例では、ホスト値検査応答キュー３０８にも同様のデータが格納されることを想定する。デバイス値検査応答キュー３１２の典型的な実装方法には、同じくリングバッファが挙げられる。もっとも、実装方法は、必ずしも本フォーマットに限らない。

デバイス値検査応答キュー３１２には、前述のRequest Type＝1（値検査要求時）に指定されたXMLインスタンスに対し、業務値の種類(ID フィールド６１１ａ)、IDに対応する業務値パターンの格納位置（Index フィールド６１１ｄ）、業務値が含まれる文字列の先頭のオフセット（start フィールド６１１ｂ）、業務値が含まれる文字列の長さ（value_length フィールド６１１ｃ）が格納される。

本情報は、１行が１要素に対応する形式を採る。図５Ｂの場合、６１１行目に<MsgId>〜〜</MsgId>タグに囲まれた業務値について記述があり、ID=1（string）、Index=2（図１６の1823に合致)、start=191（191文字目）、value_length=17（17文字）を応答している。本データを受け取ったホスト部２０４のサーバプログラム３０２は、後述する木構造解析結果（図５Ｃ)と照合し、対応する業務データの位置とタイプが合致していることを確認する(図６に後述)。

図５Ｃに、ホスト部２０４のパーサプログラム３２３によるXMLデータの木構造解析結果の例を示す。本データは、サーバプログラム３０２からの要請（XMLインスタンス送付３２１）に対応する構文解析結果応答３２２の内部に含まれる。

本データ構造は、意味的に複数のノードが子ノードID（フィールド７２４，７３５ａ〜７３５ｂ，７４５ａ〜７４５ｅ）によって接続される構造を採る。典型的には、Javaなどの開発言語のオブジェクトインスタンスとして表現されるが、必ずしも特定の言語や開発環境に依存した表現形態である必要はない。

offset=0には、XMLインスタンスの木構造解析結果のサマリフィールド７１１が格納される。本実施例の場合、“1”のとき、well-formedであることを示す。well-formedとは、XMLのタグ文字及び開始／終了トークンの対応関係をチェックした際に、完全な入れ子になっていることを示す。一般に、well-formedのチェックには、XMLファイルのノードの意味を規定するスキーマを解釈する必要が無く、値検証（バリデーション）に比べ、ホスト部２０４のＣＰＵ時間を要さない。offset=1には、XMLファイルに含まれるノードの総数フィールド７１２が格納される。

以降、ルートノード（node instance ID (フィールド７２１)＝0, “Documents”）がoffset=2〜6に、”CstmrCdtTrfInitn”ノードがoffset=7〜12（node instance ID (フィールド７３１)＝1）に、“GrpHdr”ノードがoffset=13〜21（node instance ID (フィールド７４１)＝2）に直接の親子関係で接続される。

これらのノードは、いずれも単純型の値を持たない中間ノードである。しかし、その下位には、さらに末端ノードである”MsgId”ノード（node instance ID (フィールド７５１)＝3）が接続される。本実施例の場合、単純型の値を有する末端ノードをリーフノードと称する。

“MsgId”ノードには、内容を示すID＝1（本実施例では、最大35文字のstringを想定している）を保持するフィールド７５２、本ノードに含まれる単純型の値の開始位置(position of value field)を保持するフィールド７５４、値の長さ(length of value)を保持するフィールド７５５がそれぞれ格納される。ホスト部２０４は、本情報に基づいて、図６について後述する構造化電文の妥当性チェックを実行する。

（ホスト部２０４による構造化電文の妥当性チェック）
図６に、本実施例で実行される構造化電文の妥当性チェック方法について説明する。図６は、ステップ１２１（図１）で実行される処理内容を詳細に記述したものであり、ホスト部２０４のサーバプログラム３０２が実行する。

まず、サーバプログラム３０２は、パーサプログラム３２３から受信した(1) 木構造電文の解析結果がwell-formedであるか否かを判断する（ステップ８０２）。フィールド７１１の値が“0”の場合、受信した構造化電文はwell-formedではない。この場合、サーバプログラム３０２は、以降の処理をスキップして例外処理（ステップ８９２）に移動する。

フィールド７１１の値が”1”の場合、サーバプログラム３０２は、「木構造の解析結果」を参照し、リーフノードの情報を１つ取得する（ステップ８０３）。リーフノードの情報は、例えば図５Ｃのフィールド７５１〜７５５が相当する。

次に、サーバプログラム３０２は、デバイス部２０５から受信した「値検証情報」の中にステップ８０３で取得したリーフノードの値ポジション（図５Ｃのフィールド７５４）と、start（図５Ｂの６１１ｂ）が一致するエントリをサーチする（ステップ８０４）。

次に、サーバプログラム３０２は、ステップ８０４で対応するエントリの有無を判定する（ステップ８０５）。対応するエントリが存在しない場合、サーバプログラム３０２は、well-formedでない場合と同様に、例外処理（ステップ８９２）に移動する。

図５Ｂの６１１行目から６２３行目までのいずれかの行において、リーフノードに対応するエントリが発見された場合、サーバプログラム３０２は、ステップ８０３で取得したリーフノード情報中の値の長さ（図５Ｃ中のフィールド７５５)と、ステップ８０４で発見したエントリのvalue_lengh（図５Ｂ中のフィールド６１１ｃ）を比較する(ステップ８０６)。

次に、サーバプログラム３０２は、ステップ８０６の比較結果が異なるか否かを判定する（ステップ８０７）。ステップ８０６の比較により両方の値の長さ情報が一致しない場合、サーバプログラム３０２は、例外処理（ステップ８９２）に移動する。

一方、ステップ８０６の比較により両方の値の長さ情報が一致していた場合（すなわち、チェックに通った場合）、サーバプログラム３０２は、残りのリーフ処理が無いか否かを確認する（ステップ８０８）。全てのリーフノードのチェックが完了していない場合、サーバプログラム３０２は、ステップ８０３に戻り、次のリーフノードについて一連の判定処理を実行する。これに対し、全てのリーフノードのチェックが完了していた場合、サーバプログラム３０２は、一連の処理を終了する（ステップ８９１）。サーバプログラム３０２がステップ８９１に到達すると、全リーフノードの値の種類及び長さがスキーマの規定通りであることが保証される。

（デバイス部２０５による並列バリデーション処理）
図７に、デバイスプログラム３１３が実行する文字単位での並列バリデーション処理とその際のデータの流れを概念的に示す。デバイスプログラム３１３は、入力データ９０１としてXMLファイルストリームを取得する。デバイス部２０５は、入力データ９０１を多数の演算コアで処理する。このため、デバイス部２０５は、入力データ９０１をインスタンス化し、多数のプログラムスレッド９０２ａ〜９０２ｚを生成する。インスタンス化に用いる方法は、開発環境およびデバイスカード２２４の実装状況に依存する。例えばNVIDIA（商標）社のCUDA（商標） SDKの場合、C言語に近い高級言語環境に加え、スレッド制御(同期およびコア割付)手段がAPIとして提供される。

スレッド#0のプログラムスレッド９０２ａは、XMLファイルを読み出す位置を示すread pointer９１１ａを有する。図７の例の場合、入力データ９０１のオフセット位置「183」からXMLファイルを読出し、入力バッファ９１２ａに格納する。入力バッファ９１２ａはオプションであり、他のスレッドと共用のバッファでも構わない。プログラムスレッド９０２ａは、入力バッファ９１２ａに格納されたデータに対し、後述するUTF8デコード処理９１３ａ、値検証処理９１４ａを順に実行する。

スレッド#1のプログラムスレッド９０２ｂは、XMLファイルを読み出す位置を示すread pointer９１１ｂを有する。プログラムスレッド９０２ｂは、入力データ９０１のオフセット位置「184」（すなわち、前述のプログラムスレッド９０２ａから1バイトずれた位置）から入力データを読み出し、以降同じ処理を行う。プログラムスレッド９０２ｂ以降の他のプログラムスレッド９０２ｃ…９０２ｚについても、それぞれ順番に1バイトずつずれた位置から入力データを読み出し、前述と同様の処理を実行する。この処理は、多数の演算コアを有するデバイスカード２２４が、SIMD(single instruction multiple data)型の演算を得意とすることを利用するための処置である。本実施例では、このように開始位置の検出を行わず、全てのバイトオフセットから処理を開始できるようにすることにより、高い並列性を容易に実現する。

図８に、XMLファイルの文字コードに対して適用されるデコード処理の一例を、擬似コードの形態で示す。本実施例では、XMLファイルの文字列エンコード方法がutf-8であるものと仮定する。本コードの場合、入力バッファの先頭アドレスを引数*dtとして受信する(行番号#0)。

UTF-8バイトストリームとunicodeとの対応表１００２に示すように、utf-8では、任意の1バイトのMSB側ビット(most significant bit)を確認することにより、処理対象とするバイトストリームが、1byte文字(＝ASCII)か、マルチバイト文字の先頭か、もしくはマルチバイトの途中のバイト位置かを判定することができる。図８に示すデコード処理コード１００１では、行番号#12において1バイト目のビット反転を取得し、続く行番号#13においてMSB側から数えて連続する0ビットを数え上げるclz()命令(counting leading zeroes)を発行している。すなわち、1byte文字種の場合にはi=0が代入され、2byte文字種の場合には2が代入され、3byte文字種の場合には3が代入され、4byte文字種の場合には4が代入される。本処理により、resultには、unicodeの25bit分の情報が格納され、呼び出し元に返される。

留意すべき点は、デコード処理コード１００１の場合、制御内容に依存する分岐命令が使われていない点である。一般に、SIMD型の演算コアを活用する場合において、制御内容に依存する処理が発生すると、実効性能（effective performance）が低下する。しかし、本実施例のように制御内容に依存した分岐命令が使われない場合、実効性能の低下がない。

また、本実施例のデコード処理コード１００１の場合、マルチバイト文字の途中のバイト(例えば“10xx_xxxx”)や5バイト以上の不正なUTF-8エンコードに対し、エラー値「-1」を返す処理を採用する（行番号#5, 9, 10, 11）。utf-8のマルチバイト文字を含むXMLファイルを処理対象とする場合には、いずれも呼び出し元において、これらのデータに対する処理を実行しないようにエラー値の読み飛ばしを実装する必要がある。

図９に、値検証処理９１４ａ（図７）において、有限長の正規表現によるマッチング処理に使用する内部マッチングテーブルと、対応する処理対象データおよびスキーマ表現の例を示す。

本実施例では、有限の正規表現を判定するために、unicode文字の範囲を示すパターンフィールド１１５１と、各文字の繰り返し出現回数を示す繰り返しフィールド１１５２とを含む有限正規表現テーブル１１５０を設けている。このデータ構造は、デバイスプログラム３１３に含まれている。

図９に示す処理対象データおよびスキーマ表現例１１８０におけるXMLインスタンス１１８１は、XMLファイルの一部を抜き出したものであり、国際送金で用いられる銀行口座番号IBAN (International Bank Account Number)を表している。本領域は、[A-Z]が2文字、[0-9]が2文字、[a-zA-Z0-9]が最短1文字、最長30文字で構成される。本業務データをXMLファイルから検出するため、パターンフィールド１１５１および繰り返しフィールド１１５２には、以下の情報が格納されている。

・終端デリミタ “>”；1文字。｛1100a=1100b=0x3e(“<”), 1120a=1120b=1｝
・文字範囲 “[A-Z]”；2文字。｛1101a=0x41(“A”), 1101b=0x5a(“Z”), 1121a=1121b=2｝
・文字範囲 “[0-9]”；2文字。｛1102a=0x30(“0”), 1102b=0x39(“9”), 1122a=1122b=2｝
・文字範囲 “[a-zA-Z0-9]”；1〜30文字。｛1103a=0x61(“a”), 1103b=0x7a(“z”), 1103c=0x41(“A”), 1103d=0x5a(“Z”), 1103e=0x30(“0”), 1103f=0x39(“9”), 1123a=1, 1123b=30｝
・開始デリミタ “<”；1文字。｛1104a=1104b=0x3c(“<”), 1124a=1124b=1｝

正規表現のパターンマッチング処理に際しては、上記のデータ構造を上から順番に、すなわち(1100＆1120 → 1101＆1121 → 1102＆1122 → 1103＆1123 → 1104＆1124)の順にチェックし、XMLデータのバリデーション処理を行う。バリデーション処理の詳細については、図１０を用いて説明する。

なお、図９で網掛けを付した部位(例えば1100c, 1100d)は、マッチングしない無効なエントリを示している。例えば図９の場合、最小のデータコードを示す1100cに、最大のデータコードを示す1100dよりも大きい値(例えば0xff)を格納し、後述するマッチング処理（図１１）で読み飛ばされるように設定する。

図１０に、前述のデータ構造（図９）を用いた有限の正規表現マッチング処理について詳述する。図１０に示す処理は、各プログラムスレッド９０２ａ〜９０２ｚ（図７）の値検証処理９１４ａ〜９１４ｚにそれぞれ相当し、各スレッドが並列に処理を開始する（ステップ１２００)。

各プログラムスレッドは、内部変数resultAllを1(合格)に初期化し(ステップ１２０１)、valuelenを0に初期化する(ステップ１２０２)。次に、各プログラムスレッドは、パターンフィールド１１５１（図９）から1行分のデータを取得する(ステップ１２１１ａ)。初回であれば、データ１１００(図９の１１００ａ〜ｚ)を取得する。また、各プログラムスレッドは、繰り返しフィールド１１５２（図９）から1行分のデータを取得する(ステップ１２１１ｂ)。同じく初回であれば、各プログラムスレッドは、エントリ１１２０ａおよび１１２０ｂを取得する。

次に、各プログラムスレッドは、パターンフィールド１１５１および繰り返しフィールド１１５２のデータに関し、全行分の処理が完了したか否かを判定する(ステップ１２１２)。全行分の処理が完了している場合、処理結果は内部変数resultAllおよびValuelenに格納されているため、それらを呼び出し元に返す(ステップ１２９１)。このとき、Valuelenには業務値の前後の終端デリミタおよび開始デリミタの各1文字分も加えた数値が格納されている。このため、呼び出し元への送信前に、値部分のみを取り出す処理を実行する。

全行分の処理が完了していない場合（すなわち、未処理のデータが残存している場合）、各プログラムスレッドは、内部変数result1を0に初期化すると共に(ステップ１２０３)、繰返し回数iを初期化する(ステップ１２２２)。

これ以降、各プログラムスレッドは、パターンフィールド１１５１および繰返しフィールド１１５２の1行分を処理対象とする。まず、各プログラムスレッドは、繰り返し回数iが最大回数を超えたか否かを判定する（ステップ１２４１）。繰返し回数が最大の繰返し回数(例えばエントリ１１２０ｂの値)を超えている場合、各プログラムスレッドは、次の行の処理に進む。次のステップ１２２１において、各プログラムスレッドは、図８で説明したutf8デコード処理９１３ａ経由で1文字分のデータを取得する。取得した1文字について、各プログラムスレッドは、図１１で後述するサブルーチンにおいて、1行分のパターンフィールド(例えば1100)と比較し、結果Ａを受信する（ステップ１２３１）。このとき、結果Ａには、(1100a,1100b)〜(1100y,1100z)のいずれかのフィールドにマッチしている場合に「1」が、いずれの範囲にもあてはらまない場合に「0」が格納される。

次のステップ１２４２において、各プログラムスレッドは、結果Ａが1(合格)か否かを判定する。結果Ａが1(合格)の場合、各プログラムスレッドは次のステップに進み（ステップ１２４３）、内部変数valuelenの加算処理を実行する。さらに、各プログラムスレッドは、条件付きで内部変数result1の更新処理を実行し(ステップ１２４４、１２３２)、その後、繰り返し回数を更新する(ステップ１２３３)。ここで、ステップ１２４４の条件判定は、繰り返し回数iが最小回数以上か否かにより行なう。繰り返し回数iの更新後、ステップ１２４１から始まる次文字の取得及び処理が実行される。

なお、ステップ１２４２の判定で結果Aが0であった場合、各プログラムスレッドは、パターンフィールド（例えば1100）内のいずれの範囲にも合致しなかった場合と同様、次の行のパターンマッチング処理に移行する。その際、各プログラムスレッドは、ステップ１２８１において、result1の値に“resultAll”を結果AとのAND条件で反映させる。例えばいずれかの行のパターンマッチングにおいて、最小の繰返し回数を満たさずにステップ１２８１に移行した場合、結果Aはステップ１２４２で「0(不適)」に設定されている。このため、各プログラムスレッドは、本スレッドの処理結果は不適であるとし、result1に「0」を設定する。このことから、本スレッドに与えられたバイト位置からでは、パターンマッチングしないことが分かる。

図１１に、図１０のステップ１２３１で実行される処理動作の詳述を示す。本ステップ１３００は、パターンフィールド１１５１の1行分のデータ(例えば1100)と、入力ファイルの特定の1文字を比較し、いずれかの範囲情報にマッチングしている場合に1(合格)を返す処理を行う。

まず、各プログラムスレッドは、ステップ１３０１において、内部変数result2を0(不適)に初期化する。さらに、各プログラムスレッドは、パターンフィールド１１５１の1行分を取得する処理（ステップ１３０２）、評価対象の入力文字データの1文字分(“D”と例示)を受信する（ステップ１３０３）。

続く、ステップ１３０４において、各プログラムスレッドは、1範囲分の情報ペアを取得する。例えばエントリ１１００ａの”>”およびエントリ１１００ｂの”>”を取得する。次に、各プログラムスレッドは、1行分のデータ処理を全て完了したか否か判定する（ステップ１３１１）。1行分のデータ処理が完了していない間、各プログラムスレッドは、入力データと範囲情報ペアを比較し、結果をcomp_resultに格納する（ステップ１３１２）。例えば文字コードの比較として、(1100a <= D && D <= 1100b)を想定し、両端を含むものとする。“D”が期待する範囲の文字の場合、comp_resultには1(合格)が、範囲外の場合 comp_resultには 0(不適)が格納される。

次に、各プログラムスレッドは、result2に、comp_resultを論理和（OR）条件で格納する（ステップ１３１３）。すなわち、正規表現において複数の文字範囲が指定されている場合において、指定された複数の文字範囲のうちいずれか１つの範囲について合致が検出されたとき、各プログラムスレッドは、result2を合格(1)側に倒す。

以上の処理を1行分の全ての情報ペア分繰り返すと(ステップ１３１１で肯定結果)、各プログラムスレッドは、評価結果result2を呼出元に返却する。

（列挙型・固定長文字列のマッチングに用いるデータ構造の例）
図１２に、列挙型・固定長文字列のマッチングに用いるデータ構造の例を示す。本データ構造は、PFAC(Parallel Failureless Aho-Corasick algorithm)と呼ばれるアルゴリズムに基づいており、列挙型の文字データの検索を並列化する際に有用である。

本グラフの場合、各プログラムスレッドが1文字ずつ入力ファイルを読み込んでいく際に本グラフを辿り、final stateの箇所に到達した時点で”AB”, “ABG”, “BEDE”, “ED”の4パターンのいずれかの文字列を発見する（非特許文献２）。本グラフは、デバイスプログラム３１３の内部に設けられている。本グラフの生成に必要な列挙型文字列の情報は、値検査パターン３１４の内部に有する。値検査パターン３１４の具体例については図１６で説明する。

（年月日の処理）
図１３及び図１４に、年月日の処理内容について説明する。処理データとスキーマ表現1600に例示したように、XML内では年月日表現が多用される。ただし、そのマッチングに必要な処理内容は複雑である。図１３では、うるう年判定を例に処理データフローを概観し、図１４にうるう年判定の処理を擬似コードの形態で示す。

XMLインスタンス１６０１は、「2009/9/28」の年月日と、「14:07:00」の時刻を示す部分文字列である。XMLスキーマによる値表現１６０２においては、年号規定１６０３が“‘-‘?yyyy”とのみ示されているが、この意味するところは以下の通りである。
・紀元前を示すマイナス記号が一文字付いても良い
・4桁以上の10進文字列として表現される。
・西暦ゼロ(“0000”)年は許可しない。

しかし、通常のオンラインシステムで扱う年号は1900〜2100年程度を想定しておけば十分実用に耐えると考えられる。そこで、紀元前の表現は処理対象とせず、常に4桁の表記が用いられると考えて値検証処理９１４ａ〜ｚの高速化を図る。

処理イメージ１６１０は、デバイス部２０５（図２）における年号部分に対応する入力データ１６１１ａのutf-8デコード処理(処理１６１１ｂ)に対応する。このデコード処理に、図９〜図１１に詳述した有限正規表現パターンマッチングを併用し、年号データ箇所に[0-9]の文字範囲しかないことを確認する前提で、数値の取り出しを容易化する(処理１６１２：bitwise AND処理)。

各桁の数値を組合せ、かつ、bit演算を行うことで以下の情報を各1ビットのデータ形式で取り出すことが可能である。
・400で割り切れない(処理１６２３ａ)。
・4で割り切れない(処理１６２３ｂ)。
・100で割り切れない(処理１６２３ｃ)。
・西暦0年でない(処理１６２３ｄ)。

図１３の方針に従い、うるう年判定で使用するうるう年判定擬似コード１７００の例を図１４に示す。図１４の場合、行番号#0〜#5に、前述の処理１６２３ａ〜１６２３ｄの各ビットの情報を格納する構造体を設けている。また、行番号#6に、本関数のプロトタイプを宣言する。本例の場合、第1引数に入力ファイルデータへのポインタを、第2引数に処理１６２３ａ〜１６２３ｄの情報を格納するスクラッチエリアを設け、返値にうるう年の適否を返す(1＝うるう年に該当、0＝該当しない)。

行番号#9〜#12では、各年月日の桁の文字コード(ASCIIを想定)に対し、0x0F(0b1111)とのbitwise AND処理を適用し、各10進桁の値を取り出す。さらに、行番号#13〜15では、1000〜100の2桁、10〜1の2桁、1000〜1の4桁を10進変数に取り出す。行番号#16、#17では、400で割り切れた場合にゼロとなる変数、4で割り切れた場合にゼロとなる変数を生成し、最終的に行番号#21〜#24で「0」との比較(典型的にはcomp命令に変換される)を実施する。

行番号#25は、うるう年の判定方法である、｛4で割り切れる年 かつ (100で割り切れない OR 400で割り切れる)｝を論理積と論理和で表現している。

本処理でも、図８の場合と同様に、制御内容に依存の処理を排除した表現方法が可能となっている。

（デバイス部で保持する値パターン情報）
図１５〜図１６では、有限正規表現(ID=3)、十進表現(ID=4)、列挙型(ID=5)、文字列string(ID=1)の各データ表現に対する、値検査パターン３１４（図３）のデータ格納形式を例示する。なお、本明細書の参照者の理解を助けるため、図１５及び図１６においては、リーダビリティの高い表現形式を用いている。しかし、必ずしも図１５及び図１６に示す表現に限るものではない。例えば、テキスト形式でなくバイナリ形式で格納する方法、RDB(relational database)等のデータストアに格納する方法、正規表現形式に関しては図９で示したマッチングテーブル形式を直接採用する方法も考えられる。いずれの亜種のデータ形式に関しても同業者であれば容易に想像できるため、本発明の範囲に含めるものとする。

なお、ID＝2(dateTime)、ID=6(boolean)については、ユーザ(アプリケーション開発者)がカスタマイズする余地が少ないため、明示的に入れ替え可能なデータ領域(値検査パターン３１４)には格納していない。

ID=3(有限正規表現、FLRE: finite length regular expression)に関する値パターン情報の例を符号１７１１〜１７２０に例示する。図１５の場合、値パターン情報は、最大128行の文字列配列から構成されている。しかし、必ずしも128行でなくても構わない。各行は、index番号でアドレッシング可能であり、ユーザが明示的に入れ替えを指示することもできる。図１５の場合、ID列は直感的な理解を助けるために記載しているが、ID別に異なる領域を割り当てる場合には設ける必要は無い。

符号１７１９および１７２０は、ID=2(dateTime)のサポートのために必要なエントリである。ユーザは、ID=2およびID=3の両方にマッチングした場合にのみ、業務データがdateTime形式に合致していると判断できる(図５Ｂの６１２ａおよび６１２ｂを参照)。

ID=4(10進表現、decimal)については、符号１７２１〜１７２４に示す。XMLの10進表現では、トータルの桁数(total)および小数点以下の桁数(fractionDigits)が規定されている。

図１６に、ID=5(列挙型、enumerated)のデータ保持形式の例を示す。列挙型として、enum1〜enumXまでの文字列を格納できる配列を、合計256行保持できる形態としている。例えばIndex=1の場合、”CHK”, “TRF”, “TRA”の3つの文字パターンにマッチングすることを示している。本文字パターンのマッチングには、図１２に示した有向グラフ(PFAC)を用いるのが望ましい。

ID=1(文字列、string)の場合、最小および最大の桁数が決まっている。一方、文字列に採り得る値は、XMLの仕様で固定的に決まっており、値検査パターン３１４（図３）では格納しない。string型の業務値の場合、同一のリーフノードの値が複数のIndexにヒットすることが考えられるが、ホストに対して応答する(デバイス値検査応答キュー３１２)時点で正規化を行い、ホスト部２０４に対するD2H copy３１０のデータ通信量を抑える方法も考えられる。

（値パターン情報のロード／アンロード処理）
図１７に、デバイスプログラム３１３と値検査パターン３１４との間で実行される値パターン情報のロード／アンロード処理の概念を示す。

デバイスプログラム３１３は、動作を開始すると(ステップ２０００)、デバイス値検査処理要求キューからデータを取り出す(ステップ２００１)。次に、デバイスプログラム３１３は、取り出した要求が値検査パターンロード(Request Type（フィールド５０２）= 2)か否か判定し(ステップ２０１１)、肯定結果が得られた場合、値パターン情報のロード／アンロード処理に進む。

ステップ２０１２において、デバイスプログラム３１３は、値検査パターンを引数Args[]フィールド５０３から取得する。次に、デバイスプログラム３１３は、引数内で値検査パターンのロード先Indexが指定されているか判定する（ステップ２０１３）。ステップ２０１３で肯定結果の場合、デバイスプログラム３１３は、値検査パターン３１４中の指定されたIndex箇所のパターンデータを上書きする(ステップ２０１４)。一方、ステップ２０１３で否定結果の場合、デバイスプログラム３１３は、空いているIndexを探してパターンをロードし、空いていない場合には上書きを行う(ステップ２０１５)。ステップ２０１４又はステップ２０１５の実行後、デバイスプログラム３１３はロードを終了する（ステップ２０９０）。

なお、ステップ２０１１で否定結果が得られた場合、デバイスプログラム３１３は、前述のステップ２０１２以降を実行することなく、値検査処理に移行する（ステップ２０９１）。

以上の処理手順により、XML電文処理に先立って、必要な値パターンを値検査パターン３１４にロードし、デバイスプログラム３１３に供給することが可能になる。

（ステップ１１５の処理内容）
図１８に、ステップ１１５（図１）の処理内容、すなわち構造化電文から所定の値パターンを抽出する処理内容を詳述する(ステップ２１０１〜２１０５)。まず、ステップ２１０１において、デバイス部２０５は、内部変数Min_lengthに処理対象の電文を構成する文字の最短のコード長をセットする。本例では、utf8を前提としているので、1バイトのコード長を意味する「1」をセットする。

次のステップ２１０２において、デバイス部２０５は、配列Start_offset[i=0...n]に対し、(Min_length*i)をセットする。本処理により、配列Start_offset[]には、先頭から0、1、2、、、と昇順に1ずつ加算された整数が入る。本配列が、後述するスレッド単位での処理対象データ位置を保持する。

次のステップ２１０３において、デバイス部２０５は、｛受信したXML文書サイズ／Min_lengthで与えられる個数｝だけプログラムスレッドを起動する。プログラムスレッドは、デバイス部２０５における処理の実行主体である。演算コア群２２１及びデバイスメモリ２２２の許す限り、各プログラムスレッドは並列に実行される。本スレッド単位での並列処理は、デバイスカード２２４の処理として実現される場合もあるし、サーバプログラム３０２とデバイスカード２２４の連携で実現される場合もあり得る。

以上の処理により、デバイス部２０５において、値パターンを抽出することができ、後続するステップ１１６（値パターンと検出位置を対応付けて値検証情報を生成し、ホスト部２０４に応答する）の制御に移行する。

（ステップ１１６の処理）
図１９に、デバイスプログラム３１３（図３）において実行される値検査処理１１６の詳細をサブステップ毎に示す(ステップ２２０１〜２２０８)。

デバイスプログラム３１３は、ステップ２２０１において、入力バッファ９１２ａ〜９１２ｚに、XMLインスタンスの処理対象位置のデータを読み込む。本処理は、図７に示した入力バッファ９１２ａ〜ｚにデータを取り込む処理に相当する。

次のステップ２２０２においてデバイスプログラム３１３は、取り込んだ入力バッファ９１２ａ〜ｚのデータ(文字コード)のデコード処理を実行する。本処理の内容は、図８に示したutf-8デコード処理の擬似プログラムに相当する。

続くステップ２２０３及び２２０４において、デバイスプログラム３１３は、有限処理マッチングテーブル(１１５０相当)の参照と、マッチング処理を試みる。マッチング処理２２０４は、前述の図１０及び図１１に相当する。本処理により、データタイプ「1. string」、「3. FLRE」、「4. decimal」のマッチング処理が実行される。

次に、ステップ２２０５及び２２０６において、デバイスプログラム３１３は、列挙型・固定型文字用の有向グラフの参照(図１２相当データ)、およびPFACベースのマッチング処理を実行する。本処理により、データタイプ「5. enumerated(列挙型)」のマッチング処理が実行される。

次に、ステップ２２０７において、デバイスプログラム３１３は、年月日データの判定処理を実行する。本処理は、図１３及び図１４に前述した処理に相当する。本処理において、データタイプ「2. dateTime」のマッチング処理が実行される。

前述のステップ２２０３〜２２０７では、本明細書の読者の理解を容易にするために、逐次的な処理の流れを仮定して示したが、データタイプ別に並列的に処理を行っても構わない。

最後に、ステップ２２０８において、デバイスプログラム３１３は、マッチング処理の結果をまとめ上げ、デバイス値検査応答キュー３１２(図３)へ結果をエンキューする。

（ステップ１１３ａ（図１）の処理）
図２０に、ステップ１１３ａ（図１）で実行される値パターンのロード／アンロード指示の処理をサブステップに分けて詳述する(ステップ２３０１〜２３０６)。

ステップ２３０１において、ホスト部２０４は、ネットワークから受信した構造化電文(インスタンス)から、ネームスペース識別子を取得する。図４Ａの場合、ホスト部２０４は、ネームスペース識別子として “urn:iso:std:iso:20022:tech:xsd:pain.001.001.03”を抽出する。

次のステップ２３０２において、ホスト部２０４は、抽出したネームステース識別子に対応するXMLスキーマを特定する。前述のネームスペース識別子“urn:iso:std:iso:20022:tech:xsd:pain.001.001.03”に対応するXMLスキーマは、図４Ｂに例示した。

次のステップ２３０３において、ホスト部２０４は、XMLスキーマ定義４３１(図４Ｂ)から要素定義４３３を抽出する。要素定義４３３を参照することにより、受信した構造化電文が採り得る要素のデータタイプおよび親子関係(＝木構造)を特定することができる。なお、構造化電文の受信の都度、XMLスキーマの要素定義４３３を評価していると、処理時間が長大になる。このため、ネームスペース識別子に対応して要素のデータタイプおよび親子関係を事前に抽出しておき、処理を高速化するのが望ましい。

次のステップ２３０４において、ホスト部２０４は、デバイス部２０５に対してロード済みの値検査パターン３１４と、前ステップ２３０３において抽出された要素定義４３３とを比較し、ロードされていない値検査パターン(＝不足している要素定義)を特定する。不足がない場合、特に値パターンのロード・アンロード指示は不要でステップ３１２以降の処理に移行する。

一方、値パターンに不足がある場合、ステップ２３０５において、ホスト部２０４は、一旦ロード済みの検査パターンを全てアンロードする。次に、ホスト部２０４は、ステップ２３０６において、必要な要素定義の値パターン(type＝1〜6)を生成し、ロードを指示する。なお、処理の高速化の観点からは、ステップ２３０５〜２３０６において、不足している値パターンのみを追加でロードする方式も考えられるが、同業者であれば容易に類推できるため本発明の範疇に含めるものとする。

以上により、任意のネームスペース識別子を有する構造化電文を受信した際にも処理に必要な値検査パターンをオンデマンドにデバイス部２０５にロードでき、処理を継続可能としている。

２０１…電文処理システム(サーバ)
２０２…電文ネットワーク
２０３…ネットワークストレージ(SAN/NAS)
２０４…ホスト部
２０５…デバイス部
２１１…外部I/F (PCI express)
２１２…内部ストレージ(SAS/SATA)
２１３…内部I/F (PCI express)
２１４…ＣＰＵ
２１５…メモリI/F
２１６…主記憶
２２１…演算コア群
２２２…デバイスメモリ
２２３…広帯域メモリI/F
２２４…デバイスカード
３００…クライアント
３０１…他システム
３０２…サーバプログラム
３０３…キュー・流量制御モジュール
３０４…スキーマ解釈モジュール
３０５…XMLインスタンス／値検査パターン送付
３０６…検査結果取得
３０７…ホスト値検査要求キュー
３０８…ホスト値検査応答キュー
３０９…H2D(host to device) copy
３１０…D2H(device to host) copy
３１１…デバイス値検査要求キュー
３１２…デバイス値検査応答キュー
３１３…デバイスプログラム(値検査処理)
３１４…値検査パターン
３２１…XMLインスタンス送付
３２２…構文解析結果応答
３２３…パーサプログラム

Claims (8)

1. ＣＰＵ、主記憶、外部インタフェースを有するホスト部と、複数の演算コア、デバイスメモリを有するデバイス部とを有する電文処理システムを用いた構造化電文処理方法であって、
   前記ホスト部が、前記外部インタフェースから非定型の構造化電文を受信するステップと、
   前記ホスト部が、受信した前記構造化電文を前記デバイス部に転送するステップと、
   前記ホスト部が、前記構造化電文の文書構造を解析（パーシング）し、同時並行的に、前記デバイス部が、前記構造化電文に含まれる値パターンを検証（バリデーション）するステップと、
   前記デバイス部が、検証された前記値パターンと前記構造化電文中の位置とを含む値検証情報を前記ホスト部に応答するステップと、
   前記ホスト部が、前記文書構造の解析結果と前記値検証情報とを参照し、前記構造化電文の妥当性を判断するステップと
   を有する構造化電文処理方法。
2. 請求項１に記載の構造化電文処理方法において、
   前記デバイス部が、前記構造化電文に含まれる値パターンを検証するステップは、
   前記デバイス部が、
   前記値パターンの検証処理の開始位置を前記構造化電文中に複数設定するステップと、
   前記開始位置と前記演算コアとを対応付けるステップと、
   各演算コアで値検証処理を並列的に実行するステップと
   をさらに有することを特徴とする構造化電文処理方法。
3. 請求項２に記載の構造化電文処理方法において、
   前記デバイス部が、前記値パターンの検証処理の開始位置を前記構造化電文中に複数設定するステップは、
   前記デバイス部が、前記構造化電文で採用されている文字コードセットの最短の長さを参照し、前記構造化電文の先頭から前記最短の長さの整数倍に前記開始位置を設定する
   ことを特徴とする構造化電文処理方法。
4. 請求項１に記載の構造化電文処理方法において、
   前記デバイス部は、検証対象とする値パターンの情報（値パターン情報）を前記デバイスメモリ上に保持し、
   前記デバイス部は、前記構造化電文に含まれる値パターンを検証するステップにおいて、前記値パターン情報と前記構造化電文の全体又は一部を比較するステップをさらに有する
   ことを特徴とする構造化電文処理方法。
5. 請求項４に記載の構造化電文処理方法において、
   前記デバイス部は、前記値パターン情報として、文字の範囲情報と本文字の繰り返し出現回数とを前記デバイスメモリ上に複数セット保持し、
   前記デバイス部は、前記構造化電文の一部として１文字を読み出す度に、読み出した１文字を前記値パターン情報と比較するステップをさらに有する
   ことを特徴とする構造化電文処理方法。
6. 請求項４に記載の構造化電文処理方法において、
   前記デバイス部は、前記値パターン情報として、各々１文字の情報を含む複数のノードと、各ノードを接続する有向グラフから構成される状態遷移ツリーを保持し、
   前記デバイス部は、前記構造化電文の一部として１文字を読み出す度に、読み出した１文字を前記状態遷移ツリーと比較するステップとをさらに有する
   ことを特徴とする構造化電文処理方法。
7. 請求項４に記載の構造化電文処理方法において、
   前記デバイス部は、前記構造化電文の一部として１文字を読み出す度に、読み出した１文字を西暦年、月、日、時間情報の順番に比較するステップをさらに有する
   ことを特徴とする構造化電文処理方法。
8. 請求項４に記載の構造化電文処理方法において、
   前記デバイス部は、前記値パターン情報を保持する有限の領域を保持し、
   前記ホスト部が、受信した前記構造化電文を前記デバイス部に転送するステップにおいて、
   前記ホスト部が、
   前記構造化電文からスキーマ識別子を取得する処理と、
   前記スキーマ識別子で規定される１つ以上の値パターンを特定するステップと、
   特定された値パターンの中に、前記デバイス部に保持された前記値パターン情報に含まれていない要素がある場合、対応する値パターン情報を生成して前記デバイス部に転送するステップとをさらに有する
   ことを特徴とする構造化電文処理方法。

Images