JP2012507801A - オペレーティングシステムに関する柔軟な階層的セッティングレジストリ - Google Patents

Abstract

様々な実施形態は、方法及びシステムがアプリケーション開発者によって定義可能なアクセス保護を備えた分散されたセッティングレジストリを提供することを含む。分散されたセッティングレジストリは、レジストリツリーに異なるノードを接続するためのダイナミックアビリティ及びカスタマイズ可能な特権をともなった異なる技術を横断実施されるかもしれない。セッティングレジストリは、レジストリを呼び出しているアプリケーションが、セッティングデータがどこにまたはどのように格納されるかに関係している必要がないように、レジストリインターフェース下に存在するかもしれない。レジストリのツリーの各ノードは、それ自身の特権要求及びストレージ技術を定義するかもしれない。ノードは“ネイティブ”（すなわち、セッティングレジストリシステムソフトウェア内に完全にサポートされる。）または“非ネイティブ”（すなわち、特定のアプリケーションに関する開発者によって定義される。）であるかもしれない。

Description

関連出願

この出願は、２００８年１０月２９日に出願された“オペレーティングシステムに関する柔軟な階層的セッティングレジスタ”と題した米国仮特許出願番号６１/１０９,３８０の優先権の利益を請求する。

この発明はコンピュータオペレーティングシステムに一般的に関連し、モバイルコンピューティングデバイスに関するオペレーティングシステムで実行されるレジストリシステムにさらに特に関連する。

レジストリは、オペレーティングシステム内でオペレートするソフトウェアに関するオプション及びセッティングを格納するためのディレクトリである。例えば、マイクロソフトによるウィンドウズ（登録商標）オペレーティングシステムは、ユーザのプリファレンス及びセッティングを格納することと同様に、ハードウェア、オペレーティングシステムソフトウェア、及びアプリケーションソフトウェアによって要求される情報及びセッティングを含むウィンドウズレジストリとして知られるディレクトリファイルを含む。レジストリファイルは単一のファイル構造に全てのプログラム及びハードウェアセッティング及び一定の値を置くようにサーブする。

ウィンドウズレジストリは２つの基本的な要素を含む。すなわち、キー及び値である。レジストリキーはファイルフォルダに類似している。値に加えて、各々のキーはさらにサブキーを含むかもしれないサブキーを含むことができる。キーは、階層のレベルを示すバックスラッシュを使用しているウィンドウズパスネームに類似する構文で参照される。レジストリ値はキー内部に格納されるネームまたはデータのペアである。値はキーと分離して参照される。ウィンドウズレジストリで、値は文字列、２値、符号なし３２ビット整数、ユニコード値、多数の文字列、（ウィンドウズ２０００及びそれ以降の）６４ビット整数値及びリストであることができる。ウィンドウズレジストリはデータベースタイプファンクションを提供しているデータベースとして構成される。

この中に含まれ、この明細書の一部を構成する添付している図は、発明の例示の実施形態を例証し、上で与えられた一般的な記述及び以下で与えられた詳細な記述と共に、発明の特徴を説明することをサーブする。
図１は、実施形態内のセッティングオブジェクトを実行するための例のコードブロックを提供する。 図２は、実施形態内のネイティブセッティングオブジェクトを実行するためのさらなる例のコードブロックを提供する。 図３は、２つのアプリケーションによるネイティブセッティングオブジェクトのためのプロセスコールを例証しているプロセスコール図である。 図４は、実施形態内の非ネイティブセッティングオブジェクトを実行するための例のコードブロックを提供する。 図５は、２つのアプリケーションによる非ネイティブセッティングオブジェクトに関するプロセスコールを例証しているプロセスコール図である。 図６は、実施形態内のセッティングオブジェクトコールの処理を例証している処理フロー図である。 図７は、様々な実施形態を実行することに適した携帯ハンドセットのコンポーネントブロック図である。

様々な形態が添付している図に関して詳細に記述されるだろう。可能な限り、同じ参照番号が同じ部分または同様の部分を参照して図の初めから終わりまで使用されるだろう。特定の例及び実施に作られた参照は、例示の目的のためであり、発明または請求項の範囲を限定することを意図しない。

この記述の中で、用語“例の”及び“例示の”は、“例、事例、または実例としてサーブしていること”を意味するために使用される。“例の”または“例示の”としてこの中に記述される任意の実施は、他の実施をよりも望ましい、または有利として必ずしも解釈されない。

この中で使用されるように、用語“携帯ハンドセット”及び“携帯デバイス”は、様々な携帯電話、個人用デジタル補助装置(PDA’s)、パームトップコンピュータ、ワイヤレスモデムを備えたノートパソコン、ワイヤレス電子メール受信器（例えば、ブラックベリー（登録商標）、トレオ（登録商標）デバイス）、携帯電話、及びマルチメディアインターネット可能な携帯電話（例えば、ブラックベリーストーム（登録商標））、及び類似の個人用電子デバイス、の任意の１つを参照し、互換的に使用される。携帯デバイスは、図７に関してさらに十分に以下に記述されるようなプログラム可能なプロセッサ及びメモリを含むかもしれない。

現代の携帯デバイスは、膨大なデジタル情報量を格納することができ、ユーザはエンターテインメントアプリケーションとして彼らの携帯デバイスを典型的に使用する。その結果、携帯デバイスに関して開発されるアプリケーションの複雑性及び精巧化が、パーソナルコンピュータとして開発されるものと今対抗する。様々な実施形態が、定義できるアクセス保護を備えた柔軟なセッティングレジストリを提供している携帯デバイスアプリケーションの開発を容易にする。

様々な実施形態は、アプリケーション開発者によって定義できるアクセス保護を備えた分散されたセッティングレジストリを提供する。分散されたセッティングレジストリはカスタマイズ可能な特権を備えた異なる技術及び異なるノードをレジストリツリーに接続する動的な能力を横断して提供される。レジストリを実施しているアプリケーションが、セッティング値がどこにまたはどのように格納されるかに関することである必要がないように、セッティングレジストリはレジストリインターフェース下に存在するかもしれない。レジストリのツリーの各々のノードはそれ自身の特権要求及びストレージ技術を定義するかもしれない。ノードは、“ネイティブ”（すなわち、完全にセッティングレジストリシステムソフトウェア内にサポートされる）または“非ネイティブ”（すなわち、特定のアプリケーションに関して開発者によって定義される）であるかもしれない。セッティングオブジェクトは、.mifファイルとしてこの中で参照されるモジュール情報ファイル（mif）を介してセッティングレジストリにそれ自身を登録する。

よく知られているように、携帯デバイスに内在するアプリケーションは２つのファイルによって定義されるかもしれない。すなわち、拡張子.mifを持っているモジュール情報ファイル及び拡張子.modを持っているモジュールファイルである。もし、アプリケーションがセッティング情報を要求するならば、このようなセッティング値は、アプリケーションが開始されるまたはオペレートしている時、アプリケーションによるアクセスのためにセッティングレジストリ内に格納されるかもしれない。例えば、セッティングは.iniファイル拡張子を備えた初期設定ファイルに格納されるかもしれない。このような実施で、開発者はコンパイルされたアプリケーションコードを含んでいる.modファイル、（セッティングレジストリ情報を含んでいる）コンパイルされたモジュール情報を含んでいる.mifファイル、及びセッティング値を含んでいる.iniファイルを提供しなければならない。

様々な実施形態は、ISettingsとしてこの中で時折参照されるアプリケーション・プログラミング・インターフェイス(API)、及び文字列で指定されたキーを得ること又はセッティングすることを可能にし、階層的キー構造をサポートし、キーのツリーによって列挙することを許可し、値が変化する時通知をサポートする“SettingsReg”としてこの中に時折参照されるAPIのセッティングレジストリ実装を提供する。データは、リード、ライト及び列挙オペレーションを簡単にするテキストファイルとしてセッティングレジストリに格納されるかもしれない。SettingsRegの具体化は、２つのタイプの機能、パブリックセッティング及びプライベートセッティングを提供する。パブリックセッティングは、アプリケーション及びコンポーネントがグローバルセッティングレジストリを介してシステムのレストに利用可能にすることを望むセッティングファイルである。パブリックセッティングは、オペレーションシステム内でオペレートしている全てのアプリケーションに一般的に利用可能である。プライベートセッティングは選択的に特定されるアプリケーションまたはアプリケーションのタイプまたは分類に利用可能なセッティングファイルである。

様々な実施形態のセッティングレジストリは、URIに基づいたセッティングツリー、例えば“/path/to/a/setting.”を利用する。ウィンドウズレジストリに関する場合のように大きくて、単一のレジストリの代わりに、様々な実施形態のセッティングレジストリはトップレベルレジストリに簡単に“プラグインする”任意の数のモジュールによって提供されるいくつかのより小さなレジストリから構成される。ここで、各々のサブレジストリはツリーの特定の部分を“所有する”。この構造は、各々のサブレジストリがカスタマイズ可能な方法でそれ自身のデータストアを管理する時、セッティングレジストリが維持することが容易であることを可能にする。構造は、新しいサブレジストリを追加することが簡単であるように、様々なタイプのデータ記録装置がスケーラブル可能であることも許可する。構造は、各々のサブレジストリがそれ自身の特権コンベンションを管理することができるように定義可能なセキュリティも提供する。さらに、構造はappsまたはドメインを横断して変更通知をサポートする。

セッティングレジストリは、ネイティブ及び非ネイティブデータストアの概念を持つ。ネイティブストアはISettingレジストリが組み込みのサポートを持つことに関するそれらである。例えば、実施形態でセッティングレジストリは、.iniファイルにあり、エクステンディド・ファイルシステム（EFS）に持続されるセッティングである.iniファイルに基づいたデータストア、及びヒープメモリにあり、電源（すなわち、システムオンまたはオフ）サイクルを横断して持続されないヒープに基づいたデータストア、をサポートする。非ネイティブストアはネイティブセッティングオブジェクトデータストアによってサポートされるものと異なるファイルタイプまたはストレージ技術を使用するスタンドアロン実装である。開発者は、それらのオブジェクトに関する特権の実行を含んでいる非ネイティブセッティングオブジェクトを自由に定義することができる。

ネイティブストアで、コンポーネントはそれらの.mifファイルのツリーの特定のノードの所有権を要求し、そこで、それらはそれらのストアについて、いくつかの情報をレジストリにも提供するだろう。（例えば、.iniファイルに基づいたストアに関して、ストアタイプ、この場合は.iniに基づいたストアタイプ、及び.iniファイルへのEFSパスを特定するだろう）。レジストリはデータストアの全てのオペレーションを管理するだろうし（.iniファイルの場合、レジストリはファイルを常にリードまたはライトする唯一のコンポーネントである）、だからコンポーネントが特権をそれらのストアへのアクセスを許可または拒否するために定義するかもしれない、セッティングアクセス制御リスト（ACL）のような、別個のメカニズムがある。セッティングACL（アクセス制御リスト）はファイルシステム（FS）ACLと同様に正確に作動する。

ネイティブストアで、ストアを定義または管理するためにライトされるコードはない。ネイティブストアで、レジストリ処理はストアを作り、相互に作用する能力がある。開発者は、.mifフィルのストアを簡単に登録することができ、ストレージ媒体（例えば、.iniファイル）を提供することができる。つまり、モジュールは.mifファイルを介したセッティングレジストリにそれ自身を“登録”する。ストアを使用しているアプリケーションは、データにアクセスするために定義されたキーとともにISettingsインターフェイスを使用することができる（アプリケーションはそれをするために特権を持つと想定している）。個々のネイティブセッティングオブジェクトへの全てのアクセスは、シングルトンサービス１８（図３を参照）によって実行される。つまり、全てのネイティブセッティングオブジェクト２０にアクセスする同じサービスは、情報を得るためにコールされるAPI１２、１６及びアプリケーション１０、１４からプロセス境界によって分離される処理の同じサービスによってアクセスされる。

セッティングデータはセッティングオブジェクトとしてストアされる。セッティングストアファクトリとしてこの中で参照されるオブジェクトジェネレーティングAPIは、特定のストレージ技術周辺のネイティブセッティングレジストリオブジェクトを作るために使用されるかもしれない。例えば、第１の実施形態で、２つのセッティングストアファクトリが提供される。iniファイルセッティングオブジェクトを生成するためのものと、ヒープストレージセッティングオブジェクトを生成するものである。よく知られているように、.iniファイルはプログラムが開始している時にリードされる設定データをストアするための、アプリケーションによって使用される初期設定ファイルであり、ヒープストレージは携帯デバイスがパワーダウンされるたびに削除される一時的なメモリにストアされるファイルである。

セッティングストアファクトリは、アクセスが指定されたアプリケーションまたはアプリケーションのタイプまたは集合に限定された状態で、ストアされる情報は限定されたアクセス、すなわち“プライベート”である、に与えられる時、特に使用されるかもしれない。この中で使用されるように、用語“パブリック”は、アクセス特権に関わらずセッティングレジストリで利用可能である任意のセッティングに言及し、及び用語“プライベート”はファクトリを使用しているアプリケーションで作られるオブジェクトまたはセッティングに言及する。この関連で、“プライベート”セッティングは単一のアプリケーションとの関連で作られるオブジェクトの例であり、そのアプリケーションに“プライベート”な例、を参照する。それで、もし２つのアプリケーションの両方がセッティング.ini ファクトリを使用している同じ.iniファイルを開くならば、各々のアプリケーションはここでそのオブジェクトのプライベート例を持つ（この場合、ファイルへのアクセスを持つアプリケーションはセッティングレジストリ、例えばファイルシステムACL以外のいくつかのメカニズムによって定義されるかもしれない）。１つのアプリケーションが変更を加える時、変更が生じる他のアプリケーションに通知することの方法はないかもしれない。一方、もし、その.iniファイルが、“パブリック”にする、セッティングレジストリを登録されたならば、両方のアプリケーションはセッティングレジストリを通過することによって、その.iniファイルのデータにアクセスできるだろうし、１つのアプリケーションが変更を加える時、他のアプリケーションが通知されることができるだろう。従って、セッティングオブジェクトの３つの分類があるかもしれない。全てに利用可能なパブリック、制限されたアクセスのパブリック、及びプライベート。

図１は、プログラム“foo”に関する.iniファイルを実行するために使用されることができる例のコードのサンプルを例証する。この例で、ツリーのfoo.iniであり、及びファイルfs:/~0xdeadbeef/foo.iniにストアされる情報は、“name”ノード（コード２を参照）にストアされる名前“Mike”である。このfoo.iniセッティングファイルを生成するためのセッティングストアファクトリを実行するために使用されるスクリプトは、コードブロック４に例証される。“ISetingsStoreFactory_Create”で始まる行で、開発者は使用されるノード名を特定する（例では“foo.ini”）。

ネイティブセッティングオブジェクトの生成の間、開発者は、上述されたように、オブジェクトがプライベートかパブリックであるかどうかを指定もすることができる。もし、開発者がオブジェクトをプライベートとして指定したならば、開発者はオブジェクトのアクセス特権、すなわちセッティングオブジェクトにアクセスするかもしれないアプリケーションタイプまたは特定のアプリケーションを指定することもできるかもしれない。図２に例証された例のコードで、コード“ISettings_Get(pSettings,‘Genera/name’,buf,sizeof(buf),NULL)”の行が、この例の中で“Mike”である、ノード“name”のfoo.iniファイルにストアされたデータに戻るだろう。このような.iniフィルは、レジストリシステムがセッティング値へのアクセスを許可することができるアプリケーションのリストの形式でセッティングオブジェクトに特定される特権であるFS ACLsに左右されやすいかもしれない。特権は、オブジェクト内のいくつかのセッティング値がパブリック（すなわち、任意のアプリケーションによってアクセス可能）であり、一方で同じオブジェクト内の他のセッティング値がプライベートであり、対応するACLで特定されるアプリケーションタイプまたはアプリケーションによってだけアクセス可能であるように、セッティングオブジェクト内に特定されることができる。

図１で示されるスクリプトを使用しているオブジェクトをセッティングしているネイティブノードを生成すると、開発者は図２の.cifファイルブロック６に示されるスクリプトを実行することによってセッティングレジストリにオブジェクト２を登録することができる。.cifファイルは、アプリケーション関する.mifファイルを生成するようにコンパイルされる。従って、ブロック６のコードは“name”ノードの単語“Mike”を含んでいる初期設定セッティングを維持するだろうセッティングオブジェクト“foo.ini”を定義するアプリケーション“fooApp”に関する.mifファイルで提供されるだろう情報を定義する。システムは、セッティングファイルに関してキーを決定するために携帯デバイスにストアされた.mifファイルを列挙することができる。特に、（.cifファイル６のコードによって定義される）.mifファイルは所有者、キー及びファイル（ブロック６の３行目から５行目を参照）を定義することが必要である。オブジェクトが１度登録されると、情報は図２のブロック８で示されるスクリプトを実行することによってアプリケーションによってアクセスされることができる。

上述され、及び図３に例証されるように、セッティングレジストリは全てのセッティングオブジェクト２０にアクセスするためにシングルトンサービス１８を実行する。これは、アプリケーション１０、１４及びレジストリ１２、１６の処理（破線の上部）セッティングオブジェクト２０へのアクセスとの間の（破線として例証される）処理境界の確立を可能にする。アプリケーション１０、１４によってコールされるＡＰＩ１２、１６にアクセスするネイティブセッティングはセッティングオブジェクトで実施されるファイル構造に関連した詳細を含む必要はない、またはファイル位置を指定する必要はない。このような詳細は、シングルトンサービス１８によって扱われる。

非ネイティブストアは、レジスタがネイティブサポートを持たない（すなわち、提供されるセッティングファクトリがなく、シングルトンサービス１８がセッティングオブジェクトファイルタイプにアクセスするように構成されない）データストレージメカニズムである。セッティングレジストリの様々な実施形態は、非ネイティブストアがそれ自身をツリーにインストールすること、及びそのツリー内のノードに生じる任意のオペレーションを扱うことを許可する。非ネイティブストアインプリメンテーションに依存することで、ストアのオペレーションはインプロセスまたは処理境界を横断して実行されるかもしれない。

ネイティブストアと同様に、非ネイティブストアは、ツリーの特定のノードを“所有する”ために、それらの.mifファイルに登録する。違いは非ネイティブストアがカスタムISettingsクラスに関するクラスIDを提供するということである。非ネイティブストアで、呼出者はレジストリクラスを始めに例示する。オペレーションが非ネイティブストアによって所有されるツリーのキーで作られる時、カスタムクラスが例示され（呼出者が適切な特権を持つと想定している）、オペレーションはそこに委任される。この場合、レジストリは“パススルー”として基本的には動作する。厳密には、呼出者はレジストリの代わりに直接的に例示することによって同様の機能を得ることができるだろうが、レジストリを使用することは使い方を簡単にする、特に呼出者がネイティブ及び非ネイティブの両方に関心がある時である。

開発者は、非ネイティブ“BMPSettings”に関する図４に例証される例のようなスクリプトを実行することによって非ネイティブノードを登録することができる。非ネイティブセッティングオブジェクトは、ブロック２２のコードに例証されるような.cifファイルに定義されることができる。定義された非ネイティブセッティングオブジェクトに関する処理は、ブロック２４で例証されるようなコードを含むことによって実行されるかもしれない。例示の時に、実施形態のレジストリ処理（例えば、SettingsReg）は、システムの登録された非ネイティブノードのリストを作る。一度、定義され実行されると、非ネイティブセッティングオブジェクトは、ブロック２６に例証されるものと同様のコードを含むことによってアプリケーション内にアクセスされることができる。非ネイティブノードへのアクセスコール時に、実施が作り出され及びオペレーションはそのオペレーションに委任される。

非ネイティブセッティングオブジェクトは開発者によって定義され、セッティングレジストリによって扱われることができないので、それらのアクセスコールは、非ネイティブストア実施に依存し、インプロセスまたは処理境界を横断して扱われるかもしれない。これは図５で例証される。任意のアプリケーション３０、３８が非ネイティブセッティングオブジェクト３６、４２（例えば、BMPSettings）に関するセッティングAPI３２、４０をコールする時、APIはインプロセス（すなわち、レジストリのシングルトンサービス１８を実行することのない同じ処理境界内）で要求された情報を得るために非ネイティブオブジェクトアクセスコード３６、４２を実行する。この方法で、開発者は特定のアプリケーションに関して望まれるどんな方法及びファイルタイプでも、新しいセッティングオブジェクト定義する完全な自由を持つ。

様々な実施形態の中のセッティング情報に関するアプリケーションコールの処理が図６に例証される。初期化（または、他の時間）の間、アプリケーションはISettings APIを介してセッティングレジストリでオペレーションを行うことによってセッティング情報を要求するかもしれない、ステップ６０。例えば、図３及び図５で例証されるように、アプリケーションは図２のコードブロック８及び図４のコードブロック２６で例証されるようにISettingsAPIを介して“SettingsReg”にアクセスするかもしれない。SettingsRegは要求されたセッティングオブジェクトがネイティブノードか非ネイティブノードであるべきかどうかを決定する、テスト６２。もし、要求がネイティブノードでの情報に関してならば（すなわち、テスト62=“はい”）、SettingsRegは、指し示されたセッティングオブジェクトにアクセスし、データをSettingsRegに戻す、ステップ６６、シングルトンサービスへオペレーションをパスする、ステップ６４。実施形態で、シングルトンサービスは、コールしているアプリケーションがセッティング情報にアクセスすることを認可されるかどうかを決定するためにコールされたセッティングオブジェクトで特定されるアクセス特権を比較するかもしれない、テスト６５。もし、呼び出しているアプリケーションがセッティングオブジェクト特権リストを満足しないならば（すなわち、アプリケーションまたはアプリケーションタイプがセッティングオブジェクトで特定される特権に合致しない、従ってテスト６５＝“いいえ”）、シングルトンサービスは呼出者に‘拒否されたアクセス’または類似のメッセージを返すかもしれない、ステップ６７。もし、コールしているアプリケーションはセッティングオブジェクト特権リストを満足するならば（すなわち、テスト６５＝“はい”）、SettingsRegは要求されたデータをアプリケーションに返す、ステップ６８。しかしながら、もし要求が非ネイティブノードの情報に関するものであれば（すなわち、テスト６２＝“いいえ”）、SettingsRegは要求されたデータを返すインプロセスのコールされた非ネイティブノードに関するセッティングオブジェクトを作る、ステップ７２。SettingsRegは要求されたデータをアプリケーションに返す、ステップ７４。

開発者は、アプリケーションの開発を簡単にするために様々な実施形態を使用することができる。次の段落は、開発者がセッティングレジストリの様々な実施形態を実行するためにアプリケーションに含むことができるステップ及び例のコードを記述する。

レジストリのルートレベルでサブレジストリを区別するために、各々は固有の文字列識別子を持たなければならない。これを達成するための最も簡単な方法はクラスIDを要求することである。例えば、

しかしながら、クラスIDｓは必要とされない。オーバーラップを避けるための注意がされなければならないけれども、より多くの人間が読める統一資源識別子（URIs）が同様に許可される。もしオーバーラップが生じるならば、振る舞いが定義されないかもしれない。

プライベートセッティングは、インスタンスごとに基づいてコンポーネントまたはアプリケーションに利用可能であるセッティングである。これらのセッティングはシステムの他のコンポーネントにさらされない。プライベートセッティングをサポートするISettingsは、セッティングを編成するための便利なメカニズムを簡単に提供する。

プライベートセッティングはファクトリを使用し、作られる。呼出者はセッティングを作るべきものから媒体についてのいくつかの情報を特定するし、ファクトリはセッティングにアクセスするために使用されることができるISettingsオブジェクトに戻す。

プライベートセッティングに関して、.mifファイルへの修正は要求されない。コンポーネントはランタイムで関心のISettingsオブジェクトを作り出すためにファクトリを簡単に使用する。

実施形態で、セッティングレジストリは、ISettings_OnChange()方法をサポートしないISettingsオブジェクトを戻すファクトリを含む。

パブリック.iniファイルのパブリックストアを加えるために、開発者はそれらのコンポーネントへのパブリック.iniファイルに基づいたセッティングストアを追加及びアクセスするために次のステップを実行することができる。第１の開発者はmysettings.iniと呼ばれるファイルに次のものをコピーすることができ、それをEFSのそれらのコンポーネントモジュールディレクトリに置くことができる。

第２に、開発者は、

のようなスクリプトを使用しているコンポーネントの.cifファイルに次のものを追加することによってシステムにストアを登録することができる。

第３に、開発者はセッティングへの他のappsアクセスを許可するACLsを選択的に定義することができる。

第４に、開発者はセッティングへのアクセスにアプリケーション内の次のコードを使用することができる。

開発者がコンポーネントへのパブリックヒープに基づいたセッティングストアを追加及びアクセスするためにとるステップは.iniファイルに基づいたストアに非常に類似する。主な違いは、.iniファイルの不足である。代わりに、ヒープに基づいたセッティングは、ストアによって使用されるかもしれないヒープの最大量を決定する割り当て値を必要とする。第１に、開発者は次のものをコンポーネントの.cifファイルに追加することによってシステムにストアを登録するかもしれない。

選択的に開発者は他のappsアクセスを次のようなそれらのセッティングへの他のappsアクセスを許可するＡＣＬｓを定義するかもしれない。

第３に、開発者はセッティングにアクセスするためにアプリケーション内の次のコードを使用することができる。ヒープに基づいたセッティングは、ISettings_Set()がそれにコールされるまで存在しないということに留意する。

実施形態で、開発者はカスタムISettings実装をセッティングレジストリに追加するために、次のものを実行することによって、パブリック（すなわち、全ての配置によってアクセス可能）であるアプリケーションに関するカスタムセッティングを定義することができる。第１に、開発者は具体化レジストリを実施するコンポーネントをライトする。第２に、開発者は、次のものをコンポーネント.cifファイルに追加することによってシステムにコンポーネントを登録する。

次に、開発者はセッティングにアクセスするアプリケーションの次のコードを使用する。レジストリクラスで実行される任意のISettingsオペレーションがカスタムクラスに委任されるだろうということに留意する。

実施形態で、開発者は次のものを行うことによって、アプリケーションに関するプライベート.iniファイルセッティングストア（すなわち、配置がただファイルにアクセスするための特別に与えられた許可にアクセス可能である）を定義することができる。第１に、開発者はmysetings.iniと呼ばれるファイルに次のものをコピーし、それをEFSのコンポーネントモジュールディレクトリに置く。

第２に、開発者はアプリケーションがセッティングにアクセスすることをできるようにするアプリケーションの次のコードを含む。

パブリックセッティングとは異なって、プライベートストアへのアクセスは接頭辞“/myApp/myIniSettings”を必要としないということに留意する。

開発者がアプリケーションコンポーネントのプライベートヒープに基づいたセッティングストアを実施するためにとるステップは、.iniファイルと関係がないということを除いて、.iniファイルに基づいたストアに非常に類似する。その代わり、ヒープに基づいたセッティングは、ストアによって使用されるかもしれないヒープストレージの最大量を決定するための割り当て値を必要とする。開発者は、セッティングにアクセスするためにアプリケーションに次のコードを使用することができる。ヒープに基づいたセッティングは、ISettings_Set()がそれにコールされるまで存在しないということに留意する。

実施形態で開発者は、カスタムISettingsインプリメンテーションにアクセスするために次のものを行うことによって、プライベートカスタムセッティングストアを定義することができる。第１に、開発者はISettingsを実施するコンポーネントをライトする。第２に、開発者はプライベートカスタムセッティングにアクセスするためにアプリケーションに次のコードを付け加える。

上で記述した実施形態は、例えば、携帯電話、携帯電話を備えた個人用デジタル補助装置(PDA)、モバイル電子メール受信器、モバイルウェブアクセス装置、及び将来開発されるかもしれないデバイスを装備した他のプロセッサ、のような様々なモバイルデバイスのいくつかで実施されるかもしれない。さらに、上で記述した実施形態は、デスクトップコンピュータ及びラップトップコンピュータに限定されないが含んでいる様々なコンピュータ・デバイスのいくつかで実施されるかもしれない。図７は、この中に開示された様々な実施形態おサポートすることができるモバイルデバイス２００の様々なコンポーネントを描く。典型的なモバイルヘッドセット２００は内部メモリ２０２及びユーザインターフェースディスプレイ２０３に接続されたプロセッサ２０１を含む。モバイルヘッドセット１０は、プロセッサ２０１に接続された携帯電話トランシーバ２０５及び./または無線データリンクに接続された電磁放射を送信及び受信するためのアンテナ２０４を含むかもしれない。いくつかの実施で、トランシーバ２０５は、携帯電話通信のために使用されるプロセッサ２０１及びメモリ２０２の一部が、組み合わせが無線データリンクを介してデータインタフェースを提供するため、無線インターフェースと呼ばれる。モバイルヘッドセットは、ユーザ入力を受信するためのローカースイッチ２０７またはメニュー選択ボタン及びキーパッド２０６を典型的に含む。

プロセッサ２０１は、上で記述された様々な実施形態の機能を含んでいる様々な機能を行うためのソフトウェアインストラクション（アプリケーション）によって構成されることができる、任意のプログラム可能なマイクロプロセッサ、マイクロプロセッサ、またはマルチプロセッサチップまたはチップであるかもしれない。いくつかのモバイルデバイスで、マルチプロセッサ２０１は他のアプリケーションを動かすのに専用にされた１つのプロセッサ及び無線通信機能に専用にされた１つのプロセッサのようなものが提供されるかもしれない。典型的にソフトウェアアプリケーションはそれらがアクセスされ、プロセッサ２０１にロードされる前に内部メモリ２０２に格納されるかもしれない。いくつかのモバイルデバイスで、プロセッサ２０１はアプリケーションソフトウェアインストラクションをストアするのに十分な内部メモリを含むかもしれない。この記述の目的のために、用語メモリはプロセッサ２０１それ自身内のメモリ及び内部メモリ２０２を含んでいるプロセッサ２０１によってアクセス可能な全てのメモリを参照する。メモリ２０２は、揮発性メモリまたはフラッシメモリのような不揮発性メモリ、または両方の混合物であるかもしれない。

前述の実施形態を実施するために使用されるハードウェアは一連のインストラクションを実行するように構成されたメモリ要素及びプロセシング要素であるかもしれない、一連のインストラクションとは上の方法に対応している方法ステップを行うためである。あるいは、いくつかのステップまたは方法は、与えられた機能に特有の回路によって行われるかもしれない。

当業者は、この中に開示された実施形態と関連して記述された様々な例証の論理ブロック、モジュール、回路、及びアルゴリズムステップは、電子機器、コンピュータソフトウェア、または両方の組み合わせとして実施されるかもしれないということを理解するだろう。ハードウェア及びソフトウェアのこの互換性を明らかに例証するために、様々な例証のコンポーネント、ブロック、モジュール、回路、及びステップが、それらの機能性によって一般的に上に記述された。これらの機能性がハードウェアまたはソフトウェアのどちらとして実施されるかどうかは、全体のシステムに課された設計制限及び特定のアプリケーションに依存する。当業者は、各々の特定のアプリケーションに関する方法を変更する際に、記述された機能性を実施するかもしれないが、このような実施の決定は本発明の範囲からの逸脱を生じることとして解釈されるべきでない。

この中で開示された実施形態と関連して記述されたアルゴリズムまたは方法のステップは、直接的にハードウェアで、プロセッサによって実行されるソフトウェアモジュール、または２つの組み合わせで具体化されるかもしれない。ソフトウェアモジュールは、プロセッサ読取可能な記録媒体及び/またはプロセッサ読取可能なメモリに存在するかもしれない、その両方は、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または業界で知られた任意の他の明白な形式のデータ記録媒体のいくつかであるかもしれない。さらに、プロセッサ読取可能なメモリは、２つ以上のメモリチップ、プロセッサチップ内部のメモリ、セパレートメモリチップ、及びがフラッシュメモリ及びRAMメモリのような異なるメモリタイプの組み合わせを具備しているかもしれない。モバイルヘッドセットのメモリのこの中での言及は、特定の構成、タイプまたはパッケージングに限定されないモバイルヘッドセット内の任意の１つまたは全てのメモリモジュールに包含することに意図される。例示の記録媒体は、プロセッサが情報を記録媒体から読み出すことができ、及び情報を記録媒体に書き込むことができるように、モバイルヘッドセットまたはテーマサーバのどちらかのプロセッサに接続される。あるいは、記録媒体はプロセッサに集約されるかもしれない。プロセッサ及び記録媒体はASICに存在するかもしれない。

様々な実施形態の前述の記述は、任意の当業者が本発明を作るまたは使用することを可能にするために提供される。これらの実施形態への様々な修正は、当業者にはすでに明白であるかもしれないだろうし、この中に定義される本来の原理は発明の精神または範囲から逸脱することなく他の実施形態に適用されるかもしれない。従って、本発明はこの中に示される実施形態に限定されることに意図されないし、その代わりに請求項はこの中に開示された原理及び新しい特徴に一致する最も広い範囲に扱われるだろう。

Claims (20)

1. レジストリ内のソフトウェアセッティングをストアするための及びアクセスするための方法であって、
   セッティング値を含んでいるネイティブセッティングオブジェクトを生成すること、及びキーでメモリに前記ネイティブセッティングオブジェクトをストアすることと、
   アプリケーション・プログラミング・インターフェース（API）コールの形式でアプリケーションから前記セッティング値に関するコールを受信することと、
   前記セッティング値を得るためにレジストリと関連したシングルトンサービスを実施することと、
   前記シングルトンサービス内の前記ネイティブセッティングオブジェクトからの前記セッティング値を得ることと、
   前記シングルトンサービスから前記APIに前記セッティング値を戻すことと、
   前記APIから前記アプリケーションに前記セッティング値を戻すことと
   を具備する方法。
2. 前記シングルトンオブジェクトはネイティブセッティングオブジェクトへの全てのアクセスを制御する請求項１記載の方法。
3. 前記シングルトンサービス内以外のソフトウェアに定義された非ネイティブセッティングオブジェクトを受信することと、
   前記APIが、ネイティブセッティングオブジェクトまたは非ネイティブセッティングオブジェクトをコールする前記アプリケーションから前記セッティング値をコールするかどうかを決定することで、前記ＡＰＩが非ネイティブセッティングオブジェクトをコールすることが決定された時にシングルトンサービスを行うことと前記シングルトンサービス内の前記セッティング値を得ることと前記シングルトンサービスから前記ＡＰＩファンクションに前記セッティング値を戻すこととの前記ステップが実行される、ことと、
   前記ＡＰＩが非ネイティブセッティングオブジェクトをコールすることが決定される時前記コールされたセッティング値を得るための非ネイティブプロセスを実施することと
   をさらに具備する請求項１記載の方法。
4. 前記アプリケーションが前記コールされたセッティングオブジェクトで特定された特権を満たすかどうかを決定することと、
   前記アプリケーションが前記コールされたセッティングオブジェクトで特定された前記特権を満たさないということが決定された時、前記セッティング値へのアクセスを拒否することと
   をさらに具備する請求項１記載の方法。
5. 前記ネイティブオブジェクトが生成される時、前記特権を定義することをさらに具備する請求項４記載の方法。
6. プロセッサと、
   前記プロセッサに接続され、セッティング値を含んでいるネイティブセッティングオブジェクトを生成すること及びキーでメモリに前記ネイティブセッティングオブジェクトを格納することと、
   アプリケーションプログラミングインターフェース（ＡＰＩ）コールの形式でアプリケーションから前記セッティング値に関するコールを受信することと、
   前記セッティング値を得るために、前記レジストリと関連したシングルトンサービスを実施することと、
   前記シングルトンサービス内の前記ネイティブセッティングオブジェクトから前記セッティング値を得ることと、
   前記シングルトンサービスから前記ＡＰＩに前記セッティング値を戻すことと、
   前記ＡＰＩから前記アプリケーションに前記セッティング値を戻すこととを具備するステップを実行するプロセッサ実行可能なインストラクションを用いて前記プロセッサが設定され、前記プロセッサに接続されたメモリと
   を具備するモバイルデバイス。
7. 前記プロセッサが、前記シングルトンオブジェクトがネイティブセッティングオブジェクトへの全てのアクセスを制御するようにプロセッサ実行可能なインストラクションを用いてさらに設定される請求項６記載のモバイルデバイス。
8. 前記シングルトンサービス内以外のソフトウェアで定義される非ネイティブセッティングオブジェクトを受信することと、
   前記アプリケーションからの前記セッティング値に関する前記ＡＰＩコールがネイティブまたは非ネイティブセッティングオブジェクトをコールするかどうかを決定することで、前記ＡＰＩがネイティブセッティングオブジェクトをコールすることが決定された時シングルトンサービスを実施ことと前記シングルトンサービス内で前記セッティング値を得ることと前記シングルトンサービスから前記ＡＰＩファンクションに前記セッティング値を戻すことの前記ステップが実行される、ことと、
   前記ＡＰＩが非ネイティブセッティングオブジェクトをコールすることが決定される時、前記コールされたセッティング値を得るための非ネイティブプロセスを実施することとをさらに具備するステップを実行するプロセッサ実行可能なインストラクションを用いて前記プロセッサがさらに設定される請求項６記載のモバイルデバイス。
9. 前記アプリケーションが前記コールされたセッティングオブジェクトで特定された特権を満たすかどうかを決定することと、
   前記アプリケーションが前記コールされたセッティングオブジェクトで特定された前記特権を満たさないことが決定される時、前記セッティング値へのアクセスを拒否することとをさらに具備するステップを実行するプロセッサ実行が可能なインストラクションを用いて前記プロセッサがさらに設定される請求項６記載のモバイルデバイス。
10. 前記ネイティブオブジェクトが生成される時、前記特権を定義することをさらに具備するステップを実行するためのプロセッサ実行可能なインストラクションを用いて前記プロセッサがさらに設定される請求項９記載のモバイルデバイス。
11. セッティング値を含んでいるネイティブセッティングオブジェクトを生成すること、及びキーでメモリに前記ネイティブセッティングオブジェクトを格納することと、
    アプリケーションプログラミングインターフェース（ＡＰＩ）コールの形式でアプリケーションから前記セッティング値に関するコールを受信することと、
    前記セッティング値を得るために前記レジストリに関連したシングルトンサービスを実施することと、
    前記シングルトンサービス内の前記ネイティブセッティングオブジェクトから前記セッティング値を得ることと、
    前記シングルトンサービスから前記ＡＰＩに前記セッティング値を戻すことと、
    前記ＡＰＩから前記アプリケーションに前記セッティング値を戻すこととを具備するステップをコンピュータ・デバイスのプロセッサに実行させるプロセッサ実行可能なソフトウェアインストラクションをそこに格納しているタンジブル記憶媒体。
12. 前記シングルトンオブジェクトがネイティブセッティングオブジェクトへの全てのアクセスを制御するようなプロセッサ実行可能なソフトウェアインストラクションをさらにそこに格納している請求項１１記載のタンジブル記憶媒体。
13. 前記シングルトンサービス内以外のソフトウェアで定義された非ネイティブセッティングオブジェクトを受信することと、
    前記アプリケーションから前記セッティング値に関する前記ＡＰＩコールが、ネイティブまたは非ネイティブセッティングオブジェクトをコールするかどうかを決定することで、前記ＡＰＩがネイティブセッティングオブジェクトをコールすることが決定される時シングルトンサービスを実施することと前記シングルトンサービス内の前記セッティング値を得ることと前記シングルトンサービスからの前記ＡＰＩファンクションに前記セッティング値を戻すことのステップが実行される、ことと、
    前記ＡＰＩが非ネイティブセッティングオブジェクトをコールすることが決定される時、前記コールされた少なくとも１つのセッティング値を得るための非ネイティブプロセスを実施することをさらに具備する前記ステップを実行させるプロセッサ実行可能なソフトウェアインストラクションをそこにさらに格納している請求項１１記載のタンジブル記憶媒体。
14. 前記アプリケーションが前記コールされたセッティングオブジェクトで特定された特権を満たすかどうかを決定することと、
    前記コールされたセッティングオブジェクトで特定された前記特権を前記アプリケーションが満足しないということが決定される時、前記少なくとも１つのセッティング値へのアクセスを拒否することとをさらに具備するステップを実行するためにプロセッサ実行可能なインストラクションをそこにさらに格納している請求項１１記載のタンジブル記憶媒体。
15. 前記ネイティブオブジェクトが生成される時、前記特権を定義することをさらに具備するステップを実行するプロセッサ実行可能なインストラクションをそこにさらに格納している請求項１４記載のタンジブル記憶媒体。
16. セッティング値を含んでいるネイティブセッティングオブジェクトを生成し、及びキーでメモリに前記ネイティブセッティングオブジェクトを格納するための手段と、
    アプリケーションプログラミングインタフェース（ＡＰＩ）コールの形式でアプリケーションから前記セッティング値に関するコールを受信するための手段と、
    前記セッティング値を得るために前記レジストリに関連したシングルトンサービスを実施するための手段と、
    前記シングルトンサービス内の前記ネイティブセッティングオブジェクトから前記セッティング値を得るための手段と、
    前記シングルトンサービスから前記ＡＰＩに前記セッティング値を戻すための手段と、
    前記ＡＰＩから前記アプリケーションに前記セッティング値を戻すための手段とを具備するモバイルデバイス。
17. 前記シングルトンオブジェクトを実施するための手段が、ネイティブセッティングオブジェクトへの全てのアクセスを制御するための手段を含む請求項１６記載のモバイルデバイス。
18. 前記シングルトンサービス内以外のソフトウェアで定義された非ネイティブセッティングオブジェクトを受信するための手段と、
    前記アプリケーションから前記セッティング値に関する前記ＡＰＩコールがネイティブまたは非ネイティブセッティングオブジェクトをコールするかどうかを決定することで、前記ＡＰＩがネイティブセッティングオブジェクトをコールすることが決定される時シングルトンサービスを実施することと前記シングルトン内の前記セッティング値を得ることと及び前記シングルトンサービスから前記ＡＰＩファンクションに前記セッティング値を戻すこととのステップが実行される、ことと、
    前記ＡＰＩが非ネイティブセッティングオブジェクトをコールすることが決定される時、前記コールされたセッティング値を得るための非ネイティブプロセスを実施するための手段とをさらに具備する請求項１６記載のモバイルデバイス。
19. 前記アプリケーションが前記コールされたセッティングオブジェクトで特定された特権を満たすかどうかを決定するための手段と、
    前記アプリケーションが前記コールされたセッティングオブジェクトで特定された前記特権を満たさないことが決定される時、前記セッティング値へのアクセスを拒否するための手段とをさらに具備する請求項１６記載のモバイルデバイス。
20. 前記ネイティブオブジェクトが生成される時、前記特権を定義するための手段をさらに具備する請求項１９記載のモバイルデバイス。

Images