JP2016201066A - 情報処理装置 - Google Patents

Abstract

【課題】ユーザの死を契機として所定のサービスを提供する主体が、ユーザの死亡時に確実にサービスを提供できるよう支援する。
【解決手段】サービス支援装置２０２は、保険会社装置２０８が管理する契約者のＩＤを取得する。サービス支援装置２０２は、取得したＩＤを契約者と対応付けて記憶する。サービス支援装置２０２は、契約者の死亡を検出した場合に、契約者のＩＤを保険会社装置２０８へ通知することにより、保険会社が契約者の死亡を把握することを支援する。
【選択図】図２０

Description

本発明は、データ処理技術に関し、特に情報処理装置に関する。

本出願人は、人の死に関連するサービスの提供を支援する技術を提案している（例えば特許文献１参照）。この技術は、ユーザが死亡したことを検知して、ユーザが予め指定したエンディングサービスの実行を支援するものである。

特開２０１３−１０１５４９号公報

保険会社による保険金不払いは重大な社会問題になった。保険金不払いが生じる１つの要因は、保険契約の存在を知らない遺族等の保険金受取人が保険金を請求しないことである。保険契約上、これは保険契約者側・受取人側の問題であるが、結果として本来支払われるべき保険金が未払いになるため、保険会社の社会的信用が損なわれる可能性がある。

本発明者は、ユーザが死亡したことを検知する上記の提案技術を保険のシステムに適用することで、保険会社の保険金不払いリスクを低減できると考えた。本発明の１つの目的は、ユーザの死を契機とする所定のサービスを提供する主体が、ユーザの死亡時に確実にサービスを提供できるよう支援するシステムの実現にある。

上記課題を解決するために、本発明のある態様の情報処理装置は、ユーザの死を契機として所定のサービスを提供するサービス主体と、それとは別の主体であって情報処理を担当する管理主体との間の連携をとる、管理主体が有する装置であり、サービス主体が用いるユーザのＩＤを取得するＩＤ取得部と、取得されたＩＤをユーザと対応付けて記憶するユーザ情報記憶部と、ユーザが死亡した場合にその事実を検出する検出部と、ユーザの死亡が検出された場合に、そのユーザのＩＤをサービス主体へ通知するサービス支援部と、を備える。

なお、以上に示した各構成要素の任意の組み合わせ、本発明を方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体等により表現したものもまた、本発明の態様として有効である。

本発明によれば、ユーザの死を契機とする所定のサービスを提供する主体が、ユーザの死亡時に確実にサービスを提供できるよう支援する仕組みを実現できる。

エンディングサービスシステムの構成を示す図である。 図１のサービス支援装置の機能構成を示すブロック図である。 図２のサービスマスタに格納されるデータの構成を示す図である。 図２の契約者情報保持部に格納されるデータの構成を示す図である。 図２の対象者情報保持部に格納されるデータの構成を示す図である。 図２の協力者情報保持部に格納されるデータの構成を示す図である。 図２の文書フォームマスタに格納されるデータの構成を示す図である。 図２のメッセージ保持部に格納されるデータの構成を示す図である。 図２の葬儀プランマスタに格納されるデータの構成を示す図である。 図２の葬儀情報保持部に格納されるデータの構成を示す図である。 関係者登録ページの一例を示す図である。 図２の遺言支援部の詳細な機能構成を示すブロック図である。 メッセージ作成ページの一例を示す図である。 メッセージ作成ページの一例を示す図である。 メッセージ作成ページの一例を示す図である。 メッセージ作成ページの一例を示す図である。 図２の葬儀支援部の詳細な機能構成を示すブロック図である。 サービス支援装置の動作を示すフローチャートである。 サービス支援装置の動作を示すフローチャートである。 サービス支援装置の動作を示すフローチャートである。 サービス支援装置の動作を示すフローチャートである。 サービス支援装置の動作を示すフローチャートである。 実施の形態の保険サービスシステムの構成を示す図である。 図２０のサービス支援装置の構成を示すブロック図である。 図２０の契約者端末、協力者端末の構成を示すブロック図である。 関係者画面を示す図である。 図２０の保険サービスシステムの動作を模式的に示す図である。

はじめに、本出願人が既に特許第５７０４５２０号を得ているサービス支援装置の技術を「前提技術」として説明する。この前提技術は、人の死に関連するサービスの提供を支援する技術であり、本願発明との組み合わせに好適である。図２０以降、本願発明の実施の形態について説明する。

［前提技術の背景］
２０１１年の３月、東日本大震災という未曾有の大災害があった。２万人に近い人命が一瞬の惨劇に奪われた。高齢者を除き、われわれの大半はふだん死を意識せずに生活をしている。そうした意識を根底から覆す出来事である。

突然訪れる死にどう対処するか。自身の問題だけでなく、残された家族や関係者のことも考えなければならない。震災の脅威を目の当たりにし、働き盛りの健康な人ほどこのことを考えたのではないだろうか。

もちろん、生命保険という仕組みはある。しかしこれはあくまでも金銭による補償であり、残された者の心の傷を癒すものではない。震災の遺族が荒廃した被災地の自宅跡に戻って最初に探すものは、亡くなった家族の映った写真と聞く。思い出は金銭で代えられるものではない。

人はよく、「死に際に会えなかった」と悔やむ。最期の言葉を聞けたかどうかは、残される者にとって大きな問題である。最期の言葉は、逝く人の生を、その言葉が授けられる相手との関係で集約するものであり、それがあって、そのふたりの関係を穏やかに閉じることができる。その完結性によって、残される者は、いずれはなだらかに和らいでいく悲しみの中に踏みとどまれるのである。

遺言という仕組みもある（電子的なものについては、特許文献１を参照）。しかし、一般に遺言は、財産分与等、法律的な意味をもつことが多く、臨終の場で聴き取っておきたい心の言葉にはなりにくい。

［前提技術が解決しようとする課題］
本発明者は、誰にも訪れうる突然の死に際し、むしろ健康な人こそが日頃から万全の準備をしておく仕組みづくりの必要性を痛感した。また、残される者が最大限癒されるための仕組みも必要である。本発明の目的は、生命保険や遺言よりもさらに一歩踏み込み、万全性と心のケアを、ＩＴ技術をもとに実現するシステムの提供にある。

［前提技術が課題を解決するための手段］
上記課題を解決するために、本発明のある態様のサービス支援装置は、契約者が死亡したとき、契約内容にしたがって、契約者が予め登録した対象者に対するサービスの提供を支援する装置であって、契約者に対して生存確認のためのメッセージを通知し、生存している旨の返信を契約者から受信する契約者確認部と、契約者からの返信がない場合、契約者が予め登録した協力者に対して契約者の生死を問い合わせるよう指示する警告部と、契約者の死亡が確認された場合、サービスの提供を指示する指示部と、対象者および協力者を登録する登録部と、を備える。登録部は、協力者を対象者の中から登録可能に構成された。

契約者確認部は、契約者による指定にもとづき生存確認を行う間隔を決定し、その間隔にしたがって生存確認のためのメッセージを定期的に通知してもよい。

契約者が選択可能なサービスについて、契約者の死亡後にサービスを提供すべき時期を示す情報の保持部をさらに備えてもよい。契約者確認部は、契約者により選択されたサービスについて、そのサービスを提供すべき時期に応じたタイミングで、生存確認のためのメッセージを通知してもよい。

契約者確認部は、契約者により複数種類のサービスが選択された場合、契約者の死亡から、複数種類のサービスのそれぞれが提供されるまでの期間のうち、最も短い期間に応じたタイミングで、生存確認のためのメッセージを通知してもよい。

登録部において登録された協力者に対して、サービスが提供される対象者、かつ、契約者の生存確認に協力すべき協力者として登録された旨を通知する協力者通知部をさらに備えてもよい。

対象者に対してサービスが提供される対象者であることを示すメッセージを通知し、そのメッセージに対する返信を対象者から受信する対象者確認部と、対象者からの返信がない場合、契約者に対して対象者を更新するよう促すためのメッセージを通知する契約者通知部と、をさらに備えてもよい。

複数の葬儀プランを契約者へ提示し、契約者が死亡した場合の葬儀プランを契約者に選択させる葬儀プラン提示部と、契約者により選択された葬儀プランを示す情報を契約者の葬儀の関係者へ通知する葬儀プラン通知部と、をさらに備えてもよい。

本発明の別の態様もまた、サービス支援装置である。この装置は、契約者が死亡したとき、契約内容にしたがって、所定の対象者に対するサービスの提供を支援する装置であって、対象者宛に契約者が作成したメッセージを契約者から受け付けるメッセージ受付部と、メッセージを暗号化した暗号化データを対象者へ提供するメッセージ提供部と、契約者の死亡が確認された場合、暗号化データを復号するためのキーを対象者へ提供することにより、対象者が暗号化データを復号したメッセージを閲覧可能とする復号キー提供部と、暗号化データを復号したメッセージに改ざんがないことを確認できるよう、契約者が作成したメッセージを一方向性関数に入力した結果のデータを対象者へ提供する確認データ提供部と、を備える。

契約者の遺言の形式を特定するための複数種類の情報項目の保持部と、対象者宛のメッセージを作成するための画面であって、複数種類の情報項目を契約者へ提示して選択させ、その選択結果に応じた形式の遺言作成画面を契約者へ提示するメッセージ作成支援部と、をさらに備えてもよい。

［前提技術の実施の形態］
本実施の形態では、人の死にまつわる各種サービス（以下、総称して「エンディングサービス」とも呼ぶ。）をユーザに提供するサービス支援装置を提案する。このサービス支援装置がサービスを提供する主な対象者は、自分自身でコンピュータ端末を使用できる健康な人、言い換えると、健康な状態で死とは縁遠いと考える人である。サービス支援装置は、ユーザが健康なうちから、ユーザ自身の死にまつわるイベントを予めデザインさせ、ユーザの死後、そのデザインにしたがってイベントが実現されることを支援する。実施の形態のサービス支援装置は、主に以下の２つの技術要素を備える。

技術要素１：ユーザが死亡したことを精度よく検出して、ユーザにより予め指定されていたエンディングサービスの実行を支援する。
技術要素２：ユーザが死亡した場合に、ユーザが予め関係者に残したメッセージを関係者が確認することを可能にし、また、メッセージの内容に改ざんがないことを関係者が確認することを可能にする。メッセージは、テキスト、音声、画像、動画、およびそれらを適宜組み合わせたデジタルデータであってよく、ユーザが関係者に伝えたい事柄を表現するものである。

図１は、エンディングサービスシステムの構成を示す。エンディングサービスシステム１００は、サービス支援装置１０と、契約者端末１２と、対象者端末１４で総称される対象者端末１４ａ、対象者端末１４ｂ、対象者端末１４ｃと、葬儀社端末１６で総称される葬儀社端末１６ａ、葬儀社端末１６ｂを備える。これらの各装置は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網１８を介して接続される。

サービス支援装置１０は、上記２つの技術要素を備え、エンディングサービスの提供業者（以下、「サービス事業者」とも呼ぶ。）が有する情報処理装置である。サービス支援装置１０は、ウェブサーバとしての機能を有し、エンディングサービスに関するウェブページを契約者端末１２、対象者端末１４および葬儀社端末１６へ提供して表示させる。

契約者端末１２、対象者端末１４、および葬儀社端末１６は、ウェブクライアントとして機能する情報処理端末であり、据え置き型であってもよく携帯型であってもよい。前者の例として、デスクトップＰＣであってもよく、後者の例として、ウェブブラウザが搭載された携帯電話機、スマートフォン、タブレット端末等であってもよい。

契約者端末１２は、自分自身が死亡した場合にエンディングサービスを実行することをサービス事業者と契約したユーザ（以下、「契約者」と呼ぶ。）により操作される情報処理装置である。対象者端末１４は、エンディングサービスの提供先として契約者により指定されたユーザ（以下、「対象者」と呼ぶ。）により操作される情報処理装置である。葬儀社端末１６は、サービス事業者と提携した葬儀業者が有する情報処理装置である。

図２は、図１のサービス支援装置１０の機能構成を示すブロック図である。サービス支援装置１０は、各種データを保持する記憶領域であるデータ保持部２０と、各種データ処理・通信処理を実行する制御部４０とを備える。なおウェブサーバとしての機能は公知であるため、以下の説明を省略する。

本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図２のデータ保持部２０は、サービス支援装置１０のストレージやメインメモリにより実現されてもよい。また制御部４０は、コンピュータプログラムとして記録媒体に格納され、サービス支援装置１０のストレージへインストールされてもよい。そして、当該プログラムが起動されると、制御部４０の各機能ブロックに対応するプログラムモジュールがサービス支援装置１０のメインメモリへ読み出されてＣＰＵにより実行されることにより、制御部４０の各機能が実現されてもよい。

データ保持部２０は、サービスマスタ２２と、契約者情報保持部２４と、対象者情報保持部２６と、協力者情報保持部２８と、文書フォームマスタ３０と、メッセージ保持部３２と、葬儀プランマスタ３４と、葬儀情報保持部３６を備える。

図３は、サービスマスタ２２に格納されるデータの構成を示す。サービスマスタ２２は、複数種類のエンディングサービスのそれぞれの定義情報を「サービスマスタ情報」として保持する。サービスマスタ情報では、サービスＩＤ・サービス名・サービス詳細・サービス実施時期・価格が対応づけられる。このうちサービス実施時期は、契約者が死亡してからエンディングサービスを実施するまでの期間を示す。実施の形態では、契約者が死亡してからサービス実施時期が示す日数が経過したことを条件として、エンディングサービスが対象者へ提供される。なお、契約者が死亡したことの起算日は、後述の協力者によりサービス支援装置１０へ通知された契約者の死亡日付であることとする。

図４は、契約者情報保持部２４に格納されるデータの構成を示す。契約者情報保持部２４は、複数の契約者のそれぞれに関する情報を「契約者情報」として保持する。契約者情報では、契約者ＩＤ・契約者名・契約者連絡先・サービスＩＤ・確認日付・死亡日付が対応づけられる。このうち契約者連絡先として、少なくとも契約者端末１２のメールアドレスが設定される。またサービスＩＤとして、サービス支援装置１０が契約者に提示した複数種類のエンディングサービスの中から、契約者が選択したエンディングサービスのＩＤが設定される。言い換えれば、契約者が自分自身の死後に対象者へ提供するよう契約したエンディングサービスのＩＤが設定される。また確認日付として、サービス支援装置１０において契約者の生存が確認された最新の日付が設定される。また死亡日付として、サービス支援装置１０において確認された契約者の死亡日付、具体的には、後述の協力者によりサービス支援装置１０へ通知された契約者の死亡日付が設定される。

図４の契約者ＩＤ・契約者名・契約者連絡先は、サービス業者において契約者が登録された時点であり、特定のエンディングサービスは未選択の時点で設定されてもよい。例えば、契約者が記述したサービス業者との契約締結書の内容にもとづいて、サービス事業者による手動もしくはサービス支援装置１０による自動で設定されてもよい。また、サービス支援装置１０は、契約者をオンライン登録（サインアップ）を受け付ける契約者登録部をさらに備えてもよい。契約者登録部は、契約者情報の入力ページをユーザの端末（すなわち契約者端末１２）へ提供し、そのページにおいて登録ボタンが選択された場合、契約者情報を契約者情報保持部２４へ格納することにより、ユーザを契約者として登録してもよい。

図５は、対象者情報保持部２６に格納されるデータの構成を示す。対象者情報保持部２６は、複数の対象者のそれぞれに関する情報を「対象者情報」として保持する。対象者情報では、対象者ＩＤ・対象者名・対象者連絡先・契約者ＩＤ・サービスＩＤ・確認日付が対応づけられる。このうち対象者連絡先として、少なくとも対象者端末１４のメールアドレスが設定される。また契約者ＩＤとして、対象者を指定した契約者のＩＤが設定される。またサービスＩＤとして、契約者により設定され、対象者へ提供されるエンディングサービスのＩＤが設定される。また確認日付として、サービス支援装置１０において対象者の存在が確認された最新の日付が設定される。

図６は、協力者情報保持部２８に格納されるデータの構成を示す。協力者情報保持部２８は、契約者の生存確認に協力するユーザとして１以上の対象者の中から契約者が予め指定した特定の対象者（以下、「協力者」とも呼ぶ。）に関する情報を「協力者情報」として保持する。後述するように、協力者は対象者のうち契約者の生存確認に協力するユーザである。協力者情報では、協力者ＩＤ・契約者ＩＤ・協力者連絡先が対応づけられる。このうち契約者ＩＤとして、協力者を指定した契約者のＩＤが設定される。また協力者連絡先として、少なくとも協力者の対象者端末１４のメールアドレスが設定される。

図７は、文書フォームマスタ３０に格納されるデータの構成を示す。文書フォームマスタ３０は、契約者から対象者への典型的なメッセージのテンプレートを保持する。実施の形態では、契約者が作成しようとする遺言の形式を特定するための複数種類の選択項目と、遺言のテンプレートとしての複数種類の文書フォームを保持する。また文書フォームマスタ３０は、複数種類の選択項目と複数種類の文書フォームを、複数階層にグループ分けして保持する。例えば、大分類「財産相続用遺言」は、中分類「標準形式」と「相続分を指定する形式」を含む。また中分類「標準形式」は、遺言のテンプレートしての「不動産相続用フォーム」と「預貯金相続用フォーム」と「株式相続用フォーム」を含む。その一方、中分類「相続分を指定する形式」は、遺言のテンプレートしての「自己指定用フォーム」と「第三者委託用フォーム」を含む。

図８は、メッセージ保持部３２に格納されるデータの構成を示す。メッセージ保持部３２は、契約者から対象者へ伝達されるべきメッセージに関する情報を「メッセージ情報」として保持する。メッセージ情報では、メッセージＩＤ・契約者ＩＤ・対象者ＩＤ・暗号化メッセージ・復号キー・ハッシュ値が対応づけられる。このうち契約者ＩＤとして、メッセージを作成した契約者のＩＤが設定され、また対象者ＩＤとして、メッセージの宛先となる対象者のＩＤが設定される。また暗号化メッセージとして、契約者の平文のメッセージを暗号化したデータが設定され、復号キーとして、暗号化メッセージを復号するためのキー情報が設定される。またハッシュ値として、契約者の平文のメッセージから生成されたハッシュ値が設定される。なおセキュリティ向上のため、サービス支援装置１０は、契約者から受け付けたメッセージを平文の状態では永続的に保持しない。

図９は、葬儀プランマスタ３４に格納されるデータの構成を示す。葬儀プランマスタ３４は、複数の葬儀業者のそれぞれが提案する葬儀プラン、言い換えれば、契約者が選択可能な葬儀プランの定義情報を保持する。この定義情報では、葬儀プランＩＤ・葬儀社情報・プラン詳細が対応づけられる。このうち葬儀社情報として、少なくとも葬儀社の連絡先、例えば葬儀社端末１６のメールアドレスが設定される。プラン詳細は、葬儀プランの詳細な内容を示す情報であり、例えば葬儀規模・斎場情報・会食内容・返礼品内容・葬儀の価格（総額および内訳）等を含む。

図１０は、葬儀情報保持部３６に格納されるデータの構成を示す。葬儀情報保持部３６は、契約者がデザインした自分自身の葬儀に関する情報を「葬儀情報」として保持する。葬儀情報では、契約者ＩＤ・葬儀プランＩＤ・喪主情報・葬儀詳細が対応づけられる。このうち喪主情報として、喪主の連絡先、例えば喪主の対象者端末１４のメールアドレスが設定される。また葬儀詳細として、希望する参列者の情報・宗教の指定・希望する戒名の情報・希望する演出の情報・希望する墓地やお墓の情報等を含む。

図２に戻り、制御部４０は、サービス実行部４２と、関係者登録部４８と、契約者確認部５０と、警告部５２と、協力者確認部５４と、サービス指示部５６と、対象者確認部５８と、契約者通知部６０と、サービス選択支援部６２を備える。

以下では特に言及しないが、契約者端末１２がサービス支援装置１０へアクセスする際にサービス支援装置１０は契約者端末１２に対してログインを要求し、契約者ＩＤの入力を要求するものとする。これにより、サービス支援装置１０は、アクセス元の契約者端末１２の契約者ＩＤを把握するものとする。また以下では説明の簡明化のため、１人の契約者に対する処理を説明するが、実際には複数の契約者それぞれに対する処理を順次もしくは並行して実行する。

サービス実行部４２は、複数種類のエンディングサービスに関する処理、例えば契約者により予め指定された対象者に対して、その契約者により予め指定されたエンディングサービスを提供するための処理を実行する。サービス実行部４２は、遺言支援サービスの処理を実行する遺言支援部４４と、葬儀支援サービスの処理を実行する葬儀支援部４６を含む。遺言支援部４４および葬儀支援部４６の詳細は後述する。

なおサービス実行部４２は、各エンディングサービスの一連のプロセスのうち一部を契約者の生存中に実行してもよい。そして、残りのプロセス、言い換えれば、契約者の死後に実行すべきプロセスを、後述のサービス指示部５６の指示を契機に実行する。

サービス選択支援部６２は、契約者端末１２に対して、サービス実行部４２により実行される複数種類のエンディングサービスを提示するウェブページ（以下、「サービス選択ページ」とも呼ぶ。）のデータを提供する。サービス選択ページは、複数種類のエンディングサービスの中から、１つ以上のエンディングサービスを契約者に選択させるためのウェブページであるとも言える。具体的には、サービス選択支援部６２は、エンディングサービスの一覧として、サービスマスタ２２に保持されたサービスマスタ情報が設定されたサービス選択ページを契約者端末１２へ送信して表示させる。

またサービス選択支援部６２は、サービス選択ページにおいて契約者により選択されたエンディングサービスを示す情報を契約者端末１２から取得して、そのサービスＩＤを契約者情報保持部２４における当該契約者のレコードへ格納する。契約者により選択されたエンディングサービスは、契約者とサービス事業者間において、契約者の死後に提供されることが契約されたサービスであるとも言える。

例えば、遺族年金等の各種の公的サービス・生命保険等の私的サービスの中には契約者の死亡後、所定期間内に手続きを行うべきものもある。それらのサービスを受けるための手続きを行うよう指示する旨のメッセージを対象者へ伝達することを希望する契約者は、上記の所定期間以内の値がサービス実施時期として設定された遺言支援サービスを選択する必要がある。

関係者登録部４８は、契約者が対象者および協力者を登録するためのウェブページ（以下、「関係者登録ページ」）のデータを契約者端末１２へ送信して表示させる。図１１は、関係者登録ページの一例を示す。関係者登録ページ１０２は、対象者名フィールド１０４と、連絡先フィールド１０６と、サービス種類フィールド１０８と、協力者チェックボックス１１０と、登録ボタン１１２を含む。対象者名フィールド１０４は対象者名の入力フィールドであり、連絡先フィールド１０６は対象者端末１４のメールアドレスを含む対象者の連絡先の入力フィールドである。

サービス種類フィールド１０８は対象者へ提供すべきエンディングサービスの種類を指定する入力フィールドである。サービス種類フィールド１０８は、契約者が契約済みのエンディングサービスの中から特定のサービスを選択可能なドロップダウンリストであってもよい。協力者チェックボックス１１０は、特定の対象者を協力者として指定するためのチェックボックスである。本実施の形態では、協力者としてエンディングサービスに関わらない第三者を指定することはできず、対象者の中から協力者を選択する必要がある。例えば、対象者として妻・子・父・母・友人・会社の同僚・顧問弁護士が指定された場合、協力者として妻・子・友人を指定することができる。

契約者端末１２は、関係者登録ページ１０２において登録ボタン１１２が選択されると、関係者登録ページ１０２に入力された対象者情報をサービス支援装置１０へ送信する。関係者登録部４８は、関係者登録ページ１０２に入力された対象者情報を契約者端末１２から受け付けると、ユニークな対象者ＩＤを採番するとともに、契約者情報保持部２４を参照して契約者により指定されたエンディングサービスのＩＤを特定する。そして、契約者端末１２の契約者ＩＤと対応づけて、対象者情報を対象者情報保持部２６へ格納する。また関係者登録部４８は、協力者チェックボックス１１０がチェックされた対象者についてはユニークな協力者ＩＤをさらに採番し、その対象者の情報を協力者情報として協力者情報保持部２８にも格納する。

図２に戻り、協力者確認部５４は、協力者情報保持部２８において協力者情報の追加もしくは更新があった場合、その事実を検出する。この場合、協力者確認部５４は、協力者情報が追加もしくは更新された協力者の対象者端末１４に対して、エンディングサービスが提供される対象者として指定され、かつ、契約者の生存確認に協力すべき協力者として指定された旨の電子メールを送信する。すなわち、契約者により協力者として選定されたユーザに対し、その旨を通知して契約者の生存確認に対する協力を促す。

契約者確認部５０は、契約者の生存を確認するための電子メール（以下、「生存確認メール」とも呼ぶ。）を定期的に契約者端末１２へ送信する。生存確認メールには、例えば、契約者が存命である場合にサービス支援装置１０への返信を求める内容が記載される。契約者確認部５０は、契約者が生存している旨の返信、具体的には生存確認メールに対する返信の電子メールを契約者端末１２から受け付けると、契約者情報保持部２４の契約者情報における確認日付を現在日付へ更新する。現在日付は、典型的にはサービス支援装置１０が管理する現在日時の日付であり、いわゆるシステム日付である。

契約者確認部５０は、生存確認メールにより契約者の生存確認に成功してから所定の待機期間の経過を検出すると、契約者の生存確認を再度実行する。例えば、契約者情報保持部２４の契約者情報における確認日付から所定日数が経過したことを検出すると、新たな生存確認メールを契約者端末１２へ送信して、契約者端末１２からの返信を再度受け付けて契約者情報保持部２４における確認日付を再度更新する。この待機期間は、１人の契約者に対して生存確認を繰り返すべき周期であると言え、先の生存確認から次の生存確認までの間隔であるとも言える。

待機期間は以下のように決定される。すなわち、契約者確認部５０は、契約者情報保持部２４を参照して契約者が契約済みの１以上のエンディングサービスを特定し、サービスマスタ２２を参照して契約済みの各エンディングサービスで規定されたサービス実施時期を特定する。そして、契約済みの各エンディングサービスで規定されたサービス実施時期のうち最も短いサービス実施時期（以下、「基準時期」とも呼ぶ。）に応じて待機期間を決定する。具体的には、基準時期の日数が長いほど待機期間を長く設定し、基準時期の日数が短いほど待機期間を短く設定する。例えば、基準時期が示す日数から２〜３日を減じた日数を待機日数としてもよい。契約者が図３の遺言支援サービスＢおよび相続支援サービスＢを契約済みの場合、基準時期を遺言支援サービスＢで規定された１４日と特定して、待機日数を１２日と決定してもよい。

警告部５２は、契約者確認部５０により生存確認メールが契約者端末１２へ送信された後、所定期間のうちに生存確認メールへの返信を契約者端末１２から受け付けられたか否かを判定する。この所定期間は、数時間から数日等、予め定められた返信猶予期間であってもよい。また警告部５２は、契約者情報保持部２４に保持された確認日付に対して基準時期を加えた日付が、現在日付と等しくなった場合に、生存確認メールへの返信が期限内に受け付けられなかったと判定してもよい。この場合、基準時期と待機期間の差分が返信猶予期間となる。警告部５２は、生存確認メールの送信後の所定期間において、契約者端末１２からの返信を未受信であると判定した場合、契約者ＩＤを指定して協力者への確認処理の実行を協力者確認部５４へ指示する。

協力者確認部５４は、協力者情報保持部２８を参照し、警告部５２の指示で指定された契約者ＩＤと対応づけられた協力者情報を特定する。協力者確認部５４は、契約者の生存を確認するための生存確認メールを対象者端末１４へ送信する。この生存確認メールでは、契約者が存命である場合にはその旨の連絡を依頼し、契約者が死亡している場合には契約者の死亡日の連絡を依頼する内容が記載される。

協力者確認部５４は、協力者の対象者端末１４からの返信内容が契約者の生存を示すものであった場合、契約者情報保持部２４の契約者情報における確認日付を現在日付へ更新する。その一方、協力者の対象者端末１４からの返信内容が契約者の死亡を示すものであった場合、すなわち返信内容において契約者の死亡日付の記載が検出された場合、協力者確認部５４は、その死亡日付を契約者情報保持部２４の契約者情報へ記録する。

なお、契約者により複数の協力者が指定された場合、協力者確認部５４は複数の協力者それぞれの対象者端末１４へ生存確認メールを送信する。そして、協力者確認部５４は、複数の協力者それぞれの対象者端末１４から返信を受け付けて、それぞれの返信内容に応じて契約者の生死を判定する。複数の協力者が指定された場合の契約者の生死判定には様々なアルゴリズムが考えられる。例えば、協力者確認部５４は全ての協力者からの返信内容が一致した場合に、その返信内容にしたがって契約者の生死を確定的に判定してもよい。また、過半数の協力者からの返信内容が一致した場合に、契約者の生死を確定的に判定してもよい。また、各協力者からの返信内容が不整合である場合（例えば一方は契約者の生存を示し、他方は契約者の死亡を示す場合）、再度、複数の協力者それぞれの対象者端末１４へ生存確認メールを送信してもよい。

契約者の生死判定において、いずれのアルゴリズムを採用するかは、サービス支援装置１０が持つべき性格に応じて設計者により適宜決定されてよい。例えば、契約者の生死判定において正確性を重視すべき場合、全ての協力者からの返信内容が一致した場合に確定的に判定してもよい。また契約者の生死判定において迅速性を重視すべき場合、少なくとも１人の協力者からの返信内容が契約者の死亡を示すものであれば、契約者が死亡したものと判定してもよい。また正確性と迅速性とを両立すべき場合、過半数の協力者からの返信内容が一致した場合に、契約者の生死を確定的に判定してもよい。

サービス指示部５６は、契約者情報保持部２４の契約者情報に死亡日付が設定された場合、死亡日付が設定された契約者情報に記録されたサービスＩＤを特定し、契約者ＩＤおよびサービスＩＤを指定したサービス実行指示をサービス実行部４２へ通知する。具体的には、死亡が確認された契約者が契約していたエンディングサービス毎に、死亡日付にサービス実施時期を加算した日付に至ったか否かを判定する。例えば、契約済みのあるエンディングサービスについて、現在日付が、死亡日付に当該サービスのサービス実施時期を加算した日付と等しくなったと判定した場合、サービス実行部４２へ当該サービスの提供を指示する。

対象者確認部５８は、対象者と連絡が取れることを確認するための電子メール、言い換えれば対象者が生存し、また対象者情報が正しいことを確認するための電子メール（以下、「対象者確認メール」とも呼ぶ。）を定期的に対象者端末１４へ送信する。例えば、６ヶ月〜１年に一度、対象者確認メールを送信してもよい。対象者確認部５８は、対象者確認メールに対する返信であり、対象者確認メールを正常に受領した旨の返信を対象者端末１４から受け付けると、その受付日を対象者情報保持部２６の確認日付に設定する。

警告部５２は、対象者確認部５８により対象者確認メールが対象者端末１４へ送信された後、所定期間（例えば１週間等）のうちに対象者確認メールに対する返信を対象者端末１４から受け付けたか否かを判定する。所定期間内に受け付けなかった場合、警告部５２は、契約者ＩＤを指定して対象者情報を更新すべき旨を契約者通知部６０へ通知する。

契約者通知部６０は、警告部５２から対象者情報を更新すべき旨が通知されると、契約者情報保持部２４を参照して、警告部５２により指定された契約者ＩＤと対応づけられた契約者情報を特定する。契約者通知部６０は、契約者連絡先で特定される契約者端末１２に対して、対象者情報を更新すべき旨の電子メールを送信する。この電子メールを受け付けた契約者は、関係者登録画面において対象者および協力者の情報を更新する。

図１２は、図２の遺言支援部４４の詳細な機能構成を示すブロック図である。遺言支援部４４は、メッセージ作成支援部７０と、メッセージ受付部７２と、暗号化部７４と、ハッシュ生成部７６と、メッセージ提供部７８と、ハッシュ提供部８０と、復号キー提供部８２を含む。

メッセージ作成支援部７０は、遺言支援サービスを選択した契約者に対して、対話形式により対象者宛のメッセージの作成を支援するためのウェブページ（以下、「メッセージ作成ページ」とも呼ぶ。）を提供する。メッセージ作成支援部７０は、メッセージの種類を特定するための選択項目と、契約者が選択したメッセージの種類に応じた文書フォームとを文書フォームマスタ３０から順次取得する。そして、それらのデータを設定したメッセージ作成ページを契約者端末１２へ順次提供する。

図１３（ａ）〜図１３（ｄ）は、メッセージ作成ページの一例を示す。図１３（ａ）は、ステップ１として、メッセージの宛先、すなわち遺言支援サービスにおける対象者を指定するメッセージ作成ページ１２０を示している。対象者名フィールド１２２は、対象者を指定する入力フィールドであり、契約者により事前に登録された対象者の中から特定の対象者を選択可能なドロップダウンリストであってもよい。契約者により次へボタン１２４が選択されると、次のステップのメッセージ作成ページ１２０へ遷移する。

図１３（ｂ）は、ステップ２として、メッセージの種類を選択するメッセージ作成ページ１２０を示している。ラジオボタン１２６では、図７で示した文書フォームマスタ３０におけるメッセージの大分類が選択可能に表示される。契約者により次へボタン１２４が選択されると、次のステップのメッセージ作成ページ１２０へ遷移する一方、戻るボタン１２８が選択されると、一つ前のステップのメッセージ作成ページ１２０へ遷移する。

図１３（ｃ）は、ステップ３として、ステップ２よりも詳細なレベルでメッセージの種類を選択するメッセージ作成ページ１２０を示している。ラジオボタン１３０では、図７で示した文書フォームマスタ３０におけるメッセージの中分類（ここでは大分類「財産相続用遺言」に対応する中分類）が選択可能に表示される。なお、ラジオボタン１３０において「標準形式」が選択された状態で次へボタン１２４が選択されると、ステップ４のメッセージ作成ページとして、「不動産相続用フォーム」・「預貯金相続用フォーム」・「株式相続用フォーム」の選択画面が表示される。

図１３（ｄ）は、ステップ５として、不動産相続用フォームが表示されたメッセージ作成ページ１２０を示している。このメッセージ作成ページ１２０では、不動産が主たる財産の場合の標準的な遺言書のテンプレートを表示している。契約者は、各入力フィールド１３２への情報入力を行うことにより標準的な遺言書としてのメッセージを作成することができる。同図のメッセージ作成ページ１２０において不図示の登録ボタンが選択されると、契約者端末１２は、ステップ１で指定された対象者の情報と、不動産相続用フォームへの入力データとを、対象者へのメッセージとしてサービス支援装置１０へ送信する。

図１２に戻り、メッセージ受付部７２は、契約者端末１２から送信された対象者へのメッセージを受け付けて、ユニークなメッセージのＩＤを採番する。暗号化部７４は、メッセージ受付部７２において受け付けられた平文のメッセージを暗号化する。本実施の形態では共通鍵方式によりメッセージを暗号化し、暗号化部７４は、共通鍵として暗号化対象のメッセージ毎にユニークなデータを決定する。例えば、対象者ＩＤと日時情報との組み合わせにもとづいて共通鍵を決定してもよい。暗号化部７４は、メッセージのＩＤ・メッセージの作成者である契約者のＩＤ・メッセージの宛先である対象者のＩＤと対応づけて、メッセージの暗号化データおよびその復号キー（すなわち上記の共通鍵）をメッセージ保持部３２へ格納する。

ハッシュ生成部７６は、メッセージ受付部７２において受け付けられた平文のメッセージをＳＨＡ−１等の所定のハッシュ関数へ入力し、そのハッシュ値を取得する。ハッシュ生成部７６は、メッセージのハッシュ値を、暗号化部７４により作成されたメッセージ情報と対応づけてメッセージ保持部３２へ格納する。

メッセージ提供部７８は、メッセージ保持部３２に暗号化メッセージが新規に格納されたことを検出すると、遺言支援サービスの対象者へ暗号化メッセージを提供する。具体的には、メッセージ作成ページで指定された対象者のＩＤで特定される対象者端末１４に対して、その対象者宛のメッセージの暗号化データを添付した電子メールを送信する。ハッシュ提供部８０は、メッセージ保持部３２にハッシュ値が新規に格納されたことを検出すると、遺言支援サービスの対象者へハッシュ値の情報を提供する。具体的には、メッセージ作成ページで指定された対象者のＩＤで特定される対象者端末１４に対して、その対象者宛のメッセージのハッシュ値を示すデータを添付した電子メールを送信する。なお、暗号化メッセージとハッシュ値のデータは単一の電子メールで送信されてもよい。

復号キー提供部８２は、サービス支援装置１０において契約者の死亡が確認された場合、具体的には、サービス指示部５６により遺言支援サービスの提供を指示されたとき、その契約者のＩＤと対応づけられた対象者ＩＤと復号キーとをメッセージ保持部３２から取得する。復号キー提供部８２は、対象者ＩＤで特定される対象者端末１４に対して復号キーのデータを添付した電子メールを送信する。これにより、対象者端末１４において、先にメッセージ提供部７８により提供された暗号化メッセージを復号可能となり、対象者は契約者が遺したメッセージを確認することができる。

図１４は、図２の葬儀支援部４６の詳細な機能構成を示すブロック図である。葬儀支援部４６は、葬儀プラン登録部９０と、葬儀プラン提示部９２と、葬儀情報受付部９４と、葬儀情報通知部９６を含む。

葬儀プラン登録部９０は、葬儀プランの詳細な内容を含む葬儀プランの登録要求を葬儀社端末１６から受け付けて、ユニークな葬儀プランＩＤを採番する。そして、葬儀プランＩＤと、葬儀社端末１６により特定される葬儀社情報と、葬儀プランの詳細な内容を対応づけて葬儀プランマスタ３４へ格納する。

葬儀プラン提示部９２は、葬儀支援サービスを契約済みの契約者に対して、契約者自身で葬儀の内容を決定することを支援するためのウェブページ（以下、「葬儀支援ページ」とも呼ぶ）を提供する。具体的には、葬儀プランマスタ３４に登録済みの葬儀プランの情報を含む葬儀支援ページのデータを契約者端末１２へ送信して表示させる。この葬儀支援ページは、契約者が希望する葬儀プランの選択フィールドや、喪主の連絡先を含む喪主情報の入力フィールド、図１０の説明で既述した葬儀詳細の入力フィールドを含む。

葬儀情報受付部９４は、契約者により葬儀支援ページに入力された葬儀情報を契約者端末１２から取得して対象者情報保持部２６へ格納する。図１０の説明で既述したように、この葬儀情報には、契約者が選択した葬儀プラン、契約者が指定した喪主の情報、葬儀内容に関する希望の詳細（上記の葬儀詳細）が含まれる。

葬儀情報通知部９６は、新たな葬儀情報が葬儀情報保持部３６に格納されたことを検出すると、契約者が選択した葬儀プランを提案した葬儀社の葬儀社端末１６に対して契約者の情報を含む葬儀情報を通知する。また葬儀情報受付部９４は、契約者により指定された喪主の対象者端末１４に対しても契約者の情報を含む葬儀情報を通知する。なお葬儀情報受付部９４は、サービス支援装置１０において契約者の死亡が確認された場合、具体的には、サービス指示部５６により遺言支援サービスの提供を指示されたときもまた、葬儀社端末１６および喪主の対象者端末１４に対して葬儀情報を通知してもよい。

以上の構成によるサービス支援装置１０の動作を以下説明する。
図１５〜図１９は、サービス支援装置１０の動作を示すフローチャートである。図１５は、契約者によるエンディングサービスの契約、および、契約者による関係者の登録に関する動作を示している。自分自身の死について予め備えたいユーザ、具体的には、自身の死後に起こるイベントの内容を生前にデザインしたいユーザは、サービス業者に対して自分自身の情報（すなわち契約者情報）を登録する。これにより、このユーザは契約者として契約者端末１２を介してサービス支援装置１０へアクセスすることが許可される。

サービス選択支援部６２は、契約者が選択可能なサービスの情報提供要求を契約者端末１２から受け付けると（Ｓ１０のＹ）、サービスマスタ２２に格納されたサービスマスタ情報を含むサービス選択ページを契約者端末１２へ提供する（Ｓ１２）。サービス選択ページにおいて特定のエンディングサービスを契約する旨が指定された場合、（Ｓ１４のＹ）、サービス選択支援部６２は、指定されたエンディングサービスの情報を契約者情報へ格納する（Ｓ１６）。これにより、契約者の死後に対象者へ提供すべきエンディングサービスが設定される。サービス選択ページにおいて特定のエンディングサービスを契約する旨が未指定である場合（Ｓ１４のＮ）、Ｓ１６をスキップし、契約者が選択可能なサービスの情報提供要求を受け付けなければ（Ｓ１０のＮ）、Ｓ１２〜Ｓ１６をスキップする。

関係者登録部４８は、関係者登録ページの提供要求を契約者端末１２から受け付けると、図１１で示した関係者登録ページを契約者端末１２へ提供する。契約者は、関係者登録ページにおいて、契約済みのエンディングサービス毎に対象者の情報を入力し、さらに対象者の中から１人以上の協力者を指定する。関係者登録部４８は、関係者登録ページで指定された関係者の登録要求を契約者端末１２から受け付けると（Ｓ１８のＹ）、対象者情報保持部２６の対象者情報および協力者情報保持部２８の協力者情報を更新する（Ｓ２０）。協力者が登録された場合、協力者確認部５４は、協力者の対象者端末１４に対して、エンディングサービスの対象者であり、契約者の生存確認への協力者として指定された旨を通知する（Ｓ２２）。関係者の登録要求を受け付けなければ（Ｓ１８のＮ）、Ｓ２０およびＳ２２をスキップする。

図１６は、契約者の生存確認に関する動作を示している。同図の動作は、エンディングサービスを契約済みの契約者毎、言い換えれば、契約者情報保持部２４において１以上のサービスＩＤが設定済みの契約者情報のレコード毎に並行して実行される。契約者確認部５０は、契約者が契約済みのエンディングサービスで定められたサービス実施時期に応じて、生存確認における待機期間を決定する（Ｓ３０）。そして、過去に契約者の生存を確認した日付から待機期間が経過したことを検出すると（Ｓ３２のＹ）、契約者に関する生存確認メールを契約者端末１２へ送信する（Ｓ３４）。警告部５２は、生存確認メールに対する返信の電子メールが契約者端末１２から受け付けられたか否か、また返信内容が契約者が生存していることを示す所定の内容であるか否かに応じて、契約者が生存状態にあるか否かを判定する。警告部５２により契約者が生存状態にあると判定されない場合（Ｓ３６のＮ）、協力者確認部５４は、契約者に関する生存確認メールを協力者の対象者端末１４へ送信する（Ｓ３８）。

協力者確認部５４は、生存確認メールに対する協力者の対象者端末１４からの返信内容が契約者の生存を示すものか、もしくは契約者の死亡を示すものかを判定する。例えば、返信の中に契約者の死亡日付が記載されていた場合、契約者が死亡したと判定する。協力者確認部５４は、契約者が死亡したと判定すると（Ｓ４０のＮ）、契約者の死亡日付を契約者情報保持部２４の契約者情報へ記録する。サービス指示部５６は、契約者が契約済みのエンディングサービス毎にサービス実施時期で定まる日付に至るまで待機する（Ｓ４２のＮ）。そして、サービス実施時期で定まる日付に至ったことを検出すると（Ｓ４２のＹ）、エンディングサービスの実行をサービス実行部へ指示する（Ｓ４４）。協力者からの返信により契約者が生存していることが確認された場合（Ｓ４０のＹ）、Ｓ４２およびＳ４４をスキップする。また、契約者からの返信により契約者が生存していることが確認された場合（Ｓ３６のＹ）、Ｓ３８以降をスキップする。また、過去に契約者の生存を確認した日付から待機期間が未経過であれば（Ｓ３２のＮ）、Ｓ３４以降をスキップする。

図１５および図１６で示したように、実施の形態のサービス支援装置１０によれば、契約者の生存確認に協力すべき協力者を、エンディングサービスが提供される対象者の中から選択する必要がある。対象者は契約者とある程度のつながりを有し、契約者の状態を把握するユーザであることが多いと言える。したがって、協力者を対象者の中から設定することにより、契約者の生存確認の精度を高めることができる。

また、協力者は契約者の生存有無を正しく回答する必要があり、また契約者の生存確認に際して一定の責任を負う者であるため、協力者に何のメリットもなければ、協力者として指定されることを受諾しないことも考えられる。サービス支援装置１０では、サービスを享受する対象者の中から協力者を指定することにより、契約者の生存確認への協力を取り付けやすい、言い換えれば、協力者としての指定を受諾させるインセンティブを与えることができる。また契約者により協力者が指定されたとき、その旨を協力者として指定されたユーザへ通知することで、将来時点において契約者の生存確認に協力すべき旨を予め伝えておくことができる。

またサービス支援装置１０によれば、契約者の死後におけるサービスの実施時期に応じて、言い換えると、契約者の死亡からサービスが対象者へ提供されるまでの期間に応じて、契約者の生存確認を繰り返す周期（すなわち上記の待機期間）が決定される。具体的には、契約者の死亡日から、対象者へのサービス提供日までの期間が長いほど、長い周期を決定する。これにより、予め契約者へ提示したエンディングサービスの実施時期を遵守しつつ、契約者に対する過度の生存確認、言い換えると、契約者にとって負担になる頻度での生存確認を抑制しやすくなる。なお実施の形態では、契約者が複数のエンディングサービスを契約した場合、それらのサービスのうち最も短いサービス実施時期に応じて周期を決定することにより、予め契約者へ提示したエンディングサービスの実施時期を遵守する。

図１７は、対象者情報の正誤確認に関する動作を示している。同図の動作は、エンディングサービス提供の対象者毎、言い換えれば、対象者情報保持部２６における対象者情報のレコード毎に並行して実行される。対象者確認部５８は、過去に対象者情報の正誤を確認した日付から所定日数が経過したことを検出すると（Ｓ５０のＹ）、対象者確認メールを対象者端末１４へ送信する（Ｓ５２）。対象者からの返信がないこと、もしくは返信内容が対象者情報の誤りを示すことを警告部５２が検出すると（Ｓ５４のＮ）、契約者通知部６０は、対象者情報に誤りがある旨、また対象者情報の更新を促す旨の電子メールを対象者端末１４へ送信する（Ｓ５６）。対象者からの返信により対象者情報が正しいことが確認された場合（Ｓ５４のＹ）、Ｓ５６をスキップする。また、過去に対象者情報の正誤を確認した日付から所定日数が未経過であれば（Ｓ５０のＮ）、Ｓ５２以降をスキップする。

図１７で示したように、実施の形態のサービス支援装置１０によれば、対象者情報の正誤を定期的に確認する。エンディングサービスは、契約者による契約後、実際に対象者へ提供されるまで数年〜数１０年の間隔が生じうる息の長いサービスであり、対象者の状態も時間の経過とともに変化しうる。サービス支援装置１０によれば、対象者の連絡先の変更等、最新の状況を反映して対象者情報を適切に見直すよう契約者を支援できる。

図１８は、遺言支援サービスに関する動作を示している。遺言支援部４４のメッセージ作成支援部７０は、メッセージの作成要求を契約者端末１２から受け付けると（Ｓ６０のＹ）、メッセージの作成を支援するためのメッセージ作成ページを契約者端末１２へ提供する。契約者によりメッセージの種類が選択されると（Ｓ６４のＹ）、メッセージ作成支援部７０は、その選択結果に応じて結果に応じてメッセージ作成ページの表示内容を順次更新し、最終的にメッセージのテンプレートである文書フォームを表示させる（Ｓ６６）。メッセージ作成ページにおいてメッセージの種類が選択されなければ（Ｓ６４のＮ）、Ｓ６６をスキップし、メッセージの作成要求を受け付けなければ（Ｓ６０のＮ）、Ｓ６２〜Ｓ６６をスキップする。なお、契約者はメッセージの種類として図７の自由記述フォームを選択することもでき、その場合、一般的な遺言の形式に制限されない、対象者への思い（例えば臨終の場面での最期の言葉等）を自由に記述することができる。契約者のメッセージは、例えば「いつもありがとう、感謝しています」の一言でもよい。

契約者端末１２からアップロードされたメッセージをメッセージ受付部７２が受け付けると（Ｓ６８のＹ）、暗号化部７４はそのメッセージを暗号化し（Ｓ７０）、ハッシュ生成部７６はそのメッセージのハッシュ値を算出する（Ｓ７２）。そして、メッセージ提供部７８は暗号化メッセージを対象者端末１４へ提供し、ハッシュ提供部８０はハッシュ値のデータを対象者端末１４へ提供する（Ｓ７４）。契約者の死亡が確認されてサービス指示部５６によりサービス実行が指示されると（Ｓ７６のＹ）、復号キー提供部８２は、暗号化メッセージの復号キーを対象者端末１４へ提供する（Ｓ７８）。契約者端末１２からのメッセージのアップロードがなければ（Ｓ６８のＮ）、Ｓ７０〜Ｓ７４をスキップし、契約者の生存が確認されていれば（Ｓ７６のＮ）、Ｓ７８をスキップする。

図１８で示したように、実施の形態のサービス支援装置１０によれば、契約者が死亡したことを条件として、遺言支援サービスの対象者へ暗号化メッセージの復号キーを提供する。これにより、契約者の死亡後、契約者が遺したメッセージを対象者が確認することができる。またサービス支援装置１０は、契約者のオリジナルメッセージのハッシュデータを対象者端末１４へ提供する。対象者は、暗号化メッセージを復号後、復号したメッセージから生成したハッシュデータと、サービス支援装置１０から提供されたハッシュデータとを照合し、それらの同一性を確認することで、復号したメッセージが改ざんされたものでないことを確認できる。言い換えると、契約者のオリジナルメッセージと、対象者へ提供されたメッセージとの同一性を保証できる。

またサービス支援装置１０によれば、メッセージ作成ページにおいて対話形式により契約者が作成を希望する遺言の種類を特定し、その種類に合致する形式の文書フォーム、すなわち予め用意された標準的な遺言のテンプレートを契約者へ提示する。これにより、契約者による遺言状の作成を容易なものとし、また有効な遺言状となるために必要な情報が記載されるよう支援できる。

またサービス支援装置１０によれば、契約者のメッセージとして、一般的な遺言の形式に制限されない自由な形式のメッセージを対象者へ提供できる。一般的な遺言とは違った心の通ったメッセージを対象者へ伝えることで、対象者が契約者の臨終の場にいなくても最期の言葉を聞くに等しい状況を提供できる。これにより、契約者の死後、残る者の悲しみを和らげることができる。

またサービス支援装置１０によれば、死亡した者に関わる複数の関係者に広く公開される、もしくは遺族の範囲で公開される一般的な遺言と異なり、契約者のメッセージは、契約者が指定した宛先の対象者にのみ公開される。したがって、契約者は対象者毎に違うメッセージを残すことができ、また各対象者へのメッセージは、宛先以外の者には秘密とされる。一般的に契約者は特定の対象者に公開したいが、その他の人には秘匿したい秘密を持つものであり、その秘密を本装置へ委ねることができる。

また、人が突然亡くなった場合、例えば、その人のタンス預金（または「へそくり」）が誰にも気づかれずにそのまま埋もれてしまうこともある。サービス支援装置１０により予めその所在を記したメッセージを残せば、このような問題を防止することができる。すなわち、サービス支援装置１０が対象者へ伝達する契約者のメッセージは、対象者に対する契約者の思いを伝達するだけのものではなく、「何がどこにある」「何をどうしてほしい」といったメモの伝達機能も有する。

これに関連して、上記の実施の形態では、遺言のテンプレートを契約者へ提供することを例示したが、サービス支援装置１０の文書フォームマスタ３０は、タンス預金やタンス株券の所在等、典型的に契約者がその生存中においては他人から秘匿する情報項目であり、その死後に対象者へ伝達すべき項目でありながら、その伝達が忘れられやすいと想定される各種項目（以下、「備忘項目」とも呼ぶ。）のリストをさらに保持してもよい。そしてメッセージ作成支援部７０は、備忘項目についてメッセージを作成することを促す文章をメッセージ作成ページへ表示させてもよい。また文書フォームマスタ３０は、備忘項目を対象者へ伝達するための文書フォーマット（例えばタンス預金伝達用テンプレート、タンス株券伝達用テンプレート等）を保持してもよく、メッセージ作成支援部７０は備忘項目の中から契約者の選択項目に応じた文書フォーマットをメッセージ作成ページにおいて表示させてもよい。

また図１８では不図示であるが、メッセージ提供部７８は、対象者端末１４から暗号化メッセージの再送要求を受け付けて、メッセージ保持部３２に保持された暗号化メッセージを対象者端末１４へ再送してもよい。同様に、メッセージ提供部７８は、対象者端末１４から暗号化メッセージの再送要求を受け付けて、メッセージ保持部３２に保持された暗号化メッセージを対象者端末１４へ再送してもよい。本サービスは典型的にメッセージの登録からその公開までの間隔が長期に亘るサービスであり、対象者が暗号化メッセージやハッシュデータを紛失してしまうことも想定される。サービス支援装置１０のメッセージ保持部３２は、暗号化メッセージおよびハッシュデータのバックアップを保持し、このような対象者を救済できる。

図１９は、葬儀支援サービスに関する動作を示している。葬儀支援部４６の葬儀プラン登録部９０は、葬儀プランの登録要求を葬儀社端末１６から受け付けると（Ｓ８０のＹ）、その葬儀プランの情報を葬儀プランマスタ３４へ格納する（Ｓ８２）。葬儀プラン提示部９２は、葬儀支援サービスの提供要求を契約者端末１２から受け付けると（Ｓ８４のＹ）、各葬儀プランを紹介するとともに契約者自身の葬儀の希望を葬儀情報として入力させるための葬儀支援ページを契約者端末１２へ提供する（Ｓ８６）。葬儀プランの登録要求を受け付けなければ（Ｓ８０のＮ）、Ｓ８２をスキップし、葬儀支援サービスの提供要求を受け付けなければ（Ｓ８４のＮ）、Ｓ８６をスキップする。

葬儀情報受付部９４は、契約者端末１２からアップロードされた葬儀情報を受け付けると（Ｓ８８のＹ）、その葬儀情報を葬儀情報保持部３６に記録する（Ｓ９０）。それとともに葬儀情報通知部９６は、葬儀社端末１６および喪主の対象者端末１４へ葬儀情報を通知する（Ｓ９２）。契約者の死亡が確認されてサービス指示部５６によりサービス実行が指示されると（Ｓ９４のＹ）、葬儀情報通知部９６は契約者が死亡した旨や、契約者の葬儀を実施すべき旨を葬儀社端末１６および喪主の対象者端末１４へ通知する（Ｓ９６）。契約者端末１２からの葬儀情報のアップロードがなければ（Ｓ８８のＮ）、Ｓ９０およびＳ９２をスキップし、契約者の生存が確認されていれば（Ｓ９４のＮ）、Ｓ９６をスキップする。

図１９で示したように、実施の形態のサービス支援装置１０によれば、葬儀支援ページを契約者へ提供して、契約者自身が希望する葬儀内容を入力させる。そして、その葬儀内容を葬儀社および喪主へ通知する。これにより、契約者が自身の葬儀をデザインすることを支援し、また契約者が希望する態様で葬儀が執り行われることを支援できる。

なお、本前提技術について次のような変形技術も考えられる。
第１の変形例を説明する。上記実施の形態では、契約者確認部５０は、契約者が契約したエンディングサービスのサービス実施時期に応じて、契約者の生存確認の周期である待機期間を決定することとした。したがって、契約者はエンディングサービスを選択することにより、待機期間を間接的に指定していた。変形例として、待機期間の値は契約者により直接指定されてもよい。具体的には、サービス支援装置１０は、契約者が指定した待機期間の情報を契約者端末１２から受け付けて、契約者情報保持部２４の契約者情報へ記録する確認周期取得部をさらに備えてもよい。契約者確認部５０は、確認周期取得部により取得された待機期間を、契約者の生存確認処理における待機期間として使用する。この変形例によれば、契約者の生存確認周期を契約者自身が希望する期間に設定できる。なお、契約者が契約したエンディングサービスのサービス実施時期と、契約者が指定した待機期間とが不整合の場合（例えばサービス実施時期より待機期間が長い等）、確認周期取得部は、エンディングサービスの提供がサービス実施時期で規定する時期より遅れる可能性がある旨の警告を対象者端末１４へ通知し、待機期間の修正を契約者へ促してもよい。

第２の変形例を説明する。上記実施の形態では、対象者確認部５８は、契約者により指定された対象者のそれぞれに対象者確認メールを送信することとした。変形例では、関係者登録ページにおいて、対象者情報の正誤を定期的に確認すべき対象者（以下、「第１群対象者」とも呼ぶ。）と、対象者情報の正誤を確認しない対象者（以下、「第２群対象者」とも呼ぶ。）とを契約者が指定可能であってもよい。関係者登録部４８は、対象者情報に対して第１群対象者と第２群対象者のいずれであるかを識別するための情報を付加してもよい。対象者確認部５８は、第１群対象者に対しては対象者確認メールを定期的に送信する一方、第２群対象者に対しては対象者確認メールを送信しない。この変形例によると、将来サービスが提供される旨を通知しない方がよいと契約者が判断する対象者に対しては対象者確認メールの送信を抑制できる。なお、第２群対象者は第１群対象者と比較して、契約者との関係が密でない（もしくは契約者の状態を正確に把握しにくい）と考えられるため、協力者は第１群対象者の中から指定するよう制限されてもよい。例えば、関係者登録ページにおいて、協力者のチェックボックスが、第１群対象者にのみ設定可能な態様で表示されてもよい。

第３の変形例を説明する。上記実施の形態における遺言支援サービスでは、契約者から対象者へのメッセージが受け付けられたときに、暗号化メッセージおよびハッシュデータを対象者端末１４へ提供しておくこととした。しかし、暗号化メッセージおよびハッシュデータの提供タイミングはこれに制限されない。少なくとも復号キーが対象者端末１４へ提供される時点で、暗号化メッセージおよびハッシュデータもまた対象者端末１４へ提供されればよい。例えば、契約者の死亡が確認されて、遺言支援サービスのサービス実施時期に至った場合に、復号キーとともに、暗号化メッセージおよびハッシュデータが対象者端末１４へ提供されてもよい。

第４の変形例を説明する。この変形例では、契約者が対象者宛に作成したメッセージの暗号化およびハッシュデータの取得は契約者端末１２において実行される。この変形例における遺言支援部４４は、メッセージ作成支援部７０と、復号キー取得部と復号キー提供部８２を備える。メッセージ作成支援部７０は、メッセージ作成ページとともに、平文のメッセージを暗号化するアプリケーションおよび平文のメッセージのハッシュデータを出力するアプリケーションを契約者端末１２へ提供する。そして契約者端末１２において、契約者が対象者宛に作成したメッセージの暗号化、復号キーの設定、ハッシュデータの取得が実行される。また契約者端末１２は、復号キーを対象者端末１４へアップロードする一方、暗号化メッセージとハッシュデータを対象者端末１４へ直接送信する。

復号キー取得部は、復号キーを対象者端末１４から取得する。契約者の死亡が確認されて遺言支援サービスのサービス実施時期に至った場合、復号キー提供部８２は復号キーを対象者端末１４へ送信する。この変形例によると、サービス支援装置１０において対象者のオリジナルメッセージを取り扱わないため、サービス支援装置１０においてオリジナルメッセージが改ざんされる可能性を排除することができる。また契約者の死亡後に復号キーを提供することで、契約者の死亡後に契約者が遺したメッセージを対象者に確認させることができる。

第５の変形例を説明する。上記実施の形態では、警告部５２は、生存確認メールに対する返信を契約者端末１２から受け付けない場合、協力者への確認を行うよう協力者確認部５４へ指示することとした。変形例では、警告部５２は、生存確認メールに対する返信を契約者端末１２から受け付けない場合に、サービス支援装置１０の運用者（例えばサービス事業者の担当者）へ協力者への確認を行うべき旨のメッセージを通知してもよい。また、上記実施の形態では、サービス指示部５６は、契約者の死亡が確認された場合に、エンディングサービスの提供をサービス実行部４２へ指示することとした。変形例では、サービス支援装置１０の運用者へエンディングサービスの提供業務を実施するべき旨のメッセージを通知してもよい。これらのメッセージを受け付けた運用者は、サービス支援装置１０を操作して協力者への確認処理やエンディングサービスの提供処理を実行させてもよい。

第６の変形例を説明する。この変形例のサービス支援装置１０は、対象者の誕生日等、対象者の人生のイベントにあわせて契約者のメッセージを提供する。具体的には、遺言支援部４４は、遺言に限られない汎用的なメッセージの配送処理部として機能する。メッセージ作成支援部７０は、メッセージ作成ページ内に、メッセージの配送日付を契約者が指定するための入力フィールドをさらに設ける。メッセージ保持部３２はメッセージ情報として配送日付をさらに保持し、メッセージ受付部７２はメッセージ作成ページで指定された配送日付をメッセージ保持部３２へ格納する。サービス指示部５６は、メッセージ保持部３２に格納された各メッセージについて、その配送日付と現在日付が等しくなったか否かを判定し、配送日付が現在日付と等しくなったメッセージを検出すると、そのメッセージの提供を遺言支援部４４へ指示する。

本変形例におけるメッセージの提供態様としては、実施の形態と同様に、配送日付より前に予め暗号化メッセージを対象者端末１４へ提供しておき、サービス指示部５６の指示に応じて復号キーを対象者端末１４へ提供してもよい。また、サービス指示部５６の指示に応じて暗号化メッセージと復号キーの両方を一度に対象者端末１４へ提供してもよい。さらにまた、サービス指示部５６の指示に応じて、暗号化メッセージを復号した平文のメッセージを対象者端末１４へ提供してもよい。ハッシュデータの提供タイミングについても配送日付より前に予め対象者端末１４へ提供してもよく、サービス指示部５６の指示に応じて対象者端末１４へ提供してもよい。この変形例によれば、契約者が対象者宛に作成したメッセージを、契約者が希望する任意のタイミングで対象者へ提供できる。

第７の変形例を説明する。この変形例のサービス支援装置１０は、契約者に対してメッセージの更新を効果的に促す機能を提供する。具体的には、メッセージ保持部３２は、メッセージの更新日付をさらに保持する。警告部５２は、メッセージ保持部３２に保持された各メッセージの更新日付を参照して、所定期間（例えば１年間）更新されていないメッセージ（以下、「未更新メッセージ」とも呼ぶ。）を検出すると、未更新メッセージの更新を契約者に促すよう契約者通知部６０へ指示する。契約者通知部６０は、未更新メッセージの更新を促すための電子メールを契約者端末１２へ送信する。この電子メールには、例えば、対象者（メッセージの宛先）・未更新メッセージの内容・更新日付（未更新メッセージが登録された日付）を含む文章が記載されてもよい。契約者が対象者へ残したいメッセージは時間の経過とともに変化することが想定されるが、この変形例によると、契約者の最新の思いを対象者へ提供しやすくなる。

なお、１人の契約者について複数の未更新メッセージが検出された場合、契約者通知部６０は、更新作業が集中することを避け、作業を分散させることで契約者の負担を低減するよう設計されたアルゴリズムにしたがって更新を促すことが望ましい。例えば、１つの未更新メッセージの更新を促すための電子メールを送信後、所定期間（例えば１週間）が経過するまで待機した上で、別の未更新メッセージの更新を促すための電子メールを送信してもよい。また例えば、警告部５２は、１人の契約者について複数の未更新メッセージが検出した場合、そのうち１つの未更新メッセージの更新を促すよう契約者通知部６０へ指示してもよい。これにより、メッセージの更新のために契約者に大きな負担（高いストレス）をかけてしまうことを回避でき、また、メッセージの陳腐化を防止することができる。

第８の変形例を説明する。この変形例のサービス支援装置１０は、対象者のメッセージの閲覧環境に応じてメッセージの送信態様を変える機能を提供する。具体的には、メッセージ提供部７８は、対象者からの通知（例えばウェブページもしくは電子メールを介した通知）に応じて暗号化メッセージを復号する変換部をさらに備える。この通知は、対象者端末１４におけるメッセージの閲覧環境を示すものであり、例えば復号機能の有無を示す情報であってもよく、端末の機種の識別情報であってもよく、平文でのメッセージの提供または音声でのメッセージの提供を指定する情報であってもよい。変換部は、対象者からの通知の内容にしたがって、その対象者宛の暗号化メッセージを復号し、もしくは復号後のメッセージの内容を音声データへ変換する。メッセージ提供部７８は、変換部により暗号化メッセージが変換された場合は変換後のデータ（平文のメッセージや音声データ）を対象者端末１４へ送信し、変換部により暗号化メッセージが未変換であれば暗号化メッセージを対象者端末１４へ送信する。この変形例によると、契約者からのメッセージを、確実に対象者へ伝えることができる。

第９の変形例を説明する。この変形例のサービス支援装置１０は、契約者の生存確認を抑制する機能を提供する。具体的には、契約者情報保持部２４は、契約者に対する生存確認を抑制する期間として生存確認抑止期間をさらに保持する。契約者確認部５０は、契約者が旅行や入院等のために生存確認メールに対して応答できない期間（例えば１０月１日〜１０月２０日等）を示す情報を契約者端末１２から事前に受け付けて、その期間を生存確認抑止期間として契約者情報保持部２４へ格納する。契約者確認部５０は、ある契約者について、過去に生存を確認した日付から待機期間が経過したことを検出した場合でも、現在日付が生存確認抑止期間内であれば、その契約者に対する生存確認メールの送信を抑制する。この変形例によると、契約者が旅行や入院等の理由により生存確認メールに応答できないことが予めわかっている場合に、生存確認の実施を抑制できる。これにより、協力者に対して本来不要な死亡確認のメールが送信されてしまい、不要な労力や混乱が生じることを回避できる。

第１０の変形例を説明する。この変形例では、協力者を契約者に指定させることに代えて、協力者をシステムが自動で選択する。ここで契約者が協力者として選ぶ人は、通常、家族や親友など契約者と親密な関係にある。親密な関係にあるか否かは、メッセージの更新頻度やメッセージの内容から推定することができる。そこで、メッセージ保持部３２は、メッセージの更新頻度、例えば更新回数や更新間隔を示す情報をさらに保持する。制御部４０は、特定の契約者が複数の対象者に対して設定した複数のメッセージの更新頻度、および／または、各メッセージの内容にもとづいて、複数の対象者の中から協力者を選択して協力者情報保持部２８を設定する協力者選択部をさらに備える。

協力者選択部は、１人の契約者について、その契約者が登録しているメッセージの平均的な更新頻度より高頻度で更新されているメッセージの対象者を協力者として選択してもよい。例えば、平均的な更新回数より多くの回数更新されているメッセージの対象者を協力者として選択してもよく、平均的な更新間隔より短い間隔で更新されているメッセージの対象者を協力者として選択してもよい。また協力者選択部は、他のメッセージよりも重要度が高いと想定されるメッセージの対象者を協力者として選択してもよい。例えば、複数のメッセージの中から、財産相続用遺言のカテゴリの文書フォームを用いて作成されたメッセージを検出し、そのメッセージの対象者を協力者として選択してもよい。

第１１の変形例を説明する。上記実施の形態では、契約者が登録したメッセージを一律に暗号化することとしたが、この変形例のサービス支援装置１０は、メッセージの内容に応じてメッセージのセキュリティレベルを自立的に変更する。具体的には、文書フォームマスタ３０に保持される複数の文書フォームのそれぞれに、重要度高もしくは重要度低のいずれかが予め対応づけられる。例えば、財産相続用遺言カテゴリの各文書フォームには重要度高が対応づけられる一方、それ以外の文書フォームには重要度低が対応づけられてもよい。

暗号化部７４は、重要度高の文書フォームを用いて作成されたメッセージは実施の形態と同様に暗号化する一方、重要度低の文書フォームを用いて作成されたメッセージは平文のままメッセージ保持部３２へ格納してもよい。メッセージ提供部７８は、暗号化メッセージがメッセージ保持部３２へ格納された場合は、実施の形態と同様にその暗号化メッセージを直ちに対象者端末１４へ提供する。その一方、平文のメッセージがメッセージ保持部３２へ格納された場合は、契約者の死亡が検出された時点で、言い換えれば、サービス指示部５６から契約者の死亡が通知されたときに平文のメッセージを対象者端末１４へ提供する。この変形例によると、重要度低のメッセージは平文のまま対象者端末１４へ提供されるため、対象者端末１４での復号処理が不要となり、対象者は手軽にメッセージの内容を確認できる。

別の例として、暗号化部７４は、キーワード検索によりメッセージの重要度を判定してもよい。例えば、重要度が高いメッセージに含まれると想定される所定のキーワード（「口座番号」「現金」「相続」等）や、正規表現などの文字列パターンを予め保持しておき、それらのキーワードが含まれるメッセージを重要度高のメッセージと判定し、それらのキーワードが含まれないメッセージを重要度低のメッセージと判定してもよい。なお上記の変形例において、メッセージ作成時に契約者により選択された文書フォームの識別情報が、メッセージの登録時に契約者端末１２からサービス支援装置１０へ通知されてもよく、この通知にもとづきサービス支援装置１０はメッセージの重要度を判定してもよい。

第１２の変形例を説明する。上記実施の形態のサービス支援装置１０は、対象者が暗号化メッセージおよびハッシュデータを紛失した場合に再送可能なように、バックアップとして暗号化メッセージおよびハッシュデータを永続的に保持することとした。変形例では、メッセージ保持部３２は、対象者に対して暗号化メッセージおよびハッシュデータを一旦提供した後は、これらのデータを保持することなく、復号キーのみを保持してもよい。例えば、メッセージ提供部７８は暗号化メッセージを対象者端末１４へ提供後、メッセージ保持部３２の暗号化メッセージを削除してもよい。同様に、ハッシュ提供部８０はハッシュデータを対象者端末１４へ提供後、メッセージ保持部３２のハッシュデータを削除してもよい。この変形例によれば、暗号化メッセージやハッシュデータの第三者への漏洩を一層確実に防止できる。

［本発明の実施の形態］
実施の形態のサービス支援装置は、上記前提技術を適宜適用し、ユーザの死を契機として所定のサービスを提供するサービス主体と、それとは別の主体であって情報処理を担当する管理主体との間の連携を実現する。サービス主体は、典型的にはユーザ・顧客との取決め（例えば契約）を紙ベースで管理する企業や団体であり、実施の形態では保険会社とする。管理主体は、典型的には電子的な情報処理技術によりユーザ・顧客との取決めを管理する企業や団体であり、実施の形態では前提技術に記載のエンディングサービスを提供するエンディングサービス事業者である。

実施の形態のサービス支援装置は、管理主体が有する情報処理装置であり、サービス主体と管理主体とを連携させることで、双方の得意分野を活かしたビジネスモデルを実現する。具体的には、実施の形態のサービス支援装置は、電子的な情報処理技術によりユーザの死を検知し、検知したユーザの死を連携先の保険会社のシステムへ通知する。これにより、本来支払うべき保険金が不払いになることで生じる保険会社のリスクを低減し、保険契約の円滑な履行を支援する。なおサービス支援装置は、物理的にはクラウド上のサーバを使用し、そのサーバ上に管理主体が図２や後述の図２１で示す各機能をデプロイすることで実現されてもよい。

図２０は、実施の形態の保険サービスシステムの構成を示す。保険サービスシステム２００は、サービス支援装置２０２、契約者端末２０４、協力者端末２０６、保険会社装置２０８ａ、保険会社装置２０８ｂ、保険会社装置２０８ｃを備える。これらの装置は、ＬＡＮ・ＷＡＮ・インターネットを含む通信網を介して接続される。サービス支援装置２０２、契約者端末２０４、協力者端末２０６のそれぞれは、前提技術に記載のサービス支援装置１０、契約者端末１２、対象者端末１４に対応する。

契約者端末２０４は、保険会社と生命保険を契約したユーザである契約者により操作される情報端末である。契約者は、エンディングサービス事業者が提供するアプリケーションを契約者端末２０４へインストールしたユーザでもあり、エンディングサービス事業者にとっての顧客でもある。すなわち前提技術に記載の契約者に対応する。

協力者端末２０６は、契約者の死亡時に、契約者が予め作成したメッセージを受領するユーザであり、かつ、契約者が死亡した事実をサービス支援装置２０２へ通知する役目を負うユーザ、すなわち前提技術に記載の協力者により操作される情報端末である。契約者端末２０４と協力者端末２０６は、例えばスマートフォンやタブレット端末である。

保険会社装置２０８ａ、保険会社装置２０８ｂ、保険会社装置２０８ｃのそれぞれは、Ａ保険会社、Ｂ保険会社、Ｃ保険会社の情報処理装置である。これらを総称する場合、「保険会社装置２０８」と呼ぶ。各保険会社は、例えば生命保険を取扱い、保険契約者の死亡時に、予め定められた受取人に対して死亡保険金を支払う義務を負う。協力者と受取人は同一人物であってもよい。また協力者と受取人は別人であってもよいが、保険金の受け取り状況（支払状況）がわかる間柄であることが望ましい。

図２１は、図２０のサービス支援装置２０２の構成を示すブロック図である。サービス支援装置２０２は、制御部２１０、記憶部２１２、通信部２１４を備える。制御部２１０は、各種のデータ処理を実行し、サービス支援装置２０２の動作を制御する。制御部２１０は、サービス支援装置２０２のプロセッサ（ＣＰＵやＧＰＵ等）が、各機能ブロックに対応するコンピュータプログラムを実行することにより実現されてもよい。

記憶部２１２は、制御部２１０により参照、更新されるデータを記憶する記憶領域である。記憶部２１２は、メモリやストレージにより実現されてもよい。通信部２１４は、様々な通信プロトコルにしたがって、通信網を介して外部装置と通信する。制御部２１０は、通信部２１４を介して外部装置とデータを送受する。制御部、記憶部、通信部の基本的な機能は、後述の図２２でも同様である。

記憶部２１２は、契約者情報保持部２２０、対象者情報保持部２２２、協力者情報保持部２２４、メッセージ保持部２２６を含む。契約者情報保持部２２０、対象者情報保持部２２２、協力者情報保持部２２４、メッセージ保持部２２６は、前提技術の契約者情報保持部２４、対象者情報保持部２６、協力者情報保持部２８、メッセージ保持部３２に対応する。記憶部２１２は、前提技術のサービス支援装置１０のデータ保持部２０が含む他の機能ブロックをさらに含んでもよい。

契約者情報保持部２２０は、少なくともエンディングサービスコード（以下「ＥＳコード」とも呼ぶ。）と契約者ＩＤを対応付けて保持し、好適には図４で示した契約者情報をさらに保持する。対象者情報保持部２２２は、図５で示した対象者情報を保持し、協力者情報保持部２２４は、図６で示した協力者情報を保持し、メッセージ保持部２２６は、図８で示したメッセージ情報を保持する。

ＥＳコードは、エンディングサービス事業者が予め定めた規則にしたがって定められた識別コードであり、例えば保険会社が各契約者へ割当て、契約者の管理に使用する契約者固有のＩＤである。ＥＳコードは、エンディングサービス事業者と保険会社の双方にとって契約者をユニークに特定可能な識別コードでもある。Ａ保険会社、Ｂ保険会社、Ｃ保険会社のそれぞれは、互いに異なる規則にしたがって異なる体系のＥＳコードを決定する。例えば、ＥＳコードの先頭の２〜３文字に、保険会社の識別情報を設定することを定めた規則であってもよい。各保険会社は、ＥＳコードを、各社の独自の規則にしたがって契約者に割当てた契約者のＩＤ（例えば顧客ＩＤや保険証券番号等）と対応付けて管理してもよい。

制御部２１０は、ＩＤ取得部２３０、関係者登録部２３２、イベント検出部２３４、通知先識別部２３６、サービス支援部２３８、事後確認部２４０、関係者情報提供部２４２、メッセージ取得部２４４、メッセージ配信部２４６を含む。

ＩＤ取得部２３０は、ユーザの死を契機とする所定のサービスを提供する主体が管理するユーザのＩＤを取得する。具体的にはＩＤ取得部２３０は、契約者端末２０４から送信されたＥＳコードを受信し、エンディングサービス事業者における契約者のＩＤである契約者ＩＤを採番する。そして、ＥＳコードと契約者ＩＤを対応付けて契約者情報保持部２２０に格納する。その際にＩＤ取得部２３０は、契約者端末２０４から送信された契約者に関する種々の属性情報（例えば前提技術の契約者情報）を契約者情報保持部２２０にさらに格納してもよい。

関係者登録部２３２は、前提技術の関係者登録部４８に対応する。関係者登録部２３２は、契約者端末２０４から送信された新たな対象者または協力者を指定する登録要求を受け付ける。関係者登録部２３２は、登録要求に応じて、対象者の情報を対象者情報保持部２２２に格納し、協力者の情報を協力者情報保持部２２４へ格納する。関係者登録部２３２は、新たな協力者が指定された場合、その協力者の協力者端末２０６へ契約者ＩＤを通知し、記憶させる。協力者端末２０６は、契約者の死亡をサービス支援装置２０２へ通知する際に、契約者の死亡を示す情報とともに契約者ＩＤを送信する。

また関係者登録部２３２は、契約者端末２０４から送信された既定の対象者または協力者の解除を指示する解除要求を受け付ける。関係者登録部２３２は、解除要求で指定された対象者の情報を対象者情報保持部２２２から削除し、解除要求で指定された協力者の情報を協力者情報保持部２２４から削除する。関係者登録部２３２は、契約者情報保持部２２０（例えば図４）と協力者情報保持部２２４（例えば図６）を参照し、特定の契約者ＩＤに紐付く協力者情報のレコード数が０になった場合、その契約者ＩＤが付与された契約者の協力者数が０であることを検出する。この場合、関係者登録部２３２は、その契約者ＩＤで識別される契約者端末２０４へ、新たな協力者の登録を促すメッセージを送信し、表示させる。なお、協力者が解除される場合も、解除対象の協力者の協力者端末２０６へ契約者ＩＤを通知し、協力者の指定が解除された旨を通知する。

イベント検出部２３４は、メッセージ配信の契機となるイベントの発生を検出し、また、保険会社へのＥＳコード通知の契機となるイベントの発生を検出する。実施の形態ではいずれのイベントも契約者の死亡が該当する。すなわちイベント検出部２３４は、契約者が死亡した場合にその事実を検出する。具体的にはイベント検出部２３４は、協力者端末２０６から送信された情報であり、複数の契約者のうち特定の契約者が死亡した事実を示す情報を受信し、その情報に基づき特定の契約者の死亡を検出する。

変形例として、イベント検出部２３４は、前提技術に記載の契約者の生存確認技術を使用して、契約者が生存し、または死亡した事実を検出してもよい。例えば、定期的に契約者端末２０４へ生存確認メッセージを送信し、その返信に応じて契約者の死亡を判定してもよい。また、上記生存確認メッセージでは契約者の生存、死亡が確認できない場合、協力者端末２０６へ契約者の生存を問い合わせ、その回答に応じて契約者の死亡を判定してもよい。

通知先識別部２３６は、イベント検出部２３４により契約者の死亡が検出された場合、契約者情報保持部２２０を参照して、協力者端末２０６から通知された契約者ＩＤに対応するＥＳコードを識別する。通知先識別部２３６は、識別したＥＳコードのコード体系、例えば先頭２〜３文字の値にしたがって、ＥＳコードを通知すべき保険会社を識別する。例えば、保険会社装置２０８ａ〜保険会社装置２０８ｃの中から通知先とする特定の装置を識別する。

サービス支援部２３８は、イベント検出部２３４により契約者の死亡が検出された場合に、その契約者のＥＳコードを、通知先識別部２３６により識別された特定の保険会社装置２０８へ送信する。サービス支援部２３８は、保険会社毎のウェブ管理画面やウェブＡＰＩを利用してＥＳコードを通知してもよい。例えば、通知先保険会社の保険会社装置２０８が提供するウェブ管理画面を取得し、当該画面にＥＳコードを入力して当該画面の機能によりＥＳコードを保険会社装置２０８へ送信してもよい。また、ＥＳコードを引数として、通知先保険会社の保険会社装置２０８が提供するウェブＡＰＩを呼び出すことでＥＳコードを送信してもよい。サービス支援部２３８は、保険会社装置２０８へ送信したＥＳコードと契約者ＩＤを所定の記憶領域へ格納しておく。

変形例として、サービス支援部２３８自身が、保険会社毎のウェブ管理画面やウェブＡＰＩを提供して各保険会社へＥＳコードを通知してもよい。例えばサービス支援部２３８は、ウェブサーバの機能を有し、各保険会社の担当者端末からのアクセスを受け付け、各保険会社向けのウェブ管理画面を担当者端末へ送信し、表示させてもよい。サービス支援部２３８は、ある保険会社向けのウェブ管理画面のコンテンツとして、その保険会社の契約者のうち死亡が検出された契約者のＥＳコードを設定してもよい。各保険会社の担当者は、ウェブ管理画面に表示されたＥＳコードを確認して契約者の死亡を把握する。

またサービス支援部２３８は、死亡が検出された（例えばイベント検出部２３４により死亡フラグが設定された）契約者のＥＳコード一覧を取得するための保険会社毎の第１のウェブＡＰＩを提供してもよい。さらに、ＥＳコードを引数として契約者のステータス（死亡を示す情報や、契約者の各種属性等）を取得するための保険会社毎の第２のウェブＡＰＩを提供してもよい。各保険会社の保険会社装置２０８は、上記第１および第２のウェブＡＰＩを呼び出すことで、サービス支援装置２０２において死亡が検出された契約者に関する各種情報をサービス支援装置２０２から取得してもよい。

事後確認部２４０は、サービス支援部２３８がある契約者のＥＳコードを保険会社装置２０８へ送信後、所定時間が経過した場合に、その契約者が予め指定した協力者を介して保険サービスの提供状況を確認するための処理を実行する。実施の形態では、死亡が確認された契約者が生前指定していた協力者に対して保険サービスの提供に関する問い合わせを実行する。具体的には、協力者情報保持部２２４を参照して、サービス支援部２３８が所定の記憶領域に格納した契約者ＩＤに対応付けられた協力者ＩＤを識別し、その協力者ＩＤで識別される協力者端末２０６へ問い合わせメッセージを送信する。

問い合わせの内容は、例えば保険会社から保険金が支払われたか否か、保険会社から保険金の支払に関する連絡があったか否か、保険会社へ保険金支払の請求を行ったか否かであってもよい。また、ＥＳコードの通知から問い合わせ実施までの期間は、問い合せの内容に応じて適切な期間が定められてよく、例えば１ヶ月や２ヶ月でもよい。またサービス支援装置２０２の開発者の知見や、保険サービスシステム２００を用いた実験により適切な長さに決定されてもよい。

事後確認部２４０は、問い合わせに対する回答のデータを協力者端末２０６から受信した場合、所定の後処理を実行する。例えば、受信した回答を所定の記憶領域に格納し、エンディングサービス事業者により閲覧可能にしてもよい。エンディングサービス事業者は、保険会社から保険金が支払われていない場合等、保険会社の担当者へ問い合わせを行ってもよい。

また事後確認部２４０は、受信した回答に基づいて保険会社へのフィードバックを実行してもよい。事後確認部２４０は、問い合わせへの回答が、所定のアクションを取るべき内容、例えば保険会社から保険金が支払われていないことを示す場合に、所定のアラートをサービス支援部２３８へ通知してもよい。サービス支援部２３８はこのアラートに応じて、死亡した契約者のＥＳコードを保険会社装置２０８へ再送してもよく、ＥＳコードを含む所定のアラートメッセージを保険会社装置２０８へ送信してもよい。なお、必ずしも協力者端末２０６から回答を受信する必要はない。保険サービスの請求や提供に関する確認メッセージを協力者に提示するだけでも、協力者、ひいては保険サービス受領者の注意を促すことができるからである。

変形例として、事後確認部２４０は、積極的に協力者へ問い合わせることに代えて、保険サービスの提供状況を協力者に入力させるための、言わばアンケートとしてのウェブページやメールフォームを協力者端末２０６へ送信し、表示させてもよい。また事後確認部２４０は、このウェブページやメールフォームを介して、保険サービスの提供状況を回答するよう促すメッセージを協力者端末２０６へ送信し、表示させてもよい。保険サービスの提供状況を確認するための画面は、協力者端末２０６における後述のＥＳＡｐｐの機能により表示されてもよい。協力者は、任意で保険サービスの提供状況を回答してもよい。契約者端末２０４は、協力者端末２０６から送信された回答を受信し、その回答に基づいて上記の後処理を実行してもよい。

関係者情報提供部２４２は、前提技術の協力者確認部５４に対応する機能として、或るユーザ（すなわち契約者）の協力者として指定されたことを示す情報を協力者端末２０６へ提供する。これにより、協力者端末２０６における複数の関係者の一覧画面（後述の関係者画面２７０）で、自身を協力者に指定した関係者（すなわち契約者）と、他の関係者とを異なる態様で表示させる。

関係者情報提供部２４２は、各ユーザ（契約者、対象者、協力者を含む）の端末へ、そのユーザ自身が協力者として指定した他のユーザの識別情報と、そのユーザを協力者として指定した他のユーザの識別情報を送信する。送信タイミングは、定期的であってもよく、関係者の情報が更新されたときでもよく、後述の関係者画面２７０が各ユーザの端末で表示されるときでもよい。

メッセージ取得部２４４は、契約者端末２０４から送信された対象者（協力者）宛のメッセージ、例えば遺言等を取得し、メッセージ保持部２２６に格納する。メッセージ配信部２４６は、イベント検出部２３４によりメッセージ配信契機となるイベントの発生、実施の形態では契約者の死亡が検出された場合に、メッセージ保持部２２６に格納されたメッセージを宛先の対象者（協力者）の端末へ送信する。

図２２は、図２０の契約者端末２０４、協力者端末２０６（以下、これらを総称する場合、単に「端末」と呼ぶ。）の構成を示すブロック図である。契約者端末２０４、協力者端末２０６は、制御部２５０、記憶部２５２、通信部２５４、ＬＣＤ２５６を備える。ＬＣＤ２５６は、端末本体と一体化され、端末のユーザインタフェースとなる液晶表示装置である。ＬＣＤ２５６はタッチパネルの機能も備える。

記憶部２５２は関係者情報保持部２５８を含む。関係者情報保持部２５８は、契約者または協力者により登録された自身の関係者に関する属性情報を保持する。例えば、氏名や電話番号、メールアドレス等を保持してもよい。関係者は、端末のユーザが契約者である場合の対象者、協力者かもしれない。また、端末のユーザを対象者、協力者として指定した契約者かもしれない。さらにまた、メッセージの配信や保険契約に関係しない、その他の人であるかもしれない。

関係者情報保持部２５８は、端末ユーザが協力者として指定した関係者について、その関係者の情報に、端末ユーザ自身が指定した協力者であることを示す自己指定協力者フラグを対応付けて保持する。また関係者情報保持部２５８は、端末ユーザを協力者として指定した関係者について、その関係者の情報に、端末ユーザが協力者として指定されていることを示す他者指定協力者フラグを対応付けて保持する。

制御部２５０は、ＩＤ登録部２６０、関係者登録部２６１、メッセージ登録部２６２、イベント登録部２６４、メッセージ表示部２６６、関係者画面表示部２６８を含む。実施の形態では、これらの機能はエンディングサービスアプリケーションプログラム（以下「ＥＳＡｐｐ」と呼ぶ。）により実現される。例えばＥＳＡｐｐは、ＳＤメモリカード等の記録媒体に格納されて流通され、またはアプリストアサイトのサーバからダウンロードされて端末にインストールされる。そして、端末のストレージに格納されたＥＳＡｐｐを端末のプロセッサが実行することにより、端末は各機能ブロックの機能を発揮する。契約者および協力者は、端末のユーザと言え、ＥＳＡｐｐのユーザとも言える。

変形例として、図２２における制御部２５０の各機能ブロックは、端末のウェブブラウザが、サービス支援装置２０２から提供されたウェブページを処理することで実現されてもよい。例えば、端末のウェブブラウザが、ウェブページのＨＴＭＬコードやＪａｖａＳｃｒｉｐｔ（登録商標）コードにしたがってレンダリング処理やフォーム処理を実行することで実現されてもよい。

ＩＤ登録部２６０は、契約者が入力したＥＳコードを受け付け、そのＥＳコードをサービス支援装置２０２へ送信して登録する。その際に、ＩＤ登録部２６０は、契約者が入力した契約者に関する各種属性情報（前提技術の契約者情報）をさらにサービス支援装置２０２へ送信してもよい。

関係者登録部２６１は、端末のユーザが入力した関係者の情報を受け付け、その関係者の情報を関係者情報保持部２５８に格納する。端末のユーザ（例えば契約者）は、事前に登録した関係者の中からメッセージ配信の対象者や協力者を指定する。登録される関係者は、対象者、協力者を含み、また対象者、協力者以外の関係者、例えば単に連絡先を記録しておきたい人等を含む。

関係者登録部２６１は、端末のユーザ（例えば契約者）が入力した新たな対象者や協力者の指定を受け付ける。このとき関係者登録部２６１は、新たな対象者または協力者を指定する登録要求をサービス支援装置２０２へ送信する。また関係者登録部２６１は、端末のユーザ（例えば契約者）が入力した既定の対象者や協力者の解除を受け付ける。このとき関係者登録部２６１は、既定の対象者または協力者の解除を指示する解除要求をサービス支援装置２０２へ送信する。

関係者登録部２６１は、関係者情報保持部２５８に登録された関係者のうち、端末ユーザが協力者として指定した関係者の情報に自己指定協力者フラグを付加し、端末ユーザを協力者として指定した関係者の情報に他者指定協力者フラグを付加する。既述したように、端末ユーザが協力者として指定した関係者の情報および端末ユーザを協力者として指定した関係者の情報はサービス支援装置２０２から通知される。また、協力者の解除情報もサービス支援装置２０２から通知される。解除の場合、関係者登録部２６１は、自己指定協力者フラグまたは他者指定協力者フラグを関係者の情報から削除する。

メッセージ登録部２６２は、契約者が入力した特定の対象者（協力者を含む）宛のメッセージを受け付け、そのメッセージをサービス支援装置２０２へ送信して登録する。このメッセージは、例えば契約者の死亡時に対象者に開示すべき遺言である。

イベント登録部２６４は、特定のユーザ（例えば契約者）が死亡した旨を端末のユーザ（例えば協力者）が入力した場合に、その契約者ＩＤと死亡した旨の情報を対応付けた死亡情報をサービス支援装置２０２へ送信する。メッセージ表示部２６６は、サービス支援装置２０２が送信したメッセージを取得し、ＬＣＤ２５６に表示させる。このメッセージは、例えば契約者が生前端末のユーザ宛に作成し、サービス支援装置２０２に登録した遺言等である。

関係者画面表示部２６８は、関係者情報保持部２５８を参照して、端末のユーザ（例えば契約者や協力者）が登録した１人以上の関係者の情報を並べた一覧画面である関係者画面をＬＣＤ２５６に表示させる。関係者画面表示部２６８は、関係者画面において、端末のユーザを協力者として指定した関係者と、他の関係者とを異なる態様で表示させることにより、協力者の設定状況の把握を容易にする。

図２３は関係者画面を示す。関係者画面２７０は、関係者の氏名と、自己指定協力者アイコン２７２、他者指定協力者アイコン２７４を含む。自己指定協力者アイコン２７２は、自己指定協力者フラグが付加された関係者の場合にオンの態様（例えば濃い黒色）で表示される。他者指定協力者アイコン２７４は、他者指定協力者フラグが付加された関係者の場合にオンの態様で表示される。

図２３の「鈴木花子」は、自己指定協力者アイコン２７２と他者指定協力者アイコン２７４のいずれもオンである。したがって、端末ユーザが協力者として指定済のユーザであり、かつ端末ユーザを協力者として指定済のユーザであることを示している。図２３の「山田太郎」は、自己指定協力者アイコン２７２はオンである一方、他者指定協力者アイコン２７４はオフ（例えばグレーの態様）である。したがって、端末ユーザが協力者と指定済のユーザであるが、端末ユーザを協力者として未指定のユーザであることを示している。

図２３の「中村次郎」は、自己指定協力者アイコン２７２はオフである一方、他者指定協力者アイコン２７４はオンである。したがって、端末ユーザが協力者として未指定のユーザであるが、端末ユーザを協力者として指定済のユーザであることを示している。図２３の「小林三郎」は、自己指定協力者アイコン２７２と他者指定協力者アイコン２７４のいずれもオフである。したがって、端末ユーザが協力者として未指定のユーザであり、かつ、端末ユーザを協力者として未指定のユーザであることを示している。

以上の構成による保険サービスシステム２００の動作を説明する。
図２４は、図１の保険サービスシステム２００の動作を模式的に示す。エンディングサービス事業者は、連携先の保険会社との間で、契約者に対するＥＳコードの付与規則、言い換えれば、各保険会社固有のＥＳコードの体系を予め定めておく（Ｓ１０）。保険会社と契約者は保険契約を締結し、例えば生命保険を契約する（Ｓ１２）。保険会社は、保険証書とともに契約者に付与したＥＳコードを契約者へ提供する（Ｓ１４）。例えばＥＳコードと、ＥＳＡｐｐを提供するアプリストアサイトにアクセスするための情報を提供する。

契約者は、契約者端末２０４を操作してアプリストアサイトへアクセスし、ＥＳＡｐｐをダウンロードして契約者端末２０４にインストールする（Ｓ１６）。契約者端末２０４のＩＤ登録部２６０は、サービス支援装置２０２へのユーザ登録を実行し、その際に、契約者が入力したＥＳコードをサービス支援装置２０２へ送信する（Ｓ１８）。サービス支援装置２０２のＩＤ取得部２３０は、ＥＳコードと契約者との対応関係を含む契約者情報を記録する。

契約者端末２０４は、契約者が指定した対象者や協力者の情報をサービス支援装置２０２へ送信する。サービス支援装置２０２の関係者登録部２３２は、契約者と対象者、契約者と協力者を対応付けて記録する。契約者端末２０４は、契約者が入力した対象者（協力者）宛のメッセージをサービス支援装置２０２へ送信する（Ｓ２０）。契約者端末２０４のメッセージ取得部２４４は、受信したメッセージを契約者と対象者（協力者）と対応付けて記録する。

図２４には不図示だが、契約者は任意で、過去登録した対象者や協力者を解除し、新たな対象者や協力者を指定することができる。サービス支援装置２０２によるメッセージ配信処理や保険会社装置２０８との連携処理は、メッセージやＥＳコードが登録されてから数年から数１０年後に実行される息の長いサービスである。その間には、協力者の協力者の死亡等により協力者を変更すべき事態が生じるかもしれない。実施の形態のサービス支援装置２０２によると、契約者は周囲の状況の変化に応じて、対象者や協力者を柔軟に調整することができる。

なおサービス支援装置２０２の関係者情報提供部２４２は、ＥＳＡｐｐが導入された端末（例えば契約者端末２０４、協力者端末２０６等）へ、端末のユーザが協力者として指定した他のユーザの識別情報を送信する。また、端末のユーザを協力者として指定した他のユーザの識別情報を送信する。図２３で示したように、端末の関係者画面表示部２６８は、関係者画面２７０において、端末のユーザが協力者として指定した他のユーザと、端末のユーザを協力者として指定した他のユーザを識別可能に表示させる。

この態様によると、ＥＳＡｐｐのユーザに、協力者の設定状況を直感的に把握させることができる。例えば、他者から新たに協力者として指定されたこと、他者から協力者の指定を解除されたこと等をユーザに直感的に把握させることができる。また、契約者死亡時の保険金の受取人は、協力者に指定されていない場合にその事実を容易に認識して、契約者に対して協力者に指定するよう促すことができる。

協力者は、契約者からの要請に応えて、または、契約者の協力者として指定された旨のメッセージを受領したことを契機に、ＥＳＡｐｐを協力者端末２０６へインストールする（Ｓ２２）。その後、契約者が死亡した場合、協力者端末２０６のイベント登録部２６４は、契約者の死亡を示す情報をサービス支援装置２０２へ送信する（Ｓ２４）。この情報を受信した場合、サービス支援装置２０２のイベント検出部２３４は、契約者の死亡を検出する。サービス支援装置２０２のメッセージ配信部２４６は、Ｓ２０で登録されたメッセージを協力者端末２０６および不図示の対象者の端末へ送信する（Ｓ２６）。

サービス支援装置２０２の通知先識別部２３６は、死亡が検出された契約者に紐付くＥＳコードを識別し、そのコードに基づいてコードの通知先保険会社を決定する。サービス支援装置２０２のサービス支援部２３８は、ＥＳコードを含む契約者死亡通知を通知先識別部２３６が決定した通知先の保険会社装置２０８へ送信する（Ｓ２８）。なお、Ｓ２６とＳ２８は順序が逆であってもよく、並行に実行されてもよい。契約者死亡通知を受け付けた保険会社の担当者は、ＥＳコードに紐付く契約情報等を参照して受取人を識別し、受取人へ連絡等を行う（Ｓ３０）。例えば保険会社の担当者は、受取人に対して保険金の請求を勧奨する。

この態様によると、契約者の死亡が把握できないことに起因して保険会社の保険金不払いが生じるリスクを低減することができる。例えば、定期付終身保険の場合、契約者の保険料支払期間が終了後、保険会社側で契約者の生存を自律的に把握することは困難であった。その一方、サービス支援装置２０２が実現するエンディングサービスシステムでは、契約者が生前設定したエンディングサービス（例えばメッセージ配信や保険金等）を享受するために、協力者はサービス支援装置２０２に対して契約者の死亡を通知する。実施の形態では、サービス支援装置２０２が保険会社装置２０８へ契約者の死亡を通知することにより、保険会社は保険契約者の死亡、すなわち保険金を支払うべき事態が生じたことを精度よく把握することができる。

また、サービス支援装置２０２と保険会社装置２０８で共有するＥＳコードは、保険会社毎に異なる体系が定められる。これにより、サービス支援装置２０２は、契約者死亡時にＥＳコードを通知すべき保険会社を正しく判断でき、複数の保険会社が参加可能な保険サービスシステム２００を実現できる。

サービス支援装置２０２の事後確認部２４０は、Ｓ２８の後、予め定められた期間が経過したことを検出すると、保険金の請求状況や支払状況を問い合わせるためのメッセージを協力者端末２０６へ送信する（Ｓ３２）。協力者と受取人が同一であれば、協力者は保険金の請求状況や支払状況を回答し、協力者と受取人が別であれば、協力者は受取人に確認後、回答する。その回答結果に応じて、サービス支援装置２０２やエンディングサービス事業者は適切な後処理を実行する。この態様によると、協力者や受取人へのアフターケアを提供し、また保険会社の保険金未払いリスクを一層低減することができる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。

第１変形例を説明する。実施の形態の保険サービスシステム２００では、保険会社とは独立したエンディングサービス事業者がサービス支援装置２０２を管理することとした。変形例として、保険会社がサービス支援装置２０２を管理してもよく、またサービス支援装置２０２の機能は保険会社装置２０８に組み込まれてもよい。本変形例のサービス支援装置２０２は、契約者の死亡を検出した場合に、その契約者が予め指定した人に対して所定のサービスを提供するための処理を実行してもよい。例えば、銀行等の金融機関のシステムと連携して、受取人に対する保険金の支払い処理を実行してもよい。

第２変形例を説明する。実施の形態のサービス支援装置２０２は、保険会社装置２０８と連携して保険会社の業務を支援することとした。ただしサービス支援装置２０２が連携し、また業務を支援する対象は保険会社装置２０８に限られない。サービス支援装置２０２は、協力者の申告に基づいて人の死を検知するものであり、ユーザの死を契機とする所定のサービスを提供すべき種々の主体の装置と連携し、その主体の業務を支援することができる。例えば、区市町村の役所等、公的機関の装置と連携して、人の死に伴う様々な行政サービスを支援することができる。

第３変形例を説明する。実施の形態のサービス支援装置２０２は、契約者、対象者、協力者それぞれの情報を管理することとした。変形例としてサービス支援装置２０２は、保険金の受取人の情報、例えば受取人ＩＤ・氏名・契約者ＩＤ・連絡先・メールアドレス等をさらに管理してもよい。具体的には、受取人は、自端末へのＥＳＡｐｐ導入時に、ある契約者の保険金の受取人であることを入力し、サービス支援装置２０２は、受取人の情報を契約者と対応づけて記録してもよい。別の態様として、契約者が、ＥＳコードの登録時もしくは登録後に受取人の情報をサービス支援装置２０２へ登録してもよい。契約者の死亡が検出され、ＥＳコードを保険会社装置２０８へ通知後、サービス支援装置２０２の事後確認部２４０は、協力者端末２０６に代えて受取人端末へ保険金の支払い状況を問い合わせてもよい。

第４変形例を説明する。実施の形態では言及していないが、契約者の死亡時にサービス支援装置２０２が保険会社装置２０８へ通知するＥＳコードは、エンディングサービス事業者と保険会社の両方において同一の契約者をユニークに識別可能な情報であればよい。したがって、ＥＳコードとして、保険証券番号や、保険会社が従来の業務で定める顧客ＩＤや契約ＩＤ（もしくはそれらの組み合わせ）を使用することもできる。また、サービス支援装置２０２が契約者へ付与する契約者ＩＤを使用することもできる。この場合、サービス支援装置２０２は、保険証券番号を契約者端末２０４から取得し、その保険証券番号とサービス支援装置２０２が決定した契約者ＩＤを保険会社装置２０８へ通知し、保険会社側で記録させてもよい。

第５変形例を説明する。第４変形例で一部既述したように、ＥＳコードとして、エンディングサービス事業者が定めた付与規則に制約されないコードであり、他のサービス主体が独自に定め、また独自に発行するユーザのＩＤやサービスコード（以下「外部コード」と呼ぶ。）を使用してもよい。外部コードは、保険証券の証券番号であってもよく、公的機関が国民に付与する住民票コードや個人番号（いわゆるマイナンバー）であってもよい。

ＥＳコードとして外部コードを使用する場合、契約者情報保持部２２０は、契約者ＩＤと対応付けてＥＳコードと、ＥＳコードの通知先となる外部主体（保険会社等）の識別情報を保持する。外部コードの体系はサービス主体側で独自に定められ、外部コード自体では通知先の識別が困難な場合があるからである。契約者は、サービス支援装置２０２へＥＳコードを登録する際、言い換えればユーザ登録する際に、サービス支援装置２０２へＥＳコードの通知先情報を登録してもよい。サービス支援装置２０２の通知先識別部２３６は、契約者の死が検出された場合、その契約者ＩＤに対応付けられた通知先情報に基づいてＥＳコードの通知先（例えば特定の保険会社装置２０８）を識別する。サービス支援部２３８は、通知先識別部２３６により識別された通知先へ、契約者ＩＤに対応付けられたＥＳコードを送信することにより契約者の死を通知する。

第６変形例を説明する。第２変形例で一部既述したように契約者のＥＳコードの通知先は、保険会社に代えてもしくは保険会社とともに、契約者が予め登録したサービス主体であってもよい。例えば、区市町村の役所等、公的機関の装置であってもよく、銀行や証券会社等の金融機関の装置であってもよく、成年後見人や葬儀会社、葬祭コーディネータが保持する装置や情報端末であってもよい。契約者は、ＥＳコードの通知先を複数登録してもよく、通知先の都合に応じて通知先毎に異なるＥＳコードを登録してもよい。契約者は、１つ以上のＥＳコードをサービス支援装置２０２へ登録する際に、各ＥＳコードの通知先のアドレス（ＩＰアドレスやメールアドレス等）をあわせて登録してもよい。

第７変形例を説明する。１人の契約者（１つの契約者ＩＤ）と対応づけてＥＳコードの通知先が複数登録された場合、サービス支援装置２０２のサービス支援部２３８は、契約者の死亡検出時に、通知先のサービス主体や装置の属性に応じた異なるタイミングでＥＳコードを各通知先へ送信してもよい。サービス支援部２３８は、通知先のサービス主体の属性に応じて予め固定的に定められたＥＳコードの通知タイミングを保持してもよい。通知タイミングは、例えば、通知先が成年後見人や葬儀会社であれば契約者の死亡検出直後に通知することが定められてもよい。また、通知先が保険会社であれば契約者の死亡検出から数日後（例えば葬儀が終了したことが見込まれる日数経過後）に通知することが定められてもよい。

また、ＥＳコードの通知タイミングは、契約者により通知先毎に登録され、サービス支援装置２０２の契約者情報保持部２２０に、通知先と通知タイミングの組が複数保持されてもよい。サービス支援部２３８は、予め固定された通知タイミング、または契約者が予め登録した通知タイミングを参照し、各通知先への通知タイミングに至ったことを検出した場合に、各通知先の装置へＥＳコードを送信してもよい。

第７変形例に関連する第８変形例を説明する。サービス支援部２３８は、複数のサービス主体へ異なるタイミングでＥＳコードを通知する場合、通知先のサービス主体の装置から送信されたフィードバックデータを受信してもよい。通知先のサービス主体は、契約者の死を確認した場合、また契約者の死に伴う業務を実行した場合等に、その旨を示すフィードバックデータをサービス支援装置２０２へ送信してもよい。またフィードバックデータは、契約者の死亡を確定する内容であってもよく、逆に契約者の生存を示す内容であってもよい。

ここで先（最初）のＥＳコードの通知先は、契約者や協力者に直接関係しない第三者の個人や企業、例えば弁護士や成年後見人、葬儀会社、保険会社であることが望ましい。これにより、サービス支援装置２０２ではフィードバックデータを受信した場合に、契約者が生存しているか、死亡しているかを確定でき、他のサービス主体へのＥＳコードの通知可否を判定できる。例えば、契約者が生存しているにも関わらず、協力者が誤って契約者の死亡を申告した場合に、フィードバックデータに基づいて、協力者の申告の誤りや、契約者の生存を検出でき、ＥＳコードの提供抑制を実現できる。

具体例として、サービス支援装置２０２のサービス支援部２３８は、通知タイミングが先（最初）の第１主体装置から、契約者の死亡を確定する内容のフィードバックデータを受信したことを条件として、内部に保持する死亡確定フラグをオンにしてもよい。そして以降、通知タイミングが後の第２主体装置へＥＳコードを送信してもよい。また、第１主体装置から、契約者の死亡を確定する内容を示すフィードバックデータを未受信の場合、または契約者の生存を示すフィードバックデータを受信した場合、死亡確定フラグがオフであるため、第２主体装置へＥＳコードを送信することを抑制してもよい。言い換えれば、第２主体装置への通知タイミングに至っても、第２主体装置へＥＳコードを送信することを抑制してもよい。

第９変形例を説明する。ＥＳＡｐｐのユーザ（例えば契約者）に対してサービス支援装置２０２が提供するユーザ登録画面は、ＥＳコード入力領域、受取人情報入力領域、画像指定領域、保険内容入力領域を含んでもよい。画像指定領域は、サービス支援装置２０２に登録する画像データ、例えば保険証券を撮像した画像データについて、そのファイル名を指定する入力フィールドであってもよい。保険内容領域は、保険金の支払額や支払条件、支払時期等を示す情報の入力フィールドであってもよい。

契約者端末２０４のＩＤ登録部２６０は、ユーザ登録画面に入力されたＥＳコード、受取人情報、画像データ、保険内容をサービス支援装置２０２へ送信して登録する。サービス支援装置２０２のＩＤ取得部２３０は、これらの情報を契約者情報保持部２２０に格納する。サービス支援装置２０２の事後確認部２４０は、契約者により登録された保険証券等の画像データや保険内容を含む問い合わせメッセージを協力者端末２０６や受取人端末へ送信する。この態様によると、契約者の死に伴い提供されるべき保険サービスの詳細を示しつつ保険サービスの提供に関する問い合わせを行うため、保険サービスの請求や提供が適切になされたか否かを一層確実に確認することができる。

上述した前提技術、実施の形態、変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる前提技術、実施の形態、変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、前提技術、実施の形態、変形例において示された各構成要素の単体もしくはそれらの連携により実現されることも当業者には理解されるところである。

２００ 保険サービスシステム、 ２０２ サービス支援装置、 ２０８ 保険会社装置、 ２２０ 契約者情報保持部、 ２２２ 対象者情報保持部、 ２２４ 協力者情報保持部、 ２３０ ＩＤ取得部、 ２３２ 関係者登録部、 ２３４ イベント検出部、 ２３６ 通知先識別部、 ２３８ サービス支援部、 ２４０ 事後確認部、 ２４２ 関係者情報提供部。

Claims (5)

1. ユーザの死を契機として所定のサービスを提供するサービス主体と、それとは別の主体であって情報処理を担当する管理主体との間の連携をとる、管理主体が有する装置であり、
   前記サービス主体が用いるユーザのＩＤを取得するＩＤ取得部と、
   取得されたＩＤをユーザと対応付けて記憶するユーザ情報記憶部と、
   ユーザが死亡した場合にその事実を検出する検出部と、
   ユーザの死亡が検出された場合に、そのユーザのＩＤを前記サービス主体へ通知するサービス支援部と、
   を備えることを特徴とする情報処理装置。
2. 前記検出部は、ユーザが予め指定した協力者の申告に基づいて、そのユーザが死亡した事実を検出し、
   当該装置はさらに、協力者の指定および解除をユーザから受け付ける協力者登録部をさらに備えることを特徴とする請求項１に記載の情報処理装置。
3. 前記検出部は、ユーザが予め指定した協力者の申告に基づいて、そのユーザが死亡した事実を検出し、
   当該装置はさらに、
   協力者の指定をユーザから受け付ける協力者登録部と、
   協力者の端末へ或るユーザの協力者として指定されたことを示す情報を提供することにより、前記協力者の端末における複数の関係者の一覧画面において、前記或るユーザと他の関係者とを異なる態様で表示させる協力者情報提供部と、をさらに備えることを特徴とする請求項１に記載の情報処理装置。
4. 前記検出部は、ユーザが予め指定した協力者の申告に基づいて、そのユーザが死亡した事実を検出し、
   当該装置はさらに、ユーザのＩＤを前記サービス主体へ通知後、そのユーザの協力者を介して前記所定のサービスの提供状況を確認するための処理を実行する確認部をさらに備えることを特徴とする請求項１に記載の情報処理装置。
5. ユーザのＩＤは、前記所定のサービスを提供する複数のサービス主体のそれぞれで異なる規則にしたがって定められ、
   前記サービス支援部は、前記複数のサービス主体のうち、死亡が検出されたユーザのＩＤに基づき識別される特定のサービス主体へユーザのＩＤを通知することを特徴とする請求項１から４のいずれかに記載の情報処理装置。

Images