JP2013077227A - 制御プログラム、情報処理装置および方法 - Google Patents

Abstract

【課題】ユーザが被る不利益を軽減しつつ、不注意による情報漏洩を防ぐ。
【解決手段】コンピュータは、記憶装置に記憶されたファイルの転送先を示す転送先情報が、ファイルへのアクセスを許容する対象を示す許可対象情報に含まれていない場合に、ファイルの転送前に、転送の実行を許可するか否かの入力を促す（ステップＳ１０８）。また、許可する旨の入力がコンピュータの入力手段を用いて行われると、コンピュータは、許可対象情報に転送先情報を追加する（ステップＳ１１１）とともに、ファイルの転送を実行する（ステップＳ１０６）。
【選択図】図１

Description

本発明は、情報の漏洩を防止するための保護技術に関する。

社会の情報化の進展にともない、情報の漏洩を防止するための保護技術の重要性も増している。そして、情報漏洩防止に関する様々な保護技術が提案されている。
例えば、ＵＲＬ（Uniform Resource Locator）を添付した電子メールの受信者が、第三者へ当該電子メールを転送することがある。その場合の、ＵＲＬの参照先へのアクセスに対する利便性を、情報漏洩に対するセキュリティを損なわずに向上させることを目的として、次のような技術が提案されている。

当該技術は、具体的には、共有ファイルへのアクセスを管理する共有ファイルアクセス管理システムにおける共有ファイルアクセス管理方法の一つである。当該共有ファイルアクセス管理方法によれば、電子メール中のＵＲＬによりアクセスされる共有ファイルへのアクセス権限の付与条件を示す共有ファイルアクセス権限付与条件を、処理装置が記憶装置へ格納する。また、当該共有ファイルアクセス管理方法によれば、電子メールの転送時に、当該電子メール中のＵＲＬによりアクセスされる共有ファイルの共有ファイルアクセス権限付与条件を、処理装置が記憶装置から読み出す。そして、当該電子メールの転送時の宛先が、読み出された共有ファイルアクセス権限付与条件に該当するユーザである場合、当該ユーザには、当該共有ファイルへのアクセス権限が付与される。

特開２００８−２６２２９３号公報

情報の漏洩は、悪意のあるユーザにより故意に引き起こされることもあるが、悪意のないユーザの不注意のせいで引き起こされることもある。
しかし、不注意による情報漏洩を防ぐために、ユーザによる操作に対して過度の制約を課すことは、ユーザの利便性を損なうおそれがあり、その結果、ユーザの作業効率の低下を招くおそれもある。また、情報漏洩を防ぐために事前にポリシーを設定する仕組みが採用される場合、管理者またはその他のユーザがポリシーを設定するための負担は、小さくはない。つまり、場合によっては、不注意による情報漏洩の防止と引き換えに、利便性の低下またはポリシー設定の負担などの何らかの不利益を、ユーザが被るおそれがある。

そこで本発明の一側面として、ユーザが被る不利益を軽減しつつ、不注意による情報漏洩を防ぐことを目的とする。

一態様により提供される制御プログラムは、コンピュータに以下の処理を実行させる。
前記処理は、記憶装置に記憶されたファイルの転送先を示す転送先情報が、前記ファイルへのアクセスを許容する対象を示す許可対象情報に含まれていない場合に、前記ファイルの転送前に、転送の実行を許可するか否かの入力を促すことを含む。また、前記処理は、許可する旨の入力が該コンピュータの入力手段を用いて行われると、前記許可対象情報に前記転送先情報を追加するとともに、前記ファイルの転送を実行することを含む。

上記の制御プログラムの一側面によれば、ユーザが被る不利益を軽減しつつ、不注意による情報漏洩を防ぐことができる。

ファイルのライフサイクル内で行われる処理を説明する図である。 ネットワーク構成例を示す図である。 システム構成を示すブロック図である。 コンピュータのハードウェア構成図である。 ファイル生成時に行われる生成元登録処理のフローチャートである。 管理ＤＢの例を示す図（その１）である。 管理ＤＢの例を示す図（その２）である。 管理ＤＢの例を示す図（その３）である。 添付ファイルつきの新規電子メールの送信時または添付ファイルつきの受信済み電子メールの転送時に実行される送信確認処理のフローチャートである。 添付ファイルつきの電子メールの受信時に行われる添付ファイル登録処理のフローチャートである。 電子メールの添付ファイルがローカルに保存されるときに行われる所在登録処理のフローチャートである。 ファイルの複写、移動または変名時に行われる所在更新処理のフローチャートである。 ファイルが削除されるときに行われるエントリ削除処理のフローチャートである。 共有フォルダへのファイルの書き込み時に行われる書き込み確認処理のフローチャートである。 管理ＤＢの例を示す図（その４）である。 外来ファイル管理テーブルの例を示す図である。 外来ファイル登録処理のフローチャートである。 ファイルがリモートに出力されようとするときに行われる出力確認処理のフローチャートである。 ファイル削除時に行われる外来ファイル情報更新処理のフローチャートである。

以下、実施形態について、図面を参照しながら詳細に説明する。説明の順序は以下のとおりである。
まず、図１〜４を参照して、第１〜３実施形態の共通点について説明する。その後、図５〜１３を参照して、電子メールの添付ファイルを介した情報漏洩の防止に関する第１実施形態について説明する。さらに、図１４〜１５を参照して、共有フォルダを介した情報漏洩も防止するための第２実施形態について説明する。また、うっかりミスによる情報漏洩が起きやすいファイルに監視対象を絞り込むことで処理負荷を減らす第３実施形態について、図１６〜１９を参照して説明する。最後に、その他のいくつかの変形例についても説明する。

図１は、ファイルのライフサイクル内で行われる処理を説明する図であり、ＵＭＬ（Unified Modeling Language）のアクティビティ図の形式で表されている。
まず、ステップＳ１０１で、コンピュータは、ファイルの生成元（origin）を当該ファイルに関する非第三者（non-third party）として登録する。

あるファイルに関する非第三者とは、換言すれば、当該ファイルにアクセスする権限のあるユーザまたはコンピュータである。ファイルの生成元は、当然、当該ファイルに関する非第三者である。よって、ステップＳ１０１では、生成元が自動的に非第三者として登録される。

例えば、あるユーザの使うＰＣ（Personal Computer）において新規に作成されるファイルに関しては、当該ユーザが当該ファイルの生成元として見なされてもよい。そして、生成元は、当該ユーザを識別する情報（例えばアカウント名）により表されてもよい。

あるいは、ＰＣが特定の一人のユーザによってしか使われないのであれば、当該ＰＣが生成元と見なされてもよい。そして、当該ＰＣを識別する情報により生成元が表されてもよい。例えば、イントラネット内でＰＣを識別する情報の例は、ホスト名、ＭＡＣ（Media Access Control）アドレス、固定的に（すなわち静的に）割り当てられたＩＰ（Internet Protocol）アドレスなどである。

また、受信された電子メールの添付ファイルに関しては、当該電子メールの送信元（sender）が、ファイルの生成元として見なされてもよい。そして、生成元は、送信元電子メールアドレスにより表されてもよい。

あるいは、ＦＴＰ（File Transfer Protocol）サーバやＨＴＴＰ（Hypertext Transfer Protocol）サーバなどのサーバからダウンロードされたファイルに関しては、当該サーバがファイルの生成元として見なされてもよい。そして、生成元は、当該サーバを識別する情報（例えばＦＱＤＮ（Fully Qualified Domain Name）またはＩＰアドレス）により表されてもよい。

ステップＳ１０１での登録後、コンピュータは、ファイルに対する何らかの処理の実行を指示する入力をユーザから受け取るまで待つ。そして、コンピュータは、ユーザから入力を受け取ると、ステップＳ１０１に続く合流（merge）ノードＳ１０２を経た次の決定（decision）ノードＳ１０３において、受け取った入力の種類を判定する。

コンピュータが受け取った入力が、ファイルを削除する処理の実行を指示する入力である場合は、コンピュータは、ステップＳ１０４においてファイルを削除する。そして、ファイルのライフサイクルも終了し、図１の処理も終了する。

また、コンピュータが受け取った入力が、ファイルへのアクセスを提供する処理の実行を指示する入力の場合は、図１の処理フローの制御は、決定ノードＳ１０７へと移行する。あるいは、コンピュータが受け取った入力が、その他の処理（例えばファイルの内容を編集する処理）の実行を指示する入力である場合は、図１の処理フローの制御は、合流ノードＳ１０５を経た次のステップＳ１０６へと移行する。

ステップＳ１０６で、コンピュータは、ユーザから受け取った入力によって指示された処理を実行する。そして、図１の処理フローの制御は、合流ノードＳ１０２に戻る。
また、決定ノードＳ１０７では、コンピュータは、「ユーザから受け取った入力によって指示された処理が、第三者（third party）からの当該ファイルへのアクセスを提供するか否か」を判定する。

あるファイルに関する第三者とは、当該ファイルにアクセスする権限のないユーザまたはコンピュータである。換言すれば、当該ファイルに関する非第三者としてまだ登録されていないユーザまたはコンピュータは、当該ファイルに関する第三者である。

ここで、決定ノードＳ１０７の判定が実行されるのは、ユーザからの入力が、ファイルへのアクセスを提供する処理の実行を指示する入力の場合である。ファイルへのアクセスを提供する処理の例は、例えば以下の（１−１）〜（１−４）のような処理である。

（１−１） ファイルを電子メールに添付して、当該電子メールを送信（send）する処理。
（１−２） 共有フォルダにファイルを移動（move）または複写（copy）する処理。
（１−３） ＰＣから、ＦＴＰサーバまたはＨＴＴＰサーバに、ファイルをアップロードする処理。
（１−４） ＵＳＢ（Universal Serial Bus）メモリなどの記憶媒体に、ファイルを移動または複写する処理。

そこで、コンピュータは、「ユーザからの入力によって指示された処理が以下の（２−１）と（２−２）のどちらなのか」を、決定ノードＳ１０７において判定する。

（２−１） 当該ファイルに関して登録済みの、一または複数の非第三者に対してのみ、当該ファイルへのアクセスを提供する処理。
（２−２） 当該ファイルに関して非第三者として登録されていない、一または複数の第三者に対して、当該ファイルへのアクセスを提供する処理。

そして、ユーザからの入力によって指示された処理が（２−１）の処理の場合、図１の処理フローの制御は、合流ノードＳ１０５を経た次のステップＳ１０６へと移行する。つまり、非第三者にのみアクセスを許す処理の実行がユーザから指示された場合は、指示された処理の実行が許可され、その結果、指示された処理が実行される。そして、図１の処理フローの制御は、合流ノードＳ１０２に戻る。

逆に、ユーザからの入力によって指示された処理が（２−２）の処理の場合、コンピュータは、次のステップＳ１０８において警告を出す。警告を出すことにより、コンピュータは、「ユーザからの入力により指示された処理が、第三者への情報漏洩の危険性をはらんでいる」ということを、ユーザに通知する。また、警告を出すことにより、コンピュータは、「ユーザからの入力により指示された処理を本当に実行してよいのか否か」をユーザに確認する。

例えば、ユーザからの入力は、第三者を宛先に含む電子メールにファイルを添付して電子メールを送信する処理を実行するよう、コンピュータに指示する入力かもしれない。この場合、ステップＳ１０８でコンピュータは、「第三者が宛先に指定されていますが、本当にこの電子メールを送信しますか？」というダイアログを表示してもよい。

そして、コンピュータは、警告に対してユーザから入力が与えられるまで待ち、ステップＳ１０９でユーザからの入力を受け付ける。ステップＳ１０９で受け付けられる入力は、具体的には、実行が指示された処理を許可する許可入力か、実行が指示された処理を禁止する禁止入力である。

そこで、コンピュータは、次の決定ノードＳ１１０において、許可入力と禁止入力のいずれが与えられたのかを判定する。
禁止入力が与えられた場合は、図１の処理フローの制御は、合流ノードＳ１０２に戻る。つまり、仮に、第三者からのファイルへのアクセスを提供するような処理の実行を指示する入力を、ユーザが不注意から与えてしまったとしても、ユーザはステップＳ１０８の警告を受けることで自らの不注意に気づくことができる。そして、ユーザは、禁止入力をコンピュータに与えることで、コンピュータに当該処理の実行をとりやめさせることができる。その結果、不注意に起因する情報漏洩が防止される。

逆に、許可入力が与えられた場合は、コンピュータは次のステップＳ１１１において、（２−２）の一または複数の第三者を、新たな非第三者として登録する。そして、図１の処理フローの制御は、合流ノードＳ１０５を経た次のステップＳ１０６へと移行する。その結果、許可入力により実行が許可された処理がステップＳ１０６で実行され、図１の処理フローの制御は、合流ノードＳ１０２に戻る。

以上説明した図１の処理によれば、次の（３−１）〜（３−５）のような様々な効果が得られる。つまり、図１の処理によれば、情報漏洩を防止する（３−１）の効果と、ユーザの負担を軽減する（ひいては作業効率の悪化を防止する）（３−２）〜（３−５）の効果が、ともに得られる。

（３−１） 不注意（いわゆる「うっかりミス」）に起因する情報漏洩が防止される。
（３−２） 情報漏洩を防止するための事前のポリシー設定等が不要である。よって、ユーザまたはシステム管理者などにポリシー設定のための大きな負担をかけることがない。
（３−３） 警告が出されるのは、第三者にアクセスを提供する処理の実行が実際にユーザから指示された場合のみである。よって、過剰な警告の発生によりユーザが煩わされることがない。
（３−４） ファイルの生成元は、自動的に非第三者として登録される。また、許可入力を契機とする新たな非第三者の登録も、自動的に行われる。よって、ユーザには非第三者を登録するための格別な手間は生じない。
（３−５） 非第三者間でのファイルのやりとりは、何ら制約を受けず、警告の対象でもない。よって、非第三者間でのファイルのやりとりにおいて、ユーザに煩わしさまたは不便さを感じさせることはない。

続いて、図２を参照して、ネットワーク構成例について説明する。図２には、ＬＡＮ（Local Area Network）１１０と、ＬＡＮ１１０が接続されている外部のネットワーク１２０（例えばインターネット）が例示されている。

また、図２には、ＬＡＮ１１０をネットワーク１２０に接続するルータ１１１も例示されている。ＬＡＮ１１０にはさらに、３台のクライアントＰＣ１１２〜１１４と、ファイルサーバ１１５と、メールサーバ１１６と、管理サーバ１１７が属している。

なお、実施形態によっては管理サーバ１１７が省略されてもよい。しかし、非第三者をファイルと対応づけて登録するためのＤＢ（データベース）を管理サーバ１１７が管理してもよい。

ＬＡＮ１１０内のクライアントＰＣ１１２〜１１４は、管理サーバ１１７を介して当該ＤＢにアクセスしてもよい。管理サーバ１１７が省略される場合は、クライアントＰＣ１１２〜１１４のそれぞれがローカルにＤＢを保持してもよい。

あるいは、管理サーバ１１７が保持するＤＢに含まれるエントリのうち、一部のエントリの複製がクライアントＰＣ１１２〜１１４に保持されてもよい。例えば、クライアントＰＣ１１２は、クライアントＰＣ１１２が保存しているファイルに関するエントリと、クライアントＰＣ１１２が送信または受信した電子メールに関するエントリの複製を保持してもよい。

そして、ネットワーク１２０には、メールサーバ１１６とは別のメールサーバ１２１と、ＨＴＴＰサーバ１２２と、ＦＴＰサーバ１２３が接続されている。メールサーバ１２１には、例えば不図示の別のＬＡＮなどのネットワークを介して、クライアントＰＣ１２４も接続されている。

さてここで、説明の便宜上、例えば以下の（４−１）〜（４−６）のような状況を想定する。

（４−１） クライアントＰＣ１１２において新規作成されたあるファイルが、機密情報を含む。なお、クライアントＰＣ１１２のユーザは、当該機密情報を正当に知り得る立場にいるものとする。
（４−２） ＬＡＮ１１０内のクライアントＰＣ１１３のユーザは、当該機密情報にアクセスすることを許されていない。例えば、「ＬＡＮ１１０はある会社のイントラネットであり、その会社の規則によれば、クライアントＰＣ１１３のユーザは、当該機密情報の閲覧を許されていない」などの場合が、（４−２）の具体例である。
（４−３） ＬＡＮ１１０外のクライアントＰＣ１２４のユーザも、当該機密情報にアクセスすることを許されていない。
（４−４） ファイルサーバ１１５上には、クライアントＰＣ１１３のユーザにもアクセス権のある共有フォルダが存在する。
（４−５） ＨＴＴＰサーバ１２２上の任意のファイルは任意のユーザによりダウンロード可能である。
（４−６） ＦＴＰサーバ１２３上の任意のファイルは任意のユーザによりダウンロード可能である。

以上の（４−１）〜（４−６）の想定のもとでは、クライアントＰＣ１１２のユーザの不注意から、仮に例えば以下の（５−１）〜（５−５）のような処理が実行されてしまえば、機密情報が漏洩してしまう。

（５−１） 機密情報を含む（４−１）のファイルを、クライアントＰＣ１１３のユーザに宛てた電子メールに添付して、当該電子メールを送信する処理。
（５−２） 機密情報を含む（４−１）のファイルを、クライアントＰＣ１２４のユーザに宛てた電子メールに添付して、当該電子メールを送信する処理。
（５−３） 機密情報を含む（４−１）のファイルを、（４−４）の共有フォルダに複写または移動する処理。
（５−４） 機密情報を含む（４−１）のファイルを、ＨＴＴＰサーバ１２２にアップロードする処理。
（５−５） 機密情報を含む（４−１）のファイルを、ＦＴＰサーバ１２３にアップロードする処理。

つまり、上記の（５−１）〜（５−５）の処理は、いずれも、第三者へのアクセスを提供する処理であり、情報漏洩を引き起こすおそれのある処理である。しかし、図１の処理によれば、（５−１）〜（５−５）のような処理に対しては警告が出されるので、不注意による情報漏洩が防止される。

続いて、図３のブロック図を参照して、システム構成について説明する。詳しくは後述するが、図３のシステム２００は、図２のクライアントＰＣ１１２〜１１４と管理サーバ１１７に分散したクライアントサーバシステムであってもよい。あるいは、クライアントＰＣ１１２〜１１４のそれぞれが、スタンドアロンシステムとしてシステム２００を実現してもよい。

さて、システム２００は、登録管理部２１０と実行制御部２２０と記憶装置２３０と入力装置２４０を含む。そして、登録管理部２１０は、生成元認識部２１１と登録部２１２と検出部２１３と判定部２１４を含み、実行制御部２２０は、警告部２２１と入力受付部２２２と許可部２２３と禁止部２２４を含む。また、記憶装置２３０は、ファイルを識別するファイル識別情報２３１に対応づけて、当該ファイルに関する一以上の非第三者それぞれを識別する非第三者識別情報２３２を記憶する。

登録管理部２１０は、記憶装置２３０に、ファイルの生成元を識別する情報を、当該ファイルのファイル識別情報２３１に対応づけて非第三者識別情報２３２として登録する。

ところで、ある種の処理は、当該ファイルのファイル識別情報２３１に対応づけられて記憶装置２３０に記憶されている非第三者識別情報２３２により識別されるいずれの非第三者でもない、一以上の第三者からの、当該ファイルへのアクセスを提供する。説明の便宜上、第三者からのファイルへのアクセスを提供するそのような処理を「特定の処理」という。特定の処理の具体例は（５−１）〜（５−５）の処理である。

登録管理部２１０は、特定の処理の実行を指示する特定の入力と、上記の一以上の第三者からの当該ファイルへのアクセスを許可する許可入力の双方が与えられた場合、上記の一以上の第三者の各々を、当該ファイルに関する非第三者として記憶装置２３０に登録する。特定の入力と許可入力は、具体的には、入力装置２４０を介してユーザから与えられる入力である。

そして、実行制御部２２０は、特定の入力と許可入力の双方が与えられた場合には、特定の処理の実行を許可する。しかし、実行制御部２２０は、特定の入力が与えられ、かつ許可入力が与えられない場合には、特定の処理の実行を禁止する。

以上の登録管理部２１０と実行制御部２２０の動作をより具体的に説明すれば、以下のとおりである。
生成元認識部２１１は、ファイルの生成元を認識する。例えば、生成元認識部２１１は、入力装置２４０からの入力に基づいて生成元を認識する場合もある。

そして、登録部２１２は、生成元認識部２１１の認識にしたがって、図１のステップＳ１０１において、当該ファイルのファイル識別情報２３１に対応づけて、生成元を識別する情報を非第三者識別情報２３２として記憶装置２３０に登録する。また、記憶装置２３０には、ファイル識別情報２３１と非第三者識別情報２３２だけでなく他の情報をさらに含むＤＢが保持されていてもよい。登録部２１２は、ＤＢへのエントリの追加、ＤＢ内の個々のエントリの更新、ＤＢからのエントリの削除などの、ＤＢの更新のための各種処理をさらに行ってもよい。

また、検出部２１３は、入力装置２４０を介したユーザからの入力を検出する。ユーザからの入力には、上記の特定の処理の実行を指示する特定の入力や、その他の処理の実行を指示する入力などがある。つまり、検出部２１３は、図１の決定ノードＳ１０３での判定対象の入力を検出する。そして、検出部２１３による入力の検出に応じて、判定部２１４は、検出部２１３が検出した入力が上記の特定の入力であるか否かを判定する。

具体的には、判定部２１４は、記憶装置２３０を参照することで、「検出部２１３が検出した入力が、上記の特定の入力であるか否か」を判定する。判定部２１４による判定は、図１の決定ノードＳ１０７に対応する。

なお、検出部２１３が検出した入力により実行が指示される処理が、ファイルへのアクセスを提供する処理でなければ、ユーザが指示した処理が上記の特定の処理ではないことが明らかである。よって、図１に示すように、ユーザが指示した処理が実行される。

他方、検出部２１３が検出した入力により実行が指示される処理が、ファイルへのアクセスを提供する処理である場合、ユーザが実行を指示した処理は、上記の特定の処理の可能性がある。そこで、判定部２１４は、以下のように動作する。

判定部２１４は、検出部２１３が検出した入力により実行が指示される処理の対象のファイルを識別するファイル識別情報２３１を検索キーにして、記憶装置２３０を検索する。そして、判定部２１４は、検索キーと対応づけられて記憶されている非第三者識別情報２３２を抽出する。その結果、非第三者識別情報２３２が抽出されないこともあるし、一の非第三者に関する非第三者識別情報２３２のみが抽出されることもあるし、複数の非第三者に関する非第三者識別情報２３２が抽出されることもある。

ここで、説明の便宜上、検出部２１３が検出した入力により実行が指示される処理が、アクセスを提供する対象のことを、「アクセス提供対象」という。アクセス提供対象の数は、一または複数である。例えば、アクセス提供対象は、電子メールの宛先のこともあるし、図２のファイルサーバ１１５上の共有フォルダへのアクセス権限が与えられたユーザのこともあるし、図２のＨＴＴＰサーバ１２２またはＦＴＰサーバ１２３のこともある。

判定部２１４は、一または複数のアクセス提供対象のそれぞれについて、「当該アクセス提供対象が、抽出した非第三者識別情報２３２が示すいずれかの非第三者であるか否か」を判定する。もし、アクセス提供対象の中に、一以上の第三者が含まれていれば、判定部２１４は、「検出部２１３が検出した入力は、上記の特定の入力に該当する」と判定する。逆に、アクセス提供対象が非第三者のみであれば、判定部２１４は、「検出部２１３が検出した入力は、上記の特定の入力に該当しない」と判定する。

そして、判定部２１４は、「検出部２１３が検出した入力は、上記の特定の入力に該当する」と判定した場合は、特定の入力が与えられたことを警告部２２１に通知する。すると、警告部２２１は図１のステップＳ１０８のとおり、警告を出す。

そして、図１のステップＳ１０９のとおり、入力受付部２２２が、警告に対する入力として、許可入力または禁止入力を受け付ける。許可入力と禁止入力は、入力装置２４０を介してユーザから与えられる入力である。

また、許可入力は、特定の処理の実行を許可するための入力であり、換言すれば、アクセス提供対象の中に含まれる第三者（なお、第三者の数は、一または複数である）のすべてに、特定の処理の対象たるファイルへのアクセスを許可するための入力である。逆に、禁止入力は、特定の処理の実行を禁止するための入力であり、換言すれば、アクセス提供対象の中に含まれる第三者のすべてに、特定の処理の対象たるファイルへのアクセスを禁止するための入力である。

そして、入力受付部２２２は、許可入力を受け付けた場合には、許可入力が与えられたことを登録部２１２に通知する。
ここで、許可入力は、「特定の処理の実行が許可された」と意味するだけでなく、「アクセス提供対象の中に含まれる各第三者を、特定の処理の対象たるファイルに関して今後は非第三者として扱ってよい」ということも意味する。したがって、図１のステップＳ１１１のとおり、登録部２１２は、新たな非第三者を、記憶装置２３０に登録する。

つまり、登録部２１２は、特定の処理の対象たるファイルを識別するファイル識別情報２３１に対応づけて、新たな非第三者を識別する非第三者識別情報２３２を、記憶装置２３０に登録する。なお、新たな非第三者の各々は、今までは第三者だったのであり、具体的には、判定部２１４によって上記のようにしてアクセス提供対象の中から見つけられた第三者だったわけである。よって、登録部２１２は、新たに登録する非第三者を示す非第三者識別情報２３２を、判定部２１４から取得することができる。

さらに、入力受付部２２２は、許可入力を受け付けた場合には、許可部２２３に通知を送る。また、判定部２１４も、「検出部２１３が検出した入力は、上記の特定の入力に該当しない」と判定した場合には、許可部２２３に通知を送る。

許可部２２３は、判定部２１４または入力受付部２２２から通知を受けると、検出部２１３が検出した入力により指示されている処理の実行を許可する。その結果、図１のステップＳ１０４またはＳ１０６のとおり、ユーザが指示した処理が実行される。

逆に、入力受付部２２２は、禁止入力を受け付けた場合には、禁止部２２４に通知を送る。すると、禁止部２２４は、特定の処理の実行を禁止する。したがって、図１の決定ノードＳ１１０から合流ノードＳ１０２への処理フローに示すとおり、特定の処理は実行されない。その結果、ユーザの不注意に起因する情報漏洩は防止される。

さて、以上のように動作する図３のシステム２００は、上記のとおり、スタンドアロンシステムであってもよいし、クライアントサーバシステムであってもよい。
システム２００がスタンドアロンシステムの場合、例えば、図２のクライアントＰＣ１１２が登録管理部２１０と実行制御部２２０と記憶装置２３０と入力装置２４０のすべてを含む。クライアントＰＣ１１３や１１４もクライアントＰＣ１１２と同様である。スタンドアロンシステムの例は、第３実施形態とともに後で詳しく説明する。

システム２００がクライアントサーバシステムの場合、例えば、記憶装置２３０は管理サーバ１１７内にあってもよい。そして、クライアントＰＣ１１２〜１１４のそれぞれが、実行制御部２２０と入力装置２４０を有してもよい。

登録管理部２１０は、管理サーバ１１７とクライアントＰＣ１１２〜１１４に分散していてもよい。例えば、登録部２１２と判定部２１４が管理サーバ１１７内にあってもよく、クライアントＰＣ１１２〜１１４のそれぞれが生成元認識部２１１と検出部２１３を有してもよい。

あるいは、管理サーバ１１７は、記憶装置２３０と、記憶装置２３０上のＤＢに関するＤＢインタフェイスを提供するだけでもよい。そして、クライアントＰＣ１１２〜１１４の各々が登録管理部２１０を有していてもよい。登録管理部２１０内の登録部２１２と判定部２１４は、管理サーバ１１７が提供するＤＢインタフェイスを介して記憶装置２３０上のＤＢにアクセスし、エントリの追加、削除、更新、参照などを行う。

このように、管理サーバ１１７がＤＢインタフェイスを提供し、登録部２１２や判定部２１４がクライアントＰＣ１１２〜１１４にオフロードされた実施形態には、「管理サーバ１１７の処理負荷が軽くなるので、管理サーバ１１７が多数のクライアントを管理しやすい」という利点がある。この利点について詳しく説明すれば次のとおりである。

ＬＡＮ１１０内のクライアントＰＣは、換言すれば、情報漏洩防止のために管理サーバ１１７が管理する対象のクライアントＰＣである。よって、図２のＬＡＮ１１０内に非常に多くのクライアントＰＣが存在する状況において、仮に、各クライアントＰＣについて１台の管理サーバ１１７が登録部２１２と判定部２１４として登録や判定などの処理を行うとすれば、管理サーバ１１７の負荷が非常に大きい。

そこで、ＬＡＮ１１０内のクライアントＰＣの数が多い場合は、登録部２１２と判定部２１４の機能を各クライアントＰＣにオフロードすることが好ましい。すると、管理サーバ１１７は、ＤＢインタフェイスさえ提供すればよいので、たとえクライアントＰＣの数が多くても問題ない。後に詳しく述べる第１〜２実施形態では、管理サーバ１１７がＤＢインタフェイスのみを提供するようなクライアントサーバシステムとしてシステム２００が構成される場合について、主に説明する。

続いて、図４を参照してコンピュータのハードウェア構成について説明する。図２のクライアントＰＣ１１２〜１１４、ファイルサーバ１１５、メールサーバ１１６、管理サーバ１１７、メールサーバ１２１、ＨＴＴＰサーバ１２２、ＦＴＰサーバ１２３、およびクライアントＰＣ１２４は、いずれも、図４のようなコンピュータであってよい。

図４のコンピュータ３００は、ＣＰＵ（Central Processing Unit）３０１と、ＲＯＭ（Read Only Memory）３０２と、ＲＡＭ（Random Access Memory）３０３と、通信インタフェイス３０４を有する。また、コンピュータ３００は、入力装置３０５と、出力装置３０６と、記憶装置３０７と、記憶媒体３１０の駆動装置３０８を有する。そして、コンピュータ３００内の各部は、互いにバス３０９で接続されている。また、コンピュータ３００は、通信インタフェイス３０４を介してネットワーク３１１に接続されている。

なお、入力装置３０５、出力装置３０６、２０７、および駆動装置３０８は、図４ではコンピュータ３００のブロックの中に描かれている。しかし、外付けの入力装置３０５、出力装置３０６、２０７、および駆動装置３０８が、それぞれコンピュータ３００に接続されていてもよいことは無論である。

ＣＰＵ３０１は、プログラムをＲＡＭ３０３にロードし、ＲＡＭ３０３をワーキングエリアとしても用いながら、プログラムを実行する。プログラムは、予めＲＯＭ３０２または記憶装置３０７に記憶されていてもよい。記憶装置３０７は、例えばハードディスク装置であってもよい。

あるいは、プログラムは、プログラム提供者３１２により提供され、ネットワーク３１１と通信インタフェイス３０４を介してコンピュータ３００にダウンロードされ、記憶装置３０７に記憶されてもよい。プログラム提供者３１２は、例えば、コンピュータ３００以外の他のコンピュータである。

また、プログラムは、コンピュータ読み取り可能な可搬型の記憶媒体３１０に記憶されて提供されてもよい。プログラムは、駆動装置３０８にセットされた記憶媒体３１０から、駆動装置３０８により読み取られる。読み取られたプログラムは、その後、一旦記憶装置３０７にコピーされてからＲＡＭ３０３にロードされてもよいし、直接ＲＡＭ３０３にロードされてもよい。記憶媒体３１０としては、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、光磁気ディスク、磁気ディスク、不揮発性の半導体メモリカードなどが利用可能である。

なお、通信インタフェイス３０４は、有線ＬＡＮのインタフェイス装置でもよいし、無線ＬＡＮのインタフェイス装置でもよいし、両者の組み合わせでもよい。また、入力装置３０５は、例えば、キーボード、マウスやタッチスクリーンなどのポインティングデバイス、マイク、またはそれらの組み合わせである。出力装置３０６は、例えば、ディスプレイ、スピーカ、またはそれらの組み合わせである。ディスプレイは、タッチスクリーンであってもよい。

また、ＲＯＭ３０２、ＲＡＭ３０３、記憶装置３０７、および記憶媒体３１０は、いずれも、コンピュータ読み取り可能な記憶媒体の例である。これらのコンピュータ読み取り可能な記憶媒体は、有形の（tangible）記憶媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。

ところで、図３と図４の関係を説明すると以下のとおりである。
図３の登録管理部２１０は、プログラムを実行するＣＰＵ３０１により実現されてもよい。また、システム２００がクライアントサーバシステムの場合は、登録管理部２１０を実現するために、さらに通信インタフェイス３０４が使われてもよい。

例えば、生成元認識部２１１と検出部２１３は、クライアントＰＣ１１２〜１１４それぞれのＣＰＵ３０１によって実現されてもよい。
また、登録部２１２と判定部２１４は、管理サーバ１１７が提供するＤＢインタフェイスを介して、記憶装置２３０にアクセスする。そこで、登録部２１２と判定部２１４は、クライアントＰＣ１１２〜１１４それぞれのＣＰＵ３０１と通信インタフェイス３０４によって実現されてもよい。ＣＰＵ３０１は、登録部２１２と判定部２１４を実現するためのプログラムを実行し、通信インタフェイス３０４は、ＣＰＵ３０１の制御にしたがって管理サーバ１１７と通信する。

そして、警告部２２１は、各クライアントＰＣ１１２〜１１４において、プログラムを実行するＣＰＵ３０１と、視覚的警告と聴覚的警告の一方または双方を出力する出力装置３０６により、実現されてもよい。

また、入力受付部２２２は、入力装置３０５からの入力を受け付けてプログラムにしたがって動作するＣＰＵ３０１により、実現されてもよい。図３のシステム２００がスタンドアロンシステムでない場合、入力受付部２２２を実現するのに、さらにクライアントＰＣ１１２〜１１４それぞれの通信インタフェイス３０４が使われてもよい。

そして、許可部２２３と禁止部２２４は、各クライアントＰＣ１１２〜１１４において、プログラムを実行するＣＰＵ３０１により実現されてもよい。
また、記憶装置２３０が管理サーバ１１７にある場合は、記憶装置２３０は管理サーバ１１７の記憶装置３０７であってもよい。逆に、記憶装置２３０が例えばクライアントＰＣ１１２にある場合は、記憶装置２３０はクライアントＰＣ１１２の記憶装置３０７であってもよい。そして、クライアントＰＣ１１２〜１１４それぞれにおける図３の入力装置２４０は、クライアントＰＣ１１２〜１１４それぞれにおける図４の入力装置３０５であってもよい。

続いて、図５〜１３を参照して、電子メールの添付ファイルを介した情報漏洩の防止に関する第１実施形態について説明する。第１実施形態は、図３のシステム２００がクライアントサーバシステムである場合の例である。具体的には、第１実施形態では、図２の管理サーバ１１７が、下記（６−１）〜（６−２）を含む。

（６−１） 図３の記憶装置２３０（より具体的には、後述の図６〜８の管理ＤＢ４００を保持する、図４の記憶装置３０７）。
（６−２） 記憶装置２３０上のＤＢに対する、図３の登録部２１２と判定部２１４からのＤＢアクセス要求を受け付けて、ＤＢアクセス要求に対して応答する、ＤＢインタフェイス。

なお、（６−２）のＤＢインタフェイスは、例えば、プログラムを実行するＣＰＵ３０１と、通信インタフェイス３０４によって、実現されてもよい。プログラムにしたがって動作するＣＰＵ３０１は、通信インタフェイス３０４を介してＤＢアクセス要求を受け付け、受け付けたＤＢアクセス要求にしたがって記憶装置３０７上のＤＢにアクセスし、通信インタフェイス３０４を介して、ＤＢアクセス結果を返す。

また、第１実施形態では、図２のクライアントＰＣ１１２〜１１４のそれぞれが、図３に示すブロックのうち下記（７−１）〜（７−６）を含む。

（７−１） 生成元認識部２１１。
（７−２） 上記（６−２）のＤＢインタフェイスを介して記憶装置２３０上のＤＢを更新する、登録部２１２。
（７−３） 検出部２１３。
（７−４） 上記（６−２）のＤＢインタフェイスを介して記憶装置２３０上のＤＢを参照することで判定を行う、判定部２１４。
（７−５） 実行制御部２２０。
（７−６） 入力装置２４０。

以下では、便宜上、各フローチャートに関して、クライアントＰＣ１１２〜１１４のうちの１台を状況に応じて例として選んで説明を行う。しかし、もちろん他の２台においても、同様の処理が適宜行われる。

さて、図５は、ファイル生成時に行われる生成元登録処理のフローチャートである。図５に関しては、便宜上、クライアントＰＣ１１２におけるファイルの生成を例として説明する。

図５の生成元登録処理は、生成元認識部２１１が、クライアントＰＣ１１２に現在ログインしているユーザを、生成されたファイルの生成元として認識し、登録部２１２が生成元認識部２１１の認識にしたがって生成元を記憶装置２３０に登録する処理である。つまり、図５の生成元登録処理は、図１のステップＳ１０１の処理の一例である。

具体的には、図５の生成元登録処理は、クライアントＰＣ１１２上でファイルが新たに生成されるときに実行される。例えば、下記（８−１）〜（８−２）のような操作が行われた場合には、生成元登録処理を開始するためのトリガとして、（８−２）の保存操作を生成元認識部２１１が検出する。そして、生成元認識部２１１は、トリガを検出すると、生成元登録処理を開始する。

（８−１） クライアントＰＣ１１２のユーザが、あるアプリケーションソフトウェアで新規ファイルを作成し、新規ファイルを適宜編集したとする。
（８−２） その後、ユーザは、「保存（Save）」メニューを選択し、新規ファイルをクライアントＰＣ１１２の記憶装置３０７に保存したとする。

アプリケーションソフトウェアにもよるが、（８−２）の保存操作による、記憶装置３０７上へのファイルの生成は、例えば、ＯＳが提供するＡＰＩ（Application Programming Interface）関数を介して行われる。この場合、生成元認識部２１１は、ファイルの生成に使われる所定のＡＰＩ関数の呼び出しをフックすることで、図５の処理を開始するためのトリガを検出してもよい。

生成元認識部２１１は、図５の処理を開始すると、まずステップＳ２０１で以下の（９−１）〜（９−３）の情報を取得する。

（９−１） ファイル生成を指示したユーザのアカウント名。すなわち、クライアントＰＣ１１２に現在ログインしているユーザのアカウント名。
（９−２） 生成されたファイルのフルパス（すなわち絶対パス）。フルパスの表記法はＯＳに応じて異なるが、以下では説明の便宜上、ドライブレターから始まる「Ｃ：＼ｄｉｒ１＼ｄｉｒ２＼ｆｉｌｅ．ｔｘｔ」のような表記法が使われるものと仮定する。
（９−３） ファイルが生成されたマシンのホスト名。すなわち、クライアントＰＣ１１２をＬＡＮ１１０内で一意に識別するホスト名。なお、ホスト名以外の識別情報がホスト名の代わりに使われてもよい（例えば、クライアントＰＣ１１２に固定的なＩＰアドレスが割り当てられる場合は、クライアントＰＣ１１２のＩＰアドレスがホスト名の代わりに使われてもよい）。

そして、次のステップＳ２０２で生成元認識部２１１は、生成されたファイルに対応するファイルＩＤを発行する。ファイルＩＤは、管理サーバ１１７による管理の対象範囲であるＬＡＮ１１０内で一意である。例えば、クライアントＰＣ１１２の生成元認識部２１１は、クライアントＰＣ１１２のホスト名と、クライアントＰＣ１１２内で一意なシーケンス番号とを組み合わせることで、ＬＡＮ１１０内で一意なファイルＩＤを生成してもよい。もちろん、実施形態によっては、生成元認識部２１１は、ＬＡＮ１１０内で一意なファイルＩＤの発行を管理サーバ１１７に要求し、管理サーバ１１７からファイルＩＤを取得してもよい。

続いて、ステップＳ２０３では、ステップＳ２０２で生成されたファイルＩＤと、（９−３）と（９−２）のペアにより表されるファイルの所在（location）とを対応づけるエントリが、図６のファイル所在テーブル４０２に追加される。また、次のステップＳ２０４では、ステップＳ２０２で生成されたファイルＩＤと、（９−１）のアカウント名とを対応づけるエントリが、図６のメンバテーブル４０１に追加される。そして、図５の生成元登録処理は終了する。

ここで、図６〜８を参照して、ステップＳ２０３とＳ２０４で使われるテーブルの具体例について説明する。その後、再び図５を参照して、ステップＳ２０３とＳ２０４の詳細について説明する。

図６〜８は、管理ＤＢ４００の例を示す図である。図６の管理ＤＢ４００は、図３の記憶装置２３０に保持されるＤＢであり、具体的にはメンバテーブル４０１とファイル所在テーブル４０２と電子メール管理テーブル４０３を含む。第１実施形態では、上記のとおり図３の記憶装置２３０は具体的には管理サーバ１１７の記憶装置３０７であるから、管理ＤＢ４００も管理サーバ１１７の記憶装置３０７に記憶される。

なお、管理ＤＢ４００内の各テーブルの内容は、イベントの発生にともなって変化する。よって以下では、「４００ａ」と「４００ｂ」のように異なる添え字を含む参照符号により、異なる時点における同じＤＢ（または同じテーブル）が区別される。図６〜８には、５つの異なる時点における管理ＤＢ４００が例示されているが、これら５つの例示の詳細は、フローチャートとともに後述する。ここでは、管理ＤＢ４００内の各テーブルの構成について先に説明する。

メンバテーブル４０１の各エントリは、ファイルＩＤと、当該ファイルＩＤにより識別されるファイルに関する非第三者を識別する情報（すなわち、図３の非第三者識別情報２３２）とを対応づける。図６〜８には非第三者識別情報２３２を示す列に「非第三者メンバ」という見出しが示されている。なお、ファイルＩＤは、図３のファイル識別情報２３１の一例である。

また、ファイル所在テーブル４０２の各エントリは、ファイルＩＤと、当該ファイルＩＤにより識別されるファイルの所在を示す所在情報とを対応づける。所在情報は、例えば、ホスト名と、当該ホスト名で識別されるマシン内のフルパスの組み合わせである。図６〜８には所在情報を示す列に「所在」という見出しが示されている。

そして、電子メール管理テーブル４０３の各エントリは、電子メールを一意に識別するメッセージＩＤと、電子メールに添付されているファイルのファイルＩＤと、当該添付ファイルのファイル名とを対応づける。メッセージＩＤとしては、例えば、電子メールの「Ｍｅｓｓａｇｅ−ＩＤ」ヘッダフィールドの値が使われてもよい。

ここで、図５を再び参照して、図５のステップＳ２０３とＳ２０４の詳細について、図６の具体例とともに説明する。
例えば、図５の生成元登録処理が開始される前には、メンバテーブル４０１とファイル所在テーブル４０２と電子メール管理テーブル４０３が、いずれも、エントリを持たない初期状態であったとする。また、ステップＳ２０１では、「ｎａｍｅ＿Ａ」というアカウント名と、「Ｃ：＼ｐａｔｈ＿Ａ＼Ｚ．ｔｘｔ」というフルパスと、「ＰＣ＿Ａ」というホスト名が得られたとする。

なお、ステップＳ２０２で発行されるファイルＩＤは、例えば上記のようにホスト名とシーケンス番号の組み合わせにより表されてもよい。しかし、以下では説明の便宜上、「Ｆ０００１０３」というファイルＩＤが発行されたものとする。

すると、ステップＳ２０３では、具体的には、クライアントＰＣ１１２内の生成元認識部２１１が、ファイル所在テーブル４０２へのエントリの追加を、クライアントＰＣ１１２内の登録部２１２に要求する。要求に際して、生成元認識部２１１は、「Ｆ０００１０３」というファイルＩＤと、「ＰＣ＿Ａ」というホスト名と、「Ｃ：＼ｐａｔｈ＿Ａ＼Ｚ．ｔｘｔ」というフルパスを登録部２１２に通知する。

すると、クライアントＰＣ１１２内の登録部２１２は、管理サーバ１１７内のＤＢインタフェイスを介して、ファイル所在テーブル４０２にエントリを追加する。具体的には、登録部２１２は、「ＰＣ＿Ａ」というホスト名と「Ｃ：＼ｐａｔｈ＿Ａ＼Ｚ．ｔｘｔ」というフルパスのペアで示される所在情報を「Ｆ０００１０３」というファイルＩＤに対応づける新規エントリを、ファイル所在テーブル４０２に追加する。

こうして、生成された新たなファイルの所在がファイル所在テーブル４０２に登録される。図６のファイル所在テーブル４０２ａは、以上のようにしてステップＳ２０３で追加された１個のエントリを含む。

また、ステップＳ２０４では、具体的には、クライアントＰＣ１１２内の生成元認識部２１１が、メンバテーブル４０１へのエントリの追加を、クライアントＰＣ１１２内の登録部２１２に要求する。要求に際して、生成元認識部２１１は、「Ｆ０００１０３」というファイルＩＤと、「ｎａｍｅ＿Ａ」というアカウント名を登録部２１２に通知する。

すると、クライアントＰＣ１１２内の登録部２１２は、管理サーバ１１７内のＤＢインタフェイスを介して、メンバテーブル４０１にエントリを追加する。具体的には、登録部２１２は、「ｎａｍｅ＿Ａ」というアカウント名を「Ｆ０００１０３」というファイルＩＤを対応づける新規エントリを、メンバテーブル４０１に追加する。

つまり、クライアントＰＣ１１２の登録部２１２は、ステップＳ２０４で以上のようにして、生成されたファイルに関する非第三者として、ファイルの生成を指示したユーザを登録する。図６のメンバテーブル４０１ａは、以上のようにしてステップＳ２０４で追加された１個のエントリを含む。

図６の管理ＤＢ４００ａは、以上のようにして図５の生成元登録処理が完了した時点における、管理ＤＢ４００の例である。なお、上記の説明から明らかなように、図５のステップＳ２０１とＳ２０２の実行順序は逆でもよいし、ステップＳ２０１とＳ２０２が並列に実行されてもよい。また、ステップＳ２０３とＳ２０４の実行順序は逆でもよいし、ステップＳ２０３とＳ２０４が並列に実行されてもよい。

続いて、図９を参照して、図１のステップＳ１０３〜Ｓ１１１の処理の具体例に相当する処理について説明する。図９は、添付ファイルつきの新規電子メールの送信時または添付ファイルつきの受信済み電子メールの転送時に実行される、送信確認処理のフローチャートである。

図９に関しても、便宜上、クライアントＰＣ１１２における処理を例として説明する。具体的には、図９の送信確認処理は、下記（１０−１）または（１０−２）の場合に開始される。

（１０−１） クライアントＰＣ１１２のユーザが、メールユーザエージェント（つまり電子メールクライアントソフトウェア）上で、一つ以上のファイルを添付した新規電子メールを作成し、作成した新規電子メールを送信するための操作を行ったとき。例えば、ユーザが「送信」ボタンをクリックしたとき。
（１０−２） クライアントＰＣ１１２のユーザが、メールユーザエージェント上で、受信済みかつ添付ファイルつきの電子メールを、転送する（forward）ための操作を行ったとき。例えば、ユーザが「転送」ボタンをクリックしたとき。

例えば、「送信」ボタンをクリックする入力を検出部２１３が検出すると、判定部２１４は、新たに送信されようとしている電子メールにファイルが一つ以上添付されているか否かを判定する。そして、もしファイルが一つ以上添付されていれば、判定部２１４は図９の送信確認処理を開始する。逆に、ファイルが添付されていなければ、判定部２１４は許可部２２３に通知を送り、許可部２２３が新規電子メールの送信を許可する。

また、「転送」ボタンをクリックする入力を検出部２１３が検出すると、判定部２１４は、転送されようとしている電子メールにファイルが一つ以上添付されているか否かを判定する。そして、もしファイルが一つ以上添付されていれば、判定部２１４は図９の送信確認処理を開始する。逆に、ファイルが添付されていなければ、判定部２１４は許可部２２３に通知を送り、許可部２２３が電子メールの転送を許可する。

なお、検出部２１３による検出は、例えば、メールユーザエージェントに予め用意されているフックを利用することで実現されてもよい。また、図９の処理を開始するためのトリガを検出部２１３が検出することは、図１のステップＳ１０３からステップＳ１０７への移行に相当する。

さて、判定部２１４は、図９の処理を開始すると、まずステップＳ３０１で以下の（１１−１）〜（１１−４）の情報を取得する。

（１１−１） 新規送信または転送を指示したユーザのアカウント名。
（１１−２） 送信元電子メールアドレス。
（１１−３） 宛先電子メールアドレス。
（１１−４） 各添付ファイルのファイルＩＤ。

判定部２１４は、（１１−１）のアカウント名（すなわち、クライアントＰＣ１１２に現在ログインしているユーザのアカウント名）を、例えば、ＯＳにより予め用意されているシステム関数を介して取得してもよい。

また、判定部２１４は、（１１−２）と（１１−３）のアドレスを、メールユーザエージェントから取得する。
なお、図９の処理においては、電子メールの「Ｔｏ」ヘッダフィールドに指定されているアドレスだけでなく、「ＣＣ」（Carbon Copy）ヘッダフィールドに指定されている電子メールアドレスも、宛先電子メールアドレスである。さらに、「ＢＣＣ」（Blind Carbon Copy）ヘッダフィールドに指定されている電子メールアドレスも、宛先電子メールアドレスである。よって、判定部２１４は、一つ以上の宛先電子メールアドレスを取得する。

また、判定部２１４は、各添付ファイルに関して、（１１−４）のファイルＩＤを具体的には以下のようにして取得する。
上記（１０−１）のように新規電子メールが送信されようとしている場合、判定部２１４は、クライアントＰＣ１１２のホスト名と、添付ファイルのクライアントＰＣ１１２内での所在を示すフルパスとを検索キーにして、ファイル所在テーブル４０２を検索する。なお、判定部２１４は、ホスト名を、例えばＯＳにより提供されるシステム関数などを介して取得してもよい。また、判定部２１４は、上記フルパスを、メールユーザエージェントから取得してもよい。

検索の結果、一つのエントリが見つかる。なぜなら、クライアントＰＣ１１２上で生成されたファイルが添付される場合は、図５の処理により、当該ファイルのエントリが既にファイル所在テーブル４０２に追加されているからである。

また、クライアントＰＣ１１２がかつて受信した別の電子メールに添付されていたファイルが、一旦クライアントＰＣ１１２内にローカルに保存され、その後、新規電子メールに添付される場合も、エントリが見つかる。なぜなら、後述の図１１の処理により、当該ファイルのエントリが既にファイル所在テーブル４０２に追加されているからである。

したがって、判定部２１４は、見つかったエントリから、ファイルＩＤを読み出すことで、ファイルＩＤを取得することができる。また、判定部２１４は、後述のステップＳ３０８の処理のために、ファイル名とファイルＩＤの対応関係を記憶する。

他方、（１０−２）のように電子メールが転送されようとしている場合、判定部２１４は、ユーザが転送しようとしている電子メールのメッセージＩＤと添付ファイルのファイル名を検索キーにして、電子メール管理テーブル４０３を検索する。なお、判定部２１４は、メッセージＩＤとファイル名を、メールユーザエージェントを介して取得してもよい。

検索の結果、一つのエントリが見つかる。なぜなら、ユーザが転送しようとしている電子メールが、ＬＡＮ１１０内から送信されたものの場合は、かつて送信元のクライアントＰＣが図９の処理を実行したときに、当該ファイルのエントリが既に電子メール管理テーブル４０３に追加されているからである。あるいは、ユーザが転送しようとしている電子メールの送信元がＬＡＮ１１０外の場合は、かつてクライアントＰＣ１１２において当該電子メールが受信されたときに、クライアントＰＣ１１２が後述の図１０の処理を実行したからである。図１０の処理により、当該ファイルのエントリは既に電子メール管理テーブル４０３に追加されている。

よって、ユーザが転送しようとしている電子メールの送信元がＬＡＮ１１０の内部だろうと外部だろうと、判定部２１４は、検索の結果、電子メール管理テーブル４０３からエントリを一つ見つける。したがって、判定部２１４は、（１０−２）の場合も（１０−１）の場合と同様に、見つかったエントリから、ファイルＩＤを読み出すことで、ファイルＩＤを取得することができる。そして、判定部２１４は、後述のステップＳ３０８の処理のために、ファイル名とファイルＩＤの対応関係を記憶する。

判定部２１４は、以上のようにしてステップＳ３０１で（１１−１）〜（１１−４）の情報を取得すると、次にステップＳ３０２で「警告リスト」を空に初期化する。警告リストは、判定部２１４が図１のステップＳ１０７の判定を行うために用いる情報の一例である。

また、次のステップＳ３０３で判定部２１４は、（１２−１）に示す各ペアと、（１２−２）に示す各ペアがメンバテーブル４０１に登録済みか否かを判定する。

（１２−１） ステップＳ３０１で取得した各ファイルＩＤと、ステップＳ３０１で取得した送信元電子メールアドレスのペア。
（１２−２） ステップＳ３０１で取得した各ファイルＩＤと、ステップＳ３０１で取得したアカウント名のペア。

説明の便宜上、Ｎ個のファイルが電子メールに添付されているとする（Ｎ≧１）。この場合、ファイルＩＤと送信元電子メールアドレスのペアはＮ通りあり、ファイルＩＤとアカウント名のペアもＮ通りある。よって、判定部２１４は、これらの合計２Ｎ個のペアがすべてメンバテーブル４０１に登録されているか否かを判定する。

そして、一つでもメンバテーブル４０１に登録されていないペアがあれば、処理はステップＳ３０４に移行する。逆に、２Ｎ個のペアがすべてメンバテーブル４０１に既に登録されていれば、処理はステップＳ３０５に移行する。

ステップＳ３０４で判定部２１４は、未登録の各ペアをメンバテーブル４０１に登録する。ステップＳ３０４の処理は、明らかな非第三者を登録することにより無駄な警告の発生を抑制し、その結果としてユーザの負荷を軽減するための処理である。

例えば、添付ファイルの個数が１個であり、当該添付ファイルのファイルＩＤが図６のファイル所在テーブル４０２ａに示す「Ｆ０００１０３」であるとする。また、ステップＳ３０１で得られたアカウント名と送信元電子メールアドレスが、それぞれ「ｎａｍｅ＿Ａ」と「ａ＠ｆｏｏ．ｃｏｍ」であるとする。

この場合、図６のメンバテーブル４０１ａによれば、「Ｆ０００１０３」というファイルＩＤと「ｎａｍｅ＿Ａ」というアカウント名のペアは登録済みである。しかし、「Ｆ０００１０３」というファイルＩＤと「ａ＠ｆｏｏ．ｃｏｍ」という送信元電子メールアドレスのペアは未登録である。よって、ステップＳ３０４で判定部２１４は、「Ｆ０００１０３」というファイルＩＤと「ａ＠ｆｏｏ．ｃｏｍ」という送信元電子メールアドレスのペアに対応するエントリをメンバテーブル４０１に追加する。

未登録のペアが２個以上ある場合も、判定部２１４は、同様にして、各ペアに対応するエントリをメンバテーブル４０１に追加する。その後、処理はステップＳ３０５に移行する。

ステップＳ３０５で判定部２１４は、ファイルＩＤと宛先電子メールアドレスの未注目のペアが残っているか否かを判定する。
ここで説明の便宜上、ステップＳ３０１で取得される（１１−３）の宛先電子メールアドレスの個数をＭとする（Ｍ≧１）。すると、Ｎ≧１かつＭ≧１なのでＭＮ≧１である。つまり、ファイルＩＤと宛先電子メールアドレスのペアはＭＮ通りある。

よって、判定部２１４は、ＭＮ個のペアのうち、ステップＳ３０６〜Ｓ３０８における処理対象としてまだ注目していないペアが残っているか否かを、ステップＳ３０５で判定する。

未注目ペアが残っていれば、処理はステップＳ３０６に移行する。逆に、ＭＮ個のすべてのペアが注目済みであれば、処理はステップＳ３０９に移行する。
ステップＳ３０６で判定部２１４は、ファイルＩＤと宛先電子メールアドレスの未注目ペアの一つに注目する。以下、説明の便宜上、ステップＳ３０６で注目されたペアの、ファイルＩＤと宛先電子メールアドレスを、それぞれ「注目ファイルＩＤ」と「注目電子メールアドレス」という。

次のステップＳ３０７で判定部２１４は、注目電子メールアドレスが、注目ファイルＩＤで識別されるファイルにとっての第三者か否かを判定する。具体的には、判定部２１４は、メンバテーブル４０１において、注目ファイルＩＤと注目電子メールアドレスを対応づけるエントリを検索する。

もし検索の結果としてエントリが見つかれば、注目電子メールアドレスは、注目ファイルＩＤで識別されるファイルにとっての非第三者である。つまり、当該ファイルを注目電子メールアドレスに宛てて送信することは、情報漏洩ではない。よって、処理はステップＳ３０５に戻る。

逆に、ステップＳ３０７での検索の結果、エントリが見つからなければ、注目電子メールアドレスは、注目ファイルＩＤで識別されるファイルにとっての第三者である。つまり、当該ファイルを注目電子メールアドレスに宛てて送信することは、情報漏洩にあたるおそれがある。よって、警告のために処理はステップＳ３０８に移行する。

ステップＳ３０８で判定部２１４は、警告リストを更新する。具体的には、判定部２１４は、注目ファイルＩＤと、注目ファイルＩＤに対応するファイル名と、注目電子メールアドレスの三つ組を、警告リストに追加する。なお、判定部２１４は、前述のとおり、ステップＳ３０１でファイルＩＤを取得する過程で、添付ファイルのファイル名とファイルＩＤの対応関係を記憶している。したがって、判定部２１４は、注目ファイルＩＤに対応するファイル名を認識しており、そのため、ステップＳ３０８で上記のとおり警告リストに要素を追加することができる。そして、警告リストの更新後、処理はステップＳ３０５に戻る。

他方、ファイルＩＤと宛先電子メールアドレスのＭＮ個のペアにすべて注目し終わると、判定部２１４は、警告リストが空か否かをステップＳ３０９で判定する。
警告リストが空の場合とは、すなわち、Ｍ個の宛先電子メールアドレスの各々が、Ｎ個の添付ファイルのすべてについてそれぞれ非第三者である場合である。この場合、情報漏洩のおそれはない。換言すれば、たとえ新規電子メールが送信されようとも（または、受信済みの電子メールが転送されようとも）、添付ファイルへのアクセスは、非第三者に対して提供されることはない。

よって、判定部２１４は、第三者への情報漏洩がないことを許可部２２３と登録部２１２に通知し、処理はステップＳ３１０に移行する。なお、ステップＳ３０９からステップＳ３１０への移行は、図１のステップＳ１０７からステップＳ１０５へのリンクに対応する。

逆に、警告リストが非空の場合とは、新規電子メールの送信または受信済みの電子メールの転送により、少なくとも一つの添付ファイルが、第三者からアクセス可能になってしまう場合である。つまり、警告リストが非空の場合、情報漏洩のおそれがある。

そこで、判定部２１４は警告リストを警告部２２１に出力し、処理はステップＳ３１１に移行する。なお、ステップＳ３０９からステップＳ３１１への移行は、図１のステップＳ１０７からステップＳ１０８へのリンクに対応する。

さて、ステップＳ３１０で許可部２２３は、電子メールの送信（つまり、新規電子メールの送信または受信済み電子メールの転送）を許可する。すると、当該電子メールはメールユーザエージェントにより送信される。

また、メールユーザエージェントは、当該電子メールを送信する際に、当該電子メールに新たなメッセージＩＤを割り当てる。そこで、ステップＳ３１０で登録部２１２は、割り当てられた新たなメッセージＩＤを読み取る。

そして、登録部２１２は、各添付ファイルについて、メッセージＩＤとファイルＩＤとファイル名の三つ組を、電子メール管理テーブル４０３に登録する。なお、登録部２１２は、添付ファイルのファイル名とファイルＩＤの対応関係を示す情報を、判定部２１４から取得してもよい。その後、図９の処理も終了する。

他方、ステップＳ３１１では、警告部２２１が、判定部２１４から受け取った警告リストにしたがって警告を出す。例えば、警告リストにファイルＩＤとファイル名と宛先電子メールアドレスの三つ組が４個含まれる場合、警告部２２１は、以下の（１３−１）〜（１３−３）を含むダイアログをクライアントＰＣ１１２の画面に表示してもよい。

（１３−１） 「以下の４通りの組み合わせで、第三者への情報漏洩のおそれがあります。本当にこの電子メールを送信しても構いませんか？」のような警告メッセージ。
（１３−２） 警告リストに含まれる各三つ組で対応づけられている、ファイル名と宛先電子メールアドレスのペア。
（１３−３） 警告メッセージに対する入力を受け付けるための、「はい」ボタンと「いいえ」ボタン。

なお、（１３−１）〜（１３−３）に例示したダイアログは、警告のためのＧＵＩ（Graphical User Interface）の一例に過ぎない。他のＧＵＩが使われてもよい。もちろん、警告部２２１は、音声的な警告を発してもよい。

また、警告部２２１は、警告を発するだけでなく、警告に対する入力を入力装置２４０から受け付けるように入力受付部２２２に命令する。すると、ステップＳ３１１で入力受付部２２２は入力装置２４０からの入力（例えば、（１３−３）の例では、「はい」ボタンまたは「いいえ」ボタンのクリック）を待つ。

警告に対する入力を入力受付部２２２が入力装置２４０から受け付けると、処理はステップＳ３１２に移行する。そして、ステップＳ３１２で入力受付部２２２は、受け付けた入力が、許可入力なのか、それとも禁止入力なのかを判断する。

禁止入力を入力受付部２２２が受け付けた場合、入力受付部２２２は禁止部２２４に通知を送る。そして、処理はステップＳ３１３に移行する。
逆に、許可入力を入力受付部２２２が受け付けた場合、入力受付部２２２は、非第三者への情報漏洩がないことを許可部２２３と登録部２１２に通知する。そして、処理はステップＳ３１４に移行する。

ステップＳ３１３で禁止部２２４は、電子メールの送信（具体的には、新規電子メールの送信または受信済み電子メールの転送）をやめる。つまり、禁止部２２４は、メールユーザエージェントによる当該電子メールの送信を禁止する。具体的には、禁止部２２４は、例えば、メールユーザエージェントに対してユーザから与えられた入力をキャンセルすることで、送信を禁止してもよい。そして、図９の処理は終了する。

他方、ステップＳ３１４で登録部２１２は、判定部２１４から警告リストを取得し、警告リストにしたがってメンバテーブル４０１にエントリを追加する。具体的には、登録部２１２は、警告リストに含まれる各三つ組（つまり、ファイルＩＤとファイル名と宛先電子メールアドレスの三つ組）について、当該三つ組で対応づけられているファイルＩＤと宛先電子メールアドレスのペアをメンバテーブル４０１に登録する。ステップＳ３１４でのメンバテーブル４０１への新たな非第三者の登録は、図１のステップＳ１１１での登録の具体例である。

例えば、警告リストに４個の三つ組が含まれる場合は、ステップＳ３１４で登録部２１２が４個のエントリをメンバテーブル４０１に追加する。そして、メンバテーブル４０１の更新後、処理はステップＳ３１０に移行する。

以上の図９の処理によれば、「ユーザの不注意により、非第三者宛ての電子メールにファイルが添付されて電子メールが送信され、その結果、情報が漏洩してしまう」という事態が防止される。また、図９の処理によれば、一または複数の非第三者にのみ送信されようとする電子メールに関しては、何の警告も発せられない。よって、「過剰な警告発生によりユーザの作業効率が落ちる」といった事態も回避される。

なお、図６の管理ＤＢ４００ｂは、以下の（１４−１）〜（１４−９）に説明する場合における、図９の処理の終了後の管理ＤＢ４００の例である。

（１４−１） 「ｎａｍｅ＿Ａ」というアカウント名のユーザが、新規電子メールを送信しようとしたことがトリガとなって、図９の処理が開始されたとする。
（１４−２） 図９の処理が開始される時点で、管理ＤＢ４００が図６の管理ＤＢ４００ａの状態であったとする。
（１４−３） 新規電子メールには、図６のファイル所在テーブル４０２ａに所在が示されているファイルのみが添付されており、他のファイルは添付されていないものとする。
（１４−４） 新規電子メールの送信元電子メールアドレスは「ａ＠ｆｏｏ．ｃｏｍ」であるとする。
（１４−５） 新規電子メールの宛先電子メールアドレスは「ｂ＠ｆｏｏ．ｃｏｍ」のみであるとする。
（１４−６） 上記（１４−１）〜（１４−４）より、図９のステップＳ３０４では、「Ｆ０００１０３」というファイルＩＤと「ａ＠ｆｏｏ．ｃｏｍ」という送信元電子メールアドレスを対応づけるエントリが、メンバテーブル４０１に追加される。
（１４−７） 上記（１４−２）、（１４−３）、（１４−５）より、図９のステップＳ３１１では、「Ｚ．ｔｘｔ」というファイル名の添付ファイルと「ｂ＠ｆｏｏ．ｃｏｍ」という宛先電子メールアドレスの組み合わせについて、警告が発せられる。
（１４−８） 警告に対して許可入力が与えられたとする。その結果、ステップＳ３１４では、「Ｆ０００１０３」というファイルＩＤと「ｂ＠ｆｏｏ．ｃｏｍ」という宛先電子メールアドレスを対応づけるエントリが、ファイル所在テーブル４０２に追加される。
（１４−９） ステップＳ３１０では、送信が許可された電子メールに、「Ｍ００００１５」というメッセージＩＤが割り当てられたとする。その結果、ステップＳ３１０では、「Ｍ００００１５」と「Ｆ０００１０３」を対応づけるエントリが、電子メール管理テーブル４０３に追加される。そして、図９の処理が終了する。

以上の（１４−１）〜（１４−９）に説明した場合に、管理ＤＢ４００は、図６の管理ＤＢ４００ａの状態から管理ＤＢ４００ｂの状態へと変化する。
さて次に、図１０を参照して、添付ファイルつきの電子メールの受信時に行われる添付ファイル登録処理について説明する。図１０の処理は、電子メールを受信したユーザを、当該電子メールの添付ファイルに関する非第三者として自動的に登録するための処理である。

例えば、添付ファイルつきの電子メールが、図２のクライアントＰＣ１２４から、メールサーバ１２１とネットワーク１２０とメールサーバ１１６を介して、クライアントＰＣ１１３において受信されるとする。または、添付ファイルつきの電子メールが、クライアントＰＣ１１４からメールサーバ１１６を介してクライアントＰＣ１１３において受信されるとする。

いずれの場合も、クライアントＰＣ１１３のユーザは、受信された電子メールの添付ファイルに関しての非第三者である。よって、クライアントＰＣ１１３における電子メールの受信時に、図１０の処理が行われ、非第三者の登録が行われる。

例えば、クライアントＰＣ１１３のユーザが、メールユーザエージェント上で、「受信」ボタンをクリックするなどの、電子メールの受信のための操作を行うと、検出部２１３がユーザによる操作を検出する。そして、検出部２１３は、電子メールの受信のための操作が行われたことを登録部２１２に通知する。

メールサーバ１１６の受信電子メールボックスが空であれば、電子メールは受信されない。よって、この場合、図１０の処理は不要であり、実行されない。
逆に、電子メールが１通以上受信された場合、検出部２１３からの通知を受けた登録部２１２は、受信された各電子メールについて、ファイルが添付されているか否かを調べ、ファイルが一つ以上添付されていれば図１０の処理を開始する。以下では説明の便宜上、Ｎ個のファイルが受信電子メールに添付されているとする（Ｎ≧１）。

具体的には、登録部２１２は、まずステップＳ４０１で以下の（１５−１）〜（１５−４）の各種情報を取得する。

（１５−１） 電子メールを受信するユーザのアカウント名。
（１５−２） 受信電子メールアドレス。
（１５−３） 受信電子メールのメッセージＩＤ。
（１５−４） Ｎ個の添付ファイルそれぞれのファイル名。

登録部２１２は、（１５−１）のアカウント名を、例えば、ＯＳにより予め用意されているシステム関数などを介して取得してもよい。
また、登録部２１２は、（１５−２）の受信電子メールアドレスをメールユーザエージェントから取得する。例えば、登録部２１２は、受信操作が行われる対象の電子メールボックスのプロパティから、受信電子メールアドレスを読み取ってもよい。

受信電子メールアドレスは、受信電子メールの「Ｔｏ」ヘッダフィールドに指定されていることもあり得るし、「ＣＣ」ヘッダフィールドに指定されていることもあり得る。あるいは、電子メールの送信時に「ＢＣＣ」ヘッダフィールドに指定されたアドレスが受信電子メールアドレスである場合、受信電子メールそのものには、受信電子メールアドレスが含まれないこともあり得る。

また、登録部２１２は、受信電子メールの「Ｍｅｓｓａｇｅ−ＩＤ」ヘッダフィールドから、（１５−３）のメッセージＩＤを読み取る。
また、受信電子メールは、Ｎ個の添付ファイルに対応するＮ個の「Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ」ヘッダフィールドを含む。よって、登録部２１２は、各「Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ」ヘッダフィールドから、各添付ファイルのファイル名を読み取る。

登録部２１２は、以上のようにしてステップＳ４０１で（１５−１）〜（１５−４）の情報を取得すると、次にステップＳ４０２で、取得したメッセージＩＤが電子メール管理テーブル４０３に登録されているか否かを判定する。そして、メッセージＩＤが電子メール管理テーブル４０３に登録されていれば、処理はステップＳ４０３に移行する。逆に、メッセージＩＤが電子メール管理テーブル４０３に登録されていなければ、処理はステップＳ４０４に移行する。

ステップＳ４０３は、図１０の処理を実行するクライアント（例えば図２のクライアントＰＣ１１３）を管理する管理サーバ１１７によって管理されている別のクライアント（例えばクライアントＰＣ１１２）からの電子メールが受信された場合に、実行される。換言すれば、ステップＳ４０３は、図１のステップＳ１０１における生成元の登録が済んでいる場合に実行される。

例えば、クライアントＰＣ１１２からクライアントＰＣ１１３に電子メールが送信されたとする。この場合、クライアントＰＣ１１２における図９の処理の結果として、管理サーバ１１７の管理ＤＢ４００内の電子メール管理テーブル４０３には、当該電子メールに関するエントリが追加される。したがって、電子メールを受信するクライアントＰＣ１１３が図１０の処理を行うと、ステップＳ４０２で電子メール管理テーブル４０３にエントリが見つかる。

そこで、ステップＳ４０３で登録部２１２は、受信電子メールに添付されている各ファイルのファイルＩＤを、電子メール管理テーブル４０３から取得する。登録部２１２は、各添付ファイルについて、ステップＳ４０１で取得した当該ファイルのファイル名と、ステップＳ４０１で取得したメッセージＩＤとを検索キーにして、電子メール管理テーブル４０３を検索することで、ファイルＩＤを取得する。そして、登録部２１２がＮ個の添付ファイルのファイルＩＤをすべて取得すると、処理はステップＳ４０５に移行する。

他方、ステップＳ４０４が実行されるのは、図１０を実行するクライアント（例えば図２のクライアントＰＣ１１３）を管理する管理サーバ１１７によって管理されない、イントラネット外のホストからの電子メールが受信された場合である。

例えば、クライアントＰＣ１２４から、メールサーバ１２１とネットワーク１２０とメールサーバ１１６を介して、クライアントＰＣ１１３に電子メールが送信されたとする。
この場合、クライアントＰＣ１２４は、管理サーバ１１７が管理する対象のＬＡＮ１１０の外部のホストである。よって、クライアントＰＣ１２４が電子メールを送信しても、それだけでは管理サーバ１１７の管理ＤＢ４００は変化しない。

つまり、管理ＤＢ４００には、クライアントＰＣ１２４から送信された電子メールに関するデータがまだ存在しない。したがって、電子メールを受信するクライアントＰＣ１１３が図１０の処理を行うと、ステップＳ４０２ではエントリが見つからない。

そこで、ステップＳ４０４で登録部２１２は、受信電子メールに添付されている各ファイルに対して、以下の（１６−１）と（１６−２）の処理を行う。

（１６−１） 新たなファイルＩＤを発行する処理。
（１６−２） ステップＳ４０１で取得したメッセージＩＤと、（１６−１）の処理により発行した新たなファイルＩＤと、ステップＳ４０１で取得した当該ファイルのファイル名とを対応づける新たなエントリを、電子メール管理テーブル４０３に追加する処理。

なお、（１６−１）の登録部２１２によるファイルＩＤの発行は、図５のステップＳ２０２における生成元認識部２１１によるファイルＩＤの発行と同様である。つまり、登録部２１２は、ＬＡＮ１１０内で一意なファイルＩＤを生成する。あるいは、実施形態によっては、登録部２１２は、ＬＡＮ１１０内で一意なファイルＩＤの発行を管理サーバ１１７に要求し、管理サーバ１１７からファイルＩＤを取得してもよい。

ステップＳ４０４でのファイルＩＤの発行は、図１のステップＳ１０１における生成元の登録のための前処理でもある。また、受信電子メールにＮ個のファイルが添付されている場合、（１６−２）の処理により、Ｎ個の新たなエントリが電子メール管理テーブル４０３に追加される。そして、ステップＳ４０４での（１６−１）と（１６−２）の処理の後、ステップＳ４０５の処理が実行される。

ステップＳ４０５で登録部２１２は、受信電子メールのＮ個の添付ファイルのうちで、ステップＳ４０６以降の処理の対象としてまだ注目していない添付ファイルが残っているか否かを判断する。そして、未注目の添付ファイルが残っていれば、処理はステップＳ４０６に移行する。逆に、登録部２１２がＮ個の添付ファイルすべてに注目済みであれば、図１０の処理は終了する。

ステップＳ４０６で登録部２１２は、未注目の添付ファイルのうちの一つに注目する。以下では説明の便宜上、ステップＳ４０６で注目された添付ファイルを「注目添付ファイル」という。

そして、次のステップＳ４０７で登録部２１２は、「ステップＳ４０１で取得したアカウント名が、注目添付ファイルのファイルＩＤと対応づけられているか否か」を判断する。つまり、登録部２１２は、「取得したアカウント名が、注目添付ファイルの非第三者としてメンバテーブル４０１に登録済みか否か」を判断する。具体的には、登録部２１２は、注目添付ファイルのファイルＩＤとステップＳ４０１で取得したアカウント名とを検索キーにして、メンバテーブル４０１を検索する。

検索の結果、エントリが見つかれば、取得したアカウント名は、注目添付ファイルの非第三者としてメンバテーブル４０１に登録済みである。よって、処理はステップＳ４０９に移行する。

逆に、検索の結果、エントリが見つからなければ、取得したアカウント名は、注目添付ファイルの非第三者としてまだ登録されていない。よって、登録のために処理はステップＳ４０８に移行する。

そして、ステップＳ４０８で登録部２１２は、注目添付ファイルのファイルＩＤと取得したアカウント名とのペアをメンバテーブル４０１に登録する。すなわち、登録部２１２は、当該ペアに対応する新たなエントリをメンバテーブル４０１に追加する。そして、処理はステップＳ４０９へ移行する。

ステップＳ４０９で登録部２１２は、「ステップＳ４０１で取得した受信電子メールアドレスが、注目添付ファイルのファイルＩＤと対応づけられているか否か」を判断する。つまり、登録部２１２は、「受信電子メールアドレスが、注目添付ファイルの非第三者としてメンバテーブル４０１に登録済みか否か」を判断する。具体的には、登録部２１２は、注目添付ファイルのファイルＩＤと受信電子メールアドレスとを検索キーにして、メンバテーブル４０１を検索する。

検索の結果、エントリが見つかれば、受信電子メールアドレスは、注目添付ファイルの非第三者としてメンバテーブル４０１に登録済みである。よって、処理はステップＳ４０５に戻る。

逆に、検索の結果、エントリが見つからなければ、受信電子メールアドレスは、注目添付ファイルの非第三者としてまだ登録されていない。よって、登録のために処理はステップＳ４１０に移行する。

そして、ステップＳ４１０で登録部２１２は、注目添付ファイルのファイルＩＤと受信電子メールアドレスのペアをメンバテーブル４０１に登録する。すなわち、登録部２１２は、当該ペアに対応する新たなエントリをメンバテーブル４０１に追加する。そして、処理はステップＳ４０５に戻る。

以上の図１０の処理によれば、電子メールの受信者（recipient）が、当該電子メールに添付されている各ファイルについて非第三者として自動的に登録される。また、登録は、受信者のアカウント名に関して行われるとともに、受信者の電子メールアドレスに関しても行われる。

なお、電子メールは必ず読まれるとは限らず、添付ファイルも必ず保存されるとは限らないことに注意されたい。例えば、受信者たるユーザは、電子メールを受信するとすぐに添付ファイルをローカルに保存するかもしれないし、後日、必要に応じて添付ファイルをローカルに保存するかもしれないし、添付ファイルを保存しないかもしれない。図１０の処理は、将来添付ファイルが保存されるかどうかに関わりなく、電子メールが受信されたときに実行される。

また、図７の管理ＤＢ４００ｃは、以下の（１７−１）〜（１７−８）に説明する場合における、図１０の処理の終了後の管理ＤＢ４００の例である。

（１７−１） 「ｎａｍｅ＿Ｂ」というアカウント名でクライアントＰＣ１１３を使用するユーザが、電子メールを受信するための操作を行ったとする。
（１７−２） 上記（１７−１）の操作の結果、１通の電子メールのみが受信されたとする。すると、この１通の電子メールに関して、図１０の処理が開始される。
（１７−３） 受信電子メールは、具体的には、図６の管理ＤＢ４００ｂに関して（１４−１）〜（１４−９）で説明した電子メールであるものとする。
（１７−４） 図１０の処理が開始される時点で、管理ＤＢ４００が図６の管理ＤＢ４００ｂの状態であったとする。
（１７−５） 上記（１７−１）と（１７−３）より、図１０のステップＳ４０１では、以下の情報が取得される。
・「ｎａｍｅ＿Ｂ」というアカウント名
・「ｂ＠ｆｏｏ．ｃｏｍ」という受信電子メールアドレス
・「Ｍ００００１５」というメッセージＩＤ
・「Ｚ．ｔｘｔ」というファイル名
（１７−６） 上記（１７−４）と（１７−５）と図６の電子メール管理テーブル４０３ｂより、ステップＳ４０２ではエントリが見つかる。その結果、ステップＳ４０３では「Ｆ０００１０３」というファイルＩＤがファイル電子メール管理テーブル４０３ｂから取得される。
（１７−７） 上記（１７−４）と（１７−５）と図６のメンバテーブル４０１ｂより、ステップＳ４０７では、「ｎａｍｅ＿Ｂ」がまだ非第三者として「Ｆ０００１０３」に対応づけられていないことが判明する。その結果、ステップＳ４０８では、「ｎａｍｅ＿Ｂ」を「Ｆ０００１０３」に対応づけるエントリが、メンバテーブル４０１に追加される。
（１７−８） 上記（１７−４）と（１７−５）と図６のメンバテーブル４０１ｂより、ステップＳ４０９では、「ｂ＠ｆｏｏ．ｃｏｍ」が既に非第三者として「Ｆ０００１０３」に対応づけられていることが判明する。その結果、ステップＳ４１０は実行されず、処理はステップＳ４０９からステップＳ４０５へと戻る。そして、図１０の処理が終了する。

以上の（１７−１）〜（１７−８）に説明した場合に、管理ＤＢ４００は、図６の管理ＤＢ４００ｂの状態から図７の管理ＤＢ４００ｃの状態へと変化する。
さて次に、図１１を参照して、電子メールの添付ファイルがローカルに保存されるときに行われる所在登録処理について説明する。図１０に関して述べたとおり、添付ファイルは、電子メールが受信されてすぐに保存されるとは限らず、添付ファイルの保存は任意のタイミングで生じ得る。よって、図１１の処理は、受信済みの任意の電子メールに関して、任意のタイミングで実行され得る。

図１１に関しても、図１０と同様に、便宜上、クライアントＰＣ１１３を例に説明を行う。クライアントＰＣ１１３のユーザが、メールユーザエージェント上で、ある電子メールの１個以上の添付ファイルを保存するための添付ファイル保存操作を行うと、検出部２１３がユーザによる操作を検出する。添付ファイル保存操作は、具体的には、例えば以下の（１８−１）〜（１８−４）のように複数の操作を含む操作であってもよい。

（１８−１） 「添付ファイルの保存」メニューを選択する操作。
（１８−２） 電子メールに添付されているＮ個（１≦Ｎ）の添付ファイルの中から、保存対象のＬ個（１≦Ｌ≦Ｎ）の添付ファイルを選択する操作。
（１８−３） Ｌ個の添付ファイルの保存先のフォルダのパスを指定する操作。
（１８−４） 「保存」ボタンをクリックする操作。

そして、検出部２１３は、添付ファイル保存操作を検出すると、添付ファイル保存操作が検出されたことを登録部２１２に通知する。すると、登録部２１２が図１１の処理を開始する。なお以下では説明の便宜上、上記（１８−２）の例示と同様に、電子メールにＮ個（１≦Ｎ）のファイルが添付されており、そのうちＬ個（１≦Ｌ≦Ｎ）の添付ファイルの保存がユーザから指示されたものとする。

ステップＳ５０１で登録部２１２は、保存を指示されたＬ個の添付ファイルのうち、ステップＳ５０２〜Ｓ５０４の処理の対象としてまだ注目していない添付ファイルが残っているか否かを判断する、そして、未注目の添付ファイルが残っていれば、処理はステップＳ５０２に移行する。逆に、登録部２１２がＬ個の添付ファイルすべてに注目済みであれば、図１１の処理は終了する。

ステップＳ５０２で登録部２１２は、未注目の添付ファイルのうちの一つに注目する。以下では説明の便宜上、ステップＳ５０２で注目された添付ファイルを「注目添付ファイル」という。

そして、次のステップＳ５０３で登録部２１２は、以下の（１９−１）〜（１９−３）の各種情報を取得する。

（１９−１） 注目添付ファイルのファイルＩＤ。
（１９−２） 保存対象のＬ個の添付ファイルを保存するマシン（すなわち図１１の処理を実行するマシン）のホスト名。
（１９−３） 注目添付ファイルの保存先のフルパス。

なお、登録部２１２は、図１１の処理の対象の電子メールのメッセージＩＤと、注目添付ファイルのファイル名とを検索キーにして、電子メール管理テーブル４０３を検索することで、（１９−１）のファイルＩＤを取得する。具体的には以下のとおりである。

登録部２１２は、電子メールの「Ｍｅｓｓａｇｅ−ＩＤ」ヘッダフィールドからメッセージＩＤを読み取ることができ、電子メールの「Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ」ヘッダフィールドから添付ファイルのファイル名を読み取ることができる。つまり登録部２１２は電子メールから電子メール管理テーブル４０３の検索のための検索キーを取得することができる。

また、検索の結果として、必ずエントリが見つかる。なぜなら、電子メールが送信されたときに図９のステップＳ３１０でエントリが既に追加されているか、または、電子メールが受信されたときに図１０のステップＳ４０４でエントリが既に追加されているからである。したがって、登録部２１２は、電子メール管理テーブル４０３から（１９−１）のファイルＩＤを取得することができる。

また、登録部２１２は、例えば、ＯＳにより予め用意されているシステム関数などを介して、（１９−２）のホスト名を取得する。さらに、登録部２１２は、メールユーザエージェント上で指定された保存先のフォルダのフルパスに、注目添付ファイルのファイル名を連結することで、（１９−３）のフルパスを取得する。

そして、次のステップＳ５０４で登録部２１２は、ステップＳ５０３で取得した情報にしたがって、注目添付ファイルの所在情報をファイル所在テーブル４０２に登録する。すなわち、登録部２１２は、（１９−１）〜（１９−３）を対応づける新たなエントリをファイル所在テーブル４０２に追加する。そして、処理はステップＳ５０１に戻る。

ところで、図７の管理ＤＢ４００ｄは、以下の（２０−１）〜（２０−６）に説明する場合における、図１１の処理の終了後の管理ＤＢ４００の例である。

（２０−１） 図７の管理ＤＢ４００ｃに関して（１７−１）〜（１７−８）で説明した、クライアントＰＣ１１３において受信済みの電子メールに関して、クライアントＰＣ１１３のユーザが、添付ファイル保存操作を行ったとする。すると、添付ファイル保存操作をトリガとして、図１１の処理が開始される。なお、（１７−３）と（１４−３）より、当該電子メールには１個しかファイルが添付されていない。
（２０−２） 図１１の処理が開始される時点で、管理ＤＢ４００が図７の管理ＤＢ４００ｃの状態であったとする。
（２０−３） 上記（２０−１）と（２０−２）より、図１１のステップＳ５０３では、「Ｆ０００１０３」というファイルＩＤが取得される。
（２０−４） クライアントＰＣ１１３のホスト名は「ＰＣ＿Ｂ」であるとする。よって、ステップＳ５０３では「ＰＣ＿Ｂ」というホスト名が取得される。
（２０−５） 上記（２０−１）の添付ファイル保存操作において、ユーザが、保存先のフォルダとして、「Ｃ：＼ｐａｔｈ＿Ｂ」というフルパスで識別されるフォルダを指定したとする。また、（２０−１）と（２０−２）より、添付ファイルのファイル名は「Ｚ．ｔｘｔ」である。よって、ステップＳ５０３では添付ファイルの保存先のフルパスとして、「Ｃ：＼ｐａｔｈ＿Ｂ＼Ｚ．ｔｘｔ」が取得される。
（２０−６） したがって、（２０−３）のファイルＩＤと（２０−４）のホスト名と（２０−５）のフルパスを対応づける新たなエントリが、ステップＳ５０４でファイル所在テーブル４０２に追加される。

以上の（２０−１）〜（２０−６）に説明した場合に、管理ＤＢ４００は、図７の管理ＤＢ４００ｃの状態から管理ＤＢ４００ｄの状態へと変化する。そして、例えば（２０−６）のような、図１１の処理によるエントリの追加は、非第三者間でファイルの編集を重ねながら何度もファイルをやりとりする場合に、過剰な警告の発生を防ぐ効果がある。その理由を、具体例を用いて説明すれば、以下のとおりである。

上記（２０−６）でのエントリの追加後、クライアントＰＣ１１３のユーザは、「Ｃ：＼ｐａｔｈ＿Ｂ＼Ｚ．ｔｘｔ」に保存した添付ファイルを編集して上書き保存するかもしれない。そして、クライアントＰＣ１１３のユーザは、編集したファイルを新たな電子メールに添付し、新たな電子メールをクライアントＰＣ１１２のユーザ宛に（すなわち、「ａ＠ｆｏｏ．ｃｏｍ」という電子メールアドレス宛に）送信しようとするかもしれない。

すると、クライアントＰＣ１１３では図９の処理が行われる。この場合、図９のステップＳ３０１では、かつてクライアントＰＣ１１３が図１１の処理を行ったときに（２０−６）でファイル所在テーブル４０２に追加されたエントリから、「Ｆ０００１０３」というファイルＩＤが得られる。

したがって、図９の処理によれば、「Ｃ：＼ｐａｔｈ＿Ｂ＼Ｚ．ｔｘｔ」に上書き保存された編集後のファイルに関しても、「ａ＠ｆｏｏ．ｃｏｍ」という宛先電子メールアドレスが、非第三者であると判定される。よって、もし宛先電子メールアドレスが「ａ＠ｆｏｏ．ｃｏｍ」のみであれば、警告は発生しない。

つまり、「ａ＠ｆｏｏ．ｃｏｍ」と「ｂ＠ｆｏｏ．ｃｏｍ」という二つの電子メールアドレスにより示される非第三者間で電子メールを介して上記ファイルがやりとりされる場合は、２回目以降の送信では警告が発生しない。よって、第１実施形態によれば、不注意に起因する情報漏洩が防げるだけでなく、「過剰な警告発生により、非第三者間での情報のやりとりが邪魔される」という事態も防げる。

また、あるファイルに関する非第三者の中には、例えばクライアントＰＣ１２４のような、ＬＡＮ１１０（すなわち管理サーバ１１７が管理する範囲）の外部に存在する非第三者が含まれるかもしれない。図５〜１１の説明から明らかなとおり、このような外部の非第三者と内部の非第三者との間で電子メールを介してファイルがやりとりされる場合も、ＬＡＮ１１０内部の非第三者間でファイルがやりとりされる場合と同様に、過剰な警告の発生が抑制される。

また、上記の例のように「ａ＠ｆｏｏ．ｃｏｍ」と「ｂ＠ｆｏｏ．ｃｏｍ」という二つの電子メールアドレスにより示される非第三者間で電子メールを介して上記ファイルがやりとりされるだけでなく、さらに電子メールが転送されることもある。例えば、図８の管理ＤＢ４００ｅは、そのような転送が行われた場合における管理ＤＢ４００の例である。より具体的には、以下の（２１−１）〜（２１−８）に説明する場合、管理ＤＢ４００は図８の管理ＤＢ４００ｅのように変化する。

（２１−１） クライアントＰＣ１１３のユーザが、（１７−１）〜（１７−８）で説明した電子メール（つまり、クライアントＰＣ１１３で受信済みの電子メール）を転送するための操作を行ったとする。
（２１−２） 上記（２１−１）の操作は、管理ＤＢ４００が図７の管理ＤＢ４００ｄの状態のときに行われたとする。
（２１−３） 転送先の電子メールアドレスは「ｃ＠ｂａｒ．ｏｒｇ」であるものとする。なお、「ｂａｒ．ｏｒｇ」というドメインは、図２の管理サーバ１１７が管理するＬＡＮ１１０の外部であるものとする。また、「ｃ＠ｂａｒ．ｏｒｇ」というアドレス宛の電子メールは、具体的には、図２のクライアントＰＣ１２４において受信されるものとする。
（２１−４） 上記（２１−１）のユーザ操作の検出に応じて、クライアントＰＣ１１３では、図９の処理が行われる。すると、（２１−１）〜（２１−２）と図７より、「ｃ＠ｂａｒ．ｏｒｇ」という電子メールアドレスと「Ｚ．ｔｘｔ」というファイル名の添付ファイルの組み合わせに対する警告が、図９のステップＳ３１１で出される。
（２１−５） 上記（２１−４）の警告に対し、クライアントＰＣ１１３のユーザが許可入力を与えたとする。
（２１−６） 上記（２１−５）の許可入力の結果、ステップＳ３１４では、「Ｚ．ｔｘｔ」というファイル名に対応する「Ｆ０００１０３」というファイルＩＤと、「ｃ＠ｂａｒ．ｏｒｇ」という電子メールアドレスとを対応づけるエントリが、メンバテーブル４０１に追加される。
（２１−７） また、ステップＳ３１０では、「ｃ＠ｂａｒ．ｏｒｇ」という電子メールアドレス宛に当該電子メールが転送される。なお、転送されるときに電子メールに割り当てられたメッセージＩＤが「Ｍ００００２１」であるものとする。
（２１−８） ステップＳ３１０ではさらに、「Ｍ００００２１」というメッセージＩＤと「Ｆ０００１０３」というファイルＩＤと「Ｚ．ｔｘｔ」というファイル名とを対応づけるエントリが、電子メール管理テーブル４０３に追加される。

以上の（２１−１）〜（２１−８）に説明した場合に、管理ＤＢ４００は、図７の管理ＤＢ４００ｄの状態から図８の管理ＤＢ４００ｅの状態へと変化する。すると、ＬＡＮ１１０の外部のユーザ（具体的には「ｃ＠ｂａｒ．ｏｒｇ」という電子メールアドレスで識別されるユーザ）も、上記ファイルの非第三者として新たに登録される。

ところで、以上説明したように、第１実施形態においては、図３のファイル識別情報２３１の具体例としてファイルＩＤが利用される。
ファイル識別情報２３１としての適切さという観点から検討すると、例えば単なるファイル名は、不適当である。なぜなら、ファイル名だけでは、同名の別ファイル同士を区別できないからである。

他方、ファイルの所在を示すフルパスならば、１台のホスト内の異なるフォルダにある同名の別ファイル同士を区別することが可能である。よって、図２のシステム２００がスタンドアロンシステムとして実現される場合（例えば後述の第３実施形態）には、ファイルのフルパスがファイル識別情報２３１として利用されてもよい。

しかし、クライアントサーバシステムとしてシステム２００が実現される第１実施形態では、ファイル識別情報２３１として、フルパスではなくファイルＩＤが利用される。上記のとおりファイルＩＤは管理サーバ１１７が管理するＬＡＮ１１０内で一意である。つまり、ファイルＩＤを利用することで、異なるホストの同じフルパスにある異なるファイル同士を区別することが可能となる。

ところで、上記のようなファイルＩＤを利用することの別の利点の一つは、電子メールに添付されてやりとりされるファイルの継続性の管理が可能になることである。そして、ファイルの継続性が管理可能だと、過剰な警告の発生を防ぐことができ、ユーザの作業を妨げずにすむ。

例えば、クライアントＰＣ１１４で新たに生成されたファイルが、電子メールに添付されてクライアントＰＣ１１２と１２４に送信され、クライアントＰＣ１１２と１２４でそれぞれ編集されるかもしれない。その後、クライアントＰＣ１１２と１２４からそれぞれ、編集後のファイルを添付した電子メールが、クライアントＰＣ１１４宛に送信されるかもしれない。

例えば以上のような状況では、元は同じファイルが、以下の（２２−１）〜（２２−１０）のような異なる状態をとり得る。そして、管理サーバ１１７は、（２２−７）と（２２−８）の状態を感知することはできないが、（２２−１）〜（２２−６）と（２２−９）〜（２２−１０）の状態に関しては、当該ファイルを同じ一つのファイルＩＤにより識別する。

（２２−１） クライアントＰＣ１１４で生成されて、クライアントＰＣ１１４にローカルに保存された状態のファイル。
（２２−２） クライアントＰＣ１１４からクライアントＰＣ１１２と１２４に送信される電子メールに添付された状態のファイル。
（２２−３） クライアントＰＣ１１２で受信した（２２−２）の電子メールから取り出されて、クライアントＰＣ１１２内にローカルに保存された状態のファイル。
（２２−４） 上記（２２−３）の保存の後に、クライアントＰＣ１１２において編集されて、上書き保存された状態のファイル。
（２２−５） 上記（２２−４）の上書き保存の後に、クライアントＰＣ１１２からクライアントＰＣ１１４に送信される電子メールに添付された状態のファイル。
（２２−６） クライアントＰＣ１１４で受信した（２２−５）の電子メールから取り出されて、クライアントＰＣ１１４内にローカルに保存された状態のファイル。なお、この（２２−６）における保存は、（２２−１）のファイルに対する上書き保存であってもよいし、（２２−１）とは別の場所への保存であってもよい。
（２２−７） クライアントＰＣ１２４で受信した（２２−２）の電子メールから取り出されて、クライアントＰＣ１２４内にローカルに保存された状態のファイル。
（２２−８） 上記（２２−７）の保存の後に、クライアントＰＣ１２４において編集されて、上書き保存された状態のファイル。
（２２−９） 上記（２２−８）の上書き保存の後に、クライアントＰＣ１２４からクライアントＰＣ１１４に送信される電子メールに添付された状態のファイル。
（２２−１０） クライアントＰＣ１１４で受信した（２２−９）の電子メールから取り出されて、クライアントＰＣ１１４内にローカルに保存された状態のファイル。なお、この（２２−１０）における保存も、（２２−１）のファイルに対する上書き保存であってもよいし、（２２−１）とは別の場所への保存であってもよい。

以上の例のように、第１実施形態では、同じ一つのファイルに対して次々と行われるいくつもの操作（例えば、ローカル保存、編集、電子メールに添付しての送信、など）を経ても、当該ファイルは、継続して同じファイルＩＤで管理され続ける。また、通常は、あるファイルについての非第三者は、当該ファイルに対して何らかの操作が行われても、当該ファイルについて非第三者であり続ける。そして、ファイルが継続して同じファイルＩＤで管理されると、結果として、非第三者も継続して非第三者として認識される。したがって、ファイルに対して次々と操作が行われたとしても、「操作のたびに警告が発生する」というような警告の過剰発生には陥らない。このように、ファイルＩＤをファイル識別情報２３１として利用することは、過剰な警告を防ぐうえでも有益である。

以上説明したように、ファイルＩＤをファイル識別情報２３１として利用することには利点がある。そして、もし以下に説明する図１２の処理がさらに行われれば、ファイルＩＤの利用により、さらなるファイルの追跡も可能となる。つまり、図１２の処理とファイルＩＤの利用により、「たとえファイルが複写、移動、または変名（rename）されても、ファイルを追跡してファイルの継続性を管理する」という機能が実現される。

図１２は、ファイルの複写、移動または変名時に行われる所在更新処理のフローチャートである。なお、図１２の説明における複写、移動または変名は、ある１台のホストの内部でローカルに行われる操作であるものとする。

図１２の処理は、検出部２１３が、ファイルの複写、移動または変名のための操作を検出したときに開始される。図１２の処理のトリガとして検出部２１３が検出する操作の具体例は、例えば、以下の（２３−１）〜（２３−７）などの操作である。

（２３−１） ＯＳにより提供されるコマンドによる、ファイルの複写（例えば、「ｃｏｐｙ」コマンドによるファイルの複写）。
（２３−２） ＯＳにより提供されるＧＵＩによる、ファイルの複写（例えば、ファイルのアイコンをコピーアンドペーストする操作による、ファイルの複写）。
（２３−３） ＯＳにより提供されるコマンドによる、ファイルの移動（例えば、「ｍｏｖｅ」コマンドによるファイルの移動）。
（２３−４） ＯＳにより提供されるＧＵＩによる、ファイルの移動（例えば、ファイルのアイコンをドラッグアンドドロップする操作、または、ファイルのアイコンをカットアンドペーストする操作による、ファイルの移動）。
（２３−５） ＯＳにより提供されるコマンドによる、ファイルの変名（例えば、「ｍｏｖｅ」コマンドによるファイルの変名）。
（２３−６） ＯＳにより提供されるＧＵＩによる、ファイルの変名（例えば、ファイルのアイコンを選択してプロパティ中のファイル名を書き換える操作による、ファイルの変名）。
（２３−７） アプリケーションソフトウェアによる、ファイルの複写、移動、または変名（例えば、既存のファイルをアプリケーションソフトウェアで開き、ファイルを別名で保存する操作による、ファイルの複写）。

検出部２１３は、例えば、コマンドの呼び出しやＡＰＩ関数の呼び出しをフックすることで、ファイルの複写、移動または変名のための（２３−１）〜（２３−７）のような操作を検出してもよい。検出の具体的方法が何であれ、検出部２１３は、ファイルの複写、移動または変名のための操作を検出すると、検出した操作の内容を登録部２１２に通知する。すると、登録部２１２が図１２の処理を開始する。

そして、ステップＳ６０１で登録部２１２は、以下の（２４−１）〜（２４−４）の情報を取得する。

（２４−１） 複写、移動、または変名の操作が行われるマシンのホスト名（すなわち、複写、移動、または変名のための入力が与えられるマシンのホスト名）。
（２４−２） 操作対象の元のファイルのフルパス。
（２４−３） 操作対象の元のファイルのファイルＩＤ。
（２４−４） ファイルの新たなフルパス（すなわち、複写先、移動先、または変名後のフルパス）。

登録部２１２は、例えば、ＯＳにより予め用意されているシステム関数などを介して、（２４−１）のホスト名を取得する。例えば、「ＰＣ＿Ａ」というホスト名のクライアントＰＣ１１２において図１２の処理が行われる場合、登録部２１２は、「ＰＣ＿Ａ」というホスト名を取得する。

また、上記のとおり、図１２の処理の開始のトリガとして検出部２１３が検出した操作の内容は、検出部２１３から登録部２１２に通知される。したがって、登録部２１２は、検出部２１３からの通知により、（２４−２）と（２４−４）の情報を認識することができる。

なお、検出部２１３自体は、例えば以下のようにして、（２４−２）と（２４−４）の情報を取得することができる。したがって、検出部２１３は、（２４−２）と（２４−４）の情報を登録部２１２に通知することができる。

例えば、ＯＳにより提供されるコマンドによってファイルが複写、移動、または変名される場合、検出部２１３は、コマンドの引数とカレントフォルダのフルパスから、（２４−２）と（２４−４）の情報を取得してもよい。あるいは、検出部２１３は、ファイルの複写、移動、または変名のために呼び出されるＡＰＩ関数の引数から、（２４−２）と（２４−４）の情報を取得してもよい。

また、登録部２１２は、（２４−１）のホスト名と（２４−２）のフルパスを検索キーにしてファイル所在テーブル４０２を検索することで、（２４−３）のファイルＩＤを取得する。

例えば、「ＰＣ＿Ｂ」というホスト名のクライアントＰＣ１１３において、「Ｃ：＼ｐａｔｈ＿Ｂ＼Ｚ．ｔｘｔ」というフルパスで所在が示されるファイルが、「Ｃ：＼ｐａｔｈ＿Ｂ＼ｔｍｐ＼Ｚ２．ｔｘｔ」へと複写されるとする。また、ファイル所在テーブル４０２が、具体的には図７のファイル所在テーブル４０２ｄの状態であるとする。

この場合、（２４−１）のホスト名は「ＰＣ＿Ｂ」であり、（２４−２）のフルパスは「Ｃ：＼ｐａｔｈ＿Ｂ＼Ｚ．ｔｘｔ」である。また、（２４−３）のファイルＩＤは「Ｆ０００１０３」であり、（２４−４）のフルパスは「Ｃ：＼ｐａｔｈ＿Ｂ＼ｔｍｐ＼Ｚ２．ｔｘｔ」である。

登録部２１２は、例えば以上のようにして、ステップＳ６０１で（２４−１）〜（２４−４）の情報を取得する。
すると、ステップＳ６０２で登録部２１２は、操作の種類を判断する。操作の種類が移動または変名の場合、処理はステップＳ６０３に移行する。逆に、操作の種類が複写の場合、処理はステップＳ６０４に移行する。

ステップＳ６０３で登録部２１２は、ファイルＩＤと元のファイルの所在情報を対応づけるエントリを、ファイル所在テーブル４０２から削除する。
ここで、元のファイルの所在情報は、具体的には、ステップＳ６０１で得られた（２４−１）のホスト名と（２４−２）のフルパスの組み合わせにより示される。よって、登録部２１２は、（２４−３）のファイルＩＤと（２４−１）のホスト名と（２４−２）のフルパスを検索キーにして、ファイル所在テーブル４０２を検索する。そして、登録部２１２は、検索の結果として見つかる一つのエントリを削除する。その後、処理はステップＳ６０４に移行する。

ステップＳ６０４で登録部２１２は、ファイルＩＤと新たな所在情報を対応づけるエントリを、ファイル所在テーブル４０２に追加する。ここで、新たな所在情報は、具体的には、ステップＳ６０１で得られた（２４−１）のホスト名と（２４−４）のフルパスの組み合わせにより示される。よって、登録部２１２は、（２４−３）のファイルＩＤと（２４−１）のホスト名と（２４−４）のフルパスを対応づける新たなエントリを、ファイル所在テーブル４０２に追加する。そして、図１２の処理は終了する。

ところで、図３の記憶装置２３０の有効利用のためには、管理ＤＢ４００内の不要なエントリが削除されてもよい。具体的には、図１３の処理が行われてもよい。
図１３は、ファイルが削除されるときに行われるエントリ削除処理のフローチャートである。例えばクライアントＰＣ１１２は、クライアントＰＣ１１２内にローカルに保存されているファイルが削除されようとするときに、図１３の処理を実行する。

ＯＳは、ファイル削除のために、「ｄｅｌ」コマンドなどのコマンドや、「ゴミ箱」を空にするメニューなどを提供する。よって、検出部２１３は、ファイル削除のために提供されているこれらのコマンドやメニューの呼び出しを検出すると、検出した呼び出しの内容を登録部２１２に通知する。そして、登録部２１２が図１３の処理を開始する。なお、検出部２１３は、上記のコマンドやメニューの呼び出しを検出するために、例えばフックを利用してもよい。

さて、ステップＳ７０１で登録部２１２は、下記（２５−１）〜（２５−３）の情報を取得する。

（２５−１） 削除されようとしているファイルを保存しているマシンのホスト名
（２５−２） 削除されようとしている当該ファイルのフルパス
（２５−３） 削除されようとしている当該ファイルのファイルＩＤ

例えば、クライアントＰＣ１１２の登録部２１２は、ＯＳにより予め用意されているシステム関数などを介して、（２５−１）のホスト名（すなわちクライアントＰＣ１１２のホスト名である「ｎａｍｅ＿Ａ」）を取得してもよい。

また、登録部２１２は、検出部２１３から通知された内容から、（２５−２）のフルパスを取得する。
なお、検出部２１３自体は、例えば、ファイルを削除するためのコマンドの引数とカレントフォルダのフルパスから、（２５−２）のフルパスを認識してもよい。また、ある種のＯＳによれば、「ゴミ箱」内のファイルには、当該ファイルがもともと置かれていたフォルダのフルパスを示す情報が対応づけられている。よって、検出部２１３は、例えばＯＳを介して、（２５−２）のフルパスを取得してもよい。いずれにせよ、検出部２１３は、（２５−２）のフルパスを認識して、登録部２１２に通知することができる。

また、登録部２１２は、（２５−１）のホスト名と（２５−２）のフルパスを検索キーとしてファイル所在テーブル４０２を検索することで、（２５−３）のファイルＩＤを取得することができる。

登録部２１２は、以上のようにしてステップＳ７０１で（２５−１）〜（２５−３）の情報を取得する。そして、次のステップＳ７０２で、登録部２１２は、ファイル所在テーブル４０２から、削除されようとするファイルに関するエントリを削除する。すなわち、登録部２１２は、（２５−３）のファイルＩＤと、（２５−１）のホスト名と、（２５−２）のフルパスを対応づけているエントリを、ファイル所在テーブル４０２から削除する。

そして、次のステップＳ７０３で登録部２１２は、（２５−３）のファイルＩＤが、ファイル所在テーブル４０２または電子メール管理テーブル４０３に存在するか否かを判断する。

具体的には、登録部２１２は、（２５−３）のファイルＩＤを検索キーにして、ファイル所在テーブル４０２を検索する。図１３の処理を実行するクライアントマシンとは別のクライアントマシンが、同じファイルＩＤのファイルをローカルに保存している場合は、ファイル所在テーブル４０２でエントリが見つかる。

さらに、登録部２１２は、（２５−３）のファイルＩＤを検索キーにして、電子メール管理テーブル４０３を検索する。図１３の処理を実行するクライアントマシンと他のクライアントマシンの間でかつて送受信されたいずれか電子メールに、（２５−３）のファイルＩＤのファイルが添付されていた場合は、電子メール管理テーブル４０３でエントリが見つかる。

検索の結果、ファイル所在テーブル４０２と電子メール管理テーブル４０３のどちらにもエントリが見つからなければ、処理はステップＳ７０４へ移行する。逆に、ファイル所在テーブル４０２と電子メール管理テーブル４０３の少なくとも一方でエントリが見つかった場合は、処理はステップＳ７０５へ移行する。

ステップＳ７０４で登録部２１２は、（２５−３）のファイルＩＤを含むすべてのエントリをメンバテーブル４０１から削除する。その結果、メンバテーブル４０１とファイル所在テーブル４０２と電子メール管理テーブル４０３のいずれにも、（２５−３）のファイルＩＤを含むエントリは存在しなくなる。そして、エントリの削除後、処理はステップＳ７０５に移行する。

ステップＳ７０５で検出部２１３は、ファイルの削除を許可するための制御を行う。例えば、検出部２１３は、フック関数の実行を終了させることにより、ファイルを削除するためのコマンドまたはメニューに制御を戻し、それにより、ファイルの削除を許可してもよい。ステップＳ７０５の結果、ユーザが削除を指示したファイルは削除される。

以上の図１３の処理によれば、不要になることが明らかなエントリが、メンバテーブル４０１から削除される。つまり、図１３の処理によれば、下記（２６−１）と（２６−２）の条件をともに満たすファイルに関するエントリを持たないように、メンバテーブル４０１が管理される。

（２６−１）クライアントＰＣ１１２〜１１４のいずれにも現に保存されていない。
（２６−２）クライアントＰＣ１１２〜１１４のいずれかに現に保存されている電子メールから、今後、抽出されて、クライアントＰＣ１１２〜１１４のいずれかにローカルに保存される、という可能性もない。

また、図１３の処理によれば、ファイルの削除にともなって、ファイル所在テーブル４０２から不要なエントリが削除される。したがって、図１３の処理により、記憶領域の無駄な消費が防止される。

続いて、図１４〜１５を参照して、共有フォルダを介した情報漏洩も防止するための第２実施形態について説明する。第２実施形態では、第１実施形態と同様の処理に加えて、さらに、共有フォルダを介した情報漏洩を防止するための処理も行われる。

例えば、図２のようにＬＡＮ１１０内にファイルサーバ１１５が設けられ、ファイルサーバ１１５上に共有フォルダが作成され、共有フォルダを介してユーザ間でファイルが共有されることがある。しかし、共有フォルダに設定されたアクセス権によっては、共有フォルダを介して意図せぬ情報漏洩が生じるおそれがある。

例えば、下記（２７−１）〜（２７−４）のような状況を想定する。

（２７−１） ＬＡＮ１１０は、ある会社のイントラネットである。
（２７−２） クライアントＰＣ１１２と１１３のユーザは、会社内の第１の部署の職員である。また、クライアントＰＣ１１４のユーザは第２の部署の職員である。
（２７−３） 当該会社の規則では、第２の部署の職員には、第１の部署の内部文書を閲覧することが許されていない。
（２７−４） 他方で、部署間での情報共有のために、ファイルサーバ１１５上にはある共有フォルダが作成されている。そして、当該共有フォルダに関しては、クライアントＰＣ１１２〜１１４のユーザ全員に、読み書きが許可されている。

上記（２７−１）〜（２７−４）の状況において、クライアントＰＣ１１３のユーザが、もし第１の部署の内部文書のファイルを（２７−４）の共有フォルダに保存してしまうと、第１の部署の内部文書が、第２の部署の職員に漏洩してしまう。第２実施形態では、例えばこのような情報漏洩がユーザの不注意から生じることを防ぐために、図１４の処理が行われる。

図１４は、共有フォルダへの書き込み時に行われる書き込み確認処理のフローチャートである。図１４の処理は、図１のステップＳ１０３〜Ｓ１１１の処理の具体例に相当する。

以下では説明の便宜上、クライアントＰＣ１１３において図１４の処理が行われる場合を例にとる。
また、以下では説明の簡単化のため、ある一つのファイルが共有フォルダに書き込まれようとする場合について主に説明する。複数のファイルがまとめて共有フォルダに書き込まれようとする場合には、各ファイルについて図１４の処理が行われる。

図１４の処理は、具体的には以下の（２８−１）〜（２８−３）のいずれかの場合に開始される。

（２８−１） クライアントＰＣ１１３のユーザが、クライアントＰＣ１１３内にローカルに保存されているファイルを、共有フォルダに複写または移動するための操作を行った場合。
（２８−２） クライアントＰＣ１１３のユーザが、第１の共有フォルダ上に保存されているファイルを、第２の共有フォルダに複写または移動するための操作を行った場合。
（２８−３） クライアントＰＣ１１３のユーザが、クライアントＰＣ１１３で受信済みの電子メールの添付ファイルを、共有フォルダに保存するための操作を行った場合。

なお、（２８−１）の一例は、ＯＳにより提供されるコマンドまたはＧＵＩによる、共有フォルダへのファイルの複写または移動を行うための入力が、クライアントＰＣ１１３の入力装置２４０から与えられた場合である。別の例は、クライアントＰＣ１１３内にローカルに保存されているファイルを、アプリケーションソフトウェアの「別名で保存」（Save as ...）メニューを介して、共有フォルダ上に保存するための入力が、クライアントＰＣ１１３の入力装置２４０から与えられた場合である。

また、（２８−２）の場合は、第２の共有フォルダに関して図１４の処理が開始される。（２８−２）における複写または移動も、ＯＳにより提供されるコマンドまたはＧＵＩによる操作であってもよいし、アプリケーションソフトウェアによる操作であってもよい。

また、（２８−３）の操作は、メールユーザエージェント上での操作である。（２８−３）の操作は、具体的には、例えば、「添付ファイルの保存」メニューを選択し、一つの添付ファイルを選択し、保存先として共有フォルダを選択し、「保存」ボタンをクリックする、という一連の操作を含んでもよい。

検出部２１３は、例えばフックを利用することにより、（２８−１）〜（２８−３）のいずれかの入力操作が行われたことを検出することができる。そして、検出部２１３は、（２８−１）〜（２８−３）のいずれかの入力操作を検出すると、検出した入力操作の内容を判定部２１４に通知する。すると、判定部２１４が図１４の処理を開始する。

なお、図１４の処理を開始するためのトリガを検出部２１３が検出することは、図１のステップＳ１０３からステップＳ１０７への移行に相当する。
ステップＳ８０１で判定部２１４は、以下の（２９−１）〜（２９−３）の情報を取得する。

（２９−１） ユーザが共有フォルダに書き込もうとしているファイルのファイルＩＤ。
（２９−２） ファイルが書き込まれようとしている共有フォルダのフルパス。
（２９−３） 上記（２９−２）の共有フォルダにアクセス可能なアカウントのリスト。

なお、（２９−１）〜（２９−３）の情報は、具体的には以下のようにして取得される。
検出部２１３は、（２８−１）の入力操作を検出した場合、ファイルがローカルに保存されているクライアントＰＣ１１３上のフルパスと、クライアントＰＣ１１３のホスト名を、入力操作の内容を示す情報の一部として、判定部２１４に通知する。よって、判定部２１４は、通知されたホスト名と通知されたフルパスを検索キーとしてファイル所在テーブル４０２を検索することで、（２９−１）のファイルＩＤを取得する。

あるいは、検出部２１３は、（２８−２）の入力操作を検出した場合、第１の共有フォルダ上のファイルのフルパスを、入力操作の内容を示す情報の一部として、判定部２１４に通知する。よって、判定部２１４は、第１の共有フォルダ上のファイルのフルパス検索キーとしてファイル所在テーブル４０２を検索することで、（２９−１）のファイルＩＤを取得する。

なお、図１４に関する下記の説明から明らかになるとおり、かつて行われた第１の共有フォルダへのファイルの書き込みの際に、ファイル所在テーブル４０２にエントリが追加されている。よって、上記のようにして、判定部２１４が、第１の共有フォルダ上のファイルのフルパスを検索キーとしてファイル所在テーブル４０２を検索すると、エントリが見つかる。よって、判定部２１４は、ファイルＩＤを取得することができる。

また、検出部２１３は、（２８−３）の入力操作を検出した場合、共有フォルダへ保存されようとしているファイルが添付された電子メールのメッセージＩＤと、当該ファイルのファイル名を、例えばメールユーザエージェントから取得する。そして、検出部２１３は、入力操作の内容を示す情報の一部として、メッセージＩＤとファイル名を判定部２１４に通知する。

すると、判定部２１４は、通知されたメッセージＩＤと通知されたファイル名を検索キーとして電子メール管理テーブル４０３を検索することで、（２９−１）のファイルＩＤを取得することができる。なぜなら、かつて当該電子メールがクライアントＰＣ１１３において受信されたときに、第１実施形態と同様にして図１０の処理が行われているからである。そのため、電子メール管理テーブル４０３の検索によりエントリが見つかり、判定部２１４は、見つかったエントリからファイルＩＤを取得することができる。

そして、（２９−２）のフルパス（つまり、ファイルが書き込まれようとしている共有フォルダのフルパス）も、検出部２１３により、入力操作の内容を示す情報の一部として判定部２１４に通知される。したがって、判定部２１４は（２９−２）のフルパスも取得することができる。なお、以下では説明の便宜上、共有フォルダのフルパスは、「＼＼ｓｒｖ＼ｓｈａｒｅｄ＼Ｚ．ｔｘｔ」のようなＵＮＣ（Universal Naming Convention）形式で表記されるものとする。

また、判定部２１４は、取得した（２９−２）のフルパスで識別される共有フォルダのアクセス権設定を読み取ることで、（２９−３）のリストを取得する。アクセス制御の具体的方法はＯＳに依存するが、例えば、判定部２１４は、共有フォルダのプロパティから（２９−３）のリストを取得してもよい。

なお、以下では説明の便宜上、（２９−３）のリストは、具体的には、当該共有フォルダに関してリードパーミッションが与えられているユーザアカウントのアカウント名のリストであるものとする。また、説明の便宜上、（２９−３）のリストを「アカウントリスト」という。

以上のようにして、判定部２１４は、ステップＳ８０１で（２９−１）〜（２９−３）の情報を取得する。
そして、次のステップＳ８０２で判定部２１４は、「警告リスト」を空に初期化する。図１４の処理における警告リストも、判定部２１４が図１のステップＳ１０７の判定を行うために用いる情報の一例である。

また、次のステップＳ８０３で判定部２１４は、アカウントリスト中に、ステップＳ８０４〜Ｓ８０６の処理の対象としてまだ注目していないアカウント名が残っているか否かを判定する。もし未注目のアカウント名が残っていれば、処理はステップＳ８０４に移行する。逆に、すべてのアカウント名が注目済みであれば、処理はステップＳ８０７に移行する。

ステップＳ８０４で判定部２１４は、アカウントリスト中で未注目のアカウント名の一つに注目する。以下、ステップＳ８０４で注目されたアカウント名を「注目アカウント名」という。

そして、次のステップＳ８０５で判定部２１４は、注目アカウント名が、共有フォルダに書き込まれようとしているファイルに関する非第三者として登録されているか否かを判定する。具体的には、判定部２１４は、ステップＳ８０１で取得したファイルＩＤと注目アカウント名を検索キーにしてメンバテーブル４０１を検索する。

検索の結果、もしエントリが見つかれば、注目アカウント名は非第三者として登録済みである。よって、処理はステップＳ８０３に戻る。
逆に、検索の結果、もしエントリが見つからなければ、注目アカウント名は非第三者として登録されていない。つまり、注目アカウント名は、警告対象の第三者を表す。そこで、処理はステップＳ８０６に移行する。

ステップＳ８０６で判定部２１４は、注目アカウント名を警告リストに追加する。そして、処理はステップＳ８０３に戻る。
さて、アカウントリスト中のすべてのアカウント名に注目し終わると、判定部２１４は、警告リストが空か否かをステップＳ８０７で判定する。

警告リストが空の場合とは、すなわち、ファイルが書き込まれようとしている共有フォルダにアクセス可能なすべてのユーザが、当該ファイルについての非第三者である場合である。この場合、ファイルが共有フォルダに書き込まれても、ファイルへのアクセスを非第三者に提供することにはならない。つまり、情報漏洩のおそれはない。

したがって、判定部２１４は、非第三者への情報漏洩がないことを許可部２２３と登録部２１２に通知し、処理はステップＳ８０８に移行する。なお、ステップＳ８０７からステップＳ８０８への移行は、図１のステップＳ１０７からステップＳ１０５へのリンクに対応する。

逆に、警告リストが非空の場合とは、共有フォルダへのファイルの書き込みにより、ファイルが第三者からアクセス可能になってしまう場合である。つまり、警告リストが非空の場合、情報漏洩のおそれがある。

そこで、判定部２１４は警告リストを警告部２２１に出力し、処理はステップＳ８０９に移行する。なお、ステップＳ８０７からステップＳ８０９への移行は、図１のステップＳ１０７からステップＳ１０８へのリンクに対応する。

さて、ステップＳ８０８では、許可部２２３が、共有フォルダへのファイルの書き込みを許可する。つまり、許可部２２３は、検出部２１３が検出した操作（具体的には、（２８−１）〜（２８−３）のいずれかの操作）に応じた書き込みを許可する。

また、ステップＳ８０８では、登録部２１２が、（２９−１）のファイルＩＤと、共有フォルダ上に書き込まれたファイルのフルパスを、判定部２１４から受け取る。そして、登録部２１２は、受け取ったファイルＩＤとフルパスのペアを、ファイル所在テーブル４０２に登録する。

なお、（２９−１）のファイルＩＤを取得するために使う情報の一部として、上記のとおり、判定部２１４は、書き込み対象のファイルのファイル名か、または、当該ファイル名を含むフルパス（つまり、元の所在のフルパス）を検出部２１３から受け取っている。したがって、判定部２１４は、書き込み対象のファイルのファイル名を認識することができる。

よって、判定部２１４は、ステップＳ８０１で取得した（２９−２）の共有フォルダのフルパスに、パスのデリミタである「＼」とファイル名とを連結する（concatenate）ことにより、共有フォルダ上に書き込まれたファイルのフルパスを取得することができる。登録部２１２は、判定部２１４が以上のようにして取得したフルパスを、判定部２１４から受け取る。

そして、登録部２１２は、（２９−１）のファイルＩＤと、共有フォルダ上のファイルのフルパスとを対応づける新たなエントリを、ファイル所在テーブル４０２に追加する。それにより、登録部２１２は、ファイルの新たな所在情報を、ファイル所在テーブル４０２に登録する。そして、図１４の処理は終了する。

他方、ステップＳ８０９では、警告部２２１が、判定部２１４から受け取った警告リストにしたがって警告を発する。例えば、警告リストに２個のアカウント名が含まれる場合、警告部２２１は、以下の（３０−１）〜（３０−３）を含むダイアログをクライアントＰＣ１１３の画面に表示してもよい。

（３０−１） 「以下の２個のアカウント名のユーザは、この共有フォルダにアクセス可能ですが、非第三者として登録されていません。これら２名の第三者ユーザへの情報漏洩のおそれがありますが、本当にこのファイルをこの共有フォルダに書き込んでも構いませんか？」のような警告メッセージ。
（３０−２） 警告リストに含まれる２個のアカウント名。
（３０−３） 警告メッセージに対する入力を受け付けるための、「はい」ボタンと「いいえ」ボタン。

なお、（３０−１）〜（３０−３）に例示したダイアログは、警告のためのＧＵＩの一例に過ぎない。他のＧＵＩが使われてもよい。もちろん、警告部２２１は、音声的な警告を発してもよい。

また、警告部２２１は、警告を発するだけでなく、警告に対する入力を入力装置２４０から受け付けるように入力受付部２２２に命令する。すると、ステップＳ８０９で入力受付部２２２は入力装置２４０からの入力（例えば、（３０−３）の例では、「はい」ボタンまたは「いいえ」ボタンのクリック）を待つ。

警告に対する入力を入力受付部２２２が入力装置２４０から受け付けると、処理はステップＳ８１０に移行する。そして、ステップＳ８１０で入力受付部２２２は、受け付けた入力が、許可入力なのか、それとも禁止入力なのかを判断する。

禁止入力を入力受付部２２２が受け付けた場合、入力受付部２２２は禁止部２２４に通知を送る。そして、処理はステップＳ８１１に移行する。
逆に、許可入力を入力受付部２２２が受け付けた場合、入力受付部２２２は、非第三者への情報漏洩がないことを許可部２２３と登録部２１２に通知する。そして、処理はステップＳ８１２に移行する。

ステップＳ８１１で禁止部２２４は、共有フォルダへのファイルの書き込みをやめる。つまり、禁止部２２４は、ＯＳまたはアプリケーションソフトウェアを介した共有フォルダへのファイルの書き込みを禁止する。具体的には、禁止部２２４は、例えば、ＯＳまたはアプリケーションソフトウェアに対してユーザから与えられた入力をキャンセルすることで、共有フォルダへのファイルの書き込みを禁止してもよい。そして、図１４の処理は終了する。なお、メールユーザエージェントも、もちろんアプリケーションソフトウェアの一例である。

他方、ステップＳ８１２で登録部２１２は、判定部２１４から、（２９−１）のファイルＩＤと、警告リストを取得する。そして、登録部２１２は、警告リスト中の各アカウント名を非第三者として登録する。つまり、登録部２１２は、警告リスト中の各アカウント名について、判定部２１４から受け取ったファイルＩＤと、当該アカウント名とを対応づけるエントリをメンバテーブル４０１に追加する。

そして、メンバテーブル４０１の更新後、処理はステップＳ８０８に移行する。なお、ステップＳ８１２でのメンバテーブル４０１への新たな非第三者の登録は、図１のステップＳ１１１での登録の具体例である。

以上の図１４の処理によれば、「ユーザの不注意により、非第三者がアクセス可能な共有フォルダにファイルが書き込まれ、その結果、情報が漏洩してしまう」という事態が防止される。また、図１４の処理によれば、非第三者からしかアクセス可能でない共有フォルダへのファイルの書き込みに関しては何の警告も発せられない。よって、「過剰な警告発生によりユーザの作業効率が落ちる」といった事態も回避される。

ところで、上記のとおり第２実施形態では、第１実施形態と同様の処理も行われる。以下では、第１実施形態と同様の処理と図１４の処理が、ある順序で行われた場合の、管理ＤＢ４００の具体例について、図１５を参照して説明する。

図１５は、管理ＤＢ４００の例を示す図である。管理ＤＢ４００の具体例として、図１５には管理ＤＢ４００ｆと４００ｇが例示されている。管理ＤＢ４００ｆは、具体的には次の（３１−１）〜（３１−７）に説明する場合の例である。

（３１−１） ファイルサーバ１１５のホスト名が「ｓｒｖ」であるものとする。また、ファイルサーバ１１５上には、「＼＼ｓｒｖ＼ｓｈａｒｅｄ」というフルパスで示される共有フォルダが存在するものとする。
（３１−２） 「＼＼ｓｒｖ＼ｓｈａｒｅｄ」という共有フォルダのリードパーミッションは、「ｎａｍｅ＿Ａ」、「ｎａｍｅ＿Ｂ」、および「ｎａｍｅ＿Ｄ」という３個のアカウント名でそれぞれ識別されるユーザアカウントに対して与えられているとする。なお、「ｎａｍｅ＿Ａ」、「ｎａｍｅ＿Ｂ」、および「ｎａｍｅ＿Ｄ」というアカウント名は、それぞれ、クライアントＰＣ１１２、１１３、および１１４のユーザのアカウント名であるものとする。
（３１−３） 管理ＤＢ４００が図８の管理ＤＢ４００ｅの状態のときに、クライアントＰＣ１１２のユーザが、「Ｆ０００１０３」というファイルＩＤで識別されるファイルを「＼＼ｓｒｖ＼ｓｈａｒｅｄ」という共有フォルダに書き込むための操作を行ったとする。なお、管理ＤＢ４００ｅ内のファイル所在テーブル４０２ｅに示すとおり、「ＰＣ＿Ａ」というホスト名のクライアントＰＣ１１２には、「Ｆ０００１０３」というファイルＩＤで識別されるファイルが、ローカルに保存されている。
（３１−４） クライアントＰＣ１１２の検出部２１３が（３１−３）の操作を検出し、クライアントＰＣ１１２の判定部２１４が図１４の処理を開始する。すると、図８の管理ＤＢ４００ｅと（３１−２）より、警告リストには「ｎａｍｅ＿Ｄ」というアカウント名が追加され、ステップＳ８０９で警告が出される。
（３１−５） 警告に対し、クライアントＰＣ１１２のユーザが許可を与えたとする。
（３１−６） 上記（３１−５）の入力の結果、ステップＳ８１２では、「Ｆ０００１０３」というファイルＩＤと「ｎａｍｅ＿Ｄ」というアカウント名を対応づけるエントリがメンバテーブル４０１に追加される。
（３１−７） ステップＳ８１２に続くステップＳ８０８では、「Ｆ０００１０３」というファイルＩＤと、「＼＼ｓｒｖ＼ｓｈａｒｅｄ＼Ｚ．ｔｘｔ」というフルパスで表される所在情報を対応づけるエントリが、ファイル所在テーブル４０２に追加される。そして、図１４の処理が終了する。

以上の（３１−１）〜（３１−７）に説明した場合に、管理ＤＢ４００は、図８の管理ＤＢ４００ｅの状態から、図１５の管理ＤＢ４００ｆの状態へと変化する。

なお、図８のファイル所在テーブル４０２ｅに示すとおり、「ＰＣ＿Ｂ」というホスト名のクライアントＰＣ１１３にも、「Ｆ０００１０３」というファイルＩＤで識別されるファイルがローカルに保存されている。よって、クライアントＰＣ１１２ではなくクライアントＰＣ１１３から上記共有フォルダに上記ファイルが書き込まれようとした場合にも、（３１−４）〜（３１−７）と同様にして、管理ＤＢ４００は、管理ＤＢ４００ｅの状態から管理ＤＢ４００ｆの状態へと変化する。

また、図１５の管理ＤＢ４００ｇは、具体的には、次の（３２−１）〜（３２−６）に説明する場合の例である。

（３２−１） 上記（３１−１）〜（３１−２）の想定が成り立つとする。
（３２−２） 管理ＤＢ４００が図１５の管理ＤＢ４００ｆの状態のときに、クライアントＰＣ１１４のユーザが、「＼＼ｓｒｖ＼ｓｈａｒｅｄ＼Ｚ．ｔｘｔ」というフルパスで示されるファイルを、クライアントＰＣ１１４に複写するための操作を行ったとする。具体的には、複写先のクライアントＰＣ１１４内でのフルパスが「Ｃ：＼ｐａｔｈ＿Ｄ＼Ｚ＿ｃｏｐｙ．ｔｘｔ」だとする。
（３２−３） 第１実施形態では、ある１台のホストの内部でローカルに行われる複写、移動または変名をトリガとして、図１２の処理が実行される。第２実施形態では、第１実施形態と同様の操作が図１２の処理を開始するトリガとなるだけでなく、複写、移動、または変名の操作によって行われる、共有フォルダからローカルな記憶装置上へのファイルの書き込みも、図１２の処理を開始するトリガとなる。したがって、（３２−２）の複写により、図１２の処理が開始される。
（３２−４） 上記（３２−２）において、複写のための指示の入力は、クライアントＰＣ１１４に与えられる。よって、図１２のステップＳ６０１では、クライアントＰＣ１１４のホスト名である「ＰＣ＿Ｄ」が取得される。また、（３２−２）より、ステップＳ６０１では、複写先のフルパスとして「Ｃ：＼ｐａｔｈ＿Ｄ＼Ｚ＿ｃｏｐｙ．ｔｘｔ」が取得される。
（３２−５） 上記（３２−２）と図１５のファイル所在テーブル４０２ｆより、ステップＳ６０１では、複写されるファイルのファイルＩＤとして「Ｆ０００１０３」が取得される。
（３２−６） 上記（３２−４）と（３２−５）より、ステップＳ６０４では、「ＰＣ＿Ｄ」というホスト名と「Ｃ：＼ｐａｔｈ＿Ｄ＼Ｚ＿ｃｏｐｙ．ｔｘｔ」というフルパスのペアで示される新たな所在情報が、「Ｆ０００１０３」というファイルＩＤと対応づけられる。つまり、ファイルＩＤと新たな所在情報を対応づける新たなエントリがファイル所在テーブル４０２に追加される。

以上の（３２−１）〜（３２−６）に説明した場合に、管理ＤＢ４００は、図１５の管理ＤＢ４００ｆの状態から、管理ＤＢ４００ｇの状態へと変化する。
なお、第２実施形態では、（３２−３）に示した場合だけでなく、共有フォルダ上のファイルが当該共有フォルダ内において変名される場合にも、図１２の処理が開始される。さらに、第２実施形態では、共有フォルダ上のファイルが他の共有フォルダに複写または移動される場合にも、図１２の処理が開始される。

以上説明した第２実施形態によれば、第１実施形態と同様の効果が得られる。すなわち、電子メールを用いた情報のやりとりに関しては、管理サーバ１１７が管理するＬＡＮ１１０の内部か外部かを問わずに、第三者と非第三者が区別される。そして、非第三者に情報が漏洩するおそれがある場合は、警告が出される。

さらに、第２実施形態では、ＬＡＮ１１０の内部での共有フォルダを介しての情報のやりとりに関しても、共有フォルダにアクセス可能なＬＡＮ１１０内部のユーザが、第三者なのか非第三者なのか、ということが区別される。そして、共有フォルダを介してＬＡＮ１１０内部の第三者に情報が漏洩するおそれがある場合は、警告が出される。よって、第２実施形態では、第１実施形態よりも一層すぐれた情報保護が達成される。

続いて、図１６〜１９を参照して、うっかりミスによる情報漏洩が起きやすいファイルに監視対象を絞り込むことで処理負荷を減らす第３実施形態について説明する。
なお、第３実施形態では、図３のシステム２００がスタンドアロンシステムとして実現される。すなわち、図２の管理サーバ１１７は、第３実施形態では不要である。また、図２のクライアントＰＣ１１２〜１１４のそれぞれが、図３のシステム２００を含む。

以下では説明の便宜上、主にクライアントＰＣ１１２内のシステム２００の動作について説明する。しかし、クライアントＰＣ１１３と１１４においても、クライアントＰＣ１１２と同様の処理が行われる。

第１実施形態と第２実施形態のいずれにおいても、うっかりミスによる情報漏洩が防止可能である。しかし、第１実施形態と第２実施形態では、管理サーバ１１７の処理負荷も、クライアントＰＣ１１２〜１１４の処理負荷も、比較的高い。理由は以下の（３３−１）〜（３３−７）のとおりである。

（３３−１） 第１実施形態と第２実施形態のいずれにおいても、ローカルにファイルが生成されるたびに、図５の処理が行われる。
（３３−２） 第１実施形態と第２実施形態のいずれにおいても、ファイルが添付された電子メールが受信されるたびに、図１０の処理が行われる。
（３３−３） 第１実施形態と第２実施形態のいずれにおいても、添付ファイルがローカルに保存されるたびに、図１１の処理が行われる。
（３３−４） 第１実施形態と第２実施形態のいずれにおいても、あるホスト内でローカルにファイルが複写、移動、または変名されるたびに、図１２の処理が行われる。
（３３−５） 第２実施形態では、さらに、共有フォルダからローカルな記憶装置上へファイルが複写または移動されるたびに、図１２の処理が行われる。
（３３−６） 第２実施形態では、さらに、共有フォルダ上のファイルが当該共有フォルダ内において変名されるたびに、図１２の処理が行われる。
（３３−７） 第２実施形態では、さらに、二つの共有フォルダ間でファイルが複写または移動されるたびに、図１２の処理が行われる。

しかしながら、例えばクライアントＰＣ１１２内でローカルに生成されたファイルは、クライアントＰＣ１１２のユーザがクライアントＰＣ１１２内でローカルに参照するだけかもしれない。つまり、生成されたすべてのファイルが、クライアントＰＣ１１２から送信される電子メールに添付されたり、共有フォルダに複写されたりするとは限らない。

また、クライアントＰＣ１１２のユーザは、受信電子メールの添付ファイルをただ読むだけかもしれない。つまり、ファイルの添付されたすべての電子メールが転送されるわけではない。また、添付ファイルは、必ずしも、編集されて（あるいは編集されずにそのまま）別の電子メールに添付されて誰かに送信される、というわけでもない。

そして、共有フォルダからクライアントＰＣ１１２に複写または移動されたファイルは、必ずしも、その後で別の共有フォルダに複写または移動されるとは限らないし、電子メールに添付されて誰かに送信されるとも限らない。

したがって、第１実施形態と第２実施形態では、不注意による情報漏洩が確実に防止される一方で、クライアントＰＣ１１２内から外部へ出て行かないファイルに関しても、図５、１０、１１、および１２の処理が行われる。したがって、クライアントＰＣ１１２と管理サーバ１１７には、これらの処理の負荷がかかる。

もちろん、個々のファイルがクライアントＰＣ１１２内から外部へ出て行く可能性があるか否かは、事前には分からない。よって、第１実施形態と第２実施形態では、不注意による情報漏洩を確実に防止するために、上記のように図５、１０、１１、および１２の処理が行われる。つまり、第１実施形態と第２実施形態では、ローカルに生成されるすべてのファイルが監視対象であり、電子メールまたは共有フォルダを介してローカルに保存されるすべてのファイルが監視対象である。

他方、何らかの理由から、クライアントＰＣ１１２〜１１４および管理サーバ１１７の処理負荷を軽減することが望まれる場合もあり得る。そこで、第３実施形態では、処理負荷の軽減のために、監視対象のファイルが絞り込まれる。

具体的には、第３実施形態での監視対象は、うっかりミスによる情報漏洩が起きやすいと想定されるファイルだけに絞り込まれる。換言すれば、第３実施形態では、情報漏洩の危険性の高いファイルが監視され、情報漏洩の危険性の低いファイルは監視されない。

一般に、ユーザは、自ら作成したファイルについては、内容をよく承知していると想定される。したがって、ユーザは、自ら作成したファイルについては、誰が非第三者で誰が第三者かを、よく承知していると想定される。すると、ユーザが、自ら作成したファイルを不注意から非第三者に漏洩してしまうおそれは、比較的低い。

他方で、ユーザは、他のユーザが作成したファイルについては、内容をよく承知しているとは限らず、ファイルに含まれる情報の重要性に気づいていないかもしれない。ファイルの内容をよく承知していなければ、ユーザは、誰が非第三者で誰が第三者なのかを的確に認識することができないかもしれない。その結果、ユーザは、不注意による情報漏洩を引き起こすおそれがある。

つまり、あるユーザにとって、うっかりミスによる情報漏洩が起きやすいと想定されるファイルとは、当該ユーザ自身が作成したファイル以外のファイルである。そこで、第３実施形態では、監視対象のファイルが、うっかりミスによる情報漏洩が起きやすいと想定されるファイルのみに絞り込まれる。

なお、上記のとおり第３実施形態のシステム２００はスタンドアロンシステムであり、例えば１台のコンピュータ３００上に実装される。よって、うっかりミスによる情報漏洩が起きやすいと想定されるファイルとは、換言すれば、システム２００が実装されるコンピュータ３００の外部で生成されて、ネットワーク３１１を介してコンピュータ３００にもたらされたファイルである。以下では説明の便宜上、このように外部に起源を持っており（externally originating）、外部からもたらされたファイルを、「外来（foreign）ファイル」ということにする。

ところで、外来ファイルの定義より、外来ファイルの生成元を示す情報は、当然、システム２００が実装されるコンピュータ３００を識別する情報（例えば、ＩＰアドレス）ではない。また、外来ファイルの生成元を示す情報は、当然、コンピュータ３００のユーザを識別する情報（例えば、電子メールアドレスまたはアカウント名）でもない。

それでは外来ファイルの生成元は具体的にはどのような情報で表されるのかと言えば、外来ファイルの生成元に応じて、生成元を示す情報の種別は様々である。また、生成元を示す情報は、非第三者を示す情報（つまり図２の非第三者識別情報２３２）としても使われる。

そこで、次に図１６を参照して、第３実施形態において図３のファイル識別情報２３１と非第三者識別情報２３２として使われる情報の具体例を説明する。図１６に示す外来ファイル管理テーブル４０４は、第３実施形態において、第１〜２実施形態の管理ＤＢ４００の代わりに利用されるテーブルである。

そして、外来ファイル管理テーブル４０４の各エントリは、ファイルと非第三者とを対応づけている。具体的には、外来ファイル管理テーブル４０４の各エントリは、「ファイル」、「属性種別」、および「属性値」という３個のフィールドを含む。

「ファイル」フィールドは、ファイルのフルパスを示す。第３実施形態では図３のシステム２００がスタンドアロンシステムなので、システム２００が実装される１台のホスト（例えばクライアントＰＣ１１２）内の個々のファイルは、当該ファイルのフルパスにより一意に識別可能である。つまり、「ファイル」フィールドのフルパスは、図３のファイル識別情報２３１の具体例である。

「属性種別」フィールドは、「属性値」フィールドの値の種別を示す。そして、「属性値」フィールドが非第三者を示す。つまり、「属性値」フィールドの値は図３の非第三者識別情報２３２の具体例である。

上記のとおり、第３実施形態では、生成元に応じて、生成元を示す情報の種別は様々である。同様に、生成元以外の非第三者を示す情報の種類も、第３実施形態では様々である。よって、外来ファイル管理テーブル４０４では、「属性値」フィールドに登録されている非第三者識別情報２３２がどのような種類の情報なのかということが、「属性種別」フィールドにより示される。

具体例として、図１６には外来ファイル管理テーブル４０４の６つのエントリが例示されている。
１番目のエントリは、「Ｃ：＼ｐａｔｈ＿Ａ１＼Ｚ１．ｔｘｔ」というフルパスで識別されるファイルの非第三者が、「ｂ＠ｆｏｏ．ｃｏｍ」という電子メールアドレスで識別されることを示す。

つまり、１番目のエントリで示されるファイルは、上記電子メールアドレスで識別されるユーザと、外来ファイル管理テーブル４０４を記憶しているホストのユーザとの間で、電子メールを介してやりとりされる。したがって、１番目のエントリの「属性種別」フィールドには、「電子メール」という値が記憶されている。

２番目のエントリは、「Ｃ：＼ｐａｔｈ＿Ａ２＼Ｚ２．ｔｘｔ」というフルパスで識別されるファイルの非第三者が、「＼＼ｓｒｖ＼ｓｈａｒｅｄ＿Ｘ＼」というＵＮＣ形式のフルパスで識別されることを示す。つまり、２番目のエントリによれば、「＼＼ｓｒｖ＼ｓｈａｒｅｄ＿Ｘ＼」というフルパスで識別される共有フォルダにアクセス可能なすべてのユーザが、「Ｃ：＼ｐａｔｈ＿Ａ２＼Ｚ２．ｔｘｔ」というフルパスで識別されるファイルの非第三者である。

また、２番目のエントリで示されるファイルは、上記共有フォルダにアクセス可能なユーザと、外来ファイル管理テーブル４０４を記憶しているホストのユーザとの間で、上記共有フォルダを介してやりとりされる。そして、共有フォルダを介したファイルのやりとりは、具体的には、共有フォルダと、外来ファイル管理テーブル４０４を記憶しているホストのローカルな記憶装置との間での、ファイルの複写、移動、または変名の操作により、実現される。したがって、２番目のエントリの「属性種別」フィールドには、「複写／移動／変名」という値が記憶されている。

３番目のエントリは、「Ｃ：＼ｐａｔｈ＿Ａ３＼Ｚ３．ｔｘｔ」というフルパスで識別されるファイルの非第三者が、「１２３−４５６−７８９０」という識別情報で識別されることを示す。なお、図１６の例では、この「１２３−４５６−７８９０」という識別情報は、例えばＵＳＢメモリなどの記憶媒体を識別する情報であるものとする。

一部の記憶媒体には、当該記憶媒体を一意に識別する識別情報が割り当てられており、割り当てられた識別情報は、当該記憶媒体自体に記憶されている。そして、識別情報は、例えばＯＳにより提供されるシステムツールなどを介して、読み取ることが可能である。

例えば、ある種のＵＳＢメモリの識別情報は、ベンダＩＤとプロダクトＩＤとシリアル番号の組み合わせである。そして、この識別情報は、システムツールを介して、「ＰｎＰ（Plug and Play）デバイスＩＤ」として読み取ることが可能である。

そして、３番目のエントリでは、上記のように、記憶媒体の識別情報により非第三者が示される。換言すれば、３番目のエントリによれば、当該記憶媒体を正当に入手することが想定されているユーザは、すべて非第三者である。

また、３番目のエントリのファイルは、非第三者間で、当該記憶媒体を介してやりとりされる。そして、記憶媒体を介したファイルのやりとりは、具体的には、記憶媒体と、外来ファイル管理テーブル４０４を記憶しているホストのローカルな記憶装置との間での、ファイルの複写、移動、または変名の操作により、実現される。したがって、３番目のエントリの「属性種別」フィールドにも、「複写／移動／変名」という値が記憶されている。

４番目のエントリは、「Ｃ：＼ｐａｔｈ＿Ａ４＼Ｚ４．ｔｘｔ」というフルパスで識別されるファイルの非第三者が、「ｆｔｐ．ａｂｃｄ．ｏｒｇ」というＦＱＤＮで識別されることを示す。なお、図１６の例では、この「ｆｔｐ．ａｂｃｄ．ｏｒｇ」というＦＱＤＮにより識別されるホストが、具体的には図２のＦＴＰサーバ１２３であるものとする。

このように、４番目のエントリでは、ＦＴＰサーバ１２３を識別するＦＱＤＮにより非第三者が示される。換言すれば、４番目のエントリによれば、ＦＴＰサーバ１２３にアクセス可能なユーザ（つまり、少なくとも、ＦＴＰサーバ１２３からファイルをダウンロードする権限があるユーザ）は、すべて非第三者である。

そして、４番目のエントリで示されるファイルは、ＦＴＰサーバ１２３にアクセス可能なユーザと、外来ファイル管理テーブル４０４を記憶しているホスト（例えばクライアントＰＣ１１２）のユーザとの間で、ＦＴＰサーバ１２３を介してやりとりされる。したがって、４番目のエントリの「属性種別」フィールドには、「ＦＴＰ」という値が記憶されている。

５番目のエントリは、「Ｃ：＼ｐａｔｈ＿Ａ５＼Ｚ５．ｔｘｔ」というフルパスで識別されるファイルの非第三者が、「ｗｗｗ．ｅｆｇｈ．ｃｏｍ」というＦＱＤＮで識別されることを示す。なお、図１６の例では、この「ｗｗｗ．ｅｆｇｈ．ｃｏｍ」というＦＱＤＮにより識別されるホストが、具体的には図２のＨＴＴＰサーバ１２２であるものとする。

このように、５番目のエントリでは、ＨＴＴＰサーバ１２２を識別するＦＱＤＮにより非第三者が示される。換言すれば、ＨＴＴＰサーバ１２２にアクセス可能なユーザ（つまり、少なくとも、ＨＴＴＰサーバ１２２からファイルをダウンロードする権限があるユーザ）は、すべて非第三者である。

そして、５番目のエントリで示されるファイルは、ＨＴＴＰサーバ１２２にアクセス可能なユーザと、外来ファイル管理テーブル４０４を記憶しているホスト（例えばクライアントＰＣ１１２）のユーザとの間で、ＨＴＴＰサーバ１２２を介してやりとりされる。したがって、５番目のエントリの「属性種別」フィールドには、「ＨＴＴＰ」という値が記憶されている。

６番目のエントリは、「Ｃ：＼ｐａｔｈ＿Ａ１＼Ｚ１．ｔｘｔ」というフルパスで識別されるファイルの非第三者が、「＼＼ｓｒｖ＼ｓｈａｒｅｄ＿Ｙ＼」というＵＮＣ形式のフルパスで識別されることを示す。そして、２番目のエントリと同様に６番目のエントリでも、「属性値」フィールドが共有フォルダのフルパスを示すので、「属性種別」フィールドの値は「複写／移動／変名」である。

ここで、６番目と１番目のエントリの「ファイル」フィールドのフルパスは同じである。よって、「ｂ＠ｆｏｏ．ｃｏｍ」という電子メールアドレスのユーザだけでなく、「＼＼ｓｒｖ＼ｓｈａｒｅｄ＿Ｙ＼」という共有フォルダにアクセス可能なすべてのユーザも、「Ｃ：＼ｐａｔｈ＿Ａ１＼Ｚ１．ｔｘｔ」というファイルの非第三者である。

このように、ある一つのファイルに関する複数の非第三者が異なる属性値で識別される場合、外来ファイル管理テーブル４０４には、「ファイル」フィールドの値が等しい複数のエントリが含まれる。

なお、４番目と５番目のエントリでは、非第三者識別情報２３２としてＦＱＤＮが利用されている。しかし、もちろん、ＦＱＤＮの代わりにＩＰアドレスが利用されてもよい。あるいは、ＦＴＰサーバ１２３において、フォルダごとにアクセス権設定が異なる場合には、「ｆｔｐ．ａｂｃｄ．ｏｒｇ／ａａ／ｂｂ／」のように、ＦＱＤＮにＦＴＰサーバ１２３内のパスを連結した情報が利用されてもよい。ＨＴＴＰサーバ１２２に関しても同様である。

続いて、第３実施形態で行われる処理について、図１７〜１９を参照して説明する。なお、便宜上、図２のクライアントＰＣ１１２内に実装された図３のシステム２００の動作について説明するが、クライアントＰＣ１１３と１１４に関しても同様である。

図１７は、外来ファイル登録処理のフローチャートである。図１７の処理は図１のステップＳ１０１の処理の具体例である。
図１７の処理は、具体的には、クライアントＰＣ１１２上に外来ファイルが保存されたときに実行される。例えば、下記（３４−１）〜（３４−５）のいずれかの場合に図１７の処理が実行される。

（３４−１） 電子メールの添付ファイルがクライアントＰＣ１１２に保存された場合。
（３４−２） 複写、移動、または変名の操作により、ファイルサーバ１１５などにある共有フォルダから、クライアントＰＣ１１２に、ファイルが書き込まれた場合。
（３４−３） クライアントＰＣ１１２としてのコンピュータ３００の駆動装置３０８に記憶媒体３１０がセットされ、複写、移動、または変名の操作により、記憶媒体３１０から記憶装置３０７にファイルが書き込まれた場合。
（３４−４） ＨＴＴＰサーバ１２２からクライアントＰＣ１１２にファイルがダウンロードされた場合。
（３４−５） ＦＴＰサーバ１２３からクライアントＰＣ１１２にファイルがダウンロードされた場合。

より具体的には、（３４−１）の場合は、第１実施形態における図１１の処理を開始するためのトリガとして添付ファイル保存操作を検出部２１３が検出するのと同様にして、生成元認識部２１１が、図１７の処理を開始するためのトリガを検出する。例えば、生成元認識部２１１は、図１１に関して説明した（１８−１）〜（１８−４）のような一連の操作を含む添付ファイル保存操作を検出すると、図１７の処理を開始する。

なお、複数の添付ファイルが保存対象としてユーザから同時に指定されることもある。すなわち、（１８−２）において１＜Ｌの場合もある。その場合、保存される各添付ファイルについて、図１７の処理が行われる。

また、（３４−２）の場合は、図１５の管理ＤＢ４００ｇに関して（３２−３）に説明した検出部２１３による検出と同様にして、図１７の処理を開始するためのトリガを生成元認識部２１１が検出する。すなわち、生成元認識部２１１は、共有フォルダからクライアントＰＣ１１２へのファイルの書き込み（つまり、複写、移動、または変名の操作によって行われる、ファイルの書き込み）を検出すると、図１７の処理を開始する。

なお、複数のファイルを同時に共有フォルダからクライアントＰＣ１１２へ書き込むための操作をユーザが行うこともある。その場合、書き込まれる各ファイルについて、図１７の処理が行われる。

また、（３４−３）の場合は、記憶媒体３１０からクライアントＰＣ１１２の記憶装置３０７へのファイルの書き込みを生成元認識部２１１が検出する。つまり、生成元認識部２１１は、複写、移動、または変名のためのコマンドやＡＰＩ関数の呼び出しをフックするなどの方法により、記憶媒体３１０から記憶装置３０７へのファイルの書き込みを検出する。そして、生成元認識部２１１は、記憶媒体３１０からのファイルの書き込みを検出すると、図１７の処理を開始する。

なお、複数のファイルを同時に記憶媒体３１０からクライアントＰＣ１１２へ書き込むための操作をユーザが行うこともある。その場合、書き込まれる各ファイルについて、図１７の処理が行われる。

また、（３４−４）の場合は、ＨＴＴＰサーバ１２２からクライアントＰＣ１１２へのファイルのダウンロードを、生成元認識部２１１が検出する。そして、生成元認識部２１１は、ファイルがダウンロードされたことを検出すると、図１７の処理を開始する。

例えば、生成元認識部２１１は、クライアントＰＣ１１２上で動作するＨＴＴＰクライアントソフトウェア（例えばウェブブラウザなど）の動作を監視し、ＨＴＴＰサーバ１２２からのＨＴＴＰによるファイルのダウンロードを検出してもよい。なお、複数のファイルを同時にダウンロードするための操作をユーザが行うこともある。その場合、ダウンロードされる各ファイルについて、図１７の処理が行われる。

また、（３４−５）の場合は、ＦＴＰサーバ１２３からクライアントＰＣ１１２へのファイルのダウンロードを、生成元認識部２１１が検出する。生成元認識部２１１は、ファイルがダウンロードされたことを検出すると、図１７の処理を開始する。

例えば、生成元認識部２１１は、クライアントＰＣ１１２上で動作するＦＴＰクライアントソフトウェアの動作を監視し、ＦＴＰサーバ１２３からのＦＴＰによるファイルのダウンロードを検出してもよい。なお、複数のファイルを同時にダウンロードするための操作をユーザが行うこともある。その場合、ダウンロードされる各ファイルについて、図１７の処理が行われる。

さて、以上のようにして図１７の処理が開始されると、ステップＳ９０１で生成元認識部２１１は、次の（３５−１）と（３５−２）の情報を取得する。

（３５−１） クライアントＰＣ１１２のローカルな記憶装置３０７上の、ファイルの保存先のフルパス。
（３５−２） 外来ファイルの生成元を表す外部生成元情報。

例えば、（３４−１）の場合、生成元認識部２１１は、メールユーザエージェント上で行われる添付ファイル保存操作をフックすることで、図１７の処理を開始するためのトリガを検出してもよい。

そして、生成元認識部２１１は、メールユーザエージェントに対上でユーザが行った入力操作の内容から、（３５−１）のフルパスを取得してもよい。また、生成元認識部２１１は、保存されるファイルが添付されていた電子メールの「Ｆｒｏｍ」ヘッダフィールドから、（３５−２）の外部生成元情報として、送信元電子メールアドレスを取得する。さらに、生成元認識部２１１は、属性種別が「電子メール」であることを認識する。

また、複写、移動、または変名の操作によるファイルの書き込みは、（２３−１）〜（２３−７）に例示したように、具体的には、ＯＳにより提供されるコマンド、ＯＳにより提供されるＧＵＩ、またはアプリケーションソフトウェアを介して行われる。

よって、（３４−２）の場合、生成元認識部２１１は、例えばコマンドの呼び出しやＡＰＩ関数の呼び出しをフックすることで、ファイルの複写、移動または変名のための操作を検出してもよい。そして、生成元認識部２１１は、複写、移動または変名のためのコマンドまたはＡＰＩ関数の引数から、（３５−１）のクライアントＰＣ１１２上のフルパスと、（３５−２）の外部生成元情報としての、共有フォルダのフルパスを取得する。さらに、生成元認識部２１１は、属性種別が「複写／移動／変名」であることを認識する。

同様に、（３４−３）の場合も、生成元認識部２１１は、例えばコマンドの呼び出しやＡＰＩ関数の呼び出しをフックすることで、ファイルの複写、移動または変名のための操作を検出してもよい。そして、生成元認識部２１１は、複写、移動または変名のためのコマンドまたはＡＰＩ関数の引数から、（３５−１）のクライアントＰＣ１１２上のフルパスを取得する。

また、生成元認識部２１１は、上記コマンドまたはＡＰＩ関数の引数から、ファイルが記憶媒体３１０からクライアントＰＣ１１２へと書き込まれることを認識する。よって、生成元認識部２１１は、（３５−２）の外部生成元情報としての、記憶媒体３１０の識別番号（例えばＰｎＰデバイスＩＤ）を、ＯＳにより提供されるシステムツールなどを利用して読み出す。また、生成元認識部２１１は、属性種別が「複写／移動／変名」であることを認識する。

そして、（３４−４）の場合、生成元認識部２１１は、例えば、ＨＴＴＰクライアントソフトウェアの動作を監視することにより、ユーザがＨＴＴＰクライアントソフトウェアに対して指示した内容を取得してもよい。つまり、生成元認識部２１１は、ユーザがＨＴＴＰクライアントソフトウェアに対して指示した、ファイルのダウンロード先のフルパスを、（３５−１）のフルパスとして取得してもよい。なお、ＨＴＴＰクライアントソフトウェアの動作の監視は、具体的には、ＨＴＴＰクライアントソフトウェアからのＡＰＩ関数呼び出しを生成元認識部２１１がフックすることによって実現されてもよい。

また、生成元認識部２１１は、ユーザがＨＴＴＰクライアントソフトウェアに対してダウンロードするよう指示したファイルのＵＲＩ（Uniform Resource Identifier）から、当該ファイルを記憶しているＨＴＴＰサーバ１２２のＦＱＤＮを抽出してもよい。抽出されたＦＱＤＮは、（３５−２）の外部生成元情報として使われる。また、生成元認識部２１１は、属性種別が「ＨＴＴＰ」であることを認識する。

そして、（３４−５）の場合、生成元認識部２１１は、例えば、ＦＴＰクライアントソフトウェアの動作を監視することにより、ユーザがＦＴＰクライアントソフトウェアに対して指示した内容を取得してもよい。つまり、生成元認識部２１１は、ユーザがＦＴＰクライアントソフトウェアに対して指示した、ファイルのダウンロード先のフルパスを、（３５−１）のフルパスとして取得してもよい。なお、ＦＴＰクライアントソフトウェアの動作の監視は、具体的には、ＦＴＰクライアントソフトウェアからのＡＰＩ関数呼び出しを生成元認識部２１１がフックすることによって実現されてもよい。

また、生成元認識部２１１は、ユーザがＦＴＴＰクライアントソフトウェアに対してダウンロードするよう指示したファイルのＵＲＩから、当該ファイルを記憶しているＦＴＰサーバ１２３のＦＱＤＮを抽出してもよい。抽出されたＦＱＤＮは、（３５−２）の外部生成元情報として使われる。また、生成元認識部２１１は、属性種別が「ＦＴＰ」であることを認識する。

以上のようにして、（３４−１）〜（３４−５）のいずれの場合も、生成元認識部２１１は、ステップＳ９０１で、（３５−１）のフルパスと（３５−２）の外部生成元情報を取得する。また、上記のとおり、生成元認識部２１１は、属性種別も認識する。そして、生成元認識部２１１は、取得した（３５−１）のフルパスと、取得した（３５−２）の外部生成元情報、認識した属性種別を、登録部２１２に通知する。

すると、次のステップＳ９０２で登録部２１２は、ステップＳ９０１で生成元認識部２１１が取得した情報が外来ファイル管理テーブル４０４に登録済みか否かを判断する。つまり、登録部２１２は、外来ファイル管理テーブル４０４において、「ファイル」フィールドの値が（３５−１）のフルパスであり「属性値」フィールドの値が（３５−２）の外部生成元情報であるエントリを検索する。

検索の結果、エントリが見つかれば、ステップＳ９０１で取得された情報は外来ファイル管理テーブル４０４に登録済みである。よって、図１７の処理は終了する。
逆に、検索の結果、エントリが見つからなければ、ステップＳ９０１で取得された情報は外来ファイル管理テーブル４０４にまだ登録されていない。よって、処理はステップＳ９０３に移行する。

ステップＳ９０３で登録部２１２は、外部生成元情報を、ファイル保存先のフルパス、および属性種別と対応づけて、外来ファイル管理テーブル４０４に登録する。つまり、登録部２１２は、外来ファイル管理テーブル４０４に新たなエントリを追加する。登録部２１２は、当該新たなエントリにおいて、「ファイル」フィールドに（３５−１）のフルパスを設定し、「属性種別」フィールドに生成元認識部２１１から通知された属性種別の値を設定し、「属性値」フィールドに（３５−２）の外部生成元情報を設定する。そして、図１７の処理は終了する。

続いて、図１８を参照して、ファイルがリモートに出力されようとするときに行われる出力確認処理について説明する。図１８の処理は、図１のステップＳ１０３〜Ｓ１１１の処理の具体例に相当する。

ここで、上記と同様に、図２のクライアントＰＣ１１２上に図３のシステム２００が実装される場合を例に説明する。すると、ファイルがリモートに出力されようとする場合とは、具体的には、例えば以下の（３６−１）〜（３６−５）のいずれかの場合である。よって、（３６−１）〜（３６−５）のいずれかの場合に、図１８の処理が開始される。

（３６−１） クライアントＰＣ１１２内にローカルに保存されている１個以上のファイルが、電子メールに添付され、当該電子メールがクライアントＰＣ１１２から送信されようとする場合。
（３６−２） クライアントＰＣ１１２内にローカルに保存されている１個以上のファイルが、複写、移動、または変名の操作により、ファイルサーバ１１５などにある共有フォルダに書き込まれようとする場合。
（３６−３） クライアントＰＣ１１２内にローカルに保存されている１個以上のファイルが、複写、移動、または変名の操作により、記憶媒体３１０に書き込まれようとする場合。
（３６−４） クライアントＰＣ１１２内にローカルに保存されている１個以上のファイルが、ＨＴＴＰサーバ１２２にアップロードされようとする場合。
（３６−５） クライアントＰＣ１１２内にローカルに保存されている１個以上のファイルが、ＦＴＰサーバ１２３にアップロードされようとする場合。

例えば、（３６−１）の場合は、図９の処理が開始される場合と同様にして、図１８の処理が開始される。具体的には、クライアントＰＣ１１２のユーザがメールユーザエージェント上で、「送信」ボタンをクリックするなどの、電子メールの送信のための入力操作を行うと、クライアントＰＣ１１２上のシステム２００における検出部２１３は、当該入力操作を検出する。

そして、検出部２１３は、電子メールを送信するための入力操作を検出すると、検出した入力操作の内容を示す情報を判定部２１４に通知する。すると、判定部２１４は、送信されようとする電子メールにファイルが添付されているか否かを判定する。もしファイルが１個以上添付されていれば、判定部２１４は図１８の処理を開始する。

また、（３６−２）の場合は、図１４の処理が開始される場合と同様にして、図１８の処理が開始される。つまり、クライアントＰＣ１１２において、共有フォルダへのファイルの書き込みのための入力操作をユーザが行うと、検出部２１３は当該入力操作を検出する。

なお、図１４の処理が開始される場合として例示した（２８−１）〜（２８−３）は、クライアントＰＣ１１３に関する例である。しかし、もちろん、クライアントＰＣ１１２の検出部２１３は、クライアントＰＣ１１２における（２８−１）〜（２８−３）と同様の入力操作を、検出することができる。

そして、検出部２１３は、共有フォルダへファイルを書き込むための入力操作を検出すると、検出した入力操作の内容を示す情報を判定部２１４に通知する。すると、判定部２１４が図１８の処理を開始する。

また、検出部２１３は、（３６−３）の場合も（３６−２）の場合と類似の方法により、ファイルを記憶媒体３１０に書き込むための入力操作を検出することができる。つまり、検出部２１３は、複写、移動、または変名のためのコマンドやＡＰＩ関数の呼び出しをフックするなどの方法により、クライアントＰＣ１１２の記憶装置３０７から記憶媒体３１０へのファイルの書き込みのための入力操作を検出する。

そして、検出部２１３は、記憶媒体３１０へファイルを書き込むための入力操作を検出すると、検出した入力操作の内容を示す情報を判定部２１４に通知する。すると、判定部２１４が図１８の処理を開始する。

また、（３６−４）の場合、検出部２１３は、クライアントＰＣ１１２上で動作するＨＴＴＰクライアントソフトウェアの動作を監視することで、ＨＴＴＰサーバ１２２へファイルをアップロードするための入力操作を検出してもよい。

例えば、ファイルをアップロードするために、ユーザは、「アップロード」ボタンをクリックし、ダイアログを介してファイルの所在を指定し、「ＯＫ」ボタンをクリックする、という一連の入力操作を行うかもしれない。検出部２１３は、ＨＴＴＰクライアントソフトウェアの動作を監視して、これらの一連の入力操作が行われたことを検出してもよい。例えば、検出部２１３は、ＰＯＳＴメソッドまたはＰＵＴメソッドを指定したＨＴＴＰ要求を生成するためのＡＰＩ関数の呼び出しをフックすることで、上記の入力操作を検出してもよい。

そして、検出部２１３は、ファイルをＨＴＴＰサーバ１２２にアップロードするための入力操作を検出すると、検出した入力操作の内容を示す情報を判定部２１４に通知する。すると、判定部２１４が図１８の処理を開始する。

また、（３６−５）の場合、検出部２１３は、クライアントＰＣ１１２上で動作するＦＴＰクライアントソフトウェアの動作を監視することで、ＦＴＰサーバ１２３へファイルをアップロードするための入力操作を検出してもよい。

例えば、ファイルをアップロードするために、ユーザは、コマンドを入力するかもしれない。あるいは、ユーザは、ＧＵＩを介して、ファイルのアイコンを選択し、「アップロード」ボタンをクリックする、という一連の入力操作を行うかもしれない。検出部２１３は、ＦＴＰクライアントソフトウェアの動作を監視して、ファイルのアップロードのための入力操作が行われたことを検出してもよい。

例えば、検出部２１３は、コマンドラインからのキー入力を監視することで、上記の入力操作を検出してもよい。あるいは、検出部２１３は、ＦＴＰ要求を生成するためのＡＰＩ関数の呼び出しをフックすることで、上記の入力操作を検出してもよい。

そして、検出部２１３は、ファイルをＦＴＰサーバ１２３にアップロードするための入力操作を検出すると、検出した入力操作の内容を示す情報を判定部２１４に通知する。すると、判定部２１４が図１８の処理を開始する。

以上のように、（３６−１）〜（３６−５）のいずれの場合も、ファイルをリモートに出力しようとするユーザの入力操作を検出部２１３が検出し、判定部２１４が図１８の処理を開始する。

すると、ステップＳ１００１で判定部２１４は、操作対象の各ファイルのフルパスと、ファイルの外部出力先を示す出力先情報を取得する。上記のとおり判定部２１４は、検出部２１３が検出した入力操作の内容を示す情報を検出部２１３から受け取っている。よって、判定部２１４は、検出部２１３から受け取った情報から、フルパスと出力先情報を取得することができる。

具体的には、（３６−１）の場合、電子メールの各添付ファイルの、クライアントＰＣ１１２上でのフルパスが取得される。また、電子メールの「Ｔｏ」ヘッダフィールドと「ＣＣ」ヘッダフィールドと「ＢＣＣ」ヘッダフィールドに指定されているすべての電子メールアドレスが、出力先情報として取得される。

また、（３６−２）の場合、共有フォルダに書き込まれようとする各ファイルの、クライアントＰＣ１１２上でのフルパスが取得される。さらに、共有フォルダのフルパスが、出力先情報として取得される。

そして、（３６−３）の場合、記憶媒体３１０に書き込まれようとする各ファイルの、クライアントＰＣ１１２上でのフルパスが取得される。さらに、記憶媒体３１０の識別情報（例えばＰｎＰデバイスＩＤなど）が、出力先情報として取得される。

また、（３６−４）の場合、ＨＴＴＰサーバ１２２にアップロードされようとする各ファイルの、クライアントＰＣ１１２上でのフルパスが取得される。さらに、ＨＴＴＰサーバ１２２のＦＱＤＮまたはＩＰアドレスが、出力先情報として取得される。

そして、（３６−５）の場合、ＦＴＰサーバ１２３にアップロードされようとする各ファイルの、クライアントＰＣ１１２上でのフルパスが取得される。さらに、ＦＴＰサーバ１２３のＦＱＤＮまたはＩＰアドレスが、出力先情報として取得される。

以上のようにして、ステップＳ１００１で判定部２１４は、操作対象の１個以上のファイルそれぞれのフルパスと、１個以上の出力先情報を取得する。
すると、次のステップＳ１００２で判定部２１４は、ユーザにより指示された操作により外来ファイルが第三者に出力されるか否かを判定する。ステップＳ１００２は図１のステップＳ１０７の具体例である。

具体的には、判定部２１４は、ステップＳ１００１で取得した各フルパスについて、外来ファイル管理テーブル４０４のいずれかのエントリの「ファイル」フィールドに記憶されているか否かを調べる。例えば、Ｎ（１≦Ｎ）個のフルパスがステップＳ１００１で取得されたとすると、判定部２１４は、１≦ｊ≦Ｎなる各ｊについて、以下のような処理を行う。

もし、取得されたｊ番目のフルパスが、外来ファイル管理テーブル４０４のどのエントリにも記憶されていなければ、ｊ番目のフルパスで識別されるファイルは、外来ファイルではない。よって、ｊ番目のフルパスで識別されるファイルのリモートへの出力は、警告の対象ではない。

逆に、ｊ番目のフルパスを「ファイル」フィールドに記憶するエントリが１個以上見つかった場合、ｊ番目のフルパスで識別されるファイルは、外来ファイルである。そこで、判定部２１４はさらに、ステップＳ１００１で得られた各出力先情報について、見つかった１個以上のエントリのうちのいずれかの「属性値」フィールドに記憶されているか否かを調べる。

そして、もし、見つかった１個以上のエントリのうちどのエントリの「属性値」フィールドにも記憶されていない出力先情報があれば、判定部２１４は、「当該出力先情報は第三者を示している」と判定する。また、この場合、判定部２１４は、「ユーザにより指示された操作により、少なくとも１個の外来ファイルが第三者に出力される」と判定する。

逆に、どの出力先情報も、見つかった１個以上のエントリのうちのいずれかの「属性値」フィールドに記憶されているならば、判定部２１４は、「ｊ番目のフルパスで識別される外来ファイルは、非第三者にのみ出力され、第三者には出力されない」と判定する。

判定部２１４は、取得したＮ個のフルパスのそれぞれについて以上のような判定を行うことにより、「第三者に出力される外来ファイルが一つでもあるか否か」を判定する。
そして、第三者に出力される外来ファイルが一つでも見つかれば、処理はステップＳ１００３に移行する。その際、判定部２１４は、「第三者に出力される」と判定した各外来ファイルに関して、当該外来ファイルのフルパスと、当該外来ファイルに関して第三者と判定した出力先情報とのペアを、警告部２２１に通知する。

逆に、第三者に出力される外来ファイルが一つも見つからなければ、判定部２１４は、第三者への情報漏洩がないことを許可部２２３に通知する。そして、処理はステップＳ１００７に移行する。

例えば、２個のファイルが添付された電子メールが送信されようとしており、当該電子メールの「Ｔｏ」ヘッダフィールドと「ＣＣ」ヘッダフィールドと「ＢＣＣ」ヘッダフィールドにはそれぞれ１個の電子メールアドレスが指定されているとする。この場合、ステップＳ１００１では２個のフルパスと３個の電子メールアドレスが取得される。

例えば、２個の添付ファイルのうちの１個目のフルパスは外来ファイル管理テーブル４０４に登録されておらず、２個目のフルパスは外来ファイル管理テーブル４０４に登録されているとする。この場合、判定部２１４は、外来ファイルである２個目の添付ファイルに関して、出力先情報として取得された３個の電子メールアドレスのそれぞれについて、当該電子メールアドレスが第三者か非第三者かを判定する。つまり、２個目の添付ファイルのフルパスと当該電子メールアドレスを対応づけるエントリが外来ファイル管理テーブル４０４中に存在すれば、当該電子メールアドレスは非第三者であり、そのようなエントリがなければ、当該電子メールアドレスは第三者である。

もし、３個の電子メールアドレスがすべて２個目の添付ファイルの非第三者として外来ファイル管理テーブル４０４に登録されていれば、処理はステップＳ１００７に移行する。しかし、３個の電子メールアドレスの中に１個でも非第三者として登録されていないものがあれば、処理はステップＳ１００３に移行する。

なお、以上説明した例は、（３６−１）の電子メールの送信の場合の例である。しかし、もちろん（３６−２）〜（３６−５）の場合でも、判定部２１４は、ステップＳ１００１で取得したフルパスと出力先情報を用いて外来ファイル管理テーブル４０４を検索することで、ステップＳ１００２の判定を行うことができる。

さて、ステップＳ１００３で警告部２２１は、判定部２１４から通知された情報に基づいて警告を発する。
例えば、（３６−１）の電子メールの送信の場合には、警告部２２１は、図９のステップＳ３１１と類似の警告を発してもよい。

また、（３６−２）の場合には、警告部２２１は、例えば、警告メッセージと「はい」ボタンと「いいえ」ボタンを含むダイアログを表示してもよい。警告メッセージは、例えば、「共有フォルダにファイルが書き込まれようとしていますが、この共有フォルダは非第三者として登録されていません。書き込みにより第三者へ情報が漏洩するおそれがあります。書き込みを許可しますか？」のようなものでもよい。

また、警告部２２１は、共有フォルダのプロパティから、共有フォルダにアクセス可能なユーザのアカウント名のリストを取得してもよい。そして、警告部２２１は、警告メッセージとともに、取得したリストを表示してもよい。

そして、（３６−３）〜（３６−５）の場合も、警告部２２１は、警告メッセージの文面を適宜変更して、（３６−２）の場合と類似のダイアログを表示してもよい。
もちろん、（３６−１）〜（３６−５）のいずれの場合も、警告部２２１は、判定部２１４から通知された情報に基づいて、判定部２１４によって「外来ファイルであり且つ第三者に出力される」と判定された各ファイルのフルパスを、ユーザの参考のために表示してもよい。また、警告部２２１は音声的に警告を発してもよい。

いずれにせよ、ステップＳ１００３で警告部２２１は警告を発する。そして、警告部２２１は、警告に対する入力を入力装置２４０から受け付けるように入力受付部２２２に命令する。すると、ステップＳ１００３で入力受付部２２２は入力装置２４０からの入力（例えば、「はい」ボタンまたは「いいえ」ボタンのクリック）を待つ。

警告に対する入力を入力受付部２２２が入力装置２４０から受け付けると、処理はステップＳ１００４に移行する。そして、ステップＳ１００４で入力受付部２２２は、受け付けた入力が、許可入力なのか、それとも禁止入力なのかを判断する。

禁止入力を入力受付部２２２が受け付けた場合、入力受付部２２２は禁止部２２４に通知を送る。そして、処理はステップＳ１００５に移行する。
逆に、許可入力を入力受付部２２２が受け付けた場合、入力受付部２２２は、非第三者への情報漏洩がないことを許可部２２３と登録部２１２に通知する。そして、処理はステップＳ１００６に移行する。

ステップＳ１００５で禁止部２２４は、ユーザにより指示された操作をとりやめる。禁止部２２４は、検出部２１３が検出したユーザからの入力操作をキャンセルすることで、ユーザにより指示された操作を禁止し、とりやめることができる。

例えば、（３６−１）の場合、禁止部２２４は、メールユーザエージェントに対してユーザから与えられた入力をキャンセルすることで、電子メールの送信を禁止してもよい。

あるいは、（３６−２）の場合、禁止部２２４は、共有フォルダへのファイルの書き込みのためにＯＳまたはアプリケーションソフトウェアに対してユーザから与えられた入力をキャンセルすることで、共有フォルダへのファイルの書き込みを禁止してもよい。そして、（３６−３）の場合も同様に、禁止部２２４は、記憶媒体３１０へのファイルの書き込みのためにＯＳまたはアプリケーションソフトウェアに対してユーザから与えられた入力をキャンセルすることで、記憶媒体３１０へのファイルの書き込みを禁止してもよい。

また、（３６−４）の場合、禁止部２２４は、ＨＴＴＰクライアントソフトウェアに対してユーザから与えられた入力をキャンセルすることで、ＨＴＴＰサーバ１２２へのファイルのアップロードを禁止してもよい。そして、（３６−５）の場合、禁止部２２４は、ＦＴＰクライアントソフトウェアに対してユーザから与えられた入力をキャンセルすることで、ＦＴＰサーバ１２３へのファイルのアップロードを禁止してもよい。

そして、ステップＳ１００５で禁止部２２４が以上のようにして、ユーザから指示された操作をとりやめると、図１８の処理も終了する。
また、ステップＳ１００６で登録部２１２は、警告対象を示す情報を判定部２１４から取得する。そして、登録部２１２は、判定部２１４から受け取った情報に基づいて、新たな非第三者を外来ファイル管理テーブル４０４に登録する。

具体的には、登録部２１２が受け取る情報は、リモートへの出力が許可された外来ファイルのフルパスと、まだ非第三者として登録されていない第三者を示す出力先情報との、１個または複数個のペアである。よって、登録部２１２は、各ペアに対応する新たなエントリを外来ファイル管理テーブル４０４に追加する。

なお、登録部２１２は、追加したエントリの「属性種別」フィールドに値を適宜設定する。例えば、登録部２１２は、検出部２１３が検出した入力操作の種別を、検出部２１３に問い合せてもよい。

例えば、（３６−１）の入力操作を検出部２１３が検出した場合、登録部２１２は、「電子メール」という属性種別を設定する。また、（３６−２）または（３６−２）の入力操作を検出部２１３が検出した場合、登録部２１２は、「複写／移動／変名」という属性種別を設定する。そして、（３６−４）の入力操作を検出部２１３が検出した場合、登録部２１２は、「ＨＴＴＰ」という属性種別を設定し、（３６−５）の入力操作を検出部２１３が検出した場合、登録部２１２は、「ＦＴＰ」という属性種別を設定する。

以上のようにしてステップＳ１００６で新たな非第三者が外来ファイル管理テーブル４０４に登録されると、処理はステップＳ１００７に移行する。
ステップＳ１００７で許可部２２３は、ユーザにより指示された操作を許可する。そして、図１８の処理は終了する。

なお、ステップＳ１００７の結果として、ユーザにより指示された操作が、ＯＳまたはアプリケーションソフトウェアにより、実行される。その結果、ファイルがリモートに出力される。例えば、添付ファイルつき電子メールの送信、共有フォルダへのファイルの書き込み、記憶媒体３１０へのファイルの書き込み、ＨＴＴＰサーバ１２２へのファイルのアップロード、または、ＦＴＰサーバ１２３へのファイルのアップロードが行われる。

しかし、図１８の処理によれば、ファイルがリモートに出力されるのは、ファイルが外来ファイルではないか、一または複数の出力先がすべて非第三者として登録済みであるか、今まで第三者だった出力先が新たに非第三者として指定された場合のみである。したがって、図１８の処理によれば、「不注意が原因で、ユーザが、意図せずに、外来ファイルへのアクセスを第三者に提供してしまう」という事態は防止される。

ところで、クライアントＰＣ１１２の記憶装置３０７の有効利用のためには、外来ファイル管理テーブル４０４の不要なエントリが削除されてもよい。具体的には、図１９の処理が行われてもよい。

図１９は、ファイル削除時に行われる外来ファイル情報更新処理のフローチャートである。図１９の処理は、クライアントＰＣ１１２内にローカルに保存されているファイルが削除されようとするときに行われる。

ＯＳは、ファイル削除のために、「ｄｅｌ」コマンドなどのコマンドや、「ゴミ箱」を空にするメニューなどを提供する。よって、検出部２１３は、ファイル削除のために提供されているこれらのコマンドやメニューの呼び出しを検出すると、検出した呼び出しの内容を登録部２１２に通知する。そして、登録部２１２が図１９の処理を開始する。なお、検出部２１３は、上記のコマンドやメニューの呼び出しを検出するために、例えばフックを利用してもよい。

さて、ステップＳ１１０１で登録部２１２は、削除対象のファイルのフルパスを取得する。登録部２１２は、検出部２１３から通知された内容から、削除対象のファイルのフルパスを取得することができる。

なお、検出部２１３自体は、例えば、コマンドの引数とカレントフォルダのフルパスに基づいて、削除対象のファイルのフルパスを認識してもよい。また、「ゴミ箱」内のファイルには、当該ファイルがもともと置かれていたフォルダのフルパスを示す情報が対応づけられている。よって、検出部２１３は、例えばＯＳを介して、削除対象のファイルが「ゴミ箱」に移動される前の当該ファイルの所在を示すフルパスを認識してもよい。

次のステップＳ１１０２で登録部２１２は、検出部２１３から通知されたフルパスが外来ファイル管理テーブル４０４に登録済みか否かを判断する。つまり、登録部２１２は、通知されたフルパスが「ファイル」フィールドに記憶されているエントリを、外来ファイル管理テーブル４０４において検索する。

検索の結果、もしエントリが見つからなければ、削除されるファイルは外来ファイルではなく、削除されるファイルに関する情報はそもそも外来ファイル管理テーブル４０４に存在しない。よって、図１９の処理も終了する。

逆に、検索の結果、エントリが見つかれば、削除されるファイルは外来ファイルである。よって、処理はステップＳ１１０３に移行する。なお、例えば図１６の例において「Ｃ：＼ｐａｔｈ＿Ａ１＼Ｚ１．ｔｘｔ」というフルパスで識別されるファイルが削除される場合のように、検索の結果、複数のエントリが見つかることもある。

ステップＳ１１０３で登録部２１２は、削除されるファイルに関して外来ファイル管理テーブル４０４に登録されているすべてのエントリ（すなわち、ステップＳ１１０２の検索で見つかったすべてのエントリ）を、外来ファイル管理テーブル４０４から削除する。そして、図１９の処理も終了する。

ところで、図示は省略したが、第３実施形態においては、クライアントＰＣ１１２内でローカルにファイルが複写、移動、または変名される場合に、第１実施形態の図１２と類似の処理が行われる。

具体的には、図１２に関して説明した（２３−１）〜（２３−７）のような操作を検出部２１３が検出する。そして、検出部２１３は、複写、移動、または変名の操作の対象の元のファイルのフルパスと、ファイルの新たなフルパス（すなわち、複写先、移動先、または変名後のフルパス）を取得する。そして、検出部２１３は、取得した情報を登録部２１２に通知する。

すると、登録部２１２は、元のファイルのフルパスを検索キーにして外来ファイル管理テーブル４０４を検索する。検索の結果、エントリが見つからなければ、登録部２１２は外来ファイル管理テーブル４０４を更新しない。逆に、検索の結果、エントリが１個以上見つかった場合は、見つかった各エントリについて、登録部２１２は以下の処理を行う。

検出された操作が複写操作の場合、登録部２１２は、「ファイル」フィールドには取得した新たなフルパスを設定し、「属性種別」と「属性値」フィールドには上記の検索で見つかったエントリと同じ値を設定した新たなエントリを追加する。また、検出された操作が移動操作または変名操作の場合、登録部２１２は、上記の検索で見つかったエントリの「ファイル」フィールドの値を、取得した新たなフルパスに書き換える。

以上のようにして、登録部２１２は外来ファイル管理テーブル４０４を更新する。すると、第１実施形態での図１２の処理による効果と同様の効果が得られる。つまり、たとえファイルが複写、移動、または変名されても、システム２００がファイルを追跡してファイルの継続性を管理することが可能となる。

ところで、本発明は上記実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の観点から様々に変形することもできる。上記の各実施形態および下記の各種変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。

変形の第１の観点は、処理の実行順序に関する。上記の各フローチャートにおけるステップの順序は、矛盾が生じない限り、適宜入れ替えられてもよい。また、入れ替え可能な複数のステップが並列に実行されてもよい。例えば、以下のような入れ替えが可能である。

例えば、図５のステップＳ２０１とＳ２０２の順序は入れ替えられてもよい。ステップＳ２０３とＳ２０４の順序も、入れ替えられてよい。また、図９のステップＳ３０２は、ステップＳ３０１の前に実行されてもよいし、逆にステップＳ３０４の後に実行されてもよい。

さらに、図１０において、ステップＳ４０７〜Ｓ４０８での登録と、ステップＳ４０９〜Ｓ４１０での登録の順序も、入れ替え可能である。また、図１２において、ステップＳ６０４はステップＳ６０２の前に実行されてもよい。図１４においては、ステップＳ８０１とＳ８０２の順序が入れ替え可能である。

変形の第２の観点は、データの形式と値に関する。図６〜８、１５〜１６には各種テーブルの具体例を例示したが、実施形態によっては、テーブルの構成が上記例示と異なっていてもよい。例えば、図６〜８、１５ではホスト名とホスト内のフルパスの組み合わせで所在情報が示される場合と、ホスト名を含むＵＮＣ形式のフルパスで所在情報が示される場合で、列の数が異なるが、このように列の数が異なるのも単なる図示の都合である。また、各種のデータは、必ずしもテーブル形式で管理されなくてもよい
例えば、図６のメンバテーブル４０１ｂは３個のエントリを含むが、３個のエントリのファイルＩＤは同じである。そこで、メンバテーブル４０１は、ファイルＩＤに、非第三者メンバのリストを対応づける形式のテーブルに置き換えられてもよい。

あるいは、ファイルＩＤをキーとし、非第三者メンバのリストをデータとして持つ連想配列が、メンバテーブル４０１の代わりに使われてもよい。または、テーブル形式の管理ＤＢ４００の代わりに、ＸＭＬ（Extensible Markup Language）ＤＢなどの他の形式のＤＢが利用されてもよい。

なお、図６〜８、１５〜１６に例示した値は、例示のためのものに過ぎない。例えば、ファイルＩＤの形式は、実施形態に応じて異なっていてよい。また、メッセージＩＤの形式も、メールユーザエージェントなどに応じて異なる。そして、パスの表記法も、ＯＳに応じて異なる。

変形の第３の観点は、アカウント名の利用に関する。具体的には、第１実施形態は、アカウント名を利用しないように変形されてもよい。
例えば、ＬＡＮ１１０内で共有フォルダが使われない場合や、ＬＡＮ１１０内のユーザがどの種類の情報についても皆同等の権限を持つような場合などでは、共有フォルダを介した情報漏洩について考慮しなくてもよい。よって、アカウント名は利用されなくてもよい。具体的には、例えば第１実施形態が以下のように変形されてもよい。

図５のステップＳ２０１では、アカウント名の代わりに、ファイルが生成されたマシン上にインストールされているメールユーザエージェントの設定情報から、送信用電子メールアドレスを生成元認識部２１１が読み出す。そして、ステップＳ２０４ではアカウント名の代わりに、送信用電子メールアドレスがメンバテーブル４０１に登録される。

また、図９のステップＳ３０１でアカウント名の取得は省略される。そして、ステップＳ３０３では、ファイルＩＤとアカウント名のペアがメンバテーブル４０１に登録済みか否かのチェックが省略される。

そして、図１０のステップＳ４０１でアカウント名の取得は省略される。さらに、ステップＳ４０７とＳ４０８も省略される。
変形の第４の観点は、電子メールの送信または受信に際して、どの電子メールアドレスを自動的に非第三者として登録するか、という点に関連する。

警告の発生回数を抑えてユーザが利便性を高めるためには、明らかに非第三者と考えられるユーザを示す電子メールアドレスを、自動的に非第三者として登録することが有益である。しかし、仮に非第三者の自動登録が省略されても、警告の発生によりユーザに多少の手間が生じるだけであり、情報漏洩の危険性自体は増えない。このことは、第三者を誤って非第三者として登録すると情報漏洩の危険性が増すのと対照的である。

したがって、ある条件に該当する電子メールアドレスは、非第三者として自動的に登録されてもよいし、自動的な登録が省略されてもよい。
例えば、ＬＡＮ１１０の外部のクライアントＰＣ１２４が「ｃ＠ｂａｒ．ｏｒｇ」という電子メールアドレスから送信した電子メールを、ＬＡＮ１１０の内部のクライアントＰＣ１１２が受信したとする。そして、当該電子メールにはファイルが添付されていたとする。この場合、図１０によれば、「ｃ＠ｂａｒ．ｏｒｇ」という送信元電子メールアドレスは、自動的には非第三者として登録されない。

しかし、上記の場合、電子メールの送信者は、明らかに、添付ファイルに関する非第三者である。そこで、管理サーバ１１７が管理するＬＡＮ１１０の外部からの電子メールが受信されたときに実行されるステップＳ４０４において、登録部２１２がさらに以下のような処理を行ってもよい。

すなわち、登録部２１２は、受信電子メールから送信元電子メールアドレスを読み取る。そして、登録部２１２は、各添付ファイルについて、ステップＳ４０４で発行したファイルＩＤと、読み取った送信元電子メールアドレスとを対応づけるエントリを、メンバテーブル４０１に追加する。その結果、例えば上記の場合には、「ｃ＠ｂａｒ．ｏｒｇ」という送信元電子メールアドレスが、自動的に非第三者として登録される。

ところで、上記のように「ｃ＠ｂａｒ．ｏｒｇ」という電子メールアドレスから送信された電子メールの「Ｔｏ」と「ＣＣ」のヘッダフィールドには、ＬＡＮ１１０の外部のドメインの１個以上の電子メールアドレスが指定されているかもしれない。そして、外部ドメインの１個以上の電子メールアドレスで示される外部ドメインの受信者は、送信者によって添付ファイルへのアクセスが許可されていると見なすことができ、また、実際に添付ファイルにアクセス可能なので、非第三者と見なして差し支えない。しかし、図９〜１１によれば、送信元電子メールアドレスが「ｃ＠ｂａｒ．ｏｒｇ」のような外部ドメインのものの場合、「Ｔｏ」と「ＣＣ」のヘッダフィールドに含まれる外部ドメインの電子メールアドレスは、自動的に非第三者として登録されはしない。

そこで、「Ｔｏ」と「ＣＣ」のヘッダフィールドに含まれる外部ドメインの電子メールアドレスを自動的に非第三者として登録するために、図１０のステップＳ４０４がさらに以下のように変形されてもよい。以下の変形によれば、将来の警告の発生をさらに抑制することが可能である。

すなわち、登録部２１２は、受信電子メールの「Ｔｏ」と「ＣＣ」ヘッダフィールドに含まれるすべての電子メールアドレスをさらに読み取る。その結果、１個または複数個の電子メールアドレスが得られる。そして、登録部２１２は、添付ファイルと読み取った電子メールの各組み合わせについて、ステップＳ４０４で発行したファイルＩＤと、読み取った電子メールアドレスとを対応づけるエントリを、メンバテーブル４０１に追加する。

また、以上説明したステップＳ４０４の変形とは逆に、非第三者としての自動登録の一部を省略する変形も可能である。すなわち、図９の処理においては、「ＢＣＣ」ヘッダフィールドの電子メールアドレスも「宛先電子メールアドレス」として扱われるが、「ＢＣＣ」ヘッダフィールドの電子メールアドレスは「宛先電子メールアドレス」として扱われなくてもよい。

つまり、図９の処理によれば、「ＢＣＣ」ヘッダフィールドに非第三者として登録されていない電子メールアドレスが含まれる場合、ステップＳ３１１で警告が出される。そして、警告に対してユーザから許可入力が与えられると、当該電子メールアドレスは、ステップＳ３１４で自動的に非第三者として登録される。しかし、許可入力が与えられた場合でも、「ＢＣＣ」ヘッダフィールドに指定されている電子メールアドレスは、非第三者としての自動登録の対象から除外されてもよい。

なぜなら、ある特定の状況下では、「ＢＣＣ」ヘッダフィールドの使用により隠蔽されていた電子メールアドレスが、自動登録により明らかになってしまうことがあり得るからである。そこで、他の受信者に対して電子メールアドレスを隠蔽するという「ＢＣＣ」ヘッダフィールドの目的を尊重するため、「ＢＣＣ」ヘッダフィールドに指定されている電子メールアドレスは、ステップＳ３１４における自動登録の対象から除外されてもよい。

例えば、上記のとおりクライアントＰＣ１１２〜１１４で使われる電子メールアドレスがそれぞれ「ａ＠ｆｏｏ．ｃｏｍ」、「ｂ＠ｆｏｏ．ｃｏｍ」、「ｄ＠ｆｏｏ．ｃｏｍ」であるとする。そして、ファイルが添付されたある電子メールの、「Ｆｒｏｍ」、「Ｔｏ」、「ＢＣＣ」の各ヘッダフィールドの値が、それぞれ「ａ＠ｆｏｏ．ｃｏｍ」、「ｂ＠ｆｏｏ．ｃｏｍ」、「ｄ＠ｆｏｏ．ｃｏｍ」であるとする。

この場合、クライアントＰＣ１１３のユーザは、受信した電子メールのヘッダを見ても、クライアントＰＣ１１４のユーザにも同じ電子メールが送信されたことを認識することができない。しかし、図９の処理によれば、以下の状況下では、クライアントＰＣ１１３のユーザが、「受信した電子メールの『ＢＣＣ』ヘッダフィールドには『ｄ＠ｆｏｏ．ｃｏｍ』という電子メールアドレスが指定されていたはずだ」と推測することが可能になる。

例えば、クライアントＰＣ１１３のユーザが、受信した電子メールを「ｄ＠ｆｏｏ．ｃｏｍ」という電子メールアドレスに宛てて（すなわちクライアントＰＣ１１４のユーザに宛てて）転送しようとしたとする。すると、クライアントＰＣ１１３では図９の処理が実行される。しかし、図９の処理によれば、警告は発せられない。なぜなら、かつてクライアントＰＣ１１２が電子メールを送信した際にクライアントＰＣ１１２において実行された図９の処理により、「ｄ＠ｆｏｏ．ｃｏｍ」という電子メールアドレスが非第三者として既に登録されているからである。

すると、クライアントＰＣ１１３のユーザは、警告が発せられなかったことから、転送先の「ｄ＠ｆｏｏ．ｃｏｍ」という電子メールアドレスが非第三者であると理解するかもしれない。この理解に基づいて、クライアントＰＣ１１３のユーザは、「受信した電子メールの『ＢＣＣ』ヘッダフィールドには『ｄ＠ｆｏｏ．ｃｏｍ』という電子メールアドレスが指定されていたはずだ」と推測し得る。つまり、「ＢＣＣ」ヘッダフィールドの使用により隠蔽されていた電子メールアドレスが明らかになってしまう可能性がある。

そこで、「ＢＣＣ」ヘッダフィールドの目的を尊重するために、「ＢＣＣ」ヘッダフィールドに指定されている電子メールアドレスは、図９のステップＳ３１４における自動登録の対象から除外されてもよい。

すると、上記の例ではクライアントＰＣ１１３のユーザが電子メールを「ｄ＠ｆｏｏ．ｃｏｍ」という電子メールアドレスに宛てて転送しようとしたとき、警告が発せられる。したがって、クライアントＰＣ１１３のユーザは、クライアントＰＣ１１３で受信した電子メールの「ＢＣＣ」ヘッダフィールドに「ｄ＠ｆｏｏ．ｃｏｍ」という電子メールアドレスが指定されていたことを推測することができない。以上のようにして、電子メールアドレスの隠蔽という「ＢＣＣ」ヘッダフィールドの目的により適合した形に、上記実施形態は変形されてもよい。

変形の第５の観点は、第１実施形態または第２実施形態において各種データが削除される契機に関する。図１３の処理は、ローカルに保存されているファイルが削除されようとするときに実行され、その結果、管理ＤＢ４００からエントリが削除される。しかし、さらに、共有フォルダからのファイルの削除や電子メールの削除をトリガとして管理ＤＢ４００からエントリが削除されてもよい。

例えば、第２実施形態において、ファイルを削除するためのコマンドまたはメニューが呼び出されて、共有フォルダからファイルが削除されようとするとき、検出部２１３は、上記コマンドまたはメニューの呼び出しを検出してもよい。

この場合、検出部２１３は、（２５−１）のホスト名と（２５−２）のホスト内のフルパスの代わりに、ＵＮＣ形式の共有フォルダのフルパスを、削除されようとするファイルの所在情報として取得する。また、検出部２１３は、取得した共有フォルダのフルパスを検索キーにしてファイル所在テーブル４０２を検索することで、削除されようとするファイルのファイルＩＤを取得する。

そして、検出部２１３は、共有フォルダのフルパスとファイルＩＤを登録部２１２に通知する。すると登録部２１２は、削除されようとするファイルに関するエントリをファイル所在テーブル４０２から削除する。続いて、図１３のステップＳ７０３〜Ｓ７０５と同様の処理が行われる。

また、検出部２１３は、メールユーザエージェント上で、メールボックス内にローカルに保存された電子メールが削除されようとするときに、図１３と類似の処理を行ってもよい。なお、その場合は、電子メール管理テーブル４０３の構成も変形され、図９と図１０の処理も合わせて変形される。具体的には以下のとおりである。

まず、電子メール管理テーブル４０３の各エントリには、「カウンタ」フィールドが追加される。例えば、「Ｍ００００１５」というメッセージＩＤを含むエントリの「カウンタ」フィールドの値は、「Ｍ００００１５」というメッセージＩＤの電子メールがＬＡＮ１１０内で何台のクライアントマシンに保存されているかを示す。

したがって、図９のステップＳ３１０で電子メール管理テーブル４０３に新たに追加される各エントリの「カウンタ」フィールドには、「１」という値が設定される。
同様に、図１０のステップＳ４０４では、電子メール管理テーブル４０３に新たに追加される各エントリの「カウンタ」フィールドに、「１」という値が設定される。また、ステップＳ４０３ではさらに、ステップＳ４０１で取得されたメッセージＩＤと同じメッセージＩＤを含む、電子メール管理テーブル４０３内のすべてのエントリにおいて、「カウンタ」フィールドの値が、１だけインクリメントされる。

そして、メールユーザエージェント上で、ローカルに保存された電子メールを削除するための入力がユーザから与えられたとき、検出部２１３は、当該入力を検出してもよい。そして、検出部２１３による検出をトリガとして、登録部２１２が図１３と類似の処理を開始してもよい。

具体的には、検出部２１３は、削除されようとする電子メールのメッセージＩＤを「Ｍｅｓｓａｇｅ−ＩＤ」ヘッダフィールドから読み取る。また、検出部２１３は、削除されようとする電子メールに１個以上のファイルが添付されている場合は、各添付ファイルのファイル名を「Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ」ヘッダフィールドから読み取る。そして、検出部２１３は、読み取った情報を登録部２１２に通知する。

すると、登録部２１２は、通知されたメッセージＩＤを検索キーにして電子メール管理テーブル４０３を検索する。検索の結果、１個以上のエントリが見つかる。すると、登録部２１２は、見つかった各エントリの「カウンタ」フィールドの値を１だけデクリメントする。

もし、デクリメントの結果、上記の検索の結果として見つかった各エントリの「カウンタ」フィールドの値が０になった場合は、登録部２１２はさらに、次の（３７−１）〜（３７−３）のように動作する。

（３７−１） 登録部２１２は、上記デクリメントにより「カウンタ」フィールドの値を０に更新した各エントリから、添付ファイルのファイルＩＤを読み取る。
（３７−２） 登録部２１２は、上記デクリメントにより「カウンタ」フィールドの値を０に更新した各エントリを、電子メール管理テーブル４０３から削除する。
（３７−３） 登録部２１２は、（３７−１）で読み取った各ファイルＩＤに関して、当該ファイルＩＤを検索キーにして、図１３のステップＳ７０３と同様にファイル所在テーブル４０２を検索する。検索の結果、もしファイル所在テーブル４０２にエントリが見つからなければ、登録部２１２は、図１３のステップＳ７０４と同様にして、メンバテーブル４０１からエントリを削除する。

そして、以上のようにして「カウンタ」フィールドの値がデクリメントされ、さらに、場合によっては（３７−１）〜（３７−３）の処理が行われた後、ユーザからの指示にしたがって電子メールが削除される。
以上説明したような第５の観点からの変形により、不要なエントリが管理ＤＢ４００から削除され、記憶領域がさらに有効に利用される。

変形の第６の観点は、第３実施形態においてファイルがリモートに出力される場合に関する。図１８に関連して、クライアントＰＣ１１２からファイルがリモートに出力される場合の例を（３６−１）〜（３６−５）に挙げたが、他にも、例えば（３８−１）〜（３８−９）のようにして、外来ファイルがリモートに出力される場合があり得る。

（３８−１） クライアントＰＣ１１２において受信済みの、添付ファイルつきの電子メールが、転送される場合。
（３８−２） クライアントＰＣ１１２において受信済みの電子メールの添付ファイルが、直接、ファイルサーバ１１５上の共有フォルダに保存される場合。
（３８−３） クライアントＰＣ１１２において受信済みの電子メールの添付ファイルが、直接、記憶媒体３１０に保存される場合。
（３８−４） 共有フォルダ上のファイルが電子メールに添付され、当該電子メールがクライアントＰＣ１１２から送信される場合。
（３８−５） 記憶媒体３１０上のファイルが電子メールに添付され、当該電子メールがクライアントＰＣ１１２から送信される場合。
（３８−６） 共有フォルダ上のファイルがＨＴＴＰサーバ１２２にアップロードされる場合。
（３８−７） 記憶媒体３１０上のファイルがＨＴＴＰサーバ１２２にアップロードされる場合。
（３８−８） 共有フォルダ上のファイルがＦＴＰサーバ１２３にアップロードされる場合。
（３８−９） 記憶媒体３１０上のファイルがＦＴＰサーバ１２３にアップロードされる場合。

上記（３８−１）〜（３８−９）の場合、ユーザが指示した操作がそのまま実行されると、ユーザの不注意が原因で、外来ファイルへのアクセスを第三者に提供してしまうおそれがある。しかし、図１８の処理によれば、上記（３８−１）〜（３８−９）の場合には警告が出されない。理由は以下のとおりである。

第３実施形態では、システム２００がスタンドアロンシステムなので、ファイル識別情報２３１としてホスト内のフルパスが利用されている。しかし、上記（３８−１）〜（３８−９）の場合には、リモートに出力されようとする外来ファイルには、ファイル識別情報２３１としてのクライアントＰＣ１１２内のフルパスが、対応づけられていない。したがって、図１８の処理によれば、上記（３８−１）〜（３８−９）の場合には警告が出されない。

よって、第３実施形態は以下のように変形されてもよい。すなわち、検出部２１３は、（３８−１）〜（３８−９）のように外来ファイルを一旦ローカルに保存することなく直接リモートに出力しようとするユーザからの入力をさらに検出してもよい。検出のための具体的方法については、第１〜第３実施形態に関する説明から明らかであろう。例えば、検出部２１３は、フックを利用して、（３８−１）〜（３８−９）の場合の入力を検出してもよい。

そして、検出部２１３は、外来ファイルを直接リモートに出力するための入力を検出すると、検出した入力の内容を判定部２１４に通知する。ここで、外来ファイルが直接リモートに出力されようとする場合とは、判定部２１４が外来ファイル管理テーブル４０４を検索するまでもなく、明らかに警告の対象のイベントが発生している場合である。

よって、判定部２１４は、（３８−１）〜（３８−９）の場合に該当する入力を検出した旨を検出部２１３から通知されると、検出部２１３から通知された内容を警告部２２１に出力する。そして、警告部２２１が警告を発する。例えば、警告部２２１は、「外来ファイルが直接第三者に出力されようとしており、情報漏洩のおそれがあります。操作を続行しますか？」などの警告メッセージを含むダイアログを表示してもよい。

また、警告部２２１は、警告に対する入力を入力装置２４０から受け付けるように入力受付部２２２に命令する。すると、入力受付部２２２は図１８のステップＳ１００３と同様に、入力装置２４０からの入力を待つ。

そして、警告に対する禁止入力を入力受付部２２２が受け付けた場合、入力受付部２２２は禁止部２２４に通知を送る。すると、禁止部２２４は、ユーザにより指示された操作をとりやめる。

逆に、警告に対する許可入力を入力受付部２２２が受け付けた場合、入力受付部２２２は非第三者への情報漏洩がないことを許可部２２３に通知する。すると、許可部２２３は、図１８のステップＳ１００７と同様に、ユーザにより指示された操作を許可する。

以上の第６の観点の変形によれば、外来ファイルが直接リモートに出力されようとする場合にも、警告が発せられ、不注意による第三者への情報漏洩が防止される。
変形の第７の観点は、図３のシステム２００がクライアントサーバシステムかスタンドアロンシステムかという点に関する。

第１〜２実施形態はクライアントサーバシステムの例であり、サーバとして図２の管理サーバ１１７が利用される。また、第３実施形態はスタンドアロンシステムの例であり、管理サーバ１１７は不要である。

しかし、第３実施形態を変形したクライアントサーバシステムとして、システム２００が実現されてもよい。つまり、管理サーバ１１７は、クライアントＰＣ１１２〜１１４にそれぞれ対応する３つの外来ファイル管理テーブル４０４を保持してもよい。

そして、管理サーバ１１７は、クライアントＰＣ１１２〜１１４それぞれの登録部２１２と判定部２１４に対して、ＤＢインタフェイスを提供してもよい。または、登録部２１２と判定部２１４が管理サーバ１１７に含まれるように、第３実施形態が変形されてもよい。

あるいは、別の観点から換言すれば、第３実施形態と同様に警告対象のファイルを外来ファイルのみに限定するように、第１実施形態または第２実施形態が変形されてもよい。
また、クライアントサーバシステムとしてシステム２００が実現される場合に、管理ＤＢ４００の一部がクライアントＰＣ１１２〜１１４にバックアップされていてもよい。例えば、管理ＤＢ４００のエントリのうちで、クライアントＰＣ１１２にローカルに保存されているファイルに関するエントリは、クライアントＰＣ１１２にバックアップされていてもよい。

その場合、クライアントＰＣ１１２の判定部２１４は、クライアントＰＣ１１２内にローカルにバックアップされているコピーを参照する。また、クライアントＰＣ１１２の登録部２１２は、管理サーバ１１７上の管理ＤＢ４００とクライアントＰＣ１１２上の管理ＤＢ４００のバックアップコピーの双方を更新する。

あるいは、ファイル所在テーブル４０２のエントリのうち、共有フォルダ上の所在を示すエントリ以外の各エントリは、所在情報のホスト名が示すクライアントマシンに記憶されていてもよい。つまり、ファイル所在テーブル４０２は、クライアントＰＣ１１２〜１１４と管理サーバ１１７に分散されていてもよい。

ところで、クライアントサーバシステムとスタンドアロンシステムの間での共通点と相違点という観点から様々な実施形態について概観すれば、下記のとおりである。
なお、以下の概観においては、図３に関する説明と同様に、当該ファイルに関して記憶装置２３０に登録されているいずれの非第三者でもない一以上の第三者からの、当該ファイルへのアクセスを提供する処理を、「特定の処理」ということにする。そして、特定の処理の実行を指示する入力を「特定の入力」ということにする。つまり、許可入力は上記の一以上の第三者からの当該ファイルへのアクセスを許可する入力であり、禁止入力はそのようなアクセスを禁止する入力である。

さて、クライアントＰＣ１１２〜１１４は同様の構成でよいが、便宜上、クライアントＰＣ１１２について説明する。クライアントＰＣ１１２は、システム２００がクライアントサーバシステムの場合はクライアントマシンとして動作し、システム２００がスタンドアロンシステムの場合はシステム２００全体として動作する。いずれの場合も、クライアントＰＣ１１２は、以下のような保護処理を実行する。

すなわち、クライアントＰＣ１１２は、ファイルの生成元を、当該ファイルに関する非第三者として記憶装置２３０に登録する。そして、クライアントＰＣ１１２は、特定の入力と許可入力の双方が与えられると、上記の一以上の第三者の各々を当該ファイルに関する非第三者として記憶装置２３０に登録するとともに、特定の処理の実行を許可する。

また、クライアントＰＣ１１２は、特定の入力と禁止入力の双方が与えられると、特定の処理の実行を禁止する。より具体的には、クライアントＰＣ１１２は、特定の入力が与えられると警告を発し、警告に対するユーザからの入力として、許可入力または禁止入力を受け付けてもよい。そして、警告に対して禁止入力が与えられたとき、クライアントＰＣ１１２は、特定の処理の実行を禁止してもよい。

ここで、特定の処理の具体例は、例えば、上記の一以上の第三者が宛先に指定されており上記のファイルが添付されている電子メールを送信する処理である。当該処理は、より具体的には、電子メールを新規に作成して送信する処理か、または、受信済みの電子メールを転送（forward）する処理である。

特定の処理の別の具体例は、例えば、上記の一以上の第三者にアクセス権限が与えられているフォルダ（例えばファイルサーバ１１５上の共有フォルダなど）に、上記のファイルを保存する処理である。

特定の処理のさらに別の具体例は、例えば、上記のファイルの生成元が第１の他のコンピュータの場合に、第１の他のコンピュータ以外の第２の他のコンピュータに上記のファイルを転送（transfer）する処理である。例えば、第１の他のコンピュータはＨＴＴＰサーバ１２２またはＦＴＰサーバ１２３でもよく、第２の他のコンピュータは不図示の他のＨＴＴＰサーバまたは不図示の他のＦＴＰサーバでもよい。

なお、非第三者識別情報２３２は、換言すれば、ファイルへのアクセスを許容する対象を示す許可対象情報である。よって、クライアントＰＣ１１２による上記保護処理は、換言すれば、下記（３９−１）と（３９−２）の処理を含む処理である、とも言える。

（３９−１） 記憶装置に記憶されたファイルの転送先を示す転送先情報が、許可対象情報に含まれていない場合に、ファイルの転送前に、転送の実行を許可するか否かの入力を促す処理。
（３９−２） 許可する旨の入力がクライアントＰＣ１１２の入力装置３０５を用いて行われると、許可対象情報に転送先情報を追加するとともに、ファイルの転送を実行する処理。

例えば、（３９−１）の処理を実行する第１の制御手段は、検出部２１３と判定部２１４と警告部２２１により実現されてもよい。また、（３９−２）の処理を実行する第２の制御手段は、入力受付部２２２と許可部２２３と登録部２１２により実現されてもよい。

なお、上述した「特定の処理」の具体例から理解されるように、（３９−１）と（３９−２）に述べた「ファイルの転送」は、具体的には、例えば、（４０−１）〜（４０−３）のいずれの処理による転送（transfer）であってもよい。

（４０−１） 添付ファイルつきの電子メールの送信。
（４０−２） 共有フォルダにファイルを書き込むときに行われる、共有フォルダを有する他のコンピュータ（例えばファイルサーバ１１５）へのファイルの転送。
（４０−３） 他のコンピュータ（例えばＨＴＴＰサーバ１２２またはＦＴＰサーバ１２３）へのファイルのアップロード。

また、上記保護処理においてクライアントＰＣ１１２は、非第三者として登録する生成元を、具体的には以下のようにして認識してもよい。
例えば、クライアントＰＣ１１２は、上記のファイルを新規に作成して保存する操作を検出し、作成操作を行うユーザを生成元として認識してもよい。あるいは、上記ファイルがクライアントＰＣ１１２で受信された電子メールの添付ファイルの場合は、クライアントＰＣ１１２は、受信された電子メールの送信元を生成元として認識してもよい。

また、上記ファイルが共有フォルダから複写されたファイルの場合は、クライアントＰＣ１１２は、上記ファイルを共有フォルダから複写してクライアントＰＣ１１２に保存する操作を検出することで、生成元を認識してもよい。つまり、クライアントＰＣ１１２は、共有フォルダを上記ファイルの生成元として認識してもよいし、共有フォルダへのアクセス権限が与えられている各ユーザを生成元として認識してもよい。

また、上記ファイルが他のコンピュータ（例えばＨＴＴＰサーバ１２２またはＦＴＰサーバ１２３）からダウンロードされたファイルの場合もあり得る。この場合、クライアントＰＣ１１２は、上記ファイルをダウンロードしてクライアントＰＣ１１２に保存する操作を検出してもよい。そして、クライアントＰＣ１１２は、上記他のコンピュータを生成元として認識してもよい。

さらに、上記ファイルは、固有の識別情報が予め割り当てられている記憶媒体３１０から読み込まれたファイルの場合もあり得る。この場合、クライアントＰＣ１１２は、上記ファイルを記憶媒体３１０から読み込む操作（例えば、複写、移動、変名などの操作）を検出し、記憶媒体３１０を生成元として認識してもよい。

以上に例示したような生成元の認識の結果として、生成元を示す非第三者識別情報２３２が記憶装置２３０に登録される。換言すれば、（３９−１）と（３９−２）に述べた「許可対象情報」には、生成元の認識の結果として、何らかの情報が追加される。具体的には、例えば以下の（４１−１）〜（４１−５）のような処理が行われてもよい。

（４１−１） 新規ファイルが作成された場合、新規ファイルを作成して記憶装置に保存する操作を行うユーザを識別する情報（例えばアカウント名）が、新規ファイルに関する許可対象情報に追加される。
（４１−２） 添付ファイルつきの電子メールが受信された場合、電子メールの送信元を識別する情報（つまり電子メールアドレス）が、添付ファイルに関する許可対象情報に追加される。
（４１−３） 共有フォルダ（例えばファイルサーバ１１５上の共有フォルダ）に記憶された共有ファイルが、記憶装置（例えばクライアントＰＣ１１２の記憶装置３０７）に複写または移動される場合がある。この場合、共有フォルダを識別する情報（例えばＵＮＣ形式のパス）が、記憶装置に複写または移動された共有ファイルに関する許可対象情報に追加されてもよい。あるいは、共有フォルダへのアクセス権限が与えられている一以上のユーザをそれぞれ識別する情報（例えばアカウント名）が、記憶装置に複写または移動された共有ファイルに関する許可対象情報に追加されてもよい。
（４１−４） 他のコンピュータ（例えばＨＴＴＰサーバ１２２またはＦＴＰサーバ１２３）上のリモートファイルが、ダウンロードされて記憶装置（例えばクライアントＰＣ１１２の記憶装置３０７）に保存される場合がある。この場合、上記他のコンピュータをネットワーク上で識別する情報（例えばＦＱＤＮまたはＩＰアドレス）が、ダウンロードされたリモートファイルに関する許可対象情報に追加される。
（４１−５） 固有の識別情報（例えばＰｎＰデバイスＩＤ）が予め割り当てられている記憶媒体から、当該記憶媒体に記憶されている既存ファイルが読み込まれて記憶装置（例えばクライアントＰＣ１１２の記憶装置３０７）に保存される場合がある。この場合、固有の識別情報が、記憶装置に保存された既存ファイルに関する許可対象情報に追加される。

ところで、以上の説明からも理解されるとおり、非第三者は、様々な種類の情報により識別され得る。例えば、非第三者は、非第三者としてのユーザの、電子メールアドレスとアカウント名の一方または双方により識別されてもよい。あるいは、非第三者は、非第三者としてのコンピュータを、イントラネット内またはインターネット上で識別するためのコンピュータ識別情報（例えば、ホスト名、ＭＡＣアドレス、ＩＰアドレス、ＦＱＤＮなど）により識別されてもよい。または、非第三者としての記憶媒体３１０に割り当てられており、かつ、記憶媒体３１０自体に記憶されている、記憶媒体識別情報（例えばＰｎＰデバイスＩＤなど）により、非第三者が識別されてもよい。

つまり、（３９−２）の処理において許可対象情報に追加される転送先情報は、以上述べたような、非第三者を識別する情報を用いて表されていてもよい。また、許可対象情報は、クライアントサーバシステムにおいては管理サーバ１１７に記憶され、スタンドアロンシステムにおいてはクライアントＰＣ１１２などに記憶される。

また、非第三者と対応づけられて管理される上記のファイルは、具体的には、クライアントＰＣ１１２がローカルに（つまりクライアントＰＣ１１２の記憶装置３０７に）保存するファイルである。そして、特定の入力と許可入力と禁止入力は、具体的には、クライアントＰＣ１１２に接続された入力装置２４０（つまり入力装置３０５）からクライアントＰＣ１１２に与えられる入力である。

以上概観した点は、クライアントＰＣ１１２がクライアントサーバシステムにおけるクライアントマシンとして動作する場合でも、スタンドアロンシステムとして動作する場合でも、同じである。これら二つの場合での相違点は、例えば、次のとおりである。

クライアントＰＣ１１２がクライアントサーバシステムにおけるクライアントマシンとして動作する場合、クライアントＰＣ１１２は、ファイル識別情報２３１を自ら生成してもよい。あるいは、クライアントＰＣ１１２は、ファイル識別情報２３１の生成を管理サーバ１１７に要求し、管理サーバ１１７からファイル識別情報２３１を取得してもよい。

他方、クライアントＰＣ１１２がスタンドアロンシステムとして動作する場合は、クライアントＰＣ１１２はファイル識別情報２３１を自ら生成してもよいし、クライアントＰＣ１１２内でのファイルのフルパスをファイル識別情報２３１として取得してもよい。

また、クライアントＰＣ１１２がクライアントサーバシステムにおけるクライアントマシンとして動作する場合、図３の記憶装置２３０は、具体的には、クライアントＰＣ１１２とは別のコンピュータである管理サーバ１１７の記憶装置３０７である。そして、この場合、クライアントＰＣ１１２は、入力装置２４０から与えられる入力が特定の入力に該当するか否かを、管理サーバ１１７への問い合わせを行うことによって判定する。管理サーバ１１７への問い合わせとは、具体的には、管理サーバ１１７のＤＢインタフェイスを介して、管理サーバ１１７上の管理ＤＢ４００または外来ファイル管理テーブル４０４を参照する処理である。

他方、クライアントＰＣ１１２がスタンドアロンシステムとして動作する場合は、クライアントＰＣ１１２は、クライアントＰＣ１１２自体がローカルに備える記憶装置３０７を、図３の記憶装置２３０として利用する。例えば、外来ファイル管理テーブル４０４は、クライアントＰＣ１１２の記憶装置３０７に記憶される。

また、システム２００がクライアントサーバシステムの場合にも、図３の登録管理部２１０の実装は実施形態に応じて異なっていてよい。例えば、システム２００が、クライアントＰＣ１１２と管理サーバ１１７を含むクライアントサーバシステムの場合、クライアントＰＣ１１２が実行制御部２２０と入力装置２４０を含み、管理サーバ１１７が記憶装置２３０を含む。しかし、登録管理部２１０は、実施形態に応じて適宜クライアントＰＣ１１２と管理サーバ１１７に分散される。

例えば、ある実施形態では、登録管理部２１０がすべてクライアントＰＣ１１２にあり、管理サーバ１１７は登録部２１２と判定部２１４に対するＤＢインタフェイスを提供するだけでもよい。しかし、別の実施形態では、生成元認識部２１１と検出部２１３がクライアントＰＣ１１２にあり、登録部２１２と判定部２１４が管理サーバ１１７にあってもよい。後者の場合、管理サーバ１１７は、具体的には、プログラムにしたがって以下のような保護処理を実行することで、登録部２１２および判定部２１４として動作してもよい。

管理サーバ１１７は、クライアントＰＣ１１２がローカルに保存するファイルの生成元を、当該ファイルに関する非第三者として記憶装置２３０に登録する。管理サーバ１１７は、例えば、クライアントＰＣ１１２の生成元認識部２１１から生成元の通知を受けてもよい。

また、管理サーバ１１７は、クライアントＰＣ１１２に与えられた入力の内容を知らせる第１の通知をクライアントＰＣ１１２から受信する。そして、管理サーバ１１７（具体的には管理サーバ１１７上に実装された判定部２１４）は、特定の入力がクライアントＰＣ１１２に与えられたのか否かを、受信した第１の通知から判定する。判定のために、管理サーバ１１７は、記憶装置２３０を参照する。

そして、管理サーバ１１７は、「特定の入力がクライアントＰＣ１１２に与えられた」と判定した場合、特定の入力がクライアントＰＣ１１２に与えられたことをクライアントＰＣ１１２に通知する。この通知は、具体的には例えば、警告リストの形でクライアントＰＣ１１２の警告部２２１に通知されてもよい。

そして、管理サーバ１１７（具体的には管理サーバ１１７上に実装された登録部２１２）は、許可入力がクライアントＰＣ１１２に与えられたか否かを示す第２の通知を、クライアントＰＣ１１２から受信する。

また、「特定の入力がクライアントＰＣ１１２に与えられた」と管理サーバ１１７が判定し、かつ、「許可入力がクライアントＰＣ１１２に与えられた」と第２の通知が示す場合、管理サーバ１１７は、次のように動作する。すなわち、管理サーバ１１７（具体的には管理サーバ１１７上に実装された登録部２１２）は、許可入力により上記ファイルへのアクセスが許可された一以上の第三者の各々を、当該ファイルに関する非第三者として記憶装置２３０に登録する。

以上説明した様々な実施形態のいずれにおいても、次のような効果が得られる。
すなわち、電子メールに関するポリシーや共有フォルダに関するポリシーなどの種々のポリシーを、個別に事前設定する必要がないので、ユーザや管理者などの負担が小さい。また、特定の処理の実行自体が全面的に禁止されるわけではないので、作業効率が極端に悪化するようなこともないし、ユーザが著しい不便を感じることもない。さらに、非第三者の自動登録により、過剰な警告の発生も抑制され、ユーザが警告に対して入力を与える手間も軽減される。

以上のように、ユーザの被る不利益はごくわずかである。それにもかかわらず、上記の様々な実施形態によれば、ユーザの不注意に起因する情報漏洩は、防止される。なぜなら、実際にファイルが第三者からアクセス可能な状態になる前に、ユーザには、「許可入力を与えるか否か」を意識的に考える機会が与えられるからである。

最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
コンピュータに、
記憶装置に記憶されたファイルの転送先を示す転送先情報が、前記ファイルへのアクセスを許容する対象を示す許可対象情報に含まれていない場合に、前記ファイルの転送前に、転送の実行を許可するか否かの入力を促し、
許可する旨の入力が該コンピュータの入力手段を用いて行われると、前記許可対象情報に前記転送先情報を追加するとともに、前記ファイルの転送を実行する、
処理を実行させることを特徴とする制御プログラム。
（付記２）
前記ファイルの前記転送の実行を禁止する旨の入力が前記入力手段を用いて行われると、前記ファイルの前記転送を禁止する
ことを前記処理がさらに含むことを特徴とする付記１に記載の制御プログラム。
（付記３）
前記転送先情報は、電子メールアドレスにより表され、
前記電子メールアドレスが宛先に指定されており前記ファイルが添付されている電子メールの送信により、前記ファイルが転送される
ことを特徴とする付記１または２に記載の制御プログラム。
（付記４）
前記ファイルの前記転送は、一以上のユーザにアクセス権限が与えられている共有フォルダに前記ファイルを書き込むときに行われる、前記共有フォルダを有する他のコンピュータへの前記ファイルの転送であって、
前記転送先情報は、前記一以上のユーザをそれぞれ識別する情報を含む
ことを特徴とする付記１または２に記載の制御プログラム。
（付記５）
前記転送先情報は、前記ファイルの転送先の他のコンピュータをネットワーク上で識別する情報により表される
ことを特徴とする付記１または２に記載の制御プログラム。
（付記６）
新規ファイルを作成して前記記憶装置に保存する操作を検出し、
前記操作を行うユーザを識別する情報を、前記新規ファイルに関する許可対象情報に追加する
ことを前記処理がさらに含むことを特徴とする付記１から５のいずれか１項に記載の制御プログラム。
（付記７）
添付ファイルつきの電子メールの受信を検出し、
前記電子メールの送信元を識別する情報を、前記添付ファイルに関する許可対象情報に追加する
ことを前記処理がさらに含むことを特徴とする付記１から５のいずれか１項に記載の制御プログラム。
（付記８）
共有フォルダに記憶された共有ファイルを前記記憶装置に複写または移動する操作を検出し、
前記共有フォルダを識別する情報、または、前記共有フォルダへのアクセス権限が与えられている一以上のユーザをそれぞれ識別する情報を、前記記憶装置に複写または移動された前記共有ファイルに関する許可対象情報に追加する
ことを前記処理がさらに含むことを特徴とする付記１から５のいずれか１項に記載の制御プログラム。
（付記９）
他のコンピュータ上のリモートファイルを、ダウンロードして前記記憶装置に保存する操作を検出し、
前記他のコンピュータをネットワーク上で識別する情報を、ダウンロードされた前記リモートファイルに関する許可対象情報に追加する
ことを前記処理がさらに含むことを特徴とする付記１から５のいずれか１項に記載の制御プログラム。
（付記１０）
固有の識別情報が予め割り当てられている記憶媒体から、該記憶媒体に記憶されている既存ファイルを読み込んで前記記憶装置に保存する操作を検出し、
前記固有の識別情報を、前記記憶装置に保存された前記既存ファイルに関する許可対象情報に追加する
ことを前記処理がさらに含むことを特徴とする付記１から５のいずれか１項に記載の制御プログラム。
（付記１１）
前記許可対象情報に追加される前記転送先情報は、
前記ファイルの転送によって前記ファイルへアクセス可能となるユーザの、電子メールアドレスとアカウント名の一方もしくは双方、
前記ファイルの転送先にある他のコンピュータを、イントラネット内またはインターネット上で識別するためのコンピュータ識別情報、または
前記ファイルが転送される記憶媒体に割り当てられており前記記憶媒体に記憶されている記憶媒体識別情報
を用いて表されることを特徴とする付記１から１０のいずれか１項に記載の制御プログラム。
（付記１２）
前記処理がさらに、前記ファイルを識別するファイル識別情報を生成または取得することを含み、
前記許可対象情報は、個々のファイルごとに、当該ファイルの前記ファイル識別情報と対応づけられている
ことを特徴とする付記１から１１のいずれか１項に記載の制御プログラム。
（付記１３）
前記許可対象情報は、個々のファイルごとに、前記コンピュータにローカルに記憶されている
ことを特徴とする付記１から１２のいずれか１項に記載の制御プログラム。
（付記１４）
前記許可対象情報は、個々のファイルごとに、他のコンピュータに記憶されており、
前記転送先情報が前記許可対象情報に含まれているか否かを判定する処理と、前記許可対象情報に前記転送先情報を追加する処理は、前記他のコンピュータを介して行われる
ことを特徴とする付記１から１２のいずれか１項に記載の制御プログラム。
（付記１５）
第１のコンピュータに、
第２のコンピュータの記憶装置に記憶されたファイルの転送先を示す転送先情報を前記第２のコンピュータから受信し、
前記転送先情報が、前記ファイルへのアクセスを許容する対象を示す許可対象情報に含まれていない場合に、前記第２のコンピュータに対して、前記ファイルの転送前に、転送の実行を許可するか否かの入力を促すよう、命令し、
前記入力の内容を、前記第２のコンピュータから受信し、
前記入力の前記内容が、前記転送を許可する旨である場合、前記許可対象情報に前記転送先情報を追加する、
処理を実行させることを特徴とする制御プログラム。
（付記１６）
入力手段および記憶手段と接続される情報処理装置であって、
前記記憶手段に記憶されたファイルの転送先を示す転送先情報が、前記ファイルへのアクセスを許容する対象を示す許可対象情報に含まれていない場合に、前記ファイルの転送前に、転送の実行を許可するか否かの入力を促す第１の制御手段と、
許可する旨の入力が前記入力手段を用いて行われると、前記許可対象情報に前記転送先情報を追加するとともに、前記ファイルの転送を実行する第２の制御手段と、
を備える情報処理装置。
（付記１７）
コンピュータが、
記憶装置に記憶されたファイルの転送先を示す転送先情報が、前記ファイルへのアクセスを許容する対象を示す許可対象情報に含まれていない場合に、前記ファイルの転送前に、転送の実行を許可するか否かの入力を促し、
許可する旨の入力が該コンピュータの入力手段を用いて行われると、前記許可対象情報に前記転送先情報を追加するとともに、前記ファイルの転送を実行する、
ことを特徴とする方法。

１１０ ＬＡＮ
１１１ ルータ
１１２〜１１４、１２４ クライアントＰＣ
１１５ ファイルサーバ
１１６、１２１ メールサーバ
１１７ 管理サーバ
１２０ ネットワーク
１２２ ＨＴＴＰサーバ
１２３ ＦＴＰサーバ
２００ システム
２１０ 登録管理部
２１１ 生成元認識部
２１２ 登録部
２１３ 検出部
２１４ 判定部
２２０ 実行制御部
２２１ 警告部
２２２ 入力受付部
２２３ 許可部
２２４ 禁止部
２３０ 記憶装置
２３１ ファイル識別情報
２３２ 非第三者識別情報
２４０ 入力装置
３００ コンピュータ
３０１ ＣＰＵ
３０２ ＲＯＭ
３０３ ＲＡＭ
３０４ 通信インタフェイス
３０５ 入力装置
３０６ 出力装置
３０７ 記憶装置
３０８ 駆動装置
３０９ バス
３１０ 記憶媒体
３１１ ネットワーク
３１２ プログラム提供者
４００、４００ａ〜４００ｇ 管理ＤＢ
４０１、４０１ａ〜４０１ｇ メンバテーブル
４０２、４０２ａ〜４０２ｇ ファイル所在テーブル
４０３、４０３ａ〜４０３ｇ 電子メール管理テーブル
４０４ 外来ファイル管理テーブル

Claims (8)

1. コンピュータに、
   記憶装置に記憶されたファイルの転送先を示す転送先情報が、前記ファイルへのアクセスを許容する対象を示す許可対象情報に含まれていない場合に、前記ファイルの転送前に、転送の実行を許可するか否かの入力を促し、
   許可する旨の入力が該コンピュータの入力手段を用いて行われると、前記許可対象情報に前記転送先情報を追加するとともに、前記ファイルの転送を実行する、
   処理を実行させることを特徴とする制御プログラム。
2. 前記ファイルの前記転送の実行を禁止する旨の入力が前記入力手段を用いて行われると、前記ファイルの前記転送を禁止する
   ことを前記処理がさらに含むことを特徴とする請求項１に記載の制御プログラム。
3. 前記転送先情報は、電子メールアドレスにより表され、
   前記電子メールアドレスが宛先に指定されており前記ファイルが添付されている電子メールの送信により、前記ファイルが転送される
   ことを特徴とする請求項１または２に記載の制御プログラム。
4. 前記ファイルの前記転送は、一以上のユーザにアクセス権限が与えられている共有フォルダに前記ファイルを書き込むときに行われる、前記共有フォルダを有する他のコンピュータへの前記ファイルの転送であって、
   前記転送先情報は、前記一以上のユーザをそれぞれ識別する情報を含む
   ことを特徴とする請求項１または２に記載の制御プログラム。
5. 新規ファイルを作成して前記記憶装置に保存する操作を検出し、
   前記操作を行うユーザを識別する情報を、前記新規ファイルに関する許可対象情報に追加する
   ことを前記処理がさらに含むことを特徴とする請求項１から４のいずれか１項に記載の制御プログラム。
6. 添付ファイルつきの電子メールの受信を検出し、
   前記電子メールの送信元を識別する情報を、前記添付ファイルに関する許可対象情報に追加する
   ことを前記処理がさらに含むことを特徴とする請求項１から４のいずれか１項に記載の制御プログラム。
7. 入力手段および記憶手段と接続される情報処理装置であって、
   前記記憶手段に記憶されたファイルの転送先を示す転送先情報が、前記ファイルへのアクセスを許容する対象を示す許可対象情報に含まれていない場合に、前記ファイルの転送前に、転送の実行を許可するか否かの入力を促す第１の制御手段と、
   許可する旨の入力が前記入力手段を用いて行われると、前記許可対象情報に前記転送先情報を追加するとともに、前記ファイルの転送を実行する第２の制御手段と、
   を備える情報処理装置。
8. コンピュータが、
   記憶装置に記憶されたファイルの転送先を示す転送先情報が、前記ファイルへのアクセスを許容する対象を示す許可対象情報に含まれていない場合に、前記ファイルの転送前に、転送の実行を許可するか否かの入力を促し、
   許可する旨の入力が該コンピュータの入力手段を用いて行われると、前記許可対象情報に前記転送先情報を追加するとともに、前記ファイルの転送を実行する、
   ことを特徴とする方法。

Images