特許 7122333 情報処理装置および情報処理方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-08-10

(45)【発行日】2022-08-19

(54)【発明の名称】情報処理装置および情報処理方法

(51)【国際特許分類】

   G06Q 50/26 20120101AFI20220812BHJP

   G06Q 40/02 20120101ALI20220812BHJP

【ＦＩ】

G06Q50/26

G06Q40/02

【請求項の数】 6

(21)【出願番号】P 2020055807

(22)【出願日】2020-03-26

(62)【分割の表示】P 2018051063の分割

【原出願日】2018-03-19

(65)【公開番号】P2020102270

(43)【公開日】2020-07-02

【審査請求日】2021-02-01

(73)【特許権者】

【識別番号】000102728

【氏名又は名称】株式会社エヌ・ティ・ティ・データ

(74)【代理人】

【識別番号】100095407

【弁理士】

【氏名又は名称】木村 満

(74)【代理人】

【識別番号】100132883

【弁理士】

【氏名又は名称】森川 泰司

(74)【代理人】

【識別番号】100166442

【弁理士】

【氏名又は名称】鈴木 洋雅

(74)【代理人】

【識別番号】100174067

【弁理士】

【氏名又は名称】湯浅 夏樹

(72)【発明者】

【氏名】山田 典史

(72)【発明者】

【氏名】久松 大介

(72)【発明者】

【氏名】山田 圭

(72)【発明者】

【氏名】岩崎 麻由子

(72)【発明者】

【氏名】田中 寛之

(72)【発明者】

【氏名】川村 良太

(72)【発明者】

【氏名】河西 美穂

【審査官】山崎 誠也

(56)【参考文献】

【文献】特開２０１２－１９０１５３（ＪＰ，Ａ）

【文献】特開２００５－２４２７８５（ＪＰ，Ａ）

【文献】特開２０１７－１４２６１９（ＪＰ，Ａ）

【文献】マネーフォワード、三菱東京UFJ銀行の残高情報などを取得可能に--参照系APIと連携，[online]，2018年02月23日，[令和４年５月２日検索], インターネット<URL:https://web.archive.org/web/20180223093038/https://japan.cnet.com/article/35115127/>

【文献】金融機関向けクラウドサービス「OpenCanvas」の提供について，[online]，2017年05月21日，[令和１年１１月２８日検索], インターネット<URL:https://www.nttdata.com/jp/ja/news/release/2017/051201/>

【文献】高瀬 琢磨，電子情報通信学会２０１８年総合大会講演論文集 通信２，2018年03月06日，p.39

【文献】魅力あるサービス＆ソリューションを横断的に企画・創出するＮＴＴデータ 第四金融事業本部，ＢＵＳＩＮＥＳＳ ＣＯＭＭＵＮＩＣＡＴＩＯＮ，株式会社ビジネスコミュニケーション社，2017年07月01日，第５４巻 第７号，ｐ．３６，３７，４０－４２

【文献】改正銀行法が変える電子決済の未来，Ｆｉｎａｎｃｉａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ，Ｎｏ．６５，日本金融通信社，2017年06月15日，ｐ．３３－３５

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

取引照会の内容と、照会先の金融機関を特定する金融機関特定情報と、取引照会の対象者を特定する対象者特定情報と、を含む照会要求を公的機関から受信する照会要求受信手段と、
前記金融機関がＡＰＩに対応する金融機関であるか否かを示すＡＰＩ対応金融機関情報を記憶する記憶手段と、
前記照会要求により特定される前記金融機関が、ＡＰＩに対応する金融機関であるか否かを前記ＡＰＩ対応金融機関情報に基づいて判定し、前記金融機関がＡＰＩに対応する金融機関である場合に第１の条件を満たすと判定し、前記金融機関がＡＰＩに対応しない金融機関である場合に第２の条件を満たすと判定する判定手段と、
前記判定手段が前記第１の条件を満たすと判定した場合、前記対象者特定情報に基づいて対象者を指定して前記金融機関特定情報で特定される金融機関の照会用ＡＰＩを呼び出し、前記金融機関によって特定された対象者の照会結果を取得して第１の照会結果情報を生成する照会結果情報生成手段と、
前記判定手段が前記第２の条件を満たすと判定した場合、前記取引照会の内容を含む照会依頼ファイルを前記金融機関に送信する照会依頼ファイル送信手段と、
前記照会依頼ファイル送信手段が前記照会依頼ファイルを送信した金融機関から第２の照会結果情報を受信する照会結果情報受信手段と、
前記第１の照会結果情報および前記第２の照会結果情報を前記公的機関に送信する照会結果情報送信手段と、
を備える情報処理装置。

【請求項2】

前記照会結果情報生成手段が取得した照会結果が、前記金融機関によって特定された複数の対象者候補の照会結果を含む場合には、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを判定する送信可否判定手段をさらに備え、
前記照会依頼ファイル送信手段は、前記送信可否判定手段が前記公的機関に送信しないと判定した場合に、前記照会依頼ファイルを前記金融機関に送信する、
請求項１に記載の情報処理装置。

【請求項3】

前記送信可否判定手段は、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを金融機関ごとに表す金融機関設定情報に基づいて、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを判定する、
請求項２に記載の情報処理装置。

【請求項4】

前記記憶手段は、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを前記公的機関ごとに表す公的機関設定情報をさらに記憶し、
前記送信可否判定手段は、前記公的機関設定情報に基づいて、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを判定する、
請求項２または３に記載の情報処理装置。

【請求項5】

前記照会結果情報生成手段は、前記照会用ＡＰＩを呼び出す際に前記対象者特定情報に含まれる情報のうち、個人の場合にはマイナンバー、法人の場合には法人番号に基づいて対象者を指定し、マイナンバーが前記対象者特定情報に含まれていない個人の場合には、カナ氏名と生年月日に基づいて対象者を指定し、法人番号が前記対象者特定情報に含まれていない法人の場合には、カナ名称と設立年月日に基づいて対象者を指定する、
請求項１から４のいずれか１項に記載の情報処理装置。

【請求項6】

照会要求受信手段が、取引照会の内容と、照会先の金融機関を特定する金融機関特定情報と、取引照会の対象者を特定する対象者特定情報と、を含む照会要求を公的機関から受信する照会要求受信ステップと、
記憶手段が、前記金融機関がＡＰＩに対応する金融機関であるか否かを示すＡＰＩ対応金融機関情報を記憶する記憶ステップと、
判定手段が、前記照会要求により特定される前記金融機関が、ＡＰＩに対応する金融機関であるか否かを前記ＡＰＩ対応金融機関情報に基づいて判定し、前記金融機関がＡＰＩに対応する金融機関である場合に第１の条件を満たすと判定し、前記金融機関がＡＰＩに対応しない金融機関である場合に第２の条件を満たすと判定する判定ステップと、
照会結果情報生成手段が、前記判定ステップで前記第１の条件を満たすと判定した場合、前記対象者特定情報に基づいて対象者を指定して前記金融機関特定情報で特定される金融機関の照会用ＡＰＩを呼び出し、前記金融機関によって特定された対象者の照会結果を取得して第１の照会結果情報を生成する照会結果情報生成ステップと、
照会依頼ファイル送信手段が、前記判定手段で前記第２の条件を満たすと判定した場合、前記取引照会の内容を含む照会依頼ファイルを前記金融機関に送信する照会依頼ファイル送信ステップと、
照会結果情報受信手段が、前記照会依頼ファイル送信ステップで前記照会依頼ファイルを送信した金融機関から第２の照会結果情報を受信する照会結果情報受信手段と、
照会結果情報送信手段が、前記第１の照会結果情報および前記第２の照会結果情報を前記公的機関に送信する照会結果情報送信ステップと、
を備える情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置および情報処理方法に関する。

【背景技術】

【0002】

国税庁、国税局、税務署等の公的機関の担当者は、税務調査、滞納整理、犯則調査等において必要があるときは、対象者の取引先である金融機関に対して取引照会を実施している。非特許文献１に記載されているように、取引照会では、公的機関の担当者が照会先である金融機関に照会文書を郵送し、照会文書が郵送されるたびに、照会先である金融機関が回答を記載して返送する運用となっている。

【先行技術文献】

【非特許文献】

【0003】

【文献】”金融機関に対する取引照会について”、［online］、平成２６年３月、国税庁、[平成３０年２月２３日検索]、インターネット＜ＵＲＬ：http://www8.cao.go.jp/kisei-kaikaku/kaigi/meeting/2013/wg2/sogyo/140312/item1.pdf＞

【発明の概要】

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

【0004】

しかしながら、現状の運用では、照会元の公的機関、照会の目的等によって照会文書の様式が異なっているため、照会先である金融機関は、回答を作成する作業を効率化できないという問題がある。また、金融機関は、法に基づいて対応を余儀なくされるため、作業コストを回収できないという問題がある。そして非特許文献１に開示されているように、国税当局側の照会窓口の集中化、照会文書様式の統一、取引照会の電子化等の取引照会を効率良く行うための提案が国税庁に対してなされているものの、未だ不十分である。

【0005】

本発明は、上記実情に鑑みてなされたものであり、依頼元機関から金融機関への取引照会を効率良く行うことができる情報処理装置および情報処理方法を提供することを目的とする。

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

【0006】

上記目的を達成するため、本発明の第１の観点に係る情報処理装置は、
取引照会の内容と、照会先の金融機関を特定する金融機関特定情報と、取引照会の対象者を特定する対象者特定情報と、を含む照会要求を公的機関から受信する照会要求受信手段と、
前記金融機関がＡＰＩに対応する金融機関であるか否かを示すＡＰＩ対応金融機関情報を記憶する記憶手段と、
前記照会要求により特定される前記金融機関が、ＡＰＩに対応する金融機関であるか否かを前記ＡＰＩ対応金融機関情報に基づいて判定し、前記金融機関がＡＰＩに対応する金融機関である場合に第１の条件を満たすと判定し、前記金融機関がＡＰＩに対応しない金融機関である場合に第２の条件を満たすと判定する判定手段と、
前記判定手段が前記第１の条件を満たすと判定した場合、前記対象者特定情報に基づいて対象者を指定して前記金融機関特定情報で特定される金融機関の照会用ＡＰＩを呼び出し、前記金融機関によって特定された対象者の照会結果を取得して第１の照会結果情報を生成する照会結果情報生成手段と、
前記判定手段が前記第２の条件を満たすと判定した場合、前記取引照会の内容を含む照会依頼ファイルを前記金融機関に送信する照会依頼ファイル送信手段と、
前記照会依頼ファイル送信手段が前記照会依頼ファイルを送信した金融機関から第２の照会結果情報を受信する照会結果情報受信手段と、
前記第１の照会結果情報および前記第２の照会結果情報を前記公的機関に送信する照会結果情報送信手段と、
を備える。

【0007】

前記照会結果情報生成手段が取得した照会結果が、前記金融機関によって特定された複数の対象者候補の照会結果を含む場合には、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを判定する送信可否判定手段をさらに備え、
前記照会依頼ファイル送信手段は、前記送信可否判定手段が前記公的機関に送信しないと判定した場合に、前記照会依頼ファイルを前記金融機関に送信する、
ようにしてもよい。

【0008】

前記送信可否判定手段は、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを金融機関ごとに表す金融機関設定情報に基づいて、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを判定する、
ようにしてもよい。

【0009】

前記記憶手段は、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを前記公的機関ごとに表す公的機関設定情報をさらに記憶し、
前記送信可否判定手段は、前記公的機関設定情報に基づいて、前記複数の対象者候補の照会結果を前記公的機関に送信するか否かを判定する、
ようにしてもよい。

【0010】

前記照会結果情報生成手段は、前記照会用ＡＰＩを呼び出す際に前記対象者特定情報に含まれる情報のうち、個人の場合にはマイナンバー、法人の場合には法人番号に基づいて対象者を指定し、マイナンバーが前記対象者特定情報に含まれていない個人の場合には、カナ氏名と生年月日に基づいて対象者を指定し、法人番号が前記対象者特定情報に含まれていない法人の場合には、カナ名称と設立年月日に基づいて対象者を指定する、
ようにしてもよい。

【0011】

上記目的を達成するため、本発明の第２の観点に係る情報処理方法は、
照会要求受信手段が、取引照会の内容と、照会先の金融機関を特定する金融機関特定情報と、取引照会の対象者を特定する対象者特定情報と、を含む照会要求を公的機関から受信する照会要求受信ステップと、
記憶手段が、前記金融機関がＡＰＩに対応する金融機関であるか否かを示すＡＰＩ対応金融機関情報を記憶する記憶ステップと、
判定手段が、前記照会要求により特定される前記金融機関が、ＡＰＩに対応する金融機関であるか否かを前記ＡＰＩ対応金融機関情報に基づいて判定し、前記金融機関がＡＰＩに対応する金融機関である場合に第１の条件を満たすと判定し、前記金融機関がＡＰＩに対応しない金融機関である場合に第２の条件を満たすと判定する判定ステップと、
照会結果情報生成手段が、前記判定ステップで前記第１の条件を満たすと判定した場合、前記対象者特定情報に基づいて対象者を指定して前記金融機関特定情報で特定される金融機関の照会用ＡＰＩを呼び出し、前記金融機関によって特定された対象者の照会結果を取得して第１の照会結果情報を生成する照会結果情報生成ステップと、
照会依頼ファイル送信手段が、前記判定手段で前記第２の条件を満たすと判定した場合、前記取引照会の内容を含む照会依頼ファイルを前記金融機関に送信する照会依頼ファイル送信ステップと、
照会結果情報受信手段が、前記照会依頼ファイル送信ステップで前記照会依頼ファイルを送信した金融機関から第２の照会結果情報を受信する照会結果情報受信手段と、
照会結果情報送信手段が、前記第１の照会結果情報および前記第２の照会結果情報を前記公的機関に送信する照会結果情報送信ステップと、
を備える。

【発明の効果】

【0012】

本発明によれば、依頼元機関から金融機関への取引照会を効率良く行うことができる情報処理装置および情報処理方法を提供することができる。

【図面の簡単な説明】

【0013】

【図1】本発明の実施の形態１に係る情報処理装置の概念図である。

【図2】本発明の実施の形態１に係る照会依頼ファイルの一例を表す図である。

【図3】本発明の実施の形態１に係る情報処理装置の機能ブロック図である。

【図4】本発明の実施の形態１に係るＡＰＩ対応金融機関情報の一例を表す図である。

【図5】本発明の実施の形態１に係るＡＰＩ対応項目情報の一例を表す図である。

【図6】本発明の実施の形態１に係る情報処理装置のハードウェア構成図である。

【図7】本発明の実施の形態１に係る情報処理装置の照会処理のフローチャートである。

【図8】本発明の実施の形態２に係る情報処理装置の機能ブロック図である。

【図9】本発明の実施の形態２に係る金融機関設定情報の一例を表す図である。

【図10】本発明の実施の形態２に係る公的機関設定情報の一例を表す図である。

【図11】本発明の実施の形態２に係る情報処理装置の照会処理のフローチャートである。

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

【0014】

（実施の形態１）
以下、本発明の情報処理装置を、公的機関から金融機関への取引照会業務を行うシステムに適用した実施の形態について、図面を参照して説明する。

【0015】

本実施の形態に係る情報処理装置１は、図１に示すように、公的機関２から照会依頼ファイルＳＦを受信して、後述する条件によって、金融機関３の照会用ＡＰＩ（Application Programming Interface）を呼び出すか、金融機関３に照会依頼ファイルＳＦを送信するかのいずれか一方または両方を実行する装置である。情報処理装置１は、金融機関３の照会用ＡＰＩを呼び出したときは、返却された照会結果から第１の照会結果情報を生成して、照会元である公的機関２に送信する。また、情報処理装置１は、金融機関３に照会依頼ファイルを送信したときは、第２の照会結果情報を受信して、そのまま公的機関２に送信する。

【0016】

公的機関２は、地方自治体、国税庁、税務署、日本年金機構、警察、裁判所等の各種機関であり、資産調査、税務調査、犯罪捜査協力調査等の名目で、金融機関３に取引照会を行う照会元の機関である。照会の対象となるのは個人または法人であり、納税義務がある者、納税義務があると認められる者、生活保護受給申請者、生活保護受給者、滞納者、被疑者等である。

【0017】

金融機関３は、銀行、信用金庫、保険会社、証券会社等の各種機関であり、公的機関２からの取引照会の照会先の機関である。

【0018】

公的機関２から情報処理装置１に送信される照会依頼ファイルＳＦは、図２に示すように、回答期限、調査基準日等の調査の基本情報と、マイナンバー、現住所、前住所、カナ氏名、氏名、生年月日、性別等の照会対象者を特定するための対象者特定情報と、預貯金の有無、預貯金の種類、口座開設年月日、口座番号、調査基準日現在の残高、調査基準日以前６ヶ月間の取引状況、本人確認書類の写し等の取引照会の内容を表す照会項目の情報と、を含む。照会依頼ファイルＳＦのファイル形式は、固定長ファイル、ＣＳＶ（Comma-Separated Values）、ＸＭＬ（Extensible Markup Language）等のコンピュータが読み取り可能な形式である。

【0019】

次に、情報処理装置１の機能構成について、図３を参照して説明する。情報処理装置１は、照会要求受信部１１と、ＡＰＩ対応金融機関判定部１２と、ＡＰＩ対応項目判定部１３と、ＡＰＩ連携部１４と、照会依頼ファイル送信部１５と、照会結果情報受信部１６と、照会結果情報生成部１７と、照会結果情報送信部１８と、を備える。

【0020】

照会要求受信部１１は、取引照会の内容を表す照会依頼ファイルＳＦと、照会先の金融機関３を特定する金融機関名と、を含む照会要求を公的機関２から受信する。照会先としては、１つの金融機関３を指定しても良いし、複数の金融機関３を指定しても良い。実際、公的機関２である自治体、税務署、警察等は、対象者のすべての資金を調査するため、複数の金融機関３に取引照会を行うことが多い。また、照会要求受信部１１は、１回の受信で、１人の対象者の照会依頼ファイルＳＦを受信しても良いし、まとめて複数の対象者の照会依頼ファイルＳＦを受信しても良い。なお、照会依頼ファイルＳＦの受信方法は、ＦＴＰ（File Transfer Protocol）、メール添付等の各種方法を含む。

【0021】

ＡＰＩ対応金融機関判定部１２は、照会要求受信部１１が受信した照会要求において指定された金融機関ごとに、ＡＰＩに対応しているか否かを判定する。具体的には、ＡＰＩ対応金融機関判定部１２は、図４に示すようなＡＰＩ対応金融機関情報ＡＫを保持し、これを参照して判定を行う。ＡＰＩ対応金融機関情報ＡＫは、金融機関ごとにＡＰＩに対応しているか否かを表す情報である。ＡＰＩ対応の金融機関３は、図示しないサーバに照会用ＡＰＩを用意し、情報処理装置１から当該照会用ＡＰＩを利用可能な状態にしておき、情報処理装置１からの照会要求に応じた処理を実行して照会結果を提供する。

【0022】

ＡＰＩ対応項目判定部１３は、照会要求受信部１１が受信した照会依頼ファイルＳＦに含まれる照会項目ごとに、ＡＰＩに対応しているか否かを判定する。具体的には、ＡＰＩ対応項目判定部１３は、図５に示すようなＡＰＩ対応項目情報ＡＦを保持し、これを参照して判定を行う。ＡＰＩ対応項目情報ＡＦは、照会項目ごとにＡＰＩに対応しているか否かを表す情報である。例えば、照会依頼ファイルＳＦの照会項目には、本人確認書類の写しのように、技術的にＡＰＩに馴染まないものが含まれる場合がある。そのため、ＡＰＩ対応項目情報ＡＦは、照会項目ごとにＡＰＩに対応している否かをあらかじめ指定しておくことで、後述するように照会項目ごとに処理することができるようにするものである。

【0023】

ＡＰＩ連携部１４は、ＡＰＩ対応項目判定部１３がＡＰＩに対応していると判定した照会項目について、ＡＰＩ対応金融機関判定部１２がＡＰＩに対応していると判定した金融機関３の照会用ＡＰＩを呼び出して、照会結果を受信する。照会用ＡＰＩを呼び出す際、ＡＰＩ連携部１４は、照会依頼ファイルＳＦに含まれる対象者特定情報に基づいて対象者を指定する。具体的には、ＡＰＩ連携部１４は、個人の場合はマイナンバー、法人の場合は法人番号に基づいて対象者を指定する。ただし、住所が不定の場合など、マイナンバーまたは法人番号が照会依頼ファイルＳＦに含まれる対象者特定情報に含まれていない場合には、ＡＰＩ連携部１４は、個人の場合はカナ氏名、法人の場合はカナ名称を正規化した上で、個人の場合はカナ氏名と生年月日、法人の場合はカナ名称と設立年月日に基づいて対象者を指定する。なお、正規化とは、例えば法人の場合のカナ名称において、「カブ）」、「（カブ」、「カブシキガイシャ」等の表記揺れを吸収して、形式を合わせることを意味する。金融機関３は、照会用ＡＰＩの呼び出しを受けて、自身の保有する情報システムを検索し、照会結果を情報処理装置１に送信する。この照会結果には、該当者なしの場合も含まれる。すなわち、ＡＰＩ連携部１４は、当該照会用ＡＰＩを呼び出すことにより指定した対象者の照会結果を取得する。

【0024】

照会依頼ファイル送信部１５は、ＡＰＩ対応金融機関判定部１２がＡＰＩに対応していないと判定した金融機関３に、照会依頼ファイルＳＦを送信する。また、照会依頼ファイル送信部１５は、ＡＰＩ対応金融機関判定部１２がＡＰＩに対応していると判定した金融機関３には、照会要求受信部１１が受信した照会依頼ファイルＳＦに、ＡＰＩ対応項目判定部１３がＡＰＩに対応していないと判定した照会項目が含まれる場合に、その照会依頼ファイルＳＦを送信する。照会依頼ファイル送信部１５における照会依頼ファイルＳＦの送信方法は、ＦＴＰ、メール添付等の各種方法を含む。

【0025】

照会結果情報受信部１６は、照会依頼ファイル送信部１５が照会依頼ファイルＳＦを送信した金融機関３から返却された第２の照会結果情報を受信する。実際には、金融機関３からの第２の照会結果情報は、即時に返却されなくても良い。第２の照会結果情報の受信方法は、ＦＴＰ、メール添付等の各種方法を含む。

【0026】

照会結果情報生成部１７は、ＡＰＩ連携部１４が金融機関３から受信した照会結果に基づいて、公的機関２に送信する第１の照会結果情報を生成する。具体的には、照会結果情報生成部１７は、照会結果を読み取って、第１の照会結果情報としてあらかじめ決められたファイル形式に変換して、第１の照会結果情報を生成する。第１の照会結果情報および第２の照会結果情報は、照会依頼ファイルＳＦと同様に、固定長ファイル、ＣＳＶ、ＸＭＬ等のコンピュータが読み取り可能な形式のファイルであっても良い。

【0027】

照会結果情報送信部１８は、照会結果情報受信部１６が金融機関３から受信した第２の照会結果情報および照会結果情報生成部１７が生成した第１の照会結果情報を、照会元である公的機関２に送信する。当該照会結果情報送信部１８における送信方法は、ＦＴＰ、メール添付等の各種方法を含む。

【0028】

次に、情報処理装置１のハードウェア構成について、図６を参照して説明する。情報処理装置１は、各種の処理を実行するＣＰＵ（Central Processing Unit）１０１と、揮発性メモリであるＲＡＭ（Random Access Memory）１０２と、不揮発性メモリであるＲＯＭ（Read Only Memory）１０３と、各種情報を記憶するハードディスクドライブ１０４と、通信回線とのインターフェースであるネットワークカード１０５と、を備える。

【0029】

ＣＰＵ１０１は、ハードディスクドライブ１０４に記憶されているプログラムをＲＡＭ１０２に読み出して実行することにより、後述する各種処理を実行する。

【0030】

ＲＡＭ１０２は、ＣＰＵ１０１の作業領域として用いられる。

【0031】

ＲＯＭ１０３は、ＣＰＵ１０１が実行する情報処理装置１の基本動作のための制御プログラム、ＢＩＯＳ（Basic Input Output System）等を記憶する。

【0032】

ハードディスクドライブ１０４は、情報を記憶する媒体であり、前述のＡＰＩ対応金融機関情報ＡＫ，ＡＰＩ対応項目情報ＡＦ等が格納される。

【0033】

ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３およびハードディスクドライブ１０４は、協同して、前述のＡＰＩ対応金融機関判定部１２、ＡＰＩ対応項目判定部１３または照会結果情報生成部１７として機能する。

【0034】

ネットワークカード１０５は、通信回線とのインターフェースであり、公的機関２および金融機関３との間で通信可能に接続されている。具体的には、公的機関２および金融機関３が備えるサーバ、端末等と接続されている。ネットワークカード１０５と各公的機関２および各金融機関３との間は直接接続されていても良く、インターネット、イントラネット、ＶＰＮ（Virtual Private Network）、ＬＡＮ（Local Area Network）等のネットワークを介して接続されていても良い。また、通信方式は有線でも無線でも良い。ネットワークカード１０５は、ＣＰＵ１０１、ＲＡＭ１０２およびＲＯＭ１０３と協同して、前述の照会要求受信部１１、ＡＰＩ連携部１４、照会依頼ファイル送信部１５、照会結果情報受信部１６または照会結果情報送信部１８として機能する。

【0035】

次に、情報処理装置１の動作について、図面を参照して説明する。公的機関２から照会処理の実行要求を受けると、情報処理装置１は、図７に示す照会処理を開始する。

【0036】

情報処理装置１が照会処理を開始すると、図７に示すように、照会要求受信部１１は、金融機関３を指定した取引照会の要求を、照会依頼ファイルＳＦとともに受信する（ステップＳ１１）。ここで、ステップＳ１１にて受信する情報には、対象者ごとの照会先の金融機関３を指定する情報が含まれている。このステップＳ１１において、照会要求受信部１１は、取引照会の内容と、照会先の金融機関３を特定する金融機関特定情報と、取引照会の対象者を特定する対象者特定情報と、を含む照会要求を公的機関２から受信する照会要求受信手段として機能する。また、ステップＳ１１は、照会要求を受信する照会要求受信ステップとして機能する。

【0037】

受信した照会依頼ファイルＳＦが複数ある場合、すなわち、複数の対象者の取引照会を含む場合、情報処理装置１は、以下の処理を対象者ごとに実行する。また、照会先の金融機関３が複数ある場合、情報処理装置１は、以下の処理を指定された金融機関ごとに実行する。

【0038】

ＡＰＩ対応金融機関判定部１２は、ステップＳ１１で受信した照会依頼ファイルＳＦにより照会先の金融機関３として指定された金融機関３が、ＡＰＩに対応するか否かを、ハードディスクドライブ１０４に格納されたＡＰＩ対応金融機関情報ＡＫを参照して判定する（ステップＳ１２）。

【0039】

ＡＰＩ対応金融機関判定部１２が、ＡＰＩに対応する金融機関であると判定すると（ステップＳ１２：Ｙｅｓ）、ＡＰＩ対応項目判定部１３は、ハードディスクドライブ１０４に格納されたＡＰＩ対応項目情報ＡＦを参照して、ステップＳ１１で受信した照会依頼ファイルＳＦにＡＰＩ対応項目が含まれるか否かを判定する（ステップＳ１３）。

【0040】

ＡＰＩ対応項目判定部１３が、照会依頼ファイルＳＦにＡＰＩ対応項目が含まれると判定した場合（ステップＳ１３：Ｙｅｓ）、ＡＰＩ連携部１４は、対象者を指定して金融機関３の照会用ＡＰＩを呼び出す。そして、ＡＰＩ連携部１４は、金融機関３から照会結果を受信する（ステップＳ１４）。

【0041】

次に、照会結果情報生成部１７は、ＡＰＩ連携部１４が受信した照会結果に基づいて第１の照会結果情報を生成する。そして、照会結果情報送信部１８は、第１の照会結果情報を送信する（ステップＳ１５）。

【0042】

ステップＳ１４およびステップＳ１５において、ＡＰＩ連携部１４および照会結果情報生成部１７は、協同して、対象者特定情報に基づいて対象者を指定して金融機関特定情報で特定される金融機関３の照会用ＡＰＩを呼び出し、金融機関３によって特定された対象者の照会結果を取得して第１の照会結果情報を生成する照会結果情報生成手段として機能する。また、ステップＳ１４およびステップＳ１５は、第１の照会結果情報を生成する照会結果情報生成ステップとして機能する。

【0043】

続いて、ＡＰＩ対応項目判定部１３は、ＡＰＩ対応項目情報ＡＦを参照して、ステップＳ１１で受信した照会依頼ファイルＳＦにＡＰＩ非対応項目が含まれるか否かを判定する（ステップＳ１６）。

【0044】

ステップＳ１２、ステップＳ１３およびステップＳ１６において、ＡＰＩ対応金融機関判定部１２およびＡＰＩ対応項目判定部１３は、それぞれ、または協同して、取引照会の要求が、第１の条件および第２の条件を満たすか否かを判定する判定手段として機能する。また、これらのステップＳ１２、ステップＳ１３およびステップＳ１６は、取引照会の要求が、第１の条件および第２の条件を満たすか否かを判定する判定ステップとして機能する。

【0045】

ＡＰＩ対応項目判定部１３が、照会依頼ファイルＳＦにＡＰＩ対応項目が含まれないと判定した場合（ステップＳ１３：Ｎｏ）、照会処理はステップＳ１４およびステップＳ１５の処理をスキップし、ステップＳ１６の処理に進む。

【0046】

ＡＰＩ対応項目判定部１３が、照会依頼ファイルＳＦにＡＰＩ非対応項目が含まれると判定すると（ステップＳ１６：Ｙｅｓ）、照会依頼ファイル送信部１５は、金融機関３に照会依頼ファイルＳＦを送信する（ステップＳ１７）。このステップＳ１７において、照会依頼ファイル送信部１５は、照会依頼ファイルＳＦを金融機関３に送信する照会依頼ファイル送信手段として機能する。また、このステップＳ１７は、照会依頼ファイルＳＦを金融機関３に送信する照会依頼ファイル送信ステップとして機能する。

【0047】

金融機関３の側では、受信した照会依頼ファイルＳＦに基づいて、自身の管理する情報システムを検索して第２の照会結果情報を生成し、生成した第２の照会結果情報を情報処理装置１に送信する処理が行われる。なお、ＡＰＩ対応項目とＡＰＩ非対応項目の両方を含んでいる場合は、照会依頼ファイルＳＦを受信した金融機関３は、ステップＳ１４において、対応項目の照会結果を照会用ＡＰＩにて返却しているため、それ以外の照会項目、例えば、本人確認書類の写しのみを第２の照会結果情報に含める処理が行われることとなる。そして、情報処理装置１の照会結果情報受信部１６は、金融機関３から第２の照会結果情報を受信する。そして、照会結果情報送信部１８は、第２の照会結果情報を公的機関２に送信する（ステップＳ１８）。このステップＳ１８において、照会結果情報受信部１６は、金融機関３から第２の照会結果情報を受信する照会結果情報受信手段として機能する。また、このステップＳ１８は、金融機関３から第２の照会結果情報を受信する照会結果情報受信ステップとして機能する。

【0048】

また、ステップＳ１５およびステップＳ１８において、照会結果情報送信部１８は、第１の照会結果情報および第２の照会結果情報を公的機関２に送信する照会結果情報送信手段として機能する。また、これらのステップＳ１５およびステップＳ１８は、第１の照会結果情報および第２の照会結果情報を公的機関２に送信する照会結果情報送信ステップとして機能する。

【0049】

ステップＳ１６において、ＡＰＩ対応項目判定部１３が、照会依頼ファイルＳＦにＡＰＩ非対応項目が含まれないと判定すると（ステップＳ１６：Ｎｏ）、情報処理装置１は、後述するステップＳ１９の処理に進む。

【0050】

また、ステップＳ１２において、ＡＰＩ対応金融機関判定部１２が、ＡＰＩに対応する金融機関でないと判定すると（ステップＳ１２：Ｎｏ）、照会処理はステップＳ１７に進む。この場合、ステップＳ１７において送信される照会依頼ファイルＳＦにはすべての照会項目が含まれることとなる。そして、当該照会依頼ファイルＳＦを受信した金融機関３の側では、照会依頼ファイルＳＦに含まれるすべての照会項目についての照会結果を含む第２の照会結果情報が生成され、情報処理装置１に送信される。

【0051】

そして、情報処理装置１の照会結果情報受信部１６は、金融機関３から第２の照会結果情報を受信する。そして、照会結果情報送信部１８は、第２の照会結果情報を公的機関２に送信する（ステップＳ１８）。

【0052】

照会依頼ファイルＳＦにＡＰＩ非対応項目が含まれないと判定した場合（ステップＳ１６：Ｎｏ）、またはステップＳ１８に続いて、情報処理装置１は、未処理の対象者または未処理の金融機関３が残っているか否かを判定する（ステップＳ１９）。情報処理装置１は、未処理の対象者または未処理の金融機関３が残っていると判定すると（ステップＳ１９：Ｙｅｓ）、ステップＳ１２の処理に戻る。

【0053】

一方、情報処理装置１は、未処理の対象者または未処理の金融機関３が残っていないと判定すると（ステップＳ１９：Ｎｏ）、照会処理を終了する。

【0054】

本実施の形態に係る情報処理装置１によれば、金融機関３にとっては、照会用ＡＰＩを用意すれば、第２の照会結果情報を生成する作業を大きく軽減できるため、効率が良い。また、ＡＰＩに対応していない金融機関に対しても、ファイルの送受信を行うことができるため、柔軟性が高い。

【0055】

また、照会項目ごとにＡＰＩに対応しているか否かを判定することによって、ＡＰＩに対応する項目については、ＡＰＩを利用して照会処理を行うことができる。したがって、金融機関３は、一部の照会項目だけがＡＰＩに対応していない場合であっても、その照会項目のみについて第２の照会結果情報の生成を行えば良いので、ＡＰＩに対応する利点を生かしやすい。

【0056】

（実施の形態２）
実施の形態１では、照会処理において照会用ＡＰＩの呼び出しに応じて返却された照会結果に基づいて第１の照会結果情報を生成する例を例示した。本実施の形態では、照会用ＡＰＩの呼び出しに応じて返却された照会結果が複数の対象者候補を含む場合に対する処理を追加した例を例示する。以下、本実施の形態については、実施の形態１と異なる部分を中心に説明する。

【0057】

本実施の形態に係る情報処理装置１は、図８に示すように、実施の形態１において説明した機能構成に加えて、送信可否判定部１９をさらに備える。

【0058】

送信可否判定部１９は、ＡＰＩ連携部１４が受信した照会結果をもとにして、公的機関２に第１の照会結果情報を送信するか否かを判定する。具体的には、送信可否判定部１９は、図９に示すような金融機関設定情報ＫＳおよび図１０に示すような公的機関設定情報ＰＳを保持し、これを参照して判定を行う。金融機関設定情報ＫＳは、金融機関ごとに複数の対象者候補の照会結果を送信するか否かを表す情報である。また、公的機関設定情報ＰＳは、公的機関ごとに複数の対象者候補の照会結果を送信するか否かを表す情報である。なお、金融機関設定情報ＫＳおよび公的機関設定情報ＰＳは、ともにハードディスクドライブ１０４に格納される。

【0059】

実際に、複数の対象者候補を含む照会結果は、金融機関３が対象者を一意に特定できなかった場合に発生する。したがって、金融機関にとっては、誤った対象者の個人情報を流出するリスクを回避するため、対象者を一意に特定できない場合には、公的機関２に送信したくない場合がある。そこで、金融機関ごとに送信可否を設定できるようにするための設定情報が、金融機関設定情報ＫＳである。また、公的機関によっては、犯罪捜査等の目的のため、少しでも可能性のある情報を得たいという場合がある。そこで、公的機関ごとに送信可否を設定できるようにするための設定情報が、公的機関設定情報ＰＳである。

【0060】

なお、金融機関設定情報ＫＳと公的機関設定情報ＰＳとで送信可否が異なる場合にどう判定するかは、あらかじめ設定しておく。例えば、いずれか一方が送信不可となっている場合は、送信不可と判定するというルールにしておけば良い。

【0061】

本実施の形態に係る情報処理装置１の照会処理について、図１１を参照して説明する。

【0062】

ステップＳ１４において、ＡＰＩ連携部１４が照会結果を受信すると、送信可否判定部１９は、その照会結果に複数の対象者候補が含まれるか否かを判定する（ステップＳ２０）。このステップＳ２０において、送信可否判定部１９は、複数の対象者候補の照会結果を公的機関２に送信するか否かを判定する送信可否判定手段として機能する。

【0063】

そして、送信可否判定部１９は、照会結果に複数の対象者候補が含まれると判定すると（ステップＳ２０：Ｙｅｓ）、ハードディスクドライブ１０４に格納された金融機関設定情報ＫＳおよび公的機関設定情報ＰＳを参照して、複数の対象者候補の照会結果を公的機関２に送信するか否かを判定する（ステップＳ２１）。

【0064】

送信可否判定部１９が複数の対象者候補の照会結果を公的機関２に送信すると判定すると（ステップＳ２１：Ｙｅｓ）、ステップＳ１５の処理に進み、照会結果情報生成部１７は、第１の照会結果情報を生成する。そして、照会結果情報送信部１８は、第１の照会結果情報を送信する。

【0065】

一方、送信可否判定部１９が複数の対象者候補の照会結果を公的機関２に送信しないと判定すると（ステップＳ２１：Ｎｏ）、ステップＳ１７の処理に進む。この場合、ステップＳ１７において、照会依頼ファイルＳＦを受信した金融機関３は、照会依頼ファイルＳＦに含まれる照会対象者の情報、例えば現住所、前住所等に基づいて対象者を特定する。そして、金融機関３は、第２の照会結果情報を生成し、情報処理装置１に送信する。

【0066】

また、ステップＳ２０において、送信可否判定部１９が照会結果に複数の対象者候補が含まれないと判定すると（ステップＳ２０：Ｎｏ）、ステップＳ１５の処理に進む。

【0067】

本実施の形態に係る情報処理装置１によれば、照会用ＡＰＩが対象者を一意に特定できなかった場合に対応して、公的機関２に複数の対象者候補を含む照会結果を送信するか否かを公的機関２および金融機関３ごとに細かく設定することができる。これによって、誤って個人情報を漏洩してしまうリスクを低減することができる。

【0068】

（変形例）
本発明は、上述した実施の形態に限定されるわけではなく、その他の種々の変更が可能である。

【0069】

上述の実施の形態では、各図面において、公的機関、金融機関、照会項目等の情報をひらがな、漢字等を含む名称で表された例を例示した。これらの情報の同一性を特定する精度を上げるため、数字、英字等からなる識別子をＩＤとして使用しても良い。特に、照会要求受信部１１が公的機関２から受信する照会要求には、金融機関名が含まれる例を例示したが、照会先の金融機関を特定する金融機関特定情報として機能すれば、金融機関の名称、ＩＤ等のどのような形式の情報でも良い。

【0070】

上述の実施の形態において、図７および図１１に示した照会処理の処理フローは一例であって、処理の順番が厳密にこの通りでなくても良い。また、複数の処理を並行して行っても良い。例えば、図７において、ステップＳ１３からステップＳ１５までの処理と、ステップＳ１６からステップＳ１８までの処理を並行して実行しても良い。また、ステップＳ１６からステップＳ１８までの処理を、ステップＳ１３からステップＳ１５までの処理よりも早く行っても良い。ステップＳ１６の判定処理をステップＳ１３の判定処理よりも早く行うことによって、ステップＳ１７の照会依頼ファイルＳＦの送信処理を早く行うことができる。その場合でも、照会処理は、処理の順番が変わるだけであり、図７のフローチャートと同等の処理フローを実行するものとなる。

【0071】

上述の実施の形態において、ステップＳ１５およびステップＳ１８における第１の照会結果情報および第２の照会結果情報の送信処理は、都度実行する例を例示した。しかし、送信のタイミングはこの例に限定されない。照会用ＡＰＩの処理結果である第１の処理結果ファイルはすぐに生成できるが、金融機関３から受信する第２の処理結果ファイルの受信には時間がかかると考えられる。そこで、例えば、照会用ＡＰＩの処理結果はすべての金融機関３、およびすべての対象者に対する第１の処理結果ファイルが揃ってから、まとめて照会元である公的機関２に送信しても良い。このようにすれば、すぐに取得できる照会結果をできるだけ迅速に、かつ回数を抑えつつ、公的機関２に送信できるし、時間のかかる照会結果を待たずに送信することができるため、利便性が高い。

【0072】

上述の実施の形態において、第１の条件および第２の条件を満たすか否かを判定する判定手段として、ＡＰＩに対応する金融機関であるか否かを判定するＡＰＩ対応金融機関判定部１２と、照会依頼ファイルに含まれる照会項目が、ＡＰＩ対応の項目であるか否かを判定するＡＰＩ対応項目判定部１３とを例示した。本発明の範囲はこれに限られず、例えば、照会の内容の重要性に基づいて、判定しても良い。例えば、重要性の高い照会内容の場合は、第１の条件および第２の条件をともに満たし、ＡＰＩ連携と照会依頼ファイルの送信を両方行うこととし、重要性の低い照会内容の場合は、第１の条件のみ満たし、第２の条件を満たさないものとして、ＡＰＩ連携のみ行うこととしても良い。このようにすれば、重要性の高い照会内容の場合は、比較的照会結果の精度が高くなり、重要性の低い照会内容の場合は、作業の手間がかからない。

【0073】

上述の実施の形態において、金融機関の照会用ＡＰＩとは、金融機関が持つ取引照会の機能を、外部すなわち情報処理装置１から利用可能にしたものである。したがって、ＡＰＩを、ライブラリ、プロトコル、その他ソフトウェアの実装を規定する仕様等にのみに限定して解釈すべきではない。

【0074】

上述の実施の形態２では、照会処理のステップＳ２１において送信可否判定部１９が複数の対象者候補の照会結果を公的機関２に送信しないと判定した場合、照会依頼ファイルＳＦを金融機関３に送信する例を例示した。この例では、金融機関３の担当者は、受信した照会依頼ファイルＳＦに含まれる照会対象者の情報、例えば現住所、前住所等に基づいて対象者を決定して、照会結果情報を生成することとなる。ただし、本発明の範囲はこれに限られず、送信可否判定部１９が複数の対象者候補の照会結果を公的機関２に送信しないと判定した場合、そのまま当該対象者についての当該金融機関３への照会処理を終了しても良い。その場合、情報処理装置１は、当該対象者についての当該金融機関３への照会結果を公的機関２に送信しない。そのため、当該金融機関３の担当者は、公的機関２に電話、電子メール等によって、対象者候補を特定できなかった旨を連絡しても良く、より柔軟な対応が可能となる。

【0075】

上述の実施の形態２において、照会用ＡＰＩが対象者を一意に特定できなかった場合に、照会依頼ファイルＳＦを金融機関３に送信する例を例示した。照会依頼ファイルＳＦを金融機関３に送信する条件としては、照会用ＡＰＩから該当者なしという照会結果を受信した場合に、照会依頼ファイルＳＦを金融機関３に送信するようにしても良い。このようにすれば、犯罪捜査等の重要度の高い取引照会において、重要な捜査情報を取得する機会を損失するリスクを回避することができる。

【0076】

本実施の形態に係る情報処理装置１は、専用の装置によらず、通常のコンピュータを用いて実現可能である。例えば、コンピュータに上述のいずれかを実行するためのプログラムを格納した記録媒体から該プログラムをコンピュータにインストールすることにより、上述の処理を実行する情報処理装置１を構成してもよい。また、複数のコンピュータが協同して動作することによって、１つの情報処理装置１を構成してもよい。

【0077】

また、コンピュータにプログラムを供給するための手法は、任意である。例えば、通信回線、通信ネットワーク、通信システム等を介して供給してもよい。

【0078】

また、上述の機能の一部をＯＳ（Operating System）が提供する場合には、ＯＳが提供する機能以外の部分をプログラムで提供すればよい。

【0079】

本発明は、本発明の広義の精神と範囲を逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施の形態は、この発明を説明するためのものであり、本発明の範囲を限定するものではない。すなわち、本発明の範囲は、実施の形態ではなく、特許請求の範囲によって示される。そして、特許請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、この発明の範囲内とみなされる。

【符号の説明】

【0080】

１…情報処理装置、２…公的機関、３…金融機関、１１…照会要求受信部、１２…ＡＰＩ対応金融機関判定部、１３…ＡＰＩ対応項目判定部、１４…ＡＰＩ連携部、１５…照会依頼ファイル送信部、１６…照会結果情報受信部、１７…照会結果情報生成部、１８…照会結果情報送信部、１９…送信可否判定部、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…ハードディスクドライブ、１０５…ネットワークカード、ＳＦ…照会依頼ファイル、ＡＫ…ＡＰＩ対応金融機関情報、ＡＦ…ＡＰＩ対応項目情報、ＫＳ…金融機関設定情報、ＰＳ…公的機関設定情報

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】