(57)【要約】【課題】複数の保険会社の保険商品に対する申込を行うことができるようにする。【解決手段】  携帯装置１０は、複数の保険会社３が提供する保険商品のそれぞれについて、保険商品の申込に必要な申込情報の入力項目を定義する画面定義記憶部１３４を備える。申込画面生成部１１４は、申込の対象となる保険商品に対応する画面定義情報に基づいて申込画面５３を生成する。申込情報作成部１１７は、申込画面５３に入力された情報を含む申込情報を作成する。【選択図】図１
2016170469.tif 000002
【特許請求の範囲】
【請求項１】
複数の保険会社から提供される保険の申込を受け付けるシステムであって、
前記保険のそれぞれについて、前記保険の申込に必要な申込情報の入力項目を記憶する入力項目記憶部と、
申込の対象となる保険に対応する前記入力項目を前記入力項目記憶部から特定し、特定した前記入力項目に係る情報の入力を受け付けるための入力欄を表示する入力欄表示部と、
前記入力欄に入力された前記情報を含む前記申込情報を作成する申込情報作成部と、
を備えることを特徴とする保険申込システム。
【請求項２】
請求項１に記載の保険申込システムであって、
前記保険の申込者の自署による署名を表す画像である自署画像を受け付ける署名入力部をさらに備え、
前記申込情報作成部は、前記自署画像を前記申込情報に含めて作成すること、
を特徴とする保険申込システム。
【請求項３】
請求項１または２に記載の保険申込システムであって、
前記申込情報を記憶する申込情報記憶部をさらに備え、
前記入力欄表示部は、前記申込情報記憶部に前記申込情報が記憶されている場合は、前記申込情報記憶部から前記申込情報を読み出し、読み出した前記申込情報に含まれている前記情報を前記入力欄の初期値として設定すること、
を特徴とする保険申込システム。
【請求項４】
請求項１に記載の保険申込システムであって、
前記保険会社に前記申込情報を送信する申込情報送信部と、
前記申込情報に不備があった場合に、前記保険会社から前記申込情報に対する不備を指摘した情報を受信する不備情報受信部と、
前記不備に対する回答を入力する不備回答入力部と、
をさらに備えることを特徴とする保険申込システム。
【請求項５】
複数の保険会社から提供される保険の申込を受け付ける方法であって、
前記保険のそれぞれについて、前記保険の申込に必要な申込情報の入力項目を記憶する入力項目記憶部を備えるコンピュータが、
申込の対象となる保険に対応する前記入力項目を前記入力項目記憶部から特定し、特定した前記入力項目に係る情報の入力を受け付けるための入力欄を表示するステップと、
前記入力欄に入力された前記情報を含む前記申込情報を作成するステップと、
を実行することを特徴とする保険申込方法。
【請求項６】
複数の保険会社から提供される保険の申込を受け付けるためのプログラムであって、
前記保険のそれぞれについて、前記保険の申込に必要な申込情報の入力項目を記憶する入力項目記憶部を備えるコンピュータに、
申込の対象となる保険に対応する前記入力項目を前記入力項目記憶部から特定し、特定した前記入力項目に係る情報の入力を受け付けるための入力欄を表示するステップと、
前記入力欄に入力された前記情報を含む前記申込情報を作成するステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、保険申込システム、保険申込方法およびプログラムに関する。
【背景技術】
【０００２】
携帯端末を用いて保険契約を支援するシステムが提案されている。たとえば、特許文献１では、携帯端末と保険契約支援システムとをインターネットを介して接続させて申込を行うことにより、保険契約の申込受付および引受査定を迅速化するシステムが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−０２１７４３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載のシステムでは特定の保険会社が提供する保険商品に対する申込ができるにすぎず、複数の保険会社の保険商品への申込を行うことができない。
【０００５】
本発明は、このような背景を鑑みてなされたものであり、複数の保険会社の保険商品に対する申込を行うことのできる、保険申込システム、保険申込方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するための本発明の主たる発明は、複数の保険会社から提供される保険の申込を受け付けるシステムであって、前記保険のそれぞれについて、前記保険の申込に必要な申込情報の入力項目を記憶する入力項目記憶部と、申込の対象となる保険に対応する前記入力項目を前記入力項目記憶部から特定し、特定した前記入力項目に係る情報の入力を受け付けるための入力欄を表示する入力欄表示部と、前記入力欄に入力された前記情報を含む前記申込情報を作成する申込情報作成部と、を備えることとする。
【０００７】
また、本発明の保険申込システムは、前記保険の申込者の自署による署名を表す画像である自署画像を受け付ける署名入力部をさらに備え、前記申込情報作成部は、前記自署画像を前記申込情報に含めて作成するようにしてもよい。
【０００８】
また、本発明の保険申込システムは、前記申込情報を記憶する申込情報記憶部をさらに備え、前記入力欄表示部は、前記申込情報記憶部に前記申込情報が記憶されている場合は、前記申込情報記憶部から前記申込情報を読み出し、読み出した前記申込情報に含まれている前記情報を前記入力欄の初期値として設定するようにしてもよい。
【０００９】
また、本発明の保険申込システムは、前記保険会社に前記申込情報を送信する申込情報送信部と、前記申込情報に不備があった場合に、前記保険会社から前記申込情報に対する不備を指摘した情報を受信する不備情報受信部と、前記不備に対する回答を入力する不備回答入力部と、をさらに備えるようにしてもよい。
【００１０】
また、本発明の他の態様は、複数の保険会社から提供される保険の申込を受け付ける方法であって、前記保険のそれぞれについて、前記保険の申込に必要な申込情報の入力項目を記憶する入力項目記憶部を備えるコンピュータが、申込の対象となる保険に対応する前記入力項目を前記入力項目記憶部から特定し、特定した前記入力項目に係る情報の入力を受け付けるための入力欄を表示するステップと、前記入力欄に入力された前記情報を含む前記申込情報を作成するステップと、を実行することとする。
【００１１】
また、本発明の他の態様は、複数の保険会社から提供される保険の申込を受け付けるためのプログラムであって、前記保険のそれぞれについて、前記保険の申込に必要な申込情報の入力項目を記憶する入力項目記憶部を備えるコンピュータに、申込の対象となる保険に対応する前記入力項目を前記入力項目記憶部から特定し、特定した前記入力項目に係る情報の入力を受け付けるための入力欄を表示するステップと、前記入力欄に入力された前記情報を含む前記申込情報を作成するステップと、を実行させることとする。
【００１２】
その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。
【発明の効果】
【００１３】
本発明によれば、複数の保険会社の保険商品に対する申込を行うことができる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態の保険申込システムに係る保険の申込を説明する図である。
【図２】本実施形態の保険申込システムの全体構成を示す図である。
【図３】携帯装置１０、サーバ２０および保険会社装置３０として用いられるコンピュータのハードウェア構成例を示す図である。
【図４】携帯装置１０のソフトウェア構成例を示す図である。
【図５】顧客情報記憶部１３１に記憶される顧客情報の構成例を示す図である。
【図６】商品情報記憶部１３２に記憶される商品情報の構成例を示す図である。
【図７】案件情報記憶部１３３に記憶される案件情報の構成例を示す図である。
【図８】顧客選択部１１１が表示する顧客一覧表示画面５１の一例を示す図である。
【図９】案件選択部１１２が表示する案件一覧表示画面５２の一例を示す図である。
【図１０】画面定義記憶部１３４に記憶される画面定義情報の構成例を示す図である。
【図１１】申込画面生成部１１４が生成する申込画面５３の一例を示す図である。
【図１２】サーバ２０のソフトウェア構成例を示す図である。
【図１３】申込情報作成部１１７が作成する申込情報の構成例を示す図である。
【図１４】ひな形画像記憶部１３５の構成例を示す図である。
【図１５】帳票定義記憶部１３６に記憶される帳票定義情報の構成例を示す図である。
【図１６】不備情報記憶部１３７に記憶される不備情報の構成例を示す図である。
【図１７】保険会社装置３０のソフトウェア構成を示す図である。
【図１８】携帯装置１０により実行される処理の流れを示す図である。
【図１９】画面定義情報の更新処理の流れを示す図である。
【図２０】申込情報の入力処理の流れを示す図である。
【図２１】サーバ２０により実行される処理の流れを示す図である。
【図２２】帳票の印刷処理の流れを示す図である。
【図２３】不備訂正処理の流れを示す図である。
【図２４】保険会社３において行われる業務の流れを示す図である。
【発明を実施するための形態】
【００１５】
以下、本発明の一実施形態に係る保険申込システムについて説明する。本実施形態では、保険会社３の代理店２に所属する営業担当者２１が顧客１に対して保険商品の提案を行い、それに対して顧客１が申込を行うことを想定する。代理店２は複数の保険会社３の複数の商品からなるラインナップを揃える。商品のラインナップは２０〜３０商品にわたることがある。営業担当者２１は顧客１のニーズにあわせて商品提案を行う。保険の申込手続に関し、保険会社３および保険商品毎に申込書類の様式や記入項目が異なる。また１件の申込手続において５種類程度の書類記入が必要となる煩雑な作業となっている。代理店２の営業担当者２１は、顧客１を訪問する保険販売活動にあたり、申込書類に商品パンフレット、約款等をセットにしたもの（申込みキットなどと呼ばれる。）を複数商品のそれぞれについて持参している。営業担当者２１が顧客１の希望する保険商品の申込みキットを持参していなかった場合には、営業機会を逸失することになってしまう。その一方で、売れ筋となる商品は、顧客ニーズや景気動向などに左右されて変わるため、代理店２は取扱商品の入れ替えを頻繁に行っており、たとえば四半期ごとに取扱商品を入れ替えることもある。
【００１６】
そこで、本実施形態の保険申込システムでは、図１に示すように、顧客１は営業担当者２１の携帯装置１０を用いて保険の申込を行うようにしている。これにより、営業担当者２１が申込みキットを持参せずとも、携帯装置１０の統一された画面インタフェースには複数の保険会社３の保険商品が提示され、顧客１は複数の保険の中から申し込む保険を決めることができる。なお、携帯端末１０を用いて商品パンフレットや約款など各種の情報を顧客１に提示することができるが、本実施形態では申込についての説明のみを行う。
【００１７】
＝＝システム構成＝＝
図２は、本実施形態の保険申込システムの全体構成を示す図である。本実施形態の保険申込システムは、携帯装置１０およびサーバ２０を含んで構成され、携帯装置１０とサーバ２０とは通信路４１を介して通信可能に接続される。サーバ２０はまた、保険会社装置３０と通信路４２を介して通信可能に接続される。通信路４１および通信路４２はそれぞれ独立した通信路であってもよいし、インターネットのように共通した通信路であってもよい。通信路４１および通信路４２は、たとえば、公衆電話回線網、専用電話回線網、イーサネット（登録商標）、無線通信回線などにより構築される、たとえばインターネット、ＶＡＮ（Value Added Network）、ＬＡＮ（Local Area Network）などである。
【００１８】
携帯装置１０は、代理店２の担当者が携帯するコンピュータである。携帯装置１０には、たとえばタブレットコンピュータやスマートフォン、ノート型のパーソナルコンピュータなどを採用することができる。本実施形態では、携帯装置１０はタッチパネルディスプレイを備えるタブレットコンピュータであるものとする。携帯装置１０は、顧客１の面前で保険商品についての情報を表示する表示装置として機能するとともに、保険の申込に必要な情報を顧客１に入力させるための入力装置としても機能する。
【００１９】
サーバ２０は代理店２が運用するコンピュータである。サーバ２０には、たとえばパーソナルコンピュータやワークステーションなどを採用することができる。サーバ２は、顧客１に関する情報（以下、顧客情報という。）、保険会社３が提供する保険商品についての情報（以下、商品情報という。）、顧客１に保険商品を提案している担当者２１の営業活動（以下、担当者２１による顧客１別の営業活動を案件という。）に関する情報（以下、案件情報という。）、保険商品への申込に必要な情報（以下、申込情報という。）などを管理する。本実施形態では、申込情報には、保険商品に対する申込書、意向確認書、告知書など、保険契約に必要な各種の書面に記入すべき項目を含むものとする。サーバ２０は申込情報の各項目を表示するための情報（以下、画面定義情報という。）を管理しており、携帯装置１０はサーバ２０から画面定義情報を取得し、取得した画面定義情報に基づいて申込情報の入力欄を作成することができる。
【００２０】
保険会社装置３０は保険会社３が運用するコンピュータである。保険会社３は保険会社装置３０がサーバ２０から受信した申込情報に基づいて保険加入に係る審査を行う。申込情報に不備があった場合には、保険会社３は保険会社装置３０に不備を入力し、当該不備に関する情報（以下、不備情報という。）を保険会社装置３０がサーバ２０に送信し、代理店２の担当者２１または顧客１により不備が解消されたうえで審査が行われる。
【００２１】
＝＝コンピュータ＝＝
図３は携帯装置１０、サーバ２０および保険会社装置３０として用いられるコンピュータのハードウェア構成例を示す図である。コンピュータは、ＣＰＵ１０１、メモリ１０２、記憶装置１０３、通信インタフェース１０４、入力装置１０５、出力装置１０６を備える。記憶装置１０３は、各種のデータやプログラムを記憶する、例えばハードディスクドライブやソリッドステートドライブ、フラッシュメモリなどである。通信インタフェース１０４は、通信路４１および通信路４２に接続するためのインタフェースであり、例えばイーサネット（登録商標）に接続するためのアダプタ、公衆電話回線網に接続するためのモデム、無線通信を行うための無線通信機、シリアル通信のためのＵＳＢ（Universal Serial Bus）コネクタやＲＳ２３２Ｃコネクタなどである。入力装置１０５は、データを入力する、例えばキーボードやマウス、ボタン、マイクロフォンなどである。出力装置１０６は、データを出力する、例えばディスプレイやプリンタ、スピーカなどである。携帯装置１０は入力装置１０５および出力装置１０６を複数備えることもできる。また、入力装置１０５および出力装置１０６を、１つのタッチパネルディスプレイにより実現することも可能であり、本実施形態では少なくとも携帯装置１０は、入力装置１０５および出力装置１０６としてタッチパネルディスプレイを備えるものとする。
＝＝携帯装置１０＝＝
【００２２】
図４は、携帯装置１０のソフトウェア構成例を示す図である。携帯装置１０は、選択部１１、入力部１２、不備解決部１３、データ管理部１４を備える。
【００２３】
＜選択部１１＞
選択部１１は、代理店２の担当者２１が、応対する顧客１および当該顧客１に係る案件を選択するための機能を提供する。選択部１１は、顧客選択部１１１、案件選択部１１２、顧客情報記憶部１３１、商品情報記憶部１３２および案件情報記憶部１３３を備える。
【００２４】
顧客情報記憶部１３１は、顧客情報を記憶する。図５は顧客情報記憶部１３１に記憶される顧客情報の構成例を示す図である。顧客情報には、顧客１を特定するための情報（以下、顧客ＩＤという。）に対応付けて、顧客１の氏名（契約者氏名）、当該氏名の読み仮名（カナ）、顧客１が有する口座の番号（口座番号）などが含まれる。なお、顧客情報には、図５に示した項目以外にも顧客１に関する情報（たとえば顧客１の性別、職業、電話番号、メールアドレスなど）を任意に含めることができる。
【００２５】
商品情報記憶部１３２は、商品情報を記憶する。図６は、商品情報記憶部１３２に記憶される商品情報の構成例を示す図である。図６に示すように、商品情報には、保険商品を特定する情報（以下、商品ＩＤという。）に対応付けて、当該保険商品を提供する保険会社を特定する情報（保険会社）、当該保険商品の種類（保険種別）、当該保険商品の名称などが含まれる。商品ＩＤは商品情報記憶部１３２において一意な情報である。保険会社を特定する情報は、保険会社の名称（保険会社名）であり、図１の例のように３社の保険を取り扱う場合には、保険会社名には「保険会社Ａ」「保険会社Ｂ」または「保険会社Ｃ」のいずれかが設定される。なお、保険会社に関する情報を保険会社マスタに管理するようにし、保険会社を特定する情報として保険会社マスタにおけるレコードを指定する識別情報（保険会社ＩＤ）を設定するようにしてもよい。保険種別には、保険種別を示すコード（保険種別ＩＤ）を設定するようにしてもよい。
【００２６】
案件情報記憶部１３３は、案件情報を記憶する。図７は、案件情報記憶部１３３に記憶される案件情報の構成例を示す図である。案件情報には、案件を特定する情報（以下、案件ＩＤという。）に対応付けて、当該案件に係る顧客１を特定する顧客ＩＤ、当該案件において担当者２１が顧客１に提案している保険商品を特定する商品ＩＤ、当該案件の状態（ステータス）などが含まれる。ステータスには、各種の状態を示す情報を含めることができるが、本実施形態では、「仮入力」「本入力」「承認済」「審査中」「不備」「成立」などが設定されるものとする。ステータスが「仮入力」の場合は、顧客１の保険商品に対する申込情報の入力が予め担当者２１により行われたこと（仮入力と呼ばれる。）を示す。ステータスが「本入力」の場合は、顧客１により保険商品に対する申込情報が入力（補完）されて（本入力と呼ばれる。）、申込がなされたことを示す。ステータスが「承認済」の場合は、代理店２において顧客１が申込を行うことの承認が行われたことを示す。ステータスが「審査中」の場合、申込情報または申込情報に基づいて作成された帳票が保険会社３に送信または送付されて保険会社３において審査が行われていることを示す。ステータスが「不備」の場合には、申込情報に何らかの不備があったことを示す。ステータスが「成立」の場合には、保険商品に係る契約が成立したことを示す。
【００２７】
顧客選択部１１１は、顧客情報を一覧表示する。顧客選択部１１１は、顧客情報記憶部１３１に記憶されている顧客情報を読み出して、読み出した顧客情報をタッチパネルディスプレイに一覧表示する。図８は、顧客選択部１１１が表示する顧客一覧表示画面５１の一例を示す図である。顧客一覧表示画面５１は顧客情報の一覧を表示する表示欄５１１を備える。図８の例では、顧客情報の口座番号と氏名（契約者氏名）との一覧が表示欄５１１に表示されているが、顧客情報中の任意の情報を出力してもよいし、顧客情報中の任意の情報に関する情報を出力するようにしてもよい。顧客一覧表示画面５１では、表示欄５１１をタップすることにより顧客情報が選択可能であるものとする。
【００２８】
案件選択部１１２は、案件情報を一覧表示する。案件選択部１１２は、案件情報記憶部１３３に記憶されている案件情報を読み出して、読み出した案件情報をタッチパネルディスプレイに一覧表示する。図９は、案件選択部１１２が表示する案件一覧表示画面５２の一例を示す図である。案件一覧表示画面５２は案件情報の一覧を表示する表示欄５２１を備える。図９の例では、案件情報に含まれる案件ＩＤ（案件Ｎｏ．）およびステータスに加えて、商品ＩＤに対応する商品情報に含まれる保険会社および名称（商品）が表示欄５２１に表示されている。案件選択部１１２は、図８の顧客一覧表示画面５１において顧客情報が選択されたことを契機として、選択された顧客情報の顧客ＩＤに対応する案件情報を案件選択部１１２から読み出し、読み出した案件情報のそれぞれについて、案件情報に含まれる商品ＩＤに対応する商品情報を商品情報記憶部１３２から読み出し、案件情報の案件ＩＤ、対応する商品情報の保険会社および名称、ならびに案件情報のステータスを表示欄５２１に一覧表示することにより図９に示すような表示欄５２１の表示が実現できる。
【００２９】
＜入力部１２＞
入力部１２は申込情報を入力するための機能を提供する。入力部１２は、申込情報取得部１１３、申込画面生成部１１４、申込項目入力部１１５、自署入力部１１６、申込情報作成部１１７、申込情報送信部１１８および画面定義記憶部１３４を備える。
【００３０】
申込情報取得部１１３は、顧客選択部１１１により選択された顧客ＩＤおよび案件選択部１１２により選択された商品ＩＤに対応する申込情報をサーバ２０から取得する。本実施形態では、申込情報取得部１１３は、申込情報を取得するためのコマンド（以下、申込情報取得要求という。）に上記顧客ＩＤおよび商品ＩＤを付帯させてサーバ２０に送信し、申込情報取得要求に応じてサーバ２０から応答される申込情報を受信するものとする。なお、申込情報取得部１１３は、各種の周知の手法を用いてサーバ２０から申込情報を取得するようにすることもできる。これにより、既に入力されている申込情報を編集することができる。
【００３１】
画面定義記憶部１３４は、申込情報の入力を受け付ける画面（以下、申込画面という。）における入力欄に関する情報（以下、画面定義情報という。）を記憶する。図１０は、画面定義記憶部１３４に記憶される画面定義情報の構成例を示す図である。同図に示すように、画面定義情報には、申込の対象となる保険商品を示す商品ＩＤに対応付けて、当該保険商品を提供する保険会社を特定する情報（保険会社）、申込情報の入力を受け付けるための申込画面を特定する情報（以下、画面ＩＤという。）、当該画面が備える入力欄の種類を示すパーツ種別、パーツ種別が示す入力欄に対応する申込情報の項目を示す項目ＩＤ、当該項目の値の入力を受け付けるためのオプション情報（項目オプション）が含まれる。パーツ種別には、たとえば、項目やカテゴリなどのタイトルを表示するラベルを示す「title」、文字列情報を入力するためのテキストボックスを示す「text#long」（所定の長めの長さの文字列）または「text#short｝（上記長めの長さよりも短い短めの文字列）、生年月日を入力する日付の入力欄と性別を入力するための選択ボタン等との組合せを示す「birth#and#sex」、告知書などの確認文書に対するチェックを入力するチェックボックスを示す「confirm#checkbox」、意向確認などの確認文書に対する「はい」または「いいえ」を入力する選択ボタンを示す「confirm#yesno」などが設定される。項目オプションには、たとえば、当該項目のデフォルト値、入力内容の妥当性確認（バリデーション）を行うか否か、当該入力欄に表示する項目タイトルなどが設定される。なお、項目オプションには、たとえば、複数選択を可能とするか否かなどの、データを入力する際の各種のオプションを設定することができる。
【００３２】
申込画面生成部１１４は、申込画面を生成する。申込画面生成部１１４は、画面定義記憶部１３４に記憶されている画面定義情報に応じて申込画面を生成する。申込画面生成部１１４は作成した申込画面を出力装置１０６に出力する。図１１は、申込画面生成部１１４が生成する申込画面５３の一例を示す図である。図１１の例では、申込画面５３には、「氏名」「フリガナ」「生年月日」「性別」「続柄」および「署名」を入力する入力欄が設けられている。もちろん、図１１に示されている項目以外の入力欄を申込画面５３に設けるようにしてもよいし、複数の画面で申込情報の項目を入力するように複数の申込画面５３を作成するようにしてもよい。
【００３３】
申込項目入力部１１５は、申込情報の各項目の入力を受け付ける。申込項目入力部１１５は、キーボードやタッチパネルのタップなどにより、文字列または数字のデータとして項目の入力を受け付ける。なお、入力欄への入力には一般的な処理を用いるものとしてここでは説明を省略する。たとえば、図１１の例では、申込項目入力部１１５は、「氏名」「フリガナ」および「続柄」の入力欄では、ソフトウェアキーボードを出力し、ソフトウェアキーボードからの入力を受け付け、「性別」の入力欄では、「男」「女」「法人」のいずれかがタップにより選択を受け付ける。
【００３４】
自署入力部１１６は、顧客１による署名の入力を受け付ける。自署入力部１１６は、画像として署名を受け付ける。図１１の例では、自署入力部１１６は、署名の入力欄においてタッチパネルディスプレイ上を指やスタイラスなどにより描画された画像を署名として受け付けることができる。
【００３５】
申込情報作成部１１７は、申込項目入力部１１５が受け付けた申込情報の各項目と自署入力部１１６が受け付けた署名の画像とを含む申込情報を作成する。
【００３６】
申込情報送信部１１８は、申込情報をサーバ２０に送信する。申込情報送信部１１８は、申込情報作成部１１７が申込情報を作成した後、申込情報をサーバ２０に送信する。
【００３７】
＜不備解決部１３＞
不備解決部１５は、申込情報に不備があった場合にその解決を図る機能を提供する。不備解決部１５は、不備情報受信部１１９、不備回答入力部１２０および不備情報記憶部１３７を備える。
【００３８】
不備情報受信部１１９は、申込情報の不備に関する情報（以下、不備情報という。）をサーバ２０から受信する。不備情報は、保険会社３が保険商品に対する申込を審査する過程で申込情報に不備があった場合に保険会社３からサーバ２０に送信されてくる情報である。不備情報受信部１１９は、受信した不備情報を表示する。
【００３９】
不備回答入力部１２０は、不備に対する顧客１からの訂正内容（不備回答）の入力を受け付ける。不備回答入力部１２０は、受け付けた不備回答に、不備情報を特定するための情報（以下、不備ＩＤという。）を付帯させてサーバ２０に送信する。
【００４０】
＜データ管理部１４＞
データ管理部１４は、データ受信部１２１、データ登録部１２２を備える。
【００４１】
データ受信部１２１は、サーバ２０から各種データを受信する。データ受信部１２１は、たとえば、データを取得するためのコマンド（以下、データ取得要求という。）をサーバ２０に送信し、サーバ２０からデータ取得要求に応じて送信されるデータを受信するようにしてもよいし、サーバ２０から送信されるデータを受動的に受信するようにしてもよい。データ受信部１２１は、データ取得要求を送信する場合、たとえば、携帯装置１０の起動時に、あるいは所定時間間隔で定期的に、データ取得要求をサーバ２０に送信してデータを受信するようにすることができる。また、たとえば、上記各記憶部に記憶されるデータには最終更新日時を付帯させようにし、データ受信部１２１は、各記憶部に記憶されているデータの最終更新日時のうちの最新の日時を取得して、取得した最新の日時をデータ取得要求に付帯させ、サーバ２０は最新の日時よりも新しいデータのみを応答するようにして、差分のみをサーバ２０との間で同期するようにしてもよい。
【００４２】
データ登録部１２１は、データ受信部１２１が受信したデータを各記憶部に登録する。具体的には、データ登録部１２１は、サーバ２０から受信した顧客情報を顧客情報記憶部１３１に登録し、サーバ２０から受信した商品情報を商品情報記憶部１３２に登録し、サーバ２０から受信した案件情報を案件情報記憶部１３３に登録し、サーバ２０から受信した画面定義情報を画面定義記憶部１３４に登録する。
【００４３】
なお、上述した顧客選択部１１１、案件選択部１１２、申込情報取得部１１３、申込画面生成部１１４、申込項目入力部１１５、自署入力部１１６、申込情報作成部１１７、申込情報送信部１１８、不備情報受信部１１９、不備回答入力部１２０、データ受信部１２１、データ登録部１２２は、携帯装置１０が備えるＣＰＵ１０１が記憶装置１０３に記憶されているプログラムをメモリ１０２に読み出して実行することにより実現される。また、顧客情報記憶部１３１、商品情報記憶部１３２、案件情報記憶部１３３、画面定義記憶部１３４は、携帯装置１０が備えるメモリ１０２および記憶装置１０３が提供する記憶領域の一部として実現される。
【００４４】
＝＝サーバ２０＝＝
図１２は、サーバ２０のソフトウェア構成を示す図である。サーバ２０は、申込処理部２１、不備処理部２２、データ管理部２３および審査結果確認部２４を備える。
【００４５】
＜申込処理部２１＞
申込処理部２１は、保険会社３に対する保険商品の申込に関する処理を行う。申込処理部２１は、携帯装置申込情報送信部２１１、申込情報受信部２１２、承認処理部２１３、帳票作成部２１４、保険会社申込情報送信部２２１、申込情報記憶部２４１、ひな形画像記憶部２４２および帳票定義記憶部２４３を備える。
【００４６】
図１３は、申込情報記憶部２４１が記憶する申込情報の構成例を示す図である。申込情報には、申込を特定するための情報（以下、申込ＩＤという。）に対応付けて、申込を行う顧客１を示す顧客ＩＤ、申し込む保険商品を示す商品ＩＤ、申込を行った日時（本実施形態では申込情報の入力を受け付けた日時、すなわち現在日時とする。）および申込のステータス、ならびに、申込に必要な各入力項目が含まれる。図１３の例では、氏名および署名が入力項目の一例として示されているが、これに限らず、申込情報には各種の入力項目を含めることができる。
【００４７】
携帯装置申込情報送信部２１１は、申込情報を携帯装置１０に送信する。本実施形態では、携帯装置申込情報送信部２１１は、携帯装置１０から申込情報取得要求を受信したことに応じて、付帯されている顧客ＩＤおよび商品ＩＤに対応する申込情報を申込情報記憶部２４１から読み出し、読み出した申込情報を携帯装置１０に応答する。なお、携帯装置申込情報送信部２１１は、申込情報取得要求に付帯されている顧客ＩＤおよび商品ＩＤに対応する申込情報が申込情報記憶部２４１に登録されていない場合には、当該顧客ＩＤおよび商品ＩＤのみを設定した空の申込情報を応答する。
【００４８】
申込情報受信部２１２は、携帯装置１０から送信される申込情報を受信する。申込情報受信部２１２は、受信した申込情報を申込情報記憶部２４１に登録する。
【００４９】
承認処理部２１３は、申込の承認に関する処理を行う。本実施形態では、代理店２において保険商品に対する申込の可否の承認を行い、承認された申込についてのみ保険会社３に実際に申込を行うものとする。なお、承認を行わずに保険の申込を保険会社３に行うようにすることもできる。承認は、公知の手法で行うものとする。たとえば、承認処理部２１３は、承認権限を有するユーザに対して電子メールを送信したり、画面に表示したりして、承認対象となる申込が存在することを報知し、承認するか否かの入力を当該ユーザから受け付けるようにすることができる。承認処理部２１３は、承認された申込情報の顧客ＩＤおよび商品ＩＤに対応する案件情報のステータスを「承認済」と更新し、承認されなかった申込情報の顧客ＩＤおよび商品ＩＤに対応する案件情報のステータスを「非承認」と更新するように、後述の案件情報記憶部２３３を更新する。なお、承認処理部２１３は、「承認済」および「非承認」以外のステータスを設定するようにすることもできる。案件情報記憶部２３３に登録されているデータはデータ管理部２３により携帯装置１０に送信されて、携帯装置１０とサーバ２０との間でデータの同期が行われる。
【００５０】
ひな形画像記憶部２４２は、保険申込に係る帳票のひな形となる画像（すなわち、申込情報の各項目が空欄となっている画像であり、以下、ひな形画像という。）を記憶する。図１４はひな形画像記憶部２４２の構成例を示す図である。同図に示すように、ひな形画像記憶部２４２は、申込対象となる商品を示す商品ＩＤに対応付けて、帳票を示す情報（以下、帳票ＩＤという。）、出力する帳票の名称およびひな形画像を記憶する。なお、ひな形画像記憶部２４２は、帳票の作成を必要とする保険会社３の商品についてのみ、商品ＩＤに対応付けてひな形画像を記憶すればよい。
【００５１】
帳票定義記憶部２４３は、ひな形画像上において申込情報の各項目が描画される位置を定義する情報（以下、帳票定義情報という。）を記憶する。図１５は、帳票定義記憶部２４３に記憶される帳票定義情報の構成例を示す図である。帳票定義情報には、帳票ＩＤと、申込情報の項目を示す項目ＩＤとに対応付けて、当該項目を描画するひな形画像上の領域を示す情報（以下、印字領域情報という。印字領域情報は、たとえばひな形画像上の座標値、幅および高さとすることができる。）が含まれる。
【００５２】
帳票作成部２１４は、申込情報に基づいて保険の申込に係る帳票を作成する。帳票作成部２１４は、帳票定義情報に含まれる印字領域情報に従ってひな形画像に申込情報の各項目を描画することにより帳票を作成する。たとえば、帳票作成部２１４は、申込情報の商品ＩＤに対応するひな形画像および帳票ＩＤをひな形画像記憶部２４２から読み出し、読み出した帳票ＩＤに対応する帳票定義情報を帳票定義記憶部２４３から読み出し、帳票定義情報に含まれる印字領域情報が示すひな形画像上の領域に、項目ＩＤが示す申込情報の項目を描画する。なお、画像への描画処理には一般的な処理を用いるものとして、ここでは詳細についての説明を省略する。また、申込情報の項目が描画された画像は帳票として印刷される。本実施形態において帳票の印刷には、プリンタなどにより紙に印刷することに加えて、ＰＤＦファイルを作成することも含むものとする。印刷された帳票は保険会社３に送付されることになる。本実施形態において帳票の送付には、紙に印刷された帳票を郵送すること、紙に印刷された帳票を宅配便など事業者による配送により送り届けること、ならびに、ＰＤＦファイルとして作成された帳票を、通信路４２を介してＦＴＰなどのファイルの送信プロトコルを用いて、あるいは電子メールに添付させて電子的に送信することを含むものとする。
【００５３】
保険会社申込情報送信部２２１は、申込情報を保険会社装置３０に送信する。保険会社申込情報送信部２２１は、案件情報記憶部２３３に登録されている案件情報のうち、ステータスが「承認済」となっているものに対応する申込情報を保険会社装置３０に送信する。なお、帳票の印刷が必要な場合には、申込情報を送信せずに帳票のみが送付されるようにしてもよい。
【００５４】
＜不備処理部２２＞
不備処理部２２は、不備情報および不備回答に関する処理を行う。不備処理部２２は、不備情報送信部２１５、不備回答受信部２１６、不備情報受信部２２２、不備回答送信部２２３および不備情報記憶部２４４を備える。
【００５５】
不備情報受信部２２２は、保険会社装置３０から送信される不備情報を受信する。後述するように、保険会社３において保険商品に対する申込の審査を行う過程で申込情報に不備が発見された場合に保険会社装置３０から不備情報がサーバ２０に送信される。なお、不備情報として紙の文書が保険会社３から代理店２に送付（郵送または配送など）されてきてもよいし、不備情報として画像ファイルやＰＤＦファイルが送信されてきてもよい。紙の文書が不備情報として送付されてきた場合には、不備情報受信部２２２は、当該紙の文書をスキャンして画像ファイルもしくはＰＤＦファイルを作成し、または紙の文書をスキャンした画像ファイルもしくはＰＤＦファイルの入力を受け付けるようにすればよい。また、不備情報受信部２２２は、画像ファイルやＰＤＦファイルなどのデータを不備情報とする場合には、申込ＩＤの入力を受け付けてもよい。不備情報受信部２２２は、受信した不備情報を不備情報記憶部２４４に登録する。
【００５６】
不備情報記憶部２４４は、不備情報を記憶する。図１６は、不備情報記憶部２４４に記憶される不備情報の構成例を示す図である。不備情報には、不備を特定する情報（以下、不備ＩＤという。）に対応付けて、申込を示す申込ＩＤ、不備の内容を表す不備内容、および不備回答が含まれる。保険会社３から提供される不備情報の不備回答には値は設定されていないものとする。なお、画像ファイルやＰＤＦファイルなどのデータを不備情報とする場合には、不備内容の欄に当該データが格納される。
【００５７】
不備情報送信部２１５は、不備情報を携帯装置１０に送信する。不備情報送信部２１５は、たとえば、不備情報受信部２２２が不備情報を不備情報記憶部２４４に登録したことを契機として不備情報を携帯装置１０に送信することができる。
【００５８】
不備回答受信部２１６は、携帯装置１０から不備回答を受信する。不備回答受信部２１６は、受信した不備回答に付帯されている不備ＩＤに対応する不備情報の不備回答を、受信した不備回答で更新する。
【００５９】
不備回答送信部２２３は、不備回答を保険会社装置３０に送信する。本実施形態では、不備回答送信部２２３は、不備回答受信部２１６が更新した不備情報を保険会社装置３０に送信するものとするが、不備回答のみを送信するようにしてもよい。また、不備回答送信部２２３は、不備回答を印刷して保険会社３に送付するようにしてもよい。この場合、申込情報と同様に、紙に印刷して郵送または配送するようにしてもよいし、ＰＤＦファイルを作成して保険会社装置３０に送信するようにしてもよい。
【００６０】
＜データ管理部２３＞
データ管理部２３は、携帯装置１０とサーバ２０との間でデータの同期を行う。データ管理部２３は、データ登録部２１７、データ送信部２１８、顧客情報記憶部２３１、商品情報記憶部２３２、案件情報記憶部２３３および画面定義記憶部２３４を備える。
【００６１】
顧客情報記憶部２３１、商品情報記憶部２３２、案件情報記憶部２３３および画面定義記憶部２３４は、携帯装置１０が備える顧客情報記憶部１３１（図５）、商品情報記憶部１３２（図６）、案件情報記憶部１３３（図７）および画面定義記憶部１３４（図１０）と同じ構成であるので、ここでは説明を省略する。
【００６２】
データ登録部２１７は、各種のデータの入力を受け付けて登録する。具体的には、顧客情報、商品情報、案件情報および画面定義情報の入力を受け付けて、顧客情報記憶部２３１、商品情報記憶部２３２、案件情報記憶部２３３および画面定義記憶部２３４に登録する。
【００６３】
データ送信部２１８は、データ登録部２１７が登録したデータを携帯装置１０に送信する。データ送信部２１８は、携帯装置１０から送信されるデータ取得要求に応じて、顧客情報、商品情報、案件情報および画面定義情報の少なくともいずれかを、顧客情報記憶部２３１、商品情報記憶部２３２、案件情報記憶部２３３および画面定義記憶部２３４の少なくともいずれかから読み出して応答するようにしてもよいし、データ登録部２１７がデータを登録したことを契機として、登録されたデータを携帯装置１０に送信するようにしてもよい。
【００６４】
＜審査結果確認部２４＞
審査結果確認部２４は、保険商品の申込に対する審査の結果を確認するための処理を行う。審査結果確認部２４は、審査結果表示部２１９および審査結果受信部２２４を備える。審査結果受信部２２４は、保険会社装置３０から送信される審査結果を示す情報（以下、審査結果情報という。）を受信し、審査結果表示部２１９は、審査結果情報を表示する。
【００６５】
なお、上述した携帯装置申込情報送信部２１１、申込情報受信部２１２、承認処理部２１３、帳票作成部２１４、不備情報送信部２１５、不備回答受信部２１６、データ登録部２１７、データ送信部２１８、審査結果表示部２１９、保険会社申込情報送信部２２１、不備情報受信部２２２、不備回答送信部２２３、審査結果受信部２２４は、サーバ２０が備えるＣＰＵ１０１が記憶装置１０３に記憶されているプログラムをメモリ１０２に読み出して実行することにより実現される。また、顧客情報記憶部２３１、商品情報記憶部２３２、案件情報記憶部２３３、画面定義記憶部２３４、申込情報記憶部２４１、ひな形画像記憶部２４２、帳票定義記憶部２４３は、サーバ２０が備えるメモリ１０２および記憶装置１０３が提供する記憶領域の一部として実現される。
【００６６】
＝＝保険会社装置３０＝＝
図１７は、保険会社装置３０のソフトウェア構成を示す図である。保険会社装置３０は、申込情報受信部３１１、不備情報入力部３１２、不備情報送信部３１３、不備回答受信部３１４、審査処理部３１５、審査結果送信部３１６、申込情報記憶部３３１および不備情報記憶部３３２を備える。
【００６７】
申込情報記憶部３３１および不備情報記憶部３３２は、サーバ２０が備える申込情報記憶部２４１および不備情報記憶部２４４と同じ構成であるので、ここでは説明を省略する。
【００６８】
申込情報受信部３１１は、サーバ２０から送信される申込情報を受信する。申込情報受信部３１１は、受信した申込情報を申込情報記憶部３３１に登録する。
【００６９】
不備情報入力部３１２は、不備情報の入力を受け付ける。保険会社３における保険商品への申込の審査の過程で申込情報に不備が発見された場合には、保険会社３のユーザは保険会社装置３０に対して不備情報を入力し、不備情報入力部３１２が当該不備情報を受け付ける。
【００７０】
不備情報送信部３１３は、不備情報入力部３１２が受け付けた不備情報をサーバ２０に送信する。
【００７１】
不備回答受信部３１４は、サーバ２０から送信される不備回答を受信する。本実施形態では、不備回答受信部３１４は、サーバ２０から、不備回答が設定された不備情報を受信する。
【００７２】
審査処理部３１５は、保険商品に対する申込の審査に関する処理を行う。なお、審査処理部３１５は、一般的な保険会社における保険の申込手続に関する処理を行うものとし、ここでは説明を省略する。
【００７３】
審査結果送信部３１６は、審査の結果を示す審査結果情報をサーバ２０に送信する。審査の結果は文字情報であってもよいし、画像などのデータであってもよく、審査の結果が示されるデータであれば任意のデータを設定することができる。
【００７４】
（なお：実現）
なお、上述した申込情報受信部３１１、不備情報入力部３１２、不備情報送信部３１３、不備回答受信部３１４、審査処理部３１５、審査結果送信部３１６は、保険会社装置３０が備えるＣＰＵ１０１が記憶装置１０３に記憶されているプログラムをメモリ１０２に読み出して実行することにより実現される。また、申込情報記憶部３３１および不備情報記憶部３３２は、保険会社装置３０が備えるメモリ１０２および記憶装置１０３が提供する記憶領域の一部として実現される。
【００７５】
＝＝処理＝＝
以下、本実施形態の保険申込システムにおいて実行される処理について説明する。
【００７６】
＜携帯装置１０の処理＞
図１８は、携帯装置１０により実行される処理の流れを示す図である。まず、データ管理部１４はデータ更新処理を行う（Ｓ４０１）。図１９は、データ更新処理としての画面定義情報の更新処理の流れを示す図である。データ受信部１２１は、画面定義記憶部１３４から全体版数を読み出し（Ｓ４２１）、読み出した全体版数を付帯させて、画面定義情報の差分を抽出するように指示するコマンド（以下、差分抽出要求という。）をサーバ２０に送信する（Ｓ４２２）。
【００７７】
サーバ２０のデータ送信部２１８は、受信した差分抽出要求に付帯されていた全体版数よりも大きい全体版数を画面定義記憶部２３４から読み出してＸとし（Ｓ４２３）、読み出した全体版数よりも小さい全体版数の中で最も大きいもの（１つ前の全体版数）を画面定義記憶部２３４から読み出してＹとする（Ｓ４２４）。データ送信部２１８は、画面定義記憶部２３４から、Ｙに対応する項目版数よりもＸに対応する項目版数の方が大きい商品ＩＤを読み出しして変更商品ＩＤとし（Ｓ４２５）、Ｘと変更商品ＩＤとを携帯装置１０に送信する（Ｓ４２６）。なお、変更商品ＩＤは複数あってもよい。また、該当する変更商品ＩＤがない場合には空のリストを送信するものとする。
【００７８】
携帯装置１０のデータ受信部１２１は、受信した変更商品ＩＤのそれぞれについて、変更商品ＩＤを設定したデータ取得要求をサーバ２０に送信する（Ｓ４２７）。
【００７９】
サーバ２０のデータ送信部２１８は、受信したデータ取得要求に設定されている商品ＩＤに対応する画面定義情報を画面定義記憶部２３４から読み出し（Ｓ４２８）、読み出した画面定義情報を携帯装置１０に送信する（Ｓ４２９）。
【００８０】
携帯装置１０のデータ受信部１２１は画面定義情報を受信し、受信した画面定義情報をデータ登録部１２２が画面定義記憶部１３４に登録する（Ｓ４３０）。
【００８１】
以上のようにして、全体版数が変更された場合にはその差分の画面定義情報のみがサーバ２０から携帯装置１０に送信される。
【００８２】
図１８に戻り、顧客選択部１１１は、顧客情報記憶部１３１から顧客情報を読み出して顧客の一覧を表示する（Ｓ４０２）。顧客選択部１１１は、図８に示すような顧客一覧表示画面５１を表示することになる。顧客選択部１１１は、顧客一覧表示画面５１の表示欄５１１でタップされた顧客１を特定し、特定した顧客１が選択されたと判断する（Ｓ４０３）。
【００８３】
案件選択部１１２は、選択された顧客１を示す顧客ＩＤに対応する案件情報を案件情報記憶部１３３から読み出して案件の一覧を表示する（Ｓ４０４）。案件選択部１１２は、図９に示すような案件一覧表示画面５２を表示することになる。案件選択部１１２は、案件一覧表示画面５２の表示欄５２１でタップされた案件を特定し、特定した案件が選択されたと判断する（Ｓ４０５）。
【００８４】
次に図２０に示す申込情報の入力処理が行われる（Ｓ４０６）。
【００８５】
図２０に示すように、入力部１２の申込情報取得部１１３は、上記のようにして選択された案件に対応する案件情報の顧客ＩＤおよび商品ＩＤを設定して、申込情報取得要求をサーバ２０に送信し、サーバ２０から応答される申込情報を受信する（Ｓ４４１）。
【００８６】
申込画面生成部１１４は、申込情報の商品ＩＤに対応する画面定義情報を画面定義記憶部１３４から読み出し（Ｓ４４２）、画面定義情報に従って申込画面５３に入力欄を表示する（Ｓ４４３）。これにより申込画面生成部１１４は、図１１に示すような申込画面５３を表示することになる。
【００８７】
申込項目入力部１１５は、申込画面５３から各項目のデータの入力を受け付け（Ｓ４４４）、画面定義情報の項目オプションに設定されている内容に従ってイベントの処理を行い（Ｓ４４５）、項目オプションに入力チェックの設定がなされている場合には、項目オプションに従って入力チェックを行う（Ｓ４４６）。申込項目入力部１１５は、申込画面５３から受け付けた値を申込情報に設定する（Ｓ４４７）。
【００８８】
申込項目入力部１１５は、入力終了の指示を受け付けるまで（Ｓ４４８：ＮＯ）、ステップＳ４４４からの処理を繰り返す。入力終了の指示がされたら（Ｓ４４８：ＹＥＳ）、申込情報送信部１１８は、申込画面５３から入力された値の設定された申込情報をサーバ２０に送信する（Ｓ４４９）。
【００８９】
以上のようにして、申込画面５３で受け付けた申込情報が携帯装置１０からサーバ２０に送信される。また、先に登録されている申込情報がある場合には、その申込情報が更新される。
【００９０】
＜サーバ２０の処理＞
図２１は、サーバ２０により実行される処理の流れを示す図である。代理店２において承認者により承認がなされると承認処理部２１３により案件情報のステータスが変更される（Ｓ４６１）。変更されたステータスが「変更済」である場合（Ｓ４６２：ＹＥＳ）、案件情報の商品ＩＤが示す保険商品の申込に帳票の印刷が必要なときは（Ｓ４６３：ＹＥＳ）、帳票作成部２１４は、図２２に示す帳票の印刷処理を行う（Ｓ４６４）。なお、帳票の印刷が必要か否かは保険会社ごとまたは保険商品ごとに予め設定されているものとする。
【００９１】
図２２に示すように、帳票作成部２１４は、案件情報の商品ＩＤに対応する申込情報を申込情報記憶部２４１から読み出し（Ｓ４８１）、商品ＩＤに対応するひな形画像情報をひな形画像記憶部２４２から読み出す（Ｓ４８２）。帳票作成部２１４は、ひな形画像情報に基づいてひな形となる帳票画像をメモリ上に描画する（Ｓ４８３）。帳票作成部２１４は、ひな形画像情報の帳票ＩＤに対応する帳票定義情報を読み出し（Ｓ４８４）、読み出した帳票定義情報のそれぞれについて、項目ＩＤが示す申込情報の項目を、印字領域が示す帳票画像上の領域に描画する（Ｓ４８５）。帳票作成部２１４は、帳票定義情報に基づいて申込情報の各項目を描画した帳票画像を印刷する（Ｓ４８６）。なお、帳票画像上に申込情報の各項目（テキストデータや署名の画像データ）を描画する処理や、帳票画像を印刷する処理は一般的な手法を使うものとする。また、上述したように、帳票画像の印刷は、プリンタなどにより紙に印刷することや、帳票画像を表示するためのＰＤＦファイルを作成することを含む。
【００９２】
以上のようにして、申込情報に基づいて帳票が印刷される。図２１に戻り、印刷された帳票は代理店２から保険会社３に送付される（Ｓ４６５）。上述したように、印刷された帳票の送付は、紙に印刷された帳票が郵送もしくは配送され、またはＰＤＦファイルとして作成された帳票が電子的に送信されることが含まれる。
【００９３】
一方、案件情報の商品ＩＤが示す保険商品の申込に帳票の印刷が必要でない場合（Ｓ４６３：ＮＯ）、保険会社申込情報送信部２２１は、案件情報の商品ＩＤに対応する申込情報を申込情報記憶部２４１から読み出して保険会社装置３０に送信する（Ｓ４６６）。
【００９４】
審査結果受信部２２４が保険会社装置３０から審査結果を受信した場合には（Ｓ４６７：ＹＥＳ）、審査結果表示部２１９が受信した審査結果を表示する（Ｓ４６８）。不備情報受信部２２２が保険会社装置３０から不備情報を受信した場合には（Ｓ４６９：ＹＥＳ）、図２３に示す不備訂正処理が行われる。
【００９５】
図２３に示すように、不備情報受信部２２２は、不備情報に含まれる申込ＩＤに対応する顧客ＩＤおよび商品ＩＤを申込情報記憶部２４１から読み出し、読み出した顧客ＩＤおよび商品ＩＤに対応する案件情報のステータスを「不備」とするように案件情報記憶部２３３を更新する（Ｓ５０１）。不備情報送信部２１５は不備情報を携帯装置１０に送信する（Ｓ５０２）。
【００９６】
携帯装置１０の不備情報受信部１１９は、サーバ２０から送信される不備情報を受信すると、不備情報に含まれる不備内容を表示する（Ｓ５０３）。不備回答入力部１２０は、不備回答の入力を受け付け（Ｓ５０４）、受け付けた不備回答をサーバ２０に送信する（Ｓ５０５）。
【００９７】
サーバ２０の不備回答受信部２１６は、不備回答を受信すると対応する不備情報を更新し（Ｓ５０６）、対応する案件情報のステータスを「不備回答」に更新する（Ｓ５０７）。承認処理部２１３は、承認者から承認を受けるようにし（Ｓ５０８）、案件情報のステータスが「承認済」になったら（Ｓ５０９：ＹＥＳ）、不備回答送信部２２３は不備情報を保険会社装置３０に送信する（Ｓ５１０）。保険会社装置３０では、不備回答受信部３１４が不備情報を受信して不備情報記憶部３３２に登録する。
【００９８】
＜保険会社装置３０の処理＞
図２４は、保険会社３において行われる業務の流れを示す図である。保険会社装置３０の審査処理部３１５は、審査対象となっている申込に対応する、不備回答が設定された不備情報が不備情報記憶部３３２に登録されている場合には（Ｓ５２１：ＹＥＳ）、当該不備情報の不備回答を表示する（Ｓ５２２）。審査対象となる申込に係る保険商品に帳票が必要な場合（Ｓ５２３：ＹＥＳ）、帳票に基づいて審査が行われ（Ｓ５２４）、そうでなければ（Ｓ５２３：ＮＯ）、申込情報に基づいて審査が行われる（Ｓ５２５）。
【００９９】
帳票または申込情報に不備があった場合（Ｓ５２６：ＹＥＳ）、保険会社３の担当者は当該不備を保険会社装置３０に入力し、不備情報入力部３１２がこれを受け付け（Ｓ５２７）、不備情報送信部３１３は不備情報をサーバ２０に送信する（Ｓ５２８）。
【０１００】
＝＝効果＝＝
以上説明したように、本実施形態の保険申込システムによれば、複数の保険会社３から提供される保険商品を１つのシステムで販売することができる。すなわち、金融商品の中でもとりわけ申込手続きが煩雑であり、必要書類も多岐に渡る保険販売において、複数の保険会社３の複数の保険商品でそれぞれに異なる保険申込書類を意識することなく、タブレットコンピュータなどの携帯装置１０による統一された画面インタフェースを用いて顧客１は保険申込手続を行うことができる。したがって、顧客１にとっては保険の選択肢が増えるとともに、代理店２にとっては商材が増えることになる。したがって、効率的かつ効果的な保険申込を行うことができる。
【０１０１】
また、本実施形態の保険申込システムによれば、自署も携帯装置１０を用いて画像として入力することができる。また、本実施形態の保険申込システムによれば、申込書への印鑑押印が不要となるため、手続きが簡素化され利便性が向上する。
【０１０２】
また、本実施形態の保険申込システムによれば、申込画面においてどのような入力欄を表示するべきかをサーバ２０の画面定義記憶部２３４に登録することで、携帯装置１０の画面定義記憶部１３４に自動的に同期されるようにして、携帯装置１０で適切な入力項目を申込画面に表示させることができる。したがって、新たな保険商品についての画面定義情報を登録する際には、サーバ２０は、全ての保険商品（または多くの保険商品）に共通して入力すべき項目についての画面定義情報をデフォルト情報として画面定義記憶部２３４に自動的に登録するようにし、新たに登録する保険商品に特有の入力項目についての画面定義情報のみの入力を受け付けるようにすることができる。これにより、画面定義情報の登録を効率的に行うことが可能となり、本保険申込システムで新たな保険商品の取扱いを容易かつ迅速に開始することができる。
【０１０３】
また、本実施形態の保険申込システムによれば、各保険会社３には、携帯装置１０で入力した申込情報をもとに、各保険商品専用の申込書類一式をＰＤＦ帳票やデータの形式で提供することができる。したがって、営業担当２１は紙を持ち歩く必要がなくなり便利であり、環境にも有益である。また、申込情報がデータ化されることにより紙の書類が削減されるため、代理店２における書類点検や仕分けなどの事務処理時間を短縮することができる。さらに、代理店２の本支店間における物流コストを削減することも可能となり、代理店２と保険会社３との間での物流コストを削減することもできる。加えて、代理店２にとっては、書類の紛失、盗難などによる情報漏えいリスクが軽減される。保険会社３にとっても、申込書類をデータの形式で受信した場合には、コンピュータで処理可能な申込情報を用いて審査を行うことができるので、審査業務を効率化することが可能となり、ＰＤＦの形式で受信した場合であっても、大量の書類を１台のコンピュータ上で容易に閲覧することができるので、やはり審査業務を効率化することができる。
【０１０４】
また、保険会社３で印字された帳票が必要であったとしても、代理店２において申込情報に基づいて帳票を印刷し、紙の帳票書類を送付することも、帳票画像を表示するためのＰＤＦファイルを送信することもできる。
【０１０５】
また、本実施形態の保険申込システムによれば、申込情報のうち予め判明している項目は営業担当２１が事前入力しておき、必要な項目のみを顧客１が携帯装置１０を用いて入力すればよい。したがって、効率的に申込を行うことができる。
【０１０６】
また、本実施形態の保険申込システムによれば、申込情報をシステムに入力することで、入力内容を自動的にチェックすることができる。これにより申込情報の不備を自動的に発見することが可能となり、不備件数を低減することができる。したがって、申込手続にかかる期間を短縮することができる。
【０１０７】
また、本実施形態の保険申込システムでは、申込情報に不備があった場合でも、その不備の内容を保険会社３から代理店２にデータ連動で通知され、代理店２内でオンライン参照できるので、顧客１は携帯装置１０を用いて不備の訂正を効率的に行うことができる。
【０１０８】
また、本実施形態の保険申込システムによれば、各種の保険商品の申込手続を標準化することができる。したがって、代理店２にとっては、保険募集におけるコンプライアンス遵守を確実にすることが可能となり、さらには営業担当者２１の個人スキルや個人ノウハウに依存しない保険募集業務の実現が可能となる。
【０１０９】
＝＝変形例＝＝
なお、本実施形態では、サーバ２０および保険会社装置３０は１台のコンピュータであるものとしたが、複数台のコンピュータで実現するようにしてもよい。
【０１１０】
また、本実施形態では、サーバ２０と保険会社装置３０とが通信路４２を介して直接申込情報や不備情報に係る通信を行うものとしたが、これに限らず、例えば保険会社３内に保険会社装置３０と通信可能な端末（保険会社端末）を設置し、この保険会社端末とサーバ２０とが通信を行うようにし、申込情報は、サーバ２０から保険会社端末に送信されて保険会社端末から保険会社装置３０に送信されるようにし、不備情報は、保険会社端末からサーバ２０（および保険会社装置３０）に送信されるようにしてもよい。また、代理店２内にサーバ２０と通信可能な端末（代理店端末）を設置し、この代理店端末と保険会社装置３０とが通信を行うようにして、申込情報は、サーバ２０から代理店端末に送信されて代理店端末から保険会社装置３０に送信されるようにし、不備情報は、保険会社装置３０から代理店端末に送信されて代理店端末からサーバ２０に送信されるようにしてもよい。また、保険会社端末と代理店端末との両方を設け、申込情報は、サーバ２０から代理店端末に送信され、代理店端末から保険会社端末に送信され、保険会社端末から保険会社装置３０に送信されるようにし、不備情報は、保険会社端末から代理店端末（および保険会社装置３０）に送信され、代理店端末からサーバ２０に送信されるようにしてもよい。
【０１１１】
また、本実施形態では代理店２で管理している全ての顧客１について顧客情報記憶部１３１および顧客情報記憶部２３１で管理するものとしたが、営業担当者２１ごとに顧客１を管理するようにしてもよい。この場合、たとえば営業担当者２１ごとに顧客情報を記憶しておき、ログインした営業担当者２１に対応する顧客情報の一覧を表示するようにすればよい。
【０１１２】
また、本実施形態では、代理店２において申込の承認を受けてから申込が行われるものとしたが、顧客１からの申込を受けるとすぐに保険会社３に申込が行われるようにしてもよい。また、本実施形態では、申込情報がサーバ２０から保険会社装置３０に送信されるものとしたが、携帯装置１０から保険会社装置３０に送信するようにしてもよい。
【０１１３】
また、本実施形態では、図１８のデータ更新処理（ステップＳ４０１）として、図１９に示す処理で画面定義情報の更新のみを行うものとしたが、その他の顧客情報、商品情報、案件情報などの更新を行うようにしてもよい。また、その際に、顧客情報、商品情報および案件情報についても版管理を行うようにしてもよい。たとえば、顧客情報、商品情報および案件情報に版数を含めるようにし、顧客情報記憶部１３１、商品情報記憶部１３２および案件情報記憶部１３３に記憶されている版数をサーバ２０に送信し、サーバ２０において受信した版数よりも大きい版数の顧客情報、商品情報および案件情報を読み出して応答するようにすることができる。
【０１１４】
また、本実施形態では、不備情報は携帯装置１０に送信し、携帯装置１０を用いて不備回答の入力をするものとしたが、サーバ２０において不備回答の入力を行うようにしてもよい。
【０１１５】
また、本実施形態では、顧客情報、商品情報、案件情報および画面定義情報はサーバ２０において入力するものとしたが、携帯装置１０において入力するようにしてもよい。この場合、たとえば、携帯装置１０の備えるデータ登録部１２２が顧客情報、商品情報、案件情報および画面定義情報の少なくともいずれかの入力を受け付け、受け付けた情報を顧客情報記憶部１３１、商品情報記憶部１３２、案件情報記憶部１３３および画面定義記憶部１３４の少なくともいずれかに登録するとともに、サーバ２０に送信し、サーバ２０の備えるデータ登録部２１７が受信した情報を顧客情報記憶部２３１、商品情報記憶部２３２、案件情報記憶部２３３および画面定義記憶部２３４の少なくともいずれかに登録するようにすればよい。
【０１１６】
また、本実施形態では、帳票定義情報には申込情報の各項目が描画される位置が定義されるものとしたが、これに加えて、バーコードなどの一次元コードおよびＱＲコード（登録商標）などの二次元コードを含む情報の符号化される画像（以下、符号化画像という。）に関する情報を含むようにしてもよい。この場合、符号化画像として符号化する申込情報の項目またはその他の情報、および当該符号化画像を印刷する位置を特定する情報を含めるようにする。そして、帳票作成部２１４は、帳票定義情報に符号化画像に関する情報が含まれている場合には、当該情報が示す項目またはその他の情報を符号化した符号化画像を作成し、帳票定義情報に定義される位置に当該符号化画像を描画するようにする。これにより、保険会社３では、帳票に印刷されたたとえばバーコードなどの符号化画像をスキャンして復号し、復号した情報を用いて保険商品の申込処理を効率化することができる。
【０１１７】
以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。
【符号の説明】
【０１１８】
１      顧客
２      代理店
３      保険会社
１０    携帯装置
２０    サーバ
３０    保険会社装置
４１    通信路
４２    通信路
１１    選択部
１２    入力部
１３    帳票部
１４    申込部
１５    不備解決部
１６    データ登録部
２１    担当者
５１    顧客一覧表示画面
５２    案件一覧表示画面
１１１  顧客選択部
１１２  案件選択部
１１３  申込情報取得部
１１４  申込画面生成部
１１５  申込項目入力部
１１６  自署入力部
１１７  申込情報作成部
１１８  申込情報送信部
１１９  不備情報受信部
１２０  不備回答入力部
１３１  顧客情報記憶部
１３２  商品情報記憶部
１３３  案件情報記憶部
１３４  画面定義記憶部
１３５  不備情報記憶部
【図１】
2016170469.tif 000003
【図２】
2016170469.tif 000004
【図３】
2016170469.tif 000005
【図４】
2016170469.tif 000006
【図５】
2016170469.tif 000007
【図６】
2016170469.tif 000008
【図７】
2016170469.tif 000009
【図８】
2016170469.tif 000010
【図９】
2016170469.tif 000011
【図１０】
2016170469.tif 000012
【図１１】
2016170469.tif 000013
【図１２】
2016170469.tif 000014
【図１３】
2016170469.tif 000015
【図１４】
2016170469.tif 000016
【図１５】
2016170469.tif 000017
【図１６】
2016170469.tif 000018
【図１７】
2016170469.tif 000019
【図１８】
2016170469.tif 000020
【図１９】
2016170469.tif 000021
【図２０】
2016170469.tif 000022
【図２１】
2016170469.tif 000023
【図２２】
2016170469.tif 000024
【図２３】
2016170469.tif 000025
【図２４】
2016170469.tif 000026