特許 6788911 保険管理サーバ，サービス提供システム，及びサービス提供方法

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

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

(11)【特許番号】6788911

(24)【登録日】2020年11月5日

(45)【発行日】2020年11月25日

(54)【発明の名称】保険管理サーバ，サービス提供システム，及びサービス提供方法

(51)【国際特許分類】

   G06Q 40/08 20120101AFI20201116BHJP

【ＦＩ】

   G06Q40/08

【請求項の数】5

【全頁数】16

(21)【出願番号】特願2019-53356(P2019-53356)

(22)【出願日】2019年3月20日

(65)【公開番号】特開2020-154807(P2020-154807A)

(43)【公開日】2020年9月24日

【審査請求日】2019年4月1日

【審判番号】不服2020-7836(P2020-7836/J1)

【審判請求日】2020年6月8日

【早期審理対象出願】

(73)【特許権者】

【識別番号】516134567

【氏名又は名称】株式会社Ｗａｒｒａｎｔｅｅ

(74)【代理人】

【識別番号】100116850

【弁理士】

【氏名又は名称】廣瀬 隆行

(74)【代理人】

【識別番号】100165847

【弁理士】

【氏名又は名称】関 大祐

(72)【発明者】

【氏名】庄野 裕介

【合議体】

【審判長】 佐藤 聡史

【審判官】 岡 裕之

【審判官】 松田 直也

(56)【参考文献】

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

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

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

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

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

G06Q10/00-99/00

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

【請求項1】

ユーザが利用するユーザ端末，保険者が利用する保険者端末，及びスポンサーが利用するスポンサー端末に通信網を介して接続された，サービス提供者が利用する管理サーバであって，
前記管理サーバは，
前記保険者端末から保険商品に関する情報を受信し，
前記スポンサー端末から前記保険商品の加入条件に関する情報を受信し，
前記保険者端末から受信した前記保険商品に関する情報及び前記スポンサー端末から受信した前記加入条件をそれぞれ少なくとも部分的に参照してサービスの加入条件を策定し，
前記ユーザ端末から前記サービスの加入の申込みを受信した場合に，前記サービスの加入条件に基づいて前記ユーザの前記サービスの加入の可否を判断する
管理サーバ。

【請求項2】

前記ユーザ端末からサービスの加入の申込みとともに前記ユーザに関する情報を受信し，
前記ユーザに関する情報を前記スポンサー端末に送信する
請求項１に記載の管理サーバ。

【請求項3】

前記保険商品の保険料の一部又は全部を賄うための費用の請求情報を前記スポンサー端末に送信する
請求項１又は請求項２に記載の管理サーバ。

【請求項4】

ユーザが利用するユーザ端末，保険者が利用する保険者端末，スポンサーが利用するスポンサー端末，及びこれらの端末と通信網を介して接続された，サービス提供者が利用する管理サーバを含むサービス提供システムであって，
前記保険者端末は，保険商品に関する情報を前記管理サーバに送信し，
前記スポンサー端末は，前記保険商品への加入条件に関する情報を前記管理サーバに送信し，
前記管理サーバは，前記保険者端末から受信した前記保険商品に関する情報及び前記スポンサー端末から受信した前記加入条件をそれぞれ少なくとも部分的に参照してサービスの加入条件を策定し，前記ユーザ端末から前記サービスの加入の申込みを受信した場合に，前記サービスの加入条件に基づいて前記ユーザの前記サービスの加入の可否を判断する
システム。

【請求項5】

ユーザが利用するユーザ端末，保険者が利用する保険者端末，スポンサーが利用するスポンサー端末，及びこれらの端末と通信網を介して接続された，サービス提供者が利用する管理サーバによって行われるサービス提供方法であって，
前記保険者端末が，保険商品に関する情報を前記管理サーバに送信する工程と，
前記スポンサー端末が，前記保険商品への加入条件に関する情報を前記管理サーバに送信する工程と，
前記管理サーバが，前記保険者端末から受信した前記保険商品に関する情報及び前記スポンサー端末から受信した前記加入条件をそれぞれ少なくとも部分的に参照してサービスの加入条件を策定する工程と，
前記管理サーバが，前記ユーザ端末から前記サービスの加入の申込みを受信した場合に，前記サービスの加入条件に基づいて前記ユーザの前記サービスの加入の可否を判断する工程を含む
方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は，ユーザに対して保険や製品修理などの特定のサービスを提供するためのシステムなどに関する。具体的に説明すると，本発明は，ユーザに提供される保険等のサービスに関わるコストの一部又は全部をスポンサーが負担することで，ユーザの当該サービスへの加入を促進するためのシステムなどに関するものである。

【背景技術】

【0002】

従来から，ユーザが利用する被保険者端末と，保険者が利用する保険者端末と，これの装置にンターネットを介して接続された保険管理装置とから構成される保険管理システムが知られている（特許文献１）。この保健管理システムでは，保険者が提供する保険商品の情報を保険管理装置に集約しておき，ユーザから保険加入の申込みがあったときに，この保険管理装置においてユーザが保険加入の条件を満たしているかどうかの審査を行ったり，あるいはユーザが保険金給付の条件を満たしているかどうかの審査を行うこととしている。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

ところで，従来の保険やそれに準ずるサービスは，潜在的に抱えているリスクが顕在化したときに備えて，被保険者全員でそのリスクを平準化させるためのものであり，そのためのコストは受益者負担が基本となっている。つまり，被保険者は，保険者に保険料を支払うことで保険という便益を享受することができるというのが一般的であった。このため，これまでの保険管理システムは，このような収益構造を前提として構築されたものであり，上記特許文献１のように，被保険者端末，保険者端末，及び保険管理装置が備わっていれば十分であった。

【0005】

しかしながら，被保険者は，例えば事故や病気などのリスクが顕在化した場合に保険金等の補償を受け取ることができるが，それまでの間は，被保険者にとって保険料に見合うメリットを認識しにくいという問題があり，このことが保険加入の妨げの一因となっている。また，事故発生時の補償を充実させると，それに比例して自ずと保険料が高額とものとなる。これらの問題は保険の性質上仕方ないことではあるが，事故等が発生したときに被保険者が受け取ることのできる補償を維持しつつ，少しでも被保険者の支払う保険料を下げることができれば，保険加入件数の増加につながるといえる。

【0006】

そこで，本発明は，ユーザ（被保険者）の負担を軽減して，ユーザが保険あるいはそれに準ずるサービスに加入しやすくすることを目的とする。

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

【0007】

本発明の発明者は，上記の従来技術の問題を解決する手段について鋭意検討した結果，保険等のサービスに加入するにあたりユーザが本来支払うべきコストの一部又は全部を，保険者以外のスポンサーに負担させることにより，ユーザが当該サービスに加入しやすくなるという知見を得た。そして，本発明者は，上記知見に基づけば従来技術の課題を解決できることに想到し，本発明を完成させた。具体的に説明すると，本発明は以下の構成を有する。

【0008】

本発明の第１の側面は，管理サーバに関する。本発明の管理サーバは，ユーザが利用するユーザ端末，保険者が利用する保険者端末，及びスポンサーが利用するスポンサー端末に通信網を介して接続されたサーバ装置である。管理サーバは，まず，保険者端末から保険商品に関する情報を受信する。この保険商品に関する情報には，保険内容（補償内容等）やその保険商品への加入条件などが含まれる。また，管理サーバは，スポンサー端末から保険商品の加入条件に関する情報を受信する。すなわち，本発明のシステムにより運用されるビジネスモデルでは，スポンサーが保険料を負担することになるが，その代わりとして，スポンサーが保険加入への条件を指定することを可能にしている。次に，管理サーバは，ユーザ端末からサービスの加入の申込みを受信した場合に，スポンサー端末から受信した加入条件を少なくとも部分的に参照して，ユーザのサービスの加入の可否を判断する。ここにいう「サービス」とは，上記保険商品と同内容のサービスであってもよいし，異なる内容のサービスであってもよい。例えば，ユーザの所有製品に破損が生じたときに，管理サーバの運用するサービス提供者が保険者から保険金を受け取り，そのサービス提供者が，保険金の一部又は全部をユーザに提供してもよいし，その保険金を利用してユーザに製品の交換又は修理に係るサービスを提供してもよい。サービス加入の条件は，管理サーバが，保険者端末から受信した保険商品に関する情報や，スポンサー端末から受信した保険商品の加入条件を参照して策定すればよい。

【0009】

上記構成によれば，保険等のサービスに加入するためのコストをスポンサーに負担させることでユーザの負担を軽減するというビジネスモデルを効率的に運用することができる。すなわち，ユーザのサービス加入の条件には少なくとも部分的にスポンサーの意向が反映されることなる。例えば，スポンサーは，コストを負担する代わりに，ユーザの個人情報を入手することが可能になる。商品のマーケティングのために，同種の商品を購入して使用しているユーザの個人情報は有用である。例えば，スポンサー企業は，ユーザの個人情報を製品開発に利用することができる。また，スポンサー企業は，製品の買い替え時期が到来したユーザに対して，自社製品を買い替え候補として提示することで，効果の高い宣伝をユーザに対して直接行うことができる。他方で，ユーザは自身の個人情報を提供することで，保険又はそれに準ずるサービスに無料又は低下価格で加入することが可能になる。これにより，これらのサービスの加入件数の増加が見込める。

【0010】

本発明に係る管理サーバは，ユーザ端末からサービスの加入の申込みとともにユーザに関する情報を受信し，このユーザに関する情報をスポンサー端末に送信することが好ましい。これにより，ユーザの個人情報等をスポンサー端末に対して効率的に提供することができる。

【0011】

本発明に係る管理サーバは，保険商品の保険料の一部又は全部を賄うための費用の請求情報をスポンサー端末に送信することが好ましい。このように，保険商品の保険料をユーザに負担させるのではなく，少なくとも一部をスポンサーに負担させることにより，ユーザのサービスへの加入を促進することができる。

【0012】

本発明の第２の側面は，サービス提供システムに関する。サービス提供システムは，ユーザが利用するユーザ端末，保険社が利用する保険者端末，スポンサーが利用するスポンサー端末，及びこれらの端末と通信網を介して接続された管理サーバを含む。本発明に係るサービス提供システムにおいて，保険者端末は，保険商品に関する情報を管理サーバに送信する。スポンサー端末は，保険商品への加入条件に関する情報を管理サーバに送信する。管理サーバは，ユーザ端末からサービスの加入の申込みを受信した場合に，スポンサー端末から受信した加入条件を少なくとも部分的に参照して，ユーザのサービスの加入の可否を判断する。

【0013】

本発明の第３の側面は，サービス提供方法に関する。サービス提供方法は，ユーザが利用するユーザ端末，保険社が利用する保険者端末，スポンサーが利用するスポンサー端末，及びこれらの端末と通信網を介して接続された管理サーバによって実行される。本発明に係るサービス提供方法おいて，保険者端末は，保険商品に関する情報を管理サーバに送信する。スポンサー端末は，保険商品への加入条件に関する情報を管理サーバに送信する。管理サーバは，ユーザ端末からサービスの加入の申込みを受信した場合に，スポンサー端末から受信した加入条件を少なくとも部分的に参照して，ユーザのサービスの加入の可否を判断する。

【0014】

次に，管理サーバの別の側面について説明する。すなわち，管理サーバは，保険者端末から保険商品に関する情報を受信する。また，管理サーバは，ユーザ端末からサービスの加入の申込みを受信した場合に，保険商品の加入条件を少なくとも部分的に参照して，ユーザの前記サービスの加入の可否を判断する。そして，管理サーバは，ユーザがサービスに加入可能であると判断した場合に，ユーザに関する情報をスポンサー端末に送信することとしてもよい。このように，ユーザの個人情報等をスポンサー端末に送信することで，スポンサー企業から保険商品の保険料の一部又は全部を徴収することとしてもよい。

【0015】

次に，サービス提供システムの別の側面について説明する。すなわち，サービス提供システムにおいて，保険者端末は，保険商品に関する情報を管理サーバに送信する。管理サーバは，ユーザ端末からサービスの加入の申込みを受信した場合に，保険商品の加入条件を少なくとも部分的に参照して，ユーザのサービスの加入の可否を判断し，ユーザがサービスに加入可能であると判断した場合に，ユーザに関する情報を前記スポンサー端末に送信する。

【0016】

次に，サービス提供方法の別の側面について説明する。すなわち，サービス提供方法において，保険者端末は，保険商品に関する情報を管理サーバに送信する。管理サーバは，ユーザ端末からサービスの加入の申込みを受信した場合に，保険商品の加入条件を少なくとも部分的に参照して，ユーザのサービスの加入の可否を判断し，ユーザがサービスに加入可能であると判断した場合に，ユーザに関する情報を前記スポンサー端末に送信する。

【発明の効果】

【0017】

本発明によれば，ユーザの負担を軽減して保険等のサービスへ加入を促進することができる。

【図面の簡単な説明】

【0018】

【図1】図１は，サービス提供システムの全体構成を模式的に示している。

【図2】図２は，サービス提供システムを構成する端末装置及びサーバ装置の機能ブロックの例を示している。

【図3】図３は，管理データベースに設けられた各テーブルのテータ構造例を示している。

【図4】図４は，保険者データベースに設けられた各テーブルのデータ構造例を示している。

【図5】図５は，サービス加入条件の設計フローの一例を示している。

【図6】図６は，サービスへの加入審査フローの一例を示している。

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

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

他方で，ステップＳ１7における審査の結果，エンドユーザを被保険者とした保険契約が契約条件に適合していると判断した場合，保険者端末３０は，必要情報を保険者ＤＢ３６に登録する（ステップＳ２１）。例えば，保険者端末３０は，管理サーバ１０からの共有された情報に基づいてユーザテーブルの個人情報のフィールドを登録したり，加入保険テーブルの各フィールドに情報を登録する。

【0054】

次に，保険者端末３０は，管理サーバ１０に対して，契約を締結した保険商品の保険料の請求を通知する（ステップＳ２２）。保険商品の保険料は，保険会社によって予め定められた額であってもよいし，スポンサー企業の要望に応じて調整された額であってもよい。管理サーバ１０が保険料の請求通知を受け取ると，サービス提供者は保険会社に対してその保険料を支払う手続きを行う。また，支払手続き完了後，管理サーバ１０は，保険者端末３０に対して支払い完了通知を送信する（ステップＳ２３）。その後，保険者端末３０は，保険料の受領を確認した後（ステップＳ２４），管理サーバ１０に対して保険契約の成立通知を送信する（ステップＳ２５）。この通知をもって，サービス提供者と保険会社との間で正式に保険契約が締結される。また，前述の通り，一定期間を過ぎても契約不成立通知がユーザ端末２０に送信されない場合，ユーザ端末２０の表示部２５には，正式に契約が成立した旨を表す画面が表示される（ステップＳ２６）。この段階で，サービス提供者とエンドユーザとの間で正式にサービス契約が締結されることとなる。本発明のシステムでは，サービス提供者から保険会社への保険料の支払いや保険会社での保険料の受領確認に関わらず，エンドユーザとサービス提供者との間で，サービス契約が独立して成立することが特徴の一つである。これにより，エンドユーザに対して迅速にサービスの提供を開始することができる。

【0055】

また，保険契約締結後，管理サーバ１０は，スポンサー端末３０に対して，キャンペーン料の請求を通知するとともに，スポンサー企業が入手することを予め希望していたエンドユーザの個人情報や，その所有製品に関する情報を送信する（ステップＳ２７）。例えば，管理サーバ１０は，管理ＤＢ１４のユーザテーブルや所有製品テーブルに登録されている情報の中からスポンサー企業が求める情報を抽出して，スポンサー端末３０に送信すればよい。また，スポンサー端末３０がキャンペーン料の請求通知を受け取ると，スポンサー企業はサービス提供者に対してそのキャンペーン料を支払う手続きを行う。また，支払手続き完了後，スポンサー端末３０は，管理サーバ１０に対して支払い完了通知を送信する（ステップＳ２８）。ここまでの処理で，サービス加入の審査フローが終了する。

【0056】

以上，本願明細書では，本発明の内容を表現するために，図面を参照しながら本発明の実施形態の説明を行った。ただし，本発明は，上記実施形態に限定されるものではなく，本願明細書に記載された事項に基づいて当業者が自明な変更形態や改良形態を包含するものである。

【符号の説明】

【0057】

１０…管理サーバ ２０…ユーザ端末
３０…保険者端末 ４０…スポンサー端末
１００…サービス提供システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】