JP4927830B2 - データ言語における変数の自動更新 - Google Patents

Description

本発明は、一般に、ソフトウェアアプリケーションの変数処理に関する。更に詳しくは、本発明は、データ言語における動的変数の処理に関する。

関連出願への相互参照

本願は、２００５年５月３１日に出願され、その全体が、参照によって本明細書に組み込まれている米国仮出願番号６０／６８６，２７１の優先権を主張する。

データ言語は、プログラムに対してより普及した方法になっている。データ言語は、ＨＴＭＬやＴＲＩＧＭＬ（登録商標）（カルコム社が保有）を含むＸＭＬに基づくようなマークアップ言語を含む。データ言語は、ウェブベースのアプリケーションのプログラミングに広範に使用されるが、それに限定されない。ＸＭＬベースの言語を使用して実施される機能の例は、課金処理プログラムやトランザクション処理プログラムを含んでいる。

データ言語は、元々、解釈可能である。データ言語プログラムによってパスが生成され、例えば、そのプログラムで定義された要素を使用してウェブページが表示される。プログラムは、使用される要素の定義のみならず、これら要素がどのように表示されるかに関する要素の特徴をも定義しうる。これら言語はまた、ユーザインタフェースの生成に使用することもできる。

データ言語の使用においては、例えば、変数の取り扱いに困難性がある。ＸＭＬはもともと解釈可能であるので、一旦変数が設定されると、動的な変数は変更することができない。この問題を解決する幾つかの試みは、ｊａｖａ（登録商標）スクリプトの使用を伴う。しかしながら、ｊａｖａスクリプトは、コードが再実行されるまで変数を変えないので、何かがトリガをかけて、ｊａｖａスクリプトを再実行させねばならない。自動的なトリガは存在しない。言い換えると、ｊａｖａスクリプトを含むプログラムコードは、新たな変数値を決定するために再実行されねばならない。変数が動的であり変化するのであれば、ｊａｖａスクリプトで使用される変数は、コードが再実行されるまで更新されないだろう。

データ言語を使用する際における別の困難さは、データ言語が、基礎をなすコンピュータ又はプロセッサプラットフォーム機能へのアクセスを許可しないことである。例えば、データ言語ディスプレイを、バッテリレベルを示すバッテリアイコンに使用したくても、データ言語には、プラットフォームに知られているようなバッテリレベルにアクセスするためのメカニズムが存在しない。Ｊａｖａスクリプトは、コンピュータ／プラットフォーム機能にアクセスする能力を持っていないので、この問題を被る。

従って、動的変数を含む表式の評価を可能にする方法及び装置を提供するニーズが、当該技術にある。更に、コンピュータ／プラットフォームレベル機能へのアクセスを提供する方法及び装置を有するニーズがある。

本発明と一貫するシステム及び方法は、動的変数を評価し、コンピュータプラットフォームの基礎をなしている機能へアクセスするシステム、方法、及び装置を生み出すことによって、既存システムの欠点を克服する。

本発明の１つの実施形態では、データ言語で書かれ動的変数を有する表式が、動的変数を受け取り、動的変数の第１の値を決定し、この第１の値を用いて表式を評価し、動的変数に関連した変化を検知することによって評価される。動的変数に関連する第２の値を受け取り、この第２の値を用いて表式を評価した後、表式は、この表式を含む他のプログラムコードを再解釈することなく、第２の値を用いて評価される。

他の実施形態では、動的変数は、動的変数を含み、データ言語で書かれた命令を解析し、動的変数をメモリ内に生成し、動的変数の値を割り当て、動的変数を含み、データ言語で書かれた命令を解析することなく、動的変数の値を更新することによって更新される。この動的変数はまた、動的変数の値に関連付けられたオブジェクトを生成することによって更新される。このオブジェクトは、動的変数の値を決定する。更に、機能値を観察することが、動的変数に関連しており、この機能値が変化した場合、オブジェクトに通知がなされる。

また別の実施形態では、データ言語における動的変数を更新する装置は、動的変数に割り当てられたメモリ位置を備える。ここで、動的変数は、データ言語及びプロセッサ内の命令を解析することに応じてメモリ位置が割り当てられ、動的変数に対する更新値が評価される。

また別の実施形態では、コンピュータ読取可能媒体は、データ言語で書かれ、動的変数を更新するコンピュータ実行可能命令を含んでおり、この命令は、実行されると、動的変数を含み、データ言語で書かれた命令を解析することと、動的変数をメモリ内に生成することと、動的変数の値を割り当てることと、動的変数を含み、データ言語で書かれた命令を解析することなく、動的変数の値を更新することとを備える各ステップを実行する。

本発明の他の目的、利点、及び機能が、図面の簡単な説明、発明を実施するための最良の形態、及び特許請求の範囲の後に本明細書をレビューすることにより明らかになるであろう。

全体を通じて同一符号が同一要素を示す図を参照して説明する。

添付図面で例示されるような本発明の典型的かつ好適な実施形態に対する参照がより詳細になされる。ここでは、同一の参照符号が、幾つかの図面を通じて、同一又は対応する部位を指定している。本発明の特徴、目的、及び利点が、添付図面と関連付けられた以下の詳細記述を考慮した後に、当業者により明らかになるであろう。

用語に使用に関して、本明細書では、用語「無線デバイス」、「無線電話」、及び「モバイルデバイス」が置き換え可能に使用される。本明細書で使用される用語「アプリケーション」は、実行可能型及び実行不能型ソフトウェアファイル、生データ、集合データ、パッチ、コンテンツ、ユーザインタフェース及びユーザインタフェースコンポーネント、及びその他のコードセグメントを含むことが意図される。更に、同一参照符号は、幾つかの図面を通じて同一の要素を示し、冠詞"a"及び"the"は、別段の定めがない限り複数の参照を含む。

ＴｒｉｇＭＬは、ユーザインタフェースの開発に役立つデータ駆動（driven）言語である。ＴｒｉｇＭＬは、カルコム社によって所有されている製品である。ＸＭＬの下で定義されたデータ言語のように、ＴｒｉｇＭＬコードは、タグの使用を含んでいる。実施形態は、無線デバイス上のユーザインタフェース用のＴｒｉｇＭＬに関して記述されているかもしれないが、これは説明目的のみのためであって、本発明の限定ではないことが認識されよう。本明細書に記載の装置及び方法はまた、非ユーザインタフェース環境、及び、上述したように、異なるデータ言語を用いる環境を用いる場合でも適用可能である。

図１は、本発明の実施形態においてデバイスが動作しうる通信環境１００の機能ブロック図である。この例では、通信環境１００は、無線ネットワーク１２２を含んでいる。無線ネットワーク１２２は、無線サービスプロバイダによって操作され、データ及び電気通信接続をモバイルデバイスに提供する通信ネットワークでありうる。更に、無線ネットワーク１２２はまた、有線ネットワーク、インターネット、広域ネットワーク、公衆電話交換網（ＰＳＴＮ）、及び、その他の大衆ネットワーク及び／又はプライベートネットワークをも含み、これによって、デバイスは、これらネットワークに接続された他のデバイスを用いて、直接的又は間接的に通信することができる。

一例では、無線ネットワーク１２２は、セルラ電話ネットワークを含みうる。幾つかのモバイルデバイスは、例えばセルラ電話１１２、ラップトップコンピュータ１１６、ＰＤＡ１１８、及び、モバイルメッセージングデバイス１２０であり、無線ネットワーク１２２と通信する。これらデバイスは、無線ネットワーク１２２によって通信する多くのタイプのデバイスの例として示されているだけである。

アプリケーションサーバ１２４及びユーザインタフェースサーバ１２６が、図１に図示される。ユーザインタフェースサーバ１２６は、ユーザインタフェースコンポーネント１３０（より詳細に後述する）にサービス提供する計算デバイスである。これらユーザインタフェースコンポーネント１３０は、無線ネットワーク１２２に接続された他のデバイスにダウンロードされうる。ユーザインタフェースコンポーネントは、ユーザインタフェース（例えば、機能呼出し、メニュー、コンテンツ呼出のためのコード、スキン等）を与えるためのコード及び／又はデータを含んでいる。コンテンツサーバを含むその他の多くのサーバが、情報を配信するためにネットワークへの接続に使用されうることに注目されたい。利用可能となる情報のタイプは無限であり、極めて多くの異なる例が、当業者に明らかになるであろう。ユーザインタフェースサーバ１２６は、要求元のデバイスへ、無線ネットワーク１２２を介してユーザインタフェースコンポーネント１３０を提供するように構成されたサーバソフトウェアを含んでいる。

アプリケーションサーバ１２４は、無線ネットワーク１２２に接続された計算デバイス又はシステムであり、ソフトウェアアプリケーション１２８を、モバイルデバイスによるダウンロードのために利用可能にする。一般に述べられているように、アプリケーション１２８は、デバイス上での実行のため、無線ネットワーク１２２に接続された例えばセルラ電話１１２によってダウンロード可能である。この特定の実例では、アプリケーションダウンロードサーバ１２４によってサービス提供されるアプリケーション１２８のうちの少なくとも１つは、モバイルデバイスの少なくとも１つの実行のために構成されたコンテンツベースのアプリケーションである。このコンテンツベースのアプリケーション（クライアント）は、ユーザインタフェースを介してモバイルデバイスから表式するために、コンテンツサーバ（図示せず）からコンテンツを検索するように構成されている。

図２は、本発明の実施形態におけるサンプルモバイルデバイス２０１のコンポーネントを一般に例示する機能ブロック図である。モバイルデバイス２０１は、例えば、セルラ電話、パーソナルデジタルアシスタント、ハンドヘルド「パームトップ」デバイス、ラップトップコンピュータ、ポータブル音楽プレーヤ、グローバルポジショニング衛星（ＧＰＳ）デバイス等のような計算機能を有する任意のデバイスでありうる。

モバイルデバイス２０１は、ソフトウェアアプリケーションの受信及び実行、並びにデータの表式が可能なコンピュータプラットフォーム２５０を有する。コンピュータプラットフォーム２５０は、例えば、特定用途向けＩＣ「ＡＳＩＣ」、デジタル信号プロセッサ「ＤＳＰ」、マイクロプロセッサ、マイクロコントローラ、論理回路、状態計算機、又は、その他のデータ処理デバイスのようなプロセッサ２５２を含んでいる。プロセッサ２５２は、モバイルデバイスのメモリ２５６内の幾つかの常駐プログラムとインタフェースするアプリケーションプログラミングインタフェース（ＡＰＩ）レイヤ２５４を実行する。メモリ２５６は、ランダムアクセス又は読取専用メモリ（ＲＡＭ又はＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、又は、コンピュータプラットフォームに一般的な任意のメモリを含むことができる。コンピュータプラットフォーム２５０は更に、例えばユーザインタフェースサーバ１２６（図１）からダウンロードしたソフトウェアアプリケーションやユーザインタフェースコンポーネントのように、メモリ２５６内で実際に使用されないソフトウェアアプリケーション、ファイル、又はデータを保持することができるローカルストレージ２５８を含む。このローカルストレージ２５８は、一般に、１又は複数のフラッシュメモリセルで構成されるが、例えば、磁気媒体、ＥＰＲＯＭ、ＥＥＰＲＯＭ、光学媒体、テープ、又はソフトディスクやハードディスクのような任意の２次あるいは３次記憶デバイスにもなりうる。

コンピュータプラットフォーム２５０はまた、ユーザインタフェース（図示せず）を用いてデータを表示するためのソフトウェアアプリケーションによって使用されるディスプレイ２６０を含む。

図２に示すコンポーネントは、多くのタイプのモバイルデバイスに典型的であるが、その他のコンポーネントがモバイルデバイス２０１に追加されうること、及びある場合においては、図２に示す幾つかのコンポーネントがモバイルデバイス２０１から省略されうることが理解されよう。

図３は、本発明の実施形態において、サンプル計算デバイス３０１のコアコンポーネントを一般に例示する機能ブロック図である。計算デバイス３０１は、例えばデスクトップコンピュータかサーバのような任意の固定式計算デバイスでありえる。

この例では、計算デバイス３０１は、プロセッサユニット３０４、メモリ３０６、記憶媒体３１３、及びオーディオユニット３３１を含んでいる。プロセッサユニット３０４は、有利なことに、マイクロプロセッサ、又は、例えばデジタル信号プロセッサ（ＤＳＰ）のような特別目的プロセッサを含むが、代替例では、任意の従来式のプロセッサ、コントローラ、マイクロコントローラ、又は状態計算機の形態でありうる。プロセッサユニット３０４は、メモリ３０６に接続されている。メモリ３０６は、プロセッサユニット３０４によって実行されるソフトウェア命令を保持するＲＡＭメモリとして実装される。代替実施形態では、メモリ３０６は、ファームウェア又はフラッシュメモリから構成されうる。この実施形態では、メモリ３０６に格納されたソフトウェア命令は、オペレーティングシステム３１０や、例えばユーザインタフェース（図示せず）を用いるアプリケーションのような１又は複数のその他のアプリケーション３１２を含む。

モバイルデバイス３０１はまた、計算デバイス３０１と、例えばモバイルデバイスのような１又は複数のその他の計算デバイスとの間の双方向通信を可能にする通信モジュール３２１を含む。通信モジュール３２１は、例えば、セルラ電話ネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）接続、無線ローカルエリアネットワーク、あるいは恐らくは無線広域ネットワークのような、ＲＦ通信又はその他の無線通信を可能にするコンポーネントを含む。あるいは、通信モジュール３２１は、例えば、イーサネット（登録商標）接続、ＲＪ−１１接続、ユニバーサルシリアルバス接続、ＩＥＥＥ １３９４（Ｆｉｒｅｗｉｒｅ）接続等のような陸線ネットワーク通信又はハードワイヤネットワーク通信を可能にするコンポーネントを含む。これらは、完全ではないリストであることが意図されており、その他多くの代替例が可能である。オーディオユニット３３１は、アナログフォーマットとデジタルフォーマットとの間で信号を変換するように構成されたモバイルデバイス３０１のコンポーネントである。オーディオユニット３３１は、モバイルデバイス３０１によって使用され、スピーカ３３２によって音が出力され、マクロフォン３３３から入力された信号が受け取られる。

図３は、多くの従来式の計算デバイスで一般に見られるあるコンポーネントのみを示している。特定の実装では、他の極めて多くのコンポーネントも見受けられ、ある場合においては、図３に示す幾つかのコンポーネントが省略されうる。しかしながら、図３に示す計算デバイス３０１は、今日一般的に見受けられる計算デバイスの典型である。

図４は、本発明の実施形態におけるデバイスのアプリケーションアーキテクチャを示す。このデバイスは、「コンピュータプラットフォーム」を含む。コンピュータプラットフォームは、ハードウェア、ソフトウェア、又はこれら両方を含むデバイスのコンポーネントを称する。例えば、それは、チップ、ユーザインタフェースハードウェア（例えば、ディスプレイ、入出力デバイス）、ライブラリ、サポートＡＰＩ、オペレーティングシステムへの追加拡張機能等を含むハードウェアコンポーネントに内在するオペレーティングシステムを含みうる。

１つの実施形態では、無線デバイスのアプリケーションアーキテクチャ４００は、デバイスＡＰＩ４０５、ＢＲＥＷ（登録商標）ＡＰＩ４１０、ＢＲＥＷ拡張機能４１５、Ｔｒｉｇプレーヤ、アクタ４２５、及びＴｒｉｇ４３０を含む。デバイスＡＰＩ４０５は、例えば、特定のプロセッサ又はＡＳＩＣ機能、特定のデバイスハードウェア機能等のようなデバイスと特に関連している機能を扱うソフトウェアプラットフォームによって使用されるＡＰＩを含む。

ＢＲＥＷ ＡＰＩ４１０は、カルコム社によって開発されたソフトウェアプラットフォームである。ＢＲＥＷ ＡＰＩ４１０は、デバイスのために特別に書かれる必要なく、デバイスＡＰＩ４０５及びその他の機能を呼び出す能力をアプリケーションに提供する。言い換えれば、それは、アプリケーションから、ハードウェアの特定の局面を抽出する。これによって、特別に作成する必要なく、多くのデバイスのためにアプリケーションを書くことが可能となるか、あるいは、アプリケーションが実行する具体的な各デバイスのために、ほんの少しの手直ししか必要としない。

ＢＲＥＷ拡張機能４１５は、例えば、提供しているＭＰ３プレーヤ、Ｊａｖａバーチャルマシン等のようなＢＲＥＷプラットフォームへ、追加機能を与える能力を提供する。

Ｔｒｉｇプレーヤ４２０、Ｔｒｉｇ４３０、及びアクタ４２５は、カルコム社によって開発されたｕｉＯｎｅ（登録商標）アーキテクチャのコンポーネントである。これらコンポーネントは一般に、デバイス４００のユーザインタフェース局面を称する。１つの実施形態では、Ｔｒｉｇ４３０は、コンパイルされたＴｒｉｇＭＬ（登録商標）、及び、デバイス４００上にユーザインタフェースを与えるためにアプリケーションによって使用されるその他のリソース（メタデータ、テキストファイル、及びイメージを含む）である。ここでＴｒｉｇｌｅｔ（図示せず）と称される多くのＴｒｉｇ４３０及びＴｒｉｇ最新版が、ユーザインタフェースのために使用されうる。

カルコム社によって所有されているＴｒｉｇＭＬコードは、ＸＭＬに基づいたデータ言語であり、Ｔｒｉｇ４３０のオーサリングのためのユーザインタフェース表示言語のために使用され、とりわけ、モバイルをターゲットとした機能、インタラクティブユーザインタフェースイベントモデル、及び、ピクセルポジショニングの利点を含む。

アクタ４２５は、Ｔｒｉｇを、下にあるデバイスＡＰＩ４０５及び／又はＢＲＥＷ ＡＰＩ４１０に接続するための基礎をなしているＣコードを含む。アクタ４２５はまた、入出力のために実行可能なものとして動作する。また、アクタは、下にあるデバイスＡＰＩ及びＢＲＥＷ ＡＰＩに接続しているので、コンピュータプラットフォーム機能へのアクセスを有する。

Ｔｒｉｇプレーヤ４２０は、図４では、分離されているが、ＢＲＥＷ拡張機能４１５として実現することができる。Ｔｒｉｇプレーヤは、Ｔｒｉｇ及びアクタを用いてユーザインタフェースを与えるために使用される。

図４の説明は、カルコム社のｕｉＯｎｅアーキテクチャ（コンパイルされたＴｒｉｇＭＬ、Ｔｒｉｇプレーヤ、ＢＲＥＷ ＡＰＩ等を含む）に関連するものであるが、これは説明目的であって、本発明は、その他のデータ言語、コンピュータ、ソフトウェアプラットフォーム、及びデバイスアーキテクチャを含むことが認識されるだろう。

図５は、本発明の実施形態において、Ｔｒｉｇプレーヤ４２０、アクタ４２５、及びＴｒｉｇ４３０を示すアーキテクチャと、ユーザインタフェースコンポーネントを更新するシステムを例示するブロック図である。デバイス５００は、Ｔｒｉｇプレーヤ４２０、アクタ４２５、及びＴｒｉｇ４３０を含む。Ｔｒｉｇは、ＴｒｉｇＭＬコード５０５、テキスト文字列５１０、イメージ５１５、及び、最新チャネル５２０（最新チャネルは、Ｔｒｉｇｌｅｔ５３０を取得するためのＵＲＬ及びタイミングスキームを定義する）を含む。Ｔｒｉｇは、無線で更新される。これによって、デバイスは、製造者から既に出荷された後でもユーザインタフェースが更新される。サーバ５２５は、新たなＴｒｉｇ、及び／又は、Ｔｒｉｇの最新版（例えば、Ｔｒｉｇｌｅｔ５３０）をダウンロードするために使用される。これによって、デバイスのためにユーザインタフェースがカスタマイズされる。

図６は、本発明の実施形態における関連ＴｒｉｇＭＬコード、オブジェクト、及びアクタを例示するブロック図である。ＴｒｉｇＭＬコードは、一連のタグ（６０５−６２５）を用いて書かれる。これらタグは、プログラムコードの目的と関連する具体的なパラメータを実行及び定義するための動作を定義する。１つの実施形態では、ＴｒｉｇＭＬコードは、無線デバイス上での解析及び実行の前にコンパイルされる。

本発明の１つの実施形態では、ＴｒｉｇＭＬプログラムコードが実行のために解析された場合、オブジェクト（６３０−６５０）が、ＴｒｉｇＭＬコード内の要素（６０５−６２５）と関連付けられる。これらオブジェクトは、要素の表式を含んでいる。例えば、要素６２０は、３の長さを持つボックスを示す。この要素が評価される時、ボックス長さ＝３の値を持つオブジェクト（６４５）が生成される。

プログラムコード内の表式に動的変数を含めることが望ましいかもしれない。例えば、無線デバイスのバッテリレベルに示すアイコンが望まれる場合、バッテリレベルが変化すると、ボックスの幅が変化すると仮定して、ボックスの幅を、バッテリが充電されたり消耗されると変化させ、現在のバッテリレベルを示すように更新することが望ましい。

この場合、要素“＜ボックス幅＝“バッテリ寿命／１０”＞”（６４５）は、バッテリに残っている電力量に依存して変化する動的変数“バッテリ寿命”を有する表式を含む。それは更に、バッテリ寿命値を１０で除することによって、オブジェクトによって操作される。この表式は、動的変数とともに数、文字列、及び演算を用いることを含む単純又は複雑な演算を含みうることに注目されたい。

１つの実施形態では、動的変数を含む要素の表式の値を決定するためにオブジェクト６４０が生成される。更に、アクタ６５５が生成され、バッテリ寿命値を受け取るために使用される。このオブジェクト６４０は、表式を評価する際に、動的変数のためのアクタ内で示される値を用いるだろう。

デバイスでは、例えばＡＰＩのような機能が、現在のバッテリ寿命をモニタして判定する（６６０）。この機能は、計算デバイスに対するコンピュータ又はプラットフォームレベルにおける機能を含むか、あるいは、他のＡＰＩ機能の他の機能、機能、あるいは、ローカルコンピュータ又は遠隔コンピュータに関連しているかローカル又は遠隔に実行されるタスクでありうる。当業者であれば、“バッテリ寿命”機能は、説明目的のみに使用され、任意の機能／ＡＰＩが使用されることを認識するだろう。

バッテリ寿命機能６６０の値の変化をアクタ６５５に示すために、多くのパラダイムが使用される。例えば、アクタ６５５が存在することと、値に変化が生じてアクタ６５５に通知する時とがバッテリ寿命機能６６０に通知される、観察／通知パターンが実現されうる。このパラダイムを用いて、アクタ６５５はスタンバイし、変化が生じたとの表示をバッテリ寿命機能６６０から待つ。アクタ６５５は、変化の表示を受け取ると、オブジェクト６４０に通知し、オブジェクト６４０は、バッテリ機能６６０から値を取得することができる。オブジェクトは、その後、この新たな機能値を用いて、動的変数を含む表式を評価することができる。

別のパラダイムはポーリングを含んでいる。そこでは、アクタ６５５が、変化が生じたという表示に対してバッテリ寿命機能６６０を取得する。上述したような処理が進み、オブジェクトは機能値を取得し、表式を評価する。当業者に周知であり、本発明のスコープに含まれる他の例も存在する。

表式を表すオブジェクトが再評価された場合、新たな値が、ＴｒｉｇＭＬコードを書き込む目的のために使用される。また、動的変数は、頻繁に変化しうり、各変化においては、新たな値を決定するためには、表式に関連付けられたオブジェクトだけ再評価する必要があることに注目されたい。ＴｒｉｇＭＬコードは、再解析される必要はない。

図７は、本発明の実施形態において、動的表式を評価するプロセスを示すフローチャートである。まずこの方法は、動的変数を有する表式を受け取ることにより始まる（ステップ７０５）。この表式は、一般に、例えばＸＭＬに基づくようなデータ言語フォーマットであることに留意されたい。しかしながら、他のデータ言語フォーマットも使用されうる。

また、動的変数は、変化しうる変数であり、動的変数に対するどの変化も、データ言語プログラムコードの初期解析の後であることが望まれる。更にそれは、コンピュータプラットフォームに関連付けられた機能に関連しうる。

次に、表式を評価するためにオブジェクトが生成される（ステップ７１０）。オブジェクトの使用は必ずしも必要ではなく、単に幾つかの要素のためにのみ必要かもしれない。必ずしもスカラ値あるいは数値ではないが、要素の意図の表示である値を、オブジェクトは含んでいる。

そしてアクタが生成される（ステップ７１５）。これは、動的変数の値を提供するのを支援する。あるいは、アクタは、既に存在しているかもしれない。そして、この既存のアクタは、機能値が変化したことをオブジェクトに通知するために使用される。アクタは、動的変数に関連した機能にリンクされる。アクタは、２つの機能を提供する（これら機能は、アクタに割り当てられる必要はなく、更なる機能を実行するかもしれない）。アクタによって、先ず、値のクエリ／取得／読み取り等がなされる。次に、アクタは、（本明細書で説明したパラダイムのうちの１つを用いて）機能における変化をオブジェクトへ示すためのメカニズムとして動作する。

そして、オブジェクトは、機能から機能値を取得する（ステップ７２０）。オブジェクトは、表式の評価を開始する（ステップ７２５）。次に、機能値に変化があるかが判定される（ステップ７３０）。これは、変化が生じたことをアクタに示す機能と、変化が生じたことをオブジェクトに示すアクタとによって、本明細書で説明したようにして行われる。

ステップ７３０において、機能値が変化した場合、“ｙｅｓ”のパスに従い、オブジェクトが、機能から新たな機能値を再取得し（ステップ７３５）、（動的変数に関連する）新たな機能値を用いてこの表式を評価する（ステップ７４５）。

ステップ７３０において、機能値が変化しない場合、“ｎｏ”のパスに従い、本明細書で説明した例のうちの１つ、又は、当業者に周知の他の例を用いて、機能に変化がないかがモニタされる。

他の実施形態は、例えば、

のようなＢｏｏｌｅａｎ表式に依存する「アクション」タグを更新することを含む。

ここで、与えられたＢｏｏｌｅａｎ表式が真である間、「アニメート」アニメーションタグが起動される。将来、いかなる時点においても、この表式が「偽」であることが判明した場合には、このアニメーションは停止される。

Ｂｏｏｌｅａｎ表示は、表式が真であることが判明した場合、すなわち、表式の任意のサブ要素が変化し、表式全体が真であることが判明した場合には、タグが（瞬間的に）起動されることを要求することにより、例えば

のように、１度限りの「アクション」タグのためにも使用されうる。

この‘ｄｏｌｏａｄ’アクションは、ＶＦＳ ｎｏｄｅ／ｒｅｓ／ｅｒｒｏｒｍｓｇが更新され、表式が真であると評価される毎に実行される。

表式は更に、例えば

のようなリソースパス要素として組み込まれうる。

この実施形態では、３つの要素のリソースパスが、第１の要素のための文字列定数と、最終要素のための２つの表式とを用いて構築される。このリソースパスは、再現されるイメージの位置を示す。サブ表示のうちの何れかが変化するのであれば、リソースパスが自動的に再評価され、異なるイメージが表示されるかもしれない。

複雑な表式をＸＭＬ属性に直接的に任意に埋め込むことによって、イベント又は組込式スクリプト言語を必要とすることなく、簡潔かつエレガントなマークアップを用いて、更新可能なＵＩを動的に生成することが可能となる。

上述した方法及びソフトウェア設計の説明はまた、ＲＡＭ、又は、その他のメモリ記憶デバイスに格納された命令として、装置に実装することができる。本書で示されたプロセスは、例示的に示され、かつ、具体的な順番に従って連続して説明されているが、他の実施形態では、これらプロセスのステップは、異なる順番で、多くの回数で、及び／又は並列しても行われうる。更に、幾つかの実施形態では、幾つかのプロセスで説明した１又は複数のステップが、個別のステップとして、２〜３のステップに結合されて、又は、完全に省略されて実行されることもありうる。

上記開示は、本発明の例示的な実施形態を示す一方、特許請求の範囲によって定義したような本発明の精神及びスコープから逸脱することなく、記載された実施形態に対して様々な変形及び変更がなされることが注目されるべきである。更に、本発明の要素は、単数で記述又はクレイムされているかもしれないが、単数への限定が明示的に述べられていないのであれば、複数も考慮される。

図１は、本発明の実施形態においてデバイスが動作する通信環境の機能図である。 図２は、本発明の実施形態におけるサンプルモバイルデバイスのコンポーネントを一般に例示する機能ブロック図である。 図３は、本発明の実施形態におけるサンプル計算デバイスのコンポーネントを一般に例示する機能ブロック図である。 図４は、本発明の実施形態におけるコンピュータプラットフォームのアプリケーションアーキテクチャを図示するブロック図である。 図５は、本発明の実施形態におけるＴｒｉｇプレーヤ（trigplayer）、アクタ（actor）、Ｔｒｉｇを例示しており、アーキテクチャとユーザインタフェースコンポーネントとを更新するシステムを例示するブロック図である。 図６は、本発明の実施形態におけるＴｒｉｇＭＬコード、オブジェクト、及びアクタの関係を例示するブロック図である。 図７は、本発明の実施形態における動的表式の評価のプロセスを示すフローチャートである。

Claims (6)

1. 計算デバイスの記憶媒体に記憶されたデータ言語における動的変数を更新する方法であって、
   前記動的変数を含み、前記データ言語で書かれた命令を解析することと、
   前記動的変数を生成することと、
   前記動的変数の値を割り当てること、
   前記動的変数の値を決定する、前記動的変数の値に関連付けられたオブジェクトを生成することと、
   前記動的変数に関連付けられた機能値を観察することと、
   前記機能値が変化した場合、前記オブジェクトに通知することと、
   前記動的変数を含み、前記データ言語で書かれた命令を再解析することなく、前記変化した機能値に基づいて前記動的変数の値を更新することと、
   を備える方法。
2. 前記動的変数の値を割り当てることは、ソフトウェアプラットフォームに関連する機能を評価することを備える請求項１に記載の方法。
3. 前記動的変数は、式に含まれ、
   更に、前記更新された動的変数の値を用いて前記式を更新することを備える請求項１に記載の方法。
4. 計算デバイスの記憶媒体に記憶され、データ言語で書かれた動的変数を更新するコンピュータ実行可能命令を含むコンピュータ読取可能媒体であって、前記命令は、実行された場合、
   前記動的変数を含み、前記データ言語で書かれた命令を解析することと、
   前記動的変数を生成することと、
   前記動的変数の値を割り当てることと、
   前記動的変数の値を決定し、前記動的変数の値に関連付けられたオブジェクトを生成することと、
   前記動的変数に関連付けられた機能値を観察することと、
   前記機能値が変化した場合、前記オブジェクトに通知することと、
   前記動的変数を含み、前記データ言語で書かれた命令を再解析することなく、前記変化した機能値に基づいて前記動的変数の値を更新することと
   からなる各ステップを実行するコンピュータ読取可能媒体。
5. 前記動的変数の値を割り当てることは、ソフトウェアプラットフォームに関連する機能を評価することを備える請求項４に記載のコンピュータ読取可能媒体。
6. 計算デバイスの記憶媒体に記憶されたデータ言語における動的変数を更新する装置であって、
   前記動的変数を含み、前記データ言語で書かれた命令を解析する手段と、
   前記動的変数を生成する手段と、
   前記動的変数の値を割り当てる手段と、
   前記動的変数の値を決定する、前記動的変数の値に関連付けられたオブジェクトを生成する手段と、
   前記動的変数に関連付けられた機能値を観察する手段と、
   前記機能値が変化した場合、前記オブジェクトに通知する手段と、
   前記動的変数を含み、前記データ言語で書かれた命令を再解析することなく、前記変化した機能値に基づいて前記動的変数の値を更新する手段と
   を備える装置。

Images