特許 7022249 メッセージ配信システム

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

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

(11)【特許番号】

(24)【登録日】2022-02-08

(45)【発行日】2022-02-17

(54)【発明の名称】メッセージ配信システム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20220209BHJP

【ＦＩ】

G06Q50/10

【請求項の数】 2

(21)【出願番号】P 2021152302

(22)【出願日】2021-09-17

(62)【分割の表示】P 2021014810の分割

【原出願日】2021-02-02

【審査請求日】2021-09-21

【早期審査対象出願】

(73)【特許権者】

【識別番号】520466319

【氏名又は名称】田中 繁

(74)【代理人】

【識別番号】100074734

【弁理士】

【氏名又は名称】中里 浩一

(74)【代理人】

【識別番号】100073483

【弁理士】

【氏名又は名称】八鍬 昇

(74)【代理人】

【識別番号】100164286

【弁理士】

【氏名又は名称】中里 卓夫

(72)【発明者】

【氏名】田中 繁

【審査官】池田 聡史

(56)【参考文献】

【文献】特開２０１５－５６１７６（ＪＰ，Ａ）

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

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

【文献】特開２００２－３２９０１３（ＪＰ，Ａ）

【文献】鈴木眞里子，“何を残し、何を処分する！？ 今すぐ始めるデジタル終活”，日経パソコン，日本，日経ＢＰ社，2017年02月27日，第764号，pp.40～51

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

Ｇ０６Ｑ １０／００ － ９９／００

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

【請求項1】

１または複数のコンピュータを含んだメッセージ配信システムであって、
システム利用者である第１の者の健在を確認する処理であって、当該第１の者の連絡先を記憶装置から取得し、当該連絡先に当該第１の者の健在を確認するためのメッセージを送信し、その返信を受信する健在確認処理を、周期的に実行し、
前記健在確認処理で前記返信が無かった場合、前記第１の者により事前に指定された一人または複数人の者である第２の者の連絡先を前記記憶装置から取得し、当該連絡先に、前記第１の者の生存を問い合わせ、
前記第２の者から、前記第１の者の死亡をあらわす情報を得た場合、前記第２の者に対して、前記第１の者と関係のあった者として事前に登録された一人または複数人の第３の者に対するものであって、前記第１の者によって事前に作成された第２の個別メッセージを送信して良いかを問い合わせ、
前記第２の者から前記第３の者に対する前記第２の個別メッセージの送信を抑制することを表す指令を受けた場合、前記第３の者への前記第２の個別メッセージの送信を抑止制御し、前記第２の者の連絡先のみへ第１の個別メッセージを送信することを特徴とするメッセージ配信システム。

【請求項2】

１または複数のコンピュータを含んだメッセージ配信システムであって、
システム利用者である第１の者の健在を確認する処理であって、当該第１の者の連絡先を記憶装置から取得し、当該連絡先に当該第１の者の健在を確認するためのメッセージを送信し、その返信を受信する健在確認処理を、周期的に実行し、
前記健在確認処理で前記返信が無かった場合、前記第１の者により事前に指定された一人または複数人の者である第２の者の連絡先を前記記憶装置から取得し、当該連絡先に、前記第１の者の生存を問い合わせ、
前記第２の者には、前記第１の者の家族で前記第１の者が指定した指定家族と、前記指定家族以外で前記第１の者が代理人として指定した指定代理人とからなるものであって、前記指定家族又は前記指定代理人から、前記第１の者の死亡をあらわす情報を得た場合、前記指定代理人に対して、前記第１の者によって事前に作成された前記指定家族に向けた第１の個別メッセージを送信して良いかも問い合わせ、
前記指定代理人から前記指定家族に対する前記第１の個別メッセージの送信を抑制することを表す指令を受けた場合、前記指定家族への前記第１の個別メッセージの送信も抑止制御することを特徴とするメッセージ配信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、システム利用者が死亡した場合、その後に家族・親族・友人・取引先等へメッセージを送信する技術に関する。

【背景技術】

【0002】

昨今、終活・エンディングノート等の言葉がメディアに頻繁に登場するようになった。この背景としては、いわゆる「団塊の世代」が後期高齢者に仲間入りする時代が訪れたことをあげることができる。

【0003】

加えて、核家族化が進行したため、家族のありかた、家族の絆、日本を取り巻く社会情勢や家族間における経済格差等、厳しい現実を踏まえて、家族の幸せといわゆる「争続」を回避するための前向きな行動として、これら終活が社会的に広く認知されてきたものといえる。

【0004】

その一環として、本人が希望する介護、終末期の医療、葬儀、埋葬をはじめ、財産分与の希望等を広く家族に伝える方法として「エンディングノート」の作成が有効であることが広く知られ注目を集めてきた。

【0005】

また、本願と関連のある技術として、未来に向けて特定者宛のデータを予め作成しておき、将来起きる冠婚葬祭や各種イベントで、当該特定者にその内容を個別に提供するシステムが開示されている（例えば特許文献１）。

【先行技術文献】

【特許文献】

【0006】

【文献】特許第６６５１１４６号公報

【発明の概要】

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

【0007】

エンディングメッセージを家族・親族・友人等に残す方法として、「紙ベースのエンディングノート」を作成することでも十分に有効であることは間違いない。しかしながら、多くのケースでは、これを「信頼のおける家族の一人」や、単身者の場合は「家族同様に信頼のおける友人・知人や弁護士等」に託すこととなるため、本人（以下、「故人」と表記）の死亡に際しては、託された者の失念・秘匿等により、生前からの遺志が「真正・確実・迅速」に家族・親戚縁者・友人・取引先等に到達する保証はない。

【0008】

また、エンディングノートの保管を託された者が紛失や故意または過失によって破棄するなどによりエンディングノートの存在・所在自体が不明となった場合は、故人の遺志は全く伝達・反映されない結果となる。

【0009】

そのため、財産分与に関する希望はもとより、故人の遺志（生前からの希望）をより「真正・確実・迅速」に各人へ配信することができる手段が望まれる。

【0010】

その点、一般的なエンディングノートは「本人の遺志を紙ベース等」で残すものであるため、何人でもその内容を本人の生前・死去後に知りえてしまう欠陥があり好ましくない。

【0011】

また一方で、本人死亡のときに開封する旨の依頼を添えて生前に各送達先へ書簡等を送付する方法をとっていても、送達先は本人の承諾なく随時それを開封することが可能であることから、本人死亡前にその内容を把握することは容易である。よって、財産分与に関する希望等重要な内容についても生前に特定の家族等に漏洩してしまう可能性が高い。

【0012】

また、エンディングメッセージはその性質上本人の死亡が「客観的に確認された時点」で初めて速やかに送達先へ送達されるべきものであるが、本人の死亡がどのタイミングで訪れるかは全く予測できない。昨日まで健康上全く問題のない人物であっても、突然の病死あるいは事故による急死は回避できない。

【0013】

特許文献１の技術においては、本人死亡後の未来に向けて家族などにメッセージ等を残しておくことができるが、その本人の死亡を確認するプロセスが無い。よって、特許文献１の技術においては、本人が死亡しているのかを知ることができず、結果、故人の遺志を伝達・反映する機会を逃すこととなる。

【0014】

本実施形態の目的は、死亡確認プロセスを経て死亡判定がなされた時点で、生前あらかじめ本人から電子的に預かっていたメッセージを、本人の指定した配信先（家族・親族・友人・取引先等）へ伝える技術を提供することにある。

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

【0015】

上記課題を解決するため、本発明のメッセージ配信システムは、１または複数のコンピュータを含んだメッセージ配信システムであって、システム利用者である第１の者の健在を確認する処理であって、当該第１の者の連絡先を記憶装置から取得し、当該連絡先に当該第１の者の健在を確認するためのメッセージを送信し、その返信を受信する健在確認処理を、周期的に実行し、前記健在確認処理で前記返信が無かった場合、前記第１の者により事前に指定された一人または複数人の者である第２の者の連絡先を前記記憶装置から取得し、当該連絡先に、前記第１の者の生存を問い合わせ、前記第２の者から、前記第１の者の死亡をあらわす情報を得た場合、前記第２の者に対して、前記第１の者と関係のあった者として事前に登録された一人または複数人の第３の者に対するものであって、前記第１の者によって事前に作成された第２の個別メッセージを送信して良いかを問い合わせ、前記第２の者から前記第３の者に対する前記第２の個別メッセージの送信を抑制することを表す指令を受けた場合、前記第３の者への前記第２の個別メッセージの送信を抑止制御し、前記第２の者の連絡先のみへ第１の個別メッセージを送信する。

【発明の効果】

【0016】

本発明により、死亡確認プロセスを経て死亡判定がなされた時点で、生前あらかじめ本人から電子的に預かっていたメッセージを本人の指定した配信先（家族・親族・友人・取引先等）へ伝えることができる。

【図面の簡単な説明】

【0017】

【図1】実施形態のシステム構成例を示す図である。

【図2】実施形態の基礎情報登録処理を例示するフローチャートである。

【図3】実施形態の態様により提供されるサービスを説明したパンフレットの一例を示す図である。

【図4】実施形態の本人登録画面および登録されるデータの一例を示す図である。

【図5】実施形態の指定家族登録画面および登録されるデータの一例を示す図である。

【図6】実施形態の指定家族登録画面、指定代理人登録画面の一例を示す図であり、登録される各データの一例を示す図である。

【図7】実施形態の配信先登録画面および登録されるデータの一例を示す図である。

【図8】実施形態の配信先登録画面および登録されるデータの一例を示す図である。

【図9】実施形態のシステムに登録したことを示す会員証の一例を示す図である。

【図10】実施形態の健在確認処理を例示するフローチャートである。

【図11】実施形態の健在確認処理により表示される確認画面の一例を示す図である。

【図12】実施形態の生存確認処理、および生存確認電話連絡の処理を例示するフローチャートである。

【図13】実施形態の生存確認処理により表示される確認画面の一例を示す図である。

【図14】死亡診断書の一例およびモザイク加工後の死亡診断書の一例を示す図である。

【図15】実施形態のメッセージ配信処理を例示するフローチャートである。

【図16】実施形態の各人個別に配信されるメッセージを例示する図である。

【図17】実施形態のシステムの機能ブロックの構成を例示する図である。

【図18】コンピュータの一例として、実施形態のＷｅｂサーバのハードウェア構成例を示す図である。

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

【0018】

本実施形態では、自身が死亡した際を想定し、家族・親族・友人・取引先等に送りたいメッセージ（エンディングメッセージ）を電子的に事前に預かっておき、本人の死亡が確認された時点で、本人の訃報を各配信先へ通知するとともに預かっていた各メッセージを代理送信するサービスを提供する。

【0019】

この本人の死亡の確認およびメッセージの配信に関し、本実施形態では以下の手順で行う。
１．実施形態のメッセージ配信システムは、本人へ健康状態を確認するための「健在確認メール」を定期的に自動送信する。そしてメッセージ配信システムは、この健在確認メールに対する本人の回答があるか否かを判定する。本人回答がなかった場合、メッセージ配信システムは、本人の携帯電話へＳＭＳ（Short Message Service）を用いて送信する。これは、個人のメールアドレスはプロバイダの変更・通信会社の変更・携帯電話（またはスマートフォン）の紛失・故障等により往々にして変更・喪失する場合があるため、送信先携帯電話のショートメール（ＳＭＳ）へ送信するものである。尚、ここでの送信周期は、本人の設定によるが月１回、ひと月に２回などとし、本人の健康状態によって可変とする。
２．ＳＭＳによる健在確認でも返信がない場合、本人の病死、事故死その他の状態が懸念されるため、メッセージ配信システムは、本人の指定する家族または指定代理人へ、本人の生存確認を行うためのメールを自動送信する。ここで指定家族が複数人である場合は、当該複数人同時に送信する。尚、「指定家族」とは、本人の家族のうち本人が指定・登録した家族や親族を指すものとする。また「指定代理人」とは、家族・親族・縁故者等のいない単身者等である場合に、指定家族に代えて本人が指定・登録した代理人を指すものとし、例えば、本人の信頼する友人、知人、弁護士などである。
３．この結果、いずれかの指定家族、指定代理人から「本人死亡」の回答および死亡したことをあらわす情報（申告、「死亡診断書」の撮影画像など）を受信した場合、実施形態のメッセージ配信システムは、この到着をもって本人が死亡したものと判定する。
４．このようにして本人死亡を判定した場合、実施形態のメッセージ配信システムは、事前に登録された各配信先へ、当該配信先ごとに本人が作成したメッセージをそれぞれ配信する。

【0020】

以下、図面を参照しつつ本実施形態のメッセージ配信システムの詳細について説明する。図１は、本実施形態のメッセージ配信システムのサーバ構成例を示す図である。メッセージ配信システム１００は、Ｗｅｂサーバ１１０、Ｍａｉｌサーバ１２０、ＡＰサーバ１３０、ＤＢサーバ１４０の各サーバ（コンピュータ）を有する。

【0021】

Ｗｅｂサーバ１１０は、Ｗｅｂサーバプログラムが導入されており、８０番ポート（ＨＴＴＰ）、４４３番ポート（ＨＴＴＰＳ）などの規定のポート番号で待ち受け、本人用端末１５０、指定家族用端末１６０からリクエスト情報（ＨＴＴＰ ＧＥＴ）を受信すると、これに応じてレスポンス（コンテンツ）を返信する。

【0022】

Ｍａｉｌサーバ１２０は、例えば２５番ポート（ＳＭＴＰ）で待ち受けるＭＴＡ（Mail Transfer Agent）であり、ＰＯＰ３やＩＭＡＰ４などのプロトコルを用いて、受信メールをＡＰサーバ１３０に出力する。Ｍａｉｌサーバ１２０は、ＡＰサーバ１３０からＳＭＴＰプロトコルを用いて送信指示を受けると、これに従い、Ｅ－Ｍａｉｌ（以下、「メール」や「Ｅメール」と称する）を本人用端末１５０、指定家族用端末１６０、配信対象者用端末１７０宛てに送る。

【0023】

加えて、Ｍａｉｌサーバ１２０は、他システムと連携してＳＭＳによるテキストの送受信を行う。Ｍａｉｌサーバ１２０には、当該他システムによって提供されるＡＰＩ（Application Programming Interface）が導入されており、Ｍａｉｌサーバ１２０はこのＡＰＩを介してＳＭＳによるメッセージの送受信を行う。

【0024】

ＡＰサーバ１３０は、メッセージ配信システム１００の全体を統括的に制御するサーバである。ＡＰサーバ１３０は、Ｗｅｂサーバ１１０にウェブページの表示を指示し、Ｍａｉｌサーバ１２０にメールやＳＭＳの送信を指示し、ＤＢサーバ１４０にデータの管理（＝登録、検索、更新、削除）を行わせるアプリケーションサーバである。すなわち本実施形態では、主としてＡＰサーバ１３０の指令に従い、Ｗｅｂサーバ１１０、Ｍａｉｌサーバ１２０、ＤＢサーバ１４０が動作する。

【0025】

ＤＢサーバ１４０は、システムを利用する本人によって入力された情報を体系づけて記憶するＲＤＢ（Relational Database）が構築されているサーバである。ＤＢサーバ１４０は、ＡＰサーバ１３０の指示に従い、構築された各種テーブルに対して登録、更新、参照、削除などを行う。本実施形態においては、ＤＢサーバ１４０は、顧客データテーブル２５０、配信対象者テーブル２６０、メッセージデータテーブル２７０の３つのテーブルを管理している。

【0026】

メッセージ配信システム１００は、スマートフォン、パーソナルコンピュータ、携帯電話機などの各種通信端末とインターネット１８０を介して通信可能となっている。図１では、本人が保持する本人用端末１５０、指定家族や指定代理人が保持する指定家族用端末１６０、メッセージ配信先の各人が保持する配信対象者用端末１７０を図示している。

【0027】

以下、ＤＢサーバ１４０で管理される顧客データテーブル２５０、配信対象者テーブル２６０、メッセージデータテーブル２７０の３つのテーブルについて説明する。

【0028】

顧客データテーブル２５０は、システムを利用する本人に関するデータ、信頼のある者として本人が指定する家族や指定代理人に関するデータ、および管理用データを登録するためのテーブルである。顧客データテーブル２５０には、健在か否かを本人に対して確認するための連絡先（本人の連絡先）や、本人が生存しているか否かを指定家族や指定代理人に確認するための連絡先が、少なくとも登録されている。

【0029】

配信対象者テーブル２６０およびメッセージデータテーブル２７０は、本人の死亡が確認された後にエンディングメッセージを配信するときに用いられるテーブルである。配信対象者テーブル２６０は、本人が死亡したときのメッセージ配信先である家族、親族、友人、取引先等に関するデータを登録する。またメッセージデータテーブル２７０は、本人が家族、親族、友人、取引先等の各人宛てにそれぞれ個別に作成したエンディングメッセージを管理する。尚、指定家族、指定代理人を、配信対象者としても当然よい。この場合、配信対象者テーブル２６０、メッセージデータテーブル２７０には、指定家族、指定代理人に関するデータやメッセージも登録される。

【0030】

顧客データテーブル２５０、配信対象者テーブル２６０、メッセージデータテーブル２７０の各テーブルに登録される情報を具体的に示すと、以下のとおりとなる。

【0031】

顧客データテーブル２５０には、一意となる本人ＩＤが登録され、この本人ＩＤに紐づけて本人の属性情報（氏名、生年月日、性別など）、連絡先（メールアドレス、携帯電話番号、固定電話番号、住所など）、状態フラグ、次回確認年月日が登録される。状態フラグは、本人の状態や処理の進捗状況を管理するものであり、本実施形態では、「健在」「要生存確認」「要電話連絡」「死亡確認済」「配信禁止」「配信済」の各値をとるものとする（詳細は後述する）。尚、これら以外にも「健在確認回答待ち」「生存確認回答待ち」など、待機状態であることを示す値を状態フラグの値としてとってもよい。また次回確認年月日は、健在確認を次回いつ行うかの年月日を示すものである。

【0032】

また顧客データテーブル２５０には、本人ＩＤに紐づけて、指定家族や指定代理人の属性情報（氏名、生年月日、性別、本人との関係（続柄）など）、指定家族や指定代理人の連絡先（メールアドレス、携帯電話番号、固定電話番号、住所など）、指定家族であるか指定代理人であるかの区分が登録される。また顧客データテーブル２５０には、本人ＩＤに紐づけて、本人が選定したユーザＩＤやパスワードなどの認証情報、登録年月日などの情報も登録される。

【0033】

配信対象者テーブル２６０には、一意となる配信対象者ＩＤが登録され、この配信対象者ＩＤに紐づけて、本人ＩＤ（外部キー）、配信対象者の属性情報（氏名、生年月日、性別、本人との関係（続柄）など）、連絡先（メールアドレス、携帯電話番号、固定電話番号および住所など）が登録される。

【0034】

メッセージデータテーブル２７０には、一意となるメッセージＩＤが登録され、このメッセージＩＤに紐づけて、配信対象者ＩＤ（外部キー）、本人ＩＤ（外部キー）、およびメッセージの本文が登録される。

【0035】

尚、各テーブルのレコードは、本人ＩＤと配信対象者ＩＤにより関連付けられている。

【0036】

次に、本実施形態の動作について説明する。図１に示す装置構成において、本実施形態では大別して下記の処理を実施する。
１．本人に関する情報、指定家族、指定代理人に関する情報、および配信対象者に関する情報、メッセージ本文の登録を行う「基礎情報登録処理」。
２．健在であるか否かを定期的に本人に問い合わせる「健在確認処理」。
３．健在確認が取れなくなった場合に行われる、本人が生存しているかを指定家族、指定代理人に問い合わせる「生存確認処理」。
４．死亡と判定された場合に行われる「メッセージ配信処理」。
以下、各処理の詳細について説明する。

【0037】

図２は、基礎情報登録処理の動作例を示すフローチャートである。Ｗｅｂサーバ１１０は、システムの利用を所望する者（＝本人）からのアクセスを受け付けると、申し込み画面を表示する（Ｓ１０１）。ここでの「表示」とは、Ｗｅｂサーバ１１０がＨＴＭＬデータを端末（ここでは本人用端末１５０）に送信し、当該端末がＨＴＭＬの規約に従いブラウザを介して表示する動作となる（以下同様に、このような動作を「表示」と称する）。尚、例えば図３に示すように、本サービスのカタログやパンフレットに二次元バーコード４１０を設けておき、この二次元バーコード４１０の読み取り結果として得ることができるＵＲＬを介して、アクセスを受け付けてもよい。

【0038】

この申し込み画面には、メールアドレスを入力する欄が設けられており、当該欄にメールアドレスが入力されると、ＡＰサーバ１３０は、Ｍａｉｌサーバ１２０を介して、入力されたメールアドレス宛てに申し込み確認メールを送信する（Ｓ１０２）。このメール本文には、登録情報を入力する画面用のＵＲＬが記述されており、規定時間内に当該ＵＲＬにアクセスがあると（Ｓ１０３：Ｙｅｓ）、Ｗｅｂサーバ１１０は登録情報入力画面を表示する（Ｓ１０４）。

【0039】

ここで表示される登録情報入力画面の一例を図４に示す。システムの利用を所望する本人は、当該画面を用いて、氏名などの属性情報やメールアドレスなどの連絡先を入力する。ＡＰサーバ１３０は、未入力項目があるか否か、入力された値の型や桁が正しいかの適式判定を行い（Ｓ１０５）、適式な値が入力されるまで登録画面を繰り返し表示する（Ｓ１０５：Ｎｏのループ）。適式な値が入力されると（Ｓ１０５：Ｙｅｓ）、ＡＰサーバ１３０は、一意となる本人ＩＤを発行し（Ｓ１０６）、当該本人ＩＤとともに、入力された情報を顧客データテーブル２５０に登録する。またこの際、ＡＰサーバ１３０は、状態フラグが「健在」となるように設定し、次回確認日を例えば１週間後に設定して、これらも本人ＩＤに対応付けて登録する。

【0040】

本人ＩＤを発行した後、次いでＷｅｂサーバ１１０は、指定家族に関する情報や指定代理人に関する情報を入力するための画面を表示する（Ｓ１０７）。

【0041】

図５（Ａ）、図５（Ｂ）、および図６（Ａ）は、指定家族に関する情報を入力するための画面であり、本人との続柄がそれぞれ長男、妻、次男とする場合の画面表示例である。そして図６（Ｂ）は、指定代理人に関する情報を入力するための画面表示例である。ここでは、指定家族や指定代理人の属性情報や連絡先、メッセージ本文が入力される。入力された情報のうち、属性情報や連絡先は、顧客データテーブル２５０に登録される。そして配信対象者ＩＤがＡＰサーバ１３０により発行されて、当該配信対象者ＩＤ、本人ＩＤ、属性情報、および連絡先が配信対象者テーブル２６０に登録される。加えて、メッセージＩＤがＡＰサーバ１３０により発行され、当該メッセージＩＤ、配信対象者ＩＤ（外部キー）、本人ＩＤ（外部キー）、およびメッセージの本文がメッセージデータテーブル２７０に登録される。尚、指定家族や指定代理人を配信対象者として登録する処理については、当該Ｓ１０７ではなく、この次のＳ１０８で行ってもよい。

【0042】

指定家族が１名のみである場合において、万一、メールアドレス等の変更・喪失等があった場合は後述の死亡判定の際に重大な支障となる。よって指定家族は複数人登録するのが好ましい。一方、指定代理人を複数人とする場合、本人が死亡してからメール配信が開始するまでの間、指定代理人相互の間で利害関係や意見の相違が発生するおそれがある。よって、指定代理人については１名限定の指定・登録とするのが好ましい。これに加え、指定代理人に関しては、後述のとおり本人死亡時に「死亡診断書」を入手する必要があるが、これを入手し得ない者の指定・登録は極力回避するのが好ましい。

【0043】

次いでＷｅｂサーバ１１０は、配信対象者に関する情報を入力するための画面を表示する（Ｓ１０８）。

【0044】

図７（Ａ）は、指定家族として指定されなかった家族や親族に関する情報を入力するための画面表示例であり、図７（Ｂ）は友人に関する情報を入力するための画面表示例である。そして図８は、知人や取引先に関する情報を入力するための画面表示例である。いずれにおいても、各人の属性情報や連絡先、メッセージの本文が入力される。入力されると、ＡＰサーバ１３０は配信対象者ＩＤを発行し、配信対象者ＩＤ、本人ＩＤ、属性情報、連絡先を対応付けて配信対象者テーブル２６０に登録する。加えて、ＡＰサーバ１３０はメッセージＩＤを発行し、メッセージＩＤ、配信対象者ＩＤ（外部キー）、本人ＩＤ（外部キー）、およびメッセージの本文を対応付けてメッセージデータテーブル２７０に登録する。

【0045】

尚、図７（Ａ）に示すような、当該配信対象者に対しては郵送するかを示すチェックボックスを画面内に設けてもよい。この場合、チェックボックスが選択されたか否かを示すフラグデータも対応付けて、配信対象者テーブル２６０に登録される。

【0046】

以上の動作により基礎登録処理が行われるが、このように登録された後は、図９に例示する会員証が発行されてもよい。図９の会員証では、メッセージ配信システム１００の名称、会員番号（本人ＩＤでもよい）、氏名、入会日や有効期限が明記されている。二次元バーコード９０１は、緊急連絡先用のＵＲＬがコード化されたものであり、当該会員証を拾得した第三者がこれを読み取ることで、メッセージ配信システム１００の運営側と連絡をとることができる。また二次元バーコード９０２は、本人ＩＤに紐づけられたマイページのＵＲＬがコード化されたものである。この二次元バーコード９０２を本人用端末１５０で読み取ることで、Ｗｅｂサーバ１１０は、ログイン認証を行った後に図４～図８の各画面を本人用端末１５０に表示させ、登録内容の更新処理を受け付ける。

【0047】

引き続き、健在確認処理について説明する。メッセージ配信システム１００は、顧客データテーブル２５０に登録されている情報に基づき、システム利用者である本人に対し健在を確認するメッセージを定期的に送信する。この健在確認処理について、図１０のフローチャートを用いて説明する。

【0048】

ＡＰサーバ１３０は、スケジューリングされた時刻になると、健在確認メールを本人用端末１５０に送信する（Ｓ２０１）。本実施形態では、１日に１回程度のスケジュールで、この健在確認処理を行うものとする。またＳ２０１の際、ＡＰサーバ１３０は顧客データテーブル２５０を参照し、状態フラグが「健在」であり、且つ「次回確認年月日」が本日に達しているレコードを対象に、Ｅメールによるメッセージの送信を行う。

【0049】

ここで送信されるメッセージは定型文であり、健在を確認するための画面を指定するＵＲＬ（Ｗｅｂサーバ１１０のＵＲＬ）が含まれている。当該ＵＲＬが選択されると、Ｗｅｂサーバ１１０は図１１に示す健在確認画面を表示し、利用者本人からの選択を待ち受ける（Ｓ２０２）。問題なく元気である旨を示すボタン１０１０が選択されると（Ｓ２０２：Ｙｅｓ）、ＡＰサーバ１３０は、状態フラグが「健在」となるように、また「次回確認年月日」を１か月後の年月日となるように、顧客データテーブル２５０の該当レコードを更新して処理終了となる。この場合、当該本人に対しては１か月後に改めて健在確認メッセージが送信される。

【0050】

また図１１の健在確認画面において、欄１０２０内のいずれかが選択される場合（Ｓ２０２：Ｙｅｓ）、ＡＰサーバ１３０は、状態フラグが「健在」となるように、また「次回確認年月日」を半月後の年月日となるように、顧客データテーブル２５０の該当レコードを更新して処理終了となる。この場合、当該本人に対しては半月後に改めて健在確認メッセージが送信される。図１１の欄１０３０内のいずれかが選択されても同様に、状態フラグを「健在」とし、「次回確認年月日」を更新して終了となるが、この場合は、「次回確認年月日」は１週間後の年月日となるように更新される。

【0051】

このように、同じ健在状態でも本人の健康状態に応じて「次回確認年月日」を変えることができる。すなわち、健在確認処理の実行周期を、本人の健康状態に応じて可変とすることができる。尚、ここでの実行周期はあくまでも一例である。

【0052】

一方、健在確認のメールを送信しても、規定時間（例えば１日程度）に上記のような返信が無い場合（Ｓ２０２：Ｎｏ）、ＡＰサーバ１３０は、Ｍａｉｌサーバ１２０に指示してＳＭＳによる健在確認メールの送信を行う（Ｓ２０４）。ここで送信されるメッセージは、上記Ｓ２０１とほぼ同等のものとする。そしてＡＰサーバ１３０は、返信の有無を待ち受け（Ｓ２０５）、返信があった場合は、本人の回答（健康状態）に応じて実行周期を変更する（Ｓ２０５：Ｙｅｓ、Ｓ２０６）。このＳ２０５、Ｓ２０６の動作は、Ｓ２０２、Ｓ２０３と同様であるため、説明を割愛する。

【0053】

Ｓ２０５において、規定時間（例えば１日程度）に返信が無い場合（Ｓ２０５：Ｎｏ）、ＡＰサーバ１３０は状態フラグを「要生存確認」にして（Ｓ２０６）、図１０に示す処理を終了する（処理は生存確認処理に進む）。尚、ＡＰサーバ１３０は、ここで本人ＩＤ、本人氏名、本日の年月日を対応付けて記したファイルを生成し、一時的に記憶する。

【0054】

引き続き、上記の健在確認処理において本人から返信が無かった場合に行われる生存確認処理について説明する。図１２は、生存確認処理の一連の動作例を示すフローチャートであり、図１２（Ａ）はメールによる自動配信処理であり、例えば１日１回の頻度で実行されるものとする。そして図１２（Ｂ）はオペレータによる電話連絡についての動作例をそれぞれ示している。

【0055】

まず図１２（Ａ）の動作について説明する。ＡＰサーバ１３０は、スケジューリングされた時刻になると、生存確認メールを指定家族用端末１６０に送信する（Ｓ３０１）。ＡＰサーバ１３０は、顧客データテーブル２５０を参照し、状態フラグが「要生存確認」となっているレコードを抽出し、このレコード内の指定家族用のメールアドレスや指定代理人のメールアドレスを取得する。そしてＡＰサーバ１３０は、これらのメールアドレスを宛先にして、Ｍａｉｌサーバ１２０にメールの送信を指示する。また、指定家族が複数人いる場合は、本実施形態では全てのアドレスを指定して同時に一斉送信を行うものとする。このメッセージには、例えば以下のような定型文が記されているものとする。
「ＸＸ様から当システムへのご連絡がＸ月Ｘ日以降途絶えておりますので状況をお知らせください。」
ＡＰサーバ１３０は、Ｓ２０６で作成された一時ファイルから本人氏名や年月日を取得し、これらを事前に用意したテンプレートに組み入れて送信用のメッセージを作成する。

【0056】

また、ここで送信されるメッセージには、本人の生存を確認するための画面のＵＲＬが含まれている。当該ＵＲＬが選択されると、Ｗｅｂサーバ１１０は図１３に示す生存確認画面を表示して、指定家族や指定代理人からの選択を待ち受ける（Ｓ３０２）。ＡＰサーバ１３０は、死亡を示すチェックボックス１３０１が選択されたか、またはチェックボックス群１３０３の中のいずれかの項目が選択されたかを判定することで、生存判定を行う（Ｓ３０２：Ｙｅｓ、Ｓ３０３）。

【0057】

ここでチェックボックス群１３０３の中のいずれかの項目が選択された場合、ＡＰサーバ１３０は、本人は生存しているものとして扱い（Ｓ３０３：Ｙｅｓ）、状態フラグを「健在」にし、「次回確認年月日」には例えば半月後の年月日を設定して、顧客データテーブル２５０に対して更新処理を行う（Ｓ３０４）。これにより、当該本人は引き続き図１０の健在確認処理の対象人となる。

【0058】

死亡を示すチェックボックス１３０１が選択されている場合、ＡＰサーバ１３０は、本人は死亡したものとして扱い（Ｓ３０３：Ｎｏ）、項目１３０２の値が死亡診断書の送信了承を示すものであるか、辞退を示すものであるかを判定する（Ｓ３０６）。辞退を示すものである場合（Ｓ３０６：Ｙｅｓ）、ＡＰサーバ１３０は、この申告（死亡を示すチェックボックス１３０１にチェック有り、且つ死亡診断書の送信辞退）をもって、本人の死亡を確定させ、状態フラグが「死亡確認済」となるように更新する（Ｓ３０７）。尚、このような申告は、本人の死亡をあらわす情報の一つの態様例である。

【0059】

尚、この死亡診断書の辞退については、指定家族の中の規定人数以上（例えば２／３以上）の確認、または指定代理人の確認がとれた場合、本人の死亡を確定させる、との実装にすることも可能である。このようにすることで、本人死亡の誤判定を防ぐことができる。

【0060】

Ｓ３０６が「了承」である場合（Ｓ３０６：Ｎｏ）、ＡＰサーバ１３０は、死亡診断書を撮像した画像をＷｅｂサーバ１１０が受信したかを判定する（Ｓ３０８）。指定家族もしくは指定代理人は、指定家族用端末１６０のカメラ機能を用いて、本人の死亡診断書を事前にもしくはその場で撮像し、この撮像画像をＷｅｂサーバ１１０に送信する。この際、指定家族もしくは指定代理人は、図１３に示すボタン１３０４を押下し、死亡診断書の撮像画像を選択してＷｅｂサーバ１１０にアップロードする。ＡＰサーバ１３０は、Ｗｅｂサーバ１１０にポーリングして問い合わせ、死亡診断書の撮像画像が規定フォルダにあるか否かを判定する。これにより、Ｓ３０８の受信判定が行われる。

【0061】

尚、画像内の特定箇所に網掛けやモザイク加工を施すことができるカメラアプリケーションを提供し、これを用いて撮像してもよい。図１４（Ａ）は撮像対象となる死亡診断書、図１４（Ｂ）は当該カメラアプリケーションで撮像するときの様子、図１４（Ｃ）はモザイク加工後の撮像画像を例示した図である。このような網掛けやモザイク加工を行うアプリケーションを導入することで、必要以上の情報が映り込むのを防止できるため、プライバシー保護の観点から有効である。尚、撮影後の画像をモザイク無しでそのまま送信するか、モザイク加工するかを選択可能としてもよい。

【0062】

Ｓ３０８での判定の際、ＡＰサーバ１３０は、死亡診断書の撮像画像などの何らかの画像データがＷｅｂサーバ１１０の規定フォルダに存在することをもって、本人の死亡を確定さてもよい（Ｓ３０８：Ｙｅｓ）。また、Ｓ３０８での判定の際、例えばオペレータなどが撮像画像を目視で確認し、正規の死亡診断書であるかを判断してもよい。もしくは、ＡＰサーバ１３０が、ＯＣＲ（Optical Character Recognition）の技術を用いて本人の死亡診断書であるかを判定してもよい。この場合、ＡＰサーバ１３０は、ＯＣＲの技術を用いて撮像画像から文字を抽出し、例えば「死亡診断書」の文字列、本人の氏名、医師の署名が抽出されるかを判定する。この際、「死亡診断書」の文字列は規定文であることから問題無く抽出される。また本人の氏名については、手書きであるため多少の誤検知は起こり得るが、システム内に既に本人氏名が登録されていることから、これと比較することで判定することができる。しかしながら、医師の署名については、システム内に情報が存在せず、加えて手書きであることが多いため、正しく判定することができない。この対処として、例えば「氏名」の文字列や「署名」の文字列を撮像画像内から抽出し、当該文字列の右側付近に氏名に相当するものがあるかを判定したり、撮像画像の下側付近に氏名相当のものが存在するか判定したりするなど、死亡診断書の書式に基づいた判定を行ってもよい。また、可能であれば死亡した年月日を読み取ってもよい。

【0063】

Ｓ３０８が肯定判定の場合、すなわち、本人の死亡を証明する書類を撮像した撮像画像（＝本人の死亡をあらわす情報）を受信した場合（Ｓ３０８：Ｙｅｓ）、ＡＰサーバ１３０は、本人の死亡を確定し、状態フラグを「死亡確認済」となるように更新する（Ｓ３０７）。またＳ３０７においては、本人ＩＤ、本人氏名とともに、死亡した日など、図１３の画面を介して得られた情報も一緒に一時ファイルに記録される。

【0064】

一方、撮像画像を規定時間内に受信しなかった場合（Ｓ３０８：Ｎｏ）、ＡＰサーバ１３０は、状態フラグを「要電話連絡」となるように更新し（Ｓ３０９）、図１２（Ａ）の処理を終了する。「要電話連絡」のフラグは、システム運営側のオペレータが直接電話により連絡をとる必要がある場合に付されるものである。

【0065】

尚、Ｓ３０２で指定家族もしくは指定代理人から返信が無かった場合も同様に（Ｓ３０２：Ｎｏ）、ＡＰサーバ１３０は、状態フラグを「要電話連絡」と更新し（Ｓ３０９）、図１２（Ａ）の処理を終了する。

【0066】

引き続き図１２（Ｂ）に示すオペレータによる電話連絡の動作について説明する。本実施形態では、指定家族や指定代理人からメール等による連絡が無い場合や、死亡診断書による確認がとれない場合、指定家族や指定代理人の各人に直接話をする必要があるものとして、例えば１日に１回の頻度で図１２（Ｂ）の処理が行われる。

【0067】

ＡＰサーバ１３０は、顧客データテーブル２５０内で状態フラグが「要電話連絡」となっているレコードを抽出し、この情報をモニタに表示するなどしてオペレータに連絡先を通知する（Ｓ３５１）。ここでの連絡先は、例えば指定家族や指定代理人の電話番号である。

【0068】

オペレータは指定家族や指定代理人に電話をかけるが、連絡がとれない場合（Ｓ３５２：Ｎｏ）、処理は終了となる。尚、このように連絡がとれない場合は状態フラグの変更はなく、「要電話連絡」のままであることから、次回図１２（Ｂ）の処理が行われる際には、同じ指定家族や指定代理人に電話連絡をすることとなる。

【0069】

指定家族や指定代理人と電話による連絡をとることができ（Ｓ３５２：Ｙｅｓ）、且つ本人の生存を確認できた場合（Ｓ３５３：Ｙｅｓ）、ＡＰサーバ１３０は、オペレータの操作により状態フラグを「健在」にし、「次回確認年月日」を例えば半月後として、顧客データテーブル２５０を更新する（Ｓ３５４）。これにより、当該本人は引き続き図１０の健在確認処理の対象人となる。

【0070】

オペレータの口頭確認の結果、本人が死亡している場合（３５３：Ｎｏ）、処理は図１２（Ａ）のＳ３０６に進み、死亡診断書の送信を辞退するかの確認動作となる。尚、この際はオペレータより口頭またはメールにより図１３（１３０２）への入力および死亡診断書の送信を促す。この実装により、口頭のみでは残らない死亡確認のエビデンスを、電子データとして残すことができる。死亡診断書の送信を辞退の場合（Ｓ３０６：Ｙｅｓ）、ＡＰサーバ１３０は、この申告（死亡を示すチェックボックス１３０１にチェック有り、且つ死亡診断書の送信辞退）をもって、本人の死亡を確定させ、状態フラグが「死亡確認済」となるように更新する（Ｓ３０７）。辞退でない場合（Ｓ３０６：Ｎｏ）、オペレータは死亡診断書を受信した場合（Ｓ３０８：Ｙｅｓ）、処理はＳ３０７に進む。以降の動作は上記のとおりである。

【0071】

尚、電話による口頭連絡を行った場合において、その後放置されて図１３への入力および死亡診断書の送信が無い場合、ペンディングフラグなどの別フラグを立てて、オペレータによる口頭・メール（自動送信を含む）により死亡通知画面への入力督促を一定頻度（月１回程度）で継続して行ってもよい。そして、指定家族・指定代理人による放置状態が続いた場合は、会員有効期間の満了・更新処理の際に、本人による更新確認（不図示の更新申し込みボタンの押下）が無いことをもって、当サービスの提供が終了され、サービスの提供を終了してもよい。

【0072】

尚、図１２（Ａ）、（Ｂ）に示すメール・電話による連絡が取れない場合や、もしくはメール・電話による連絡に替えて、郵送や電報等の方法を用いてもよい。郵送や電報等の方法を用いる場合も、図１２（Ｂ）に相当する手続きを行うことで対処することができる。

【0073】

本人の死亡を確定した場合、処理は図１５に示すメッセージ配信処理に進む。引き続きこの図１５のフローチャートについて説明する。尚、このメッセージ配信処理も１日１回の頻度で実行するようにスケジューリングされている。

【0074】

ＡＰサーバ１３０は、顧客データテーブル２５０内で状態フラグが「死亡確認済」となっているレコードを検索し、検索されたレコード内の指定家族、指定代理人用のメールアドレスを抽出する。そしてＡＰサーバ１３０は、Ｍａｉｌサーバ１２０を介して、当該指定家族、指定代理人用のメールアドレス宛てに、配信対象者に個別メッセージを配信してもよいかを問い合わせるメッセージを送信する（Ｓ４０１）。この際、全ての指定家族、指定代理人に問い合わせメッセージを送信する。

【0075】

配信を禁止する旨の返信が一定期間内（例えば数日程度）に指定家族全員または指定代理人からあった場合（Ｓ４０２：Ｙｅｓ）、ＡＰサーバ１３０は、状態フラグを「配信禁止」とするように、顧客データテーブル２５０を更新し（Ｓ４０３）、全ての処理が終了となる。すなわち、指定家族全員または指定代理人が個別メッセージの配信を希望しなかった場合、ＡＰサーバ１３０は、この旨を示す「配信禁止」の値を状態フラグに残して、指定家族または指定代理人以外への配信を実行しないように抑止制御する。尚、配信を復帰させたい場合は、オペレータの操作により状態フラグを「死亡確認済」に戻すことで、Ｓ４０１からやり直すことができる。

【0076】

ここで、故人の伝達遺志の尊重および法定相続の観点から、指定家族全員および指定代理人に対する「配信禁止」は行わないものとする。例えば、「父親（故人）が、指定家族である弟に対してうかつなメッセージを配信するのは兄として不利益となる」などと兄が思う場合、当該兄としては配信禁止を希望する。しかしながら、このような状況においても、故人の伝達遺志の尊重および弟などの指定家族は法定相続人に該当する可能性が高いことから、ＡＰサーバ１３０は指定家族全員および指定代理人にはメッセージを配信する。なお、指定代理人も弁護士などの相続に関係するものとなり得ることから、指定家族と同様に配信禁止は行わないものとする。

【0077】

配信を禁止する旨の返信が一定期間内に無かった場合（Ｓ４０２：Ｎｏ）、ＡＰサーバ１３０は、配信対象者テーブル２６０から配信対象者ＩＤ、およびメールアドレスを取得し、メッセージデータテーブル２７０から、配信対象者ＩＤに対応するメッセージの本文を取得することで、配信対象者の各々に個別のメッセージを送信する（Ｓ４０４、Ｓ４０５：Ｎｏのループ）。

【0078】

全員に配信し終えた場合（Ｓ４０５：Ｙｅｓ）、ＡＰサーバ１３０は、状態フラグを「配信済」と更新し（Ｓ４０６）、全ての処理が終了となる。

【0079】

ここで、メッセージ配信処理により配信されるメッセージを図１６に例示する。図１６（Ａ）は指定家族（妻）宛て、図１６（Ｂ）は友人宛てとなっている。いずれのメッセージも、メッセージデータテーブル２７０に登録されているメッセージの本文に定型文を付記したものである。定型文について、ＡＰサーバ１３０は、Ｓ３０７で作成した一時ファイルから、亡くなった本人の氏名や死亡の日を取得し、これらを事前に用意したテンプレート文に組み入れて、図１６に示す定型文を作成する。尚、定型文については、図１６に示すように、指定家族用のものと配信対象者用のものとで異ならせてもよい。

【0080】

また一方で、例えば配信エラーが発生するなど、メールによる配信ができない場合、オプションにより郵送や電報等の手段を用いてもよい。すなわち、図７（Ａ）に示す「郵送希望」のチェックボックスにマークが付されている場合は郵送や電報等の手段を用いる、とすることで、エンディングメッセージを確実に伝えたい人とそうでない人との差別化を図ることができる。

【0081】

以上が本実施形態に関する一連の処理についての説明であるが、ここで、各処理を実行する機能ブロックを図１７に例示するとともに、この機能ブロックに沿った説明を付記する。

【0082】

メッセージ配信システム１００は、基礎事項登録部２１０、健在確認部２２０、生存確認部２３０、配信部２４０を有する。これら各機能部は、メッセージ配信システム１００に含まれる複数のコンピュータ（＝Ｗｅｂサーバ１１０、Ｍａｉｌサーバ１２０、ＡＰサーバ１３０、ＤＢサーバ１４０）により実現される。尚、負荷分散や耐障害性を向上させることを目的にして冗長化構成を採用してもよいし、各機能を集約して１つもしくは２～３台程度の少数のコンピュータのみで実現してもよい。

【0083】

基礎事項登録部２１０は、システム利用者である第１の者（＝本人）に関する情報、当該第１の者の指定する者である第２の者（＝指定家族、指定代理人）に関する情報、当該第１の者と関係のある者である第３の者（＝家族、親族、友人、知人、取引先などの配信対象者）に関する情報、第２の者および第３の者ごとの個別メッセージを登録するための入力画面（図４～図８）を表示する。

【0084】

また基礎事項登録部２１０は、この入力画面を介して入力された各情報を、各々対応付けて記憶装置に記憶する（＝ＤＢサーバ１４０に登録する）。尚、第２の者、第３の者は、それぞれ一人であってもよいし、複数人であってもよい。

【0085】

健在確認部２２０は、第１の者の健在を確認する健在確認処理を、周期的に実行する。すなわち健在確認部２２０は、当該第１の者の連絡先を記憶装置から取得し、当該連絡先に当該第１の者の健在を確認するためのメッセージを送信し、その返信を受信する、との一連の処理を、周期的に実行する。

【0086】

生存確認部２３０は、健在確認処理で返信が無かった場合、第２の者の連絡先を記憶装置から取得し、当該連絡先に、第１の者の生存を問い合わせる。また生存確認部２３０は、第２の者から、第１の者の死亡をあらわす情報を得たかを判定する。尚、上記の説明では、「第１の者の死亡をあらわす情報」とは、第２の者からの申告（＝死亡を示すチェックボックス１３０１にチェック有り、且つ死亡診断書の送信辞退）、もしくは第１の者の死亡を証明する書類（＝例えば死亡証明書）を撮像した撮像画像であるものとして説明した。

【0087】

配信部２４０は、第２の者から、第１の者の死亡をあらわす情報を得た場合、第３の者の連絡先を記憶装置から取得し、第３の者各々に向けた個別メッセージを、当該第３の者の連絡先宛てにそれぞれ送信する。

【0088】

最後に、本実施形態に係るコンピュータの一例として、Ｗｅｂサーバ１１０のハードウェア構成例を図１８に示す。尚、Ｍａｉｌサーバ１２０、ＡＰサーバ１３０、ＤＢサーバ１４０や各端末（１５０、１６０、１７０）も、図１２に示すものと同じ構成を有している。

【0089】

Ｗｅｂサーバ１１０は、一般的なコンピュータと同等のハードウェア資源を備えている。したがって、ＣＰＵ１１１０、ＲＡＭ１１２０、ＲＯＭ１１３０、ストレージ１１４０、および通信Ｉ／Ｆ１１５０がバス１１６０を介して接続されている。通信Ｉ／Ｆ１１５０は、有線または無線で機器間を通信するためのインタフェースを構成し、ＡＰサーバ１３０などの外部機器と接続する。

【0090】

ＣＰＵ１１１０は演算処理装置であり、Ｗｅｂサーバ１１０全体の動作を制御する。ＲＡＭ１１２０は揮発性記憶装置であり、ＲＯＭ１１３０は不揮発性記憶装置である。そしてストレージ１１４０は、ＨＤＤやＳＳＤなどの大容量記憶装置（補助記憶装置）である。

【0091】

このハードウェア構成において、ＲＯＭ１１３０やストレージ１１４０に格納されたプログラム１１４１は、ＲＡＭ１１２０にロードされ、ＣＰＵ１１１０がこれを演算実行する。この実行により、種々の機能モジュールを含むソフトウェア制御部が構成される。このようにして構成されたソフトウェア制御部と、上記の構成を含むハードウェア資源との組み合わせによって、図１７に示す機能ブロックが構成される。

【0092】

本実施形態のメッセージ配信システム１００は、以下の優位性を有している。
本人の死亡を確認するまでは、メッセージ（エンディングメッセージ）が配信されず、且つ、家族および第三者等がその内容を本人存命中に知る手段も原則的に無いため、秘密事項の漏洩を抑止することができる。

【0093】

そのため、重要遺品となるＰＣ（パソコン）のパスワード、銀行預金口座番号、土地建物リストその他の資産目録、遺言書（法で定める遺言書）の預け先等、相続発生時に重要な要素となる機密事項を安心してメッセージとして預けることができる。また、本人死亡後に、本人所望の相手先にメッセージが送信されることで、確実・円満な相続および死亡後の諸手続きを円滑に執り行うことができる。

【0094】

この背景として、通帳すらも電子化される時代になったため本人が死亡した場合パスワードが分からなければ遺品のＰＣも開くことができず、どこの銀行にいくら預金があるのかさえ遺族でも把握できない事態が多々発生していることにある。加えて、本人が生前にネット上で行った契約行為（定期購読・定期購入等反復継続する契約）を解約することもできない状態に陥る。本実施形態のように、各種契約の内容や解約に必要な連絡先（場合によりパスワード）を然るべき者に自動送信されることは、極めて有効な対策となる。

【0095】

また、上記実施形態の態様に対し、以下の事項を追加し、または以下の事項に変更することも可能である。

【0096】

上記の基礎登録処理が終了した後は仮登録の状態としておき、会費支払いのステップ（課金システム）を実行して入金が確認でき次第、本登録を行う実装でもよい。またこの際、メール作成・登録において悪質な業務妨害登録を防止するため、登録数を原則１００件に制限し、１００件を超える登録はオプション料金にて追加可能としてもよい。

【0097】

システム利用者の本人の設定により、指定家族、指定代理人の優先順位を設け、この順で生存確認（図１２（Ａ）の処理）を行ってもよい。この場合、順次確認して得られた返結果により死亡確認が取れた段階で、本人の遺志に基づきメッセージ（エンディングメッセージ）を各人に配信する。

【0098】

また、各処理における返信の確認（Ｓ２０２、Ｓ３０２、Ｓ４０２）は、Ｗｅｂ画面を介したものとしているが、Ｅメールでの送信の際に開封確認設定をしておく手法や、空メールなどの返信の有無を確認する手法でも構わない。また、システム側からの連絡手段やメッセージの送信手段として、ＥメールやＷｅｂなどの電子的な手段以外にも、電話、郵送、電報等の手段（法的に可能であれば宅配メール便等も含む）を用いてもよい。

【0099】

メッセージの一斉配信に関し、本実施形態においては、Ｅメールなどの電子的手段のみを原則とし、郵送（電報や電話でもよい）によるメッセージの配信（伝達）はオプションとしている。郵送オプションの未契約会員（基本契約のみの会員）が郵送希望メッセージを登録しようとした場合は、オプション契約を追加するか否かの意思確認画面を表示した上で、郵送オプションの追加契約および支払いステップに移行するものとする。尚、当該郵送オプションは基本契約と同一の有効期間とし、オプション未契約会員が期中に郵送オプションを追加した場合は、その時点からオプション契約ありの会員へ移行する。

【0100】

例えば本人用端末１５０、指定家族用端末１６０に、専用アプリケーションを導入し、当該アプリケーションを介して、連絡、健在確認、生存確認などを行ってもよい。

【0101】

本人のなりすまし対策として、本人の登録時に運転免許証、健康保険証等の複写物や撮像画像を要求する実装を加えても構わない。また、紙のマークシートなどを用いてシステムに登録する機能を加えてもよい。

【0102】

定型メールを用意するほか、不適切ワードをフィルタリングして誹謗中傷メールを送信しないようにする実装を加えてもよい。

【0103】

年賀状作成アプリケーション等に付随される住所録（メールアドレス・電話番号等）の既存データが存在する場合は、その取り込みによりメッセージ作成・登録時の省力化を図ってもよい。

【0104】

本実施形態では、メッセージ（テキスト）のみに言及しているが、写真や動画、ファイル等を添付して配信する実装でもよい。また当該写真や動画、ファイル等を他のクラウドシステム（配信システム）に保存しておき、このクラウドシステムのＵＲＬなどをメッセージに付して配信してもよい。

【0105】

指定家族または指定代理人から得る死亡確認書類としては、「死亡診断書」以外であってもよい。すなわち、本人死亡を確認できる書類であればよく、行政上の書類であれば信ぴょう性が高くなるため好ましい。

【0106】

個別メッセージの一斉配信の抑止に関し、指定家族間での意見のバラツキは争いの原因となるため、指定家族においては上記のとおり全員一致による「配信禁止」を原則としている。これに対し、指定家族のうちのいずれか一人でも個別メッセージの一斉配信を希望しない場合は、メッセージの一斉配信を行わない、とする実装でもよい。また、多数決により一斉配信するか否かを決定し、この決定に基づき一斉配信の有無を制御してもよい。この一斉配信するか否かに関しては、「配信停止希望ボタン」を図１４の確認画面に設け、このボタンの押下状態に応じてメッセージを配信するか抑止するかを決定する実装でもよい。

【0107】

図１５に示すメッセージ配信処理内で行われる配信の抑止について、指定家族と指定代理人とで立場の差異を設けてもよい。例えば指定家族と指定代理人が定められている場合、指定代理人の方が指定家族よりも強い立場となるものとする。

【0108】

このように立場に差異を設ける場合、指定代理人は、指定家族中に配信の抑止を求める者がいないかの確認をし、配信の抑止を求める者がいれば配信しないようにするなど、メール配信の許可／不許可の最終判断を指定代理人が行えるようにしてもよい。但し、指定代理人が、弁護士など相続の問題を解決するため相続受権を得ている者であり、当該抑止行為について予め本人から特権が与えられた場合に限るものとする。このような実装にすることで、相続時に、指定家族間で揉めることを抑制するために、事前に指定代理人が指定家族間の調整を行い、相続を円滑に行うことができる。

【0109】

上記実施形態では、指定家族と指定代理人の両方を指定することを要し、もしくは併存できるものとしているが、指定家族と指定代理人の一方のみを指定（併存不可）とする実装でもよい。これは、「両方併存が前提の場合、本人が指定家族以外の誰を指定代理人に選択するか悩む」ことを防止するためである。

【0110】

本実施形態では装置内部に発明を実施する機能が予め記録されている場合について説明したが、これに限らず、同様の機能をネットワークから装置にダウンロードしてもよいし、同様の機能を記録媒体に記憶させたものを装置にインストールしてもよい。記録媒体としては、ＣＤ－ＲＯＭ、ＤＶＤ等、プログラムを記憶でき、かつ装置が読み取り可能な記録媒体であれば、いずれの形態であってもよい。またこのように予めインストールやダウンロードにより得る機能は、装置内部のＯＳ（オペレーティング・システム）等と協働して、その機能を実現させてもよい。

【0111】

以上、本実施形態により、死亡確認プロセスを経て死亡判定がなされた時点で、生前あらかじめ本人から電子的に預かっていたメッセージを本人の指定した配信先（家族・親族・友人・取引先等）へ伝えることができる。

【0112】

本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施することができる。そのため、前述の実施形態はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には、なんら拘束されない。さらに、特許請求の範囲の均等範囲に属する全ての変形、様々な改良、代替および改質は、すべて本発明の範囲内のものである。

【符号の説明】

【0113】

１００：メッセージ配信システム、１１０：Ｗｅｂサーバ、１２０：Ｍａｉｌサーバ、
１３０：ＡＰサーバ、１４０：ＤＢサーバ、１５０：本人用端末、
１６０：指定家族用端末、１７０：配信対象者用端末、１８０：インターネット、
２１０：基礎事項登録部、２２０：健在確認部、２３０：生存確認部、
２４０：配信部、２５０：顧客データテーブル、２６０：配信対象者テーブル、
２７０：メッセージデータテーブル、

【要約】      （修正有）

【課題】死亡確認プロセスを経て本人の死亡判定がなされた時点で、電子的に預かっていたメッセージを本人の指定した家族・親族・友人・取引先等へ伝えることができるメッセージ配信システムを提供する。
【解決手段】メッセージ配信システム１００は、Ｗｅｂサーバ１１０、Ｍａｉｌサーバ１２０、ＡＰサーバ１３０、ＤＢサーバ１４０と、を有する。ＡＰサーバ１３０は、Ｗｅｂサーバ１１０にウェブページの表示を指示し、Ｍａｉｌサーバ１２０にメールやＳＭＳの送信を指示し、ＤＢサーバ１４０にデータの管理（登録、検索、更新、削除）を行わせるアプリケーションサーバである。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】