JP2017107572A - 実時間データを提供するためのシステムおよび方法 - Google Patents

Abstract

【課題】リッチインターネットアプリケーション（ＲＩＡ）に実時間データを提供するシステムおよび方法を開示する。【解決手段】少なくとも１つの実時間データサーバと協働するＲＩＡフレームワークのグラフィックおよびネットワークの特徴は、低減された待ち時間とウェブブラウザにおける実時間データアプリケーションを提供することであって、データはデータソースで生成され、サーバに伝搬され、かつ、サーバで収集される。持続的な接続がＲＩＡからサーバに対して作り出され、ＲＩＡはデータに登録される。登録されたデータは、サーバで収集された少なくとも幾つかのデータを含む。サーバは、データがサーバで収集されるように、持続的な接続を介して登録されたデータをＲＩＡに伝搬する。【選択図】図３

Description

著作権の告知
本特許文献の開示の一部分は、著作権保護を対象とする資料を含む。著作権者は、特許商標庁の特許出願または記録に見られる特許文献、または特許開示物による複製物に異存はないが、その他の点では、何であれ全ての著作権を保有する。

実時間データとは、データが最初に作成された後、一定時間内に処理および／または送信されるべき任意のデジタル情報またはアナログ情報を指す。データが作成された時から処理および／または送信されるまでに経過した時間は、待ち時間として知られている。任意の特定の実時間アプリケーションにとって可能な最大の待ち時間は、アプリケーションに依存する。最大待ち時間が厳しい要件であるアプリケーションは、「ハードな」実時間アプリケーションと呼ぶことができ、最大待ち時間が厳しい要件でないアプリケーションは、「ソフトな」実時間アプリケーションと呼ぶことができる。ソフトな実時間アプリケーションは、時に主観的なアプリケーション依存を満たし、一定の「十分な速さ」を満たすことだけが必要である。非実時間データは、特定の待ち時間要求に何ら応じる必要がないデータである。

「データ」とういう用語は、ハードな実時間、ソフトな実時間、または非実時間データを指し得る。「実時間データ」は、ハードな実時間データまたはソフトな実時間データを指し得る。

実時間データは、典型的に、物理的処理またはデータを処理するコンピュータシステムの外部のコンピュータプログラムに起因して作成される。例えば、実時間データは、モータの状態、流体タンクのレベル、バルブの位置、コンベヤの速度などのような産業プロセスの制御システムに由来する情報と、例えば株のような金融商品用の価格、容量と、ユーザがコンピュータディスプレイでボタンをクリックしたことを示すようなユーザインターフェースにおけるイベントと、ヒトであるオペレータによるデータ入力と、コンピュータ・オペレーティングシステムの状態変化とを含み得る。徐々に変化する視覚的な何らかの情報は、実時間データとして扱うことができる。

データの発信元は、「データソース」と記載され得る。例えば、データは、物理的処理として発信元となり、電気的に計算され、デジタル表現に変換され得るか、またはデータは、デジタル表現の発信元となり得る。一般的に、データはデジタル表現としてデジタルコンピュータで利用可能に作成され、続く零以上のステップがデータをデジタル表現に変換する。データソースは、コンピュータプログラムによりアクセス可能なデジタルの状態にデータを変換するために必要な全てのコンポーネントおよび工程を含み得る。

データソースの類似物は「データシンク」である。データシンクは、データを消費または使用する。幾つかのデータシンクの例は、処理制御システムにおけるアクチュエータ、株式取引システムにおける株式取引ソフトウェア、ユーザインターフェース用アプリケーション、データベースまたは他のデータ・ストレージシステムが挙げられる。

多くのデータソースは、データシンクでもある。従って、データソースは、データソース、データシンク、または同時に両方を含み得る。例えば、データがデータソースに送信される場合、データソースもデータシンクとして働き得る。

コンピュータ・アプリケーションでは、データは通常「サーバ」に管理される。サーバは、データソース、データシンクのいずれか、または両方として働くことができ、「クライアント」アプリケーションは、サーバが管理するデータと相互に作用することが可能となる。

一般的に、クライアント・アプリケーションは、データと相互に作用するためにサーバとの接続を開始しなければならない。この接続は、データとの一または僅かな相互作用の間のみ接続する「一時的」、またはデータと多く相互作用するために接続を持続させ、クライアント・アプリケーションの存続期間のために接続可能な「永続的」が存在し得る。永続的な接続は、「持続」接続とも呼ばれる。

データソースは、データのデジタル表現を定義する一または複数の「データフォーマット」でデータを提供する。データフォーマットは、発行された基本的なデータソースに一致し得るか、またはデータソースに特定的であり得る。同様に、データシンクは、発行された基本フォーマットのデータまたはデータシンクに特定的なフォーマットのデータを必要とし得る。

データソースは、一または複数の「通信プロトコル」を介してデータへのアクセスを提供する。通信プロトコルは、データがデータソースからデータシンクに転送されるメカニズムを特定する。通信プロトコルは、基本的なデータソースに一致し得るか、またはデータソースに特異的であり得る。データソースは、サポートされていないデータフォーマットが、全てサポートされた通信プロトコルを介して送信されるようにデータフォーマットと通信プロトコルとを組み合わせ得る。一般的に「プロトコル」または「データプロトコル」とは、特定の通信プロトコルを介して送信された特定のデータフォーマットの組み合わせを指す。

データシンクは、データソースにより生成されたデータを使用するために、データソースにより提供された少なくとも１つのデータプロトコルをサポートしなければならない。データプロトコルは多大に存在するため、全てのデータソースおよびデータシンクについて全てのデータプロトコルをサポートすることは実用的ではない。結果、データを使用するクライアント・アプリケーションは、通常、主要な目的のために一番必要なプロトコルだけをサポートするように作成される。同様に、データソースも一般的に主要な目的に必要なプトコルのみをサポートする。従って、例えば、ＨＴＴＰプロトコルをサポートするウェブブラウザをＤＤＥプロトコルをサポートする表計算アプリケーションに直接接続させる方法はない。

データシンクにデータソースにより提供されるデータを使用させるために、プロトコルの変換工程が行われて、データソースによってサポートされているプロトコルからデータシンクにサポートされているプロトコルにデータを変換しなければならない。この変換工程は、「ミドルウェア」アプリケーションにより行うことができる。ミドルウェア・アプリケーションの主な目的は、通常はデータソースとデータシンクとが共通してプロトコルを共有する場合は間接的に相互作用できるように、１つのプロトコルから別のプロトコルにデータを変換することによってデータソースとデータシンクとの通信を促すことであり得る。

データソースは、少なくとも２つの方法を使用してデータをデータシンクに転送し得る。
１．オンデマンド。データソースは、データソースで利用可能なデータの一部または全てを要求するデータシンクを受動的に待つ。データシンクがデータを要求した場合は、ソースが要求されたデータの現在の状態を示す結果を用いて応答する。データシンクがデータ変更を知らされる必要があるならば、データシンクはデータソースが更新されたデータを用いて応答するために、データシンクは要求を繰り返さなければならない。データシンクによる同一データに対する繰り返し要求は「ポーリング」として知られている。データシンクは、新しい要求毎にデータソースへの一時的な接続を作り出し得るか、または繰り返し要求が送信される間にわたり持続的な接続を作り出し得る。
２．登録による方法。データシンクはデータソースへの持続的な接続を作り出し、データソースから利用可能な一部または全てのデータを登録する。データソースは、持続的な接続を介して変更が生じるとデータに対する何らかの変化を送信する。データソースは、データシンクが他に特定するかまたは接続が終わるまでデータに対する変化を送信し続ける。

共有メモリ、メッセージ・キュー、およびメールボックスのようなデータ転送方法は、要求または同意方法のいずれかのバリエーションであることが理解される。データ転送、データ伝搬、またはデータ通信という用語は全て、システム内のデータの移動を指し、これらの用語は、特定のデータ通信方法に関連するように、互換可能に使用され得ることもさらに理解される。これらの方法は、通信プロトコルに基づいて独立している。

実時間データを扱うコンピュータ・アプリケーションは、信頼があり、反応がよく、データソースに簡単に接続されなければならない。これは、実時間データ処理アプリケーションが、歴史的に、直接的または間接的にデータソースに接続される単独型のアプリケーションとして作成されてきたことを意味する。この単独型のアーキテクチャは、アプリケーションにコンピュータのグラフィック能力を最大限に利用することも可能とし、実時間データの高等で動的な視覚化を提供する。反対に、ウェブブラウザ技術に基づいたアプリケーションは、データ接続およびグラフィック速度の観点から不適当なことが証明されている。従って、ウェブブラウザにおける広範な実時間データ処理および表示は、利用できなかった。ウェブブラウザでＡｃｔｉｖｅＸコンポーネントを使用してデータ駆動型表示にアクセスする試みを行う開発者もいたが、しかしこれらのコンポーネントは、一般的に現代のブラウザではサポート性が乏しく、これらのコンポーネントが示すセキュリティーの危険性に起因して限定が課される。

内蔵されたブラウザのＪａｖａｓｃｒｉｐｔエンジンを使用して、ウェブブラウザにおいて変化するデータを表示する試みが成されてきた。これは、一般的に、ＡＪＡＸ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｊａｖａｓｃｒｉｐｔ ａｎｄ ＸＭＬ）と呼ばれる手法を用いて実現され、ウェブブラウザは新しいデータを定期的にポーリングし、次いでこれに応じてディスプレイを更新する。このポーリングメカニズムは非常に非効率的であり、比較的少量のデータセットまたは比較的移動が遅いデータにのみ好適である。ＣＰＵまたはネットワークのバンド幅を浪費させないためにポーリングの割合を低減させることは、実時間アプリケーションを受けられないデータの待ち時間が増えることに対し効果がある。

ストリーミングＡＪＡＸと呼ばれるメカニズムを介してＡＪＡＸを改善する試みは、ブラウザのページをロードするメカニズムの副作用を利用してＪａｖａｓｃｒｉｐｔコマンドを徐々にページに対して追加することによりブラウザのページを増加的に拡大させる。Ｊａｖａｓｃｒｉｐｔコマンドの各々は、連続的なデータの流れといった印象を与えながらコマンドが立ち上がると実行する。ウェブブラウザは、事実上、ネットワーク接続が遅い間に極めて大量のウェブページを負担しているものと思い込む。この方法は、ウェブブラウザのメモリやＣＰＵの使用が、送信されるこれまでにない大量のページに起因して続けて徐々に増えていく事実を含め、幾つかの障害を持つ。

ＡＪＡＸもストリーミングＡＪＡＸの方法もウェブブラウザ内のディスプレイ選択肢という品質の欠損を被る。ウェブブラウザは、一般的に静止ページおよびウェブ「フォーム」のディスプレイ用に設計されており、高速または高品質なグラフィックの提示という選択肢を提供しない。グラフィカルなディスプレイという選択肢に対する改善のための試みは、ブラウザ間では両立しない虜があり、一般的に非常に実行が遅い。

内蔵されたウェブブラウザの能力に基づいて全てのデータを送信する解決法は、ウェブブラウザでデータを受信することを最初に標的とする。データ通信は、一方向であり、また、サーバからデータを受信する接続は、サーバにデータを送信するために使用することもできない。サーバにデータを再送信する必要がある場合は、新たに接続を開き、ＨＴＴＰリクエストを送信し、次いで再び接続を閉じなければならない。従って、ストリーミングＡＪＡＸのような解決法は、膨大なオーバーヘッドとデータ送信の毎に新しいＨＴＴＰリクエストを発行しなければならないことにより被る待ち時間とにより、データサーバにデータを送信するのが非常に遅い。

速いかのように見えるが遅く移動する（待ち時間が長い）データを提示することによりユーザ体験を改善しようというウェブベースのデータ視覚化に対する試みが成されている。これは、実際に到着するデータよりも高い頻度でウェブブラウザに補完データを表示することにより実現される。速度計を意味する環状ゲージは、５秒毎に分離された１〜１００の値を受信する。次に、ウェブページは、各回に４回値を変えながら１秒間にゲージダイヤルを５回取り出す。これにより、根本的なデータ伝達はそのような情報を含まないが、視聴者に滑らかに速度が変化する印象を与える。すなわち、そのような補間データの表示は、もっぱら視聴者を惑わせる場合がある。こうした種類の補間は根本的なデータの実際の動作を曖昧にし、通常、プロセス制御および株式市場の取引のような実時間アプリケーションでは許容できない。

Ａｄｏｂｅ Ｆｌａｓｈ（商標）およびＭｉｃｒｏｓｏｆｔ Ｓｉｌｖｅｒｌｉｇｈｔ（商標）のようなリッチインターネットアプリケーション（「ＲＩＡ」）フレームワークは、ウェブブラウザにおけるデータ処理およびグラフィック描写の両方について改善されたプラットフォームを提供する。これらのＲＩＡフレームワークはまた、ＲＩＡ内での直接的なＴＣＰ／ＩＰ通信をサポートする。驚くべきことに、これらの特徴を組み合わせることにより、ウェブブラウザでの実時間情報を処理および表示することが可能となる。この処理・表示能力は、ＲＩＡが主にビデオ、宣伝、およびゲームに好適であるというソフトウェア産業における認識に起因して、実時間データシステムに移転されてこなかった。

本発明は、ウェブブラウザで少ない待ち時間の実時間データアプリケーションを提供するために、少なくとも１つの実時間データサーバと協働する、ＲＩＡフレームワークのグラフィック特性およびネットワーク特性を使用するためのシステムおよび方法を提供する。本発明は、データソースのデータがウェブブラウザ内で使用できないデータソースを同時に扱いながら、現在のＡＪＡＸおよびストリーミングＡＪＡＸの限定を克服する。

本発明は、最先端の技術により、あるポイントまでのデータ待ち時間を縮小することでウェブブラウザへの実時間データの送達を改善し、視覚化コンポーネントは、補間値ではなく実際のデータ値を使用して活発化できる。これにより、データの一時的な動作がユーザに対して一層正確に提示される。一時的なデータの動作は、通常、そのデータにより提示される実際の動的な実時間システムの理解に重要である。例えば、物理的ゲージを観察する者は、ゲージ針の動作に振動またはオーバーシュートを観察することにより重要なシステムの特性を判別することができる。本発明の一実施形態では、物理的ゲージのデジタル表現は針の原動力を捕獲し、物理的ゲージとして同じように高品質の情報を提供することができる。

本発明は、ＣＰＵおよびネットワークのコストを抑え、待ち時間を低減させながら、ユーザからデータサーバへのデータ送信の速度を大幅に改善する。これにより、ユーザは、システムの反応が現在の動作に重要な、一層高機能な制御シナリオに参加することが可能となる。例えば、システムは、容器に水を注ぐ間に、相互作用を維持および解除するための相互作用を必要とし得る。ユーザはボタンを押し、容器が満タンになるまで維持し、次いでボタンを離す。システムが、容器から溢れないように迅速に応答しなければならないことは明白である。この種の制御は、データ伝達の待ち時間が予測できないことに起因して、典型的なウェブベース・アプリケーションでは実行できない。驚くべきことに、本発明は、以前は遅すぎ、信頼性がなく、またはウェブブラウザを通して検討されるには原始的であったこの種の制御および実時間データ・アプリケーションを可能にする。

典型的なウェブアプリケーションは、アプリケーション設計者による特異的なフォーマットで提供されるデータを扱う。これは、エンドユーザの選択を限定する意図的な方法であり得、または単に設計に対する限定であり得る。データフォーマットが（ＸＭＬまたはＪＳＯＮなどの）業界基準に従っている場合でも、データソースはアプリケーションに特異的である。本発明はまた、業界基準および所有者のソースの両方を発信元とする多種多様な実時間データを送達するための汎用的なメカニズムも提供する。有利に、本発明はさらに、種々のデータフォーマットでそのデータを提供することができる。

多くのデータソース、実時間および非実時間は、ネットワークの使用（すなわち、ネットワークを通した送信）を意図しない。本発明によれば、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ（商標）（マイクロソフト株式会社）のようなデータソースからのデータをネットワークを通して任意のＲＩＡまたはウェブベース・アプリケーションに確実かつ迅速に送達することが可能となる。ＯＰＣに基づいたデータソースのようなデータソースは、ネットワークの使用を意図するものであったが、ウェブブラウザと通信するようには設計されていない。本発明によれば、ウェブベース・アプリケーションに確実かつ迅速にこれらのソースを送達することが可能となる。データベース・システムのような他のデータソースは、実時間情報について全くインターフェースを提供していない。本発明によれば、データベース・アプリケーショのようなソースからの非実時間データを実時間データのように送達することが可能となり、それにより、ＲＩＡまたはウェブベース・アプリケーションのために非効率的なデータベースのポーリングの必要性を排除する。

データソースおよびデータシンクは、持続的な接続または一時的な接続によりサーバと接続し得る。サーバに接続する方法は、特定のデータソースまたはデータシンクの要求を反映させることが理解される。

本発明は、一または複数のデータソースからの実時間データがリッチインターネットアプリケーションで効率的に利用できる方法を提供する。本発明はさらに、ＲＩＡが、効率的に実時間データに変更するか、またはソースデータ（単数または複数）に再び送信することができる新規の実時間データを生成するための方法を提供する。ソースデータ（単数または複数）は、ネットワーク上の他のＲＩＡにそのデータを再送信することができる。従って、本発明によれば、効率的に任意の数のＲＩＡアプリケーションが実時間で別のＲＩＡアプリケーションと通信し、一つまたは多くの実時間データソースと協働して通信することが可能となる。抽出することにより提示可能な任意のデータが発信元のソース、提示、または転送プロトコルの有無に関わらずＲＩＡで利用できるように、本発明は実時間データの抽出が可能である。

本発明の一実施形態に係る、ＲＩＡとデータサーバとの間の直接接続を示す例示的なブロック図である。 本発明の一実施形態に係る、ＲＩＡと、サーバと、別離したデータソースとの間の接続を示す例示的なブロック図である。 本発明の一実施形態に係る、複数のＲＩＡと、サーバと、複数の別離したデータソースとの間の接続を示す例示的なブロック図である。 本発明の一実施形態に係る、ＲＩＡの制御フローの一方法を示すフローチャートである。 本発明の一実施形態に係る、サーバ操作の一方法を示すフローチャートである。 本発明の一実施形態に係る、サーバ操作の一方法を示すフローチャートである。 本発明の一実施形態に係る、複数のＲＩＡへの同時接続を管理するデータサーバを示す例示的なブロック図である。 本発明の一実施形態に係る、表計算アプリケーションとＲＩＡとの間のローカルネットワークまたは広域ネットワークを介したデータの実時間通信を示す例示的なブロック図である。 本発明の一実施形態に係る、システムの実施を示す例示的なブロック図である。

以下の記載は、どの当業者も本発明を成すことができ、使用できるように提示され、本発明の特定のアプリケーションを背景として提供される。開示される実施形態に対する種々の変更が当業者には容易に明らかとなり、本明細書で定義される一般原則は、本発明の範囲から逸脱することなく他の実施形態およびアプリケーションに適用され得る。種々の実施形態および実施例に対する言及は、本発明の範囲を限定せず、本明細書に添付した請求の範囲によってのみ限定される。従って、本明細書で説明する例のどれもが限定されることを意図しておらず、主張する本発明について、可能性のある多くの実施形態のうちの幾つかを説明するにすぎない。

本発明の実施形態が実行されるプログラム環境には、例示的に、汎用コンピュータ、または携帯用コンピュータ若しくは携帯電話のような特殊目的の装置が組み込まれる。そのような装置（例えば、プロセッサ、メモリ、データストレージ、ディスプレイ、ユーザの入力手段）の詳細は、明瞭さのために省略され得る。

本発明の技術は、種々の技術を使用することにより実装され得ることも理解される。例えば、本明細書に記載される方法は、コンピュータシステムで実行されるソフトウェアに実装されるか、またはマイクロプロセッサ、若しくは他の特別に設計されたアプリケーションに特異的な集積回路、プログラム可能な倫理装置のいずれかの組み合わせ若しくは種々の組み合わせを用いてハードウェアに実装され得る。詳細には、本明細書に記載される方法は、コンピュータで読み取り可能な好適な媒体に存在する、コンピュータが実行可能な一連の命令により実施され得る。コンピュータで読み取り可能な好適な媒体は、揮発性（例えばＲＡＭ）および／または不揮発性（例えばＲＯＭ、ディスク）メモリ、搬送波、並びに通信媒体（例えば、銅線、同軸ケーブル、光ファイバ媒体）を含み得る。例示的な搬送波は、ローカルネットワーク、インターネットまたは他の幾つかの通信リンクのような公的にアクセス可能なネットワークに従ってデジタルデータ・ストリームを搬送する電気信号、電磁信号、または光信号の形態を取り得る。

図面に示される例示の実施形態を参照すると、簡易化された例は明瞭さのために選択されたことが理解される。図面に見受けられる一つの構成要素における単一の例（例えば、ＲＩＡ、サーバ、データソース、データシンクなど）は、複数の同じ構成要素と置換され得、それも本発明の範囲内に含まれる。

従って、一態様において、本発明は、ＲＩＡに実時間データを提供する方法を提供する。その方法は、データソースでデータを生成することと、サーバにデータを伝搬することと、サーバでデータを収集することと、ＲＩＡからサーバへの持続的な接続を作り出すことと、登録されたデータに前記ＲＩＡを登録させることとを含み、登録されたデータは、サーバで収集された少なくとも幾つかのデータを含み、サーバは、データがサーバで収集されるように持続的な接続を介して登録されたデータをＲＩＡに伝搬する。方法はさらに、ＲＩＡが発信元のデータをサーバに送信することを含み得る。ＲＩＡが発信元のデータは、持続的な接続を通したデータに対する少なくとも１つの変化リクエストを含み得る。さらにデータは、少なくとも１つの中間コンポーネントを介して伝搬され得る。サーバは、少なくとも１つの変化リクエストを受信し得、少なくとも１つの変化リクエストをデータソースに送信し得る。少なくとも１つの変化リクエストは、中間コンポーネントを介して伝達され得る。中間コンポーネントは、中間ハードウェアコンポーネントまたは中間ソフトウェアコンポーネントであり得る。任意に、ＲＩＡが登録されたデータに登録し得る。データソースでデータを生成し、そのデータをサーバに伝搬することは、サーバでデータを収集することとともに行われ得る。ＲＩＡは、計算またはグラフィック描写の変更など、データに基づいてアクションを遂行し得る。ＲＩＡは、ユーザディスプレイ上にデータの視覚表示を提供し、ユーザはＲＩＡが発信元のデータを生成するために視覚表示とやり取りし得る。視覚表示は、ＲＩＡフレームワーク内で実行するプログラムであり得る。ＲＩＡが発信元のデータは、サーバを停止させるか、またはどのデータがサーバから届いたのか変えるなど、その動作を変えるために、サーバに命令してアクションを遂行させ得る。

例えば、ＲＩＡが発信元のデータは、ユーザとの処理の結果、タイマーイベント、サーバに由来するデータへの応答、スクリプト、またはユーザではなく生成された別のイベントであり得る。

別の態様では、本発明は、実時間データをＲＩＡに提供するコンピュータに実装された方法を提供する。前記方法は、データソースからデータを提供することと、データソースからサーバにデータソースを伝搬することと、サーバでデータを収集することと、ＲＩＡでデータを生成することと、サーバからＲＩＡへの第１持続接続を作り出すことと、ＲＩＡからサーバへの第２持続接続を作り出すことと、第２持続接続を介してＲＩＡからサーバにデータを伝搬することと、登録されたデータにＲＩＡを登録することとを含み、登録されたデータは、サーバで収集された少なくとも幾つかのデータを含み、サーバは、第１持続接続を介してＲＩＡに登録されたデータを伝搬する。方法はさらに、サーバからデータシンクにデータを伝搬することを含む。第１持続接続および第２持続的な接続は、単一接続から成り得る。データソース、データシンク、およびサーバは、単一のコンポーネントまたは２つのコンポーネントの任意の組み合わせから成り得る。データは、ソフトウェアコンポーネント、ハードウェア、コンポーネント、およびネットワークを含む群から選択される少なくとも１つの中間物を介して伝搬され得る。

データ項目は、登録に基づいてＲＩＡとサーバとの間で伝搬され得、データ項目はデータ項目の変化に応じて直ぐに伝搬される。伝搬されたデータは、数値データ、非数値データ、構成設定、および実行コマンドを含む群から選択され得る。ＲＩＡは、データに基づいてアクションを遂行し得、該アクションは、ユーザディスプレイの視覚表示の変更、計算、新規データの生成、既存データの変更、データの格納、可聴表示、スクリプトの実行、サーバへのデータの伝搬、ユーザ可視なプログラミングの応答、ユーザ不可視なプログラミングの応答を含む群から選択される。ＲＩＡで生成されたデータは、サーバに命令して、サーバ内でのデータの変更、サーバに接続されたデータシンクへのデータの伝搬、スクリプトの実行、ファイルシステムへのデータの格納、新規データの作成、サーバに接続されたデータシンクへの新規データの伝搬、サーバ構成の変更、サーバ動作の変更、ユーザ可視なプログラミングの応答、およびユーザ不可視なプログラミングの応答を含む群から選択されるアクションを遂行させ得る。

さらに別の態様では、本発明は、上述したように、一または複数のコンピュータで実行される場合に、実時間データをＲＩＡに提供する方法をコンピュータに行わせる命令を記憶したコンピュータ読み取り可能な記憶媒体を提供する。

別の態様では、本発明は、ＲＩＡに実時間を提供するためのコンピュータシステムを提供する。前記システムは、プロセッサと、入力手段と、ディスプレイと、少なくとも１つのデータソースと、少なくとも１つのデータソースからデータを収集するためのデータ収集コンポーネント、および少なくとも１つのデータクライアントにデータを放出するためのデータ放出コンポーネントを備える少なくとも１つのサーバと、少なくとも１つのＲＩＡと、任意に少なくとも１つのデータシンクとを備える。サーバはさらに、データ放出コンポーネントにより放出するためにデータ収集コンポーネントにより収集されたデータの形態を変更するためのデータ変更コンポーネントを備え得る。少なくとも１つのデータソースと少なくとも１つのサーバは、少なくとも１つのコンピュータプログラム（すなわち、単一のコンピュータプログラム、または２つ以上の別箇のコンピュータプログラム）に実装され得ることが理解される。

サーバはさらに、データ変更コンポーネントと、データ生成コンポーネントと、ユーザインターフェース用コンポーネントと、コンピュータファイルシステム相互作用コンポーネントと、サーバで実行するコンピュータ上で実行する他のプログラムと相互作用するためのプログラム相互作用コンポーネントと、プログラム可能なアクションを行うためのスクリプト言語コンポーネントと、クライアントプログラムからＨＴＴＰリクエストを受け、それらリクエストに特定される文書を用いて、「ウェブサーバ」に類似する方法で応答するためのＨＴＴＰコンポーネントであって、前記リクエストに応じる文書を動的に構築し、サーバに在るデータの現在の値とサーバが内蔵するスクリプト言語で実行制御文の結果を文書内に含める能力を備えるＨＴＴＰコンポーネントと、任意のローカルまたはネットワークでアクセス可能なコンピュータで実行する別の一例のサーバとデータを交換または同期すし、両方のサーバがそのデータの基本的に同一の複製を維持することができ、それにより、いずれかの一例のサーバに接続されたクライアント・アプリケーションが相互に作用する 同じデータセットと相互作用することができる、同期コンポーネントと、データが収集される割合を限定するための第１調整コンポーネントと、データが放出される割合を限定するための第２調整コンポーネントと、他のサーバへの接続性の損失を検出し、接続性が取り戻せる場合は他のサーバに再接続する接続コンポーネントと、他のサーバからのデータが、一または複数の他のサーバがアクセスできないように同一または類似する情報を持つ複数の他のサーバと重複して接続する重複コンポーネントと、ソース内の幾つかまたは全てのデータが別のデータと類似する値を維持するようにデータソースのデータを橋絡するか、または１つのソースにあるデータが他のソースにあるデータの数学的変換として維持されるように橋絡するブリッジングコンポーネントであって、双方向のブリッジング操作を介して順方向にも逆方向にも数学的変換を適用する能力を備えるブリッジングコンポーネントと、から選択される一または複数のコンポーネントを備え得る。この一式のサーバコンポーネントは、他のデータの収集、並びに通信メカニズム、他の処理メカニズム、および他の記憶メカニズムをサポートするために、サーバに追加機能を追加することにより拡張することができることが理解される。

データ収集コンポーネントは、一または複数の以下の方法でデータを収集し得る：
オンデマンドであって、サーバは、別のサーバに在る幾つかまたは全てのデータのためにリクエストを送信し、他のサーバはそのリクエストに応じて、リクエストされたデータの現在の値（単数または複数）を用いて一度だけ応答する、方法と、登録による方法であって、サーバは、別のサーバにある幾つかまたは全てのデータに対し登録のためのリクエストを送信し、他のサーバは、そのデータの現在の値（単数または複数）を送信することにより応答し、次いでサーバが他のサーバとの接続を終了するか、または他のサーバが更新の送信を中止することをリクエストするまで、データの値（単数または複数）に対する逐次的変化を送信し続ける方法と、
トリガによる方法であって、クライアント、スクリプトまたはヒト（ユーザ）が、あるトリガの状況が、タイマ、時刻、データ変化、システム状態の変化、ユーザアクション、または他の幾つかの検出可能なイベントを満たす場合にのみデータを収集するようにサーバを構成する方法と、
サーバにデータを送信するために「クライアント」アプリケーションを受動的に待つ方法。

データ放出コンポーネントは、一または複数の以下の方法でデータを放出し得る：
オンデマンドであって、「クライアント」アプリケーションは、幾つかまたは全てのデータに対してリクエストを送信し、サーバはリクエストに応じて、リクエストされたデータの現在の値（単数または複数）を用いて一度だけ応答する方法と、
登録による方法であって、クライアント・アプリケーションは、幾つかまたは全てのデータを登録するためのリクエストを送信し、サーバがデータの現在の値（単数または複数）を送信することにより応答し、次いでクライアントがサーバとの接続を終了するか、またはサーバが更新の送信を中止することをリクエストするまでデータの値（単数または複数）に対する逐次的変化を送信し続ける、方法と、
トリガによる方法であって、クライアント、スクリプト、またはヒト（ユーザ）が、あるトリガの条件がタイマ、時刻、データ変化、システム状態の変化、ユーザアクション、または他の幾つかの検出可能なイベントを満たす場合にのみデータを放出するようにサーバを構成する方法。

データ収集コンポーネントで収集されるデータは、Ｄｙｎａｍｉｃ Ｄａｔａ Ｅｘｃｈａｎｇｅ（ＤＤＥ）、ＯＬＥ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ（ＯＰＣ）、ＯＰＣアラームおよびイベント仕様（ＯＰＣ Ａ＆Ｅ）、Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＯＰＣ−ＵＡ）、ＯＰＣ Ｅｘｐｒｅｓｓ インターフェース（ＯＰＣ−Ｘｉ）、ＴＣＰ／ＩＰ、カスタムインターフェースを介してＴＣＰ／ＩＰを渡るＳＳＬ（セキュア・ソケット・レイヤー）、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）、Ｓｅｃｕｒｅ ＨＴＴＰ（ＨＴＴＰＳ）、オープン・データベース・コネクティビティ（ＯＤＢＣ）、Ｍｉｃｒｏｓｏｆｔ Ｒｅａｌ−Ｔｉｍｅ Ｄａｔａ ｓｐｅｃｉｆｉｃａｔｉｏｎ （ＲＴＤ）、メッセージ・キュー、Ｗｉｎｄｏｗｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｆｏｕｎｄａｔｉｏｎ （ＷＣＦ）、ＰｒｏｆｉｂｕｓおよびＭｏｄｂｕｓなどの工業用バスのプロトコル、Ｗｉｎｄｏｗｓ Ｓｙｓｔｅｍパフォーマンス・カウンタ、システムに組み込まれたＴＣＰ／ＩＰ通信、ＭＳ−Ｗｉｎｄｏｗｓ（登録商標）ではないシステムに由来するＴＣＰ／ＩＰ通信、Ｌｉｎｕｘ（登録商標）に由来するＴＣＰ／ＩＰ通信、ＱＮＸに由来するＴＣＰ／ＩＰ通信、ＴＲＯＮに由来するＴＣＰ／ＩＰ通信、ＣコンパイラおよびＴＣＰ実装を提供する任意のシステムに由来するＴＣＰ／ＩＰ通信、内蔵のスクリプト言語を使用して記載されたスクリプト、ユーザインターフェースを介してヒトが入力したデータ、ローカルディスクファイルから読み込まれたデータ、リモートからアクセス可能なディスクファイルから読み込まれたデータ、所有者のフォーマット、ユーザが定義したフォーマット、並びにサーバへの拡張を通じて追加されたフォーマットから選択される一または複数の通信プロトコルを使用して受信され得る。所有者のフォーマットの一例は、Ｗｏｎｄｅｒｗａｒｅ ＳｕｉｔｅＬｉｎｋ（商標）である。

データ放出コンポーネントから放出されるデータは、Ｄｙｎａｍｉｃ Ｄａｔａ Ｅｘｃｈａｎｇｅ （ＤＤＥ）、ＯＬＥ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ （ＯＰＣ）、ＯＰＣアラームおよびイベント仕様（ＯＰＣ Ａ＆Ｅ）Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＯＰＣ−ＵＡ）、（ＯＰＣ−ＵＡ）、ＯＰＣ Ｅｘｐｒｅｓｓ インターフェース （ＯＰＣ−Ｘｉ）、ＴＣＰ／ＩＰ、カスタムインターフェースを介してＴＣＰ／ＩＰを渡るＳＳＬ（セキュア・ソケット・レイヤー）、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）、Ｓｅｃｕｒｅ ＨＴＴＰ（ＨＴＴＰＳ）、オープン・データベース・コネクティビティ（ＯＤＢＣ）、Ｍｉｃｒｏｓｏｆｔ Ｒｅａｌ−Ｔｉｍｅ Ｄａｔａ ｓｐｅｃｉｆｉｃａｔｉｏｎ （ＲＴＤ）、メッセージ・キュー、Ｗｉｎｄｏｗｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｆｏｕｎｄａｔｉｏｎ （ＷＣＦ）、ＰｒｏｆｉｂｕｓおよびＭｏｄｂｕｓなどの工業用バスのプロトコル， Ｗｉｎｄｏｗｓ Ｓｙｓｔｅｍパフォーマンス・カウンタ、システムに組み込まれたＴＣＰ／ＩＰ通信、ＭＳ−Ｗｉｎｄｏｗｓ（登録商標）ではないシステムに由来するＴＣＰ／ＩＰ通信、Ｌｉｎｕｘ（登録商標）に由来するＴＣＰ／ＩＰ通信、ＱＮＸに由来するＴＣＰ／ＩＰ通信、ＴＲＯＮに由来するＴＣＰ／ＩＰ通信、ＣコンパイラおよびＴＣＰ実装を提供する任意のシステムに由来するＴＣＰ／ＩＰ通信、内蔵のスクリプト言語を使用して記載されたスクリプト、ユーザインターフェースを介してヒトに提示されるデータ、ローカルディスクファイルから読み込まれたデータ、リモートからアクセス可能なディスクファイルから読み込まれたデータ、所有者のフォーマット、ユーザが定義したフォーマット、サーバへの拡張を通じて追加されたフォーマット、電子メール（Ｅメール）、並びにショート・メッセージ・サービス（ＳＭＳ）のメッセージフォーマットから選択される一または複数の通信プロトコルを使用して送信され得る。

さらに、データ収集コンポーネントで収集されたデータは、通信プロトコルに適したフォーマットであり得る。データ放出コンポーネントから放出されたデータは、通信プロトコルに適したフォーマットであり得る。データ収集コンポーネントで収集されたデータおよびデータ放出コンポーネントから放出されたデータもまた、括弧付き表現（ＬＩＳＰなど）のフォーマット、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ）、Ｊａｖａｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ （ＪＳＯＮ）、プロプライエタリ・バイナリ・フォーマット、ユーザ定義可能なテキストフォーマット、並びにサーバの拡張を通じて追加されたフォーマットから選択されるフォーマットであり得る。

システムはさらに、ＴＣＰ／ＩＰ接続およびサーバによりサポートされた一または複数のデータフォーマットを実装するアプリケーション・プログラミング・インターフェース（ＡＰＩ）を備え、ＡＰＩは上述した接続の確立においてプログラマを支援し得る。ＡＰＩは、以下のプラットフォーム：「Ｃ」プログラミング言語、「Ｃ＋＋」プログラミング言語、ＭｉｃｒｏｓｏｆｔのＮｅｔプログラミング環境、Ｍｉｃｒｏｓｏｆｔ ＳｉｌｖｅｒｌｉｇｈｔのＲＩＡフレームワーク、Ａｄｏｂｅ ＦｌａｓｈのＲＩＡフレームワーク、Ａｄｏｂｅ ＡｉｒのＲＩＡフレームワーク、ＴＣＰ／ＩＰ通信をサポートするプログラミング言語（任意のスクリプト言語を含む）、並びにＴＣＰ／ＩＰ通信をサポートするＲＩＡフレームワークのうち一または複数のプラットフォームのために実装され得る。

ＲＩＡは、Ｍｉｃｒｏｓｏｆｔ Ｓｉｌｖｅｒｌｉｇｈｔ、Ａｄｏｂｅ Ａｉｒ、およびＴＣＰ／ＩＰ通信をサポートするＲＩＡフレームワークから選択されるＲＩＡフレームワークを使用して実装され得る。ＲＩＡフレームワークは、データを受信するためサーバへの第１の永続的ＴＣＰ／ＩＰデータ接続を作り出し、サーバからデータを受信し、第２ＴＣＰ／ＩＰデータ接続を通じてサーバにデータを送信するためのサポートを備え得る。データは、オンデマンド、または登録によりサーバから受信され得る。第１ＴＣＰ／ＩＰデータ接続および第２ＴＣＰ／ＩＰデータ接続は、同じ接続であり得る。第２ＴＣＰ／ＩＰデータ接続永続的接続であり得る。第２ＴＣＰ／ＩＰデータ接続は、一時的な接続であり得る。サーバへのＴＣＰ／ＩＰデータ接続は、上述したＡＰＩ直接のＴＣＰ／ＩＰ接続、ＨＴＴＰ、およびＨＴＴＰＳから選択されるプロトコルであり得る。

サーバからのデータは、括弧付き表現（ＬＩＳＰなど）のフォーマット、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ）、Ｊａｖａｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）プロプライエタリ・バイナリ・フォーマット、ユーザ定義可能なテキストフォーマット、並びにサーバへの拡張により追加されたフォーマットから選択される一または複数のフォームで受信され得るか、またはサーバへのデータは送信され得る。

ＲＩＡフレームワークはさらに、データを示すグラフィックディスプレイをユーザに提示するためのサポートを備え得る。グラフィックディスプレイは、テキスト表示、スライダ、チャート、傾向グラフ、環状ゲージ、線形ゲージ、ボタン、チェックボックス、ラジオボタン、プログレスバー、基本のグラフィカル・オブジェクト、ＲＩＡフレームワークにサポートされているコントロール、ＲＩＡフレームワークを拡張するために作成されたカスタムコントロール、ＲＩＡフレームワークを使用して実装された第三者コントロール、およびカスタム化されたグラフィック要素から選択される一または複数のグラフィック要素を備え得る。

グラフィックディスプレイの構成情報は、サーバ上で保存されるとともにサーバからロードされ得る。グラフィック要素は、グラフィックディスプレイにおいて作成および変更され得る。グラフィック要素は、ユーザがカスタム可能なカスタム化されたグラフィック要素であり得、カスタム化はサーバ上で保存され得る。カスタム化は、ＲＩＡフレームワークに実装されたアプリケーションに変更を必要とすることなくプログラマにより行われ得る。カスタム化されたグラフィック要素は、他のグラフィック描写でユーザが使用するために利用可能であり得る。これらのカスタム化は、ユーザインターフェース・アプリケーションにより元々サポートされているグラフィック要素に全て追加して、新たなディスプレイを作成し、既存のディスプレイを変更するためのものであり得る。グラフィック要素は、ユーザが変更可能な一または複数の特性を備え得、プログラマにより選択可能であり得る。ユーザのグラフィック要素との相互作用により、ユーザインターフェース・アプリケーションがデータに対する変更をサーバに放出させる。ユーザ専用モードが提供されると、ユーザによるグラフィックディスプレイの作成または変更を許可せず、また読み取り専用モードが提供されると、ユーザによるグラフィック要素との相互作用を許可しない。システム・アドミニストレータは、ユーザと、ユーザインターフェース・アプリケーションがユーザ専用モードおよび読み取り専用モードの１つで動作するグラフィックディスプレイを選択し得る。ユーザは、識別が必要とされる場合に自身を識別することが必要とされ、ユーザインターフェース・アプリケーションは、ユーザ専用モードおよび読み取り専用モードの少なくとも１つのモードで動作し得る。有利に、本発明の特徴によると、任意のユーザＲＩＡ端末を通してグラフィックディスプレイの変更が可能であり、保存により生じた変更は、サーバに接続された他の全てのＲＩＡ端末が直ぐに利用することができる。

図１を参照すると、一実施形態において、ＲＩＡ１０１は、データソースおよびデータサーバ１００の両方として機能するプログラムに対しデータが直接接続する。この状況は、データソースがＴＣＰ／ＩＰプロトコルを用いる生データのコレクタおよびトランスミッタの両方である場合に生じ得る。ＰＬＣ内に組み込まれたＯＰＣ−ＵＡサーバがこの例である。別の例は、データソースとして機能し、カスタム用ＴＣＰ／ＩＰインターフェースを提供するＴＣＰ／ＩＰサーバの能力を提供する組み込み装置である。さらに別の例は、ＴＣＰ／ＩＰインターフェースを提供する株式市場のデータ供給である。

図２を参照すると、一実施形態において、別の構成は別個になったデータソース２０２とサーバ２０３とを含む。この構成は、データソース２０２のデータプロトコルを、ＲＩＡ２０１が処理できるＴＣＰ／ＩＰプロトコルに変換することにより通信モデルを拡張する。これにより、サーバ２０３がＴＣＰ／ＩＰのインターフェースを直接提供しないデータソース２０２と相互作用することが可能になるため、データソース２０２の数および種類が非常に拡大される。

図３を参照すると、一実施形態において、サーバ３０３は、同時に２つ以上のデータソース３０２と２つ以上のＲＩＡ３０１との接続を維持し得る。この一層複雑な構成は、データソース３０２とＲＩＡ３０１とからのデータを、ＴＣＰ／ＩＰネットワーク上のどこからでもアクセス可能な単一のデータセットに集約する。

別の実施形態では、システムは、複数のデータソースおよび／または一若しくは複数のＲＩＡと内部接続された複数のサーバを含み得る。

図４を参照すると、一実施形態におけるＲＩＡ動作の方法および制御フローが示される。ＲＩＡは、一または複数は組み込まれ得るが、明確な停止基準を必要としない。ＲＩＡは、ユーザＲＩＡを含むウェブブラウザまたはウェブページを閉じたときに暗黙的に停止される。ＲＩＡは、２つの制御フローを同時に従い、単一のプログラムスレッドにインターリーブされるか、または別個のプログラムスレッドに実装され得る。方法は、ＲＩＡに特異的な追加処理を含み得る。

１つ目の制御フローでは、ＲＩＡはサーバへの接続を確立および維持、並びにサーバから利用可能なデータにおける変化への応答を試みる。まず、ＲＩＡは接続の確立を試みる（ステップ４０１）。接続が成功しない場合、ＲＩＡはただひたすらその接続を試みる。接続が成功する場合（ステップ４０２）、次いでＲＩＡは、全てまたは一部分のデータセットに参加し得る（ステップ４０３）。代替的に、接続していることに基づいてサーバがデータにＲＩＡを黙示的に加えることが可能であり、この場合ステップ４０３は省略されてよい。参加に加えて、ＲＩＡは、接続の更新の最短時間またはタイムアウトパラメータなどデータ送信動作を構成するため、サーバに他の情報も送信し得る。

接続を確立すると、ＲＩＡはサーバからデータにおける変化通知を待つ（ステップ４０４）。データ変更が生じている場合（ステップ４０５）、次いでＲＩＡは何らかの方法でそのデータを処理する（ステップ４０７）。この処理は、ＲＩＡの内部状態を変更、グラフィック描写を変更、ＲＩＡ設計者が決定する音または他の任意のログラミングの応答を出すためであり得る。データ変化が生じない場合、ＲＩＡは何等かの理由でサーバへの接続が切れたかを特定するために調べる。接続が切れていない場合、ＲＩＡは再びデータ変化が生じるのを待つ（ステップ４０４）。接続が切れている場合、その時ＲＩＡは再びサーバへの接続を試みる（ステップ４０１）。

ステップ４０１〜ステップ４０７と同時に、ＲＩＡはユーザ入力を受入れ、ユーザは、サーバに伝搬できるデータの変化を作成することが可能となる。ＲＩＡは、別個のプログラムスレッドまたはステップ４０１〜ステップ４０７と多重化してユーザ入力を待つ（ステップ４２０）。

図４は、別々にスレッド構成された方法を例示する。ユーザ入力が生じた場合（ステップ４２１）、次いでＲＩＡは、結果生じたデータのサーバへの送信を試みることができる。ＲＩＡは、サーバが接続されているか（ステップ４２２）を確かめるためにまず調べることでこの試みを行う。接続されている場合、ＲＩＡは新しいデータをサーバに送信する（ステップ４２３）。接続されていない場合、ＲＩＡはさらに入力を待つ（ステップ４２０）。サーバ接続のチェック（ステップ４２２）は、データを送信するために暗黙的に試みられ、この場合、ステップ４２２およびステップ４２３は実質的に組み合わせられる。

ＲＩＡはまた、ユーザ入力が受入れられないなど相互作用できない場合、ステップ４２０〜ステップ４２３を省略することができる。

図５を参照すると、一実施形態におけるデータサーバの動作方法が示される。サーバは、０以上のＲＩＡ接続にデータを出しながら、同時に０以上のデータソースからデータを収集し得る。主要な２つの制御フローを別々のスレッドか、または単一のスレッド内で２つの制御フローパスをインターリーブすることにより実装することができる。

データソースと相互に作用するために、サーバはまずそのデータソースとの接続を確立しなければならない（ステップ５０１）。通常、サーバがデータソースへの該接続を開始する。場合によっては、データソースがサーバへのその接続を開始する。接続が成功する場合（ステップ５０２）、サーバはデータソースからデータを収集し始める（ステップ５０３）。接続が失敗する場合、サーバはデータソースへの接続を再度試みる（ステップ５０１）。データソースがサーバへの接続の開始側である場合、次いでステップ５０１およびステップ５０２は単一の待ち状態へと折り重なり、サーバは接続するため受動的にデータソースを待つ。データの収集（ステップ５０３）は、データソースに適した方法に従い、一方のデータソースと別のデータソースで異なり得る。サーバは、データをサーバに表示することができる任意のデータソースと適応するように作成することができる。新規データがデータソースから利用可能になると（ステップ５０４）、サーバはそのデータをサーバの内部のデータ表現に変換する。これにより、サーバは異なるデータ表現を使用して種々のデータソースを集めることが可能となる。ステップ５０６は、データソース、サーバ、およびＲＩＳが全て同じデータ表現を使用する簡単なケースの場合に省略することができる。次いでサーバは、データの各ＲＩＡへの送信を試みる。サーバはまず、ＲＩＡが接続されるように確立し得る（ステップ５０７）。一または複数のＲＩＡが接続される場合、サーバはＲＩＡに好適な表現へとデータを変換し（ステップ５０８）、そのデータを接続された各ＲＩＡに送信する（ステップ５０９）。ＲＩＡが接続されない場合、サーバはデータソースからデータを収集し続ける（ステップ５０３）。サーバは無期限にこのシーケンスを繰り返す（ステップ５０１〜ステップ５０９）。データシンクがデータソースからデータを必要とするサーバに接続されていないとき、サーバはそのデータソースからデータを収集しないように選択し得る。

データソースからデータを収集することと同時に、またはインターリーブして、サーバはＲＩＡからの接続も管理する。サーバはＲＩＡからの接続を待つ（ステップ５２０）。ＲＩＡがサーバとの接続を試みるとき（ステップ５２１）、サーバは接続を受入れ（ステップ５２２）、他のＲＩＡからの接続を待ち続ける。ＲＩＡとの接続を待つ間に、サーバは既存のＲＩＡ接続が切れているかを特定しなければならない（ステップ５２３）。ＲＩＡが切れている場合、ＲＩＡ接続はサーバにおける追跡から解除され（ステップ５２４）、それにより、接続が切れたＲＩＡにはその後データを送信するための試みはなされない（ステップ５０９）。サーバは、このシーケンスを無期限に繰り返す（ステップ５２０〜ステップ５２４）。サーバは、認証失敗またはサーバがＲＩＡインスタンスからの同時接続の最大数に限定を加えるなど、何らかの理由でサーバが接続を拒否し得るように、ＲＩＡが接続を試みる（ステップ５２２）ときに、承認基準を適用し得る。

データソースからデータを収集すること、ＲＩＡからの新規接続を管理することと同時に、またはインターリーブして、サーバはまた、既に接続されたＲＩＡからデータを受信し得る。サーバはＲＩＡから届くまでデータを待つ（ステップ５３０）。新規データが届くと（ステップ５３１）サーバはこのデータをサーバの内部のデータフォーマットに変換する（ステップ５３２）。次いでサーバは、いずれかのＲＩＡが現在接続されているかを特定する（ステップ５３３）。次いでサーバは、データＲＩＡが受信するのに好適なフォーマットにデータを変換し（ステップ５３４）、現在接続されている各ＲＩＡにデータを送信する（ステップ５３５）。次いでサーバは、この情報の変更を必要とするいずれかのデータソースが現在接続されているかを判断する（ステップ５３６）。現在サーバに接続されている情報を必要とする各データソースのため、サーバはそのデータソースに好適なフォーマットにデータを変換し（ステップ５３７）、データを送信する（ステップ５３８）。サーバはこのシーケンスを無期限に繰り返す（ステップ５３０〜ステップ５３８）

ステップ５０１〜ステップ５０９は、サーバが接続し得る各データソースに対し、繰り返し反復することができる。

ステップ５２０〜ステップ５２４は、サーバが接続を受信し得る各ＲＩＡに対し、繰り返し反復することができる。

ステップ５３０〜ステップ５３８は、接続された各ＲＩＡに対し反復され得るか、ステップ５３０は接続された全てのＲＩＡを同時に待つように多重に行われるか、またはこれらの選択肢を組み合わせて行われ得る。

図４および図５で例示した方法は、ＲＩＡおよびデータサーバの両方に対する明確な停止条件、サーバに接続するためデータソースを受動的に待つサーバの能力、ＲＩＡに積極的に接続するサーバの能力、複数のデータソースへの接続を同時に管理するサーバの能力、複数のＲＩＡへの接続を同時に管理するサーバの能力、および複数のＲＩＡからデータを同時に受信するサーバの能力を含む追加の能力を備えるように改良され得ることが理解される。

図６を参照すると、一実施形態において、複数のＲＩＡ６０１への接続を同時に管理するデータサーバ６０３の能力によると、有利にＲＩＡ６０１はサーバを介して別のＲＩＡ６０１と通信することが可能となる。ＲＩＡ６０１からサーバ６０３に送信される任意の情報は、ＲＩＡ６０１がデータソースのように扱われ、サーバに接続されており、データに参加している他の任意のＲＩＡ６０１にそのデータを伝搬する。驚くべきことに、これにより実時間で互いに更新するＲＩＡのネットワークを効果的に作り出す。実際に、サーバ６０３は、サーバがサポートするプロトコルの任意の組み合わせを使用して、任意の数のクライアント・アプリケーション間で通信することができるように使用され得る。

図７を参照すると、一実施形態では、本発明の実質的な利益は、そうでなければネットワークを介してアクセスできないソースが発信元であるデータをＲＩＡ７０１に提示する能力である。この実施形態では、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌのような表計算アプリケーション７０５を基にしたデータは、本発明の前は可能ではなかったローカルまたは広域ネットワークを介して送信され得る。Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌからのデータ送信は、ＤＤＥ、ＲＴＤまたは不安定なスクリプトを用いたアドホック通信に限定される。ＲＩＡとの実時間通信を可能とするＤＤＥ、ＲＴＤまたはスクリプトを通じたアドホック通信を含む、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌから供給されるプロトコルはＲＩＡと実時間で通信できない。本発明によれば、任意のアプリケーションが任意のＴＣＰ／ＩＰネットワークを用いて表計算データと実時間で通信することが可能となり、表計算データ用アプリケーションの範囲が広大に拡大する。ＲＩＡ７０１とのこの通信能力の組み合わせは、単一のウェブブラウザ接続を介した単一の表計算と複数の同時ユーザが相互接続する能力を提供する。この同一の機能性は、サーバ７０３がサポートする任意のプロトコルにまで拡張する。

ウェブブラウザ内でＲＩＡを実行する場合、ＲＩＡは、ウェブサーバを使用してウェブブラウザに提供されなければならない。すなわち、ユーザは、ウェブブラウザにＵＲＬを入力するか、またはそのＵＲＬのためにウェブページ内のリンクをクリックしてＲＩＡを含むウェブページをウェブブラウザにロードさせる。ＵＲＬは、Ｍｉｃｒｏｓｏｆｔ ＩＩＳ（商標）またはＡｐａｃｈｅ（商標）などのウェブサーバによりサービスが提供されている。よって、ＲＩＡをロードおよび接続するイベントのシーケンスは以下の通り。
１．ユーザがウェブブラウザでＵＲＬを選択する
２．ウェブブラウザがウェブサーバからＲＩＡを含むページをロードする
３．ウェブブラウザがＲＩＡを開始する
４．ＲＩＡがＴＣＰ／ＩＰを介してデータサーバと接続する
５．ＲＩＡがデータサーバのデータに参加する
６．データサーバが参加に従ってデータを送信する
７．ＲＩＡが接続を絶つかまたは停止するまでデータサービスが続く

このシーケンスには、ウェブサーバが存在し、ＲＩＡに配信するように構成されていることが必要である。システムコンポーネントの数を縮小し、ＲＩＡのデータ機能とウェブの機能とを一層強く一体化するため、データサーバにウェブサーバの能力を組み込むことが便利であろう。

組み込まれたブラウザまたは別個の非ブラウザホスト（ＲＩＡ用ブラウザ外モードと呼ぶ場合もある）から実行されてＲＩＡセッションを起動し得ることが当業者には容易に明らかになるであろう。ＵＲＬおよびウェブブラウザは、ユーザにとって明らかではない場合がある。従って、上述したイベントの最初の３つのステップが変更されてこれらの代替の実施形態を反映し得る。

本発明では、ＲＩＡはデータを使用または生成することができるＲＩＡフレームワークを使用して記載された任意のアプリケーションであり得る。

一実施形態では、ＲＩディスプレイはユーザにとって視覚的な実時間データである。視覚コンポーネントは、ゲージ、傾向グラフ、プログレスバー、ボタン、画像、及びデスクトップのアプリケーションで一般的な他の視覚表現であり得る。可能性として多種多様な表現が存在するため、特定のデータセットに最も好適な表現は、別のデータセットに最も好適な表現と異なり、ＲＩＡは、ユーザが設定可能とすべきである。これは、ユーザがデータを視覚「オブジェクト」と関連付けることが可能な視覚構成ツールとともに提示されることを意味する。これらの視覚オブジェクトの収集は共に、関連情報を表示するために共通して使用される視覚「ページ」に配置することができる。次いで、ユーザは、異なる一式の関連情報を表示するために複数のページを作成することができる。

データの視覚化をカスタマイズさせる能力をユーザに提供するために、ＲＩＡは、エディタとして一層共通して参照される、一体化したカスタム機能、または別々になったカスタム機能のいずれかを提供しなければならない。このエディタは、ユーザが実時間データを表示するページの視覚的なデザインを特定する手段を提供する。また、エディタは、視覚オブジェクトの特殊なバージョンを設計する能力も提供し得る。

個々の視覚オブジェクトのデザイン、視覚ページのデザインに関する情報は、ウェブサーバに格納されるべきである。これにより、ユーザは、ウェブサーバで必要なアクセス特権を用いて他の任意のユーザが閲覧できるデータの視覚化を作り出すことが可能となる。ＲＩＡは、ウェブサーバと相互作用して文書を格納し、 ＸＭＬなどのフォーマットで格納された文書を回収する。この情報通信は、既存の実時間データ接続を用いるか、またはＨＴＴＰ接続を使用して行われ得る。データサーバ内に内蔵されたウェブサーバは、必要ではないがこの送信の実施を簡易にする。

本発明の一実施形態では、本発明の方法を実装するシステムは、以下のソフトウェアアプリケーションを含む。
１．データサーバとして機能するＣｏｇｅｎｔ ＤａｔａＨｕｂ（商標）（Ｃｏｇｅｎｔ Ｒｅａｌ−Ｔｉｍｅ Ｓｙｓｔｅｍｓ Ｉｎｃ．）
２．ウェブサーバとして機能するＣｏｇｅｎｔ ＤａｔａＨｕｂ（Ｃｏｇｅｎｔ Ｒｅａｌ−Ｔｉｍｅ Ｓｙｓｔｅｍｓ Ｉｎｃ．）
３．ＲＩＡフレームワークとして機能するＭｉｃｒｏｓｏｆｔ Ｓｉｌｖｅｒｌｉｇｈｔ（マイクロソフト株式会社）
４．Ｍｉｃｒｏｓｏｆｔ Ｓｉｌｖｅｒｌｉｇｈｔのためのプロトコル実装層として機能するＤａｔａＨｕｂ ＡＰＩ ｆｏｒ ．Ｎｅｔ（Ｃｏｇｅｎｔ Ｒｅａｌ−Ｔｉｍｅ Ｓｙｓｔｅｍｓ Ｉｎｃ．）
５．ウェブブラウザに実時間データを表示するためのＲＩＡとして機能するＤａｔａＨｕｂ ＷｅｂＶｉｅｗ（商標）（Ｃｏｇｅｎｔ Ｒｅａｌ−Ｔｉｍｅ Ｓｙｓｔｅｍｓ Ｉｎｃ．）
６．視覚オブジェクトおよびページ設計のためのディスプレイ・エディタとして機能するＤａｔａＨｕｂ ＷｅｂＶｉｅｗ（Ｃｏｇｅｎｔ Ｒｅａｌ−Ｔｉｍｅ Ｓｙｓｔｅｍｓ Ｉｎｃ．）

加えて、Ｃｏｇｅｎｔ ＤａｔａＨｕｂは以下を含む様々なデータソースからデータを送信または受信し得る。
１．表計算アプリケーションとして機能するＭｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ（商標）（マイクロソフト株式会社）
２．データ通信インターフェースとして機能するＯＰＣ−ＤＡサーバ（各社）
３．データ通信インターフェースとして機能するＯＰＣ−ＵＡサーバ（各社）
４．データ通信インターフェースとして機能するＯＰＣ Ｘｉサーバ（各社）
５．データベースインターフェースとして機能するＯＤＢＣサーバ（各社）

図８を参照すると、一実施形態では、特定の実装に応じて、０以上のデータソースがＣｏｇｅｎｔ ＤａｔａＨｕｂに配置される。

本発明の代替的な実施形態では、ＲＩＡフレームワークは、持続したネットワーク接続をサポートすることが可能な任意のＲＩＡフレームワークであり得る。そのような代替的なＲＩＡフレームワークの例は、Ａｄｏｂｅ Ｆｌａｓｈ（商標）、およびＡｄｏｂｅ Ｆｌｅｘ（商標）を含む。他のＲＩＡフレームワークもまた好適であり得ることが想定される。

ＲＩＡは、サーバのＴＣＰ／ＩＰ通信プロトコルを使用してデータを消費または生成することができるＲＩＡフレームワークを使用して作成された任意のアプリケーションであり得る。

ＲＩＡフレームワークは、例えば、ＨＴＭＬ５が必要とされるＴＣＰ通信メカニズムをサポートしている場合など、ウェブブラウザに不可欠なものであり得る。

データサーバは、構築されたＲＩＡがアクセスできるＴＣＰ／ＩＰ通信方法を供給できる限り、データソースからデータを収集、またはデータソース自体として機能するように設計された任意のアプリケーションであってよい。

データソースは、サーバにおける表示に好適なフォーマットに変換できる実時間データを生成することが可能な任意のアプリケーションまたはシステムであり得る。

また、データソースは、サーバにおける表示に好適なフォーマットに変換できる非実時間データを生成することが可能な任意のアプリケーションまたはシステムであり得る。サーバは、発信元のデータが実時間でない場合でもＲＩＡにデータを提供するために、前記データを繰り返しポーリングするか、または参加により収集することができる。例えば、データベース管理システム（ＤＢＭＳ）は、一般的に実時間でなくても、データは繰り返してポーリングしてサーバ内で定期的に更新データを生成し、ＤＢＭＳにおける疑似的な実時間のデータ図をＲＩＡに供給することができる。

サーバおよびデータソースは、単一のアプリケーションに組み合わされ得、その場合、ＴＣＰ／ＩＰ接続を介してそのデータへのアクセスを提供するＯＰＣ−ＵＡサーバ、または内蔵された装置であり得る。

ウェブサーバは、ＲＩＡを含むウェブページを提供することができる任意のアプリケーションであり得る。

ＴＣＰ／ＩＰソケットを開き、相互に作用することができるコンパイルまたは解釈された任意のコンピュータ言語を使用して開発されたプログラムは、ウェブブラウザ内で実行または実行しないＲＩＡの代わりに使用され得る。同様に、本発明の方法はまた、ＲＩＡの代わりに、ブラウザ、ブラウザ以外のホストで直接またはブラウザの拡張を通じて実行可能なコードを使用して実施され得、ブラウザ、ブラウザ外のホスト、またはブラウザの拡張は開くことができ、ＴＣＰ／ＩＰソケットと相互に作用することができ、持続したネットワーク接続することができ、任意にグラフィック能力を提供することができる。

Claims (21)

1. リッチインターネットアプリケーション（ＲＩＡ）に実時間データを提供するコンピュータ実装方法であって、前記方法は、コンピュータに、
   データの発信元であるデータソースからデータを提供することと、
   前記データソースからサーバにデータを伝搬することと、
   前記サーバでデータを収集することであって、前記サーバで収集されたデータは、少なくとも前記データソースから伝搬されたデータを含むことと、
   前記サーバから前記ＲＩＡへの第１持続接続を作り出すことと、
   登録されたデータに前記ＲＩＡを登録することであって、前記登録されたデータは、前記サーバで収集されたデータの少なくとも一部を含み、前記サーバは、前記データソースで前記データに変更が生じる際に、前記第１持続接続を介して前記登録されたデータを前記ＲＩＡに伝搬することと、
   前記ＲＩＡでデータを生成することと、
   前記ＲＩＡから前記サーバへの第２持続接続を作り出すことと、
   前記第２持続接続を介して前記ＲＩＡから前記サーバに、前記ＲＩＡで生成されたデータを伝搬することと、
   前記サーバに命令して、前記ＲＩＡでのデータ項目の変化に対応するアクションを遂行させることと、
   を実行させることを含む、方法。
2. 前記第１持続接続および前記第２持続接続は１つの接続から成る、請求項１に記載の方法。
3. 前記データソースおよび前記サーバは、少なくとも１つのコンポーネントから成る、請求項１または２に記載の方法。
4. 前記データは、少なくとも１つの媒介物を介して伝搬され、前記媒介物は、ソフトウェアコンポーネント、ハードウェアコンポーネント、およびネットワークを含む群から選択される、請求項１乃至３のいずれか一項に記載の方法。
5. 前記データ項目が登録に基づいて前記ＲＩＡと前記サーバとの間で伝搬され、前記データ項目は前記データ項目の変化に応じて直ちに伝搬される、請求項１乃至４のいずれか一項に記載の方法。
6. 伝搬されるデータは、数値データ、非数値データ、構成設定および実行可能コマンドを含む群から選択される、請求項１乃至５のいずれか一項に記載の方法。
7. 前記ＲＩＡは、前記データに基づいてアクションを行い、前記アクションは、ユーザディスプレイの視覚表示の変更、計算、新規データの生成、既存データの変更、データの格納、可聴表示、スクリプトの実行、新規データの前記サーバへの伝搬、ユーザ可視なプログラミングの応答、およびユーザ不可視なプログラミングの応答を含む群から選択される、請求項１乃至６のいずれか一項に記載の方法。
8. 前記ＲＩＡで生成されたデータは、前記サーバ内のデータの変更、前記サーバに接続されたデータシンクへの前記データの伝搬、スクリプトの実行、ファイルシステムへの前記データの格納、新規データの作成、前記サーバに接続されたデータシンクへの新規データの伝搬、サーバ構成の変更、サーバ動作の変更、ユーザ可視なプログラミングの応答、およびユーザ不可視なプログラミングの応答を含む群から選択されるアクションを行うよう前記サーバに指示する、請求項１乃至７のいずれか一項に記載の方法。
9. 前記第１持続接続は、ＴＣＰ／ＩＰ接続および前記サーバによりサポートされた少なくとも１つのデータフォーマットを実装するアプリケーション・プログラミング・インターフェース、直接のＴＣＰ／ＩＰ接続、ＨＴＴＰおよびＨＴＴＰＳを含む群から選択されるプロトコルを含む、請求項１乃至８のいずれか一項に記載の方法。
10. 前記ＲＩＡで生成されたデータは、ユーザの相互作用、タイマーイベント、前記サーバに由来するデータ変更への応答、またはユーザにより生成されない別のイベントの結果として生成される、請求項１乃至９のいずれか一項に記載の方法。
11. 前記方法は、前記コンピュータに、前記データソースのデータプロトコルを、前記ＲＩＡにより処理することができるプロトコルに変換することを実行させることをさらに含む、請求項１乃至１０のいずれか一項に記載の方法。
12. リッチインターネットアプリケーション（ＲＩＡ）に実時間データを提供するためのコンピュータシステムであって、前記システムは、
    プロセッサと、
    入力手段と、
    ディスプレイと、
    データの発信元である少なくとも１つのデータソースであって、前記データソースは、前記データソースからサーバへ前記データを伝搬するように配置される、データソースと、
    データを収集するためのデータ収集コンポーネント、および少なくとも１つのデータクライアントにデータを放出するためのデータ放出コンポーネントを備える少なくとも１つのサーバであって、前記サーバで収集されたデータは、少なくとも前記少なくとも１つのデータソースから伝搬されたデータを含む、サーバと、
    少なくとも１つのＲＩＡであって、前記ＲＩＡは、
    前記サーバから前記ＲＩＡへの第１持続接続を作り出すことと、
    前記サーバで収集されたデータの少なくとも一部を含む登録されたデータに前記ＲＩＡを登録することと、
    前記データソースで前記データに変更が生じる際に、前記第１持続接続を介して前記サーバから伝搬される登録されたデータを受信することと、
    データを生成することと、
    前記ＲＩＡから前記サーバへの第２持続接続を作り出すことと、
    前記第２持続接続を介して前記サーバに、前記ＲＩＡで生成されたデータを伝搬することと、
    前記サーバに命令して、前記ＲＩＡでのデータ項目の変化に対応するアクションを遂行させることと、
    を行うように構成され、
    前記少なくとも１つのＲＩＡは、前記少なくとも１つのデータクライアントのうち１つである、ＲＩＡと、
    を備える、システム。
13. 前記少なくとも１つのサーバが、前記データ放出コンポーネントによる放出のために前記データ収集コンポーネントにより収集されたデータのフォームを変更するためのデータ変更コンポーネントをさらに備える、請求項１２に記載のシステム。
14. 前記少なくとも１つのサーバが、前記データ放出コンポーネントによる放出のために前記データ収集コンポーネントにより収集されたデータのフォームを変更するためのデータ変更コンポーネントと、ユーザインターフェースと、プログラム可能なアクションを行うためのスクリプト言語コンポーネントと、ＨＴＴＰリクエストを受入れるためのＨＴＴＰコンポーネントと、任意のローカルまたはネットワークでアクセス可能なコンピュータ上で前記サーバの別の実行中のインスタンスとデータを交換および同期させるための同期コンポーネントと、データが収集される速度を限定するための第１調整コンポーネントと、データが放出される速度を限定するための第２調整コンポーネントと、他のサーバへの接続性が失われたことを検出し、接続性が再び取り戻される場合に前記他のサーバに再接続するための接続性コンポーネントと、同一または類似する情報の複数の他のサーバのうち１つ以上がアクセス不能である場合に前記他のサーバのうちいずれかからのデータを収集するために、前記他のサーバと重複して接続する重複コンポーネントと、複数のデータソースにあるデータを移動させるための橋渡し用コンポーネントとから成る群から選択される少なくとも１つのコンポーネントをさらに備える、請求項１２または１３に記載のシステム。
15. 前記第１持続接続は、ＴＣＰ／ＩＰ接続および前記サーバによりサポートされた少なくとも１つのデータフォーマットを実装するアプリケーション・プログラミング・インターフェース、直接のＴＣＰ／ＩＰ接続、ＨＴＴＰおよびＨＴＴＰＳを含む群から選択されるプロトコルを含む、請求項１２乃至１４のいずれか一項に記載のシステム。
16. 前記第１持続接続および前記第２持続接続は１つの接続から成る、請求項１２乃至１５のいずれか一項に記載のシステム。
17. 前記ＲＩＡは、前記データを表現するグラフィック描写を提示するようにさらに構成され、前記グラフィック描写は少なくとも１つのグラフィック要素を含み、前記少なくとも１つのグラフィック要素はカスタム化されたグラフィック要素であり、前記カスタム化されたグラフィック要素はプログラマによりカスタマイズ可能であり、前記カスタム化は前記ＲＩＡに実装されたアプリケーションに対する変更を伴わない、請求項１２乃至１６のいずれか一項に記載のシステム。
18. 前記ＲＩＡは、ユーザの相互作用、タイマーイベント、前記サーバに由来するデータ変更への応答、またはユーザにより生成されない別のイベントの結果としてデータを生成するように構成される、請求項１２乃至１７のいずれか一項に記載のシステム。
19. 前記ＲＩＡが、前記データソースのデータプロトコルを、前記ＲＩＡにより処理することができるプロトコルに変換するようにさらに構成される、請求項１２乃至１８のいずれか一項に記載のシステム。
20. １つ以上のコンピュータで実行される場合に、リッチインターネットアプリケーション（ＲＩＡ）に実時間データを提供する方法を前記コンピュータに行わせる指示を記憶するコンピュータ読み取り可能な記憶媒体であって、前記方法は、
    データの発信元であるデータソースからデータを提供することと、
    前記データソースからサーバにデータを伝搬することと、
    前記サーバでデータを収集することであって、前記サーバで収集されたデータは、少なくとも前記データソースから伝搬されたデータを含むことと、
    前記サーバから前記ＲＩＡへの第１持続接続を作り出すことと、
    登録されたデータに前記ＲＩＡを登録することであって、前記登録されたデータは、前記サーバで収集されたデータの少なくとも一部を含み、前記サーバは、前記データソースで前記データに変更が生じる際に、前記第１持続接続を介して前記登録されたデータを前記ＲＩＡに伝搬することと、
    前記ＲＩＡでデータを生成することと、
    前記ＲＩＡから前記サーバへの第２持続接続を作り出すことと、
    前記第２持続接続を介して前記ＲＩＡから前記サーバに、前記ＲＩＡで生成されたデータを伝搬することと、
    前記サーバに命令して、前記ＲＩＡでのデータ項目の変化に対応するアクションを遂行させることと、
    を含む、記憶媒体。
21. 前記方法が、前記データソースのデータプロトコルを、前記ＲＩＡにより処理することができるプロトコルに変換することをさらに含む、請求項２０に記載の記憶媒体。

Images