JP2005228126A - 情報通知方法／プログラム／プログラム記録媒体／装置、サービス管理装置、サービスシステム - Google Patents

Abstract

【課題】 複数のコミュニティから通知情報を受け取るユーザが、通知情報を上手く整理できる方法を提供する。
【解決手段】 クライアント端末３ｂは、ルール情報設定部５０に、ユーザの属するコミュニティの優先度を示すコミュニティラベル情報と、このコミュニティラベル情報をもとにクライアント端末３ｂに送信される通知情報をどのように並べ替えるかを定めるルール情報を入力する。これらはＤＢ６に登録される。クライアント端末３ａがコミュニティサービスサーバ７において更新操作を行うと、コミュニティサービスサーバ７は、ＤＢ６を参照して、クライアント端末３ａの属するコミュニティを構成するユーザのために通知情報を生成し、これを通知情報テーブル５１に蓄積する。キュー操作処理部５２は、クライアント端末３ｂからポーリングを受信すると、ＤＢ６のルール情報とコミュニティラベル情報をもとに通知情報を並べ替えて送信する。
【選択図】 図１

Description

本発明は、複数のユーザからなるグループ、フォーラム、サークルなど（以下、コミュニティ）のメンバ（以下、コミュニティメンバ）が、インターネットなどのネットワークを介して行うコミュニケーション活動（以下、コミュニティ活動）に用いるツールをユーザに提供するサービス（以下、コミュニティサービス）に関する。

複数のユーザからなるコミュニティのメンバに、インターネットなどのネットワークを介して行うコミュニティ活動のツールを提供するいわゆるコミュニティサービスとして、ネットワーク上の伝言板、掲示板、チャット、メーリングリスト、スケジューラ、共有ファイル、インスタントメッセンジャーなどのツールを用いた様々なものがある（例えば、特許文献１から３を参照）。

一般に、コミュニティサービスを実現するためのシステム（以下、コミュニティサービスシステム）を構築する場合、ユーザの操作する端末がポーリングなどにより自分宛てに送付される通知情報のすべてを取得することが、システムの設計の前提となっている（例えば、特許文献４から６を参照）。
特開２００２−２４１０５号公報 特開２００２−１４０４４３号公報 特開２００２−１８３１５５号公報 特開平５−３５６３１号公報 特開平５−４８６５０号公報 特開平５−３２７７３４号公報

しかしながら、一度に大量の通知情報が送付される場合、重要度の高い通知情報が、受信側のユーザにとっては重要度の低い通知情報に紛れてしまうおそれもあり、必要な通知情報を探し出すのに手間がかかる、あるいは、見落としてしまうといった問題があった。かかる問題は、コミュニティサービスが多様化・大規模化すればするほど、深刻になると思われる。

そこで、本発明の目的は、複数のコミュニティから通知情報を受け取るユーザが、膨大な通知情報を上手く整理できる方法を提供することにある。

上記目的を達成するために、本発明は、情報通知装置を設け、この情報通知装置が、複数のユーザによって構成されたコミュニティに対してコミュニケーション用ツールを提供するコミュニティサービスサーバが生成した通知情報を、ユーザによって操作されるクライアント端末装置に送信する。

情報通知装置は、コミュニティサービスサーバから、このコミュニティサービスサーバが生成した通知情報と、当該通知情報の宛先であるコミュニティの識別子を受信し、これをユーザごとに蓄積する。

そして、情報通知装置は、通知情報を受け取るユーザが属する複数のコミュニティの優先度を示すコミュニティラベル情報と、このコミュニティラベル情報にもとづいて、当該ユーザのために蓄積された通知情報をどのように並べ替えるか、および／または、絞り込むかを定めるルール情報とを参照して、コミュニティの識別子をもとに、当該ユーザのために蓄積された通知情報を並べ替え、および／または、絞り込み、ネットワークを介して、当該ユーザの操作するクライアント端末装置に送信する。

上記コミュニティラベル情報と、ルール情報は、別途、当該ユーザの操作するクライアント端末装置から登録する。また、ルール情報は、コミュニティラベル情報の他、通知情報の重要度、通知情報の生成日時、通知情報を既に送信済みか否かを示す未通知／既通知情報についても、並べ替えおよび／または絞り込みの方法を定めているのが好ましい。

このようにすると、コミュニティサービスが多様化・大規模化しても、当該ユーザの重視するコミュニティの情報を優先度の高いものから通知することができる。

以上説明したように、本発明によれば、コミュニティや通知情報の重要度にもとづき、コミュニティに関する通知情報を並べ替え、絞り込みして受信することができるため、複数のコミュニティに属している場合であっても、重要な通知情報を見落とすこともなく、大量の通知情報を効率よく受け取ることができる。

また、ルール情報やコミュニティラベル情報は、コミュニティサービス管理サーバで一元的に管理しているため、１台のクライアント端末を複数のユーザで利用する場合であっても、それぞれのユーザ独自のルールや優先順位を指定することができる。

次に、本発明の実施の形態について、図面を参照して詳細に説明する。

図１を参照すると、本発明の一実施形態のコミュニティサービスシステムは、クライアント端末３ａ、３ｂと、情報通知装置５と、データベース（ＤＢ）６と、コミュニティサービスサーバ７を含む。そして、情報通知装置５は、ルール情報設定部５０と、キュー操作処理部５２と、通知情報テーブル５１を含む。

クライアント端末３ａは、ネットワークを介して、コミュニティサービスサーバ７が提供するコミュニティ活動用のツール（ネットワーク伝言板など）に、更新操作（書き込みなど）を行う。この更新操作の際に、当該更新の重要度を設定する。

クライアント端末３ｂは、クライアント端末３ａが属しているコミュニティと同じコミュニティに属しているものとする。クライアント端末３ｂは、ネットワークを介して、情報通知装置５のルール情報設定部５０に、更新通知（クライアント端末３ｂが属しているコミュニティにおいて更新操作があった旨の通知）または更新メッセージ（更新操作された内容そのもの。例えば、書き込みがなされた場合、その書き込みの内容）を取得する際のルール情報、および、クライアント端末３ｂが自己の属する複数のコミュニティに対して付けたラベル（以下、コミュニティラベル情報）を入力する。

ここで、コミュニティラベル情報とは、ユーザが自己の属するコミュニティのそれぞれに対してつけるラベルである。例えば、ユーザが、野球、サッカー、ゴルフに関するコミュニティに属していた場合、それぞれのコミュニティに「野球」、「サッカー」、「ゴルフ」というふうに、それぞれのコミュニティを識別するラベルをつける。また、コミュニティに優先度を設けたい場合、野球に「スポーツ１」、サッカーに「スポーツ２」、ゴルフに「スポーツ３」というふうに、それぞれのコミュニティを識別するラベルをつける。

また、ルール情報とは、更新操作を行ったクライアント端末が当該更新メッセージに付けた重要度や、更新操作を行われた日時（以下、更新日時）や、更新通知または更新メッセージを受け取るクライアント端末が当該更新通知または更新メッセージをまだダウンロードしていないか、それとも既にダウンロードしているかについての情報（未通知／既通知情報）や、上記コミュニティラベル情報をもとに、更新通知または更新メッセージをどのようにして並べ替え、絞り込むかを定める情報である。

例えば、重要度なら、重要度の高い順に並べ替え、所定の重要度以下のものを排除する。更新日時なら、更新日時の古い順に並べ替える。未通知／既通知情報なら、既にダウンロードしているものを排除する。コミュニティラベル情報であれば、コミュニティラベルの優先度の高い順に並べ替えたり、所定の優先度以下のものを排除したりする。他にも、様々なルール情報設定が可能である。また、重要度、更新日時、未通知／既通知情報、コミュニティラベル情報のなかから任意のものを選択して、選択した情報についてのみルール情報設定を行うようにしてもよい。さらに、これら４つに優先順位を設けてもよい。さらに、これら４つ以外についても、ルール情報設定を行ってもよい。

クライアント端末３ｂは、情報通知装置５にポーリングを行って、キュー操作処理部５２によって並べ替えられ、絞り込まれた自己宛ての更新通知または更新メッセージを取得する。取得した更新通知または更新メッセージには、クライアント端末３ａによる更新通知または更新メッセージが含まれる。

また、クライアント端末３ｂは、更新通知を取得する場合には、コミュニティサービスサーバ７にアクセスして、この項新通知に対応する更新メッセージを取得する。

上記では、便宜上、クライアント端末３ａ、３ｂの機能を分けて記載しているが、クライアント端末３ａ、３ｂには、当然、交替可能性があるものとする。すなわち、クライアント端末３ａが更新通知または更新メッセージを取得し、クライアント端末３ｂが更新操作を行うことも当然ありうる。

ルール情報設定部５０は、クライアント端末３ｂによって入力されたルール情報、コミュニティラベル情報をＤＢ６に登録する。通知情報テーブル５１は、コミュニティサービスサーバ７から受け取った、更新通知または更新メッセージを蓄積する。コミュニティサービスサーバ７から送られてくる更新通知または更新メッセージには、更新日時、重要度が付加されている。更新通知または更新メッセージは、コミュニティサービスサーバ７がＤＢ６のユーザ情報、コミュニティ情報を参照することで、宛先となるユーザごとに蓄積される（さらに、コミュニティごとに蓄積されるようにしてもよい）。また、クライアント端末３ｂがポーリングを行って更新通知または更新メッセージを取得することで、更新通知または更新メッセージには未通知／既通知情報が付加される。キュー操作処理部５２は、ＤＢ６のルール情報、コミュニティラベル情報を参照して、通知情報テーブル５１に蓄積された更新通知または更新メッセージを並べ替え、絞り込む。

ＤＢ６は、コミュニティサービスシステムを利用するユーザの情報、コミュニティサービスシステムを利用するユーザによって構成されているコミュニティの情報、コミュニティラベル情報、ルール情報を蓄積している。

コミュニティサービスサーバ７は、更新通知または更新メッセージを、ＤＢ６を参照して、通知情報テーブル５１に蓄積する。すなわち、更新操作が行われたコミュニティを判断し、ＤＢ６を参照して、当該コミュニティに属するユーザを調べる。そして、この更新通知または更新メッセージを、当該コミュニティに属するユーザのために、通知情報テーブル５１に蓄積する。さらに、コミュニティごとに蓄積するようにしてもよい。コミュニティサービスサーバ７によって蓄積される更新通知または更新メッセージには、重要度、更新日時が付加される。重要度は、更新操作を行ったクライアント端末が定めたものである。

図２を参照すると、本実施形態のコミュニティサービスシステムにおいて、クライアント端末３ｂへの更新通知または更新メッセージの送信までの処理の時間的な流れを示すシーケンス図が示されている。図２中の符号２００〜２０９は、図１中の符号２００〜２０９に対応している。

ステップ２００で、クライアント端末３ｂは、情報通知装置５のルール情報設定部５０に、ルール情報、コミュニティラベル情報を送信する。ステップ２０１で、ルール情報設定部５０は、クライアント端末３ｂから受信したルール情報、コミュニティラベル情報を、ＤＢ６に登録する。なお、ステップ２００とステップ２０１は、ステップ２０５と同時に行ってもよい。

ステップ２０２で、クライアント端末装置３ａは、コミュニティサービスサーバ７にアクセスし、自己が属しているあるコミュニティにおいて、ツールの更新操作を行う。その際、当該更新操作の重要度も設定する。ステップ２０３で、コミュニティサービスサーバ７は、ＤＢ６のユーザ情報、コミュニティ情報を参照して、更新操作が行われたコミュニティに属するユーザ（クライアント端末３ｂもその１つ）を割り出し、更新通知または更新メッセージを、ユーザごとに用意する。そして、ステップ２０４で、コミュニティサービスサーバ７は、情報通知装置５の通知情報テーブル５１に、ユーザごとに用意された更新通知または更新メッセージを蓄積する。その際、当該更新通知または更新メッセージのコミュニティＩＤ、更新日時、重要度も付加される。

ステップ２０５で、クライアント端末３ｂは、自己宛ての更新通知または更新メッセージを取得するため、情報通知装置５にポーリングを行う。ステップ２０６で、クライアント端末３ｂからポーリングを受信すると、キュー操作処理部５２は、通知情報テーブル５１に蓄積された、クライアント端末３ｂ宛ての更新通知または更新メッセージを並べ替え、絞り込むため、ＤＢ６から、ルール情報、コミュニティラベル情報を取得する。ステップ２０７で、キュー操作処理部５２は、ルール情報、コミュニティラベル情報、重要度、更新日時、未通知／既通知情報をもとに、通知情報テーブル５１に蓄積された、クライアント端末３ｂ宛ての更新通知または更新メッセージを並べ替え、絞り込む。ステップ２０８で、情報通知装置５は、キュー操作処理部５２が並べ替え、絞り込んだ更新通知または更新メッセージを、クライアント端末３ｂに送信する。この際、送信を行った更新通知または更新メッセージの未通知／既通知情報は、既通知に更新される。クライアント端末３ａが行った更新操作に対応する更新通知または更新メッセージは、キュー操作処理部５２によって排除されていなければ、クライアント端末３ｂに送信される。

ステップ２０９で、クライアント端末装置３ｂは、受信するものが更新通知の場合、コミュニティサービスサーバ７にアクセスし、当該更新通知に対応する更新メッセージを取得する。

なお、本実施形態では、情報通知装置５とＤＢ６とコミュニティサービスサーバ７を分離したシステムを例示しているが、これらが一体となったシステムであってもよい。また、コミュニティサービスサーバ７を、コミュニティ活動に用いるツールの提供に関する機能と、ユーザやコミュニティについての情報の管理に関する機能に分離し、ユーザやコミュニティについての情報の管理に関する機能と情報通知装置５とＤＢ６を一体化させることも可能である。以下の実施例では、後者のタイプのコミュニティサービスシステムについて、詳細に説明する。

また、情報通知装置５は、専用のハードウェアにより実現する以外に、その機能を実現するためのプログラムを、コンピュータ読み取りが可能な記録媒体に記録して、この記録媒体に記録されたプログラムを、情報通知装置５となるべきコンピュータに読み込ませて実行することにより、実現するものでもよい。コンピュータ読み取りが可能な記録媒体とは、フロッピーディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取りが可能な記録媒体とは、インターネットを介してプログラムを送信する場合のように、短時間の間に、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、コンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。

一般に、コミュニティサービスシステムを構築する場合、コミュニティ活動に用いるツールを決定し、コミュニティサービスを提供する機能とともに、提供可能なサービスやユーザの情報を管理するためのデータベースを用意する必要がある。そのため、従来のコミュニティサービスシステムにおいては、コミュニティサービスそのものの機能と、データベースによって提供可能なサービスやユーザの情報を管理する機能が一体化して実装されていた（例えば、特許文献１から３を参照）。

しかしながら、従来のコミュニティサービスシステムでは、コミュニティサービスそのものの機能と、データベースによって提供可能なサービスやユーザの情報を管理する機能が一体化して実装されていたため、同じユーザに対するサービスであっても、コミュニティ活動に用いる特定のツールごとにユーザ等の情報を管理するためのデータベースを用意する必要があった。このため、特に多様なコミュニティサービスを実現する大規模なコミュニティサービスシステムの場合、上記データベースが巨大になり、このデータベースを管理するためのシステムの負担が大きくなるという問題があった。また、このようなシステムにおいては、ユーザは、特定のツールごとのデータベースに対応して、コミュニティメンバ全員分のユーザ情報を入力する必要があるため、ユーザに対する負担も大きくなるという問題があった。

そこで、データベースの管理の負担とユーザの情報入力の負担を軽減して、多様かつ大規模なコミュニティサービスを実現するコミュニティサービスシステムを構築するために、データベースの管理を行うサーバと、コミュニティにツールを提供するサーバを分離したコミュニティサービスシステムが望まれる。以下の実施例は、このようなコミュニティサービスシステムの一実施例であり、本発明の特徴である情報通知方法が採用され、その機能強化が図られている。

図３を参照すると、本発明の一実施例のコミュニティサービスシステムは、インターネットなどのネットワーク４を介したサーバ・クライアントの構成をとる。サーバとして、１台のコミュニティサービス管理サーバ１と、１台または複数台のコミュニティサービス提供サーバ２（２ａ、２ｂ）がある。また、クライアントとして、各ユーザが操作する複数台のクライアント端末３（３ａ、３ｂ、３ｃ、３ｄ）がある。クライアント端末３は、例えば、パーソナルコンピュータや、インターネットなどに接続して情報を閲覧できる携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）のような携帯用個人端末などである。

図４を参照すると、コミュニティサービス管理サーバ１と、コミュニティサービス提供サーバ２（２ａ、２ｂ、２ｃ）と、クライアント端末３（３ａ、３ｂ、３ｃ）の機能構成が示されている。

コミュニティサービス管理サーバ１は、提供可能なサービスやユーザの情報を管理するとともに、ユーザに対する各種通知情報を蓄積するコミュニティ管理機能部１０と、提供可能なサービスやユーザの情報を管理するための各種データベースを有している。

コミュニティサービス提供サーバ２（２ａ、２ｂ、２ｃ）は、ユーザからの入力情報に基づき、コミュニティ活動に用いるツールを決定してコミュニティを開設するとともに、このツールによるコミュニティサービスを提供するコミュニティサービス提供機能部２０（２０ａ、２０ｂ、２０ｃ）を有している。

クライアント端末３（３ａ、３ｂ、３ｃ）は、ユーザからの入力情報を入力するとともに、コミュニティサービス管理サーバ１から受信した各種通知情報、および、コミュニティサービス提供サーバ２から受信した各種コミュニティ活動用ツールの画面（ページ）情報を表示するためのサービスブラウズ機能部３０（３０ａ、３０ｂ、３０ｃ）を有している。

ここで、コミュニティサービス管理サーバ１のコミュニティ管理機能部１０は、そのサブシステムとして、各クライアント端末３（３ａ、３ｂ、３ｃ）のサービスブラウズ機能部３０（３０ａ、３０ｂ、３０ｃ）に対向して設けられ、クライアント端末３（３ａ、３ｂ、３ｃ）に対するサーバ機能を有するとともに、ユーザに対する各種通知情報を管理するサービスブラウズ管理機能部１００と、コミュニティ活動に用いるツールを決定してコミュニティを開設するコミュニティ開設部１０１（図４には不図示。後述する）と、コミュニティに招待されたユーザのコミュニティ参加に関する状態情報を更新するコミュニティメンバ更新部１０２（図４には不図示。後述する）と、コミュニティメンバに対してコミュニティ活動用ツールに関する更新通知を発行する更新通知発行部１０３（図４には不図示。後述する）と、コミュニティメンバにコミュニティ活動用ツールによるコミュニティサービスを提供するサービス提供部１０４（図４には不図示。後述する）を含む。

さらに、サービスブラウズ管理機能部１００は、ユーザに対する各種通知情報を蓄積する種々の通知情報テーブル１０００（図１の通知情報テーブル５１と同じ機能を有する）と、通知情報テーブル１０００に蓄積された各種通知情報を並べ替えたり、絞り込んだりするキュー操作処理部１００１（図１のキュー操作処理部５２と同じ機能を有する）を有する。

また、コミュニティサービス管理サーバ１が有している提供可能なサービスやユーザの情報を管理するためのデータベースは、ルール情報を含め、ユーザに関する情報を保持するユーザＤＢ１４と、本システムによって提供可能なサービスに関する情報を保持するコミュニティサービスＤＢ１３と、開設されたコミュニティのリストを保持するコミュニティＤＢ１２と、コミュニティに属するメンバのリストを保持するとともに、コミュニティラベル情報を保持するコミュニティメンバＤＢ１１から構成されている。

また、コミュニティサービス管理サーバ１は、コミュニティサービス提供サーバ２（２ａ、２ｂ、２ｃ）のコミュニティサービス提供機能部２０（２０ａ、２０ｂ、２０ｃ）と通信を行うための送信部１５および受信部１６（図４には不図示。後述する）を有している。

コミュニティ活動用ツールとしては、ネットワーク伝言板、ネットワーク掲示板、チャット、メーリングリスト、スケジューラ、共有ファイル、インスタントメッセンジャーなどさまざまな形態が考えられる。以下では、コミュニティ活動用ツールとしてコミュニティメンバで共有できるネットワーク伝言板を提供するコミュニティサービスを想定して説明する。

本実施例のコミュニティサービスシステムによってコミュニティサービスを提供する際の処理の段階として、（１）コミュニティ活動に用いるツールを決定してコミュニティを開設する処理の段階、（２）コミュニティに招待されたユーザのコミュニティ参加に関する状態情報を更新する処理の段階、および、（３）コミュニティメンバであるユーザにコミュニティサービスを提供する処理の段階の３つの段階がある。以下、各段階について詳細に説明を行う。

図５を参照すると、（１）コミュニティ活動に用いるツールを決定してコミュニティを開設する処理において中心的な役割を果たすコミュニティ開設部１０１の機能構成が示されている。また、図６を参照すると、（１）コミュニティ活動に用いるツールを決定してコミュニティを開設する処理の流れを示すフローチャートが示されている。以下、図５および図６を参照して、この処理について詳細に説明する。

まず、ユーザは、クライアント端末３のサービスブラウズ機能部３０を起動する。起動されたサービスブラウズ機能部３０は、コミュニティサービス管理サーバ１のサービスブラウズ管理機能部１００にアクセスする。そして、ステップ４００で、コミュニティ開設部１０１のユーザＩＤ有無判別部１０１０は、アクセスしてきたクライアント端末３がユーザＩＤを保有しているかどうかを判断する。

このとき、ユーザＩＤ有無判別部１０１０がユーザＩＤを持っていないと判断した場合は、ステップ４０３で、ユーザ登録部１０１２が、ユーザＩＤを発行するとともに、ステップ４０４で、クライアント端末３からパスワード、ならびにその他の必要なユーザ情報を受信し、ステップ４０５で、発行したユーザＩＤ、ユーザが入力したパスワード、ならびにその他の必要なユーザ情報をユーザＤＢ１４に登録する。

表１を参照すると、以上の処理によってユーザＤＢ１４に登録される情報の一例が示されている。なお、ユーザＩＤは、すでに使用されているユーザＩＤ以外でユーザが任意に指定したものや、ユーザ登録部１０１２がランダムに生成したものなどを利用することができる。ユーザＤＢ１４には、少なくともユーザＩＤと、ユーザのログインパスワードが登録される必要がある。さらに、ユーザの名前、ユーザの電子メールアドレスなども登録されるのが好ましい。

ユーザＩＤ有無判別部１０１０がユーザＩＤを持っていると判断した場合は、ステップ４０１で、クライアント端末３から、ユーザによって入力されたユーザＩＤとパスワードを受信する。そして、ステップ４０２で、ユーザ認証部１０１１が、このユーザＩＤとパスワードを受信し、受信したパスワードとユーザＤＢ１４に登録されているパスワードを照合して認証を行う。認証結果が正しければ、ユーザ認証部１０１１は、この認証情報を一時的に保持しておく。

次に、ステップ４０６で、コミュニティサービス決定部１０１３が、コミュニティサービスＤＢ１３に登録されている、本システムで利用可能なコミュニティサービスに関する情報を読み出し、サービスブラウズ管理機能部１００を介してクライアント端末３のサービスブラウズ機能部３０へ送信する。

表２を参照すると、コミュニティサービスＤＢ１３に登録されている情報の一例が示されている。コミュニティサービスＤＢ１３は、少なくともコミュニティサービスを提供するコミュニティサービス提供サーバ２のＩＤ、コミュニティサービスの名称、コミュニティサービス提供サーバ２のＵＲＬを含んでいる必要がある。さらに、当該コミュニティサービスを説明する説明文を含んでいるのが好ましい。

本システムで利用可能なコミュニティサービスに関する情報を受信したサービスブラウズ機能部３０は、クライアント端末３に利用可能なコミュニティサービスに関する情報を表示するとともに、ユーザに対し利用したいコミュニティサービスを選択するように要求する。ユーザが、選択したコミュニティサービスに関する情報をサービスブラウズ機能部３０に入力すると、コミュニティサービス決定部１０１３が、サービスブラウズ管理機能部１００を介してこの情報を受信し、ユーザに提供するコミュニティサービスを決定する。

ステップ４０７で、ユーザが、選択したコミュニティサービスを利用するためのコミュニティの開設に必要な情報をサービスブラウズ機能部３０に入力すると、コミュニティ登録部１０１４が、サービスブラウズ管理機能部１００を介してこれらの情報を受信し、決定したコミュニティサービスに関する情報とともにコミュニティＤＢ１２に登録する。ユーザが入力する、コミュニティの開設に必要な情報の例としては、コミュニティの名称、そのコミュニティの説明文などがある。

コミュニティ登録部１０１４は、これらの情報をコミュニティＤＢ１２に登録する際、データベース内で一意なＩＤをコミュニティＩＤとして付与し、併せて登録する。また、コミュニティサービスＤＢ１３から取得した、当該コミュニティサービスを提供するコミュニティサービス提供サーバ２に関するＵＲＬなどの情報も、併せて登録する。

表３を参照すると、以上の処理によりコミュニティＤＢ１２に登録される情報の一例が示されている。コミュニティＤＢ１２は、少なくともコミュニティＩＤ、コミュニティの名称、コミュニティサービス提供サーバ２のＩＤ、コミュニティサービス提供サーバ２のＵＲＬを含んでいる必要がある。さらに、コミュニティの開設者のユーザＩＤや、コミュニティの説明文を含んでいるのが好ましい。

次に、ステップ４０８で、コミュニティ開設要求発行部１０１５が、送信部１５を介して、コミュニティＤＢ１２に登録されたコミュニティＩＤ、コミュニティの開設に必要な情報を、同様にコミュニティＤＢ１２に登録されたＵＲＬに基づき、選択されたコミュニティサービスを提供するコミュニティサービス提供サーバ２のコミュニティサービス提供機能部２０へ送信し、コミュニティの開設を要求する。当該コミュニティサービス提供機能部２０は、受信した情報に基づきコミュニティを開設する。本実施例では、コミュニティメンバで共有できるネットワーク伝言板が開設されることになる。

次に、開設されたコミュニティに属するコミュニティメンバの候補を登録する。ステップ４０９で、ユーザが、コミュニティメンバとして招待したいユーザの情報をサービスブラウズ機能部３０に入力すると、コミュニティメンバ登録部１０１６が、サービスブラウズ管理機能部１００を介してこの情報を受信し、そのユーザのユーザＩＤをユーザＤＢ１４から取得し、コミュニティメンバＤＢ１１に登録する。

表４を参照すると、以上の処理によってコミュニティメンバＤＢ１１に登録される情報の一例が示されている。コミュニティメンバＤＢ１１は、少なくともコミュニティＩＤと、当該コミュニティを開設したユーザのＩＤ、当該コミュニティを開設したユーザが招待したユーザのＩＤ、招待したユーザの状態（当該コミュニティに招待中であるか、参加しているか、参加を拒否したかなど。これは、後述の（２）の処理で決定される）を含んでいる必要がある。

さらに、表４とは別に、ユーザＩＤごとに、その参加状態を示したテーブルも保持する。表５を参照すると、このようなテーブルの一例が示されている。なお、当該コミュニティを開設したユーザについても、表５のテーブルが作成される。

次に、ステップ４１０で、ルール情報設定部１０１８（図１のルール情報設定部５０と同じ機能を有する）が、サービスブラウズ管理機能部１００を介してクライアント端末３から、当該コミュニティを開設したユーザのルール情報とコミュニティラベル情報を受信する（これは、図２のステップ２００と同様である）。ルール情報はユーザＤＢ１４に登録され、コミュニティラベル情報は、表５の形式に変換されたテーブルに付け加えられる形で、コミュニティメンバＤＢ１１に登録される。

表６を参照すると、ステップ４１０の後のユーザＤＢ１４の内容が示されている。表１と比較すると、新たにルール情報が付加されている。ここでは、更新日時、コミュニティラベル、未通知／既通知情報、重要度による並べ替えルールが登録されているが、さらに、絞り込みルールを登録してもよい。

表７を参照すると、ステップ４１０の後のコミュニティメンバＤＢ１１の内容が示されている。表５と比較すると、新たにコミュニティラベルが付加されている。

このようにコミュニティメンバの候補のユーザが登録され、当該コミュニティを開設したユーザのルール情報と、当該コミュニティを開設したユーザのための、開設されたコミュニティに付加されるコミュニティラベル情報が登録されると、ステップ４１１で、メッセージ生成部１０１７が、当該コミュニティに招待されたユーザに対して、コミュニティメンバとして招待されたことを通知するメッセージを生成する。ステップ４１２で、生成したメッセージは、ユーザに通知すべき通知情報として、サービスブラウズ管理機能部１００の通知情報テーブル１０００に蓄積される。この通知情報にも重要度や更新日時が付されていてもよい。

なお、本実施例では、コミュニティの開設と同時にコミュニティメンバの候補の登録を行っているが、コミュニティの開設とコミュニティメンバの候補の登録は必ずしも同時に行わなくてもよい。また、既に開設されているコミュニティについて、任意の段階でコミュニティメンバの候補を登録できるようにしてもよい。また、コミュニティ開設者のユーザ以外のユーザ（既に当該コミュニティに参加済みのユーザ）が行ってもよい。

また、本実施例では、コミュニティの開設と同時にルール情報の登録を行っているが、コミュニティの開設とルール情報の登録は必ずしも同時に行わなくてもよい。当該コミュニティの開設前に既に登録されているルール情報をそのまま使用してもよいし、任意の段階でルール情報を登録、変更してもよい。

また、本実施例では、コミュニティの開設と同時にコミュニティラベルの登録を行っているが、コミュニティの開設とコミュニティラベルの登録は必ずしも同時に行わなくてもよい。また、既に開設されているコミュニティについて、任意の段階でコミュニティラベルを登録できるようにしてもよい。

図７を参照すると、（２）コミュニティに招待されたユーザのコミュニティ参加に関する状態情報を更新する処理において中心的な役割を果たすコミュニティメンバ更新部１０２の機能構成が示されている。また、図８を参照すると、（２）コミュニティに招待されたユーザのコミュニティ参加に関する状態情報を更新する処理の流れを示すフローチャートが示されている。以下、図７および図８を参照して、この処理について詳細に説明する。

まず、コミュニティメンバ更新部１０２のユーザＩＤ有無判別部、ユーザ認証部、ユーザ登録部（以上、不図示）が、ステップ４００からステップ４０５と全く同様な処理を行い、コミュニティサービス管理サーバ１にアクセスしてきたクライアント端末３の登録、認証を行う。

ステップ６００で、クライアント端末３のサービスブラウズ機能部３０は、所定の時間間隔でコミュニティサービス管理サーバ１のサービスブラウズ管理機能部１００にポーリングを行い、当該ユーザＩＤのユーザに通知すべき更新通知情報などの通知情報があるかどうかを確認する（このときにおいても、キュー操作処理部１００１は、通知情報テーブル１０００に蓄積された通知情報の並べ替え処理や絞り込み処理を行う）。ステップ６０１で、サービスブラウズ管理機能部１００は、ポーリングを受信した時点で通知情報テーブル１０００に送信すべき通知情報があると判断すれば、ステップ６０２で、サービスブラウズ機能部３０にその情報を送信する。通知情報を受信したサービスブラウズ機能部３０は、その内容を解析し、クライアント端末３に表示したり、処理を実行したりする。

通知情報がコミュニティへの招待通知である場合には、ステップ６００で、コミュニティメンバの候補としてコミュニティメンバＤＢ１１に登録されたユーザのクライアント端末３のサービスブラウズ機能部３０からコミュニティサービス管理サーバ１のサービスブラウズ管理機能部１００に対してポーリングが行われると、ステップ６０１で、通知情報テーブル１０００には当該ユーザに対してコミュニティメンバとして招待されたことを通知するメッセージが蓄積されているので、ステップ６０２で、サービスブラウズ管理機能部１００は、サービスブラウズ機能部３０にこの通知情報を送信する。ステップ６０３で、サービスブラウズ機能部３０は、受信した通知情報をコミュニティへの招待通知であると解析し、ユーザに対して、意思を確認するため、招待されたコミュニティへ参加するかどうかの入力を要求する。

次に、ステップ６０４で、ユーザの入力によってコミュニティへの参加の意思が確認できた場合には、サービスブラウズ機能部３０は、参加する旨の情報をサービスブラウズ管理機能部１００に送信する。ステップ６０５で、これを受信したコミュニティ管理機能部１０の参加意思情報判定部１０２１は、当該情報を参加の旨の情報であると判定し、ステップ６０６で、ユーザ状態情報更新部１０２０が、コミュニティメンバＤＢ１１における招待されたユーザの状態情報（表４、表５、表７を参照）を「参加」を表す情報に更新する。

次に、ステップ６０７で、ルール情報設定部１０２３（図１のルール情報設定部５０と同じ機能を有する）が、サービスブラウズ管理機能部１００を介してクライアント端末３から、当該コミュニティに参加の意思を表明したユーザのルール情報とコミュニティラベル情報を受信する。ルール情報はユーザＤＢ１４に登録され、コミュニティラベル情報は、表５の形式に変換されたテーブルに追加する形で、コミュニティメンバＤＢ１２に登録される。当該コミュニティに参加の意思を表明したユーザに対しても、表６と表７のような内容のテーブルが形成される。

また、参加の意思が確認できない場合、あるいは参加が拒否された場合には、サービスブラウズ機能部３０はサービスブラウズ管理機能部１００を介してコミュニティ管理機能部１０へその旨の情報を送信する。ステップ６０５で、これを受信したコミュニティ管理機能部１０の参加意思情報判定部１０２１は、当該情報を不参加の旨の情報であると判定し、ステップ６０８で、メッセージ生成部１０２２が、コミュニティメンバの候補を登録したユーザ（本実施例では、コミュニティの開設者）に対して、招待されたユーザが不参加となったことを通知するメッセージを生成する。そして、ステップ６０９で、生成したメッセージは、ユーザに通知すべき通知情報として、サービスブラウズ管理機能部１００が通知情報テーブル１０００に蓄積する。この通知情報にも重要度や更新日時が付されていてもよい。

なお、本実施例では、コミュニティへの参加確認と同時にルール情報の登録を行っているが、コミュニティへの参加確認とルール情報の登録は必ずしも同時に行わなくてもよい。当該コミュニティへの参加確認の前に既に登録されているルール情報をそのまま使用してもよいし、任意の段階でルール情報を登録、変更してもよい。

また、本実施例では、コミュニティへの参加確認と同時にコミュニティラベル情報の登録を行っているが、コミュニティへの参加確認とコミュニティラベルの登録は必ずしも同時に行わなくてもよい。また、既に参加確認しているコミュニティについて、任意の段階でコミュニティラベルを登録できるようにしてもよい。

次に、（３）コミュニティメンバであるユーザにコミュニティサービスを提供する処理について説明する。ユーザにコミュニティサービスを提供する処理は、（３ａ）あるコミュニティメンバによってそのコミュニティのコミュニティ活動用ツールに対して何らかの更新操作が行われたときに、他のコミュニティメンバに対して当該ツールに関する更新通知を発行する処理と、（３ｂ）コミュニティメンバに当該ツールに関する更新通知を送信し、当該ツールによるコミュニティサービスを提供する処理に分かれる。

図９を参照すると、（３ａ）コミュニティメンバに対してコミュニティ活動用ツールに関する更新通知を発行する処理において中心的な役割を果たす更新通知発行部１０３の機能構成が示されている。また、図１０を参照すると、（３ａ）コミュニティメンバに対してコミュニティ活動用ツールに関する更新通知を発行する処理の流れを示すフローチャートが示されている。以下、図９および図１０を参照して、この処理について詳細に説明する。

まず、ユーザは、クライアント端末３のサービスブラウズ機能部３０を起動する。起動されたサービスブラウズ機能部３０は、コミュニティサービス管理サーバ１のサービスブラウズ管理機能部１００にアクセスし、ユーザから入力されたユーザＩＤとパスワードとをサービスブラウズ管理機能部１００へ送信する。ステップ８００で、更新通知発行部１０３のユーザ認証部１０３０が、このユーザＩＤとパスワードを受信し、ステップ８０１で、受信したパスワードとユーザＤＢ１４に登録されているパスワードを照合して認証を行う。認証結果が正しければ、ユーザ認証部１０３０は、この認証情報を一時的に保持しておくとともに、ステップ８０２で、サービスブラウズ管理機能部１００を介してクライアント端末３のサービスブラウズ機能部３０に送信する。サービスブラウズ機能部３０は、受信した認証情報を保持しておく。

次に、ステップ８０３で、コミュニティ一覧生成部１０３１が、コミュニティメンバＤＢ１１を参照し、当該ユーザがメンバとなっているコミュニティのコミュニティＩＤを含む一覧を生成し、サービスブラウズ管理機能部１００を介してクライアント端末３のサービスブラウズ機能部３０に送信する。このとき、コミュニティＤＢ１２も併せて参照し、該当するコミュニティにコミュニティサービスを提供しているコミュニティサービス提供サーバ２のＵＲＬなどの情報も送信する。サービスブラウズ機能部３０は、受信したコミュニティの一覧をクライアント端末３に表示するとともに、ユーザからどのコミュニティを選択するかの入力を受け付ける。コミュニティが選択されると、クライアント端末３のサービスブラウズ機能部３０は、上記ＵＲＬに基づき、該当するコミュニティサービス提供サーバ２のコミュニティサービス提供機能部２０へアクセスし、選択されたコミュニティのコミュニティＩＤと保持している認証情報を送信する。

ステップ８０４で、コミュニティサービス提供サーバ２のコミュニティサービス提供機能部２０は、コミュニティサービス管理サーバ１の認証情報取得部１０３３に対して、クライアント端末３から受信した認証情報を送信し、その認証情報が正しいかどうかを照会する。ステップ８０５で、受信部１６を介してこれを受信した認証情報取得部１０３３は、これを認証情報チェック部１０３２に渡す。認証情報チェック部１０３２は、受信した認証情報と、ユーザ認証部１０３０が保持している認証情報の整合性をチェックし、整合していれば、送信部１５を介して認証成功の通知を（ステップ８０６）、整合していなければ認証失敗の通知をコミュニティサービス提供サーバ２のコミュニティサービス提供機能部２０に送信する（ステップ８１２）。コミュニティサービス提供機能部２０は、コミュニティ管理機能部１０から認証成功の通知を受信した場合、クライアント端末３から受信したコミュニティＩＤに基づき、当該コミュニティのコミュニティ活動用ツールの画面（ページ）情報をクライアント端末３のサービスブラウズ機能部３０へ送信する。本実施例においては、当該コミュニティのネットワーク伝言板の画面（ページ）情報が送信される。サービスブラウズ機能部３０は、受信した画面（ページ）情報をクライアント端末３に表示する。

次に、ユーザが、クライアント端末３に表示された画面（ページ）情報に基づき、サービスブラウズ機能部３０を介してコミュニティサービス提供機能部２０の当該コミュニティ活動用ツールに対して何らかの更新操作を行ったとする。ユーザが行う更新操作としては、本実施例の場合、コミュニティのネットワーク伝言板に書き込みを行うことなどが該当する。ステップ８０７で、コミュニティサービス提供サーバ２のコミュニティサービス提供機能部２０は、コミュニティ活動用ツールに対して更新操作が行われたことを検知すると、当該コミュニティ活動用ツールを利用しているコミュニティの他のメンバに更新通知を行うため、当該コミュニティのコミュニティＩＤ、更新日時、当該更新操作を行ったユーザによって付けられた、当該更新操作の重要度を含む更新情報をコミュニティサービス管理サーバ１の更新情報取得部１０３４へ送信する。更新情報取得部１０３４は、受信部１６を介してこれを受信し、ユーザＩＤ／ＵＲＬ検索部１０３５に渡す。ステップ８０８で、ユーザＩＤ／ＵＲＬ検索部１０３５は、コミュニティメンバＤＢ１１に対して、当該更新情報に含まれるコミュニティＩＤをキーとして、当該コミュニティに属しているユーザのユーザＩＤを検索し、取得する。また、ステップ８０９で、コミュニティＤＢ１２に対して、同じコミュニティＩＤをキーとして当該コミュニティのコミュニティ活動用ツールを提供しているコミュニティサービス提供サーバ２のＵＲＬを検索し、取得する。その後、ステップ８１０で、更新通知生成部１０３６が、取得したユーザＩＤのユーザに対して、当該コミュニティの情報、および、取得したコミュニティサービス提供サーバ２のＵＲＬを含む、コミュニティ活動用ツールに対して更新がなされた旨を通知するメッセージである更新通知情報（更新日時、重要度が付加されている）を生成する。ステップ８１１で、この更新通知情報もまた、ユーザに通知すべき通知情報として、サービスブラウズ管理機能部１００が通知情報テーブル１０００に蓄積する。

表８を参照すると、以上の処理で生成される更新通知情報テーブルの一例が示されている。表８は、更新操作があったときに、当該更新操作ごとに生成されるテーブルで、少なくとも当該更新を識別するＩＤ（更新通知ＩＤ）と、更新されたページのコミュニティＩＤと、更新されたページのＵＲＬを含んでいる。さらに、更新を行ったユーザのユーザＩＤと、更新日時、重要度が付加されている。

表９を参照すると、更新操作ごとに生成される表８のテーブルを、ユーザＩＤごとに整理したテーブルの一例が示されている。更新通知情報は、最終的にユーザごとに送信するため、ユーザごとに整理された表９のようなテーブルも生成する。ユーザごとに整理された更新通知情報テーブルは、さらに、未通知／既通知のフラグ（既に一度通知を行ったかどうかのフラグ）も含んでいる。

図１１を参照すると、（３ｂ）コミュニティメンバにコミュニティ活動用ツールによるコミュニティサービスを提供する処理において中心的な役割を果たすサービス提供部１０４の機能構成が示されている。また、図１２を参照すると、（３ｂ）コミュニティメンバにコミュニティ活動用ツールによるコミュニティサービスを提供する処理を示すフローチャートが示されている。以下、図１１および図１２を参照して、この処理について詳細に説明する。

まず、ステップ９００から９０２で、サービス提供部１０４のユーザ認証部１０４０は、クライアント端末から受信したパスワードの照合を行い、クライアント端末３に認証情報を送信する。クライアント端末３は、この認証情報を一時的に保持する。以上の処理は、ステップ８０１から８０２と全く同じである。

次に、ステップ９０３で、クライアント端末３のサービスブラウズ機能部３０は、所定の時間間隔でコミュニティサービス管理サーバ１のサービスブラウズ管理機能部１００にポーリングを行い、サービスブラウズ管理機能部１００はポーリングを受信する。ステップ９０４で、サービスブラウズ管理機能部１００は、ポーリングを受信した時点で通知情報テーブル１０００に通知すべき通知情報があるか調べる。

通知すべき通知情報がある場合には、ステップ９０５で、キュー操作処理部１００１は、ユーザＤＢ１４に登録されている、当該ユーザのルール情報と、コミュニティメンバＤＢ１１に登録されている、当該ユーザのコミュニティラベル情報を参照し、重要度、更新日時、未通知／既通知情報、コミュニティラベル情報にもとづいて、通知情報の並べ替え、絞り込みを行う。この処理は、図２のステップ２０７と同様な処理である。

ステップ９０６で、サービスブラウズ管理機能部１００は、サービスブラウズ機能部３０に、並べ替えや絞り込みがなされた通知情報を送信する。通知情報を受信したサービスブラウズ機能部３０は、その内容を解析する。このとき、例えば、受信した通知情報にコミュニティＩＤが含まれている場合には、ステップ９０７で、この通知情報を当該コミュニティの更新通知情報と判断する。

このようにして、通知情報が更新通知情報と判断された場合には、サービスブラウズ機能部３０は、同時に受信したＵＲＬに基づき、当該コミュニティサービス提供サーバ２にアクセスし、コミュニティＩＤと保持している認証情報を送信する。その後、ステップ９０８で、コミュニティサービス提供サーバ２のコミュニティサービス提供機能部２０は、クライアント端末３から受信した認証情報が正しいかどうかを、受信部１６を介してコミュニティサービス管理サーバ１の認証情報取得部１０４２に照会する。ステップ９０９で、認証情報チェック部１０４１は、この認証情報と、ユーザ認証部１０４０が保持している認証情報の整合性をチェックし、整合していれば、ステップ９１０で、送信部１５を介してコミュニティサービス提供サーバ２に認証成功の通知を送信する。コミュニティサービス提供サーバ２のコミュニティサービス提供機能部２０は、認証情報チェック部１０４１から認証成功の通知を受信した場合、クライアント端末３から受信したコミュニティＩＤに基づき、当該コミュニティのコミュニティ活動用ツールの画面（ページ）情報をクライアント端末３のサービスブラウズ機能部３０へ送信する。整合していなければ、ステップ９１１で、送信部１５を介してコミュニティサービス提供サーバ２に認証不成功の通知を送信する。

以下、ユーザは、クライアント端末３に表示された画面（ページ）情報に基づき、サービスブラウズ機能部３０を介してコミュニティサービス提供機能部２０のコミュニティ活動用ツールに対して更新操作を行うことができる。更新を行うと、ステップ８０７からステップ８１１、ステップ９０３からステップ９１１の処理が再実行されることにより、コミュニティ活動が進められる。

なお、本実施例では、コミュニティを開設したユーザが、当該コミュニティに招待したいユーザを登録し、コミュニティを開設したユーザとその招待に応じたユーザでコミュニティメンバを構成したが、コミュニティ開設部１０１のコミュニティメンバ登録部１０１６が、当該コミュニティに自発的に参加したいユーザのクライアント端末３から登録要求を受けつけ、これをコミュニティメンバに加え、コミュニティメンバＤＢ１１に登録することも可能である。

また、コミュニティサービス管理サーバ１は、専用のハードウェアにより実現する以外に、その機能を実現するためのプログラムをコンピュータ読み取りが可能な記録媒体に記録して、この記録媒体に記録されたプログラムを、コミュニティサービス管理サーバ１となるべきコンピュータに読み込ませて実行することにより、実現するものでもよい。コンピュータ読み取りが可能な記録媒体とは、フロッピーディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取りが可能な記録媒体とは、インターネットを介してプログラムを送信する場合のように、短時間の間に、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、コンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。

本発明の一実施形態のコミュニティサービスシステムの構成を示した図である。 本発明の一実施形態のコミュニティサービスシステムにおける処理の流れを示したシーケンス図である。 本発明の一実施例のコミュニティサービスシステムの構成を示した図である。 コミュニティサービス管理サーバ１と、コミュニティサービス提供サーバ２（２ａ、２ｂ、２ｃ）と、クライアント端末３（３ａ、３ｂ、３ｃ）の機能構成を示した図である。 コミュニティ開設部１０１を中心としたコミュニティサービス管理サーバ１の機能構成を示した図である。 コミュニティ活動に用いるツールを決定してコミュニティを開設する処理の流れを示すフローチャートである。 コミュニティメンバ更新部１０２を中心としたコミュニティサービス管理サーバ１の機能構成を示した図である。 コミュニティに招待されたユーザのコミュニティ参加に関する状態情報を更新する処理の流れを示すフローチャートである。 更新通知発行部１０３を中心としたコミュニティサービス管理サーバ１の機能構成を示した図である。 コミュニティメンバに対してコミュニティ活動用ツールに関する更新通知を発行する処理の流れを示すフローチャートである。 サービス提供部１０４を中心としたコミュニティサービス管理サーバ１の機能構成を示した図である。 コミュニティメンバにコミュニティ活動用ツールによるコミュニティサービスを提供する処理を示すフローチャートである。

符号の説明

１ コミュニティサービス管理サーバ
１０ コミュニティ管理機能部
１００ サービスブラウズ管理機能部
１０００ 通知情報テーブル
１００１ キュー操作処理部
１０１ コミュニティ開設部
１０１０ ユーザＩＤ有無判別部
１０１１ ユーザ認証部
１０１２ ユーザ登録部
１０１３ コミュニティサービス決定部
１０１４ コミュニティ登録部
１０１５ コミュニティ開設要求発行部
１０１６ コミュニティメンバ登録部
１０１７ メッセージ生成部
１０１８ ルール情報設定部
１０２ コミュニティメンバ更新部
１０２０ ユーザ状態情報更新部
１０２１ 参加意思情報判定部
１０２２ メッセージ生成部
１０２３ ルール情報設定部
１０３ 更新通知発行部
１０３０ ユーザ認証部
１０３１ コミュニティ一覧生成部
１０３２ 認証情報チェック部
１０３３ 認証情報取得部
１０３４ 更新情報取得部
１０３５ ユーザＩＤ／ＵＲＬ検索部
１０３６ 更新通知生成部
１０４ サービス提供部
１０４０ ユーザ認証部
１０４１ 認証情報チェック部
１０４２ 認証情報取得部
１１ コミュニティメンバＤＢ
１２ コミュニティＤＢ
１３ コミュニティサービスＤＢ
１４ ユーザＤＢ
１５ 送信部
１６ 受信部
２、２ａ、２ｂ、２ｃ コミュニティサービス提供サーバ
２０、２０ａ コミュニティサービス提供機能部
３、３ａ、３ｂ、３ｃ、３ｄ クライアント端末
３０、３０ａ サービスブラウズ機能部
４ ネットワーク
５ 情報通知装置
５０ ルール情報設定部
５１ 通知情報テーブル
５２ キュー操作処理部
６ ＤＢ
７ コミュニティサービスサーバ
２００〜２０９ ステップ
４００〜４１２ ステップ
６００〜６０９ ステップ
８００〜８１２ ステップ
９００〜９１１ ステップ

Claims (13)

1. 情報通知装置が、複数のユーザによって構成されたコミュニティに対してコミュニケーション用ツールを提供する第１の装置が生成した通知情報を、ユーザによって操作されるクライアント端末装置に送信する情報通知方法であって、
   前記情報通知装置が、前記第１の装置から、前記第１の装置が生成した通知情報と、当該通知情報の宛先であるコミュニティの識別子を受信し、これをユーザごとに蓄積する第１のステップと、
   前記情報通知装置が、通知情報を受け取るユーザが属する複数のコミュニティの優先度を示すコミュニティラベル情報と、このコミュニティラベル情報にもとづいて、当該ユーザのために蓄積された通知情報をどのように並べ替えるか、および／または、絞り込むかを定めるルール情報とを参照して、前記識別子をもとに、当該ユーザのために蓄積された通知情報を並べ替え、および／または、絞り込み、ネットワークを介して、当該ユーザの操作するクライアント端末装置に送信する第２のステップを有する情報通知方法。
2. １つまたは複数のサービス提供装置による、複数のユーザによって構成されたコミュニティへのコミュニケーション用ツールの提供を管理するサービス管理装置が、前記サービス提供装置からの更新通知またはユーザによって操作されるクライアント端末装置からの入力情報にもとづいて生成した通知情報を、ユーザによって操作されるクライアント端末装置に送信する情報通知方法であって、
   前記サービス管理装置が、生成した通知情報と、当該通知情報の宛先であるコミュニティの識別子を、ユーザごとに蓄積する第１のステップと、
   前記サービス管理装置が、通知情報を受け取るユーザが属する複数のコミュニティの優先度を示すコミュニティラベル情報と、このコミュニティラベル情報にもとづいて、当該ユーザのために蓄積された通知情報をどのように並べ替えるか、および／または、絞り込むかを定めるルール情報とを参照して、前記識別子をもとに、当該ユーザのために蓄積された通知情報を並べ替え、および／または、絞り込み、ネットワークを介して、当該ユーザの操作するクライアント端末装置に送信する第２のステップを有する情報通知方法。
3. 前記第１のステップで、前記情報通知装置または前記サービス管理装置は、当該通知情報の重要度、当該通知情報の生成日時、当該通知情報を既に送信済みか否かを示す未通知／既通知情報のうち、１つまたは複数をさらに蓄積し、
   前記ルール情報は、前記重要度、前記生成日時、前記未通知／既通知情報にもとづいて、当該ユーザのために蓄積された通知情報をどのように並べ替えるか、および／または、絞り込むかをさらに定め、
   前記第２のステップで、前記情報通知装置または前記サービス管理装置は、前記ルール情報を参照して、当該ユーザのために蓄積された通知情報を並べ替え、および／または、絞り込み、ネットワークを介して、当該ユーザの操作するクライアント端末装置に送信する、請求項１または２に記載の情報通知方法。
4. 前記第２のステップで、前記情報通知装置または前記サービス管理装置は、通知情報を受信するクライアント端末装置からポーリングを受信し、これに応答して通知情報を送信する、請求項１から３のいずれか１項に記載の情報通知方法。
5. 請求項１から４のいずれか１項に記載の各ステップを、前記情報通知装置または前記サービス管理装置となるべきコンピュータに実行させるプログラム。
6. 請求項１から４のいずれか１項に記載の各ステップを、前記情報通知装置または前記サービス管理装置となるべきコンピュータに実行させるプログラムを記録した、コンピュータ読み取りが可能な記録媒体。
7. 複数のユーザによって構成されたコミュニティに対してコミュニケーション用ツールを提供する第１の装置が生成した通知情報を、ユーザによって操作されるクライアント端末装置に送信する情報通知装置であって、
   前記第１の装置から、前記第１の装置が生成した通知情報と、当該通知情報の宛先であるコミュニティの識別子を受信し、これをユーザごとに蓄積する第１の手段と、
   通知情報を受け取るユーザが属する複数のコミュニティの優先度を示すコミュニティラベル情報と、このコミュニティラベル情報にもとづいて、当該ユーザのために蓄積された通知情報をどのように並べ替えるか、および／または、絞り込むかを定めるルール情報とを参照して、前記識別子をもとに、当該ユーザのために蓄積された通知情報を並べ替え、および／または、絞り込み、ネットワークを介して、当該ユーザの操作するクライアント端末装置に送信する第２の手段を有する情報通知装置。
8. 前記第１の手段は、当該通知情報の重要度、当該通知情報の生成日時、当該通知情報を既に送信済みか否かを示す未通知／既通知情報のうち、１つまたは複数をさらに蓄積する手段をさらに有し、
   前記ルール情報は、前記重要度、前記生成日時、前記未通知／既通知情報にもとづいて、当該ユーザのために蓄積された通知情報をどのように並べ替えるか、および／または、絞り込むかをさらに定め、
   前記第２の手段は、前記ルール情報を参照して、当該ユーザのために蓄積された通知情報を並べ替え、および／または、絞り込み、ネットワークを介して、当該ユーザの操作するクライアント端末装置に送信する手段をさらに有する、請求項７に記載の情報通知装置。
9. 前記第２の手段は、通知情報を受信するクライアント端末装置からポーリングを受信し、これに応答して通知情報を送信する、請求項７または８に記載の情報通知装置。
10. １つまたは複数のサービス提供装置による、複数のユーザによって構成されたコミュニティへのコミュニケーション用ツールの提供を管理し、前記サービス提供装置からの更新通知またはユーザによって操作されるクライアント端末装置からの入力情報にもとづいて生成した通知情報を、ユーザによって操作されるクライアント端末装置に送信するサービス管理装置であって、
    生成した通知情報と、当該通知情報の宛先であるコミュニティの識別子を、ユーザごとに蓄積する第１の手段と、
    通知情報を受け取るユーザが属する複数のコミュニティの優先度を示すコミュニティラベル情報と、このコミュニティラベル情報にもとづいて、当該ユーザのために蓄積された通知情報をどのように並べ替えるか、および／または、絞り込むかを定めるルール情報とを参照して、前記識別子をもとに、当該ユーザのために蓄積された通知情報を並べ替え、および／または、絞り込み、ネットワークを介して、当該ユーザの操作するクライアント端末装置に送信する第２の手段を有するサービス管理装置。
11. 前記第１の手段は、当該通知情報の重要度、当該通知情報の生成日時、当該通知情報を既に送信済みか否かを示す未通知／既通知情報のうち、１つまたは複数をさらに蓄積する手段をさらに有し、
    前記ルール情報は、前記重要度、前記生成日時、前記未通知／既通知情報にもとづいて、当該ユーザのために蓄積された通知情報をどのように並べ替えるか、および／または、絞り込むかをさらに定め、
    前記第２の手段は、前記ルール情報を参照して、当該ユーザのために蓄積された通知情報を並べ替え、および／または、絞り込み、ネットワークを介して、当該ユーザの操作するクライアント端末装置に送信する手段をさらに有する、請求項１０に記載のサービス管理装置。
12. 前記第２の手段は、通知情報を受信するクライアント端末装置からポーリングを受信し、これに応答して通知情報を送信する、請求項１０または１１に記載のサービス管理装置。
13. ユーザによって操作される複数のクライアント端末装置と、
    前記複数のクライアント端末装置によって構成されたコミュニティに、ネットワークを介してコミュニケーション用ツールの提供を行う１つまたは複数のサービス提供装置と、
    前記１つまたは複数のサービス提供装置による、前記コミュニティへのサービス提供を、前記ネットワークを介して管理し、前記サービス提供装置からの更新通知または前記クライアント端末装置からの入力情報にもとづいて生成した通知情報を、前記クライアント端末装置に送信する、請求項１０から１２のいずれか１項に記載のサービス管理装置を有するサービスシステム。
    
    

Images