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

Abstract

【課題】保険に関する役務の複数の提供者を繋ぐハブとなる機能を実現させること。【解決手段】サービス提供者サーバ１は、保険会社Ｈの保険会社既存システムＨＳや代理店Ｄの担当者端末ＤＴ等と通信をする。顧客情報管理部５１は、保険の加入者又は加入の候補者を顧客として、当該顧客に関する情報を第１種顧客情報として保険ＤＢ７１に格納して管理する。保険会社Ｈの保険会社既存システムＨＳには、所定情報の入力をトリガとして、保険会社既存システムＨＳにより管理されている顧客に関する第２種顧客情報を出力する保険ＡＰＩが、保険会社既存システムＨＳに構築されている。保険ＡＰＩ制御部５３は、所定情報を保険会社既存システムＨＳに送信することで第２種顧客情報を取得する制御を実行する。【選択図】図７

Description

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

従来より、保険に関する役務の提供者（保険会社や代理店等）を支援するための技術は提案されている（例えば、特許文献１参照）。

特開２００２－２３３２００号公報

しかしながら、複数の保険会社の夫々により提供される保険を組み合わせた保険商品を代理店が取り扱う等、保険に関する役務の提供者として複数人が関与することが一般的である。
このため、保険に関する役務の複数の提供者を繋ぐハブとなる機能の実現が要求されているが、特許文献１を含め従来の技術では、このような要求に応えることができない状況である。

本発明は、このような状況を鑑みてなされたものであり、保険に関する役務の複数の提供者を繋ぐハブとなる機能を実現させることを目的とする。

上記目的を達成するため、本発明の一態様の情報処理装置は、
保険に関する役務の提供者の他情報処理装置と通信をする情報処理装置において、
前記保険の加入者又は加入の候補者を顧客として、当該顧客に関する情報を第１種顧客情報として所定のデータベースに格納して管理する第１種顧客情報管理手段と、
所定情報の入力をトリガとして、前記第１種顧客情報管理手段の管理外であって前記他情報処理装置により管理されている前記顧客に関する第２種顧客情報を出力するＡＰＩが前記他情報処理装置に構築されており、前記所定情報を前記他情報処理装置に送信することで前記第２種顧客情報を取得する制御を実行する第２種顧客情報取得手段と、
を備える。

本発明の一態様の情報処理方法及びプログラムの夫々は、上述の本発明の一態様の情報処理装置に対応する方法及びプログラムの夫々である。

本発明によれば、保険に関する役務の複数の提供者を繋ぐハブとなる機能を実現させることができる。

本発明の情報処理装置の一実施形態が適用される情報処理システムにより実現可能となる本サービスの概要を示す図である。 図１の本サービスの適用例を示す図である。 図２に示す本サービスのひとつとして提供される保険ＡＰＩの具体的適用例を説明する図である。 ２つの保険会社の夫々が提供する類似保険の商品性とそのオペレーションの違いがどのように基礎書類等で定義されるかの一例を示す図である。 本発明の情報処理装置の一実施形態に係るサービス提供者サーバが適用される情報処理システムの構成の一例を示す図である。 図６は、図５に示す情報処理システムのうちサービス提供者サーバのハードウェア構成の一例を示すブロック図である。 図５の情報処理システムの一構成要素である図６のサーバの機能的構成のうち、保険システム基盤ＨＢの機能的構成の一例を示す機能ブロック図である。

以下、本発明の実施形態について、図面を用いて説明する。

まず、図１を参照して、本発明の情報処理装置の一実施形態が適用される情報処理システムにより実現可能となるサービス（以下、「本サービス」と呼ぶ）の概要について説明する。

図１は、本発明の情報処理装置の一実施形態が適用される情報処理システムにより実現可能となる本サービスの概要を示す図である。

本サービスは、サービス提供者（例えば後述の図２のサービス提供者ＳＡ）から、Ｐ（Ｐは１以上の整数値であり、図１の例ではＰ＝３）の保険会社Ｈ１乃至ＨＰと、Ｑ（Ｑは１以上の整数値であり、図１の例ではＰ＝３）の代理店Ｄ１乃至ＤＱの夫々に対して提供されるサービスである。
なお、保険会社Ｈ１乃至ＨＰを個々に区別する必要がない場合、これらをまとめて「保険会社Ｈ」と呼ぶ。同様に、代理店Ｄ１乃至ＤＱを個々に区別する必要がない場合、これらをまとめて「代理店Ｄ」と呼ぶ。

Ｐの保険会社Ｈ１乃至ＨＰは、１以上の保険（生命保険や損害保険）を提供する役務を行う者であり、例えば、生命保険会社、損害保険会社、少額短期の保険商品を取り扱う事業者等である。
Ｑの代理店Ｄ１乃至ＤＱは、顧客とコンタクトして当該顧客に対して保険商品（１以上の保険のの組合せ等）の提供を代理する役務を行う者であり、会員マーケット、Ｅコマース事業者、旅行代理店、企業代理店（職域保険）、中小企業従業員、銀行（当該銀行のアプリケーションを管理する者）等である。なお、Ｑの代理店Ｄ１乃至ＤＱのうち少なくとも一部は、保険代理店資格をもたないプラットフォーマーであってもよい。

サービス提供者は、本発明の情報処理装置の一実施形態であるサービス提供者サーバ（例えば後述する図３のサービス提供者サーバ１）により、保険システム基盤ＨＢを管理する。
保険システム基盤ＨＢは、Ｐの保険会社Ｈ１乃至ＨＰ及びＱの代理店Ｄ１乃至ＤＱ（正確には夫々により管理される各種装置）と接続する。これにより、保険システム基盤ＨＢは、Ｐの保険会社Ｈ１乃至ＨＰの夫々とＱの代理店Ｄ１乃至ＤＱの夫々とを繋ぐことで、これらのもののハブとして機能するＳａａＳシステムである。
保険システム基盤ＨＢは、例えばＰの保険会社Ｈ１乃至ＨＰの夫々に対しては、保険ＡＰＩ、マーケティング機能、ＵＸ機能、保険金請求ボット提供機能、アプリケーション提供機能等、各種機能を提供し発揮させる。
また、保険システム基盤ＨＢは、例えばＱの代理店Ｄ１乃至ＤＱの夫々に対して、保険証券マイページ（所定の保険商品についての商品ページや申し込みフォーム等）管理機能、スクレイピング機能等、各種機能を提供し発揮させる。

図２は、図１の本サービスの適用例を示す図である。
図２の例では、保険会社Ｈ１乃至ＨＰのうち所定の保険会社Ｈと、Ｑの代理店Ｄ１乃至ＤＱのうち所定の代理店Ｄとが保険システム基盤ＨＢにより接続されている。
保険会社Ｈは、１以上の保険を顧客に提供する者であり、コールセンター等の担当者端末ＨＴと、保険会社既存システムＨＳとを管理している。保険会社既存システムＨＳは、保険会社Ｈのメインフレームシステムや決算システム等により構成される。
代理店Ｄは、保険商品（１以上の保険の組合せ等からなる商品）の顧客への提供を代理する者であり、顧客ネットワークＣＮと、サービス提供者ＳＡから提供される商品ページ及び申し込みフォームＳＦとを管理する。

このように、保険会社Ｈと代理店Ｄとが保険システム基盤ＨＢに接続されることにより、例えば次のようなサービスＳ１乃至Ｓ６の提供が可能になる。
サービスＳ１は、保険システム基盤ＨＢが、バッチ処理＿ＣＳＶ連携等により保険会社既存システムＨＳとシンクロを図るものである。
サービスＳ２は、アドミン・ポータルを通じて、保険システム基盤ＨＢにより管理される各種情報を担当者端末ＨＴにより閲覧・編集を可能にさせるものである。
サービスＳ３は、サービス提供者ＳＡによる、保険システム基盤ＨＢのエンジニアリングサービスである。
サービスＳ４は、サービス提供者ＳＡによる、商品ページ及び申し込みフォームＳＦのエンジニアリング・デザイン・マーケティングサービスである。
サービスＳ５は、保険ＡＰＩを構築するサービスである。
サービスＳ６は、顧客ネットワークＣＮにより管理される顧客に対して、商品ページ＆申し込みフォームＳＦを活用しながら、保険契約を締結させる支援をするサービスである。

以下、図３を参照して、サービスＳ５，即ち、保険ＡＰＩを構築するサービスについて詳しく説明する。
図３は、保険ＡＰＩの具体的適用例を説明する図である。

図３に示すように、商品ページＳＦ及び申し込みフォームＳＦは、保険会社Ｈの保険等を含む保険商品に関して、顧客に各種情報を提示し、最終的には保険契約の締結までを支援するものである。
顧客が保険商品を検討したり或いは保険契約の締結をする際には、当該保険商品が顧客に適用できるか否かの即座の判断が必要になる。
しかしながら、このような即座の判断をするために必要な顧客の情報は、保険システム基盤ＨＢに管理されておらず、保険会社既存システムＨＳにより管理されている。例えば、保険会社Ｈが提供する保険については、当該保険会社Ｈの社内規制や法令制約により、顧客毎に付与できる保険金額（補償金額）が決まっている。このような社内規則等に違反しているか否か、即ち、顧客が検討したり契約締結しようとしている保険商品の保険金額がこの顧客毎に付与されている金額を超えていないかについては、即座の判断が必要になる。
そこで、図３に示すように、サービスＳ５により、保険会社の既存システムＨＳ上にＡＰＩが構築されて、このような即座の判断ができるように保険システム基盤ＨＢと保険会社既存システムＨＳとが連携される。
なお、上述した図２のサービスＳ１のバッチ処理＿ＣＳＶ携等によっても、保険システム基盤ＨＢと保険会社既存システムＨＳとの連携はなされている。しかしながら、バッチ処理＿ＣＳＶ連携等の頻度は週１回程度であるため、即座の判断に間に合わないおそれ（更新すべき情報が更新されていないおそれ）がある。このため、サービスＳ５，即ち、保険ＡＰＩを構築するサービスが提供されるのである。
具体的には例えば、図３の例では、保険会社Ｈにおいて顧客に設定された保険金額がＡＰＩで取得できるデータである。このデータを取得するためにＡＰＩで送信するデータは、顧客の年齢、性別、生年月日、住所等である。

サービスＳ５により構築可能な保険ＡＰＩは、図３の例に特に限定されず、各種各様なものを採用することができる。
例えば、保険会社Ｈの中には、保険会社既存システムＨＳの一部として反社チェックシステムを有しているものもある。このような場合には、顧客の反社チェックをするために、保険会社既存システムＨＳの反社チェックシステムを呼び出すＡＰＩを構築することができる。このようなＡＰＩが構築されることで、その顧客が反社の者か否かを即座に判断することが可能になる。
また例えば、顧客についての保険会社Ｈにおける他の保険商品の加入状況や検討状況を返すＡＰＩを構築することができる。このようなＡＰＩが構築され、顧客の同一性を担保できれば、その顧客について、保険の加入しすぎ、不足している保険の提案、より良い保険の提案等が、保険システム基盤ＨＢ（例えばそれと接続されている商品ページＳＦ及び申し込みフォームＳＦ等）において即座に可能になる。
また例えば、顧客の保険会社Ｈにおける保険成績（過去の保険事故の状況）を呼び出すＡＰＩを構築することができる。このようなＡＰＩが構築されることで、例えば、その顧客が、自動車事故を多発する人等の保険引き受け不可となっているか否かを即座に判断することが可能になる。
また例えば、保険会社既存システムＨＳに、顧客の個人情報を管理するデータベースが存在する場合、保険申し込みに必要な個人情報を返すＡＰＩを構築することが可能になる。これにより、保険システム基盤ＨＢ（例えばそれと接続されている商品ページ及び申し込みフォームＳＦ等）において、入力補助をして、ＵＸを改善することが可能になる。
なお、これらの各種例の保険ＡＰＩで呼び出される情報についても、週１回程度の頻度で、上述した図２のサービスＳ１のバッチ処理＿ＣＳＶ連携等によって、保険システム基盤ＨＢと保険会社既存システムＨＳとの連携はなされている。ただし、上述したように、即座の判断に間に合わないおそれ（更新すべき情報が更新されていないおそれ）があるため、これらの各種例の保険ＡＰＩが構築されていると好適である。

以上まとめると、サービスＳ５，即ち、保険ＡＰＩを構築するサービスは、保険システム基盤ＨＢが次のような機能を有し発揮することで実現可能になる。
即ち、保険システム基盤ＨＢは、保険に関する役務の提供者の他情報処理装置と通信をする機能を有する。
ここで、「保険に関する役務の提供者」とは、Ｐの保険会社Ｈ１乃至ＨＰ及びＱの代理店Ｄ１乃至ＤＱをまとめた総称である。また、「保険に関する役務の提供者」により管理される装置が、「他情報処理装置」である。
保険システム基盤ＨＢは、保険の加入者又は加入の候補者を顧客として、当該顧客に関する情報を第１種顧客情報として所定のデータベースに格納して管理する第１種顧客情報管理機能を有する。
保険システム基盤ＨＢは、所定情報（例えば図３の例では顧客の氏名・年齢・性別・生年月日・住所等）の入力をトリガとして、第１種顧客情報管理機能の管理外であって他情報処理装置により管理されている顧客に関する第２種顧客情報（例えば図３の例では、顧客に付与された保険金額（補償金額））を出力するＡＰＩが他情報処理装置に構築されており、所定情報を他情報処理装置に送信することで第２種顧客情報を取得する制御を実行する第２種顧客情報取得機能を有する。

本サービスは、上述の図２及び図３のサービスＳ１乃至Ｓ６の他、下記のような各種各様なサービスを提供することができる。

即ち、図１で上述したように、保険システム基盤ＨＢは、Ｐの保険会社Ｈ１乃至ＨＰ及びＱの代理店Ｄ１乃至ＤＱ（正確には夫々により管理される各種装置）と接続する。
ここで、Ｐの保険会社Ｈ１乃至ＨＰ及びＱの代理店Ｄ１乃至ＤＱは、「保険に関する役務の提供者」としてまとめられる。そこで、Ｐ＋Ｑ＝Ｎとすると、「保険に関する役務の提供者」はＮ人存在することになる。
即ち、保険システム基盤ＨＢは、Ｎ人の「保険に関する役務の提供者」の夫々により管理される他情報処理装置と夫々通信することで、次のような機能を発揮させることができる。
即ち、保険システム基盤ＨＢは、Ｎ人の「保険に関する役務の提供者」のうちＭ（ＭはＮ以下の整数値）の提供者により夫々提供される保険又は保険商品について、所定単位毎に情報を抽出する保険情報抽出機能を有している。
ここで、抽出される情報の格納場所は、特に限定されず、保険システム基盤ＨＢ内（例えば後述の図４の記憶部１８）であってもよいし、他情報処理装置内（例えば保険会社既存システムＨＳ内）等であってもよい。
保険システム基盤ＨＢは、保険商品情報抽出機能により所定単位毎に抽出された情報に基づいて、保険に関する所定機能の発揮に必要なパラメータを１以上抽出するパラメータ生成機能を有している。
保険システム基盤ＨＢは、１以上のパラメータに基づいて、「保険に関する役務の提供者」により設定された規定や法令（例えば一人の被保険者（顧客）に対してのガン保険の保険金額の上限など）を含む制約の範囲内で所定機能を発揮させる処理を実行する機能発揮手段を有している。

ここで、保険に関する所定機能は、特に限定されず、例えば、ノーコードツール機能、団体向けポータル機能、及び保険料課金ロジック機能等が存在する。
そこで以下、ノーコードツール機能、団体向けポータル機能、及び保険料課金ロジック機能等の夫々の詳細について、その順番に個別に説明する。

先ず、保険に関する所定機能の一例として、ノーコードツール機能について説明する。
ノーコードツール機能とは、保険商品についての商品ページ及び申し込みフォームをノーコードで生成可能にする機能である。

保険システム基盤ＨＢは、複数の保険会社Ｈの保険会社既存システムＨＳの夫々と接続されている。保険会社既存システムＨＳには、各保険会社Ｈの保険商品に関する各種情報が蓄積されて管理されている。
換言すると、保険システム基盤ＨＢは、複数の保険会社の複数の保険商品と接続される。
保険商品は、複雑であり、日本国では法令で定められる基礎書類で定義される。基礎書類とは、約款、事業方法書、算出方法書等の書類をいう。
保険システム基盤ＨＢは、このような各保険会社でばらばらな複雑な基礎書類（データ）を所定単位毎に読み込むことで、保険に関する所定機能の発揮に必要な変数やパラメータ（これらをまとめて「パラメータ」と呼ぶ）を自動的に生成してくれる機能、即ち、パラメータ生成機能を有している。
ここで、パラメータ生成機能には、パラメータを生成するのみならず、その延長としてパラメータを入力すると必要な機能実装が保険システム基盤ＨＢ自身に対して行われる機能も含まれている。

図４は、２つの保険会社の夫々が提供する類似保険の商品性とそのオペレーションの違いがどのように基礎書類等で定義されるかの一例を示す図である。
図４の例では、保険会社Ｈ１（Ｘ保険会社）と保険会社Ｈ２（Ｙ保険会社）の夫々が提供するがん保険についての基礎書類の一例が示されている。
所定の１行が、各保険会社Ｈ１乃至Ｈ２の夫々のがん保険についての所定項目の制約等を示している。
図４の例では、パラメータ生成機能により、所定の１行（所定項目の制約）を単位として、パラメータが抽出される。
例えば、「特約」というパラメータとしては、保険会社Ｈ１（Ｘ保険会社）については「がん診断時に一律で［Ａ］万円のみ」というパラメータが抽出され、保険会社Ｈ２（Ｙ保険会社）については「がんによる入院で入院日額［Ｂ］万円の給付」というパラメータが抽出される。ここで、備考にも示されるように、［Ａ］や［Ｂ］は顧客毎に設定される変数である。
保険システム基盤ＨＢは、図４の例では１行に対応する項目毎に、基礎書類等を解析するエンジンによって、各保険の特性を１以上のパラメータとして抽出して、後述する各種機能に反映させることができる。
換言すると、パラメータ生成機能とは、各保険会社Ｈ毎に異なる仕様やＵＩを（保険システム基盤ＨＢ）に読み込み吐き出すことができる機能であると把握することもできる。

保険システム基盤ＨＢは、このようにして抽出された１以上のパラメータを用いることで、様々な保険の組み合わせ（特約の組み合わせ等）による保険商品を作成する保険商品作成機能を有している。
ここで、保険システム基盤ＨＢは、上述の保険金額等の保険会社Ｈ内の規定や、法令等（例えば一人の被保険者（顧客）に対してのガン保険の保険金額の上限等の）の制約に合致しない保険商品が生成されないようにしたりグレーアウトする制約確認機能を、保険商品作成機能の一部として有している。このような制約は、上述のパラメータ生成機能により抽出されたパラメータ（例えば図４の「保険金額上限」等）により把握される。
保険システム基盤ＨＢは、このような保険商品作成機能により生成された保険商品、即ち、このような制約に合致した保険商品について、商品ページ及び申し込みフォームＳＦをノーコードで自動的に生成する生成機能を有している。
換言すると、このような保険商品作成機能（制約確認機能を含む）及び生成機能が、ノーコードツール機能である。

次に、保険に関する所定機能の一例として、団体向けポータル機能について説明する。
団体向けポータル機能とは、団体向けの保険商品について、商品ページ及び申し込みフォームＳＦを生成する機能である。
Ｑの代理店Ｄ１乃至ＤＱ（Ｑは数百の場合もある）について、似たような保険商品の商品ページ及び申し込みフォームＳＦを作成する必要があるが、非常に手間のかかるものである。
この場合、保険システム基盤ＨＢは、保険商品情報抽出機能として、各代理店Ｄ１乃至ＤＱの夫々の特性についてのアンケート結果やヒアリング結果を示す情報や、ブランドガイドライン等を抽出する。
そして、保険システム基盤ＨＢは、パラメータ生成機能により、抽出されたこれらの情報に基づいて、１以上のパラメータを生成する。
保険システム基盤ＨＢは、上述の保険商品作成機能（制約確認機能を含む）により生成された各代理店Ｄ１乃至ＤＱ毎の夫々の保険商品について、商品ページ及び申し込みフォームＳＦをノーコードで自動的に生成する生成機能を有している。
換言すると、このような保険商品作成機能（制約確認機能を含む）及び生成機能が、団体向けポータル機能である。

次に、保険に関する所定機能の一例として、保険料課金ロジック機能について説明する。
保険料課金ロジック機能とは、顧客の保険料金（以下、「保険料」と呼ぶ）の収納をする（そのようなロジックを提供する）機能である。
ここで、保険料課金ロジック機能は、顧客の保険料の少なくとも一部としてポイントで収納する（そのようなロジックを提供する）機能を含むことができる。なお、このような機能を以下、「ポイント課金ロジック機能」と呼ぶ。
具体的には例えば、保険システム基盤ＨＢは、保険会社Ｈの保険の収納代行の処理を実行することができる。
ここで、保険会社Ｈ毎に、約款等の基礎書類に規定される課金方法（例えば、毎月１日課金とか、初月は日割り等の方法）や失効方法（２回課金失敗で契約失効等の方法）が規定されている。
そこで、保険システム基盤ＨＢは、パラメータ抽出手法を発揮して、保険会社Ｈの基礎書類（データ）を読み込むことで、課金方法や失効方法に関するパラメータを１以上生成する。例えば図４の例では、「保険料」、「保険料の払い込み方法」、「保険料の失効ルール」、「失効猶予期間中の保険事故に対する扱い」等の項目から１以上のパラメータが生成される。
保険システム基盤Ｈは、このような１以上のパラメータを用いることで、保険会社Ｈの保険の収納代行の処理を実現するためのロジックを生成して提供する機能を有する。このような機能が、保険料課金ロジック機能である。

次に、ポイント課金ロジック機能について説明する。
ポイント課金ロジック機能とは、顧客が保有するポイントと、当該顧客のクレジットカードの併用で月次保険料を当該顧客から課金する（そのようなロジックを生成して提供する）機能である。
具体的には例えば、ポイント課金ロジック機能によれば、ポイントについては残高が不足することもあるので毎月のポイントの残高を確認し、残高の分だけポイントから課金して、残りの額をクレジットカードで課金するロジックが提供される。

本サービスは、上述の図２及び図３のサービスＳ１乃至Ｓ６、並びにノーコードツール機能、団体向けポータル機能、及び保険料課金ロジック機能等の各種所定機能を発揮させるサービスの他、下記のような各種各様なサービスを提供することができる。

即ち、上述したように、保険システム基盤ＨＢは、Ｐの保険会社Ｈ１乃至ＨＰ及びＱの代理店Ｄ１乃至ＤＱといったＮ人の「保険に関する役務の提供者」の夫々により管理される他情報処理装置と夫々通信することで、次のような機能を発揮させることができる。
即ち、保険システム基盤ＨＢは、Ｎ人の「保険に関する役務の提供者」のうち所定提供者の他情報処理装置から第１種顧客情報の提供が依頼された場合、当該所定提供者による役務の提供に関する当該第１種顧客情報の提供を許可し、当該所定提供者以外の提供者による役務の提供に関する当該第１種顧客情報の提供を禁止する第１種顧客情報提供機能を有している。
ここで、第１種顧客情報とは、上述したように、保険システム基盤ＨＢの第１種顧客情報管理機能により管理される顧客の情報である。

保険システム基盤ＨＢは、複数の保険会社Ｈ及び複数の代理店Ｄ（正確には夫々が管理する装置）と接続される。このため、原則として、代理店Ｄ側の端末（例えば図５の担当者端末ＤＴ１乃至ＤＳＱ）からも、保険システム基盤ＨＢにより管理されている情報（例えば第１種顧客情報）の閲覧（提供）が可能になされている。
例えば、代理店Ｄ１（Ａ代理店）で保険会社Ｈ１（Ｘ保険会社）の保険に加入したＣ顧客が存在したとする。このＣ顧客の第１種顧客情報は、代理店Ｄ１（Ａ代理店）側で保険システム基盤ＨＢにアクセスしたときも、保険会社Ｈ１（Ｘ保険会社）側で保険システム基盤ＨＢにアクセスしたときも、閲覧（提供）が許可される。代理店Ｄ１（Ａ代理店）にとっても、保険会社Ｈ１（Ｘ保険会社）にとっても、Ｃ顧客の第１種顧客情報は、自身の役務の提供に関するものだからである。
これに対して、例えばＣ顧客が代理店Ｄ１（Ａ代理店）を介さずに保険会社Ｈ１（Ｘ保険会社）の保険ダイレクトで加入していた場合には、保険会社Ｈ１（Ｘ保険会社）側で保険システム基盤ＨＢにアクセスしたときには、当然ながら閲覧（提供）が許可される。保険会社Ｈ１（Ｘ保険会社）にとっては、Ｃ顧客の第１種顧客情報は、自身の役務の提供に関するものだからである。しかしながら、代理店Ｄ１（Ａ代理店）側で保険システム基盤ＨＢにアクセスしたときには、閲覧（提供）が禁止される。即ち、代理店Ｄ１（Ａ代理店）は、Ｃ顧客の第１種顧客情報を閲覧することはできない。代理店Ｄ１（Ａ代理店）にとっては、Ｃ顧客の第１種顧客情報は、自身の役務の提供に関するものには該当しないからである。

ただし、自身の役務の提供に関するものではなくても、共有すべき情報が存在する場合がある。
このような場合のために、第１種顧客情報提供機能は、所定提供者以外の提供者による役務の提供に関する第１種顧客情報のうち、所定条件を満たすもの、又は当該第１種顧客情報を加工した情報については、提供の禁止を解除する機能を有してもよい。
即ち、Ｃ顧客は単一の人物であるので、保険システム基盤ＨＢは、次の観点で判断して、提供（閲覧）を可能とする機能を発揮してもよい。

例えば、保険会社Ｈ１（Ｘ保険会社）から保険システム基盤ＨＢに提供されたＣ顧客の情報、即ち、Ｃ顧客の第１種顧客情報のうち、ＫＹＣ（マイナンバ、免許証等）やＡＭＬ（反社チェック等）については、代理店Ｄ１（Ａ代理店）等の他の「保険に関する役務の提供者」にシェアすることで、顧客Ｃや「保険に関する役務の提供者」の手間を省くことができると判断できる場合がある。
換言すると、代理店Ｄ１（Ａ代理店）等の他の「保険に関する役務の提供者」にシェアすることで、顧客Ｃや他の「保険に関する役務の提供者」の手間を省くことができるということが所定条件の一例であり、当該所定条件を満たす場合がある。
このような場合、保険システム基盤ＨＢは、所定条件を満たす第１種顧客情報、即ちＣ顧客のＫＹＣやＡＭＬについては、他の「保険に関する役務の提供者」の閲覧（提供）の禁止を解除（即ち閲覧（提供）の許可）をする。

例えば、Ｃ顧客の情報又は保険システム基盤ＨＢで管理されている情報（Ｃ顧客の年齢、性別、住所、年収、家族構成等の属性情報）に基づいて算出された、Ｃ顧客に類似する者の疾病確率等は、Ｃ顧客の第１種顧客情報を加工した情報の一例である。そこで、保険システム基盤ＨＢは、このような情報については、任意の「保険に関する役務の提供者」の閲覧（提供）の禁止を解除（即ち閲覧（提供）の許可）をする。

例えば、Ｃ顧客について、保険会社Ｈ１（Ｘ保険会社）の保険加入の情報から別の保険の提案がされるべきと判断された場合に、別の保険会社Ｈ２（Ｙ保険会社）が自動提案されたり提案すべきというフラグが出されてもよい。
この場合、別の保険の提案がされるべきと判断されることが所定条件の一例であり、当該所定条件を満たすときがある。
このようなとき、保険システム基盤ＨＢは、所定条件を満たす第１種顧客情報、即ちＣ顧客についての保険会社Ｈ１（Ｘ保険会社）の保険加入の情報については、別の保険会社Ｈ２（Ｙ保険会社）の閲覧（提供）の禁止を解除（即ち閲覧（提供）の許可）をする。

例えば、Ｃ顧客について、保険会社Ｈ１（Ｘ保険会社）においては保険金請求が多すぎたり不正請求があったりしたこと等でブラックリストに入れられていた場合、その事実を別の保険会社Ｈ２（Ｙ保険会社）等にシェアするようにしてもよい。
この場合、ブラックリストに入れられていることが所定条件の一例であり、当該所定条件を満たすときがある。
このようなとき、保険システム基盤ＨＢは、所定条件を満たす第１種顧客情報、即ちＣ顧客についての保険会社Ｈ１（Ｘ保険会社）においてブラックリストに入れられているという事実を示す情報については、別の保険会社Ｈ２（Ｙ保険会社）の閲覧（提供）の禁止を解除（即ち閲覧（提供）の許可）をする。

以上、図１乃至図４を参照して、本サービスの概要について説明した。

次に、図５を参照して、上述した本サービスの提供を実現化させる情報処理システム、即ち本発明の情報処理装置の一実施形態のサービス提供者サーバが適用される情報処理システムの構成について説明する。
図５は、本発明の情報処理装置の一実施形態に係るサービス提供者サーバが適用される情報処理システムの構成の一例を示す図である。

図５に示す情報処理システムは、サービス提供者サーバ１と、保険会社Ｈ１乃至ＨＰの夫々が管理する装置と、代理店Ｄ１乃至ＤＱの夫々が管理する装置とを含むように構成されている。
サービス提供者サーバ１と、保険会社Ｈ１乃至ＨＰの夫々が管理する装置と、代理店Ｄ１乃至ＤＱの夫々が管理する装置とは、インターネット等の所定のネットワークを介して相互に接続されている。

ここで、保険会社ＨＫ（Ｋは、１乃至Ｐのうち任意の整数値）が管理する装置としては、担当者端末ＨＴＫと保険会社既存システムＨＳＫとが存在する。
なお、以下、「保険会社Ｈ」と符号Ｋを省略して呼んでいる場合には、各装置の符号Ｋを省略し、「担当者端末ＨＴ」及び「保険会社既存システムＨＳ」の夫々と呼ぶ。
また、代理店ＤＬ（Ｌは、１乃至Ｑのうち任意の整数値）が管理する装置としては、担当者端末ＤＴＬと代理店既存システムＤＳＬとが存在する。
なお、以下、「代理店Ｄ」と符号Ｋを省略して呼んでいる場合には、各装置の符号のうちＫを省略し、「担当者端末ＤＴ」及び「代理店既存システムＤＳ」の夫々と呼ぶ。

サービス提供者サーバ１は、サービス提供者ＳＡにより管理される情報処理装置であり、保険システム基盤ＨＢを構築する。
サービス提供者サーバ１（保険システム基盤ＨＢ）は、保険会社Ｈ１乃至ＨＰの夫々が管理する装置と、代理店Ｄ１乃至ＤＱの夫々が管理する装置と適宜通信をしながら、本サービスを実現するための各種処理を実行する。

図６は、図５に示す情報処理システムのうちサービス提供者サーバのハードウェア構成の一例を示すブロック図である。

サービス提供者サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、入力部１６と、出力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２、及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、入力部１６、出力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

入力部１６は、例えばキーボード等により構成され、各種情報を入力する。
出力部１７は、液晶等のディスプレイやスピーカ等により構成され、各種情報を画像や音声として出力する。
記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮＷを介して他の装置（例えば図５の保険会社Ｈや代理店Ｄが管理する各装置）との間で通信を行う。

ドライブ２０には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア４０が適宜装着される。ドライブ２０によってリムーバブルメディア４０から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。
また、リムーバブルメディア４０は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。

このような図６のサービス提供者サーバ１の各種ハードウェアと各種ソフトウェアとの協働により、保険システム基盤ＨＢが構築される。その結果、上述の本サービスを提供することができる。
以下、図６のサービス提供者サーバ１において構築される保険システム基盤ＨＢの機能的構成について説明する。

図７は、図５の情報処理システムの一構成要素である図６のサーバの機能的構成のうち、保険システム基盤の機能的構成の一例を示す機能ブロック図である。

図７に示すように、ＣＰＵ１１においては、顧客情報管理部５１と、商品ページ・申し込みフォーム管理部５２と、保険ＡＰＩ制御部５３と、保険情報抽出部５４と、パラメータ生成部５５と、機能発揮部５６とが機能する。
機能発揮部５６には、ノーコードツール生成部６１と、保険料金ロジック生成部６２と、団体向ポータル生成部６３とが設けられている。

また、記憶部１８の一領域には、保険ＤＢ７１が設けられている。
保険ＤＢ７１には、バッチ処理＿ＣＳＶ連携等（図２のサービスＳ１）により保険会社Ｈや代理店Ｄとシンクロを図ったデータが格納される。保険ＤＢ７１には、その他、保険システム基盤ＨＢにおいて生成又は取得された各種情報が保険ＤＢ７１に格納される。例えば、図示はしないが、保険ＡＰＩ、マーケティング機能、ＵＸ機能、保険金請求ボット提供機能、アプリケーション提供機能、保険証券マイページ（所定の保険商品についての商品ページや申し込みフォーム等）管理機能、スクレイピング機能等、各種機能が発揮された際に生成又は取得された各種情報が保険ＤＢ７１に格納される。

顧客情報管理部５１は、顧客に関する情報を第１種顧客情報として保険ＤＢ７１に格納して管理する。

ここで、所定情報の入力をトリガとして、保険ＤＢ７１の管理外であって保険会社既存システムＨＳや代理店既存システムＤＳにより管理されている顧客に関する第２種顧客情報を出力するＡＰＩ（保険ＡＰＩ）が、保険会社既存システムＨＳや代理店既存システムＤＳに構築されているものとする。
保険ＡＰＩ制御部５３は、図３等を用いて上述したように、当該保険ＡＰＩを制御して、所定情報を保険会社既存システムＨＳや代理店既存システムＤＳに送信することで第２種顧客情報を取得する。
ここで、上述したように、保険ＤＢ７１には、バッチ処理＿ＣＳＶ連携等（図２のサービスＳ１）により保険会社Ｈや代理店Ｄとシンクロを図ったデータ（顧客に付与された保険金等）が格納されて管理されている。しかしながら、このようなデータは、１週間等の間隔毎に保険会社Ｈや代理店Ｄから取得されたデータであり、取得時点では保険会社Ｈや代理店Ｄには管理されていたかもしれないが、その後は更新されて管理対象外になる。
したがって、バッチ処理＿ＣＳＶ連携等（図２のサービスＳ１）により保険会社Ｈや代理店Ｄとシンクロを図ったデータ（顧客に付与された保険金等）は、あくまでも第１種顧客情報であって、第２種顧客情報には該当しない。即ち、リアルタイムに保険会社Ｈや代理店Ｄにおいて管理されているデータ（顧客に付与された保険金等）が、第２種顧客情報である。

保険情報抽出部５４は、上述の保険情報抽出機能を発揮し、保険会社Ｈ及び代理店Ｄにより夫々提供される保険又は保険商品について、所定単位毎に情報を抽出する。
パラメータ生成部５５は、上述のパラメータ生成機能を発揮し、保険情報抽出部５４により所定単位毎に抽出された情報に基づいて、保険に関する所定機能の発揮に必要なパラメータを１以上抽出する。
機能発揮部５６は、パラメータ生成部５５により生成された１以上のパラメータに基づいて、保険会社Ｈや代理店Ｄにより設定された規定、法令（例えば一人の被保険者に対してのガン保険の保険金額の上限など）を含む制約の範囲内で所定機能を発揮させる処理を実行する。

具体的には例えば、機能発揮部５６のうちノーコードツール生成部６１は、上述のノーコードツール機能を発揮させる。
即ち、ノーコードツール生成部６１は、パラメータ生成部５５により生成された１以上のパラメータを用いることで、様々な保険の組み合わせ（特約の組み合わせ等）による保険商品を作成する。
ここで、ノーコードツール生成部６１は、上述の保険金額等の保険会社Ｈ内の規定や、法令等（例えば一人の被保険者（顧客）に対してのガン保険の保険金額の上限等の）の制約に合致しない保険商品が生成されないようにしたりグレーアウトする。
ノーコードツール生成部６１は、このようにして生成した保険商品、即ち、このような制約に合致した保険商品について、商品ページ及び申し込みフォームＳＦをノーコードで自動的に生成する。

また例えば、機能発揮部５６のうち保険料金ロジック生成部６２は、上述の保険料課金ロジック機能を発揮させる。即ち、保険料金ロジック生成部６２は、パラメータ生成部５５により生成された１以上のパラメータを用いることで、保険会社Ｈの保険の収納代行の処理を実現するためのロジックを生成して提供する。
さらに、保険料金ロジック生成部６２は、顧客が保有するポイントと、当該顧客のクレジットカードの併用で月次保険料を当該顧客から課金する（そのようなロジックを生成して提供する）。

また例えば、機能発揮部５６のうち団体向ポータル生成部６３は、上述の団体向けポータル機能を発揮させる。即ち、団体向ポータル生成部６３は、パラメータ生成部５５により生成された１以上のパラメータを用いることで、団体向けの保険商品について、商品ページ及び申し込みフォームＳＦを生成する。

情報閲覧制御部５７は、保険会社Ｈ１乃至ＨＰ及び代理店Ｄ１乃至ＤＱのうち所定提供者の他情報処理装置から第１種顧客情報の閲覧（提供）が依頼された場合、当該所定提供者による役務の提供に関する当該第１種顧客情報の閲覧（提供）を許可する。一方、情報閲覧制御部５７は、当該所定提供者以外の提供者による役務の提供に関する当該第１種顧客情報の閲覧（提供）を禁止する。
ここで、情報閲覧制御部５７は、所定提供者以外の提供者による役務の提供に関する第１種顧客情報のうち、所定条件を満たすもの、又は当該第１種顧客情報を加工した情報については、閲覧（提供）の禁止を解除する（即ち、閲覧（提供）を許可する）。

以上、本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものとみなす。

以下、上述の各機能について例を用いてより具体的に説明する。
まず、本サービスにおける、サービス提供者サーバ１の保険システム基盤ＨＢと保険会社Ｈの保険会社既存システムＨＳと、代理店既存システムＤＳとを間での情報の授受に用いられる保険ＡＰＩについて、具体的な利用例を用いながら説明する。

例えば、「山田太郎（ヤマダタロウ）」という氏名の顧客（加入者又は加入の候補者）が新規契約者として本サービスの保険システム基盤ＨＢに対してデータが上がってきたとする（契約申し込みがあったとする）。この時、本サービスの保険システム基盤ＨＢには、顧客のデータとして、その顧客の氏名以外に一般的に保険申し込みに必要な情報が格納される。具体的には例えば、顧客のデータには、顧客の性別、生年月日、電話番号、住所、免許証番号が含まれ得る。

即ち例えば、顧客が代理店Ｄにおいて代理店Ｄの担当者から保険商品の紹介を受けた結果として保険商品の契約を新規に結ぼうとする場合、当該顧客のデータが代理店Ｄの担当者端末ＤＴに入力される。
顧客情報管理部５１は、代理店Ｄの担当者端末ＤＴ等から取得された顧客の氏名、顧客の性別、生年月日、電話番号、住所、免許証番号といったデータを、保険ＤＢ７１に格納して管理する。

そして、保険システム基盤ＨＢは、接続先の保険会社既存システムＨＳに対して顧客であるヤマダタロウの情報について、保険ＡＰＩを用いて照会をかける。
即ち、保険会社既存システムＨＳには、上述したように、所定情報の入力をトリガとして、保険ＤＢ７１の管理外であって保険会社既存システムＨＳや代理店既存システムＤＳにより管理されている顧客に関する情報を出力する保険ＡＰＩが構築されている。
そこで、保険システム基盤ＨＢの保険ＡＰＩ制御部５３は、保険ＡＰＩを制御して、ヤマダタロウに関する情報を保険会社既存システムＨＳや代理店既存システムＤＳに送信することで第２種顧客情報を取得することで照会する。
このようにして、保険システム基盤ＨＢは、顧客であるヤマダタロウに関する情報に基づいて、保険会社既存システムＨＳに対して、当該顧客の保険の加入状況の情報を取得する。

しかしながら、保険会社既存システムＨＳにおいては、その保険会社Ｈ自身が登録したデータであって、以下のような表記ゆれや情報の未アップデート等が存在し、単に照会するだけでは、本来照会結果に含まれるべき顧客のデータが取得できないことがある。
例えば、保険会社既存システムＨＳにおいては、住所に含まれる文字が全角又は半角の相違、「山田太郎」と「山田太朗」等の漢字の表記ミス、結婚等による苗字の変更、引越しによる住所の変更、生年月日の西暦和暦表示等が存在することがある。

具体的には例えば、同一の顧客である山田太郎（ヤマダタロウ）について、保険会社Ｈ１の保険会社既存システムＨＳにおいて「氏名：山田太郎、フリガナ：ヤマダタロウ、住所：東京都中央区……」と登録されていたり、保険会社Ｈ２の保険会社既存システムＨＳにおいて「氏名：山田太朗、フリガナ：ヤマダタロウ、住所：東京都中央区……」として登録されていたりすることがある。この場合、氏名の漢字の相違により、別の人物（顧客）であると判断されることがある。
また例えば、保険会社Ｈ３の保険会社既存システムにおいて、「山田太郎、フリガナ：ヤマダタロウ、住所：神奈川県横浜市……」と、現住所とは別の住所（例えば以前住んでいた住所）が登録されている場合がある。

本サービスでは、上記の表記揺れを保険システム基盤ＨＢと保険会社既存システムＨＳとの間に設けられた図示せぬ中間データベースにより、データの擬似名寄せを行う。
即ち、保険会社Ｈ１乃至Ｈ３の夫々に登録されている同一の顧客である山田太郎（ヤマダタロウ）について、名寄される。
これにより、保険システム基盤ＨＢに登録されたヤマダタロウに関する情報が、保険会社既存システムＨＳに既に存在しているか否かと、保険業に必要となる保険金額などの情報を取得することを可能となる。
ここで、中間データベースとは、保険システム基盤ＨＢと保険会社既存システムＨＳとの夫々に記録された顧客の情報同士を紐づけるための情報を格納したデータベースである。

上述してきたように、従来、保険会社Ｈは、保険会社Ｈ自身の保険会社既存システムＨＳを有している。さらに、保険会社Ｈは、所定年より前と後など、保険会社既存システムＨＳの更新前後のシステムを別個に有していることがある。そして、保険会社Ｈは、グループ会社等の保険会社既存システムＨＳも有していることがある。
このように、複数の保険会社既存システムＨＳが存在するなかで、保険会社Ｈは、従来、手作業で社内のデータベースの名寄を行ってきた背景がある。

これに対して、本サービスの保険システム基盤ＨＢは、以下に示すように、疑似名寄をすることができる。
即ち、同一の顧客（保険契約後においては保険の契約者）を紐づけるための情報の作成と利用の流れについて説明する。
同一の顧客を紐づける情報の作成方法として、バッチ処理が存在する。
即ち、まず、顧客情報管理部５１は、複数の保険会社Ｈの保険会社既存システムＨＳから、顧客の個人を特定可能な情報を含む所定情報を夫々取得して、保険ＤＢ７１に格納して管理する。
ここで、顧客の個人を特定可能な情報には、例えば、氏名の漢字記載、読み仮名記載、携帯電話番号、住所等が存在する。
これにより、保険ＤＢ７１に含まれる顧客の情報と、各保険会社Ｈの保険会社既存システムＨＳの各保険商品の情報とが紐づけられる。
そして、顧客情報管理部５１は、取得された顧客の個人を特定可能な情報に基づいて、複数の保険会社Ｈの保険会社既存システムＨＳを超えて（１つの保険会社既存システムＨＳではなく、複数の保険会社既存システムＨＳの複数の保険商品の間で）同一の顧客の名寄を行う。
そして、顧客情報管理部５１は、保険商品同士を紐づける情報を、保険ＤＢ７１に格納して管理する。これにより、複数の保険会社Ｈの顧客同士が名寄されるのである。このような名寄は、夜間にバッチ処理により行うことができる。
これにより、同一の携帯電話番号と住所を有する、保険会社Ｘの山田太郎と、保険会社Ｙの山田太朗とが同一の人物であると紐づけられて管理される。

また、同一の顧客を紐づける情報の作成方法として、保険システム基盤ＨＢ上のログイン処理が存在する。
具体的には例えば、顧客が本システム基盤ＨＢ上のアカウントを作成する場合、本システム基盤ＨＢ上のアカウント作成のために入力した顧客の個人を特定するための情報や、ＳＭＳ認証のために登録された携帯電話番号、ＳＮＳやポータルサイトを用いたＳＳＯ認証、保険システム基盤ＨＢ上で顧客の能動的な登録により保険会社Ｈと紐づけられた情報、厚生労働省のガンの罹患や転帰の履歴情報等が、顧客情報管理部５１により保険ＤＢ７１に格納して管理される。
なお、上述の情報は、適宜保険会社Ｈにより取得されてもよい。
このようなログイン情報等に基づいて、顧客の疑似名寄のための中間データベースが作成される。

そして、保険会社Ｚにおいて「山田太郎（ヤマダタロウ）」が新規の契約を結ぼうとする場合においては、情報閲覧制御部５７は、保険ＤＢ７１に記憶された、顧客を紐づける情報を参照して、情報の閲覧の制御を実行させる。即ち、情報閲覧制御部５７は、保険会社Ｘに対して「山田太郎」の最新の顧客情報を取得し、保険会社Ｙの「山田太朗」の情報を取得可能に閲覧の制御を実行する。
これにより、保険会社Ｘ及び保険会社Ｙにおける顧客の最新の保険の加入状況の情報の取得が可能となるのである。

更に言えば、上述の例では、ヤマダタロウの氏名の漢字の誤記についての名寄であったが、氏名や携帯電話番号が同一で、住所が異なる場合においても同様に疑似名寄ができる。即ち、上述した、「氏名：山田太郎、フリガナ：ヤマダタロウ、住所：東京都中央区……」、「氏名：山田太朗、フリガナ：ヤマダタロウ、住所：東京都中央区……」といった２つの異なる住所の契約についても名寄が可能となる。
このとき、この２つのデータを用いて、他の保険会社Ｈ等に照会することもできる。これにより、名寄しきれていない同一の顧客（ヤマダタロウ）についての最新の保険の加入状況も、取得可能となる。

また、一般に保険契約においては、契約者（契約の主体であって保険料を負担する者）となえり得る顧客の他に、被保険者（保険の対象であって、死亡保険においては被保険者が死亡した場合に保険金の支払いが発生する）や、保険金受取人（保険金が支払われる先となる者）などの複数の種類の人物が関連して登録される。
一般には、顧客たる契約者の情報が最もリッチな情報として、その契約者を基準に保険会社既存システムＨＳのデータベースに格納されている。即ち、被保険者や、保険金受取人の情報は、契約者の情報と比較して少ないことがあり得る。しかしながら、本サービスでは、上述の中間データベースにより、同一の保険の被保険者や保険金受取人についても紐づける。
なお、被保険者の中間データベースの作成方法と、閲覧の制御の方法については、上述の顧客（契約者）と基本的に同様に実現することができる。

これにより、複数の保険会社Ｈのデータベースの夫々に対して、ある特定の被保険者の保険の加入状況や、ある特定の保険金受取人についての保険の加入状況について、照会することが可能となる。
具体的には、例えば、保険会社Ｈ１における、「契約者が山田太郎であり被保険者が山田花子である死亡保険」と、保険会社Ｈ２における「契約者が山田次郎であり被保険者が山田花子である死亡保険」とが名寄せされて照会される。
このような、名寄により、顧客や被保険者等の同一性が担保されるため、その顧客に対して、保険の加入しすぎ、不足している保険の提案、より良い保険の提案等が、可能となる。
更に言えば、名寄せは、バッチ処理等によって行うこともできるが、上述の保険ＡＰＩを用いてその都度保険会社既存システムＨＳ等に照会がなされるため、即座の加入の可否の判断や提案が可能となるのである。

なお、上述の例では、死亡保険といった人（被保険者）に対する保険を例として説明したが、火災保険や地震保険においては家屋について、破損保険や盗難保険においては物品についても同様に名寄せされる。
これにより、家屋について火災保険や地震保険、物品についての破損保険、盗難保険についても、保険の加入しすぎ、不足している保険の提案といったより良い保険の提案等を即座に行うことが可能となる。

また、上述の例では、保険システム基盤ＨＢは、保険ＡＰＩを用いて、保険会社既存システムＨＳに対して各種情報の照会を行うものとしたが、適宜代理店既存システムＤＳに対して各種情報の照会が行われてもよい。

更に、上記の保険金額のＡＰＩによるデータ取得以外にも、ヤマダタロウの保険会社既存システムＨＳにおける加入済みの保険の情報や家族構成等の情報を取得することで、保険業のＣＶＲ（コンバージョン率）やＰｒｏｆｉｔａｂｉｌｉｔｙ（利潤）を予測することが可能となる。
即ち、保険会社既存システムＨＳに対して紹介することで把握できる顧客であるヤマダタロウの加入済の保険の情報を鑑みれば、みなおしが必要な（例えば加入しすぎ）保険や、不足している（例えば、加入したほうが良い）保険について提案が可能となる。
具体的には例えば、保険会社既存システムＨＳから照会により取得した情報から「扶養している子供が２２歳になっている時期であるが、大きな死亡保険を契約しているものの医療保険加入がない状態」である旨がわかる場合、死亡保険を解約し、医療保険加入を促すことはヤマダタロウのニーズに合致した提案となる。

また例えば、Ｐｒｏｆｉｔａｂｉｌｉｔｙについても同様である。つまり、保険料を所与とした時には、保険業のＰｒｏｆｉｔａｂｉｌｉｔｙは保険金支払の蓋然性（例えば、がん保険であれば、がんの罹患確率）に基づいて予測することができる。即ち、保険会社既存システムＨＳから照会により取得した情報にヤマダタロウの健康診断結果やワクチン接種履歴などが含まれている場合、がんになる可能性を、単なる保険の加入時に収集される情報（年齢、性別、過去の通院履歴の有無等）よりも精緻にＰｒｏｆｉｔａｂｉｌｉｔｙを予測できる。

次に、以下、本サービスにおける、上述の顧客の保険料の収納をするロジックを提供する機能である保険料課金ロジック機能について、具体的な利用例を用いながら説明する。

即ち、保険の契約は、一度加入した後、状況が変化した場合、再度同様の保険に加入することが困難となることがある。特に、医療保険において、被保険者の健康状態が悪化した場合には、これは顕著である。
そのため、例えば、契約者において契約を継続したいという意志や財力があるにもかかわらず、月払いで引き落とされる保険料（掛け金）の引き落としが、何らかの理由で行われなかったとする。このような場合においても、その契約は、すぐに無効（失効）とならず、１ヵ月から２ヵ月程度の所定の猶予期間が設けられることが一般的である。
これにより、例えば、保険料の支払い用のクレジットカードの有効期限が切れて新たなクレジットカードの情報の入力が必要な場合に、契約者がそれを失念してしまったときにおいても、その契約はその所定の猶予期間において救済され得る。
また一度失効した保険も契約者の希望があれば再度有効化（復活）できるケースも存在する。これは保険契約の重要性や公共性に関わる要請であると考えられる。

保険商品は、このような複雑な金融商品であるため、保険会社Ｈの各社それぞれによって失効及び再度有効化（復活）の取り扱いは異なることが多い。また例えば、生命保険と損害保険とでは、類似した用語が異なる意味を持つものも多い。例えば、生保の失効（上述）は、損保では保険料不払解除と呼ばれたりする。

具体的には例えば、第１の顧客が、８月１０日に同時に保険会社Ｘと保険会社Ｙの夫々により提供される月払いで保険料を支払う保険契約を締結（加入）したとする。そして、８月及び９月の保険料は、両社ともに無事支払い（収納）されたとする。１０月の保険料について、Ｘ社は１０月１日の課金（自動引き落とし等）であったが課金に失敗したとする。これに対し、Ｙ社は１０月１０日での課金であったが課金に失敗したとする。
更に、Ｘ社の約款（保険法や行政の認可によって成り立っている、以下同様）によれば１１月１日から１１月３０日までに１０月保険料の入金が確認されれば失効しない。そして、Ｙ社の約款によれば、１１月１０日から１２月９日までに入金が確認されれば失効しない。このように、複数の保険会社により、課金（自動引き落としなど）の日が異なる場合、失効させないために入金すべき期間が異なることになる。更に言えば、失効させないために入金すべき期間の長さについても、上述の例では１ヵ月であったが、各社の間でそれと異なる約款となっている可能性もある。
また、例えば、仮にどちらも失効したとしても、Ｘ社では、失効後の復活を取り扱っており、Ｙ社では復活を取り扱っていない、ということもあり得る。更に言えば、Ｘ社では復活が可能であるが、再度健康状態に関する健康診断書や告知事項を示さなければならない。

このように、本サービスの保険システム基盤ＨＢは、保険の課金の失敗時の取り扱いにおいて、各会社の約款に基づいて、課金の失敗後の処理を適切に実行することができるのである。

上述の保険会社既存システムＨＳとの情報の連携においては、以下のような処理もなされる。具体的には、本サービスの保険システム基盤ＨＢと接続された保険会社Ｘと保険会社Ｙが存在するとする。そして、ヤマダタロウという顧客は、保険会社ＸにおいてはＫＹＣ（本人確認）やＡＭＬ（資産や負債の総合管理）の確認が済んでいるとする。
このような前提のもと、保険システム基盤ＨＢは、保険会社Ｙにヤマダタロウが保険の申込にきたとき、保険会社Ｘにおいて済んでいるＫＹＣやＡＭＬに関する情報を、保険システム基盤ＨＢを介してＹ保険会社に提供することができる。
即ち、情報閲覧制御部５７は、保険会社Ｘによる保険の提供に関するヤマダタロウの情報のうち、所定条件を満たすもの、又は当該第１種顧客情報を加工した情報については、閲覧（提供）の禁止を解除し、保険会社Ｙに提供することができる。

ここで、保険業は規制業であり、個人情報の取り扱いは法令の変化等によりダイナミックに変化していく。そこで、本保険会社既存システムＨＳは、これに対応する。
また、個人情報の中でも保険業特有な病歴等の機微情報などはたとえ顧客の合意があったとしても情報を保険会社間でシェアすることは法律等により認められない可能性が有る。そこで、本サービスの保険システム基盤ＨＢは、シェア可能な最大範囲で、情報を匿名化する。
例えば、保険システム基盤ＨＢには保険会社Ｘのシステムに存在する情報は全て存在すると仮定した場合、情報閲覧制御部５７は、顧客の所定の病歴関連の情報をスコアリングさせ、Ｙ保険会社のシステムから本サービス経由で当該顧客の情報照会があった際には、スコアリングされた病歴スコアリングのスコアのみを保険会社Ｙに返すことができる。これにより、機微情報そのものではなく、その顧客の加工されたスコアが保険会社Ｙに提供される。これにより、保険会社Ｙは、その法律等により認められない機微情報ではなく、スコアに基づいて、顧客に提案を行うことが可能となるのである。

また、本サービスは、保険会社Ｈ１（Ｘ保険会社）から保険システム基盤ＨＢに提供されたＣ顧客の情報、即ち、Ｃ顧客の第１種顧客情報のうち、ＫＹＣ（マイナンバ、免許証等）やＡＭＬ（反社チェック等）については、代理店Ｄ１（Ａ代理店）等の他の「保険に関する役務の提供者」にシェアすることで、顧客Ｃや「保険に関する役務の提供者」の手間を省くことができる。

また、本サービスの保険システム基盤ＨＢは、以下のような予測結果の情報を、複数の保険会社Ｈ間に提供することができる。
具体的ンヒア、前提として、具体的には、本サービスの保険システム基盤ＨＢと接続された保険会社Ｘと保険会社Ｙが存在するとする。即ち、本サービスの保険システム基盤ＨＢと、保険会社Ｘの保険会社既存システムＨＳ、保険システム基盤ＨＢと保険会社Ｙの保険会社既存システムＨＳとはそれぞれ接続されているとする。
この前提のもと、ヤマダタロウがさらに保険会社Ｚに保険申し込みをした際に、保険会社Ｘ及び保険会社Ｙにより管理された情報に基づいた予測結果を保険会社Ｚに返すことができる。

ここで、予測には２通り存在する。
第１に、記載内容の正しさについて説明する。
例えば、保険会社Ｚに対して申し込みされた自動車保険の対象の自動車について、ヤマダタロウは新車と入力したが、保険会社Ｘにより管理された（例えば、保険会社Ｘの保険会社既存システムＨＳ等に格納されている）情報に基づけば、その自動車は、中古車であると判定される場合が存在し得る。即ち、このような場合、結果として保険会社Ｚへの保険申し込みにおける虚偽申し込みを判定することができる。
これにより、保険会社ＺのＰｒｏｆｉｔａｂｉｌｉｔｙを上昇させることができる。

また例えば、保険会社Ｚに対して申し込みされた自動車保険の申込書等に記載されたヤマダタロウの住所は新しい住所であるが、保険会社Ｙにより管理されている（保険会社Ｙの保険会社既存システムＨＳ等に格納されている）の住所はアップデートされていない場合が存在し得る。このような場合、保険会社Ｚの担当者端末ＨＴの画面上においては、本サービスを介して提供される保険会社Ｙにより管理されている情報のアップデートを促すことが可能となる。これにより、顧客は、保険会社Ｙへの情報のアップデートを失念していたとしても、アップデートを可能とするとともに、都度の手続が不要となり利便性が向上する。

また例えば、本サービスの保険システム基盤ＨＢは、保険会社Ｘにより管理されている（保険会社Ｘの保険会社既存システムＨＳ等に格納されている）顧客たるヤマダタロウの家族構成や既保険契約の情報を参照することができる。これにより、ヤマダタロウにとって不足している保険情報（保険商品や保険商品で保護される要素等）を予測できる。そこで、そのような不足している保険商品を保険会社Ｚの担当者端末ＨＴの画面等でレコメンドする。これにより、保険契約のＣＶＲを向上させることができる。

第２の予測は、将来のＰｒｏｆｉｔａｂｉｌｉｔｙである。
ここでいうＰｒｏｆｉｔａｂｉｌｉｔｙは、例えば、医療保険の場合であれば、将来ヤマダタロウが病気になる（ならない）確率をいう。
まず、保険会社Ｚの保険商品の申込時点で、保険会社Ｘにより管理されている（保険会社Ｘの保険会社既存システムＨＳ等に格納されている）健康情報予測に役立つデータを匿名化（もしくは上述のスコアリング化等）する加工を行う。そして、保険システム基盤ＨＢは、保険会社Ｚ等の他の保険会社Ｈは適切な保険商品やその保険料の提案を顧客たるヤマダタロウに提案（提供）することができる。
また、顧客たるヤマダタロウにとっては、（データ不足による）過度に保守的な（高い）保険料ではなく、適切な量の保険料を提案されるメリットがある。
また、このような意図での保険会社Ｈ側の接続先としては、厚生労働省データベース等の公的なデータベースも含まれる。
一般に保険会社Ｘ、Ｙ、Ｚの各社の保険会社既存システムＨＳはレガシー化しているのが膣場である。そのため、保険会社既存システムＨＳをセキュアに外部データベースと接続することは困難である。しかしながら、保険会社既存システムＨＳは本サービスの保険システム基盤ＨＢを介することでセキュアに、外部接続のメリット（情報の授受等）を享受することが可能となる。

また、保険システム基盤ＨＢは、保険商品作成機能（制約確認機能を含む）により生成された各代理店Ｄ１乃至ＤＱ毎の夫々の保険商品について、商品ページ及び申し込みフォームＳＦをノーコードで自動的に生成する生成機能を有している。換言すると、このような所定の団体に向けた保険商品作成機能（制約確認機能を含む）及び生成機能が、団体向けポータル機能である。これについて、以下、例を用いて具体的に説明する。

その団体に所属する者（契約者の候補）の属性に対して、どういう保険が（ＣＶＲ， ｐｒｏｆｉｔａｌｉｂｙｔの観点共に）良いはずだ、というデータベースが本サービスにおいて蓄積される。

本サービスは複数の保険代理店（代理店Ａ、代理店Ｂ、代理店Ｃ・・）と繋がっている。代理店がＢ２Ｃプラットフォーマ（例えば小売店等を運営するプラットフォーマ）である場合においては、本業として顧客とさまざまなデータのやりとりを行っているケースがある。即ち例えば、プラットフォーマは、プラットフォーマで出している小売店のブランドのクレジットカード等の取引情報を有している。また例えば、顧客の年齢性別のみならず購買データや、ロイヤリティーマーケティングが他の所定業者のポイントの付与状況経由で、購買のみならずレジャー行動データ等も取得していることがある。

そのため、本サービスの保険システム基盤ＨＢには、多くの代理店での保険商品購買データが存在し得る、特に、各種ＡＢテストを通じて、どのような代理店にはどのような訴求方法・訴求内容が良いかのデータが溜まっている。新たな代理店Ｄが本サービスに接続される際に、例えば以下のデータを受け取ることで、既存接続済代理店Ａ，Ｂ，Ｃでの経験を一定自動的に反映することができる。

４０代の女性が多めであれば、赤色のＬａｎｄｉｎｇ Ｐａｇｅにすることが良い、などが反映される。また例えば、家族構成も反映できる。
具体的には例えば、子育て世代であれば、子供の画像を多用する、介護世帯であれば祖父母の画像を多用する、などを反映される。
また例えば、平均世帯年収（もしくはそれを暗示するもの）が反映される。具体的には例えば、年収が高い場合にはよりラグジュアリーでリッチな保障内容を提示することができる。
更に言えば、もしくはもっと簡単に、代理店Ｄの顧客の傾向を定性的に代理店Ｄにアンケートするだけでも意味がある可能性がある。例えば、”より安定志向 ｏｒ よりリスクテイク志向”などを反映することができる。

上記のような事前情報により、一定程度、ＣＶＲやＰｒｏｆｉｔａｂｉｌｉｔｙが最適化されたＬａｎｄｉｎｇ Ｐａｇｅを構築することが可能であるが、さらに、世の中の動向（例えば、新型感染症が猛威をふるう、自動車は自動運転が主流になる）が変わるにつれて、最適なものも変化するため、複数の代理店のＣＶＲ， Ｐｒｏｆｉｔａｂｉｌｉｔｙの分析結果を本サービスで統合し、常にその時点での最適解が提供できるようなものを提供可能とすることができる。

また例えば、上述の実施形態では、保険システム基盤ＨＢと接続されるのは、保険会社Ｈ又は代理店Ｄの夫々が管理する各装置とされたが、特にこれに限定されず、「保険に関する役務の提供者」の他情報処理装置であれば足りる。

また、図５に示すシステム構成、及び図６に示すサービス提供者サーバ１のハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。

また、図７に示す機能ブロック図は、例示に過ぎず、特に限定されない。即ち、上述した保険システム基盤ＨＢにより実現可能な各機能が所定の情報処理装置（例えばサービス提供者サーバ１）に備えられていれば足り、この機能を実現するためにどのような機能ブロック及びデータベースを用いるのかは、特に図７の例に限定されない。
また、機能ブロック及びデータベースの存在場所も、図７に限定されず、任意でよい。

また、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。
また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

以上をまとめると、本発明が適用される情報処理装置は、次のような構成を有していれば足り、各種各様な実施の形態を取ることができる。
即ち、本発明が適用される情報処理装置（例えば図５のサービス提供者サーバ１）は、
保険に関する役務の提供者の他情報処理装置（例えば図７の保険会社Ｈの保険会社既存システムＨＳや代理店Ｄの担当者端末ＤＴ）と通信をする情報処理装置において、
前記保険の加入者又は加入の候補者を顧客として、当該顧客に関する情報を第１種顧客情報として所定のデータベース（例えば図７の保険ＤＢ７１）に格納して管理する第１種顧客情報管理手段（例えば図７の顧客情報管理部５１）と、
所定情報（例えば図３の顧客の氏名年齢等）の入力をトリガとして、前記第１種顧客情報管理手段の管理外であって前記他情報処理装置（例えば図７の保険会社Ｈの保険会社既存システムＨＳ）により管理されている前記顧客に関する第２種顧客情報（例えば顧客に付与された図３の保険金額等）を出力するＡＰＩ（例えば明細書でいう保険ＡＰＩ）が前記他情報処理装置に構築されており、前記所定情報を前記他情報処理装置に送信することで前記第２種顧客情報を取得する制御を実行する第２種顧客情報取得手段（例えば図７の保険ＡＰＩ制御部５３）と、
を備えればよい。

さらに、情報処理装置は、
前記提供者はＮ人（Ｎは２以上の整数値）存在し（例えば図５の例では、Ｐ人の保険会社Ｈ１乃至ＨＰ及びＱ人の代理店Ｄ１乃至ＤＱが存在し）、前記情報処理装置はＮの他情報処理装置と夫々通信し、
前記Ｎ人の提供者のうちＭ（ＭはＮ以下の整数値）の提供者により夫々提供される保険又は保険商品について、所定単位（例えば図４の１行の項目単位）毎に情報を抽出する保険情報抽出手段（例えば図７の保険情報抽出部５４）と、
前記保険情報抽出手段により前記所定単位毎に抽出された前記情報に基づいて、前記保険に関する所定機能の発揮に必要なパラメータを１以上抽出するパラメータ抽出手段（例えば図７のパラメータ生成部５５）と、
前記１以上のパラメータに基づいて、前記提供者により設定された規定、法令（例えば一人の被保険者に対してのガン保険の保険金額の上限など）を含む制約の範囲内で前記所定機能を発揮させる処理を実行する機能発揮手段（例えば図７の機能発揮部５６）と、
をさらに備えることができる。
例えば図７のノーコードツール生成部６１により発揮される所定機能は、保険商品の商品ＬＰ（商品ページ）又は申し込みフォームをノーコードで生成可能にする機能であるようにすることができる。
例えば図７の保険料金ロジック生成部６２により発揮される所定機能は、顧客による保険料金の収納をする機能であるようにすることができる。さらに、当該所定機能は、前記顧客による前記保険料金の少なくとも一部としてポイントで収納する機能であるようにすることができる。
例えば図７の団体向ポータル生成部６３により発揮される定機能は、団体向けの商品ＬＰを生成する機能であるようにすることができる。

また、情報処理装置は、
前記提供者はＮ人（Ｎは２以上の整数値）存在し（例えば図５の例では、Ｐ人の保険会社Ｈ１乃至ＨＰ及びＱ人の代理店Ｄ１乃至ＤＱが存在し）、前記情報処理装置はＮの他情報処理装置と夫々通信し、
前記Ｎ人の提供者のうち所定提供者の前記他情報処理装置から前記第１種顧客情報の提供が依頼された場合、当該所定提供者による役務の提供に関する当該第１種顧客情報の提供を許可し、当該所定提供者以外の提供者による役務の提供に関する当該第１種顧客情報の提供を禁止する第１種顧客情報提供手段（例えば図７の情報閲覧制御部５７）
をさらに備えるようにすることができる。
さらに、前記第１種顧客情報提供手段は、
前記所定提供者以外の提供者による役務の提供に関する前記第１種顧客情報のうち、所定条件を満たすもの、又は当該第１種顧客情報を加工した情報については、提供の禁止を解除するようにすることもできる。

１・・・サービス提供者サーバ、１１・・・ＣＰＵ、１２・・・ＲＯＭ、１３・・・ＲＡＭ、１６・・・入力部、１７・・・出力部、１８・・・記憶部、１９・・・通信部、２０・・・ドライブ、４０・・・リムーバブルメディア、５１・・・顧客情報管理部、５２・・・商品ページ・申し込みフォーム管理部、５３・・・保険ＡＰＩ制御部５３、５４・・・保険情報抽出部、５５・・・パラメータ生成部、５６・・・機能発揮部５６、６１・・・保険ＤＢ、ＨＢ・・・保険システム基盤、Ｈ，Ｈ１乃至ＨＰ・・・保険会社、ＨＴ、ＨＴ１乃至ＨＴＰ・・・担当者端末、ＨＳ１乃至ＨＳＰ・・・保険会社既存システム、Ｄ、Ｄ１乃至ＤＱ・・・代理店、ＤＴ、ＤＴ１乃至ＤＴＱ・・・担当者端末、ＤＳ、ＤＳ１乃至ＤＳＱ・・・代理店既存システム

Claims (10)

1. 保険に関する役務の提供者の他情報処理装置と通信をする情報処理装置において、
   前記保険の加入者又は加入の候補者を顧客として、当該顧客に関する情報を第１種顧客情報として所定のデータベースに格納して管理する第１種顧客情報管理手段と、
   所定情報の入力をトリガとして、前記第１種顧客情報管理手段の管理外であって前記他情報処理装置により管理されている前記顧客に関する第２種顧客情報を出力するＡＰＩが前記他情報処理装置に構築されており、前記所定情報を前記他情報処理装置に送信することで前記第２種顧客情報を取得する制御を実行する第２種顧客情報取得手段と、
   を備える情報処理装置。
2. 前記提供者はＮ人（Ｎは２以上の整数値）存在し、前記情報処理装置はＮの他情報処理装置と夫々通信し、
   前記Ｎ人の提供者のうちＭ（ＭはＮ以下の整数値）の提供者により夫々提供される保険又は保険商品について、所定単位毎に情報を抽出する保険情報抽出手段と、
   前記保険情報抽出手段により前記所定単位毎に抽出された前記情報に基づいて、前記保険に関する所定機能の発揮に必要なパラメータを１以上抽出するパラメータ抽出手段と、
   前記１以上のパラメータに基づいて、前記提供者により設定された規定と法令とを含む制約の範囲内で前記所定機能を発揮させる処理を実行する機能発揮手段と、
   をさらに備える請求項１に記載の情報処理装置。
3. 前記所定機能は、保険商品の商品ＬＰ又は申し込みフォームをノーコードで生成可能にする機能である、
   請求項２に記載の情報処理装置。
4. 前記所定機能は、前記顧客による保険料金の収納をする機能である、
   請求項２に記載の情報処理装置。
5. 前記所定機能は、前記顧客による前記保険料金の少なくとも一部としてポイントで収納する機能である、
   請求項４に記載の情報処理装置。
6. 前記所定機能は、団体向けの商品ＬＰを生成する機能である、
   請求項２に記載の情報処理装置。
7. 前記提供者はＮ人（Ｎは２以上の整数値）存在し、前記情報処理装置はＮの他情報処理装置と夫々通信し、
   前記Ｎ人の提供者のうち所定提供者の前記他情報処理装置から前記第１種顧客情報の提供が依頼された場合、当該所定提供者による役務の提供に関する当該第１種顧客情報の提供を許可し、当該所定提供者以外の提供者による役務の提供に関する当該第１種顧客情報の提供を禁止する第１種顧客情報提供手段
   をさらに備える請求項１に記載の情報処理装置。
8. 前記第１種顧客情報提供手段は、
   前記所定提供者以外の提供者による役務の提供に関する前記第１種顧客情報のうち、所定条件を満たすもの、又は当該第１種顧客情報を加工した情報については、提供の禁止を解除する、
   請求項７に記載の情報処理装置。
9. 保険に関する役務の提供者の他情報処理装置と通信をする情報処理装置が実行する情報処理方法において、
   前記保険の加入者又は加入の候補者を顧客として、当該顧客に関する情報を第１種顧客情報として所定のデータベースに格納して管理する第１種顧客情報管理ステップと、
   所定情報の入力をトリガとして、前記第１種顧客情報管理ステップの処理で行われる管理外であって前記他情報処理装置により管理されている前記顧客に関する第２種顧客情報を出力するＡＰＩが前記他情報処理装置に構築されており、前記所定情報を前記他情報処理装置に送信することで前記第２種顧客情報を取得する制御を実行する第２種顧客情報取得ステップと、
   を含む情報処理方法。
10. 保険に関する役務の提供者の他情報処理装置と通信をするコンピュータに、
    前記保険の加入者又は加入の候補者を顧客として、当該顧客に関する情報を第１種顧客情報として所定のデータベースに格納して管理する第１種顧客情報管理ステップと、
    所定情報の入力をトリガとして、前記第１種顧客情報管理ステップの処理で行われる管理外であって前記他情報処理装置により管理されている前記顧客に関する第２種顧客情報を出力するＡＰＩが前記他情報処理装置に構築されており、前記所定情報を前記他情報処理装置に送信することで前記第２種顧客情報を取得する制御を実行する第２種顧客情報取得ステップと、
    を含む制御処理を実行させるプログラム。

Images