情報管理システム
【課題】情報交換のための単一統合システムをもたらす、追加の機能性を提供すること。
【解決手段】情報管理システムは、ユーザがネットワークに接続することを可能とするアプリケーションが実行される一又はそれ以上のワークステーションを含む。各アプリケーションは、アプリケーションがネットワークに送信しようとしているか、又はネットワークから受信したばかりの送信データをモニターし、そのデータに関して取るべき適切なアクションを決定するアナライザを有する。アナライザは、どのようなアクションを取るべきかを決定するために、ワークステーションを制御するための、スーパバイザにより定義されたポリシーを含むポリシーデータを参照することができる。そのアクションは、保存や記録保持のために、送信データからパスワード、ユーザ名、デジタル署名、電子商取引の取引の詳細といったデータを抽出することとすることができる。
【解決手段】情報管理システムは、ユーザがネットワークに接続することを可能とするアプリケーションが実行される一又はそれ以上のワークステーションを含む。各アプリケーションは、アプリケーションがネットワークに送信しようとしているか、又はネットワークから受信したばかりの送信データをモニターし、そのデータに関して取るべき適切なアクションを決定するアナライザを有する。アナライザは、どのようなアクションを取るべきかを決定するために、ワークステーションを制御するための、スーパバイザにより定義されたポリシーを含むポリシーデータを参照することができる。そのアクションは、保存や記録保持のために、送信データからパスワード、ユーザ名、デジタル署名、電子商取引の取引の詳細といったデータを抽出することとすることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特に情報セキュリティ、取引監査及び報告、中央集中型ポリシー、及び、アプリケーション接続性の領域において、「インターネット」アプリケーションに対する拡張管理機能性を提供することに関する。
【背景技術】
【０００２】
特に企業間（Ｂ２Ｂ）、また、企業・消費者間（Ｂ２Ｃ）での電子商取引（ｅＣｏｍｍｅｒｃｅ）は、郵便、電話、及び、個人的な面談などのこれまでの手段ではなく、リンクしたコンピュータシステムから成る世界的なネットワークである「インターネット」を使用して買い手及び売り手が通信する、急速に成長している市場である。売り手は、「インターネット」への接続、「ワールド・ワイド・ウェブ」上のページ、又は、一般的に特定の市場部門の品物及びサービスを商う電子市場を通じて閲覧又はダウンロードすることができるデジタル小冊子及びカタログを使用して製品及びサービスを宣伝する。買い手は、全て電子的に、またいつでも、供給業者を捜し、品物を選択し、見積りを取得し、注文をしてそれを追跡し、支払いさえも行うことができる。「ｅＣｏｍｍｅｒｃｅ」によって、調達経費の大幅な軽減による柔軟性、選択性、及び、効率の向上が約束される。
【０００３】
ユーザを「インターネット」に接続する世界的に容認されている方法は２通りある。その１つは「ウェブブラウザ」であり、これによって、ユーザは、個々のウェブサイトにアクセスすることにより「ワールド・ワイド・ウェブ」上のページを閲覧することができ、そのアドレスは、一般的にこれまでの手段を使用して広く公開されているか、又は、別のウェブサイトで参照される。最も広く採用されているウェブブラウザは、マイクロソフト・コーポレーション製の「インターネット・エクスプローラ」である。
【０００４】
第２の接続手段は、「電子メール」プログラムを使用することであり、これによって、ユーザは、「ｅ−ｍａｉｌ」として公知のメッセージを作成し、これは、次に「インターネット」上で意図する受信者のアドレスに電子的に経路指定される。よく知られている「電子メール」プログラムには、ＩＢＭ・コーポレーション製の「ロータス・ノーツ」、及び、マイクロソフト・コーポレーション製の「アウトルック」が含まれる。
【０００５】
一般的な「ｅＣｏｍｍｅｒｃｅ」のシナリオにおいては、買い手は、売り手のウェブサイト上で価格設定及び配達情報と共に、特定の製品を特定すると考えられる。買い手は、次に、ウェブサイト上の電子注文書式に必要事項を記入するか、又は、売り手に直接「電子メール」を送ることによって注文する。注文には、一般的に、恐らくは「クレジットカード」に関する詳細事項という形か、又は、何らかの電子支払い手段による支払いの約束が含まれることになる。次に、売り手は、一般的に返信電子メールを送って受注を確認する。
【０００６】
「ウェブブラウザ」は、認定された各種の規格、特に「インターネット」規格文書「ＲＦＣ２６１６」で詳細に記載されている「ハイパーテキスト・トランスファープロトコル（ＨＴＴＰ）」に従って作動する。「電子メール」プログラムは、認定された各種の規格、特に「インターネット」規格文書「ＲＦＣ０８２１」で詳細に記載されている「シンプルメール・トランスファープロトコル（ＳＭＴＰ）」、及び、「インターネット」規格文書「ＲＦＣ２０４５−２０４９」で詳細に記載されている「多目的インターネットメール拡張仕様（ＭＩＭＥ）」に従って作動する。
【０００７】
「ｅＣｏｍｍｅｒｃｅ」は莫大な利点をもたらすが、その採用は、多くの新しい問題になっており、特に最終的にこれまでの方法に取って代わろうとする場合、その継続的な採用を確保するためにこれらの問題に対処しなければならない。重要問題の１つは、セキュリティである。
「インターネット」は、開放型通信ネットワークであり、それは、誰でも使用することができることから定義上安全性に欠けるものである。「インターネット」上で交換される機密性情報（例えば、「ｅＣｏｍｍｅｒｃｅ」取引において）を保護する手段は、確実な送信プロトコル及びメッセージ処理の採用によってこれまでに実現されている。例えば、ウェブ「サーバ」とウェブ「ブラウザ」との間で使用されている確実な点間送信プロトコルには、ネットスケープ・コミュニケーションズ・コーポレーションによって定義されている「セキュア・ソケット・レイヤー（ＳＳＬ）」、及び、「インターネット」規格文書「ＲＦＣ２２４６」で定義されているその継承プロトコル「トランスポート・レイヤー・セキュリティ（ＴＬＳ）」が含まれる。確実な電子メールメッセージ規格には、「インターネット」規格文書「ＲＦＣ２６３３」で詳細に定義されている「機密性多目的インターネットメール拡張仕様（Ｓ／ＭＩＭＥ）」、及び、フィリップ・チマーマンによって開発された公有機密性メッセージ処理システム「プリティ・グッド・プライバシー」が含まれる。
【０００８】
「インターネット」に接続されたサーバ上の情報へのアクセスを管理するために、ユーザ名及びパスワードから成るシステムが広く採用されている。例えば、特定のウェブサーバ上の割引価格リストへのアクセスは、アクセスを許可するユーザ名及びパスワードを過去に提示した取引上のユーザに制限することができる。同様に、オンライン情報サービスでは、一般的に、そのサービスに対して支払いがあった者にアクセスを制限するためのユーザ名及びパスワードが広範囲に使用されている。各ユーザに独特なユーザ名及び変更可能なパスワードを与えることによって、そのサービスにより支払済みの加入者のみがシステムにアクセスすることができるようにすることができ、ユーザは、そのサービスによって記憶された個人的データへの他人によるアクセスを防止することができる。
【０００９】
「ｅＣｏｍｍｅｒｃｅ」の用途において、重要な問題は、身元及び信頼性という問題である。供給業者が「インターネット」を通じて注文を受信した時、その顧客に関する事前の知識を有していないことは全くあり得ることであり、おそらくありそうなことである。供給業者は、顧客が、ａ）自分で言っているその本人であること、換言すると、誰かが他の誰かに成りすましているのではないこと、及び、ｂ）信頼することができ、提供する品物又はサービスに対して最終的に支払いをする意志が有ることを立証しなければならない。これらの問題は、「Ｂ２Ｃ」市場では、これまでは主としてクレジットカードを使用して対処されている。顧客は、自分のクレジットカード番号及び住所を注文と共に提示し、次に、供給業者はクレジットカード会社に確認し、その料金に対する許可を取得する。この処理全体は、人間の介入がなく、一般的に全くオンライン上で行われる。この方法は、供給業者がクレジットカード保持者の住所に品物を出荷する場合には大体において効果的であり、なぜなら、潜在的な窃盗犯は、カード保持者の詳細を盗み出す必要があるばかりでなく、品物の配達に割り込む必要があるからである。物理的な配達を伴わないサービスの場合には、その効果ははるかに落ちる。
【００１０】
明らかに、「ｅＣｏｍｍｅｒｃｅ」におけるクレジットカードの使用は、普及してはいるものの、例えば最大１０，０００ドルまでの金額を伴う可撓性のある小規模の取引に制限されている。このような金額を上回る取引（総額の金銭的条件がそれ以下のもののそれを遥かに上回るもの）の場合、相互に信頼された第三者を使用して、身元及び信頼性を立証しなければならない。
身元の立証の要であるのは、「デジタル証明書」の使用である。顧客は、信頼された第三者による「デジタル証明書」の発行を受けることができ、次に、「デジタル証明書」は、通信事項に電子的に「署名する」ために使用される。署名入りメッセージが受信されると、受信者（この場合は供給業者）は、ａ）送信者の身元、ｂ）メッセージが変更されていないこと、及び、ｃ）送信者が後で自分がメッセージを送信したことを否定できないこと、を明確に立証することができる。「デジタル証明書」に関する認定された規格は、「ＩＴＵ」文書「Ｘ．５０９」に説明されており、「インターネット」通信におけるその使用は、「インターネット」規格文書「ＲＦＣ２３１２」、「ＲＦＣ２４５９」、「ＲＦＣ２５１０」、「ＲＦＣ２５１１」、「ＲＦＣ２５２７」、「ＲＦＣ２５６０」、「ＲＦＣ２５８５」、及び、「ＲＦＣ２６３２」で説明されている。
バリサート・コーポレーションによって提供されるサービスなどの請求可能な第三者サービスは、「デジタル証明書」が例えば何らかの方法で危うくなった後で証明書が無効にされていないことを確認するのに使用することができる。
【００１１】
メッセージの信憑性が立証されると、供給業者は、別の第三者を利用して信頼性を立証することができるか、又は、同一の第三者を利用して信憑性及び信頼性を立証することができる。例えば、世界の大手銀行の協会である「Ｉｄｅｎｔｒｕｓ」は、供給業者が「Ｉｄｅｎｔｒｕｓ」発行の「デジタル証明書」を用いて署名されたメッセージを受信した時、供給業者が、その顧客が認定銀行と良好な取引状態にある有効な口座保持者であることを独立に確認することができるシステムを提供する。
【００１２】
最終的には、このシステムは、銀行が更に取引を保証し、それによって供給業者に対する支払いが保証されるように拡張されることになる。「顧客」及び「供給業者」という用語は、「インターネット」通信に関わる任意の２つの当事者に適用できることが認められるであろう。
上述のシステムの適切な組合せによって、「インターネット」の使用、及び、「インターネット」を通じて利用可能なサービス及び機能に対する確実な基礎が得られることが分る。しかし、これらのシステムのみを使用して「ｅＣｏｍｍｅｒｃｅ」を行うことに関するいくつかの問題があることが認められる。これらの問題について以下で検討する。
【００１３】
上記で参照した機密性送信プロトコル及びメッセージ処理において、データは、通常は送信される前に暗号化され、閲覧する前に意図する受信者によって復号化が行われる。従って、万一データが送信中に傍受された場合、無許可の第三者が復号化アルゴリズムの秘密の復号化キーを知っているか又は確認することができる場合を除き、無許可の第三者によって閲覧されずに安全なものとなる。
機密リンク又はメッセージの各終点でのデータの暗号化及び復号化には、かなりの処理パワーが必要とされる。更に、送信側及び受信側の双方の当事者は、システムが問題なく作動するために、同じ暗号化強度での暗号化アルゴリズムの同一暗号化キーを所有していなければならない。これは、例えば、コンピュータシステムに対するデータのインポート及びエクスポートの規制によってより高強度のアルゴリズムの使用が禁止されており、リンク又はメッセージがより低い強度で暗号化せざるを得ないか又は機密性通信が全くできない場合には問題になることが多い。その結果、機密リンク及びメッセージ処理は、通常は必要な時に限って使用される。
【００１４】
「ワールド・ワイド・ウェブ」上での通信の場合、機密性通信に対する要件は、「ウェブサーバ」によって判断及び開始される。例えば、サーバがユーザに漏れなく記載させるために注文書を送信しようとしている場合、注文書がサーバに返送される時に暗号化されるように機密リンクを開始することができる。同様に、注文が完了すると、サーバは、機密リンクを終了して通常の暗号化されていない通信に戻ることができる。
【００１５】
一般的に、リンクが機密であることを示すユーザが有する唯一のものはアイコン（通常は南京錠を示す）であり、ブラウザウインドウ内に表示される。このアイコンが表示されると、ユーザは、一般的に、ブラウザに問い合わせて使用されている暗号化アルゴリズムの強度を判断することができ、クレジットカード及びアドレス詳細などの機密性情報を入力して続けて送信するか否かを決めることができる。
しかし、実際には、ユーザは、リンクが機密性のものであるか検査しないことが多く、それが送信されている情報を保護するのに適切な暗号化強度であることを検査する頻度ははるかに少ない。この問題に対処するために、マイクロソフト・コーポレーション製の「アウトルック」などの「電子メール」アプリケーションは、初期設定によって全ての「電子メール」を暗号化する能力を提供する。
【００１６】
ユーザ名及びパスワードの広範囲な採用は、特に効果的なセキュリティ上の慣行としてパスワードを頻繁に変更する必要ある時に、覚えておく必要がある真の番号のために多くの「インターネット」ユーザに対して管理上の問題を引き起こす。同様に、ユーザは、他の誰かが既に自分のユーザ名の「お気に入り」を任意のサイトで使用している恐れがあることから、多くの場合様々な異なるユーザ名を使用する必要があることになる。ユーザ名及びパスワードを覚えたり、その後の機会にユーザ名及びパスワードフィールドを自動的に書き込むための機能は、マイクロソフト・コーポレーション製の「インターネット・エクスプローラ」などのウェブブラウザ、及び、「Ｇａｔｏｒ．ｃｏｍ」製の「Ｇａｔｏｒ」などの付加的な「ヘルパー」機能によって設けられている。これらの機能によって、一般的に、ユーザ名、パスワード、及び、それぞれが適用されるウェブページのファイルが維持される。これらのファイルは、確実に適切なユーザのみがアクセスすることができるように暗号化される。許可されたユーザが暗号キーを忘れてしまったり、もはや暗号キーを与えるのに連絡することができない時、又は、ファイルが誤って又は故意に、紛失、破壊、又は、改ざんされた時など、このようなユーザ名及びパスワードが失われたり、又は、利用することができなくなった場合、「インターネット」アカウント及びサービスへのアクセスが失われる恐れがあり、必要なユーザ名及び／又はパスワードを交換又は取り戻すために、各サイトに個別に接続しなければならない。これは、アクセスの喪失及び管理時間に関して企業にとっては非常に経費の掛かる問題になりかねない。更に、このような記憶されたユーザ名及びパスワードは、最初に使用された機械上での使用にのみ利用可能である。ユーザが別の機械に移ったり、複数の機械を使用する場合、記憶されたユーザ名及びパスワードは、これらの他の機械からはユーザは利用することができない。
【００１７】
全ての企業及び多くの個々のユーザは、自分たちが着手する取引の正確な記録を維持する法律上の義務を有するが、「ｅＣｏｍｍｅｒｃｅ」取引に関しては、これが困難であることを証明することができる。企業は、例えば、論争の場合には品物が注文された条件を証明するために監査を目的として記録を維持しなければならない。このような記録は、「ｅＣｏｍｍｅｒｃｅ」環境においてはかなり維持し難く、ユーザは、例えば「電子メール」で送られた注文書のコピーを保管するとか、又は、ウェブサイト購入からのウェブページ領収書を印刷しておく必要がある。ユーザにとっては、これは労力を要するものであり、このように作成されたいかなる記録も完全なもの又は信頼できるものであるという保証はない。
【００１８】
「ｅＣｏｍｍｅｒｃｅ」取引の記録を保管する１つの自動的なソリューションは、マックス・マネジャー・コーポレーション製の「ＡＭａｘ Ｍａｎａｇｅｒ（登録商標）」アプリケーションによって実現されている。「Ｍａｘ Ｍａｎａｇｅｒ」は、公知のウェブサイトで領収書ページを捕捉し、取引情報をそれらの領収書ページから抽出し、そのアプリケーションが実行されている機械上で領収書ページ及び抽出された取引情報の両方をローカルに記憶する。しかし、「Ｍａｘ Ｍａｎａｇｅｒ」は、作動させるために領収書ページの正確なアドレス及びレイアウトを供給してやる必要がある。「Ｍａｘ Ｍａｎａｇｅｒ」は、領収書ページのアドレスを判断するか、又は、ブラウザによって閲覧されている現在のページを領収書ページが供給された領収書ページのそのレイアウトと比較するかのいずれかにより、「ｅＣｏｍｍｅｒｃｅ」取引が行われたことを判断する。領収書ページを特定すると、適合させるためのテンプレートとしてページの公知のレイアウトを使用することにより、該当取引の詳細が領収書ページから抽出される。「Ｍａｘ Ｍａｎａｇｅｒ」の重大な欠点は、データが詳細と共に供給されたページからデータを抽出するためにしかそれを使用することができないということである。更に、領収書ページのレイアウトが変更されている場合、「Ｍａｘ Ｍａｎａｇｅｒ」は、変更後のレイアウト用の新しいテンプレートが供給されるまで、ページからいかなるデータもまともに抽出することができない。ウェブサイトは頻繁に変更されることから、「Ｍａｘ Ｍａｎａｇｅｒ」は、このような変更を考慮するために絶えず更新されなければならない。これは、大局的には非実用的であり、必然的に取引が見逃され、更に悪い場合には間違った報告がなされる。
【００１９】
これらの問題はまた、コンピュータ端末が分散式であり、その結果、多くの場合に端末とユーザとが別々の場所にいるということからきている。複数ユーザという環境においては、ユーザコンピュータは、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）を使用して、物理的に互いに接続することができ、「ＬＡＮ」によって「インターネット」への接続のための「ゲートウェイ」が得られる。また、ユーザコンピュータは、「電子メール」メッセージの中央収集及び配信点として機能するマイクロソフト・コーポレーション製の「エクスチェンジ・サーバ」、頻繁に閲覧するウェブサイトの性能を改善するためのキャッシュとして、及び、望ましくないものと指定された特定のウェブサイトへのアクセスを防止するためのフィルタとして機能するマイクロソフト・コーポレーション製の「プロキシー・サーバ」などのローカルサーバに接続することができる。しかし、２つのローカルユーザ間で送られるメッセージの場合を除き、情報の交換に関する限り、各ユーザは、同一場所で他人から全く孤立して作動する。これは、従業員の活動を中央で管理する手段を有さず、情報の共有から為し得る大幅な経費節約の恩恵を受けることができない企業及び他の組織に対して重大な管理上の問題を呈する。例えば、組織内の２つのユーザは、同一送信者によってデジタル署名された「電子メール」メッセージを独立して受信する恐れがある。双方の受信者は、個別に「デジタル証明書」を確認しなければならず、２つの確認料金が発生して少なくともその１つは不要なものである。
【発明の概要】
【発明が解決しようとする課題】
【００２０】
本発明は、上述のシステム固有の問題を緩和し、情報交換のための単一統合システムをもたらす、上述のシステムへの追加の機能性を提供する。
【００２１】
本発明は、ここで参照すべき独立請求項に示されており、本発明の有利な態様は、特許請求の範囲に示されている。
情報管理システムは、「ｅＣｏｍｍｅｒｃｅ」環境における多くの利点をオンライン商社にもたらし、オンライン商社は、ポリシーデータに暗号化された取引の命令に従って従業員によって為される取引を制御し、パスワード及びオンラインで行われた取引の記録を自動的に維持し、「デジタル証明書」の確認に関する不要な検査の支払いを回避し、従業員によるデータの送信が常に機密に実行されるように保証することができることによる恩恵を受ける。
ここで、本発明の好ましい実施形態について、図面を参照しながら例示的に更に詳細に説明する。
【図面の簡単な説明】
【００２２】
【図１】従来技術により「インターネット」を構成するシステム及びリソースの現在の構成の概略図である。
【図２】企業環境において実行される本発明の好ましい実施形態の概略図である。
【図３】本発明の好ましい実施形態によるウェブブラウザの作動の概略図である。
【図４】ウェブブラウザによって作られた一般的な入力ウインドウの図である。
【図５】本発明の好ましい実施形態による「電子メール」クライアントの作動の概略図である。
【図６】ユーザによって遠隔ウェブサイトに送信されたユーザ名及びパスワード値を捕捉するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図７】データを記録するための制御条件を指定する例示的なポリシーデータの図である。
【図８】ウェブサイト又は「電子メール」クライアントに対して送受信されたデータに含まれるクレジットカード番号を認識するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図９】ユーザによって受信された「デジタル証明書」の有効性を立証するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１０】「デジタル証明書」を確認すべきか否かを判断するための例示的なポリシーデータの図である。
【図１１】「デジタル証明書」に対して確認が必要とされるか否かを判断するために、図１０に示した例示的ポリシーデータを使用する方法を示すフローチャートである。
【図１２】「ｅＣｏｍｍｅｒｃｅ」取引の一部を構成するユーザに対する送受信を特定するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１３】取引を特定するために図１２に示した処理と共に使用されることを意図した例示的なポリシーデータの図である。
【図１４】単一取引の一部を構成すると特定された送信を記録することにより取引の記録を形成するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１５】特定された取引を所定のポリシー設定に基づいて承認又は拒否するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１６】特定された取引が承認を必要とするか否かを判断し、適切な承認者を特定するための例示的なポリシーデータの図である。
【図１７】伝送のための適切なレベルの暗号化を判断し、そのレベルが設けられている場合に限りその伝送が送信されることを可能にするための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１８】必要とされる暗号化強度を様々なデータ形式に対して指定する例示的なポリシーデータの図である。
【図１９】発信メッセージの再方向付けを制御するための例示的なポリシーデータの図である。
【図２０】図１９に示したポリシーデータを利用して送信前に検討するために発信メッセージを第三者に再方向付けするための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図２１】図１９に示したポリシーデータを利用して会社外部のサイトへの情報のアップロードを制御するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図２２】会社内外の受信者へのメッセージの転送を制御するための例示的なポリシーデータの図である。
【図２３】図２２に示すポリシーデータを利用する本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図２４】発信メッセージがデジタル署名されているか否かを管理するための例示的なポリシーデータの図である。
【図２５】図２４に示すポリシーデータを利用する本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【発明を実施するための形態】
【００２３】
好ましいシステムは、「インターネット」のユーザにコンピュータシステム上の情報の流れを管理する自動的な方法を提供する。それは、送信が行われるセキュリティレベルを管理する機能、オンライン取引を記録し、承認を得るために第三者にまさに行われようとしている取引を参照する機能、及び、承認が拒否された場合に取引が発生するのを防止する手段を提供し、それはまた、受信されたか又はまさに送信されようとしているいかなる伝送からの関連データも抽出及び記録し、電子メールの送信を知的に管理する機能を提供する。
【００２４】
好ましいシステムは、「インターネット」上で商売をする「ｅＣｏｍｍｅｒｃｅ」会社が遭遇する問題の多くに対するソリューションを提供する。このため、以下で論じられる例示的な内容は、ほとんど「インターネット」上で自社事業の少なくとも一部を行っている妥当な規模の会社による本システムの実施及び使用に関するものとなる。しかし、いかなる規模及び概要の会社や民間の個人を含む「インターネット」を使用する人はだれでも、好ましいシステムによってもたらされる機能性の恩恵を受けることができることが認められるであろう。
好ましいシステムの機能性は、ウェブブラウザ又は電子メールクライアントに「プラグイン」されるコード・モジュールを通じて実行される。これらのプラグイン・モジュールを使用して、作動中のウェブブラウザ又は電子メールクライアントの挙動を制御又は変更することができる。
【００２５】
多くの既存のウェブブラウザ及び電子メールクライアントは、既に、このようなプラグイン・モジュールと容易に一体化することができる。マイクロソフト・コーポレーション製の「インターネット・エクスプローラ」の場合、プラグインは「ブラウザ・ヘルパー」として知られており、１９９９年１月にマイクロソフト・コーポレーションによって発行された、ディノ・エスポシト著の文書「ブラウザ・ヘルパー・オブジェクト：あなたが望むようなブラウザ」において詳しく説明されている。マイクロソフト製の「アウトルック」及び「エクスチェンジ・ｅ−ｍａｉｌ・クライアンツ」の場合、プラグインは、「エクステンション」として知られており、１９９８年３月にマイクロソフト・コーポレーションによって発行された、シャロン・ロイド著の文書「マイクロソフト・アウトルック及びエクスチェンジ・クライアント・エクステンション」において詳しく説明されている。好ましいシステムで作られた「ブラウザ・ヘルパー・オブジェクト」及び「エクステンション」プラグインの使用については、更に詳細に後述する。
【００２６】
好ましいシステムの機能性を実行するためのブラウザ又は電子メールクライアントのプラグイン・モジュールの使用には、メッセージ内容の暗号化が通常はブラウザ又は電子メールクライアント自体によって行われることから、パスワード情報を抽出するため又は暗号化の目標とするレベルを判断するための送信コンテントの検査を、例えばコンテントが暗号化されて送信準備完了の状態になる前、又は、実際に受信後の非暗号化の状態となった後に行うことができるという付加的な利点がある。
【００２７】
図１は、一般的に「インターネット」１０上で品物及びサービスを販売している会社であるサービスプロバイダと、このような品物又はサービスを購入することを希望するユーザとの間の関係を示す。ウェブブラウザ２２、２４、及び、２６を備えたユーザは、「インターネット」を通じて接続し、ウェブページ情報をウェブサーバ１４及び１８から検索することができる。代替的に、電子メールアプリケーション２０、３０、及び、３２を有するユーザは、「ａｂｃ．ｃｏｍ」及び「ｘｙｚ．ｃｏｍ」を有する電子メッセージを電子メールサーバ１２及び１６を通じて送受信することができる。
【００２８】
図１の右下隅に示すものなどの企業レベルの設定において、企業ユーザのウェブブラウザ２４及び２６は、プロキシー・サーバ２８を通じて「インターネット」に接続される。プロキシー・サーバ２８は、ウェブページをキャッシュし、ウェブサイトへのアクセスを制御するのに使用される。同様に、企業は、企業に入ってくる電子メールの中央回収点として機能し、個々のユーザへの電子メールの配信を制御する電子メールサーバ３４を通じて「インターネット」に接続された電子メールクライアント３０及び３２を有する。図１は、「ａｂｃ．ｃｏｍ」及び「ｘｙｚ．ｃｏｍ」を売り手として示すが、企業は、買い手及び売り手の両方になり得ることが理解され、買い手として、「ａｂｃ．ｃｏｍ」及び「ｘｙｚ．ｃｏｍ」は、この説明のために企業ユーザとして説明される。
【００２９】
個人用電子メールアプリケーション２０によって送受信された電子メールの場合、メールは、一般的に個人ユーザが加入する「インターネット」接続サービス業者によって提供される遠隔電子メールサーバによって回収及び配信されることになる点に注意すべきである。
このシステムの特徴及び機能の多くは、個々のユーザにかなりの便益をもたらすが、本システムは、取引情報が多くのユーザから収集されるマルチユーザ環境において作動する時に最大の利点を提供する。図２は、マルチユーザ環境における本システムの好ましい構成の概略図を示す。好ましいシステムは、データベース４２とオペレータコンソール４４とに接続された「中央管理サーバ」４０を含む。「中央管理サーバ」４０はまた、「アプリケーションインタフェース」５０及び５２と開放「アプリケーション・プログラム・インタフェース」５４とを含む「バック・オフィス・アプリケーション・プラグイン」と、「ゲートウェイ」構成要素６０、６２、及び、６４とに接続される。「ゲートウェイ」構成要素６２は、「インターネット・エクスプローラ・プラグイン」７０、「ネットスケープ・ナビゲータ・プラグイン」７２、及び、「ロータス・ノーツ・プラグイン」７６を備えた、１つ又はそれ以上のユーザのコンピュータ上に位置する「ユーザアプリケーション・プラグイン」に接続されているように図示されている。これらのプラグインは、これらのプラグインが一体化されているホストプログラムにおいて好ましいシステムの機能性をもたらすために使用される。４つの可能なホストプログラムである、「インターネット・エクスプローラ」、「ネットスケープ・ナビゲータ」、「マイクロソフト・アウトルック」、及び、「ロータス・ノーツ」が示されているが、好ましいシステムの機能性を実行するように挙動を変更することができることを条件として、「インターネット」に接続することができる任意の他のプログラムを使用してもよい。
【００３０】
「インターネット」１０への接続は、ユーザアプリケーション・プラグイン、及び、そのそれぞれのホストプログラムを通じて行われる。
「ゲートウェイ」構成要素７０、７２、及び、７４は、オプションであるが、各「ゲートウェイ」が情報を記憶及び転送すると共にシステム全体をスケーリングすることを可能にし、その結果、任意数のユーザを接続することを可能にするので好ましいものである。
複数のユーザマシン上の異なるアプリケーションに対する複数のアプリケーション「プラグイン」７０、７２、７４、及び、７６からの情報は、中央管理サーバ４０によって収集され、付随するデータベース４２に記憶される。
【００３１】
「バック・オフィス・アプリケーション・プラグイン」５０、５２、及び、５４により、本システムは、注文処理及び会計事務システムなどの第三者管理アプリケーションと接続することができる。これは、取引情報をこのようなシステムで自動的に入力及び処理することを可能にする。
「オペレータコンソール」４４は、運営管理用に、特に取引の承認用に設けられる。図２においては「中央管理サーバ」に直接取り付けられるように論理的に示されているが、このようなコンソールは、任意のネットワーク化されたコンピュータ上で実行することができる。電子メール又はウェブブラウザ・プラグインが特定の取引が承認を必要とすると判断した場合、要求が「中央管理サーバ」に送られ、許可されたオペレータによる承認待ちの順番に入れられる。
【００３２】
本システムの作動は、ポリシーデータによって制御され、ポリシーデータは、セキュリティに関する企業の規則、認定、及び、ユーザが行うことを許可されるアクション、並びに作動情報を記憶する。ポリシーデータは、「オペレータコンソール」４４、「バック・オフィス・アプリケーション・プラグイン」又は「ユーザ・アプリケーション・プラグイン」のいずれかによってアクセスされるように、「中央管理サーバ」上のポリシーファイルに記憶されることが好ましい。本システムの管理人又はネットワークのスーパバイザは、１つ又はそれ以上のポリシー又はポリシーファイルの設定を定義することができ、個々のユーザ又はユーザのグループを異なるポリシーに割り当てることができ、その結果、各ユーザのコンピュータで直接にパラメータ及びコントロールを設定する必要なく「インターネット」と対話するユーザの能力又はワークステーションの能力さえも制御する。例えば、会社の経理部のユーザを会計ポリシーに割り当てることができ、そのポリシーのその後のいかなる変更も、自動的にそのポリシーに割り当てられた全てのユーザの能力の変化をもたらす。
【００３３】
ポリシーデータを編集又は設定する能力は、ネットワーク・スーパバイザ又は他の許可された１人又は複数の者に制限されることが好ましい。これは、「オペレータコンソール」４４などのポリシーデータを編集するためのアクセスを有効化されたネットワークにおける１つ又はそれ以上のスーパバイザ・ワークステーションを指定することによって達成することができる。
ポリシーは、構造がツリー状であり、設定値をツリーの個々のポリシーノードまで強制的に落とすことができ、例えば、会社の資金繰りが万一問題になった場合に経営最高責任者が全ての購入に自分の承認を必要とするようにさせたいと希望した場合、世界規模の変更がたやすく行うことができることが好ましい。このようなポリシーを基本としたシステムにより、これまでの購入システム及び現行の「ｅＣｏｍｍｅｒｃｅ」購入環境の両方に固有の冗長性が大幅に軽減される。
【００３４】
ネットワークの各ユーザは、ポリシーデータの自分独自の表現を有することになる。メモリ内のスペースを節約するために、主ネットワークポリシーと異なる各ユーザのポリシーの枝及び葉のみが記憶されることが好ましい。ポリシーデータは、「中央管理サーバ」上にファイル形式で記憶されることが好ましいが、ポリシーデータの記憶がファイル形式のみに制限されることを意図したものではない。ポリシー設定の任意の他の表現又は暗号化を好ましいシステム内で採用してもよい。
ウェブブラウザ又は電子メールクライアントにおける本システムの実施について、ここで更に詳細に説明する。
【００３５】
ウェブブラウザでの好ましいシステムの使用
図３は、ウェブブラウザの簡素化された作動を示す。ウェブブラウザは、ユーザからの開始要求に応答して、又は、ユーザのコンピュータの起動ファイルから自動的に段階Ｓ１００で立ち上げられる。起動ファイルは、コンピュータが起動された時に、指定されたプログラムを自動的に実行するコマンドを含む。ウェブブラウザは、起動された後、所定の設定に従って一般的に「ホームページ」つまり閲覧用のデフォルトウェブページを要求する。これは、段階Ｓ１０２で示されている。
要求は、適切なウェブサーバ９０に送られ、「インターネット」上のその正確なアドレスは、通常は「ドメイン名サービス」によって判断される。ウェブサーバ９０は、次に、ウェブページを定義する適切なデータで応答し、この処理は、それぞれ段階Ｓ１０４及びＳ１０６として表されており、その結果、段階Ｓ１０８となる。
【００３６】
ウェブページを定義するデータは、「ＨＴＭＬ」スクリプト、及び、「ＸＭＬ」又は「ＡｃｔｉｖｅＸ」、及び、実行可能なプログラムを暗号化する「Ｊａｖａ（登録商標）ｓｃｒｉｐｔ」などの他の可能なデータ形式などから成る。ブラウザは、このデータを解釈し、段階Ｓ１１０で適宜表示及び／又は実行する。
次に、ブラウザは、一般的に段階１１２でユーザ入力を待つ。このような入力には、表示されたフィールドを埋める、ハイパーリンクをクリックする、又は、新しいウェブページの「ＵＲＬ」アドレスを入力するなどを挙げることができる。最終的には、このようなアクションにより、段階Ｓ１１４及び段階Ｓ１１６で更なる要求がウェブサーバ９０に送られることになる。要求は、単に別のウェブページアドレスであってもよいし、又は、表示されたフィールドにユーザによって入力されたものなどの追加データを含んでもよい。
【００３７】
図４は、サンプルウェブページの表示を示し、「ＧＵＩ」がユーザ名及び電子メールアドレスを受信するためにユーザに提示されている。図４を参照すれば、ユーザが提示された名前要求フィールドに自分の名前を「フレッド・スミス」として、電子メールアドレスを「ｆｓｍｉｔｈ＠ｘｙｚ．ｃｏｍ」として電子メールアドレスフィールドに入力したことが分るであろう。
ユーザが要求ウインドウ上に設けれられた「提出」ボタンをクリックすると、ユーザが入力した詳細は、ウェブサーバ９０に送られるコマンド内に含められる。このようなコマンドは、以下のようになるであろう。
ｈｔｔｐ：／／ｗｗｗ．ｓａｍｐｌｅ．ｃｏｍ／ｓａｍｐｌｅ２．ｈｔｍ？ＵｓｅｒＩＤ＝Ｆｒｅｄ＋Ｓｍｉｔｈ＆ｅｍａｉｌ＝ｆｓｍｉｔｈ＠ｘｙｚ．ｃｏｍ＆ｓｕｂｍｉｔ＝ｓｕｂｍｉｔ
以上から、ユーザ名が「ＵｓｅｒＩＤ」という変数の値としてコマンドに組み込まれ、電子メールアドレスは、「ｅｍａｉｌ」という変数の値として組み込まれることが分る。
【００３８】
コマンドは、段階Ｓ１１４において組み立てられ、段階１１６においてウェブサーバ９０に送信され、ユーザ名及び電子メールアドレス情報は、例えば、電子メールを通じて製品情報をユーザに送るため、又は、ウェブページにアクセスできるようにするために使用することができる。
ブラウザ・ヘルパー・オブジェクト（「ＢＨＯ」）の形の本発明の好ましい実施形態によって得られるプラグイン・モジュールは、標準的なウェブブラウザの機能性を高めるために更なる機能性を提供する。「ＢＨＯ」は、ウェブブラウザが様々なウェブサイト及びページと対話するようにユーザによって操作及び命令された時に発生するいくつかの重大なイベントに応答するように実行される。
【００３９】
「ＢＨＯ」は、ブラウザからウェブサーバに提出されたナビゲーション要求とデータとをモニタし、ユーザ独自のデータを特定するように実行される。これは、単に所定の単語及び語句があるか否かに関して発信データストリームを検索することによって行うことができる。図４に示した上述の場合において、２つの変数の定義「ＵｓｅｒＩＤ」及び「ｅｍａｉｌ」を検索し、それに続くデータを抽出して記憶することができる。代替的に、「ＢＨＯ」は「？」記号を検索することができ、「？」記号は、接続される「ＵＲＬ」アドレスの終わりを示し、それに続くものがデータであることを示す。「ＢＨＯ」はまた、接続されているウェブサイトから受信された着信データストリームをモニタすることができる。
【００４０】
「ＢＨＯ」はまた、ウェブブラウザ自体の作動をモニタするために実行することができる。ウェブブラウザは、それが作動する時に「ｅｖｅｎｔｓ」を生成し、共依存のソフトウエアモジュール又はオブジェクトに何か重要なことが発生したばかりであること、又は、アクションが完了したばかりであることを通知する。イベントの名称は、通常、それ自体が発生したばかりのことを説明するものであり、更に詳細にイベントを説明する追加データが一般的に利用可能である。「ＢＨＯ」は、これらのイベントを捕捉し、それらによってアクションを取るように実行される。
【００４１】
「ＢＨＯ」がそれに応答して実行される１つのこのようなイベントは、「ＢｅｆｏｒｅＮａｖｉｇａｔｅ２」と呼ばれ、これは、ユーザがウェブブラウザに新しいページにナビゲートするように要求した時にウェブブラウザが立ち上げる。イベントが発せられ、要求されたページがダウンロードされる前にそれを「ＢＨＯ」が認識することができ、これにより、「ＢＨＯ」は、ユーザがページを閲覧する前にいかなる関連アクションをも取ることができる。１つのこのようなアクションは、そのページ、及び、そのページに応答して提出された任意のデータをデータベースに記録することであろう。別のこのようなアクションは、要求されたページの「ＵＲＬ」をイベント内で特定し、そのページがダウンロードされるのを防止することであろう。
【００４２】
「ＢＨＯ」が捕捉する別のイベントは、「ＤｏｃｕｍｅｎｔＣｏｍｐｌｅｔｅ」イベントであり、これは、新しいページがウェブサイトからメモリに完全にダウンロードされた時にウェブブラウザによって立ち上げられる。そのページは、マイクロソフト製の「ドキュメント・オブジェクト・モデル（ＤＯＭ）」に準拠する「ドキュメント・オブジェクト」の形式に暗号化される。「ＤＯＭ」により、ページを構成するデータに総合的にアクセスすることができるようになり、その結果、「ＢＨＯ」は、自らに興味があるデータ項目を抽出することができる。例えば、「ＢＨＯ」は、そのページが「ｅＣｏｍｍｅｒｃｅ」取引の一部を成すか否かを判断するためにデータを「ＤＯＭ」に要求することができる。これは、「Ｒｅｃｅｉｐｔ」又は「Ａｃｃｏｕｎｔ Ｎｕｍｂｅｒ」などの用語がないかに関して「ＤＯＭ」内のオブジェクトを検索することによって行うことができる。
【００４３】
「ＢＨＯ」はまた、「ＤＯＭ」を使用して、ウェブページ上に要求されているデータのフィールド名又はフィールド形式を判断することができる。次に、ユーザによってこのようなフィールドに入力されたデータは、「ＤＯＭ」から抽出されて記憶されるか、又は、それに対してアクションを起こすことができる。フィールド名は、一般的に、何が記憶されているかを説明するものである。例えば、パスワードは、「ｐａｓｓｗｏｒｄ」というフィールドに保持されることが多く、それによってウェブページ上で検索することができる。クレジットカード番号は、同様の方法で検索することができる。通常、パスワードフィールドは、あらゆる入力されたデータがアスタリスクとして表示されるような形式のものである。これもまた、「ＤＯＭ」の解析から判断して、関連データを識別するのに使用することができる。
【００４４】
ユーザデータは、一般的にはウェブサイトからダウンロードされたウェブページには存在しないが、ユーザによって「ＨＴＭＬ」形式で入力されるであろう。通常、潜在的に機密性のユーザデータは、ユーザが「Ｓｕｂｍｉｔ」ボタンを選択した時にウェブサイトを通じてウェブサイトに送信される。この段階で、「ＢＨＯ」は、ウェブブラウザによって発せられた「Ｓｕｂｍｉｔ」イベントを捕捉し、「ＤＯＭ」にアクセスしてユーザデータを抽出し、必要であれば、そのデータが送信されるのを防止することができる。
【００４５】
機密リンク上での暗号化及び復号化は、図３においては、それぞれ点Ｃ及び点Ａ後に行われる。従って、「ＢＨＯ」は、暗号化前又は復号化後にそのデータを解析することができる。これは、「ＢＨＯ」がデータ自体の暗号化又は復号化を行う必要がないことから有利である。これは、現行の「ＵＲＬ」の始めにあるプロトコル識別子「ｈｔｔｐ」によって識別することができることから、リンクが機密性であるか否かを判断する能力に悪影響を与えることはない。送信コンテントの検査は、暗号化前又は復号化が行われた後に行われることが好ましい。
【００４６】
電子メールクライアントの作動に関する検討
図５を参照して、ここで一般的な電子メールクライアントの作動、及び、電子メールクライアントにおける好ましい実施形態の実行について説明する。
図５は、電子メールクライアントの簡素化された作動を示す。「受信」及び「送信」作動は、一般的に独立して作動し、これらの作動は、それぞれ図５の反対側に別個に示されており、段階Ｓ１２０及び段階Ｓ１３０から始まる。
【００４７】
電子メールクライアントの「ｒｅｃｅｉｖｅ ｍｅｓｓａｇｅ」作動は、段階Ｓ１２０で開始される。これは、ユーザにいかなる新しい受信メッセージをも知らせておくために所定の間隔で自動的に行うことができ、又は、ユーザが手作業で「ｒｅｃｅｉｖｅ ｍｅｓｓａｇｅ」アイコンを選択することに応答して行うことができる。これを開始する作動により、電子メールクライアントは、電子メールサーバ９５をポーリングして、任意の新しいメッセージをユーザのコンピュータにダウンロードする。段階Ｓ１２２において、電子メールメッセージは、電子メールクライアントによって受信される。一般的に、新しいメッセージは、受信された時に「Ｉｎｂｏｘ」に追加され、受信されたメッセージヘッダ（例えば、送信者名、日付、及び、表題）がリストに配置される。次に、ユーザは、メッセージ全体を読むためにリスト内の適切な項目をクリックし、メッセージをコンピュータ画面に表示させる。段階Ｓ１２４で、電子メールメッセージが表示される。
【００４８】
発信電子メールの場合、ユーザは、「ｃｏｍｐｏｓｅ ｅ−ｍａｉｌ」オプションを段階Ｓ１３０として選択する。これに応えて、電子メールクライアントは、テキストエディタを含むインタフェースを供給し、ユーザは、メッセージ本文のテキストと、宛先アドレス及び件名などの他の情報とを入力することができる。段階Ｓ１３２で、ユーザはメッセージを構成し、その後に「ｓｅｎｄ ｃｏｍｍａｎｄ」を発するために電子メールクライアントによって供給されたアイコン又はメニューオプションを選択することによりメッセージを送ることを選ぶ。段階Ｓ１３４で、電子メールは、受信者に送信されるように電子メールサーバに送られる。電子メールクライアントによって暗号化が適用される場合、それは、段階Ｓ１３４で送信前に適用される。
【００４９】
好ましい実施形態において、付加的な機能性が、プラグイン・モジュールを通じて電子メールクライアントに対して与えられる。電子メールクライアントは、「マイクロソフト・エクスチェンジ」クライアント又は「マイクロソフト・アウトルック」クライアントなどのマイクロソフトによって供給されたもののうちの１つであり、プラグイン・モジュールは、「エクスチェンジ」クライアント・エクステンションとして暗号化されることが好ましい。これらについては、上述のシャロン・ロイド著の文書「マイクロソフト・アウトルック及びエクスチェンジ・クライアント・エクステンション」に説明されている。
【００５０】
「エクスチェンジ・クライアント・エクステンション」は、「マイクロソフト・ウインドウズ（登録商標）・コンポーネント・オブジェクト・モデル（ＣＯＭ）」に準拠し、「エクスチェンジ ＩＥｘｃｈＥｘｔ」インタフェースを利用するコンポーネント・オブジェクトである。このインタフェースにより、「エクスチェンジ」の電子メールクライアントの作動を変更するためのいくつかの追加インタフェースが得られ、例えば、既存のクライアント挙動を交換又は変更し、新しいコマンドをクライアントのメニューに追加することを可能にする「ＩＥｘｃｈＥｘｔＣｏｍｍａｎｄｓ」インタフェース、及び、新しいメッセージの到着、読み取り、書き込み、メッセージ送信、及び、添付ファイルの読取り及び書込みなどのクライアント「ｅｖｅｎｔ」を処理するように習慣的な行動を実行させる「ＩＥｘｃｈＥｘｔＥｖｅｎｔｓ」インタフェースなどがある。また、「ＩＥｘｃｈＥｘｔＭｅｓｓａｇｅＥｖｅｎｔｓ」、「ＩＥｘｃｈＥｘｔＳｅｓｓｉｏｎＥｖｅｎｔｓ」、及び、「ＩＥｘｃｈＥｘｔＡｔｔａｃｈｍｅｎｔＥｖｅｎｔｓ」インタフェースが設けられており、インタフェース名の各々が暗示するより特定的なタスクに対して更なる機能性を提供する。
【００５１】
好ましい実施形態において、プラグイン・モジュールを形成する「エクスチェンジ・クライアント・エクステンション」は、種々の作業を行ってアクションを完了した時にクライアントプログラムによって立ち上げられるクライアント「ｅｖｅｎｔｓ」に応答するように実行される。当該の「ｅｖｅｎｔｓ」は、上述の「ＣＯＭ」インタフェースによって供給される。従って、プラグイン・モジュールによる電子メールクライアントのモニタリングは、「ＢＨＯ」プラグイン・モジュールがウェブブラウザの作動をモニタする方法と類似のものであることが分る。
【００５２】
電子メールクライアント・プラグイン・モジュールは、例えば、新しいメッセージがその下にあるメール配信システムから受信された時、かつ、ユーザが目にすることができる前に立ち上げられる「ＯｎＤｅｌｉｖｅｒｙ」イベントに応答して実行される。「ＯｎＤｅｌｉｖｅｒｙ」イベントは、ダウンロードされてメモリに保持された電子メールメッセージの異なる部分にアクセスするための情報を含む。メッセージヘッダ、メッセージ本文、及び、いかなるメッセージ添付ファイルも、「メール・アプリケーション・プログラム・インタフェース（ＭＡＰＩ）」呼出しを通じて個別にアクセスすることができるメッセージオブジェクトのプロパティとしてメモリに暗号化される。
【００５３】
「ＯｎＤｅｌｉｖｅｒｙ」イベントの一部として供給される情報を通じて、プラグイン・モジュールは、メッセージヘッダにアクセスして、例えば送信者の身元を抽出する。更に、プラグイン・モジュールは、「ＭＡＰＩ」呼出しから得られた情報を利用して、キーワード又は関連データがないかどうか受信されたメッセージの本文を走査することができる。それは、「ｒｅｃｅｉｐｔ」又は「ａｃｃｏｕｎｔ ｎｕｍｂｅｒ」などの重要な単語を特定することによって「ｅＣｏｍｍｅｒｃｅ」取引の証拠を検索することができる。次に、メッセージは、監査を目的として記憶することができる。未承認送信者又は有害なメッセージコンテントの場合、そのメッセージを見られることなく削除することができる。
【００５４】
従って、受信された電子メールの解析は、図５においてはポイントＡでユーザによる閲覧の前に行われる。電子メールは、好ましくは「Ｉｎｂｏｘ」に置かれる前でさえも検査される。メッセージが「Ｉｎｂｏｘ」に置かれる前に自動的に復号化されない場合、例えばユーザが復号化キーを入力することが必要な場合には、メッセージは、復号化直後であってしかも閲覧前に検索される。「デジタル証明書」は、電子メールの添付ファイルとして含めてもよく、閲覧前にたやすく検査することができ、確認などの任意の適切なアクションを行うことを可能にする。
【００５５】
プラグイン・モジュールがそれに応答して実行される別の重要なクライアントイベントは、ユーザが「ｓｅｎｄ ｃｏｍｍａｎｄ」を選択し、電子メールクライアントに新しい電子メールメッセージをメール配信システムに送信するように要求した時に立ち上げられる「ＯｎＷｒｉｔｅＣｏｍｐｌｅｔｅ」イベントである。このイベントは、図５のポイントＢで、送信前及びいかなる暗号化も行われない前に立ち上げられる。送信されるべき新しいメッセージは、「ＭＡＰＩ」呼出しによりアクセスすることができるオブジェクトとしてメモリに同様に記憶される。プラグイン・モジュールは、「ＭＡＰＩ」呼出しを使用してクレジットカード番号などの機密性データに関して発信電子メールのコンテントを走査し、結果的にメッセージを記録させるか、又は、阻止させることさえ可能である。
【００５６】
プラグイン・モジュールの作動
ウェブブラウザ、及び、電子メールクライアント・プラグイン・モジュールの好ましい実行については、上述の図３及び図５を参照して既に説明している。次に、プラグイン・モジュールにより供給される機能性について、詳細に図６から図１８までを参照しながら説明する。
ユーザ名、パスワード、及び、他の情報の識別及び記録
好ましいシステムは、ユーザのワークステーションへの送受信に含まれるデータ、特に、ウェブサイトページ、ファイル転送プロトコル（ＦＴＰ）サイト、及び、「インターネット」上の他のこのようなサイトにアクセスするためにユーザによって入力されたユーザ名及びパスワードを自動的に識別、収集、及び、記憶する手段を提供する。
【００５７】
現時点でパスワードを記録する機能をもたらすシステムは、現時点では、ユーザが「ＧＵＩ」上に設けられた「ｒｅｍｅｍｂｅｒ ｐａｓｓｗｏｒｄ」オプションをクリックした時にのみそれを行う。パスワードは、例えば、ユーザが起動時にユーザ名及びパスワードを入力することによってそのコンピュータで確認された時にのみ開かれるユーザのコンピュータ上の保護されたローカルファイルに保存される。「ｒｅｍｅｍｂｅｒ ｐａｓｓｗｏｒｄ」オプションは、パスワードが必要とされる度にユーザが入力しなくても済むように、次にユーザが接続した時に本システムがユーザのパスワードを覚えておくようにさせてパスワードフィールドにそのパスワードを予め記入する。ローカルに記憶されるパスワードファイルの欠点は、ユーザが別のコンピュータに移動した時に、記憶されたパスワードファイルにアクセスすることができないのでパスワードを自分で再入力しなければならないということである。
【００５８】
好ましいシステムは、ユーザからの命令が必要なくパスワードを自動的に識別し、識別されたパスワード及びユーザ名をデータリポジトリーに記憶する。これは、中央データベース４２であることが好ましい。これにより、任意のユーザのパスワードがユーザがログオンする端末に関係なく思い出されるが、端末がデータベースにアクセスできることが条件である。
あらゆる識別されたパスワード及びユーザ名は、最初のウェブサイト上で記憶されたフィールド名、及び、送信先かつ使用された場所である「インターネット」サイトのアドレスと共にデータベースに記憶される。サイト情報は、パスワード及びユーザ名情報をそのサイトに提出する「ＨＴＴＰ」要求、及び、メモリに保持されたウェブページの表現に含まれているので簡単に検索することができる。
【００５９】
セキュリティのために、データベースに記憶された情報は、ネットワーク・スーパバイザ、システム管理者、又は、会社取締役などの選ばれた数の人々のみがアクセスすることができるように暗号化されることが好ましい。彼らは、ネットワーク内のワークステーションを通じて、身元確認を行うためにユーザ名及びパスワードを入力することにより、又は、オペレートコンソール４４などのスーパバイザ・ワークステーションを通じてデータベースにアクセスすることができる。
【００６０】
アドレス詳細と共に為されるユーザ名及びパスワードの記憶により、オンライン機能を使用する会社にとって重要な利点が呈示される。既存の技術を用いると、ユーザが保護ファイルへのアクセスを防止するための自分の確認用パスワードを忘れたり、又は、パスワードを開示せずに退職した場合に「インターネット」サービスにアクセスすることができない。同様の状況は、保護ファイルが損傷、削除、又は、他の方法で紛失した場合に発生する。その時は、紛失したパスワードを交換又は発見するために、各「インターネット」サービスに接続しなければならず、これは、失われたアクセス及び管理時間の両方の点で費用が掛かる可能性がある。好ましいシステムを用いると、パスワード情報は、中央データベースから発見することができ、そのためにウェブサイトへのアクセスは失われない。
【００６１】
図６は、ウェブサーバに送信されるべきデータからユーザ名及びパスワード情報を抽出するために実行されたプラグイン・モジュールの作動を概略的に示すフローチャートである。段階Ｓ１５０において、プラグイン・モジュールが開始され、ブラウザからウェブサーバにまさに送信されようとしているデータを構文解析する。これは、図３で示した処理のポイント「Ｃ」で発生する。次に、制御は段階Ｓ１５２に移り、プラグイン・モジュールは、送信されるべきデータがユーザ名又はパスワード情報を含むか否かを判断する。
【００６２】
パスワード及びユーザ名は、図３、図４、及び、図５を参照して説明した方法、つまり、提出されたコマンド内のフィールド名を識別することにより、又は、「ＣＯＭ」を使用して例えばフィールド名、フィールド形式、又は、ウェブページ上のデータを識別するのに使用された表示方法を検索することにより識別することができる。また、パスワード及びユーザ名は、「ワールド・ワイド・ウェブ」上の遠隔サーバ又はプロバイダによるか、又は、電子メールメッセージのコンテントを走査することによってさえも呈示されるウェブページの「ＨＴＭＬ」、ポップアップウインドウ、又は、「ＧＵＩ」（グラフィッカル・ユーザ・インタフェース）から検索することができる。
【００６３】
ウェブページのコマンド又は「ＤＯＭ」内のパスワード及びユーザ名をそのフィールド名内で識別することは、「パスワード」又は「ユーザ名」などの明白なラベルでその目的を説明するフィールド名に依存する。フィールド名自体が意味を持たない場合、送信されるデータの性質は、「ストリング」又は「整数」などであるデータのフィールド形式、又は、そのデータを入力するのに使用された表示方法から推論することができる。パスワードを受信するように意図されるフィールドは、「ＤＯＭ」内の「パスワード」フィールド形式を検索することにより、その表現内で識別することができる。パスワードデータの入力先であるウェブページ上のテキストボックスでは、一般的に各文字入力はアスタリスクとして表示され、このプロパティを「ＤＯＭ」から判断することができ、テキストボックスへ入力されたデータが他のインジケータがない場合でさえもパスワードであると推論するのに使用することができる。パスワードは、アスタリスクのストリングとして表示されるが、メモリ内の表現は、それでも尚ユーザによって入力された文字情報を含む。次に、パスワードは、単に入力をフィールドから抽出することによって検索することができる。
【００６４】
代替的に、パスワード及びユーザ名は、「ｒｅｍｅｍｂｅｒ ｐａｓｓｗｏｒｄ」オプションがユーザによって選択されている時にマイクロソフト製の「インターネット・エクスプローラ」などの他のプログラムによって記憶されたものを参照することにより識別することができる。このようなパスワードは、ユーザのコンピュータ上のローカル保護ファイルに記憶される。このファイルは、ユーザがコンピュータ上に確認された時に「解錠」され、従って、好ましいシステムのブラウザ・プラグイン・モジュールによりパスワード及びユーザ名情報を取得するためにアクセスすることができる。
【００６５】
プラグイン・モジュールが送信されるべきデータにおいてユーザ名又はパスワードを検出しなかった場合、制御は段階Ｓ１５８に移り、この時点でモジュールはフローから出て、制御は図３のポイント「Ｃ」に戻される。次に、ブラウザは、データをウェブサーバに送信することができる。しかし、ユーザ名又はパスワードが段階Ｓ１５２で検出された場合、制御は段階Ｓ１５４に移り、識別されたユーザ名又はパスワード、及び、データの送信先であるウェブページの「ＵＲＬ」又は他の識別子の値が抽出される。次に、制御は段階Ｓ１５６に移り、これらの値、及び、「ＵＲＬ」又は他の識別子は、好ましいシステムデータベース４２に記憶される。記憶が行われると、制御は次に段階Ｓ１５８に移り、モジュールはフローから出て、制御は図３のポイント「Ｃ」に戻される。次に、モジュールは、データをウェブサーバに送信することができる。
【００６６】
好ましい実施形態は、パスワード又はユーザ名の記憶によって直ちに得られる利点のために例示的に使用されたそれらの記憶のみに限定される必要はない。他の形式のデータ、特にクレジットカード情報及び「デジタル証明書」などの「ｅＣｏｍｍｅｒｃｅ」取引に関係するものもまた、データベース又は記録が得られるように有益に抽出及び記憶することができる。情報を送信から抽出するためのシステムもまた、電子メールシステムに適用することができる。
【００６７】
この情報は、上述の方法、つまり「ＤＯＭ」を通じて又は電子メールコンテントの「ＣＯＭ」表現への「ＭＡＰＩ」呼出しを通じて抽出することができ、又は、ウェブページが符号化される言語から抽出することができる。ウェブページは、一般的に、「ハイパーテキスト・マークアップ言語（ＨＴＭＬ）」、つまり、従来のテキストマッチング技術を使用して公知のキーワード又はインジケータがないかどうか検索することができる人間読取り可能テキストベースの言語に符号化される。好ましい実施形態において、データの記録は、ウェブページが後で検索して閲覧することができるように、パスワード及びユーザ名情報のみを記録する段階、閲覧されているウェブページ又は電子メールアカウントの「ＵＲＬ」を記録する段階、ウェブページのフィールドに提出された任意のデータを記録する段階、及び、ウェブページの「ＨＴＭＬ」を記録する段階を伴うであろう。
好ましいシステムによってもたらされるプラグイン・モジュールは、ポリシーデータに関連して作動し、ポリシーデータは、例えば、ファイル、データベース、又は、ソフトウエアコードに記録することができる。ポリシーデータにより、好ましいシステムのユーザは、各プラグイン・モジュールの作動を命令し、それによってプラグイン・モジュールの機能性を制御することができる。
【００６８】
図７に示すポリシーデータのサンプル表現は、ユーザがプラグイン・モジュールの作動を制御して、他の形式のデータと共にパスワード及びユーザ名情報を記録する方法を示す。
ポリシーデータのツリー状の構造は、図７に明確に示されており、図７は、「ＡＲｅｃｏｒｄｉｎｇ＠」と題したポリシーデータの１つの主なブランチのみを示す。「Ｒｅｃｏｒｄｉｎｇ」ブランチは、ウェブブラウザ・イン・モジュール、及び、電子メールクライアント・プラグイン・モジュールの作動の命令をそれぞれ含む「ＡＢｒｏｗｓｅｒ＠」、及び、「ＡＥｍａｉｌ＠」という２つのサブブランチに分かれる。
【００６９】
ブラウザブランチは、「ＡＤａｔａＴｏＲｅｃｏｒｄ＠」、「ＡＷｈｅｎＴｏＳｔａｒｔＲｅｃｏｒｄｉｎｇ＠」、及び、「ＡＷｈｅｎＴｏＳｔｏｐＲｅｃｏｒｄｉｎｇ＠」という３つのサブブランチを含む。「ＤａｔａＴｏＲｅｃｏｒｄ」ブランチは、ユーザのワークステーション及びウェブサーバに対する送受信から抽出されるデータの形式を指定する。４つの形式のデータは図に示されており、これらは、閲覧されているウェブページ、閲覧されているウェブページの「ＨＴＭＬ」、ウェブページ上に設けられたフィールドにユーザによって入力され、ウェブサイトに提出されたデータ、及び、ユーザによって入力された任意のパスワード及びユーザ名である。これらは、「Ａ「ＵＲＬ」＠」、「ＡＨＴＭＬ＠」、「ＡＳｕｂｍｉｔｔｅｄＦｉｅｌｄｓ＠」、及び、「ＡＰａｓｓｗｏｒｄｓ＠」と題された「ＤａｔａＴｏＲｅｃｏｒｄ」ブランチの４つの異なるサブブランチ上で示されている。それらの各サブブランチ上のＹＥＳ／ＮＯオプションは、表示されたデータが記録されるべきか否かを指定する。
【００７０】
「ＷｈｅｎＴｏＳｔａｒｔＲｅｃｏｒｄｉｎｇ＠」ブランチは、「ＤａｔａＴｏＲｅｃｏｒｄ＠」ブランチにおいて指定されたデータが記録されるポイントを指定するいくつかの条件を定める。この例において５つの条件が示されており、各々は個別のブランチで定められ、それぞれ、「ＡＷｈｅｎＢｒｏｗｓｅｒＩｓＯｐｅｎｅｄ＠」、「ＡＩｆＣｒｅｄｉｔＣａｒｄＲｅｃｅｉｖｅｄ＠」、「ＡＰａｓｓｗａｒｄＳｕｂｍｉｔｔｅｄ＠」、及び、「ＡＩｆＫｅｙｗｏｒｄｓＳｅｎｔ＠」と題されている。いつ記録を開始すべきかを判断するためにこれらの条件を使用すべきであるか否かは、各ブランチ上でＹＥＳ／ＮＯマーカーによって表示されている。
【００７１】
同様に、「ＷｈｅｎＴｏＳｔｏｐＲｅｃｏｒｄｉｎｇ＠」ブランチは、「ＤａｔａＴｏＲｅｃｏｒｄ＠」ブランチにおいて指定されたデータの記録を停止すべきポイントを判断するために使用することができる３つの条件を示している。これらの条件は、「ＡＷｈｅｎＵｓｅｒＣｌｏｓｅｓＢｒｏｗｓｅｒ＠」、「ＡＷｈｅｎＵｓｅｒＣｈａｎｇｅｓＳｉｔｅ＠」、及び、「ＡＷｈｅｎＵｓｅｒＣｈａｎｇｅｓＰａｇｅ＠」である。各条件及び記録されるデータ形式に対するＹＥＳ／ＮＯ状態は、プラグイン・モジュールの作動を制御するために、好ましいシステムのユーザが簡単に設定することができる。
【００７２】
ポリシーデータの電子メールブランチは、「ＤａｔａＴｏＲｅｃｏｒｄ」ブランチ、及び、「ＷｈｅｎＴｏＲｅｃｏｒｄ」ブランチに分けられている。これらのブランチの各々は、「Ｓｅｎｔ Ｍａｉｌ」及び「Ｒｅｃｅｉｖｅｄ Ｍａｉｌ」を処理するブランチに細分化されている。記録することができるデータの形式は、「ＤａｔａＴｏＲｅｃｏｒｄ」ブランチに定められ、送られたメールについては、メッセージテキスト及びメッセージの任意の添付物とすることができ、デジタル署名で署名されたメッセージの場合には、署名を伴う「デジタル証明書」のコピーとすることができる。「Ｓｅｎｔ Ｍａｉｌ」及び「Ｒｅｃｅｉｖｅｄ Ｍａｉｌ」を記録するための条件は、「ＷｈｅｎＴｏＲｅｃｏｒｄ」ブランチに定められており、送られたか又は受信されたメール内のクレジットカード番号、キーワード、又は、「デジタル証明書」の識別に基づくものとすることができる。
【００７３】
説明したツリー状の構造は、データを容易にまとめて参照することができるのでポリシーデータの好ましい形式である。また、この構造により、異なるポリシーを受信するために異なるユーザをツリーの異なるブランチに割り当てることができる。ツリー状の構造は好ましいものであるが、他の配置も可能とすることができる。この図で示されているブランチは、単に例示的であるように意図されている。
【００７４】
クレジットカード番号の識別
好ましいシステムはまた、一般的に１４桁と１６桁の間の長さの数値桁のストリングを検索することにより、ウェブサーバ又は電子メールクライアントに送信されるデータ内の「クレジットカード」番号又は他のアカウント情報を検索する。次に、その桁のストリングがカード番号を確認するためにクレジットカード会社によって世界的に使用される試験の１つを満足するか否かが判断される。クレジットカード番号が送信に見つけられた場合、好ましいシステムは、承認を得るために送信を第三者に問い合わせる、クレジットカード番号が会社に属する場合には送信を安全保護するためにより高度な暗号化を再交渉する、又は、送信が全く行われないようにするなどの、ポリシーファイルの設定によるいくつかのアクションを取ることができる。
【００７５】
クレジットカード番号を識別する最も一般的な試験は、「ＡＮＳＩ規格Ｘ４．１３」に定義されており、一般的に「ＬＵＨＮ」又は「Ｍｏｄ １０」として知られている。
「Ｌｕｈｎ」公式は、検査桁を生成するためにクレジットカード番号に適用され、従って、クレジットカードを確認するためにも使用することができ、その場合は、検査桁はその公式の一部として考えられる。「Ｌｕｈｎ」公式を使用してクレジットカード番号を確認するためには、番号の右側から始まって左側に移動する１桁目以降の２桁目ごとの値に２を掛け、次に、桁の全て、つまり２を掛けた桁とそうでない桁の両方を合計し、２倍した結果として１０に等しいか又はそれ以上になったいかなる桁の数値も、例えば「１０」が「１＋０＝１」と計算され、「１８」が「１＋８＝９」と計算されるように、それらが２つの単一の桁値であるかのように加え合わされる。足し算の合計が１０で割り切れる場合、そのクレジットカードは、有効なクレジットカード番号である。
【００７６】
図８は、まさに送信されようとしているデータにおいて、上述の「Ｌｕｈｎ」公式を使用してクレジットカード番号を検出するプラグイン・モジュールの作動を示すフローチャートである。クレジットカード番号が識別された場合、プラグイン・モジュールは、更なるポリシーベースの検査を実行し、その結果に基づいて、クレジットカード番号を含むデータを送信するか、又は、送信を防止するかを決めることができる。
【００７７】
このモジュールは、段階Ｓ１６０で作動を開始するが、この段階は、ブラウザ実行の場合には図３に示した処理のポイント「Ｃ」、又は、電子メールクライアント実行の場合には図５に示した処理の「Ｂ」に続くものである。制御は、段階１６０から段階Ｓ１６２に移り、段階Ｓ１６２において、モジュールは、ウェブサーバ又は電子メールサービスにまさに送信されようとしているデータを走査し、クレジットカード番号の可能性が高い桁の第１ストリングをそのデータから抽出する。
これは、特定の桁数の長さに亘る桁のストリングの送信を含むデータを走査することによって達成される。クレジットカード番号は、通常は長さが１２桁を上回る桁で構成され、通常は１６桁を上回らない。従って、この範囲の桁のいかなるストリングも可能なクレジットカード番号として識別することができる。
【００７８】
抽出段階Ｓ１６２の後、制御は判断段階Ｓ１６４に移り、そこで、ファイル検査のルーチン終了が為される。データが候補のクレジットカード番号を含まず、いずれかの第１候補の番号が見つかる前にファイル検査の終了になった場合、段階Ｓ１６４で、制御は段階Ｓ１７８に移り、データの送信は、更なる検査を行うことなく続行することができる。次に、モジュールは段階Ｓ１８０でフローから出る。制御は、図３に示すウェブブラウザの作動においてはポイント「Ｃ」から、又は、図５に示す電子メールクライアント作動においてはポイントＢから再開する。
【００７９】
段階Ｓ１６２において、第１の潜在的なクレジットカード番号がデータ内で見つかった場合、抽出されてメモリに記憶される。ファイルの終了にはならないが、制御は、段階１６２から段階Ｓ１６４へ、次にＳ１６６に移り、記憶された候補番号の「ｃｈｅｃｋｓｕｍ」が「Ｌｕｈｎ」公式を使用して計算される。次に、制御は判断段階Ｓ１６８に移り、「ｃｈｅｃｋｓｕｍ」が問い合わせされる。
「ｃｈｅｃｋｓｕｍ」の結果として候補番号が有効クレジットカード番号でないと分った場合、制御は段階Ｓ１６２に戻り、次の潜在的なクレジットカード番号がデータから抽出される。第２のクレジットカード番号が見つからなかった場合、ファイルの終了となり、制御は、送信の進行が許される段階Ｓ１７８に移り、次に、モジュールがフローから出る段階Ｓ１８０に移る。
【００８０】
しかし、「ｃｈｅｃｋｓｕｍ」の結果として候補番号が有効クレジットカード番号であると分った場合、制御は判断段階Ｓ１７０に移り、取るべき適切なアクションがあるかどうかポリシーデータの設定に問い合わせる。そのアクションは、番号自体、その番号を送信するユーザの身元、及び、送信先のアドレスなどの要素から判断することができる。ポリシーデータは、例えば、クレジットカードを送信すべきではないとか、又は、送信が続行される前により高い暗号化強度が必要であると指定することができるであろう。
【００８１】
このポリシー検査段階により、取引を行うユーザよりも高いレベルでクレジットカード取引を制御することができる。従って、金融面の決定は、迅速かつ簡単に実行することができ、モニタリングを必要とせずに自動的に実施することができる。組織は、例えば、その組織のアカウント上でクレジットカード取引を行う能力を特定の許可された人々に制限したり、又は、特定のアカウント上の取引を全て制限したいと思う場合がある。
【００８２】
段階Ｓ１７０において、クレジットカード番号及び取引の他の詳細がポリシーファイル内の設定と比較され、送信が行われてもよいか否かが判断される。ポリシー検査を参照して何らかの理由でそのクレジットカード番号は送信されるべきではないと判断された場合、制御は段階Ｓ１７２に移り、そのデータの送信が停止され、次に段階Ｓ１７４に移り、モジュールはフローから出る。この時点で、本システムは、ユーザに要求が否定されたことをポップアップメッセージボックスによって通知することができる。次に、制御は、ウェブブラウザの場合には図３のポイントＡに、又は、電子メールクライアントの場合には図５の段階Ｓ１３２の「ｃｏｍｐｏｓｅ ｍａｉｌ」に戻る。
【００８３】
段階Ｓ１７２において、クレジットカード番号を送信することができると判断された場合、制御は段階Ｓ１７６に移り、データの送信が発生し、次に段階Ｓ１８０に移り、モジュールはフローから出る。この場合、制御は、ウェブブラウザ作動においてはポイントＣから、又は、電子メールクライアント作動においては図５に示すポイントＢから再開する。
クレジットカード番号は、単に送信のコンテントを走査することにより段階Ｓ１６２において識別されるとは限らない。ウェブブラウザでの実施において、クレジットカード番号は、例えば送信される任意の変数のフィールド名を参照することにより、又は、メモリ内のウェブページの表現からも直接識別することができる。パスワードの識別に関する上述の検討は、これをより詳細に説明している。
【００８４】
好ましいシステムはまた、アカウント番号などの他の関連する金融上の詳細がないかどうか発信される送信を検索するように構成することができる。資金を預金することができる会社アカウント番号は、別ファイルに記憶することができる。次に、説明した方法により、発信データから任意の可能性の高い文字又は桁のストリングを抽出してアカウントファイル内の入力コンテントと比較し、それが有効アカウント番号であるか否かを判断することができる。次に、上述の方法で取引を続行又は拒絶することができるであろう。クレジットカード番号を参照したが、デビットカード番号のような支払いを行うためのあらゆる形式のカード番号もまた使用し得ることが認められるであろう。
また、クレジットカード番号の識別を送信されるデータに関して説明したが、同様の技術を使用して、受信する伝送からクレジットカード番号を識別して抽出することができることが認められるであろう。
【００８５】
確認及び認証サポート
オンライン取引では、一般的に、ユーザが自分で言うその本人であること、及び、注文した品物の代金を支払うことができるということの何らの形の認証が必要とされる。これらの要件は、通常、売り手が後でカード発行人に確認することができるクレジットカード番号とカード保持者の住所とを購入者が業者に供給することによって満足される。しかし、「デジタル証明書」がユーザによって電子取引に添付されることが増加傾向にあり、デジタル署名と共に「デジタル証明書」は、受信者が送信者という名前の人物から発せられた取引を確認することを可能にする。「Ｉｎｄｅｎｔｒｕｓ」のようないくつかの発行機関からの「デジタル証明書」はまた、その保持者が所定の金額を支払うという自分の責任を全うすることの保証として機能することができる。これらの証明書は、オンラインで取引をする時に有用である。
【００８６】
「デジタル証明書」は、情報を送信する時又は取引を行う時に個人の身元を確立する普及している手段である。それらはまた、いかなる送信情報又は取引詳細の受信者に対しても、それらの詳細やその情報が無許可の第三者によって途中で改竄されていないという保証を提供する。
「デジタル証明書」は、ベリサイン・インコーポレーテッドのような独立した「証明書発行機関」によって個人、組織、又は、会社に発行される。組織はまた、別の「証明書発行機関」によって発行された「ルート」証明書から得ることができるか又は得ることができない独自の「デジタル証明書」を発行する独自の「証明書発行機関」として機能することができる。「デジタル証明書」には、一般的に、保持者名、一連番号、満了日、証明書保持者の一般キーの写し、及び、証明書発行機関のデジタル署名が含まれる。また、個人キーが証明書保持者に発行され、保持者は、それをだれにも開示してはならない
【００８７】
証明書は、各保持者独自のものであり、保持者がもはや実行可能でない場合は発行人により取り消すことができ、代替的に、保持者は、自分の個人キーが危うくなった場合にはそれを取り消すように頼むことができる。
一般キー及び個人キーは、いずれも、メッセージを暗号化又は復号化をするために協働して使用することができる。メッセージを個人キーで復号化した後には証明書保持者によってのみ読むことができるように、誰でも証明書保持者の一般キーを使用してメッセージを暗号化することができる。
【００８８】
また、メッセージには、メッセージのコンテントをハッシュという数学的要約に変換するソフトウエアを使用してデジタル署名することができる。その後、ハッシュは、送信者の個人キーを使用して暗号化される。その後、ハッシュは、送信されているメッセージのデジタル署名として使用することができる。元のメッセージ、デジタル署名、及び、送信者の「デジタル証明書」は、全て、受信者に送信され、受信者は、その後、自分が受信したメッセージが不備なく元の形から改竄されていないことを確認するために、受信されたメッセージのハッシュを生成することができる。受信されたハッシュが、保持者の一般キーで復号化された後に受信者によって生成されたハッシュと合った場合は、受信者は、そのメッセージは証明書の発行先であるその人物から送られたものであり、メッセージは元の形から途中で変更されていないと信用することができる。従って、「デジタル証明書」は、「インターネット」上で取引を行う会社にはかなり重要であり、ますます重要になっている。
【００８９】
オンライン業者が、顧客の身元を確認するために「デジタル証明書」を利用する場合、証明書は任意の取引が許可される前にまだ有効であることを発行人に対して検査することが必要である。このような検査は、バリサート・インコーポレーテッドなどの独立した確認サービスを使用してオンラインで行うことができる。通常、このようなサービスに対しては手数料が請求される。
【００９０】
おそらく、組織の従業員は、各々単一のクライアントから電子メールを受信し、各電子メールは、個別の機会に「デジタル証明書」で証明されるであろう。現在、自分たち自身で手作業で共有しない限り、１人の従業員によって受信された証明書に関する情報が別の従業員と共有される方法はなく、その結果、個々の従業員は、同一の証明書を受信する度に確認するように要請するであろう。しかし、証明書が発行人によって取り消されると、二度と回復されず、それで、既に取り消された証明書に費やされた確認手数料は不要であることからこれは無駄である。更に、受信者は、以前に確認された証明書を再検査すべきか否かに関して業務上の判断をしたいと思う可能性がある。例えば、１００万ドル分の品物のデジタル署名された注文がある日受信されて、証明書は問題なく確認され、翌日に５０ドルの別の注文が受信されて同一の証明書で署名された場合、その組織は、２番目の検査は不要であり、それによって確認料金の節約になると考えるであろう。
【００９１】
好ましいシステムは、受信された「デジタル証明書」、最終検査時の証明書の状態、並びに、可能な場合には、クライアント、金額、日付、及び、品物のような取引情報に関する情報を記録する手段を提供する。この情報は、本システムの全てのユーザがアクセスすることができる中央データベースに記憶される。また、好ましいシステムは、記憶された情報を使用して確認検査が望ましいか否かを判断し、「デジタル証明書」の状態により取引を受理又は拒否する手段を提供する。従って、本システムのユーザは、真偽を自分で立証する必要がなく、取引を受信して検討することができる。
【００９２】
図９は、会社従業員によって受信された取引から「デジタル証明書」を抽出し、その確認状態、及び、日付、金額、及び、品物などの任意の関連取引の詳細と共に、それらをデータベース内に記録するために実行される好ましいシステムのプラグイン・モジュールの作動を示す。モジュールは、まず、証明書が明らかに無効であるか否か、また、メッセージは正しくその証明書によって署名されているかを判断するために検査する。証明書は、例えば、満了日が過ぎている場合、又は、無効な「捺印」を含む場合は明らかに無効である。このような捺印は、例えば証明書自体の「ｃｈｅｃｋｓｕｍ」である場合がある。メッセージは、証明書に含まれた情報から署名を確認することができない場合は正しく署名されていないことになる。証明書確認及びメッセージ署名の詳細については、先に参照した「ＩＴＵ」及び「ＲＦＣ」文書に詳しく説明されている。次に、モジュールは、その証明書がデータベースに既に記憶されているか否かを判断するために検査し、記憶されていないものだけを記録する。証明書のコピーが既に記憶されている場合、モジュールは、データベース記録を検査して、取り消しと以前に識別されていたか否かを判断し、識別されていた場合は直ちにその取引は拒否される。そうでない場合、次にモジュールは、業務上の規則を定義するポリシーに従って、証明書を確認するか否かを判断する。任意のこのような確認を考慮に入れて、次に、証明書を信頼すべきか否か、従って「デジタル証明書」によって署名された取引は拒否されるべきか受理されるべきか否かを判断する。モジュールは、「デジタル証明書」を含むデータの受信後に段階Ｓ１９０で開始される。「デジタル証明書」は、一般的に、メッセージの添付ファイルとして送信され、添付ファイルのヘッダ内の最初の数バイトを検査することによって識別することができる。これらのバイトにより、添付されたファイルの形式が識別され、それによって添付ファイルが「デジタル証明書」か否かが示されることになる。
【００９３】
初期化段階Ｓ１９０は、モジュールがウェブブラウザで実行された場合には図３のポイントＡで、また、モジュールが電子メールクライアントで実行された場合には図５のポイントＡの後に発生する。初期化後、モジュールは、段階Ｓ１９１に進み、証明書の満了日が検査され、デジタル署名がメッセージに署名されたことが確認される。証明書が満了となっていたか、又は、メッセージが不正に署名されていた場合、モジュールは、段階Ｓ１９２に進み、その取引を拒否する。そうでない場合は、モジュールは、段階Ｓ１９２に進み、「デジタル証明書」の以前に受信されたコピーがないかデータベースを検索する。次に、制御は段階Ｓ１９４に移る。証明書のコピーがデータベースで見つかった場合、制御は判断段階Ｓ１９６に移り、そこでモジュールは、証明書が以前に取り消しとして記載されていたか否かを判断する。これは、以前の確認検査が「デジタル証明書」が取り消されていたことを明らかにした場合に生じているものである。証明書がまだデータベース内にない場合、制御は段階Ｓ１９４から段階Ｓ２０２に移り、新しい証明書及び証明書が受信された日付が、証明書が送信されたアドレス、及び、金額及びアカウント番号などの取引に関連した任意の取引の更なる詳細と共に、データベースに記憶される。段階Ｓ１９６で証明書が既に取り消しと記載された場合、制御は、直接段階Ｓ１９８に移り、「デジタル証明書」を構成する取引が自動的に拒否される。これには、例えば、証明書が無効と分った送信の開始者に拒否を説明するために自動的に生成されたメッセージを送信する段階、及び、「デジタル証明書」の受信者が拒否された送信に関連していかなる更なる段階を講じることをも防止する段階を伴うであろう。次に、モジュールは、段階Ｓ２００でフローから出る。
【００９４】
しかし、段階Ｓ１９６で証明書が以前に取り消しと記載されていなかった場合、制御は段階Ｓ２０４に移り、証明書により署名されたか、同じ会社の他の証明書により署名されたか、又は、同じアカウント上で取引を行うのに使用された送信の履歴は、証明書のオンライン確認検査が必要とされるか否かを判断するためにポリシーデータを用いて検討される。制御はまた、段階２０２で新しい「デジタル証明書」がデータベースに追加された後に段階Ｓ２０４に移る。
【００９５】
ポリシーデータには、以前に受信した署名された取引と以前に行われた取り消し検査との履歴と共に検討した時に、取引に署名するために使用された証明書をこの場合に確認すべきか否かを示す命令が含まれる。例示的なポリシーデータをここで参照すべき図１０に示す。
ポリシーデータは、ポリシーデータ表現の「ＤｉｇｉｔａｌＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチ上の「ＡｃｃｅｐｔａｎｃｅＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチ上に記憶されている。「ＡｃｃｅｐｔａｎｃｅＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチは、証明書が金額に関する受信者との取引を伴う送信に署名するために使用される「金融上の」「デジタル証明書」と、送信の受信者との金銭的な取引を伴わない「Ａｉｄｅｎｔｉｔｙ＠」「デジタル証明書」とを個々に取り扱う２つの個別のブランチに細分化されている。いくつかの証明書は、金銭的な取引に関連して使用するために限って発行される。例えば、署名された送信の受信者に対する保証として、「Ｉｄｅｎｔｒｕｓ」のような一部のオンライン銀行組織によって「保証証明書」が発行される。このような保証証明書は、伝送の送信者が「Ｉｎｄｅｎｔｒｕｓ」加盟銀行の顧客であること、及び、この顧客が支払いを行わなかった場合には、その銀行が債務を引き受けることを証明するものである。
【００９６】
異なる種類又はクラスの「デジタル証明書」を発行する組織は、そのクラスに従って各証明書にマーキングを付している。従って、証明書が特定クラスのものとして識別することは、異なる組織がその証明書を分類する方法を知り、適切なインジケータを受信した証明書において検索するということである。
「デジタル証明書」の発行人は、異なる目的に合った多くの異なるクラスの証明書を交付することができる。これらは、ポリシー・データ・ツリーの対応するサブブランチにより、ポリシーデータによって別々に取り扱うことができる。
【００９７】
例示的なポリシーにおいて、「ＡＩｄｅｎｔｉｔｙＣｅｒｔｉｆｉｃａｔｅｓ＠」と題した第１のブランチは、金銭的な取引を伴わない送信を取り扱う。このブランチは、４つの個別のサブブランチを含む。これらの第１のサブブランチは、「ＡＡｌｗａｙｓＡｃｃｅｐｔＦｒｏｍ＠」と題されており、信頼できると考えられる個人及び組織の名前を記載する「表ａ」への参照を含む。この表に記載された名前は、その会社が知っており黙示的に信頼しているものであり、これらの個人及び組織については、「デジタル証明書」がその発行人から取り消されているか否かを判断する必要はない。
「ＡＡｌｗａｙｓＣｈｅｃｋＦｒｏｍ＠」と題された第２のブランチは、「デジタル証明書」を常に検査すべき組織及び個人の名前が記憶されている別表である表ｂへの参照を含む。明らかに、表ａ及び表ｂのコンテントは、好ましいシステムのユーザの経験に依存するものになり、ユーザの入力したものに任されることになる。
【００９８】
「ＡＣｈｅｃｋＩｆＤａｙｓＳｉｎｃｅＣｅｒｔｉｆｃａｔｅＲｅｃｅｉｖｅｄＦｒｏｍＣｏｍｐａｎｙ＠」と題された第３のブランチは、有効な「デジタル証明書」会社からの受領以降の期間を指定しており、この期間内では、その会社から受領されたあらゆる更なる「デジタル証明書」の検査は不要とみなされる。この場合、その期間は１０日間と設定されている。
「ＡＣｈｅｃｋＩｆＤａｙｓＳｉｎｃｅＬａｓｔＲｅｃｅｉｖｅｄＴｈｉｓＣｅｒｔｉｆｉｃａｔｅ＠」と題された第４のブランチは、個別の「デジタル証明書」の場合の同様の期間を指定する。図示した例においては、ポリシーデータは、いかなる所定の識別の「デジタル証明書」に関する確認の検査も３０日毎のみに行う必要があると指定する。ここでもまた、これらのブランチの両方で指定された日数は、決めるのは好ましいシステムのユーザに任される。有効な「デジタル証明書」が受領されてから経過した期間は、「デジタル証明書」及びデータベースに記憶された関連データを参照することによって判断することができる。受信される度ではなく「デジタル証明書」を定期的に検査することにより、検査するのに使う費用を節約することができる。また、「ＭｏｎｅｔａｒｙＣｅｒｔｉｆｉｃａｔｅ」ブランチは、それぞれ、表ｘ及び表ｙを参照する「ＡｌｗａｙｓＡｃｃｅｐｔＦｒｏｍ」ブランチ及び「ＡｌｗａｙｓＣｈｅｃｋＦｒｏｍ」ブランチを含む。表ｘには、「デジタル証明書」の状態検査が不要である組織及び個人が記載されており、表ｙには、検査が常に必要とされるもの全員が記載されている。また、「ＭｏｎｅｔａｒｙＣｅｒｔｉｆｉｃａｔｅ」ブランチは、全ての「デジタル証明書」を検査しなければならない閾値取引金額を指定する「ＣｈｅｃｋＡｍｏｕｎｔＥｘｃｅｅｄｓ」ブランチ、及び、最後に、最近受信されて確認された「デジタル証明書」に対して検査を行うための２つの条件を定める「ＩｆＲｅｃｅｎｔｌｙＣｈｅｃｋｅｄ」ブランチを含む。「ＩｆＲｅｃｅｎｔｌｙＣｈｅｃｋｅｄ」ブランチにより、ユーザは、過去の取り消し検査から特定の期間内、この場合は３０日内に受信された小額、この場合は５０００ドルについての取引に関して受信された「デジタル証明書」は確認する必要はないことを指定することができる。
【００９９】
図１１は、図９に示したポリシーデータと対話するプラグイン・モジュール処理を示す。この処理は、図８に示したものの副処理であり、段階Ｓ２０４で発生し、それによって判断段階Ｓ２０６に進み、プラグイン・モジュールは、受信した「デジタル証明書」の状態のオンライン検査を行うか否かを判断する。この副処理は、段階Ｓ２２０で始まり、そこから制御は段階Ｓ２２２に移り、メッセージに署名するのに使用された「デジタル証明書」のクラスからその取引が金銭的なものであるか否かが判断される。取引が金銭的なものであった場合、制御は段階Ｓ２３２に流れ、この段階は、ポリシーデータの「ＡｃｃｅｐｔａｎｃｅＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチの「ＭｏｎｅｔａｒｙＣｅｒｔｉｆｉｃａｔｅ」ブランチ内の各ブランチに対応する判断段階チェーン内の第１のものである。
【０１００】
段階Ｓ２２２において、取引が金銭的なものではないと判断された場合、制御は段階Ｓ２２４に移り、この段階は、ポリシーデータの「ＡｃｃｅｐｔａｎｃｅＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチの「ＩｄｅｎｔｉｔｙＣｅｒｔｉｆｉｃａｔｅｓ」ブランチに対応する判断段階チェーン内の第１の判断段階である。チェーン内の判断段階の各々において、ポリシーデータの「ＩｄｅｎｔｉｔｙＣｅｒｔｉｆｉｃａｔｅｓ」ブランチの各サブブランチに指定された条件が満足されているか否かを確かめるために単純な検査が行われる。その検査結果により、制御は、「デジタル証明書」の信用が確立されているので「デジタル証明書」の状態のオンライン検査は不要である段階Ｓ２４２か、又は、信用が確立されていないのでオンライン検査が必要とみなされる段階Ｓ２４４か、又は、チェーンの次の判断段階かのいずれかに流れる。
【０１０１】
すなわち、「デジタル証明書」の送信者が「ＡＡｌｗａｙｓＡｃｃｅｐｔＦｒｏｍ＠」表である表ａに記載されているか否かが判断される判断段階Ｓ２２４において、「デジタル証明書」の送信者が表Ａに記載されていた場合、制御は、判断段階Ｓ２２４から段階Ｓ２４２に流れ、信用が証明書に確立されて副処理が終わり、図８の段階Ｓ２０８に戻る。送信者が表Ａになかった場合、制御は、段階Ｓ２２４からチェーン段階Ｓ２２６内の次の判断段階に流れ、「デジタル証明書」の送信者が「ＡＡｌｗａｙｓＣｈｅｃｋＦｒｏｍ＠」表である表ｂに記載されているか否かが判断される。同様に、送信者がこの表に記載されていた場合、制御は段階Ｓ２４４に流れ、「デジタル証明書」の状態のオンライン検査が必要であるとみなされる。制御は、副処理の段階Ｓ２４４から図８の段階Ｓ２１０に戻る。
【０１０２】
「デジタル証明書」の送信者が表ｂに記載されていなかった場合、制御は、判断段階Ｓ２２６から、ポリシーデータに記載されたサブブランチとして記載されたその次の条件を表すチェーン内の判断段階に流れる。すなわち、判断段階Ｓ２８８において、この「デジタル証明書」が過去３０日間において確認されたか否かに関して検査が行われる。これは、記憶された「デジタル証明書」のデータベースにおいてその「デジタル証明書」を調べ、記憶された情報からその「デジタル証明書」が以前に検査された日付を抽出する段階を伴うことになる。「デジタル証明書」の状態が過去３０日間で検査されていた場合、制御は段階Ｓ２４２に流れ、そこで信用が確立される。記憶された「デジタル証明書」の情報から、過去３０日間において検査されていなかったことが分った場合、制御は、段階Ｓ２２８から判断段階Ｓ２３０に流れ、別の「デジタル証明書」が同一の会社から受信されたか否か、及び、その「デジタル証明書」が過去１０日以内に検査されたか否かを見るために検査が行われる。この判断では、やはり、記憶された「デジタル証明書」のデータベース及びこれらの「デジタル証明書」に関係する情報を検査することが行われる。他の「デジタル証明書」が過去１０日以内に検査されていた場合、制御は段階Ｓ２４２に流れ、受信された「デジタル証明書」の信用が確立される。そうでない場合は、制御は段階Ｓ２４４に流れる。
【０１０３】
金銭的な送信の場合、ポリシーデータで定められた条件は、判断段階Ｓ２３２から判断段階Ｓ２４０へと進められる。判断段階Ｓ２３２において「デジタル証明書」の送信者が「デジタル証明書」の検査が不要であるとみなされている会社及び組織の名前を定めた表ｂに記載されていると分った場合、信用が確立され、制御は段階Ｓ２４３に移る。見つからなかった場合、制御は、判断段階Ｓ２３４であるチェーン内の次の段階に移る。判断段階Ｓ２３４において、「デジタル証明書」の送信者が「ＡＡｌｗａｙｓＣｈｅｃｋＦｒｏｍ＠」表である表ｂに記載されていると分った場合、信用は確立されず、制御は段階Ｓ２４４に移る。記載されていなかった場合、制御は段階Ｓ２３６に移り、取引が行われている金額が１０，０００ドルを超えているか否かが判断される。この判断は、証明書の発行人によって予め決められたか、又は、取引を形成する関連の電子メール内に含まれた金額を含む署名された取引データを参照しながら行われる。取引が１０，０００ドルを超える金額に対するものであると分った場合、又は、取引金額が送信されたデータを参照しても判断することができなかった場合、信用は確立されず、制御は段階Ｓ２４４に移る。そうでなかった場合、制御は段階Ｓ２３８に移り、この「デジタル証明書」が過去３０日間において検査されたか否かが判断される。ここでもまた、この判断は、記憶された「デジタル証明書」及び「デジタル証明書」に関係するデータを参照しながら行われる。証明書が過去３０日間において検査されていなかった場合、信用は確立されず、制御は段階Ｓ２４４に移る。検査されていた場合、制御は段階Ｓ２４０に移り、そこで、以前に判断された取引金額が５，０００ドルを上回るとみなされた場合、信用は確立されず、制御は段階Ｓ２４４に移る。取引金額が５，０００ドルを下回る場合、「デジタル証明書」を信頼することに対する受容可能なリスクとして分類されて信用が確立され、制御は段階Ｓ２４２に移る。
【０１０４】
これらの最後の２つの条件によって、本システムは、最近の取引履歴に基づいて証明書の状態を検査すべきか否かを判断することができる。例えば、取引が中庸な金額、すなわち、５，０００ドルよりも低い金額に関して当事者によってまさに行われようとしており、また、記録された取引及び証明書の詳細の検索によってごく最近に同一当事者が取引を行い、その時点で「デジタル証明書」が有効と確認されたことが分った場合、第１回後の非常に間もないうちにその当事者の証明書の有効性を再度検査することは不要であるというのは論拠のあることであり、２回目の確認手数料を支払うのではなく、その当事者を信用することが好ましい。
【０１０５】
ポリシーファイル内の命令は、会社内の個人の経験、及び、重大な危険性なしに許可可能とみなされる取引金額などに基づいて、その会社が自社顧客又は納入業者に対して有する信用のレベルを反映するように定めることができることが認められるであろう。また、ポリシーファイルは、その「デジタル証明書」の保持者の取引詳細の記録に関連して使用すべき更に総合的なポリシーを実行するように定めることができる。例えば、保持者によって提供されるいかなる取引も、金額、品物、及び、サービスがその取引履歴通りに維持されているか否かを確かめるために、以前に行った取引の記録に照らして比較することができる。そうでない場合、証明書の有効性を検査してまだ有効であり送信者の身元を特定するものであることを確認することが望ましいであろう。取り消されていた場合には、第三者が元の保持者の個人キーを取得して、不正な取引を行おうとしている可能性がある。
【０１０６】
段階Ｓ２０４においてポリシーデータを検査した後、「デジタル証明書」の信用は、確立されているか又は確立されていないことになる。判断段階Ｓ２０６において、信用が確立されていた場合、制御は段階Ｓ２０８に移り、その取引を含む送信が受理される。次に、制御は段階Ｓ２００に移り、そこでモジュールはフローから出て、ウェブブラウザの場合は図３のポイントＡに、又は、電子メールクライアントの場合は図５のポイントＡに戻る。
【０１０７】
段階Ｓ２０６において「デジタル証明書」の信用が確立されなかった場合、制御は段階Ｓ２１０に移り、オンライン確認検査が「デジタル証明書」に対して行われる。これは、「デジタル証明書」が取り消されたか否か、又は、「ｅＣｏｍｍｅｒｃｅ」取引の場合には「デジタル証明書」の発行人が取引で約束された金額の保証を確認することになるのか否かを見るために検査する段階を伴うであろう。次に、制御は段階Ｓ２１２に移り、その証明書に関してデータベースに記憶された有効性状態が更新される。次に、制御は段階Ｓ２１４に移り、そこで証明書が無効と判明した場合、制御は段階Ｓ１９８に移り、取引は拒否されるか又は段階Ｓ２０８に移り、そこで取引が受理される。取引の拒否とは、開かれる前に受信者のメールボックスから削除されるか、又は、その送信に「拒否」という語又は何らかの他のインジケータが記載されることを意味するであろう。段階Ｓ１９８又はＳ２０８のいずれかの後、制御は段階Ｓ２００に移り、そこでモジュールはフローから出る。取引が進行することを許可された時は常に、データベースは、その情報が今後の確認検査の必要性を判断する際に使用することができるように、日付及び金額のような取引に関する情報を含むように更新される。
【０１０８】
情報の記録
好ましいシステムはまた、オンラインで実行される取引の取引情報を記録する自動的な方法を提供する。この関連において、「Ａｔｒａｎｓａｃｔｉｏｎ＠」及び「ＡｅＣｏｍｍｅｒｃｅ ｔｒａｎｓａｃｔｉｏｎ＠」という語は、インターネット上、又は、会社の同一ネットワーク上でさえも、２人の当事者間で為された金額又は金額に相当するものを約束する同意を意味するように意図されている。一般的は、ユーザ自身は、該当電子記録のハードコピーを取ることによって、又は、コンピュータ上のファイルにあらゆる電子記録のコピーを積極的に記憶することによって取引情報を維持する責任がある。これらの記録を維持するのに手作業の方法に頼ることは、明らかに信頼性がなく労動集約的である。
【０１０９】
一方、好ましいシステムは、取引が始まったか又は行われていることのインジケータを求めて本システムによって処理された全ての通信の情報内容を走査する。このようなインジケータは非常に多い。最も直接的なものは、大半のウェブページは取引が実行される前に機密リンクをネゴシエートしてその後そのリンクを閉じるため、リンクが機密リンクであるか否かということである。リンクが機密リンクであるか否かの判断は、宛先ウェブページの「ＵＲＬ」を検査することによって達成される。機密リンクは、接頭語「ｈｔｔｐ」の後の「ｓ」によって表示される。従って、好ましいシステムの１つの作動モードは、リンクが機密リンクである間にウェブページに送信された全てのデータを記録することである。また、好ましいシステムは、機密リンクをネゴシエートするが「ｅＣｏｍｍｅｒｃｅ」サイトではない、すなわち、購入をするため以外に接続されているものであってこれらのページに送信されたデータを記録しないウェブページの記録を維持する。このようなウェブページは、電子メールサービスを行うマイクロソフト製の「ホットメール」ウェブページであろう。
別のインジケータは、単にサイトの「ＵＲＬ」であろう。この場合、好ましいシステムは、オンライン取引会社のものとして特定されたウェブページに送信された全てのデータを記録するように構成することができる。他のインジケータは、識別されたカード番号、電子領収書、販売を確認する電子メール、「デジタル証明書」特にデジタル保証証明書の使用、又は、購入コードであろう。
【０１１０】
取引が発生していると特定された状態で、好ましいシステムは、ユーザ及び特定された業者間の各通信をそっくりそのまま記憶することによって、又は、取引を走査して日付、金額、品物の種類、及び、数量のような特定の詳細を抽出することによって、その取引の詳細を記録することができる。
取引データの記録は、取引の終了が特定された時、又は、購入者と業者間の所定の数の取引が行われた後に停止することができる。同様に、取引が特定されると、好ましいシステムは、取引の第１の認識された送信直前に行われたキャッシュされた所定数の送信をデータベースに記録することができる。
【０１１１】
これは、例えば、送信が発生しているという第１のインジケータがクレジットカード番号又は電子領収書の検出である時には、それらが取引の正に終了時に受信される可能性が高いので有益であろう。従来の送信は、例えば、購入されている品物又はサービスに関する情報を含むウェブページ、又は、仕様又は納品条件が同意された電子メールの交換から成るものとすることができる。従来の送信は、取引が検出されたものと同一の形式、異なる形式、又は、各形式の混合であることが全く可能であることに注意すべきである。例えば、ユーザは、ウェブサイトｗｗｗ．ａｂｃ．ｃｏｍを訪れて品物の詳細を取得し、次に「ｏｒｄｅｒｓ＠ａｂｃ．ｃｏｍ」に送られる電子メールで注文することができるであろう。
好ましいシステムは、取引詳細を中央共通データベース４２に記録する。更に、データベースは、ローカルファイル又はネットワーク上のサービスとしてもよい。データベースに記憶された情報は、必要な認定を有する人のみがアクセスすることができるように公知の暗号化技術を使用して暗号化することができる。
【０１１２】
図１２は、電子取引がオンラインで行われている時期を特定するためのモジュールの例示的な実行の作動図である。図１４は、好ましいシステムが識別された取引をデータベースに記録する処理を示し、図１５は、好ましいシステムによって識別された取引を所定の承認ポリシーに基づいて承認又は拒否することができる様子を示す。
次に、図１２を参照して、オンライン取引が発生している時期を特定するためのモジュールの作動について説明する。
モジュールは、段階Ｓ２５０で、データの受信に応答して又はユーザが遠隔サイトへのデータ送信を開始したのに応答して作動を開始する。これは、ウェブブラウザでの実行の場合、図３に示すように、それぞれポイントＡの後又はポイントＣの後、また、電子メールクライアントでの実行の場合、図５に示すように、それぞれポイントＡ又はＢの後となる。
【０１１３】
次に、制御は段階Ｓ２５２に移り、ウェブブラウザの場合には、機密リンクがデータを送信するサイトとデータを受信するサイトとの間でネゴシエートされたか否かが判断される。これは、上述したように、接続された「ＵＲＬ」アドレスに問い合わせるか、又は、ウェブブラウザに質問して暗号化が採用されているか否かを確認することによって達成することができる。電子メールメッセージの場合、この段階は省略され、制御は、直接段階Ｓ２６０に移る。ウェブブラウザによるオンライン取引は、通常、名前及びアドレス、及び、クレジットカード番号又は他のアカウント特定情報のような個人情報の送信を伴うことから、当然のことながら、通常は機密リンクがネゴシエートされる。従って、機密リンクの存在だけで取引が行われていることを十分に示すものになる。しかし、機密性を有する接続は、取引詳細の送信以外の理由からもネゴシエートすることができる。従って、段階Ｓ２５２において、接続が機密のものであると判断された場合、制御は段階Ｓ２５４に移り、接続が為された遠隔サイトのアドレスは、オンライン取引を行う機能を提供していないが機密性接続は確かに確立している公知のサイトのリストに照らして検査される。マイクロソフト製の「ホットメール」サイトなどのブラウザベースの電子メールサイトは、１つのこのような例である。次に、制御は段階Ｓ２５６に移り、以前の検査に基づく判断が行われる。サイトアドレスが、取引の実施を促進しないものである非「ｅＣｏｍｍｅｒｃｅ」サイトと特定された場合、次に、取引が発生する可能性があるか否かが判断され、制御は、取引内容を更に検査するために段階Ｓ２６０に移る。段階Ｓ２５６において、サイトアドレスが公知の非「ｅＣｏｍｍｅｒｃｅ」サイトと特定されなかった場合、オンライン取引が発生していると仮定され、モジュールは段階Ｓ２５８でフローから出る。
【０１１４】
段階Ｓ２５２で機密性の接続が確立されていないと判明した場合、又は、機密性接続は確立されているが、段階Ｓ２５６で判断されたように、公知の非「ｅＣｏｍｍｅｒｃｅ」サイトに対してであるか又はその送信が電子メールであった場合、制御は段階Ｓ２６０に移る。判断段階Ｓ２６０において、送信の内容に対するいくつかの検査のうちの第１の検査が、それが取引の一部であるか否かを判断するために行われる。段階Ｓ２６０において、送信は、クレジットカード番号を含むか否か確認するために走査される。これを行うための方法は、図８を参照して説明された。クレジットカード番号が送信内で見つかった場合、取引が発生しているに違いないと仮定され、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。クレジットカード番号が見つからなかった場合、制御は、代わりに判断段階Ｓ２６２に移り、送信がアカウントコードを含むか否かを確認するために走査される。アカウントコードは、（例えば）この段階の実行時にモジュールによってアクセスされる個別のファイルに記憶することができ、又は、代替的に、アカウントコードは、メッセージのテキストに表示される「アカウント番号」又は類似の文字のようなファイル名などの送信内の説明データ内で識別することができる。
【０１１５】
判断段階Ｓ２６２において、アカウントコードが見つかった場合、送信は取引の一部を成すと仮定され、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。アカウントコードが見つからなかった場合、制御は段階Ｓ２６４に移り、ウェブブラウザの場合には、「ＵＲＬ」がデータベース内のファイルに記憶された公知の「ｅＣｏｍｍｅｒｃｅ」の「ＵＲＬ」リストと比較される。判断段階Ｓ２６６において、その比較に関する判断が行われる。「ＵＲＬ」が公知の「ｅＣｏｍｍｅｒｃｅ」ページにおけるもの又は公知の組の「ｅＣｏｍｍｅｒｃｅ」ページ内のものであると判明した場合、「ｅＣｏｍｍｅｒｃｅ」取引が行われていると判断され、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。同様に、電子メールの場合には、宛先アドレスが公知の「ｅＣｏｍｍｅｒｃｅ」の電子メールアドレス、例えば「ｏｒｄｅｒｓ＠ａｂｃ．ｃｏｍ」のリストと比較され、適合するものが見つかった場合は、「ｅＣｏｍｍｅｒｃｅ」取引が行われていると判断され、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。
説明した検査は、送信が「ｅＣｏｍｍｅｒｃｅ」取引の一部でありそうであるか否かを判断するために為し得る可能な検査を単に表しているに過ぎず、網羅したものであることを意図していない。更に、検査が図示されている順番には特別な意味はない。順番は、単に、図１３を参照して分るようにポリシーデータの構造に依存する。
【０１１６】
段階Ｓ２６８において、上述のものに加えて、例えば、データ内に置かれた購入コード又は組込コードを検索するなど、会社が採用することが望ましいと判断する取引のインジケータの有無に関する任意の更なる検査を表す一般的な検査が図示されている。好ましいシステムにおいて使用されているウェブブラウザ又は電子メールクライアントにより、ユーザが、その送信は取引の一部であるので記録すべきであることを示すために、組込コードで送信をマークすることができることが好ましい。また、組込コードは、ウェブサイト又は取引データの一部をユーザのワークステーションに送信する電子メールクライアントによってデータ内に置くことができる。
【０１１７】
サイトが公知の「ｅＣｏｍｍｅｒｃｅ」サイトと認識されなかった場合、制御は段階Ｓ２６６の後にこの段階に移り、そのような取引インジケータが段階Ｓ２６８において見つかった場合、取引は発生しているとみなされ、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。段階Ｓ２６８でこのようなインジケータが見つからなかった場合、取引は発生していないとみなされ、モジュールは、段階Ｓ２５８でフローから出る。フローから出た後、データは、図３及び図５のポイントＣ及びＢの後にそれぞれ送信するか、又は、図３及び図５のポイントＡで受信されてから処理することができる。
【０１１８】
説明した例において、その目的は、取引が発生しているという単なる疑いがある場合に送信及び可能性がある取引の詳細を記録し始めることである。取引の一部ではないデータの記録は、取引を全く記録しないよりも好ましいと仮定される。図１３は、「ｅＣｏｍｍｅｒｃｅ」取引が発生していることを識別し、取引データの記録方法を制御するために使用されたポリシーデータの図である。ポリシーデータは、「ＡＩｄｅｎｔｉｆｉｃａｔｉｏｎ＠」及び「ＡＴｅｒｍｉｎａｔｉｏｎ＠」という２つの個別のサブブランチに細分化されるポリシー・データ・ツリーの「取引」ブランチによって表現される。「Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」ブランチ自体は、図１２で示した処理で行われた判断に対応する５つのサブブランチに分けられる。これらのサブブランチのうち、「ＡＩｆＣｏｎｎｅｃｔｉｏｎＧｏｅｓＳｅｃｕｒｅ＠」と題されたサブブランチによって、ユーザは、プラグイン・モジュールがウェブサーバとの接続が機密になったことを検出した時に記録を開始すべきであるか否かを指定することができる。このサブブランチで指定された諸条件は、図１２に示した判断段階Ｓ２５２に対応する。図１２に示した制御の流れは、図１３に示したポリシー・データ・ツリーの種々のブランチに指定された条件のレイアウトに対応することは、図１２及び図１３を参照すれば認められるであろう。「ＩｆＣｏｎｎｅｃｔｉｏｎＧｏｅｓＳｅｃｕｒｅ」ブランチの「ＥｘｃｌｕｄｅｄＳｉｔｅｓ」ブランチは、機密サイトをネゴシエートすると知られているが「ｅＣｏｍｍｅｒｃｅ」ウェブサイトではないと知られているウェブサイトが記載される表ｑへの参照を含む。表ｑは、図１２に示した処理の段階Ｓ２５６において参照される。
【０１１９】
「ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」ブランチの次のサブブランチは、「ＡＩｆＣｒｅｄｉｔＣａｒｄＮｕｍｂｅｒＰｒｅｓｅｎｔ＠」と題されており、これによって、ユーザは、送信されている又は受信されているデータの記録を開始するためにクレジットカード番号の検出を使用すべきであるか否かを指定することができる。このサブブランチは、判断段階Ｓ２６０に対応する。「ＩｆＣｒｅｄｉｔＣａｒｄＮｕｍｂｅｒＰｒｅｓｅｎｔ」ブランチの「ＰｒｅｖｉｏｕｓＰａｇｅｓ」サブブランチは、クレジットカード番号が検出されたウェブページ以前のウェブページの数を記載し、それはまた記録されるべきである。クレジットカード番号は一般的に取引終了時に提出されることから、このサブブランチの設置によって、取引の詳細及び要求を含む可能性が高い過去のウェブページを検出及び記憶することができる。これらのウェブページは、仮に取引が特定された場合にもウェブページがキャッシュから検索されてデータベースに記憶されるように、好ましいシステムによって絶えずキャッシュされる。これについて、図１４を参照しながら更に詳細に説明する。
【０１２０】
「Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」ブランチの次のサブブランチは、「ＡＩｆＡｃｃｏｕｎｔｓＣｏｄｅＰｒｅｓｅｎｔ＠」と題されており、これによって、ユーザは、送信されているか又は受信されているデータ内のアカウントコードの検出をデータの記録を開始するためのインジケータとして取るべきであるか否かを指定することができる。アカウントコードは、図１２に示す段階Ｓ２６２において表ｒを参照して特定される。この表への参照は、「ＩｆＡｃｃｏｕｎｔｓＣｏｄｅＰｒｅｓｅｎｔ」ブランチの「ＡｃｃｏｕｎｔＣｏｄｅｓ」サブブランチに含まれている。この表はまた、クレジットカード識別に関して上述したものと類似の方法で記録すべき以前のウェブページ数を示すが、この場合、記録すべき以前のウェブページ数は表ｒに記憶されており、ウェブページの異なる数を各検出アカウントコードに対して指定することができることに注意すべきである。
【０１２１】
「ＩｆＫｎｏｗｎＥＣｏｍｍｅｒｃｅＳｉｔｅ」ブランチによって、ユーザは、「ｅＣｏｍｍｅｒｃｅ」取引が行われると知られているサイト、サイトの一部、又は、単一のサイトに対応している「ＵＲＬ」のリストを指定することができる。現在のページ「ＵＲＬ」は、取引が行われているか否かを判断するために、このリスト内のエントリと照合される。「ＫｎｏｗＳｉｔｅｓ」サブブランチは、公知の「ｅＣｏｍｍｅｒｃｅ」サイトの「ＵＲＬ」が記憶されている表ｓへの参照を含む。ウェブサイトの「ＵＲＬ」が公知の「ｅＣｏｍｍｅｒｃｅ」サイトであるか否かの判断は、図１２の段階Ｓ２６４後の判断段階Ｓ２６６において行われる。最後に、「ＩｆＯｔｈｅｒＩｎｄｉｃａｔｉｏｎＰｒｅｓｅｎｔ」ブランチは、ユーザが他のインジケータの判断をデータ記録の開始点として使用すべきであるか否かを指定する方法を提供する。「Ｋｅｙｗｏｒｄｓ」及び「ＰｒｅｖｉｏｕｓＰａｇｅｓ」と題されたこのブランチの２つのサブブランチは、検出し得る可能なインジケータ、この場合は表ｔに記載されたキーワードと、キーワードが検出された場合に記憶することが必要とされる以前のページ数とを指定する。
【０１２２】
「取引」ブランチの「終了」ブランチは、送信されている又は受信されているデータの記録を終了するのに使用される条件を指定する４つのサブブランチに分かれる。各サブブランチは、取引の終了を定義することができる条件を定める。「ＡＩｆＣｏｎｎｅｃｔｉｏｎＧｏｅｓＩｎｓｅｃｕｒｅ＠」と題された第１のブランチによって、ユーザは、記録が停止されるように、ウェブブラウザによる機密性接続の廃止が取引の終了を示すことを指定することができる。他のサブブランチは、ウェブサイトが変更された時に記録が停止する、デジタル領収書が受信された場合に記録が停止する、及び、取引が発生しているという表示後に２０種類のウェブページが受信された後に記録が停止することを指定することができる。
【０１２３】
この図に示したポリシーデータは特に、また他の図においても、それが各ユーザに独特なものであることを強調しなければならない。ユーザが「ＹＥＳ又はＮＯ」変数を相応に設定することにより、又は、例えば記録されるべきページ数を変更することにより特定の条件に対してアクションを起こすべきであるか否かを指定することができるばかりでなく、ブランチの構造及び配置、及び、それらのブランチで指定された条件もまた、ユーザ毎に異なっていてもよい。例示的なポリシーは、ウェブブラウザ環境における取引の記録を説明する一方、類似のポリシーは、電子メール環境を制御し、機密性接続のオプションを省略するが、クレジットカード番号、アカウントコード、又は、電子メール内の他の識別可能な情報の検出時に、又は、電子メールが公知の「ｅＣｏｍｍｅｒｃｅ」アドレスに送られた場合に電子メールを記録するようにポリシーを定義することを可能にすることが認められるであろう。
【０１２４】
取引を識別する方法の全ての利点は、その方法が好ましいシステムと遠隔サイトとの間の送信を記録するための手段と共に利用された時に実現される。これによって、ユーザが実行した全ての送信の記録を自動的に保管及び維持管理することができる。記録は、受信又は送信された各伝送の紙によるコピーを取る必要もなく更新された状態で保管することができる。従って、会社の記録保管は、かなり容易かつ正確になる。
【０１２５】
図１４は、取引を含む送信を記録するためのモジュールの作動を示す。モジュールは、段階Ｓ２７０で開始される。
モジュールがウェブブラウザの一部として実施された場合、段階Ｓ２７０は、データ受信後に図３のポイントＡで、又は、遠隔サイトへデータを送信する直前に図３のポイントＣの後で開始される。モジュールが電子メールクライアントの一部として実施された場合、段階Ｓ２７０は、電子メールが受信された後に図５のポイントＡの後に、又は、ユーザによって作成された電子メールが受信者に送信される直前に図５のポイントＢの後に発生する。段階Ｓ２７０後に、制御は段階Ｓ２７２に移り、図９を参照して上述した取引を特定するための試験が行われ、「ｅＣｏｍｍｅｒｃｅ」取引が発生しているか否かに関して判断が行われる。次に、制御は段階Ｓ２７４に移り、取引は発生していないと判断された場合は、制御は、直接段階Ｓ２７６に移り、そこでモジュールはフローから出る。
【０１２６】
しかし、取引が発生していると判断された場合、制御は段階Ｓ２７８に移り、そこで、検出手段、送信者の身元、取引金額、又は、どの前回の送信（それがある場合）を特定された送信と共に記憶するべきであるか、及び、どのくらい詳細に送信を記録すべきかを判断する他のパラメータのうちの１つ又はそれ以上に関してポリシーが調べられる。例えば、ポリシーは、多額の金額を伴う取引を小額の取引よりも詳細に記録するように要求するかもしれない。作動におけるこの一例は、多額の金額を伴う取引のためにオンライン取引業者のウェブサイト上で取引を行っている時にアクセスされた全てのウェブページを記録するが、小額取引については電子領収書を含む送信のみを記録することであろう。
【０１２７】
ポリシーファイルはまた、記憶されるデータの量を判断するだけでなく、記録されるデータの性質を判断することができる。取引の一連のスナップショットとして送信又はウェブページ全体を、例えばウェブページがキャッシュメモリに記憶されるのと同一の方法で記録することができ、又は、代替的には、日付、業者の身元、及び、金額のような個々のデータ項目を送信又はウェブページから抽出して、それら自体又はスナップショットデータと共に記憶することができる。
このように、最も重要な取引には確実に十分な記録スペースがあるようにするために、記憶のためのメモリを最も効果的に使用することができる。また、記録される取引データの量は、業者の身元、地理的位置、ユーザの会社との取引履歴、及び、オファーされる品物及びサービスによる場合がある。
【０１２８】
図１３において、例示的なポリシーデータは、記録されるデータ量がメモリにキャッシュされたページから検索されるウェブページ数によって指定されるという簡単なシナリオを示している。数字は、クレジットカード番号、アカウントコード、又は、キーワードが特定されるか否かによって異なる。更に、表ｒは、異なるアカウントコードの認識で、記憶すべき以前のウェブページ数が異なる可能性があることを示しており、アカウントの相対的な重要性を反映している。
【０１２９】
この単純な事例をより高度な事例に拡張することは、ポリシーデータにより高いレベルの詳細を提供することによって達成することができる。ポリシー・データ・ツリーに対する追加のブランチは、品物及び／又はサービスに関係する会社名又は個人名又は特定のキーワード、及び、これらのキーワード及び名称に依存する記録すべきデータ量を指定することができるであろう。
また、これらの表は、記憶すべき異なる形式のデータ量を示すために拡張することができる。会社名、販売されていた物、及び、数量などのデータは、電子メールテキスト、ウェブページを構成する「ＨＴＭＬ」テキスト、又は、ウェブページの「ＤＯＭ」表現から抽出してデータベースに記憶することができる。
【０１３０】
キャッシュ内に記憶された全てのウェブページ又は情報を検索することができ、又は、代替的に、本システムは、取引の一部であると当初に特定されたページと共通の詳細を有するページのみを検索することができる。
代替的に、全ての記憶されたメッセージのリストは、ユーザが識別された取引に関係する送信を手作業で選択するようにユーザに提示することができる。
どれだけのデータを記憶すべきかの判断後に、制御は判断段階Ｓ２８０に移る。段階Ｓ２８０において、以前の送信を記憶すべきであった場合、制御は段階Ｓ２８２に移り、ローカルキャッシュに記憶された送信が検索される。ウェブブラウザの場合、これは、上述したように以前のページの所定数としてもよい。取引がウェブブラウザにおいて検索された場合、ポリシーはまた、例えば、同一の組織に送られたか又は同一の組織から受信された以前の電子メールメッセージがないかに関してキャッシュを検索するように命令することができる。これは、ブラウザ「ＵＲＬ」の部分を電子メールアドレスの部分と対照させることによって判断することができる。同様に、電子メールメッセージにおいて検出された取引によって、以前の電子メール及び以前のウェブページをキャッシュから検索することができる。次に、制御は段階Ｓ２８４に移り、識別された取引及びあらゆる検出された以前の送信は、システムデータベース４２に記憶される。
【０１３１】
段階Ｓ２８０において、以前の送信が必要とされた場合、制御は、直接段階Ｓ２８４に移り、取引として特定された送信がシステムデータベースに記録される。段階Ｓ２８４において送信が記憶される同時に、完全な記録を形成するためにユーザ身元、金額、及び、取引の相手方当事者などの関連データもシステムデータベースに記録することができるが、これは、ポリシーデータの命令に依存することになる。次に、制御は段階Ｓ２８６に移り、モジュールはフローから出る。
モジュールがフローから出た後の段階Ｓ２７６以降、データは、図３及び図５のポイントＡに続いてそれぞれ送信することができ、又は、図３及び図５のポイントＣ及びＢでそれぞれ受信された以降に処理することができる。
【０１３２】
送信が行われていると識別された状態で、ユーザと相手方当事者との間の全ての送信は、本システムが取引が完了されたことを検出するまで記録することができる。取引終点の検出及び記録の停止は、取引が行われているか否かの識別に関して上述したものと類似の方法で行うことができる。最も簡単な実施例は、電子領収書又は発送指図書が受信されるまで送信情報を記録することである。代替的に、送信の記録をユーザと相手方当事者との間の所定回数の送信が発生した後に、又は、取引が識別されてから一定の期間が経過した場合に停止させることができる。
送信は、ユーザがウェブサイトを変更する度にキャッシュが空になる場合には更に単純にすることができる。これによって、キャッシュメモリに必要とされるメモリを低容量に維持し、検索技術が使用される場合には検索する必要がある以前の送信回数も少なくなる。
【０１３３】
上述の方法はまた、取引が検出及び記録された後に発生する関連の送信を記録するのに使用することができることが認められるであろう。例えば、ウェブブラウザを使用して行われた取引の後には、一般的に、確認の電子メールが売り手から買い手に送られることになる。この電子メールは、注文番号、アカウント番号、品物の説明、及び、価格のような共通の特性を含むことから取引の一部を形成するものとして検出することができる。また、購入するのに使用された元のウェブサイトが「ａｂｃ．ｃｏｍ」であった時は、それをウェブサイトアドレスに類似したアドレス、例えば「ｃｕｓｔｏｍｅｒｓｅｒｖｉｃｅｓ＠ａｂｃ．ｃｏｍ」から送ることができる。所定の期間内に発生するその後の送信のみが元の取引に関連するものであるとみなされるように時間要素が使用されることが好ましい。
【０１３４】
取引情報の記録に加えて、例えば、組織が実際に電子商取引の採用によって真の生産性の恩恵を得ていることを保証するために、ユーザの挙動を解析する能力を有する管理を提供する他の情報を記録することが有利であろう。このような情報は、ユーザ自身の生産性に限定されずに全体的な処理に及び、例えば、ウェブ購入サイトのどれが購入処理に関して最も効率的か、従って購入経費を低減する際の最大の利点はどれにあるかを判断するためにウェブ購入サイトを比較することを可能にする。好ましいシステムは、購入に掛かる期間、購入を完了するのに必要とされるキーストローク数及びマウスクリック回数、及び、ダウンロードするページ又は受信する応答をユーザが待つ間の「アイドル」時間の量のような更なる情報を記録することによってこれに準備する。この情報は、取引記録と共にデータベースに記録することができ、統計的な解析を取引の範囲に亘って実施することができる。
【０１３５】
取引に掛かった時間は、タイムスタンプを受信された送信の各々と関連付けることによって判断することができる。取引が完了していると判断された時、第１の送信（段階Ｓ２８２においてキャッシュから取り戻されたものとしてもよい）に付随するタイムスタンプを最終送信に付随するタイムスタンプから差し引き、全体的な取引期間となるその結果が段階Ｓ２８４においてデータベースに記憶される。代替的に、第１の送信と最終送信とをデータベースに記録した後で取引期間を計算することができる。キーストローク数及びマウスクリック回数は、オペレーティングシステム内への標準的な「ウィンドウズ」の「フック」を使用して「マイクロソフトウィンドウズ」ベースのシステムにおいて判断することができる。このような技術は、マイクロソフト・コーポレーションのウェブサイト（ｈｔｔｐ:／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ ／ｄｅｆａｕｌｔ．ａｓｐ？ｕｒｌ＝／ｌｉｂｒａｒｙ／ｅｎ−ｕｓ／ｄｎｍｇｍｔ／ｈｔｍｌ／ｍｓｄｎ＿ｈｏｏｋｓ３２．ａｓｐ）で利用可能である、１９９３年７月２９日付けのザ・マイクロソフト・ディベロッパー・ネットワーク・テクノロジー・グループのカイル・マーシュ著の文書「ウィン３２フックス」において更に詳しく説明されている。
【０１３６】
好ましいシステムは、受信された各送信間で発生するキーストローク数（「ＷＨ＿ＫＥＹＢＯＡＲＤ」フックを使用）及びマウスクリック回数（「ＷＨ＿ＭＯＵＳＥ」フックを使用）のカウンタを維持し、これらの総数を受信された送信と関連付ける。別のアプリケーションに焦点がある間（例えば、ユーザが一時的に別のアプリケーションに切り替えた場合）に発生するキーストローク及びマウスクリックは無視される。取引が完了していると判断された場合、第１の送信（段階Ｓ２８２においてキャッシュから取り戻されたものとしてもよい）と最終送信との間のキーストローク及びマウスクリックの総数が互いに加えられ、その結果（取引全体でのキーストリング及びマウスクリックの総数）が段階Ｓ２８４においてデータベースに記憶される。同様に、ウェブサイト取引応答時間は、各発信伝送要求が送られる時間に注目し、応答送信が受信される時間からそれを差し引くことによって測定することができる。取引の開始と終了との間の応答時間を合計すれば、ユーザがウェブサイトを待つのに費やした総時間が得られる。同様に、好ましいシステムはまた、伝送が受信された時間と応答が送信された時間との間の時間であるユーザ応答時間を計数する。
【０１３７】
好ましいシステムはまた、ユーザの応答時間のうち、どれだけの時間がデータ入力に費やされたかを計算するので、従って、ユーザが着信伝送を「吸収する」のに必要とされた時間（その差として）を判断することができる。データ入力に費やされた時間は、「ストップウォッチ」を維持することによって判断される。ストップウォッチは、新しい送信が受信される毎にリセットされ、ユーザがキーストロークを入力するか又はマウスをクリックする時、常に直ちに再起動される。ユーザが所定の時間、例えば５秒間キーストロークを入力しなかったか又はマウスをクリックしなかった場合、本システムは、ユーザが現在以前の送信の詳細を吸収していると仮定してストップウォッチを止める。また、ストップウォッチは、キーストローク又はマウスクリックによって発信伝送を送信させた時に止められる。取引開始と終了との間のデータ入力に費やされた時間を合計すれば、ウェブサイトでデータ入力にユーザが費やした総時間が出る。合計時間は、今後の解析のために段階Ｓ２８４でデータベースに記憶することができる。
【０１３８】
好ましいシステムはまた、行われている取引をモニタして必要とみなされた場合には承認を得るために取引を自動的に紹介するための手段を提供する。この処理によって、大手企業は、ポリシーデータに定められた単一の組の基準を使用して自社従業員によって行われている取引をモニタして制御することができる。ポリシーデータは、ユーザが自分でその取引を行うことが許可されているか否か、又は、ユーザが会社の上層部からの許可を必要とするか否かを判断するために、取引が識別される度に参照することができる。その処理を、ここで参照すべきである図１５に示す。
【０１３９】
この処理を具体化するモジュールは、段階Ｓ２９０で開始される。この開始は、検討する必要がある取引の全ての関連詳細が判断されるとすぐに、かつ、取引が行われる前に行われることが好ましい。電子メールによる取引の場合には、品物及び価格などの詳細は、一般的に単一の電子メール内に含まれており、その電子メールの送信前に検討することができる。ウェブブラウザによる取引の場合には、取引の存在は、全ての詳細が分る前に検出することができ、その場合、全ての詳細が分るまで開始されない。これは、最終的な義務は、全ての関連の詳細が分ったかなり後になって、取引処理の最後の最後まで発生しないので一般的には問題にならない。取引及び関連の詳細の検出は、図１２を参照して上述した方法で判断することができる。図３及び図５をざっと参照すれば、その段階Ｓ２９０は、必要とされる詳細が分ると、ウェブブラウザによる実行の場合には図３のポイントＣの後に、又は、電子メールクライアントによる実行の場合には図５のポイントＡの後に発生することが分るであろう。
【０１４０】
制御は、段階Ｓ２９０から判断段階Ｓ２９２に移り、取引の詳細は、承認が必要とされるか否かを判断するためにポリシー設定に照らして比較される。この判断は、取引を行う従業員の身元又は地位、取引金額、又は、取引の相手方当事者に基づくものとすることができる。いくつかの場合においては、会社の財務担当取締役が各取引が行われる前にその各々を検討したいと思う場合のように、承認が常に必要とされるかもしれない。
【０１４１】
図１６は、取引が第三者からの承認を必要とするか否かを判断するため、及び、使用すべき妥当な承認者の身元を判断するために使用することができる例示的なポリシーデータの図である。この場合、ポリシーデータ内の条件は、取引金額と、取引の相手方当事者の「ＵＲＬ」アドレスとによって承認が必要とされるか否かを規定するものである。
関連のポリシーデータは、ポリシー・データ・ツリーの「取引承認」ブランチに定められている。このブランチは、４つのサブブランチに細分化されている。第１のブランチは、「ＭａｘｉｍｕｍＵｎａｐｐｒｏｖｅｄＴｒａｎａｃｔｉｏｎＡｍｏｕｎｔ」と題されており、取引の閾値金額を定義する。閾値を上回る金額に関する取引は、行われる前に承認者によって承認されなければならない。
【０１４２】
「ＭａｘｉｍｕｍＵｎａｐｐｒｏｖｅｄＭｏｎｔｈｌｙＡｍｏｕｎｔ」と題された第２のサブブランチは、ユーザが１ヵ月以内で行うことができる取引の金額を定義する。この場合、月間総額が２，５００ドルを超えるようなユーザによって行われたいかなる取引も、その閾値に到達した後に行われる更なる取引と同様に第三者からの承認を必要とすることになる。
「ＥｘｃｌｕｄｅｄＳｉｔｅｓ」と題された第３のブランチは、取引が行われる前に第三者からの承認を常に必要とする全てのサイトのウェブサイト及び電子メールアドレスを含む表を参照する。最後に、「Ａｐｐｒｏｖｅｒｓ」と題された最後のブランチは、可能な第三者の承認者の名前が記載されている表を参照する。各名前に並べて、その承認者が承認する権限を有する対象である最大取引金額及びその承認者が取引を承認することができない対象外サイトのリストがある。各場合の最も単純なものにおいて、承認者は、部長又は管理者などの取引を行うユーザと同一ネットワーク上にログインされた他のコンピュータユーザであろう。承認者は、その役割上の性格から、商事会社が行う金銭的な取引の責任を負い、また、その責任を負う権限を有するその会社の社員であることになる。また、承認者は、財務部専属者のような主としてこの役割のために採用された者のグループから得られるという可能性がある。
【０１４３】
取引ブランチの最初の３つのサブブランチの条件によって承認が必要とされると分った場合、取引限度が提案された取引の限度に等しいか又はそれ以上であり、かつ、関係サイトに対する取引の承認を禁止されていない承認者が見つかるまで承認者の表を走査することにより、妥当な承認者を見つけることができる。
図１６に示す例示的なポリシーデータは、ネットワーク内の単一のコンピュータユーザ又はユーザのグループに専用のポリシーデータであることが認められるであろう。他のユーザ又はグループは、異なる設定及び異なる承認者リストを有してもよい。
適切な承認者を判断するための条件は、ポリシー・データ・ツリーの新しいサブブランチを作成することによって導入することができることが認められるであろう。
【０１４４】
承認処理の作動は、例えば「ｅＣｏｍｍｅｒｃｅ」取引を含むものだけでなく、任意の種類の送信に拡張することができる。このような作動は、種々の条件が定義されるか、又は、ポリシーデータのサブブランチに例えば送信内で識別されてかつその作動基準とすべきユーザ名、アドレス、又は、キーワードを指定させることによって実行することができる。従って、特定の会社又は個人宛ての全ての電子メールによる送信は、承認を必要とさせるか、又は、所定の情報を含む全ての電子メールをキーワードの識別を通じて認識させることができる。
【０１４５】
承認が必要でないことが段階Ｓ２９２において判断された場合、制御は、直接段階Ｓ２９４に移り、そこでモジュールはフローから出る。段階Ｓ２９４の後、取引の送信が許可されてその取引を処理することができる。制御は、段階Ｓ２９４から図３のポイントＣに、又は、図５のポイントＢに戻る。
しかし、段階Ｓ２９２において、ポリシー設定を調べた後に取引の承認が必要とされると判断された場合、制御は段階Ｓ２９６に移り、取引の詳細は、その取引の適切な承認者を判断するために使用される。承認者は、自分のワークステーションか、又は、図２に示すように「オペレータ」コンソール４４などの承認者専用機能を有するワークステーションでログオンした会社従業員であってもよく、又は、自動化処理である場合さえもある。いくつかの部門を有する大企業の場合、各部門に対してそれぞれがその部署のアカウントをモニタする承認者グループを有することは有利であろう。これによって、例えば、その部署の長が購入又は特定の性格の購入を一時的に停止したいと判断した場合、取引が行われる前に拒否することができる。
【０１４６】
制御は、適切な承認者の判断後に段階Ｓ２９６から段階Ｓ２９８に移り、承認要求が、システム承認待ち行列１００を通じて指名された承認者に送信される。段階Ｓ２９８後、制御は判断段階Ｓ３００に移り、承認者からの応答が受信されたか否かが判断される。承認の要求が提出されるとすぐにタイマーが起動される。段階Ｓ３００において応答が受信されていない場合、制御は段階Ｓ３０２に移り、時間切れ時期が経過したか否かがタイマーから判断される。その時期が経過していないことを条件として、制御は、段階Ｓ３０２から段階Ｓ３００に戻り、本システムは、承認者からの応答を待ち続ける。従って、段階Ｓ３００及び段階Ｓ３０２によって、応答が受信されるまで、又は、制限時間になるまでシステムが待つというループが形成される。判断段階Ｓ３００において、応答が受信されると、制御は段階Ｓ３０４に移り、取引が承認又は拒否されたか否かによってアクションが取られる。
【０１４７】
取引が承認された場合、制御は、段階Ｓ３０４から段階Ｓ２９４に移り、そこでモジュールはフローから出て、送信を続行することが許可される。しかし、送信が承認されなかった場合、制御は、段階Ｓ３００から段階Ｓ３０６に移り、そこでモジュールはフローから出る。しかし、段階Ｓ３０６でフローから出ることによって、取引の送信が行われるのが防止され、ウェブブラウザの実施の場合には図３のポイントＡに、又は、電子メールクライアントの実施の場合には図５の段階Ｓ１３２の「ｃｏｍｐｏｓｅ ｅ−ｍａｉｌ」にユーザを戻す。
また、段階Ｓ３０２において、承認者からの承認が受信されずに「時間切れ」になったとみなされた場合、制御は、直接段階Ｓ３０６に移り、そこでモジュールはフローから出る。
【０１４８】
図１５の右側は、承認者に関して伴う段階を示す。承認処理は、段階Ｓ３１０において開始され、そこから、制御は段階Ｓ３１２に移り、承認者のコンピュータが新しい承認要求がないかシステム承認待ち行列に問い合わせる。次に、制御は判断段階Ｓ３１４に移る。段階Ｓ３１４において、未決の要求がなかった場合、制御は段階Ｓ３１２に戻り、システム待ち行列がもう１度ポーリングされる。これらの段階は、承認要求が受信されるまで、又は、承認者が承認段階を非活性にするまで繰り返される。
【０１４９】
段階Ｓ３１４において、承認要求が受信された場合、制御は段階Ｓ３１６に移り、承認要求がシステム待ち行列からダウンロードされ、承認者自身がその要求を承認又は拒否すべきか判断する。次に、制御は段階Ｓ３１８に移り、承認者の応答がシステム承認待ち行列に返送され、そこからユーザワークステーションに送信される。
制御は、段階Ｓ３１８から段階Ｓ１３２に移り、新しい承認要求がないかシステム承認待ち行列が問い合わせされる。承認処理は、状況によっては自動化することができることが認められるであろう。例えば、取引は、会社が十分な資金を有していない場合、予算金額を上回る場合か又は単に最大金額を上回る場合には自動的に拒否することができる。代替的に、このような自動化は、承認要求が為されることさえもないように、ユーザ処理の一部として設けることができるであろう。
【０１５０】
所定の取引を承認するか否かを判断する際には、承認者は、例えば、総価格及び納入業者などの単に概略的情報ではなく、購入されるものを正確に見定めることができるように、完全な見通しを有することができることが理想的である。好ましいシステムは、上述の送信を記録する機能を承認機能と組み合わせることによってこれに準備するものである。段階Ｓ２９８で提出された承認要求は、段階Ｓ２８４において記憶された取引情報のデータベース内の位置への参照を用いて補足される。承認者が段階Ｓ３１６において位置詳細を受信すると、システムは、取引を成す送信をデータベースから検索し、承認者が承認の判断を行う際に検討することができるように送信を適切な方法で表示する。作動は、その後通常通りに段階Ｓ３１８で続行される。明らかに、記録段階Ｓ２８４は、承認要求が段階Ｓ２９８で行われる前に行われることが重要であり、そうでない場合は、記録された情報は、まだ利用可能な状態ではないことになる。段階Ｓ２８４で取引は識別されているがまだ完了となっていない（まだ承認されていないために）ことになるから、段階Ｓ２８４において行われたデータベース記録は、取引を「未決」と識別するフラグを含むことが必要である。次に、このフラグは、取引が承認又は拒否されたことを示すために段階Ｓ３１６において更新することができ、又は、代替的に、承認が拒否された場合は、データベース記録は、取引が行われなかったので削除することができる。
【０１５１】
セキュリティ
好ましいシステムは、送信されているデータの識別された性質によって、適切なセキュリティ等級を送信に割り当てるための手段を提供する。割り当てられるセキュリティ等級は、自分の要望を反映するために、システムのユーザがポリシーデータを使用して設定することができる。
この場合におけるポリシーデータの最も単純な実施例は、従業員パスワード、雇用主パスワード、クレジットカード番号、及び、銀行取引詳細のような可能な形式のデータを第１の欄に含み、かつ、各データ形式に適切であるとみなされた目標とする暗号化強度（例えば、キー・ビット数による）を第２の欄に含むリストである。セキュリティレベルをデータの判断された性質によって割り当てる他の方法も、本発明の範囲内で採用することができることが認められるであろう。
【０１５２】
図１７は、様々な形式のデータについて適切な暗号化強度を定義するポリシーデータの例示的な図を示す。ポリシーデータは、ポリシー・データ・ツリーの個別のブランチに配置されたいくつかのキー値の対の形を取る。キーは、パスワード、クレジットカード番号、提出されたキーワード、及び、任意の他の提出されたデータに対する一般キーのような送信されているデータの形式を指定する。これらのキーに対応する値が、キーで指定されたデータの送信に適切とみなされるビットによる暗号化強度である。キー値の対は、ポリシー・データ・ツリーの「ＴｒａｎｓｍｉｔｔｅｄＤａｔａＳｅｃｕｒｉｔｙ」ブランチの「ＲｅｑｕｉｒｅｄＥｎｃｒｙｐｔｉｏｎＬｅｖｅｌ」ブランチのいくつかのブランチに配置される。従って、この例において、パスワードは、４０ビットという目標とする暗号化強度を有し、会社クレジットカード番号及び個人のクレジットカード番号は、いずれも１２８ビットの目標とする暗号化強度を有し、提出されたキーワードは、４０ビットの目標とする暗号化強度を有し、他の提出されたデータは、暗号化を必要としないことが分るであろう。
【０１５３】
「ＳｕｂｍｉｔｔｅｄＫｅｙｗｏｒｄｓ」ブランチは、機密性であり何らかの形の暗号化を必要とすると指定された特定の語又はストリング又はテキストを参照する。これらは、ユーザ名、アドレス情報、財務情報、又は、「極秘」又は「秘密」などの予め選択された語としてもよい。提出されたキーワードは、それらが記憶されている表又はファイルを参照することによって検出することができる。
更に、ポリシーデータの各ブランチは、一般的な暗号化強度を与える代わりに、例えば異なるパスワード又はクレジットカード番号が各パスワード又は数字に固有の対応する暗号化強度と共に記載されている表を参照することができる。
【０１５４】
セキュリティ等級が割り当てられると、プラグイン・モジュールは、そのセキュリティ情報の送信のために、ウェブサーバを用いてウェブブラウザによって確立されたリンクのセキュリティを判断するためにウェブブラウザに質問するか、又は、電子メールによる送信の場合、ユーザ又はアプリケーションが決定した暗号化設定がメッセージに適用されることになる。一般的に、これは、送信用データを符号化するのに使用された暗号化アルゴリズムの暗号強度になる。このような送信詳細は、ウェブサービスプロバイダからの「電子ハンドシェイク」の一部としてウェブブラウザによって受信される。
【０１５５】
機密リンクは、通常、右下角の閉じたパッドロックアイコンの存在によって「ブラウザ」ウィンドウに表示される。ユーザは、アイコンをクリックしてハンドシェイクによって供給されたセキュリティのレベルを質問することができる。これを行う際には、ユーザは「ＡＳＳＬ」確保形式の通知（１２８ビット）を受信するであろう。この通知の第１の部分には、使用された暗号化の形式が説明され、第２の部分では暗号化強度が説明されている。プラグイン・モジュールは、セキュリティレベルが提案された送信に適当か否かの判断に使用することができるように、このデータをブラウザから自動的に取得するように実施される。同様に、電子メールメッセージの場合、プラグイン・モジュールは、ユーザ又はアプリケーションが設定した暗号化設定がメッセージの送信前に使用されるべきであると判断する。
【０１５６】
モジュールは、指定された暗号化強度をリンク又はメッセージの暗号化強度と比較し、比較の結果によって以下のアクションのうちの１つを実行する。
ａ）リンクのセキュリティが送信されている情報の性質に適切である場合、モジュールは、情報が送信されることを可能にする。
ｂ）リンクのセキュリティが情報の送信に必要とされるものを上回る場合、モジュールは、そのセキュリティレベルで情報が送信されることを可能にするか、ウェブサーバ及びウェブブラウザと新しい適切なセキュリティレベルを自動的にネゴシエートしてそのレベルで情報を送信するか、又は、現在のセキュリティレベルは不要であることをユーザにプロンプト表示し、アクションを起こすようにユーザを促す。
ｃ）リンクのセキュリティが送信されている情報の性質には十分でなかった場合、モジュールは、送信が行われるのを防止してユーザに警告するか、ウェブサーバ及びウェブブラウザと新しい適切なセキュリティレベルを自動的にネゴシエートしてそのレベルで情報を送信するか、又は、電子メールの場合、暗号化強度の設定を自動的に上げるか、又は、現在のセキュリティレベルが不十分であることをユーザにプロンプト表示し、まだ送信の実行を希望するかどうかの確認をユーザに促す。
【０１５７】
プラグイン・モジュールは、決められた目標とするセキュリティレベルの差に応じるように構成し得ること、いくつかの方法で準備されること、及び、上記で概説したアクションは例示的なものにすぎないことが認められるであろう。
システムが取り得る更なるアクションには、異なるウェブページがユーザのマシンにダウンロードされるように要求すること、又は、機密性情報が送信されないように、提出されたフィールドデータを変更することが含まれるであろう。
【０１５８】
好ましいシステムのユーザによって送信されているデータをモニタするためのブラウザ又は電子メールプラグイン・モジュールの作動が、参照すべき図１８に示されている。モジュールは、段階Ｓ３２０において、ウェブサーバにデータが送信される直前に図３のポイントＣで、又は、電子メールが送信される直前に図５のポイントＢで作動を開始する。次に、制御は段階Ｓ３２２に移り、モジュールは、送信されようとしているデータの構文解析をしてクレジットカード番号を捜す。これを行う可能な方法は、図を参照して上述した通りである。データ内でクレジットカード番号が検出されなかった場合、制御は段階Ｓ３１４に移り、モジュールは、まさに送信されようとしているデータ内でパスワードを捜す。これを行うための方法は、図６を参照して上述した通りである。データ内にパスワードが見つからなかった場合、制御は段階Ｓ３１６に移り、モジュールは、データ内で会社アカウント又は購入コードを捜す。アカウント又は購入コードの認識は、ファイル内に会社のコードを記憶してこれらのコードを発信データ内に見つかる桁のストリームのいずれとも対照させるように試みることによって達成することができる。アカウントコードが見つからなかった場合、制御は段階Ｓ３１８に移り、モジュールは、送信されるデータ内の他の機密性データの指示を捜す。このような指示は、好ましくは検出に使用された個別のファイルで予め定義する必要があることになり、好ましいシステムのユーザの要件に依存することになる。この例には、会社が着手しているプロジェクトに関係する指定されたキーワード、プロジェクト表題自体、データ受信者又は送信者の個人的な詳細アドレス、又は、データ自体に含まれる「極秘」又は「私用」という語でさえも含まれるであろう。
【０１５９】
データが機密性であり、送信される前により強い保護を必要とするという指示が何も見つからなかった場合、送信は、現在の暗号化レベルで続行することが許可される。これは、いかなる暗号化も適用されることなく送信が行われることを意味するであろう。
しかし、段階Ｓ３２２から段階Ｓ３２８までにおける検査のいずれでも機密性とみなされるデータが明らかにならなかった場合、制御は段階Ｓ３３２に移り、セキュリティ等級が検出されたデータに割り当てられる。これは、検出されたデータをポリシーデータの所定のエントリと比較することによって達成される。
【０１６０】
ポリシーデータのブランチの各エントリは、そのデータの送信に使用することができる最小レベルである予め割り当てられた暗号化レベルを有する。全てのポリシー設定と同様に、表内のエントリ及び割り当てられた暗号化レベルは、好ましいシステムを使用する会社によりその要件に基づいて決定される。こうして、セキュリティ等級を割り当てることは、単に、パスワード、クレジットカード番号、又は、ポリシーデータ内の他のデータを調べ、対応する等級を読み取るということになる。ポリシーデータのサブブランチ上の表への参照を用いて、異なる暗号化強度を異なるパスワード及びクレジットカード番号などに割り当てることができる。
【０１６１】
適切なセキュリティレベルが段階Ｓ３３２において判断されると、制御は段階Ｓ３３４に移り、モジュールは、データが送信されているウェブサーバとネゴシエートされた暗号化レベルか、又は、メッセージを送信する前に電子メールアプリケーションによって使用されることになる暗号化レベルを判断する。これは、ウェブブラウザ又は電子メールアプリケーションに質問するか、又は、両方とも送信前に発生することになるリンクの確立又は電子メール暗号化要件の判断の時に暗号化強度変数を設定することにより達成することができる。
【０１６２】
次に、制御は段階Ｓ３３６に移り、目標とするセキュリティレベル、すなわち、暗号化強度が前段階において決定されたものと比較される。目標とする暗号化レベルが段階Ｓ３３４で決定されたものに等しいか又はそれ以下であった場合、送信されるデータに対する十分な保護があるとみなされ、制御は終了段階Ｓ３３０に移り、そこでモジュールはフローから出る。段階Ｓ３３０の後、制御は、モジュールがウェブブラウザ又は電子メールクライアントで実行されるかによって、図３のポイントＣ又は図５のポイントＢに戻る。その後、データの送信は、通常の方法で進行することができる。
【０１６３】
しかし、段階Ｓ３３６において、目標とする暗号化レベルが現在設定されているものを上回る場合、モジュールは、適切な暗号化レベルがネゴシエートされるまで送信の進行を可能にしない。制御は段階Ｓ３３８に移り、モジュールは、暗号化強度を上げることができるか否か判断し、暗号化強度を上げることができる場合は、制御は段階Ｓ３４０に移り、新しいより強力な暗号化されたリンクがネゴシエートされるか、又は、電子メールの場合にはより高い暗号化強度が設定される。
【０１６４】
利用可能な最高暗号化レベルは、ウェブサーバ及びウェブブラウザの両方、又は、電子メールの場合には電子メール送受信アプリケーションによって使用されているソフトウエアに依存する。そこで、適切な暗号化レベルが一方の当事者には利用可能ではなく、データの送信を進めることが決して許可されないという場合があり得る。更に、いくつかの形式のデータには、いかなる暗号化レベルもデータの保護には決して十分ではないことを示すようなセキュリティ等級が与えられる場合があり、すなわち、そのデータの送信が永久に妨げられる。
【０１６５】
リンクの再確立を試行するか、又は、電子メール暗号化設定をより高い暗号化強度に変更した後に、制御は、リンク又は設定が現在は適切な強度であることを保証するために段階Ｓ３３４に戻る。段階Ｓ３３８において適切な暗号化レベルを再ネゴシエートすることができなかったか、又は、暗号化強度を上げようとする試行が失敗に終わった場合、データを送信することは安全ではないとみなされ、制御は終了段階Ｓ３４２に移り、そこでモジュールはフローから出る。段階Ｓ３４２でフローから出た後、制御は、ユーザが送信を再検討して編集するか又は破棄するように、図３のポイントＡか、又は、図５の段階Ｓ１３２の「ｃｏｍｐｏｓｅ ｅ−ｍａｉｌ」に戻る。送信が防止される理由を説明する適切なメッセージもまたユーザに表示することができる。
従って、好ましいシステムは、データの送信ができるだけ安全であるように保証する方法を提供する。それは、ユーザが送信を機密にするのを忘れるという可能性を排除し、使用されるセキュリティレベルが不十分な場合はより適切なセキュリティレベルをネゴシエートする。
【０１６６】
「ウェブブラウザ」は、ユーザによって入力されたデータが安全でないリンクで正に送られようとしていることをユーザに警告する類似の機能を提供するか、又は、全てのメッセージを初期設定で暗号化する機能を提供することができる。しかし、好ましいシステムは、送信されるデータの内容を検査してそのセキュリティ要件を判断する能力を提供し、このようなセキュリティ要件、及び、判断されたリンクのセキュリティレベル（暗号化強度）に基づいて、送信を許可又は防止する。好ましいシステムは、人的エラーの可能性を低減する安全な送信のための大幅に改良されたシステムを提供することが認められるであろう。
【０１６７】
機密性情報に対する発信電子メールのモニタリング
機密性データが送信者と受信者との間で第三者によって妨害されるという問題に加えて、組織は、そのユーザによる機密性情報の故意の公開によりかなりの危険に晒されている。例えば、組織から退職する前に顧客リストのような極秘文書のコピーを「電子的に」盗むという方法は、容易に達成されて事実上追跡不可能であり、その結果広く行われている。ユーザにとって必要なことは、後で検索するために文書を自分の私用電子メールアドレスに送ることだけである。文書は、「ホットメール」などの「インターネット」のメールサービスを使用できるので、組織独自の電子メールシステムを通じて送ることさえしなくてもよく、無許可の「リーク」の追跡を現行の手段によっては事実上不可能にしている。
【０１６８】
適切な暗号化レベルがメッセージに適用されることを保証する手段をもたらすだけでなく、好ましいシステムは、潜在的に機密性と識別されたメッセージをユーザが知らないうちに自動的に再方向付けするか、又は、別の宛先にコピーすることを可能にする。このようなメッセージを再方向付けするか否かを判断する際には、好ましいシステムは、送信者の身元、意図された受信者の身元、意図された受信者のアドレスの性質、メッセージ内容の性質、メッセージに対するあらゆる添付ファイルの性質及び存在、メッセージが送信されるように意図された手段、及び、メッセージ及び／又はあらゆる添付物を暗号化するか否かを含むいくつかの要素を考慮に入れる。
【０１６９】
メッセージの性質は、１つ又はそれ以上のキーワード又はキーワードの組合せがないか走査することによって、又は、標準的な「自然言語クエリー」技術を使用することによって判断することができる。意図された受信者のアドレスの性質は、公知の「インターネット」メールサービスドメインのリストを参照することによって判断することができる。例えば、「ｈｏｔｍａｉｌ．ｃｏｍ」、「ｙａｈｏｏ．ｃｏｍ」、及び、「ａｏｌ．ｃｏｍ」は、全てが企業ではなく個人によって広く使用されている。同様に、アドレスは、送信者名との類似性がないか検査することができ、例えば、フレッド・スミスによってアドレス「ｓｍｉｔｈ９００＠ａｏｌ．ｃｏｍ」に送られたと分っているメールは、受信者アドレス内に「ｓｍｉｔｈ」及び「ａｏｌ．ｃｏｍ」の両方が含まれていることよって怪しいと考えることができる。メッセージの更なる検査は、メッセージが極秘データの無許可の公開である可能性を支持する場合があり、例えば、メッセージがメッセージテキスト及び件名が未記入の添付ファイルのみから成る場合、送信者は自分が単に読むだけのテキストを入力する可能性は低いので重要な手かがりとなる。メッセージが送信されている時の手段は重要な要素であり、例えば、ホットメールなどの「インターネット」メールサービスを使用して送られた送信は、通常の企業レベルの電子メールシステムを通じて送られたものよりもはるかに怪しいと考えることができる。
実際に「インターネット」メールサービスへのファイルの「アップロード」は潜在的に非常に怪しいので、好ましい実施形態は、このようなサービスへのファイルのアップロードを全く禁止する手段を提供する。
【０１７０】
メールを再方向付けする時に、好ましいシステムは、新しい受信者が自分に再方向付けされたということ、及び、誰に元々送られたのかを判断することができるように、本来意図された受信者のアドレスと共に、更なるテキスト、例えば「−−−−Ｒｅｄｉｒｅｃｔｅｄ Ｍａｉｌ−−−−」をメールの始めに追加する。
転送されたメッセージを暗号化すべきである場合、好ましいシステムは、第三者に対して暗号化又は暗号化されていないメッセージを再方向付けすることができる。好ましくは、送信者の暗号化キーがメッセージと共に送られ、第三者に対して、既に暗号化されている場合にはメッセージを暗号解読し、送信のために本来の送信者の暗号化キーでメッセージを暗号化する手段が提供される。
【０１７１】
好ましいシステムはまた、「−−−−Ｒｅｄｉｒｅｃｔｅｄ Ｍａｉｌ−−−−」テキストを捜すことによって、再方向付けされた（すなわち、本来意図された受信者ではないユーザに送られた）着信メールを識別する。このようなメールには、新しい受信者の注意を喚起するために、特別なアイコンを使用することにより、又は、本人に通知するためのメッセージボックスを設置することによりフラグを付けることができる。また、新しい受信者が容易にメッセージを「承認」して、本来意図された受信者に送ってもらうことを可能にする手段を提供することができる。これは、例えば「承認」ボタンを設けることによって達成することができる。このボタンが押された場合、好ましいシステムは、ユーザが通常の「転送」ボタンを押した場合と同じ方法で新しいメッセージを作成する。しかし、「承認」ボタンの場合は、転送されたことを注記するためにテキストをメッセージに追加するのではなく、本システムは、本来意図された受信者リストをメッセージから抽出し、再方向付けに関する詳細を剥ぎ取ってメッセージを元の状態にする。次に、宛先フィールド「Ｔｏ」、「Ｃｃ」、及び、「Ｂｃｃ」には、抽出された元の受信者アドレスが自動的に記入され、「Ｆｒｏｍ」フィールド（通常は表示されない場合でも全てのメッセージに対して存在する）には、元の送信者の名前／アドレスが記入される。また、日付／時刻フィールドは、元のメッセージの日付／時刻に調節することができる。次に、メッセージは、自動的に又はユーザが「Ｓｅｎｄ」ボタンを押した時に送られる。このように、ボタン１つ又は２つのみを押せば、再方向付けされたメールを承認して送ることができ、配信時には、再方向付けが何も行われなかったかのように、元の受信者から来たように見えることになる。
【０１７２】
メールを再方向付けするために実行されたプラグイン・モジュールの作動を制御するためのサンプル・ポリシーデータを図１９に示し、このようなプラグイン・モジュールの作動の概略図を図２０に示す。図１９は、図２０の判断段階に対応するいくつかのブランチを有するポリシー・データ・ツリーである。
プラグイン・モジュールは、図５の電子メールクライアント作動の図のポイントＢに対応する段階Ｓ３５０で開始される。開始されると、プラグイン・モジュールは６つの段階を通過し、発信電子メールメッセージの異なる詳細を判断する。まず、段階Ｓ３５１において、電子メールを送る者の身元が所定の名前又はアドレスリスト内のエントリに照らして検査される。このリスト上のユーザからの電子メールは、メッセージの内容にかかわらず、また、受信者にかかわらず、電子メールを直接意図された受信者に送信する権限を有するとみなされる。リスト上に記載されていない者は誰でも、その内容によって自分の電子メールが再方向付けされるか又はされない可能性がある。従って、判断段階Ｓ３５１において、ユーザ名又はアドレスがリスト上で見つかった場合、制御は段階Ｓ３６４に移り、電子メールを更なる対話なしに送信することが許可される。しかし、ユーザがリスト上で見つからなかった場合、制御は、更なる検査を行うために段階Ｓ２５３に移る。段階Ｓ３５２において、発信電子メールメッセージの受信者は、図１９に示すポリシーデータの受信者ブランチ上に指定されたルックアップ表ｓに照らして検査される。次の判断段階Ｓ３５４において、電子メールメッセージを含むテキスト及び電子メールメッセージに添付されたあらゆる添付物は、ルックアップ表ｔ内のエントリと比較される。表ｔは、ポリシーデータの「キーワード」ブランチ上で参照され、電子メールメッセージの性質が会社にとって機密であり得ることを示す語を含む。次の段階Ｓ３５６において、電子メールメッセージは、暗号化すべきであるか否かを確認するために検査される。暗号化は、電子メールが送信される瞬間まで発生せず、従って、この段階では電子メールに単に暗号化のフラグが付けられることになる点が留意される。次の判断段階Ｓ３５８において、電子メールメッセージが添付物を含むか否か、及び、次の判断段階Ｓ３６０において、電子メールメッセージが添付物に伴うテキストを含むか否か、すなわち、電子メールメッセージの本文テキストが未記入か否かが判断される。
【０１７３】
ルックアップ表が調べられる判断段階Ｓ３５２、Ｓ３５４、又は、Ｓ３６２のいずれかにおいて、ルックアップ表内のエントリと電子メール内のエントリとの照合により、電子メールが、会社外に送られる前に検査用に第三者に再方向付けされるべきであることが示される。例えば、段階Ｓ３５４において電子メールが「極秘」又は「秘密」という語を含むと判明した場合、それは、電子メールが意図された受信者に配信される前に第三者によって検査されることを正当化するのに十分であることになる。これによって、会社が知ることなく機密性情報が社外に送られないことが保証される。従って、制御は、これらの段階から段階Ｓ３６４に流れ、電子メールが再方向付けされたことを示すテキストがメッセージに追加され、受信者アドレスは、再方向付けされたメッセージの送信先である確認する当事者のアドレスに変更される。次に、制御は段階Ｓ３６６に移り、そこで電子メールは送信される。電子メールメッセージが再方向付けされるようにマークされていた場合、段階Ｓ３３６において、それは、勿論メッセージの元の受信者ではなく、確認する当事者に検討のために送信されることになる。
【０１７４】
判断段階Ｓ３５６において、メッセージの暗号化が検出された場合、それは、検討されるようにメッセージを第三者に再方向付けすることを正当化するのに十分であるとみなされる。従って、メッセージが暗号化される場合、制御は、段階Ｓ３５６から段階Ｓ３６４に移り、メッセージが再方向付けされるように修正される。暗号化されるようにフラグ付けされたメッセージの場合、メッセージが暗号化されることなく再方向付けされ、新しい受信者がメッセージを読むことができるように、暗号化フラグが除かれることが好ましい。また、メッセージに追加された再方向付けテキストは、メッセージを送信前に再暗号化することができるように、暗号化キー（一般的に意図された受信者の一般キーであり、従って、機密に属さない）を含むことが好ましい。
代替的に、意図された受信者の「デジタル証明書」全体を再方向付けされたメッセージと共に含めることができるであろう。その後、一般キー又は証明書は、場合によっては上述の自動化された承認処理によって除去されることになる。
【０１７５】
段階Ｓ３５８において、電子メールが添付ファイルを含んでいなかった場合、電子メールは、潜在的に機密に属する情報を有する文書又はファイルを含む可能性はないとみなされ、従って、段階Ｓ３６４において、一切の干渉なしに電子メールを送信することが許可される。電子メールが確かに添付物を含み、段階Ｓ３６０において、電子メールがメッセージの本文又は件名に入力されたテキストを含まないと判断された場合、メッセージは、その送信者の異なるアカウントに送られる可能性が高いものとして認識される。その電子メールは、次に段階Ｓ３６２及びＳ３６４において、検査されるように第三者に転送される。
【０１７６】
図２１は、会社のコンピュータシステムから外部サイトへの情報のアップロードを阻止するためのプラグイン・モジュールの作動を示す。単純な２段階の検査が用いられ、それは、段階Ｓ３７０での開始に続く段階Ｓ３７２における外部サイトアドレスの検査と、段階Ｓ３７４においてアップロードされている情報内の機密キーワードの検査とを含む。段階Ｓ３７２において外部サイトアドレスは禁止されたサイトではないと判明し、かつ、段階Ｓ３７４において機密キーが検出されないことを条件として、段階Ｓ３７６において、アップロードが進行することが許可される。そうでない場合は、段階Ｓ３７８において、アップロードは阻止される。
情報のアップロードを選択的に阻止するプラグイン・モジュールの作動を制御するためのポリシーデータは複雑なものではなく、図１９の下部に示されている。
このように、会社の利益にならない理由で送信されている機密性情報を含む発信伝送は、送信前に確認することができ、必要に応じて送信を防止することができる。
【０１７７】
電子メールの転送の管理
電子メールアプリケーションは、着信メールを１つ又はそれ以上のユーザに「転送」するための手段を提供する。ユーザは、通常「転送」ボタンをクリックし、それによって、あたかもユーザが自分でキー入力したかのように、着信メールのコピーが自動的にメール構成ウィンドウに入力される。その後に必要なことは、ユーザが転送されるメールの意図された受信者の名前を入力して「Ｓｅｎｄ」ボタンをクリックすることだけである。これは、ユーザが容易に受信メールの内容を他人と共有することを可能にする有用な特徴である。
【０１７８】
しかし、機密性の情報を含むメールの場合、特にメールの機密性の性質が直ちに明らかではない場合、例えばユーザがそれを読むために閲覧ウィンドウをスクロールダウンすることが必要とされるような機密性の情報がメールの下の方に表示されている場合には、問題が起きる可能性がある。ユーザは、特に処理する電子メールが多い時には、最初の数行のみ、場合によっては件名行のみをざっと見た後に電子メールを転送することが多い。その結果、機密性の情報が組織内で、更に危険なことには組織外でうっかり開示されることが多い。その結果、これまでにかなりの金額が失われた注意を引く事例がいくつかある。
従って、好ましいシステムは、電子メールの転送を制御する手段を提供する。このような制御には、転送電子メールが送信される前にユーザに警告を発し、電子メールが転送されるのを完全に防止することが含まれる。送信前に電子メールを承認するか、又は、上述したように別のユーザに再方向付けする手段を提供することもできるであろう。
【０１７９】
転送は、電子メールの内容及び電子メールが既に送られたその受信者のアドレスによって発生することが好ましい。例えば、電子メールの機密性の性質は、「極秘」などのキーワードがないか走査することを含むいくつかの方法により、又は、機密性の属性が「個人的」、「私用」、又は、「極秘」に設定されているか否かを確かめることにより判断することができる。また、「＜ＮＯＦＯＲＷＡＲＤ＞」（転送を防止する）又は「＜ＮＯＦＯＲＷＡＲＤＥＸＴＥＲＮＡＬ＞」（組織外への転送を防止する）のような予め定義されたキー・ストリングを挿入することによって、メッセージの元の構成者が今後の転送には不適とマークするための手段を提供することができる。このような手段はまた、メッセージに対する追加の属性の形で提供することができるであろう。
【０１８０】
好ましいシステムは、内容に基づく要素に加えて、メッセージの以前の受信者のリストに問い合わせる。電子メールが既に元の構成者によって組織外に送られていた場合、例えば、それを更に外部に転送させることは安全であると考えてもよい。同様に、元の電子メールが単一の受信者のみに送られた場合、元の構成者は広く回覧させることを意図してはいなかったと判断してもよく、適切な警告を出すことができるであろう。上述の要素に応じたアクション方針をポリシーに従って判断することができる。
【０１８１】
まさに送信されようとしている電子メールが転送電子メールであるという事実は、電子メールプログラムによって元のメールの始めに自動的に追加される「−−−−Ｏｒｉｇｉｎａｌ Ｍｅｓｓａｇｅ−−−−」などのキーストリングがないかどうか電子メールを走査することによってたやすく判断することができる。同様に、元のメッセージのストリングに続くキーストリング「Ｔｏ：」及び「Ｃｃ：」がないかを走査することによって以前の受信者のリストを判断することができる。受信者のリストは、これらのキーストリングの直後に見つけられる。内部及び外部の受信者は、ドメイン名（それがある場合）の参照によって区別することができる。例えば、「Ｆｅａｄ Ｓｍｉｔｈ」として示された受信者名は、一般的に内部のものであり、「ｆｓｍｉｔｈ＠ｘｙｚ．ｃｏｍ」は一般的に外部のものである。
【０１８２】
電子メールメッセージの転送を制御するために実行されるプラグイン・モジュールの作動を命令するためのポリシーデータを図２２に示し、このようなモジュールの作動を図２３に示す。
ポリシー・データ・ツリーは、コマンド値を設定することができるパラメータを指定するいくつかのサブブランチを含む。例えば、「ＹＥＳ」に設定された時の第１のサブブランチ「ＰｒｅｖｅｎｔＡｌｌ」は、全ての電子メールが転送されるのを防止されるようにモジュールに命令する。「ＹＥＳ」に設定された時の次のサブブランチ「ＷａｒｎＡｌｌ」は、電子メールがまさに転送されようとしている時は常にモジュールに対して電子メールクライアントユーザに警告するように要求する。次の２つのサブブランチ「ＰｒｅｖｅｎｔＥｘｔｅｒｎａｌ」及び「ＷａｒｎＥｘｔｅｒｎａｌ」は、外部電子メールのみに対応するパラメータを含み、これらの２つのサブブランチによって、電子メールクライアントのユーザは、会社内の電子メール転送に影響を与える規則と会社外の人たちへの電子メール転送に影響を与える規則とを区別することができる。「ＰｒｅｖｅｎｔＫｅｙｗｏｒｄｓ」ブランチは、機密性の情報を示すキーワードが記憶されるルックアップ表を指定する。このようなキーワードは、「＜ＮＯＦＯＲＷＡＲＤ＞」又は「＜ＮＯＦＯＲＷＡＲＤＥＸＴＥＲＮＡＬ＞」などの予め定義されたキーストリング又は１つ又はそれ以上の予め定義された語とすることができる。
【０１８３】
電子メールは送信前に走査され、このようなキーワードが電子メールのテキスト又は電子メールのいずれかの添付物で見つかった場合、電子メールを転送することが許可されない。「ＹＥＳ」に設定された時の最後の２つのサブブランチ「ＰｒｅｖｅｎｔＩｆＮｏｔＳｅｎｔＥｘｔｅｒｎａｌｌｙ」は、以前に会社外に送信されたことがない場合には転送電子メールの会社外への送信を禁止する。実際には、転送電子メールは、会社内の受信者全員に送信することができ、外部の受信者は、単に受信者リストから削除されるか、又は代替的に、送信前に、アドレスリストに外部の受信者が含まれないように、ユーザに対してアドレスリストの修正を要求してもよい。
最後に、「ＹＥＳ」に設定された時の「ＰｒｅｖｅｎｔＩｆＳｉｎｇｌｅＲｅｃｉｐｉｅｎｔ」ブランチ上で設定されたパラメータは、メッセージの元の受信者が単一の個人であった場合には、あらゆる電子メールメッセージの転送を防止する。
【０１８４】
プラグイン・モジュールの作動を図２３に示す。プラグイン・モジュールは、段階Ｓ３８０において、ここでもまた図５のポイントＢで開始される。キーストリング「−−−−Ｏｒｉｇｉｎａｌ Ｍｅｓｓａｇｅ−−−−」は、転送用メッセージを生成した時に電子メールプログラムによって元のメールの始めに自動的に追加されるので、判断段階Ｓ３８２において、電子メールには、このキーストリングを含むか否かを確認するために予備走査が行われる。電子メールメッセージがこのキーストリングを含んでいなかった場合、電子メールメッセージは元のメッセージであり、転送されていないと推論することができ、段階Ｓ３８４においてメッセージを送信することができる。しかし、段階Ｓ３８２において、メッセージがキーストリング「−−−−Ｏｒｉｇｉｎａｌ Ｍｅｓｓａｇｅ−−−−」を含むと判明した場合、電子メールメッセージは、明らかに転送メッセージであり、モジュールは、更なる措置を講じて転送メッセージを送信することを可能にすべきか否かを判断する。次に、制御は段階Ｓ３８６に移り、その転送メッセージの受信者は、いずれかがオンライン会社外の者か否かに関して確認するために検査される。外部の受信者がいた場合、段階Ｓ３８８において、プラグイン・モジュールは、電子メールメッセージを走査してその電子メールが以前に会社外の受信者に転送されたことがあるか否か確認する。転送されたことがなかった場合、段階Ｓ３９０において、電子メールメッセージは転送が防止され、電子メールクライアントのユーザに通知される。しかし、電子メールメッセージが会社外に送られたことがあった場合、段階Ｓ３９２において警告がユーザに発せられ、その後、その電子メールメッセージはユーザにより送信されるか、又は、意図された受信者を改訂するためにユーザに返送することができる。
【０１８５】
段階Ｓ３８６において、転送メッセージが会社外のアドレスに送られるべきではない場合、制御は段階Ｓ３９４に移り、ユーザが元のメッセージの唯一の受信者であったか否かが判断される。そうであった場合、メッセージの元の構成者が多くの読み手に送信されることを意図していなかった事例と考えてもよい。従って、制御は段階Ｓ３９０に流れ、転送電子メールメッセージの送信は阻止される。これは、このような措置を取ることを指定する図２２に示すポリシーデータに従ったものである。代替的に、メッセージを転送しようとするユーザに警告を出すことができる。
【０１８６】
最終に行われる検査は、判断段階Ｓ３９６におけるものであり、そこでは、メッセージ及びメッセージに添付された内容がキーワード表のエントリと比較される。電子メール内のエントリと表内のエントリとの間の一致が見つかった場合、メッセージは、機密性情報を含むと考えられて転送されない。その後、モジュールは段階Ｓ３９０で終了する。機密性キーワードが見つからなかった場合、段階Ｓ３８４において、電子メールを転送することが許可される。
【０１８７】
発信伝送の署名の管理
「デジタル証明書」を使用してメッセージに署名する能力は、明らかに、送信者の身元を確立する際にはメッセージの受信者にとって、また、メッセージが改竄されていないことを保証する際には両当事者にとって貴重なものである。しかし、メッセージの送信者は、デジタル署名されたメッセージは、それが送られると拒否又は取り消すことができない潜在的に拘束力を有する契約になることを認識すべきである。従って、手書きの署名を紙製文書に付す時に注意するのとちょうど同じように、文書にデジタル署名する時にも注意することは絶対に必要にことである。マイクロソフト・コーポレーション製の「アウトルック」のような電子メールアプリケーションは、メッセージに自動的にデジタル署名する手段を提供し、これは、送信者の身元を確認する際には、受信者にとって上述した理由から貴重なものと考えられるが、また、潜在的に危険なものであり、ユーザは、メッセージ内容には極度の注意を払うことが要求される。
【０１８８】
好ましいシステムは、ポリシーデータに従って発信メッセージの署名を制御する手段を提供する。サンプル・ポリシーデータは図２４に示されており、このような制御には、以下のものが含まれる。
メッセージの署名を強制する、
メッセージの署名をユーザに示唆する、
メッセージに署名すべきでないことをユーザに示唆する、及び
メッセージの署名を防止する。
【０１８９】
どのアクション方針を取るかを決める際に、好ましいシステムは、メッセージ内容（あらゆる添付物を含む）の性質、意図された受信者の身元及び／又は所属組織、送信者の身元、使用されている「デジタル証明書」（署名するようにメッセージが既にフラグ付けされている場合）の性質、及び、メッセージに署名するのに利用可能な１つ又は複数の「デジタル証明書」の性質を含むいくつかの要素を考慮に入れる。
メッセージの性質は、１つ又はそれ以上のキーワード又はその組合せがないかメッセージを走査することによって、又は、標準的な「自然言語クエリー」技術を使用することによって判断することができる。同様に、意図された又は利用可能な「デジタル証明書」の性質は、証明書の発行人及び種類の参照によって判断することができる。
【０１９０】
図２５は、電子メールが適切にデジタル署名されるか又はデジタル署名されないように保証するためのプラグイン・モジュールの作動を示す。モジュールは、段階Ｓ４００において、図５に示す電子メールクライアントの作動におけるポイントＢで開始される。次に、制御は判断段階Ｓ４０２に移り、発信電子メールが、署名されるように既にマークされているか否かを確認するために走査される。メッセージの実際の「署名」は、送信直前まで発生しないことになる。署名されるようにマークされていなかった場合、制御は段階Ｓ４０４に移り、モジュールは、受信者ルックアップ表（表ｆ）を調べ、発信電子メールの受信者が電子メールが常にデジタル署名されるべき者と識別されているか否かを判断する。受信者が表ｆにあった場合、制御は段階Ｓ４０６に移り、電子メールクライアントのユーザは、電子メールがデジタル署名されない場合は送れないという通知を受ける。代替的に、プラグイン・モジュールは、電子メール作成者の「デジタル証明書」を使用して電子メールに自動的にデジタル署名することができる。
【０１９１】
段階Ｓ４０４において、発信電子メールの受信者がルックアップ表で見つからなかった場合、制御は段階Ｓ４０８に移り、次に、ポリシーデータの「ＥｎｆｏｒｃｅＳｉｇｎｉｎｇ」ブランチの「ＫｅｙｗｏｒｄｓＴａｂｌｅ」が調べられる。仮に表ｇのキーワードのいずれかが電子メールのテキスト、又は、電子メールの添付物のいずれかで見つかった場合、電子メールのデジタル署名が必要であることになり、制御は、前と同じように段階Ｓ４０６に移る。判断段階Ｓ４０４及びＳ４０６は、ポリシーデータの「ＥｎｆｏｒｃｅＳｉｇｎｉｎｇ」ブランチ上のルックアップ「受信者」及び「キーワード」表を調べるためのルックアップ・コマンドに対応することが認められるであろう。
このようなキーワードは、図２４に示すような「極秘」、「秘密」、「契約」、「見積り」、及び、「注文」などの所定の語とすることができる。
【０１９２】
電子メールの受信者が表ｆで見つからず、また電子メールが表ｇに指定されたキーワードを含まなかった場合、制御は、サンプル・ポリシーデータの「ＳｕｇｇｅｓｔＳｉｇｎｉｎｇ」ブランチ上のルックアップ・コマンドに対応する判断段階Ｓ４１０に移る。判断段階Ｓ４１０において、受信者のアドレスは、電子メールの署名が勧告されているか否かを判断するために、ルックアップ表ｈ内のものと比較される。受信者の名前が表ｈで見つかった場合、制御は段階Ｓ４１２に移り、電子メールクライアントのユーザは、発信電子メールメッセージにデジタル署名することが望ましいことを通知される。しかし、電子メールクライアントのユーザは、電子メールメッセージにデジタル署名することを要求されず、電子メールは、従って、ユーザが署名なしで電子メールを送信することを選択した場合にはそのように送信されてもよい。判断段階Ｓ４１０の後、受信者の名前が表ｈで見つからなかった場合、制御は判断段階Ｓ４１４に移り、前と同じように電子メールテキストは、機密性のデータを含んでデジタル署名が必要であることを示すようないくつかのキーワードがないか検索される。電子メールがこのような機密性キーワードを含むか否かにより、電子メールクライアントのユーザは、段階Ｓ４１２において、メッセージにデジタル署名をすることが望ましいことを通知されるか、又は、代替的に、電子メールメッセージは、段階Ｓ４１６において署名なしで送信される。
【０１９３】
プラグイン・モジュールの開始に続く段階Ｓ４０２において、電子メールが署名に関してマークされていることが判明した場合、制御は判断段階Ｓ４１８に移る。判断段階Ｓ４１８において、プラグイン・モジュールは、ポリシーデータの「ＤｅｎｙＳｉｇｎｉｎｇ」ブランチの下で指定された「ＤｅｎｙＳｉｇｎｉｎｇ」ブランチ内のルックアップ表ｍを調べる。表ｍは、「ＤｅｎｙＳｉｇｎｉｎｇ」ブランチの下の「ＣｅｒｔｉｆｉｃａｔｅｓＵｓｅｄ」ブランチ上で指定されており、発行人、形式、証明書番号、又は、該当するとみなされる「デジタル証明書」の署名キーを指定する。仮に発信電子メールに署名するために使用されるべきデジタル署名又は署名キーが表ｍで見つかった場合、メッセージに署名すること又は署名しないことが適切なのかを判断するために、「受信者」及び発信電子メールの性質に関する更なる検査が行われることになる。制御は段階Ｓ４２０に移り、発信電子メールの受信者が受信者表と比較され、次に判断段階Ｓ４２２に移り、電子メールのテキスト及びあらゆる添付物が様々なキーワードがないかに関して走査される。判断段階Ｓ４２０又はＳ４２２にいずれかにおいて、受信者又はメッセージのいずれかのテキストがルックアップ表で定義されたものと一致した場合、制御は段階Ｓ４２４に移り、電子メールの送信が阻止される。次に、電子メールクライアントのユーザは、電子メールテキスト入力段階に戻され、メッセージをデジタル署名することなく再送信するように要求されてもよい。
【０１９４】
段階Ｓ４１８又はＳ４２２のいずれかにおいて、証明書又は署名キーが当該のものではないと判明し、かつ、電子メールのテキストがいかなる機密性の語も含んでいなかった場合、制御は、ポリシー・データ・ツリーの「ＳｕｇｇｅｓｔＮｏｔＳｉｇｎｉｎｇ」ブランチ上の第１のサブブランチに対応する段階Ｓ４２６に移る。ポリシー・データ・ツリーの「ＤｅｎｙＳｉｇｎｉｎｇ」ブランチに関して、３つの判断段階Ｓ４２６、Ｓ４２８、及び、Ｓ４３０は、それぞれ、ルックアップ表ｊ、ｋ、及び、ｌの所定の機密性エントリに照らして、電子メールと共に使用された「デジタル証明書」又は署名キー、発信電子メールの受信者、及び、発信電子メールのテキストを検査するためのルックアップ・コマンドに対応する。段階Ｓ４２６において、発信電子メールに署名するのに使用された証明書が当該のものであると判明し、かつ、段階Ｓ４２８又は段階Ｓ４３０のいずれかにおいて、受信者又は発信電子メールのテキストが指定されたルックアップ表内のエントリに一致すると判明した場合、制御は段階Ｓ４３２に流れ、電子メールクライアントのユーザは、発信電子メールメッセージにデジタル署名しないことが望ましいことを通知される。しかし、そのユーザは、それでも尚署名された電子メールメッセージを送りたい場合には自由にそうすることができる。
判断段階Ｓ４２６、Ｓ４２８、及び、Ｓ４３０のいずれにおいても一致が見つからなかった場合、電子メールは、段階Ｓ４１６で通常通り送られる。
【０１９５】
インスタントメッセージング及び電話技術アプリケーション
「インスタントメッセージング」（「チャット」としても知られている）及びデジタル電話技術関連用途（「ボイス・オーバー・ＩＰ」など）のような更なる応用は、ブラウザ及び電子メールの活気に加えて、現在のビジネス状況において人気を得てきている。「インスタントメッセージング」規格は、「ＲＦＣ」の２７７８及び２７７９において、また、「ＩＥＴＦ ＳＩＭＰＬＥ」作業グループによって定義されている。「ボイス・オーバー・ＩＰ」規格は、「ＩＴＵ−Ｔ勧告Ｈ．３２３」（１９９８年）に定義されている。本発明の多くの態様は、このようなアプリケーションで送受信されたデータに適用することができる。「インスタントメッセージング」は、概念的には、「会話」が両当事者が一貫して存在する「ライブ」で行われる点を除き、一連の送受信電子メールと類似のものである。しかし、本発明の目的に対しては、その手順は全く同じものである。図５は、段階Ｓ１２２、Ｓ１２４、Ｓ１３２、及び、Ｓ１３４内の語電子メールを「Ｍｅｓｓａｇｅ」という語と入れ換えることによって「インスタントメッセージング」を表すことができる。「Ｅ−ｍａｉｌ Ｓｅｒｖｅｒ」の説明９５は、「Ｍｅｓｓａｇｅ Ｒｅｌａｙ」と入れ換えられる。好ましい実施形態は、「インターネット・メッセージング」アプリケーションとのプラグインを準備することにより、又は、プラグインの機能性を含む「インスタントメッセージング」アプリケーションを開発することにより、前と同じようにポイントＡ及びＢで割り込むように構成される。代替的に、この割り込みは、プロトコルレベルで発生することができ、ネットワークパケットがユーザマシンから出る前か、又は、ネットワークパケットがユーザマシンに到達した時か、又は、ネットワーク上のある中間点においてネットワークパケットに割り込むことが認められるであろう。
【０１９６】
「ボイス・オーバー・インターネット・プロトコル」（ＶＯＩＰ）は、概念的には、メッセージ内容が符号化されて直ちに送信されるデジタル化された発話から成る点を除き、「インスタントメッセージング」と類似のものである。メッセージ内容の解析は非現実的であるが、メッセージを記録して「呼出し」レベルで制御を行う手段は実行可能であり、音声メッセージング・アプリケーションへのプラグインとして、又は、ユーザマシン内又はネットワーク上のある中間点のいずれかにおけるネットワーク・プロトコル・レベルにおいて、類似の方法で実施される。
【０１９７】
好ましいシステムの実施について既存のアプリケーションに対するプラグイン・モジュールに関連して説明されたが、本発明は、本明細書で説明したプラグイン・モジュールの機能性が既に最初からコード化されているウェブブラウザ、電子メールクライアント、「インスタントメッセージング」アプリケーション、又は、「ボイス・オーバー・ＩＰ」アプリケーションを準備することにより実施されてもよい。
【技術分野】
【０００１】
本発明は、特に情報セキュリティ、取引監査及び報告、中央集中型ポリシー、及び、アプリケーション接続性の領域において、「インターネット」アプリケーションに対する拡張管理機能性を提供することに関する。
【背景技術】
【０００２】
特に企業間（Ｂ２Ｂ）、また、企業・消費者間（Ｂ２Ｃ）での電子商取引（ｅＣｏｍｍｅｒｃｅ）は、郵便、電話、及び、個人的な面談などのこれまでの手段ではなく、リンクしたコンピュータシステムから成る世界的なネットワークである「インターネット」を使用して買い手及び売り手が通信する、急速に成長している市場である。売り手は、「インターネット」への接続、「ワールド・ワイド・ウェブ」上のページ、又は、一般的に特定の市場部門の品物及びサービスを商う電子市場を通じて閲覧又はダウンロードすることができるデジタル小冊子及びカタログを使用して製品及びサービスを宣伝する。買い手は、全て電子的に、またいつでも、供給業者を捜し、品物を選択し、見積りを取得し、注文をしてそれを追跡し、支払いさえも行うことができる。「ｅＣｏｍｍｅｒｃｅ」によって、調達経費の大幅な軽減による柔軟性、選択性、及び、効率の向上が約束される。
【０００３】
ユーザを「インターネット」に接続する世界的に容認されている方法は２通りある。その１つは「ウェブブラウザ」であり、これによって、ユーザは、個々のウェブサイトにアクセスすることにより「ワールド・ワイド・ウェブ」上のページを閲覧することができ、そのアドレスは、一般的にこれまでの手段を使用して広く公開されているか、又は、別のウェブサイトで参照される。最も広く採用されているウェブブラウザは、マイクロソフト・コーポレーション製の「インターネット・エクスプローラ」である。
【０００４】
第２の接続手段は、「電子メール」プログラムを使用することであり、これによって、ユーザは、「ｅ−ｍａｉｌ」として公知のメッセージを作成し、これは、次に「インターネット」上で意図する受信者のアドレスに電子的に経路指定される。よく知られている「電子メール」プログラムには、ＩＢＭ・コーポレーション製の「ロータス・ノーツ」、及び、マイクロソフト・コーポレーション製の「アウトルック」が含まれる。
【０００５】
一般的な「ｅＣｏｍｍｅｒｃｅ」のシナリオにおいては、買い手は、売り手のウェブサイト上で価格設定及び配達情報と共に、特定の製品を特定すると考えられる。買い手は、次に、ウェブサイト上の電子注文書式に必要事項を記入するか、又は、売り手に直接「電子メール」を送ることによって注文する。注文には、一般的に、恐らくは「クレジットカード」に関する詳細事項という形か、又は、何らかの電子支払い手段による支払いの約束が含まれることになる。次に、売り手は、一般的に返信電子メールを送って受注を確認する。
【０００６】
「ウェブブラウザ」は、認定された各種の規格、特に「インターネット」規格文書「ＲＦＣ２６１６」で詳細に記載されている「ハイパーテキスト・トランスファープロトコル（ＨＴＴＰ）」に従って作動する。「電子メール」プログラムは、認定された各種の規格、特に「インターネット」規格文書「ＲＦＣ０８２１」で詳細に記載されている「シンプルメール・トランスファープロトコル（ＳＭＴＰ）」、及び、「インターネット」規格文書「ＲＦＣ２０４５−２０４９」で詳細に記載されている「多目的インターネットメール拡張仕様（ＭＩＭＥ）」に従って作動する。
【０００７】
「ｅＣｏｍｍｅｒｃｅ」は莫大な利点をもたらすが、その採用は、多くの新しい問題になっており、特に最終的にこれまでの方法に取って代わろうとする場合、その継続的な採用を確保するためにこれらの問題に対処しなければならない。重要問題の１つは、セキュリティである。
「インターネット」は、開放型通信ネットワークであり、それは、誰でも使用することができることから定義上安全性に欠けるものである。「インターネット」上で交換される機密性情報（例えば、「ｅＣｏｍｍｅｒｃｅ」取引において）を保護する手段は、確実な送信プロトコル及びメッセージ処理の採用によってこれまでに実現されている。例えば、ウェブ「サーバ」とウェブ「ブラウザ」との間で使用されている確実な点間送信プロトコルには、ネットスケープ・コミュニケーションズ・コーポレーションによって定義されている「セキュア・ソケット・レイヤー（ＳＳＬ）」、及び、「インターネット」規格文書「ＲＦＣ２２４６」で定義されているその継承プロトコル「トランスポート・レイヤー・セキュリティ（ＴＬＳ）」が含まれる。確実な電子メールメッセージ規格には、「インターネット」規格文書「ＲＦＣ２６３３」で詳細に定義されている「機密性多目的インターネットメール拡張仕様（Ｓ／ＭＩＭＥ）」、及び、フィリップ・チマーマンによって開発された公有機密性メッセージ処理システム「プリティ・グッド・プライバシー」が含まれる。
【０００８】
「インターネット」に接続されたサーバ上の情報へのアクセスを管理するために、ユーザ名及びパスワードから成るシステムが広く採用されている。例えば、特定のウェブサーバ上の割引価格リストへのアクセスは、アクセスを許可するユーザ名及びパスワードを過去に提示した取引上のユーザに制限することができる。同様に、オンライン情報サービスでは、一般的に、そのサービスに対して支払いがあった者にアクセスを制限するためのユーザ名及びパスワードが広範囲に使用されている。各ユーザに独特なユーザ名及び変更可能なパスワードを与えることによって、そのサービスにより支払済みの加入者のみがシステムにアクセスすることができるようにすることができ、ユーザは、そのサービスによって記憶された個人的データへの他人によるアクセスを防止することができる。
【０００９】
「ｅＣｏｍｍｅｒｃｅ」の用途において、重要な問題は、身元及び信頼性という問題である。供給業者が「インターネット」を通じて注文を受信した時、その顧客に関する事前の知識を有していないことは全くあり得ることであり、おそらくありそうなことである。供給業者は、顧客が、ａ）自分で言っているその本人であること、換言すると、誰かが他の誰かに成りすましているのではないこと、及び、ｂ）信頼することができ、提供する品物又はサービスに対して最終的に支払いをする意志が有ることを立証しなければならない。これらの問題は、「Ｂ２Ｃ」市場では、これまでは主としてクレジットカードを使用して対処されている。顧客は、自分のクレジットカード番号及び住所を注文と共に提示し、次に、供給業者はクレジットカード会社に確認し、その料金に対する許可を取得する。この処理全体は、人間の介入がなく、一般的に全くオンライン上で行われる。この方法は、供給業者がクレジットカード保持者の住所に品物を出荷する場合には大体において効果的であり、なぜなら、潜在的な窃盗犯は、カード保持者の詳細を盗み出す必要があるばかりでなく、品物の配達に割り込む必要があるからである。物理的な配達を伴わないサービスの場合には、その効果ははるかに落ちる。
【００１０】
明らかに、「ｅＣｏｍｍｅｒｃｅ」におけるクレジットカードの使用は、普及してはいるものの、例えば最大１０，０００ドルまでの金額を伴う可撓性のある小規模の取引に制限されている。このような金額を上回る取引（総額の金銭的条件がそれ以下のもののそれを遥かに上回るもの）の場合、相互に信頼された第三者を使用して、身元及び信頼性を立証しなければならない。
身元の立証の要であるのは、「デジタル証明書」の使用である。顧客は、信頼された第三者による「デジタル証明書」の発行を受けることができ、次に、「デジタル証明書」は、通信事項に電子的に「署名する」ために使用される。署名入りメッセージが受信されると、受信者（この場合は供給業者）は、ａ）送信者の身元、ｂ）メッセージが変更されていないこと、及び、ｃ）送信者が後で自分がメッセージを送信したことを否定できないこと、を明確に立証することができる。「デジタル証明書」に関する認定された規格は、「ＩＴＵ」文書「Ｘ．５０９」に説明されており、「インターネット」通信におけるその使用は、「インターネット」規格文書「ＲＦＣ２３１２」、「ＲＦＣ２４５９」、「ＲＦＣ２５１０」、「ＲＦＣ２５１１」、「ＲＦＣ２５２７」、「ＲＦＣ２５６０」、「ＲＦＣ２５８５」、及び、「ＲＦＣ２６３２」で説明されている。
バリサート・コーポレーションによって提供されるサービスなどの請求可能な第三者サービスは、「デジタル証明書」が例えば何らかの方法で危うくなった後で証明書が無効にされていないことを確認するのに使用することができる。
【００１１】
メッセージの信憑性が立証されると、供給業者は、別の第三者を利用して信頼性を立証することができるか、又は、同一の第三者を利用して信憑性及び信頼性を立証することができる。例えば、世界の大手銀行の協会である「Ｉｄｅｎｔｒｕｓ」は、供給業者が「Ｉｄｅｎｔｒｕｓ」発行の「デジタル証明書」を用いて署名されたメッセージを受信した時、供給業者が、その顧客が認定銀行と良好な取引状態にある有効な口座保持者であることを独立に確認することができるシステムを提供する。
【００１２】
最終的には、このシステムは、銀行が更に取引を保証し、それによって供給業者に対する支払いが保証されるように拡張されることになる。「顧客」及び「供給業者」という用語は、「インターネット」通信に関わる任意の２つの当事者に適用できることが認められるであろう。
上述のシステムの適切な組合せによって、「インターネット」の使用、及び、「インターネット」を通じて利用可能なサービス及び機能に対する確実な基礎が得られることが分る。しかし、これらのシステムのみを使用して「ｅＣｏｍｍｅｒｃｅ」を行うことに関するいくつかの問題があることが認められる。これらの問題について以下で検討する。
【００１３】
上記で参照した機密性送信プロトコル及びメッセージ処理において、データは、通常は送信される前に暗号化され、閲覧する前に意図する受信者によって復号化が行われる。従って、万一データが送信中に傍受された場合、無許可の第三者が復号化アルゴリズムの秘密の復号化キーを知っているか又は確認することができる場合を除き、無許可の第三者によって閲覧されずに安全なものとなる。
機密リンク又はメッセージの各終点でのデータの暗号化及び復号化には、かなりの処理パワーが必要とされる。更に、送信側及び受信側の双方の当事者は、システムが問題なく作動するために、同じ暗号化強度での暗号化アルゴリズムの同一暗号化キーを所有していなければならない。これは、例えば、コンピュータシステムに対するデータのインポート及びエクスポートの規制によってより高強度のアルゴリズムの使用が禁止されており、リンク又はメッセージがより低い強度で暗号化せざるを得ないか又は機密性通信が全くできない場合には問題になることが多い。その結果、機密リンク及びメッセージ処理は、通常は必要な時に限って使用される。
【００１４】
「ワールド・ワイド・ウェブ」上での通信の場合、機密性通信に対する要件は、「ウェブサーバ」によって判断及び開始される。例えば、サーバがユーザに漏れなく記載させるために注文書を送信しようとしている場合、注文書がサーバに返送される時に暗号化されるように機密リンクを開始することができる。同様に、注文が完了すると、サーバは、機密リンクを終了して通常の暗号化されていない通信に戻ることができる。
【００１５】
一般的に、リンクが機密であることを示すユーザが有する唯一のものはアイコン（通常は南京錠を示す）であり、ブラウザウインドウ内に表示される。このアイコンが表示されると、ユーザは、一般的に、ブラウザに問い合わせて使用されている暗号化アルゴリズムの強度を判断することができ、クレジットカード及びアドレス詳細などの機密性情報を入力して続けて送信するか否かを決めることができる。
しかし、実際には、ユーザは、リンクが機密性のものであるか検査しないことが多く、それが送信されている情報を保護するのに適切な暗号化強度であることを検査する頻度ははるかに少ない。この問題に対処するために、マイクロソフト・コーポレーション製の「アウトルック」などの「電子メール」アプリケーションは、初期設定によって全ての「電子メール」を暗号化する能力を提供する。
【００１６】
ユーザ名及びパスワードの広範囲な採用は、特に効果的なセキュリティ上の慣行としてパスワードを頻繁に変更する必要ある時に、覚えておく必要がある真の番号のために多くの「インターネット」ユーザに対して管理上の問題を引き起こす。同様に、ユーザは、他の誰かが既に自分のユーザ名の「お気に入り」を任意のサイトで使用している恐れがあることから、多くの場合様々な異なるユーザ名を使用する必要があることになる。ユーザ名及びパスワードを覚えたり、その後の機会にユーザ名及びパスワードフィールドを自動的に書き込むための機能は、マイクロソフト・コーポレーション製の「インターネット・エクスプローラ」などのウェブブラウザ、及び、「Ｇａｔｏｒ．ｃｏｍ」製の「Ｇａｔｏｒ」などの付加的な「ヘルパー」機能によって設けられている。これらの機能によって、一般的に、ユーザ名、パスワード、及び、それぞれが適用されるウェブページのファイルが維持される。これらのファイルは、確実に適切なユーザのみがアクセスすることができるように暗号化される。許可されたユーザが暗号キーを忘れてしまったり、もはや暗号キーを与えるのに連絡することができない時、又は、ファイルが誤って又は故意に、紛失、破壊、又は、改ざんされた時など、このようなユーザ名及びパスワードが失われたり、又は、利用することができなくなった場合、「インターネット」アカウント及びサービスへのアクセスが失われる恐れがあり、必要なユーザ名及び／又はパスワードを交換又は取り戻すために、各サイトに個別に接続しなければならない。これは、アクセスの喪失及び管理時間に関して企業にとっては非常に経費の掛かる問題になりかねない。更に、このような記憶されたユーザ名及びパスワードは、最初に使用された機械上での使用にのみ利用可能である。ユーザが別の機械に移ったり、複数の機械を使用する場合、記憶されたユーザ名及びパスワードは、これらの他の機械からはユーザは利用することができない。
【００１７】
全ての企業及び多くの個々のユーザは、自分たちが着手する取引の正確な記録を維持する法律上の義務を有するが、「ｅＣｏｍｍｅｒｃｅ」取引に関しては、これが困難であることを証明することができる。企業は、例えば、論争の場合には品物が注文された条件を証明するために監査を目的として記録を維持しなければならない。このような記録は、「ｅＣｏｍｍｅｒｃｅ」環境においてはかなり維持し難く、ユーザは、例えば「電子メール」で送られた注文書のコピーを保管するとか、又は、ウェブサイト購入からのウェブページ領収書を印刷しておく必要がある。ユーザにとっては、これは労力を要するものであり、このように作成されたいかなる記録も完全なもの又は信頼できるものであるという保証はない。
【００１８】
「ｅＣｏｍｍｅｒｃｅ」取引の記録を保管する１つの自動的なソリューションは、マックス・マネジャー・コーポレーション製の「ＡＭａｘ Ｍａｎａｇｅｒ（登録商標）」アプリケーションによって実現されている。「Ｍａｘ Ｍａｎａｇｅｒ」は、公知のウェブサイトで領収書ページを捕捉し、取引情報をそれらの領収書ページから抽出し、そのアプリケーションが実行されている機械上で領収書ページ及び抽出された取引情報の両方をローカルに記憶する。しかし、「Ｍａｘ Ｍａｎａｇｅｒ」は、作動させるために領収書ページの正確なアドレス及びレイアウトを供給してやる必要がある。「Ｍａｘ Ｍａｎａｇｅｒ」は、領収書ページのアドレスを判断するか、又は、ブラウザによって閲覧されている現在のページを領収書ページが供給された領収書ページのそのレイアウトと比較するかのいずれかにより、「ｅＣｏｍｍｅｒｃｅ」取引が行われたことを判断する。領収書ページを特定すると、適合させるためのテンプレートとしてページの公知のレイアウトを使用することにより、該当取引の詳細が領収書ページから抽出される。「Ｍａｘ Ｍａｎａｇｅｒ」の重大な欠点は、データが詳細と共に供給されたページからデータを抽出するためにしかそれを使用することができないということである。更に、領収書ページのレイアウトが変更されている場合、「Ｍａｘ Ｍａｎａｇｅｒ」は、変更後のレイアウト用の新しいテンプレートが供給されるまで、ページからいかなるデータもまともに抽出することができない。ウェブサイトは頻繁に変更されることから、「Ｍａｘ Ｍａｎａｇｅｒ」は、このような変更を考慮するために絶えず更新されなければならない。これは、大局的には非実用的であり、必然的に取引が見逃され、更に悪い場合には間違った報告がなされる。
【００１９】
これらの問題はまた、コンピュータ端末が分散式であり、その結果、多くの場合に端末とユーザとが別々の場所にいるということからきている。複数ユーザという環境においては、ユーザコンピュータは、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）を使用して、物理的に互いに接続することができ、「ＬＡＮ」によって「インターネット」への接続のための「ゲートウェイ」が得られる。また、ユーザコンピュータは、「電子メール」メッセージの中央収集及び配信点として機能するマイクロソフト・コーポレーション製の「エクスチェンジ・サーバ」、頻繁に閲覧するウェブサイトの性能を改善するためのキャッシュとして、及び、望ましくないものと指定された特定のウェブサイトへのアクセスを防止するためのフィルタとして機能するマイクロソフト・コーポレーション製の「プロキシー・サーバ」などのローカルサーバに接続することができる。しかし、２つのローカルユーザ間で送られるメッセージの場合を除き、情報の交換に関する限り、各ユーザは、同一場所で他人から全く孤立して作動する。これは、従業員の活動を中央で管理する手段を有さず、情報の共有から為し得る大幅な経費節約の恩恵を受けることができない企業及び他の組織に対して重大な管理上の問題を呈する。例えば、組織内の２つのユーザは、同一送信者によってデジタル署名された「電子メール」メッセージを独立して受信する恐れがある。双方の受信者は、個別に「デジタル証明書」を確認しなければならず、２つの確認料金が発生して少なくともその１つは不要なものである。
【発明の概要】
【発明が解決しようとする課題】
【００２０】
本発明は、上述のシステム固有の問題を緩和し、情報交換のための単一統合システムをもたらす、上述のシステムへの追加の機能性を提供する。
【００２１】
本発明は、ここで参照すべき独立請求項に示されており、本発明の有利な態様は、特許請求の範囲に示されている。
情報管理システムは、「ｅＣｏｍｍｅｒｃｅ」環境における多くの利点をオンライン商社にもたらし、オンライン商社は、ポリシーデータに暗号化された取引の命令に従って従業員によって為される取引を制御し、パスワード及びオンラインで行われた取引の記録を自動的に維持し、「デジタル証明書」の確認に関する不要な検査の支払いを回避し、従業員によるデータの送信が常に機密に実行されるように保証することができることによる恩恵を受ける。
ここで、本発明の好ましい実施形態について、図面を参照しながら例示的に更に詳細に説明する。
【図面の簡単な説明】
【００２２】
【図１】従来技術により「インターネット」を構成するシステム及びリソースの現在の構成の概略図である。
【図２】企業環境において実行される本発明の好ましい実施形態の概略図である。
【図３】本発明の好ましい実施形態によるウェブブラウザの作動の概略図である。
【図４】ウェブブラウザによって作られた一般的な入力ウインドウの図である。
【図５】本発明の好ましい実施形態による「電子メール」クライアントの作動の概略図である。
【図６】ユーザによって遠隔ウェブサイトに送信されたユーザ名及びパスワード値を捕捉するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図７】データを記録するための制御条件を指定する例示的なポリシーデータの図である。
【図８】ウェブサイト又は「電子メール」クライアントに対して送受信されたデータに含まれるクレジットカード番号を認識するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図９】ユーザによって受信された「デジタル証明書」の有効性を立証するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１０】「デジタル証明書」を確認すべきか否かを判断するための例示的なポリシーデータの図である。
【図１１】「デジタル証明書」に対して確認が必要とされるか否かを判断するために、図１０に示した例示的ポリシーデータを使用する方法を示すフローチャートである。
【図１２】「ｅＣｏｍｍｅｒｃｅ」取引の一部を構成するユーザに対する送受信を特定するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１３】取引を特定するために図１２に示した処理と共に使用されることを意図した例示的なポリシーデータの図である。
【図１４】単一取引の一部を構成すると特定された送信を記録することにより取引の記録を形成するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１５】特定された取引を所定のポリシー設定に基づいて承認又は拒否するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１６】特定された取引が承認を必要とするか否かを判断し、適切な承認者を特定するための例示的なポリシーデータの図である。
【図１７】伝送のための適切なレベルの暗号化を判断し、そのレベルが設けられている場合に限りその伝送が送信されることを可能にするための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図１８】必要とされる暗号化強度を様々なデータ形式に対して指定する例示的なポリシーデータの図である。
【図１９】発信メッセージの再方向付けを制御するための例示的なポリシーデータの図である。
【図２０】図１９に示したポリシーデータを利用して送信前に検討するために発信メッセージを第三者に再方向付けするための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図２１】図１９に示したポリシーデータを利用して会社外部のサイトへの情報のアップロードを制御するための、本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図２２】会社内外の受信者へのメッセージの転送を制御するための例示的なポリシーデータの図である。
【図２３】図２２に示すポリシーデータを利用する本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【図２４】発信メッセージがデジタル署名されているか否かを管理するための例示的なポリシーデータの図である。
【図２５】図２４に示すポリシーデータを利用する本発明の好ましい実施形態によるプラグイン・モジュールの作動を示すフローチャートである。
【発明を実施するための形態】
【００２３】
好ましいシステムは、「インターネット」のユーザにコンピュータシステム上の情報の流れを管理する自動的な方法を提供する。それは、送信が行われるセキュリティレベルを管理する機能、オンライン取引を記録し、承認を得るために第三者にまさに行われようとしている取引を参照する機能、及び、承認が拒否された場合に取引が発生するのを防止する手段を提供し、それはまた、受信されたか又はまさに送信されようとしているいかなる伝送からの関連データも抽出及び記録し、電子メールの送信を知的に管理する機能を提供する。
【００２４】
好ましいシステムは、「インターネット」上で商売をする「ｅＣｏｍｍｅｒｃｅ」会社が遭遇する問題の多くに対するソリューションを提供する。このため、以下で論じられる例示的な内容は、ほとんど「インターネット」上で自社事業の少なくとも一部を行っている妥当な規模の会社による本システムの実施及び使用に関するものとなる。しかし、いかなる規模及び概要の会社や民間の個人を含む「インターネット」を使用する人はだれでも、好ましいシステムによってもたらされる機能性の恩恵を受けることができることが認められるであろう。
好ましいシステムの機能性は、ウェブブラウザ又は電子メールクライアントに「プラグイン」されるコード・モジュールを通じて実行される。これらのプラグイン・モジュールを使用して、作動中のウェブブラウザ又は電子メールクライアントの挙動を制御又は変更することができる。
【００２５】
多くの既存のウェブブラウザ及び電子メールクライアントは、既に、このようなプラグイン・モジュールと容易に一体化することができる。マイクロソフト・コーポレーション製の「インターネット・エクスプローラ」の場合、プラグインは「ブラウザ・ヘルパー」として知られており、１９９９年１月にマイクロソフト・コーポレーションによって発行された、ディノ・エスポシト著の文書「ブラウザ・ヘルパー・オブジェクト：あなたが望むようなブラウザ」において詳しく説明されている。マイクロソフト製の「アウトルック」及び「エクスチェンジ・ｅ−ｍａｉｌ・クライアンツ」の場合、プラグインは、「エクステンション」として知られており、１９９８年３月にマイクロソフト・コーポレーションによって発行された、シャロン・ロイド著の文書「マイクロソフト・アウトルック及びエクスチェンジ・クライアント・エクステンション」において詳しく説明されている。好ましいシステムで作られた「ブラウザ・ヘルパー・オブジェクト」及び「エクステンション」プラグインの使用については、更に詳細に後述する。
【００２６】
好ましいシステムの機能性を実行するためのブラウザ又は電子メールクライアントのプラグイン・モジュールの使用には、メッセージ内容の暗号化が通常はブラウザ又は電子メールクライアント自体によって行われることから、パスワード情報を抽出するため又は暗号化の目標とするレベルを判断するための送信コンテントの検査を、例えばコンテントが暗号化されて送信準備完了の状態になる前、又は、実際に受信後の非暗号化の状態となった後に行うことができるという付加的な利点がある。
【００２７】
図１は、一般的に「インターネット」１０上で品物及びサービスを販売している会社であるサービスプロバイダと、このような品物又はサービスを購入することを希望するユーザとの間の関係を示す。ウェブブラウザ２２、２４、及び、２６を備えたユーザは、「インターネット」を通じて接続し、ウェブページ情報をウェブサーバ１４及び１８から検索することができる。代替的に、電子メールアプリケーション２０、３０、及び、３２を有するユーザは、「ａｂｃ．ｃｏｍ」及び「ｘｙｚ．ｃｏｍ」を有する電子メッセージを電子メールサーバ１２及び１６を通じて送受信することができる。
【００２８】
図１の右下隅に示すものなどの企業レベルの設定において、企業ユーザのウェブブラウザ２４及び２６は、プロキシー・サーバ２８を通じて「インターネット」に接続される。プロキシー・サーバ２８は、ウェブページをキャッシュし、ウェブサイトへのアクセスを制御するのに使用される。同様に、企業は、企業に入ってくる電子メールの中央回収点として機能し、個々のユーザへの電子メールの配信を制御する電子メールサーバ３４を通じて「インターネット」に接続された電子メールクライアント３０及び３２を有する。図１は、「ａｂｃ．ｃｏｍ」及び「ｘｙｚ．ｃｏｍ」を売り手として示すが、企業は、買い手及び売り手の両方になり得ることが理解され、買い手として、「ａｂｃ．ｃｏｍ」及び「ｘｙｚ．ｃｏｍ」は、この説明のために企業ユーザとして説明される。
【００２９】
個人用電子メールアプリケーション２０によって送受信された電子メールの場合、メールは、一般的に個人ユーザが加入する「インターネット」接続サービス業者によって提供される遠隔電子メールサーバによって回収及び配信されることになる点に注意すべきである。
このシステムの特徴及び機能の多くは、個々のユーザにかなりの便益をもたらすが、本システムは、取引情報が多くのユーザから収集されるマルチユーザ環境において作動する時に最大の利点を提供する。図２は、マルチユーザ環境における本システムの好ましい構成の概略図を示す。好ましいシステムは、データベース４２とオペレータコンソール４４とに接続された「中央管理サーバ」４０を含む。「中央管理サーバ」４０はまた、「アプリケーションインタフェース」５０及び５２と開放「アプリケーション・プログラム・インタフェース」５４とを含む「バック・オフィス・アプリケーション・プラグイン」と、「ゲートウェイ」構成要素６０、６２、及び、６４とに接続される。「ゲートウェイ」構成要素６２は、「インターネット・エクスプローラ・プラグイン」７０、「ネットスケープ・ナビゲータ・プラグイン」７２、及び、「ロータス・ノーツ・プラグイン」７６を備えた、１つ又はそれ以上のユーザのコンピュータ上に位置する「ユーザアプリケーション・プラグイン」に接続されているように図示されている。これらのプラグインは、これらのプラグインが一体化されているホストプログラムにおいて好ましいシステムの機能性をもたらすために使用される。４つの可能なホストプログラムである、「インターネット・エクスプローラ」、「ネットスケープ・ナビゲータ」、「マイクロソフト・アウトルック」、及び、「ロータス・ノーツ」が示されているが、好ましいシステムの機能性を実行するように挙動を変更することができることを条件として、「インターネット」に接続することができる任意の他のプログラムを使用してもよい。
【００３０】
「インターネット」１０への接続は、ユーザアプリケーション・プラグイン、及び、そのそれぞれのホストプログラムを通じて行われる。
「ゲートウェイ」構成要素７０、７２、及び、７４は、オプションであるが、各「ゲートウェイ」が情報を記憶及び転送すると共にシステム全体をスケーリングすることを可能にし、その結果、任意数のユーザを接続することを可能にするので好ましいものである。
複数のユーザマシン上の異なるアプリケーションに対する複数のアプリケーション「プラグイン」７０、７２、７４、及び、７６からの情報は、中央管理サーバ４０によって収集され、付随するデータベース４２に記憶される。
【００３１】
「バック・オフィス・アプリケーション・プラグイン」５０、５２、及び、５４により、本システムは、注文処理及び会計事務システムなどの第三者管理アプリケーションと接続することができる。これは、取引情報をこのようなシステムで自動的に入力及び処理することを可能にする。
「オペレータコンソール」４４は、運営管理用に、特に取引の承認用に設けられる。図２においては「中央管理サーバ」に直接取り付けられるように論理的に示されているが、このようなコンソールは、任意のネットワーク化されたコンピュータ上で実行することができる。電子メール又はウェブブラウザ・プラグインが特定の取引が承認を必要とすると判断した場合、要求が「中央管理サーバ」に送られ、許可されたオペレータによる承認待ちの順番に入れられる。
【００３２】
本システムの作動は、ポリシーデータによって制御され、ポリシーデータは、セキュリティに関する企業の規則、認定、及び、ユーザが行うことを許可されるアクション、並びに作動情報を記憶する。ポリシーデータは、「オペレータコンソール」４４、「バック・オフィス・アプリケーション・プラグイン」又は「ユーザ・アプリケーション・プラグイン」のいずれかによってアクセスされるように、「中央管理サーバ」上のポリシーファイルに記憶されることが好ましい。本システムの管理人又はネットワークのスーパバイザは、１つ又はそれ以上のポリシー又はポリシーファイルの設定を定義することができ、個々のユーザ又はユーザのグループを異なるポリシーに割り当てることができ、その結果、各ユーザのコンピュータで直接にパラメータ及びコントロールを設定する必要なく「インターネット」と対話するユーザの能力又はワークステーションの能力さえも制御する。例えば、会社の経理部のユーザを会計ポリシーに割り当てることができ、そのポリシーのその後のいかなる変更も、自動的にそのポリシーに割り当てられた全てのユーザの能力の変化をもたらす。
【００３３】
ポリシーデータを編集又は設定する能力は、ネットワーク・スーパバイザ又は他の許可された１人又は複数の者に制限されることが好ましい。これは、「オペレータコンソール」４４などのポリシーデータを編集するためのアクセスを有効化されたネットワークにおける１つ又はそれ以上のスーパバイザ・ワークステーションを指定することによって達成することができる。
ポリシーは、構造がツリー状であり、設定値をツリーの個々のポリシーノードまで強制的に落とすことができ、例えば、会社の資金繰りが万一問題になった場合に経営最高責任者が全ての購入に自分の承認を必要とするようにさせたいと希望した場合、世界規模の変更がたやすく行うことができることが好ましい。このようなポリシーを基本としたシステムにより、これまでの購入システム及び現行の「ｅＣｏｍｍｅｒｃｅ」購入環境の両方に固有の冗長性が大幅に軽減される。
【００３４】
ネットワークの各ユーザは、ポリシーデータの自分独自の表現を有することになる。メモリ内のスペースを節約するために、主ネットワークポリシーと異なる各ユーザのポリシーの枝及び葉のみが記憶されることが好ましい。ポリシーデータは、「中央管理サーバ」上にファイル形式で記憶されることが好ましいが、ポリシーデータの記憶がファイル形式のみに制限されることを意図したものではない。ポリシー設定の任意の他の表現又は暗号化を好ましいシステム内で採用してもよい。
ウェブブラウザ又は電子メールクライアントにおける本システムの実施について、ここで更に詳細に説明する。
【００３５】
ウェブブラウザでの好ましいシステムの使用
図３は、ウェブブラウザの簡素化された作動を示す。ウェブブラウザは、ユーザからの開始要求に応答して、又は、ユーザのコンピュータの起動ファイルから自動的に段階Ｓ１００で立ち上げられる。起動ファイルは、コンピュータが起動された時に、指定されたプログラムを自動的に実行するコマンドを含む。ウェブブラウザは、起動された後、所定の設定に従って一般的に「ホームページ」つまり閲覧用のデフォルトウェブページを要求する。これは、段階Ｓ１０２で示されている。
要求は、適切なウェブサーバ９０に送られ、「インターネット」上のその正確なアドレスは、通常は「ドメイン名サービス」によって判断される。ウェブサーバ９０は、次に、ウェブページを定義する適切なデータで応答し、この処理は、それぞれ段階Ｓ１０４及びＳ１０６として表されており、その結果、段階Ｓ１０８となる。
【００３６】
ウェブページを定義するデータは、「ＨＴＭＬ」スクリプト、及び、「ＸＭＬ」又は「ＡｃｔｉｖｅＸ」、及び、実行可能なプログラムを暗号化する「Ｊａｖａ（登録商標）ｓｃｒｉｐｔ」などの他の可能なデータ形式などから成る。ブラウザは、このデータを解釈し、段階Ｓ１１０で適宜表示及び／又は実行する。
次に、ブラウザは、一般的に段階１１２でユーザ入力を待つ。このような入力には、表示されたフィールドを埋める、ハイパーリンクをクリックする、又は、新しいウェブページの「ＵＲＬ」アドレスを入力するなどを挙げることができる。最終的には、このようなアクションにより、段階Ｓ１１４及び段階Ｓ１１６で更なる要求がウェブサーバ９０に送られることになる。要求は、単に別のウェブページアドレスであってもよいし、又は、表示されたフィールドにユーザによって入力されたものなどの追加データを含んでもよい。
【００３７】
図４は、サンプルウェブページの表示を示し、「ＧＵＩ」がユーザ名及び電子メールアドレスを受信するためにユーザに提示されている。図４を参照すれば、ユーザが提示された名前要求フィールドに自分の名前を「フレッド・スミス」として、電子メールアドレスを「ｆｓｍｉｔｈ＠ｘｙｚ．ｃｏｍ」として電子メールアドレスフィールドに入力したことが分るであろう。
ユーザが要求ウインドウ上に設けれられた「提出」ボタンをクリックすると、ユーザが入力した詳細は、ウェブサーバ９０に送られるコマンド内に含められる。このようなコマンドは、以下のようになるであろう。
ｈｔｔｐ：／／ｗｗｗ．ｓａｍｐｌｅ．ｃｏｍ／ｓａｍｐｌｅ２．ｈｔｍ？ＵｓｅｒＩＤ＝Ｆｒｅｄ＋Ｓｍｉｔｈ＆ｅｍａｉｌ＝ｆｓｍｉｔｈ＠ｘｙｚ．ｃｏｍ＆ｓｕｂｍｉｔ＝ｓｕｂｍｉｔ
以上から、ユーザ名が「ＵｓｅｒＩＤ」という変数の値としてコマンドに組み込まれ、電子メールアドレスは、「ｅｍａｉｌ」という変数の値として組み込まれることが分る。
【００３８】
コマンドは、段階Ｓ１１４において組み立てられ、段階１１６においてウェブサーバ９０に送信され、ユーザ名及び電子メールアドレス情報は、例えば、電子メールを通じて製品情報をユーザに送るため、又は、ウェブページにアクセスできるようにするために使用することができる。
ブラウザ・ヘルパー・オブジェクト（「ＢＨＯ」）の形の本発明の好ましい実施形態によって得られるプラグイン・モジュールは、標準的なウェブブラウザの機能性を高めるために更なる機能性を提供する。「ＢＨＯ」は、ウェブブラウザが様々なウェブサイト及びページと対話するようにユーザによって操作及び命令された時に発生するいくつかの重大なイベントに応答するように実行される。
【００３９】
「ＢＨＯ」は、ブラウザからウェブサーバに提出されたナビゲーション要求とデータとをモニタし、ユーザ独自のデータを特定するように実行される。これは、単に所定の単語及び語句があるか否かに関して発信データストリームを検索することによって行うことができる。図４に示した上述の場合において、２つの変数の定義「ＵｓｅｒＩＤ」及び「ｅｍａｉｌ」を検索し、それに続くデータを抽出して記憶することができる。代替的に、「ＢＨＯ」は「？」記号を検索することができ、「？」記号は、接続される「ＵＲＬ」アドレスの終わりを示し、それに続くものがデータであることを示す。「ＢＨＯ」はまた、接続されているウェブサイトから受信された着信データストリームをモニタすることができる。
【００４０】
「ＢＨＯ」はまた、ウェブブラウザ自体の作動をモニタするために実行することができる。ウェブブラウザは、それが作動する時に「ｅｖｅｎｔｓ」を生成し、共依存のソフトウエアモジュール又はオブジェクトに何か重要なことが発生したばかりであること、又は、アクションが完了したばかりであることを通知する。イベントの名称は、通常、それ自体が発生したばかりのことを説明するものであり、更に詳細にイベントを説明する追加データが一般的に利用可能である。「ＢＨＯ」は、これらのイベントを捕捉し、それらによってアクションを取るように実行される。
【００４１】
「ＢＨＯ」がそれに応答して実行される１つのこのようなイベントは、「ＢｅｆｏｒｅＮａｖｉｇａｔｅ２」と呼ばれ、これは、ユーザがウェブブラウザに新しいページにナビゲートするように要求した時にウェブブラウザが立ち上げる。イベントが発せられ、要求されたページがダウンロードされる前にそれを「ＢＨＯ」が認識することができ、これにより、「ＢＨＯ」は、ユーザがページを閲覧する前にいかなる関連アクションをも取ることができる。１つのこのようなアクションは、そのページ、及び、そのページに応答して提出された任意のデータをデータベースに記録することであろう。別のこのようなアクションは、要求されたページの「ＵＲＬ」をイベント内で特定し、そのページがダウンロードされるのを防止することであろう。
【００４２】
「ＢＨＯ」が捕捉する別のイベントは、「ＤｏｃｕｍｅｎｔＣｏｍｐｌｅｔｅ」イベントであり、これは、新しいページがウェブサイトからメモリに完全にダウンロードされた時にウェブブラウザによって立ち上げられる。そのページは、マイクロソフト製の「ドキュメント・オブジェクト・モデル（ＤＯＭ）」に準拠する「ドキュメント・オブジェクト」の形式に暗号化される。「ＤＯＭ」により、ページを構成するデータに総合的にアクセスすることができるようになり、その結果、「ＢＨＯ」は、自らに興味があるデータ項目を抽出することができる。例えば、「ＢＨＯ」は、そのページが「ｅＣｏｍｍｅｒｃｅ」取引の一部を成すか否かを判断するためにデータを「ＤＯＭ」に要求することができる。これは、「Ｒｅｃｅｉｐｔ」又は「Ａｃｃｏｕｎｔ Ｎｕｍｂｅｒ」などの用語がないかに関して「ＤＯＭ」内のオブジェクトを検索することによって行うことができる。
【００４３】
「ＢＨＯ」はまた、「ＤＯＭ」を使用して、ウェブページ上に要求されているデータのフィールド名又はフィールド形式を判断することができる。次に、ユーザによってこのようなフィールドに入力されたデータは、「ＤＯＭ」から抽出されて記憶されるか、又は、それに対してアクションを起こすことができる。フィールド名は、一般的に、何が記憶されているかを説明するものである。例えば、パスワードは、「ｐａｓｓｗｏｒｄ」というフィールドに保持されることが多く、それによってウェブページ上で検索することができる。クレジットカード番号は、同様の方法で検索することができる。通常、パスワードフィールドは、あらゆる入力されたデータがアスタリスクとして表示されるような形式のものである。これもまた、「ＤＯＭ」の解析から判断して、関連データを識別するのに使用することができる。
【００４４】
ユーザデータは、一般的にはウェブサイトからダウンロードされたウェブページには存在しないが、ユーザによって「ＨＴＭＬ」形式で入力されるであろう。通常、潜在的に機密性のユーザデータは、ユーザが「Ｓｕｂｍｉｔ」ボタンを選択した時にウェブサイトを通じてウェブサイトに送信される。この段階で、「ＢＨＯ」は、ウェブブラウザによって発せられた「Ｓｕｂｍｉｔ」イベントを捕捉し、「ＤＯＭ」にアクセスしてユーザデータを抽出し、必要であれば、そのデータが送信されるのを防止することができる。
【００４５】
機密リンク上での暗号化及び復号化は、図３においては、それぞれ点Ｃ及び点Ａ後に行われる。従って、「ＢＨＯ」は、暗号化前又は復号化後にそのデータを解析することができる。これは、「ＢＨＯ」がデータ自体の暗号化又は復号化を行う必要がないことから有利である。これは、現行の「ＵＲＬ」の始めにあるプロトコル識別子「ｈｔｔｐ」によって識別することができることから、リンクが機密性であるか否かを判断する能力に悪影響を与えることはない。送信コンテントの検査は、暗号化前又は復号化が行われた後に行われることが好ましい。
【００４６】
電子メールクライアントの作動に関する検討
図５を参照して、ここで一般的な電子メールクライアントの作動、及び、電子メールクライアントにおける好ましい実施形態の実行について説明する。
図５は、電子メールクライアントの簡素化された作動を示す。「受信」及び「送信」作動は、一般的に独立して作動し、これらの作動は、それぞれ図５の反対側に別個に示されており、段階Ｓ１２０及び段階Ｓ１３０から始まる。
【００４７】
電子メールクライアントの「ｒｅｃｅｉｖｅ ｍｅｓｓａｇｅ」作動は、段階Ｓ１２０で開始される。これは、ユーザにいかなる新しい受信メッセージをも知らせておくために所定の間隔で自動的に行うことができ、又は、ユーザが手作業で「ｒｅｃｅｉｖｅ ｍｅｓｓａｇｅ」アイコンを選択することに応答して行うことができる。これを開始する作動により、電子メールクライアントは、電子メールサーバ９５をポーリングして、任意の新しいメッセージをユーザのコンピュータにダウンロードする。段階Ｓ１２２において、電子メールメッセージは、電子メールクライアントによって受信される。一般的に、新しいメッセージは、受信された時に「Ｉｎｂｏｘ」に追加され、受信されたメッセージヘッダ（例えば、送信者名、日付、及び、表題）がリストに配置される。次に、ユーザは、メッセージ全体を読むためにリスト内の適切な項目をクリックし、メッセージをコンピュータ画面に表示させる。段階Ｓ１２４で、電子メールメッセージが表示される。
【００４８】
発信電子メールの場合、ユーザは、「ｃｏｍｐｏｓｅ ｅ−ｍａｉｌ」オプションを段階Ｓ１３０として選択する。これに応えて、電子メールクライアントは、テキストエディタを含むインタフェースを供給し、ユーザは、メッセージ本文のテキストと、宛先アドレス及び件名などの他の情報とを入力することができる。段階Ｓ１３２で、ユーザはメッセージを構成し、その後に「ｓｅｎｄ ｃｏｍｍａｎｄ」を発するために電子メールクライアントによって供給されたアイコン又はメニューオプションを選択することによりメッセージを送ることを選ぶ。段階Ｓ１３４で、電子メールは、受信者に送信されるように電子メールサーバに送られる。電子メールクライアントによって暗号化が適用される場合、それは、段階Ｓ１３４で送信前に適用される。
【００４９】
好ましい実施形態において、付加的な機能性が、プラグイン・モジュールを通じて電子メールクライアントに対して与えられる。電子メールクライアントは、「マイクロソフト・エクスチェンジ」クライアント又は「マイクロソフト・アウトルック」クライアントなどのマイクロソフトによって供給されたもののうちの１つであり、プラグイン・モジュールは、「エクスチェンジ」クライアント・エクステンションとして暗号化されることが好ましい。これらについては、上述のシャロン・ロイド著の文書「マイクロソフト・アウトルック及びエクスチェンジ・クライアント・エクステンション」に説明されている。
【００５０】
「エクスチェンジ・クライアント・エクステンション」は、「マイクロソフト・ウインドウズ（登録商標）・コンポーネント・オブジェクト・モデル（ＣＯＭ）」に準拠し、「エクスチェンジ ＩＥｘｃｈＥｘｔ」インタフェースを利用するコンポーネント・オブジェクトである。このインタフェースにより、「エクスチェンジ」の電子メールクライアントの作動を変更するためのいくつかの追加インタフェースが得られ、例えば、既存のクライアント挙動を交換又は変更し、新しいコマンドをクライアントのメニューに追加することを可能にする「ＩＥｘｃｈＥｘｔＣｏｍｍａｎｄｓ」インタフェース、及び、新しいメッセージの到着、読み取り、書き込み、メッセージ送信、及び、添付ファイルの読取り及び書込みなどのクライアント「ｅｖｅｎｔ」を処理するように習慣的な行動を実行させる「ＩＥｘｃｈＥｘｔＥｖｅｎｔｓ」インタフェースなどがある。また、「ＩＥｘｃｈＥｘｔＭｅｓｓａｇｅＥｖｅｎｔｓ」、「ＩＥｘｃｈＥｘｔＳｅｓｓｉｏｎＥｖｅｎｔｓ」、及び、「ＩＥｘｃｈＥｘｔＡｔｔａｃｈｍｅｎｔＥｖｅｎｔｓ」インタフェースが設けられており、インタフェース名の各々が暗示するより特定的なタスクに対して更なる機能性を提供する。
【００５１】
好ましい実施形態において、プラグイン・モジュールを形成する「エクスチェンジ・クライアント・エクステンション」は、種々の作業を行ってアクションを完了した時にクライアントプログラムによって立ち上げられるクライアント「ｅｖｅｎｔｓ」に応答するように実行される。当該の「ｅｖｅｎｔｓ」は、上述の「ＣＯＭ」インタフェースによって供給される。従って、プラグイン・モジュールによる電子メールクライアントのモニタリングは、「ＢＨＯ」プラグイン・モジュールがウェブブラウザの作動をモニタする方法と類似のものであることが分る。
【００５２】
電子メールクライアント・プラグイン・モジュールは、例えば、新しいメッセージがその下にあるメール配信システムから受信された時、かつ、ユーザが目にすることができる前に立ち上げられる「ＯｎＤｅｌｉｖｅｒｙ」イベントに応答して実行される。「ＯｎＤｅｌｉｖｅｒｙ」イベントは、ダウンロードされてメモリに保持された電子メールメッセージの異なる部分にアクセスするための情報を含む。メッセージヘッダ、メッセージ本文、及び、いかなるメッセージ添付ファイルも、「メール・アプリケーション・プログラム・インタフェース（ＭＡＰＩ）」呼出しを通じて個別にアクセスすることができるメッセージオブジェクトのプロパティとしてメモリに暗号化される。
【００５３】
「ＯｎＤｅｌｉｖｅｒｙ」イベントの一部として供給される情報を通じて、プラグイン・モジュールは、メッセージヘッダにアクセスして、例えば送信者の身元を抽出する。更に、プラグイン・モジュールは、「ＭＡＰＩ」呼出しから得られた情報を利用して、キーワード又は関連データがないかどうか受信されたメッセージの本文を走査することができる。それは、「ｒｅｃｅｉｐｔ」又は「ａｃｃｏｕｎｔ ｎｕｍｂｅｒ」などの重要な単語を特定することによって「ｅＣｏｍｍｅｒｃｅ」取引の証拠を検索することができる。次に、メッセージは、監査を目的として記憶することができる。未承認送信者又は有害なメッセージコンテントの場合、そのメッセージを見られることなく削除することができる。
【００５４】
従って、受信された電子メールの解析は、図５においてはポイントＡでユーザによる閲覧の前に行われる。電子メールは、好ましくは「Ｉｎｂｏｘ」に置かれる前でさえも検査される。メッセージが「Ｉｎｂｏｘ」に置かれる前に自動的に復号化されない場合、例えばユーザが復号化キーを入力することが必要な場合には、メッセージは、復号化直後であってしかも閲覧前に検索される。「デジタル証明書」は、電子メールの添付ファイルとして含めてもよく、閲覧前にたやすく検査することができ、確認などの任意の適切なアクションを行うことを可能にする。
【００５５】
プラグイン・モジュールがそれに応答して実行される別の重要なクライアントイベントは、ユーザが「ｓｅｎｄ ｃｏｍｍａｎｄ」を選択し、電子メールクライアントに新しい電子メールメッセージをメール配信システムに送信するように要求した時に立ち上げられる「ＯｎＷｒｉｔｅＣｏｍｐｌｅｔｅ」イベントである。このイベントは、図５のポイントＢで、送信前及びいかなる暗号化も行われない前に立ち上げられる。送信されるべき新しいメッセージは、「ＭＡＰＩ」呼出しによりアクセスすることができるオブジェクトとしてメモリに同様に記憶される。プラグイン・モジュールは、「ＭＡＰＩ」呼出しを使用してクレジットカード番号などの機密性データに関して発信電子メールのコンテントを走査し、結果的にメッセージを記録させるか、又は、阻止させることさえ可能である。
【００５６】
プラグイン・モジュールの作動
ウェブブラウザ、及び、電子メールクライアント・プラグイン・モジュールの好ましい実行については、上述の図３及び図５を参照して既に説明している。次に、プラグイン・モジュールにより供給される機能性について、詳細に図６から図１８までを参照しながら説明する。
ユーザ名、パスワード、及び、他の情報の識別及び記録
好ましいシステムは、ユーザのワークステーションへの送受信に含まれるデータ、特に、ウェブサイトページ、ファイル転送プロトコル（ＦＴＰ）サイト、及び、「インターネット」上の他のこのようなサイトにアクセスするためにユーザによって入力されたユーザ名及びパスワードを自動的に識別、収集、及び、記憶する手段を提供する。
【００５７】
現時点でパスワードを記録する機能をもたらすシステムは、現時点では、ユーザが「ＧＵＩ」上に設けられた「ｒｅｍｅｍｂｅｒ ｐａｓｓｗｏｒｄ」オプションをクリックした時にのみそれを行う。パスワードは、例えば、ユーザが起動時にユーザ名及びパスワードを入力することによってそのコンピュータで確認された時にのみ開かれるユーザのコンピュータ上の保護されたローカルファイルに保存される。「ｒｅｍｅｍｂｅｒ ｐａｓｓｗｏｒｄ」オプションは、パスワードが必要とされる度にユーザが入力しなくても済むように、次にユーザが接続した時に本システムがユーザのパスワードを覚えておくようにさせてパスワードフィールドにそのパスワードを予め記入する。ローカルに記憶されるパスワードファイルの欠点は、ユーザが別のコンピュータに移動した時に、記憶されたパスワードファイルにアクセスすることができないのでパスワードを自分で再入力しなければならないということである。
【００５８】
好ましいシステムは、ユーザからの命令が必要なくパスワードを自動的に識別し、識別されたパスワード及びユーザ名をデータリポジトリーに記憶する。これは、中央データベース４２であることが好ましい。これにより、任意のユーザのパスワードがユーザがログオンする端末に関係なく思い出されるが、端末がデータベースにアクセスできることが条件である。
あらゆる識別されたパスワード及びユーザ名は、最初のウェブサイト上で記憶されたフィールド名、及び、送信先かつ使用された場所である「インターネット」サイトのアドレスと共にデータベースに記憶される。サイト情報は、パスワード及びユーザ名情報をそのサイトに提出する「ＨＴＴＰ」要求、及び、メモリに保持されたウェブページの表現に含まれているので簡単に検索することができる。
【００５９】
セキュリティのために、データベースに記憶された情報は、ネットワーク・スーパバイザ、システム管理者、又は、会社取締役などの選ばれた数の人々のみがアクセスすることができるように暗号化されることが好ましい。彼らは、ネットワーク内のワークステーションを通じて、身元確認を行うためにユーザ名及びパスワードを入力することにより、又は、オペレートコンソール４４などのスーパバイザ・ワークステーションを通じてデータベースにアクセスすることができる。
【００６０】
アドレス詳細と共に為されるユーザ名及びパスワードの記憶により、オンライン機能を使用する会社にとって重要な利点が呈示される。既存の技術を用いると、ユーザが保護ファイルへのアクセスを防止するための自分の確認用パスワードを忘れたり、又は、パスワードを開示せずに退職した場合に「インターネット」サービスにアクセスすることができない。同様の状況は、保護ファイルが損傷、削除、又は、他の方法で紛失した場合に発生する。その時は、紛失したパスワードを交換又は発見するために、各「インターネット」サービスに接続しなければならず、これは、失われたアクセス及び管理時間の両方の点で費用が掛かる可能性がある。好ましいシステムを用いると、パスワード情報は、中央データベースから発見することができ、そのためにウェブサイトへのアクセスは失われない。
【００６１】
図６は、ウェブサーバに送信されるべきデータからユーザ名及びパスワード情報を抽出するために実行されたプラグイン・モジュールの作動を概略的に示すフローチャートである。段階Ｓ１５０において、プラグイン・モジュールが開始され、ブラウザからウェブサーバにまさに送信されようとしているデータを構文解析する。これは、図３で示した処理のポイント「Ｃ」で発生する。次に、制御は段階Ｓ１５２に移り、プラグイン・モジュールは、送信されるべきデータがユーザ名又はパスワード情報を含むか否かを判断する。
【００６２】
パスワード及びユーザ名は、図３、図４、及び、図５を参照して説明した方法、つまり、提出されたコマンド内のフィールド名を識別することにより、又は、「ＣＯＭ」を使用して例えばフィールド名、フィールド形式、又は、ウェブページ上のデータを識別するのに使用された表示方法を検索することにより識別することができる。また、パスワード及びユーザ名は、「ワールド・ワイド・ウェブ」上の遠隔サーバ又はプロバイダによるか、又は、電子メールメッセージのコンテントを走査することによってさえも呈示されるウェブページの「ＨＴＭＬ」、ポップアップウインドウ、又は、「ＧＵＩ」（グラフィッカル・ユーザ・インタフェース）から検索することができる。
【００６３】
ウェブページのコマンド又は「ＤＯＭ」内のパスワード及びユーザ名をそのフィールド名内で識別することは、「パスワード」又は「ユーザ名」などの明白なラベルでその目的を説明するフィールド名に依存する。フィールド名自体が意味を持たない場合、送信されるデータの性質は、「ストリング」又は「整数」などであるデータのフィールド形式、又は、そのデータを入力するのに使用された表示方法から推論することができる。パスワードを受信するように意図されるフィールドは、「ＤＯＭ」内の「パスワード」フィールド形式を検索することにより、その表現内で識別することができる。パスワードデータの入力先であるウェブページ上のテキストボックスでは、一般的に各文字入力はアスタリスクとして表示され、このプロパティを「ＤＯＭ」から判断することができ、テキストボックスへ入力されたデータが他のインジケータがない場合でさえもパスワードであると推論するのに使用することができる。パスワードは、アスタリスクのストリングとして表示されるが、メモリ内の表現は、それでも尚ユーザによって入力された文字情報を含む。次に、パスワードは、単に入力をフィールドから抽出することによって検索することができる。
【００６４】
代替的に、パスワード及びユーザ名は、「ｒｅｍｅｍｂｅｒ ｐａｓｓｗｏｒｄ」オプションがユーザによって選択されている時にマイクロソフト製の「インターネット・エクスプローラ」などの他のプログラムによって記憶されたものを参照することにより識別することができる。このようなパスワードは、ユーザのコンピュータ上のローカル保護ファイルに記憶される。このファイルは、ユーザがコンピュータ上に確認された時に「解錠」され、従って、好ましいシステムのブラウザ・プラグイン・モジュールによりパスワード及びユーザ名情報を取得するためにアクセスすることができる。
【００６５】
プラグイン・モジュールが送信されるべきデータにおいてユーザ名又はパスワードを検出しなかった場合、制御は段階Ｓ１５８に移り、この時点でモジュールはフローから出て、制御は図３のポイント「Ｃ」に戻される。次に、ブラウザは、データをウェブサーバに送信することができる。しかし、ユーザ名又はパスワードが段階Ｓ１５２で検出された場合、制御は段階Ｓ１５４に移り、識別されたユーザ名又はパスワード、及び、データの送信先であるウェブページの「ＵＲＬ」又は他の識別子の値が抽出される。次に、制御は段階Ｓ１５６に移り、これらの値、及び、「ＵＲＬ」又は他の識別子は、好ましいシステムデータベース４２に記憶される。記憶が行われると、制御は次に段階Ｓ１５８に移り、モジュールはフローから出て、制御は図３のポイント「Ｃ」に戻される。次に、モジュールは、データをウェブサーバに送信することができる。
【００６６】
好ましい実施形態は、パスワード又はユーザ名の記憶によって直ちに得られる利点のために例示的に使用されたそれらの記憶のみに限定される必要はない。他の形式のデータ、特にクレジットカード情報及び「デジタル証明書」などの「ｅＣｏｍｍｅｒｃｅ」取引に関係するものもまた、データベース又は記録が得られるように有益に抽出及び記憶することができる。情報を送信から抽出するためのシステムもまた、電子メールシステムに適用することができる。
【００６７】
この情報は、上述の方法、つまり「ＤＯＭ」を通じて又は電子メールコンテントの「ＣＯＭ」表現への「ＭＡＰＩ」呼出しを通じて抽出することができ、又は、ウェブページが符号化される言語から抽出することができる。ウェブページは、一般的に、「ハイパーテキスト・マークアップ言語（ＨＴＭＬ）」、つまり、従来のテキストマッチング技術を使用して公知のキーワード又はインジケータがないかどうか検索することができる人間読取り可能テキストベースの言語に符号化される。好ましい実施形態において、データの記録は、ウェブページが後で検索して閲覧することができるように、パスワード及びユーザ名情報のみを記録する段階、閲覧されているウェブページ又は電子メールアカウントの「ＵＲＬ」を記録する段階、ウェブページのフィールドに提出された任意のデータを記録する段階、及び、ウェブページの「ＨＴＭＬ」を記録する段階を伴うであろう。
好ましいシステムによってもたらされるプラグイン・モジュールは、ポリシーデータに関連して作動し、ポリシーデータは、例えば、ファイル、データベース、又は、ソフトウエアコードに記録することができる。ポリシーデータにより、好ましいシステムのユーザは、各プラグイン・モジュールの作動を命令し、それによってプラグイン・モジュールの機能性を制御することができる。
【００６８】
図７に示すポリシーデータのサンプル表現は、ユーザがプラグイン・モジュールの作動を制御して、他の形式のデータと共にパスワード及びユーザ名情報を記録する方法を示す。
ポリシーデータのツリー状の構造は、図７に明確に示されており、図７は、「ＡＲｅｃｏｒｄｉｎｇ＠」と題したポリシーデータの１つの主なブランチのみを示す。「Ｒｅｃｏｒｄｉｎｇ」ブランチは、ウェブブラウザ・イン・モジュール、及び、電子メールクライアント・プラグイン・モジュールの作動の命令をそれぞれ含む「ＡＢｒｏｗｓｅｒ＠」、及び、「ＡＥｍａｉｌ＠」という２つのサブブランチに分かれる。
【００６９】
ブラウザブランチは、「ＡＤａｔａＴｏＲｅｃｏｒｄ＠」、「ＡＷｈｅｎＴｏＳｔａｒｔＲｅｃｏｒｄｉｎｇ＠」、及び、「ＡＷｈｅｎＴｏＳｔｏｐＲｅｃｏｒｄｉｎｇ＠」という３つのサブブランチを含む。「ＤａｔａＴｏＲｅｃｏｒｄ」ブランチは、ユーザのワークステーション及びウェブサーバに対する送受信から抽出されるデータの形式を指定する。４つの形式のデータは図に示されており、これらは、閲覧されているウェブページ、閲覧されているウェブページの「ＨＴＭＬ」、ウェブページ上に設けられたフィールドにユーザによって入力され、ウェブサイトに提出されたデータ、及び、ユーザによって入力された任意のパスワード及びユーザ名である。これらは、「Ａ「ＵＲＬ」＠」、「ＡＨＴＭＬ＠」、「ＡＳｕｂｍｉｔｔｅｄＦｉｅｌｄｓ＠」、及び、「ＡＰａｓｓｗｏｒｄｓ＠」と題された「ＤａｔａＴｏＲｅｃｏｒｄ」ブランチの４つの異なるサブブランチ上で示されている。それらの各サブブランチ上のＹＥＳ／ＮＯオプションは、表示されたデータが記録されるべきか否かを指定する。
【００７０】
「ＷｈｅｎＴｏＳｔａｒｔＲｅｃｏｒｄｉｎｇ＠」ブランチは、「ＤａｔａＴｏＲｅｃｏｒｄ＠」ブランチにおいて指定されたデータが記録されるポイントを指定するいくつかの条件を定める。この例において５つの条件が示されており、各々は個別のブランチで定められ、それぞれ、「ＡＷｈｅｎＢｒｏｗｓｅｒＩｓＯｐｅｎｅｄ＠」、「ＡＩｆＣｒｅｄｉｔＣａｒｄＲｅｃｅｉｖｅｄ＠」、「ＡＰａｓｓｗａｒｄＳｕｂｍｉｔｔｅｄ＠」、及び、「ＡＩｆＫｅｙｗｏｒｄｓＳｅｎｔ＠」と題されている。いつ記録を開始すべきかを判断するためにこれらの条件を使用すべきであるか否かは、各ブランチ上でＹＥＳ／ＮＯマーカーによって表示されている。
【００７１】
同様に、「ＷｈｅｎＴｏＳｔｏｐＲｅｃｏｒｄｉｎｇ＠」ブランチは、「ＤａｔａＴｏＲｅｃｏｒｄ＠」ブランチにおいて指定されたデータの記録を停止すべきポイントを判断するために使用することができる３つの条件を示している。これらの条件は、「ＡＷｈｅｎＵｓｅｒＣｌｏｓｅｓＢｒｏｗｓｅｒ＠」、「ＡＷｈｅｎＵｓｅｒＣｈａｎｇｅｓＳｉｔｅ＠」、及び、「ＡＷｈｅｎＵｓｅｒＣｈａｎｇｅｓＰａｇｅ＠」である。各条件及び記録されるデータ形式に対するＹＥＳ／ＮＯ状態は、プラグイン・モジュールの作動を制御するために、好ましいシステムのユーザが簡単に設定することができる。
【００７２】
ポリシーデータの電子メールブランチは、「ＤａｔａＴｏＲｅｃｏｒｄ」ブランチ、及び、「ＷｈｅｎＴｏＲｅｃｏｒｄ」ブランチに分けられている。これらのブランチの各々は、「Ｓｅｎｔ Ｍａｉｌ」及び「Ｒｅｃｅｉｖｅｄ Ｍａｉｌ」を処理するブランチに細分化されている。記録することができるデータの形式は、「ＤａｔａＴｏＲｅｃｏｒｄ」ブランチに定められ、送られたメールについては、メッセージテキスト及びメッセージの任意の添付物とすることができ、デジタル署名で署名されたメッセージの場合には、署名を伴う「デジタル証明書」のコピーとすることができる。「Ｓｅｎｔ Ｍａｉｌ」及び「Ｒｅｃｅｉｖｅｄ Ｍａｉｌ」を記録するための条件は、「ＷｈｅｎＴｏＲｅｃｏｒｄ」ブランチに定められており、送られたか又は受信されたメール内のクレジットカード番号、キーワード、又は、「デジタル証明書」の識別に基づくものとすることができる。
【００７３】
説明したツリー状の構造は、データを容易にまとめて参照することができるのでポリシーデータの好ましい形式である。また、この構造により、異なるポリシーを受信するために異なるユーザをツリーの異なるブランチに割り当てることができる。ツリー状の構造は好ましいものであるが、他の配置も可能とすることができる。この図で示されているブランチは、単に例示的であるように意図されている。
【００７４】
クレジットカード番号の識別
好ましいシステムはまた、一般的に１４桁と１６桁の間の長さの数値桁のストリングを検索することにより、ウェブサーバ又は電子メールクライアントに送信されるデータ内の「クレジットカード」番号又は他のアカウント情報を検索する。次に、その桁のストリングがカード番号を確認するためにクレジットカード会社によって世界的に使用される試験の１つを満足するか否かが判断される。クレジットカード番号が送信に見つけられた場合、好ましいシステムは、承認を得るために送信を第三者に問い合わせる、クレジットカード番号が会社に属する場合には送信を安全保護するためにより高度な暗号化を再交渉する、又は、送信が全く行われないようにするなどの、ポリシーファイルの設定によるいくつかのアクションを取ることができる。
【００７５】
クレジットカード番号を識別する最も一般的な試験は、「ＡＮＳＩ規格Ｘ４．１３」に定義されており、一般的に「ＬＵＨＮ」又は「Ｍｏｄ １０」として知られている。
「Ｌｕｈｎ」公式は、検査桁を生成するためにクレジットカード番号に適用され、従って、クレジットカードを確認するためにも使用することができ、その場合は、検査桁はその公式の一部として考えられる。「Ｌｕｈｎ」公式を使用してクレジットカード番号を確認するためには、番号の右側から始まって左側に移動する１桁目以降の２桁目ごとの値に２を掛け、次に、桁の全て、つまり２を掛けた桁とそうでない桁の両方を合計し、２倍した結果として１０に等しいか又はそれ以上になったいかなる桁の数値も、例えば「１０」が「１＋０＝１」と計算され、「１８」が「１＋８＝９」と計算されるように、それらが２つの単一の桁値であるかのように加え合わされる。足し算の合計が１０で割り切れる場合、そのクレジットカードは、有効なクレジットカード番号である。
【００７６】
図８は、まさに送信されようとしているデータにおいて、上述の「Ｌｕｈｎ」公式を使用してクレジットカード番号を検出するプラグイン・モジュールの作動を示すフローチャートである。クレジットカード番号が識別された場合、プラグイン・モジュールは、更なるポリシーベースの検査を実行し、その結果に基づいて、クレジットカード番号を含むデータを送信するか、又は、送信を防止するかを決めることができる。
【００７７】
このモジュールは、段階Ｓ１６０で作動を開始するが、この段階は、ブラウザ実行の場合には図３に示した処理のポイント「Ｃ」、又は、電子メールクライアント実行の場合には図５に示した処理の「Ｂ」に続くものである。制御は、段階１６０から段階Ｓ１６２に移り、段階Ｓ１６２において、モジュールは、ウェブサーバ又は電子メールサービスにまさに送信されようとしているデータを走査し、クレジットカード番号の可能性が高い桁の第１ストリングをそのデータから抽出する。
これは、特定の桁数の長さに亘る桁のストリングの送信を含むデータを走査することによって達成される。クレジットカード番号は、通常は長さが１２桁を上回る桁で構成され、通常は１６桁を上回らない。従って、この範囲の桁のいかなるストリングも可能なクレジットカード番号として識別することができる。
【００７８】
抽出段階Ｓ１６２の後、制御は判断段階Ｓ１６４に移り、そこで、ファイル検査のルーチン終了が為される。データが候補のクレジットカード番号を含まず、いずれかの第１候補の番号が見つかる前にファイル検査の終了になった場合、段階Ｓ１６４で、制御は段階Ｓ１７８に移り、データの送信は、更なる検査を行うことなく続行することができる。次に、モジュールは段階Ｓ１８０でフローから出る。制御は、図３に示すウェブブラウザの作動においてはポイント「Ｃ」から、又は、図５に示す電子メールクライアント作動においてはポイントＢから再開する。
【００７９】
段階Ｓ１６２において、第１の潜在的なクレジットカード番号がデータ内で見つかった場合、抽出されてメモリに記憶される。ファイルの終了にはならないが、制御は、段階１６２から段階Ｓ１６４へ、次にＳ１６６に移り、記憶された候補番号の「ｃｈｅｃｋｓｕｍ」が「Ｌｕｈｎ」公式を使用して計算される。次に、制御は判断段階Ｓ１６８に移り、「ｃｈｅｃｋｓｕｍ」が問い合わせされる。
「ｃｈｅｃｋｓｕｍ」の結果として候補番号が有効クレジットカード番号でないと分った場合、制御は段階Ｓ１６２に戻り、次の潜在的なクレジットカード番号がデータから抽出される。第２のクレジットカード番号が見つからなかった場合、ファイルの終了となり、制御は、送信の進行が許される段階Ｓ１７８に移り、次に、モジュールがフローから出る段階Ｓ１８０に移る。
【００８０】
しかし、「ｃｈｅｃｋｓｕｍ」の結果として候補番号が有効クレジットカード番号であると分った場合、制御は判断段階Ｓ１７０に移り、取るべき適切なアクションがあるかどうかポリシーデータの設定に問い合わせる。そのアクションは、番号自体、その番号を送信するユーザの身元、及び、送信先のアドレスなどの要素から判断することができる。ポリシーデータは、例えば、クレジットカードを送信すべきではないとか、又は、送信が続行される前により高い暗号化強度が必要であると指定することができるであろう。
【００８１】
このポリシー検査段階により、取引を行うユーザよりも高いレベルでクレジットカード取引を制御することができる。従って、金融面の決定は、迅速かつ簡単に実行することができ、モニタリングを必要とせずに自動的に実施することができる。組織は、例えば、その組織のアカウント上でクレジットカード取引を行う能力を特定の許可された人々に制限したり、又は、特定のアカウント上の取引を全て制限したいと思う場合がある。
【００８２】
段階Ｓ１７０において、クレジットカード番号及び取引の他の詳細がポリシーファイル内の設定と比較され、送信が行われてもよいか否かが判断される。ポリシー検査を参照して何らかの理由でそのクレジットカード番号は送信されるべきではないと判断された場合、制御は段階Ｓ１７２に移り、そのデータの送信が停止され、次に段階Ｓ１７４に移り、モジュールはフローから出る。この時点で、本システムは、ユーザに要求が否定されたことをポップアップメッセージボックスによって通知することができる。次に、制御は、ウェブブラウザの場合には図３のポイントＡに、又は、電子メールクライアントの場合には図５の段階Ｓ１３２の「ｃｏｍｐｏｓｅ ｍａｉｌ」に戻る。
【００８３】
段階Ｓ１７２において、クレジットカード番号を送信することができると判断された場合、制御は段階Ｓ１７６に移り、データの送信が発生し、次に段階Ｓ１８０に移り、モジュールはフローから出る。この場合、制御は、ウェブブラウザ作動においてはポイントＣから、又は、電子メールクライアント作動においては図５に示すポイントＢから再開する。
クレジットカード番号は、単に送信のコンテントを走査することにより段階Ｓ１６２において識別されるとは限らない。ウェブブラウザでの実施において、クレジットカード番号は、例えば送信される任意の変数のフィールド名を参照することにより、又は、メモリ内のウェブページの表現からも直接識別することができる。パスワードの識別に関する上述の検討は、これをより詳細に説明している。
【００８４】
好ましいシステムはまた、アカウント番号などの他の関連する金融上の詳細がないかどうか発信される送信を検索するように構成することができる。資金を預金することができる会社アカウント番号は、別ファイルに記憶することができる。次に、説明した方法により、発信データから任意の可能性の高い文字又は桁のストリングを抽出してアカウントファイル内の入力コンテントと比較し、それが有効アカウント番号であるか否かを判断することができる。次に、上述の方法で取引を続行又は拒絶することができるであろう。クレジットカード番号を参照したが、デビットカード番号のような支払いを行うためのあらゆる形式のカード番号もまた使用し得ることが認められるであろう。
また、クレジットカード番号の識別を送信されるデータに関して説明したが、同様の技術を使用して、受信する伝送からクレジットカード番号を識別して抽出することができることが認められるであろう。
【００８５】
確認及び認証サポート
オンライン取引では、一般的に、ユーザが自分で言うその本人であること、及び、注文した品物の代金を支払うことができるということの何らの形の認証が必要とされる。これらの要件は、通常、売り手が後でカード発行人に確認することができるクレジットカード番号とカード保持者の住所とを購入者が業者に供給することによって満足される。しかし、「デジタル証明書」がユーザによって電子取引に添付されることが増加傾向にあり、デジタル署名と共に「デジタル証明書」は、受信者が送信者という名前の人物から発せられた取引を確認することを可能にする。「Ｉｎｄｅｎｔｒｕｓ」のようないくつかの発行機関からの「デジタル証明書」はまた、その保持者が所定の金額を支払うという自分の責任を全うすることの保証として機能することができる。これらの証明書は、オンラインで取引をする時に有用である。
【００８６】
「デジタル証明書」は、情報を送信する時又は取引を行う時に個人の身元を確立する普及している手段である。それらはまた、いかなる送信情報又は取引詳細の受信者に対しても、それらの詳細やその情報が無許可の第三者によって途中で改竄されていないという保証を提供する。
「デジタル証明書」は、ベリサイン・インコーポレーテッドのような独立した「証明書発行機関」によって個人、組織、又は、会社に発行される。組織はまた、別の「証明書発行機関」によって発行された「ルート」証明書から得ることができるか又は得ることができない独自の「デジタル証明書」を発行する独自の「証明書発行機関」として機能することができる。「デジタル証明書」には、一般的に、保持者名、一連番号、満了日、証明書保持者の一般キーの写し、及び、証明書発行機関のデジタル署名が含まれる。また、個人キーが証明書保持者に発行され、保持者は、それをだれにも開示してはならない
【００８７】
証明書は、各保持者独自のものであり、保持者がもはや実行可能でない場合は発行人により取り消すことができ、代替的に、保持者は、自分の個人キーが危うくなった場合にはそれを取り消すように頼むことができる。
一般キー及び個人キーは、いずれも、メッセージを暗号化又は復号化をするために協働して使用することができる。メッセージを個人キーで復号化した後には証明書保持者によってのみ読むことができるように、誰でも証明書保持者の一般キーを使用してメッセージを暗号化することができる。
【００８８】
また、メッセージには、メッセージのコンテントをハッシュという数学的要約に変換するソフトウエアを使用してデジタル署名することができる。その後、ハッシュは、送信者の個人キーを使用して暗号化される。その後、ハッシュは、送信されているメッセージのデジタル署名として使用することができる。元のメッセージ、デジタル署名、及び、送信者の「デジタル証明書」は、全て、受信者に送信され、受信者は、その後、自分が受信したメッセージが不備なく元の形から改竄されていないことを確認するために、受信されたメッセージのハッシュを生成することができる。受信されたハッシュが、保持者の一般キーで復号化された後に受信者によって生成されたハッシュと合った場合は、受信者は、そのメッセージは証明書の発行先であるその人物から送られたものであり、メッセージは元の形から途中で変更されていないと信用することができる。従って、「デジタル証明書」は、「インターネット」上で取引を行う会社にはかなり重要であり、ますます重要になっている。
【００８９】
オンライン業者が、顧客の身元を確認するために「デジタル証明書」を利用する場合、証明書は任意の取引が許可される前にまだ有効であることを発行人に対して検査することが必要である。このような検査は、バリサート・インコーポレーテッドなどの独立した確認サービスを使用してオンラインで行うことができる。通常、このようなサービスに対しては手数料が請求される。
【００９０】
おそらく、組織の従業員は、各々単一のクライアントから電子メールを受信し、各電子メールは、個別の機会に「デジタル証明書」で証明されるであろう。現在、自分たち自身で手作業で共有しない限り、１人の従業員によって受信された証明書に関する情報が別の従業員と共有される方法はなく、その結果、個々の従業員は、同一の証明書を受信する度に確認するように要請するであろう。しかし、証明書が発行人によって取り消されると、二度と回復されず、それで、既に取り消された証明書に費やされた確認手数料は不要であることからこれは無駄である。更に、受信者は、以前に確認された証明書を再検査すべきか否かに関して業務上の判断をしたいと思う可能性がある。例えば、１００万ドル分の品物のデジタル署名された注文がある日受信されて、証明書は問題なく確認され、翌日に５０ドルの別の注文が受信されて同一の証明書で署名された場合、その組織は、２番目の検査は不要であり、それによって確認料金の節約になると考えるであろう。
【００９１】
好ましいシステムは、受信された「デジタル証明書」、最終検査時の証明書の状態、並びに、可能な場合には、クライアント、金額、日付、及び、品物のような取引情報に関する情報を記録する手段を提供する。この情報は、本システムの全てのユーザがアクセスすることができる中央データベースに記憶される。また、好ましいシステムは、記憶された情報を使用して確認検査が望ましいか否かを判断し、「デジタル証明書」の状態により取引を受理又は拒否する手段を提供する。従って、本システムのユーザは、真偽を自分で立証する必要がなく、取引を受信して検討することができる。
【００９２】
図９は、会社従業員によって受信された取引から「デジタル証明書」を抽出し、その確認状態、及び、日付、金額、及び、品物などの任意の関連取引の詳細と共に、それらをデータベース内に記録するために実行される好ましいシステムのプラグイン・モジュールの作動を示す。モジュールは、まず、証明書が明らかに無効であるか否か、また、メッセージは正しくその証明書によって署名されているかを判断するために検査する。証明書は、例えば、満了日が過ぎている場合、又は、無効な「捺印」を含む場合は明らかに無効である。このような捺印は、例えば証明書自体の「ｃｈｅｃｋｓｕｍ」である場合がある。メッセージは、証明書に含まれた情報から署名を確認することができない場合は正しく署名されていないことになる。証明書確認及びメッセージ署名の詳細については、先に参照した「ＩＴＵ」及び「ＲＦＣ」文書に詳しく説明されている。次に、モジュールは、その証明書がデータベースに既に記憶されているか否かを判断するために検査し、記憶されていないものだけを記録する。証明書のコピーが既に記憶されている場合、モジュールは、データベース記録を検査して、取り消しと以前に識別されていたか否かを判断し、識別されていた場合は直ちにその取引は拒否される。そうでない場合、次にモジュールは、業務上の規則を定義するポリシーに従って、証明書を確認するか否かを判断する。任意のこのような確認を考慮に入れて、次に、証明書を信頼すべきか否か、従って「デジタル証明書」によって署名された取引は拒否されるべきか受理されるべきか否かを判断する。モジュールは、「デジタル証明書」を含むデータの受信後に段階Ｓ１９０で開始される。「デジタル証明書」は、一般的に、メッセージの添付ファイルとして送信され、添付ファイルのヘッダ内の最初の数バイトを検査することによって識別することができる。これらのバイトにより、添付されたファイルの形式が識別され、それによって添付ファイルが「デジタル証明書」か否かが示されることになる。
【００９３】
初期化段階Ｓ１９０は、モジュールがウェブブラウザで実行された場合には図３のポイントＡで、また、モジュールが電子メールクライアントで実行された場合には図５のポイントＡの後に発生する。初期化後、モジュールは、段階Ｓ１９１に進み、証明書の満了日が検査され、デジタル署名がメッセージに署名されたことが確認される。証明書が満了となっていたか、又は、メッセージが不正に署名されていた場合、モジュールは、段階Ｓ１９２に進み、その取引を拒否する。そうでない場合は、モジュールは、段階Ｓ１９２に進み、「デジタル証明書」の以前に受信されたコピーがないかデータベースを検索する。次に、制御は段階Ｓ１９４に移る。証明書のコピーがデータベースで見つかった場合、制御は判断段階Ｓ１９６に移り、そこでモジュールは、証明書が以前に取り消しとして記載されていたか否かを判断する。これは、以前の確認検査が「デジタル証明書」が取り消されていたことを明らかにした場合に生じているものである。証明書がまだデータベース内にない場合、制御は段階Ｓ１９４から段階Ｓ２０２に移り、新しい証明書及び証明書が受信された日付が、証明書が送信されたアドレス、及び、金額及びアカウント番号などの取引に関連した任意の取引の更なる詳細と共に、データベースに記憶される。段階Ｓ１９６で証明書が既に取り消しと記載された場合、制御は、直接段階Ｓ１９８に移り、「デジタル証明書」を構成する取引が自動的に拒否される。これには、例えば、証明書が無効と分った送信の開始者に拒否を説明するために自動的に生成されたメッセージを送信する段階、及び、「デジタル証明書」の受信者が拒否された送信に関連していかなる更なる段階を講じることをも防止する段階を伴うであろう。次に、モジュールは、段階Ｓ２００でフローから出る。
【００９４】
しかし、段階Ｓ１９６で証明書が以前に取り消しと記載されていなかった場合、制御は段階Ｓ２０４に移り、証明書により署名されたか、同じ会社の他の証明書により署名されたか、又は、同じアカウント上で取引を行うのに使用された送信の履歴は、証明書のオンライン確認検査が必要とされるか否かを判断するためにポリシーデータを用いて検討される。制御はまた、段階２０２で新しい「デジタル証明書」がデータベースに追加された後に段階Ｓ２０４に移る。
【００９５】
ポリシーデータには、以前に受信した署名された取引と以前に行われた取り消し検査との履歴と共に検討した時に、取引に署名するために使用された証明書をこの場合に確認すべきか否かを示す命令が含まれる。例示的なポリシーデータをここで参照すべき図１０に示す。
ポリシーデータは、ポリシーデータ表現の「ＤｉｇｉｔａｌＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチ上の「ＡｃｃｅｐｔａｎｃｅＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチ上に記憶されている。「ＡｃｃｅｐｔａｎｃｅＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチは、証明書が金額に関する受信者との取引を伴う送信に署名するために使用される「金融上の」「デジタル証明書」と、送信の受信者との金銭的な取引を伴わない「Ａｉｄｅｎｔｉｔｙ＠」「デジタル証明書」とを個々に取り扱う２つの個別のブランチに細分化されている。いくつかの証明書は、金銭的な取引に関連して使用するために限って発行される。例えば、署名された送信の受信者に対する保証として、「Ｉｄｅｎｔｒｕｓ」のような一部のオンライン銀行組織によって「保証証明書」が発行される。このような保証証明書は、伝送の送信者が「Ｉｎｄｅｎｔｒｕｓ」加盟銀行の顧客であること、及び、この顧客が支払いを行わなかった場合には、その銀行が債務を引き受けることを証明するものである。
【００９６】
異なる種類又はクラスの「デジタル証明書」を発行する組織は、そのクラスに従って各証明書にマーキングを付している。従って、証明書が特定クラスのものとして識別することは、異なる組織がその証明書を分類する方法を知り、適切なインジケータを受信した証明書において検索するということである。
「デジタル証明書」の発行人は、異なる目的に合った多くの異なるクラスの証明書を交付することができる。これらは、ポリシー・データ・ツリーの対応するサブブランチにより、ポリシーデータによって別々に取り扱うことができる。
【００９７】
例示的なポリシーにおいて、「ＡＩｄｅｎｔｉｔｙＣｅｒｔｉｆｉｃａｔｅｓ＠」と題した第１のブランチは、金銭的な取引を伴わない送信を取り扱う。このブランチは、４つの個別のサブブランチを含む。これらの第１のサブブランチは、「ＡＡｌｗａｙｓＡｃｃｅｐｔＦｒｏｍ＠」と題されており、信頼できると考えられる個人及び組織の名前を記載する「表ａ」への参照を含む。この表に記載された名前は、その会社が知っており黙示的に信頼しているものであり、これらの個人及び組織については、「デジタル証明書」がその発行人から取り消されているか否かを判断する必要はない。
「ＡＡｌｗａｙｓＣｈｅｃｋＦｒｏｍ＠」と題された第２のブランチは、「デジタル証明書」を常に検査すべき組織及び個人の名前が記憶されている別表である表ｂへの参照を含む。明らかに、表ａ及び表ｂのコンテントは、好ましいシステムのユーザの経験に依存するものになり、ユーザの入力したものに任されることになる。
【００９８】
「ＡＣｈｅｃｋＩｆＤａｙｓＳｉｎｃｅＣｅｒｔｉｆｃａｔｅＲｅｃｅｉｖｅｄＦｒｏｍＣｏｍｐａｎｙ＠」と題された第３のブランチは、有効な「デジタル証明書」会社からの受領以降の期間を指定しており、この期間内では、その会社から受領されたあらゆる更なる「デジタル証明書」の検査は不要とみなされる。この場合、その期間は１０日間と設定されている。
「ＡＣｈｅｃｋＩｆＤａｙｓＳｉｎｃｅＬａｓｔＲｅｃｅｉｖｅｄＴｈｉｓＣｅｒｔｉｆｉｃａｔｅ＠」と題された第４のブランチは、個別の「デジタル証明書」の場合の同様の期間を指定する。図示した例においては、ポリシーデータは、いかなる所定の識別の「デジタル証明書」に関する確認の検査も３０日毎のみに行う必要があると指定する。ここでもまた、これらのブランチの両方で指定された日数は、決めるのは好ましいシステムのユーザに任される。有効な「デジタル証明書」が受領されてから経過した期間は、「デジタル証明書」及びデータベースに記憶された関連データを参照することによって判断することができる。受信される度ではなく「デジタル証明書」を定期的に検査することにより、検査するのに使う費用を節約することができる。また、「ＭｏｎｅｔａｒｙＣｅｒｔｉｆｉｃａｔｅ」ブランチは、それぞれ、表ｘ及び表ｙを参照する「ＡｌｗａｙｓＡｃｃｅｐｔＦｒｏｍ」ブランチ及び「ＡｌｗａｙｓＣｈｅｃｋＦｒｏｍ」ブランチを含む。表ｘには、「デジタル証明書」の状態検査が不要である組織及び個人が記載されており、表ｙには、検査が常に必要とされるもの全員が記載されている。また、「ＭｏｎｅｔａｒｙＣｅｒｔｉｆｉｃａｔｅ」ブランチは、全ての「デジタル証明書」を検査しなければならない閾値取引金額を指定する「ＣｈｅｃｋＡｍｏｕｎｔＥｘｃｅｅｄｓ」ブランチ、及び、最後に、最近受信されて確認された「デジタル証明書」に対して検査を行うための２つの条件を定める「ＩｆＲｅｃｅｎｔｌｙＣｈｅｃｋｅｄ」ブランチを含む。「ＩｆＲｅｃｅｎｔｌｙＣｈｅｃｋｅｄ」ブランチにより、ユーザは、過去の取り消し検査から特定の期間内、この場合は３０日内に受信された小額、この場合は５０００ドルについての取引に関して受信された「デジタル証明書」は確認する必要はないことを指定することができる。
【００９９】
図１１は、図９に示したポリシーデータと対話するプラグイン・モジュール処理を示す。この処理は、図８に示したものの副処理であり、段階Ｓ２０４で発生し、それによって判断段階Ｓ２０６に進み、プラグイン・モジュールは、受信した「デジタル証明書」の状態のオンライン検査を行うか否かを判断する。この副処理は、段階Ｓ２２０で始まり、そこから制御は段階Ｓ２２２に移り、メッセージに署名するのに使用された「デジタル証明書」のクラスからその取引が金銭的なものであるか否かが判断される。取引が金銭的なものであった場合、制御は段階Ｓ２３２に流れ、この段階は、ポリシーデータの「ＡｃｃｅｐｔａｎｃｅＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチの「ＭｏｎｅｔａｒｙＣｅｒｔｉｆｉｃａｔｅ」ブランチ内の各ブランチに対応する判断段階チェーン内の第１のものである。
【０１００】
段階Ｓ２２２において、取引が金銭的なものではないと判断された場合、制御は段階Ｓ２２４に移り、この段階は、ポリシーデータの「ＡｃｃｅｐｔａｎｃｅＣｏｎｆｉｄｅｎｃｅＲａｔｉｎｇ」ブランチの「ＩｄｅｎｔｉｔｙＣｅｒｔｉｆｉｃａｔｅｓ」ブランチに対応する判断段階チェーン内の第１の判断段階である。チェーン内の判断段階の各々において、ポリシーデータの「ＩｄｅｎｔｉｔｙＣｅｒｔｉｆｉｃａｔｅｓ」ブランチの各サブブランチに指定された条件が満足されているか否かを確かめるために単純な検査が行われる。その検査結果により、制御は、「デジタル証明書」の信用が確立されているので「デジタル証明書」の状態のオンライン検査は不要である段階Ｓ２４２か、又は、信用が確立されていないのでオンライン検査が必要とみなされる段階Ｓ２４４か、又は、チェーンの次の判断段階かのいずれかに流れる。
【０１０１】
すなわち、「デジタル証明書」の送信者が「ＡＡｌｗａｙｓＡｃｃｅｐｔＦｒｏｍ＠」表である表ａに記載されているか否かが判断される判断段階Ｓ２２４において、「デジタル証明書」の送信者が表Ａに記載されていた場合、制御は、判断段階Ｓ２２４から段階Ｓ２４２に流れ、信用が証明書に確立されて副処理が終わり、図８の段階Ｓ２０８に戻る。送信者が表Ａになかった場合、制御は、段階Ｓ２２４からチェーン段階Ｓ２２６内の次の判断段階に流れ、「デジタル証明書」の送信者が「ＡＡｌｗａｙｓＣｈｅｃｋＦｒｏｍ＠」表である表ｂに記載されているか否かが判断される。同様に、送信者がこの表に記載されていた場合、制御は段階Ｓ２４４に流れ、「デジタル証明書」の状態のオンライン検査が必要であるとみなされる。制御は、副処理の段階Ｓ２４４から図８の段階Ｓ２１０に戻る。
【０１０２】
「デジタル証明書」の送信者が表ｂに記載されていなかった場合、制御は、判断段階Ｓ２２６から、ポリシーデータに記載されたサブブランチとして記載されたその次の条件を表すチェーン内の判断段階に流れる。すなわち、判断段階Ｓ２８８において、この「デジタル証明書」が過去３０日間において確認されたか否かに関して検査が行われる。これは、記憶された「デジタル証明書」のデータベースにおいてその「デジタル証明書」を調べ、記憶された情報からその「デジタル証明書」が以前に検査された日付を抽出する段階を伴うことになる。「デジタル証明書」の状態が過去３０日間で検査されていた場合、制御は段階Ｓ２４２に流れ、そこで信用が確立される。記憶された「デジタル証明書」の情報から、過去３０日間において検査されていなかったことが分った場合、制御は、段階Ｓ２２８から判断段階Ｓ２３０に流れ、別の「デジタル証明書」が同一の会社から受信されたか否か、及び、その「デジタル証明書」が過去１０日以内に検査されたか否かを見るために検査が行われる。この判断では、やはり、記憶された「デジタル証明書」のデータベース及びこれらの「デジタル証明書」に関係する情報を検査することが行われる。他の「デジタル証明書」が過去１０日以内に検査されていた場合、制御は段階Ｓ２４２に流れ、受信された「デジタル証明書」の信用が確立される。そうでない場合は、制御は段階Ｓ２４４に流れる。
【０１０３】
金銭的な送信の場合、ポリシーデータで定められた条件は、判断段階Ｓ２３２から判断段階Ｓ２４０へと進められる。判断段階Ｓ２３２において「デジタル証明書」の送信者が「デジタル証明書」の検査が不要であるとみなされている会社及び組織の名前を定めた表ｂに記載されていると分った場合、信用が確立され、制御は段階Ｓ２４３に移る。見つからなかった場合、制御は、判断段階Ｓ２３４であるチェーン内の次の段階に移る。判断段階Ｓ２３４において、「デジタル証明書」の送信者が「ＡＡｌｗａｙｓＣｈｅｃｋＦｒｏｍ＠」表である表ｂに記載されていると分った場合、信用は確立されず、制御は段階Ｓ２４４に移る。記載されていなかった場合、制御は段階Ｓ２３６に移り、取引が行われている金額が１０，０００ドルを超えているか否かが判断される。この判断は、証明書の発行人によって予め決められたか、又は、取引を形成する関連の電子メール内に含まれた金額を含む署名された取引データを参照しながら行われる。取引が１０，０００ドルを超える金額に対するものであると分った場合、又は、取引金額が送信されたデータを参照しても判断することができなかった場合、信用は確立されず、制御は段階Ｓ２４４に移る。そうでなかった場合、制御は段階Ｓ２３８に移り、この「デジタル証明書」が過去３０日間において検査されたか否かが判断される。ここでもまた、この判断は、記憶された「デジタル証明書」及び「デジタル証明書」に関係するデータを参照しながら行われる。証明書が過去３０日間において検査されていなかった場合、信用は確立されず、制御は段階Ｓ２４４に移る。検査されていた場合、制御は段階Ｓ２４０に移り、そこで、以前に判断された取引金額が５，０００ドルを上回るとみなされた場合、信用は確立されず、制御は段階Ｓ２４４に移る。取引金額が５，０００ドルを下回る場合、「デジタル証明書」を信頼することに対する受容可能なリスクとして分類されて信用が確立され、制御は段階Ｓ２４２に移る。
【０１０４】
これらの最後の２つの条件によって、本システムは、最近の取引履歴に基づいて証明書の状態を検査すべきか否かを判断することができる。例えば、取引が中庸な金額、すなわち、５，０００ドルよりも低い金額に関して当事者によってまさに行われようとしており、また、記録された取引及び証明書の詳細の検索によってごく最近に同一当事者が取引を行い、その時点で「デジタル証明書」が有効と確認されたことが分った場合、第１回後の非常に間もないうちにその当事者の証明書の有効性を再度検査することは不要であるというのは論拠のあることであり、２回目の確認手数料を支払うのではなく、その当事者を信用することが好ましい。
【０１０５】
ポリシーファイル内の命令は、会社内の個人の経験、及び、重大な危険性なしに許可可能とみなされる取引金額などに基づいて、その会社が自社顧客又は納入業者に対して有する信用のレベルを反映するように定めることができることが認められるであろう。また、ポリシーファイルは、その「デジタル証明書」の保持者の取引詳細の記録に関連して使用すべき更に総合的なポリシーを実行するように定めることができる。例えば、保持者によって提供されるいかなる取引も、金額、品物、及び、サービスがその取引履歴通りに維持されているか否かを確かめるために、以前に行った取引の記録に照らして比較することができる。そうでない場合、証明書の有効性を検査してまだ有効であり送信者の身元を特定するものであることを確認することが望ましいであろう。取り消されていた場合には、第三者が元の保持者の個人キーを取得して、不正な取引を行おうとしている可能性がある。
【０１０６】
段階Ｓ２０４においてポリシーデータを検査した後、「デジタル証明書」の信用は、確立されているか又は確立されていないことになる。判断段階Ｓ２０６において、信用が確立されていた場合、制御は段階Ｓ２０８に移り、その取引を含む送信が受理される。次に、制御は段階Ｓ２００に移り、そこでモジュールはフローから出て、ウェブブラウザの場合は図３のポイントＡに、又は、電子メールクライアントの場合は図５のポイントＡに戻る。
【０１０７】
段階Ｓ２０６において「デジタル証明書」の信用が確立されなかった場合、制御は段階Ｓ２１０に移り、オンライン確認検査が「デジタル証明書」に対して行われる。これは、「デジタル証明書」が取り消されたか否か、又は、「ｅＣｏｍｍｅｒｃｅ」取引の場合には「デジタル証明書」の発行人が取引で約束された金額の保証を確認することになるのか否かを見るために検査する段階を伴うであろう。次に、制御は段階Ｓ２１２に移り、その証明書に関してデータベースに記憶された有効性状態が更新される。次に、制御は段階Ｓ２１４に移り、そこで証明書が無効と判明した場合、制御は段階Ｓ１９８に移り、取引は拒否されるか又は段階Ｓ２０８に移り、そこで取引が受理される。取引の拒否とは、開かれる前に受信者のメールボックスから削除されるか、又は、その送信に「拒否」という語又は何らかの他のインジケータが記載されることを意味するであろう。段階Ｓ１９８又はＳ２０８のいずれかの後、制御は段階Ｓ２００に移り、そこでモジュールはフローから出る。取引が進行することを許可された時は常に、データベースは、その情報が今後の確認検査の必要性を判断する際に使用することができるように、日付及び金額のような取引に関する情報を含むように更新される。
【０１０８】
情報の記録
好ましいシステムはまた、オンラインで実行される取引の取引情報を記録する自動的な方法を提供する。この関連において、「Ａｔｒａｎｓａｃｔｉｏｎ＠」及び「ＡｅＣｏｍｍｅｒｃｅ ｔｒａｎｓａｃｔｉｏｎ＠」という語は、インターネット上、又は、会社の同一ネットワーク上でさえも、２人の当事者間で為された金額又は金額に相当するものを約束する同意を意味するように意図されている。一般的は、ユーザ自身は、該当電子記録のハードコピーを取ることによって、又は、コンピュータ上のファイルにあらゆる電子記録のコピーを積極的に記憶することによって取引情報を維持する責任がある。これらの記録を維持するのに手作業の方法に頼ることは、明らかに信頼性がなく労動集約的である。
【０１０９】
一方、好ましいシステムは、取引が始まったか又は行われていることのインジケータを求めて本システムによって処理された全ての通信の情報内容を走査する。このようなインジケータは非常に多い。最も直接的なものは、大半のウェブページは取引が実行される前に機密リンクをネゴシエートしてその後そのリンクを閉じるため、リンクが機密リンクであるか否かということである。リンクが機密リンクであるか否かの判断は、宛先ウェブページの「ＵＲＬ」を検査することによって達成される。機密リンクは、接頭語「ｈｔｔｐ」の後の「ｓ」によって表示される。従って、好ましいシステムの１つの作動モードは、リンクが機密リンクである間にウェブページに送信された全てのデータを記録することである。また、好ましいシステムは、機密リンクをネゴシエートするが「ｅＣｏｍｍｅｒｃｅ」サイトではない、すなわち、購入をするため以外に接続されているものであってこれらのページに送信されたデータを記録しないウェブページの記録を維持する。このようなウェブページは、電子メールサービスを行うマイクロソフト製の「ホットメール」ウェブページであろう。
別のインジケータは、単にサイトの「ＵＲＬ」であろう。この場合、好ましいシステムは、オンライン取引会社のものとして特定されたウェブページに送信された全てのデータを記録するように構成することができる。他のインジケータは、識別されたカード番号、電子領収書、販売を確認する電子メール、「デジタル証明書」特にデジタル保証証明書の使用、又は、購入コードであろう。
【０１１０】
取引が発生していると特定された状態で、好ましいシステムは、ユーザ及び特定された業者間の各通信をそっくりそのまま記憶することによって、又は、取引を走査して日付、金額、品物の種類、及び、数量のような特定の詳細を抽出することによって、その取引の詳細を記録することができる。
取引データの記録は、取引の終了が特定された時、又は、購入者と業者間の所定の数の取引が行われた後に停止することができる。同様に、取引が特定されると、好ましいシステムは、取引の第１の認識された送信直前に行われたキャッシュされた所定数の送信をデータベースに記録することができる。
【０１１１】
これは、例えば、送信が発生しているという第１のインジケータがクレジットカード番号又は電子領収書の検出である時には、それらが取引の正に終了時に受信される可能性が高いので有益であろう。従来の送信は、例えば、購入されている品物又はサービスに関する情報を含むウェブページ、又は、仕様又は納品条件が同意された電子メールの交換から成るものとすることができる。従来の送信は、取引が検出されたものと同一の形式、異なる形式、又は、各形式の混合であることが全く可能であることに注意すべきである。例えば、ユーザは、ウェブサイトｗｗｗ．ａｂｃ．ｃｏｍを訪れて品物の詳細を取得し、次に「ｏｒｄｅｒｓ＠ａｂｃ．ｃｏｍ」に送られる電子メールで注文することができるであろう。
好ましいシステムは、取引詳細を中央共通データベース４２に記録する。更に、データベースは、ローカルファイル又はネットワーク上のサービスとしてもよい。データベースに記憶された情報は、必要な認定を有する人のみがアクセスすることができるように公知の暗号化技術を使用して暗号化することができる。
【０１１２】
図１２は、電子取引がオンラインで行われている時期を特定するためのモジュールの例示的な実行の作動図である。図１４は、好ましいシステムが識別された取引をデータベースに記録する処理を示し、図１５は、好ましいシステムによって識別された取引を所定の承認ポリシーに基づいて承認又は拒否することができる様子を示す。
次に、図１２を参照して、オンライン取引が発生している時期を特定するためのモジュールの作動について説明する。
モジュールは、段階Ｓ２５０で、データの受信に応答して又はユーザが遠隔サイトへのデータ送信を開始したのに応答して作動を開始する。これは、ウェブブラウザでの実行の場合、図３に示すように、それぞれポイントＡの後又はポイントＣの後、また、電子メールクライアントでの実行の場合、図５に示すように、それぞれポイントＡ又はＢの後となる。
【０１１３】
次に、制御は段階Ｓ２５２に移り、ウェブブラウザの場合には、機密リンクがデータを送信するサイトとデータを受信するサイトとの間でネゴシエートされたか否かが判断される。これは、上述したように、接続された「ＵＲＬ」アドレスに問い合わせるか、又は、ウェブブラウザに質問して暗号化が採用されているか否かを確認することによって達成することができる。電子メールメッセージの場合、この段階は省略され、制御は、直接段階Ｓ２６０に移る。ウェブブラウザによるオンライン取引は、通常、名前及びアドレス、及び、クレジットカード番号又は他のアカウント特定情報のような個人情報の送信を伴うことから、当然のことながら、通常は機密リンクがネゴシエートされる。従って、機密リンクの存在だけで取引が行われていることを十分に示すものになる。しかし、機密性を有する接続は、取引詳細の送信以外の理由からもネゴシエートすることができる。従って、段階Ｓ２５２において、接続が機密のものであると判断された場合、制御は段階Ｓ２５４に移り、接続が為された遠隔サイトのアドレスは、オンライン取引を行う機能を提供していないが機密性接続は確かに確立している公知のサイトのリストに照らして検査される。マイクロソフト製の「ホットメール」サイトなどのブラウザベースの電子メールサイトは、１つのこのような例である。次に、制御は段階Ｓ２５６に移り、以前の検査に基づく判断が行われる。サイトアドレスが、取引の実施を促進しないものである非「ｅＣｏｍｍｅｒｃｅ」サイトと特定された場合、次に、取引が発生する可能性があるか否かが判断され、制御は、取引内容を更に検査するために段階Ｓ２６０に移る。段階Ｓ２５６において、サイトアドレスが公知の非「ｅＣｏｍｍｅｒｃｅ」サイトと特定されなかった場合、オンライン取引が発生していると仮定され、モジュールは段階Ｓ２５８でフローから出る。
【０１１４】
段階Ｓ２５２で機密性の接続が確立されていないと判明した場合、又は、機密性接続は確立されているが、段階Ｓ２５６で判断されたように、公知の非「ｅＣｏｍｍｅｒｃｅ」サイトに対してであるか又はその送信が電子メールであった場合、制御は段階Ｓ２６０に移る。判断段階Ｓ２６０において、送信の内容に対するいくつかの検査のうちの第１の検査が、それが取引の一部であるか否かを判断するために行われる。段階Ｓ２６０において、送信は、クレジットカード番号を含むか否か確認するために走査される。これを行うための方法は、図８を参照して説明された。クレジットカード番号が送信内で見つかった場合、取引が発生しているに違いないと仮定され、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。クレジットカード番号が見つからなかった場合、制御は、代わりに判断段階Ｓ２６２に移り、送信がアカウントコードを含むか否かを確認するために走査される。アカウントコードは、（例えば）この段階の実行時にモジュールによってアクセスされる個別のファイルに記憶することができ、又は、代替的に、アカウントコードは、メッセージのテキストに表示される「アカウント番号」又は類似の文字のようなファイル名などの送信内の説明データ内で識別することができる。
【０１１５】
判断段階Ｓ２６２において、アカウントコードが見つかった場合、送信は取引の一部を成すと仮定され、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。アカウントコードが見つからなかった場合、制御は段階Ｓ２６４に移り、ウェブブラウザの場合には、「ＵＲＬ」がデータベース内のファイルに記憶された公知の「ｅＣｏｍｍｅｒｃｅ」の「ＵＲＬ」リストと比較される。判断段階Ｓ２６６において、その比較に関する判断が行われる。「ＵＲＬ」が公知の「ｅＣｏｍｍｅｒｃｅ」ページにおけるもの又は公知の組の「ｅＣｏｍｍｅｒｃｅ」ページ内のものであると判明した場合、「ｅＣｏｍｍｅｒｃｅ」取引が行われていると判断され、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。同様に、電子メールの場合には、宛先アドレスが公知の「ｅＣｏｍｍｅｒｃｅ」の電子メールアドレス、例えば「ｏｒｄｅｒｓ＠ａｂｃ．ｃｏｍ」のリストと比較され、適合するものが見つかった場合は、「ｅＣｏｍｍｅｒｃｅ」取引が行われていると判断され、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。
説明した検査は、送信が「ｅＣｏｍｍｅｒｃｅ」取引の一部でありそうであるか否かを判断するために為し得る可能な検査を単に表しているに過ぎず、網羅したものであることを意図していない。更に、検査が図示されている順番には特別な意味はない。順番は、単に、図１３を参照して分るようにポリシーデータの構造に依存する。
【０１１６】
段階Ｓ２６８において、上述のものに加えて、例えば、データ内に置かれた購入コード又は組込コードを検索するなど、会社が採用することが望ましいと判断する取引のインジケータの有無に関する任意の更なる検査を表す一般的な検査が図示されている。好ましいシステムにおいて使用されているウェブブラウザ又は電子メールクライアントにより、ユーザが、その送信は取引の一部であるので記録すべきであることを示すために、組込コードで送信をマークすることができることが好ましい。また、組込コードは、ウェブサイト又は取引データの一部をユーザのワークステーションに送信する電子メールクライアントによってデータ内に置くことができる。
【０１１７】
サイトが公知の「ｅＣｏｍｍｅｒｃｅ」サイトと認識されなかった場合、制御は段階Ｓ２６６の後にこの段階に移り、そのような取引インジケータが段階Ｓ２６８において見つかった場合、取引は発生しているとみなされ、制御は段階Ｓ２５８に移り、そこでモジュールはフローから出る。段階Ｓ２６８でこのようなインジケータが見つからなかった場合、取引は発生していないとみなされ、モジュールは、段階Ｓ２５８でフローから出る。フローから出た後、データは、図３及び図５のポイントＣ及びＢの後にそれぞれ送信するか、又は、図３及び図５のポイントＡで受信されてから処理することができる。
【０１１８】
説明した例において、その目的は、取引が発生しているという単なる疑いがある場合に送信及び可能性がある取引の詳細を記録し始めることである。取引の一部ではないデータの記録は、取引を全く記録しないよりも好ましいと仮定される。図１３は、「ｅＣｏｍｍｅｒｃｅ」取引が発生していることを識別し、取引データの記録方法を制御するために使用されたポリシーデータの図である。ポリシーデータは、「ＡＩｄｅｎｔｉｆｉｃａｔｉｏｎ＠」及び「ＡＴｅｒｍｉｎａｔｉｏｎ＠」という２つの個別のサブブランチに細分化されるポリシー・データ・ツリーの「取引」ブランチによって表現される。「Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」ブランチ自体は、図１２で示した処理で行われた判断に対応する５つのサブブランチに分けられる。これらのサブブランチのうち、「ＡＩｆＣｏｎｎｅｃｔｉｏｎＧｏｅｓＳｅｃｕｒｅ＠」と題されたサブブランチによって、ユーザは、プラグイン・モジュールがウェブサーバとの接続が機密になったことを検出した時に記録を開始すべきであるか否かを指定することができる。このサブブランチで指定された諸条件は、図１２に示した判断段階Ｓ２５２に対応する。図１２に示した制御の流れは、図１３に示したポリシー・データ・ツリーの種々のブランチに指定された条件のレイアウトに対応することは、図１２及び図１３を参照すれば認められるであろう。「ＩｆＣｏｎｎｅｃｔｉｏｎＧｏｅｓＳｅｃｕｒｅ」ブランチの「ＥｘｃｌｕｄｅｄＳｉｔｅｓ」ブランチは、機密サイトをネゴシエートすると知られているが「ｅＣｏｍｍｅｒｃｅ」ウェブサイトではないと知られているウェブサイトが記載される表ｑへの参照を含む。表ｑは、図１２に示した処理の段階Ｓ２５６において参照される。
【０１１９】
「ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」ブランチの次のサブブランチは、「ＡＩｆＣｒｅｄｉｔＣａｒｄＮｕｍｂｅｒＰｒｅｓｅｎｔ＠」と題されており、これによって、ユーザは、送信されている又は受信されているデータの記録を開始するためにクレジットカード番号の検出を使用すべきであるか否かを指定することができる。このサブブランチは、判断段階Ｓ２６０に対応する。「ＩｆＣｒｅｄｉｔＣａｒｄＮｕｍｂｅｒＰｒｅｓｅｎｔ」ブランチの「ＰｒｅｖｉｏｕｓＰａｇｅｓ」サブブランチは、クレジットカード番号が検出されたウェブページ以前のウェブページの数を記載し、それはまた記録されるべきである。クレジットカード番号は一般的に取引終了時に提出されることから、このサブブランチの設置によって、取引の詳細及び要求を含む可能性が高い過去のウェブページを検出及び記憶することができる。これらのウェブページは、仮に取引が特定された場合にもウェブページがキャッシュから検索されてデータベースに記憶されるように、好ましいシステムによって絶えずキャッシュされる。これについて、図１４を参照しながら更に詳細に説明する。
【０１２０】
「Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」ブランチの次のサブブランチは、「ＡＩｆＡｃｃｏｕｎｔｓＣｏｄｅＰｒｅｓｅｎｔ＠」と題されており、これによって、ユーザは、送信されているか又は受信されているデータ内のアカウントコードの検出をデータの記録を開始するためのインジケータとして取るべきであるか否かを指定することができる。アカウントコードは、図１２に示す段階Ｓ２６２において表ｒを参照して特定される。この表への参照は、「ＩｆＡｃｃｏｕｎｔｓＣｏｄｅＰｒｅｓｅｎｔ」ブランチの「ＡｃｃｏｕｎｔＣｏｄｅｓ」サブブランチに含まれている。この表はまた、クレジットカード識別に関して上述したものと類似の方法で記録すべき以前のウェブページ数を示すが、この場合、記録すべき以前のウェブページ数は表ｒに記憶されており、ウェブページの異なる数を各検出アカウントコードに対して指定することができることに注意すべきである。
【０１２１】
「ＩｆＫｎｏｗｎＥＣｏｍｍｅｒｃｅＳｉｔｅ」ブランチによって、ユーザは、「ｅＣｏｍｍｅｒｃｅ」取引が行われると知られているサイト、サイトの一部、又は、単一のサイトに対応している「ＵＲＬ」のリストを指定することができる。現在のページ「ＵＲＬ」は、取引が行われているか否かを判断するために、このリスト内のエントリと照合される。「ＫｎｏｗＳｉｔｅｓ」サブブランチは、公知の「ｅＣｏｍｍｅｒｃｅ」サイトの「ＵＲＬ」が記憶されている表ｓへの参照を含む。ウェブサイトの「ＵＲＬ」が公知の「ｅＣｏｍｍｅｒｃｅ」サイトであるか否かの判断は、図１２の段階Ｓ２６４後の判断段階Ｓ２６６において行われる。最後に、「ＩｆＯｔｈｅｒＩｎｄｉｃａｔｉｏｎＰｒｅｓｅｎｔ」ブランチは、ユーザが他のインジケータの判断をデータ記録の開始点として使用すべきであるか否かを指定する方法を提供する。「Ｋｅｙｗｏｒｄｓ」及び「ＰｒｅｖｉｏｕｓＰａｇｅｓ」と題されたこのブランチの２つのサブブランチは、検出し得る可能なインジケータ、この場合は表ｔに記載されたキーワードと、キーワードが検出された場合に記憶することが必要とされる以前のページ数とを指定する。
【０１２２】
「取引」ブランチの「終了」ブランチは、送信されている又は受信されているデータの記録を終了するのに使用される条件を指定する４つのサブブランチに分かれる。各サブブランチは、取引の終了を定義することができる条件を定める。「ＡＩｆＣｏｎｎｅｃｔｉｏｎＧｏｅｓＩｎｓｅｃｕｒｅ＠」と題された第１のブランチによって、ユーザは、記録が停止されるように、ウェブブラウザによる機密性接続の廃止が取引の終了を示すことを指定することができる。他のサブブランチは、ウェブサイトが変更された時に記録が停止する、デジタル領収書が受信された場合に記録が停止する、及び、取引が発生しているという表示後に２０種類のウェブページが受信された後に記録が停止することを指定することができる。
【０１２３】
この図に示したポリシーデータは特に、また他の図においても、それが各ユーザに独特なものであることを強調しなければならない。ユーザが「ＹＥＳ又はＮＯ」変数を相応に設定することにより、又は、例えば記録されるべきページ数を変更することにより特定の条件に対してアクションを起こすべきであるか否かを指定することができるばかりでなく、ブランチの構造及び配置、及び、それらのブランチで指定された条件もまた、ユーザ毎に異なっていてもよい。例示的なポリシーは、ウェブブラウザ環境における取引の記録を説明する一方、類似のポリシーは、電子メール環境を制御し、機密性接続のオプションを省略するが、クレジットカード番号、アカウントコード、又は、電子メール内の他の識別可能な情報の検出時に、又は、電子メールが公知の「ｅＣｏｍｍｅｒｃｅ」アドレスに送られた場合に電子メールを記録するようにポリシーを定義することを可能にすることが認められるであろう。
【０１２４】
取引を識別する方法の全ての利点は、その方法が好ましいシステムと遠隔サイトとの間の送信を記録するための手段と共に利用された時に実現される。これによって、ユーザが実行した全ての送信の記録を自動的に保管及び維持管理することができる。記録は、受信又は送信された各伝送の紙によるコピーを取る必要もなく更新された状態で保管することができる。従って、会社の記録保管は、かなり容易かつ正確になる。
【０１２５】
図１４は、取引を含む送信を記録するためのモジュールの作動を示す。モジュールは、段階Ｓ２７０で開始される。
モジュールがウェブブラウザの一部として実施された場合、段階Ｓ２７０は、データ受信後に図３のポイントＡで、又は、遠隔サイトへデータを送信する直前に図３のポイントＣの後で開始される。モジュールが電子メールクライアントの一部として実施された場合、段階Ｓ２７０は、電子メールが受信された後に図５のポイントＡの後に、又は、ユーザによって作成された電子メールが受信者に送信される直前に図５のポイントＢの後に発生する。段階Ｓ２７０後に、制御は段階Ｓ２７２に移り、図９を参照して上述した取引を特定するための試験が行われ、「ｅＣｏｍｍｅｒｃｅ」取引が発生しているか否かに関して判断が行われる。次に、制御は段階Ｓ２７４に移り、取引は発生していないと判断された場合は、制御は、直接段階Ｓ２７６に移り、そこでモジュールはフローから出る。
【０１２６】
しかし、取引が発生していると判断された場合、制御は段階Ｓ２７８に移り、そこで、検出手段、送信者の身元、取引金額、又は、どの前回の送信（それがある場合）を特定された送信と共に記憶するべきであるか、及び、どのくらい詳細に送信を記録すべきかを判断する他のパラメータのうちの１つ又はそれ以上に関してポリシーが調べられる。例えば、ポリシーは、多額の金額を伴う取引を小額の取引よりも詳細に記録するように要求するかもしれない。作動におけるこの一例は、多額の金額を伴う取引のためにオンライン取引業者のウェブサイト上で取引を行っている時にアクセスされた全てのウェブページを記録するが、小額取引については電子領収書を含む送信のみを記録することであろう。
【０１２７】
ポリシーファイルはまた、記憶されるデータの量を判断するだけでなく、記録されるデータの性質を判断することができる。取引の一連のスナップショットとして送信又はウェブページ全体を、例えばウェブページがキャッシュメモリに記憶されるのと同一の方法で記録することができ、又は、代替的には、日付、業者の身元、及び、金額のような個々のデータ項目を送信又はウェブページから抽出して、それら自体又はスナップショットデータと共に記憶することができる。
このように、最も重要な取引には確実に十分な記録スペースがあるようにするために、記憶のためのメモリを最も効果的に使用することができる。また、記録される取引データの量は、業者の身元、地理的位置、ユーザの会社との取引履歴、及び、オファーされる品物及びサービスによる場合がある。
【０１２８】
図１３において、例示的なポリシーデータは、記録されるデータ量がメモリにキャッシュされたページから検索されるウェブページ数によって指定されるという簡単なシナリオを示している。数字は、クレジットカード番号、アカウントコード、又は、キーワードが特定されるか否かによって異なる。更に、表ｒは、異なるアカウントコードの認識で、記憶すべき以前のウェブページ数が異なる可能性があることを示しており、アカウントの相対的な重要性を反映している。
【０１２９】
この単純な事例をより高度な事例に拡張することは、ポリシーデータにより高いレベルの詳細を提供することによって達成することができる。ポリシー・データ・ツリーに対する追加のブランチは、品物及び／又はサービスに関係する会社名又は個人名又は特定のキーワード、及び、これらのキーワード及び名称に依存する記録すべきデータ量を指定することができるであろう。
また、これらの表は、記憶すべき異なる形式のデータ量を示すために拡張することができる。会社名、販売されていた物、及び、数量などのデータは、電子メールテキスト、ウェブページを構成する「ＨＴＭＬ」テキスト、又は、ウェブページの「ＤＯＭ」表現から抽出してデータベースに記憶することができる。
【０１３０】
キャッシュ内に記憶された全てのウェブページ又は情報を検索することができ、又は、代替的に、本システムは、取引の一部であると当初に特定されたページと共通の詳細を有するページのみを検索することができる。
代替的に、全ての記憶されたメッセージのリストは、ユーザが識別された取引に関係する送信を手作業で選択するようにユーザに提示することができる。
どれだけのデータを記憶すべきかの判断後に、制御は判断段階Ｓ２８０に移る。段階Ｓ２８０において、以前の送信を記憶すべきであった場合、制御は段階Ｓ２８２に移り、ローカルキャッシュに記憶された送信が検索される。ウェブブラウザの場合、これは、上述したように以前のページの所定数としてもよい。取引がウェブブラウザにおいて検索された場合、ポリシーはまた、例えば、同一の組織に送られたか又は同一の組織から受信された以前の電子メールメッセージがないかに関してキャッシュを検索するように命令することができる。これは、ブラウザ「ＵＲＬ」の部分を電子メールアドレスの部分と対照させることによって判断することができる。同様に、電子メールメッセージにおいて検出された取引によって、以前の電子メール及び以前のウェブページをキャッシュから検索することができる。次に、制御は段階Ｓ２８４に移り、識別された取引及びあらゆる検出された以前の送信は、システムデータベース４２に記憶される。
【０１３１】
段階Ｓ２８０において、以前の送信が必要とされた場合、制御は、直接段階Ｓ２８４に移り、取引として特定された送信がシステムデータベースに記録される。段階Ｓ２８４において送信が記憶される同時に、完全な記録を形成するためにユーザ身元、金額、及び、取引の相手方当事者などの関連データもシステムデータベースに記録することができるが、これは、ポリシーデータの命令に依存することになる。次に、制御は段階Ｓ２８６に移り、モジュールはフローから出る。
モジュールがフローから出た後の段階Ｓ２７６以降、データは、図３及び図５のポイントＡに続いてそれぞれ送信することができ、又は、図３及び図５のポイントＣ及びＢでそれぞれ受信された以降に処理することができる。
【０１３２】
送信が行われていると識別された状態で、ユーザと相手方当事者との間の全ての送信は、本システムが取引が完了されたことを検出するまで記録することができる。取引終点の検出及び記録の停止は、取引が行われているか否かの識別に関して上述したものと類似の方法で行うことができる。最も簡単な実施例は、電子領収書又は発送指図書が受信されるまで送信情報を記録することである。代替的に、送信の記録をユーザと相手方当事者との間の所定回数の送信が発生した後に、又は、取引が識別されてから一定の期間が経過した場合に停止させることができる。
送信は、ユーザがウェブサイトを変更する度にキャッシュが空になる場合には更に単純にすることができる。これによって、キャッシュメモリに必要とされるメモリを低容量に維持し、検索技術が使用される場合には検索する必要がある以前の送信回数も少なくなる。
【０１３３】
上述の方法はまた、取引が検出及び記録された後に発生する関連の送信を記録するのに使用することができることが認められるであろう。例えば、ウェブブラウザを使用して行われた取引の後には、一般的に、確認の電子メールが売り手から買い手に送られることになる。この電子メールは、注文番号、アカウント番号、品物の説明、及び、価格のような共通の特性を含むことから取引の一部を形成するものとして検出することができる。また、購入するのに使用された元のウェブサイトが「ａｂｃ．ｃｏｍ」であった時は、それをウェブサイトアドレスに類似したアドレス、例えば「ｃｕｓｔｏｍｅｒｓｅｒｖｉｃｅｓ＠ａｂｃ．ｃｏｍ」から送ることができる。所定の期間内に発生するその後の送信のみが元の取引に関連するものであるとみなされるように時間要素が使用されることが好ましい。
【０１３４】
取引情報の記録に加えて、例えば、組織が実際に電子商取引の採用によって真の生産性の恩恵を得ていることを保証するために、ユーザの挙動を解析する能力を有する管理を提供する他の情報を記録することが有利であろう。このような情報は、ユーザ自身の生産性に限定されずに全体的な処理に及び、例えば、ウェブ購入サイトのどれが購入処理に関して最も効率的か、従って購入経費を低減する際の最大の利点はどれにあるかを判断するためにウェブ購入サイトを比較することを可能にする。好ましいシステムは、購入に掛かる期間、購入を完了するのに必要とされるキーストローク数及びマウスクリック回数、及び、ダウンロードするページ又は受信する応答をユーザが待つ間の「アイドル」時間の量のような更なる情報を記録することによってこれに準備する。この情報は、取引記録と共にデータベースに記録することができ、統計的な解析を取引の範囲に亘って実施することができる。
【０１３５】
取引に掛かった時間は、タイムスタンプを受信された送信の各々と関連付けることによって判断することができる。取引が完了していると判断された時、第１の送信（段階Ｓ２８２においてキャッシュから取り戻されたものとしてもよい）に付随するタイムスタンプを最終送信に付随するタイムスタンプから差し引き、全体的な取引期間となるその結果が段階Ｓ２８４においてデータベースに記憶される。代替的に、第１の送信と最終送信とをデータベースに記録した後で取引期間を計算することができる。キーストローク数及びマウスクリック回数は、オペレーティングシステム内への標準的な「ウィンドウズ」の「フック」を使用して「マイクロソフトウィンドウズ」ベースのシステムにおいて判断することができる。このような技術は、マイクロソフト・コーポレーションのウェブサイト（ｈｔｔｐ:／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ ／ｄｅｆａｕｌｔ．ａｓｐ？ｕｒｌ＝／ｌｉｂｒａｒｙ／ｅｎ−ｕｓ／ｄｎｍｇｍｔ／ｈｔｍｌ／ｍｓｄｎ＿ｈｏｏｋｓ３２．ａｓｐ）で利用可能である、１９９３年７月２９日付けのザ・マイクロソフト・ディベロッパー・ネットワーク・テクノロジー・グループのカイル・マーシュ著の文書「ウィン３２フックス」において更に詳しく説明されている。
【０１３６】
好ましいシステムは、受信された各送信間で発生するキーストローク数（「ＷＨ＿ＫＥＹＢＯＡＲＤ」フックを使用）及びマウスクリック回数（「ＷＨ＿ＭＯＵＳＥ」フックを使用）のカウンタを維持し、これらの総数を受信された送信と関連付ける。別のアプリケーションに焦点がある間（例えば、ユーザが一時的に別のアプリケーションに切り替えた場合）に発生するキーストローク及びマウスクリックは無視される。取引が完了していると判断された場合、第１の送信（段階Ｓ２８２においてキャッシュから取り戻されたものとしてもよい）と最終送信との間のキーストローク及びマウスクリックの総数が互いに加えられ、その結果（取引全体でのキーストリング及びマウスクリックの総数）が段階Ｓ２８４においてデータベースに記憶される。同様に、ウェブサイト取引応答時間は、各発信伝送要求が送られる時間に注目し、応答送信が受信される時間からそれを差し引くことによって測定することができる。取引の開始と終了との間の応答時間を合計すれば、ユーザがウェブサイトを待つのに費やした総時間が得られる。同様に、好ましいシステムはまた、伝送が受信された時間と応答が送信された時間との間の時間であるユーザ応答時間を計数する。
【０１３７】
好ましいシステムはまた、ユーザの応答時間のうち、どれだけの時間がデータ入力に費やされたかを計算するので、従って、ユーザが着信伝送を「吸収する」のに必要とされた時間（その差として）を判断することができる。データ入力に費やされた時間は、「ストップウォッチ」を維持することによって判断される。ストップウォッチは、新しい送信が受信される毎にリセットされ、ユーザがキーストロークを入力するか又はマウスをクリックする時、常に直ちに再起動される。ユーザが所定の時間、例えば５秒間キーストロークを入力しなかったか又はマウスをクリックしなかった場合、本システムは、ユーザが現在以前の送信の詳細を吸収していると仮定してストップウォッチを止める。また、ストップウォッチは、キーストローク又はマウスクリックによって発信伝送を送信させた時に止められる。取引開始と終了との間のデータ入力に費やされた時間を合計すれば、ウェブサイトでデータ入力にユーザが費やした総時間が出る。合計時間は、今後の解析のために段階Ｓ２８４でデータベースに記憶することができる。
【０１３８】
好ましいシステムはまた、行われている取引をモニタして必要とみなされた場合には承認を得るために取引を自動的に紹介するための手段を提供する。この処理によって、大手企業は、ポリシーデータに定められた単一の組の基準を使用して自社従業員によって行われている取引をモニタして制御することができる。ポリシーデータは、ユーザが自分でその取引を行うことが許可されているか否か、又は、ユーザが会社の上層部からの許可を必要とするか否かを判断するために、取引が識別される度に参照することができる。その処理を、ここで参照すべきである図１５に示す。
【０１３９】
この処理を具体化するモジュールは、段階Ｓ２９０で開始される。この開始は、検討する必要がある取引の全ての関連詳細が判断されるとすぐに、かつ、取引が行われる前に行われることが好ましい。電子メールによる取引の場合には、品物及び価格などの詳細は、一般的に単一の電子メール内に含まれており、その電子メールの送信前に検討することができる。ウェブブラウザによる取引の場合には、取引の存在は、全ての詳細が分る前に検出することができ、その場合、全ての詳細が分るまで開始されない。これは、最終的な義務は、全ての関連の詳細が分ったかなり後になって、取引処理の最後の最後まで発生しないので一般的には問題にならない。取引及び関連の詳細の検出は、図１２を参照して上述した方法で判断することができる。図３及び図５をざっと参照すれば、その段階Ｓ２９０は、必要とされる詳細が分ると、ウェブブラウザによる実行の場合には図３のポイントＣの後に、又は、電子メールクライアントによる実行の場合には図５のポイントＡの後に発生することが分るであろう。
【０１４０】
制御は、段階Ｓ２９０から判断段階Ｓ２９２に移り、取引の詳細は、承認が必要とされるか否かを判断するためにポリシー設定に照らして比較される。この判断は、取引を行う従業員の身元又は地位、取引金額、又は、取引の相手方当事者に基づくものとすることができる。いくつかの場合においては、会社の財務担当取締役が各取引が行われる前にその各々を検討したいと思う場合のように、承認が常に必要とされるかもしれない。
【０１４１】
図１６は、取引が第三者からの承認を必要とするか否かを判断するため、及び、使用すべき妥当な承認者の身元を判断するために使用することができる例示的なポリシーデータの図である。この場合、ポリシーデータ内の条件は、取引金額と、取引の相手方当事者の「ＵＲＬ」アドレスとによって承認が必要とされるか否かを規定するものである。
関連のポリシーデータは、ポリシー・データ・ツリーの「取引承認」ブランチに定められている。このブランチは、４つのサブブランチに細分化されている。第１のブランチは、「ＭａｘｉｍｕｍＵｎａｐｐｒｏｖｅｄＴｒａｎａｃｔｉｏｎＡｍｏｕｎｔ」と題されており、取引の閾値金額を定義する。閾値を上回る金額に関する取引は、行われる前に承認者によって承認されなければならない。
【０１４２】
「ＭａｘｉｍｕｍＵｎａｐｐｒｏｖｅｄＭｏｎｔｈｌｙＡｍｏｕｎｔ」と題された第２のサブブランチは、ユーザが１ヵ月以内で行うことができる取引の金額を定義する。この場合、月間総額が２，５００ドルを超えるようなユーザによって行われたいかなる取引も、その閾値に到達した後に行われる更なる取引と同様に第三者からの承認を必要とすることになる。
「ＥｘｃｌｕｄｅｄＳｉｔｅｓ」と題された第３のブランチは、取引が行われる前に第三者からの承認を常に必要とする全てのサイトのウェブサイト及び電子メールアドレスを含む表を参照する。最後に、「Ａｐｐｒｏｖｅｒｓ」と題された最後のブランチは、可能な第三者の承認者の名前が記載されている表を参照する。各名前に並べて、その承認者が承認する権限を有する対象である最大取引金額及びその承認者が取引を承認することができない対象外サイトのリストがある。各場合の最も単純なものにおいて、承認者は、部長又は管理者などの取引を行うユーザと同一ネットワーク上にログインされた他のコンピュータユーザであろう。承認者は、その役割上の性格から、商事会社が行う金銭的な取引の責任を負い、また、その責任を負う権限を有するその会社の社員であることになる。また、承認者は、財務部専属者のような主としてこの役割のために採用された者のグループから得られるという可能性がある。
【０１４３】
取引ブランチの最初の３つのサブブランチの条件によって承認が必要とされると分った場合、取引限度が提案された取引の限度に等しいか又はそれ以上であり、かつ、関係サイトに対する取引の承認を禁止されていない承認者が見つかるまで承認者の表を走査することにより、妥当な承認者を見つけることができる。
図１６に示す例示的なポリシーデータは、ネットワーク内の単一のコンピュータユーザ又はユーザのグループに専用のポリシーデータであることが認められるであろう。他のユーザ又はグループは、異なる設定及び異なる承認者リストを有してもよい。
適切な承認者を判断するための条件は、ポリシー・データ・ツリーの新しいサブブランチを作成することによって導入することができることが認められるであろう。
【０１４４】
承認処理の作動は、例えば「ｅＣｏｍｍｅｒｃｅ」取引を含むものだけでなく、任意の種類の送信に拡張することができる。このような作動は、種々の条件が定義されるか、又は、ポリシーデータのサブブランチに例えば送信内で識別されてかつその作動基準とすべきユーザ名、アドレス、又は、キーワードを指定させることによって実行することができる。従って、特定の会社又は個人宛ての全ての電子メールによる送信は、承認を必要とさせるか、又は、所定の情報を含む全ての電子メールをキーワードの識別を通じて認識させることができる。
【０１４５】
承認が必要でないことが段階Ｓ２９２において判断された場合、制御は、直接段階Ｓ２９４に移り、そこでモジュールはフローから出る。段階Ｓ２９４の後、取引の送信が許可されてその取引を処理することができる。制御は、段階Ｓ２９４から図３のポイントＣに、又は、図５のポイントＢに戻る。
しかし、段階Ｓ２９２において、ポリシー設定を調べた後に取引の承認が必要とされると判断された場合、制御は段階Ｓ２９６に移り、取引の詳細は、その取引の適切な承認者を判断するために使用される。承認者は、自分のワークステーションか、又は、図２に示すように「オペレータ」コンソール４４などの承認者専用機能を有するワークステーションでログオンした会社従業員であってもよく、又は、自動化処理である場合さえもある。いくつかの部門を有する大企業の場合、各部門に対してそれぞれがその部署のアカウントをモニタする承認者グループを有することは有利であろう。これによって、例えば、その部署の長が購入又は特定の性格の購入を一時的に停止したいと判断した場合、取引が行われる前に拒否することができる。
【０１４６】
制御は、適切な承認者の判断後に段階Ｓ２９６から段階Ｓ２９８に移り、承認要求が、システム承認待ち行列１００を通じて指名された承認者に送信される。段階Ｓ２９８後、制御は判断段階Ｓ３００に移り、承認者からの応答が受信されたか否かが判断される。承認の要求が提出されるとすぐにタイマーが起動される。段階Ｓ３００において応答が受信されていない場合、制御は段階Ｓ３０２に移り、時間切れ時期が経過したか否かがタイマーから判断される。その時期が経過していないことを条件として、制御は、段階Ｓ３０２から段階Ｓ３００に戻り、本システムは、承認者からの応答を待ち続ける。従って、段階Ｓ３００及び段階Ｓ３０２によって、応答が受信されるまで、又は、制限時間になるまでシステムが待つというループが形成される。判断段階Ｓ３００において、応答が受信されると、制御は段階Ｓ３０４に移り、取引が承認又は拒否されたか否かによってアクションが取られる。
【０１４７】
取引が承認された場合、制御は、段階Ｓ３０４から段階Ｓ２９４に移り、そこでモジュールはフローから出て、送信を続行することが許可される。しかし、送信が承認されなかった場合、制御は、段階Ｓ３００から段階Ｓ３０６に移り、そこでモジュールはフローから出る。しかし、段階Ｓ３０６でフローから出ることによって、取引の送信が行われるのが防止され、ウェブブラウザの実施の場合には図３のポイントＡに、又は、電子メールクライアントの実施の場合には図５の段階Ｓ１３２の「ｃｏｍｐｏｓｅ ｅ−ｍａｉｌ」にユーザを戻す。
また、段階Ｓ３０２において、承認者からの承認が受信されずに「時間切れ」になったとみなされた場合、制御は、直接段階Ｓ３０６に移り、そこでモジュールはフローから出る。
【０１４８】
図１５の右側は、承認者に関して伴う段階を示す。承認処理は、段階Ｓ３１０において開始され、そこから、制御は段階Ｓ３１２に移り、承認者のコンピュータが新しい承認要求がないかシステム承認待ち行列に問い合わせる。次に、制御は判断段階Ｓ３１４に移る。段階Ｓ３１４において、未決の要求がなかった場合、制御は段階Ｓ３１２に戻り、システム待ち行列がもう１度ポーリングされる。これらの段階は、承認要求が受信されるまで、又は、承認者が承認段階を非活性にするまで繰り返される。
【０１４９】
段階Ｓ３１４において、承認要求が受信された場合、制御は段階Ｓ３１６に移り、承認要求がシステム待ち行列からダウンロードされ、承認者自身がその要求を承認又は拒否すべきか判断する。次に、制御は段階Ｓ３１８に移り、承認者の応答がシステム承認待ち行列に返送され、そこからユーザワークステーションに送信される。
制御は、段階Ｓ３１８から段階Ｓ１３２に移り、新しい承認要求がないかシステム承認待ち行列が問い合わせされる。承認処理は、状況によっては自動化することができることが認められるであろう。例えば、取引は、会社が十分な資金を有していない場合、予算金額を上回る場合か又は単に最大金額を上回る場合には自動的に拒否することができる。代替的に、このような自動化は、承認要求が為されることさえもないように、ユーザ処理の一部として設けることができるであろう。
【０１５０】
所定の取引を承認するか否かを判断する際には、承認者は、例えば、総価格及び納入業者などの単に概略的情報ではなく、購入されるものを正確に見定めることができるように、完全な見通しを有することができることが理想的である。好ましいシステムは、上述の送信を記録する機能を承認機能と組み合わせることによってこれに準備するものである。段階Ｓ２９８で提出された承認要求は、段階Ｓ２８４において記憶された取引情報のデータベース内の位置への参照を用いて補足される。承認者が段階Ｓ３１６において位置詳細を受信すると、システムは、取引を成す送信をデータベースから検索し、承認者が承認の判断を行う際に検討することができるように送信を適切な方法で表示する。作動は、その後通常通りに段階Ｓ３１８で続行される。明らかに、記録段階Ｓ２８４は、承認要求が段階Ｓ２９８で行われる前に行われることが重要であり、そうでない場合は、記録された情報は、まだ利用可能な状態ではないことになる。段階Ｓ２８４で取引は識別されているがまだ完了となっていない（まだ承認されていないために）ことになるから、段階Ｓ２８４において行われたデータベース記録は、取引を「未決」と識別するフラグを含むことが必要である。次に、このフラグは、取引が承認又は拒否されたことを示すために段階Ｓ３１６において更新することができ、又は、代替的に、承認が拒否された場合は、データベース記録は、取引が行われなかったので削除することができる。
【０１５１】
セキュリティ
好ましいシステムは、送信されているデータの識別された性質によって、適切なセキュリティ等級を送信に割り当てるための手段を提供する。割り当てられるセキュリティ等級は、自分の要望を反映するために、システムのユーザがポリシーデータを使用して設定することができる。
この場合におけるポリシーデータの最も単純な実施例は、従業員パスワード、雇用主パスワード、クレジットカード番号、及び、銀行取引詳細のような可能な形式のデータを第１の欄に含み、かつ、各データ形式に適切であるとみなされた目標とする暗号化強度（例えば、キー・ビット数による）を第２の欄に含むリストである。セキュリティレベルをデータの判断された性質によって割り当てる他の方法も、本発明の範囲内で採用することができることが認められるであろう。
【０１５２】
図１７は、様々な形式のデータについて適切な暗号化強度を定義するポリシーデータの例示的な図を示す。ポリシーデータは、ポリシー・データ・ツリーの個別のブランチに配置されたいくつかのキー値の対の形を取る。キーは、パスワード、クレジットカード番号、提出されたキーワード、及び、任意の他の提出されたデータに対する一般キーのような送信されているデータの形式を指定する。これらのキーに対応する値が、キーで指定されたデータの送信に適切とみなされるビットによる暗号化強度である。キー値の対は、ポリシー・データ・ツリーの「ＴｒａｎｓｍｉｔｔｅｄＤａｔａＳｅｃｕｒｉｔｙ」ブランチの「ＲｅｑｕｉｒｅｄＥｎｃｒｙｐｔｉｏｎＬｅｖｅｌ」ブランチのいくつかのブランチに配置される。従って、この例において、パスワードは、４０ビットという目標とする暗号化強度を有し、会社クレジットカード番号及び個人のクレジットカード番号は、いずれも１２８ビットの目標とする暗号化強度を有し、提出されたキーワードは、４０ビットの目標とする暗号化強度を有し、他の提出されたデータは、暗号化を必要としないことが分るであろう。
【０１５３】
「ＳｕｂｍｉｔｔｅｄＫｅｙｗｏｒｄｓ」ブランチは、機密性であり何らかの形の暗号化を必要とすると指定された特定の語又はストリング又はテキストを参照する。これらは、ユーザ名、アドレス情報、財務情報、又は、「極秘」又は「秘密」などの予め選択された語としてもよい。提出されたキーワードは、それらが記憶されている表又はファイルを参照することによって検出することができる。
更に、ポリシーデータの各ブランチは、一般的な暗号化強度を与える代わりに、例えば異なるパスワード又はクレジットカード番号が各パスワード又は数字に固有の対応する暗号化強度と共に記載されている表を参照することができる。
【０１５４】
セキュリティ等級が割り当てられると、プラグイン・モジュールは、そのセキュリティ情報の送信のために、ウェブサーバを用いてウェブブラウザによって確立されたリンクのセキュリティを判断するためにウェブブラウザに質問するか、又は、電子メールによる送信の場合、ユーザ又はアプリケーションが決定した暗号化設定がメッセージに適用されることになる。一般的に、これは、送信用データを符号化するのに使用された暗号化アルゴリズムの暗号強度になる。このような送信詳細は、ウェブサービスプロバイダからの「電子ハンドシェイク」の一部としてウェブブラウザによって受信される。
【０１５５】
機密リンクは、通常、右下角の閉じたパッドロックアイコンの存在によって「ブラウザ」ウィンドウに表示される。ユーザは、アイコンをクリックしてハンドシェイクによって供給されたセキュリティのレベルを質問することができる。これを行う際には、ユーザは「ＡＳＳＬ」確保形式の通知（１２８ビット）を受信するであろう。この通知の第１の部分には、使用された暗号化の形式が説明され、第２の部分では暗号化強度が説明されている。プラグイン・モジュールは、セキュリティレベルが提案された送信に適当か否かの判断に使用することができるように、このデータをブラウザから自動的に取得するように実施される。同様に、電子メールメッセージの場合、プラグイン・モジュールは、ユーザ又はアプリケーションが設定した暗号化設定がメッセージの送信前に使用されるべきであると判断する。
【０１５６】
モジュールは、指定された暗号化強度をリンク又はメッセージの暗号化強度と比較し、比較の結果によって以下のアクションのうちの１つを実行する。
ａ）リンクのセキュリティが送信されている情報の性質に適切である場合、モジュールは、情報が送信されることを可能にする。
ｂ）リンクのセキュリティが情報の送信に必要とされるものを上回る場合、モジュールは、そのセキュリティレベルで情報が送信されることを可能にするか、ウェブサーバ及びウェブブラウザと新しい適切なセキュリティレベルを自動的にネゴシエートしてそのレベルで情報を送信するか、又は、現在のセキュリティレベルは不要であることをユーザにプロンプト表示し、アクションを起こすようにユーザを促す。
ｃ）リンクのセキュリティが送信されている情報の性質には十分でなかった場合、モジュールは、送信が行われるのを防止してユーザに警告するか、ウェブサーバ及びウェブブラウザと新しい適切なセキュリティレベルを自動的にネゴシエートしてそのレベルで情報を送信するか、又は、電子メールの場合、暗号化強度の設定を自動的に上げるか、又は、現在のセキュリティレベルが不十分であることをユーザにプロンプト表示し、まだ送信の実行を希望するかどうかの確認をユーザに促す。
【０１５７】
プラグイン・モジュールは、決められた目標とするセキュリティレベルの差に応じるように構成し得ること、いくつかの方法で準備されること、及び、上記で概説したアクションは例示的なものにすぎないことが認められるであろう。
システムが取り得る更なるアクションには、異なるウェブページがユーザのマシンにダウンロードされるように要求すること、又は、機密性情報が送信されないように、提出されたフィールドデータを変更することが含まれるであろう。
【０１５８】
好ましいシステムのユーザによって送信されているデータをモニタするためのブラウザ又は電子メールプラグイン・モジュールの作動が、参照すべき図１８に示されている。モジュールは、段階Ｓ３２０において、ウェブサーバにデータが送信される直前に図３のポイントＣで、又は、電子メールが送信される直前に図５のポイントＢで作動を開始する。次に、制御は段階Ｓ３２２に移り、モジュールは、送信されようとしているデータの構文解析をしてクレジットカード番号を捜す。これを行う可能な方法は、図を参照して上述した通りである。データ内でクレジットカード番号が検出されなかった場合、制御は段階Ｓ３１４に移り、モジュールは、まさに送信されようとしているデータ内でパスワードを捜す。これを行うための方法は、図６を参照して上述した通りである。データ内にパスワードが見つからなかった場合、制御は段階Ｓ３１６に移り、モジュールは、データ内で会社アカウント又は購入コードを捜す。アカウント又は購入コードの認識は、ファイル内に会社のコードを記憶してこれらのコードを発信データ内に見つかる桁のストリームのいずれとも対照させるように試みることによって達成することができる。アカウントコードが見つからなかった場合、制御は段階Ｓ３１８に移り、モジュールは、送信されるデータ内の他の機密性データの指示を捜す。このような指示は、好ましくは検出に使用された個別のファイルで予め定義する必要があることになり、好ましいシステムのユーザの要件に依存することになる。この例には、会社が着手しているプロジェクトに関係する指定されたキーワード、プロジェクト表題自体、データ受信者又は送信者の個人的な詳細アドレス、又は、データ自体に含まれる「極秘」又は「私用」という語でさえも含まれるであろう。
【０１５９】
データが機密性であり、送信される前により強い保護を必要とするという指示が何も見つからなかった場合、送信は、現在の暗号化レベルで続行することが許可される。これは、いかなる暗号化も適用されることなく送信が行われることを意味するであろう。
しかし、段階Ｓ３２２から段階Ｓ３２８までにおける検査のいずれでも機密性とみなされるデータが明らかにならなかった場合、制御は段階Ｓ３３２に移り、セキュリティ等級が検出されたデータに割り当てられる。これは、検出されたデータをポリシーデータの所定のエントリと比較することによって達成される。
【０１６０】
ポリシーデータのブランチの各エントリは、そのデータの送信に使用することができる最小レベルである予め割り当てられた暗号化レベルを有する。全てのポリシー設定と同様に、表内のエントリ及び割り当てられた暗号化レベルは、好ましいシステムを使用する会社によりその要件に基づいて決定される。こうして、セキュリティ等級を割り当てることは、単に、パスワード、クレジットカード番号、又は、ポリシーデータ内の他のデータを調べ、対応する等級を読み取るということになる。ポリシーデータのサブブランチ上の表への参照を用いて、異なる暗号化強度を異なるパスワード及びクレジットカード番号などに割り当てることができる。
【０１６１】
適切なセキュリティレベルが段階Ｓ３３２において判断されると、制御は段階Ｓ３３４に移り、モジュールは、データが送信されているウェブサーバとネゴシエートされた暗号化レベルか、又は、メッセージを送信する前に電子メールアプリケーションによって使用されることになる暗号化レベルを判断する。これは、ウェブブラウザ又は電子メールアプリケーションに質問するか、又は、両方とも送信前に発生することになるリンクの確立又は電子メール暗号化要件の判断の時に暗号化強度変数を設定することにより達成することができる。
【０１６２】
次に、制御は段階Ｓ３３６に移り、目標とするセキュリティレベル、すなわち、暗号化強度が前段階において決定されたものと比較される。目標とする暗号化レベルが段階Ｓ３３４で決定されたものに等しいか又はそれ以下であった場合、送信されるデータに対する十分な保護があるとみなされ、制御は終了段階Ｓ３３０に移り、そこでモジュールはフローから出る。段階Ｓ３３０の後、制御は、モジュールがウェブブラウザ又は電子メールクライアントで実行されるかによって、図３のポイントＣ又は図５のポイントＢに戻る。その後、データの送信は、通常の方法で進行することができる。
【０１６３】
しかし、段階Ｓ３３６において、目標とする暗号化レベルが現在設定されているものを上回る場合、モジュールは、適切な暗号化レベルがネゴシエートされるまで送信の進行を可能にしない。制御は段階Ｓ３３８に移り、モジュールは、暗号化強度を上げることができるか否か判断し、暗号化強度を上げることができる場合は、制御は段階Ｓ３４０に移り、新しいより強力な暗号化されたリンクがネゴシエートされるか、又は、電子メールの場合にはより高い暗号化強度が設定される。
【０１６４】
利用可能な最高暗号化レベルは、ウェブサーバ及びウェブブラウザの両方、又は、電子メールの場合には電子メール送受信アプリケーションによって使用されているソフトウエアに依存する。そこで、適切な暗号化レベルが一方の当事者には利用可能ではなく、データの送信を進めることが決して許可されないという場合があり得る。更に、いくつかの形式のデータには、いかなる暗号化レベルもデータの保護には決して十分ではないことを示すようなセキュリティ等級が与えられる場合があり、すなわち、そのデータの送信が永久に妨げられる。
【０１６５】
リンクの再確立を試行するか、又は、電子メール暗号化設定をより高い暗号化強度に変更した後に、制御は、リンク又は設定が現在は適切な強度であることを保証するために段階Ｓ３３４に戻る。段階Ｓ３３８において適切な暗号化レベルを再ネゴシエートすることができなかったか、又は、暗号化強度を上げようとする試行が失敗に終わった場合、データを送信することは安全ではないとみなされ、制御は終了段階Ｓ３４２に移り、そこでモジュールはフローから出る。段階Ｓ３４２でフローから出た後、制御は、ユーザが送信を再検討して編集するか又は破棄するように、図３のポイントＡか、又は、図５の段階Ｓ１３２の「ｃｏｍｐｏｓｅ ｅ−ｍａｉｌ」に戻る。送信が防止される理由を説明する適切なメッセージもまたユーザに表示することができる。
従って、好ましいシステムは、データの送信ができるだけ安全であるように保証する方法を提供する。それは、ユーザが送信を機密にするのを忘れるという可能性を排除し、使用されるセキュリティレベルが不十分な場合はより適切なセキュリティレベルをネゴシエートする。
【０１６６】
「ウェブブラウザ」は、ユーザによって入力されたデータが安全でないリンクで正に送られようとしていることをユーザに警告する類似の機能を提供するか、又は、全てのメッセージを初期設定で暗号化する機能を提供することができる。しかし、好ましいシステムは、送信されるデータの内容を検査してそのセキュリティ要件を判断する能力を提供し、このようなセキュリティ要件、及び、判断されたリンクのセキュリティレベル（暗号化強度）に基づいて、送信を許可又は防止する。好ましいシステムは、人的エラーの可能性を低減する安全な送信のための大幅に改良されたシステムを提供することが認められるであろう。
【０１６７】
機密性情報に対する発信電子メールのモニタリング
機密性データが送信者と受信者との間で第三者によって妨害されるという問題に加えて、組織は、そのユーザによる機密性情報の故意の公開によりかなりの危険に晒されている。例えば、組織から退職する前に顧客リストのような極秘文書のコピーを「電子的に」盗むという方法は、容易に達成されて事実上追跡不可能であり、その結果広く行われている。ユーザにとって必要なことは、後で検索するために文書を自分の私用電子メールアドレスに送ることだけである。文書は、「ホットメール」などの「インターネット」のメールサービスを使用できるので、組織独自の電子メールシステムを通じて送ることさえしなくてもよく、無許可の「リーク」の追跡を現行の手段によっては事実上不可能にしている。
【０１６８】
適切な暗号化レベルがメッセージに適用されることを保証する手段をもたらすだけでなく、好ましいシステムは、潜在的に機密性と識別されたメッセージをユーザが知らないうちに自動的に再方向付けするか、又は、別の宛先にコピーすることを可能にする。このようなメッセージを再方向付けするか否かを判断する際には、好ましいシステムは、送信者の身元、意図された受信者の身元、意図された受信者のアドレスの性質、メッセージ内容の性質、メッセージに対するあらゆる添付ファイルの性質及び存在、メッセージが送信されるように意図された手段、及び、メッセージ及び／又はあらゆる添付物を暗号化するか否かを含むいくつかの要素を考慮に入れる。
【０１６９】
メッセージの性質は、１つ又はそれ以上のキーワード又はキーワードの組合せがないか走査することによって、又は、標準的な「自然言語クエリー」技術を使用することによって判断することができる。意図された受信者のアドレスの性質は、公知の「インターネット」メールサービスドメインのリストを参照することによって判断することができる。例えば、「ｈｏｔｍａｉｌ．ｃｏｍ」、「ｙａｈｏｏ．ｃｏｍ」、及び、「ａｏｌ．ｃｏｍ」は、全てが企業ではなく個人によって広く使用されている。同様に、アドレスは、送信者名との類似性がないか検査することができ、例えば、フレッド・スミスによってアドレス「ｓｍｉｔｈ９００＠ａｏｌ．ｃｏｍ」に送られたと分っているメールは、受信者アドレス内に「ｓｍｉｔｈ」及び「ａｏｌ．ｃｏｍ」の両方が含まれていることよって怪しいと考えることができる。メッセージの更なる検査は、メッセージが極秘データの無許可の公開である可能性を支持する場合があり、例えば、メッセージがメッセージテキスト及び件名が未記入の添付ファイルのみから成る場合、送信者は自分が単に読むだけのテキストを入力する可能性は低いので重要な手かがりとなる。メッセージが送信されている時の手段は重要な要素であり、例えば、ホットメールなどの「インターネット」メールサービスを使用して送られた送信は、通常の企業レベルの電子メールシステムを通じて送られたものよりもはるかに怪しいと考えることができる。
実際に「インターネット」メールサービスへのファイルの「アップロード」は潜在的に非常に怪しいので、好ましい実施形態は、このようなサービスへのファイルのアップロードを全く禁止する手段を提供する。
【０１７０】
メールを再方向付けする時に、好ましいシステムは、新しい受信者が自分に再方向付けされたということ、及び、誰に元々送られたのかを判断することができるように、本来意図された受信者のアドレスと共に、更なるテキスト、例えば「−−−−Ｒｅｄｉｒｅｃｔｅｄ Ｍａｉｌ−−−−」をメールの始めに追加する。
転送されたメッセージを暗号化すべきである場合、好ましいシステムは、第三者に対して暗号化又は暗号化されていないメッセージを再方向付けすることができる。好ましくは、送信者の暗号化キーがメッセージと共に送られ、第三者に対して、既に暗号化されている場合にはメッセージを暗号解読し、送信のために本来の送信者の暗号化キーでメッセージを暗号化する手段が提供される。
【０１７１】
好ましいシステムはまた、「−−−−Ｒｅｄｉｒｅｃｔｅｄ Ｍａｉｌ−−−−」テキストを捜すことによって、再方向付けされた（すなわち、本来意図された受信者ではないユーザに送られた）着信メールを識別する。このようなメールには、新しい受信者の注意を喚起するために、特別なアイコンを使用することにより、又は、本人に通知するためのメッセージボックスを設置することによりフラグを付けることができる。また、新しい受信者が容易にメッセージを「承認」して、本来意図された受信者に送ってもらうことを可能にする手段を提供することができる。これは、例えば「承認」ボタンを設けることによって達成することができる。このボタンが押された場合、好ましいシステムは、ユーザが通常の「転送」ボタンを押した場合と同じ方法で新しいメッセージを作成する。しかし、「承認」ボタンの場合は、転送されたことを注記するためにテキストをメッセージに追加するのではなく、本システムは、本来意図された受信者リストをメッセージから抽出し、再方向付けに関する詳細を剥ぎ取ってメッセージを元の状態にする。次に、宛先フィールド「Ｔｏ」、「Ｃｃ」、及び、「Ｂｃｃ」には、抽出された元の受信者アドレスが自動的に記入され、「Ｆｒｏｍ」フィールド（通常は表示されない場合でも全てのメッセージに対して存在する）には、元の送信者の名前／アドレスが記入される。また、日付／時刻フィールドは、元のメッセージの日付／時刻に調節することができる。次に、メッセージは、自動的に又はユーザが「Ｓｅｎｄ」ボタンを押した時に送られる。このように、ボタン１つ又は２つのみを押せば、再方向付けされたメールを承認して送ることができ、配信時には、再方向付けが何も行われなかったかのように、元の受信者から来たように見えることになる。
【０１７２】
メールを再方向付けするために実行されたプラグイン・モジュールの作動を制御するためのサンプル・ポリシーデータを図１９に示し、このようなプラグイン・モジュールの作動の概略図を図２０に示す。図１９は、図２０の判断段階に対応するいくつかのブランチを有するポリシー・データ・ツリーである。
プラグイン・モジュールは、図５の電子メールクライアント作動の図のポイントＢに対応する段階Ｓ３５０で開始される。開始されると、プラグイン・モジュールは６つの段階を通過し、発信電子メールメッセージの異なる詳細を判断する。まず、段階Ｓ３５１において、電子メールを送る者の身元が所定の名前又はアドレスリスト内のエントリに照らして検査される。このリスト上のユーザからの電子メールは、メッセージの内容にかかわらず、また、受信者にかかわらず、電子メールを直接意図された受信者に送信する権限を有するとみなされる。リスト上に記載されていない者は誰でも、その内容によって自分の電子メールが再方向付けされるか又はされない可能性がある。従って、判断段階Ｓ３５１において、ユーザ名又はアドレスがリスト上で見つかった場合、制御は段階Ｓ３６４に移り、電子メールを更なる対話なしに送信することが許可される。しかし、ユーザがリスト上で見つからなかった場合、制御は、更なる検査を行うために段階Ｓ２５３に移る。段階Ｓ３５２において、発信電子メールメッセージの受信者は、図１９に示すポリシーデータの受信者ブランチ上に指定されたルックアップ表ｓに照らして検査される。次の判断段階Ｓ３５４において、電子メールメッセージを含むテキスト及び電子メールメッセージに添付されたあらゆる添付物は、ルックアップ表ｔ内のエントリと比較される。表ｔは、ポリシーデータの「キーワード」ブランチ上で参照され、電子メールメッセージの性質が会社にとって機密であり得ることを示す語を含む。次の段階Ｓ３５６において、電子メールメッセージは、暗号化すべきであるか否かを確認するために検査される。暗号化は、電子メールが送信される瞬間まで発生せず、従って、この段階では電子メールに単に暗号化のフラグが付けられることになる点が留意される。次の判断段階Ｓ３５８において、電子メールメッセージが添付物を含むか否か、及び、次の判断段階Ｓ３６０において、電子メールメッセージが添付物に伴うテキストを含むか否か、すなわち、電子メールメッセージの本文テキストが未記入か否かが判断される。
【０１７３】
ルックアップ表が調べられる判断段階Ｓ３５２、Ｓ３５４、又は、Ｓ３６２のいずれかにおいて、ルックアップ表内のエントリと電子メール内のエントリとの照合により、電子メールが、会社外に送られる前に検査用に第三者に再方向付けされるべきであることが示される。例えば、段階Ｓ３５４において電子メールが「極秘」又は「秘密」という語を含むと判明した場合、それは、電子メールが意図された受信者に配信される前に第三者によって検査されることを正当化するのに十分であることになる。これによって、会社が知ることなく機密性情報が社外に送られないことが保証される。従って、制御は、これらの段階から段階Ｓ３６４に流れ、電子メールが再方向付けされたことを示すテキストがメッセージに追加され、受信者アドレスは、再方向付けされたメッセージの送信先である確認する当事者のアドレスに変更される。次に、制御は段階Ｓ３６６に移り、そこで電子メールは送信される。電子メールメッセージが再方向付けされるようにマークされていた場合、段階Ｓ３３６において、それは、勿論メッセージの元の受信者ではなく、確認する当事者に検討のために送信されることになる。
【０１７４】
判断段階Ｓ３５６において、メッセージの暗号化が検出された場合、それは、検討されるようにメッセージを第三者に再方向付けすることを正当化するのに十分であるとみなされる。従って、メッセージが暗号化される場合、制御は、段階Ｓ３５６から段階Ｓ３６４に移り、メッセージが再方向付けされるように修正される。暗号化されるようにフラグ付けされたメッセージの場合、メッセージが暗号化されることなく再方向付けされ、新しい受信者がメッセージを読むことができるように、暗号化フラグが除かれることが好ましい。また、メッセージに追加された再方向付けテキストは、メッセージを送信前に再暗号化することができるように、暗号化キー（一般的に意図された受信者の一般キーであり、従って、機密に属さない）を含むことが好ましい。
代替的に、意図された受信者の「デジタル証明書」全体を再方向付けされたメッセージと共に含めることができるであろう。その後、一般キー又は証明書は、場合によっては上述の自動化された承認処理によって除去されることになる。
【０１７５】
段階Ｓ３５８において、電子メールが添付ファイルを含んでいなかった場合、電子メールは、潜在的に機密に属する情報を有する文書又はファイルを含む可能性はないとみなされ、従って、段階Ｓ３６４において、一切の干渉なしに電子メールを送信することが許可される。電子メールが確かに添付物を含み、段階Ｓ３６０において、電子メールがメッセージの本文又は件名に入力されたテキストを含まないと判断された場合、メッセージは、その送信者の異なるアカウントに送られる可能性が高いものとして認識される。その電子メールは、次に段階Ｓ３６２及びＳ３６４において、検査されるように第三者に転送される。
【０１７６】
図２１は、会社のコンピュータシステムから外部サイトへの情報のアップロードを阻止するためのプラグイン・モジュールの作動を示す。単純な２段階の検査が用いられ、それは、段階Ｓ３７０での開始に続く段階Ｓ３７２における外部サイトアドレスの検査と、段階Ｓ３７４においてアップロードされている情報内の機密キーワードの検査とを含む。段階Ｓ３７２において外部サイトアドレスは禁止されたサイトではないと判明し、かつ、段階Ｓ３７４において機密キーが検出されないことを条件として、段階Ｓ３７６において、アップロードが進行することが許可される。そうでない場合は、段階Ｓ３７８において、アップロードは阻止される。
情報のアップロードを選択的に阻止するプラグイン・モジュールの作動を制御するためのポリシーデータは複雑なものではなく、図１９の下部に示されている。
このように、会社の利益にならない理由で送信されている機密性情報を含む発信伝送は、送信前に確認することができ、必要に応じて送信を防止することができる。
【０１７７】
電子メールの転送の管理
電子メールアプリケーションは、着信メールを１つ又はそれ以上のユーザに「転送」するための手段を提供する。ユーザは、通常「転送」ボタンをクリックし、それによって、あたかもユーザが自分でキー入力したかのように、着信メールのコピーが自動的にメール構成ウィンドウに入力される。その後に必要なことは、ユーザが転送されるメールの意図された受信者の名前を入力して「Ｓｅｎｄ」ボタンをクリックすることだけである。これは、ユーザが容易に受信メールの内容を他人と共有することを可能にする有用な特徴である。
【０１７８】
しかし、機密性の情報を含むメールの場合、特にメールの機密性の性質が直ちに明らかではない場合、例えばユーザがそれを読むために閲覧ウィンドウをスクロールダウンすることが必要とされるような機密性の情報がメールの下の方に表示されている場合には、問題が起きる可能性がある。ユーザは、特に処理する電子メールが多い時には、最初の数行のみ、場合によっては件名行のみをざっと見た後に電子メールを転送することが多い。その結果、機密性の情報が組織内で、更に危険なことには組織外でうっかり開示されることが多い。その結果、これまでにかなりの金額が失われた注意を引く事例がいくつかある。
従って、好ましいシステムは、電子メールの転送を制御する手段を提供する。このような制御には、転送電子メールが送信される前にユーザに警告を発し、電子メールが転送されるのを完全に防止することが含まれる。送信前に電子メールを承認するか、又は、上述したように別のユーザに再方向付けする手段を提供することもできるであろう。
【０１７９】
転送は、電子メールの内容及び電子メールが既に送られたその受信者のアドレスによって発生することが好ましい。例えば、電子メールの機密性の性質は、「極秘」などのキーワードがないか走査することを含むいくつかの方法により、又は、機密性の属性が「個人的」、「私用」、又は、「極秘」に設定されているか否かを確かめることにより判断することができる。また、「＜ＮＯＦＯＲＷＡＲＤ＞」（転送を防止する）又は「＜ＮＯＦＯＲＷＡＲＤＥＸＴＥＲＮＡＬ＞」（組織外への転送を防止する）のような予め定義されたキー・ストリングを挿入することによって、メッセージの元の構成者が今後の転送には不適とマークするための手段を提供することができる。このような手段はまた、メッセージに対する追加の属性の形で提供することができるであろう。
【０１８０】
好ましいシステムは、内容に基づく要素に加えて、メッセージの以前の受信者のリストに問い合わせる。電子メールが既に元の構成者によって組織外に送られていた場合、例えば、それを更に外部に転送させることは安全であると考えてもよい。同様に、元の電子メールが単一の受信者のみに送られた場合、元の構成者は広く回覧させることを意図してはいなかったと判断してもよく、適切な警告を出すことができるであろう。上述の要素に応じたアクション方針をポリシーに従って判断することができる。
【０１８１】
まさに送信されようとしている電子メールが転送電子メールであるという事実は、電子メールプログラムによって元のメールの始めに自動的に追加される「−−−−Ｏｒｉｇｉｎａｌ Ｍｅｓｓａｇｅ−−−−」などのキーストリングがないかどうか電子メールを走査することによってたやすく判断することができる。同様に、元のメッセージのストリングに続くキーストリング「Ｔｏ：」及び「Ｃｃ：」がないかを走査することによって以前の受信者のリストを判断することができる。受信者のリストは、これらのキーストリングの直後に見つけられる。内部及び外部の受信者は、ドメイン名（それがある場合）の参照によって区別することができる。例えば、「Ｆｅａｄ Ｓｍｉｔｈ」として示された受信者名は、一般的に内部のものであり、「ｆｓｍｉｔｈ＠ｘｙｚ．ｃｏｍ」は一般的に外部のものである。
【０１８２】
電子メールメッセージの転送を制御するために実行されるプラグイン・モジュールの作動を命令するためのポリシーデータを図２２に示し、このようなモジュールの作動を図２３に示す。
ポリシー・データ・ツリーは、コマンド値を設定することができるパラメータを指定するいくつかのサブブランチを含む。例えば、「ＹＥＳ」に設定された時の第１のサブブランチ「ＰｒｅｖｅｎｔＡｌｌ」は、全ての電子メールが転送されるのを防止されるようにモジュールに命令する。「ＹＥＳ」に設定された時の次のサブブランチ「ＷａｒｎＡｌｌ」は、電子メールがまさに転送されようとしている時は常にモジュールに対して電子メールクライアントユーザに警告するように要求する。次の２つのサブブランチ「ＰｒｅｖｅｎｔＥｘｔｅｒｎａｌ」及び「ＷａｒｎＥｘｔｅｒｎａｌ」は、外部電子メールのみに対応するパラメータを含み、これらの２つのサブブランチによって、電子メールクライアントのユーザは、会社内の電子メール転送に影響を与える規則と会社外の人たちへの電子メール転送に影響を与える規則とを区別することができる。「ＰｒｅｖｅｎｔＫｅｙｗｏｒｄｓ」ブランチは、機密性の情報を示すキーワードが記憶されるルックアップ表を指定する。このようなキーワードは、「＜ＮＯＦＯＲＷＡＲＤ＞」又は「＜ＮＯＦＯＲＷＡＲＤＥＸＴＥＲＮＡＬ＞」などの予め定義されたキーストリング又は１つ又はそれ以上の予め定義された語とすることができる。
【０１８３】
電子メールは送信前に走査され、このようなキーワードが電子メールのテキスト又は電子メールのいずれかの添付物で見つかった場合、電子メールを転送することが許可されない。「ＹＥＳ」に設定された時の最後の２つのサブブランチ「ＰｒｅｖｅｎｔＩｆＮｏｔＳｅｎｔＥｘｔｅｒｎａｌｌｙ」は、以前に会社外に送信されたことがない場合には転送電子メールの会社外への送信を禁止する。実際には、転送電子メールは、会社内の受信者全員に送信することができ、外部の受信者は、単に受信者リストから削除されるか、又は代替的に、送信前に、アドレスリストに外部の受信者が含まれないように、ユーザに対してアドレスリストの修正を要求してもよい。
最後に、「ＹＥＳ」に設定された時の「ＰｒｅｖｅｎｔＩｆＳｉｎｇｌｅＲｅｃｉｐｉｅｎｔ」ブランチ上で設定されたパラメータは、メッセージの元の受信者が単一の個人であった場合には、あらゆる電子メールメッセージの転送を防止する。
【０１８４】
プラグイン・モジュールの作動を図２３に示す。プラグイン・モジュールは、段階Ｓ３８０において、ここでもまた図５のポイントＢで開始される。キーストリング「−−−−Ｏｒｉｇｉｎａｌ Ｍｅｓｓａｇｅ−−−−」は、転送用メッセージを生成した時に電子メールプログラムによって元のメールの始めに自動的に追加されるので、判断段階Ｓ３８２において、電子メールには、このキーストリングを含むか否かを確認するために予備走査が行われる。電子メールメッセージがこのキーストリングを含んでいなかった場合、電子メールメッセージは元のメッセージであり、転送されていないと推論することができ、段階Ｓ３８４においてメッセージを送信することができる。しかし、段階Ｓ３８２において、メッセージがキーストリング「−−−−Ｏｒｉｇｉｎａｌ Ｍｅｓｓａｇｅ−−−−」を含むと判明した場合、電子メールメッセージは、明らかに転送メッセージであり、モジュールは、更なる措置を講じて転送メッセージを送信することを可能にすべきか否かを判断する。次に、制御は段階Ｓ３８６に移り、その転送メッセージの受信者は、いずれかがオンライン会社外の者か否かに関して確認するために検査される。外部の受信者がいた場合、段階Ｓ３８８において、プラグイン・モジュールは、電子メールメッセージを走査してその電子メールが以前に会社外の受信者に転送されたことがあるか否か確認する。転送されたことがなかった場合、段階Ｓ３９０において、電子メールメッセージは転送が防止され、電子メールクライアントのユーザに通知される。しかし、電子メールメッセージが会社外に送られたことがあった場合、段階Ｓ３９２において警告がユーザに発せられ、その後、その電子メールメッセージはユーザにより送信されるか、又は、意図された受信者を改訂するためにユーザに返送することができる。
【０１８５】
段階Ｓ３８６において、転送メッセージが会社外のアドレスに送られるべきではない場合、制御は段階Ｓ３９４に移り、ユーザが元のメッセージの唯一の受信者であったか否かが判断される。そうであった場合、メッセージの元の構成者が多くの読み手に送信されることを意図していなかった事例と考えてもよい。従って、制御は段階Ｓ３９０に流れ、転送電子メールメッセージの送信は阻止される。これは、このような措置を取ることを指定する図２２に示すポリシーデータに従ったものである。代替的に、メッセージを転送しようとするユーザに警告を出すことができる。
【０１８６】
最終に行われる検査は、判断段階Ｓ３９６におけるものであり、そこでは、メッセージ及びメッセージに添付された内容がキーワード表のエントリと比較される。電子メール内のエントリと表内のエントリとの間の一致が見つかった場合、メッセージは、機密性情報を含むと考えられて転送されない。その後、モジュールは段階Ｓ３９０で終了する。機密性キーワードが見つからなかった場合、段階Ｓ３８４において、電子メールを転送することが許可される。
【０１８７】
発信伝送の署名の管理
「デジタル証明書」を使用してメッセージに署名する能力は、明らかに、送信者の身元を確立する際にはメッセージの受信者にとって、また、メッセージが改竄されていないことを保証する際には両当事者にとって貴重なものである。しかし、メッセージの送信者は、デジタル署名されたメッセージは、それが送られると拒否又は取り消すことができない潜在的に拘束力を有する契約になることを認識すべきである。従って、手書きの署名を紙製文書に付す時に注意するのとちょうど同じように、文書にデジタル署名する時にも注意することは絶対に必要にことである。マイクロソフト・コーポレーション製の「アウトルック」のような電子メールアプリケーションは、メッセージに自動的にデジタル署名する手段を提供し、これは、送信者の身元を確認する際には、受信者にとって上述した理由から貴重なものと考えられるが、また、潜在的に危険なものであり、ユーザは、メッセージ内容には極度の注意を払うことが要求される。
【０１８８】
好ましいシステムは、ポリシーデータに従って発信メッセージの署名を制御する手段を提供する。サンプル・ポリシーデータは図２４に示されており、このような制御には、以下のものが含まれる。
メッセージの署名を強制する、
メッセージの署名をユーザに示唆する、
メッセージに署名すべきでないことをユーザに示唆する、及び
メッセージの署名を防止する。
【０１８９】
どのアクション方針を取るかを決める際に、好ましいシステムは、メッセージ内容（あらゆる添付物を含む）の性質、意図された受信者の身元及び／又は所属組織、送信者の身元、使用されている「デジタル証明書」（署名するようにメッセージが既にフラグ付けされている場合）の性質、及び、メッセージに署名するのに利用可能な１つ又は複数の「デジタル証明書」の性質を含むいくつかの要素を考慮に入れる。
メッセージの性質は、１つ又はそれ以上のキーワード又はその組合せがないかメッセージを走査することによって、又は、標準的な「自然言語クエリー」技術を使用することによって判断することができる。同様に、意図された又は利用可能な「デジタル証明書」の性質は、証明書の発行人及び種類の参照によって判断することができる。
【０１９０】
図２５は、電子メールが適切にデジタル署名されるか又はデジタル署名されないように保証するためのプラグイン・モジュールの作動を示す。モジュールは、段階Ｓ４００において、図５に示す電子メールクライアントの作動におけるポイントＢで開始される。次に、制御は判断段階Ｓ４０２に移り、発信電子メールが、署名されるように既にマークされているか否かを確認するために走査される。メッセージの実際の「署名」は、送信直前まで発生しないことになる。署名されるようにマークされていなかった場合、制御は段階Ｓ４０４に移り、モジュールは、受信者ルックアップ表（表ｆ）を調べ、発信電子メールの受信者が電子メールが常にデジタル署名されるべき者と識別されているか否かを判断する。受信者が表ｆにあった場合、制御は段階Ｓ４０６に移り、電子メールクライアントのユーザは、電子メールがデジタル署名されない場合は送れないという通知を受ける。代替的に、プラグイン・モジュールは、電子メール作成者の「デジタル証明書」を使用して電子メールに自動的にデジタル署名することができる。
【０１９１】
段階Ｓ４０４において、発信電子メールの受信者がルックアップ表で見つからなかった場合、制御は段階Ｓ４０８に移り、次に、ポリシーデータの「ＥｎｆｏｒｃｅＳｉｇｎｉｎｇ」ブランチの「ＫｅｙｗｏｒｄｓＴａｂｌｅ」が調べられる。仮に表ｇのキーワードのいずれかが電子メールのテキスト、又は、電子メールの添付物のいずれかで見つかった場合、電子メールのデジタル署名が必要であることになり、制御は、前と同じように段階Ｓ４０６に移る。判断段階Ｓ４０４及びＳ４０６は、ポリシーデータの「ＥｎｆｏｒｃｅＳｉｇｎｉｎｇ」ブランチ上のルックアップ「受信者」及び「キーワード」表を調べるためのルックアップ・コマンドに対応することが認められるであろう。
このようなキーワードは、図２４に示すような「極秘」、「秘密」、「契約」、「見積り」、及び、「注文」などの所定の語とすることができる。
【０１９２】
電子メールの受信者が表ｆで見つからず、また電子メールが表ｇに指定されたキーワードを含まなかった場合、制御は、サンプル・ポリシーデータの「ＳｕｇｇｅｓｔＳｉｇｎｉｎｇ」ブランチ上のルックアップ・コマンドに対応する判断段階Ｓ４１０に移る。判断段階Ｓ４１０において、受信者のアドレスは、電子メールの署名が勧告されているか否かを判断するために、ルックアップ表ｈ内のものと比較される。受信者の名前が表ｈで見つかった場合、制御は段階Ｓ４１２に移り、電子メールクライアントのユーザは、発信電子メールメッセージにデジタル署名することが望ましいことを通知される。しかし、電子メールクライアントのユーザは、電子メールメッセージにデジタル署名することを要求されず、電子メールは、従って、ユーザが署名なしで電子メールを送信することを選択した場合にはそのように送信されてもよい。判断段階Ｓ４１０の後、受信者の名前が表ｈで見つからなかった場合、制御は判断段階Ｓ４１４に移り、前と同じように電子メールテキストは、機密性のデータを含んでデジタル署名が必要であることを示すようないくつかのキーワードがないか検索される。電子メールがこのような機密性キーワードを含むか否かにより、電子メールクライアントのユーザは、段階Ｓ４１２において、メッセージにデジタル署名をすることが望ましいことを通知されるか、又は、代替的に、電子メールメッセージは、段階Ｓ４１６において署名なしで送信される。
【０１９３】
プラグイン・モジュールの開始に続く段階Ｓ４０２において、電子メールが署名に関してマークされていることが判明した場合、制御は判断段階Ｓ４１８に移る。判断段階Ｓ４１８において、プラグイン・モジュールは、ポリシーデータの「ＤｅｎｙＳｉｇｎｉｎｇ」ブランチの下で指定された「ＤｅｎｙＳｉｇｎｉｎｇ」ブランチ内のルックアップ表ｍを調べる。表ｍは、「ＤｅｎｙＳｉｇｎｉｎｇ」ブランチの下の「ＣｅｒｔｉｆｉｃａｔｅｓＵｓｅｄ」ブランチ上で指定されており、発行人、形式、証明書番号、又は、該当するとみなされる「デジタル証明書」の署名キーを指定する。仮に発信電子メールに署名するために使用されるべきデジタル署名又は署名キーが表ｍで見つかった場合、メッセージに署名すること又は署名しないことが適切なのかを判断するために、「受信者」及び発信電子メールの性質に関する更なる検査が行われることになる。制御は段階Ｓ４２０に移り、発信電子メールの受信者が受信者表と比較され、次に判断段階Ｓ４２２に移り、電子メールのテキスト及びあらゆる添付物が様々なキーワードがないかに関して走査される。判断段階Ｓ４２０又はＳ４２２にいずれかにおいて、受信者又はメッセージのいずれかのテキストがルックアップ表で定義されたものと一致した場合、制御は段階Ｓ４２４に移り、電子メールの送信が阻止される。次に、電子メールクライアントのユーザは、電子メールテキスト入力段階に戻され、メッセージをデジタル署名することなく再送信するように要求されてもよい。
【０１９４】
段階Ｓ４１８又はＳ４２２のいずれかにおいて、証明書又は署名キーが当該のものではないと判明し、かつ、電子メールのテキストがいかなる機密性の語も含んでいなかった場合、制御は、ポリシー・データ・ツリーの「ＳｕｇｇｅｓｔＮｏｔＳｉｇｎｉｎｇ」ブランチ上の第１のサブブランチに対応する段階Ｓ４２６に移る。ポリシー・データ・ツリーの「ＤｅｎｙＳｉｇｎｉｎｇ」ブランチに関して、３つの判断段階Ｓ４２６、Ｓ４２８、及び、Ｓ４３０は、それぞれ、ルックアップ表ｊ、ｋ、及び、ｌの所定の機密性エントリに照らして、電子メールと共に使用された「デジタル証明書」又は署名キー、発信電子メールの受信者、及び、発信電子メールのテキストを検査するためのルックアップ・コマンドに対応する。段階Ｓ４２６において、発信電子メールに署名するのに使用された証明書が当該のものであると判明し、かつ、段階Ｓ４２８又は段階Ｓ４３０のいずれかにおいて、受信者又は発信電子メールのテキストが指定されたルックアップ表内のエントリに一致すると判明した場合、制御は段階Ｓ４３２に流れ、電子メールクライアントのユーザは、発信電子メールメッセージにデジタル署名しないことが望ましいことを通知される。しかし、そのユーザは、それでも尚署名された電子メールメッセージを送りたい場合には自由にそうすることができる。
判断段階Ｓ４２６、Ｓ４２８、及び、Ｓ４３０のいずれにおいても一致が見つからなかった場合、電子メールは、段階Ｓ４１６で通常通り送られる。
【０１９５】
インスタントメッセージング及び電話技術アプリケーション
「インスタントメッセージング」（「チャット」としても知られている）及びデジタル電話技術関連用途（「ボイス・オーバー・ＩＰ」など）のような更なる応用は、ブラウザ及び電子メールの活気に加えて、現在のビジネス状況において人気を得てきている。「インスタントメッセージング」規格は、「ＲＦＣ」の２７７８及び２７７９において、また、「ＩＥＴＦ ＳＩＭＰＬＥ」作業グループによって定義されている。「ボイス・オーバー・ＩＰ」規格は、「ＩＴＵ−Ｔ勧告Ｈ．３２３」（１９９８年）に定義されている。本発明の多くの態様は、このようなアプリケーションで送受信されたデータに適用することができる。「インスタントメッセージング」は、概念的には、「会話」が両当事者が一貫して存在する「ライブ」で行われる点を除き、一連の送受信電子メールと類似のものである。しかし、本発明の目的に対しては、その手順は全く同じものである。図５は、段階Ｓ１２２、Ｓ１２４、Ｓ１３２、及び、Ｓ１３４内の語電子メールを「Ｍｅｓｓａｇｅ」という語と入れ換えることによって「インスタントメッセージング」を表すことができる。「Ｅ−ｍａｉｌ Ｓｅｒｖｅｒ」の説明９５は、「Ｍｅｓｓａｇｅ Ｒｅｌａｙ」と入れ換えられる。好ましい実施形態は、「インターネット・メッセージング」アプリケーションとのプラグインを準備することにより、又は、プラグインの機能性を含む「インスタントメッセージング」アプリケーションを開発することにより、前と同じようにポイントＡ及びＢで割り込むように構成される。代替的に、この割り込みは、プロトコルレベルで発生することができ、ネットワークパケットがユーザマシンから出る前か、又は、ネットワークパケットがユーザマシンに到達した時か、又は、ネットワーク上のある中間点においてネットワークパケットに割り込むことが認められるであろう。
【０１９６】
「ボイス・オーバー・インターネット・プロトコル」（ＶＯＩＰ）は、概念的には、メッセージ内容が符号化されて直ちに送信されるデジタル化された発話から成る点を除き、「インスタントメッセージング」と類似のものである。メッセージ内容の解析は非現実的であるが、メッセージを記録して「呼出し」レベルで制御を行う手段は実行可能であり、音声メッセージング・アプリケーションへのプラグインとして、又は、ユーザマシン内又はネットワーク上のある中間点のいずれかにおけるネットワーク・プロトコル・レベルにおいて、類似の方法で実施される。
【０１９７】
好ましいシステムの実施について既存のアプリケーションに対するプラグイン・モジュールに関連して説明されたが、本発明は、本明細書で説明したプラグイン・モジュールの機能性が既に最初からコード化されているウェブブラウザ、電子メールクライアント、「インスタントメッセージング」アプリケーション、又は、「ボイス・オーバー・ＩＰ」アプリケーションを準備することにより実施されてもよい。
Notice: Undefined index: CLJ in /mnt/www/gzt_disp.php on line 301
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開２００９−１６９９６０（Ｐ２００９−１６９９６０Ａ）
【公開日】平成２１年７月３０日（２００９．７．３０）
【国際特許分類】
【出願番号】特願２００９−３５８３５（Ｐ２００９−３５８３５）
【出願日】平成２１年２月１８日（２００９．２．１８）
【分割の表示】特願２００２−５４１５８３（Ｐ２００２−５４１５８３）の分割
【原出願日】平成１３年１１月８日（２００１．１１．８）
【出願人】（５０３１６８６１４）オーケストリア リミテッド (4)
【Ｆターム（参考）】
【公開日】平成２１年７月３０日（２００９．７．３０）
【国際特許分類】
【出願日】平成２１年２月１８日（２００９．２．１８）
【分割の表示】特願２００２−５４１５８３（Ｐ２００２−５４１５８３）の分割
【原出願日】平成１３年１１月８日（２００１．１１．８）
【出願人】（５０３１６８６１４）オーケストリア リミテッド (4)
【Ｆターム（参考）】
[ Back to top ]