JP2004506280A - イメージおよびイメージ遷移の表示 - Google Patents

Abstract

本発明は、ソース値（ｓｏｕｒｃｅ ｖａｌｕｅ）を表現するイメージを表示するステップ、デスティネーション値（ｄｅｓｔｉｎａｔｉｏｎ ｖａｌｕｅ）を表すイメージを表示するステップ、および遷移イメージ（ｔｒａｎｓｉｔｉｏｎ ｉｍａｇｅ）を表示するステップを備える方法から構成され、ここで、遷移イメージはソース値とデスティネーション値の関数である。さらに、本発明は、グラフィックス表示装置（１０６）、メモリ（１０４）、タイミング装置（１０２）、およびこれらメモリ、タイミング装置、およびグラフィックス表示装置に結合された処理装置（１００）を備える装置から構成され、ここにおいて、処理装置は、第１の静的値（ｓｔａｔｉｃ ｖａｌｕｅ）から第２の静的値に遷移を提供するようにシステム構成されており、また、遷移は第１の静的値と第２の静的値の関数である。

Description

【０００１】
本特許は、ＤＹＮＡＧＬＹＰＨＳ社のためにＲａｂｂが２０００年８月３日に出願した米国特許仮出願第６０／２２３，２９５号に対する優先権を主張し、その全体を参照により本出願に組み込む。
【０００２】
（発明の背景）
本発明は、イメージの表示（ｄｉｓｐｌａｙ）に関するものであり、より具体的には、値集合（ｖａｌｕｅ ｓｅｔ）の一方のメンバーと値集合の他方のメンバーとの間の遷移（ｔｒａｎｓｉｔｉｏｎ）を表示（ｄｉｓｐｌａｙ）することに関する。さらに具体的には、本発明は、値集合の第１のメンバーと値集合の第２のメンバー（値集合の第１のメンバーと同じメンバーであってもよい）との間の一意的遷移を表示することに関するものであり、値集合は複数のメンバーを含み、一意的遷移は値集合の第１のメンバーと値集合の第２メンバーの関数として一意的に定義される。
【０００３】
写真などの静止イメージをその静止イメージのデジタル表現に変換できることは、当技術分野で知られている。同様に、動イメージ、すなわちビデオイメージをデジタル表現に変換することも当技術分野で知られている。通常、たとえば、コンピュータ・システム上のデジタル表現では、ビデオ・イメージは一連の静止イメージとして取り込まれる。各静止イメージは、ビデオ・イメージの一瞬をキャプチャ（とらえる）する。視聴者にとっては一連の静止イメージの高速表示により動いているように見える。
【０００４】
多くの場合、ビデオ・イメージの第１の集まりは、ビデオ・イメージの第２の集まりに連続的に合併または遷移される。一方のビデオ・イメージから第２のビデオ・イメージへの遷移を作り出すために使用される、当技術分野で知られている一般的な手法を「スイッチ（ｓｗｉｔｃｈ）」と呼ぶ。このような「スイッチ」としては、カット（ｃｕｔ）、ワイプ（ｗｉｐｅ）、フェード（ｆａｄｅ）、およびプッシュ（ｐｕｓｈ）がある。スイッチングは、テレビの生中継、たとえば、ニュース放送のときに天気予報番組の担当者からスポーツ番組の担当者にスイッチする場合に、使用されることに留意されたい。
【０００５】
上述のように、デジタル表現内のビデオ・イメージは通常静止イメージ・シーケンスである。遷移を生み出すために処理されるのがこれらの静止イメージ・シーケンスである。
【０００６】
しかし、これまで、ある静止イメージ（またはあるビデオ・イメージ）から別の静止イメージ（または別のビデオ・イメージ）への遷移は、一方の静止イメージ（または一方のビデオ・イメージ）または他方の静止イメージ（または他方のビデオ・イメージ）の関数として実行されておらず、むしろ、他方の静止イメージ（またはビデオ・イメージ）へと一方の静止イメージ（または一方のビデオ・イメージ）の単一、特定の操作を実行していた。たとえば、ワイプの場合、他方の静止イメージ（または統合のビデオ・イメージ）が他方の静止イメージ（または一方のビデオ・イメージ）上をワイプし、一方の静止イメージ（または一方のビデオ・イメージ）を置き換える。これは、一方の静止イメージ（または一方のビデオ・イメージ）および他の静止イメージ（または他のビデオ・イメージ）と無関係に全く同じ方法で実行される。
【０００７】
たとえば、イメージ・シーケンス間の遷移を行うための方法および装置は米国特許第５３５３３９１号で開示されている。‘３９１特許では、コンピュータ制御表示システム上で第１のイメージ・シーケンスと第２のイメージ・シーケンスとの間の遷移を生成し、表示するための方法と装置を開示している。ここで説明している方法は、いくつかのステップを必要とし、これらは、通常コンピュータ・システムに格納されるデジタル化された第１と第２のイメージ・シーケンスを提供するステップと、第１と第２のイメージ・シーケンスの間で遷移を行う合計時間の持続時間を与えるステップと、第１と第２のイメージ・シーケンスの間の遷移を指定する遷移リソースを与えるステップと、第１のイメージ・シーケンスの第１の部分（第１の部分は持続時間が遷移の持続時間以内である）を決定するステップと、第２のイメージ・シーケンスの第２の部分（第２のイメージ・シーケンスの第２の部分は持続時間が遷移の持続時間以内である）を決定するステップと、遷移リソースから遷移テンプレートを作成し、遷移テンプレートの持続時間が遷移に等しいステップと、第１のイメージ・シーケンスの第１の部分および第２のイメージ・シーケンスの第２の部分と遷移テンプレートとを組み合わせ、第３のイメージ・シーケンスを生成するステップを含む。遷移リソースから遷移テンプレートを作成するステップはさらに、オブジェクトを選択するステップと、オブジェクトおよび／またはソース・イメージ領域の補間を行うステップと、オブジェクトをソース・イメージ領域にマッピングするステップを含む。ステップを組み合わせることで、遷移テンプレートを使用し、第１のソース・シーケンス、第２のソース・シーケンス、またはその両方のうちのどの部分を第３のイメージ・シーケンス内に表示するかを決定する。さらに、遷移全体の持続時間を修正する手段または遷移内の個別フレームの持続時間を修正する手段も提供する。
【０００８】
そこで、上で示したように、現在のところ、値集合の中の各値から値集合の中の他の値への使用可能な遷移からなるマトリックス全体について、一意的な遷移を完全に列挙するアニメーション化インジケータ（ａｎｉｍａｔｅｄ ｉｎｄｉｃａｔｏｒ）はない。つまり、今のところ、一方の静止イメージ（または一方のビデオ・イメージ）から他方の静止イメージ（または他方のビデオ・イメージ）への遷移が一方の静止イメージ（または一方のビデオ・イメージ）または他方の静止イメージ（または他方のビデオ・イメージ）の関数として実行されるアニメーション化インジケータはない。
【０００９】
使用可能な遷移の部分集合を列挙するアニメーション化インジケータは存在し、そして上述のように、これらアニメーション化インジケータは、何らかの値から別の値への遷移を行う安価な汎用的な手段を提供する。
【００１０】
本発明は、上述の要求や他方の要求に、都合よく、対処する。
【００１１】
（発明の概要）
本発明は、値集合の一方のメンバーから値集合の他方のメンバーへの遷移を表示し、値集合は複数の値を含み、遷移が値集合のメンバーおよび値集合の他のメンバーの関数として定義される、システムおよび方法を提供することにより、上記の要求、さらに他の要求に、有利に対処する。
【００１２】
一実施形態では、本発明は、複数のソース値（ｓｏｕｒｃｅ ｖａｌｕｅ）を含むソース値集合からソース値を受け取るステップと、複数のデスティネーション値（ｄｅｓｔｉｎａｔｉｏｎ ｖａｌｕｅ）を含むデスティネーション値集合からデスティネーション値を受け取るステップと、受信されたソース値と受信されたデスティネーション値の関数路として遷移シーケンスを生成するステップ、を備える方法として特徴づけることができる。
【００１３】
他の実施形態では、本発明は、ソース値を表すイメージを表示するステップ、デスティネーション値を表すイメージを表示するステップ、および遷移イメージを表示するステップを備える方法として特徴づけることができ、遷移イメージがソース値とデスティネーション値の関数であることを特徴とする。
【００１４】
さらに他の実施形態では、本発明は、グラフィックス表示装置、メモリ、タイミング装置、および、これらメモリ、タイミング装置、およびグラフィックス表示装置に結合された処理装置、を備え、処理装置は第１の静的値から第２の静的値に遷移を提供するように構成され、遷移は第１の静的値と第２の静的値の関数であることを特徴とする。
【００１５】
さらに他の実施形態では、本発明は、メモリを備える装置として特徴づけることができ、メモリはソース値からデスティネーション値への遷移を提供するように構成されたコードを備え、遷移はソース値とデスティネーション値の関数であることを特徴とする。
【００１６】
他の実施形態では、本発明は、ソース値グループを作成するステップと、デスティネーション値グループを作成するステップと、ソース値グループの一メンバーからデスティネーション値グループの一メンバーへの遷移を作成するステップを備える方法として特徴づけることができ、遷移はソース値グループのメンバーとデスティネーション値グループのメンバーの関数であることを特徴とする。
【００１７】
さらに他の実施形態では、本発明は、複数の下位グリフを備える第１のグリフを表示するステップ、下位グリフを操作するステップ、第２のグリフを表示するステップを備える、イメージを表示する方法として特徴づけることができる。
【００１８】
他の実施形態では、本発明は、ソース値を生成するステップ、複数のデスティネーション値を生成するステップ、およびソース値からデスティネーション値への個々の遷移を生成するステップを備える、イメージを表示する方法として特徴づけることができる。
【００１９】
他の実施形態では、本発明は、複数のソース値を生成するステップ、デスティネーション値を生成するステップ、およびソース値のそれぞれからデスティネーション値への個々の遷移を生成するステップを備える、イメージを表示する方法として特徴づけることができる。
【００２０】
本発明の上記の態様および他の態様、特徴、および利点は、以下の図面とともに提示されている以下のさらに具体的な説明から明白になるであろう。
【００２１】
対応する参照文字は、複数の図面全体を通して対応するコンポーネントを示している。
【００２２】
（好ましい実施形態の詳細な説明）
現在考察している最も良い本発明の実施方法についての以下の説明は、制限するものと解釈されるべきものではなく、単に、本発明の一般的な原理を説明することを目的として、作成されている。本発明の範囲は、請求項を参照することに決定されるべきである。
【００２３】
本発明の実施形態は、アニメーション化インジケータを使用し表示する新しいプロセッサ実装システムと方法である。アニメーション化インジケータは、静的値（または静止イメージ）、または一方の静的値（または一方の静止イメージ）から他方の静的値（または他方の静止イメージ）への遷移を表示する。
【００２４】
静的値（または一方の静的値から他方の静的値への遷移で表示される中間値）は、複数の表示オブジェクトから構成される。これらの表示オブジェクトはそれぞれ、グリフと呼ばれる目に見えるシンボル、または一方のグリフから他方のグリフへの遷移を表示する。それぞれのグリフは、複数のグリフからなるアルファベットの一意的メンバーである。アルファベットのグリフは、２つ以上のメンバーから構成される。複数のグリフは、１つのシンボル、コード、またはインデックスを表すことができる。通常、これらは数字、英数字、またはその他の特殊文字を表す。
【００２５】
複数のグリフからなるすべてのアルファベットは、それに関連付けられた複数のアニメーション・スタイルを有することができる。アニメーション・スタイルは、静的な場合にそれぞれのグリフの特定の視覚的表現を定義し、それぞれのグリフから他方のグリフへの遷移の集合を定義する。まとめると、複数のグリフからなるグループは、インジケータによって表示されるべき値を表現するのに使用される。値の視覚的表現は、表示される値を構成する表示オブジェクトのグリフの集合的スタイルにより決定される。
【００２６】
インジケータは、さまざまな遷移状態にある前記値を構成する複数の表示オブジェクトを指し示すことにより、一方の値から他方の値への遷移を表示する。インジケータ、それが構成する表示オブジェクト、およびアニメーション・スタイルは、インジケータ・モデルと呼ばれる。
【００２７】
複数のグリフからなるアルファベットがあるのと全く同様に、インジケータによって表示され得る有効な値の集合もある。この集合は、ここにおいては、有効値集合と呼ぶ。最大でも、この集合は値を構成するＮ個のグリフと、アルファベットのグリフを構成するＭ個のグリフとのすべての順列からなる。この集合は、完全値集合（ｃｏｍｐｌｅｔｅ ｖａｌｕｅ ｓｅｔ）と呼び、Ｍ＾Ｎ個のメンバーを含む。通常、有効な値集合はカウンタ、タイマー、またはクロックのすべての値、または人間の言語アルファベットの（大文字または小文字のいずれかまたは両方）文字からなるテキスト単語の集合からなる。
【００２８】
本発明の実施形態により、アニメーション・スタイルは、値の表現を構成する複数のグリフのそれぞれに対して設定することができる。これらは、個別に設定することもグループとして設定することもできる。本発明の実施形態は、指定されたアニメーション時間インデックスで、複数のグリフを既存のアニメーション・スタイルに、または入力内に含まれる新しく指定したスタイルに、変更する入力を受け取ることができる。入力は、アニメーションの開始前、またはリアルタイムでインジケータが遷移を実行中のときに受け取ることができる。
【００２９】
本発明の実施形態はさらに、次のような特徴を備えるのが好ましい。つまり本実施形態は、有効値集合内の任意の値から他の任意の値への使用可能なすべての遷移を表示することができること（値集合の遷移は、シーケンシャル部分集合、ランダム部分集合、または完全値遷移集合の他の任意の部分集合、に制限されない）。本実施形態は、インジケータが値集合内の値のどれに対する遷移を実行すべきかを指定する入力を、受け取ることができること（インジケータは、他の値を通じて遷移することなく進行する、という点で一意的に連続的に指定された値への遷移を実行し、インジケータは完全値遷移集合で遷移を直接実行できる）。本実施形態は、指定された値、現在値、または将来の値から、他の指定された値への遷移、その際に特定のアニメーション時間インデックスから始めること、別のアニメーション時間インデックスで終了することを、インジケータに指定する入力を受け取ることができること（入力は、アニメーションが開始する前、またはリアルタイムでインジケータが遷移の実行中に受け取ることができる）。本実施形態は、指定されたアニメーション時間インデックスに、または指定されたアニメーション時間インデックスの範囲にわたって、インジケータ・モデルの複数のプロパティ（特性）を変更する入力を受け取ることができること（入力は、アニメーションが開始する前、またはリアルタイムでインジケータ遷移の実行中に受け取ることができる）。すべてのグリフ遷移は、相互に一意的なスタイルにより定義することができること（グリフ遷移は、スタイルによって定義された他のグリフ遷移と視覚的に一致しない）。完全値遷移集合内のすべての値遷移は相互に一意的なものとすることができること（値遷移は、他の値遷移と視覚的に一致しない）。それぞれのグリフ遷移は、開始および停止グリフ・ペアに一意的に固有のものとすることができること（すべてのグリフ遷移は、グリフ・ペアの視覚的な表現（ｖｉｓｕａｌ ｍａｎｉｆｅｓｔａｔｉｏｎ）に依存するだけでなく、遷移に固有の方法および／またはデータにも依存する）。すべての遷移には、汎用でない異様な形に変える手段、つまりグリフから他のグリフへの遷移を実行するのと全く同じ方法で適用できるような手段、を包含することができ、このような汎用の手法の例として、フェード・インおよびフェード・アウト、シマーリング（ｓｈｉｍｍｅｒｉｎｇ）、スパークリング（ｓｐａｒｋｌｉｎｇ）、単純なスクロール、またはその他のラスター・ベース変換があること。値遷移のいかなる時点でも、遷移の開始または停止値がそれぞれの停止または開始値の境界領域にわたって単純に変換されているように見えるように、インジケータは視覚的表現を表示することはしないこと。すべてのグリフ遷移は、単一の一意的な連続的遷移であるか、または中間状態を介して３つまたはそれ以上の連結された独立の部分的遷移を使用することができること（これらの部分的遷移は、他の完全なグリフ遷移を形成する際に共有できる）。グリフ遷移が中間状態を介して２つの独立の部分的遷移の連結を包含する場合、この中間状態は完全なグリフ遷移を形成する際に他のすべてのグリフ遷移により共有されないこと。
【００３０】
これらの特徴を実現するインジケータをここではダイナメート化インジケータとして引用される。
【００３１】
グリフの視覚的表現をモデル化する本実施形態による手法の新規性のある組み合わせは、Ｍ＾２個の遷移を完全に指定し、遷移指定情報を格納するために必要な作業量を大幅に低減する。主要な手法は、シンボルのスタイルの表現を構成する共通の視覚的下位要素の階層的分解にある。
【００３２】
まず図１を参照すると、本実施形態による装置はプロセッサ（ＣＰＵ）１００、タイミング装置１０２、メモリ装置１０４、グラフィックス表示装置１０６、アプリケーション・ソフトウェア１０８、およびソフトウェア・エンジン１１０で構成される。アプリケーション・ソフトウェア１０８は、ソフトウェア・エンジン１１０が本実施形態の原理により値の表示を管理する間、この装置の目的および機能の全体、つまり実質的に全体的な目的および機能とすることができるビジネス方法を実現する。アプリケーション・ソフトウェア１０８により実行される全体的な目的および機能は、本実施形態には本質的なものではなく、その代わり、本実施形態に本質的なものはインジケータの表示に集中する。
【００３３】
ソフトウェア・エンジン１１０は、インジケータ・モデルを管理し、アプリケーション・ソフトウェア１０８により使用される。ソフトウェア・エンジン１１０は、アプリケーション・ソフトウェア１０８から入力を受け取り、インジケータ・モデルに変更を加え、インジケータ・モデルにアニメーション動作を行わせる、つまり一方の値から他方の値に遷移させる。プロセッサ１００により、ソフトウェア・エンジン１１０は表示メモリ１０４にアクセスできる。ソフトウェア・エンジン１１０は、定期的に、表示メモリをインジケータの現在の視覚的状態を使用して更新する。
【００３４】
インジケータ・モデルは、インジケータの状態を表すオブジェクトである。インジケータ・モデルは、インジケータの値を構成するグリフを表す表示オブジェクトを含む。インジケータ・モデルはさらに、グリフの視覚的表現を指定するアニメーション・スタイルを保持する。
【００３５】
スタイルはユーザ定義オブジェクトである。本実施形態のコンテキストにおける「ユーザ」は、装置のエンド・ユーザではなく、アプリケーション・ソフトウェア１０８で実現されているビジネス方法を実施する際にソフトウェア・エンジン１１０を使用する装置の実装者（ｉｍｐｌｅｍｅｎｔｅｒ）、たとえば、ソフトウェア開発者である。
【００３６】
したがって、本実施形態の中心となるのはソフトウェア・エンジン１１０である。ソフトウェア・エンジン１１０は、１つまたは複数のインジケータを表示するためアプリケーション・ソフトウェア１０８（または複数のプログラム）によりユーティリティとして使用される。アプリケーション・ソフトウェア１０８は、ソフトウェア・エンジン１１０の外部にあるソフトウェアであり、他の何らかの機能、またはビジネス方法、またはプロセスを提供する。ソフトウェア・エンジン１１０は、ここで実現されているように独立して使用するものではなく、アプリケーション・ソフトウェア１０８のサービスとして使用するものである。一方、単一のソフトウェア単位で、ソフトウェア・エンジン１１０によって実行されるインジケータの表示、およびアプリケーション・ソフトウェア１０８により実行されるビジネス方法の実行を提供するように、ソフトウェア・エンジン１１０およびアプリケーション・ソフトウェア１０８を組み合わせる、ことが考えられる。
【００３７】
ソフトウェア・エンジン１１０およびアプリケーション・ソフトウェア１０８は、図２に示されているような同じコンピュータ・システム、または図３に示されているような何らかの有線または無線通信リンク、例えば、ネットワーク上を利用する分離したコンピュータ・システムのコンピュータ・メモリ内に存在することができる。
【００３８】
ソフトウェア・エンジン１１０は、ソフトウェア・エンジン１１０の機能を制御するアプリケーション・ソフトウェア１０８から入力を受け取る。この入力は、（１）新しいダイナメート化インジケータを作成するコマンド、（２）既存のダイナメート化インジケータを破棄するコマンド、または（３）ダイナメート化インジケータのプロパティを設定するコマンド、の形式を取る。コマンドはどれも、特定の時刻に即座に、または一定期間にわたって実行するように指定することができる。コマンドへの応答として、ソフトウェア・エンジン１１０はアプリケーション・ソフトウェア１０８に出力として送り返すイメージ・データを生成する（図４を参照）。
【００３９】
本実施形態を利用するためには、実装者はソフトウェア・コンポーネント（これ以降「オブジェクト」と呼ぶ）の特定の集まりを実装しなければならない。
【００４０】
図５を参照すると、ソフトウェア・エンジンは以下のソフトウェア・オブジェクトからなる。
１つまたは複数のインジケータ・モデル５００、
０個またはそれ以上のグリフ５０２、
１つまたは複数のソフトウェア・タイミング・デバイス５０４（つまり、タイミング・デバイスとインターフェースするソフトウェア・コンポーネント）、および
１つまたは複数のアニメーション・スタイル５０６。
【００４１】
ソフトウェア・エンジン１１０（図１）が現在アプリケーション・ソフトウェア１０８に対して管理している、ダイナメート化インジケータ毎に１つのインジケータ・モデル５００がある。各インジケータ・モデル５００は、０個またはそれ以上のグリフ５０２で構成され、それぞれのインジケータ・モデル５００は、１つまたは複数のアニメーション・スタイルに関連付けられる。インジケータ・モデル５００は、その関連するアニメーション・スタイル５０６を使用してそのイメージの作成を管理する。各インジケータ・モデル５００はさらに、図５に示されているように、単一のソフトウェア・タイミング・デバイス５０４に関連付けられる。ソフトウェア・タイミング・デバイス５０４は、１つまたは複数の関連するインジケータ・モデル５００に、次のイメージのデータを作成する必要のあることを知らせるタイミング入力を供給する。
【００４２】
明示的なソフトウェア・エンジン「オブジェクト」はないことに留意されたい。ソフトウェア・エンジン１１０（図１）は、オブジェクト・コード（つまり、実行可能コンピュータ命令）と、さらにメイン・メモリに格納されているソフトウェア・タイミング・デバイス５０４、アニメーション・スタイル５０６、インジケータ・モデル５００、グリフ５０２、およびその他のオブジェクトからなる。
【００４３】
本実施形態は、データを管理するモデルと、モデルに対するイメージの作成を管理するスタイルの２つの論理的／機能的セグメントに分けられる。インジケータ・モデル５００は、関連するアニメーション・スタイル５０６と連携して現在のイメージを定義する。
【００４４】
ソフトウェア・エンジン１１０内に、明示的なダイナメート化インジケータ・ソフトウェア・オブジェクトはない。ダイナメート化インジケータは、そのグリフ５０２、関連するアニメーション・スタイル５０６、および関連するソフトウェア・タイミング・デバイス５０４を備えるインジケータ・モデル５００を組み合わせたものである。これらのオブジェクトをまとめることでダイナメート化インジケータが形成される。これ以降、「インジケータ」または「インジケータ・オブジェクト」は、インジケータ・モデルを意味するものとする。構成を参照する場合、ダイナメート化インジケータという用語を使用することにする。
【００４５】
本実施形態により、インジケータ・モデル５００が表すことができる有効な値集合が決定される。この有効な値集合には、表示可能イメージにより最終的に表すことができる一意的な値を含めることができる。この集合を、インジケータ・モデルのアルファベットと呼ぶ。
【００４６】
例１
図６を参照すると、ダイナメート化された動物インジケータが示されているが、これはさまざまな動物、つまりＤｏｇ（犬）、Ｃａｔ（猫）、Ｂａｔ（コウモリ）、Ｒａｔ（ネズミ）、Ｅｌｋ（ヘラジカ）、Ｐｉｇ（豚）、Ｍａｎ（人）のイメージの集合６００を示している。Ｎｏ　ａｎｉｍａｌ（動物以外）の値も、ダイナメート化インジケータで、ｎｏ　ａｎｉｍａｌが表示されるときについて定義することができる。定義により、アルファベットは８個の一意的な値で構成される。したがって、本実施形態により、ＡｎｉｍａｌＩｎｄｉｃａｔｏｒは、一意的な遷移集合６０２内に少なくとも６４個の一意的な遷移（８×８）を持つ。
【００４７】
インジケータ・モデルは、常に静的値−状態または動的値−状態の２つの一般化された状態のうちの１つを取る。インジケータ・モデルが遷移の状態にない場合、インジケータ・モデルは静的状態（または静的値−状態）にあると考えられる。インジケータ・モデルの静的状態における値−状態は、有効な値集合のうちの現在値として定義される。インジケータ・モデルに関連付けることができるプロパティは多数あるが、値−状態はその主要なプロパティである。
【００４８】
インジケータ・モデルがその２つの値の間で遷移状態にある場合、それは動的状態にあると考えられる。動的状態におけるインジケータ・モデルの値−状態は、静的状態におけるその値−状態の先行する値（ｐｒｅｖｉｏｕｓ ｖａｌｕｅ）、および静的状態におけるその値−状態の次の値として定義され、インジケータ・モデルは、その次の値に向かって現在のステップ値に従って遷移することになる。これら２つの値−状態、つまり前の値−状態および次の値−状態は、ソース−デスティネーションのペア（ｓｒｃ−ｄｓｔと略称する）と呼ばれる。したがって、インジケータ・モデルが動的状態にあるときに、その値−状態は、現在のステップ値に従っている現在のｓｒｃ−ｄｓｔペアである。現在のステップ値は、インジケータ・モデルが前の値−状態から次の値−状態までどれだけ進行したかを表す。現在のステップ値の設定値は、重要ではないが、０．０から１．０の間のパラメータ単位値に正規化するのが好ましい。
【００４９】
インジケータ・モデルに関連付けることができるプロパティは多数あるが、値状態はその主要なプロパティである。
【００５０】
上述のように、すべてのインジケータ・モデルはソフトウェア・タイミング・デバイスに関連付けられる。本実施形態のソフトウェア・エンジンでは、ソフトウェア・タイミング・デバイスは、（実時間から相対時間への変換を提供するような）システムのタイミング・デバイスとのインターフェースを備える。それぞれのソフトウェア・タイミング・デバイスは、特定のインジケータ・モデル（または一般的に計時されるインジケータ・モデルの集合）の時間インデックス・スケール（タイム・スケールとも呼ばれる）に適合するように、システムのタイミング・デバイスを変換する。
【００５１】
ソフトウェア・エンジンが、アプリケーション・ソフトウェアから特定の時点の、または時間範囲にわたって、ダイナメート化インジケータのプロパティを設定するコマンドを受け取ると、インジケータ・モデルに関連付けられたソフトウェア・タイミング・デバイスは、コマンドの実行を時間の関数として管理する。このデバイスは、インジケータ・モデル上で実行されるときが来るまでコマンドを保管しておく。コマンドの実行の瞬間が来ると、そのデバイスは、インジケータ・モデル上の、たとえば新しい出力イメージ・データを作成する、コマンドを実行するよう信号を送る。コマンドが、ある期間（ｔｉｍｅ ｓｐａｎ）にわたって実行されるアクション用のコマンドである場合、ソフトウェア・タイミング・デバイスは、インジケータ・モデルに対して定期的に、アクションの継続するように信号を送り、インジケータ・モデル状態および／またはプロパティの更新し、および、その期間にわたる新しい出力イメージの生成する。
【００５２】
すべてのソフトウェア・タイミング・デバイスは、１つまたは複数のインジケータ・モデル、つまり１つのインジケータ・モデルまたは共通計時インジケータ・モデルの集合に関連付けることができる。ただし、それぞれのインジケータ・モデルは、単一のソフトウェア・タイミング・デバイスにのみ関連付けられる。インジケータ・モデルのように、ソフトウェア・タイミング・デバイスを１つまたは複数のアニメーション・スタイルに関連付けることができる。ソフトウェア・タイミング・デバイスのスタイルを、関連するインジケータ・モデルのデフォルト・スタイルとして使用することができる。
【００５３】
デフォルトでは、本実施形態はソフトウェア・タイミング・デバイスを完全に実装する。実装者は、実装されているインジケータ・モデルまたはアニメーション・スタイルを操作するために新しいソフトウェア・タイミング・デバイスを実装する必要はない。
【００５４】
アニメーション・スタイルは、インジケータ・モデルの視覚的表現を管理する。実装者は、ダイナメート化インジケータに関連付ける少なくとも１つのアニメーション・スタイルを定義する。アニメーション・スタイルは、複数のインジケータ・モデルに関連付けられることができる。インジケータ・モデルは、複数のアニメーションを、スタイルを使用してその外観（ｌｏｏｋ）の個別の側面を定義することができる。実装者が定義することができるアニメーション・スタイルの数に制限はない。
【００５５】
インジケータ・モデルと同様、アニメーション・スタイルは有効な値集合を定義する。実装者は、スタイルのアルファベットのそれぞれの値に対応する静止イメージの集合を、定義しなければならない。インジケータ・モデルに関連付けられるべきアニメーション・スタイルに対して、アニメータ・スタイルにより、インジケータ・モデルの有効な集合内の値毎に一意的な静止イメージを定義しなければならない。つまり、アニメーション・スタイルの有効な値集合は、インジケータ・モデルの有効な集合を完全に包含（つまり、上位集合）していなければならない。実装者は、さらに、関連するすべてのインジケータ・モデルのすべてのｓｒｃ−ｄｓｔペアに対する一意的な遷移を持つアニメーション・スタイルを定義しなければならない。まとめると、静止イメージおよび一意的な遷移は、アニメーション・スタイルの主要なプロパティであるといえる。
【００５６】
静止イメージは、アニメーション・スタイルの基部を形成し、ダイナメート化インジケータの基本的な外観（ｌｏｏｋ）を定義する。実装者は、通常、静止イメージを設計する際に一貫した視覚的テーマに従うが、アニメーション・スタイルが人間によって定義されるまたは人間が理解できる美観に従う必要はない。静止イメージの唯一の要件は、視覚的に一意であり互いに区別できることである。
【００５７】
静止イメージを表現する方法は重要でない。「イメージ」という用語を用いた場合、これは、イメージ・データまたはイメージを生成する手段を意味する。それぞれの静止イメージは、実際のイメージ・データ（たとえば、ビットマップ・データやベクトル・データ）、コンピュータ命令の集合、または下位構造の階層として表現することができる。これらの方法はすべてよく理解されている。静止イメージを描画する方法は重要でない。重要なのは、アニメーション・スタイルは、イメージ・データまたはイメージ生成命令を、関連するインジケータ・モデルのそれぞれの静的な値−状態に関連付けることが可能である、ということである。
【００５８】
例１（続き）
ＺｏｏＰｉｃｔｕｒｅＳｔｙｌｅ、ＫａｎｊｉＮａｍｅＳｔｙｌｅ、およびＬａｂＤＮＡＳｔｙｌｅという３つのアニメーション・スタイルが定義されている。ＺｏｏＰｉｃｔｕｒｅＳｔｙｌｅ　４０については動物園の動物のスケッチに基づくイメージが作成されている。ＫａｎｊｉＮａｍｅＳｔｙｌｅについては、漢字の単語を使用して記述されているすべての動物名を表すのに必要なデータが集められている。ＬａｂＤＮＡＳｔｙｌｅについては、ＡｎｉｍａｌＩｎｄｉｃａｔｏｒで指定された７つの動物のそれぞれの染色体（ｃｈｒｏｍｏｓｏｍｅｓ）のイメージと、ｎｏ−ａｎｉｍａｌの値に対する空（ｅｍｐｔｙ）の背景イメージを生成するためのデータが集められている。いくつかの定義されているアニメーション・スタイルが、ＡｎｉｍａｌＩｎｄｉｃａｔｏｒのインジケータ・モデルで要求される以上の多くの静止イメージを指定することは重要でない。重要なのは、ＡｎｉｍａｌＩｎｄｉｃａｔｏｒインジケータ・モデルの静的な値−状態のそれぞれに対する一意的なイメージを、そのスタイルが収容することである。関連付けられているインジケータ・モデルの値−状態よりも大きな静止イメージ集合を定義することにより、スタイルは、この例で最初に定義した８個よりも多いさまざまな値をインジケータ・モデルに供給することができる。
【００５９】
ダイナメート化インジケータが一方の値から他方の値に遷移するときに、ダイナメート化インジケータのインジケータ・モデルは、関連するソフトウェア・タイミング・デバイスから周期的信号を受信し、インジケータ・モデルの現在の値−状態のイメージを出力する。インジケータ・モデルは、アニメーション・スタイルと協調して、インジケータ・モデルの現在の値−集合に対応するイメージを出力する。これらの周期的信号により、インジケータ・モデルは、動的な値−状態を通る遷移を表すイメージ・シーケンスを生成する。
【００６０】
インジケータ・モデルの関連するアニメーション・スタイル毎に、実装者は、関連するインジケータ・モデルが遷移する、使用可能なｓｒｃ−ｄｓｔペアについて、一意的な遷移を指定しなければならない。最低でも、アニメーション・スタイルはＮ＾２個の一意的な遷移を定義しなければならない。
【００６１】
実装者は、それぞれの遷移の外観および振る舞いの基本として、アニメーション・スタイルの静止イメージを使用する。それぞれの遷移シーケンスには、（１）各シーケンスは、インジケータ・モデルの現在の動的な値−状態を表すｓｒｃ−ｄｓｔペアの静止イメージで始まり静止イメージで終わる、（２）各遷移シーケンスは少なくとも１つの中間イメージを定義する、（３）遷移シーケンスの中間イメージのそれぞれはｓｒｃ−ｄｓｔペアの静止イメージとは異なる、（４）それぞれの遷移シーケンスは他のｓｒｃ−ｄｓｔペアの遷移シーケンスとは異なる、という４つの必要条件がある。ｓｒｃ−ｄｓｔペアについて生成できる使用可能な遷移の数に制限はない（また、したがって、得られる視覚的表現の数も制限はない）。
【００６２】
実装者は、アニメーション・スタイルのそれぞれの遷移の外観および振る舞いを定義した後、その「遷移の手段（ｍｅａｎｓ ｏｆ ｔｒａｎｓｉｔｉｏｎ）」を定義しなければならない。遷移の手段は、遷移シーケンス毎に一意的なイメージのシーケンスを生成するために使用される方法である。遷移の手段は、実装者のアニメーション・スタイルの中から、選択された遷移の方法の設定に存在する。遷移の手段は、ｓｒｃ−ｄｓｔ遷移のそれぞれを表す、事前に生成されているイメージ・データのシーケンスの順に、複雑なモーフィングから単純にアクセスする方法までどのようなアニメーション手法をも採用できる。しかし、採用する遷移の実際の手段は重要でない。
【００６３】
アニメーション・スタイルの静止イメージの場合と同様、遷移のスタイルにより生成されるイメージの遷移シーケンスを表現することは重要なことではない。イメージは、ビットマップ・データまたはベクトル・ベースのデータ、またはコンピュータ命令、または下位構造またはその他の組成データまたは命令の階層として定義することができる。
【００６４】
例１（続き）
アニメーション・スタイルのそれぞれについて、実装者はＡｎｉｍａｌＩｎｄｉｃａｔｏｒインジケータ・モデルのすべてのｓｒｃ−ｄｓｔペアに対する遷移の手段を定義する。ＡｎｉｍａｌＩｎｄｉｃａｔｏｒインジケータ・モデルは、６４個の遷移が定義される８個の値からなるアルファベットを持つ。アニメーション・スタイルに関して、所望する場合、実装者はｓｒｃ−ｄｓｔペア毎に遷移についての複数のオプション手段を装備することができる。遷移のオプションの手段を定義すると、遷移の数がＮ＾２を超える。
【００６５】
インジケータ・モデルが、そのプロパティの１つを設定する信号または他の方法で自動的に更新する信号を受信した場合、選択されたアニメーション・スタイルと連携して、その変更を、管理し、達成し、新しいイメージを出力する。
【００６６】
この信号は、インジケータ・モデルに変更を加えるのに必要なアクションを指定する。変更が実行されるときに、その変更は、信号が発生したときの現在の時間インデックスを含むことができる。信号が、ある期間にわたって発生する変更の場合、その信号はオプションでその期間を含むことがある。その時間範囲から、０．０と１．０の間のパラメータ単位値を計算することができる。
【００６７】
この場合も、重要な主要プロパティはインジケータ・モデルの現在の値−状態である。インジケータ・モデルに対し一方のスタイルから他方のスタイルへの変更するように信号を送ることができることにも留意されたい。
【００６８】
インジケータ・モデルの値−状態が変化した後、インジケータ・モデルは選択したアニメーション・スタイルと連携して、出力イメージを生成する。インジケータ・モデルが静的状態にある場合、選択されたアニメーション・スタイルは単に、インジケータ・モデルの値に対応する関連する静止イメージを出力するだけである。インジケータ・モデルが動的状態にある場合、選択されたアニメーション・スタイルは遷移の手段を使用して出力イメージを決定する。
【００６９】
インジケータ・モデルが動的状態にある場合、アニメーション・スタイルは、インジケータ・モデルの現在の値−状態のｓｒｃ−ｄｓｔペアと現在のステップ値を、出力イメージを生成する際の主パラメータとして、使用する。実装者が特定のｓｒｃ−ｄｓｔペアに対して複数の遷移シーケンスを持つようにスタイルを定義している場合、アニメーション・スタイルは、１つまたは複数の二次パラメータを使用して適切な遷移手段を選択する。アニメーション・スタイルは、さらに、出力イメージを生成するときの視認性、サイズ、および配色（ｃｏｌｏｒ ｓｃｈｅｍｅ）などの、インジケータの他のプロパティも考慮できる。
【００７０】
アニメーション・スタイルは、インジケータ・モデルの現在の値−状態を表すイメージを生成する静的手段および動的手段の組み合わせを、使用することができる。動的手段では、一次パラメータ、二次パラメータ、およびオプション・パラメータを、リアルタイムでイメージを生成するための直接データとして使用する計算を、必然的に含んでいる。
【００７１】
静的手段は、パラメータをキーとして使用して索引付けしたルックアップ・テーブルを使用することにより、さらに簡単に採用することができる。それぞれの入力でのデータは、有用な形式、たとえば、事前に生成されたイメージ、イメージを生成する個々のコンピュータによる方法、圧縮ムービーのフレームなどの有用な形式である。
【００７２】
本実施形態で採用しているデフォルトの方法は、静的な手法と動的な手法の両方を組み合わせた方法である。この方法では、ｓｒｃ−ｄｓｔペアと、ルックアップ・テーブルに索引付けするキーとしての二次パラメータを組み合わせている。ルックアップ・テーブルのそれぞれのエントリには、選択された遷移シーケンスに固有のデータが含まれる。このデータは、インジケータの値−状態の現在のステップ値とともに使用され、リアルタイムで現在の出力イメージを生成する。そのデータは、イメージを生成するためにアニメーション・スタイルで使用されるパラメータの形式、またはイメージ・シーケンスの生成を行うための個別の自己充足型の方法の形式、とすることができる。
【００７３】
本実施形態はさらに、データを、格納済みのイメージのあらかじめ生成されたシーケンスとするオプションも実装する。この基本的な方法では、現在のステップ値使用して、遷移シーケンスから適切なイメージ・フレームを選択する。この方法は、特定の遷移シーケンスを実行する毎に再計算する必要がないように、遷移イメージをキャッシュするため使用できる、という点でより複雑な方法のコンテキストにおいて有用である。
【００７４】
テーブルの中のそれぞれのエントリにおけるデータの正確な種類は、この実施形態では重要でない。必要なのは、そのデータが、指定された一意的遷移の一部としてイメージをスタイルが出力できるようにする、という点である。同様に、テーブルを配列、マトリックス、辞書、または当分野で知られているデータ構造として実装するかどうかも重要でない。
【００７５】
最終的に、本実施形態を利用することで、実装者は、選択したあるスタイル用の遷移の手段であってもそれを自由に定義することができる。
【００７６】
一般に、ほとんどのインジケータ（つまり、非ダイナメート化インジケータ）は、視覚的に、類似の下位要素から構成される。同じことがほとんどのダイナメート化インジケータについてもいえる。実装者は、ここでグリフと呼んでいる下位構成要素（下位オブジェクト）を使用してインジケータ・モデルを構成することにより、この事実を活かすことができる。インジケータ・モデルは、０個またはそれ以上のグリフ（またはグリフ・オブジェクト）で構成することができる。インジケータ・モデルは、そのグリフの「コンテキスト」である。グリフは、「親」コンテキスト、つまりインジケータ・モデルを１つ持つだけである。
【００７７】
あらゆる意図および目的に関して、グリフはそれ自体インジケータである。インジケータ・モデルのすべての動作はグリフにも適用される。単語グリフを使用するのは、単に説明するためにすぎない。単語グリフのすべての使用は、インジケータ・モデル、下位インジケータ、または下位オブジェクトとして解釈することができる。
【００７８】
インジケータ・モデルのように、グリフは、現在のイメージを出力するため関連するスタイルと連携するという点でモデルでもある。実装者がグリフをスタイルに明示的に関連付けない場合、本実施形態ではデフォルトで、グリフにその親インジケータ・モデルのスタイルを取り込む。グリフは、インジケータ・モデルとして自らその下位オブジェクトで構成することができる。
【００７９】
インジケータ・モデルが下位インジケータを収容する場合、インジケータ・モデルの出力イメージは、インジケータ・モデル自身のイメージの合成であり、インジケータ・モデルの下位インジケータによって生成されるものである。通常、インジケータ・モデルに下位インジケータがある場合、インジケータ・モデルは単に、それ自身の管轄する出力イメージに寄与することなく、下位インジケータの出力イメージを構成する（組み合わせる）。
【００８０】
インジケータ・モデルは、下位インジケータを使用して、値−状態間の遷移を補助し、出力されるイメージのセクションを視覚的に構成することができる。インジケータ・モデルのそれぞれの下位インジケータは、それ自体のアニメーション・スタイルに関連付けることができる。そのため、ダイナメート化インジケータは、複数のスタイルを一度に表示しながら表示することができる。
【００８１】
例２
図７を参照すると、ＨｅａｒｔＩｎｄｉｃａｔｏｒインジケータ・モデルが、０〜２００の有効な値範囲で定義されている。ハート・モニタの値が変化すると、次の心拍数値への数値の移動の表示がアニメ化される。３つのグリフ集合が、ＨｅａｒｔＩｎｄｉｃａｔｏｒインジケータ・モデルを構成するのに使用され、ディジット毎に１つのグリフ集合が使用されている。
【００８２】
２つのアニメーション・スタイルが、ＨｅａｒｔＩｎｄｉｃａｔｏｒハート・モニタに実装された状態で使用されている。最初のスタイルＤｏｔＤｉｇｉｔｓは、実装者によって実装されている。ＦＯＬＤＩＮＧＤＩＧＩＴＳ（商標）は、本実施形態によるソフトウェア・エンジンの提供者からライセンスを受けている。インジケータ・モデルの１００のディジット（グリフ）は、ＤｏｔＤｉｇｉｔｓアニメーション・スタイルに関連付けられている。ハート・モニタのインジケータ・モデルは、ＦＯＬＤＩＮＧＤＩＧＩＴＳ（商標）アニメーション・スタイルに関連付けられている。１のディジットと１０のディジットは明示的にはアニメーション・スタイルに関連付けられていないため、１のディジット（グリフ）と１０のディジット（グリフ）では親のコンテキスト、つまりそれらのインジケータ・モデルから、ＦＯＬＤＩＮＧＤＩＧＩＴＳ（商標）スタイルを採用する。図７の最下段にあるディジット（ｄｉｇｉｔ）は、ダイナメート化インジケータの現在の値−状態が１２９である場合のハート・モニタのダイナメート化インジケータを示すイメージを示す。ダッシュの矩形はそれぞれ、各グリフがかかわる出力イメージの領域、つまり１００の位、１０の位、および１の位である。上方の陰影領域は、ダイナメート化インジケータを構成する実際のオブジェクトを表す。
【００８３】
それぞれの下位インジケータ（グリフ）は出力イメージの領域を管理できる。インジケータ・モデルのグリフ（複数）がこれを行う場合、共同して、それらは、それらのインジケータ・モデルの一意的な遷移の完全なマトリックスを実現する。
【００８４】
本実施例によれば、１０のディジット（グリフ）と１のディジット（グリフ）は値０〜９を表現できなければならない。１０のディジットは、さらに、ブランク状態を表現できなければならない。ＦＯＬＤＩＮＧＤＩＧＩＴＳ（商標）アニメーション・スタイルは、ブランク状態とともにすべてのディジットについて遷移の完全なダイナメート化マトリックスを実装する。そのため、ＦＯＬＤＩＮＧＤＩＧＩＴＳ（商標）アニメーション・スタイルは、１０のディジットまたは１のディジットのそれぞれ遷移に必要な１２１個および１００個の遷移をすべて指示できる。１００のディジットは、ディジット１および２およびブランク状態のみを表現しなければならないので異なる範囲を持つ。ＤｏｔＤｉｇｉｔｓスタイルの遷移の手段は、必要な８つすべての遷移、つまりブランク−＞１、ブランク−＞２、１−＞ブランク、１−＞１、１−＞２、２−＞１、２−＞２、および２−＞ブランクについての遷移に対して、配信し、実装する。このグリフについては、ブランク−＞ブランクの遷移は存在しない。
【００８５】
前述のディジットのそれぞれは、それ自体完全にダイナメート化されたインジケータである。これらは共にＨｅａｒｔＩｎｄｉｃａｔｏｒダイナメート化インジケータを構成する。これらは全体としてＨｅａｒｔＩｎｄｉｃａｔｏｒダイナメート化インジケータの使用可能な４０４０１（２０１×２０１）個のｓｒｃ−ｄｓｔペアのそれぞれについて一意的な遷移を出力する。ＨｅａｒｔＩｎｄｉｃａｔｏｒダイナメート化インジケータのそれぞれの遷移はソース値とデスティネーション値に明示的に依存する。
【００８６】
上述のように、アニメーション・スタイルは、特定の種類のインジケータ・モデルを使用して操作するために実装者が実装する。特定のインジケータ・モデルに関連付けられるには、アニメーション・スタイルの有効な値集合は、インジケータの有効な値集合の上位集合（ｓｕｐｅｒ−ｓｅｔ）でなければならない。それとは別に、その下位インジケータ（グリフ）を代わりにサポートすることにより、アニメーション・スタイルは、インジケータ・モデルを間接的にサポートするよう実装することができる。上のハート・モニタの例では、ＦＯＬＤＩＮＧＤＩＧＩＴＳ（商標）アニメーション・スタイルは、集合０〜９とブランク状態のうちの有効な値のみをサポートする。これは有効な値のＨｅａｒｔＩｎｄｉｃａｔｏｒ集合（０〜２００）の部分集合（ｓｕｂｓｅｔ）にすぎない。しかし、ＦＯＬＤＩＮＧＤＩＧＩＴＳ（商標）は、ディジット・ベースのすべてのカウンタ・インジケータを操作するために実装されている。関連付けられているカウンタ・インジケータがカウンタの集合内のすべての有効な値を表すのに十分な程度、ディジット下位インジケータ（グリフ）を定義することを確実にすることによって、これを行う。
【００８７】
アニメーション・スタイルは、インジケータ・モデルへの下位インジケータ（グリフ）の追加または削除を行ったり、必要に応じての下位インジケータのプロパティを設定するように実装することができる。インジケータ・モデルが、そのインジケータ・モデルを明示的にはサポートしていないアニメーション・スタイルと連携しようとする場合、本実施形態で採用しているデフォルトの方法は、代わりにそのアニメーション・スタイルがそのインジケータ・モデルの下位インジケータ（グリフ）と連携するようにする方法である。アニメーション・スタイルは、サポートするすべての種類のインジケータ・モデルに対して、イメージの個々の集合と遷移の手段を収容するように、実装することができる。
【００８８】
インジケータ・モデル、グリフ、およびソフトウェア・タイミング・デバイスはすべてモデルである。これらはすべて、関連するアニメーション・スタイルを備えることができ、関連するオブジェクトの階層内に組み込むことができる。ソフトウェア・エンジンは、複数のソフトウェア・タイミング・デバイスを管理することができる。ソフトウェア・エンジンのソフトウェア・タイミング・デバイスは、ソフトウェア・エンジンのモデル・オブジェクト階層のルート・オブジェクトである。それぞれのソフトウェア・タイミング・デバイスは１つまたは複数のインジケータ・モデルに関連付けられる。インジケータ・モデルのそれぞれについて、ソフトウェア・タイミング・デバイスはその親コンテキストとなる。ソフトウェア・タイミング・デバイスは明示的な親コンテキストを持たない。
【００８９】
同様に、それぞれのインジケータ・モデルは、０個またはそれ以上の下位インジケータ（グリフ）に関連付けることができる。これらの下位インジケータについて、参照インジケータ・モデルは、その親コンテキストである。これらの下位インジケータのそれぞれが次々に、下位インジケータ（下位グリフ）で構成されることができる。それぞれのインジケータは、コンテキスト階層のルートに到達するまで親コンテキストの経路をたどることにより関連するソフトウェア・タイミング・デバイスにアクセスすることができる。それとは別に、インジケータ・モデルは、ソフトウェア・タイミング・デバイスへの直接参照を使用するように実装することもできる。
【００９０】
このようにしてインジケータ・モデルの下位インジケータを編成することの利点の１つに、インジケータ・モデルがコンテキストの系統からプロパティを取り出すために、階層を利用できることがあげられる。インジケータ・モデル（または下位インジケータ）がそのプロパティの１つについて値を定義していない場合、インジケータ・モデルは親コンテキストによって定義された値を自分の値として使用する。親コンテキストも値を定義していない場合、その次のコンテキストに対し値のチェックが行われる。値の検索は、そのプロパティを定義しているモデルが見つかるまで、階層の最上位に向かって続く。そのプロパティが、ソフトウェア・タイミング・デバイスまたは特定の階層内のインジケータ・モデルまたは下位インジケータにより定義されていない場合、元々のインジケータ・モデル（または下位インジケータ）はそのプロパティに対してデフォルト値を使用する。
【００９１】
すべてのインジケータ・モデル（または下位インジケータ）は、値−状態などのいくつかのプロパティを、直接的に、収容する。他のプロパティは、収容されず、そのプロパティに対する値またはデフォルト値を提供するインジケータの上位階層に依存する。図８を参照。
【００９２】
図８は、上述のＦＯＬＤＩＮＧＤＩＧＩＴＳ（商標）アニメーション・スタイルを使用して単一ディジットのダイナメート化インジケータ例を構成するオブジェクトを示している。そのインジケータ・モデルは、現在、数６の静的な値−状態と数９の静的な値−状態の間の遷移シーケンスから得られるイメージを示している。そのインジケータ・モデルは、遷移シーケンスの始めから終わりまでの道程の４０％の地点にある。祖父（または親）インジケータ・モデル（または下位インジケータ）、カウンタ（また１のディジット）のスタイルを採用するため、セグメント（下位グリフ）のどれも、自分のアニメーション・スタイルを指定していない。
【００９３】
同様に、下位グリフは自己の視認性（ｖｉｓｉｂｉｌｉｔｙ）に対する値を指定しないので、このタイミング・デバイスでは、それらの曾祖父の視認性を採用する。階層内のインジケータ・モデルのいずれも色に対し値を指定しないため、色プロパティに対するデフォルト値が使用される。
【００９４】
グリフの色のほかに管理できる階層の、他のさまざまな、プロパティがある。インジケータの視覚的な面は、プロパティ、たとえば、背景、下位グリフの形状、を使用する。視覚的プロパティのように、タイミング・プロパティは、思いのままに、たとえば、遷移のテンポ、時間インデックス毎のフレーム数、タイム・スケール（つまり、インデックス当たりのフレーム数）、で設定および変更が可能である。タイミング・プロパティが通常、タイミング・デバイス内に格納され、管理されると同時に、どのインジケータ・モデルもさらに自己のタイミング・プロパティを収容することができる。
【００９５】
インジケータ・モデルは、すべて、その各値−状態に対するそれら独自の値を収容する。図に示されているケースでは、第１、第２、第５、および第６の下位グリフは静的状態にあり、現在のステップ値を必要としない。第３および第４の下位グリフは動的状態にあり、それが生じている遷移がどの程度かを知るために現在のステップを必要とする。下位グリフは、それ独自の現在のステップを定義しないので、親の現在のステップ、つまりディジット・グリフを採用する。
【００９６】
インジケータ・モデルのプロパティが設定されている場合、直接的にそのプロパティを収容しているのであれば、新しい値がインジケータ・モデル自体の中に格納される。そうでない場合、その値は辞書データ構造内に格納され、そこではプロパティの名前がキーとして使用される。
【００９７】
この手法は、各インジケータ・モデル（または下位インジケータ）に必要なメモリを低減するために、実装者が使用することができる。通常デフォルト値に依存するプロパティ、または特定のインジケータ・モデル（または下位インジケータ）に対しあまり頻繁に必要とされないプロパティは、必要なときのみ備えることができる。この手法は、実行速度がメモリ消費量よりも重要な場合に避けることができる。
【００９８】
インジケータ・モデル（または下位インジケータ）のプロパティを設定しても、そのプロパティの親コンテキストの値は影響を受けない。インジケータ・モデルが複数の下位インジケータを備えている場合、その下位インジケータが自己のプロパティに対して値を定義していないのであれば、その下位インジケータのプロパティの値は、インジケータ・モデルの値となる。
【００９９】
インジケータ・モデルのプロパティを設定した場合は必ず、インジケータ・モデルは、その親コンテキストだけでなく、その下位インジケータのすべてに通知する。そのインジケータ・モデルのそれぞれに対し、その親コンテキストまたは下位インジケータで発生した変更に適応するように、それぞれのアニメーション・スタイルと連携する機会が与えられる。
【０１００】
すでに述べたように、アニメーション・スタイルは、下位インジケータを他のインジケータに動的に追加したり削除したりする形で実装することができる。図８のグリフは、６個の下位グリフから成り立っている。６−＞９の遷移が完了した後、そのグリフは８への遷移の入力を受け取ると仮定する。そのグリフは、アニメーション・スタイルＦＯＬＤＩＮＧＤＩＧＩＴＳ（商標）と連携して遷移を実行する。スタイルが指定されたグリフは、遷移９−＞８を表示するためには７セグメントを必要とする（図３０を参照）。そのグリフは現在、６セグメントの下位グリフのみを持つので、そのスタイルは、もう１つセグメントをそのグリフに追加することになる。
【０１０１】
グリフが、８−＞４、次に４−＞３の遷移の実行を指令されて、８−＞４の遷移を遂行したとすると、７セグメントはまだ必要であり（図２９を参照）、したがって下位グリフは追加または削除されない。しかし、遷移４−＞３を実行する場合は、５セグメントで足りる（図２４を参照）。グリフのスタイルは、そのグリフに下位グリフの２つを取り除かせる。
【０１０２】
上述のように、インジケータ・モデルが、そのプロパティの１つを特定の時間インデックス、またはある期間にわたる態様で備えるべきであるとした場合、そのソフトウェア・タイミング・デバイスが、それに信号を送信する。テンポなどのタイミング・プロパティであっても、また時間インデックス当たりのフレーム数も、特定の時間インデックスでまたはある期間にわたって設定することができる。
【０１０３】
インジケータ・モデルは、計時信号オブジェクトを使用して、時間インデックスでまたはある期間にわたって発生するアクションを記録する。特定の時間インデックス（の態様）で発生する信号を、ここでは「ワンショット」信号を呼び、時間インデックス期間にわたって発生する信号を、ここでは反復信号と呼ぶ。ワンショット信号のアクションは１回実行され、反復信号のアクションは複数回にわたって実行される。反復アクションは、その期間の開始時間インデックスと停止時間インデックスを備えている。ワンショット・アクションの場合、開始および停止インデックスは同じ値に設定される。すべての計時信号は、ターゲット・インジケータ・モデル、発生する（主）アクション、およびオプションにより、計時信号で実行するアクションの種類を識別するＩＤ、を備えている。
【０１０４】
ソフトウェア・タイミング・デバイスでは、保留計時信号を、最も早い開始時間インデックスを持つ信号を優先する優先待ち行列に格納する。複数の信号に同じ開始時間インデックスがある場合、早期の停止時間インデックスを持つ信号に優先度を与える。
【０１０５】
反復信号の主（反復）アクションに加えて、反復信号はオプションの設定アクションとオプションの後処理アクションを持つことができる。ソフトウェア・タイミング・デバイスの現在時間インデックスが反復信号の開始時間インデックスよりも大きいかまたは等しくなると、反復信号の設定アクションが１回だけ実行される。設定アクションは、主（反復）アクションが最初に実行される前に必ず実行される。ソフトウェア・タイミング・デバイスの現在時間インデックスが反復信号の停止時間インデックスよりも大きくなると、反復信号の後処理アクションが１回だけ実行される。後処理アクションは、主（反復）アクションが最後に実行された後に必ず実行される。
【０１０６】
ソフトウェア・タイミング・デバイスは、プロセッサを介して主タイミング・デバイスから送られてきた更新信号を受信し、マスター時間インデックスを追跡する。プロセッサはこれらの信号を要求されたその時間ちょうどに定期的に送るのが理想的である。しかし、現実には、多くのシステムにおいて要求された更新時間に大きな変動があることが多い。残念なことに、さまざまな理由から、コンピュータ・システムが、実行されているソフトウェアのすべてのコンポーネントに、精密なタイミングで更新信号を送信することは困難であるか、または計算処理的に非常にコストがかかることが多い、ということが当技術分野でよく理解されている。
【０１０７】
このような問題の対処を試みる時宜を得た態様で、信号を送信しなければならないソフトウェア・システムにおいて、さまざまな方法がある。時宜を得た態様での信号の配信が正しく処理されないと、システムのロジックに問題に生じる可能性がある。これは最終的に、システムがサポートするアニメーションにマイナスの効果を及ぼす。本実施形態ではタイミングが不規則であったり、さらには非常に遅れたとしてもインジケータ・モデルが常に特定のアクションを実行できることを確実にするために、設定アクションと後処理アクションを用いる。
【０１０８】
非常に遅れるということは、ソフトウェア・タイミング・デバイスがインジケータ・モデルの遷移シーケンスで受信することが「期待」される更新信号を受信したが、遷移シーケンス全体が完了してしまった後、実際に、第２の遷移シーケンスが開始されてしまった後に、非常に遅れて、その信号が発生する、ことを意味する。この様な場合、エンジンはそのタイム・スロットの間に実行されなかった遷移シーケンスをスキップすることができる。残念なことに、このようなアプローチは、第３の遷移シーケンスが、第２の遷移シーケンス、つまりスキップされた遷移シーケンスの期間に発生した特定のアクションを必要とした場合には、適切に機能しない。本実施形態による設定アクションと後処理アクションの使用は、スキップされた遷移シーケンスが依然として必要な開始および終了アクションを実行することを確実にする。
【０１０９】
実装者がインジケータ・モデルを定義するとき、その実装者は、インジケータ・モデルに特有のプロパティが変化する場合に実行するアクションを、定義する。実装者は、時間範囲にわたって発生する変更に関して特定の設定および後処理アクションを定義すること、を選択することもできる。
【０１１０】
図９を参照すると、デバイスは、主タイミング・デバイスのマスター時間インデックスを自分の時間スケールにマッピングし（ブロック９００）、ソフトウェア・タイミング・デバイスの現在の時間インデックスを計算することにより更新プロセスを開始する。ソフトウェア・タイミング・デバイスは、リストを用いて反復する信号を保持し、「次回ウェイクアップ時間インデックス（ｎｅｘｔ ｗａｋｅｕｐ ｔｉｍｅ−ｉｎｄｅｘ）」を保持する変数を初期化する（ブロック９０２）。次回ウェイクアップ時間インデックスは、更新プロセスを再度開始するために、ソフトウェア・タイミング・デバイスがプロセッサから更新信号を受信する時間インデックスである。
【０１１１】
ソフトウェア・タイミング・デバイスは優先待ち行列内の最初の計時信号をチェックする（ブロック９０４）。現在の時間インデックスが第１の計時信号のアクション時間インデックスに等しいかあるいはそれ以上の場合（ブロック９０６）、第１の計時信号（または現在の信号）は優先待ち行列から削除され（ブロック９０８）、実行される。
【０１１２】
これが、実行中の現在の信号の最初の時間であれば（ブロック９１０）、ソフトウェア・タイミング・デバイスは現在の信号に類似する信号で、すでに実行された信号がないか調べる。もしあれば、前に実行された信号をプリエンプト（ｐｒｅｅｍｐｔｅｄ）する。ソフトウェア・タイミング・デバイスは、反復リストに現在の信号と同じＩＤを持つ前の信号が含まれているか調べる（ブロック９１２）。もし含まれていれば、ソフトウェア・タイミング・デバイスは強制的に、前の信号で後処理アクションを実行させ（ブロック９１４）、前の信号をリストから削除する（ブロック９１４）。現在の信号に設定アクションがあれば、現在の信号の設定アクションが実行される（ブロック９１６）。
【０１１３】
これが、実行中の現在の信号の最初の時間かどうかに関係なく、現在の信号の一次アクションが実行される（ブロック９１８）。
【０１１４】
現在の時間インデックスが現在の信号停止時間インデックスよりも大きい場合（ブロック９２０）、現在の信号の後処理アクションが実行される（ブロック９２２）。大きくない場合、現在の信号がソフトウェア・タイミング・デバイスの反復リストに追加される（ブロック９２４）。すると現在の信号により、現在の時間インデックスと現在の信号の自更新間隔を使用して次回アクション時間インデックスを計算する。ソフトウェア・タイミング・デバイスは、この次回アクション時間インデックスが次回ウェイクアップ時間インデックスの現在値よりも早い場合（ブロック９２８）、これをを次回ウェイクアップ時間インデックスとして格納する（ブロック９２６）。
【０１１５】
信号のアクションが実行されると、必ず、現在の時間インデックスおよび信号自体がオプション・パラメータとしてアクションに渡される。
【０１１６】
プロセスは、待ち行列に残されているすべての計時信号について繰り返される。このプロセスは、現在の時間インデックスが待ち行列内の現在の最初の計時信号のアクション時間インデックスよりも小さい場合、切り上げて終了される（ブロック９０６）。
【０１１７】
ソフトウェア・タイミング・デバイスが待ち行列の実行を完了すると、ソフトウェア・タイミング・デバイスは反復リスト内のすべての計時信号を優先待ち行列に返す（ブロック９３０）。その後、ソフトウェア・タイミング・デバイスは、プロセッサが次回ウェイクアップ時間インデックスにおいてそれにウェイクアップ信号を送信することを要求する（ブロック９３２）。最後に、ソフトウェア・タイミング・デバイスは、（前の更新プロセスにより）変更された関連するすべてのインジケータ・モデルに、それ自体の妥当性を確認し、その後新しい出力イメージを生成する、命令を出す（ブロック９３４）。
【０１１８】
ソフトウェア・タイミング・デバイスのインジケータ・モデルが更新された後、それぞれのインジケータ・モデルは、自己妥当性確認を行い、新しいイメージを生成する。デフォルトでは、インジケータは、アニメーション・スタイルを連携し、その下位階層内の下位インジケータの妥当性確認を再帰的に行うことによって、自己の妥当性確認を行う。妥当性確認は、更新に適応するためにインジケータ・モデルが実行しなければならないタスクを必然的に含む。インジケータ・モデルは、新しい出力イメージを生成する前に、整合性のとれた状態（ｃｏｎｓｉｓｔｅｎｔ ｓｔａｔｅ）になければならない。
【０１１９】
デフォルトで、イメージ生成は、妥当性確認と同じ再帰的プロセスを使用する。各インジケータ・モデルはアニメーション・スタイルと連携して、現在の値−状態を表すイメージ・データを生成する。インジケータ・モデルの階層内の下位インジケータのイメージを合成して、単一の最終的な出力イメージを作成する。
【０１２０】
実装者は、妥当性確認を行い、実装者が実装するインジケータ・モデルおよびスタイルによる出力イメージの生成を行うのに必要なアクションを定義しなければならない。本実施形態では、実装者は必要に応じて妥当性確認及びイメージ出力の再帰的な性質を自由に変更できる。
【０１２１】
本実施形態は、現在のところ、Ｓｍａｌｌｔａｌｋ言語の派生言語であるＳｑｕｅａｋを用いて実装されている。ただし、本実施形態は、決して、このオブジェクト指向プログラミング言語やその他のオブジェクト指向プログラミング言語に限定されるわけではない。本実施形態は、さまざまな他のプログラミング・システムを用いて容易に実装可能である。
【０１２２】
図１０を参照すると、ＤｙｎａＧｌｙｐｈソフトウェア・フレームワークのクラス階層は、ｍｏｄｉｆｉｅｄＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）形式で表されており、これは本実施形態のコア・オブジェクト・クラスを抽象したものである。図１０のそれぞれのブロックは１つのクラスを表す。クラスの名前とそのクラスの各インスタンスの定義済み属性がそれぞれ仕切り線の上下に示されている。クラスの名前は、クラスが抽象クラスであれば斜体で表記されている。スーパー・クラスは、三角形の継承マーカーによりそのサブ・クラスに接続している。波線は、フレームワークの厳密には一部でなく、実装者が実装しなければならないクラスを接続している。
【０１２３】
リスト内で、属性はダッシュまたは星印がその前に付いている。属性の前にダッシュが付いている場合、属性はインスタンス変数である、つまりクラスの各インスタンスはその属性に対応する自分の値を持つことができる。星印が前についている場合、属性はクラス変数である、つまりその属性はそのクラスのすべてのインスタンスにより共有される。各属性の後に、その属性の型の表示が来る。型は、基本型、またはＤｙｎａＧｌｙｐｈフレームワークによって定義された型（クラス）の１つへの参照、である。一重矢印は、参照クラスのインスタンスがその被参照クラスの単一インスタンスを参照することを示す。二重矢印は、１つまたは複数のインスタンスが参照されていることを示す。矢印の根元がひし形の場合、これは従属関係を示す。
【０１２４】
図には、各クラスの最も重要な属性のみ示されている。具象ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔおよびＡｎｉｍａｔｉｏｎＳｔｙｌｅクラスのインスタンスは多くの場合、色、色の深み、背景イメージなどの他の属性を追跡する必要がある。これらのプロパティはふつうのものであるが、ＤｙｎａＧｌｙｐｈフレームワークで明示的に要求されるわけではない。これは、実装者に任された設定上の問題であり、本実施形態の性質には直接関係するものではない。
【０１２５】
以下のクラスは、ほとんどのオブジェクト指向システムでは標準であり、当業者にはよく知られているかまたは容易にアクセスできる。
【０１２６】
Ａｃｔｉｏｎ−名前付きまたは無名関数。Ｓｍａｌｌｔａｌｋでは、アクションはアクション・プロトコルに準拠するオブジェクトである。メッセージ・セクタ（シンボル）、メッセージ、メッセージ送信、ブロックはすべて、このプロトコルに準拠する。
【０１２７】
Ｂｏｏｌｅａｎ−真または偽のいずれか。
Ｃｏｌｌｅｃｔｉｏｎ｛Ｔｙｐｅ｝．−指定された型のオブジェクトのコレクション。この型がＯｂｊｅｃｔの場合、任意の型のオブジェクトが受け付けられる。クラス階層のコンテキストでは、コレクションは通常ディクショナリ（辞書）を指定し、コレクションの各メンバーはＳｙｍｂｏｌキーで参照される。
Ｆｏｒｍ−任意の深さのビットマップ／ピクスマップとして実装されているイメージ。フォームはさらに、イメージの原点（ｏｒｉｇｉｎ）とバウンディング・ボックス（ｂｏｕｎｄｉｎｇ ｂｏｘ）を表す矩形を備える。
ＧｒａｐｈｉｃｓＣｏｎｔｅｘｔ−ＧｒａｐｈｉｃｓＣｏｎｔｅｘｔは、フォーム間のすべてのＢｉｔＢＬＴ（ビット・ブロック転送）描画を、処理し、追跡する。これは、現在の描画状態を追跡する。その描画状態はスタック可能である。
Ｉｎｔｅｇｅｒ−整数。
Ｏｒｄｅｒｅｄ　Ｌｉｓｔ（Ｔｙｐｅ｝−指定された型のオブジェクトの順序付けのあるコレクション。
Ｎｕｍｂｅｒ−整数、固定小数点数、浮動小数点数、または分数。
Ｏｂｊｅｃｔ−オブジェクト指向階層内の任意のオブジェクト。
Ｐｏｉｎｔ−数値ｘとｙからなる二次元デカルト（直交）座標の点。点は、標準コンピューター・グラフィックスの軸を使用し、ｘ軸は右に向かって正、ｙ軸は下に向かって正となるように取る。
Ｒｅｃｔａｎｇｌｅ−左上と右下の２点により定義される二次元デカルト座標の矩形である。
Ｓｙｍｂｏｌ−一意的な識別子。（通常は、一意的な文字列）。
ＣｏｌｏｒおよびＵｎｄｅｆｉｎｅｄＯｂｊｅｃｔは、このクラス階層図では明示的に参照していない別の重要な２つの基本型である。色は通常、ＲＧＢ、またはフォーム内で使用する階調（ｇｒａｙ ｓｃａｌｅ）値である。Ｓｍａｌｌｔａｌｋでは、ｎｉｌをＵｎｄｅｆｉｎｅｄオブジェクトとして使用する。「ｎｉｌ」は、すべての高水準プログラミング言語では定義されていないが、その概念はすべてにおいて実装されている（または実装可能である）。
【０１２８】
ＤｙｎａＧｌｙｐｈ　Ｃｌａｓｓ（型）
ＡｎｉｍａｔｉｏｎＯｂｊｅｃｔ−ＡｎｉｍａｔｉｏｎＯｂｊｅｃｔはＤｙｎａＧｌｙｐｈオブジェクト階層内のすべてのクラスの抽象スーパー・クラスである。他の基本型と同様に、Ｏｂｊｅｃｔクラスから派生する。ＡｎｉｍａｔｉｏｎＯｂｊｅｃｔは、フレームワーク内で使用される汎用ユーティリティ・メソッド（関数）の集積場所である。
Ａｔｔｒｉｂｕｔｅｓ（属性）：
ｉｄ−オブジェクトの一意的なｉｄを参照する。
【０１２９】
ＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔ−ＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔは、ＡｎｉｍａｔｉｏｎＯｂｊｅｃｔから下降（ｄｅｓｃｅｎｄ）する抽象クラスである。ＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔは、そのインスタンスの下位要素包含階層と、要素（ｅｌｅｍｅｎｔ）相互間の物理的レイアウトとを管理する。各ＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔインスタンスは、自分の局所座標系システム（ｉｔｓ ｏｗｎ ｌｏｃａｌ ｃｏｏｒｄｉｎａｔｅ ｓｙｓｔｅｍ）を使用する。
Ａｔｔｒｉｂｕｔｅｓ（属性）：
ＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔ−ＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔを収容するコンテキストを参照する。オブジェクトが包含コンテキストを持たないか、または最上位コンテキストの場合、ＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔはコンテキストそれ自体を参照する。
ｓｕｂｃｏｎｔｅｘｔｓ−コンテキストに収容される０個またはそれ以上のＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔｓ（ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔｓ）のコレクションを参照する。
ｌｏｃａｔｉｏｎ−包含コンテキストの座標系システムの原点からのオブジェクトの原点の距離である点を参照する。
ｂｏｕｎｄｓ−自座標系システムの原点から測定したコンテキストのバウンディング・ボックスを参照する。
【０１３０】
ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔ−ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔはＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔから下降する抽象クラスである。ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔは、ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔオブジェクトの共通属性情報をすべて扱う。ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔはさらに、要素の基本的な更新、妥当性確認および表示を扱う。
ＡｎｉｍａｔｉｏｎＣｏｎｔｅｘｔとＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔは、まとめて、すでに述べたインジケータ・モデル・オブジェクトの実施形態である。これらの２つのクラスは、単一のクラスに組み合わせることができるが、２つの別々のクラスに分割し、インジケータ・モデルの構造面および機能面の態様を別々に抽象化した。
Ａｔｔｒｉｂｕｔｅｓ（属性）：
ｓｔｙｌｅ−適切な具象ＡｎｉｍａｔｉｏｎＳｔｙｌｅオブジェクトを参照する。
ｉｓＶｉｓｉｂｌｅ−要素の視認性の論理値を参照する。ｉｓＶｉｓｉｂｌｅは、表示するかどうかを決定する。
ｖａｌｕｅＳｔａｔｅ−要素の現在の（遷移）状態の主要な態様。この属性の解釈は、ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔの具象下降クラスのそれぞれにより定義される。
ｃｕｒｒｅｎｔＳｔｅｐ−開始から終了までの現在の状態の遷移の進行状況を表す数値。ｃｕｒｒｅｎｔＳｔｅｐは単位値により表すことができる（がそうする必要はない）。
ｐｒｏｐｅｒｔｉｅｓ−属性のコレクションを参照する。要素が特定のインスタンス変数（スロット）を持たない属性はこのディクショナリ内に保持することができる。（実装者側で、定義済みクラスに対し特定のスロットを追加することもできる）。
【０１３１】
ＡｎｉｍａｔｉｏｎＤｅｖｉｃｅ−ＡｎｉｍａｔｉｏｎＤｅｖｉｃｅは、ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔから下降する具象クラスである。ＡｎｉｍａｔｉｏｎＤｅｖｉｃｅのインスタンスはアニメーションを実行するためＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔインスタンス・ツリーのルートとして必要である。ＡｎｉｍａｔｉｏｎＤｅｖｉｃｅは、ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔインスタンスのアニメーションタイミングを取る役割を持つ。
ＡｎｉｍａｔｉｏｎＤｅｖｉｃｅは、すでに述べているようにタイミング・デバイス・オブジェクトの実現（ｅｍｂｏｄｉｍｅｎｔ）である。
Ａｔｔｒｉｂｕｔｅｓ（属性）：
ｔｉｍｅｄＡｃｔｉｏｎｓ−ＡＥＴｉｍｅｄＡｃｔｉｏｎｓの優先待ち行列または並べ替えリストを参照する。このリストは、昇順で並べ替えられ、ＡＥＴｉｍｅｄＡｃｔｉｏｎｓのｓｔａｒｔＴｉｍｅＩｎｄｅｘ、そのｓｔｏｐＴｉｍｅＩｎｄｅｘ、および必要ならばそのｉｄで優先度が設定される。
ｆｒａｍｅｓＰｅｒＳｅｃｏｎｄ−デバイスの更新頻度を参照する。
ｃｌｏｃｋＯｆｆｓｅｔ−コンピュータ・システムのマスター時間インデックスからのデバイスのオフセットを参照する。マスター時間インデックスを自分のタイム・スケールに変換するのに使用される。
ｆｒａｍｅＴｉｃｋ−現在のアニメーション・フレームの所望される時の刻みを参照する。ｆｒａｍｅＴｉｃｋは、ｃｌｏｃｋＯｆｆｓｅｔとコンピュータ・システムの現在の時の刻みとともに使用し、次のｆｒａｍｅＴｉｃｋ時間を計算する。（刻みはハードウェア装置の設定によってサポートされているアトミックの具体的な時間単位である。）
ｉｎｔｅｒｎａｌＧｒａｐｈｉｃｓ−デバイスがダブル・バッファリング描画に使用する内部ＧｒａｐｈｉｃｓＣｏｎｔｅｘｔを参照する。この属性はオプションである。
ｅｘｔｅｒｎａｌＧｒａｐｈｉｃｓ−デバイスの下位要素の最終的複合描画を表示するＧｒａｐｈｉｃｓＣｏｎｔｅｘｔを参照する。
【０１３２】
ＡＥＴｉｍｅｄＡｃｔｉｏｎ−ＡＥＴｉｍｅｄＡｃｔｉｏｎは、ＡｎｉｍａｔｉｏｎＯｂｊｅｃｔから下降する具象クラスである。そのインスタンスは、ａｎ　ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔインスタンス上で遅延アクション、または期間にわたって発生するアクション（遷移）を実行するために必要なすべての情報を保持する。
ＡＥＴｉｍｅｄＡｃｔｉｏｎは、すでに述べているような計時信号オブジェクトの実現である。
Ａｔｔｒｉｂｕｔｅｓ（属性）：
ｔａｒｇｅｔ−計時アクションのターゲットＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔを参照する。
ｓｔａｒｔＴｉｍｅＩｎｄｅｘ−計時アクションの開始時間インデックスを参照する。
ｓｔｏｐＴｉｍｅＩｎｄｅｘ−計時アクションの停止時間インデックスを参照する。
ａｃｔｉｏｎＭｏｄｅ−計時アクションの現在の状態を参照する（たとえば、開始待機、メイン・アクション実行中、もうじき終了）。
ｓｅｔｕｐＡｃｔｉｏｎ−主アクションが開始する直前に実行される設定アクションを参照する。設定アクションを実行すると、ターゲット・オブジェクトはターゲットの計時アクションのうち他方（たとえば、同じｉｄ、アクションをオーバーラップする期間の他のアクション）をオーバーライドする機会が与えられる。
ｐｒｉｍａｒｙＡｃｔｉｏｎ−計時アクションの期間にわたって繰り返される主アクションを参照する。
ｐｏｓｔＡｃｔｉｏｎ−主アクションの期間が完了した直後に実行されるアクションを参照する。
【０１３３】
ＦｒａｍｅＳｅｑｕｅｎｃｅ−ＦｒａｍｅＳｅｑｕｅｎｃｅは、ＡｎｉｍａｔｉｏｎＯｂｊｅｃｔから下降する具象クラスである。ＦｒａｍｅＳｅｑｕｅｎｃｅインスタンスは、あらかじめ生成されているイメージのシーケンスおよびその運動経路をキャッシュするため、ＡｎｉｍａｔｉｏｎＳｔｙｌｅオブジェクトにより使用される。ＦｒａｍｅＳｅｑｕｅｎｃｅインスタンスは、１つまたは複数のイメージ、および１つまたは複数の場所の点を収容する。インスタンスが１つのイメージのみを参照する場合、この同じイメージを、順繰りにインスタンスの場所のそれぞれにある各フレーム内で使用する。インスタンスが１つの点だけを参照する場合、インスタンスのイメージのそれぞれがフレームもそれぞれの中の同じアンカー点で描画される。インスタンスが複数のイメージおよび点を参照する場合、各イメージは各アンカー点に順繰りに配置される。
Ａｔｔｒｉｂｕｔｅｓ（属性）：
ａｎｃｈｏｒＰｏｉｎｔｓ−点の順序付けられたコレクションを参照する。
ｆｏｒｍｓ−フォームの順序付けられたコレクションを参照する。
【０１３４】
ＡｎｉｍａｔｉｏｎＳｔｙｌｅ−ＡｎｉｍａｔｉｏｎＳｔｙｌｅは、ＡｎｉｍａｔｉｏｎＯｂｊｅｃｔから派生する抽象クラスである。ＡｎｉｍａｔｉｏｎＳｔｙｌｅｓは、表示とＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔｓの遷移状態の管理を扱う。アニメーション・スタイルがＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔインスタンスに接続された場合、アニメーション・スタイルにより下位要素または下位スタイルをインスタンスまたは下位要素に追加したり削除したりできる。
すべての具象ＡｎｉｍａｔｉｏｎＳｔｙｌｅは遷移データのデータベースを持つ。デフォルトでは、データベースのキーは、スタイルでサポートしている特定の各遷移である。各キーで格納されているデータの性質はＡｎｉｍａｔｉｏｎＳｔｙｌｅのそれぞれの具象派生クラスにより定義される。
ＡｎｉｍａｔｉｏｎＳｔｙｌｅのインスタンスはＦｒａｍｅＳｅｑｕｅｎｃｅｓを使用してその遷移に対するイメージ・データをキャッシュする。参照側ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔインスタンスの型、バウンズ・エクステント（ｂｏｕｎｄｓ ｅｘｔｅｎｔ）、色の深み、またはフレーム・カウントが変化した場合、ＡｎｉｍａｔｉｏｎＳｔｙｌｅインスタンスのキャッシュをフラッシュしなければならない場合がある。ＡｎｉｍａｔｉｏｎＳｔｙｌｅインスタンスに対してＦｒａｍｅＳｅｑｕｅｎｃｅｓを生成する場合、計算に非常に時間がかかることがある。このようなデータに対する不要な再ビルドを避けるために、それぞれの具象スタイル・クラスでそれ自身のすでにビルドされているインスタンスをキャッシュすることができる。
ＡｎｉｍａｔｉｏｎＳｔｙｌｅは、すでに述べたようにアニメーション・スタイルオブジェクトの実現である。
Ａｔｔｒｉｂｕｔｅｓ（属性）：
ｓｔｙｌｅＣａｃｈｅ−このＡｎｉｍａｔｉｏｎＳｔｙｌｅのビルド済みインスタンスをキャッシュするコレクションを参照するクラス変数である。
ｔｒａｎｓｉｔｉｏｎＤａｔａ−特定の具象ＡｎｉｍａｔｉｏｎＳｔｙｌｅにより定義されているそれぞれの遷移について必要な遷移データのコレクションご参照する。（いくつかのＡｎｉｍａｔｉｏｎＳｔｙｌｅサブ・クラスはこの属性をクラス変数にすることができる。）
ｅｘｔｅｎｔ−スタイルのこのインスタンスのサイズを表す点を参照する。
ｄｅｐｔｈ−スタイルのこのインスタンスが表示される（色の）深みのビットを参照する。
ｆｒａｍｅＣｏｕｎｔ−スタイルのこのインスタンスを使用して状態遷移を完全に段階的に通過するために使用されるフレームの個数を参照する。
ｆｒａｍｅＳｅｑｕｅｎｃｅｓ−このエクステント、深さ、およびフレーム・カウントでこのＡｎｉｍａｔｉｏｎＳｔｙｌｅを実装するために必要なＦｒａｍｅＳｅｑｕｅｎｃｅｓのデータベースを参照する。
【０１３５】
ＣｏｎｃｒｅｔｅＡＥとＣｏｎｃｒｅｔｅＡＳクラス
ＣｏｎｃｒｅｔｅＡＥおよびＣｏｎｃｒｅｔｅＡＳは、それぞれ、ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔおよびＡｎｉｍａｔｉｏｎＳｔｙｌｅの実装者定義サブ・クラスを表す。ＤｙｎａＧｌｙｐｈソフトウェア・フレームワークを使用するには、実装者側でＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔおよびＡｎｉｍａｔｉｏｎＳｔｙｌｅの両方の少なくとも１つの具象サブ・クラスを定義しなければならない。具象ＡｎｉｍａｔｉｏｎＳｔｙｌｅｓおよびＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔｓで、そのインスタンスに必要な追加属性を定義することができる。具象要素は、具象ＡｎｉｍａｔｉｏｎＳｔｙｌｅオブジェクトを参照するだけである。それぞれの具象ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔクラスはインジケータ・モデル、または実装者が定義するグリフに対応する。
【０１３６】
−ａｌｐｈａＮｕｍｅｒｉｃｏｎソフトウェア・フレームワークのまとめ
ａｌｐｈａＮｕｍｅｒｉｃｏｎは、複数のグリフからなるアルファベット内にある全てのグリフを他のグリフにダイナメート化するためのソフトウェア・フレームワークである。このフレームワークは、アプリケーション・ソフトウェアとともにユーティリティ・パッケージとして使用される。
ａｌｐｈａＮｕｍｅｒｉｃｏｎは、アプリケーション・ソフトウェアが、文字、数字、およびその他のグリフの表示にダイナメート化処理を利用することを可能にする。
【０１３７】
グリフは、具象ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔｓにより表される。ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔは、他の具象ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔｓから再帰的に構成することができる。グリフ集合を表すために使用できるＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔｓについて、最大数はない。つまり、このフレームワークでは、一度に表現し表示できるグリフの最大数に制限を課していないということである。唯一の制限は、作業メモリ内で表すことができるオブジェクトの個数である。
【０１３８】
ＡｎｉｍａｔｉｏｎＥｌｅｍｅｎｔインスタンスのツリーをアニメーション化するために、ルートはＡｎｉｍａｔｉｏｎＤｅｖｉｃｅでなければならない。デバイスには、要素の下位ツリーを開始し調整する状態情報および振る舞いのすべてが収容される。
【０１３９】
ソフトウェア・タイミング・デバイスとその下位要素のアニメーション化の過程で、アプリケーション・プログラムはグリフを表す要素の状態および属性を調整し、所望するアニメーションの振る舞いを実現する。
の調整は、直ちに、または設定された時間インデックスで、または時間インデックスから次の時間インデックスまでの範囲にわたって、その要素に対して行うことができる。
【０１４０】
フレームワーク内では、時間は、具体的な時間単位（たとえば秒）ではなく、時間インデックスのタームで表される。このため、タイム・スケールとａｌｐｈａＮｕｍｅｒｉｃｏｎアニメーションのペースを簡単に調整できる。時間インデックスは、時間単位、たとえば、分、秒、１／１０秒などを表すことができる。
【０１４１】
図１１から１９を参照すると、数種類のアニメーションの振る舞いが示されている。図に示されている振る舞いはすべて、ソフトウェア・コンポーネントの状態で実装され、そのソフトウェア・コンポーネントは、何らかの値を表すインジケータを表示する、アプリケーション・ソフトウェアのブラックボックス・コンポーネントとして、使用されている。アプリケーション・ソフトウェアとソフトウェア・コンポーネントは、プロセッサやその他のコンピュータ・ベースのデバイス上で実行される。プロセッサは、ソフトウェア・コンポーネントにより作成された出力イメージが最終的に表示される表示デバイス（ｄｉｓｐｌａｙ ｄｅｖｉｃｅ）を、使用する。
【０１４２】
図１１から１９では、中心要素はソフトウェア・コンポーネントを表すボックスである。ボックスの左側には、ソフトウェア・コンポーネントへの１つまたは複数の入力が示されている。ソフトウェア・コンポーネントは、これらの入力を使って、イメージ出力として生成するイメージまたはイメージ・シーケンスを決定する。イメージ出力は常に、インジケータの現在の値−状態を表すイメージである。
【０１４３】
ボックスの中には２つの矩形長円形がある。一番上の長円形は、ソース値集合を表し、一番下の楕円形はデスティネーション値集合を表す。これらの値集合は、インジケータの使用可能な開始値とインジケータの使用可能な終了値を、表す。それぞれの長円形の中には、円があり、それぞれは、インジケータの有効な値を表す。これらの値は、状態Ｖ１からＶｎと呼ばれ、ｎは値集合の中の一意的な値の個数である。両方の長円形は同様の有効な値集合を表す。インジケータの有効な値毎に、その値を表す一意的なイメージが存在する。
【０１４４】
ソース値集合とデスティネーション値集合を表すそれぞれの楕円形の左に菱形がある。一番上の菱形は、ソース値からの遷移の開始時間を表す。一番下の菱形は、デスティネーション値への遷移の終了時間を表す。一番上の菱形から一番下の菱形への頭が広くなっている矢印がそこに置かれており、ソフトウェア・コンポーネント内の時間の流れの方向に注意を引くようになっている。
【０１４５】
図１１から１９では、ソース値集合からデスティネーション値集合までの１つまたは複数の太線の矢印がある。これらの矢印はそれぞれ、ソース値からデスティネーション値への遷移を行う一意的な手段を表す。実際の遷移の手段は、インジケータにとっては重要でない。アニメーションについての従来の手段を使用して、一方の値から他方の値への遷移を達成することができる。
【０１４６】
矢印はそれぞれ、パイプとして考えることができる。パイプを流れるものは重要でない。パイプの存在、およびその接続のレイアウトが重要なのである。
【０１４７】
インジケータの現在の状態は、それが表そうとしている値に密接に関連している。インジケータが静的状態にある場合、その現在状態はその値により定義される。インジケータがソース値からデスティネーション値へのアニメーション化された遷移を実行している過程にある場合、そのインジケータの現在の状態はその遷移のソース値とデスティネーション値により定義される。したがって、インジケータの状態はその値−状態と呼ばれる。
【０１４８】
図１１を参照すると、単純なインジケータがそこに示されている。単純なインジケータとは、アニメーション化されていない基本的なインジケータである。この図は、単純な製品に見られるほとんどどのような電子的インジケータをも表すことができる。たとえば、コンピュータ画面、ＶＣＲ、テレビの画面、デジタル時計、キャラクタ・ディスプレイ上のアニメーションを使用しないほとんどのインジケータがそうである。英数字ページャでは、有効な集合は、一度にその画面に表示できる数字と英字の使用可能な組み合わせを含む。空港のゲート・インジケータでは、有効な値集合は、インジケータが配置されている空港のゲートのすべての英字および数字の組み合わせを含む。
【０１４９】
ソース値は、インジケータの現在の値−状態である、つまり、現在表示されている静的値である。ソフトウェア・コンポーネントは、次の値の入力を受け取ると、ソフトウェア・コンポーネントの値−状態を新しい値に設定し、その新しい値に対応するイメージを出力する。その新しいイメージは、値の設定時に出力される。次の値に対する唯一の制限は、インジケータの有効な値集合にそれが含まれていなければならないという点である。
【０１５０】
図１１では、ソース値の集合からデスティネーション値の集合まで１つのパイプしかないが、それは、遷移を実行する手段が１つしかないからである。遷移は瞬間的（または静的）なものなので、インジケータは単に、次の値−状態に設定されるだけであり、単一の新しいイメージが出力される。
【０１５１】
注釈：　単純なインジケータによりその値が変更され、イメージが十分速く生成される場合には、アニメーションが実行されているように見えることに留意されたい。しかし厳密にいうと、これは実際のアニメーションではない。インジケータのアニメーションは、ソース値−状態とデスティネーション値−状態の間の中間状態（複数）を表すイメージ（複数）を出力することとして定義される。これらの中間イメージ（複数）は、一意の静的ソースおよびデスティネーション・イメージとは異なっている。単純なインジケータでは、中間イメージをいっさい使用しないで１ステップだけで遷移を行うので、アニメーションにならない。
【０１５２】
ここでは示されていないが、図１１から１９までのインジケータはすべて、デフォルトで、単純なインジケータの振る舞いを行うことができる、つまり有効な値から他の有効な値への即時静的遷移を実行するということである。
【０１５３】
次に図１２を参照すると、シーケンシャル・アニメーション化インジケータがそこに示されている。シーケンシャル・アニメーション化インジケータは、静的ソース値から静的デスティネーション値へ遷移するときに複数の一意的な中間イメージを生成するという点でアニメーション化されている。このインジケータは、任意の有効な値から他の任意の有効な値へではなく、１つの有効な値から次の（または前の）１つの有効な値に遷移することしかできないという点でシーケンシャルである。
【０１５４】
アプリケーション・ソフトウェアがインジケータの変更を開始すると、アプリケーション・ソフトウェアはソフトウェア・コンポーネントに２つの認可された入力値（ｃａｎｏｎｉｃａｌ ｉｎｐｕｔ　正規の入力値）、つまり次の値（現在の値の前の値または現在の値の後の値のいずれか）、およびアニメーション化された遷移が完了する時間、を送る。この入力は、他の明示的または暗示的入力がそのインジケータ用に定義され得るという点で、正規のものである。しかし、これらとは異なった入力も、最終的に、実効的な正規の入力に、細分化されることが可能である。
【０１５５】
インジケータへの有効な入力は、インジケータの現在の値−状態により制限される。次の値は、現在の値へのシーケンシャル隣接値でなければならない。この依存性は、ソース値から次のデスティネーション値入力まで延びている波線矢印で示されている。終了時間は開始時間の後にこなければならない。開始時間には、ソース値はインジケータの現在値になっている。デスティネーション値は、インジケータの次の値である。
【０１５６】
図１２で、開始時間と終了時間の間には複数の水平矢印がある。これらの矢印を使用して、時間の経過を表す。これらの矢印はそれぞれ出力を指している。全体的に、これらの出力は、ソース値からデスティネーション値へ遷移の進行に従うインジケータの値−状態を表すために使用される複数のイメージを供給する。これらのイメージは、アニメーション化遷移のフレームとして使用される。
【０１５７】
図１１の場合と異なり、図１２には、複数のパイプ矢印がある。矢印はそれぞれ、特定のソース値から特定のデスティネーション値への遷移を行う一意的な手段を表す。たとえば、一意的なアニメーション化遷移を使用して、Ｖ２はＶ１またはＶ３に遷移することができる。シーケンシャル・アニメーション化インジケータでは、それぞれの値は２つの隣接値へのアニメーション化遷移しか実行できない。有効なかつ一意的な遷移手段の総数は、２×Ｎに等しい。
【０１５８】
図１４を参照すると、アニメーション化エレベータ・インジケータが、主にシーケンシャル・インジケータの一例として示されている。このインジケータは、いくつかの値からは少数の特別な遷移（標準を超える）を持ち、また他の値についてはさらに少ない特別な遷移を持つ。しかし、まとめると、有効な遷移の一般的なパターンがシーケンシャルであり、遷移の総数が約２×Ｎであるという点でほとんどシーケンシャルである。
【０１５９】
エレベータを制御するアプリケーション・ソフトウェアでインジケータの変更を必要とする場合、これは、ソフトウェア・コンポーネントに２つの正規の入力値、つまり次の階と、アニメーション化遷移がそれ自身を完了する終了時間を送信する。終了時間は、エレベータがある階から他の階への移動に要する時間の量に基づく。他のシーケンシャル・アニメーション化インジケータと同様に、次の有効な入力値はインジケータの現在の値−状態に依存する。
【０１６０】
図１３におけるシーケンシャル・ムービー・インジケータは、アニメーション的に一方の有効な値から他方の有効な値への値が遷移するインジケータである。シーケンシャル・アニメーション化インジケータのように、このインジケータは一方の値から他方の値に順番に遷移するときに複数のイメージを出力する。しかし、このインジケータは、アニメーション化される値があらかじめ定められているという点で、シーケンシャル・アニメーション化インジケータと異なっている。そのソフトウェア・コンポーネントは、特定の値への遷移をそのソフトウェア・コンポーネントに対して可能にする、アプリケーション・ソフトウェアからの、入力を受け付けることができない。ソフトウェア・コンポーネントが受け付けられる入力は、複数の値の所定のシーケンスにわたってそのアニメーションを開始するように、それに対して１つの指令を出すものだけである。
【０１６１】
そのアプリケーション・ソフトウェアは、ソフトウェア・コンポーネントに、イメージの出力を開始する入力を供給する。そのアプリケーション・ソフトウェアは、それらのイメージを受け取り、このイメージをムービーのフレームとして表示する。
【０１６２】
図６：共通アニメーション化インジケータ
図１５で参照される共通アニメーション化インジケータは、単一の共通遷移方法を使用して有効なソース値から有効なデスティネーション値へアニメーション化するという事実から、その名前が付けられている。（実際、ソース値集合とデスティネーション値集合は無限であってもよいが、それは、ソース値からデスティネーション値への遷移がソース値またはデスティネーション値の関数となっていないからである。）シーケンシャル・アニメーション化インジケータと異なり、この共通インジケータは、次の値が有効な値集合の中に含まれていなければならないという点を除き、次の値入力に対する制限を持たない。
【０１６３】
このソフトウェア・コンポーネントは、汎用ラスター・ベースの遷移方法を使用して何らかの値から他の値へのアニメーション化遷移を実行することができる。この手法は、汎用のアニメーション化遷移を実行するうえで最も安価な手段である。
【０１６４】
遷移を生成する手段は１つしかないため、このソフトウェア・コンポーネントは、ソース値の集合からデスティネーション値の集合まで、１つのパイプしか持たない。何らかの値から別の値への遷移が一意的な外観を持つことは保証されない。
【０１６５】
このインジケータは、遷移の手段がソース値またはデスティネーション値に依存しないという点でシーケンシャル・アニメーション化インジケータと異なっている。共通アニメーション化インジケータなどのラスター手法は、静的ソース・イメージと静的デスティネーション・イメージを、直接的に（そのまま）使用して、遷移の中間イメージを生成する。静的ソース・イメージおよび静的停止イメージは何でも良い。ラスター手法では、ソース値またはデスティネーション値をまったく直接には使用しない。
【０１６６】
図１６を参照すると、マルチ・モード共通アニメーション化インジケータがそこに示されている。共通インジケータは、ソース値からデスティネーション値へ遷移に、単一の汎用ラスター・ベースの手段を使用するが、同じソフトウェア・コンポーネントが、複数の汎用ラスター・ベースの手法を使用できる。ほとんどのアニメーション化電子情報表示は、表示値の間にアニメーション化された遷移を作成するさまざまなラスター・ベースの「効果」を備える。
【０１６７】
図１６のソフトウェア・コンポーネントは、ラスター手法を使用するよう指定する追加入力を持つ。
【０１６８】
図１７を参照すると、中間状態アニメーション化インジケータは、有効なソース値から有効なデスティネーション値へのアニメーション化遷移を実行できるという点で共通アニメーション化インジケータに類似している。これらは、２×Ｎ個のパイプを使用するという点でシーケンシャル・アニメーション化インジケータに類似している。
【０１６９】
一方の値から他方の値への遷移はすべて、２つの別々の下位遷移からなる。イメージ出力するプロセスのある時点で、すべての遷移が他のすべての遷移と共有する共通中間値−状態に達する。この共有中間値−状態のときに、そのエンジンは同じ共通イメージを出力する。
【０１７０】
共通アニメーション化インジケータよりも表現力が高いが、シーケンシャル・アニメーション化インジケータの場合のように各値の遷移が完全に一意であるとする遷移には、ならない。
【０１７１】
図１８を参照すると、図１から１０の実施形態によるダイナメート化インジケータが示されている。ダイナメート化インジケータ・ソフトウェア・コンポーネントは、すべての有効な値から他の有効な値への一意的な遷移を行う。そのことは、インジケータに対し、最も豊富で最も表現力のある使用可能なアニメーション化遷移の能力を与える。
【０１７２】
パイプ矢印はそれぞれ、特定のソース値から特定のデスティネーション値への遷移を行う一意的な手段を表す。図に示されている実施形態のソフトウェア・コンポーネントは、同じソース値から同じデスティネーション値への一意的なアニメーション化遷移を指定する、ことに留意されたい。
【０１７３】
図１８には、各ソース−デスティネーションの値ペアに対するパイプが１つしか示されていないが、本実施形態では単一のソース値から単一のデスティネーション値への複数のパイプをサポートしている。そのために、ソフトウェア・コンポーネントは適切なパイプを選択することを目的に追加入力値を必要とする。
【０１７４】
図１９を参照すると、マルチ・スタイル・ダイナメート化インジケータがそこに示されている。ソース値集合のすべてのメンバーとデスティネーション値集合のすべてのメンバの間の一意的な遷移の完全な列挙し、およびソース−デスティネーションの値集ペアに対する複数の手段（パイプ）を提供する他に、図に示されている実施形態は、ソフトウェア・コンポーネント内で複数のダイナメート化スタイルを使用することを可能にする。
【０１７５】
各スタイルは、完全な遷移集合に対する特定の統一された外観（ｌｏｏｋ）を定義する。インジケータ全体で特定のスタイルを使用するか、またはインジケータを構成するグリフのそれぞれで異なるスタイルを同時にかつ独立に使用することができる。遷移の任意の時点に、このソフトウェア・コンポーネントはスタイルをグリフに再割り当てすることができる。
【０１７６】
マルチスタイル・インジケータ・ソフトウェア・コンポーネントは、使用すべき遷移スタイルと、どのグリフが使用されるべきかを指定する追加入力を受け付ける。図は、４つのスタイルを持つインジケータを示しているが、さらに多くのスタイルも可能である。
【０１７７】
例３
銀行の建物の外壁に、ふつうのアナログまたはデジタル・メカニズムのものではなくダイナメート化インジケータを採用した時刻−日付−温度を保持する時計がかかっている。ダイナメート化インジケータを使用すると、ふつうの時計よりも面白みがあるというだけでなく、銀行の客が時間の経過を、より視覚的にかつ瞬時に、理解することができる。別のレベルでは、ダイナメート化した時計は、銀行の建物に非常事態が発生したときに密かに警察に通報することに使用される。遷移のうち１つまたは複数に、図１９のマルチ・スタイルのダイナメート化インジケータの遷移スタイルを変更することでもたらされるような、通常のものと微妙な違いがあることに気づくことで、警察はこのことに対して注意を喚起させられる。どの遷移が異なるか、またこのような遷移がどのように異なるかに応じて、さまざまな二次情報が伝達される。このような情報は、「内情に通じていない」人々にとっては実際に気づかれないものである。
【０１７８】
このように、ダイナメート化インジケータは、遷移のスタイルと手段を使用して、表示される一次データ以外の二次情報を伝達することができる。この２つのレベルの情報を使用することで、「秘密」情報をありふれた風景（ｐｌａｉｎ ｓｉｇｈｔ）の中で伝達することができる。二次情報は、その二次情報が存在していることの知識のない見物人に対して、またはその二次情報のデコード方法、あるいは解釈方法についての知識のない見物人に対して「効果的に暗号化されている」といえる。ここで見物人は、人である必要はなく、動物でもよく、あるいは一次および／または二次情報を解釈するように設計された機械であってもよい。
【０１７９】
例４
ダイナメート化インジケータは、を使用すると、以前にはできなかったような新しい方法で時間を表示するのに使用することができる。通常、デジタル時計では、４ディジットまたは６ディジットが一度に表示され、時間と分、または時間、分、秒がそれぞれ表示される。時刻と日付を間欠的に交互に表示する時計もある。４ディジットの時計では、「時」は「月」に変わり、「分」は「日」に変わる。６ディジット時計では動作は似ているが、秒はさらに年に変わるという点が異なる。もちろん、米国以外の国では、多くの場合、その日付設定は別の配列になっているが、間欠的遷移の動作は類似している。
【０１８０】
ダイナメート化インジケータを使用すると、情報のこれらのモード間の遷移は、より面白く、注意を引く方法で完全にアニメーション化することができる。さらに、月および曜日についての英字略語も、間欠的なアニメーションで表示することもできる。この例は４ディジットと６ディジットの数字／文字時計の場合であるが、他の形式に対しても推定することもできる。
【０１８１】
行われていない形式の１つは、時刻と日付の２ディジット／文字を一度に表示するだけの時計である。これは、１）すでに４桁または６桁が使用できるときに表示される情報を２文字に減らす必要はないという広く受け入れられている考え、と、２）２文字が表している日付−時刻の部分を区別するためには、表示されている２文字だけから入手可能な手がかりは十分でない、という２つの主な理由のため行われてこなかったと推測する。
【０１８２】
しかし、ダイナメート化インジケータを使用すると、２つの文字だけで時刻と日付を効果的に表示することができる。そこで、滑らかなアニメーション化遷移を使用し、また時刻−日付単位の間の遷移のテンポを変えることで、表示されている日付−時刻の単位に注目し検出することができる。日付と時刻を表示するのに小さな表示面積しかない場合、２文字を使用することで、表示領域内においてその２文字をさらに大きくすることができ、その結果、読みやすくすることができる。これは特に、腕時計などの小型の製品や、ＰＤＡ、電子レンジなどの小型家電製品の表示に役立つ。
【０１８３】
図２０から３０を参照すると、０から９までのディジットと「−」からなる値集合内のすべての値の遷移の例が示されている。「−」への遷移は、図２０に示されている遷移と逆の遷移である。図２１から３０では、一番左の欄は静的開始値の結果として生成されるイメージを表し、続くそれぞれの欄（右へ移動）は、右のその欄内のイメージが生成される時刻に続いて発生する時刻の遷移イメージを表す。一番右の欄は、静的デスティネーション値の結果として生成されたイメージを表す。このアニメーション・スタイルは、ＦＯＬＤＩＮＧ　ＤＩＧＩＴＳアニメーション・スタイルという名前で販売される。
【０１８４】
ここで開示した発明は特定の実施形態とアプリケーションを使って説明したが、当業者であれば請求項に記載されている発明の範囲を逸脱することなく多数の修正およびバリエーションを加えることは可能である。
【図面の簡単な説明】
【図１】
示されている本発明の一実施形態によるダイナメート化されたインジケータ（ｄｙｎａｍａｔｅｄ ｉｎｄｉｃａｔｏｒ）装置を示すブロック図である。
【図２】
図１のダイナメート化されたインジケータ装置の一バリエーションなどのコンピュータ・メモリに格納されるソフトウェア・エンジンおよび複数のアプリケーション・ソフトウェア・システムのブロック図である。
【図３】
図１のダイナメート化されたインジケータ装置の他のバリエーションなどのコンピュータ・ネットワークを介して互いに結合された複数のコンピュータ・メモリに格納されるソフトウェア・エンジンおよび複数のアプリケーション・ソフトウェア・システムのブロック図である。
【図４】
図１のダイナメート化されたインジケータ装置の一バリエーションのソフトウェア・エンジンと複数のアプリケーション・ソフトウェアの間の通信を示すブロック図である。
【図５】
図４のソフトウェア・エンジンを備えるソフトウェア・オブジェクトを記述しているブロック図である。
【図６】
図４のソフトウェア・エンジンで使用できるような、有効値集合、静止イメージ表現の集合、および有効値集合に対する一意的な遷移シーケンスの完全に記述された集合、を示すブロック図である。
【図７】
ハート・モニタ例（ｈｅａｒｔ ｍｏｎｉｔｏｒ ｅｘａｍｐｌｅ）の、図４などのソフトウェア・エンジン内の、オブジェクト階層を示すブロック図である。
【図８】
折り返しディジット例（ｆｏｌｄｉｎｇ ｄｉｇｉｔ ｅｘａｍｐｌｅ）の、図４などのソフトウェア・エンジン内の、オブジェクト階層を示すブロック図である。
【図９】
一実施形態による方法を実行する際の、図４のソフトウェア・エンジンによりトラバース（ｔｒａｖｅｒｓｅ）されるステップを示すフローチャートである。
【図１０】
図４などのソフトウェア・エンジン内のクラス階層を示すブロック図である。
【図１１】
単純なインジケータの図式表現である。
【図１２】
シ−ケンシャル・アニメーション化インジケータの図式表現である。
【図１３】
シ−ケンシャル・ムービー・インジケータ（ｓｅｑｕｅｎｔｉａｌ ｍｏｖｉｅ ｉｎｄｉｃａｔｏｒ）の図式表現である。
【図１４】
アニメーション化エレベータ・インジケータの図式表現である。
【図１５】
共通アニメーション化インジケータの図式表現である。
【図１６】
マルチ・モード・アニメーション化インジケータの図式表現である。
【図１７】
中間値アニメーション化インジケータの図式表現である。
【図１８】
図４のソフトウェア・エンジンを使用して達成できるようなダイナメート化インジケータの図式表現である。
【図１９】
図４のソフトウェア・エンジンを使用して達成できるようなマルチ・スタイル・ダイナメート化インジケータの図式表現である。
【図２０】
数字０から９、および「−」を備える値集合内の「−」値と他のすべての値との間の遷移のグラフィック表現である。
【図２１】
数字０から９、および「−」を備える値集合内の「０」値とすべての値との間の遷移のグラフィック表現である。
【図２２】
数字０から９、および「−」を備える値集合内の「１」値とすべての値との間の遷移のグラフィック表現である。
【図２３】
数字０から９、および「−」を備える値集合内の「２」値とすべての値との間の遷移のグラフィック表現である。
【図２４】
数字０から９、および「−」を備える値集合内の「３」値とすべての値との間の遷移のグラフィック表現である。
【図２５】
数字０から９、および「−」を備える値集合内の「４」値とすべての値との間の遷移のグラフィック表現である。
【図２６】
数字０から９、および「−」を備える値集合内の「５」値とすべての値との間の遷移のグラフィック表現である。
【図２７】
数字０から９、および「−」を備える値集合内の「６」値とすべての値との間の遷移のグラフィック表現である。
【図２８】
数字０から９、および「−」を備える値集合内の「７」値とすべての値との間の遷移のグラフィック表現である。
【図２９】
数字０から９、および「−」を備える値集合内の「８」値とすべての値との間の遷移のグラフィック表現である。
【図３０】
数字０から９、および「−」を備える値集合内の「９」値とすべての値との間の遷移のグラフィック表現である。

Claims (42)

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. 前記第１のグリフは、複数のプロパティを有することを特徴とする請求項２７に記載の方法。
32. 前記下位グリフは、前記第１のグリフから複数のプロパティを継承することを特徴とする請求項３１に記載の方法。
33. イメージを表示する方法であって、
    ソース値を生成すること、
    複数のデスティネーション値を生成すること、および、
    前記ソース値から前記デスティネーション値のそれぞれへの個々の異なる遷移を生成すること
    を備えることを特徴とする方法。
34. 前記個々の異なる遷移は、前記ソース値とデスティネーションの１つについての関数であることを特徴とする請求項３３に記載の方法。
35. さらに、
    複数のソース値を生成すること、および
    前記ソース値のそれぞれから前記デスティネーション値のそれぞれへの個々の異なる遷移を生成すること
    を備えることを特徴とする請求項３３に記載の方法。
36. さらに、
    ソース・イメージを表示すること、
    デスティネーション・イメージを表示すること、および
    複数の遷移イメージを表示すること
    を備えることを特徴とする請求項３３に記載の方法。
37. 前記ソース・イメージは、前記ソース値の関数であり、
    前記デスティネーション・イメージは、前記デスティネーション値の１つについての関数である
    ことを特徴とする請求項３６に記載の方法。
38. イメージを表示する方法であって、
    複数のソース値を生成すること、
    デスティネーション値を生成すること、および、
    前記ソース値のそれぞれから前記デスティネーション値への個々の異なる遷移を生成することを含むことを特徴とする方法。
39. 前記異なる遷移は、前記ソース値の１つとデスティネーションの関数であることを特徴とする請求項３８に記載の方法。
40. さらに、
    複数のデスティネーション値を生成すること、および、
    前記ソース値のそれぞれから前記デスティネーション値のそれぞれへの個々の異なる遷移を生成すること
    を備えることを特徴とする請求項３８に記載の方法。
41. さらに、
    ソース・イメージを表示すること、
    デスティネーション・イメージを表示すること、および、
    複数の遷移イメージを表示すること
    を備えることを特徴とする請求項３８に記載の方法。
42. 前記ソース・イメージは、前記ソース値の１つについての関数であり、
    前記デスティネーション・イメージは、前記デスティネーション値の１つについての関数であることを特徴とする請求項４１に記載の方法。

Images