JP2014099012A - コミュニティサーバ、コミュニティサーバの制御方法、およびプログラム - Google Patents

Abstract

【課題】 発起人が電子会議の開始処理を行うと、ネットコミュニティを通して他のユーザに参加の依頼が通知され、参加の依頼を受けたユーザは、簡単な操作のみで電子会議に参加することが出来る仕組みを提供する。
【解決手段】 ネットコミュニティのユーザからの入室要求を受け付け、電子会議サーバにおける会議室に入室させるように、ネットコミュニティと電子会議サーバが連携して動作するシステムであり、入室を要求したユーザが、その会議室に最初に入室した参加者である場合には、他のユーザに対して、参加の要請をするために通知する。
【選択図】図１７

Description

本発明は、コミュニティシステム（電子掲示板）と電子会議システムの連携を可能とする技術に関する。

例えば地理的に分散したコミュニケーションで意見交換をするためにＳＮＳ（ソーシャルネットワークシステム、あるいは電子掲示板、以下本明細書ではネットコミュニティあるいは単にコミュニティと呼ぶことがある。）と呼ばれるグループウェアを利用する場合がある。コミュニティの中で、特定の目的を持ったユーザが集まって仮想的グループを作成し意見交換をする場をフォーラムと呼ぶ。企業などのプロジェクトにおいて、前述のコミュニティ内でフォーラムを作成して、情報共有、意見交換を行うが、基本的に、これらの情報は投稿されたテキストメッセージであり、リアルタイムでの意見交換を望む場合には、不十分である。

そこで、コミュニティを使用している組織にとって、コミュニティと合わせて、オンラインミーティング（電話会議、ビデオカンファレンス、テレビ会議、Ｗｅｂ会議）を用いて、リアルタイムな意見交換をしたいという要望がある。

しかしながら、従来、コミュニティシステムと会議システムはあくまで別々のアプリケーションであるため、コミュニティのユーザのうち会議に参加したいユーザを、会議システムにも登録し、会議実施時は、会議室を予約、会議を招集するユーザは、他の参加者がその会議室に入室できるようにして参加を呼びかける、等の手順を踏まなければならなかった。

特許文献１では、インスタントメッセージのシステム（以下、ＩＭと略す）のユーザが電子会議（カンファレンスコール）の発起人となる場合に、ＩＭを介して電子会議の開催を要求する技術を提供している。特許文献１の技術において、ＩＭは、電子会議システムに記憶された他の参加可能なユーザを受け取り、発起人に提示、発起人はそれらユーザの中から参加者を指定する。さらに発起人は、ＩＭから電子会議システムを介して、電子会議の開催を他の参加者に呼びかける。

特表２００７−５２０１１７号公報

しかしながら、特許文献１は、あくまで電子会議システムにおいて管理されているユーザを、潜在的ターゲットとしてインスタントメッセージのユーザである発起人に提示し、発起人の観点からは潜在的ターゲットから参加者を選択しなければならない。また、インスタントメッセージは、会議システムを介して選択された参加者に通知処理と、電子会議システムの接続処理を行っているものの、通知を受けたユーザは、参加するために自ら電子会議システムにログインしなければならない。

本発明は、上記問題に鑑み、発起人が電子会議の開始処理を行うと、ネットコミュニティを通して他のユーザに参加の依頼が通知され、参加の依頼を受けたユーザは、簡単な操作のみで電子会議に参加することが出来る仕組みを提供することである。

本発明は、クライアント端末と、電子会議サーバと、ネットワークを介して接続可能な、ネットコミュニティに投稿されたメッセージを管理するコミュニティサーバであって、前記ネットコミュニティに投稿された前記メッセージを分割して管理するフォーラムを、フォーラム記憶手段に記憶させるためのフォーラム登録手段と、前記フォーラムと、投稿された前記メッセージと、該メッセージの投稿者であるユーザと、を対応付けてメッセージ情報としてメッセージ記憶手段に記憶させるメッセージ登録手段と、前記ネットコミュニティのユーザからの入室要求を受け付け、該ユーザを前記電子会議サーバにおける会議室に入室させるよう要求する会議室入室要求手段と、前記会議室入室要求手段により受け付けた入室要求に基づき前記会議室に入室した際に、該会議室への入室者が１人である第１入室者であるか否かを判定する会議開催判定手段と、前記会議開催判定手段により前記第１入室者であると判定された場合には、前記ネットコミュニティの他のユーザに、前記会議室へ入室することにより前記会議に参加を要請する参加要請通知手段と、を備えることを特徴とする。

本発明によれば、発起人が電子会議の開始処理を行うと、ネットコミュニティを通して他のユーザに参加の依頼が通知され、参加の依頼を受けたユーザは、簡単な操作のみで電子会議に参加することが出来る仕組みを提供することを可能とする。

本発明の実施形態に係わるシステム構成の一例を示す図である。 本発明の実施形態に係わるコミュニティサーバのハードウェア構成の一例を示すブロック図である。 本発明の実施形態に係わるコミュニティサーバのソフトウェア構成の一例を示す図である。 本発明の実施形態に係わるコミュニティにおけるフォーラムとメッセージの一覧を表示するＧＵＩ（グラフィカル・ユーザ・インタフェース）の一例を示す図である。 本発明の実施形態に係わるフォーラムとメッセージのデータ構成の一例を示す図である。 本発明の実施形態に係わる投稿されたメッセージに対するサブメッセージを投稿するＧＵＩの一例を示す図である。 本発明の実施形態に係わるメッセージ一覧において、投稿に従ってメッセージが追加される状態遷移の一例を示す図である。 本発明の第２の実施形態に係わる投稿されたメッセージに対するコメントを投稿するＧＵＩの一例を示す図である。 本発明の第２の実施形態に係わる投稿されたコメントに対するサブコメントを投稿するＧＵＩの一例を示す図である。 本発明の第２の実施形態に係わるメッセージ、コメント、サブコメントの一覧を表示するＧＵＩの一例を示す図である。 本発明の実施形態に係わるメールからの投稿処理の一例を示すフローチャートである。ャートである。 本発明の実施形態に係わるＳＮＳユーザインタフェースからの投稿処理の一例を示すフローチャートである。 本発明の実施形態に係わる会議の参加者を選択するためのＧＵＩの一例を示す図である。 本発明の実施形態に係わるフォーラム上のいずれのメンバーが会議室に入室しているかを表示するＧＵＩの一例を示す図である。 本発明の実施形態に係わる会議室の入室状況を表示する処理の一例を示すフローチャートである。 本発明の実施形態に係わる会議参加の処理の一例を示すフローチャートである。 本発明の実施形態に係わる会議参加の処理の一例を示すフローチャートである。

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

＜コミュニティシステムの基本的な動作を説明する第１の実施形態＞
図１は、本発明の実施形態に係わるシステム構成の一例を示す図である。

本発明の実施形態におけるシステム構成では、コミュニティサーバ１０１がクライアント端末１０２（例えば社内のＳＮＳ（ソーシャルネットワークシステム）クライアント、社外のメールクライアント）、メールサーバ１０３、Ｗｅｂメールサーバ１０４、電子会議サーバ１０５が、ネットワーク１０６を介して接続されている。図１では、ＳＮＳクライアントを社内、メールクライアントを社外として例示しているが、あくまでネットコミュニティ（電子掲示板、ＳＮＳなど。）に対して、コミュニティのユーザ権限を持ち、ＳＮＳクライアントから投稿するか、メールクライアントから投稿するか、を示すものであり、これらの構成を制限するものではない。以下ネットコミュニティをコミュニティと略する場合がある。

コミュニティサーバ１０１は、クライアント端末１０２から投稿を受け付け、コミュニティに表示する。また、条件に応じてメールクライアントであるクライアント端末１０２に、投稿をメールとして送信する情報処理装置である。

クライアント端末１０２は、ユーザにＳＮＳユーザインタフェース、またはメールソフトを使用させ、コミュニティサーバ１０１に対して投稿を行う情報処理装置である。また、ＳＮＳクライアントであるクライアント端末１０２においては、ユーザは、コミュニティのフォーラム、メッセージなどを各ユーザの権限に応じて閲覧可能である。

メールサーバ１０３は、コミュニティサーバ１０１から、またはＷｅｂメールサーバ１０４から、メールとメールの送受信の指示を受け付け、指示に従ってメールを送信し、または受信メールを各サーバに渡す。

次に、Ｗｅｂメールサーバ１０４について説明する。本発明でいうＷｅｂメールサーバ１０４に基づいて構成されるメールシステムとは、クライアント端末１０２のＷｅｂブラウザで利用することができる電子メールシステムのことを指す。受信したメールの閲覧や、新規メッセージの作成・送信などをＷｅｂブラウザのみで行なうことができる。クライアント端末１０２にメールソフトをインストールしてメールの送受信を管理する電子メールシステムとは異なり、すべてのメール送受信をサーバ側で管理するため、ユーザは、Ｗｅｂブラウザを用いることでどこにいてもメールの作成、受信、閲覧を行うことが可能である。

本システムの実施形態においては、メールサーバ１０３、Ｗｅｂメールサーバ１０４のいずれを用いてもよい。また、Ｗｅｂメールサーバ１０４が、構成としてはメールサーバ１０３を利用するものであって、クライアント端末１０２に対して、メールサーバ１０３をＷｅｂブラウザから利用できるようにするものであってもよい。また、前述ではクライアント端末１０２からＷｅｂブラウザを用いてＷｅｂメールサーバにアクセスする説明をしたが、本発明の実施形態においては、コミュニティサーバ１０１からＨＴＴＰプロトコルによる通信を行う構成も含む。

本発明の実施形態においては、コミュニティサーバ１０１から、メールサーバ１０３、またはＷｅｂメールサーバ１０４のＡＰＩ（アプリケーション・プログラミング・インタフェース）などを用いてメールの送受信を行う場合も含まれる。

電子会議サーバ１０５は、クライアント端末１０２からコミュニティサーバ１０１を経由して、会議の開始、会議室への入室などの処理を行う。また、会議中の音声、動画などを各々のクライアント端末１０２からの集約し、また配信などの処理を実行するサーバである。

なお、電子会議システムについては、特許文献「特開２０１２−１７８０７５」などに詳細が記載されており、周知の技術であるため、本実施形態では説明を省略する。

また、コミュニティサーバ１０１、メールサーバ１０３、Ｗｅｂメールサーバ１０４、電子会議サーバ１０５のいずれか、または全ては同一の筐体であってもよい。図１の構成は一例であり、様々な構成が可能である。

図２は、本発明の実施形態に係わるコミュニティサーバ１０１のハードウェア構成の一例を示すブロック図である。その他の情報処理装置、すなわちクライアント端末１０２、メールサーバ１０３、Ｗｅｂメールサーバ１０４に対しても適用可能である。

図２に示すように、コミュニティサーバ１０１は、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、通信Ｉ／Ｆコントローラ２０８等が接続された構成を採る。

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や、各サーバあるいは各ＰＣが実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。また、本発明を実施するために必要な情報が記憶されている。なお外部メモリはデータベースであってもよい。

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。

また、入力コントローラ２０５は、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。

ビデオコントローラ２０６は、ディスプレイ２１０等の表示器への表示を制御する。尚、表示器は液晶ディスプレイ等の表示器でもよい。これらは、必要に応じて管理者が使用する。

メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、あるいは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ）カードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ２０８は、ネットワーク１０６を介して外部機器と接続・通信し、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いた通信等が可能である。

尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上に表示することが可能である。また、ＣＰＵ２０１は、ディスプレイ２１０上のマウスカーソル（図示しない）等によるユーザ指示を可能とする。

本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイルおよび各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明についても後述する。

図３は、本発明の実施形態に係わるコミュニティサーバのソフトウェア構成の一例を示す図である。コミュニティサーバ１０１は、フォーラム登録部３０１、メール受付部３０２、ＳＮＳメッセージ受付部３０３、ＩＤ付与判定部３０４、ＩＤ判定部３０５、投稿部３０６、メール送信部３０７、フォーラム記憶部３０８、メッセージ記憶部３０９、メッセージ登録部３１０等を備えて構成されている。

フォーラム登録部３０１は、コミュニティサーバ１０１のフォーラム作成の権限のある管理ユーザ、または一般ユーザに作成させ、フォーラム記憶部３０８に登録する。

メール受付部３０２は、メールからの投稿データ（後述するメッセージ、サブメッセージ、コメント、サブコメント等）を受け付ける。

ＳＮＳメッセージ受付部３０３は、ＳＮＳユーザインタフェースからの投稿データを受け付ける。

ＩＤ付与判定部３０４は、第１の投稿データのヘッダ等の指定位置に、第２の投稿データを特定するＩＤが付与されているか否かを判定する。第２の投稿データを特定するＩＤが付与されている場合は、第１の投稿データが、新規の投稿（フォーラムの直下にあるもの）ではなく、ＩＤにより特定される第２の投稿データを指定して、その下位の投稿としてなされたものであることを示している。ＩＤが付与されていない場合は、新規の投稿であることを示している。

ＩＤ判定部３０５は、ＩＤがある場合にそのＩＤが投稿されたフォーラムに既に存在かを判定する。なければエラーである。特にメールからの投稿はコミュニティのユーザではないため、投稿データのヘッダ等の指定位置に、誤って又は不正にＩＤを付与可能である。これらのＩＤを有する投稿を防止することも可能となる。本発明の実施形態においては、ＩＤが投稿されたフォーラムに既に存在するかを判定する例としたが、ＩＤをコミュニティ全体として管理し、また判定するようにしてもよい。

投稿部３０６は、メール受付部３０２またはＳＮＳメッセージ受付部３０３で受け付けた投稿データを、コミュニティの指定のフォーラムに投稿する。投稿データは、投稿したユーザ情報などとともにメッセージ情報としてメッセージ記憶部３０９に記憶される。フォーラムの指定については後述する。

メール送信部３０７は、第１の投稿データが、メールから投稿されたものである場合に、第１の投稿データを指定して第２のデータを投稿する際に、第１投稿データに対するメールを送信するものである。メールアドレスの取得などの詳細は後述する。

フォーラム記憶部３０８は、前記フォーラム登録部から登録されたコミュニティ内のフォーラムに関する情報を記憶する。詳細は後述する。

メッセージ記憶部３０９は、投稿された投稿データをフォーラムに対応付けて記憶する。詳細は後述する。具体的にはメッセージ登録部３１０により登録される。

ユーザ情報記憶部３１１は、コミュニティシステムのユーザ情報が登録されているデータベースである。本発明の実施形態においては、後述するように電子会議サーバ１０５へのユーザ情報としても使用される。

ログイン制御部３１２は、ユーザにログイン操作をさせ、ユーザが入力したアカウント、パスワードなどをユーザ情報記憶部３１１に記憶されているユーザ情報と比較して、コミュニティシステムへのアクセス権限がある場合に、権限に応じてコミュニティサイトを使用できるようにする。

会議予約部３１３は、コミュニティシステムのクライアント端末１０２から、会議室および会議時間帯の予約を行うための機能部である。本発明の実施形態においては、各フォーラムに会議室とその会議室の使用可能時間が予め割り当てられているため、必ずしも実装されている必要はない。具体的には、後述する図４で４０６を押下することで、会議室の予約を行う。会議室の予約については前述の「特開２０１２−１７８０７５」に詳細に記載されている周知の技術であるため説明を省略する。

会議参加部３１４は、予約された会議室、または本発明の実施形態においては、フォーラムに対応付けられた会議室に入室し、会議に参加するための機能部である。具体的には、後述する図４で４０７を押下することで、会議室に入室する。会議室の入室については前述同様「特開２０１２−１７８０７５」に詳細に記載されている周知の技術であるため説明を省略する。

電子会議サーバ１０５は、管理部３２１、実行部３２２等から構成されている。

管理部３２１は会議システムのクライアント端末１０２からのログイン（認証）、会議室の予約・設定、実行部３２２への接続制限（時間指定）等を行う。ただし前述同様、これらの管理は、本発明の実施形態においては、コミュニティサーバ１０１、特にログインはログイン制御部３１２が行うため、管理部３２１は使用しない構成として説明する。しかしながら、コミュニティサーバ１０１では管理せず、電子会議サーバ１０５の管理部３２１に管理をさせるよう構成してもよい。

実行部３２２は、ユーザの会議室への入室要求により、電子会議システムのクライアントとセッションを確立し、電子会議を実行する。具体的には、音声、画像などのデータの集約、配信を行う。

これらの電子会議サーバ１０５については前述同様「特開２０１２−１７８０７５」に詳細に記載されている周知の技術であるため説明を省略する。

図４は、本発明の実施形態に係わるコミュニティにおけるフォーラムとメッセージの一覧を表示するＧＵＩ（グラフィカル・ユーザ・インタフェース）の一例を示す図である。図４の４００が、クライアント端末１０２（ＳＮＳクライアント）においてＳＮＳユーザに使用されるＳＮＳユーザインタフェースの例を図示している。

４０１には、コミュニティで使用可能なフォーラムの一覧を、フォーラム記憶部３０８に基づき表示される。不図示ではあるが、例えばユーザ情報記憶部において、各フォーラムに対するユーザのアクセス権限を設定することが可能であり、特定のＳＮＳユーザがＳＮＳユーザインタフェースを使用する場合には、アクセス権限があるもののみ表示するようにしてもよい。また、アクセス権限においても、単に閲覧権限がある場合、また投稿する権限がある場合などにより表示形態（色、アイコンの形状）などを変更してもよい。

４０２には、現在着目しているフォーラムの名称が表示される。例えば、４０１のフォーラムの一覧からユーザが閲覧したいフォーラムをマウスでクリックする等により、４０３の画面を表示させることが可能である。図４の例では、“Ａ社プロジェクト”（Ａ社から受注した開発案件の情報共有とそのサポートをするためのフォーラム名）が表示されている。前述のフォーラム登録部３０１において、例えば、“Ａ社プロジェクト”の関係者のみにアクセス権限を付与してもよい。その他、経営者やプロジェクト管理部門などにもアクセス権限を付与することも考えられる。また、後述する４０４（ＳＮＳからの新規投稿）ボタンが表示されている。

４０３には、投稿されたメッセージを階層構造（ツリー構造）として表示するものである。階層構造においては、あるメッセージがフォーラムに直接的に紐付けられる（ルートとなるメッセージ）。ルートとなるメッセージは、複数存在可能である。図４の４０３においては、メッセージＡとメッセージＢの２つがルートとなるメッセージである。ルートとなるメッセージは、例えば、４０４の新規投稿ボタンをマウスでクリックすることにより不図示ではあるがメッセージ入力画面が表示されることで投稿するメッセージを作成する、などのように実装される。また、サブメッセージを投稿する場合（すなわち、これから投稿しようとする第１のメッセージを、階層構造における第２のメッセージの１つ下の階層）に投稿したい場合がある。例えば図４のメッセージＡの下の、メッセージＡ１、メッセージＡ２、あるいはメッセージＡ２の下のメッセージＡ２１、メッセージＡ２２などである。この場合は、例えば第２のメッセージ（１つ上の階層のメッセージ）をマウスで右クリックする、などによりメッセージを作成するＧＵＩが表示され、投稿後は第２のメッセージの１つ下の階層に配置されるようにする。

メッセージＡ、メッセージＢは、同じ“Ａ社プロジェクト”に関する情報であっても、異なる話題を扱うために、異なる階層構造としてメッセージ群を分割する。この１つのメッセージ群を“スレッド”と称することもある。メッセージＡをルートとするスレッドは、メッセージＡに対する意見、確認、御礼などを述べるために、下位のメッセージ（サブメッセージ）としてメッセージＡ１、メッセージＡ２を有する。４０３では、メッセージＡの１階層下に表示される（右側にインデントされて表示）。

第１の実施形態の図４においては、無制限にメッセージの階層構造を作成できるが、コミュニティシステムとして階層の数が固定されていてもよい。また、管理者が階層数を設定できるようにしてもよい。この場合は、例えばフォーラム登録部３０１において、フォーラム毎に設定できるようにしてもよいし、不図示の管理者ＧＵＩにおいて、システム全体として統一の階層数を設定できるようにしてもよい。設定可能な場合には、目的により、例えば社内のパーソナルコンピュータで主に使うのか、社外において画面の小さい携帯端末で主に使うのか、で運用方法を変更することが可能である。

４０５〜４０７は、コミュニティ以外のアプリケーションとの連携や、コミュニティのシステムを利用して他の目的のために用いる際の、アプリケーション開始ボタンである。

例えば、４０５は、新規メッセージをワークフローとして用いるためのボタンである。４０６は、電子会議システムにおいて会議室の予約を行う。４０７は、予約された会議室に入室（会議への参加）を行う。

４０８は、メールからの投稿を受け付けた際に、メールを受け付けたことをユーザに示すためのアイコンである。例えば、点滅、回転などの簡単なアニメーション等、表示形態を変えることにより実現する。

４１０は、メールによるメッセージの投稿を受け付けた場合に、そのメッセージをユーザが表示した画面の一例である。このコミュニティサーバ１０１は、“Ｃ開発株式会社”で運用されており、４１０の画面は、“Ａ社”の“ニシモトさん”からメールで投稿されたものである。メールで投稿するためには、後述するコミュニティの“Ａ社プロジェクト”フォーラムに設定されたメールアドレスを知っている必要がある。すなわち、Ａ社・ニシモトさんには、予め前記メールアドレスを通知している。

運用の例として、例えば、メールクライアントを使用するユーザは、社外の顧客であり、ＳＮＳユーザインタフェースを使用するユーザは、Ｃ開発株式会社の担当部門、担当プロジェクトなどの担当者である。後述するように、担当者は、顧客に対してメールをする／しない、を選択しながらメッセージを投稿することが可能である。すなわち、顧客の要求／質問に対して、まず、要求／質問を受け付けた旨の回答をメールで送信し、その後、社内の担当者間で対応策について打ち合わせを行い、対応策がまとまった時点で最終回答をする、といった対応が可能となる。もちろん、その間に、中間回答を随時行うことも可能である。

これらの方法により、社内の担当者としては、ＳＮＳユーザインタフェースのみを用いて、顧客の要求／質問を受け付け、回答することが可能となる効果が得られる。また、社内での打ち合わせの全てではなく、必要なメッセージのみを顧客にメールで送信することが可能となる効果が得られる。
以上で、図４のＧＵＩの説明を完了する。

図５は、本発明の実施形態に係わるフォーラムとメッセージのデータ構成の一例を示す図である。コミュニティで管理されるデータは、フォーラム記憶部３０８（図５の５００を用いて詳述）、メッセージ記憶部３０９（図５の５１０を用いて詳述）に記憶される。

フォーラム記憶部３０８は、フォーラム名５０１、フォーラムメールアドレス５０２、会議室番号５０３、入室可能時間５０４、最大利用人数５０５等のデータ項目から構成される。

フォーラム名５０１は、図４のフォーラム一覧４０１において表示されるフォーラムの名称が登録されるデータ項目である。

フォーラムメールアドレス５０２は、該フォーラムにメールによる投稿をする際に使用するメールのアドレスを記載するデータ項目である。このメールアドレスは、対応するフォーラムの情報が、前記フォーラム登録部により登録される際に、権限のあるユーザ（管理ユーザなど）により指定することができる。

さらに、電子会議システムと連携するため、フォーラム毎に指定の会議室が、会議室番号５０３により割り当てられる。これらの会議室には、入室可能時間５０４で指定された時間に、当該フォーラムのメンバーが自由に入室することが出来る。ただし、最大利用人数５０５が設定されている場合には、同時に最大利用人数５０５の数のユーザしか入室できない。

メッセージ記憶部３０９は、フォーラム名５１１、ＩＤ５１２、投稿時刻５１３、上位ＩＤ５１４、メールアドレス５１５、内容５１６、投稿者５１７等のデータ項目から構成される。

フォーラム名５１１は、メッセージの情報がいずれのフォーラムのものかを特定するデータ項目である。

ＩＤ５１２は、メッセージを一意的に特定するＩＤを記載するデータ項目である。後述の上位ＩＤ５１４と合わせて使用することで、ルートのメッセージまで辿ることができる。これにより１つのスレッドの階層構造（ツリー構造）を決定することが可能である。また、後述するように、メールによる投稿があった場合に、そのメールのヘッダなどの指定位置にＩＤがあり、そのＩＤがメールアドレスに対応するフォーラムにおいて既存である場合には、そのスレッドに投稿されたメッセージとして特定される。メールクライアントからの投稿も、ＳＮＳクライアントからの投稿も、そのメッセージのヘッダ等の指定位置にあるＩＤのサブメッセージとして１つ下位の位置に投稿されることを想定している。しかしながらそのような構成に限定する

ものではない。例えば、メールクライアントからの投稿に限っては、ＩＤを上位に辿って、必ずルートのメッセージの１つ下位の位置に投稿するように、コミュニティシステムを実装する、なども可能である。その他、投稿されたメッセージにおけるユーザの指定（メールのタイトルに何らかの記号を指定する、など）によりいずれのメッセージの下位に投稿するかを指定できてもよい。

投稿時刻５１３は、メッセージが投稿された時刻を記載するためのデータ項目である。

上位ＩＤ５１４は、該メッセージが、他のメッセージ（階層構造において１つ上位）のサブメッセージとして投稿された場合に、その上位のメッセージのＩＤを記載するデータ項目である。

メールアドレス５１５は、該メッセージの投稿がメールクライアントからなされた場合に、その送信元のメールアドレスを記載するデータ項目である。

内容５１６は、投稿されたメッセージの内容である。図４の４１０における「件名：製品の問い合わせ Ｃ開発株式会社・玉置様〜よろしくお願い申し上げます。」が記載されるデータ項目である。あるいは件名は別のデータ項目としてもよい。内容５１６の３行目以降は（＜＞で囲まれた文字列）は、実際の内容ではなく、各メッセージの階層構造における位置づけを記載している。

投稿者５１７は、当該メッセージを投稿したユーザを示す。

なお、図５の５００は図４の４００のフォーラム一覧、図５の５１０は、図４の４０３のメッセージ一覧に対応させて、フォーラムのデータ、投稿されたメッセージのデータが登録された例として記載している。

以上、図５の説明を完了する。前述のデータ構成はあくまで一例であり、その他のデータ項目を含んでいてもよい。例えばフォーラム記憶部３０８は、フォーラムを示すアイコンのイメージファイルに対するリンクが記載されていてもよい。その他、異なる構成であってもよい。

図６は、本発明の実施形態に係わる投稿されたメッセージに対するサブメッセージを投稿するＧＵＩの一例を示す図である。図６の例では、図４の“Ａ社プロジェクト”フォーラムに投稿された“メッセージＡ”に対して、サブメッセージを投稿する際のＧＵＩである。前述のように、例えば、メッセージＡをマウスで右クリックすることにより図６のＧＵＩが表示される。

図６の上部側は、図４の４１０と同じである。すなわち、メッセージＡの内容がそのまま表示される。下部側の６０１には、サブメッセージを入力するための欄（６０２）、メッセージを投稿するためのボタン（６０３）、メッセージを投稿し、更にその内容をメールで送信するためのボタン（６０４）が表示される。ＳＮＳユーザは、６０２の入力欄にメッセージを入力する。

前記の６０３のボタンを押下した場合（メッセージを投稿する指定をした場合）、図４の４０３のメッセージ一覧における“メッセージＡ１”の投稿処理が行われる。

前記の６０４のボタンを押下した場合（メッセージの投稿とメールの送信の両方を行う指定をした場合）、図４の４０３のメッセージ一覧における“メッセージＡ１”の投稿と同時にメールの送信処理もされるが、その詳細について説明する。

前記投稿の際のメールの送信に使用するアドレスは、メッセージを投稿する際に指定した（投稿が完了した時点で１つ上の階層のメッセージとなる）メッセージに対応したメールアドレスを検索する。すなわち、前記の例では、メッセージＡのサブメッセージを投稿するため、メッセージＡに対応するメールアドレス（図５の５１５）のメールアドレスを送信に使用する。また、対応するメールアドレスがない場合には、送信処理は中止する。
以上で、図６の説明を完了する。

＜コミュニティシステムの基本的な動作を説明する第２の実施形態＞
図７から図１０を用いて第２の実施形態を説明する。第１の実施形態と第２の実施形態は、基本的に同じフローで処理されるが、第２の実施形態においては、メッセージの階層構造が３階層に制限されている。ルートメッセージを単に“メッセージ”、ルートメッセージ（メッセージ）のサブメッセージを“コメント”、コメントのサブメッセージを“サブコメント”と呼び、これが前述の３階層を構成する。

運用例として図４でも説明したように、メッセージ（ルートメッセージ）は、フォーラムに対応するＳＮＳクライアントから、またはメールアドレスを知っているメールユーザがメールクライアントを用いて投稿可能である。すなわち、まず第１に、社内での担当者（ＳＮＳクライアントのユーザ）の間で、打ち合わせなどの情報共有を話題毎に行うことが可能である。この場合は、スレッド（メッセージ及びその下位のコメント、サブコメントをまとめたもの）に対応するメールアドレス（顧客のメールアドレス）がないため、メールが送信されることはない。さらに、メッセージが顧客のメールクライアントから送信されたものである場合には、対応するメールアドレスがあるため、メッセージなどの投稿時にメールを送信する場合と送信しない場合がある。

第１の実施形態との違いは、顧客にメールを送信するか否かを、コメントの投稿かサブコメントの投稿か、で変更することである。これにより、第１の実施形態とは異なり、投稿する階層により、担当者がメール送信するか否かを固定し、誤って社内での相談をメールしてしまうことを防止する効果を得ることが可能である。詳細を以下に説明する。

図７は、本発明の実施形態に係わるメッセージ一覧において、投稿に従ってメッセージが追加される状態の遷移の一例を示す図である。図７は、ＳＮＳユーザインタフェースにおいて、メッセージＡ（７０２）が投稿された状態（７０１）、メッセージＡ（７０２）に対するコメントＡ１（７０４）が投稿された状態（７０２）、コメントＡ１（７０４）に対するサブコメントＡ１１（７０６）が投稿された状態（７０５）、を図示している。

図８は、本発明の第２の実施形態に係わる投稿されたメッセージに対するコメントを投稿するＧＵＩの一例を示す図である。第１の実施形態においては、図６で説明したように第１の実施形態においては、サブメッセージを作成した後に、そのメッセージをコミュニティに投稿するだけか、投稿と合わせてメール送信も行うか、を投稿者がボタンなどにより指定した。第２の実施形態においては、以下の通りとなる。

メッセージに対して、コメントの投稿を使用とする場合には、図８のＧＵＩのようになる。上部側は、図４、図６の４１０と同じである。すなわち、メッセージＡの内容がそのまま表示される。下部側の８０１には、コメントを入力するための欄（８０２）、コメントを投稿し、更にその内容をメールで送信するためのボタン（８０３）が表示される。ＳＮＳユーザは、８０２の入力欄にメッセージを入力する。メッセージＡがメールから投稿されたものである場合には、前述の通り、コメントの投稿およびメールの送信が行われるが、メッセージＡがＳＮＳユーザインタフェースから投稿されたものである場合には、メールの送信は行われない（対応するメールアドレスがない）。その場合、８０３の“コメント＆メール”ボタンの代わりに、後述する図９の９０４と同様の、“コメント”ボタンが表示され、投稿のみが可能であることを投稿者に分かりやすく提示してもよい。

図９は、本発明の第２の実施形態に係わる投稿されたコメントに対するサブコメントを投稿するＧＵＩの一例を示す図である。前述の運用例の説明の通り、サブコメントはコメントに対して１つ下位となるメッセージの投稿であり、また社内での打ち合わせであるため、メール送信は行わない（例え、メッセージにメールアドレスが対応していても送信しない）。

図９の上部側の９０１は、投稿及び顧客に対する送信を行ったサブコメントである（図８の８０３と同じ内容）。それに対して、下部側９０２には、サブコメントの入力欄（９０３）と、入力したサブコメントを投稿するためのボタン（９０４）がある。

図１０は、本発明の第２の実施形態に係わるメッセージ、コメント、サブコメントの一覧を表示するＧＵＩの一例を示す図である。前述の例にあるように、顧客からのメールによる投稿（メッセージＡ（１００１）と、それに対する応答（コメントＡ１（１００２）：投稿およびメール送信）がある。更に、コメントＡ１に対する社内でのサブコメント（１００３〜１００４）がある。

コメントＡ２は、ユーザの投稿が、メッセージＡのコメントとして表示されている。コメントＡ１を投稿する担当者がメッセージＡを選択したため（この時点でコメントＡ１はない）、メッセージＡのＩＤをヘッダに付与して顧客にメール送信する。その返信である顧客からのメールのヘッダにも前記ＩＤが付与されているため、メッセージＡのサブメッセージであるコメントとして投稿される。これにより、コメントＡ１のサブコメント（社内での対応策の打ち合わせ）に、顧客からの返信メールであるコメントＡ２が紛れ込まないようにすることが可能である。

逆に、内容としてはコメントＡ１（担当者から顧客へのメール）に対する返信であるため、コメントＡ１のサブコメントとする方が分かりやすければ、投稿されたばかりのコメントＡ１のＩＤをヘッダに付与して顧客に返信すればよい。

また、不図示ではあるが、メッセージＡのコメントとするか、コメントＡ１のサブコメントとするかを投稿者に選択させるように、ＳＮＳユーザインタフェースのコメント投稿時に指示可能としてもよい。

最終的に、メッセージＡに対する対応策が、社内担当者間で決定し、メッセージＡに対しての投稿と顧客に対するメール送信を行った状態がコメントＡ３（１００６）である。

以上で図７から図１０を用いて、第２の実施形態において、第１の実施形態と異なる部分の説明を行った。次に、図１１、図１２のフローチャートを用いて、コミュニティサーバにおける処理を説明する。基本的には、第１の実施形態と第２の実施形態とで処理が同じであるため、同じフローチャートを用いるが異なるのは次の２点である。まず１点目は、ＳＮＳユーザインタフェースにおいて、３階層目（またはサブコメント）に対する投稿が可能か否か、が異なる。２点目としては、サブコメント（３階層目）の投稿時に、メールアドレスがコメント（２階層目）に設定されていなければ、第１階層まで確認するか否か、が異なる。これら２点の違いは、フローチャートの説明の中では特に述べない。

図１１は、本発明の実施形態に係わるメールからの投稿処理の一例を示すフローチャートである。図１１の各ステップは、コミュニティサーバ１０１のＣＰＵ２０１によって実行される。

Ｓ１１０１においては、コミュニティサーバにおけるコミュニティの処理を終了する命令がされたか否かをチェックする。終了命令がない場合（ＮＯ）にはＳ１１０２に進む。終了命令がある場合（ＹＥＳ）には、終了する。
Ｓ１１０２においては、メールの受信を確認する。

Ｓ１１０３においては、Ｓ１１０２の確認においてメールが受信されたか否かを判定する。メールの受信がある場合（ＹＥＳ）には、Ｓ１１０４に進む。ない場合（ＮＯ）には、Ｓ１１０１に進む。

Ｓ１１０４においては、受信したメールデータの所定位置（例えばヘッダの送信者名に対応する位置）に本発明の実施形態で指定された形式のＩＤが付与されているか解析する。

Ｓ１１０５においては、ＩＤが含まれているか否かを判定する。含まれていない場合（ＮＯ）には、Ｓ１１０６に進む。含まれている場合（ＹＥＳ）には、Ｓ１１０８に進む。

Ｓ１１０６においては、メールデータとして投稿されたメッセージをルートメッセージと見なす。すなわち、他のメッセージの下位となるメッセージではなく新規メッセージとしてＩＤを発行する（ＩＤ発行部）。

Ｓ１１０７においては、メールデータとして投稿されたメッセージを、送信元のメールアドレスおよびＳ１１０６において発行されたＩＤを対応付けて、ルートメッセージとして投稿する。

Ｓ１１０８においては、ＩＤがフォーラムにおいて既存のものか否かを判定する。既存のＩＤではない場合（ＮＯ）には、Ｓ１１０９に進む。既存のＩＤである場合（ＹＥＳ）の場合には、Ｓ１１１０に進む。

Ｓ１１０９においては、存在していないＩＤが付与されたメッセージのメールからの投稿を、えらーとみなし、メール送信元に対してその旨を通知する。

Ｓ１１１０においては、メールデータをＩＤに対応したメッセージのサブメッセージとして投稿する。この場合に置いて、本メッセージに対応するＩＤを新たに発行する（ＩＤ発行部）。
以上により、図１１のフローチャートの説明を完了する。

図１２は、本発明の実施形態に係わるＳＮＳユーザインタフェースからの投稿処理の一例を示すフローチャートである。図１２の各ステップは、コミュニティサーバ１０１のＣＰＵ２０１によって実行される。

Ｓ１２０１においては、コミュニティサーバにおけるコミュニティの処理を終了する命令がされたか否かをチェックする。終了命令がない場合（ＮＯ）にはＳ１２０２に進む。終了命令がある場合（ＹＥＳ）には、終了する。

Ｓ１２０２においては、ＳＮＳユーザインタフェースからのメッセージの投稿有無を確認する。

Ｓ１２０３においては、Ｓ１２０２の確認において投稿があるか否かを判定する。投稿がある場合（ＹＥＳ）には、Ｓ１２０４に進む。ない場合（ＮＯ）には、Ｓ１２０１に進む。

Ｓ１２０４においては、投稿されたメッセージの所定位置（例えばヘッダの指定されたタグの位置）に本発明の実施形態で指定された形式のＩＤが付与されているか解析する。

Ｓ１２０５においては、ＩＤが含まれているか否かを判定する。含まれていない場合（ＮＯ）には、Ｓ１２０６に進む。含まれている場合（ＹＥＳ）には、Ｓ１２０８に進む。

Ｓ１２０６においては、投稿されたメッセージをルートメッセージと見なす。すなわち、他のメッセージの下位となるメッセージではなく新規メッセージとしてＩＤを発行する（ＩＤ発行部）。

Ｓ１２０７においては、投稿されたメッセージを、Ｓ１２０６において発行されたＩＤを対応付けて、ルートメッセージとして投稿する。

Ｓ１２０８においては、メッセージをＩＤに対応したメッセージのサブメッセージとして投稿する。この場合に置いて、本メッセージに対応するＩＤを新たに発行する（ＩＤ発行部）。

Ｓ１２０９においては、このメッセージをメール送信するように指定されているか否かを判定する（メール送信指定判定部）。前述の運用例では、担当者から顧客にメールを送信する場合に対応する。送信すると指定されている場合（ＹＥＳ）には、Ｓ１２１０に進む。送信すると指定されていない場合（ＮＯ）には、Ｓ１２０１に進む。送信する／しないを具体的に説明すると、第１の実施形態における図６のメッセージボタン（６０３）を押下するか、メッセージ＆メールボタン（６０４）を押下するか、による。また、第２の実施形態におけるメッセージに対するコメントの投稿か、コメントに対するサブコメントの投稿か、等による。その他、前述しているように、不図示ではあるがユーザが明示的に選択できる場合、など各方法による指定を含むものとする。

Ｓ１２１０においては、対応するＩＤに基づき、上位のメッセージを辿り、メールアドレスを取得する。第２の実施例においては、コメントを投稿した際に、上位であるメッセージにメールアドレスがある場合である。また、第１の実施例においても上位のメッセージにメールアドレスがある場合であるが、１つ上位のメッセージにメールアドレスがない場合に、更に上位を辿るかは設計または設定による。

Ｓ１２１１においては、前記Ｓ１２１０においてメールアドレスを取得した場合に、Ｓ１２０８において投稿したメッセージをメールとして、前記メールアドレスに送信する。
以上により、図１２のフローチャートの説明を完了する。

＜コミュニティシステムと会議システムの連携に係わる実施形態＞
図１３は、本発明の実施形態に係わる会議の参加者を選択するためのＧＵＩの一例を示す図である。フォーラム内のあるユーザが会議を発起する際に、他のユーザを選択する場合の画面である。

また、以下の説明において、クライアント端末１０２は、ＳＮＳユーザインタフェースの電子会議に関連する部分（アイコンなど）の表示を変更することがある。さらに、電子会議クライアントとしてのユーザインタフェースを起動することもある。

実装としては、ＳＮＳクライアントの機能が、電子会議クライアントを起動させてもよい。あるいは電子会議クライアントの機能がＳＮＳクライアント起動時とあわせて起動されており、必要に応じてＳＮＳクライアントと電子会議サーバとの仲介をしたり、電子会議のユーザインタフェースを表示をさせてもよい。

図１３の４００は、クライアント端末１０２の表示装置に表示されるＳＮＳユーザインタフェースであり、図４で説明したものと同じである。ＳＮＳのユーザのうち、会議の発起人になろうとするユーザが、４０６のボタンを押下することで、電子会議サーバ１０５と連携して（例えば、電子会議クライアントを表示することによって）電子会議サーバ１０５の会議室を予約するよう実装してもよい。この場合には、図５の会議室番号５０３で説明したフォーラムに対応付けられた会議室は不要であるか、またはデフォルトとしては会議室番号５０３が使用され、それ以外の会議室も使用可能になるようにしてもよい。

また、会議室を予約する際に参加を促す他のユーザの指定方法には様々な実装がある。例えば、予約する際に、選択されている（アクティブになっている）フォーラムの全てのユーザ、あるいは選択されている（アクティブになっている）スレッドの全てのユーザが参加を促す対象ユーザとして、自動的に選択されてもよい。

あるいは、会議室を予約する発起人であるユーザが、クライアント端末１０２の表示装置に表示される参加候補ユーザ一覧１３０１から参加を促す対象ユーザを選択するように実装されてもよい。その際に、選択されているフォーラムの全てのユーザ、あるいは選択されているスレッドの全てのユーザが、参加候補ユーザ一覧１３０１に表示されてもよい。発起人であるユーザは、参加候補ユーザ一覧１３０１の中から参加させたい他のユーザを参加要請チェックボックス１３０２等により選択する。

発起人が参加者として指名したユーザは、コミュニティサーバ１０１または電子会議サーバに送信され、対応するフォーラムまたは会議室と対応付けられて、参加要請ユーザ記憶部（不図示）に記憶されるようにしてもよい。参加要請ユーザ記憶部には、参加を要請されたユーザが、実際に参加しているか否かを区別するように記憶することが可能である。

図１４は、本発明の実施形態に係わるフォーラム上のいずれのメンバーが会議室に入室しているかを表示するＧＵＩの一例を示す図である。

図１４のＳＮＳユーザインタフェースにおいて、参加を促されたユーザの「会議への参加」ボタン（４０７）は、例えば点滅する、アニメーションになる、色を変えるなど表示形態を変え、ユーザに会議への参加が促されている旨をわかるようにしてもよい。この時に「会議への参加」ボタン（４０７）を押下すると、参加が促されている会議室に入室できる。

なお、誰も参加していない状態で、「会議への参加」ボタン（４０７）を押下すると、フォーラムに対応付けられた会議室、または４０６で予め予約された会議室に、自動的に入室し発起人とみなされ、図１３で説明したように、対応付けられるフォーラムやスレッドのユーザに自動的に会議室へ参加するよう通知されるように実装されてもよい。

また、参加を要請されたユーザの状態は、図１３で説明したように、会議室への「入室」、または「未入室」に区別されるので、入室状況欄１４０１が表示され、例えばフォーラム（この例では「Ａ社プロジェクト」フォーラム）フォーラムの他のユーザからわかるようにしてもよい。

図１５は、本発明の実施形態に係わる会議室の入室状況を表示する処理の一例を示すフローチャートである。図１５のフローチャートの各ステップは、コミュニティサーバ１０１、クライアント端末１０２、電子会議サーバ１０５のいずれかのＣＰＵ２０１によって実行される。

Ｓ１５０１からＳ１５１７のループ処理は、コミュニティサーバ１０１と電子会議サーバ１０５が連携して会議が行われている間、繰り返される。ただし、ここで「会議が行われている間」とは、実際に複数の参加者が同じ会議室に入室し、何らかの打合せを行っている間に限定しない。例えば、複数ある会議室のうち、いずれかの会議室が予約されている時間帯に常時監視用に動作していてもよい。あるいは、コミュニティサーバ１０１が動作している間であれば、予約がなくても予約外に会議が開催されることを想定して、常時監視用に動作していてもよい。

「常時監視」としては、前述のように様々な実装が可能であるが、各ユーザの入室から退室までを監視し、入退室に応じた処理を前述のループ処理の中で実施することになる。

Ｓ１５０２において、コミュニティサーバ１０１は、電子会議サーバ１０５に現在の入室者リストを要求する。すなわち、現在「どのユーザが」、「いずれの会議室に」入室しているか、という情報を要求する。ここで、コミュニティサーバ１０１は、フォーラム（あるいはスレッド）に対応した会議室、または会議室を自由に予約できる場合はであっても、それら予約された会議室を記憶しており特定できる。従ってコミュニティサーバ１０１で記憶した会議室（会議室の一覧）に対してのみ「どのユーザが」使用しているかを問い合わせる要求を送信してもよい。

Ｓ１５０３において、電子会議サーバ１０５は、コミュニティサーバ１０１から入室者リストの送信要求を受け付ける。

Ｓ１５０４において、電子会議サーバ１０５は、電子会議サーバ１０５の会議室と該会議室に入室しているユーザを記憶する記憶部（不図示）から、ユーザリストを取得する。ここで、前述のようにＳ１５０２におけるコミュニティサーバ１０１からの要求に会議室の一覧が含まれている場合は、その会議室の一覧に参加しているユーザリストを取得するものとする。

Ｓ１５０５において、電子会議サーバ１０５は、Ｓ１５０４にて取得したユーザと会議室の情報をコミュニティサーバ１０１に送信する。

Ｓ１５０６において、コミュニティサーバ１０１は、電子会議サーバ１０５から送信されたユーザと会議室の情報を受信する。

Ｓ１５０７からＳ１５１１のループ処理においてコミュニティサーバ１０１は、Ｓ１５０６で受信したユーザと会議室の情報をもとにクライアント端末１０２に対するＳＮＳユーザインタフェースの会議参加者状況の表示情報の変更指示を行う。すなわち、ユーザと会議室の情報ごとに処理するループとなる。ここで、ループ処理はユーザと会議室の情報に基づくため、１人のＳＮＳユーザが複数の会議室に同時に入室可能な場合は同一ユーザが（異なる会議室で）現れる可能性がある。また１ユーザが同時に入室可能なのは１会議室に限定されている場合には、複数回現れない。いずれの実装であってもよい。

Ｓ１５０８において、コミュニティサーバ１０１は、１入室者（会議の参加者）に着目する。

Ｓ１５０９において、コミュニティサーバ１０１は、着目した入室者が入室している会議室と対応するフォーラムを取得する。

Ｓ１５１０において、コミュニティサーバ１０１は、フォーラムに対応する入室者リスト（なければ生成）に着目中の入室者を追加する。

Ｓ１５１２からＳ１５１６のループ処理においてコミュニティサーバ１０１は、Ｓ１５０７からＳ１５１１で生成した入室者リストに対する処理を繰り返す。すなわち、入室者リストがあるフォーラムごと単位の処理を実行する。

Ｓ１５１３において、コミュニティサーバ１０１は、１つのフォーラムに着目する。

Ｓ１５１４において、コミュニティサーバ１０１は、参加を要請されているユーザの参加状況（会議室への入室状況）を判定し（入室状況判定部）、その判定結果に基づき着目中のフォーラムに登録されているユーザのクライアント端末１０２（ＳＮＳクライアント）に対して、入室者、未入室者を通知する（入室状況通知部）。

Ｓ１５１５において、クライアント端末１０２は、コミュニティサーバ１０１から入室者、未入室者の通知を受け付け、クライアント端末１０２（ＳＮＳクライアント）のＳＮＳユーザインタフェースの表示を変更させる。すなわち、例えば図１４の入室状況欄１４０１における入室、未入室のユーザリストを更新させる。

図１５のフローチャートで説明した処理により、コミュニティシステムのユーザは、自分が関連する（登録されている）フォーラムで何らかの会議が開始されたことや、そのユーザ自身が参加要請されていることなどを、視覚的に認識できる。すなわち、電子会議システムとの連携を意識せず、コミュニティシステムのＳＮＳユーザインタフェース上で、容易に確認することが出来るという効果を得ることができる。
以上で、図１５のフローチャートの説明を完了する。

図１６は、本発明の実施形態に係わる会議参加の処理の一例を示すフローチャートである。図１６のフローチャートの各ステップは、コミュニティサーバ１０１、クライアント端末１０２、電子会議サーバ１０５のいずれかのＣＰＵ２０１によって実行される。

クライアント端末１０２はＳＮＳクライアントとして動作し、ユーザが操作するＳＮＳユーザインタフェースにおいて、会議室への入室要求を受け付ける。前述のように、ＳＮＳユーザインタフェースにおけるフォーラムに電子会議サーバ１０５の会議室が１つ対応付けられている場合（図５の５０３）には、「会議への参加」ボタン（図４の４０７）を押下するだけで、入室要求を発行することが出来る。また、同フォーラムで、既に他のユーザにより会議が開催されている場合も同様である。フォーラムに会議室が対応付けられておらず、予め予約する必要がある場合には、会議の発起人は４０６により予め会議室を予約し、同時に入室する。予約と入室を分け、予め４０６で予約しておき、会議開始時刻に、４０７で入室してもよい。

Ｓ１６０１において、クライアント端末１０２は、前述の会議室への入室を、コミュニティサーバ１０１に要求する。

Ｓ１６０２において、コミュニティサーバ１０１は、クライアント端末１０２（ＳＮＳクライアント）から会議室の入室要求を受け付ける。

Ｓ１６０３において、コミュニティサーバ１０１は、会議室の入室要求から、入室を要求する対応フォーラムを取得する。具体的には、ＳＮＳユーザインタフェースにおいて入室を要求したユーザが、いずれのフォーラムから入室要求の操作を行ったかによる。

Ｓ１６０４において、コミュニティサーバ１０１は、Ｓ１６０３で取得したフォーラム（入室要求に対応するフォーラム）から、入室する会議室を取得する。具体的には、フォーラム記憶部３０８の会議室番号５０３を取得する。

Ｓ１６０５において、コミュニティサーバ１０１は、ユーザの入室要求に基づき、入室する会議室を指定して入室をクライアント端末１０２に要求する（Ｓ１６０２〜Ｓ１６０５により会議室入室要求手段部を構成）。

Ｓ１６０６において、クライアント端末１０２は、ユーザが入室する会議室と入室の要求をコミュニティサーバ１０１から受信する。

Ｓ１６０７において、クライアント端末１０２（ＳＮＳクライアント）は、Ｓ１６０６において受信した会議室を指定して、入室をクライアント端末１０２（電子会議クライアント）に対して要求する。

Ｓ１６０８において、クライアント端末１０２（電子会議クライアント）は、Ｓ１６０７における会議室への入室の要求を、クライアント端末１０２（ＳＮＳクライアント）から受け付ける。

Ｓ１６０９において、クライアント端末１０２（電子会議クライアント）は、Ｓ１６０８において受け付けた会議室への入室の要求を、電子会議サーバ１０５に要求する。

Ｓ１６１０において、電子会議サーバ１０５は、クライアント端末１０２（電子会議クライアント）からの会議室への入室要求を受け付ける。

Ｓ１６１１（電子会議サーバ１０５）と、Ｓ１６１２（クライアント端末１０２：電子会議クライアント）と、においては、会議室に入室するためのセッションを確立する。

Ｓ１６１３からＳ１６１５のループ処理においてクライアント端末１０２（電子会議クライアント）は、ユーザが会議室から退室するまで、会議実施（ユーザの参加状態維持）の処理を継続する。

一方、Ｓ１６１６からＳ１６１８のループ処理において電子会議サーバは、全てのユーザが会議室から退室するまで、会議実施の処理を継続する。

Ｓ１６１７（電子会議サーバ１０５）と、Ｓ１６１４（クライアント端末１０２：電子会議クライアント）と、においては、会議を実施するためのデータの送信処理、および再生処理を行う。

具体的には、Ｓ１６１４において、電子会議クライアント（クライアント端末１０２）は、会議参加者の音声、またカメラが接続されている場合には、撮像データを電子会議サーバ１０５に送信する。また、電子会議サーバ１０５から転送された他の参加者の電子会議クライアント（クライアント端末１０２）の音声、撮像データを受信し、電子会議クライアントの表示装置に表示制御する。

また、Ｓ１６１７において、電子会議サーバ１０５は、電子会議クライアント（クライアント端末１０２）から音声、撮像データを受信し、合成するなど画像処理を行い、さらに会議に参加している電子会議クライアントに送信する。

以上、図１６のフローチャートにより、ＳＮＳクライアントのユーザは、電子会議システムを別のアプリケーションであることを意識せずに、容易に入室（参加）することができるという効果を得る。すなわち、コミュニティシステムと電子会議システムのシームレスな連携が実現される。
以上で、図１６のフローチャートの処理を説明する。

図１７は、本発明の実施形態に係わる会議参加の処理の一例を示すフローチャートである。図１６のフローチャートとの違いは、会議室に最初に入室するユーザが発起人となるため、他のユーザ（他のクライアント端末１０２、すなわちＳＮＳクライアント）に、参加を要請することである。図１７のフローチャートの各ステップは、コミュニティサーバ１０１、クライアント端末１０２のいずれかのＣＰＵ２０１によって実行される。
会議室に最初に入室するユーザであるか否かは、例えば前述のＳ１６０４または後述のＳ１７０４の処理の最初に判定が行われ、分岐する（会議開催判定部）。

Ｓ１６０１からＳ１６０３までは、図１６と同一の処理なので説明を省略する。また、Ｓ１７０６からは、Ｓ１７０７へステップの他に、図１６のＳ１６０７への「会議室への入室を要求」に関する処理も行われる。「会議室への入室を要求」する処理と「選択されたユーザへ通知」する処理の前後関係はないため、いずれが先であってもよい。以下で、Ｓ１７０４からＳ１７１１までの各ステップの説明を行う。

Ｓ１７０４において、コミュニティサーバ１０１は、Ｓ１７０３で取得したフォーラム（入室要求に対応するフォーラム）から、入室する会議室を取得する。具体的には、フォーラム記憶部３０８の会議室番号５０３を取得する。また、フォーラムに登録されているユーザ（あるいは発起人となるユーザがフォーカスしているスレッドにメッセージを投稿した全ユーザ）から、ユーザ一覧を取得する。

Ｓ１７０５において、コミュニティサーバ１０１は、入室要求をしたユーザが入室する会議室と、ユーザ一覧をクライアント端末１０２に通知する（参加候補ユーザ一覧通知部）。

Ｓ１７０６において、クライアント端末１０２は、ユーザが入室する会議室と、ユーザ一覧をコミュニティサーバ１０１から受信する。

Ｓ１７０７において、クライアント端末１０２は、ＳＮＳのユーザ（会議の発起人）に、参加するユーザを促す他のユーザを選択させる。具体的には、図１３の参加候補ユーザ一覧１３０１を提示し、他のユーザに選択させる。あるいは、Ｓ１７０５において、ユーザ一覧をクライアント端末１０２に送信せず、すなわち発起人であるユーザには参加候補ユーザ一覧１３０１を提示して他のユーザを選択させることなくともよい。その場合、コミュニティサーバ１０１側で、フォーラムユーザ全員、またはスレッドにメッセージを投稿したユーザ全員を自動的に参加者として選択されたものとしてもよい。以下の処理は、Ｓ１７０７において、発起人であるユーザに他の参加者のユーザを選択した場合を想定したものである。

Ｓ１７０８において、クライアント端末１０２は、コミュニティサーバ１０１に、会議への参加を要請するために選択したユーザへの通知を要求する。

Ｓ１７０９において、コミュニティサーバ１０１は、クライアント端末１０２から、会議への参加を要請するために選択したユーザへの通知の要求を受け付ける。

Ｓ１７１０において、コミュニティサーバ１０１は、選択されたユーザを、参加要請ユーザとして参加要請ユーザ記憶部に登録する。

Ｓ１７１１において、コミュニティサーバ１０１は、参加要請されたユーザのクライアント端末１０２に、参加要請の通知を行う（参加要請通知）。この通知により、クライアント端末１０２においては、前述のように図１４の４０７の表示形態が変更される等の処理が行われる。

なお、クライアント端末１０２のユーザが、ＳＮＳユーザインタフェースを起動しているとは限らない。そのため、各ユーザがユーザ情報記憶部３１１に通知先のメールアドレスを登録している場合には、メールによって会議への参加要請も合わせて通知するようにしてもよい。

以上の処理により、会議の発起人が意識しない（自動的にフォーラムまたはスレッドのユーザが参加要請される場合）、あるいは電子会議システムを意識せず簡単な指定（Ｓ１７０７で図１３の１３０１を用いてユーザを選択する場合）により、他のユーザに参加を要請することが可能となる効果を得る。
以上で図１７のフローチャートの説明を完了する。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、図１１、図１２、図１５〜図１７に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図１１、図１２、図１５〜図１７の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図１１、図１２、図１５〜図１７の各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。 さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ コミュニティサーバ
１０２ クライアント端末
１０３ メールサーバ
１０４ Ｗｅｂメールサーバ
１０５ 電子会議サーバ
１０６ ネットワーク

Claims (10)

1. クライアント端末と、電子会議サーバと、ネットワークを介して接続可能な、ネットコミュニティに投稿されたメッセージを管理するコミュニティサーバであって、
   前記ネットコミュニティに投稿された前記メッセージを分割して管理するフォーラムを、フォーラム記憶手段に記憶させるためのフォーラム登録手段と、
   前記フォーラムと、投稿された前記メッセージと、該メッセージの投稿者であるユーザと、を対応付けてメッセージ情報としてメッセージ記憶手段に記憶させるメッセージ登録手段と、
   前記ネットコミュニティのユーザからの入室要求を受け付け、該ユーザを前記電子会議サーバにおける会議室に入室させるよう要求する会議室入室要求手段と、
   前記会議室入室要求手段により受け付けた入室要求に基づき前記会議室に入室した際に、該会議室への入室者が１人である第１入室者であるか否かを判定する会議開催判定手段と、
   前記会議開催判定手段により前記第１入室者であると判定された場合には、前記ネットコミュニティの他のユーザに、前記会議室へ入室することにより前記会議に参加を要請する参加要請通知手段と、
   を備えることを特徴とするコミュニティサーバ。
2. 前記会議室入室要求手段により受け付けた入室要求には、入室を要求した前記ユーザが閲覧しているフォーラムの情報が含まれるものであって、
   前記会議室は、前記フォーラム記憶手段において前記フォーラムに対してあらかじめ対応付けられており、
   前記会議室入室要求手段は、
   前記ユーザを、前記フォーラム記憶手段において、前記フォーラムに対応付けられた前記会議室に入室させることを特徴とする請求項１に記載のコミュニティサーバ。
3. 前記参加要請通知手段により参加を要請されたユーザと、入室する前記会議室と、入室状況と、を記憶する参加要請ユーザ記憶手段と、
   参加を要請された前記ユーザが、前記会議室に入室しているか否かを参加要請ユーザ記憶手段に記憶された前記入室状況に基づき判定する入室状況判定手段と、
   参加要請された前記ユーザの入室状況判定手段による判定結果を、前記クライアント端末に通知する入室状況通知手段と、
   を更に備えることを特徴とする請求項１または請求項２のいずれかに記載のコミュニティサーバ。
4. 前記参加要請通知手段は、
   前記会議開催判定手段により第１入室者であると判定されたユーザが閲覧している前記フォーラムの他のユーザに対して参加を要請するものであることを特徴とする請求項１乃至請求項３のいずれか１項に記載のコミュニティサーバ。
5. 前記参加要請通知手段は、
   前記会議開催判定手段により第１入室者であると判定されたユーザが閲覧しているスレッドに前記メッセージを投稿した他のユーザに対して参加を要請するものであることを特徴とする請求項１乃至請求項３のいずれか１項に記載のコミュニティサーバ。
6. 前記会議開催判定手段により第１入室者であると判定されたユーザが閲覧している前記フォーラムの他のユーザの一覧を、参加候補ユーザ一覧として前記第１入室者の前記クライアント端末に送信し、提示させる参加候補ユーザ一覧通知手段と、
   を更に備え、
   前記参加要請通知手段は、
   前記第１入室者であるユーザに、前記参加候補ユーザ一覧から選択されたユーザに対して参加を要請するものであることを特徴とする請求項１乃至請求項３のいずれか１項に記載のコミュニティサーバ。
7. 前記会議開催判定手段により第１入室者であると判定されたユーザが閲覧しているスレッドの他のユーザの一覧を、参加候補ユーザ一覧として前記第１入室者の前記クライアント端末に送信し、提示させる参加候補ユーザ一覧通知手段と、
   を更に備え、
   前記参加要請通知手段は、
   前記第１入室者であるユーザに、前記参加候補ユーザ一覧から選択されたユーザに対して参加を要請するものであることを特徴とする請求項１乃至請求項３のいずれか１項に記載のコミュニティサーバ。
8. 前記コミュニティに登録されたユーザに関するユーザ情報を記憶するユーザ情報記憶手段と、
   を更に備え、
   前記ユーザ情報に対応するユーザのメールアドレスが登録されている場合には、前記参加要請通知手段は、更に、前記参加を要請するユーザに対してメールによる参加要請の通知をすることを特徴とする請求項１乃至請求項７のいずれか１項に記載のコミュニティサーバ。
9. クライアント端末と、電子会議サーバと、ネットワークを介して接続可能な、ネットコミュニティに投稿されたメッセージを管理するコミュニティサーバの制御方法であって、
   フォーラム登録手段が、前記ネットコミュニティに投稿された前記メッセージを分割して管理するフォーラムを、フォーラム記憶手段に記憶させるためのフォーラム登録ステップと、
   メッセージ登録手段が、前記フォーラムと、投稿された前記メッセージと、該メッセージの投稿者であるユーザと、を対応付けてメッセージ情報としてメッセージ記憶手段に記憶させるメッセージ登録ステップと、
   会議室入室要求手段が、前記ネットコミュニティのユーザからの入室要求を受け付け、該ユーザを前記電子会議サーバにおける会議室に入室させるよう要求する会議室入室要求ステップと、
   会議開催判定手段が、前記会議室入室要求ステップにより受け付けた入室要求に基づき前記会議室に入室した際に、該会議室への入室者が１人である第１入室者であるか否かを判定する会議開催判定ステップと、
   参加要請通知手段が、前記会議開催判定ステップにより前記第１入室者であると判定された場合には、前記ネットコミュニティの他のユーザに、前記会議室へ入室することにより前記会議に参加を要請する参加要請通知ステップと、
   を備えることを特徴とするコミュニティサーバの制御方法。
10. コンピュータを、クライアント端末と、電子会議サーバと、ネットワークを介して接続可能な、ネットコミュニティに投稿されたメッセージを管理するコミュニティサーバとして機能させるためのプログラムであって、
    前記コンピュータを、
    前記ネットコミュニティに投稿された前記メッセージを分割して管理するフォーラムを、フォーラム記憶手段に記憶させるためのフォーラム登録手段、
    前記フォーラムと、投稿された前記メッセージと、該メッセージの投稿者であるユーザと、を対応付けてメッセージ情報としてメッセージ記憶手段に記憶させるメッセージ登録手段、
    前記ネットコミュニティのユーザからの入室要求を受け付け、該ユーザを前記電子会議サーバにおける会議室に入室させるよう要求する会議室入室要求手段、
    前記会議室入室要求手段により受け付けた入室要求に基づき前記会議室に入室した際に、該会議室への入室者が１人である第１入室者であるか否かを判定する会議開催判定手段、
    前記会議開催判定手段により前記第１入室者であると判定された場合には、前記ネットコミュニティの他のユーザに、前記会議室へ入室することにより前記会議に参加を要請する参加要請通知手段、
    を備えることを特徴とするコミュニティサーバとして機能させるためのプログラム。

Images