JP2007523411A - コンピュータ・デバイス用セキュリティ・モデルのための方法及びシステム - Google Patents

Abstract

コンピュータ・デバイスのグラフィックス・サブシステム内のセキュリティ・モデル及び実行モードのためのシステム、方法及びコンピュータ読取可能媒体が開示されている。独自のセキュリティ方針を有し、独自のセキュリティ・ニーズに基づいてインスタンス化されるときに保護ドメイン内に配置されるオブジェクトを作成するための均一な合理化された柔軟な方法が説明されている。プロセス境界は、セキュリティ・モデルを実行するための一次セキュリティまたは保護境界として使用される。セキュリティ・モデルは、大部分のオブジェクト・モデルはオブジェクトにインタフェースを持たせるという事実を利用する。オブジェクトのインタフェースは、どの呼び出し元オブジェクトがアクセス可能であるのかを判定するために使用される。したがって、オブジェクトの機能のインタフェースへのマッピングがある。オブジェクトは、呼び出し元オブジェクトによる調査と呼び出し元が認識している内容に基づいて、呼び出し元オブジェクトが何に対して資格を有しているのかを判定する。呼び出し元の調査は、呼び出し元が、他のどの態様のオブジェクトに対して資格があるのかを判定する。本発明の方法の態様は、インタフェースの存在を認識している外部オブジェクトからの呼び出しを受信しているターゲット・オブジェクトのインタフェースを含む。ターゲット・オブジェクトでは、第１の呼び出しに基づいて、外部オブジェクトがターゲット・オブジェクトの他のインタフェースにアクセスできるか否かが判定される。アクセスはこの判定に基づいて他のインタフェースに対して許可される。
【選択図】図６

Description

（優先権の主張）
本発明は、２００４年２月９日に出願されたアメリカ合衆国仮特許出願第６０／５４３，１０８号に基づく優先権を主張する。この出願の内容は、参照することにより本書に組み込まれる。

（関連出願）
本発明は以下の出願に関連する。
（１）代理人整理番号４００１．Ｐａｌｍ．ＰＳＩの「A System and Method of Format Negotiation in a Computing Device」という出願
（２）代理人整理番号４００２．Ｐａｌｍ．ＰＳＩの「A System and Graphics Subsystem for a Computing Device」という出願
（３）代理人整理番号４００４．Ｐａｌｍ．ＰＳＩの「A System and Method of Managing Connections with an Available Network」という出願
これらの出願は、本出願と同日に出願されており、それぞれの出願の内容は、参照することにより本書に組み込まれる。

（技術分野）
本発明は、概して、オペレーティング・システム・ソフトウェアに関する。より詳細には、本発明は、セキュリティ・モデルを実現するためのソフトウェア、及びコンピュータ・デバイスのグラフィックス・サブシステムにおけるその実行に関する。

（序論）
グラフィックス・サブシステム及びオペレーティング・システムは、一般に、（アプリケーション・プログラマ等のような）サード−パーティの開発者や、完全に信頼できない発行元によって作成された外部のアプリケーション及びプラグ−イン・コンポーネントに、それらの環境における実行を許可する。このような実行は、頻繁に、ネイティブ・システムに対するセキュリティ上の問題を引き起こす。サード−パーティ・コンポーネントが不完全に作成されており、そのために重大な欠陥を有している場合、オペレーティング・システムの環境の中でそれを実行すると、深刻な、あるいは致命的なエラー状態を引き起こす可能性がある。サード−パーティ・コンポーネントが（ウィルスのような）悪質なものである場合、それは故意に極秘データを盗んだり、破壊的な動作を実行するかもしれない。不完全に作成されたコード、または悪質なコードに対しての保護を実行する方法を有さないために、コードが実行されるときに、そのコードは正しく作成された良性のものであると暗に「信頼する」オペレーティング・システムもある。

しかしながら、ネイティブ・システムは、外部の不完全なあるいは悪質なコードによるシステムへの危害または侵入に対して予防措置を実行することが好ましい。最近の多くのシステムは、保護単位としてプロセスの利用を採用している。例えば、アプリケーション・プログラムのようなサード−パーティ・コンポーネントは、それぞれが独自のプロセスを実行する場合がある。このモデルでは、コードは独自のプロセス内では自由な実行を許可されるが、プロセスの境界はハードウェアのレベルで強制される。各プロセスは、システムにより、そのプロセスの外部のサービスにアクセスするための許可の特定のセットを与えられ、各プロセス中で実行されるコードは、許可を与えられたプロセスへの外部動作に制限される。このプロセスの保護単位としての利用は、所定レベルの複雑さを超えてオペレーティング・システムの中でほぼユビキタスであると言える。

保護単位としてプロセスを利用する適切な予防手段の実行には、コードとコンポーネントをプロセスに区分する方針及び関連する方法と、それらのプロセスに許可を与える方針及び関連付する方法の両方が必要である。

コードをプロセスに区分する方針及び方法は、この方針がシステムによって制御、操作できるコンポーネント間の境界を規定するのに重要である。コンポーネントＡとコンポーネントＢが同じプロセスにある場合、システムがいずれかのコンポーネントを他方の不備や悪意から保護できるという保証はない。例えば、コンポーネントＡのコードがコンポーネントＢのコードまたはデータにアクセスできれば、コンポーネントＢの極秘データへのアクセスを確保できるであろう。同様にコンポーネントＢが外部リソースＣに対するアクセスを要求、確保する場合、システムは、事実上、コンポーネントＢと同じプロセス内で実行しているすべてのコードにそのリソースに対するアクセスを与えたことになる。しかしながら、コンポーネントＡとコンポーネントＢが異なるプロセスで実行されている場合には、システムは一方のコードとデータを他方の不備または悪意のあるコードから確実に保護し、これらのコンポーネント内の一方に対する許可を、他方に対する許可を与えることなく確実に与えることができる。

システムをコンポーネントによる不備または悪意のあるアクションから保護する（及び、他のコンポーネントの一部への不備または悪意のあるアクションからコンポーネントを保護する）ための１つの簡単な共通の技術は、新規にインスタンス化された各コンポーネントを区分された専用のプロセスに入れることである。例えば、実行すべき各アプリケーションに対して新たなプロセスが作成され、アプリケーションがそのプロセス中に入れられることで、安全なプロセス境界によって他のサード−パーティ・コンポーネントとシステム・コンポーネントの両方から区分される。しかしながら、各プロセスに関連する著しいオーバヘッドがある。これは、プロセスの作成と破壊、及びプロセス内での通信のために必要な処理と比較したときのプロセス境界を超えてメッセージを送信するために必要な余分な処理に関連するメモリと処理時間の両方を含む。したがって、新しいアプリケーションごとにプロセスを作成するのは、きわめて非効率となる場合がある。多くの場合、コンポーネントは特定のシステムの動作に対してそれらのコンポーネント自体が信頼できることを示す信頼証明（例えば、悪意のある詐称者によって実質的に複製不可能な暗号シグナチャ等）を有する。他のケースでは、２以上のコンポーネントが、互いの関係では信頼できると見なされるが、機密のシステム・サービスに対しては信頼できると見なされず（例えば、コンポーネントＡとコンポーネントＢはともに同じサード−パーティ発行者またはベンダによって暗号化署名されているが、この発行者は必ずしもシステム自体には信頼されていない）、この場合、これらの両方のコンポーネントを単一のプロセスに入れることが適切である場合がある。これらの信頼できるオブジェクトをそれぞれ専用のプロセスに区分すると、システム・リソースを非常に無駄に使用し、システムの全体的な性能を引き下げることがある。

プロセスに許可を与える方針及び方法は、システムがアクセスするための許可をプロセスの中で実行中のコードに与える場合、そのコードは外部のリソースにアクセスできるために重要である。コードをプロセスに区分することにより「規則」（すなわち、コンポーネントは同じプロセスで使用可能な他のコンポーネントだけにアクセスできる）が確立される場合、プロセスに許可を与えるとその規則に対する「例外」（すなわち、これらの特定のシステム・サービスを除き、そのプロセスで実行しているどのコードが使用許可を有するのか）が確立される。多くのシステムでは、これは全てのセキュリティの情報、アクセス・コントロール・データ等を記憶するための中央レポジトリを使用して行われる。例えば、システム・サービスが要求を処理する必要がある場合、その要求元がそのサービスにアクセスする許可を有しているかどうかを中央権限に確認する。この設計は、システム全体のすべてのセキュリティ方針に関する非常に集中化した情報、保護されているコンポーネントと方策を実現する中央権限の間でのデータ及び方策の重複、及び中央権限とシステム内のオブジェクトとの間の持続的な通信を必要とし、そのいずれもが動的な、拡張可能なオープン・システムにおいては望ましくない

また、ほとんどのシステムでは、このような許可はプロセスに対して静的な方法により、定義され、追跡される。例えば、このようなシステムでは、コンポーネントは専用の独自のプロセスに存在するように設計され、そのコンポーネントに対してではなく、そのプロセスに対するセキュリティ制約を宣言する。コンポーネントがより動的にプロセスに区分されるシステムでは、コンポーネント・レベルでセキュリティの方針を定義することが好ましいであろう。これにより、好適に区分を決定するためにコンポーネント単位の情報を利用可能となり、共通利用できるコンポーネントのネットワークが区分方式でそのセキュリティ方針を定義可能となり、集中化及びそれに関連するオーバヘッドの要求の大半を排除することができるであろう。

必要とされている技術は、プロセス及び交錯するプロセスの境界に関連する非効率が最小限に抑えられる一方で、必要な保護が実行されるように、システム自体とその中で実行されている互いに関連するコンポーネントの両方のセキュリティの要求に基づいてコンポーネントをプロセスに区分する方法である。さらに、この第１の方法が存在し、コンポーネントが動的基準に基づいてプロセスに区分される環境で必要とされているのは、プロセスの区分の決定を通知し、及び軽快かつ拡張性のある方式でアプリケーション特有のセキュリティ方針を実行するために、システム内で実行中のコンポーネントによってセキュリティ方式を区分方式で定義できるようにする方法である。

本発明の付加的な特徴及び利点は、以下の説明に記載され、部分的にはその説明から明らかとなり、あるいは本発明の実施により学習されるであろう。本発明の特徴及び利点は、特に添付の請求項に指摘されている方法、機器、及び組み合わせによる手段によって実現され、得られるであろう。本発明のこれらの及び他の特徴は、以下の説明及び添付の請求項からより完全に明らかとなり、あるいはここで述べたように本発明の実施によって学習されるであろう。

本発明は、コンピュータ・デバイスのグラフィックス・サブシステム及びオペレーティング・システム内で、オブジェクトのためのセキュリティ・モデル、及びそのモデルの実行を提供するための改善されたシステム及び方法に対する従来の技術の要求に対処する。本発明は、オブジェクト・インタフェースの使用、及びオブジェクト周辺の保護境界としてプロセスを利用して実現される動的保護ドメインを利用するセキュリティの実行と連動した機能モデルを利用したオブジェクトとコンポーネントのためのセキュリティ及びアクセス・コントロールを提供するシステム、方法及びコンピュータ読取可能メディアを備えている。

本発明の方法としての態様は、独自のセキュリティ方針を有し、独自のセキュリティ・ニーズに基づいてインスタンス化されるときに保護ドメイン内に配置されるオブジェクトを作成するための均一な合理化された、柔軟な方法に関する。方法は、セキュリティ・モデルを実行するための一次セキュリティまたは保護境界としてプロセス境界を使用する。セキュリティ・モデルは、大部分のオブジェクト・モデルはオブジェクトにインタフェースを持たせるという事実を利用する。オブジェクトのインタフェースは、どの呼び出し元オブジェクトがアクセス可能であるのかを判定するために使用される。したがって、オブジェクトの機能のインタフェースへのマッピングがある。オブジェクトは、呼び出し元オブジェクトによる調査と呼び出し元が認識している内容に基づいて、呼び出し元オブジェクトが何に対して資格があるのかを判定する。呼び出し元の調査は、呼び出し元が、他のどの態様のオブジェクトに対して資格を有しているのかを判定する。

本発明の一態様では、コンピュータ・デバイスのオペレーティング・システム内のオブジェクトへのアクセスを制御する方法が説明されている。ターゲット・オブジェクトのインタフェースは、そのインタフェースの存在を検知している外部オブジェクトからの呼び出しを受信する。ターゲット・オブジェクトでは、第１の呼び出しに基づいて、外部オブジェクトがターゲット・オブジェクトの他のインタフェースへのアクセスを有するか否かが判定される。アクセスは、この決定に基づいて他のインタフェースに与えられる。

本発明の別の態様では、コンピュータ・デバイスのオペレーティング・システム内でオブジェクトを保護するための方法が説明されている。オブジェクトのためのアクセス制約が決定される。第１のオブジェクトのアクセス制約に対応するセキュリティ・プロファイルを有する保護ドメインが識別される。次にそのオブジェクトは保護領域内に入れられる。

本発明の上述した他の利点と特徴を得る方法を説明するために、前記に簡略して説明した本発明のより具体的な説明を、添付図面で図解されるその具体的な実施形態を参照することにより提供する。これらの図面は本発明の典型的な実施形態のみを表しており、したがってその範囲を制限すると見なされるべきものではないことを理解されたい。本発明は添付図面を使用することによりさらに具体的かつ詳細に記述、説明される。

（発明の詳細な説明）
本発明の種々の実施形態を以下に詳しく説明する。特定の実施を説明するが、これは例示的な目的のためだけに行うことを理解されたい。当業者は、他の構成要素及び構成を、本発明の精神及び範囲から逸脱することなく使用してよいことを理解するであろう。

本発明は、主にモバイル機器及び携帯端末の使用を目的としているが、図示するような任意のコンピュータ・デバイスで実行可能でもあるオペレーティング・システムのグラフィックス・サブシステムとして機能するシステム、方法、及びコンピュータ読取可能メディアを提供する。他のコンピュータ・デバイスの例としては、ノート型パソコン、タブレット、さまざまなインターネット機器、及びラップトップ型及びデスクトップ型コンピュータを含む。好適な実施形態では、グラフィックス・サブシステムは、携帯電話とＰＤＡの組み合わせのようなハンドヘルド・モバイル・コンピュータ・デバイスで動作する。

図１は、本発明の好適な実施形態におけるオペレーティング・システム１０のグラフィックス・サブシステム１００の２つの主要な態様を示す図である。この２つの態様は、描画（つまりレンダリング）モデル態様１０２とトランスポート態様１０４である。一般的に、グラフィックス・サブシステムは、グラフィックス及びディスプレイ・ハードウェアと接続し、そのハードウェア及びグラフィックス関連サービスへのアプリケーション及びシステム・ソフトウェア・アクセスを提供し、複数のアプリケーションの間のグラフィックス・ハードウェアへのアクセスを場合によっては多重化するオペレーティング・システムのコンポーネントである。

描画モデル態様１０２は、極めて表現に富んだ描画言語を定義する。これによりグラフィックス・サブシステムのプログラマは、経路塗りつぶし及びストローキングを含むプリミティブな描画コマンドを使用して画像を記述し、色の変調、混合、切り抜き等を加えることができる。レンダリングはターゲット領域内の各ピクセル値の定義として明示的にモデル化される。描画言語は２つの基本的なタイプのプリミティブ、つまりパラメータ描画処理（経路定義）とラスタ描画処理（ブリッティング）を含むカレント・ピクセル値を修正するための少数の描画プリミティブを提供する。さらに複雑なレンダリングは、複数の処理を合成することによって達成される。本発明のレンダリング・モデルの他の機能は、任意経路塗りつぶし、アルファ・ブレンディング、アンチ−エイリアシング、任意の二次元と色空間との変換、リニア・カラー・グラデーション、オプションのバイリニア・スケーリング付きビットマップ・レンダリング、領域ベース切り抜き、及び一般的な色変調（ブール切り抜きから空間色変調まで）を含む。描画モデルのコンポーネントはより低価格の装置の場合、除外することができる。例えば、一般的な色変調、アンチ−エイリアシング、または低出力のハードウェアで計算するには高価となるような他の処理をサポートしないためにコンポーネントを除外することができる。他方、モデルを完全な三次元ハードウェア・アクセラレータを使用するように構成することもできる。描画モデル態様１０２は、描画言語内でコマンドを表現するためにクライアントによって使用される描画ＡＰＩも定義する。

トランスポート態様１０４は、クライアント・プロセス内のような描画ＡＰＩに対する呼び出しによって表現されるところから、典型的にはサーバ・プロセス内のような実行されるところへの描画コマンドの伝送を可能にする。トランスポート態様１０４は非同期処理の問題に対処する。例えば、ディスプレイ・サーバによって制御される画面またはディスプレイが、どのようにすれば、さまざまなクライアント・プロセスから生じる描画及び更新コマンドを多重化し、ディスプレイ・サーバがその結果生成される画像が同一となるであろうと判定する場合に、状況に応じてコマンドを規則に反して実行することができるのかという問題に対処する。

ディスプレイ・サーバの複数のクライアントから同時に生成される描画コマンドは、通常、積極的に順序を決められていない。すなわち、それらは、通常、さまざまな順序で実行され、あたかもそれらがクライアントによって指定された順序で実行されたかのように同一の画像を取得することができる。例えば、好適な実施形態では、グラフィックス・サブシステム１００のトランスポート態様１０４及び描画モデル態様１０２は、Ａ、Ｂ、Ｃの順に順序が指定されている描画コマンド・グループＡ、Ｂ、Ｃを用いて、ＣのコマンドがＡによって描画される領域をオーバーレイし、ＢがＡとＣの何れかの影響を受けない領域に描画し、ＡはＣの前に実行されなければならないが、Ｂは任意の時点で描画することが許可されなければならないということを確実にしなければならない。これは、Ａ、Ｂ及びＣが異なるクライアント・プロセスから生成され、Ａに対応するクライアントが低速であるか、遮断されているか、または故障しており、Ｂに対応するクライアントが処理を続行する準備ができている状況においては非常に有効である。また、トランスポート態様１０４は、ディスプレイ・サーバが、ビューの区分された階層と通信できるようにする（各ビューが画面の特定の部分の部分的または完全なオーナーシップ（すなわち、ディスプレイのそれらの部分における実際のピクセル）を有している）。

図２は、モバイル機器のディスプレイ２０４を示す図であり、このディスプレイは要素２０４ａ、２０４ｂ、２０４ｃ、ディスプレイ・サーバ・プロセス２０２及びビュー階層２０６を有する。ディスプレイ・サーバ２０２プロセスは、画面２０４上に示されているユーザ・インタフェースのグラフィックスの特徴、すなわち、どの要素が表示され、それらがどのようにして表示されるのかを制御する。ディスプレイ・サーバ２０２は、ディスプレイ・サーバによって直接通信される唯一のビューであるという点で他のビューと区別されるルート・ビュー２０８と共に親―子関係に配列された多数のビューによって構成されたビュー・オブジェクト階層２０６と通信する。トランスポート態様１０４は、ディスプレイ・サーバ２０２が、場合によってはさまざまなクライアント・プロセスの全体で区分されるさまざまなビューから生じる描画コマンドを多重化し、それらを正しい順序で、またはディスプレイ・サーバが適切であると判断する順序で実行できるようにする。

描画コマンドは、クライアント・ビューから、配信ルートとして機能するオブジェクトを活用するグラフィック・レンダリングに対応するディスプレイ・サーバに転送される。レンダリング・ストリームとも呼ばれるこれらのオブジェクトは、トランスポート態様１０４の特徴である。図３Ａは、レンダリング・ストリーム・オブジェクト３０２及びコマンド３０４のサンプル・ストリームの図である。レンダリング・ストリーム３０２は、１つまたは複数のクライアント・プロセスの中の１つまたは複数の（ビュー等の）クライアントからサーバ・プロセスのディスプレイ・サーバにコマンド３０４を転送する。好適な実施形態では、レンダリング・ストリーム３０２は、ディスプレイ・サーバ２０２によってインスタンス化されるオブジェクトであり、コマンドをクライアント・ビュー内で表現される場所からディスプレイ・サーバ内で実行される場所へ転送する一方向の伝送路として機能する。必要な場合や、適切なセキュリティ処置が講じられていると仮定でき、あるいはシステム・コンポーネントが信頼できることが既知である場合には、クライアント・ビュー及びディスプレイ・サーバは、異なるプロセス内に存在し、または同じプロセス内で動作することができる。好適な実施形態では、レンダリング・ストリームの中で表現される描画コマンドは、プロセス境界を越えて転送するときに、効率をより高くするために、ディスプレイ・サーバへ転送される前に、バッファリングされる。ビューからディスプレイ・サーバへのアクティブなレンダリング・ストリームは、多数あり得る。

すべてのタイプの描画コマンドはレンダリング・ストリーム３０２に転送することができる。好適な実施形態では、例えば、ｍｏｖｅｔｏ、ｌｉｎｅｔｏ、ｃｌｏｓｅｐａｔｈ、ｆｉｌｌ＜ｃｏｌｏｒ＞、ｓｔｒｏｋｅ＜ｃｏｌｏｒ＞等の描画コマンドは、ポストスクリプト・コマンドに似ている。好適な実施形態では、レンダリング・ストリームは、コマンドまたはピクセル、変調データ等の他の任意のデータの一方向への伝送を容易にする。直接的な応答を通常は必要としないコマンドは、レンダリング・ストリームを使用した転送に最も適している。

描画モデル態様１０２は、レンダリング・ストリームとは無関係にその機能を実行できる。例えば、描画コマンドのあて先が、携帯端末の画面ではなくビットマップのようなローカルなものである場合、描画モデルは（トランスポート態様１０４の他の機能を使用するかもしれないが）レンダリング・ストリームを使用する必要はない。描画モデルがレンダリング・ストリームと無関係に動作する場合には、同一の描画モデルＡＰＩが使用される。しかしながら、状況によっては、コマンドはローカルな面に直接レンダリングされるか、あるいは他の何れかのディスプレイに転送されてもよい。

好適な実施形態では、クライアント・ビューによる描画は、ディスプレイ・サーバによって画面をリフレッシュするように命令されるときに発生する。これは、例えば、１つまたは複数の視認できるコンポーネントの外観の変更、若しくは階層を形成するビューの追加または削除を行う何らかのアクションまたは状態変化が発生した後のように、画面上のピクセルの特定の領域を担当するビューが無効である、または「汚れている」、またはなんらかの理由のために描画し直される必要があるときに行われる。アップデート・イベントに応じて、ビューは描画コマンドをディスプレイ・サーバに送信するので、サーバはこれらのコマンドに従ってそれらのピクセルを変化させることができる。好適な実施形態では、これが、ビューが画面に描画できる唯一の機構である。

ディスプレイ・サーバによる要求、及びそれによってクライアントにより行われる描画を含むイベントのこのシーケンスは、アップデート・サイクルと呼ばれる。ディスプレイ・サーバは、ルート・ビューにアップデート・イベントを送信することにより、このようなサイクルを開始する。ルート・ビューは、最終的な画像を作成するとともに、描画するためのビューを呼び出すため、必要に応じて、ビューの階層全体でイベントを区分する。レンダリング・ストリームは、サーバがクライアント・ビューの１つまたは複数のプロセスと異なるプロセスまたはデバイスで動作するとき、または互いに非同期で動作するとともに同一階層内で結合されたビューの複数のシステムがあるときに、クライアント・ビューからディスプレイ・サーバにレンダリング・コマンドを転送するためのアップデート・サイクルの間に使用される。これらのビューの結合されたシステムは、後述するように、ビュー・レイアウト・ルート・オブジェクトを使用することにより互いに非同期となる。

本発明のグラフィックス・サブシステムは、ビューの単一のシステム内の階層において先行する処理の描画に同期する各ビュー、または互いに非同期で動作するビューの複数のシステムによる並列の各ビューによって、アップデートの連続した実行を可能とする。これは部分的にはレンダリング・ストリームの分岐する能力によって可能になる。分岐は、支流または分岐したレンダリング・ストリームが作成され、元のまたは親のレンダリング・ストリームが、親ビューによって表現されるその後の描画コマンドを転送するために同期して使用され続ける一方で、子プロセスが選ぶ後のポイントにおいて（分岐動作を実行する親ビューに対して非同期で）描画するために子ビューに渡される手順である。

図３Ｂは、分岐したレンダリング・ストリームを示している。例えば、階層２０６の中の１つまたは複数のビューを含むクライアント・プロセスは、画面に描画すべきアプリケーション・ユーザ・インタフェースを有していてもよい。ディスプレイ・サーバは画面上に何が表示されるのかを最終的に制御し、クライアント・ビューは所望の画像を説明するのに必要な情報を有しているので、ディスプレイ・サーバはこれらのビューから描画コマンドを受信するためにレンダリング・システムを必要とする。好適な実施形態では、ディスプレイ・サーバはレンダリング・システムをインスタンス化し、それをアップデート・イベントとともにルート・ビュー２０８に送り、アップデート・サイクルを開始する。アプリケーションのイメージを描画するのに必要なコマンドは、Ａ、Ｂ及びＣという３つのシーケンスに分割され、各シーケンスはアプリケーションを備えるビューのサブセットによって作成される。シーケンスＡが作成され、独自のレンダリング・ストリーム３０６に入れられ、その後、レンダリング・ストリーム３０８はそれから分岐し、それらのコマンドを表現し、転送するのに使用されるシーケンスＢを作成するビューのサブセットに与えられる。これに続いて、シーケンスＣが作成され、独自のレンダリング・ストリーム３０６の中に入れられる。レンダリング・ストリーム３０８は、このようにして、グループＡ内のコマンドが（おそらくバッファリングされ、必ずしも転送されないことによって）表現された後であり、グループＣの最初のコマンドが表現される前のポイントで、レンダリング・ストリーム３０６から分岐する。レンダリング・ストリーム３０６で転送されるデータは、シーケンスＡからのコマンド、レンダリング・ストリーム３０８のためのトークン信号、及びシーケンスＣからのコマンドを含む。レンダリング・ストリーム３０８のコマンドはシーケンスＢからのものであり、このレンダリング・ストリームは、描画コマンドをディスプレイ・サーバに返すときにそれ自体を識別するためにトークン信号Ｂを使用する。

分岐を行う各行為は、ディスプレイ・サーバによる再順序付けの可能性を生じさせる。したがって、このシナリオでは、分岐は、レンダリング・ストリーム３０８のコマンドがレンダリング・ストリーム３０６内のコマンドと同時に、またはばらばらに実行できる可能性を生じさせる。実際の並列での実行は、複数のプロセッサまたはハードウェア・アクセラレータの使用を採用でき、あるいは単一のグラフィック・アクセラレータに送信されるコマンドを再順序付することにより、さらに高い効率に到達することができる。ディスプレイ・サーバはレンダリング・ストリーム３０６と３０８からこれらのコマンドを平行して受信し、コマンドは、表現された順序及びコマンド間の依存性に基づいて実行されるコマンドの実際の順序を決定する。

図４は、ディスプレイ・サーバのコンポーネントと、それらコンポーネントのビュー階層及び物理的な画面に対する関係を示す図である。ディスプレイ・サーバ２０２は画面を制御し、その画面に対する直接的なアクセスを有する唯一の存在である。グラフィックス・ドライバは２つのコンポーネント、すなわち、グラフィックス・ハードウェア・レジスタへの完全なアクセスを提供し、ホスト・オペレーティング・システムのＩ／Ｏ・サブシステムまたはカーネルに存在するドライバ４０２と、ディスプレイ・サーバ２０２に存在し、フレーム・バッファに対するメモリ−マッピングされたアクセス、及びグラフィックス・アクセラレーション・ハードウェアにより実現されるあらゆるグラフィックス機能へのアクセスを提供するグラフィックス・アクセラレント４０４に分割されている。ディスプレイ・サーバは、グラフィックス・アクセラレント、領域塗りつぶし及びピクセル処理に関する低レベル・レンダラ４０６（ミニ−ＧＬとしても知られている）、及びストローキング、レンダリング状態管理等の描画経路操作とメモリ・バッファ管理を提供する高レベル・レンダラ４０９から構成されている。

ディスプレイ・サーバ２０２は、１つのビュー、つまりルート・ビュー２０８だけの明確な情報を有している。ディスプレイ・サーバの観点から見ると、ルート・ビュー２０８は画面全体のイベント（入力イベントとアップデート・イベントを含む）の処理に関与する。単純なデバイスでは、ルート・ビューが事実上、唯一のビューであるかもしれない。ビューを１つだけ使用し、ビューの再順序付けをしない単一のプロセスがある場合、デザインの複雑さはディスプレイ・サーバとビュー階層の間の単純なコード経路と化し、貧弱なハードウェアに対して極めて効率的である。さらに高度なハードウェアとユーザ・インタフェースを有するデバイスでは、ルート・ビューは、処理されるアップデート・イベント及びインプット・イベントに対するその関連をビューの階層に区分する。

図５は、Ｉビュー５０４、Ｉビュー・ペアレント５０６、及びＩビュー・マネージャ５０８と呼ばれる３つの別々のインタフェースを有するベーシック・ビュー・オブジェクト５０２の図である。ビュー階層は、これらのインタフェースにアクセスする階層内の親と子の相互対話によって動作する。Ｉビュー５０４は、子ビュー５１０等の子として別のビューに追加するだけでなく、ビューのコア状態及び特性の操作も可能にする。Ｉビュー５０４は、親がその子に接続するためのインタフェースである。インプット、アップデート、レイアウト及び他のイベント・タイプは、子のＩビュー５０４インタフェースで呼び出しを行う各親ビューや、自身の子のＩビュー５０４インタフェースで代わりに（同期または非同期でのどちらかで）呼び出しを行うビュー等により、ディスプレイ・サーバからリーフ・ビューへ階層を下って伝搬される。Ｉビュー・ペアレント５０６インタフェースは、例えば親ビュー５１２等の親に子ビューが接続するためのインタフェースであり、例えば、レイアウトを実行するためにイベントまたは要求を無効にする等のように、階層を上ってイベントを伝搬するために使用できるインタフェースである。Ｉビュー・マネージャ５０８は、子ビューがその兄弟を操作するためにその親に使用する、またはコードのサード−パーティの部分が子をビューに追加または削除するために使用するインタフェースである。

ビュー階層のルーズな結合は、これらのインタフェースのいくつかを、他の特定のインタフェースへのアクセスを有する呼び出し元に対して非公開とすることによって部分的に実行される。例えば、（所望されるように各ビューにより無効にできる）ビューに対するデフォルトのセキュリティの方針は、最初にその親のためにＩビュー・ペアレント５０６インタフェースを与えられる子ビューが、それをＩビュー５０４インタフェースに変換できないということである。ビュー自体が、そのビューの描画、その親に対する参照等に適用すべき空間的な２Ｄ変換等の状態を記憶する。

アクティブ・オブジェクトのセット間でのピア−ツー−ピア信頼ネットワークを確立する機能的なセキュリティ・モデルが、図６及び図７に説明されている。セキュリティ・モデルは、システムの中の各オブジェクトが自身のセキュリティ方針を宣言できるようにし、信頼ネットワークが、各個別オブジェクトによる各方針のアプリケーションにより暗示的かつ動的に確立されるようにする。

機能セキュリティ・モデルは一連の単純な原則に基づいている。それらの原則の間で重要なのは、オブジェクトが、その義務を達成するためにリソース（または機能）Ａに対するアクセスだけを必要とする場合、例えばＢやＣのような任意の他の機能に対してではなく、Ａに対するアクセスだけが与えられるべきであるという最小権限の原則である。さらに、オブジェクトが機能Ｄが必要であると判断すると、この要求を許可し、付与する可能性がある別の機能を使用してＤを明示的に要求しなければならない。

多くのオブジェクト・モデル及びオブジェクト指向プログラミング言語は、それらを使用して定義されたオブジェクトが、それに作用する１つまたは複数の明確なインタフェースを公開または発行できるようにする。オブジェクトが発行する各インタフェースは、そこで呼び出すことができるオブジェクトまたはメソッドに送信できる一連のメッセージを定義する。大部分のインタフェース−ベースのオブジェクト・モデルでは、オブジェクトを使用することを希望するクライアントは、まず、オブジェクトを検査するとともに所望のインタフェースを要求することによってそのオブジェクトのインタフェースに対する参照を取得し、次に、そのインタフェースで、メソッドに呼び出しをさせ、またはメッセージを送信しなければならない。このようなインタフェースは、通常、オブジェクトに対するアクセスが付与される最小の制度である。

本発明の好適な実施形態では、既定のインタフェースのためのオブジェクトへの何らかの要求をそのオブジェクトの既知の明確なインタフェースを使用して行うことにより要求することによって、この要求の時点でどのインタフェースを使用して要求が行われたのかをオブジェクトに知らせることによって、各オブジェクトが、（他の要因の間で）どのインタフェースを使用して要求が行われたのかに基づいてどのインタフェースを発行するのかをカスタマイズできるようにすることによって、他のプロセスまたはデバイス内のオブジェクトによってインタフェースが参照または使用されるときに（言い換えると、メソッドの呼び出しまたはメッセージの通過がセキュリティ境界を超えてインタフェース上で行われたときに）、各オブジェクト・インタフェースを独自の機能的な安全な通信チャネルにマッピングすることによって、セキュリティ方針が定義され、実現される。

オブジェクト（「呼び出し元」オブジェクト）が他のオブジェクト（「呼び出し先」オブジェクト）のインタフェースＢに対する要求を出そうとするとき、その要求は、呼び出し元がなんらかの手段によってすでに取得した呼び出し先のインタフェースＡを使用して行われなければならない。このインタフェースＡは、例えば、オブジェクトを作成することによって作成された時点で呼び出し元に提供され、または他のオブジェクトとの対話で呼び出し元によって要求されることができる。呼び出し先オブジェクトは、Ｂに対する要求を受信し、このときに、要求がインタフェースＡを使用して行われたという情報を受ける。この情報と、呼び出し先が実際にインタフェースＢを使用するか否かと、呼び出し先が定義しようとする他の方針に基づいて、呼び出し先は呼び出し元に要求されたインタフェースＢを提供するか否かを決定することができる。

さらに、インタフェース上で行われる他の呼び出し、またはインタフェースを使用して交換されるメッセージ（すなわち、インタフェース検査要求を実行しないもの）は、それら自体で、呼び出されたオブジェクトまたは他のオブジェクトによって発行されるインタフェースを返すことができる。このようなそれぞれの対話（明確なインタフェース検査、またはあるオブジェクトによる他のオブジェクトとの第３のインタフェースに対する参照の共有のいずれか）では、ピア・オブジェクトのネットワーク中の信頼ネットワークは漸次的かつ動的に定義されている。この信頼ネットワークは、既定のオブジェクトにより動作が許容される範囲を定義する。例えば、呼び出し元オブジェクトが呼び出し先オブジェクトのインタフェースＡに対する参照を有する場合、呼び出し先がアクセスできる可能性があり、Ａを通して使用できるようにする可能性がある他のオブジェクトに対するそれらのインタフェースだけではなく、インタフェースＡを通してインタフェース要求を行うことによって取得できる呼び出し先上の他のあらゆるインタフェースの（したがってアクセスできると見なされなければならない）アクセスを、それは容易に取得することができるであろう。

各オブジェクトが、独自のインタフェースまたは他のオブジェクトのインタフェースをどのようにして、いつ、誰と共用するかについての決定は、特定のオブジェクトの実行次第であり、オブジェクトが検討するために選択する任意の数の要因に依存することがある。本発明の好適な実施形態では、呼び出し先のどのインタフェースが呼び出し元によってうまく要求可能であるのかを決定するために使用される主要なまたは唯一の要因は、単に要求がどのインタフェースを使用して行われたかということである。暗号シグナチャ、パスワード保護、及びユーザ検証等のような他の要因は、特定の状況的なニーズに基づいた特殊な規則を規定するためにいずれかの特定のオブジェクトによって使用されてよいが、これらのタイプの要因を使用するには、呼び出し元が必要な許可を有するかどうかを判定するための呼び出し元に対する特定のテストのために、中央権限がコンタクトを受ける必要がある。オブジェクトがそれらのインタフェースの１つで呼び出しを取得すると、そのオブジェクトは、まず、そのインタフェースに対する参照を有していることにより、呼び出し元オブジェクトがその呼び出しを行うための権限または許可を有していることを知る。任意の既定のオブジェクトにおける好適な実施形態では、他のインタフェースを要求するためにどの特定のインタフェースが使用されたのかという認識が、どのインタフェースがその要求に応じて公開されるのか、したがってどのようにして信頼ネットワークが構築されるのかを判断するために必要とされる情報のすべてである。したがって、オブジェクト・インタフェースへの呼び出し毎に、中央権限を備えた持続的な許可のチェックをする必要はない。

セキュリティ方針は、オブジェクトの機能性をサービスにアクセスするためにどのレベルまたはどのタイプの許可が必要とされるのかによってグループ化されるサービスのカテゴリを定義するインタフェースに区分することによって確立できる。例えば、オブジェクトは、最小限のアクセスを許可するインタフェースを有することができ、必ずしも完全に信頼できないオブジェクトにこの機能を与えることができ、すべての機能への完全なアクセスを許可する他のインタフェースを信頼できる他のオブジェクトに提供することができる。

図５に示すように、好適な実施形態の例では、グラフィック・ビュー・オブジェクトはＩビュー・マネージャ、Ｉビュー・ペアレント及びＩビュー・チャイルド３つのインタフェース、を有している。このようなビューの階層は、これらのインタフェースに互いにアクセスする階層内での親と子の対話によって動作する。

（所望されるように各ビュー・オブジェクトによって無効にできる）ビューのためのデフォルトのセキュリティ方針は、Ｉビュー・マネージャとＩビュー・ペアレント（オブジェクトによって実行される場合にも）の両方はＩビュー・インタフェースを使用して行われる任意の要求に対して公開されるが、Ｉビューは他の２つのインタフェースを使用して行われるあらゆる要求に対して非公開とされ（すなわち、Ｉビュー・マネージャまたはＩビュー・ペアレント・インタフェースのどちらかを使用したＩビュー・インタフェースに対する要求は失敗するであろう）、Ｉビュー・ペアレントはＩビュー・マネージャから非公開とされるということである。言い換えるとＩビュー・インタフェースを使用してビューに対するインタフェースを要求する呼び出し元はＩビュー・ペアレントとＩビュー・マネージャの両方を取得可能であり、Ｉビュー・ペアレントを使用してインタフェースを要求する呼び出し元はＩビュー・マネージャを取得することができ、Ｉビュー・マネージャを通じてインタフェースを要求する呼び出し元は追加のインタフェースに接続されない。

これらの各インタフェースは、それに対する参照を取得しているいずれかのオブジェクトに特定の許可のセットを付与し、このデフォルトのビューのセキュリティ方針は、ビューは本来その子を所有し、それらを所望のとおりに操作できるが、子は一般にその親を直接制御または操作することが可能であってはならないという仮定の元、設計されている。親はそれぞれの子へのＩビュー・インタフェースを有しており、したがって、子へのすべての既知のインタフェースにアクセスできるため、それぞれの子を完全に制御できる。しかし、子ビューは、階層に追加されるときに、その親へのＩビュー・ペアレント・インタフェースだけを与えられているため、例えば親の移動またはサイズ変更を許可するような、親へのＩビュー・インタフェースを取得することはできないか、またはその親の親に対する参照のような他の情報を取得できるようにすることができる。これにより、限られたＩビュー・ペアレント・インタフェースによって提供されるように、階層内でそれより上のビューに対する間接的な影響だけが子に与えられる。特定のニーズのある特定のオブジェクトの場合、親ビューは、Ｉビュー・ペアレント・インタフェースで行われる要求に応じて、その兄弟を操作する直接的なアクセスを獲得するための許可を事実上その子たちに付与または付与しないＩビュー・マネージャ・インタフェースを提供するか否かを決定できる。この許可はいくつかの状況で意味を持ち、他の状況では意味を持たない可能性があるため、各オブジェクトは適合するデフォルトの方針を無効にすることを選択することができる。

この方針に従うことにより、ビュー階層は、セキュリティを維持しながら、多くのプロセスを交差し、特殊なインタフェースを必要とせずに一定の方法によりメッセージを階層の上下に伝達することができるようになる。

図６は、本発明の好適な実施形態に従うインタフェース呼び出しに基づいたセキュリティ・アクセスを決定するオブジェクトのためのプロセスのフロー図である。ステップ６０２では、ターゲット・オブジェクトは、外部オブジェクトからそのインタフェースの１つで呼び出しを受ける。例えば、ターゲット・インタフェースが３つのインタフェースＡ、Ｂ及びＣを有していると、それぞれがターゲット・オブジェクトの機能にさまざまな程度のアクセスを付与する。インタフェースＡは最高のアクセスを付与し、インタフェースＣは最低を付与する。ステップ６０４では、ターゲット・オブジェクトは、独自のセキュリティ方針をチェックすることにより外部オブジェクトが他のインタフェースへのアクセスを許可されるかどうかを判定する。好適な実施形態では、ターゲット・オブジェクトはシステム内の全てのオブジェクトについてのセキュリティ・データを記憶している中央権限によってチェックをしない。外部オブジェクトがインタフェースＡで呼び出しをしている場合、ターゲット・オブジェクトは外部オブジェクトがインタフェースＢとＣにアクセスできると判定してよい。ステップ６０６では、ターゲット・オブジェクトは、ステップ６０４で判定したように、他のインタフェースへのアクセスを許可するために外部オブジェクトへのアクセスを付与する。

前述したのは、オブジェクトが何のプロセスに存在するかに関係なく、オブジェクトがどのように動作し、どのようにセキュリティ方針を定義するのかということである。例えば、呼び出し元オブジェクトと呼び出し先オブジェクトは同一または異なるプロセスに存在することができる。オブジェクトがプロセス全体で区分される方針またはパターンは、時間コードが記述されるとき、または時間セキュリティ方針が定義されるときには知られている必要はない。コードは、インタフェース検査方針により定義されるようなオブジェクト間の暗黙のセキュリティ方針が、システムにより確実に実行されると仮定して記載される。

しかしながら、前述されていることはセキュリティ方針を定義するための仕組みを提供するに過ぎない。メモリ保護及び言語−ベースのセキュリティを含む、このようなモデルを実行するさまざまなクラスのメソッドがある。好適な実施形態では、１つのこのようなメソッドの実行により、互いに保護されるべきオブジェクトを別々のプロセスに区分する。

本発明の好適な実施形態では、あるプロセス内のオブジェクトが（同じデバイスまたは別のデバイスの）異なるプロセス内のオブジェクトに対するインタフェースを取得すると、それらのプロセス間の安全なルートが確立され、そのインタフェース参照と関連付けられる。あるプロセスの特定のオブジェクトに対するそれぞれ単一のインタフェースでは、他のプロセスがそのインタフェースに対する参照を保持するオブジェクトを含む場合、単一の安全なルートがそのプロセスと他のプロセスとの間に存在する。この安全なルートは、メッセージとメソッド呼び出しを、あるプロセスから他のプロセスへ特定のインタフェースで転送するために、及びその呼び出し元に何らかの結果の値を返すために使用される。これは図７に示されている。したがって、プロセス７０４内のオブジェクト７０２がインタフェース７０６を有し、インタフェース７０６に対する参照がプロセス７１０内のオブジェクト７０８及びプロセス７１８内のオブジェクト７１２、７１４、７１６によって保持される場合、２つの安全なルート、すなわち、プロセス７０４とプロセス７１０の間の１つのルート７２０とプロセス７１８とプロセス７０４の間のもう一つのルート７２２が存在する。すべての呼び出しまたは同じ遠隔プロセスからの既定のオブジェクトに対する既定のインタフェースによる対話は、同じ安全なルートを通して送られる。

インタフェースが最初に特定の遠隔プロセスと共用されると必ず、これらの安全なルートが必要に応じてオン−デマンドで作成される。これらの安全なルートの使用によって、遠隔プロセスから要求が到達するときに、呼び出し元はインタフェースに対する参照を有していたために要求を行ったことを許可され、要求されたこのインタフェースが確実に特定できることが、オブジェクトに保証される。安全なルートは、図７の破線によって示されるように、プロセス境界が２つの通信しているオブジェクトの間に存在するときにだけ作成される。オブジェクトが同じプロセスの他のオブジェクトに対して呼び出し実行しようとする場合、そのオブジェクトは、安全なルートを使用することなく直接参照され、呼び出される。これにより、オブジェクト間でローカルな通信を行う場合、非常に高速になる。

（前記に詳述されるように）オブジェクト自体によってだけ確立されるセキュリティ方針はつねに有効である一方、オブジェクトの別個のプロセスへの区分（このようにして、安全なルートの使用を、それらの間でのメッセージ、データ及びインタフェース参照を交換するために強制的に使用させる）は、それらの方針を実行するための確実な方法である。目的は悪質なコードまたは欠陥のあるコードからオブジェクトを保護し、既存のオブジェクトをそれから保護することである。しかし、セキュリティ方針の実行は重大な性能とメモリ使用の影響をもたらすことがある。例えば、システム内の各オブジェクトに独自のプロセスが与えられる場合、結果として生じるオーバヘッドは容認できない。しかも、プロセスに基づき、ハードウェア・メモリ保護を使用して実現される実行方式では、これは、セキュリティ方針の厳格な実行がシステム内の全てのオブジェクトに対して必要とされる場合に、必要とされる内容である。したがって、このような実行が必要とみなされるようなときに、これらの方針の実行を適用することが望ましい。

セキュリティ方針の実行を必要でないとみなしてよいさまざまな理由がある。例えば、オブジェクトのネットワーク内で互いに対話しているコンポーネントのすべてが同じベンダによって作成されていた場合、それらが互いに悪意がある可能性が非常に低ければ、それらは互いに保護される必要はない。もう一つの例は、（極秘またはプライベートなデータを処理しない２つの正常なサード−パーティ・アプリケーションのような）同一のセキュリティ制約と許可を有する２つ以上の他の無関係のオブジェクトである。何れの場合でも、オブジェクトのセットを共通プロセスの中にクラスタ化すると、オブジェクトあたりに１つのプロセスを有するのに比較して必要とされるメモリ・オーバヘッドがかなり減少し、オブジェクト自体は、インタフェース間でメッセージを送るために安全なルートを作成することなく、非常に効率的に対話できるであろう。この区分は、例えば、それが同じベンダにより発行されるすべてのオブジェクトに拡張される包括的な信頼によって無効にされないときに、賢明に行われる。

本発明の好適な実施形態では、システムが、オブジェクトを作成した時点で、動的保護ドメインと呼ばれる異なるドメインにオブジェクトを割り当てることができるようにすることによって、セキュリティ・モデルが選択的に実行される。これは図８に示されている。ステップ８０２では、呼び出し元が、新しいオブジェクトのインスタンス化が必要であると判定する。ステップ８０４に示されているように、オブジェクトのインスタンス化または作成の要求を呼び出し元が行うオブジェクト・インスタンス化機構が提供される。要求は、インスタンス化されているオブジェクトが、システムが最も適切であると判定する動的保護ドメイン内で作成されることを規定する。ステップ８０６では、インスタンス化機構は、システム内でアクティブ・オブジェクトによって宣言されるセキュリティ制約及びセキュリティ要件、システム独自のグローバル・セキュリティ方針、及びシステムが積極的に作成するセキュリティ対性能と最適リソース活用のあらゆるトレードオフ等のような種々のセキュリティ要因に基づいて、オブジェクトを作成する。ステップ８０８では、オブジェクトは既存の動的保護ドメインまたは新規保護ドメインに位置され、プロセスによって好適な実施形態内で実現される。システムは、これが必要とみなされる場合、新規に作成されたオブジェクトをホストするために、新しい動的保護ドメインを作成してもよい。

このインスタンス化機構から返されるオブジェクトは、（例えば、新規に作成されたオブジェクトが、作成者がアクセスする許可を有さない極秘データへアクセスすることを必要とする場合に）遠隔保護ドメイン内で作成された遠隔オブジェクトに対するインタフェースへの参照であるかもしれないし、または（例えば、新規に作成されたオブジェクトが、作成者がそれは信頼すると宣言した発行者によって暗号で署名されている場合に）同一のプロセス内のローカル・オブジェクトであるかもしれない。作成者は前述されたインタフェース抽象化機構を使用しているため、結果として作成されたオブジェクトがローカルで作成されたのか、遠隔で作成されたのかに応じて、それは知る必要が無く、または異なるように動作する必要はない。これらの決定を下すために使用される制約、方針及び要件は実行するのに特殊であり、デバイスごとに異なる可能性がある。本発明の好適な実施形態では、動的保護ドメインはプロセスとして実現されている。

オブジェクトは、保護方針に基づいて保護ドメインにクラスタ化されるが、それらの方針に従っている間は、呼び出し元あるいは呼び出し元が指定する代理に可能な限り「近くに」配置される。言い換えると、オブジェクトをセキュリティ上の配慮に違反せずにそれと対話しているそれらのオブジェクトと同じプロセスで作成できる場合、それは作成される。

好適な実施形態では、ビュー階層内では、親ビューは、そのコンポーネントが行うこと、あるいはどのベンダがそれを提供したのかに関する事前の情報を有していなくても、「プラグ−イン」子ビュー・オブジェクトをインスタンス化してよい。親、親のプロセス、システム及び子のセキュリティ制約及び方針に基づいて、システムは、子が存在するための新しいプロセス（そのプロセスは最大の保護を提供するであろう）を作成するため、または新しい子を、子のセキュリティ・ニーズに適合し、プライベート情報（その情報は、完全に新しいプロセスに、単一の子ビュー・オブジェクトだけに役立つことを要求しないが、親とシステムに優れたレベルのセキュリティとロバスト性を提供するであろう）を保持するオブジェクトを含まない他の既存のプロセスの中に位置させるために、子のコンポーネントを親のプロセス（そのプロセスは最大の性能を許可するであろう）中にロードするか否かを決定できる。これにより、このような保護に対するニーズを表現するそれらのコンポーネント間で保護を維持することが許可されている間は、ビュー階層は、例えば、任意の１つのコンポーネントによって知られている階層構成なしに、サード−パーティ・コードの強調する部分の外から動的に構築されることができる。

前述した本発明の一実施形態はハードウェア・デバイスまたはシステムに関しているので、コンピュータ・デバイスに関連付けられる基本的なコンポーネントを以下に説明する。

図９及び関連する説明は、本発明が実現されてよい適切なコンピュータ環境の簡潔で一般的な説明を提供することを目的とする。必要とされてはいないが、本発明を、少なくとも部分的には、パーソナル・コンピュータまたは携帯コンピュータ・デバイスで実行されるプログラム・モジュール等のコンピュータで実行可能な説明の一般的な背景で説明した。一般的に、プログラム・モジュールは、特定のタスクを実行するか、あるいは特定の抽象的なデータ・タイプを実現するルーチン・プログラム、オブジェクト、コンポーネント、データ構造等を含む。さらに、当業者は、本発明が携帯端末、マルチプロセッサ・システム、マイクロプロセッサ−ベースのまたはプログラム制御可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ、通信装置、携帯電話、タブレット等を含む他のコンピュータ・システム構成で実施されてよいことを理解するであろう。本発明は、タスクが通信ネットワークを介してリンクされている遠隔処理装置によって実行される分散型コンピュータ環境でも実施されてよい。分散型コンピュータ環境では、プログラム・モジュールはローカル・メモリ記憶装置と遠隔メモリ記憶装置の両方に位置してよい。

図９を参照すると、本発明を実現するための例示的なシステムは、中央演算処理装置（ＣＰＵ）１２０、システム・メモリ１３０、及びシステム・メモリ１３０を含む種々のシステム・コンポーネントをＣＰＵ１２０に接続するシステム・バス１１０を含む汎用コンピュータ・デバイス９を有している。システム・バス１１０は、メモリ・バスまたはメモリ・コントローラ、周辺機器のバス、及び種々のバス・アーキテクチャのいずれかを使用するローカル・バスを含む複数のタイプのバス構造のいずれかであってよい。システム・メモリ１３０は、読み取り専用メモリ（ＲＯＭ）１４０とランダム・アクセス・メモリ（ＲＡＭ）１５０を有している。基本入出力システム（ＢＩＯＳ）は、起動中等のように、パーソナル・コンピュータ９の要素間で情報を転送するのを補助する基本的なルーチンを有しており、ＲＯＭ１４０に記憶されている。コンピュータ・デバイス９は、データを読み取り、書き込むためのハードディスク・ドライブ１６２のような記憶装置をさらに有している。この記憶装置は、リムーバブル磁気ディスクに対して読み取り、または書き込みを行うための磁気ディスク・ドライブ、若しくはＣＤ ＲＯＭまたは他の光学式メディア等のリムーバブル光ディスクに対して読み取り、または書き込みを行うための光ディスク・ドライブであってよい。ドライブ及び関連するコンピュータで読取可能なメディアは、コンピュータ読取可能命令、データ構造、プログラム・モジュール及びコンピュータ・デバイス９のための他のデータの不揮発性の記憶を提供する。
ここに説明されている例示的な実施形態はハード・ディスク、リムーバブル磁気ディスク、及びリムーバブル光ディスクを利用しているが、磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）及び読み取り専用メモリ（ＲＯＭ）等のようなコンピュータによってアクセス可能なデータを記憶できる他のタイプのコンピュータ読取可能メディアも、例示的な動作環境で使用してもよいことが当業者によって理解されるべきである。

図９は、バス１１０と通信する入力装置１６０と出力装置１７０も示している。入力装置１６０はマルチ−メディア・データまたは他のデータのためのソースとして動作し、出力装置１７０はディスプレイ、スピーカ、またはマルチ−メディア・データのための目標としてのコンポーネントの組み合わせを備える。装置１７０は、ビデオ・カムコーダのようなソース・デバイス１６０からのデータを受信及び記憶する記録装置に相等してもよい。通信インタフェース１８０は、コンピュータ・デバイス９との通信手段を提供してもよい。

理解できるように、ハードウェア・コンポーネントの前記説明は実例として示されるにすぎない。例えば、基本的なコンポーネントは、デスクトップ・コンピュータと携帯型または持ち運び可能なコンピュータ・デバイスとの間で異なる場合がある。当業者は、本発明が実施される特定のハードウェア・デバイス（またはネットワーク化されたコンピュータ・デバイスのグループ）に基づいて基本的なハードウェア・コンポーネントを修正、調整する方法を理解するであろう。

本発明の範囲内の実施形態は、コンピュータで実行可能な命令またはそこに記憶されているデータ構造を持ち運び、または記憶するためのコンピュータ読取可能メディアを含んでいてもよい。このようなコンピュータ読取可能メディアは、汎用または特殊目的用コンピュータによってアクセス可能な任意の使用可能なメディアである場合がある。制限ではなく一例として、このようなコンピュータ読取可能メディアは、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ等の光記憶ディスク、磁気記憶ディスク等の磁気記憶装置、またはコンピュータで実行可能な命令またはデータ構造の形で所望のプログラム・コード手段を持ち運び、または記憶するために使用できるあらゆる他の媒体を含むことができる。ネットワークまたは他の通信接続（有線、無線、またはそれらの組み合わせのいずれか）によって情報がコンピュータに転送または提供されると、コンピュータはコンピュータ読取可能媒体として接続を適切に表示する。したがって、厳密には、このような接続はコンピュータ読取可能媒体ということができる。また、前記の組み合わせも、コンピュータ読取可能媒体の範囲に含まれるべきである。

コンピュータ実行可能命令は、例えば、汎用コンピュータ、特殊目的用コンピュータ、または特殊目的処理装置に所定の機能または機能のグループを実行させる命令及びデータを含んでいる。コンピュータ実行可能命令は、独立した環境またはネットワーク環境でコンピュータによって実行されるプログラム・モジュールも含んでいる。一般的には、プログラム・モジュールは、特定のタスクを実行し、または特定の理論的データ・タイプを実現する、ルーチン、プログラム、オブジェクト、コンポーネント及びデータ構造等を含んでいる。コンピュータ実行可能な命令、関連付けられたデータ構造、及びプログラム・モジュールは、ここに開示されている方法のステップを実行するためのプログラム・コード手段の例を意味する。このような実行可能な命令または関連付けられたデータ構造の特定のシーケンスは、このようなステップで説明された機能を実行するための対応する動作の例を意味する。

当業者は、本発明の他の実施形態が、パーソナル・コンピュータ、携帯端末、マルチ−プロセッサ・システム、マイクロプロセッサ−ベースまたはプログラム制御可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ等を含む、多くのタイプのコンピュータ・システム構成を用いるネットワーク・コンピュータ環境で実施されてよいことを理解するであろう。実施形態は、通信ネットワークを介してリンクされたローカル処理装置及び遠隔処理装置によって実行されるタスクが実行される分散型コンピュータ環境で実行されてもよい。分散型コンピューティング環境では、プログラム・モジュールはローカルなメモリ記憶装置及び遠隔メモリ記憶装置の両方に配置されてよい。

前記説明は特定の詳細を含んでよいが、それらは決して請求項を制限すると解釈されてはならない。説明されている本発明の実施形態の他の構成は、本発明の範囲の一部である。例えば、オブジェクトは、機能が一致するオブジェクト・モデルのインタフェース以外の特徴を使用してよい。他の例では、保護ドメインは、メモリ保護や言語ベースのセキュリティのようなプロセス以外のシステムのコンポーネントにより定義することができる。したがって、添付の請求項及びそれらの法律上の同等の物は、示されている特定の例ではなく、本発明だけを定義している。

本発明の好適な実施形態による、モバイル機器または携帯端末用のオペレーティング・システムのグラフィックス・サブシステム・コンポーネントの２つの態様を示す図である。 本発明の好適な実施形態による、ユーザ・インタフェース要素、ディスプレイ・サーバ・プロセス及びビュー階層を有するモバイル機器のディスプレイの図である。 レンダリング・ストリーム・オブジェクト、コマンドのサンプル・ストリーム及びレンダリング・ストリーム分岐の図である。 レンダリング・ストリーム・オブジェクト、コマンドのサンプル・ストリーム及びレンダリング・ストリーム分岐の図である。 本発明の好適な実施形態による、ディスプレイ・サーバ・コンポーネントと、それらのビュー階層と物理的な画面に対する関係の図である。 本発明の好適な実施形態に従って他のビューと通信するためのビュー・オブジェクト及び選択された種々のインタフェースの図である。 本発明の好適な実施形態による、インタフェースへ機能をマッピングするプロセスのフロー図である。 プロセス内のオブジェクトと動的保護ドメインを実現するプロセス間のルートを示す図である。 動的保護ドメイン内で新たなオブジェクトをインスタンス化するプロセスのフロー図である。 本発明によるコンピュータ・デバイスの基本的なコンポーネントのブロック図である。

Claims (31)

1. オペレーティング・システム内のオブジェクトに対するアクセスを制御する方法であって：
   外部オブジェクトからターゲット・オブジェクトの第１インタフェースへの呼び出しを受信する工程と；
   ターゲット・オブジェクトにおいて、第１インタフェースへの呼び出しに基づいて、外部オブジェクトがターゲット・オブジェクトの他のインタフェースにアクセスできるか否かを判定する工程と；
   判定に従って他のインタフェースへのアクセスを許可する工程を有する方法。
2. 外部オブジェクトがターゲット・オブジェクトの他のインタフェースにアクセスできるか否かを判定する工程が、ターゲット・オブジェクト内に含まれるセキュリティ方針を調べる工程をさらに有することを特徴とする請求項１に記載の方法。
3. セキュリティ方針がターゲット・オブジェクト内に完全に含まれていることを特徴とする請求項２に記載の方法。
4. 外部オブジェクトとターゲット・オブジェクトが同じプロセスで動作するか否かを判定する工程をさらに有する請求項１に記載の方法。
5. 外部オブジェクトがターゲット・オブジェクトの他のインタフェースにアクセスできるか否かを判定する工程が；
   第１インタフェースが外部オブジェクトによって要求されているときに、アクセスできるターゲット・オブジェクトの他のインタフェースを特定する工程をさらに有することを特徴とする請求項１に記載の方法。
6. ターゲット・オブジェクトの第１プロセスを決定する工程をさらに有する請求項１に記載の方法。
7. 外部オブジェクトの第２プロセスを決定する工程をさらに有する請求項６に記載の方法。
8. ターゲット・オブジェクトと外部オブジェクトの間の相互プロセス通信を実行する工程をさらに有する請求項７に記載の方法。
9. ターゲット・オブジェクトの各インタフェースにチャネルを確保する工程をさらに有する請求項１に記載の方法。
10. 外部オブジェクトがターゲット・オブジェクトの他のインタフェースにアクセスできるか否かを判定する工程が、ターゲット・オブジェクト内のアクセスの制約を分析する工程をさらに有することを特徴とする請求項１に記載の方法。
11. ターゲット・オブジェクト内に記憶されているインタフェース・アクセス・データを分析する工程をさらに有する請求項１に記載の方法。
12. ターゲット・オブジェクトと外部オブジェクトが同じ保護ドメイン内にあるか否かを判定する工程をさらに有する請求項１に記載の方法。
13. 保護ドメインがプロセスであることを特徴とする請求項１２に記載の方法。
14. ターゲット・オブジェクトが独自のセキュリティ方針を設定することを特徴とする請求項１に記載の方法。
15. 外部オブジェクトが他のインタフェースにアクセスできるか否かを判定する工程が、
    外部オブジェクトの機能を決定する工程をさらに有することを特徴とする請求項１に記載の方法。
16. 外部オブジェクトの機能をターゲット・オブジェクトのインタフェースにマッピングする工程をさらに有する請求項１４に記載の方法。
17. ターゲット・オブジェクトと外部オブジェクトが同じ方法によって作成されることを特徴とする請求項１に記載の方法。
18. ターゲット・オブジェクトと外部オブジェクトがビュー階層内のビューであることを特徴とする請求項１に記載の方法。
19. ビューが親呼び出しインタフェース、子呼び出しインタフェース、及び子管理インタフェースを有することを特徴とする請求項１８に記載の方法。
20. オペレーティング・システム内のオブジェクトに対するアクセスを制御するシステムであって：
    外部オブジェクトからターゲット・オブジェクトの第１インタフェースへの呼び出しを受信するように構成されたモジュールと；
    第１インタフェースで受信される呼び出しに基づいて、外部オブジェクトがターゲット・オブジェクトの他のインタフェースにアクセスできるか否かを判定するように構成されたモジュールと；
    判定に従って他のインタフェースへのアクセスを許可するように構成されたモジュールを有するシステム。
21. オペレーティング・システム内のオブジェクトに対するアクセスを制御するシステムであって：
    外部オブジェクトからターゲット・オブジェクトの第１インタフェースへの呼び出しを受信する手段と；
    ターゲット・オブジェクトにおいて、第１インタフェースへの呼び出しに基づいて、外部オブジェクトがターゲット・オブジェクトの他のインタフェースにアクセスできるか否かを判定する手段と；
    判定に従って他のインタフェースへのアクセスを許可する手段を有するシステム。
22. コンピュータ装置を制御して、オペレーティング・システム内のオブジェクトへのアクセスを制御するための命令を記憶しているコンピュータ読取可能媒体であって、その命令が：
    外部オブジェクトからターゲット・オブジェクトの第１インタフェースへの呼び出しを受信する工程と；
    ターゲット・オブジェクトにおいて、第１インタフェースへの呼び出しに基づいて、外部オブジェクトがターゲット・オブジェクトの他のインタフェースにアクセスできるか否かを判定する工程と；
    判定に従って他のインタフェースへのアクセスを許可する工程を有することを特徴とするコンピュータ読取り可能媒体。
23. コンピュータ・デバイス・オペレーティング・システム内でオブジェクトを保護する方法であって：
    第１オブジェクトの１つまたは複数のアクセスの制約を決定する工程と；
    第１オブジェクトの１つまたは複数のアクセスの制約に対応するセキュリティ・プロファイルを有する保護ドメインを特定する工程と；
    第１オブジェクトを保護ドメイン内に配置する工程を有する方法。
24. 第１オブジェクトと第２オブジェクトを同じ方法によって作成する工程をさらに有する請求項２３に記載の方法。
25. 第１オブジェクトと第２オブジェクトが、２以上の保護ドメイン全体で透過的に通信できることを特徴とする請求項２４に記載の方法。
26. 保護ドメインがプロセスであることを特徴とする請求項２３に記載の方法。
27. オブジェクトのためのセキュリティ制約が、オブジェクト内に含まれているオブジェクトからオブジェクトへのセキュリティ・モデルを作成する工程をさらに有する請求項２３に記載の方法。
28. 保護ドメインを特定する工程が、第１オブジェクトと局所的に関連する保護ドメインを特定しようとする工程をさらに有することを特徴とする請求項２３に記載の方法。
29. オペレーティング・システムのセキュリティ要件に基づいてプロセスを作成する工程をさらに有する請求項２３に記載の方法。
30. オブジェクトのセキュリティ方針に基づいて、プロセス内のオブジェクトをクラスタ化する工程をさらに有する請求項２９に記載の方法。
31. コンピュータ・デバイス・オペレーティング・システム内でオブジェクトを保護するシステムであって：
    第１オブジェクトの１つまたは複数のアクセスの制約を決定する手段と；
    第１オブジェクトの１つまたは複数のアクセスの制約に対応するセキュリティ・プロファイルを有する保護ドメインを特定する手段と；
    第１オブジェクトを保護ドメイン内に配置する手段を有するシステム。

Images