JP2007523421A - ユーザインターフェイスにおけるメニュー項目の表示 - Google Patents

Abstract

【課題】ユーザインターフェイスにおけるメニュー項目の表示
【解決手段】デバイスのためにユーザインターフェイス（ＵＩ）が提供される。そのユーザインターフェイスは、ＵＩのリージョン（ｒｅｇｉｏｎ）内で表示するには大きすぎる要素のリストを生成する。表示されるべきリスト要素の数が判別され、そして、生成された要素のリストからリスト要素の適切なサブセットが選択される。
【選択図】図１

Description

本発明は、ユーザインターフェイスにおけるメニュー項目を表示する方法、特に移動通信ネットワークと共に使用されるデバイス用の方法に関する。

多くのモバイルデバイスにおいて共通する制限の１つは、表示スクリーンが相当に小さく、メニューが表示される際に、常にそのスクリーンにメニュー項目のすべてを一度に表示することは可能ではないことである。従来のアプローチは、関連付けられたアイコンあるいはグラフィックと共に、メニュー項目のすべてをメモリに読み込み、ユーザがメニューをスクロールアップあるいはスクロールダウンするにつれて、それらを適切に表示する傾向がある。このアプローチは、移動体電話のようなリソースが限られているデバイス、及びデバイスのディスプレイを描画するため、及び／あるいは、そのデバイス用のオペレーティングソフトウェアを提供するためにマークアップ言語を使用するデバイスにとっては効率的な技法ではない。

〔発明の概要〕
本発明の第１の観点によれば、ユーザインターフェイスにおける複数のユーザインターフェイス要素のサブセットを表示する方法であって、前記方法は（ｉ）前記ユーザインターフェイス内で表示されうる複数のユーザインターフェイス要素のサブセットのサイズを判別し、（ｉｉ）前記ユーザインターフェイス内での表示のために選択される可能性のある複数のユーザインターフェイス要素を判別し、（ｉｉｉ）ステップ（ｉｉ）において判別された前記複数のユーザインターフェイス要素からユーザインターフェイス要素のサブセットを選択し、（ｉｖ）ステップ（ｉｉｉ）において選択された前記ユーザインターフェイス要素のサブセットを表示する、ステップを備える方法が提供される。ステップ（ｉｉｉ）はユーザ入力に応答してユーザインターフェイス要素の更なるサブセットを選択できるように繰り返されてもよく、その時ステップ（ｉｖ）はユーザインターフェイス内で前記ユーザインターフェイスの更なるサブセットを表示できるように繰り返される。

本発明の第２の観点によれば、上記方法の何れかを実行する、計算機で実行可能な符号を備えるデータキャリアが提供される。

本発明の第３の観点によれば、ディスプレイとユーザインターフェイスとを備える装置であって、前記装置は使用において、（ｉ）前記ユーザインターフェイス内で表示されうる複数のユーザインターフェイス要素のサブセットのサイズを判別し、（ｉｉ）前記ユーザインターフェイス内での表示のために選択される可能性のある複数のユーザインターフェイス要素を判別し、（ｉｉｉ）ステップ（ｉｉ）において判別された前記複数のユーザインターフェイス要素からユーザインターフェイス要素の前記サブセットを選択し、（ｉｖ）前記ユーザインターフェイス内にステップ（ｉｉｉ）において選択されたユーザインターフェイス要素の前記サブセットを表示するように構成されている装置を提供する。

本発明の第４の観点によれば、プロセッシング手段と、格納手段と、ディスプレイと、ユーザ入力手段と、無線通信手段と、ユーザインターフェイスとを備える装置であって、前記装置は上述の方法うちの何れかの方法を実行するように構成された装置が提供される。

詳細な発明の記述

図解のみ及び図解と付属する図面を経由して発明が記載されている。図１は本発明を具体化したシステムの概略的な描写を示す。そのシステムは、サーバ１００と、コンテンツツールセット２００と、複数のモバイル装置３００と、運用サポートシステム（ＯＳＳ）７００と、コンテンツフィード（ｃｏｎｔｅｎｔ ｆｅｅｄ）５００とユーザインターフェイス（ＵＩ）ソース（ｓｏｕｒｃｅ）６００とから構成される。使用において、サーバ１００はモバイル装置３００、３０１、・・・とコンテンツデータ及びＵＩデータを通信する。モバイル装置３００、３０１、・・・のそれぞれは、ソフトウェアパッケージ４００から構成される。サーバ１００は、ＯＳＳが、例えば、広告、アカウント管理、等のモバイルネットワークに作用するために伝統的に使用される状態で、ＯＳＳ７００とインターフェイスする。サーバ１００はさらにコンテンツツールセット２００とインターフェイスする。前記コンテンツツールセットはＵＩソース６００、６０１、・・・からデータを受信し、前記サーバがモバイル装置３００内に構成されたソフトウェアパッケージ４００にまとめられたＵＩデータを送信できるように、ＵＩデータを一まとめにする。前記サーバは複数のコンテンツフィードからデータを受信し、このデータが処理され、ソフトウェアパッケージ４００に送信されうるように、あるいはモバイル装置３００がソフトウェアパッケージ４００を用いてそのデータにアクセスできるように、一まとめにされる。

前記システムは、モバイルネットワークオペレータ（ＭＮＯ）により運用されるシステムと装置とから構成されるオペレータドメイン５０と、複数のモバイル装置から構成されるユーザドメイン６０と、多数の異なるエンティティにより制御あるいは操作される可能性のあるコンテンツフィードとＵＩフィードとから構成されるサードパーティドメイン７０との、３つの異なるドメインに分割されるものと想定できる。

図２はサーバ１００の構造と動作とを極めて詳細に描いている。サーバ１００は、パブリッシングコンポーネント１１０と、コンテンツサーバコンポーネント１５０とから構成される。パブリッシングコンポーネントは、データベース１１１と、インポートキュー１１２と、コンテンツツールセットインターフェイス１１３と、ユーザインターフェイス１１４と、カタログ１１５とから構成される。動作中、前記パブリッシングコンポーネントはコンテンツツールセットインターフェイスでコンテンツツールセットからコンテンツ（ｃｏｎｔｅｎｔ）を受信する。このコンテンツは１あるいは２以上のｔｒｉｇと１あるいは２以上のｔｒｉｇｌｅｔからなる（下記参照）パーセル（ｐａｒｃｅｌ）２１０ａ、２１０ｂ、・・・の形式で表現される。ｔｒｉｇは移動体電話のようなモバイル装置用のユーザインターフェイスであり、ｔｒｉｇｌｅｔはｔｒｉｇを拡張あるいは変更するために使用されうるデータファイルである。もし、パーセルが２以上のｔｒｉｇからなる場合は、ｔｒｉｇのうちの１つは他のｔｒｉｇから得られるマスターｔｒｉｇである可能性がある。

図３は、モバイル装置３００用のソフトウェア４００の概略的な描写を示す。ソフトウェア４００は、マークアップ言語レンダラ（ｒｅｎｄｅｒｅｒ）４１０と、更新マネージャ４２０と、ネットワーク通信エージェント４２５と、リソースマネージャ４３０と、仮想ファイルシステム４３５と、アクターマネージャ４４０と、複数のアクター４４５ａ、４４５、・・・と、ネイティブＵＩレンダラ４５０と、サポートマネージャ４６０と、ｔｒｉｇマネージャ４６５と、マークアップ言語パーザ４７０とから構成される。

前記ソフトウェアがＸＭＬアプリケーションであるＴｒｉｇＭＬを用いて動作し、マークアップ言語レンダラ４１０がモバイル装置３００上での表示のためにＴｒｉｇＸＭＬコードを図に表現することが望ましい。前記マークアップ言語レンダラはＴｒｉｇＭＬパーザを使用して、ＴｒｉｇＭＬリソースを解析し、デバイススクリーン上にコンテンツを表示し、ハンドセット上のコンテンツの交換とビューイング（ｖｉｅｗｉｎｇ）とを制御する。前記ネイティブＵＩレンダラは、ＴｒｉｇＭＬを使用することなく表示されうるＵＩコンポーネントを表示するため、及びエラーメッセージを表示するため使用される。

ソフトウェア４００はデバイスに特有な方法で用意されインストールされる。例えば、Ｎｏｋｉａ社のＳｅｒｉｅｓ ６０のデバイスでは、ＳＩＳファイルを用いてソフトウェアがインストールされる一方、マイクロソフト社のＳｍａｒｔｐｈｏｎｅのデバイスではＣＡＢファイルを用いてソフトウェアがインストールされる。同様に、ソフトウェアのアップグレードはデバイスに特有な方法で処理される。アップグレードは空中を伝わって提供される可能性がある。そのソフトウェアは、例えば、コンテンツのみの内でそのビルト（ｂｕｉｌｔ）を表現する自己完結したアプリケーション、すなわちそのアプリケーションと共に供給されたｔｒｉｇに後で追加のｔｒｉｇが追加されえないアプリケーション、のように、より制限されたフォーマットで用意される可能性がある。

ｔｒｉｇマネージャ４６５はリソースマネージャ４３０と前記マークアップ言語レンダラとのインターフェイスを提供する。それは一般にｔｒｉｇの管理に責任を持つ。これは、使用中のｔｒｉｇの知識の持続と、現在のｔｒｉｇの変更と、起動時のｔｒｉｇの選択と、壊れたｔｒｉｇ用のフォールバックとしての更なるｔｒｉｇの選択と、インストールされたｔｒｉｇの集合の維持と、ｔｒｉｇのアップデートチャネル定義の読み込みと、更新マネージャの適切な構成とを含む。

前記リソースマネージャはデバイス上の永続的な記憶の抽象化、すなわちファイルを真のファイルとしてあるいはデータベースのレコードとして格納することを提供する。リソースマネージャはマークアップ言語レンダラと更新マネージャとのファイルシステムインターフェイスを提供する。リソースマネージャは、ファイルパスのロジックの取り扱いと、真のリソースファイルとアクター属性との区別と、ｔｒｉｇ相対パスの絶対パスへのマッピングと、ｔｒｉｇマネージャとのインターフェイシング（ｉｎｔｅｒｆａｃｉｎｇ）と、更新マネージャへ修正インターフェイスの提供とに責任を持つ。

リソースマネージャはまた、特にデバイスパワーのロス（ｌｏｓｓ）のような予見不可能な中断に直面した際の、永続的な記憶に格納されたリソースの整合性の保証にも責任を持つ。リソースマネージャは現在使用されているｔｒｉｇの知識を持たない。そのインターフェイスはスレッドセーフ（ｔｈｒｅａｄ ｓａｆｅ）である。（なぜなら、異なるスレッド（ｔｈｒｅａｄ）から更新マネージャとレンダラとの双方により使用される可能性があるからである。）
前記更新マネージャはｔｒｉｇとｔｒｉｇｌｅｔとの受け取りと適用とを扱う。更新マネージャはレンダラとｔｒｉｇマネージャとのインターフェイスを提供し、レンダラにより指示された際の手動更新の開始とｔｒｉｇマネージャにより、そのように構成される際の自動更新チャネルの制御及び実現と、手動更新の進捗状況の表示と、ネットワークコネクション、及び／あるいは、デバイス電源の予期しないロスを伴った更新の回復とに責任を持つ。行進用のパケットのフォーマットはＸＭＬスキーマのバイナリシリアライゼーションとして定義される可能性がある。

前記サポートマネージャはイベントあるいはエラーの発生を報告するため他のコンポーネントのためのインターフェイスを提供する。エラーの深刻度に依存して、サポートマネージャはイベントを記録、及び／あるいは、エラーメッセージポップアップの提示をするであろう。

アクターマネージャ４４０はソフトウェア内にあるアクターの集合の面倒を見る。コンテンツがアクターにイベントを送信しているレンダラと、属性値が変更されたことを知らせたいアクターと、イベントを発行したいアクター（下記を参照のこと）とにより、それは使用される。

前記ソフトウェアは、どれだけのアクターが、またどの種類のアクターが含まれるかに依存してより多くなる可能性のある、最低２つのスレッドが実行されるマルチスレッドアプリケーションで構成される可能性がある。ソフトウェアは主としてメインスレッドとして言及する１つのスレッドで実行する。メインスレッドは、他のコンポーネントと同時に通信するレンダラを実行するために使用される。アクターは常にレンダラとのシンクロナスインターフェイスを有する。もし、アクターがその機能のために追加のスレッドを要求する場合、スレッド相互間の通信を管理するのはそのアクターの責任となる。多くのアクターがスレッド相互間の通信を要求するような場合では、不要なコード重複を避けるため、軽量メッセージングフレームワークが使用されることが望ましい。

メインスレッドに加えて、更新マネージャはネットワークスレッドを実行する。ネットワークスレッドは更新パケットをダウンロードするために使用され、そのパケットが到着するまでレンダラが影響されずに続けられるようにメインスレッドから分離されている。更新マネージャは、更新パケットで定義された変更を適用する際に更新マネージャがレンダラとリソースマネージャと同時に通信できるように、スレッド相互間のメッセージングを取り扱うことへの責任を持つ。

ソフトウェアのメモリ割り当て戦略はプラットフォームに特有である。ＭＩＤＰプラットフォームにおいて、ソフトウェアは単にすべてのメモリ要求のために、システムヒープとガベージコレクタとを使用する。ガベージコレクションを予測可能な状態に維持し、動作中の予期しない休止を被らないための試みにおいて、コンテンツの置換イベントが発生するときはいつでもガベージコレクションが強制される。あらゆるメモリ割り当てに失敗することが想定される、その場合においては、そのソフトウェアがオブジェクトへのすべてのその参照を削除し、ガベージコレクト（ｇａｒｂａｇｅ ｃｏｌｌｅｃｔ）し、そのソフトウェアがすでに立ち上がりに成功し、最初のページを表現したことが想定を再スタートする。

Ｃ＋＋を基盤とするプラットフォーム上では、システムヒープからの事前割当とオンデマンド割り当てとの混合がなされるであろう。立ち上げ用に要求されたすべてのメモリは立ち上げの間オンデマンドに割り当てられ、ここでのあらゆる停止はソフトウェアの終了（可能であれば、メッセージを伴う終了）を引き起こす。立ち上がりが正常に終了すると、コンテンツ文書モデルの表現のために必要とされるメモリが事前割当される。提供されたコンテンツは定義された上限以下の使用が認め（ａｕｔｈｏｒ）られ、表現されることが保証される。そのソフトウェアの速い動作のために必要とされる様々なキャッシュ用にＲＡＭの追加的な使用がされる。メモリの状況が低い場合、これらのキャッシュが解放され、ソフトウェアからの低レンダリング性能に帰結する。

前記レンダラ（Ｒｅｎｄｅｒｅｒ）はキーの押下に関する情報を受け取る。あるキーのためにビルド時（ｂｕｉｌｄ ｔｉｍｅ）に構成された振る舞いがない場合、それは現在フォーカスしている要素に対し、ＴｒｉｇＭＬコンテンツイベントとして送信される。そして、そのコンテンツイベントはＴｒｉｇＭＬの通常のイベント処理ロジックにより定義されたものとして取り扱われる。

例えば、あるキーが押下された場合、関係のあるキーに対するパラメータセットと共に‘ｋｅｙｐｒｅｓｓ’イベントがレンダラに配達される。そのキーが離された際に、‘！ｋｅｙｐｒｅｓｓ’イベントがそのレンダラに配達される。あるキーがある長い期間の間押下したままにした場合、‘ｌｏｎｇｋｅｙｐｒｅｓｓ’イベントがそのレンダラに配達される。そのキーが離されると、‘！ｌｏｎｇｋｅｙｐｒｅｓｓ’イベントと‘！ｋｅｙｐｒｅｓｓ’イベントとがそのレンダラに配達される。

前記ソフトウェアが開始されたときはいつでも、以下のアクションを実行する。

・中断された更新処理をチェックし、継続する。

・（とある他の手段によりそのファイルシステムに、前もって供給されたか、インストールされたか）ファイルシステム内にある更新をチェックし、処理する。

・もし知っている場合、（最後に実行したｔｒｉｇである可能性がある）カレントなｔｒｉｇを開始する。

・もし、カレントなｔｒｉｇが設定されていない場合、‘デフォルト’ｔｒｉｇとしての印が付けられているｔｒｉｇが開始されうる。

・デフォルトのｔｒｉｇの存在がない場合、アルファベット順で最初に有効なｔｒｉｇが選択されるであろう。

ｔｒｉｇは定義されたリソース名ｓｔａｒｔ−ｕｐ／ｄｅｆａｕｌｔを読み込むことで開始される。ｓｔａｒｔ−ｕｐ／ｄｅｆａｕｌｔで定義されたＴｒｉｇＭＬはコンテンツのルートノード用の新たなコンテンツとして構文解析（ｐａｒｓｅ）される。

インストールの後で初めてｔｒｉｇが前記ソフトウェアにより実行される時、そのｔｒｉｇはリソース名ｓｔａｒｔｕｐ／ｆｉｒｓｔｔｉｍｅを読み込むことにより開始される。そのソフトウェアはｔｒｉｇがそのｔｒｉｇ用のトップレベルフォルダ内に位置するファイル内で実行されるか否かを記録する可能性がある。モバイル装置により使用されるプラットフォームに依存して、ソフトウェアの自動立ち上げがビルド時の構成オプションとして設定されている可能性がある。さらに、自動立ち上がりの後、そのソフトウェアがバックグラウンドに置かれることもビルド時の構成オプションである可能性がある。

ランチャはアプリケーションアイコンとしてユーザに対して現れる可能性があり、それが選択されるとそのランチャにより指定されたｔｒｉｇと共に前記ソフトウェアが開始する。（このｔｒｉｇはランチャのアイコン、及び／あるいは、名前により示される可能性がある。）ｔｒｉｇを開始するためにランチャを使用する際には、‘ｅｎｔｒｙ ｐｏｉｎｔ’パラメータを指定することができる。そのパラメータは‘ｓｔａｒｔ−ｕｐ’フォルダに見られるファイルのリソース名である。このファイルはそのｔｒｉｇが以前に実行されていない場合には使用されず、この場合代わりに‘ｆｉｒｓｔｔｉｍｅ’と呼ばれるファイルが使用される。

前記ソフトウェアはデバイス上の仮想ファイルシステム内に格納されたコンテンツリソースファイルを使用する。伝統的なファイルシステムとして実現されない可能性があるため、そのファイルシステムは可能的なものとして記述されるが、リソースに対するすべての参照は、まるでフォルダとファイルとの階層的システム内に格納されているかのように、ファイルパスである。さらに、そのソフトウェアは以下の情報のうちのいくつかあるいはすべてを格納する：利用統計、アクティブなユーザのカウント値、ＴｒｉｇＭａｎａｇｅｒの状態、（バイナリＸＭＬとしてシリアライズされた）ＴｒｉｇＭＬフラグメント及び更新チャネルの定義、ＰＮＧ画像、ＵＴＦ−８ ＯＴＡで符号化された後プラットフォームに特有な符号で格納されたプレインテキスト、例えば呼出音（ｒｉｎｇ ｔｏｎｅ）ファイルのような他のプラットフォームに特有なリソース、背景画像、等。

アクター属性値が変化した際、あるいはｔｒｉｇｌｅｔによりファイルが置き換えられた際に、ファイルシステム内のファイルは変更されうる。／ａｔｔｒディレクトリ内のファイルが変化した際には、前記レンダラは直ちに通知され、コンテンツツリーの関連する枝が更新されリフレッシュされる。画像リソースとテキストリソースとが変化した際には、レンダラは影響を受けたリソースが直ちに再読み込みされた（コンテンツツリーの全体あるいは影響を受けた枝だけがリフレッシュされる可能性がある）かのように振舞う。ＴｒｉｇＭＬフラグメントが変化した際には、レンダラは通知されておらず、旧式になった可能性のある現在のコンテンツを表示し続けるかのように振舞う。これは、そのソフトウェアが現在のコンテンツの＜ｉｎｃｌｕｄｅ＞要素と＜ｌｏａｄ＞ヒストリとを持続する必要性を避けるためである。

ソフトウェア４００はデバイスの特有な方法でモバイル装置内に供給される。１あるいは２以上のｔｒｉｇがインストールの一部、例えば圧縮されていない更新パケットとして供給されうる。立ち上がり時に、そのパケットは伸張されファイルシステムにインストールされる。

アクター４４５は属性値を発行し、イベントを取り扱い、イベントを発するコンポーネントである。アクターはレンダラと同時に通信する。もし、アクターが非同期に振舞う必要がある場合には、そのレンダラのメインスレッドの外部のスレッドとの管理と通信とはそのアクターの責任である。

多くのモバイル装置に共通する制限の１つは、ディスプレイスクリーンがかなり小さく、メニューが表示される際に、常にそのスクリーンにメニュー項目のすべてを一度に表示できるわけではないことである。従来のアプローチは、関連付けられたアイコンあるいはグラフィックと共に、メニュー項目のすべてをメモリに読み込み、ユーザがメニューをスクロールアップあるいはスクロールダウンするにつれて、それらを適切に表示する傾向がある。このアプローチは、移動体電話のようなリソースが限られているデバイス、及びデバイスのディスプレイを描画するため、及び／あるいは、そのデバイス用のオペレーティングソフトウェアを提供するためにマークアップ言語を使用するデバイスにとっては効率的な技法ではない。

これらのメニュー項目がそのデバイスにより同時に表示されうるように、メモリに読み込まれるべきメニュー項目の数を制限することを可能にする効率的な技法を提供することにより、この問題が処理される。ユーザがメニューをスクロールアップまたはスクロールダウンした場合、もはやディスプレイにない項目は廃棄され、現在ディスプレイ上にある項目がメモリに読み込まれる。

好ましくは、これは、あるデータのリストビューを定めるためＴｒｉｇＭＬにおける＜ｇｒｉｄｄａｔａ＞要素を使用することで実現されうる。ここで、そのデータはファイルシステム内のフォルダに格納され、リストの外観は各項目に対し同一の構造を持つ。＜ｇｒｉｄｄａｔａ＞要素はそのデータが置かれうるフォルダで指定する１個の‘ｒｅｐｅａｔ−ｏｖｅｒ’属性を有する。＜ｇｒｉｄｄａｔａ＞の単一の子要素はそのリスト内の各項目の出現に関するテンプレートである。

テンプレートは特別な記号（例えば‘＄＄’をイテレータ（ｉｔｅｒａｔｏｒ）として参照する）を使用する可能性がある。これは、テンプレートが実体化（ｉｎｓｔａｎｔｉａｔｅ）される度に変化するテンプレート変数である。例：
＜ｇｒｉｄｄａｔａ ｒｅｐｅａｔｏｖｅｒ＝“ｎｅｗｓ／ｈｅａｄｌｉｎｅｓ”＞
＜ｔｅｘｔ ｒｅｓ＝“ｎｅｗｓ／ｈｅａｄｌｉｎｅｓ／＄＄／ｔｉｔｌｅ．ｔｘｔ”／＞
＜／ｇｒｉｄｄａｔａ＞
ｗｈｅｒｅｔｈｅｆｏｌｄｅｒｎｅｗｓ／ｈｅａｄｌｉｎｅｓ／ ｃｏｎｔａｉｎｓ：
０／ｔｉｔｌｅ．ｔｘｔ
１／ｔｉｔｌｅ．ｔｘｔ
２／ｔｉｔｌｅ．ｔｘｔ
３／ｔｉｔｌｅ．ｔｘｔ
これは、それぞれが‘ｎｅｗｓ／ｈｅａｄｌｉｎｅ／＄＄’フォルダ内の‘ｔｉｔｌｅ．ｔｘｔ’リソースを指している単純な＜ｔｅｘｔ＞要素により記述された、４項目のリストを表示しようとする。リソースデータがその中にディスプレイ上での＜ｇｒｉｄｄａｔａ＞要素が持つ余裕以上の項目を持つ場合、その＜ｇｒｉｄｄａｔａ＞要素は表示されうる項目のみを表示する。ユーザがリストをスクロールした際に、＜ｇｒｉｄｄａｔａ＞要素は‘ｄａｔａ−ｗｉｎｄｏｗ’を適宜シフトさせる。この技法の利点は現在のディスプレイに要求されているリソースのみが現実にメモリに読み込まれ、メモリの利用を減らし、項目のリストを表現するためにかかる総時間を減らすことである。

リストが表示される順序を定めるために、同様のスキームが使用されうる。‘ｒｅｐｅａｔ−ｏｖｅｒ’属性のターゲットがフォルダの代わりにファイルである場合、そのファイルは、繰り返して使用するためリソース名のリストを含むことが仮定される。例えば、
＜ｇｒｉｄｄａｔａ ｒｅｐｅａｔｏｖｅｒ＝“ｆｏｏｔｂａｌｌ／ｌｅａｇｕｅ”＞
＜ｔｅｘｔ ｒｅｓ＝“ｆｏｏｔｂａｌｌ／ｔｅａｍｓ／＄＄／ｎａｍｅ．ｔｘｔ”／＞
＜／ｇｒｉｄｄａｔａ＞
ｗｈｅｒｅ ｔｈｅ ｆｉｌｅ ｆｏｏｔｂａｌｌ／ｌｅａｇｕｅ ｃｏｎｔａｉｎｓ：
Ｍａｎｃｈｅｓｔｅｒ
Ａｒｓｅｎａｌ
Ｃｈｅｌｓｅａ
ｔｈｅ ｆｏｌｄｅｒ ｆｏｏｔｂａｌｌ／ｔｅａｍｓ／ ｃｏｎｔａｉｎｓ：
Ｍａｎｃｈｅｓｔｅｒ／ｎａｍｅ．ｔｘｔ
Ａｒｓｅｎａｌ／ｎａｍｅ．ｔｘｔ
Ｃｈｅｌｓｅａ／ｎａｍｅ．ｔｘｔ
で、各ｎａｍｅ．ｔｅｘｔはチーム名を保持するテキストファイルである。この結果は、チームに関連付けられたテストファイルが、定義された順序でデバイスディスプレイの定義されたエリア内に表示されるであろうということである。

３つのエントリから構成されるリストを持ち、表示される予定である姓データとファーストネームデータとのリストをもたらすテンプレートを持つ、この更なる例が以下で与えられる。

＜ｇｒｉｄｌｉｓｔ ｉｄ＝“ｍｙＬｉｓｔ” ｒｅｐｅａｔｏｖｅｒ＝“ｐａｔｈ／ｔｏ／ｌｉｓｔ” ｒｏｗｓ＝“３”＞
＜ｇｒｏｕｐ＞
＜ｔｅｘｔ ｒｅｓ＝“＄＄／ｓｕｒｎａｍｅ”／＞
＜ｔｅｘｔ ｒｅｓ＝“＄＄／ｆｉｒｓｔｎａｍｅ”／＞
＜／ｇｒｏｕｐ＞
＜／ｇｒｉｄｌｉｓｔ＞
このアプローチは、リストが他のリスト内でネストされうるように拡張されうる。上述のアプローチに従えば、多数の異なるリストが存在する場合に、‘＄＄’演算子がどのリストを参照しているかに関する曖昧さが存在する。この問題は、例えば
｛／ｅｌｅｍ／ｍｙＬｉｓｔ／ｉｎｄｅｘ｝
のような、それが参照しているリストをユニークに識別している表現で‘＄＄’を置き換えることにより処理される。

リストにユニークに参照できるようにしている他に、このアプローチは、項目が現実にそのリストの中にないリストを参照できるようにする。例えば、ウィンドウのタイトルバーは、リスト内で選択された項目に関係するテキストを含むことが可能で、そのタイトルバー内のテキストはリストがスクロールされるにつれて変更されうる。

データがファイルシステム以外の手段、例えばそれがデータベースに格納されている、あるいは、別のソフトウェアコンポーネントによりデータがオンザフライ（ｏｎ ｔｈｅ ｆｌｙ）で生成されている場合、ファイルシステムのインターフェイスがそのデータの根本的な（ｕｎｄｅｒｌｙｉｎｇ）プロバイダにマッピングされうる仮想ファイルシステム４３５が使用されている場合このスキームはいまだ使用されうる。これは、そのコンテンツがいまだ上述したように配置されうるが、そのデータが効率的なデータ記憶とデータ検索とを可能にする方法で提供されうることを意味する。

ＯＴＡを送信された更新は前記ソフトウェアにより始められたＨＴＴＰ−ＧＥＴリクエストを用いてフェッチされうる。このＧＥＴリクエストはその更新に関連付けられたＵＲＬに向けられる。ＨＴＴＰ応答の本体はアップデートパケットフォーマットでデータを運んでいるバイナリファイルである。データの受け取りは、レンダラスレッドとは別個のスレッドで処理される。（自動的に開始された）バックグラウンドの更新にとって、このことはユーザがＵＩを操作し続けることを可能にする。（手動で開始された）フォアグラウンドの更新にとって、このことはレンダラスレッドがプログレスバーを表示しキャンセルの指示を聞くことを可能にする。

更新をアンパックしインストールするために使用されるアルゴリズムはデバイスに特有である。しかし、そのアルゴリズムが、ファイルシステムにおいて改変された状態あるいは修復不可能な状態に到達しないように、予期しない中断（例：パワーロス）から安全であることが重要である。これは、ゴールと共に２つのスレッド（ネットワークスレッドとレンダラスレッド）を用いて達成される可能性がある。該ゴールは最小の可能な時間の間レンダラスレッドを中断するようにネットワークスレッドにより実行されることを可能とする多くの更新処理を持つことである。

他の故障モードが考えられる。ＨＴＴＰ−ＧＥＴが開始されえない場合、あるいはＨＴＴＰ−ＧＥＴがＨＴＴＰエラー応答コードと合致する場合、更新時のこの試みは放棄され、後刻新たな更新の試みが開始されるという再試行戦略が用いられる。ＨＴＴＰ応答がネットワーク信号の消失により中断された場合、あらゆる一時ファイルが削除され後刻更新の試みが再開されるという再試行戦略が使用される。更新ヘッダがアップデートペイロードの大きさがデバイスに適合させるには大きすぎる可能性があることを示していた場合、あるいはその更新がソフトウェアの非互換バージョンを要求した場合、あるいはその更新がすでにデバイス上に存在する場合、そのヘッダデータは削除され更新の試みとあらゆるその後の再試行とは中止される。

ＴｒｉｇＭＬフラグメントは、ｔｅｘｔ ＴｒｉｇＭＬを有するファイルであり、及びそれらのフラグメント内部のリソース参照は仮想ファイルパスである。これらの仮想ファイルパスの実ファイルパスへのマッピングはＴｒｉｇＤｅｆｉｎｉｔｉｏｎファイルにより定義される。このファイルはｔｒｉｇの他の特性をも定める。ｔｒｉｇｌｅｔをコンパイルするために使用される際には、このファイルは入力されたＴｒｉｇＭＬ／ＰＮＧ／Ｔｅｘｔリソースをどのようにｔｒｉｇの仮想ファイルシステムの変更（ｍｏｄｉｆｉｃａｔｉｏｎ）にマッピングするかも定める。

モバイル装置のユーザインターフェイスをうまく表現するために、マークアップ言語は以下の特性を持たなければならない。簡潔なページ定義、一貫性のあるレイアウト規則、コンパクトなレンダラ中の実装可能性、複数のレイヤリングと任意のオーバラッピングコンテンツとの提供、イベントモデル、ＵＩのページ間で変更しなければならないディスプレイエリアのみの再描画の要求、プロパティ値の読み出しとイベントの受信とイベントの送信とのためのプラットフォームに対するフックのインクルード、拡張容易性、グラフィカルな柔軟性。これらの特性と、望ましい機能性を提供する要素と属性との外観とを提供するＴｒｉｇＭＬは、２００４年２月１９日に出願した我々の同時係属中の出願、ＧＢ０４０３７０９．９に見ることができよう。

ＵＩを再び刻みつける（ｒｅ−ｂｒａｎｄ）コストと更新の継続的なストリームを生み出すコストとを最小化することが望ましい。これは、創造的なプロセスからユーザへのデータの伝達への情報の効率的なフローを提供することにより可能となる。パーセルとして言及されるコンテナは、サードパーティの係わり合い（ｉｍｖｏｌｖｅｍｅｎｔ）のため、テンプレートと、ＵＩｓと、ＵＩの更新とのために使用される。パーセルはサードパーティが刻みつけられた（ｂｒａｎｄｅｄ）ＵＩと更新とを生み出し、テストし、引き渡すために必要となるすべての情報を含む。

共通の基底（ｂａｓｅ）から多くの異なるＵＩが派生させられうる。典型的には、共通の基底はほとんどのインターフェイスそれ自身を実現するであろうし、それから派生したｔｒｉｇは例えば刻みつけのように、その上で些細な変化を実現するであろう。ＴｒｉｇｌｅｔはＴｒｉｇから派生されうる。そして、（任意には自身のリソースから導入される可能性のある）それが選択する親のＴｒｉｇからのリソースの何れかがオーバーライドされうる。ここで、「リソース」がＴｒｉｇＭＬに指し示すことにも注意すれば、Ｔｒｉｇの振る舞いとレイアウトとは単一の画像あるいは一片のテキストを置き換えるのとちょうど同じくらい容易にＴｒｉｇｌｅｔにより変更されうる。

パーセルは１または２以上の基本ｔｒｉｇ（すなわち、何れかの他のｔｒｉｇから派生させられないＴｒｉｇ）と、基本Ｔｒｉｇから派生した１または２以上の、複数のｔｒｉｇと、ｔｒｉｇの何れかと他のｔｒｉｇｌｅｔから派生した複数のｔｒｉｇｌｅｔとから派生した複数のｔｒｉｇｌｅｔとから構成される可能性がある。

パーセルのフォーマットはこのすべての情報をシリアライズされたオブジェクトとして格納する不透明なバイナリフォーマットである。パーセルは、画像、テキスト、ＵＲＬｓ、更新チャネル、呼出音ファイル、壁紙、ネイティブアプリケーション、等のような、多数のリソースを有する可能性がある。各リソースは、そのリソースの閲覧、編集、削除の方法に関するパーミッション（ｐｅｒｍｉｓｓｉｏｎ）情報を含む。パーセルは、ディスプレイサイズやＲＡＭ容量のような異なる能力を持つモバイル装置向けにｔｒｉｇ、及び／あるいは、ｔｒｉｇｌｅｔを開発するために使用される可能性がある。これを単純化するため、多数の階層が定義される可能性があり、その階層内でデータリソースあるいはＴｒｉｇＭＬ要素とが分類される可能性がある。ｔｒｉｇあるいはｔｒｉｇｌｅｔがパーセルからコンパイルされる際に、もっとも適切なリソースあるいはＴｒｉｇＭＬ要素がある特定デバイス用に選択されコンパイルされうる。

図４は、本発明の実施形態にかかるユーザインターフェイスを含むデバイス８００の概略的な描写を示す。このデバイスは、ユーザインターフェイス８１５を表示するディスプレイ８１０と、ユーザがユーザインターフェイス８１５と互いに影響を与えられるようにするユーザインターフェイス手段８２０とを含む。プロセッサ８３０は、１あるいは２以上の記憶手段８４０内に格納された前記ソフトウェアを実行する。他のデバイス、及び／あるいは、通信ネットワークと通信できるようにする１または２以上の無線通信インターフェイス８５０が存在する可能性がある。電力、及び／あるいは、通信ケーブルを受け入れるためのインターフェイスを含む可能性もある、前記デバイスに動力を供給するために１または２以上のバッテリ８６０が受け入れられる可能性がある。

これらのコンポーネントとインターフェイスとの性質はそのデバイスの性質に依存することになろう。それは、そのようなユーザインターフェイスがモバイルハンドセットあるいは携帯電話ハンドセット内部に実現されうること、しかしながら、例えばデジタルカメラ、パーソナルデジタルオーガナイザー、デジタル音楽プレーヤ、ＧＰＳナビゲータ、ポータブルゲームコンソール、等のような他のポータブルデバイスにも適用可能であることが理解されよう。さらに、ラップトップコンピュータやデスクトップコンピュータのようなユーザインターフェイスを含む他のデバイスにも適用可能である。

上記ユーザインターフェイス手段は、数字キーボードあるいは英数字キーボードのような複数のボタン、もしくはタッチスクリーンあるいは類似のものから構成される可能性がある。１あるいは２以上の記憶装置は、電源が失われた場合に格納されたデータが失われないように、メモリカードのような不揮発性メモリの形で構成される可能性がある。更新あるいは変更される必要のないデータを格納するために、ＲＯＭ記憶手段が提供される可能性がある。より早い応答時間のため頻繁にアクセスされるデータのキャッシングをサポートする、一時的な記憶のために、ＲＡＭが提供される可能性がある。前記デバイスは、格納手段として使用される可能性のあるユーザリムーバブルメモリカードと任意でハードディスクドライブとを受け入れる可能性もある。使用される格納手段はデバイスの大きさや電力消費、要求される記憶容量、等の異なる要求条件の釣り合いをとることにより決定されよう。

そのようなデバイスは仮想的にあらゆる無線通信ネットワーク、例えば、第２世代デジタル移動体電話ネットワーク（すなわち、ＧＳＭ、Ｄ−ＡＭＰＳ）、いわゆる２．５Ｇネットワーク（すなわち、ＧＰＲＳ、ＨＳＣＳＤ、ＥＤＧＥ）、第３世代のＷＣＤＭＡネットワークあるいはＣＤＭＡ−２０００ネットワーク、及びこれらのネットワークと類似のネットワークとの改良品及び派生品、と共に実現される可能性がある。建物とキャンパスとの内部で、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤＡ、あるいは（ラジオシステムであろうと光学システムであろうと）無線ＬＡＮのような他の技術が使用される可能性もある。ＵＳＢ、及び／あるいは、ＦｉｒｅＷｉｒｅの接続性が、他のデバイスとのデータ同期、及び／あるいは、バッテリの充電のために、供給される可能性がある。

上記方法を実現するための、及び／あるいは、上述のデバイスを構成するためのコンピュータソフトウェアは、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、不揮発性メモリカード、等のようなデータキャリア上で提供される可能性がある。

本出願は２００４年２月１９日に提出された英国特許出願０４０３７０９．９の利益と、参照としてここに組み入れられた内容とを主張する。

本発明を具体化したシステムの概略的な描写を示す。 サーバの構造と動作とを極めて詳細に描く。 モバイル装置向けのソフトウェアの概略的な描写を示す。 本発明の実施形態にかかるユーザインターフェイスを備える装置の概略的な描写を示す。

符号の説明

１００…サーバ、２００…コンテンツツールセット、３００…モバイル装置、４００…ソフトウェア、５００…コンテンツフィード、７００…運用サポートシステム（ＯＳＳ）

Claims (23)

1. ユーザインターフェイス内に複数のユーザインターフェイス要素のサブセットを表示する方法であって、
   （ｉ）前記ユーザインターフェイス内に表示されうる複数のユーザインターフェイス要素の前記サブセットのサイズを判別し、
   （ｉｉ）前記ユーザインターフェイス内に表示されるために選択される可能性のある複数のユーザインターフェイス要素を判別し、
   （ｉｉｉ）ステップ（ｉｉ）において判別された前記複数のユーザインターフェイス要素からユーザインターフェイスの前記サブセットを選択し、
   （ｉｖ）前記ユーザインターフェイス内にステップ（ｉｉｉ）において選択されたユーザインターフェイスの前記サブセットを表示する、
   ステップを備える方法。
2. ステップ（ｉｉｉ）はユーザ入力に応答してユーザインターフェイス要素の更なるサブセットを選択するために繰り返され、ステップ（ｉｖ）は前記ユーザインターフェイス内にユーザインターフェイス要素の前記更なるサブセットを表示することが繰り返される、請求項１に記載の方法。
3. 前記ユーザ入力がユーザ入力手段を活性化することを備え、ユーザインターフェイス要素の更なるサブセットの前記選択と前記表示とが、リストあるいはメニューがスクロールされる原因となる、請求項２に記載の方法。
4. 前記複数のユーザインターフェイス要素が単一の場所に格納され、マークアップ言語要素が前記複数のユーザインターフェイス要素の前記場所を定めるために提供される、請求項１乃至３の何れかに記載の方法。
5. 前記マークアップ言語要素はさらにリスト内のユーザインターフェイス要素の前記選択されたサブセットの表示を定める、請求項４に記載の方法。
6. テンプレートが前記マークアップ言語要素と関連付けられており、前記テンプレートが前記リスト内に表示されたユーザインターフェイス要素の前記選択されたサブセットの出現を判別する、請求項５に記載の方法。
7. 前記複数のユーザインターフェイス要素が単一のファイルに格納され、マークアップ言語要素が前記ファイルの場所を定めるために提供され、前記ファイルは前記ユーザインターフェイス内で表示するための１または２以上のデータリソースを備える、請求項１乃至３の何れかに記載の方法。
8. 前記マークアップ言語要素はさらにリスト内のユーザインターフェイス要素の前記選択されたサブセットの前記表示を定める、請求項７に記載の方法。
9. テンプレートが前記マークアップ言語要素と関連付けられており、前記テンプレートが前記リスト内に表示されたユーザインターフェイス要素の前記選択されたサブセットの出現を判別する、請求項８に記載の方法。
10. ユーザインターフェイス要素の前記選択されたサブセットの前記リストは、１または２以上の更なるリストを備え、前記１または２以上の更なるリストのそれぞれはユニークな表現により同定（ｉｄｅｎｔｉｆｙ）される、請求項３乃至９の何れかに記載の方法。
11. 請求項１乃至１０の何れかに記載の方法を実行するための計算機で実行可能なコードを備えるデータキャリア。
12. ディスプレイとユーザインターフェイスとを備える装置であって、前記装置は使用において、
    （ｉ）前記ユーザインターフェイス内で表示されうる複数のユーザインターフェイス要素のサブセットのサイズを判別し、
    （ｉｉ）前記ユーザインターフェイス内で表示するために選択される可能性のある複数のユーザインターフェイス要素を判別し、
    （ｉｉｉ）ステップ（ｉｉ）において判別された前記複数のユーザインターフェイス要素からユーザインターフェイス要素の前記サブセットを選択し、
    （ｉｖ）前記ユーザインターフェイス内にステップ（ｉｉｉ）において選択されたユーザインターフェイス要素の前記サブセットを表示する、
    ように、構成されている装置。
13. 前記装置はさらに、使用において、ユーザ入力手段を備え、ユーザインターフェイス要素の更なるサブセットを選択するためにステップ（ｉｉｉ）を繰り返し、前記ユーザインターフェイス内にユーザインターフェイス要素の前記更なるサブセットを表示するためにステップ（ｉｖ）を繰り返すようにユーザ入力に応答するように構成されている請求項１２に記載の装置。
14. 前記装置は、ユーザインターフェイス要素の更なるサブセットの前記選択と前記表示とがリストあるいはメニューがスクロールさせられる原因となるように、前記ユーザ入力手段の活性化に応答する、請求項１２または１３に記載の装置。
15. 前記装置はさらに格納手段を備え、前記複数のユーザインターフェイス要素は単一の場所に格納され、マークアップ言語要素が前記複数のユーザインターフェイス要素の前記場所を定めるために提供される、請求項１２乃至１４の何れかに記載の装置。
16. 前記マークアップ言語要素はさらにリスト内のユーザインターフェイス要素の前記選択されたサブセットの表示を定める、請求項１５に記載の装置。
17. テンプレートが前記マークアップ言語要素と関連付けられており、前記テンプレートが前記リスト内に表示されたユーザインターフェイス要素の前記選択されたサブセットの出現を判別する、請求項１６に記載の装置。
18. 前記装置はさらに格納手段を備え、前記複数のユーザインターフェイス要素は単一のファイルに格納され、マークアップ言語要素は前記ファイルの場所を定めるために提供され、前記ファイルは前記ユーザインターフェイス内で表示するための１または２以上のデータリソースから構成される、請求項１２乃至１４の何れかに記載の装置。
19. 前記マークアップ言語要素はさらにリスト内のユーザインターフェイス要素の前記選択されたサブセットの表示を定める、請求項１８に記載の装置。
20. テンプレートが前記マークアップ言語要素と関連付けられており、前記テンプレートが前記リスト内に表示されたユーザインターフェイス要素の前記選択されたサブセットの出現を判別する、請求項１９に記載の装置。
21. ユーザインターフェイス要素の前記選択されたサブセットの前記リストは１または２以上の更なるリストを備え、前記１または２以上の更なるリストはユニークな表現により同定される、請求項１５乃至２０の何れかに記載の装置。
22. 前記装置は無線通信手段を備える、請求項１１乃至２１の何れかに記載の装置。
23. 処理手段と、格納手段と、ディスプレイと、ユーザ入力手段と、無線通信手段と、ユーザインターフェイスとを備える装置であって、前記装置は請求項１乃至１０の何れかに記載の方法を実行するように構成された装置。

Images