特許7570737 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ コンプライアンス・データラボ株式会社の特許一覧

特許7570737情報処理装置

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7A
7B
8
9
10
11
12
13
14
15

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

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

(11)【特許番号】

(24)【登録日】2024-10-11

(45)【発行日】2024-10-22

(54)【発明の名称】情報処理装置

(51)【国際特許分類】

G06Q 50/10 20120101AFI20241015BHJP

【ＦＩ】

G06Q50/10

【請求項の数】 5

(21)【出願番号】P 2023538547

(86)(22)【出願日】2022-07-26

(86)【国際出願番号】 JP2022028759

(87)【国際公開番号】W WO2023008420

(87)【国際公開日】2023-02-02

【審査請求日】2023-12-11

(31)【優先権主張番号】P 2021125975

(32)【優先日】2021-07-30

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】521157812

【氏名又は名称】コンプライアンス・データラボ株式会社

(74)【代理人】

【識別番号】100190621

【弁理士】

【氏名又は名称】崎間伸洋

(74)【代理人】

【識別番号】100212510

【弁理士】

【氏名又は名称】笠原翔

(72)【発明者】

【氏名】山崎博史

(72)【発明者】

【氏名】笠井麻矢子

【審査官】渡邉加寿磨

(56)【参考文献】

【文献】米国特許出願公開第２０１８／０２２５３８９（ＵＳ，Ａ１）

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

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

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

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

【請求項1】

実質的支配者の情報である支配者情報を提供すべき企業である第１の企業を指定する企業指定情報を取得する第１の取得手段と、
前記第１の取得手段により取得された前記企業指定情報を基に特定される、対象とする企業である対象企業を一意に識別可能な企業識別情報の他に、前記対象企業の受益者を表す受益者情報、及び前記受益者による前記対象企業の株の保有比率を表す保有比率情報を少なくとも含む受益者関係情報を有する企業情報を取得する第２の取得手段と、
前記第２の取得手段により取得された前記企業情報を参照して、想定する指定国の定義による受益率を特定する受益率特定手段と、
前記第２の取得手段により取得された前記企業情報、及び前記受益率特定手段により特定された受益率を基に、前記第１の企業における前記実質的支配者である前記受益者を特定し、特定した前記受益者に対応する前記受益者関係情報中の少なくとも一部を前記支配者情報として抽出する抽出手段と、
を備え、
前記受益率特定手段は、前記受益者が法人であり、且つ前記指定国の定義から設定される第１の条件を満たしている場合、前記受益者に対応する前記企業情報を参照して、前記受益者である法人に、前記指定国の定義から設定される第２の条件を満たす受益者が存在するか否かを少なくとも確認することにより、前記指定国の定義による受益率を特定する、
情報処理装置。

【請求項2】

実質的支配者の情報である支配者情報を提供すべき企業である第１の企業を指定する企業指定情報を取得する第１の取得手段と、
前記第１の取得手段により取得された前記企業指定情報を基に特定される、対象とする企業である対象企業を一意に識別可能な企業識別情報の他に、前記対象企業の受益者を表す受益者情報、及び前記受益者による前記対象企業の株の保有比率を表す保有比率情報を少なくとも含む受益者関係情報を有する企業情報を取得する第２の取得手段と、
前記第２の取得手段により取得された前記企業情報を参照して、想定する指定国の定義による受益率を特定する受益率特定手段と、
前記第２の取得手段により取得された前記企業情報、及び前記受益率特定手段により特定された受益率を基に、前記第１の企業における前記実質的支配者である前記受益者を特定し、特定した前記受益者に対応する前記受益者関係情報中の少なくとも一部を前記支配者情報として抽出する抽出手段と、
を備え、
前記抽出手段により抽出された前記支配者情報を出力するための出力手段と、
前記対象企業の前記企業識別情報の他に、前記指定国とされる可能性のある国のうちの一つと想定する想定国の公用語である言語により、前記対象企業の名称である企業名、及び前記対象企業の前記受益者の名称である受益者名がそれぞれ表された企業名情報、及び受益者名情報を少なくとも含む国別企業情報を取得可能な第３の取得手段と、をさらに備え、
前記出力手段は、前記企業情報が前記指定国の公用語である言語とは異なる言語で表され、且つ前記指定国が前記想定国のうちの何れかに一致する場合、前記抽出手段により前記受益者が前記実質的支配者と特定された前記第１の企業に対応する前記国別企業情報の少なくとも一部を前記支配者情報とともに出力させる、
情報処理装置。

【請求項3】

【請求項4】

【請求項5】

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置に関する。

【背景技術】

【0002】

近年、アンチ・マネーロンダリング、及び安全保障貿易管理に関する規制、或いは罰則が世界的に厳格化され、国際的な枠組の下で、日本でも法律が施行されている。その法律により、日本では、金融機関に代表される特定事業者に対し、法人との取り引き時、実質的支配者（ＵＢＯ：Ultimate Beneficial Ownership）情報を必ず申告させるようにしている（例えば、特許文献１参照）。このようなことから、顧客が必要とする法人のＵＢＯ情報を提供する情報サービス会社が設立されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１９－３６０９８号公報

【発明の概要】

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

【0004】

情報サービス会社は、ＵＢＯ情報を提供するためのデータベース（ＤＢ）を構築し、構築したＤＢから必要なＵＢＯ情報を抽出することにより、サービスとしてＵＢＯ情報を提供する。しかし、ＵＢＯの定義は、全ての国で同じではない。情報サービス会社が構築したＤＢは、サービスの提供を想定した国の定義に沿ってＵＢＯ情報を抽出できるように設計されており、想定した国とは異なる定義でのＵＢＯ情報は適切に抽出できない。このため、従来、ＤＢの想定とは異なる定義でＵＢＯ情報を提供する場合、例えばＤＢから対象法人に係わるレコードの情報（以降「法人情報」）を抽出させ、抽出させた法人情報を従業員に確認させることにより、ＵＢＯを特定させるようなことが行われている。

【0005】

通常、ＤＢのレコードは、法人毎に、株主（受益者）分、存在する。そのため、多くの法人では、複数のレコードが存在する。多数のレコードが存在する法人も少なくない。また、ＵＢＯの特定には、資本関係を考慮する必要がある。つまり、ＵＢＯを特定する場合、対象法人だけでなく、対象法人の株主となっている他の法人、更にはその他の法人の株主となっている別の法人のレコード等も確認する必要がある場合も少なくない。

【0006】

このようなことから、１対象法人のＵＢＯを特定するためには、従業員は、多数のレコードを確認する必要があるのが普通である。そのため、ＤＢで想定されていない定義でのＵＢＯの特定には非常に長い時間を要する場合も少なくないのが実情となっている。

【0007】

そのような不具合から、ＤＢで想定していない定義の国用に、ＤＢを新たに用意するという選択肢が考えられる。しかし、必要な法人の情報収集だけでも膨大なコスト、及び長い時間がともに必要である。そのため、サービスの提供をより早く開始できるようにするうえでも、既存のＤＢを利用するのが望ましいと考えられる。

【0008】

そこで、本発明は、既存のＤＢを利用して、複数の異なる定義で適切なＵＢＯ情報を抽出可能な情報処理装置を提供することを目的とする。

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

【0009】

本発明の一態様の情報処理装置は、実質的支配者の情報である支配者情報を提供すべき企業である第１の企業を指定する企業指定情報を取得する第１の取得手段と、前記第１の取得手段により取得された前記企業指定情報を基に特定される、対象とする企業である対象企業を一意に識別可能な企業識別情報の他に、前記対象企業の受益者を表す受益者情報、及び前記受益者による前記対象企業の株の保有比率を表す保有比率情報、を少なくとも含む受益者関係情報を有する企業情報を取得する第２の取得手段と、前記第２の取得手段により取得された前記企業情報を参照して、想定する指定国の定義による受益率を特定する受益率特定手段と、前記第２の取得手段により取得された前記企業情報、及び前記受益率特定手段により特定された受益率を基に、前記第１の企業における前記実質的支配者である前記受益者を特定し、特定した前記受益者に対応する前記受益者関係情報中の少なくとも一部を前記支配者情報として抽出する抽出手段と、を備える。

【発明の効果】

【0010】

本発明は、既存のＤＢを利用して、複数の異なる定義で適切なＵＢＯ情報を抽出可能な情報処理装置を提供することができる。

【図面の簡単な説明】

【0011】

【図1】本発明の情報処理装置の一実施形態に係るＡＰサーバにより情報サービス会社が提供するサービスの例の概要を説明する図である。

【図2】本発明の情報処理装置の一実施形態に係るＡＰサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。

【図3】本発明の情報処理装置の一実施形態に係るＡＰサーバのハードウェア構成の一例を示すブロック図である。

【図4】本発明の情報処理装置の一実施形態に係るＡＰサーバ上に実現される機能的構成の一例を示す機能ブロック図である。

【図5】１法人における資本関係の例を示す図である。

【図6】１法人により抽出される企業情報の例を説明する図である。

【図7A】ＵＢＯ特定処理の例を示すフローチャートである。

【図7B】ＵＢＯ特定処理の例を示すフローチャートである。

【図8】国別企業情報の構成例を説明する図である。

【図9】納品されるファイルの内容例を説明する図である。

【図10】本発明の情報処理装置の一実施形態の変形例に係るＡＰサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。

【図11】本発明の情報処理装置の第２一実施形態に係るＡＰサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。

【図12】本発明の情報処理装置の第２実施形態に係るＡＰサーバ上に実現される機能的構成の一例を示す機能ブロック図である。

【図13】第２実施形態におけるＵＢＯ特定処理の例を示すフローチャートである。

【図14】第２実施形態におけるＵＢＯ特定処理の例を示すフローチャートである（続き１）。

【図15】第２実施形態におけるＵＢＯ特定処理の例を示すフローチャートである（続き２）。

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

【0012】

以下、本発明を実施するための形態について、図を参照しながら説明する。なお、説明する実施形態は、あくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。本発明の技術的範囲には、様々な変形例も含まれる。

【0013】

（第１実施形態）
図１は、本発明の情報処理装置の第１実施形態に係るＡＰ（APplication）サーバにより情報サービス会社が提供するサービスの例の概要を説明する図である。

【0014】

情報サービス会社ＳＫは、情報提供会社ＪＫと連携し、顧客Ｃが望む法人のＵＢＯ（Ultimate Beneficial Ownership）情報を提供するサービス（以降「本サービス」と表記）を行う。顧客Ｃは、主に、法律でＵＢＯ情報の申告が義務となっている特定事業者である。特定事業者とは、具体的には、金融機関等、ファイナンスリース事業者、クレジットカード事業者、カジノ事業者、或いは宅地建物取引業者等である。ＵＢＯは、法人の事業経営を実質的に支配することが可能となる関係にある者を指し、どのような者が該当するかについては、法人の性質に従って定められている。ここでの法人には、企業等の他に、国、地方公共団体等も含まれる。つまり「法人」は、ここでは個人以外の人を指す意味で用いる。

【0015】

情報提供会社ＪＫは、顧客Ｃからの依頼を処理し、情報サービス会社ＳＫにＵＢＯ情報の抽出を依頼する。その依頼により、情報サービス会社ＳＫは、指定された法人（以降「対象法人」と表記）のＵＢＯの特定を行い、その特定結果を情報提供会社ＪＫに商品として納品する。情報提供会社ＪＫは、その特定結果を顧客Ｃに納品する。このようなことから、情報提供会社ＪＫは、フロントエンドのように機能し、情報サービス会社ＳＫは、バックエンドのように機能する。

【0016】

特定されるＵＢＯは、厳密にはＵＢＯの候補である。ここでは、特に断らない限り、ＵＢＯはＵＢＯの候補を指す意味で用いる。
情報提供会社ＪＫには、企業情報ＤＢ（Data Base）ＫＪ、及び国別企業情報ＤＢＫＫが構築されたストレージＳＴが用意されている。このストレージＳＴは、企業情報ＤＢＫＪ、及び国別企業情報ＤＢＫＫの保存に十分な容量を備えたものである。その容量を複数のストレージＳＴにより確保するようにしても良い。つまり、ストレージＳＴの数、各ストレージＳＴの容量等は、特に限定されない。

【0017】

企業情報ＤＢＫＪは、例えばＵＢＯ情報を提供する情報会社から提供された既存のＤＢであり、ＵＢＯ情報の抽出が可能なように構築されている。その情報会社は、例えば欧州でサービスを提供する会社であり、企業情報は例えば英語で表現されている。ＵＢＯの定義も欧州に沿ったものである。

【0018】

この情報会社は、全世界の法人を対象に、法人の情報を標準化し、標準化した情報に企業コードを割り当て、それらをまとめて１レコードに格納させている。各レコードには、ＵＢＯ情報の提供を可能にするために、対応する法人の１株主（受益者）に係わる情報も格納されている。それにより、企業情報ＤＢＫＪには、法人毎に、株主分のレコードが存在している。以降は、１レコードに格納された情報群を「企業情報」と表記する。その企業情報中の企業コードは、法人を一意に識別可能な識別情報である。

【0019】

国、地方公共団体、及び上場企業等では、他の法人とは異なり、個人（代表者等）の本人特定事項のみを確認すれば良いものとなっている。このことから、実質的に、申告が求められているのは、国、地方公共団体、及び上場企業等とは別に分類される法人である。その法人は主に企業である。企業情報ＤＢＫＪの１レコードに格納されている情報群を「企業情報」と呼称するのは、そのためである。

【0020】

企業等は、随時、新たに設立されるだけでなく、設立されていた企業等が消滅する場合もある。名称、住所、或いはリーダー（ＣＥＯ（Chief Executive Officer）、ＣＦＯ（Chief Financial Officer）等）も随時、変更される。情報会社は、このような企業等の設立、消滅、或いは各種変更等に対応し、企業情報ＤＢＫＪの更新を行う。このこともあり、企業情報ＤＢＫＪは、信頼性の高いＤＢとなっている。

【0021】

顧客Ｃは、ＵＢＯ情報の提供を依頼する場合、例えばＵＢＯ情報の提供を望む対象法人のリストを作成し、そのリストが格納されたファイルＦ１を情報提供会社ＪＫに送付する。そのファイルＦ１のリストは、例えば法人毎に、法人名、住所、及び企業コードが情報として入力されるのを想定したものである。企業コードは、企業情報ＤＢＫＪに用いられている企業コードである。そのため、顧客Ｃには、対象法人毎に、法人名、及び住所の入力、或いは企業コードの入力を求めている。

【0022】

法人名が同じ法人が複数、存在する可能性がある。同様に、複数の法人が同じ住所を登録させている場合もあり得る。このことから、企業コードが入力されない場合、法人名、及び住所は入力が必須の情報となる。それにより、法人名、及び住所の組、企業コードは何れも、本実施形態における企業指定情報に相当する。

【0023】

情報提供会社ＪＫの従業員は、受信されたファイルＦ１を確認し、企業コードが入力されていない法人の企業コードを特定し入力する。そのようにして企業コードが入力されたファイルＦ１が、情報サービス会社ＳＫに送信され、ＵＢＯ情報の抽出が依頼される。ＵＢＯ情報の抽出を可能にするために、情報提供会社ＪＫは、企業コードをキーとした企業情報ＤＢＫＪに対する検索を行い、その企業キーを格納したレコード、つまり企業情報を少なくとも抽出する。抽出した企業情報を参照し、更にＵＢＯ情報の抽出に必要と予想される企業情報を抽出する場合もある。この企業情報の抽出は、資本関係を考慮して行われるものである。このようにして抽出された企業情報は、ファイル化され、ファイルＦ３としてファイルＦ１とともに情報サービス会社ＳＫに送信される。

【0024】

なお、ファイルＦ３中の企業情報は、例えばファイルＦ１にまとめても良い。つまり、ＵＢＯ情報の抽出を依頼する際に情報提供会社ＪＫから情報サービス会社ＳＫに送信するファイルは、ファイルＦ１の一つのみとしても良い。

【0025】

情報サービス会社ＳＫは、ファイルＦ１、Ｆ３を参照し、顧客Ｃが指定した対象法人のＵＢＯを特定し、特定したＵＢＯのＵＢＯ情報を抽出する（ステップＳ１）。抽出されたＵＢＯ情報は、ファイルＦ４としてまとめられる。

【0026】

企業情報ＤＢＫＪは、例えば欧州でのＵＢＯの定義に沿ったものである。企業情報中のＵＢＯの判定に用いる情報の一部は、日本のような別の国の定義では不適切な内容となる可能性がある。このことから、日本の定義に沿ってのＵＢＯの特定では、日本では不適切な内容となっている情報は、日本の定義に沿ってその内容が確認される。そのようにして、企業情報ＤＢＫＪに格納されている企業情報中の日本の定義に沿う情報はそのまま参照しつつ、定義に沿わない情報はその内容を確認し、その確認結果をＵＢＯの特定に用いるようにしている。このため、日本の定義に沿って作成されていない企業情報ＤＢＫＪを参照して、日本の定義に沿ったＵＢＯの特定を行うことができる。企業情報ＤＢＫＪを用いて、日本の定義に沿ったＵＢＯの特定を行う場合、日本が指定国に相当する。

【0027】

企業情報ＤＢＫＪは、既存のＤＢである。そのような企業情報ＤＢＫＪを利用することで、その企業情報ＤＢＫＪのようなＤＢを新たに作成する場合と比較し、本サービスの提供のために必要なコスト、及び時間はともに大幅に抑えられる。企業情報中に日本の定義に沿っていない情報があっても、その定義に沿っていない情報の内容を確認することにより、ＵＢＯの特定は適切に行うことができる。企業情報で採用された定義、及び日本の定義の何れとも異なる部分がある定義に沿ったＵＢＯの特定も、同様に行うことができる。企業情報で採用されている定義に沿ったＵＢＯの特定は、企業情報を参照して行うことができる。このことから、必要な情報の内容を確認し、企業情報ＤＢＫＪのような既存のＤＢを利用することは、既存のＤＢの利用範囲をより広げ、より幅広いサービスの提供を実現させるうえで有効である。

【0028】

企業情報ＤＢＫＪに使用されている言語は英語である。日本語では、１つの英語表現に複数の日本語表現が存在する場合が多い。例えば個人名で用いられる「ひろし」は、ひらがなの他に、漢字でも表現される。漢字表現は数多く存在する。その漢字表現としては、例えば「浩」「宏」「博」「寛」「洋」「浩志」「弘司」等がある。読みが同じであっても使用される漢字が異なる人は、別人である。このようなこともあり、本サービスでは、日本の定義に沿ってＵＢＯを特定する場合、日本語でのＵＢＯ情報の提供に対応させている。国別企業情報ＤＢＫＫは、そのための辞書として用意されたＤＢである。ここでは、言語は、特に断らない限り、国の公用語である言語を指す意味で用いる。

【0029】

国別企業情報ＤＢＫＫを辞書として利用し入力される情報としては、法人名、個人名、及び住所等がある。ここでは、理解を容易とするために、入力される情報はこの３つのみと想定する。住所は、他の２つとは異なり、１英語表現に１日本語表現が対応することも多い。しかし、本サービスでは、顧客Ｃの利便性を考慮し、住所も日本語で提供するようにしている。

【0030】

なお、国別企業情報ＤＢＫＫは、基本的に、本サービスを提供する国に応じて用意すれば良いものである。これは、その国の言語（公用語）の表現でＵＢＯ情報の提供が望まれるケースが大部分であるからである。しかし、外国企業が顧客Ｃであった場合、日本語以外の言語でのＵＢＯ情報の提供を望むことも考えられる。日本語の他にも、１つの英語表現に対して複数の表現が存在することの多い言語（例えば北京語）が存在する。このことから、日本語以外の言語の国別企業情報ＤＢＫＫを用意して、その言語でのＵＢＯ情報の提供に対応可能にしても良い。日本語を含め、１つの英語表現に対して複数の表現が存在することの多い言語を公用語とする国は、想定国か、或いは想定国の候補である。

【0031】

国別企業情報ＤＢＫＫは、例えば法人毎に、その法人の名称、及びその法人の各株主の名称等が対応する言語表現の情報で１レコードにまとめられたものである。そのレコードには、法人を一意に特定可能なように企業コードも格納されている。ここでは、１レコードに格納された情報群を「国別企業情報」と表記する。また、想定する言語は「対象言語」と表記する。なお、国別企業情報ＤＢＫＫの構成は、特に限定されるものではない。例えば各株主の情報がそれぞれ１レコードに格納されたものであっても良い。

【0032】

ファイルＦ４の作成は、ＵＢＯの候補となる個人、或いは法人が特定されたことを意味する。個人は、対象法人か、或いはその対象法人と資本関係のある別法人の株主である。ファイルＦ４の作成後、情報サービス会社ＳＫは、対象法人の企業コード、更には別法人の企業コードを情報提供会社ＪＫに送信し、送信した企業コードに対応する国別企業情報の提供を要求する（ステップＳ２）。対象言語の特定用に、国コード、或いは情報提供会社ＪＫから情報サービス会社ＳＫに依頼時に通知される、その依頼に割り当てられた識別用コード等も併せて送信される。

【0033】

この要求により、情報提供会社ＪＫは、情報サービス会社ＳＫから受信した企業コードを用いた国別企業情報ＤＢＫＫの検索を行うことにより、その企業コードを格納した国別企業情報を抽出する。抽出された国別企業情報は、ファイル化され、ファイルＦ５としてを情報サービス会社ＳＫに提供される。

【0034】

情報サービス会社ＳＫは、このようにして提供されたファイルＦ５を保存する（ステップＳ２）。このファイルＦ５の受信、及び保存も、ステップＳ２に含まれる。
情報サービス会社ＳＫは、ファイルＦ４、Ｆ５を参照して、法人名、及び個人名のそれぞれに対応する対象言語表現の特定を行い、特定した対応関係の確認、及び修正を従業員に行わせるための画面を生成する。それにより、従業員に対し、自動的に対応付けた対象言語表現の法人名、及び個人名が適切か否かの確認、更には適切でないと判断した箇所の修正を行わせる。そのような確認作業により、法人名、及び個人名が確定される。その確定結果がファイル化され、ファイルＦ６として作成される（以上ステップＳ３）。なお、対象言語表現の特定は、周知の機械翻訳技術、及び自然言語処理の技術を用いて行うことができる。

【0035】

作成されたファイルＦ６は、顧客Ｃに提供するＵＢＯ情報のうちの一部である。情報サービス会社ＳＫは、ファイルＦ６の内容をファイルＦ４に反映、つまり合成する（ステップＳ４）。その合成結果が、顧客Ｃに納品するファイルＦ２となり、情報サービス会社ＳＫから情報提供会社ＪＫに納品される。なお、実際には、ファイルＦ２は、納品されるまでの間に各種チェックが行われる。つまり、ファイルＦ２は、各種チェックを経て、情報サービス会社ＳＫから情報提供会社ＪＫに納品される。

【0036】

情報提供会社ＪＫは、情報サービス会社ＳＫから送信されたファイルＦ２を顧客Ｃに納品する。
このように、本サービスでは、顧客ＣがファイルＦ１で指定した各対象法人のＵＢＯ情報の提供が依頼された場合、企業情報ＤＢＫＪ中の企業情報を参照し、対象法人のＵＢＯを特定する。更に必要に応じて、ＵＢＯの特定結果を用いて国別企業情報ＤＢＫＫ中の国別企業情報を参照し、ＵＢＯ情報を対象言語化する。そのようにして、本サービスでは、欧州とは異なる定義に沿ってＵＢＯを適切に特定するとともに、顧客Ｃにとって望ましい言語でＵＢＯ情報を提供する。

【0037】

なお、情報サービス会社ＳＫは、情報提供会社ＪＫから、必要な企業情報、及び国別企業情報を取得するようになっているが、企業情報ＤＢＫＪ、及び国別企業情報ＤＢＫＫのうちの少なくとも一方を情報サービス会社ＳＫに保管させても良い。ＵＢＯ情報が必要な対象法人は、ファイルＦ１にリストの形で指定させるのではなく、情報提供会社ＪＫが送信する画面（Ｗｅｂページ）上で指定可能なようにしても良い。その画面では、ＵＢＯの特定で想定する国を指定できるようにして、複数の国に対応させるのが望ましい。また、情報提供会社ＪＫではなく、顧客Ｃに対して直接、本サービスを提供するようにしても良い。このようなことを含め、本サービスの提供方法には、様々な変形が可能である。

【0038】

以降は、図２～図９を参照しつつ、図１に例示する本サービスの実現方法について詳細に説明する。
図２は、本発明の情報処理装置の第１実施形態に係るＡＰサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。

【0039】

情報サービス会社ＳＫには、図２に示すように、本実施形態に係るＡＰサーバ１と端末２とを例えばＬＡＮ（Local Area Network）により接続させたシステムが構築されている。情報提供会社ＪＫには、Ｗｅｂサーバ３と端末４とを例えばＬＡＮにより接続させたシステムが構築されている。情報サービス会社ＳＫ、及び情報提供会社ＪＫともに、端末２、４は従業員等が使用する端末であり、通常、複数台、存在する。ここでは便宜的に１台のみ示している。
なお、ＡＰサーバ１は、クラウドサービスにより提供されるものであっても良い。このこともあり、ＡＰサーバ１の所有者、及びその設置場所等は、特に限定されるものではない。これは、後述するＷｅｂサーバ３でも同様である。

【0040】

Ｗｅｂサーバ３は、顧客Ｃからのリクエストとして送信される依頼を処理するサーバであり、ネットワークＮと接続されている。そのネットワークＮには、各顧客Ｃで使用される端末５が接続可能である。それにより、顧客Ｃは、ネットワークＮを介して端末５をＷｅｂサーバ３に接続させ、Ｗｅｂサーバ３が提供するサービスを利用する。以降、混乱を避けるために、各端末２、４及び５は、それぞれ「処理側端末２」「受付側端末４」及び「顧客側端末５」と表記する。何れの端末も使用するのは従業員のみと想定する。

【0041】

処理側端末２は、図１にステップＳ３として示す確認作業に使用するのが可能な情報処理装置である。受付側端末４は、顧客Ｃから法人名、及び住所で指定された対象法人に割り当てられている企業コードの特定、及び入力等に使用するのが可能な情報処理装置である。顧客側端末５は、ネットワークＮを介して提供される各種サービスの利用を可能にする情報処理装置である。それらは何れも、例えばＰＣ（Personal Computer）、或いはタブレットＰＣ等の通信機能を備えた情報処理装置である。

【0042】

情報サービス会社ＳＫと情報提供会社ＪＫとは、例えば専用回線により接続されている。専用回線で接続させる場合、情報サービス会社ＳＫ、及び情報提供会社ＪＫともに、専用回線を介した通信を可能にするノードが存在する。図２では、便宜的に、そのようなノードは示していない。ここでは、Ｗｅｂサーバ３とＡＰサーバ１とは、情報提供会社ＪＫ、及び情報サービス会社ＳＫのそれぞれで敷設されているＬＡＮ等を介して接続されるものと想定する。

【0043】

Ｗｅｂサーバ３が提供するサービスを利用する場合、顧客側端末５から、ファイルＦ１とともに、ＵＢＯ情報の提供を依頼するコマンドがＷｅｂサーバ３に送信される。この送信は、例えば顧客側端末５からの要求によりＷｅｂサーバ３から送信される依頼受け付け用の画面（Ｗｅｂページ）上の操作により行われるようにしても良い。その場合、例えば顧客側端末５を使用する従業員に、ファイルＦ１をその画面上に添付させた後、ＵＢＯ情報の提供を指示するボタンをクリック操作させるようにしても良い。つまり、そのクリック操作により、添付されたファイルＦ１、及びＵＢＯ情報の提供を依頼するコマンドを顧客側端末５から送信させるようにしても良い。なお、このようなサービスの依頼方法は、１例であり、その依頼方法は特に限定されるものではない。依頼方法は、例えばメール、或いはファイル転送サービス等を用いたものであっても良い。

【0044】

Ｗｅｂサーバ３は、顧客側端末５からコマンドとともにファイルＦ１を受信した場合、その旨を受付側端末４に通知し、ファイルＦ１をアクセス可能に公開する。それにより、Ｗｅｂサーバ３は、何れかの受付側端末４を使用する従業員に対し、ファイルＦ１の内容確認、及び必要な企業コードの入力を求める。この結果、顧客Ｃから受信されたファイルＦ１は、内容確認が行われ、必要な企業コードが入力されたものに必要に応じて更新される。

【0045】

企業情報ＤＢＫＪ、及び国別企業情報ＤＢＫＫは、Ｗｅｂサーバ３が搭載、或いは接続されたストレージに保管されている。このことから、Ｗｅｂサーバ３は、ファイルＦ１の内容確認が行われた後、企業コードをキーとした企業情報ＤＢＫＪの検索を行い、ＵＢＯの特定に必要な企業情報を抽出する。資本関係を考慮し、抽出した企業情報中で株主として示されている法人の企業コードをキーとした企業情報ＤＢＫＪの検索も必要に応じて行い、更に企業情報を抽出する。抽出した企業情報はファイルＦ３としてまとめられ、ＵＢＯ情報の抽出を依頼するコマンドとともに、Ｗｅｂサーバ３からＡＰサーバ１に送信される。ファイルＦ３の他に、企業コードが入力されているファイルＦ１、及びＵＢＯを特定するうえで想定する国である指定国を表す国コードもＡＰサーバ１に送信される。

【0046】

対象法人の企業コードをキーとして企業情報ＤＢＫＪから抽出される企業情報は、欧州の定義に沿ったＵＢＯの特定を可能にする。このため、その企業情報中の株主として示さされている法人の企業コードにより更に抽出される企業情報、つまり資本関係に着目して更に抽出される企業情報は、欧州の定義に沿ったＵＢＯの特定には不要な情報となる。しかし、欧州以外の指定国、例えば日本の定義に沿ったＵＢＯの特定には、必要な情報である。このことから、本サービスでは、資本関係から特定された別法人の企業コードによる企業情報の抽出も行われる。

【0047】

国によるＵＢＯの定義の相違は、資本関係に係わるもの以外にも存在する。例えば企業でＵＢＯとされる個人は、欧州では株の保有比率が２５％以上という条件を満たす個人である。しかし、米国では、その保有比率が２５％超という条件を満たす個人である。ＵＢＯを適切に特定するためには、このような定義の相違にも対応させる必要がある。

【0048】

ＡＰサーバ１は、ファイルＦ１、及びＦ３を参照し、対象法人のＵＢＯの候補を特定する。ＵＢＯの候補として特定した個人が対象法人以外の法人の株主であった場合、その個人が株主となっている法人の企業コードも併せて特定される。ＡＰサーバ１は、ＵＢＯの特定結果をファイルＦ４として保存するとともに、抽出した企業コードを例えば国コードとともにＷｅｂサーバ３に送信し、企業コード、及び国コードに対応する企業コードの提供を要求する。

【0049】

この要求により、Ｗｅｂサーバ３は、受信した企業コードをそれぞれキーとした国別企業情報ＤＢＫＫの検索を行い、ＡＰサーバ１が要求した国別企業情報を抽出する。検索の対象となる国別企業情報ＤＢＫＫは、国コードによって指定されるものである。Ｗｅｂサーバ３は、そのようにして抽出した国別企業情報をファイルＦ５にまとめてＡＰサーバ１に送信する。

【0050】

ＡＰサーバ１は、ファイルＦ４、Ｆ５の各内容を企業コードで対応付け、対象法人の名称、更にはＵＢＯと特定した法人、或いは個人の名称とする指定国の言語表現を特定する。次にＡＰサーバ１は、その特定結果、及びファイルＦ４、Ｆ５の各内容の一部を用いて、各名称の確認、及び修正のためのファイルＦ６を作成し、作成したファイルＦ６を用いて、確認作業用の画面（Ｗｅｂページ）を作成する。その作成後、ＡＰサーバ１は、例えば処理側端末２を使用する従業員に対し、各名称の確認作業のための処理を行う。

【0051】

その処理により、確認作業用の画面へのアクセスが可能になるとともに、各名称の確認作業が必要な依頼の存在が処理側端末２を使用する従業員に通知される。この結果、確認作業が可能な従業員により、確認作業が行われ、その確認作業の内容に応じて、ファイルＦ６が更新される。

【0052】

そのようにしてファイルＦ６が更新された後、ＡＰサーバ１は、更新後のファイルＦ６の内容をファイルＦ４に合成する。その合成により、ファイルＦ４は、指定国の言語でＵＢＯ情報が表現されたファイルＦ２に更新される。そのファイルＦ２は、更に別の従業員、例えばファイルＦ２を納品するか否かを判断する権限を有する従業員のチェックを受けた後、ＡＰサーバ１からＷｅｂサーバ３に送信される。それにより、顧客Ｃには、そのファイルＦ２がＷｅｂサーバ３を介して送信されることとなる。

【0053】

図３は、本発明の情報処理装置の一実施形態に係るＡＰサーバのハードウェア構成の一例を示すブロック図である。次に図３を参照し、ＡＰサーバ１のハードウェア構成例について具体的に説明する。なお、この構成例は１例であり、ＡＰサーバ１のハードウェア構成はこれに限定されない。

【0054】

ＡＰサーバ１は、ＣＰＵ（Central Processing Unit）１１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、バス１４と、入出力インターフェース１５と、出力部１６、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０と、を備えている。

【0055】

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、或いは／及び記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。ＡＰサーバ１として機能させるアプリケーション・プログラム、つまり本サービスの提供用に開発されたアプリケーション・プログラムは、例えば記憶部１８に記憶されている。そのアプリケーション・プログラムをＣＰＵ１１がＲＡＭ１３に読み出して実行することにより、ＡＰサーバ１は、Ｗｅｂサーバ３からの依頼に対応することができる。

【0056】

ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。そのデータには、ＣＰＵ１１が実行する各種プログラムも含まれる。
ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

【0057】

出力部１６は、例えば液晶等のディスプレイを含む構成である。出力部１６は、ＣＰＵ１１の制御により、各種画像を表示する。出力部１６は、ＡＰサーバ１に搭載されたものであっても良いが、必要に応じて接続されるものであっても良い。つまり、出力部１６は、必須の構成要素ではない。

【0058】

入力部１７は、例えばキーボード等の各種ハードウェア釦等を含む構成である。その構成には、マウス等のポインティングデバイスが１つ以上、含まれていても良い。操作者は、入力部１７を介して各種情報を入力することができる。この入力部１７も、ＡＰサーバ１に搭載されたものであっても良いが、必要に応じて接続されるものであっても良い。つまり、入力部１７も、必須の構成要素ではない。

【0059】

記憶部１８は、例えばハードディスク装置、或いはＳＳＤ（Solid State Drive）等の補助記憶装置である。データ量の大きいデータは、この記憶部１８に記憶される。
通信部１９は、ＬＡＮを介したＷｅｂサーバ３、及び処理側端末２との間の通信を可能にする。

【0060】

ドライブ２０は、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリカード等のリムーバブルメディア２５を着脱可能な装置である。ドライブ２０は、例えば装着されたリムーバブルメディア２５からの情報の読み取り、及びリムーバブルメディア２５への情報の書き込みが可能である。それにより、リムーバブルメディア２５に記録されたプログラムは、ドライブ２０を介して、記憶部１８に記憶させることができる。また、ドライブ２０に装着されたリムーバブルメディア２５は、記憶部１８に記憶されている各種データのコピー先、或いは移動先として用いることができる。

【0061】

このようなＡＰサーバ１が備えるハードウェア資源は、アプリケーション・プログラムを含む各種プログラムによって制御される。その結果、ＡＰサーバ１は、Ｗｅｂサーバ１からの依頼を処理し、指定国の定義によるＵＢＯの特定、並びに指定国の言語表現でのＵＢＯ情報の提供を行うことができる。各種プログラムには、ＯＳ（Operating System）が含まれる。本サービスを提供するためのアプリケーション・プログラムは、そのＯＳ上で動作する。

【0062】

本サービス用に開発されたアプリケーション・プログラムは、リムーバブルメディア２５に記録させて配布しても良い。インターネット等のネットワークを介して配布可能にしても良い。このことから、アプリケーション・プログラムを記録した記録媒体としては、ネットワークに直接的、或いは間接的に接続された情報処理装置に搭載、若しくは装着されたものか、或いは外部のアクセス可能な装置に搭載、若しくは装着されたものであっても良い。以降、このアプリケーション・プログラムは、他と区別するために「開発アプリケーション」と表記する。

【0063】

Ｗｅｂサーバ３としては、ＡＰサーバ１のハードウェア構成と基本的に同じものを採用することができる。そのため、ここでの詳細な説明は省略する。ただし、Ｗｅｂサーバ３を構成する記憶部として、企業情報ＤＢＫＪ、及び国別企業情報ＤＢＫＫを格納するうえで十分な容量のストレージＳＴが搭載されている必要がある。そのストレージＳＴは、Ｗｅｂサーバ３に接続されたものであっても良い。ここでは、ストレージＳＴはＷｅｂサーバ３に搭載されているものとする。また、通信部は、ネットワークＮを介した通信を可能にするものと、ＡＰサーバ１との通信を可能にするものとの２つは備える必要がある。

【0064】

図４は、本発明の情報処理装置の一実施形態に係るＡＰサーバ上に実現される機能的構成の一例を示す機能ブロック図である。次に図４を参照しつつ、ＡＰサーバ１上に実現される機能的構成の例について詳細に説明する。

【0065】

ＡＰサーバ１のＣＰＵ１１上には、機能的構成として、図４に示すように、振分部１１１、依頼処理部１１２、ＵＢＯ特定部１１３、情報要求部１１４、情報入力部１１５、合成部１１６、及び出力処理部１１７が実現されている。これらは、上記開発アプリケーションを含む各種プログラムをＣＰＵ１１が実行することにより実現される。その結果として、記憶部１８には、条件情報格納部１８１、中間結果格納部１８２、及び特定結果格納部１８３が情報格納用に確保されている。

【0066】

振分部１１１は、通信部１９との間でデータの授受を行い、通信部１９から入力したデータを渡すべき出力先を特定し、特定した出力先にデータを渡す。データを渡す出力先は、依頼処理部１１２、情報要求部１１４、情報入力部１１５、及び出力処理部１１７のうちの何れかである。振分部１１１がデータを渡すべき出力先に渡す結果、そのデータの処理に必要な機能が動作する。

【0067】

依頼処理部１１２は、Ｗｅｂサーバ３から送信されるＵＢＯ情報の抽出の依頼を処理する。その依頼とともに送信されるファイルＦ１、Ｆ３、及び国コードも、振分部１１１から依頼処理部１１２に渡される。これらファイルＦ１、Ｆ３、及び国コードは依頼処理部１１２からＵＢＯ特定部１１３に渡される。この依頼処理部１１２は、本実施形態における狭義の第１の取得手段、及び第２の取得手段に相当する。

【0068】

ＵＢＯ特定部１１３は、ファイルＦ１、Ｆ３を参照し、ファイルＦ１で指定された対象法人毎に、国コードが表す指定国の定義に沿ってＵＢＯを特定する。ＵＢＯの特定のために、ＵＢＯ特定部１１３は、記憶部１８に確保された条件情報格納部１８１に格納されている条件情報を参照する。この条件情報は、国別、或いは定義別に用意される情報であり、想定する各国が定義するＵＢＯの条件等の内容を表している。それにより、条件情報を参照するＵＢＯ特定部１１３は、実際には欧州、及び日本以外の国の定義に沿ったＵＢＯの特定も可能になっている。国コードは、条件情報のうちで参照すべき条件情報の特定に用いられる。このＵＢＯ特定部１１３は、本実施形態における受益率特定手段、及び抽出手段に相当する。

【0069】

図５は、１法人における資本関係の例を示す図である。図６は、１法人により抽出される企業情報の例を説明する図である。図６に示す企業情報の例は、図５に示す資本関係を有する１法人を対象法人とする場合のものである。ここで、図５、及び図６を参照して、指定国が日本であった場合に、ＵＢＯ特定部１１３によるＵＢＯの特定方法について具体的に説明する。

【0070】

図５に示す例では、久喜株式会社（英語表記：Kuki Corp.）が対象法人Ｔである。その久喜株式会社に直接、資本を投入している株主として、「埼玉一郎」（英語表記：Ichiro Saitama）、「古河商事株式会社」（英語表記：Koga Corp.）、及び「千葉二郎」（英語表記：Jiro Chiba）が存在している。図５では、「埼玉一郎」をＰ１、「古河商事株式会社」をＣ２、及び「千葉二郎」をＰ３（英語表記：Jiro Chiba）で表している。それら株主の直接保有比率は、それぞれ、３０％、３０％、及び４０％である。

【0071】

古河商事株式会社の株主として、「東京太郎」（英語表記：Taro Tokyo）が存在する。その株主の直接保有比率は、６０％である。
このような資本関係が存在する対象法人では、図６に示すように、計５つの企業情報が抽出される。図６において、上の４つは何れも、欧州の定義に沿ってＵＢＯを特定する場合に抽出される企業情報である。最も下に位置する企業情報は、日本の定義に沿ってＵＢＯを特定するために抽出された企業情報である。

【0072】

図６では、企業情報のうちでＵＢＯの特定に特に重要な部分を抜粋して示している。抜粋した部分には、図６に示すように、企業コード（図中の英語表記：Corp NO.）、社名（法人名）（図中の英語表記：Business Name）、株主名（図中の英語表記：Shareholder）、株主の企業コード（図中の英語表記：Benef No.）、直接保有比率（図中の英語表記：Direct%）、間接保有比率（図中の英語表記：Indirect%）、実際の保有比率（図中の英語表記：Act%）、受益率（図中の英語表記：Beneficial%）、及び受益者インジケーター（図中の英語表記：Beneficial Indicator）の各情報が含まれる。これらの情報において、企業コードは、本実施形態における企業識別情報に相当する。また、株主名、及び株主の企業コードは、本実施形態における受益者情報に相当する。この受益者情報は以降「株主情報」とも表記する。

【0073】

直接保有比率、間接保有比率、及び実際の保有比率は何れも、ＵＢＯの特定、或いは受益率の算出に用いられる情報であり、本実施形態における保有比率情報に相当する。受益率、及び受益者インジケーターもＵＢＯの特定に用いられる情報である。これら、或いは受益率は、本実施形態における受益率情報に相当する。受益者インジケーターは、受益者である株主がＵＢＯになり得るか否かを表す情報である。図６中に表記の「True」「False」はそれぞれ、ＵＢＯになり得る、ＵＢＯになり得ない、を表している。受益者情報、及び保有比率情報は全て、本実施形態における受益者関係情報に相当する。本実施形態における企業情報には、受益者関係情報の他に、企業識別情報、受益率情報、株主名、及びその他が含まれる。

【0074】

古河商事株式会社の株主である「東京太郎」は、図５に示すように、久喜株式会社の直接の株主ではない。しかし、「東京太郎」は、古河商事株式会社を通して、久喜株式会社との間に資本関係が存在する。このため、図６に示すように、「東京太郎」は、久喜株式会社の受益者と見なされ、企業情報が抽出されている。

【0075】

「東京太郎」を受益者とする企業情報では、直接保有比率、間接保有比率、及び実際の保有比率は全て０％か、或いはそれらの情報は全て存在しない。しかし、久喜株式会社の株を所有する古河商事株式会社に資本を投入していることから、受益率として、古河商事株式会社での直接保有比率、及びその古河商事株式会社の久喜株式会社に対する直接保有比率から算出された１８％が存在している。

【0076】

この１８％という数値は、欧州での定義（基準）により算出されたものである。その数値の算出方法は、日本の定義（基準）とは異なる。つまり、この例での欧州基準では、古河商事株式会社の久喜株式会社に対する直接保有比率、及び「東京太郎」の古河商事株式会社に対する直接保有比率を用いて
受益率＝久喜株式会社に対する直接保有比率×古河商事株式会社に対する直接保有比率
＝３０％ × ６０％＝１８％
により算出される。これに対し、日本基準では
受益率＝久喜株式会社に対する直接保有比率 × １００％
＝３０％ × １００％＝３０％
により算出される。

【0077】

法人の株の５０％超を所有する個人は、理論的に、その法人における意思決定を自ら行うことができる。このことから、日本基準では、個人が株の５０％超を所有する法人は、その個人が全ての株を所有しているものと見なし、直接保有比率が実質的に１００％であるとして、受益率を算出するようにしている。それにより、実質的な直接保有比率を採用しない欧州基準とは、日本基準で算出される受益率は基本的に一致しない。

【0078】

上記のように受益率を算出する日本基準では、個人ではＵＢＯと見なされる法人の資本関係を辿り、その法人に直接、或いは間接的に資本を投入している法人の受益者を確認する必要がある。図６の最も下に位置する企業情報、つまり古河商事株式会社の企業情報は、そのために実際に抽出された企業情報である。この企業情報を参照することにより、「東京太郎」の久喜株式会社における実際の受益率を確認することができる。

【0079】

図７Ａ、及び図７Ｂは、ＵＢＯ特定処理の例を示すフローチャートである。このＵＢＯ特定処理は、１対象法人のＵＢＯの特定のためにＵＢＯ特定部１１３によって実行される部分を抽出して、その部分の処理の流れの例を表したものである。ここで図７Ａ、及び図７Ｂを参照し、ＵＢＯ特定処理について詳細に説明する。処理を実行する主体としてはＵＢＯ特定部１１３を想定する。

【0080】

本サービスでは、ＵＢＯの法人への一般的に予測される影響力の強さから複数のカテゴリに分け、ＵＢＯを特定するとともに、そのＵＢＯが属するカテゴリも併せて特定するようにしている。図７Ａ、及び図７Ｂでは、影響力が最も強いＵＢＯのカテゴリは「第１順位」、次に影響力が強いＵＢＯのカテゴリは「第２順位」、影響力が最小のＵＢＯのカテゴリは「第４順位」とそれぞれ表記している。

【0081】

指定国が日本であった場合、第１順位は、例えば株の保有比率が５０％超となっているＵＢＯが分類される。第２順位は、例えば株の保有比率が２５％超であり、且つ５０％以下となっているＵＢＯが分類される。第４順位には、例えば株の保有比率が２５％超の第１順位に分類されるＵＢＯが存在しない法人の代表者がＵＢＯとして分類される。何れのカテゴリも、対象法人の株を直接、保有していない個人、或いは法人がＵＢＯとされる場合がある。

【0082】

先ず、ステップＳ１１では、ＵＢＯ特定部１１３は、指定国に対応する条件情報を条件情報格納部１８１から読み出し、ＵＢＯを特定するうえでの条件α～γを設定する。設定される条件αは、第１順位と分類するＵＢＯが満たすべき条件である。条件βは、第２順位と分類するＵＢＯが満たすべき条件である。条件γは、第２順位以上に分類するＵＢＯが満たすべき条件である。それにより、条件γは、条件βで下限となる条件である。本実施形態では、条件γが第１の条件に相当し、条件αが第２の条件に相当する。

【0083】

ステップＳ１１に続くステップＳ１２では、ＵＢＯ特定部１１３は、ファイルＦ３を参照して、対象法人の株を所有する個人を対象に、各個人の保有比率を特定する。特定される保有比率は、例えば直接保有比率、間接保有比率、及び実際の保有比率である。
次に移行するステップＳ１３では、ＵＢＯ特定部１１３は、条件αを満たす個人が存在するか否か判定する。条件αを満たす個人、例えば株の何れかの保有比率が５０％超となっている個人が存在する場合、ステップＳ１３の判定はＹＥＳとなってステップＳ１４に移行し、その個人を第１順位に決定する。その後、ステップＳ１５に移行する。一方、そのような個人が存在しない場合、ステップＳ１３の判定はＮＯとなってステップＳ１５に移行する。

【0084】

ステップＳ１５では、ＵＢＯ特定部１１３は、条件βを満たす個人が存在するか否か判定する。その条件βを満たす個人、例えば株の何れかの保有比率が５０％以下であり、且つ２５％超となっている個人が一人以上、存在する場合、ステップＳ１５の判定はＹＥＳとなってステップＳ１６に移行し、条件βを満たす全ての個人を第２順位に決定する。その後、ステップＳ１７に移行する。一方、そのような個人が存在しない場合、ステップＳ１５の判定はＮＯとなって、そのステップＳ１７に移行する。

【0085】

ステップＳ１７では、ＵＢＯ特定部１１３は、ファイルＦ３を参照して、対象法人の株を所有する法人を対象に、各法人の保有比率を特定する。ここで特定される保有比率は、例えば直接保有比率である。

【0086】

次に移行するステップＳ１８では、ＵＢＯ特定部１１３は、条件γを満たし、且つ受益者インジケーターが「False」となっている法人が存在するか否か判定する。この条件γは、例えば直接保有比率が２５％超という条件である。この条件γを満たす法人が存在する場合、ステップＳ１８の判定はＹＥＳとなって図７ＢのステップＳ２２に移行する。そのような法人が存在しない場合、ステップＳ１８の判定はＮＯとなってステップＳ１９に移行する。

【0087】

ステップＳ１９では、ＵＢＯ特定部１１３は、対象法人のＵＢＯが決定済みか否か判定する。ステップＳ１９には、ステップＳ１４で第１順位の個人、或いは／及び、ステップＳ１６で第２順位の個人を決定した後に移行する場合がある。その場合、既にＵＢＯが決定されていることになる。このことから、その場合、ステップＳ１９の判定はＹＥＳとなってステップＳ２１に移行する。一方、そうでない場合、ＵＢＯは決定されていないことから、ステップＳ１９の判定はＮＯとなってステップＳ２０に移行する。

【0088】

ステップＳ２０では、ＵＢＯ特定部１１３は、対象法人の代表者を第４順位に決定する。続くステップＳ２１では、ＵＢＯ特定部１１３は、指定国の定義でＵＢＯの特定結果を操作する。その後、ＵＢＯ特定処理が終了する。
後述するステップの処理の実行時を含め、ステップＳ２１への移行時には、ＵＢＯの特定結果は４つのケースに分けられる。そのケースとは、対象法人の代表者の第４順位（第１ケース）、一人以上の第２順位（第２ケース）、一人の第１順位（第３ケース）、及び一人の第２順位と一人の第１順位（第４ケース）、の４つである。ここでの「人」は、個人、或いは特定の法人のことである。特定法人とは、国、地方公共団体、或いは上場企業等の法人のことである。

【0089】

指定国とされる国のうちには、第１順位、第２順位のような区別をしない国が存在する。そのような国では、第１順位と決定された人、及び第２順位と決定された人はともにＵＢＯとされる。第１順位、第２順位のような区別をする国でも、第１順位と決定された人、及び第２順位と決定された人をともにＵＢＯとする国がある。日本は、区別する国の一つである。しかし、日本では、第１順位と決定された人のみがＵＢＯとされる。

【0090】

対象法人により図６に示すような企業情報が抽出された場合、上記のように、「ＴａｒｏＴｏｋｙｏ」は欧州の定義ではＵＢＯとされないのに対し、日本の定義ではＵＢＯとされる。指定国が欧州、及び日本の何れであれ、ステップＳ２１への移行時には「ＴａｒｏＴｏｋｙｏ」はＵＢＯとして決定される。しかし、指定国が欧州であった場合、「ＴａｒｏＴｏｋｙｏ」は、受益率により、ＵＢＯから除外される。「ＴａｒｏＴｏｋｙｏ」以外のＵＢＯが存在しなかった場合、対象法人の代表者がＵＢＯとされる。このような操作の実現のために、ステップＳ２１では、指定国の定義に沿った受益率の算出、算出した受益率による操作も必要に応じて行われる。

【0091】

ＵＢＯの定義は国によって異なることから、ステップＳ２１の処理が実行され、指定国の定義に沿って、ＵＢＯの特定結果が必要に応じて操作される。その操作により、指定国の定義でＵＢＯとされる人の最終的な抽出が行われ、抽出された人のＵＢＯとしての判定結果は指定国の定義に沿ったものに変換される。指定国が日本であった場合、第４のケースでは、第１順位と決定された人のみがＵＢＯとされる。第１～第３ケースでは、特定結果への操作は行われず、その特定結果は維持される。

【0092】

図７ＢのステップＳ２２以降では、対象法人の資本関係を辿り、ＵＢＯを特定するための処理が行われる。
先ず、ステップＳ２２では、ＵＢＯ特定部１１３は、ステップＳ１８の判定をＹＥＳとさせる法人のうちの一つを処理対象として選択する。次のステップＳ２３では、ＵＢＯ特定部１１３は、選択した法人の企業情報を参照する。その後に移行するステップＳ２４では、ＵＢＯ特定部１１３は、選択した法人に条件αを満たす株主が存在するか否か判定する。そのような株主が存在する場合、ステップＳ２４の判定はＹＥＳとなってステップＳ２５に移行する。そのような株主が存在しない場合、ステップＳ２４の判定はＮＯとなってステップＳ３０に移行する。
なお、本実施形態では、ステップＳ２３で参照する企業情報はファイルＦ３中に格納されているものであるが、その企業情報はＷｅｂサーバ３から必要に応じて取得するものであっても良い。このこともあり、企業情報は、ファイル化して送受信しなくとも良い。

【0093】

ステップＳ２５では、ＵＢＯ特定部１１３は、条件αを満たす株主が法人か否か判定する。その株主が法人であった場合、言い換えればその株主が示された企業情報中の受益者インジケーターが「False」であった場合、ステップＳ２５の判定はＹＥＳとなってステップＳ２６に移行する。その株主が個人であった場合、ステップＳ２５の判定はＮＯとなってステップＳ２７に移行する。

【0094】

ステップＳ２６では、ＵＢＯ特定部１１３は、株主が特定の法人か否か判定する。株主が特定法人であった場合、ステップＳ２６の判定はＹＥＳとなってステップＳ２７に移行する。株主が特定法人でない場合、ステップＳ２６の判定はＮＯとなり、上記ステップＳ２２に戻る。

【0095】

そのようにしてステップＳ２６からステップＳ２２に移行した場合、ステップＳ２２では、現在、選択している法人の株主のうちで条件αを満たす法人、つまりステップＳ２４の判定をＹＥＳとさせた法人が新たに選択される。それにより、ステップＳ２２～Ｓ２６で形成される処理ループを実行する結果、対象法人から資本関係を辿りつつ、ＵＢＯとすべき個人、或いは法人を特定することができる。この処理ループは、ＵＢＯとすべき個人、或いは法人を特定することにより終了する。

【0096】

ステップＳ２７では、ＵＢＯ特定部１１３は、ステップＳ１８の判定をＹＥＳとさせた法人のうちで選択中の法人（図７Ｂ中「元々の法人」と表記）が、条件αを満たすか否か判定する。選択中の法人が条件αも満たしていた場合、ステップＳ２７の判定はＹＥＳとなってステップＳ２８に移行する。選択中の法人が条件αを満たしていない場合、ステップＳ２７の判定はＮＯとなってステップＳ２９に移行する。

【0097】

ステップＳ２７には、ステップＳ２６でのＹＥＳの判定の他に、ステップＳ２５でのＮＯの判定によっても移行する。そのため、ＵＢＯは、個人、及び特定法人のうちの何れかに応じて決定する必要がある。それにより、ステップＳ２８、及びＳ２９ともに、個人、及び特定法人のうちの何れかであるかに応じて処理内容が異なる。

【0098】

ステップＳ２８では、ＵＢＯ特定部１１３は、個人であればその個人、特定法人であればその法人自体を第１順位に決定する。その決定後、ステップＳ３０に移行する。一方のステップＳ２９では、ＵＢＯ特定部１１３は、個人であればその個人、特定法人であればその法人自体を第２順位に決定する。その決定後、ステップＳ３０に移行する。

【0099】

ステップＳ３０では、ＵＢＯ特定部１１３は、他に資本関係を辿るべき法人が存在するか否か判定する。ステップＳ１８の判定をＹＥＳとさせた法人のうちで処理対象として選択していない法人が残っている場合、ステップＳ３０の判定はＹＥＳとなって上記ステップＳ２２に戻る。それにより、そのステップＳ２２では、ステップＳ２６から移行した場合とは異なり、残っている法人のうちから１法人が選択される。一方、選択する対象となる法人が残っていない場合、ステップＳ３０の判定はＮＯとなり、図７ＡのステップＳ１９に移行する。ステップＳ１９に移行させるのは、ＵＢＯと決定された人が存在しない可能性があるためである。

【0100】

このように、ＵＢＯ特定部１１３は、資本関係を辿ってのＵＢＯの特定も必要に応じて行う。それにより、図５に示すような資本関係では、「埼玉一郎」及び「千葉二郎」に加え、古河商事株式会社を介して久喜株式会社に間接的に資本を投入している「東京太郎」も第２順位のＵＢＯとして特定されることになる。「東京太郎」は、ステップＳ１５の判定をＹＥＳとさせないことから、ステップＳ２９で第２順位と決定される。この特定結果は、ファイルＦ４としてファイル化され、記憶部１８に確保された中間結果格納部１８２に格納される。指定国の言語表現のための企業コードとしては、久喜株式会社の企業コードの他に、古河商事株式会社の企業コードが特定され、ＵＢＯ特定部１１３から国コードとともに情報要求部１１４に渡される。

【0101】

情報要求部１１４は、ＵＢＯ特定部１１３から渡された全ての企業コードを国コードとともに振分部１１１に渡し、振分部１１１を介して、対応する国別企業情報の提供を情報提供会社ＪＫのＷｅｂサーバ３に要求する。対象企業が久喜株式会社であり、その久喜株式会社に図５に示すような資本関係が存在していた場合、ＵＢＯ特定部１１３から渡される企業コードは、久喜株式会社、古河商事株式会社の２社の企業コードとなる。この情報要求部１１４は、本実施形態における第３の取得手段に相当する。

【0102】

その要求により、Ｗｅｂサーバ３は、国コードに対応する国別企業情報ＤＢＫＫに対し、受信した企業コードをそれぞれキーとする検索を行い、企業コードの数分の国別企業情報を抽出する。そのようにして抽出された国別企業情報がファイルＦ５としてファイル化され、Ｗｅｂサーバ３からＡＰサーバ１に送信される。

【0103】

図８は、国別企業情報の構成例を説明する図である。なお、この構成例は１例であり、国別企業情報の構成例は図８に示すようなものに限定されない。
この図８は、図５に示すような資本関係が存在する久喜株式会社が対象法人であり、且つ指定国が日本であった場合、ファイルＦ５としてまとめられる国別企業情報の構成例を示している。図８に示すように、国別企業情報は、企業コード、社名、主株主、代表者名、代表者名（カナ）、及び代表者住所の各情報を含む。指定国が日本であることから、企業コード以外は全て日本語表現の情報となっている。

【0104】

国別企業情報中の主株主は、主な株主毎に、その株主の名称、及び直接保有比率を表す情報である。主な株主は、ＵＢＯと特定される可能性のある株主である。そのような株主に限定することにより、主株主とする情報の量が膨大になるのを回避するようにしている。直接保有比率は、名称に続く括弧内の情報として表されている。

【0105】

上記のように、ＵＢＯとして、法人の代表者を特定する場合がある。このことから、２種類の代表者名、及び代表者住所が国別企業情報に含まれている。
Ｗｅｂサーバ３から送信されたファイルＦ５は、通信部１９によって受信され、ＣＰＵ１１に入力される。その結果、ファイルＦ５は、振分部１１１を介して情報要求部１１４に渡される。情報要求部１１４は、ファイルＦ５を情報入力部１１５に渡すか、或いはその存在を通知する。

【0106】

情報入力部１１５は、ファイルＦ４、及びＦ５を参照して、特定されたＵＢＯに対応する指定国の言語表現を特定し、その特定結果の確認、及び修正用の画面（Ｗｅｂページ）を作成する。この画面は、指定国の言語（公用語）に応じて作成されるものである。つまり、この画面は、指定国の言語が企業情報の言語と異なっている場合に作成される。
この画面には、特に図示しないが、例えば特定したＵＢＯ毎に、言語表現の特定結果に加え、ファイルＦ４から抽出したＵＢＯの名称（英語表記）、並びにファイルＦ５から抽出した主株主（主な株主の名称等が含まれる）、及び２種類の代表者名等が配置されている。言語表現の特定結果は、ＵＢＯの名称（英語表現）に対応付けられた株主の名称、或いは代表者名である。株主の名称、及び代表者名はともに、指定国の言語による言語表現である。言語表現の特定結果を配置することにより、その画面上にＵＢＯの名称の他の言語表現が自動入力された形となっている。なお、指定国が日本であった場合、言語表現の特定結果は、例えばＵＢＯの漢字表記、及びカナ表記の２つである。

【0107】

このような画面の作成後、情報入力部１１５は、例えば処理側端末２を使用する従業員を対象に、特定したＵＢＯの言語表現の確認を促す通知のための処理を行うとともに、その言語表現の確認対象となるＵＢＯの特定結果をアクセス可能に公開する。それにより、情報入力部１１５は、公開したＵＢＯの特定結果へのアクセスを要求した処理側端末２に、作成した画面を送信させる。その画面の送信は、情報入力部１１５から振分部１１１に画面、及び処理側端末２のアドレスを渡し、そのアドレス宛に画面を通信部１９に送信させることで実現される。

【0108】

そのようにして送信された画面を受信した処理側端末２は、受信した画面を表示装置上に表示させる。それにより、従業員は、画面上でＵＢＯの言語表現を確認し、必要に応じて、その言語表現を修正する。その画面上に配置された指定国の言語表現の主株主、及び代表者名は、指定国の言語でＵＢＯの名称とする言語表現の候補である。このため、従業員は、言語表現の特定結果の適切な確認、更には適切な修正も容易に行うことができる。ファイルＦ４、Ｆ５からの抽出を通して、画面上に配置する情報の量を抑えたのは、特定結果の適切な確認、及び適切な修正を従業員がより容易に行えるようにするためである。必要に応じて修正が行われた画面の内容は、従業員の送信指示により、処理側端末２からＡＰサーバ１に送信される。

【0109】

その画面の内容は、通信部１９により受信され、ＣＰＵ１１に入力される。それにより、その内容は、振分部１１１を介して情報入力部１１５に渡される、情報入力部１１５は、渡された内容を用いて、ファイルＦ４に内容を追加する合成用のファイルＦ６を作成し、作成したファイルＦ６を合成部１１６に渡すか、或いはその存在を通知する。

【0110】

なお、従業員による言語表現の確認、及び修正は、画面の代わりに作成するファイルにより行わせるようにしても良い。言語表現の特定は行わずに、つまり指定国の言語表現の自動入力は行わずに、ＵＢＯの氏名を従業員に入力させるようにしても良い。そのようにしても、指定国の言語でＵＢＯの名称とする言語表現の候補が配置されていることから、従業員は適切な言語表現を容易に入力することができる。

【0111】

合成部１１６は、ファイルＦ６の内容をファイルＦ４に加える合成を行う。この合成では、指定国の言語表現ではない言語表現は、指定国の言語表現に置き換えられる。例えば企業コード以外の全ての情報が指定国の言語表現の情報に置き換えられる。国別企業情報中の社名は、企業コードにより対応付けられ、ファイルＦ４内に情報として格納されている社名として更新される。そのような合成後のファイルＦ４が納品用のファイルＦ２として、記憶部１８に確保された特定結果格納部１８３に格納される。なお、指定国の言語表現に置き換える必要がない場合、つまり企業情報ＤＢＫＪの言語と指定国の言語とが一致する場合、ファイルＦ４がファイルＦ２とされる。

【0112】

図９は、納品されるファイルの内容例を説明する図である。図９に示す内容例は１例であり、納品されるファイルであるファイルＦ２の内容例は図９に示すようなものに限定されない。例えば、元のファイルＦ４の社名、及びＵＢＯの名称等を残したものであっても良い。
図９に内容例を示すファイルＦ２は、図８と同様に、図５に示すような資本関係が存在する久喜株式会社が対象法人であり、且つ指定国が日本であった場合のものである。図９に示すように、ファイルＦ２は、特定したＵＢＯ毎に、企業コード、社名、ＵＢＯ候補名、ＵＢＯ候補名（カナ）、及びＵＢＯ判定結果の各情報をＵＢＯ情報として表す構成となっている。

【0113】

ＵＢＯ情報中のＵＢＯ判定結果は、ＵＢＯが属すると分類したカテゴリを示す情報である。漢字表記、及びカナ表記の２種類のＵＢＯ候補名は、法人では代表者をＵＢＯと特定することから、個人名である。この２種類のＵＢＯ候補名が、従業員の確認を必要とする言語表現である。カナ表現のＵＢＯ候補名の括弧書きは、特定した言語表現、つまり従業員による修正が行われる前の言語表現である。図９では、修正前の言語表現を併せて示すことにより、従業員の確認による言語表現の修正内容を確認可能とさせている。なお、社名は、企業コードにより一意に特定できるため、従業員による確認の対象外である。

【0114】

出力処理部１１７は、特定結果格納部１８３に格納されたファイルＦ２の出力に係わる処理を行う機能である。この出力処理部１１７により、処理側端末２を使用する従業員は、特定結果格納部１８３に格納された任意のファイルＦ２をＡＰサーバ１から取得することができる。また、この出力処理部１１７により、リムーバブルメディア２５へのファイルＦ２の書き込み、及び出力部１６へのファイルＦ２の出力も可能となっている。この出力処理部１１７は、本実施形態における出力手段に相当する。

【0115】

なお、本実施形態では、ＵＢＯを３つのカテゴリに分け、ＵＢＯが属するカテゴリの決定を通して、ＵＢＯの特定を行うような形となっている。しかし、ＵＢＯの特定は、カテゴリの決定ではなく、受益率により行うようにしても良い。欧州基準とは異なる基準の受益率であっても、対象法人から資本関係を辿ることにより算出することができる。この受益率は、決定したカテゴリとともに、或いはそのカテゴリに代えて、ＵＢＯ情報に含めても良い。

【0116】

国別企業情報は、図８に示すように、法人の主株主を確認可能な情報である。このことから、ステップＳ２２では、企業情報中に必要な情報が存在していない場合を想定し、企業情報の他に、国別企業情報も参照して、対象とする法人の株主を確認するようにしても良い。このことから、国別企業情報は、株主の確認のために取得するようにしても良い。主株主が法人であれば、企業コードも確認可能に追加させるようにしても良い。

【0117】

本実施形態では、情報提供会社ＪＫに対して本サービスを提供する形となっているが、顧客Ｃを対象に本サービスを提供するようにしても良い。その提供方法としては、例えば以下のようなものが考えられる。
図１０は、本発明の情報処理装置の一実施形態の変形例に係るＡＰサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。

【0118】

図１０に示すように、この変形例は、情報サービス会社ＳＫが顧客Ｃに対して直接、本サービスを提供するためのものである。そのために、ＡＰサーバ１は、Ｗｅｂサーバの機能を備えるか、或いはネットワークＮとＡＰサーバ１との間の通信に介在するＷｅｂサーバが存在する。このことから、ＡＰサーバ１は、通信部１９を２つ以上、備えている。処理側端末２は、受付側端末４の用途にも用いられる。情報提供会社ＪＫには、情報サービス会社ＳＫに必要な情報を提供するために、Ｗｅｂサーバ３の代わりにＤＢサーバ６が設置されている。
このような構成により、顧客Ｃは、本実施形態と同様のサービスを利用することができる。

【0119】

企業情報ＤＢＫＪ、及び国別企業情報ＤＢＫＫは、情報サービス会社ＳＫ側で用意しても良い。そのようにする場合、情報提供会社ＪＫは不要となる。また、企業情報ＤＢＫＪ、及び国別企業情報ＤＢＫＫの必要な情報は、顧客Ｃへのサービスの提供とは無関係の会社等から取得するようにしても良い。本実施形態では、既存のＤＢは、企業情報ＤＢＫＪのみであるが、既存のＤＢは複数であっても良い。複数の既存のＤＢは、複数の会社等がそれぞれ管理する１つ以上のＤＢによって得られるものであっても良い。

【0120】

ＵＢＯの特定は、指定国の定義に沿って行う必要があり、受益率を考慮する必要がある。図７Ａ、図７Ｂにフローチャートの例を示すＵＢＯ特定処理は、欧州の定義に沿って算出された受益率が情報として企業情報に含まれていることもあり、日本の定義を重視したものとし、日本の定義での受益率の算出は不要となっている。つまり処理の流れのなかで日本の定義に沿って受益率を特定し、ＵＢＯを決定できる形となっている。上記のように、受益率を算出するのに必要な情報は企業情報内に存在する。これらのようなこともあり、受益率情報自体は必須の情報ではなく、受益率の特定も算出することに限定されない。そのため、企業情報は、受益率情報が含まれていないものであっても良い。それにより、ＵＢＯ特定処理としては、受益率情報が企業情報中に存在することを前提とするもの、企業情報中の受益者情報を用いないもの、つまり企業情報中の受益者情報の有無に依存しないもの、及び企業情報中に存在する受益者情報は利用するもの、の何れであっても良い。受益率情報が存在しない場合、指定国以外の国の定義に沿った受益率を算出するようにしても良い。つまり、受益率を算出、或いは特定する国は複数であっても良い。上記実施形態では、例えば日本、欧州のそれぞれで受益率を算出するようにしても良い。何れにしても、ＵＢＯは指定国の定義に沿って決定する必要があることから、指定国の定義に沿って受益率を特定する必要がある。

【0121】

（第２実施形態）
図１１は、本発明の情報処理装置の第２実施形態に係るＡＰサーバによるサービスの提供のために構築されたシステム、及びそのシステムが接続されたネットワーク環境の例を説明する図である。

【0122】

第２実施形態では、図１１に示すように、顧客Ｃからリクエストとして送信される依頼の処理を情報サービス会社ＳＫ自体が行うようになっている。それにより、情報サービス会社ＳＫは、上記第１実施形態とは異なり、単体で本サービスを提供する。つまり、情報サービス会社ＳＫは、顧客Ｃからの依頼の処理、その依頼のために送信されたファイルＦ１の従業員による確認、各ＤＢからの必要な情報の抽出、及びファイルＦ２の顧客Ｃへの納品等を行う。そのために、情報サービス会社ＳＫには、ＡＰサーバ１の他に、端末２、Ｗｅｂサーバ３、及びＤＢサーバ６が存在し、それらがＬＡＮ等のネットワーク７により接続されている。

【0123】

端末２、Ｗｅｂサーバ３、及びＤＢサーバ６は、何れも上記したような使い方がされるか、或いは機能が搭載されたものである。このことから、それらには同じ符号を付している。ここでは、再度の詳細な説明は省略する。なお、ＡＰサーバ１、Ｗｅｂサーバ３、及びＤＢサーバ６の各ノードは、クラウドサービスにより設置されたものであっても良い。それにより、各ノードの設置場所、所有者等は特に限定されない。

【0124】

図１２は、本発明の情報処理装置の第２実施形態に係るＡＰサーバ上に実現される機能的構成の一例を示す機能ブロック図である。次に図１２を参照し、上記第１実施形態におけるＡＰサーバ１との相違に着目した説明を行う。
第２実施形態では、図１２に示すように、ＤＢサーバ６には図１に示すストレージＳＴが搭載されている。このストレージＳＴには、国別企業情報ＤＢＫＫの他に、第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮが企業情報ＤＢＫＪの代わりに構築されている。ここでＮは、２以上の整数であり、具体的な値は特に限定されない。

【0125】

これら第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮは、例えば複数の情報会社から提供されたものであり、各情報ＤＢＫＪ１～ＫＪＮには、想定した国でのＵＢＯの定義に沿って企業情報が格納されている。１レコードに格納された企業情報の内容は同じか、或いはほぼ同じである。

【0126】

上記第１実施形態で用いられる企業情報ＤＢＫＪは、例えば欧州でのＵＢＯの定義に沿ったものであり、使用されている言語は英語である。ＵＢＯの定義は、上記のように、全ての国で同じではない。例えば欧州でのＵＢＯの定義は、日本と異なるだけでなく、米国とも異なる。その一方、多くの国では、直接投資が可能である。このようなことから、本実施形態では、第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮのうちで企業情報の抽出に用いるものを選択し、ＵＢＯを特定するようにしている。第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮのうちからＵＢＯの定義が異なる複数のＤＢを選択する可能性があることから、第２実施形態でも第１実施形態と同様に、ＵＢＯの定義に沿った受益率の算出を必要に応じて行うようになっている。以降、第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮのうちの任意の情報ＤＢを指す意味で「企業情報ＤＢＫＪ」を用いることとする。

【0127】

第２実施形態では、図１２に示すように、第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮは、ＤＢサーバ６によって管理される。そのため、ＡＰサーバ１は、ＤＢサーバ６から必要な企業情報を随時、取得するようになっている。
この企業情報の取得は、情報要求部１１４によって行われる。情報要求部１１４は、ＵＢＯ特定部１１３の指示に従って、例えばＵＢＯ特定部１１３が企業コード等で指定する企業情報の取得のためのリクエストを生成し振分部１１１に渡す。

【0128】

そのリクエストは、ＣＰＵ１１から通信部１９に出力され、ＤＢサーバ６に送信される。この結果、ＤＢサーバ６は、そのリクエストで指定された企業情報を対応する企業情報ＤＢＫＪから抽出してＡＰサーバ１に送信する。ＡＰサーバ１に受信された企業情報は、通信部１９からＣＰＵ１１に出力され、振分部１１１を介して情報要求部１１４に渡され、更にＵＢＯ特定部１１３に渡される。このようなことから、第２実施形態では、ＵＢＯ特定部１１３は、情報要求部１１４を制御し、必要な企業情報を随時、ＤＢサーバ６から取得し、ＵＢＯの特定を行うようになっている。

【0129】

第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮのそれぞれは、カバーする範囲が異なるのが普通である。これは、第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮのうちの何れかを提供する各情報会社の調査能力、及び調査可能範囲等が異なるからである。カバーする範囲が異なることから、第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮのうちで企業情報を参照する企業情報ＤＢＫＪを必要に応じて切り換えることにより、必要な企業情報を参照できる可能性はより高くなる。これは、ＵＢＯを特定できる可能性もより高くなることを意味する。国によるＵＢＯの定義の違いに対応することにより、上記のように、ＵＢＯの特定は適切に行うことができる。これらのことから、第２実施形態では、第１実施形態と比較し、ＵＢＯの適切な特定をより高い確率で行えるようになる。

【0130】

図１３～図１５は、第２実施形態におけるＵＢＯ特定処理の例を示すフローチャートである。ＵＢＯ特定処理は、第１実施形態と同じく、１対象法人のＵＢＯの特定のためにＵＢＯ特定部１１３によって実行される部分を抽出して、その部分の処理の流れの例を表したものである。ここで図１３～図１５を参照し、第２実施形態におけるＵＢＯ特定処理について詳細に説明する。処理を実行する主体としてはＵＢＯ特定部１１３を想定する。

【0131】

第２実施形態でも、第１実施形態と同じく、ＵＢＯの法人への一般的に予測される影響力の強さから複数のカテゴリに分け、ＵＢＯを特定するとともに、そのＵＢＯが属するカテゴリも併せて特定するようにしている。また、第２実施形態では、ＵＢＯの種別を表す情報を保存するようにしている。図１３～図１５に表記の「種別フラグ」は、その情報の保存のために用意した変数である。図１３～図１５では、第１実施形態と同じか、或いは基本的に同じ内容の処理には同一の符号を付している。それにより、ここでは、第１実施形態から異なる部分に着目するかたちで説明を行う。

【0132】

この種別フラグには、対象法人が国、或いは地方公共団体等であった場合には１が代入され、上場企業であった場合には２が代入される。対象法人の代表者をＵＢＯと特定した場合、３～５の間の整数値が代入される。具体的には、株主情報、及び保有比率情報の両方があってＵＢＯと特定された代表者には３、株主情報があっても保有比率情報がなく、ＵＢＯと特定された代表者には４、株主情報がないことによりＵＢＯと特定された代表者には５、がそれぞれ代入される。また、資本関係を辿り、ＵＢＯと特定された国、或いは地方公共団体には６、ＵＢＯと特定されたのが上場企業であれば７がそれぞれ代入される。ＵＢＯと特定された個人には８が代入される。このようなことから、種別フラグに設定される値は、第２実施形態における特定理由情報に相当する。

【0133】

このような値を種別フラグに代入し、その値を確認可能にすることにより、顧客Ｃにとっては、ＵＢＯと特定された理由を知ることができる。種別フラグの値が４、或いは５であった場合、特定されたＵＢＯとは異なる法人、或いは個人が実際のＵＢＯである可能性があることになる。このことから、種別フラグは、特定されたＵＢＯの信頼度を表す情報ともなっている。それにより、種別フラグは、本サービスの質をより高くする情報となっている。

【0134】

先ず、ステップＳ１１では、ＵＢＯ特定部１１３は、指定国に対応する条件情報を条件情報格納部１８１から読み出し、ＵＢＯを特定するうえでの条件α～γを設定する。続くステップＳ５１では、ＵＢＯ特定部１１３は、指定国に応じて、企業情報を抽出する企業情報ＤＢＫＪを設定する。それにより、例えば指定国が日本であれば、ＵＢＯ特定部１１３は、第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮのうちから、日本でのＵＢＯの定義に沿って構築された企業情報ＤＢＫＪを選択し設定する。

【0135】

ステップＳ５１の次に移行するステップＳ５２では、ＵＢＯ特定部１１３は、対象法人が特定法人か否か判定する。対象法人が特定法人であった場合、ステップＳ５２の判定はＹＥＳとなってステップＳ５３に移行する。対象法人が特定法人でなかった場合、ステップＳ５２の判定はＮＯとなってステップＳ５４に移行する。
ステップＳ５３では、ＵＢＯ特定部１１３は、対象法人はＵＢＯを特定する対象外と決定し、対象法人に応じて、種別フラグに１、或いは２を設定（代入）する。その後は図１５のステップＳ１９に移行する。

【0136】

このようにして、第２実施形態では、特定法人である対象法人にも対応するようにしている。そのため、顧客Ｃは、対象法人が特定法人か否かを確認しなくとも良いことになる。従って、顧客Ｃにとっては、第１実施形態と比較し、ＵＢＯ情報を得るための作業の負荷がより軽減することになる。

【0137】

ステップＳ５４では、ＵＢＯ特定部１１３は、ステップＳ５１で設定した企業情報ＤＢＫＪに、対象法人の資本関係を辿るうえで有効な情報がないか否か判定する。その企業情報ＤＢＫＪに、対象法人の資本関係を辿る必要性を示す情報が存在しないか、或いは対象法人の資本関係を辿ることを可能にする情報が存在しない場合、ステップＳ５４の判定はＹＥＳとなってステップＳ５５に移行する。対象法人の資本関係を辿るうえで有効な情報が存在する場合、ステップＳ５４の判定はＮＯとなってステップＳ１２に移行する。

【0138】

選択可能な企業情報ＤＢＫＪのレコード構成は全て同じとは限らない。そのため、有効な情報は、レコード構成によって変化する。具体的には、図６に示すように、１対象法人で企業情報が株主毎に１レコードとして抽出される企業情報ＤＢＫＪでは、有効な情報とは、条件γを少なくとも満たすことを示す保有比率情報、及び株主情報が存在する企業情報のことである。条件γを満たすことを示していない保有比率情報、及び株主情報が存在する企業情報は、有効な情報とは見なされない。株主情報、及び保有比率情報のうちの少なくとも一方が存在しない企業情報も有効な情報とは見なされない。
一方、１対象法人で企業情報が１レコードとして抽出され、その企業情報中に株主毎の受益者関係情報が存在する企業情報ＤＢＫＪでは、有効な情報とは、条件γを少なくとも満たすことを示す保有比率情報、及び株主情報が存在する受益者関係情報のことである。条件γを満たすことを示していない保有比率情報、及び株主情報が存在する受益者関係情報は、有効な情報とは見なされない。株主情報、及び保有比率情報のうちの少なくとも一方が存在しない受益者関係情報も有効な情報とは見なされない。
ここでは、混乱を避けるために、選択可能な企業情報ＤＢＫＪの全ては、１レコードに、受益者関連情報が一つのみ存在する企業情報（図６参照）が格納されているものと想定する。選択可能な企業情報ＤＢＫＪのレコード構成は特に限定されない。

【0139】

ステップＳ５５では、ＵＢＯ特定部１１３は、対象法人の株主情報がないか否か判定する。対象法人の株主情報がある企業情報がなく、株主を特定できない場合、ステップＳ５５の判定はＹＥＳとなってステップＳ５６に移行する。対象法人の株主情報がある企業情報が存在する場合、ステップＳ５５の判定はＮＯとなってステップＳ５７に移行する。

【0140】

ステップＳ５６では、ＵＢＯ特定部１１３は、対象法人の代表者を第４順位に決定し、種別フラグに５を設定する。その後、図１５のステップＳ１９に移行する。
一方、ステップＳ５７では、ＵＢＯ特定部１１３は、対象法人の代表者を第４順位に決定し、保有比率情報の有無に応じて、種別フラグに３、或いは４を設定する。上記のように、保有比率情報が企業情報に存在する場合は３、保有比率情報が企業情報に存在しない場合は４が種別フラグに設定される。種別フラグの設定後は、図１５のステップＳ１９に移行する。

【0141】

ステップＳ５４の判定がＮＯとなって移行するステップＳ１２、及び続くステップＳ１３～Ｓ１８の各処理内容は、第１実施形態と同じか、或いはほぼ同じである。しかし、ステップＳ１４、Ｓ１６では、ＵＢＯ特定部１１３は、個人を第１順位、或いは第２順位に決定することから、何れでも種別フラグに８を設定するようになっている。また、ステップＳ１８では、ＵＢＯ特定部１１３は、条件γを満たす法人があるか否かの判定を行う。これは、選択中の企業情報ＤＢＫＪに格納された企業情報に受益者インジケーターが存在するとは限らないからである。第１実施形態からの相違は、基本的にはこれだけである。第２実施形態では、ステップＳ１８の判定がＮＯとなった場合、図１５のステップＳ１９に移行し、ステップＳ１８の判定がＹＥＳとなった場合、図１４のステップＳ２２に移行する。

【0142】

図１４のステップＳ２２～Ｓ３０では、第１実施形態から以下の点が異なる。
第２実施形態では、ＡＰサーバ１が必要な企業情報を随時、ＤＢサーバ６から取得するようになっている。このことから、ステップＳ２３での企業情報の参照は、ステップＳ２２で選択した法人の企業情報をＤＢサーバ６から取得して行われる。この企業情報の取得は、例えばステップＳ２２で選択した法人の企業コードを含むコマンドを情報要求部１１４に生成させ、ＤＢサーバ６に送信させることで実現される。

【0143】

また、第２実施形態では、ステップＳ２４の判定がＮＯとなった場合に、ステップＳ６１に移行する。そのステップＳ６１では、ＵＢＯ特定部１１３は、ステップＳ２２で選択した法人で資本関係を辿るのを可能にする株主情報が存在しないか否か判定する。株主情報が全く存在しないか、或いは存在するとしても、資本関係を辿るべき可能性が考えられる株主情報が不足している場合、ステップＳ６１の判定はＹＥＳとなってステップＳ６２に移行する。株主情報に不足がない場合、ステップＳ６１の判定はＮＯとなってステップＳ３０に移行する。

【0144】

ステップＳ６２では、ＵＢＯ特定部１１３は、ステップＳ２２で選択した法人を再確認対象に設定する。この再確認対象の設定後、ステップＳ３０に移行する。
ステップＳ２２で選択した法人の企業情報中の株主情報は、現在、設定（選択）中の企業情報ＤＢＫＪに格納されている企業情報には存在していなくとも、別の企業情報ＤＢＫＪに格納されている企業情報には存在する可能性がある。その可能性から、ＵＢＯの特定をより高精度に行うためには、別の企業情報ＤＢＫＪに格納されている企業情報も確認する必要がある。第２実施形態では、別の企業情報ＤＢＫＪに格納されている企業情報を確認すべき法人を再確認対象として管理し、別の企業情報ＤＢＫＪに格納されている企業情報を確認すべき法人を制限している。

【0145】

図１４のステップＳ２２～Ｓ３０では、更に、ステップＳ２８、及びＳ２９で種別フラグに６～８のうちの何れかを設定するようになっている。ステップＳ２８、及びＳ２９は、ステップＳ２６でのＹＥＳの判定により実行される可能性がある。それにより、ＵＢＯと特定されるのは、個人、国、若しくは地方公共団体、或いは上場企業のうちの何れかである。そのため、ステップＳ２８、及びＳ２９では、種別フラグに６～８のうちの何れかが設定される。

【0146】

図１４のステップＳ２２～Ｓ３０では、第１実施形態から上記のような点が異なる。第２実施形態でも、ステップＳ３０の判定がＮＯとなった場合、図１５のステップＳ１９に移行する。次にステップＳ１９以降の処理について詳細に説明する。このステップＳ１９には、ステップＳ５３、Ｓ５６、或いはＳ５７の処理の実行後にも移行する。
ステップＳ１９では、ＵＢＯ特定部１１３は、対象法人のＵＢＯが決定済みか否か判定する。ＵＢＯが決定済みであった場合、ステップＳ１９の判定はＹＥＳとなってステップＳ２１に移行する。ＵＢＯが決定済みでない場合、ステップＳ１９の判定はＮＯとなってステップＳ７１に移行する。

【0147】

ステップＳ７１では、ＵＢＯ特定部１１３は、未確認の再確認対象があるか否か判定する。未確認の再確認対象が存在する場合、ステップＳ７１の判定はＹＥＳとなってステップＳ７５に移行する。未確認の再確認対象が存在しない場合、ステップＳ７１の判定はＮＯとなってステップＳ７２に移行する。

【0148】

ステップＳ７２への移行は、ＵＢＯを特定するための処理がこれ以上、行えないことを意味する。このことから、ステップＳ７２～Ｓ７４では、上記ステップＳ５５～Ｓ５７と同様に、対象法人の代表者を第４順位に決定し、株主情報の有無、更には保有比率情報の有無に応じて、種別フラグに３～５のうちの何れかを設定するための処理が行われる。その処理の終了後、つまりステップＳ７３、或いはＳ７４の処理の実行後はステップＳ３１に移行する。

【0149】

ステップＳ５５への移行は、ステップＳ５４の判定がＹＥＳとなることが条件である。これに対し、ステップＳ７２への移行は、ステップＳ５４の判定がＮＯとなることが条件である。それにより、ステップＳ７２～Ｓ７４の処理は、ステップＳ１２以降の処理を実行しても、第１順位、及び第２順位の何れかに決定されるＵＢＯが特定できなかった場合を想定したものとなっている。

【0150】

一方、ステップＳ７５では、ＵＢＯ特定部１１３は、再確認対象の企業情報を確認するために設定すべき企業情報ＤＢＫＪの確認を行う。続くステップＳ７６では、設定すべき企業情報ＤＢＫＪが存在するか否か判定する。設定すべき企業情報ＤＢＫＪが存在する場合、ステップＳ７６の判定はＹＥＳとなってステップＳ７７に移行し、ＵＢＯ特定部１１３は、存在を確認した企業情報ＤＢＫＪを参照の対象とするＤＢに決定し設定する。その後は図１３のステップＳ１２に戻る。それにより、新たに設定した企業情報ＤＢＫＪを対象にしたＵＢＯの特定が継続して行われる。

【0151】

一方、設定すべき企業情報ＤＢＫＪが存在しない場合、ステップＳ７６の判定はＮＯとなってステップＳ７７に移行し、ＵＢＯ特定部１１３は、第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮによりＵＢＯを特定できない旨を表すアラートを付与する。その後はステップＳ２１に移行する。

【0152】

付与するアラートは、ＵＢＯを特定するうえで必要な企業情報が不足していることを示している。このことから、付与するアラートは、第２実施形態における警告情報に相当する。このようなアラートを付与することにより、情報サービス会社ＳＫの従業員、及び顧客Ｃは、ＵＢＯが特定されなかった理由を認識することができる。

【0153】

設定すべき企業情報ＤＢＫＪとは、例えば再確認対象と設定の法人が設立された国か、或いはその国との経済的なつながりの深い国等の情報会社によって提供される企業情報ＤＢＫＪである。このことから、設定すべき企業情報ＤＢＫＪは、再確認対象毎に特定されるものであり、設定すべき企業情報ＤＢＫＪが複数、存在する場合もあり得る。また、新たに設定した企業情報ＤＢＫＪでも、再確認対象を設定する可能性がある。このようなことから、第２実施形態では、第１企業情報ＤＢＫＪ１～第Ｎ企業情報ＤＢＫＪＮのうちで参照する企業情報ＤＢＫＪを必要に応じて切り換えながら、第１順位、或いは第２順位のＵＢＯの特定（探索）を行うようになっている。ＵＢＯの特定は、第１順位、第２順位、或いは第４順位であるＵＢＯを特定するか、或いはＵＢＯを特定できないことが確認できた場合に終了する。ＵＢＯを特定できないことが確認できた場合とは、ＵＢＯを特定する前に、設定すべき企業情報ＤＢＫＪがないことが確認できた場合、つまりステップＳ７６の判定がＮＯとなった場合である。

【0154】

ステップＳ２１では、ＵＢＯ特定部１１３は、指定国の定義でＵＢＯの特定結果を操作する。操作した後の特定結果、種別フラグ、及び付与したアラート等を中間結果格納部１８２に保存した後、ＵＢＯ特定処理が終了する。

【0155】

このようなＵＢＯ特定処理をＵＢＯ特定部１１３が実行した結果、ＵＢＯを特定できた場合、第１実施形態と同様に、情報要求部１１４には、ＵＢＯ特定部１１３から企業コードが渡される。それにより、情報要求部１１４は、渡された企業コード、及び指定国の国コードを用いて、国別企業情報ＤＢＫＫから国別企業情報をＤＢサーバ６に抽出させるためのコマンドを生成する。第２実施形態では、このコマンドのＤＢサーバ６への送信により、第１実施形態ではファイルＦ５に格納される国別企業情報がＤＢサーバ６から取得される。国別企業情報を取得してからファイルＦ２を生成するまでの処理の内容は、第１実施形態と同じか、或いはほぼ同じである。このことから、その処理の内容、つまり情報入力部１１５、及び合成部１１６についての説明は省略する。

【0156】

第２実施形態では、顧客Ｃと情報サービス会社ＳＫとの間に情報提供会社ＪＫが介在しないことから、顧客Ｃから直接、依頼を受けるだけでなく、ファイルＦ２を直接、顧客Ｃに送信するようになっている。しかし、依頼の受信、及びファイルＦ２の顧客Ｃへの送信はともに、Ｗｅｂサーバ３を介して行われる。このことから、依頼の受信、及びファイルＦ２の顧客Ｃへの送信の何れも、第１実施形態と同様に行われる。

【0157】

第２実施形態では、資本関係を辿るうえで必要な株主情報が不足している可能性が考えられる企業情報があった場合、その企業情報が作成された法人を再確認対象に設定し、別の企業情報ＤＢＫＪの企業情報を確認するようにしている。それにより、第２実施形態では、設定している企業情報ＤＢＫＪを切り換えるまで、再確認対象とする法人の設定を継続して行い、企業情報ＤＢＫＪの設定の切り換えにより、再確認対象と設定した法人の企業情報を確認するようになっている。

【0158】

しかし、企業情報ＤＢＫＪの設定の切り換え方は、これに限定されない。例えば再確認対象と設定する法人の存在を確認できた時点で、その法人の企業情報を別の企業情報ＤＢＫＪで確認し、その確認結果に応じて、ＵＢＯの特定を継続させるようにしても良い。このことから、参照可能と選択する企業情報ＤＢＫＪは、企業情報ＤＢＫＪを切り換えるとしても、複数の企業情報ＤＢＫＪを参照可能な状態とさせても良い。参照可能とする企業情報ＤＢＫＪの選択については、再確認対象と設定した法人に応じて選択するのではなく、法人に関わらず、例えば順次、設定した順序に沿って選択するようにしても良い。このようなこともあり、企業情報ＤＢＫＪの選択の仕方についても特に限定されない。

【0159】

各企業情報ＤＢＫＪに格納される企業情報の構成は、上記のように、特に限定されない。つまり企業情報は、例えば受益者情報、保有比率情報、及び受益率情報を含む受益者関係情報、並びに企業識別情報が含まれるものであれば良い。このことから、個人に着目した構成の企業情報を格納させたＤＢを企業情報ＤＢＫＪの代わりに、或いは企業情報ＤＢＫＪとともに用いるようにしても良い。このようなことから、ＤＢの用意でも各種変形が可能である。

【0160】

第２実施形態では、ＵＢＯの特定に必要な企業情報が存在しないことをアラートの付与により確認可能にさせているが、アラートの付与以外の方法により、確認可能にさせても良い。例えばフラグ、或いはメッセージ等で確認可能にさせても良い。このようなこともあり、警告情報の生成の仕方は、特に限定されない。これは、種別フラグでも同様である。種別フラグに設定可能な値、及びその値の数等は、特に限定されない。それにより、例えば種別フラグを複数、用意し、種別フラグ毎に、その種別フラグで表す情報の種類を決定するようにしても良い。確認可能にする情報の数分、種別フラグのようなフラグを用意しても良い。種別フラグへの値の設定に代えて、或いは種別フラグへの値の設定とともに、メッセージの決定（生成）、或いは種別フラグに値を設定させた企業情報の抽出等を行うようにしても良い。このようなことから、特定理由情報の生成の仕方、及び保存の仕方等は特に限定されない。

【符号の説明】

【0161】

１ＡＰサーバ、２、４、５端末、３Ｗｅｂサーバ、６ＤＢサーバ、１１ＣＰＵ、１８記憶部、１１１振分部、１１２依頼処理部、１１３ＵＢＯ特定部、１１４情報要求部、１１５情報入力部、１１６合成部、１１７出力処理部、Ｃ顧客、ＪＫ情報提供会社、ＫＪ企業情報ＤＢ、ＫＫ国別企業情報ＤＢ、ＳＫ情報サービス会社、ＳＴストレージ。

【図1】