JP2018049535A - Ｓｎｓサーバ、ｓｎｓサーバによって実行される方法、管理者の情報処理装置、管理者の情報処理装置によって実行される方法、プログラム - Google Patents

Abstract

【課題】故人の没後に関わる情報を適切な範囲で共有することができるＳＮＳサーバを提供すること。
【解決手段】ＳＮＳサーバ１２０は、第１のユーザ（Ｃ）と、故人（Ａ）用のＳＮＳアカウントを管理する管理者（Ｂ）とを利用者に含むＳＮＳを提供するＳＮＳサーバ１２０であって、第１のユーザ（Ｃ）から、故人（Ａ）の没後に関わる情報を求めるリクエストを受信する受信部１２２１と、リクエストに対する回答内容として、第１のユーザ（Ｃ）と故人（Ａ）とのＳＮＳ上の関係に応じたものを管理者（Ｂ）に提示する提示部１２２３と、を備える。
【選択図】図３

Description

本発明は、ＳＮＳ（Social Networking Service：ソーシャル・ネットワーキング・サービス）を提供するＳＮＳサーバの技術に関するものである。

友人や恩師の墓参りをしたいときに、その墓がどこにあるのかがわからないことがある。通常は遺族等に問い合わせることになるが、その連絡先を探すのが大変なこともある。もし、故人がFacebook（登録商標）などのＳＮＳの利用者で、自身のＳＮＳサイトにお墓の情報を載せているのであれば便利である。しかし、一般に墓は死亡後に作られるため、生前に墓の情報を自身のＳＮＳサイトに載せておくことができない。一方、没後は、故人はもとより、第三者も故人のＳＮＳアカウントにログインできないため、同様に故人のＳＮＳサイトにお墓の情報を載せることができない。

もっとも、故人のアカウントを管理するアカウント管理人を設定することができるＳＮＳも存在している（参照：非特許文献１の１８２〜１８３頁）。

リンクアップ「ゼロからはじめる Facebookフェイスブック スマートガイド」（技術評論社、初版、２０１６）

しかし、アカウント管理人が故人のＳＮＳサイトに墓の情報をそのまま載せることは必ずしも望ましくない。例えば、誰もが故人の墓の所在地を見ることができると、故人との関係によっては遺族がそういった情報を伝えたくない人にまで情報が伝わるおそれがある。

そこで、本発明は、故人の没後に関わる情報を適切な範囲で共有することができるＳＮＳサーバの技術を提供することを目的とする。

本発明の一態様に係るＳＮＳサーバは、第１のユーザと、故人用のＳＮＳアカウントを管理する管理者とを利用者に含むＳＮＳを提供するＳＮＳサーバであって、第１のユーザから、故人の没後に関わる情報を求めるリクエストを受信する受信部と、リクエストに対する回答内容として、第１のユーザと故人とのＳＮＳ上の関係に応じたものを管理者に提示する提示部と、を備える。

本発明の一態様に係るＳＮＳサーバによって実行される方法は、第１のユーザと、故人用のＳＮＳアカウントを管理する管理者とを利用者に含むＳＮＳを提供するＳＮＳサーバによって実行される方法であって、第１のユーザから、故人の没後に関わる情報を求めるリクエストを受信するステップと、リクエストに対する回答内容として、第１のユーザと故人とのＳＮＳ上の関係に応じたものを管理者に提示するステップと、を含む。

本発明の一態様に係るプログラムは、第１のユーザと、故人用のＳＮＳアカウントを管理する管理者とを利用者に含むＳＮＳを提供するＳＮＳサーバに、第１のユーザから、故人の没後に関わる情報を求めるリクエストを受信することと、リクエストに対する回答内容として、第１のユーザと前記故人との前記ＳＮＳ上の関係に応じたものを管理者に提示することと、を実行させる。

本発明の一態様に係る管理者の情報処理装置は、利用者にＳＮＳを提供するＳＮＳサーバにネットワークを介して接続され、故人用のＳＮＳアカウントを管理する管理者の情報処理装置であって、故人の没後に関わる情報を登録のためＳＮＳサーバに送信する送信部と、利用者の一人である第１のユーザから、ＳＮＳサーバに登録された情報を求めるリクエストがされた場合に、ＳＮＳサーバから、リクエストに対する回答内容として第１のユーザと故人とのＳＮＳ上の関係に応じて提示された回答内容を受信する受信部と、を備える。

本発明の一態様に係る管理者の情報処理装置によって実行される方法は、利用者にＳＮＳを提供するＳＮＳサーバにネットワークを介して接続され、故人用のＳＮＳアカウントを管理する管理者の情報処理装置によって実行される方法であって、故人の没後に関わる情報を登録のためＳＮＳサーバに送信するステップと、利用者の一人である第１のユーザから、ＳＮＳサーバに登録された情報を求めるリクエストがされた場合に、ＳＮＳサーバから、リクエストに対する回答内容として第１のユーザと故人とのＳＮＳ上の関係に応じて提示された回答内容を受信するステップと、を含む。

本発明の一態様に係るプログラムは、利用者にＳＮＳを提供するＳＮＳサーバにネットワークを介して接続され、故人用のＳＮＳアカウントを管理する管理者の情報処理装置に、故人の没後に関わる情報を登録のためＳＮＳサーバに送信することと、利用者の一人である第１のユーザから、ＳＮＳサーバに登録された情報を求めるリクエストがされた場合に、ＳＮＳサーバから、リクエストに対する回答内容として第１のユーザと故人とのＳＮＳ上の関係に応じて提示された回答内容を受信することと、を実行させる。

本発明によれば、故人の没後に関わる情報を適切な範囲で共有することができる。

実施形態に係るＳＮＳサーバを含む情報処理システムの概略図である。 図１の情報処理システムにおける登録プロセスを示すフロー図であり、（ａ）は管理者を登録するフロー図であり、（ｂ）は故人の没後情報を登録するフロー図である。 図１の情報処理システムにおいて故人の没後情報を共有するプロセスを示すフロー図である。 図３のプロセスに用いる、要求者と故人とのＳＮＳ上の関係を示すテーブルの一例を示す図である。 図２及び３のプロセスで現れる画面の一例を示す模式図であり、（ａ）は故人のＳＮＳサイトの画面、（ｂ）は管理者の画面、（ｃ）要求者の画面、（ｄ）管理者の画面、（ｅ）管理者の画面、（ｆ）管理者の画面である。 図３のプロセスにおいて故人の没後情報を受信したときの、要求者の画面の一例を示す模式図である。 二次元コードを設けた墓と実施形態に係る情報処理システムとを示す概略図である。 図７の情報処理システムが二次元コードを読み込んだときの読取処理プロセスを示すフロー図である。 図７の読取処理プロセスにおいて、二次元コードを設けた墓に対する要求者のチェックインを記録したテーブルの一例を示す図である。 図７の読取処理プロセスにおいて要求者のモバイル端末の画面に現れるＷｅｂサイトの一例を示す模式図である。 図１の情報処理システムにおけるＳＮＳサーバを示すブロック図である。 図１の情報処理システムにおける管理者のクライアント端末を示すブロック図である。

上記の添付図面を参照して、本発明の好適な実施形態について説明する。

図１に示すように、情報処理システム１００は、複数のクライアント端末１１０Ａ、１１０Ｂ、１１０Ｃ−１、１１０Ｃ−２、…１１０Ｃ−Ｎ（以下、総称して「１１０」と付することもある。）及びＳＮＳサーバ１２０がネットワーク１３０に接続可能に構成されている。ネットワーク１３０は、ＬＡＮ、ＷＡＮ、有線あるいは無線のネットワーク、又は、インターネットなどで構成される。

クライアント端末１１０は、表示画面を有するコミュニケーション装置又はコンピュータで構成することができ、例えば、デスクトップ型、ラップトップ型あるいはタブレット型のコンピュータ、ＰＤＡ、携帯電話又はスマートフォンで構成される。クライアント端末１１０は、ＳＮＳサーバ１２０が提供するＳＮＳを利用するためのソフトウェア（例えば、ウェブブラウザやアプリケーション１４０）を有している。クライアント端末１１０をＳＮＳの利用者の種類で区分けすると、故人（Ａ）のクライアント端末１１０Ａと、管理者（Ｂ）のクライアント端末１１０Ｂと、要求者（Ｃ１、Ｃ２、…ＣＮ。以下、総称して「Ｃ」と付することもある。）のクライアント端末１１０Ｃ−１、１１０Ｃ−２、…１１０Ｃ―Ｎと、に分けられる。故人（Ａ）、管理者（Ｂ）及び要求者（Ｃ）は、ＳＮＳサーバ１２０が提供するＳＮＳに会員登録又は利用登録された利用者である。故人（Ａ）のクライアント端末１１０Ａは、故人（Ａ）が生前に自身のＳＮＳサイトを利用するのに使用していたものである。管理者（Ｂ）のクライアント端末１１０Ｂは、管理者（Ｂ）が故人（Ａ）用のＳＮＳアカウントを管理するのに使用するものである。管理者（Ｂ）は、例えば、故人（Ａ）の遺族又は友人のほか、エージェント（葬儀業者、法事業者、石材業者、霊園業者など）が務めることができる。要求者（Ｃ１、Ｃ２、…ＣＮ）のクライアント端末１１０Ｃ−１、１１０Ｃ−２、…１１０Ｃ―Ｎは、要求者（Ｃ１、Ｃ２、…ＣＮ）が故人（Ａ）の没後情報をリクエストするのに使用するものである。

ＳＮＳサーバ１２０は、クライアント端末１１０にＳＮＳ機能を提供する情報処理装置である。ＳＮＳサーバ１２０は、ＳＮＳ機能を利用する利用者の情報を記憶している。記憶する利用者の情報は、例えば、利用者が自身のＳＮＳアカウントにログインするためのＩＤ及びパスワードのほか、生年月日、出身地、高校、大学、職歴及び趣味等のプロフィール、さらには利用者が所属するグループ等を含むことが可能である。また、このプロフィールやグループには様々な項目を含むことが可能であり、各項目について公開範囲を設定することが可能である。そして、ＳＮＳアカウントにログインすることで表示される利用者のＳＮＳサイトにおいては、ＳＮＳの利用者同士がつながりを設定することが可能であるほか、ＳＮＳの利用者同士でグループを作成することも可能である。また、ＳＮＳサーバ１２０は、このＳＮＳを利用するためのソフトウェアとは別のソフトウェアに関して利用者が保存又は登録している連絡先にアクセス可能に構成されてもよい。詳細は図１１で後述するが、ＳＮＳサーバ１２０は、上記の利用者の情報に加えて、管理者（Ｂ）の情報や、故人（Ａ）の没後情報のほか、故人（Ａ）と要求者（Ｃ）とのＳＮＳ上の関係についての情報などを記憶する。

図２（ａ）は、故人（Ａ）用のＳＮＳアカウントを管理する管理者（Ｂ）を登録するプロセスを示すフロー図である。故人（Ａ）は、自身のＳＮＳアカウントを没後に管理する管理者（Ｂ）を生前に登録する場合、その依頼をＳＮＳサーバ１２０に送信する（Ｓ２００）。故人（Ａ）が生前に登録しなかった場合には、管理者（Ｂ）となるべき者が、故人（Ａ）の没後に管理者の登録依頼をＳＮＳサーバ１２０に送信する（Ｓ２０２）。ＳＮＳサーバ１２０は、故人（Ａ）用のＳＮＳアカウントの登録依頼を受信し（Ｓ２０４）、管理者（Ｂ）を登録する（Ｓ２０６）。そして、ＳＮＳサーバ１２０はその登録確認を管理者（Ｂ）に送信し（Ｓ２０８）、管理者（Ｂ）はこれを受信する（Ｓ２１０）。故人（Ａ）が生前に管理者登録を依頼した場合には、登録確認が故人（Ａ）にも送信され、故人（Ａ）はこれを受信する（Ｓ２１２）。なお、登録依頼を行う者と実際に管理者となる者とは異なっていてもよい。例えば、葬儀業者などが故人の遺族を管理者（Ｂ）に指定する旨の登録依頼をＳＮＳサーバ１２０に送信することも可能である。

図２（ｂ）は、故人（Ａ）の没後情報を登録するプロセスを示すフロー図である。管理者（Ｂ）は、故人（Ａ）の没後情報を登録する依頼をＳＮＳサーバ１２０に送信する（Ｓ２２０）。故人（Ａ）が生前に自身の没後情報を登録できる場合には、その依頼をＳＮＳサーバ１２０に送信することも可能である（Ｓ２２２）。例えば、墓がすでに存在している場合には、故人（Ａ）は生前に自身の墓情報の登録依頼をＳＮＳサーバ１２０に送信することができる。ＳＮＳサーバ１２０は、没後情報の登録依頼を受信し（Ｓ２２４）、没後情報を登録する（Ｓ２２６）。そして、ＳＮＳサーバ１２０はその登録確認を管理者（Ｂ）に送信し（Ｓ２２８）、管理者（Ｂ）はこれを受信する（Ｓ２３０）。これにより、管理者（Ｂ）は故人（Ａ）の没後情報がＳＮＳサーバ１２０に登録されたことを確認することができる。故人（Ａ）が生前に自身の没後情報の登録を依頼した場合には、登録確認が故人（Ａ）にも送信され、故人（Ａ）はこれを受信する（Ｓ２３２）。ＳＮＳサーバ１２０に登録された故人（Ａ）の没後情報は、非公開に設定される。

ここで、故人（Ａ）の没後情報とは、故人（Ａ）の没後に関わる情報をいい、例えば、故人（Ａ）の葬儀、法事及び墓の少なくとも一つに関する情報を含むことができる。具体的に、葬儀に関する情報は、葬儀の日時、場所、喪主、形式などについての情報である。法事に関する情報は、法事の日時、場所、主催者、食事の有無などについての情報である。墓に関する情報は、墓の場所などについての情報である。

図３は、故人（Ａ）の没後情報を共有するプロセスを示すフロー図である。このプロセスは、要求者（Ｃ）より、故人（Ａ）の没後情報を求めるリクエストがＳＮＳサーバ１２０に送信されることで始まる（Ｓ３００）。ＳＮＳサーバ１２０は、没後情報のリクエストを受信し（Ｓ３０２）、要求者（Ｃ）と故人（Ａ）とのＳＮＳ上の関係を特定する（Ｓ３０４）。例えば、ＳＮＳサーバ１２０は、要求者（Ｃ）が故人（Ａ）とＳＮＳ上でのつながりを有することを特定したり、要求者（Ｃ）が故人（Ａ）とＳＮＳ上で特別なグループやカテゴリーに属していることを特定したりする。その結果、ＳＮＳサーバ１２０は、リクエストに対する回答内容を管理者（Ｂ）に提示するために、特定したＳＮＳ上の関係に応じた回答内容を管理者（Ｂ）に送信する（Ｓ３０６）。管理者（Ｂ）は、提示された回答内容を受信する（Ｓ３０８）。提示された回答内容は、故人（Ａ）の没後情報を伝えることを許可する選択肢（Ｓ３１０）、これを拒否する選択肢（Ｓ３１２）、及び、故人（Ａ）に関する質問を問う選択肢（Ｓ３１４）のうち、ＳＮＳ上の関係に応じたものが１つ以上含まれる。

管理者（Ｂ）が許可の選択肢を選択した場合（Ｓ３１０）、その旨がＳＮＳサーバ１２０に送信される（Ｓ３１６）。これに応答して、ＳＮＳサーバ１２０は、要求者（Ｃ）に対して、リクエストされた没後情報を送信する（Ｓ３１８）。こうして、要求者（Ｃ）は、要求どおり、故人（Ａ）の没後情報を受信する（Ｓ３２０）。一方、管理者（Ｂ）が拒否の選択肢を選択した場合（Ｓ３１２）、その旨がＳＮＳサーバ１２０に送信される（Ｓ３２２）。これに応答して、ＳＮＳサーバ１２０は、要求者（Ｃ）に対してリクエスト拒否の旨を送信する（Ｓ３２４）。こうして、要求者（Ｃ）は、リクエストが拒否された旨を受信する（Ｓ３２６）。

あるいは、管理者（Ｂ）が質問の選択肢を選択した場合は（Ｓ３１４）、その旨がＳＮＳサーバ１２０に送信される（Ｓ３２８）。これに応答して、ＳＮＳサーバ１２０は、要求者（Ｃ）に対して、故人（Ａ）に関する質問を送信する（Ｓ３３０）。要求者（Ｃ）は、質問を受信し（Ｓ３３２）、質問に回答すると（Ｓ３３４）、ＳＮＳサーバ１２０は、その回答を受信し（Ｓ３３６）、その回答が所定の基準を満たすかどうかを判断する（Ｓ３３８）。所定の基準は、回答があっているかどうか、あるいは回答にスコアをつける場合にはそのスコアが所定値以上の場合かどうかとすることができる。所定の基準を満たす場合（Ｓ３４０）、ＳＮＳサーバ１２０は、要求者（Ｃ）に対して、リクエストされた没後情報を送信する（Ｓ３１８）。所定の基準を満たさない場合（Ｓ３４２）、ＳＮＳサーバ１２０は、要求者（Ｃ）に対してリクエスト拒否の旨を送信する（Ｓ３２４）。また、いずれの場合であっても、ＳＮＳサーバ１２０は、回答の判断結果を管理者（Ｂ）に送信し（Ｓ３４４）、管理者（Ｂ）は、これを受信する（Ｓ３４６）。したがって、管理者（Ｂ）は、質問をなげた要求者（Ｃ）に没後情報が伝わったのかどうかを確認することができる。

他の実施態様では、図３に破線で示すように、質問に対する回答を管理者（Ｂ）に送信し（Ｓ３５０）、回答をＳＮＳサーバ１２０で判断しないようにしてもよい。すなわち、回答の判断主体を管理者（Ｂ）としてもよい。この場合、管理者（Ｂ）は回答を受信すると（Ｓ３５２）、故人（Ａ）の没後情報を伝えることを許可する選択肢（Ｓ３５４）と、これを拒否する選択肢（Ｓ３５６）とが提示される。管理者（Ｂ）の判断により、許可の選択肢が選択されると、その旨がＳＮＳサーバ１２０に送信され（Ｓ３５８）、ＳＮＳサーバ１２０から要求者（Ｃ）に没後情報が送信される（Ｓ３１８）。一方、管理者（Ｂ）の判断により、拒否の選択肢が選択されると、その旨がＳＮＳサーバ１２０に送信され（Ｓ３６０）、ＳＮＳサーバ１２０から要求者（Ｃ）にリクエスト拒否の旨が送信される（Ｓ３２４）。

このように、本実施形態では、ＳＮＳを利用して、要求者（Ｃ）から故人（Ａ）の没後情報を求めるリクエストを受け付け、そのリクエストに対して、要求者（Ｃ）と故人（Ａ）とのＳＮＳ上の関係に応じた回答内容を管理者（Ｂ）に提示する。これにより、要求者（Ｃ）にしてみれば、故人（Ａ）の遺族の連絡先が分からない場合でも、また、そのような連絡先が分かっている場合でも、遺族に事情を説明することなく故人（Ａ）の没後情報をＳＮＳ上で尋ねることができるので、便利である。また、管理者（Ｂ）にしてみれば、要求者（Ｃ）が故人（Ａ）と生前にどういう関係であったのかを知らなくても、リクエストに対してどのように応えるべきかという判断材料が提示されるので、故人（Ａ）の没後情報を適切な範囲で提供することができる。

図４は、要求者（Ｃ）と故人（Ａ）とのＳＮＳ上の関係を示すテーブル４００の一例を示す図である。このテーブル４００は、例えば図３の特定ステップ（Ｓ３０４）で用いられるものであり、ＳＮＳサーバ１２０に保存されている。図４に示すように、要求者Ｃ１〜Ｃ４は、故人（Ａ）とはＳＮＳ上でつながりを有している。このつながりは、例えば要求Ｃ１〜Ｃ４及び故人（Ａ）の一方が他方につながり申請を送り、他方がつながり申請を許可することで設定される。

要求者Ｃ１は、さらに、故人（Ａ）と同じグループに所属している。このグループは、要求者Ｃ１、故人（Ａ）又は他のグループメンバーによってＳＮＳ上で作られたものであり、このグループにおいては、グループメンバーが自身の没後情報を他のグループメンバーに伝えることを生前に許可している。すなわち、要求者Ｃ１及び故人（Ａ）がこのグループに所属していることで、故人（Ａ）は自身の没後情報を要求者Ｃ１に伝えることをＳＮＳ上で生前に許可している。なお、他の実施態様においては、このようなグループに所属しなくとも、故人（Ａ）は個別に要求者Ｃ１に対してそのような生前許可を設定することも可能である。このような要求者Ｃ１の属性に鑑み、ＳＮＳサーバ１２０は、要求者Ｃ１からのリクエストに対する回答内容として、少なくとも、故人（Ａ）の没後情報を伝えることを許可する選択肢（図３：Ｓ３１０）を管理者（Ｂ）に提示する。

要求者Ｃ２〜Ｃ４は、上記のグループには所属していない。このため、故人（Ａ）は、自身の没後情報を要求者（Ｃ２〜Ｃ４）に伝えることをＳＮＳ上で生前に許可していない。要求者Ｃ２及びＣ３は、それぞれ、故人（Ａ）とカテゴリーａ及びｂに関して、ＳＮＳ上の互いのプロフィールを共通にしている。例えば、カテゴリーａは大学であり、カテゴリーｂは現在の職場である。一方、要求者Ｃ４は、故人（Ａ）とはＳＮＳ上で互いのプロフィールを共通にするカテゴリーをもっていない。このような要求者Ｃ２〜Ｃ４の属性に鑑み、ＳＮＳサーバ１２０は、要求者Ｃ２〜Ｃ４からのリクエストに対する回答内容として、少なくとも、故人（Ａ）に関する質問を問う選択肢（図３：Ｓ３１４）を管理者（Ｂ）に提示する。要求者Ｃ２及びＣ３に対する質問としては、共通するカテゴリーａ及びｂに応じたものを提示する。例えば、要求者Ｃ２に対する質問としては、「故人（Ａ）が大学（カテゴリーａ）のときに所属していたサークル、研究室又はゼミを答えてください。」などという質問とすることができる。要求者Ｃ４に対する質問としては、共通するカテゴリーがないため、より一般的あるいはプライベートな内容、例えば故人（Ａ）の趣味、特技、福祉活動などについての質問とすることができる。なお、共通するカテゴリーが複数ある場合には、いずれか一つまたは複数のカテゴリーに応じた質問を提示すればよい。

要求者Ｃ５及びＣ６は、故人（Ａ）とはＳＮＳ上でのつながりを有していないが、それぞれ、ＳＮＳサーバ１２０がアクセス可能な故人（Ａ）の連絡先及びＳＮＳサーバ１２０がアクセス可能な管理者（Ｂ）の連絡先に含まれている者である。これらの連絡先は、ＳＮＳサーバ１２０が提供するＳＮＳを利用するためのソフトウェアとは別のソフトウェアに関して、故人（Ａ）又は管理者（Ｂ）が他者の個人情報（名前、住所、電話番号、電子メールなど）を保存又は登録した連絡先である。このような要求者Ｃ５及びＣ６の属性に鑑み、ＳＮＳサーバ１２０は、要求者Ｃ５及びＣ６からのリクエストに対する回答内容として、少なくとも、故人（Ａ）に関する質問を問う選択肢（図３：Ｓ３１４）を管理者（Ｂ）に提示する。要求者Ｃ５及びＣ６に対する質問としては、上記の要求者Ｃ４に対する質問と同様のものを提示すればよいが、上記の要求者Ｃ４に対する質問よりも難易度が高いもの、あるいは、より一層故人（Ａ）のプライベートなことを問うものとしてもよい。

要求者Ｃ７は、故人（Ａ）とはＳＮＳ上でのつながりを有さず、かつ、ＳＮＳサーバ１２０がアクセス可能な故人（Ａ）及び管理者（Ｂ）のいずれの連絡先にも含まれていない者である。すなわち、要求者Ｃ７は、ＳＮＳサーバ１２０のデータ上及びＳＮＳサーバ１２０がアクセス可能なデータ上、故人（Ａ）及び管理者（Ｂ）との関係を確認できない者である。このような要求者Ｃ７の属性に鑑み、ＳＮＳサーバ１２０は、要求者Ｃ７からのリクエストに対する回答内容として、少なくとも、故人（Ａ）の没後情報を伝えることを拒否する選択肢（図３：Ｓ３１２）を管理者（Ｂ）に提示する。

図５は、図２及び図３のプロセスで現れる画面の一例を示す模式図である。図５（ａ）は、故人（Ａ）のＳＮＳサイトの画面を示している。このＳＮＳサイトは、故人（Ａ）用のＳＮＳアカウントに関連付けられたものであり、このＳＮＳアカウントにおけるコンテンツを表示する。このコンテンツには、故人（Ａ）の識別子（名前や写真）を示すフィールド５００と、故人（Ａ）のプロフィールへとつながるフィールド５０２、管理者（Ｂ）がログインするための管理者専用フィールド５０４、要求者（Ｃ）が故人（Ａ）につながり申請を送るためのフィールド５０６、及び、要求者（Ｃ）が故人（Ａ）の没後情報をリクエストするためのフィールド５０８が含まれている。管理者（Ｂ）は、管理者専用フィールド５０４を通じてログインすることで、故人（Ａ）用のＳＮＳアカウントを管理することができる。例えば、管理者（Ｂ）は、管理者専用フィールド５０４を通じて、故人（Ａ）の没後情報やその他の関連情報（後述の代行サービスの情報など）を登録することができる。なお、図５（ａ）の画面は例えば図３のＳ３００の際に現れる。

図５（ｂ）は、管理者（Ｂ）が故人（Ａ）の没後情報を登録するときに現れる、管理者（Ｂ）の画面を示している。この画面には、葬儀、法事及び墓に関する情報をそれぞれ入力するためのフィールド５１０、５１２及び５１４が表示される。例えば、管理者（Ｂ）は、墓のフィールド５１４を通じて、故人（Ａ）の墓の場所を登録することができる。また、管理者（Ｂ）は、墓のフィールド５１４を通じて、霊園内における故人（Ａ）の墓の写真を登録することもできる。故人（Ａ）の墓参りをしたい要求者は、墓の所在地のみならず、霊園内の墓の写真もあることで、故人（Ａ）の墓を簡単に見つけることができるようになる。なお、図５（ｂ）の画面は例えば図２（ｂ）のＳ２２０の際に現れる。

図５（ｃ）は、要求者（Ｃ）が図５（ａ）のフィールド５０８（没後情報リクエスト）に入力（クリック又はタップ）したときに表示される、要求者（Ｃ）の画面を示している。この画面には、葬儀、法事及び墓に関する情報のリクエストを受け付けるフィールド５２０、５２２及び５２４が表示される。要求者（Ｃ）がフィールド５２０、５２２及び５２４のいずれかを入力（クリック又はタップ）すると、それに対応するリクエストがＳＮＳサーバ１２０に送信される。なお、フィールド５０８は、例えば、アイコン、ボックス又はリンクなどの態様とすることができ、要求者（Ｃ）からのリクエストを受け付ける。

図５（ｄ）〜（ｆ）は、それぞれ、要求者（Ｃ）からのリクエストに対する回答内容がＳＮＳサーバ１２０から提示されたときの、管理者（Ｂ）の画面を示している。上述したように、管理者（Ｂ）は、ＳＮＳサーバ１２０から、リクエストに対する回答内容として要求者（Ｃ）と故人（Ａ）とのＳＮＳ上の関係に応じて提示されたものを受信する。図５（ｄ）〜（ｆ）に示すように、管理者（Ｂ）が受信するメッセージには、どの要求者（Ｃ）からリクエストがあったかを示す領域５３０、要求者（Ｃ）と故人（Ａ）とのＳＮＳ上の関係（要求者（Ｃ）の属性）を示す領域５３２、及び、１つ以上の選択肢を示す領域５３４が含まれている。

図５（ｄ）に示すように、要求者（Ｃ）が図４の要求者Ｃ１に該当する場合には、没後情報を提供することを許可する選択肢５４０が表示される。一方、図５（ｅ）に示すように、要求者（Ｃ）が図４の要求者Ｃ２〜Ｃ６のいずれかに該当する場合には、故人（Ａ）に関する質問を問う選択肢５４２が表示されると共に、許可の選択肢５４０も表示される。このように「質問」と「許可」という二つの選択肢５４０、５４２を提示することで、管理者（Ｂ）が要求者（Ｃ）をよく知っていて質問する必要がない場合に、没後情報を速やかに要求者（Ｃ）に提供することが可能となる。また、図５（ｆ）に示すように、要求者（Ｃ）が図４の要求者Ｃ７に該当する場合には、没後情報を提供することを拒否する選択肢５４４が表示されると共に、質問の選択肢５４２も表示される。このように「拒否」と「質問」という二つの選択肢５４２、５４４を提示することで、管理者（Ｂ）が要求者（Ｃ）とはデータ上はつながりがないものの、実際には要求者（Ｃ）を知っている場合に、リクエストを拒否しないで済む。なお、図５（ｄ）〜（ｆ）の画面は例えば図３のＳ３０８の際に現れる。

図６は、故人（Ａ）の没後情報を受信したときの要求者（Ｃ）の画面の一例を示す模式図である。この画面は例えば図３のＳ３２０の際に現れる。すなわち、故人（Ａ）の没後情報が要求者（Ｃ）に提供されることが許可された場合に表示される。図６〜１０では、没後情報として、墓に関する情報がリクエストされた場合を例に説明するが、葬儀又は法事に関する情報がリクエストされた場合も同様である。

図６に示すように、要求者（Ｃ）が受信したメッセージ６００には、没後情報領域６０２、代行サービス領域６０４及びパスワード領域６０６が含まれている。没後情報領域６０２は、要求者（Ｃ）がリクエストした没後情報を表示する領域であり、ここでは故人（Ａ）の墓の所在地と、その墓の写真（霊園内における墓の写真）とに関する情報が含まれている。

代行サービス領域６０４は、要求者（Ｃ）が依頼可能な代行サービスに関する情報を表示する領域である。そのような情報には、例えば、要求者（Ｃ）に代わる別の者が、故人（Ａ）の墓参りをするお参り代行、故人（Ａ）の墓を掃除したりその周辺の草抜きをしたりする掃除代行、故人（Ａ）の墓に花や線香を供える献花代行、花や線香を購入する購入代行などに関する情報が含まれる。このような代行サービスに関する情報を没後情報とともに要求者（Ｃ）に送信・提供することで、要求者（Ｃ）の利便性に供することができる。例えば、要求者（Ｃ）は購入代行のサービスを利用することで、墓参り前にお花のオーダーを出し、墓に近い場所（コンビニエンスストアあるいは実際にオーダーした花屋などのお店や、墓のある霊園）でオーダーしたお花を受け取ることができるようになる。このような代行サービスに関する情報は、管理者（Ｂ）からの依頼又は入力によりＳＮＳサーバ１２０に登録することができる。例えば、購入代行の情報として、故人（Ａ）の墓の近くの花屋を登録することができる。このような情報を登録するタイミングは、例えば、故人（Ａ）の没後情報の登録を依頼する際（参照：図２（ｂ）のＳ２２０）でもよいし、その後（例えば、図５の管理者専用フィールド５０４を使用するとき）でもよい。

パスワード領域６０６は、二次元コードのパスワードに関する情報を表示する領域である。この領域には、パスワードを伝える理由を説明する内容も含まれている。この説明にあるように、故人（Ａ）の墓又は納骨地（霊園）には故人（Ａ）用の二次元コードが設けられており、墓参りをした人が二次元コードを読み込んでパスワードを入力することで、墓参りをした人が故人（Ａ）に関する情報を見ることができるようになっている。このパスワードを没後情報とともに要求者（Ｃ）に送信・提供することで、要求者（Ｃ）には墓参りの付加価値を、管理者（Ｂ）には訪問者の墓参り状況の情報を提供することができる。これについて次に説明する。なお、パスワード領域６０６は、故人（Ａ）の墓等に二次元コードが設けられたことが管理者（Ｂ）からの依頼又は入力によってＳＮＳサーバ１２０に登録された際に、ＳＮＳサーバ１２０が自動的に作成するように、ＳＮＳサーバ１２０を構成するとよい。

図７は、二次元コードを設けた墓と情報処理システム１００とを示す概略図である。故人（Ａ）の墓７００には、パスワードが必要な故人（Ａ）用の二次元コード７０２が設けられている。二次元コード７０２は、例えばＱＲコード（登録商標）であり、所定の情報をリーダーで読み取り可能に格納している。二次元コード７０２は、例えば墓石業者によって作成されて墓７００に設けられるが、上記のとおり、このような墓石業者が管理者（Ｂ）を務める場合もある。要求者（Ｃ）は、上述したクライアント端末１１０として、スマートフォンなどのモバイル端末７１０を有している。モバイル端末７１０は、情報を表示する機能、二次元コード７０２を読み込むリーダーとしての機能、パスワードを入力する機能、ネットワーク１３０を介してＳＮＳサーバ１２０と通信する機能、及び、ＧＰＳ等を利用して自機の位置を測定する機能など、各種の機能を実現するためのソフトウェアを有している。

図８は、二次元コードの読取処理プロセスを示すフロー図である。まず、要求者（Ｃ）が現地でモバイル端末７１０を使用して二次元コード７０２を読み込むと（Ｓ８００）、モバイル端末７１０にはパスワードを入力する画面が表示される（Ｓ８０２）。要求者（Ｃ）がさらにモバイル端末７１０を使用してパスワードを入力すると（Ｓ８０４）、パスワードの情報がＳＮＳサーバ１２０に送信される。ＳＮＳサーバ１２０は、パスワードの情報を受信し（Ｓ８０６）、受信したパスワードが適合するかどうかを判断する（Ｓ８０８）。パスワードが不適合であると判断された場合には（Ｓ８１０）、その結果がモバイル端末７１０に送信される（Ｓ８１２）。要求者（Ｃ）は、これを受信したモバイル端末７１０を通じて（Ｓ８１４）、パスワードが間違っていることに気付く。あるいは、間違って他人の墓に来たことに気付く。

一方、パスワードが適合であると判断された場合には（Ｓ８１６）、ＳＮＳサーバ１２０は、要求者（Ｃ）が故人（Ａ）の墓にチェックインしたことを記憶する（Ｓ８１８）とともに、そのことを管理者（Ｂ）に送信する（Ｓ８２０）。管理者（Ｂ）は、これを受信したクライアント端末１１０Ｂを通じて（Ｓ８２２）、要求者（Ｃ）が故人（Ａ）の墓参りに訪れたことにリアルタイムで気付くことができる。なお、チェックインしたことが故人（Ａ）用のＳＮＳアカウントに関連付けられたＳＮＳサイトに自動的に載るようにしてもよい。また、パスワードが適合であると判断された場合（Ｓ８１６）、ＳＮＳサーバ１２０は、モバイル端末７１０に対して、故人（Ａ）に関する情報をモバイル端末７１０に表示させるための情報を送信する（Ｓ８２６）。モバイル端末７１０は、この情報を受信して（Ｓ８２８）、故人（Ａ）に関する情報を表示する（Ｓ８３０）。こうして、要求者（Ｃ）は、モバイル端末７１０に表示された情報を通じて、墓の場所が間違いないことを確認できると共に、墓の前で故人（Ａ）のことをより知ることができたり、故人（Ａ）に対する思いを強くしたりすることもできる。

ここで、モバイル端末７１０に表示される故人（Ａ）に関する情報は、故人（Ａ）用のＳＮＳアカウントに関連付けられたＳＮＳサイト（例えば、図５（ａ）の画面）とすることもできるし、このＳＮＳサイトとは別に故人（Ａ）のために作られたＷｅｂサイトとすることもできる。このようなＳＮＳサイト又はＷｅｂサイトには、様々な情報を含めることができ、例えば、故人（Ａ）のプロフィール、写真、死亡日時、死亡時の年齢、死因、戒名、納骨日、生前のメッセージ、家系図のほか、墓に埋葬されているその他の人や動物といった情報、さらには、墓の石材及びデザイン並びに墓が作られた過程といった墓情報や、上述と同様の代行サービスの情報なども含めることができる。このような情報は、文字や画像のみならず、動画であってもよい。なお、このような情報が墓参りをすれば見られるという利点をいかし、墓誌になにも彫刻しないということもできる。これは個人情報をあまり公にしたくない人にとって望ましい。

他の実施態様では、図８に破線で示すように、ＳＮＳサーバ１２０が、パスワードの情報とともにモバイル端末７１０の位置情報も受信するようにしてもよい（Ｓ８４０）。そして、ＳＮＳサーバ１２０は、パスワードを判断する際、受信した位置情報を利用してもよい（Ｓ８４２）。この位置情報を利用することで、ＳＮＳサーバ１２０は、要求者（Ｃ）が実際に墓７００に訪れた上で、パスワードを入力しているかどうかを判断することができる。そして、ＳＮＳサーバ１２０は、要求者（Ｃ）が実際に墓７００に訪れていないと判断した場合には、上記のパスワードが適合した場合のステップ（Ｓ８１８、Ｓ８２０、Ｓ８２６）を実行せず、パスワードが不適合であると判断してもよい（Ｓ８１０）。これにより、実際に墓７００に訪れた人に限り、故人（Ａ）に関する情報を見られるようにすることができるため、要求者（Ｃ）に対して墓参りの付加価値をより一層強調することができる。

図９は、墓７００に対する要求者（Ｃ）のチェックインの記録を示すテーブル９００の一例を示している。このテーブル９００は、例えば図８のチェックイン記録のステップ（Ｓ８１８）にて記録・更新されるものであり、ＳＮＳサーバ１２０に記憶される。テーブル９００には、要求者（Ｃ）に関連付けて、墓７００への訪問日時及び合計の訪問回数が記憶される。例えば、要求者Ｃ１については、２０１６年１月１日と同年７月１日の計２回、墓７００の二次元コード７０２を読み込んでパスワードを入力したことが記憶されている。

図１０は、故人（Ａ）のために作られたＷｅｂサイト１０００が表示された要求者（Ｃ）のモバイル端末７１０の画面の一例を示している。この画面は、例えば図８の表示ステップ（Ｓ８３０）の際に現れる。このＷｅｂサイト１０００では、タイトル１００２とともに、クリック又はタップにより故人（Ａ）のプロフィール、墓情報及び代行サービスにそれぞれにつながるフィールド１００４、１００６、１００８が表示されている。したがって、例えばモバイル端末７１０において墓情報のフィールド１００６を選択すると、墓７００の石材の種類や、デザインのほか、墓７００が作られた過程、墓７００の建立に携わった業者などが表示される。

以上説明した図６〜１０の例では、二次元コード７０２を墓に設けた場合を例に説明したが、二次元コード７０２を他の場所に設けることもできる。例えば、故人（Ａ）の葬儀場所、法事場所、納骨地、骨壺及び仏壇にも二次元コード７０２を設けることができる。このような場所やものに関しても、上述した墓の場合と同様に二次元コード７０２を利用することで、例えば葬儀場所に対する要求者（Ｃ）のチェックインを記録することができたり、要求者（Ｃ）ごとに、葬儀への参列の有無と墓参りの有無・日時・回数とを紐づけて記憶したりすることができる。

次に、図１１及び図１２を参照して、上述した内容を実現するためのＳＮＳサーバ１２０及びクライアント端末１１０の構成要素について説明する。

図１１は、ＳＮＳサーバ１２０を示すブロック図である。ＳＮＳサーバ１２０は、ネットワークインタフェース１２１０、演算処理部１２２０及び記憶部１２３０を備えている。ネットワークインタフェース１２１０は、ＳＮＳサーバ１２０をネットワーク１３０に接続する。演算処理部１２２０は、ＣＰＵやＭＰＵ等によって構成される。演算処理部１２２０は、各種入力に基づいて、記憶部１２３０に記憶されたプログラムを実行することで、種々の機能部を動作させる。このプログラムは、ＣＤ−ＲＯＭやＵＳＢメモリなどの記憶媒体に記憶されるか、あるいはネットワーク１３０を介してダウンロードされコンピュータにインストールされる。演算処理部１２２０は、種々の機能部として、受信部１２２１、登録処理部１２２２、提示部１２２３、判断部１２２４及び送信部１２２５を有している。

受信部１２２１は、種々の情報をネットワークインタフェース１２１０を介して受信する。例えば、受信部１２２１は、管理者となるべき者又は故人（Ａ）より管理者（Ｂ）の登録依頼（図２（ａ）：Ｓ２０４）を、また、管理者（Ｂ）又は故人（Ａ）より故人（Ａ）の没後情報の登録依頼（図２（ｂ）：Ｓ２２４）を受信する。また、受信部１２２１は、要求者（Ｃ）より、故人（Ａ）の没後情報のリクエスト（図３：Ｓ３０２）、質問に対する回答（図３：Ｓ３３６）、二次元コードのパスワード（図８：Ｓ８０６）、及び、モバイル端末７１０の位置情報（図８：Ｓ８４０）などを受信する。

登録処理部１２２２は、受信部１２２１が受信した各種の登録依頼を処理する。例えば、登録処理部１２２２は、管理者（Ｂ）の登録依頼及び故人（Ａ）の没後情報の登録依頼を処理し、管理者（Ｂ）の情報及び故人（Ａ）の没後情報を記憶部１２３０に登録する（図２（ａ）：Ｓ２０６、図２（ｂ）：Ｓ２２６）。また、登録処理部１２２２は、ＳＮＳへの利用者としてのアカウント登録も処理し、記憶部１２３０に個々の利用者の情報を登録する。そのほか、登録処理部１２２２は、代行サービスに関する情報についても処理し、記憶部１２３０に登録する。

提示部１２２３は、要求者（Ｃ）から求められた故人（Ａ）の没後情報のリクエストに対する回答内容として、要求者（Ｃ）と故人（Ａ）とのＳＮＳ上の関係に応じたものを提示する（図３：Ｓ３０４、３０６）。具体的には、提示部１２２３は、リクエストに対する回答内容を管理者（Ｂ）に提示するために、要求者（Ｃ）と故人（Ａ）とのＳＮＳ上の関係を特定し、その特定結果に応じた回答内容を記憶部１２３０から抽出する。

判断部１２２４は、受信部１２２１が受信した各種の要確認情報を判断する。例えば、判断部１２２４は、質問に対する要求者（Ｃ）からの回答が所定の基準を満たすかどうかを判断する（図３：Ｓ３３８）。また、判断部１２２４は、モバイル端末７１０に入力された二次元コードのパスワードが適合するかどうかを判断したり（図８：Ｓ８０８）、モバイル端末７１０の位置が所定範囲内かどうか（例えば要求者（Ｃ）が実際に墓７００に訪れた上で、パスワードを入力しているかどうか）（図８：Ｓ８４２）を判断したりする。

送信部１２２５は、種々の情報をネットワークインタフェース１２１０を介して送信する。例えば、送信部１２２５は、登録処理部１２２２が登録依頼を処理した結果を登録依頼者や関係者に伝えるために送信する。一例をあげると、送信部１２２５は、故人（Ａ）又は管理者となるべきもの等に対して、管理者が登録されたことの登録確認（図２（ａ）：Ｓ２０８）を、また、故人（Ａ）又は管理者（Ｂ）に対して、故人（Ａ）の没後情報が登録されたことの登録確認（図２（ｂ）：Ｓ２２８）を送信する。加えて、送信部１２２５は、提示部１２２３が提示した情報、すなわちＳＮＳ上の関係に応じた回答内容を管理者（Ｂ）に送信する（図３：Ｓ３０６）。また、送信部１２２５は、管理者（Ｂ）が選択した回答内容に基づく回答結果や、判断部１２２４が判断した判断結果を、管理者（Ｂ）又は／要求者（Ｃ）に送信する。一例をあげると、送信部１２２５は、要求者（Ｃ）に対して、リクエストされた没後情報（図３：Ｓ３１８）、リクエストが拒否された旨（図３：Ｓ３２４）又は所定の質問（図３：Ｓ３３０）を送信するとともに、没後情報と併せて代行サービスや二次元コードのパスワードを送信する（参照：図６）。また、送信部１２２５は、管理者（Ｂ）に対して、質問に対する回答（図３：Ｓ３５０）やその判断結果（図３：Ｓ３４４）を送信すると共に、要求者（Ｃ）に対して、二次元コードのパスワードが不適合であるとの判断結果を送信する（図８：Ｓ８１２）。さらに、送信部１２２５は、パスワードが適合している場合には、管理者（Ｂ）に対しては、要求者（Ｃ）が二次元コードの設置場所（墓、葬儀場所、法事場所、納骨地等）にチェックインしたことを送信し（図８：Ｓ８２０）、要求者（Ｃ）に対しては、モバイル端末７１０に表示させる故人（Ａ）に関する情報（図８：Ｓ８２６。例えば、図１０のＷｅｂサイト）を送信する。

記憶部１２３０は、ハードディスクドライブ、ＳＤＤ、ＲＡＭなどの記憶装置によって構成され、演算処理部１２２０における処理の実行に必要な各種プログラムや、各種プログラムの実行に必要なデータ等を記憶する。例えば、記憶部１２３０には、利用者情報ＤＢ１２３２、没後利用ＤＢ１２３４及びチェックインＤＢ１２３６が保存されている。

利用者情報ＤＢ１２３２は、ＳＮＳの利用者の情報を記憶する。例えば、利用者情報ＤＢ１２３２は、ＳＮＳの利用者ごとに、ＳＮＳアカウント、ＩＤ、パスワード、プロフィール、つながりのある他の利用者、所属するグループ、故人であるかどうか、及び、管理者であるかどうかなどの情報を対応付けて記憶している。したがって、利用者情報ＤＢ１２３２は、一利用者である故人と他の利用者である要求者とのＳＮＳ上の関係（例：図４のテーブル４００）についても記憶している。

没後利用ＤＢ１２３４は、故人（Ａ）ごとに、管理者（Ｂ）の情報、故人（Ａ）の没後情報、要求者（Ｃ）への質問内容、この質問に対する答えの内容、代行サービスの内容、及び、二次元コードの情報（二次元コードが墓等に設けられているかどうか、設けられている場合にはそのパスワード及び設置場所、並びに、設けられている場合には二次元コードの読み込みによって表示される故人に関する情報（例：図５（ａ）のＳＮＳサイト、図１０のＷｅｂサイト１０００）等の情報）などの各種情報を対応付けて記憶している。

チェックインＤＢ１２３６は、故人（Ａ）ごとに、要求者（Ｃ）に関連付けて、故人（Ａ）用の二次元コードが設けられた場所（故人（Ａ）の葬儀場所、法事場所、墓及び納骨地など）に訪問（チェックイン）したかを、その日時や回数を対応付けて記憶している。したがって、チェックインＤＢ１２３６は、図９のテーブルについても記憶している。チェックインＤＢ１２３６は、ネットワーク１３０を介して管理者（Ｂ）にアクセス可能に構成されており、管理者（Ｂ）は、ＳＮＳのどの利用者がいつ、どのぐらいの頻度で故人（Ａ）の墓参りをしたか等を適宜確認することができるようになっている。なお、チェックインＤＢ１２３６で記録した内容を利用して、ＳＮＳサーバ１２０が、二次元コードの設置場所に訪問したことがある利用者に対して、一時的又は定期的な連絡（例えば、一周忌、三回忌のお知らせ、喪中のお知らせなど）を送るようにすることも可能である。

図１２は、管理者（Ｂ）のクライアント端末１１０Ｂを示すブロック図である。クライアント端末１１０Ｂは、ネットワークインタフェース１３００、ユーザインタフェース１３１０、演算処理部１３２０及び記憶部１３３０を備えた情報処理装置である。ネットワークインタフェース１３００は、クライアント端末１１０Ｂをネットワーク１３０に接続する。

ユーザインタフェース１３１０は、入力部１３１２及び表示部１３１４を有する。入力部１３１２は、管理者（Ｂ）からの入力・操作を受け付けるものであり、例えばキーボード、タッチパネル、音声入力装置などによって構成される。表示部１３１４は、提示された回答内容（複数の選択肢）などの画像を画面上に表示するものであり、例えば液晶などの各種ディスプレイによって構成される。なお、表示部１３１４がタッチパネルを構成し、表示部１３１４を入力部として機能させることも可能である。

演算処理部１３２０は、ＣＰＵやＭＰＵ等によって構成される。演算処理部１３２０は、各種入力に基づいて、記憶部１３３０に記憶されたプログラムを実行することで、種々の機能部を動作させる。このプログラムは、ＣＤ−ＲＯＭやＵＳＢメモリなどの記憶媒体に記憶されるか、あるいはネットワーク１３０を介してダウンロードされコンピュータにインストールされる。演算処理部１３２０は、種々の機能部として、受信部１３２２及び送信部１３２４を有している。

受信部１３２２は、種々の情報をネットワークインタフェース１３００を介してＳＮＳサーバ１２０から受信する。例えば、受信部１３２２は、管理者がＳＮＳサーバ１２０に登録されたことの登録確認（図２（ａ）：Ｓ２１０）や、没後情報がＳＮＳサーバ１２０に登録されたことの登録確認（図２（ｂ）：Ｓ２３０）を受信する。また、受信部１３２２は、ＳＮＳサーバ１２０から提示されたＳＮＳ上の関係に応じた回答内容（複数の選択肢）を受信する（図３：Ｓ３０８）。さらに、受信部１３２２は、要求者（Ｃ）が質問に対して回答した場合にその回答を受信するほか（図３：Ｓ３５２）、ＳＮＳサーバ１２０が当該回答を判断した場合にはその判断結果を受信する（図３：Ｓ３４６）。加えて、受信部１３２２は、要求者（Ｃ）が使用した二次元コードのパスワードが適合していた場合には、要求者（Ｃ）が二次元コードの設置場所にチェックインしたことを受信する（図８：Ｓ８２２）。

送信部１３２４は、種々の情報をネットワークインタフェース１３００を介して送信する。例えば、送信部１３２４は、ＳＮＳサーバ１２０に対し、管理者（Ｂ）の登録依頼（図２（ａ）：Ｓ２０２）や、没後情報の登録依頼（図２（ｂ）：Ｓ２２０）を送信する。また、送信部１３２４は、ＳＮＳサーバ１２０に対し、管理者（Ｂ）が選択した回答内容の選択肢（許可、拒否又は質問）の選択結果を送信するほか（図３：Ｓ３１６、Ｓ３２２、Ｓ３２８）、管理者（Ｂ）が要求者（Ｃ）の質問に対する回答に対して選択した応答内容の選択肢（許可又は拒否）の選択結果を送信するほか（図３：Ｓ３５６、３５８）。

記憶部１３３０は、ハードディスクドライブ、ＳＤＤ、ＲＡＭなどの記憶装置によって構成され、演算処理部１３２０における処理の実行に必要な各種プログラムや、各種プログラムの実行に必要なデータ等を記憶する。記憶部１３３０は、ＳＮＳサーバ１２０が提供するＳＮＳを利用するためのソフトウェア（例えば、ウェブブラウザやアプリケーション）を記憶する。また、記憶部１３３０は、ＳＮＳサーバ１２０から送信される各種情報を一時的に記憶する。

以上説明した本実施形態のＳＮＳサーバ１２０は、第１のユーザである要求者（Ｃ）と、故人（Ａ）用のＳＮＳアカウントを管理する管理者（Ｂ）とを利用者に含むＳＮＳを提供するＳＮＳサーバ１２０であって、第１のユーザである要求者（Ｃ）から、故人（Ａ）の没後に関わる情報を求めるリクエストを受信する受信部１２２１と、リクエストに対する回答内容として、第１のユーザである要求者（Ｃ）と故人（Ａ）とのＳＮＳ上の関係に応じたものを管理者（Ｂ）に提示する提示部１２２３と、を備える。

また、本実施形態の管理者（Ｂ）の情報処理装置１１０Ｂは、利用者にＳＮＳを提供するＳＮＳサーバ１２０にネットワーク１３０を介して接続され、故人（Ａ）用のＳＮＳアカウントを管理する管理者（Ｂ）の情報処理装置１１０Ｂであって、故人（Ａ）の没後に関わる情報を登録のためＳＮＳサーバ１２０に送信する送信部１３２４と、利用者の一人である第１のユーザ（要求者（Ｃ））から、ＳＮＳサーバ１２０に登録された情報を求めるリクエストがされた場合に、ＳＮＳサーバ１２０から、リクエストに対する回答内容として第１のユーザ（要求者（Ｃ））と故人（Ａ）とのＳＮＳ上の関係に応じて提示された回答内容を受信する受信部１３２２と、を備える。

このような実施形態によれば、ＳＮＳ上において故人の没後に関わる情報を適切な範囲で共有することができる。

以上、具体例を参照しつつ本発明の実施形態について説明した。以上の具体例は、本発明を説明するための例示であり、本発明をその実施形態のみに限定する趣旨ではない。すなわち、これら具体例に、当業者が適宜設計変更を加えたものも、本発明の特徴を備えている限り、本発明の範囲に包含される。例えば、前述した各具体例が備える各要素などは、例示したものに限定されるわけではなく適宜変更することができる。

例えば、上記の実施形態では、故人（Ａ）が、生前に自ら故人（Ａ）用のＳＮＳアカウントを登録し、生前にＳＮＳの利用者の一人であった場合について説明した。しかし、故人（Ａ）が生前にＳＮＳの利用者でなかったとしても、管理者（Ｂ）が故人（Ａ）のためにＳＮＳアカウントを登録し、これを管理する場合についても、上記の実施形態を適用することができる。すなわち、上述の「故人（Ａ）用のＳＮＳアカウント」とは、故人（Ａ）が生前に自ら登録したＳＮＳアカウントや、このＳＮＳアカウントから没後に移行されたＳＮＳアカウントのほか、故人（Ａ）の生前又は没後に故人（Ａ）のために管理者（Ｂ）によって登録されたＳＮＳアカウントをも含むものである。

また、故人（Ａ）は、ＳＮＳ上でつながりを有する利用者を生前に自動又は手動でカテゴリー別に分類するようにしておいてもよく、この分類したカテゴリーに応じて上記の質問が提示されるようにしてもよい。

１００ 情報処理システム、１１０ クライアント端末、１１０Ａ 故人のクライアント端末、１１０Ｂ 管理者のクライアント端末（情報処理装置）、１１０Ｃ 要求者のクライアント端末、１２０ ＳＮＳサーバ、１３０ ネットワーク、１２２１ 受信部、１２２３ 提示部、１２２４ 判断部、１２２５ 送信部、１２３０ 記憶部、１３２２ 受信部、１３２４ 送信部、１３３０ 記憶部、Ａ 故人、Ｂ 管理者、Ｃ 要求者

Claims (42)

1. 第１のユーザと、故人用のＳＮＳアカウントを管理する管理者とを利用者に含むＳＮＳを提供するＳＮＳサーバであって、
   前記第１のユーザから、前記故人の没後に関わる情報を求めるリクエストを受信する受信部と、
   前記リクエストに対する回答内容として、前記第１のユーザと前記故人との前記ＳＮＳ上の関係に応じたものを前記管理者に提示する提示部と、
   を備えた、ＳＮＳサーバ。
2. 前記故人の没後に関わる情報は、前記故人の葬儀、法事及び墓の少なくとも一つに関する情報を含む、請求項１に記載のＳＮＳサーバ。
3. 前記故人用のＳＮＳアカウントにおけるコンテンツには、前記リクエストを受け付けるフィールドが含まれており、
   前記受信部は、前記第１のユーザが前記フィールドに入力した場合に前記リクエストを受信する、請求項１又は２に記載のＳＮＳサーバ。
4. 前記ＳＮＳ上の関係が、前記故人が自身の没後に関わる情報を前記第１のユーザに伝えることを前記ＳＮＳ上で生前に許可している、というものである場合、
   前記提示部は、前記リクエストに対する回答内容として、前記故人の没後に関わる情報を前記第１のユーザに提供することを許可する選択肢を前記管理者に提示する、請求項１から３のいずれか一項に記載のＳＮＳサーバ。
5. 前記第１のユーザ及び前記故人は、前記ＳＮＳ上で作られたグループにともに所属しており、
   前記グループは、グループメンバーが自身の没後に関わる情報を他のグループメンバーに伝えることを生前に許可している、請求項４に記載のＳＮＳサーバ。
6. 前記ＳＮＳ上の関係が、前記故人が自身の没後に関わる情報を前記第１のユーザに伝えることを前記ＳＮＳ上で生前に許可していないが、前記故人が前記第１のユーザと前記ＳＮＳ上でのつながりを有している、というものである場合、
   前記提示部は、前記リクエストに対する回答内容として、前記故人に関する質問を問う選択肢を前記管理者に提示する、請求項１から３のいずれか一項に記載のＳＮＳサーバ。
7. 前記管理者が前記選択肢を選択したことに応答して、前記第１のユーザに前記質問を送信する送信部を備えており、
   前記質問に対する前記第１のユーザによる回答が所定の基準を満たす場合、
   前記提示部は、前記故人の没後に関わる情報を前記第１のユーザに提供することを許可する選択肢を前記管理者に提示する、請求項６に記載のＳＮＳサーバ。
8. 前記質問に対する前記第１のユーザによる回答が所定の基準を満たすかどうかを判断する判断部をさらに備えた、請求項７に記載のＳＮＳサーバ。
9. 前記提示部は、前記リクエストに対する回答内容として、前記故人の没後に関わる情報を前記第１のユーザに提供することを許可する選択肢も前記管理者に提示する、請求項６に記載のＳＮＳサーバ。
10. 前記第１のユーザ及び前記故人が、前記ＳＮＳ上の互いのプロフィールにおける複数のカテゴリーのうち、少なくとも一つのカテゴリーを共通にしている場合、
    前記提示部は、前記質問として、前記共通する少なくとも一つのカテゴリーに応じたものを提示する、請求項６から９のいずれか一項に記載のＳＮＳサーバ。
11. 前記ＳＮＳ上の関係が、前記故人が前記第１のユーザとは前記ＳＮＳ上でのつながりを有していないが、当該ＳＮＳサーバがアクセス可能な前記故人の連絡先及び当該ＳＮＳサーバがアクセス可能な前記管理者の連絡先の少なくとも一方に前記第１のユーザが含まれている場合、
    前記提示部は、前記リクエストに対する回答内容として、前記故人に関する質問を問う選択肢を前記管理者に提示する、請求項１から３のいずれか一項に記載のＳＮＳサーバ。
12. 前記管理者が前記選択肢を選択したことに応答して、前記第１のユーザに前記質問を送信する送信部を備えており、
    前記質問に対する前記第１のユーザによる回答が所定の基準を満たす場合、
    前記提示部は、前記故人の没後に関わる情報を前記第１のユーザに提供することを許可する選択肢を前記管理者に提示する、請求項１１に記載のＳＮＳサーバ。
13. 前記質問に対する前記第１のユーザによる回答が所定の基準を満たすかどうかを判断する判断部をさらに備えた、請求項１２に記載のＳＮＳサーバ。
14. 前記提示部は、前記リクエストに対する回答内容として、前記故人の没後に関わる情報を前記第１のユーザに提供することを許可する選択肢も前記管理者に提示する、請求項１１に記載のＳＮＳサーバ。
15. 前記ＳＮＳ上の関係が、前記故人が前記第１のユーザとは前記ＳＮＳ上でのつながりを有さず、かつ、当該ＳＮＳサーバがアクセス可能な前記故人の連絡先及び当該ＳＮＳサーバがアクセス可能な前記管理者の連絡先に前記第１のユーザが含まれていない場合、
    前記提示部は、前記故人の没後に関わる情報を前記第１のユーザに伝えることを拒否する選択肢を前記管理者に提示する、請求項１から３のいずれか一項に記載のＳＮＳサーバ。
16. 前記管理者が前記選択肢を選択したことに応答して、前記リクエストが拒否された旨を前記第１のユーザに送信する送信部をさらに備えた、請求項１５に記載のＳＮＳサーバ。
17. 前記提示部は、前記故人の没後に関わる情報を伝えることを許可する選択肢、前記故人の没後に関わる情報を伝えることを拒否する選択肢、及び、前記故人に関する質問を問う選択肢のうち、１つ以上の選択肢を前記ＳＮＳ上の関係に応じて前記管理者に提示する、請求項１から３のいずれか一項に記載のＳＮＳサーバ。
18. 前記管理者からの回答内容として、前記提示された１つ以上の選択肢の中から前記管理者が選択した選択肢に基づくものを前記第１のユーザに送信する送信部をさらに備えた、請求項１７に記載のＳＮＳサーバ。
19. 前記故人の没後に関わる情報が前記第１のユーザに提供されることが許可された場合、前記故人の没後に関わる情報を前記第１のユーザに送信する送信部をさらに備えた、請求項１から３のいずれか一項に記載のＳＮＳサーバ。
20. 前記送信部は、前記故人の没後に関わる情報とともに、前記第１のユーザが依頼可能な代行サービスに関する情報も送信する、請求項１９に記載のＳＮＳサーバ。
21. 前記故人の葬儀場所、法事場所、墓、納骨地、骨壺及び仏壇の少なくとも一つには、前記故人用の二次元コードが設けられており、
    前記送信部は、前記故人の没後に関わる情報とともに、前記二次元コードのパスワードも前記第１のユーザに送信する、請求項１９又は２０に記載のＳＮＳサーバ。
22. 前記第１のユーザが、ネットワークを介して当該ＳＮＳサーバと通信可能なモバイル端末を使用して、前記二次元コードを読み込んで前記パスワードを入力した場合、前記送信部はその旨を前記管理者に送信する、請求項２１に記載のＳＮＳサーバ。
23. 前記第１のユーザが、ネットワークを介して当該ＳＮＳサーバと通信可能なモバイル端末を使用して、前記二次元コードを読み込んで前記パスワードを入力した場合、その旨を記憶する記憶部をさらに備えた、請求項２１に記載のＳＮＳサーバ。
24. 前記記憶部は、前記第１のユーザがモバイル端末を介して前記二次元コードを読み込んで前記パスワードを入力した日時及び回数の少なくとも一つを記憶する、請求項２３に記載のＳＮＳサーバ。
25. 前記記憶部は、前記管理者にアクセス可能に構成されている、請求項２３又は２４に記載のＳＮＳサーバ。
26. 前記第１のユーザが、ネットワークを介して当該ＳＮＳサーバと通信可能なモバイル端末を使用して、前記二次元コードを読み込んで前記パスワードを入力した場合、前記送信部は、前記故人に関する情報を前記モバイル端末に表示させるための情報を前記モバイル端末に送信する、請求項２１に記載のＳＮＳサーバ。
27. 前記故人に関する情報は、前記故人用のＳＮＳアカウントに関連付けられたＳＮＳサイトを含む、請求項２６に記載のＳＮＳサーバ。
28. 前記故人に関する情報は、前記故人用のＳＮＳアカウントに関連付けられたＳＮＳサイトとは別に前記故人のために作られたＷｅｂサイトである、請求項２６に記載のＳＮＳサーバ。
29. 前記故人の没後に関わる情報は、前記故人の墓に関する情報であり、
    前記送信部は、前記故人の没後に関わる情報として、少なくとも前記墓の所在地及び霊園内における当該墓の写真を前記第１のユーザに送信する、請求項１９から２８のいずれか一項に記載のＳＮＳサーバ。
30. 前記ＳＮＳ上の関係を記憶する記憶部をさらに備えた、請求項１から２９のいずれか一項に記載のＳＮＳサーバ。
31. 前記故人は、生前、前記ＳＮＳの利用者の一人であり、
    前記故人用のＳＮＳアカウントは、前記故人が生前に登録したものである、請求項１から３０のいずれか一項に記載のＳＮＳサーバ。
32. 第１のユーザと、故人用のＳＮＳアカウントを管理する管理者とを利用者に含むＳＮＳを提供するＳＮＳサーバによって実行される方法であって、
    前記第１のユーザから、前記故人の没後に関わる情報を求めるリクエストを受信するステップと、
    前記リクエストに対する回答内容として、前記第１のユーザと前記故人との前記ＳＮＳ上の関係に応じたものを前記管理者に提示するステップと、
    を含む、ＳＮＳサーバによって実行される方法。
33. 第１のユーザと、故人用のＳＮＳアカウントを管理する管理者とを利用者に含むＳＮＳを提供するＳＮＳサーバに、
    前記第１のユーザから、前記故人の没後に関わる情報を求めるリクエストを受信することと、
    前記リクエストに対する回答内容として、前記第１のユーザと前記故人との前記ＳＮＳ上の関係に応じたものを前記管理者に提示することと、
    を実行させる、プログラム。
34. 利用者にＳＮＳを提供するＳＮＳサーバにネットワークを介して接続され、故人用のＳＮＳアカウントを管理する管理者の情報処理装置であって、
    前記故人の没後に関わる情報を登録のため前記ＳＮＳサーバに送信する送信部と、
    前記利用者の一人である第１のユーザから、前記ＳＮＳサーバに登録された前記情報を求めるリクエストがされた場合に、前記ＳＮＳサーバから、前記リクエストに対する回答内容として前記第１のユーザと前記故人との前記ＳＮＳ上の関係に応じて提示された回答内容を受信する受信部と、
    を備えた、管理者の情報処理装置。
35. 前記情報は、前記故人の葬儀、法事及び墓の少なくとも一つに関する情報を含む、請求項３４に記載の管理者の情報処理装置。
36. 前記ＳＮＳ上の関係が、前記故人が前記情報を前記第１のユーザに伝えることを前記ＳＮＳ上で生前に許可している、というものである場合、
    前記受信部が受信する回答内容には、前記情報を前記第１のユーザに提供することを許可する選択肢が含まれる、請求項３４又は３５に記載の管理者の情報処理装置。
37. 前記ＳＮＳ上の関係が、前記故人が前記情報を前記第１のユーザに伝えることを前記ＳＮＳ上で生前に許可していないが、前記故人が前記第１のユーザと前記ＳＮＳ上でのつながりを有している、というものである場合、
    前記受信部が受信する回答内容には、前記故人に関する質問を問う選択肢が含まれる、請求項３４又は３５に記載の管理者の情報処理装置。
38. 前記ＳＮＳ上の関係が、前記故人が前記第１のユーザとは前記ＳＮＳ上でのつながりを有していないが、当該ＳＮＳサーバがアクセス可能な前記故人の連絡先及び当該ＳＮＳサーバがアクセス可能な前記管理者の連絡先の少なくとも一方に前記第１のユーザが含まれている場合、
    前記受信部が受信する回答内容には、前記故人に関する質問を問う選択肢が含まれる、請求項３４又は３５に記載の管理者の情報処理装置。
39. 前記ＳＮＳ上の関係が、前記故人が前記第１のユーザとは前記ＳＮＳ上でのつながりを有さず、かつ、当該ＳＮＳサーバがアクセス可能な前記故人の連絡先及び当該ＳＮＳサーバがアクセス可能な前記管理者の連絡先に前記第１のユーザが含まれていない場合、
    前記受信部が受信する回答内容には、前記情報を前記第１のユーザに伝えることを拒否する選択肢が含まれる、請求項３４又は３５に記載の管理者の情報処理装置。
40. 前記故人の葬儀場所、法事場所、墓、納骨地、骨壺及び仏壇の少なくとも一つには、パスワードが必要な前記故人用の二次元コードが設けられており、
    前記第１のユーザが、ネットワークを介して前記ＳＮＳサーバと通信可能なモバイル端末を使用して、前記二次元コードを読み込んで前記パスワードを入力した場合に、前記受信部はその旨を前記ＳＮＳサーバから受信する、請求項３４から３９のいずれか一項に記載の管理者の情報処理装置。
41. 利用者にＳＮＳを提供するＳＮＳサーバにネットワークを介して接続され、故人用のＳＮＳアカウントを管理する管理者の情報処理装置によって実行される方法であって、
    前記故人の没後に関わる情報を登録のため前記ＳＮＳサーバに送信するステップと、
    前記利用者の一人である第１のユーザから、前記ＳＮＳサーバに登録された前記情報を求めるリクエストがされた場合に、前記ＳＮＳサーバから、前記リクエストに対する回答内容として前記第１のユーザと前記故人との前記ＳＮＳ上の関係に応じて提示された回答内容を受信するステップと、
    を含む、管理者の情報処理装置によって実行される方法。
42. 利用者にＳＮＳを提供するＳＮＳサーバにネットワークを介して接続され、故人用のＳＮＳアカウントを管理する管理者の情報処理装置に、
    前記故人の没後に関わる情報を登録のため前記ＳＮＳサーバに送信することと、
    前記利用者の一人である第１のユーザから、前記ＳＮＳサーバに登録された前記情報を求めるリクエストがされた場合に、前記ＳＮＳサーバから、前記リクエストに対する回答内容として前記第１のユーザと前記故人との前記ＳＮＳ上の関係に応じて提示された回答内容を受信することと、
    を実行させるプログラム。