JPWO2014181530A1 - サービス提供方法 - Google Patents

Abstract

保険料更新システムは、所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者によってネットワークを介して記事を送信する記事送信部（６０７）と、記事送信部（６０７）によって送信された記事を契約者以外の閲覧者に対して表示する記事表示部（６０９）と、契約者と閲覧者とがどの程度の交流関係であるかを示す交流度を決定する交流度決定部（９０１）と、交流度決定部（９０１）によって決定された交流度に応じて契約の内容（保険料）を決定する保険料更新部（６０４）とを備える。

Description

本発明は、所定のサービスを提供するサービス提供者と結ぶ契約の内容を決定するサービス提供方法に関する。

従来の医療保険又は生命保険は、加入時に保険料を決定し、その保険料は、満期になるまで固定的であった。すなわち、被保険者が、契約中に体調を崩したとしても、保険料は変化しない。このことは、保険会社のリスクが高まる可能性があることを意味する。

保険会社は、前記したリスクを、保険料に転嫁するので、健康な人でも、割高な保険料を支払わなければならなくなる。あるいは、保険会社は、契約後のリスクを最小限にするために、少しでも健康に不安がある人物との契約を拒否する可能性もある。また、健康面の問題を明確にするために、契約前の健康診断の項目が増大する可能性もある。このことは、保険加入希望者にとっては気軽に保険に加入できないという問題となり、保険会社にとっては契約数が少なくなるという問題となる。

このような背景から、被保険者の健康状態に応じて、保険料を動的に変更する保険契約更改システムが提案されている（例えば、特許文献１参照）。特許文献１では、携帯電話端末に搭載された歩数計で毎日の被保険者の歩数を計測し、計測した歩数を保険会社のサーバに送信し、受信した歩数から１日当たりの平均歩数を算出し、算出した１日当たりの平均歩数に対応する保険契約レベルを用いた保険契約者の契約更改を行うシステムが提案されている。

しかしながら、特許文献１のシステムは、更なる改善が必要であった。

特許第４４３２２４２号明細書

本発明の一態様に係るサービス提供方法は、所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者によってネットワークを介して記事を送信する送信ステップと、前記送信ステップにおいて送信された前記記事を前記契約者以外の閲覧者に対して表示する表示ステップと、前記契約者と前記閲覧者とがどの程度の交流関係であるかを示す交流度を決定する交流度決定ステップと、前記交流度決定ステップにおいて決定された前記交流度に応じて前記契約の内容を決定する契約決定ステップとを含む。

（Ａ）は、本実施の形態における制御システムが提供するサービスの全体像を示す図であり、（Ｂ）は、機器メーカがデータセンタ運営会社に該当する例を示す図であり、（Ｃ）は、機器メーカ及び管理会社の両者又はいずれか一方がデータセンタ運営会社に該当する例を示す図である。 本発明の実施の形態１における保険料更新システムの構成を示す図である。 本発明の実施の形態１における保険料更新システムの動作を説明するためのフローチャートである。 実施の形態１において、記事表示部によって表示される表示画面の一例を示す図である。 実施の形態１において、更新された保険料をユーザに通知する表示画面の一例を示す図である。 本発明の実施の形態２における保険料更新システムの構成を示す図である。 本発明の実施の形態２における保険料更新システムの動作を説明するためのフローチャートである。 実施の形態２において、ＳＮＳリアル交流度を用い更新された保険料をユーザに通知する表示画面の一例を示す図である。 本発明の実施の形態３におけるサービス提供システムの構成を示す図である。 サービスの提供が開始される際のユーザとサービス提供者との関係を説明するための模式図である。 返却期限が経過する前に、ユーザが物品を返却した場合のユーザとサービス提供者との関係を説明するための模式図である。 返却期限が経過しても、ユーザが物品を返却していない場合のユーザとサービス提供者との関係を説明するための模式図である。 実施の形態４において、記事表示部によって表示される表示画面の一例を示す図である。 実施の形態４において、記事表示部によって表示される表示画面内のアイコンの他の例を示す図である。 実施の形態４において、記事表示部によって表示される表示画面内のアイコンの他の例を示す図である。 サービスの類型１（自社データセンタ型クラウドサービス）における情報提供システムが提供するサービスの全体像を示す図である。 サービスの類型２（ＩａａＳ利用型クラウドサービス）における情報提供システムが提供するサービスの全体像を示す図である。 サービスの類型３（ＰａａＳ利用型クラウドサービス）における情報提供システムが提供するサービスの全体像を示す図である。 サービスの類型４（ＳａａＳ利用型クラウドサービス）における情報提供システムが提供するサービスの全体像を示す図である。

（本発明の基礎となった知見）
特許文献１のシステムによれば、被保険者の健康状態に応じて、保険料を動的に変更することができる。したがって、従来の医療保険及び生命保険が抱えていた、固定的な保険料によって発生する、保険加入者と保険会社との双方の問題が解消される。

しかし、従来のシステムは、新たな課題が生じる可能性がある。契約者は、保険会社へ報告する歩数が増えることによって、保険料が安くなることを知っている。そのため、保険料を安くしたい契約者は、保険会社へ虚偽の歩数を報告するおそれがある。例えば、契約者本人が歩数計を保持するのではなく、契約者の子供が歩数計を保持して活動することにより、契約者本人が健康のために活動しなくても、保険料を安くすることができる。

保険会社としては、このような詐欺行為を絶対に阻止しなければならないが、歩数計のデータが間違いなく被保険者のものであることを確認するのは困難である。そのため、保険会社は、被保険者の良心を信じるしかなく、保険料更新の要点となる活動量が、本当に被保険者のものであることを確認する方法については、検討されていない。

このような課題を解決するために、本発明者らは、以下の態様に係る発明を想到するに至った。

本発明の一態様に係るサービス提供方法は、所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者によってネットワークを介して記事を送信する送信ステップと、前記送信ステップにおいて送信された前記記事を前記契約者以外の閲覧者に対して表示する表示ステップと、前記契約者と前記閲覧者とがどの程度の交流関係であるかを示す交流度を決定する交流度決定ステップと、前記交流度決定ステップにおいて決定された前記交流度に応じて前記契約の内容を決定する契約決定ステップとを含む。

この構成によれば、送信ステップにおいて、所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者によってネットワークを介して記事が送信される。表示ステップにおいて、送信された記事が契約者以外の閲覧者に対して表示される。交流度決定ステップにおいて、契約者と閲覧者とがどの程度の交流関係であるかを示す交流度が決定される。契約決定ステップにおいて、決定された交流度に応じて契約の内容が決定される。

したがって、ネットワークを介して記事を送信する契約者と、送信された記事を閲覧する契約者以外の閲覧者とがどの程度の交流関係であるかを示す交流度に応じて契約の内容が決定されるので、契約内容の決定時におけるリスクをより低減することができる。

また、上記態様において、前記交流度決定ステップは、前記契約者によって送信された前記記事とともに、前記契約者の本名が前記閲覧者に閲覧可能に表示される場合、前記交流度を高くすることが好ましい。

この場合、契約者の本名が閲覧者に閲覧可能に表示されることにより、契約者と閲覧者との交流関係がより緊密であると判断することができる。

また、上記態様において、前記交流度決定ステップは、前記契約者によって送信された前記記事とともに、前記契約者の住所が前記閲覧者に閲覧可能に表示される場合、前記交流度を高くすることが好ましい。

この場合、契約者の住所が閲覧者に閲覧可能に表示されることにより、契約者と閲覧者との交流関係がより緊密であると判断することができる。

また、上記態様において、前記交流度決定ステップは、前記契約者によって送信された前記記事とともに、前記契約者の顔画像が前記閲覧者に閲覧可能に表示される場合、前記交流度を高くすることが好ましい。

この場合、契約者の顔画像が閲覧者に閲覧可能に表示されることにより、契約者と閲覧者との交流関係がより緊密であると判断することができる。

また、上記態様において、前記契約者の公的身分証明書の画像を取得する画像取得ステップをさらに含み、前記交流度決定ステップは、前記画像取得ステップにおいて取得された前記契約者の公的身分証明書の画像と、前記契約者によって登録された前記契約者の本名、住所又は顔画像とが一致する場合、前記本名、前記住所又は前記顔画像が本物であると判断し、前記交流度を高くすることが好ましい。

この場合、画像取得ステップにおいて、契約者の公的身分証明書の画像が取得される。交流度決定ステップにおいて、取得された契約者の公的身分証明書の画像と、契約者によって登録された契約者の本名、住所又は顔画像とが一致する場合、本名、住所又は顔画像が本物であると判断され、交流度が高くされる。

したがって、契約者の公的身分証明書の画像に基づいて、契約者の本名、住所又は顔画像が本物であるか否かを判断することができる。

また、上記態様において、前記契約者と、前記契約者と友達関係にある閲覧者とを関連付けて記憶する記憶ステップをさらに含み、前記交流度決定ステップは、前記契約者の本名が前記閲覧者によって検索された回数、又は前記契約者の本名を検索した前記閲覧者と前記契約者とが友達関係であるとして関連付けられた数が多い場合、前記交流度を高くすることが好ましい。

この場合、記憶ステップにおいて、契約者と、契約者と友達関係にある閲覧者とが関連付けて記憶される。交流度決定ステップにおいて、契約者の本名が閲覧者によって検索された回数、又は契約者の本名を検索した閲覧者と契約者とが友達関係であるとして関連付けられた数が多い場合、交流度が高くされる。

したがって、閲覧者が契約者の本名を知っていれば、契約者の本名で検索することが可能であるので、契約者と閲覧者との交流関係が緊密であると判断することができる。また、契約者の本名を検索した閲覧者と契約者とが友達関係であるとして関連付けられた場合、契約者と閲覧者との交流関係がより緊密であると判断することができる。

また、上記態様において、前記契約者と、前記契約者と友達関係にある閲覧者とを関連付けて記憶する記憶ステップをさらに含み、前記交流度決定ステップは、前記記憶ステップにおいて前記契約者と友達関係にあるとして関連付けられている前記閲覧者の交流度の高さに応じて、前記契約者の前記交流度を決定することが好ましい。

この場合、記憶ステップにおいて、契約者と、契約者と友達関係にある閲覧者とが関連付けて記憶される。交流度決定ステップにおいて、契約者と友達関係にあるとして関連付けられている閲覧者の交流度の高さに応じて、契約者の交流度が決定される。

したがって、契約者と友達関係にあるとして関連付けられている閲覧者の交流度が高ければ、当該閲覧者と友達関係にあるとして関連付けられている契約者の交流度も高くすることが可能となる。

また、上記態様において、前記交流度決定ステップは、前記契約者の顔画像と同一の顔であると判断できる顔画像を含む画像が前記閲覧者から送信された数が多い場合、前記交流度を高くすることが好ましい。

この場合、契約者の顔画像と同一の顔であると判断できる顔画像を含む画像を送信する閲覧者は、契約者と現実世界における友達関係にあると判断することができるので、契約者の顔画像と同一の顔であると判断できる顔画像を含む画像が閲覧者から送信された数が多ければ、交流度を高く決定することができる。

また、上記態様において、前記契約は、医療保険契約又は生命保険契約を含み、前記契約者の活動量を示す活動量情報を取得する活動量取得ステップをさらに含み、前記表示ステップは、前記送信ステップにおいて送信された前記記事と、前記活動量取得ステップにおいて取得された前記活動量情報とを前記閲覧者に対して表示し、前記契約決定ステップは、前記活動量取得ステップにおいて取得された前記活動量情報と、前記交流度決定ステップにおいて決定された前記交流度とに応じて前記医療保険契約又は前記生命保険契約における保険料を決定することが好ましい。

この場合、契約は、医療保険契約又は生命保険契約を含む。活動量取得ステップにおいて、契約者の活動量を示す活動量情報が取得される。表示ステップにおいて、送信された記事と、取得された活動量情報とが閲覧者に対して表示される。契約決定ステップにおいて、取得された活動量情報と、決定された交流度とに応じて医療保険契約又は生命保険契約における保険料が決定される。

したがって、契約者の活動量を示す活動量情報が閲覧者に対して表示されるとともに、活動量情報と交流度とに応じて医療保険契約又は生命保険契約における保険料が決定されるので、契約者の活動量を反映させた適切な保険料を決定することができる。また、活動量は閲覧者に対して表示されるので、信頼性の高い活動量を用いて保険料を決定することができる。

また、上記態様において、前記活動量情報は、前記契約者の移動量を含むことが好ましい。

この場合、契約者の移動量を反映させた適切な保険料を決定することができる。また、契約者の移動量は閲覧者に対して表示されるので、信頼性の高い移動量を用いて保険料を決定することができる。

また、上記態様において、前記移動量は、前記契約者の歩数を含むことが好ましい。

この場合、契約者の歩数を反映させた適切な保険料を決定することができる。また、契約者の歩数は閲覧者に対して表示されるので、信頼性の高い歩数を用いて保険料を決定することができる。

また、上記態様において、前記活動量取得ステップは、前記契約者が所有する歩数計により前記契約者の歩数を取得することが好ましい。

この場合、契約者が所有する歩数計により契約者の歩数を取得することができる。

また、上記態様において、前記活動量情報は、前記契約者の身体情報を含むことが好ましい。

この場合、契約者の身体情報を反映させた適切な保険料を決定することができる。また、契約者の身体情報は閲覧者に対して表示されるので、信頼性の高い身体情報を用いて保険料を決定することができる。

また、上記態様において、前記身体情報は、前記契約者の脈拍、血圧、血糖値及び尿酸値のいずれかを含むことが好ましい。

この場合、契約者の脈拍、血圧、血糖値及び尿酸値のいずれかを反映させた適切な保険料を決定することができる。また、契約者の脈拍、血圧、血糖値及び尿酸値のいずれかは閲覧者に対して表示されるので、信頼性の高い脈拍、血圧、血糖値及び尿酸値のいずれかを用いて保険料を決定することができる。

また、上記態様において、前記契約は、物品をレンタルするレンタル契約を含み、前記契約決定ステップは、前記交流度決定ステップにおいて決定された前記交流度に応じて前記レンタル契約において前記契約者に物品をレンタルするか否かを決定することが好ましい。

この場合、契約は、物品をレンタルするレンタル契約を含む。契約決定ステップにおいて、決定された交流度に応じてレンタル契約において契約者に物品をレンタルするか否かが決定される。

したがって、交流度に応じてレンタル契約において契約者に物品をレンタルするか否かが決定されるので、交流度により契約者に対する信頼度を判断することができ、より信頼度が高い契約者に物品をレンタルすることができる。

また、上記態様において、前記契約は、融資契約を含み、前記契約決定ステップは、前記交流度決定ステップにおいて決定された前記交流度に応じて前記融資契約において前記契約者に融資するか否かを決定することが好ましい。

この場合、契約は、融資契約を含む。契約決定ステップにおいて、決定された交流度に応じて融資契約において契約者に融資するか否かが決定される。

したがって、交流度に応じて融資契約において契約者に融資するか否かが決定されるので、交流度により契約者に対する信頼度を判断することができ、より信頼度が高い契約者に融資することができる。

本発明の他の態様に係るサービス提供方法は、所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者によってネットワークを介して記事を送信する送信ステップと、前記契約者の活動量を示す活動量情報を取得する活動量取得ステップと、前記送信ステップにおいて送信された前記記事と、前記活動量取得ステップにおいて取得された前記活動量情報とを、前記契約者によって閲覧が許可された閲覧者に対して表示する表示ステップと、前記活動量取得ステップにおいて取得された前記活動量情報に応じて前記契約の内容を決定する契約決定ステップとを含む。

この構成によれば、送信ステップにおいて、所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者によってネットワークを介して記事が送信される。活動量取得ステップにおいて、契約者の活動量を示す活動量情報が取得される。表示ステップにおいて、送信された記事と、取得された活動量情報とが、契約者によって閲覧が許可された閲覧者に対して表示される。契約決定ステップにおいて、取得された活動量情報に応じて契約の内容が決定される。

したがって、契約者の活動量を示す活動量情報に応じて契約の内容が決定されるので、契約者の活動量を反映させた適切な契約の内容を決定することができる。また、活動量は閲覧者に対して表示されるので、信頼性の高い活動量を用いて契約の内容を決定することができる。

なお、以下で説明する実施の形態は、いずれも本発明の一具体例を示すものである。以下の実施の形態で示される数値、形状、構成要素、ステップ及びステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。また、全ての実施の形態において、各々の内容を組み合わせることもできる。

（提供するサービスの全体像）
図１（Ａ）は、本実施の形態における情報提供システムが提供するサービスの全体像を示す図である。情報提供システムは、グループ１００、データセンタ運営会社１１０及びサービスプロバイダ１２０を備える。

グループ１００は、例えば企業、団体又は家庭等であり、その規模を問わない。グループ１００には、機器Ａ及び機器Ｂを含む複数の機器１０１と、ホームゲートウェイ１０２とが存在する。複数の機器１０１は、被保険者の活動量（例えば、歩数）を計測する歩数計を含む。また、複数の機器１０１は、インターネットと接続可能な機器（例えば、歩数計を内蔵するスマートフォン等）、及びそれ自身ではインターネットと接続不可能な機器（例えば、歩数計等）を含む。複数の機器１０１は、それ自身ではインターネットと接続不可能な機器であっても、ホームゲートウェイ１０２を介してインターネットと接続可能となる機器を含んでもよい。例えば、歩数計は、内蔵されたメモリにその日の歩数を記録し、記録した歩数を、インターネットに接続可能な機器に無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介して送信してもよい。また、ユーザ１０は、グループ１００内の複数の機器１０１を使用する。

データセンタ運営会社１１０には、クラウドサーバ１１１が存在する。クラウドサーバ１１１は、インターネットを介して様々な機器と連携する仮想化サーバである。クラウドサーバ１１１は、主に通常のデータベース管理ツール等で扱うことが困難な巨大なデータ（ビッグデータ）等を管理する。データセンタ運営会社１１０は、データ管理、クラウドサーバ１１１の管理、及びそれらを行うデータセンタの運営等を行っている。データセンタ運営会社１１０が行っている役務の詳細については後述する。

ここで、データセンタ運営会社１１０は、データの管理又はクラウドサーバ１１１の運営等のみを行っている会社に限らない。例えば、図１（Ｂ）に示すように、複数の機器１０１のうちの一つの機器を開発及び製造している機器メーカが、データの管理又はクラウドサーバ１１１の管理等を行っている場合は、機器メーカがデータセンタ運営会社１１０に該当する。また、データセンタ運営会社１１０は一つの会社に限らない。例えば、図１（Ｃ）に示すように、機器メーカ及び他の管理会社が共同又は分担してデータの管理又はクラウドサーバ１１１の運営を行っている場合は、両者又はいずれか一方がデータセンタ運営会社１１０に該当する。

サービスプロバイダ１２０には、サーバ１２１が存在する。ここで言うサーバ１２１とは、その規模は問わず、例えば、個人用ＰＣ（パーソナルコンピュータ）内のメモリ等も含む。また、サービスプロバイダ１２０にサーバ１２１が存在していない場合もある。

なお、上記サービスにおいて、ホームゲートウェイ１０２は必須ではない。例えば、クラウドサーバ１１１が全てのデータ管理を行っている場合等は、ホームゲートウェイ１０２は不要となる。また、家庭内のあらゆる機器がインターネットに接続されている場合のように、それ自身ではインターネットと接続不可能な機器は存在しない場合もある。

次に、上記サービスにおける情報の流れを説明する。

まず、グループ１００の機器Ａ又は機器Ｂは、各ログ情報をデータセンタ運営会社１１０のクラウドサーバ１１１に送信する。クラウドサーバ１１１は、機器Ａ又は機器Ｂのログ情報を集積する（図１（Ａ）の矢印１３１）。ここで、ログ情報とは、複数の機器１０１が取得した、ユーザ１０の健康状態を表す情報、又は、ユーザ１０の健康状態が変化する原因を表す情報である。例えば、ログ情報は、歩数計等が備える加速度センサ又は振動センサによって取得されたユーザ１０の歩数又は移動距離などの活動量を含む。また、例えば、ログ情報は、脈拍計等の医療機器によって取得されたユーザ１０の脈拍、血圧、血糖値又は尿酸値などを含む。なお、ログ情報は、これらの情報に限らず、ユーザ１０から取得可能なすべての情報を含んでもよい。ログ情報は、インターネットを介して複数の機器１０１自体から直接クラウドサーバ１１１に提供されてもよい。また、ログ情報は、複数の機器１０１から一旦ホームゲートウェイ１０２に集積され、ホームゲートウェイ１０２からクラウドサーバ１１１に提供されてもよい。

次に、データセンタ運営会社１１０のクラウドサーバ１１１は、集積したログ情報を一定の単位でサービスプロバイダ１２０に提供する。ここで、一定の単位とは、データセンタ運営会社１１０が集積した情報を整理してサービスプロバイダ１２０に提供することのできる単位でもよいし、サービスプロバイダ１２０が要求する単位でもよい。また、一定の単位でログ情報を提供するとしているが、一定の単位でなくてもよく、状況に応じて提供する情報量が変化してもよい。ログ情報は、必要に応じてサービスプロバイダ１２０が保有するサーバ１２１に保存される（図１（Ａ）の矢印１３２）。

そして、サービスプロバイダ１２０は、ログ情報をユーザに提供するサービスに適合する情報に整理し、ユーザに提供する。サービスが提供されるユーザは、複数の機器１０１を使用するユーザ１０でもよいし、外部のユーザ２０でもよい。ユーザ１０，２０へのサービス提供方法としては、例えば、サービスプロバイダ１２０から直接ユーザ１０，２０へサービスが提供されてもよい（図１（Ａ）の矢印１３３，１３４）。また、ユーザ１０へのサービス提供方法としては、例えば、データセンタ運営会社１１０のクラウドサーバ１１１を再度経由して、ユーザ１０にサービスが提供されてもよい（図１（Ａ）の矢印１３５，１３６）。また、データセンタ運営会社１１０のクラウドサーバ１１１は、ログ情報をユーザに提供するサービスに適合する情報に整理し、サービスプロバイダ１２０に提供してもよい。

なお、ユーザ１０は、ユーザ２０と異なっていても同一であってもよい。

上記で説明したサービスプロバイダ１２０が提供するサービスとは、好適には、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）、または、保険料を更新するサービスである。これら二つのサービスは、互いに異なるサービスプロバイダで運営されてもよいし、また、単一のサービスプロバイダで運営されてもよい。

また、上記で説明したクラウドサーバ１１１は、サービスプロバイダ１２０と別のデータセンタ運営会社が運営してもよいし、サービスプロバイダ１２０と同一のデータセンタ運営会社が運営してもよい。すなわち、クラウドサーバ１１１は、ＳＮＳ又は保険料を更新するサービスのいずれかのサーバと同一であってもよいし、両方のサーバと同一であってもよい。

以下、本発明の実施の形態について、図面を参照しながら説明する。

（実施の形態１）
図２は、本発明の実施の形態１における保険料更新システムの構成を示す図である。図２に示す保険料更新システムは、活動量取得部６０１、活動量送信部６０２、ＳＮＳ管理部６０３、保険料更新部６０４、記事送信部６０７及び記事表示部６０８，６０９を備える。

図２において、ユーザ１０は、活動量取得部６０１によって取得された自らの健康に関する情報を送信することを条件に、保険会社と医療保険契約又は生命保険契約を結んでいる。すなわち、ユーザ１０は、所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者である。

活動量取得部６０１は、図１の機器Ａ又は機器Ｂに相当し、ユーザ１０の健康に関する情報（本実施の形態１では、活動量情報と称する）を取得する。活動量情報は、ユーザ１０の移動量を含む。また、移動量は、ユーザ１０の歩数を含む。例えば、活動量取得部６０１は、歩数計等で構成され、加速度センサ又は振動センサを備える。活動量取得部６０１は、加速度センサ又は振動センサによって計測されたユーザ１０の歩数又は移動距離などを、活動量として取得する。

あるいは、活動量取得部６０１は、脈拍計等の医療機器で構成されてもよい。この場合、ユーザ１０の活動量情報は、ユーザ１０の身体情報を含む。また、身体情報は、脈拍、血圧、血糖値又は尿酸値等を含む。なお、活動量情報は、これらの情報に限らず、ユーザ１０から取得可能な、ユーザ１０の健康状態が直接的又は間接的に判定できるすべての情報を含み、それらの活動量情報を取得できる装置が、活動量取得部６０１となりうる。

活動量送信部６０２は、活動量取得部６０１によって取得された活動量情報を、ＳＮＳ管理部６０３及び保険料更新部６０４に送信する。活動量送信部６０２は、例えば、ソフトウェア的にはインターネットプロトコル等で実装され、ハードウェア的には、第３世代移動通信システム又はＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）などの携帯電話通信サービス、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）又はイーサネット（登録商標）等で実装される。なお、活動量送信部６０２は、活動量をＳＮＳ管理部６０３及び保険料更新部６０４に転送できれば、どのような構成であってもよい。また、図１におけるホームゲートウェイ１０２は、活動量送信部６０２の一部を構成してもよい。

記事送信部６０７は、ユーザ１０によって入力された記事を、ネットワークを介してＳＮＳ管理部６０３へ送信する。記事送信部６０７は、例えばスマートフォン又はパーソナルコンピュータなどの端末６１１に含まれる。記事は、例えば、ユーザ（契約者）に実際に起こった出来事である。

ＳＮＳ管理部６０３は、好適には、いわゆるソーシャル・ネットワーク・サービスを提供するコンピュータシステムであり、例えばＦａｃｅｂｏｏｋ（登録商標）又はｍｉｘｉ（登録商標）などに相当するサービスプロバイダによって運営されるサーバ６０５に含まれる。すなわち、ＳＮＳ管理部６０３は、記事送信部６０７によって送信されたユーザ１０が投稿した記事を保存し、インターネット等を通じて、ユーザ１０とシステム上の友達関係にあるユーザ２０又はユーザ３０に対して、保存された記事を閲覧可能な状態にするサービスを提供する。なお、ユーザ２０及びユーザ３０は、ユーザ１０の現実の友人であることが望ましいが、その限りではない。図２のサーバ６０５は、図１におけるサーバ１２１に相当する。

ＳＮＳ管理部６０３は、記事表示部６０８，６０９からの要求に応じて、記事送信部６０７によって送信された記事を記事表示部６０８，６０９へ送信する。

記事表示部６０８，６０９は、ＳＮＳ管理部６０３によって送信された記事をユーザ１０以外の閲覧者（ユーザ２０又はユーザ３０）に対して表示する。記事表示部６０８，６０９は、例えばスマートフォン又はパーソナルコンピュータなどの端末６１２，６１３に含まれる。

ＳＮＳ管理部６０３は、活動量送信部６０２からユーザ１０の活動量情報を受信すると、記事送信部６０７によって送信されたユーザ１０の記事と同様に、活動量をユーザ１０の記事として保存し、ユーザ２０又はユーザ３０に対して、保存された記事を閲覧可能な状態にする。これにより、記事表示部６０８，６０９は、記事送信部６０７によって送信された記事と、活動量取得部６０１によって取得された活動量情報とを閲覧者に対して表示する。なお、本実施の形態では、活動量は、直接、活動量送信部６０２からＳＮＳ管理部６０３に送信されるが、この限りではない。活動量は、図１におけるデータセンタ運営会社１１０のクラウドサーバ１１１に一旦蓄積された後、ＳＮＳ管理部６０３、すなわち図１におけるサービスプロバイダ１２０のサーバ１２１に送信されてもよい。

保険料更新部６０４は、保険業務サービスを提供するコンピュータシステムであり、好適には、保険会社に相当するサービスプロバイダによって運営されるサーバ６０６に含まれる。図２のサーバ６０６は、図１におけるサーバ１２１に相当する。サーバ６０６は、ＳＮＳ管理部６０３を備えるサーバ６０５と同一のサーバである必要はなく、別のサーバでもよい。また、サーバ６０６を運営するサービスプロバイダは、サーバ６０５を運営するサービスプロバイダと同一のサービスプロバイダである必要はなく、別のサービスプロバイダでもよい。

保険料更新部６０４は、活動量取得部６０１によって取得された活動量情報に応じて契約の内容を決定する。保険料更新部６０４は、活動量取得部６０１によって取得された活動量情報に応じて医療保険契約又は生命保険契約における保険料を決定する。

保険料更新部６０４は、活動量送信部６０２によって送信された活動量情報を受信し、一定期間、例えば一ヶ月間における活動量を集計する。その後、保険料更新部６０４は、ユーザ１０の活動量（健康状態）を評価し、評価結果に基づき、ユーザ１０の保険料を更新する。なお、本実施の形態では、活動量情報は、直接、活動量送信部６０２から保険料更新部６０４に送信されるが、この限りではない。活動量は、ＳＮＳ管理部６０３と同様に、図１におけるデータセンタ運営会社１１０のクラウドサーバ１１１に一旦蓄積された後、保険会社のサーバ６０６、すなわち図１におけるサービスプロバイダ１２０のサーバ１２１に送信されてもよい。

図３は、本発明の実施の形態１における保険料更新システムの動作を説明するためのフローチャートである。

まず、ステップＳ１において、記事送信部６０７は、ユーザ１０によって記事が入力されたか否かを判断する。このとき、ユーザ１０は、端末６１１が備える入力部（不図示）を用いて記事を入力する。ここで、記事が入力されていないと判断された場合（ステップＳ１でＮＯ）、ステップＳ４の処理に移行する。

一方、記事が入力されたと判断された場合（ステップＳ１でＹＥＳ）、ステップＳ２において、記事送信部６０７は、入力された記事をＳＮＳ管理部６０３へ送信する。

次に、ステップＳ３において、ＳＮＳ管理部６０３は、受信した記事を記事表示部６０８及び記事表示部６０９へ送信し、記事表示部６０８及び記事表示部６０９は、受信した記事を表示する。このとき、ＳＮＳ管理部６０３は、ユーザ１０の記事送信部６０７から送信された記事を、ユーザ１０と友達関係であると予め対応付けられているユーザ２０，３０の記事表示部６０８及び記事表示部６０９へ送信する。

次に、ステップＳ４において、活動量送信部６０２は、活動量取得部６０１によって活動量が取得されたか否かを判断する。ここで、活動量が取得されていないと判断された場合（ステップＳ４でＮＯ）、ステップＳ７の処理に移行する。

一方、活動量が取得されたと判断された場合（ステップＳ４でＹＥＳ）、ステップＳ５において、活動量送信部６０２は、活動量取得部６０１によって取得された活動量をＳＮＳ管理部６０３及び保険料更新部６０４へ送信する。なお、保険料更新部６０４は、受信した活動量をユーザ１０に対応付けて記憶する。

次に、ステップＳ６において、ＳＮＳ管理部６０３は、受信した活動量を記事として記事表示部６０８及び記事表示部６０９へ送信し、記事表示部６０８及び記事表示部６０９は、受信した記事（活動量）を表示する。このとき、ＳＮＳ管理部６０３は、ユーザ１０の活動量取得部６０２から送信された記事（活動量）を、ユーザ１０と友達関係であると予め対応付けられているユーザ２０，３０の記事表示部６０８及び記事表示部６０９へ送信する。

次に、ステップＳ７において、保険料更新部６０４は、保険料を更新する保険料更新タイミングであるか否かを判断する。例えば、保険料更新部６０４は、一ヶ月に一度、保険料を更新する。例えば、保険料更新部６０４は、月初に、前月の活動量を用いて当月の保険料を決定してもよい。また、例えば、保険料更新部６０４は、月末に、当月の活動量を用いて翌月の保険料を決定してもよい。ここで、保険料更新タイミングではないと判断された場合（ステップＳ７でＮＯ）、ステップＳ１の処理に戻る。

一方、保険料更新タイミングであると判断された場合（ステップＳ７でＹＥＳ）、ステップＳ８において、保険料更新部６０４は、活動量を用いて保険料を決定する。

次に、ステップＳ９において、保険料更新部６０４は、決定した保険料をユーザ１０の端末６１１へ送信し、端末６１１は、受信した保険料を表示する。その後、ステップＳ１の処理へ戻り、ステップＳ１以降の処理が行われる。

図４は、実施の形態１において、記事表示部６０８によって表示される表示画面の一例を示す図である。表示画面７０１は、ユーザ２０の友達が投稿した記事を表示している。記事７０２〜７０３は、ユーザ２０の友達関係にあるユーザのそれぞれによって送信された記事を表している。この中で、記事７０２，７０３，７０４は、ユーザ２０の友達であるユーザ１０によって送信された記事であり、記事７０５，７０６は、ユーザ２０の他の友達であるユーザ３０によって送信された記事である。表示画面７０１が表示されることで、ユーザ２０は、友達であるユーザ１０及びユーザ３０の近況を知ることができる。

記事７０２，７０３は、ユーザ１０自身が入力した記事ではなく、活動量送信部６０２が送信した、活動量取得部６０１によって取得された活動量情報である。すなわち、ユーザ１０の活動量は、ユーザ２０に閲覧可能な状態になっている。記事７０２は、歩数計によって取得されたユーザ１０の１日の歩数を表している。記事７０３は、血圧計によって取得されたユーザ１０の血圧を表している。

保険料更新部６０４は、記事７０２，７０３と同様の内容の活動量情報を活動量送信部６０２から受信し、受信した活動量情報に応じて、ユーザ１０の保険料を更新する。ユーザ１０の活動量は、ユーザ１０の友達（ユーザ２０及びユーザ３０）に閲覧可能な状態である。そのため、ユーザ１０が、活動量取得部６０１を、他人、例えば子供に装着して活動量情報を偽造した場合、偽造したことが友達に知られることとなり、友達の信頼を失うこととなる。このことが抑止力となり、ユーザ１０は、活動量を偽造することが困難となる。本実施の形態の構成により、活動量が真実である可能性が高い状態において、保険料を更新することができるので、保険会社は保険のリスクを低減することができるという格別の効果を奏することができる。

図５は、実施の形態１において、更新された保険料をユーザ１０に通知する表示画面の一例を示す図である。図５では、一ヶ月の平均歩数（一日分）に応じて保険料が増減することが明記され、さらに、一ヶ月の平均歩数（一日分）により決定された今月分の保険料が提示されている。保険料更新部６０４は、一ヶ月の平均歩数（一日分）が多くなるにつれて、保険料を安くする。図５に示す表示画面では、ユーザの平均歩数が１００００歩から１２０００歩の間であったため、保険料更新部６０４は、一ヶ月の保険料を５０００円に決定する。

このように、保険料とともに活動量が表示されることで、ユーザ１０は、自分の活動が保険料に与える影響を認識することができ、その結果、保険料を低減させるための活動を行うようになる。保険料が低減することはユーザ１０のメリットである。また、ユーザ１０が健康になることで、保険リスクがより一層低下する。保険リスクが低下することは、保険会社のメリットである。なお、図５で例示した保険料は、保険会社のサーバ６０６からユーザ１０の端末６１１（スマートフォンなど）にメールで送信してもよい。また、図５で例示した保険料は、保険会社のサーバ６０６からユーザ１０の端末６１１に、図５の表示画面を表示するためのインターネットのアドレス（ＵＲＬ）をメールで送信してもよい。さらに、図５で例示した保険料は、郵送でユーザ１０に通知されてもよい。

（実施の形態２）
図６は、本発明の実施の形態２における保険料更新システムの構成を示す図である。図６に示す保険料更新システムは、活動量取得部６０１、活動量送信部６０２、ＳＮＳ管理部６０３、保険料更新部６０４、記事送信部６０７、記事表示部６０８，６０９及び交流度決定部９０１を備える。

図６において、交流度決定部９０１は、ユーザ１０（契約者）と、ユーザ１０が送信した記事を閲覧する閲覧者とがどの程度の交流関係であるかを示すＳＮＳリアル交流度を決定する。交流度決定部９０１は、ＳＮＳ管理部６０３に保存された投稿記事又はユーザの属性情報に基づいてＳＮＳリアル交流度を決定する。ユーザ１０が送信した記事を閲覧する閲覧者がシステム内のみの仮想的な友達である場合、ＳＮＳリアル交流度は低くなる。また、ユーザ１０が送信した記事を閲覧する閲覧者が、実際に会ったことがあり、通常の社会的な交流がある現実の友達である場合、ＳＮＳリアル交流度は高くなる。ＳＮＳリアル交流度は、例えば数値で表されるが、本発明は特にこれに限定されず、所定値に対して高いか低いかのレベルで表されてもよい。

保険料更新部６０４は、実施の形態１で説明した構成と基本的には同一であるが、交流度決定部９０１によって決定されたＳＮＳリアル交流度をさらに利用して、保険料を更新する点が異なる。保険料更新部６０４は、交流度決定部９０１によって決定されたＳＮＳリアル交流度に応じて契約の内容を決定する。

一例として、ソーシャルネットワーキングサービスを提供するサービスプロバイダのサーバ６０５と、保険会社のサーバ６０６とは、それぞれ異なる事業主によって運営されている。サーバ６０５はＳＮＳ運営会社によって運営され、サーバ６０６は保険会社によって運営されている。ＳＮＳ運営会社は、あらかじめ定められた契約のもと、保険会社に対し、ＳＮＳリアル交流度を提供する。保険会社は、ＳＮＳリアル交流度の提供に応じて、ＳＮＳ運営会社に対し、情報料を支払う。ＳＮＳ運営会社のサーバ６０５は、外部のコンピュータシステムからの要求に応じてＳＮＳリアル交流度を提供するためのＡＰＩ（アプリケーションインターフェース）を持つ。保険会社のサーバ６０６に含まれる保険料更新部６０４は、サーバ６０５のＡＰＩにアクセスし、契約を結んでいる会社であることを示す認証コードと、対象となるユーザ１０を識別するユーザＩＤとを渡すことで、ユーザ１０に関するＳＮＳリアル交流度を受け取る。

図６における交流度決定部９０１及び保険料更新部６０４以外の構成要素は、実施の形態１と同様であるので、説明を省略する。

交流度決定部９０１の説明をする前に、実施の形態１における課題を説明する。実施の形態１では、ユーザ１０の活動量情報に応じて保険料を更新しているが、活動量情報はＳＮＳ管理部６０３によってＳＮＳに開示され、ユーザ１０の友達（ユーザ２０）に対して活動量情報が閲覧可能となる。これにより、ユーザ１０による活動量情報の偽造を抑制している。しかし、ユーザ１０の友達が、システム内のみの仮想的な友達である場合、ユーザ１０は、活動量情報を偽造することを躊躇しないかもしれない。ユーザ２０が、システム内のみの交流で、ユーザ１０と実際に会ったこともない場合、ユーザ１０の活動量情報の偽造を、ユーザ２０は見抜けない可能性が高い。また、活動量情報の偽造をユーザ２０が見抜けたとしても、システム内だけの友達の信用を失ったところで、ユーザ１０にとってのデメリットも小さい。したがって、活動量情報のＳＮＳでの公開が、活動量情報の偽造を阻止するための抑止力にならない可能性がある。

この課題を解決するため、実施の形態２においては、保険料更新システムは、ＳＮＳ管理部６０３におけるユーザ１０の友達関係が、活動量の偽造を阻止するための抑止力になるだけの友達関係であることを示すＳＮＳリアル交流度を決定する交流度決定部９０１を備える。保険料更新部６０４は、決定されたＳＮＳリアル交流度に基づいて、保険料を更新する。

交流度決定部９０１は、下記に例示する様々な方法によりＳＮＳリアル交流度を決定することが可能であるが、ＳＮＳリアル交流度の決定方法は、二つに大別できる。第一の方法は、ユーザが、仮想的な属性ではなく、リアルな属性をＳＮＳ側に提示しているか否かに応じてＳＮＳリアル交流度を決定する。第２の方法は、ＳＮＳ側に提示されたリアルな属性によって、ＳＮＳでの交流を行っているか否かに応じてＳＮＳリアル交流度を決定する。

実際の姿が見えないインターネットの世界では、リアルな属性を隠して、仮想的な人格を作って、他人と交流することが可能となる。典型的には、性別を偽ってインターネット上で交流することも可能である。このような状態では、例え活動量をＳＮＳ管理部６０３に送信して閲覧可能なシステムであったとしても、活動量の偽造を控えようという抑止力にはならない。なぜならば、最初から、近況を示す記事の多くが偽造されているからである。

従って、仮想的な人格ではなく、リアルな人格のリアルな属性をＳＮＳ側に提示していることは、それだけで、ＳＮＳでの記事の信憑性を高めることになる。少なくとも、実名を公表した上で、性別を偽った記事を投稿することはできない。すなわち、実名を公表していれば、活動量の偽造を阻止するための抑止力になる。この観点が、上記の第１の方法によるＳＮＳリアル交流度の決定方法の基本的な考え方である。

さらに、ＳＮＳ上で、リアルな属性を公開した上で、リアルな友達と交流が行われていることが確認できれば、より一層、ＳＮＳでの記事の信憑性が高まる。通常の人間は、社会的であるがゆえに、リアルな友達の信用を失うようなことは控える。従って、ＳＮＳ上で他のユーザと交流していれば、より一層、活動量の偽造を阻止するための抑止力となる。この観点が、上記の第２の方法によるＳＮＳリアル交流度の決定方法の基本的な考え方である。

第１の方法による、ＳＮＳリアル交流度の決定方法を、下記に例示する。

（１）交流度決定部９０１は、ユーザ１０（契約者）によって送信された記事とともに、ユーザ１０の本名が閲覧者に閲覧可能に表示される場合、ＳＮＳリアル交流度を高くする。また、交流度決定部９０１は、取得されたユーザ１０（契約者）の公的身分証明書の画像と、ユーザ１０によって登録されたユーザ１０の本名とが一致する場合、本名が本物であると判断し、ＳＮＳリアル交流度を高くする。

ＳＮＳ管理部６０３に登録されているユーザのアカウント名が偽名ではなく、本名であり、且つ、本名であることを証明する公的身分証明書がＳＮＳ管理部６０３に提示された場合、ＳＮＳリアル交流度はより高くなる。公的身分証明書は、例えば、運転免許証又は保険証等を含む。公的身分証明書は、ＳＮＳ管理部６０３を運営するスタッフに対面して提示する必要はない。端末６１１は、運転免許証又は保険証をスキャナで電子画像化し、その画像をＳＮＳ管理部６０３に送信してもよい。さらに、ＳＮＳ管理部６０３は、送信された画像からテキストを読み取り、読み取ったテキストと、ユーザによって入力された名前とを照合してもよい。つまり、公的身分証明書の提示は、人手ではなく、コンピュータを用いた方法又は装置で実現可能である。

なお、運転免許証又は保険証の画像は、ユーザの住所を含む。そのため、当然、ユーザの住所がＳＮＳ管理部６０３に提示された場合は、ＳＮＳリアル交流度はより高くなる。すなわち、交流度決定部９０１は、ユーザ１０（契約者）によって送信された記事とともに、ユーザ１０の住所が閲覧者に閲覧可能に表示される場合、ＳＮＳリアル交流度を高くしてもよい。また、交流度決定部９０１は、取得されたユーザ１０（契約者）の公的身分証明書の画像と、ユーザ１０によって登録されたユーザ１０の住所とが一致する場合、住所が本物であると判断してもよい。

（２）交流度決定部９０１は、ユーザ１０（契約者）によって送信された記事とともに、ユーザ１０の顔画像が閲覧者に閲覧可能に表示される場合、ＳＮＳリアル交流度を高くする。ＳＮＳにおけるユーザのアカウントのアイコン画像が、風景、静物又は絵などではなく、ユーザの顔写真であれば、ＳＮＳリアル交流度はより高くなる。

（３）ＳＮＳにおいて公開されているユーザの顔画像が、ユーザによって送信された運転免許証等の公的身分証明書に含まれる顔画像と同じであれば、ＳＮＳリアル交流度はより高くなる。すなわち、交流度決定部９０１は、取得されたユーザ１０（契約者）の公的身分証明書の画像と、ユーザ１０によって登録されたユーザ１０の顔画像とが一致する場合、顔画像が本物であると判断し、ＳＮＳリアル交流度を高くする。

（４）出身校又は会社などの、ユーザが帰属する団体に関する情報と、ユーザの氏名とが登録された場合、ＳＮＳ管理部６０３は、団体名と氏名とを検索キーワードとして、インターネット検索を行う。その結果、登録された団体に登録された氏名の人物が存在することが確認された場合、ＳＮＳリアル交流度はより高くなる。例えば、登録された団体名と氏名とが記載された学術論文が検索結果に含まれる場合、登録された氏名の人物が登録された団体に帰属している可能性は高い。

また、検索結果に含まれる学術論文の末尾の顔写真と、アカウントのアイコンの顔写真とを、顔認証技術により照合し、同一の人物であると判定された場合、ＳＮＳリアル交流度はより高くなる。

また、ＳＮＳ管理部６０３は、公開されている特許文献の中から、登録された団体名（出願人）と登録された氏名（発明者）とを検索してもよい。その結果、登録された団体及び登録された氏名を含む特許文献が存在する場合、ＳＮＳリアル交流度はより高くなる。インターネット検索は、いわゆる検索サービスのＷｅｂサイトによる全Ｗｅｂページを対象にしたものでもよい。また、例えば学術論文の検索は、論文専用のＷｅｂサイトに対してのみ行ってもよい。さらに、特許文献の検索は、特許データベースに対してのみ行ってもよい。また、公的な文書である学術論文又は特許文献よりも信頼度は落ちるが、ＳＮＳ管理部６０３は、登録された帰属団体又は登録された帰属団体に関連する団体が運営するＷｅｂサイト（出身校の同窓会、大学の研究室、又は団体の関係者によるスポーツイベントの記録など）に、登録された氏名が存在するか否かを判断してもよい。登録された氏名が存在する場合、ＳＮＳリアル交流度はより高くなる。

また、ＳＮＳ管理部６０３は、ある名前の人物が全国に何人いるかを集計しているＷｅｂサイトを利用し、登録された名前の人物が所定数以上である場合、登録された名前の人物が所定数より少ない場合に比べ、ＳＮＳリアル交流度は低くなる。こうすれば、同姓同名の人物を誤って認識してしまった場合のリスクを軽減することができる。逆に、登録された名前が非常に珍しい名前である場合、すなわち、登録された名前の人物が所定数より少ない場合、ＳＮＳリアル交流度は高くなることはいうまでもない。

（５）氏名と共に、住所が登録された場合は、ＳＮＳリアル交流度は高くなる。例えば、郵便局のＷｅｂサイトを利用し、登録された住所がでたらめなものでなく、確かに存在する住所であると判定できた場合は、ＳＮＳリアル交流度はより高くなる。さらに、登録された郵便番号が、登録された住所を示す場合は、ＳＮＳリアル交流度はより高くなる。また、スマートフォンによって住所が登録される場合、スマートフォンで取得したＧＰＳ信号からユーザが登録を行っている位置を特定し、特定した位置が、登録された住所と一致した場合は、ＳＮＳリアル交流度はより高くなる。

なお、第１の決定方法は上記の方法に限るものではなく、ユーザのリアルな属性がＳＮＳにどれくらい提示されているかを評価するものであれば、他の方法も用いることができる。

続いて、第２の方法による、ＳＮＳリアル交流度の決定方法を、下記に例示する。

（６）上記（１）の方法によって本名であると確認されたアカウント名がＳＮＳ内において他のユーザによって検索され、その検索結果により、アカウント名に対応するユーザと他のユーザとがＳＮＳ上の友達関係となった場合、ＳＮＳリアル交流度はより高くなる。なお、ＳＮＳ上の友達関係となるとは、ユーザ同士を友達として関連付けることである。例えば、ユーザ２０がユーザ１０とＳＮＳ上の友達になることを所望する場合、ユーザ２０は、ユーザ１０に対してＳＮＳ上の友達になってもよいかを確認する。そして、ユーザ１０によって承認された場合、ユーザ１０とユーザ２０とは友達として関連付けられる。その場合、ユーザ１０を識別するための識別情報に対して、ユーザ２０を識別するための識別情報が対応付けられて記憶される。また、上記の方法で友達関係となったユーザの数が多いほど、ＳＮＳリアル交流度はより高くしてもよい。

すなわち、ＳＮＳ管理部６０３は、ユーザ１０（契約者）と、ユーザ１０と友達関係にある閲覧者とを関連付けて記憶する。交流度決定部９０１は、ユーザ１０の本名が閲覧者によって検索された回数、又はユーザ１０の本名を検索した閲覧者とユーザ１０とが友達関係であるとして関連付けられたが多い場合、ＳＮＳリアル交流度を高くする。

（７）上記（３）の方法によって公的身分証明書に含まれる顔画像と同じであると判定されたユーザ１０の顔画像を含む画像が、ユーザ１０以外の他のユーザから送信された場合、ＳＮＳリアル交流度はより高くなる。すなわち、ＳＮＳ管理部６０３は、ユーザ１０以外の他のユーザから送信された画像に、ユーザ１０の顔画像が含まれているか否かを判断し、他のユーザから送信された画像に、ユーザ１０の顔画像が含まれていると判断された場合、所定のＳＮＳリアル交流度をユーザ１０に付与する。また、他のユーザから送信された画像に、ユーザ１０とＳＮＳ上の友達関係にあるユーザ２０の顔画像が含まれている場合、ＳＮＳリアル交流度はより高くなる。さらに、ユーザ２０の顔画像が、上記（３）の方法によって公的身分証明書に含まれる顔画像と同じであると判定された場合、ＳＮＳリアル交流度はより高くなる。

交流度決定部９０１は、ユーザ１０（契約者）の顔画像と同一の顔であると判断できる顔画像を含む画像が閲覧者から送信された数が多い場合、ＳＮＳリアル交流度を高くする。

（８）ＳＮＳリアル交流度が高いユーザと友達関係であれば、ＳＮＳリアル交流度はより高くなる。すなわち、ＳＮＳ管理部６０３は、ユーザ１０と友達関係にある他のユーザのＳＮＳリアル交流度が所定値以上である場合、所定のＳＮＳリアル交流度をユーザ１０に付与する。ＳＮＳ管理部６０３は、ユーザ１０（契約者）と友達関係にある閲覧者とを関連付けて記憶する。交流度決定部９０１は、ＳＮＳ管理部６０３においてユーザ１０と友達関係にあるとして関連付けられている閲覧者のＳＮＳリアル交流度の高さに応じて、ユーザ１０のＳＮＳリアル交流度を決定する。

交流度決定部９０１は、上記の（１）〜（８）で説明した条件を満たす毎に所定の値のＳＮＳリアル交流度をユーザ１０に付与する。例えば、ユーザ１０が本名をＳＮＳ上で公開している場合、交流度決定部９０１は、ＳＮＳリアル交流度“１０”をユーザ１０に付与し、ユーザ１０が住所をＳＮＳ上で公開している場合、交流度決定部９０１は、ＳＮＳリアル交流度“１０”をユーザ１０に付与する。交流度決定部９０１は、付与されたＳＮＳリアル交流度を合算する。

なお、第２の決定方法は上記の方法に限るものではなく、ユーザのリアルな友達との交流がＳＮＳにどれくらい反映されているかを評価するものであれば、他の方法も用いることができる。

図７は、本発明の実施の形態２における保険料更新システムの動作を説明するためのフローチャートである。

ステップＳ２１〜ステップＳ２７の処理は、図３のステップＳ１〜Ｓ７の処理と同じであるので、説明を省略する。

保険料更新タイミングであると判断された場合（ステップＳ２７でＹＥＳ）、ステップＳ２８において、保険料更新部６０４は、交流度決定部９０１に対してＳＮＳリアル交流度を要求し、交流度決定部９０１は、ＳＮＳリアル交流度を決定して保険料更新部６０４へ送信する。なお、交流度決定部９０１は、上述した方法により、ＳＮＳリアル交流度を決定する。

次に、ステップＳ２９において、保険料更新部６０４は、受信した活動量と、交流度決定部９０１によって決定されたＳＮＳリアル交流度とを用いて保険料を決定する。なお、活動量とＳＮＳリアル交流度とを用いて保険料を決定する方法については、後述する。

次に、ステップＳ３０において、保険料更新部６０４は、決定した保険料をユーザ１０の端末６１１へ送信し、端末６１１は、受信した保険料を表示する。その後、ステップＳ２１の処理へ戻り、ステップＳ２１以降の処理が行われる。

以上のように決定されたＳＮＳリアル交流度を用いて保険料を決定する例を、図８に示す。図８は、実施の形態２において、ＳＮＳリアル交流度を用い更新された保険料をユーザ１０に通知する表示画面の一例を示す図である。図５と異なる点は、横軸の数値が、歩数ではなく、保険料削減寄与度となっている点である。保険料削減寄与度は、以下の式（１）に示すように、一日の平均歩数と、交流度変換値とを乗算して求める。

保険料削減寄与度＝一日の平均歩数×交流度変換値・・・・（１）

取得された歩数計の数値が、偽造されていないと十分に信用できるだけのリアルさがＳＮＳに反映されている場合、交流度変換値は“１”となり、取得された歩数計の数値が、まったく信用できない場合、交流度変換値は“０”となる。例えば、第１の方法及び第２の方法により決定したＳＮＳリアル交流度が、所定の閾値以上である場合、交流度変換値は１に設定され、ＳＮＳリアル交流度が閾値より小さい場合、交流度変換値は、閾値でＳＮＳリアル交流度を除算した値に設定される。これにより、交流度変換値は、０から１までの値になる。

ＳＮＳリアル交流度を用いて算出した交流度変換値を、歩数に乗算することで、保険料削減寄与度は、０から歩数までの値となる。すなわち、交流度変換値が１ということは、ユーザ同士のリアルな交流がＳＮＳに十分に反映されており、ＳＮＳ管理部６０３に送信された歩数が十分に確からしいということであり、保険料削減寄与度は、活動量取得部６０１が取得した値そのものになる。一方、交流度変換値が０．５ということは、ユーザ同士のリアルな交流がＳＮＳに十分に反映されておらず、ＳＮＳ管理部６０３に送信された歩数が半分程度しか信用できないということであり、保険料削減寄与度は、活動量取得部６０１が取得した値の半分となる。保険料更新部６０４は、このように算出された保険料削減寄与度を用いて、図８に示すグラフにより、保険料を更新する。図８に示すグラフからわかるように、交流度変換値が０、すなわち、リアルな交流がＳＮＳにまったく反映されていない場合は、保険料削減寄与度も０となり、取得された歩数が多くても、保険料が削減されることはない。

本実施の形態２では、前記したように、ユーザ１０がＳＮＳに活動量を記事として投稿することを条件に保険会社がユーザ１０と医療保険契約又は生命保険契約を結び、ＳＮＳリアル交流度に応じて保険料が更新されるが、本発明はその限りではない。保険会社は、保険契約前に、ユーザ１０のＳＮＳリアル交流度が一定の基準を満たすか否かを判定し、ＳＮＳリアル交流度が一定の基準を満たさなければ、ＳＮＳに活動量を投稿することを条件とする保険契約を拒否してもよい。

ＳＮＳ管理部６０３を備えるサーバ６０５は、交流度決定部９０１を備え、サーバ６０５を運営するサービスプロバイダは、決定したＳＮＳリアル交流度を保険会社に販売してもよい。また、保険会社が運営するサーバ６０６は、交流度決定部９０１を備えてもよい。また、保険会社及びＳＮＳのいずれのサービスプロバイダでもない第３のサービスプロバイダが運営するサーバが、交流度決定部９０１を備えてもよい。

前記したように、実施の形態２によれば、交流度決定部９０１により、リアルな交流がＳＮＳに反映されている度合に応じて、保険料を更新することができる。これにより、保険料の更新に伴うリスクをより一層低減できるという、格別の効果を奏することができる。

なお、ＳＮＳリアル交流度は、単一の数値である必要はなく、ｎ次元のベクトルデータであってもよい。例えば、ＳＮＳリアル交流度は、第１の数値及び第２の数値の二つの数値で構成されもよく、第１の数値は、ＳＮＳ側に提供したリアルな属性の量を示し、第２の数値は、ＳＮＳ上での他のユーザとの交流度を示してもよい。

（実施の形態３）
実施の形態２は、交流度決定部９０１を実施の形態１に応用するものであったが、交流度決定部９０１は、そのほかの形態にも応用できる。

図９は、本発明の実施の形態３におけるサービス提供システムの構成を示す図である。実施の形態３は、交流度決定部９０１を利用する別の実施の形態である。図９に示すサービス提供システムは、ＳＮＳ管理部６０３、記事送信部６０７、記事表示部６０８，６０９、交流度決定部９０１及びサービス提供者システム１１０１を備える。

図９において、サービス提供者システム１１０１は、ユーザ１０に対してある種のサービスを提供するサービス提供者が運営するコンピュータシステムである。ここで言うサービス提供者とは、ある種のリスクを負いながら、ユーザ１０から対価を受け取り、ある種のサービスを提供する業務を行う業者を広く示している。このようなサービス提供者は、典型的には、レンタル業者又は融資会社である。

レンタル業者は、対価を受け取り、物品を貸し出すことを業務とするが、常に、貸した物品が返却されないというリスクを負っている。そのリスクを低減するため、レンタル業者は、例えば利用者に対して、運転免許証の提示を求める。これは、貸した物品が返却されない際に、利用者に連絡することで、リスクを低減しようとするものである。また、レンタル業者は、物品が利用者から返却されないことを想定し、その対策として、盗難保険に加入する。

運転免許証の提示によって、利用者の身元が明らかになることは、運転免許証が提示されない場合に比べて、確かにリスクの低減につながる。しかしながら、一部の利用者が物品を返却しないというリスクをなくしてしまうことはできない。さらに、リスクは、盗難保険に加入することによって低減できるが、盗難保険の保険料は、レンタルの対価に上乗せされる。つまり、レンタル業の利用者は、一部の利用者のために、当人に窃盗する気がないにもかかわらず、レンタル業者に、物品が窃盗されるかもしれないとみなされ、その分のリスクが、レンタル料に上乗せされているというのが現状である。このことは、レンタル業者と利用者との双方にとってのデメリットである。

本実施の形態３は、前記したようなデメリットを、ＳＮＳ管理部６０３と交流度決定部９０１とを利用することで、解決するものである。

図９において、ユーザ１０は、ＳＮＳ管理部６０３によって管理されるＳＮＳのアカウントを持っている。さらに、ユーザ１０は、リアルな友達であるユーザ２０及びユーザ３０と、ＳＮＳ管理部６０３によって管理されるＳＮＳにおいても交流している。

サービス提供者システム１１０１は、ユーザ１０に対してサービスを提供するサービス提供者が運営する、コンピュータを用いたシステムであり、ＳＮＳ管理部６０３によって管理されるＳＮＳのアカウントを持っている。

ユーザ１０は、サービス提供者に対して、サービスの提供を依頼する。例えば、端末６１１は、サービス提供者システム１１０１に対して、物品のレンタルを依頼する。サービス提供者システム１１０１は、交流度決定部９０１によって決定されたユーザ１０に関するＳＮＳリアル交流度を取得する。サービス提供者システム１１０１は、取得したＳＮＳリアル交流度が十分高いか否か、すなわち、取得したＳＮＳリアル交流度が所定値以上であるか否かを判断する。ＳＮＳリアル交流度が十分高いと判断された場合、サービス提供者システム１１０１は、ユーザ１０のアカウントに対して、友達として関連付けることを承認するための友達承認依頼を送信するようにＳＮＳ管理部６０３に指示する。ユーザ１０は、友達承認依頼を承認する。すると、ＳＮＳ管理部６０３は、ユーザ１０とサービス提供者とを友達として関連付ける。これにより、図１０で図示したような関係が構築される。

なお、ＳＮＳリアル交流度が低いと判断された場合、すなわち、ＳＮＳリアル交流度が所定値より小さいと判断された場合、サービス提供者システム１１０１は、ユーザ１０の端末６１１に対し、物品を貸し出すことができないことを通知してもよい。このように、サービス提供者システム１１０１は、交流度決定部９０１によって決定されたＳＮＳリアル交流度に応じてレンタル契約において契約者に物品をレンタルするか否かを決定する。

図１０は、サービスの提供が開始される際のユーザとサービス提供者との関係を説明するための模式図である。ユーザ１０とサービス提供者システム１１０１とは、ＳＮＳ上の友達として関連付けられている。また、ユーザ１０のリアルな友達であるユーザ２０及びユーザ３０と、ユーザ１０とは、ＳＮＳ上の友達として関連付けられている。このような関係が構築されたことを確認したサービス提供者は、ユーザ１０から対価を受け取った上で、サービスの提供、すなわち物品のレンタルを行う。

図１１は、返却期限が経過する前に、ユーザ１０が物品を返却した場合のユーザとサービス提供者との関係を説明するための模式図である。物品の返却が確認された後、サービス提供者システム１１０１は、サービス提供者システム１１０１のアカウントと、ユーザ１０のアカウントとにおける友達関係を破棄するようにＳＮＳ管理部６０３に指示する。ＳＮＳ管理部６０３は、サービス提供者システム１１０１とユーザ１０との友達としての関連付けを破棄する。これにより、レンタルに関する商行為は完了する。

図１２は、返却期限が経過しても、ユーザ１０が物品を返却していない場合のユーザとサービス提供者との関係を説明するための模式図である。返却期限を経過しても物品が返却されない場合、サービス提供者システム１１０１は、ＳＮＳ管理部６０３によってユーザ１０の友達として関連付けられているユーザ２０とユーザ３０とに対し、ユーザ１０が物品を返却していないというメッセージを送信するようにＳＮＳ管理部６０３に指示する。メッセージの送信は、例えばＦａｃｅｂｏｏｋ（登録商標）におけるメッセージ機能を用いることが可能である。ＳＮＳが例えばＦａｃｅｂｏｏｋ（登録商標）である場合、メッセージは友達の友達に対して送信できるので、サービス提供者システム１１０１がユーザ１０とＳＮＳ上の友達になっていれば、サービス提供者システム１１０１はユーザ２０及びユーザ３０に対してメッセージを送信できる。

ユーザ１０にとって、リアルな友達に、物品を返却していないというメッセージが送られることは、大変な不名誉である。従って、サービス提供者システム１１０１が、ユーザ１０とＳＮＳ上の友達として関連付けられていることは、物品の持ち逃げに対する強力な抑止力となりうる。つまり、サービス提供者にとっては、交流度決定部９０１によって決定されたＳＮＳリアル交流度に基づいてＳＮＳ上にリアルな友達との交流が反映されていることを確認し、契約者の友達にメッセージを送信できる状況を設定することで、盗難のリスクを大きく低減することができる。したがって、レンタル業者は、盗難保険の保険料を低減できるので、レンタル料を安くすることができる。これは、レンタル業者と利用者との双方にとってのメリットとなる。

なお、本実施の形態３では、サービス提供者システム１１０１がユーザ１０のＳＮＳ上の友達となるとしたが、この構成は必須ではない。交流度決定部９０１によって決定されたＳＮＳリアル交流度により、ユーザ１０が健全な社会的な交流を営んでいる人物であり、物品を持ち逃げするような人物ではないと確認できるだけでも、物品の盗難に関するリスクを低減することができる。

なお、本実施の形態３では、サービス提供者は、物品を貸し出すサービスを提供するとしているが、本発明は他のサービスでも適用可能である。例えば、サービス提供者は、融資するサービスを提供してもよい。この場合、物品とはお金であり、物品の返却とは、利子を伴うお金の返却となる。

すでに、インターネット上には、融資の手続きに必要な書類をすべて電子的に送信するだけで、指定した銀行口座に入金される、融資システムが存在する。顧客は、運転免許証のような身分証明書の画像を送信することで、融資の審査を受ける。このような融資システムでは、顧客は、自宅でパーソナルコンピュータを操作するだけで簡便に融資を受けることができるが、身分証明書の画像を送信しなければならないという手間が必要になる。また、融資システムは、電子的に身分証明書を受け取るが、受け取った身分証明書を確認するのは人間であり、融資の審査に人手が必要であるという課題が存在している。

本実施の形態３におけるサービス提供システムは、上記のような融資システムに応用することができる。まず、あらかじめ、融資会社は、ＳＮＳを提供するサービスプロバイダと、ＳＮＳリアル交流度の提供を受けるための、契約を結んでおく。そして、ＳＮＳ管理部６０３は、ＳＮＳのＷｅｂサイト内に、融資の申請を受け付けるページを開設する。融資を受けたい顧客は、ＳＮＳにログインする。そして、ＳＮＳのＷｅｂサイト内に開設された融資ページに移動し、融資の申請を行う。

この時、ＳＮＳ管理部６０３は、融資会社のサービス提供者システム１１０１の融資受付のＡＰＩをコールする。ＳＮＳ管理部６０３は、顧客のＳＮＳ上のＩＤを引数としてコールする。サービス提供者システム１１０１は、ＳＮＳのサービスプロバイダが運営するサーバ６０５に用意されたＳＮＳリアル交流度を取得するためのＡＰＩを、顧客のＳＮＳ上のＩＤを引数としてコールすることで、ＳＮＳリアル交流度を取得する。

サービス提供者システム１１０１は、取得したＳＮＳリアル交流度が十分高いか否か、すなわち、取得したＳＮＳリアル交流度が所定値以上であるか否かを判断する。ＳＮＳリアル交流度が十分に高いと判断された場合、融資の審査に合格したとして、サービス提供者システム１１０１は、指定された顧客の銀行口座に入金する。

なお、ＳＮＳリアル交流度が低いと判断された場合、すなわち、ＳＮＳリアル交流度が所定値より小さいと判断された場合、サービス提供者システム１１０１は、ユーザ１０の端末６１１に対し、融資ができないことを通知してもよい。このように、サービス提供者システム１１０１は、交流度決定部９０１によって決定されたＳＮＳリアル交流度に応じて融資契約において契約者に融資するか否かを決定する。

このように、ＳＮＳリアル交流度を利用することで、顧客にとっては、身分証明書などを送信することなく、自分の信用を証明することができるという効果を得ることができる。また、融資会社にとっては、ＳＮＳリアル交流度という数値データのみで融資の審査を行うので、融資の審査のための人手を大幅に減らすことができるという効果を得ることができる。

上記の実施の形態３によれば、交流度決定部９０１により、リアルな交流がＳＮＳに反映されていることが確認され、さらにサービス提供者が利用者のＳＮＳ上の友達として関連付けられることで、サービス提供者の商行為のリスクを大幅に低減することができ、且つ、利用者が支払う対価も低減することができる。

（実施の形態４）
従来、レンタル業者は、サービスを提供する前に、利用者に対して運転免許証の提示を求めるが、本実施の形態４におけるサービス提供システムによれば、より簡便にサービスを提供することができる。

図１３は、実施の形態４において、記事表示部６０８によって表示される表示画面の一例を示す図である。表示画面１３０１には、ユーザ１０が送信した記事７０４が表示されるとともに、活動量取得部６０１によって取得されたユーザ１０の活動量が記事７０３として表示される。ここで、アイコン１３０２は、ユーザ１０の顔画像を表している。アイコン１３０２は、交流度決定部９０１によって決定されたユーザ１０のＳＮＳリアル交流度１３０５を含む。ＳＮＳリアル交流度１３０５は、数値で表され、ユーザ１０のアイコン１３０２内の左上部分に表示されている。

図１４は、実施の形態４において、記事表示部６０８によって表示される表示画面内のアイコンの他の例を示す図である。図１４におけるアイコン１３０３は、ユーザ１０のＳＮＳリアル交流度が所定の閾値以上である場合、ＳＮＳリアル交流度が所定の閾値を超えていることを示すマーク１３０６を含む。場合にアイコンに付与される図形で表したものである。なお、ユーザ１０のＳＮＳリアル交流度が所定の閾値より小さい場合、マーク１３０６は表示されない。

図１５は、実施の形態４において、記事表示部６０８によって表示される表示画面内のアイコンの他の例を示す図である。図１５において、ユーザ１０のＳＮＳリアル交流度が所定の閾値以上である場合、アイコン１３０４の外周部分には、ＳＮＳリアル交流度が所定の閾値を超えていることを示す飾りが付与される。

ユーザ１０は、サービス提供者にサービスの提供を依頼する際、スマートフォン等の端末に表示される自らのＳＮＳのアカウント画面を提示する。サービス提供者は、提示されたアカウント画面に表示されるＳＮＳリアル交流度に応じて、サービスの提供条件を調整する。

実施の形態２で示した通り、ＳＮＳリアル交流度の値は、ユーザ１０がＳＮＳ側に対して運転免許証などを提示し、アカウント名が本名であることが確認された場合に、高くなる。つまり、サービス提供者は、利用者のＳＮＳのアカウント画面で、ＳＮＳリアル交流度が所定の閾値以上であることを確認すれば、運転免許証を確認したことになり、運転免許証の提示を求める必要がなくなる。利用者にとっては、運転免許証を提示しなくてもサービスが受けられるという格別の効果を奏する。

サービス提供者は、ユーザ１０のＳＮＳのアカウント画面におけるＳＮＳリアル交流度を確認する。サービス提供者は、ユーザ１０のＳＮＳリアル交流度が所定の閾値以上であると判断すると、サービス提供者システム１１０１に対し、サービス提供者とユーザ１０とが友達関係になるための指示を入力する。サービス提供者システム１１０１は、サービス提供者からの入力を受け付け、ユーザ１０のアカウントに対して友達として関連付けることを承認するための友達承認依頼を送信するようにＳＮＳ管理部６０３に指示する。ユーザ１０は、友達承認依頼を承認する。ＳＮＳ管理部６０３は、ユーザ１０とサービス提供者とを友達として関連付ける。これにより、下記の２つの効果が発生する。

第１の効果としては、サービス提供者が、サービス提供者システム１１０１とユーザ１０とが確かにＳＮＳ上の友達関係になったことを、サービス提供者システム１１０１を通じて確認することで、ユーザ１０が提示したユーザ１０のＳＮＳのアカウント画面が、ＳＮＳとは無関係の偽造された画像ではないことを確認できる。

第２の効果としては、ユーザ１０とサービス提供者システム１１０１とが友達関係になったことで、サービス提供者は、ユーザ１０に対する問い合わせを、ＳＮＳ上のユーザ１０のアカウントに対して行うことができる。さらには、サービス提供者は、ユーザ１０と連絡が取れなくなったときに、ユーザ１０の友達として関連付けられている他のユーザに対して問い合わせを行うことができる。このことは、サービスを提供する前にユーザ１０に対して住所又は連絡先の記入を求めるのと同様の効果、又はそれ以上の効果を生む。そもそも、サービス提供者が、サービスを提供する前に利用者に住所又は連絡先を求めるのは、レンタルした物品の返却が滞ったときの対策のためであり、とくに利用者に確実に連絡するためである。サービス提供者とユーザ１０とがＳＮＳ上で友達として関連付けられることで、サービス提供者はＳＮＳを用いてユーザ１０に連絡することが可能となり、さらに、ユーザ１０の友達として関連付けられている他のユーザにも連絡することが可能となるので、単に住所又は連絡先を知る以上の対策が期待できる。このため、サービス提供者は、利用者に対して住所又は連絡先の記入を求める必要はなくなる。つまり、ユーザ１０は、ＳＮＳのアカウント画面をサービス提供者に見せ、サービス提供者からの友達承認依頼に対して承認するだけで、サービスの提供を受けることができる。

上記したように、本実施の形態では、ＳＮＳリアル交流度が、ＳＮＳのアカウント画面のアイコン上に表示される。このため、利用者は、サービスの提供の申し出をする際、ＳＮＳのアカウント画面をサービス提供者に提示し、サービス提供者からの友達承認依頼を承認すればよい。これにより、従来行っていた、運転免許証の提示が不要になるとともに、住所又は連絡先の記入が不要になるという、格別の効果を奏することができる。

上記の実施の形態において説明された技術は、例えば、以下のクラウドサービスの類型において実現されうる。しかし、上記の実施の形態において説明された技術が実現されるクラウドサービスの類型はこれに限られるものではない。

（サービスの類型１：自社データセンタ型クラウドサービス）
図１６は、サービスの類型１（自社データセンタ型クラウドサービス）における情報提供システムが提供するサービスの全体像を示す図である。本類型は、サービスプロバイダ１２０がグループ１００から情報を取得し、ユーザに対してサービスを提供する。本類型では、サービスプロバイダ１２０が、データセンタ運営会社の機能を有している。すなわち、サービスプロバイダ１２０が、ビッグデータを管理するクラウドサーバ２０３を保有している。したがって、データセンタ運営会社は存在しない。

本類型では、サービスプロバイダ１２０は、データセンタ（クラウドサーバ）２０３を運営及び管理している。また、サービスプロバイダ１２０は、オペレーティングシステム（ＯＳ）２０２及びアプリケーション２０１を管理する。サービスプロバイダ１２０は、サービスプロバイダ１２０が管理するＯＳ２０２及びアプリケーション２０１を用いてサービスを提供する（矢印２０４）。

（サービスの類型２：ＩａａＳ利用型クラウドサービス）
図１７は、サービスの類型２（ＩａａＳ利用型クラウドサービス）における情報提供システムが提供するサービスの全体像を示す図である。ここで、ＩａａＳとは、インフラストラクチャー・アズ・ア・サービスの略であり、コンピュータシステムを構築及び稼動させるための基盤そのものを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。

本類型では、データセンタ運営会社１１０が、データセンタ（クラウドサーバ）２０３を運営及び管理している。また、サービスプロバイダ１２０は、ＯＳ２０２及びアプリケーション２０１を管理する。サービスプロバイダ１２０は、サービスプロバイダ１２０が管理するＯＳ２０２及びアプリケーション２０１を用いてサービスを提供する（矢印２０４）。

（サービスの類型３：ＰａａＳ利用型クラウドサービス）
図１８は、サービスの類型３（ＰａａＳ利用型クラウドサービス）における情報提供システムが提供するサービスの全体像を示す図である。ここで、ＰａａＳとは、プラットフォーム・アズ・ア・サービスの略であり、ソフトウェアを構築及び稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。

本類型では、データセンタ運営会社１１０は、ＯＳ２０２を管理し、データセンタ（クラウドサーバ）２０３を運営及び管理している。また、サービスプロバイダ１２０は、アプリケーション２０１を管理する。サービスプロバイダ１２０は、データセンタ運営会社１１０が管理するＯＳ２０２及びサービスプロバイダ１２０が管理するアプリケーション２０１を用いてサービスを提供する（矢印２０４）。

（サービスの類型４：ＳａａＳ利用型クラウドサービス）
図１９は、サービスの類型４（ＳａａＳ利用型クラウドサービス）における情報提供システムが提供するサービスの全体像を示す図である。ここで、ＳａａＳとは、ソフトウェア・アズ・ア・サービスの略である。ＳａａＳ利用型クラウドサービスは、例えば、データセンタ（クラウドサーバ）を保有しているプラットフォーム提供者が提供するアプリケーションを、データセンタ（クラウドサーバ）を保有していない会社又は個人などの利用者がインターネットなどのネットワーク経由で使用できる機能を有するクラウドサービス提供モデルである。

本類型では、データセンタ運営会社１１０は、アプリケーション２０１を管理し、ＯＳ２０２を管理し、データセンタ（クラウドサーバ）２０３を運営及び管理している。また、サービスプロバイダ１２０は、データセンタ運営会社１１０が管理するＯＳ２０２及びアプリケーション２０１を用いてサービスを提供する（矢印２０４）。

以上、いずれのクラウドサービスの類型においても、サービスプロバイダ１２０がサービスを提供する。また、例えば、サービスプロバイダ又はデータセンタ運営会社は、ＯＳ、アプリケーション又はビックデータのデータベース等を自ら開発してもよいし、また、第三者に外注させてもよい。

本発明に係るサービス提供方法は、契約内容の決定時におけるリスクをより低減することができ、所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者に対し所定のサービスを提供するサービス提供方法に有用である。

Claims (17)

1. 所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者によってネットワークを介して記事を送信する送信ステップと、
   前記送信ステップにおいて送信された前記記事を前記契約者以外の閲覧者に対して表示する表示ステップと、
   前記契約者と前記閲覧者とがどの程度の交流関係であるかを示す交流度を決定する交流度決定ステップと、
   前記交流度決定ステップにおいて決定された前記交流度に応じて前記契約の内容を決定する契約決定ステップとを含む、
   サービス提供方法。
2. 前記交流度決定ステップは、前記契約者によって送信された前記記事とともに、前記契約者の本名が前記閲覧者に閲覧可能に表示される場合、前記交流度を高くする、
   請求項１記載のサービス提供方法。
3. 前記交流度決定ステップは、前記契約者によって送信された前記記事とともに、前記契約者の住所が前記閲覧者に閲覧可能に表示される場合、前記交流度を高くする、
   請求項１又は２記載のサービス提供方法。
4. 前記交流度決定ステップは、前記契約者によって送信された前記記事とともに、前記契約者の顔画像が前記閲覧者に閲覧可能に表示される場合、前記交流度を高くする、
   請求項１〜３のいずれかに記載のサービス提供方法。
5. 前記契約者の公的身分証明書の画像を取得する画像取得ステップをさらに含み、
   前記交流度決定ステップは、前記画像取得ステップにおいて取得された前記契約者の公的身分証明書の画像と、前記契約者によって登録された前記契約者の本名、住所又は顔画像とが一致する場合、前記本名、前記住所又は前記顔画像が本物であると判断し、前記交流度を高くする、
   請求項２〜４のいずれかに記載のサービス提供方法。
6. 前記契約者と、前記契約者と友達関係にある閲覧者とを関連付けて記憶する記憶ステップをさらに含み、
   前記交流度決定ステップは、前記契約者の本名が前記閲覧者によって検索された回数、又は前記契約者の本名を検索した前記閲覧者と前記契約者とが友達関係であるとして関連付けられた数が多い場合、前記交流度を高くする、
   請求項１〜５のいずれかに記載のサービス提供方法。
7. 前記契約者と、前記契約者と友達関係にある閲覧者とを関連付けて記憶する記憶ステップをさらに含み、
   前記交流度決定ステップは、前記記憶ステップにおいて前記契約者と友達関係にあるとして関連付けられている前記閲覧者の交流度の高さに応じて、前記契約者の前記交流度を決定する、
   請求項１〜５のいずれかに記載のサービス提供方法。
8. 前記交流度決定ステップは、前記契約者の顔画像と同一の顔であると判断できる顔画像を含む画像が前記閲覧者から送信された数が多い場合、前記交流度を高くする、
   請求項１〜７のいずれかに記載のサービス提供方法。
9. 前記契約は、医療保険契約又は生命保険契約を含み、
   前記契約者の活動量を示す活動量情報を取得する活動量取得ステップをさらに含み、
   前記表示ステップは、前記送信ステップにおいて送信された前記記事と、前記活動量取得ステップにおいて取得された前記活動量情報とを前記閲覧者に対して表示し、
   前記契約決定ステップは、前記活動量取得ステップにおいて取得された前記活動量情報と、前記交流度決定ステップにおいて決定された前記交流度とに応じて前記医療保険契約又は前記生命保険契約における保険料を決定する、
   請求項１〜８のいずれかに記載のサービス提供方法。
10. 前記活動量情報は、前記契約者の移動量を含む、
    請求項９記載のサービス提供方法。
11. 前記移動量は、前記契約者の歩数を含む、
    請求項１０記載のサービス提供方法。
12. 前記活動量取得ステップは、前記契約者が所有する歩数計により前記契約者の歩数を取得する、
    請求項１１記載のサービス提供方法。
13. 前記活動量情報は、前記契約者の身体情報を含む、
    請求項９記載のサービス提供方法。
14. 前記身体情報は、前記契約者の脈拍、血圧、血糖値及び尿酸値のいずれかを含む、
    請求項１３記載のサービス提供方法。
15. 前記契約は、物品をレンタルするレンタル契約を含み、
    前記契約決定ステップは、前記交流度決定ステップにおいて決定された前記交流度に応じて前記レンタル契約において前記契約者に物品をレンタルするか否かを決定する、
    請求項１〜８のいずれかに記載のサービス提供方法。
16. 前記契約は、融資契約を含み、
    前記契約決定ステップは、前記交流度決定ステップにおいて決定された前記交流度に応じて前記融資契約において前記契約者に融資するか否かを決定する、
    請求項１〜８のいずれかに記載のサービス提供方法。
17. 所定のサービスを提供するサービス提供者と所定の契約を結んだ契約者によってネットワークを介して記事を送信する送信ステップと、
    前記契約者の活動量を示す活動量情報を取得する活動量取得ステップと、
    前記送信ステップにおいて送信された前記記事と、前記活動量取得ステップにおいて取得された前記活動量情報とを、前記契約者によって閲覧が許可された閲覧者に対して表示する表示ステップと、
    前記活動量取得ステップにおいて取得された前記活動量情報に応じて前記契約の内容を決定する契約決定ステップとを含む、
    サービス提供方法。

Images