JP2020197768A - 情報処理装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】勘定系システムと、他のシステムや他の業務との連携をより容易にする情報処理装置、情報処理方法、及びプログラムを提供する。
【解決手段】情報処理システム１において、情報処理装置１０は、クライアントから取得した第１データに基づいてシステムを特定し、システムで処理の実行が可能な第２データに変換し、第２データをシステムに送信し、システムから取得した処理結果から処理の成否を判定する。処理が成立した場合は、処理結果から第３データを選択し、第３データを出力する。また、第１データは、依頼人名及び取引種別であって、依頼人名を顧客識別番号に変換し、顧客識別番号及び取引種別に基づいて、システムを特定する。
【選択図】図１

Description

本発明は、情報処理装置、情報処理方法、及びプログラムに関する。

金融機関における勘定系システムは、銀行業務の中核を担う重要なシステムであり、顧客の口座の残高の管理や、利息計算、入出金、振込、送金の処理、為替取引、他の金融機関との資金決済を実行する。各銀行は、数十年にわたって多大なコストをかけ、巨大かつ信頼性の高い勘定系システムを独自に構築している。

特許文献１には、勘定系システムと、為替取引のためのシステムとの連携を図る銀行システムについて開示されている。特許文献１の銀行システムは、顧客の端末、勘定系システムおよび為替取引管理システムに接続された顧客システムを有する銀行システムにおける外貨預金を用いた為替取引方法において、顧客システムが、為替取引管理システムから第１レートを含むレート情報を取得して、顧客の端末から受信した取引要求情報とともに、勘定系システムに送信する第１ステップと、勘定系システムが、予め格納された第２レートに基づいて、定期預金口座の残高から担保差入可能額を算出して貸越テーブルに格納する第２ステップと、取引要求情報に含まれる出金金額に基づいて、勘定系システムが、貸越テーブルの担保差入可能額と出金口座となる流動性預金口座の残高との合計から出金金額を減額し、取引要求情報で指定された入金口座となる流動性預金口座の残高を、レート情報の第１レートに従って更新する第３ステップと、を備えている。

特開２００６−２０９６７７号公報

勘定系システムは、勘定系システム内におけるデータの処理に長けている一方で、勘定系システムと連携する他のシステムに対しては、データの処理が制約される場合がある。そのため、特許文献１に記載されているように、他のシステムや、他の業態と連携するための方法が複雑である。また、他のシステムから、勘定系システムに連携させる場合、データの形式が異なると異常終了となるため、例外的な処理を行う必要がある。

そこで、本発明では、勘定系システムと、他のシステムや他の業務との連携をより容易にすることを目的の一とする。

本発明の一実施形態に係る情報処理方法は、クライアントから取得した第１データに基づいてシステムを特定し、システムで処理の実行が可能な第２データに変換し、第２データをシステムに送信し、システムから取得した処理結果から処理の成否を判定し、処理が成立した場合は、処理結果から第３データを選択し、第３データを出力する、情報処理方法。

上記方法において、第１データは、依頼人名及び取引種別であって、依頼人名を顧客識別番号に変換し、顧客識別番号及び取引種別に基づいて、システムを特定する。

上記方法において、第１データは、依頼人名及び取引種別であって、依頼人名及び取引種別に基づいて、システムを特定する。

上記方法において、第２データに変換することは、特定されたシステムに基づいて、当該システムに対応するコードに変換することを含む。

上記方法において、処理結果は、リターンコードを含み、リターンコードに基づいて、処理の成否を判定する。

上記方法において、処理が不成立と判定する場合、不成立の結果をクライアントに出力する。

上記情報処理方法を、コンピュータに実行させるためのプログラム。

本発明の一実施形態に係る情報処理装置は、クライアントから取得した第１データを処理するシステムを特定するシステム特定部と、第１データをシステムで処理するための第２データに変換する変換部と、システムで第２データを処理した処理結果を取得する処理結果取得部と、処理結果から処理の成否を判定する判定部と、を有する。

上記構成において、第１データは、依頼人名及び取引種別であって、システム特定部は、依頼人名と顧客識別番号とが対応付けられた第１テーブルを参照して、依頼人名を顧客識別番号に変換し、顧客識別番号と取引種別とが対応付けられた第２テーブルを参照して、システムを特定する。

上記構成において、第１データは、依頼人名及び取引種別であって、システム特定部は、依頼人名と取引種別とが対応付けられた第３テーブルを参照して、システムを特定する。

上記構成において、変換部は、システムとシステムに対応するコードとが対応づけられた第４テーブルを参照して、システムをコードに変換する、コード変換部を有する。

上記構成において、判定部は、処理結果に含まれるリターンコードに基づいて、処理の成否を判定する。

上記構成において、判定部が、処理が不成立と判定する場合、不成立の結果をクライアントに出力する。

本発明では、勘定系システムと他のシステムとの連携をより容易にすることができる。

本発明の一実施形態に係る情報処理装置の概要を説明する図である。 プロバイダに含まれるシステムの一例である。 顧客情報テーブルの一例である。 コード変換テーブルに含まれるテーブルの一例である。 コード変換テーブルに含まれるテーブルの一例である。 本発明の一実施形態に係る情報処理装置のハードウェアの構成を説明する図である。 本発明の一実施形態に係る情報処理装置の機能ブロックを説明する図である。 クライアントに提供されるＷＥＢアプリケーションの表示画面の一例である。 クライアントに提供されるＷＥＢアプリケーションの表示画面の一例である。 クライアントに提供されるＷＥＢアプリケーションの表示画面の一例である。 情報処理装置、クライアント、及びプロバイダの各々で処理されるデータの一例である。 本発明の一実施形態に係る情報処理方法を説明するフローチャートである。 本発明の一実施形態に係る情報処理方法を説明するフローチャートである。 本発明の一実施形態に係る情報処理装置の機能ブロックを説明する図である。

＜第１実施形態＞
本発明の一実施形態に係る情報処理装置１０を含む情報処理システム１について、図１乃至図１４を参照して説明する。

［情報処理装置の概要］
図１は、本発明の一実施形態に係る情報処理装置１０を含む情報処理システム１の構成を説明する図である。図１に、情報処理装置１０、クライアント２０、及びプロバイダ３０を示す。情報処理装置１０と、クライアント２０とは、ネットワーク４０を介して、データを送受信する。クライアント２０はデータを送信し、情報処理装置１０を介して、プロバイダ３０で処理されたデータの提供を受ける。

クライアント２０は、プロバイダ３０に対してサービスの依頼を行い、当該サービスの提供を受けるものをいう。ここで、クライアント２０は、例えば、パーソナルコンピュータ、スマートフォン、タブレットなどの端末装置である。また、クライアント２０は、店舗に設置されるＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）であってもよい。クライアント２０は、制御部２０１、表示部２０２、操作部２０３、及び通信部２０４を有している。制御部２０１は、表示部２０２に表示されたユーザインタフェースから、操作部２０３によって残高照会を指示したり、振り込みを指示したりする機能を有する。また、クライアント２０は、情報処理装置１０と有線又は無線により通信が接続され、操作信号やデータなどを送受信する。

プロバイダ３０は、クライアント２０に対して、サービスを提供するものをいう。ここで、プロバイダ３０は、金融機関が提供するいわゆる勘定系システムを含む。本明細書等において、勘定系システムとは、預金勘定元帳を処理し、為替、ＡＴＭネットワークとの接続を制御する基幹系システムをいう。図２に、プロバイダ３０が有するシステムの一例を示す。プロバイダ３０は、少なくとも勘定系システム３１０を有しており、勘定系システム３１０は、預金業務３１１、融資業務３１２、為替業務３１３、日計業務３１４、自振業務３１５、顧客管理３１６を有する。プロバイダ３０は、上記した勘定系システム３１０の他、いわゆる国際系システム３２０、情報系システム３３０、インターネットバンキング、営業店端末などチャネル系システム３４０を含んだオンラインシステム全般との接続を制御するシステムが含まれていてもよい。プロバイダ３０は、情報処理装置１０と有線又は無線により通信が接続され、操作信号やデータなどを送受信する。また、プロバイダ３０は、勘定処理に必要なデータが格納された業務データ格納部３１を有している。

勘定系システムは、勘定系システム内におけるデータの処理に長けている一方で、他のシステムに対しては、データの入力形式が固定化されるため、データの処理が制約される場合がある。そのため、他のシステムから、勘定系システムに連携させる場合、データの形式が異なると異常終了となるため、例外的な処理を行う必要がある。

そこで、本発明では、勘定系システムと、他のシステムや他の業務との連携をより容易にする。

情報処理装置１０は、クライアント２０からプロバイダ３０への残高照会や、振り込みなどの指示を、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用して実現する。本実施形態では、ＡＰＩとして、ＷＥＢＡＰＩを使用する例について説明する。ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）のＷＥＢＡＰＩは、ＧＥＴ（取得）、ＰＯＳＴ（登録）、ＰＵＴ（更新）、ＤＥＬＥＴＥ（削除）のメソッドと、リソースを特定するＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を用いたリクエスト（「要求」や「要求データ」とも言う）を勘定系システムに送信し、勘定系システムからレスポンス（「応答」や「応答データ」とも言う）をＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）やＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などで受け取る。

勘定系システムで処理をするために必要なデータについてはクライアント２０に公開することなく、クライアント２０が必要とするデータのみを提供することができる。以下、情報処理装置１０の具体的な構成について説明する。

［情報処理装置のハードウェア構成］
図６は、本発明の一実施形態に係る情報処理装置１０のハードウェア構成を説明するブロック図である。図６に示すように、情報処理装置１０は、制御部１０１、記録媒体１０５、表示部１０２、操作部１０３、及び通信部１０４を有する。

制御部１０１は、例えば、ＣＰＵ（Ｃｅｍｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等であり、後述する機能ブロックの動作を制御する。制御部１０１は、例えば、ＲＯＭ及び記録媒体１０５に記録されている動作プログラムを読み出し、ＲＡＭに展開して動作プログラムを実行することにより、各機能ブロックによって情報処理装置１０の処理機能を実現する。

表示部１０２は、液晶ディスプレイ、有機ＥＬディスプレイなどの表示装置であって、制御部１０１の制御によって、各種の画面を表示する。操作部１０３は、ユーザからの操作を受け付けて、操作に応じた信号を制御部１０１に出力する操作装置であって、この例ではキーボードおよびマウスである。通信部１０４は、制御部１０１の制御により、ネットワーク４０と接続して、クライアント２０及びプロバイダ３０など、他の装置とデータの送受信を行う。

記録媒体１０５は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の恒久的な情報保持及びデータの書き換えが可能な記録装置である。記録媒体１０５は、顧客情報テーブル１０６、コード変換テーブル１０７、及びプログラム１０８が含まれる。

顧客情報テーブル１０６は、各顧客氏名に紐づけられて、顧客識別番号（Ｃｕｓｔｏｍｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｉｌｅ）番号）、性別、住所、電話番号、勤務先、勤務先住所、口座を開設した店番号などの属性情報が種類別に格納されている。図３は、顧客情報テーブル１０６の一例である。ここで、属性情報の「種別」とは、氏名、性別、住所、電話番号などの属性情報の種類を意味する。また、種別の数は、上記の８種類に限定されるものではなく、多数の種別の属性情報を含んでいてもよい。また、顧客情報テーブル１０６は、各顧客に紐づけられている顧客識別番号（Ｃｕｓｔｏｍｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｉｌｅ）番号）毎に属性情報を含んでいてもよい。

コード変換テーブル１０７は、クライアント２０から取得したデータを、プロバイダ３０で処理するためのデータに変換するためのテーブルである。クライアント２０から取得したデータは、プロバイダ３０において、そのまま処理することが困難である。また、クライアント２０から取得したデータだけでは不十分な場合がある。そのため、クライアント２０から取得したデータを変換したり、クライアント２０から取得したデータに形式的なデータを追加したりして、プロバイダ３０で処理することが可能なフォーマットにする必要がある。例えば、コード変換テーブル１０７には、顧客の氏名、顧客識別番号、店の番号などの属性情報と、取引種別と、勘定処理に必要な勘定系システムに含まれるシステムと、当該システムに対応するコードが格納されている。ここで、取引種別とは、残高照会であってもよいし、振込・振替であってもよい。また、コード変換テーブル１０７には、国コード、ＳＷＩＦＴ（Ｓｏｃｉｅｔｙ ｆｏｒ Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｂａｎｋ Ｆｉｎａｎｃｉａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）、店別通貨別休日、為替レート、取引種別コード、プログラム名、顧客別レート優遇条件などの銀行内のマスター系のデータが、随時蓄積される。また、コード変換テーブル１０７に格納されるテーブルは、一種類に限定されない。コード変換テーブル１０７は、クライアント２０から取得したデータを変換するためのテーブルが複数種格納してもよい。コード変換テーブル１０７は、例えば、顧客識別番号及び取引種別に対応するシステムのテーブル、システムに対応するコードのテーブル、取引種別に対応するコードのシステムなど、複数のテーブルを格納する。図４は、顧客識別番号及び取引種別に対応するシステムのテーブルの一例であり、図５は、システムに対応するコードのテーブルの一例である。

プログラム１０８は、図７で説明する各種機能ブロックを実現するためのプログラムを含む。なお、プログラム１０８は、磁気記録媒体、光記録媒体、光磁気記録媒体、半導体メモリなどのコンピュータ読み取り可能な記録媒体に記憶した状態で提供されてもよい。この場合には、情報処理装置１０は、記録媒体を読み取る装置を備えていればよい。また、プログラム１０８は、ネットワーク４０経由でダウンロードされてもよい。

［情報処理装置の機能ブロック図］
次に、情報処理装置１０の制御部１０１によって実現される情報処理機能について、図７乃至図１０を参照して説明する。情報処理機能では、クライアント２０から取得したデータを、プロバイダ３０で処理するためのデータに変換し、プロバイダ３０から取得した処理結果を、クライアント２０に提供するためのデータにする。

図７は、本発明の一実施形態に係る情報処理装置１０の機能ブロック図である。図８乃至図１０は、クライアント２０に表示されるＷＥＢアプリケーション５００の表示画面の一例である。図１１は、情報処理装置１０、クライアント２０、プロバイダ３０の各々で処理されるデータの一例である。また、図１１（Ａ）及び図１１（Ｆ）は、クライアント２０のデータの一例であり、図１１（Ｂ）及び図１１（Ｅ）は、情報処理装置１０のデータの一例であり、図１１（Ｃ）及び図１１（Ｄ）は、プロバイダ３０のデータの一例である。

図７に示すように、情報処理装置１０は、ＷＥＢアプリケーション１１０、データ取得部１１１、システム特定部１１２、コード変換部１１３、コード生成部１１４、コード送信部１１５、処理結果取得部１２１、判定部１２２、選択部１２３、顧客情報テーブル１０６、及びコード変換テーブル１０７を有する。

ＷＥＢアプリケーション１１０は、情報処理装置１０への指示を行う機能を有する。クライアント２０は、ＷＥＢアプリケーション１１０によって、プロバイダ３０からのデータの提供を要求するために必要なデータを入力し、情報処理装置１０へ送信する。また、ＷＥＢアプリケーション１１０は、プロバイダ３０によって処理された処理結果を、クライアント２０に出力する機能を有する。

図８は、クライアント２０に表示されるＷＥＢアプリケーション５００の表示画面の一例である。図８に示すＷＥＢアプリケーション５００では、ユーザがログインした状態を示している。ＷＥＢアプリケーション５００には、ユーザである依頼人名５０１、支店名５０２、口座番号５０３、金額５０４、及び取引種別５０５〜５０７が表示される。図８では、取引種別５０５は残高照会、取引種別５０６は、入出金明細の確認、及び取引種別５０７は、振込・振替を示している。本実施形態では、ユーザが取引種別５０７として振込・振替を選択する場合について説明する。

図９は、クライアント２０に表示されるＷＥＢアプリケーション５００の表示画面の一例である。本実施形態では、ユーザが取引種別５０７として、振込・振替を選択しているため、ユーザはＷＥＢアプリケーション５００において、顧客が知りうるデータとして、取引日５０８、取引金額５０９、送金先５１１を入力する。図１１（Ａ）に、クライアント２０から入力されるデータの一例を示す。

データ取得部１１１は、ＷＥＢアプリケーション１１０に入力されたデータを取得する。データ取得部１１１は、取引の種類に応じて必要なデータを取得する。ここでは、取引種別として振り込みを実行する場合は、必要なデータは、依頼人名５０１、取引日５０８、取引金額５０９、送金先５１１などのデータである。

システム特定部１１２は、クライアント２０から取得したデータから、プロバイダ３０で処理するための連携先システムを特定する。システム特定部１１２は、図３に示す顧客情報テーブル１０６を参照して、依頼人名から顧客識別番号に変換する。ここでは、図３に示すように、「山田太郎」から「ＡＡ１１１１ＢＢ」に変換する。次に、システム特定部１１２は、図４に示すコード変換テーブル１０７Ａを参照して、顧客識別番号（ＣＩＦ）及び取引種別に基づいて、連携先システムを特定する。ここでは、図４に示すように、「顧客識別番号」から、連携先システムとして為替業務３１３のシステムを特定する。システム特定部１１２は、連携先システムをコード変換部１１３に送信する。

コード変換部１１３は、連携先システムを取得すると、図５に示すコード変換テーブル１０７Ｂを参照して、プロバイダ３０における連携先システムを特定し、連携先システムに対応するコードに変換する。ここでは、コード変換部１１３は、為替業務３１３のシステムに対応するコード「１１１１−１１３」に変換する。また、コード変換部１１３は、コード変換テーブル１０７を参照して、取引種別から取引種別コードを生成する。ここでは、取引種別は振込・振替であるため、振込・振替に対応するコードに変換する。コード変換部１１３は、連携先システムのコード及び取引種別コードをコード生成部１１４に送信する。

コード生成部１１４は、コード変換部１１３から連携先システムに対応するコードを取得すると、コード変換テーブル１０７を参照して、連携先システムのコードから共通ヘッダを生成し、適用レート、及び計算応当日を生成する。ここでは、コード生成部１１４は、為替業務３１３のシステムに対応するコードから、為替業務３１３のシステムで使用される共通ヘッダを生成し、適用レート、計算応当日を生成する。さらに、コード生成部１１４は、データ取得部１１１から取引金額及び取引日を取得する。コード生成部１１４は、顧客識別番号、連携先システムのコード、共通ヘッダ、取引種別に対応するコード、適用レート、計算応当日、取引金額、及び取引日などのデータを、コード送信部１１５に送信する。図１１（Ｂ）に、情報処理装置１０からプロバイダ３０に送信されるデータの一例を示す。コード生成部１１４で生成されるコードは一例であり、上記のコードに限定されない。特定されたシステムに応じて、適宜使用するコードは異なる。

コード送信部１１５は、コード生成部１１４から取得したデータを、プロバイダ３０に送信する。

プロバイダ３０は、情報処理装置１０から受信したデータに基づいて、連携先システムにおいて勘定処理を実行する。ここでは、プロバイダ３０は、為替業務３１３のシステムにおいて、振込・振替処理を実行する。図１１（Ｃ）に、プロバイダ３０の連携先システムにおいて、処理されるデータの一例を示す。次に、連携先システムは、顧客識別番号、店番、リターンコード、取引後残高、処理通番、ＩＢＡＮ、取引金額、取引日などデータを含む処理結果を生成する。図１１（Ｄ）に、連携先システムで生成された処理結果の一例を示す。なお、ＩＢＡＮ（アイバン）は、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂａｎｋ Ａｃｃｏｕｎｔ Ｎｕｍｂｅｒの略で、「国際銀行口座番号」とも呼ばれ、主にヨーロッパ（欧州）で使われる、銀行口座の所在国・支店・口座番号を一意に特定するための統一規格のコードである。プロバイダ３０は、連携先システムで生成された処理結果を、情報処理装置１０に送信する。

処理結果取得部１２１は、プロバイダ３０から勘定処理の処理結果を取得する。処理結果取得部１２１は、勘定処理の処理結果を、判定部１２２に送信する。

判定部１２２は、処理結果に含まれるリターンコードから、勘定処理の成否を判定する。勘定処理が成立した場合は、処理結果に含まれるリターンコード以外のデータを、選択部１２３に送信する。また、勘定処理が不成立の場合は、勘定処理が不正立である結果を、ＷＥＢアプリケーション１１０に送信する。

選択部１２３は、コード変換テーブル１０７を参照して、処理結果取得部１２１から取得したデータから、取引種別の処理結果に対応するデータを選択する。クライアント２０に開示する必要のないデータは、ここでは選択されない。選択部１２３は、処理結果取得部１２１から取得した顧客識別番号、店番、取引後残高、処理通番、ＩＢＡＮ、取引金額、取引日などのデータから、クライアント２０に出力するデータを選択する。ここでは、選択部１２３は、コード変換テーブル１０７を参照して、処理結果取得部１２１から取得したデータから、振込・振替の処理結果に対応する取引後残高及び処理通番を選択する。図１１（Ｅ）に、クライアント２０に出力するデータの一例を示す。

ＷＥＢアプリケーション１１０は、取引後残高、処理通番、及び取引の成否（処理の成否）をクライアント２０に出力する。図１０は、クライアント２０に表示されるＷＥＢアプリケーション５００の表示画面の一例である。本実施形態では、ユーザが取引種別５０７として、振込・振替を選択しているため、ユーザはＷＥＢアプリケーション５００において、ユーザが選択した取引種別に関する処理結果が表示される。処理結果として、取引の成否５１２、取引後残高５１３、及び処理通番５１４が表示される。図１１（Ｆ）に、クライアント２０に提供するデータの一例を示す。

［情報処理方法］
次に、情報処理装置１０で実行される情報処理方法について、図１２及び図１３を参照して説明する。

まず、情報処理装置１０のデータ取得部１１１は、クライアント２０からデータを取得する（ステップＳ４０１）。次に、システム特定部１１２は、取得したデータに基づいて、プロバイダ３０の連携先システムを特定する（ステップＳ４０２）。次に、コード変換部１１３は、コード変換テーブルを参照して、特定した連携先システムに基づいて、データをコードに変換する（ステップＳ４０３）。次に、コード生成部は、特定した連携先システムで処理するためのコードを生成する（ステップＳ４０４）。次に、コード送信部は、特定した連携先システムに、変換したデータを送信する（ステップＳ４０５）。

次に、情報処理装置１０の処理結果取得部１２１は、プロバイダ３０の連携先システムが処理した処理結果を取得する（ステップＳ４１１）。判定部１２２は、処理結果に含まれるリターンコードから取引の成否を判定する（ステップＳ４１２）。判定部１２２は、取引が成立したと判定した場合（ステップＳ４１２；Ｙｅｓ）は、ステップＳ４１３に進み、取引が不成立であると判定した場合（ステップＳ４１２；Ｎｏ）は、ステップＳ４１５に進む。取引が成立した場合（ステップＳ４１２）は、取得した処理結果から、クライアント２０が必要とするデータだけを選択する（ステップＳ４１３）。次に、ＷＥＢアプリケーションは、取引の成立及び選択されたデータをクライアント２０に出力する（ステップＳ４１４）。なお、取引が不成立である場合は、ＷＥＢアプリケーションは、取引が不成立だったことをクライアント２０に出力する。

以上説明した通り、クライアント２０からプロバイダ３０へデータの処理を要求する際に、情報処理装置１０によって、プロバイダ３０が有するシステムにおいて処理の実行が可能なデータに変換することができる。また、クライアント２０と、プロバイダ３０とを連携させる場合に、データの形式が異なっていたとしても、情報処理装置１０によって、プロバイダ３０で処理の実行が可能なデータに変換することができるため、異常終了となることを抑制することができるため、例外的な処理を行う必要もなくなる。

（変形例）
以上、本発明の一実施形態について説明したが、以下の通り変形して実施することも可能である。

（１）システム特定部１１２は、プロバイダ３０で処理するための連携先システムを特定する際に、顧客情報テーブル１０６を参照して、依頼人名を顧客識別番号に変換した後、顧客識別番号及び取引種別に基づいて連携先システムを特定する例について説明したが、これに限定されない。例えば、システム特定部１１２は、コード変換テーブル１０７を参照して、依頼人名及び取引種別に基づいて、連携先システムを特定してもよい。

図１４に、図７に示す情報処理装置１０の機能ブロックとは一部異なる情報処理装置１０Ａについて示す。データ取得部１１１が依頼人名及び取引種別を取得した後、システム特定部１１２は、コード変換テーブル１０７を参照して、依頼人名及び取引種別に基づいて、連携先システムを特定する。システム特定部１１２が連携先システムを特定した後、コード変換部１１３は、顧客情報テーブル１０６を参照して、依頼人名を顧客識別番号に変換してもよい。その後、コード変換部１１３は、コード変換テーブル１０７を参照して、連携先システムに対応するコードに変換してもよい。

（２）図７及び図１４において、コード変換部１１３及びコード生成部１１４とで機能ブロックを分けて、それぞれの機能ブロックで実行する処理について説明したが、これに限定されない。例えば、変換部を一つの機能ブロックとして、コード変換部１１３及びコード生成部１１４の双方の処理を実行してもよい。この場合、コード変換部１１３及びコード生成部１１４の処理を実行する順序は限定されず、コード生成部１１４の処理を実行した後、コード変換部１１３の処理を実行してもよい。

１：情報処理システム、１０：情報処理装置、２０：クライアント、３０：プロバイダ、３１：業務データ格納部、４０：ネットワーク、１０１：制御部、１０２：表示部、１０３：操作部、１０４：通信部、１０５：記録媒体、１０６：顧客情報テーブル、１０７：コード変換テーブル、１０８：プログラム、１１０：アプリケーション、１１１：データ取得部、１１２：システム特定部、１１３：コード変換部、１１４：コード生成部、１１５：コード送信部、１２１：処理結果取得部、１２２：判定部、１２３：選択部、２０１：制御部、２０２：表示部、２０３：操作部、２０４：通信部、３１０：勘定系システム、３１１：預金業務、３１２：融資業務、３１３：為替業務、３１４：日計業務、３１５：自振業務、３１６：顧客管理、３２０：国際系システム、３３０：情報系システム、３４０：チャネル系システム、５０１：依頼人名、５０２：支店名、５０３：口座番号、５０４：金額、５０５：取引種別、５０６：取引種別、５０７：取引種別、５０８：取引日、５０９：取引金額、５１１：送金先、５１２：取引の成否、５１３：取引後残高、５１４：処理通番

Claims (13)

1. クライアントから取得した第１データに基づいてシステムを特定し、前記システムで処理の実行が可能な第２データに変換し、前記第２データを前記システムに送信し、前記システムから取得した処理結果から前記処理の成否を判定し、前記処理が成立した場合は、前記処理結果から第３データを選択し、前記第３データを出力する、情報処理方法。
2. 前記第１データは、依頼人名及び取引種別であって、
   前記依頼人名を顧客識別番号に変換し、
   前記顧客識別番号及び前記取引種別に基づいて、前記システムを特定する、請求項１に記載の情報処理方法。
3. 前記第１データは、依頼人名及び取引種別であって、
   前記依頼人名及び前記取引種別に基づいて、前記システムを特定する、請求項１に記載の情報処理方法。
4. 前記第２データに変換することは、
   特定された前記システムに基づいて、当該システムに対応するコードに変換することを含む、請求項１乃至３のいずれか一項に記載の情報処理方法。
5. 前記処理結果は、リターンコードを含み、
   前記リターンコードに基づいて、前記処理の成否を判定する、請求項１乃至４のいずれか一に記載の情報処理方法。
6. 前記処理が不成立と判定する場合、不成立の結果を前記クライアントに出力する、請求項１乃至５のいずれか一に記載の情報処理方法。
7. 請求項１乃至６のいずれか一に記載の情報処理方法を、
   コンピュータに実行させるためのプログラム。
8. クライアントから取得した第１データを処理するシステムを特定するシステム特定部と、
   前記第１データを前記システムで処理するための第２データに変換する変換部と、
   前記システムで前記第２データを処理した処理結果を取得する処理結果取得部と、
   前記処理結果から前記処理の成否を判定する判定部と、を有する、情報処理装置。
9. 前記第１データは、依頼人名及び取引種別であって、
   前記システム特定部は、前記依頼人名と顧客識別番号とが対応付けられた第１テーブルを参照して、前記依頼人名を顧客識別番号に変換し、
   前記顧客識別番号と前記取引種別とが対応付けられた第２テーブルを参照して、前記システムを特定する、請求項８に記載の情報処理装置。
10. 前記第１データは、依頼人名及び取引種別であって、
    前記システム特定部は、前記依頼人名と前記取引種別とが対応付けられた第３テーブルを参照して、前記システムを特定する、請求項８に記載の情報処理装置。
11. 前記変換部は、前記システムと前記システムに対応するコードとが対応づけられた第４テーブルを参照して、前記システムを前記コードに変換する、コード変換部を有する、請求項８乃至１０のいずれか一に記載の情報処理装置。
12. 前記判定部は、前記処理結果に含まれるリターンコードに基づいて、前記処理の成否を判定する、請求項８乃至１１のいずれか一に記載の情報処理装置。
13. 前記判定部が、前記処理が不成立と判定する場合、不成立の結果を前記クライアントに出力する、請求項８乃至１２のいずれか一に記載の情報処理装置。
    

Images