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

Abstract

【課題】 スレッド（あるいはメッセージ）を、投稿元のフォーラムと他のフォーラムとで共有することを可能にする。
【解決手段】 ネットコミュニティにおけるスレッド（相互に関連するメッセージ群）と、紹介メッセージと、共有指定先のフォーラムと、をユーザから受け付けると、共有指定先のフォーラムにおいて、紹介メッセージを通常のメッセージとして投稿し、さらに、前記スレッドを共有するため、前記通常のメッセージとして投稿した紹介メッセージに、共有スレッドとしての関連付け情報を、メッセージ記憶手段に記憶させる。
【選択図】図１７

Description

本発明は、ネットコミュニティ（電子掲示板）を管理するコミュニティサーバにであって、複数のフォーラムにおいてスレッド（メッセージ）を共有する技術に関する。

ネットワーク上でコミュニケーションを取ることが可能なアプリケーションとして、ネットコミュニティ（電子掲示板、ＳＮＳ（ソーシャルネットワークシステム））などが存在する。しかしながら、情報の共有は、基本的にフォーラムと呼ばれる共通の目的を持つグループ内でのメッセージ共有に限られる。すなわち、あるフォーラムに一度投稿されたメッセージは、他のフォーラムにおいては閲覧することはできない。

これに対して、特許文献１では、あるフォーラムに投稿されたメッセージ、またはスレッド（フォーラム内における１つの話題を提起したメッセージに対しての意見をまとめたメッセージ群）を、他のフォーラムに移動する技術を提供している。

特開２００３−３０１０３号公報

しかしながら、特許文献１における技術では、もともとメッセージが投稿されたあるフォーラムには残すことなく、そのフォーラムからメッセージまたはスレッドを他のフォーラムへ移動して、他のフォーラムへの投稿として閲覧可能とするものである。すなわち、移動した後は、移動元のフォーラムにおいては閲覧できなくなるという問題があった。

本発明は、上記問題に鑑み、スレッド（あるいはメッセージ）を、投稿元のフォーラムと他のフォーラムとで共有する仕組みを提供することを目的とする。

本発明は、クライアント端末と、ネットコミュニティに投稿されたメッセージを管理するコミュニティサーバと、がネットワークを介して接続可能なコミュニティシステムであって、前記クライアント端末は、前記ネットコミュニティに投稿された前記メッセージを分割して管理するフォーラムのうち、第１の該フォーラムにおいて、相互に関連付けられたメッセージのグループから構成されるスレッドの指定をユーザから受け付けるスレッド受付手段と、前記スレッド受付手段により受け付けた前記スレッドを共有させるための前記フォーラムを、第２の前記フォーラムとして、ユーザから受け付ける共有指定先フォーラム受付手段と、前記スレッドに関する紹介のメッセージを、ユーザから受け付ける紹介メッセージ受付手段と、前記スレッド受付手段により受け付けた前記スレッドと、前記紹介メッセージと、第２の前記フォーラムと、を共有要求として、該スレッドを共有するために前記コミュニティサーバに通知するスレッド共有要求通知手段と、を備え、前記コミュニティサーバは、前記フォーラムを、フォーラム記憶手段に記憶させるためのフォーラム登録手段と、前記フォーラムと、投稿された前記メッセージと、を対応付けてメッセージ情報としてメッセージ記憶手段に記憶させるメッセージ登録手段と、前記スレッド共有要求通知手段により通知された前記共有要求を受け付けるスレッド共有要求受付手段と、前記スレッド共有要求受付手段により受け付けた前記共有要求における前記紹介メッセージを、第２の前記フォーラムの前記メッセージとして投稿する投稿手段と、を備え、前記メッセージ記憶手段は、更に、前記紹介メッセージと、前記スレッドの情報を共有情報として記憶することを特徴とする。

本発明によれば、スレッド（あるいはメッセージ）を、投稿元のフォーラムと他のフォーラムとで共有することが可能となる。

本発明の実施形態に係わるシステム構成の一例を示す図である。 本発明の実施形態に係わるコミュニティサーバのハードウェア構成の一例を示すブロック図である。 本発明の実施形態に係わるコミュニティサーバのソフトウェア構成の一例を示す図である。 本発明の実施形態に係わるコミュニティにおけるフォーラムとメッセージの一覧を表示するＧＵＩ（グラフィカル・ユーザ・インタフェース）の一例を示す図である。 本発明の実施形態に係わるフォーラムとメッセージのデータ構成の一例を示す図である。 本発明の実施形態に係わる投稿されたメッセージに対するサブメッセージを投稿するＧＵＩの一例を示す図である。 本発明の実施形態に係わるメッセージ一覧において、投稿に従ってメッセージが追加される状態遷移の一例を示す図である。 本発明の実施形態に係わる投稿されたメッセージに対するコメントを投稿するＧＵＩの一例を示す図である。 本発明の実施形態に係わる投稿されたコメントに対するサブコメントを投稿するＧＵＩの一例を示す図である。 本発明の実施形態に係わるメッセージ、コメント、サブコメントの一覧を表示するＧＵＩの一例を示す図である。 本発明の実施形態に係わるメールからの投稿処理の一例を示すフローチャートである。ャートである。 本発明の実施形態に係わるＳＮＳユーザインタフェースからの投稿処理の一例を示すフローチャートである。 本発明の実施形態におけるフォーラムを共有するための共有指定元での操作を実施するＧＵＩの一例を示す図である。 本発明の実施形態におけるスレッドの共有指定先での表示状態の一例を示す図である。 本発明の実施形態におけるスレッドの共有指定先で紹介メッセージを展開した表示状態の一例を示す図である。 本発明の実施形態におけるスレッドを共有した場合のメッセージのデータ構成の一例を示す図である。 本発明の実施形態におけるスレッドの共有処理の一例を示すフローチャートである。 本発明の実施形態における共有されたスレッドの閲覧処理の一例を示すフローチャートである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

フォーラム記憶部３０８は、フォーラム名５０１、フォーラムメールアドレス５０２等のデータ項目から構成される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜フォーラムにおけるスレッドの共有に係わる実施形態＞
次に図１３から図１８を用いて、フォーラムにおけるスレッドの共有に係わる実施形態について説明する。

図１３は、本発明の実施形態におけるフォーラムを共有するための共有指定元での操作を実施するＧＵＩの一例を示す図である。ユーザがコミュニティサイトにおいて、共有指定元となるフォーラムにおいて、既に投稿されているメッセージ（ルートとなるメッセージ）を指定し、対応するスレッドを他の共有指定先となるフォーラムを指定するための操作を行う。

クライアント端末１０２においてユーザがあるフォーラムを表示（例えば図１０）、ルートとなるメッセージ（例えば図１０の１００１）を選択した状態で、図４のボタン（４０９）を押下すると、図１３のスレッドの共有画面１３００ａが表示される。

ここで、ルートとなるメッセージは、該メッセージの下位のメッセージ（前述の第２の実施形態においては、コメントおよびサブコメント）を関連付けて取得可能であるため、コミュニティシステムとしては、スレッド全体を選択されたのと同等の意味を持つ。従って、本実施形態ではルートとなるメッセージを選択したとして説明するが、下位のメッセージを選択した場合でも上位のメッセージにメッセージＩＤなどにより関連付けられ、スレッド全体の情報を取得可能である場合には、スレッドの選択と見なすこともできる。従って、以降では説明の便宜上、「共有のために（特にルートの）メッセージを選択する」、または「共有のためにスレッドを選択する」などの文言を区別不要な場合は同一の意味で用いることがある。

スレッドの共有画面１３００ａにおいては、選択したメッセージが共有するスレッドとして１３０２に表示される。また、該スレッドを共有指定先のフォームに移動する際に、そのスレッドを紹介するため、紹介メッセージ１３０１を入力するため、文字列入力フィールドを備える。

初期状態では、選択フォーラム欄１３０３ａには、スレッドを共有する他のフォーラムが指定されていない。スレッドを共有するフォーラムを指定するためには、ユーザは、１３０４を押下する。すると、フォーラム一覧１３１０が表示される。ユーザは、フォーラム一覧１３１０から１または複数のフォーラムを選択する。選択結果は、選択フォーラム欄１３０３ｂのように表示される。以上の操作をした後、ユーザが共有ボタン１３０５を押下することにより、選択されたスレッドは共有指定先のフォーラムに共有される。

ここで、ユーザによるスレッドの選択は１つのみであるが、複数選択可能としてもよい。また、複数のスレッドを選択した場合、紹介メッセージは、１つであり共通のものであってもよいし、それぞれ異なる紹介メッセージを入力可能としてもよい。本実施の形態はあくまで一例であり、その他の方法であってもよい。

図１４は、本発明の実施形態におけるスレッドの共有指定先での表示状態の一例を示す図である。図１３において説明した操作が実行された後、例えば、フォーラム「Ｂ事業部共有」の閲覧権限があるユーザが、閲覧すると、図１４のＧＵＩのように表示される。ここで図面の都合上、他のメッセージの記載は省略している。

共有指定先のフォーラムのＧＵＩ（１４００ｂ）においては、図１３の紹介メッセージ１３０１が、メッセージとして投稿されている（１４０１）。また、共有されたメッセージ（メッセージＡ、１４０２）も共有指定先のフォーラムから閲覧可能に表示されている。実際にメッセージＡ（１４０２）は、共有指定先のフォーラムに投稿されているわけではなく、共有指定元のフォーラム（例えば図１０）のメッセージに関連付けられ、共有されている。従って、共有指定元のフォーラムでは閲覧、サブメッセージが投稿できる等の状態に変更はない。

図１５は、本発明の実施形態におけるスレッドの共有指定先で紹介メッセージを展開した表示状態の一例を示す図である。

すなわち、図１４における紹介メッセージは、共有指定先のフォーラムにおいて通常のメッセージとして投稿されているため、投稿以降、サブメッセージを投稿していくことが可能である。紹介メッセージ（１４０１）をルートのメッセージとして、ユーザが押下するとスレッド内のサブメッセージ（１５０１）が展開される。

一方、共有されたメッセージ（１４０２）をユーザが押下した場合は、ＧＵＩは、共有指定元のフォーラムを表示するＧＵＩに移動し、例えば図１０の通りに表示される。その状態で、ユーザは共有されたメッセージに対するサブメッセージを投稿することができる。

図１６は、本発明の実施形態におけるスレッドを共有した場合のメッセージのデータ構成の一例を示す図である。

５１０は、図５で説明したメッセージ記憶部３０９である。図１６においては、図１３のスレッド共有の操作をする際に入力した紹介メッセージが、１つのメッセージとして登録されている（１６００）。

１６１０は、共有されたスレッドの情報を記憶する記憶部である。具体的には、メッセージ記憶部３０９の同一テーブルのデータ項目に組み込まれていてもよい（１６０３、１６０４）。あるいは、メッセージ記憶部３０９において、図５と関連付けられた他のテーブルとして１６０１から１６０４のデータ項目により構成されていてもよい。

また、メッセージが紹介メッセージか、通常のメッセージかを区別する必要がある。その方法として、前述のようにテーブルが分かれている場合には、５１０における５１１および５１２と、１６１０における１６０１および１６０２が一致するレコードがあるか否かで判定する。あるいは、前述の通り１６０３、１６０４が５１０と同一のテーブルに組み込まれている場合には１６０３、１６０４のデータ項目に値があるかｎｕｌｌ（または空）であるか否かで判定してもよい。また、データ項目として共有フラグを有し、ｔｒｕｅ（紹介メッセージ）、ｆａｌｓｅ（通常のメッセージ）の値により判定してもよい。以上の構成はあくまで一例である。

図１７は、本発明の実施形態におけるスレッドの共有処理の一例を示すフローチャートである。図１７の各ステップは、コミュニティサーバ１０１またはクライアント端末１０２のＣＰＵ２０１によって実行される。また、図１７のフローチャートの説明は、フォーラム（例えば図１０のＡ社プロジェクト）のメッセージが表示されている状態から開始する。

Ｓ１７０１においてクライアント端末は、ユーザからスレッド共有するスレッド（例えば図１０の１００１）の選択を受け付ける（スレッド受付部）。

Ｓ１７０２においてクライアント端末は、スレッド共有操作の画面データを、コミュニティサーバ１０１に要求する。具体的には、ユーザが図４の操作ボタン（４０９）を押下したことに受け付け、スレッド共有操作の画面（図１３の１３００）を表示するための画面データを、コミュニティサーバ１０１に要求する。

Ｓ１７０３においてコミュニティサーバ１０１は、クライアント端末１０２からスレッド共有操作の画面データの要求を受け付ける。

Ｓ１７０４においてコミュニティサーバ１０１は、クライアント端末１０２にスレッド共有操作の画面データを送信する。

Ｓ１７０５においてクライアント端末１０２は、スレッド共有操作の画面データを、コミュニティサーバ１０１から受信する。

Ｓ１７０６においてクライアント端末１０２は、スレッド共有操作の画面を表示する。

Ｓ１７０７においてクライアント端末１０２は、ユーザが選択した、スレッドの共有指定先のフォーラムを受け付ける（共有指定先フォーラム受付部）。

Ｓ１７０８においてクライアント端末１０２は、ユーザが入力した、紹介メッセージを受け付ける（紹介メッセージ受付部）。

Ｓ１７０９においてクライアント端末１０２は、ユーザにより前記選択されたスレッドの共有指示を受け付ける。具体的には、ユーザが図１３の共有ボタン１３０５の押下したことに基づき、指示を受け付ける。

Ｓ１７１０においてクライアント端末１０２は、ユーザにより選択されたスレッドを、ユーザにより指定された共有指定先のフォーラムと共有させるようコミュニティサーバ１０１に要求する（共有要求、スレッド共有要求通知部）。

Ｓ１７１１においてコミュニティサーバ１０１は、ユーザにより選択されたスレッドを、ユーザにより指定された共有指定先のフォーラムと共有させるよう送信されたクライアント端末１０２からの要求を受け付ける（スレッド共有要求受付部）。

Ｓ１７１２においてコミュニティサーバ１０１は、クライアント端末１０２においてユーザから受け付けた紹介メッセージを、共有指定先のフォーラムにメッセージ（メッセージ情報）として投稿する。具体的には、図１６の５１０のテーブルへの登録を行う（１６００）。

Ｓ１７１３においてコミュニティサーバ１０１は、クライアント端末１０２においてユーザにより選択されたスレッドを、ユーザにより指定された共有指定先のフォーラムと共有させるよう前記紹介メッセージと関連付けて共有情報とする。具体的には、図１６の１６１０のテーブルへの登録を行う。

以上で、図１７のフローチャートによるスレッド共有の処理について、説明を完了する。

図１８は、本発明の実施形態における共有されたスレッドの閲覧処理の一例を示すフローチャートである。図１８の各ステップは、コミュニティサーバ１０１またはクライアント端末１０２のＣＰＵ２０１によって実行される。図１８のフローチャートにより、スレッドの共有に係わる紹介メッセージ、共有指定元から共有指定されたメッセージ、通常に投稿されたメッセージ毎の動作の違いを説明する。また、図１８のフローチャートの説明は、フォーラム（例えば図１４のＢ事業部共有）において、メッセージＸ（紹介メッセージ）がクライアント端末１０２の表示装置に表示制御部により表示されている状態から開始する。この時点で、メッセージＡ＜共有指定元：Ａ社プロジェクト＞は表示されていないものとする。

Ｓ１８０１においてクライアント端末１０２は、共有指定先のフォーラム（例えば図１４のＢ事業部共有）においてユーザに選択されたメッセージ（例えば図１４のメッセージＸ（紹介メッセージ）＜共有指定元：Ａ社プロジェクト＞１４０１、あるいは同フォーラムで通常に投稿されたメッセージ）を受け付ける（展開スレッド受付部）。

Ｓ１８０２においてクライアント端末１０２は、前述のメッセージが紹介メッセージか否かを判定する（第１のスレッド判定部）。具体的には、表示されているメッセージに含まれている属性情報が、紹介メッセージか否かを判定する。あるいは、クライアント端末１０２は、コミュニティサーバ１０１に問い合わせることにより、Ｓ１８０２の判定がコミュニティサーバ１０１において処理されるようシステムを構成し、図１６で説明したメッセージ記憶部３０９の１６０３、１６０４に基づき判定するなど処理してもよい。紹介メッセージである場合（ＹＥＳの場合）には、Ｓ１８０３に進む。そうでない場合（ＮＯ、すなわち通常に投稿されたメッセージの場合）には、Ｓ１８１５に進む。

Ｓ１８０３においてクライアント端末１０２は、前述で選択された紹介メッセージと関連付けられたメッセージの取得を、コミュニティサーバ１０１に要求する（第１のスレッド情報要求部）。具体的には、紹介メッセージ（例えば、図１４のメッセージＸ（１４０１））を選択された場合には、紹介メッセージのフォーラム名、メッセージＩＤ（例えば図１６のＢ事業部共有（１６０１）、Ｘ（１６０２））を指定して、その時点では取得・表示されていない共有指定元のメッセージの取得を要求する。

Ｓ１８０４においてコミュニティサーバ１０１は、紹介メッセージ（例えばフォーラム名がＢ事業部共有、メッセージＩＤがＸ）の指定による共有指定元のメッセージ取得の要求を受け付ける（第１のスレッド情報要求受付部）。

Ｓ１８０５においてコミュニティサーバ１０１は、紹介メッセージの共有指定元のフォーラム名、メッセージのＩＤを取得する。具体的には、図１６のテーブル（１６１０）を１６０１、１６０２に基づく検索を実行し、共有指定元のフォーラム名（１６０３：例えばＡ社プロジェクト）、共有指定元ＩＤ（１６０４：例えばＡ）を取得する。さらに、前述で取得した共有指定元のフォーラム名、共有指定元ＩＤに基づき、メッセージに関する情報を取得する。具体的には、メッセージを図１６のテーブル（５１０）フォーラム名（５１１：例えばＡ社プロジェクト）、ＩＤ（５１２：例えばＡ）により特定されるメッセージの情報を取得する。

Ｓ１８０６においてコミュニティサーバ１０１は、前述で取得したメッセージの情報（例えばメッセージＡの情報）をクライアント端末１０２に送信する（第１のスレッド情報送信部）。

Ｓ１８０７においてクライアント端末１０２は、コミュニティサーバ１０１で送信されたメッセージの情報（例えばメッセージＡの情報）を受信する（第１のスレッド情報受信部）。

Ｓ１８０８においてクライアント端末１０２は、共有指定先のフォーラムにおいて、紹介メッセージおよび共有された共有指定元のメッセージの両方を表示する。例えば図１４のＢ事業部共有におけるメッセージＸ（紹介メッセージ）とメッセージＡ（共有されたメッセージ）のようなＧＵＩとなる。

Ｓ１８０９においてクライアント端末１０２は、紹介メッセージ（例えば図１４のメッセージＸ）および共有された共有指定元のメッセージ（例えば図１４のメッセージＡ）のうち、ユーザが選択したメッセージを受け付ける。

Ｓ１８１０においてクライアント端末１０２は、選択されたメッセージが紹介メッセージか共有された共有指定元のメッセージかを判定する（第２のスレッド判定部）。具体的には、Ｓ１８０２と同様に表示されているメッセージに含まれている属性情報が、紹介メッセージか否かを判定する。あるいは、クライアント端末１０２は、コミュニティサーバ１０１に問い合わせることにより、Ｓ１８１０がコミュニティサーバ１０１において処理されるようシステムを構成し、図１６で説明したメッセージ記憶部３０９の１６０３、１６０４に基づき判定するなど処理してもよい。選択されたメッセージが紹介メッセージである場合（ＹＥＳの場合）には、Ｓ１８１１に進む。共有されたメッセージである場合（ＮＯの場合）には、Ｓ１８１５に進む。

Ｓ１８１１においてクライアント端末１０２は、共有指定元のフォーラム（例えばＡ社プロジェクト）に移動し、共有されたメッセージ（例えばメッセージＡ）に対応するスレッドの情報（スレッドを構成する全てのメッセージの情報、以下共有されたスレッドという）の取得を、コミュニティサーバ１０１に要求する（第２のスレッド情報要求部）。

Ｓ１８１２においてコミュニティサーバ１０１は、共有されたスレッド（例えばメッセージＡに対応するスレッド）の情報取得の要求を受け付ける（第２のスレッド情報要求受付部）。

Ｓ１８１３においてコミュニティサーバ１０１は、共有されたスレッドを取得する。具体的には、図５のメッセージ記憶部５１０において共有されたスレッド（例えばフォーラム名（５１１）がＡ社プロジェクト、ＩＤ（５１２）が上位ＩＤ（５１４）を辿ることによりＡに関連する全てのメッセージ）の情報を取得する。

Ｓ１８１４においてコミュニティサーバ１０１は、共有されたスレッドをクライアント端末１０２に送信する（（第２のスレッド情報送信部））。

Ｓ１８１５においてクライアント端末１０２は、コミュニティサーバ１０１から共有されたスレッドを受信する（第２のスレッド情報受信部）。

Ｓ１８１６においてクライアント端末１０２は、ユーザにより共有指定先のフォーラムで選択されたメッセージ（紹介メッセージ（例えば図１４のメッセージＸ）または同フォーラムにて通常に投稿されたメッセージ）に対応するスレッドの情報取得を、コミュニティサーバ１０１要求する。具体的には、メッセージのフォーラム名、メッセージＩＤを指定してスレッド情報取得の要求を送信する。

Ｓ１８１７においてコミュニティサーバ１０１は、クライアント端末１０２から送信されたスレッドの情報取得の要求を受け付ける。具体的には、メッセージのフォーラム名、メッセージＩＤが指定されて、スレッド情報取得の要求を受け付ける。

Ｓ１８１８においてコミュニティサーバ１０１は、スレッドの情報を取得する。具体的には、前述の図５のメッセージ記憶部を、前述の要求としてメッセージ記憶部５１０において、フォーラム名（５１１）、メッセージＩＤ（５１２）が一致するメッセージをスレッド情報として取得する。

Ｓ１８１９においてコミュニティサーバ１０１は、スレッドの情報をクライアント端末１０２に送信する。

Ｓ１８２０においてクライアント端末１０２は、コミュニティサーバ１０１からスレッドの情報を受信する。

図１８のフローチャートによる共有されたスレッドの閲覧処理については、あくまで一例であり、クライアント端末１０２で説明されたステップがコミュニティサーバ１０１において動作してもよいし、逆にコミュニティサーバ１０１で説明されたステップがクライアント端末１０２において動作してもよい。
以上で、図１８のフローチャートによるスレッド共有の処理について、説明を完了する。

なお、紹介メッセージに係わるスレッドには共有指定先のフォーラムにて、また、共有指定元のメッセージに係わるスレッドには共有指定元のフォーラムにて、サブメッセージの投稿が可能である。

共有スレッドについては、共有指定元、共有指定先のスレッドとしていずれのフォーラムからも閲覧、投稿が可能となり、公開されている両フォーラムにおける意見交換及び情報共有が可能となるという効果を得ることができる。一方、紹介メッセージに対応するスレッドについては、共有指定先のフォーラムにおいてのみ閲覧、投稿が可能となり、共有指定先のフォーラムのユーザのみで意見交換を行い、必要な情報のみを共有されたスレッドに反映する事が可能になるという効果を得ることができる。

以上により、複数のフォーラム間での適切且つ柔軟な情報共有、及び意見交換が可能となるという効果を得ることができる。

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

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

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

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

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

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

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

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

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

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

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

Claims (9)

1. クライアント端末と、ネットコミュニティに投稿されたメッセージを管理するコミュニティサーバと、がネットワークを介して接続可能なコミュニティシステムであって、
   前記クライアント端末は、
   前記ネットコミュニティに投稿された前記メッセージを分割して管理するフォーラムのうち、第１の該フォーラムにおいて、相互に関連付けられたメッセージのグループから構成されるスレッドの指定をユーザから受け付けるスレッド受付手段と、
   前記スレッド受付手段により受け付けた前記スレッドを共有させるための前記フォーラムを、第２の前記フォーラムとして、ユーザから受け付ける共有指定先フォーラム受付手段と、
   前記スレッドに関する紹介のメッセージを、ユーザから受け付ける紹介メッセージ受付手段と、
   前記スレッド受付手段により受け付けた前記スレッドと、前記紹介メッセージと、第２の前記フォーラムと、を共有要求として、該スレッドを共有するために前記コミュニティサーバに通知するスレッド共有要求通知手段と、
   を備え、
   前記コミュニティサーバは、
   前記フォーラムを、フォーラム記憶手段に記憶させるためのフォーラム登録手段と、
   前記フォーラムと、投稿された前記メッセージと、を対応付けてメッセージ情報としてメッセージ記憶手段に記憶させるメッセージ登録手段と、
   前記スレッド共有要求通知手段により通知された前記共有要求を受け付けるスレッド共有要求受付手段と、
   前記スレッド共有要求受付手段により受け付けた前記共有要求における前記紹介メッセージを、第２の前記フォーラムの前記メッセージとして投稿する投稿手段と、
   を備え、
   前記メッセージ記憶手段は、更に、
   前記紹介メッセージと、前記スレッドの情報を共有情報として記憶することを特徴とするコミュニティシステム。
2. 前記クライアント端末は、更に、
   前記フォーラムにおける前記メッセージを前記クライアント端末の表示装置に表示させるための表示制御手段と、
   前記表示装置に表示された第２の前記フォーラムの前記メッセージを含む前記スレッドのうち、いずれの該スレッドに含まれる全ての該メッセージを展開して表示するかを指定するため、ユーザが指定した該スレッドを受け付ける展開スレッド受付手段と、
   前記展開スレッド受付手段により受け付けた前記スレッドが、前記紹介メッセージに対応する該スレッドであるか、共有された前記スレッドであるかを判定する第１のスレッド判定手段と、
   前記スレッドが、前記第１のスレッド判定手段により前記紹介メッセージに対応する該スレッドであると判定された場合には、共有された該スレッドの情報を前記コミュニティサーバに要求する第１のスレッド情報要求手段と、
   前記第１のスレッド情報要求手段に対して、前記コミュニティサーバから送信された共有された前記スレッドの情報を受け付ける第１のスレッド情報受信手段と、を備え、
   前記表示制御手段は、
   該紹介メッセージと、前記第１のスレッド情報受信手段で受け付けた共有された前記スレッドに対応する情報と、を前記表示装置に表示させるものであって、
   前記コミュニティサーバは、更に、
   前記クライアント端末における前記第１のスレッド情報要求手段を受け付ける第１のスレッド情報要求受付手段と、
   前記第１のスレッド情報要求受付手段により受け付けた前記スレッドの情報により、該スレッドの情報おける共有された前記スレッドの情報をメッセージ記憶手段から取得する第１のスレッド情報取得手段と、
   前記第１のスレッド情報取得手段により取得した共有された前記スレッドの情報を、前記クライアント端末に送信する第１のスレッド情報送信手段と、
   を備えることを特徴とする請求項１に記載のコミュニティシステム。
3. 前記クライアント端末は、更に、
   前記展開スレッド受付手段により受け付けた前記スレッドが、共有された該スレッドであるか否かを判定する第２のスレッド判定手段と、
   前記スレッドが、前記第２のスレッド判定手段により共有された該スレッドであると判定された場合には、共有された該スレッドの情報を前記コミュニティサーバに要求する第２のスレッド情報要求手段と、
   前記第２のスレッド情報要求手段に対して、前記コミュニティサーバから送信された共有された前記スレッドの情報を受け付ける第２のスレッド情報受信手段と、を備え、
   前記表示制御手段は、
   前記第２のスレッド情報受信手段で受け付けた共有された前記スレッドにおける全ての前記メッセージを、前記表示装置に展開して表示させるものであって、
   前記コミュニティサーバは、更に、
   前記クライアント端末における前記第２のスレッド情報要求手段を受け付ける第２のスレッド情報要求受付手段と、
   前記第２のスレッド情報要求受付手段により受け付けた前記スレッドの情報により、該スレッドの情報おける共有された前記スレッドの情報をメッセージ記憶手段から取得する第２のスレッド情報取得手段と、
   前記第２のスレッド情報取得手段により取得した共有された前記スレッドの情報に含まれる全ての前記メッセージを、前記クライアント端末に送信する第２のスレッド情報送信手段と、
   を備えることを特徴とする請求項２に記載のコミュニティシステム。
4. 前記表示制御手段は、
   前記第２のスレッド判定手段により、前記展開スレッド受付手段により受け付けた前記スレッドが、共有された該スレッドであると判定された場合には、該スレッドの共有を指示された共有指定元の前記フォーラムに表示状態を遷移し、該スレッドを展開して表示させることを特徴とする請求項２または請求項３に記載のコミュニティシステム。
5. 前記スレッド受付手段は、
   前記スレッドにおいて相互に関連付けられた前記メッセージのグループから、１つの該メッセージをユーザから受け付けるものであって、
   前記メッセージ記憶手段は、
   前記共有情報における前記スレッドの情報として、１つの前記メッセージの情報を記憶することを特徴とする請求項１乃至請求項４のいずれか１項に記載のコミュニティシステム。
6. 前記スレッド受付手段は、
   前記スレッドにおいて相互に関連付けられた前記メッセージのグループのうち、前記フォーラムに直接に関連付けられるルートの該メッセージをユーザから受け付けるものであって、
   前記メッセージ記憶手段は、
   前記共有情報における前記スレッドの情報として、ルートの前記メッセージの情報を記憶することを特徴とする請求項１乃至請求項５のいずれか１項に記載のコミュニティシステム。
7. クライアント端末と、ネットワークを介して接続可能なネットコミュニティに投稿されたメッセージを管理するコミュニティサーバであって、
   前記ネットコミュニティに投稿された前記メッセージを分割して管理するフォーラムを、フォーラム記憶手段に記憶させるためのフォーラム登録手段と、
   前記フォーラムと、投稿された前記メッセージと、を対応付けてメッセージ情報としてメッセージ記憶手段に記憶させるメッセージ登録手段と、
   第１の前記フォーラムにおいて共有させるべくユーザにより指定された相互に関連付けられたメッセージのグループから構成されるスレッドと、共有の指定をされた該スレッドに関する紹介のメッセージである紹介メッセージと、該スレッドの共有先として指定された第２の前記フォーラムと、を前記クライアント端末から共有要求として受け付けるスレッド共有要求受付手段と、
   前記スレッド共有要求受付手段により受け付けた前記共有要求における前記紹介メッセージを、第２の前記フォーラムの前記メッセージとして投稿する投稿手段と、
   を備え、
   前記メッセージ記憶手段は、更に、
   前記紹介メッセージと、前記スレッドの情報を共有情報として記憶することを特徴とするコミュニティサーバ。
8. クライアント端末と、ネットコミュニティに投稿されたメッセージを管理するコミュニティサーバと、がネットワークを介して接続可能なコミュニティシステムの制御方法であって、
   前記クライアント端末は、
   スレッド受付手段が、前記ネットコミュニティに投稿された前記メッセージを分割して管理するフォーラムのうち、第１の該フォーラムにおいて、相互に関連付けられたメッセージのグループから構成されるスレッドの指定をユーザから受け付けるスレッド受付ステップと、
   共有指定先フォーラム受付手段が、前記スレッド受付ステップにより受け付けた前記スレッドを共有させるための前記フォーラムを、第２の前記フォーラムとして、ユーザから受け付ける共有指定先フォーラム受付ステップと、
   紹介メッセージ受付手段が、前記スレッドに関する紹介のメッセージを、ユーザから受け付ける紹介メッセージ受付ステップと、
   スレッド共有要求通知手段が、前記スレッド受付ステップにより受け付けた前記スレッドと、前記紹介メッセージと、第２の前記フォーラムと、を共有要求として、該スレッドを共有するために前記コミュニティサーバに通知するスレッド共有要求通知ステップと、
   を備え、
   前記コミュニティサーバは、
   フォーラム登録手段が、前記フォーラムを、フォーラム記憶手段に記憶させるためのフォーラム登録ステップと、
   メッセージ登録手段が、前記フォーラムと、投稿された前記メッセージと、を対応付けてメッセージ情報としてメッセージ記憶手段に記憶させるメッセージ登録ステップと、
   スレッド共有要求受付手段が、前記スレッド共有要求通知ステップにより通知された前記共有要求を受け付けるスレッド共有要求受付ステップと、
   投稿手段が、前記スレッド共有要求受付ステップにより受け付けた前記共有要求における前記紹介メッセージを、第２の前記フォーラムの前記メッセージとして投稿する投稿ステップと、
   を備え、
   前記メッセージ記憶手段は、更に、
   前記紹介メッセージと、前記スレッドの情報を共有情報として記憶することを特徴とするコミュニティシステムの制御方法。
9. クライアント端末と、ネットコミュニティに投稿されたメッセージを管理するコミュニティサーバと、がネットワークを介して接続可能なコミュニティシステムにおいて実行可能なプログラムであって、
   前記クライアント端末を、
   前記ネットコミュニティに投稿された前記メッセージを分割して管理するフォーラムのうち、第１の該フォーラムにおいて、相互に関連付けられたメッセージのグループから構成されるスレッドの指定をユーザから受け付けるスレッド受付手段、
   前記スレッド受付手段により受け付けた前記スレッドを共有させるための前記フォーラムを、第２の前記フォーラムとして、ユーザから受け付ける共有指定先フォーラム受付手段、
   前記スレッドに関する紹介のメッセージを、ユーザから受け付ける紹介メッセージ受付手段、
   前記スレッド受付手段により受け付けた前記スレッドと、前記紹介メッセージと、第２の前記フォーラムと、を共有要求として、該スレッドを共有するために前記コミュニティサーバに通知するスレッド共有要求通知手段、
   として機能させ、
   前記コミュニティサーバを、
   前記フォーラムを、フォーラム記憶手段に記憶させるためのフォーラム登録手段、
   前記フォーラムと、投稿された前記メッセージと、を対応付けてメッセージ情報としてメッセージ記憶手段に記憶させるメッセージ登録手段、
   前記スレッド共有要求通知手段により通知された前記共有要求を受け付けるスレッド共有要求受付手段、
   前記スレッド共有要求受付手段により受け付けた前記共有要求における前記紹介メッセージを、第２の前記フォーラムの前記メッセージとして投稿する投稿手段、
   として機能させ、
   前記メッセージ記憶手段は、更に、
   前記紹介メッセージと、前記スレッドの情報を共有情報として記憶することを特徴とするプログラム。
   

Images