情報処理装置、情報処理方法、プログラム、記録媒体
【課題】状態遷移表を切り替えるデータパターンを予め定義しておき、このデータパターンが解析データから検出されることで状態遷移表を切り替え、障害の原因と対策を提示する。
【解決手段】本発明は、通信データの解析を行う情報処理装置であって、通信データの障害を特定するための状態遷移表を記録する記録手段と、解析対象となる通信データから解析データを作成する作成手段と、前記作成手段により作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出手段と、前記検出手段により検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御手段とを有する。
【解決手段】本発明は、通信データの解析を行う情報処理装置であって、通信データの障害を特定するための状態遷移表を記録する記録手段と、解析対象となる通信データから解析データを作成する作成手段と、前記作成手段により作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出手段と、前記検出手段により検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
ＥＤＩデータ交換装置において発生した障害の記録、検出及び解析の技術に関する。
【背景技術】
【０００２】
近年、企業などにおいては受発注業務における業務効率化のために、電子商取引を行うＥＤＩシステムが導入されている。その多くは、業務内容に即したファイルの転送を行うものだが、業界や取引相手先により、さまざまな通信プロトコルを使い分けなければならないケースが一般的である。
【０００３】
そのため、障害が発生した場合これらのプロトコルに精通している要員の確保が困難であるので、原因の特定や復旧作業に多くの時間やコストが掛かってしまうだけでなく、ビジネスの機会を損失するリスクもあるのが現状である。
【０００４】
このような、ＥＤＩデータ交換装置の障害を自動的に検出し、復旧の時間やコストを軽減する技術として、特許文献１及び２に示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平６−６２０８８
【特許文献２】特開平４−１０７３５
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１の技術では、解析データに１つの状態遷移表だけを用いる方法であり、複数のプロトコル（状態遷移表）が階層構造になっている場合には、対応できない。
【０００７】
また、特許文献２の技術では、解析データはリアルタイムで出力される（実際の通信を行いながら）ため、解析作業中は運用者が常に監視する必要がある。
【０００８】
本発明は、上記課題を解決するものであり、状態遷移表を切り替えるデータパターンを予め定義しておき、このデータパターンが解析データから検出されることで状態遷移表を切り替え、障害の原因と対策を提示することを可能とする。
【課題を解決するための手段】
【０００９】
本発明は、通信データの解析を行う情報処理装置であって、通信データの障害を特定するための状態遷移表を記録する記録手段と、解析対象となる通信データから解析データを作成する作成手段と、前記作成手段により作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出手段と、前記検出手段により検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御手段とを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、状態遷移表を切り替えるデータパターンを予め定義しておき、このデータパターンが解析データから検出されることで状態遷移表を切り替え、障害の原因と対策を提示することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態におけるＥＤＩシステムの構成を示す図である。
【図２】本発明の実施形態における各種端末のハードウェア構成を示す図である。
【図３】本発明の実施形態における運用管理サーバ１０１の機能ブロックを示す図である。
【図４】本発明の実施形態におけるＥＤＩシステムの基本的な処理フローを示す図である。
【図５】本発明の実施形態におけるＥＤＩシステムの解析データテーブルを示す図である。
【図６】本発明の実施形態におけるＥＤＩシステムのエラー情報データテーブルを示す図である。
【図７】本発明の実施形態におけるＥＤＩシステムの通信データ解析処理フローを示す図である。
【図８】本発明の実施形態におけるＥＤＩシステムのプロトコル一覧を示す図である。
【図９】本発明の実施形態におけるＥＤＩシステムのプロトコル属性テーブルを示す図である。
【図１０】本発明の実施形態におけるＥＤＩシステムのＢＳＣイベント判定処理を示す図（１）である。
【図１１】本発明の実施形態におけるＥＤＩシステムのＢＳＣイベント判定処理を示す図（２）である。
【図１２】本発明の実施形態におけるＥＤＩシステムのＢＳＣイベント判定処理を示す図（３）である。
【図１３】本発明の実施形態におけるＥＤＩシステムのＢＳＣイベント判定処理を示す図（４）である。
【図１４】本発明の実施形態におけるＥＤＩシステムのイベント判定テーブルを示す図である。
【図１５】本発明の実施形態におけるＥＤＩシステムのエラー解析処理フローを示す図である。
【図１６】本発明の実施形態におけるＥＤＩシステムのＢＳＣ透過状態遷移表を示す図（１）である。
【図１７】本発明の実施形態におけるＥＤＩシステムのＢＳＣ透過状態遷移表を示す図（２）である。
【図１８】本発明の実施形態におけるＥＤＩシステムの全銀手順状態遷移表を示す図である。
【図１９】本発明の実施形態におけるＥＤＩシステムの全銀ＴＣＰＩＰサブレイヤ状態遷移表を示す図である。
【図２０】本発明の実施形態におけるＥＤＩシステムの状態遷移表−判定処理を示す図である。
【図２１】本発明の実施形態におけるＥＤＩシステムのエラー詳細情報テーブルを示す図である。
【図２２】本発明の実施形態におけるＥＤＩシステムの全銀手順解析対象抽出処理を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１３】
図１は、本発明の実施形態のＥＤＩシステムの構成を示す図である。
【００１４】
通信サーバ１０２とＥＤＩ端末１０３は、ネットワークを介して商取引に関する電子情報であるＥＤＩデータを相互に交換する。運用管理サーバ１０１は、通信サーバ１０２が受信したデータを監視して、ジョブを実行する。
【００１５】
なお、図１のネットワーク上に接続される各種端末の構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００１６】
通信サーバ１０２は、ＥＤＩ通信機能を有し、ＥＤＩ端末１０３との間のデータ交換を行う。ここでいうデータ交換とは、通信可能なＥＤＩプロトコルでＥＤＩデータを送受信することを指す。
【００１７】
次に、図１の運用管理サーバ１０１のハードウェア構成について、図２を用いて説明する。なお、通信サーバ１０２とＥＤＩ端末１０３のハードウェア構成については、同じであるので説明を省略する。
【００１８】
図２は、本発明の実施形態における各種端末のハードウェア構成を示す図である。
【００１９】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２０】
また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。
【００２１】
ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。
【００２２】
また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。
【００２３】
ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。本発明には直接関係があるものではない。
【００２４】
メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピー（登録商標）ディスク或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００２５】
通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００２６】
なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００２７】
本発明を実現するためのＥＤＩ運用管理プログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００２８】
図３は、図１の運用管理サーバ１０１の構成を概略的に示す機能ブロック図である。これらの装置は主にＷｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）などのＯＳを搭載したコンピュータを想定しているが、本発明では、使用ＯＳは特定しない。
【００２９】
通信制御部３０１は、通信実行と通信データを記憶部３０２に記録し、また通信中、記憶部３０４に記録した通信データを基に、主処理を実現するための機能である。また、その結果を表示部３０３の機能を呼び出し、表示させるものである。
【００３０】
記憶部３０２は、通信中のデータ及び、通信終了後の通信データを読み込む機能と、書き込む機能を持つ。
【００３１】
表示部３０３は、記憶部３０２から読み込まれた通信データを元に作成した、通信制御部３０１が作成したエラー情報データを表示するための機能である。
【００３２】
図４は、本発明の実施形態のＥＤＩシステムの基本的な処理フローを示す図である。
【００３３】
まず、ステップＳ４０１において、運用管理サーバ１０１は、通信制御部が記憶部の通信データを基に解析データを作成する。そして、解析の結果、作成した解析データを、解析データテーブルに記録する。図５に解析データテーブルの一例を示す。
【００３４】
解析データテーブル５０は、セッションＮｏ５０１、シーケンスＮｏ５０２、インデックス５０３、方向５０４、日時５０５、データ長５０６、データイメージ５０７の項目を備える。
【００３５】
次に、ステップＳ４０２において、運用管理サーバ１０１は、ステップＳ４０１で作成した解析データテーブル５０から通信中に発生した全エラーを表示部で表示可能なエラー情報データを作成する。作成したエラー情報データは、エラー情報データテーブルに記録する。
【００３６】
図６にエラー情報データテーブルの一例を示す。
【００３７】
エラー情報データテーブル６０は、セッションＮｏ６０１、シーケンスＮｏ６０２、プロトコル名６０３、イベント名６０４、エラーＮｏ６０５の項目を備える。
【００３８】
なお、詳細な処理の説明は後述する。
【００３９】
最後に、ステップＳ４０３において、運用管理サーバ１０１は、ステップＳ４０２で作成したエラー情報データを表示部に表示する処理を行って、全体の処理を終了する。
【００４０】
図７は、図４におけるステップＳ４０２の詳細フローを示す図である。ステップＳ４０２では、状態遷移表に記述された情報をもとに、解析データから通信中のエラーを示すエラー情報データを生成する処理である。
【００４１】
ここでは、全銀ＢＳＣ手順と全銀ＴＣＰＩＰ手順の２つのプロトコルの解析処理が行える例を挙げて以下の説明を行う。全銀ＢＳＣで解析する場合は、図８に示すプロトコル一覧８１を適用する。全銀ＴＣＰＩＰで解析する場合は、図８に示すプロトコル一覧８２を適用する。具体的には、解析データテーブルのセッションＮｏ．とプロトコル一覧を紐付けることで行う。なお、プロトコル一覧には、階層Ｎｏ８０１、プロトコルＮｏ８０２の項目を備える。
【００４２】
ステップＳ５０１において、運用管理サーバ１０１は、はじめに解析する対象のプロトコルＮｏを取得する。具体的には、値０をキーにし、プロトコル一覧８１または８２を検索する。一致したレコードのプロトコルＮｏを取得し、現在処理中のプロトコルＮｏをこの値で更新する。また、現在処理中のイベントコードを値０で更新する。例えば、全銀ＢＳＣの場合、プロトコル一覧８１を適用する。そして、適用したプロトコル一覧８１からプロトコルＮｏ「１」の使用を決定する。
【００４３】
ステップＳ７０２において、運用管理サーバ１０１は、現在処理中のセッションＮｏを運用者が指定した解析対象のセッションＮｏで、現在処理中のシーケンスＮｏを値０で更新する。具体的には、現在処理中のセッションＮｏ「１００」、シーケンスＮｏ「０」となる。
【００４４】
ステップＳ７０３において、運用管理サーバ１０１は、未処理の解析データレコードが存在するかをチェックする。ない場合は、処理を終了し、ある場合は、ステップＳ７０４へ進む。ここでは、具体的には、現在処理中のセッションＮｏ及び、現在処理中のシーケンスＮｏに１を足した値をキーに解析データテーブル５０を検索し、一致するレコードが存在しない場合は、解析対象となるすべての解析データレコードに対し解析済みと判断し、ステップＳ４０２の処理を終了する。一致するレコードが存在した場合はレコードのシーケンスＮｏで現在処理中のシーケンスＮｏを更新する。例えば、図５のセッションＮｏ「１００」、シーケンスＮｏ「１」のレコードが最初の解析対象となる。
【００４５】
ステップＳ７０４において、運用管理サーバ１０１は、解析データレコードのデータイメージを読み込む。例えば、図５のセッションＮｏ「１００」、シーケンスＮｏ「１」のデータイメージを読み込む。なお、ステップＳ７０３で、一致するレコードが１つ以上存在する場合は、インデックスが最大であるものを読み込み対象とし、読み込む。→理由
ステップＳ７０５において、運用管理サーバ１０１は、ステップＳ７０４で読み込んだデータイメージの解析に必要なプロトコル属性を取得する。具体的には、現時処理中のプロトコルＮｏをキーにプロトコル属性テーブルを検索し、一致するレコードを取得する。図９にプロトコル属性テーブルの一例を示す。図９のプロトコル属性テーブル９０の場合、プロトコルＮｏ「１」の属性を解析に使用することが決まる。
【００４６】
ステップＳ７０６において、運用管理サーバ１０１は、現在処理中のプロトコルでの解析範囲を取得する。具体的には、ステップＳ７０５で取得したレコードの解析範囲開始オフセット及び、解析範囲終了オフセットを取得する。このオフセットとは、ステップＳ７０４で読み込んだデータイメージの先頭を０とした値（バイト数）である（以下、本文中で述べるオフセットは同じ意味とする。）。
【００４７】
ここで、全銀ＢＳＣ手順と全銀ＴＣＰＩＰ手順とで処理が異なる。
（１）全銀ＢＳＣ手順の場合
全銀ＢＳＣ手順の場合、最下層のプロトコルＮｏ．は「１」となるので、図９のプロトコルＮｏ「１」の解析範囲開始／終了オフセット値を取得すると、このオフセットは−１となる。負数の場合は、オフセットの値としては無効なので、この値は適用しない。このときは、プロトコル固有の処理の適用となり、絶対値が処理Ｎｏ．となる。例えば、全銀ＢＳＣの場合、解析範囲が一定ではないため、具体値を入れられない。その場合、解析範囲を同定する特殊処理の番号を負数で示す。この例の場合−１なので、処理番号１となる。そして、図１０の処理が実行され、図１０の処理終了後、解析データテーブル５０にデータイメージがイベントコードのみであるレコードが追加される。
例えば、解析対象のデータ長が１１バイト「３２３２３２３２２ＤＦＦＦＦＦＦＦＦＦＦＦＦ」の場合、２バイト判定処理（図１１）に移る。図１１において、データは２バイト以上なので、１バイトコードパターンが存在するかをチェックする。このデータ内には「２Ｄ」というコードが含まれている。この結果２Ｄが発生した事象（イベント）となり、この結果を新規レコードとして解析テーブルに追加する。図５のセッションＮｏ「１００」、シーケンスＮｏ「１」、インデックスＮｏ「１」が追加されたレコードである。
（２）全銀ＴＣＰＩＰ手順の場合
全銀ＴＣＰＩＰ手順の場合、最下層のプロトコルＮｏ．は４となるので、開始オフセットは０、終了オフセットは７となる。解析対象のデータセッションＮｏ．１０１、シーケンスＮｏ．１が解析対象レコードの場合解析の範囲は「００４Ｄ１００Ｆ００００００００」となる。
【００４８】
次に、ステップＳ７０７において、運用管理サーバ１０１は、現在処理中のプロトコルでのクオート処理（データ置換）処理の内容を取得する。具体的には、ステップＳ７０６の解析範囲内出現した、全てのクオート処理置換前コードパターンをクオート処理置換後コードパターンで置き換える。
【００４９】
ここで、「クオート処理」とは、エスケープ処理で変換した結果を元に戻す処理である。また、「エスケープ処理」とは、プロトコル毎に決められている特殊に意味を持つコードを、通常のデータとして扱うための変換処理のことである。
【００５０】
（１）全銀ＢＳＣ手順の場合
全銀ＢＳＣ手順の場合、現在処理中のプロトコルＮｏに依存する。
プロトコルＮｏが「１」の場合、クオート処理置換前コードパターン及び、クオート処理置換後コードパターンの記述がない。この場合はクオート処理を行わない。
プロトコルＮｏが「２」の場合、クオート処理置換前コードパターン「１０１０」、クオート処理置換後コードパターンは「１０」なので、「１０１０」は「１０」に置き換えられる。
（２）全銀ＴＣＰＩＰ手順の場合
全銀ＴＣＰＩＰ手順の場合、プロトコルＮｏ「４」、「５」、「６」のいずれかが適用されるがいずれもクオート処理置換前コードパターン及び、クオート処理置換後コードパターンの記述がない。そのため、クオート処理は行われない。
【００５１】
次に、ステップＳ７０８において、運用管理サーバ１０１は、現在処理中の解析データが、現在処理中のプロトコルで、どのイベントに該当するかを取得する。具体的には、ステップＳ７０５で取得したレコードのイベント判定位置開始オフセット及び、イベント判定位置終了オフセットを取得する。現在処理中の解析データにこの値の位置のコードを取得する。次に、このコードと現在処理中のプロトコルＮｏをキーにイベント判定テーブルを検索し、一致するレコードを取得する。一致するレコードが存在しない場合は、プロトコル上、定義されていないイベントが発生したとする。一致するレコードが存在した場合、現在処理中のイベントコードをこのコードで、更新する。図１４にイベント判定テーブルの一例を示す。
【００５２】
（１）全銀ＢＳＣ手順の場合
全銀ＢＳＣ手順の場合、最下層のプロトコルＮｏは「１」となるので、このオフセットの記述がない。この場合、イベント取得処理は行わない。
（２）全銀ＴＣＰＩＰ手順の場合
全銀ＴＣＰＩＰ手順の場合、最下層のプロトコルＮｏは「４」となるので、開始オフセットは２、終了オフセットも２となる。解析対象のデータセッションＮｏ「１０１」、シーケンスＮｏ「１」が解析対象レコードの場合イベントとするコードは、「１０」となる。プロトコルＮｏ「４」、及びコード「１０」をキーとして、イベント判定テーブル１４００を検索すると、全銀ＴＣＰＩＰサブレイヤのテキストイベントであることが分かる。現在処理中のイベントコードを「１０」で更新する。
【００５３】
次に、ステップＳ７０９において、運用管理サーバ１０１は、現在処理中のプロトコルに状態遷移表が存在するかを判定する。具体的には、ステップＳ７０５で取得したレコードの状態遷移表Ｎｏを取得する。存在する場合は、ステップＳ７１０へ進みエラー解析処理を行う。存在しない場合はステップＳ７１１へ進む。
【００５４】
ステップＳ７１０において、運用管理サーバ１０１は、エラー解析処理を行う。本処理の詳細を、図１５を用いて説明する。
【００５５】
図１５は、状態遷移表（図１６乃至１９を参照）を、状態Ｎｏイベントコードをキーにプロトコル上のエラーが、解析データレコードに発生しているかを調べる処理を示す図である。
【００５６】
図１６および１７は、ＢＳＣ透過状態遷移表（状態遷移表Ｎｏ．１）の一例を示す表である。
【００５７】
図１８は、全銀手順状態遷移表（状態遷移表Ｎｏ．２）の一例を示す表である。
【００５８】
図１９は、銀ＴＣＰＩＰサブレイヤ状態遷移表（状態遷移表Ｎｏ．３）の一例を示す表である。
【００５９】
ステップＳ１５０１において、運用管理サーバ１０１は、状態遷移表Ｎｏと、状態Ｎｏイベントコードをキーとし、状態遷移表から取得したエラー判定処理の処理内容を実行する。
【００６０】
図１６（状態遷移表Ｎｏ．１）を例とすると、解析の最初なので、状態番号１（ＥＮＱ（２Ｄ）待ち）となる。
イベントコードはステップＳ７０８で取得されていないので、セッションＮｏ「１００」、シーケンスＮｏ「１」で解析データテーブル５０を検索すると、該当のレコードが２件見つかる。このうちインデックスＮｏが最大のものをイベントコードとする。この場合イベントコードは（ＥＮＱ（２Ｄ））となる。この２つの条件に一致するエラー判定条件処理を実行する。この場合、図２０の処理が実行される。
【００６１】
ステップＳ２００１において、運用管理サーバ１０１は、現在処理中のセッションＮｏ．と１つ大きいシーケンスＮｏ．をキーに解析データテーブル５０を検索する。
【００６２】
ステップＳ２００２において、運用管理サーバ１０１は、解析データがあるかを判定する。Ｙｅｓの場合、２００５へ進み、Ｎｏの場合、２００３へ進む。
【００６３】
ステップＳ２００３において、運用管理サーバ１０１は、解析データの方向（受信／送信）を取得する。
【００６４】
ステップＳ２００４において、運用管理サーバ１０１は、ＢＳＣイベント判定処理を行う。この処理は、図１０に示す処理である。
【００６５】
図１０乃至１３を用いて、ＢＳＣイベント判定処理の詳細を説明する。
【００６６】
ステップＳ１００１において、運用管理サーバ１０１は、データは２バイト以上かを判定する。Ｙｅｓの場合、ステップＳ１００７へ進み、Ｎｏの場合、ステップＳ１００２へ進む。
【００６７】
ステップＳ１００２において、運用管理サーバ１０１は、１バイトコードがあるかを判定する。Ｙｅｓの場合、ステップＳ１００３へ進み、Ｎｏの場合、ステップＳ１００６へ進む。
【００６８】
ステップＳ１００３において、運用管理サーバ１０１は、１バイトイベントとする。
【００６９】
ステップＳ１００４において、運用管理サーバ１０１は、同定したイベントコードをデータイメージに格納したレコードを解析データテーブルに追加する。セッションＮｏ．シーケンスＮｏ．は現在値としインデックス値を＋１とする。
【００７０】
ステップＳ１００５において、運用管理サーバ１０１は、現在処理中のイベントコードを更新する。
【００７１】
ステップＳ１００６において、運用管理サーバ１０１は、不正イベントとする。
【００７２】
ステップＳ１００７において、運用管理サーバ１０１は、２バイト判定処理を行う。この処理の詳細は、後に説明する。
【００７３】
ステップＳ１００８において、運用管理サーバ１０１は、不正イベントであるかを判定する。Ｙｅｓの場合、ステップＳ１００６へ進み、Ｎｏの場合、ステップＳ１００９へ進む。
【００７４】
ステップＳ１００９において、運用管理サーバ１０１は、１／２バイトまた電文イベントとする。
【００７５】
図１１は、２バイト判定処理の詳細なフローである。
【００７６】
ステップＳ１１０１において、運用管理サーバ１０１は、データは２バイトであるかを判定する。Ｙｅｓの場合、ステップＳ１１０２へ進み、Ｎｏの場合、ステップＳ１１０５へ進む。
【００７７】
ステップＳ１１０２において、運用管理サーバ１０１は、１バイトコードパターンａ）、ｂ）があるかを判定する。Ｙｅｓの場合、ステップＳ１１０３へ進み、Ｎｏの場合、ステップＳ１１０４へ進む。
【００７８】
ステップＳ１１０３において、運用管理サーバ１０１は、１バイトイベントとする。
【００７９】
ステップＳ１１０４において、運用管理サーバ１０１は、不正イベントとする。
【００８０】
ステップＳ１１０５において、運用管理サーバ１０１は、３バイト判定処理を行う。この処理の詳細は、後に説明する。
【００８１】
ステップＳ１１０６において、運用管理サーバ１０１は、不正イベントであるかを判定する。Ｙｅｓの場合、ステップＳ１１０４へ進み、Ｎｏの場合、ステップＳ１１０７へ進む。
【００８２】
ステップＳ１１０７において、運用管理サーバ１０１は、１また２バイトイベントとする。
【００８３】
図１２は、３バイト判定処理の詳細なフローである。
【００８４】
ステップＳ１２０１において、運用管理サーバ１０１は、データは３バイトであるかを判定する。Ｙｅｓの場合、ステップＳ１２０２へ進み、Ｎｏの場合、ステップＳ１２０５へ進む。
【００８５】
ステップＳ１２０２において、運用管理サーバ１０１は、１バイトコードパターンｃ）または２バイトコードパターンａ）、ｂ）があるかを判定する。Ｙｅｓの場合、ステップＳ１２０３へ進み、Ｎｏの場合、ステップＳ１２０４へ進む。
【００８６】
ステップＳ１２０３において、運用管理サーバ１０１は、１また２バイトイベントとする。
【００８７】
ステップＳ１２０４において、運用管理サーバ１０１は、不正イベントとする。
【００８８】
ステップＳ１２０５において、運用管理サーバ１０１は、４バイト判定処理を行う。この処理の詳細は、後に説明する。
【００８９】
ステップＳ１２０６において、運用管理サーバ１０１は、不正イベントであるかを判定する。Ｙｅｓの場合、ステップＳ１２０４へ進み、Ｎｏの場合、ステップＳ１２０７へ進む。
【００９０】
ステップＳ１２０７において、運用管理サーバ１０１は、２また電文（１００２）イベントとする。
【００９１】
図１３は、４バイト判定処理の詳細なフローである。
【００９２】
ステップＳ１３０１において、運用管理サーバ１０１は、データは４バイトであるかを判定する。Ｙｅｓの場合、ステップＳ１３０２へ進み、Ｎｏの場合、ステップＳ１３０５へ進む。
【００９３】
ステップＳ１３０２において、運用管理サーバ１０１は、２バイトコードパターンｃ）があるかを判定する。Ｙｅｓの場合、ステップＳ１３０３へ進み、Ｎｏの場合、ステップＳ１３０４へ進む。
【００９４】
ステップＳ１３０３において、運用管理サーバ１０１は、２バイトイベントとする。
【００９５】
ステップＳ１３０４において、運用管理サーバ１０１は、不正イベントとする。
【００９６】
ステップＳ１３０５において、運用管理サーバ１０１は、電文コードパターンがあるかを判定する。Ｙｅｓの場合、ステップＳ１３０４へ進み、Ｎｏの場合、ステップＳ１３０６へ進む。
【００９７】
ステップＳ１３０６において、運用管理サーバ１０１は、電文イベントとする。
【００９８】
ステップＳ１３０７において、運用管理サーバ１０１は、解析データテーブルに新規レコードを追加する。
【００９９】
次に、ステップＳ２００５において、運用管理サーバ１０１は、解析データなしとする。
【０１００】
ステップＳ２００６において、運用管理サーバ１０１は、現在処理中のセッションＮｏ、シーケンスＮｏ．をキーに解析データテーブルを検索し、最大インデックスのレコードのイメージデータを再読み込みする。
【０１０１】
例えば、現在処理中のセッションＮｏ「１００」、シーケンスＮｏ「１」＋「１」＝「２」を条件に解析データテーブル５０を検索する。この例では２レコード目が取得できる。このレコードから送信、データ長１３バイトが解り、データイメージを図１０の処理に適用することとなる。
【０１０２】
この結果、解析データテーブル５０にセッションＮｏ「１００」、シーケンスＮｏ「２」、インデックスＮｏ「１」のレコードが追加される。
【０１０３】
この後、セッションＮｏ「１００」、シーケンスＮｏ「２」で解析データテーブル５０を検索すると、該当レコードが２件見つかる。このうちインデックスＮｏが最大のものをイベントコードとする。この場合イベントコードは（ＡＣＫ０−１０７０）となる。
【０１０４】
次に、ステップＳ１５０２において、運用管理サーバ１０１は、同じ状態遷移表の判定条件をステップＳ１５０１で取得したイベントコードをキーに検索する。検索した結果、異常の条件と一致した場合は、ステップＳ１５０４へ、正常の条件と一致した場合はステップＳ１５０３へ処理が進む。例えば、図２０の処理結果より、ＡＣＫ０を送信したことが解る。判定条件に照らし合わせると、これは正常であることが解る。
【０１０５】
ステップＳ１５０３において、運用管理サーバ１０１は、現在処理中の状態遷移表Ｎｏと、状態Ｎｏイベントコードをキーとし、状態遷移表から取得したエラー判定処理の判定結果（正常：遷移先状態Ｎｏ．）から、状態遷移表の状態Ｎｏを遷移先状態Ｎｏで更新する。正常なので、遷移先状態Ｎｏは「２」であるので状態番号を「２」で更新する。
【０１０６】
Ｓ１５０４において、運用管理サーバ１０１は、現在処理中の解析データレコードのセッションＮｏ及びシーケンスＮｏを取得する。また、現在処理中の状態遷移表Ｎｏと、状態Ｎｏイベントコードをキーとし、状態遷移表から取得したエラー判定処理の判定結果（異常：エラーＮｏ．）から、エラー情報データレコードを作成し、エラー情報データテーブル６０の最後尾に追加する。
【０１０７】
次に、ステップＳ７１１において、運用管理サーバ１０１は、上位プロトコルへの切り替えが発生するかを取得する。具体的には、ステップＳ７０８で判定した、現在処理中のイベントコードと、プロトコルＮｏ．をキーにイベント判定テーブル１４００を検索する。一致するレコードが存在しないか、または一致するレコードがあった場合でも、レコードの上位遷移先階層Ｎｏ．が存在しない場合は、上位の状態遷移表への切り替えは発生しないので、ステップＳ７１４へ進む。
【０１０８】
反対に一致するレコードが存在し、かつレコードの上位遷移先階層Ｎｏ．が存在する場合は上位の状態遷移表への切り替えが発生する。その場合、ステップＳ７１２とステップＳ７１３で上位遷移先階層Ｎｏ．をキーにプロトコル一覧テーブルを検索し、一致したレコードのプロトコルＮｏ．を取得する。取得したプロトコルＮｏ．で現在処理中のプロトコルＮｏ．を更新し、ステップＳ７０５へ戻る。
【０１０９】
例えば、現在処理中のセッションＮｏ「１００」、シーケンスＮｏ「１」で解析データテーブル５０を検索すると、該当のレコードが２件見つかる。このうちインデックスＮｏが最大のものをイベントコードとする。この場合イベントコードは（ＥＮＱ−２Ｄ）となる。イベント判定テーブル１４００上のプロトコルＮｏ「１」に「２Ｄ」のコードは存在しないので、階層の移動は発生しない。
【０１１０】
次に、ステップＳ７１４において、運用管理サーバ１０１は、下位プロトコルへの切り替えが発生するかを取得する。具体的には、ステップＳ７０８で判定した、現在処理中のイベントコードと、プロトコルＮｏ．をキーにイベント判定テーブル１４００を検索する。一致するレコードが存在しないか、または一致するレコードがあった場合でも、レコードの下位遷移先階層Ｎｏ．が存在しない場合は、下位の状態遷移表への切り替えは発生しないので、ステップＳ７０３へ戻る。
【０１１１】
反対に一致するレコードが存在し、かつレコードの下位遷移先階層Ｎｏ．が存在する場合は下位の状態遷移表への切り替えが発生する。その場合、ステップＳ７１５とステップＳ７１６で下位遷移先階層Ｎｏ．をキーにプロトコル一覧テーブルを検索し、一致したレコードのプロトコルＮｏ．を取得する。取得したプロトコルＮｏ．で現在処理中のプロトコルＮｏ．を更新し、ステップＳ７０３へ戻る。
【０１１２】
ステップＳ７０３において、ここまでの繰り返しで、発生した全エラーのエラー情報データテーブルが作成される。
【０１１３】
エラー詳細情報テーブル２１００は、ステップＳ７２０で作成されたエラー情報データレコードの状態遷移表Ｎｏ．とエラーＮｏ．をキーに検索され、一致したレコードの詳細情報１と詳細情報２が取得される。取得された詳細情報１および２は、ステップＳ４０３で通信制御部３０１が表示部３０３にエラー情報を表示させる際に使用される。
【０１１４】
以上、図４におけるステップＳ４０２の詳細フローを説明した。
【０１１５】
上述した通り、本発明によれば、状態遷移表を切り替えるデータパターンを予め定義しておき、このデータパターンが解析データから検出されることで状態遷移表を切り替え、障害の原因と対策を提示することが可能となる。
【０１１６】
また、本発明では解析データを通信セッション毎に記録・蓄積しておくため、解析作業中は運用者が常に監視する必要がないだけでなく、発生頻度が少ない、潜在的な障害も洩らすことなく検出し、原因の特定及び対策の提示が可能となる。
【０１１７】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１１８】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【符号の説明】
【０１１９】
１０１ 運用管理サーバ
１０２ 通信サーバ
１０３ ＥＤＩ端末
１０４ ネットワーク
【技術分野】
【０００１】
ＥＤＩデータ交換装置において発生した障害の記録、検出及び解析の技術に関する。
【背景技術】
【０００２】
近年、企業などにおいては受発注業務における業務効率化のために、電子商取引を行うＥＤＩシステムが導入されている。その多くは、業務内容に即したファイルの転送を行うものだが、業界や取引相手先により、さまざまな通信プロトコルを使い分けなければならないケースが一般的である。
【０００３】
そのため、障害が発生した場合これらのプロトコルに精通している要員の確保が困難であるので、原因の特定や復旧作業に多くの時間やコストが掛かってしまうだけでなく、ビジネスの機会を損失するリスクもあるのが現状である。
【０００４】
このような、ＥＤＩデータ交換装置の障害を自動的に検出し、復旧の時間やコストを軽減する技術として、特許文献１及び２に示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平６−６２０８８
【特許文献２】特開平４−１０７３５
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１の技術では、解析データに１つの状態遷移表だけを用いる方法であり、複数のプロトコル（状態遷移表）が階層構造になっている場合には、対応できない。
【０００７】
また、特許文献２の技術では、解析データはリアルタイムで出力される（実際の通信を行いながら）ため、解析作業中は運用者が常に監視する必要がある。
【０００８】
本発明は、上記課題を解決するものであり、状態遷移表を切り替えるデータパターンを予め定義しておき、このデータパターンが解析データから検出されることで状態遷移表を切り替え、障害の原因と対策を提示することを可能とする。
【課題を解決するための手段】
【０００９】
本発明は、通信データの解析を行う情報処理装置であって、通信データの障害を特定するための状態遷移表を記録する記録手段と、解析対象となる通信データから解析データを作成する作成手段と、前記作成手段により作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出手段と、前記検出手段により検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御手段とを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、状態遷移表を切り替えるデータパターンを予め定義しておき、このデータパターンが解析データから検出されることで状態遷移表を切り替え、障害の原因と対策を提示することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態におけるＥＤＩシステムの構成を示す図である。
【図２】本発明の実施形態における各種端末のハードウェア構成を示す図である。
【図３】本発明の実施形態における運用管理サーバ１０１の機能ブロックを示す図である。
【図４】本発明の実施形態におけるＥＤＩシステムの基本的な処理フローを示す図である。
【図５】本発明の実施形態におけるＥＤＩシステムの解析データテーブルを示す図である。
【図６】本発明の実施形態におけるＥＤＩシステムのエラー情報データテーブルを示す図である。
【図７】本発明の実施形態におけるＥＤＩシステムの通信データ解析処理フローを示す図である。
【図８】本発明の実施形態におけるＥＤＩシステムのプロトコル一覧を示す図である。
【図９】本発明の実施形態におけるＥＤＩシステムのプロトコル属性テーブルを示す図である。
【図１０】本発明の実施形態におけるＥＤＩシステムのＢＳＣイベント判定処理を示す図（１）である。
【図１１】本発明の実施形態におけるＥＤＩシステムのＢＳＣイベント判定処理を示す図（２）である。
【図１２】本発明の実施形態におけるＥＤＩシステムのＢＳＣイベント判定処理を示す図（３）である。
【図１３】本発明の実施形態におけるＥＤＩシステムのＢＳＣイベント判定処理を示す図（４）である。
【図１４】本発明の実施形態におけるＥＤＩシステムのイベント判定テーブルを示す図である。
【図１５】本発明の実施形態におけるＥＤＩシステムのエラー解析処理フローを示す図である。
【図１６】本発明の実施形態におけるＥＤＩシステムのＢＳＣ透過状態遷移表を示す図（１）である。
【図１７】本発明の実施形態におけるＥＤＩシステムのＢＳＣ透過状態遷移表を示す図（２）である。
【図１８】本発明の実施形態におけるＥＤＩシステムの全銀手順状態遷移表を示す図である。
【図１９】本発明の実施形態におけるＥＤＩシステムの全銀ＴＣＰＩＰサブレイヤ状態遷移表を示す図である。
【図２０】本発明の実施形態におけるＥＤＩシステムの状態遷移表−判定処理を示す図である。
【図２１】本発明の実施形態におけるＥＤＩシステムのエラー詳細情報テーブルを示す図である。
【図２２】本発明の実施形態におけるＥＤＩシステムの全銀手順解析対象抽出処理を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１３】
図１は、本発明の実施形態のＥＤＩシステムの構成を示す図である。
【００１４】
通信サーバ１０２とＥＤＩ端末１０３は、ネットワークを介して商取引に関する電子情報であるＥＤＩデータを相互に交換する。運用管理サーバ１０１は、通信サーバ１０２が受信したデータを監視して、ジョブを実行する。
【００１５】
なお、図１のネットワーク上に接続される各種端末の構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００１６】
通信サーバ１０２は、ＥＤＩ通信機能を有し、ＥＤＩ端末１０３との間のデータ交換を行う。ここでいうデータ交換とは、通信可能なＥＤＩプロトコルでＥＤＩデータを送受信することを指す。
【００１７】
次に、図１の運用管理サーバ１０１のハードウェア構成について、図２を用いて説明する。なお、通信サーバ１０２とＥＤＩ端末１０３のハードウェア構成については、同じであるので説明を省略する。
【００１８】
図２は、本発明の実施形態における各種端末のハードウェア構成を示す図である。
【００１９】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２０】
また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。
【００２１】
ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。
【００２２】
また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。
【００２３】
ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。本発明には直接関係があるものではない。
【００２４】
メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピー（登録商標）ディスク或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００２５】
通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００２６】
なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００２７】
本発明を実現するためのＥＤＩ運用管理プログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００２８】
図３は、図１の運用管理サーバ１０１の構成を概略的に示す機能ブロック図である。これらの装置は主にＷｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）などのＯＳを搭載したコンピュータを想定しているが、本発明では、使用ＯＳは特定しない。
【００２９】
通信制御部３０１は、通信実行と通信データを記憶部３０２に記録し、また通信中、記憶部３０４に記録した通信データを基に、主処理を実現するための機能である。また、その結果を表示部３０３の機能を呼び出し、表示させるものである。
【００３０】
記憶部３０２は、通信中のデータ及び、通信終了後の通信データを読み込む機能と、書き込む機能を持つ。
【００３１】
表示部３０３は、記憶部３０２から読み込まれた通信データを元に作成した、通信制御部３０１が作成したエラー情報データを表示するための機能である。
【００３２】
図４は、本発明の実施形態のＥＤＩシステムの基本的な処理フローを示す図である。
【００３３】
まず、ステップＳ４０１において、運用管理サーバ１０１は、通信制御部が記憶部の通信データを基に解析データを作成する。そして、解析の結果、作成した解析データを、解析データテーブルに記録する。図５に解析データテーブルの一例を示す。
【００３４】
解析データテーブル５０は、セッションＮｏ５０１、シーケンスＮｏ５０２、インデックス５０３、方向５０４、日時５０５、データ長５０６、データイメージ５０７の項目を備える。
【００３５】
次に、ステップＳ４０２において、運用管理サーバ１０１は、ステップＳ４０１で作成した解析データテーブル５０から通信中に発生した全エラーを表示部で表示可能なエラー情報データを作成する。作成したエラー情報データは、エラー情報データテーブルに記録する。
【００３６】
図６にエラー情報データテーブルの一例を示す。
【００３７】
エラー情報データテーブル６０は、セッションＮｏ６０１、シーケンスＮｏ６０２、プロトコル名６０３、イベント名６０４、エラーＮｏ６０５の項目を備える。
【００３８】
なお、詳細な処理の説明は後述する。
【００３９】
最後に、ステップＳ４０３において、運用管理サーバ１０１は、ステップＳ４０２で作成したエラー情報データを表示部に表示する処理を行って、全体の処理を終了する。
【００４０】
図７は、図４におけるステップＳ４０２の詳細フローを示す図である。ステップＳ４０２では、状態遷移表に記述された情報をもとに、解析データから通信中のエラーを示すエラー情報データを生成する処理である。
【００４１】
ここでは、全銀ＢＳＣ手順と全銀ＴＣＰＩＰ手順の２つのプロトコルの解析処理が行える例を挙げて以下の説明を行う。全銀ＢＳＣで解析する場合は、図８に示すプロトコル一覧８１を適用する。全銀ＴＣＰＩＰで解析する場合は、図８に示すプロトコル一覧８２を適用する。具体的には、解析データテーブルのセッションＮｏ．とプロトコル一覧を紐付けることで行う。なお、プロトコル一覧には、階層Ｎｏ８０１、プロトコルＮｏ８０２の項目を備える。
【００４２】
ステップＳ５０１において、運用管理サーバ１０１は、はじめに解析する対象のプロトコルＮｏを取得する。具体的には、値０をキーにし、プロトコル一覧８１または８２を検索する。一致したレコードのプロトコルＮｏを取得し、現在処理中のプロトコルＮｏをこの値で更新する。また、現在処理中のイベントコードを値０で更新する。例えば、全銀ＢＳＣの場合、プロトコル一覧８１を適用する。そして、適用したプロトコル一覧８１からプロトコルＮｏ「１」の使用を決定する。
【００４３】
ステップＳ７０２において、運用管理サーバ１０１は、現在処理中のセッションＮｏを運用者が指定した解析対象のセッションＮｏで、現在処理中のシーケンスＮｏを値０で更新する。具体的には、現在処理中のセッションＮｏ「１００」、シーケンスＮｏ「０」となる。
【００４４】
ステップＳ７０３において、運用管理サーバ１０１は、未処理の解析データレコードが存在するかをチェックする。ない場合は、処理を終了し、ある場合は、ステップＳ７０４へ進む。ここでは、具体的には、現在処理中のセッションＮｏ及び、現在処理中のシーケンスＮｏに１を足した値をキーに解析データテーブル５０を検索し、一致するレコードが存在しない場合は、解析対象となるすべての解析データレコードに対し解析済みと判断し、ステップＳ４０２の処理を終了する。一致するレコードが存在した場合はレコードのシーケンスＮｏで現在処理中のシーケンスＮｏを更新する。例えば、図５のセッションＮｏ「１００」、シーケンスＮｏ「１」のレコードが最初の解析対象となる。
【００４５】
ステップＳ７０４において、運用管理サーバ１０１は、解析データレコードのデータイメージを読み込む。例えば、図５のセッションＮｏ「１００」、シーケンスＮｏ「１」のデータイメージを読み込む。なお、ステップＳ７０３で、一致するレコードが１つ以上存在する場合は、インデックスが最大であるものを読み込み対象とし、読み込む。→理由
ステップＳ７０５において、運用管理サーバ１０１は、ステップＳ７０４で読み込んだデータイメージの解析に必要なプロトコル属性を取得する。具体的には、現時処理中のプロトコルＮｏをキーにプロトコル属性テーブルを検索し、一致するレコードを取得する。図９にプロトコル属性テーブルの一例を示す。図９のプロトコル属性テーブル９０の場合、プロトコルＮｏ「１」の属性を解析に使用することが決まる。
【００４６】
ステップＳ７０６において、運用管理サーバ１０１は、現在処理中のプロトコルでの解析範囲を取得する。具体的には、ステップＳ７０５で取得したレコードの解析範囲開始オフセット及び、解析範囲終了オフセットを取得する。このオフセットとは、ステップＳ７０４で読み込んだデータイメージの先頭を０とした値（バイト数）である（以下、本文中で述べるオフセットは同じ意味とする。）。
【００４７】
ここで、全銀ＢＳＣ手順と全銀ＴＣＰＩＰ手順とで処理が異なる。
（１）全銀ＢＳＣ手順の場合
全銀ＢＳＣ手順の場合、最下層のプロトコルＮｏ．は「１」となるので、図９のプロトコルＮｏ「１」の解析範囲開始／終了オフセット値を取得すると、このオフセットは−１となる。負数の場合は、オフセットの値としては無効なので、この値は適用しない。このときは、プロトコル固有の処理の適用となり、絶対値が処理Ｎｏ．となる。例えば、全銀ＢＳＣの場合、解析範囲が一定ではないため、具体値を入れられない。その場合、解析範囲を同定する特殊処理の番号を負数で示す。この例の場合−１なので、処理番号１となる。そして、図１０の処理が実行され、図１０の処理終了後、解析データテーブル５０にデータイメージがイベントコードのみであるレコードが追加される。
例えば、解析対象のデータ長が１１バイト「３２３２３２３２２ＤＦＦＦＦＦＦＦＦＦＦＦＦ」の場合、２バイト判定処理（図１１）に移る。図１１において、データは２バイト以上なので、１バイトコードパターンが存在するかをチェックする。このデータ内には「２Ｄ」というコードが含まれている。この結果２Ｄが発生した事象（イベント）となり、この結果を新規レコードとして解析テーブルに追加する。図５のセッションＮｏ「１００」、シーケンスＮｏ「１」、インデックスＮｏ「１」が追加されたレコードである。
（２）全銀ＴＣＰＩＰ手順の場合
全銀ＴＣＰＩＰ手順の場合、最下層のプロトコルＮｏ．は４となるので、開始オフセットは０、終了オフセットは７となる。解析対象のデータセッションＮｏ．１０１、シーケンスＮｏ．１が解析対象レコードの場合解析の範囲は「００４Ｄ１００Ｆ００００００００」となる。
【００４８】
次に、ステップＳ７０７において、運用管理サーバ１０１は、現在処理中のプロトコルでのクオート処理（データ置換）処理の内容を取得する。具体的には、ステップＳ７０６の解析範囲内出現した、全てのクオート処理置換前コードパターンをクオート処理置換後コードパターンで置き換える。
【００４９】
ここで、「クオート処理」とは、エスケープ処理で変換した結果を元に戻す処理である。また、「エスケープ処理」とは、プロトコル毎に決められている特殊に意味を持つコードを、通常のデータとして扱うための変換処理のことである。
【００５０】
（１）全銀ＢＳＣ手順の場合
全銀ＢＳＣ手順の場合、現在処理中のプロトコルＮｏに依存する。
プロトコルＮｏが「１」の場合、クオート処理置換前コードパターン及び、クオート処理置換後コードパターンの記述がない。この場合はクオート処理を行わない。
プロトコルＮｏが「２」の場合、クオート処理置換前コードパターン「１０１０」、クオート処理置換後コードパターンは「１０」なので、「１０１０」は「１０」に置き換えられる。
（２）全銀ＴＣＰＩＰ手順の場合
全銀ＴＣＰＩＰ手順の場合、プロトコルＮｏ「４」、「５」、「６」のいずれかが適用されるがいずれもクオート処理置換前コードパターン及び、クオート処理置換後コードパターンの記述がない。そのため、クオート処理は行われない。
【００５１】
次に、ステップＳ７０８において、運用管理サーバ１０１は、現在処理中の解析データが、現在処理中のプロトコルで、どのイベントに該当するかを取得する。具体的には、ステップＳ７０５で取得したレコードのイベント判定位置開始オフセット及び、イベント判定位置終了オフセットを取得する。現在処理中の解析データにこの値の位置のコードを取得する。次に、このコードと現在処理中のプロトコルＮｏをキーにイベント判定テーブルを検索し、一致するレコードを取得する。一致するレコードが存在しない場合は、プロトコル上、定義されていないイベントが発生したとする。一致するレコードが存在した場合、現在処理中のイベントコードをこのコードで、更新する。図１４にイベント判定テーブルの一例を示す。
【００５２】
（１）全銀ＢＳＣ手順の場合
全銀ＢＳＣ手順の場合、最下層のプロトコルＮｏは「１」となるので、このオフセットの記述がない。この場合、イベント取得処理は行わない。
（２）全銀ＴＣＰＩＰ手順の場合
全銀ＴＣＰＩＰ手順の場合、最下層のプロトコルＮｏは「４」となるので、開始オフセットは２、終了オフセットも２となる。解析対象のデータセッションＮｏ「１０１」、シーケンスＮｏ「１」が解析対象レコードの場合イベントとするコードは、「１０」となる。プロトコルＮｏ「４」、及びコード「１０」をキーとして、イベント判定テーブル１４００を検索すると、全銀ＴＣＰＩＰサブレイヤのテキストイベントであることが分かる。現在処理中のイベントコードを「１０」で更新する。
【００５３】
次に、ステップＳ７０９において、運用管理サーバ１０１は、現在処理中のプロトコルに状態遷移表が存在するかを判定する。具体的には、ステップＳ７０５で取得したレコードの状態遷移表Ｎｏを取得する。存在する場合は、ステップＳ７１０へ進みエラー解析処理を行う。存在しない場合はステップＳ７１１へ進む。
【００５４】
ステップＳ７１０において、運用管理サーバ１０１は、エラー解析処理を行う。本処理の詳細を、図１５を用いて説明する。
【００５５】
図１５は、状態遷移表（図１６乃至１９を参照）を、状態Ｎｏイベントコードをキーにプロトコル上のエラーが、解析データレコードに発生しているかを調べる処理を示す図である。
【００５６】
図１６および１７は、ＢＳＣ透過状態遷移表（状態遷移表Ｎｏ．１）の一例を示す表である。
【００５７】
図１８は、全銀手順状態遷移表（状態遷移表Ｎｏ．２）の一例を示す表である。
【００５８】
図１９は、銀ＴＣＰＩＰサブレイヤ状態遷移表（状態遷移表Ｎｏ．３）の一例を示す表である。
【００５９】
ステップＳ１５０１において、運用管理サーバ１０１は、状態遷移表Ｎｏと、状態Ｎｏイベントコードをキーとし、状態遷移表から取得したエラー判定処理の処理内容を実行する。
【００６０】
図１６（状態遷移表Ｎｏ．１）を例とすると、解析の最初なので、状態番号１（ＥＮＱ（２Ｄ）待ち）となる。
イベントコードはステップＳ７０８で取得されていないので、セッションＮｏ「１００」、シーケンスＮｏ「１」で解析データテーブル５０を検索すると、該当のレコードが２件見つかる。このうちインデックスＮｏが最大のものをイベントコードとする。この場合イベントコードは（ＥＮＱ（２Ｄ））となる。この２つの条件に一致するエラー判定条件処理を実行する。この場合、図２０の処理が実行される。
【００６１】
ステップＳ２００１において、運用管理サーバ１０１は、現在処理中のセッションＮｏ．と１つ大きいシーケンスＮｏ．をキーに解析データテーブル５０を検索する。
【００６２】
ステップＳ２００２において、運用管理サーバ１０１は、解析データがあるかを判定する。Ｙｅｓの場合、２００５へ進み、Ｎｏの場合、２００３へ進む。
【００６３】
ステップＳ２００３において、運用管理サーバ１０１は、解析データの方向（受信／送信）を取得する。
【００６４】
ステップＳ２００４において、運用管理サーバ１０１は、ＢＳＣイベント判定処理を行う。この処理は、図１０に示す処理である。
【００６５】
図１０乃至１３を用いて、ＢＳＣイベント判定処理の詳細を説明する。
【００６６】
ステップＳ１００１において、運用管理サーバ１０１は、データは２バイト以上かを判定する。Ｙｅｓの場合、ステップＳ１００７へ進み、Ｎｏの場合、ステップＳ１００２へ進む。
【００６７】
ステップＳ１００２において、運用管理サーバ１０１は、１バイトコードがあるかを判定する。Ｙｅｓの場合、ステップＳ１００３へ進み、Ｎｏの場合、ステップＳ１００６へ進む。
【００６８】
ステップＳ１００３において、運用管理サーバ１０１は、１バイトイベントとする。
【００６９】
ステップＳ１００４において、運用管理サーバ１０１は、同定したイベントコードをデータイメージに格納したレコードを解析データテーブルに追加する。セッションＮｏ．シーケンスＮｏ．は現在値としインデックス値を＋１とする。
【００７０】
ステップＳ１００５において、運用管理サーバ１０１は、現在処理中のイベントコードを更新する。
【００７１】
ステップＳ１００６において、運用管理サーバ１０１は、不正イベントとする。
【００７２】
ステップＳ１００７において、運用管理サーバ１０１は、２バイト判定処理を行う。この処理の詳細は、後に説明する。
【００７３】
ステップＳ１００８において、運用管理サーバ１０１は、不正イベントであるかを判定する。Ｙｅｓの場合、ステップＳ１００６へ進み、Ｎｏの場合、ステップＳ１００９へ進む。
【００７４】
ステップＳ１００９において、運用管理サーバ１０１は、１／２バイトまた電文イベントとする。
【００７５】
図１１は、２バイト判定処理の詳細なフローである。
【００７６】
ステップＳ１１０１において、運用管理サーバ１０１は、データは２バイトであるかを判定する。Ｙｅｓの場合、ステップＳ１１０２へ進み、Ｎｏの場合、ステップＳ１１０５へ進む。
【００７７】
ステップＳ１１０２において、運用管理サーバ１０１は、１バイトコードパターンａ）、ｂ）があるかを判定する。Ｙｅｓの場合、ステップＳ１１０３へ進み、Ｎｏの場合、ステップＳ１１０４へ進む。
【００７８】
ステップＳ１１０３において、運用管理サーバ１０１は、１バイトイベントとする。
【００７９】
ステップＳ１１０４において、運用管理サーバ１０１は、不正イベントとする。
【００８０】
ステップＳ１１０５において、運用管理サーバ１０１は、３バイト判定処理を行う。この処理の詳細は、後に説明する。
【００８１】
ステップＳ１１０６において、運用管理サーバ１０１は、不正イベントであるかを判定する。Ｙｅｓの場合、ステップＳ１１０４へ進み、Ｎｏの場合、ステップＳ１１０７へ進む。
【００８２】
ステップＳ１１０７において、運用管理サーバ１０１は、１また２バイトイベントとする。
【００８３】
図１２は、３バイト判定処理の詳細なフローである。
【００８４】
ステップＳ１２０１において、運用管理サーバ１０１は、データは３バイトであるかを判定する。Ｙｅｓの場合、ステップＳ１２０２へ進み、Ｎｏの場合、ステップＳ１２０５へ進む。
【００８５】
ステップＳ１２０２において、運用管理サーバ１０１は、１バイトコードパターンｃ）または２バイトコードパターンａ）、ｂ）があるかを判定する。Ｙｅｓの場合、ステップＳ１２０３へ進み、Ｎｏの場合、ステップＳ１２０４へ進む。
【００８６】
ステップＳ１２０３において、運用管理サーバ１０１は、１また２バイトイベントとする。
【００８７】
ステップＳ１２０４において、運用管理サーバ１０１は、不正イベントとする。
【００８８】
ステップＳ１２０５において、運用管理サーバ１０１は、４バイト判定処理を行う。この処理の詳細は、後に説明する。
【００８９】
ステップＳ１２０６において、運用管理サーバ１０１は、不正イベントであるかを判定する。Ｙｅｓの場合、ステップＳ１２０４へ進み、Ｎｏの場合、ステップＳ１２０７へ進む。
【００９０】
ステップＳ１２０７において、運用管理サーバ１０１は、２また電文（１００２）イベントとする。
【００９１】
図１３は、４バイト判定処理の詳細なフローである。
【００９２】
ステップＳ１３０１において、運用管理サーバ１０１は、データは４バイトであるかを判定する。Ｙｅｓの場合、ステップＳ１３０２へ進み、Ｎｏの場合、ステップＳ１３０５へ進む。
【００９３】
ステップＳ１３０２において、運用管理サーバ１０１は、２バイトコードパターンｃ）があるかを判定する。Ｙｅｓの場合、ステップＳ１３０３へ進み、Ｎｏの場合、ステップＳ１３０４へ進む。
【００９４】
ステップＳ１３０３において、運用管理サーバ１０１は、２バイトイベントとする。
【００９５】
ステップＳ１３０４において、運用管理サーバ１０１は、不正イベントとする。
【００９６】
ステップＳ１３０５において、運用管理サーバ１０１は、電文コードパターンがあるかを判定する。Ｙｅｓの場合、ステップＳ１３０４へ進み、Ｎｏの場合、ステップＳ１３０６へ進む。
【００９７】
ステップＳ１３０６において、運用管理サーバ１０１は、電文イベントとする。
【００９８】
ステップＳ１３０７において、運用管理サーバ１０１は、解析データテーブルに新規レコードを追加する。
【００９９】
次に、ステップＳ２００５において、運用管理サーバ１０１は、解析データなしとする。
【０１００】
ステップＳ２００６において、運用管理サーバ１０１は、現在処理中のセッションＮｏ、シーケンスＮｏ．をキーに解析データテーブルを検索し、最大インデックスのレコードのイメージデータを再読み込みする。
【０１０１】
例えば、現在処理中のセッションＮｏ「１００」、シーケンスＮｏ「１」＋「１」＝「２」を条件に解析データテーブル５０を検索する。この例では２レコード目が取得できる。このレコードから送信、データ長１３バイトが解り、データイメージを図１０の処理に適用することとなる。
【０１０２】
この結果、解析データテーブル５０にセッションＮｏ「１００」、シーケンスＮｏ「２」、インデックスＮｏ「１」のレコードが追加される。
【０１０３】
この後、セッションＮｏ「１００」、シーケンスＮｏ「２」で解析データテーブル５０を検索すると、該当レコードが２件見つかる。このうちインデックスＮｏが最大のものをイベントコードとする。この場合イベントコードは（ＡＣＫ０−１０７０）となる。
【０１０４】
次に、ステップＳ１５０２において、運用管理サーバ１０１は、同じ状態遷移表の判定条件をステップＳ１５０１で取得したイベントコードをキーに検索する。検索した結果、異常の条件と一致した場合は、ステップＳ１５０４へ、正常の条件と一致した場合はステップＳ１５０３へ処理が進む。例えば、図２０の処理結果より、ＡＣＫ０を送信したことが解る。判定条件に照らし合わせると、これは正常であることが解る。
【０１０５】
ステップＳ１５０３において、運用管理サーバ１０１は、現在処理中の状態遷移表Ｎｏと、状態Ｎｏイベントコードをキーとし、状態遷移表から取得したエラー判定処理の判定結果（正常：遷移先状態Ｎｏ．）から、状態遷移表の状態Ｎｏを遷移先状態Ｎｏで更新する。正常なので、遷移先状態Ｎｏは「２」であるので状態番号を「２」で更新する。
【０１０６】
Ｓ１５０４において、運用管理サーバ１０１は、現在処理中の解析データレコードのセッションＮｏ及びシーケンスＮｏを取得する。また、現在処理中の状態遷移表Ｎｏと、状態Ｎｏイベントコードをキーとし、状態遷移表から取得したエラー判定処理の判定結果（異常：エラーＮｏ．）から、エラー情報データレコードを作成し、エラー情報データテーブル６０の最後尾に追加する。
【０１０７】
次に、ステップＳ７１１において、運用管理サーバ１０１は、上位プロトコルへの切り替えが発生するかを取得する。具体的には、ステップＳ７０８で判定した、現在処理中のイベントコードと、プロトコルＮｏ．をキーにイベント判定テーブル１４００を検索する。一致するレコードが存在しないか、または一致するレコードがあった場合でも、レコードの上位遷移先階層Ｎｏ．が存在しない場合は、上位の状態遷移表への切り替えは発生しないので、ステップＳ７１４へ進む。
【０１０８】
反対に一致するレコードが存在し、かつレコードの上位遷移先階層Ｎｏ．が存在する場合は上位の状態遷移表への切り替えが発生する。その場合、ステップＳ７１２とステップＳ７１３で上位遷移先階層Ｎｏ．をキーにプロトコル一覧テーブルを検索し、一致したレコードのプロトコルＮｏ．を取得する。取得したプロトコルＮｏ．で現在処理中のプロトコルＮｏ．を更新し、ステップＳ７０５へ戻る。
【０１０９】
例えば、現在処理中のセッションＮｏ「１００」、シーケンスＮｏ「１」で解析データテーブル５０を検索すると、該当のレコードが２件見つかる。このうちインデックスＮｏが最大のものをイベントコードとする。この場合イベントコードは（ＥＮＱ−２Ｄ）となる。イベント判定テーブル１４００上のプロトコルＮｏ「１」に「２Ｄ」のコードは存在しないので、階層の移動は発生しない。
【０１１０】
次に、ステップＳ７１４において、運用管理サーバ１０１は、下位プロトコルへの切り替えが発生するかを取得する。具体的には、ステップＳ７０８で判定した、現在処理中のイベントコードと、プロトコルＮｏ．をキーにイベント判定テーブル１４００を検索する。一致するレコードが存在しないか、または一致するレコードがあった場合でも、レコードの下位遷移先階層Ｎｏ．が存在しない場合は、下位の状態遷移表への切り替えは発生しないので、ステップＳ７０３へ戻る。
【０１１１】
反対に一致するレコードが存在し、かつレコードの下位遷移先階層Ｎｏ．が存在する場合は下位の状態遷移表への切り替えが発生する。その場合、ステップＳ７１５とステップＳ７１６で下位遷移先階層Ｎｏ．をキーにプロトコル一覧テーブルを検索し、一致したレコードのプロトコルＮｏ．を取得する。取得したプロトコルＮｏ．で現在処理中のプロトコルＮｏ．を更新し、ステップＳ７０３へ戻る。
【０１１２】
ステップＳ７０３において、ここまでの繰り返しで、発生した全エラーのエラー情報データテーブルが作成される。
【０１１３】
エラー詳細情報テーブル２１００は、ステップＳ７２０で作成されたエラー情報データレコードの状態遷移表Ｎｏ．とエラーＮｏ．をキーに検索され、一致したレコードの詳細情報１と詳細情報２が取得される。取得された詳細情報１および２は、ステップＳ４０３で通信制御部３０１が表示部３０３にエラー情報を表示させる際に使用される。
【０１１４】
以上、図４におけるステップＳ４０２の詳細フローを説明した。
【０１１５】
上述した通り、本発明によれば、状態遷移表を切り替えるデータパターンを予め定義しておき、このデータパターンが解析データから検出されることで状態遷移表を切り替え、障害の原因と対策を提示することが可能となる。
【０１１６】
また、本発明では解析データを通信セッション毎に記録・蓄積しておくため、解析作業中は運用者が常に監視する必要がないだけでなく、発生頻度が少ない、潜在的な障害も洩らすことなく検出し、原因の特定及び対策の提示が可能となる。
【０１１７】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１１８】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【符号の説明】
【０１１９】
１０１ 運用管理サーバ
１０２ 通信サーバ
１０３ ＥＤＩ端末
１０４ ネットワーク
【特許請求の範囲】
【請求項１】
通信データの解析を行う情報処理装置であって、
通信データの障害を特定するための状態遷移表を記録する記録手段と、
解析対象となる通信データから解析データを作成する作成手段と、
前記作成手段により作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出手段と、
前記検出手段により検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御手段と
を有することを特徴とする情報処理装置。
【請求項２】
前記記憶手段により記憶される状態遷移表は、プロトコル毎に記録され、
前記表示制御手段は、それぞれのプロトコル毎に障害の原因と対策を提示することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
通信データの障害を特定するための状態遷移表を記録する記録手段を有し、通信データの解析を行う情報処理装置における情報処理方法であって、
解析対象となる通信データから解析データを作成する作成ステップと、
前記作成ステップにより作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出ステップと、
前記検出ステップにより検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御ステップと
を有することを特徴とする情報処理方法。
【請求項４】
通信データの解析を行う情報処理装置において実行可能なプログラムであって、
通信データの障害を特定するための状態遷移表を記録する記録手段、
解析対象となる通信データから解析データを作成する作成手段、
前記作成手段により作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出手段、
前記検出手段により検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御手段
として前記情報処理装置を機能させることを特徴とするプログラム。
【請求項５】
請求項４に記載のプログラムをコンピュータ読み取り可能に記憶した記録媒体。
【請求項１】
通信データの解析を行う情報処理装置であって、
通信データの障害を特定するための状態遷移表を記録する記録手段と、
解析対象となる通信データから解析データを作成する作成手段と、
前記作成手段により作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出手段と、
前記検出手段により検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御手段と
を有することを特徴とする情報処理装置。
【請求項２】
前記記憶手段により記憶される状態遷移表は、プロトコル毎に記録され、
前記表示制御手段は、それぞれのプロトコル毎に障害の原因と対策を提示することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
通信データの障害を特定するための状態遷移表を記録する記録手段を有し、通信データの解析を行う情報処理装置における情報処理方法であって、
解析対象となる通信データから解析データを作成する作成ステップと、
前記作成ステップにより作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出ステップと、
前記検出ステップにより検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御ステップと
を有することを特徴とする情報処理方法。
【請求項４】
通信データの解析を行う情報処理装置において実行可能なプログラムであって、
通信データの障害を特定するための状態遷移表を記録する記録手段、
解析対象となる通信データから解析データを作成する作成手段、
前記作成手段により作成された解析データから、予め定義される前記記録手段により記録される状態遷移表を切り替えるデータパターンを検出する検出手段、
前記検出手段により検出されたデータパターンに応じて前記前記記録手段により記録される状態遷移表を切り替えることで、障害の原因と対策を示す情報を表示する表示制御手段
として前記情報処理装置を機能させることを特徴とするプログラム。
【請求項５】
請求項４に記載のプログラムをコンピュータ読み取り可能に記憶した記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公開番号】特開２０１２−１４１７１０（Ｐ２０１２−１４１７１０Ａ）
【公開日】平成２４年７月２６日（２０１２．７．２６）
【国際特許分類】
【出願番号】特願２０１０−２９３０４１（Ｐ２０１０−２９３０４１）
【出願日】平成２２年１２月２８日（２０１０．１２．２８）
【出願人】（３９０００２７６１）キヤノンマーケティングジャパン株式会社 (656)
【出願人】（３１２０００２０６）キヤノンＭＪアイティグループホールディングス株式会社 (259)
【出願人】（５９２１３５２０３）キヤノンＩＴソリューションズ株式会社 (528)
【Ｆターム（参考）】
【公開日】平成２４年７月２６日（２０１２．７．２６）
【国際特許分類】
【出願日】平成２２年１２月２８日（２０１０．１２．２８）
【出願人】（３９０００２７６１）キヤノンマーケティングジャパン株式会社 (656)
【出願人】（３１２０００２０６）キヤノンＭＪアイティグループホールディングス株式会社 (259)
【出願人】（５９２１３５２０３）キヤノンＩＴソリューションズ株式会社 (528)
【Ｆターム（参考）】
[ Back to top ]