特開 2022-72664 情報処理装置、情報処理方法及び情報処理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022072664

(43)【公開日】2022-05-17

(54)【発明の名称】情報処理装置、情報処理方法及び情報処理プログラム

(51)【国際特許分類】

   G06Q 40/02 20120101AFI20220510BHJP

   G06F 8/20 20180101ALI20220510BHJP

【ＦＩ】

G06Q40/02

G06F8/20

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2020182228

(22)【出願日】2020-10-30

【新規性喪失の例外の表示】特許法第３０条第２項適用申請有り タブレットソリューションを提供：富士通 ｈｔｔｐｓ：／／ｐｒ．ｆｕｊｉｔｓｕ．ｃｏｍ／ｊｐ／ｎｅｗｓ／２０２０／１０／１４．ｈｔｍｌ タブレットソリューションを提供：ＢＣＳＯＬ ｈｔｔｐ：／／ｗｗｗ．ｂｃｓｏｌ．ｃｏ．ｊｐ／ｉｍｇ／ｎｅｗｓ／［和文］みずほ銀行様プレスリリース案（店頭タブレット）．ｐｄｆ

(71)【出願人】

【識別番号】508287965

【氏名又は名称】バンキングチャネルソリューションズ株式会社

(71)【出願人】

【識別番号】592052416

【氏名又は名称】株式会社 みずほ銀行

(71)【出願人】

【識別番号】592131906

【氏名又は名称】みずほリサーチ＆テクノロジーズ株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】田中 直幸

(72)【発明者】

【氏名】遠山 茂

(72)【発明者】

【氏名】岩楯 奈那

【テーマコード（参考）】

5B376

5L055

【Ｆターム（参考）】

5B376BB11

5B376BC02

5B376FA17

5L055BB03

(57)【要約】

【課題】勘定系システムの利便性を向上させること。
【解決手段】本願に係る情報処理装置は、定義情報生成部と、取得部と、出力部とを有する。定義情報生成部は、勘定系システムで使用される複数の取引画面それぞれの画面定義に関する画面定義情報を用いて、外部に提供する勘定系システムの機能に関する機能定義情報を生成する。取得部は、機能定義情報に基づいて生成された入力画面を介して、入力情報を取得する。出力部は、機能定義情報に従って、入力情報を、勘定系システムで処理可能な形式のデータに変換し、変換したデータを勘定系システムに出力する。
【選択図】図２

【特許請求の範囲】

【請求項1】

勘定系システムで使用される複数の取引画面それぞれの画面定義に関する画面定義情報を用いて、外部に提供する前記勘定系システムの機能に関する機能定義情報を生成する定義情報生成部と、
前記機能定義情報に基づいて生成された入力画面を介して、入力情報を取得する取得部と、
前記機能定義情報に従って、前記入力情報を、前記勘定系システムで処理可能な形式のデータに変換し、変換した前記データを前記勘定系システムに出力する出力部と
を備えることを特徴とする情報処理装置。

【請求項2】

前記定義情報生成部は、前記画面定義情報を用いて、前記外部に提供する機能に対応する取引画面において当該機能の実行に必要な情報の入力を受け付ける入力項目に基づくアプリケーションインタフェースの定義情報を含む前記機能定義情報を生成する
ことを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記定義情報生成部は、前記画面定義情報を用いて、前記アプリケーションインタフェースの振る舞いを定義した定義情報であって前記機能の実行時に要求される入力画面の遷移を定義するマッシュ定義情報を含む前記機能定義情報を生成する
ことを特徴とする請求項２に記載の情報処理装置。

【請求項4】

前記アプリケーションインタフェースの定義情報に基づいて、前記外部に提供された機能を利用する利用元が前記アプリケーションインタフェースの利用時に参照する接続条件の仕様書を生成する仕様情報生成部をさらに備える
ことを特徴とする請求項２に記載の情報処理装置。

【請求項5】

前記出力部は、前記定義情報生成部によって生成された機能定義情報に基づいて、前記入力画面を介して取得されて前記勘定系システムで処理可能な形式に変換された前記データが、前記外部に提供される機能の実行に必要な条件を満たすか否かを判定し、前記条件を満たす場合に、前記データを前記勘定系システムに出力する
ことを特徴とする請求項１～４のうちいずれか１つに記載の情報処理装置。

【請求項6】

前記出力部は、前記データの応答として、前記勘定系システムから前記勘定系システムで処理可能な形式の応答データを受信し、前記機能定義情報に従って、前記応答データを前記入力情報に対応する形式の応答情報に変換し、前記応答情報を送信する
ことを特徴とする請求項１～５のうちいずれか１つに記載の情報処理装置。

【請求項7】

前記定義情報生成部は、前記外部に提供する複数の機能それぞれで利用される各取引画面の各画面定義情報を用いて、複数のアプリケーションインタフェースそれぞれに関する定義情報を含む前記アプリケーションインタフェースの定義情報と、前記マッシュ定義情報とを含む前記機能定義情報を生成し、
前記取得部は、前記複数のアプリケーションインタフェースのいずれかのアプリケーションインタフェースを用いた前記入力画面を介して、前記入力情報を取得し、
前記出力部は、前記機能定義情報に従って、前記入力情報を、前記勘定系システムで処理可能な送信電文データに変換し、変換した前記送信電文データを、前記勘定系システムに出力し、前記送信電文データに対する応答電文データに、前記機能定義情報を適用することによって新たな送信電文データを、前記勘定系システムに出力する
ことを特徴とする請求項３に記載の情報処理装置。

【請求項8】

コンピュータが、
勘定系システムで使用される複数の取引画面それぞれの画面定義に関する画面定義情報を用いて、外部に提供する前記勘定系システムの機能に関する機能定義情報を生成し、
前記機能定義情報に基づいて生成された入力画面を介して、入力情報を取得し、
前記機能定義情報に従って、前記入力情報を、前記勘定系システムで処理可能な形式のデータに変換し、変換した前記データを前記勘定系システムに出力する、
処理を含むことを特徴とする情報処理方法。

【請求項9】

コンピュータに、
勘定系システムで使用される複数の取引画面それぞれの画面定義に関する画面定義情報を用いて、外部に提供する前記勘定系システムの機能に関する機能定義情報を生成し、
前記機能定義情報に基づいて生成された入力画面を介して、入力情報を取得し、
前記機能定義情報に従って、前記入力情報を、前記勘定系システムで処理可能な形式のデータに変換し、変換した前記データを前記勘定系システムに出力する、
処理を実行させることを特徴とする情報処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

銀行の利用者は、口座開設、住所変更、ローン申請等の各種手続きを行うために、窓口の営業時間内に、銀行に行かなければならない場合がある。このような不便さを解消するために、スマートフォンのアプリケーションやＰＣ（Personal Computer）のブラウザを使用して、各種手続きを行う技術が望まれている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１８－０５５６２５号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、銀行業務を実行する勘定系システムは、信頼性が高いシステムであるとともに、例えば３０００画面等の大量の取引画面を使用した複雑な情報処理を行う。セキュリティの観点からは、一般の利用者が、勘定系システムの外部から勘定系システムを直接操作することを可能にすることは、リスクが大き過ぎる。また、勘定系システムの仕様書そのものを、オンラインサービスの開発者に提供することも、リスクが大きい。ゆえに一般の利用者に提供する機能範囲に限定して、利用しやすい形で提供することが求められている。

【0005】

本願は、上記に鑑みてなされたものであって、勘定系システムの利便性を向上させることを目的とする。

【課題を解決するための手段】

【0006】

本開示の実施形態に係る情報処理装置は、勘定系システムで使用される複数の取引画面それぞれの画面定義に関する画面定義情報を用いて、外部に提供する前記勘定系システムの機能に関する機能定義情報を生成する定義情報生成部と、前記機能定義情報に基づいて生成された入力画面を介して、入力情報を取得する取得部と、前記機能定義情報に従って、前記入力情報を、前記勘定系システムで処理可能な形式のデータに変換し、変換した前記データを前記勘定系システムに出力する出力部とを備える。

【発明の効果】

【0007】

実施形態の一態様によれば、勘定系システムの利便性を向上させることができる。

【図面の簡単な説明】

【0008】

【図1A】図１Ａは、本開示の例示的な実施形態に係る、勘定系システムの機能を提供する機能提供処理の一例を示す説明図である。

【図1B】図１Ｂは、本開示の例示的な実施形態に係る、勘定系システムの機能を提供する機能提供処理の一例を示す説明図である。

【図2】図２は、実施形態に係るサービス連携システムの一例を示す図である。

【図3】図３は、実施形態に係る画面定義情報記憶部の一例を示す図である。

【図4】図４は、実施形態に係るマッシュアップ情報記憶部の一例を示す図である。

【図5】図５は、ＡＰＩ定義を生成するＡＰＩ定義生成処理の一例を示す説明図である。

【図6】図６は、リクエストＪＳＯＮを受信するリクエストＪＳＯＮ受信処理の一例を示す説明図である。

【図7】図７は、リクエストＪＳＯＮを送信電文データに変換するリクエストＪＳＯＮ変換処理の一例を示す説明図である。

【図8】図８は、実施形態に係る情報処理装置によって実行される、勘定系システムの機能を提供するための処理の一例を示すフローチャートである。

【図9】図９は、実施形態に係る情報処理装置によって実行される、リクエストＪＳＯＮに基づいて勘定系システムと電文データを送受信するための処理の一例を示すフローチャートである。

【図10】図１０は、実施形態に係る情報処理装置によって実行される、勘定系システムから受信された電文データをレスポンスＪＳＯＮに変換するための処理の一例を示すフローチャートである。

【図11】図１１は、ハードウェア構成の一例を示す図である。

【発明を実施するための形態】

【0009】

以下、本開示の実施形態について、図面を参照しつつ詳細に説明する。なお、この実施形態により本発明が限定されるものではない。１つまたは複数の実施形態の詳細は、以下の説明および図面に記載される。また、複数の実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の１つまたは複数の実施形態において同一の部位には同一の符号を付し、重複する説明は省略する。

【0010】

〔１．例示的な実施形態〕
まず、図１Ａ及び図１Ｂを参照して、本開示の例示的な実施形態について詳細に説明する。

【0011】

〔１－１．例示的な実施形態の概要〕
近年、歴史的な低金利により、銀行の利益事情は、冷え込んでいる。このため、様々な銀行が、既存の銀行のシステムを有効活用して利益を上げる方法を模索している。このような方法の１つとしては、勘定系システムで実行される各業務である各機能を外部に提供することが挙げられる。例えば、既存の勘定系システムで用意されている口座開設、住所変更、ローン申請などの機能をフィンテック企業などに代表される外部事業者に提供することが提案されている。

【0012】

勘定系システムの機能を外部事業者に公開するにあたり、勘定系システムのインタフェースが問題となる。例えば、勘定系システムは、レガシーな形式の独自のユーザインタフェースを採用している場合がある。このような独自のユーザインタフェースは、例えばバイナリ形式の電文などである独自のフォーマットの電文を送受信するものである。そこで、様々な銀行が、勘定系システムの機能を、一般的なインタフェースであるアプリケーションプログラミングインタフェース（Application Programming Interface、ＡＰＩ）によって提供することを目指している。

【0013】

しかしながら、勘定系システムは、口座開設、住所変更、ローン申請に限らず、各種預金、与信取引、為替取引、信託、公共債、ローン等の非常に多くの機能を保有している。一般的に、このような多くの業務を機能化するために人手でＡＰＩ化するには、高い人月コストも時間もかかる。

【0014】

また、勘定系システムは、上述したような機能の動作をチェックするチェック機能も実装している。したがって、このチェック機能を再実装するのにも時間がかかる。

【0015】

そこで、例示的な実施形態に係る情報処理装置は、勘定系システムが提供する各機能のＡＰＩ化を効率的に実現するために、以下に説明される処理を実行する。

【0016】

具体的には、情報処理装置は、外部の他のプログラムから呼び出して利用するための手順やデータ形式などを定めた規約の一例であるＡＰＩを外部にサービスとして提供することで、稼働中である勘定系システムの機能の提供を実現する。図１Ａ及び図１Ｂに示す例示的な実施形態では、勘定系システム２００の機能を提供するＡＰＩを自動的に構築するために、情報処理装置は、稼働中の勘定系システム２００の取引画面をＡＰＩ化する。例えば、情報処理装置は、口座開設の画面、住所変更の画面、ローン申請の画面等の取引画面から、口座開設ＡＰＩ、住所変更ＡＰＩ、ローン申請ＡＰＩ等のウェブＡＰＩをそれぞれ生成する。

【0017】

情報処理装置は、銀行業務で取り扱われる大量の取引画面（例えば、３０００画面）を自動的にＡＰＩ化することによって、外部事業者向けのサービス連携（機能連携）を提供することができる。さらに、情報処理装置は、取引画面から生成されたＡＰＩ（例えば、口座開設ＡＰＩ、住所変更ＡＰＩ、ローン申請ＡＰＩ）を使用して、銀行業務の項目（例えば、型、桁数、必須項目／任意項目）のチェックを行うことができる。

【0018】

上述のＡＰＩの自動生成に加えて、情報処理装置は、このＡＰＩを使用したマッシュアップにより既存の機能を組み合わせた金融サービスと同じサービスを提供することもできる。例えば、情報処理装置は、氏名変更ＡＰＩと、カード再発行ＡＰＩとを組み合わせることによって、氏名を変更するとともに、氏名が変更されたカードを再発行する金融サービスを提供することができる。これにより、情報処理装置は、銀行の手続きの利便性を高めることができる。

【0019】

〔１－２．機能提供処理〕
以下では、図１Ａおよび図１Ｂを参照して、上述した例示的な実施形態に係る機能提供処理について説明する。

【0020】

図１Ａおよび図１Ｂは、本開示の例示的な実施形態に係る、勘定系システム２００の機能を提供する機能提供処理の一例を示す説明図である。例示的な実施形態では、機能提供処理が、図１Ａ及び図１Ｂに示された情報処理装置１００によって行われる。図１に示されていないが、インターネット等のネットワークＮによって、図１Ａおよび図１Ｂに示された情報処理装置１００、勘定系システム２００、事業者装置３００およびユーザ装置４００が接続される。

【0021】

情報処理装置１００は、外部事業者向けのサービス連携を提供する企業によって管理されるサーバ装置の一例である。外部事業者向けのサービス連携は、外部事業者の各種コンテンツが勘定系システム２００の機能と連携することを可能にする。一例として、外部事業者が自動車ディーラである場合に、コンテンツは、ローンの申請や残高照会に関するコンテンツである。この例では、自動車の購入者は、自動車ディーラがＡＰＩの仕様に沿って開発した、例えばウェブサイトのコンテンツを使用して、自動車ローンを申請することができる。

【0022】

勘定系システムは、銀行や銀行が有するデータセンタ等に設置されたメインフレームやサーバによって実装される。この例では、勘定系システム２００は、銀行によって管理される。勘定系システム２００は、銀行の窓口での顧客の届け出（例えば、出金、住所変更）等の各種情報を受け付けて記録する。また、勘定系システム２００は、顧客のお金や顧客情報を管理する。

【0023】

事業者装置３００は、外部事業者によって管理されるサーバ装置の一例である。上述のように、外部事業者は、公開されたＡＰＩの仕様に沿って、例えば、自動車ローンの申請などの各種金融サービスを開発し、事業者装置３００を用いてユーザに提供する。

【0024】

ユーザ装置４００は、スマートフォンとして示されている。この例では、ユーザ装置４００は、外部事業者がＡＰＩの仕様に沿って開発した各種コンテンツを利用するユーザによって管理される。

【0025】

図１Ａに示されるように、はじめに、情報処理装置１００は、銀行業務で取り扱われる取引画面を定義した画面定義情報を、勘定系システム２００から取得する（ステップＳ１）。図１Ａの例では、情報処理装置１００は、取引画面のセット１０に対応する画面定義情報のセット２０を取得する。例えば、取引画面のセット１０は、大量の取引画面を含む。各取引画面は、各画面定義情報にそれぞれ対応する。画面定義情報は、例えばＪＡＶＡ（登録商標）やＣＯＢＯＬ等の開発言語で記述された取引画面の入力項目等を定義する定義情報である。

【0026】

上述の取引画面は、行員の端末に表示されて、銀行の行員によるデータ入力に使用される。例えば、取引画面のセット１０は、口座開設用の取引画面、住所変更用の取引画面、ローン申請用の取引画面を含む。行員は、このような取引画面を使用して銀行業務を行っている。

【0027】

次いで、情報処理装置１００は、取得された画面定義情報からＡＰＩ定義およびマッシュアップＡＰＩを生成する（ステップＳ２）。例えば、情報処理装置１００は、画面定義情報のセット２０から、ＡＰＩ定義のセット３０を生成する。ＡＰＩ定義は、画面定義情報から生成されたＡＰＩ用の項目定義であり、例えばJavaScript（登録商標）などの各種スクリプト言語で記述される。ＡＰＩ定義のセット３０は、画面定義情報のセット２０に含まれる画面定義情報の入力項目に関する項目情報を定義するものである。

【0028】

加えて、情報処理装置１００は、画面定義情報のセット２０から、マッシュアップＡＰＩ４０を生成する。マッシュアップＡＰＩ４０は、ＡＰＩが組み合わされて使用される際の動作を決定する定義であり、ＡＰＩ定義のセット３０の振る舞いを定義するものである。画面定義情報の一例は、図３を参照して以下で詳述される。また、マッシュアップＡＰＩの一例は、図４を参照して以下で詳述される。

【0029】

次いで、情報処理装置１００は、生成されたＡＰＩ定義およびマッシュアップＡＰＩから、ＡＰＩ接続条件仕様書を生成する（ステップＳ３）。ＡＰＩ接続条件仕様書は、ＡＰＩ定義を利用する外部事業者によって参照される接続条件を記載した仕様書である。仕様書は、マッシュアップＡＰＩの動作の定義として、例えば、どのようにＡＰＩ定義が他のＡＰＩ定義と連携するかを含んでもよい。例えば、外部事業者は、ＡＰＩ接続条件仕様書に記載されたＡＰＩ接続条件に沿って、ＪＳＯＮ（JavaScript Object Notation）インタフェースを実装した各種アプリケーションを開発することができる。このように、情報処理装置１００は、外部事業者がＪＳＯＮインタフェースを使用して各種アプリケーションを開発することができるように、ＡＰＩ定義を、自動的にドキュメント化することができる。ＡＰＩ接続条件仕様書を生成する処理の一例は、図５を参照して以下で詳述される。

【0030】

次いで、情報処理装置１００は、生成されたＡＰＩ接続条件仕様書を、事業者装置３００に提供する（ステップＳ４）。事業者装置３００に関係する外部事業者は、ＡＰＩ接続条件仕様書を使用して、勘定系システム２００の機能が利用可能な金融サービスを開発する。例えば、事業者は、ＪＳＯＮインタフェースを使用して、金融サービスに関するアプリケーションを開発する。そして、事業者装置３００は、勘定系システム２００が提供する金融サービスを、ユーザ装置４００に提供する（ステップＳ５）。

【0031】

図１Ｂを参照すると、図１ＡのステップＳ５の後に、ユーザ装置４００は、勘定系システム２００の機能の実行を、事業者装置３００に要求する（ステップＳ６）。そして、情報処理装置１００は、勘定系システム２００の機能の実行に関するリクエストＪＳＯＮを、事業者装置３００から受信する（ステップＳ７）。リクエストＪＳＯＮを受信する処理の一例は、図６を参照して以下で詳述される。

【0032】

次いで、情報処理装置１００は、受信されたリクエストＪＳＯＮを送信電文データに変換する（ステップＳ８）。図１Ｂの例では、情報処理装置１００は、ＡＰＩ定義のセット３０と、マッシュアップＡＰＩ４０に従って、受信されたリクエストＪＳＯＮ５０を、送信電文データ６０にマッピングする。送信電文データ６０は、レガシーな形式のデータの一例であるバイナリデータである。リクエストＪＳＯＮを送信電文データにマッピングする処理の一例は、図７および図９を参照して以下で詳述される。

【0033】

次いで、情報処理装置１００は、ＡＰＩ定義を参照することによって、送信電文データの項目をチェックする（ステップＳ９）。例えば、情報処理装置１００は、ＡＰＩ定義のセット３０を読み込み、送信電文データ６０の型や桁数が適切かを判定し、必須項目が欠けていないかを判定する。

【0034】

次いで、情報処理装置１００は、送信電文データ６０を、勘定系システム２００に送信する（ステップＳ１０）。そして、情報処理装置１００は、勘定系システム２００の機能の実行結果に関する受信電文データを、勘定系システム２００から受信する（ステップＳ１１）。

【0035】

次いで、情報処理装置１００は、受信された受信電文データを、レスポンスＪＳＯＮに変換する（ステップＳ１２）。図１Ｂの例では、情報処理装置１００は、ＡＰＩ定義のセット３０に従って、受信電文データ７０を、レスポンスＪＳＯＮ８０にマッピングする。受信電文データをレスポンスＪＳＯＮにマッピングする処理の一例は、図１０を参照して以下で詳述される。

【0036】

その後、情報処理装置１００は、レスポンスＪＳＯＮ８０を、事業者装置３００に送信する（ステップＳ１３）。そして、事業者装置３００は、勘定系システム２００の機能の実行結果を、ユーザ装置４００に提供する（ステップＳ１４）。

【0037】

上述のように、情報処理装置１００は、既存の勘定系システム２００において業務に使用されている大量の取引画面から、各取引画面の機能に対応するＡＰＩ定義を生成する。ユーザが、勘定系システム２００の機能を要求した場合に、情報処理装置１００は、生成されたＡＰＩ定義を参照することによって、リクエストＪＳＯＮを、勘定系システム２００において使用されるバイナリデータに変換し、このデータを勘定系システム２００に送信する。

【0038】

これにより、情報処理装置１００は、外部事業者向けのサービス連携を実現することができる。さらに、情報処理装置１００は、生成されたＡＰＩ定義のセット３０やマッシュアップＡＰＩ４０を使用することによって、ユーザが、勘定系システム２００の機能を組み合わせて使用することを可能にする。

【0039】

以下、このような勘定系システム機能提供処理を行う情報処理装置１００について詳細に説明する。

【0040】

〔２．サービス連携システム〕
次に、図２を参照して、上記図１Ａおよび図１Ｂで説明した処理を実現する、情報処理装置１００を含むシステムの機能構成例について説明する。

【0041】

〔２－１．サービス連携システムの構成〕
図２は、実施形態に係るサービス連携システム１の一例を示す図である。図２に示されるように、サービス連携システム１は、情報処理装置１００、勘定系システム２００、事業者装置３００およびユーザ装置４００等の構成要素を含む。図２中では図示していないが、サービス連携システム１は、複数台の情報処理装置１００や、複数台の事業者装置３００や、複数台のユーザ装置４００を含んでもよい。また、サービス連携システム１は、情報処理装置１００に関係する事業者、エンドユーザの装置等の、他の構成要素を含んでもよい。

【0042】

情報処理装置１００、勘定系システム２００、事業者装置３００およびユーザ装置４００は、それぞれネットワークＮと有線又は無線により接続される。ネットワークＮは、例えば、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）等のネットワークである。サービス連携システム１の構成要素は、ネットワークＮを介して互いに通信を行うことができる。

【0043】

情報処理装置１００は、勘定系システム２００の機能を提供するための処理を実行する情報処理装置である。情報処理装置１００は、勘定系システム２００の機能を利用するためのインタフェース（すなわち、窓口）を、勘定系システム２００の取引画面から生成することができる。例えば、情報処理装置１００は、事業者装置３００の金融サービスに勘定系システム２００の機能を提供するＡＰＩや、このＡＰＩの仕様書を生成することができる。また、情報処理装置１００は、ＡＰＩの仕様書を外部事業者に公開することができる。情報処理装置１００は、サーバを含む、任意のタイプの情報処理装置であってもよい。複数台の情報処理装置１００が、ウェブサーバ、アプリケーションサーバ、データベースサーバ等の各種サーバの機能をそれぞれ提供してもよい。情報処理装置１００の構成例は、次の節で詳述される。

【0044】

勘定系システム２００は、預金、融資、振り込み等の銀行業務をつかさどる情報システムである。勘定系システム２００は、業務アプリケーション、ＣＩＦ（Customer Information File）、制御アプリケーション等の要素を含む。勘定系システム２００は、サーバやストレージ等のハードウェアを含む、任意のタイプの情報システムであってもよい。

【0045】

事業者装置３００は、勘定系システム２００の機能を利用するためのインタフェースを通して、金融サービスを提供する情報処理装置である。事業者は、情報処理装置１００によって生成されたＡＰＩの仕様書に基づいて、勘定系システム２００のＡＰＩを呼び出す金融サービス（例えば、ウェブサイト、スマートフォンのアプリケーション）を開発することができる。事業者装置３００は、サーバを含む、任意のタイプの情報処理装置であってもよい。

【0046】

ユーザ装置４００は、ユーザによって利用される情報処理装置である。ユーザ装置４００は、事業者装置３００によって提供される金融サービスへのアクセスを要求することができる。ユーザ装置４００は、スマートフォン、デスクトップ型ＰＣ、ノート型ＰＣ、タブレット型ＰＣ等のクライアント装置を含む、任意のタイプの情報処理装置であってもよい。

【0047】

〔２－２．情報処理装置の構成〕
次に、図２に示した各装置のうち、図１Ａおよび図１Ｂで説明した機能を実行する情報処理装置１００について詳細に説明する。図２に示されるように、情報処理装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、情報処理装置１００は、情報処理装置１００を利用する管理者等から各種操作を受け付けるキーボードやマウスなどの入力部や、各種情報を表示するためのディスプレイなどの表示部を有してもよい。

【0048】

（通信部１１０）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。通信部１１０は、有線または無線によりネットワーク網と接続される。通信部１１０は、勘定系システム２００、事業者装置３００およびユーザ装置４００に、ネットワークＮを介して、通信可能に接続される。通信部１１０は、勘定系システム２００、事業者装置３００およびユーザ装置４００との間で、ネットワーク網を介して、情報の送受信を行うことができる。

【0049】

（記憶部１２０）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図２に示されるように、記憶部１２０は、画面定義情報記憶部１２１と、マッシュアップ情報記憶部１２２と、ＡＰＩ定義記憶部１２３と、ＡＰＩ接続条件仕様書記憶部１２４とを有する。

【0050】

（画面定義情報記憶部１２１）
画面定義情報記憶部１２１は、勘定系システム２００の各業務の実行時に利用される取引画面ごとに、各取引画面において入力を受け付ける項目、項目の定義、値などに関する画面定義情報を記憶する。一例では、画面定義情報は、テキストデータであってもよく、リレーショナルデータベースのテーブルによって定義されてもよい。例えば、３０００個の取引画面が存在する場合、３０００個の画面定義情報が生成される。

【0051】

図３は、実施形態に係る画面定義情報記憶部１２１の一例を示す図である。図３の例では、画面定義情報記憶部１２１に記憶された画面定義情報は、「項目名称」、「項目論理名称」、「型」、「桁数」、「必須チェック対象項目」、「システム論理項目名」等の項目を有する。

【0052】

「項目名称」は、項目の名称を示す。「項目論理名称」は、プログラムが理解する論理名称を示す。「型」は、項目の型を示し、「桁数」は、項目の桁数を示す。「必須チェック対象項目」は、項目が必須チェック対象であるかを示す。「システム論理項目名」は、勘定系システム２００において項目を識別するための文字列を示す。

【0053】

例えば、図３の１行目を説明すると、項目名称「ＣＩＦ番号」の項目の項目論理名称が「cifno」であり、項目名称「ＣＩＦ番号」の項目の型が「数値」であり、項目名称「ＣＩＦ番号」の項目の桁数が「１０」であり、項目名称「ＣＩＦ番号」の項目が必須チェック対象項目ではなく、項目名称「ＣＩＦ番号」の項目のシステム論理項目名が「F0001」であることを示している。

【0054】

（マッシュアップ情報記憶部１２２）
マッシュアップ情報記憶部１２２は、マッシュアップＡＰＩの生成に使用されるマッシュアップ情報を記憶する。マッシュアップ情報は、テキストデータやリレーショナルデータベースのテーブルによって定義されてもよい。

【0055】

図４は、実施形態に係るマッシュアップ情報記憶部１２２の一例を示す図である。図４の例では、マッシュアップ情報記憶部１２２に記憶されたマッシュアップ情報は、「実行取引」、「実行条件」、「デフォルト値、設定定義」、「引継ぎデータ」、「コピーデータ」等のテーブルを有する。

【0056】

「実行取引」は、取引画面に対応する実行取引を示す。例えば、実行取引ＩＤ「00001」で識別される実行取引は、ＣＩＦ開設である。「実行条件」は、実行取引の実行条件を示す。例えば、登録番号がリクエストデータにある場合に、実行取引ＩＤ「00042」で識別される実行取引は、実行される。「デフォルト値、設定定義」は、実行取引のデフォルト値を示す。例えば、実行取引ＩＤ「00001」で識別される実行取引において、科目のデフォルト値は、「普通」である。「引継ぎデータ」は、実行取引の項目がマッシュアップによってどのように他の実行取引に引き継がれるかを示す。例えば、実行取引ＩＤ「00010」で識別される実行取引の「店番号」は、実行取引ＩＤ「00031」で識別される実行取引に引き継がれる。「コピーデータ」は、実行取引の項目がマッシュアップによってどのように他の実行取引にコピーされるかを示す。例えば、実行取引ＩＤ「00001」で識別される実行取引の項目「主な取引の目的」は、実行取引ＩＤ「00031」で識別される実行取引に、項目「取引の目的」としてコピーされる。

【0057】

（ＡＰＩ定義記憶部１２３）
ＡＰＩ定義記憶部１２３は、ＡＰＩ定義のセット３０と、マッシュアップＡＰＩ４０とを記憶する。ＡＰＩ定義のセット３０に含まれるＡＰＩ定義は、外部に提供する機能に対応する取引画面において、当該機能の実行に必要な情報の入力を受け付ける入力項目に関する項目情報に基づくＡＰＩの定義情報である。具体的には、ＡＰＩ定義は、事業者装置３００が、情報処理装置１００が提供する勘定系システム２００の機能を利用するための方式や取り決めを定義する。例を挙げると、ＡＰＩ定義は、画面定義情報の各項目について、リクエストとして送信するパラメータや指定できる値などの定義情報である。

【0058】

また、マッシュアップＡＰＩ４０は、アプリケーションインタフェースの振る舞いを定義した定義情報であって、公開される機能の実行時に要求される入力画面の遷移を定義するマッシュアップの定義情報である。例えば、マッシュアップＡＰＩ４０には、各実行取引に対応する実行取引が実行される順番や機能の組み合わせなどが定義される。例を挙げると、マッシュアップＡＰＩ４０は、口座開設を行う場合に、取引画面Ａ、取引画面Ｂ、取引画面Ｃが実行されることを定義する。

【0059】

（ＡＰＩ接続条件仕様書記憶部１２４）
ＡＰＩ接続条件仕様書記憶部１２４は、外部に提供された機能を利用する利用元（事業者装置３００）がＡＰＩの利用時に参照する接続条件の仕様書である接続条件仕様書を記憶する。すなわち、この接続条件仕様書には、取引画面ごとに、各取引画面に対応したＡＰＩを使用するための各ＵＲＬ（Uniform Resource Locator）などが定義され、さらには、利用するときの条件（ドメイン指定）などを含むこともできる。

【0060】

（制御部１３０）
制御部１３０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等のプロセッサによって、情報処理装置１００内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等を作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＧＰＧＰＵ（General Purpose Graphic Processing Unit）等の集積回路により実現されてもよい。

【0061】

制御部１３０は、図２に示されるように、収集部１３１と、定義情報生成部１３２と、仕様情報生成部１３３と、提供部１３４と、取得部１３５と、出力部１３６とを有し、以下に説明する情報処理の機能や作用を実現又は実行する。また、制御部１３０は、図１Ａおよび図１Ｂを参照して上述した勘定系システム２００の機能提供処理を実現することができる。情報処理装置１００の１つまたは複数のプロセッサは、情報処理装置１００の１つまたは複数のメモリに記憶された命令を実行することによって、制御部１３０内の各制御部の機能を実現することができる。なお、制御部１３０の内部構成は、図２に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。例えば、出力部１３６は、出力部１３６以外の部に関して後述する情報処理の全部または一部を行ってもよい。

【0062】

（収集部１３１）
収集部１３１は、勘定系システム２００の機能を提供するための処理に使用される各種情報を収集する。少なくとも１つの実施形態では、収集部１３１は、勘定系システム２００で使用される取引画面の画面定義に関する画面定義情報を収集する。収集部１３１は、各種画面の内容や機能を定義する画面定義情報を取得する。

【0063】

一例では、収集部１３１は、銀行業務で取り扱われる取引画面を定義した画面定義情報を、勘定系システム２００から取得する。図１Ａを参照して上述したように、収集部１３１は、例えば、取引画面のセット１０に対応する画面定義情報のセット２０を取得する。例えば、取引画面のセット１０は、大量の取引画面を含む。複数の取引画面は、複数の画面定義情報にそれぞれ対応する。

【0064】

そして、収集部１３１は、画面定義情報記憶部１２１に、取得した画面定義情報を格納する。なお、収集部１３１は、情報処理装置１００を利用する管理者から、ユーザインタフェースを介して、画面定義情報を受信することができる。

【0065】

また、収集部１３１は、情報処理装置１００を利用する管理者から、ユーザインタフェースを介して、マッシュアップ情報を受け付けてもよい。そして、収集部１３１は、受け付けられたマッシュアップ情報を、マッシュアップ情報記憶部１２２に格納する。

【0066】

（定義情報生成部１３２）
定義情報生成部１３２は、画面定義情報記憶部１２１に記憶される画面定義情報を用いて、ＡＰＩ定義とマッシュアップＡＰＩとを生成して、ＡＰＩ定義記憶部１２３に格納する。具体的には、定義情報生成部１３２は、事業者装置３００が取得して使用できるように、画面定義情報に定義される各項目に対して、ＡＰＩとして使用するときパラメータや指定できる値などを定義したＡＰＩ定義を生成する。例えば、図３の画面定義情報を例にして説明すると、定義情報生成部１３２は、「ＣＩＦ番号」に対して、パラメータとして「cifno」、値として「10桁の数値」を定義し、「店番号」に対して、パラメータとして「tenban」、値として「6桁の数値」を定義する。すなわち、外部の事業者装置３００が、「ＣＩＦ番号」の入力画面を生成するときに、「パラメータ＝cifno」、「値＝10桁の数値」を設定することで、勘定系システム２００との間で正常なデータ送受信が実現できる。

【0067】

同様に、具体的には、定義情報生成部１３２は、画面定義情報やマッシュアップ情報記憶部１２２に記憶されるマッシュアップ情報などを用いて、実行取引が実行される順番を定義したマッシュアップＡＰＩを生成する。例えば、定義情報生成部１３２は、マッシュアップ情報や管理者等が予め定義した情報を用いて、ある業務Ａ（機能Ａ）を実行するときに取引画面Ｘ、取引画面Ｙ、取引画面Ｚが必要になることを特定する。すると、定義情報生成部１３２は、取引画面ＸのＡＰＩが読み出された後に、取引画面ＹのＡＰＩと取引画面ＺのＡＰＩとが連続して呼び出されることを規定したマッシュアップＡＰＩを生成する。一例を挙げると、マッシュアップＡＰＩは、口座開設を行うユーザに対して、取引画面Ｘ、取引画面Ｙ、取引画面Ｚの順に入力項目の入力を要求することが定義される。なお、定義情報生成部１３２は、情報処理装置１００を利用する管理者から、ユーザインタフェースを介して、マッシュアップＡＰＩの一部を受け付けてもよい。

【0068】

上述したように、定義情報生成部１３２は、画面定義情報を用いて、勘定系システム２００の外部に公開される複数の機能を使用するために、ＡＰＩ定義とマッシュアップＡＰＩを生成する。

【0069】

（仕様情報生成部１３３）
仕様情報生成部１３３は、ＡＰＩ定義に基づいて、ＡＰＩ接続条件仕様書を生成する。具体的には、仕様情報生成部１３３は、外部に公開する機能を利用するために、ＡＰＩ定義で定義された各ＡＰＩを参照するＵＲＬなどを規定したＡＰＩ接続条件仕様書を生成する。例えば、仕様情報生成部１３３は、ＡＰＩ定義を参照して、公開する各機能と、各機能に対応する取引画面ごとに生成された各ＡＰＩの名称とを取得し、これらに各ＡＰＩを使用するための各ＵＲＬとを対応付けることで、ＡＰＩ接続条件仕様書を生成する。また、仕様情報生成部１３３は、ＡＰＩ接続条件仕様書に、ＡＰＩ定義にしたがった各項目のパラメータや指定値などを定義することもできる。

【0070】

したがって、外部の事業者装置３００は、口座開設を実行するときに、口座開設に対応するＡＰＩのＵＲＬを指定することで、当該ＡＰＩを利用したサービスを実現することができる。このとき、事業者装置３００は、ＡＰＩ定義にしたがって、パラメータや値などを指定する。なお、生成手法は、ＡＰＩドキュメンテーションなどのOpenAPI Generator等を用いることができる。

【0071】

（提供部１３４）
提供部１３４は、各種インタフェースに関する情報を提供する。例えば、提供部１３４は、仕様情報生成部１３３によって生成されたＡＰＩ接続条件仕様書を、事業者装置３００を含む外部に提供する。例えば、提供部１３４は、インターネット上でＡＰＩ接続条件仕様書を公開することで外部に提供することもでき、予め契約した事業者装置３００に対してのみＡＰＩ接続条件仕様書を公開することもできる。

【0072】

（取得部１３５）
取得部１３５は、各種入力情報を取得する。具体的には、取得部１３５は、ＡＰＩ接続条件仕様書に基づいて生成された入力画面を介して、入力情報を取得する。例えば、取得部１３５は、事業者装置３００が提供する入力画面において入力された情報を、ＪＳＯＮ形式に変換して取得する。そして、取得部１３５は、取得された入力情報を、ユーザからのリクエストを示すリクエストＪＳＯＮとしてサービス連携の処理対象とする。

【0073】

（出力部１３６）
出力部１３６は、ＡＰＩ定義とマッシュアップＡＰＩに従って、取得部１３５によって取得された入力情報を、勘定系システム２００で処理可能な形式のデータに変換し、変換したデータを勘定系システム２００に出力する。

【0074】

一例では、出力部１３６は、ＡＰＩ定義とマッシュアップＡＰＩに従って、取得部１３５によって受信されたリクエストＪＳＯＮを送信電文データに変換する。図１Ｂを参照して上述したように、出力部１３６は、ＡＰＩ定義のセット３０と、マッシュアップＡＰＩ４０に従って、リクエストＪＳＯＮ５０を、送信電文データ６０にマッピングする。そして、出力部１３６は、送信電文データ６０を勘定系システム２００に出力する。

【0075】

また、出力部１３６は、出力されたデータに対する応答として、勘定系システム２００から、勘定系システム２００で処理可能な形式のデータを受信し、受信されたデータを、ＡＰＩ定義とマッシュアップＡＰＩに従って、入力情報に対応する形式の応答情報に変換し、この応答情報を送信する。

【0076】

一例では、図１Ｂを参照して上述したように、出力部１３６は、送信電文データ６０を、勘定系システム２００に送信する。そして、出力部１３６は、勘定系システム２００の機能の実行結果に関する受信電文データを、勘定系システム２００から受信する。そして、出力部１３６は、受信された受信電文データを、レスポンスＪＳＯＮに変換する。図１Ｂを参照して上述したように、出力部１３６は、ＡＰＩ定義のセット３０に従って、受信電文データ７０を、レスポンスＪＳＯＮ８０にマッピングする。そして、出力部１３６は、レスポンスＪＳＯＮ８０をリクエスト元に送信する。

【0077】

また、出力部１３６は、定義情報生成部１３２によって生成されたＡＰＩ定義とマッシュアップＡＰＩに基づいて、勘定系システム２００で処理可能な形式である送信電文データ６０が、データ入力に関する所定の条件を満たすかを判定することもできる。

【0078】

一例では、出力部１３６は、ＡＰＩ定義を参照することによって、送信電文データ６０に含まれる各項目のうち必須チェック対象項目を特定する。そして、出力部１３６は、必須チェック対象項目に該当する各項目のデータの型や桁数が、ＡＰＩ定義によって指定されている適切な情報であるかや必須項目が欠けていないかを判定する。そして、出力部１３６は、適切な情報である場合に、送信電文データ６０を勘定系システム２００に出力する。

【0079】

（機能提供処理の一例）
上記では、例示的な実施形態に係る機能提供処理を、図１Ａおよび図１Ｂを参照して説明した。ここでは、機能提供処理を、図５、図６および図７を参照してより詳細に説明する。

【0080】

図５は、ＡＰＩ定義を生成するＡＰＩ定義生成処理の一例を示す説明図である。図５に示されるように、制御部１３０の定義情報生成部１３２は、画面定義情報のセット２０から、ＡＰＩ定義のセット３０を生成する。例えば、定義情報生成部１３２は、画面定義情報のセット２０にそれぞれ対応する複数のテーブルであるＡＰＩ定義のセット３０を生成する。例えば、定義情報生成部１３２は、画面定義情報のセット２０に含まれる画面定義情報から、項目名称、項目論理名称、型、桁数、必須チェック対象項目、システム論理項目名等の項目を抽出し、項目名称を識別するＩＤを生成する。そして、定義情報生成部１３２は、項目名称を識別するＩＤに、項目論理名称、型、桁数、必須チェック対象項目、システム論理項目名等の項目を関連付け、このＩＤに関連付けられた項目を有するテーブルを生成する。

【0081】

さらに、定義情報生成部１３２は、画面定義情報のセット２０から、マッシュアップ情報２５を生成する。そして、定義情報生成部１３２は、マッシュアップ情報２５から、マッシュアップＡＰＩ４０を生成する。定義情報生成部１３２は、ＡＰＩ定義のセット３０と、マッシュアップＡＰＩ４０とに基づいて、ＡＰＩ接続条件仕様書４５を生成する。

【0082】

より具体的には、定義情報生成部１３２は、マッシュアップ情報２５から、マッシュアップ情報２５に対応するデータベースの内容を定義したファイルであるマッシュアップＡＰＩ４０を生成する。ＡＰＩ定義のセット３０の場合と同様に、定義情報生成部１３２は、マッシュアップ情報２５から、図４を参照して上述した「実行取引」、「実行条件」、「デフォルト値、設定定義」、「引継ぎデータ」、「コピーデータ」等の複数のテーブルを有するマッシュアップＡＰＩ４０を生成する。例えば、マッシュアップＡＰＩ４０は、各実行取引が実行される順番を定義する。一例として、マッシュアップＡＰＩ４０は、実行取引ＩＤ「00001」によって識別される実行取引「ＣＩＦ開設」の後に、実行取引ＩＤ「00010」によって識別される実行取引「口座開設」が実行されることを定義する。

【0083】

定義情報生成部１３２が、ＡＰＩ定義のセット３０と、マッシュアップＡＰＩ４０を生成した後、仕様情報生成部１３３は、ＡＰＩ定義のセット３０と、マッシュアップＡＰＩ４０から、ＡＰＩ接続条件仕様書４５を生成する。例えば、仕様情報生成部１３３は、OpenAPI Generator等のＡＰＩドキュメンテーションの手法を用いて、ＡＰＩ定義のセット３０およびマッシュアップＡＰＩ４０から、ＡＰＩ接続条件仕様書４５を、自動的に生成する。

【0084】

図６は、リクエストＪＳＯＮを受信するリクエストＪＳＯＮ受信処理の一例を示す説明図である。図６に示されるように、制御部１３０の取得部１３５は、ＡＰＩ接続条件仕様書を使用して作成されたユーザインタフェースＵＩを介して、リクエストＪＳＯＮ５０ａを取得する。ユーザインタフェースＵＩは、例えば、事業者によって開発された金融サービスの画面である。このように、金融サービスの画面の入力項目は、リクエストＪＳＯＮ５０ａの項目にマッピングされる。

【0085】

図７は、リクエストＪＳＯＮを送信電文データに変換するリクエストＪＳＯＮ変換処理の一例を示す説明図である。図７に示されるように、制御部１３０の出力部１３６は、ＡＰＩ定義のセット３０と、マッシュアップＡＰＩ４０とに基づいて、リクエストＪＳＯＮ５０を、送信電文データ６０にマッピングする。リクエストＪＳＯＮ５０は、“cifno“：“1234567890“等の項目を含む。“cifno“は、項目論理名称であり、リクエストＪＳＯＮのキー値に対応する。一方、“1234567890“は、リクエストＪＳＯＮのバリュー値に対応する。

【0086】

出力部１３６は、ＡＰＩ定義のセット３０と、マッシュアップＡＰＩ４０とに基づいて、ＪＳＯＮインタフェースを、バイナリ形式の電文に変換する。例えば、出力部１３６は、リクエストＪＳＯＮに含まれる値である「値Ｖ１「1234567890」、値Ｖ２「123456」、値Ｖ３「01」」を、送信電文データ６０に含まれる値である「値Ｖ１「1234567890」、値Ｖ２「123456」、値Ｖ３「01」」にマッピングする。図７の例では、送信電文データ６０に含まれる「PT」は、区切り文字である。また、送信電文データ６０に含まれる「F0001」、「F0002」および「F0003」は、システム論理項目名である。このように、出力部１３６は、ＪＳＯＮインタフェースで使用される英字項目名に関連付けられたデータを、レガシーな形式の電文データにマッピングして、勘定系システム２００に出力する。

【0087】

〔３．機能提供処理のフロー〕
次に、図８、図９および図１０を参照して、実施形態に係る情報処理装置１００による機能提供処理の手順について説明する。

【0088】

図８は、実施形態に係る情報処理装置１００によって実行される、勘定系システム２００の機能を提供するための処理の一例を示すフローチャートである。

【0089】

図８に示されるように、はじめに、情報処理装置１００（例えば、定義情報生成部１３２）は、画面定義情報に基づいてＡＰＩ定義を生成する（ステップＳ１０１）。

【0090】

次いで、情報処理装置１００（例えば、仕様情報生成部１３３、提供部１３４）は、生成されたＡＰＩ定義等に基づいて、ＡＰＩ接続条件仕様書を生成して提供する（ステップＳ１０２）。例えば、情報処理装置１００は、生成されたＡＰＩ接続条件仕様書を、事業者装置３００に提供する。

【0091】

次いで、情報処理装置１００（例えば、取得部１３５）は、生成されたＡＰＩ接続条件仕様書を使用して開発されたアプリケーションを介して、リクエストＪＳＯＮを受信する（ステップＳ１０３）。例えば、情報処理装置１００は、ＪＳＯＮインタフェースを使用して開発されたアプリケーションを介して、リクエストＪＳＯＮを、事業者装置３００から受信する。

【0092】

次いで、情報処理装置１００（例えば、出力部１３６）は、受信されたリクエストＪＳＯＮに基づいて、勘定系システム２００と、電文データを送受信する（ステップＳ１０４）。リクエストＪＳＯＮに基づく勘定系システム２００との電文データの送受信は、図９を参照して以下で詳述される。

【0093】

次いで、情報処理装置１００（例えば、出力部１３６）は、勘定系システム２００から受信された電文データを、レスポンスＪＳＯＮに変換する（ステップＳ１０５）。勘定系システム２００から受信された電文データのレスポンスＪＳＯＮへの変換は、図１０を参照して以下で詳述される。

【0094】

次いで、情報処理装置１００（例えば、出力部１３６）は、レスポンスＪＳＯＮを、事業者装置３００に送信する（ステップＳ１０６）。

【0095】

図９は、実施形態に係る情報処理装置１００によって実行される、リクエストＪＳＯＮに基づいて勘定系システム２００と電文データを送受信するための処理の一例を示すフローチャートである。

【0096】

図９に示すように、はじめに、情報処理装置１００（例えば、出力部１３６）は、マッシュアップＡＰＩを読み込む（ステップＳ２０１）。例えば、情報処理装置１００は、図４を参照して上述したＡＰＩ接続条件仕様書記憶部１２４から、マッシュアップＡＰＩを取得する。

【0097】

次いで、情報処理装置１００は、受信されたリクエストＪＳＯＮをメモリ上に保持することによって、ＪＳＯＮデータを取得する（ステップＳ２０２）。

【0098】

次いで、情報処理装置１００は、ＡＰＩ定義を読み込む（ステップＳ２０３）。例えば、情報処理装置１００は、図３を参照して上述したＡＰＩ定義記憶部１２３から、ＡＰＩ定義を取得する。

【0099】

次いで、情報処理装置１００は、ＡＰＩ定義から項目情報を取得する（ステップＳ２０４）。例えば、情報処理装置１００は、図３を参照して上述した画面定義情報に対応する項目情報（例えば、項目名称、項目論理名称、型、桁数、必須チェック対象項目、システム論理項目名）を取得する。

【0100】

次いで、情報処理装置１００は、取得された項目情報の項目論理名称が取得されたＪＳＯＮデータのキー値と一致するかを判定する（ステップＳ２０５）。ＪＳＯＮデータのキー値は、例えば、図７を参照して上述したリクエストＪＳＯＮ５０に含まれる、「cifno」（すなわち、第１のキー）等のキーである。

【0101】

項目情報の項目論理名称がＪＳＯＮデータのキー値と一致すると判定された場合に（ステップＳ２０５：Ｙｅｓ）、情報処理装置１００は、項目情報からシステム論理項目名を取得する（ステップＳ２０６）。システム論理項目名は、例えば、図３を参照して上述した画面定義情報に含まれる、「F0001」、「F0002」、「F0003」等の項目名である。

【0102】

次いで、情報処理装置１００は、取得されたシステム論理項目名と、ＪＳＯＮデータのキー値に関連付けられたバリュー値に基づいて、送信電文データを構築する（ステップＳ２０７）。ＪＳＯＮデータのキー値に関連付けられたバリュー値は、図７を参照して上述したリクエストＪＳＯＮ５０に含まれる、「1234567890」、「123456」、「01」等のバリューである。

【0103】

次いで、情報処理装置１００は、他のＡＰＩ定義項目が残っているかを判定する（ステップＳ２０８）。他のＡＰＩ定義項目が残っていると判定された場合に（ステップＳ２０８：Ｙｅｓ）、処理手順は、ステップＳ２０５に戻る。この場合、情報処理装置１００は、他のＡＰＩ定義項目に関して、再度ステップＳ２０５を実行する。

【0104】

ステップＳ２０５において、項目情報の項目論理名称がＪＳＯＮデータのキー値と一致しないと判定された場合に（ステップＳ２０５：Ｎｏ）、情報処理装置１００は、デフォルト値定義がマッシュアップＡＰＩにあるかを判定する（ステップＳ２０９）。デフォルト値定義は、例えば、図４を参照して上述したマッシュアップ情報に含まれる、「科目＝普通」、「税＝分離課税」、「科目＝普通」等の値である。

【0105】

デフォルト値定義がマッシュアップＡＰＩにあると判定された場合に（ステップＳ２０９：Ｙｅｓ）、情報処理装置１００は、送信電文データ用の領域にデフォルト値を設定する（ステップＳ２１０）。

【0106】

デフォルト値定義がマッシュアップＡＰＩにないと判定された場合に（ステップＳ２０９：Ｎｏ）、情報処理装置１００は、コピー値定義がマッシュアップＡＰＩにあるかを判定する（ステップＳ２１１）。コピー値定義は、例えば、図４を参照して上述したマッシュアップ情報に含まれる、「コピー元取引ＩＤ」によって識別される実行取引において使用される項目情報の項目論理名称に対応する値である。

【0107】

コピー値定義がマッシュアップＡＰＩにあると判定された場合に（ステップＳ２１１：Ｙｅｓ）、情報処理装置１００は、送信電文データ用の領域にコピー値を設定する（ステップＳ２１２）。コピー値定義がマッシュアップＡＰＩにないと判定された場合に（ステップＳ２１１：Ｎｏ）、処理手順は、ステップＳ２０８に移行する。

【0108】

ステップＳ２０８において、他のＡＰＩ定義項目が残っていないと判定された場合に（ステップＳ２０８：Ｎｏ）、情報処理装置１００は、他のＪＳＯＮデータ項目がＪＳＯＮデータに残っているかを判定する（ステップＳ２１３）。他のＪＳＯＮデータ項目は、例えば、図７を参照して上述したリクエストＪＳＯＮ５０に含まれる、「tenban」（すなわち、第２のキー）等のキーである。他のＪＳＯＮデータ項目がＪＳＯＮデータに残っていると判定された場合に（ステップＳ２１３：Ｙｅｓ）、処理手順は、ステップＳ２０４に戻る。この場合、情報処理装置１００は、他のＪＳＯＮデータ項目に関して、再度ステップＳ２０４を実行する。

【0109】

他のＪＳＯＮデータ項目がＪＳＯＮデータに残っていないと判定された場合に（ステップＳ２１３：Ｎｏ）、情報処理装置１００は、送信電文データの項目をチェックする（ステップＳ２１４）。例えば、情報処理装置１００は、ＡＰＩ定義を参照し、送信電文データの型や桁数をチェックする。

【0110】

次いで、情報処理装置１００は、送信電文データを、勘定系システム２００に送信する（ステップＳ２１５）。

【0111】

次いで、情報処理装置１００は、勘定系システム２００から、受信電文データを受信して格納する（ステップＳ２１６）。例えば、情報処理装置１００は、受信電文データを、記憶部１２０内の所定の記憶領域（例えば、メモリ、ＳＳＤ（Solid State Drive））に格納する。このようにして、情報処理装置１００は、受信電文データを保持する。

【0112】

次いで、情報処理装置１００は、他の実行取引がＪＳＯＮデータに残っているかを判定する（ステップＳ２１７）。他の実行取引は、例えば、図４を参照して上述したマッシュアップ情報に含まれる、「実行取引ＩＤ」によって識別される他の実行取引である。例えば、第１の実行取引が、ＣＩＦ開設であり、第２の実行取引が、口座開設であってもよい。

【0113】

他の実行取引がＪＳＯＮデータに残っていると判定された場合に（ステップＳ２１７：Ｙｅｓ）、処理手順は、ステップＳ２０３に戻る。この場合、情報処理装置１００は、他の実行取引に関して、再度ステップＳ２０３を実行する。他の実行取引がＪＳＯＮデータに残っていないと判定された場合に（ステップＳ２１７：Ｎｏ）、処理手順は、終了する。なお、情報処理装置１００は、マッシュアップＡＰＩを参照し、引継ぎデータを、受信電文データや受信電文データに設定してもよい。引継ぎデータは、例えば、図４を参照して上述したマッシュアップ情報に含まれる、引継ぎ項目名等のデータである。このようにして、情報処理装置１００は、送信電文データを更新してもよい。

【0114】

図１０は、実施形態に係る情報処理装置１００によって実行される、勘定系システム２００から受信された電文データをレスポンスＪＳＯＮに変換するための処理の一例を示すフローチャートである。

【0115】

はじめに、情報処理装置１００（例えば、出力部１３６）は、記憶された応答電文データを取得する（ステップＳ３０１）。例えば、情報処理装置１００は、記憶部１２０内の所定の記憶領域から、応答電文データを取得する。

【0116】

次いで、情報処理装置１００は、ＡＰＩ定義を読み込む（ステップＳ３０２）。例えば、情報処理装置１００は、図３を参照して上述したＡＰＩ定義記憶部１２３から、ＡＰＩ定義を取得する。

【0117】

次いで、情報処理装置１００は、ＡＰＩ定義から第１の項目情報を取得する（ステップＳ３０３）。

【0118】

次いで、情報処理装置１００は、応答電文データから第２の項目情報を抽出する（ステップＳ３０４）。

【0119】

次いで、情報処理装置１００は、第１の項目情報のシステム論理項目名が第２の項目情報のシステム論理項目名と一致するかを判定する（ステップＳ３０５）。

【0120】

第１の項目情報のシステム論理項目名が第２の項目情報のシステム論理項目名と一致すると判定された場合に（ステップＳ３０５：Ｙｅｓ）、情報処理装置１００は、ＡＰＩ定義から論理項目名称を取得する（ステップＳ３０６）。

【0121】

次いで、情報処理装置１００は、レスポンスＪＳＯＮ用の領域にシステム論理項目名と、項目情報のデータとを設定する（ステップＳ３０７）。例えば、情報処理装置１００は、システム論理項目名と、項目情報のデータとをＪＳＯＮデータにマージする。

【0122】

次いで、情報処理装置１００は、他のＡＰＩ定義項目が応答電文データに残っているかを判定する（ステップＳ３０８）。他のＡＰＩ定義項目が応答電文データに残っていると判定された場合に（ステップＳ３０８：Ｙｅｓ）、処理手順は、ステップＳ３０５に戻る。この場合、情報処理装置１００は、他のＡＰＩ定義項目に関して、再度ステップＳ３０５を実行する。

【0123】

ステップＳ３０５において、第１の項目情報のシステム論理項目名が第２の項目情報のシステム論理項目名と一致しないと判定された場合に（ステップＳ３０５：Ｎｏ）、処理手順は、ステップＳ３０８に移行する。

【0124】

ステップＳ３０８において、他のＡＰＩ定義項目が応答電文データに残っていないと判定された場合に（ステップＳ３０８：Ｎｏ）、情報処理装置１００は、他の応答電文データ項目が応答電文データに残っているかを判定する（ステップＳ３０９）。

【0125】

他の応答電文データ項目が応答電文データに残っていると判定された場合に（ステップＳ３０９：Ｙｅｓ）、処理手順は、ステップＳ３０３に戻る。この場合、情報処理装置１００は、他の応答電文データ項目に関して、再度ステップＳ３０３を実行する。他の応答電文データ項目が応答電文データに残っていないと判定された場合に（ステップＳ３０９：Ｎｏ）、処理手順は、終了する。

【0126】

〔４．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の一部を手動的に行うこともできる。あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

【0127】

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

【0128】

例えば、図２に示した記憶部１２０の一部又は全部は、情報処理装置１００によって保持されるのではなく、ストレージサーバ等に保持されてもよい。この場合、情報処理装置１００は、ストレージサーバにアクセスすることで、画面定義情報やマッシュアップ情報等の各種情報を取得する。

【0129】

〔５．ハードウェア構成〕
また、上述してきた実施形態に係る情報処理装置１００は、例えば図１１に示すような構成のコンピュータ１０００によって実現される。図１１は、ハードウェア構成の一例を示す図である。コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力ＩＦ（Interface）１０６０、入力ＩＦ１０７０、ネットワークＩＦ１０８０がバス１０９０により接続された形態を有する。

【0130】

演算装置１０３０は、一次記憶装置１０４０や二次記憶装置１０５０に格納されたプログラムや入力装置１０２０から読み出したプログラム等に基づいて動作し、各種の処理を実行する。一次記憶装置１０４０は、ＲＡＭ等、演算装置１０３０が各種の演算に用いるデータを一時的に記憶するメモリ装置である。また、二次記憶装置１０５０は、演算装置１０３０が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等により実現される。

【0131】

出力ＩＦ１０６０は、モニタやプリンタといった各種の情報を出力する出力装置１０１０に対し、出力対象となる情報を送信するためのインタフェースであり、例えば、ＵＳＢ（Universal Serial Bus）やＤＶＩ（Digital Visual Interface）、ＨＤＭＩ（登録商標）（High Definition Multimedia Interface）といった規格のコネクタにより実現される。また、入力ＩＦ１０７０は、マウス、キーボード、およびスキャナ等といった各種の入力装置１０２０から情報を受信するためのインタフェースであり、例えば、ＵＳＢ等により実現される。

【0132】

なお、入力装置１０２０は、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等から情報を読み出す装置であってもよい。また、入力装置１０２０は、ＵＳＢメモリ等の外付け記憶媒体であってもよい。

【0133】

ネットワークＩＦ１０８０は、ネットワークＮを介して他の機器からデータを受信して演算装置１０３０へ送り、また、ネットワークＮを介して演算装置１０３０が生成したデータを他の機器へ送信する。

【0134】

演算装置１０３０は、出力ＩＦ１０６０や入力ＩＦ１０７０を介して、出力装置１０１０や入力装置１０２０の制御を行う。例えば、演算装置１０３０は、入力装置１０２０や二次記憶装置１０５０からプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行する。

【0135】

例えば、コンピュータ１０００が情報処理装置１００として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。

【0136】

上述してきたように、実施形態に係る情報処理装置１００は、定義情報生成部１３２と、取得部１３５と、出力部１３６とを有する。

【0137】

実施形態に係る情報処理装置１００において、定義情報生成部１３２は、勘定系システム２００で使用される複数の取引画面それぞれの画面定義に関する画面定義情報を用いて、外部に提供する勘定系システム２００の機能に関する機能定義情報を生成する。また、実施形態に係る情報処理装置１００において、取得部１３５は、機能定義情報に基づいて生成された入力画面を介して、入力情報を取得する。また、実施形態に係る情報処理装置１００において、出力部１３６は、機能定義情報に従って、入力情報を、勘定系システム２００で処理可能な形式のデータに変換し、変換したデータを勘定系システム２００に出力する。

【0138】

また、実施形態に係る情報処理装置１００において、定義情報生成部１３２は、画面定義情報を用いて、外部に提供する機能に対応する取引画面において当該機能の実行に必要な情報の入力を受け付ける入力項目に基づくアプリケーションインタフェースの定義情報を含む機能定義情報を生成する。

【0139】

また、実施形態に係る情報処理装置１００において、定義情報生成部１３２は、画面定義情報を用いて、アプリケーションインタフェースの振る舞いを定義した定義情報であって機能の実行時に要求される入力画面の遷移を定義するマッシュ定義情報を含む機能定義情報を生成する。

【0140】

また、実施形態に係る情報処理装置１００は、アプリケーションインタフェースの定義情報に基づいて、外部に提供された機能を利用する利用元がアプリケーションインタフェースの利用時に参照する接続条件の仕様書を生成する仕様情報生成部１３３を有する。

【0141】

また、実施形態に係る情報処理装置１００において、出力部１３６は、定義情報生成部１３２によって生成された機能定義情報に基づいて、入力画面を介して取得されて勘定系システム２００で処理可能な形式に変換されたデータが、外部に提供される機能の実行に必要な条件を満たすか否かを判定し、条件を満たす場合に、データを勘定系システム２００に出力する。

【0142】

また、実施形態に係る情報処理装置１００において、出力部１３６は、データの応答として、勘定系システム２００から勘定系システム２００で処理可能な形式の応答データを受信し、機能定義情報に従って、応答データを入力情報に対応する形式の応答情報に変換し、応答情報を送信する。

【0143】

また、実施形態に係る情報処理装置１００において、外部に提供する勘定系システム２００の機能は、外部に提供する勘定系システム２００の複数の機能のうちの１つであり、定義情報生成部１３２は、画面定義情報を用いて、外部に提供する勘定系システム２００の複数の機能に関する複数の機能定義情報を、複数の機能を組み合わせて実行するための機能定義情報である、機能組み合わせに関する機能定義情報とともに生成する。また、実施形態に係る情報処理装置１００において、取得部１３５は、定義情報生成部１３２によって生成された複数の機能定義情報に対応する入力情報を取得する。また、実施形態に係る情報処理装置１００において、出力部１３６は、定義情報生成部１３２によって生成された、複数の機能定義情報と、機能組み合わせに関する機能定義情報とに従って、取得部１３５によって取得された入力情報を、勘定系システム２００で処理可能な形式のデータに変換し、変換したデータを、勘定系システム２００に出力し、複数の機能定義情報と、機能組み合わせに関する機能定義情報とに、出力されたデータに対する応答を適用することによって、新たなデータを、勘定系システム２００に出力する。

【0144】

上述した各処理により、情報処理装置１００は、勘定系システム２００の利便性を向上させることができる。

【0145】

以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。また、銀行以外の利用者に対する、勘定系システムの利便性を向上させ、それによって新たなサービスが創出できる効果がある。加えて、勘定系システム機能を様々なチャネルで再利用させることができ、その結果、新規サービス構築に係る開発コストを削減し、開発スピードを向上させられる。

【0146】

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、出力部は、出力手段や出力回路に読み替えることができる。

【符号の説明】

【0147】

１ サービス連携システム
１００ 情報処理装置
１１０ 通信部
１２０ 記憶部
１２１ 画面定義情報記憶部
１２２ マッシュアップ情報記憶部
１２３ ＡＰＩ定義記憶部
１２４ ＡＰＩ接続条件仕様書記憶部
１３０ 制御部
１３１ 収集部
１３２ 定義情報生成部
１３３ 仕様情報生成部
１３４ 提供部
１３５ 取得部
１３６ 出力部
２００ 勘定系システム
３００ 事業者装置
４００ ユーザ装置

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】