JP2008310383A - コミュニティサイト提供システム、コミュニティサイト提供方法及びコンピュータプログラム - Google Patents

Abstract

【課題】本発明のコミュニティサイト提供システムは、複数のコミュニティサイトを階層化して接続し、ユーザが各コミュニティサイト間をシームレスに移動可能とする。
【解決手段】階層化ＳＮＳ提供部１１０は、ユーザの実際に属する組織単位毎にＳＮＳ３００をそれぞれ生成し、各ＳＮＳ３００を実組織の階層構造に似せて階層化する。各ＳＮＳ３００は、それぞれの業務に応じた画面構成を備える。ユーザは、所属ＳＮＳだけでなく、所属ＳＮＳの上位または下位に位置するＳＮＳに一時的に移動することができる。階層化ＳＮＳ上の位置やユーザ属性に応じて、情報を発信可能な範囲及び情報を受信可能な範囲が制御される。
【選択図】図１

Description

本発明は、コミュニティサイト提供システム、コミュニティサイト提供方法及びコンピュータプログラムに関する。

例えば、ホームページ、電子メールシステム（e-mail）、電子掲示板システム（BBS）、ブログシステム（Weblog）等の、通信ネットワークを用いた種々のコミュニケーションシステムが提供されている。また、ＳＮＳ（ソーシャル・ネットワーキングサービス）として知られるコミュニティサイトも普及している（非特許文献１）。

ＳＮＳは、登録されたメンバーのみが参加することができ、匿名性の少ない情報交換をメンバー同士で自由に行うことができる。ＳＮＳでは、各ユーザにそれぞれ自分専用のウェブページが用意されており、ウェブページにはブログと呼ばれる日記等を掲載可能である。また、ＳＮＳでは、目的や趣味を共通にする複数のユーザがコミュニティを生成することもできる。ユーザは、自分のブログやコミュニティの掲示板等を介して、種々の情報を発信することができ、他のユーザと意見を交換することができる。

このようにＳＮＳは、そこに参加する多数のユーザ間で情報を交換し、情報を共有し、新たな情報を生産することができるコミュニケーションシステムであるため、企業内での活用も始まりつつある。
ソーシャル・ネットワーキングサービスmixi（ミクシー）インターネット＜URL:http://mixi.jp/＞

企業がＳＮＳを用いて社員間での情報共有や情報交換を促進しようとしても、利用の促進に失敗し、想定した効果を得られない場合も多い。例えば、多数の社員が一つの企業ＳＮＳに属する場合には、一般のＳＮＳと同様に見知らぬユーザが多数を占める状態になってしまい、企業というクローズドな環境でＳＮＳを利用する安心感が失われ、この結果、企業ＳＮＳの活動が停滞する。

さらに、多数の社員が参加する企業ＳＮＳでは、各社員のＳＮＳ活動が低下したとしても、参加者総数が多いため、結果的に多数の情報が生産されうる。しかし、多くの社員にとって、自分の属する部署以外の他部署に固有の情報は役に立たないことが多い。即ち、各社員は、自分との関係が希薄な雑多な情報に取り囲まれることになり、本当に必要とする情報を企業ＳＮＳから速やかに得ることができないという問題点もある。

一方、安心感の保証や自分との関連が希薄な情報の排除を重視して、部や本部など、企業内の各組織ごとに個別にＳＮＳを作成した場合、組織改編や人事異動に対応することが困難となる。

さらに、ユーザが、特定の趣味や出身校など、共通の話題に基づいて、それぞれ閉じたコミュニティを構成し、その中でコミュニケーションをすればよい一般のＳＮＳに対して、企業内のコミュニケーションにおいては、粒度の異なる議題を整理して議論できる環境が求められる。即ち、例えば、あるべき人事評価制度の姿など、全社員で議論したい内容と、部署のレクリエーションや特定の顧客の動向についてなど、所定の部や課の構成員のみで共有すべき情報とが混在していると、円滑なコミュニケーションが阻害される。

そこで、本発明の目的は、複数のコミュニティサイトを階層化して連結することにより、使い勝手を向上できるようにしたコミュニティサイト提供システム、コミュニティサイト提供方法及びコンピュータプログラムを提供することにある。本発明の他の目的は、階層化された所定コミュニティサイト間をユーザが自在に移動して、情報の発信及び取得を行うことができるようにしたコミュニティサイト提供システム、コミュニティサイト提供方法及びコンピュータプログラムを提供することにある。本発明の別の目的は、現実の組織構成に対応する複数のコミュニティサイトを階層化して連結し、各コミュニティサイトでの情報管理を容易に行うことができるコミュニティサイト提供システム、コミュニティサイト提供方法及びコンピュータプログラムを提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明の一つの観点に従う、各ユーザ毎にそれぞれ生成されるウェブページを各ユーザ間で相互に連結して構成されるコミュニティサイトを複数提供するためのコミュニティサイト提供システムは、複数のコミュニティサイトを階層化して提供するコミュニティサイト提供部と、各コミュニティサイトで使用されるデータを記憶するデータ記憶部と、各コミュニティサイトからの要求に応じてデータ処理を実行し、その処理結果を要求元のコミュニティサイトに送信するデータ処理部と、データ処理部からの要求に応じてデータ記憶部からデータを取得し、取得したデータをデータ処理部に送信するデータ入出力管理部と、を備え、コミュニティサイト提供部は、データ処理部から受信した処理結果に基づいて各コミュニティサイトの各ユーザ毎のウェブページをそれぞれ生成し、かつ、各コミュニティサイトのうち予め設定された範囲内のコミュニティサイト間で、ユーザの移動を許可する。

本発明の実施形態では、コミュニティサイト提供部は、各ユーザが最初に所属する初期所属先コミュニティサイトと直系上位または直系下位の関係にある所定コミュニティサイト間で、各ユーザの移動を許可する。

本発明の実施形態では、コミュニティサイト提供部は、ユーザの属するコミュニティサイトの階層構造上の位置及びユーザの属性に応じて、情報の発信範囲または情報の取得範囲のうち少なくともいずれか一方を制御する。

本発明の実施形態では、コミュニティサイト提供部は、各ユーザが現在所属するコミュニティサイト内で、各ユーザに情報の発信または情報の取得を許可するように制御することができる。

本発明の実施形態では、コミュニティサイト提供部は、ユーザに設定されているアクセス権限に基づいて、各コミュニティサイト間の移動を制御する。

本発明の実施形態では、コミュニティサイト提供部は、所定コミュニティサイトまたは初期所属先コミュニティサイトのいずれかにおいて情報が発信された旨を、各ユーザが現在所属するコミュニティサイト内で通知する。

本発明の実施形態では、データ記憶部は、各コミュニティサイトでそれぞれ使用されるデータを一元管理しており、データ入出力管理部は、データ処理部からの要求に応じてデータ記憶部から取得したデータのうち、要求元ユーザに応じたデータのみをデータ処理部に送信する。

本発明の実施形態では、各コミュニティサイトの階層構造に関する構造情報と、ユーザが各コミュニティサイトから情報を取得可能な範囲及びユーザが各コミュニティサイトに情報を発信可能な範囲を制御するための管理情報とは、データ記憶部にそれぞれ記憶されている。

本発明の実施形態では、構造情報及び管理情報は、ウェブページの生成に使用するコンテンツデータとは別にデータ記憶部に記憶されており、かつ、管理情報とコンテンツデータとは対応付けられている。

本発明の実施形態では、コンテンツデータの属性に応じて管理情報の所定の一部を更新することにより、コンテンツデータがユーザによって取得可能な範囲を制御する。

本発明の実施形態では、各コミュニティサイトは、各ユーザの属する各実組織に対応してそれぞれ構成されており、コミュニティサイト提供部は、各実組織により形成される階層構造に応じて、各コミュニティサイトを階層化して提供する。

本発明の他の観点に従う、各ユーザ毎にそれぞれ生成されるウェブページを各ユーザ間で相互に連結して構成されるコミュニティサイトを複数提供するための方法は、複数のコミュニティサイトを階層化して提供するステップと、ユーザが現在所属するコミュニティサイト及びユーザの属性応じて、データ記憶部に記憶されているコンテンツデータを全て検出するステップと、検出されたコンテンツデータのうちユーザに予め許可されている所定のコンテンツデータのみを取得するステップと、取得された所定のコンテンツデータによってユーザ用のウェブページを生成するステップと、生成されたウェブページを、ユーザの使用するユーザコンピュータが備える情報出力装置に出力させるステップと、ユーザが所属コミュニティサイトから別のコミュニティサイトへの移動を希望した場合には、ユーザの属性に応じて移動を許可するステップと、をそれぞれ実行する。

本発明のさらに別の観点に従う、コンピュータ上に、各ユーザ毎にそれぞれ生成されるウェブページを各ユーザ間で相互に連結して構成されるコミュニティサイトを複数生成させるためのコンピュータプログラムは、複数のコミュニティサイトを階層化して提供する機能と、各コミュニティサイトで使用されるコンテンツデータをデータ記憶部に記憶させる機能と、ユーザが現在所属するコミュニティサイトに応じて、データ記憶部に記憶されているコンテンツデータを検出する機能と、検出されたコンテンツデータのうちユーザの属性に応じた所定のコンテンツデータのみを、ユーザの位置するコミュニティサイトに送信する機能と、所定のコンテンツデータに基づいて、ユーザ用のウェブページを生成する機能と、生成されたウェブページをユーザの使用するユーザコンピュータに送信する機能と、ユーザが所属コミュニティサイトから別のコミュニティサイトへの移動を希望した場合には、ユーザの属性に応じて移動を許可する機能とをコンピュータ上に実現させる。

以下、図面に基づき、本発明の実施の形態を説明する。図１に示すように、本実施形態に係るコミュニティサイト提供システムは、例えば、企業内の各組織に対応する複数のＳＮＳ（Social Networking Service）３００を階層化して連結する。同一企業内の各ユーザは、それぞれの所属部署に応じたＳＮＳ３００に参加して、情報交換等を行う。

このシステムでは、階層化ＳＮＳされた複数のＳＮＳを提供する機能１１０とは別に、各ユーザによる情報の発信及び取得を管理する機能１３０を設け、この機能１３０を介して、一元管理されたコンテンツデータにアクセスするようになっている。

また、本システムでは、ユーザは、自分の所属する部署に対応付けられているＳＮＳ３００（初期所属先ＳＮＳ）だけでなく、その上位（例えば直系上位）または下位（例えば、直系下位）に位置する別のＳＮＳ３００に一時的に移動して、情報の発信や情報の取得を行うことができる。以下、本実施形態をより詳細に説明する。

図１は、本実施例によるコミュニティサイト提供システムの全体構成を示すブロック図である。本システムは、例えば、ＳＮＳ提供装置１００と、ＳＮＳ提供装置１００に通信ネットワークCNを介して接続された複数のユーザ端末２００とを備えている。

ＳＮＳ提供装置１００は、１台または複数台のコンピュータ装置から構成されるもので、例えば、階層化ＳＮＳ提供部１１０と、データ処理部１２０と、セキュリティ処理部１３０と、検索処理部１４０と、コンテンツデータベース１５０と、セキュリティデータベース１６０とを備えている。

階層化ＳＮＳ提供部１１０は、「コミュニティサイト」の一例としての複数のＳＮＳ３００を階層化して接続し、各ユーザの操作するユーザ端末２００に提供するものである。ＳＮＳ３００は、例えば、ウェブサーバとして構成されており、ユーザの属する企業等の組織の構成に応じて用意されている。実際の組織は、例えば、事業部、部、課等のように上位レベルから低位レベルまで複数の階層で構成されることが多い。そこで、階層化ＳＮＳ提供部１１０は、実組織の階層化構造に合わせて、最上位ＳＮＳから最下位ＳＮＳまでの複数の階層でＳＮＳ３００を提供する。

各ＳＮＳ３００は、それぞれに特有の画面構成を備えることができる。各ＳＮＳ３００に特有の画面構成は、例えば、個別フロント提供機能３１０によって実現させることができる。例えば、証券業務を行う部署に対応するＳＮＳ３００には各種指標のグラフを表示させる等のように、各ＳＮＳ３００に対応する部署の業務に応じたコンテンツ及び機能を配置して各ユーザのウェブページを構成することができる。各ＳＮＳ３００のウェブページの構成は後述するが、各ＳＮＳ３００は、例えば、ブログ、掲示板等のサービスを備えている。

なお、便宜上、本実施例では、最上位、中位、最下位の３つの階層を示す。しかし、これに限らず、実組織の階層構造に対応しているならば、２つの階層または４つ以上の階層でＳＮＳ３００をそれぞれ構築する構成でもよい。また、理解のために、最上位ＳＮＳには「Ｈ」、中位ＳＮＳには「Ｍ１，Ｍ２」、最下位のＳＮＳには「Ｌ１〜Ｌ４」の符号を添えて説明する場合がある。

具体的に例を挙げると、最上位ＳＮＳ３００（Ｈ）は、全社に対応するＳＮＳとして、中位ＳＮＳ３００（Ｍ１，Ｍ２）は、各事業本部に対応するＳＮＳとして、最下位ＳＮＳ３００（Ｌ１〜Ｌ４）は、各事業本部に属する下部組織（課やグループ）に対応するＳＮＳとして、それぞれ構築することができる。

詳細は後述するが、各ユーザは、例えば、一般社員、管理職、役員等のようなそれぞれの地位に応じて、その所属先ＳＮＳが決定される。例えば、一般社員のユーザは、最下位ＳＮＳに所属し、管理職のユーザは中位ＳＮＳに所属する。所属先ＳＮＳは、各ユーザが階層化ＳＮＳにログインしたときに配置される最初のＳＮＳであり、本明細書では、初期所属先ＳＮＳまたはホームＳＮＳと呼ぶ。

ユーザの初期位置はホームＳＮＳとなるが、各ユーザは、最初の一回の認証処理を行うだけで、階層化された所定のＳＮＳ間を自在に移動でき、ホームＳＮＳ以外の他のＳＮＳに参加できる。即ち、ユーザは、ホームＳＮＳと直系上位または直系下位の関係にある所定ＳＮＳ間で、各ＳＮＳ間を自在に移動し、所望のＳＮＳに参加できる。

なお、ＳＮＳに参加するとは、そのＳＮＳから情報を取得すること、または、そのＳＮＳ内に情報を発信すること、の少なくともいずれか一方を意味する。例えば、最下位ＳＮＳのユーザは、その上位に位置する中位ＳＮＳや、さらにその上位に位置する最上位ＳＮＳに参加できる。中位ＳＮＳのユーザは、その上位または下位に位置するＳＮＳのいずれにも参加できる。

最上位ＳＮＳは、ユーザの属する組織全体（全社）に対応しており、各ＳＮＳの最も上位に位置する。最上位ＳＮＳの下に位置する各ＳＮＳに所属するユーザは、階層構造を最上位ＳＮＳまで移動することにより、最上位ＳＮＳに参加することができる。従って、中位ＳＮＳや最下位ＳＮＳをホームＳＮＳとする各ユーザは、最上位ＳＮＳに移動することにより、全ユーザに向けて情報を発信することができる。

直系上位及び直系下位について説明すると、例えば、中位ＳＮＳ（Ｍ１）を基準とした場合、中位ＳＮＳ（Ｍ１）の直系上位に位置するＳＮＳは、最上位ＳＮＳ（Ｈ）であり、中位ＳＮＳ（Ｍ１）の直系下位に位置するＳＮＳは、最下位ＳＮＳ（Ｌ１）及び（Ｌ２）である。中位ＳＮＳ（Ｍ１）から見て、他の最下位ＳＮＳ（Ｌ３）及び（Ｌ４）は、傍系下位のＳＮＳに該当する。本実施例では、ユーザは、初期所属先ＳＮＳの直系上位または直系下位に位置する所定のＳＮＳ間で移動可能である。通常の場合、ユーザは、傍系ＳＮＳに移動することはできない。但し、システム管理者は、全ＳＮＳを管理する必要があるため、全ＳＮＳに移動可能である。

データ処理部１２０は、各ＳＮＳ３００からの要求に応じてデータ処理を行うためのものである。例えば、データ処理部１２０は、セキュリティ処理部１３０から受け取った各種コンテンツデータ（ブログの記事データや掲示板の投稿データ等）を、そのままで又は加工して、要求元のＳＮＳに出力する。データ処理部１２０は、各ユーザの友人リストを管理するための処理や、電子メールの作成や送受信等を管理するための処理等を行うこともできる。データ処理部１２０の詳細は、図２と共に後述する。

セキュリティ処理部１３０は、各ＳＮＳ３００における各種コンテンツデータの利用を管理するためのものである。セキュリティ処理部１３０の詳細は後述するが、セキュリティ処理部１３０は、各ユーザの属性や現在参加しているＳＮＳ３００の階層構造上の位置に応じて、各ユーザに利用させるコンテンツデータを取捨選択する。

検索処理部１４０は、例えば、DBMS（DataBase Management System）として構成され、コンテンツデータベース１５０やセキュリティデータベース１６０からデータを読み出したり、これら各データベース１５０，１６０にデータを入力する。なお、説明の便宜上、セキュリティ処理部１３０と検索処理部１４０とを別々の構成として説明したが、両者を一体化する構成でもよい。

コンテンツデータベース１５０は、各ＳＮＳ３００で利用される各種のコンテンツデータを記憶するものである。セキュリティデータベース１６０は、各コンテンツデータの利用を管理するための管理データを記憶するものである。これら各データベース１５０，１６０の詳細は後述する。

図１中のユーザ端末２００は、例えば、パーソナルコンピュータ、携帯情報端末、携帯電話等のようなコンピュータ端末として構成される。ユーザ端末２００は、例えば各ユーザに１台ずつ、または複数のユーザに１台ずつのように、配置される。各ユーザ端末２００は、例えば、イントラネット、ＬＡＮ、インターネットのような通信ネットワークＣＮを介して、階層化ＳＮＳ提供部１１０に双方向通信可能に接続されている。

図２は、データ処理部１２０、セキュリティ処理部１３０及びコンテンツデータベース１５０の構成及び関係を示す説明図である。コンテンツデータベース１５０には、例えば、トピックデータ１５１やブログデータ１５２等のような複数のコンテンツデータを各種類毎にそれぞれ管理している。トピックデータ１５１とは、電子掲示板での書込み内容を示すデータである。

データ処理部１２０は、共通ロジック１２１と複数の個別ロジック１２２とを備えて構成することができる。共通ロジック１２１は、各ＳＮＳ３００に共通する機能を担当するためのものである。個別ロジック１２２は、各ＳＮＳ３００毎の個別の機能を担当するものである。共通ロジック１２１は、例えば、新着ブログを取得する機能、新着トピックを取得する機能、ニュースを取得する機能等を実現する。個別ロジック１２２は、例えば、証券や為替に関する各種指標を取得しグラフ化する機能等のように、各部署に対応するＳＮＳ３００にとって好ましい個別の機能を実現する。

セキュリティ処理部１３０は、データ処理部１２０からの検索要求に応じてコンテンツデータベース１５０を検索し、検索されたコンテンツデータの中から要求元ユーザ（正確には、要求元ウェブページ）に応じたコンテンツデータのみを抽出して、データ処理部１２０に返すようになっている。つまり、セキュリティ処理部１３０は、各ユーザ毎のコンテンツフィルタ１３１をそれぞれ動的に実現することができる。

最上位ＳＮＳ３００内のウェブページが新着ブログの取得を要求すると、共通ロジック１２１は、最上位ＳＮＳで公開可能な新着ブログを全て検出するようにとセキュリティ処理部１３０に指示する。セキュリティ処理部１３０は、コンテンツデータベース１５０に記憶されているブログデータ１５２の中から、最上位ＳＮＳで公開可能な、最近更新されたデータを全て抽出する。

セキュリティ処理部１３０は、セキュリティデータベース１６０に登録されている管理データを用いることにより、最上位ＳＮＳ３００のウェブページに応じたコンテンツフィルタ１３１を生成し、最上位ＳＮＳ３００での利用が許可されているブログデータのみをデータ処理部１２０に送信する。

同様に、中位ＳＮＳ３００及び最下位ＳＮＳ３００の各ユーザのウェブページからコンテンツデータの取得が要求されると、共通ロジック１２１はセキュリティ処理部１３０にコンテンツデータの検索を要求する。セキュリティ処理部１３０は、要求元ウェブページの属性（どのユーザのウェブページか、どの階層に属するウェブページか）に応じたコンテンツフィルタ１３１を生成し、要求元ウェブページに送信が許可されているコンテンツデータのみをデータ処理部１２０に送信する。

従って、図２中にＤ１として示すように、同様の検索要求に対しては、要求元ウェブページの属性にかかわらず、セキュリティ処理部１３０は、ほぼ同量のコンテンツデータを読み出す。しかし、コンテンツフィルタ１３１は、要求元ウェブページに送信可能なコンテンツデータのみを通過させ、その他のコンテンツデータを通過させない。従って、各ＳＮＳ３００のウェブページに配信されるデータ量は、それぞれ相違する。

最上位ＳＮＳは組織全体（全社）に対応しており、全ユーザが最上位ＳＮＳで情報の発信及び取得が可能である。従って、最上ＳＮＳは、参加可能なユーザ数が最も多いため、同一の検索結果Ｄ１に対して、最上位ＳＮＳ３００には比較的多量のデータＤＨが送信される。例えば、部署を越えた趣味の集まりを企画する場合等には、最上位ＳＮＳにおいて全ユーザに向けて情報が発信される。中位ＳＮＳは、例えば事業部に対応しており、参加可能なユーザ数は全ユーザ数の一部となる。従って、同一の検索結果Ｄ１に対して、中位ＳＮＳ３００には中程度のデータＤＭが送信される。最下位ＳＮＳは、例えば事業部内の各部に対応しており、参加可能なユーザ数は中位ＳＮＳのユーザ数の一部となる。従って、同一の検索結果Ｄ１に対して、最下位のＳＮＳ３００には少量のデータＤＬが送信される。

なお、以上の説明は、ＳＮＳの参加可能ユーザ数とコンテンツデータの生産量とが略比例すると考えた場合である。実際には、各ユーザ毎にＳＮＳへの参加意欲はそれぞれ相違し、また、業務の繁忙の程度等によっても、各ＳＮＳで生産されるコンテンツデータ量は相違する。

図３は、コンテンツデータベース１５０の詳細及びセキュリティデータベース１６０との関係を示す説明図である。コンテンツデータベース１５０は、例えば、トピックデータ１５１やブログデータ１５２のように、コンテンツの種類毎にデータを管理する。各コンテンツデータは、例えば、ユーザＩＤと、データ本体と、作成時刻と、公開範囲と、別ファイルへのパス情報と、その他の情報とを備えて構成される。

ユーザＩＤ（Identification）とは、各ＳＮＳ３００に参加するユーザをそれぞれ識別するための情報である。本システム内で一意に特定できるように、各ユーザには予めユーザＩＤが設定される。データ本体とは、コンテンツデータの内容を示すものであり、例えばテキストデータ等から構成される。作成時刻とは、そのコンテンツデータが作成された時刻を示す情報である。公開範囲とは、コンテンツデータを階層化ＳＮＳ内で公開する範囲を規定する情報である。公開範囲の欄には、後述の公開管理マスタ１６３の公開ＩＤを示す値が設定される。別ファイルへのパス情報とは、例えば、データ本体と共に表示される画像データ、データ本体と共に演奏される音楽データ等の所在を示す情報である。その他の情報としては、例えば、同一種類の各コンテンツデータをそれぞれ識別するためのシーケンシャル番号、データサイズ等の情報を挙げることができる。

図３の下側には、セキュリティデータベース１６０に含まれる各管理データ１６１，１６２，１６３が示されている。各管理データ１６１〜１６３の詳細は後述するが、ユーザＩＤを介して、コンテンツデータとユーザ管理マスタ１６２とは対応付けられており、公開ＩＤを介して、コンテンツデータと公開管理マスタ１６３とは対応付けられている。また、各ＳＮＳ３００を識別するためのＳＮＳＩＤを介して、ＳＮＳ階層管理マスタ１６１は、ユーザ管理マスタ１６２及び公開管理マスタ１６３にそれぞれ対応付けられる。

図４は、ＳＮＳ階層管理マスタ１６１の構成を示す説明図である。ＳＮＳ階層管理マスタ１６１は、階層化されたＳＮＳの構造を管理するためのものである。ＳＮＳ階層管理マスタ１６１は、例えば、ＳＮＳＩＤと、ＳＮＳ名と、上位ＳＮＳＩＤと、その他の情報とを備えて構成される。

上述の通り、ＳＮＳＩＤは、本システム内で各ＳＮＳ３００を一意に識別するための情報である。ＳＮＳ名とは、そのＳＮＳ３００の名称である。例えば、最上位ＳＮＳには「全社」、中位レベルＳＮＳには「○○事業部」や「○○カンパニー」、最下位ＳＮＳには「○○部」や「○○課」のような、実組織の名称を設定することができる。４階層の場合、全社ＳＮＳ、役員用ＳＮＳ、各事業部用ＳＮＳ、各部用ＳＮＳのように、構成することもできる。

上位ＳＮＳＩＤとは、そのＳＮＳ３００の直系上位に位置するＳＮＳ３００を特定するためのＩＤである。上位のＳＮＳは、親ＳＮＳと呼ぶこともできる。なお、下位ＳＮＳは子ＳＮＳと呼ぶこともできる。このように、各ＳＮＳ３００の連結関係を管理することにより、ＳＮＳ３００の上位及び下位にどのＳＮＳ３００が存在するかを把握することができる。

図５は、ユーザ管理マスタ１６２の構成を示す説明図である。ユーザ管理マスタ１６２は、各ＳＮＳ３００に参加する各ユーザを管理するためのものである。ユーザ管理マスタ１６２は、例えば、ユーザＩＤと、初期所属先ＳＮＳと、移動可能範囲と、その他の情報とを備えて構成することができる。

初期所属先ＳＮＳとは、そのユーザが実際に属する実組織に対応するＳＮＳ３００を特定するための情報である。図５中では、理解の容易のために初期所属先ＳＮＳをＳＮＳ名称で表しているが、実際には、そのユーザの属するＳＮＳ３００を特定するＳＮＳＩＤが設定される。初期所属先ＳＮＳとは、そのユーザが本システムにログインしたときに最初に参加するＳＮＳである。以下の説明では、初期所属先ＳＮＳをホームＳＮＳと呼ぶ場合がある。本システムにユーザがログインすると、そのユーザは、ホームＳＮＳに配置される。ユーザは、ホームＳＮＳの直系上位に位置するＳＮＳと、ホームＳＮＳの直系下位に位置するＳＮＳとを結ぶ直系経路上で、各ＳＮＳ間を移動することができる。

移動可能範囲とは、そのユーザが移動可能なＳＮＳの範囲を示す情報であり、「アクセス権限」に該当する。各ユーザは、移動可能範囲に設定された範囲内で、階層化された各ＳＮＳを移動可能である。図５中では、便宜上、移動可能な範囲を「−（制限なし）」、「１つ上まで」、「上位への移動禁止」等のように、相対的に表現している。これに代えて、移動可能なＳＮＳ３００のＳＮＳＩＤを明示的に設定する構成でもよい。その他の情報としては、例えば、ユーザの設定するパスワードのようなユーザ認証情報、ユーザの氏名、ユーザの所属する実組織名、ユーザの役職等を挙げることができる。

図６は、公開管理マスタ１６３の構成を示す説明図である。公開管理マスタ１６３は、コンテンツデータベース１５０に記憶されている各コンテンツデータを公開する範囲、つまり、そのコンテンツデータを利用可能なユーザのウェブページの範囲を管理するためのものである。公開管理マスタ１６３は、例えば、公開ＩＤと、公開対象ＳＮＳと、公開範囲と、その他の情報とを含んで構成される。

公開ＩＤとは、公開の種類を特定するための情報である。本実施例では、各ＳＮＳ３００毎にそれぞれ「限定公開」または「全体公開」のいずれかの値を設定可能である。従って、ＳＮＳ３００の数に２を乗じた数だけ公開の種類が存在する。公開対象ＳＮＳとは、コンテンツデータを公開するＳＮＳ３００を特定するための情報である。なお、図６では、便宜上ＳＮＳ名で示しているが、実際には、コンテンツデータを公開するＳＮＳのＩＤが設定される。公開範囲とは、コンテンツデータを公開する範囲、即ち公開のレベルを示す情報である。

上述の通り、本実施例では、「限定公開」または「全体公開」のいずれかを選択することができる。限定公開とは、ＳＮＳＩＤで特定されるＳＮＳをホームＳＮＳとするユーザに限って公開されることを意味する。但し、ユーザの属性（地位）が当該ＳＮＳをホームＳＮＳとするユーザの属性（地位）を上回っている場合、その高位ユーザは、下位ＳＮＳ内で限定公開されている情報にアクセス可能である。例えば、事業部長は、ホームＳＮＳの下位に位置する各部のＳＮＳに移動することにより、各部で限定公開された各種の情報を閲覧したり、あるいは情報を発信することができる。また、後述のように、特権を与えられたユーザは、そのＳＮＳがホームＳＮＳではない場合でも、限定公開されたコンテンツデータの取得が可能となるように構成することもできる。

これに対し、全体公開とは、そのＳＮＳに位置する全ユーザに対して公開されることを意味する。即ち、全体公開に設定されている場合、そのＳＮＳをホームＳＮＳとしないユーザであっても、そのＳＮＳに移動することにより、そのコンテンツデータを取得することができる。直系の経路上を移動する各ユーザは、移動先のＳＮＳにおいて、全体公開に設定されたコンテンツデータを閲覧等することができ、また、移動先ＳＮＳにおいてコメントの投稿等を行うことができる。このような一時的滞在者であるユーザが移動先ＳＮＳにおいて発信した情報は、基本的に全体公開されたものとして取り扱われる。

図７は、階層化されたＳＮＳ３００間をユーザが移動する様子を示す説明図である。図９中の上側には最上位ＳＮＳ３００（Ｈ）で提供されるウェブページＰＨの例が、中央部には中位ＳＮＳ３００（Ｍ１，Ｍ２）で提供されるウェブページＰＭの例が、下側には最下位ＳＮＳ３００（Ｌ１〜Ｌ４）で提供されるウェブページＰＬの例が、それぞれ示されている。

便宜上、各ウェブページＰＨ〜ＰＬを同様な構成として示すが、上述のように、各ウェブページＰＨ〜ＰＬは、それぞれ個別の画面構成を備えることができる。領域Ａ１には、例えば、操作メニュー等が配置される。また、領域Ａ１には、ＳＮＳの階層ツリーを移動するために使用するボタンＢ１，Ｂ２のいずれか又は両方が設けられる。上位移動ボタンＢ１は、直系上位に位置するＳＮＳへ移動するための指示部であり、下位移動ボタンＢ２は、直系下位に位置するＳＮＳへ移動するための指示部である。

最上位ＳＮＳ３００（Ｈ）が提供するウェブページＰＨは、上位移動ボタンＢ１を備えておらず、最下位ＳＮＳ３００（Ｌ１〜Ｌ４）が提供するウェブページＰＬは、下位移動ボタンＢ２を備えない。最上位ＳＮＳ３００（Ｈ）と最下位ＳＮＳ３００（Ｌ１〜Ｌ４）との中間に位置するＳＮＳ（Ｍ１，Ｍ２）により提供されるウェブページＰＭのみが、両方のボタンＢ１，Ｂ２を備えることができる。

領域Ａ２には、例えば、ブックマーク、ブログ、ＢＢＳのような各種コンテンツデータが表示される。また、領域Ａ２には、例えば、そのユーザのプロフィール、そのＳＮＳに参加しているユーザの一覧、そのユーザの参加するコミュニティの一覧等を表示させることもできる。ブックマークとは、例えば、URL（Uniform Resource Locator）のような、ウェブ上のコンテンツリソースの所在を示す情報である。

領域Ａ３には、そのＳＮＳをホームＳＮＳとするユーザに限定して公開されているコンテンツデータ、つまり、例えば、議事録や帳簿のような、そのＳＮＳに対応する実組織内で機密扱いになっている情報が表示される。

図７の左側に実線矢印で示すように、ユーザは、上位移動ボタンＢ１を操作することにより、一つ上の階層に位置するＳＮＳ３００に移動可能である。ユーザは、移動先のＳＮＳ３００において、全体公開扱いで情報を発信したり、全体公開に設定された情報を取得することができる。さらに上位のＳＮＳへの移動を希望する場合、ユーザは、移動先ＳＮＳのウェブページに表示されている上位移動ボタンＢ１を操作する。但し、ユーザは、ユーザ管理マスタ１６２によって設定されている範囲内でのみ移動することができる。

下り方向についても同様である。ユーザは、下位移動ボタンＢ２を操作することにより、一つ下の階層のＳＮＳ３００に移動可能である。ユーザは、移動先のＳＮＳ３００において、情報の発信及び情報の取得を行うことができる。さらに下位のＳＮＳへの移動を希望する場合、ユーザは、移動先ＳＮＳのウェブページに表示されている下位移動ボタンＢ２を操作する。

このように、ユーザは、ボタンＢ１，Ｂ２を操作することにより、直系の経路上を順番に、ＳＮＳ階層を辿って移動することができる。なお、これに代えて、例えば、ＳＮＳ階層構造を模したツリー型の移動メニューをウェブページ中に図形表示し、この移動メニューを操作することにより、目的のＳＮＳに直接移動する構成としても良い。また、音声認識技術を用いて、音声によるコマンド入力でＳＮＳ間を移動する構成でも良い。

図８は、ＳＮＳで情報を発信する場合の画面例を示す説明図である。ブログのエントリを作成する場合を例に挙げて説明する。ブログ作成画面５００は、例えば、ＳＮＳ名表示欄５０１と、操作メニュー５０２と、エントリタイトル欄５０３と、本文記入部５０４と、画像添付部５０５と、公開範囲設定部５０６と、投稿操作部５０７等とを備えて構成される。

公開範囲設定部５０６には、限定公開を指定するための設定部５０６Ａと、全体公開を指定するための設定部５０６Ｂとが設けられている。図８では、紙面の都合上、そのＳＮＳをホームＳＮＳとしない一時的なユーザを「ビジター」と示す。

情報を発信するユーザは、いずれかの設定部５０６Ａ，５０６Ｂを用いて、ブログエントリの公開範囲を選択する。選択された公開範囲は、ブログのエントリのデータ本体に対応付けられてコンテンツデータベース１５０に記憶される。より詳しくは、そのエントリの作成されたＳＮＳがどれであるか、及び、限定公開と全体公開のいずれが選択されたかに基づいて、公開管理マスタ１６３が参照され、作成元ＳＮＳと公開範囲の組合せに対応する公開ＩＤが一つ選択される。そして、選択された公開ＩＤは、エントリを作成したユーザのユーザＩＤ等と共にエントリのデータ本体に対応付けられて、コンテンツデータベース１５０に記憶される。

ここで、留意すべき点は、公開範囲設定部５０６には、２つの設定部５０６Ａ，５０６Ｂの両方が常に表示されるとは限らない点である。即ち、ブログエントリを作成するユーザの属性や、作成元ＳＮＳの階層構造上の位置に応じて、設定部５０６Ａ，５０６Ｂのいずれか一方または両方が、公開範囲設定部５０６に表示される。ユーザは、限定公開するか全体公開するかを常に選択できるわけではなく、ＳＮＳ提供装置１００によって許可された場合にのみ、限定公開とするか全体公開とするかを選択できる。

そのＳＮＳをホームＳＮＳとするユーザは、全体公開とするか限定公開とするかを選択可能であるが、そのＳＮＳをホームＳＮＳとしないユーザ（ビジター）は、基本的に、限定公開を選択することはできない。但し、そのＳＮＳをホームＳＮＳとしないユーザであっても、そのホームＳＮＳの下位に位置するＳＮＳにおいては、限定公開された情報にアクセス可能である。

図９は、ユーザがＳＮＳに参加し、ＳＮＳ間を移動する場合の処理を示すフローチャートである。なお、本フローチャートを含む下記の各フローチャートは、本発明の理解及び実施に必要な範囲で処理の概要を示しており、実際のコンピュータプログラムとは相違する場合がある。いわゆる当業者であれば、フローチャート中のステップの実行順序を入れ替えたり、ステップを削除したり、新たなステップを追加したり、他のステップに入れ替えたりすることができる場合もあろう。

ユーザは、ユーザ端末２００を用いて、自分の属する実組織に対応するホームＳＮＳにアクセスし、ログインする（Ｓ１０）。ホームＳＮＳは、ユーザ管理マスタ１６２を用いて、ユーザ認証を行う（Ｓ１１）。ユーザＩＤ及びパスワードによるユーザ認証に限らず、例えば、声紋、虹彩、指紋等の生体情報を用いてユーザ認証を行う構成でもよい。

ユーザ認証が成功すると、ホームＳＮＳは、そのユーザ用のコンテンツデータを取得して、そのユーザ専用のウェブページを生成する（Ｓ１２）。以下の説明では、ユーザ専用のウェブページをユーザページと呼ぶ場合がある。コンテンツデータを取得してウェブページを生成する処理については、図１０と共に後述する。

ホームＳＮＳは、生成したユーザページをユーザ端末２００に送信する（Ｓ１３）。ユーザ端末２００は、ユーザページを受信して端末画面に表示させる（Ｓ１４）。ユーザページには、限定公開されたコンテンツデータや全体公開されたコンテンツデータが表示される。

ユーザは、ユーザページを用いて情報を発信することができる（Ｓ１５）。図８で述べたように、ユーザは、新規に作成したコンテンツデータをコンテンツデータベース１５０に記憶させる際に、公開範囲を設定することができる。

ホームＳＮＳは、ユーザから入力された新たなコンテンツデータをコンテンツデータベース１５０に保存させる（Ｓ１６）。そして、ホームＳＮＳは、新たなコンテンツデータが反映された新たなユーザページを生成し（Ｓ１７）、その新たなユーザページをユーザ端末２００に送信する（Ｓ１８）。ユーザ端末２００は、前記Ｓ１４と同様に、受信した新たなユーザページを端末画面に表示させる（Ｓ１９）。

ユーザは、別のＳＮＳから情報を取得するために、または、別のＳＮＳに情報を発信するために、ＳＮＳ間での移動を希望する（Ｓ２０）。上述の通り、ユーザは、上位移動ボタンＢ１または下位移動ボタンＢ２を用いて、ホームＳＮＳの上位または下位に位置するＳＮＳに移動できる。

ホームＳＮＳは、ユーザからＳＮＳ間の移動を要求されると、ＳＮＳ階層管理マスタ１６１を参照し、移動先ＳＮＳに通知する（Ｓ２１）。移動先ＳＮＳは、ユーザに提供可能なコンテンツデータを取得してユーザページを生成し（Ｓ２２）、生成したユーザページをユーザ端末２００に送信する（Ｓ２３）。

ユーザ端末２００は、前記同様に、移動先ＳＮＳから受信したユーザページを端末画面に表示させる（Ｓ２４）。ユーザは、移動先ＳＮＳにおいて情報を発信することもできる（Ｓ２５）。移動先ＳＮＳは、ユーザ端末２００から入力されたコンテンツデータを保存し（Ｓ２６）、ユーザページを更新してユーザ端末２００に提供する。

このように、ユーザは、ボタンＢ１，Ｂ２を操作することにより、上位または下位に隣接するＳＮＳ間を移動することができ、移動先でユーザ専用のウェブページを得ることができる。

ここで、ユーザは、ホームＳＮＳをログアウトしてから移動先ＳＮＳにログインするのではなく、ホームＳＮＳにログインした状態で、移動先ＳＮＳに一時的に移動可能となっている点に留意すべきである。即ち、本システムでは、ユーザは、最初のユーザ認証を行うだけで、階層化された所定のＳＮＳ間をシームレスに移動することができる。

図１０は、図９のフローチャートで述べたユーザページを作成するステップ（Ｓ１２，Ｓ１７，Ｓ２２）の詳細を示すフローチャートである。ユーザページを生成すべきＳＮＳは、共通ロジック１２１にコンテンツデータの取得を要求する（Ｓ３０）。この取得要求には、どのＳＮＳに位置するどのユーザに向けたコンテンツデータであるかを示す要求元に関する情報やコンテンツデータの種類に関する情報が明示されている。

共通ロジック１２１は、要求元に関する情報及びコンテンツデータの種類を明示して、セキュリティ処理部１３０にコンテンツデータの読出しを要求する（Ｓ３１）。セキュリティ処理部１３０は、要求された種類のコンテンツデータをコンテンツデータベース１５０から全て読出す（Ｓ３２）。

セキュリティ処理部１３０は、要求元に関する情報に基づいてユーザ管理マスタ１６２及び公開管理マスタ１６３を参照し（Ｓ３３）、要求元のユーザが利用可能なコンテンツデータのみを共通ロジック１２１に送信する（Ｓ３４）。なお、説明の便宜上、共通ロジック１２１とセキュリティ処理部１３０が直接的にデータを交換する場合を例に挙げて説明するが、各ＳＮＳに固有の機能を使用する場合には、共通ロジック１２１は個別ロジック１２２を介してセキュリティ処理部１３０とデータを交換する。

共通ロジック１２１は、セキュリティ処理部１３０で選別されたコンテンツデータを受信すると（Ｓ３５）、この選別されたコンテンツデータを要求元のＳＮＳに送信する（Ｓ３６）。ＳＮＳは、共通ロジック１２１からコンテンツデータを受信すると（Ｓ３７）、ＳＮＳに固有のスキン及び機能を確認し（Ｓ３８）、ユーザページを構成するために必要な全てのコンテンツデータが揃ったか否かを判定する（Ｓ３９）。全てのコンテンツデータを取得するまで（S39:NO）、Ｓ３０〜Ｓ３８が繰り返される。そして、ユーザページを構成する全てのコンテンツデータを取得すると（S39:YES）、ＳＮＳは、ユーザページを生成する（Ｓ４０）。なお、ここでは便宜上、全部のコンテンツデータが揃ってからユーザページを作成する場合を述べたが、これに代えて、コンテンツデータの取得とユーザページの作成とを平行して進めることもできる。

図１１は、階層化されたＳＮＳの構成に変化が生じた場合の対応方法を示すフローチャートである。本システムでは、上述の通り、ユーザの属する実組織の階層構成に応じて、組織単位のＳＮＳを階層化している。従って、本システムが提供する階層化ＳＮＳは、実組織に生じる変化に影響される。組織構成の変化としては、例えば、ある部署の廃止、新部署の設立、複数の部署の統合、ある部署が所属する事業部の変更、ある部署から別の部署への人事異動等を挙げることができる。

例えば、そのコンテンツデータにアクセスする権限の無いユーザがそのコンテンツデータを利用したり、不要なコンテンツデータがユーザページに溢れたりするのを防止するために、コンテンツデータの管理方法を変える必要がある。

そこで、本システムの管理者は、組織変更（部署の統廃合等）に応じて、ＳＮＳ階層管理マスタ１６１を更新する（Ｓ５０）。続いて、管理者は、組織変更に応じて、公開管理マスタ１６３を更新する（Ｓ５１）。管理者は、組織変更に伴う人事異動または組織変更とは別の人事異動に応じて、ユーザ管理マスタ１６２を更新する（Ｓ５２）。

このように、管理者は、コンテンツデータに設定されている公開範囲（公開ＩＤ）を修正することなく、コンテンツデータベース１５０とは別のセキュリティデータベース１６０に記憶されている管理データ（各マスタ１６１〜１６３）のみを修正するだけで、組織変更や人事異動に対応することができる。

図１２及び図１３は、ユーザが階層化されたＳＮＳ間を移動する様子を示す説明図である。なお、図１２，図１３では、ウェブページ（ユーザページ）の左側には、そのユーザに固有の情報が示されている。つまり、ユーザがホームＳＮＳの上位または下位に位置するＳＮＳに移動した場合でも、そのユーザのホームＳＮＳで表示されていた情報が移動先ＳＮＳでも表示される。但し、後述の実施例で示すように、移動先のＳＮＳに応じて表示内容を変えることもできる。

図１２は、例えば、上級管理職のような中位ユーザがＳＮＳ間を移動する様子を示す説明図である。中位ユーザは、ホームＳＮＳ３００（Ｍ）が提供するウェブページＰＭに加えて、その上位及び下位に位置する他のＳＮＳ３００（Ｈ），３００（Ｌ）が提供するウェブページＰＨ，ＰＬに移動可能である。中位ユーザは、下位ＳＮＳ３００（Ｌ）に限定して公開されている情報（領域Ａ３の「班会議ＬＣ４」」）にもアクセスすることができる。

図１３は、例えば、一般社員のような下位ユーザがＳＮＳ間を移動する様子を示す説明図である。下位ユーザも中位ユーザと同様に、ホームＳＮＳ３００（Ｌ）で全体公開または限定公開されている情報と、その上位に位置するＳＮＳ３００（Ｍ）で全体公開されている情報とにアクセスすることができる。下位ユーザに提供される上位ウェブページＰＭには、上位ＳＮＳ３００（Ｍ）に限定して公開されている情報（領域Ａ３の「部長会ＭＣ４」）は表示されない。下位ユーザは、ＳＮＳ３００（Ｍ）を経由して、さらに上位のＳＮＳ３００（Ｈ）に移動することができる。

このように構成される本実施例によれば、複数のＳＮＳ３００を階層化し、ユーザが階層化されたＳＮＳ間を移動することができる。従って、例えば、比較的少数のユーザ単位でＳＮＳを階層化することにより、個々のＳＮＳを比較的容易に管理することができ、使い勝手が向上する。また、実社会での信頼関係を反映させてＳＮＳを構築可能であり、ＳＮＳでの活動を活発化させることができる。これにより、情報の共有、情報の交換、情報の生産等が円滑に行われ、知的労働の生産性を高めることができる。

さらに、比較的小規模のＳＮＳを階層化して連結し、情報（コンテンツデータ）の流通する範囲を制御する構成のため、そのＳＮＳに参加するユーザにとって不要な情報がＳＮＳを満たすというような事態を防止できる。従って、ユーザは、有用な情報に速やかにアクセスすることができ、これにより知的労働の生産性が向上する。

本実施例では、ユーザの属する実組織に対応して各ＳＮＳを構築し、実際の組織同士により構成される階層構造に対応させて各ＳＮＳを階層化して接続させており、かつ、情報の公開範囲を複数段階（限定公開及び全体公開）で制御可能な構成である。従って、実組織で顔見知りのユーザ同士が信頼関係をもってＳＮＳ活動を活発に行うことができ、実組織に応じた範囲で情報の発信及び情報の取得を行うことができる。これにより、ユーザは、自分の属する実組織への帰属意識、仲間意識を高めることができる。

本実施例では、各ＳＮＳは個別の画面構成を採用可能な構成とした。従って、実組織の業務に適した画面構成を採用でき、より一層生産性を高めることができる。

本実施例では、階層化されたＳＮＳ間をユーザが移動する場合に、そのユーザの属性及び現在位置するＳＮＳに応じて、情報にアクセス可能な範囲を制御する。従って、情報漏洩等が生じる可能性を低減でき、システムの信頼性を高くすることができる。

本実施例では、各ＳＮＳで使用されるコンテンツデータをコンテンツデータベース１５０で一元管理し、コンテンツデータの生産及び利用を制御するための管理データをコンテンツデータベース１５０とは別のセキュリティデータベース１６０で管理する。従って、実組織の変化や人事異動を階層化ＳＮＳに反映させる場合に、セキュリティデータベース１６０内の管理データだけを修正すればよい。従って、実組織の変動や人事異動に速やかに対応させてＳＮＳを運用することができ、管理の手間も削減できる。

本実施例では、データ処理部１２０を共通ロジック１２１と個別ロジック１２２とから階層化して構成する。従って、実組織の変動があった場合でも、共通ロジック１２１を修正する必要は殆どなく、一部の個別ロジック１２２のみを修正するだけで、新組織に対応したＳＮＳを構築することができる。

図１４，図１５に基づいて、第２実施例を説明する。本実施例を含む以下の各実施例は、第１実施例の変形例に該当する。本実施例では、実組織の変動や人事異動に応じて階層化ＳＮＳの構成が変化する場合に、コンテンツデータの種類に応じて管理方法を変えるようになっている。

図１４は、階層化ＳＮＳの構成を変えるための処理を示すフローチャートである。本システムの管理者は、ＳＮＳ階層管理マスタ１６１、公開管理マスタ１６３及びユーザ管理マスタ１６２をそれぞれ更新する（Ｓ５０，Ｓ５１，Ｓ５２）。さらに、管理者は、コンテンツデータの種類に応じて、コンテンツデータ中の公開範囲（公開ＩＤ）を変更する（Ｓ５３）。

図１５は、コンテンツデータの種類に応じて、コンテンツデータ内の公開範囲を変える様子を示す説明図である。例えば、最下位ＳＮＳ３００（Ｌ１）から最下位ＳＮＳ３００（Ｌ２）に、あるユーザが異動した場合、コンテンツデータの一部は異動先のＳＮＳ３００（Ｌ２）に引き継がれ、残りのコンテンツデータは異動元のＳＮＳ３００（Ｌ１）に残される。例えば、ブックマーク及びブログのデータは、異動先のＳＮＳ３００（Ｌ２）内のコンテンツデータとして移し、トピックデータは異動元のＳＮＳ３００（Ｌ１）内のコンテンツデータとして残しておくことができる。

ＳＮＳ内のコンテンツデータを、例えば、その作成者であるユーザ個人に帰属する性質を備えるコンテンツデータ（ブログ等）と、ユーザの属する実組織に帰属する性質を備えるコンテンツデータ（トピック等）とに分類する場合、ユーザへの帰属性の高いコンテンツデータは異動先ＳＮＳに移し、組織への帰属性が高いコンテンツデータは異動元ＳＮＳに残しておくことができる。どの種類のコンテンツデータをユーザ個人に帰属させ、どの種類のコンテンツデータを組織に帰属させるかは、予め設定される。

このように構成される本実施例も前記第１実施例と同様の効果を奏する。さらに、本実施例では、コンテンツデータの種類に応じて、コンテンツデータ内の公開範囲を修正するため、ユーザの使い勝手を高めることができる。

図１６に基づいて第３実施例を説明する。本実施例では、図１６に示す滞在監視処理により、ＳＮＳ間を移動して一時的に滞在するユーザを定期的に監視する。ＳＮＳ提供装置１００は、所定時間毎に、ＳＮＳに一時的に滞在しているユーザについてユーザ管理マスタ１６２を参照し、そのアクセス権限を確認する（Ｓ６０）。

ＳＮＳ提供装置１００は、そのユーザにアクセス権限が無いと判断した場合（S60:YES）、エラーメッセージを出力し（Ｓ６２）、そのユーザを所属ＳＮＳに強制的に復帰させる（Ｓ６３）。

ユーザ管理マスタ１６２には、移動可能なＳＮＳの範囲に加えて、移動条件または滞在条件も設定されている。例えば、本システムでは、所定時間だけ移動先での滞在を許可したり、所定回数だけＳＮＳ間の移動を許可したり、所定期間だけＳＮＳ間の移動を許可したりすることができる。これにより、例えば、ユーザの属性（正社員、パート、派遣社員、協力会社の社員等）に応じてＳＮＳ間の移動を適切に制御することができ、使い勝手が向上する。

図１７に基づいて第４実施例を説明する。本実施例では、ユーザが階層化されたＳＮＳ間を移動する際に、移動先ＳＮＳのウェブページ中に、ホームＳＮＳのウェブページで表示されている情報を引き続き表示させる。

図１７の領域Ａ２の左側に示す部分には、例えば、ユーザのプロフィール、ホームＳＮＳのメンバーリスト、ホームＳＮＳのコミュニティリスト等の所定情報が表示される。この所定情報は、そのユーザの移動先ウェブページでもそのまま引き続き表示される。

例えば、メンバーリストの表示欄がインスタントメッセンジャーのような構成を備える場合、ユーザは移動先ＳＮＳにおいてもシームレスに友人等と連絡を取り合うことができ、ユーザの使い勝手が向上する。同様に、所定情報としてオンライン会議機能やチャット機能等が含まれる場合、ユーザは、オンラインによる会議を中断することなく、ＳＮＳ間を移動することができる。

図１８，図１９に基づいて本発明の第５実施例を説明する。本実施例では、一部のユーザに「特権」を与えることにより、同位の他のユーザよりも情報発信及び情報取得の範囲を広げる。

図１８は、ＳＮＳに情報を発信する場合の処理を示すフローチャートである。ユーザから情報発信の要求を受けると、本処理は開始される。ＳＮＳ提供装置１００は、ユーザ管理マスタ１６２Ａを参照して、情報の発信を希望するユーザに特権が与えられているか否かを確認する（Ｓ７０）。ユーザ管理マスタ１６２Ａには、特権を利用可能なＳＮＳに関する情報が加えられている。

ユーザが特権を有する場合（S71:YES）、ＳＮＳ提供装置１００は、その特権ユーザによる情報の公開範囲を選択可能とする（Ｓ７２）。即ち、特権ユーザが掲示板に投稿等する場合に、その投稿を限定公開とするか全体公開とするかの選択肢が、特権ユーザに与えられる。これに対し、ユーザが特権を有さない場合（S71:NO）、ＳＮＳ提供装置１００は、そのユーザによる情報発信の公開範囲を全体公開のみとし、選択の余地を与えない（Ｓ７３）。

図１９は、階層化されたＳＮＳ間をユーザが移動する場合の処理を示すフローチャートである。この移動制御処理は、ユーザからＳＮＳ間の移動を要求されると開始する。まず、ＳＮＳ提供装置１００は、ＳＮＳ階層管理マスタ１６１を参照し、移動先ＳＮＳを確認する（Ｓ８０）。

ＳＮＳ提供装置１００は、移動先として指定されたＳＮＳが現在のＳＮＳの下位に位置するＳＮＳであるか否かを判定する（Ｓ８１）。移動先として指定されたＳＮＳが下位ＳＮＳではない場合（S81:NO）、ＳＮＳ提供装置１００は、そのユーザが特権を有するか否かを判定する（Ｓ８２）。特権ユーザの場合（S82:YES）、Ｓ８４に移る。特権ユーザではない場合（S82:NO）、エラー処理が行われる（Ｓ８３）。エラー処理では、例えば、「このＳＮＳに移動する権限がありません。管理者にお問い合わせ下さい。」等のエラーメッセージをユーザに通知する。

一方、移動先が下位ＳＮＳであると判定された場合（S81:YES）、ＳＮＳ提供装置１００は、移動先ＳＮＳに応じた全てのコンテンツデータの取得を要求する（Ｓ８４）。そして、ＳＮＳ提供装置１００は、特権ユーザであるか否かを判定し（Ｓ８５）、特権ユーザの場合（S85:YES）、移動先ＳＮＳで閲覧可能な全てのコンテンツデータを、特権ユーザ用のウェブページ（移動先ＳＮＳから一時的に提供されるウェブページ）に表示させる（Ｓ８６）。

特権ユーザではない場合（S85:NO）、ＳＮＳ提供装置１００は、移動先ＳＮＳに関する全てのコンテンツデータの中から、その移動先ＳＮＳに限定して公開されているコンテンツデータを除去し（Ｓ８７）、全体公開されているコンテンツデータのみをユーザに利用させる（Ｓ８８）。

このように構成される本実施例も前記第１実施例と同様の効果を奏する。これに加えて、本実施例では、ユーザに特権を与えることにより、特権ユーザの情報発信範囲及び情報取得範囲を容易に拡張することができる。従って、例えば、監査人や弁護士等に特権を与えることにより、監査業務等を円滑に行うことができる。

図２０に基づいて第６実施例を説明する。本実施例では、ユーザの移動可能なＳＮＳで情報が更新された場合、その旨をユーザに通知する。図２０は、更新通知処理を示すフローチャートである。ＳＮＳ提供装置１００は、各ＳＮＳでの情報更新をチェックし（Ｓ９０）、いずれかのＳＮＳで情報が更新されたか否かを判定する（Ｓ９１）。

いずれかのＳＮＳで情報が更新された場合（S91:YES）、ＳＮＳ提供装置１００は、情報が更新されたＳＮＳに移動可能なユーザ（ここでは、所定ユーザと呼ぶ）をチェックし（Ｓ９２）、情報の更新されたＳＮＳに所定ユーザが位置しているか否かを判定する（Ｓ９３）。情報の更新されたＳＮＳに所定ユーザが位置していない場合（S93:NO）、ＳＮＳ提供装置１００は、例えば、領域Ａ１内において、情報の更新されたＳＮＳが存在する旨を所定ユーザに通知する（Ｓ９４）。

このように構成される本実施例も前記第１実施例と同様の効果を奏する。さらに、本実施例では、情報の更新されたＳＮＳの存在をユーザに通知するため、ユーザは、更新された情報に速やかにアクセスすることができ、使い勝手が向上する。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、前記各実施例では、コミュニティサイトの一例としてＳＮＳを挙げたが、これに限らず、例えば、二次元または三次元のキャラクタが仮想空間内で情報を交換するコミュニティサイトにも、本発明を適用することができる。

ＳＮＳ提供システムの全体構成を示す説明図である。 データ処理部及びセキュリティ処理部のブロック図である。 コンテンツデータベースを示す説明図である。 ＳＮＳ階層管理マスタを示す説明図である。 ユーザ管理マスタを示す説明図である。 公開管理マスタを示す説明図である。 ＳＮＳ移動に応じてウェブページが変化する様子を示す説明図である。 ＳＮＳに情報を発信する場合の画面例を示す説明図である。 ＳＮＳ間を移動して情報の発信及び取得を行う様子を示すフローチャートである。 ユーザ属性等に応じてユーザ用のウェブページを生成する様子を示すフローチャートである。 組織変更等に応じてコンテンツデータの管理方法を変える様子を示すフローチャートである。 中位ユーザがＳＮＳ間を移動する様子を示す説明図である。 下位ユーザがＳＮＳ間を移動する様子を示す説明図である。 第２実施例に係るＳＮＳ提供システムで実行される、コンテンツデータの管理方法を変える様子を示すフローチャートである。 コンテンツデータの種類に応じて、一部のコンテンツデータが移動先ＳＮＳに引き継がれ、残りのコンテンツデータが移動元ＳＮＳに残される様子を示す説明図である。 第３実施例に係るＳＮＳ提供システムで実行される、ユーザの滞在監視処理を示すフローチャートである。 第４実施例に係るＳＮＳ提供システムで実行される、ウェブページの変化を示す説明図である。 第５実施例に係るＳＮＳ提供システムで実行される、ＳＮＳへの情報発信処理を示すフローチャートである。 ＳＮＳ間での移動を制御する処理を示すフローチャートである。 第６実施例に係るＳＮＳ提供システムで実行される、更新通知処理を示すフローチャートである。

符号の説明

１００…ＳＮＳ提供装置、１１０…階層化ＳＮＳ提供部、１２０…データ処理部、１２１…共通ロジック、１２２…個別ロジック、１３０…セキュリティ処理部、１３１…コンテンツフィルタ、１４０…検索処理部、１５０…コンテンツデータベース、１６０…セキュリティデータベース、１６１…ＳＮＳ階層管理マスタ、１６２，１６２Ａ…ユーザ管理マスタ、１６３…公開管理マスタ、２００…ユーザ端末、３００…ＳＮＳ、３１０…個別フロント提供機能、５００…ブログ作成画面、５０６…公開範囲設定部、５０６Ａ…限定公開設定部、５０６Ｂ…全体公開設定部、Ｂ１…上位移動ボタン、Ｂ２…下位移動ボタン、ＰＨ〜ＰＬ…各レベルのＳＮＳからユーザに与えられる専用のウェブページ。

Claims (15)

1. 各ユーザ毎にそれぞれ生成されるウェブページを前記各ユーザ間で相互に連結して構成されるコミュニティサイトを複数提供するためのコミュニティサイト提供システムであって、
   複数の前記コミュニティサイトを階層化して提供するコミュニティサイト提供部と、
   前記各コミュニティサイトで使用されるデータを記憶するデータ記憶部と、
   前記各コミュニティサイトからの要求に応じてデータ処理を実行し、その処理結果を要求元のコミュニティサイトに送信するデータ処理部と、
   前記データ処理部からの要求に応じて前記データ記憶部からデータを取得し、取得したデータを前記データ処理部に送信するデータ入出力管理部と、を備え、
   前記コミュニティサイト提供部は、前記データ処理部から受信した前記処理結果に基づいて前記各コミュニティサイトの各ユーザ毎のウェブページをそれぞれ生成し、かつ、前記各コミュニティサイトのうち予め設定された範囲内のコミュニティサイト間で、ユーザの移動を許可するコミュニティ提供システム。
2. 前記コミュニティサイト提供部は、前記各ユーザが最初に所属する初期所属先コミュニティサイトと直系上位または直系下位の関係にある所定コミュニティサイト間で、前記各ユーザの移動を許可する請求項１に記載のコミュニティサイト提供システム。
3. 前記コミュニティサイト提供部は、前記ユーザの属する前記コミュニティサイトの階層構造上の位置及び前記ユーザの属性に応じて、情報の発信範囲または情報の取得範囲のうち少なくともいずれか一方を制御する請求項１に記載のコミュニティサイト提供システム。
4. 前記コミュニティサイト提供部は、前記各ユーザが現在所属する前記コミュニティサイト内で、前記各ユーザに情報の発信または情報の取得を許可するように制御する請求項２又は請求項３のいずれか一項に記載のコミュニティサイト提供システム。
5. 前記コミュニティサイト提供部は、前記ユーザに設定されているアクセス権限に基づいて、前記各コミュニティサイト間の移動を制御する請求項１に記載のコミュニティサイト提供システム。
6. 前記コミュニティサイト提供部は、前記所定コミュニティサイトまたは前記初期所属先コミュニティサイトのいずれかにおいて情報が発信された旨を、前記各ユーザが現在所属するコミュニティサイト内で通知する請求項２に記載のコミュニティサイト提供システム。
7. 前記データ記憶部は、前記各コミュニティサイトでそれぞれ使用されるデータを一元管理しており、
   前記データ入出力管理部は、前記データ処理部からの要求に応じて前記データ記憶部から取得したデータのうち、要求元ユーザに応じたデータのみを前記データ処理部に送信する請求項１に記載のコミュニティ提供システム。
8. 前記各コミュニティサイトの階層構造に関する構造情報と、前記ユーザが前記各コミュニティサイトから情報を取得可能な範囲及び前記ユーザが前記各コミュニティサイトに情報を発信可能な範囲を制御するための管理情報とは、前記データ記憶部にそれぞれ記憶されている請求項１に記載のコミュニティサイト提供システム。
9. 前記構造情報及び前記管理情報は、前記ウェブページの生成に使用するコンテンツデータとは別に前記データ記憶部に記憶されており、かつ、前記管理情報と前記コンテンツデータとは対応付けられている請求項８に記載のコミュニティサイト提供システム。
10. 前記コンテンツデータの属性に応じて前記管理情報の所定の一部を更新することにより、前記コンテンツデータが前記ユーザによって取得可能な範囲を制御する請求項９に記載のコミュニティサイト提供システム。
11. 前記各コミュニティサイトは、前記各ユーザの属する各実組織に対応してそれぞれ構成されており、前記コミュニティサイト提供部は、前記各実組織により形成される階層構造に応じて、前記各コミュニティサイトを階層化して提供する請求項１に記載のコミュニティサイト提供システム。
12. 各ユーザ毎にそれぞれ生成されるウェブページを前記各ユーザ間で相互に連結して構成されるコミュニティサイトを複数提供するための方法であって、
    複数の前記コミュニティサイトを階層化して提供するステップと、
    前記ユーザが現在所属するコミュニティサイト及び前記ユーザの属性に応じて、データ記憶部に記憶されているコンテンツデータを全て検出するステップと、
    前記検出されたコンテンツデータのうち前記ユーザに予め許可されている所定のコンテンツデータのみを取得するステップと、
    前記取得された所定のコンテンツデータによって前記ユーザ用のウェブページを生成するステップと、
    前記生成されたウェブページを、前記ユーザの使用するユーザコンピュータが備える情報出力装置に出力させるステップと、
    前記ユーザが前記所属コミュニティサイトから別のコミュニティサイトへの移動を希望した場合には、前記ユーザの属性に応じて移動を許可するステップと、
    をそれぞれ実行するコミュニティサイト提供方法。
13. 前記ユーザコンピュータから入力された新たなコンテンツデータを、前記ユーザの属性により定まる公開レベルに対応付けて、前記データ記憶部に記憶させるステップを、さらに備える請求項１２に記載のコミュニティサイト提供方法。
14. 前記各コミュニティサイトは、前記各ユーザの属する各実組織に対応して階層化して構成されており、
    前記ユーザの属性に応じて移動を許可するステップは、前記各ユーザが最初に所属する初期所属先コミュニティサイトと直系上位または直系下位の関係にある所定コミュニティサイト間で、前記各ユーザの移動を許可する請求項１２に記載のコミュニティサイト提供方法。
15. コンピュータ上に、各ユーザ毎にそれぞれ生成されるウェブページを前記各ユーザ間で相互に連結して構成されるコミュニティサイトを複数生成させるためのコンピュータプログラムであって、
    複数の前記コミュニティサイトを階層化して提供する機能と、
    前記各コミュニティサイトで使用されるコンテンツデータをデータ記憶部に記憶させる機能と、
    前記ユーザが現在所属するコミュニティサイトに応じて、前記データ記憶部に記憶されている前記コンテンツデータを検出する機能と、
    前記検出されたコンテンツデータのうち前記ユーザの属性に応じた所定のコンテンツデータのみを、前記ユーザの位置するコミュニティサイトに送信する機能と、
    前記所定のコンテンツデータに基づいて、前記ユーザ用のウェブページを生成する機能と、
    生成された前記ウェブページを前記ユーザの使用するユーザコンピュータに送信する機能と、
    前記ユーザが前記所属コミュニティサイトから別のコミュニティサイトへの移動を希望した場合には、前記ユーザの属性に応じて移動を許可する機能と、
    をコンピュータ上に実現させるためのコンピュータプログラム。

Images