JP2019191979A - サーバークライアントシステム、サーバークライアントシステムのサーバーおよびユーザー端末 - Google Patents

Abstract

【課題】 ネットワークを介して知り合うユーザーの信頼性を担保したり、この信頼性を保守していくシステムがなかった。【解決手段】 どちらが先に仮タグ情報を作成して相手方のユーザーに許可を求めたかにかかわらずユーザーが他のユーザーに特定のタグを付すときと、ユーザーが特定のタグを編集するときには、相手側のユーザーの許可を必要とし、所定のユーザーが他のユーザーに付した特定のタグ、または所定のユーザーが他のユーザーから付された特定のタグを削除するときには、相手側のユーザーの許可の有無にかかわらずタグを削除できるようにしたため、ネットワークを介してつながりができていく他のユーザーとの関係についていつでも見直し、原因となっているつながりを特定し、修正したり、削除することで、本来希望するつながりを維持していくことが可能となる。【選択図】 図１０

Description

本発明は、複数のユーザー端末がネットワークに接続可能となっており、同複数のユーザー端末同士でサーバーに記憶される所定の情報へのアクセスを可能としたサーバークライアントシステム、サーバークライアントシステムのサーバーおよびユーザー端末に関する。

ソーシャルネットワークサービスシステムでは、複数のユーザー端末がネットワークに接続可能となっており、同複数のユーザー端末同士でサーバーに記憶される所定の情報へのアクセスを可能としている。
あるユーザーが、自分の身の回りの情報を登録すると、他のユーザーがこの情報を取得できる。取得できる情報は、テキスト情報、静止画像情報、動画像情報、音声情報など様々である。情報は、趣味、コミュニティなど、複数のユーザーに共通するものも多く、ユーザー同士が友達関係という結束情報を付し合うことで、付していないユーザーと切り分けた特別の関係を築くことも可能となっている。

ところで、ネットワークを介してユーザー同士がつながりを持っていくときに、そのユーザーの信頼性が気になることが多い。このとき現実の知り合いであるユーザーと友達の関係にある他のユーザーであれば、少しは信頼性が高いといえる。しかし、友達関係は必ずしも信頼性の保証を伴うものではない。友達関係を将来的に維持するか否かを考慮するとしても、友達の友達を友達としていく過程で、どの友達関係において、問題の原因となっているのかを探るすべもない。

一方、このソーシャルネットワークサービスに加わるためには、すでにユーザーとなっている人からの推薦を必須とするものもある。理論的には、不適切なユーザーが参加することを防いでいるはずであるが、推薦されて登録されたユーザーが他のユーザーを推薦する基準はまちまちであるので、自然に全体の信頼性も薄らいでくる。この場合、その後に不適切なユーザーを排除するすべもない。

コトバンク ソーシャルネットワークなど

ネットワークを介して知り合うユーザーの信頼性を担保したり、この信頼性を保守していくシステムがなかった。
本発明は、ネットワークを介して知り合うユーザーの信頼性を担保したり、この信頼性を保守していくことが可能なサーバークライアントシステム、サーバークライアントシステムのサーバーおよびユーザー端末を提供する。

複数のユーザー端末がネットワークを介してサーバーに接続可能となっており、同複数のユーザー端末が前記サーバーに記憶される情報へアクセスを可能としたサーバークライアントシステムであって、前記サーバーは、タグを識別する情報と、（どちらが先に仮タグ情報を作成して相手方のユーザーに許可を求めたかにかかわらず）他のユーザーに所定のタグを付したユーザーと、同タグを付されたユーザーとの情報をタグ情報として保持するタグ情報保持記憶手段と、特定のユーザーが他のユーザーに特定のタグを付すときに、タグを付されるユーザーの許可を取得してからタグを付し、または、特定のユーザーが自分自身に特定のタグを付すときに、誰か他のユーザーの許可を取得してからタグを付すタグ付け許可手段と、特定のタグを編集するときに、当該タグのタグ情報に含まれる相手方のユーザーの許可を取得してからタグを編集させるタグ編集手段と、特定のユーザーが所定のタグのタグ情報に基づいて相手側のユーザーの許可の有無にかかわらず同タグを削除するタグ削除手段と、タグ情報に基づいて、所定のユーザーを起点としてタグ情報で連結される他のユーザーを検索して、タグのつながり状況の情報を得るタグ付けリンク情報取得手段を備え、前記ユーザー端末は、前記サーバーに対し、特定のユーザーに対するタグ付けとタグ情報の編集とタグ情報の削除の要求を行い、また、タグ情報の付加と編集に対して許可することを可能とした構成としてある。なお、他のユーザーに所定のタグを付す場合には2通りあり、相手に付そうとするユーザーが仮タグを作成して、付されようとするユーザーに送信する場合と、自分自身に付そうとするユーザーが自分で仮タグを作成して、それを付してもらいたい相手のユーザーに付してもらうことをリクエストする場合とであるが、どちらも結局はタグ付けが行われたあとでは、どちらが先に仮タグ情報を作成して相手方のユーザーに許可を求めたかにかかわらず、タグを付した、タグを付された、ということになる。タグを付す、タグを付された、という表現にはこの2通りが含まれることとする。

上記構成において、タグ情報保持記憶手段は、タグを識別する情報と、他のユーザーに所定のタグを付したユーザーと、同タグを付されたユーザーとの情報をタグ情報として保持する。タグは、タグを付すこと、タグを編集すること、タグを削除することが可能となっている。ここで、「タグを付すこと」というのは、タグを自分に付してくれるようリクエストしてタグが付されることも含む。まず、タグ付許可手段は、特定のユーザーが他のユーザーに特定のタグを付すときに、タグを付されるユーザーの許可を取得してからタグを付す。または特定のユーザーが他のユーザーに特定のタグを自分に付してくれるようリクエストした場合には、リクエストされた側のユーザーがそのタグを許可してタグを付す。次に、タグ編集手段は、特定のタグを編集するときに、当該タグのタグ情報に含まれる相手方のユーザーの許可を取得してからタグを編集させる。そして、タグ削除手段は、特定のユーザーが所定のタグのタグ情報に基づいて相手側のユーザーの許可の有無にかかわらず同タグを削除する。タグは連鎖的に付されていくので、個々のタグを見極める必要もある。このため、タグ付けリンク情報取得手段は、タグ情報に基づいて、所定のユーザーを起点としてタグ情報で連結される他のユーザーを検索して、タグのつながり状況の情報を得ることを可能としている。このようなサーバーの各機能に対応して、前記ユーザー端末は、前記サーバーに対し、特定のユーザーに対するタグ付けとタグ情報の編集とタグ情報の削除の要求を行い、また、タグ情報の付加と編集に対して許可することができる。

タグは信頼性に限られるものではないが、一例として、タグを付すことを信頼の保証に使用するとすると、タグを付すユーザーは、他のユーザーに信頼性を保証するつもりでタグを付す。このとき、付されるユーザーは、信頼性であったとしても、付す側のユーザーが信頼性に疑問があると感じることもある。このような場合、タグを付されることは負の信頼を付されるのに等しいと感じることもある。従って、タグを付す場合、付される側の許可を必須としている。ただし、付される側が自分で仮タグを作成した場合には付される側は既に許可していることになるので、この場合には逆に付す側の許可を必須としている。要はタグは双方両者の許可が必須であって、それによって成り立ち、タグ付けされるということである。最初に仮タグを作成したユーザーは実質的にそのタグを許可したということになる。タグ付けは、どちらの側が先に仮タグを作成したかにかかわらず、そのあと相手側の許可が得られればタグ付けが完成する。

タグを付した後で、タグの意味を変えたいような場合には、タグを付し直すのではなく、タグの情報を編集して意味を変えられるようにすると便利である。しかし、ポジティブな意味であったものを、ネガティブの意味に勝手に編集されるということも起きえる。従って、すでに付しているタグの情報を編集する場合も、タグを付される側の許可を必須としている。タグの編集は、タグ情報に含まれる相手方のユーザーの許可を取得することが必要であるが、タグを付したユーザーからも行えるし、タグを付されたユーザーからも行える。

タグを付すことで、信頼性のつながりを構築できたはずであっても、後々、思わぬつながりを構築してしまったことに気づくことがある。また、リンクの責務を鬱陶しく思うようになることもある。また、信頼性に疑問があるユーザーにつながりができていることを発見したならば、すぐにでもつながりを切りたいと思うこともある。この場合、不適切なユーザーがつながりの削除を拒否できるとすると、他の信頼性のおけるユーザーには迷惑がかかる。このため、タグを削除するときには、付されたユーザーの許可の有無にかかわらず、削除できるようにしている。また逆にタグを付されたユーザーが、付したユーザーの許可の有無にかかわらず、そのタグを削除できる。

このようなつながりを表すことが可能なタグには、タグを識別する情報と、他のユーザーに所定のタグを付したユーザーと、同タグを付されたユーザーとの情報をタグ情報として保持する。タグを識別する情報に加え、付したユーザーと、付されたユーザーとがわかることで、つながりの連鎖をたどることができる。ユーザーは複数のタグを他のユーザーに付すことが考えられるので、連鎖する一連のタグを他の連鎖する一連のタグと識別する情報も必要となる。
タグ情報は、タグの独立性を示すためのものであればよく、個別の記号、特定の名前などを含んでもよい。個別の識別情報に加えて、共通の名称を含むというものでもよい。ある一つのつながりを示すためには共通の名称が便利であるが、名称が重複することは当然に予測できるから、これとともに個別の識別情報が備えられていればよい。ユーザーの識別は、名称のみならず、登録番号、端末の符号など、各種のものを利用可能である。

このように、タグ自体に連鎖を辿れる要素は備えており、これを利用して、タグ付けリンク情報取得手段は、タグのつながり状況の情報を得ることが可能である。例えば、タグ付けリンク情報取得手段を利用して、後日、不適切と思われるタグ付けを特定した上で、そのタグ付けを削除したり、編集したりする。
なお、ユーザーというのは個々の人間である必要はない。ネットワークに接続される一クライアントであればよい。個人、グループ、組織、会社、工場、電子機器であってもよい。

本発明のサーバークライアントシステムによれば、ネットワークを介してつながりができていく他のユーザーとの関係についていつでも見直し、原因となっているつながりを特定し、修正したり、削除することで、本来希望するつながりを維持していくことが可能となる。

ネットワークを示す図である。 サーバーのブロック図である。 タグ付けのフローチャートである。 タグ編集のフローチャートである。 タグ削除のフローチャートである。 タグのつながり状況の情報であるリンクを検索するメイン処理のフローチャートである。 タグのつながり状況の情報であるリンクを検索するサブルーチン処理のフローチャートである。 友達関係を構築するリクエストと許可のやりとりを示す図である。 ポストしたときにタグでユーザーを限定するフローチャートである。 複数のタグとタイムラインを示す図である。 タグ付けリンク上または友達登録上の階層数の数え方を示す図である。 ポストする画面を示す図である。 ポストおよびリポストされた情報とタイムラインを示す図である。 リポストを行うための画面を示す図である。 タグ付けの通常例を示す図である。 タグ付けの変形例を示す図である。

以下、図面にもとづいて本発明の実施形態を説明する。
図１は、ネットワークを示す図である。
同図において、ネットワーク１０には、複数のユーザー端末２０（クライアントあるいはクライアント端末とも呼ぶ）と、サーバー３０とが接続されている。ネットワーク１０は広域ネットワークでもよいし、特定の地域や構内などのローカルネットワークでもよい。ユーザー端末２０は、ネットワーク１０に有線または無線で接続可能であり、各種のネットワークサービスを享受可能となっている。ユーザー端末２０は、人が操作するものでもよいし、人が関与しない無人応答の端末であってもよい。

サーバー３０は、記憶領域を有し、所定のソフトウェアやハードウェアが総合的に機能することで、クライアントにネットワークサービスを提供する。サーバー３０の構成はＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスクなどの大容量記憶領域、各種のインターフェイス（ＩＦ）などからなり、ハードディスクやＲＯＭに記憶されている制御ソフトウェアをＣＰＵが実行する。むろん、制御主体はＣＰＵと制御ソフトウェアとによる協働に限られるものではなく、各機能を実行可能なＡＳＩＣが実行するようにしてもよい。この場合、検索処理を各種のフィルタで実現するようにしてもよい。

図２は、サーバーのブロック図である。
本実施形態において、本サーバー３０は、ネットワーク１０への電気信号のやりとりを通じて情報のアクセスを行うネットワークＩＦ３１と、ソーシャルネットワークサービス（ＳＮＳ）システムを提供する基本構成としてのポスト管理回路３２とタイムライン管理回路３３とＳＮＳ管理メモリ３４とを備えている。ポスト管理回路３２は主にユーザーがポストあるいはリポストする情報の管理（新規追加、編集、削除など）を行い、タイムライン管理回路３３は各ユーザーのタイムラインの情報の管理（新規追加、編集、削除など）を行なう。ポストされる情報、リポストされる情報、タイムラインの情報は、ＳＮＳ管理メモリ３４に記憶される。なお、ポストをメッセージと捉えることもでき、その意味では「メッセンジャーサービス」「メッセンジャーアプリ」と呼ぶこともできる。

サーバー３０は、さらにタグ管理システム４０を構成している。タグ管理システム４０は、タグ情報を保持して記憶するタグ情報保持記憶メモリ４１と、タグ情報を付加するタグ付加回路４２と、タグ情報を編集するタグ編集回路４３と、タグ情報を削除するタグ削除回路４４とを備えている。また、タグ情報の付加と編集の際には対象となるユーザーの許可を必要とするため、この許可の有無を確認して判定する許可判定回路４５も備えている。

タグ情報は、どちらが先に仮タグ情報を作成して相手方のユーザーに許可を求めたかにかかわらず、あるユーザーから他のユーザーに付す。このため、タグ情報は、付したユーザーを特定する情報（第１タグ情報）と、付されたユーザーを特定する情報（第２タグ情報）と、タグを識別するためのＩＤ情報（タグ識別情報）とを備える。ユーザーＡが、ユーザーＢに、釣り仲間という意図でfishingというタグを付けるとすると、第１タグ情報は「Ａ」、第２タグ情報は「Ｂ」、タグ識別情報は「fishing」ということになる。なお、これ以外の情報を含んでいてもよい。
ＩＤ情報は、各タグに固有の特定情報に加えて、連鎖するタグのグループを特定する特定情報と、固有や連鎖に限定されない情報も備えてもよい。固有の特定情報は各タグごとに唯一無二の情報であるが、連鎖するタグのグループを特定するタグ情報は、最初にタグが付されるときに固有のものが生成されて、以後はユーザーがタグを付して連鎖していくときに同じものが再利用されていくようにする。以上のような情報により、連鎖する一連のタグを他の連鎖する一連のタグと識別する情報となる。ＩＤ情報は、例えば趣味やサークルなどの名称などを付けられ、他に同じ名称が付されているか否かにかかわらず自由に付けることができる。なお、本実施例においては、タグ情報保持記憶メモリ４１がタグ情報保持記憶手段を構成している。

図３は、タグ付けのフローチャートである。
タグ情報を付加するタグ付加回路４２は、サーバー３０に対してユーザー端末２０からログインし、他のユーザーを指定してタグを付すリクエストをする。サーバー３０では、ステップＳ１０２にて、タグ付けがリクエストされるのを待機している。
このとき、リクエストしたユーザー端末のユーザーを特定する情報が、「付したユーザー」を特定する情報となり、タグを付す相手として指定した他のユーザーを特定する情報が、「付されたユーザー」を特定する情報となる。
タグ情報に含まれるタグを識別する情報（タグ識別情報とも呼ぶ）は、「付したユーザー」が決定する。自分の釣り仲間と密に連絡を取れるように、「ｆｉｓｈｉｎｇ」というタグを付けたり、自分のテニス仲間と密に連絡を取れるように、「ｔｅｎｎｉｓ」というタグを付けたりすることが考えられる。このような付け方であるため、別々のユーザーが、独自に別々の他のユーザーにタグを付すときに、偶然、同じものとなることがあるが、これは構わない。あるユーザーが、同じタグ識別情報（「ｆｉｓｈｉｎｇ」）を、異なる連鎖を想定して付すことはないので、「付したユーザー」と、「付されたユーザー」と、タグ識別情報とにより、タグ付けの連鎖の区別は付けることができる。
なお、ユーザーインターフェイスについては、「付したユーザー」のユーザー端末において、「付されたユーザー」と、タグ識別情報とを指定する入力画面を設ける。また、あるユーザーが、自分自身にタグを付すために、他のユーザーにリクエストする場合もある。この場合は、ユーザーインターフェイスについては、「付されたユーザー」のユーザー端末において、「付したユーザー」と、タグ識別情報とを指定する入力画面を設ける。

一方、連鎖という観点では、独立したタグ情報（連鎖用タグ情報）を付して管理してもよい。それぞれ別個に連鎖するタグは、この独立した連鎖用タグ情報を比較するだけで判別できるようになる。
また、データベースで管理する場合、タグを付すときに各タグ情報を区別するために唯一無二の情報であるＩＤ情報は付されることになる。通常は、タグ付加回路４２が決定すればよい。ＩＤ情報については、上述した必要な要素を備えるものの、データベースでの実装については適宜データベースの使用などに合わせる必要があり、個々の要素が単体である必要はなく、組み合わせて一つのものとするなど、変更可能である。唯一無二のＩＤ情報はユーザーに管理させないようなデータベースであってもよい。また、初回のタグ付けの際に、タグ付加回路４２は、連鎖用タグ情報を決定してもよい。連鎖用タグ情報もこの時点では唯一無二の情報であり、他にダブることはない。しかし、「付されたユーザー」が次に他のユーザーに同じタグを付すことが可能であり、その場合には、新たに付す連鎖用タグ情報は、「付されたユーザー」に付されているタグ情報の中の連鎖用タグ情報を流用する。

サーバー３０は、ステップＳ１０２において、タグ付けリクエストありと判断した上で、「付したユーザー」、「付されたユーザー」、タグ識別情報を取得し、ステップＳ１０４において、第１タグ情報と、第２タグ情報とを決定し、仮のタグ情報とする。例えば、タグ識別情報は「good friend」、付したユーザーは「ユーザーＡ」、付されたユーザーは「ユーザーＢ」である。なお、「付したユーザー」はこの時点では厳密には付そうとするユーザーの意であり、「付されたユーザー」は付されようとするユーザーの意である。
以上のようなタグ情報は、ユーザーが、他のユーザーを指定してタグを付すリクエスト、またはタグを付してほしいリクエストをするときに、「付されたユーザー」となる側のユーザー、または「付すことをリクエストされたユーザー」となる側のユーザーの許可を必要とする。このため、タグ付加回路４２は、タグ付けのリクエストがあると、タグ情報の内容を許可判定回路４５に通知する。許可判定回路４５は、タグ情報の内容に基づいて、「付されたユーザー」となる側のユーザー、または「付すことをリクエストされたユーザー」となる側のユーザーに対して、そのタグ付けを許容するのか否かを問い合わせ、その回答を待ち、回答が肯定的である場合にだけタグ付加回路４２に対してタグ付けの許可があったことを通知する。

タグ付加回路４２は、許可判定回路４５からの肯定的な通知があるまでは、リクエストされたタグ情報を仮のものとして扱い、タグ情報保持記憶メモリ４１に仮のタグ情報として記憶するものの正式には記憶させない。そして、許可判定回路４５からの肯定的な通知があったときに、タグ付加回路４２はタグ情報をタグ情報保持記憶メモリ４１に記憶させる。
以上の処理を行うため、ステップＳ１０６においてサーバー３０の許可判定回路４５が「付されたユーザー」または「付すことをリクエストされたユーザー」に情報を開示して許否を待機する。ステップＳ１０８において、許可判定が肯定的であると判断されると、ステップＳ１１０にて、仮のタグ情報をタグ情報保持記憶メモリ４１に記憶させるし、許可判定が否定的であると判断されると、ステップＳ１１２において、仮のタグ情報を破棄する。
本実施例においては、タグ付加回路４２と許可判定回路４５とにより、タグ付許可手段を構成する。

ところで、タグはユーザー間の関係を表すとも言えるので、あるユーザーが他のユーザーに付す一方的なものだけではない方が使いやすい。あるユーザーから他のユーザーにタグを付すというリクエスト、あるいはあるユーザーが他のユーザーにタグを付してほしいというリクエストに対して、付される側のユーザー、または付してほしいリクエストをされたユーザーがタグ識別情報を変更することを希望する場合もある。本実施形態では、付される側のユーザー、または付してほしいリクエストをされたユーザーが、この変更のために仮タグ情報を修正するリクエストを出すことができ、サーバー３０の側では、ステップＳ１１４にて、仮タグ情報の修正リクエストがあるか待機している。
ステップＳ１１４にて、サーバー３０が仮タグ情報修正リクエストありと判断すると、ステップＳ１１６にて、タグ情報の要素を取得する。ここでは、タグ識別情報は「good friend」、付したユーザーは「ユーザーＡ」、付されたユーザーは「ユーザーＢ」の情報となる。

なお、タグを付すときには、付そうとするユーザーからリクエストし、付されようとするユーザーがタグを修正するリクエストをする流れと、付してほしいリクエストをされたユーザーがタグを修正するリクエストをする流れとなっているが、タグを付す際であっても、ユーザーＡの側からでも、ユーザーＢの側からでも行えるようにしてもよい。
サーバー３０は、ステップＳ１１８にて、仮タグ情報を特定し、仮タグ情報とタグ情報保持記憶メモリ４１から、仮タグ情報を取得し、修正するタグ識別情報に基づいてタグ識別情報を修正して、今回の仮タグ情報とする。これは、一度は「ユーザーＡ」と「ユーザーＢ」の間でタグ情報を付した状態となっており、タグ情報保持記憶メモリ４１にはこれに該当する仮タグ情報も残っているため、重複しないように、該当する仮タグ情報を特定しておくために行われる。なお、タグ情報保持記憶メモリ４１に、該当する正式のタグ情報も残っているのであれば、同タグ情報を特定しておく。
なお、タグ情報の修正のためのインターフェイスは仮タグ情報を残しつつ、いずれかの情報を修正させる。以前の仮タグ情報を残しておくことにより、タグ情報保持記憶メモリ４１に残っている修正対象のタグ情報を特定する。

以上のようなタグ情報は、ユーザーが他のユーザーを指定してタグを付すリクエストをするときに、「付されたユーザー」となる側のユーザーの許可を必要とする。このため、タグ付加回路４２は、タグ付けのリクエストがあると、タグ情報の内容を許可判定回路４５に通知する。
許可判定回路４５は、タグ情報の内容に基づいて、「付されたユーザー」となる側のユーザー、または「付してほしいリクエストをされたユーザー」となる側のユーザーに対して、そのタグ情報の修正を許容するのか否かを問い合わせ、その回答を待つ。そして、回答が肯定的である場合にだけ、タグ付加回路４２はタグ情報をタグ情報保持記憶メモリ４１に記憶させる。
すなわち、サーバー３０は、ステップＳ１２０にて、許可判定回路４５に許可判定を依頼し、ステップＳ１２２にて、同許可判定回路４５の許可判定が肯定的であるとされると、ステップＳ１２４にて、仮タグ情報に基づいてタグ情報保持記憶メモリ４１のタグ情報を修正する。また、許可判定回路４５の許可判定が否定的である場合には、ステップＳ１２６にて、同仮タグ情報を破棄する。

次に、タグ編集回路４３は、タグ情報を編集する。
図４は、タグ編集のフローチャートである。
タグ情報を編集しようとするユーザーは、サーバー３０に対してユーザー端末２０からログインし、他のユーザーに付したタグを編集するリクエストをする。サーバー３０では、ステップＳ２０２にて、タグ付け編集がリクエストされるのを待機している。

タグは既に付されているので、ユーザーは編集したいタグを特定してタグ編集のリクエストをする。編集可能なタグ情報は基本的にタグ識別情報である。付したユーザーである自分（第1タグ情報）を編集することはできず、付されたユーザー（第2タグ情報）を変えるなら新たにタグを付せばよい。このため、ユーザーが自由に決めたタグ情報のタグ識別情報だけが編集対象となる。

ユーザーは、自分がタグを付した相手のユーザーと、編集後のタグ識別情報を特定してリクエストする。
サーバー３０は、ステップＳ２０２において、「付したユーザー」、「付されたユーザー」、タグ識別情報を取得し、ステップＳ２０４において、タグ情報を特定し、タグ情報保持記憶メモリからタグ情報を取得し、タグ識別情報を修正して、仮のタグ情報とする。例えば、「付したユーザー」はユーザーＡ、「付されたユーザー」はユーザーＢ、タグ識別情報は「good friend」となる。なお、必ずしも付したユーザーの側からのみ編集できるようにするのではなく、付されたユーザーの側から編集をリクエストできるようにしてもよい。ユーザーインターフェイスでは、最初に、自分が「付したユーザー」なのか「付されたユーザー」なのかを選択し、次に相手のユーザーを特定させるようにすれば、「付したユーザー」と「付されたユーザー」とを特定できるようになる。
サーバー３０は、ステップＳ２０４にて、タグ情報を特定し、仮タグ情報としてタグ情報保持記憶メモリ４１から、仮タグ情報を取得し、タグ識別情報を修正して、仮タグ情報とする。

既に付されたタグが自分の意志にかかわらず自由に変更されるのは困る。肯定的なタグを付けられていたはずなのに、知らぬ間に悪意のあるタグ情報に変更されてしまうことが起こりかねないからである。このため、あるユーザーが、他のユーザーに付したタグを編集するリクエストをするときに、相手のユーザーの許可を必要とする。また逆に、既に付したタグが自分の意志にかかわらず自由に変更されるのは困る。普通に肯定的なタグを付けていたはずなのに、知らぬ間に過剰な表現の肯定的なタグ情報に変更されてしまうことが起こりかねないからである。このため、あるユーザーが、そのユーザー自身に付されたタグを編集するリクエストをするときに、相手のユーザーの許可を必要とする。タグを付した側のユーザーからのリクエストであれば相手は「付されたユーザー」であるし、タグを付された側のユーザーからのリクエストであれば相手は「付したユーザー」である。
そして、タグ編集回路４３は、タグ編集のリクエストがあると、タグ情報の内容を許可判定回路４５に通知する。許可判定回路４５は、タグ情報の内容に基づいて、相手側のユーザーに対して、そのタグ編集を許容するのか否かを問い合わせ、その回答を待ち、回答が肯定的である場合にだけタグ編集回路４３に対してタグ編集の許可があったことを通知する。

タグ編集回路４３は、許可判定回路４５からの肯定的な通知があるまでは、リクエストされたタグ情報を仮のものとして扱い（仮タグ情報）、タグ情報保持記憶メモリ４１には仮タグ情報としては記憶させるが正式なタグ情報としては記憶させない。そして、許可判定回路４５からの肯定的な通知があったときに、タグ編集回路４３はタグ情報をタグ情報保持記憶メモリ４１に記憶させる。
以上の処理を行うため、ステップＳ２０６においてサーバー３０の許可判定回路４５が相手側の「ユーザー」に情報を開示して許否を待機する。ステップＳ２０８において、許可判定が肯定的であると判断されると、ステップＳ２１０にて、仮のタグ情報に基づいてタグ情報保持記憶メモリ４１のタグ情報を修正するし、許可判定が否定的であると判断されると、ステップＳ２１２において、仮のタグ情報を破棄する。すなわち、タグ編集はされなかったことになる。
本実施例においては、タグ編集回路４３と許可判定回路４５とにより、タグ編集手段を構成する。

次に、タグ削除回路４４はタグ情報を削除する。
図５は、タグ削除のフローチャートである。
あるユーザーが、他のユーザーを信頼して、「信頼のおける仲間」というタグを付したとする。そのタグを付されたユーザーが、他のユーザーを信頼して同じタグを付していったとする。そのタグ付けのつながりが広まったとする。

しかし、最初のユーザーがそのタグ付けのつながりを確認したときに、あるところで、「信頼のおける仲間」と言えないユーザーにもタグが付されていることを発見したとする。このような場合、最初に信頼のおける仲間というタグを付したユーザーは、何階層にも渡ってタグが付された状態を見て、不安を感じることもある。少なくとも確実に信頼の置けない知人にもそのタグが付されていたからである。このような場合は、タグを削除する。この場合、付されたユーザーの許可は不要としなければならない。なぜなら、付されたユーザーが拒否したとすると、ある人が最初のユーザーを知っているがために、そのタグを付されたユーザーを信頼したとしても、タグ付けのつながり状況が長いために間に信頼感のおけないユーザーも加わったことで、その末端にまで信頼の和のようなつながりが生じているように見えてしまうからである。

このため、サーバー３０のタグ削除回路４４では、ステップＳ３０２にて、タグ削除リクエストがあるか待機した上で、リクエストがあれば、「付したユーザー」、「付されたユーザー」、タグ識別情報を取得し、ステップＳ３０４にて、タグ情報保持記憶メモリのタグ情報を特定した上で、同タグ情報を削除する。
タグを削除することができるユーザーは、「付したユーザー」であってもよいし、「付されたユーザー」であってもよい。「付したユーザー」からのリクエストに対応する場合は、相手である「付されたユーザー」を特定させ、「付されたユーザー」からのリクエストに対応する場合は、相手である「付したユーザー」を特定させる。
本実施例においては、タグ削除回路４４により、タグ削除手段を構成する。

本実施例においては、タグ付けを削除するのは、ある特定のユーザーからある特定のユーザーに付したタグ付け、あるいはある特定のユーザーからある特定のユーザーに付されたタグ付けである。しかし、タグ付けの削除の仕方についてはこれに限られない。例えば、階層を指定して削除することもできるようにしてもよい。「何階層以下のタグ付けを削除する」という具合である。また、あるユーザーへのタグ付けの削除だけではなく、そのユーザーの階層から先の階層のすべてにおいてタグ付けを削除するようにしてもよい。タグ付けの状況は、以下に示すタグ付けリンク情報取得回路４６で確認できるので、当該タグ付けリンク情報取得回路４６で確認した上で、タグ付けを削除することも可能である。

タグ情報は、付したユーザーと、付されたユーザーとを一組とした一つのデータとしてタグ情報保持記憶メモリ４１に記憶されている。しかし、タグは連鎖して付されていくものであるため、連鎖している状況を確認できる必要がある。タグ付けリンク情報取得回路４６は、個々の複数のタグ情報を参照して、タグ付けの起点からタグ付けの終点に至る連鎖状況（リンク情報）を取得するものである。付したユーザーと付されたユーザーとが一組となっているので、起点となるユーザーが付したユーザーを検索し、次には付されたユーザーを付したユーザーとして、この付したユーザーがタグを付した次のユーザーを検索していくという処理を繰り返す。なお、ユーザーは複数のユーザーに同じタグを付すことや、付されたユーザーが、付した人に、自分が付されたのと同じタグ識別情報のタグを付すことや、それに類似すること（回り回って最初に付した人に戻って付すこと）もあるので、リンク情報の連鎖は一連の場合だけでなく、ネットワーク状になっていることもある。

図６は、タグのつながり状況の情報であるリンクを検索するメイン処理のフローチャートであり、図７は、タグのつながり状況の情報であるリンクを検索するサブルーチン処理のフローチャートである。このフローチャートは、いわゆるＰＡＤの書式で表示している。タグのつながり状況を知るにあたり、タグのつながり状況のデータを生成する処理を行い、再度利用できるように、生成されたタグつながり状況データを記憶しておくことも考えられるし、タグのつながりをたぐりながら該当するユーザーを見つけ出して何らかの処理を行うことも考えられる。前者であれば、生成されるデータをデータベースなどを利用して記録していく必要があるし、後者であれば、つながり状況が判定された時点で何らかの処理を行い、その処理後、さらにつながり状況の判定を続行していくことになる。
リンク情報は、ある連鎖を特定するものであり、さらに検索条件を設定して対象を絞り込むようにしてもよい。この検索条件としてタグ条件設定をステップＳ４０２にて設定する。例えば、自分が付したタグを削除する場合、インターフェイスでは「付したユーザー」を入力しなくても、単に「タグ識別情報」を特定することで、検索条件として利用できる。「付したユーザー」と「タグ識別情報」を特定してタグ情報保持記憶メモリ４１を参照すれば、同「付したユーザー」が同「タグ識別情報」を付した相手側のユーザーを特定できる。

タグはユーザーがユーザーに付していくものであるから、リンク情報はきわめて長くなることも多い。例えば、信用情報であればすべての連鎖の関係を辿れるようにすることが好都合であるし、あるユーザーのポスト通知を他のユーザーのタイムラインに表示するような場合には連鎖する関係にあるすべてのユーザーに表示する必要もないことが多い。

従って、あるユーザーが他のユーザーにタグを付すことを階層と表現する場合、階層を限定してリンク情報を取得できるようにすると各種のニーズに応えることができるようになる。この階層限定をステップＳ４０４にて設定する。むろん、この階層限定は任意であり、何も限定しなければ階層限定をしないという扱いでもよいし、何も限定しなければ階層限定を５段階とするというような扱いでもよい。５段階というのは一例に過ぎない。
タグ条件設定や階層限定設定は、ユーザーがポストする情報の書き込み欄に併設して設定欄を設け、これらを設定できるようにしておく。

タグの検索条件と階層限定とが設定されたら、この条件に該当するユーザーを検索する。ここで、便宜上、タグを付したユーザーを親と呼び、タグを付されたユーザーを子と呼ぶことにする。子を検索する処理は、子を親に代えて何度もネストしている状況を検索していくので、サブルーチン処理で実現している。
起点とするユーザーが定まっている時点で、ステップＳ４０５では、親となるユーザーを保持しておくスタックに、起点となるユーザーを親として設定する。
以上で「付したユーザー」とタグ識別情報とが定まるので、子を探すことが可能となる。方法はすべてのユーザーの中から、指定された「付したユーザー」とタグ識別情報とに一致するタグを持つユーザーを探せばいい。ステップＳ４０６では、最初の子検索処理を行う。
ここで、スタックは、先入れ後出しのメモリのようなものであり、未処理の親や子をスタックに入れ、処理を終えたらスタックから出す。スタックに入れるときに既に未処理の親や子が残っていれば、その親や子は未処理の第２位の順番となり、最新の未処理の親や子が終わるまで待機する。スタックに親や子を出し入れすれば、それに伴ってスタック内の未処理の親や子はさらに上位側に移動させられたり、下位側に移動させられたりするので、階層構造を検出するときに、ネストするごとにスタックへのデータの出し入れをすることで、階層構造をもれなく調べることが可能となる。このスタックを階層ごとに用意し、階層を上下させながらその階層のスタックに記憶されるユーザーごとに子を検索することで、階層構造になっているタグのリンク状況をたどることができる。
むろん、スタックを利用するのは一手法であり、他の手法で階層構造となる親子関係をもれなく検出することは可能である。

子検索処理では、まず、ステップＳ５０２において現在の階層を取得する。階層はネストする処理で逐次書き込むことにしており、最初の子検索ではまだ階層を書き込んでいないので、ステップＳ５０２で得られる階層は最上層あるいは「０」層となる。子を探すということは階層を１階層下げるということであり、階層を下げた結果、対象となる階層が上述した階層限定設定の対象範囲となる場合には次の作業を行う。ただし、最初の子検索では、スタックに起点となる親と子を入れることが目的であり、階層限定設定の意味はない。
次のステップＳ５０４では、スタックにある「ユーザー」を「付したユーザー（親）」として設定する。これで親が特定されたことになる。ステップＳ５０６では、親であるユーザーが設定したタグ情報を取得する。このタグ情報に一致する子を検索するので検索条件を得ていることになる。そして、ステップＳ５０８では、検索条件が合致する子（付されたユーザー）を検索し、ステップＳ５１０では、検索されたユーザーを下位層のユーザーとして下位層のスタックに保存する。検索条件が合致するというのは、各タグ情報を参照して、「付したユーザー」と、タグ識別情報が一致するタグ情報を付されたユーザーを捜すということである。この場合は、「付されたユーザー」から「付したユーザー」を検索する必要はないので、常に、「付したユーザー」と、タグ識別情報が一致することが検索条件である。

これで起点となるユーザーを親とする子は検索されたので、ネスト処理の回復後にこのユーザーを親として検索しないように、ステップＳ５１１では、親階層のスタックのユーザーを繰り下げる。繰り下げることでスタックのもっとも下位のユーザーは削除される。従って、二度と同じ親で子を検索することはなくなる。言い換えると、スタックには未処理の親が残っており、別の未処理の親をスタックに入れると、先に入っていた親が上に移動する。後で入った親を処理して繰り下げれば、後で入った親は消え、未処理で残っていた下位の親が下位に移動して次の処理対象となる。
この状態で、親階層のスタックと、その一つ下位層のスタックとが生成され、親階層のスタックは空、一つ下位層のスタックには検索された子が保持されている。最後に、ステップＳ５１２において、現在の階層情報を保存し、次の子検索の処理に備える。なお、スタックの処理については、上位及び下位という説明は適宜、その処理に応じて変化することとする。

最初の子検索を終了したら、ステップＳ４０８において、ループ処理が行われる。このループ処理の条件は、「下位層があり、階層限定の許可層の間」というものである。タグが初めて付けられたときは、あるユーザーが他のユーザーにタグを付したという１階層しかないので、その下位の層は存在せず、ループ処理には入らない。しかし、タグを付されたユーザーが別のユーザーにタグを付したときには、２階層目が生じたことになるから、以後は下位層があるという条件をクリアする。一方、階層限定についても条件としており、例えば、「５階層まで」と限定が付されているのであれば、下位の５階層を超えたら条件はクリアしなくなる。上述したように階層限定は必須のものではないので、階層限定をしない場合は子が見つからなくなるまでということになる。

ループ処理においては、ステップＳ４１０にて、階層を下げ、ステップＳ４１２にて、下げた階層での上述した子検索のサブルーチン処理を行う。階層を下げるというのは、検索されたユーザーを保持しておくスタックを変更する処理に相当する。スタックは階層ごとに検索されるユーザーを保持しているので、どの階層に着目するかによってスタックを変更する。

以上のようなスタックとループ処理を行うことで、階層構造にあるネストしたユーザーを検索することができ、ユーザーを階層構造として表示することになる。従って、タグ情報がタグ情報保持記憶メモリ４１に記憶されていることを前提として、本処理を実現するハードウェアおよびソフトウェアが一体的となってタグ付けリンク情報取得回路４６を構成している。また、本実施例においては、タグ付けリンク情報取得回路４６がリンク情報取得手段を構成している。
なお、階層構造を前提とすると、ＡからＢへ、ＢからＣへ、ＣからＡへというループするタグ付けはできないが、仕様としてこのようなループするタグ付けを許容しても構わない。このような場合には、ループ処理を許容する子検索の処理をする。

本実施例においては、すべてのユーザーからすべてのユーザーにタグ付けできる。しかし、あらかじめユーザーとユーザーとが友達関係を構築している場合に限定するということも可能である。
図８は、友達関係を構築するリクエストと許可のやりとりを示す図である。
友達関係は、基本的には、ユーザーとユーザーとの結びつきとして所定のパラメータを設定しておき、このパラメータが設定されているユーザー間では互いに開示しあう情報の範囲を、他のユーザーよりも広くするものである。この他にも各種の定義は可能であるが、本実施例においては、タグ付けを許容するための１つの条件として利用することが考えられる。

サーバー３０では、ステップＳ６０２において、あるユーザー（要求側）から、他のユーザー（承認側）への友達リクエストがあるか待機している。このような友達リクエストがあると、ステップＳ６０４において、承認側のユーザーに対して、要求側のユーザーからのリクエストを通知する。リアルタイムに要求側のユーザーが応答することは期待できないので、ステップＳ６０６では、サーバー３０が承認待機時間を設定する。例えば、１週間というような期間を設定する。このような承認待機時間は任意である。待機時間を設けないと、拒否するまで待機してしまうことになる。すなわち、相手が許可か許否するまで待機してもよいし、相手の回答できない状況を想定して一定時間の待機をもって、承認の限界を設けてもよいということである。

サーバー３０は、ステップＳ６０８において、承認待機時間の間だけ、次のループ処理を実行する。すなわち、ステップＳ６１０において、承認ありと判断されるまで待機する。承認時間の間に、承認側のユーザーが友達リクエストを承認をすると、サーバー３０は、ステップＳ６１０にて、承認ありと判断し、ステップＳ６１２にて、友達関係を設定する。より具体的には、要求側のユーザーと、承認側のユーザーとについて、友達関係あり、の情報を設定する（パラメータを設定する）。しかし、承認時間の間に、承認側のユーザーが友達リクエストを承認しなかった場合には、サーバー３０は、ステップＳ６１０にて、承認なしと判断し、ステップＳ６１４にて、承認拒否とする。承認許否として、それぞれのユーザーに対して、友達関係は成立しませんでしたという通知を送るようにしてもよい。
タイムオーバーという処理でもよい。なお、アルゴリズムとしては、それぞれのユーザーの間に友達関係はないというのが初期値であるから、タイムアウトを判断したら友達関係の設定をすることなく処理を終了するということも可能である。
承認時間というものを設けない場合は、承認側のユーザーが友達リクエストを承認をすると、サーバー３０は、ステップＳ６１０にて、承認ありと判断し、ステップＳ６１２にて、友達関係を設定するし、承認側のユーザーが友達リクエストを承認しなかった場合には、サーバー３０は、ステップＳ６１０にて、承認なしと判断し、ステップＳ６１４にて、承認拒否とする。

友達関係を前提としたタグ付けの場合は、タグ付加回路４２は、ステップＳ１０２において、タグ付けがリクエストされた時点で、両ユーザーの間に友達関係が設定されているか判断し、友達関係が設定されていればタグ付けの処理を開始し、友達関係が設定されていない場合はタグ付けの処理を開始することなく終了すればよい。また、ユーザー端末２０においては、タグ付けの処理の際にタグ付けするユーザーを特定するが、その時点で友達関係にあるユーザーだけが候補とされるようにしてもよい。
本実施例においては、上述した処理を経て友達関係を連結することができ、友達関係連結手段を構成している。

本サーバークライアントシステムは、ソーシャルネットワークサービス（メッセンジャーサービスとも言える）を提供する。このため、ポスト管理回路３２とタイムライン管理回路３３とＳＮＳ管理メモリ３４とを備えている。
ポスト管理回路３２は主にユーザーがポストあるいはリポストする情報の管理（新規追加、編集、削除など）を行うが、ユーザーがある情報をポストあるいはリポストしたときに、その情報を他のユーザーのタイムラインに表示する。この処理を、タイムライン管理回路３３が行なう。ポストされる情報、リポストされる情報、タイムラインの情報は、ＳＮＳ管理メモリ３４に記憶される。

本実施例では、ユーザーがポストした情報を、ユーザーのうちの誰のタイムラインに表示するかを、上述したタグ付けに基づいて限定することが可能である。
図９は、ポストしたときにタグでユーザーを限定するフローチャートである。
ポスト管理回路３２は、ユーザーからポストされる情報を受け付け、タイムライン管理回路３３は、タグ付けと階層限定の情報に基づいて、どのユーザーのタイムラインにこの情報を表示させるかを特定する。なお、この処理ではポストされる情報を受け付け、タイムラインに配信させることになるが、ポスト管理回路３２とタイムライン管理回路３３とが以下のフローチャートに基づいて協働して処理する。

ポスト管理回路３２とタイムライン管理回路３３（以下、単にサーバー３０と総称する）は、ステップＳ７０２において、ユーザーからの情報のポストを受付け、ステップＳ７０３において、同ポスト情報をＳＮＳ管理メモリ３４に用意されているポスト情報保持記録メモリへ書き込む。ステップＳ７０４では、タグ指定があるか判断し、タグ指定があれば、ステップＳ７０６にて、そのタグ条件を取得する。例えば、自分が付している、あるいは付されている、タグを指定してポストしたとすると、そのタグ情報が付されているユーザーを限定しているという意味であり、タグ条件は連鎖する「同じタグ識別情報が付されている」ということになる。
タグ識別情報自体は、偶然、別々のユーザーが、同じタグ識別情報を付すことはあり得る。「good friend」というタグ識別情報は一般的であり、重複して利用されることは希ではない。しかし、あるユーザーを起点として、同ユーザーが別のユーザーに「good friend」というタグ識別情報を持つタグを付し、付されたユーザーがさらに別のユーザーに同じタグ識別情報を持つタグを付すことで連鎖する。同じタグ識別情報を持つとしてもこの連鎖の中の一つなのか、異なる連鎖の中の一つかという違いが現れる。本実施形態では、タグ条件で検索するときに一致すると判断するのは同じ連鎖の中の一つである場合である。
なお、タグ情報の中に連鎖を識別する情報を付している場合は、その識別情報を利用すれば判断できる。

次に、サーバー３０は、ステップＳ７０８において、階層限定の有無を判定し、階層限定がない場合には、階層限定なしと判断し、ステップＳ７１０にて、階層限定をデフォルトの５階層とする。階層限定がある場合には、指定された階層数を利用する。この場合も階層限定は任意である。デフォルトの扱いが、階層限定をしない場合には階層数を限定しないというルールとしてもよい。
その後、サーバー３０は、ステップＳ７１２では、タグ付けリンク情報に基づいて、タグ条件に合致し、階層限定に合致する、「付されたユーザー」を特定し、ステップＳ７１４にて、この特定された、「付されたユーザー」のタイムラインに、ユーザーとポスト情報を書き込む。ポスト情報は別のユーザーの元で「表示される」のであるが、当該ユーザーがこのサービスを利用するタイミングはポストしたタイミングとリアルタイムではないので、各ユーザーごとに用意される所定のメモリ領域に、次に表示すべき情報を「書き込んで」おけば、同ユーザーがこのサービスを利用したときに所定の領域に「表示される」ということになる。

図１０は、複数のタグとタイムラインを示す図である。
同図において、ユーザーは、ユーザーＡ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｘがいるものとする。ユーザーＡからユーザーＢ，Ｃへと２種類のタグ（fishingとtennis）が付されている。そのうちの１種類のタグ（fishing）は、さらに、ユーザーＣから、ユーザーＤへと付されているが、ユーザーＤはユーザーＥに対して別の種類のタグ（ＬＡ）を付しており、このユーザーＥはユーザーＦに表面上は同じタグ（fishing）を付している。表面上は同じというのは、このタグ（fishing）はタグ識別情報であって自由に決められるものであるから、同じものとなっているが、起点は異なる。従って、異なる連鎖である。

一方、ユーザーＸは、ユーザーＤに対して１種類のタグ（tennis）を付している。ユーザーＣは２種類のタグ（fishingとtennis）を付されており、ユーザーＤも２種類のタグ（fishingとtennis）を付されている。しかし、１種類のタグ（fishing）の起点は共通するものの、残りの１種類のタグ（tennis）の起点は共通していない。従って、これらは別の連鎖である。

このようなタグ付けがされている中で、ユーザーＡが、タグ指定として２種類のタグ（fishingとtennis）を付し、階層限定を２階層とし、”Ｉ ａｍ Ａ”とポストしたとする。
ユーザーＢ，Ｃは、連鎖するタグが付されており、起点が共通している。また、ユーザーＡを基準とした階層も２階層の範囲内である。従って、ユーザーＢ，Ｃのタイムラインには、ユーザーＡがポストした”Ｉ ａｍ Ａ”という情報が表示される。

ユーザーＤの場合、連鎖するタグ（fishing）が付されていて、起点が共通するものの、ユーザーＡを基準とした階層が３階層目となり、階層限定の範囲外となる。従って、ユーザーＤのタイムラインには、ユーザーＡがポストした”Ｉ ａｍ Ａ”という情報は表示されない。また、タグ（tennis）については、連鎖するタグではないので、この意味でも、ユーザーＡがポストした情報は表示されない。

一方、階層限定がない場合は、デフォルトの５階層となる。この場合、ユーザーＥは５階層の範囲内ではあるものの、連鎖するタグ（fishing）が付されていないので対象外である。また、ユーザーFは５階層の範囲内ではあるものの、表面上は同じタグ（fishing）が付されているものの、これは連鎖するタグではないので対象外である。ユーザーＤの場合、一方のタグ（fishing）については連鎖するものの、もう一方のタグ（tennis）についてはユーザーＸからタグ付けされているので連鎖していない。このような場合、一つでも連鎖するタグが付されているのであれば、ポストされた情報を表示するものとする。なお、複数のタグを指定する場合、それらを論理積の条件としたり、論理和の条件とすることは適宜選択できるようにする。
タグ指定として２種類のタグ（fishingとtennis）を付した場合、「両者とも含む（ａｎｄ）」という条件か、「少なくとも一方を含む（ｏｒ）」という条件かを判断する必要もある。一例として、限定がなければ論理積の条件として扱い、論理積か論理和の限定があればそれに従うというような扱いが可能である。

図１１は、タグ付けリンク上または友達登録上の階層数の数え方を示す図である。
タグ付けの連鎖は必ずしも一直線とはならない。図に示す例では、ユーザーＨはユーザーＩとユーザーＬにタグ付けしており、ユーザーＬが同じタグをユーザーＩに付している。このような場合、階層を考えるとき、ユーザーＧ，Ｈ，Ｉとつながる連鎖と、ユーザーＧ，Ｈ，Ｌ，Ｉとつながる連鎖とが生じる。ユーザーＩは、前者の連鎖では２階層目であるが、後者の連鎖では３階層目としてカウントされる。以下のユーザーでは、二つの階層数を持つことになる。この結果、ユーザーＫ，Ｍは５階層目と６階層目とカウントされる。もし、ユーザーＭがユーザーＫに同じタグを付したとすれば、ユーザーＫは４階層目と５階層目と６階層目という３つの階層数を持つことになる。

このようなタグのつながり状況の場合に、階層限定として３階層と指定した場合、本実施例では、ユーザーＪまでが対象となる。すなわち、所有する複数の階層数における最小値の階層数に基づいて判断している。
図１２〜図１４は、画面表示の例を示している。図１２は、ポストする画面を示す図であり、図１３は、ポストおよびリポストされた情報とタイムラインを示す図であり、図１４は、リポストを行うための画面を示す図である。

図１２を参照すると、表示欄は、上からメッセージ欄ＣＬ１、タグ指定欄ＣＬ２、階層数限定欄ＣＬ３となっている。この例では、メッセージ欄ＣＬ１には、文字を入力可能となっており、文字を入力してポストボタンＢＴ１をクリックすると、タグ指定で限定されるユーザーのタイムラインに文字情報が表示されることになる。

図１３を参照すると、このタイムラインでは、順にＴＯＭのポスト情報、ＧＥＯＲＧＥのリポスト情報、ＪＡＣＫのリポスト情報が表示されている。ＴＯＭがタグ指定と階層数を限定してポストしたことに対応して、ＧＥＯＲＧＥと、ＪＡＣＫとが、次々にリポストしたことが現れている。ＴＯＭとＧＥＯＲＧＥ、およびＴＯＭとＪＡＣＫとは、それぞれタグでリンクされている関係であり、かつ今回のＴＯＭのポストで指定された階層数の範囲に入るからそれぞれのタイムラインにＴＯＭのポストが表示され、それをリポストすることができた。つまり、ＴＯＭはタグ指定として、Close friend, basketball, Texasを付しており、このタグ付けで連鎖しているユーザーに対して、限定された階層数の範囲で文字情報がタイムラインに表示される。ＧＥＯＲＧＥとＪＡＣＫのリポストについては、それぞれそれらのリポストを行うにあたって指定されたタグ情報も表示されている。ＧＥＯＲＧＥのリポストについてはfishing のタグが付され、ＪＡＣＫのリポストについてはseaのタグが付されている。この例では、ＴＯＭのタグ指定は、論理和で対象を制限しており、Close friend, basketball, Texas のいずれか一つが一致すれば対象となる。

また、タイムライン上のユーザーのポストには、そのポストを元のポストとして引用しながら、新しいメッセージをポストするためのリポストボタンＢＴ２が表示される。このリポストボタンＢＴ２をクリックすると、図１４に示すリポストのための入力欄が表示される。
リポストのための入力欄は、図１２に示すポストのための入力欄に加えて、元になった他のユーザーがポストした情報が表示されている。すなわち、上からメッセージ欄ＣＬ１、タグ指定欄ＣＬ２、階層数限定欄ＣＬ３、元のポスト情報表示欄ＣＬ４となっている。 ポスト情報表示欄ＣＬ４には、ユーザーを特定する情報（ＪＡＣＫ）、ポストされた文字情報、そのユーザーがこのポストを行ったときに指定したタグ（basketball, baseball, tennis, fishing ）、限定設定した階層限定数（１）が表示されている。

図１５はタグ付けの通常例、図１６はタグ付けの変形例を示す図である。
図１５においては、ユーザーＡとユーザーＢとユーザーＣとが、ユーザーＤに同一のタグ「fishing」をつけることができるのは上述した実施形態と同様であり、その場合には、ユーザーＤは「fishing [A]」、「fishing [B]」、「fishing [C]」という３つの同じ名前の「fishing」というタグを持つ。ここにおいて、fishingの後の[]は付したユーザー（第１タグ情報）を表している。「fishing [A]」はユーザーＡがユーザーＤに付したタグであり、「fishing [B]」はユーザーＢがユーザーＤに付したタグであり、「fishing [C]」はユーザーＣがユーザーＤに付したタグである。しかし、図１６の本変形例においては、ユーザーDは「fishing[A, B, C]」という複数ユーザーが付したとする１つのタグを持つことができるものである。

この例は、ユーザーＡ、ユーザーＢ、ユーザーＣのうちの誰が最初にユーザーＤに対して「fishing」というタグを付けたかどうかは関わりなく、要するにユーザーＡとユーザーＢとユーザーＣとそしてユーザーＤとの全員がそのタグについて承認したということを表すタグである。
たとえば、ユーザーＡが最初に「fishing [A]」をユーザーＤに付して付し、その後それを見たユーザーＢがそれを承認したとする。このようにすると、ユーザーＤのそのタグは「fishing [A, B]」となる（ユーザーＡとユーザーＢは付した人を示す）ようにしている。そして、ユーザーＣが今度はそれを見てそのタグを承認すると、そのユーザーＤのタグは「fishing [A, B, C]」ということになる。

当事者ではない第３者（ユーザーＡ、ユーザーＢ、ユーザーＣ、ユーザーＤ以外のユーザー）から見れば、ひと目で一度に「ああ、このユーザーＤについている「fishing」タグは、ユーザーＡ、ユーザーＢ、ユーザーＣの３人もの人が共通して承認しているのだな」と分かりやすい。
しかも、もっとこれを発展させて、「誰か一人でも反対者（承認しない人）がいた場合には、それは成り立たない（ユーザーＤに「fishing」というタグは付けられない）」という機能も加えると、信用度合いの効果が上がってくる。
承認をすることができる人を、予め定めることもできる。何かのグループに所属するメンバーとか、何かの資格を与えられたメンバーとか。そのメンバーだけがこの承認、非承認に参加することができることとする。そのようにすれば、さらに信用度合いが上がる。

インターネット上の辞書サイトを例に挙げると、この辞書サイトの記事の編集を多数の人に任せるようにしてもよいが、誰かの書き込みが他の人の承認を得られないとその書き込みは公表（表示）されないようにするということも実現できる。このようにすれば、信用度のある人の承認を得られた記事だけが表示されるということになる。その場合、所定の資格制を持たせるようにし、資格のある人が他の人の書き込み記事内容を承認すれば、表示されるというようにする。
すなわち、第１のユーザー（上述したユーザーＡ）が第２のユーザー（上述したユーザーＤ）に付したタグを、第３のユーザー（上述したユーザーＢ）が承認すると、第３のユーザーを「他のユーザーに所定のタグを付したユーザー」（付したユーザー）とし、第２のユーザーを「タグを付されたユーザー」（付されたユーザー）とし、第１のユーザーが第２のユーザーに付したタグを識別する情報（タグ識別情報）と同じタグを識別する情報（タグ識別情報）とをもつタグ情報を生成してタグ情報保持記憶メモリ４１に記憶させることになる。

他のユーザーが、他のユーザーに付しているタグを承認するためには、例えば、タグ承認回路４７を設け、ユーザーがこのタグ承認回路４７に上述したリクエストをすることで実現することができる。この場合、許可判定回路４５を利用し、タグを承認するときに対象となる二人のユーザーの承認を得るようにしてもよい。

なお、本発明は上記実施例に限られるものでないことは言うまでもない。当業者であれば言うまでもないことであるが、
・上記実施例の中で開示した相互に置換可能な部材および構成等を適宜その組み合わせを変更して適用すること
・上記実施例の中で開示されていないが、公知技術であって上記実施例の中で開示した部材および構成等と相互に置換可能な部材および構成等を適宜置換し、またその組み合わせを変更して適用すること
・上記実施例の中で開示されていないが、公知技術等に基づいて当業者が上記実施例の中で開示した部材および構成等の代用として想定し得る部材および構成等と適宜置換し、またその組み合わせを変更して適用することは本発明の一実施例として開示されるものである。

１０…ネットワーク、
２０…ユーザー端末、
３０…サーバー、
３１…ネットワークＩＦ、
３２…ポスト管理回路、
３３…タイムライン管理回路、
３４…ＳＮＳ管理メモリ、
４０…タグ管理システム、
４１…仮タグ情報とタグ情報保持記憶メモリ、
４２…タグ付加回路、
４３…タグ編集回路、
４４…タグ削除回路、
４５…許可判定回路、
４６…リンク情報取得回路、
４７…タグ承認回路。

Claims (9)

1. 複数のユーザー端末がネットワークを介してサーバーに接続可能となっており、同複数のユーザー端末が前記サーバーに記憶される情報へアクセスを可能としたサーバークライアントシステムであって、
   前記サーバーは、
   タグを識別する情報と、他のユーザーに所定のタグを付したユーザーと、同タグを付されたユーザーとの情報をタグ情報として保持するタグ情報保持記憶手段と、
   特定のユーザーが他のユーザーに特定のタグを付すときに、タグを付されるユーザーの許可を取得してからタグを付し、または、特定のユーザーが自分自身に特定のタグを付すときに、誰か他のユーザーの許可を取得してからタグを付すタグ付許可手段と、
   特定のタグを編集するときに、当該タグのタグ情報に含まれる相手方のユーザーの許可を取得してからタグを編集させるタグ編集手段と、
   特定のユーザーが所定のタグのタグ情報に基づいて相手側のユーザーの許可の有無にかかわらず同タグを削除するタグ削除手段と、
   タグ情報に基づいて、所定のユーザーを起点としてタグ情報で連結される他のユーザーを検索して、タグのつながり状況の情報を得るタグ付けリンク情報取得手段を備え、
   前記ユーザー端末は、前記サーバーに対し、特定のユーザーに対するタグ付けとタグ情報の編集とタグ情報の削除の要求を行い、また、タグ情報の付加と編集に対して許可することが可能であることを特徴とするサーバークライアントシステム。
2. 前記タグ付けリンク情報取得手段は、ユーザーからユーザーへのタグのつながり状況の情報を階層状に表示することを特徴とする請求項１に記載のサーバークライアントシステム。
3. 前記サーバーは、各ユーザーを、他のユーザーと、第１の関係で連結する友達関係連結手段を備え、
   この第１の関係で連結されているユーザー間で前記タグを付すことができることとしていることを特徴とする請求項１または請求項２に記載のサーバークライアントシステム。
4. 前記サーバーは、各ユーザーからの情報のポストを受け付け可能であるとともに、各ユーザーごとにタイムラインを管理可能であり、
   各ユーザーが情報をポストした場合に、当該ユーザーがタグを付したユーザーからつながる一連の当該タグでリンクされたユーザーのグループのタイムラインにポストした情報を表示することを特徴とする請求項１〜請求項３のいずれかに記載のサーバークライアントシステム。
5. 複数のタグに基づいて、ポストした情報を表示するユーザーを限定することを特徴とする請求項１〜請求項４のいずれかに記載のサーバークライアントシステム。
6. ポストした情報を表示するユーザーを、タグを付加した階層の数に基づいて限定することを特徴とする請求項１〜請求項５のいずれかに記載のサーバークライアントシステム。
7. タグ承認手段は、どちらが先に仮タグ情報を作成して相手方のユーザーに許可を求めたかにかかわらず第１のユーザーが第２のユーザーに付したタグを、第３のユーザーが承認すると、第３のユーザーを前記他のユーザーに所定のタグを付したユーザーとし、第２のユーザーを前記タグを付されたユーザーとし、第１のユーザーが第２のユーザーに付したタグを識別する情報と同じタグを識別する情報とをもつタグ情報を生成し、前記タグ情報保持記憶手段に記憶させることを特徴とする請求項１〜請求項６のいずれかに記載のサーバークライアントシステム。
8. 複数のユーザー端末がネットワークを介してサーバーに接続可能となっており、同複数のユーザー端末が前記サーバーに記憶される情報へアクセスを可能としたサーバークライアントシステムのサーバーであって、
   前記サーバーは、
   タグを識別する情報と、他のユーザーに所定のタグを付したユーザーと、同タグを付されたユーザーとの情報をタグ情報として保持するタグ情報保持記憶手段と、
   特定のユーザーが他のユーザーに特定のタグを付すときに、タグを付されるユーザーの許可を取得してからタグを付し、または、特定のユーザーが自分自身に特定のタグを付すときに、誰か他のユーザーの許可を取得してからタグを付すタグ付許可手段と、
   特定のタグを編集するときに、当該タグのタグ情報に含まれる相手方のユーザーの許可を取得してからタグを編集させるタグ編集手段と、
   特定のユーザーが所定のタグのタグ情報に基づいて相手側のユーザーの許可の有無にかかわらず同タグを削除するタグ削除手段と、
   タグ情報に基づいて、所定のユーザーを起点としてタグ情報で連結される他のユーザーを検索して、タグのつながり状況の情報を得るタグ付けリンク情報取得手段を備えることを特徴とするサーバークライアントシステムのサーバー。
9. 複数のユーザー端末がネットワークを介してサーバーに接続可能となっており、同複数のユーザー端末が前記サーバーに記憶される情報へアクセスを可能としたサーバークライアントシステムのユーザー端末であって、
   前記ユーザー端末は、前記サーバーに対し、特定のユーザーに対するタグ付けとタグ情報の編集とタグ情報の削除の要求を行い、また、タグ情報の付加と編集に対して許可することが可能であることを特徴とするユーザー端末。