JP6436895B2 - 管理装置、管理方法及び管理プログラム - Google Patents

管理装置、管理方法及び管理プログラム Download PDF

Info

Publication number
JP6436895B2
JP6436895B2 JP2015231401A JP2015231401A JP6436895B2 JP 6436895 B2 JP6436895 B2 JP 6436895B2 JP 2015231401 A JP2015231401 A JP 2015231401A JP 2015231401 A JP2015231401 A JP 2015231401A JP 6436895 B2 JP6436895 B2 JP 6436895B2
Authority
JP
Japan
Prior art keywords
user
service provider
event information
service
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015231401A
Other languages
English (en)
Other versions
JP2017097745A (ja
Inventor
伸介 ▲高▼橋
伸介 ▲高▼橋
和真 佐藤
和真 佐藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Yahoo Japan Corp
Original Assignee
Yahoo Japan Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Yahoo Japan Corp filed Critical Yahoo Japan Corp
Priority to JP2015231401A priority Critical patent/JP6436895B2/ja
Publication of JP2017097745A publication Critical patent/JP2017097745A/ja
Application granted granted Critical
Publication of JP6436895B2 publication Critical patent/JP6436895B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

本発明は、管理装置、管理方法及び管理プログラムに関する。
近年、情報技術の発達により、スマートフォン等のスマートデバイスの利用が拡がっている。デバイスのユーザは、通信ネットワークを介して、様々なサービスの提供を受けることができる。また、ユーザは、例えば自身が死亡した場合など、サービスの提供を受けることが出来なくなった場合に、サービスにおける権限や資産の承継を所望する場合がある。
このような承継に関する技術として、ユーザの死亡届をサーバに登録することで相続手続を行うインターネット相続手続システムに関する技術が知られている。また、個人が予め自分の死後又は要介護時に、電子メール等を管理するシステムに対して、自分に係る残存データを消去する又は指定者に送信する等の情報処理を依頼又は実行するシステムに関する技術が知られている。
特開2008−9581号公報 特開2014−174976号公報
しかしながら、上記の従来技術では、承継に関するユーザの手間の軽減を図ることが難しい。すなわち、ユーザの身上に発生するイベントは死亡に限られず、また、ユーザが利用するサービスも多岐にわたる。このため、ユーザは、承継に関する手続を包括的に行うことが難しく、手続そのものが手間となり、負担となる。
本願は、上記に鑑みてなされたものであって、承継に関するユーザの手間の軽減を図ることができる管理装置、管理方法及び管理プログラムを提供することを目的とする。
本願に係る管理装置は、ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付ける受付部と、前記ユーザに関するイベント情報を取得する取得部と、前記ユーザに対応付けられるサービス提供者であって、前記取得部によって取得されたイベント情報に関係するサービス提供者に対して、当該イベント情報に基づく通知を送信する送信部と、を備えたことを特徴とする。
実施形態の一態様によれば、承継に関するユーザの手間の軽減を図ることができるという効果を奏する。
図1は、実施形態に係る管理システムによる処理の一例を示す図である。 図2は、実施形態に係る管理装置の構成例を示す図である。 図3は、実施形態に係るユーザ情報記憶部の一例を示す図である。 図4は、実施形態に係る承継設定記憶部の一例を示す図である。 図5は、実施形態に係る承継設定の一例を示す図である。 図6は、実施形態に係る処理手順を示すフローチャート(1)である。 図7は、実施形態に係る処理手順を示すフローチャート(2)である。 図8は、変形例に係る管理システムによる処理の一例を示す図である。 図9は、管理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。
以下に、本願に係る管理装置、管理方法及び管理プログラムを実施するための形態(以下、「実施形態」と呼ぶ)について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る管理装置、管理方法及び管理プログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。
〔1.管理システムによる処理の一例〕
まず、図1を用いて、実施形態に係る管理システム1による処理の一例について説明する。図1は、実施形態に係る管理システム1による処理の一例を示す図である。図1では、本願に係る管理装置に対応する管理装置100が、ユーザから承継に関する登録を受け付け、受け付けた内容に従い、承継を実行する処理の一例について説明する。
図1に示すように、管理システム1には、ユーザ端末10〜10と、サービス提供装置50〜50と、管理装置100とが含まれる。ユーザ端末10、サービス提供装置50〜50及び管理装置100は、図示しないネットワーク(例えば、インターネット)を介して、有線又は無線により互いに通信可能に接続される。なお、図1に示した管理システム1に含まれる各装置の台数は、図示した数に限られない。
ユーザ端末10は、ユーザU01によって利用される情報処理端末である。ユーザ端末10は、ユーザU02によって利用される情報処理端末である。ユーザ端末10〜10は、例えば、デスクトップ型PC(Personal Computer)や、ノート型PCや、タブレット型端末や、PDA(Personal Digital Assistant)や、ウェアラブル端末(Wearable Device)等である。ユーザ端末10〜10は、ユーザU01又はユーザU02による操作に従って、管理装置100との情報の送受信等を行う。なお、以下では、ユーザ端末10とユーザ端末10とを区別する必要のないときは、ユーザ端末10と表記する。また、ユーザU01とユーザU02とを区別する必要のないときは、ユーザと表記する。また、ユーザ端末10をユーザと読み替える場合がある。例えば、ユーザ端末10をユーザU01と読み替え、ユーザ端末10をユーザU02と読み替える場合がある。
サービス提供装置50〜50は、ユーザに対して各種サービスを提供する事業者等に管理されるサーバ装置である。例えば、サービス提供装置50は、生命保険会社によって管理されるサーバ装置である。サービス提供装置50は、ユーザから生命保険に関する手続きを受け付けたり、管理装置100から所定の情報を受け付けたりする。また、サービス提供装置50は、金融機関によって管理されるサーバ装置である。また、サービス提供装置50は、SNS(Social Networking Service)をユーザに提供する事業者によって管理されるサーバ装置である。また、サービス提供装置50は、クラウドを利用したネットワークサービスをユーザに提供する事業者によって管理されるサーバ装置である。なお、以下では、サービス提供装置50〜50を区別する必要のないときは、サービス提供装置50と表記する。
管理装置100は、ユーザが利用するサービスの承継に関する処理を管理するサーバ装置である。管理装置100は、ユーザから承継に関する設定の登録を受け付ける。また、管理装置100は、ユーザに何らかのイベント(承継に関する設定を行ったユーザが死亡したことや、ユーザが認知症等により要介護認定されたことや、ユーザが身体障害認定を受けたこと、また、ユーザが結婚したり、引っ越ししたりしたこと等、ユーザの身上に起こる事象)が発生した場合に、予めユーザから受け付けていた設定内容に従い、承継の処理を行う。例えば、管理装置100は、ユーザU01が死亡した場合に、ユーザU01の契約していた生命保険会社への伝達を行う、という設定をユーザU01から受け付ける。また、管理装置100は、承継人に設定されたユーザU02への生命保険契約の権限を委譲する、という設定を受け付ける。そして、管理装置100は、ユーザU01が死亡した、というようなイベントに関する情報(以下、「イベント情報」と表記する場合がある)を取得した場合には、受けていた設定に従い、生命保険会社が管理するサービス提供装置50に予め設定されていた内容の承継の通知を送信する。
管理装置100は、ユーザU01が承継の設定を行うに際して、例えばユーザ端末10上に表示される管理ツールのようなユーザインターフェイスを提供する。すなわち、管理装置100は、承継に関するプラットフォームのような役割を果たし、ユーザ端末10とサービス提供装置50との間で行われる承継手続等を包括的に管理することができる。以下、図1を用いて、管理システム1が実現する一連の処理を流れに沿って説明する。
図1に示す例において、ユーザU01は、管理装置100に対して承継設定を登録する(ステップS11)。具体的には、ユーザU01は、ユーザU01が死亡した場合等の各サービスに関する取扱いを管理装置100に登録する。すなわち、ユーザU01は、ユーザU01に所定のサービスを提供する事業者であるサービス提供者と、ユーザU01自身との対応付けを登録する。また、ユーザU01は、サービス提供者に対して、自身が提供を受けているサービスの承継に関する詳細な内容を登録する。例えば、ユーザU01は、自身が死亡した場合の生命保険会社や金融機関との取引に関する権限をユーザU02に委譲することや、利用中のSNSのアカウントをユーザU02に承継することや、利用中のクラウドサービスに保存されているデータを消去すること等の設定を登録する。ユーザU01は、例えばユーザ端末10を用いて管理装置100が提供する管理ツールにアクセスし、管理ツール上で承継に関する設定を行う。なお、管理ツールは、ユーザ端末10上で実行される所定のアプリとして提供されてもよい。
その後、ユーザU01にイベントが発生したとする。例えば、ユーザU01が死亡したというイベントが発生した場合に、ユーザU01の死亡を知り得た人物(ここでは、ユーザU02とする)によって、イベントの発生が管理装置100に通知される(ステップS12)。この場合、ユーザU02は、所定の公的な証明書(例えば、ユーザU01の死亡が確認できる戸籍表や、火葬許可証、医師の診断書等)とともに、管理装置100側にユーザU01の死亡を通知してもよい。管理装置100側(例えば、管理装置100の管理者)は、証明書に記載されている内容を検証し、イベントの通知が信頼のおける通知と判定した場合に、ユーザU01にイベントが発生したという情報を入力する。言い換えれば、管理装置100は、ユーザU01に対して、「死亡」状態であるというフラグを設定する。
管理装置100は、通知されたイベント情報に基づいて、イベントが発生したユーザを特定する。そして、管理装置100は、発生したイベントがユーザU01に関するものであることを特定したのち、ユーザU01の承継に関する設定を参照する。
そして、管理装置100は、イベントに応じた通知先を選択する(ステップS13)。すなわち、管理装置100は、死亡というイベントが発生した場合に、ユーザU01が利用していたサービスのうち、いずれのサービスに通知をするべきかを選択する。また、管理装置100は、通知先のサービスにそれぞれどのような内容で承継処理を実行すべきかの設定を参照する。そして、管理装置100は、サービス提供装置50〜50のうち、通知先として設定されているサービス提供装置50に、イベントに応じた通知を送信する(ステップS14)。
サービス提供装置50は、管理装置100から通知を受信する。すなわち、サービス提供装置50は、ユーザU01が死亡したというイベントが発生したという情報を受信する。また、サービス提供装置50は、ユーザU01が、ユーザU01が契約している生命保険に関して所定の承継処理を実行するよう設定していたという情報を受信する。通知の内容に従い、サービス提供装置50は、ユーザU01に関する承継を実行する(ステップS15)。例えば、サービス提供装置50は、ユーザU01が契約している生命保険の番号を承継人として設定されているユーザU02に通知すること、今後の処理の権限をユーザU02が承継すること、また、ユーザU01がユーザU02に対するメッセージ等を残している場合には、かかるメッセージをユーザU02に通知する、など、設定された内容に応じた処理を実行する。これらの処理は、サービス提供装置50とユーザ端末10との間で直接行われてもよいし、管理装置100を介して行われてもよい。
また、管理装置100は、ユーザU01のイベントに応じて、サービス提供装置50〜50に対しても通知が送信されるよう設定を受け付けていた場合には、サービス提供装置50〜50に対して設定の通りに通知を送信する。その後、管理装置100は、各サービス提供装置50によって行われた承継の結果を、承継人として設定されているユーザU02に通知する(ステップS16)。例えば、管理装置100は、サービス提供装置50〜50で実行された承継処理の内容をユーザU02が一元的に確認できるよう、管理ツールに承継処理の内容を表示する。
このように、実施形態に係る管理装置100は、ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付ける。また、管理装置100は、ユーザに関するイベント情報を取得する。そして、管理装置100は、ユーザU01に対応付けられるサービス提供者であって、取得されたイベント情報に関係するサービス提供者に対して、当該イベント情報に基づく通知を送信する。
このように、実施形態に係る管理装置100は、ユーザが利用するサービスとユーザとを対応付けておき、ユーザにイベントが発生した場合には、ユーザと対応付けられているサービスのうち、イベントに応じた通知先に通知を送信する。また、管理装置100は、ユーザからイベント情報を取得した場合に、ユーザに設定に応じて、複数のサービスへ通知を送信することができる。すなわち、管理装置100は、ユーザが利用するサービスに関する承継処理を包括的に管理させることができるため、ユーザの利便性を向上させることができる。また、管理装置100によれば、各サービス提供者は、ユーザからわざわざ通知を受けなくとも、管理装置100からイベントの発生の通知を受けることができる。このため、サービス側は、イベントの発生を容易に把握することが可能となり、イベントの発生したユーザや承継人に対する対応を一早く行うことができたり、ユーザの意向に沿った対応をしたりすることができる。通常、上記のような処理をユーザが行うためには、サービス提供者一つ一つと個別に承継の設定を行うことが必要となる。一方で、管理装置100は、上述のように、承継に関するプラットフォームとして機能することにより、管理ツールを介した登録を受け付けることで、複数のサービスとユーザとを対応付け、適切な承継処理を行うことができる。また、ユーザU01から承継を受けるユーザU02にとっても、管理装置100にイベント情報の発生を通知するだけで、ユーザU01に発生したイベント情報を複数のサービスに通知することが可能となり、手続きを管理装置100に対する手続きに一本化することができる。さらに、ユーザU02は、例えば管理装置100から提供される管理ツールを用いて各サービスとの承継処理を管理することで、自らが承継を受けるサービスを一元的に把握することができる。これにより、管理装置100は、承継するユーザ、承継を受けるユーザの双方にとって、承継に関する手間の軽減を図ることができる。
〔2.管理装置の構成〕
次に、図2を用いて、実施形態に係る管理装置100の構成について説明する。図2は、実施形態に係る管理装置100の構成例を示す図である。図2に示すように、管理装置100は、通信部110と、記憶部120と、制御部130とを有する。なお、管理装置100は、管理装置100を利用する管理者等から各種操作を受け付ける入力部(例えば、キーボードやマウス等)や、各種情報を表示するための表示部(例えば、液晶ディスプレイ等)を有してもよい。
(通信部110について)
通信部110は、例えば、NIC(Network Interface Card)等によって実現される。かかる通信部110は、通信ネットワークと有線又は無線で接続され、通信ネットワークを介して、ユーザ端末10やサービス提供装置50等との間で情報の送受信を行う。
(記憶部120について)
記憶部120は、例えば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。実施形態に係る記憶部120は、ユーザ情報記憶部121と、承継設定記憶部122とを有する。以下、各記憶部について順に説明する。
(ユーザ情報記憶部121について)
ユーザ情報記憶部121は、管理装置100を利用するユーザに関する情報を記憶する。ここで、図3に、実施形態に係るユーザ情報記憶部121の一例を示す。図3は、実施形態に係るユーザ情報記憶部121の一例を示す図である。図3に示した例では、ユーザ情報記憶部121は、「ユーザID」、「氏名」、「住所」、「生年月日」、「年齢」、「本人確認書類」、「連絡ユーザ」といった項目を有する。
「ユーザID」は、管理装置100を利用するユーザを識別する識別情報を示す。「氏名」は、ユーザの氏名を示す。「住所」は、ユーザの居住している住所を示す。「生年月日」は、ユーザの生年月日を示す。「年齢」は、ユーザの年齢を示す。なお、各項目の情報は概念的に示したものであり、例えば、「住所」の項目には、実際にはユーザが居住している都道府県名や市町村名等が記憶される。
「本人確認書類」は、ユーザを確認するための書類である。言い換えれば、本人確認書類は、管理装置100に登録されるユーザ情報を証明するための書類である。本人確認書類は、例えば、住民票や免許証などの公的な書類である。例えば、ユーザは、管理ツールでユーザ自身の情報を入力するとともに、管理装置100の管理者等に公的な書類を送付する。管理装置100の管理者は、管理ツールで入力された情報と本人確認書類とを照合し、情報の信頼性が確認された場合に、ユーザ情報を管理装置100に登録する。なお、管理装置100は、通信ネットワークを介して公的に証明された情報としてユーザ情報を受け付けた場合には、管理者の入力等によらず、受け付けた情報をユーザ情報としてユーザ情報記憶部121に登録してもよい。
「連絡ユーザ」は、登録されたユーザの代わりに管理装置100に連絡を行ったり、管理装置100からの連絡を受け付けたりすることを許可されたユーザを示す。例えば、登録を行ったユーザが死亡するなどして、ユーザ本人から死亡届を管理装置100に通知できない状態となった場合、管理装置100は、連絡ユーザに設定されたユーザからの死亡届の連絡を正当な連絡として受け付けることができる。なお、連絡ユーザとして登録される情報は、ユーザの氏名等ではなく、例えば、ユーザの代わりに管理装置100との情報のやり取りを認められたユーザが使用するユーザ端末10の識別情報等であってもよい。
すなわち、図3では、ユーザ情報記憶部121に記憶される情報として、ユーザID「U01」で識別されるユーザの氏名は「AAA」であり、住所は「BBB」であり、生年月日は「19CC/CC/CC」であり、年齢は「DD」であり、これらの個人情報を確認した本人確認書類は「住民票」であり、また、ユーザU01の代わりに管理装置100との連絡が認められているユーザには、「ユーザU02」や「ユーザU03」や「ユーザU04」が設定されている、という一例を示している。
(承継設定記憶部122について)
承継設定記憶部122は、ユーザが設定した承継に関する情報を記憶する。ここで、図4に、実施形態に係る承継設定記憶部122の一例を示す。図4は、実施形態に係る承継設定記憶部122の一例を示す図である。図4に示した例では、承継設定記憶部122は、「ユーザID」、「イベント」、「証明書」、「通知先」、「承継設定」といった項目を有する。
「ユーザID」は、ユーザを識別する識別情報を示す。「イベント」は、ユーザに発生するイベントの種類を示す。「証明書」は、イベントが発生したことを証明する書類を示す。証明書は、イベントごとに異なっていてもよい。例えば、イベントが「死亡」である場合の証明書は、戸籍表や火葬許可証や医師診断書等の公的な書類である。なお、図4に示した証明書は一例であり、管理装置100がイベントの発生を証明するものとして信頼性を有すると判定した書類やデータについては、証明書として認められる。例えば、ユーザU01が死亡した場合には、管理装置100側は、ユーザU01の連絡ユーザであるユーザU02や、ユーザU03や、ユーザU04から、イベントが発生した連絡とともに、署名書を取得する。管理装置100の管理者は、イベントと証明書とを照合し、情報の信頼性が確認された場合に、イベントに応じたフラグをユーザU01に設定する。
「通知先」は、イベントが発生した場合に、イベントの発生及び承継処理の内容が通知されるサービス提供者を示す。「承継設定」は、ユーザが個別に設定する承継処理の詳細内容を示す。なお、図4の例では、承継設定は、「E01」といった概念で示しているが、実際には、サービスを承継する人物を特定する情報や、承継処理として行う処理内容などが記憶される。
すなわち、図4では、承継設定記憶部122に記憶される情報として、ユーザID「U01」で識別されるユーザにイベント「死亡」が発生した場合には、イベントを証明する証明書として、「戸籍表」や「火葬許可証」や「医師診断書」が必要であり、当該イベントに対応する通知先は、「生命保険会社」や「金融機関」や「SNS」や「クラウドサービス」であり、それぞれの承継設定は「E01」、「E02」、「E03」、「E04」として設定されている、という一例を示している。
ここで、ユーザが設定する承継設定について、図5を用いて説明する。図5は、実施形態に係る承継設定の一例を示す図である。図5に示すように、承継設定は、設定されるサービスごとに異なる情報を含んでいてもよい。
例えば、承継設定E01は、「ユーザID」、「承継者」、「保険番号」、「伝達情報」といった項目を有する。「ユーザID」は、ユーザを識別する識別情報を示す。「承継者」は、ユーザU01がサービスの手続に関する権限を承継するユーザ名を示す。「保険番号」は、ユーザU01が契約している保険内容を特定する番号を示す。「伝達情報」は、ユーザU01が承継者やサービス側に対して承継の内容を伝達するメッセージや、承継の詳細な内容を示す。
例えば、承継設定E02は、「ユーザID」、「承継者」、「口座番号」、「伝達情報」といった項目を有する。「ユーザID」、「承継者」、「伝達情報」は、承継設定E01で説明した同様の項目に対応する。「口座番号」は、ユーザU01が契約している金融機関における口座を特定する番号を示す。
例えば、承継設定E03は、「ユーザID」、「承継者」、「アカウント」、「承継後設定」といった項目を有する。「ユーザID」、「承継者」は、承継設定E01で説明した同様の項目に対応する。「アカウント」は、ユーザU01が利用しているSNSのアカウントを識別する識別情報を示す。
「承継後設定」は、ユーザU01からアカウントが承継されるにあたり、承継されたSNSの情報に対してどのような取扱いを認めるかを示す。例えば、「承継後設定」が「編集を許可」である場合は、ユーザU01のアカウントLLLを承継したユーザU02が、ユーザU01のアカウントLLLに保持されている情報等を自由に編集することが許可されていることを示す。例えば、「承継後設定」が「公開のみ」である場合は、ユーザU01のアカウントMMMを承継したユーザU04が、ユーザU01のアカウントMMMに保持されている情報等を編集できないものの、公開したり、保持し続けたりすることができることを示している。例えば、「承継後設定」が「消去」である場合は、ユーザU01のアカウントNNNについては、アカウントそのものや、保持されている情報を消去する処理が行われることを示す。
なお、図5に示した承継設定は、一例であり、図5に示した設定以外であっても、承継設定として、サービスごとに種々の設定が登録されてもよい。
(制御部130について)
図2に戻って説明を続ける。制御部130は、例えば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、管理装置100内部の記憶装置に記憶されている各種プログラム(管理プログラムの一例に相当)がRAMを作業領域として実行されることにより実現される。また、制御部130は、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。
実施形態に係る制御部130は、図2に示すように、受付部131と、取得部132と、選択部133と、送信部134とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部130の内部構成は、図2に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。
(受付部131について)
受付部131は、各種情報を受け付ける。例えば、受付部131は、管理装置100が提供する承継に関するプラットフォームへの登録をユーザから受け付ける。そして、受付部131は、ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付ける。
また、受付部131は、対応付けを行ったサービスごとの承継設定を受け付ける。すなわち、受付部131は、ユーザ側でイベントが発生した場合にサービス側で実行される承継処理の内容の設定を受け付ける。具体的には、受付部131は、死亡や要介護認定などユーザ本人が手続きを行うことが困難となるイベントが発生した場合には、サービスにおける手続の権限を所定のユーザに承継させる、といった設定を受け付ける。また、受付部131は、例えばユーザがSNSやクラウド系サービス等のネットワークサービスを利用している場合には、それらのサービスで保持されているデータの取り扱い等の設定を受け付ける。受付部131は、ユーザから受け付けた情報をユーザ情報記憶部121や承継設定記憶部122に適宜記憶する。
なお、受付部131は、管理装置100の管理者等から、ユーザから受け付けた情報がユーザから送付された公的な証明書により確認されたこと等の情報の入力を受け付けてもよい。また、受付部131は、ユーザや管理装置100の管理者等から、登録された承継設定に関する変更や修正などを受け付けてもよい。
また、受付部131は、ユーザ端末10から各種情報を受け付けるにあたり、承継処理を管理する管理ツールを提供してもよい。例えば、管理ツールは、ユーザ端末10上で表示されるユーザインターフェイスを有する。そして、受付部131は、管理ツールを介して、ユーザ端末10から承継処理の設定等の登録を受け付ける。
(取得部132について)
取得部132は、各種情報を取得する。具体的には、取得部132は、ユーザ側で発生するイベントに関する情報であるイベント情報を取得する。例えば、取得部132は、イベント情報として、受付部131によって登録されたユーザが死亡したことや、要介護認定を受けたこと、成年後見人がついたこと、結婚したこと、身体障害者の認定を受けたこと、破産したこと、引っ越しをしたこと等、ユーザの身上で発生する事象に関する情報を取得する。
なお、取得部132は、イベント情報を取得する際には、公的な証明書によって証明されたイベント情報を取得するようにしてもよい。この場合、取得部132は、例えば管理装置100の管理者等から人為的に確認されたイベント情報を、当該管理者等から入力されることにより取得する。また、取得部132は、ユーザのイベント情報を公的に管理するシステムからイベント情報を取得することが可能な場合には、公的なシステムからイベント情報を取得してもよい。例えば、取得部132は、受付部131によって登録されたユーザが死亡したことを承継者等から通知された場合に、公的なシステムに当該ユーザの情報を問い合わせる。そして、取得部132は、イベント情報として、公的に認証された、当該ユーザの死亡情報を取得する。この場合、取得部132は、例えば、ユーザ1人1人に公的に発行される識別情報(例えば、マイナンバー(登録商標)等)に基づいて、公的なシステムに問い合わせを行うことによって、イベント情報を取得してもよい。
また、取得部132は、サービス提供装置50から各種情報を取得してもよい。例えば、取得部132は、受付部131によってユーザから受け付けられた承継設定のうち、サービスに関する情報であって、ユーザから受け付けた情報では不足している情報等をサービス提供装置50から取得する。例えば、取得部132は、ユーザから生命保険に関する保険番号等を取得していない場合に、ユーザ識別情報等に基づいて、保険番号を生命保険会社によって管理されるサービス提供装置50から取得するようにしてもよい。
また、取得部132は、サービス側で承継処理が実行された場合に、実行された処理の内容をサービス側から取得してもよい。例えば、取得部132は、サービス提供装置50との相互の通信を確立することにより、サービス側で行われた処理内容をサービス提供装置50から取得する。
取得部132は、取得した情報をユーザ情報記憶部121や承継設定記憶部122に適宜記憶する。また、取得部132は、取得した情報を送信部134に送り、例えばユーザ端末10に情報を送信させるようにしてもよい。
なお、取得部132は、上述した管理ツールを介して、イベント情報を取得してもよい。例えば、取得部132は、管理ツールを介して、イベントが発生した旨をユーザ端末10から取得する。また、取得部132は、ユーザ端末10から取得したイベントに関して、証明書による証明を必要とする場合には、その旨を管理ツール上に表示し、ユーザに証明書を管理装置100側に送付することを促してもよい。
(選択部133について)
選択部133は、イベントに応じたサービスを選択する。具体的には、選択部133は、受付部131によって登録されたユーザとサービスとの対応付けのうち、取得部132が取得したイベント情報に応じたユーザとサービスとの対応付けを選択する。
例えば、選択部133は、ユーザから受け付けた承継設定に従い、ユーザ側で発生したイベントに応じたサービスを選択する。すなわち、選択部133は、ユーザ側で「死亡」というイベントが発生した場合に、ユーザが、「生命保険会社」と、「金融機関」と、「SNS提供事業者」と、「クラウドサービス提供事業者」とが提供するサービスに対する承継処理を設定していることを参照する。そして、選択部133は、取得部132によってイベント情報を取得された場合に、承継処理を実行させるサービスとして、ユーザが設定した上記サービスを選択する。
なお、選択部133は、ユーザの設定によりサービスを選択するとともに、イベントに応じて予め設定されたサービスを選択するようにしてもよい。例えば、選択部133は、所定のユーザに「死亡」というイベントが発生した場合、少なくとも「生命保険会社」は承継処理を実行させるサービス提供先として選択するなど、予めイベントごとに承継処理の通知を行うサービスを管理装置100側で設定しておく。そして、選択部133は、ユーザによる手動の設定によらず、管理装置100側で設定された仕様に従い、サービスを選択する。これにより、選択部133は、ユーザの手間を省くことができる。
(送信部134について)
送信部134は、各種情報を送信する。例えば、送信部134は、ユーザに対応付けられるサービス提供者であって、取得部132によって取得されたイベント情報に関係するサービス提供者に対して、当該イベント情報に基づく通知を送信する。イベント情報に基づく通知とは、例えば、発生したイベントの種類、イベントが発生したユーザの識別情報、ユーザによって設定されていた承継処理の内容等である。
送信部134は、選択部133によって選択されたサービスに対して、イベント情報に基づく通知を送信する。すなわち、送信部134は、ユーザによって設定された内容に従ってサービスに通知を送信する場合もあるし、発生したイベントに応じて管理装置100側で通知を送信するサービスとして定められたサービスに通知を送信する場合もある。また、送信部134は、受付部131によってユーザに対応付けられるサービス提供者として、複数のサービス提供者の登録が受け付けられている場合には、取得された一つのイベント情報に基づく通知を複数のサービス提供者に対して送信するようにしてもよい。
また、送信部134は、各サービス側で承継処理が実行された場合に、承継処理の内容をユーザ端末10に送信してもよい。例えば、送信部134は、サービス提供装置50から送信された情報に基づいて、ユーザ端末10に承継処理の内容を送信する。このような情報の伝達は、送信部134から直接ユーザ端末10に情報が送信されてもよいし、管理装置100が提供する管理ツールを介して、ユーザに伝達されてもよい。この場合、送信部134が通知を送信する送信先は、イベント情報を送信したユーザ端末10に限られない。例えば、送信部134は、管理装置100に登録されているユーザ、言い換えれば、イベント情報を通知したユーザ、又は当該イベント情報に関して登録を受け付けているユーザ(連絡ユーザ、承継者等)に対して、承継処理の内容を送信するようにしてもよい。
〔3.処理手順〕
次に、図6及び図7を用いて、実施形態に係る管理装置100による処理の手順について説明する。図6は、実施形態に係る処理手順を示すフローチャート(1)である。図6では、管理装置100がユーザ端末10から承継処理に関する登録を受け付ける処理の流れについて説明する。
図6に示すように、管理装置100に係る受付部131は、ユーザ端末10から承継設定の登録を受け付けたか否かを判定する(ステップS101)。承継設定の登録を受け付けていない場合には、受付部131は、受け付けるまで待機する(ステップS101;No)。
一方、承継設定の登録を受け付けた場合には(ステップS101;Yes)、受付部131は、受け付けた内容に従い、ユーザとサービスとを対応付けて登録する(ステップS102)。
また、受付部131は、イベントが発生した場合に通知を行う送信先となるサービスに関して、イベント情報ごとの通知先の設定を登録する(ステップS103)。なお、受付部131は、サービスで実行される承継処理の内容の設定を受け付けてもよい。これにより、受付部131による、承継に関する登録処理が完了する。なお、受付部131は、登録を行った後であっても、任意のタイミングで、ユーザから登録情報の変更や更新を受け付けてもよい。
次に、図7を用いて、管理装置100が各サービスに対して承継処理を実行させる処理の流れについて説明する。図7は、実施形態に係る処理手順を示すフローチャート(2)である。
図7に示すように、管理装置100に係る取得部132は、管理装置100に登録を行ったユーザ本人、又は、連絡ユーザからイベント情報を取得したか否かを判定する(ステップS201)。イベント情報を取得していない場合には、取得部132は、取得するまで待機する(ステップS201;No)。
一方、取得部132がイベント情報を取得した場合には(ステップS201;Yes)、選択部133は、イベント情報に含まれるユーザの識別情報に基づいて、イベントに関するユーザを特定する(ステップS202)。
そして、選択部133は、イベント情報に応じた通知先を選択する。続いて、送信部134は、イベント情報に応じた通知先へ通知を送信する(ステップS203)。その後、取得部132は、承継処理等に関するサービスからのフィードバックがあったか否かを判定する(ステップS204)。
サービスからのフィードバックがあった場合には(ステップS204;Yes)、送信部134は、サービスが実行した承継の内容を承継者等(例えば、連絡ユーザ)に通知する(ステップS205)。サービスからのフィードバックがない場合や(ステップS204;No)、サービスが実行した承継の内容を承継者等に通知した場合には、管理装置100は、承継に関する処理を終了する。
〔4.変形例〕
上述した管理システム1による処理は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、管理システム1の他の実施形態(変形例)について説明する。
〔4−1.サービス側からの通知〕
上記実施形態では、ユーザ又は連絡ユーザがイベントの発生を管理装置100に送信する例を示した。しかし、イベントの発生は、サービス側から管理装置100に送信されてもよい。この点について、図8を用いて説明する。
図8に示す例において、ユーザU01は、図1と同じく、管理装置100に対して承継設定を登録する(ステップS21)。
その後、ユーザU01にイベントが発生したとする。例えば、ユーザU01が死亡したというイベントが発生した場合に、ユーザU01の死亡を知り得たユーザU02によって、イベントの発生が通知される。この場合、ユーザU01が管理装置100に承継に関する登録を行っていることをユーザU02が知らない場合等には、ユーザU02は、ユーザU02が死亡したことを生命保険会社等のサービスに連絡する場合がある。図8の例では、ユーザU02は、生命保険会社が管理するサービス提供装置50にイベントの発生を通知するものとする(ステップS22)。
サービス提供装置50は、ユーザU02からの通知を受けて、ユーザU01に関する承継を実行する(ステップS23)。この場合、サービス提供装置50が実行する処理は、管理装置100に登録されている承継処理と同一でなくてもよい。例えば、サービス提供装置50は、承継処理として、ユーザU02が死亡した場合に所定の保険金を支払う等、通常の生命保険会社の業務を行ってもよい。サービス提供装置50は、承継の結果をユーザ側に通知する(ステップS24)。
ここで、サービス提供装置50は、通知を受けたイベントに関するユーザがユーザU01であり、管理装置100に承継処理を登録しているユーザであることを参照する。そして、サービス提供装置50は、ステップS22で受け付けたイベントの発生を管理装置100に通知する(ステップS25)。
管理装置100は、サービス提供装置50から通知されたイベント情報に基づいて、イベントが発生したユーザU01を特定する。そして、管理装置100は、発生したイベントがユーザU01に関するものであることを特定したのち、ユーザU01の承継に関する設定を参照する。
そして、管理装置100は、イベントに応じた通知先を選択する(ステップS26)。そして、管理装置100は、サービス提供装置50〜50のうち、通知先として設定されているサービス提供装置50に、イベントに応じた通知を送信する(ステップS27)。
管理装置100から通知を受け付けたサービス提供装置50は、ユーザU01に関する承継を実行する(ステップS28)。その後、管理装置100は、各サービス提供装置50によって行われた承継の結果をユーザ側に通知する(ステップS29)。
このように、変形例に係る管理装置100は、ユーザ側に限らず、サービス経由でイベント情報を受け付けてもよい。すなわち、管理装置100に係る取得部132は、ユーザに関するイベント情報をサービス側から取得してもよい。そして、送信部134は、イベント情報の送信元であるサービス以外の他のサービスであって、ユーザと対応付けられている他のサービスに対して、当該イベント情報に基づく通知を送信する。この場合であっても、管理装置100は、登録された内容に従い、各サービス提供装置50にイベントの発生を通知し、承継処理を実行させることができる。すなわち、ユーザ側は、管理装置100に承継に関する登録を行っていることで、所定のサービスのみにイベントが発生したことを通知した場合であっても、登録しておいた複数の承継処理を実行させることができる。このようにして、管理装置100は、承継に関するユーザの手間の軽減を図ることができる。
〔4−2.承継処理〕
上記実施形態における承継処理は、様々な態様で実施されてよい。例えば、ユーザU01は、金融機関に関する承継処理として、家族であるユーザU02へ口座を承継させるとともに、伝達情報としてメッセージを登録しておき、承継の際には、金融機関側がメッセージを確認できるようにしておいてもよい。
例えば、ユーザU01は、承継者に向けたメッセージとして、当該金融機関における口座を保持すること、といったメッセージを登録する。金融機関側は、承継処理の際に、メッセージを参照する。そして、金融機関側は、ユーザU02へ口座が承継するとともに、当該メッセージをユーザU02へ伝達する。これにより、金融機関側は、ユーザU01が亡くなった後でも、自身が管理する口座が解約されないよう承継者に依頼するといった営業活動を円滑に行うことができる。
また、管理装置100は、ユーザU01が許可する場合には、あるサービスにおける承継者の情報を共有させてもよい。これにより、例えば、生命保険に関してユーザU01の承継者となるユーザU02に対して、それまで取引のなかった金融機関がユーザU02に営業を行うなど、事業活動を活性化させることができる。なお、ユーザU02は、管理装置100を利用することで、種々の態様で実施される承継処理について、各サービスへの連絡を効率よく行ったり、各サービスで実施される処理を一元的に把握したりすることができるため、煩雑化させずに各サービスへの対応を行うことができる。
〔4−3.通知順序〕
管理装置100は、各サービスに通知を行う際に、同時に通知を送信するのではなく、順序を付けて通知を送信してもよい。すなわち、管理装置100は、イベント情報に基づく通知を受信したサービス側で実行された承継に関する処理の内容を取得し、取得されたサービス側で実行された承継に関する処理の内容に基づいて、さらに他のサービス提供者にイベント情報に基づく通知を送信するようにしてもよい。例えば、金融機関における承継処理において、イベントが発生したユーザの口座が凍結すると不都合が生じる場合等には、管理装置100は、金融機関に先立って、他のサービス提供装置50に通知を送信してもよい。
また、サービス提供装置50は、自身における承継処理が完了した場合に、かかる処理のフィードバックを管理装置100に送信するようにしてもよい。管理装置100は、サービス提供装置50からのフィードバックを受けて、次の順序となる他のサービス提供装置50にイベントに関する通知を送信する。これにより、管理装置100は、サービスごとに順序付けて行う通知を円滑に行うことができる。
〔4−4.承継処理の自動登録〕
管理装置100は、全ての承継処理や選択先をユーザの設定に委ねるのではなく、自動で行ってもよい。すなわち、管理装置100は、予め、イベントに対応した通知先や承継処理の雛形を予め設定しておく。そして、管理装置100は、ユーザが未設定の項目に関しては、雛形に従った処理を行う。例えば、管理装置100は、イベントが死亡である場合には、少なくとも、ユーザが契約している生命保険会社や金融機関には通知が送信される、といった雛形を有しておく。また、例えば、管理装置100は、ユーザが利用しているネットワークサービス関連のデータは、特段の指示の無い限り、アクセス不可にしたり消去したりする、といった雛形を有しておく。これにより、ユーザは、全ての処理を一つ一つ設定する手間が省けるため、承継に関する処理を効率的に行うことができる。
〔4−5.サービス〕
管理装置100が通知先として選択するサービスは、上記実施形態で示した例に限られない。例えば、管理装置100は、イベントの発生を受けて所定の対象者にメッセージを送付するメッセージサービス事業者や、ユーザ端末10の通信回線を提供する通信事業者などに、イベントに応じた通知を行ってもよい。
また、管理装置100は、イベントが結婚の場合等、複数のユーザに関するイベント情報を取得してもよい。そして、管理装置100は、取得された複数のユーザが関連するイベント情報に基づく通知を、複数のユーザのいずれにも対応付けられているサービス提供者に送信してもよいし、複数のユーザのいずれかに対応付けられているサービス提供者に対して送信するようにしてもよい。このように、管理装置100は、対象となるユーザが複数である場合や、サービスが複数のユーザにまたがる場合であっても、各々に対応する柔軟な処理を行うことができる。
〔4−6.対応付けの自動登録〕
管理装置100は、ユーザ側からの申請のみならず、サービス側からの申請に応じて、ユーザとサービスとの対応付けを登録してもよい。
例えば、生命保険会社は、まだ管理装置100によって対応付けされていないユーザであるユーザU05から、生命保険会社が提供する保険への申し込みを受け付けたとする。この場合、生命保険会社によって管理されるサービス提供装置50は、ユーザU05に対して保険番号を発行する。そして、サービス提供装置50は、管理装置100に対して、発行した保険番号を通知する。管理装置100は、サービス提供装置50から送信された保険番号を受け付けるとともに、ユーザU05に対応するユーザIDを発行する。そして、管理装置100は、ユーザU05と、生命保険会社とを対応付けて登録する。なお、ユーザU05は、ユーザIDが既に発行されているユーザであってもよい。すなわち、管理装置100は、管理プラットフォームを既に利用しているユーザであっても、新たに何らかのサービスに加入したユーザに関しては、サービス側からの申請に応じて、サービスとユーザとの対応付けを行うようにしてもよい。
このように、管理装置100は、ユーザと対応付けられていないサービス提供者であって、当該ユーザからサービスの提供を受ける旨の申し出を受け付けたサービス提供者から、当該ユーザとサービス提供者との対応付けの申し出を受け付ける。そして、管理装置100は、サービス提供者からの申し出に応じて、当該ユーザとサービス提供者とを対応付けて登録する。このように、管理装置100は、ユーザ側からの申請のみならず、サービス側からの申請に応じて、ユーザとサービスとの対応付けを行うことができる。これにより、ユーザは、あるサービスを利用する際に、自動的に管理装置100に対応付けを登録することができるため、自ら登録処理を行う手間が省けるため、承継処理に関する手間を軽減することができる。
〔5.ハードウェア構成〕
また、上述してきた実施形態に対応する管理装置は、例えば図9に示すような構成のコンピュータ1000によって実現される。以下、管理装置100を例に挙げて説明する。図9は、管理装置100の機能を実現するコンピュータ1000の一例を示すハードウェア構成図である。コンピュータ1000は、CPU1100、RAM1200、ROM1300、HDD1400、通信インターフェイス(I/F)1500、入出力インターフェイス(I/F)1600、及びメディアインターフェイス(I/F)1700を有する。
CPU1100は、ROM1300又はHDD1400に記憶されたプログラムに基づいて動作し、各部の制御を行う。ROM1300は、コンピュータ1000の起動時にCPU1100によって実行されるブートプログラムや、コンピュータ1000のハードウェアに依存するプログラム等を記憶する。
HDD1400は、CPU1100によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス1500は、通信網500(通信ネットワーク)を介して他の機器からデータを受信してCPU1100へ送り、CPU1100が作成したデータを、通信網500を介して他の機器へ送信する。
CPU1100は、入出力インターフェイス1600を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。CPU1100は、入出力インターフェイス1600を介して、入力装置からデータを取得する。また、CPU1100は、入出力インターフェイス1600を介して作成したデータを出力装置へ出力する。
メディアインターフェイス1700は、記録媒体1800に記憶されたプログラム又はデータを読み取り、RAM1200を介してCPU1100に提供する。CPU1100は、かかるプログラムを、メディアインターフェイス1700を介して記録媒体1800からRAM1200上にロードし、ロードしたプログラムを実行する。記録媒体1800は、例えばDVD(Digital Versatile Disc)、PD(Phase change rewritable Disk)等の光学記録媒体、MO(Magneto-Optical disk)等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
例えば、コンピュータ1000が実施形態に係る管理装置100として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部130の機能を実現する。また、HDD1400には、記憶部120内のデータが記憶される。コンピュータ1000のCPU1100は、これらのプログラムを記録媒体1800から読み取って実行するが、他の例として、他の装置から通信網500を介してこれらのプログラムを取得してもよい。
〔6.その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図2に示した受付部131と取得部132とは統合されてもよい。また、例えば、記憶部120に記憶される情報は、通信ネットワークを介して、外部に備えられた記憶装置に記憶されてもよい。
また、例えば、上記実施形態では、管理装置100が、イベント情報を取得する取得部132と、通知先を選択する選択部133とを備える例を示した。しかし、管理装置100は、イベント情報を取得する等、情報の送受信を行うフロントサーバと、通知先を選択する等の処理を行うバックエンドサーバとに分離されてもよい。この場合、説明してきた管理装置100による処理は、例えば、フロントエンドサーバとバックエンドサーバとを有する管理システム1によって実現される。
また、上述してきた各実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
〔7.効果〕
上述してきたように、実施形態に係る管理装置100は、受付部131と、取得部132と、送信部134とを有する。受付部131は、ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付ける。取得部132は、ユーザに関するイベント情報を取得する。送信部134は、ユーザに対応付けられるサービス提供者であって、取得部132によって取得されたイベント情報に関係するサービス提供者に対して、当該イベント情報に基づく通知を送信する。
このように、実施形態に係る管理装置100は、ユーザが利用するサービスとユーザとを対応付けておき、ユーザにイベントが発生した場合には、ユーザと対応付けられているサービスのうち、イベントに応じた通知先に通知を送信することができる。これにより、管理装置100は、承継に関するユーザの利便性を向上させるとともに、承継に関するユーザの手間の軽減を図ることができる。
また、受付部131は、ユーザに対応付けられるサービス提供者として、複数のサービス提供者の登録を受け付ける。送信部134は、取得部132によって取得された一つのイベント情報に基づく通知を複数のサービス提供者に対して送信する。
このように、実施形態に係る管理装置100は、ユーザが利用する複数のサービスに関する承継処理を包括的に管理することができる。すなわち、管理装置100は、一つのイベントに対して、複数のサービスに関して承継処理を行わせることができるため、ユーザの利便性を向上させることができる。また、管理装置100によれば、承継を受けるユーザにとっても、管理装置100に対する通知のみで複数のサービス提供者への連絡を済ませることができるため、承継される側のユーザに関する承継処理の手間を軽減させることもできる。
また、取得部132は、ユーザに関するイベント情報をサービス提供者側から取得してもよい。送信部134は、イベント情報の送信元であるサービス提供者以外の他のサービス提供者であって、ユーザと対応付けられている他のサービス提供者に対して、当該イベント情報に基づく通知を送信する。
このように、実施形態に係る管理装置100は、サービス側からイベント情報を取得してもよい。すなわち、ユーザは、ある一つのサービス提供者にイベントの発生を通知することで、自身が関わる全てのサービスにイベントの発生を通知させたり、承継処理を実行させたりすることができる。これにより、管理装置100は、承継に関するユーザの負担を軽減させることができる。
また、実施形態に係る管理装置100は、受付部131によって受け付けられたサービス提供者のうち、イベント情報が含む内容に基づいて、当該イベント情報に関連するサービス提供者を選択する選択部133をさらに有する。送信部134は、選択部133によって選択されたサービス提供者に対して、イベント情報に基づく通知を送信する。
このように、実施形態に係る管理装置100は、イベントに応じて、通知を行うサービス提供者を選択することができる。このため、管理装置100は、死亡等に限らず、ユーザの身上に発生しうるあらゆるイベントを包括的に管理することができる。これにより、管理装置100は、承継に関するユーザの手間の軽減を図ることができる。
また、選択部133は、イベント情報に応じて、予め管理装置100側が通知先として設定しているサービス提供者のうち、ユーザと対応付けられているサービス提供者を選択する。送信部134は、選択部133によって選択されたサービス提供者に対して、イベント情報に基づく通知を送信する。
このように、実施形態に係る管理装置100は、全てのサービスに対して通知先や承継処理の内容の登録をユーザから受け付けることを要しない。すなわち、管理装置100は、予め設定された内容に従い、通知先の選択や、通知の送信を行うようにしてもよい。これにより、管理装置100は、承継に関するユーザの手間の軽減を図ることができる。
また、取得部132は、複数のユーザが関連するイベント情報(例えば、結婚等)を取得する。送信部134は、取得部132によって取得された複数のユーザが関連するイベント情報に基づく通知を、当該複数のユーザのいずれにも対応付けられているサービス提供者、又は当該複数のユーザのいずれかに対応付けられているサービス提供者に対して送信する。
このように、実施形態に係る管理装置100は、複数のユーザに関連するイベントであっても、それぞれのユーザに対応するサービス提供者に対して通知を送信することができる。このように、管理装置100は、承継に関するプラットフォームとして、ユーザのニーズに応えた柔軟な処理を実現することができる。
また、取得部132は、イベント情報に基づく通知を受信したサービス提供者側で実行された承継に関する処理の内容を取得する。送信部134は、取得部132によって取得されたサービス提供者側で実行された承継に関する処理の内容に基づいて、さらに他のサービス提供者にイベント情報に基づく通知を送信する。
このように、実施形態に係る管理装置100は、あるサービスで実行された承継処理の内容に応じて、次の順序となるサービス側に通知を送信するようにしてもよい。これにより、管理装置100は、承継に関するプラットフォームとして、ユーザのニーズに応えた柔軟な処理を実現することができる。
また、取得部132は、イベント情報に基づく通知を受信したサービス提供者側で実行された承継に関する処理の内容を取得する。送信部134は、イベント情報を通知したユーザ、又は当該イベント情報に関して登録を受け付けているユーザに対して、サービス提供者側で実行された承継に関する処理の内容に基づく通知を送信する。
このように、実施形態に係る管理装置100は、あるサービスで実行された承継処理の内容に基づく通知(承継処理の結果等)をユーザ側に送信することができる。例えば、管理装置100は、提供する管理ツールを介して、ユーザに承継処理の結果を通知する。これにより、ユーザは、承継処理に関する情報を一元的に管理することができるため、効率のよい承継処理を行うことができる。また、承継を受けるユーザにとっても、自身が承継を受けるサービスで行われた処理を一元的に把握することができるため、効率のよい管理を行うことができる。
また、受付部131は、所定のサービス提供者と対応付けのされていないユーザであって、当該所定のサービス提供者が提供するサービスに当該ユーザが登録された場合には、当該所定のサービス提供者から、当該所定のサービス提供者と当該ユーザとの対応付けの登録を受け付ける。
このように、実施形態に係る管理装置100は、あるサービス提供者によって登録されたユーザ(すなわち、サービスを利用しようとするユーザ)に関して、サービスとの対応付けを自動的に登録してもよい。すなわち、管理装置100によれば、ユーザは、ある一つのサービスへの申請によって管理装置100への登録を済ませることができるため、手続きの簡素化を図ることができ、承継処理の手間の軽減を図ることができる。
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
また、上述してきた「部(section、module、unit)」は、「手段」や「回路」などに読み替えることができる。例えば、取得部132は、取得手段や取得回路に読み替えることができる。
1 管理システム
10 ユーザ端末
50 サービス提供装置
100 管理装置
110 通信部
120 記憶部
121 ユーザ情報記憶部
122 承継設定記憶部
130 制御部
131 受付部
132 取得部
133 選択部
134 送信部

Claims (12)

  1. ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付け、受け付けた当該サービス提供者と当該ユーザとを対応付けた情報を記憶部に記憶する受付部と、
    前記ユーザに関するイベント情報を取得する取得部と、
    前記取得部によって取得されたイベント情報に関係するサービス提供者であって、前記記憶部において前記ユーザに対応付けられて登録されているサービス提供者に対して、当該イベント情報に基づく通知を送信する送信部と、
    を備え、
    前記取得部は、
    前記イベント情報に基づく通知を受信したサービス提供者側で実行された承継に関する処理の内容をさらに取得し、
    前記送信部は、
    前記取得部によって取得された前記サービス提供者側で実行された承継に関する処理の内容に基づいて、さらに他のサービス提供者に前記イベント情報に基づく通知を送信する、
    ことを特徴とする管理装置。
  2. ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付け、受け付けた当該サービス提供者と当該ユーザとを対応付けた情報を記憶部に記憶する受付部と、
    前記ユーザに関するイベント情報を取得する取得部と、
    前記取得部によって取得されたイベント情報に関係するサービス提供者であって、前記記憶部において前記ユーザに対応付けられて登録されているサービス提供者に対して、当該イベント情報に基づく通知を送信する送信部と、
    を備え、
    前記取得部は、
    前記イベント情報に基づく通知を受信したサービス提供者側で実行された承継に関する処理の内容を取得し、
    前記送信部は、
    前記イベント情報を通知したユーザ、又は当該イベント情報に関して登録を受け付けているユーザに対して、前記サービス提供者側で実行された承継に関する処理の内容に基づく通知を送信する、
    ことを特徴とする管理装置。
  3. 前記取得部は、
    前記ユーザに関するイベント情報を前記サービス提供者側から取得し、
    前記送信部は、
    前記取得部によって取得されたイベント情報に関係するサービス提供者であって、前記記憶部において前記ユーザに対応付けられて登録されている、前記イベント情報の送信元である前記サービス提供者以外の他のサービス提供者に対して、当該イベント情報に基づく通知を送信する、
    ことを特徴とする請求項1又は2に記載の管理装置。
  4. 前記受付部は、
    前記ユーザに対応付けられるサービス提供者として、複数のサービス提供者の登録を受け付け、
    前記送信部は、
    前記取得部によって取得された一つのイベント情報に基づく通知を複数のサービス提供者に対して送信する、
    ことを特徴とする請求項1〜3のいずれか一つに記載の管理装置。
  5. 前記受付部は、
    前記サービス提供者と前記ユーザに関するイベント情報の内容とを対応付ける情報を受け付け、受け付けた情報を前記記憶部に記憶し、
    前記取得部によって取得された前記イベント情報が含む内容と、前記受付部によって受け付けられたサービス提供者とイベント情報の内容とを対応付けた情報とを参照することにより、取得された当該イベント情報に関連するサービス提供者を選択する選択部、をさらに備え、
    前記送信部は、
    前記選択部によって選択されたサービス提供者に対して、前記イベント情報に基づく通知を送信する、
    ことを特徴とする請求項1〜4のいずれか一つに記載の管理装置。
  6. 前記選択部は、
    前記イベント情報に応じて、予め管理装置側が通知先として設定しているサービス提供者のうち、前記ユーザと対応付けられているサービス提供者を選択し、
    前記送信部は、
    前記選択部によって選択されたサービス提供者に対して、前記イベント情報に基づく通知を送信する、
    ことを特徴とする請求項に記載の管理装置。
  7. 前記取得部は、
    複数のユーザが関連するイベント情報を取得し、
    前記送信部は、
    前記取得部によって取得された複数のユーザが関連するイベント情報に基づく通知を、当該複数のユーザのいずれにも対応付けられているサービス提供者、又は当該複数のユーザのいずれかに対応付けられているサービス提供者に対して送信する、
    ことを特徴とする請求項1〜6のいずれか一つに記載の管理装置。
  8. 前記受付部は、
    所定のサービス提供者と対応付けのされていないユーザであって、当該所定のサービス提供者が提供するサービスに当該ユーザが登録された場合には、当該所定のサービス提供者から、当該所定のサービス提供者と当該ユーザとの対応付けの登録を受け付ける、
    ことを特徴とする請求項1〜7のいずれか一つに記載の管理装置。
  9. コンピュータが実行する管理方法であって、
    ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付け、受け付けた当該サービス提供者と当該ユーザとを対応付けた情報を記憶部に記憶する受付工程と、
    前記ユーザに関するイベント情報を取得する取得工程と、
    前記取得工程によって取得されたイベント情報に関係するサービス提供者であって、前記記憶部において前記ユーザに対応付けられて登録されているサービス提供者に対して、当該イベント情報に基づく通知を送信する送信工程と、
    を含み、
    前記取得工程は、
    前記イベント情報に基づく通知を受信したサービス提供者側で実行された承継に関する処理の内容をさらに取得し、
    前記送信工程は、
    前記取得工程によって取得された前記サービス提供者側で実行された承継に関する処理の内容に基づいて、さらに他のサービス提供者に前記イベント情報に基づく通知を送信する、
    ことを特徴とする管理方法。
  10. ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付け、受け付けた当該サービス提供者と当該ユーザとを対応付けた情報を記憶部に記憶する受付手順と、
    前記ユーザに関するイベント情報を取得する取得手順と、
    前記取得手順によって取得されたイベント情報に関係するサービス提供者であって、前記記憶部において前記ユーザに対応付けられて登録されているサービス提供者に対して、当該イベント情報に基づく通知を送信する送信手順と、
    をコンピュータに実行させ、
    前記取得手順は、
    前記イベント情報に基づく通知を受信したサービス提供者側で実行された承継に関する処理の内容をさらに取得し、
    前記送信手順は、
    前記取得手順によって取得された前記サービス提供者側で実行された承継に関する処理の内容に基づいて、さらに他のサービス提供者に前記イベント情報に基づく通知を送信する、
    ことを特徴とする管理プログラム。
  11. コンピュータが実行する管理方法であって、
    ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付け、受け付けた当該サービス提供者と当該ユーザとを対応付けた情報を記憶部に記憶する受付工程と、
    前記ユーザに関するイベント情報を取得する取得工程と、
    前記取得工程によって取得されたイベント情報に関係するサービス提供者であって、前記記憶部において前記ユーザに対応付けられて登録されているサービス提供者に対して、当該イベント情報に基づく通知を送信する送信工程と、
    を含み、
    前記取得工程は、
    前記イベント情報に基づく通知を受信したサービス提供者側で実行された承継に関する処理の内容を取得し、
    前記送信工程は、
    前記イベント情報を通知したユーザ、又は当該イベント情報に関して登録を受け付けているユーザに対して、前記サービス提供者側で実行された承継に関する処理の内容に基づく通知を送信する、
    ことを特徴とする管理方法。
  12. ユーザに所定のサービスを提供する事業者であるサービス提供者と当該ユーザとの対応付けの登録を受け付け、受け付けた当該サービス提供者と当該ユーザとを対応付けた情報を記憶部に記憶する受付手順と、
    前記ユーザに関するイベント情報を取得する取得手順と、
    前記取得手順によって取得されたイベント情報に関係するサービス提供者であって、前記記憶部において前記ユーザに対応付けられて登録されているサービス提供者に対して、当該イベント情報に基づく通知を送信する送信手順と、
    をコンピュータに実行させ、
    前記取得手順は、
    前記イベント情報に基づく通知を受信したサービス提供者側で実行された承継に関する処理の内容を取得し、
    前記送信手順は、
    前記イベント情報を通知したユーザ、又は当該イベント情報に関して登録を受け付けているユーザに対して、前記サービス提供者側で実行された承継に関する処理の内容に基づく通知を送信する、
    ことを特徴とする管理プログラム。
JP2015231401A 2015-11-27 2015-11-27 管理装置、管理方法及び管理プログラム Active JP6436895B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2015231401A JP6436895B2 (ja) 2015-11-27 2015-11-27 管理装置、管理方法及び管理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2015231401A JP6436895B2 (ja) 2015-11-27 2015-11-27 管理装置、管理方法及び管理プログラム

Publications (2)

Publication Number Publication Date
JP2017097745A JP2017097745A (ja) 2017-06-01
JP6436895B2 true JP6436895B2 (ja) 2018-12-12

Family

ID=58817023

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015231401A Active JP6436895B2 (ja) 2015-11-27 2015-11-27 管理装置、管理方法及び管理プログラム

Country Status (1)

Country Link
JP (1) JP6436895B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6865716B2 (ja) * 2017-11-14 2021-04-28 有限会社東名アソシエイツ 任意後見契約の情報処理装置、任意後見契約の情報処理方法及び任意後見契約の情報処理のためのコンピュータプログラム
JP7273388B2 (ja) * 2018-10-29 2023-05-15 ジーアーチ株式会社 事業承継支援システム
JP6937795B2 (ja) * 2019-05-20 2021-09-22 進 國府田 保険情報管理装置、情報処理方法、及びプログラム
WO2022113296A1 (ja) * 2020-11-27 2022-06-02 日本電気株式会社 流通管理装置、流通管理システムおよび流通管理方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002157324A (ja) * 2000-11-20 2002-05-31 Casio Comput Co Ltd 解約手続き代行システムおよびそのプログラム記録媒体
JP2002163347A (ja) * 2000-11-28 2002-06-07 Canon Inc 通信回線を利用した緊急時サポート用の個人情報管理システム、その制御方法および記憶媒体
US20080086314A1 (en) * 2005-12-22 2008-04-10 Yvonne Fitzpatrick Entity-Linking System to Report the Death of a Person
JP5704540B2 (ja) * 2011-11-09 2015-04-22 株式会社フォーカルワークス サービス支援装置
JP6311239B2 (ja) * 2013-08-29 2018-04-18 富士通株式会社 情報処理装置、プログラム、及び方法
US20150242814A1 (en) * 2014-02-24 2015-08-27 Rana A. Saad Systems and methods for handling social digital accounts and assets upon death or incapacitation

Also Published As

Publication number Publication date
JP2017097745A (ja) 2017-06-01

Similar Documents

Publication Publication Date Title
US8355935B2 (en) Third party information transfer
JP6436895B2 (ja) 管理装置、管理方法及び管理プログラム
EP3050280B1 (en) Network access
JP2022509488A (ja) グループ・ベースの携帯装置管理
US20220028506A1 (en) Data capturing and exchange method and system
CN103339605A (zh) 在分布式系统中管理医疗保健信息
US20130290032A1 (en) System and method for electronic health record dropoff
US20150261933A1 (en) System and method for receiving communications and providing alerts
US20160197925A1 (en) Information processing apparatus and method, and program
JP2013131131A (ja) 情報処理装置、情報処理方法及び情報処理システム
US20130152155A1 (en) Providing user attributes to complete an online transaction
KR20220117259A (ko) 제3자와 사용자 데이터 항목을 안전하고 개인적으로 공유하기 위한 방법
US10325252B2 (en) Payment management apparatus, payment management method, and storage medium
US20160180036A1 (en) Apparatus and method for processing prior authorizations for prescription drugs
US20170188239A1 (en) Control device, wireless communication control method, and wireless communication control program
JP2019046262A (ja) 情報処理装置、情報処理方法、及び情報処理プログラム
JP6867140B2 (ja) 情報処理システム、情報処理方法、及びプログラム
JP5766670B2 (ja) 個人情報開示制御装置及び方法及びプログラム
JP2020166601A (ja) 仲介サーバ、プログラム、及び情報処理方法
CA3007273A1 (en) System and method for cross-region patient data management and communication
JP7080200B2 (ja) 情報仲介システム、情報仲介方法、及びプログラム
WO2020103567A1 (zh) 一种数据处理方法、装置和计算机设备
US9424405B2 (en) Using receipts to control assignments of items of content to users
KR20120087208A (ko) 명함정보 관리 방법
US12067635B2 (en) Social media final notification system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170315

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180320

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180515

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20180717

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181002

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20181011

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181030

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181113

R150 Certificate of patent or registration of utility model

Ref document number: 6436895

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250