JP2013025777A

JP2013025777A - 情報処理装置、情報処理方法、及び、プログラム

Info

Publication number: JP2013025777A
Application number: JP2011163366A
Authority: JP
Inventors: Hajime Gi; 元魏; Yuichi Kageyama; 雄一影山; Norifumi Yoshikawa; 典史吉川; Mitsuru Takehara; 充竹原
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2011-07-26
Filing date: 2011-07-26
Publication date: 2013-02-04
Also published as: CN102970318A; US20130031606A1; CN102970318B

Abstract

【課題】利便性の高いコミュニティを、容易に生成する。
【解決手段】ASNSサーバは、複数の端末から送信されてくる情報の類似度に応じて、コミュニティを生成する。また、ASNSサーバは、１つの端末から異なる種類の複数の情報が送信されてきた場合には、複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する。本技術は、例えば、類似する情報を送信してきたユーザどうしが参加可能な仮想世界のコミュニティの生成に適用できる。
【選択図】図１

Description

本発明は、情報処理装置、情報処理方法、及び、プログラムに関し、特に、例えば、利便性の高い（仮想的な）コミュニティを、容易に生成することができるようにする情報処理装置、情報処理方法、及び、プログラムに関する。

現実世界（実世界）では、人は、例えば、結婚式や、勉強会、日常のランチ、会社のミーティング等のコミュニティをつくるが、現在、そのような現実世界のコミュニティの他、情報を共有するために、インターネット等のネットワーク上の、仮想世界の（仮想的な）コミュニティとしての、例えば、SNS(Social Network Service)や掲示板等が普及している。

そして、現実世界のコミュニティと、仮想世界のコミュニティとを同期させること、すなわち、現実世界において、空間及び時間を共有しているユーザだけが参加することができる仮想世界のコミュニティの提案が要請されている。

例えば、現実世界のコミュニティとしての結婚式に参加しているユーザが、その結婚式に同期した仮想世界のコミュニティに参加することで、新郎新婦の写真や、動画、メッセージ等を共有することができる。また、例えば、現実世界のコミュニティとしての勉強会に参加しているユーザが、その勉強会に同期した仮想世界のコミュニティに参加することで、勉強会の資料等を共有することができる。

しかしながら、既存のSNSや掲示板では、仮想世界のコミュニティ（以下、特に必要がない限り、単に、コミュニティという）への参加の手続が煩雑であることや、セキュリティに問題があることがある。

すなわち、既存のSNSでは、ユーザの誰かが、コミュニティを管理するオーナ（管理者）となって、他のユーザを、コミュニティに招待する必要があり、招待されたユーザは、アカウントを作ることや、アカウントを用いてログインをする必要がある。

また、既存の掲示板では、SNSよりコミュニティを作り易いが、その掲示板のアドレスを、コミュニティに招待するユーザに伝える必要がある。さらに、既存の掲示板では、コミュニティに、不特定多数からアクセスされるおそれがある。

以上のようなコミュニティへの参加の手続の煩雑さや、セキュリティの問題に対処するために、様々なSNSが提案されている。

例えば、特許文献１では、GPS機能を有するモバイル機器において、位置情報や時間情報を利用することで、同じ時間と同じ場所を共有しているユーザ（モバイル機器）のみでコミュニティを形成し、オーナが、コミュニティに招待するという手続きを行わずに済むSNSが提案されている。

また、特許文献２では、大学の講義室の机に、ID(Identification)を登録した座席検知用のUSB(Universal Serial Bus)メモリを取り外し不可能に設置し、授業に参加した学生が、机に設置されているUSBメモリから、IDをPC(Personal Computer)に取り込むことで、授業に参加した学生の情報発信を可能とすることが提案されている。

その他、コミュニティに関しては、ユーザIDを事前に作成し、プロフィールを交換してから、コミュニケーションをすること(http://jp.techcrunch.com/archives/jp-the-day-sekai-camera-threw-away-camera/)や、FacebookのIDを利用して、コミュニティを生成するアプリケーション(http://www.itmedia.co.jp/news/articles/1103/02/news029.html)が提案されている。

なお、特許文献１及び２の技術では、個人の繋がりを識別するために、個人認証用のIDを何かしらの方法であらかじめ設定する必要がある。また、特許文献２に記載の技術では、IDが登録されたUSBメモリが、取り外し不可能なように、講義室の机に設置されているため、場所の汎用性がなく、講義室でなければ、情報発信をすることができない。

特開2010-218524号公報特開2008-257359号公報

コミュニティについては、利便性の高いコミュニティを、容易に生成する技術の提案が要請されている。

本技術は、このような状況に鑑みてなされたものであり、利便性の高いコミュニティを、容易に生成することができるようにするものである。

本技術の一側面の情報処理装置、又は、プログラムは、端末から送信されてくる情報を取得する取得部と、複数の端末から送信されてくる情報の類似度に応じて、コミュニティを生成する生成部とを備え、前記コミュニティ生成部は、１つの端末から異なる種類の複数の情報が送信されてきた場合に、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する情報処理装置、又は、情報処理装置として、コンピュータを機能させるためのプログラムである。

本技術の一側面の情報処理方法は、端末から送信されてくる情報を取得し、複数の端末から送信されてくる情報の類似度に応じて、コミュニティを生成するステップを含み、前記コミュニティの生成では、１つの端末から異なる種類の複数の情報が送信されてきた場合に、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する情報処理方法である。

以上のような一側面においては、端末から送信されてくる情報が取得され、複数の端末から送信されてくる情報の類似度に応じて、コミュニティが生成される。コミュニティの生成では、１つの端末から異なる種類の複数の情報が送信されてきた場合に、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数がカウントされ、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティが生成される。

なお、情報処理装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。

また、プログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。

本技術の一側面によれば、利便性の高いコミュニティを、容易に生成することができる。

本技術を適用したコミュニティ提供システムの一実施の形態の構成例を示すブロック図である。コミュニティ提供システムの処理の概要を説明する図である。携帯端末１１のハードウェアの構成例を示すブロック図である。携帯端末１１の機能的な構成例を示すブロック図である。携帯端末１１の処理を説明するフローチャートである。 ASNSサーバ１２の機能的な構成例を示すブロック図である。コミュニティ管理部６２の構成例を示すブロック図である。仮登録DB６４に記憶される仮テーブルの例を示す図である。コミュニティDB６５に記憶される認証テーブルの例を示す図である。コミュニティDB６５に記憶されるコミュニティテーブルの例を示す図である。仮テーブルを示す図である。仮テーブルを示す図である。仮テーブルを示す図である。仮テーブルを示す図である。仮テーブル、認証テーブル、及び、コミュニティテーブルを示す図である。仮テーブルを示す図である。仮テーブルを示す図である。仮テーブルを示す図である。仮テーブルを示す図である。コミュニティの生成を説明する図である。コミュニティの生成を説明する図である。仮テーブル登録処理を説明するフローチャートである。共通オブジェクト処理の詳細を説明するフローチャートである。認証ID付与処理を説明するフローチャートである。コミュニティ生成処理を説明するフローチャートである。セキュリティ処理を説明するフローチャートである。セキュリティ処理を説明するフローチャートである。コミュニティ提供システムがコミュニティを提供する処理を説明する図である。参加希望ユーザが、第１の途中参加方法により、コミュニティに途中参加する場合の携帯端末１１の処理を説明するフローチャートである。参加希望ユーザが、第１の途中参加方法により、コミュニティに途中参加する場合のASNSサーバ１２の処理を説明するフローチャートである。参加希望ユーザが、第１の途中参加方法により、コミュニティに途中参加する場合の、コミュニティ提供システムの処理を説明する図である。参加希望ユーザが、第２の途中参加方法により、コミュニティに途中参加する場合の携帯端末１１の処理を説明するフローチャートである。参加希望ユーザが、第２の途中参加方法により、コミュニティに途中参加する場合のASNSサーバ１２の処理を説明するフローチャートである。参加希望ユーザが、第２の途中参加方法により、コミュニティに途中参加する場合の、コミュニティ提供システムの処理を説明する図である。

［本技術を適用したコミュニティ提供システムの一実施の形態］

図１は、本技術を適用したコミュニティ提供システムの一実施の形態の構成例を示すブロック図である。

図１において、コミュニティ提供システムは、ネットワーク１０、複数の携帯端末１１、及び、ASNSサーバ１２を有する。

ネットワーク１０は、インターネット等のネットワークであり、そこには、ASNSサーバ１２が接続されている。

携帯端末１１は、例えば、携帯ゲーム機や、携帯電話機、スマートフォン等の携帯型のタブレット端末、ノート型のPC等の、ユーザが携帯可能な端末であり、ネットワーク１０を介して、ASNSサーバ１２と通信する機能を有している。

なお、ネットワーク１０と携帯端末１１との間の通信としては、無線通信、及び、有線通信のいずれをも採用することができる。

ASNSサーバ１２は、ネットワーク１０を介して、携帯端末１１と通信することにより、その場にいる一定のユーザだけが参加（アクセス）可能で、かつ、セキュアなコミュニケーションを実現する臨時的なコミュニティ（臨時コミュニティ）を、携帯端末１１のユーザに提供する。

ここで、ASNSサーバ１２がコミュニティ（臨時コミュニティ）を提供するサービスを、ASNS(Adhoc SNS)ともいう。

図２は、図１のコミュニティ提供システムの処理の概要を説明する図である。

コミュニティに参加しようとするユーザは、そのユーザが所有する携帯端末１１を操作することにより、例えば、GPS(Global Positioning System)によって獲得される現在地の位置情報や、所定の画像、音声（音）、テキスト等の情報であるオブジェクトを、ASNSサーバ１２に送信する。

ASNSサーバ１２は、携帯端末１１からのオブジェクトを受信し、オブジェクトを送信してきた携帯端末１１の中で、同一とみなせる時刻に、互いに共通（類似）するオブジェクトを送信してきた携帯端末１１のユーザのみが参加可能なコミュニティを生成する。

したがって、例えば、現実世界で、空間及び時間を共有している複数のユーザが、各ユーザの所有する携帯端末１１を操作して、互いに共通するオブジェクトを、ASNSサーバ１２に送信するだけで、ASNSサーバ１２では、互いに共通するオブジェクトを送信してきた携帯端末１１のユーザのみが参加可能なコミュニティが生成される。

さらに、ASNSサーバ１２は、互いに共通するオブジェクトを送信してきた携帯端末１１のユーザのみが参加可能なコミュニティを識別する一時的なIDであるコミュニティIDを、互いに共通するオブジェクトを送信してきた携帯端末１１に送信するとともに、コミュニティに参加する携帯端末１１（のユーザ）を識別する一時的なIDである端末IDを、各携帯端末１１に送信する。

互いに共通するオブジェクトを送信した携帯端末１１は、その携帯端末１１の端末IDと、その携帯端末１１（のユーザ）が参加するコミュニティのコミュニティIDとを受信する。そして、携帯端末１１は、端末IDとコミュニティIDとを用いて、コミュニティIDによって識別されるコミュニティに参加（アクセス）することができる。

ここで、コミュニティの生成、及び、そのコミュニティへの参加を目的として、複数のユーザが、各ユーザの所有する携帯端末１１を操作して、ASNSサーバ１２に送信するオブジェクトは、何らかの共通性（類似性）を必要とする。そこで、コミュニティの生成、及び、そのコミュニティへの参加を目的として、ユーザが、携帯端末１１を操作して、ASNSサーバ１２に送信するオブジェクトを、共通オブジェクトともいう。

ASNSサーバ１２では、共通オブジェクトが、ユーザがコミュニティに参加するための、ユーザの認証に用いられる。

すなわち、ASNSサーバ１２では、同一とみなせる時刻に受信した複数の共通オブジェクトが互いに類似している（共通性がある）場合に、その互いに類似する共通オブジェクトを送信してきた携帯端末１１のユーザにのみ参加が許可されるコミュニティが生成される。

このため、ASNSサーバ１２が生成するコミュニティには、そのコミュニティにユーザを招待するオーナを必要としない。

共通オブジェクトに用いるオブジェクトは、現実世界で空間及び時間を共有し、かつ、コミュニティに参加しようとしているユーザのみが知り得る情報（その場にいない人が知り得ない情報）であることが望ましい。

したがって、共通オブジェクトとしては、例えば、その場にいる人を撮影した写真や動画、その場の風景を所定の構図で撮影した写真や動画、その場で決めた合い言葉としてのテキストや音声、携帯端末１１がGPSの機能を有する場合には、その機能によって獲得される現在地の位置情報等を採用することができる。

なお、ASNSサーバ１２では、複数の共通オブジェクトが互いに類似しているかどうかの類似性の判定（類似判定）を行うが、類似判定の方法は、共通オブジェクトの種類（例えば、テキストや、画像、音声等のメディアの違い）によって異なり、また、科学技術の進化によって変化する。

共通オブジェクトが、例えば、テキストの合い言葉である場合には、その合い言葉としてのテキストどうしが完全に一致するときに、複数の共通オブジェクトとしての合い言葉（どうし）が類似すると判定することができる。

また、共通オブジェクトが、例えば、人を撮影した写真（人写真）である場合には、その人写真に映る人どうしが類似する度合いを表す類似度が所定の閾値以上であるときに、複数の共通オブジェクトとしての人写真（どうし）が類似すると判定することができる。

さらに、共通オブジェクトが、例えば、その場の風景を同一の構図で撮影した写真である場合には、その写真全体どうしの類似度が所定の閾値以上であるときに、複数の共通オブジェクトとしての写真（どうし）が類似すると判定することができる。

また、共通オブジェクトが、例えば、その場の音（環境音）である場合には、その環境音の波形どうしの類似度が所定の閾値以上であるときに、複数の共通オブジェクトとしての環境音（どうし）が類似すると判定することができる。

さらに、共通オブジェクトが、例えば、その場の１シーンを撮影した動画（音声が付随する動画）である場合には、その動画としての画像どうしの類似度が所定の閾値以上であり、かつ、動画に付随する音声の波形どうしの類似度が所定の閾値以上であるときに、複数の共通オブジェクトとしての動画（どうし）が類似すると判定することができる。

また、共通オブジェクトが、例えば、現在地の位置情報である場合には、その位置情報が表す位置どうしの距離が所定の閾値以下であるときに、複数の共通オブジェクトとしての位置情報（どうし）が類似すると判定することができる。

さらに、共通オブジェクトとしては、複数のオブジェクトを採用することができる。すなわち、共通オブジェクトとしては、例えば、第１の構図で撮影した第１の写真と第２の構図で撮影した第２の写真等の、同一の種類の複数のオブジェクトや、位置情報と動画等の、異なる種類の複数のオブジェクトを採用することができる。

共通オブジェクトとして、複数のオブジェクトを採用する場合には、ASNSサーバ１２では、複数のオブジェクトそれぞれが類似するときに、すなわち、例えば、共通オブジェクトとして、例えば、位置情報と動画を採用する場合には、ASNSサーバ１２では、位置情報どうしが類似し、かつ、動画どうしが類似するときに、共通オブジェクトどうしが類似すると判定される。

以上のように、共通オブジェクトとして、例えば、位置情報と動画等の複数のオブジェクトを採用し、位置情報どうしが類似し、かつ、動画どうしが類似するときに、共通オブジェクトどうしが類似すると判定する場合には、１つのオブジェクトを共通オブジェクトとして用いる場合よりもセキュアなコミュニティを生成することができる。

なお、ASNSサーバ１２では、同一とみなせる時刻に受信した複数の共通オブジェクトの類似性が判定され、その複数の共通オブジェクトが互いに類似していると判定された場合に、その互いに類似する共通オブジェクトを送信してきた携帯端末１１のユーザにのみ参加が許可されるコミュニティが生成されるが、この、コミュニティの生成において、互いに類似していると判定された共通オブジェクトを、コミュニティ生成用オブジェクトということとする。

ASNSサーバ１２では、コミュニティの生成後、そのコミュニティにまだ参加していないユーザ（以下、未参加ユーザともいう）の携帯端末１１から、共通オブジェクトが送信されてきた場合に、その共通オブジェクトと、コミュニティ生成用オブジェクトとが類似するときには、未参加ユーザのコミュニティへの参加（未参加ユーザの携帯端末１１からの、コミュニティへのアクセス）を許可することができる。

この場合、コミュニティ生成用オブジェクトと類似する共通オブジェクトを送信してきた未参加ユーザによるコミュニティへの参加を許可する期限を、コミュニティの生成後の一定期間に制限することで、コミュニティのセキュリティを向上させることができる。

［ハードウェアの構成例］

図３は、図１の携帯端末１１のハードウェアの構成例を示すブロック図である。

図３において、携帯端末１１は、バス２１、CPU(Central Processing Unit)２２、ROM(Read Only Memory)２３、RAM(Random Access Memory)２４、ハードディスク２５、出力部２６、入力部２７、通信部２８、ドライブ２９、入出力インターフェース３０、及び、リムーバブル記録媒体３１を有する。

CPU２２ないしハードディスク２５、及び、入出力インターフェース３０は、バス２１介して接続されている。CPU２２ないしハードディスク２５、及び、入出力インターフェース３０（に接続されているデバイス）は、バス２１を介して、相互に、データをやりとりすることができる。

また、入出力インターフェース３０には、出力部２６ないしドライブ２９が接続されており、したがって、CPU２２ないしドライブ２９は、バス２１や入出力インターフェース３０を介して、相互に、データをやりとりすることができる。

CPU２２は、ROM２３に記憶されたプログラムや、ハードディスク２５等から読み出されて、RAM２４に記憶（展開）されたプログラムを実行することにより、各種の処理を行う。

ROM２３は、例えば、EEPROM(Electrically Erasable Programmable ROM)等であり、携帯端末１１の電源がオフにされたときも保持する必要があるデータやプログラムを記憶する。

RAM２４は、CPU２２の動作上必要なプログラムやデータを記憶する。

ハードディスク２５には、CPU２２が実行するプログラムや、各種のデータが記録される。

出力部２６は、例えば、液晶パネル等の表示装置、及び、スピーカ等であり、画像を表示し、音声を出力する。

入力部２７は、例えば、キーボードや、タブレット（タッチスクリーン）等のポインティングデバイス等であり、ユーザによって操作され、その操作に応じたデータ（信号）を出力する。

通信部２８は、例えば、LAN(Local Area Network)等の通信インターフェースであり、外部の装置との、無線や有線での通信を制御する。

ドライブ２９には、DVD(Digital Versatile Disc)等の光ディスクや、USBメモリ等の半導体メモリであるリムーバブル記録媒体３１の着脱が可能になっている。

ドライブ２９は、そこに装着されたリムーバブル記録媒体３１を駆動することにより、リムーバブル記録媒体３１にデータを記録し、また、リムーバブル記録媒体３１からデータを読み出す。

入出力インターフェース３０は、各種のデバイスを、携帯端末１１に接続するためのインターフェースとして機能する。図３では、上述したように、入出力インターフェース３０には、バス２１、出力部２６ないしドライブ２９が接続されているが、入出力インターフェース３０には、その他のデバイスを接続することが可能である。

以上のように構成される携帯端末１１において、ハードディスク２５には、ASNSのクライアント側のプログラムであるクライアントプログラム（クライアントアプリケーション）等がインストールされている。

CPU２２は、ハードディスク２５にインストールされているプログラムを実行することにより、各種の処理を行う。

なお、プログラムは、ハードディスク２５にあらかじめインストールしておくことができる。

また、プログラムは、リムーバブル記録媒体３１に格納（記録）しておき、リムーバブル記録媒体３１から携帯端末１１にインストールすることができる。このようなリムーバブル記録媒体３１は、いわゆるパッケージソフトウエアとして提供することができる。

なお、プログラムは、リムーバブル記録媒体３１から携帯端末１１にインストールする他、通信網や放送網を介して、携帯端末１１にダウンロードし、内蔵するハードディスク２５にインストールすることができる。すなわち、プログラムは、例えば、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、携帯端末１１に無線で転送することや、LAN、インターネットといったネットワークを介して、携帯端末１１に有線で転送することができる。

ここで、携帯端末１１の他、ASNSサーバ１２（図１）も、図３に示したように構成される。

但し、携帯端末１１、及び、ASNSサーバ１２それぞれでは、ハードディスク２５にインストールされているプログラムが異なる。ASNSサーバ１２には、クライアントプログラム（クライアントアプリケーション）ではなく、ASNSのサーバ側のプログラムであるサーバプログラム（サーバアプリケーション）等がインストールされている。

［携帯端末１１の機能的構成例］

図４は、図１の携帯端末１１の機能的な構成例を示すブロック図である。

携帯端末１１は、CPU２２（図３）がクライアントプログラムを実行することにより、等価的に、図４の機能的構成となって、各種の処理を行う。

図４において、携帯端末１１は、通信部５１、共通オブジェクト取得部５２、及び、制御部５３を有する。

通信部５１は、ネットワーク１０（図１）を介して、ASNSサーバ１２と通信を行う。また、通信部５１は、その他、例えば、wifi（登録商標）-directや、赤外線、Bump（登録商標）、3G、Bluetooth（登録商標）、さらには、例えば、NFC(Near Field Communication)等の近接通信によって、他の携帯端末１１等との間で通信を行うことができる。

共通オブジェクト取得部５２は、例えば、ユーザの操作等に従って、共通オブジェクトを取得する。

すなわち、共通オブジェクト取得部５２は、例えば、GPSの機能を有し、現在地の位置情報を、共通オブジェクトとして取得する。また、共通オブジェクト取得部５２は、例えば、カメラやマイクであり、動画や、静止画としての写真、音声を、共通オブジェクトとして取得する。さらに、共通オブジェクト取得部５２は、例えば、キーボードや、音声認識装置であり、ユーザがキーボードを操作することにより入力するテキストや、ユーザが発した音声を音声認識装置で音声認識することにより得られるテキストを、共通オブジェクトとして取得する。

その他、共通オブジェクト取得部５２は、携帯端末１１に記憶されている動画や、写真、音声、テキスト等のファイルを、共通オブジェクトとして取得することができる。

制御部５３は、携帯端末１１全体を制御する。

［携帯端末１１の処理］

図５は、図４の携帯端末１１の処理を説明するフローチャートである。

コミュニティに参加しようとするユーザは、例えば、クライアントプログラムを起動し、その後、共通オブジェクトを取得するように、ユーザが所有する携帯端末１１を操作する。

携帯端末１１は、ユーザの操作に従って、クライアントプログラムを起動し、これにより、図４に示した構成となって、ASNSのクライアントとして機能する。

すなわち、ステップＳ１１において、共通オブジェクト取得部５２（図４）が、例えば、ユーザの操作に従って、共通オブジェクトを取得し、処理は、ステップＳ１２に進む。

ステップＳ１２では、通信部５１（図４）は、共通オブジェクト取得部５２が取得した共通オブジェクトを含む、ASNSサーバ１２が要求するデータを、ASNSサーバ１２に送信し、処理は、ステップＳ１３に進む。

ここで、携帯端末１１の通信部５１が、ASNSサーバ１２に送信する、共通オブジェクトを含むデータを、端末データともいう。

ステップＳ１３では、制御部５３（図４）は、ASNSサーバ１２から、コミュニティへの参加（アクセス）が許可されたかどうかを判定する。

ステップＳ１３において、コミュニティへの参加が許可されなかったと判定された場合、すなわち、後述するようにして、ASNSサーバ１２から、コミュニティを識別するコミュニティID(C_id)と、携帯端末１１を識別する端末ID(i-uid)とが送信されてこなかった場合、ステップＳ１４及びＳ１５をスキップして、処理は終了する。

また、ステップＳ１３において、コミュニティへの参加が許可されたと判定された場合、すなわち、ASNSサーバ１２から、コミュニティID(C_id)と、端末ID(i-uid)とが送信されてきた場合、処理は、ステップＳ１４に進み、通信部５１は、ASNSサーバ１２からのコミュニティIDと端末IDとを受信して、処理は、ステップＳ１５に進む。

ステップＳ１５では、制御部５３は、通信部５１で受信されたコミュニティIDと端末IDとを用いて、コミュニティに参加する。

すなわち、制御部５３は、例えば、ユーザの操作に応じて、通信部５１を制御することにより、ネットワーク１０を介して、ASNSサーバ１２上に生成された、コミュニティIDで識別されるコミュニティに、例えば、写真や動画の画像データ、ユーザのメールアドレス等プロフィールその他のコンテンツをアップロードする。

また、制御部５３は、例えば、ユーザの操作に応じて、通信部５１を制御することにより、コミュニティIDで識別されるコミュニティから、コンテンツをダウンロードする。

コミュニティでは、コンテンツのアップロード及びダウンロードの他、そのコミュニティに参加しているユーザどうして、メッセージのやりとり等を行うことができる。コミュニティを介してのメッセージのやりとりが行われる場合、制御部５３は、そのメッセージのやりとりを制御する。

［ASNSサーバ１２の機能的構成例］

図６は、図１のASNSサーバ１２の機能的な構成例を示すブロック図である。

ASNSサーバ１２は、CPU２２（図３）がサーバプログラムを実行することにより、等価的に、図６の機能的構成となって、各種の処理を行う。

図６において、ASNSサーバ１２は、通信部６１、コミュニティ管理部６２、制御部６３、仮登録DB(DataBase)６４、及び、コミュニティDB６５を有する。

通信部６１は、ネットワーク１０（図１）を介して、携帯端末１１と通信を行う。

コミュニティ管理部６２は、例えば、仮登録DB６４やコミュニティDB６５に記憶されたデータ等に基づいて、コミュニティの生成その他のコミュニティの管理を行う。

制御部６３は、ASNSサーバ１２全体を制御する。

仮登録DB６４は、後述する仮テーブルを記憶している。

コミュニティDB６５は、後述する認証テーブル、及び、コミュニティテーブルを記憶している。

図７は、図６のコミュニティ管理部６２の構成例を示すブロック図である。

図７において、コミュニティ管理部６２は、制御部７１、共通オブジェクト処理部７２、コミュニティ生成部７３、コミュニティ処理部７４、及び、コンテンツ管理部７５を有する。

制御部７１は、コミュニティ管理部６２全体を制御する。

共通オブジェクト処理部７２は、携帯端末１１からASNSサーバ１２に送信されてくる共通オブジェクトを取得し、共通オブジェクトどうしの類似度（距離）の算出や、その類似度に基づく共通オブジェクトどうしの類似性の判定、その他、共通オブジェクトに関する処理を行う。

コミュニティ生成部７３は、携帯端末１１からの共通オブジェクトの類似度に応じて、コミュニティを生成する。

すなわち、コミュニティ生成部７３は、携帯端末１１からASNSサーバ１２に送信されてくる共通オブジェクトどうしの、類似度に基づく類似性の判定において、共通オブジェクトどうしが類似していると判定された場合、つまり、複数の携帯端末１１から送信されてきた共通オブジェクトどうしが、互いに類似する場合、その互いに類似する共通オブジェクトを送信してきた携帯端末１１（のユーザ）に参加を許可するコミュニティを生成する。

ここで、コミュニティの実体は、メモリ（例えば、図３のRAM２４等）上に確保される記憶領域である。コミュニティに参加しているユーザ（の携帯端末１１）は、そのコミュニティとしての記憶領域を用いて、コンテンツのアップロードやダウンロード、他のユーザとのメッセージのやりとり等を行うことができる。

コミュニティ処理部７４は、コミュニティ生成部７３が生成したコミュニティを管理する。すなわち、コミュニティ処理部７４は、コミュニティに参加しているユーザの携帯端末１１からアップロード（送信）されてきたコンテンツのコミュニティへの保存や、携帯端末１１からダウンロードが要求されたコンテンツのコミュニティからの読み出し、ユーザどうしがコミュニティを介してメッセージをやりとりするための、メッセージの送受信の制御等を行う。

コンテンツ管理部７５は、コミュニティにアップロードされたコンテンツを管理する。すなわち、コンテンツ管理部７５は、例えば、コミュニティにアップロードされたコンテンツの削除を行うことを、そのコンテンツの所有者（コンテンツをアップロードしたユーザ）だけに制限する。また、コンテンツ管理部７５は、例えば、コミュニティにアップロードされたコンテンツのダウンロードを行うことを、そのコンテンツの所有者が許可したユーザだけに制限する。

［仮テーブル］

図８は、図６の仮登録DB６４に記憶される仮テーブルの例を示す図である。

コミュニティ管理部６２のコミュニティ生成部７３（図７）は、携帯端末１１から端末データが送信され、通信部６１（図６）で受信されると、１つの端末データについて、仮テーブルに、１つのエントリ（レコード）を新たに登録する。

仮テーブル（のエントリ）には、id，Auth_id，i_uid，MAC，time，Auth_type，obj、及び、S_levelが登録される。

仮テーブルにおいて、idは、仮テーブルのエントリを区別（識別）する識別情報（以下、仮テーブルIDともいう）である。

コミュニティ生成部７３は、仮テーブルに、新たなエントリを登録するときに、その新たなエントリに対して、仮テーブルIDを付与する。図８では、エントリごとにユニークな番号が、仮テーブルのid（仮テーブルID）として使用されている。

Auth_idは、共通オブジェクトが類似する複数の端末データ（についてのエントリ）をグループにグルーピングするための、そのグループを区別する識別情報（以下、認証IDともいう）である。

すなわち、図５で説明したように、携帯端末１１がASNSサーバ１２に送信する端末データには、共通オブジェクトが含まれており、コミュニティ生成部７３は、複数の携帯端末１１から送信されていた端末データそれぞれに含まれる共通オブジェクトが類似する場合、その類似する共通オブジェクトを送信してきた複数の（携帯端末１１の）ユーザがコミュニティに参加するための認証が成功したこととして、その複数の携帯端末１１からの端末データそれぞれについてのエントリに対し、同一の認証ID(Auth_id)を付与する。

図８では、グループごとにユニークな番号が、認証ID(Auth_id)として使用されている。

i_uidは、端末データを送信してきた携帯端末１１（のユーザ）を識別する識別情報（以下、端末IDともいう）である。

コミュニティ生成部７３は、１つの端末データについてのエントリを、仮テーブルに登録するときに、その端末データを送信してきた携帯端末１１に、一時的なIDを端末ID(i_uid)として付与する。

図８では、端末データを送信してきた携帯端末１１（のユーザ）ごとにユニークな番号が、端末ID(i_uid)として使用されている。

ここで、以上のように、端末ID(i_uid)は、携帯端末１１（のユーザ）ごとにユニークであるため、仮テーブルに、ある携帯端末１１から送信されてきた端末データについてのエントリが、既に登録されている場合において、同一の携帯端末１１から、端末データが、再度送信されてきたときには、その再度送信されてきた端末データについてのエントリには、同一の携帯端末１１について既に登録されているエントリに付与されている端末IDと同一の端末IDが付与される。

図８では、仮テーブルID(id)が2と3とのエントリに、同一の端末ID(i_uid)である345が登録されている。この仮テーブルID(id)が2と3とのエントリは、同一の携帯端末１１（のユーザ）から、送信データが２回送信され、１回目の端末データと２回目の端末データとのそれぞれについて登録されたエントリである。

MACは、端末データを送信してきた携帯端末１１のMACアドレスを表し、timeは、エントリが、仮テーブルに登録された時刻（日時）を表す。

Auth_typeは、コミュニティに参加するための認証に用いられる情報、すなわち、共通オブジェクトの種類（メディア）を表す。

コミュニティ生成部７３は、端末データについてのエントリを、仮テーブルに登録するときに、その端末データに含まれる共通オブジェクトの種類を認識し、その種類を表す情報を、Auth_typeとして登録する。

ここで、例えば、値が1のAuth_typeは、共通オブジェクトが、例えば、写真であることを表す。また、例えば、値が2のAuth_typeは、共通オブジェクトが、例えば、音声であることを表し、例えば、値が3のAuth_typeは、共通オブジェクトが、例えば、動画であることを表す。さらに、例えば、値が4のAuth_typeは、共通オブジェクトが、例えば、位置情報であることを表し、例えば、値が5のAuth_typeは、共通オブジェクトが、例えば、テキストであることを表す。また、例えば、値が9のAuth_typeは、共通オブジェクトが、例えば、文字の羅列であるトークンであることを表す。

objは、携帯端末１１からの端末データに含まれる共通オブジェクト（又は、共通オブジェクトのファイル名等のURI(Uniform Resource Identifier)）である。

S_levelは、コミュニティのセキュリティ、すなわち、コミュニティに参加するための認証の厳しさ（厳重さ）を表すセキュリティレベルである。

セキュリティレベルには、例えば、セキュリティが緩いことを表すレベル１（第１レベル）、セキュリティが緩くもなく、厳しくもない（普通である）ことを表すレベル２（第２レベル）、及び、セキュリティが厳しいことを表すレベル３がある。

レベル１のセキュリティレベルでは、コミュニティに参加する複数のユーザの携帯端末１１それぞれから送信されてくる共通オブジェクトが、異なる種類のオブジェクトであることが許可（許容）される。

したがって、レベル１のセキュリティレベルでは、後述するように、例えば、写真を共通オブジェクトとして含む端末データを送信してきた（携帯端末１１の）ユーザと、音声を共通オブジェクトとして含む端末データを送信してきたユーザのような、異なる種類の共通オブジェクトを送信してきたユーザどうしが、同一のコミュニティに参加することができる。

レベル２のセキュリティレベルでは、コミュニティに参加する複数のユーザの携帯端末１１それぞれから送信されてくる共通オブジェクトが、同一の種類のオブジェクトであることが要求される。

したがって、レベル２のセキュリティレベルでは、例えば、写真を共通オブジェクトとして含む端末データを送信してきたユーザと、音声を共通オブジェクトとして含む端末データを送信してきたユーザのような、異なる種類の共通オブジェクトを送信してきたユーザどうしは、同一のコミュニティに参加することができない。

レベル３のセキュリティレベルでは、コミュニティに参加する複数のユーザの携帯端末１１それぞれから、２つ以上の共通オブジェクト（を含む端末データ）が送信されてくることが要求される。

そして、レベル３のセキュリティレベルでは、あるユーザ（の携帯端末１１）が送信してきた２つ以上の共通オブジェクトそれぞれと、他のユーザが送信してきた２つ以上の共通オブジェクトそれぞれとが類似している場合に、それらのユーザに、コミュニティへの参加が許可される。

なお、レベル３のセキュリティレベルで必要となる２つ以上の共通オブジェクトは、同一の種類のオブジェクトであってもよいし、異なる種類のオブジェクトであってもよい。

ここで、携帯端末１１からの端末データには、共通オブジェクト(obj)の他、携帯端末１１のMACアドレス、及び、セキュリティレベル(S_level)等が含まれる。コミュニティ生成部７３は、端末データに含まれる共通オブジェクト(obj)、MACアドレス、及び、セキュリティレベル(S_level)を、仮テーブルに登録する。

また、セキュリティレベル(S_level)については、携帯端末１１において、ユーザによる、セキュリティレベルを指定する操作に応じて、端末データに含めることができる。さらに、ユーザが、セキュリティレベルを指定する操作を行わなかった場合には、携帯端末１１において、デフォルトのセキュリティレベルを、端末データに含めることができる。

端末データに、デフォルトのセキュリティレベルが含まれる場合、コミュニティ生成部７３は、デフォルトのセキュリティレベルとしての、例えば、レベル１を、仮テーブルに登録する。

なお、コミュニティ生成部７３において、デフォルトのセキュリティレベルは、例えば、携帯端末１１の現在地の位置情報に基づいて設定することができる。

すなわち、携帯端末１１において、端末データには、携帯端末１１の現在地の位置情報を含め、コミュニティ生成部７３では、端末データに含まれる位置情報に基づいて、デフォルトのセキュリティレベルを、例えば、レベル１やレベル３に設定することができる。

具体的には、携帯端末１１の位置情報が、例えば、結婚式場や飲食店等の不特定の人が出入りする場所を表している場合には、セキュリティが緩いレベル１を、デフォルトのセキュリティレベルとして設定することができる。

また、携帯端末１１の位置情報が、例えば、会社の会議室等の特定の人が出入りする場所を表している場合には、セキュリティが厳しいレベル３を、デフォルトのセキュリティレベルとして設定することができる。

なお、セキュリティレベルとしては、上述したレベル１ないし３の他、例えば、携帯端末１１の現在地に応じて、認証に要求される共通オブジェクトが異なる、といったようなレベルを採用することができる。

［認証テーブル］

図９は、図６のコミュニティDB６５に記憶される認証テーブルの例を示す図である。

コミュニティ生成部７３（図７）は、仮テーブルに登録されたエントリ（の端末データを送信してきたユーザ）の認証が成功すると、その認証が成功したエントリに登録されたデータ（エントリデータ）、すなわち、認証IDを付与したエントリデータ（以下、認証成功データともいう）について、認証テーブルに、エントリを新たに登録する（仮テーブルの、認証IDが付与されたエントリに対応するエントリを、認証テーブルに登録する）。

認証テーブル（のエントリ）には、id，Auth_id，i_uid，MAC，time，Auth_type、及び、objが登録される。

認証テーブルにおいて、idは、認証テーブルのエントリを区別する識別情報（以下、認証テーブルIDともいう）である。

コミュニティ生成部７３は、認証テーブルに、新たなエントリを登録するときに、その新たなエントリに対して、認証テーブルIDを付与する。図９では、エントリごとにユニークな番号が、認証テーブルのid（認証テーブルID）として使用されている。

なお、認証テーブルIDは、仮テーブルIDとは、別個の、独立のIDである。

Auth_idは、図８で説明した認証IDであり、コミュニティ生成部７３は、認証テーブルのエントリに、そのエントリに対する認証成功データ（仮テーブルの、認証IDが付与されたエントリのデータ）に含まれる認証IDを登録する。

i_uidは、図８で説明した端末IDであり、コミュニティ生成部７３は、認証テーブルのエントリに、そのエントリに対する認証成功データに含まれる端末IDを登録する。

MACは、MACアドレスを表し、コミュニティ生成部７３は、認証テーブルのエントリに、そのエントリに対する認証成功データに含まれるMACアドレスを登録する。

timeは、エントリが、認証テーブルに登録された時刻（日時）を表す。

Auth_typeは、図８の場合と同様に、共通オブジェクトの種類を表し、コミュニティ生成部７３は、認証テーブルのエントリに、そのエントリに対する認証成功データに含まれるAuth_typeを登録する。

objは、図８の場合と同様に、共通オブジェクトであり、コミュニティ生成部７３は、認証テーブルのエントリに、そのエントリに対する認証成功データに含まれる共通オブジェクト(obj)を登録する。

［コミュニティテーブル］

図１０は、図６のコミュニティDB６５に記憶されるコミュニティテーブルの例を示す図である。

コミュニティ生成部７３（図７）は、認証テーブルに登録されたエントリの中に、同一の認証ID(Auth_id)が付与されたエントリがある場合、その同一の認証IDが付与された（エントリの元になった端末データを送信してきた携帯端末１１の）ユーザが参加可能なコミュニティを生成する。

すなわち、コミュニティ生成部７３は、同一の認証IDが付与されたユーザが参加可能なコミュニティとしての記憶領域を確保する。

さらに、コミュニティ生成部７３は、同一の認証IDが付与されたユーザが参加可能なコミュニティについて、コミュニティテーブルに、コミュニティを管理するためのコミュニティデータのエントリを新たに登録する（認証テーブルの、同一の認証IDが付与されたエントリに対応するエントリを、コミュニティテーブルに登録する）。

コミュニティテーブル（のエントリ）には、コミュニティデータとしてのid，C_id，i_uid，time，time_limit，Auth_id、及び、S_levelが登録される。

コミュニティテーブルにおいて、idは、コミュニティテーブルのエントリを区別する識別情報（以下、コミュニティテーブルIDともいう）である。

コミュニティ生成部７３は、コミュニティテーブルに、新たなエントリを登録するときに、その新たなエントリに対して、コミュニティテーブルIDを付与する。図１０では、エントリごとにユニークな番号が、コミュニティテーブルのid（コミュニティテーブルID）として使用されている。

なお、コミュニティテーブルIDは、仮テーブルID及び認証テーブルIDとは、それぞれ、別個の、独立のIDである。

C_idは、そのエントリ（そのC_idが登録されるエントリ）のコミュニティデータによって管理されるコミュニティを区別する識別情報（以下、コミュニティIDともいう）であり、コミュニティ生成部７３は、コミュニティを生成するときに、そのコミュニティに対して、ユニークなコミュニティID(C_id)を付与する。

i_uidは、図８で説明した端末IDであり、コミュニティ生成部７３は、コミュニティID(C_id)が表すコミュニティに参加することができるユーザ（の携帯端末１１）に付与された端末ID（の一覧）を、コミュニティテーブルのi_uidとして登録する。

timeは、エントリが、コミュニティテーブルに登録された時刻（日時）を表す。

time_limitは、コミュニティに参加することを要求することができる制限時刻を表す。コミュニティ生成部７３は、例えば、コミュニティテーブルのエントリのtimeに、所定の時間を加算した時刻を、time_limitに登録する。

time_limitが表す時刻が経過した後に、仮テーブルに端末データが登録されたユーザについては、共通オブジェクトが、コミュニティに参加することが可能なユーザの共通オブジェクトと類似していても、そのコミュニティへの参加は、許可されない（ASNSサーバ１２から、端末ID及びコミュニティIDが提供されない）。

Auth_idは、図８で説明した認証IDであり、コミュニティ生成部７３は、コミュニティテーブルのコミュニティIDが表すコミュニティ（コミュニティIDによって特定されるコミュニティ）に参加可能なユーザに付与された認証IDを、コミュニティテーブルのAuth_idに登録する。

S_levelは、図８で説明したセキュリティレベルであり、コミュニティ生成部７３は、コミュニティテーブルのコミュニティIDが表すコミュニティに参加可能なユーザ（の携帯端末１１）から送信されてきた端末データに含まれるセキュリティレベルを、コミュニティテーブルのS_levelに登録する。

なお、コミュニティテーブルのコミュニティIDが表すコミュニティに参加可能なユーザ（以下、単に、参加ユーザともいう）から送信されてきた端末データに含まれるセキュリティレベルが一致している場合には、その一致しているセキュリティレベルが、コミュニティテーブルのS_levelに登録される。

参加ユーザから送信されてきた端末データに含まれるセキュリティレベルが一致していない場合には、参加ユーザから送信されてきた端末データに含まれるセキュリティレベルのうちの、例えば、最も厳しいセキュリティレベル（値が大きいレベル）が、コミュニティテーブルのS_levelに登録される。

［仮テーブル、認証テーブル、及び、コミュニティテーブルへのデータの登録］

図１１ないし図２１は、ASNSサーバ１２のコミュニティ生成部７３が行う、仮テーブル、認証テーブル、及び、コミュニティテーブルへのデータ（エントリ）の登録を説明する図である。

図１１は、仮テーブルを示す図である。

あるユーザU#1（の携帯端末１１）から、ASNSサーバ１２に、端末データが送信されてくると、コミュニティ生成部７３は、図１１に示すように、その端末データを送信してきたユーザU#1に、端末ID(i_uid)を付与し、ユーザU#1からの端末データについて、仮テーブルに、仮テーブルID(id)が、例えば、1のエントリを登録する。

ここで、以下、適宜、仮テーブルに登録された、仮テーブルID(id)が値kのエントリを、仮テーブルエントリ#kと記載する。

図１１では、ユーザU#1に対して、値が123の端末ID(i_uid)が付与されている。

その後、他のユーザU#2が、ASNSサーバ１２に、端末データを２回送信したとする。

この場合、コミュニティ生成部７３は、やはり、端末データを送信してきたユーザU#2に、端末ID(i_uid)を付与し、ユーザU#2からの２回分の端末データそれぞれについて、仮テーブルに、エントリを登録する。

図１１では、ユーザU#2からの２回分の端末データのうちの１回目の端末データについて、仮テーブルに、仮テーブルID(id)が2のエントリ（仮テーブルエントリ#2）が登録され、さらに、２回目の端末データについて、仮テーブルに、仮テーブルID(id)が3のエントリ（仮テーブルエントリ#3）が登録されている。

また、図１１では、ユーザU#2に対して、値が345の端末ID(i_uid)が付与されている。

仮テーブルエントリ#2及び#3は、いずれも、ユーザU#2からの端末データについて登録されたエントリであるため、そのi_uidは、いずれも、ユーザU#2に付与された値である345になっている。

また、図１１において、ユーザU#1は、写真の共通オブジェクトを含む端末データを送信したために、仮テーブルエントリ#1のAuth_typeは、写真を表す値である1になっている。

さらに、図１１において、ユーザU#2は、１回目の端末データには、写真の共通オブジェクトを含めて送信し、２回目の端末データには、音声の共通オブジェクトを含めて送信したために、仮テーブルエントリ#2のAuth_typeは、写真を表す値である1になっており、仮テーブルエントリ#3のAuth_typeは、音声を表す値である2になっている。

いま、ユーザU#1からの端末データに含まれる写真の共通オブジェクトと、ユーザU#2からの１回目の端末データに含まれる写真の共通オブジェクトとが類似しているとすると、コミュニティ生成部７３は、その類似する共通オブジェクトを送信してきたユーザU#1及びU#2がコミュニティに参加するための認証が成功したとして、類似している共通オブジェクトが含まれていたユーザU#1からの端末データについての仮テーブルエントリ#1と、ユーザU#2からの１回目の端末データについての仮テーブルエントリ#2に対し、同一の認証ID(Auth_id)を付与する。

図１２は、仮テーブルエントリ#1及び#2に、同一の認証IDが付与された後の仮テーブルを示す図である。

図１２では、値が321の認証ID(Auth_id)が、仮テーブルエントリ#1及び#2に付与されている。

なお、図１２では、ユーザU#2からの２回目の端末データに含まれる音声の共通オブジェクトに類似する共通オブジェクトのエントリは、仮テーブルに登録されていないため、ユーザU#2からの２回目の端末データについての仮テーブルエントリ#3には、認証ID(Auth_id)は、付与されていない。

その後、さらに他のユーザU#3が、ASNSサーバ１２に、端末データを送信したとする。

コミュニティ生成部７３は、端末データを送信してきたユーザU#3に、端末ID(i_uid)を付与し、ユーザU#3からの端末データについて、仮テーブルに、エントリを登録する。

図１３は、ユーザU#3からの端末データについてのエントリが登録された仮テーブルを示す図である。

図１３では、ユーザU#3からの端末データについて、仮テーブルに、仮テーブルID(id)が4のエントリ（仮テーブルエントリ#4）が登録されている。

また、図１３では、ユーザU#3に対して、値が678の端末ID(i_uid)が付与されている。

さらに、図１３において、ユーザU#3は、音声の共通オブジェクトを含む端末データを送信したために、仮テーブルエントリ#4のAuth_typeは、音声を表す値である2になっている。

いま、ユーザU#2からの２回目の端末データに含まれる音声の共通オブジェクトと、ユーザU#3からの端末データに含まれる音声の共通オブジェクトとが類似しているとすると、コミュニティ生成部７３は、その類似する共通オブジェクトを送信してきたユーザU#2及びU#3がコミュニティに参加するための認証が成功したとして、類似している共通オブジェクトが含まれていたユーザU#2からの２回目の端末データについての仮テーブルエントリ#3と、ユーザU#3からの端末データについての仮テーブルエントリ#4に対し、同一の認証ID(Auth_id)を付与する。

図１４は、仮テーブルエントリ#3及び#4に、同一の認証IDが付与された後の仮テーブルを示す図である。

図１４では、仮テーブルエントリ#1及び#2に付与された認証ID＝321とは異なる、値が333の認証ID(Auth_id)が、仮テーブルエントリ#3及び#4に付与されている。

ここで、図１４では、仮テーブルエントリ#1ないし#4のセキュリティレベル(S_level)は、すべて、レベル１になっている。

図８で説明したように、レベル１のセキュリティレベルでは、コミュニティに参加する複数のユーザ（の携帯端末１１）それぞれから送信されてくる共通オブジェクトが、異なる種類のオブジェクトであることが許可される。

したがって、レベル１のセキュリティレベルでは、例えば、写真を共通オブジェクトとして含む端末データを送信してきたユーザU#1及びU#2と、音声を共通オブジェクトとして含む端末データを送信してきたユーザU#2及びU#3のような、異なる種類の共通オブジェクトを送信してきたユーザU#1ないしU#3が、同一のコミュニティに参加することができる。

すなわち、コミュニティ生成部７３（図７）は、セキュリティレベルがレベル１になっている仮テーブルエントリに対する端末データを送信してきたユーザについては、異なる種類の複数の共通オブジェクトを送信してきたユーザが存在する場合には、その複数の共通オブジェクトのうちのいずれかの共通オブジェクトと類似する共通オブジェクト（を含む端末データ）を送信してきたユーザすべてに参加を許可するコミュニティを生成する。

図１４では、セキュリティレベルがレベル１になっている仮テーブルエントリ#1ないし#4に対する端末データを送信してきたユーザU#1ないしU#3のうちの、ユーザU#2が、異なる種類の複数の共通オブジェクトとしての写真と音声の共通オブジェクトを送信してきている。

そして、ユーザU#1が送信してきた写真の共通オブジェクトは、ユーザU#2が送信してきた写真の共通オブジェクトと類似し、ユーザU#3が送信してきた音声の共通オブジェクトは、ユーザU#2が送信してきた写真の共通オブジェクトと類似している。

この場合、コミュニティ生成部７３は、ユーザU#1ないしU#3すべてに参加を許可するコミュニティを生成する。

図１５は、ユーザU#1ないしU#3すべてに参加を許可するコミュニティを生成する場合の仮テーブル、認証テーブル、及び、コミュニティテーブルを示す図である。

図１５において、仮テーブルには、図１４と同様の仮テーブルエントリ#1ないし#4が登録されている。

仮テーブルにおいては、上述したように、仮テーブルエントリ#1及び#2には、値が321の認証IDが付与されているとともに、仮テーブルエントリ#3及び#4には、値が333の認証IDが付与されており、仮テーブルエントリ#1及び#2に付与されている認証IDと、仮テーブルエントリ#3及び#4に付与されている認証IDとは、異なっている。

コミュニティ生成部７３は、同一の認証IDが付与されている仮テーブルエントリに対応するエントリを、認証テーブルに登録する。

図１５では、値が321の認証IDが付与されている仮テーブルエントリ#1及び#2それぞれに対応するエントリが、認証テーブルに登録されている。

ここで、以下、適宜、認証テーブルに登録された、認証テーブルID(id)が値kのエントリを、認証テーブルエントリ#kと記載する。

図１５において、認証テーブルエントリ#1は、仮テーブルエントリ#1に対応し（仮テーブルエントリ#1のエントリデータについてのエントリであり）、認証テーブルエントリ#2は、仮テーブルエントリ#2に対応する。

コミュニティ生成部７３は、値が333の認証IDが付与されている仮テーブルエントリ#3及び#4それぞれに対応する認証テーブルエントリも、認証テーブルに登録するが、異なる認証IDが付与された仮テーブルエントリに、同一の端末ID(i_uid)が登録されている場合には、異なる認証IDが付与された仮テーブルエントリに対応する認証テーブルエントリを、認証IDを同一の値に統一して、認証テーブルに登録する。

図１５では、仮テーブルの、値が321の認証IDが付与されている仮テーブルエントリ#1及び#2のうちの仮テーブルエントリ#2と、値が333の認証IDが付与されている仮テーブルエントリ#3及び#4のうちの仮テーブルエントリ#3とに、同一の端末ID(i_uid)である値345が登録されている。

この場合、コミュニティ生成部７３は、異なる認証IDが付与されている仮テーブルエントリ、つまり、認証ID(Auth_id)が値321の仮テーブルエントリ#1及び#2と、認証ID(Auth_id)が値333の仮テーブルエントリ#3及び#4との認証IDを、例えば、最小の値（小さい方の値）である値321に統一し、統一後の認証IDが付与されている仮テーブルエントリ#1ないし#4に対応する認証テーブルエントリ#1ないし#4を、認証テーブルに登録する。

また、コミュニティ生成部７３は、認証テーブルに登録した認証テーブルエントリ#1ないし#4に対応する仮テーブルエントリ#1ないし#4を、仮テーブルから削除する。

図１０で説明したように、コミュニティ生成部７３は、認証テーブルに登録されたエントリの中に、同一の認証ID(Auth_id)が付与されたエントリがある場合、その同一の認証IDが付与されたエントリに登録されている端末ID(i_uid)によって特定される（携帯端末１１の）ユーザが参加可能なコミュニティを生成する。

すなわち、図１５では、認証テーブルエントリ#1ないし#4に、同一の値321の認証IDが付与されており、コミュニティ生成部７３は、認証テーブルエントリ#1に登録されている端末ID(i_uid)である値123によって特定されるユーザU#1、認証テーブルエントリ#2及び#3に登録されている端末ID(i_uid)である値345によって特定されるユーザU#2、及び、認証テーブルエントリ#4に登録されている端末ID(i_uid)である値678によって特定されるユーザU#3が参加可能なコミュニティとしての記憶領域を確保する。

さらに、コミュニティ生成部７３は、同一の値321の認証IDが付与された認証テーブルエントリ#1ないし#4に対応するエントリを、コミュニティテーブルに登録する。

すなわち、コミュニティ生成部７３は、同一の値321の認証IDが付与されたユーザU#1ないしU#3（同一の値321の認証IDが付与された認証テーブルエントリ#1ないし#4に登録されている端末ID(i_uid)によって特定されるユーザU#1ないしU#3）が参加可能なコミュニティに、コミュニティID(C_id)を付与し、そのコミュニティID(C_id)や、コミュニティに参加可能なユーザU#1ないしU#3の端末ID(i_uid)等を含むコミュニティデータのエントリを、コミュニティテーブルに登録する。

ここで、以下、適宜、コミュニティテーブルに登録された、コミュニティテーブルID(id)が値kのエントリを、コミュニティテーブルエントリ#kと記載する。

図１５では、同一の値321の認証IDが付与された認証テーブルエントリ#1ないし#4に対応するコミュニティテーブルエントリ、すなわち、ユーザU#1ないしU#3が参加可能なコミュニティを管理するためのコミュニティテーブルエントリとして、値10のコミュニティID(C_id)が付与され、ユーザU#1ないしU#3それぞれの端末IDである値123，345、及び、678を含むコミュニティテーブルエントリ#1が、コミュニティテーブルに登録されている。

コミュニティ処理部７４は、コミュニティテーブルエントリ#1を参照し、そのコミュニティテーブルエントリ#1に登録されているコミュニティID(C_id)＝10によって特定されるコミュニティについては、そのコミュニティテーブルエントリ#1に端末ID(i_uid)＝123，345，678が登録されているユーザU#1ないしU#3（の携帯端末１１）にのみ、アクセスを許可する。

以上のように、レベル１のセキュリティレベルでは、異なる種類の共通オブジェクトを送信してきたユーザU#1ないしU#3、すなわち、写真を共通オブジェクトとして含む端末データを送信してきたユーザU#1及びU#2と、音声を共通オブジェクトとして含む端末データを送信してきたユーザU#2及びU#3との全員が、同一のコミュニティに参加することができる。

ここで、例えば、ユーザU#1ないしU#3が、ある場所に集合し、コミュニティを生成するために、ユーザU#1が、携帯端末１１としての、例えば、カメラ付きの携帯電話機を用い、カメラで撮影した集合場所の風景の写真を共通オブジェクトとして含む端末データを、ASNSサーバ１２に送信し、ユーザU#2が、携帯端末１１としての、例えば、カメラ付きの携帯電話機を用い、カメラで撮影した集合場所の風景の写真を共通オブジェクトとして含む端末データを、ASNSサーバ１２に送信し、その後、所定の単語を発した音声を共通オブジェクトとして含む端末データを、ASNSサーバ１２に送信し、ユーザU#3が、携帯端末１１としての、例えば、カメラなしの携帯電話機を用い、所定の単語を発した音声を共通オブジェクトとして含む端末データを、ASNSサーバ１２に送信した場合に、図１１ないし図１５で説明したように、ユーザU#1ないしU#3が参加可能なコミュニティが生成される。

図１６は、仮テーブルを示す図である。

図１６の仮テーブルには、図１４の仮テーブルと同様の仮テーブルエントリ#1ないし#4が登録されている。

したがって、仮テーブルエントリ#1及び#2と、仮テーブルエントリ#3及び#4とのそれぞれの認証ID(Auth_id)は、異なっており、仮テーブルエントリ#1及び#2の認証ID(Auth_id)は、値321に、仮テーブルエントリ#3及び#4の認証ID(Auth_id)は、値333に、それぞれ、なっている。

但し、図１４では、仮テーブルエントリ#1ないし#4のセキュリティレベル(S_level)は、すべて、レベル１になっていたが、図１６では、仮テーブルエントリ#1ないし#4のセキュリティレベル(S_level)は、すべて、レベル２になっている。

図８で説明したように、レベル２のセキュリティレベルでは、コミュニティに参加する複数のユーザの携帯端末１１それぞれから送信されてくる共通オブジェクトが、同一の種類のオブジェクトであることが要求される。

すなわち、コミュニティ生成部７３（図７）は、セキュリティレベルがレベル２になっている仮テーブルエントリに対する端末データを送信してきたユーザについては、異なる種類の複数の共通オブジェクトを送信してきたユーザが存在する場合には、その複数の共通オブジェクトそれぞれについて、その共通オブジェクトと類似する共通オブジェクトを送信してきた携帯端末１１の端末数（端末数は、携帯端末１１のユーザのユーザ数でもあるので、以下、ユーザ数ともいう）をカウントし、そのユーザ数に基づく多数決により、ユーザ数が最も多い共通オブジェクトと類似する共通オブジェクトを送信してきた（携帯端末１１の）ユーザに参加を許可するコミュニティを生成する。

図１６では、セキュリティレベルがレベル２になっている仮テーブルエントリ#1ないし#4に対する端末データを送信してきたユーザU#1ないしU#3のうちの、ユーザU#2が、異なる種類の複数の共通オブジェクトとしての写真と音声の共通オブジェクトを送信してきている。

この場合、コミュニティ生成部７３は、ユーザU#2が送信してきた複数の共通オブジェクトである写真と音声の共通オブジェクトそれぞれについて、その共通オブジェクトと類似する共通オブジェクトを送信してきた（携帯端末１１の）ユーザのユーザ数をカウントする。

図１６では、ユーザU#1が送信してきた写真の共通オブジェクトは、ユーザU#2が送信してきた写真の共通オブジェクトと類似し、ユーザU#3が送信してきた音声の共通オブジェクトは、ユーザU#2が送信してきた写真の共通オブジェクトと類似している。

したがって、図１６では、ユーザU#2が送信してきた写真の共通オブジェクトと類似する共通オブジェクトを送信してきたユーザは、ユーザU#1の１人であり、ユーザU#2が送信してきた音声の共通オブジェクトと類似する共通オブジェクトを送信してきたユーザは、ユーザU#3の１人であるため、多数決による優劣をつけられないので、コミュニティ生成部７３は、この段階では、コミュニティを生成しない。

その後、ユーザU#1ないしU#3以外のユーザU#4が、ASNSサーバ１２に、端末データを送信したとする。

コミュニティ生成部７３は、端末データを送信してきたユーザU#4に、端末ID(i_uid)を付与し、ユーザU#4からの端末データについて、仮テーブルに、エントリを登録する。

図１７は、ユーザU#4からの端末データについてのエントリが登録された仮テーブルを示す図である。

図１７では、ユーザU#4からの端末データについて、仮テーブルに、仮テーブルID(id)が5のエントリ（仮テーブルエントリ#5）が登録されている。

また、図１７では、ユーザU#4に対して、値が900の端末ID(i_uid)が付与されている。

さらに、図１７において、ユーザU#4は、写真の共通オブジェクトを含む端末データを送信したために、仮テーブルエントリ#5のAuth_typeは、写真を表す値である1になっている。

また、仮テーブルエントリ#5のセキュリティレベル(S_level)は、他の仮テーブルエントリ#1ないし#4と同一のレベル２になっている。

いま、ユーザU#4からの端末データに含まれる写真の共通オブジェクトが、ユーザU#1やU#2からの端末データに含まれる写真の共通オブジェクトに類似しているとすると、コミュニティ生成部７３は、その類似する共通オブジェクトを送信してきたユーザU#4がコミュニティに参加するための認証が成功したこととして、ユーザU#4からの端末データについての仮テーブルエントリ#5に対して、そのユーザU#4からの端末データに含まれる写真の共通オブジェクトと類似する写真の共通オブジェクトが登録されている仮テーブルエントリ#1や#2と同一の認証ID(Auth_id)を付与する。

図１８は、仮テーブルエントリ#5に、仮テーブルエントリ#1及び#2と同一の認証IDが付与された後の仮テーブルを示す図である。

図１８では、仮テーブルエントリ#5に、仮テーブルエントリ#1及び#2と同一の認証IDが付与され、その結果、仮テーブルエントリ#1，#2、及び、#5の認証IDは、値321になっており、仮テーブルエントリ#3及び#4の認証IDは、値333になっている。

図１９は、ユーザ数に基づく多数決によるコミュニティの生成を説明する図である。

すなわち、図１９は、図１８と同様の仮テーブルエントリ#1ないし#5が登録されている仮テーブルを示している。

図１９では、複数の共通オブジェクトとしての写真と音声の共通オブジェクトを送信してきたユーザU#2（i_uidが345のユーザ）の、その複数の共通オブジェクトのうちの写真の共通オブジェクトと類似する共通オブジェクトを送信してきたユーザは、ユーザU#1及びU#4（i_uidが123のユーザと、900のユーザ）の２人であり、ユーザU#2の音声の共通オブジェクトと類似する共通オブジェクトを送信してきたユーザは、ユーザU#3（i_uidが678のユーザ）の１人であるため、写真の共通オブジェクトを送信してきたユーザと、音声の共通オブジェクトを送信してきたユーザとの多数決は、ユーザU#2を含めれば、３対２となる。

したがって、ユーザU#2が送信してきた複数の共通オブジェクトとしての写真と音声の共通オブジェクトについては、写真の共通オブジェクトの方が、音声の共通オブジェクトよりも、ユーザ数が多いため、コミュニティ生成部７３は、ユーザ数が多い写真の共通オブジェクトを送信してきたユーザに参加を許可するコミュニティを生成する。

すなわち、オブジェクト生成部７３は、ユーザ数の多数決の、いわば勝者である写真の共通オブジェクトを含む、ユーザU#1からの端末データについての仮テーブルエントリ#1、ユーザU#2からの１回目の端末データについての仮テーブルエントリ#2、及び、ユーザU#4からの端末データについての仮テーブルエントリ#5（図１９において、値が321の認証ID(Auth_id)が付与された仮テーブルエントリ）それぞれに対応する認証テーブルエントリを、認証テーブルに登録し、以下、図１５で説明した場合と同様にして、多数決の勝者である写真の共通オブジェクトを送信してきたユーザU#1，U#2、及び、U#4に参加を許可する（ユーザU#1，U#2、及び、U#4が参加可能な）コミュニティを生成する。

この、ユーザU#1，U#2、及び、U#4が参加可能なコミュニティには、多数決の勝者になった写真の共通オブジェクト（Auth_typeが値1の共通オブジェクト）を送信していないユーザ、すなわち、多数決の勝者にならなかった音声の共通オブジェクト（Auth_typeが値2の共通オブジェクト）しか送信していないユーザ#3（仮テーブルエントリ#4に対する端末データを送信してきたユーザ#3）は、参加することができない。

ユーザ#3が、ユーザU#1，U#2、及び、U#4が参加可能なコミュニティに参加するには、多数決の勝者になった写真の共通オブジェクト（に類似する写真の共通オブジェクト）を、ASNSサーバ１２に送信する必要がある。

このため、コミュニティ生成部７３では、多数決の勝者にならなかった音声の共通オブジェクト（Auth_typeが値2の共通オブジェクト）しか送信していないユーザ#3に対して、多数決の勝者である写真の共通オブジェクト（Auth_typeが値1の共通オブジェクト）を送信することを要求するメッセージを、通信部６１（図６）に送信させることができる。

以上のように、ASNSサーバ１２では、１つの携帯端末１１から異なる種類の複数の共通オブジェクトが送信されてきた場合に、その複数の共通オブジェクトそれぞれについて、その共通オブジェクトと類似する共通オブジェクトを送信してきた携帯端末１１の端末数（ユーザ数）をカウントし、その端末数が最も多い共通オブジェクトと類似する共通オブジェクトを送信してきた携帯端末１１のユーザに参加を許可するコミュニティを生成するので、すなわち、複数の種類の共通オブジェクトが送信されてきた場合に、互いに類似する数が最も多い種類の共通オブジェクトを送信してきたユーザに参加を許可するコミュニティを生成するので、利便性の高いコミュニティを、容易に生成することができる。

すなわち、コミュニティを生成しようとするユーザの多数決によって、そのコミュニティに参加する認証を行うための共通オブジェクトを決定することができるコミュニティを、容易に生成することができる。

また、ASNSサーバ１２では、セキュリティレベルに基づいて、コミュニティを生成するので、ユーザは、セキュリティレベルを指定するだけで、例えば、上述したように、複数（種類）の共通オブジェクトのうちのいずれかの共通オブジェクトと類似する共通オブジェクトを送信してきたユーザに参加を許可するコミュニティを生成することや、多数決によって、そのコミュニティに参加する認証を行うための共通オブジェクト（の種類）を決定することができるコミュニティを、容易に生成することができる。

図２０は、セキュリティレベル(S_level)がレベル１である場合の、コミュニティ生成部７３（図７）によるコミュニティの生成を説明する図である。

ここで、以下、適宜、端末ID(i_uid)として、値kが付与された（携帯端末１１の）ユーザを、以下、ユーザi_uid#kと記載する。

図２０Ａは、仮テーブルを示している。

図２０Ａの仮テーブルには、ユーザi_uid#123が送信してきた共通オブジェクトXxx-1を含む端末データについての仮テーブルエントリ#1、ユーザi_uid#345が送信してきた共通オブジェクトXxx-2を含む端末データについての仮テーブルエントリ#2、ユーザi_uid#345が送信してきた共通オブジェクト000を含む端末データについての仮テーブルエントリ#3、及び、ユーザi_uid#678が送信してきた共通オブジェクト001を含む端末データについての仮テーブルエントリ#4が登録されている。

したがって、図２０では、ユーザi_uid#345は、２つの共通オブジェクトXxx-2及び000を送信している。

また、図２０Ａの仮テーブルにおいて、共通オブジェクトXxx-1を含む仮テーブルエントリ#1のAuth_type、及び、共通オブジェクトXxx-2を含む仮テーブルエントリ#2のAuth_typeは、いずれも、写真を表す値１になっており、共通オブジェクト000を含む仮テーブルエントリ#3のAuth_type、及び、共通オブジェクト001を含む仮テーブルエントリ#4のAuth_typeは、いずれも、テキストを表す値５になっている。

したがって、共通オブジェクトXxx-1及びXxx-2は、写真（のオブジェクト）であり、共通オブジェクト000及び001は、テキストである。

また、共通オブジェクトXxx-1とXxx-2とは、類似しており、共通オブジェクト000と001とは、類似していることとする。

図２０Ａでは、仮テーブルエントリ#1ないし#4のセキュリティレベル(S_level)が、レベル１になっている。

さらに、図２０Ａでは、ユーザi_uid#345は、２つの共通オブジェクトXxx-2及び000、すなわち、写真の共通オブジェクトXxx-2と、テキストの共通オブジェクト000とを送信してきている。

そして、ユーザi_uid#123からの写真の共通オブジェクトXxx-1は、２つの共通オブジェクトXxx-2及び000を送信してきたユーザi_uid#345からの写真の共通オブジェクトXxx-2に類似し、ユーザi_uid#678からのテキストの共通オブジェクト001は、２つの共通オブジェクトXxx-2及び000を送信してきたユーザi_uid#345からのテキストの共通オブジェクト000に類似する。

この場合、レベル１のセキュリティレベルでは、図１５で説明したように、ユーザi_uid#123，i_uid#345、及び、i_uid#678に参加を許可するコミュニティが生成される。

図２０Ｂは、レベル１のセキュリティレベルで生成されるコミュニティに参加可能なユーザを説明する図である。

例えば、ユーザi_uid#123が、写真の共通オブジェクトXxx-1を、ASNSサーバ１２に送信し、ユーザi_uid#345が、共通オブジェクトXxx-1と類似する写真の共通オブジェクトXxx-2と、テキストの共通オブジェクト000との、２種類の共通オブジェクトを、ASNSサーバ１２に送信する。

さらに、例えば、ユーザi_uid#678が、共通オブジェクト000と類似するテキストの共通オブジェクト001を、ASNSサーバ１２に送信する。

この場合、ユーザi_uid#123の写真の共通オブジェクトXxx-1と、ユーザi_uid#678のテキストの共通オブジェクト001とは、種類（メディア）が異なるので、類似しない。

したがって、ASNSサーバ１２では、ユーザi_uid#123の写真の共通オブジェクトXxx-1と、ユーザi_uid#678のテキストの共通オブジェクト001だけでは、ユーザi_uid#123及びi_uid#678が参加可能なコミュニティは、生成されない。

但し、図２０では、ユーザi_uid#345が、ユーザi_uid#123の写真の共通オブジェクトXxx-1と類似する写真の共通オブジェクトXxx-2と、ユーザi_uid#678のテキストの共通オブジェクト001と類似するテキストの共通オブジェクト000との、２種類の共通オブジェクトを、ASNSサーバ１２に送信している。

この場合、ASNSサーバ１２では、図２０Ｂに示すように、互いに類似する写真の共通オブジェクトを送信してきたユーザi_uid#123とi_uid#345とがリンクされる（１つのグループにグルーピングされる）（同一の認証IDが付与される）。

さらに、ASNSサーバ１２では、図２０Ｂに示すように、互いに類似するテキストの共通オブジェクトを送信してきたユーザi_uid#345とi_uid#678とがリンクされる。

そして、レベル１のセキュリティレベルでは、写真の共通オブジェクトを送信してきたユーザi_uid#123と、テキストの共通オブジェクトを送信してきたユーザi_uid#678とが、図２０Ｂに示すように、共通のリンク先であるユーザi_uid#345を経由してリンクされる。

以上のようにして、ASNSサーバ１２では、ユーザi_uid#123，i_uid#345、及び、i_uid#678のすべてがリンクされ、これらのユーザi_uid#123，i_uid#345、及び、i_uid#678が参加可能なコミュニティが生成される。

図２１は、セキュリティレベル(S_level)がレベル２である場合の、コミュニティ生成部７３（図７）によるコミュニティの生成を説明する図である。

図２１Ａは、仮テーブルを示している。

図２１Ａの仮テーブルには、ユーザi_uid#123が送信してきた共通オブジェクトXxx-1を含む端末データについての仮テーブルエントリ#1、ユーザi_uid#345が送信してきた共通オブジェクトXxx-2を含む端末データについての仮テーブルエントリ#2、ユーザi_uid#345が送信してきた共通オブジェクト000を含む端末データについての仮テーブルエントリ#3、ユーザi_uid#678が送信してきた共通オブジェクト001を含む端末データについての仮テーブルエントリ#4、及び、ユーザi_uid#900が送信してきた共通オブジェクトXxx-3を含む端末データについての仮テーブルエントリ#5が登録されている。

図２１でも、図２０と同様に、ユーザi_uid#345は、２つの共通オブジェクトXxx-2及び000を送信している。

なお、図２１Ａの仮テーブルにおいて、共通オブジェクトXxx-1を含む仮テーブルエントリ#1のAuth_type、共通オブジェクトXxx-2を含む仮テーブルエントリ#2のAuth_type、及び、共通オブジェクトXxx-3を含む仮テーブルエントリ#5のAuth_typeは、いずれも、写真を表す値１になっており、共通オブジェクト000を含む仮テーブルエントリ#3のAuth_type、及び、共通オブジェクト001を含む仮テーブルエントリ#4のAuth_typeは、いずれも、テキストを表す値５になっている。

したがって、共通オブジェクトXxx-1，Xxx-2、及び、Xxx-3は、写真であり、共通オブジェクト000及び001は、テキストである。

また、共通オブジェクトXxx-1，Xxx-2、及び、Xxx-3は、互いに類似し、共通オブジェクト000と001とも、互いに類似していることとする。

図２１Ａでは、仮テーブルエントリ#1ないし#5のセキュリティレベル(S_level)が、レベル２になっている。

さらに、図２１Ａでは、ユーザi_uid#345は、２つの共通オブジェクトXxx-2及び000、すなわち、写真の共通オブジェクトXxx-2と、テキストの共通オブジェクト000とを送信してきている。

そして、ユーザi_uid#123からの写真の共通オブジェクトXxx-1は、２つの共通オブジェクトXxx-2及び000を送信してきたユーザi_uid#345からの写真の共通オブジェクトXxx-2に類似する。

また、ユーザi_uid#900からの写真の共通オブジェクトXxx-3は、２つの共通オブジェクトXxx-2及び000を送信してきたユーザi_uid#345からの写真の共通オブジェクトXxx-2に類似する。

さらに、ユーザi_uid#678からのテキストの共通オブジェクト001は、２つの共通オブジェクトXxx-2及び000を送信してきたユーザi_uid#345からのテキストの共通オブジェクト000に類似する。

したがって、２つの共通オブジェクトXxx-2及び000を送信してきたユーザi_uid#345からの写真の共通オブジェクトXxx-2に類似するのは、ユーザi_uid#123からの写真の共通オブジェクトXxx-1と、ユーザi_uid#900からの写真の共通オブジェクトXxx-3との、２つの共通オブジェクトである。

また、２つの共通オブジェクトXxx-2及び000を送信してきたユーザi_uid#345からのテキストの共通オブジェクト000に類似するのは、ユーザi_uid#678からのテキストの共通オブジェクト001の、１つの共通オブジェクトだけである。

この場合、２つの共通オブジェクトXxx-2及び000を送信してきたユーザi_uid#345からの写真の共通オブジェクトXxx-2と、テキストの共通オブジェクト000とでは、写真の共通オブジェクトXxx-2の方が、類似する共通オブジェクトが多いので、レベル２のセキュリティレベルでは、図１７ないし図１９で説明したように、多数決により、互いに類似する写真のオブジェクトを送信してきたユーザi_uid#123，i_uid#345、及び、i_uid#900に参加を許可するコミュニティが生成される。

図２１Ｂは、レベル２のセキュリティレベルで生成されるコミュニティに参加可能なユーザを説明する図である。

さらに、例えば、ユーザi_uid#678が、共通オブジェクト000と類似するテキストの共通オブジェクト001を、ASNSサーバ１２に送信し、ユーザi_uid#900が、共通オブジェクトXxx-1と類似する写真の共通オブジェクトXxx-3を、ASNSサーバ１２に送信する。

この場合、ASNSサーバ１２では、多数決によって、互いに類似する共通オブジェクトの数が多い、写真の共通オブジェクトを送信してきたユーザi_uid#123，i_uid#345、及び、i_uid#900が参加可能なコミュニティが生成される。

すなわち、レベル２のセキュリティレベルでは、図２１Ｂに示すように、互いに類似する写真の共通オブジェクトを送信してきたユーザi_uid#123，i_uid#345、及び、i_uid#900がリンクされる。

さらに、図２１Ｂに示すように、互いに類似するテキストの共通オブジェクトを送信してきたユーザi_uid#345とi_uid#678とがリンクされる。

但し、レベル２のセキュリティレベルでは、写真の共通オブジェクトのみを送信してきたユーザi_uid#123やi_uid#900と、テキストの共通オブジェクトのみを送信してきたユーザi_uid#678とは、図２１Ｂに示すように、共通のリンク先であるユーザi_uid#345が存在していても、そのユーザi_uid#345を経由してリンクされない。

そして、ASNSサーバ１２では、リンクされる数が多いユーザi_uid#123，i_uid#345、及び、i_uid#900が参加可能なコミュニティが生成される。

この場合、テキストの共通オブジェクト001しか送信していないユーザi_uid#678は、写真の共通オブジェクトXxx-1，Xxx-2、又は、Xxx-3と類似する写真の共通オブジェクトを送信しないと、ユーザi_uid#123，i_uid#345、及び、i_uid#678が参加可能なコミュニティに参加することはできない。

以上のように、レベル２のセキュリティレベルでは、多数決の勝者となった種類の共通オブジェクト（図２１では、写真の共通オブジェクト）を送信していないユーザは、その勝者となった種類の共通オブジェクトを送信してきたユーザが参加可能なコミュニティへの参加を制限される。

［仮テーブル登録処理］

図２２は、ASNSサーバ１２（図６）が、仮テーブルに仮テーブルエントリを登録する仮テーブル登録処理を説明するフローチャートである。

ASNSサーバ１２において、通信部６１は、携帯端末１１から端末データが送信されてくるのを待って、ステップＳ２１において、携帯端末１１からの端末データを受信することにより取得し、コミュニティ管理部６２（図７）のコミュニティ生成部７３に供給して、処理は、ステップＳ２２に進む。

ステップＳ２２では、コミュニティ生成部７３は、直前のステップＳ２１で受信した端末データを送信してきた（携帯端末１１の）ユーザに、端末ID(i_uid)を付与し、その端末IDと端末データとから、エントリデータを生成し、仮テーブル（図８）の仮テーブルエントリに登録して、処理は、ステップＳ２３に進む。

ステップ２３では、共通オブジェクト処理部７２が、仮テーブルの仮テーブルエントリに登録された共通オブジェクト（ユーザからの端末データに含まれていた共通オブジェクト）を処理する共通オブジェクト処理を行う。

そして、携帯端末１１から端末データがASNSサーバ１２に送信されてくるのを待って、処理は、ステップＳ２３からステップＳ２１に戻り、以下、同様の処理が繰り返される。

［共通オブジェクト処理］

図２３は、図２２のステップＳ２３で行われる共通オブジェクト処理の詳細を説明するフローチャートである。

ステップＳ４１において、共通オブジェクト処理部７２は、仮テーブル（図８）の最新の仮テーブルエントリのAuth_typeを参照して、最新の仮テーブルエントリの共通オブジェクト(obj)の種類が、GPSによる位置情報、テキスト、及び、バイナリデータのうちのいずれであるかを判定する。

ステップ４１において、最新の仮テーブルエントリの共通オブジェクト(obj)の種類が、テキストであると判定された場合、処理は、ステップＳ４７に進み、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)であるテキストそのものを、共通オブジェクトどうしが類似するかどうかの類似判定に用いるオブジェクト解析データとして、コミュニティ生成部７３に供給し、処理はリターンする。

また、ステップＳ４１において、最新の仮テーブルエントリの共通オブジェクト(obj)の種類が、GPSの位置情報であると判定された場合、処理は、ステップＳ４２に進み、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)である位置情報が、他の共通オブジェクトである位置情報と類似するということができる、類似判定の閾値である類似レンジを設定して、処理は、ステップＳ４７に進む。

この場合、ステップＳ４７では、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)である位置情報そのものを、共通オブジェクトどうしが類似するかどうかの類似判定に用いるオブジェクト解析データとして、コミュニティ生成部７３に供給するとともに、ステップＳ４２で設定した類似レンジを、コミュニティ生成部７３に供給し、処理はリターンする。

ここで、コミュニティ生成部７３（図７）では、後述するように、共通オブジェクトどうしが類似するかどうかの類似判定を行う。共通オブジェクトどうしが類似しているかどうかの類似判定は、例えば、共通オブジェクトどうしの距離（図２で説明した類似度の逆数等に相当する）が、所定の閾値以内であるかどうかによって行われる。

すなわち、共通オブジェクトどうしの距離が、所定の閾値以内であれば、類似していると判定され、所定の閾値以内でなければ、類似していないと判定される。

共通オブジェクトどうしの距離を求めるのに用いられるデータが、オブジェクト解析データであり、共通オブジェクトが、GPSの位置情報である、例えば、緯度と経度である場合には、その緯度と経度を用いて、距離を求めることができるので、その位置情報である緯度と経度が、そのまま、オブジェクト解析データとして使用される。

また、類似判定では、上述したように、共通オブジェクトどうしの距離が、所定の閾値以内であれば、類似していると判定されるが、その所定の閾値が、類似レンジであり、ステップＳ４２では、位置情報の共通オブジェクトどうしの類似判定に用いられる閾値である類似レンジが設定される。

なお、テキストの共通オブジェクトどうしの類似判定では、テキストの一字一句が一致している場合に、テキストの共通オブジェクトどうしが類似していると判定される。したがって、テキストの共通オブジェクトどうしの類似判定では、テキストの各文字が、オブジェクト解析データとして、距離の計算に用いられ、また、類似レンジはないので（0であるので）、ステップＳ４１において、最新の仮テーブルエントリの共通オブジェクト(obj)の種類が、テキストであると判定された場合、そのテキストの共通オブジェクトについては、オブジェクト解析データも、類似レンジも求められない（求める必要がない）。

ここで、類似レンジの設定では、例えば、共通オブジェクトの種類ごと（距離を求めるのに用いるオブジェクト解析データごと）に、あらかじめ決められた値等を、類似レンジに設定することができる。

ステップＳ４１において、最新の仮テーブルエントリの共通オブジェクト(obj)の種類が、バイナリデータであると判定された場合、処理は、ステップＳ４３に進み、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)であるバイナリデータが、写真、動画、及び、音声（音）のうちのいずれであるかを判定する。

ステップＳ４３において、最新の仮テーブルエントリの共通オブジェクト(obj)であるバイナリデータが、写真であると判定された場合、処理は、ステップＳ４４に進み、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)である写真を解析して、その写真としての画像の特徴量（ベクトル）を、オブジェクト解析データとして得るとともに、その写真の類似判定に用いる類似レンジを設定して、処理は、ステップＳ４５に進む。

ステップＳ４５では、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)である写真が、人の顔が映っている顔写真であるかどうかを判定する。

ステップＳ４５において、最新の仮テーブルエントリの共通オブジェクト(obj)である写真が、顔写真でないと判定された場合、処理は、ステップＳ４６をスキップして、ステップＳ４７に進み、共通オブジェクト処理部７２は、直前のステップＳ４４で得られたオブジェクト解析データと類似レンジを、コミュニティ生成部７３に供給し、処理はリターンする。

また、ステップＳ４５において、最新の仮テーブルエントリの共通オブジェクト(obj)である写真が、顔写真であると判定された場合、処理は、ステップＳ４６に進み、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)である顔写真を、顔の特徴量が得られる方法で解析することにより、その顔写真としての画像の特徴量を、オブジェクト解析データとして得るとともに、その顔写真の類似判定に用いる類似レンジを設定して、処理は、ステップＳ４７に進む。

この場合、ステップＳ４７では、共通オブジェクト処理部７２は、直前のステップＳ４６で得られたオブジェクト解析データと類似レンジを、コミュニティ生成部７３に供給し、共通オブジェクト処理はリターンする。

一方、ステップＳ４３において、最新の仮テーブルエントリの共通オブジェクト(obj)であるバイナリデータが、動画であると判定された場合、処理は、ステップＳ４８に進み、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)である動画に付随する音声（音）の波形を解析することにより、その音声の特徴量（ベクトル）を、オブジェクト解析データとして得るとともに、その音声の類似判定に用いる類似レンジを設定して、処理は、ステップＳ４９に進む。

ステップＳ４９では、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)である動画としての画像を解析して、その画像の特徴量を、オブジェクト解析データとして得るとともに、その画像の類似判定に用いる類似レンジを設定して、処理は、ステップＳ４７に進む。

この場合、ステップＳ４７では、共通オブジェクト処理部７２は、直前のステップＳ４８で得られた、動画に付随する音声についてのオブジェクト解析データ及び類似レンジと、直前のステップＳ４９で得られた、動画としての画像についてのオブジェクト解析データ及び類似レンジとを、コミュニティ生成部７３に供給し、処理はリターンする。

ここで、動画の共通オブジェクトどうしの類似判定では、動画に付随する音声についてのオブジェクト解析データどうしの距離（オブジェクト解析データから求められる距離）が、音声についての類似レンジ以下（類似レンジの範囲内）であり、かつ、動画としての画像についてのオブジェクト解析データどうしの距離が、画像についての類似レンジ以下である場合に、類似していると判定される。

ステップＳ４３において、最新の仮テーブルエントリの共通オブジェクト(obj)であるバイナリデータが、音声（音）であると判定された場合、処理は、ステップＳ５０に進み、共通オブジェクト処理部７２は、最新の仮テーブルエントリの共通オブジェクト(obj)である音声の波形を解析することにより、その音声の特徴量を、オブジェクト解析データとして得るとともに、その音声の類似判定に用いる類似レンジを設定して、処理は、ステップＳ４７に進む。

この場合、ステップＳ４７では、共通オブジェクト処理部７２は、直前のステップＳ５０で得られた、音声のオブジェクト解析データ及び類似レンジを、コミュニティ生成部７３に供給し、共通オブジェクト処理はリターンする。

［認証ID付与処理］

図２４は、コミュニティ生成部７３（図７）が、仮テーブルのエントリのうちの、認証ID(Auth_id)が付与されていないエントリに、認証ID(Auth_id)を付与する認証ID付与処理を説明するフローチャートである。

ステップＳ６１において、コミュニティ生成部７３は、仮テーブル（図８）から、認証ID(Auth_id)が付与されていないエントリの１つを、注目する注目エントリに選択して，処理は、ステップＳ６２に進む。

ステップＳ６２では、コミュニティ生成部７３は、仮テーブル（図８）から、注目エントリ以外のエントリであって、まだ、注目エントリに対して比較対象エントリに選択されていないエントリの１つを、注目エントリと共通オブジェクトを比較する比較対象の比較対象エントリに選択して、処理は、ステップＳ６３に進む。

ステップＳ６３では、コミュニティ生成部７３は、注目エントリの共通オブジェクトと、比較対象エントリの共通オブジェクトとの類似度としての距離を、注目エントリの共通オブジェクトから得られたオブジェクト解析データと、比較対象エントリの共通オブジェクトから得られたオブジェクト解析データとを用いて算出し、処理は、ステップＳ６４に進む。

ステップＳ６４では、コミュニティ生成部７３は、注目エントリの共通オブジェクトと、比較対象エントリの共通オブジェクトとの類似度としての距離に基づいて、注目エントリの共通オブジェクトと、比較対象エントリの共通オブジェクトとが類似するかどうかを判定する。

ステップＳ６４において、注目エントリの共通オブジェクトと、比較対象エントリの共通オブジェクトとが類似しないと判定された場合、処理は、ステップＳ６５に進み、コミュニティ生成部７３は、仮テーブルの、注目エントリ以外のエントリのすべてを、比較対象エントリに選択したかどうかを判定する。

ステップＳ６５において、仮テーブルの、注目エントリ以外のエントリの中に、まだ、比較対象エントリに選択していないエントリがあると判定された場合、処理は、ステップＳ６２に戻り、以下、同様の処理が繰り返される。

また、ステップＳ６５において、仮テーブルの、注目エントリ以外のエントリのすべてを、比較対象エントリに選択したと判定された場合、処理は、ステップＳ６１に戻り、以下、同様の処理が繰り返される。

一方、ステップＳ６４において、注目エントリの共通オブジェクトと、比較対象エントリの共通オブジェクトとが類似すると判定された場合、すなわち、注目エントリの共通オブジェクトと、比較対象エントリの共通オブジェクトとの類似度としての距離が、注目エントリの共通オブジェクトについて設定された類似レンジ（図２３）以下である場合、処理は、ステップＳ６６に進み、コミュニティ生成部７３は、仮テーブル（図８）の比較対象エントリに、認証ID(Auth_id)が、既に付与されているかどうかを判定する。

ステップＳ６６において、比較対象エントリに、認証ID(Auth_id)が、既に付与されていると判定された場合、処理は、ステップＳ６７に進み、コミュニティ生成部７３は、仮テーブルの注目エントリに、比較対象エントリに付与されている認証ID(Auth_id)と同一の認証ID(Auth_id)を付与して、処理は、ステップＳ６１に戻る。

また、ステップＳ６６において、比較対象エントリに、認証ID(Auth_id)が付与されていないと判定された場合、処理は、ステップＳ６８に進み、コミュニティ生成部７３は、仮テーブルにないユニークな認証ID(Auth_id)を生成（発行）し、その認証ID(Auth_id)を、仮テーブルの注目エントリ、及び、比較対象エントリに付与して、処理は、ステップＳ６１に戻る。

以上のように、認証ID付与処理では、仮テーブルにおいて、認証ID(Auth_id)が付与されていないエントリと共通オブジェクトが類似する他のエントリが存在する場合には、その、認証ID(Auth_id)が付与されていないエントリに、認証ID(Auth_id)が付与される。

認証ID(Auth_id)の付与では、認証ID(Auth_id)が付与されていないエントリと共通オブジェクトが類似する他のエントリに、既に、認証ID(Auth_id)が付与されている場合には、その認証ID(Auth_id)と同一の認証ID(Auth_id)が、認証ID(Auth_id)が付与されていないエントリに付与される。

一方、認証ID(Auth_id)が付与されていないエントリと共通オブジェクトが類似する他のエントリに、まだ、認証ID(Auth_id)が付与されている場合には、認証ID(Auth_id)が付与されていないエントリと、そのエントリと共通オブジェクトが類似する他のエントリには、新たに発行されたユニークな認証ID(Auth_id)が付与される。

［コミュニティ生成処理］

図２５は、コミュニティ生成部７３（図７）が、仮テーブルを参照して、コミュニティを生成するコミュニティ生成処理を説明するフローチャートである。

ステップＳ８１において、コミュニティ生成部７３は、仮テーブル（図８）に登録されてから、所定の時間（以上）が経過しているエントリの１つを、注目エントリに選択して、処理は、ステップＳ８２に進む。

ステップＳ８２では、コミュニティ生成部７３は、注目エントリに、認証ID(Auth_id)が付与されているかどうかを判定する。

ステップＳ８２において、注目エントリに、認証ID(Auth_id)が付与されていないと判定された場合、処理は、ステップＳ８３に進み、コミュニティ生成部７３は、仮テーブルから、注目エントリを削除して、処理は、ステップＳ８１に戻る。

ここで、いまの場合、注目エントリは、仮テーブルに登録されてから、少なくとも所定の時間が経過しているエントリであるから、注目エントリに、認証ID付与処理（図２４）で付与される認証ID(Auth_id)が付与されていないということは、注目エントリが仮テーブルに登録された時刻の前後の所定の時間の間に、注目エントリの共通オブジェクトと類似する共通オブジェクト（を含む端末データ）が、ASNSサーバ１２に送信されてきていないことになり、注目エントリの共通オブジェクトを送信してきたユーザとともに参加可能なコミュニティに参加しようとする他のユーザが存在しない蓋然性が高い。

そこで、コミュニティ生成部７３は、注目エントリに、認証ID(Auth_id)が付与されていない場合には、上述のように、ステップＳ８３で、注目エントリを、仮テーブルから削除する。

一方、ステップＳ８２において、注目エントリに、認証ID(Auth_id)が付与されていると判定された場合、すなわち、仮テーブル(図８）に、注目エントリの共通オブジェクトと類似する共通オブジェクトが登録された他のエントリが存在する場合、処理は、ステップＳ８４に進み、コミュニティ生成部７３は、認証ID(Auth_id)が付与されている注目エントリに対応する認証テーブルエントリや、注目エントリの共通オブジェクトと類似する共通オブジェクトが登録された仮テーブルエントリに対応する認証テーブルエントリ等を、認証テーブル（図９）（図１５）に登録するセキュリティ処理を行って、処理は、ステップＳ８５に進む。ここで、セキュリティ処理の詳細については、後述する。

ステップＳ８５では、コミュニティ生成部７３は、認証テーブルに、仮テーブルの注目エントリに付与されている認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている認証テーブルエントリがあるかどうかを判定する。

ステップＳ８５において、仮テーブルの注目エントリに付与されている認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている認証テーブルエントリが、認証テーブルにないと判定された場合、処理は、ステップＳ８１に戻る。

また、ステップＳ８５において、仮テーブルの注目エントリに付与されている認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている認証テーブルエントリが、認証テーブルにあると判定された場合、処理は、ステップＳ８６に進み、コミュニティ生成部７３は、仮テーブルの注目エントリに付与されている認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている認証テーブルエントリ（以下、同一認証IDエントリともいう）を、認証テーブル（図９）から検出する。

そして、コミュニティ生成部７３は、同一認証IDエントリに登録されている端末ID(i_uid)によって特定される（携帯端末１１の）ユーザが参加可能なコミュニティを生成する。

すなわち、コミュニティ生成部７３は、同一認証IDエントリに登録されている端末ID(i_uid)によって特定されるユーザ（以下、許可ユーザともいう）が参加可能なコミュニティとしての記憶領域を確保するとともに、そのコミュニティに、コミュニティID(C_id)を付与する。

さらに、コミュニティ生成部７３は、コミュニティに付与したコミュニティID(C_id)や、同一認証IDエントリに登録されている許可ユーザの端末ID(i_uid)等を含むコミュニティデータのエントリを、コミュニティテーブル（図１０）（図１５）に登録して、処理は、ステップＳ８５からステップＳ８６に進む。

ステップＳ８６では、コミュニティ生成部７３は、仮テーブルから、注目エントリ、及び、注目エントリの認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている仮テーブルエントリを削除し、処理は、ステップＳ８７に進む。

ステップＳ８７では、コミュニティ生成部７３は、許可ユーザの携帯端末１１に対して、その許可ユーザの端末ID(i_uid)と、許可ユーザが参加可能なコミュニティのコミュニティID(C_id)を、通信部６１に送信させ、処理は、ステップＳ８１に戻る。

以上のようにして、コミュニティ生成部７３から送信される端末ID(i_uid)とコミュニティID(C_id)とを受信した携帯端末１１（のユーザ）は、コミュニティID(C_id)によって特定されるコミュニティに参加することができる。

［セキュリティ処理］

図２５のステップＳ８４で行われるセキュリティ処理は、セキュリティレベル(S_level)によって、処理内容が異なる。

図２６は、セキュリティレベル(S_level)がレベル１である場合（コミュニティテーブルのセキュリティレベル(S_level)に、レベル１が登録される場合）のセキュリティ処理を説明するフローチャートである。

ステップＳ１０１において、コミュニティ生成部７３は、仮テーブル（図１５）において、注目エントリの認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている仮テーブルエントリ（以下、認証ID直接一致エントリともいう）を検出し、処理は、ステップＳ１０２に進む。

ステップＳ１０２では、コミュニティ生成部７３は、仮テーブルにおいて、注目エントリの認証ID(Auth_id)と異なる認証ID(Auth_id)が付与されているエントリの中に、認証ID直接一致エントリの端末ID(i_uid)と同一の端末ID(i_uid)が登録されているエントリ、つまり、認証ID(Auth_id)が注目エントリとは異なるが、端末ID(i_uid)が認証ID直接一致エントリ（のいずれか）と同一の仮テーブルエントリ（以下、認証ID不一致／端末ID一致エントリ）があるかどうかを判定する。

ここで、例えば、いま、注目エントリが、図１５の仮テーブルエントリ#1であるとすると、図１５の仮テーブルエントリ#2が、注目エントリの認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている認証ID直接一致エントリとなる。

また、図１５において、仮テーブルエントリ#2と端末IDが一致する仮テーブルエントリ#3が、認証ID(Auth_id)が注目エントリである仮テーブルエントリ#1とは異なるが、端末ID(i_uid)が認証ID直接一致エントリである仮テーブルエントリ#2と同一の認証ID不一致／端末ID一致エントリとなる。

したがって、認証ID不一致／端末ID一致エントリと、認証ID直接一致エントリとは、同一のユーザからの端末データについての仮テーブルエントリであるが、登録されている共通オブジェクト（の種類）が異なる仮テーブルエントリである。

ステップＳ１０２において、仮テーブルに、認証ID不一致／端末ID一致エントリがないと判定された場合、処理は、ステップＳ１０３に進み、コミュニティ生成部７３は、ステップＳ１０１で検出した認証ID直接一致エントリに対応する認証テーブルエントリを、認証テーブル（図１５）に登録して、処理はリターンする。

また、ステップＳ１０２において、仮テーブルに、認証ID不一致／端末ID一致エントリがあると判定された場合、処理は、ステップＳ１０４に進み、コミュニティ生成部７３は、仮テーブルにおいて、認証ID不一致／端末ID一致エントリと同一の認証ID(Auth_id)が付与されている仮テーブルエントリ（以下、認証ID間接一致エントリともいう）を検出し、処理は、ステップＳ１０５に進む。

ここで、例えば、いま、注目エントリが、図１５の仮テーブルエントリ#1であるとすると、図１５の仮テーブルエントリ#4が、認証ID不一致／端末ID一致エントリである仮テーブルエントリ#3と同一の認証ID(Auth_id)が付与されている認証ID間接一致エントリとなる。

ステップＳ１０５では、コミュニティ生成部７３は、ステップＳ１０１で検出した認証ID直接一致エントリ、及び、ステップＳ１０４で検出した認証ID間接一致エントリそれぞれに対応する認証テーブルエントリを、認証テーブル（図１５）に登録する。

さらに、ステップＳ１０５では、コミュニティ生成部７３は、認証テーブルの、認証ID直接一致エントリ、及び、認証ID間接一致エントリそれぞれに対応する認証テーブルエントリの認証ID(Auth_id)を、例えば、仮テーブルの注目エントリの認証ID(Auth_id)等の同一の値に統一して、処理はリターンする。

セキュリティレベル(S_level)がレベル１である場合には、以上のようなセキュリティ処理が行われることにより、図１５や図２０で説明したように、異なる種類の共通オブジェクトを送信してきたユーザどうしであっても参加しうるコミュニティが生成される。

図２７は、セキュリティレベル(S_level)がレベル２である場合（コミュニティテーブルのセキュリティレベル(S_level)に、レベル２が登録される場合）のセキュリティ処理を説明するフローチャートである。

ステップＳ１１１において、コミュニティ生成部７３は、仮テーブル（図１８）において、注目エントリの認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている仮テーブルエントリ（認証ID直接一致エントリ）を検出し、処理は、ステップＳ１１２に進む。

ステップＳ１１２では、コミュニティ生成部７３は、仮テーブルにおいて、注目エントリの認証ID(Auth_id)と異なる認証ID(Auth_id)が付与されているエントリの中に、認証ID直接一致エントリの端末ID(i_uid)と同一の端末ID(i_uid)が登録されているエントリ、つまり、認証ID(Auth_id)が注目エントリとは異なるが、端末ID(i_uid)が認証ID直接一致エントリ（のいずれか）と同一の仮テーブルエントリ（認証ID不一致／端末ID一致エントリ）があるかどうかを判定する。

ここで、例えば、いま、注目エントリが、図１８の仮テーブルエントリ#1であるとすると、図１５の仮テーブルエントリ#2及び#5が、注目エントリの認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている認証ID直接一致エントリとなる。

また、図１５において、認証ID直接一致エントリである仮テーブルエントリ#2と端末IDが一致するが、認証ID(Auth_id)が一致していない仮テーブルエントリ#3が、認証ID不一致／端末ID一致エントリとなる。

図２６で説明したように、認証ID不一致／端末ID一致エントリと、認証ID直接一致エントリとは、同一のユーザからの端末データについての仮テーブルエントリであるが、登録されている共通オブジェクト（の種類）が異なる仮テーブルエントリである。

ステップＳ１１２において、仮テーブルに、認証ID不一致／端末ID一致エントリがないと判定された場合、処理は、ステップＳ１１３ないしＳ１１５をスキップして、ステップＳ１１６に進み、コミュニティ生成部７３は、ステップＳ１１１で検出した認証ID直接一致エントリに対応する認証テーブルエントリを、認証テーブル（図９）に登録して、処理はリターンする。

以上のように、仮テーブルに、認証ID不一致／端末ID一致エントリがない場合には、認証ID直接一致エントリに対応する認証テーブルエントリだけが、認証テーブル（図９）に登録される。したがって、認証ID直接一致エントリ、つまり、注目エントリの認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている仮テーブルエントリの端末ID(i_uid)によって特定されるユーザが参加可能なコミュニティが生成される。

また、ステップＳ１１２において、仮テーブルに、認証ID不一致／端末ID一致エントリがあると判定された場合、処理は、ステップＳ１１３に進み、コミュニティ生成部７３は、仮テーブルにおいて、認証ID不一致／端末ID一致エントリと同一の認証ID(Auth_id)が付与されている仮テーブルエントリのエントリ数をカウントするとともに、認証ID直接一致エントリのエントリ数をカウントして、処理は、ステップＳ１１４に進む。

ここで、ステップＳ１１３において、仮テーブルにおいて、認証ID不一致／端末ID一致エントリと同一の認証ID(Auth_id)が付与されている仮テーブルエントリのエントリ数のカウントは、認証ID(Auth_id)ごとに行われる。

すなわち、認証ID不一致／端末ID一致エントリは、注目エントリの認証ID(Auth_id)と異なる認証ID(Auth_id)が付与されている仮テーブルエントリであり、仮テーブルに、複数の認証ID不一致／端末ID一致エントリが存在する場合に、その複数の認証ID不一致／端末ID一致エントリのすべての認証ID(Auth_id)が一致しているとは限らない。

ステップＳ１１３の認証ID不一致／端末ID一致エントリのカウントは、同一の認証ID(Auth_id)が付与されている認証ID不一致／端末ID一致エントリのエントリ数を調べるのに行われるため、（同一の）認証ID(Auth_id)ごとに行われる。

ステップＳ１１４では、コミュニティ生成部７３は、ステップＳ１１３でのエントリ数のカウント結果を比較することにより、認証ID不一致／端末ID一致エントリと同一の認証ID(Auth_id)が付与されている仮テーブルエントリと、認証ID直接一致エントリとの中で、認証ID直接一致エントリのエントリ数が最も多いかどうかを判定する。

ステップＳ１１４において、認証ID不一致／端末ID一致エントリと同一の認証ID(Auth_id)が付与されている仮テーブルエントリと、認証ID直接一致エントリとの中で、認証ID不一致／端末ID一致エントリと同一の認証ID(Auth_id)が付与されている仮テーブルエントリのエントリ数が最も多いと判定された場合、すなわち、認証ID直接一致エントリの共通オブジェクトが、多数決の勝者ではない場合、処理は、ステップＳ１１５及びＳ１１６をスキップして、リターンする。

以上のように、認証ID直接一致エントリの共通オブジェクトが、多数決の勝者ではない場合には、認証テーブルへの認証テーブルエントリの登録が行われないので、認証ID直接一致エントリ、つまり、注目エントリの認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている仮テーブルエントリの端末ID(i_uid)によって特定されるユーザが参加可能なコミュニティは、生成されない。

一方、ステップＳ１１４において、認証ID不一致／端末ID一致エントリと同一の認証ID(Auth_id)が付与されている仮テーブルエントリと、認証ID直接一致エントリとの中で、認証ID直接一致エントリのエントリ数が最も多いと判定された場合、すなわち、認証ID直接一致エントリの共通オブジェクトが、多数決の勝者である場合、処理は、ステップＳ１１５に進み、コミュニティ生成部７３は、認証ID不一致／端末ID一致エントリと同一の認証ID(Auth_id)が付与されている仮テーブルエントリの端末ID(i_uid)によって特定されるユーザ（多数決の勝者になった共通オブジェクトと異なる種類の共通オブジェクトを送信してきたユーザ）の携帯端末１１に対して、コミュニティに参加するためには、認証ID直接一致エントリのAuth_typeが表す種類の共通オブジェクト、つまり、多数決の勝者になった共通オブジェクトと同一の種類の共通オブジェクトを送信することが必要である旨のメッセージ（多数決の勝者になった共通オブジェクトと同一の種類の共通オブジェクトを要求するメッセージ)を送信して、処理は、ステップＳ１１６に進む。

ステップＳ１１６では、コミュニティ生成部７３は、多数決の勝者となった種類の共通オブジェクトを有する認証ID直接一致エントリに対応する認証テーブルエントリを、認証テーブル（図９）に登録して、処理はリターンする。

以上のように、認証ID直接一致エントリの共通オブジェクト（の種類）が多数決の勝者である場合には、その勝者になった種類の共通オブジェクトを有する認証ID直接一致エントリに対応する認証テーブルエントリだけが、認証テーブル（図９）に登録される。したがって、認証ID直接一致エントリ、つまり、注目エントリの認証ID(Auth_id)と同一の認証ID(Auth_id)が付与されている仮テーブルエントリの端末ID(i_uid)によって特定されるユーザが参加可能なコミュニティが生成される。

セキュリティレベル(S_level)がレベル２である場合には、以上のようなセキュリティ処理が行われることにより、図１９や図２１で説明したように、多数決の勝者となった種類の共通オブジェクト、すなわち、互いに類似する数が最も多い種類の共通オブジェクトを送信してきたユーザに参加を許可するコミュニティが生成される。

［コミュニティ提供システムの処理］

図２８は、図１のコミュニティ提供システムがコミュニティを提供する処理を説明する図である。

ここで、以下、適宜、あるユーザＡの携帯端末１１を、端末Ａとも記述し、ユーザＡと異なるユーザＢの携帯端末１１を、端末Ｂとも記述する。

ユーザＡ及びＢは、お互いが参加するコミュニティを生成しようとする場合、それぞれ、互いに類似する共通オブジェクトを取得し、端末データに含めて送信するように、端末Ａ及びＢを操作する。

端末Ａは、ステップＳ１３１において、ユーザＡの操作に従った端末データを、コミュニティの生成の要請として、ASNSサーバ１２に送信する。

ASNSサーバ１２では、コミュニティ管理部６２（図６）が、端末Ａからの端末データを受信し、ステップＳ１３２において、端末Ａからの端末データについての仮テーブルエントリを、仮登録DB６４（図６）の仮テーブル（図８）に登録する仮テーブル登録処理（図２２）を行う。

さらに、ASNSサーバ１２では、ステップＳ１３３において、コミュニティ管理部６２が、仮登録DB６４の仮テーブルの仮テーブルエントリに、認証IDを付与する認証ID付与処理（図２４）を行う。

なお、ステップＳ１３３において、認証ID付与処理が行われるときには、まだ、ユーザＡ（端末Ａ）からの端末データに含まれる共通オブジェクトと類似する共通オブジェクトを有する仮テーブルエントリが、仮テーブルに登録されておらず、そのため、この時点では、まだ、ユーザＡからの端末データについての仮テーブルエントリには、認証IDは、付与されない。

一方、端末Ｂは、ステップＳ１３４において、ユーザＢの操作に従って、ユーザＡの端末データに含まれる共通オブジェクトと類似する共通オブジェクトを含む端末データを、コミュニティの生成の要請として、ASNSサーバ１２に送信する。

ASNSサーバ１２では、コミュニティ管理部６２が、端末Ｂからの端末データを受信し、ステップＳ１３５において、端末Ｂからの端末データについての仮テーブルエントリを、仮登録DB６４の仮テーブルに登録する仮テーブル登録処理（図２２）を行う。

さらに、ASNSサーバ１２では、ステップＳ１３６において、コミュニティ管理部６２が、仮登録DB６４の仮テーブルの仮テーブルエントリに、認証IDを付与する認証ID付与処理（図２４）を行う。

ステップＳ１３６において、認証ID付与処理が行われるときには、ユーザＡからの端末データについての仮テーブルエントリ（以下、仮テーブルエントリＡともいう）と、ユーザＢからの端末データについての仮テーブルエントリ（以下、仮テーブルエントリＢともいう）とが、仮テーブルに登録されている。

そして、仮テーブルエントリＡの共通オブジェクトと、仮テーブルエントリＢの共通オブジェクトとは、互いに類似するので、仮テーブルエントリＡ及びＢには、同一の認証ID(Auth_id)が付与される。

その後、ステップＳ１３７では、コミュニティ管理部６２が、同一の認証IDが付与されている仮テーブルエントリに登録されている端末IDによって特定されるユーザが参加可能なコミュニティを生成するコミュニティ生成処理（図２５）において、仮テーブルから、同一の認証IDが付与された仮テーブルエントリＡ及びＢを検出する。

ステップＳ１３８では、コミュニティ管理部６２は、コミュニティ生成処理(図２５）において、コミュニティDB６５（図６）の認証テーブル（図９）に、仮テーブルから検出した、同一の認証IDが付与された仮テーブルエントリＡ及びＢそれぞれに対応する認証テーブルエントリＡ及びＢを登録する。

さらに、コミュニティ管理部６２は、コミュニティ生成処理(図２５）において、コミュニティDB６５の認証テーブルに登録した認証テーブルエントリＡ及びＢに登録されている端末ID(i_uid)によって特定されるユーザＡ及びＢが参加可能なコミュニティを生成する。

すなわち、コミュニティ管理部６２は、ユーザＡ及びＢが参加可能なコミュニティとしての記憶領域を確保するとともに、そのコミュニティに、コミュニティID(C_id)を付与し、そのコミュニティを管理するための、コミュニティID(C_id)等を含むコミュニティデータのエントリを、コミュニティDB６５のコミュニティテーブル（図１０）に登録する。

ステップＳ１３９では、コミュニティ管理部６２は、コミュニティDB６５のコミュニティテーブルから、ユーザＡ及びＢが参加可能なコミュニティのコミュニティID(C_id)と、ユーザＡ及びＢの端末ID(i_uid)とを取得する。

ステップＳ１４０では、コミュニティ管理部６２は、端末Ａに、ユーザＡの端末IDとコミュニティIDを送信するとともに、端末Ｂに、ユーザＢの端末IDとコミュニティIDを送信する。

端末Ａ及びＢは、それぞれ、コミュニティ管理部６２からの端末IDとコミュニティIDを受信する。そして、ユーザＡ及びＢは、それぞれ、端末IDとコミュニティIDを受信した端末Ａ及びＢを操作することにより、コミュニティIDで特定されるコミュニティを介して、コンテンツのダウンロードやアップロード、メッセージのやりとり等を行うことができる。

［コミュニティへの途中参加］

図１のコミュニティ提供システムによれば、空間及び時間を共有している複数のユーザは、互いに類似するオブジェクトを含む端末データを、同じようなタイミングで、ASNSサーバ１２に送信することにより、その複数のユーザが参加可能なコミュニティに参加することができる。

ところで、コミュニティテーブルのエントリには、図１０で説明したように、time_limitが登録され、そのtime_limitが表す時刻が経過した後は、そのときにコミュニティに参加していないユーザのコミュニティの参加は、制限される。

すなわち、コミュニティのtime_limitが表す時刻が経過した後に、そのコミュニティに参加していないユーザである未参加ユーザが、コミュニティに既に参加している参加済みユーザが送信してきた共通オブジェクトと類似する共通オブジェクトを送信してきても、未参加ユーザが、コミュニティに参加することは、許可されない（ASNSサーバ１２から、端末ID及びコミュニティIDが提供されない）。

しかしながら、既に存在する（生成された）コミュニティへの、後からのユーザの参加を一切認めないのは、コミュニティの利便性に欠けるおそれがある。

一方、既に存在するコミュニティへの、後からのユーザの参加を無制限に許すことは、コミュニティのセキュリティ上問題が生じるおそれがある。

そこで、図１のコミュニティ提供システムでは、一定の制限の下で、既に存在するコミュニティに、後から、ユーザが参加すること（以下、途中参加ともいう）が可能になっている。

コミュニティへの途中参加の方法としては、コミュニティテーブル（図１０）のtime_limitを変更する第１の途中参加方法と、文字の羅列であるトークンを用いる第２の途中参加方法とがある。

まず、第１の途中参加方法について説明する。

ここで、以下、適宜、既に存在するコミュニティに、既に参加している参加済みユーザの携帯端末１１を、参加済み端末ともいい、既に存在するコミュニティに参加していない未参加ユーザであって、そのコミュニティへの途中参加を希望している参加希望ユーザの携帯端末１１を、参加希望端末ともいう。

図２９は、参加希望ユーザが、第１の途中参加方法により、コミュニティに途中参加する場合の携帯端末１１の処理を説明するフローチャートである。

コミュニティに途中参加しようとする参加希望ユーザは、空間及び時間を共有している参加済みユーザに、途中参加を希望する旨を伝える。

参加済みユーザは、参加希望ユーザの途中参加を了承する場合、コミュニティに参加するユーザの追加を要求するユーザ追加リクエストを送信するように、参加済み端末としての携帯端末１１を操作する（例えば、参加済み端末に設けられた、途中参加を要求するボタンを操作する）。

参加済み端末は、ステップＳ２０１において、参加済みユーザの操作に従って、ユーザ追加リクエストを、ASNSサーバ１２に送信する。

一方、コミュニティに途中参加しようとする参加希望ユーザは、クライアントプログラムを起動し、その後、共通オブジェクトを取得するように、参加希望ユーザが所有する参加希望端末としての携帯端末１１を操作する。

参加希望端末では、クライアントプログラムが起動され、ステップＳ２０２において、ユーザの操作に従って、共通オブジェクト（参加済みユーザが既に送信済みの共通オブジェクトに類似する共通オブジェクト）が取得される。さらに、参加希望端末では、共通オブジェクトを含む端末データが、ASNSサーバ１２に送信される。

その後、ステップＳ２０３において、参加希望端末は、ASNSサーバ１２から、コミュニティへの参加（アクセス）が許可されたかどうかを判定する。

ステップＳ２０３において、コミュニティへの参加が許可されなかったと判定された場合、すなわち、ASNSサーバ１２から、参加済みユーザが参加しているコミュニティのコミュニティID(C_id)と、参加希望端末を識別する端末ID(i-uid)とが送信されてこなかった場合、ステップＳ２０４及びＳ２０５をスキップして、処理は終了する。

また、ステップＳ２０３において、コミュニティへの参加が許可されたと判定された場合、すなわち、ASNSサーバ１２から、参加済みユーザが参加しているコミュニティのコミュニティID(C_id)と、参加希望端末を識別する端末ID(i-uid)とが送信されてきた場合、処理は、ステップＳ２０４に進み、参加希望端末は、ASNSサーバ１２からのコミュニティIDと端末IDとを受信して、処理は、ステップＳ２０５に進む。

ステップＳ２０５では、参加希望端末は、ASNSサーバ１２からのコミュニティIDと端末IDとを用いて、コミュニティに参加する。

図３０は、参加希望ユーザが、第１の途中参加方法により、コミュニティに途中参加する場合のASNSサーバ１２の処理を説明するフローチャートである。

ASNSサーバ１２は、参加済み端末から、ユーザ追加リクエストが送信されてくると、ステップＳ２１１において、そのユーザ追加リクエストに応じて、参加済みユーザが参加しているコミュニティを管理するコミュニティテーブル（図１０）のtime_limitを、現在時刻に、所定の時間を加算した時刻に変更する。

すなわち、ASNSサーバ１２は、例えば、現在時刻が、19時1分20秒である場合には、その現在時刻に、所定の時間としての30秒等を加算した時刻である19時1分50秒等に、time_limitを変更する。

なお、time_limitを変更するために、現在時刻に加算する所定の時間は、30秒等に限定されるものではない。また、所定の時間は、ASNSサーバ１２で、あらかじめ設定しておくことや、参加済みユーザが、参加済み端末を操作することにより指定することができる。

また、ASNSサーバ１２であらかじめ設定された所定の時間、ひいては、その所定の時間を用いて変更されたtime_limitは、参加済みユーザが、参加済み端末を操作することにより、異なる時刻に変更することができる。

ステップＳ２１２では、ASNSサーバ１２は、参加希望端末から、共通オブジェクトを含む端末データが送信されてくるのを待って、その端末データを受信する（受け取る）。

ステップＳ２１３では、ASNSサーバ１２は、端末データを送信してきた参加希望端末（の参加希望ユーザ）に、端末ID(i_uid)を付与し、その端末ID等を含む、参加希望端末からの端末データについての仮テーブルエントリを生成して、仮テーブル（図８）に登録（記憶）する。

ステップＳ２１４では、ASNSサーバ１２は、参加希望端末からの端末データについての仮テーブルエントリの共通オブジェクトを処理する共通オブジェクト処理（図２３）を行う。

ステップＳ２１５では、ASNSサーバ１２は、参加済みユーザが参加しているコミュニティを生成するときに、参加済みユーザが送信してきた（端末データに含まれる）共通オブジェクトと、参加希望端末からの端末データに含まれる共通オブジェクト（参加希望端末からの端末データについての仮テーブルエントリの共通オブジェクト）とが類似するかどうかを、ステップＳ２１４で行われた共通オブジェクト処理で求められたオブジェクト解析データに基づいて判定する。

ステップＳ２１５において、参加済みユーザが送信してきた共通オブジェクトと、参加希望端末からの端末データに含まれる共通オブジェクトとが類似しないと判定された場合、処理は、ステップＳ２１６に進み、ASNSサーバ１２は、参加済みユーザが送信してきた共通オブジェクトと類似しない共通オブジェクトでは、コミュニティに途中参加することはできない旨のエラーメッセージを、参加希望端末に送信して、処理は終了する。

また、ステップＳ２１５において、参加済みユーザが送信してきた共通オブジェクトと、参加希望端末からの端末データに含まれる共通オブジェクトとが類似していると判定された場合、処理は、ステップＳ２１７に進み、ASNSサーバ１２は、コミュニティテーブル（図１０）を更新する。

すなわち、ステップＳ２１７では、ASNSサーバ１２は、コミュニティテーブル（図１０）の、参加済みユーザが参加しているコミュニティのコミュニティデータのエントリに、参加希望ユーザの端末ID(i_uid)を追加することにより、参加済みユーザが参加しているコミュニティに、参加希望ユーザが参加することができる状態に、コミュニティテーブルを更新する。

なお、ステップＳ２１７でのコミュニティテーブルの更新、すなわち、コミュニティテーブルのエントリへの端末ID(i_uid)の追加は、そのエントリのtime_limit（図１０）が表す時刻が経過している場合には、制限される。

ステップＳ２１８では、ASNSサーバ１２は、参加済みユーザが参加しているコミュニティのコミュニティIDと、参加済みユーザの端末IDとを、参加希望端末に送信し、処理は終了する。

コミュニティIDと端末IDとを受信した参加希望端末では、図２９で説明したように、そのコミュニティIDと端末IDとを用いて、コミュニティに参加（途中参加）することができる。

図３１は、参加希望ユーザが、第１の途中参加方法により、コミュニティに途中参加する場合の、図１のコミュニティ提供システムの処理を説明する図である。

ここで、ユーザＡが参加済みユーザであり、ユーザＢが参加希望ユーザであることとし、以下、適宜、参加済みユーザＡの携帯端末１１を、参加済み端末Ａとも記述し、参加希望ユーザＢの携帯端末１１を、参加希望端末Ｂとも記述する。

参加済みユーザＡは、参加希望ユーザＢから、参加済みユーザＡが参加しているコミュニティへの途中参加の要請を受け、その要請を了承した場合、ユーザ追加リクエストを送信するように、参加済み端末Ａを操作する。

参加済み端末Ａは、ステップＳ２３１において、参加済みユーザＡの操作に従って、ユーザ追加リクエストを、コミュニティテーブルのtime_limitの変更の要請として、ASNSサーバ１２に送信する。

ASNSサーバ１２では、コミュニティ管理部６２（図６）が、参加済み端末Ａからのユーザ追加リクエストを受信し、ステップＳ２３２において、参加済み端末Ａからのユーザ追加リクエストに従って、コミュニティDB６５（図６）のコミュニティテーブル（図１０）の、参加済みユーザＡが参加しているコミュニティを管理するコミュニティデータのエントリのtime_limitを、現在時刻に、所定の時間を加算した時刻に変更する（書き換える）。

一方、参加希望ユーザＢは、参加済みユーザＡに、コミュニティへの途中参加を要請した後、共通オブジェクトを取得し、端末データに含めて送信するように、参加希望端末Ｂを操作する。

ステップＳ２３３において、参加希望端末Ｂは、参加希望ユーザＢの操作に従って、参加済みユーザＡがコミュニティを生成するときに送信した端末データに含まれる共通オブジェクトと類似する共通オブジェクトを含む端末データを、コミュニティの生成の要請として、ASNSサーバ１２に送信する。

ASNSサーバ１２では、コミュニティ管理部６２が、参加希望端末Ｂからの端末データを受信し、ステップＳ２３４において、参加希望端末Ｂからの端末データについての仮テーブルエントリを、仮登録DB６４の仮テーブルに登録する仮テーブル登録処理（図２２）を行う。

さらに、ASNSサーバ１２では、ステップＳ２３５において、コミュニティ管理部６２が、仮登録DB６４の仮テーブルの仮テーブルエントリの、参加希望ユーザＢからの共通オブジェクトが、参加済みユーザＡがコミュニティを生成するときに送信してきた共通オブジェクトと類似するかどうかの類似判定（類似性の判定）を行う。

そして、参加希望ユーザＢからの共通オブジェクトが、参加済みユーザＡがコミュニティを生成するときに送信してきた共通オブジェクトと類似する場合、ステップＳ２３６において、コミュニティ管理部６２は、コミュニティDB６５のコミュニティテーブルの、参加済みユーザＡが参加しているコミュニティのコミュニティデータのエントリに、参加希望ユーザＢの端末ID(i_uid)を追加する。

ステップＳ２３７では、コミュニティ管理部６２は、コミュニティDB６５のコミュニティテーブルから、参加済みユーザＡが参加しているコミュニティのコミュニティID(C_id)と、参加希望ユーザＢの端末ID(i_uid)とを取得する。

ステップＳ２３８では、コミュニティ管理部６２は、参加希望端末Ｂに、参加希望ユーザＢの端末ID(i_uid)とコミュニティID(C_id)を送信する。

参加希望端末Ｂは、コミュニティ管理部６２からの端末IDとコミュニティIDを受信する。そして、参加希望ユーザＢは、端末IDとコミュニティIDを受信した参加希望端末Ｂを操作することにより、コミュニティIDで特定されるコミュニティを介して、コンテンツのダウンロードやアップロード、メッセージのやりとり等を行うことができる。

次に、第２の途中参加方法について説明する。

図３２は、参加希望ユーザＢが、第２の途中参加方法により、コミュニティに途中参加する場合の携帯端末１１の処理を説明するフローチャートである。

コミュニティに途中参加しようとする参加希望ユーザＢは、空間及び時間を共有している参加済みユーザＡに、途中参加を希望する旨を伝える。

参加済みユーザＡは、参加希望ユーザＢの途中参加を了承する場合、動作モードが、ASNSサーバ１２等との間でトークンの受け渡しを行うトークン受け渡しモードになるように、参加済み端末Ａとしての携帯端末１１を操作する。

参加済み端末Ａは、ステップＳ３０１において、参加済みユーザＡの操作に従って、動作モードを、トークン受け渡しモードにし、ASNSサーバ１２に、トークンを要求するための、参加済み端末ＡのMACアドレスを、ASNSサーバ１２に送信する。

ステップＳ３０２において、参加済み端末Ａは、ASNSサーバ１２から、トークンが送信されてくるのを待って、ASNSサーバ１２からのトークンを取得（受信）する。

ここで、ASNSサーバ１２から参加済み端末Ａに送信されるトークンは、コミュニティに（途中）参加する権利として機能する。

ステップＳ３０３において、参加済み端末Ａと参加希望端末Ｂとが、NFC等の近接通信を開始する。

ステップＳ３０４において、参加希望端末Ｂは、参加済み端末ＡがASNSサーバ１２から取得したトークンを、参加済み端末Ａから、近接通信によって取得する。

ステップＳ３０５において、参加希望端末Ｂは、その参加希望端末Ｂ自身のMACアドレスを、近接通信によって、参加済み端末Ａに送信する（渡す）。

ステップＳ３０６において、参加済み端末Ａは、参加希望端末Ｂから送信されてきた、その参加希望端末ＢのMACアドレスを、ASNSサーバ１２に送信する。

ステップＳ３０７において、参加希望端末Ｂは、近接通信によって、参加済み端末Ａから取得したトークンを、その参加希望端末ＢのMACアドレスとともに、ASNSサーバ１２に送信する。

その後、ステップＳ３０８において、参加希望端末Ｂは、ASNSサーバ１２から、コミュニティへの参加（アクセス）が許可されたかどうかを判定する。

ステップＳ３０８において、コミュニティへの参加が許可されなかったと判定された場合、すなわち、ASNSサーバ１２から、参加済みユーザＡが参加しているコミュニティのコミュニティID(C_id)と、参加希望端末Ｂを識別する端末ID(i-uid)とが送信されてこなかった場合、ステップＳ３０９及びＳ３１０をスキップして、処理は終了する。

また、ステップＳ３０８において、コミュニティへの参加が許可されたと判定された場合、すなわち、ASNSサーバ１２から、参加済みユーザＡが参加しているコミュニティのコミュニティID(C_id)と、参加希望端末Ｂを識別する端末ID(i-uid)とが送信されてきた場合、処理は、ステップＳ３０９に進み、参加希望端末Ｂは、ASNSサーバ１２からのコミュニティIDと端末IDとを受信して、処理は、ステップＳ３１０に進む。

ステップＳ３１０では、参加希望端末Ｂは、ASNSサーバ１２からのコミュニティIDと端末IDとを用いて、コミュニティに参加する。

図３３は、参加希望ユーザＢが、第２の途中参加方法により、コミュニティに途中参加する場合のASNSサーバ１２の処理を説明するフローチャートである。

ASNSサーバ１２は、トークン受け渡しモードの参加済み端末Ａから、その参加済み端末ＡのMACアドレスが送信されてくると、ステップＳ３２１において、その参加済み端末ＡのMACアドレス（以下、MACアドレスＡとも記載する）を受信する。

ステップＳ３２２において、ASNSサーバ１２は、参加済み端末Ａからの、その参加済み端末ＡのMACアドレスＡを一時記憶（記録）する。

さらに、ステップＳ３２２では、ASNSサーバ１２は、MACアドレスＡが、コミュニティテーブルに登録されているかどうかを確認し、MACアドレスＡが、コミュニティテーブルに登録されている場合、すなわち、MACアドレスＡが、既に生成されているコミュニティに参加しているユーザの携帯端末１１のMACアドレスである場合、例えば、乱数を、トークンとして発行し、MACアドレスＡを送信してきた参加済み端末Ａに送信する。

ステップＳ３２３において、ASNSサーバ１２は、参加済み端末Ａから、参加希望端末Ｂの参加希望端末ＢのMACアドレス（以下、MACアドレスＢとも記載する）が送信されてくるのを待って、そのMACアドレスＢを受信する。

ステップＳ３２４において、ASNSサーバ１２は、参加済み端末Ａからの、参加希望端末ＢのMACアドレスＢを、一時記憶する。

ステップＳ３２５において、ASNSサーバ１２は、参加希望端末Ｂから、その参加希望端末ＢのMACアドレスＢと、トークンとが送信されてくるのを待って受信する。

そして、ステップＳ３２６において、ASNSサーバ１２は、ステップＳ３２５で参加希望端末Ｂから受信したMACアドレスＢ（以下、受信MACアドレスともいう）と、ステップＳ３２４で記憶した、参加済み端末Ａからの、参加希望端末ＢのMACアドレスＢ（以下、記憶MACアドレスともいう）とが一致するかどうかを判定する。

ステップＳ３２６において、受信MACアドレスと、記憶MACアドレスとが一致しないと判定された場合、処理は、ステップＳ３２７に進み、ASNSサーバ１２は、受信MACアドレスを送信してきた携帯端末１１が、参加希望端末Ｂになりすましている可能性があるとして、受信MACアドレスを送信してきた携帯端末１１に、エラーメッセージを送信して、処理を終了する。

また、ステップＳ３２６において、受信MACアドレスと、記憶MACアドレスとが一致すると判定された場合、処理は、ステップＳ３２８に進み、ASNSサーバ１２は、ステップＳ３２５で参加希望端末Ｂから受信したトークン（以下、受信トークンともいう）と、ステップＳ３２２で発行したトークン（以下、発行トークンともいう）とが一致するかどうかを判定する。

ステップＳ３２８において、受信トークンと発行トークンとが一致しないと判定された場合、処理は、ステップＳ３２７に進み、ASNSサーバ１２は、受信トークンを送信してきた携帯端末１１が、参加希望端末Ｂになりすましている可能性があるとして、受信トークンを送信してきた携帯端末１１に、エラーメッセージを送信して、処理を終了する。

また、ステップＳ３２８において、受信トークンと発行トークンとが一致すると判定された場合、処理は、ステップＳ３２９に進み、ASNSサーバ１２は、コミュニティテーブル（図１０）を更新する。

すなわち、ステップＳ３２９では、ASNSサーバ１２は、コミュニティテーブル（図１０）の、参加済みユーザＡが参加しているコミュニティのコミュニティデータのエントリに、参加希望ユーザＢの端末IDを追加することにより、参加済みユーザＡが参加しているコミュニティに、参加希望ユーザＢが参加することができる状態に、コミュニティテーブルを更新する。

なお、ステップＳ３２９でのコミュニティテーブルの更新、すなわち、コミュニティテーブルのエントリの端末IDの追加は、そのエントリのtime_limitが表す時刻が経過していても、制限されない。

ステップＳ３３０では、ASNSサーバ１２は、参加済みユーザＡが参加しているコミュニティのコミュニティIDと、参加済みユーザの端末IDとを、参加希望端末Ｂに送信し、処理は終了する。

コミュニティIDと端末IDとを受信した参加希望端末Ｂでは、図３２で説明したように、そのコミュニティIDと端末IDとを用いて、コミュニティに参加（途中参加）することができる。

図３４は、参加希望ユーザが、第２の途中参加方法により、コミュニティに途中参加する場合の、図１のコミュニティ提供システムの処理を説明する図である。

参加済みユーザＡは、参加希望ユーザＢから、参加済みユーザＡが参加しているコミュニティへの途中参加の要請を受け、その要請を了承した場合、トークン受け渡しモードになるように、参加済み端末Ａを操作する。

参加済み端末Ａは、ステップＳ３４１において、参加済みユーザＡの操作に従って、動作モードを、トークン受け渡しモードに設定し、参加済み端末ＡのMACアドレスＡを、ASNSサーバ１２に送信する。

ASNSサーバ１２では、コミュニティ管理部６２（図６）が、参加済み端末ＡからのMACアドレスＡを受信し、ステップＳ３４２において、例えば、仮登録DB６４に一時記憶する。

ステップＳ３４３において、コミュニティ管理部６２は、トークンを発行し、MACアドレスＡを送信してきた参加済み端末Ａに送信する。

参加済み端末Ａは、コミュニティ管理部６２からのトークンを受信し、参加希望端末Ｂとの間で近接通信を開始する。

すなわち、ステップＳ３４４において、参加済み端末Ａは、トークンを、近接通信によって、参加希望端末Ｂに送信し、参加希望端末Ｂは、参加済み端末Ａからのトークンを受信する。

ステップＳ３４５において、参加希望端末Ｂは、その参加希望端末ＢのMACアドレスＢを、近接通信によって、参加済み端末Ａに送信し、参加済み端末Ａは、参加希望端末ＢからのMACアドレスＢを受信する。

その後、ステップＳ３４６において、参加済み端末Ａは、参加希望端末ＢからのMACアドレスＢを、コミュニティ管理部６２に送信する。

コミュニティ管理部６２は、参加済み端末ＡからのMACアドレスＢを受信し、ステップＳ３４７において、そのMACアドレスＢを、ステップＳ３４３で発行したトークンと対応付けて、例えば、仮登録DB６４に一時記憶する。

ステップＳ３４８において、参加希望端末Ｂは、その参加希望端末ＢのMACアドレスＢと、参加済み端末Ａから近接通信によって取得したトークンとを、コミュニティ管理部６２に送信する。

コミュニティ管理部６２は、参加希望端末ＢからのMACアドレスＢとトークンを受信し、ステップＳ３４９において、仮登録DB６４に記憶されているトークンである発行トークン、及び、その発行トークンと対応付けて、仮登録DB６４に記憶されているMACアドレスＢである記憶MACアドレスと、参加希望端末Ｂから受信したトークン、及び、MACアドレスＢである受信トークン、及び、受信MACアドレスとを照合する。

ステップＳ３５０では、コミュニティ管理部６２は、ステップＳ３４９での、発行トークン及び記憶MACアドレスと、受信トークン及び受信MACアドレスとの照合の結果として、発行トークンと受信トークンとが一致し、かつ、記憶MACアドレスと受信MACアドレスとが一致するかどうかを判定する。

発行トークンと受信トークンとが一致し、かつ、記憶MACアドレスと受信MACアドレスとが一致する場合、コミュニティ管理部６２は、ステップＳ３５１において、コミュニティDB６５のコミュニティテーブルの、参加済みユーザＡが参加しているコミュニティのコミュニティデータのエントリに、参加希望ユーザＢの端末ID(i_uid)を追加する。

ステップＳ３５２では、コミュニティ管理部６２は、コミュニティDB６５のコミュニティテーブルから、参加済みユーザＡが参加しているコミュニティのコミュニティID(C_id)と、参加希望ユーザＢの端末ID(i_uid)とを取得する。

さらに、ステップＳ３５２では、コミュニティ管理部６２は、参加希望端末Ｂに、参加希望ユーザＢの端末IDとコミュニティID(i_uid)を送信する。

第２の途中参加方法では、トークンとMACアドレスを用いることにより、参加希望端末Ｂへのなりすましを防止することができる。

また、第２の途中参加方法では、参加希望端末Ｂは、共通オブジェクトを、ASNSサーバ１２に送信する必要がない。

なお、トークンには、有効期限が設定される。有効期限を経過したトークンは無効であり、ASNSサーバ１２は、無効なトークンに対しては、処理を行わない。

本技術によれば、コミュニティをより安心に、より簡単に利用することができるようになる。

また、本技術によれば、すなわち、例えば、バス旅行や、結婚式、ロックフェスティバル等のコンサート、社内ミーティング、展示会等において、利便性の高いコミュニティを生成することができる。

具体的には、例えば、バス旅行では、見知らぬ人どうしが一緒になる。この場合、バス旅行の参加者は、一時的にコミュニケーションをとることになるが、そのコミュニケーションを、例えば、メール交換によってとることは、煩雑である。また、バス旅行において、バス旅行の参加者の誰かが、従来のSNSのコミュニティをつくり、そのコミュニティに、他の参加者を招待することは、面倒である。

一方、バス旅行において、本技術のコミュニティをつくることにより、結果的に安心してコミュニケーションを図ることができる。また、本技術のコミュニティによれば、バス旅行の参加者は、メールアドレスなどの個人情報を知らせずに、他の参加者が撮影した写真や、動画を共有することができる

次に、例えば、結婚式については、結婚式の参加者は、多くが面識のない人たちであるが、本技術のコミュニティをつくることにより、新郎新婦の写真、動画、メッセージ等を共有することを簡単に行うことができる。

また、本技術のコミュニティには、途中参加が可能であるため、結婚式の二次会や三次会だけに参加する参加者であっても、結婚式でつくったコミュニティに、途中参加することができ、コミュニティに、結婚式を撮影した動画をアップロードしておけば、結婚式から参加した参加者と、二次会等から参加した参加者との間で、結婚式で起こった出来事を共有することができる。

次に、例えば、ロックフェスティバルその他の様々な音楽ジャンルのアーティストが登場するコンサート等のイベントについては、同じイベントに参加しているユーザであっても、好きな趣味や好きな音楽ジャンルはバラバラであることがある。

そこで、イベントに出演するアーティストごとに、本技術のコミュニティをつくることで、好きな音楽ジャンルが共通するユーザどうしが、お互いを容易に見つけることができる。

また、ユーザは、１以上のコミュニティに参加することができ、コミュニティに参加しているユーザの共通性（例えば、あるコミュニティと、他のコミュニティとの両方に参加しているユーザの数）を、コミュニティどうしの相関として、ユーザに提示することにより、例えば、ユーザは、自身が好きな音楽ジャンルとして認識していた音楽ジャンルとユーザの共通性がある、自身が好きな音楽ジャンルとして認識していなかった音楽ジャンルを発見することができる。

次に、例えば、社外ミーティングについては、社外ミーティングで初面識の人どうしが、本技術のコミュニティをつくることができる。社外ミーティングの参加者が、例えば、スマートフォンを所持している場合には、そのスマートフォンによって、所持者の音声を解析して、本技術のコミュニティに蓄積することができる。この場合、コミュニティを、参加者の発言を保存するログとして使用することができ、さらに、そのログを、後日の議事録の作成に役立てることができる。

次に、例えば、展示会については、例えば、その展示会での商談に参加したユーザの音声を、本技術のコミュニティに蓄積することができる。この場合、コミュニティを、商談に参加したユーザの発言を保存するログとして使用することができ、さらに、後日、そのログから、商談のときの雰囲気を認識することや、展示会の評判を調べることができる。

ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。

また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

なお、本技術は、以下のような構成をとることができる。

［１]
端末から送信されてくる情報を取得する取得部と、
複数の端末から送信されてくる情報の類似度に応じて、コミュニティを生成する生成部と
を備え、
前記コミュニティ生成部は、１つの端末から異なる種類の複数の情報が送信されてきた場合に、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する
情報処理装置。
［２]
前記コミュニティ生成部は、所定のセキュリティレベルに基づいて、コミュニティを生成する
［１］に記載の情報処理装置。
［３]
前記セキュリティレベルとして、少なくとも、
コミュニティに参加する複数のユーザの端末から送信されてくる情報が、異なる種類の情報であることを許可する第１レベルと、
コミュニティに参加する複数のユーザの端末から送信されてくる情報が、同一の種類の情報であることを要求する第２レベルと
があり、
前記コミュニティ生成部は、
前記セキュリティレベルが、第１のレベルである場合、前記複数の情報のうちのいずれかの情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成し、
前記セキュリティレベルが、第２レベルである場合、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する
［２］に記載の情報処理装置。
［４]
前記端末数が最も多い情報と異なる種類の情報を送信してきた端末に、前記端末数が最も多い情報と同一の種類の情報の送信を要求する
［１］ないし［３］のいずれかに記載の情報処理装置。
［５]
端末から送信されてくる情報を取得し、
複数の端末から送信されてくる情報の類似度に応じて、コミュニティを生成する
ステップを含み、
前記コミュニティの生成では、１つの端末から異なる種類の複数の情報が送信されてきた場合に、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する
情報処理方法。
［６]
端末から送信されてくる情報を取得する取得部と、
複数の端末から送信されてくる情報の類似度に応じて、コミュニティを生成する生成部と
して、コンピュータを機能させるためのプログラムであり、
前記コミュニティ生成部は、１つの端末から異なる種類の複数の情報が送信されてきた場合に、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する
プログラム。

１０ネットワーク，１１携帯端末，１２ ASNSサーバ，２１バス，２２ CPU，２３ ROM，２４ RAM，２５ハードディスク，２６出力部，２７入力部，２８通信部，２９ドライブ，３０入出力インターフェース，３１リムーバブル記録媒体，５１通信部，５２共通オブジェクト取得部，５３制御部，６１通信部，６２コミュニティ管理部，６３制御部，６４仮登録DB，６５コミュニティDB，７１制御部，７２共通オブジェクト処理部，７３コミュニティ生成部，７４コミュニティ処理部，７５コンテンツ管理部

Claims

端末から送信されてくる情報を取得する取得部と、
複数の端末から送信されてくる情報の類似度に応じて、コミュニティを生成する生成部と
を備え、
前記コミュニティ生成部は、１つの端末から異なる種類の複数の情報が送信されてきた場合に、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する
情報処理装置。
前記コミュニティ生成部は、所定のセキュリティレベルに基づいて、コミュニティを生成する
請求項１に記載の情報処理装置。
前記セキュリティレベルとして、少なくとも、
コミュニティに参加する複数のユーザの端末から送信されてくる情報が、異なる種類の情報であることを許可する第１レベルと、
コミュニティに参加する複数のユーザの端末から送信されてくる情報が、同一の種類の情報であることを要求する第２レベルと
があり、
前記コミュニティ生成部は、
前記セキュリティレベルが、第１のレベルである場合、前記複数の情報のうちのいずれかの情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成し、
前記セキュリティレベルが、第２レベルである場合、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する
請求項２に記載の情報処理装置。
前記端末数が最も多い情報と異なる種類の情報を送信してきた端末に、前記端末数が最も多い情報と同一の種類の情報の送信を要求する
請求項３に記載の情報処理装置。
端末から送信されてくる情報を取得し、
複数の端末から送信されてくる情報の類似度に応じて、コミュニティを生成する
ステップを含み、
前記コミュニティの生成では、１つの端末から異なる種類の複数の情報が送信されてきた場合に、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する
情報処理方法。
端末から送信されてくる情報を取得する取得部と、
複数の端末から送信されてくる情報の類似度に応じて、コミュニティを生成する生成部と
して、コンピュータを機能させるためのプログラムであり、
前記コミュニティ生成部は、１つの端末から異なる種類の複数の情報が送信されてきた場合に、前記複数の情報それぞれについて、その情報と類似する情報を送信してきた端末の端末数をカウントし、その端末数が最も多い情報と類似する情報を送信してきた端末のユーザに参加を許可するコミュニティを生成する
プログラム。