特許 6046793 銀行システム、銀行システムによって実行される方法およびプログラム

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

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

(11)【特許番号】6046793

(24)【登録日】2016年11月25日

(45)【発行日】2016年12月21日

(54)【発明の名称】銀行システム、銀行システムによって実行される方法およびプログラム

(51)【国際特許分類】

   G06Q 40/08 20120101AFI20161212BHJP

   G06Q 40/02 20120101ALI20161212BHJP

【ＦＩ】

   G06Q40/08

   G06Q40/02

【請求項の数】9

【全頁数】18

(21)【出願番号】特願2015-245345(P2015-245345)

(22)【出願日】2015年12月16日

【審査請求日】2015年12月16日

(73)【特許権者】

【識別番号】397077955

【氏名又は名称】株式会社三井住友銀行

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】坂東 完雄

【審査官】 関 博文

(56)【参考文献】

【文献】 特開２００３−１０８７７０（ＪＰ，Ａ）

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

【文献】 特開２００４−１１８７３２（ＪＰ，Ａ）

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

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

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

Ｇ０６Ｑ １０／００−９９／００

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

【請求項1】

保険商品の銀行窓販を支援するための銀行システムであって、
前記銀行システムは、１または複数の生保システムと通信可能なように構成され、かつ１または複数の顧客端末と通信可能なように構成されており、
前記銀行システムは、
顧客情報を格納する顧客マスタと、
保険商品に関連付けられた設計書元データを格納するデータベースと、
入力された顧客データに基づいて前記設計書元データを前記データベースに格納し、かつ前記データベースに格納されている前記設計書元データを、前記設計書元データによって示される前記生保システムに送信するデータ処理手段であって、送信される前記設計書元データは、前記設計書元データを識別する識別子および契約者識別情報を含む、データ処理手段と、
前記生保システムによって生成された設計書番号と、前記識別子と、前記契約者識別情報とを含む第１のデータを受信する設計書番号取得手段であって、前記設計書番号は、前記設計書元データに基づく設計書データを識別し、前記設計書データは、前記生保システムによって保持され、前記銀行システムに提供される、設計書番号取得手段と、
前記第１のデータに含まれる前記契約者識別情報に基づいて、前記顧客マスタの対応する顧客データに、前記第１のデータに含まれる前記設計書番号をセットすることにより、前記セットされた設計書番号に関連付けられる前記設計書データを前記顧客端末から閲覧可能にするマッチング処理手段と、
前記閲覧可能になった前記設計書データに対する申込を示す信号を前記顧客端末から受信する申込受信処理手段と、
申込のあった前記設計書データに関連付けられる前記識別子を前記生保システムに送信する申込データ送信手段と、
前記生保システムから受信された前記識別子および証券番号に基づいて、前記顧客マスタおよび前記データベースを更新する証券番号受信処理手段と
を備えた銀行システム。

【請求項2】

前記申込受信処理手段は、前記顧客端末に保険料変更を可能とするアプリケーションを提供し、かつ前記顧客端末からの保険料変更操作に応答して前記生保システムと通信することにより、変更後の保険料の情報を前記顧客端末に提供する、請求項１に記載の銀行システム。

【請求項3】

前記申込受信処理手段は、前記保険料の変更が行われたことを条件として、内容変更があったことを示すフラグに予め定められた値をセットすることにより前記データベースを更新する、請求項２に記載の銀行システム。

【請求項4】

前記顧客端末からのアクセスに応答して前記銀行システムによる認証処理が行われた後、前記申込受信処理手段は、顧客ＩＤに関連付けられる顧客識別情報に基づいて前記顧客マスタを検索し、前記顧客ＩＤに対応する設計書番号が前記顧客マスタ内に存在する場合に、前記データベースに問い合わせを行って、閲覧可能な保険商品の設計書のデータを顧客端末に提供する、請求項１に記載の銀行システム。

【請求項5】

前記顧客マスタは、顧客が検討している保険商品が有効なものであるかどうかを示す第１のフラグをさらに有し、
前記申込受信処理手段は、前記証券番号の受信に応答して、前記第１のフラグに、加入済みの保険商品であることを示す値をセットする、請求項１に記載の銀行システム。

【請求項6】

前記顧客マスタは、顧客が検討している保険商品が有効なものであるかどうかを示す第１のフラグをさらに有し、
前記銀行システムは、予め定められた期間の経過後、前記第１のフラグに、無効を示す値をセットする、請求項１に記載の銀行システム。

【請求項7】

前記データベースは、顧客が銀行の窓口以外で保険商品の申込をしたことを示す第２のフラグを有し、
前記閲覧可能になった前記設計書データに対する申込を示す信号を受信したことに応答して、前記第２のフラグが更新される、請求項１に記載の銀行システム。

【請求項8】

保険商品の銀行窓販を支援するための銀行システムによって実行される方法であって、
前記銀行システムは、１または複数の生保システムと通信可能なように構成され、かつ１または複数の顧客端末と通信可能なように構成されており、
前記銀行システムは、
顧客情報を格納する顧客マスタと、
保険商品に関連付けられた設計書元データを格納するデータベースと
を備え、前記方法は、
入力された顧客データに基づいて前記設計書元データを前記データベースに格納し、かつ前記データベースに格納されている前記設計書元データを、前記設計書元データによって示される前記生保システムに送信することであって、送信される前記設計書元データは、前記設計書元データを識別する識別子および契約者識別情報を含む、ことと、
前記生保システムによって生成された設計書番号と、前記識別子と、前記契約者識別情報とを含む第１のデータを受信することであって、前記設計書番号は、前記設計書元データに基づく設計書データを識別し、前記設計書データは、前記生保システムによって保持され、前記銀行システムに提供される、ことと、
前記第１のデータに含まれる前記契約者識別情報に基づいて、前記顧客マスタの対応する顧客データに、前記第１のデータに含まれる前記設計書番号をセットすることにより、前記セットされた設計書番号に関連付けられる前記設計書データを前記顧客端末から閲覧可能にすることと、
前記閲覧可能になった前記設計書データに対する申込を示す信号を前記顧客端末から受信することと、
申込のあった前記設計書データに関連付けられる前記識別子を前記生保システムに送信することと、
前記生保システムから受信された前記識別子および証券番号に基づいて、前記顧客マスタおよび前記データベースを更新することと
を備える方法。

【請求項9】

請求項８に記載の方法をコンピュータに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、銀行システム、銀行システムによって実行される方法およびプログラムに関する。より詳細には、本発明は、銀行において生命保険などの保険商品を販売する際（いわゆる、銀行窓販の際）に使用される銀行システム、銀行システムによって実行される方法およびプログラムに関し、店頭チャネルとインターネットチャネルの両方の販売チャネルを取り扱い可能な銀行システム、銀行システムによって実行される方法およびプログラムに関する。

【背景技術】

【0002】

様々な保険会社が今の時代のニーズに合った保険商品を開発し、個人や法人などに提供している。個人が保険に加入しようとする場合、任意の保険会社の営業担当者からその会社の保険商品の説明をうけて加入したり、保険会社に資料請求をして検討した後、郵送などで申込をしたり、パソコン（ＰＣ）などを使用して最初に自分である程度調べてからインターネット経由で見積もりや申込を行ったりすることができることが知られている。また近年、銀行窓販といって、銀行が登録を受けて保険募集を行うことも知られており、銀行窓販の対象となる保険は、生命保険（例えば、医療、がん、死亡、介護保障などを対象とする保険）や損害保険（例えば、自動車保険など）の多岐に亘っている。銀行は、預金、貸付、為替業務以外に保険に関する手続きも同じ営業店内の窓口で顧客に対して提供することができるため、個人にとっては、複数の店舗に行く必要がなく便利なものとなってきつつある。

【0003】

上述したように、個人が保険に加入しようとする場合、利用可能なチャネルは複数存在しているが、それぞれのチャネルにはメリットとデメリットが存在している。既知のデメリットに対しては様々な対応が取られており、例えば、保険契約者から受け取る書面に何かしらの不備がある場合に、その訂正のために契約者のもとを営業職員が再訪しなければならず、そのために申込受付から引受査定開始までに数日単位の遅延が引き起こされるという問題に対して、営業職員を支援するためのシステムが知られていた（特許文献１）。あるいは、保険会社の実情に即して営業活動をより効率的に行うために、営業職員がインターネットを介して個々の顧客に、顧客に応じた保険に関する情報を提示することができる営業活動支援システムが知られていた（特許文献２）。

【0004】

これらのチャネルの一つである銀行窓販は、銀行の窓口担当者が顧客の状況を面前で聞いた上で顧客のニーズ（顧客自身が気付いていないものも含む）に合った保険商品を提案することができるというメリットを有するものの、保険商品の相談・提案に関する業務にはより多くの時間がかかることが多いため、限られた時間内では保険の加入に至らないこともあり、当該顧客が説明を受けた保険に加入しようと思っても再び、銀行の窓口に出向かなければならないという不便さが存在していた。一方、他のチャネル、例えば、請求した資料に基づいて保険の申込をしたり、インターネット経由で保険の申込をしたりするチャネルの場合、個人が自宅などにいながらにして簡便に手続きを行えるというメリットがあるものの、保険の知識が豊富な営業担当者と相談をする機会が非常に限られているため、保険の知識に必ずしも詳しくない個人には自分に本当に適した保険を選択することが、難しい場合もあるというデメリットもあった。

【0005】

また、従来、銀行で取引可能なのは銀行システム内に取引先番号（ＣＩＦ（Customer Information File）番号ともいう）が登録されている顧客に限られていた。ＣＩＦは、銀行システムにおいて、各業務共通の顧客マスタに位置づけられるものであり、預金を始めとする、銀行との取引を新規に行う場合には、ＣＩＦが登録されることが知られている。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２０１４−２１７４３号公報

【特許文献2】特開２０１４−１１８５５１号公報

【発明の概要】

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

【0007】

上述したように、保険の申込は、大まかに分類すると、店頭（生命保険会社の外交員による顧客訪問を含む）およびインターネットの２種類のチャネルによって行われていた。しかしながら、現在までのところ、両方のチャネル（オムニチャネル）を使用して保険申込ができるシステムは存在していなかった。

【0008】

本願発明は、このような課題に鑑みてなされたものであり、保険商品の銀行窓販を支援するために、対面での保険説明とＷｅｂ経由での保険申込を取り扱い可能なオムニチャネル対応の、銀行システム、銀行システムによって実行される方法およびプログラムを提供することを目的とする。

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

【0009】

本発明の一態様である、保険商品の銀行窓販を支援するための銀行システムは、１または複数の生保システムと通信可能なように構成され、かつ１または複数の顧客端末と通信可能なように構成されており、前記銀行システムは、顧客情報を格納する顧客マスタと、保険商品に関連付けられた設計書元データを格納するデータベースと、入力された顧客データに基づいて前記設計書元データを前記データベースに格納し、かつ前記データベースに格納されている前記設計書元データを、前記設計書元データによって示される前記生保システムに送信するデータ処理手段であって、送信される前記設計書元データは、前記設計書元データを識別する識別子および契約者識別情報を含む、データ処理手段と、前記生保システムによって生成された設計書番号と、前記識別子と、前記契約者識別情報とを含む第１のデータを受信する設計書番号取得手段であって、前記設計書番号は、前記設計書元データに基づく設計書データを識別し、前記設計書データは、前記生保システムによって保持され、前記銀行システムに提供される、設計書番号取得手段と、前記第１のデータに含まれる前記契約者識別情報に基づいて、前記顧客マスタの対応する顧客データに、前記第１のデータに含まれる前記設計書番号をセットすることにより、前記セットされた設計書番号に関連付けられる前記設計書データを前記顧客端末から閲覧可能にするマッチング処理手段と、前記閲覧可能になった前記設計書データに対する申込を示す信号を前記顧客端末から受信する申込受信処理手段と、申込のあった前記設計書データに関連付けられる前記識別子を前記生保システムに送信する申込データ送信手段と、前記生保システムから受信された前記識別子および証券番号に基づいて、前記顧客マスタおよび前記データベースを更新する証券番号受信処理手段とを備える。

【0010】

本発明の一態様である、保険商品の銀行窓販を支援するための銀行システムによって実行される方法では、前記銀行システムは、１または複数の生保システムと通信可能なように構成され、かつ１または複数の顧客端末と通信可能なように構成されており、前記銀行システムは、顧客情報を格納する顧客マスタと、保険商品に関連付けられた設計書元データを格納するデータベースとを備え、前記方法は、入力された顧客データに基づいて前記設計書元データを前記データベースに格納し、かつ前記データベースに格納されている前記設計書元データを、前記設計書元データによって示される前記生保システムに送信することであって、送信される前記設計書元データは、前記設計書元データを識別する識別子および契約者識別情報を含む、ことと、前記生保システムによって生成された設計書番号と、前記識別子と、前記契約者識別情報とを含む第１のデータを受信することであって、前記設計書番号は、前記設計書元データに基づく設計書データを識別し、前記設計書データは、前記生保システムによって保持され、前記銀行システムに提供される、ことと、前記第１のデータに含まれる前記契約者識別情報に基づいて、前記顧客マスタの対応する顧客データに、前記第１のデータに含まれる前記設計書番号をセットすることにより、前記セットされた設計書番号に関連付けられる前記設計書データを前記顧客端末から閲覧可能にすることと、前記閲覧可能になった前記設計書データに対する申込を示す信号を前記顧客端末から受信することと、申込のあった前記設計書データに関連付けられる前記識別子を前記生保システムに送信することと、前記生保システムから受信された前記識別子および証券番号に基づいて、前記顧客マスタおよび前記データベースを更新することとを備える。

【発明の効果】

【0011】

本発明によれば、対面での保険説明とＷｅｂ経由での保険申込を取り扱い可能な、オムニチャネル対応の銀行システム、当該銀行システムによって実行される方法およびプログラムを提供することが可能となる。

【0012】

本発明によれば、顧客は後日に保険の加入をじっくりと検討することができるので、銀行窓口での時間を短縮することが可能となる。従来は、保険商品の相談・提案に関する業務に多くの時間がかかっていたが、限られた時間内に加入申込まで完了させなくてもよくなるため、顧客および銀行の担当者共に大幅に時間短縮を図ることができ、顧客利便性も飛躍的に向上することになる。また、顧客が銀行の担当者と面前で相談することが可能となるので、顧客ニーズにより即した保険商品の選択が可能となる。

【0013】

従来の銀行窓販では、銀行と各生命保険会社との間で書類のやり取りが発生しており、それに伴うデータ入力作業なども発生していたため、最終的に保険証券が発行されるまでに数日かかっていたが、本発明によれば、銀行システムと生保システムとの間でのデータ連携が図れることになるので、銀行窓口で相談したその日のうちに保険証券の発行まで完了することができるようになる。また、本発明によれば、銀行内の顧客口座と保険契約のデータとが即時連携可能な状態となり、人手による処理が激減し、内部管理がしやすくなる。

【図面の簡単な説明】

【0014】

本明細書において開示される実施形態の詳細な理解は、添付図面に関連して例示される以下の説明から得ることができる。

【図1】本発明に係る銀行システムを含むシステム全体の概要図である。

【図2】本発明に係る銀行システムのシステム構成図である。

【図3】顧客マスタのデータ構造の一例を説明する図である。

【図4】設計書ＤＢのデータ構造の一例を説明する図である。

【図5】保険商品の銀行窓販の際に銀行システムおよびＩＢシステムによって実行される処理フローの一例を説明するフロー図である。

【図6】本発明に係る銀行システムの機能ブロック図である。

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

【0015】

以下、本発明の実施形態について詳細に説明する。図１は、本発明に係る銀行システム１００を含むシステム全体の概要図である。図１を参照すると、銀行システム１００は、共同ゲートウェイ（ＧＷ）サーバ１１０を介して１または複数の生保システム１２０ａ、１２０ｂ、１２０ｃ（本明細書では説明の便宜上、これらを一括して「生保システム１２０」と呼ぶこととする）にネットワークを経由して接続されることが可能である。銀行システム１００と、生保システム１２０との間のネットワークとして、専用線を例にして説明するが、本発明で利用可能なネットワークは専用線に限定されることはなく、同様の機能を果たす他の種類のネットワークを利用することも可能である。

【0016】

銀行システム１００は、周知の勘定系システムの他、インターネット（登録商標）を通じて残高照会や振込、振替などの銀行のサービスを提供するインターネットバンキング（ＩＢ）システム１３０を備えることができる。銀行システム１００およびＩＢシステム１３０は、生保システム１２０と通信することにより、生保システム１２０によって提供される、保険窓販支援のためのアプリケーションを利用することができる。すなわち、銀行の営業担当者などは、保険窓販支援のためのアプリケーションを通じて、任意の生命保険会社の保険商品の情報にアクセスし、設計書を作成するためのデータを入力することによって設計書を作成することができる。

【0017】

銀行システム１００は、顧客端末１４０ａ、１４０ｂ、１４０ｃ（本明細書では説明の便宜上、これらを一括して「顧客端末１４０」と呼ぶこととする）とインターネットなどを通じて接続可能であり、例えば、顧客端末１４０は、ＩＢシステム１３０が提供する１または複数の銀行のサービスを利用することができる。顧客は、顧客端末１４０を操作してＩＢシステム１３０にアクセスし、さらに生保システム１２０とも通信することにより、当該顧客のために作成された設計書のデータを参照することができる。設計書のデータは、生保システム１２０内に記憶され、顧客端末１４０からのアクセスに応じて銀行システム１００（ＩＢシステム１３０）を通じて顧客端末１４０に提供されることが可能であるが、本発明の一実施形態では、生保システム１２０が設計書のデータを銀行システム１００に所定の周期で送信しておき、銀行システム１００が受信した設計書のデータを銀行システム１００内（例えば、設計書ＤＢ２０７内）に格納しておき、顧客端末１４０からのアクセスに応じて顧客端末１４０に設計書のデータを提供してもよい。

【0018】

共同ＧＷサーバ１１０は、銀行システム１００と、１または複数の生保システム１２０とを仲介する機能を果たすことができるコンピュータである。共同ＧＷサーバ１１０は、銀行システム１００を運営する銀行によって管理／運営されてもよく、あるいは任意の第三者によって管理／運営されてもよいＡＳＰ（Application Service Provider）サーバとすることが可能である。

【0019】

生保システム１２０のそれぞれは、生保システム１２０のそれぞれを管理／運営する生命保険会社などによって提供される保険商品のデータを銀行システム１００に対して提供し、顧客の所望の保険商品に対する設計書を作成するためのアプリケーション機能を提供し、顧客のために作成された１または複数の設計書のデータを格納することができる。保険商品のデータは、各生保システム１２０内の保険商品のデータベースに格納されることが可能であり、１または複数の設計書のデータは、各生保システム１２０内の契約データベースに格納されることが可能である。設計書を作成するための元データは銀行システム１００および／またはＩＢシステム１３０内に格納されることも可能である。保険加入時に作成される設計書は、保険への加入を検討している顧客に対し、保険や保障の内容を詳しく説明するために提示する書類であり、保険の契約内容（主契約、特約などを含む）、保険料払込方法、契約者・被保険者などの情報以外にも、契約申込書、取扱報告書（補足資料含む）、受取人指定書なども含む、従来から存在する書類である。このため、本明細書では、設計書に記載される各項目についての詳細な説明は省略することとする。設計書のデータは、生保システム１２０のそれぞれにおいて格納されてもよいし、あるいは銀行システム１００内に格納されてもよい。さらに、生保システム１２０のそれぞれと銀行システム１００の両方に格納されるように構成されてもよく、かかる場合には、両方のデータは適時に同期されるように構成されうる。

【0020】

顧客端末１４０は、インターネットなどのネットワークを介して銀行システム１００、特に、ＩＢシステム１３０と通信可能なように接続されることが可能である。顧客端末１４０は、保険の申込を検討している顧客の端末であり、例えば、有線環境および／または無線環境において動作可能なパーソナルコンピュータ（ＰＣ）、タブレット型端末、ラップトップ、携帯情報端末、ユーザ機器（ＵＥ）、スマートフォンなどの任意のタイプのデバイスとすることができる。本明細書では、顧客端末１４０と、銀行システム１００／ＩＢシステム１３０との間のネットワークとしてインターネットを例にして説明するが、同様の機能を果たす他の種類のネットワークを利用することも可能である。

【0021】

図１に示されるようなシステムでは、保険への加入を検討している顧客は、銀行窓口にて提案を受けた、自らのニーズ（顧客自身が気付いていなかったものも含む）に合った１または複数の保険商品に対する、仮登録された１または複数の設計書のデータを顧客端末１４０を介して参照しながら保険の申込を行うことができる。さらに、顧客は、設計書のデータのうちの一部、例えば、保険料の支払方法について修正を試みるシミュレーションを顧客端末１４０を介して行うことができる。本発明の一実施形態では、銀行および生命保険会社で用意したいくつかのパターンを選択することによって当該シミュレーションが行われてもよいし、あるいは、顧客が任意の数値を変更することによってシミュレーションが行われてもよい。そのため、銀行の窓口に何度も行く必要がなくなり、かつインターネットなどを利用して自分で調べるよりも自らのニーズにより即した保険商品の申込が可能となる。なお、仮登録された１または複数の設計書のデータに対して有効期限（例えば、作成から１ヶ月）を設定することが可能であり、銀行システム１００および／または生保システム１２０は、有効期限が経過したデータを無効にして顧客が参照できないようにすることができる。

【0022】

図２は、本発明に係る銀行システム１００のシステム構成図である。図２に示すように、銀行システム１００は、一般的なコンピュータと同様に、バス２１０などによって相互に接続された制御部２０１、主記憶部２０２、補助記憶部２０３、インターフェース（ＩＦ）部２０４および出力部２０５を備えることができる。銀行システム１００はまた、ファイル／データベースとして、顧客マスタ２０６および設計書ＤＢ２０７を備えることができる。

【0023】

制御部２０１は、中央処理装置（ＣＰＵ）とも呼ばれ、銀行システム１００内の各構成要素の制御やデータの演算を行い、また、補助記憶部２０３に格納されている各種プログラムを主記憶部２０２に読み出して実行することができる。主記憶部２０２は、メインメモリとも呼ばれ、受信した各種データ、コンピュータ実行可能な命令および当該命令による演算処理後のデータなどを記憶することができる。補助記憶部２０３は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データやプログラムを長期的に保存する際に使用される。

【0024】

図２の実施形態では、制御部２０１、主記憶部２０２および補助記憶部２０３を同一のサーバコンピュータ内に設ける実施形態について説明したが、他の実施形態として、銀行システム１００は、制御部２０１、主記憶部２０２および補助記憶部２０３を複数個使用することにより、複数のサーバコンピュータによる並列分散処理を実現するように構成されることもできる。また、他の実施形態として、銀行システム１００用の複数のサーバを設置し、複数サーバが一つの補助記憶部２０３を共有する実施形態にすることも可能である。

【0025】

ＩＦ部２０４は、他のシステムや装置との間でデータを送受信する際のインターフェースの役割を果たし、また、システムオペレータから各種コマンドや入力データ（各種マスタ、テーブルなど）を受け付けるインターフェースを提供することができる。出力部２０５は、処理されたデータを表示する表示画面や当該データを印刷するための印刷手段などを提供することができる。

【0026】

顧客マスタ２０６は、銀行顧客の基礎情報を格納する顧客マスタファイルであり、ＣＩＦとも言われるマスタファイルである。顧客が銀行との取引を新規に行う場合には、顧客マスタ２０６に顧客情報が登録されることになる。なお、保険への加入に際して、窓口を訪れた顧客は銀行との取引があるものの、被保険者は銀行との取引がない場合もある（例えば、夫婦のうち妻が銀行との取引があるが、夫である被保険者には銀行との取引がない場合）が、その場合には、顧客マスタ２０６に銀行との取引がなかった被保険者などのデータが登録されることになる。

【0027】

図３は、顧客マスタ２０６のデータ構造の一例を説明する図である。図３に示すように、顧客マスタ２０６は、店番号３０１、取引先番号３０２、銀行口座情報３０３、属性情報３０４、および設計書番号／証券番号３０５を含むことができるが、これらのデータ項目に限定されることはなく他の任意のデータ項目も含むことが可能である。例えば、顧客マスタ２０６は、届出印鑑の印影、所有するクレジットカードの種類、暗証番号などの情報を含むように構成されてもよく、顧客が同一銀行内の複数の営業店に口座を保有する場合に、それらの口座を結びつける共通番号（例えば、「名寄せ」処理などの際に利用可能な個人識別番号）を含むように構成されてもよい。このような共通番号は、顧客を識別するための番号として使用されることが可能なため、他の金融機関の顧客マスタにも格納されることが可能である。かかる場合には、当該共通番号に基づいて、複数の金融機関が保有する顧客の情報を関連付けることも可能となる。また、顧客マスタ２０６は、顧客の口座情報の共通データ項目として、複数のアプリケーションで利用されることができる。

【0028】

店番号３０１は、銀行顧客を管理するそれぞれの営業店を識別する番号であり、取引先番号３０２は、当該営業店における顧客を識別する番号である。店番号３０１および取引先番号３０２を合わせてＣＩＦ番号（取引先番号）と呼ぶこともできる。すなわち、図３の実施形態では、店番号３０１および取引先番号３０２を異なるデータ項目として示したが、両者を合わせて１つのデータ項目として構成することもできる。また、他の実施形態として、取引先番号３０２のみを銀行内で利用可能な顧客識別番号として利用することも可能であり、かかる場合には、ある取引先番号３０２は、複数の営業店に存在することはなく、その銀行内で唯一無二の番号として使用される。

【0029】

銀行口座情報３０３は、顧客の銀行口座の情報であり、店番号、科目、口座番号、口座名義などの情報を含むことができる。属性情報３０４は、顧客の氏名、カナ氏名、住所、連絡先などの情報を含むことができる。

【0030】

設計書番号／証券番号３０５は、顧客が加入を検討している１または複数の保険商品に関連付けられた設計書のデータの識別番号、および顧客が正式に保険に加入した際に発行される保険証券に付された証券番号を示す。設計書番号／証券番号３０５は、設計書ＤＢ２０７に格納されている設計書を作成するための元データを識別する番号として機能することもできる。なお、設計書は書面の形式で作成されるものであるため、設計書を作成するための元データとは、設計書に含まれる各種データのことを指す。

【0031】

設計書番号／証券番号３０５は、有効フラグを有することが可能である。有効フラグに予め定められた値（例えば、有効を示す「１」）がセットされている場合には、設計書番号／証券番号３０５によって識別される保険商品の設計書番号／証券番号が「既に加入済みの保険商品」の設計書番号／証券番号であることを示す。本発明において、銀行の窓口で相談した結果１または複数の設計書が作成されると、当該設計書に対応する設計書番号が当該顧客の顧客マスタ２０６の設計書番号／証券番号３０５に設定されることになる。有効フラグの初期値はＮｕｌｌであってよい。その後、顧客がＩＢシステム１３０を通じて正式に申し込んだ後、所定のデータ処理後に発行された証券番号が当該顧客の顧客マスタ２０６の設計書番号／証券番号３０５に設定されることになる。証券番号が設定された後、有効フラグに予め定められた値（例えば、有効を示す「１」）がセットされてよい。なお、顧客が提案された保険商品の内容を検討した結果、加入しないと判断した場合には、所定の期限が到来するなど、予め定められた条件が満たされた場合に無効を示す値（例えば、「０」）が設計書番号／証券番号３０５の有効フラグにセットされることになる。

【0032】

図２に戻って説明すると、設計書ＤＢ２０７は、顧客が加入を検討している、または既に加入済みの、１または複数の保険商品の設計書を作成するための元データを格納するデータベースである。本発明の一実施形態では、設計書ＤＢ２０７は、生保システム１２０から受信した設計書のデータを格納するようにさらに構成されることも可能である。本発明の一実施形態では、設計書ＤＢ２０７は、銀行システム１００内に存在しているが、それぞれの生保システム１２０内に当該生命保険会社などが提供する保険商品に対する設計書のデータ（最終生成物たる設計書だけでなく、その元データも含む）を格納する設計書ＤＢが存在してもよい。

【0033】

図４は、設計書ＤＢ２０７のデータ構造の一例を説明する図である。保険加入時に作成される設計書は、保険への加入を検討している顧客に対し、保険や保障の内容を詳しく説明するために提示する書類であり、保険の契約内容（主契約、特約などを含む）、保険料払込方法、契約者・被保険者などの情報以外にも、契約申込書、取扱報告書（補足資料含む）、受取人指定書なども含む、従来から存在する書類である。このため、本明細書では、設計書に記載される各項目についての詳細な説明は省略することとする。

【0034】

図４に示したように、設計書ＤＢ２０７は、データ項目として、保険会社コード４０１、設計書番号／証券番号４０２、受付管理ＩＤ４０３、保険商品名４０４、契約者生年月日４０５、契約者名４０６、保険内容４０７、保険料明細４０８および提案内容４０９を含むことができる。なお、本発明に係る設計書ＤＢ２０７は、これら以外の任意のデータ項目を含むことも可能であり、他の実施形態では、これらのデータ項目をさらに細分化したデータ構造を採用してもよい。

【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】

１００ 銀行システム
１１０ 共同ゲートウェイ（ＧＷ）サーバ
１２０ 生保システム
１３０ インターネットバンキング（ＩＢ）システム
１４０ 顧客端末
２０１ 制御部
２０２ 主記憶部
２０３ 補助記憶部
２０４ インターフェース（ＩＦ）部
２０５ 出力部
２０６ 顧客マスタ
２０７ 設計書ＤＢ
６０１ データ処理部
６０２ 設計書番号取得部
６０３ マッチング処理部
６０４ 申込受信処理部
６０５ 申込データ送信部
６０６ 証券番号受信処理部

【要約】      （修正有）

【課題】保険商品の銀行窓販を支援する銀行システムを提供する。
【解決手段】銀行システム１００は、顧客マスタ２０６と、保険商品の設計書元データを格納するＤＢ２０７と、設計書元データを識別する識別子および契約者識別情報を含む設計書元データを生保システムに送信し、生保システムによって生成された、設計書元データに基づく設計書データを識別する設計書番号を含む第１のデータを受信し、生保システムによって銀行システムに提供される。銀行システムはさらに、顧客マスタの対応する顧客データに、第１のデータに含まれる設計書番号をセットし、関連する設計書データを顧客端末から閲覧可能し、設計書データに対する申込を顧客端末から受信し、申込のあった設計書データに関連する識別子を生保システムに送信し、生保システムから受信した識別子および証券番号に基づいて、顧客マスタおよびＤＢを更新する。
【選択図】図６

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】