(57)【要約】【課題】振込依頼電文に含まれている変換対象の振込受取人名（英字）を振込受取人名（カナ）に一意的に変換するためのシステムを提供する。【解決手段】外部から受信した１つまたは複数のＸＭＬ形式および非ＸＭＬ形式の送金依頼電文を全銀プロトコル準拠の形式に変換するシステムは、ＸＭＬ形式および非ＸＭＬ形式の送金依頼電文を共通ＸＭＬ形式の送金依頼電文に変換した後、全銀手順準拠の形式の送金依頼電文に変換する。共通ＸＭＬ形式の送金依頼電文は受取人の口座情報の各項目が記録される位置が予め定まっている。共通ＸＭＬ形式から全銀手順準拠の形式に変換する際、振込受取人の情報のうち、変換すべき文字は元の文字２バイト分が１バイト分に変換される。変換すべき文字２バイトのうち、１番目のバイトと２番目のバイトで表される文字が同一か否か判定され、同一でない場合に２番目のバイトで表される文字が母音か否か判定される。一方、非変換対象の文字は変換処理されずそのまま残る。【選択図】図９
2010277344.tif 000002
【特許請求の範囲】
【請求項１】
他のシステムから受信した１つまたは複数のＸＭＬ形式および非ＸＭＬ形式の送金依頼電文を全銀プロトコル準拠の形式に変換するシステムであって、
前記送金依頼電文には、第１の受取人名を含む送金受取人の口座情報が含まれ、
前記第１の受取人名は、当該システムによる変換前の情報であって、前記第１の受取人名に含まれる文字は、半角形式、すなわち、１文字あたり１バイトで表され、
前記システムは、
受信した送金依頼電文のうち、１つまたは複数の非ＸＭＬ形式の送金依頼電文をＸＭＬ形式にファイル変換する手段と、
他のシステムから受信した１つまたは複数のＸＭＬ形式の送金依頼電文、および前記ＸＭＬ形式にファイル変換後の１つまたは複数の送金依頼電文を共通ＸＭＬ形式に変換する手段であって、該共通ＸＭＬ形式は前記送金受取人の口座情報のそれぞれの情報が格納される記録位置が予め定まっている、手段と、
前記共通ＸＭＬ形式に変換済みの１つまたは複数の送金依頼電文に含まれている前記第１の受取人名を全銀プロトコル準拠の第２の受取人名に変換する手段と、
前記全銀プロトコル準拠の第２の受取人名に変換済みの送金依頼電文を全銀プロトコル準拠の形式の送金依頼電文に変換する手段と
を備え、
前記第１の受取人名から前記第２の受取人名への変換は、前記第１の受取人名に含まれる変換対象の２バイト分の文字が前記第２の受取人名に含まれる１バイト分の文字に対応するように変換されることを特徴とするシステム。
【請求項２】
前記第１の受取人名を前記第２の受取人名に変換する手段は、
前記第１の受取人名に含まれる文字を先頭から２バイトずつ読み込む手段と、
読み込まれた２バイトについて、それぞれ、
非変換対象文字の前後にセットされる所定の文字であるか否かを判定する手段と、
前記所定の文字で囲まれた前記非変換対象文字を特定する手段と、
第１のバイトと第２のバイトが同一の文字を表すのか否かを判定する手段と、
同一の文字ではないと判定された場合に、第２のバイトが母音を表す文字であるか否かを判定する手段と、
前記第１のバイトと第２のバイトによって特定される文字が予め登録されている変換テーブルに存在するか否かを判定し、存在する場合には前記第１のバイトと第２のバイトによって特定される文字を変換対象文字として特定する手段と、
を繰り返す手段と
をさらに備えたことを特徴とする請求項１記載のシステム。
【請求項３】
前記第１の受取人名から前記第２の受取人名への変換は、
前記変換文字として特定された前記第１のバイトと第２のバイトによって特定される文字を予め登録してある変換テーブルに基づいて変換し、
前記特定された非変換対象文字を変換せずにそのままにしておく、
ことによって行われ、
前記変換テーブルは、変換対象の文字につき、変換前の文字２バイトが変換後の文字１バイトに対応する対応付け情報が登録されている
ことを特徴とする請求項２に記載のシステム。
【請求項４】
前記非変換対象文字を特定する手段は、
前記所定の文字の次の１文字を読み込み、該次の１文字が読み込まれたか否かを判定する手段と、
読み込まれた場合に、該次の１文字が前記所定の文字であるか否かを判定する手段と、
該次の１文字が前記所定の文字であると判定された場合に、さらに次の１文字を読み込む手段と、
該読み込まれたさらに次の１文字が前記所定の文字であるか否かを判定する手段と、
をさらに備えたことを特徴とする請求項２または３に記載のシステム。
【請求項５】
依頼者ごとに、前記第１の受取人名を前記第２の受取人名に変換するための対応関係を示すデータを格納するテーブルをさらに備えたことを特徴とする請求項１乃至４のいずれかに記載のシステム。
【請求項６】
他のシステムから受信した１つまたは複数のＸＭＬ形式および非ＸＭＬ形式の送金依頼電文を全銀プロトコル準拠の形式に変換するための、コンピュータが実施する方法であって、
前記送金依頼電文には、第１の受取人名を含む送金受取人の口座情報が含まれ、
前記第１の受取人名は、当該システムによる変換前の情報であって、前記第１の受取人名に含まれる文字は、半角形式、すなわち、１文字あたり１バイトで表され、
前記方法は、
受信した送金依頼電文のうち、１つまたは複数のＸＭＬ形式および非ＸＭＬ形式の送金依頼電文をＸＭＬ形式にファイル変換するステップと、
他のシステムから受信した１つまたは複数のＸＭＬ形式の送金依頼電文、および前記ＸＭＬ形式にファイル変換後の１つまたは複数の送金依頼電文を共通ＸＭＬ形式に変換するステップであって、該共通ＸＭＬ形式は前記送金受取人の口座情報のそれぞれの情報が格納される記録位置が予め定まっている、ステップと、
前記共通ＸＭＬ形式に変換済みの１つまたは複数の送金依頼電文に含まれている前記第１の受取人名を全銀プロトコル準拠の第２の受取人名に変換するステップと、
前記全銀プロトコル準拠の第２の受取人名に変換済みの送金依頼電文を全銀プロトコル準拠の形式の送金依頼電文に変換するステップと
を含み、
前記第１の受取人名から前記第２の受取人名への変換は、前記第１の受取人名に含まれる変換対象の２バイト分の文字が前記第２の受取人名に含まれる１バイト分の文字に対応するように変換されることを特徴とする方法。
【請求項７】
前記第１の受取人名を前記第２の受取人名に変換するステップは、
前記第１の受取人名に含まれる文字を先頭から２バイトずつ読み込むステップと、
読み込まれた２バイトについて、それぞれ、
非変換対象文字の前後にセットされる所定の文字であるか否かを判定するステップと、
前記所定の文字で囲まれた前記非変換対象文字を特定するステップと、
第１のバイトと第２のバイトが同一の文字を表すのか否かを判定するステップと、
同一の文字ではないと判定された場合に、第２のバイトが母音を表す文字であるか否かを判定するステップと、
前記第１のバイトと第２のバイトによって特定される文字が予め登録されている変換テーブルに存在するか否かを判定し、存在する場合には前記第１のバイトと第２のバイトによって特定される文字を変換対象文字として特定するステップと、
を繰り返すステップと
をさらに含むことを特徴とする請求項６記載の方法。
【請求項８】
前記第１の受取人名から前記第２の受取人名への変換は、
前記変換文字として特定された前記第１のバイトと第２のバイトによって特定される文字を予め登録してある変換テーブルに基づいて変換し、
前記特定された非変換対象文字を変換せずにそのままにしておく、
ことによって行われ、
前記変換テーブルは、変換対象の文字につき、変換前の文字２バイトが変換後の文字１バイトに対応する対応付け情報が登録されている
ことを特徴とする請求項７に記載の方法。
【請求項９】
前記非変換対象文字を特定するステップは、
前記所定の文字の次の１文字を読み込み、該次の１文字が読み込まれたか否かを判定するステップと、
読み込まれた場合に、該次の１文字が前記所定の文字であるか否かを判定するステップと、
該次の１文字が前記所定の文字であると判定された場合に、さらに次の１文字を読み込むステップと、
該読み込まれたさらに次の１文字が前記所定の文字であるか否かを判定するステップと、
をさらに含むことを特徴とする請求項７または８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、海外顧客からネットワーク経由で受信した振込依頼電文を全銀ネットワークに送信するために、海外顧客が指定した振込受取人名の英字を全銀手順で指定された文字に変換するシステムに関する。
【背景技術】
【０００２】
国内金融機関同士で振込を行う際、各金融機関は全国銀行協会（全銀協）が制定した手順に則って振込電文（振込データ）の送受信を行っている。この全銀ネットワークにて送受信する振込データのうち、振込受取人名については全銀文字、つまり、半角英字および半角カタカナで行うことになっている。
【０００３】
従来、海外から顧客が日本国内に振込依頼をする際には、インターネットバンキングやスイフト（ＳＷＩＦＴ：Society for Worldwide Interbank Financial Telecommunication）ネットワーク経由で振込依頼電文を国内金融機関宛に送信している。当該振込電文は、国内金融機関にて全銀フォーマットに適合するように変換されて、従来技術の銀行振込システム１０３によって振込先の金融機関に向けて送信される。
【０００４】
この変換処理としては、事前登録変換方式やテーブル変換方式などが従来から知られており、従来システムは、このような方式を１つまたは複数使用して構築されている。ここで、事前登録変換方式とは、顧客別に振込受取人名（英字）と振込受取人名（カナ）の組合せを事前に登録したテーブルを用意し、変換処理を行う方式である。テーブル変換方式とは、所定の変換テーブルに基づいて振込受取人名を入力された英字からカナに変換する方式である（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平５−１２２４８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来のテーブル変換方式では、入力された振込受取人名（英字）のうち変換対象の文字を一意的に変換して振込受取人名（カナ）に変換することは困難であった（例えば、「SHINICHI」は「シンイチ」や「シニチ」などに変換される）。そのため、振込受取人名（カナ）に一意的に変換できない場合は、人的作業による確認に頼らざるを得なかった。
【０００７】
本発明は、このような問題に鑑みてなされたもので、受信した振込依頼電文に含まれている振込受取人名（英字）の文字のうちの変換対象の文字を変換することにより振込受取人名（カナ）に一意的に変換するためのシステムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記の課題を解決するために、本発明に係るシステムは、他のシステムから受信した１つまたは複数のＸＭＬ形式および非ＸＭＬ形式の送金依頼電文を全銀プロトコル準拠の形式に変換するシステムである。そして、送金依頼電文には、第１の受取人名を含む送金受取人の口座情報が含まれ、第１の受取人名は、当該システムによる変換前の情報であって、第１の受取人名に含まれる文字は、半角形式、すなわち、１文字あたり１バイトで表される。当該システムは、受信した送金依頼電文のうち、１つまたは複数の非ＸＭＬ形式の送金依頼電文をＸＭＬ形式にファイル変換する手段と、他のシステムから受信した１つまたは複数のＸＭＬ形式の送金依頼電文、およびＸＭＬ形式にファイル変換後の１つまたは複数の送金依頼電文を共通ＸＭＬ形式に変換する手段であって、該共通ＸＭＬ形式は送金受取人の口座情報のそれぞれの情報が格納される記録位置が予め定まっている、手段と、共通ＸＭＬ形式に変換済みの１つまたは複数の送金依頼電文に含まれている第１の受取人名を全銀プロトコル準拠の第２の受取人名に変換する手段と、全銀プロトコル準拠の第２の受取人名に変換済みの送金依頼電文を全銀プロトコル準拠の形式の送金依頼電文に変換する手段と、を備え、第１の受取人名から第２の受取人名への変換は、第１の受取人名に含まれる変換対象の２バイト分の文字が第２の受取人名に含まれる１バイト分の文字に対応するように変換されることを特徴とする。
【０００９】
また、本発明に係る方法は、他のシステムから受信した１つまたは複数のＸＭＬ形式および非ＸＭＬ形式の送金依頼電文を全銀プロトコル準拠の形式に変換するための、コンピュータが実施する方法である。そして、送金依頼電文には、第１の受取人名を含む送金受取人の口座情報が含まれ、第１の受取人名は、当該システムによる変換前の情報であって、第１の受取人名に含まれる文字は、半角形式、すなわち、１文字あたり１バイトで表される。当該方法は、受信した送金依頼電文のうち、１つまたは複数のＸＭＬ形式および非ＸＭＬ形式の送金依頼電文をＸＭＬ形式にファイル変換するステップと、他のシステムから受信した１つまたは複数のＸＭＬ形式の送金依頼電文、およびＸＭＬ形式にファイル変換後の１つまたは複数の送金依頼電文を共通ＸＭＬ形式に変換するステップであって、該共通ＸＭＬ形式は送金受取人の口座情報のそれぞれの情報が格納される記録位置が予め定まっている、ステップと、共通ＸＭＬ形式に変換済みの１つまたは複数の送金依頼電文に含まれている第１の受取人名を全銀プロトコル準拠の第２の受取人名に変換するステップと、全銀プロトコル準拠の第２の受取人名に変換済みの送金依頼電文を全銀プロトコル準拠の形式の送金依頼電文に変換するステップと、を含み、第１の受取人名から第２の受取人名への変換は、第１の受取人名に含まれる変換対象の２バイト分の文字が第２の受取人名に含まれる１バイト分の文字に対応するように変換されることを特徴とする。
【発明の効果】
【００１０】
本発明は、海外から顧客が送信する振込電文において、振込受取人名（カナ）に変換すべき振込受取人名（英字）を２バイト固定文字とすることにより振込受取人名（英字）を振込受取人名（カナ）に一意的に変換することが可能になる効果を奏する。その結果、多種多様なフォーマットのデータ／ファイルを一元的に受け付けることができ、さらに、英字→カナへの変換エラーなどの場合に発生する事務作業負担の軽減を図ることができ、付随するオペレーションミスを防ぐことができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態に係るマルチフォーマット変換システムの概要を説明する図である。
【図２】本発明の一実施形態に係るマルチフォーマット変換システムのシステム構成図である。
【図３】本発明に係るマルチフォーマット変換システム１００によって実行される処理のフローの概要を説明する図である。
【図４】本発明の一実施形態に係るマルチフォーマット変換システムの機能ブロック図である。
【図５】本発明に係るマルチフォーマット変換システムによって実行される、全銀ネットワークに送信可能なフォーマットの送金依頼電文を作成する一例を示すフロー図である。
【図６】本発明に係る振込受取人名変換処理の詳細を示す処理フローである。
【図７】本発明に係るテーブル変換方式の一実施例を示す変換テーブルである。
【図８】本発明に係るテーブル変換方式のデータ処理のイメージを示す図である。
【図９】本発明に係るテーブル変換方式の詳細を説明する図である。
【図１０】本発明において、非変換対象の文字が含まれるか否かを判定するためのフロー図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施の形態について詳細に説明する。なお、以下の説明では、本発明に係るシステムは、海外顧客から振込依頼電文を受信して処理するシステムであるため、海外顧客は日本語の漢字、ひらがな、カタカナ（全角、半角とも）を使用することができない前提で説明する。つまり、海外顧客が送信可能なのは、英数字（半角）および各種記号（例えば、括弧「（）」など）だけである。また、振込の宛先は国内に存在する金融機関とする前提で説明する。
【００１３】
図１は、本発明に係るマルチフォーマット変換システム１００の概要を説明するための図である。本発明では、海外顧客がＣＭＳ（キャッシュマネジメントシステム：Cash Management System）やインターネットバンキングサービスなどを用いてＳＷＩＦＴ／インターネット１０１経由で送金依頼電文を送信する。マルチフォーマット変換システム１００が受信する送金依頼電文は、図１に示すように、大きく分けてＳＷＩＦＴネットワーク経由およびインターネット経由の２つのルートで受信される。ＳＷＩＦＴネットワーク経由で送受信される電文は、ＳＷＩＦＴにおいて規定されたフォーマットに従った形式で送受信され、また、その電文の形式もＸＭＬ形式、ＣＳＶ形式、固定長データを含むテキストファイル形式など、複数の電文用フォーマットが存在する。さらに、ＳＷＩＦＴネットワーク経由で送受信される電文には、個々の企業が独自に定義するフォーマットも含まれる。一方、本発明においては、インターネット経由で送受信される電文（インターネットバンキングシステムによって送信される）は、ＸＭＬ形式が規定されている。
【００１４】
つまり、本発明においては、送金依頼電文は多様なフォーマットとすることが可能である。マルチフォーマット変換システム１００は、多様なフォーマットをとりうる送金依頼電文を受信して、銀行振込システム１０３が全銀ネットワーク１０２に送信可能な形式に変換した後、銀行振込システム１０３に対して送信処理を行い、銀行振込システム１０３が全銀ネットワーク１０２に送信を行う。
【００１５】
図２は、マルチフォーマット変換システム１００のシステム構成を簡略的に示した図である。マルチフォーマット変換システム１００は、制御部２０１、主記憶部２０２、補助記憶部２０３、入力部２０４、出力部２０５、および外部との送受信を行うインターフェース（Ｉ／Ｆ）を含む。これらの構成要素はバスなどで相互に接続されており、制御部２０１によって各構成要素２０２〜２０５は統括して制御される。
【００１６】
制御部２０１は、中央処理装置（ＣＰＵ：Central Processing Unit）とも呼ばれ、上述したように各構成要素２０２〜２０５の制御やデータの演算を行い、また、補助記憶部２０３に格納されている各種プログラムを主記憶部２０２に読み出して実行する。主記憶部２０２は、メインメモリとも呼ばれ、マルチフォーマット変換システム１００が受信した送金依頼電文、コンピュータ実行可能な命令および当該命令による演算処理後のデータなどを記憶する。
【００１７】
補助記憶部２０３は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データやプログラムを長期的に保存する際に使用される。主記憶部２０２は、補助記憶部２０３よりも記憶容量が相対的に小さいため、一時的なデータの記憶や演算処理などに使用されるのに対し、補助記憶部２０３は、必要なデータや情報の長期的な記憶・保存のために使用される。つまり、制御部２０１がプログラムを実行してデータの演算を行う場合には、補助記憶部２０３から必要なデータやプログラムを主記憶部２０２に読み出し、演算結果のデータを長期的に記憶・保存するには制御部２０１が補助記憶部２０３に演算結果のデータを書き込むこととなる。
【００１８】
入力部２０４は、ＳＷＩＦＴ／インターネット１０１経由で顧客から送金依頼電文を受信し、システム１００内に入力する。入力された送金依頼電文は、主記憶部２０２に一時的に記憶される。また、入力部２０４は、システムオペレータより各種コマンドや入力データ（各種マスタ、テーブルなど）を受け付けるインターフェース（入力画面などのアプリケーションプログラム）を提供する。
【００１９】
出力部２０５は、マルチフォーマット変換システム１００において全銀フォーマットに準拠した送金依頼電文を銀行振込システム１０３に送信し、そこから送金依頼電文は全銀ネットワーク１０２経由で振込先に送信される。また、出力部２０５は、マルチフォーマット変換システム１００によって処理されたデータを表示する表示画面も提供する。
【００２０】
図３は、本発明に係るマルチフォーマット変換システム１００によって実行される処理のフローの概要を説明する図である。なお、以下に説明するステップＳ３０３以外の各ステップにおける処理は従来技術に係るデータ処理であるため、詳細な説明は省略する。
【００２１】
ステップＳ３０１では、マルチフォーマット変換システム１００は、インターネット／ＳＷＩＦＴネットワーク１０１から送金依頼電文を受信して、主記憶部２０２などのシステム内の所定の場所に蓄積する。マルチフォーマット変換システム１００は、所定の周期ごとに送金依頼電文が蓄積されているかを確認し、蓄積されている場合には、ステップＳ３０２に処理を進める。
【００２２】
ステップＳ３０２では、マルチフォーマット変換システム１００は、蓄積された１つまたは複数の電文を読み込み、それらの電文が送金依頼電文であるか否かを確認する。ここで、送金依頼電文でないと判定された電文は、本システムの処理対象外となる。なお、ＳＷＩＦＴネットワーク経由で受信された送金依頼電文（ＳＷＩＦＴ規定フォーマットおよび企業独自フォーマット）については、本ステップにおいて後処理のために口座マスタから所定の情報が付加され、さらに、非ＸＭＬ形式の送金依頼電文についてはＸＭＬ形式のフォーマットに変換される。なお、本ステップにおいて変換されるＸＭＬ形式のフォーマットは、後述する共通ＸＭＬ形式とは異なる。上述したように、ＳＷＩＦＴネットワーク経由で受信される電文は多種多様な電文フォーマットをとりうるため、本ステップでは、それらの電文をＸＭＬ形式にファイル変換することにより、ＳＷＩＦＴ経由の電文をＸＭＬ形式に揃える処理を行っている。
【００２３】
ステップＳ３０３では、マルチフォーマット変換システム１００は、送金依頼電文について、共通ＸＭＬ形式のファイルフォーマットに変換する「一次変換」処理、および一次変換されたファイルを全銀用フォーマットに変換する「二次変換」処理を行う。「一次変換」処理は、多種多様な送金依頼電文のフォーマット（全てＸＭＬ形式）を共通ＸＭＬ形式に変換することを可能にする処理である。本ステップの詳細な処理は、図４において詳述する。
【００２４】
ステップＳ３０４では、マルチフォーマット変換システム１００は、二次変換処理にて全銀手順に従ったフォーマットに変換された送金依頼電文から送信用ファイルを作成した後、銀行振込システム１０３に送信し、銀行振込システム１０３が該電文を全銀ネットワーク１０２に向けて送信する。ステップＳ３０５では、マルチフォーマット変換システム１００は、銀行振込システム１０３が作成した送信結果ファイルを銀行振込システム１０３から受信して、システム内に取り込む。
【００２５】
図４は、マルチフォーマット変換システム１００の機能モジュールを示すブロック図である。図４に示すように、マルチフォーマット変換システム１００は、電文受付・確認部４０１、電文取込・検証部４０２、全銀用ファイル作成・送信部４０３、送信結果受信・取込部４０４、送信電文フォーマット判定部４０５、ＸＭＬ変換部４０６、一次変換部４０７、重複チェック部４０８、電文項目チェック部４０９、マスタ情報設定部４１０、二次変換部４１１、受取人マスタ４２０、変換テーブル４２１、ＳＷＩＦＴ用マスタ４２２、インターネットバンキング用マスタ４２３、銀行マスタ４３０、顧客マスタ４３１、口座マスタ４３２、通貨マスタ４３３、受信管理テーブル４３４を有する。
【００２６】
電文受付・確認部４０１は、インターネットバンキングおよびＳＷＩＦＴネットワークから送金依頼電文を受信して、主記憶部２０２などに蓄積する。また、電文受付・確認部４０１は、所定の周期ごとに送金依頼電文が蓄積されているかを確認する。電文取込・検証部４０２は、蓄積されている１つまたは複数の送金依頼電文を読み込み、送金依頼電文であるか否かを確認する。
【００２７】
全銀用ファイル作成・送信部４０３は、マルチフォーマット変換システム１００によって二次変換処理された送金依頼電文から銀行振込システム１０３が全銀ネットワーク１０２に送信可能な送信用ファイルを作成し、銀行振込システム１０３に送信する。また、送信結果受信・取込部４０４は、全銀用ファイル作成・送信部４０３によって送信された送金依頼電文についての送信結果ファイルをシステム内に取り込む。なお、銀行振込システム１０３が送信結果ファイルを作成して、この送信結果ファイルをマルチフォーマット変換システム１００に送信する。
【００２８】
送信電文フォーマット判定部４０５は、本発明に係るシステム１００の処理対象の電文がインターネットバンキング経由およびＳＷＩＦＴネットワーク経由のいずれで受信された電文であるかを判定する。インターネットバンキング経由で受信される電文はＸＭＬ形式のフォーマットであり、また、ＳＷＩＦＴネットワーク経由で受信される電文のフォーマットはＳＷＩＦＴ独自に決められた形式や企業独自に決められた形式であるため、ＸＭＬ形式および非ＸＭＬ形式（ＣＳＶ、テキストなど）の多種多様なフォーマットごとに受信後の処理が異なってくる。
【００２９】
ＸＭＬ変換部４０６は、送信電文フォーマット判定部４０５によってＳＷＩＦＴネットワーク経由で受信されたと判定された電文についてＸＭＬ形式にファイル変換する処理を行う。ＳＷＩＦＴネットワーク経由の電文は、ＸＭＬ形式および非ＸＭＬ形式を含む多種多様なフォーマットをとりうるため、ＸＭＬ変換部４０６は、それらの電文をＸＭＬ形式に揃える処理（ファイル変換）を行う。
【００３０】
一次変換部４０７は、本発明のマルチフォーマット変換システム１００により受信された、ＳＷＩＦＴ用フォーマットおよび企業独自フォーマット、並びにインターネットバンキング用フォーマットの送金依頼電文を共通ＸＭＬ形式のフォーマットに変換する処理を行う。なお、インターネットバンキング用フォーマットは、元々、ＸＭＬ形式のフォーマットであるが、ＳＷＩＦＴ用フォーマットおよび企業独自フォーマットはＸＭＬ変換部４０６によってＸＭＬ形式に揃えられている。
【００３１】
また、一次変換部４０７は、多種多様な送金依頼電文のフォーマットのそれぞれについて該フォーマットのどの位置にどの内容の項目がセットされているかを登録したマスタ（例えば、ＳＷＩＦＴ用マスタ４２２、インターネットバンキング用マスタ４２３、ある企業独自のフォーマットを記録した顧客マスタ４３１など）を利用して、送金依頼電文に含まれている各種項目を共通ＸＭＬ形式のフォーマット内の所定の位置にセットしていく。
【００３２】
重複チェック部４０８は、一次変換された（即ち、共通ＸＭＬ形式に変換された）送金依頼電文が重複して存在しているか否かを判定する。また、電文項目チェック部４０９は、各送金依頼電文について項目チェックを行う。例えば、決済日が先日付であるか否か、顧客マスタ４３１を利用して顧客ごとの決済時限（つまり、本システムにおける顧客ごとの送金依頼受付時限）に間に合うか否かなど、送金依頼電文に含まれている項目の必須チェック、属性チェック、桁数チェック、相関チェックなどを行う。
【００３３】
マスタ情報設定部４１０は、銀行マスタ４３０、口座マスタ４３２、通貨マスタ４３３などを使用して、送金依頼電文に含まれているデータ（銀行コード、支店コード、口座番号など）に基づいて必要な情報を当該送金依頼電文に付加していく。
【００３４】
二次変換部４１１は、共通ＸＭＬ形式の送金依頼電文を、銀行振込システム１０３が全銀ネットワーク１０２に送信可能なフォーマットに変換する処理（二次変換）を行う。二次変換された送金依頼電文は、振込先の宛先口座を持つ金融機関に対して全銀用ファイル作成・送信部４０３によって銀行振込システム１０３に送られ、銀行振込システム１０３から全銀ネットワーク１０２経由で送信される。
【００３５】
受取人マスタ４２０は、送金依頼電文に含まれている振込受取人名（英字）と振込受取人名（カナ）の組合せを登録してあるマスタである。また、代替実施形態として、顧客別に受取人識別用のコード（例えば「０１」）と振込受取人名（カナ）の組合せを登録しておくことも可能である。この受取人マスタ４２０から所望のデータを検索する際は、顧客マスタ４３１などの情報を元にして検索を行う。
【００３６】
変換テーブル４２１は、本発明に係る「テーブル変換方式」により振込受取人名（英字）を振込受取人名（カナ）に変換するためのテーブルである。図７に示すように、この変換テーブル４２１は、変換対象となる英字を２バイト固定文字とすることにより、一意的に英字→カタカナ変換を可能にしている。
【００３７】
ＳＷＩＦＴ用マスタ４２２は、所定のＳＷＩＦＴ準拠の電文形式（例えば、ＳＷＩＦＴ  ＭＴ１０１：「ＭＴ」はメッセージタイプの略）をＸＭＬ形式や共通ＸＭＬ形式に変換するための項目間の対応付け情報を格納し、インターネットバンキング用マスタ４２３は、インターネットバンキングシステムから送信された電文を共通ＸＭＬ形式に変換するための項目間の対応付け情報を格納する。
【００３８】
ここで、図７を参照して本発明に係る「テーブル変換方式」で使用する英字→カナへの変換テーブル４２１を説明する。図７は、本発明に係る「テーブル変換方式」の一実施例を示す変換テーブル（英字→カナ）であるが、全ての英字および記号等が２バイト固定の文字である点に特徴がある。つまり、従来からあった変換テーブルは、カタカナ１文字を表すのに１〜３バイトの文字を対応付けていたために一意的に変換処理ができなかったが、本発明ではこれを２バイト固定文字とすることで変換対象の英字を一意的に変換処理できるようにした点に特徴がある。
【００３９】
図７のうち、第Ａ群に示されている文字は、「ア行」「ン」を除くカタカナについての変換の対応付けを表しているテーブルである。一方、第Ｂ群に示されている文字は、「ア行」「ン」の他、各種記号の対応付けを表しているテーブルである。なお、図７に示した変換テーブルは一例であって、変換対象の全ての英字および記号等が２文字（２バイト）の固定であればどのようなものであっても構わない。
【００４０】
銀行マスタ４３０は、日本国内の銀行の銀行コード、銀行名、支店コード、支店名を保存しているマスタであり、顧客マスタ４３１は、企業独自フォーマットに含まれる各項目をＸＭＬ形式、共通ＸＭＬ形式のフォーマットに変換するための項目間の対応付けを示す情報や、顧客別の決済時限（本システムにおける顧客ごとの送金依頼受付時限）など顧客別に情報を設定しておくためのマスタである。また、口座マスタ４３２は、振込先となる口座が存在するか否かをチェックするためのマスタである。このチェックは、銀行マスタ４３０とともに、銀行コード、支店コード、口座科目、口座番号のデータセットをもとに行われる。また、通貨マスタ４３３は、外国通貨と円貨とを換算して振込を行う際に使用するマスタである。
【００４１】
受信管理テーブル４３４は、本発明に係るマルチフォーマット変換システム１００によって処理される送金依頼電文の処理状況データを記録するためのテーブルである。送金依頼電文が本システム１００によって受信されると対応する処理状況データが作成され、当該送金依頼電文が正常に振込処理されるか、または処理対象外・エラー発生と判断されるまで処理状況データのアップデートが行われる。
【００４２】
図５は、本発明に係るマルチフォーマット変換システム１００によって実行される、全銀ネットワーク１０２に送信可能なフォーマットの送金依頼電文を作成する一例を示すフロー図である。
【００４３】
ステップＳ５０１では、電文取込・検証部４０２は、所定の周期ごとに主記憶部２０２などに格納されている１つまたは複数の電文を読み込む。この電文には、インターネットバンキングおよびＳＷＩＦＴネットワーク経由で受信された送金依頼電文が両方含まれているが、他の種類の電文も含まれうる。
【００４４】
ステップＳ５０２では、電文取込・検証部４０２は、読み込まれた処理対象の電文が送金依頼電文であるのか否かを判定し、送金依頼電文ではない場合、当該電文の処理は終了する。
【００４５】
ステップＳ５０３では、送信電文フォーマット判定部４０５は、読み込んだ送金依頼電文がＳＷＩＦＴネットワーク経由で受信された電文であるか否かを判定する。当該判定は、電文に含まれているヘッダー情報などによって行うことができる。この判定をする理由は、インターネットバンキング経由で受信された電文（ＸＭＬ形式）とＳＷＩＦＴネットワーク経由で受信された電文（非ＸＭＬ形式およびＸＭＬ形式）とはそのフォーマットが異なるため、後続処理を分けるためである。
【００４６】
ステップＳ５０４では、一次変換部４０７は、ＳＷＩＦＴネットワーク経由で受信された送金依頼電文をＸＭＬフォーマットにファイル変換する。ＳＷＩＦＴネットワーク経由で受信した送金依頼電文はＸＭＬ形式ではない電文も含まれることがあり、かつ様々なフォーマットが存在する（例えば、ＳＷＩＦＴ  ＭＴ１０１など）。なお、ＳＷＩＦＴで使用できるフォーマットや企業独自フォーマットは既知であるため、当該既知のフォーマットに含まれる各々の項目（電文内でその記録位置が定まっている）をＸＭＬ形式の対応する各項目にセットする詳細な処理の説明は省略する。
【００４７】
ステップＳ５０５では、一次変換部４０７は、送金依頼電文を全て共通ＸＭＬ形式に変換して揃える処理を行う。ステップＳ５０４までの処理によって処理対象の送金依頼電文は全てＸＭＬ形式に揃えられている。しかし、それらのフォーマットはまだ複数の形式が存在するため、本ステップにおいて共通ＸＭＬ形式のフォーマットに揃えることにより後続の処理を行いやすくする。
【００４８】
一次変換部４０７は、多種多様な送金依頼電文のフォーマットのそれぞれについて該フォーマットのどの位置にどの内容の項目がセットされているかを登録したマスタ（例えば、ＳＷＩＦＴ用マスタ４２２、インターネットバンキング用マスタ４２３、顧客マスタ４３１など）を利用して、送金依頼電文に含まれている各種項目を共通ＸＭＬ形式のフォーマット内の所定の位置にセットする。また、本ステップにおいて全ての送金依頼電文が共通ＸＭＬ形式のフォーマットに揃えられるため、外部から受信する電文はどのような形式であっても構わない。なお、本ステップによる変換を後処理の変換と対比する意味で「一次変換」とも呼ぶ。
【００４９】
ステップＳ５０６では、重複チェック部４０８は、一次変換された（即ち、共通ＸＭＬ形式に変換された）送金依頼電文が重複して存在しているか否かを判定する。重複する送金依頼電文が存在する場合、当該送金依頼電文については本処理フローを終了する。
【００５０】
ステップＳ５０７では、電文項目チェック部４０９は、各送金依頼電文について項目チェックを行う。例えば、決済日が先日付であるか否か、顧客マスタ４３１を利用して顧客ごとの送金依頼受付時限に間に合うか否かなど、送金依頼電文に含まれている項目の必須チェック、属性チェック、桁数チェック、相関チェックなどを行う。なお、各種チェックでエラーとなった送金依頼電文については、本ステップの後続の処理は行わず、本処理フローを終了する。
【００５１】
ステップＳ５０８では、マスタ情報設定部４１０は、銀行マスタ４３０、口座マスタ４３２、通貨マスタ４３３などを使用して、送金依頼電文に含まれているデータをキーにして必要な情報を当該送金依頼電文に付加していく。なお、各種マスタ４３０、４３２、４３３などから項目を設定する処理においてエラーが発生した場合には、当該送金依頼電文の処理は終了する。
【００５２】
ステップＳ５０９では、マルチフォーマット変換システム１００は、受取人マスタ４２０および変換テーブル４２１を用いて、送金依頼電文に含まれている振込受取人名の「英字」を「全銀文字（カナ）」に変換する処理を行う。当該処理の詳細は、図６に示す処理フローを参照しながら後述する。
【００５３】
ステップＳ５１０では、二次変換部４１１は、上記の各ステップでデータ処理された送金依頼電文を、全銀ネットワーク１０２に送信可能なフォーマットに変換する。この変換処理を上述の一次変換と区別する意味で二次変換と呼ぶこととする。二次変換された送金依頼電文は、その後、ステップＳ３０４で説明したように銀行振込システム１０３を介して振込先の口座を持つ金融機関に対して全銀ネットワーク１０２経由で送信される。
【００５４】
図６は、本発明に係る、振込受取人名変換処理の詳細を示す処理フローである。
【００５５】
ステップＳ６０１では、処理対象の送金依頼電文について「事前登録変換方式」により振込受取人名を変換可能か否かを判定する。「事前登録変換方式」とは、振込受取人名（英字）と振込受取人名（カナ）の組合せを事前に登録したテーブルを用意し、変換処理を行う方式である。つまり、マルチフォーマット変換システム１００は、受取人マスタ４２０を参照し、送信元の顧客が予め登録している振込受取人名（英字）が当該送金依頼電文に含まれているか否かを判定する。含まれていると判定された場合にはステップＳ６０２に処理が進み、含まれていないと判定された場合にはステップＳ６０３に処理が進む。
【００５６】
ステップＳ６０２では、マルチフォーマット変換システム１００は、受取人マスタ４２０に登録されている振込受取人名（カナ）の情報を取得し、当該送金依頼電文にセットする。また、代替の実施形態として、本発明においては、受取人マスタ４２０に顧客別に振込受取人情報を変換するための英数字（例えば、「０１」）を登録させておき、当該英数字に対応する振込受取人名（例えば、「ワカクサ タロウ」）を指定することができる。これにより、顧客は振込受取人名（英字）を送金依頼電文に指定する代わりに、当該英数字（「０１」）を指定することで振込受取人名（英字）→振込受取人名（カナ）の変換を実現することができる。
【００５７】
ステップＳ６０３では、当該送金依頼電文が本発明に係る「テーブル変換方式」の対象になりうるか否かを判定する。「テーブル変換方式」とは、所定の変換テーブルに基づいて振込受取人名を入力された英字からカナに変換する方式である。本発明では、図７に示すような、カタカタ１文字が英数字２文字に対応し、また記号１文字が同一の記号二文字に対応する変換テーブルを使用する。つまり、送金依頼電文に含まれる変換対象の振込受取人名（英字）は２バイト固定文字となる。
【００５８】
ここで、「変換対象の」振込受取人名（英字）と記載している意味を説明する。変換後も英数字のままで表現したい場合には、本発明においては図７の第Ｂ群に示す「ｚｚ」で囲むようにすることができる。例えば、変換後も「ABC」とそのまま表現したい場合、「ZZABCZZ」と入力することで英数字部分の「ABC」をそのまま表現することができる。このようにすることで、本発明では、海外の顧客が送信する送金依頼電文の振込受取人名の項目は、一意的に変換したい文字と変換せずにそのままにしておきたい文字とを混在させることができる。以下、図９を使用してステップＳ６０３の処理の詳細を説明する。
【００５９】
ステップＳ９０１では、マルチフォーマット変換システム１００は、送金依頼電文に含まれている振込受取人名（英字）を検索し、振込受取人名（英字）を先頭から２バイトずつ読み込む。ステップＳ９０２では、読み込みができたか否かを判定する。最後の文字まで図９のフロー図により処理がなされている場合には、読み込まれないので、ステップＳ６０４の処理に進む。
【００６０】
ステップＳ９０３では、読み込まれた２バイト文字が「ｚｚ」であるか否かを判定する。「ｚｚ」であると判定された場合にはステップＳ９０７に処理が進み、一方、「ｚｚ」ではないと判定された場合にはステップＳ９０４に処理が進む。
【００６１】
ステップＳ９０４では、読み込まれた２バイト文字のうち、第１のバイト文字と第２のバイト文字が同一であるか否かが判定される。ここで、「テーブル変換方式」のデータ処理のイメージを示す図８を参照する。図８に示すように、２バイト文字のうち先頭から見て最初の１バイトで表される文字が第１のバイト文字であり、２バイト文字のうち第１のバイトと異なるバイト（つまり、次のバイト）の方が第２のバイト文字である。例えば、図８では、先頭から最初の２バイトでは第１のバイト文字および第２のバイト文字は、それぞれ、「Ｗ」、「Ａ」である。
【００６２】
ステップＳ９０４において、同一であると判定された場合にはステップＳ９０６に処理が進む。一方、同一ではないと判定された場合にはステップＳ９０５に処理が進む。
【００６３】
ステップＳ９０５では、第２のバイトが母音（Ａ、Ｉ、Ｕ、Ｅ、Ｏ）であるか否かを判定する。第２のバイトが母音ではない場合、本発明に係る「テーブル変換方式」の対象ではないため、ステップＳ６０５に処理が進む。一方、母音であると判定された場合には、ステップＳ９０６に処理が進む。
【００６４】
ステップＳ９０６では、当該２バイトの文字が図７に例示した変換テーブルに存在するか否かが判定される。変換テーブルに存在すると判定された場合にはステップＳ９０１に処理が戻り、次の２バイトを読み込む処理を行う。この際、マルチフォーマット変換システム１００は、変換対象の文字を特定して対応付けられる文字に変換待ちにする処理を行う。つまり、変換前と変換後の文字データを主記憶部２０２に一時的に保存しておき、後述のステップＳ６０４の処理を待つ。一方、変換テーブルに存在しないと判定された場合にはステップＳ６０５に処理が進む。
【００６５】
ステップＳ９０７では、振込受取人名（英字）の中に変換後も英数字のままにしておきたい文字（非変換対象文字）がふくまれている場合に該当するケースなので、図７に例示した第Ｂ群の「ｚｚ」で囲まれているか否かを判定していく。当該処理の詳細を図１０を参照しながら説明する。
【００６６】
ステップ１００１では、マルチフォーマット変換システム１００は、ステップＳ９０３で読み込まれた「ｚｚ」の次の１文字を読み込む。ステップＳ１００２では、１文字が読み込まれた否かを判定する。読み込まれなかった場合は、一組の「ｚｚ」で囲まれていないことを示すか、あるいは、振込受取人名（英字）が「ｚｚ」で終わっていることを示すので、図９の処理に対して引数「ＮＧ」を返す。
【００６７】
ステップＳ１００３では、マルチフォーマット変換システム１００は、読み込まれた１文字が「ｚ」であるか否かを判定する。「ｚ」である場合にはステップＳ１００４に処理が進み、「ｚ」でない場合には、ステップＳ１００１に処理が戻り、次の１文字を読み込む。
【００６８】
ステップＳ１００４では、マルチフォーマット変換システム１００は、さらに１文字を読み込む。ステップＳ１００５では、さらに読み込まれた１文字が「ｚ」であるのか否かを判定する。「ｚ」であると判定された場合には「ｚｚ」が検出されたことを意味するので、図９の処理に対して引数「ＯＫ」を返す。一方、「ｚ」でないと判定された場合にはステップＳ１００１に処理が戻り、次の１文字を読み込む。
【００６９】
図１０に示した各ステップの処理を行うことにより、振込受取人名（英字）に「ｚｚ」で囲まれた、非変換対象の文字が含まれているか否かを判定することができる。ここで、非変換対象の文字が含まれていると判定された場合には、マルチフォーマット変換システム１００は、非変換対象の文字を特定しておき、当該文字については変換しないことを示す情報を主記憶部２０２に一時的に保存する。そして、後述のステップＳ６０４の処理を待つ。
【００７０】
図９に戻って説明を続ける。ステップＳ９０７の判定処理を行うことにより、「ＯＫ」または「ＮＧ」の引数が得られるので、「ＯＫ」の場合にはステップＳ９０１に処理が戻り、一方、「ＮＧ」の場合にはステップＳ６０５の処理に処理が進む。
【００７１】
このように、図９に示した上述のような判定を行うことにより、送金依頼電文に含まれた振込受取人名（英字）が本発明に係る「テーブル変換方式」の対象になりうるか否かを判定することができる。
【００７２】
再び、ステップＳ６０４に戻って説明すると、マルチフォーマット変換システム１００は、送金依頼電文に含まれている振込受取人名（英字）を、主記憶部２０２に一時保存してある、特定された変換前と変換後との文字データの情報および非変換対象の文字データの情報を用いて振込受取人名（カナ）に変換する。このようにすることで、外部から受信した送金依頼電文に含まれている振込受取人名（英字）を顧客が意図したとおりに一意的に振込受取人名（カナ）に変換することが可能となる。
【００７３】
ステップＳ６０５では、周知の方法を用いて英字→カタカナに変換処理を行えるか否かを判定する。つまり、本ステップの処理は、周知の処理の組合せ（例えば、変換対象の文字が１文字や３文字：「SHI」→「シ」、「SAMBA」→「サンバ」など）であるため、その詳細な処理の説明は省略する。なお、この変換処理を「ロジック変換処理」と呼ぶことにする。また、ステップＳ６０６では、「ロジック変換方式」にしたがって変換対象の送金依頼電文の振込受取人名（英字）を振込受取人名（カナ）に変換する処理を行う。
【００７４】
ステップＳ６０７では、本発明に係るマルチフォーマット変換システム１００では送金依頼電文に含まれている振込受取人名（英字）の変換ができなかった場合の例外処理（例えば、空欄によるエラー、誤入力）を行う。具体的には、マルチフォーマット変換システム１００の入力部２０４が提供するユーザーインターフェースを介してオペレータにより振込受取人名（カナ）を入力すること等を行う。
【００７５】
なお、図６の処理フローでは、３つの変換方式を順番に行っていったが、顧客マスタ４３１に顧客ごとにいずれの変換方式を使用するかを登録しておき、その登録された情報に基づいて変換方式を選択することが可能である。
【００７６】
以上、例示的な実施形態を参照しながら本発明の原理を説明したが、様々な実施形態を本発明の要旨を逸脱することなく、構成および細部において変更できることが当業者には理解されよう。
【符号の説明】
【００７７】
２０１  制御部
２０２  主記憶部
２０３  補助記憶部
２０４  入力部
２０５  出力部
４０１  電文受付・確認部
４０２  電文取込・検証部
４０３  全銀用ファイル作成・送信部
４０４  送信結果受信・取込部
４０５  送信電文フォーマット判定部
４０６  ＸＭＬ変換部
４０７  一次変換部
４０８  重複チェック部
４０９  電文項目チェック部
４１０  マスタ情報設定部
４１１  二次変換部
４２０  受取人マスタ
４２１  変換テーブル
４２２  ＳＷＩＦＴ用マスタ
４２３  インターネットバンキング用マスタ
４３０  銀行マスタ
４３１  顧客マスタ
４３２  口座マスタ
４３３  通貨マスタ
４３４  受信管理テーブル
【図１】
2010277344.tif 000003
【図２】
2010277344.tif 000004
【図３】
2010277344.tif 000005
【図４】
2010277344.tif 000006
【図５】
2010277344.tif 000007
【図６】
2010277344.tif 000008
【図７】
2010277344.tif 000009
【図８】
2010277344.tif 000010
【図９】
2010277344.tif 000011
【図１０】
2010277344.tif 000012