(57)【要約】【課題】  コンテンツの更新等をコンテンツに関係付けられたユーザにメールで通知する際に、他の通知対象者のメールアドレスは隠蔽するが、そのメールに返信することで他の通知対象者にメールを送信することを可能とする。【解決手段】コンテンツ管理サーバ１０２は、コンテンツ管理モジュール３０３により、複数のユーザ情報と複数のコンテンツ情報を管理して、コンテンツの更新を監視する。また更新通知モジュール３０４により、コンテンツ管理モジュール３０３からコンテンツ更新が通知された場合に、ユーザ情報およびコンテンツ情報に基づいて特定される更新通知対象ユーザに対して、更新通知メールを送信する。またメール転送モジュール３０５により、更新通知メールに対して更新通知対象ユーザのうちの１ユーザからの返信メールを受信した場合に、該返信メールを更新通知対象ユーザに対して転送する。更新通知対象ユーザのアドレスは、各メールのＢＣＣアドレスに設定される。【選択図】  図３
2007279921.tif 000002
【特許請求の範囲】
【請求項１】
システム内のコンテンツ情報を管理するコンテンツ管理サーバと、複数のクライアント装置がネットワークを介して接続され、前記コンテンツ管理サーバと前記クライアント装置のユーザとの間におけるメール通信を可能とするコンテンツ管理システムであって、
前記コンテンツ管理サーバは、
複数のユーザ情報と複数のコンテンツ情報を管理して、コンテンツの更新を監視するコンテンツ管理手段と、
前記コンテンツ管理手段によってコンテンツが更新された旨が通知された場合に、前記ユーザ情報および前記コンテンツ情報に基づいて特定される、前記クライアント装置における更新通知対象ユーザに対して、更新通知メールを送信する更新通知手段と、
前記更新通知メールに対して前記更新通知対象ユーザのうちの１ユーザからの返信メールを受信した場合に、該返信メールを、前記ユーザ情報および前記コンテンツ情報に基づいて特定される更新通知対象ユーザに対して転送するメール転送手段と、
を有することを特徴とするコンテンツ管理システム。
【請求項２】
前記更新通知手段は、前記更新通知メールに対し、前記更新通知対象ユーザの電子メールアドレスをＢＣＣアドレスに設定し、システムで唯一の受信用アドレスをＴＯアドレスに設定して、送信することを特徴とする請求項１記載のコンテンツ管理システム。
【請求項３】
前記メール転送手段は、前記返信メールに対し、前記更新通知対象ユーザの電子メールアドレスをＢＣＣアドレスに設定し、前記受信用アドレスをＴＯアドレスに設定して、転送することを特徴とする請求項２記載のコンテンツ管理システム。
【請求項４】
前記メール転送手段は、前記返信メールのＦＲＯＭアドレスに設定された電子メールアドレスが前記ユーザ情報内に含まれる場合に、該返信メールを転送することを特徴とする請求項１乃至３のいずれかに記載のコンテンツ管理システム。
【請求項５】
前記更新通知手段は、前記更新通知メールに対し、前記受信用アドレスをＦＲＯＭアドレスおよびＲＥＰＬＹ−ＴＯアドレスに設定して送信し、
前記メール転送手段は、前記受信用アドレスで受信された返信メールに対し、前記受信用アドレスをＦＲＯＭアドレスおよびＲＥＰＬＹ−ＴＯアドレスに設定して転送する
ことを特徴とする請求項２乃至４のいずれかに記載のコンテンツ管理システム。
【請求項６】
前記コンテンツ情報は、コンテンツを識別するコンテンツ識別情報を有し、
前記更新通知手段は、前記更新通知メールに対し、前記コンテンツ識別情報がＳＵＢＪＥＣＴに含まれるように設定して、送信することを特徴とする請求項５記載のコンテンツ管理システム。
【請求項７】
前記コンテンツ識別情報は、キーワード情報であることを特徴とする請求項６記載のコンテンツ管理システム。
【請求項８】
前記コンテンツ情報は、コンテンツ更新時に更新通知メールの宛先となる更新通知アドレス情報を有し、
前記更新通知手段は、前記更新通知メールに対し、前記更新通知アドレスをＦＲＯＭアドレスおよびＲＥＰＬＹ−ＴＯアドレスに設定して送信し、
前記メール転送手段は、前記更新通知アドレスで受信された前記返信メールに対し、前記更新通知アドレスをＦＲＯＭアドレスおよびＲＥＰＬＹ−ＴＯアドレスに設定して転送する
ことを特徴とする請求項２乃至４のいずれかに記載のコンテンツ管理システム。
【請求項９】
前記コンテンツ情報は、コンテンツに対するユーザの権限情報を有し、
前記更新通知手段は、更新されたコンテンツに対する前記ユーザの権限情報に基づいて前記ユーザ情報から前記更新通知対象ユーザの電子メールアドレスを取得し、
前記メール転送手段は、更新されたコンテンツに対する前記ユーザの権限情報に基づいて前記ユーザ情報から前記更新通知対象ユーザの電子メールアドレスを取得する
ことを特徴とする請求項１乃至８のいずれかに記載のコンテンツ管理システム。
【請求項１０】
システム内のコンテンツ情報を管理するコンテンツ管理サーバと、複数のクライアント装置がネットワークを介して接続されたコンテンツ管理システムにおいて、前記コンテンツ管理サーバと前記クライアント装置のユーザとの間におけるメール通信を制御する制御方法であって、
前記コンテンツ管理サーバにおいて、
複数のユーザ情報と複数のコンテンツ情報を管理して、コンテンツの更新を監視するコンテンツ監視ステップと、
前記コンテンツ監視ステップによってコンテンツが更新された旨が通知された場合に、前記ユーザ情報および前記コンテンツ情報に基づいて特定される、前記クライアント装置における更新通知対象ユーザに対して、更新通知メールを送信する更新通知ステップと、
前記更新通知メールに対して前記更新通知対象ユーザのうちの１ユーザからの返信メールを受信する返信メール受信ステップと、
前記返信メールを、前記ユーザ情報および前記コンテンツ情報に基づいて特定される更新通知対象ユーザに対して転送するメール転送ステップと、
を有することを特徴とするコンテンツ管理システムの制御方法。
【請求項１１】
前記更新通知ステップにおいては、前記更新通知メールに対し、前記更新通知対象ユーザの電子メールアドレスをＢＣＣアドレスに設定し、システムで唯一の受信用アドレスをＴＯアドレスに設定して、送信することを特徴とする請求項１０記載のコンテンツ管理システムの制御方法。
【請求項１２】
前記メール転送ステップにおいては、前記返信メールに対し、前記更新通知対象ユーザの電子メールアドレスをＢＣＣアドレスに設定し、前記受信用アドレスをＴＯアドレスに設定して、転送することを特徴とする請求項１１記載のコンテンツ管理システムの制御方法。
【請求項１３】
システム内のコンテンツ情報を管理するコンテンツ管理サーバと、複数のクライアント装置がネットワークを介して接続されたコンテンツ管理システムにおいて、前記コンテンツ管理サーバと前記クライアント装置のユーザとの間におけるメール通信を制御する制御プログラムであって、
前記コンテンツ管理サーバにおいて、
複数のユーザ情報と複数のコンテンツ情報を管理して、コンテンツの更新を監視するコンテンツ管理モジュールと、
前記コンテンツ管理モジュールによってコンテンツが更新された旨が通知された場合に、前記ユーザ情報および前記コンテンツ情報に基づいて特定される、前記クライアント装置における更新通知対象ユーザに対して、更新通知メールを送信する更新通知モジュールと、
前記更新通知メールに対して前記更新通知対象ユーザのうちの１ユーザからの返信メールを受信した場合に、該返信メールを、前記ユーザ情報および前記コンテンツ情報に基づいて特定される更新通知対象ユーザに対して転送するメール転送モジュールと、
を有することを特徴とするコンテンツ管理システムの制御プログラム。
【請求項１４】
前記更新通知モジュールにおいては、前記更新通知メールに対し、前記更新通知対象ユーザの電子メールアドレスをＢＣＣアドレスに設定し、システムで唯一の受信用アドレスをＴＯアドレスに設定して、送信することを特徴とする請求項１３記載のコンテンツ管理システムの制御プログラム。
【請求項１５】
前記メール転送モジュールにおいては、前記返信メールに対し、前記更新通知対象ユーザの電子メールアドレスをＢＣＣアドレスに設定し、前記受信用アドレスをＴＯアドレスに設定して、転送することを特徴とする請求項１４記載のコンテンツ管理システムの制御プログラム。
【請求項１６】
請求項１３乃至１５のいずれかに記載の制御プログラムが記録されたことを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ管理システムおよびその制御方法に関し、特に、コンテンツの更新情報をユーザに通知するコンテンツ管理システムおよびその制御方法に関する。
【背景技術】
【０００２】
従来のコンテンツ管理システムにおいては、コンテンツの登録や更新などのコンテンツに対する操作が行なわれた時にコンテンツ管理システムがユーザに更新の発生を通知する、更新通知機能を備えていた。すなわち、コンテンツ管理システムが通知の送付対象となるユーザの宛先情報を保持し、通知対象であるコンテンツに対して通知対象である操作が行なわれると、コンテンツ管理システムからユーザに対して通知を行なっていた。（例えば、特許文献１参照）。
【０００３】
また、電子メール技術の普及に伴い、コンテンツ管理システムにおいて、更新通知機能における通知手段として電子メールを用いることも行われていた。すなわち、通知対象とするユーザ群をコンテンツに対するアクセス権設定などによって判定し、そのコンテンツに対してある一定の権限を有しているユーザ群に対して通知を行っていた。（例えば、特許文献２参照）。
【０００４】
そのような電子メールを用いた通知においては、発信者や受信者のプライバシー保護を目的として、メールアドレスが他者に公開されない方法も重要視されている。上記従来の更新通知機能では、コンテンツの操作を行なったユーザの電子メールアドレスを電子メールの“ＦＲＯＭ”や“ＲＥＰＬＹ−ＴＯ”アドレスに指定し、通知対象者の電子メールアドレスを“ＴＯ”アドレスや“ＣＣ”アドレスに指定して送信していた。すると、“ＴＯ”アドレスや“ＣＣ”アドレスに指定された個々の受信者に対し、送信者及び他の全受信者のメールアドレスが露呈されてしまうこととなり、プライバシー保護上問題があった。
【０００５】
よって、送信者、受信者のアドレスを隠蔽するために、以下のような方法が一般的に用いられていた。すなわち、“ＦＲＯＭ”や“ＲＥＰＬＹ−ＴＯ”アドレスにはコンテンツの操作を行なったユーザの電子メールアドレスではなく、ダミーのメールアドレスを指定し、通知対象者の電子メールアドレスは電子メールの“ＢＣＣ”アドレスに指定する方法である。このようなアドレス指定を行うことによって、通知対象となる個々の受信者に対し、他の利用者の電子メールアドレスが公開されないようにすることができる。
【０００６】
また、送信者の電子メールアドレスを他者に公開せず、且つ受信者が送信者にメールを返信することを可能にするために、以下のような電子メールサーバ技術が用いられていた。すなわち、メールの送信元アドレスが秘匿指定されている場合には、これを匿名アドレスに変換して送信先に配信し、メールの送信先アドレスに該変換された匿名アドレスが指定されている場合には、変換前のアドレスに戻して配信する。（例えば、特許文献３参照）。
【０００７】
この技術を利用すれば、メールの送信者の電子メールアドレスを匿名アドレスに変換して更新通知メールを配信することが可能となり、更新通知の受信者に対して送信者の電子メールアドレスを公開せずに通知メールを送ることができる。また、受信者は送信者の匿名アドレス宛てにメールを返信することができるため、送信者のアドレスを知らなくてもメールを返信することが可能となる。
【特許文献１】特登録３５７１７９４号
【特許文献２】特開２００４−５５００号公報
【特許文献３】特開２０００−１７４８０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記従来のように、送信者および受信者の電子メールアドレスを非公開にしてコンテンツの登録や更新などの情報をユーザに通知する通知機能は実現されていた。しかしながら上記従来の通知方法は、コンテンツ管理システムが通知のメールを送信するためのもの、もしくは電子メールの送信者が自分の電子メールアドレスを秘匿しつつ受信者からの返信を受け取るためのものであった。すなわち、複数の受信者に対して通知が送られた後に、各々の受信者同士が各々のメールアドレスを他者に公開することなく、メールによる情報交換を行なうことについては考慮されていなかった。
【０００９】
例えば、コンテンツ管理システムからコンテンツの更新通知メールを受け取った受信者は、更新されたコンテンツを参照して、何らかの意見や感想を持つことが考えられる。例えば、そのコンテンツが文書であれば、これを参照したユーザは記述内容の誤りを見つけたり、記述されている内容に対する賛成、反対などの意見等を持つであろう。そのような意見情報は、更新通知の送信者だけでなく、更新通知を受け取った他の受信者とも共有したい情報である。したがって受信者は、更新後コンテンツに対する自身の意見や感想を、更新通知メールの送信者だけではなく、該通知メールを受け取っている他のユーザに対しても、メールによって発信できることが望ましい。しかしながら、このような発信を行うには以下の様な問題があった。
【００１０】
第１の問題は、メールを受信する通知対象ユーザ群の特定に関する問題である。上記従来の技術では、文書管理システムからの更新通知メールは、そのコンテンツに対してある一定の権限を有しているユーザ群に対して発信される。この通知対象ユーザ群の指定方法としては例えば、そのコンテンツの更新通知を受ける権限そのものを指定する方法や、そのコンテンツに対して「参照権限以上を有しているユーザ」等の権限範囲を指定する方法が考えられる。
【００１１】
しかしながら、コンテンツとユーザ間の権限の設定は随時変更される可能性があり、該変更に応じて、そのコンテンツの通知対象ユーザ群も変動する可能性がある。すなわち、時間経過と共に、かつては更新通知対象に含まれていたユーザが通知対象ユーザ群から外れてしまったり、かつては通知対象に含まれていなかったユーザが通知対象ユーザ群に追加される、というような変動がおきる可能性が常にある。
【００１２】
以上の可能性を前提として、ここで、コンテンツ管理システムから“ＴＯ”もしくは“ＣＣ”アドレスに通知対象ユーザ群の個々のメールアドレスを指定した更新通知メールが発信された場合を考える。以降、このコンテンツ管理システムから最初に送信されるメールを「オリジナル更新通知メール」と称する。
【００１３】
オリジナル更新通知メールを受信したユーザは、自分の意見等をメールに記載して、オリジナル更新通知メールの受信者全員に該メールを発信することが可能である。すなわち、オリジナル更新通知メールの“ＴＯ”もしくは“ＣＣ”アドレスに指定されている全アドレスを、自分のメールの“ＴＯ”や“ＣＣ”アドレスに指定して送信すれば良い。以降、オリジナル更新通知メールを受け取った後の受信者からの発信メールを「受信者間メール」と称する。
【００１４】
しかしながら、受信者間メールが送信される宛先は、先に送られたオリジナル更新通知メールに指定されていた受信者群に限定されてしまう。
【００１５】
上述したように、コンテンツの更新通知メールの通知対象ユーザ群は変動する可能性がある。したがって、オリジナル更新通知メール発信後に、その通知対象ユーザ群から外れたユーザに対して受信者間メールが配信されてしまうという、好ましくない事態が発生しうる。一方、オリジナル更新通知メール発信後に新たにその通知対象ユーザ群に追加されたユーザに対しては、その追加以降に発信された受信者間メールが配信されることが好ましい。
【００１６】
しかし、“ＴＯ”や“ＣＣ”アドレスへの返信によるメールの交換を行う場合では、返信するユーザが通知対象ユーザ群における上述したような通知対象者の変動を把握することは困難であった。したがって、通知対象ユーザの変動を反映させた最適な配信を行うことは容易にはできなかった。。
【００１７】
第２の問題は、プライバシーを重視して、オリジナル更新通知メールの“ＢＣＣ”アドレスに受信者を指定して通知する場合である。この場合、通知対象ユーザ群のアドレスが“ＢＣＣ”アドレスに指定され、個々の受信者には他の受信者のアドレスが公開されないため、受信者間メールを送ることができないという問題があった。
【００１８】
本発明は上述した問題を解決するためになされたものであり、以下の機能を実現するコンテンツ管理システムおよびその制御方法を提供することを目的とする。すなわち、コンテンツの更新等を該コンテンツに関係付けられたユーザにメールで通知する際に、そのメールに返信することで適切な通知対象者にメールを送信する。また、通知対象者にメールを送信する際に、他の通知対象者のメールアドレスを秘匿する。
【課題を解決するための手段】
【００１９】
上記目的を達成するための一手段として、本発明のコンテンツ管理システムは以下のような構成を備える。
【００２０】
すなわち、システム内のコンテンツ情報を管理するコンテンツ管理サーバと、複数のクライアント装置がネットワークを介して接続され、前記コンテンツ管理サーバと前記クライアント装置のユーザとの間におけるメール通信を可能とするコンテンツ管理システムであって、前記コンテンツ管理サーバは、複数のユーザ情報と複数のコンテンツ情報を管理して、コンテンツの更新を監視するコンテンツ管理手段と、前記コンテンツ管理手段によってコンテンツが更新された旨が通知された場合に、前記ユーザ情報および前記コンテンツ情報に基づいて特定される、前記クライアント装置における更新通知対象ユーザに対して、更新通知メールを送信する更新通知手段と、前記更新通知メールに対して前記更新通知対象ユーザのうちの１ユーザからの返信メールを受信した場合に、該返信メールを、前記ユーザ情報および前記コンテンツ情報に基づいて特定される更新通知対象ユーザに対して転送するメール転送手段と、を有することを特徴とする。
【００２１】
例えば、前記更新通知手段は、前記更新通知メールに対し、前記更新通知対象ユーザの電子メールアドレスをＢＣＣアドレスに設定し、システムで唯一の受信用アドレスをＴＯアドレスに設定して、送信することを特徴とする。
【００２２】
例えば、前記メール転送手段は、前記返信メールに対し、前記更新通知対象ユーザの電子メールアドレスをＢＣＣアドレスに設定し、前記受信用アドレスをＴＯアドレスに設定して、転送することを特徴とする。
【発明の効果】
【００２３】
本発明によれば、コンテンツの更新等を該コンテンツに関係付けられたユーザにメールで通知する際に、そのメールに返信することで適切な通知対象者にメールを送信することができる。また、通知対象者にメールを送信する際に、他の通知対象者のメールアドレスを秘匿することができる。
【発明を実施するための最良の形態】
【００２４】
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の各実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００２５】
＜第１実施形態＞
●システム構成
図１は、本実施形態における通知機能を実現する、コンテンツ管理システムの構成を示す図である。同図に示すように本実施形態のコンテンツ管理システムは、クライアントコンピュータ１０１、コンテンツ管理サーバ１０２、メールサーバ１０３が、インターネットなどのネットワーク１００を介して接続されることによって構成される。
【００２６】
図１において、クライアントコンピュータ１０１（１）、１０１（２）、…、１０１（Ｎ）は、各々同様な構成を有している。したがって、ここでは説明を簡略化するために、複数のクライアントコンピュータ１０１（１）、１０１（２）、…、１０１（Ｎ）の中で特定されたクライアントコンピュータを指す場合は、クライアントコンピュータ（Ｘ）と記す。また、複数のクライアントコンピュータ１０１（１）、１０１（２）、…、１０１（Ｎ）の全てを指す場合は、単にクライアントコンピュータ１０１と記す。メールサーバ１０３（１）、１０３（２）、…、１０３（Ｎ）についても同様である。また、ネットワーク１００としては、本実施形態ではインターネットを例に説明するが、これはＬＡＮ等の他のネットワークシステムであってもかまわない。また、本実施形態ではコンテンツ管理サーバ１０２とメールサーバ１０３を別々のサーバ構成として記載するが、これらが同一サーバの構成をとっても構わない。また、本実施形態では１台のメールサーバ１０３が、メールの送信機能と受信機能の双方を有しているものとして記述しているが、受信用のメールサーバ、送信用のメールサーバとして別々の構成となっていても構わない。
【００２７】
コンテンツ管理サーバ１０２、メールサーバ１０３は、それぞれ後述するようにＣＰＵ、ＲＯＭ、ＲＡＭ、ＨＤＤ等を備えた情報処理装置（コンピュータ）により構成される。また、クライアントコンピュータ１０１は、ネットワーク閲覧手段を備えた一般的な情報処理装置（コンピュータ）により構成される。
【００２８】
図２は、コンテンツ管理サーバ１０２およびメールサーバ１０３の具体的な構成例を示す図である。同図において、２０１は情報処理装置の演算・制御を司る中央演算装置（以下、ＣＰＵと記す）である。２０２はランダムアクセスメモリ（以下、ＲＡＭと記す）であり、ＣＰＵ２０１の主メモリとして、及び実行プログラムの領域や該プログラムの実行エリアならびにデータエリアとして機能する。
【００２９】
２０３はＣＰＵ２０１の動作処理手順を記憶しているリードオンリメモリ（以下、ＲＯＭと記す）である。ＲＯＭ２０３には情報処理装置の機器制御を行うシステムプログラムである基本ソフト（ＯＳ）を記録したプログラムＲＯＭと、システムを稼働するために必要な情報等が記録されているデータＲＯＭがある。また、ＲＯＭ２０３の代わりに、後述するＨＤＤ２０９を用いる場合もある。
【００３０】
２０４はネットワークインターフェース（ＮＥＴＩＦ）であり、ネットワークを介して情報処理装置間のデータ転送を行うための制御や接続状況の診断を行う。２０５はビデオＲＡＭ（ＶＲＡＭ）であり、後述する情報処理装置の稼働状態を示すＣＲＴ２０６の画面に表示させるための画像を展開し、その表示の制御を行う。２０６はディスプレイ等の表示装置（以下、ＣＲＴと記す）である。
【００３１】
２０７は外部入力装置２０８からの入力信号を制御するためのコントローラ（以下、ＫＢＣと記す）である。２０８は利用者が行う操作を受け付けるための外部入力装置（以下、ＫＢＣと記す）であり、例えばキーボードやマウス等のポインティングデバイスが用いられる。
【００３２】
２０９はハードディスクドライブ（以下、ＨＤＤと記す）であり、アプリケーションプログラムや各種データ保存用に用いられる。本実施形態におけるアプリケーションプログラムとは、本実施形態における各種処理手段を実行するソフトウェアプログラム等である。
【００３３】
２１０は外部入出力装置（以下、ＦＤＤと記す）であり、例えばフロッピー（登録商標）ディスクドライブ、ＣＤＲＯＭドライブ等のリムーバブルディスクを入出力するものであり、上述したアプリケーションプログラムの媒体からの読み出し等に用いられる。
【００３４】
２１３は、取り外し可能なデータ記録装置（リムーバブル・メディア）であり、以下、ＦＤと記す。ＦＤ２１３としては例えば、ＦＤＤ２１０によって読み出しされる、磁気記録媒体（フロッピー（登録商標）ディスクや外付けハードディスク等）、光記録媒体（ＣＤ−ＲＯＭ等）、光磁気記録媒体（ＭＯ等）、半導体記録媒体（メモリカード等）などがある。尚、ＨＤＤ２０９に格納するアプリケーションプログラムやデータを、ＦＤＤ２１０に格納して使用することも可能である。
【００３５】
２１１は後述するＰＲＴ２１２への出力信号を制御するためのコントローラ（以下、ＰＲＴＣと記す）である。２１２は印刷装置（以下、ＰＲＴと記す）であり、例えばレーザビームプリンタ（ＬＢＰ）等が用いられる。２００は上述した各ユニット間を接続するための伝送バス（アドレスバス、データバス、入出力バス、及び制御バス）である。
【００３６】
図３は、クライアントコンピュータ１０１、コンテンツ管理サーバ１０２、メールサーバ１０３内で動作する処理モジュール群及び情報を格納する格納装置群、それら処理モジュール群及び格納装置群間の制御及び情報の流れを説明するための図である。
【００３７】
図３において、３０３、３０４、３０５、３１１、３１２は処理モジュールである。これら処理モジュールは、図２に示したＲＯＭ２０３、ＨＤＤ２０９、又はＦＤＤ２１０より読み込まれてＲＡＭ２０２に展開され、ＣＰＵ２０１で使用されるアプリケーションプログラム、又はプログラムの一部として動作する。
【００３８】
図３において、３０６はコンテンツ管理情報格納装置であり、ファイルシステムやデータベースシステムを用いて、コンテンツ管理サーバ１０２におけるＨＤＤ２０９、ＲＡＭ２０２、及びＦＤＤ２１０の少なくとも一つを用いて情報を格納する。コンテンツ管理情報格納装置３０６に格納された情報に対しては、特定のキーや条件を指定することによって、直接アクセスすることが可能である。なお、本実施形態においてはコンテンツ管理サーバ１０２内にコンテンツ管理情報格納装置３０６を備える例を示したが、本発明はこの構成に限定されない。例えば、コンテンツ管理情報格納装置を別のサーバ上に配置し、コンテンツ管理サーバ１０２からネットワークなどを介したアクセスを可能とするような構成も可能である。
【００３９】
図３に示す矢印は、図１のネットワーク１００を介して各処理モジュール間等でやり取りされる情報の流れや、主な処理の制御を表している。情報処理装置（コンテンツ管理サーバ１０２やメールサーバ１０３）とその中の処理モジュールや情報格納装置との関係は、自動起動されるか、ユーザがＫＢ２０８より入力した情報や指示が、必要に応じてＲＡＭ２０２に展開されてＣＰＵ２０１へ伝えられる。ＣＰＵ２０１での演算に必要な処理モジュールと情報格納装置に格納された情報は、ＲＯＭ２０３、ＨＤＤ２０９、ＦＤＤ２１０等からＲＡＭ２０２に展開されてＣＰＵ２０１へ伝えられる。ＣＰＵ２０１での演算結果は、必要に応じて、ＲＡＭ２０２、ＨＤＤ２０９、ＦＤＤ２１０等の情報格納装置にその情報が書き込まれる。また同時に、ＣＰＵ２０１での演算結果は必要に応じて、ＶＲＡＭ２０５を介してＣＲＴ２０６に表示される。ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＮＥＴＩＦ２０４、ＶＲＡＭ２０５、ＫＢＣ２０７、ＨＤＤ２０９、ＦＤＤ２１０間の伝送は、伝送バス２００を介して行われる。
【００４０】
図３においてコンテンツ管理サーバ１０２を利用するユーザは、クライアントコンピュータ１０１のネットワーク閲覧手段３０１を用いてコンテンツ管理サーバ１０２のコンテンツ管理モジュール３０３にアクセスする。これにより、コンテンツの作成、更新や、コンテンツに対する通知条件の設定などのコンテンツ操作を実行することが可能となる。
【００４１】
コンテンツ管理サーバ１０２内のコンテンツ管理モジュール３０３は、ユーザによってコンテンツに対する操作が行なわれると、更新通知モジュール３０４に操作が発生したことを通知することが可能である。
【００４２】
更新通知モジュール３０４は、コンテンツ管理モジュール３０３よりコンテンツの更新の通知を受け取ると、メールサーバ１０３にアクセスしてメール送信モジュール３１１を用いて、コンテンツの更新情報を電子メールで送信ことが可能である。
【００４３】
メール転送モジュール３０５は、メールサーバ１０３にアクセスしてメール受信モジュール３１２を用いてメールを受信し、再びメール送信モジュール３１１を用いてメールを転送することが可能である。
【００４４】
クライアントコンピュータ１０１を使用するユーザは、電子メール送受信手段３０２を用いてメールサーバ１０３にアクセスし、メール送信モジュール３１１や、メール受信モジュール３１２を使用してメールの送信や受信を行なうことが可能である。
【００４５】
コンテンツ管理情報格納装置３０６は情報格納装置であり、主な情報を格納するために、システム情報記憶部３０７と、ユーザ情報記憶部３０８と、コンテンツ情報記憶部３０９と、更新通知情報記憶部３１０を備える。システム情報記憶部３０７には、コンテンツ管理モジュール３０３、更新通知モジュール３０４、メール転送モジュール３０５が利用するシステム情報が格納されている。ユーザ情報記憶部３０８には、コンテンツ管理システムを利用可能なユーザの情報が格納されている。コンテンツ情報記憶部３０９には、コンテンツ管理モジュールが管理するコンテンツに関する情報や、コンテンツのファイル本体のデータ、及びユーザ情報記憶部３０８に格納されている各ユーザと各コンテンツの間のアクセス権限情報等が格納されている。更新通知情報記憶部３１０には、コンテンツ情報記憶部３０９に格納されている各コンテンツの更新通知設定情報が格納されている。
【００４６】
●コンテンツ管理情報
以下、コンテンツ管理サーバ１０２において、コンテンツ管理情報格納装置３０６の各記憶部に格納される情報について、詳細に説明する。
【００４７】
図４は、システム情報記憶部３０７に格納されている情報の具体例を示す図である。送信メールサーバアドレス４０１は、更新通知モジュール３０４、メール転送モジュール３０５がメールの送信に使用する送信用メールサーバを一意に特定するためのメールサーバアドレスである。この送信メールサーバアドレス４０１によって、ネットワーク１００を介して接続可能な複数のメールサーバ１０３の中から、メール送信処理に使用するメールサーバを指定することが可能となる。送信メールサーバアカウントＩＤ４０２と送信メールサーバパスワード４０３は、そのメールサーバを使用する認証処理時に必要となる認証情報を表している。受信メールサーバアドレス４０４は、メール転送モジュール３０５がメールの受信に使用する受信用メールサーバを一意に特定するためのメールサーバアドレスである。この受信メールサーバアドレス４０４によって、ネットワーク１００を介して接続可能な複数のメールサーバ１０３の中から、メール受信処理に使用するメールサーバを指定することが可能となる。受信メールサーバアカウントＩＤ４０５と受信メールサーバパスワード４０６は、そのメールサーバを使用する認証処理時に必要となる認証情報を表している。システムメールアドレス４０７は、受信用メールサーバ４０４で受信するメールのメールアドレスである。図４の例では、“server@contx.co.jp”というメールアドレスを使用する旨が示されている。
【００４８】
図５は、ユーザ情報記憶部３０８に格納された、コンテンツ管理処理モジュール３０３を利用するユーザを管理するためのユーザ情報のフォーマットを表す図である。
【００４９】
図５において、ユーザ情報テーブル５００は、コンテンツ管理モジュール３０３を利用するユーザと１対１に対応し、ユーザを一意に識別するユーザＩＤ５０１と、パスワード５０２、ユーザが使用する電子メールのメールアドレス５０３などから構成される。メールアドレス５０３は、各々のユーザに対して更新通知モジュール３０４がメールを送信する際に、宛先として使用するメールアドレスである。
【００５０】
図６は、図５に示したユーザ情報記憶部３０８に格納されているユーザ情報の具体例を示しており、すなわち、図６における表６００が、ユーザ情報テーブル５００の具体例である。
【００５１】
図６において、データ行６００（１）は、ユーザＩＤ＝“USER_A”に該当するユーザのユーザ情報である。データ行６００（１）では、メールアドレス＝“user_a@aaa.co.jp”となっており、“USER_A”が“user_a@aaa.co.jp”というメールアドレスを使用していることを示している。すなわち、更新通知モジュール３０４やメール転送モジュール３０５がユーザＩＤ＝“USER_A”のユーザに対してメールを送信する場合には、メールの宛先としてメールアドレス＝“user_a@aaa.co.jp”を指定することを示している。データ行６００（２）、及びデータ行６００（３）も同様に、それぞれユーザＩＤ＝“USER_B”、及びユーザＩＤ＝“USER_C”に該当するユーザ情報である。それぞれ、メールアドレス＝“user_b@bbb.co.jp”と、メールアドレス＝“user_c@ccc.co.jp”というメールアドレスを使用することを示している。データ行６００（Ｎ）はその他のユーザの情報についても、先に説明したデータ行６００（１）やデータ行６００（２）、データ行６００（３）と同様の形式で格納されていることを表している。
【００５２】
図７は、コンテンツ情報記憶部３０９に格納され、コンテンツ管理モジュール３０３によって管理されるコンテンツ及び各コンテンツと各ユーザ間のアクセス権限情報のフォーマットを表す図である。
【００５３】
図７において、コンテンツ基本情報テーブル７００は、コンテンツＩＤ７０１と格納場所７０２から構成される。コンテンツＩＤ７０１は、コンテンツ管理モジュール３０３で管理されているコンテンツと１対１に対応し、コンテンツを一意に識別するためのＩＤ情報である。また格納場所７０２は、コンテンツＩＤ７０１によって特定されるコンテンツの格納されているファイルシステム上の位置を表す情報である。
【００５４】
図７において、コンテンツ権限情報テーブル７０３は、コンテンツ基本情報テーブル７００で管理されている各コンテンツに対して、コンテンツ管理モジュール３０３を利用するユーザがどのような権限を有しているかを定義する。コンテンツＩＤ７０４は、コンテンツ基本情報テーブル７００で管理されているコンテンツＩＤ７０１に対応するものである。ユーザＩＤ７０５は、図５に示したユーザ情報テーブル５００のユーザＩＤ５０１に対応するものである。権限７０６は、コンテンツＩＤ７０４よって特定されたコンテンツに対して、ユーザＩＤ７０５によって特定されたユーザがどのような権限を有しているかを表すものである。
【００５５】
図８は、図７に示したコンテンツ情報記憶部３０９に格納されているコンテンツ情報の具体例を示しており、図８における表８００がコンテンツ基本テーブル７００の具体例を、表８０１がコンテンツ権限テーブル７０３の具体例を示している。
【００５６】
表８００において、データ行８００（１）はコンテンツＩＤ＝“Ｘ００１”で一意に識別されるコンテンツが、格納場所＝“/contents/X001/X001.doc”で示されるようなファイルシステム上のパスに配置されていることを表している。データ行８００（２）も同様に、コンテンツＩＤ＝“Ｘ００２”で一意に識別されるコンテンツが、格納場所＝“/contents/X002/X002.xls”で示されるファイルシステム上のパスに配置されていることを表している。また、データ行８００（３）も、コンテンツＩＤ＝“Ｘ００３”で一意に識別されるコンテンツが、格納場所＝“/contents/X002/X003.jpg”で示されるファイルシステム上のパスに配置されていることを表している。なお、本実施形態ではコンテンツをファイルシステム上に配置し、そのパスを格納場所として記憶することとしているが、本発明はこの例に限定されない。例えば、コンテンツをデータベース内に格納するなどして、そのデータのポインタを管理する方法等をとっても構わない。
【００５７】
表８０１において、データ行８０１は、表８００の各データ行で管理されているコンテンツに対して、図６に示した表６００における各データ行で表されるユーザが、各々どのような権限を有しているかを表している。例えばデータ行８０１（１）は、コンテンツＩＤ＝“Ｘ００１”で特定されるコンテンツに対して、ユーザＩＤ＝“ＵＳＥＲ＿Ａ”で特定されるユーザが、“参照”権限と、“更新”権限と、“削除”権限を有していることを表している。他のデータ行８０１に関しても同様である。なお、本実施形態は図８において、ユーザＩＤ単位に権限を管理し、権限の種類として参照、更新、削除、不可、等を使用する例を示した。しかしながら本発明はこの例に限定されるものではなく、複数のユーザをグループとして管理し、グループに対してコンテンツの権限を管理しても良く、また、図８に示した種類以外の権限等を使用しても良い。
【００５８】
図９は、更新通知情報記憶部３１０に格納され、更新通知モジュール３０４によって実施される更新通知処理の設定を管理するための情報のフォーマットを表す図である。
【００５９】
図９において、更新通知情報テーブル９００は、図７に示したコンテンツ基本情報テーブル７００によって管理されている各コンテンツに対して、どのような更新通知の処理条件が設定されているかを管理するものである。コンテンツＩＤ９０１は、コンテンツ基本情報テーブル７００のコンテンツＩＤ７０１に対応するものである。更新通知対象設定９０２は、そのコンテンツに対して操作が行なわれた時に更新通知メールを送信する通知処理を実行するか否かを表すものである。更新通知対象ユーザ権限９０３は、更新通知の宛先として指定する通知対象ユーザ群を、コンテンツに対する権限の種類によって指定するためのものである。更新通知キーワード９０４は、更新通知のメール情報に挿入する文字列である。この更新通知キーワード９０４の文字列は、コンテンツ基本情報テーブル７００のコンテンツＩＤ７０１と同様にコンテンツと１対１に対応しており、これによって、コンテンツ基本情報テーブル７００に管理されているコンテンツが一意に特定される。
【００６０】
図１０は、図９に示した更新通知情報記憶部３１０に格納されている更新通知情報の具体例を示しており、図１０における表１０００が、更新通知情報テーブル９００の具体例を示している。
【００６１】
まず、図１０におけるデータ行１０００（１）について説明する。データ行１０００（１）において、コンテンツＩＤ＝“Ｘ００１”は、図８のデータ行８００（１）に示されたコンテンツＩＤ＝“Ｘ００１”に対応するコンテンツのデータであることを示している。また、更新通知対象設定＝“通知する”は、このデータ行のコンテンツが更新通知処理対象として指定されていること、即ち、更新通知メールが送信されるコンテンツであることを表している。また、更新通知対象ユーザ権限＝“参照、更新、削除”は、このコンテンツに対して“参照”、又は“更新”、又は“削除”の権限を有するユーザに対して、更新通知メールを送信することを表している。また、更新通知キーワード＝“ＫＥＹ＿Ｘ００１”は、コンテンツＩＤ＝“Ｘ００１”のコンテンツに対して一意に設定される更新通知キーワードが“ＫＥＹ＿Ｘ００１”であることを表している。すなわち、更新通知キーワードとして“ＫＥＹ＿Ｘ００１”を使用するコンテンツがコンテンツＩＤ＝“Ｘ００１”以外に存在しないことを示している。
【００６２】
図８のデータ行８０１（１），８０１（２）,８０１（３）によれば、“ＵＳＥＲ＿Ａ”,“ＵＳＥＲ＿Ｂ”,“ＵＳＥＲ＿Ｃ”はコンテンツＩＤ＝“Ｘ００１”に対してそれぞれの権限を有していることが表されている。よって、データ行１０００（１）の例によれば、コンテンツＩＤ＝“Ｘ００１”のコンテンツに対して“参照”又は“更新”又は“削除”の権限を有するユーザという条件に、“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”が適合することとなる。したがって、“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”は、更新通知メールが送られる対象となる。
【００６３】
図１０において、データ行１０００（２）については、そのコンテンツＩＤは“Ｘ００２”であるが、これはデータ行１０００（１）と同様に、図８のデータ行８００（２）に示されたコンテンツＩＤ＝“Ｘ００２”に対応するコンテンツの更新通知情報を示す。
【００６４】
また、データ行１０００（３）についても同様に、そのコンテンツＩＤである“Ｘ００３”は、図８のデータ行８００（３）に示されたコンテンツＩＤ＝“Ｘ００３”に対応するコンテンツの更新通知情報を示す。ここで、データ行１０００（３）の更新通知情報設定＝“通知しない”は、このコンテンツが更新通知処理対象として指定されていない旨、すなわち、このコンテンツについては、ユーザが操作を行なっても更新通知メールが発信されないことを示している。データ行１０００（３）の更新通知対象ユーザ権限、及び更新通知キーワードは、この行のコンテンツが新通知処理対象として指定されていないため、特にデータが指定されないことを表している。
【００６５】
本実施形態においては、図１０に示した更新通知情報記憶部３１０について、更新通知設定について通知を行なうか否かの２設定のみを可能とする例を示した。しかしながら本発明はこの例に限定されず、例えばある特定の操作が行なわれた時にのみ通知するなど、通知対象とする操作の種類を限定するように通知条件の詳細設定を可能としても良い。
【００６６】
●コンテンツ更新通知情報の設定
図１１は、ユーザがコンテンツ管理モジュール３０３を用いて、或るコンテンツについての更新通知情報テーブル９００の情報を指定する際の処理概要を示すフローチャートである。この処理によってコンテンツ管理モジュール３０３はまず、ユーザが指定したコンテンツに対して、更新通知を行なうか否かを設定する。そしてさらに、更新通知を行なう場合にはどのような権限を有するユーザをその通知対象とするか、その際の更新通知キーワードはどのような文字列とするか、という情報の設定を行なう。
【００６７】
まずステップＳ１１０１において、ユーザはクライアントコンピュータ（Ｘ）のネットワーク閲覧手段３０１を使用して、コンテンツ管理サーバ１０２のコンテンツ管理モジュール３０３にアクセスする。そして、或るコンテンツを指定し、更新通知設定の処理の開始を指示する。コンテンツ管理モジュール３０３は、指定されたコンテンツのコンテンツＩＤを取得して更新通知情報テーブル９００を検索し、そのコンテンツＩＤに対応するデータ行を取得し、その内容をユーザに提示する。するとユーザは、提示された内容を確認して、所望の更新通知条件情報を指定する。ユーザが指定できる情報は、更新通知対象設定９０２、更新通知対象ユーザ権限９０３である。
【００６８】
次にステップＳ１１０２において、コンテンツ管理モジュール３０３はユーザの指定内容を取得して、まず、当該コンテンツが更新通知の通知対象として指定されたか否かを確認する。「通知対象ではない」と指定された場合にはステップＳ１１０７に進み、当該コンテンツに対応する更新通知情報テーブル９００のデータ行の更新通知キーワード９０４の設定をクリアする。この具体例が、図１０に示したデータ行１０００（３）である。なお、この時、更新通知対象ユーザ権限９０３に対応する設定値もクリアしても構わない。
【００６９】
ステップＳ１１０２で「通知対象である」と指定された場合にはステップＳ１１０３へ進む。ステップＳ１１０３では、ステップＳ１１０１で取得したデータ行の更新通知キーワード９０４が既に設定済みであるか否かを確認し、設定済みであればステップＳ１１０５へ進む。この設定済みの場合の具体例が、図１０に示したデータ行１０００（２）である。一方、更新通知キーワード９０４が未設定であればステップＳ１１０４へ進む。この未設定の場合の具体例が、図１０に示したデータ行１０００（３）である。
【００７０】
ステップＳ１１０４において、コンテンツ管理モジュール３０３は、当該コンテンツに対する新たな更新通知キーワードの文字列を生成する。この更新通知キーワードは、図７のコンテンツ基本情報テーブル７００において管理されているコンテンツと１対１で対応するものであり、コンテンツを一意に識別できる値である。よってコンテンツ管理モジュール３０３は、図９に示した更新通知情報テーブル９００の更新通知キーワード９０４に格納されている既存の情報を調査し、未使用の更新通知キーワードを生成する。なお、本実施形態においてはコンテンツ管理モジュール３０３が更新通知キーワードを生成する例を示したが、これをユーザが任意に指定できるものとしても構わない。その場合にはコンテンツ管理モジュール３０３において、ユーザの指定した値が更新通知情報テーブル９００内で使用されていない値であることをチェックする必要がある。
【００７１】
ステップＳ１１０５において、コンテンツ管理モジュール３０３は、更新通知キーワードの情報と、それ以外にユーザが指定した更新通知対象ユーザ権限の情報を、当該コンテンツに対応する更新通知情報テーブル９００のデータ行に保存する。
【００７２】
以上で、図１１に示された、或るコンテンツについての更新通知情報テーブル９００の設定処理は終了する。図１０に示した具体例は、この処理結果の具体例でもある。
【００７３】
●オリジナル更新通知メールの送信処理
以上のように、更新通知メールを発信する対象となるコンテンツの条件設定が完了すると、次に、この条件設定に従って実際に更新通知が発信される。以下、コンテンツ更新に伴う更新通知メールの送信処理について説明する。
【００７４】
図１２は、ユーザがコンテンツ管理モジュール３０３を用いて、或るコンテンツについて更新などの操作を行なった後に発生する更新通知メールの送信処理の概要を示すフローチャートである。
【００７５】
図１２のステップＳ１２０１において、ユーザがクライアントコンピュータ（Ｘ）のネットワーク閲覧手段３０１を用いてコンテンツ管理サーバ１０２のコンテンツ管理モジュール３０３にアクセスし、或るコンテンツに対して更新等の操作を行う。するとコンテンツ管理モジュール３０３は、更新通知処理モジュール３０４に対して更新の操作対象となったコンテンツのコンテンツＩＤを通知する。
【００７６】
次にステップＳ１２０２において、通知を受けた更新通知モジュール３０４は、更新されたコンテンツのＩＤに基づいて図９に示す更新通知情報テーブル９００を検索する。そして、該当する更新通知情報データ行を取り出し、更新通知対象設定９０２に指定されている値を確認する。例えば、図１０に示す例によれば、当該コンテンツのコンテンツＩＤが“Ｘ００１”である場合には、更新通知対象設定９０２の値は“通知する”である（データ行１０００（１）参照）。またコンテンツＩＤが“Ｘ００３”である場合には、更新通知対象設定９０２の値は“通知しない”である（データ行１０００（３）参照）。
【００７７】
そしてステップＳ１２０３において、更新通知モジュール３０４はステップＳ１２０２において確認された更新通知対象設定９０２の値が“通知しない”であった場合には、これ以上処理を続行する必要が無いと判断して処理を終了する。一方、更新通知対象設定９０２の値が「通知する」であった場合には、ステップＳ１２０４へ進む。
【００７８】
ステップＳ１２０４では、ステップＳ１２０２で取得した当該コンテンツの更新通知情報テーブル９００のコンテンツＩＤ９０１と、更新通知対象ユーザ権限９０３に指定されている値とに基づいて、コンテンツ権限情報テーブル７０３が検索される。そして、当該コンテンツに対して更新通知対象ユーザ権限９０３に指定されている権限を有するユーザＩＤの一覧を取得する。このユーザＩＤの一覧はすなわち、当該コンテンツに対して更新操作が行われた際に更新通知メールを送信する対象となるユーザのＩＤの一覧である。以降、この通知対象のユーザ群を「通知対象ユーザ群」と称する。
【００７９】
ここで、ステップＳ１２０４における通知対象ユーザ群の決定処理について、具体例を挙げてさらに詳細に説明する。
【００８０】
図１０のデータ行１０００（１）に示される、コンテンツＩＤが“Ｘ００１”であるデータを例とすると、更新通知対象ユーザ権限９０３の値は“参照、更新、削除”である。よって、コンテンツＩＤ＝“Ｘ００１”であるコンテンツに対して、参照、又は更新、又は削除の権限を有しているユーザが、通知対象ユーザ群に追加される。図８の例において、当該コンテンツに対してそのような権限を有しているユーザは、“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”である。（図８のデータ行８０１（１），８０１（２），８０１（３）参照）。したがって、これらのユーザがコンテンツＩＤ＝“Ｘ００１”のコンテンツの通知対象ユーザ群となる。
【００８１】
また、図１０のデータ行１０００（２）に示される、コンテンツＩＤが“Ｘ００２”であるデータを例とすると、更新通知対象ユーザ権限９０３の値は“参照、更新”である。よって、コンテンツＩＤ＝“Ｘ００２”であるコンテンツに対して、参照、又は更新の権限を有しているユーザが、通知対象ユーザ群に追加される。図８の例において、当該コンテンツに対してそのような権限を有しているユーザは、“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”である。（図８のデータ行８０１（４），８０２（５）参照）。したがって、これらのユーザがンテンツＩＤ＝“Ｘ００２”のコンテンツの通知対象ユーザ群となる。
【００８２】
以上のようにステップＳ１２０４で通知対象ユーザ群が決定されると、次にステップＳ１２０５において更新通知モジュール３０４は、該通知対象ユーザ群に該当するユーザＩＤの一覧を用いてユーザ情報テーブル５００を検索する。そして、対応するデータ行のメールアドレス５０３を取得する。ここで、図８及び図１０を例にとると、コンテンツＩＤ＝“Ｘ００１”のコンテンツの通知対象ユーザ群は“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”である。したがって、図６に示すユーザ情報によれば、対応するメールアドレスはそれぞれ、“user_a@aaa.co.jp”，“user_b@bbb.co.jp”，“user_c@ccc.co.jp”である。（図６のデータ行６００（１）、６００（２）、６００（３）参照）。
【００８３】
次にステップＳ１２０６において、更新通知モジュール３０４は、ステップ１２０２で取得した当該コンテンツの更新通知情報テーブル９００のデータ行における、更新通知キーワード９０４の値を取得する。図１０を例にとれば、当該コンテンツのコンテンツＩＤが“Ｘ００１”である場合、更新通知キーワード９０４の値は“ＫＥＹ＿Ｘ００１”である（図１０のデータ行１０００（１）参照）。
【００８４】
次にステップＳ１２０７において、更新通知モジュール３０４は、システム情報記憶部３０７に格納されているシステム情報（図４参照）を取得する。
【００８５】
次にステップＳ１２０８において、更新通知モジュール３０４は、更新通知メールとして送信するオリジナル更新通知メールを作成する。ここで「オリジナル更新通知メール」とは、コンテンツに対する操作によってサーバ側で作成されて送られる更新通知メールを称したものであり、後述する「受信者間メール」や「転送通知メール」と区別する。なお、「受信者間メール」とは「オリジナル更新通知メール」を受け取ったユーザが作成して送信するメールであり、「転送通知メール」とは「受信者間メール」を受け取った更新通知モジュール３０４が転送するメールである。
【００８６】
ここで、オリジナル更新通知メールの作成方法について説明する。
【００８７】
まず、ＦＲＯＭアドレス、ＲＥＰＬＹ−ＴＯアドレス、ＴＯアドレスに対し、ステップＳ１２０７で取得したシステム情報記憶部３０７に格納されている、システム情報内のシステムメールアドレス４０７に該当するアドレスを設定する。このように、ＦＲＯＭアドレスやＲＥＰＬＹ−ＴＯアドレスにシステムメールアドレスを指定するのは、後にオリジナル更新通知メールを受信したユーザが、容易に受信者間メールを作成できるようにするためである。すなわち、このオリジナル更新通知メールに対する「返信」として受信者間メールを作成すれば、システムメールアドレスが受信者間メールのＴＯアドレスに指定されるため、受信者間メールの作成が容易となる。またＢＣＣアドレスに対しては、ステップＳ１２０５で取得した通知対象ユーザ群のメールアドレス一覧を指定する。これにより、受信者同士で互いのメールアドレスが露呈されることを回避できる。またＳＵＢＪＥＣＴに対しては、ステップＳ１２０６で取得した更新通知キーワードを指定する。なお、メールの本文については特に規定はない。
【００８８】
ここで、ステップＳ１２０８において作成されるオリジナル更新通知メールの具体例を図１４に示し、詳細に説明する。図１４に示すオリジナル更新通知メール１４００は、図４、図６、図８、図１０で示された具体例に基づき、コンテンツＩＤ＝“Ｘ００１”のコンテンツのオリジナル更新通知メールの具体例である。
【００８９】
ＦＲＯＭドレス１４０１、ＲＥＰＬＹ−ＴＯアドレス１４０２、ＴＯアドレス１４０３には、ステップＳ１２０７で取得した、システム情報のシステムメールアドレス４０７＝“server@contx.co.jp”（図４参照）が指定されている。ＢＣＣアドレス１４０４には、ステップＳ１２０５で取得したコンテンツＩＤ＝“Ｘ００１”の通知対象ユーザ群である、“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”の各ユーザのメールアドレスが指定されている。ＳＵＢＪＥＣＴ１４０５には、ステップＳ１２０６で取得したコンテンツＩＤ＝“Ｘ００１”に対応する更新通知キーワード＝“ＫＥＹ＿Ｘ００１”が指定されている。更新通知モジュール３０４は、メール本文１４０６に例えば通知する内容を記載するが、上述したようにその内容自体は限定されないため、説明を割愛する。
【００９０】
なお、図１４のオリジナル更新通知メール１４００では、ＢＣＣアドレス１４０４に通知対象ユーザ群のメールアドレスをすべて指定する例を示したが、これを或る人数ごとに分けて複数のオリジナル更新通知メールを作成しても良い。
【００９１】
以上のようにステップＳ１２０８でオリジナル更新通知メールが作成されると、次にステップＳ１２０９において、更新通知モジュール３０４は、このオリジナル更新通知メールの送信処理を実行する。この送信処理は、ステップＳ１２０７で取得した送信メールサーバアドレス４０１、送信メールサーバアカウントＩＤ４０２、送信メールサーバパスワード４０３等をもとに、メールサーバ１０３（Ｘ）のメール送信モジュール３１１にアクセスして行われる。
【００９２】
以上の様に、図１２のフローチャートに示す処理によって、コンテンツに対して更新等の操作を行なった後に発生する更新通知メールが送信される。
【００９３】
●受信されたオリジナル更新通知メール
更新通知モジュール３０４から発信されるオリジナル更新通知メールの送信先は、通知対象ユーザ群に指定されたユーザのメールアドレスと、システム情報記憶部３０７に格納されているシステム情報の送信メールサーバアドレス４０１に対応する。通知対象ユーザ群のアドレスに送られたオリジナル更新通知メールは、各ユーザによって、クライアントコンピュータ１０１（Ｘ）の電子メール送受信手段３０２を介して受信される。
【００９４】
ユーザが受信したメールは、ＦＲＯＭアドレス、ＲＥＰＬＹ−ＴＯアドレス、ＴＯアドレス、ＳＵＢＪＥＣＴ、メールの本文の内容については、更新通知モジュール３０４が作成した内容と等しくなる。しかし、ＢＣＣアドレスを使用している場合、各ユーザが受信したメールのＢＣＣアドレスには、アドレスが記載されていない状態となる。
【００９５】
図１４の受信されたオリジナル更新通知メール１４１０は、更新通知モジュール３０４が送信したオリジナル更新通知メール１４００を、各ユーザがクライアントコンピュータ１０１（Ｘ）の電子メール送受信手段３０２で受信した際のメール情報を示している。
【００９６】
受信されたオリジナル更新通知メール１４１０のＦＲＯＭアドレス１４１１、ＲＥＰＬＹ―ＴＯアドレス１４１２、ＴＯアドレス１４１３、ＳＵＢＪＥＣＴ１４１５、メール本文１４１６はそれぞれ、オリジナル更新通知メール１４００の指定内容と同様である。しかし、ＢＣＣアドレス１４１４については、アドレスが記載されていない状態となる。すなわち、オリジナル更新通知メール１４００ではＢＣＣに通知対象ユーザ群の各メールアドレスが指定されているが、それを受信した各ユーザには、他にどのようなユーザが更新通知メールを受信しているかがメールからは判別できない状態となる。このように本実施形態では、他の受信者のアドレスを露呈してしまうことなく、すなわち受信者のプライバシーを守りつつ、通知の必要な受信者に対して通知メールを送付することができる。
【００９７】
●受信者間メール
本実施形態において、メールを受け取ったユーザがこの更新通知メールを受信した他のユーザと情報交換を行いたい場合、即ち各ユーザから他の受信者に対してメールを送信したい場合には、電子メール送受信手段３０２を用いてメールを返信する。このような、ユーザが返信するメールを「受信者間メール」と称する。
【００９８】
ユーザが受信者間メールを作成する上で遵守すべき規定は、ＴＯアドレス、ＦＲＯＭアドレス、ＳＵＢＪＥＣＴに対する指定内容であり、その内容を以下に説明する。
【００９９】
すなわち、受信者間メールのＴＯアドレスには、受信されたオリジナル更新通知メールに記載されているＲＥＰＬＹ−ＴＯアドレス、もしくはＦＲＯＭアドレスの内容を指定する。なお、受信されたオリジナル更新通知メールに記載されているＲＥＰＬＹ−ＴＯアドレスおよびＦＲＯＭアドレスには、常に同じアドレスが指定されているため、実質的にどちらを使用しても構わない。なお、一般的な電子メール作成アプリケーションを使用して返信メールを作成する場合には、受信したメールのＲＥＰＬＹ−ＴＯアドレスもしくはＦＲＯＭアドレスに指定されているアドレスを、受信者間メールのＴＯアドレスに設定するのが一般的である。
【０１００】
受信者間メールのＦＲＯＭアドレスには、ユーザが、受信されたオリジナル更新通知メールを受け取ったアドレスを指定する。即ち、元のオリジナル更新通知メールにおいて、ＢＣＣアドレスに指定されていた中の、そのユーザに該当する１つのアドレスを指定する。上述したように、ユーザ自身が受信したオリジナル更新通知メールにはＢＣＣアドレスが記載されていないが、そもそもそのメールの受信はできているため、ユーザはＢＣＣアドレスに指定されていた自分自身のアドレスは認識しているものと考えられる。
【０１０１】
受信者間メールのＳＵＢＪＥＣＴには、受信されたオリジナル更新通知メールに指定されていたＳＵＢＪＥＣＴを指定する。
【０１０２】
以上が、ユーザが受信者間メールを作成する上で注意すべき規定である。なお、受信者間メールのＲＥＰＬＹ−ＴＯアドレス、ＢＣＣアドレス、メールの本文については特に規定されないため、ユーザの任意に扱って構わない。
【０１０３】
図１５は、受信者間メールの具体例を示す図である。図１５の受信者間メール１５００は、オリジナル更新通知メール１４００を受け取ったユーザが、上述したような規定に従って、同じ更新通知メールを受け取っている他のユーザに対してメールを発信する際に作成した受信者間メールの例を示す。
【０１０４】
図１５において、ＴＯアドレス１５０３には、受信されたオリジナル更新通知メール１４１０のＲＥＰＬＹ−ＴＯアドレス１４１２に指定されているアドレスが指定されている。これは、システム情報記憶部３０７のシステムメールアドレス４０７と同じアドレスである。
【０１０５】
ＦＲＯＭアドレス１５０１、ＲＥＰＬＹ−ＴＯアドレス１５０２には、この受信者間メール１５００を作成したユーザ自身のメールアドレスが指定される。図１５の例においては、“user_a@aaa.co.jp”が指定されている。これは、このメールが図１４のオリジナル更新通知メール１４００のＢＣＣアドレス１４０４に指定されていたアドレスの中の、“user_a@aaa.co.jp”に該当するユーザによって作成されたことを示している。
【０１０６】
ＳＵＢＪＥＣＴ１５０５には、受信されたオリジナル更新通知メール１４１０に指定されていた文字列と同じ文字列を指定している。
【０１０７】
ＢＣＣアドレス１５０４には、何も指定する必要は無い。なおメール本文１５０６については、ユーザの任意のメッセージを記載して構わない。
【０１０８】
●受信者間メールの転送処理
本実施形態において、オリジナル更新通知メールを受信したユーザが、同じメールを受信した他のユーザと情報交換したい場合には、以上のような受信者間メールを作成し、電子メール送受信手段３０２を介して送信すれば良い。この様にして作成され送信されたメールは、宛先、即ちＴＯアドレスに送られる。上述したように、受信者間メールのＴＯアドレスはシステムメールアドレスである。したがって、この受信間メールはメール転送モジュール３０５によって受信され、再び通知対象ユーザ群に対して転送される。以下にその詳細を説明する。
【０１０９】
図１３は、メール転送モジュール３０５が、ユーザが送信した受信者間メールを他の受信者に対して転送する処理を示すフローチャートである。
【０１１０】
まずステップＳ１３０１において、メール転送モジュール３０５は、コンテンツ管理情報格納装置３０６内のシステム情報記憶部３０７に格納されているシステム情報を取得する。
【０１１１】
次にステップＳ１３０２においてメール転送モジュール３０５は、ステップＳ１３０１で取得したシステム情報に基づき、システムメールアドレス４０７宛てに送信されているメール情報を受信する。この処理は、ステップＳ１３０１で取得した受信メールサーバアドレス４０４、受信メールサーバアカウントＩＤ４０５、受信メールサーバパスワード４０６に基づき、該当するメールサーバ１０３（Ｘ）のメール受信モジュール３１２にアクセスして行われる。
【０１１２】
ここで受信されるメール、即ち、宛先としてシステムメールアドレスが指定されるメールは、図１２のフローチャートにおいて更新通知モジュール３０４が送信したオリジナル更新通知メールと、そのメールを受信したユーザが作成した受信者間メールである。オリジナル更新通知メールを受信した場合、その受信したメールの内容は、通知対象ユーザ群に含まれるユーザが受信したものと同じ内容となる。受信者間メールを受信した場合は、その内容は受信者間メールそのものと同じである。
【０１１３】
なお、ステップＳ１３０２で受信されるメールとしては、上述したオリジナル更新通知メールと受信者間メールのほかに、その他の目的で宛先にシステムメールアドレスが指定されたメールも含まれる。
【０１１４】
以上のようにメール転送モジュール３０５がメール情報を受信すると、次にステップＳ１３０３において、メール転送モジュール３０５は、該受信したメール情報の数を確認する。すなわち、受信したメールが１件も無い、もしくは受信したすべてのメールに対してステップＳ１３０３以降の処理を実施したのであれば、再びステップＳ１３０２に戻って受信処理を行なう。一方、メール情報が残っているのであれば、処理はステップＳ１３０４に進む。
【０１１５】
ステップＳ１３０４において、メール転送モジュール３０５は、受信したメールのＦＲＯＭアドレスとＳＵＢＪＥＣＴに指定されている値を取得する。
【０１１６】
次にステップＳ１３０５において、メール転送モジュール３０５は、図５に示したユーザ情報テーブル５００のメールアドレス５０３に、当該メールのＦＲＯＭアドレスに指定されたメールアドレスと一致するユーザ情報が存在するか否かを判定する。一致するユーザ情報が無い場合は、コンテンツ管理モジュール３０３で管理していないユーザから送信されてきたメールであるので、メール情報を破棄してステップＳ１３０３に戻り、次のメールの処理を行なう。一方、一致するユーザ情報が存在する場合には、次のステップＳ１３０６に進む。
【０１１７】
ここで、ステップＳ１３０５におけるＦＲＯＭアドレスの判定処理について、詳細に説明する。
【０１１８】
メール転送モジュール３０５は、ＦＲＯＭアドレスがシステムメールアドレス４０７と等しくなく、また、ユーザ情報テーブル５００のメールアドレス５０３に一致するものも存在しなかった場合に、そのメールを破棄してステップＳ１３０３に戻る。この場合、そのメールは、受信されたオリジナル更新通知メール１４１０でも、受信者間メール１５００でもない、第三者からたまたま送られてきたメールということになる。
【０１１９】
例えば、処理対象のメールが図１４に示す受信されたオリジナル更新通知メール１４１０であれば、ＦＲＯＭアドレス１４１１は、システム情報記憶部３０７に格納されているシステムメールアドレス４０７である。この場合、ユーザ情報テーブル５００のメールアドレス５０３に一致するものが存在するはずは無いので、一致するユーザがいないこととなり、そのメールは破棄されてステップＳ１３０３に戻り、次のメールの処理を行なう。これは即ち、メール転送モジュール３０５がオリジナル更新通知メールを受信しても、それを他に転送することは無いことを意味している。
【０１２０】
また、例えば処理対象のメールが図１５に示す受信者間メール１５００であれば、ＦＲＯＭアドレスはオリジナル更新通知メール１４００を送信した際にＢＣＣに指定したメールアドレスの一つである。したがって、ユーザ情報テーブル５００のメールアドレス５０３に一致するものが存在するはずであり、次のステップＳ１３０６に進む事となる。
【０１２１】
また、実際には受信者間メールではなくても、ＴＯアドレスにシステムメールアドレスが指定され、ＦＲＯＭにはユーザ情報テーブル５００に登録されているユーザのメールアドレスが偶然使用されているメールも存在する。このようなメールについても受信者間メールと同様に、次のステップＳ１３０６に進むこととなる。
【０１２２】
ステップＳ１３０６でメール転送モジュール３０５は、図９の更新通知情報テーブル９００を検索し、更新通知キーワード９０４に、ステップＳ１３０４で取得したメールのＳＵＢＪＥＣＴに指定された文字列と一致するデータが存在するか否かを判定する。一致するデータがない場合は、メール情報を破棄してステップＳ１３０３に戻り、次のメールの処理を行なうが、一致する更新通知情報が存在する場合には、その更新通知情報を取得して次のステップＳ１３０７に進む。このステップＳ１３０７に進めた処理対象のメールとはすなわち、ユーザ情報テーブル５００に登録されているユーザからの送信であって、更新通知情報テーブル９００に登録されているコンテンツに関する受信者間メールである。
【０１２３】
例えば、処理対象のメールが、ステップＳ１３０５を通過した図１５に示す受信者間メール１５００であるとすると、ＳＵＢＪＥＣＴ１５０５には“ＫＥＹ＿Ｘ００１”が指定されている。このＳＵＢＪＥＣＴ１５０５に合致する更新通知情報テーブル９００のデータは、図１０のデータ行１０００（１）に示されるコンテンツＩＤ＝“Ｘ００１”のデータ行である。受信者間メール１５００は、コンテンツＩＤ＝“Ｘ００１”のオリジナル更新通知メール１４００を受信したユーザから送信されたメールである。したがって、更新通知モジュール３０４が作成したオリジナル更新通知メール１４００と、転送モジュール３０５によって処理されている受信者間メール１５００は、同じコンテンツに対するメールとして処理されていることが分かる。
【０１２４】
また例えば、処理対象のメールが、実際には受信者間メールではないが、ＴＯアドレスにシステムメールアドレスが、ＦＲＯＭにユーザ情報テーブル５００に登録されているユーザのメールアドレスが指定されたメールである場合について考える。この場合、ＳＵＢＪＥＣＴに指定された文字列が更新通知情報テーブル９００の更新通知キーワード９０４と一致しないケースが殆どであると考えられる。偶然に一致する確率も可能性としては考えられるが、更新通知キーワード９０４の文字数の下限を大きくし、できるだけ長いキーワードを使用する事で、そのような偶然の一致の発生は防ぐことが可能である。したがって、このようなメールは破棄され、受信者間メールだけがステップＳ１３０７に進むことがになる。
【０１２５】
ステップＳ１３０７において、メール転送モジュール３０５は、ステップＳ１３０６で取得された更新通知情報の更新通知対象設定９０２を参照し、指定されたコンテンツが更新通知処理対象として指定されているか否かを確認する。ここで“通知しない”が指定されている場合はメール情報を破棄してステップＳ１３０３に戻り、次のメールの処理を行なう。一方、“通知する”が指定されている場合は、次のステップ１３０８に進む。尚、ここで“通知しない”が指定されているということは、当該コンテンツのオリジナル更新通知メール１４００が更新通知モジュール３０４によって送信された後に、そのコンテンツの更新通知情報の設定が変更され、通知対象ではなくなったことを意味する。
【０１２６】
すなわち、このステップＳ１３０７における通知対象か否かの判定処理によって、図１１で説明した通知情報設定処理によってコンテンツの更新通知情報テーブル９００が変更され、当該コンテンツが更新通知対象ではなくなった場合にも対応することができる。このような場合にはすなわち、当該コンテンツに対して何らかの操作が行なわれてもオリジナル更新通知メールは送信されないことはもちろん、送信されたオリジナル更新通知メールに対する受信者間メールについても転送されなくなる。
【０１２７】
次にステップＳ１３０８において、メール転送モジュール３０５は、ステップＳ１３０６で取得した更新通知情報のコンテンツＩＤ９０１と、更新通知対象ユーザ権限９０３に基づき、コンテンツ権限情報テーブル７０３を検索する。これにより、当該コンテンツに対して更新通知対象ユーザ権限９０３に指定されている権限を有するユーザＩＤの一覧を取得する。このユーザＩＤの一覧がすなわち、通知対象ユーザ群である。
【０１２８】
例えば、処理対象のメールが図１５で示す受信者間メール１５００であった場合、それがコンテンツＩＤ＝“Ｘ００１”に関するメールとして処理されていることは、ステップＳ１３０６において説明したとおりである。したがって、図１０に示す更新通知情報テーブル９００と、図８に示すコンテンツ権限情報テーブル７０３より、通知対象ユーザ群が決定される。すなわち、図１０のデータ行１０００（１）と、図８のデータ行８０１（１），８０１（２），８０１（３）より、通知対象ユーザ群が“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”であることが分かる。これは、オリジナル更新通知メールの送信処理を示す図１２のステップＳ１２０４における具体例として、コンテンツＩＤ＝“Ｘ００１”の通知対象ユーザ群が“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”となることを説明した内容と一致する。このように、更新通知モジュール３０４によって送信されたオリジナル更新通知メールと、それに対応する受信者間メールを元にメール転送モジュール３０５が処理する転送通知メールについて、その通知対象ユーザ群は一致している。また、受信者間メールを受信するまでの間に、通知対象ユーザ群が変更されてしまった場合にも、常に最新の情報が反映された状態で通知対象ユーザ群を抽出することが可能である。なお、通知対象ユーザ群の変更は、更新通知情報テーブル９００の設定内容や、図５のユーザ情報テーブル５００及び図７のコンテンツ権限情報テーブル７０３の値が変更されることによって生じる。
【０１２９】
以上のようにステップＳ１３０８で通知対象ユーザ群が決定されると、次にステップＳ１３０９において、メール転送モジュール３０５は、ステップＳ１３０８で取得された通知対象ユーザ群のユーザＩＤの一覧を用いてユーザ情報テーブル５００を検索する。そして、対応するデータ行のメールアドレス５０３を取得する。
【０１３０】
そしてステップＳ１３１０において、メール転送モジュール３０５は、ステップＳ１３０２で受信し、現在処理対象としている受信メール（受信者間メール１５００）に基づいて、「転送通知メール」情報を作成する。このとき、ステップＳ１３０１で取得したシステム情報と、ステップＳ１３０６で特定した更新通知キーワードと、ステップＳ１３０９で取得した通知対象ユーザ群に対応するメールアドレスの一覧が用いられる。ここで「転送通知メール」とは、或る更新通知メールの受信者であるユーザから発信された受信者間メールを、メール転送モジュール３０５がその他の受信者に対して転送する際のメールを指す。
【０１３１】
ここで、メール転送モジュール３０５による転送通知メールの作成方法について、詳細に説明する。
【０１３２】
まず、ＦＲＯＭアドレス、ＲＥＰＬＹ−ＴＯアドレス、ＴＯアドレスには、システム情報記憶部３０７のシステムメールアドレス４０７に格納されているメールアドレスを指定する。ＢＣＣアドレスには、ステップＳ１３０９で取得した通知対象ユーザ群に対応するメールアドレスの一覧を指定する。ＳＵＢＪＥＣＴには、ステップＳ１３０６で特定した更新通知キーワードを指定する。メールの本文には、現在処理対象としている受信メール（受信者間メール）のメール本文を指定する。
【０１３３】
図１５に示す転送通知メール１５１０は、受信者間メール１５００を受信したメール転送モジュール３０５が作成した転送通知メールの具体例を示したものである。受信者間メール１５００は、図８においてコンテンツＩＤ＝“Ｘ００１”で示されているコンテンツのオリジナル更新通知メール１４００に対応するものである。図１３のステップＳ１３０６において説明したように、オリジナル更新通知メール１４００と受信者間メール１５００は、同じコンテンツに対するメールとして処理されている。したがって、転送通知メール１５１０もコンテンツＩＤ＝“Ｘ００１”で示されているコンテンツの転送通知メールの例であることが分かる。
【０１３４】
転送通知メール１５１０のＦＲＯＭドレス１５１１、ＲＥＰＬＹ−ＴＯアドレス１５１２、ＴＯアドレス１５１３には、システムメールアドレス４０７に格納されている“server@contx.co.jp”が指定されている。
【０１３５】
転送通知メール１５１０のＢＣＣアドレス１５１４には、ステップＳ１３０９で取得した通知対象ユーザ群のメールアドレスが指定されている。転送通知メール１５１０は、コンテンツＩＤ＝“Ｘ００１”に該当するコンテンツの受信者間メールに対する転送通知メールであるので、コンテンツＩＤ＝“Ｘ００１”の通知対象ユーザ群として指定されているユーザのメールアドレスが指定されている。すなわち、“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”のメールアドレス“user_a@aaa.co.jp”，“user_b@bbb.co.jp”，“user_c@ccc.co.jp”が指定されている。図１３のステップＳ１３０８の説明において、更新通知モジュール３０４によって処理されるオリジナル更新通知メールと、それに対応してメール転送モジュール３０５が作成する転送通知メールとで、通知対象ユーザ群が一致することを説明した。図１５に示す転送通知メール１５１０においても、ＢＣＣアドレス１５１４に指定されているアドレスは、図１４のオリジナル更新通知メール１４００のＢＣＣアドレス１４０４と等しい。
【０１３６】
転送通知メール１５１０のＳＵＢＪＥＣＴ１５１５には、コンテンツ＝“Ｘ００１”に対応する更新通知キーワード＝“ＫＥＹ＿Ｘ００１”が指定されている。図１３のステップＳ１３０６において、オリジナル更新通知メール１４００と受信者間メール１５００が同一コンテンツに対するメールとして処理されている旨を説明した。よって、ＳＵＢＪＥＣＴ１５１５に指定される更新通知キーワードは、対応するオリジナル更新通知メール１４００のＳＵＢＪＥＣＴ１４０５に指定されている文字列と等しい。
【０１３７】
転送通知メール１５１０のメール本文１５１６には、現在処理対象としている受信メール、すなわち受信者間メール１５００のメール本文１５０６と同じ内容を指定する。
【０１３８】
以上のようにステップＳ１３１０で転送通知メール情報が作成されると、次にステップＳ１３１１においてメール転送モジュール３０５は、ステップＳ１３０１で取得したシステム情報に基づき、この転送通知メール情報を送信する。この送信処理は、システム情報の送信メールサーバアドレス４０１、送信メールサーバアカウントＩＤ４０２、送信メールサーバパスワード４０３等をもとに、メールサーバ１０３（Ｘ）のメール送信モジュール３１１にアクセスして実行される。
【０１３９】
以上説明したように図１３に示す転送処理によれば、本実施形態においてオリジナル更新通知メールの受信者より発信された受信者間メールは、オリジナル更新通知メールと同じ通知対象ユーザ群に対して送信される。
【０１４０】
以下、クライアントコンピュータ（Ｘ）において受信された転送通知メールについて、詳細に説明する。受信者間メール１５００が図１３に示す転送処理によって転送通知メール１５１０として送信されると、受信者であるユーザがクライアントコンピュータ１０１（Ｘ）の電子メール送受信手段３０２が、これを受信する。図１５における受信された転送通知メール１５２０は、このように受信された転送通知メールの具体例を示すものである。
【０１４１】
受信された転送通知メール１５２０におけるアドレス設定は、転送通知メール１５１０に対して、上述した図１４のオリジナル更新通知メール１４００と、受信されたオリジナル更新通知メール１４１０とを対比させた場合と同様である。すなわち、転送通知メール１５１０に対して、ＦＲＯＭアドレス、ＲＥＰＬＹ−ＴＯアドレス、ＴＯアドレス、ＳＵＢＪＥＣＴ、メール本文は同じであるが、ＢＣＣアドレスだけが異なっている。転送通知メール１５１０においては、ＢＣＣアドレス１５１４に通知対象ユーザ群のアドレスが指定されていたが、それを受信したユーザのメール（すなわち、受信された転送通知メール１５２０）では、ＢＣＣアドレス１５２４には何も指定されていない。
【０１４２】
また、受信された転送通知メール１５２０のメール本文１５２６は、そのメールを発信した発信者が作成した受信者間メール１５００のメール本文１５０６と同じである。これにより、オリジナル更新通知メールを受け取ったユーザが他の受信者に対して発信するために記述した受信者間メールの内容が、正しく他の受信者に伝わることになる。
【０１４３】
また、受信された転送通知メール１５２０のＢＣＣアドレス１５２４はクリアされているので、これを受信したユーザは、他の受信者のメールアドレスを認識できない。これにより、他の受信者のアドレスを露呈してしまうことなく、すなわち他の受信者のプライバシーを守りつつ、受信者間メールが適正な受信者に対して転送される。
【０１４４】
受信された転送通知メール１５２０における各アドレス（１５２１，１５２２，１５２３，１５２４）およびＳＵＢＪＥＣＴ１５２５に指定されているアドレスや更新通知キーワードは、受信されたオリジナル更新通知メール１４１０の指定内容と同様である。これにより、受信されたオリジナル更新通知メールから受信者間メールを作成したのと同様の手順により、受信された転送通知メール１５２０に基づいてユーザがメールを作成し、送信すれば、それがまた新たな受信者間メールとなることが分かる。すなわち、ユーザが受信された転送通知メールに基づいて受信者間メールを作成して送信すると、そのメールが再び図１３で示した転送処理を経て、転送通知メールとなって発信され、他の更新通知メール受信者に受信される。
【０１４５】
このようにメールが循環することによって、更新通知モジュール３０４がオリジナル更新通知メールを通知対象ユーザ群に送信して以降、通知対象ユーザ群の間で、互いのメールアドレスを知らないままにメールによる情報交換が可能になる。この通知対象ユーザ間におけるメールは、各ユーザが受信したメールに返信するという簡易な形式で作成できる。
【０１４６】
以上説明したように本実施形態によれば、コンテンツの更新時に更新通知対象ユーザに更新通知メールが送信され、メールを受信したユーザがそのメールに返信すれば、該コンテンツの全ての更新通知対象ユーザに対して、該返信メールが転送される。メールの受信後に、コンテンツの更新通知メール送信対象ユーザに変動が発生した場合にも、その変動が反映されて、変動後の送信対象ユーザに対してメールが転送される。なお、ユーザが受信する更新通知メールおよび転送された返信メールには、他の受信者のメールアドレスは記載されていない。
【０１４７】
したがって、コンテンツの更新等を該コンテンツに関連付けられたユーザにメールで通知する際に、他の通知対象ユーザのプライバシーに配慮しつつ、簡易な操作で、適切な通知対象者に受信者間メールを配信することができる。
【０１４８】
＜第２実施形態＞
以下、本発明に係る第２実施形態について説明する。第２実施形態におけるシステム構成は、多くの部分において上述した第１実施形態と同様の構成からなる。よって第２実施形態においては、上述した第１実施形態と同様の構成については詳細な説明を省略し、第１実施形態と同様である旨を記載するに留める。第２実施形態においては、コンテンツごとに更新通知アドレスを備え、該コンテンツの更新時に該更新通知アドレスに基づいて更新通知が行われることを特徴とする。
【０１４９】
●システム構成概要
第２実施形態におけるシステム構成は、上述した第１実施形態における図１と同様である。また、コンテンツ管理サーバ１０２およびメールサーバ１０３の具体的な構成も、第１実施形態における図２と同様である。また、クライアントコンピュータ１０１、コンテンツ管理サーバ１０２、メールサーバ１０３内で動作する処理モジュール群及び情報を格納する格納装置群、それらの制御および情報の流れについても、第１実施形態における図３と同様である。
【０１５０】
また、コンテンツ管理サーバ１０２において、コンテンツ管理情報格納装置３０６の各記憶部に格納される情報についても、第１実施形態における図４と同様である。ただし、第２実施形態では後述するように、各コンテンツ毎に更新通知アドレス、更新通知アドレスアカウントというメールアドレスとメールアカウントを使用して、メールの受信処理を行なう。そして、更新通知アドレスアカウントが使用する受信メールサーバも、図４に示す受信メールサーバアカウントＩＤ４０５、システムメールアドレス４０７と同様に、受信メールサーバアドレス４０４で特定されるメールサーバを使用する。なお第２実施形態においては、受信メールサーバアドレス４０４で指定されるメールサーバを使用せずに、更新通知アドレスアカウント用の別の受信用メールサーバを用意し、そのメールサーバアドレスを別途、システム情報記憶部３０７に保持しても良い。
【０１５１】
また、コンテンツ管理処理モジュール３０３を利用するユーザを管理するためのユーザ情報のフォーマットについても第１実施形態における図５と同様であり、さらにその具体例についても第１実施形態における図６と同様である。
【０１５２】
また、コンテンツ情報記憶部３０９に格納されたコンテンツ及びアクセス権限情報のフォーマットについても第１実施形態における図７と同様であり、さらにその具体例も第１実施形態における図８と同様である。
【０１５３】
●更新通知情報
図１６は、第２実施形態において、コンテンツ管理サーバ１０２の更新通知情報記憶部３１０に格納され、更新通知モジュール３０４によって実施される更新通知処理の設定を管理するための情報のフォーマットを表す図である。図１６に示す更新通知情報テーブル１６００において、コンテンツＩＤ１６０１、更新通知対象設定１６０２、更新通知対象ユーザ権限１６０３は、第１実施形態で図９に示した更新通知情報テーブルにおける各項目（９０１、９０２、９０３）と同様である。そして第２実施形態の更新通知情報テーブル１６００においては、第１実施形態における更新通知キーワード９０４に代えて、更新通知アドレス１６０４、更新通知アドレスアカウント１６０５、更新通知アドレスパスワード１６０６を備えることを特徴とする。
【０１５４】
更新通知アドレス１６０４は、更新通知メールにおいて使用するメールアドレスである。この更新通知アドレス１６０４は、図７に示すコンテンツ基本情報テーブル７００のコンテンツＩＤ７０１と同様に、コンテンツと１対１に対応する。したがって、更新通知アドレス１６０４によって、コンテンツ基本情報テーブル７００に管理されているコンテンツを一意に特定することができる。更新通知アドレスアカウント１６０５と更新通知アドレスパスワード１６０６は、更新通知アドレス１６０４のメールを受信する際に必要となる、受信用メールサーバのアカウントとパスワードである。
【０１５５】
図１７は、図１６に示した更新通知情報記憶部３１０に格納されている更新通知情報の具体例を示しており、図１７における表１７００が、更新通知情報テーブル１６００の具体例を示している。なお、図１７の表１７００において、上述した第１実施形態で図１０に示した表１０００と同様の項目（コンテンツＩＤ、更新通知対象設定、更新通知対象ユーザ権限）については、その詳細な説明を省略する。
【０１５６】
図１７におけるデータ行１７００（１）について、更新通知アドレス＝“mail_x001@contx.co.jp”は、コンテンツＩＤ＝“Ｘ００１”のコンテンツに対して使用可能なメールアドレスを示している。これはすなわち、更新通知アドレスが“mail_x001@contx.co.jp”であるコンテンツは、コンテンツＩＤ＝“Ｘ００１”以外に存在しないことを示している。また、データ行１７００（１）の更新通知アドレスアカウントと更新通知アドレスパスワードは、更新通知アドレス＝“mail_x001@contx.co.jp”を利用する上で必要となるメールサーバのアカウントとパスワードである。
【０１５７】
●コンテンツ更新通知情報の設定
図１８は、ユーザがコンテンツ管理モジュール３０３を用いて、或るコンテンツについての更新通知情報テーブル１７００の情報を指定する際の処理概要を示すフローチャートである。
【０１５８】
まずステップＳ１８０１において、ユーザはクライアントコンピュータ（Ｘ）のネットワーク閲覧手段３０１を使用して、コンテンツ管理サーバ１０２のコンテンツ管理モジュール３０３にアクセスする。そして、或るコンテンツを指定し、更新通知設定の処理の開始を指示する。コンテンツ管理モジュール３０３は、指定されたコンテンツのコンテンツＩＤを取得して更新通知情報テーブル１７００を検索し、そのコンテンツＩＤに対応するデータ行を取得し、その内容をユーザに提示する。するとユーザは、提示された内容を確認して、所望の更新通知条件情報を指定する。
【０１５９】
次にステップＳ１８０２において、コンテンツ管理モジュール３０３はユーザの指定内容を取得して、まず、当該コンテンツが更新通知の通知対象として指定されたか否かを確認する。「通知対象ではない」と指定された場合にはステップＳ１８０７に進み、「通知対象である」と指定された場合にはステップＳ１８０３へ進む。
【０１６０】
ステップＳ１８０７においてコンテンツ管理モジュール３０３は、システム情報記憶部３０７に格納されているシステム情報（図４参照）を取得する。そして、ステップＳ１８０１で取得した更新通知情報テーブルの更新通知アドレス１６０４を参照し、更新通知用のメールアドレスが設定されている場合には、これを無効化する。この無効化処理としては、まずシステム情報の受信メールサーバアドレス４０４、受信メールサーバアカウントＩＤ４０５、受信メールサーバパスワード４０６を使用して、該当するメールサーバ１０３（Ｘ）のメール受信モジュール３１２にアクセスする。そして、更新通知アドレスアカウント１６０５に指定されているメールアカウントの削除を実施する。この削除処理により、そのメールアドレスは宛先として使用できなくなる。メールアドレスの削除が実行されたら、更新通知アドレス１６０４の値をクリアし、更新通知情報テーブルのデータを保存して、図１８の処理を終了する。
【０１６１】
一方、ステップＳ１８０３では、ステップＳ１８０１で取得したデータ行の更新通知アドレス１６０４にメールアドレスが設定されているか否かを確認し、設定済みであればステップＳ１８０５へ進み、未設定であればステップＳ１８０４へ進む。
【０１６２】
ステップＳ１８０４において、コンテンツ管理モジュール３０３は、当該コンテンツに対する新たな更新通知アドレスアカウントと更新通知パスワード、更新通知アドレスの文字列を生成する。なお、大抵の場合、メールアドレスのアカウントはメールアドレスに含まれる"＠"より左側の文字列と同じであるので、第２実施形態においてもそれを前提として説明する。
【０１６３】
更新通知アドレスは、コンテンツと１対１で対応する一意なものでなければならない。よって、ユーザの任意に生成したメールアドレスが、システムにおいて既に使用されているか否か、すなわち登録済みであるか否かを調査する必要がある。この調査は、図１６の更新通知情報テーブル１６００における更新通知アドレス１６０４を検索することによってなされる。生成したメールアドレスが未登録であれば、これを新たな更新通知アドレスとして、更新通知情報テーブル１６００に登録する。このとき、そのアドレスの“＠”より左側の文字列を、更新通知アドレスアカウントとして、更新通知情報テーブル１６００に登録する。また、更新通知アドレスパスワードについては、任意の文字列を生成する。そしてコンテンツ管理モジュール３０３は、該当するメールサーバ１０３（Ｘ）のメール受信モジュール３１２に対し、新たな更新通知アドレスアカウント、更新通知アドレスパスワード、更新通知アドレスを新規登録する。この処理は、システム情報（図４）を取得して受信メールサーバアドレス４０４、受信メールサーバアカウントＩＤ４０５、受信メールサーバパスワード４０６に基づき、該当するメールサーバ１０３（Ｘ）のメール受信モジュール３１２にアクセスして行われる。
【０１６４】
登録が完了したら、当該コンテンツの更新通知情報テーブル１６００における更新通知アドレス１６０４、更新通知アドレスアカウント１６０５、更新通知アドレスパスワード１６０４にそれぞれの値を設定してデータを保存し、ステップＳ１８０５へ進む。
【０１６５】
ステップＳ１８０５において、コンテンツ管理モジュール３０３は、更新通知アドレス、更新通知アドレスアカウント、更新通知アドレスパスワードの情報を、当該コンテンツに対応する更新通知情報テーブル１６００のデータ行に保存する。このとき、ユーザが指定した更新通知対象ユーザ権限の情報も同時に保存される。
【０１６６】
以上で、図１８に示された、或るコンテンツについての更新通知情報テーブル１６００の設定処理は終了する。図１７に示した具体例はこの処理結果の具体例でもある。
【０１６７】
●オリジナル更新通知メールの送信処理
以上のように、更新通知メールを発信する対象となるコンテンツの条件設定が完了すると、次に、この条件設定に従って実際に更新通知が発信される。以下、第２実施形態におけるコンテンツ更新に伴う更新通知メールの送信処理について説明する。
【０１６８】
図１９は、ユーザがコンテンツ管理モジュール３０３を用いて、或るコンテンツについて更新などの操作を行なった後に発生する更新通知メールの送信処理の概要を示すフローチャートである。
【０１６９】
図１９のステップＳ１９０１において、ユーザがクライアントコンピュータ（Ｘ）のネットワーク閲覧手段３０１を用いてコンテンツ管理サーバ１０２のコンテンツ管理モジュール３０３にアクセスし、或るコンテンツに対して更新等の操作を行う。するとコンテンツ管理モジュール３０３は、更新通知処理モジュール３０４に対して更新の操作対象となったコンテンツのコンテンツＩＤを通知する。
【０１７０】
次にステップＳ１９０２において、通知を受けた更新通知モジュール３０４は、更新されたコンテンツのＩＤに基づいて図１６に示す更新通知情報テーブル１６００を検索する。そして、該当する更新通知情報データ行を取り出し、更新通知対象設定１６０２に指定されている値を確認する。例えば、図１７に示す例によれば、当該コンテンツのコンテンツＩＤが“Ｘ００１”である場合には、更新通知対象設定１６０２の値は“通知する”である（データ行１７００（１）参照）。またコンテンツＩＤが“Ｘ００３”である場合には、更新通知対象設定１７０２の値は“通知しない”である（データ行１７００（３）参照）。
【０１７１】
そしてステップＳ１９０３において、更新通知モジュール３０４はステップＳ１９０２において確認された更新通知対象設定１６０２の値が“通知しない”であった場合には、これ以上処理を続行する必要が無いと判断して処理を終了する。一方、更新通知対象設定１６０２の値が「通知する」であった場合には、ステップＳ１９０４へ進む。
【０１７２】
ステップＳ１９０４において、ステップＳ１９０２で取得した当該コンテンツの更新通知情報テーブル１６００のコンテンツＩＤ１６０１と、更新通知対象ユーザ権限１６０３に指定されている値とに基づいて、コンテンツ権限情報テーブル７０３が検索される。そして、当該コンテンツに対して更新通知対象ユーザ権限１６０３に指定されている権限を有するユーザＩＤの一覧を取得する。このユーザＩＤの一覧はすなわち、当該コンテンツに対して更新操作が行われた際に更新通知メールを送信する対象となるユーザのＩＤの一覧である。以降、この通知対象のユーザ群を「通知対象ユーザ群」と称する。
【０１７３】
ここで、ステップＳ１９０４における通知対象ユーザ群の決定処理について、具体例を挙げてさらに詳細に説明する。
【０１７４】
図１７のデータ行１７００（１）に示される、コンテンツＩＤが“Ｘ００１”であるデータを例とすると、更新通知対象ユーザ権限１６０３の値は“参照、更新、削除”である。よって、コンテンツＩＤ＝“Ｘ００１”であるコンテンツに対して、参照、又は更新、又は削除の権限を有しているユーザが、通知対象ユーザ群に追加される。図８の例において、当該コンテンツに対してそのような権限を有しているユーザは、“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”である。（図８のデータ行８０１（１），８０１（２），８０１（３）参照）。したがって、これらのユーザがコンテンツＩＤ＝“Ｘ００１”のコンテンツの通知対象ユーザ群となる。
【０１７５】
また、図１７のデータ行１７００（２）に示される、コンテンツＩＤが“Ｘ００２”であるデータを例とすると、更新通知対象ユーザ権限１６０３の値は“参照、更新”である。よって、コンテンツＩＤ＝“Ｘ００２”であるコンテンツに対して、参照、又は更新の権限を有しているユーザが、通知対象ユーザ群に追加される。図８の例において、当該コンテンツに対してそのような権限を有しているユーザは、“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”である。（図８のデータ行８０１（４），８０２（５）参照）。したがって、これらのユーザがンテンツＩＤ＝“Ｘ００２”のコンテンツの通知対象ユーザ群となる。
【０１７６】
以上のようにステップＳ１９０４で通知対象ユーザ群が決定されると、次にステップＳ１９０５において更新通知モジュール３０４は、該通知対象ユーザ群に該当するユーザＩＤの一覧を用いてユーザ情報テーブル５００を検索する。そして、対応するデータ行のメールアドレス５０３を取得する。ここで、図８及び図１７を例にとれば、コンテンツＩＤ＝“Ｘ００１”のコンテンツの通知対象ユーザ群は“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”である。したがって、図６に示すユーザ情報によれば、対応するメールアドレスはそれぞれ、“user_a@aaa.co.jp”，“user_b@bbb.co.jp”，“user_c@ccc.co.jp”である。（図６のデータ行６００（１）、６００（２）、６００（３）参照）。
【０１７７】
次にステップＳ１９０６において、更新通知モジュール３０４は、ステップ１９０２で取得した当該コンテンツの更新通知情報テーブル１６００のデータ行における、更新通知アドレス１６０４の値を取得する。図１７を例にとれば、当該コンテンツのコンテンツＩＤが“Ｘ００１”である場合、更新通知アドレス１６０４の値は“mail_x001@contx.co.jp”である（図１７のデータ行１７００（１）参照）。
【０１７８】
次にステップＳ１９０７において、更新通知モジュール３０４は、システム情報記憶部３０７に格納されているシステム情報（図４参照）を取得する。
【０１７９】
次にステップＳ１９０８において、更新通知モジュール３０４は、更新通知メールとして送信するオリジナル更新通知メールを作成する。
【０１８０】
ここで、オリジナル更新通知メールの作成方法について説明する。
【０１８１】
まず、ＦＲＯＭアドレスとＲＥＰＬＹ−ＴＯアドレスに対し、ステップＳ１９０６で取得した現在処理対象としているコンテンツの更新通知アドレスを指定する。このように、ＦＲＯＭアドレスやＲＥＰＬＹ−ＴＯアドレスに更新通知アドレスを指定するのは、後にオリジナル更新通知メールを受信したユーザが、容易に受信者間メールを作成できるようにするためである。すなわち、このオリジナル更新通知メールに対する「返信」として受信者間メールを作成すれば、更新通知アドレスが受信者間メールのＴＯアドレスに指定されるため、受信者間メールの作成が容易となる。また、ＴＯアドレスに対しては、ステップＳ１９０７で取得したステム情報記憶部３０７に格納されているシステム情報（図４参照）に格納されているシステムメールアドレス４０７を指定する。またＢＣＣアドレスに対しては、ステップＳ１９０５で取得した通知対象ユーザ群のメールアドレス一覧を指定する。なお、ＳＵＢＪＥＣＴとメールの本文については特に規定はない。
【０１８２】
ここで、ステップＳ１２０８において作成されるオリジナル更新通知メールの具体例を図２１に示し、詳細に説明する。図２１に示すオリジナル更新通知メール２１００は、図４、図６、図８、図１７で示された具体例に基づき、コンテンツＩＤ＝“Ｘ００１”のコンテンツのオリジナル更新通知メールの具体例である。
【０１８３】
ＦＲＯＭドレス２１０１、ＲＥＰＬＹ−ＴＯアドレス２１０２には、ステップＳ１９０６で取得した、当該コンテンツの更新通知アドレス１６０４＝“mail_x001@contx.co.jp”が指定されている。ＴＯアドレス２１０３には、ステップＳ１９０７で取得したシステム情報記憶部３０７に格納されているシステム情報のシステムメールアドレス４０７＝“server@contx.co.jp”（図４参照）が指定されている。ＢＣＣアドレス２１０４には、ステップＳ１９０５で取得したコンテンツＩＤ＝“Ｘ００１”の通知対象ユーザ群における各ユーザのメールアドレスが指定されている。ＳＵＢＪＥＣＴ２１０５やメール本文２１０６には、通知するメールの件名や通知内容を記載するが、上述したようにその内容自体は限定されないため、その決定方法等についての説明を割愛する。
【０１８４】
なお、図２１のオリジナル更新通知メール２１００では、ＢＣＣアドレス２１０４に通知対象ユーザ群のメールアドレスをすべて指定する例を示したが、これを或る人数ごとに分けて複数のオリジナル更新通知メールを作成しても良い。
【０１８５】
以上のようにステップＳ１９０８でオリジナル更新通知メールが作成されると、次にステップＳ１９０９において、更新通知モジュール３０４は、このオリジナル更新通知メールの送信処理を実行する。この送信処理は、ステップＳ１９０７で取得した送信メールサーバアドレス４０１、送信メールサーバアカウントＩＤ４０２、送信メールサーバパスワード４０３等をもとに、メールサーバ１０３（Ｘ）のメール送信モジュール３１１にアクセスして行われる。
【０１８６】
以上の様に、図１９のフローチャートに示す処理によって、コンテンツに対して更新等の操作を行なった後に発生する更新通知メールが送信される。
【０１８７】
●受信されたオリジナル更新通知メール
更新通知モジュール３０４から発信されるオリジナル更新通知メールの送信先は、通知対象ユーザ群に指定されたユーザのメールアドレスと、システム情報記憶部３０７に格納されているシステム情報の送信メールサーバアドレス４０１に対応する。通知対象ユーザ群のアドレスに送られたオリジナル更新通知メールは、各ユーザによって、クライアントコンピュータ１０１（Ｘ）の電子メール送受信手段３０２を介して受信される。
【０１８８】
ユーザが受信したメールは、ＦＲＯＭアドレス、ＲＥＰＬＹ−ＴＯアドレス、ＴＯアドレス、ＳＵＢＪＥＣＴ、メールの本文の内容については、更新通知モジュール３０４が作成した内容と等しくなる。しかし、ＢＣＣアドレスを使用している場合、各ユーザが受信したメールのＢＣＣアドレスには、アドレスが記載されていない状態となる。
【０１８９】
図２１の受信されたオリジナル更新通知メール２１１０は、更新通知モジュール３０４が送信したオリジナル更新通知メール２１００を、各ユーザがクライアントコンピュータ１０１（Ｘ）の電子メール送受信手段３０２で受信した際のメール情報を示している。
【０１９０】
受信されたオリジナル更新通知メール２１１０のＦＲＯＭアドレス２１１１、ＲＥＰＬＹ―ＴＯアドレス２１１２、ＴＯアドレス２１１３、ＳＵＢＪＥＣＴ２１１５、メール本文２１１６はそれぞれ、オリジナル更新通知メール２１００の指定内容と同様である。しかし、ＢＣＣアドレス２１１４については、アドレスが記載されていない状態となる。すなわち、オリジナル更新通知メール２１００ではＢＣＣに通知対象ユーザ群の各メールアドレスが指定されているが、それを受信した各ユーザには、他にどのようなユーザが更新通知メールを受信しているかがメールからは判別できない状態となる。このように本実施形態では、他の受信者のアドレスを露呈してしまうことなく、すなわち受信者のプライバシーを守りつつ、通知の必要な受信者に対して通知メールを送付することができる。
【０１９１】
●受信者間メール
以下、第２実施形態における、更新通知メールを受信した受信者間において通信される受信者間メールについて説明する。
【０１９２】
ユーザが受信者間メールを作成する上で遵守すべき規定は、ＴＯアドレス、ＦＲＯＭアドレスに対する指定内容であり、その内容を以下に説明する。
【０１９３】
すなわち、受信者間メールのＴＯアドレスには、受信されたオリジナル更新通知メールに記載されているＲＥＰＬＹ−ＴＯアドレス、もしくはＦＲＯＭアドレスの内容を指定する。なお、受信されたオリジナル更新通知メールに記載されているＲＥＰＬＹ−ＴＯアドレスおよびＦＲＯＭアドレスには、常に同じアドレスが指定されているため、実質的にどちらを使用しても構わない。なお、一般的な電子メール作成アプリケーションを使用して返信メールを作成する場合には、受信したメールのＲＥＰＬＹ−ＴＯアドレスもしくはＦＲＯＭアドレスに指定されているアドレスを、受信者間メールのＴＯアドレスに設定するのが一般的である。
【０１９４】
受信間メールのＦＲＯＭアドレスには、ユーザが、受信されたオリジナル更新通知メールを受け取ったアドレスを指定する。即ち、元のオリジナル更新通知メールにおいて、ＢＣＣアドレスに指定されていた中の、そのユーザに該当する１つのアドレスを指定する。上述したように、ユーザ自身が受信したオリジナル更新通知メールにはＢＣＣアドレスが記載されていないが、そもそもそのメールの受信はできているため、ユーザはＢＣＣアドレスに指定されていた自分自身のアドレスは認識しているものと考えられる。
【０１９５】
以上が、ユーザが受信者間メールを作成する上で注意すべき規定である。なお、受信間メールのＲＥＰＬＹ−ＴＯアドレス、ＢＣＣアドレス、ＳＵＢＪＥＣＴ、メールの本文については特に規定されないため、ユーザの任意に扱って構わない。
【０１９６】
図２２は、受信者間メールの具体例を示す図である。図２２の受信者間メール２２００は、オリジナル更新通知メール２１００を受け取ったユーザが、上述したような規定に従って、同じ更新通知メールを受け取っている他のユーザに対してメールを発信する際に作成した受信者間メールの例を示す。
【０１９７】
図２２のＦＲＯＭアドレス２２０１、ＲＥＰＬＹ−ＴＯアドレス２２０２には、この受信者間メール２２００を作成したユーザ自身のメールアドレスが指定される。ユーザは先にこのアドレスをＢＣＣアドレスに指定して送られたオリジナル更新通知メール２１００を受信しているので、このアドレスをユーザ自身が認識している、もしくは電子メール送受信手段３０２において情報として管理されていることは明らかである。
【０１９８】
ＴＯアドレス２２０３には、受信されたオリジナル更新通知メール２１１０のＲＥＰＬＹ−ＴＯアドレス２１１２に指定されているアドレスが指定されている。図１９のステップＳ１９０８において、更新通知モジュール３０４は、ＲＥＰＬＹ−ＴＯアドレス２１１２に対し、処理対象であるコンテンツに対して用意されたメールアドレス、即ち図１６のコンテンツの更新通知アドレス１６０４の内容を指定している。具体的には、受信されたオリジナル更新通知メール２１１０のＲＥＰＬＹ−ＴＯアドレス２１１２には“mail_x001@contx.co.jp”というアドレスが指定されている。これを受信者間メール２２００のＴＯアドレス２２０３として使用することになる。このアドレスはすなわち、図１７のデータ行１７００（１）が示すように、コンテンツＩＤ＝“Ｘ００１”のコンテンツに対応する更新通知アドレスを示す。
【０１９９】
また、ＢＣＣアドレス２２０４には何も指定する必要は無い。ＳＵＢＪＥＣＴ２２０５およびメール本文２２０６については、ユーザの任意のメッセージを記載して構わない。
【０２００】
●受信者間メールの転送処理
第２実施形態において、オリジナル更新通知メールを受信したユーザが、同じメールを受信した他のユーザと情報交換したい場合には、以上のような受信者間メールを作成し、電子メール送受信手段３０２を介して送信すれば良い。この様にして作成され送信されたメールは、宛先、即ちＴＯアドレスに送られる。上述したように、受信者間メールのＴＯアドレスは、更新通知情報テーブル１６００でコンテンツ毎に管理されている更新通知アドレスである。したがって、この受信者間メールは、メール転送モジュール３０５によって受信され、再び通知対象ユーザ群に対して転送される。以下にその詳細を説明する。
【０２０１】
図２０は、メール転送モジュール３０５が、ユーザが送信した受信者間メールを他の受信者に対して転送する処理を示すフローチャートである。
【０２０２】
まずステップＳ２００１において、メール転送モジュール３０５は、コンテンツ管理情報格納装置３０６内のシステム情報記憶部３０７に格納されているシステム情報を取得する。
【０２０３】
次にステップＳ２００２において、メール転送モジュール３０５は、図１６の更新通知情報テーブル１６００に格納されたデータの中から、更新通知アドレス１６０４に更新通知アドレスが設定されているデータを順次読出す。そして、ステップＳ２００３以降の処理を順次実行する。更新通知情報テーブル１６００の１データ行には１つのコンテンツが対応している。したがって、更新通知情報テーブル１６００を順次読み出して処理を行なうということは、そのデータ行のコンテンツＩＤ１６０１に指定されているコンテンツの受信者間メールの転送処理を行なうことになる。
【０２０４】
そしてステップＳ２００３において、ステップＳ２００２で取得した更新通知アドレス１６０４宛てに送信されているメール情報を受信する。この処理は、更新通知アドレス１６０４の他、更新通知アドレスアカウント１６０５、更新通知アドレスパスワード１６０６、およびシステム情報の受信メールサーバアドレス４０４に基づき、該当するメールサーバ１０３（Ｘ）にアクセスして行われる。
【０２０５】
ここで受信されるメールには、図１９のフローチャートにおいてオリジナル更新通知メールを受信したユーザが作成した受信者間メールが含まれる。また、ステップＳ２００２で説明したようにコンテンツＩＤ毎の処理を行なっているため、ここで受信される受信者間メールも、ステップＳ２００２で定められた現在処理中のコンテンツＩＤに対応する更新通知アドレス宛てに送られたものである。
【０２０６】
以上のようにメール転送モジュール３０５がメール情報を受信すると、次にステップＳ２００４において、メール転送モジュール３０５は、ステップＳ２００３で受信したメール情報の数を確認する。すなわち、受信したメールが１件も無い、もしくは受信したすべてのメールに対してステップＳ２００５以降の処理を実施したのであれば、再びステップＳ２００２に戻って、次に読み出した更新通知情報テーブル１６００に対する処理を行なう。一方、メール情報が残っているのであれば、処理はステップＳ２００５に進む。
【０２０７】
ステップＳ２００５において、メール転送モジュール３０５は、受信したメールのＦＲＯＭアドレスに指定されている値を取得する。このＦＲＯＭアドレスとしては、受信者間メールを送信したユーザのアドレスが指定されているはずである。
【０２０８】
次にステップＳ２００６において、メール転送モジュール３０５は、図５に示したユーザ情報テーブル５００のメールアドレス５０３に、当該メールのＦＲＯＭアドレスに指定されたメールアドレスと一致するユーザ情報が存在するか否かを判定する。一致するユーザ情報が無い場合は、メール情報を破棄してステップＳ２００４に戻り、次のメールの処理を行なう。一方、一致するユーザ情報が存在する場合には、次のステップＳ２００７に進む。
【０２０９】
ここで、ステップＳ２００６におけるＦＲＯＭアドレスの判定処理について、詳細に説明する。
【０２１０】
例えば、処理対象のメールが図２２に示す受信者間メール２２００であれば、ＦＲＯＭアドレスはオリジナル更新通知メール２１００を送信した際にＢＣＣに指定したメールアドレスの一つである。したがって、ユーザ情報テーブル５００のメールアドレス５０３に一致するものが存在するはずである。
【０２１１】
受信したメールのＦＲＯＭアドレスと一致するアドレスが、ユーザ情報テーブル５００のメールアドレス５０３に存在しなかった場合には、そのメールは、コンテンツ管理モジュール３０３で管理していないユーザから送信されてきたメールである。もしくは、過去、すなわちオリジナル更新通知メールが送信された時点ではユーザとして登録されていたが、その後、今回受信されるまでの間に、ユーザ情報テーブル５００から削除されてしまったと考えられる。いずれにしても、この受信処理が行なわれる段階ではシステムのユーザとして認められていない人物から送られてきたメールとなるので、これが破棄されてしまったとしても何ら問題ない。
【０２１２】
ステップＳ２００７において、メール転送モジュール３０５は、ステップＳ２００２で順次読み出されている更新通知情報テーブル１６００の更新通知対象設定１６０２を参照し、指定されたコンテンツが更新通知処理対象として指定されているかを確認する。ここで“通知しない”が指定されている場合はメール情報を破棄してステップＳ２００４に戻り、次のメールの処理を行なう。一方、“通知する”が指定されている場合は、次のステップ２００８に進む。
【０２１３】
ここで、現在処理しているメールが正規のユーザから送られてきた受信者間メールであると仮定する。すると、更新通知対象設定１６０２として“通知しない”が指定されているため、当該コンテンツのオリジナル更新通知メール２１００が更新通知モジュール３０４によって送信された後に、そのコンテンツの更新通知情報の設定が変更されたことが分かる。すなわち、通知対象ではなくなったことを意味する。このように、以前は更新通知対象であったとしても、現時点では更新通知対象ではなくなってしまったメールについては、これをユーザに対して送ることは更新通知の条件設定に適合しない。よって、そのようなメールは破棄されるべきである。
【０２１４】
次にステップＳ２００８において、メール転送モジュール３０５は、ステップＳ２００２で順次読み出した更新通知情報テーブル１６００のコンテンツＩＤ１６０１と、更新通知対象ユーザ権限１６０３に基づき、コンテンツ権限情報テーブル７０３を検索する。これにより、当該コンテンツに対して更新通知対象ユーザ権限１９０３に指定されている権限を有するユーザＩＤの一覧を取得する。このユーザＩＤの一覧がすなわち、通知対象ユーザ群である。
【０２１５】
例えば、処理対象のメールが図２０で示したような受信者間メール２２００であると仮定する。すると、ステップＳ２００２で順次読み出した更新通知情報テーブル１６００のコンテンツＩＤ１６０１＝“Ｘ００１”である時に、更新通知アドレス１６０４は“mail_x001@contx.co.jp”である（図１７の１７００（１）参照）。よって、そのデータを処理している場合には、受信者間メール２２００に示されるように、ＴＯアドレスが“mail_x001@contx.co.jp”であるメールを受信することが可能である。このように、メール転送モジュール３０５は、コンテンツＩＤ＝“Ｘ００１”のメールとして、受信者間メール２２００がを処理している。したがって、図１７のデータ行１７００（１）と、図８のデータ行８０１（１），８０１（２），８０１（３）より、通知対象ユーザ群が“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”であることが分かる。これは、オリジナル更新通知メールの送信処理を示す図１９のステップＳ１９０４における具体例として、コンテンツＩＤ＝“Ｘ００１”の通知対象ユーザ群が“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，“ＵＳＥＲ＿Ｃ”となることを説明した内容と一致する。すなわち、更新通知モジュール３０４によって送信されたオリジナル更新通知メールと、それに対応する受信者間メールを元にメール転送モジュール３０５が処理する転送通知メールについて、その通知対象ユーザ群は一致している。また、受信者間メールを受信するまでの間に、通知対象ユーザ群が変更されてしまった場合にも、常に最新の情報が反映された状態で通知対象ユーザ群を抽出することが可能である。なお、通知対象ユーザ群の変更は、更新通知情報テーブル１６００の設定内容や、図５のユーザ情報テーブル５００及び図７のコンテンツ権限情報テーブル７０３の値が変更されることによって生じる。
【０２１６】
以上のようにステップＳ２００８で通知対象ユーザ群が決定されると、次にステップＳ２００９において、メール転送モジュール３０５は、ステップＳ２００８で取得された通知対象ユーザ群のユーザＩＤの一覧を用いてユーザ情報テーブル５００を検索する。そして、対応するデータ行のメールアドレス５０３を取得する。
【０２１７】
そしてステップＳ２０１０において、メール転送モジュール３０５は、ステップＳ２００３で受信し、現在処理対象としている受信メール（受信者間メール２２００）に基づいて「転送通知メール」情報を作成する。このとき、ステップＳ２００１で取得したシステム情報と、ステップＳ２００２で読み出したコンテンツに対応する更新通知情報テーブル１６００の情報と、ステップＳ２００９で取得した通知対象ユーザ群に対応するメールアドレスの一覧が用いられる。ここで「転送通知メール」とは、或る更新通知メールの受信者であるユーザから発信された受信者間メールを、メール転送モジュール３０５がその他の受信者に対して転送する際のメールを指す。
【０２１８】
ここで、メール転送モジュール３０５による転送通知メールの作成方法について、詳細に説明する。
【０２１９】
まず、ＦＲＯＭアドレス、ＲＥＰＬＹ−ＴＯアドレスには、現在処理中のコンテンツに対応する更新通知情報テーブル１６００における更新通知アドレス１６０４を指定する。ＴＯアドレスには、システム情報記憶部３０７のシステムメールアドレス４０７に格納されているメールアドレスを指定する。ＢＣＣアドレスには、ステップＳ２００９で取得した通知対象ユーザ群に対応するメールアドレスの一覧を指定する。ＳＵＢＪＥＣＴとメールの本文には、現在処理対象としている受信メール（受信者間メール）のＳＵＢＪＥＣＴとメール本文をそれぞれ指定する。
【０２２０】
図２２に示す転送通知メール２２１０は、受信者間メール２２００を受信したメール転送モジュール３０５が作成した転送通知メールの具体例を示したものである。
【０２２１】
メール転送モジュール３０５が受信者間メール２２００を受信して、処理しているということより、以下のことが分かる。すなわち、受信者間メール２２００のＴＯアドレス２２０３が“mail_x001@contx.co.jp”であるので、これは図１７のデータ行１７００（１）に対応していることが分かる。したがって、現在メール転送モジュール３０５はステップＳ２００２において、図１７のデータ行１７００（１）に示されるコンテンツＩＤ＝“Ｘ００１”のデータ処理をしているという事になる。
【０２２２】
転送通知メールのＦＲＯＭアドレス、ＲＥＰＬＹ−ＴＯアドレスには、現在処理を行なっているコンテンツの更新通知アドレス１６０４が使用される。したがって、転送通知メール２２１０のＦＲＯＭアドレス２２１１、ＲＥＰＬＹ−ＴＯアドレス２２１２には、データ行１７００（１）の更新通知アドレス＝“mail_x001@contx.co.jp"が指定される。またＴＯアドレスには、システム情報記憶部３０７のシステムメールアドレス４０７に格納されているメールアドレスが指定されるため、ＴＯアドレス２２１３には図４のシステムメールアドレス４０７＝“server@contx.co.jp”が指定される。またＢＣＣアドレス２２１４には、ステップＳ２００９で取得した通知対象ユーザ群に対応するメールアドレスの一覧が指定される。ここで、受信者間メール２２００を処理した場合の通知対象ユーザ群が、図８のデータ行８０１（１），８０１（２），８０１（３）より、“ＵＳＥＲ＿Ａ”，“ＵＳＥＲ＿Ｂ”，ＵＳＥＲ＿Ｃ”になることは、ステップＳ２００８の説明で示した通りである。
すると、この通知対象ユーザ群に対応するメールアドレスは、図６のデータ行６００（１），６００（２），６００（３）によれば“user_a@aaa.co.jp”，“user_b@bbb.co.jp”，“user_c@ccc.co.jp”である。このアドレスがＢＣＣアドレス２２１４に指定される。また、ＳＵＢＪＥＣＴ２２１５とメールの本文２２１６には、現在処理対象としている受信メール、すなわち受信者間メール２２００のＳＵＢＪＥＣＴ２２０５とメール本文２２０６と同じ内容を指定する。
【０２２３】
以上のようにステップＳ２０１０で転送通知メール情報が作成されると、次にステップＳ２０１１においてメール転送モジュール３０５は、ステップＳ２００１で取得したシステム情報に基づき、この転送通知メール情報を送信する。この送信処理は、システム情報の送信メールサーバアドレス４０１、送信メールサーバアカウントＩＤ４０２、送信メールサーバパスワード４０３等をもとに、メールサーバ１０３（Ｘ）のメール送信モジュール３１１にアクセスして実行される。
【０２２４】
以上説明したように図２０に示す転送処理によれば、第２実施形態においてオリジナル更新通知メールの受信者より発信された受信者間メールは、オリジナル更新通知メールと同じ通知対象ユーザ群に対して送信される。
【０２２５】
以下、クライアントコンピュータ（Ｘ）において受信された転送通知メールについて、詳細に説明する。受信者間メール２２００が図２０に示す転送処理によって転送通知メール２２１０として送信されると、受信者であるユーザがクライアントコンピュータ１０１（Ｘ）の電子メール送受信手段３０２が、これを受信する。図２２における受信された転送通知メール２２２０は、このように受信された転送通知メールの具体例を示すものである。
【０２２６】
受信された転送通知メール２２２０のメール本文２２２６は、そのメールを発信した発信者が作成した受信者間メール２２００のメール本文２２５０６と同じである。これにより、オリジナル更新通知メールを受け取ったユーザが他の受信者に対して発信するために記述した受信者間メールの内容が、正しく他の受信者に伝わることになる。
【０２２７】
受信された転送通知メール２２２０における各アドレス（２２２１，２２２２，２２２３，２２２４）に指定されているアドレスは、受信されたオリジナル更新通知メール２１１０の指定内容と同様である。これにより、受信されたオリジナル更新通知メールから受信者間メールを作成したのと同様の手順により、受信された転送通知メール２２２０に基づいてユーザがメールを作成し、送信すれば、それがまた新たな受信者間メールとなることが分かる。すなわち、ユーザが受信された転送通知メールに基づいて受信者間メールを作成して送信すると、そのメールが再び図２０で示した転送処理を経て、転送通知メールとなって発信され、他の更新通知メール受信者に受信される。
【０２２８】
以上説明したように第２実施形態によれば、コンテンツに更新通知アドレスの情報を関連付けることによって、上述した第１実施形態と同様に、プライバシに配慮した受信者間メールを適切に配信することができる。
【０２２９】
＜他の実施形態＞
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記憶媒体(記録媒体)等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、クライアントコンピュータ、webアプリケーション等）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０２３０】
尚本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される。なお、この場合のプログラムとは、実施形態において図に示したフローチャートに対応したプログラムである。
【０２３１】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０２３２】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等の形態であっても良い。
【０２３３】
プログラムを供給するための記録媒体としては、以下に示す媒体がある。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、MO、CD-ROM、CD-R、CD-RW、磁気テープ、不揮発性のメモリカード、ROM、DVD(DVD-ROM，DVD-R)などである。
【０２３４】
プログラムの供給方法としては、以下に示す方法も可能である。すなわち、クライアントコンピュータのブラウザからインターネットのホームページに接続し、そこから本発明のコンピュータプログラムそのもの(又は圧縮され自動インストール機能を含むファイル)をハードディスク等の記録媒体にダウンロードする。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるWWWサーバも、本発明に含まれるものである。
【０２３５】
また、本発明のプログラムを暗号化してCD-ROM等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせることも可能である。すなわち該ユーザは、その鍵情報を使用することによって暗号化されたプログラムを実行し、コンピュータにインストールさせることができる。
【０２３６】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。さらに、そのプログラムの指示に基づき、コンピュータ上で稼動しているOSなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０２３７】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、実行されることによっても、前述した実施形態の機能が実現される。すなわち、該プログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行うことが可能である。
【図面の簡単な説明】
【０２３８】
【図１】本発明に係るコンテンツ管理システムの全体構成を示す図である。
【図２】本発明におけるコンテンツ管理サーバおよびメールサーバの構成例を示す図である。
【図３】本発明における処理モジュール群及び情報格納装置群を示す図である。
【図４】本発明におけるシステム情報記憶部のフォーマットおよびデータの具体例を示す図である。
【図５】本発明におけるユーザ情報記憶部のフォーマットを示す図である。
【図６】本発明におけるユーザ情報記憶部のデータの具体例を示す図である。
【図７】本発明におけるコンテンツ情報記憶部のフォーマットを示す図である。
【図８】本発明におけるコンテンツ情報記憶部のデータの具体例を示す図である。
【図９】本発明に係る一実施形態における更新通知情報記憶部のフォーマットを示す図である。
【図１０】本実施形態における更新通知情報記憶部のデータの具体例を示す図である。
【図１１】本実施形態における更新通知情報記憶部への情報設定処理を示すフローチャートである。
【図１２】本実施形態におけるオリジナル更新通知メール送信処理を示すフローチャートである。
【図１３】本実施形態における受信者間メール転送処理を示すフローチャートである。
【図１４】本実施形態におけるオリジナル更新通知メールと受信されたオリジナル更新通知メールの具体例を示す図である。
【図１５】本実施形態における受信者間メール、転送通知メール、受信された転送通知メールの具体例を示す図である。
【図１６】本発明に係る第２実施形態における更新通知情報記憶部のフォーマットを示す図である。
【図１７】第２実施形態における更新通知情報記憶部のデータの具体例を示す図である。
【図１８】第２実施形態における更新通知情報記憶部への情報設定処理を示すフローチャートである。
【図１９】第２実施形態におけるオリジナル更新通知メール送信処理を示すフローチャートである。
【図２０】第２実施形態における受信者間メール転送処理を示すフローチャートである。
【図２１】第２実施形態におけるオリジナル更新通知メールと受信されたオリジナル更新通知メールの具体例を示す図である。
【図２２】第２実施形態における受信者間メール、転送通知メール、受信された転送通知メールの具体例を示す図である。
【図１】
2007279921.tif 000003
【図２】
2007279921.tif 000004
【図３】
2007279921.tif 000005
【図４】
2007279921.tif 000006
【図５】
2007279921.tif 000007
【図６】
2007279921.tif 000008
【図７】
2007279921.tif 000009
【図８】
2007279921.tif 000010
【図９】
2007279921.tif 000011
【図１０】
2007279921.tif 000012
【図１１】
2007279921.tif 000013
【図１２】
2007279921.tif 000014
【図１３】
2007279921.tif 000015
【図１４】
2007279921.tif 000016
【図１５】
2007279921.tif 000017
【図１６】
2007279921.tif 000018
【図１７】
2007279921.tif 000019
【図１８】
2007279921.tif 000020
【図１９】
2007279921.tif 000021
【図２０】
2007279921.tif 000022
【図２１】
2007279921.tif 000023
【図２２】
2007279921.tif 000024