(57)【要約】【課題】大量のＸＭＬデータに対する処理を高速化する。【解決手段】ＸＭＬデータ超並列処理システムは、複数のＸＭＬデータ処理装置１０１を備える。各ＸＭＬデータ処理装置１０１は、ＣＰＵ１０４を含むホスト部１３０と、ホスト部１３０に接続された複数のＧＰＵ１１０とで構成される。ホスト部１３０は、電文ネットワーク１０２やネットワークストレージ１０３からＸＭＬデータが分割されたＸＭＬデータを取得する。そして、ホスト部１３０は、取得したＸＭＬデータを更に複数のＸＭＬデータに分割し、ホスト部１３０に接続された各ＧＰＵ１１０に再分割されたＸＭＬデータを分配する。各ＧＰＵ１１０は、各ＧＰＵ１１０の有する複数の計算コアを用いて、ホスト部１３０によって分配されたＸＭＬデータを並列処理し、その処理結果を含む処理結果データをホスト部１３０に送る。ホスト部１３０は、各ＧＰＵ１１０から処理結果データを受け取る。【選択図】図1
2015106293.tif 000002
【特許請求の範囲】
【請求項１】
ホスト部と当該ホスト部に接続された複数の並列処理装置とで構成されるＸＭＬデータ処理装置を複数備えるＸＭＬデータ超並列処理システムであって、
前記各ＸＭＬデータ処理装置のホスト部が、
ＸＭＬデータが分割された分割ＸＭＬデータを取得するデータ取得手段と、
前記データ取得手段によって取得された分割ＸＭＬデータを更に複数の再分割ＸＭＬデータに分割し、当該ホスト部に接続された前記各並列処理装置に当該各再分割ＸＭＬデータを分配するＸＭＬデータ分配手段と、
前記各並列処理装置から処理結果データを接受する処理結果データ接受手段と、
を備え、
前記各ＸＭＬデータ処理装置の各並列処理装置が、
前記各ＸＭＬデータ処理装置のホスト部によって分配された再分割ＸＭＬデータを接受する再分割ＸＭＬデータ接受手段と、
複数の計算コアを有し、当該各計算コアを用いて前記再分割ＸＭＬデータ接受手段によって接受された再分割ＸＭＬデータを並列処理する並列処理手段と、
前記並列処理手段による再分割ＸＭＬデータの処理結果を含む前記処理結果データを前記ホスト部に送出する処理結果データ送出手段と、
を備える、
ことを特徴とするＸＭＬデータ超並列処理システム。
【請求項２】
前記ホスト部のデータ取得手段が、検証対象文字列の位置を示す取得対象位置情報と、ＸＭＬスキーマとを取得し、
前記各並列処理装置の並列処理手段が、
前記各計算コアによる並列処理により、前記取得対象位置情報に基づいて、前記各再分割ＸＭＬデータから検証対象文字列を抜き出す検証対象文字列抜き出し手段と、
前記各計算コアによる並列処理により、前記取得対象位置情報に基づいて、前記ＸＭＬスキーマから各検証対象文字列のデータ型および所定のデータ型についての制約条件を抽出するデータ型抽出手段と、
前記各計算コアの並列処理により、前記検証対象文字列抜き出し手段によって抜き出された各検証対象文字列が前記データ型抽出手段によって抽出されたデータ型に応じた所定の条件を満たし、前記所定のデータ型である場合には更に前記制約条件を満たすか否かを判定する検証手段と、
を有し、
前記各並列処理装置の処理結果データ送出手段が、前記検証手段によって全ての前記検証対象文字列が前記データ型に応じた所定の条件を満たし、前記所定のデータ型である場合には更に前記制約条件を満たすと判定された場合に、全ての前記検証対象文字列を含む処理結果データを前記ホスト部に送出する、
ことを特徴とする請求項１に記載のＸＭＬデータ超並列処理システム。
【請求項３】
ＣＰＵを含むホスト部と当該ホスト部に接続された複数のＧＰＵとで構成されるコンピュータを複数備えるＸＭＬデータ超並列処理システムにおいて、ＣＰＵで実行されるホストプログラムとＧＰＵで実行されるデバイスプログラムとを含むＸＭＬデータ超並列処理プログラムであって、
前記ホストプログラムが、前記各コンピュータのホスト部を
ＸＭＬデータが分割された分割ＸＭＬデータを取得するデータ取得手段と、
前記データ取得手段によって取得された分割ＸＭＬデータを更に複数の再分割ＸＭＬデータに分割し、当該ホスト部に接続された前記各ＧＰＵに当該各再分割ＸＭＬデータを分配するＸＭＬデータ分配手段と、
前記各ＧＰＵから処理結果データを接受する処理結果データ接受手段と、
して機能させ、
前記デバイスプログラムが、前記各ＧＰＵを、
前記各コンピュータのホスト部によって分配された再分割ＸＭＬデータを接受する再分割ＸＭＬデータ接受手段と、
各ＧＰＵの備える複数の計算コアを用いて前記再分割ＸＭＬデータ接受手段によって接受された再分割ＸＭＬデータを並列処理する並列処理手段と、
前記並列処理手段による再分割ＸＭＬデータの処理結果を含む前記処理結果データを前記ホスト部に送出する処理結果データ送出手段と、
して機能させる、
ＸＭＬデータ超並列処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＸＭＬデータを超並列で処理するＸＭＬデータ超並列処理システムおよびＸＭＬデータ超並列処理プログラムに関する。
【背景技術】
【０００２】
今日では、多数の業界で業務データを自動・高速で処理するシステムが使用されている。一方、これらの業務データについて多様化・大容量化が進んでいる。これに伴い、従来のＣＰＵ（Central Processing Unit）での処理の速度では業務データの処理に長時間を要し、実運用に耐えられなくなってきている。
このため、従来画像処理に利用していたＧＰＵ（Graphics Processing Unit）に内蔵されている多数の計算コアの並列処理により高性能化を実現する超並列データ処理システムが普及しつつある。また、ＧＰＵ用の並列マッチングライブラリ（PFAC Library）もオープンソースで公開されている（例えば、非特許文献１参照。）
【０００３】
従来の超並列データ処理システムは、複数のＣＰＵを有するＣＰＵ部と複数のＧＰＵを有するＧＰＵ部とを有する。そして、ＧＰＵ部は複数の計算コアを有する。このような構成の超並列データ処理システムにおいては、電源を投入すると、ＣＰＵ部は業務データを分割して読み込む。そして、ＣＰＵ部を経由してＧＰＵ部で超並列データ処理が２回実行され、処理結果がＣＰＵ部に転送される。ＣＰＵ部は、１回目と２回目の処理結果のコンペア（比較）処理を実行し、差異が存在しない場合は「ＯＫ」を出力し、差異が存在する場合は「ＮＧ」と実際に差異が存在した部分とを出力する。
【０００４】
また、電子文書の意味や構造を記述するためのマークアップ言語としてＸＭＬ（eXtensible Markup Language）が知られている（例えば、非特許文献２と３を参照。）。特許文献１〜３には、ＸＭＬデータを検証する方法が記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−３３１４７９号公報
【特許文献２】特開２００４−３０６５１号公報
【特許文献３】特開２０１２−１９４７６４号公報
【非特許文献】
【０００６】
【非特許文献１】Chen-HsiungLiu, Lung-Sheng Chien, Cheng-Hung Lin, Shih-Chieh Chang, 'PFAC Library - GPU-basedstring matching algorithm. Version 1.1', [online] April, 2011. ［retrieved on 2013-10-8] Retrieved from the Internet :<URL:http://pfac.googlecode.com/files/PFAC_userGuide_r1.1.pdf>.
【非特許文献２】JohnE. Simpson, 'The Naming of Parts', [online] July 25, 2001. ［retrieved on 2013-10-8] Retrieved from the Internet :<http://www.xml.com/pub/a/2001/07/25/namingparts.html>.
【非特許文献３】'ExtensibleMarkup Language (XML) 1.0 (Fifth Edition)', [online] W3C Recommendation 26November 2008. ［retrieved on 2013-10-8] Retrieved fromthe Internet :<http://www.w3.org/TR/REC-xml/>.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来の超並列データ処理システムでは処理対象の業務データが大容量になると１回の超並列データ処理にかかる時間が線形的に増加する。
このため、ペタバイト級以上のビッグデータを入力とする超並列データ処理では１回の処理に数時間〜数週間かかり、処理結果の検証のために同じ処理を２回実施するのは非効率かつ、本来１回で業務データが処理できるところを処理結果の検証のためにその業務データの処理に倍近くかかるといった不都合が生じている。
【０００８】
また、特許文献１および特許文献２に記載の方法ではＤＴＤを用いて業務データの一つであるＸＭＬのデータ検証を実行しているが、特許文献１および特許文献２にはその検証をＧＰＵで処理することにより加速する方法について示されていない。特許文献３に記載の方法ではＸＭＬスキーマを用いてＸＭＬのデータ検証を実行しているが、特許文献３にはその検証をＧＰＵで処理することにより加速する方法について示されていない。
また、ＤＴＤによるＸＭＬの検証では各タグのデータに対してデータ型や値の範囲等の検証を実施することが不可能である。
【０００９】
本発明の目的は、ＸＭＬスキーマを用いた大量のＸＭＬデータの検証処理を含め、大量のＸＭＬデータに対する処理を高速化することができるＸＭＬデータ超並列処理システムおよびＸＭＬデータ超並列処理プログラムを提供することである。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明のＸＭＬデータ超並列処理システムは、
ホスト部と当該ホスト部に接続された複数の並列処理装置とで構成されるＸＭＬデータ処理装置を複数備えるＸＭＬデータ超並列処理システムであって、
前記各ＸＭＬデータ処理装置のホスト部が、
ＸＭＬデータが分割された分割ＸＭＬデータを取得するデータ取得手段と、
前記データ取得手段によって取得された分割ＸＭＬデータを更に複数の再分割ＸＭＬデータに分割し、当該ホスト部に接続された前記各並列処理装置に当該各再分割ＸＭＬデータを分配するＸＭＬデータ分配手段と、
前記各並列処理装置から処理結果データを接受する処理結果データ接受手段と、
を備え、
前記各ＸＭＬデータ処理装置の各並列処理装置が、
前記各ＸＭＬデータ処理装置のホスト部によって分配された再分割ＸＭＬデータを接受する再分割ＸＭＬデータ接受手段と、
複数の計算コアを有し、当該各計算コアを用いて前記再分割ＸＭＬデータ接受手段によって接受された再分割ＸＭＬデータを並列処理する並列処理手段と、
前記並列処理手段による再分割ＸＭＬデータの処理結果を含む前記処理結果データを前記ホスト部に送出する処理結果データ送出手段と、
を備える、
ことを特徴とする。
【００１１】
好ましくは、本発明のＸＭＬデータ超並列処理システムは、
前記ホスト部のデータ取得手段が、検証対象文字列の位置を示す取得対象位置情報と、ＸＭＬスキーマとを取得し、
前記各並列処理装置の並列処理手段が、
前記各計算コアによる並列処理により、前記取得対象位置情報に基づいて、前記各再分割ＸＭＬデータから検証対象文字列を抜き出す検証対象文字列抜き出し手段と、
前記各計算コアによる並列処理により、前記取得対象位置情報に基づいて、前記ＸＭＬスキーマから各検証対象文字列のデータ型および所定のデータ型についての制約条件を抽出するデータ型抽出手段と、
前記各計算コアの並列処理により、前記検証対象文字列抜き出し手段によって抜き出された各検証対象文字列が前記データ型抽出手段によって抽出されたデータ型に応じた所定の条件を満たし、前記所定のデータ型である場合には更に前記制約条件を満たすか否かを判定する検証手段と、
を有し、
前記各並列処理装置の処理結果データ送出手段が、前記検証手段によって全ての前記検証対象文字列が前記データ型に応じた所定の条件を満たし、前記所定のデータ型である場合には更に前記制約条件を満たすと判定された場合に、全ての前記検証対象文字列を含む処理結果データを前記ホスト部に送出する、
ことを特徴とする。
【００１２】
また、本発明のＸＭＬデータ超並列処理プログラムは、
ＣＰＵを含むホスト部と当該ホスト部に接続された複数のＧＰＵとで構成されるコンピュータを複数備えるＸＭＬデータ超並列処理システムにおいて、ＣＰＵで実行されるホストプログラムとＧＰＵで実行されるデバイスプログラムとを含むＸＭＬデータ超並列処理プログラムであって、
前記ホストプログラムが、前記各コンピュータのホスト部を
ＸＭＬデータが分割された分割ＸＭＬデータを取得するデータ取得手段と、
前記データ取得手段によって取得された分割ＸＭＬデータを更に複数の再分割ＸＭＬデータに分割し、当該ホスト部に接続された前記各ＧＰＵに当該各再分割ＸＭＬデータを分配するＸＭＬデータ分配手段と、
前記各ＧＰＵから処理結果データを接受する処理結果データ接受手段と、
して機能させ、
前記デバイスプログラムが、前記各ＧＰＵを、
前記各コンピュータのホスト部によって分配された再分割ＸＭＬデータを接受する再分割ＸＭＬデータ接受手段と、
各ＧＰＵの備える複数の計算コアを用いて前記再分割ＸＭＬデータ接受手段によって接受された再分割ＸＭＬデータを並列処理する並列処理手段と、
前記並列処理手段による再分割ＸＭＬデータの処理結果を含む前記処理結果データを前記ホスト部に送出する処理結果データ送出手段と、
して機能させる。
【発明の効果】
【００１３】
本発明によれば、ＸＭＬスキーマを用いた大量のＸＭＬデータの検証処理を含め、大量のＸＭＬデータに対する処理を高速化することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係るＸＭＬデータ超並列処理システムの構成の一例を示す図である。
【図２】処理対象のＸＭＬデータ（ビッグデータ）の一例を示す図である。
【図３】処理対象に関連するタグ情報、位置情報（ＸＰａｔｈ）、検証対象データおよびtransition_table変数の一例を示す図である。
【図４】処理対象のＸＭＬデータに対するＸＭＬスキーマの一例を示す図である。
【図５】図４の続きの図である。
【図６】クライアント、他システムおよび電文処理装置（サーバ）内部とのデータフローの一例を示す図である。
【図７】本実施形態に係るＸＭＬデータ超並列処理システムの処理フローの一例を示す図である。
【図８】ネットワークを経由して分割されたＸＭＬを受信する処理（図７のステップ７０１）の詳細な処理フローの一例を示す図である。
【図９】ＧＰＵによる処理を実施するための事前処理（図７のステップ７０２）の詳細な処理フローの一例を示す図である。
【図１０】入力するパターン文字列の一例と事前処理で生成されるTransitionTableファイルの一例を示す図である。
【図１１】図６の６４０に記載の情報をデバイス部に送信する処理（図７のステップ７０３）の詳細な処理フローの一例を示す図である。
【図１２】タグ文字列抜き処理（図７のステップ７０４）の詳細なフローの一例を示す図である。
【図１３】取得対象の開始タグおよび終了タグの位置情報を取得する処理（図１２のステップ１２０３）の詳細な処理フローの一例を示す図である。
【図１４】取得対象位置情報に記載されているＸＰａｔｈ毎の開始タグおよび終了タグの位置情報を取得する処理（図１３のステップ１３１５）の詳細な処理フローの一例を示す図である。
【図１５】図１２のステップ１２０３で取得した位置情報からタグ文字列を抜き取る処理（図１２のステップ１２０４）の詳細な処理フローの一例を示す図である。
【図１６】図７のステップ７０４で取得した文字列と検証条件を紐付ける処理（図７のステップ７０５）の詳細な処理フローの一例を示す図である。
【図１７】データ型と対応する数値を示す図である。
【図１８】図７の７０４で取得した文字列に対する検証処理（図７のステップ７０７）の詳細な処理フローの一例を示す図である。
【図１９】ｂｏｏｌｅａｎ型（type[i][j]=2の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図２０】ｄｅｃｉｍａｌ型（type[i][j]=3の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図２１】ｆｌｏａｔ型（type[i][j]=4の場合の例）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図２２】ｄｏｕｂｌｅ型（type[i][j]=5の場合）に対するデータ検証処理の詳細なフローの一例を示す図である。
【図２３】ｄｕｒａｔｉｏｎ型（type[i][j]=6の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図２４】ｄａｔｅＴｉｍｅ型（type[i][j]=7の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図２５】ｔｉｍｅ型（type[i][j]=8の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図２６】ｄａｔｅ型（type[i][j]=9の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図２７】ｇＹｅａｒＭｏｎｔｈ型（type[i][j]=10の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図２８】ｇＹｅａｒ型（type[i][j]=11の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図２９】ｇＭｏｎｔｈＤａｙ型（type[i][j]=12の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３０】ｇＤａｙ型（type[i][j]=13の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３１】ｇＭｏｎｔｈ型（type[i][j]=14の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３２】ｈｅｘＢｉｎａｒｙ型（type[i][j]=15の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３３】ｂａｓｅ６４Ｂｉｎａｒｙ型（type[i][j]=16の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３４】ｎｏｒｍａｌｉｚｅｄＳｔｒｉｎｇ型（type[i][j]=20の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３５】ｔｏｋｅｎ型（type[i][j]=21の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３６】ｌａｎｇｕａｇｅ型（type[i][j]=22の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３７】ＮＭＴＯＫＥＮ型（type[i][j]=23の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３８】Ｎａｍｅ、ＮＣＮａｍｅ、ＩＤ、ＩＤＲＥＦおよびＥＮＴＩＴＹ型（type[i][j]=25〜28または30の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図３９】ＩＤＲＥＦＳおよびＥＮＴＩＴＩＥＳ型（type[i][j]=29または31の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図４０】ｉｎｔｅｇｅｒ型（type[i][j]=32の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図４１】ｎｏｎＰｏｓｉｔｉｖｅＩｎｔｅｇｅｒ型type[i][j]=33の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図４２】ｎｅｇａｔｉｖｅＩｎｔｅｇｅｒ型（type[i][j]=34の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図４３】ｌｏｎｇ型（type[i][j]=35の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図４４】ｉｎｔ型（type[i][j]=36の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図４５】ｓｈｏｒｔ型（type[i][j]=37の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図４６】ｂｙｔｅ型（type[i][j]=38の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図４７】ｎｏｎＮｅｇａｔｉｖｅＩｎｔｅｇｅｒ型（type[i][j]=39の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図４８】ｕｎｓｉｇｎｅｄＬｏｎｇ型（type[i][j]=40の場合）に対するデータ検証処理の詳細なフローの一例を示す図である。
【図４９】ｕｎｓｉｇｎｅｄＩｎｔ型（type[i][j]=41の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図５０】ｕｎｓｉｇｎｅｄＳｈｏｒｔ型（type[i][j]=42の場合）に対するデータ検証処理の詳細なフローの一例を示す図である。
【図５１】ｕｎｓｉｇｎｅｄＳｈｏｒｔ型（type[i][j]=43の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図５２】ｐｏｓｉｔｉｖｅＩｎｔｅｇｅｒ型（type[i][j]=44の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す図である。
【図５３】ファセットと対応する数値の一例を示す図である。
【図５４】ファセットがｅｑｕａｌ（condition[i][j][]の最初の数字が1の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図５５】ファセットがｎｕｍｅｒｉｃ（condition[i][j][]の最初の数字が5の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図５６】ファセットがｌｅｎｇｔｈ（condition[i][j][]の最初の数字が6の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図５７】ファセットがｍａｘＬｅｎｇｔｈ（condition[i][j][]の最初の数字が7の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図５８】ファセットがｍｉｎＬｅｎｇｔｈ（condition[i][j][]の最初の数字が8の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図５９】ファセットがｐａｔｔｅｒｎ（condition[i][j][]の最初の数字が9の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図６０】ファセットがｅｎｕｍｅｒａｔｉｏｎ（condition[i][j][]の最初の数字が10の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図６１】ファセットがｍａｘＩｎｃｌｕｓｉｖｅ（condition[i][j][]の最初の数字が12の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図６２】ファセットがｍａｘＥｘｃｌｕｓｉｖｅ（condition[i][j][]の最初の数字が13の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図６３】ファセットがｍｉｎＩｎｃｌｕｓｉｖｅ（condition[i][j][]の最初の数字が14の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図６４】ファセットがｍｉｎＥｘｃｌｕｓｉｖｅ（condition[i][j][]の最初の数字が15の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図６５】ファセットがｔｏｔａｌＤｉｇｉｔｓ（condition[i][j][]の最初の数字が16の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図６６】ファセットがｆｒａｃｔｉｏｎＤｉｇｉｔｓ（condition[i][j][]の最初の数字が17の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す図である。
【図６７】タグ文字抜き処理で取得したデータをホスト部に送信する処理（図７のステップ７１０）の詳細なフローの一例を示す図である。
【図６８】図７のステップ７１１で表示部またはクライアントに出力するエラーメッセージの一例を示す図である。
【図６９】エラー内容を表示部またはクライアントに出力する処理（図７のステップ７１１）の詳細なフローの一例を示す図である。
【図７０】ロールバック処理（図７のステップ７１３）の詳細なフローの一例を示す図である。
【図７１】デバイス部１４０から受信したデータをネットワーク経由で他システムへ送信する処理（図７のステップ７１４）の詳細なフローの一例を示す図である。
【発明を実施するための形態】
【００１５】
以下、本発明の実施形態に係るＸＭＬデータ超並列処理システムについて図面を参照しながら説明する。
【００１６】
図１は、本発明の実施形態に係るＸＭＬデータ超並列処理システムの構成の一例を示す。
ＸＭＬデータ超並列処理システムは、複数（Ｋ台）のＸＭＬデータ処理装置（サーバ）１０１、入力部の電文ネットワーク１０２とネットワークストレージ（ＳＡＮ（Storage Area Network）／ＮＡＳ（Network Attached
Storage））１０３、出力部の電文ネットワーク１２２とネットワークストレージ（ＳＡＮ／ＮＡＳ）１２３、および表示部１２５を備える。
ＸＭＬデータ処理装置（サーバ）１０１は、ＣＰＵ（中央演算装置）１０４、ホストメモリ（主記憶）１０５、入力部の外部インタフェース（外部Ｉ／Ｆ）１０６、メモリインタフェース（メモリＩ／Ｆ）１０７、入力部の内部ストレージ１０８（ＳＡＳ(Serial Attached SCSI)／ＳＡＴＡ(Serial ATA)）、内部インタフェース（内部Ｉ／Ｆ）１０９、出力部の内部ストレージ１２１（ＳＡＳ／ＳＡＴＡ）、出力部の外部Ｉ／Ｆ１２４、および複数（Ｌ枚、サーバ１０１  １台当たり）のＧＰＵ（並列処理装置）１１０を有する。ＧＰＵ１１０は、デバイスメモリ１１１と、複数の計算コアで構成される計算コア群１１２とで構成される。デバイスメモリ１１１と計算コア群１１２の間は広帯域メモリＩ／Ｆ１１３で接続されている。
入力部の電文ネットワーク１０２と出力部の電文ネットワーク１２２は、単一または複数の金融機関のコンピュータが接続されたネットワークである。
入力部の電文ネットワーク１０２とネットワークストレージ（ＳＡＮ／ＮＡＳ）１０３は外部Ｉ／Ｆ１０６を経由して各ＸＭＬデータ処理装置（サーバ）１０１に接続されており、出力部の電文ネットワーク１２２とネットワークストレージ（ＳＡＮ／ＮＡＳ）１２３は外部Ｉ／Ｆ１２４を経由して各ＸＭＬデータ処理装置（サーバ）１０１に接続されている。また、表示部１２５は、ＧＰＵ１１０を経由して各ＸＭＬデータ処理装置（サーバ）１０１に接続されている。
【００１７】
ＸＭＬデータ処理装置（サーバ）１０１をクライアントとして利用する場合、表示部１２５は例えば検証結果を表示する装置（モニタ）に相当する。その場合、ＧＰＵ１１０の内の１枚がビデオボードに相当する。また、ネットワークストレージ１０３、１２３、内蔵ストレージ１０８、１２１は同一装置であってもよい。
例えば、銀行間同士で送金業務が発生した場合、通信電文が大量に発生する。この通信電文において必要な情報だけを取得したい場合、電文解析処理を実行する。このとき、通信電文の格納場所が電文ネットワーク１０２上、ネットワークストレージ１０３または内蔵ストレージ１０８に相当し、必要な情報の格納場所が電文ネットワーク１２２上、ネットワークストレージ１２３または内蔵ストレージ１２１に相当する。この時、ＸＭＬデータ処理装置（サーバ）１０１は電文解析処理装置に相当する。この電文解析処理の中で超並列処理を実行する装置がＧＰＵ（並列処理装置）１１０に相当する。
【００１８】
図２は、処理対象のＸＭＬデータ（ビッグデータ）の一例を示す。
処理対象データ２０１はビッグデータであるＸＭＬデータの一部である。実際には数十億〜数千兆行を想定している。なお、以下では、処理対象データ２０１をＸＭＬデータ２０１またはＸＭＬという場合もある。
ＸＭＬとはExtensive
Markup Languageの略であり、個別の目的に応じたマークアップ言語群を創るために汎用的に使うことができる仕様である。マークアップ言語とは、コンピュータ言語の一種で、文章の論理的な構造（段落など）や見栄え（フォントサイズなど）に関する指定を、文章とともにテキストファイルに記述するための言語である。ＸＭＬは、拡張可能な言語の一つに分類されるが、その理由は、ＸＭＬを使うことで、使用者は自分たち自身で複数のタグ（<xx>、</yy>等）を定義することができるからである。ＸＭＬの文脈におけるタグとは、文書の断片に意味を付加するための印である。また、２０２は２０１を分割して受信したＸＭＬ（分割ＸＭＬ）の例である。もちろん２０１は２０２の部分を含んでいる。
【００１９】
ＣＰＵ１０４がホストプログラムを実行することによって、データ取得手段とＸＭＬデータ分配手段と処理結果データ接受手段とを備えるホスト部１３０の機能が実現される。また、ＧＰＵ１１０がデバイスプログラムを実行することによって、再分割ＸＭＬデータ接受手段と並列処理手段と処理結果データ送出手段とを備えるデバイス部１４０の機能が実現される。
ホスト部１３０のデータ取得手段は、電文ネットワーク１０２やネットワークストレージ１０３からＸＭＬデータが分割されたＸＭＬデータ（分割ＸＭＬデータ）等を取得する。ＸＭＬデータ分配手段は、データ取得手段によって取得されたＸＭＬデータを更に複数のＸＭＬデータ（再分割ＸＭＬデータ）に分割し、ホスト部１３０に接続された各ＧＰＵ１１０に再分割された各ＸＭＬデータを分配する。
そして、各ＧＰＵ１１０の再分割ＸＭＬデータ接受手段は、ホスト部１３０によって分配されたＸＭＬデータ（再分割ＸＭＬデータ）を受け取る（接受する）。並列処理手段は、各ＧＰＵ１１０の有する計算コア郡１１２（複数の計算コア）を用いて受け取ったＸＭＬデータを並列処理する。処理結果データ送出手段は、その処理結果を含む処理結果データをホスト部１３０に送出する。
ホスト部１３０の処理結果データ接受手段は、各ＧＰＵ１１０から処理結果データを受け取る（接受する）。
【００２０】
ＸＭＬデータ、検証対象文字列の位置を示す取得対象位置情報、およびＸＭＬスキーマ等を取得して、取得対象位置情報に基づいてＸＭＬデータから検証対象文字列を抜き出し、取得対象位置情報に基づいてＸＭＬスキーマに記述されているデータ型とファセット（制約）を抽出し、データ型とファセット（制約）により検証対象文字列が正しいか否か検証する方法を以下で説明する。
【００２１】
図３は、取得対象関連タグ情報３０１、取得対象位置情報（ＸＰａｔｈ）３０２、処理対象データ２０１と取得対象関連タグ情報３０１と取得対象位置情報（ＸＰａｔｈ）３０２とから生成される検証対象データ（出力データ）３０３、および取得対象関連タグ情報３０１を基にtransition_table変数が参照している文字列３０４の一例を示す。
取得対象位置情報（ＸＰａｔｈ）３０２は取得対象情報が存在するタグをＸＰａｔｈで記述したものである。処理対象データ２０１では１行目のDocumentタグがルートタグであり、その子タグにCstmrCdtTrfInitnが存在している。この時、CstmrCdtTrfInitnを示すＸＰａｔｈは“/Document/CstmrCdtTrfInitn”で表現される。ルートタグの前と親タグと子タグとの間にはＸＰａｔｈにおいては“/”で区切る。
取得対象関連タグ情報３０１は、ＸＭＬデータに含まれるタグの内、取得対象位置情報（ＸＰａｔｈ、XML Path Language）３０２に記載されている文字列を“/”を区切りとして分割した文字列を開始タグ“<”および終了タグ“</”を付与して重複なしで辞書順に並び替えたものである。ただし、“<”および“/”は数字やアルファベットよりも前とする。
【００２２】
例えば、図２の処理対象データ２０１、図３の取得対象関連タグ情報３０１、および取得対象位置情報（ＸＰａｔｈ）３０２の”/Documents/CstmrCdtTrfInitn/PmtInf/CdtTrfTxInf/Amt/InstdAmt”を入力とすると、図２の処理対象データ２０１の該当タグ<Documents><CstmrCdtTrfInitn>…<Amt><InstdAmt>の値を拾う。そしてこのときの出力データは”10000000”、…、”900000”である。
また、処理対象データ２０１、取得対象関連タグ情報３０１、および取得対象位置情報（ＸＰａｔｈ）３０２の”/Documents/CstmrCdtTrfInitn/PmtInf/Dbtr/Nm”を入力とすると、図２の処理対象データ２０１の該当タグ<Documents><CstmrCdtTrfInitn>…<Dbtr><Nm>の値を拾い、出力データは”ABC Corporation”、…である。
同じようにして処理対象データ２０１と他のＸＰａｔｈを入力とすると処理対象データ２０１の中から該当するタブに記載された値を取得する。以上から処理対象データ２０１、取得対象関連タグ情報３０１、および取得対象位置情報（ＸＰａｔｈ）３０２から生成される出力データは検証対象データ（出力データ）３０３のとおりである。複数の検証対象文字列が存在する場合、検証対象データ（出力データ）３０３は一つずつ改行されて出力される。
検証対象データ（出力データ）３０３の生成処理の詳細は図７以降で説明する。
また、文字列３０４は、PFAC
Libraryで生成されるTransitionTableファイルからmatched pattern ID、pattern lengthおよびpattern(string literal)を取り出した文字列である。TransitionTableファイルの詳細は図１０で、文字列３０４の生成処理の詳細は図７以降で説明する。
【００２３】
図４および図５は、ＸＭＬスキーマの一例を示す。
このＸＭＬスキーマでＸＭＬデータのタグの値が正しいか検証する。この例ではPmtInfIdタグ（ＸＰａｔｈは”/Documents/CstmrCdtTrfInitn/PmtInf/PmtInfId”４０３）の値において４０４および４０５で７文字のstring（文字列）型であることが宣言されている。また、５０３ではEndToEndIdタグの値が「任意の８文字-４桁の数字-01〜12のいずれか-00〜39のいずれか」の形式であることが、５０４ではInstdAmtタグの値が非負整数であることが宣言されていて、それ以外のファセット（制約）は存在しないことを示している。５０５についてもNmタグの値が文字列型であることが宣言されていて、それ以外のファセットは存在しないことを示している。４０５のpatternファセット（制約）の”.{7}”について”.”は任意の文字、”{7}”はその前にある”.”が七つ連続するということである。また５０３のpatternファセットの”\/”は”/”を、”\d”は数字１桁を、”\d{4}”は数字４桁を、”[1-9]”は1から9までのいずれか一つ、”[0-2]”は0から2までのいずれか一つ、”[0-3]”は0から3までのいずれか一つ、“(0[1-9]|1[0-2])”は01から12までのいずれか一つを示す。
【００２４】
図６は、クライアント６００、他システム６０２およびＸＭＬデータ処理装置（サーバ）１０１内部とのデータフローの一例を示す。
クライアント６００から処理実行命令６０１がＸＭＬデータ処理装置（サーバ）１０１に送信されると、ホスト部１３０はビッグデータ（ＸＭＬデータ）が格納されている他システム６０２と接続し、ＸＭＬデータ、分割部分のＸＰａｔｈ、取得対象関連タグ情報、取得対象位置情報（ＸＰａｔｈ）およびＸＭＬスキーマ（以上６０３）を読み込む。
なお、本実施形態では、取得対象関連タグ情報を他システム６０２から読み込むとするが、他システム６０２から読み込まずにホスト部１３０のＣＰＵ１０４が取得対象位置情報（ＸＰａｔｈ）に基づいて取得対象関連タグ情報を作成するとしてもよい。
【００２５】
図１のとおり、ＸＭＬデータ処理装置（サーバ）１０１にはＬ枚のＧＰＵ１１０が接続されており、デバイスメモリ１１１の容量の約９分の１がＧＰＵ１枚当たりの処理可能なＸＭＬデータの容量の最大値である（例えば、非特許文献１参照。）。つまり、ＸＭＬデータ処理装置（サーバ）１０１  １台においては（デバイスメモリ１１１の容量×Ｌ÷９）を最大としてＸＭＬデータ２０１を分割して読み込む必要がある。分割して読み込む処理の詳細については図７以降で説明する。
読み込んだＸＭＬデータ２０１は、さらに流量制御処理６１１により（デバイスメモリ１１１の容量÷９）を最大として分割される。他システム６０２から読み込んだ取得対象関連タグ情報はＨ２Ｄｃｏｐｙ（ホスト部１３０からデバイス部１４０へデータコピー）６１２され、ＴｒａｎｓｉｔｉｏｎＴａｂｌｅ生成処理６２１（PFAC Libraryの一部）により生成されたＴｒａｎｓｉｔｉｏｎＴａｂｌｅがＤ２Ｈｃｏｐｙ（デバイス部１４０からホスト部１３０へデータコピー）６３０される。ＴｒａｎｓｉｔｉｏｎＴａｂｌｅの詳細は図１０で説明する。
ホスト部１３０にＴｒａｎｓｉｔｉｏｎＴａｂｌｅがコピーされた後、分割したＸＭＬデータ、ＴｒａｎｓｉｔｉｏｎＴａｂｌｅ、取得対象位置情報（ＸＰａｔｈ）、ＸＭＬスキーマがＨ２Ｄｃｏｐｙ  ６４０  される。デバイス部１４０は、取得対象文字列抜き取り処理６５１を実行して得られた文字列に対して、ＸＭＬスキーマによる検証処理１、検証処理２、…６５２を実行する。検証処理にてデータ型等に誤りが存在しなかった場合、取得データはＤ２Ｈｃｏｐｙ  ６６０  される。一方、誤りが存在した場合は検証結果（エラー内容）がＤ２Ｈｃｏｐｙ  ６６０  される。最後にホスト部１３０は取得データを他システム６０２に送信、またはエラー内容をクライアント６００に送信する。
これらについての詳細は図７以降で説明する。
【００２６】
図７は、本実施形態に係るＸＭＬデータ超並列処理システムの処理フローの一例を示す。
ＳＴＡＲＴ７００は、クライアント６００から送信された処理実行命令６０１をＸＭＬデータ処理装置（サーバ）１０１が受信した時点である。ＸＭＬデータ処理装置（サーバ）１０１は他システム６０２からネットワークを経由して分割されたＸＭＬデータ（分割ＸＭＬデータ）２０１を受信する（ステップ７０１）。ＸＭＬデータ処理装置（サーバ）１０１は分割されたＸＭＬデータの受信の際、分割部分のＸＰａｔｈも受信し、ＸＰａｔｈから生成した開始タグを頭に付与する。また、受信の最終行のＸＰａｔｈを他システム６０２に送信し、ＸＰａｔｈから生成した終了タグを終わりに付与する。こうして分割されたＸＭＬも整形式に修正することが可能である。その他、図３の取得対象関連タグ情報３０１、取得対象位置情報（ＸＰａｔｈ）３０２および図４、５のＸＭＬスキーマ（４０１、４０２、５０１、５０２）も読み込む。ステップ７０１の詳細は図８で説明する。
ＸＭＬデータを受信した後、ホスト部１３０およびデバイス部１４０は事前処理を実行する（ステップ７０２）。この事前処理において、図３の取得対象関連タグ情報３０１をデバイス部１４０にコピーし、デバイス部１４０がＴｒａｎｓｉｔｉｏｎＴａｂｌｅを生成し、デバイス部１４０からホスト部１３０にＴｒａｎｓｉｔｉｏｎＴａｂｌｅをコピーする。ステップ７０２の詳細は図９で説明する。
次に、図６の６４０に記載の情報（分割したＸＭＬデータ、ＴｒａｎｓｉｔｉｏｎＴａｂｌｅ、取得対象位置情報、およびＸＭＬスキーマ）をデバイス部１４０に送信する（ステップ７０３）。ステップ７０３の詳細は図１１で説明する。
【００２７】
デバイス部１４０は、６４０に記載の情報を読み込んだ後、タグ文字列抜き取り処理を実行する（ステップ７０４）。この時点で未検証ながらビッグデータ（ＸＭＬ）を解析し、必要なデータは取得したことになる。ステップ７０４の詳細は図１２で説明する。
ステップ７０４で取得した文字列に対して、ＸＭＬスキーマ検証条件の紐付け処理を実行する（ステップ７０５）。ステップ７０５の詳細は図１６で説明する。
ステップ７０４で得られた文字列の個数によりブロック数を設定し、並列処理を実施する（ステップ７０６〜７０８）。並列処理において、ステップ７０４で得られた文字列に対して検証条件を元に正しい値かどうかを検証する（ステップ７０７）。ステップ７０７の詳細は図１８で説明する。
並列処理終了後、検証結果に含まれる誤りの有無により処理が異なる（ステップ７０９）。誤りの有無は図１８で説明する結果フラグflag[][]が0の場合が誤りあり（検証NG）であり、flag[][]が1の場合は誤りなし（検証OK）と定義する。ただしflagが２次元配列になっているのは、ＧＰＵ１１０の搭載枚数および各ＧＰＵ１１０における検証対象文字列の数によるものである。デバイス部１４０は、誤りが存在しなかったＧＰＵ１１０がステップ７０４で取得した文字列をホスト部１３０に送信する（ステップ７１０）。ステップ７１０の詳細は図６７で説明する。
ホスト部１３０は、デバイス部１４０から文字列を受信し、その文字列をネットワーク経由で他のシステム６０２に送信する（ステップ７１４）。ステップ７１４の詳細は図７１で説明する。
【００２８】
一方、デバイス部１４０は、検証結果に誤りが存在した場合、エラーの内容を表示部１２５およびクライアント６００に出力（表示）する（ステップ７１１）。ステップ７１１の詳細は図６９で説明する。また、出力する内容は図６８で説明する。
エラー内容の出力処理の後、リラン処理を実行する。ただし、リラン処理には回数制限（基準値）を設定し、リラン回数が基準値以上かどうか判定する（ステップ７１２）。リラン回数が基準値未満の場合、再度タグ文字列抜き処理から実行する（ステップ７０４）。
一方、リラン回数が基準値に達した場合、リラン処理を中止し、ロールバック処理を実行する（ステップ７１３）。ロールバック処理ではデバイス部１４０に存在するＧＰＵ１１０上のデバイスメモリ１１１の解放を実行する。これによりデバイスメモリにコピーしたＸＭＬデータ２０１、ＴｒａｎｓｉｔｉｏｎＴａｂｌｅ、取得対象位置情報３０２、ＸＭＬスキーマはすべて消去される。ステップ７１３の詳細は図７０で説明する。
ロールバック処理の後は検証結果に誤りが存在しなかったデバイス部１４０から受信した文字列をネットワーク経由で他システム６０２へ送信する（ステップ７１４）。すべての取得文字列の他システム６０２への送信が完了した後は次の業務処理へ続く（ステップ７１５）。
なお、ステップ７０１は本発明のデータ取得手段の例であり、ステップ７０３は本発明のＸＭＬデータ分配手段および再分割ＸＭＬデータ接受手段の例であり、ステップ７０４〜７０８は本発明の並列処理手段の例であり、ステップ７０４は本発明の検証対象文字列抜き出し手段の例であり、ステップ７０５は本発明のデータ型抽出手段の例であり、ステップ７０６〜７０８は本発明の検証手段の例であり、ステップ７１０は本発明の処理結果データ送出手段および処理結果データ接受手段の例である。
【００２９】
以下、各処理の詳細を説明する。
図８は、ネットワークを経由して分割されたＸＭＬを受信する処理（図７のステップ７０１）の詳細な処理フローの一例を示す。
他システム６０２からＸＭＬデータ２０１を受信する前に、内部参照配列変数xmlstream[]を初期化する（ステップ８０１）。この変数はＧＰＵ１１０  １枚毎に一つの要素が与えられる。xmlstreamには、ＸＭＬデータ２０１が分割され、前後に整形式に必要なタグを付与したＸＭＬへのポインタが格納される。ステップ８０１実行後、他システム６０２との通信に必要なソケットを作成（ステップ８０２）、ソケットに名称を付与（ステップ８０３）、他システム６０２からの接続を許可（ステップ８０４）した後、他システム６０２からの接続が開始される（ステップ８０５）。
【００３０】
接続開始後、内部参照配列変数xmlstream[]に対してホストメモリ（主記憶）１０５への確保が実行される（ステップ８０６）。ホストメモリ１０５が確保された後、他システム６０２から最大（デバイスメモリ１１１の容量×Ｌ（ＧＰＵの搭載枚数）÷９）バイトのＸＭＬデータを受信する（ステップ８０７）。この時、受信バイト数が0バイトであるならば（ステップＳ８０８：Ｙｅｓ）、ステップ８０７へ戻って再度受信を試みる。
一方、受信バイト数が0でないならば（ステップＳ８０８：Ｎｏ）、他システム６０２から分割部分のＸＰａｔｈ、取得対象関連タグ情報３０１、取得対象位置情報（ＸＰａｔｈ）３０２およびＸＭＬスキーマ（４０１、４０２、５０１、５０２）を受信する。なお、ＸＭＬデータの先頭を読み込んだ場合、分割部分のＸＰａｔｈは文字”/”を受信する（ステップ８０９）。これら四つの内、少なくとも一つの受信バイト数が0であるならば（ステップ８１０：Ｙｅｓ）、該当する情報のみ再受信を試みる（ステップ８１１）。再受信した情報の受信バイト数が0の場合（ステップＳ８１２：Ｙｅｓ）、ステップ８１１に戻って再度受信を試みる。
ＸＭＬデータ２０１、分割部分のＸＰａｔｈ、取得対象関連タグ情報３０１、取得対象位置情報（ＸＰａｔｈ）３０２およびＸＭＬスキーマ（４０１、４０２、５０１、５０２）がすべて受信されたならば、ＸＭＬデータをさらに最大（デバイスメモリ１１１の容量÷９）バイトのＬ個に分割する（ステップ８１３）。
【００３１】
その後、分割したＸＭＬデータに対して、先頭と最後にタグ情報を付与し、整形式なＸＭＬに修正する。その処理はサーバ１０１に構成されているＧＰＵ１１０の枚数（Ｌ枚）分、以下四つの処理を繰り返す（ステップ８１４〜ステップ８１９）。
一番目の処理はＸＰａｔｈを基に開始タグを作成し、ＸＭＬの頭に付与することである（ステップ８１５）。具体例として図２の２０２の場合、他システム６０２から受信したＸＰａｔｈは、”/Document/CstmrCdtTrfInitn/CdtTrfTxInf”である。この場合、生成される開始タグは”<Document><CstmrCdtTrfInitn>”である。
二番目の処理はＸＭＬの最後の行のＸＰａｔｈを生成することである（ステップ８１６）。図２の２０２の場合、生成されるＸＰａｔｈは”/Document/CstmrCdtTrfInitn”である。
三番目の処理はＸＰａｔｈから終了タグを生成し、ＸＭＬの終わりに付与することである（ステップ８１７）。図２の２０２の場合、付与される終了タグは”</CstmrCdtTrfInitn></Document>”である。
四番目の処理は整形式にタグを付与したＸＭＬを内部参照配列変数xmlstream[i]にコピーすることである（ステップ８１８）。なお、配列の添え字iは（i+1）枚目のＧＰＵ１１０で処理することを示す。以下、配列の添え字iについては同様である。
繰り返し処理終了後、最後にステップ８１６で生成したＸＰａｔｈをＸＭＬデータの受信元（他システム６０２）に送信する（ステップ８２０）。送信が終了すると、事前処理（ステップ７０２）に進む（ステップ８２１）。
【００３２】
図９は、ＧＰＵ１１０による処理を実施するための事前処理（図７のステップ７０２）の詳細な処理フローの一例を示す。
ＸＭＬデータ２０１の受信（ステップ７０１）から引継ぎ（ステップ９００）、内部参照配列変数handle[]を初期化する（ステップ９０１）。この変数はＧＰＵ１１０  １枚毎に一つの要素が与えられる。handleには、PFAC Libraryを利用するためのPFACコンテキストへのポインタが格納される。
続いて、内部参照配列変数d_input_string[]を初期化する（ステップ９０２）。この変数はＧＰＵ１１０  １枚毎に一つの要素が与えられる。d_input_stringには、デバイス部１４０上にコピーされるＸＭＬ（ステップ８１３〜８２０で整形式に修正したＸＭＬインスタンス）へのポインタが格納される。
続いて、内部参照配列変数d_xpath[]を初期化する（ステップ９０３）。この変数はＧＰＵ１１０  １枚毎に一つの要素が与えられる。d_xpathには、デバイス部１４０上にコピーされる取得対象位置情報（ステップ８０９で受信したＸＰａｔｈ）へのポインタが格納される。
続いて、内部参照配列変数d_matched_result[]を初期化する（ステップ９０４）。この変数はＧＰＵ１１０  １枚毎に一つの要素が与えられる。d_matched_resultには、PFAC Libraryで生成されるタグIDへのポインタが格納される。
続いて、内部参照配列変数d_pos[]を初期化する（ステップ９０５）。この変数はＧＰＵ１１０  １枚毎に一つの要素が与えられる。d_posには、PFAC Libraryで生成されるタグIDに対する位置情報（数値）へのポインタが格納される。
続いて、内部参照配列変数d_results[]を初期化する（ステップ９０６）。この変数はＧＰＵ１１０  １枚毎に一つの要素が与えられる。d_resultsには、ステップ７０４で取得した文字列へのポインタが格納される。
続いて、内部参照配列変数schema[]を初期化する（ステップ９０７）。この変数はＧＰＵ１１０  １枚毎に一つの要素が与えられる。schemaには、ステップ７０１で受信したＸＭＬスキーマへのポインタが格納される。
続いて、内部参照配列変数transition_table[]を初期化する（ステップ９０８）。この変数はＧＰＵ１１０  １枚毎に一つの要素が与えられる。transition_tableには、ステップ９１３で生成されるTransitionTableファイルの一部の文字列へのポインタが格納される。
【００３３】
以上、内部参照配列変数の初期化が終了した後、ＧＰＵ１１０の搭載枚数分、以下を繰り返す（ステップ９０９〜ステップ９２２）。
一番目の処理は利用するＧＰＵ１１０を指定することである（ステップ９１０）。二番目の処理は指定したＧＰＵ１１０に対してPFAC Libraryを初期化することである（ステップ９１１）。この処理の中でPFAC
Libraryを利用するためのハンドルを生成しhandle変数に設定する。三番目の処理はパターン文字列をデバイスメモリ１１１に読み込むことである（ステップ９１２）。デバイスメモリ１１１に読み込むパターン文字列の具体例は図３の取得対象関連タグ情報３０１である。ステップ９１２はPFAC Libraryに委任させている。
四番目の処理は読み込んだパターン文字列に対するTransitionTableファイルを生成することである（ステップ９１３）。具体例として、ステップ９１２での入力情報を図１０の１００１とする。この時、ステップ９１３において図１０の１００２を内容とするTransitionTableファイルが生成される。ステップ９１３もPFAC
Libraryに委任させている。
五番目の処理はリラン回数を0に設定することである（ステップ９１４）。六番目から十二番目の処理はそれぞれ内部参照変数d_input_string[i]（ステップ９１５）、d_xpath[i]（ステップ９１６）、d_matched_result[i]（ステップ９１７）、d_pos[i]（ステップ９１８）、transition_table[i]（ステップ９１９）、d_results[i]（ステップ９２０）、schema[i]（ステップ９２１）のデバイスメモリ１１１の確保である。
繰り返し処理終了後は図６に記載の分割したＸＭＬデータ、TransitionTableの一部、取得対象位置情報、ＸＭＬスキーマをデバイス部１４０に送信する処理（ステップ７０３）に進む（ステップ９２３）。
【００３４】
図１０は、PFAC
Libraryに読み込ませるパターン文字列１００１の一例とPFAC Libraryで生成されるTransitionTableファイル１００２の一例を示す。１００２においてタグ列抜き取り処理７０４に必要な部分は[matched pattern ID]、[pattern length]、[pattern(string literal)]の３項目である。
【００３５】
図１１は、図６の６４０に記載の情報をデバイス部に送信する処理（図７のステップ７０３）の詳細な処理フローの一例を示す。
図１１に記載の処理はすべてＧＰＵ１１０の搭載枚数分、繰り返しである（ステップ１１０１〜１１０６）。最初にＣＰＵ１０４のホストメモリ（主記憶）１０５に確保されているＸＭＬ（xmlstream[i]変数）を内部参照変数d_input_string[i]のデバイスメモリ１１１にコピーする（ステップ１１０２）。続いて、取得対象位置情報（ＸＰａｔｈ）を内部参照変数d_xpath[i]のデバイスメモリ１１１にコピーする（ステップ１１０３）。その次に、図９のステップ９１３で生成したTransitionTableファイルを読み込み、matched pattern ID、pattern length、pattern (string literal)の３項目を内部参照変数transition_table[i]のデバイスメモリ１１１にコピーする（ステップ１１０４）。最後に、ＸＭＬスキーマを内部参照変数schema[i]のデバイスメモリ１１１にコピーする（ステップ１１０５）。これらの一連の処理がＧＰＵ１１０の搭載枚数分繰り返した後、デバイス部１４０にてタグ文字列抜き取り処理に進む（ステップ１１０７）。
【００３６】
図１２は、タグ文字列抜き処理（図７のステップ７０４）の詳細なフローの一例を示す。
図１２に記載の処理はすべてＧＰＵ１１０の搭載枚数分、繰り返しである（ステップ１２０１〜１２０５）。最初にＧＰＵ１１０のデバイスメモリに読み込んだＸＭＬとパターン文字列からマッチング結果と位置情報を取得し、それぞれ内部参照変数d_matched_result[i]、d_pos[i]のデバイスメモリ１１１にコピーする（ステップ１２０２）。この処理はPFAC Libraryに委任させている。
その後、具体的に本発明で取得すべき情報（文字列）を特定するために以下の二つの処理を実行する。一つ目はd_matched_result[i]、d_pos[i]、d_xpath[i]（図１１のステップ１１０３）とtransition_table[i]（図１１のステップ１１０４）から取得対象の開始タグと終了タグの位置情報を取得する（ステップ１２０３）。二つ目はステップ１２０３で取得した位置情報と開始タグの長さからタグ値を取得（タグ文字抜き）し、内部参照変数d_result[i]のデバイスメモリ１１１にコピーする（ステップ１２０４）。ステップ１２０３の処理の詳細は図１３で、ステップ１２０４の処理の詳細は図１５で説明する。
【００３７】
図１３は、取得対象の開始タグおよび終了タグの位置情報を取得する処理（図１２のステップ１２０３）の詳細な処理フローの一例を示す。
最初に内部参照変数xpath_pattern[i][][]を定義する（ステップ１３０１）。ここで、３次元配列として定義している理由は、各ＧＰＵ１１０、各ＸＰａｔｈ、そしてＸＰａｔｈに記載されている各タグ名という３次元で値が定まるためである。ＸＰａｔｈに記載されている各タグ名は内部参照変数d_xpath[i]の各行に対して”/”でトークン分割したものである（ステップ１３０２）。分割した情報を３次元配列xpath_pattern[i][][]に設定する（ステップ１３０３）。
【００３８】
例えば、ＧＰＵ１１０の1枚目で処理すると仮定して、取得対象位置情報ＸＰａｔｈが図３の３０２であると仮定する。この場合xpath_patternはそれぞれ以下を参照するポインタである。
xpath_pattern[0][0][0]=”Document”、xpath_pattern[0][0][1]=”CstmrCdtTrfInitn”、 xpath_pattern[0][0][2]=”PmtInf”、 xpath_pattern[0][0][3]=”Dbtr”、 xpath_pattern[0][0][4]=”Nm”、 xpath_pattern[0][1][0]=”Document”、 xpath_pattern[0][1][1]=” CstmrCdtTrfInitn”、 xpath_pattern[0][1][2]= ”PmtInf”、 xpath_pattern[0][1][3]=”CdtTrfTxInf”、 xpath_pattern[0][1][4]=”Cdtr”、 xpath_pattern[0][1][5]=”Nm”、 xpath_pattern[0][2][0]=”Documents”、 xpath_pattern[0][2][1]=”CstmrCdtTrfInitn”、 xpath_pattern[0][2][2]=”PmtInf”、 xpath_pattern[0][2][3]=”CdtTrfTxInf”、 xpath_pattern[0][2][4]=”PmtId”、 xpath_pattern[0][2][5]=”EndToEndId”、 xpath_pattern[0][3][0]=”Document”、 xpath_pattern[0][3][1]=”CstmrCdtTrfInitn”、 xpath_pattern[0][3][2]=”PmtInf”、 xpath_pattern[0][3][3]=”CdtTrfTxInf”、 xpath_pattern[0][3][4]=”Amt”、 xpath_pattern[0][3][5]=”InstdAmt”。
【００３９】
続いて、内部参照変数transition_table[i]を読み込む（ステップ１３０４）。具体例として取得対象関連タグ情報が図３の３０１の場合、transition_table[i]が示す文字列は図３の３０４のとおりとなる。
続いて、内部参照変数pattern_match[i][]を定義する（ステップ１３０５）。ここで、２次元配列として定義している理由は、各ＧＰＵ１１０と各matched pattern IDという２次元で値が定まるためである。
続いて、d_xpath[i]の行数でブロック数を設定（ステップ１３０６）し、transition_table[i]の行数でスレッド数を設定する（ステップ１３０７）。ここでスレッドというのはデバイス部１４０における計算コアにおいてプログラムを実行する最小単位である。また、ブロックとはいくつかのスレッドをまとめたものである。
続いて、ステップ１１０４で取得したmatched pattern IDを成分としてpattern_match[i][]にpattern(string literal)を参照する（ステップ１３０８）。ただし、参照する値はダブルクォーテーション「”」と最初の”<”を取り除いた文字列とする。例えば、ステップ１１０４で取得したtransition_table[0]が図３の３０４の場合、pattern_match[0][0]=”/Amt”、pattern_match[0][1]=”/Cdtr”、…、pattern_match[0][10]=”/PmtInf”、pattern_match[0][11]=”Amt”、…、pattern_match[0][21]=”PmtInf”である。
【００４０】
その後、ステップ１３０６で設定したブロック数およびステップ１３０７で設定したスレッド数により並列処理を実行する（ステップ１３０９〜ステップ１３１４）。並列処理の中ではd_path[i]の各行のトークン分繰り返し処理を実行する（ステップ１３１０〜ステップ１３１３）。この繰り返し件数はxpath_pattern[i][][]の件数に等しい。この繰り返しの中でxpath_pattern[i][][]がpattern_match[i][]と等しいかどうか判定する（ステップ１３１１）。等しい場合、xpath_pattern[i][][]をpattern_match[i][]の成分（数値）に置換する（ステップ１３１２）。
【００４１】
例えば、transition_table[0]が図３の３０４の場合、xpath_pattern[0][][]は以下の通り置換される。
xpath_pattern[0][0][0]=16、xpath_pattern[0][0][1]=14、xpath_pattern[0][0][2]=21、xpath_pattern[0][0][3]=15、xpath_pattern[0][0][4]=19、xpath_pattern[0][1][0]=16、xpath_pattern[0][1][1]=14、xpath_pattern[0][1][2]=21、xpath_pattern[0][1][3]=13、xpath_pattern[0][1][4]=12、xpath_pattern[0][1][5]=19、xpath_pattern[0][2][0]=16、xpath_pattern[0][2][1]=14、xpath_pattern[0][2][2]=21、xpath_pattern[0][2][3]=13、xpath_pattern[0][2][4]=20、xpath_pattern[0][2][5]=17、xpath_pattern[0][3][0]=16、xpath_pattern[0][3][1]=14、xpath_pattern[0][3][2]=21、xpath_pattern[0][3][3]=13、xpath_pattern[0][3][4]=11、xpath_pattern[0][3][5]=18。
【００４２】
以上で並列処理は終了し、数値で置換したxpath_pattern[i][][]とd_matched_result[i]、d_pos[i]とを比較してd_path[i]の各行に対する開始タグおよび終了タグの位置情報を取得する（ステップ１３１５）。ステップ１３１５の詳細は図１４で説明する。ステップ１３１５の終了後、ステップ１２０４の処理へ進む（ステップ１３１５）。
【００４３】
図１４は、取得対象位置情報に記載されているＸＰａｔｈ毎の開始タグおよび終了タグの位置情報を取得する処理（図１３のステップ１３１５）の詳細な処理フローの一例を示す。
最初にd_xpath[i]の行数でブロック数を設定する（ステップ１４０１）。その後、ステップ１４０１で設定したブロック数により並列処理を実行する（ステップ１４０２〜ステップ１４０９）。並列処理の中では最初に配列変数j[]を-1に設定する（ステップ１４０３）。この配列変数j[]の長さはステップ１４０１で設定したブロック数である。その後、d_xpath[i]の各行のトークン分繰り返し処理を実行する（ステップ１４０４〜ステップ１４０７）。この繰り返し処理の中で、最初にj[]の値に1加算する（ステップ１４０５）。その後、d_matched_result[i][j[]]がxpath_pattern[i][][]と等しいかどうか判定する（ステップ１４０６）。等しい場合は次のトークンにおいてj[]の値に1加算して（ステップ１４０５）再度、d_matched_result[i][j[]]がxpath_pattern[i][][]と等しいかどうか判定する（ステップ１４０６）。等しくない場合は同じトークンにおいてj[]の値に1加算して再度、d_matched_result[i][j[]]がxpath_pattern[i][][]と等しいかどうか判定する（ステップ１４０６）。この繰り返し処理が終了した後、d_xpath[i]の各行に対して、d_pos[i][j[]]の値を開始タグ、d_pos[i][j[]+1]の値を終了タグの位置情報として設定する（ステップ１４０８）。
以上で並列処理は終了し、図１３のステップ１３１６つまり図１２のステップ１２０４へ処理が進む。
【００４４】
図１５は、図１２のステップ１２０３で取得した位置情報からタグ文字列を抜き取る処理（図１２のステップ１２０４）の詳細な処理フローの一例を示す。
最初にd_xpath[i]の行数でブロック数を設定する（ステップ１５０１）。その後、ステップ１５０１で設定したブロック数により並列処理を実行する（ステップ１５０２〜１５０５）。並列処理の中においては以下の処理を実行する。
【００４５】
一つ目の処理は各ブロックにおいて、以下の式の値で取得する文字の長さを設定する（ステップ１５０３）。
d_pos[i][j[]+1]-(d_pos[i][j[]]+
transition_table[i][j[]]のpattern length+1)。
【００４６】
二つ目の処理はd_input_string[i]のd_pos[i][j[]]バイト目からステップ１５０３で設定した長さを処理結果d_results[i][]に設定し、ＧＰＵ１１０のデバイスメモリにコピーする（ステップ１５０４）。この処理により、d_results[i][]に検証対象の文字列が参照可能になる。
具体例としてＧＰＵ１１０の1枚目で処理すると仮定して、ＸＭＬデータが図２の２０２、取得対象関連タグ情報が図３の３０１、取得対象位置情報が図３の３０２の場合、d_results[0][]は以下の通りである。
d_result[0][0]=”ABC/4568/2012-09-08”、 d_result[0][1]=”10000000”、 d_result[0][2]=”DEF Electronics”。
【００４７】
これら二つの処理を並列に実行した後は図１２のステップ１２０５へ進み、ＧＰＵの搭載枚数分繰り返した後、検証対象の文字列がすべて取得されたことになる。その後、ステップ７０５に処理が進む。
【００４８】
図１６は、図７のステップ７０４で取得した文字列と検証条件を紐付ける処理（図７のステップ７０５）の詳細な処理フローの一例を示す。
最初にd_xpath[i]の行数でブロック数を設定する（ステップ１６０１）。その後、ステップ１６０１で設定したブロック数により並列処理を実行する（ステップ１６０２〜１６１６）。並列処理の中においては以下の処理を実行する。
一つ目の処理は各ブロックにおいて、データ型type[i][]と条件condition[i][][]を設定する（ステップ１６０３）。これらは、図１７および図５３で記載されているとおり、数値または数値とvalue=”xx”のカンマ区切りで表現される。また、データ型typeは2次元、条件conditionは3次元配列になっているが、typeはＧＰＵ１１０の枚数およびブロック数で、conditionはＧＰＵ１１０、ブロック数およびtype[i][]に応じた一つまたは複数の条件で値が一意に定まるためである。
二つ目の処理は配列変数j[]を0に設定する（ステップ１６０４）。この配列変数j[]の長さはステップ１６０１で設定したブロック数である。
その後、d_xpath[i]の各行のトークン分繰り返し処理を実行する（ステップ１６０５〜ステップ１６０８）。この繰り返し処理の中で、最初にj[]の値に1加算する（ステップ１６０６）。その後、d_xpath[i]のトークンがschema[i]のj[]行目に含まれるかどうか判定する（ステップ１６０７）。含まれる場合（ステップ１６０７：Ｙｅｓ）は次のトークンにおいてj[]の値に1加算して（ステップ１６０６）再度、d_xpath[i]のトークンがschema[i]のj[]行目に含まれるかどうか判定する（ステップ１６０７）。含まれない場合（ステップ１６０７：Ｎｏ）は同じトークンにおいてj[]の値に1加算して再度、d_xpath[i]のトークンがschema[i]のj[]行目に含まれるかどうか判定する（ステップ１６０７）。
【００４９】
この繰り返し処理が終了した後、”type=”という文字列がschema[i]のj[]行目に含まれるかどうか判定する（ステップ１６０９）。含まれる場合（ステップ１６０９：Ｙｅｓ）、type[i][]にschema[i]のj[]行目のtype属性を代入する（ステップ１６１０）。
含まれない場合（ステップ１６０９：Ｎｏ）、type[i][]にschema[i]のj[]+2行目のbase属性を代入する（ステップ１６１１）。後者の場合、図４および図５のとおりＸＭＬスキーマにはファセット（制約）が記載されている。そのため、ファセットを以下の条件でcondition[i][][]に参照させる。
schema[i]のj[]+3行目以降、value属性が存在する行数分繰り返す（ステップ１６１２〜１６１４）。この繰り返しの中でcondition[i][][]にschema[i]のj[]+3行目以降のファセットとvalue属性をカンマ区切りの文字列として参照させる。具体例は図５３の５３０２に記載している。
ただし、type[i][]はデータ型の名前（”xs:string”、”date”等）を代入するのではなく、図１７に記載のとおり、名前に対応する数値が代入される。また、ファセットについてもファセットの名前でなく、図５３の５３０１に記載のとおり、ファセットに対応する数値を参照する。
並列処理の最後にデータ型type[i][]と条件condition[i][][]をデバイスメモリ１１１へコピーする（ステップ１６１５）。
以上で並列処理は終了し、図７のステップ７０６へ処理が進む。
【００５０】
図１７は、データ型と対応する数値を示す。具体例としてＧＰＵ１１０の1枚目で処理すると仮定して、ＸＭＬデータが図２の２０２、取得対象関連タグ情報が図３の３０１、取得対象位置情報が図３の３０２の場合、ＸＭＬスキーマが図４および図５の場合、type[0][]は以下の通りである。
type[0][0]=1、type[0][1]=39、type[0][2]=1。
図５３についての詳細は後で説明するが、condition[0][][]は以下の通りである。
condition[0][0][0]=”9,value=”
.{8}\/\d{4}-(0[1-9]|1[0-2])-[0-3]\d””、condition[0][1][]およびcondition[0][2][]については図５の５０４および５０５から値なし。
【００５１】
図１８は、図７の７０４で取得した文字列に対する検証処理（図７のステップ７０７）の詳細な処理フローの一例を示す。
最初に検証処理の結果に関するフラグflag[i][j]=1（検証OK）に設定し、count変数を0に初期化する（ステップ１８０１）。このフラグも２次元配列になっているのはＧＰＵ１１０の搭載枚数および各ＧＰＵ１１０における検証対象文字列の数によるものである。
続いて、デバイスメモリ１１１から図７のステップ７０５で取得した属性type[i][j]（ステップ１８０２）、condition[i][j][]（ステップ１８０３）、およびステップ７０４で取得したd_results[i][j]を読み込む（ステップ１８０４）。
その後、データ型のチェックを実行するが、チェック対象外のデータ型が存在するため、type[i][j]の値が1、17、18、19、24のいずれかであるかどうか判定する（ステップ１８０５）。値が1、17、18、19、24に対応するデータ型は図１７のとおりstring、anyURI、QName、NOTATION、NMTOKENSである。これら以外のデータ型の場合（ステップ１８０５：Ｎｏ）、チェック処理を実行する（ステップ１８０６）。データ型によるチェック処理の詳細は図１９〜図５２で説明する。
【００５２】
データ型によるチェック処理終了後、フラグflag[i][j]が1（検証OK）かどうかチェックする（ステップ１８０７）。1でない（ステップ１８０７：Ｎｏ、検証NG）の場合はファセット（制約）によるチェック処理（ステップ１８０８〜１８１３）を実行せずに検証処理を終了（ステップ１８１４）し、図７のステップ７０９に進む。
一方、フラグflag[i][j]が1（ステップ１８０７：Ｙｅｓ、検証OK）の場合はcondition[i][j][]の数（iおよびjは固定）だけファセットによる検証処理を実施する（ステップ１８０８〜１８１３）。
ファセットによるチェックについても、チェック対象外のファセットが存在するため、condition[i][j][]の最初の数字（カンマの前の数字）が2、3、4、11のいずれかであるかどうか判定する（ステップ１８０９）。これらのファセットはそれぞれordered、bounded、cardinality、whiteSpaceである。これら以外のファセットの場合（ステップ１８０９：Ｎｏ）、チェック処理を実行する（ステップ１８１０）。ファセットによるチェック処理の詳細は図５４〜図６６で説明する。
ファセットによるチェック処理終了後、繰り返し数をcount変数に代入（ステップ１８１１）し、ファセット名がenumeration（condition[i][j][]の最初の数字が10）でないかつフラグflag[i][j]が1でない（ステップ１８１２：Ｙｅｓ、検証NG）の場合、condition[i][j][]の数による繰り返し処理から脱出する（ステップ１８１２）。
繰り返し処理の終了（ステップ１８１３）、脱出（ステップ１８１２：Ｙｅｓ）またはデータ型チェックの時点で検証NG（ステップ１８０７：Ｎｏ）の場合取得した文字列に対する検証処理は終了（ステップ１８１４）し、文字列の数による並列処理（図７のステップ７０６〜７０８）が終了後、図７のステップ７０９へ進む。
【００５３】
図１９は、ｂｏｏｌｅａｎ型（type[i][j]=2の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が”true”、”false”、”1”、”0”のいずれかであるかどうか判定する（ステップ１９０１）。d_result[i][j]がこれら四つのいずれかでない場合（ステップ１９０１：Ｎｏ）、フラグflag[i][j]を0（検証NG）に設定する（ステップ１９０２）。一方、d_result[i][j]がこれら四つのいずれかである場合（ステップ１９０１：Ｙｅｓ）、特にフラグflag[i][j]を変更しない。以上でデータ型による検証処理は終了（ステップ１９０３）し、図１８のステップ１８０７に進む。
【００５４】
図２０は、ｄｅｃｉｍａｌ型（type[i][j]=3の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が数字形式であるかどうか判定する。具体的には、検証対象文字列が符号部分”(\+|-)?”、整数部分”\d*”、ピリオドと小数部分”(\.\d*)?”の順であるかどうかチェックする（ステップ２００１）。例えば+2.001は検証OKであるが-2.001.01は検証NGである。また、ステップ２００１では”-.”等が検証OKになるので、+、-のいずれかまたはピリオドのみの場合” (\+|-)?\.?”を検証NGにするためのチェックを実行する（ステップ２００２）。ここで、\+は+、\dは数字1文字、\.はピリオド、*は直前の文字の0回以上の繰り返し、?は直前の文字が0回または1回のいずれか、\+|-は+または-のいずれかを示す。ステップ２００１およびステップ２００２で数字として表現不可能な場合（ステップ２００１：Ｎｏ、ステップ２００１：Ｙｅｓ）、フラグflag[i][j]を0（検証NG）に設定する(ステップ２００３)。以上でデータ型による検証処理は終了（ステップ２００４）し、図１８のステップ１８０７に進む。
【００５５】
図２１は、ｆｌｏａｔ型（type[i][j]=4の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が仮数部分と指数部分で表現されているかどうか判定する。
具体的には、まずｆｌｏａｔ型において、型として認められている0、-0、IN、-INF、NaNのいずれかであるかどうか判定する（ステップ２１０１）。検証対象文字列がこれら五つのいずれかである場合（ステップ２１０１：Ｙｅｓ）はフラグflag[i][j]は変更せずにデータ型による検証処理は終了（ステップ２１０６）し、図１８のステップ１８０７に進む。
一方、検証対象文字列がこれら五つのいずれかでない場合（ステップ２１０１：Ｎｏ）は仮数部分(\+|-)?\d+(\.\d+)?と指数部分((E|e)(+\|-)?\d+)?で表現されているかどうか判定する（ステップ２１０２）。ただし、指数部分は省略することが可能である。また、\d+は数字が1文字以上続くことを意味する。例えば-1.01や5.35e+3は仮数部分と指数部分で表現されていると判定される。しかし、2.05e+1.42は仮数部分と指数部分で表現されていると判定されない。ステップ２１０２で仮数部分と指数部分で表現されていると判定されない場合（ステップ２１０２：Ｎｏ）、フラグflag[i][j]を0（検証NG）に設定し（ステップ２１０５）、データ型による検証処理は終了（ステップ２１０６）する。
【００５６】
ステップ２１０２で仮数部分と指数部分で表現されていると判定された場合（ステップ２１０２：Ｙｅｓ）、仮数部分の絶対値が16777216未満であるかどうか判定する（ステップ２１０３）。仮数部分の絶対値が16777216以上の場合（ステップ２１０３：Ｎｏ）はフラグflag[i][j]を0（検証NG）に設定し（ステップ２１０５）、データ型による検証処理は終了（ステップ２１０６）する。
仮数部分の絶対値が16777216未満である場合（ステップ２１０３：Ｙｅｓ）、続いて指数部分が-149×log2以上かつ、104×log2以下であるかどうか判定する（ステップ２１０４）。指数部分についてこれらの条件を満たさない場合（ステップ２１０４：Ｎｏ）はフラグflag[i][j]を0（検証NG）に設定し（ステップ２１０５）、データ型による検証処理は終了（ステップ２１０６）する。指数部分についての条件を満たす場合（ステップ２１０４：Ｙｅｓ）、フラグflag[i][j]を変更せずにデータ型による検証処理は終了（ステップ２１０６）する。ただしlog2は10を底とする対数でおよそ0.301である。
例えば、検証対象文字列が16777215の場合は仮数部分の絶対値が16777216未満なのでステップ２１０３の判定によりフラグの変更は発生しないが、検証対象文字列が16777216の場合はステップ２１０３の判定によりフラグが0（検証NG）に変更される。また、検証対象文字列が1.0E+31の場合は指数部分が104×log2以下であるのでステップ２１０４の判定によりフラグの変更は発生しないが、検証対象文字列が1.0E+32の場合、ステップ２１０４の判定によりフラグが0（検証NG）に変更される。
【００５７】
図２２は、ｄｏｕｂｌｅ型（type[i][j]=5の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が仮数部分と指数部分で表現されているかどうか判定する。
具体的には、まずｄｏｕｂｌｅ型において、型として認められている0、-0、IN、-INF、NaNのいずれかであるかどうか判定する（ステップ２２０１）。検証対象文字列がこれら五つのいずれかである場合（ステップ２２０１：Ｙｅｓ）はフラグflag[i][j]は変更せずにデータ型による検証処理は終了（ステップ２２０６）し、図１８のステップ１８０７に進む。
一方、検証対象文字列がこれら五つのいずれかでない場合（ステップ２２０１：Ｎｏ）は仮数部分(\+|-)?\d+(\.\d+)?と指数部分((E|e)(+\|-)?\d+)?で表現されているかどうか判定する（ステップ２２０２）。ただし、指数部分は省略することが可能である。また、\d+は数字が1文字以上続くことを意味する。例えば-1.01や5.35e+3は仮数部分と指数部分で表現されていると判定される。しかし、2.05e+1.42は仮数部分と指数部分で表現されていると判定されない。ステップ２２０２で仮数部分と指数部分で表現されていると判定されない場合（ステップ２２０２：Ｙｅｓ）、フラグflag[i][j]を0（検証NG）に設定し（ステップ２２０５）、データ型による検証処理は終了（ステップ２２０６）する。
【００５８】
ステップ２２０２で仮数部分と指数部分で表現されていると判定された場合（ステップ２２０２：Ｙｅｓ）、仮数部分の絶対値が253未満であるかどうか判定する（ステップ２２０３）。仮数部分の絶対値が253以上の場合（ステップ２２０３：Ｎｏ）はフラグflag[i][j]を0（検証NG）に設定し（ステップ２２０５）、データ型による検証処理は終了（ステップ２２０６）する。
仮数部分の絶対値が253未満である場合（ステップ２２０３：Ｙｅｓ）、続いて指数部分が-1075×log2以上かつ、970×log2以下であるかどうか判定する（ステップ２２０４）。指数部分についてこれらの条件を満たさない場合（ステップ２２０４：Ｎｏ）はフラグflag[i][j]を0（検証NG）に設定し（ステップ２２０５）、データ型による検証処理は終了（ステップ２２０６）する。指数部分についての条件を満たす場合（ステップ２２０４：Ｙｅｓ）、フラグflag[i][j]を変更せずにデータ型による検証処理は終了（ステップ２２０６）する。
例えば、検証対象文字列が253-1の場合は仮数部分の絶対値が253未満なのでステップ２２０３の判定によりフラグの変更は発生しないが、検証対象文字列が253の場合はステップ２２０３の判定によりフラグが0（検証NG）に変更される。また、検証対象文字列が1.0E+291の場合は指数部分が970×log2以下であるのでステップ２１０４の判定によりフラグの変更は発生しないが、検証対象文字列が1.0E+292の場合、ステップ２１０４の判定によりフラグが0（検証NG）に変更される。
【００５９】
図２３は、ｄｕｒａｔｉｏｎ型（type[i][j]=6の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]がPnYnMnDTnHnMnSの形式かどうか判定する。ここで、Pは期間（period）であり必須である。nYは年数、一つ目のnMは月数、nDは日数、Tは日付と時刻の区切り、nHは時間、二つ目のnMは分、nSは秒である。ただし、Tについてすべての時刻項目がなければ省略可能で、nSのnについては小数点以下の桁を含んでもよい。また先頭に負号(-)を先頭に付けて、負の存続期間を表現することも可能である。以上のことから”-?P(\d+Y)? (\d+M)? (\d+D)? (T(\d+H)?(\d+M)? (\d+(\.\d*)?S)?)?”で表現されているかどうか判定する（ステップ２３０１）。例としてP23Y0M4DT11H52M46SはPnYnMnDTnHnMnSの形式であるが、PYMDT13H59M59.999SはPnYnMnDTnHnMnSの形式でないため、フラグflag[i][j]が0（検証NG）に変更される（ステップ２３０３）。ただし、ｄｕｒａｔｉｏｎ型でない-PTもステップ２３０１のチェックでは正しいと判定されるため、”-?PT?”で表現されているかどうかも判定する（ステップ２３０２）。”-?PT?”で表現される文字列と判定した場合、フラグflag[i][j]が0（検証NG）に変更される。以上の判定で検証処理は終了（ステップ２３０４）し、図１８のステップ１８０７に進む。
【００６０】
図２４は、ｄａｔｅＴｉｍｅ型（type[i][j]=7の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]がCCYY-MM-DDThh:mm:ssの形式かどうか判定する。ここでCCは世紀、YYは年、MMは月、DDは日、Tは日付と時刻の区切り、hhは時間、mmは分、ssは秒である。
最初にステップ２４０１でMMが01〜12、DDが01〜31、hhが00〜23、mmとssが00〜59であることをチェックする。また、ssの後にZ、+hh:mmまたは-hh:mmが付いていてもデータ型として正しいので、これについてもチェックしている。このことからd_results[i][j]が”\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[1-2]\d|3[0-1])T([0-1]\d|2[0-3]):[0-5]\d:[0-5]\d(Z|((+|-)
([0-1]\d|2[0-3]):[0-5]\d))?”で表現されているかどうか判定する。ここで\d{4}は4桁の数字を示し、0[1-9]|1[0-2]で01〜12、0[1-9]|[1-2]\d|3[0-1]で01〜31、[0-1]\d|2[0-3]で00〜23、[0-5]\dで00〜59をそれぞれ示す。この時点で例えば2013-09-00T23:59:59はDDが01〜31にないのでフラグflag[i][j]が0（検証NG）に変更される（ステップ２４０９）。ステップ２４０９を実行した場合はその時点でデータ型の検証処理が終了（ステップ２４１０）し、図１８のステップ１８０７に進む。
続いて、2月、4月、6月、9月、11月には31日が存在しないため、ステップ２４０２でチェックする。この時点で例えば2013-09-31T23:59:59は存在しない日付であるためフラグflag[i][j]が0（検証NG）に変更される（ステップ２４０９）。
【００６１】
続いて、2月の扱いについて、整数型変数yを定義し、d_results[i][j]の最初の4文字を代入する（ステップ２４０３）。次に整数型変数y4を定義し、yを4で割った余りを代入する（ステップ２４０４）。y4が0でない場合、yは4の倍数でないため、その年の2月29日は存在しない。ステップ２４０５ではy4が0でない場合に2月29日でないことをチェックする。この時点で例えば2013-02-29T23:59:59は存在しない日付であるためフラグflag[i][j]が0（検証NG）に変更される（ステップ２４０９）。一方、y4が0の場合、基本的にはうるう年であり2月29日が存在する。しかし、西暦1800年、1900年、2100年等100の倍数であって400の倍数でない年の2月29日が存在しない。そこで整数型変数y400を定義しyを400で割った余りを代入する（ステップ２４０６）。y400が100、200または300である場合、その年の2月29日は存在しない。ステップ２４０７ではy400が100、200または300である場合に2月29日でないことをチェックする。この時点で例えば1900-02-29T23:59:59は存在しない日付であるためフラグflag[i][j]が0（検証NG）に変更される（ステップ２４０９）。最後にすべての年において2月30日は存在しないことをチェックする（ステップ２４０８）。
これらのチェックで存在しない日付はすべてフラグflag[i][j]が0（検証NG）に変更される（ステップ２４０９）。存在する日付および時刻についてはフラグflag[i][j]は変更されず、データ型の検証処理は終了（ステップ２４１０）し、図１８のステップ１８０７に進む。
【００６２】
図２５は、ｔｉｍｅ型（type[i][j]=8の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]がhh:mm:ssの形式かどうか判定する。ここで、hhは時間、mmは分、ssは秒である。hhが00〜23、mmとssが00〜59であることをチェックし、ssの後にZ、+hh:mmまたは-hh:mmが付いていてもデータ型として正しいので、これについてもチェックする（ステップ２５０１）。このチェックで存在しない時刻である場合（ステップ２５０１：Ｎｏ）、フラグflag[i][j]が0（検証NG）に変更される（ステップ２５０２）。例えば24:00:00は存在しない時刻である。このチェックのみで検証処理は終了（ステップ２５０３）し、図１８のステップ１８０７に進む。
【００６３】
図２６は、ｄａｔｅ型（type[i][j]=9の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]がCCYY-MM-DDの形式かどうか判定する。ここでCCは世紀、YYは年、MMは月、DDは日である。
最初にステップ２６０１でMMが01〜12、DDが01〜31であることをチェックする。また、DDの後にZ、+hh:mmまたは-hh:mmが付いていてもデータ型として正しいので、これについてもチェックしている。ここでhhは時間、mmは分である。このことからd_results[i][j]が”\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[1-2]\d|3[0-1]) (Z|((+|-)
([0-1]\d|2[0-3]):[0-5]\d))?”で表現されているかどうか判定する。ここで\d{4}は4桁の数字を示し、0[1-9]|1[0-2]で01〜12を、0[1-9]|[1-2]\d|3[0-1]で01〜31、[0-1]\d|2[0-3]で00〜23、[0-5]\dで00〜59をそれぞれ示す。この時点で例えば2013-09-00はDDが01〜31にないのでフラグflag[i][j]が0（検証NG）に変更される（ステップ２６０９）。ステップ２６０９を実行した場合はその時点でデータ型の検証処理が終了（ステップ２６１０）し、図１８のステップ１８０７に進む。
続いて、2月、4月、6月、9月、11月には31日が存在しないため、ステップ２６０２でチェックする。この時点で例えば2013-09-31は存在しない日付であるためフラグflag[i][j]が0（検証NG）に変更される（ステップ２６０９）。
【００６４】
続いて、2月の扱いについて、整数型変数yを定義し、d_results[i][j]の最初の4文字を代入する（ステップ２６０３）。次に整数型変数y4を定義し、yを4で割った余りを代入する（ステップ２６０４）。y4が0でない場合、yは4の倍数でないため、その年の2月29日は存在しない。ステップ２６０５ではy4が0でない場合に2月29日でないことをチェックする。この時点で例えば2013-02-29は存在しない日付であるためフラグflag[i][j]が0（検証NG）に変更される（ステップ２６０９）。一方、y4が0の場合、基本的にはうるう年であり2月29日が存在する。しかし、西暦1800年、1900年、2100年等100の倍数であって400の倍数でない年の2月29日が存在しない。そこで整数型変数y400を定義しyを400で割った余りを代入する（ステップ２６０６）。y400が100、200または300である場合、その年の2月29日は存在しない。ステップ２６０７ではy400が100、200または300である場合に2月29日でないことをチェックする。この時点で例えば1900-02-29は存在しない日付であるためフラグflag[i][j]が0（検証NG）に変更される（ステップ２６０９）。最後にすべての年において2月30日は存在しないことをチェックする（ステップ２６０８）。
これらのチェックで存在しない日付はすべてフラグflag[i][j]が0（検証NG）に変更される（ステップ２６０９）。存在する日付についてはフラグflag[i][j]は変更されず、データ型の検証処理は終了（ステップ２６１０）し、図１８のステップ１８０７に進む。
【００６５】
図２７は、ｇＹｅａｒＭｏｎｔｈ型（type[i][j]=10の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]がCCYY-MMの形式かどうか判定する。ここでCCは世紀、YYは年、MMは月である。ステップ２７０１でMMが01〜12であることをチェックする。また、MMの後にZ、+hh:mmまたは-hh:mmが付いていてもデータ型として正しいので、これについてもチェックしている。ここでhhは時間、mmは分である。このことからd_results[i][j]が”\d{4}-(0[1-9]|1[0-2])(Z|((+|-)([0-1]\d|2[0-3]):[0-5]\d))?”で表現されているかどうか判定する。ここで\d{4}は4桁の数字を示し、0[1-9]|1[0-2]で01〜12、[0-1]\d|2[0-3]で00〜23、[0-5]\dで00〜59をそれぞれ示す。このチェックで存在しない月である場合、フラグflag[i][j]が0（検証NG）に変更される（ステップ２７０２）。例えば2013-00は存在しない月である。このチェックのみで検証処理は終了（ステップ２７０３）し、図１８のステップ１８０７に進む。
【００６６】
図２８は、ｇＹｅａｒ型（type[i][j]=11の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]がCCYYの形式かどうか判定する。ここでCCは世紀、YYは年である。ステップ２８０１ではCCYYの後にZ、+hh:mmまたは-hh:mmが付いていてもデータ型として正しいので、これについてもチェックしている。ここでhhは時間、mmは分である。このことからd_results[i][j]が”\d{4}(Z|((+|-)([0-1]\d|2[0-3]):[0-5]\d))?”で表現されているかどうか判定する。ここで\d{4}は4桁の数字、[0-1]\d|2[0-3]で00〜23、[0-5]\dで00〜59を示す。このチェックで存在しない年である場合、フラグflag[i][j]が0（検証NG）に変更される（ステップ２８０２）。例えば10000は存在しない年である。このチェックのみで検証処理は終了（ステップ２８０３）し、図１８のステップ１８０７に進む。
【００６７】
図２９は、ｇＭｏｎｔｈＤａｙ型（type[i][j]=12の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が--MM-DDの形式かどうか判定する。ここでMMは月、DDは日である。最初にステップ２９０１でMMが01〜12、DDが01〜31であることをチェックする。また、DDの後にZ、+hh:mmまたは-hh:mmが付いていてもデータ型として正しいので、これについてもチェックしている。ここでhhは時間、mmは分である。このことからd_results[i][j]が”--(0[1-9]|1[0-2])-(0[1-9]|[1-2]\d|3[0-1])(Z|((+|-)
([0-1]\d|2[0-3]):[0-5]\d))?”で表現されているかどうか判定する。ここで0[1-9]|1[0-2]で01〜12を、0[1-9]|[1-2]\d|3[0-1]で01〜31、[0-1]\d|2[0-3]で00〜23、[0-5]\dで00〜59をそれぞれ示す。この時点で例えば--09-00はDDが01〜31にないのでフラグflag[i][j]が0（検証NG）に変更される（ステップ２９０４）。ステップ２９０４を実行した場合はその時点でデータ型の検証処理が終了（ステップ２９０５）し、図１８のステップ１８０７に進む。
続いて、2月、4月、6月、9月、11月には31日が存在しないため、ステップ２９０２でチェックする。この時点で例えば--09-31は存在しない日付であるためフラグflag[i][j]が0（検証NG）に変更される（ステップ２９０４）。続いて、2月には30日が存在しないため、ステップ２９０３でチェックする。この時点で--02-30は存在しない日付であるためフラグflag[i][j]が0（検証NG）に変更される（ステップ２９０４）。以上のチェックでデータ型の検証処理は終了（ステップ２９０５）し、図１８のステップ１８０７に進む。
【００６８】
図３０は、ｇＤａｙ型（type[i][j]=13の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が---DDの形式かどうか判定する。ここで、DDは日である。ステップ３００１でDDが01〜31であることをチェックする。また、DDの後にZ、+hh:mmまたは-hh:mmが付いていてもデータ型として正しいので、これについてもチェックしている。ここでhhは時間、mmは分である。このことからd_results[i][j]が”---(0[1-9]|[1-2]\d|3[0-1])(Z|((+|-)([0-1]\d|2[0-3]):[0-5]\d))?”で表現されているかどうか判定する。ここで0[1-9]|[1-2]\d|3[0-1]で01〜31、[0-1]\d|2[0-3]で00〜23、[0-5]\dで00〜59をそれぞれ示す。このチェックで存在しない日である場合、フラグflag[i][j]が0（検証NG）に変更される（ステップ３００２）。例えば00は存在しない日である。このチェックのみで検証処理は終了（ステップ３００３）し、図１８のステップ１８０７に進む。
【００６９】
図３１は、ｇＭｏｎｔｈ型（type[i][j]=14の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が--MM--の形式かどうか判定する。ここで、MMは月である。ステップ３１０１でMMが01〜12であることをチェックする。また、MMの後にZ、+hh:mmまたは-hh:mmが付いていてもデータ型として正しいので、これについてもチェックしている。ここでhhは時間、mmは分である。このことからd_results[i][j]が”--(0[1-9]|1[0-2])--(Z|((+|-)([0-1]\d|2[0-3]):[0-5]\d))?”で表現されているかどうか判定する。ここで0[1-9]|1[0-2]で01〜12、[0-1]\d|2[0-3]で00〜23、[0-5]\dで00〜59をそれぞれ示す。このチェックで存在しない月である場合、フラグflag[i][j]が0（検証NG）に変更される（ステップ３１０２）。例えば00は存在しない月である。このチェックのみで検証処理は終了（ステップ３１０３）し、図１８のステップ１８０７に進む。
【００７０】
図３２は、ｈｅｘＢｉｎａｒｙ型（type[i][j]=15の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が16進のバイナリデータであるかどうか判定する。具体的には0〜9、A〜F、a〜fの22文字のみで表現されているかどうか判定する（ステップ３２０１）。このチェックで空文字または0〜9、A〜F、a〜fの22文字以外の文字（記号含む）が含まれている場合、フラグflag[i][j]が0（検証NG）に変更される（ステップ３２０２）。例えば”ABCDEFG”は7文字目が”G”であるため16進のバイナリデータではない。このチェックのみで検証処理は終了（ステップ３２０３）し、図１８のステップ１８０７に進む。
【００７１】
図３３は、ｂａｓｅ６４Ｂｉｎａｒｙ型（type[i][j]=16の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]がbase64コードのバイナリデータであるかどうか判定する。具体的には英数字および+、/、=の65文字のみで表現されているかどうか判定する（ステップ３３０１）。このチェックで空文字または英数字、+、/、=の65文字以外の文字（記号等）が含まれている場合、フラグflag[i][j]が0（検証NG）に変更される（ステップ３３０２）。例えば”<AB>”は1文字目および4文字目が英数字でもなく、+、/、=でないため、base64コードのバイナリデータではない。このチェックのみで検証処理は終了（ステップ３３０３）し、図１８のステップ１８０７に進む。
【００７２】
図３４は、ｎｏｒｍａｌｉｚｅｄＳｔｒｉｎｇ型（type[i][j]=20の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]において、キャリッジリターン、行送りあるいはタブ文字を含まない文字列であるかどうか判定する。具体的にはd_results[i][j]が”.*(\r|\n|\t)+.*”で表現されているかどうか判定する（ステップ３４０１）。ここで”.*”は空文字を含む任意の文字列であり、”(\r|\n|\t)+”はキャリッジリターン（\r）、行送り（\n）あるいはタブ文字（\t）の一つ以上の繰り返しである。”.*(\r|\n|\t)+.*”で表現されている場合、フラグflag[i][j]が0（検証NG）に変更される（ステップ３４０２）。例えば”A      （タブ文字）B”はAとBの間にタブ文字が含まれているのでｎｏｒｍａｌｉｚｅｄＳｔｒｉｎｇ型ではない。このチェックのみで検証処理は終了（ステップ３４０３）し、図１８のステップ１８０７に進む。
【００７３】
図３５は、ｔｏｋｅｎ型（type[i][j]=21の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。ｔｏｋｅｎ型はｎｏｒｍａｌｉｚｅｄＳｔｒｉｎｇ型であり、かつ先行あるいは後続のスペースを含まず、内部に複数のスペース列も含まない文字列型である。
最初に検証対象文字列d_results[i][j]が”.*(\r|\n|\t)+.*”で表現されているかどうか判定する（ステップ３５０１）。”.*(\r|\n|\t)+.*”で表現されている場合（ステップ３５０１：Ｙｅｓ）、フラグflag[i][j]が0（検証NG）に変更される（ステップ３５０５）。ステップ３５０５によりフラグflag[i][j]が0（検証NG）に変更された場合、検証処理は終了（ステップ３５０６）し、図１８のステップ１８０７に進む。
一方、”.*(\r|\n|\t)+.*”で表現されていない場合（ステップ３５０１：Ｎｏ）、続いて検証対象文字列d_results[i][j]の先頭文字がスペースかどうか判定する（ステップ３５０２）。先頭文字がスペースの場合（ステップ３５０２：Ｙｅｓ）はフラグflag[i][j]が0（検証NG）に変更される（ステップ３５０５）。
先頭文字がスペースでない場合（ステップ３５０２：Ｎｏ）、続いて最後の文字がスペースかどうか判定する（ステップ３５０３）。最後の文字がスペースの場合（ステップ３５０３：Ｙｅｓ）はフラグflag[i][j]が0（検証NG）に変更される（ステップ３５０５）。
最後の文字がスペースでない場合（ステップ３５０３：Ｎｏ）、内部に複数のスペース列が含まれているかどうか判定する（ステップ３５０４）。具体的には検証対象文字列d_results[i][j]が”.*\s{2,}.*”で表現されているかどうか判定する。ここで、”.*”は空文字を含む任意の文字列、\s{2,}は複数のスペース列があることを示す。複数のスペース列が検証対象文字列に含まれる場合（ステップ３５０４：Ｙｅｓ）、フラグflag[i][j]が0（検証NG）に変更される（ステップ３５０５）。以上のチェックで検証処理は終了（ステップ３５０６）し、図１８のステップ１８０７に進む。
【００７４】
図３６は、ｌａｎｇｕａｇｅ型（type[i][j]=22の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]において、言語識別子であるかどうか判定する。具体的にはd_results[i][j]が”([a-zA-Z]{2}|[iI]-[a-zA-Z]+|[xX]-[a-zA-Z]{1,8})(-[a-zA-Z]{1,8})*”で表現されているかどうか判定する（ステップ３６０１）。つまり、英文字2文字、i-（英文字1文字以上）、I-（英文字1文字以上）、x-（英文字1〜8文字）、X-（英文字1〜8文字）のいずれかに-（英文字1〜8文字）を0回以上繰り返しが付いた文字列である。例えば、”jp”は英文字2文字なのでｌａｎｇｕａｇｅ型である。一方”y-abcdefg”は”y”で始まっているのでｌａｎｇｕａｇｅ型でない。ｌａｎｇｕａｇｅ型でない場合（ステップ３６０１：Ｎｏ）、フラグflag[i][j]が0（検証NG）に変更される（ステップ３６０２）。以上のチェックで検証処理は終了（ステップ３６０３）し、図１８のステップ１８０７に進む。
【００７５】
図３７は、ＮＭＴＯＫＥＮ型（type[i][j]=23の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]において、スペースが含まれていないことを判定する。具体的にはd_results[i][j]が”.*\s.*”で表現されているかどうか判定する（ステップ３７０１）。ここで、”\s”はスペースを示す。スペースが含まれている場合（ステップ３７０１：Ｙｅｓ）、フラグflag[i][j]は0（検証NG）に変更される（ステップ３７０２）。以上のチェックで検証処理は終了（ステップ３７０３）し、図１８のステップ１８０７に進む。
【００７６】
図３８は、Ｎａｍｅ、ＮＣＮａｍｅ、ＩＤ、ＩＤＲＥＦおよびＥＮＴＩＴＹ型（type[i][j]=25〜28または30の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]において、Ｎａｍｅ、ＮＣＮａｍｅ、ＩＤ、ＩＤＲＥＦおよびＥＮＴＩＴＹ型のいずれかであることを判定する。Ｎａｍｅ型はXMLの名前、ＮＣＮａｍｅ型は修飾されない名前、ＩＤ型はXML1.0第2番のID属性型、ＩＤＲＥＦ型はXML1.0第2番のIDREF属性型、ＥＮＴＩＴＹ型はXML1.0第2番のENTITY属性型をそれぞれ示す。具体的にはd_results[i][j]が”([a-zA-Z]+|_|:)([0-9a-zA-Z]+|_|-|\.|:)*”で表現されているかどうか判定する（ステップ３８０１）。これは検証対象文字列の先頭が英文字1文字以上、”_”、”:”のいずれかであり、その後は英数字1文字以上、”_”、”-“、”.”、”:”のいずれかが0回以上繰り返すことを意味する。ただし、この判定については検証対象文字列がすべて1バイト文字の場合である。
検証対象文字列に2バイト文字を含む場合、非特許文献２『The Naming of Parts』の「[5] Name ::= (Letter |
'_' | ':') (NameChar)*」の右辺（”::=”の右側）で表現されているかどうか判定する。右辺のLetterについては非特許文献３『Extensible Markup Language
(XML) 1.0 (Fifth Edition)』の「B Character Classes」章の[84]にて、NameCharについては非特許文献２『The Naming of Parts』の「[4] NameChar ::=
Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender」で定義され、Digit、CombiningChar、Extenderについてはそれぞれ非特許文献３『Extensible Markup Language (XML) 1.0 (Fifth Edition)』の「B Character Classes」章の[88]、[87]、[89]で説明している。
例えば、”Zu99.:”はＮａｍｅ、ＮＣＮａｍｅ、ＩＤ、ＩＤＲＥＦおよびＥＮＴＩＴＹ型のいずれかであるが、”99Zu”はＮａｍｅ、ＮＣＮａｍｅ、ＩＤ、ＩＤＲＥＦおよびＥＮＴＩＴＹ型のいずれでもない。Ｎａｍｅ、ＮＣＮａｍｅ、ＩＤ、ＩＤＲＥＦおよびＥＮＴＩＴＹ型のいずれでもないと判定された場合（ステップ３８０１：Ｎｏ）、フラグflag[i][j]は0（検証NG）に変更される（ステップ３８０２）。以上のチェックで検証処理は終了（ステップ３８０３）し、図１８のステップ１８０７に進む。
【００７７】
図３９は、ＩＤＲＥＦＳおよびＥＮＴＩＴＩＥＳ型（type[i][j]=29または31の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]において、ＩＤＲＥＦＳおよびＥＮＴＩＴＹＳ型のいずれかであることを判定する。ＩＤＲＥＦＳ型はXML1.0第2番のIDREFS属性型の、ＥＮＴＩＴＹＳ型はXML1.0第2番のENTITYS属性型をそれぞれ示す。具体的にはd_results[i][j]が”(([a-zA-Z]+|_|:)([0-9a-zA-Z]+|_|-|\.|:)*\s)*([a-zA-Z]+|_|:)([0-9a-zA-Z]+|_|-|\.|:)*”で表現されているかどうか判定する（ステップ３９０１）。これは検証対象文字列の先頭が英文字1文字以上、”_”、”:”のいずれかであり、その後は英数字1文字以上、”_”、”-“、”.”、”:”のいずれかが0回以上繰り返す文字列がスペース区切りで続くことを意味する。ただし、この判定については検証対象文字列がすべて1バイト文字の場合である。
検証対象文字列に2バイト文字を含む場合、非特許文献２『The Naming of Parts』の「[5] Name ::= (Letter |
'_' | ':') (NameChar)*」で定義されるNameがスペース区切りで続いているかどうか判定する。もちろんスペース区切りの各Nameが同じ文字列である必要はない。右辺のLetterについては非特許文献３『Extensible Markup Language (XML) 1.0 (Fifth Edition)』の「B Character Classes」章の[84]にて、NameCharについては非特許文献２『The Naming of Parts』の「[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' |
CombiningChar | Extender」で定義され、Digit、CombiningChar、Extenderについてはそれぞれ非特許文献３『Extensible Markup Language (XML) 1.0 (Fifth Edition)』の「B Character Classes」章の[88]、[87]、[89]で説明している。
例えば、”Zu99.:
Zy__”はＩＤＲＥＦＳおよびＥＮＴＩＴＹＳ型のいずれかであるが、”Zu99 99Zu”はスペース区切りの後の部分が”([a-zA-Z]+|_|:)([0-9a-zA-Z]+|_|-|\.|:)*”で表現される文字列でないため、ＩＤＲＥＦＳおよびＥＮＴＩＴＹＳ型のいずれでもない。ＩＤＲＥＦＳおよびＥＮＴＩＴＹＳ型のいずれでもないと判定された場合（ステップ３９０：Ｎｏ）、フラグflag[i][j]は0（検証NG）に変更される（ステップ３９０２）。以上のチェックで検証処理は終了（ステップ３９０３）し、図１８のステップ１８０７に進む。
【００７８】
図４０は、ｉｎｔｅｇｅｒ型（type[i][j]=32の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が整数であることを判定する。具体的には”(\+|-)?\d+”で表現される文字列であることを判定する（ステップ４００１）。ここで”(\+|-)?”とは”+”または”-“がいずれかまたは空文字、”\d+”は1文字以上の数字をそれぞれ示す。整数でないと判断された場合（ステップ４００１：Ｎｏ）、フラグflag[i][j]は0（検証NG）に変更される（ステップ４００２）。以上のチェックで検証処理は終了（ステップ４００３）し、図１８のステップ１８０７に進む。
【００７９】
図４１は、ｎｏｎＰｏｓｉｔｉｖｅＩｎｔｅｇｅｒ型（type[i][j]=33の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が0以下の整数であることを判定する。具体的には”-\d+”で表現される文字列であることを判定する（ステップ４１０１）。この場合、最初の1文字目は必ず”-“であり、2文字目以降は数字である。整数でないまたは最初の1文字目が”-“でない場合（ステップ４１０１：Ｎｏ）、フラグflag[i][j]は0（検証NG）に変更される（ステップ４１０２）。以上のチェックで検証処理は終了（ステップ４１０３）し、図１８のステップ１８０７に進む。
【００８０】
図４２は、ｎｅｇａｔｉｖｅＩｎｔｅｇｅｒ型（type[i][j]=34の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が負の整数であることを判定する。具体的には”-[1-9]\d*”で表現される文字列であることを判定する（ステップ４２０１）。この場合、最初の1文字目は必ず”-“であり、2文字目は0以外の数字、3文字目以降は存在しないか数字である。負の整数でない場合（ステップ４２０１：Ｎｏ）、フラグflag[i][j]は0（検証NG）に変更される（ステップ４２０２）。以上のチェックで検証処理は終了（ステップ４２０３）し、図１８のステップ１８０７に進む。
【００８１】
図４３は、ｌｏｎｇ型（type[i][j]=35の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が整数であることを判定する。具体的には”(\+|-)?\d+”で表現される文字列であることを判定する（ステップ４３０１）。整数でないつまり”(\+|-)?\d+”で表現される文字列でない場合（ステップ４３０１：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４３０３）。この場合、検証処理は終了（ステップ４３０４）し、図１８のステップ１８０７に進む。
検証対象文字列が整数である場合（ステップ４３０１：Ｙｅｓ）、続いてこの整数が-9223372036854775808以上、9223372036854775807以下であるかどうか判定する（ステップ４３０２）。この範囲に存在しない場合（ステップ４３０２：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４３０３）。以上のチェックで検証処理は終了（ステップ４３０４）し、図１８のステップ１８０７に進む。
【００８２】
図４４は、ｉｎｔ型（type[i][j]=36の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が整数であることを判定する。具体的には”(\+|-)?\d+”で表現される文字列であることを判定する（ステップ４４０１）。整数でないつまり”(\+|-)?\d+”で表現される文字列でない場合（ステップ４４０１：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４４０３）。この場合、検証処理は終了（ステップ４４０４）し、図１８のステップ１８０７に進む。
検証対象文字列が整数である場合（ステップ４４０１：Ｙｅｓ）、続いてこの整数が-2147483648以上、2147483647以下であるかどうか判定する（ステップ４４０２）。この範囲に存在しない場合（ステップ４４０２：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４４０３）。以上のチェックで検証処理は終了（ステップ４４０４）し、図１８のステップ１８０７に進む。
【００８３】
図４５は、ｓｈｏｒｔ型（type[i][j]=37の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が整数であることを判定する。具体的には”(\+|-)?\d+”で表現される文字列であることを判定する（ステップ４５０１）。整数でないつまり”(\+|-)?\d+”で表現される文字列でない場合（ステップ４５０１：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４５０３）。この場合、検証処理は終了（ステップ４５０４）し、図１８のステップ１８０７に進む。検証対象文字列が整数である場合（ステップ４５０１：Ｙｅｓ）、続いてこの整数が-32768以上、32767以下であるかどうか判定する（ステップ４５０２）。この範囲に存在しない場合（ステップ４５０２：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４５０３）。以上のチェックで検証処理は終了（ステップ４５０４）し、図１８のステップ１８０７に進む。
【００８４】
図４６は、ｂｙｔｅ型（type[i][j]=38の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が整数であることを判定する。具体的には”(\+|-)?\d+”で表現される文字列であることを判定する（ステップ４６０１）。整数でないつまり”(\+|-)?\d+”で表現される文字列でない場合（ステップ４６０１：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４６０３）。この場合、検証処理は終了（ステップ４６０４）し、図１８のステップ１８０７に進む。
検証対象文字列が整数である場合（ステップ４６０１：Ｙｅｓ）、続いてこの整数が-128以上、127以下であるかどうか判定する（ステップ４６０２）。この範囲に存在しない場合（ステップ４６０２：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４６０３）。以上のチェックで検証処理は終了（ステップ４６０４）し、図１８のステップ１８０７に進む。
【００８５】
図４７は、ｎｏｎＮｅｇａｔｉｖｅＩｎｔｅｇｅｒ型（type[i][j]=39の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が非負整数であることを判定する。具体的には”(-0|\+?0|\+?[1-9]\d*)”で表現される文字列であることを判定する（ステップ４７０１）。これは-0、0、+0または正の整数であることを意味する。これらでない場合（ステップ４７０１：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４７０２）。以上のチェックで検証処理は終了（ステップ４７０３）し、図１８のステップ１８０７に進む。
【００８６】
図４８は、ｕｎｓｉｇｎｅｄＬｏｎｇ型（type[i][j]=40の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が符号なし整数であることを判定する。具体的には”(0|[1-9]\d*)”で表現される文字列であることを判定する（ステップ４８０１）。整数でないまたは符号が付いている、つまり”(0|[1-9]\d*)”で表現される文字列でない場合（ステップ４８０１：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４８０３）。この場合、検証処理は終了（ステップ４８０４）し、図１８のステップ１８０７に進む。
検証対象文字列が符号なし整数である場合（ステップ４８０１：Ｙｅｓ）、続いてこの整数が18446744073709551615以下であるかどうか判定する（ステップ４８０２）。この範囲に存在しない場合（ステップ４８０２：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４８０３）。以上のチェックで検証処理は終了（ステップ４８０４）し、図１８のステップ１８０７に進む。
【００８７】
図４９は、ｕｎｓｉｇｎｅｄＩｎｔ型（type[i][j]=41の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が符号なし整数であることを判定する。具体的には”(0|[1-9]\d*)”で表現される文字列であることを判定する（ステップ４９０１）。整数でないまたは符号が付いている、つまり”(0|[1-9]\d*)”で表現される文字列でない場合（ステップ４９０１：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４９０３）。この場合、検証処理は終了（ステップ４９０４）し、図１８のステップ１８０７に進む。
検証対象文字列が符号なし整数である場合（ステップ４９０１：Ｙｅｓ）、続いてこの整数が42949687295以下であるかどうか判定する（ステップ４９０２）。この範囲に存在しない場合（ステップ４９０２：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ４９０３）。以上のチェックで検証処理は終了（ステップ４９０４）し、図１８のステップ１８０７に進む。
【００８８】
図５０は、ｕｎｓｉｇｎｅｄＳｈｏｒｔ型（type[i][j]=42の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が符号なし整数であることを判定する。具体的には”(0|[1-9]\d*)”で表現される文字列であることを判定する（ステップ５００１）。整数でないまたは符号が付いている、つまり”(0|[1-9]\d*)”で表現される文字列でない場合（ステップ５００１：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ５００３）。この場合、検証処理は終了（ステップ５００４）し、図１８のステップ１８０７に進む。
検証対象文字列が符号なし整数である場合（ステップ５００１：Ｙｅｓ）、続いてこの整数が65535以下であるかどうか判定する（ステップ５００２）。この範囲に存在しない場合（ステップ５００２：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ５００３）。以上のチェックで検証処理は終了（ステップ５００４）し、図１８のステップ１８０７に進む。
【００８９】
図５１は、ｕｎｓｉｇｎｅｄＳｈｏｒｔ型（type[i][j]=43の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が符号なし整数であることを判定する。具体的には”(0|[1-9]\d*)”で表現される文字列であることを判定する（ステップ５１０１）。つまり0または1〜9で始まる数字の列で表現されるかどうか判定する。数字以外の文字を含むまたは”00”で始まる文字列の場合（ステップ５１０１：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ５１０３）。この場合、検証処理は終了（ステップ５１０４）し、図１８のステップ１８０７に進む。
検証対象文字列が符号なし整数である場合（ステップ５１０１：Ｙｅｓ）、続いてこの整数が255以下であるかどうか判定する（ステップ５１０２）。この範囲に存在しない場合（ステップ５１０２：Ｎｏ）はフラグflag[i][j]は0（検証NG）に変更される（ステップ５１０３）。以上のチェックで検証処理は終了（ステップ５１０４）し、図１８のステップ１８０７に進む。
【００９０】
図５２は、ｐｏｓｉｔｉｖｅＩｎｔｅｇｅｒ型（type[i][j]=44の場合）に対するデータ検証処理（図１８のステップ１８０６）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]が正の整数であることを検証する。具体的には”\+?[1-9]\d*”で表現される文字列であることを判定する（ステップ５２０１）。つまり”+”の符号（符号はなくてもよい）と1〜9で始まる数字の列で表現されるかどうか判定する。それらで表現不可能な文字列の場合（ステップ５２０１：Ｎｏ）、フラグflag[i][j]は0（検証NG）に変更される（ステップ５２０２）。以上のチェックで検証処理は終了（ステップ５２０３）し、図１８のステップ１８０７に進む。
【００９１】
図５３は、ファセットと対応する数値の一例を示す。
５３０１はファセットと対応する数値を示し、５３０２はcondition[i][][]の値（参照）の具体例である。この例では「7,value=”32”」を参照している。これはファセット名がmaxLengthであり、最大32文字であることを示している。
【００９２】
図５４は、ファセットがｅｑｕａｌ（condition[i][j][]の最初の数字が1の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
検証対象文字列d[i][j]がcondition[i][j][]の「1,value=”xx”」に記載されている”xx”に等しいかどうか判定する（ステップ５４０１）。等しくない場合、フラグflag[i][j]は0（検証NG）に変更される（ステップ５４０２）。以上のチェックで検証処理は終了（ステップ５４０３）し、図１８のステップ１８１１に進む。
【００９３】
図５５は、ファセットがｎｕｍｅｒｉｃ（condition[i][j][]の最初の数字が5の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
condition[i][j][]が「5,value=”true”」の場合、d_results[i][j]が数値であるかどうか判定する（ステップ５５０１）。例えば、”123.45”は数値であるが、”123.45G”は数値でない。d_results[i][j]が数値でない場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ５５０３）、検証処理は終了（ステップ５５０４）する。condition[i][j][]が「5,value=”false”」の場合、d_results[i][j]が数値であるかどうか判定する（ステップ５５０２）。d_results[i][j]が数値である場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ５５０３）、検証処理は終了（ステップ５５０４）する。フラグflag[i][j]が変更されない場合についても以上の判定のみで検証処理は終了（ステップ５５０４）する。その後は図１８のステップ１８１１に進む。
【００９４】
図５６は、ファセットがｌｅｎｇｔｈ（condition[i][j][]の最初の数字が6の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初にデータ型がｈｅｘＢｉｎａｒｙ型（type[i][j]=15）またはｂａｓｅ６４Ｂｉｎａｒｙ型（type[i][j]=16）であるかどうか判定する（ステップ５６０１）。ｈｅｘＢｉｎａｒｙ型の場合、検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」の2分の1であるかどうか判定する（ステップ５６０２）。例えば、condition[i][j][]が「6,value=”16”」の場合、検証対象文字列が8文字であれば”Yes”であり、検証処理が終了（ステップ５６０６）する。検証対象文字列が8文字以外であれば”No”であり、type[i][j]=16かつ検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」の4分の3であるかどうか判定する（ステップ５６０３）。この場合、明らかに”No”であるので、フラグflag[i][j]は0（検証NG）に変更され（ステップ５６０５）、検証処理が終了（ステップ５６０６）する。
ｂａｓｅ６４Ｂｉｎａｒｙ型の場合、検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」の4分の3であるかどうか判定する（ステップ５６０３）。例えば、condition[i][j][]が「6,value=”16”」の場合、検証対象文字列が12文字であれば”Yes”であり、検証処理が終了（ステップ５６０６）する。検証対象文字列が12文字以外であれば”No”であり、フラグflag[i][j]は0（検証NG）に変更され（ステップ５６０６）、検証処理が終了（ステップ５６０７）する。
ｈｅｘＢｉｎａｒｙ型でもｂａｓｅ６４Ｂｉｎａｒｙ型でもない場合、データ型が数値または時間を示す型であるかどうか判定する。具体的には、type[i][j]が3〜14または32〜44であるかどうか判定する（ステップ５６０４）。データ型が数値または時間を示す型である場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ５６０６）、検証処理が終了（ステップ５６０７）する。データ型が数値型でも時間型でもない場合、検証対象文字列d_results[i][j]の長さが「 condition[i][j][]のvalue値」であるかどうか判定する（ステップ５６０５）。例えば、condition[i][j][]が「6,value=”16”」の場合、検証対象文字列が16文字であれば”Yes”であり、検証処理が終了（ステップ５６０７）する。検証対象文字列が16文字以外であれば”No”であり、フラグflag[i][j]は0（検証NG）に変更され（ステップ５６０６）、検証処理が終了（ステップ５６０７）する。
いずれの場合にも検証処理が終了（ステップ５６０７）した後は図１８のステップ１８１１に進む。
【００９５】
図５７は、ファセットがｍａｘＬｅｎｇｔｈ（condition[i][j][]の最初の数字が7の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初にデータ型がｈｅｘＢｉｎａｒｙ型（type[i][j]=15）またはｂａｓｅ６４Ｂｉｎａｒｙ型（type[i][j]=16）であるかどうか判定する（ステップ５７０１）。ｈｅｘＢｉｎａｒｙ型の場合、検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」の2分の1以下であるかどうか判定する（ステップ５７０２）。例えば、condition[i][j][]が「7,value=”15”」の場合、検証対象文字列が7文字以下であれば”Yes”であり、検証処理が終了（ステップ５７０７）する。検証対象文字列が8文字以上であれば”No”であり、type[i][j]=16かつ検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」の4分の3以下であるかどうか判定する（ステップ５７０３）。この場合、明らかに”No”であるので、フラグflag[i][j]は0（検証NG）に変更され（ステップ５７０６）、検証処理が終了（ステップ５７０７）する。
ｂａｓｅ６４Ｂｉｎａｒｙ型の場合、検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」の4分の3以下であるかどうか判定する（ステップ５７０３）。例えば、condition[i][j][]が「7,value=”15”」の場合、検証対象文字列が11文字以下であれば”Yes”であり、検証処理が終了（ステップ５７０７）する。検証対象文字列が12文字以上であれば”No”であり、フラグflag[i][j]は0（検証NG）に変更され（ステップ５７０６）、検証処理が終了（ステップ５７０７）する。
ｈｅｘＢｉｎａｒｙ型でもｂａｓｅ６４Ｂｉｎａｒｙ型でもない場合、データ型が数値または時間を示す型であるかどうか判定する。具体的には、type[i][j]が3〜14または32〜44であるかどうか判定する（ステップ５７０４）。データ型が数値または時間を示す型である場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ５７０６）、検証処理が終了（ステップ５７０７）する。データ型が数値型でも時間型でもない場合、検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」以下であるかどうか判定する（ステップ５７０５）。例えば、condition[i][j][]が「7,value=”15”」の場合、検証対象文字列が15文字以下であれば”Yes”であり、検証処理が終了（ステップ５７０７）する。検証対象文字列が16文字以上であれば”No”であり、フラグflag[i][j]は0（検証NG）に変更され（ステップ５７０６）、検証処理が終了（ステップ５７０７）する。
いずれの場合にも検証処理が終了（ステップ５７０７）した後は図１８のステップ１８１１に進む。
【００９６】
図５８は、ファセットがｍｉｎＬｅｎｇｔｈ（condition[i][j][]の最初の数字が8の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初にデータ型がｈｅｘＢｉｎａｒｙ型（type[i][j]=15）またはｂａｓｅ６４Ｂｉｎａｒｙ型（type[i][j]=16）であるかどうか判定する（ステップ５８０１）。ｈｅｘＢｉｎａｒｙ型の場合、検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」の2分の1以上であるかどうか判定する（ステップ５８０２）。例えば、condition[i][j][]が「8,value=”15”」の場合、検証対象文字列が8文字以上であれば”Yes”であり、検証処理が終了（ステップ５８０７）する。検証対象文字列が7文字以下であれば”No”であり、type[i][j]=16かつ検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」の4分の3以下であるかどうか判定する（ステップ５８０３）。この場合、明らかに”No”であるので、フラグflag[i][j]は0（検証NG）に変更され（ステップ５８０６）、検証処理が終了（ステップ５８０７）する。
ｂａｓｅ６４Ｂｉｎａｒｙ型の場合、検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」の4分の3以上であるかどうか判定する（ステップ５８０３）。例えば、condition[i][j][]が「8,value=”15”」の場合、検証対象文字列が12文字以上であれば”Yes”であり、検証処理が終了（ステップ５８０７）する。検証対象文字列が11文字以下であれば”No”であり、フラグflag[i][j]は0（検証NG）に変更され（ステップ５８０６）、検証処理が終了（ステップ５８０７）する。
ｈｅｘＢｉｎａｒｙ型でもｂａｓｅ６４Ｂｉｎａｒｙ型でもない場合、データ型が数値または時間を示す型であるかどうか判定する。具体的には、type[i][j]が3〜14または32〜44であるかどうか判定する（ステップ５８０４）。データ型が数値または時間を示す型である場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ５８０６）、検証処理が終了（ステップ５７０７）する。データ型が数値型でも時間型でもない場合、検証対象文字列d_results[i][j]の長さが「condition[i][j][]のvalue値」以下であるかどうか判定する（ステップ５８０５）。例えば、condition[i][j][]が「8,value=”15”」の場合、検証対象文字列が15文字以上であれば”Yes”であり、検証処理が終了（ステップ５７０７）する。検証対象文字列が14文字以下であれば”No”であり、フラグflag[i][j]は0（検証NG）に変更され（ステップ５８０６）、検証処理が終了（ステップ５８０７）する。
いずれの場合にも検証処理が終了（ステップ５８０７）した後は図１８のステップ１８１１に進む。
【００９７】
図５９は、ファセットがｐａｔｔｅｒｎ（condition[i][j][]の最初の数字が8の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
検証対象文字列d_results[i][j]がcondition[i][j][]のvalue値に記載のパターンにマッチングしているかどうか判定する（ステップ５９０１）。例えば、condition[i][j][]が「9,value=”[a-z]+”」の場合、検証対象文字列が1文字以上の英小文字で表現されていれば”Yes”であり検証処理が終了（ステップ５９０３）する。検証対象文字列に英小文字以外の文字を含む、あるいは空文字である場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ５９０２）、検証処理が終了（ステップ５９０３）する。いずれの場合にも検証処理が終了（ステップ５９０６）した後は図１８のステップ１８１１に進む。
【００９８】
図６０は、ファセットがｅｎｕｍｅｒａｔｉｏｎ（condition[i][j][]の最初の数字が10の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初にcondition[i][j][]の[]が0であるかどうか判定する（ステップ６００１）。0である場合、フラグflag[i][j]は0（検証NG）に変更される（ステップ６００２）。いすれの場合にも検証対象文字列d_results[i][j]がcondition[i][j][]のvalue値と等しいかどうか判定する（ステップ６００３）。等しい場合、フラグflag[i][j]は1（検証OK）に変更され（ステップ６００４）、検証処理が終了（ステップ６００５）する。等しくない場合、フラグflag[i][j]が変更されないまま、検証処理が終了（ステップ６００５）する。
例えば、検証対象文字列d_results[i][j]が”ZYXWVUT”の場合、condition[i][j][]が「10,value=”ZYXWVUT”」ならはステップ６００４によりフラグflag[i][j]は1（検証OK）に変更される。condition[i][j][]が「10,value=”ZYXWVUS”」ならば、フラグflag[i][j]は変更されない。
いずれの場合にも検証処理が終了（ステップ６００５）した後は図１８のステップ１８１１に進む。
【００９９】
図６１は、ファセットがｍａｘＩｎｃｌｕｓｉｖｅ（condition[i][j][]の最初の数字が12の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初にデータ型が数値または時間を示す型であるかどうか判定する。具体的には、type[i][j]が3〜14または32〜44であるかどうか判定する（ステップ６１０１）。データ型が数値または時間を示す型でない場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ６１０３）、検証処理が終了（ステップ６１０４）する。データ型が数値または時間を示す型である場合、検証対象文字列d_results[i][j]がcondition[i][j][]のvalue値以下であるかどうか判定する（ステップ６１０２）。condition[i][j][]のvalue値よりも大きい場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ６１０３）、検証処理が終了（ステップ６１０４）する。d_results[i][j]がcondition[i][j][]のvalue値以下の場合、フラグflag[i][j]は変更されず、検証処理が終了（ステップ６１０３）する。
例えば検証対象文字列d_results[i][j]がｄｅｃｉｍａｌ型”3.14”でcondition[i][j][]が「12,value=”3.2”」の場合、3.14は3.2以下であるので、フラグflag[i][j]は変更されない。しかし、condition[i][j][]が「12,value=”3.1”」の場合、3.14は3.1より大きいので、フラグflag[i][j]は0（検証NG）に変更される。また、検証対象文字列d_results[i][j]がｄａｔｅＴｉｍｅ型”2012-02-29T23:59:59”でcondition[i][j][]が「12,value=”2012-02-29T23:59:59”」の場合、検証対象文字列と比較する時間が同じであるため、フラグflag[i][j]は変更されない。しかし、condition[i][j][]が「12,value=”2012-02-29T23:59:58”」の場合、23時59分59秒は23時59分58秒よりも後（大きい）であるため、フラグflag[i][j]は0（検証NG）に変更される。
いずれの場合にも検証処理が終了（ステップ６１０４）した後は図１８のステップ１８１１に進む。
【０１００】
図６２は、ファセットがｍａｘＥｘｃｌｕｓｉｖｅ（condition[i][j][]の最初の数字が13の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初にデータ型が数値または時間を示す型であるかどうか判定する。具体的には、type[i][j]が3〜14または32〜44であるかどうか判定する（ステップ６２０１）。データ型が数値または時間を示す型でない場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ６２０３）、検証処理が終了（ステップ６２０４）する。データ型が数値または時間を示す型である場合、検証対象文字列d_results[i][j]がcondition[i][j][]のvalue値未満であるかどうか判定する（ステップ６２０２）。condition[i][j][]のvalue値以上の場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ６２０３）、検証処理が終了（ステップ６２０４）する。d_results[i][j]がcondition[i][j][]のvalue値未満の場合、フラグflag[i][j]は変更されず、検証処理が終了（ステップ６２０４）する。
例えば検証対象文字列d_results[i][j]がｄｅｃｉｍａｌ型”3.14”でcondition[i][j][]が「12,value=”3.2”」の場合、3.14は3.2未満であるので、フラグflag[i][j]は変更されない。しかし、condition[i][j][]が「12,value=”3.1”」の場合、3.14は3.1以上であるで、フラグflag[i][j]は0（検証NG）に変更される。また、検証対象文字列d_results[i][j]がｄａｔｅＴｉｍｅ型”2012-02-29T23:59:59”でcondition[i][j][]が「12,value=”2012-03-01T00:00:00”」の場合、2013年2月29日は2013年3月1日よりも前（未満）であるため、フラグflag[i][j]は変更されない。しかし、condition[i][j][]が「12,value=”2012-02-29T23:59:59”」の場合、検証対象文字列と比較する時間が同じであるため、フラグflag[i][j]は0（検証NG）に変更される。
いずれの場合にも検証処理が終了（ステップ６２０４）した後は図１８のステップ１８１１に進む。
【０１０１】
図６３は、ファセットがｍｉｎＩｎｃｌｕｓｉｖｅ（condition[i][j][]の最初の数字が14の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初にデータ型が数値または時間を示す型であるかどうか判定する。具体的には、type[i][j]が3〜14または32〜44であるかどうか判定する（ステップ６３０１）。データ型が数値または時間を示す型でない場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ６３０３）、検証処理が終了（ステップ６３０４）する。データ型が数値または時間を示す型である場合、検証対象文字列d_results[i][j]がcondition[i][j][]のvalue値以上であるかどうか判定する（ステップ６３０２）。condition[i][j][]のvalue値未満の場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ６３０３）、検証処理が終了（ステップ６３０４）する。d_results[i][j]がcondition[i][j][]のvalue値以上の場合、フラグflag[i][j]は変更されず、検証処理が終了（ステップ６３０３）する。
例えば検証対象文字列d_results[i][j]がｄｅｃｉｍａｌ型”3.14”でcondition[i][j][]が「12,value=”3.1”」の場合、3.14は3.1以上であるので、フラグflag[i][j]は変更されない。しかし、condition[i][j][]が「12,value=”3.2”」の場合、3.14は3.2未満であるので、フラグflag[i][j]は0（検証NG）に変更される。また、検証対象文字列d_results[i][j]がｄａｔｅＴｉｍｅ型”2012-02-29T23:59:59”でcondition[i][j][]が「12,value=”2012-02-29T23:59:59”」の場合、検証対象文字列と比較する時間が同じであるため、フラグflag[i][j]は変更されない。しかし、condition[i][j][]が「12,value=”2012-03-01T00:00:00”」の場合、2012年2月29日は2012年3月1日よりも前（未満）であるため、フラグflag[i][j]は0（検証NG）に変更される。
いずれの場合にも検証処理が終了（ステップ６３０４）した後は図１８のステップ１８１１に進む。
【０１０２】
図６４は、ファセットがｍｉｎＥｘｃｌｕｓｉｖｅ（condition[i][j][]の最初の数字が15の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初にデータ型が数値または時間を示す型であるかどうか判定する。具体的には、type[i][j]が3〜14または32〜44であるかどうか判定する（ステップ６４０１）。データ型が数値または時間を示す型でない場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ６４０３）、検証処理が終了（ステップ６４０４）する。データ型が数値または時間を示す型である場合、検証対象文字列d_results[i][j]がcondition[i][j][]のvalue値より大きいかどうか判定する（ステップ６４０２）。condition[i][j][]のvalue値以下の場合、フラグflag[i][j]は0（検証NG）に変更され（ステップ６４０３）、検証処理が終了（ステップ６４０４）する。d_results[i][j]がcondition[i][j][]のvalue値より大きい場合、フラグflag[i][j]は変更されず、検証処理が終了（ステップ６４０３）する。
例えば検証対象文字列d_results[i][j]がｄｅｃｉｍａｌ型”3.14”でcondition[i][j][]が「12,value=”3.1”」の場合、3.14は3.1より大きいので、フラグflag[i][j]は変更されない。しかし、condition[i][j][]が「12,value=”3.2”」の場合、3.14は3.2以下であるので、フラグflag[i][j]は0（検証NG）に変更される。また、検証対象文字列d_results[i][j]がｄａｔｅＴｉｍｅ型”2012-02-29T23:59:59”でcondition[i][j][]が「12,value=”2012-02-29T23:59:58”」の場合、23時59分59秒は23時59分58秒よりも後（大きい）ので、フラグflag[i][j]は変更されない。しかし、condition[i][j][]が「12,value=”2012-02-29T23:59:59”」の場合、検証対象文字列と比較する時間が同じであるため、、フラグflag[i][j]は0（検証NG）に変更される。
いずれの場合にも検証処理が終了（ステップ６４０４）した後は図１８のステップ１８１１に進む。
【０１０３】
図６５は、ファセットがｔｏｔａｌＤｉｇｉｔｓ（condition[i][j][]の最初の数字が16の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が整数または固定小数点数であるかどうか判定する。具体的には、type[i][j]が3または32〜44であるかどうか判定する（ステップ６５０１）。整数でも固定小数点数でもない場合、フラグflag[i][j]は0（検索NG）に変更され（ステップ６５０３）、検証処理は終了（ステップ６５０４）する。整数または固定小数点数である場合、整数部分の桁数と小数点以下の部分の桁数を合計し、それがcondition[i][j][]のvalue値以下であることを判定する（ステップ６５０２）。condition[i][j][]のvalue値以下であれば、フラグflag[i][j]は変更されず、検証処理が終了（ステップ６５０４）する。condition[i][j][]のvalue値よりも大きければ、フラグ[i][j]は0（検証NG）に変更され（ステップ６５０３）、検証処理が終了（ステップ６５０４）する。
例えばd_results[i][j]が1.41421356の場合、整数部分の桁数は1、小数点以下の部分の桁数は8なのでそれらの合計は9である。そのため、condition[i][j][]が「16,value=”9”」ならばcondition[i][j][]のvalue値以下であるのでフラグflag[i][j]は変更されない。しかし、condition[i][j][]が「16,value=”8”」ならばcondition[i][j][]のvalue値よりも整数部分と小数点以下の部分の合計桁数の方が大きいため、フラグflag[i][j]は0（検証NG）に変更される。
いずれの場合にも検証処理が終了（ステップ６５０４）した後は図１８のステップ１８１１に進む。
【０１０４】
図６６は、ファセットがｆｒａｃｔｉｏｎＤｉｇｉｔｓ（condition[i][j][]の最初の数字が17の場合）に対するデータ検証処理（図１８のステップ１８１０）の詳細なフローの一例を示す。
最初に検証対象文字列d_results[i][j]が整数または固定小数点数であるかどうか判定する。具体的には、type[i][j]が3または32〜44であるかどうか判定する（ステップ６６０１）。整数でも固定小数点数でもない場合、フラグflag[i][j]は0（検索NG）に変更され（ステップ６６０３）、検証処理は終了（ステップ６６０４）する。整数または固定小数点数である場合、小数点以下の部分の桁数がcondition[i][j][]のvalue値以下であることを判定する（ステップ６６０２）。condition[i][j][]のvalue値以下であれば、フラグflag[i][j]は変更されず、検証処理が終了（ステップ６６０４）する。condition[i][j][]のvalue値よりも大きければ、フラグ[i][j]は0（検証NG）に変更され（ステップ６６０３）、検証処理が終了（ステップ６６０４）する。
例えばd_results[i][j]が1.41421356の場合、小数点以下の部分の桁数は8であるため、condition[i][j][]が「17,value=”8”」ならばcondition[i][j][]のvalue値以下であるのでフラグflag[i][j]は変更されない。しかし、condition[i][j][]が「17,value=”7”」ならばcondition[i][j][]のvalue値よりも小数点以下の部分の桁数の方が大きいため、フラグflag[i][j]は0（検証NG）に変更される。
いずれの場合にも検証処理が終了（ステップ６６０４）した後は図１８のステップ１８１１に進む。
【０１０５】
図６７は、タグ文字抜き処理で取得したデータをホスト部に送信する処理（図７のステップ７１０）の詳細なフローの一例を示す。
この処理はステップ７０９で誤りが無かったＧＰＵ１１０の枚数分繰り返す（ステップ６７０１〜６７０４）。繰り返し処理の中では最初にデバイスメモリ１１１に存在する検証済文字列d_result[i][]をＣＰＵ１０４のホストメモリ（主記憶）１０５にコピーする（ステップ６７０２）。コピー完了後、デバイスメモリ１１１を解放する（ステップ６７０３）。
具体例としてＧＰＵ１１０の1枚目で処理すると仮定して、ＸＭＬデータが図２の２０２、取得対象関連タグ情報が図３の３０１、取得対象位置情報が図３の３０２の場合、ＣＰＵのホストメモリ（主記憶）１０５にコピーされるデータd_results[0][]は以下の通りである。
d_result[0][0]=”ABC/4568/2012-09-08”、 d_result[0][1]=”10000000”、 d_result[0][2]=” DEF Electronics”。
ＧＰＵ１１０の搭載枚数分、この処理を繰り返した後は図７のステップ７１４の処理へ進む。
【０１０６】
図６８は、図７のステップ７１１で表示部１２５またはクライアント６００に出力するエラーメッセージの一例を示す。
エラーメッセージの出力内容は次の3パターン存在する。
一つ目は６８０１のとおりデータ型検証によるエラーの場合である。1行目には「以下の行でデータに誤りが発生しました。」を、2行目には「XPath△:△（誤りのあったＸＰａｔｈ）」を、3行目には「Value△:△（誤りのあった検証対象文字列）」を、4行目には「Data△Type△:△（データ型名）」を表示部１２５またはクライアント６００に出力する。なお、△は半角スペースであるり、以下でも同様である。
二つ目は６８０２のとおりenumeration以外のファセット検証によるエラーの場合である。1行目には「以下の行でデータに誤りが発生しました。」を、2行目には「XPath△:△（誤りのあったＸＰａｔｈ）」を、3行目には「Value△:△（誤りのあった検証対象文字列）」を、4行目には「Data△Type△:△（データ型名）」を、5行目には「Data△Facet△:△（ファセット名）△value=”（ファセットに記載されたvalue値）”」を表示部１２５またはクライアント６００に出力する。
三つ目は６８０３のとおりenumerationでのファセット検証によるエラーの場合である。1行目には「以下の行でデータに誤りが発生しました。」を、2行目には「XPath△:△（誤りのあったＸＰａｔｈ）」を、3行目には「Value△:△（誤りのあった検証対象文字列）」を、4行目には「Data△Type△:△（データ型名）」を、5行目には「Data△Facet△:」を、6行目以降に「enumeration△value=”（ファセットに記載されたvalue値）”」をenumerationファセットの数だけ表示部１２５またはクライアント６００に出力する。
これらの出力のための処理フローについては図６９で説明する。
【０１０７】
図６９は、エラー内容を表示部１２５またはクライアント６００に出力する処理（図７のステップ７１１）の詳細なフローの一例を示す。
最初にデータ検証で誤りが発生した検証対象文字列d_result[i][j]をデバイスメモリ１１１からＣＰＵのホストメモリ（主記憶）１０５にコピーする（ステップ６９０１）。続いて、データ型を表示部１２５またはクライアント６００に出力するために必要なデータ型に対応する数値type[i][j]をデバイスメモリ１１１からＣＰＵのホストメモリ（主記憶）１０５にコピーする（ステップ６９０２）。続いて、type[i][j]と実際に表示部１２５またはクライアント６００に出力する文字列とを対応づけるため、データ型とtype[i][j]に代入する数値一覧（図１７の１７０１および１７０２）をＣＰＵのホストメモリ（主記憶）１０５に読み込む（ステップ６９０３）。読み込み完了後、リラン回数に1を加算し（ステップ６９０４）、内部参照変数type_nameを初期化、type_nameにtype[i][j]に対応するデータ型名を代入する（ステップ６９０５）。その後、表示部１２５またはクライアント６００に以下の文字列を出力させる（ステップ６９０６）。ただし、△は半角スペース、\nは改行、<>は<>内の変数の値（参照先）を示し、出力部分は鍵括弧内のみである。
1行目：「以下の行でデータに誤りが発生しました。\n」
2行目：「XPath△:△<変数d_xpath[i]の(j+1)行目>\n」
3行目：「Value△:△<変数d_results[i][j]>\n」
4行目：「Data△Type△:△<変数type_name>\n」
【０１０８】
続いて、ファセットを表示部１２５またはクライアント６００に出力するために必要なファセットに対応する数値とvalue値のカンマ区切りの組み合わせから構成される文字列condition[i][j][]および図１８の１８０１で初期化および１８１３で値を代入した変数countをデバイスメモリ１１１からＣＰＵのホストメモリ（主記憶）１０５にコピーする（ステップ６９０７）。ここで、デバイスメモリ１１１からＣＰＵのホストメモリ（主記憶）１０５にコピーしたバイト数が0バイトかどうか判定する（ステップ６９０８）。0バイトの場合、データ型検証のエラーの場合である。具体例については図６８の６８０１を参照。この場合、表示部１２５またはクライアント６００への出力処理は終了（ステップ６９１４）し、図７のステップ７１２に進む。
1バイト以上の場合、condition[i][j][]と実際に表示部１２５またはクライアント６００に出力する文字列を対応づけるため、ファセットとcondition[i][j][]に代入する数値一覧（図５３の５３０１）をＣＰＵのホストメモリ（主記憶）１０５に読み込む（ステップ６９０９）。読み込み完了後、内部参照配列変数condition_name[]を初期化し、condition_name[]にcondition[i][j][]が参照している数値に対応するファセット名を代入する（ステップ６９１０）。続いて、condition[i][j][count]が参照している数値が10、つまりファセット名condition_name[0]がenumerationかどうか判定する（ステップ６９１１）。10でない場合、表示部１２５またはクライアント６００に以下の文字列を追加出力させる（ステップ６９１２）。ただし、△は半角スペース、\nは改行、<>は<>内の変数の値（参照先）を示し、出力部分は鍵括弧内のみである。具体例については図６８の６８０２を参照。
5行目：「Data△Facet△:△<condition_name[count]>△<condition[i][j][count]の”value=”以降>\n」
【０１０９】
condition[i][j][count]が参照している数値が10、つまりファセット名condition_name[count]がenumerationである場合、表示部１２５またはクライアント６００に以下の文字列を追加出力させる（ステップ６９１３）。ただし、△は半角スペース、\nは改行、<>は<>内の変数の値（参照先）、n1、n2、…、nkはcondition[i][j][nl]（l=1、2、…、k）が参照している数値が10である数列であり、0＜n1＜n2＜…＜nk＝countを満たす。また、出力部分は鍵括弧内のみである。もちろん、condition[i][j][l]が参照している数値が10であるlの個数はk個である。具体例については図６８の６８０３を参照。
5行目：「Data△Facet△:\n」
6行目：「Enumeration△<condition[i][j][n1]の”value=”以降>\n」
7行目：「Enumeration△<condition[i][j][n2]の”value=”以降>\n」
…
最終行：「Enumeration△<condition[i][j][nk]の”value=”以降>\n」
【０１１０】
以上で表示部１２５またはクライアント６００にエラー内容を出力させる処理は終了（ステップ６９１４）し、図７のステップ７１２に進む。
【０１１１】
図７０は、ロールバック処理（図７のステップ７１３）の詳細なフローの一例を示す。
ロールバック処理は、リランの回数が基準値以上のＧＰＵ１１０のみに対して実行する。つまりこの処理はリランの回数が基準値以上のＧＰＵ１１０の数だけの繰り返しになる（ステップ７００１〜７００３）。繰り返し処理の中ではデバイスメモリ１１１を解放する（ステップ７００２）。メモリ解放処理終了（ステップ７００４）後は図７のステップ７１４に進む。
【０１１２】
図７１は、デバイス部１４０から受信したデータをネットワーク経由で他システムへ送信する処理（図７のステップ７１４）の詳細なフローの一例を示す。
その後、他システム６０２との通信に必要なソケットを作成（ステップ７１０１）、ソケットに名称を付与（ステップ７１０２）、他システム６０２からの接続を許可（ステップ７１０３）した後、他システム６０２からの接続が開始される（ステップ７１０４）。検証済の文字列d_resilts[][]を他システム６０２に送信する（ステップ７１０５）。全文字列の送信終了（ステップ７１０６）後は、図７のステップ７１５に進む。
【０１１３】
以上説明したように、本発明によれば、ＸＭＬスキーマを用いた大量のＸＭＬデータの検証処理を含め、大量のＸＭＬデータに対する処理を高速化することができる。
【符号の説明】
【０１１４】
１０１…ＸＭＬデータ処理装置（サーバ）
１０２…電文ネットワーク（入力部）
１０３…ネットワークストレージ（入力部）（ＳＡＮ／ＮＡＳ）
１０４…ＣＰＵ（中央演算装置）
１０５…ホストメモリ（主記憶）
１０６…外部Ｉ／Ｆ（ＰＣＩ  Ｅｘｐｒｅｓｓ）
１０７…メモリＩ／Ｆ
１０８…内部ストレージ（入力部）（ＳＡＳ／ＳＡＴＡ）
１０９…内部Ｉ／Ｆ（ＰＣＩ  Ｅｘｐｒｅｓｓ）
１１０…ＧＰＵ（並列処理装置）
１１１…デバイスメモリ
１１２…計算コア群
１１３…広帯域メモリＩ／Ｆ
１２１…内部ストレージ（出力部）（ＳＡＳ／ＳＡＴＡ）
１２２…電文ネットワーク（出力部）
１２３…ネットワークストレージ（出力部）（ＳＡＮ／ＮＡＳ）
１２５…表示部
１３０…ホスト部
１４０…デバイス部
２０１…処理対象データ
２０２…分割して受信したＸＭＬ
３０１…取得対象関連タグ情報
３０２…取得対象位置情報（ＸＰａｔｈ）
３０３…検証対象データ
３０４…３０１の場合におけるtransition_table変数が参照している文字列
４０１、４０２、５０１、５０２…ＸＭＬスキーマ
４０３…タグの値のデータ型がｓｔｒｉｎｇ（文字列）型
４０４…「タグの値のデータは任意の７文字である。」という制約
４０５…タグの値のデータ型がｄａｔｅ（日付）型
５０３…「タグの値のデータは『任意の８文字／４桁の数字−01〜12のいずれか−00〜39のいずれか』である。」という制約
５０４…タグの値のデータ型がｎｏｎＮｅｇａｔｉｖｅＩｎｔｅｇｅｒ（非負整数）型
６００…クライアント
６０１…入力：処理実行命令、出力：検査結果
６０２…他システム
６０３…入力：ＸＭＬデータ／取得対象関連タグ情報／取得対象位置情報／ＸＭＬスキーマ、出力：取得データ
６１１…流量制御処理
６１２…取得対象関連タグ情報を ホスト部（ＣＰＵ）からデバイス部（ＧＰＵ）へ転送
６２１…ＴｒａｎｓｉｔｉｏｎＴａｂｌｅ生成処理
６３０…ＴｒａｎｓｉｔｉｏｎＴａｂｌｅをデバイス部（ＧＰＵ）からホスト部（ＣＰＵ）へ転送
６４０…分割したＸＭＬデータ／ＴｒａｎｓｉｔｉｏｎＴａｂｌｅ／取得対象位置情報／ＸＭＬスキーマをホスト部（ＣＰＵ）からデバイス部（ＧＰＵ）へ転送
６５１…取得対象文字抜き取り処理
６５２…ＸＭＬスキーマによる検証処理
６６０…取得文字列／検証結果をデバイス部（ＧＰＵ）からホスト部（ＣＰＵ）へ転送
１００１…入力するパターン文字列の例
１００２…１００１の入力に対して生成されるＴｒａｎｓｉｔｉｏｎＴａｂｌｅ
１７０１、１７０２…データ型とそれに対応する数値
５３０１…ファセットとそれに対応する数値
６８０１…データ型検証によるエラーメッセージの例
６８０２…ｅｎｕｍｅｒａｔｉｏｎ以外のファセット検証によるエラーメッセージの例
６８０３…ｅｎｕｍｅｒａｔｉｏｎのファセット検証によるエラーメッセージの例
【図１】
2015106293.tif 000003
【図２】
2015106293.tif 000004
【図３】
2015106293.tif 000005
【図４】
2015106293.tif 000006
【図５】
2015106293.tif 000007
【図６】
2015106293.tif 000008
【図７】
2015106293.tif 000009
【図８】
2015106293.tif 000010
【図９】
2015106293.tif 000011
【図１０】
2015106293.tif 000012
【図１１】
2015106293.tif 000013
【図１２】
2015106293.tif 000014
【図１３】
2015106293.tif 000015
【図１４】
2015106293.tif 000016
【図１５】
2015106293.tif 000017
【図１６】
2015106293.tif 000018
【図１７】
2015106293.tif 000019
【図１８】
2015106293.tif 000020
【図１９】
2015106293.tif 000021
【図２０】
2015106293.tif 000022
【図２１】
2015106293.tif 000023
【図２２】
2015106293.tif 000024
【図２３】
2015106293.tif 000025
【図２４】
2015106293.tif 000026
【図２５】
2015106293.tif 000027
【図２６】
2015106293.tif 000028
【図２７】
2015106293.tif 000029
【図２８】
2015106293.tif 000030
【図２９】
2015106293.tif 000031
【図３０】
2015106293.tif 000032
【図３１】
2015106293.tif 000033
【図３２】
2015106293.tif 000034
【図３３】
2015106293.tif 000035
【図３４】
2015106293.tif 000036
【図３５】
2015106293.tif 000037
【図３６】
2015106293.tif 000038
【図３７】
2015106293.tif 000039
【図３８】
2015106293.tif 000040
【図３９】
2015106293.tif 000041
【図４０】
2015106293.tif 000042
【図４１】
2015106293.tif 000043
【図４２】
2015106293.tif 000044
【図４３】
2015106293.tif 000045
【図４４】
2015106293.tif 000046
【図４５】
2015106293.tif 000047
【図４６】
2015106293.tif 000048
【図４７】
2015106293.tif 000049
【図４８】
2015106293.tif 000050
【図４９】
2015106293.tif 000051
【図５０】
2015106293.tif 000052
【図５１】
2015106293.tif 000053
【図５２】
2015106293.tif 000054
【図５３】
2015106293.tif 000055
【図５４】
2015106293.tif 000056
【図５５】
2015106293.tif 000057
【図５６】
2015106293.tif 000058
【図５７】
2015106293.tif 000059
【図５８】
2015106293.tif 000060
【図５９】
2015106293.tif 000061
【図６０】
2015106293.tif 000062
【図６１】
2015106293.tif 000063
【図６２】
2015106293.tif 000064
【図６３】
2015106293.tif 000065
【図６４】
2015106293.tif 000066
【図６５】
2015106293.tif 000067
【図６６】
2015106293.tif 000068
【図６７】
2015106293.tif 000069
【図６８】
2015106293.tif 000070
【図６９】
2015106293.tif 000071
【図７０】
2015106293.tif 000072
【図７１】
2015106293.tif 000073