JP5235665B2

JP5235665B2 - Ｕｉテーマの変更時にリモート・リポジトリに問い合わせることによりカスタム・インターフェース要素を自動的に取得する方法、装置およびコンピュータ・プログラム製品

Info

Publication number: JP5235665B2
Application number: JP2008524602A
Authority: JP
Inventors: ミカエルイングラシア; チットゥリスレシュ; トルガキャピン; コウイチモリ
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2005-08-01
Filing date: 2005-08-01
Publication date: 2013-07-10
Anticipated expiration: 2025-08-01
Also published as: US20100169357A1; EP1913497A4; WO2007015118A1; EP1913497A1; JP2009503713A

Description

本発明は、全般的にユーザ・インターフェースに関し、特に、カスタマイズ可能なユーザ・インターフェースに関する。

背景

当該技術分野において、コンピュータ・デバイスから離れた構成要素にアクセスすること、ならびにユーザ・インターフェース要素を変更することが知られている。このような技術の例には、2000年8月8日発行のゴーダル（Guordal）らの米国特許第6,100,888号、2000年2月29日発行のゴーダルらの米国特許第6,031,532号、および2004年8月12日公開のガスリー（Guthrie）らの米国特許出願公開第2004/0158811A1号などがある。

典型的なパーソナル・コンピュータ・デバイスのユーザ・インターフェースは、カスタマイズ可能な広範囲の機能をサポートしている。ユーザは、配色、アイコンのビジュアル・デザイン、カスタマイズされたサウンド・イベントのような項目を独自のものにできる。カスタマイズ設定を単純化するために、これらの設定を複数のテーマに論理的にグループ化することをサポートしているシステムもある。特定のテーマを読み込むことで、デバイスの設定すべてが同時に自動変更されるため、ユーザ自身が設定を個別に変更する必要がなくて済むようになる。

高度なパーソナル・コンピュータ・デバイスには、テーマに加えて、ウィジェットなど、個々のユーザ・インターフェース（UI：user interface）要素の外観および印象のユーザ・カスタマイズをサポートしているものもある。例えば、図1および2を参照すると、Windows XP（登録商標）環境で操作しているユーザが、「WindowsクラシックUI」（図1aにあるように）の使用および「Windows XP UI」（図1bにあるように）の使用から選択できるようにする、複数のダイアログ・ボックス12が図示されている。図2a〜2bでは、種々のテーマ・パッケージをユーザが定義および使用できるようにする、リナックス（Linux）（商標）・デバイス上で動作しているGNOMEデスクトップの第2の例が図示されており、このテーマ・パッケージは、ウィジェット、アプリケーション境界（application border）およびシステム・アイコンなど、システム全体の新たな外観および印象を定義するものである。

この技術の説明に使用されるいくつかの用語を参考として定義しておく。「スキン」は、デバイス上の単一のアプリケーションの外観および印象を指定するアプリケーション・レベルの定義である。１つのアプリケーションのスキンを変更しても、同一のデバイス上で実行される他のアプリケーションには全く影響がない。当該技術分野で知られている例は、マイクロソフト・ウィンドウズ（登録商標）を実行しているコンピュータで使用されるウィンアンプ（WinAmp）またはウィンドウズ・メディア・プレーヤー（Windows Media Player）のスキンを見ればわかる。

「テーマ」も同じくUIの外観および印象を変更するが、スキンとは明確に異なる点がいくつかある。まず、テーマは、システム・レベルで要素の外観および印象を変更する。これは、デバイス上で使用されるUIテーマを変更すると、そのデバイス上で実行される全アプリケーションに影響が及ぶことを意味する。次に、通常、テーマによって変更可能なのは外観および印象のみではない。エラーまたは警告など、特定のUIイベントにサウンドを関連付けることもできる。最後に、テーマの定義は通常、どのスクリーン・セーバを使用するか、およびその他のシステム設定などの指定を含む。

最後に「ウィジェット」を定義する。「ウィジェット」は、ユーザからのユーザ入力の受け付け、またはユーザに対する情報の表示を行うシステムUIコントロールである。ユニックス（UNIX）（登録商標）の専門用語の領域では、このようなコントロールはウィジェットと呼ばれる一方、ウィンドウズ（登録商標）の領域では、このようなコントロールは一般的に「コントロール」と呼ばれる。一貫させるために、本願明細書ではこのようなコントロールはすべて「ウィジェット」と呼ばれる。ウィジェットには幅広い種類のものがある。一般的な種類のウィジェットの一部には、「テキスト・ボックス」、「ラジオ・ボタン」、「ドロップ・ダウン・リスト」、「コマンド・ボタン」、「ツリー表示」、「チェック・ボックス」などがあるが、これらに限定はされない。

上述のとおり、パーソナル・コンピュータ・デバイスで、デバイスのグラフィカル・ユーザ・インターフェースのユーザ・カスタマイズができるのは、一般的なことである。変更される属性で最も一般的なのは、配色およびテキスト・サイズなどの単純な属性である。一部の高度なデバイスにより、システム内でのUIウィジェットの外観および印象のユーザ・カスタマイズがサポートされている一方、多くのシステムにテーマ管理のサポートが含まれている。

現在、ユーザが新たなテーマをデバイスにインストールしたい場合、1）運用している特定のプラットフォームのテーマ・パッケージが格納されている場所、ならびに使用しているデバイスおよびソフトウェアのバージョンを知ること、2）テーマをダウンロードすること、3）テーマにより要求される、必要な拡張をすべてシステムにダウンロードすること、および4）すべてをインストールすること、ただし多くの場合は、手動でファイルを正しい場所へコピーすることが必要である。ユーザの目から見た問題は、多数のプラットフォームおよびデバイスに対応するテーマ・パッケージが膨大な量になっていることである。これは、初心者のユーザにとってかなり大変なものとなる可能性がある。

テーマの設計者も、同様の複雑性に直面している。現在テーマの設計者には、1）どのプラットフォームおよびデバイスをサポートするかを決定すること、2）ウィジェット定義および関連した素材などのテーマの内容を作成すること、および3）当該の特定のプラットフォームおよびデバイス向けに素材をすべてまとめてテーマ・パッケージを形成することが必要とされる。設計者が、別のデバイス向けに同じテーマを作成したければ、プロセスを再度繰り返す必要がある。このような繰り返しは時間のかかる取り組みである。現在のスキームに関する別の問題は、設計者が、サポートしたいプラットフォームごとにテーマ素材およびディストリビューションを再作成しなければならないということである。大部分のプラットフォームがウィジェット定義の共通のセットを共有しているにも関わらず、設計者は、この取り組みをたびたび繰り返さなければならない。設計者が新たなプラットフォーム向けのテーマを作成したい場合、設計者はゼロからすべてを再設計して組み込まなければならない。

サービス提供元は、様々な設計者から提供されたテーマ定義をユーザに提供する。現在のシステムのもとでは、これによって記憶スペースが浪費される可能性がある。多数の異なるプラットフォーム向けのテーマが、いくつかのウィジェット定義を共通して有している。例えば、大部分のシステムは、「コマンド・ボタン」、「テキスト・ボックス」、「チェック・ボックス」および「リスト」という概念を有する。現在のスキームのもとでは、各テーマが、サポート対象のプラットフォームそれぞれに対してまとめられて、共通のウィジェットの重複した定義を含まなければならないため、サービス提供元で記憶スペースが浪費されている。

したがって、デバイスにテーマを展開したいユーザが、効率的にテーマ定義を作成、格納し、それにアクセスできるようにする技術が必要とされている。このような技術は、携帯電話会社、コンテンツ設計者およびアプリケーション開発者の役に立つと思われる。
米国特許第6,100,888号米国特許第6,031,532号米国特許出願公開第2004/0158811A1号

好適な実施形態の摘要

本発明の例示的実施形態によれば、方法は、デバイスに常駐していない少なくとも１つのユーザ・インターフェース要素を特定的に要求するクエリを形成することと、このクエリを、ユーザ・インターフェース要素の定義を複数含むリモート・リポジトリへ送信することと、リモート・リポジトリから応答データを、クエリに応答して動的に検索することと、応答データをデバイスのユーザ・インターフェースに適用することとを含む。

本発明のさらなる例示的実施形態によれば、システムは、デバイスに常駐していない少なくとも１つのユーザ・インターフェース要素を要求するクエリを形成する手段と、このクエリを、ユーザ・インターフェース要素の定義を複数含むリモート・リポジトリへ送信する手段と、リモート・リポジトリから応答データを、クエリに応答して動的に検索する手段と、応答データを前記デバイスのユーザ・インターフェースに適用する手段とを含む。

本発明の別の例示的実施形態によれば、情報保持媒体に有形に具現化されてデジタル・データ処理装置により実行可能であり、ユーザ・インターフェースを変更することを目的とした動作を実行する機械可読命令のプログラムが提供され、この動作は、デバイスに常駐していない少なくとも１つのユーザ・インターフェース要素を要求するクエリを形成することと、このクエリを、ユーザ・インターフェース要素の定義を複数含むリモート・リポジトリに送信することと、ユーザ・インターフェース要素の定義を少なくとも１つ含む応答をリモート・リポジトリから受信することと、デバイスのユーザ・インターフェースを、この応答に応答して変更することとを含む。

これら教示の前述の態様およびその他の態様は、以下の詳細な説明を添付の図面と併せて読むことで、さらに明らかとなる。

テーマを選択する先行技術のユーザ・インターフェースの例示的実施形態である。テーマを選択する先行技術のユーザ・インターフェースの例示的実施形態である。

テーマを取り入れた先行技術のユーザ・インターフェースの例示的実施形態である。

本発明を実践するシステムの例示的実施形態の説明図である。

例示的なテーマおよびウィジェット表の項目の説明図である。

本発明の方法の例示的実施形態の論理流れ図である。

リポジトリの例示的実施形態のベン図である。

一致しないアイコンから成るユーザ・インターフェースの例示的実施形態である。

一致するアイコンから成るユーザ・インターフェースの例示的実施形態である。

本発明の方法の例示的実施形態の論理流れ図である。

例示的なスタイル定義表項目の説明図である。

スタイル定義が適用される例示的なユーザ・インターフェースの説明図である。

本発明の方法の例示的実施形態の論理流れ図である。

本発明の例示的実施形態に従った移動局の図である。

詳細な説明

本発明の例示的実施形態では、UIを使用できるデバイスのユーザによるアクセスを目的として、テーマ・データ、スタイルデータ、アイコン、ウィジェットを含むがこれらに限定されない、デバイスに依存しないUIデータならびにデバイスに依存するUIデータを、リポジトリに格納する方法が提供される。以下でさらに詳しく説明するように、ユーザによる遠隔アクセスが可能なリポジトリでこのようなUIデータを記憶することによって、ユーザ側で必要とされる取り組みが比較的低レベルであり効率的に所望の変更が実装される方法で、デバイスのUIに変更を加えることが可能になる。

図3を参照すると、本発明の例示的実施形態を実践するシステムの構成が図示されている。デバイス10は、グラフィカル・ユーザ・インターフェース（GUI: graphical user interface）15が常駐しているコンピュータ・デバイスである。デバイス10は、パーソナルコンピュータ（PC: personnel computer）、ラップトップ・コンピュータ、ノートブック型コンピュータ、携帯情報端末（PDA: personal digital assistant）、移動電話などを含むがこれらに限定されない、任意のデジタル・コンピュータ・デバイスであればよい。

デバイス10は、リンク17を介してリポジトリ20と双方向通信している。リンク17は、無線リンク17として図示されているが、配線接続、またはデバイス10がリポジトリ20へデジタル・データを送信し、リポジトリ20からデジタル・データを受信できるようにする、その他任意の形態の接続であればよい。

リポジトリ20は、UIデータを格納しており、要求されたUIデータを検索して要求されたUIデータをデバイス10へリンク17を介して送信することによって、リポジトリ20内に格納されているUIデータについての要求に応答できる。リポジトリ20は、非限定的な例として、ウィジェット定義、アイコン定義、UIスタイル定義およびテーマ定義、ひとまとめにして「UI要素の定義」21を格納しているとよい。特にウィジェットおよびテーマに関して、リポジトリ20は、多数の利用可能なテーマに対応するウィジェット・タイプの定義を格納しているとよい。

例示的実施形態では、リポジトリ20は、関係データベース内にUI要素の定義21を格納している。そのため、各ウィジェット定義は、ウィジェット定義が準拠しているテーマの識別子によって属性付けされるとよく、さらに、定義がデバイスに依存する場合は、そのウィジェット定義が有効であるすべてのデバイスのデバイス識別子によって属性付けされるとよい。同じように、各ウィジェット定義は、そのウィジェット定義が有効であるテーマすべてを特定する属性を含んでもよい。

図4を参照すると、リポジトリ20に存在するデータベースの、ウィジェットおよびテーマについての表項目の例が図示されている。「0143」というウィジェットidを有するウィジェット・タイプ「list box」は、定義されているように、ウィジェットが、テーマ「classic」および「futuristic」に適合しており、PDAおよびPCに適合することを示す属性を有する。これらの属性に加え、一般的なウィジェット定義41が図示されている。ウィジェット定義41は、ウィジェットを記述しているかまたはその記述を可能にする任意のデータ形式により形成されるとよい。ウィジェット定義41は、ビットマップまたはその他の画像ファイル形式により形成されたデータを含んで、ウィジェットの外観を記述することもあり得る。さらにウィジェット定義は、ポインタまたは統一資源識別子（URI: uniform resource identifier）などのその他のアドレス指定メカニズムを含んで、さらなるウィジェット定義41のデータのローカル位置またはリモート位置を示すこともあり得る。さらに、ウィジェット定義41のデータは、サポートされているデバイスまたはプラットフォームの異なる画面解像度に対応する、種々の解像度の画像ファイルをいくつか含んでもよく、または反対に、スケーラブル・ベクター・グラフィックス（SVG: scalable vector graphics）形式により提供されるものなど、大きさに依存しない単一のウィジェット定義41を含んでもよい。

さらに、「0117」というテーマidおよび「classic」というテーマ・タイプを有するテーマの例示的な表項目が図示されている。数値として示されているが、テーマidは、下記のように拡張可能なマーク付け言語（XML: extensible markup language）名前空間の定義法に似た命名規則を使用して参照されてもよい。テーマidは、テーマに含まれるウィジェットに対応する１つまたは複数のウィジェットidを属性として有する。上記の例で述べたように、ウィジェットid「0143」の表項目は、ウィジェットについてテーマ「classic」に適合すると定義している。テーマid「0117」は、種類「classic」のものであり、そのため、ウィジェットid「0143」を構成要素のウィジェットとして記載しているということが分かるであろう。ウィジェットidおよびテーマ・タイプを含むがこれらに限定されないテーマidに関連する属性の領域は、テーマを十分に定義する。

関係データベースをホストしているリポジトリ20に関連して説明したが、本発明は、以下でより詳しく説明されるように、UIデータを格納および読み出しできる任意の形態のデータ・リポジトリに広範に適用される。

リポジトリ20の一般的な形態および機能についてここで説明したため、デバイス10と、デバイス10から離れているリポジトリ20との対話について論じることができる。図5を参照すると、UIデータが要求および利用される方法の論理流れ図が図示されている。ステップ1で、例えば選択されたテーマに関係するデータなど、UIデータの要求が構成される。例示的実施形態では、デバイス10にはユーザ・インターフェース15が組み込まれており、これによってテーマが選択されるとよい。例えばユーザは、リスト・ボックス内の選択対象をクリックすることによって、「classic」テーマを適用することを決定してもよい。
ステップ2で、デバイス10に繋がれているかまたはデバイス10内にあり、ソフトウェアで定義されているものなどの命令を実行できる処理装置19が、ユーザの「classic」という選択を受信し、要求されたテーマに対応した関連するUI要素の定義すべてを検索するためのリポジトリ20への要求、すなわちクエリをフォーマットする。例示の場合では、クエリはテーマidまたはテーマ・タイプのみを含んでもよい。このような場合、リポジトリは、テーマ属性として「classic」を有するウィジェットに対応する全ウィジェット定義41のデータを返すと思われる。なお、リポジトリは、要求されたウィジェット定義41を検索してクエリへの応答を動的に作成する。「動的に作成する」というのは、応答の内容はクエリの内容に応じて作成され、クエリの内容によって決まるものであり、そのため、作成前から完成した形で存在することはないということを意味する。別の例示的実施形態では、クエリは、テーマ識別子（id: identifier）ならびに必要とされるウィジェット定義41のデータの明確なリストを含んでもよい。このような場合、要求されるユーザ・インターフェース要素が、読み出しのために明確に特定される。例えば、デバイス10とリポジトリ20との間の通信は、ハイパーテキスト転送プロトコル（HTTP: HyperText Transfer Protocol）を使用して実行でき、この場合、要求は次のようにフォーマットされる:

GET THEME
THEME_ID＝"http://www.nokia.com/classic/2004"
WIDGET_TYPES＝"text/entry, list/select,
button/command, button/radio,
button/toggle"

この例に加えて、さらなる情報がこの要求に埋め込まれてもよい。例えば、所望の解像度またはデバイスのタイプが含まれてもよい。このような追加の情報を含めることで、特定のデバイスにより追加としてサポートされているテーマを構成するウィジェットだけがアクセスされて、デバイス10へ送信されればよくなる。図6を参照すると、リポジトリ20に格納されているすべてのウィジェット・タイプの領域内における、ウィジェット定義41の考えられる共通部分の例示的なベン図が図示されている。

図5に戻ると、リポジトリ20が、ステップ3でデバイス10のクエリにより定義されたUIデータを検索し、ステップ4で、ウィジェット定義41を用いてデバイス10に応答する。上述のように、ウィジェット定義41は、単数または複数のウィジェットの属性を記述するデータという形をとってもよく、または、ウィジェット定義41を取得できる場所を指示するURIという形をとってもよい。例えば、ウィジェット定義41そのものを返す応答は次のようにフォーマットされ得る:

OK THEME
THEME_ID＝"http://www.nokia.com/classic/2004" <widget_definition_data>

このような応答は、ステップ4でリポジトリ20によりデバイス10へ送信される。応答を受信すると、デバイス10、より具体的には処理装置19が、ステップ4で与えられたURIからのウィジェット定義の取り出し、あるいは、応答の<widget_definition_data>部分からのウィジェット定義41の抽出に進む。

最後にステップ5で、処理装置19は、新たに受信されたウィジェットに従い適切なユーザ・インターフェースの設定を変更し、その結果、それに合わせてデバイスのユーザ・インターフェースが変更される。

明らかなことではあるが、上述のシステムは、所定のテーマを形成するすべてのウィジェット定義41を、別々のテーマ・パッケージで格納する必要性を軽減する。単一のウィジェット定義41が、複数のテーマによって使用されるとよい。さらに、要求されたテーマに関連しているUIデータすべてをデバイス10に送信する必要はない。上述のとおり、受信されたクエリのもとであるデバイスに適合するウィジェット定義41、またはデバイス10により特定的に要求されたウィジェット定義41のみから、関連する要求対象のウィジェット定義41をすべて含むテーマ・データを動的に形成できる。

さらに、デバイス10のユーザは、複雑な手順でテーマ・パッケージを構成するウィジェット定義41すべてを得る必要はない。ユーザは、リポジトリ20において入手可能なテーマを閲覧して、１つ選択するだけでよい。ユーザのデバイス10は必要なウィジェット定義41を要求するだけでよく、リモート・リポジトリ20は、要求されたテーマ・データを動的に集めて、それをデバイス10へ送信する。

代わりの例示的実施形態では、アイコンから形成されたUIデータの格納にリポジトリ20が利用される。アイコンはアプリケーション専用であることが多い。一般的に、特定のアプリケーションに対応するアイコンは表示されてアクセス手段としての機能を果たし、この手段によってアプリケーションを呼び出しできる。結果として、特定のテーマを実装しているデバイス10にアプリケーションを読み込むと、アプリケーションの常駐アイコンがテーマに合わないという状況がもたらされることもある。これは特に、テーマの定義の前に開発されてデバイス10に読み込まれたアプリケーションおよび付随するアイコンを利用する場合に起こる可能性がある。

通常は、テーマに準拠したアプリケーション用アイコンを欠くテーマをユーザ・インターフェースが実装すると、初期設定のアイコンが利用される。多くの場合、このような代用によって、図7a〜7bに関して図示されているような、デザイン要素の魅力に欠ける混在状態を有するユーザ・インターフェースがもたらされる。図7aでは、ユーザ・インターフェース15にテーマが実装されているが、ここではアイコン71すべてがテーマに適合しているわけではない。アプリケーション「ビデオ録画」のアイコン71aが平たく見える一方、「アプリケーション」のアイコン71bなど、他のアイコン71は遠近法で表示されていることに注目されたい。これは、「ビデオ録画」アプリケーションの初期設定のアイコン71を、斜視図アイコン71をサポートしているテーマに合わせて使用した結果である。

図7bを参照すると、あるテーマを実装しているユーザ・インターフェース15が図示されており、ここでは、アプリケーション・アイコン71''すべてがテーマに準拠している。例えば、アプリケーション「ビデオ録画」のアイコン71a'が遠近法になっている様子に注目されたい。本発明のこの例示的実施形態によれば、アイコン定義などのUIデータが格納されているリポジトリ20にアクセスできるデバイス10が、デバイスに常駐していないアイコン定義を要求および受信できる。

例示的実施形態では、リモート・リポジトリ20からアイコン定義を取得するために２つの情報が使用される。１つ目はテーマidであり、２つ目はアプリケーションidである。ウィジェット定義41から形成されているテーマ・パッケージに関連して上で述べたように、XML名前空間の定義法に似た方法を使用して、テーマidを作成できる。アプリケーションidについては、具体例としてシンビアン（Symbian）（商標）のようなシステムに照らして言えば、各アプリケーションが一意的なidをシンビアン（商標）社に登録することが要求される。そのため、シンビアン（商標）・オペレーティング・システムを利用しているシステムでは、リポジトリ20の検索に使用されるアプリケーションidを、シンビアン（商標）に登録されている公式idとすることもできる。さらに、シンビアン（商標）以外のシステム上では、アプリケーションidは、XML名前空間の定義法に似た方法で決定することも可能である。

図8を参照すると、アイコンが要求、受信および実装される方法の論理流れ図が図示されている。図5のステップ5で示されているように、ステップ1で、例えば新たなテーマを用いて、デバイスのユーザ・インターフェース15が更新されている。ステップ2で、デバイス10、具体的には処理装置19が、デバイス10にインストールされているがデバイス10では定義されておらず、そのためリポジトリ20から得る必要があるアプリケーションがどれであるかを確認するために問い合せを行う。

ステップ3で、デバイス10は、未定義のアプリケーションに対応するアイコン定義についてリポジトリ20に問い合わせる。クエリは、リンク17を介してデバイス10からリポジトリ20へ送信され、このクエリは、スキンidまたはテーマid、およびアイコン定義が必要なアプリケーションのアプリケーションidから成っている。例えば、クエリはHTTPによって実行することもでき、クエリは次のようにフォーマットされる:

GET ICON APP_ID＝"483920432"
THEME_ID＝"http://www.nokia.com/classic/2004"

リポジトリ20はステップ4で、アイコン定義かまたはアイコン定義を取得できるURIを用いてデバイス10に応答する。例えば、アイコン定義そのものを返す応答は、次のようなフォーマットをとり得る:

OK ICON APP_ID＝"483920432"
THEME_ID＝"http://www.nokia.com/newtheme/2004" <icon_data>

アイコン・データは、異なる解像度の単数または複数の画像から形成されてもよく、SVG形式などの大きさに依存しない方法で定義されてもよい。必要であれば、デバイス10はステップ5で、ステップ4においてリポジトリ20からの応答内で提供されたURIから必要なアイコンを取り出し、またはそうでなければ、デバイス10は、リポジトリ20により与えられたアイコン定義を利用して、ユーザ・インターフェース15上に表示されるアイコンを更新し、ユーザ・インターフェース15に一貫した外観および印象を提供する。

なお、上記で明示された、デバイス10からのクエリの例およびそれに続くリポジトリ20からの応答は、要求を処理するのに必要な最小限の情報を示している。追加の情報をさらにクエリに含めて、適切なアイコン定義をさらに絞り込むことも可能である。例えば、アイコンの所望の表示解像度が要求と共に渡されることもあり得る。これは、デバイス10により望まれる細かさを判断するのに役立つと思われる。さらに、その他の関連したいくつかのデータが、各クエリまたは応答と共に渡されることもあり得る。

代わりの実施形態では、テーマに関連するスタイル情報についてデバイス10がリポジトリ20に問い合わせできる技術が提供される。上述のとおり、アプリケーションがデバイス10に読み込まれてそこで実行されると、アプリケーションに関連するアイコン定義データがデバイス10に常駐していないという状況がもたらされる可能性がある。このような状況になると、アイコン定義データを提供するようリポジトリ20が問い合わせられる。より一般的な意味では、デバイス10は、ユーザ・インターフェース15内へのレンダリングが必要であるが表示されているテーマに適合せず、指定のテーマについてリポジトリ20で定義されていない、種々の常駐のアプリケーション、アイコンおよびウィジェットを有することもある。このような場合は、初期設定のウィジェットおよび初期設定のアイコンなど、初期設定のユーザ・インターフェース要素のレンダリングが用いられることがよくある。初期設定の要素を使用すると、ビジュアル・デザイン要素、具体的にはユーザ・インターフェース要素の、魅力に欠ける混在状態がもたらされる可能性がある。

リポジトリ20にスタイル定義を格納することで、テーマの根底にある全般的な美観に関する構成を定義および格納することが可能である。一度定義すれば、スタイル定義を利用して、リポジトリ20で個別に定義はされていないが所望のテーマに全般的に一致する、アイコンまたはウィジェットなどのユーザ・インターフェース要素を生成できる。

図9を参照すると、スタイル定義の例示的な表項目が図示されており、これは例えばリポジトリ20の関係データベースに採用されることも考えられる。スタイルは、「2460」というidにより定義されている。表の他の列は、「2460」というスタイルidを有するスタイルが、テーマ・タイプ「classic」に適合することを示している。さらに、スタイルの全体的な美観に関する属性を定義する働きをする、全般的なスタイルの属性がいくつか含まれている。例えば、「rx」および「ry」は、種々のユーザ・インターフェース要素の曲率を定義する。それぞれが「0」という値を有するため、ユーザ・インターフェース要素は、四角い傾向にあることになる。同じように、他のユーザ・インターフェース要素は、「medium」といラインのストローク幅および「none」というダイアログ不透明度を有するよう定義されている。これらの属性は、全体のスタイルに関連しているように示されているが、要素ごとに定義されることも同じく可能である。例えば、コマンド・ボタンなどのユーザ・インターフェース要素が丸くなるよう指定される（button.command.rx＝high,button.command.ry＝high）一方、ラジオ・ボタンは四角くなるよう定義される（button.radio.rx＝0,button.radio.ry＝0）こともあり得る。

図10a〜10bを参照すると、ユーザ・インターフェース上で見られる可能性のある例示的なウィンドウ1001が図示されている。図10aを参照すると、「rx＝0」、「ry＝0」、「stroke width＝medium」および「dialog−opacity＝none」などのスタイルプロパティを含むスタイルが採用されている。全体的に四角い要素1003に注目されたい。反対に、図10bは、「rx＝medium」、「ry＝medium」、「stroke width＝thin」、および「dialog−opacity＝25％」などのスタイルプロパティを含む例示的なウィンドウ1001を図示している。全体的に丸い要素1003に注目されたい。

図11を参照すると、方法の論理流れ図が図示されており、この方法により、デバイス10によるスタイル定義およびデータの要求が可能であり、それに対しリポジトリ20によって応答される。通常、ステップ1で、ユーザ・インターフェースが更新されてテーマが取り入れられている。デバイス10が、スタイルにより定義されていないウィジェット、コントロール、アイコンまたは同様のものなどのユーザ・インターフェース要素を表示する必要がある場合、デバイス10はステップ2で、テーマに関連するスタイル定義を要求するクエリを形成する。

例えばクエリは、リンク17をとおして、次のとおりのHTTPフォーマットの要求という形で発行されてもよい:

GET STYLE THEME_ID＝"http://www.nokia.com/classic/2004"

ステップ3で、リポジトリ20は要求されたスタイル情報を検索し、応答をフォーマットする。例えば、スタイル情報を返す応答は、次のようなフォーマットをとることも可能である:

OK STYLE THEME_ID＝"http://www.nokia.com/newtheme/2004" <style_data>

ステップ4で、リポジトリ20からデバイス10へ応答が送信され、ステップ5でデバイス10が、スタイル定義データで指定されるとおりに、所望のユーザ・インターフェース要素の適切なユーザ・インターフェース設定を変更して、ここから一貫した新たな外観および印象を有するデバイスが与えられる。結果として、ここからは、テーマで定義されていなかったあらゆるユーザ・インターフェース要素を、リモート・リポジトリからのスタイルデータで指定されている変更を用いてレンダリングできる。

図13を参照すると、本発明を実践するシステムの例示的実施形態が図示されている。リポジトリ20は、少なくとも１つのデバイス10、およびユーザ・インターフェース要素の提供元130の両方と通信しており、好適には双方向通信している。このような構成では、ユーザ・インターフェース要素130の設計者および提供元は、その作成物を、多数のデバイス10により使用されるようにリポジトリ20に格納できる。

上述のとおり、本発明は移動局、特に移動電話で実践されてもよい。移動局（MS:mobile station）は、公衆交換電話網に組み合わされる基地局の移動電話網などの通信ネットワークに無線でアクセスできる、手持ち式の携帯デバイスである。セル式電話、ブラックベリー（Blackberry）（登録商標）・デバイス、およびインターネットまたはその他の相互通信機能を有する携帯情報端末（PDA）が、MSの例である。移動局のほかに、携帯無線機、および無線ローカル・エリア・ネットワーク（WLAN:wireless localized area network）またはWIFIネットワークなどのローカル・ネットワークのみにアクセスし得るデバイスなど、さらなる手持ち式のデバイスも、携帯用の無線デバイスに含まれる。

図12は、本発明が好適に配置され得る移動局MS121を、ブロック図の形式で図示する。これらのブロックは機能上のものであり、下記の機能は、図12を参照して説明されるように単一の物理的実態により実行されてもよく、されなくてもよい。ディスプレイ122、および、ユーザにより作動される一連のボタンから入力を受けるユニットなどの入力用ユーザ・インターフェース124が、ユーザと相互作用するために提供される。さらにMS121は、MS121内で機能を制御する中央処理装置128に電力を供給する内蔵型の電池などの電力源26を含む。処理装置128内には、デジタル抽出、間引き、補間、符号化および復号化、変調および復調、暗号化および復号化、拡散および逆拡散（CDMA準拠のMS121について）、および当該技術分野で知られているさらなる信号処理関数などの関数がある。

ディスプレイ122のドライバ、変調、符号化、複合化のアルゴリズム、ルックアップ表などのデータ配列、および同様のものなどのコンピュータ・プログラムは、主記憶装置媒体（main memory storage media）134に格納され、この主記憶装置ストレージ媒体134は、当該技術分野で知られているように、コンピュータ可読の命令およびプログラムならびにデータを格納する、電子、光学または磁気の記憶装置ストレージ媒体であればよい。本発明の例示的実施形態では、主記憶装置134に、本発明を実装するコンピュータ・プログラムが格納されている。

当然のことながら、本願明細書で説明された種々の例示的実施形態は、ハードウェアまたは専用回路、ソフトウェア、論理、またはそれらの任意の組み合わせに実装されるとよい。例えば、一部の態様がハードウェアに実装される一方、その他の態様が制御装置、マイクロプロセッサ、処理装置またはその他のコンピュータ・デバイスにより実行され得るファームウェアまたはソフトウェアに実装されてもよいが、本発明はこれらに限定されない。本発明の種々の態様は、ブロック図、流れ図として、または他の何らかの図的表現を使用して図示および表現できるが、当然のことながら、本願明細書で説明されたこれらのブロック、装置、システム、技術または方法は、限定する意味のない例として、ハードウェア、ソフトウェア、ファームウェア、専用回路もしくは専用論理、汎用ハードウェアもしくは汎用制御装置、またはその他のコンピュータ・デバイス、またはこれらの何らかの組み合わせに実装され得る。

本発明の代わりの例示的実施形態は、集積回路モジュールなどの種々の構成要素において実践され得る。集積回路の設計は、全般的にみて高度に自動化されたプロセスである。論理レベルの設計を、半導体基板上にすぐにエッチングおよび形成可能な半導体回路設計に変換するために利用できる複雑かつ強力なソフトウェア・ツールが複数ある。

カリフォルニア州マウンテン・ビュー（Mountain View, California）のシノプシス（Synopsys）（商標）社、およびカリフォルニア州サンノゼ（San Jose, California）のケイデンス・デザイン（Cadence Design）（商標）により提供されているようなプログラムは、確立された設計ルール、ならびに記憶済みの設計モジュールの非常に大きなライブラリを使用して、自動的に半導体チップ上に導体を経路付けし、構成要素を位置付ける。半導体回路の設計が完了すれば、結果として生じた設計が、製造用に半導体加工施設、すなわち「製造工場」へ、標準化された電子形式（例えばOpus、GDSII、または同様のものなど）で送信されればよい。

本発明の好適な実施形態であると現時点で考えられているものを図示および説明してきたが、当然のことながら、当業者が多数の変更および改変を思い付く可能性は高い。添付の特許請求の範囲では、特許請求の範囲に記載されている発明の意図および範囲に含まれる変更および改変すべてを対象とすることが意図されている。

Claims

ユーザ・インターフェース要素の定義を複数格納するリポジトリの処理手段が、プログラム命令に従って動作する方法であって、
リモート・デバイスに関するデバイス情報および前記リモート・デバイスのユーザ・インターフェースのテーマの識別情報を少なくとも含むクエリを、前記リモート・デバイスから受信することと；
前記受信した前記デバイス情報および前記テーマ識別情報に適合するウィジェット定義を、前記リポジトリ内で検索することと；
前記検索されたウィジェット定義を含む応答データを作成し、該応答データを前記リモート・デバイスへ送信することと；
を含む、方法。
前記応答データは、少なくとも１つのウィジェット定義の場所の情報を含む、請求項１に記載の方法。
前記クエリは、少なくとも１つのアプリケーション識別情報を含み、前記応答データは、少なくとも１つのアプリケーション・アイコン定義を含む、請求項１または２のいずれかに記載の方法。
前記クエリは少なくとも１つのスタイル定義を要求し、前記応答データはスタイルデータを含む、請求項１から３のいずれかに記載の方法。
ユーザ・インターフェース要素の定義を複数格納するリポジトリの処理手段に、請求項１から４のいずれかに記載の方法を実行させるプログラムコードを含む、プログラム。
リモート・デバイスに関するデバイス情報および前記リモート・デバイスのユーザ・インターフェースのテーマの識別情報を少なくとも含むクエリを、前記リモート・デバイスから受信する手段と；
前記クエリに応答して、前記受信した前記デバイス情報および前記テーマ識別情報に適合するウィジェット定義を、ユーザ・インターフェース要素の定義を複数格納する格納手段から検索する手段と；
前記検索されたウィジェット定義を含む応答データを作成し、該応答データを前記リモート・デバイスへ送信する手段と；
を有する、システム。
単一のサーバとして構成される、請求項６に記載のシステム。
デバイスの処理手段が、前記デバイスの記憶手段に格納されたプログラムの命令に従って動作する方法であって、
前記デバイスに常駐していない少なくとも１つのユーザ・インターフェース要素を要求するクエリであって、前記デバイスに関するデバイス情報および前記デバイスのユーザ・インターフェースのテーマの識別情報を少なくとも含むクエリを形成することと；
前記クエリを、ユーザ・インターフェース要素の定義を複数格納するリモート・リポジトリへ送信することと；
前記送信した前記デバイス情報および前記テーマ識別情報に適合するウィジェット定義を少なくとも含む応答を、前記リモート・リポジトリから受信することと；
前記デバイスのユーザ・インターフェースを、前記応答に応じて変更することと；
を含む方法。
デバイスの処理手段に、請求項８に記載の方法を実行させるプログラムコードを含む、プログラム。
デバイスに常駐していない少なくとも１つのユーザ・インターフェース要素を要求するクエリであって、前記デバイスに関するデバイス情報および前記デバイスのユーザ・インターフェースのテーマの識別情報を少なくとも含むクエリを形成する手段と；
前記クエリを、ユーザ・インターフェース要素の定義を複数格納するリモート・リポジトリへ送信する手段と；
前記送信した前記デバイス情報および前記テーマ識別情報に適合するウィジェット定義を少なくとも含む応答を、前記リモート・リポジトリから受信する手段と；
前記デバイスのユーザ・インターフェースを、前記応答に応じて変更する手段と
を含むデバイス。
移動電話である、請求項１０に記載のデバイス。