JP4892049B2 - 情報共有システム - Google Patents

Description

本発明は、電子メールで投稿される記事を共有する情報共有システムに係り、例えば他の情報共有システムに対しても、記事を受け渡しして情報を共有（以下、連携ともいう）し得る情報共有システムに関する。

近年、パーソナルコンピュータ等の計算機とネットワークとを利用して、複数のユーザ間で情報を交換するための電子的なコミュニケーション手段が広く普及している。電子メールやメーリングリスト、電子掲示板、ニュースグループなどに代表されるコミュニケーション手段は、すでに日常的な業務や個人間の交流に欠かせない手段となっている。

しかし、部門や会社をまたがった情報交換を行う際、上記の手段をどこで運用するか、という問題が発生する。この問題への対応方法としては、ひとつは第三者の組織が運用しているサービスを使用することである。この場合は業務機密などを外部組織におくことになってしまう。また、主体となる組織を決め、その組織が運用するサービスを使用することもある。この場合は、情報の記録を相手にゆだねることで主体性を確保できなくなること、記録している情報へのアクセス管理権を相手にまかせることになることで、データの管理が自由に行えない課題がのこる。

そのため、例えば電子メールのやり取りの場合、あえてメーリングリストや電子掲示板を使わずに、電子メールのあて先を複数設定し、関係者すべてにメールを送ったり、複数のメーリングリストに投稿（クロスポスト）することが一般的である。

しかし、この場合、投稿者は本人の意思でメールを送信するたびに複数の宛先を設定しなければならない。そのため、投稿者の手間が増えるだけでなく、誤って宛先に指定し忘れると、そのグループには情報が伝達されないという問題が残る。

また、他の従来の技術として、電子メールをやりとりしている本人同士以外の第三者が、そのやり取りの内容を掲示板で閲覧可能とし、電子メールの情報の共有化を行う方式が知られている（特許文献１参照）。

この特許文献１に記載の技術を用いることで、社内ネットワーク内であれば、部門の垣根を越えて情報を共有することも可能である。

しかし、社内ネットワーク外のグループやユーザとの間で情報を共有する場合には、情報セキュリティや個人情報の観点から、これらのグループおよびユーザを社内システムに登録することはできない。

そのため、社外の人間に情報を伝達する場合には、その社内の人間には特許文献１に記載の技術を用いて情報を伝達し、社外の人間には電子メールを用いるなどの作業が必要になる。したがって、上記の従来技術の問題点と同様に、投稿者の手間の増加およびヒューマンエラーの問題が残る。そこで、投稿者が意識的に複数の宛先を設定することなく、また、社内ネットワーク外のグループとも情報を共有できることが望ましい。このことは、例えば複数の情報共有システムを用い、各情報共有システム間で情報が共有可能になれば実現できると考えられる。

特開２００５−８４８４４号公報

以上説明したように、特許文献１に記載のような情報共有システムは、社内ネットワーク内であれば特に問題はないが、本発明者の検討によれば、複数の情報共有システム間で情報を共有していない点で改良の余地がある。

例えば、営業部門の情報共有システムと、製品開発部門の情報共有システムとは、営業目的と製品開発目的のように目的が異なるために別々に運営されてユーザの個人情報も別々に登録されるが、市場ニーズに応える等の共通の目的をもつ場合があるので、記事を受け渡しして共有できる方がより望ましい。すなわち、複数の情報共有システム間でも記事を連携できる方がより望ましい。

本発明は上記実情を考慮してなされたもので、他の情報共有システムに対しても情報を共有し得る情報共有システムを提供することを目的とする。

本発明の一つの局面は、互いに電子メールを送受信可能なサーバ装置及び各ユーザ端末を備えた複数の情報共有システムにおける各々の情報共有システムであって、前記サーバ装置としては、他の情報共有システムのサーバアドレスを記憶する連携先情報記憶手段と、電子メール毎に、送信日時、投稿者名、タイトル及び本文を含むメール内容情報と、連携元のユニークＩＤ及び元記事情報とを関連付けて記憶するための記事情報記憶手段と、いずれかのユーザ端末から電子メールを受信したとき、この電子メールのメール内容情報と、当該電子メールを示す前記連携元のユニークＩＤと、当該電子メールに含まれる履歴元メールの連携元のユニークＩＤからなる元記事情報とを関連付けて前記記事情報記憶手段に書き込む手段と、前記受信した電子メールを記事メールとして前記各ユーザ端末に送信する第１の記事メール送信手段と、前記受信した電子メールに前記記事情報記憶手段内の連携元のユニークＩＤ及び元記事情報を付加して連携メールを作成する連携メール作成手段と、前記作成された連携メールを、前記連携先情報記憶手段内のサーバアドレスに基づいて送信する連携メール送信手段と、他のサーバ装置から連携メールを受信したとき、この連携メールのメール内容情報と、当該連携メールに含まれる連携元のユニークＩＤ及び元記事情報とを関連付けて送出する連携記事送出手段と、前記連携記事送出手段により送出されたメール内容情報、連携元のユニークＩＤ及び元記事情報を関連付けて前記記事情報記憶手段に書き込む連携記事書込手段と、前記受信した連携メールを記事メールとして前記各ユーザ端末に送信する第２の記事メール送信手段と、を備えた情報共有システムである。

なお、本発明の一つの局面は、サーバ装置及び各ユーザ端末からなる各装置の集合体を「システム」として表現したが、これに限らず、各装置の集合体又は各装置について、「装置」、「方法」、「プログラム」又は「プログラムを記憶したコンピュータ読取り可能な記憶媒体」として表現することができる。

（作用）
本発明の一つの局面においては、情報共有システムのサーバ装置は、いずれかのユーザ端末から電子メールを受信したとき、この電子メールの内容と、当該電子メールを示す連携元のユニークＩＤと、当該電子メールに含まれる履歴元メールの連携元のユニークＩＤからなる元記事情報とを関連付けて記事情報記憶手段に書き込む。また、サーバ装置は、受信した電子メールを記事メールとして各ユーザ端末に送信する。

また、サーバ装置は、受信した電子メールに記事情報記憶手段内の連携元のユニークＩＤ及び元記事情報を付加して連携メールを作成し、作成された連携メールを他のサーバ装置に送信する。

サーバ装置は、他のサーバ装置から連携メールを受信したとき、この連携メールの内容、当該連携メールに含まれる連携元のユニークＩＤ及び元記事情報を関連付けて記事情報記憶手段に書き込む。また、サーバ装置は、受信した連携メールを記事メールとして各ユーザ端末に送信する。

以上のように、情報共有システムのサーバ装置は、投稿された電子メールの記事を登録し、記事メールとして各ユーザ端末に送信した後、記事メールを連携させる連携メールを他の情報共有システムに送信し、他の情報共有システムのサーバ装置から受信した連携メールの記事を登録し、記事メールとして各ユーザ端末に送信する。

従って、情報共有システムは、他の情報共有システムに対しても情報を共有することができる。

以上説明したように本発明によれば、他の情報共有システムに対しても情報を共有できる。

本発明の第１の実施形態に係る記事連携システムの概略を示す模式図である。 同実施形態における各々の情報共有システムからなる記事連携システムの構成を示す模式図である。 同実施形態におけるタスク設定ファイルの一例を示す模式図である。 同実施形態におけるシステム設定ファイルの一例を示す模式図である。 同実施形態における連携先情報の一例を示す模式図である。 同実施形態における記事情報の一例を示す模式図である。 同実施形態におけるユーザ情報の一例を示す模式図である。 同実施形態における連携元の情報共有システムの動作を説明するためのフローチャートである。 同実施形態における電子メールの一例を示す模式図である。 同実施形態における記事メールの一例を示す模式図である。 同実施形態における連携メールの一例を示す模式図である。 同実施形態における連携先の情報共有システムの動作を説明するためのフローチャートである。 同実施形態における記事メールの一例を示す模式図である。 同実施形態における新規投稿時の動作を示す模式図である。 同実施形態における２番目の投稿時の動作を示す模式図である。 同実施形態における２番目の投稿時における電子メールの一例を示す模式図である。 同実施形態における２番目の投稿時における記事メールの一例を示す模式図である。 同実施形態における２番目の投稿時における連携メールの一例を示す模式図である。 同実施形態における２番目の投稿時における記事メールの一例を示す模式図である。 本発明の第２の実施形態に係る連携先の情報共有システムの動作を説明するためのフローチャートである。 同実施形態の第１の変形例における連携メールの一例を示す模式図である。 同変形例における動作を説明するための模式図である。 同実施形態の第２の変形例における動作を説明するための模式図である。 本発明の第３の実施形態に係る連携先の情報共有システムの動作を説明するためのフローチャートである。 同実施形態における連携元の情報共有システムの動作を説明するためのフローチャートである。 同実施形態における連携メールの一例を示す模式図である。 本発明の第４の実施形態に係る情報共有システムの未到着記事情報記憶部の構成を示す模式図である。 同実施形態における連携先の情報共有システムの動作を説明するためのフローチャートである。 同実施形態における動作を説明するための模式図である。 同実施形態における動作を説明するための模式図である。 同実施形態の変形例における連携記事記憶部の構成を示す模式図である。 同変形例における動作を説明するためのフローチャートである。 同変形例における動作を説明するための模式図である。

以下、本発明の各実施形態について図面を用いて説明するが、その前に、各実施形態の概要を述べる。各実施形態の概要は、他の情報共有システムに対しても情報を共有可能な各情報共有システムからなる記事連携システムに関するものである。ここで、第１の実施形態では、基本の構成及び処理の流れを述べており、第２乃至第４の実施形態では、連携メールに遅延が発生した場合の処理を述べている。

例えば、第１の実施形態では、図１に概略を示すように、記事連携システム１が複数の情報共有システム２Ａ，２Ｂ，２Ｃからなり、各情報共有システム２Ａ，２Ｂ，２Ｃが各ユーザ端末３Ａ，３Ｂ，３Ｃとサーバ装置４Ａ，４Ｂ，４Ｃとを備えた基本構成を述べている。なお、参照符号末尾のアルファベットＡ，Ｂ，Ｃは、各々の情報共有システムを示す情報共有システムＩＤを示している。各情報共有システム２Ａ，２Ｂ，２Ｃの個数は任意であり、同様に、ユーザ端末３Ａ，３Ｂ，３Ｃの台数も任意である。また、第１の実施形態では、図１中の丸数字に対応する次の（１）〜（６）に示す処理の流れを述べている。

（１）情報共有システム２Ａのあるユーザ端末３Ａが電子メールで記事をサーバ装置４Ａに投稿する。（２）情報共有システム２Ａのサーバ装置４Ａは、投稿された電子メールの記事をタスクＡ００１に登録し、（３）記事メールを各ユーザ端末３Ａに送信した後、（４）記事メールを連携させる連携メールを他の情報共有システム２Ｂ，２Ｃに送信する。（５）各情報共有システム２Ｂ，２Ｃのサーバ装置４Ｂ，４Ｃは、連携メールの記事をタスクＢ００１，Ｃ００１に登録し、（６）記事メールを各ユーザ端末３Ｂ，３Ｃに送信する。なお、ここでいう「タスクＡ００１に登録」及び「タスクＢ００１，Ｃ００１に登録」は、それぞれ「当該サーバ装置４Ａ内の記事情報記憶部４０３に登録」及び「当該サーバ装置４Ｂ，４Ｃ内の記事情報記憶部４０３に登録」を意味している。

一方、第２の実施形態では、連携メールに遅延が発生した場合に関し、連携先で待つ処理を述べており、第３の実施形態では、連携元で待つ処理を述べている。第４の実施形態では、待たずに島を作成する処理（孤立した記事を登録する処理）を述べている。以上が各実施形態の概要である。

このような各実施形態においては、装置４Ａ，４Ｂ，４Ｃ，３Ａ，３Ｂ，３Ｃ毎に、ハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体から対応する装置のコンピュータにインストールされ、対応する装置の機能を実現させるためのプログラムが用いられる。

続いて、第１の実施形態から順次、具体的に説明する。

（第１の実施形態）
図２は本発明の第１の実施形態に係る各々の情報共有システムからなる記事連携システムの構成を示す模式図である。この記事連携システム１は、複数の独立した情報共有システム２Ａ，２Ｂ，２Ｃを備えている。各々の情報共有システム２Ａ，２Ｂ，２Ｃは、各ユーザ端末３Ａ，３Ｂ，３Ｃの情報共有に関する機能ブロックについては互いに同一構成であり、サーバ装置４Ａ，４Ｂ，４Ｃの情報共有に関する機能ブロックについても互いに同一構成であるため、ここでは１つの情報共有システム２Ａを代表例に挙げて説明する。

情報共有システム２Ａは、互いに電子メールを送受信可能な複数のユーザ端末３Ａ及びサーバ装置４Ａを備えている。

ユーザ端末３Ａは、サイト連携設定部３１、記事投稿部３２、記事閲覧部３３、メール送信部３４、メール受信部３５及びメモリ３６を備えたパーソナルコンピュータである。

サイト連携設定部３１は、サーバ装置４Ａによるアクセス制御に応じて、サイト連携情報及び連携先情報をサーバ装置４Ａに設定するものであって、具体的には、ユーザの操作により、サイト連携情報及び連携先情報をそれぞれユーザ端末３Ａに入力する機能と、当該入力したサイト連携情報及び連携先情報をそれぞれサーバ装置４Ａに送信する機能をもっている。

記事投稿部３２は、サーバ装置４Ａによるアクセス制御に応じて、記事をサーバ装置４Ａに投稿するものであって、具体的にはユーザの操作により、記事としての電子メールを作成する機能と、当該作成した電子メールをサーバ装置４Ａに送信する機能をもっている。

記事閲覧部３３は、サーバ装置４Ａによるアクセス制御に応じて、サーバ装置４Ａに蓄積された記事を閲覧するためのものであり、具体的には、ユーザの操作により、サーバ装置４Ａにアクセスして記事を閲覧する機能をもっている。

メール送信部３４は、ユーザの操作により、電子メールをサーバ装置４Ａに送信する機能をもっている。

メール受信部３５は、サーバ装置４Ａから送信された電子メールを受信し、当該受信した電子メールをメモリ３６に書き込む機能をもっている。

メモリ３６は、各部３１〜３５から読出／書込可能な記憶部であり、例えば、送信前のサイト連携情報、送信前の記事としての電子メール、受信した閲覧データ、送信用の電子メール、受信した電子メール等が記憶される。

サーバ装置４Ａは、アクセス制御部４１、メール受信部４２、メール送信部４３、サイト連携情報登録部４４、記事登録部４５、連携判定部４６、メール内容解析部４７、メール作成部４８、連携記事作成部４９、サイト連携情報記憶部４０１、連携先情報記憶部４０２、記事情報記憶部４０３、タスク情報記憶部４０４及びユーザ情報記憶部４０５を備えている。各記憶部４０１〜４０５は、一つの記憶部として設けてもよい。

アクセス制御部４１は、ユーザ端末４Ａからのアクセスを制御するアクセス制御機能をもっている。アクセス制御機能は、例えば、ユーザＩＤ毎に、パスワード、サイト連携設定部３１からのアクセスの許可又は拒否、記事投稿部３２からのアクセスの許可又は拒否、記事閲覧部３３からのアクセスの許可又は拒否、といったアクセス権情報を図示しないメモリに記憶しておき、各部３１，３２，３３からのアクセス要求に応じて当該メモリを参照しながらアクセスを許可又は拒否する機能である。アクセスの許可又は拒否は、読出の許可又は拒否と、書込の許可又は拒否とに分けてもよい。但し、このようなアクセス制御部４１及びアクセス制御は、記事連携動作には影響しないので、省略してもよい。

メール受信部４２は、ユーザ端末３Ａから送信された電子メールを受信する機能と、他のサーバ装置４Ｂ，４Ｃから送信された連携メールを受信する機能と、当該受信した電子メール又は連携メールをそれぞれ連携判定部４６に送出する機能をもっている。

メール送信部４３は、受信した電子メール又は連携メールを記事メールとして各ユーザ端末３Ａに送信すると共に、作成された連携メールを他のサーバ装置３Ｂ，３Ｃに送信するものであって、具体的には、メール作成部４８から送出された記事メールをユーザ端末３Ａに送信する機能と、メール作成部４８から送出された連携メールを他のサーバ装置４Ｂ，４Ｃに送信する機能をもっている。

サイト連携情報登録部４４は、ユーザ端末３Ａからアクセス制御部４１を介して受けたサイト連携情報をサイト連携情報記憶部４０１に書き込む機能と、ユーザ端末３Ａからアクセス制御部４１を介して受けた連携先情報を連携情報記憶部４０２に書き込む機能とをもっている。

記事登録部４５は、ユーザ端末３Ａからアクセス制御部４１を介して受信した電子メールの情報を記事情報記憶部４０３に書き込む機能と、受信した電子メールの情報をメール送信部４３に送出する機能と、連携判定部４６から受けた電子メールの情報を記事情報記憶部４０３に書き込む機能とをもっている。

連携判定部４６は、記事登録部４５又はメール受信部４２から受けた電子メール又は連携メールについて、連携メールか否かを判定する機能と、電子メール及び連携メールを記事情報記憶部４０３に書き込むように記事登録部４５に送出する機能と、判定結果に応じて連携メール又は記事メールを作成するようにメール作成部４８を制御する機能とをもっている。

メール内容解析部４７は、連携判定部４６から受けた電子メールの内容を解析する機能と、当該解析した結果を連携判定部４６に送出する機能とをもっている。

メール作成部４８は、記事登録部４５又は連携判定部４６に制御され、連携メール又は記事メールを作成する機能と、作成した連携メール又は記事メールをメール送信部４３に送出する機能とをもっている。

連携記事作成部４９は、連携判定部４６に制御され、連携記事を作成する機能をもっている。

サイト連携情報記憶部４０１は、各部４１〜４９から読出／書込可能な記憶部であり、ここではサイト連携情報登録部４４から書き込まれたサイト連携情報を記憶している。

ここで、サイト連携情報は、タスク設定ファイル及びシステム設定ファイルから構成される。

タスク設定ファイルは、図３（ａ）〜図３（ｃ）に示すように、各情報共有システム２Ａ，２Ｂ，２Ｃ間の連携の許可又は拒否を示す連携可否情報、連携ＩＤ、投稿先のタスクＩＤ及びサーバアドレスを関連付けた設定ファイルであり、サイト連携情報記憶部４０１に記憶される。連携ＩＤは、記事連携システム１で一意の情報である。また、タスク設定ファイルは、サイト連携の説明文を設定してもよい。但し、サイト連携の説明文は任意の付加的事項であり、省略してもよい。また、図３（ａ）、図３（ｂ）及び図３（ｃ）はそれぞれ情報共有システム２Ａ，２Ｂ，２Ｃのタスク設定ファイルを示している。また、全ての電子メールを連携する場合、タスク設定ファイルは省略可能である。

システム設定ファイルは、図４に示すように、システムとしてサイト間連携を許可する／許可しないを表す情報と、連携実行間隔とを関連付けた設定ファイルであり、サイト連携情報記憶部４０１に記憶される。但し、以下の各実施形態は、記事連携（サイト連携）を実行することが前提であるので、このシステム設定ファイルは省略してもよい。

サイト連携情報は、連携する全ての情報共有システム２Ａ，２Ｂ，２Ｃで設定する必要がある。一方の情報共有システムしか設定しない場合は、片方向の連携となる。

連携先情報記憶部４０２は、各部４１〜４９から読出／書込可能な記憶部であり、ここでは連携情報を記憶している。連携情報は、図５に示すように、各情報共有システム間の連携ＩＤ、連携先の情報共有システムＩＤ、連携先のタスクＩＤ及びサーバアドレスを関連付けた情報である。連携ＩＤは、サイト連携情報の設定時に振られる一意の番号であることを想定している。連携情報は、連携先タスクＩＤ毎に別の行として表現している。但し、連携先のタスクＩＤが連携先の情報共有システムＩＤを含んでいるので、連携先の情報共有システムＩＤは省略してもよい。また、全ての電子メールを連携する場合、連携先のサーバアドレス以外の情報（連携ＩＤ、連携先の情報共有システムＩＤ、連携先のタスクＩＤ）は、連携先情報から省略可能である。

記事情報記憶部４０３は、各部４１〜４９から読出／書込可能な記憶部であり、受信した電子メールの内容を閲覧可能とするための記事情報を記憶している。記事情報は、電子メール毎に、送信日時、投稿者名、タイトル及び本文を含むメール内容情報と、連携元のユニークＩＤ及び元記事情報とを関連付けた情報であり、ここでは図６に示すように、サーバ内記事ＩＤ、添付ファイル及び記事のユニークＩＤを更に関連付けている。サーバ内記事ＩＤは、電子メールの記事が記事情報記憶部４０３に登録された際にサーバ内で振られるサーバ装置４Ａ内で一意の番号である。記事のユニークＩＤは、サーバ内記事ＩＤとは異なり、記事連携システム１内で一意の番号であり、例えば電子メールのメッセージＩＤが使用可能となっている。但し、サーバ内記事ＩＤ及び記事のユニークＩＤは、記事連携動作には影響しないので、省略してもよい。連携元のユニークＩＤ（例、A001004）は、電子メールを示す情報であり、連携元の情報共有システムＩＤ（例、A）と連携元のタスクＩＤ（例、A001）及びサーバ内記事ＩＤ（例、004）を組み合わせた番号で、オリジナルの記事の在り処を示す。但し、この例では、連携元のタスクＩＤ（例、A001）が連携元の情報共有システムＩＤ（例、A）を含んでいるので、連携元の情報共有システムＩＤとの組み合わせを省略している。

タスク情報記憶部４０４は、各部４１〜４９から読出／書込可能な記憶部であり、例えば、投稿先のタスクＩＤ及び当該タスクの説明文を含むタスク情報を記憶している。但し、タスク情報記憶部４０４は、記事連携動作には影響しないため、省略してもよい。タスクの説明文は、例えば、「タスクとは、共通の関心分野、価値観や目的を持った利用者が集まって持続的に相互作用する場のことを指す。」といったタスクの定義に基づいて、当該タスクにおける「共通の関心分野、価値観や目的」、「利用者」及び「持続的に相互作用する場」などの説明などを含んでいる。

ユーザ情報記憶部４０５は、各部４１〜４９から読出／書込可能な記憶部であり、同一情報共有システム２Ａに属するユーザ端末３Ａのユーザ情報を記憶している。ユーザ情報は、例えば図７（ａ）〜図７（ｃ）に示すように、電子メールの投稿先のタスクＩＤ、ユーザＩＤ、ユーザ名及びユーザアドレスを関連付けた情報である。ここで、図７（ａ）、図７（ｂ）及び図７（ｃ）はそれぞれ情報共有システム２Ａ，２Ｂ，２Ｃのユーザ情報を示している。但し、ユーザＩＤ及びユーザ名は、記事連携動作には影響しないので、省略してもよい。

次に、以上のように構成された記事連携システムの動作を説明する。以下の説明は、サイト連携情報の設定動作及び記事の投稿動作の順に述べる。記事の投稿動作は、連携元の情報共有システムの動作及び連携先の情報共有システムの動作の順に説明する。

［サイト連携情報の設定動作］
各ユーザ端末３Ａ，３Ｂ，３Ｃでは、各ユーザの操作により、サイト連携設定部３１がシステム設定及びタスク設定ファイルを作成し、当該システム設定及びタスク設定ファイルからなるサイト連携情報をサーバ装置４Ａ，４Ｂ，４Ｃに送信する。

サーバ装置４Ａ，４Ｂ，４Ｃにおいては、サイト連携情報登録部４４が、サイト連携情報をサイト連携情報記憶部４０１に書き込む。

なお、サイト連携情報の書込は、連携を行う全ての情報共有システム２Ａ，２Ｂ，２Ｃで行う必要がある。一方の情報共有システム２Ａ，２Ｂ又は２Ｃしかサイト連携情報を書き込まない場合は、片方向の連携となる。

［記事の投稿動作］
ある情報共有システム２Ａにおいて、あるユーザ端末３Ａがサーバ装置４Ａに電子メールを送信して記事を投稿した場合を例に挙げ、連携元の情報共有システム２Ａ及び連携先の情報共有システム２Ｂ，２Ｃの動作を説明する。なお、記事を投稿したユーザ端末３Ａ，３Ｂ又は３Ｃが属する情報共有システム２Ａ，２Ｂ又は２Ｃを「連携元」と呼び、記事を投稿したユーザ端末３Ａ，３Ｂ又は３Ｃが属さない情報共有システム２Ａ，２Ｂ又は２Ｃを「連携先」と呼ぶ。連携元及び連携先は、記事を投稿したユーザ端末３Ａ，３Ｂ又は３Ｃが属するか否かに応じて交替する。

［連携元の情報共有システム：図８］
ユーザ端末３Ａは、ユーザの操作により、記事投稿部３２が、例えば図９に示す如き、送信日時、投稿者名、投稿先のタスクＩＤ、タイトル、本文及び添付ファイルを含む電子メールをサーバ装置４Ａに送信することにより、記事を投稿する（ＳＴ１）。なお、電子メールは、添付ファイル又は本文を含まなくてもよく、このことはユーザ端末３Ａ，３Ｂ，３Ｃから投稿される全ての電子メールで同様である。

サーバ装置４Ａにおいては、記事登録部４５が、記事を受け取り、記事情報記憶部４０２に登録する（ＳＴ２）。詳しくは、記事登録部４５は、いずれかのユーザ端末３Ａから電子メールを受信したとき、例えば図９に示した電子メールであれば、図６の１行目のデータに示すように、この電子メールの送信日時“2009/08/01 10:00”、投稿者名“山田一郎”、タイトル“…”、本文“…”及び添付ファイル“…”と（但し、それぞれ“…”は任意の内容）、当該電子メールに含まれる投稿先のタスクＩＤ“A001”に新たな（サーバ内）記事ＩＤ“001”を付して得られた連携元のユニークＩＤ“A001001”とを関連付けて記事情報記憶部４０３に書き込むと共に、この電子メールが履歴元メールの連携元のユニークＩＤからなる元記事情報を含む場合には更に、得られた連携元のユニークＩＤに当該元記事情報を関連付けて記事情報記憶部４０３に書き込む。但し、図９の例では、元記事情報を含まないので、図６の１行目のデータに示すように、元記事情報は書き込まれない。また、記事登録部４５は、受信した電子メールをメール送信部４３及び連携判定部４６に送出する。

メール送信部４３は、受信した電子メールに基づき、ユーザ情報記憶部４０５から該当タスクのユーザアドレスを取得し、各ユーザ端末３Ａに記事メールを送信する（ＳＴ３）。詳しくは、メール送信部４３は、例えば、受信した電子メールに含まれる投稿先のタスクＩＤ“A001”に基づいてユーザ情報記憶部４０５内のユーザアドレス“yamada-ichiro@succeedAtoshi-sol.co.jp”，“ito-shiro@succeedAtoshi-sol.co.jp”を読出し、図１０に示すように、このユーザアドレスに基づいて当該電子メールを記事メールとして送信（転送）する。

次に、サーバ装置４Ａにおいては、連携判定部４６が、記事登録部４５を介して受信した電子メールが連携対象かを判定する（ＳＴ４）。この判定は、必ずしも連携可否情報を用いなくても、記事が投稿されたタスクのＩＤがサイト連携情報記憶部４０１に有るか否かに応じて実行可能である。但し、ここでは、連携判定部４６は、受信した電子メール内の投稿先のタスクＩＤ“A001”に基づいてサイト連携情報記憶部４０１内のタスク設定ファイルの連携可否情報“許可”を参照し、当該電子メールの連携の許可又は拒否を判定する。

連携判定部４６は、ステップＳＴ４で連携対象（連携の許可）と判定した電子メールに対し、元記事情報を含まない新規投稿の電子メールであるか否かを判定し（ＳＴ５）、判定結果をメール作成部４８に送出する。

メール作成部４８は、ステップＳＴ５の判定の結果、新規投稿の電子メールではないとき、この電子メールに対応する記事情報記憶部４０３内の元記事情報からなる連携元のスレッド情報を作成し（ＳＴ６）、この電子メールに記事情報記憶部４０３内の連携元のユニークＩＤ及び連携元のスレッド情報（元記事情報）を付加して連携メールを作成する（ＳＴ７）。但し、図９の例は新規投稿の電子メールを示している。

そこで、メール作成部４８は、ステップＳＴ５の判定の結果、新規投稿の電子メールのとき、この電子メールに記事情報記憶部４０３内の連携元のユニークＩＤ“A001001”を付加して連携メールを作成する（ＳＴ７）。

メール送信部４３は、ステップＳＴ７で作成された連携メールを、図１１に示すように、連携先情報記憶部４０２内のサーバアドレス“taskacount1@succeedB.toshi-sol.co.jp”，“taskacount1@succeedC.toshi-sol.co.jp”に基づいて送信する（ＳＴ８）。送信先は、情報共有システム２Ｂ，２Ｃのサーバ装置４Ｂ，４Ｃである。

［連携先の情報共有システム；図１２］
サーバ装置４Ｂ，４Ｃにおいては、メール受信部４２がメールを受信する（ＳＴ１１）。

連携判定部４６は、受信したメール内容をメール内容解析部４８に送り、連携メールか否かを判定する（ＳＴ１２）。この判定は、例えば、メールの送信元アドレス“taskacount1@succeedA.toshi-sol.co.jp”が連携情報記憶部４０２内のサーバアドレスであれば連携メールであり、ユーザ情報記憶部４０５内のユーザアドレスであれば連携メールではないとして実行できる。

連携判定部４６は、ステップＳＴ１２の判定の結果、連携メールのとき（他のサーバ装置４Ａから連携メールを受信したとき）、記事内容及び元記事情報（元記事の連携のユニークＩＤ）を連携記事作成部４９に送出する。

連携記事作成部４９は、記事内容及び元記事情報に基づいて、例えばメール本文に元記事情報を挿入した形式の連携記事を作成する（ＳＴ１３）。但し、連携記事の作成は、履歴元メール付のメール本文の作成と同様であるので、省略してもよい。

続いて、連携判定部４６は、この連携メールの送信日時“2009/08/01 10:10”、投稿者名“山田一郎”、タイトル“…”、本文“…”及び添付ファイル“…”と、当該連携メールに含まれる連携元のユニークＩＤ“A001001”とを関連付けて記事登録部４５に送出すると共に、この連携メールが元記事情報を含む場合には更に、当該連携元のユニークＩＤに当該元記事情報を関連付けて記事登録部４５に送出する。この例では連携メールは、元記事情報を含んでいない。

記事登録部４５は、記事を受け取り、記事情報記憶部４０２に登録する（ＳＴ１４）。詳しくは、記事登録部４５は、連携判定部４６から送出された送信日時“2009/08/01 10:10”、投稿者名“山田一郎”、“…”、本文“…”、添付ファイル“…”及び連携元のユニークＩＤ“A001001”を関連付けて記事情報記憶部４０３に書き込むと共に、連携判定部４６により元記事情報が送出された場合には更に、当該連携元のユニークＩＤに当該元記事情報を関連付けて記事情報記憶部４０３に書き込む。この例では、元記事情報は送出されていない。

各サーバ装置４Ｂ，４Ｃのメール送信部４３は、ユーザ情報から該当タスクのユーザアドレスを取得し、ユーザ端末３Ｂ，３Ｃに記事メールを送信する（ＳＴ１５）。詳しくは、メール送信部４３は、受信した連携メールに含まれて記事情報記憶部４０３に書き込まれた連携元のユニークＩＤ“A001001”から抽出した投稿先のタスクＩＤ“A001”に基づいて、当該投稿先のタスクＩＤ“A001”に対応する連携ＩＤ“001”に対応する連携先のタスクＩＤ“B001”，“C001”を連携先情報記憶部４０２から読出し、この連携先のタスクＩＤ“B001”，“C001”に基づいてユーザ情報記憶部４０５内のユーザアドレス“akiba-jiro@succeedB.toshi-sol.co.jp”，“ueda-saburo@succeedC.toshi-sol.co.jp”を読出し、このユーザアドレスに基づいて当該連携メールを記事メールとして送信（転送）する。例えばサーバ装置４Ｂの場合、メール送信部４３は、図１３に示す如き、記事メールをユーザ端末３Ｂに送信する。

以上のようなステップＳＴ１，ＳＴ３，ＳＴ８，ＳＴ１５のメール送信動作は、図１４に示すように表される。これに対し、例えば情報共有システム２Ｂのいずれかのユーザ端末３Ｂから電子メールが投稿された場合の動作は、図１５に示すように表される。図１５中、情報共有システム２Ｂが連携元であり、情報共有システム２Ａ，２Ｃが連携先である。すなわち、連携元及び連携先は、記事を投稿したユーザ端末３Ａ，３Ｂ又は３Ｃが属するか否かに対応しており、記事を投稿したユーザ端末３Ａ，３Ｂ，３Ｃに応じて交替している。また、図１５に対応するユーザ端末３Ｂからの投稿メールを図１６に示し、サーバ装置４Ｂからの記事メールを図１７に示し、サーバ装置４Ｂからの連携メールを図１８に示し、サーバ装置４Ｃからの記事メールを図１９に示す。以下同様にして、連携元と連携先とが交替しながら記事を連携することにより、各情報共有システム２Ａ，２Ｂ，２Ｃは、記事情報記憶部４０３内の情報を共有するように動作する。

また、ユーザ端末３Ａ，３Ｂ，３Ｃにおいては、ユーザの操作により、記事閲覧部３３が、サーバ装置４Ａ，４Ｂ，４Ｃ内の記事情報記憶部４０３の内容を閲覧表示することができる。

上述したように本実施形態によれば、情報共有システム２Ａのサーバ装置４Ａは、投稿された電子メールの記事を登録し、記事メールとして各ユーザ端末３Ａに送信した後、記事メールを連携させる連携メールを他の情報共有システム２Ｂ，２Ｃに送信する。他の情報共有システム２Ｂ，２Ｃのサーバ装置４Ｂ，４Ｃは、受信した連携メールの記事を登録し、記事メールとして各ユーザ端末３Ｂ，３Ｃに送信する。この動作は、記事を投稿したユーザ端末３Ａ，３Ｂ又は３Ｃに応じて連携元と連携先とが交替しながら実行される
従って、情報共有システムは、他の情報共有システムに対しても情報を共有することができる。

補足すると、本実施形態は、独立した複数の情報共有システム２Ａ，２Ｂ，２Ｃ間で記事情報の受け渡しを行い、連携している情報共有システム２Ａ，２Ｂ，２Ｃにおいて記事の議論構造の同期をとることで、利用しているユーザにあたかも１つの情報共有システム２Ａ，２Ｂ又は２Ｃ内で記事の共有をしているように提供する仕組みにより、独立した情報共有システム２Ａ，２Ｂ，２Ｃの間で記事を連携することができる。

また、図７に示したように、各々の情報共有システム２Ａ，２Ｂ，２Ｃのユーザ情報を他の情報共有システム２Ａ，２Ｂ，２Ｃが持つことなく、複数の情報共有システム２Ａ，２Ｂ，２Ｃ間での記事連携を実現するので、個人情報を保護することができる。詳しくは連携メールによって投稿者名（ユーザ名）が情報共有システム２Ａ，２Ｂ，２Ｃ間で共有されるものの、ユーザ名以外の個人情報を保護することができる。

（第２の実施形態）
次に、本発明の第２の実施形態について、前述した図２を参照しながら説明する。なお、以下の各実施形態も同様にして重複した部分の説明を省略する。

すなわち、第２の実施形態は、第１の実施形態の変形形態であり、連携メール遅延時の待機処理を実現するための元記事判定機能及び判定再実行機能を各サーバ装置４Ａ，４Ｂ，４Ｃに追加した構成となっている。

具体的には、各サーバ装置４Ａ，４Ｂ，４Ｃの連携判定部４６は、他のサーバ装置４Ａ，４Ｂ又は４Ｃから連携メールを受信したとき、この連携メールが元記事情報を含む場合には、当該元記事情報内の連携元のユニークＩＤに関連する記事情報記憶部４０３への書込が済んでいるか否かを判定する元記事書込判定機能と、この判定の結果、書込が済んでいるときには前述した記事登録部４５への送出を実行し、当該書込が済んでいないときには一定時間待機した後、元記事書込判定機能による判定を再実行する判定再実行機能と、を更に備えている。

次に、以上のように構成された情報共有システムの動作を図２０のフローチャートを用いて説明する。図２０のフローチャートは連携先の情報共有システムの動作を示している。

いま、第１の実施形態と同様に、ステップＳＴ１〜ＳＴ１２が実行されたとする。

サーバ装置４Ｂ，４Ｃの連携判定部４６は、ステップＳＴ１２の判定の結果、連携メールのとき（他のサーバ装置４Ａから連携メールを受信したとき）、連携メールに付加されている元記事情報内の連携元のユニークＩＤをもつ記事が、記事情報記憶部４０３に登録されているかを確認する（ＳＴ１３ａ−１）。詳しくは、連携判定部４６は、連携メールが元記事情報を含む場合には、当該元記事情報内の連携元のユニークＩＤに関連する記事情報記憶部４０３への書込が済んでいるか否かを判定する。

ステップＳＴ１３ａ−１の判定の結果、元記事情報内の連携元のユニークＩＤをもつ記事が登録されていない、つまり、遅延が発生し、本来先に到着しているはずの元記事が連携先の情報共有システム２Ｂ，２Ｃにはまだ届いていない場合は、連携判定部４６は、一定時間待つ（ＳＴ１３ａ−２）。

その後、連携判定部４６は、再度、ステップＳＴ１３ａ−１の処理を実行する。元記事情報内の連携元のユニークＩＤをもつ記事が記事情報記憶部４０３に登録されるまで、連携判定部４６は、ステップＳＴ１３ａ−１〜ＳＴ１３ａ−２の処理を繰り返す。

以下、前述同様に、サーバ装置４Ｂ，４ＣはステップＳＴ１４以降の処理を実行する。

上述したように本実施形態によれば、連係判定部４６が、他のサーバ装置４Ａから連携メールを受信したとき、この連携メールが元記事情報を含む場合には、当該元記事情報内の連携元のユニークＩＤに関連する記事情報記憶部４０３への書込が済んでいるか否かを判定し、書込が済んでいないときには一定時間待機した後、判定を再実行する構成により、第１の実施形態の効果に加え、受信した連携メールに対する元記事の連携メールが遅延して未到着の場合に、遅延して到着した元記事の連携メールを登録した後に、受信した連携メールを登録するので、連携メールの通信状況に依らず、連携メールの順序通りにユーザに記事を配信することができる。

補足すると、連携元の情報共有システム２Ａから連携先の情報共有システム２Ｂ，２Ｃに連携メールを送信する際に、記事内容とともに、連携元のスレッド情報（元記事情報）を付加することで、連携先の情報共有システム２Ｂ，２Ｃでは、連携元と連携先のスレッド状態を比較することができる。連携元と連携先でスレッド状態が異なる場合は、連携先のスレッドの状態が連携メール内の連携元のスレッド情報と同期するまで、連携メールの登録及びユーザへの配信を待つこととする。

これによって、サイト間の通信状況に依らず議論の構造通りにユーザに記事を配信することができる。

さらに補足すると、第１の実施形態では、通信の遅延が発生した場合などに、連携元の情報共有システム２Ａの記事メールの配信順が必ずしも保障されない。連携元の情報共有システム２Ａと連携先の情報共有システム２Ｂ，２Ｃとで記事の順番が狂ってしまうと、ユーザが記事を見る順番が狂い、議論の経緯が分かりづらく、ユーザが混乱する可能性がある。

しかしながら、第２の実施形態では、受信した連携メールの元記事情報に対応する連携メールが到着するまで、受信した連携メールの登録及び配信を待機するので、記事の配信順を保障することができる。

（変形例）
以上のような第２の実施形態は、機能拡張により、以下の第１又は第２の変形例に変形してもよい。第１又は第２の実施形態においては、機能拡張によって直前の元記事が到着していない場合でも、記事議論の構造を同期した状態で、連携先の該当タスクのユーザが他の連携先の情報共有システムのユーザに遅れることなく、記事を閲覧可能となる。これによって、サイト間の議論をよりスムーズに進めることができる。

［第１の変形例：連携記事情報仮作成機能］
第１の変形例は、第１の実施形態に比べ、直前の連携メールを受信していない場合でも、連携記事の情報を仮作成し、記事情報記憶部４０３に登録する構成により、議論の構造を同期した状態で、連携先の該当タスクのユーザが記事閲覧部３３から連携記事の議論の構造を知ることが可能となるものである。

具体的には、各サーバ装置４Ａ，４Ｂ，４Ｃのメール作成部４８は、第１の実施形態の機能において、元記事情報として、直前の履歴元メールの連携元のユニークＩＤからなる前回の元記事情報と、当該直前の履歴元メールに対する直前の履歴元メールの連携元のユニークＩＤからなる前々回の元記事情報とを付加して連携メールを作成する機能を更に備えている。

各サーバ装置４Ａ，４Ｂ，４Ｃの連携判定部４６は、第１の実施形態の機能において、他のサーバ装置４Ａ，４Ｂ又は４Ｃから連携メールを受信したとき、この連携メールが前回と前々回の元記事情報を含む場合には、当該前回の元記事情報内の連携元のユニークＩＤに関連する記事情報記憶部４０３への書込が済んでいるか否かを判定する前回記事書込判定機能と、この判定の結果、書込が済んでいるときには前述した記事登録部４５への送出を実行し、当該書込が済んでいないときには一定時間待機した後、前回記事書込判定機能による判定を再実行する判定再実行機能と、判定再実行機能により再実行した判定の結果、書込が済んでいるときには前述した記事登録部４５への送出を実行し、当該書込が済んでいないときには、前々回の元記事情報を記事登録部４５に送出すると共に、連携メールの送信日時、投稿者名、タイトル、本文、添付ファイル、連携元のユニークＩＤ及び前回の元記事情報を関連付けて記事登録部４５に送出する前々回元記事送出機能と、を更に備えている。

記事登録部４５は、第１の実施形態の機能に対し、連携判定部４６から送出された前回及び前々回の元記事情報を関連付けて、未到着の連携メールの連携元のユニークＩＤ及び元記事情報として記事情報記憶部４０３に書き込む機能と、連携判定部４６から送出された送信日時、投稿者名、タイトル、本文、添付ファイル、連携元のユニークＩＤ及び前回の元記事情報を関連付けて記事情報記憶部４０３に書き込む機能と、を更に備えている。

ユーザ端末３Ａ，３Ｂ，３Ｃの記事閲覧部３３は、サーバ装置４Ａ，４Ｂ，４Ｃ内の記事情報記憶部４０３の記憶内容を連携元のユニークＩＤ毎に一覧表示するための閲覧機能であって、当該記憶内容のうち、連携元のユニークＩＤに関連付けた送信日時、投稿者名及びタイトルがあれば当該送信日時、投稿者名及びタイトルを表示し、連携元のユニークＩＤに関連付けた送信日時が無ければ未到着情報を表示するように、当該一覧表示を実行する閲覧機能をもっている。

以上のように構成された第１の変形例は、第２の実施形態に対し、以下の動作が相違する。

ステップＳＴ６において、メール作成部４８が連携元のスレッド情報（１つ以上の元記事情報）を作成する際に、例えば図２１に示すように、直前の元記事情報（前回の連携元のユニークＩＤ：B001008）に加えて、この元記事情報の直前の元記事情報（前々回の連携元のユニークＩＤ：A001007）を付加する。

ステップＳＴ１３ａ−２において、一定時間待っても直前の元記事情報の連携のユニークＩＤ“B001008”をもつ記事が登録されない場合は、連携判定部４６は、未登録の記事に対しての直前の元記事（受信した連携メール“A001009”に対して２つ前の記事）の連携のユニークＩＤ（前々回の連携元のユニークＩＤ：A001007）から、前々回の元記事情報“A001007”を記事登録部４５に送出すると共に、連携メールの送信日時“2009/08/04 14:50”、投稿者名“山田一郎”、タイトル“…”、本文“…”、添付ファイル“…”、連携元のユニークＩＤ“A001009”及び前回の元記事情報“B001008”を関連付けて記事登録部４５に送出する。

記事登録部４５は、図２２の上半分に示すように、連携判定部４６から送出された前回及び前々回の元記事情報を関連付けて、未到着の連携メールの連携元のユニークＩＤ“B001008”及び元記事情報“A001007”として記事情報記憶部４０３に書き込む機能と、連携判定部４６から送出された送信日時“2009/08/04 14:50”、投稿者名“山田一郎”、タイトル“…”、本文“…”、添付ファイル“…”、連携元のユニークＩＤ“A001009”及び前回の元記事情報“B001008”を関連付けて記事情報記憶部４０３に書き込む
記事閲覧部３３は、図２２の下半分に示すように、サーバ装置４Ｃ内の記事情報記憶部４０３の記憶内容を連携元のユニークＩＤ毎に一覧表示するとき、当該記憶内容のうち、連携元のユニークＩＤに関連付けた送信日時、投稿者名及びタイトルがあれば当該送信日時、投稿者名及びタイトルを表示し、連携元のユニークＩＤに関連付けた送信日時が無ければ未到着情報を表示する。

すなわち、記事閲覧部３３は、未到着である元記事の箇所に「未到着」のラベルＬを付けて、未到着であること（仮作成の状態であること）が分かるように一覧表示を実行する。なお、「未到着」のラベルＬは、未到着情報の一例であり、未到着情報はラベルに限定されない。例えば、未到着情報は、未到着を表す記号、図又は色などであってもよい。このことは第２の変形例でも同様である。

第１の変形例によれば、図２１に示したように、連携元のスレッド情報として、前回と前々回の元記事情報を含む連携メールを送信する構成により、未到着の連携メールがあるとき、前回及び前々回の元記事情報を関連付けて、未到着の連携メールの連携元のユニークＩＤ及び元記事情報として記事情報記憶部４０３に書き込む。このため、第１の実施形態の効果に加え、該当記事が到着するまで、それ以降の記事が未登録となることを防止できる。また、第１の変形例によれば、図２２に示したように、該当記事が到着しない間も、連携している全ての情報共有システムの間で議論構造の同期をとった状態で、コミュニケーションが継続される。

［第２の変形例：連携記事本文仮作成機能］
第２の変形例は、第１の変形例に比べ、未到着の連携メールの本文を仮作成し、記事情報記憶部４０３に登録することで、議論の構造を同期した状態で、連携先の該当タスクのユーザが記事閲覧部３３から連携記事を閲覧することが可能となるものである。

具体的には、各サーバ装置４Ａ，４Ｂ，４Ｃの記事登録部４５は、第１の変形例の機能に加え、連携メールの本文の参照部分から、元記事の本文を推定し、記事本文を仮作成する仮作成機能をもっている。詳しくは、仮作成機能は、例えば図２３に示すように、記事情報記憶部４３に連携元のユニークＩＤ“B001008”及び元記事情報“A001007”が書き込まれており且つ当該連携元のユニークＩＤ“B001008”に関連付けた送信日時、投稿者、タイトル及び本文が書き込まれていない場合、当該連携元のユニークＩＤ“B001008”に一致する元記事情報“B001008”に関連付けた本文の履歴元メール参照部分“記号＞の右側部分及び上方部分”に基づいて、当該連携元のユニークＩＤ“B001008”に関連付けた投稿者“秋葉二郎”及び本文“了解しました。送付は明日でもＯＫですか？”を記事情報記憶部４０３に書き込む機能となっている。

これにより、記事閲覧部３３は、未到着ラベルＬが付された連携メールを開いた場合に、第１の変形例とは異なり、仮作成された本文“了解しました。送付は明日でもＯＫですか？”を表示することができる。

第２の変形例によれば、記事登録部４５が、未到着の連携メールに関し、当該連携元のユニークＩＤに一致する元記事情報に関連付けた本文の履歴元メール参照部分に基づいて、当該連携元のユニークＩＤに関連付けた投稿者及び本文を書き込むので、第１の変形例の効果に加え、未到着の連携メールの本文をも閲覧することができる。

補足すると、欠落している記事の後の記事から未到着である記事の本文を推定することにより、欠落している内容をユーザが類推可能となることで、該当記事が到着しない間も、連携している全ての情報共有システムの間で議論構造の同期をとった状態で、コミュニケーションがより円滑に継続される。

（第３の実施形態）
次に、本発明の第３の実施形態について、前述した図２を参照しながら説明する。

第３の実施形態は、第２の実施形態の変形形態であり、連携メール遅延時の待機機能に代えて、連携メール遅延時の再送信要求処理を実現するための機能を各サーバ装置４Ａ，４Ｂ，４Ｃに追加した構成である。

具体的には、各サーバ装置４Ａ，４Ｂ，４Ｃの連携判定部４６は、前述した判定再実行機能に代えて、元記事書込判定機能による判定の結果、書込が済んでいる場合には前述した記事登録部４５への送出を実行し、当該書込が済んでいないときには当該判定に用いた元記事情報内の連携元のユニークＩＤから投稿元のタスクＩＤを抽出し、この投稿元のタスクＩＤに対応するサーバアドレスを連携先情報記憶部４０２から読出し、このサーバアドレス及び当該連携元のユニークＩＤを含む再送信要求メール作成指令をメール作成部４８に送出する機能をもっている。

メール作成部４８は、連携判定部４６から受けた再送信要求メール作成指令に基づいて、当該再送信要求メール作成指令内の連携元のユニークＩＤを含み且つ当該再送信要求メール作成指令内のサーバアドレスを送信先アドレスとした再送信要求メールを作成する機能と、再送信要求メールをメール送信部４３に送出する機能とを備えている。

また、メール作成部４８は、他のサーバ装置４Ａ，４Ｂ又は４Ｃから受信した再送信要求メール内の連携元のユニークＩＤに基づいて記事情報記憶部４０３内の送信日時、投稿者名、タイトル、本文、添付ファイル、連携元のユニークＩＤ及び元記事情報を読出し、当該読み出した内容を含み且つ当該再送信要求メールの送信元アドレスを送信先アドレスとした連携メールを作成する機能とを更に備えている。

メール送信部４３は、メール作成部４８から受けた再送信要求メールを送信する機能と、メール作成部により作成された連携メールを再送信要求メールの送信元のサーバ装置４Ａ，４Ｂ，４Ｃに返信する機能とを更に備えている。

次に、以上のように構成された情報共有システムの動作を図２４及び図２５のフローチャートを用いて説明する。図２４は連携先の情報共有システムの動作を示し、図２５は連携元の情報共有システムの動作を示している。

いま、第１又は第２の実施形態と同様に、ステップＳＴ１〜ＳＴ１２が実行されたとする。

このとき、連携先の情報共有システム２Ｂ，２Ｃのサーバ装置４Ｂ，４Ｃにおいて、連携判定部４６は、例えば図２６に示すように、受信した連携メールが元記事情報“A001009”を含む場合には、当該元記事情報内の連携元のユニークＩＤ“A001009”に関連する記事情報記憶部４０３への書込が済んでいるか否かを判定する（ＳＴ１３ａ−１）。

連携判定部４６は、ステップＳＴ１３ａ−１の判定の結果、書込が済んでいないときには、当該判定に用いた元記事情報内の連携元のユニークＩＤ“A001009”から投稿先のタスクＩＤ“A001”を抽出し、この投稿先のタスクＩＤに対応するサーバアドレス“taskacount1@succeedA.toshi-sol.co.jp”を連携先情報記憶部４０２から読出し、このサーバアドレス“taskacount1@succeedA.toshi-sol.co.jp”及び当該連携元のユニークＩＤ“A001009”を含む再送信要求メール作成指令をメール作成部４８に送出する。

メール作成部４８は、この再送信要求メール作成指令に基づいて、当該再送信要求メール作成指令内の連携元のユニークＩＤ“A001009”を含み且つ当該再送信要求メール作成指令内のサーバアドレス“taskacount1@succeedA.toshi-sol.co.jp”を送信先アドレスとした再送信要求メールを作成する（ＳＴ１６）。

メール送信部４３は、この再送信要求メールを連携元の情報共有システム２Ａに送信する。

連携元の情報共有システム２Ａのサーバ装置４Ａのメール受信部４２は、他のサーバ装置４Ｂ又は４Ｃから再送信要求メールを受信した場合、一定時間待った後、付加されている連携元のユニークＩＤ“A001009”をメール作成部４８に送出する（ＳＴ２１〜ＳＴ２３）。

メール作成部４８は、送出された連携元のユニークＩＤ“A001009”に基づいて記事情報記憶部４０３内の送信日時“2009/08/04 14:50”、投稿者名“山田一郎”、タイトル“…”、本文“…”、添付ファイル“…”、連携元のユニークＩＤ“A001009”及び元記事情報“B001008”を読出し（ＳＴ２４）、当該読み出した内容を含み且つ当該再送信要求メールの送信元アドレスを送信先アドレスとした連携メールを作成する。

しかる後、メール送信部は、作成された連携メールを当該再送信要求メールの送信元のサーバ装置４Ｂ又は４Ｃに返信する（ＳＴ２５）。

連携先の情報共有システム４Ｂ，４Ｃは、受信した連携メールに付加されている連携元のユニークＩＤ“A001009”をもつ記事が記事情報記憶部４０３に登録済みかを確認する（ＳＴ１３ａ−１）。

このステップＳＴ１３ａ−１において、登録済みだった場合は、第１及び第２の実施形態と同様に、記事情報記憶部４０３への登録（ＳＴ１４）、ユーザへの記事メール配信（ＳＴ１５）を行う。登録されていない場合は、登録されるまでステップＳＴ１６〜ＳＴ１７，ＳＴ２１〜ＳＴ２５，ＳＴ１３ａ−１の処理を繰り返す。また、再送信要求をして連携メールが戻ってくるまでの間に、遅延していた連携メールが届いた場合は、後から送られてきた連携メールを破棄する。

上述したように本実施形態によれば、未到着の連携メールに対する再送信要求メールを送信する構成により、第１の実施形態の効果に加え、未到着の連携メールの到着がより迅速になることを期待することができる。

補足すると、連携元と連携先でスレッド状態が異なる場合は、連携先のスレッドの状態が連携メール内の連携元のスレッド情報と同期するまで、連携元と連携先の情報共有システム２Ａと２Ｂ又は２Ｃとの間で再送信要求メールと連携メールの送信を繰り返す。第２の実施形態の場合では、元記事の連携メールが届くまで待機するが、第３の実施形態では、再送信要求メールによって、議論の構造通りに、より迅速に元記事の登録及び連携記事のユーザへの送信を行うことができる。

（第４の実施形態）
次に、本発明の第４の実施形態について、前述した図２を参照しながら説明する。

第４の実施形態は、第２の実施形態の第１又は第２の変形例に対する変形形態であり、連携メール遅延時の処理として、遅延した連携メールの行を空けて、受信した連携メールを一覧表示し、遅延した連携メール受信時に各連携メールを接続して一覧表示するための機能を追加したものである。

具体的には、各サーバ装置４Ａ，４Ｂ，４Ｃは、図２７に示すように、未到着の連携メール毎に、連携元のユニークＩＤ及び元記事情報を関連付けて記憶する未到着記事情報記憶部４０６を更に備えている。なお、未到着記事情報記憶部４０６内の連携元のユニークＩＤ及び元記事情報は、未到着の連携メールの記事情報を登録する毎に、記事登録部４５により消去される。

メール作成部４８は、前述した元記事情報として、直前の履歴元メールの連携元のユニークＩＤからなる前回の元記事情報と、当該直前の履歴元メールに対する直前の履歴元メールの連携元のユニークＩＤからなる前々回の元記事情報とを付加して連携メールを作成する機能をもっている。

連携判定部４６は、他のサーバ装置４Ａ，４Ｂ又は４Ｃから連携メールを受信したとき、この連携メールが前回と前々回の元記事情報を含む場合には、当該前回の元記事情報内の連携元のユニークＩＤに関連する記事情報記憶部４０３への書込が済んでいるか否かを判定する機能と、この判定の結果、書込が済んでいるときには前述した記事登録部４５への送出を実行し、書込が済んでいないときには、前回及び前々回の元記事情報を関連付けて、未到着の連携メールの連携元のユニークＩＤ及び元記事情報として未到着記事情報記憶部４０６に書き込むと共に、前々回の元記事情報を記事登録部４５に送出し、連携メールの送信日時、投稿者名、タイトル、本文、添付ファイル、連携元のユニークＩＤ及び前回の元記事情報を関連付けて記事登録部４５に送出する機能と、をもっている。

記事登録部４５は、連携判定部４６により送出された前回及び前々回の元記事情報を関連付けて、未到着の連携メールの連携元のユニークＩＤ及び元記事情報として記事情報記憶部４０３に書き込む機能と、連携判定部４６により送出された送信日時、投稿者名、タイトル、本文、添付ファイル、連携元のユニークＩＤ及び前回の元記事情報を関連付けて記事情報記憶部４０３に書き込む機能と、をもっている。

一方、各ユーザ端末３Ａ，３Ｂ，３Ｃの記事閲覧部３３は、サーバ装置４Ａ，４Ｂ，４Ｃ内の記事情報記憶部４０３の記憶内容を連携元のユニークＩＤ毎に一覧表示するための閲覧機能であって、当該記憶内容のうち、連携元のユニークＩＤに関連付けた送信日時、投稿者名及びタイトルがあれば当該送信日時、投稿者名及びタイトルを表示し、連携元のユニークＩＤに関連付けた送信日時が無ければ空白情報を表示するように、一覧表示を実行する閲覧機能と、閲覧機能による一覧表示の実行中、記事情報記憶部４０３内の関連する連携元のユニークＩＤ及び元記事情報に基づいて、送信日時、投稿者名及びタイトルを表示した表示行の間を接続する線情報を表示する機能とをもっている。

次に、以上のように構成された情報共有システムの動作を図２８のフローチャートを用いて説明する。図２８は連携先の情報共有システムの動作を示している。

いま、第２の実施形態の第１又は第２の変形例と同様に、ステップＳＴ１〜ＳＴ１２が実行されたとする。すなわち、ステップＳＴ６では、メール作成部４８が連携元のスレッド情報（１つ以上の元記事情報）を作成する際に、例えば図２１に示したように、直前の元記事情報（前回の連携元のユニークＩＤ：B001008）に加えて、この元記事情報の直前の元記事情報（前々回の連携元のユニークＩＤ：A001007）を付加しているものとする。

さてステップＳＴ１２が実行され、連携先の情報共有システム２Ｂ，２Ｃのサーバ装置４Ｂ，４Ｃの連携判定部４６は、ステップＳＴ１２の判定の結果、連携メールのとき（他のサーバ装置４Ａから連携メールを受信したとき）、図２１に示した如き、この連携メールが前回と前々回の元記事情報（B001008、A001007）を含む場合には、当該前回の元記事情報内の連携元のユニークＩＤ“B001008”に関連する記事情報記憶部４０３への書込が済んでいるか否かを判定する（ＳＴ１３ｂ−１）。

ステップＳＴ１３ｂ−１の判定の結果、書込（登録）が済んでいないときには、図２９に示すように、連携判定部４６は、前回及び前々回の元記事情報（B001008、A001007）を関連付けて、未到着の連携メールの連携元のユニークＩＤ“B001008”及び元記事情報“A001007”として未到着記事情報記憶部４０６に書き込むと共に、前々回の元記事情報“A001007”を記事登録部４５に送出する。記事登録部４５は、送出された前回及び前々回の元記事情報を関連付けて、未到着の連携メールの連携元のユニークＩＤ及び元記事情報として記事情報記憶部４０３に書き込む。また、連携判定部４６は、連携メールの送信日時“2009/0804 14:50”、投稿者名“山田一郎”、タイトル“…”、本文“…”、添付ファイル“…”、連携元のユニークＩＤ“A001009”及び前回の元記事情報“B001008”を関連付けて連携記事作成部４５に送出する。

連携記事作成部４９は、送出された連携メールの送信日時“2009/0804 14:50”、投稿者名“山田一郎”、タイトル“…”、本文“…”、添付ファイル“…”、連携元のユニークＩＤ“A001009”及び前回の元記事情報“B001008”に基づいて、例えば記事情報記憶部４０３を参照して連携記事が作成済みか否かを判定し（ＳＴ１３ｂ−２）、作成済みでなければ、例えばメール本文に元記事情報を挿入した形式の連携記事（連携メールの本文）を作成し（ＳＴ１３ｂ−３）、当該連携記事としての本文を連携判定部４６に戻す。但し、連携記事の作成に関するステップＳＴ１３ｂ−２，ＳＴ１３ｂ−３は、履歴元メール付のメール本文の作成と同様であるので、省略してもよい。

このとき、元記事が記事情報記憶部４０３に登録されていないので、作成した記事を本来の議論経緯に結びつけることができない。このため、ステップＳＴ１３ｂ−３で作成した記事は、他の議論とは独立した状態となる。

いずれにしても連携判定部４６は、連携メールの送信日時“2009/0804 14:50”、投稿者名“山田一郎”、タイトル“…”、本文“…”、添付ファイル“…”、連携元のユニークＩＤ“A001009”及び前回の元記事情報“B001008”を関連付けて記事登録部４５に送出する。

記事登録部４５は、送信日時“2009/0804 14:50”、投稿者名“山田一郎”、タイトル“…”、本文“…”、添付ファイル“…”、連携元のユニークＩＤ“A001009”及び前回の元記事情報“B001008”を関連付けて記事情報記憶部４０３に書き込む（ＳＴ１４）。

メール送信部４３は、前述同様に、ユーザ情報から該当タスクのユーザアドレスを取得し、ユーザ端末３Ｂ，３Ｃに記事メールを送信する（ＳＴ１５）。

また、連携判定部４６は、またステップＳＴ１３ｂ−２の判定の結果、連携記事が作成済みのときには一定時間待つことにより（ＳＴ１３ｂ−４）、一定時間毎に未登録記事情報記憶部４０６から連携元のユニークＩＤを読出し、当該読み出した連携元のユニークＩＤ“B001008”に関連する記事情報記憶部４０３への書込が済んでいるか否かを判定する（ＳＴ１３ｂ−１）。

ステップＳＴ１３ｂ−１の判定の結果、書込（登録）が済んでいるとき、連携判定部４６は、連携メールの送信日時“2009/0804 14:50”、投稿者名“山田一郎”、タイトル“…”、本文“…”、添付ファイル“…”、連携元のユニークＩＤ“A001009”及び前回の元記事情報“B001008”を関連付けて記事登録部４５に送出する。

以下、前述した通り、ステップＳＴ１４及びＳＴ１５が実行される。

一方、例えば、ユーザ端末３Ｃの記事閲覧部３３は、ユーザの操作により、図２９に元記事未登録の場合（ＳＴ１３ｂ−１；ｎｏ）を示すように、サーバ装置４Ｂ，４Ｃ内の記事情報記憶部４０３の記憶内容のうち、連携元のユニークＩＤ（例、A001007、A001009）に関連付けた送信日時、投稿者名及びタイトルがあれば当該送信日時、投稿者名及びタイトルを表示し、連携元のユニークＩＤ（例、B001008）に関連付けた送信日時が無ければ空白情報を表示するように、一覧表示を実行する。

また、記事閲覧部３３は、ユーザの操作により、図３０に元記事登録済みの場合（ＳＴ１３ｂ−１；ｙｅｓ）を示すように、閲覧機能による一覧表示の実行中、記事情報記憶部４０３内の関連する連携元のユニークＩＤ及び元記事情報に基づいて、送信日時、投稿者名及びタイトルを表示した表示行の間を接続する線情報Ｌｉを表示する。

上述したように本実施形態によれば、連携メール遅延時の処理として、遅延した連携メールの行を空けて、受信した連携メールを一覧表示し、遅延した連携メール受信時に各連携メールを接続して一覧表示するので、第１の実施形態の効果に加え、遅延した連携メールがあっても、記事を順序通りに閲覧することができる。

補足すると、連携元と連携先でスレッド状態が異なる場合は、連携先のスレッドの状態が連携メール内の連携元のスレッド情報と同期するまで、議論経緯を独立した状態で進め、未登録だった元記事が記事情報に登録された場合に、この元記事を接点として、２つの議論経緯を結びつけることで、連携元と連携先のスレッドの状態が異なる場合でも、ユーザへの記事メールの送信を迅速に行うことができ、ユーザの議論を妨げない。

なお、第４の実施形態は、以下のような変形例としてもよい。

すなわち、この変形例は、各サーバ装置４Ａ，４Ｂ，４Ｃは、図３１に示すように、記事情報記憶部４０３内の「連携元のユニークＩＤ」及び「本文」と、記事情報記憶部４０３内の連携元のユニークＩＤ及び元記事情報に基づいて複数の本文の間を接続する「線情報Ｌｉ」とを有する連携記事情報を記憶する連携記事記憶部４０７を更に備えている。

また、この変形例は、図３２に示すように、ステップＳＴ１３ｂ−２及びＳＴ１３ｂ−３に代えて、ステップＳＴ１３ｂ−２’及びＳＴ１３ｂ−３’を実行し、且つステップＳＴ１３ｂ−５を付加した動作を実行する。

このような変形例では、ステップＳＴ１３ｂ−２’〜ＳＴ１３−３’において、連携記事作成部４９は、送出された連携メールの送信日時“2009/0804 14:50”、投稿者名“山田一郎”、タイトル“…”、本文“…”、添付ファイル“…”、連携元のユニークＩＤ“A001009”及び前回の元記事情報“B001008”に基づいて、連携記事記憶部４０７を参照して連携記事情報（連携元のユニークＩＤ及び本文）が作成済み（書込済み）か否かを判定し（ＳＴ１３ｂ−２’）、作成済みでなければ、図３３の上半分に示すように、連携メールの連携元のユニークＩＤ“A001009”及び本文“ＯＫです。”からなる連携記事情報を作成して（ＳＴ１３ｂ−３）連携記事記憶部４０７に書き込む。

このとき、元記事が記事情報記憶部４０３に登録されていないので、作成した連携記事情報を本来の議論経緯に結びつけることができない。このため、ステップＳＴ１３ｂ−３’で書き込んだ連携記事情報は、他の議論とは独立した状態となる。

また、ステップＳＴ１３ｂ−５（元記事が記事情報に登録されている場合）において、連携判定部４６は、新たに登録された元記事の連携元のユニークＩＤ“B001008”とステップＳＴ１３ｂ−３’で書き込んだ連携記事情報のユニークＩＤ“A001009”、及び元記事が有する元記事情報“A001007”を連携記事作成部４９に送る。連携記事作成部４９は、図３３の下半分に示すように、新たに登録した元記事（B001008）と当該元記事が有する元記事情報“A001007”が示す記事(新たに登録した元記事にとっての親の記事)とを接続する第１の接続線情報Ｌ１と、新たに登録した元記事（B001008）とステップＳＴ１３ｂ−３で作成した連携記事（新たに登録した元記事にとっての子の記事）とを接続する第２の接続線情報Ｌ２とを連携情報記憶部４０７に書き込む（ＳＴ１３ｂ−５）。

以下、前述した通り、ステップＳＴ１４及びＳＴ１５が実行される。また、連携記事記憶部４０７内の連携記事情報は、例えば、ユーザ端末３Ｃの記事閲覧部３３から閲覧表示することができる。

以上のような変形例としても、第４の実施形態と同様の効果を得ることができる。

なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。

また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。

また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。

さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。

また、記憶媒体は１つに限らず、複数の媒体から上記実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。

尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。

また、本発明におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。

なお、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。

１…記事連携システム、２Ａ，２Ｂ，２Ｃ…情報共有システム、３Ａ，３Ｂ，３Ｃ…ユーザ端末、３１…サイト連携設定部、３１…サイト連携設定部、３２…記事投稿部、３３…記事閲覧部、３４，４３…メール送信部、３５，４２…メール受信部、３６…メモリ、４Ａ，４Ｂ，４Ｃ…サーバ装置、４１…アクセス制御部、４４…サイト連携情報登録部、４５…記事登録部、４６…連携判定部、４７…メール内容解析部、４８…メール作成部、４９…連携記事作成部、４０１…サイト連携情報記憶部、４０２…連携先情報、４０３…記事情報記憶部、４０４…タスク情報記憶部、４０５…ユーザ情報記憶部、４０６…未到着記事情報記憶部、４０７…連携記事記憶部。

Claims (6)

1. 互いに電子メールを送受信可能なサーバ装置及び各ユーザ端末を備えた複数の情報共有システムにおける各々の情報共有システムであって、
   前記サーバ装置は、
   電子メール毎に、送信日時、投稿者名、タイトル及び本文を含むメール内容情報と、連携元のユニークＩＤ及び元記事情報とを関連付けて記憶するための記事情報記憶手段と、
   いずれかのユーザ端末から電子メールを受信したとき、この電子メールのメール内容情報と、当該電子メールを示す前記連携元のユニークＩＤと、当該電子メールに含まれる履歴元メールの連携元のユニークＩＤからなる元記事情報とを関連付けて前記記事情報記憶手段に書き込む手段と、
   前記受信した電子メールを記事メールとして前記各ユーザ端末に送信する第１の記事メール送信手段と、
   前記受信した電子メールに前記記事情報記憶手段内の連携元のユニークＩＤ及び元記事情報を付加して連携メールを作成する連携メール作成手段と、
   前記作成された連携メールを、他の情報共有システムのサーバ装置に送信する連携メール送信手段と、
   他のサーバ装置から連携メールを受信したとき、この連携メールのメール内容情報と、当該連携メールに含まれる連携元のユニークＩＤ及び元記事情報とを関連付けて送出する連携記事送出手段と、
   前記連携記事送出手段により送出されたメール内容情報、連携元のユニークＩＤ及び元記事情報を関連付けて前記記事情報記憶手段に書き込む連携記事書込手段と、
   前記受信した連携メールを記事メールとして前記各ユーザ端末に送信する第２の記事メール送信手段と、
   を備えたことを特徴とする情報共有システム。
2. 請求項１に記載の情報共有システムにおいて、
   前記連携記事送出手段は、
   前記他のサーバ装置から連携メールを受信したとき、この連携メールが元記事情報を含む場合には、当該元記事情報内の連携元のユニークＩＤに関連する前記記事情報記憶手段への書込が済んでいるか否かを判定する元記事書込判定手段と、
   この判定の結果、書込が済んでいるときには前記送出を実行し、当該書込が済んでいないときには一定時間待機した後、前記元記事書込判定手段による判定を再実行する判定再実行手段と、
   を備えたことを特徴とする情報共有システム。
3. 請求項１に記載の情報共有システムにおいて、
   前記連携メール作成手段は、
   前記元記事情報として、直前の履歴元メールの連携元のユニークＩＤからなる前回の元記事情報と、当該直前の履歴元メールに対する直前の履歴元メールの連携元のユニークＩＤからなる前々回の元記事情報とを付加して連携メールを作成し、
   前記連携記事送出手段は、
   前記他のサーバ装置から連携メールを受信したとき、この連携メールが前回と前々回の元記事情報を含む場合には、当該前回の元記事情報内の連携元のユニークＩＤに関連する前記記事情報記憶手段への書込が済んでいるか否かを判定する前回記事書込判定手段と、
   この判定の結果、書込が済んでいるときには前記送出を実行し、当該書込が済んでいないときには一定時間待機した後、前記前回記事書込判定手段による判定を再実行する判定再実行手段と、
   前記判定再実行手段により再実行した判定の結果、書込が済んでいるときには前記送出を実行し、当該書込が済んでいないときには、前々回の元記事情報を前記連携記事書込手段に送出すると共に、前記連携メールのメール内容情報、連携元のユニークＩＤ及び前回の元記事情報を関連付けて前記連携記事書込手段に送出する前々回元記事送出手段と、
   を備え、
   前記連携記事書込手段は、
   前記前々回元記事送出手段から送出された前回及び前々回の元記事情報を関連付けて、未到着の連携メールの連携元のユニークＩＤ及び元記事情報として前記記事情報記憶手段に書き込む手段と、
   前記前々回元記事送出手段から送出されたメール内容情報、連携元のユニークＩＤ及び前回の元記事情報を関連付けて前記記事情報記憶手段に書き込む手段と、
   を備え、
   前記ユーザ端末は、
   前記サーバ装置内の記事情報記憶手段の記憶内容を連携元のユニークＩＤ毎に一覧表示するための閲覧手段であって、当該記憶内容のうち、連携元のユニークＩＤに関連付けた送信日時、投稿者名及びタイトルがあれば当該送信日時、投稿者名及びタイトルを表示し、連携元のユニークＩＤに関連付けた送信日時が無ければ未到着情報を表示するように、前記一覧表示を実行する前記閲覧手段と、
   を備えたことを特徴とする情報共有システム。
4. 請求項３に記載の情報共有システムにおいて、
   前記連携記事書込手段は、
   前記記事情報記憶手段に連携元のユニークＩＤ及び元記事情報が書き込まれており且つ当該連携元のユニークＩＤに関連付けた送信日時、投稿者、タイトル及び本文が書き込まれていない場合、当該連携元のユニークＩＤに一致する元記事情報に関連付けた本文の履歴元メール参照部分に基づいて、当該連携元のユニークＩＤに関連付けた投稿者及び本文を書き込む手段、
   を更に備えたことを特徴とする情報共有システム。
5. 請求項２に記載の情報共有システムにおいて、
   前記連携記事送出手段は、
   前記判定再実行手段に代えて、前記元記事書込判定手段による判定の結果、書込が済んでいる場合には前記送出を実行し、当該書込が済んでいないときには当該判定に用いた元記事情報内の連携元のユニークＩＤから投稿先のタスクＩＤを抽出し、この投稿先のタスクＩＤに対応するサーバアドレスを前記連携先情報記憶手段から読出し、このサーバアドレス及び当該連携元のユニークＩＤを含む再送信要求メール作成指令を送出する手段、
   を備え、
   前記再送信要求メール作成指令に基づいて、当該再送信要求メール作成指令内の連携元のユニークＩＤを含み且つ当該再送信要求メール作成指令内のサーバアドレスを送信先アドレスとした再送信要求メールを作成する手段と、
   前記再送信要求メールを送信する手段と、
   他のサーバ装置から再送信要求メールを受信したとき、この再送信要求メール内の連携元のユニークＩＤに基づいて前記記事情報記憶手段内のメール内容情報、連携元のユニークＩＤ及び元記事情報を読出し、当該読み出した内容を含み且つ再送信要求メールの送信元アドレスを送信先アドレスとした連携メールを作成する手段と、
   この作成された連携メールを前記再送信要求メールの送信元のサーバ装置に返信する手段と、
   を更に備えたことを特徴とする情報共有システム。
6. 請求項１に記載の情報共有システムにおいて、
   未到着の連携メール毎に、連携元のユニークＩＤ及び元記事情報を関連付けて記憶するための未到着記事記憶手段を更に備え、
   前記第２の連携メール作成手段は、
   前記元記事情報として、直前の履歴元メールの連携元のユニークＩＤからなる前回の元記事情報と、当該直前の履歴元メールに対する直前の履歴元メールの連携元のユニークＩＤからなる前々回の元記事情報とを付加して連携メールを作成し、
   前記連携記事送出手段は、
   前記他のサーバ装置から連携メールを受信したとき、この連携メールが前回と前々回の元記事情報を含む場合には、当該前回の元記事情報内の連携元のユニークＩＤに関連する前記記事情報記憶手段への書込が済んでいるか否かを判定する前回記事書込判定手段と、
   この判定の結果、書込が済んでいるときには前記送出を実行し、書込が済んでいないときには、前回及び前々回の元記事情報を関連付けて、未到着の連携メールの連携元のユニークＩＤ及び元記事情報として前記未到着記事記憶手段に書き込むと共に、前々回の元記事情報を前記連携記事書込手段に送出し、前記連携メールのメール内容情報、連携元のユニークＩＤ及び前回の元記事情報を関連付けて前記連携記事書込手段に送出する前々回元記事送出手段と、
   を備え、
   前記連携記事書込手段は、
   前記前々回元記事送出手段から送出された前回及び前々回の元記事情報を関連付けて、未到着の連携メールの連携元のユニークＩＤ及び元記事情報として前記記事情報記憶手段に書き込む手段と、
   前記前々回元記事送出手段から送出されたメール内容情報、連携元のユニークＩＤ及び前回の元記事情報を関連付けて前記記事情報記憶手段に書き込む手段と、
   を備え、
   前記ユーザ端末は、
   前記サーバ装置内の記事情報記憶手段の記憶内容を連携元のユニークＩＤ毎に一覧表示するための閲覧手段であって、当該記憶内容のうち、連携元のユニークＩＤに関連付けた送信日時、投稿者名及びタイトルがあれば当該送信日時、投稿者名及びタイトルを表示し、連携元のユニークＩＤに関連付けた送信日時が無ければ空白情報を表示するように、前記一覧表示を実行する前記閲覧手段と、
   前記閲覧手段による一覧表示の実行中、前記記事情報記憶手段内の関連する連携元のユニークＩＤ及び元記事情報に基づいて、前記送信日時、投稿者名及びタイトルを表示した表示行の間を接続する線情報を表示する線情報表示手段と、
   を備えたことを特徴とする情報共有システム。

Images