JP2023135450A - 予約手続処理システム - Google Patents

Abstract

【課題】ユーザ利用機関以外の第三者にユーザの希望手続内容を知られることがなく予約手続処理を実行できるようにして、従来技術と比較して秘密漏洩のリスクを最小に抑える。【解決手段】ユーザの死亡認証又は手続不能認証と、仲介機関側第１受付部で受け付けた予約手続依頼を照合して、死亡認証又は手続不能認証されたユーザが予約手続依頼をしたことを判別する。ユーザ利用機関側第２受付部は、死亡認証又は手続不能認証されたユーザが予約手続依頼をしたことが判別されたことに応じて、当該死亡認証又は手続不能認証されたユーザの希望手続内容の処理実行を受け付ける。死亡認証又は手続不能認証されたユーザの希望手続内容の処理実行を受け付けたことに応じて、当該死亡認証又は手続不能認証されたユーザが依頼した希望手続内容の処理を実行する。【選択図】図３

Description

本発明は、ユーザが予約した手続きを処理するための予約手続処理システムに関する。

（従来技術）

特許文献１（特開２００２-１５７３２４号公報）には、解約代行管理装置によって利用者と契約先との間の契約内容を契約当事者固有の当事者識別情報に対応づけて管理し、利用者本人である解約実行申込者あるいは利用者本人と特別な関係にある解約実行申込者から契約内容の解約実行の申込要求があった場合に、その解約実行申込者が提示した当事者識別情報に基づいて対応する契約内容を取得して、契約内容の解約手続きの実行要求を契約先端末に対して送信するという発明が記載されている。

特許文献２（特開２０１１-１３８２３６号公報）には、システム管理装置が、利用者からの契約内容を受け付け、利用者との契約を履行するために必要な情報を記憶しておき、利用者によるウェブサービスの利用状況を監視し、監視の結果に応じて、利用者が利用続行不能な状態であるか否かの確認を行い、利用者が利用続行不能と判定された場合に、ウェブサービスの解約手続きを代行するという発明が記載されている。

特開２００２-１５７３２４号公報 特開２０１１-１３８２３６号公報

本発明は、ユーザ利用機関以外の第三者にユーザの希望手続内容を知られることがなく予約手続処理を実行できるようにして、従来技術と比較して、秘密漏洩のリスクを最小に抑えることを課題とする。

第１の態様は、ユーザからユーザ利用機関に対する予約手続依頼を受け付ける仲介機関側第１受付部と、前記仲介機関側第１受付部で前記予約手続依頼を受け付けるに応じて、ユーザから希望手続内容を受け付けるユーザ利用機関側第１受付部と、ユーザの死亡情報又は手続不能情報を受け付ける仲介機関側第２受付部と、前記仲介機関側第２受付部で受け付けたユーザの死亡情報又は手続不能情報に基づいて当該ユーザの死亡認証又は手続不能認証を取得する認証取得部と、前記認証取得部で取得されたユーザの死亡認証又は手続不能認証と、前記仲介機関側第１受付部で受け付けた予約手続依頼を照合して、前記死亡認証又は手続不能認証されたユーザが前記予約手続依頼をしたことを判別する判別部と、前記判別部によって死亡認証又は手続不能認証されたユーザが前記予約手続依頼をしたことが判別されたことに応じて、当該死亡認証又は手続不能認証されたユーザの希望手続内容の処理実行を受け付けるユーザ利用機関側第２受付部と、前記ユーザ利用機関側第２受付部で死亡認証又は手続不能認証されたユーザの希望手続内容の処理実行を受け付けたことに応じて、当該死亡認証又は手続不能認証されたユーザが依頼した前記希望手続内容の処理を実行する処理部と、を備えた予約手続処理システムである。

第２の態様は、第１の態様において、前記仲介機関側第１受付部と、前記仲介機関側第２受付部と、前記認証取得部と、前記判別部は、仲介機関が管理するシステムに設けられ、

前記ユーザ利用機関側第１受付部と、前記ユーザ利用機関側第２受付部と、前記処理部は、ユーザ利用機関が管理するシステムに設けられている、予約手続システムである。

第３の態様は、第２の態様において、前記仲介機関は、業務を通じてユーザの死亡を知る立場にある機関であり、前記認証取得部は、火葬許可証又は死亡診断書又は埋葬許可証又は埋火葬許可証をユーザの死亡認証として取得する、予約手続システムである。

第４の態様は、第１から第３の態様のいずれにおいて、複数のユーザ利用機関毎に、前記ユーザ利用機関側第１受付部と、前記ユーザ利用機関側第２受付部と、前記処理部が設けられている、予約手続システムである。

第５の態様は、第１から第４の態様のいずれかにおいて、前記仲介機関側第１受付部は、複数のユーザ利用機関の中から１又は２以上のユーザ利用機関に対する予約手続依頼を選択する予約手続依頼選択部を備えている予約手続システムである。

第６の態様は、第１から第５の態様のいずれかにおいて、前記ユーザ利用機関側第１受付部は、複数の希望手続内容の中から１又は２以上の希望手続内容を選択する希望手続内容選択部を備えている予約手続システムである。

第７の態様は、第１から第６の態様のいずれかにおいて、前記ユーザ利用機関側第１受付部で受け付ける希望手続内容は、個人情報の削除又は/及び取引履歴の削除又は/及びアカウント削除又は/及び取引契約の解除又は/及び口座凍結又は/及び定期的な契約の停止を含んでいる、予約手続システムである。

第８の態様は、第１から第７の態様のいずれかにおいて、前記仲介機関側第２受付部は、ユーザの死亡情報又は手続不能情報と共に当該ユーザの死亡情報又は手続不能情報の提供元の情報を受け付け、前記ユーザ利用機関側第２受付部は、ユーザの死亡認証又は手続不能認証と共にユーザの死亡情報又は手続不能情報の提供元の情報を受け付け、前記処理部によって、前記希望手続内容が実行された際に、その旨をユーザの死亡情報又は手続不能情報の提供元に連絡する連絡部を備えた予約手続システムである。

第９の態様は、第１から第８の態様のいずれかにおいて、前記仲介機関側第１受付部と、前記仲介機関側第２受付部と、前記認証取得部と、前記判別部で取得される情報は、複数の仲介機関で共有され、一の仲介機関で受け付けた前記予約手続依頼の情報は、他の仲介機関で共有されると共に、前記他の仲介機関で受け付けた前記ユーザの死亡情報又は手続不能情報は、前記一の仲介機関で共有される、予約手続システムである。

第１から第９の態様によれば、ユーザ利用機関以外の第三者にユーザの希望手続内容を知られることがなく予約手続処理を実行できる。これにより従来技術と比較して、ユーザ本人が希望した手続きの内容が第三者に知られるという秘密漏洩のリスクを最小に抑えることができる。

図１は、実施形態の予約手続処理システムの構成を例示する図である。 図２は、実施形態のハードウェア構成を例示するブロック図である。 図３は、実施形態の予約手続処理システムの機能構成を例示するブロック図である。 図４は、仲介機関側管理システムとユーザ利用機関側管理システムとのソフトウェア上の連携関係を示す図である。 図５Ａは、仲介機関側管理システムとユーザ利用機関側管理システムで行われる処理の流れを説明するためのシーケンス図である。 図５Ｂは、仲介機関側管理システムとユーザ利用機関側管理システムで行われる処理の流れを説明するためのシーケンス図である。 図６は、予約手続依頼画面を例示する図である。 図７Ａは、希望手続内容画面を例示する図である。 図７Ｂは、希望手続内容画面を例示する図である。 図８は、葬儀申込画面を例示する図である。

以下、図面を参照して、本発明の予約手続処理システムの実施形態を説明する。

図１は、実施形態の予約手続処理システム１の構成を例示する図である。

予約手続処理システム１は、仲介機関側端末１１１、１１２と、仲介機関側サーバ１２１、１２２と、ユーザ利用機関側端末２１１、２１２と、ユーザ利用機関側サーバ２２１、２２２と、ユーザ側端末３００と、提供元側端末３１０と、葬儀社側端末３２０と、これら各端末１１１、１１２、２１１、２１２、３００、３１０、３２０及びサーバ１２１、１２２、２２１、２２２間で相互にデータを送受信可能に接続するネットワーク４００とから構成されている。

仲介機関側端末１１１と、仲介機関側サーバ１２１を含む管理システムを、仲介機関側管理システム１０１という。同様に仲介機関側端末１１２と、仲介機関側サーバ１２２を含む管理システムを、仲介機関側管理システム１０２という。例えば企業ＣＯ１１に、仲介機関側端末１１１、仲介機関側サーバ１２１が設けられ、企業ＣＯ１１は、仲介機関側サーバ１２１のデータベースへのアクセス権限を有している。また企業ＣＯ１２に、仲介機関側端末１１２、仲介機関側サーバ１２２が設けられ、企業ＣＯ１２は、仲介機関側サーバ１２２のデータベースへのアクセス権限を有している。

ユーザ利用機関側端末２１１と、ユーザ利用機関側サーバ２２１を含む管理システムを、ユーザ利用機関側管理システム２０１という。同様にユーザ利用機関側端末２１２と、ユーザ利用機関側サーバ２２２を含む管理システムを、ユーザ利用機関側管理システム２０２という。例えば企業ＣＯ２１に、ユーザ利用機関側端末２１１、ユーザ利用機関側サーバ２２１が設けられ、企業ＣＯ２１は、ユーザ利用機関側サーバ２２１のデータベースへのアクセス権限を有している。また企業ＣＯ２２に、ユーザ利用機関側端末２１２、ユーザ利用機関側サーバ２２２が設けられ、企業ＣＯ２２は、ユーザ利用機関側サーバ２２２のデータベースへのアクセス権限を有している。

仲介機関側端末１１１、１１２と、ユーザ利用機関側端末２１１、２１２と、ユーザ側端末３００と、提供元側端末３１０と、葬儀社側端末３２０は、サーバ機器へアクセスするためのクライアント機器であり、例えばパーソナルコンピュータ、スマートフォンなどの携帯機器で構成される。ネットワーク４００は、インターネットやイントラネット等で構成される。仲介機関側サーバ１２１、１２２と、ユーザ利用機関側サーバ２２１、２２２は、サーバ機器あるいはクラウドコンピューティングサービス上に構築された仮想サーバ等で構成されている。

図２は、実施形態の仲介機関側端末１１１、１１２と、仲介機関側サーバ１２１、１２２と、ユーザ利用機関側端末２１１、２１２と、ユーザ利用機関側サーバ２２１、２２２と、ユーザ側端末３００と、提供元側端末３１０と、葬儀社側端末３２０のハードウェア構成を例示するブロック図である。
図２に示すように、仲介機関側端末１１１、１１２と、仲介機関側サーバ１２１、１２２と、ユーザ利用機関側端末２１１、２１２と、ユーザ利用機関側サーバ２２１、２２２と、ユーザ側端末３００と、提供元側端末３１０と、葬儀社側端末３２０はそれぞれ、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ストレージ１４、入力装置１６、表示装置１７、通信Ｉ／Ｆ１８がシステムバス１５を介して相互に通信可能に接続されて構成されている。
ＣＰＵ１１は、中央演算処理ユニットであり、各種プログラムを実行したり、システムバス１５に接続される各デバイスを制御したりする。すなわち、ＣＰＵ１１は、ＲＯＭ１２又はストレージ１４からプログラムを読み出し、ＲＡＭ１３を作業領域としてプログラムを実行する。ＣＰＵ１１は、ＲＯＭ１２又はストレージ１４に記録されているプログラムにしたがって、システムバス１５に接続される各デバイスの制御及び各種の演算処理を行う。ＲＯＭ１２又はストレージ１４には、ＣＰＵ１１が実行する制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や、本実施形態を実現するためのコンピュータで読み取りが可能で実行が可能なプログラム及び必要な各種データを保持している。

ＲＯＭ１２は、各種制御プログラム及び各種データを格納する。ＲＡＭ１３は、ＣＰＵ１１の主メモリ、ワークエリア等として機能し作業領域として一時的にプログラム又はデータを記憶する。ストレージ１４は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）により構成され、ＢＩＯＳ、ＯＳを含む各種プログラム及び各種データを格納する。

入力装置１６は、マウス等のポインティングデバイス、及びキーボードを含み、各種の入力を行うために使用される。

表示装置１７は、例えば、液晶ディスプレイであり、各種の情報を表示する。表示装置１７は、タッチパネル方式を採用して、入力装置１６として機能しても良い。

表示装置１７の表示画面には、後述する各種画面が表示される。

通信インタフェース１８は、他の機器と通信するためのインタフェースであり、例えば、イーサネット（登録商標）、ＦＤＤＩ、Ｗｉ－Ｆｉ（登録商標）等の規格が用いられる。通信インタフェース１８は、ネットワーク４００と接続してデータの送受信の制御を行う。

図３は実施形態の予約手続処理システム１の機能構成を例示するブロック図である。

予約手続処理システム１は、仲介機関側第１受付部１００１と、ユーザ利用機関側第１受付部２００１と、仲介機関側第２受付部１００２と、認証取得部１００３と、判別部１００４と、予約手続依頼情報格納部１００５と、ユーザ利用機関側第２受付部２００２と、処理部２００３と、連絡部２００４と、希望手続内容情報格納部２００５を含んで構成される。

図３に示す仲介機関側第１受付部１００１と、仲介機関側第２受付部１００２と、認証取得部１００３と、判別部１００４と、予約手続依頼情報格納部１００５の機能構成は、仲介機関側端末１１１、１１２及び仲介機関側サーバ１２１、１２２、つまり仲介機関側管理システム１０１、１０２が備えている。図３に示すユーザ利用機関側第１受付部２００１と、ユーザ利用機関側第２受付部２００２と、処理部２００３と、連絡部２００４と、希望手続内容情報格納部２００５の機能構成は、ユーザ利用機関側端末２１１、２１２及びユーザ利用機関側サーバ２２１、２２２、つまりユーザ利用機関側管理システム２０１、２０２が備えている。

仲介機関側第１受付部１００１は、ユーザからユーザ利用機関に対する予約手続依頼を受け付ける。

ユーザ利用機関側第１受付部２００１は、仲介機関側第１受付部１００１で予約手続依頼を受け付けるに応じて、ユーザから希望手続内容を受け付ける。

仲介機関側第２受付部１００２は、ユーザの死亡情報又は手続不能情報を受け付ける。

認証取得部１００３は、仲介機関側第２受付部１００２で受け付けたユーザの死亡情報又は手続不能情報に基づいて当該ユーザの死亡認証又は手続不能認証を取得する。

判別部１００４は、認証取得部１００３で取得されたユーザの死亡認証又は手続不能認証と、仲介機関側第１受付部１００１で受け付けた予約手続依頼を照合して、死亡認証又は手続不能認証されたユーザが予約手続依頼をしたことを判別する。

ユーザ利用機関側第２受付部２００２は、判別部１００４によって死亡認証又は手続不能認証されたユーザが予約手続依頼をしたことが判別されたことに応じて、当該死亡認証又は手続不能認証されたユーザの希望手続内容の処理実行を受け付ける。

処理部２００３は、ユーザ利用機関側第２受付部２００２で死亡認証又は手続不能認証されたユーザの希望手続内容の処理実行を受け付けたことに応じて、当該死亡認証又は手続不能認証されたユーザが依頼した希望手続内容の処理を実行する。

連絡部２００４は、処理部２００３によって、希望手続内容が実行された際に、その旨をユーザの死亡情報又は手続不能情報の提供元に連絡する。

図４は、仲介機関側管理システム１０１、１０２とユーザ利用機関側管理システム２０１、２０２とのソフトウェア上の連携関係を示す。

仲介機関側管理システム１０１、１０２とユーザ利用機関側管理システム２０１、２０２は別のシステムであって、システムの運用主体（管理主体）は別である。仲介機関側管理システム１０１の管理主体は、例えば企業ＣＯ１１であり、介機関側管理システム１０２の管理主体は、例えば企業ＣＯ１２である。ユーザ利用機関側管理システム２０１の管理主体は、企業ＣＯ２１であり、ユーザ利用機関側管理システム２０１の管理主体は、企業ＣＯ２２であり、仲介機関側管理システム１０１の管理主体ＣＯ１１、ＣＯ１２とは異なる。

ユーザ利用機関側管理システム２０１は仲介機関側管理システム１０１、１０２とＡＰＩ（アプリケーション・プログラミング・インターフェース）連携しており、仲介機関側管理システム１０１、１０２の要求に応じて、ＡＰＩが読み出され、特定動作を実行する。同様にユーザ利用機関側管理システム２０２は仲介機関側管理システム１０１、１０２とＡＰＩ連携している。

ユーザ利用機関側管理システム２０１、２０２はそれぞれ、ユーザ利用機関側管理システム２０１、２０２のシステム構成に応じたＡＰＩ２１０１、ＡＰＩ２１０１を有している。

ユーザ利用機関側管理システム２０１、２０２はそれぞれ、仲介機関側管理システム１０１、１０２からネットワーク４００を介してＡＰＩ２１０１、ＡＰＩ２１０２が呼び出されることにより、希望手続内容を受け付ける処理等、特定の処理動作の機能を、仲介機関側管理システム１０１、１０２に提供する。希望手続内容等の情報は、仲介機関側管理システム１０１、１０２で管理されることはなく、ユーザ利用機関側管理システム２０１、２０２で管理される。

図５Ａ、図５Ｂは、１つの仲介機関側管理システム１０１と複数（２つ）のユーザ利用機関側管理システム２０１、２０２で行われる処理の流れを説明するためのシーケンス図である。図５Ａは、ユーザの生前時のシーケンス図で、図５Ｂは、ユーザの死亡後のシーケンス図である。

（ユーザの生前時等）

（予約手続依頼の受け付け）

仲介機関ＣＯ１１は、業務を通じてユーザの死亡又はユーザが手続不能であることを知る立場にある機関であり、ユーザＵ１１とユーザ利用機関ＣＯ２１、ＣＯ２２とを仲介する。

ユーザＵ１１は、ユーザ利用機関ＣＯ２１、ＣＯ２２が提供するサービスを受けたり、ユーザ利用機関ＣＯ２１、ＣＯ２２が販売する商品を購入等する。ユーザＵ１１は、仲介機関ＣＯ１１が提供する仲介サービスを利用する。

仲介機関ＣＯ１１が提供する仲介サービスの一つに予約手続依頼のサービスがある。予約手続依頼のサービスとは、ユーザＵ１１の生前時又はユーザＵ１１に手続能力がある状態のときに、ユーザ利用機関ＣＯ２１、ＣＯ２２で行われるべき希望手続内容の予約を受け付けておき、ユーザＵ１１の死亡時又はユーザＵ１１に手続能力がなくなった状態のときに、ユーザ利用機関ＣＯ２１、ＣＯ２２においてその予約した希望手続内容を履行するサービスのことである。

ユーザＵ１１はユーザ側端末３００を操作する。仲介機関ＣＯ１１の仲介機関側サーバ１２１は、ＨＴＴＰ（Hyper Text Transfer Protocol）の通信プロトコルに従い、クライアント端末であるユーザ側端末３００の表示装置１７に、図６に示す予約手続依頼画面５００を表示させるＷＥＢサーバとして機能する。

予約手続依頼画面５００の表示は、ユーザ認証を条件にしてもよい。ユーザＵ１１は、仲介機関ＣＯ１１が管理するユーザ識別符号ＩＤ１１、パスワードＰＳ１１に対応付けられている。ユーザ側端末３００において、ユーザ識別符号ＩＤ１１、パスワードＰＳ１１を入力するログイン操作が行われると、ユーザ認証がなされ、これにより仲介機関ＣＯ１１の仲介機関側サーバ１２１に格納された表示情報のデータが読み出され、ネットワーク４００を介してユーザ側端末３００の表示装置１７に、予約手続依頼画面５００が表示される。

図６は、予約手続依頼画面５００を例示する。なお図６の画面デザインは一例であり、実施形態の機能を実現できるのであれば任意のデザインを採用することができる。

仲介機関ＣＯ１１の仲介機関側第１受付部１００１は、予約手続依頼画面５００上でユーザＵ１１からユーザ利用機関に対する予約手続依頼を受け付ける。

予約手続依頼画面５００には、予約手続依頼選択部５１０が設けられている。予約手続依頼選択部５１０は、仲介機関側第１受付部１００１を構成する。

予約手続依頼選択部５１０では、複数のユーザ利用機関ＣＯ２１、ＣＯ２２の中から１又は２以上のユーザ利用機関に対する予約手続依頼を選択することができる。予約手続依頼選択部５１０は、例えばチェックボックスで構成されている。例えば、ユーザ利用機関ＣＯ２１及びＣＯ２２に対して予約手続きを依頼したい場合には、予約手続依頼選択部５１０で「ＣＯ２１」及び「ＣＯ２２」を選択する操作を行えばよい。

予約手続依頼選択部５１０における選択操作をもって仲介機関側第１受付部１００１は、ユーザＵ１１から、選択したユーザ利用機関ＣＯ２１及びＣＯ２２に対する予約手続依頼を受け付ける。「ユーザＵ１１がユーザ利用機関ＣＯ２１及びＣＯ２２に対して予約手続依頼を生前に行った」という予約手続依頼情報は、予約手続依頼情報格納部１００５に、ユーザＵ１１に対応付けられて格納される（Ｓ１）。

（希望手続内容の受け付け）

ユーザ利用機関ＣＯ２１の予約手続依頼が受け付けられると、ユーザ利用機関ＣＯ２１のユーザ利用機関側管理システム２０１が有するＡＰＩ２１０１が呼び出される（Ｓ２）。

これにより図７Ａに示すようにユーザ側端末３００の表示装置１７の表示画面は、希望手続内容画面６００Ａに遷移する。ユーザ利用機関ＣＯ２１のユーザ利用機関側第１受付部２００１は、希望手続内容画面６００Ａ上でユーザＵ１１から希望手続内容を受け付ける。

希望手続内容画面６００Ａの表示は、ユーザ認証を条件にしてもよい。ユーザＵ１１は、ユーザ利用機関ＣＯ２１が管理するユーザ識別符号ＩＤ２１１、パスワードＰＳ２１１に対応付けられている。ユーザ側端末３００において、ユーザ識別符号ＩＤ２１１、パスワードＰＳ２１１を入力するログイン操作が行われると、ユーザ認証がなされ、ユーザ利用機関側サーバ２２１に格納された表示情報のデータが読み出され、ユーザ側端末３００の表示装置１７に、希望手続内容画面６００Ａが表示される。

希望手続内容画面６００Ａには、希望手続内容選択部６１０が設けられている。希望手続内容選択部６１０は、ユーザ利用機関側第１受付部２００１を構成する。

希望手続内容選択部６１０では、複数の希望手続内容の中から１又は２以上の希望手続内容を選択することができる。希望手続内容選択部６１０は、例えばチェックボックスで構成されている。

複数の希望手続内容は、「個人情報の削除」、「取引履歴の削除」、「アカウント削除」、「取引契約の解除」、「口座凍結」、「定期的な契約の停止」を含む。

複数の希望手続内容は、複数のユーザ利用機関ＣＯ２１、ＣＯ２２毎に異ならせることができる。ユーザ利用機関ＣＯ２１は、「口座凍結」の選択が可能であるが、「定期的な契約の停止」の選択はできない。またーザ利用機関ＣＯ２２は、「定期的な契約の停止」の選択が可能であるが、「口座凍結」の選択はできない。

例えば、ユーザ利用機関ＣＯ２１に開設されている預金口座の凍結を予約したい場合には、希望手続内容選択部６１０で「口座凍結」を選択する操作を行えばよい。

希望手続内容選択部６１０における選択操作をもってユーザ利用機関ＣＯ２１のユーザ利用機関側第１受付部２００１は、ユーザＵ１１から、ユーザ利用機関ＣＯ２１の預金口座の凍結という希望手続内容を受け付ける。「ユーザＵ１１から口座凍結という希望手続内容を受け付けた」という希望手続内容情報は、ユーザ利用機関ＣＯ２１の希望手続内容情報格納部２００５に、ユーザＵ１１に対応付けられて格納される。

希望手続内容画面６００Ａには、希望手続内容の処理が終了したことを遺族等に連絡するか否かを選択する連絡要不要選択部６２０が設けられている。連絡要不要選択部６２０で、「連絡する」を選択した場合には、「ユーザＵ１１の希望手続内容の処理が終了したことを遺族等に連絡する」という連絡要情報が、ユーザ利用機関ＣＯ２１の希望手続内容情報格納部２００５に、ユーザＵ１１に対応付けられて格納される。また連絡要不要選択部６２０で、「連絡しない」を選択した場合には、「ユーザＵ１１の希望手続内容の処理が終了したことは遺族等に連絡しない」という連絡不要情報が、ユーザ利用機関ＣＯ２１の希望手続内容情報格納部２００５に、ユーザＵ１１に対応付けられて格納される（Ｓ３）。

ユーザＵ１１から予約手続依頼を受け付けた他のユーザ利用機関ＣＯ２２についても同様である。

ユーザ利用機関ＣＯ２２の予約手続依頼が受け付けられると（Ｓ１）、ユーザ利用機関ＣＯ２２のユーザ利用機関側管理システム２０２が有するＡＰＩ２１０２が呼び出され（Ｓ２）、図７Ｂに示すようにユーザ側端末３００の表示装置１７の表示画面は、希望手続内容画面６００Ｂに遷移する。ユーザ利用機関ＣＯ２２のユーザ利用機関側第１受付部２００１は、希望手続内容画面６００Ｂ上でユーザＵ１１から希望手続内容を受け付ける。

例えば、ユーザ利用機関ＣＯ２２に対して、定期的な契約（サブスクリプションサービスの契約）の停止を予約したい場合には、希望手続内容選択部６１０で「定期的な契約の停止」を選択する操作を行えばよい。

希望手続内容選択部６１０における選択操作をもってユーザ利用機関ＣＯ２２のユーザ利用機関側第１受付部２００１は、ユーザＵ１１から、定期的な契約（サブスクリプションサービスの契約）の停止という希望手続内容を受け付ける。「ユーザＵ１１から定期的な契約（サブスクリプションサービスの契約）の停止という希望手続内容を受け付けた」という希望手続内容情報は、ユーザ利用機関ＣＯ２２の希望手続内容情報格納部２００５に、ユーザＵ１１に対応付けられて格納される。

連絡要不要選択部６２０で、「連絡する」を選択した場合には、「ユーザＵ１１の希望手続内容の処理が終了したことを遺族等に連絡する」という連絡要情報が、ユーザ利用機関ＣＯ２２の希望手続内容情報格納部２００５に、ユーザＵ１１に対応付けられて格納される。また連絡要不要選択部６２０で、「連絡しない」を選択した場合には、「ユーザＵ１１の希望手続内容の処理が終了したことは遺族等に連絡しない」という連絡不要情報が、ユーザ利用機関ＣＯ２２の希望手続内容情報格納部２００５に、ユーザＵ１１に対応付けられて格納される（Ｓ３）。

（ユーザの死亡後又は手続不能状態後）

（ユーザ死亡情報又は手続不能情報の受け付け）

ユーザＵ３１は、ユーザＵ１１の遺族、所属機関、死亡情報管理機関など、ユーザＵ１１の死亡情報又は手続不能情報を仲介機関ＣＯ１１に提供できる個人又は法人である（本明細書において、提供元という）。本明細書において、手続不能情報とは、脳死状態、認知症発症状態、要介護状態など死亡に至らずとも本人がユーザ利用機関ＣＯ２１、ＣＯ２２に対する手続きを執ることが不能であることを示す情報をいうものとする。

例えばユーザＵ１１は、自身の死亡後又は手続不能状態後に仲介機関ＣＯ１１に対して自身の死亡情報又は手続不能情報を提供するように、生前時等にユーザＵ３１に口頭、遺言書、メール等で申し送りをすることができる。

ユーザＵ１１の死亡後又は手続不能状態後にユーザＵ３１は、仲介機関ＣＯ１１に対して死亡情報又は手続不能情報を提供する。

例えばユーザＵ１１の遺族であるユーザＵ３１は、仲介機関ＣＯ１１が提供する葬儀支援サービスを利用する。提供元側端末３１０において、ユーザＵ３１のログイン操作が行われると、仲介機関ＣＯ１１の仲介機関側サーバ１２１に格納された表示情報のデータが読み出され、ネットワーク４００を介して提供元側端末３１０の表示装置１７に、葬儀申込画面７００が表示される。

図８は、葬儀申込画面７００を例示する。

仲介機関側第２受付部１００２は、葬儀申込画面７００上で、ユーザＵ１１の死亡情報又は手続不能情報を受け付ける。また仲介機関側第２受付部１００２は、葬儀申込画面７００上で、死亡情報又は手続不能情報の提供元の情報を受け付ける。

葬儀申込画面７００には、情報受付部７１０が設けられている。情報受付部７１０は、仲介機関側第２受付部１００２を構成する。

情報受付部７１０は、例えば故人氏名入力部７１１、故人年齢入力部７１２、故人逝去日入力部７１３、依頼者名入力部７１４、葬儀申込ボタン７１５などで構成されている。

例えば、故人氏名入力部７１１に、「Ｕ１１」というユーザＵ１１を特定する情報が入力され、依頼者名入力部７１４に、「Ｕ３１」というユーザＵ３１を特定する情報が入力され、葬儀申込ボタン７１５を押す操作がなされると、仲介機関側第２受付部１００２は、ユーザＵ１１が死亡したという死亡情報及びユーザＵ３１が死亡情報の提供元であるという提供元の情報を受け付ける。なおユーザＵ１１が手続不能状態になった場合にも同様にして仲介機関側第２受付部１００２は、ユーザＵ１１が手続不能状態であるという手続不能情報及びユーザＵ３１が手続不能情報の提供元であるという提供元情報を受け付けることができる。

以上のように、仲介機関側第２受付部１００２は、オンラインで、死亡情報又は手続不能情報及び提供元の情報を受け付ける。しかし、電話、ＦＡＸ、口頭など任意の手段で死亡情報又は手続不能情報及び提供元の情報を受け付ける実施も可能である。

例えば、ユーザＵ１１の死亡情報及びユーザＵ３１が死亡情報の提供元であるという提供元情報を電話で受け、電話を受けた仲介機関ＣＯ１１の担当者が、仲介機関側端末１１１の表示装置１７の表示画面上の情報受付部７１０に、ユーザＵ１１の死亡情報及びＵ１３が死亡情報の提供元であるという提供元情報を入力してもよい。手続不能情報についても同様である（Ｓ４）。

（死亡認証又は手続不能認証の取得）

認証取得部１００３は、仲介機関側第２受付部１００２で受け付けたユーザＵ１１の死亡情報又は手続不能情報に基づいて当該ユーザＵ１１の死亡認証又は手続不能認証を取得する。

仲介機関ＣＯ１１は、ユーザＵ３１の葬儀申込みを受けて、葬儀社ＣＯ４０に葬儀を委託する。ユーザＵ３１の葬儀申込みを受けて、仲介機関側端末１１１からネットワーク４００、図示しないメールサーバを介して葬儀社側端末３２０にユーザＵ１１の葬儀を委託する旨の委託メールが送信される。

委託メールを受信し、葬儀を受託した葬儀社ＣＯ４０は、死亡届の手続きを代行する。ユーザＵ３１は、葬儀社ＣＯ４０にユーザＵ１１の死亡診断書を提出する。

葬儀社ＣＯ４０は、ユーザＵ１１の死亡診断書を役所に提出して、ユーザＵ１１の火葬許可証を受領する。

葬儀社側端末３２０からネットワーク４００、図示しないメールサーバを介して仲介機関側端末１１１に、ユーザＵ１１の火葬許可証のＰＤＦファイルが送信される。以上のように、仲介機関ＣＯ１１は、葬儀社ＣＯ４０に、オンラインで、葬儀を委託し、火葬許可証を受領する。しかし、電話、ＦＡＸ、口頭など任意の手段で葬儀を委託し、ＦＡＸ等により火葬許可証を受領する実施も可能である。

認証取得部１００３は、ユーザＵ１１の火葬許可証のＰＤＦファイルを、ユーザＵ１１の死亡認証として取得する。なお死亡認証としては、火葬許可証に限定されるわけではなく、死亡診断書、埋葬許可証、埋火葬許可証であってもよい。またユーザＵ１１が手続不能状態になった場合には、認証取得部１００３は、ユーザＵ１１が手続不能状態であることを公的な機関等が証明する手続不能認証を取得する（Ｓ５）。

（死亡認証又は手続不能認証されたユーザと予約手続依頼をしたユーザの照合・判別）

判別部１００４は、受診した火葬許可証のＰＤＦファイルに示されるユーザと、予約手続依頼情報格納部１００５に格納された予約手続依頼情報に示されるユーザを照合する。この結果、判別部１００４は、死亡認証されたユーザＵ１１がユーザ利用機関ＣＯ２１及びＣＯ２２に対して予約手続依頼をしたことを判別する。またユーザＵ１１が手続不能状態になった場合には、判別部１００４は、手続不能認証されたユーザＵ１１がユーザ利用機関ＣＯ２１及びＣＯ２２に対して予約手続依頼をしたことを判別する（Ｓ６）。

（希望手続内容の処理実行の受け付け）

仲介機関ＣＯ１１の判別部１００４によって死亡認証又は手続不能認証されたユーザＵ１１がユーザ利用機関ＣＯ２１の予約手続依頼をしたことが判別されると、仲介機関ＣＯ１１からユーザ利用機関ＣＯ２１に対して、ユーザＵ１１の死亡認証又は手続不能認証が送信されると共に、ユーザＵ１１の死亡情報又は手続不能情報の提供元がユーザＵ３１であるという提供元情報がネットワーク４００を介して送信される（Ｓ７）。

これら情報を受信することによりユーザ利用機関ＣＯ２１のユーザ利用機関側第２受付部２００２は、死亡認証又は手続不能認証されたユーザＵ１１の希望手続内容の処理実行を受け付けると共に、ユーザＵ１１の死亡情報又は手続不能情報の提供元がユーザＵ３１であるという提供元情報を受け付ける（Ｓ８）。

他のユーザ利用機関ＣＯ２２についても同様である。

仲介機関ＣＯ１１の判別部１００４によって死亡認証又は手続不能認証されたユーザＵ１１がユーザ利用機関ＣＯ２２の予約手続依頼をしたことが判別されると、仲介機関ＣＯ１１からユーザ利用機関ＣＯ２２に対して、ユーザＵ１１の死亡認証又は手続不能認証が送信されると共に、ユーザＵ１１の死亡情報又は手続不能情報の提供元がユーザＵ３１であるという提供元情報がネットワーク４００を介して送信される（Ｓ７）。

これら情報を受信することによりユーザ利用機関ＣＯ２２のユーザ利用機関側第２受付部２００２は、死亡認証又は手続不能認証されたユーザＵ１１の希望手続内容の処理実行を受け付けると共に、ユーザＵ１１の死亡情報又は手続不能情報の提供元がユーザＵ３１であるという提供元情報を受け付ける（Ｓ８）。

（希望手続内容の処理実行）

ユーザ利用機関ＣＯ２１の処理部２００３は、死亡認証又は手続不能認証されたユーザＵ１１が依頼した希望手続内容の処理を実行する。ユーザ利用機関ＣＯ２１の処理部２００３は、希望手続内容情報格納部２００５に格納され、「ユーザＵ１１」に対応付けられた「口座凍結」という希望手続内容の情報を参照して、ユーザＵ１１の預金口座を凍結する処理を実行する（Ｓ９）。

他のユーザ利用機関ＣＯ２２についても同様である。

ユーザ利用機関ＣＯ２２の処理部２００３は、死亡認証又は手続不能認証されたユーザＵ１１が依頼した希望手続内容の処理を実行する。ユーザ利用機関ＣＯ２２の処理部２００３は、希望手続内容情報格納部２００５に格納され、「ユーザＵ１１」に対応付けられた「定期的な契約（サブスクリプションサービスの契約）の停止」という希望手続内容の情報を参照して、ユーザＵ１１との間で締結された定期的な契約（サブスクリプションサービスの契約）を停止する処理を実行する（Ｓ９）。

（希望手続処理の実行を終了した旨の連絡）

ユーザ利用機関ＣＯ２１の連絡部２００４は、ユーザ利用機関ＣＯ２２の希望手続内容情報格納部２００５に、連絡要情報及び連絡不要情報のいずれがユーザＵ１１に対応付けられて格納されていることを確認する。ユーザ利用機関ＣＯ２２の希望手続内容情報格納部２００５に、連絡要情報がユーザＵ１１に対応付けられて格納されていることが確認された場合には、ユーザＵ１１の希望手続処理の実行が終了した旨を提供元Ｕ３１に連絡する。例えばユーザ利用機関ＣＯ２１のユーザ利用機関側端末２１１からネットワーク４００、図示しないメールサーバを介して提供元側端末３１０に、ユーザＵ１１の希望手続処理の実行が終了した旨の連絡メールが送信される。一方、ユーザ利用機関ＣＯ２１の希望手続内容情報格納部２００５に、連絡不要情報がユーザＵ１１に対応付けられて格納されていることが確認された場合には、提供元に連絡メールを送信することなく処理を終える（Ｓ１０）。

ユーザ利用機関ＣＯ２２についても同様である。

ユーザ利用機関ＣＯ２２の連絡部２００４は、ユーザ利用機関ＣＯ２２の希望手続内容情報格納部２００５に、連絡要情報がユーザＵ１１に対応付けられて格納されていることが確認された場合には、ユーザＵ１１の希望手続処理の実行が終了した旨を、連絡メールにて提供元Ｕ３１に連絡する。一方、ユーザ利用機関ＣＯ２２の希望手続内容情報格納部２００５に、連絡不要情報がユーザＵ１１に対応付けられて格納されていることが確認された場合には、連絡メールを送信することなく処理を終える（Ｓ１０）。

なお電話、ＦＡＸ、口頭など任意の手段で、ユーザ利用機関ＣＯ２１、ＣＯ２２から提供元Ｕ３１に対して希望手続処理の実行が終了した旨の連絡を行ってもよい。

（情報の共有）

仲介機関側第１受付部１００１と、仲介機関側第２受付部１００２と、認証取得部１００３と、判別部１００４で取得される情報は、複数の仲介機関ＣＯ１１、ＣＯ１２で共有することができる。

これにより一の仲介機関ＣＯ１１で受け付けたユーザＵ１１の予約手続依頼の情報は、他の仲介機関ＣＯ１２で取得される。

また他の仲介機関ＣＯ１２で受け付けたユーザＵ１１の死亡情報又は手続不能情報は、一の仲介機関ＣＯ１１で取得される。

このためユーザＵ１１が一の仲介機関ＣＯ１１で予約手続依頼を行ったが、ユーザＵ１１の遺族等であるユーザＵ１３が一の仲介機関ＣＯ１１ではなくて他の仲介機関ＣＯ１２に、ユーザＵ１１の死亡情報又は手続不能情報を提供した場合であったとしても、他の仲介機関ＣＯ１２はユーザＵ１１の予約手続依頼の情報を取得して、ユーザ利用機関ＣＯ２１、ＣＯ２２に、ユーザＵ１１の希望手続きを確実に実行させることができる。

本実施形態によれば、仲介機関はユーザの希望手続内容を管理することなく、ユーザの死亡後又は手続不能状態後に、ユーザ利用機関にユーザの希望手続処理を実行させることができる。このためユーザ利用機関以外の第三者にユーザの希望手続内容を知られることがなく予約手続処理を実行できる。これにより従来技術と比較して、ユーザ本人が希望した予約手続きの内容が第三者に知られるという秘密漏洩のリスクを最小に抑えることができる。

１００１ 仲介機関側第１受付部
２００１ ユーザ利用機関側第１受付部
１００２ 仲介機関側第２受付部
１００３ 認証取得部
１００４ 判別部
１００５ 予約手続依頼情報格納部
２００２ ユーザ利用機関側第２受付部
２００３ 処理部２００３
２００４ 連絡部
２００５ 希望手続内容情報格納部

Claims (9)

1. ユーザからユーザ利用機関に対する予約手続依頼を受け付ける仲介機関側第１受付部と、
   前記仲介機関側第１受付部で前記予約手続依頼を受け付けるに応じて、ユーザから希望手続内容を受け付けるユーザ利用機関側第１受付部と、
   ユーザの死亡情報又は手続不能情報を受け付ける仲介機関側第２受付部と、
   前記仲介機関側第２受付部で受け付けたユーザの死亡情報又は手続不能情報に基づいて当該ユーザの死亡認証又は手続不能認証を取得する認証取得部と、
   前記認証取得部で取得されたユーザの死亡認証又は手続不能認証と、前記仲介機関側第１受付部で受け付けた予約手続依頼を照合して、前記死亡認証又は手続不能認証されたユーザが前記予約手続依頼をしたことを判別する判別部と、
   前記判別部によって死亡認証又は手続不能認証されたユーザが前記予約手続依頼をしたことが判別されたことに応じて、当該死亡認証又は手続不能認証されたユーザの希望手続内容の処理実行を受け付けるユーザ利用機関側第２受付部と、
   前記ユーザ利用機関側第２受付部で死亡認証又は手続不能認証されたユーザの希望手続内容の処理実行を受け付けたことに応じて、当該死亡認証又は手続不能認証されたユーザが依頼した前記希望手続内容の処理を実行する処理部と、
   を備えた予約手続処理システム。
2. 前記仲介機関側第１受付部と、前記仲介機関側第２受付部と、前記認証取得部と、前記判別部は、仲介機関が管理するシステムに設けられ、
   前記ユーザ利用機関側第１受付部と、前記ユーザ利用機関側第２受付部と、前記処理部は、ユーザ利用機関が管理するシステムに設けられている、
   請求項１に記載の予約手続システム。
3. 前記仲介機関は、業務を通じてユーザの死亡を知る立場にある機関であり、
   前記認証取得部は、火葬許可証又は死亡診断書又は埋葬許可証又は埋火葬許可証をユーザの死亡認証として取得する、
   請求項２に記載の予約手続システム。
4. 複数のユーザ利用機関毎に、前記ユーザ利用機関側第１受付部と、前記ユーザ利用機関側第２受付部と、前記処理部が設けられている、
   請求項１から３のいずれか一項に記載の予約手続システム。
5. 前記仲介機関側第１受付部は、
   複数のユーザ利用機関の中から１又は２以上のユーザ利用機関に対する予約手続依頼を選択する予約手続依頼選択部
   を備えている請求項１から４のいずれか一項に記載の予約手続システム。
6. 前記ユーザ利用機関側第１受付部は、
   複数の希望手続内容の中から１又は２以上の希望手続内容を選択する希望手続内容選択部
   を備えている請求項１から５のいずれか一項に記載の予約手続システム。
7. 前記ユーザ利用機関側第１受付部で受け付ける希望手続内容は、個人情報の削除又は/及び取引履歴の削除又は/及びアカウント削除又は/及び取引契約の解除又は/及び口座凍結又は/及び定期的な契約の停止を含んでいる、
   請求項１から６のいずれか一項に記載の予約手続システム。
8. 前記仲介機関側第２受付部は、ユーザの死亡情報又は手続不能情報と共に当該ユーザの死亡情報又は手続不能情報の提供元の情報を受け付け、
   前記ユーザ利用機関側第２受付部は、ユーザの死亡認証又は手続不能認証と共にユーザの死亡情報又は手続不能情報の提供元の情報を受け付け、
   前記処理部によって、前記希望手続内容が実行された際に、その旨をユーザの死亡情報又は手続不能情報の提供元に連絡する連絡部
   を備えた請求項１から７のいずれか一項に記載の予約手続システム。
9. 前記仲介機関側第１受付部と、前記仲介機関側第２受付部と、前記認証取得部と、前記判別部で取得される情報は、複数の仲介機関で共有され、
   一の仲介機関で受け付けた前記予約手続依頼の情報は、他の仲介機関で共有されると共に、
   前記他の仲介機関で受け付けた前記ユーザの死亡情報又は手続不能情報は、前記一の仲介機関で共有される、
   請求項１から８のいずれか一項に記載の予約手続システム。