JP6348634B1 - 情報管理システム、及びプログラム - Google Patents

Abstract

【課題】故人の伝言内容を複数の縁故者に公平かつ確実に開示する。【解決手段】管理サーバ１０は、ユーザに関連する特定の縁故者に対して開示されるべき伝言内容と、伝言内容を開示する対象となる複数の縁故者とを、ユーザのアカウントに対応付けて保存するデータベース１２を備える。管理サーバ１０は、ユーザが死亡したことを表す死亡通知を受信した場合、当該ユーザのアカウントに対応付けられている縁故者それぞれのユーザ端末３０に対して、当該ユーザの死亡についての確認を求める確認通知を送信する。そして、管理サーバ１０は、確認通知が送信された複数の縁故者の全てからユーザの死亡を認める旨の回答を受付けたことを条件に、当該複数の縁故者それぞれのユーザ端末３０に対して、当該アカウントに対応付けられている開示情報の伝言内容を開示可能にする。【選択図】図１

Description

本開示は、故人が生前に保存したメッセージを特定の縁故者に対して開示にする情報管理システム、及び当該情報管理システムにおいて利用されるプログラムに関する。

特許文献１には、故人が生前に自分自身や親類・知人に関する情報を記録すると共に、当人の死をトリガーにして、故人が希望する限定された範囲に当該故人が記録した情報を伝達する個人情報管理システムについて記載されている。

特開２０１２−１６８６６４号公報

上述のような個人情報管理システムにおいて扱われる情報には、例えば、遺産の相続に関する情報のような縁故者間の利害に関する情報が含まれ得る。そのため、故人のメッセージが縁故者に開示される際には、複数の縁故者間のトラブルに発展しないように配慮することが肝要である。例えば、故人の死を他の縁故者よりも早くに知った一部の縁故者が、他の縁故者に先駆けて故人のメッセージを入手し、抜け駆けをするといった行為を未然に防ぐ工夫が求められる。本開示は、このような課題を解決するためになされたものである。

本開示の一態様に係る情報管理システムは、データベースと、死亡受付部と、確認通知部と、回答受付部と、開示制御部とを備える。
データベースは、ユーザに設定されたアカウントに関する情報であるアカウント情報を保存するように構成されている。また、データベースは、ユーザに関連する特定の縁故者に対して開示されるべき伝言内容を少なくとも含む開示情報を、当該ユーザのアカウント情報に対応付けて保存するように構成されている。また、データベースは、ユーザのアカウント情報に対応付けられている開示情報の伝言内容を開示する対象となる複数の縁故者それぞれの連絡先を特定し得る情報を含む縁故者情報を、当該アカウント情報に対応付けて保存するように構成されている。

死亡受付部は、ユーザが死亡したことを表す死亡通知を受付けるように構成されている。確認通知部は、死亡通知を受付けたことを条件に、当該死亡通知に該当するユーザのアカウント情報に対応付けられている縁故者情報から特定される複数の縁故者それぞれの連絡先に対して、当該ユーザの死亡についての確認を求める確認通知を送信するように構成されている。

回答受付部は、確認通知部により確認通知が送信された複数の縁故者からの回答を受付けるように構成されている。開示制御部は、確認通知が送信された複数の縁故者の全てからユーザの死亡を認める旨の回答を受付けたことを条件に、当該複数の縁故者それぞれの連絡先に対して、当該アカウント情報に対応付けられている開示情報の伝言内容を開示可能にするように構成されている。

上述の情報管理システムによれば、ユーザのアカウントに対応付けられた複数の縁故者全員が、当該ユーザが死亡したことに同意したことを条件に、伝言内容が開示される仕組みになっている。すなわち、指定された複数の縁故者のうちの一部のみがユーザの死亡に同意している段階では、当該ユーザの伝言内容は何れの縁故者にも開示されない。これにより、ユーザの伝言内容を確実に全ての縁故者に開示することができると共に、一部の縁故者が他の縁故者に対して抜け駆けをするといったトラブルを防ぐことができる。

また、本開示の情報管理システムにおいて、更に次のように構成してもよい。すなわち、データベースは、単一のユーザについて複数のアカウントに関するアカウント情報を保存可能に構成されている。また、データベースは、単一のユーザに関する複数のアカウント情報それぞれについて、開示情報と複数の縁故者に関する縁故者情報とを個別に対応付けて保存可能に構成されている。確認通知部は、死亡通知に該当するユーザの複数のアカウント情報にそれぞれ対応付けられている縁故者情報から特定される複数の縁故者それぞれの連絡先に対して、当該ユーザの死亡についての確認を求める確認通知を送信するように構成されている。

そして、開示制御部は、複数のアカウント情報それぞれについて、次のようにして伝言内容を開示可能にするように構成されている。すなわち、１つのアカウント情報に対応付けられた複数の縁故者の全てからユーザの死亡を認める旨の回答を受付けたことを条件に、当該複数の縁故者それぞれの連絡先に対して、当該アカウント情報に対応付けられている開示情報の伝言内容を開示可能にする。

例えば、家族、親類、友人・知人、弁護士や遺品整理士等の関係者といった、縁故者として指定され得る様々な人物と故人との関係の度合は様々であり、その関係の度合に応じて故人が伝えたい伝言内容の内容も多様に異なると考えられる。そこで、１人のユーザが複数のアカウントを持てるようにしたことで、個々のアカウントごとに複数の縁故者とその縁故者に伝えたい伝言内容を登録することができる。そうすることで、１つのアカウントごとに縁故者をグループ分けし、そのグループごとに開示する伝言内容の内容を異ならせるといった具合に、多様な運用が可能となる。

また、本開示の情報管理システムにおいて、更に次のように構成してもよい。すなわち、データベースの開示情報には、ユーザの死亡後において伝言内容が開示されるべき期日を表す期日情報が更に含まれている。そして、開示制御部は、開示情報に含まれる期日情報で示される期日が到来したときに、当該開示情報の伝言内容を開示可能にするように構成されている。このような構成によれば、例えば、年忌ごとといった節目のタイミングで、それぞれの節目に合わせた内容の伝言内容を縁故者に開示するといった多様な運用が可能となる。

また、本開示の情報管理システムにおいて、更に次のように構成してもよい。すなわち、管理者の権限に基づいてユーザの死亡を確定する情報である死亡確定情報の入力を受付ける確定情報受付部を更に備える。そして、開示制御部は、死亡確定情報を受付けた場合、確認通知が送信された複数の縁故者からの回答の有無に関わらず、当該複数の縁故者それぞれの連絡先に対して、ユーザの伝言内容を開示可能にするように構成されている。このような仕組みによれば、何らかの不測の事態によって縁故者がユーザの死亡を認める回答を行うことが困難な状況において、管理者の権限に基づいて例外的に伝言内容を縁故者に開示することができる。

また、本開示の情報管理システムにおいて、更に次のように構成してもよい。すなわち、ユーザのアカウント情報に対応付けられている縁故者情報に該当する縁故者は、データベースにアカウント情報が登録されている他のユーザである。このような構成によれば、縁故者への伝言内容を託したいユーザに関する情報と、当該伝言内容を受け取るべき縁故者に関する情報とを統括して管理可能な情報管理システムを実現できる。

また、本開示の情報管理システムにおいて、更に次のように構成してもよい。すなわち、ユーザの身体に装着されて当該ユーザの生体信号を計測して外部に送信するように構成されたウェアラブル端末により計測された生体信号を取得し、その取得した生体信号に基づいてユーザの生死状態を判定するように構成された判定部を更に備える。そして、死亡受付部は、判定部による判断結果を死亡通知として取得するように構成されている。

ユーザの身体に装着されるウェアラブル端末を利用することで、ユーザの生体信号を常時看視することができる。そして、ウェアラブル端末によって常時看視され得る生体信号を用いることで、ユーザの生死状態を常時速やかに判断して、いち早く縁故者に通知を送信することができる。

なお、本開示に係る情報管理システムを利用するユーザ及び縁故者のためのユーザインタフェースとして、例えば、スマートフォンやタブレットコンピュータ等の通信端末を利用することが考えられる。具体的には、それらの通信端末に次のようなプログラムを実装するとよい。そのプログラムは、アカウント登録手順と、縁故者登録手順と、開示情報登録手順と、受信手順と、送信手順と、出力手順とを、コンピュータに実行させるプログラムである。

アカウント登録手順は、入力されたアカウント情報を情報処理システムに登録する手順である。縁故者登録手順は、入力された縁故者情報をアカウント情報に対応付けて情報処理システムに登録する手順である。開示情報登録手順は、入力された開示情報をアカウント情報に対応付けて情報処理システムに登録する手順である。受信手順は、情報処理システムから送信される確認通知を受信する手順である。送信手順は、受信した確認通知で示されるユーザについて、当該ユーザが死亡したことを認める操作を受付けたことを条件に、当該ユーザの死亡を認める旨の回答を情報処理システムに送信する手順である。出力手順は、前記情報処理システムによって開示可能にされた開示情報の伝言内容にアクセスし、その伝言内容の内容を出力する手順である。

上述のように構成されたプログラムによれば、本開示の情報管理システムにおけるユーザ及び縁故者双方のためのユーザインタフェースを実現できる。

情報管理システムの全体構成を表す図。 「users」テーブルの論理的構造を表す図。 「accounts」テーブルの論理的構造を表す図。 「bereaves」テーブルの論理的構造を表す図。 「messages」テーブルの論理的構造を表す図。 「movie_messages」テーブルの論理的構造を表す図。 生前整理アプリケーションの機能の一覧を表す図。 情報管理システムにおいて実行される処理の一例を表す図。 情報管理システムにおいて実行される処理の変形例を表す図。 生前整理アプリケーションにおける画面表示例を表す図。 生前整理アプリケーションにおける画面表示例を表す図。

以下、本開示の実施形態を図面に基づいて説明する。なお、本開示は下記の実施形態に限定されるものではなく様々な態様にて実施することが可能である。
［情報管理システムの構成の説明］
実施形態の情報管理システムの構成について、図１を参照しながら説明する。図１に例示されるとおり、情報管理システムは、例えばインターネット等の広域ネットワークであるネットワーク１００に接続された管理サーバ１０を備える。

管理サーバ１０は、登録されたユーザの生前整理に関する情報を管理するサービスに関する各種処理を実行するサーバコンピュータである。以下、このサービスを、生前整理サービスという。管理サーバ１０は、図示しないＣＰＵ、ＲＡＭ、ＲＯＭ、補助記憶装置、入出力インタフェース等を中心に構成されている。この管理サーバ１０の機能は、ＣＰＵがＲＯＭや、半導体メモリ等の非遷移的実体的記憶媒体に格納されたプログラムを実行することにより実現される。管理サーバ１０は、機能的構成として、制御部１１とデータベース１２とを備える。

制御部１１は、ネットワーク１００に接続されたユーザ端末３０上で動作する、生前整理サービスのための専用のアプリケーション（以下、生前整理アプリケーションという）からの要求に応じて各種情報を提供する機能を有する。なお、ネットワーク１００に接続されたユーザ端末３０と、管理サーバ１０との通信は、周知のＨＴＴＰＳ(Hypertext Transfer Protocol Secure)の仕組みによりデータのやりとりを暗号化した状態で行われる。また、制御部１１は、登録されたユーザに関する情報が保存されたデータベースを管理し、その保存されている情報に基づいて各ユーザに対応した情報提供等のサービスを実行する機能を有する。データベース１２を管理する機能として、制御部１１には、例えば、PostgreSQL（登録商標）等の周知の関係データベース管理システムが実装されている。

データベース１２は、生前整理サービスを利用する権限を有するユーザに関する各種情報を保存するためのデータベースである。このデータベース１２には、ユーザに関するデータ群を、情報種別ごとに表形式にまとめたテーブルが保存される。データベース１２に保存されるテーブルには、ユーザの定義に関する情報のテーブル、ユーザのアカウントに関する情報のテーブル、ユーザのアカウントに対応付けられる縁故者に関する情報のテーブル、及び伝言内容に関する情報のテーブル等が含まれる。これらのテーブルには、各テーブルのデータ間の関連を定義する情報も記録されている。ここで、データベース１２において保存される主なテーブルの詳細な内容について、図２〜図６を参照しながら説明する。

《「users」テーブル》
図２に例示される「users」テーブルは、生前整理サービスの会員として登録されたユーザの定義に関する情報が記録されるテーブルである。図２に例示されるとおり、「users」テーブルは、「id」、「push_id」、「os」、「created_at」、及び「updated_at」からなる＃１〜＃５の属性を有する。この「users」テーブルには、個々のユーザごとに＃１〜＃５の各属性に対応する値の組（以下、レコードともいう）が記録される。また、各属性には、値として取り得る範囲を表す型が定義されている。図２に例示される「users」テーブルにおける各属性の内容は、次のとおりである。

「id」は、ユーザを識別するための一意の識別子を表す属性であり、記録される値はinteger型である。この「id」の属性は、「users」テーブルにおける主キーであり、当該ユーザのレコードを特定するために利用される。

「push_id」は、当該ユーザに対応するユーザ端末３０に対してプッシュ通知を行う際に用いる、当該ユーザ端末３０に対応する固有の識別情報を表す属性である。この「push_id」の属性に記録される値は、character varying型である。

「os」は、当該ユーザに対応するユーザ端末３０に実装されているオペレーティングシステム（すなわち、ＯＳ）の種類を表す属性であり、記録される値はcharacter varying型である。本実施形態では、ユーザ端末３０に実装されるＯＳとして、例えばiOS（登録商標）や、Android（登録商標）等を想定している。

「created_at」は、当該ユーザに関するレコードが「users」テーブルに作成された日時を表す属性であり、記録される値はtimestamp without time zone型である。「updated_at」は、当該ユーザに関するレコードが更新された日時を表す属性であり、記録される値はtimestamp without time zone型である。

《「accounts」テーブル》
図３に例示される「accounts」テーブルは、先述の「users」テーブルに登録されているユーザそれぞれに設定されているアカウントに関する情報が記録されるテーブルである。本実施形態では、１人のユーザについて少なくとも１以上のアカウントを設定できるようになっている。

図３に例示されるとおり、「accounts」テーブルは、「id」、「user_id」、「created_at」、「updated_at」、「user_type」、「name」、「tel」、「prefecture_id」、「postcode」、「address1」、「address2」、「email」、「encrypted_password」、「reset_password_token」、及び「passed_date」からなる＃１〜＃１５の属性を有する。この「accounts」テーブルには、個々のアカウントごとに＃１〜＃１５の各属性に対応する値の組（すなわち、レコード）が記録される。また、各属性には、値として取り得る範囲を表す型が定義されている。図３に例示される「accounts」テーブルにおける各属性の内容は、次のとおりである。

「id」は、ユーザに設定されたアカウントを識別するための一意の識別子を表す属性であり、記録される値はinteger型である。この「id」の属性は、「accounts」テーブルにおける主キーであり、当該アカウントのレコードを特定するために利用される。

「user_id」は、当該アカウントと対応付けられるユーザの識別子を表す属性であり、記録される値はinteger型である。この「user_id」の属性には、当該アカウントと対応付けられるユーザの識別子として、「users」テーブル（図２参照）における当該ユーザの「id」の属性と共通の値が記録される。これにより、「users」テーブルに登録されているユーザと、「accounts」テーブルに登録されているアカウントとの対応関係を特定することができるようになっている。また、「accounts」テーブルにおいて、「user_id」の属性に共通のユーザの識別子を記録した複数のレコードを設けることで、１人のユーザについて複数のアカウントを設定できるようになっている。

「created_at」は、当該アカウントに関するレコードが「accounts」テーブルに作成された日時を表す属性であり、記録される値はtimestamp without time zone型である。「updated_at」は、当該アカウントに関するレコードが更新された日時を表す属性であり、記録される値はtimestamp without time zone型である。

「user_type」は、当該アカウントにおけるユーザの種別を表す属性であり、記録される値はinteger型である。この「user_type」の属性には、例えば、一般のユーザは０、遺品整理士は１、弁護士は２、アドバイザーは３といった具合に、ユーザの種別に応じた所定の数値が記録される。

「name」は、当該アカウントにおけるユーザの名称を表す属性であり、記録される値はcharacter varying型である。この「name」の属性に記録された名称は、当該アカウントを表す名称としてユーザ端末３０において表示される。「tel」は、当該アカウントにおけるユーザの連絡先としての電話番号を表す属性であり、記録される値はcharacter varying型である。

「prefecture_id」は、当該アカウントにおけるユーザの住所が属する都道府県を識別するためのコードを表す属性であり、記録される値はinteger型である。「postcode」は、当該アカウントにおけるユーザの住所に対応する郵便番号を表す属性であり、記録される値はcharacter varying型である。「address1」は、当該アカウントにおけるユーザの住所の上位の階層を表す属性であり、記録される値はcharacter varying型である。「address2」は、当該アカウントにおけるユーザの住所の下位の階層を表す属性であり、記録される値はcharacter varying型である。「email」は、当該アカウントにおけるユーザの連絡先としての電子メールアドレスを表す属性であり、記録される値はcharacter varying型である。

「encrypted_password」は、当該アカウントにログインするための認証に用いる、暗号化されたパスワードを表す属性であり、記録される値はcharacter varying型である。「reset_password_token」は、当該アカウントに設定されたパスワードをリセットする際の認証に用いるトークンを表す属性であり、記録される値はcharacter varying型である。

「passed_date」は、当該アカウントに対応するユーザが死亡した日付を表す属性であり、記録される値はdatetime型である。この「passed_date」の属性には、初期値としてNULLが記録されており、管理サーバ１０が外部からの通知に基づいて当該ユーザの死亡を確定したときに、その死亡した日付が記録される。

《「bereaves」テーブル》
図４に例示される「bereaves」テーブルは、ユーザのアカウントに対応付けられる縁故者に関する情報が記録されるテーブルである。なお、ここでいう縁故者とは、例えば、家族、親類、友人、知人、弁護士や遺品整理士といった、ユーザと特定の関係を有する人物を含む概念である。この「bereaves」テーブルにおいてユーザのアカウントに対応付けられる縁故者は、当該ユーザが予め記録しておいた伝言内容を、当該ユーザが死亡した後に開示する対象となる人物である。

本実施形態では、ユーザのアカウントに対応付けられる縁故者は、データベース１２にアカウントが登録されている他のユーザである。また、１つのアカウントについて少なくとも２以上の複数の縁故者のアカウントを対応付けるようになっている。また、１人のユーザに複数のアカウントが設定されている場合には、個々のアカウントごとに縁故者のアカウントを対応付けることができるようになっている。

図４に例示されるとおり、「bereaves」テーブルは、「id」、「account_id」、「account_target_id」、「created_at」、及び「updated_at」からなる＃１〜＃５の属性を有する。この「bereaves」テーブルには、各アカウントに対応付けられる個々の縁故者ごとに＃１〜＃５の各属性に対応する値の組（すなわち、レコード）が記録される。また、各属性には、値として取り得る範囲を表す型が定義されている。図４に例示される「bereaves」テーブルにおける各属性の内容は、次のとおりである。

「id」は、アカウントに対応付けられた縁故者のレコードを識別するための一意の識別子を表す属性であり、記録される値はinteger型である。この「id」の属性は、「bereaves」テーブルにおける主キーである。

「account_id」は、縁故者を指名したユーザのアカウントを表す属性であり、記録される値はinteger型である。この「account_id」の属性には、「accounts」テーブル（図３参照）における当該アカウントの「id」の属性と共通の値が記録される。これにより、「accounts」テーブルに登録されているユーザのアカウントと、「bereaves」テーブルに記録されているレコードとの対応関係を特定することができるようになっている。また、「bereaves」テーブルにおいて、「account_id」の属性に共通のアカウントの識別子を記録した複数のレコードを設けることで、１つのアカウントについて複数の縁故者を設定できるようになっている。

「account_target_id」は、「account_id」の属性で示されるアカウントに対応付けされる縁故者のアカウントを表す属性であり、記録される値はinteger型である。この「account_target_id」の属性には、「accounts」テーブル（図３参照）における当該アカウントの「id」の属性と共通の値が記録される。これにより、「accounts」テーブルに登録されている縁故者のアカウントと、「bereaves」テーブルに記録されているレコードとの対応関係を特定することができるようになっている。

「created_at」は、当該レコードが「bereaves」テーブルに作成された日時を表す属性であり、記録される値はtimestamp without time zone型である。「updated_at」は、当該レコードが更新された日時を表す属性であり、記録される値はtimestamp without time zone型である。

《「messages」テーブル》
図５に例示される「messages」テーブルは、ユーザのアカウントに対応付けられた縁故者に開示される伝言内容であって、文書等の文字情報で構成される伝言内容に関する情報が記録されるテーブルである。なお、本実施形態では、１つアカウントについて少なくとも１以上の伝言内容を設定できるようになっている。

図５に例示されるとおり、「messages」テーブルは、「id」、「account_id」、「message」、「day_of_publish」、「created_at」、及び「updated_at」からなる＃１〜＃６の属性を有する。この「messages」テーブルには、個々の伝言内容ごとに＃１〜＃６の各属性に対応する値の組（すなわち、レコード）が記録される。また、各属性には、値として取り得る範囲を表す型が定義されている。図５に例示される「messages」テーブルにおける各属性の内容は、次のとおりである。

「id」は、ユーザのアカウントに対応する伝言内容を識別するための一意の識別子を表す属性であり、記録される値はinteger型である。この「id」の属性は、「messages」テーブルにおける主キーであり、当該伝言内容のレコードを特定するために利用される。

「account_id」は、当該伝言内容を用意したユーザのアカウントを表す属性であり、記録される値はinteger型である。この「account_id」の属性には、「accounts」テーブル（図３参照）における当該アカウントの「id」の属性と共通の値が記録される。これにより、「accounts」テーブルに登録されているユーザのアカウントと、「messages」テーブルに記録されているレコードとの対応関係を特定することができるようになっている。また、「messages」テーブルにおいて、「account_id」の属性に共通のアカウントの識別子を記録した複数のレコードを設けることで、１つのアカウントについて複数の伝言内容を対応付けることができるようになっている。

「message」は、伝言内容を構成する文書等の文字情報を表す属性であり、記録される値はtext型である。「day_of_publish」は、当該伝言内容が開示される期日を表す属性であり、記録される値はinteger型である。この「day_of_publish」の属性に記録される値は、例えば、当該ユーザの死亡日から起算される開示の期日までの日数を表す値である。

「created_at」は、当該レコードが「messages」テーブルに作成された日時を表す属性であり、記録される値はtimestamp without time zone型である。「updated_at」は、当該レコードが更新された日時を表す属性であり、記録される値はtimestamp without time zone型の値である。

《「movie_messages」テーブル》
図６に例示される「movie_messages」テーブルは、ユーザのアカウントに対応付けられた縁故者に開示される伝言内容であって、動画や静止画等の画像情報で構成される伝言内容に関する情報が記録されるテーブルである。なお、本実施形態では、１つアカウントについて少なくとも１以上の伝言内容を設定できるようになっている。

図６に例示されるとおり、「movie_messages」テーブルは、「id」、「account_id」、「path」、「day_of_publish」、「created_at」、及び「updated_at」からなる＃１〜＃６の属性を有する。この「movie_messages」テーブルには、個々の伝言内容ごとに＃１〜＃６の各属性に対応する値の組（すなわち、レコード）が記録される。また、各属性には、値として取り得る範囲を表す型が定義されている。図６に例示される「movie_messages」テーブルにおける各属性の内容は、次のとおりである。

「id」は、ユーザのアカウントに対応する伝言内容を識別するための一意の識別子を表す属性であり、記録される値はinteger型である。この「id」の属性は、「movie_messages」テーブルにおける主キーであり、当該伝言内容のレコードを特定するために利用される。

「account_id」は、当該伝言内容を用意したユーザのアカウントを表す属性であり、記録される値はinteger型である。この「account_id」の属性には、「accounts」テーブル（図３参照）における当該アカウントの「id」の属性と共通の値が記録される。これにより、「accounts」テーブルに登録されているユーザのアカウントと、「movie_messages」テーブルに記録されているレコードとの対応関係を特定することができるようになっている。また、「movie_messages」テーブルにおいて、「account_id」の属性に共通のアカウントの識別子を記録した複数のレコードを設けることで、１つのアカウントについて複数の伝言内容を対応付けることができるようになっている。

「path」は、伝言内容を構成する動画や静止画等の画像ファイルのデータベース１２内での所在（すなわち、パス）を表す属性であり、記録される値はcharacter varying型である。「day_of_publish」は、当該伝言内容が開示される期日を表す属性であり、記録される値はinteger型である。この「day_of_publish」の属性に記録される値は、例えば、当該ユーザの死亡日から起算される開示の期日までの日数を表す値である。

「created_at」は、当該レコードが「movie_messages」テーブルに作成された日時を表す属性であり、記録される値はtimestamp without time zone型である。「updated_at」は、当該レコードが更新された日時を表す属性であり、記録される値はtimestamp without time zone型である。

図１の説明に戻る。管理者端末２０は、管理サーバ１０に接続されて用いられる管理者用の端末装置であり、キーボード等の入力デバイスと出力用のディスプレイを備える。管理者端末２０は、情報管理システムを運営する管理者の権限に基づく指示を管理サーバ１０に対して与える機能を有する。

ユーザ端末３０は、生前整理サービスをユーザが利用するためのユーザインタフェースとしての機能を備える携帯情報端末である。ユーザ端末３０は、いわゆるスマートフォン等の高機能携帯電話やタブレットコンピュータ等により具現化され、モバイルデータ通信や無線ＬＡＮ通信を利用してネットワーク１００に接続する。

ユーザ端末３０は、図示しないＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の半導体メモリ、入出力インタフェース、無線通信装置等を中心に構成されている。ユーザ端末３０が備える入出力デバイスとしては、例えば、液晶ディスプレイ、スピーカ、マイク、タッチパネル、指紋センサ等が例示される。ユーザ端末３０機能は、ＣＰＵがＲＯＭや、半導体メモリ等の非遷移的実体的記憶媒体に格納されたプログラムを実行することにより実現される。

ユーザ端末３０には、生前整理サービスを利用するためのユーザインタフェースの機能を提供する生前整理アプリケーションがインストールされている。ユーザ端末３０は、生前整理アプリケーションを通じて管理サーバ１０との間で情報をやりとりし、ユーザから入力された情報を管理サーバ１０に送信したり、管理サーバ１０から受信した情報に基づいて各種情報を提示する。

ここで、ユーザ端末３０おいて稼動する生前整理アプリケーションにより提供される主な機能の具体例について、図７を参照しながら説明する。
生前整理アプリケーションは、図７に例示されるとおり、一般ユーザ向けの機能として、例えば、「ユーザ登録をする」、「アカウントを設定・追加する」、「掲示板に投稿する」、「伝言内容を開示したい縁故者を設定する」、「エンディングノートを作成・保存する」、「メッセージを作成・保存する」、「専門資格業者に連絡をする」、「情報を閲覧する」、「有料会員に登録する」等の機能を備える。また、弁護士や遺品整理士、アドバイザー等の専門資格業者向けの機能として、「コラムを書く」、「掲示板にコメントする」等の機能を更に備える。なお、専門資格業者に該当するユーザについても、一般ユーザ向けの機能を利用できる。

上述の各機能の概要は次のとおりである。
（１）「ユーザ登録をする」機能は、生前整理アプリケーションを通じて生前整理サービスを利用する初期の段階において、ユーザを情報管理システムに登録する機能である。例えば、生前整理アプリケーションは、ユーザが生前整理アプリケーションにログインするための認証情報を設定する手続きを実行する。認証情報としては、例えば、パスワードや生体情報（指紋、静脈、網膜等）を用いることが考えられる。

また、生前整理アプリケーションは、新規のユーザと当該ユーザが使用するユーザ端末３０に関する情報を管理サーバ１０に登録するために必要な情報を管理サーバ１０に送信する。ここで送信される情報には、例えば、ユーザ端末３０のＯＳの種類を表す情報や、ユーザ端末３０に対してプッシュ通知を行うために必要な固有の識別情報等を含むデバイス情報が含まれる。

管理サーバ１０の制御部１１は、生前整理アプリケーションから受信した新規のユーザ及びユーザ端末３０に関する情報に基づき、データベース１２の「users」テーブル（図２参照）に、新規のユーザに関するレコードを新たに作成する。

（２）「アカウントを設定・追加する」機能は、登録されたユーザについてアカウントを設定する機能である。具体的には、生前整理アプリケーションは、アカウントを設定するために必要な各種情報の入力をユーザから受付けるためのＧＵＩを表示し、そのＧＵＩに従ってユーザから入力された情報を管理サーバ１０に送信する。ここで送信される情報には、例えば、当該アカウントで使用するユーザの名称、ユーザの種類、電話番号、郵便番号、住所、電子メールアドレス、当該アカウントにアクセスするためのパスワード、パスワードをリセットするためのトークン等の情報が含まれる。

管理サーバ１０の制御部１１は、生前整理アプリケーションから受信したアカウントの設定に関する情報に基づき、データベース１２の「accounts」テーブル（図３参照）に新規のアカウントに関するレコードを新たに作成する。このアカウントに関するレコードには、対応するユーザのidが記録される。これにより、「users」テーブルに登録されているユーザと、「accounts」テーブルに登録された新規のアカウントが対応付けられる。

（３）「掲示板に投稿する」機能は、管理サーバ１０による生前整理サービスの一部として運営される電子掲示板に、ユーザが入力した記事を投稿する機能である。電子掲示板とは、ネットワーク環境において記事を書き込んだり、記事に対するコメントを書き込んだり、それらの情報を閲覧できるようにしたものである。

（４）「伝言内容を開示したい縁故者を設定する」機能は、ユーザが用意した伝言内容を開示する対象となる縁故者をアカウントごとに設定する機能である。具体的には、生前整理アプリケーションは、アカウントにログインしている状態で、当該アカウントに対応付けされる縁故者を特定するための情報の入力をユーザから受付けるためのＧＵＩを表示し、そのＧＵＩに従ってユーザから入力された情報を管理サーバ１０に送信する。縁故者を特定するための情報としては、例えば、縁故者のアカウントに登録されている電子メールアドレスを用いることが考えられる。なお、本実施形態では、伝言内容を縁故者に開示可能にするためには、１つのアカウントにつき２名以上の縁故者を登録することを要件としている。

管理サーバ１０の制御部１１は、生前整理アプリケーションから受信した縁故者の設定に関する情報に基づき、「bereaves」テーブル（図４参照）に新規の縁故者に関するレコードを新たに作成する。具体的には、制御部１１は、生前整理アプリケーションから受信した縁故者の電子メールアドレス等に基づいて、データベース１２の「accounts」テーブルから当該縁故者に該当するユーザのアカウントを特定する。そして、制御部１１は、縁故者を指名したユーザのアカウントを表す「account_id」と、指名された縁故者のアカウントを表す「account_target_id」とを含むレコードを、「bereaves」テーブルに新たに追加する。これにより、「accounts」テーブルに登録されているアカウントの中から、縁故者を指名したユーザのアカウントと、当該縁故者のアカウントとが対応付けられる。

（５）「エンディングノートを作成・保存する」機能は、ユーザが縁故者に対して開示したい伝言内容の１態様である「エンディングノート」を、アカウントごとに作成及び保存する機能である。ここでいうエンディングノートとは、予め用意された項目に沿って縁故者に伝えたい事項がまとめられた情報である。

エンディングノートに記録できる項目としては、例えば、自己紹介や自分史等といったユーザ自身のこと、親戚や友人・知人の一覧、財産・保険・年金等について、ペットについて、お墓や葬儀について、解約をお願いしたいもの、各種サービスの暗証番号、遺書について等といったものが挙げられる。

生前整理アプリケーションは、アカウントにログインしている状態において、エンディングノートの項目に沿った情報を入力するための入力項目を備えたＧＵＩを表示し、そのＧＵＩに従ってユーザから入力された情報を管理サーバ１０に送信する。管理サーバ１０の制御部１１は、生前整理アプリケーションから受信したエンディングノートの内容を表す情報に基づき、「message」テーブル（図５参照）に新規の伝言内容に関するレコードを新たに作成する。この伝言内容に関するレコードには、対応するユーザのアカウントを表す「account_id」が記録される。これにより、「accounts」テーブルに登録されているアカウントと、「message」テーブルに登録された新規の伝言内容が対応付けられる。

（６）「メッセージを作成・保存する」機能は、ユーザが縁故者に対して開示したい伝言内容の１態様である「メッセージ」を、アカウントごとに作成及び保存する機能である。ここでいうメッセージとは、特定のテーマや項目等を設けず、縁故者に伝えたい事項が自由に記述された文書や、ユーザが撮影された動画／静止画等の情報である。

生前整理アプリケーションは、アカウントにログインしている状態において、メッセージを構成する文字情報の入力を受付けるためのＧＵＩを表示し、そのＧＵＩに従ってユーザから入力された情報を管理サーバ１０に送信する。あるいは、生前整理アプリケーションは、ユーザ端末３０に備えられたカメラ及びマイクを起動してユーザの動画像や静止画像を撮影し、撮影された画像ファイルをメッセージとして管理サーバ１０に送信する。

また、生前整理アプリケーションは、文書メッセージや画像メッセージを開示すべき期日の入力をユーザから受付け、入力された期日を表す情報をメッセージと共に管理サーバ１０に送信する。なお、メッセージを開示すべき期日として指定され得るものとしては、例えば、年忌等の節目の日が上げられる。また、ユーザの死後に速やかに開示されるべきメッセージについては、期日の指定は不要である。

管理サーバ１０の制御部１１は、生前整理アプリケーションから受信したメッセージの情報に基づき、「messages」テーブル（図５参照）又は「move_messages」（図６参照）に新規の伝言内容に関するレコードを新たに作成する。この伝言内容に関するレコードには、対応するユーザのアカウントを表す「account_id」が記録される。これにより、「accounts」テーブルに登録されているアカウントと、「message」テーブル又は「move_messages」テーブルに登録された新規の伝言内容が対応付けられる。

（７）「専門資格業者に連絡をする」機能は、弁護士や遺品整理士、アドバイザー等の専門資格業者として登録されている特定のユーザのアカウントに対して、連絡事項を通知する機能である。

（８）「情報を閲覧する」機能は、管理サーバ１０から提供される各種コンテンツをディスプレイに表示する閲覧機能である。例えば、生前整理アプリケーションは、電子掲示板や、専門資格業者が投稿したコラム、死亡したユーザのエンディングノートやメッセージ等のコンテンツのデータを、管理サーバ１０から取得し、これを表示する。

なお、死亡したユーザのエンディングノートやメッセージ等の伝言内容については、当該ユーザの死後において、当該ユーザのアカウントに対応付けられた複数の縁故者による所定の確認の手続を経たことを条件に、管理サーバ１０によって開示される。この一連の手順の詳細な説明については、後述する。

（９）「有料会員に登録する」機能は、所定の会費を支払うことで特典が付与される有料会員にユーザを登録する機能である。例えば、ユーザが伝言内容を作成する機能のうち、エンディングノートを作成・保存する機能については、有料会員限定のサービスとし、メッセージを作成・保存する機能については、有料会員の登録の有無に関わらず利用可能にするといった運用が挙げられる。

（１０）「コラムを書く」機能は、専門資格業者として登録されているユーザのために設けられた機能である。この機能は、専門資格業者が作成した、一般ユーザを対象とする記事を公開する機能である。

（１１）「掲示板にコメントする」機能は、専門資格業者として登録されているユーザのために設けられた機能である。この機能は、一般ユーザによって電子掲示板に投稿された記事に対して、コメント（すなわち、レス）を投稿する機能である。

［伝言内容の開示に関する処理の説明］
登録されたユーザが死亡したときに、管理サーバ１０が当該ユーザ（以下、故人という）のアカウントに対応付けられた縁故者に伝言内容を開示する処理の手順について、図８のシーケンス図を参照しながら説明する。図８の事例では、ユーザが死亡したとき（ステップＳ０）に、何らかの方法により、故人のアカウントに対応付けられた縁故者の少なくとも１人に故人の死亡が知らされたことを前提とする。また、遺族等から故人の死亡証明書が生前整理サービスの管理部門に提出されたことを前提とする。

ステップＳ１００では、故人の死亡を知った縁故者のユーザ端末３０から、生前整理アプリケーションを通じて故人に関する死亡通知が管理サーバ１０に送信される。死亡通知の送信は、生前整理アプリケーションにおける縁故者の操作指示に基づいて実行されるようになっている。この死亡通知には、故人のアカウントを特定する情報が含まれる。

ステップＳ１０２では、管理サーバ１０の制御部１１が、ユーザ端末３０から受信した死亡通知に該当するアカウントに対応付けられている全ての縁故者のユーザ端末３０に対して、故人の死亡についての確認を求める確認通知を送信する。具体的には、制御部１１は、データベース１２の「users」テーブル、「accounts」テーブル、及び「bereaves」テーブルにおいて相互に対応付けられているユーザ間の関係に基づき、故人のアカウントに対応付けられている縁故者を抽出する。そして、制御部１１は、抽出された縁故者に対応するユーザ端末３０を対象とするプッシュ通知により、故人の死亡の確認を求める確認通知を送信する。あるいは、抽出された縁故者に対応する電子メールアドレスに対して、電子メールで確認通知を送信する構成であってもよい。なお、故人に複数のアカウントが設定されている場合、制御部１１は、全てのアカウントに対応付けられている縁故者に対して確認通知を送信する。

ステップＳ１０４では、管理サーバ１０から確認通知を受信したそれぞれのユーザ端末３０において、縁故者が故人の死亡を認める入力操作を行ったことを条件に、死亡を認める回答を管理サーバ１０に送信する。この回答には、送信元の縁故者のアカウントを表す情報が含まれる。ステップＳ１０６では、管理サーバ１０の制御部１１は、複数の縁故者のユーザ端末３０から送信されてくる回答を受信する。

ステップＳ１０８では、制御部１１が、故人のアカウントに対応付けられた全ての縁故者から死亡を認める回答を受信したか否かを判定する。なお、故人に複数のアカウントが設定されている場合、制御部１１は、個々のアカウントごとに判定を行う。すなわち、制御部１１は、１つのアカウントに対応付けられた全ての縁故者から死亡を認める回答を受信したことを条件に、そのアカウントについて肯定判定をする。

ステップＳ１０８において肯定判定がなされた場合、制御部１１はステップＳ１００に進む。ステップＳ１１０では、制御部１１は、肯定判定がなされたアカウントについて故人の死亡を確定する。具体的には、制御部１１は、データベース１２の「accounts」テーブルにおける故人のアカウントの「passed_date」の属性に、死亡した日付を記録する。次のステップＳ１１２では、制御部１１は、死亡が確定されたアカウントに対応付けられている全ての縁故者に対して、当該アカウントに対応する伝言内容のうち、開示の期日が設定されていない伝言内容を開示する。

具体的には、制御部１１は、データベース１２の「messages」テーブル及び「move_messages」テーブルから開示するエンディングノートやメッセージ等の伝言内容の一覧を抽出する。そして、制御部１１は、開示するエンディングノートやメッセージ等の伝言内容の一覧を、開示の対象となる縁故者のユーザ端末３０に通知する。これにより、縁故者のユーザ端末３０において、管理サーバ１０から通知された伝言内容の一覧に基づいて、閲覧する伝言内容のデータを管理サーバ１０から取得できるようになっている。

一方、死亡が確定されたアカウントに対応する伝言内容のうち、開示の期日が設定されている伝言内容については、制御部１１は次のようにする。すなわち、ステップＳ１１４では、制御部１１は、現在の日時が伝言内容の開示の期日に該当する日付を過ぎているか否かを判定する。伝言内容の開示の期日に該当する日付を過ぎている場合、制御部１１はステップＳ１１６に進む。ステップＳ１１６では、開示の期日が過ぎている伝言内容を開示する。

ステップＳ１１８では、縁故者のユーザ端末３０は、管理サーバ１０において開示された伝言内容のデータを取得し、それをディスプレイに表示して縁故者に閲覧させる。具体的には、ユーザ端末３０は、管理サーバ１０から通知された伝言内容の一覧に基づいて、伝言内容のデータを管理サーバから取得する。管理サーバ１０は、ユーザ端末３０からの取得要求に応じて、開示された伝言内容のデータを要求元のユーザ端末３０に送信する。そして、ユーザ端末３０は、取得した伝言内容のデータに基づいて、文字情報や動画像・静止画像等を表示する。

一方、故人の死亡証明書を受理した管理部門では、ステップＳ１２０において、管理者が所定の手続により故人の死亡の事実を確認する。そして、故人のアカウントに対応付けられた何れかの縁故者について、何らかの止むを得ない事情により故人の死亡を認める回答を送ることが継続的に困難な状況に陥っていると管理者が把握した場合、次のようにする。それは、故人の伝言内容が永久に開示されない事態を回避するために行われる例外的な措置である。

すなわち、ステップＳ１２２において、管理者は、管理者端末２０から管理サーバ１０に対して、回答できない縁故者に対応する故人のアカウントについて死亡を確定する入力操作を行う。ステップＳ１２２により管理者端末２０から死亡を確定する入力操作を受付けた管理サーバ１０の制御部１１は、ステップＳ１１０において、当該アカウントについて故人の死亡を確定し、Ｓ１１２以降の処理に進む。

［伝言内容の開示に関する処理の変形例］
図８に例示される処理の変形例について、図９を参照しながら説明する。上述の図８の事例では、ステップＳ１００において、故人の死亡が知らされた縁故者のユーザ端末３０から、管理サーバ１０に対して死亡通知が送信される事例について説明した。これに対し、図９の事例は、ユーザの身体に装着されたウェアラブル端末により測定されるユーザの生体信号に基づいて、管理サーバ１０がユーザの生死状態を判定する構成を採用した点で図８の事例と相違する。

ウェアラブル端末は、装着者の心拍数や血圧、体温等を表す生体信号を計測するセンサと、外部の通信機器（例えば、ユーザ端末３０）と無線通信を行うための通信装置とを備え、常時、装着者の生体信号を外部の通信機器に送信するように構成されている。外部の通信機器は、ウェアラブル端末から受信した生体信号と、そのウェアラブル端末を装着しているユーザの識別情報とを含むユーザ生体情報を管理サーバ１０に送信する。なお、ウェアラブル端末は、例えば、指輪や腕輪等のように、装着者にとって違和感の少ない態様で装着可能な形状を有し、内蔵された電源あるいはワイヤレスで供給される電源によって稼動するものが望ましい。

図９に例示されるとおり、ステップＳ１０１では、管理サーバ１０の制御部１１は、受信したユーザ生体情報のデータに基づいて、当該ユーザの生死状態を判定する。具体的には、制御部１１は、ユーザ生体情報に含まれる生体信号を生死状態の判断基準となる所与の基準データと比較し、その比較結果に基づいてユーザの生死状態を判断する。

ステップＳ１０１においてユーザが死亡したと判定した場合、制御部１１はステップＳ１０２に進む。ステップＳ１０２では、制御部１１は、故人のアカウントに対応付けられている全ての縁故者のユーザ端末３０に対して、故人の死亡についての確認を求める確認通知を送信する。ステップＳ１０２以降の手順については、図８の事例と同様であるので説明を省略する。

［ユーザ端末３０における画面表示例］
つぎに、ユーザ端末３０における生前整理アプリケーションの画面表示例について、図１０及び図１１を参照しながら説明する。

図１０は、生前整理アプリケーションの起動から、アカウント登録、及び縁故者設定までの一連の手順における画面表示例である。まず、図１０の（１）は、生前整理アプリケーションの起動直後における画面表示例である。起動直後の画面には、例えば、生前整理アプリケーションにログインするための指紋認証を開始するボタンが設けられている。このボタンがタッチパネル上で押下されることにより、図１０の（２）に例示されるユーザ認証画面に移行する。

図１０の（２）は、ユーザが生前整理アプリケーションにログインするための指紋認証を受付けるためのユーザ認証画面の一例である。このユーザ認証画面において、指紋センサにより読取られたユーザの指紋が予め登録されている指紋と一致したことを条件に、ユーザのログインが成立する。

ユーザのログインが成立した後、当該ユーザにアカウントが１つも登録されていない場合、図１０の（３）に例示されるアカウント登録画面に移行する。図１０の（３）に例示されるとおり、アカウント登録画面には、アカウントを登録するために必要な各種情報を入力するための入力フォームが設けられている。ユーザが入力フォームに従って必要な情報を入力した後、「登録」ボタンが押下されると、入力された情報がユーザ端末３０から管理サーバ１０に送信され、管理サーバ１０において当該ユーザのアカウントが登録される。

一方、ユーザのログインが成立した後、当該ユーザに既にアカウントが登録されている場合、あるいは図１０の（３）のアカウント登録画面においてアカウントの登録が済んだ場合、図１０の（４）に例示されるアカウント選択画面に移行する。図１０の（４）に例示されるとおり、アカウント選択画面には登録済のアカウントの一覧が表示されている。このアカウント選択画面に表示されているアカウントの一覧の中からグインするアカウントが１つ選択され、「決定」ボタンが押下されることで、図１０の（５）に例示されるアカウント認証画面に移行する。

図１０の（５）に例示されるとおり、アカウント認証画面には、選択されたアカウントにログインするためのパスワードの入力するための入力フォームが設けられている。このアカウント認証画面において、入力フォームに入力されたパスワードが、当該アカウントに対応付けて予め登録されているパスワードと一致したことを条件に、当該アカウントへのログインが成立する。アカウントへのログインが成立した後、図１０の（６）に例示されるアカウント画面に移行する。

図１０の（６）に例示されるとおり、アカウント画面には、ログイン中のアカウントにおいてユーザが利用できる機能の一覧が表示されている。このアカウント画面に表示されている機能の一覧の中から、「アカウント管理」ボタンが押下された場合、図１０の（７）に例示されるアカウント管理画面に移行する。

図１０の（７）に例示されるとおり、アカウント管理画面には、ログイン中のアカウントに関する管理を行うための機能の一覧が表示されている。このアカウント管理画面に表示されている機能の一覧の中から、「縁故者設定」ボタンが押下された場合、図１０の（８）に例示される縁故者設定画面に移行する。

図１０の（８）に例示されるとおり、縁故者設定画面には、ログイン中のアカウントに該当するユーザが死亡した際に伝言内容を開示する対象となる、複数の縁故者を指定するための入力フォームが設けられている。図１０の（８）の事例では、他のユーザのアカウントに登録されているメールアドレスを入力フォームに入力することで、そのアカウントを縁故者に指定することができるようになっている。なお、図１０の（８）の事例では、２名の縁故者のメールアドレスを入力できるようになっているが、２名よりも多くの縁故者を指定できるような構成であってもよい。

ユーザが入力フォームに従って縁故者のメールアドレスを入力した後、「入力」ボタンが押下されると、入力された情報がユーザ端末３０から管理サーバ１０に送信される。管理サーバ１０は、データベース１２に登録されているアカウントの中から、受信したメールアドレスに該当する縁故者のアカウントを抽出し、抽出された縁故者のアカウントを、当該縁故者を指名したアカウントに対応付けてデータベース１２に登録する。

つぎに、図１１は、死亡通知の送信から、死亡を認める回答の送信、及び伝言内容の閲覧までの一連の手順における画像表示例である。なお、図１１の画像表示例は、図１０の事例において縁故者を登録したアカウント「acc3」から縁故者に指名されたアカウント側の画面表示例を想定したものである。

図１１の（１）は、ログイン中のアカウントを縁故者に指名している他のユーザのアカウント（以下、指名アカウントという）の一覧である。図１１の（１）の事例では、指名アカウントの一覧にアカウント「acc3」が表示されていると共に、「通知する」ボタンが設けられている。この「通知する」ボタンは、指名アカウントに該当するユーザが死亡した際の第一報を、管理サーバ１０に通知する機能を実行するためのアイコンである。指名アカウント一覧画面に表示されている「通知する」ボタンが押下された場合、図１１の（２）に例示される死亡通知画面に移行する。

図１１の（２）に例示されるとおり、死亡通知画面には、アカウント「acc3」に該当のユーザが亡くなった日付を入力するための入力フォームが設けられている。ユーザが入力フォームに従って指名ユーザの死亡した日付を入力した後、「決定」ボタンが押下されると、入力された日付の情報を含む死亡通知がユーザ端末３０から管理サーバ１０に送信されるようになっている。管理サーバ１０は、アカウント「acc3」に関する死亡通知を受信した場合、アカウント「acc3」に該当するユーザの全てのアカウントに対応付けられている縁故者のアカウントに対して、アカウント「acc3」の死亡について確認を求める確認通知を送信する。

管理サーバ１０から確認通知を受信した各ユーザ端末３０では、図１１の（３）に例示されるように、アカウント「acc3」の縁故者となっているアカウント画面において、「お知らせがあります」との表示がなされる。このアカウント画面において「お知らせがあります」ボタンが押下された場合、図１１の（４）に例示されるお知らせ画面に移行する。

図１１の（４）に例示されるとおり、お知らせ画面には、管理サーバ１０から受信した確認通知に該当するアカウントの一覧が表示されている。このお知らせ画面に表示されているアカウントの一覧の中から、ユーザが手続を進めるアカウントを選択することで、図１１の（５）に例示される回答送信画面に移行する。

図１１の（５）に例示されるとおり、回答送信画面にはアカウント「acc3」の死亡を知らせる文面と共に、その死亡を認める旨の回答をするための「認める」ボタンが設けられている。この回答送信画面において「認める」ボタンが押下されると、死亡を認める回答がユーザ端末３０から管理サーバ１０に送信されるようになっている。管理サーバ１０は、アカウント「acc3」に関する確認通知を送信した先の全ての縁故者のアカウントからの回答を待ち受ける。

管理サーバ１０が他の縁故者からの回答を待ち受けている間、図１０の（６）に例示されるように、指名アカウントの一覧画面において、アカウント「acc3」の表示と共に「確認中」の表示が設けられる。この時点では、各縁故者のユーザ端末３０においては、アカウント「acc3」に関する伝言内容を閲覧することはできないようになっている。その後、アカウント「acc3」に対応付けられている全ての縁故者からの回答が出揃った場合、管理サーバ１０は、アカウント「acc3」の伝言内容を、対応する各縁故者のアカウントに対して開示する。

その結果、図１０の（７）に例示されるように、縁故者のアカウントにおける指名アカウントの一覧画面において、アカウント「acc3」の表示と共に「情報閲覧」ボタンが設けられる。この「情報閲覧」ボタンが押下された場合、図１０の（８）に例示される伝言内容一覧画面に移行する。

図１０の（８）に例示されるとおり、伝言内容一覧画面には、アカウント「acc3」の伝言内容の項目の一覧が表示されている。この伝言内容一覧画面において、ユーザが閲覧したい項目を選択することにより、選択された項目に該当する伝言内容を閲覧することができるようになっている。例えば、図１０の（８）に例示される伝言内容一覧画面において、「メッセージを閲覧」の項目が選択された場合、図１０の（９）に例示されるメッセージ一覧画面に移行する。

図１０の（９）に例示されるとおり、メッセージ一覧画面には、管理サーバ１０により開示済みのメッセージの一覧が表示されている。このメッセージ一覧画面において、ユーザが閲覧したいメッセージを選択することにより、選択されたメッセージの文字情報や画像が表示されるようになっている。ただし、メッセージ一覧画面に表示されているメッセージの他に、例えば、七回忌を開示の期日とするメッセージが存在し、かつ現時点で七回忌を迎えていない場合、そのメッセージはメッセージ一覧画面には表示されず、閲覧できないようになっている。

［効果］
実施形態の情報管理システムによれば、以下の効果を奏する。
ユーザのアカウントに対応付けられた複数の縁故者全員が、当該ユーザが死亡したことに同意したことを条件に、伝言内容が開示される。つまり、指定された複数の縁故者のうちの一部のみがユーザの死亡に同意している段階では、当該ユーザの伝言内容は何れの縁故者にも開示されない。これにより、ユーザの伝言内容を確実に全ての縁故者に公平に開示することができると共に、一部の縁故者が他の縁故者に対して抜け駆けをするといったトラブルを防ぐことができる。

１人のユーザが複数のアカウントを持つことができ、個々のアカウントごとに複数の縁故者とその縁故者に伝えたい伝言内容を登録することができる。これにより、縁故者として指定される様々な人物について、ユーザとの関係の度合応じてアカウントごとに縁故者をグループ分けし、そのグループごとに開示する伝言内容の内容を異ならせるといった多様な運用が可能となる。

伝言内容に開示期日を設定できるようになっている。これにより、例えば、年忌ごとといった節目のタイミングで、それぞれの節目に合わせた内容の伝言内容を縁故者に開示するといった多様な運用が可能となる。

ユーザの死亡を確定する指示を管理者端末２０から入力できるようになっている。これにより、何らかの不測の事態によって縁故者がユーザの死亡を認める回答を行うことが困難な状況において、管理者の権限に基づいて例外的に伝言内容を縁故者に開示することができる。

伝言内容を縁故者に伝達したいユーザと、縁故者として故人の伝言内容を閲覧するユーザとが、共に生前整理サービスにおけるアカウントを有するユーザとして管理されている。これにより、縁故者への伝言内容を託したいユーザに関する情報と、当該伝言内容を受け取るべき縁故者に関する情報とを統括して管理可能な情報管理システムを実現できる。

ユーザの身体に装着されるウェアラブル端末により測定された生体信号を常時看視することで、ユーザの生死状態を常時速やかに判断して、いち早く縁故者に通知を送信することができる。

［特許請求の範囲に記載の構成との対応］
実施形態の各構成と、特許請求の範囲に記載の構成との対応は次のとおりである。
管理サーバ１０の制御部１１がユーザ端末３０から死亡通知を受信する処理が、死亡受付部としての処理に相当する。管理サーバ１０の制御部１１が実行するステップＳ１０２の処理が、確認通知部としての処理に相当する。管理サーバ１０の制御部１１が実行するステップＳ１０６の処理が、回答受付部としての処理に相当する。管理サーバ１０の制御部１１が管理者端末２０から死亡確定の入力を受付ける処理が、確定情報受付部としての処理に相当する。管理サーバ１０の制御部１１が実行するステップＳ１１２及びステップＳ１１４の処理が、開示制御部としての処理に相当する。管理サーバ１０の制御部１１が実行するステップＳ１０１の処理が、判定部としての処理に相当する。

［変形例］
上記各実施形態における１つの構成要素が有する機能を複数の構成要素に分担させたり、複数の構成要素が有する機能を１つの構成要素に発揮させたりしてもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加、置換等してもよい。なお、特許請求の範囲に記載の文言から特定される技術思想に含まれるあらゆる態様が、本開示の実施形態である。

例えば、上述の実施形態では、死亡したユーザの伝言内容が開示される対象となる縁故者についても、前記ユーザと同様に生前整理サービスにアカウントを有するユーザである事例について説明した。これに限らず、生前整理サービスのユーザとして登録されていない人物を縁故者として設定できる構成であってもよい。その場合、縁故者として登録される人物の電子メール宛に、故人の死亡についての確認を求める確認通知や、伝言内容の開示を行う旨の通知を送信するように構成することが考えられる。

上述した管理サーバ１０を構成要件とするシステム、管理サーバ１０としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体、情報管理方法等の種々の形態で本開示を実現することもできる。

１０…管理サーバ、１１…制御部、１２…データベース、２０…管理者端末、３０…ユーザ端末、１００…ネットワーク。

Claims (6)

1. ユーザに設定されたアカウントに関する情報であるアカウント情報を保存し、また、前記ユーザに関連する特定の縁故者に対して開示されるべき伝言内容を少なくとも含む伝言開示情報を、当該ユーザのアカウント情報に対応付けて保存し、また、前記ユーザのアカウント情報に対応付けられている開示情報の伝言内容を開示する対象となる複数の縁故者それぞれの連絡先を特定し得る情報を含む縁故者情報を、当該アカウント情報に対応付けて保存するように構成されたデータベースと、
   前記ユーザが死亡したことを表す死亡通知を受付けるように構成された死亡受付部と、
   前記死亡受付部により死亡通知を受付けたことを条件に、当該死亡通知に該当するユーザのアカウント情報に対応付けられている縁故者情報から特定される複数の縁故者それぞれの連絡先に対して、当該ユーザの死亡についての確認を求める確認通知を送信するように構成された確認通知部と、
   前記確認通知部により前記確認通知が送信された複数の縁故者からの回答を受付けるように構成された回答受付部と、
   前記回答受付部により、前記確認通知が送信された複数の縁故者の全てから前記ユーザの死亡を認める旨の回答を受付けたことを条件に、当該複数の縁故者それぞれの連絡先に対して、当該アカウント情報に対応付けられている開示情報の伝言内容を開示可能にするように構成された開示制御部と、
   を備え、
   前記データベースは、更に、ユーザの定義に関する情報であるユーザ情報を保存し、かつ単一のユーザについて複数のアカウントに関するアカウント情報を、当該単一のユーザに関するユーザ情報と対応付けて保存可能に構成され、また、前記単一のユーザに関する複数のアカウント情報それぞれについて、前記開示情報と複数の縁故者に関する前記縁故者情報とを個別に対応付けて保存可能に構成されており、
   前記確認通知部は、前記死亡通知を受付けたことを条件に、当該死亡通知に該当するユーザの複数のアカウント情報にそれぞれ対応付けられている縁故者情報から特定される複数の縁故者それぞれの連絡先に対して、当該ユーザの死亡についての確認を求める確認通知を送信するように構成されており、
   前記開示制御部は、前記複数のアカウント情報それぞれについて、１つのアカウント情報に対応付けられた複数の縁故者の全てから前記ユーザの死亡を認める旨の回答を受付けたことを条件に、当該複数の縁故者それぞれの連絡先に対して、当該アカウント情報に対応付けられている開示情報の伝言内容を開示可能にするように構成されている、
   情報管理システム。
2. 前記データベースの開示情報には、前記ユーザの死亡後において前記伝言内容が開示されるべき期日を表す期日情報が更に含まれており、
   前記開示制御部は、前記開示情報に含まれる期日情報で示される期日が到来したときに、当該開示情報の伝言内容を開示可能にするように構成されている、
   請求項１に記載の情報管理システム。
3. 当該情報管理システムにおける管理者の権限に基づいて、前記ユーザの死亡を確定する情報である死亡確定情報の入力を受付ける確定情報受付部を更に備え、
   前記開示制御部は、前記確定情報受付部により死亡確定情報を受付けた場合、前記確認通知が送信された複数の縁故者からの回答の有無に関わらず、当該複数の縁故者それぞれの連絡先に対して、前記ユーザのアカウント情報に対応付けられている開示情報の伝言内容を開示可能にするように構成されている、
   請求項１又は請求項２に記載の情報管理システム。
4. 前記ユーザのアカウント情報に対応付けられている前記縁故者情報に該当する縁故者は、前記データベースに前記アカウント情報が登録されている他のユーザである、
   請求項１ないし請求項３の何れか１項に記載の情報管理システム。
5. 前記ユーザの身体に装着されて当該ユーザの生体信号を計測して外部に送信するように構成されたウェアラブル端末により計測された生体信号を取得し、その取得した生体信号に基づいて前記ユーザの生死状態を判定するように構成された判定部を更に備え、
   前記死亡受付部は、前記判定部による判断結果を前記死亡通知として取得するように構成されている、
   請求項１ないし請求項４の何れか１項に記載の情報管理システム。
6. 請求項１ないし請求項５の何れか１項に記載の情報処理システムにおける前記ユーザ及び前記縁故者によって用いられる通信端末に備えられたコンピュータに実行させるためのプログラムであって、
   入力された前記ユーザ情報を前記情報処理システムに登録するユーザ登録手順と、
   前記情報処理システムに登録された前記ユーザ情報に対応するアカウントについて、入力された前記アカウント情報を前記情報処理システムに登録するアカウント登録手順と、
   前記単一のユーザに関して登録されている複数のアカウント情報に対応するアカウントの中から、ログインの対象となるアカウントを当該ユーザに選択させる選択手順と、
   前記選択手順において選択されたアカウントについて、入力された前記縁故者情報を前記アカウント情報に対応付けて前記情報処理システムに登録する縁故者登録手順と、
   前記選択手順において選択されたアカウントについて、入力された前記開示情報を前記アカウント情報に対応付けて前記情報処理システムに登録する開示情報登録手順と、
   前記情報処理システムから送信される確認通知を受信する受信手順と、
   前記受信手順において受信した確認通知で示されるユーザについて、当該ユーザが死亡したことを認める操作を受付けたことを条件に、当該ユーザの死亡を認める旨の回答を前記情報処理システムに送信する送信手順と、
   前記情報処理システムによって開示可能にされた前記開示情報の伝言内容にアクセスし、その伝言内容の内容を出力する出力手順と、
   を前記コンピュータに実行させるプログラム。

Images