JP2010536107A - データ発信源の追跡及びデータ伝送の制御 - Google Patents

Abstract

【課題】 データ発信源の追跡及びデータ伝送の制御の方法、装置及びコンピュータ・プログラムを提供する。
【解決手段】 一実施形態において、スクリプト動作による機密データの伝送は、その機密データの発信元以外のあらゆるネットワーク位置への伝送を妨げるように、ＨＴＴＰクライアントのスクリプト・エンジン内の、データ内に配置された発信源タグに応答する、新規な機能によって制限される。データ入力に結合される発信源タグは、あらゆる出力データ項目に伝播され、それにより、派生情報の伝送もまた制御することができる。
【選択図】 図３

Description

本発明は、ウェブ・ブラウザなどのスクリプト化可能なクライアントのための、データ発信源を追跡し、機密データの伝送を制御する方法、データ処理装置、及びコンピュータ・プログラムを提供する。

ウェブ・ブラウザは、ユーザのデータ処理装置上で実行されてワールド・ワイド・ウェブ上の情報へのアクセスを提供するコンピュータ・プログラムであり、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いて、ウェブ・サーバ・コンピュータにウェブ・ページを検索する要求をサブミットして、ウェブ・ページ・コンテンツをブラウズするか又はそれと相互作用する。幾つかのウェブ・ブラウザ及び類似のＨＴＴＰクライアントは、スクリプト言語を解釈することができる。典型的には、ＪａｖａＳｃｒｉｐｔ（登録商標）が用いられるが、ウェブ・ブラウザによってはＶＢＳｒｉｐｔ（ビジュアル・ベーシック・スクリプト・エディション）が理解され、そのメカニズムは他の言語にも拡張可能である。ページのテキストにスクリプト言語命令を組み込むことにより、著者は、ページが適切な能力を有するブラウザによって見られるときに、任意の複雑な動作を示すようにするか、又はその代わりに、静的文書のように見えるようにすることができる。このような命令は、直接に、又は、その命令が含まれる独立したファイルに対する参照によって組み込むことができる。

ウェブ・ページに埋め込まれたスクリプト命令は、ブラウザ内のサブシステム又は「スクリプト・エンジン」によって解釈される。このエンジン自体は、プログラミング言語、典型的にはＣ＋＋又はＪａｖａ（登録商標）などのより構造化された言語で書かれる。エンジンには多数の動作を実行する能力があり、各々のスクリプト言語命令は、文字通り、そのエンジンに対してエンジンの利用可能な動作のうちの特定の１つを実行させるための命令である。

スクリプト・エンジンは、さらに、ブラウザ内でウェブ・ページ自体を表すデータ構造体へのアクセスを有する。エンジンによって実行可能な動作のうちのあるものは、これらのデータ構造体からの読み出し及びそれへの書き込みを含み、ブラウザで見られるページを効果的に編集する。スクリプト動作に用いることができる他のデータ・ソースは、初期値を設定するか又はいずれかの他のソースから記入することができるスクリプト変数と、「ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ」として知られる技術を用いて独立にダウンロードされた他のデータとを含む。

スクリプト・エンジン内に限定して情報を操作すること、及び、ウェブ・ページの内部表示と情報を交換することと並んで、ブラウザにネットワーク接続を通じて他のシステムと相互作用させるか、又は、通常は人間のユーザによって命令される他の動作を実行させるようなスクリプト命令のクラスが存在する。このセットにおいて利用可能な命令の選択は、通常、悪意のあるスクリプトが与え得る影響を減らすために制限される。

スクリプトはウェブ・ページの一部として届くため、また、スクリプト自体が後でページに挿入され得る情報を含んでいる可能性があるため、スクリプト自体はデータの一形態であるので、本発明における「データ要素」に関する全ての考察はスクリプトを構成する命令のリストにも等しく当てはまることに留意することが重要である。

上記の機能をどのように用いることができるかの一例として、ＡＪＡＸ（非同期ＪａｖａＳｃｒｉｐｔ及びＸＭＬ）技術を用いてウェブ・ページの形で配信されるウェブ・ベースの文書編集アプリケーションを考える。グラフィカル・ウェブ・ブラウザは、初めに、様々な表示要素（ルーラー、ボタン、テキスト編集領域など）を収容すると共にスクリプト命令のファイルを参照するページをダウンロードする。これらの命令は、スクリプト・エンジンに、ユーザの動作に対してどのように応答するかを指示する。例えば、ユーザが「太字」ボタンを作動させたとすると、スクリプト・エンジンは、最初にそのページを読んでテキスト領域中のどの単語をユーザが選択したのかを判断するように命令される可能性がある。この情報は、そのテキストを太字としてマーク付けするようにページのデータ構造を変更する別の命令によって用いられることになる。最後に、「レンダリング・エンジン」として知られるブラウザの別の部分がこれらのマークを読み込み、結果として、マーク付けされた単語がページ上で太字で表示されるようにする。

ＪａｖａＳｃｒｉｐｔをサポートするウェブ・ブラウザのようなスクリプト化可能なＨＴＴＰクライアントは、従来、一度に１つのソース位置からのみデータをロードしていた。しかしながら、ウェブ・サービス環境では、幾つかのソース位置からのスクリプト及びデータを１つのスクリプト環境において組み合わせることができるのが望ましい。ウェブ・ベースの文書編集アプリケーションの例に戻ると、現在のところ、ユーザは、例えば、プロバイダのサーバに文書をアップロードすることにより、彼らの文書をアプリケーションのプロバイダに公開して預託する必要がある。

現在のところ、ワールド・ワイド・ウェブを介して、ウェブ・ブラウザ内で動作するスクリプトを用いてウェブ・サーバと通信するウェブ・サービスの形態で、多数のアプリケーション・プログラムが利用可能であるが、多くの組織及び個人は、それらの機密文書の本質的な公開を受け入れることを望まない。このことが利用可能なアプリケーションの使用を制限する。

クライアント内のスクリプト言語で書かれたこの種のアプリケーションを、１つ又は複数の異なる位置から取得したデータに対して実行することは可能であろう。しかしながら、ひとたびスクリプト及びデータがスクリプト環境にロードされると、スクリプトがそのデータをそれら自体のサーバに、悪意により又はスペルチェックなどの機能を提供する過程で、返送しないことを保証する適切なメカニズムは現在のところ存在しない。既知の解決策は、許可されないスクリプトが特定のファイル及びオブジェクトにアクセスすることを防止することを含むが、これは過度な制約になり得る。

例えば、特許文献１は、スクリプトの発信源と定義された許可とに基づいてスクリプトがオブジェクトにアクセスする能力を制御することについて記述している。クライアントのアクセス制御データ構造体内の項目は、ソース識別子フィールドと、オブジェクトに関連付けられた許可識別子フィールドとを含み、スクリプトの発信源が記録され次いで照合され、許可されないスクリプトは特定のオブジェクトにアクセスすることを妨げられる。

特許文献２は、信頼されないスクリプトのようなコンテンツの実行コンテキストを制限することについて記述している。プロセスがリソースにアクセスしようとするとき、そのプロセスに付随するトークンがそのリソースに関するセキュリティ情報と比較されて、アクセスが許可されるかどうかが判定される。スクリプトのソースは、それがどの程度信頼できるか、そしてどのプロセスを特定のリソースに対して実行することができるかを判定することができる。

特許文献３は、外部位置からファイルを取得すること、及び取得したファイルの発信源に関するタグ付け情報を追加することを開示する。取得したファイルの発信源は、コンテンツの実行又はレンダリングを許可するか又は妨げるかといった、その後のセキュリティ・ポリシー判断に用いることができる。

米国特許第６，９８６，０６２号明細書 米国特許第６，５０５，３００号明細書 米国特許出願公開第２００６／０２３０４５２号明細書

ウェブ・ブラウザのようなスクリプト化可能なクライアントのための、データの発信源を追跡し、機密データの伝送を制御する方法、データ処理装置、及びコンピュータ・プログラムを提供する。

本発明の第１の態様は、機密データの伝送を制御する方法であって、スクリプト環境内で実行される、発信源表示を第１のデータ要素に結合させるステップと、発信源表示を第１のデータ要素から生成されたデータ要素に伝播させるステップと、第１のデータ要素及び生成されたデータ要素の伝送を、発信源表示を参照して識別される許可された宛先だけまでに限定するステップとを含む方法を提供する。

第１のデータ要素は、発信源表示が結合されたデータ要素のセット、潜在的には非常に大きなデータセットの一部分を含むことができる。生成されたデータ要素もまた、生成されたデータ要素のセットのうちの１つとすることができる。

本発明の一実施形態において、第１のデータ要素と、第１のデータ要素から生成された任意のデータ要素とは、第１のデータ要素の発信源以外の如何なる発信源にも伝送を妨げられる。これにより、スクリプト動作が、ネットワークの全域で機密データをデータの出所以外のいずれのネットワーク・ノードにも伝送することを防止することができ、一方データ伝送を制限する規則の制約内でスクリプトが協働することを可能になる。

一実施形態において、スクリプト環境内で、各々が結合した発信源表示を有する複数のデータ要素から新規のデータ要素が生成された場合には、新規のデータ要素は、その複数のデータ要素に由来する結合した発信源表示を有することになる。複数の機密入力データ要素が異なる発信源を有する場合には、伝送を制限するステップは、如何なる宛先に対しても出力データの伝送を妨げることができ、一方これに対して共通の発信源を有する複数の入力データ要素から派生した出力は、その共通の発信源には返送することができるが、いずれかの他の宛先に伝送することは妨げられる。

伝送を制限するステップは、「信頼されない」スクリプトが動作するスクリプト環境内において有益である。この文脈における「信頼されない」スクリプトとは、スクリプト又はその提供者のセキュリティ制御又は信頼性が検証されていない任意のスクリプトである（従って、「信頼されない」という用語は、そのスクリプト又はその提供者が何らかの悪意を有すると認識されることを意味しない）。

本発明は、機密データがスクリプトによって操作されるときに、スクリプトがそのデータを、情報を未だ有しない任意のサーバに送信しないことを保証することで、スクリプト又はその提供者の信頼性を検証することを必要とせずに、機密データを保護する。発信源表示を結合させるステップ及び伝播させるステップは、ウェブ・ブラウザ内のスクリプト・エンジンによって実行することができ、このエンジンはデータ内のセキュリティ・タグに応じて、いずれかのスクリプトがタグ付きデータを、そのデータの出所位置以外の位置に送信することを妨げる。タグはデータの発信源位置を表示する。一実施形態による「スクリプト・エンジン」は、スクリプト・インタープリタ、タグ・ジェネレータ、及びタグ・プロパゲータを備える。

本発明の第２の態様は、少なくとも１つのデータ処理装置と、少なくとも１つのデータ記憶装置と、スクリプト・インタープリタと、発信源表示を第１のデータ要素に結合させるための手段と、発信源表示を第１のデータ要素から生成された新規のデータ要素に伝播させるための手段と、第１のデータ要素及び生成されたデータ要素の伝送を、データ処理システムから、発信源表示を参照して識別される許可された宛先だけまでに限定する手段と、を備えるデータ処理システムを提供する。

この第２の態様の一実施形態において、スクリプト・インタープリタ、結合させるための手段、伝播させるための手段、及び、伝送を限定するための手段は全て、ウェブ・ブラウザのようなスクリプト化可能なＨＴＴＰクライアント・コンピュータ・プログラム内に実装される。一実施形態において、結合させるための手段及び伝播させるための手段は、ＨＴＴＰクライアント・プログラム内の改善されたスクリプト・エンジンの特徴として提供され、記録媒体上のコンピュータ可読プログラム・コードを備えたプログラムとして入手可能にすることができる。

本発明の実施形態は、例として、添付の図面を参照し、以下でより詳細に説明する。

本発明を実施することができるネットワークの概要図である。 本発明を実施することができる例示的なクライアント・データ処理システムを示す。 本発明の一実施形態によるスクリプト・エンジンのコンポーネントを示す。 発信源タグを生成してストアし、その後で新規のデータ要素に伝播させ、次いでこれを用いて、機密データがデータの発信源以外の宛先に伝送されることを防止する、本発明の一実施形態によるクライアントとサーバの間の対話の一連の動作を示す。 本発明の一実施形態による、注釈を伝播させるための一連の動作を示す。

１．ネットワーク環境と例示的なクライアント・システム
図１に概略的に示す分散型データ処理ネットワークは、ＨＴＴＰを介して互いに通信する、任意の数のクライアント・データ処理システム１０、２０、３０及びサーバ・データ処理システム４０、５０、６０を含む。本発明は、システム・ハードウェア又はオペレーティング・システムのいずれによっても、特定の型のデータ処理システムに限定されないが、図２に概略的に示す典型的なクライアント・システム１０は、少なくとも１つのデータ処理装置１００と、揮発性システム・メモリ１１０及びディスク記憶装置のような不揮発性記憶コンポーネント１２０を典型的に含む少なくとも１つのデータ記憶装置と、内部通信バス１３０と、マウス１６０、キーボード１７０、及びモニタ１８０のためのデバイス・ドライバ１４０及び接続インターフェース１５０を含む入力／出力コンポーネントと、ネットワーク・インターフェース１９０とを含むラップトップ型又はデスクトップ型のデータ処理システムとすることができる。本発明の実施に用いられる典型的なクライアント・システムには、オペレーティング・システム・ソフトウェア２００、ウェブ・ブラウザ２１０、及び多数のアプリケーション・プログラム２２０、２３０を含む多数のプログラム・コード・コンポーネントがインストールされる。ウェブ・ブラウザ２１０は、遠隔ウェブ・サーバと要求−応答型ＨＴＴＰモデルを用いるネットワーク通信により対話するように適合される。ウェブ・サーバ４０、５０、６０は、それぞれ、１つ又は複数のＨＴＴＰサーバ７０と、単一のサーバ・データ処理システム上で、又は、高い可用性と処理量を与えるように協働するサーバ・クラスタ上で実行される１つ又は複数のアプリケーション・サーバ８０、９０とを含むことができるが、本発明は如何なる特定のウェブ・サーバ・アーキテクチャをも必要としない。

本発明と共に用いるためのクライアント・システムにおいて、ウェブ・ブラウザ２１０は、ダウンロードされたウェブ・ページ内でのスクリプトの実行を可能にするスクリプト・エンジン２４０の主要なコンポーネントを備えるスクリプト・インタープリタを含む。本発明の種々のコンポーネント及び特徴は、新規のスクリプト・エンジンのプログラム・コード・コンポーネントとして幾つかのコンポーネントが実装される本発明の一実施形態との関連において、図３乃至図６を参照して以下に説明する。図３に示すように、スクリプト・エンジン２４０は、スクリプト・インタープリタ２５０、発信源タグ・ジェネレータ２６０、及びタグ・プロパゲータ２７０を備える。当業者であれば、以下に説明する伝送を防止する手段のような本発明の種々のコンポーネントは、特定用途向け集積回路（ＡＳＩＣ）のようなハードウェア・コンポーネントとして同様に実施することができることを理解するであろう。

以下に説明するように、生成され伝播されたタグは、ウェブ・ブラウザ又は他のＨＴＴＰクライアントによって、機密データ要素の伝送を制御するのに用いられる。

２．発信源を表示するタグの生成及び保管
前述のように、スクリプト・エンジンの動作に用いることができる多種類のデータ要素が存在する。これらの要素の全ては、スクリプト・エンジン２４０自体又はウェブ・ブラウザ２１０（又は、他の実施形態においては、スクリプト・エンジンがその一部分である別のプログラム）に関連付けられたデータ構造体にストアされる。スクリプト動作は、それらの内部作業の一部分として、これらのデータ構造体内のデータを読み出し、修正することになるが、スクリプトが独自の目的でデータ構造体自体を調査又は改変できるようなスクリプト動作は存在しない。

既存のスクリプト・エンジンにおいて、これらのデータ構造体は、典型的には、データ要素の現行の値、及びスクリプト・エンジンが用いるためのある付加的情報の両方を含む。このような情報の一例は、自動ガーベジ・コレクションに関する情報である。本発明は、データ要素に発信源表示を結合させることを含み、本発明の実装に関与するデータ要素に対する「注釈」は、スクリプト・エンジンが用いるために与えられる他の情報と同様にスクリプト・エンジンのデータ構造体内にストアすることができる。このことは、本発明を実装するのに、現行のウェブ・ブラウザ及び他のスクリプト化可能なＨＴＴＰクライアント・プログラムに対する小さな変更のみが必要であることを意味し、スクリプトがそれら独自の注釈によって介入するのに利用できるメカニズムが存在しないことを保証する。

図４は、一組のデータ要素に対する発信源表示タグ又は「注釈」の最初の生成に関与する一連のステップを示す。機密と見なされる全てのデータには、初めにスクリプト動作に用いられるより前に発信源タグを付与しなければならない。データを現代のウェブ・ブラウザに持ち込むための多数の方法が存在するが、それらの大部分はＨＴＴＰプロトコル（Ｗ３Ｃ Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ’ｓ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２６１６「Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ−ＨＴＴＰ／１．１」、１９９９年６月における仕様）を含む。このような方法に対して、本発明を実施するように適合されたウェブ・ブラウザ又は他のＨＴＴＰクライアントは、専用のＨＴＴＰヘッダを要求の中に用い、別の専用のＨＴＴＰヘッダを応答の中に用いることができる。ＨＴＴＰ仕様は、特別のヘッダを用いることを可能にし、関連する機能を実装しないシステムはこれに関するヘッダを無視することになることを留意されたい。

それゆえに、図４に示すように、本発明の一実施形態によるクライアント−サーバの対話シーケンスは、ウェブ・ブラウザのようなスクリプト化可能なクライアントがウェブ・サーバにＨＴＴＰ要求を送信すること（３００）で開始する。全てのＨＴＴＰクライアントが本発明を実装することにはならないが、本発明を実際に実装するクライアントは、典型的には、そのことを表示する新規のヘッダを（各々のデータ要求に付随する多数のヘッダの間に）含むことになる。

現在利用可能なウェブ・ブラウザは、いまや、それらがサポートする機能について、またどの（人間）言語が許容されるかといった、それらのユーザが必要とするコンテンツの種類についても、大量の情報を送信する。例えば、以下のような要求があり得る。
GET / HTTP/1.1
Host: ibm.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.5)
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

リクエスタが「安全な」コンテンツ保護を与えることがきるかどうかを識別するための新規の要求ヘッダを追加することができる。コンテンツの型「安全な」は、コンテンツの既存のカテゴリとは異なる（ＭＩＭＥ型、人間言語、エンコードの型又は文字セットでないからである）。第１の実施形態において、新規の要求ヘッダは、フィールド名「Ａｃｃｅｐｔ−Ｓｅｃｕｒｉｔｙ」を有するが、これは単に例証的な一例である。フィールド名が何であろうと、新規のヘッダ・フィールドは、要求するクライアントにより、発信源タグ付けを用いたデータ保護が与えられるかどうかを示す単純な表示とすることができる。

要求ヘッダ「Ａｃｃｅｐｔ−Ｓｅｃｕｒｉｔｙ：ｏｒｉｇｉｎ−ｔａｇｇｉｎｇ」は、サーバが安全なデータの送信を望む場合、ブラウザはその安全なデータを保護することができることを示すが、これは安全なデータを要求するわけではない。追加のヘッダは全てのＨＴＴＰ要求に含めることができるが、これは必須ではない。このような新規のヘッダは、異なる種類の随意に実装されるセキュリティを用いる将来の拡張を可能にする。例えば、「Ａｃｃｅｐｔ−Ｓｅｃｕｒｉｔｙ」要求ヘッダ、及び、発信源タグ付けに基づくデータ伝送の制限は、別のセキュリティ選択肢と共に実装することが可能である。

サーバは、クライアントにダウンロードする準備ができた要求されたページにアクセスする（３１０）が、ウェブ・サーバは、いずれかの機密データを伝送する前に新規の要求ヘッダの存在についてチェックするように構成することができる。チェックは、全てのＨＴＴＰ要求に対して実施することができ、又はウェブ・サーバがＨＴＴＰ要求に応答する際にデータの機密度の表示を検出するメカニズムを備えている場合には、ウェブ・サーバがアクセスしたページ内の機密データを特定した場合にのみ応答して実施することができる。一実施形態において、データの機密度の表示は、データを作成するとき又はコンテンツ・サーバにストアするときに挿入することができる。

データの機密度をチェックする前に又はその後のいずれでクライアントの能力をチェックするかに関する特定の順序は本発明には重要ではない。ウェブ・サーバが要求されたページ内で機密情報を特定し、そして要求するクライアントがそのデータの保護を誓約していない（即ち、要求の中に新規のヘッダを含めていない）とウェブ・サーバが判断した場合には、本発明の一実施形態によるサーバは、要求を拒否することによって、又は、機密データを含めずに要求されたページを提供することによって、クライアントに応答する（３２０）。

ウェブ・サーバは異なった仕方で動作するようにプログラムし、構成することができる（また、幾つかのウェブ・サーバは本発明をサポートするためのいずれかの新規の機能を実装しなくてよい）が、本実施形態において設けられる新規の要求ヘッダは、機密データを提供するかどうかについて、サーバが情報に基づく判断を行うことを可能にする。それゆえ、サーバは、それぞれのサーバに機密データを保護するためのクライアントの能力及び誓約について通知しない如何なるクライアントにも、その機密データの提供を拒否することができる。

上記の本発明の実施形態は、機密データを保護すると主張するが実際には保護しないＨＴＴＰクライアントを妨げる如何なるメカニズムも含まないことに留意されたい。この第１の実施形態において、ＨＴＴＰクライアントは人間ユーザの代理人と見なされており、本発明の範囲は、ユーザに委ねられるデータにのみ拡張される。認可されたユーザのみが機密データを取得できることを保証するためには、ユーザ認証の公知の解決策を用いる必要がある。

ウェブ・サーバが要求されたページの中で機密データを特定し、そして要求ヘッダ内のフィールドのチェックが、要求するクライアントは機密データの保護を与えると判断する場合には、ウェブ・サーバは、要求されたページ及び「機密データ」フラグを要求側クライアントに伝送する（３３０）。本発明とは独立であるが、転送中の傍受を防止するために、機密データのいずれの伝送も、セキュア・ソケット・レイヤーのようなセキュリティ・メカニズムを用いて保護することが一般に望ましい。

従って、本実施形態において、どのデータが機密データであるかの判断は、そのデータを提供するサーバによって実施される。ＨＴＴＰ要求に応答して機密データが提供される（３３０）ときは、この応答は、そのコンテンツが本発明により機密データとして処理されることを示すヘッダを搬送することになる。「機密データ」ヘッダは、特定の発信源情報を発信源タグに含めることに関するウェブ・サーバからの明示的な命令を含むことができ、この命令は、発信源タグ・ジェネレータ２６０によって実行される。このデータを受信する（３４０）クライアントがスクリプト化可能であり、このデータが、スクリプト動作がアクセス可能なメモリ領域に配置される場合には、クライアントは、データを保存するとき且つスクリプトを実行する前に、そのデータに発信源タグを添付する（３５０）必要がある。その後、発信源タグは、クライアント内において受信したデータ要素から生成されるあらゆる新規のデータ要素に伝播され（３６０）（後述のように）、そして発信源タグは、タグ付きデータ要素の伝送を制御する（３７０）のに用いられる（同様に後述する）。

タグ内で発信源を記述する精度は、サーバが決定することができる。例えば、小規模な会社であれば、ブラウザに対して「ｃｏｍｐａｎｙ．ｃｏｍ」の発信源タグをそのデータに添付させるヘッダを用いて、自社のイントラネット上の全ての文書を取り扱うことができる。それゆえ、スクリプトは、そのデータを社内のあらゆるシステムに送信できるが、外部のどこにも送信できない。より大規模な会社であれば、ブラウザに対して「ｓｅｃｒｅｔｄｏｃｓｔｏｒｅ．ｒ−ａｎｄ−ｄ．ｃｏｍｐａｎｙ．ｃｏｍ」又は「ｗｅｂａｐｐｓ．ｆｉｎａｎｃｅ．ｃｏｍｐａｎｙ．ｃｏｍ」でデータにタグ付けさせるヘッダを用いて、会社のデータのうちのあるものをより厳しく制限することができる。共有サーバ上にあり、同じくそこに常駐し得る他のアプリケーションを信頼することができないウェブ・アプリケーションは、データが「ａｐｐｓ．ｓｈａｒｅｄｈｏｓｔｉｎｇｃｏｍｐａｎｙ．ｃｏｍ」のドメインだけでなくさらに、ポート番号「８０８０」及びファイルパス「／ｃｕｓｔｏｍｅｒｓ／ａｃｃｏｕｎｔ４２／ｓｅｃｒｅｔｄｏｃｓ」でタグ付けされるようにデータを取り扱うことできる。これは、排他的に特定のウェブ・アプリケーションの制御下にある位置情報に基づく発信源表示を与えるが、これに対して同じサーバ上の他の位置はそれほど正確に指定する必要はない。このように、そのウェブ・アプリケーションの排他的制御下にある位置は、以下のように指定することができる。
http://apps.sharedhostingcompany.com:8080/customers/account42/secretdocs/
従って、上記のタグ付けスキームは、共有サーバの場合にも対処可能な十分な正確さを有するが、これに対して共有サーバを扱わない場合には、ホスト名が十分であり得る。

ページ上のスクリプト化されたダイアログ・ボックス及びテキスト・ボックスにタイプ入力された情報、及びローカル・ファイルからロードされたデータは、機密度の審問を委託することができる発信源サーバを有さない。この問題は、ユーザから取得される情報、又は別にスクリプト・エンジンが動作するコンピュータから取得若しくは生成される情報に、「ローカル」を意味する特別の発信源タグでタグ付けすることにより対処することができる。このタグは、広い意味で他の発信源タグに類似するが、後述のように特別に取り扱うことができる。

殆どのブラウザはまた、ＨＴＴＰ以外のプロトコルを介してデータにアクセスすることができ、広く用いられている例はファイル転送プロトコル（ＦＴＰ）である。幾つかの場合において、これらのプロトコルもまた、ＨＴＴＰに関して上述したように追加のヘッダを用いて拡張することができる。これに対して他の場合には、上記の「ローカル」発信源タグを用いてローカル・ファイルと同様にデータを取り扱うことがより適切である（例えば、ブラウザがＳＭＢ又はＮＦＳ共有ファイルシステム・プロトコルを実装している場合）。本発明は、幾つかの難解なプロトコルが発信源タグ付けシステムがないままであっても、相変わらず有用且つ有効であり、その理由は、そのようなプロトコルが本発明から利益を得るような種類のウェブ・アプリケーションに使われる可能性は低いからである。

本発明の一実施形態において、注釈を生成してストアするための上述の技術は、必要な記憶容量を減らし、注釈伝播のより高速な実施を可能にするように改良される。典型的な用途においては、常時用いられる注釈値の数は少数（たぶん１つのみ）であろうが、これらの値は非常に多くの個々のデータ要素に適用することができる。改良は、この特徴を考慮に入れて発信源値の中心表を利用する。個々の注釈は、それら自体のコピー値を伝えるのではなく表の適切な行を示すだけの必要がある。

３．タグの伝播
ひとたびデータの一項目が発信源タグを有すると、それから派生する全ての他のデータに同じタグが伝播される３６０。より具体的には、入力及び出力の両方を有する全てのスクリプト動作に対して、入力のデータ構造体内に存在する全ての発信源タグが、スクリプト・エンジン２４０のタグ・プロパゲータ・コンポーネント２７０により、対応する出力のデータ構造体に転写されることになる。例えば、ＪａｖａＳｃｒｉｐｔのＳｔｒｉｎｇ．ｓｕｂＳｔｒｉｎｇ（）メソッドは、テキストの文字列を入力として取得し、テキストのより短い文字列を出力として生成する動作である。このメソッドを本発明によるスクリプト・エンジン２４０内で用いて、「ｅｘａｍｐｌｅ．ｃｏｍ」から安全に取得したページからあるテキストを抽出したとすると、その抽出されたテキストもまた、「ｅｘａｍｐｌｅ．ｃｏｍ」の発信源でタグ付けされることになる。この実施形態に関して、オブジェクトに対して実行されるいずれのスクリプト動作も、オブジェクトを入力として取得することと見なす必要がある。

上記の背景技術の節で述べたように、スクリプト・エンジンは、典型的には、構造化言語で記述されて特定の動作を与える。これらの動作は、その構造化言語で記述されたプログラム・コードにより定義される。本実施形態において、この節で説明する付加的な動作は、スクリプト・エンジン内のプログラム・コードにタグ伝播機能を追加することによって実装される。スクリプトは、本発明を実装しないスクリプト・エンジンにおけると全く同じに一連の動作の要求を続けることになるが、ユーザ及びスクリプト・プログラマに対して透過的に、発信源タグが生成され（３５０）、次いで伝播される（３６０）。

スクリプト動作が１つより多くの入力項目に対して行われ、そして少なくとも２つの入力項目が全ては同じ発信源からではない発信源タグを有するときは、出力データは特別なタグを取得する。タグ付きデータはその発信源以外のどこにも送信することができず、そして新規のデータのソースは複数の発信源を包含するので、許可される伝送の規則の範囲内で送信することができる位置は存在しない。従って、特別なタグは「ＮＯＷＨＥＲＥ」を表示し、このようにタグ付けされたデータはスクリプト環境から出ることができない。

この特定の実施形態において、上述の伝播は、制限が強くなる順に以下の４つの型の発信源タグを用いる。
ＮＯＮＥ：項目は発信源タグを有しない。何故なら項目が取得されたＨＴＴＰセッション又は他の手段は安全として示されなかったからである。
ＬＯＣＡＬ：項目はユーザにより入力されたか又はローカル・ファイルからロードされた。
ＯＲＩＧＩＮ：データが取得された位置を示す標準的な発信源タグである。スクリプト環境において同時に用いられる多数の異なる発信源が存在し得る。
ＮＯＷＨＥＲＥ：このデータ項目が取得されたパスには１つより多くの発信源でタグ付けされたデータが関与した。
このような種類のタグが２入力スクリプト動作の場合に相互作用する仕方を表１に示す。

２入力動作の場合と同様に、３つ又はそれ以上の入力要素によるスクリプト動作は、出力（単数又は複数）に、入力の中で見出される最も制限の強いタグ型を割り当てるが、例外として、最も制限の強い型が「ＯＲＩＧＩＮ」であり、且つ、１つより多くの発信源位置が存在する場合には、前述のように出力には「ＮＯＷＨＥＲＥ」が用いられることになる。単一入力動作の場合には、全ての出力はその入力項目のタグを継承する。

スクリプト動作の出力に結合させるタグを決定するための一連のステップを図５に示すが、図５に示した特定の動作シーケンスは、本発明の例証的な一実施形態のみに関する。この実施形態によれば、ＨＴＴＰクライアントがそのローカル・メモリから入力データ（例えば、検索されたウェブ・ページなど）を引き出して（４００）処理を開始するとき、ＨＴＴＰクライアントは、従来の仕方で入力データを処理してスクリプトを特定する。次いで、ＨＴＴＰクライアントはそのスクリプト・インタープリタ２５０を呼び出す。各スクリプト命令を実行する前に、スクリプト・インタープリタは、入力データ要素に結合したタグのセットを抽出し（４１０）、それらをタグ・プロパゲータ２７０に渡す。タグ・プロパゲータは、次いで、一組の規則を適用して、スクリプト動作の出力に対する適切なタグを決定する。入力データ上の任意の発信源タグの存在のチェック（４２０）が、入力データ要素に結合したタグは存在しないと判断する場合には、このプロセスをショートカットすることが可能である。この「ショートカット」は、図５のステップ４２０とステップ５００の間の矢印によって示す。

入力がタグ有しないとステップ４２０で判断された場合、出力もまた関連するタグを有しない。しかしながら、新規のデータ要素がユーザによって入力されるか又はローカル・ファイルからロードされる場合、これらの入力は、タグ型「ＬＯＣＡＬ」を有するとして扱われ、その場合、スクリプト・エンジンの処理の出力もまた、関連するタグ型「ＬＯＣＡＬ」（又は、他のタグ付き入力と組み合わされた場合には、より制限が強いタグ型）を有することになる。このことは以下でより詳細に説明する。

関係する入力タグが存在するためにステップ４２０における判断が肯定である場合、本実施形態によるタグ伝播処理が、最も制限が強いタグ型から開始する順序で実施される。即ち、タグ・プロパゲータ２７０により実行される第１のステップは、いずれかの入力がタグ型「ＮＯＷＨＥＲＥ」を有するかを判断すること（４３０）を含む。有する場合には、タグ型「ＮＯＷＨＥＲＥ」がスクリプト・エンジンの出力データ要素又は複数要素に結合される（４４０）。

データ伝送の制御にタグをどのように用いるかは、以下の例示的な伝播シーケンスの説明に続く「データ伝送の制御のための発信源表示の使用」と題する節において、より詳細に説明する。しかしながら、ここで、この制御の一例を例証として与える。データ要素にタグ型「ＮＯＷＨＥＲＥ」が結合しているとき、スクリプト・インタープリタは、スクリプト命令を実行する（５００）ことができるが、但し、これらのスクリプト命令に応答するＨＴＴＰクライアントの動作が、結合したタグ「ＮＯＷＨＥＲＥ」により課せられる制限に従うことになる点で異なる。具体的には、タグ「ＮＯＷＨＥＲＥ」を有するデータ要素は、スクリプト環境の外部へ伝送されることを妨げられることになる。

図５の伝播シーケンスに戻ると、どの入力データ要素もタグ型「ＮＯＷＨＥＲＥ」を有しない場合には、プロパゲータは、特定のスクリプト命令に対し、複数の異なる「ＯＲＩＧＩＮ」タグを有する複数の入力が存在するかどうかを判断する（４５０）。存在する場合には、出力データ要素又は複数要素にタグ型「ＮＯＷＨＥＲＥ」を結合させる（４４０）。

ステップ４５０における判断が否であった場合には、プロパゲータは、現行のスクリプト動作に関する入力データ要素が単一の「ＯＲＩＧＩＮ」型タグを有する（即ち、機密データが一つだけ存在するか又は全ての機密データが同じ発信源を有する）かどうかを判断する（４６０）。有する場合には、関係する「ＯＲＩＧＩＮ」型タグをスクリプト命令の出力データ要素に結合させる（４７０）。

ステップ４６０における判断が否であった場合には、プロパゲータは、現行のスクリプト命令に対するいずれかの入力が結合した「ＬＯＣＡＬ」タグ型を有する（ユーザにより入力されるか又はローカル・ファイルからロードされたデータ要素を含む。これらは「ＬＯＣＡＬ」タグを有すると見なされる。上記を参照）かどうかを判断する（４８０）。有する場合には、「ＬＯＣＡＬ」タグをスクリプト動作の出力データ要素に結合させる（４９０）。

スクリプト動作の出力に結合させるタグを決定した後で、ＨＴＴＰクライアント内のスクリプト・エンジンは、後述のように、タグにより課せられるデータ伝送の制限に従って、その処理を実行する（５００）。ステップ４１０乃至ステップ５００は、スクリプト内の各スクリプト命令ごとに繰り返して実行され、スクリプト・エンジンは実行中にタグを伝播させる。

スクリプト動作に加えて、それ自体は実際にはスクリプト動作ではないが、スクリプトのドメインに影響を与える他の動作が存在し得る。例えば、テキスト・ボックスにタイプ入力するユーザは「ＬＯＣＡＬ」データを生成することになるが、このユーザはこの「ＬＯＣＡＬ」データを「ＯＲＩＧＩＮ」データと組み合わせる可能性がある。その場合には、タグ・プロパゲータ・コンポーネント（又は、ＨＴＴＰクライアント内の他の場所で実行される等価のコンポーネント）が規則を適用して、結果として生じるデータに対する適切なタグを決定することが望ましい。本実施形態において、ＨＴＴＰクライアントは、タグ・プロパゲータを呼び出し、タグ付きデータの任意のそのような組合せに対する適切なタグを決定する。他の実施形態においては、タグ・プロパゲータはスクリプト・エンジンから独立したコンポーネントとして実装することができる。テキスト・ボックスにタイプ入力するユーザの例においては、スクリプト・エンジンは、通常全てのキー押しに対して呼び出され、その結果、変更通知されるように登録されたスクリプトのどの部分をも起動することができ、それにより、スクリプト・エンジンのタグ・プロパゲータ・コンポーネントが直ちに呼び出されて、新規のデータに対する適切なタグが決定される。

４．データ伝送を制御するための発信源表示の使用
ある特定のスクリプト動作は、ウェブ・ブラウザからネットワーク上の他の場所にあるサーバへのデータ伝送を含む。例えば、ＨＴＭＬフォーム（ＲＦＣ１８６６に定められた）をスクリプト制御の下でサブミットすることができ、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ（前述の）を用いることができ、又は、その「パス」、「クエリ」、又は「フラグメント」部分がデータ搬送手段として特別に構成されたＵＲＬにアクセスするようにブラウザに命令することができる。本発明は、任意のデータがブラウザの外に出ることを許可される前に実施する必要がある付加的な処理を定める。説明する動作は、ブラウザ内で実行されるスクリプトに対する変更を何も必要とせずに、ブラウザの構造化言語プログラム・コードに組み入れられる。

データを伝送する能力があると識別されたあらゆるスクリプト動作は、その入力データのタグにより条件付けられる。１つのスクリプト命令の入力データがその前のスクリプト命令の出力である可能性があり、その場合には、上述のタグの伝播が、データ伝送を制御するための関連するタグを決定したことになる。伝送制御は、スクリプト・エンジン２４０のコンポーネントとして実装することができ、又は、ブラウザ内に独立に実装することができる。以下で定められる規則により、データが伝送できない場合には、伝送動作は完了できないはずである。この動作はまたエラー報告を（必ずしもユーザに向けてではなく）行うことが好ましい。

幾つかの伝送動作は、異なるタグを有し得る複数の入力を扱う可能性がある。この場合、タグ・プロパゲータ２７０に関して上述したように、伝送に関する規則を適用する前に、タグを組み合わせる必要がある。

伝送されるデータが如何なる型の発信源タグをも有しない場合には、自由に送信することができる。これは、本発明を実装していないブラウザの状態（代替的なデータ保護メカニズムが設けられていない場合）、及び、機密でないデータを扱うブラウザの状態である。

データが特別な「ＮＯＷＨＥＲＥ」タグを搬送する場合、そのデータをローカルのスクリプト環境の外部に伝送することはできない。

データが「ＯＲＩＧＩＮ」型の発信源タグを搬送する場合には、データは、そのタグに矛盾しない位置のみに伝送することができる。矛盾しない位置とは、
同じＤＮＳドメイン又はそのサブドメインを有する（例えば、「ｄｅｖ．ｃｏｍｐａｎｙ．ｃｏｍ」を発信源とするデータは、「ｄｏｃｓｔｏｒｅ．ｄｅｖ．ｃｏｍｐａｎｙ．ｃｏｍ」に送信することができる）位置と、
タグ内で指定されたポート番号に対応するインターネット・プロトコル・ポート上に常駐する（タグがポート番号を指定する場合）位置と、
タグがパスを指定する場合、そのパス又はその派生パスに同様に存在する（例えば、発信源がパス「／ａｐｐｓ／ｅｘｐｅｎｓｅｔｏｏｌ」を含むデータは、「／ａｐｐｓ／ｅｘｐｅｎｓｅｔｏｏｌ／ｓｕｂｍｉｔｆｏｒｍ」に送信することができる）位置と
のうちの一つである。

データが特別な「ＬＯＣＡＬ」タグを搬送する場合、ブラウザにより、以下の規則が実施される。
１．スクリプト・エンジンの中に「ＯＲＩＧＩＮ」又は「ＮＯＷＨＥＲＥ」タグのいずれかを有するデータが存在しない場合、ブラウザは、機密データが含まれないと見なして、「ＬＯＣＡＬ」データをどこにでも送信することを許可することができる。このことは、既存のウェブ・ページ及びアプリケーションの動作を変更しないという利点を有するが、「ＬＯＣＡＬ」タグを有するデータについては、新規のデータ要素を初めに作成するときに可能性のあるセキュリティ露出を避けるような代替的な動作が好ましい可能性ある。
２．エンジンの中の幾つかのデータが機密データである場合には、ブラウザは「ＬＯＣＡＬ」データの伝送を妨げるように構成することができ、又は、「ＬＯＣＡＬ」情報を伝送する前にユーザに問うように構成することができる。しかしながら、ユーザに決定を委ねる場合には、ユーザが時々セキュリティ露出を容認すべきでないときに容認することを認識する必要がある。多くの場合、ユーザによって入力されたデータは、伝送される前に通常の処理により、「ＯＲＩＧＩＮ」タグ付きデータと組み合わされることになり、従って、「ＬＯＣＡＬ」タグに関する規則ではなく、「ＯＲＩＧＩＮ」タグに関する規則に従うことになる。
３．ブラウザ内の全ての発信源タグが同じであるときは、ユーザ制御に頼ることなく、「ＬＯＣＡＬ」データのその発信源への伝送を許可する（しかし、他の場所への伝播はなお問題にする）ことで、より多くの場合を処理することができる。この解決策は、安全な文書編集アプリケーションのような普通の場合に、セキュリティとユーザビリティの釣合を取る。

上述の規則の組は、データ・セキュリティとユーザ経験の混乱との間の釣合を取るが、一方、ブラウザがそれら情報の機密度について明確な知識を有しない可能性があることを容認する。

５．暗号化データのための拡張
上述の特徴は、機密情報の伝送を制御するための完全且つ有利なシステムを提供する。しかしながら、これらの機能を暗号化データの概念を含めることにより拡張して、更に有用な能力を付与することが可能である。これは送信中のデータ・ストリームの如何なるＳＳＬ暗号化からも完全に独立していることに留意されたい。

スクリプト及びページを変えずに実装可能な基本的な本発明とは異なり、この機能は、それを用いるように具体的にスクリプトを書くことを必要とする。この拡張をサポートするために、適切な公開暗号を用いてデータと暗号化形の間の変換を行うことができる新規の動作を、スクリプト・エンジン内で利用できるようにすることになる。

５番目の種類の発信源タグ「ＥＮＣＲＹＰＴＥＤ」が追加される。暗号化データに関する規則は、以下の通りである。
作成：データは暗号化形態で届くことができ、その場合このことは、それを搬送する伝送の中の適切なＨＴＴＰヘッダにより示される。既存のデータを暗号化するスクリプト動作を実行するのに、スクリプト・エンジンの明示的な暗号化サポートが用いられるとき、その結果もまた、それが搬送した可能性のあるいずれの以前のタグにも関係なく、この「ＥＮＣＲＹＰＴＥＤ」タグでラベル付けされる。
伝播：一般に、暗号化データを他の情報と組み合わせることが有用である可能性は低い。しかしながら、そうすることは可能であり、その場合には、上述の通常の伝播に対してと同様に、出力は、暗号化されていない入力要素のタグ（又は、１つより多くのタグが存在する場合には、それらのタグのうち最も制限の強いもの）を取得することになる。
暗号解読：暗号化データがスクリプト・エンジンの機能を用いて暗号解読されるとき、その出力には「ＮＯＷＨＥＲＥ」の発信源タグが付与され、伝送されることはできない。
伝送：「ＥＮＣＲＹＰＴＥＤ」でタグ付けされたデータは、鍵を保持しない如何なるエンティティにも無用であるので、どこにでも伝送することができる。

従って、本発明は、機密データに発信源表示を結合させて、個々のデータ要素にタグ付けし、或いは、機密データを含むウェブ・ページ、ファイル、又はデータベースにタグ付けして、タグに従ってそのデータの前方伝送を制御する。機密データはユーザによってクライアント・データ処理システムに入力されることもあり、又は、ストアされたウェブ・ページ内などの安全コンテンツ・サーバにデータが保持されることもあるが、本発明は、その前方伝送を制御することを正当化するのに十分に機密であると考えられる任意のデータに対して適用可能である。本発明の上述の実施形態において、大部分のデータはこのような形で前方伝送を制約されることはなく、その理由は、インターネットを介して入手可能な大量のデータは公的に入手できることを意図したものであり、また、特定の情報片を作成又は編集した個人又は組織が保護は必要ないと判断する可能性があるからである。しかしながら、データ処理ネットワークを介してアクセス可能であり、且つ「信頼されない」スクリプトにより露出される可能性があり、それでも尚、ユーザが彼らの情報を他者に露出させずに利用可能なウェブ・サービス及びスクリプトを安全且つ有効に用いようとする場合に保護する必要がある大量の専有情報もまた存在する。

当業者であれば、上記の本発明の特定の実施形態は、本発明の範囲内で種々の方法で変更又は拡張することができ、従って、上記の詳細な実施形態の説明は、本発明に対する限定ではなく例証であると考えるべきであることを理解するであろう。

例えば、上記の新規要求ヘッダは、本発明の可能性のある一実施形態のみを表すものであり、本発明の１つの代替的な実施形態は新規要求ヘッダを必要としない。その代りに、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ型の要求の使用に対するセキュリティ制約が緩和され、本発明の一実施形態による修正型スクリプト・エンジンで置き換えられ、データが第３者のウェブサイトから取得されるときはいつも機密としてデータのタグ付けを行う。現在、スクリプトは、そのスクリプトがダウンロードされたサーバ以外のサーバからデータを取得するのにＸＭＬＨｔｔｐＲｅｑｕｅｓｔ型の要求を（少なくとも直接には）用いることはできない。これは、悪意のあるＪａｖａＳｃｒｉｐｔがユーザの信用証明書、又はファイアウォールの背後にあるユーザのデータ処理システムの位置を利用して攻撃を行い、第３者サイトからのデータをウェブ・ブラウザに読み出し、次いでこのデータをスクリプトの発信元であるサイトに送り返すのを防止するためである。これは、「クロス・サイト・スクリプティング脆弱性」として知られる。本発明の一実施形態によるスクリプト・エンジン内で発信源タグを用い、ダウンロードされたデータを機密として特定することで、そのような攻撃は、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔに対する既知の制限に頼らずに防止することができる。従って、第３者サイトからのデータをダウンロードして有用に処理することを許可するとともに、そのようなデータに機密とタグ付けして、セキュリティを維持することができる。

第２に、異なるブラウザは、「機密データ」フラグを含むデータの受信に応答して発信源タグを挿入するための異なるメカニズムを実装することができ、そして、関係するデータ構造体内における発信源タグのカテゴリ及び具体的な表現もまた、本発明の異なる実施形態の間で変えることができる。典型的な当業者であれば、ひとたび望ましい動作に関する上記の記述を読めば、本特許明細書において定められる本発明の範囲内に種々の実施の選択肢があることを認識するであろう。

１０、２０、３０：クライアント・データ処理システム
４０、５０、６０：サーバ・データ処理システム
７０：ＨＴＴＰサーバ
８０、９０：アプリケーション・サーバ
１００：データ処理装置
１１０：揮発性システム・メモリ
１２０：不揮発性記憶装置コンポーネント
１３０：内部通信バス
１４０：デバイス・ドライバ
１５０：接続インターフェース
１６０：マウス
１７０：キーボード
１８０：モニタ
１９０：ネットワーク・インターフェース
２００：オペレーティング・システム・ソフトウェア
２１０：ウェブ・ブラウザ
２２０、２３０：アプリケーション・プログラム
２４０：スクリプト・エンジン
２５０：スクリプト・インタープリタ
２６０：発信源タグ・ジェネレータ
２７０：タグ・プロパゲータ

Claims (18)

1. 機密データの伝送を制御する方法であって、スクリプト環境内で実行される、
   発信源表示を第１のデータ要素に結合させるステップと、
   前記第１のデータ要素から生成されたデータ要素に前記発信源表示を伝播させるステップと、
   前記第１のデータ要素及び前記生成されたデータ要素の伝送を、前記発信源表示を参照して識別された許可された宛先のみに制限するステップと
   を含む方法。
2. 発信源表示を第１のデータ要素に前記結合させるステップは、前記第１のデータ要素が機密データを含むとの判断に応じて実行される、請求項１に記載の方法。
3. 前記伝送を制限するステップは、前記第１のデータ要素が機密データを含むとの判断に応じて実行される、請求項１に記載の方法。
4. 前記第１のデータ要素は、前記スクリプト環境から遠隔にあるソース・データ処理システムから取得され、前記伝送を制限するステップは、前記ソース・データ処理システム以外の任意の宛先への前記第１のデータ要素の伝送を妨げるステップを含む、前記請求項のいずれか１項に記載の方法。
5. 発信源表示を第１のデータ要素に前記結合させるステップは、前記第１のデータ要素がスクリプト動作によって処理されるとの判断に応じて実行される、前記請求項のいずれか１項に記載の方法。
6. 前記結合させるステップ、前記伝播させるステップ、及び前記制限するステップは、遠隔サーバ・データ処理装置と通信するためのネットワーク接続インターフェースを備えたクライアント・データ処理装置上で実行され、
   前記ネットワーク接続インターフェースを経由して、前記遠隔サーバ・データ処理装置に、前記遠隔サーバ・データ処理装置から前記第１のデータ要素を引き出す要求を送信するステップと、
   前記遠隔サーバ・データ処理装置からデータを受信するステップと
   をさらに含む、前記請求項のいずれか１項に記載の方法。
7. 前記要求を送信するステップは、前記要求内において、前記クライアント・データ処理装置が前記伝送を制限するステップを実行するための手段を備えることを明記するステップを含む、請求項６に記載の方法。
8. 発信源表示を第１のデータ要素に前記結合させるステップは、前記遠隔サーバ・データ処理装置から、データが機密データを含むとの表示を含むデータを受信することに応じて実行される、請求項６又は請求項７に記載の方法。
9. 前記送信するステップ及び前記受信するステップは、ＨＴＴＰクライアント・プログラムにより実行され、前記第１のデータ要素は、前記ＨＴＴＰクライアント・プログラムにより、前記ＨＴＴＰクライアント・プログラムが機密データを保護することができるとの表示を含むＨＴＴＰ要求に応じて取得される、請求項６に記載の方法。
10. 前記結合させるステップ及び前記伝播させるステップは、前記クライアント・データ処理装置内において動作するスクリプト・エンジンにより実行される、請求項６乃至請求項９のいずれか１項に記載の方法。
11. 前記発信源表示を前記伝播させるステップは、
    １つ又は複数の出力を生成するスクリプト動作に対する１つ又は複数の入力の組を識別するステップと、
    前記１つ又は複数の入力に結合されたあらゆる発信源表示を識別するステップと、
    前記入力の発信源表示から第２の発信源表示を派生させるステップと、
    前記１つ又は複数の生成された出力に関連する前記第２の発信源表示を保存するステップと
    を含む、
    前記請求項のいずれか１項に記載の方法。
12. 前記第１のデータ要素は、スクリプト動作によって、前記スクリプト環境から遠隔のデータ処理システムから引き出される、前記請求項のいずれか１項に記載の方法。
13. 少なくとも１つのデータ処理装置と、
    少なくとも１つのデータ記憶装置と、
    スクリプト・インタープリタと、
    発信源表示を第１のデータ要素に結合させるための手段と、
    前記発信源表示を、前記第１のデータ要素から生成された新規のデータ要素に伝播させるための手段と、
    前記第１のデータ要素及び前記生成されたデータ要素の伝送を、前記データ処理システムから、前記発信源表示を参照して識別される許可された宛先だけまでに制限する手段と
    を備えるデータ処理システム。
14. 遠隔サーバ・データ処理装置と通信するためのネットワーク接続インターフェースと、
    前記ネットワーク接続インターフェースを経由して、前記遠隔サーバ・データ処理装置に、前記遠隔サーバ・データ処理装置から前記第１のデータ要素を引き出す要求を送信するための手段と、
    前記遠隔サーバ・データ処理装置からデータを受信するための手段と
    をさらに備える、請求項１３に記載のデータ処理システム。
15. 前記結合させるための手段及び前記伝播させるための手段は、スクリプト・エンジンのコンポーネントを含む、請求項１３又は請求項１４に記載のデータ処理システム。
16. 前記結合させるための手段、前記伝播させるための手段、及び前記制限するための手段は、ＨＴＴＰクライアント・プログラムのコンポーネントを含む、請求項１３乃至請求項１５のいずれか１項に記載のデータ処理システム。
17. 前記伝送を制限するための手段は特定用途向け集積回路を含む、請求項１３に記載のデータ処理システム。
18. 記録媒体に記録された、データ処理装置を制御するためのプログラム・コードを備え、
    前記プログラム・コードは前記データ処理装置上で実行して請求項１乃至請求項１２のいずれか１項に記載の方法を実施する、
    コンピュータ・プログラム。

Images