JP5069308B2 - 不適切なコードおよびデータの拡散防止における改善 - Google Patents

Description

本発明は、不適切なコードおよびデータの拡散を防止するコンピュータシステムと、それらシステムをオペレーションする方法とに関する。特に、本発明は出願人による英国特許出願０５１１７４９．４に記載されたシステムと方法の改善である。

過去１０年間、コンピュータシステムは、不適切なコードの攻撃を受けることが多くなっている。（現在までの）不適切コードの最も極端な例は、コンピューターウイルスである。コンピューターウイルスは、同名の生物ウイルスのように、１台のマシンに感染し、次にそこから、電子メールシステムの情報源を乗っ取ることによって、他のコンピュータに感染することができる。その結果、ウイルスが侵入した各コンピュータのアドレス帳を用いて、ウイルスを含む電子メールが、１台のコンピュータから他の多くのコンピュータに送信される。その結果、帯域幅が浪費され、これがユーザにとって頭痛の種となっている。更に、多くのウイルスは、侵入した各コンピュータにおいて、例えばファイルの消去など、好ましくない動きをする。

ウイルスおよびその他の悪意のあるコンテンツは、典型的には、別個の添付ファイルで到来する。しかし、ウイルスは、電子メールの一部に隠されていることもあり、明確なコードの分離や実行をユーザに要求することなく、活動するようになる。ワードプロセッサ、スプレッドシート、データベースなどの多くのアプリケーションには、強力なマクロスクリプト言語が含まれている。マクロスクリプト言語は、ドキュメントやファイルに、特定の動作を行うことができるスクリプトを含ませることが可能である。ウイルスの作者は、マクロウイルスを書くためにそのようなスクリプト言語を利用し、そして、ドキュメントやファイルを含む電子メールの添付物が、隠蔽ウイルスの隠れ場所となる。

ウイルスは、不適切なコードが唯一の形態ではない。「無料」のプログラムが、隠された「スパイウェア」とともによく配布される。スパイウェアは、例えば、ユーザのコンピュータに密かにインストールされる。スパイウェアは、その後、訪れたウェブサイトや他のトランザクションを遠隔のコンピュータに報告する可能性がある。スパイウェアのうちの或るものは、好ましくない広告を表示させる。また、或るスパイウェアは、モデムが高額料金の番号を繰り返しダイアルするようにし向けて、スパイウェアの作者が遠距離通信オペレータから収入を受け取る。その他の有害な種類のコードとしては、マルウェア、ワーム、トラップドアなどがある。

ウイルスが、或るコンピュータから他のコンピュータへと自己増殖する一方で、スパムメール（無差別広告メール）やディスク上での隠れた配布によって、或いは、益々増加する何の気なしに開いたウェブサイトからのダウンロードによって、ウイルス以外の形態の不適切コードが配布されている。この種の不適切コードは、全て共通して、その存在や真の目的が隠匿され、ターゲットとなったコンピュータの所有者やユーザには分からないという事実である。或る種のものは比較的害が少ないが、貴重なビジネスデータを一掃する能力をもつものもあり、これ故に、ウイルス除去ソフトウェアを提供する産業が発展してきた。

現在知られているアンチウイルス（ウイルス駆除）ソフトウェアは、保護されるコンピュータ上で実行されるプログラムから構成される。このようなプログラムは、典型的には、モニタモードとスキャンモードとで動作する。上記モニタモードでは、アクセスされるファイルに対して、そのファイルへアクセスされるたびにウイルスチェックが行われる。上記スキャンモードでは、（ディスクドライブなどの）特定な場所の全てのファイルがスキャンされる。アンチウイルスプログラムのプロバイダは、ウイルスの発生を監視していて、新しいウイルスが検出されると、アンチウイルスプログラム会社は、ウイルスを解析し、ウイルスを検出するのに使用できるデータを抽出する。次いで、このデータは、当該特定のアンチウイルスプログラムを実行するコンピュータが利用できるものとされる。すなわち、上記プログラムは、典型的には、アンチウイルスプログラム会社のウェブサイト上に提供され、ダウンロードすることによって、上記プログラムの実行が図られる。

ウイルスは種々様々な方法で検出される。ウイルスの一部を形成する一連の特徴コードを保存することができる。また、上記一連の特徴コードの存在に対してスキャンされたファイルを保存することができる。すなわち、上記一連の特徴コードは、ウイルスに対する「サイン」または「指紋」として機能する。これに代わって、ウイルスは、それが意図する挙動によって検出することができる。また、ソースコードやスクリプトファイルを解析して、ウイルスの特徴である所定動作を検出してもよい。

ウイルスは、不幸にも、生物のウイルスと同様、容易に「変化」できる。大文字や小文字の置換に相当するようなコードの小さな変化によって、ウイルスのサインを変化させることができる。したがって、如何なる方法であれ、ウイルスを検出するためのデータファイルは、極めて大きなものとなっている。また、アンチウイルスプログラムに費やされる時間は、チェックすべきサインや規則の数が大きくなるにつれて、それに対応して、増大している。この時間の増大は、ウイルススキャンモードでは許可できるかもしれないが、モニタモードでは、ファイルへのアクセス所要時間に対して、絶えず増加する待ち時間が付加される。更に、ダウンロードがより大きなものとなるにつれて、また、より頻繁に必要になるにつれて、ユーザが必要な最新情報をダウンロードし損なって、したがって、最も新しい（したがって最も危険な）ウイルスに対して無防備となる危険性が高い。

したがって、本発明は、不適切なコードに抗した保護への全く異なるアプローチを取るものである。本発明の一側面によれば、所定のデータフォーマットのコンテンツデータを含む電子ファイルを受信する方法であって、上記電子ファイルを受信するプロセスと、上記データフォーマットを判定するプロセスと、上記コンテンツデータを構文解析するプロセスとを備え、上記コンテンツデータが上記所定のデータフォーマットに一致するか否かを判定し、上記コンテンツデータが上記所定のデータフォーマットに一致している場合、上記構文解析されたデータを再生して上記データフォーマットにて再生電子ファイルを生成する。

対応するコンピュータシステム、プログラム、およびそのようなプログラムを載せる媒体も提供される。

本発明の一実施形態は、それぞれの受信されたファイルを解析し、次いでそれから代替ファイルを再構成するように動作する。オリジナルファイル自体は保護すべきコンピュータ上に直接保存されたりアクセスされたりしないため、オリジナルファイルはそれ自体ではそのコンピュータに害を及ぼすことはできない。オリジナルファイルは、例えば、それが実行できないビット反転形式その他の形式で保存される。一方、上記代替ファイルは、「クリーンな」コードおよびデータしか生成することができないジェネレータルーチンを使用して生成される。したがって、受信されたファイル内のコードがどのようなコードであってもそれに対応した不適切コードを生成することはできない。

本発明の一部は、コンピュータファイルに関する幾つかの長く知られている真実の新たな応用にその根拠を置くことができる。最近ではコンピュータにインポートされる大多数のファイルが標準化されたファイルフォーマットである。独自に開発したプログラムは、それら自身のファイルフォーマットを作り出している（そしてそれらのプログラムによって使用されることを予定しているデータはそれらのフォーマットに一致しなければならない）が、異なる独占プログラム間のデータの交換に対しては少なからぬ需要がある。すなわち、第一に、１つの独占プログラムには別の独占プログラムによって書かれたデータを読み込むためのインポートフィルタがたいてい供給されており、第二に、如何なる独占プログラムにも関連づけられていない幾つかのフォーマットが存在する。そのような汎用的なフォーマットの例としては、ＡＳＣＩＩテキスト、リッチテキストフォーマット（ＲＴＦ）、ハイパーテキストマークアップランゲージ（ＨＴＭＬ）、およびエクステンシブルマークアップランゲージ（ＸＭＬ）がある。

したがって、ファイル中のデータは、それが任意のアプリケーションプログラムによって読み込まれることになっており、かつ様々なファイルで使用される各フォーマットが広く知られているものであるならば、厳格な規格に精確に従っていなければならない。本発明者らは、各ファイルによって使用される各フォーマットは幅広く変化することを許可しているが、大多数のファイルには幾つかの比較的狭い実用的な制約を満たすデータが含まれているということに気づいた。例えば、ほとんどのオペレーティングシステムおよびアプリケーションは、かなりの長さのファイルタイトルを受け入れるが、ほとんどのユーザが、たいてい短くて容易に認識できるファイル名を使用する。

したがって、本発明の一実施形態によって行われる解析は、表明されたファイル形式の仕様にそれ以外では一致しているデータが、実用的な限界に違反しているか否かを検出することを含むものとすることができる。これらの「現実世界」の制約は、本発明が「正常な」受け入れ可能なファイルを検出することを可能にする。このタイプの実用的な限界に対応していない如何なるファイルコンテンツもジェネレータプログラムに渡されることはなく、したがってユーザのコンピュータに実行可能な形式において到達することはない。

したがって、本発明の一実施形態は、周知のアンチウイルスプログラムとは基本的に異なった様式で動作するものであることが分かるであろう。周知のアンチウイルスプログラムは、ウイルスを検出することを狙いとしており、ウイルスであることが検出されない全てのものを通過させる。したがって、それらのプログラムは最大の危険から、すなわち未知のウイルスの危険からユーザを保護することに必ず失敗する。新参のウイルスはそれぞれ、ウイルス対策会社の注目するところとなる前に、既に多くのコンピュータに感染してしまうに違いない。

更に、ウイルス対策ソフトウェアがインストールされ、検出済みデータの最新版を保有している場合でも、ウイルスは、そのウイルス対策ソフトウェアによって検出可能となる前に、通常、保護されるコンピュータのハードドライブその他の媒体に保存されるであろう。何らかの理由でウイルス対策ソフトウェアが動作しないと、そのウイルスは適当な場所にあって活性化される可能性がある。

米国公開特許出願ＵＳ２００３／０１４５２１３は、ファイル内においてマクロまたは悪意のあるコードを検出するシステムを開示している。そのファイルは、その後、テンプレートで再構築され、その悪意のあるコードがテンプレートから除去されて、上記ファイルの汚染されていないバージョンを提供する。

全く対照的に、本発明は、ウイルスを検出することも、また代表的なウイルス様の挙動を拒絶することすらも、その狙いとする必要がない。その代わりに、全ての入力ファイルを完全に拒絶することができ、可能な場合はそれらのファイルを、不適切なコードおよびデータを含ませることができない生成ファイルに代替させる。したがって、不適切なコードおよびデータが、保護すべきコンピュータのハードドライブに実行可能な形式で到達することを防ぐことができ、それらが１台のコンピュータから別のコンピュータへ伝染することは不可能となる。さらに、本発明は、全ての既知ウイルスの最新データベースを維持することを必要とすることなく、未知のウイルスから守る「ゼロ・デイ」プロテクションを提供する。

ここで、米国公開特許出願２００３／２２９８１０が、ウイルスに対する保護策として「光学式ファイアウォール」の提案を開示している。この後すぐに明白になるであろう理由により、このシステムは実施に移された（または、実施に移すことができたものである）とは考えられない。その公開出願には、ファイアウォールコンピュータが画像ファイルなどのファイルを受け取って、そのファイアウォールコンピュータのディスプレイ上にその画像を表示するシステムが記載されている。光学式センサアレイが画像をスキャンし、スキャンされた画像が相手の受信者に与えられる。画像内に隠されたウイルスはどれも表示されず、したがってスキャンされた画像においてウイルスであるとは判定されない。変形例として、スクリーンのビットマップを実際のスクリーン表示の代わりに使用する場合もある。

様々な理由から、上述の米国特許出願において提供される「光学式カプラ」ファイアウォールは、ウイルスに対する有効かつ信頼できる保護を提供することはできないであろう。

例えば、光学式文字認識（ＯＣＲ）ソフトウェアを使用した再現は、不適切な情報を提供する可能性がある。更に、ビデオ技術を使用した画像の再現は、意図したより低い品質の画像を提供する可能性がある。また、入力ファイルがウイルスを含む場合、その入力ファイルを受信するコンピュータが感染してしまうであろう。

他方、再生ファイルを実行し、表示し、光学スキャンする代わりに、それらのファイルを解析し、次に、再生することにより、本発明の一実施形態は、大多数の場合、オリジナルファイル（それに不適切コードがないならば）と匹敵する代替ファイルをその代替が透明になるようなしかたで提供することができる。

ファイルフォーマットは、それらの複雑さにばらつきがある。一方の極において、テキストファイルは単純なフォーマットを有する。スクリプトやマクロを含むことができるファイル（ワードプロセッサやスプレッドシートファイルなど）は、中間的な複雑さのものであるが、コードを含むファイルはコードパーサ（コード構文解析ツール）によってしか完全に解析することができない。本発明によればそのようなコード解析は結局可能となるが、本発明の実施形態は、その１つの利便性として、ドキュメントファイルから全てのマクロとスクリプトを除去し、プログラム、コード、マクロまたはスクリプトだけから成る如何なるファイルも通過させないように動作することもできる。

ユーザが上記のようなファイルを受信することを望む場合も頻繁におこるであろうことは容易に想像がつく。したがって、１つの好ましい実施形態においては、本発明は、特定のソースに由来するファイル（または特定の形式のファイル）は常時通過させ、他のソースに由来するファイルは拒絶するように、ソースによってファイルをフィルタリングするように構成したフィルタと同時並行で動作するようにしてもよい。

このように、本発明の実施形態は全てのソースからのファイル内のコードを受信することをブロック（阻止）する一方で、並列フィルタが既知のソースからだけの上記ファイルを許可する。したがって、ユーザは、本発明によって拒絶されるであろう、例えば、システム管理者や公認されたウェブサイトからのファイルを受信することができる。ユーザがコードを受信することを望むそれらのソースのみを識別することにより、本発明は不適切コードを阻止することができる。

本発明はウイルスを検出することより、むしろファイル規格との一致および代表的なユーザの対応を検出することによって機能することが可能となるため、頻繁な更新は不要である。そのような更新が必要となるのは、ある規格に対する大きな変更が広範囲に受け容れられたとき、あるいはユーザの対応が実質的に変化したときだけであり、これらはいずれもウイルス対策の更新版を配布しなければならないときの大急ぎのスピードと比べるとスローな処理過程である。同様に、実行すべきテストの回数が時間の経過とともにほぼ安定して維持されるため、プログラム起動のための待ち時間も時の経過によって全く増加しない。

本発明の他の態様、実施形態、利点は以下の説明および特許請求の範囲で論ずる。発明の実施形態は、添付の図面を参照して、例証としてのみ記載されている。
本発明の一実施形態による電子ファイルシステムのブロック図を示す。 本発明の実施形態での使用に適したコンピュータシステムを示す。 本発明の一実施形態によるプロセスのフローチャートを示す。 本発明の一態様による開発と試験の方法のフローチャートを示す。 図４に示す開発と試験の方法の一例の概略図である。 本発明のもう一つの態様による開発と試験の方法の概略図である。 本発明の第２の実施形態による電子メールシステムのブロック図を示す。 本発明の第２の実施形態によるプロセスのフローチャートを示す。 電子メールを形成する異なる部分のレイアウトの例を示す。 本発明の第３の実施形態によるプロセスのフローチャートを示す。

［第１の実施形態］
図１は、本発明の第１の実施形態による基本システムのレイアウトを概略的に示す。電子ファイルは、ソース１０２で生成され、伝送媒体１０３を介して伝送される。伝送媒体１０３としては、例えば、有線システムや無線システム或いはネットワークなどの電子ファイルを伝送するのに適した媒体を用いることができる。電子ファイルは、通常の方式で伝送媒体１０３を通過して送信先に到達する。本実施形態では、ＡＶ（アンチウイルス）アプリケーション１０５が送信先のシステム１０９にインストールされている。到来する電子ファイル内のデータは、解析されて許可できると決定されたならば再生されるがそのときまで、ＡＶアプリケーション１０５が作動して、送信先のシステム１０９のオペレーティングシステム１０７への進入が許可されない。後述するように、受信される電子ファイルの或る部分は所定の許可可能フォーマットに照らして解析される。受信される電子ファイルの他の部分については、ハッシュが創成され、悪意のないコンテンツと前もって識別されたハッシュ・データベース１０６内で調べられる。ＡＶアプリケーション１０５は、一致解析装置１３１と、ハッシュ・ジェネレータ（ハッシュ発生装置）１３３と、ハッシュ・チェッカ１３４と、コンテンツ・リジェネレータ（コンテンツ再生装置）１３５とを有して、電子ファイル１０１がオペレーティングシステム１０７に通過許可できるかどうかを決定し、また、許可可能なコンテンツを再生している。

図２は、図１に示す受信先のシステム１０９を実行するようになっているコンピュータシステムを示すブロック図である。上記システム１０９は、入力インタフェース１１１において、到来する電子ファイル１０１を受信する。入力インタフェース１１１はマイクロプロセッサ１１３に接続されている。マイクロプロセッサ１１３は、受信されたファイルに対して、様々なプロセスを実行するように構成されている。マイクロプロセッサ１１３は、受信した電子ファイル内のコンテンツを構文解析するためのパーサ（構文解析ツール）１１５を含んでいる。マイクロプロセッサ１１３は、更に、メモリ装置１１７と着脱式媒体ドライブ１１９とに接続されていて、ＣＤ１２０やフロッピーディスク（図示せず）のような着脱式媒体からデータを読み込んだり、媒体にデータを書き込んだりする。マイクロプロセッサ１１３は、また、ディスプレイ１２５やキーボード１２７などの出力装置への接続を可能にする幾つかのインタフェース（１２１、１２３）に接続されている。

到来した実行可能なファイルがＡＶアプリケーション内に入ったときに自動的に実行されることがないように、本システムでは、到来する電子ファイルを構成するデータを、何らかの適切なスクランブル（暗号化）フォーマットで、メモリに格納するようになっている。

この実施形態では、スクランブル法によって、１バイト内のビットの順序が反転されている。すなわち、ビット０〜７は順序通りに受け取られるが、ビット反転方式で格納され、ビット０がビット７に転換され、ビット１がビット６に転換され、ビット２がビット５に転換され、ビット３がビット４に転換される。したがって、例えば、１０１１００００から成る１バイトの場合、００００１１０１の順序で格納される。このようにして、如何なる実行可能なコードも自動的に実行されることが不可能となり、したがって、如何なる既感染電子ファイルもＡＶアプリケーションまたは送信先のオペレーティングシステムに感染することができない。

図３は、電子ファイル１０１が送信先のオペレーティングシステム１０７への通過が許可されるか否かを決定すべく、この実施形態においてＡＶアプリケーション１０５が実行する処理ステップのフローチャートを示している。ステップＳ３−１では、電子ファイル１０１が、任意の適切な手段を用いて、ＡＶアプリケーション１０５に入力され、また、ＡＶアプリケーション１０５によって受信される。この入力手段は、受け取られる電子ファイルの種類と、電子ファイルが伝送される媒体とに依って、変えることができる。この実施形態においては、電子ファイル１０１はＡＶアプリケーション内に受け入れられる。

この実施形態では、システム１０９によって受信される電子ファイル１０１は、ＡＶアプリケーション１０５が解析する一つ以上のコンテンツデータ部分を含んでいる。コンテンツデータのこの部分は、パッシブ（受動）コンテンツデータであり得る。上記パッシブ・コンテンツデータは、例えば、テキストやイメージやオーディオやビデオのコンテンツといった所定の目的をもつデータタイプのコンテンツである。

この実施形態では、ＡＶアプリケーションは、既知で許可可能な予め定義された複数の格納済フォーマットのうちの１つに一致する電子ファイルのみを通過できるように、設計されている。また、ＡＶアプリケーションは、悪意のないものとして識別されたアクティブ（能動）コンテンツデータのみを通過できるように、設計されている。一例として、電子ファイルはコンテンツデータから構成される。上記コンテンツデータは、特定の一連の規則から成るファイル形式の仕様にしたがって符号化され配列される。ファイルの各形式（テキスト、ＨＴＭＬ、ＸＭＬ、スプレッドシートなど）は関連する一連の規則を有する。一般的なファイルの形式は、しばしば、ファイル名の末尾語（例えば、.ｐｄｆや.ｔｘｔや.ｄｏｃ）によって示される。或いは、それに代わって、ファイル中の初めの数バイトのデータによって示されることがある。ファイルの形式の多くは、ファイル構造に関するものを示すヘッダを含み、次にコンテンツデータ（例えば、テキスト、数字、音声または画像のデータ、スクリプト、マクロ）が続く。電子ファイル１０１はコンテンツデータの複数の部分を含み得る。その部分の或るものはパッシブ・コンテンツであり、また、或るものはアクティブ・コンテンツである。

パッシブ・コンテンツデータは、パラメータ（例えば、コンテンツデータがボールド体で表示されることを示すタグ）を含んでもよい。ファイル形式の仕様を構成する規則は、そのようなパラメータが取ることのできる値や範囲を指定するものとしてよい。それらの規則は、例えば、コンテンツデータが取り得る許可値または許可範囲値を指定するものとしてもよい。

当業者が認識するように、特定の形式のファイルを開くことができるアプリケーションプログラムが、ファイル形式の仕様を構成する規則をファイルに適用するために、パーサ（構文解析ツール）を含んでいて、コンテンツデータを抽出して表示または処理することは知られている。例えば、ワードプロのアプリケーションは、ファイルを、その工業所有権が保護されたファイルフォーマット（例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ（登録商標））で開くことができる。また、その他のワードプロのアプリケーションの所有権保護されたファイルフォーマットでファイルを開くことができるし、リッチテキストフォーマット（ＲＴＦ）やＡＳＣＩＩやＨＴＭＬなどの一般的なファイルフォーマットでも、ファイルを開くことができる。特定の形式のファイルとしてコンテンツデータを格納できるアプリケーションプログラムは、ファイル形式の仕様を構成する規則をパッシブ・コンテンツデータに適用するためのジェネレータを含んでいて、ファイルを所要のフォーマットで作成する。

本実施形態では、各ファイル形式に対して、所定のフォーマットが格納されている。この所定のフォーマットは、通常、そのファイル仕様を構成する規則を含んでいる。しかし、所定のフォーマットは、頻繁に使用されるフォーマット（の一部分）に関連した規則を含んでいるに過ぎない。更に、所定のフォーマットは、一般的かつ頻繁に使用される値と範囲を含むだけのものとなるように、追加規則を含んで、コンテンツおよびパラメータが取り得る数値や範囲を制約する。このようにして、パッシブ・コンテンツの所定形式のファイルの一部分のみが、それらは専ら日常的に頻繁に発生するデータとパラメータとから成るが、本実施形態の対応する格納済の所定フォーマットによって、解析され得る。

システムを通過するのを許可されないパッシブ・コンテンツのデータタイプの構成要素の例としては（何故ならば、稀にしか使用されないので、所定のフォーマットはそれらに関する規則を含んでいないからである）、ＨＴＭＬ頁におけるＩフレームと、ＭＰ３ファイルにおけるジェネラル・カプセル化オブジェクト（ＧＥＯＢ）のタグとがある。稀にしか使用されなくてシステムを通過することが許可されないデータ値の例としては、一般的に使用されるＴＡＢ、ＣＢ／ＬＦ、およびＬＦ文字以外には、ＡＳＣＩＩファイル内の制御文字がある（所定のフォーマットは上記データ値を除外した値に限定される）。

コンテンツデータは、アクティブ・コンテンツのデータでもよい。一例として、受信した電子ファイル１０１はＨＴＭＬページであって、このＨＴＭＬページは、ＨＴＭＬタグを有する幾つかのアクティブ・コンテンツデータの部分と、関連するテキストのコンテンツと、ジャバスクリプトやＶＢスクリプトファンクションのような実行可能な少なくとも１つのアクティブ・コンテンツデータの部分とを含む。上記アクティブ・コンテンツデータは、また、受信電子ファイル１０１に関連する特定のルールセットから決定されてもよい。例えば、ＨＴＭＬドキュメントのルールセットは＜ジャバスクリプト＞タグの定義を含む。＜ジャバスクリプト＞タグは、ジャバスクリプトの実行可能コードとして、ＨＴＭＬファイルの一部を定義するために使用される。もう一つの例としては、マイクロソフト・ワードのファイルやドキュメント用の特定のルールセットは、サブファイルのディレクトリ構造と、特定のマイクロソフト・ワードファイル内に含まれるサブディレクトリとを定義する。「ＶＢＡ」のラベルが貼られた特定のサブディレクトリは、マイクロソフト・ワードのファイル内のマクロを定義するために使用される。ファイル「ＶＢＡ_ＰＲＯＪＥＣＴ」は、アクティブ・コンテンツの一部分を定義するサブファイルのもう一つの例である。標準名を有していない他のサブファイルは、マイクロソフト・ワードのファイル内のアクティブ・コンテンツの部分を定義する「ＰＲＯＪＥＣＴｗｍ」ファイルにリストされる。

したがって、ステップＳ３−３において、プロセッサ１１３は処理されるコンテンツの次の部分を識別するが、これが、電子ファイル１０１が初めて処理される受信電子ファイル１０１内のコンテンツの第１部分である。この実施形態において、部分を識別する方法は、ファイルタイプの仕様に定義されているように、電子ファイル１０１の構造に依る。したがって、受信されるファイルのタイプに依存して、プロセッサ１１３は、ファイルタイプの仕様に付随した特定なセットのルールにしたがって、受信電子ファイル１０１を処理して、コンテンツの次の部分を識別する。例えば、ＪＰＥＧのファイルタイプの仕様は、ＪＰＥＧイメージについての情報を含むために幾つかのタグを定義するルールセットを備えている。もう一つの例として、ＨＴＭＬファイルはコンテンツデータから成り、コンテンツデータは、ＨＴＭＬファイルの構成要素の異なるセットのタグを定義する特定なセットのルールにしたがって、配置されている。

ステップＳ３−４において、プロセッサ１１３は、受信電子ファイル１０１のタイプに関連する特定なセットのルールによって識別される部分と対応するものとして、コンテンツの今識別された部分が認識されているか否かを、決定する。コンテンツの部分が特定ファイルタイプの仕様によって定義されるものとして認識されないと、プロセッサ１１３が決定したならば、ステップＳ３−１５において、電子ファイルを隔離することによって、受信電子ファイル１０１はブロックされる。したがって、受信電子ファイル１０１は如何なる形態においても再生されなくて、ファイルの処理は終了する。

他方、コンテンツデータの一部が認識されているということをプロセッサ１１３が決定したならば、次にステップＳ３−５において、コンテンツの今識別された部分がパッシブ・コンテンツデータであるか、或いはアクティブ・コンテンツデータであるかどうかをプロセッサ１１３が決定する。この実施形態では、再度、上述したように、プロセッサ１１３が、受信電子ファイル１０１に関連する特定なセットのルールから、この決定をする。

ステップＳ３−５において、コンテンツの一部分がパッシブ・コンテンツデータであることをプロセッサ１１３が決定するならば、そのときは、ステップＳ３−６において、一致解析装置１３１が使用され、パッシブ・コンテンツデータの一部分が処理されて、上述したように、コンテンツの一部分が所定のフォーマットに一致しているかどうかを決定する。当業者が認識するように、パッシブ・コンテンツの識別部分は、複数のサブ部分を含み、サブ部分の各々は付随する所定のフォーマットを有する。このような場合、ステップＳ３−６において、一致解析装置１３１が呼び出されて、各サブ部分を順に処理して、各サブ部分が所定のフォーマットに一致しているかどうかを決定する。ステップＳ３−７では、一致解析装置１３１が、電子ファイルがそれが示すフォーマット内にあって、全てのパラメータが特定の電子ファイルのタイプに付随する所定のフォーマットと一致することを決定するならば、そのときは、ステップＳ３−９において、このパッシブ・コンテンツデータの許可された部分が、再生のためにコンテンツ・リジェネレータ１３５に渡される。この実施形態では、コンテンツ・リジェネレータ１３５が使用されて、当初の受信電子ファイルのタイプに付随する所定のフォーマットにおいて、許可されたコンテンツデータの一部分から代用ファイルを再生する。

次に、処理はステップＳ３−１３に続く。ステップＳ３−１３では、プロセッサ１１３が処理するコンテンツがあるかどうかを決定する。処理するコンテンツがあると決定されたならば、プロセッサ１１３は、ステップＳ３−３に戻って、処理されるべきコンテンツの次の部分を識別する。

ステップＳ３−７において、パッシブ・コンテンツの一部分が如何なる所定の構成にも対応しないと一致解析装置１３１が決定するならば、次に、ステップＳ３−１１において、クリーニングモードフラグがＡＶアプリケーション１０５に設定されたかどうかをプロセッサ１１３が決定する。この実施態様では、電子ファイル１０１の不一致部分が再生されないように受信電子ファイル１０１をクリーニングするプロセスは、メモリ１１７に設定されたフラグ（旗）によって制御され得る。クリーニングモードフラグは、ステップＳ３−１２においてクリーニングプロセスを可能にするようにトゥルー（真）と設定され、その結果、受信電子ファイル１０１の不一致部分は除去あるいはクリーニングされて、再生ファイルには存在しない。従って、このクリーニングプロセスにおいて、未知のファンクション（関数、機能）を含むファイルの断片や一部分は取り除かれつつ、ユーザには有用な再生ファイルが提供される。一方、クリーニングモードフラグは、クリーニングプロセスを無効にするようにフォールス（偽）と設定される。クリーニングプロセスが無効の場合、メッセージの一部分か電子ファイルが不一致であると決定されているならば、電子ファイルは、完全にブロックされて、如何なる形態においても再生されない。

クリーニングフラグが設定され、ステップＳ３−１２においてクリーニングプロセスが行なわれるならば、処理はパスしてステップＳ３−９に至る。ステップＳ３−９では、コンテンツ・リジェネレータ１３５を用いて、受信電子ファイル１０１の不一致部分に対応した再生ファイルのクリーン部分が再生される。この実施形態では、結果得られるクリーン部分は、例えば、オリジナルの電子ファイルからの不一致データを有することなく、関連部分のタグを含んでいる。その代わりに、結果得られるファイルが当初の電子ファイルのタイプに付随した所定のフォーマットであるように、タグが挿入される。クリーン部が所定のフォーマットで一旦再生されると、上述したように、ステップＳ３−１３では、プロセッサ１１３が、処理すべきコンテンツが存在するかどうかを決定する。図３に示す実施形態では、パッシブ・コンテンツデータの全ての部分が、ステップＳ３−７において、所定のフォーマットに一致するか否かを決定するために、一致解析装置１３１は、ステップＳ３−６において、複数のサブポーションの各々を再帰的に処理する。その代わりとして、各サブポーションのクリーニング処理を行うために、一致解析装置１３１は所定のフォーマットに一致しないと決定することが可能である。

ステップＳ３−７〜Ｓ３−１５の上記説明は、受信電子ファイル１０１におけるコンテンツデータのパッシブ部分の処理に関係する。しかし、上述したように、コンテンツデータの一部は、アクティブ・コンテンツデータであり得る。したがって、プロセッサ１１３が、上述したステップＳ３−５において、コンテンツの現在の部分がアクティブ・コンテンツデータであると決定した場合、ステップＳ３−１７において、ハッシュ・ジェネレータ１３３が使用されて、アクティブ・コンテンツの部分に対してハッシュを生成する。ステップＳ３−１９において、発生したハッシュがハッシュ・データベース１０６に既に存在するか否かを見るために、ハッシュ・チェッカ１３４がハッシュ・データベースをチェックする。ハッシュがハッシュ・データベース１０６に既に存在する場合、アクティブ・コンテンツの付随部分は、悪意のないものとして、以前に識別されている。そして、ステップＳ３−９において、許可されたアクティブ・コンテンツは、コンテンツ・リジェネレータ１３５に渡り、上述したようにリジェネレータ１３５によって再生される。一方、ステップＳ３−１９において、ハッシュがハッシュ・データベース１０６に存在しない場合、ステップＳ３−２１において、処理がステップＳ３−１１に渡り、上述した同じやり方で、アクティブ・コンテンツデータのこの部分に対して、クリーニングプロセスが行われるべきかどうか、或いは、電子ファイルがブロックされるべきかどうかをプロセッサ１１３が決定する。次に、処理がステップＳ３−１３に続いて、ステップＳ３−１３では、プロセッサ１１３が処理するコンテンツが存在するかどうかを決定する。処理するコンテンツが存在すると決定された場合、受信電子ファイル１０１の部分が許可されたコンテンツデータであるならば、受信電子ファイル１０１の全ての部分が処理され再生されるまで、プロセッサ１１３はステップＳ３−３〜Ｓ３−２１を繰り返す。

受信電子ファイル１０１の全ての部分の一処理が一旦完了すると、次にステップＳ３−２５において、通常のやり方で処理されるように、再生電子ファイルが送信先システム１０９のオペレーティングシステム１０７に送られる。所定のフォーマットを作成するルールを用いたファイルから抽出可能なパッシブ・コンテンツデータの全てと、悪意のないものとして識別されたアクティブ・コンテンツデータの全てとが、抽出され、再生される。したがって、抽出されない部分は再生されない。

このようにして、ファイルの一致チェックと再生とによって、ウイルスはオペレーティングシステムに侵入できなく感染できない。実際、普通に存在するフォーマットのパッシブ・コンテンツデータと、悪意のないアクティブ・コンテンツのみが、抽出され、したがって再生される。

当業者が認識しているように、受信電子ファイル１０１の不一致部分が再生されないとき、ＡＶアプリケーション１０５のコンテンツ・ジェネレータ１３５が、再生された電子ファイルに関連警告文を挿入して、メッセージの一部分が通過許可されなかったことを受信者に伝える。選択肢として、この警告テキストは、サブパーツが通過許可されない理由を示すものとすることができる。

更に、電子ファイル１０１のパッシブ・コンテンツの一部分のサブパーツは、このパーツに対応する所定の許可フォーマットに一致していない場合には、ブロックできる。すなわち再生することなく、好ましくは消去できる。すなわち、例えば、ＡＳＣＩＩ電子ファイルの文字列が制御文字（例えば「ＢＥＬ」文字）を含んでいる場合、この文字列を、ＡＶアプリケーション１０５により挿入されるテキスト警告に置き換えて、この文字列は所定フォーマットに一致しないので再生電子ファイルのこの部分から除外されている、と受信者に知らせることができる。上記一致解析装置１３１は、許可されない制御文字（例えば「ＢＥＬ」文字）を特別に探索するのではなく、所定の許可フォーマットによって定義された許可される制御文字だけを通過させる。

［ハッシュの登録］
上記説明において、ハッシュ・データベース１０６は、善良なもの或いは悪意のないものとして、以前に解析されて示されたアクティブ・コンテンツデータに対するハッシュ値を有する。当業者が認識するように、このようなデータベースは、本システムとメソッドとが最も有効であるべく、新たに遭遇する悪質でないスクリプトやマクロ、実行可能コードを用いて最新化するために、不断のメンテナンスを必要とする。さて、このような新たに遭遇するコンテンツデータが、管理モードに際してハッシュ・データベース１０６に包含すべく、どのように解析されるかについて、簡単な説明がなされる。

この例では、図１に示す送信先システム１０９は、ウェブ・プロクシー・サーバである。ウェブ・プロクシー・サーバは、システム管理者からの要求を受信して、ＨＴＭＬのスクリプトを登録する。この例では、システム管理者が、通常のウェブサーフィンに対して異なるポート、例えばポート８１８１のウェブ・プロクシー・サーバ１０９に、ＨＴＴＰのリクエストとして登録すべきスクリプトを用いて、ＨＴＭＬページを送信する。異なるポートを使用することによって、上記リクエストを通常のウェブ・トラフィックと区別できるとともに、このポートへのアクセスがファイアウォールによって制限されるので、登録するスクリプトがいっそう安全なものになる。このようなユニークなポートを使用することにより、ウェブ・プロクシー・サーバ１０９は、システム管理者がスクリプトの登録をリクエストしていることを認知できるが、許可されたＩＰアドレスの制限やパスワードの使用といった特別な追加確認チェックによって実施される付加的なセキュリティを用いることができる。

この確認が成功裏に完了すると、ウェブ・プロクシー・サーバ１０９は、リクエストをインターネット上に通して、ＨＴＴＰの応答を待つ。このＨＴＴＰの応答は、その後、ウェブ・プロクシー・サーバ１０９によって受信されて戻される。ウェブ・プロクシー・サーバ１０９は、通常のサーフィン応答ではなく、登録リクエストとして、受信した応答をマークする。次に、この応答はＡＶアプリケーション１０５に渡される。受信された応答は、この例では、登録されるスクリプトを用いたＨＴＭＬページである。受信ファイルが登録リクエストとしてマークされるので、ＡＶアプリケーション１０５が、上述の通常のチェッキングモードではなく登録モードで作動するように設定されていることを除いて、受信された応答は、図３に関して上述したのと同様に、ＡＶアプリケーション１０５により処理される。

登録プロセスでは、一致解析装置１３１は、受信ファイルのＨＴＭＬの部分がＨＴＭＬ仕様と一致し、合理的な値を有しているかをチェックする。受信ファイルのジャバスクリプトの部分を処理する際には、ハッシュ・ジェネレータ１３３はジャバスクリプトファンクションのためのハッシュを創成し、ＡＶアプリケーション１０５はハッシュがハッシュ・データベース１０６に存在するかどうかをチェックする。スクリプトが以前に登録されているならば、その特定のスクリプトに対して更なる行動は不要である。しかし、スクリプトがハッシュ・データベース１０６に存在しないならば、そのときは、ＡＶアプリケーション１０５がその特定のスクリプトに関する情報を集める。その特定のスクリプトは、このスクリプトを登録すべきかどうかの判断をすべく、システム管理者に提示される。この例では、ＨＴＭＬフォームがシステム管理者に表示するために創成され、システム管理者はどのスクリプトがハッシュ・データベース１０６に登録されるべきかを表明する。ＨＴＭＬフォームを形成するために、データ構造が使用されて、処理されるＨＴＭＬ頁のために登録され得るハッシュを全て収集する。システム管理者が情報に基づく決定をすべくシステム管理者に十分な情報を提供されるように、この例では、ファンクションの完全なテキストが、創成されたハッシュとともに、データ構造に含まれる。ＡＶアプリケーション１０５が受信されたＨＴＭＬファイルの全ての部分を一旦処理すると、データ構造にはシステム管理者によって審査されるハッシュおよびファンクションが投入される。データ構造の各エントリーは、ＨＴＭＬフォームのエントリーにフォーマットされる。データ構造の全てのエントリーがＨＴＭＬフォームに処理された後、このフォームはシステム管理者に送られる。システム管理者は、新たに遭遇するスクリプトの内のどれが悪意のないものであるかを、したがって、ハッシュ・データベース１０６に含むことができるかを、示すことができる。レジスタ応答がシステム管理者から得られると、指示されたスクリプトのハッシュがハッシュ・データベース１０６に追加される。

［開発段階］
上記内容は、ファイルデータを処理するとともに、既知で良好なデータのファイルを書き直すシステムとメソッドの説明である。この既知で良好なデータとは、ファイルフォーマットの仕様および語用論的限定事項やその他の特定の限定事項に合致するデータであり、或いは、悪意のないデータとして以前に確認されたデータである。したがって、ファイルの受取人は確信を持って悪意のないデータを受取ることができる。開発段階を通じて操作上の連続的な正確性を保証するために、ＡＶアプリケーション１０５を試験し開発を行うに際して、幾つかの問題が生じる。これらの態様について説明する。

［２つのパスエラーの検出］
この書き直しのプロセスの際に、実行エラーが、上述のシステムや方法が実施することになっているファイルフォーマットの仕様および語用論的限定事項やその他の特定の限定事項に合致しない再生ファイルを生じさせる可能性がある。したがって、コンテンツ・リジェネレータ１３５の開発に際しては、操作上の連続的な正確性を保証すべく、開発段階を通して、再生されたファイルをテストすることが必要である。

図４は、リジェネレータ１３５の開発試験段階における処理手続を示す図である。図４に示すように、リジェネレータ１３５の試験は、ステップＳ４−１において、電子ファイルの入力から始まる。これは、図３に関して上述したステップＳ３−１での電子ファイルの受信に類似している。ステップＳ４−３では、プロセッサ１１３は電子ファイルを処理して、電子ファイル内のコンテンツが許容されるかを決定し、その結果によって、ファイルを所定のフォーマットで再生する。ステップＳ４−３で実施される処理ステップは、図３に関連して上述したものである。既に論じたように、図３に示す処理手続の結果は、再生ファイルが創成されるか（ステップＳ３−２５）、或いは、電子ファイルが隔離されるか（ステップＳ３−１５）のいずれかである。したがって、ステップＳ４−５では、再生ファイルが創成されているのか、或いは、そうでないのかをプロセッサ１１３が決定する。ステップＳ４−７では、現在の電子ファイルが所定のフォーマットに一致していなく、したがって、隔離されることが決定される。

一方、再生ファイルが創成されたならば、ステップＳ４−８において、クリーニングフラグが無効に設定される。したがって、ステップＳ４−９において、再生ファイルが第２処理パス内で処理されるとき、所定のフォーマットや語用論的限定事項やその他の特定の限定事項に一致しないコンテンツに遭遇すると、たちどころに処理手続は機能しなくなる。ステップＳ４−９で行なわれるステップは、図３に関連して上述したものである。ステップＳ４−１１では、再生ファイルが創成されているかどうかをプロセッサ１１３が再び決定する。ステップＳ４−９の処理手続が再生ファイルの創成という結果になったならば、このことによって、ステップＳ４−１３において、リジェネレータ１３５の機能が正しいことが保証される。一方、再生ファイルがステップＳ４−９での処理手続によって創成されなかったならば、このことによって、ステップＳ４−１５において、リジェネレータ１３５の有効性が損なわれていることが示される。

したがって、ステップＳ４−３における第１処理手続パスの再生段階の際に、何らのエラーが導入されたならば、これらエラーは、ステップＳ４−９において第２処理手続パスに渡される再生ファイルに存在することになる。これらのエラーは、次に、第２処理手続パスによって浮き彫りとなる。エラーを有する再生ファイルは、本システムや方法によって実施される所定のフォーマットや語用論的限定事項やその他の特定の限定事項に一致しないからである。

さて、開発試験段階におけるこのエラーの具体的な検出例について説明する。次の例においては、ＭＰ３の音楽ファイルは、上述した方法によって処理される。通常、このようなＭＰ３ファイル内には、特定の音楽に関する特別な情報を含むタグであって、符号化された音楽データとは分離しているタグが様々存在する。このようなＭＰ３のタグの一つは「ＴＣＯＭ」タグである。「ＴＣＯＭ」タグは、特定のＭＰ３ファイルの音楽データコンテンツの作成者に関する情報を詳しく記述している。

図５は、２パス試験開発法にしたがって処理されるＭＰ３ファイルの一例を示す。図５に概略図示された典型的なＭＰ３ファイル５０１は、非交換の未加工メモリデータバッファに格納されていて、タグ「ＴＣＯＭ」とＴＣＯＭデータと音楽データコンテンツとを含む。ＭＰ３ファイル５０１は、ステップＳ４−３において説明したように、第１処理手続パスのときに、プロセッサ１１３によって読み込まれる。図５に示す例では、リジェネレータ１３５の実行エラーにより、「ＴＣＯＭ」タグが出力バッフアに誤って書き直されて、再生されたＭＰ３ファイル５０３がタグ「ＴＣＭＯ」を含むようになる。その結果、このタグはＭＰ３ファイルフォーマット仕様に一致しなくなり、したがって、ステップＳ４−９において第２処理手続パス中に再生ファイル５０３が処理される際に、不正な「ＴＣＯＭ」タグに遭遇し、再生ファイル５０３が隔離される。プロセスの第２パスにおいてファイルを再生し損じた結果として、このことは、リジェネレータ１３５が第１処理手続パス中に電子ファイルを正しく再生していないことを示している。

［フォールト・スプリット］
本システムと方法の開発時におけるもう一つの問題は、良好な既知ファイルを収集するために、また、既知の悪意のないデータファイル・フォーマットや語用論的限定、その他の限定に関するデータベースを創成するために、多くの電子ファイルについてプロセスを試験しなければならいことである。電子ファイルを調べるプロセスは、典型的には、それぞれが開発モードでファイルされたプロダクト・デベロッパー・プロセッシング（製品開発者処理）に依っていて、その出力を評価して、要求されるアクションを決定する。このプロセスは可成りの資力を必要とする。

この問題を克服するために、試験プロセスを効果的に自動化するとともに、出力の評価では製品開発者を支援する開発試験方法が考え出された。この方法によると、収集されたファイルのディレクトリを介して処理が繰り返され、ディレクトリ内の各ファイルについて、図３の処理のステップと再生のステップが行われる。ディレクトリ内の各ファイルについてのプロセスが進行するにつれて、その処理手続は、ファイルをブロック或いは隔離状態に置く理由を詳述しているステータス・コード（状態コード）やフェイラー・ストリング（不履行文字列）に帰還する。処理に起因する不履行の起こり得る理由は、適当なエラーコードやリーズン・ストリング（理由文字列）に帰還する。本開発試験方法は、これらのリーズン・ストリングを用い、エラーコードやリーズン・ストリングというサブディレクトリ名の「サブディレクトリ」を創成している。また、この方法は、エラーコードやリーズン・ストリングに依るサブディレクトリに各対応ファイルを移動する。全てのファイルの処理が終了すると、製品開発者は、処理によって何故ファイルがブロック或いは隔離状態に置かれているのか、その理由を全て記したリストを迅速に検閲できる。さらに、製品開発者は、各サブディレクトリ内のファイル数を見ることにより、これらの理由の相対的な重要性を確認できる。このようにして、製品開発者は、最も多く停止を引き起こす不履行理由に対して、努力を集中させることができる。

図６は、この開発試験プロセスの概略図である。図６は、フォールト・スプリット開発試験モジュール６０３によって処理されるＪＰＥＧイメージファイル６０１のディレクトリを示す。ディレクトリ６０１内の各ファイルはＡＶアプリケーション１０５に受け継がれて、図３に関して上述したように、ＡＶアプリケーション１０５がファイルの各々に作用する。各特定のファイルの処理が完了すると、ＡＶアプリケーション１０５は、特定のファイルの処理において不履行が存在したかどうかのステータス（状態）およびリーズン（理由）に帰還する。

図６に示す例では、ＡＶアプリケーション１０５は、ファイル「picture1.jpg」を処理しているときに、リーズン・ストリング「不適切なヘッダー値」の付いたエラー００５４を見つけている。このエラーコードとリーズン・ストリングとは、フォールト・スプリットモジュール６０３に帰還する。フォールト・スプリットモジュール６０３は、同じエラーストリングを有するサブディレクトリが存在するかどうかを決定する。もし存在するならば、対応ファイルは単にサブディレクトリにコピーされる。図６に示す例では、他のサブディレクトリが存在しないので、フォールト・スプリットモジュール６０３は、エラーストリング「failure_0054_incorrect_header_value」という名前の新しいサブディレクトリ６０７を創成する。サブディレクトリ６０７が一旦創成されると、対応するファイル「picture1.jpg」がこのサブディレクトリ６０７にコピーされる。

フォールト・スプリットモジュール６０３は、原初ディレクトリ６０１の全てのファイルを処理するまで、このディレクトリの各ファイルを処理する。このようにして、開発試験プロセスが完了すると、ディレクトリ構造６０７は、原初ディレクトリ６０１のファイルを処理するときに遭遇したエラーコードのサブディレクトリを含むものとなり、対応するファイルは各サブディレクトリにコピーされた状態になっている。

［第２の実施形態］
第１の実施形態に類似していて、以下に説明する第２の実施形態では、電子ファイルとは、インターネット上で作成者からインターネットサービスプロバイダ（ＩＳＰ）に伝送される電子メールのことである。ＩＳＰは、各電子メールを電子メールクライアントサーバに送る。電子メールクライアントサーバは、電子メールを受信すると直ぐに、相手の受信者の受信ボックスに電子メールを送る。

図７は、本発明のＡＶアプリケーションが組み込まれた本実施形態による電子メールシステムの配置を示す。電子メールは送信者によってソース場所２０１から送信される。その電子メールは、インターネット２０３を経由して、インターネットサービスプロバイダ（ＩＳＰ）２０５へ送られる。上記ＩＳＰは、電子メールに組み込まれたドメイン名によって決定される。受信者の電子メールクライアントサーバ２０７は、ダイレクトオープン接続によって、ＩＳＰ２０５に接続されている。第１の接続は、送信電子メールを電子メールクライアントサーバ２０７からＩＳＰ２０５へ送るためのシンプルメール転送プロトコル（ＳＭＴＰ）送信接続２０９である。第２の接続は、ＩＳＰ２０５から電子メールを取り出すＰＯＰ（ポストオフィスプロトコル）の受信接続２１１である。

ＡＶアプリケーション１０５はＩＳＰ２０５に配置されている。ＡＶアプリケーション１０５は、受信者の電子メールクライアントサーバ２０７に接続された入出力ポートに存在して、電子メールクライアントサーバ２０７によって送受信される全ての送受信電子メールを解析する。

本実施形態では、ＡＶアプリケーション１０５は一片のコンピュータコードである。上記コンピュータコードは、既知のコンピュータプログラミング技法を用いて実行される。電子メールが電子メールクライアントサーバ２０７に入る前に、電子メールクライアントサーバ２０７に送られる電子メールは全て、ＡＶアプリケーション１０５を通過しなければならない。同様に、電子メールクライアントサーバによってＩＳＰ２０５に送られる電子メールは全て、ＩＳＰ２０５に入る前に、ＡＶアプリケーション１０５を通過しなければならない。

ＡＶアプリケーション１０５は、データがこのアプリケーションに入る際に、そのデータを解析することによって、受信電子メールのメッセージを分析する。第１の実施形態と同様、実行可能なファイルを動作停止させるべく、データはスクランブルモードで格納されている。ＡＶアプリケーション１０５は、受信電子メールの個々のパーツが所定の許可フォーマットに一致するか否かを判定する。そのパーツが一致する場合は、ＡＶアプリケーション１０５は電子メールメッセージの各パーツを再生する。したがって、如何なる電子メール内の如何なるウイルスも、受信者のシステムに感染することは許されなく、また、受信者のシステムからＩＳＰに通ることは許されない。

第１の実施形態において論じたように、一致解析装置１３１は、特定のデータ形式の各々を解析するために用いられていて、そのデータ形式に対応した所定フォーマットに一致するか否かを調べ、そして、一致するコンテンツデータを抽出する。次に、コンテンツ・リジェネレータ１３５は、そのデータ形式に対応した所定の許可フォーマットを用いて、そのデータを再生する。この実施形態では、各データ形式は、それ自身の特有の一致解析装置およびコンテンツ再生装置によって解析され、再生される。

各一致解析装置１３１は、受け取ったデータに応じて、データに関する特定の規則群を実行する。これらの規則は、ファイル形式に対する所定の公的な仕様によって定義されている。また、現実の世界でよく見られる（したがって安全な）周知のデータ形式の例によって定義されている。上記規則は、一般的に、ファイル形式仕様に一致するファイルのサブセットのみを許可する。しかし、公的仕様の規則の内の或るものは、通常は規則に反するが、緩和することができる。例えば、電子メールアドレスはスペースを含まないが、人気の電子メールアプリケーションにはこの規則を破るものがある。この点に関して仕様に違反する電子メールは、どこにでもある。したがって、本実施形態による電子メールを解析する所定フォーマットは、スペースを含む電子メールアドレスを受け入れて、電子メールアドレスを解析、抽出する。

また、一致解析装置は、データファイル内の特定のパラメータをチェックするものでもよい。例えば、ファイルがＲＴＦ（リッチテキストフォーマット）ファイルであるとヘッダに記述されているならば、そのときは、ＲＴＦファイル仕様にしたがって、最初の数バイトのデータが読み込まれて、これが正しいかどうかを判定する。

図８は、本実施形態に従ってＡＶアプリケーションを組み込んだシステムの動作法のフローチャートを示す。図８に見られるように、ステップＳ８−１において、電子メールが、ＳＭＴＰ受信接続を介して、ＩＳＰ（インターネットサービスプロバイダ）にて受信される。

ステップＳ８−３において、プロトコル一致解析装置が、受信電子メールの基本フォーマットを読み込むプロセスを実行する。そして、基本電子メールプロトコルに一致するように電子メールを再生する。（不一致型の電子メールリーダは電子メールを読む。）次いで、読み込まれたデータは、基本電子メールプロトコルに一致する電子メールライタに渡される。このようにして、何処にでもある不一致は一致電子メールに変換される。例えば、受信者の電子メールアドレスが酷い状態に形成されている場合には、（例えば、スペースを除去することによって、或いは、閉じた角括弧を最後に挿入することによって）電子メールライタがそれを書き直して一致させる。

もう一つの例は、電子メールメッセージが、「Ｆｒｏｍ：」というヘッダが無い状態で、受け取られるときである。この場合には、電子メールメッセージがカプセル化されて、全体が、ヘッダ「Ｆｒｏｍ：」を含む新しい電子メールメッセージとなる。

電子メール内の他のパラメータも一致したものにされる。上記パラメータは、例えば、行長、正しいＡＳＣＩＩ文字列の使用、適切な場合における正しいＢＡＳＥ６４コーディングの使用、完全なヘッダ情報（「Ｔｏ：」、「Ｓｕｂｊｅｃｔ：」など）、電子メールのヘッダと本文との間のスペースなどである。

電子メールが、その一部を書き直すことができない程に、まずく形成されている場合、不一致部分が脱落しても筋の通る電子メールがまだ存在しているかどうかが判定される。その処理の結果、まだ電子メールが筋の通ると判定された場合、電子メールは、不一致部分が欠けた状態のままで書き直されることができる。その場所には、警告テキストを挿入してもよい。

また、プロトコル一致解析装置は、電子メール全体を拒絶するものとしてもよい。例えば、プロトコル一致解析装置が、不一致ＢＡＳＥ６４のコード化が電子メール内の大きいデータ片で使用されていることを検出した場合、その電子メールは、ステップＳ８−１７において、完全に拒絶される。

プロトコル一致解析装置が、電子メールが電子メールプロトコルに一致すると判定した場合、その電子メールはプロトコル一致解析装置によって再生される。そして、そのプロセスにおいて、次のステップに渡される。

全ての電子メールは、電子メール用の最新ＲＦＣ規格（すなわち、ＲＦＣ８２２とその後続版）に一致させるべきである。この規格は、電子メールがいかに形成されるかを定義している。電子メールがプロトコル一致解析装置を通した後には、ＲＦＣ８２２規格の一致解析装置は、電子メールがＲＦＣ８２２規格に一致しているかどうかを検査する。すなわち、ＲＦＣ８２２規格の一致解析装置は、まず、（後述するように）電子メール内の境界を見つけて電子メールを個々の構成部分に分解し、次に、電子メールの各構成部分を解析してそれがＲＦＣ８２２に一致するかを検査することにより、上記一致チェックを行う。

ＲＦＣ８２２規格の一致解析装置が、周知の全データ形式の一致をチェックできることを保証すべく、ＲＦＣ規格が更新される際には、更新が必要であることが理解される。

周知のごとく、電子メールは、例えば図９に示すように、幾つかの別々の部分から構成される。電子メールは、ＲＦＣ８２２ヘッダ９０１から始まる。ＲＦＣ８２２ヘッダ９０１は、「Ｆｒｏｍ：」、「Ｔｏ：」、「Ｓuｂｊｅｃｔ：」などの幾つかのフィールドが定義される。その次は、ＭＩＭＥヘッダ９０３である。ＭＩＭＥヘッダ９０３は、「コンテンツ形式」などの拡張プロトコルで使用される幾つかのフィールドを定義する。上記拡張プロトコルは、電子メールの異なる部分間の境界を示すのに使用されるテキストを定義する。

ヘッダ（９０１と９０３）に続いて、最初の境界９０５が示される。電子メールの次の部分は、更なるヘッダであるＭＩＭＥヘッダ９０７から始まる。ＭＩＭＥヘッダ９０７は、この部分で使用されるフォーマットを定義する。この例では、この部分は、テキストフォーマットで表示されるテキスト内容を備える。したがって、その後には、テキスト９０９のブロックが続く。テキストブロック９０９の終わりには、もう１つの境界９１１が存在する。

更なるＭＩＭＥヘッダ９１３が、電子メールの次の部分がどのフォーマットであるかを示す。この例では、電子メールの次の部分は、混合テキストおよびＨＴＭＬのフォーマットブロック９１５である。もう１つの境界９１７は、その部分の終わりを電子メールに示す。

電子メールの次の部分として、ＭＩＭＥヘッダ９１９が、電子メールの添付物に関するデータ形式を示す。この場合は、上記データ形式はＺＩＰファイルである。ＺＩＰファイル９２１は、符号化されて電子メールに加えられるＢＡＳＥ６４である。次に、更なる境界９２３がＺＩＰファイルブロックの終わりを示す。

電子メールの最後部分として、ＭＩＭＥヘッダ９２５が、電子メールの添付物に関するもう一つのデータ形式を示す。この場合は、上記データ形式は実行可能コードの一部分である。実行可能コード９２７は、電子メール内におけるアクティブ・コンテンツデータの一部分の例である。次に、最終境界９２９が実行可能コードのブロックの終わりを示す。

図８のステップＳ８−７において、ＲＦＣ２２規格の一致解析装置は、パーサ（構文解析ツール）を用いて、電子メールを構成するＡＳＣＩＩ文字を解析する。次いで、ＲＦＣ８２２規格の一致解析装置は、電子メールにおける境界を検出して、特定のパラメータが既知の許可可能な所定フォーマットに一致するか否かを検査できる。例えば、ＲＦＣ８２２規格の一致解析装置は行長を検査して、行長がＲＦＣ８２２規格に一致するか否かを調べ、２０００以下の行長のみが再生される。

電子メール内の構文解析されたデータがＲＦＣ８２２規格に一致するか否かを調べるために、更なる検査を行うことができる。例えば、電子メール内の文字が規格で定義された既知の許可可能なＡＳＣＩＩ文字であるか否か、ヘッダ情報が規格で定義された通りか否か、そしてヘッダ長が規格の定義に一致するか否か、が検査される。ここに挙げたこれらの検査は、ＲＦＣ８２２規格の一致解析装置が実行する様々な大検査群の単なる例に過ぎない（その他の部分は、当業者には明白であろう）。本発明は、それ自体、上に挙げた例に限定されるものではない。

ＲＦＣ８２２規格の一致解析装置は、構文解析されたデータを解析して基本ＲＦＣ８２２規格に一致するか否かを調べると同時に、特定のパラメータがＲＦＣ８２２規格の電子メールの現実の例に一致するか否かをも検査する。すなわち、特定のパラメータの仕様では、ユーザが定義するように開放されているが、現実の世界では、妥当な値のみが使用される。例えば、電子メールは、通常、最小の数のパーツを備えるのみである。したがって、１０００個の境界を含む電子メールが受信される場合、この電子メールは、ＲＦＣ８２２規格の電子メールの現実例とはならず、したがってＲＦＣ８２２規格の一致解析装置によって、ブロックされる。すなわち、電子メールは再生されず、好ましくは消去される。

更なる一致チェックを要するデータを含んだ電子メールの各構成部分に対しては、第１の実施形態において論じたように、構成部分がパッシブ・コンテンツデータを成すのか或いはアクティブ・コンテンツデータを成すのかについて、ＡＶアプリケーションによって決定される。構成部分がパッシブ・コンテンツデータを成すならば、そのときは、ステップＳ８−９において、構成部分の対応するデータ形式に依って、構成部分を個別の一致解析装置に送る。すなわち、解析された電子メール部分がテキストと定義された場合、テキストを構成するＡＳＣＩＩ文字が、テキスト一致解析装置に送られる。解析された電子メール部分がＴＩＦＦファイルと定義された場合は、ＴＩＦＦファイルを構成する文字がＴＩＦＦ一致解析装置に送られる。

ステップＳ８−９において、各パッシブデータ一致解析装置は、送られてきたデータを解析して、データが、表明されたフォーマットに一致するか否かを調べる。一致する場合、データは一致解析装置によって再生される。データ内に何らかの不一致がある場合、データは一致解析装置によって除外されるか、或いは、可能ならば、一致するようにデータが再生される。データを一致するように再生する例の一つは、入れ子ブラケットが欠けている場合に、ＲＴＦファイルに入れ子ブラケットを追加する例である。

電子メールが異なるデータ形式の入れ子構造を含んでいる場合、パッシブデータ一致解析装置が繰り返し呼び出される。そして、数台の特定の装置は順次動作され、各装置は、新たなデータ形式が発見される各ポイントで、待機させられる。このようにして、電子メールは、ＪＰＥＧ写真ファイルを含むワードプロセッサドキュメント等のＺＩＰファイルを帯同するが、一連の異なる一致解析装置（ｚｉｐ、ワードプロセシング、ＪＰＥＧ）を通過でき、入れ子構造のファイルを介してドロップダウンして、各ファイルが順次解析される。

一方、構成部分がアクティブ・コンテンツデータから成るという決定がＡＶアプリケーションによってなされると、ステップＳ８−１０において、アクティブ・コンテンツデータ解析装置がデータを解析して、スクリプトやマクロや実行可能コードが悪意のないものかどうかを決定する。アクティブ・コンテンツデータ解析装置によって成された処理は、アクティブ・コンテンツのためのハッシュを創成し、そのハッシュがハッシュ・データベースに存在するか否かを決定する。この処理は、第１の実施形態において上述している。

解析の終わりには、一致する再生部分を用いて、ファイルが再編成される。ステップＳ８−１１において、適切に理路整然として理解可能かつ有意義な電子メールを形成すべく電子メールの十分な部分が再生されていると判定されると、ステップＳ８−１３に示すように、上記再生された部分を用いて、また、ＲＦＣ８２２規格の一致解析装置を用いて、データは再編成される。これにより、再生された電子メールが正しいフォーマットで確実に送られる。次いで、ステップＳ８−１５に示すように、ＳＭＴＰプロトコルを用いて、再生された電子メールはＡＶアプリケーションにより所望の受信者に送信される。

しかし、ステップＳ８−１１において、有用な電子メールを形成すべく電子メールの十分な部分が再生されなかったとＡＶアプリケーションが判定した場合、電子メールはステップＳ８−１７において拒絶される。ステップＳ８−１７では、警告テキストが所望の電子メール受信者に送られて、受信者に向けられた電子メールがシステムによって拒絶されたことを受信者に知らせる。警告テキストは、メッセージが削除された詳細な理由を含むことができる。また、警告テキストは、受信者が送信者を識別するのに役立つ情報を更に含むか、或いは電子メールが拒絶された理由を含むことができる。

本実施形態において使用する一致解析装置の幾つかの例を以下に詳細に説明する。これらの一致解析装置は、ステップＳ８−９において使用できる。ＲＦＣ８２２ヘッダやＭＩＭＥヘッダ或いはファイル拡張子の情報に基づいて、テキストであると表明する電子メールの構成部分は、Ｓ８−９で示すように、テキスト一致解析装置に渡される。テキスト一致解析装置は、以下に述べるように、テキストデータを構文解析し、そのテキストデータが所定の許可可能なフォーマットに一致するか否かを判定する。

例えば、カンマ区切り変数（ＣＳＶ：Comma Separated Variable）やリッチテキストフォーマット（ＲＴＦ）などの異なる形式のテキストファイルが幾つか存在するとき、テキスト一致解析装置は、最初に、構文解析されたデータが表明しているのはどの形式のテキストファイルであるのかを識別しなければならない。電子メールに添付されたファイルは、全て、それと関連のあるファイル拡張子を有して、ファイル形式が何であるかを示す。テキスト一致解析装置は、ＭＩＭＥヘッダ内の構文解析されたファイル拡張子を解析して、そのテキストファイルが純粋なＡＳＣＩＩファイルであるか否かを判定する。純粋なＡＳＣＩＩファイルであれば、以下に述べる通り、ＡＳＣＩＩ一致解析装置を使用すればよい。

一方、テキスト一致解析装置が、解析の結果、そのテキストファイルが純粋なＡＳＣＩＩ以外のファイル形式、例えばＣＳＶファイルであると判定した場合は、ＣＳＶ一致解析装置が呼び出されてＣＳＶデータを解析し、再生する。しかしながら、まず最初に、ＡＳＣＩＩ一致解析装置が、電子メール内のテキストファイルを構成しているＡＳＣＩＩ文字を解析して、そのテキスト列がＡＳＣＩＩの所定フォーマットに一致するか否かを調べ、一致していれば、そのＡＳＣＩＩファイルを再生する。

ＡＳＣＩＩ一致解析装置はデータを解析して、ファイルが最小のＡＳＣＩＩ所定フォーマットに一致していることを確実にする。例えば、ＡＳＣＩＩ一致解析装置は、ＡＳＣＩＩ文字３２〜１２７と、４つの制御文字、すなわち、「改行」（ＬＦ＝１０）、「復帰改行」（ＣＲ＝１３）、「タブ」（ＴＡＢ＝９）および「垂直タブ」（ＶＴ＝１１）のみの再生を許可し、そしてシステムを通過することを許可する。

ベル文字（ＢＥＬ＝７）などの他の制御文字は、ＡＶアプリケーションによって定義されるＡＳＣＩＩファイルの所定の許可可能なフォーマット内には、存在しない。したがって、ＡＳＣＩＩ一致解析装置は、構文解析されるＡＳＣＩＩコードブロックにおいて「ＢＥＬ」文字を再生せず、そのＡＳＣＩＩ文字を拒絶する。

ＡＳＣＩＩ一致解析装置が実行するその他の解析例は、
・固有の行長さは１０２４文字未満であるか？
・ワード長さは２５文字未満であるか？
・文字に対するスペースの割合は所定限界以下であるか？
である。

データが基本所定フォーマットに一致していないために、ＡＳＣＩＩ一致解析装置がＡＳＣＩＩコードの一部分のデータを再生することができない場合はいつでも、ＡＳＣＩＩ一致解析装置は、そのデータを検査して、それが他のいずれかの形式のＡＳＣＩＩコード（例えば、ソースコード、ＢｉｎＨｅｘ、ＢＡＳＥ６４など）に一致するか否かを調べる。データが他の形式のＡＳＣＩＩコードに一致する場合、そのデータはそのＡＳＣＩＩ形式に関する一致解析装置に送られる。この一致解析装置は、上に示した例では、ソースコード一致解析装置、ＢｉｎＨｅｘ一致解析装置、或いはＢＡＳＥ６４一致解析装置である。当然のことながら、ＢＡＳＥ６４ＡＳＣＩＩコードファイルは、符号化されたデータ内に他の形式のファイルを含み得る。これらの他の形式のファイルもまた、次に、関連するファイル形式一致解析装置などに送られる。

他の形式のＡＳＣＩＩコードのためのパッシブ・コンテンツデータ一致解析装置は、電子メールのこの部分のデータに対して更なる一致限定事項を有する。例えば、ファイルがチェックされて、このファイルが適切に構造化されたコードであるか否か、正しい行長を有するか否かなどが調べられる。各パッシブ・コンテンツデータ一致解析装置が、コンテンツおよびパラメータのデータが一致していると判定すると、すなわち、そのデータを抽出すると、抽出されたコンテンツデータは、当該パッシブ・コンテンツデータ一致解析装置を用いて、許可所定フォーマットで再生される。

ＡＳＣＩＩ一致解析装置がいったんそのタスクを終了すると、再生されたＡＳＣＩＩデータは、そのデータが表明する関連のテキスト一致解析装置に送られる。この実施形態では、テキストファイルがＣＳＶファイルである。したがって、データはＣＳＶ一致解析装置に送られる。

ＣＳＶ一致解析装置によって実行される検査例は以下の通りである。すなわち、ＣＳＶ一致解析装置は、パラグラフがＣＳＶファイルに対する所定フォーマットの一部でないとき、ＡＳＣＩＩデータを解析して、確実に、長いテキストパラグラフが含まれないようにする。一致しないために解析できないデータは、ＣＳＶ一致解析装置によって拒絶される。また、ＣＳＶ一致解析装置は、検査をして、例えば、デリミッター（非制限手段）の数がＣＳＶファイル内のデリミッターの通常所定数に一致するか否かを調べる。データが一致するとＣＳＶ一致解析装置が判定した場合、そのデータは同一のフォーマットに再生される。

このようにして、所定のフォーマットに一致するテキストファイル部分のみが、ＡＶアプリケーションの次のステージに通過できる。このテキストファイルの一致部分のみが、再生された他のデータ形式部と共に再生され、再編成されて、送信先に送られる。したがって、電子メールのウイルスを含む部分は、不一致となり、したがってブロックされ、すなわち再生されることがなく、そして好ましくは、削除される。不一致部分は、ＡＶアプリケーションを通過できなく、オペレーティングシステムに感染することが許されない。

一致解析装置の他の例として、ＴＩＦＦファイルを解析し再生するのに使用されるＴＩＦＦ（Tagged Image File Format）一致解析装置がある。

ＴＩＦＦファイルは、１組のディレクトリとタグとが所定のフォーマットで配置された構造化フォーマットを有している。イメージデータ自体が意味のある画像を表しているか否かを判定できる。しかしながら、ＴＩＦＦ一致解析装置は、イメージデータが確実に所定の限界内に収まっているかを確認するために、イメージデータを構文解析し分析する。

ＴＩＦＦファイル内のヘッダ情報は、正しい情報が完全で手付かずのものであるか否かを調べるために、構文解析され分析される。例えば、ＴＩＦＦ一致解析装置は、ヘッダ情報がＴＩＦＦ画像に対して妥当限界内の解像度、サイズ、被写界深度を含むものであるか否かを調べるために検査を行う。更に、ＴＩＦＦ一致解析装置は、ヘッダに示された帯片（ストリップ）の数がイメージデータと合っているか否かを判定する。

ＴＩＦＦファイルは、典型的には、ＬＺＷ（Lempel-Ziv-Welch）圧縮技術を通常使用して圧縮される。ＴＩＦＦファイルは複数のＴＩＦＦストリップを含む。各ＴＩＦＦストリップは、この例では、ＡＶアプリケーションによって取り扱われる像の中の最も低い単位またはアトムまたは構成要素であり、語用論的制限が適用され得る。帯片の長が妥当な所定限界内にあるか否かを調べるために、各ＴＩＦＦ帯片は一致解析装置によって解凍される。例えば、帯片長が最大イメージサイズの限界以下の場合（例えば、標準のＡ０用紙サイズより大きい場合）、帯片は拒絶される。ＴＩＦＦ一致解析装置が１つの帯片を拒絶すると、ＴＩＦＦファイル全体が拒絶される。

また、ＴＩＦＦ一致解析装置は、ＴＩＦＦファイル内のタグ（すなわち、パラメータデータ）に関する解析を実行する。タグは所定の許可フォーマットに照らして検査されて、例えば、タグが（ヘッダにおけるタグ情報のディレクトリに従って）指定された順序にあるか否か、タグが互いに正しく関連づけられているか否かについて調べられる。

ＴＩＦＦ一致解析装置が、データが所定の許可フォーマットに一致すると判定すると、データが再生されて、オリジナルのファイル名を有する再生ＴＩＦＦファイルが作成される（上記ファイル名は所定のフォーマットに一致する）。再生ＴＩＦＦファイルは電子メールサーバに送られて電子メールに再編成される。

ＴＩＦＦファイル自体の中に他のイメージ形式をもたせることも可能である。例えば、ＪＰＥＧ画像をＴＩＦＦファイル内にカプセル化してもよい。ＴＩＦＦ一致解析装置によって異なるイメージ形式が検出された場合、そのイメージに関連するデータが別の一致解析装置、この例では、ＪＰＥＧ一致解析装置に送られる。次いで、ＪＰＥＧ一致解析装置は、そのデータを構文解析し分析して、データが予期されるＪＰＥＧフォーマットに一致するか否かを調べる。一致している場合、そのデータをＪＰＥＧフォーマットで再生する。再生されたデータは、次に、再生されたＴＩＦＦファイル内に再編成される。上記ＴＩＦＦファイルは、その後、更に再生電子メールを再編成するために使用される。次に、この電子メールは電子メールサーバに渡される。

本実施形態における別の利用可能な選択肢は、ＡＶアプリケーションが、電子メールの不一致箇所に代えて、警告テキストを挿入することである。すなわち、電子メールの再生時に、一致解析装置が一部分のデータを構文解析して、その一部分が所定の許可可能なフォーマットに一致しないと判定された場合、一致解析装置は、不一致部分の代わりに、警告テキストを挿入して、その電子メールの一部がＡＶアプリケーションによって拒絶されたことを相手の電子メール受信者に知らせる。或いは、不一致のために一致解析装置が電子メールの一部分全体をブロックする場合、ＡＶアプリケーションは、警告テキストを電子メール内に挿入して、電子メールの一部分がブロックされたことを相手の受信者に知らせる。すなわち、電子メールの一部分が、再生されなかったこと、更に好ましくは消去されたことを相手の受信者に知らせる。

［第３の実施形態］
次に、本発明の第３の実施形態を、図１０を参照して説明する。この第３の実施形態は、第１或いは第２の実施形態の全ての特徴が組み込まれ、第１或いは第２の実施形態と関連して述べた選択肢（オプション）のいずれをも含むものである。

本実施形態は、ＡＶアプリケーションが電子メールの一部、部分または全体（本実施形態では「不一致部分」という）をブロックする状況に関する。第１の実施形態において検討した図３を参照すると、これは様々な理由に対して生じる。例えば、パッシブ・コンテンツデータの一部分が所定のフォーマットと一致しないので、また、クリーニングモードフラグが設定されていないので、ステップＳ３−１５において、ファイル全体が隔離状態に置かれる。或いは、ステップＳ３−１１において、クリーニングモードフラグが設定されたならば、パッシブ・コンテンツデータの一部分を除いてもよい。

この実施形態では、電子ファイル或いはその一部が一致しなく、したがって、システムに通過することを許されないという決定が信頼ＡＶアプリケーションによってなされた場合、原初電子ファイルはソースフィルタアプリケーションに移動して、ソースフィルタアプリケーションが、電子ファイルが信頼されるソースを起源にしているかどうかを決定する。

この決定は、システムが或る信頼されるソースから何を受け取ること期待するのかに基づいてなされる。データのタイプがそのソースに許容されるかどうかを見るために、換言すると、電子メールがソースによってフィタに掛けられるかどうかを見るために、システムは、データのタイプのリストを、メモリに記憶されたソースの所定のリストに照らし合わすことによって、上記決定をする。したがって、一致しないデータを含むファイルが同じ信頼されるソースから受け取られた場合、それが同じ信頼されるソースを起源としているので、この不一致データは悪意がないと判断され、この原初の不一致データはオペレーティングシステムに通すことが許される。このようにして、システムはＡＶアプリケーションを備え、ソースフィルタアプリケーションが、同時に、大多数の安全な電子ファイルを目的とする所に通す。

図１０は、本第３の実施形態によるプロセスのフローチャートを示す。ステップＳ１０−１において、部分が不一致であるか否かについて、したがって、部分がブロックされるべきか否かについて、ＡＶアプリケーションが判定を行う。ＡＶアプリケーションによってブロックされた場合、その不一致部分はソースフィルタアプリケーションに送られて、ステップＳ１０−３に示すように、そのファイルが信頼されるソースからのものであるか否かを確認する。

ソースフィルタアプリケーションは、システムユーザの選択に基づいて、その不一致部分が信頼されるソース（例えば、送信者のアドレス）に由来するか否かを判定する。上記システムは、そのメモリ内に、信頼されるソースと考えられないファイル形式のリストと、これらファイル形式に付随したソースとを格納している。したがって、システムは、ファイルの送信者とファイル形式に基づいて、そのファイルが通過許可されるか否かを判定することができる。

ステップＳ１０−３での判定において、ファイル形式が、関連するソースから、許可可能としてリストアップされたものの一つではないと判定された場合、そのファイルはステップＳ１０−５でブロックされる。ファイル形式が許可可能と見なされた場合、ステップＳ１０−７において、不一致部分はＡＶアプリケーションを迂回する。ＡＶアプリケーションは、ステップＳ１０−９において、受信ファイルの残りを再生する。そして、ＡＶアプリケーションは、ステップＳ１０−１１において、ファイルの再生された一致部分と迂回した不一致部分とを再編成する。

例えば、バンキングシステムが多数の電子メールを既知の送信者から受信し、その多数の電子メールが複雑なマクロを組み込んだスプレッドシートを含んでいる場合、これらのマクロが、スプレッドシートの添付ファイル内のマクロ用所定許可フォーマットに収まらないことがある。その場合、マクロ一致解析装置は電子メールのこの部分をブロックすることになる。

しかしながら、誰がその電子メールを送っているかをバンキングシステムが判定でき、また、送信者が、バンキングシステムの信頼できる相手として、これらのファイル形式のデータベース内に入力されているときは、電子メールの中のスプレッドシートは悪意あるものとは見なされない。したがって、システムユーザは上記ソースフィルタアプリケーションをセットアップして、これら不一致マクロ部分が、ＡＶアプリケーションを迂回し、且つ、電子メールの再生された部分と共に再編成された電子メールとすることができる。

これに代替わる方法として、ソースフィルタアプリケーションは或るモードで動作させることができる。これによって、ＡＶアプリケーションから受け取った再生ファイルが、送信先のシステムに連通することを許可されるべきか否かを判定する。不一致部分自体は即座にファイル全体が拒絶される程にはＡＶアプリケーションに対して不一致ではないが、結果的にはオリジナルのファイルと実質的に異なる再生一致ファイルとなる、そのような不一致部分を含むファイルをＡＶアプリケーションが受け取った場合、再生ファイルはソースフィルタアプリケーションに送られる。例えば、オリジナルのファイルサイズは、ＡＶアプリケーションによって再生されないマクロ内の膨大な数の書直し言語に起因して、再生された一致ファイルのサイズよりもかなり大きなものになり得る。

ソースフィルタアプリケーションは、ファイル形式がそのファイルに対して承認されたソースから送られているか否かを判定する。送られている場合は、ソースフィルタアプリケーションは、そのファイル形式がシステムを通過することを許可する。

［その他の実施形態］
本発明の実施形態は、単なる例証としてここに記載されているに過ぎないこと、また、本発明の範囲から逸脱することなく種々の変更および変形がなし得ることが理解される。

本発明は、電子ファイルをソースから送信先に移す如何なるシステムにおいても、実施し得ることが理解される。本発明の目的とする電子ファイル送信方法は、特定の方法に限定されるものではない。すなわち、例えば、一つのコンピュータシステムのハードウェア内の１つの構成要素から他の構成要素に、電子ファイルを転送してもよい。或いは、例えば、基地局から空中インタフェースを介して移動電話装置に、電子ファイルを転送してもよい。また、例えば、ローカルエリアネットワーク（ＬＡＮ）や広域ネットワーク（ＷＡＮ）を介して、或いはインターネットを経由して、電子ファイルを伝送してもよい。

当業者が認識しているように、携帯電話のようなリソース限定の送信先装置のネットワーク系環境では、リソースが限定されているために、各装置には、上記実施形態で述べた大多数のプロセスのみを行う機能が設けられている。このような環境では、機能性を有する更なるネットワーク装置が、ネットワークに設けられている。この更なるネットワーク装置は、装置に新たな機能性を組み込むことによって、新たな機能性をサポートすることができる。このようにして、ネットワーク上に存在するリソース限定装置毎に更新する必要はない。一例として、携帯電話のネットワークでは、各携帯電話機は初期の限定された機能でもって製造される。携帯電話機の機能は、携帯電話機の使用者が第三者のソフトウェアをインストールすることによって更新される。携帯電話機上のＡＶアプリケーションに対して未知のフォーマットの電子ファイルを要求あるいは受信するために、新たにインストールされたソフトウェアが使用されるならば、そのときは、ＡＶアプリケーションは、受信電子ファイルを処理する能力を有していない場合を識別し、したがって、フルセットの機能を有するネットワーク装置に電子ファイルを渡す。ネットワーク装置は、この新しい機能を認識するべく更新され、したがって、携帯電話機のために受信電子ファイルを処理することができる。次に、ネットワーク装置は、携帯電話機に電子ファイルの再生版を渡し返すことができる。これに替わる更なる方法として、携帯電話機に送信されるデータを傍受するために、十分に機能的なネットワーク装置を作ってもよい。このネットワーク装置は、そのとき、機能的に限定された携帯電話のために、再生版を携帯電話機に送信する以前に特定の電子ファイルを処理できる。

上述した第１の実施形態では、ＡＶアプリケーションは、送信先のファイル内に配置されている。当業者が認識しているように、それに換えて、或いは、それに加えて、ソースにＡＶアプリケーションを配置してもよいし、或いは、送信手段のどこかに、或いは、通信路に沿った或る点で電子ファイルを解析することができるどこかに、ＡＶアプリケーションを配置してもよい。

上述した第１の実施形態では、電子ファイルはコンテンツデータから成り、コンテンツデータは、特定のルール集を備えたファイルタイプの仕様にしたがって符号化され、配置されている。当業者が認識するように、電子ファイル１０１は、ビデオストリームやオーディオストリームのようなストリーミングデータとして受信される。このような場合、受信ファイルは、ファイルタイプの仕様にしたがって符号化、配置されるのではなく、例えばストリーミングデータのための送信プロトコルのような、プロトコル仕様にしたがって符号化され、配置される。したがって、ＡＶアプリケーションは、各ファイルタイプの仕様の所定のフォーマットとルールを保存しているのに加えて、様々なプロトコル仕様の所定のフォーマットとルールをも保存している。そのとき、ＡＶアプリケーションは、受信したストリーミングデータを処理して、このデータがプロトコルの所定のフォーマットに従ったものかどうかを決定することができる。

上述した第１の実施形態では、ハッシュ・データベース１０６とハッシュ・ジェネレータ１３３が、送信先システム１０９内に設けられている。当業者が認識するように、アクティブ・コンテンツデータの部分の処理は、従来の第三者のアンチウイルス・アプリケーションによって実施され得る。例えば、受信電子ファイルがマイクロソフトワード書類のマクロの場合、パッシブ・コンテンツデータを形成するワード書類の大部分は、ＡＶアプリケーションによって処理されて、それが安全か否かを決定する。そして、アクティブ・コンテンツデータを形成するマクロ書類が、それが既知のセキュリティー攻撃ツールを含んでいるかどうかを決定するために、従来のアンチウイルス製品によってスキャンされる。しかし、このような選択肢には、アプリケーションデータベースが更新されていない場合にゼロ・デイ攻撃を受けるおそれのある第３者のアンチウイルス・アプリケーションに頼るという不利益がある。もう一つの選択肢としては、信頼し得る第三者から得られた既知の良好なスクリプト、マクロ、実行可能コードなどのハッシュ・データベースをダウンロードすることによって、例えば、ウイルスの痕跡のデータベースをダウンロードすることで知られたものと同じメカニズムを用いることによって、送信先システム１０９は、ハッシュ・データベース１０６を更新するように構成されている。このメカニズムは、第三者のハッシュ・データベースに包含すべく、マクロやスクリプトや実行可能コードに、使用される。

上述した第１の実施形態では、パッシブ・コンテンツデータが所定のフォーマットに一致しなくて、クリーニングモードフラグが無効となる場合、電子ファイル全体が隔離される。当業者が認識するように、全体のファイルを単に隔離することの代替え案として、フォーマットや明細書が未知の電子ファイルの一部は、アクティブ・コンテンツデータと同じようにして取り扱うことができる。したがって、未知のコンテンツのこれらの部分のためにハッシュが創成され、ハッシュは、良好なコンテンツのハッシュ・データベースに対してチェックされる。

上述した第１の実施形態では、クリーニングモードフラグが無効である場合、クリーニングプロセスが実施されて、非一致部分が除去される。また、コンテンツ・リジェネレータが使用されて、必要な空値を再生するか、或いは、所定のファイルのタイプにしたがって、再生されたファイルの一部を除去する。当業者が認識するように、このクリーニングプロセスにおいて、プロセッサは、コンテンツデータの一部に対して明白な訂正を行うように設定されている。例えば、或るデータビットの明白な脱落のために、ＪＰＥＧファイルが形成される。このような明白なエラーの場合、クリーニングプロセス中に欠落ビットを加えて、コンテンツデータの一部を修正してもよい。

上述した第１の実施形態では、アクティブ・コンテンツデータの部分に対して、ハッシュが生成される。スクリプト、マクロ、実行可能コードが、意味的に異ならないように修正されるならば、アクティブ・コンテンツデータの異なるバージョンは、ハッシュ・データベースに登録される必要のある全て異なるハッシュとなる。このことを回避するために、スクリプトやマクロや実行可能コードは正規化されて、ハッシュ・データベースに記憶されるべきハッシュを創成する前に、レイアウトおよび変数名の変更が削除される。例えば、スペースおよび改行が全て削除され、変数名は標準化された表記に全て置き換えられる。この結果、スクリプトやマクロや実行可能コードは無用となるが、単に表面的に異なっていて機能的には同一なスクリプトやマクロや実行可能コードが同じテキストに標準化されている限り、この無用となることは重要でない。具体的な例として、ジャバスクリプトファンクションを定義するコードの次の部分は、ＨＴＭＬファイル内に受信される。

コードのこの部分は、全てのスペース（文字列の外）を削除するとともに、全ての変数を標準名（この場合、＄＜ｎ＞。＜ｎ＞は各新変数に対して変数値を増加させる数）に置き換えることによって、標準化される。この例では、標準化されたコードは、結果的には次のようになる。

上述した第１の実施形態では、アクティブ・コンテンツデータの部分に対して、ハッシュが創成される。当業者が認識するように、２つの異なるスクリプト、マクロ、実行可能コードの機能は、同一のハッシュを与える。これが生じる可能性を減少させるために、反復可能な所定のやり方でランダムビットを加えることにより、スクリプト、マクロ、実行可能コードを塩漬けにすることが可能である。その際には、誰かが悪意のあるスクリプトを登録スクリプトとして通すのをいっそう困難にするために、ハッシュが創成される前に行われる。当業者が認識するように、このようにパッシブ・コンテンツデータを変更することによって、誰かが（特に、ハッシュ・データベースの知識を有する誰かが）、許可アクティブ・コンテンツデータに成り済ました悪意あるスクリプト、マクロ、実行可能コードを創成することが、いっそう困難になる。これは、その誰か（彼または彼女）が、ハッシュが創成される前に、内容を変更または変化させるプロセスに関する知識を有していないと考えられるからである。

上述した第１の実施形態では、ハッシュ・データベース１０６は単一のデータベースであって、この単一のデータベースは、悪意のないものとして以前に示されたアクティブ・コンテンツデータに対するハッシュの全てを保管する。当業者が認識しているように、ハッシュ・データベースは、その代わりに、例えば、スクリプト、マクロ、実行可能コードのためのデータベース等の複数の既知のタイプのデータベースを保管することができる。このようにして、ハッシュ・データベースの調査は、例えば、ハッシュが登録されたジャバスクリプトのそれと適合しているために、ＶＢスクリプトが誤って通過するということがないように、アクティブ・コンテンツデータのタイプに対して特有なものとなる。

更に、上述した実施形態の更なる選択肢として、ユーザのためにオーバーライド装置を備えて、電子ファイル受信時に、ユーザが、ＡＶアプリケーションまたはソースフィルタアプリケーションによってなされた判定を手動でオーバーライド（処置）することが考えられる。すなわち、不一致に起因してＡＶアプリケーション内の一致解析装置が電子メールの一部または部分または全体をブロックするときであっても、電子メールの不一致なものの再生、再編成を許可する選択肢がユーザに与えられる。この選択肢の実施の一例は、相手の受信者にテキスト警告書を提供して、不一致と解析された電子メールは、所定の許可フォーマットに一致するものと同様にシステム通過を許可すべきであるか否かを受信者に尋ねることである。この警告に対する応答により、可能であれば、電子メールを再生し、再編成する命令が一致解析装置に与えられる。或いはそれに代わって、オリジナルの電子メールは、ＡＶアプリケーションおよびソースフィルタアプリケーションの両方を迂回することが許可されて、再生されることなくシステムを通過する。

更に、第２の実施形態で説明したＡＶアプリケーションは、ＩＳＰ電子メールサーバ以外の場所に設置し得ることが考えられる。例えば、ＡＶアプリケーションは、受信者の電子メールクライアントサーバに配置し設置してもよい。こうして、電子メールクライアントサーバによってハードディスクドライブ上の受信者受信ボックスに送られた電子メールが、上述した再生電子メールとなる。

更に、ＡＶアプリケーションは、限定的なものではないが、シリコン、ガリウム砒素（ＧａＡｓ）、リン化インジウム（ＩｎＰ）などの半導体素子において、ハードワイヤ接続してもよいことが考えられる。すなわち、ＡＶアプリケーションは定量化可能なタスクを有している。この定量化可能なタスクは、所定の一致フォーマットを形成するプロセスに対して更新する必要がない。構文解析、分析、再生および再編成を含むＡＶアプリケーションのタスクを実行するのに必要な命令は、任意の適切な半導体装置において、実現可能である。また、ＡＶアプリケーションを実行するのに必要な命令は、半固定メモリ素子や固定メモリ素子に格納しておくことが可能である。そのとき、上記メモリ素子は、接続されたプロセッサと協働して作動し、ＡＶアプリケーションを実行する。これらの場合、本発明を、保護すべきコンピュータとは分離して、別個の装置として提供することが可能となる。上記別個の装置（例えば、モデムカード、ネットワークアダプタカード、またはディスクドライブコントローラなどのカード）には、保護すべきコンピュータとは別のプロセッサやメモリハードウェアが含まれる。そうすることによって、到来する電子ファイルを保護すべきコンピュータのファイルシステムその他のリソースから完全に隔離し、通常書込みや更新のできない場所に上記電子ファイルを保存して、それによりＡＶアプリケーション自体に対する“トラップドア”攻撃を回避するという利点が得られる。すなわち、一定レベルの物理的セキュリティが得られるという利点がある。上記半導体装置はプロセッサとメモリ素子とから成り、上記プロセッサはメモリ素子からのＡＶアプリケーションを実行させ、到来ファイルを隔離するために、上記ファイルをメモリ素子に保存する。

更に、上記半導体装置は、従来法を用いる適当なネットワークカードの一部として設けることが考えられる。このようにして、ネットワークカードは、上記方法を用いて受信電子ファイルを再生することによって、ネットワークを不適切なコードおよびデータから確実に保護する手段として、通信ネットワーク内で用いることができる。

更に、上記第１の実施形態で説明した電子ファイルは、コンピュータ装置によって受け取られ、着脱式メモリ素子に保存することが考えられる。例えば、電子ファイルは、直接またはワイヤレスの媒体を介して、コンピュータ装置に接続されたＵＳＢディスク装置、スマートカード、セキュアデジタル（ＳＤ）メモリ装置、マルチメディアカード（ＭＭＣ）メモリ装置、コンパクトフラッシュ（ＣＦ）カード１型または２型、スマートメディア（ＳＭ）カード、ＸＤカード、フロッピーディスク、ＺＩＰドライブ、ポータブルハードドライブ、その他の適切なメモリ装置に保存することができる。

更に、本出願で説明されるオペレーティングシステムは、ファイルを使用するあらゆるシステムであり得ると考えられる。例えば、埋込み型システム、ルータ、ネットワークカード等である。

更に、他のスクランブル方法を用いて、確実に、受信された実行可能ファイルが自動的には実行され得ないことが考えられる。例えば、スクランブル方法は、バイトスワップ法を用いて、受信バイトの各ペアを格納する。この例では、ＡＢＣＤＥＦの６バイトがＡＶアプリケーションによって受信された場合であって、バイトＡが最初にバイトＦが最後に受信された場合には、上記ＡＢＣＤＥＦはＢＡＤＣＦＥの順でメモリに格納される。最初のバイトＡは２番目のメモリ位置に格納され、２番目のバイトＢは最初のメモリ位置に格納される。この反転は、後続のメモリ位置における受信バイトの各ペアに対しても、生じる。このようにして、如何なる実行可能なコードも自動的に動作することができないので、如何なる感染電子ファイルも、ＡＶアプリケーションや送信先のオペレーティングシステムに感染することができない。

上述した実施形態では、電子ファイルは処理用の送信先システムによって受信される。当業者が認識するように、通信ストリーム内でデータファイルを処理するときに、データは、データのチャンク（塊）またはパケットの形で、送信先システムに達する。上記データのチャンクまたはパケットは、処理される電子ファイルの全てを形成すべく蓄積される。一般に、受信される電子ファイルは、丸ごと受信され、連続する一つのメモリに保存される。このような場合、電子ファイルを有効にするために、電子ファイル内の異なる位置のデータを解析する必要があるならば、このような処理が可能となる。ファイル全体がメモリ内に存在するからである。しかし、当業者が認識するように、電子ファイルの全受信データが、メモリ全体として、保存され得るという訳ではない。例えば、ネットワークカードやルータのような装置は、典型的には限定されたメモリ資源を有していて、処理するためにこれらの装置内の電子ファイル全体を緩衝することは、適切ではない。このような環境では、送信者のパソコンのようなソースの装置は、リソースが限定されたネットワーク装置よりもずっと多くのリソースを有している。したがって、ソース装置は、電子ファイルを書き直すように作られていて、ＡＶアプリケーションによって一緒に処理しなければならないファイルの全ての関係部分が、リソース限定装置に整然と流される。このようにして、リソース限定装置は電子ファイル全体を緩衝する必要はない。また、小さな緩衝材を使用して、処理されるファイルの部分のみを保管してもよい。電子ファイルの一部分が処理されて悪意のないものと一旦決定されると、その部分は再生されて、受信者のパソコンのような送信先装置に即座に送られる。このようにして、ストリーミングデータの送信が行われるが、これは、十分なバッファリングアプローチが使用されるならば、データの流れが連続的に開始され停止される「集中的な」タイプの転送とは対照的である。

誤解を避けるために述べておくと、本明細書によって、上述の新規実施形態のいずれか或いは全てに対して、単独で或いは組み合わせで、保護が求められている。本発明の様々な局面および実施形態およびそれらの変形例について説明したので、本発明が、その原理から逸脱することなく、構成や詳細において変更され得ることを当業者は認識する。我々は、全ての実施形態および請求項の精神と範囲に含まれる変更や変形について権利を主張する。

Claims (38)

1. 電子ファイルを処理する方法において、
   上記電子ファイル内のコンテンツデータの一部分を識別することと、
   上記コンテンツデータの識別された一部分が、一定の目的を有するパッシブ・コンテンツデータであるか、或いは、関連したファンクションを有するアクティブ・コンテンツデータであるかを決定することと
   を備え、
   上記コンテンツデータの識別された一部分がパッシブ・コンテンツデータであると決定されたならば、そのときは、
   上記パッシブ・コンテンツデータの上記一部分のファイルタイプまたはプロトコルを決定し、且つ、
   上記ファイルタイプまたはプロトコルに対応する一組のルールを備えた所定のデータフォーマットに上記パッシブ・コンテンツデータが一致するかどうかを決定することによって、上記パッシブ・コンテンツデータの一部分が再生されるべきかどうかを決定し、
   上記コンテンツデータの一部分がアクティブ・コンテンツデータであると決定されたならば、そのときは、
   上記アクティブ・コンテンツデータの一部分を解析して、上記アクティブ・コンテンツデータの一部分が再生されるべきどうかを決定し、且つ、
   上記アクティブ・コンテンツデータの一部分が再生されるべきであると決定されたならば、上記アクティブ・コンテンツデータの一部分を再生して、再生電子ファイルを創成し、
   上記電子ファイルはコンテンツデータの複数の部分を備え、上記方法は、上記コンテンツデータの複数の部分の各々を処理して、アクティブ・コンテンツデータの各部分が再生されるべきか否かを決定し、且つ、再生されるべきと決定されたコンテンツデータのこれらの部分を再生して、再生電子ファイルを創成し、
   上記方法は、クリーニングモードが有効か無効かどうかを決定するステップを更に備え、パッシブ・コンテンツデータの少なくとも一部分が再生されるべきでないと決定され、且つ、クリーニングモードが無効であると決定されたならば、コンテンツデータの部分を再生して再生電子ファイルを創成する上記ステップは実施されないことを特徴とする方法。
2. 請求項１に記載の方法において、
   パッシブ・コンテンツデータの少なくとも一部分が再生されるべきでないと決定され、且つ、クリーニングモードが無効であると決定されたならば、上記電子ファイルが隔離されることを特徴とする方法。
3. 請求項１乃至２のいずれか一つに記載の方法において、
   アクティブ・コンテンツデータの一部分を解析する上記ステップは、
   上記アクティブ・コンテンツデータの一部分のためのハッシュを創成することと、
   上記創成されたハッシュが既知のアクティブ・コンテンツデータのハッシュ・データベースに存在するかどうかを決定することと、
   上記創成されたハッシュが上記ハッシュ・データベースに存在することが決定されたならば、上記アクティブ・コンテンツデータの一部分は再生されるべきことを決定することと
   を備えていることを特徴とする方法。
4. 請求項１乃至３のいずれか一つに記載の方法において、
   電子ファイル内のパッシブ・コンテンツデータの一部分がパッシブ・コンテンツデータの複数のサブ部分を備え、上記サブ部分の各々が処理されて、上記パッシブ・コンテンツデータのサブ部分が所定のファイルフォーマットに一致するかどうかを決定し、上記サブ部分の全てが所定のファイルフォーマットに一致するならば、上記パッシブ・コンテンツデータの一部分は所定のファイルフォーマットに一致すると決定されることを特徴とする方法。
5. 請求項４に記載の方法において、
   上記パッシブ・コンテンツデータの複数のサブ部分は、異なるファイルタイプを有することを特徴とする方法。
6. 請求項１または２のいずれか一つに記載の方法において、
   アクティブ・コンテンツデータの一部分を解析する上記ステップは、第三者のアンチウイルス・アプリケーションを用いて上記アクティブ・コンテンツデータの一部分を処理することによって、上記アクティブ・コンテンツデータの一部分が再生されるべきか否かを決定することを特徴とする方法。
7. 請求項１乃至６のいずれか一つに記載の方法において、
   上記パッシブ・コンテンツデータは、テキストまたはイメージまたはオーディオまたはビデオのコンテンツデータを備えていることを特徴とする方法。
8. 請求項１乃至７のいずれか一つに記載の方法において、
   上記アクティブ・コンテンツデータは、スクリプトまたはマクロまたは実行可能コードを備えていることを特徴とする方法。
9. 請求項１乃至８のいずれか一つに記載の方法において、
   パッシブ・コンテンツデータの一部分の意図する所定のデータタイプを決定することができないならば、そのときは、そのパッシブ・コンテンツデータの一部分をアクティブ・コンテンツデータの一部分として解析することを特徴とする方法。
10. 請求項３に記載の方法において、
    アクティブ・コンテンツデータの一部分を標準化するステップを更に備え、ハッシュを創成する上記ステップは、上記アクティブ・コンテンツデータの標準化された一部分のためのハッシュを創成することを特徴とする方法。
11. 請求項３に記載の方法において、
    所定の繰り返し可能なやり方でアクティブ・コンテンツデータの一部分を変換するステップを更に備え、ハッシュを創成する上記ステップは、アクティブ・コンテンツデータの変換された一部分のためのハッシュを創成することを特徴とする方法。
12. 請求項１乃至１１のいずれか一つに記載の方法において、
    メモリ内にスクランブルフォーマットで電子ファイルを格納することを更に備えていることを特徴とする方法。
13. 請求項１２に記載の方法において、
    データの各バイトは、ビットが逆の順で格納されることを特徴とする方法。
14. 請求項１２に記載の方法において、
    上記データは、受信データのバイトの各ペアが逆のメモリ順で配置されるように、格納されることを特徴とする方法。
15. 請求項１乃至１４のいずれか一つに記載の方法において、
    再生されるべきでないと決定されたコンテンツデータの一部分を警告テキストに置き換えることを更に備えていることを特徴とする方法。
16. 請求項１に記載の方法において、
    上記電子ファイルは電子メールであり、上記方法は再生された電子メールを所望の受信者に送ることを更に備えていることを特徴とする方法。
17. 請求項１に記載の方法において、
    着脱式メモリ装置から上記電子ファイルを受信することと、計算装置に上記再生された電子ファイルを送ることとを、更に備えていることを特徴とする方法。
18. コンピュータ可読媒体は、コンピュータ上でコンピュータプログラムを実行させたときに、請求項１乃至１７のいずれか一つに記載の方法を行うように構成された上記コンピュータプログラムを備えていることを特徴とする半導体装置。
19. 請求項１乃至１７のいずれか一つに記載の方法を行うための指示を含むメモリ手段を備えていることを特徴とする半導体装置。
20. 請求項１９に記載の半導体装置において、
    上記半導体装置は半永久または永久メモリ装置であることを特徴とする半導体装置。
21. 請求項１９または２０に記載の半導体装置を備えていることを特徴とするネットワークカード。
22. 電子ファイルのコンテンツデータの一部分を識別するための手段と、
    上記コンテンツデータの識別された部分が、一定の目的を有するパッシブ・コンテンツデータであるか、或いは関連するファンクションを有するアクティブ・コンテンツデータであるかどうかを決定するための手段と、
    パッシブ・コンテンツデータの一部分のファイルタイプまたはプロトコルを決定するための手段であって、上記パッシブ・コンテンツデータが、上記ファイルタイプまたは上記プロトコルに対応する一組のルールを備えた所定のデータフォーマットに一致するかどうかを決定することによって、パッシブ・コンテンツデータの一部分が再生されるべきかどうかを決定するための手段と、
    アクティブ・コンテンツデータの一部分を解析してアクティブ・コンテンツデータの一部分が再生されるべきかどうかを決定するための手段と、
    上記コンテンツデータの一部分が再生されるべきであると決定されたならば、上記コンテンツデータの一部分を再生して再生電子ファイルを創成するための手段と
    を備え、
    上記電子ファイルはコンテンツデータの複数の部分を備え、上記装置は、上記コンテンツデータの複数の部分の各々を処理して、アクティブ・コンテンツデータの各部分が再生されるべきか否かを決定し、且つ、再生されるべきであると決定されたコンテンツデータのこれらの部分を再生して、再生電子ファイルを創成するように、構成されており、
    クリーニングモードが有効なのか無効なのかを決定するための手段を更に備え、
    パッシブ・コンテンツデータの少なくとも一部分が再生されるべきでなく、且つ、上記クリーニングモードが無効であると決定されたならば、コンテンツデータの部分を再生するための上記手段は、再生電子ファイルを創成しないように構成されていることを特徴とする装置。
23. 請求項２２に記載の装置において、
    パッシブ・コンテンツデータの少なくとも一部分が再生されるべきでなく、且つ、上記クリーニングモードが無効であると決定されたならば、上記装置は、上記電子ファイルを隔離するように構成されていることを特徴とする装置。
24. 請求項２２または２３に記載の装置において、
    アクティブ・コンテンツデータの一部分を解析するための上記手段は、
    上記アクティブ・コンテンツデータの一部分のためのハッシュを創成し、
    上記創成されたハッシュが既知のアクティブ・コンテンツデータのハッシュ・データベースに存在するかどうかを決定し、
    上記創成されたハッシュが既知のアクティブ・コンテンツデータのハッシュ・データベースに存在すると決定されたならば、上記アクティブ・コンテンツデータの一部分は再生されるべきであると決定する
    ように構成されていることを特徴とする装置。
25. 請求項２２乃至２４のいずれか一つに記載の装置において、
    パッシブ・コンテンツデータの一部分のファイルタイプまたはプロトコルを決定するための手段は、特定のファイルタイプまたはプロトコルに各々が関連する複数の一致分析装置を備えていることを特徴とする装置。
26. 請求項２５に記載の装置において、
    上記電子ファイル内のパッシブ・コンテンツデータの一部分は、パッシブ・コンテンツデータの複数のサブ部分を備え、上記サブ部分の各々は上記複数の一致分析装置の内のそれぞれ一つの一致分析装置によって処理されて、上記パッシブ・コンテンツデータのサブ部分が所定のデータフォーマットに一致するかどうかを決定することを特徴とする装置。
27. 請求項２２乃至２６のいずれか一つに記載の装置において、
    コンテンツデータの一部分を再生するための手段は、特定のファイルタイプまたはプロトコルに各々が関連する複数のコンテンツ再生装置を備えていることを特徴とする装置。
28. 請求項２２乃至２７のいずれか一つに記載の装置において、
    アクティブ・コンテンツデータの一部分を解析するための上記手段は、第三者のアンチウイルス・アプリケーションを用いて上記アクティブ・コンテンツデータの一部分を処理することによって、上記アクティブ・コンテンツデータの一部分が再生されるべきか否かを決定するように構成されていることを特徴とする装置。
29. 請求項２２乃至２８のいずれか一つに記載の装置において、
    上記パッシブ・コンテンツデータは、テキストまたはイメージまたはオーディオまたはビデオのコンテンツデータを備えていることを特徴とする装置。
30. 請求項２２乃至２９のいずれか一つに記載の装置において、
    上記アクティブ・コンテンツデータは、スクリプトまたはマクロまたは実行可能コードを備えていることを特徴とする装置。
31. 請求項２２乃至３０のいずれか一つに記載の装置において、
    アクティブ・コンテンツデータの一部分を解析するための上記手段は、更に、パッシブ・コンテンツデータの一部分の所定とされるデータタイプを決定する上記手段が、上記パッシブ・コンテンツデータの一部分の所定とされるデータタイプを決定することができないならば、パッシブ・コンテンツデータの一部分を解析するように構成されていることを特徴とする装置。
32. 請求項２２乃至３１のいずれか一つに記載の装置において、
    アクティブ・コンテンツデータの一部分を標準化する手段を更に備えていることを特徴とする装置。
33. 請求項２２乃至３２のいずれか一つに記載の装置において、
    上記電子ファイルをメモリ内にスクランブルフォーマットで格納するための手段を更に備えていることを特徴とする装置。
34. 請求項３３に記載の装置において、
    データの各バイトは、ビットが逆の順で格納されていることを特徴とする装置。
35. 請求項３３に記載の装置において、
    上記データは、受信データのバイトの各ペアが逆のメモリ順で配置されるように、格納されることを特徴とする装置。
36. 請求項２２乃至３５のいずれか一つに記載の装置において、
    電子ファイルを再生するための上記手段は、更に、再生されるべきでないと決定されたコンテンツデータの一部分を警告テキストに置き換えるように構成されていることを特徴とする装置。
37. 請求項２２に記載の装置において、
    上記電子ファイルは電子メールであり、また、上記装置は、再生された電子メールを所望の受信者に送付するための手段を更に備えていることを特徴とする装置。
38. 請求項２２に記載の装置において、
    着脱式記憶装置からの上記電子ファイルを受信するための手段と、上記再生された電子ファイルを計算装置に送付するための手段とを、更に備えていることを特徴とする装置。

Images