(57)【特許請求の範囲】
【請求項１】
安全なネットワーク接続を提供する方法であって、前記方法が、
サーバにおいて、前記サーバに対するインバウンド接続要求を前記サーバと第１クライアントとの間のネットワーク上でリッスンすることと、
前記サーバにおいて、前記第１クライアントから第１インバウンド接続要求を受信することと、
前記第１インバウンド接続要求から、前記サーバと前記第１クライアントとの間に第１ネットワーク接続を確立することと、
前記サーバにおいて、前記第１ネットワーク接続を通して前記第１クライアントから第１データセットを受信することであって、前記第１クライアントが、前記第１データセットの信頼できるソースであり、かつ全てのインバウンド接続要求によりアクセス不可能であることと、
前記サーバにおいて、前記ネットワーク上の第２クライアントから第２インバウンド接続要求を受信することと、
前記第２インバウンド接続要求から、前記サーバと前記第２クライアントとの間に第２ネットワーク接続を確立することと、
前記第１データセットを、前記第２ネットワーク接続を通して前記サーバから前記第２クライアントに伝搬することであって、前記サーバが、前記第２クライアントに関して前記第１データセットの信頼できるソースであることと、
前記サーバにおいて、第１データサブセットを前記第２クライアントから受信することであって、前記第１データサブセットが、前記第２クライアントによる前記第１データセットのサブセットに対する修正であることと、
前記第１データサブセットを前記サーバから前記第１クライアントに伝搬することと、
を含む、方法。
【請求項２】
前記サーバにおいて、第２データセットを前記第２クライアントから受信することであって、前記第２クライアントが前記第２データセットの信頼できるソースであること
をさらに含む、請求項１に記載の方法。
【請求項３】
前記サーバを介して、前記第１データセットおよび前記第２クライアントからの第２データセットのうちの少なくとも１つを、前記第１クライアントへ前記第１ネットワーク接続および前記第２ネットワーク接続を通して伝搬すること
をさらに含む、請求項２に記載の方法。
【請求項４】
安全なネットワーク接続を提供する方法であって、前記方法が、
第１クライアントによりネットワーク上のサーバに、第１インバウンド接続要求を送信することと、
前記第１インバウンド接続要求から、前記サーバと前記第１クライアントとの間に第１ネットワーク接続を確立することと、
前記第１クライアントにより前記サーバに、前記第１ネットワーク接続を通して第１データセットを送信することであって、前記第１クライアントが、前記第１データセットの信頼できるソースであり、かつ全てのインバウンド接続要求によりアクセス不可能であることと、
前記ネットワーク上の第２クライアントにより前記サーバに、第２インバウンド接続要求を送信することと、
前記第２インバウンド接続要求から、前記サーバと前記第２クライアントとの間に第２ネットワーク接続を確立することと、
前記第２クライアントにおいて、前記第１データセットを前記サーバから前記第２ネットワーク接続を通して受信することであって、前記サーバが、前記第２クライアントに関して前記第１データセットの信頼できるソースであることと、
を含む、方法。
【請求項５】
前記第１クライアントにより、第１データサブセットを前記サーバから受信することであって、前記第１データサブセットが、第２クライアントにより生成され、かつ前記第２クライアントにより前記サーバに送信されており、前記第１データサブセットが、前記第１データセットのサブセットに対する修正であり、前記サーバが、前記第２クライアントに関して前記第１データセットの信頼できるソースであること
をさらに含む、請求項４に記載の方法。
【請求項６】
安全なネットワーク接続を提供する方法であって、前記方法が、
第１クライアントによりネットワーク上のサーバに、第１インバウンド接続要求を送信することと、
前記第１インバウンド接続要求から、前記サーバと前記第１クライアントとの間に第１ネットワーク接続を確立することと、
前記第１クライアントにより前記サーバに、前記第１ネットワーク接続を通して第１データセットを送信することであって、前記第１クライアントが、前記第１データセットの信頼できるソースであり、かつ全てのインバウンド接続要求によりアクセス不可能であることと、
前記第１クライアントにより、第１データサブセットを前記サーバから受信することであって、前記第１データサブセットが、第２クライアントにより生成され、かつ前記第２クライアントにより前記サーバに送信されており、前記第１データサブセットが、前記第１データセットのサブセットに対する修正であり、前記サーバが、前記第２クライアントに関して前記第１データセットの信頼できるソースであることと、
を含む、方法。
【請求項７】
前記第１クライアントにおいて、前記第１データサブセットを受け入れるかまたは拒絶するかを判断することと、
前記第１クライアントが前記第１データサブセットを受け入れるときに、前記サーバが前記第１データサブセットを前記第１データセットに挿入することと、
をさらに含む、請求項１、２、３、５および６のいずれか１項に記載の方法。
【請求項８】
前記第２クライアントにより前記サーバに、第２データセットを送信することであって、前記第２クライアントが、前記第２データセットの信頼できるソースであること
をさらに含む、請求項４乃至７のいずれか１項に記載の方法。
【請求項９】
前記第１クライアントにより、前記第１データセットおよび前記第２クライアントからの第２データセットのうちの少なくとも１つを、前記第１ネットワーク接続および前記第２ネットワーク接続を通して受信すること
をさらに含む、請求項１および４のいずれか１項に記載の方法。
【請求項１０】
前記第２クライアントが、全てのインバウンド接続要求によりアクセス不可能である、請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記第２クライアントが、第２サーバ、および（ｉ）前記ネットワーク上の１つ以上の二次エンドユーザ装置に関して前記第１データセットの信頼できるソース、（ｉｉ）前記ネットワーク上の１つ以上の二次エンドユーザ装置に関して前記第２データセットの信頼できるソース、または（ｉ）および（ｉｉ）の組合せとして機能する、請求項２、３、８および９のいずれか１項に記載の方法。
【請求項１２】
前記第２クライアントが、（ｉ）前記第１クライアント、（ｉｉ）または前記ネットワーク上の１つ以上の二次エンドユーザ装置、または（ｉ）および（ｉｉ）の組合せに対するデータサーバとして機能する、請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記第２クライアントが、同時に、前記第１クライアントまたは前記ネットワーク上の１つ以上の二次エンドユーザ装置に対するデータの信頼できるソース、および、前記第１クライアントまたは前記ネットワーク上の１つ以上の二次エンドユーザ装置に対する信頼できないサーバである、請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
システムであって、
１つ以上のプロセッサと、
前記１つ以上のプロセッサに結合されたコンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体がその上に格納された命令を含み、前記命令が、前記１つ以上のプロセッサにより実行されるときに、前記１つ以上のプロセッサに請求項１乃至１３のいずれか１項に記載の方法を行わせる、コンピュータ可読記憶媒体と、
を備える、システム。
【請求項１５】
１つ以上のプロセッサに請求項１乃至１３のいずれか１項に記載の方法を行わせるための命令の１つ以上のシーケンスをその上に格納している非一時的なコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２０１５年６月１８日に出願された米国非仮出願第１４／７４３，６６６号に対する優先権を主張し、それは、２０１４年１１月１４日に出願された米国非仮出願第１４／５４２，４２７号の継続であり、それは、２０１４年７月１０日に出願された米国仮出願第６２／０２３，１７２号および２０１４年８月１０日に出願された米国仮出願第６２／０３５，４７３号に対する優先権を主張し、それらの内容が参照により本明細書に組み込まれる。
【０００２】
著作権の告知
本特許文献の開示の一部分は、著作権保護を対象とする資料を含む。著作権者は、特許商標庁の特許出願または記録に見られる特許文献、または特許開示物による複製物に異存はないが、その他の点では、何であれ全ての著作権を保有する。
【背景技術】
【０００３】
実時間データとは、データが最初に作成された後、一定時間内に処理および／または送信されるべき任意のデジタル情報またはアナログ情報を指す。データが作成された時から処理および／または送信されるまでに経過した時間は、待ち時間として知られている。任意の特定の実時間アプリケーションにとって可能な最大の待ち時間は、アプリケーションに依存する。最大待ち時間が厳しい要件であるアプリケーションは、「ハードな」実時間アプリケーションと呼ぶことができ、最大待ち時間が厳しい要件でないアプリケーションは、「ソフトな」実時間アプリケーションと呼ぶことができる。ソフトな実時間アプリケーションは、時に主観的なアプリケーション依存を満たし、一定の「十分な速さ」を満たすことだけが必要である。非実時間データは、特定の待ち時間要求に何ら応じる必要がないデータである。
【０００４】
「データ」とういう用語は、ハードな実時間、ソフトな実時間、または非実時間データを指し得る。「実時間データ」は、ハードな実時間データまたはソフトな実時間データを指し得る。
【０００５】
実時間データは、典型的に、物理的処理またはデータを処理するコンピュータシステムの外部のコンピュータプログラムに起因して作成される。例えば、実時間データは、モータの状態、流体タンクのレベル、バルブの位置、コンベヤの速度などのような産業プロセスの制御システムに由来する情報と、例えば株のような金融商品用の価格、容量と、ユーザがコンピュータディスプレイでボタンをクリックしたことを示すようなユーザインターフェースにおけるイベントと、ヒトであるオペレータによるデータ入力と、コンピュータ・オペレーティングシステムの状態変化とを含み得る。徐々に変化する視覚的な何らかの情報は、実時間データとして扱うことができる。
【０００６】
データの発信元は、「データソース」と記載され得る。例えば、データは、物理的処理として発信元となり、電気的に計算され、デジタル表現に変換され得るか、またはデータは、デジタル表現の発信元となり得る。一般的に、データはデジタル表現としてデジタルコンピュータで利用可能に作成され、続く零以上のステップがデータをデジタル表現に変換する。データソースは、コンピュータプログラムによりアクセス可能なデジタルの状態にデータを変換するために必要な全てのコンポーネントおよび工程を含み得る。
【０００７】
データソースの類似物は「データシンク」である。データシンクは、データを消費または使用する。幾つかのデータシンクの例は、処理制御システムにおけるアクチュエータ、株式取引システムにおける株式取引ソフトウェア、ユーザインターフェース用アプリケーション、データベースまたは他のデータ・ストレージシステムが挙げられる。
【０００８】
多くのデータソースは、データシンクでもある。従って、データソースは、データソース、データシンク、または同時に両方を含み得る。例えば、データがデータソースに送信される場合、データソースもデータシンクとして働き得る。
【０００９】
コンピュータ・アプリケーションでは、データは通常「サーバ」に管理される。サーバは、データソース、データシンクのいずれか、または両方として働くことができ、「クライアント」アプリケーションは、サーバが管理するデータと相互に作用することが可能となる。
【００１０】
一般的に、クライアント・アプリケーションは、データと相互に作用するためにサーバとの接続を開始しなければならない。この接続は、データとの一または僅かな相互作用の間のみ接続する「一時的」、またはデータと多く相互作用するために接続を持続させ、クライアント・アプリケーションの存続期間のために接続可能な「永続的」が存在し得る。永続的な接続は、「持続」接続とも呼ばれる。
【００１１】
データソースは、データのデジタル表現を定義する一または複数の「データフォーマット」でデータを提供する。データフォーマットは、発行された基本的なデータソースに一致し得るか、またはデータソースに特定的であり得る。同様に、データシンクは、発行された基本フォーマットのデータまたはデータシンクに特定的なフォーマットのデータを必要とし得る。
【００１２】
データソースは、一または複数の「通信プロトコル」を介してデータへのアクセスを提供する。通信プロトコルは、データがデータソースからデータシンクに転送されるメカニズムを特定する。通信プロトコルは、基本的なデータソースに一致し得るか、またはデータソースに特異的であり得る。データソースは、サポートされていないデータフォーマットが、全てサポートされた通信プロトコルを介して送信されるようにデータフォーマットと通信プロトコルとを組み合わせ得る。一般的に「プロトコル」または「データプロトコル」とは、特定の通信プロトコルを介して送信された特定のデータフォーマットの組み合わせを指す。
【００１３】
データシンクは、データソースにより生成されたデータを使用するために、データソースにより提供された少なくとも１つのデータプロトコルをサポートしなければならない。データプロトコルは多大に存在するため、全てのデータソースおよびデータシンクについて全てのデータプロトコルをサポートすることは実用的ではない。結果、データを使用するクライアント・アプリケーションは、通常、主要な目的のために一番必要なプロトコルだけをサポートするように作成される。同様に、データソースも一般的に主要な目的に必要なプトコルのみをサポートする。従って、例えば、ＨＴＴＰプロトコルをサポートするウェブブラウザをＤＤＥプロトコルをサポートする表計算アプリケーションに直接接続させる方法はない。
【００１４】
データシンクにデータソースにより提供されるデータを使用させるために、プロトコルの変換工程が行われて、データソースによってサポートされているプロトコルからデータシンクにサポートされているプロトコルにデータを変換しなければならない。この変換工程は、「ミドルウェア」アプリケーションにより行うことができる。ミドルウェア・アプリケーションの主な目的は、通常はデータソースとデータシンクとが共通してプロトコルを共有する場合は間接的に相互作用できるように、１つのプロトコルから別のプロトコルにデータを変換することによってデータソースとデータシンクとの通信を促すことであり得る。
【００１５】
データソースは、少なくとも２つの方法を使用してデータをデータシンクに転送し得る。
１．オンデマンド。データソースは、データソースで利用可能なデータの一部または全てを要求するデータシンクを受動的に待つ。データシンクがデータを要求した場合は、ソースが要求されたデータの現在の状態を示す結果を用いて応答する。データシンクがデータ変更を知らされる必要があるならば、データシンクはデータソースが更新されたデータを用いて応答するために、データシンクは要求を繰り返さなければならない。データシンクによる同一データに対する繰り返し要求は「ポーリング」として知られている。データシンクは、新しい要求毎にデータソースへの一時的な接続を作り出し得るか、または繰り返し要求が送信される間にわたり持続的な接続を作り出し得る。
２．登録による方法。データシンクはデータソースへの持続的な接続を作り出し、データソースから利用可能な一部または全てのデータを登録する。データソースは、持続的な接続を介して変更が生じるとデータに対する何らかの変化を送信する。データソースは、データシンクが他に特定するかまたは接続が終わるまでデータに対する変化を送信し続ける。
【００１６】
共有メモリ、メッセージ・キュー、およびメールボックスのようなデータ転送方法は、要求または同意方法のいずれかのバリエーションであることが理解される。データ転送、データ伝搬、またはデータ通信という用語は全て、システム内のデータの移動を指し、これらの用語は、特定のデータ通信方法に関連するように、互換可能に使用され得ることもさらに理解される。これらの方法は、通信プロトコルに基づいて独立している。
【００１７】
実時間データを扱うコンピュータ・アプリケーションは、信頼があり、反応がよく、データソースに簡単に接続されなければならない。これは、実時間データ処理アプリケーションが、歴史的に、直接的または間接的にデータソースに接続される単独型のアプリケーションとして作成されてきたことを意味する。この単独型のアーキテクチャは、アプリケーションにコンピュータのグラフィック能力を最大限に利用することも可能とし、実時間データの高等で動的な視覚化を提供する。反対に、ウェブブラウザ技術に基づいたアプリケーションは、データ接続およびグラフィック速度の観点から不適当なことが証明されている。ＨＴＴＰプロトコルは、各要求／応答ペアが、ウェブサーバへの新しいソケットをオープンして、通信を行い、次いでソケットをシャットダウンするようウェブクライアント（通常はウェブブラウザ）に要求する要求／応答通信方法として意図されている。このパラダイムは、まれにしか起こらず、特別に時間依存でない通信に対してはうまく機能する。ＨＴＴＰプロトコルはさらに、トランザクションのタイプを、ウェブサーバからのデータ取得またはウェブサーバへのデータ送信に制限するが、同じトランザクションでは両方を制限しない。このモデルに基づくＡＪＡＸなどの手法は、比較的少ないトランザクションを作成すると予期されていて、より高速へスケーリングする傾向は非常に乏しい。各トランザクションに対して接続を確立してクローズする計算コストおよびネットワークコストは、かかるシステムの速度に対する制限として機能する。
【００１８】
従って、ウェブブラウザにおける表示だけでなく、広範な実時間データ処理は、利用できなかった。ウェブブラウザでＡｃｔｉｖｅＸコンポーネントを使用してデータ駆動型表示にアクセスする試みを行う開発者もいたが、しかしこれらのコンポーネントは、一般的に現代のブラウザではサポート性が乏しく、これらのコンポーネントが示すセキュリティの危険性に起因して限定が課される。
【００１９】
内蔵されたブラウザのＪａｖａｓｃｒｉｐｔエンジンを使用して、ウェブブラウザにおいて変化するデータを表示する試みが成されてきた。これは、一般的に、ＡＪＡＸ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｊａｖａｓｃｒｉｐｔ  ａｎｄ  ＸＭＬ）と呼ばれる手法を用いて実現され、ウェブブラウザは新しいデータを定期的にポーリングし、次いでこれに応じてディスプレイを更新する。このポーリングメカニズムは非常に非効率的であり、比較的少量のデータセットまたは比較的移動が遅いデータにのみ好適である。ＣＰＵまたはネットワークのバンド幅を浪費させないためにポーリングの割合を低減させることは、実時間アプリケーションを受けられないデータの待ち時間が増えることに対し効果がある。
【００２０】
ストリーミングＡＪＡＸと呼ばれるメカニズムを介してＡＪＡＸを改善する試みは、ブラウザのページをロードするメカニズムの副作用を利用してＪａｖａｓｃｒｉｐｔコマンドを徐々にページに対して追加することによりブラウザのページを増加的に拡大させる。Ｊａｖａｓｃｒｉｐｔコマンドの各々は、連続的なデータの流れといった印象を与えながらコマンドが立ち上がると実行する。ウェブブラウザは、事実上、ネットワーク接続が遅い間に極めて大量のウェブページを負担しているものと思い込む。この方法は、ウェブブラウザのメモリやＣＰＵの使用が、送信されるこれまでにない大量のページに起因して続けて徐々に増えていく事実を含め、幾つかの障害を持つ。このような特別に設計されたウェブサーバから複数の非同期メッセージを収集するためにＨＴＴＰ接続をオープンにしたままにすると、事実上、一時的なＨＴＴＰ接続を永続するストリーミング接続にする。これは、新しいデータがサーバから非同期に送信でき、クライアントが各新しいメッセージに対して接続をオープンしてクローズすることを要求しないため、サーバからクライアントへのはるかに速い更新を可能にする。しかし、クライアントからサーバへの通信を加速するのには役立たない。事実上、それは、サーバからクライアントへの高速な一方向チャネルを作成するが、クライアントからサーバへ伝達する際にはＨＴＴＰの負の性能特性を依然として保持する。
【００２１】
ＡＪＡＸもストリーミングＡＪＡＸの方法もウェブブラウザ内のディスプレイ選択肢という品質の欠損を被る。ウェブブラウザは、一般的に静止ページおよびウェブ「フォーム」のディスプレイ用に設計されており、高速または高品質なグラフィックの提示という選択肢を提供しない。グラフィカルなディスプレイという選択肢に対する改善のための試みは、ブラウザ間では両立しない虜があり、一般的に非常に実行が遅い。
【００２２】
内蔵されたウェブブラウザの能力に基づいて全てのデータを送信する解決法は、ウェブブラウザでデータを受信することを最初に標的とする。データ通信は、一方向であり、また、サーバからデータを受信する接続は、サーバにデータを送信するために使用することもできない。サーバにデータを再送信する必要がある場合は、新たに接続を開き、ＨＴＴＰリクエストを送信し、次いで再び接続を閉じなければならない。従って、ストリーミングＡＪＡＸのような解決法は、膨大なオーバーヘッドとデータ送信の毎に新しいＨＴＴＰリクエストを発行しなければならないことにより被る待ち時間とにより、データサーバにデータを送信するのが非常に遅い。
【００２３】
速いかのように見えるが遅く移動する（待ち時間が長い）データを提示することによりユーザ体験を改善しようというウェブベースのデータ視覚化に対する試みが成されている。これは、実際に到着するデータよりも高い頻度でウェブブラウザに補完データを表示することにより実現される。速度計を意味する環状ゲージは、５秒毎に分離された１〜１００の値を受信する。次に、ウェブページは、各回に４回値を変えながら１秒間にゲージダイヤルを５回取り出す。これにより、根本的なデータ伝達はそのような情報を含まないが、視聴者に滑らかに速度が変化する印象を与える。すなわち、そのような補間データの表示は、もっぱら視聴者を惑わせる場合がある。こうした種類の補間は根本的なデータの実際の動作を曖昧にし、通常、プロセス制御および株式市場の取引のような実時間アプリケーションでは許容できない。
【００２４】
Ａｄｏｂｅ  Ｆｌａｓｈ（商標）およびＭｉｃｒｏｓｏｆｔ  Ｓｉｌｖｅｒｌｉｇｈｔ（商標）のようなリッチインターネットアプリケーション（「ＲＩＡ」）フレームワークは、ウェブブラウザにおけるデータ処理およびグラフィック描写の両方について改善されたプラットフォームを提供する。これらのＲＩＡフレームワークはまた、ＲＩＡ内での直接的なＴＣＰ／ＩＰ通信をサポートする。驚くべきことに、これらの特徴を組み合わせることにより、ウェブブラウザでの実時間情報を処理および表示することが可能となる。この処理・表示能力は、ＲＩＡが主にビデオ、宣伝、およびゲームに好適であるというソフトウェア産業における認識に起因して、実時間データシステムに移転されてこなかった。
【００２５】
ＨＴＴＰに対する一般的な代替手段は、高速データ用の二次通信ソケットをＨＴＴＰ通信チャネルと並行して提供することである。事実上、ウェブクライアントは、提示情報のためにＨＴＴＰを経由して、および、高速の双方向データ通信のために別個の専用ソケットを経由して、通信する。これは、速度の問題を解決するが、他の問題をもたらす。
【００２６】
別個の通信ソケットは、別個のＴＣＰポートをサーバ上でオープンすることを必要とする。これは、企業ファイアウォールにおける別の開口部を意味し、ＩＴ部門は一般にそれに抵抗する。
【００２７】
ＦｌａｓｈまたはＳｉｌｖｅｒｌｉｇｈｔなどのリッチインターネットアプリケーション（ＲＩＡ）フレームワークは、一般に、アクセスポリシーサーバとして機能するために、さらに別の周知のポートをオープンする必要のあるソケット通信に制限を実装する。これは、企業ファイアウォールにおけるさらなる開口部をもたらし、本技術の有用性をさらに制限する。
【００２８】
ブラウザ内で動作するＲＩＡフレームワーク（例えば、Ｓｌｉｖｅｒｌｉｇｈｔ）は、それ自身のＳＳＬ層を実装せず、代わりに、暗号化のためのブラウザのＨＴＴＰＳ実装に依存し得る。かかる場合、ＲＩＡによって実装される専用ソケットは安全ではないだろう。
【００２９】
専用ソケットは、ウェブプロキシを通過できない。
【００３０】
インターネットを経由した高速または実時間データ処理が出現すると、永続する高速ソケット通信に対する必要性が生じた。この必要性によりＲＩＡ実装者はかかるソケットを提供せざるを得なくなったが、前述した制限があった。ウェブサーバへの、ＨＴＴＰまたは、より好ましくは、ＨＴＴＰＳを経由した永続する双方向ソケット通信に対する満たされていない必要性が残っている。
【００３１】
ＨＴＭＬ５仕様は、ＷｅｂＳｏｃｋｅｔと呼ばれるドラフト仕様を含む。これは、ＨＴＴＰを介したソケットを使用して、クライアントとサーバとの間に双方向の通信を提供しようとする。ＷｅｂＳｏｃｋｅｔは現時点では、広くサポートされていないが、それらは、順方向および逆方向ウェブプロキシを通じて双方向接続の作成の可能性を提供する。本発明は、ＷｅｂＳｏｃｋｅｔを通じた実時間データ接続を可能にして、データソースまたはエンドユーザがプロキシサーバを経由してインターネットから分離されていて、任意のＴＣＰ／ＩＰポートを経由して接続を作成できない場合でさえ良好な接続を提供する。これは、クライアントネットワーク上に追加の潜在的なレベルのセキュリティを可能にしながら、本発明が有用に実装され得るネットワークトポロジのセットを大幅に広げる。
【００３２】
本発明は、増大する産業用の監視制御とデータ収集（「ＳＣＡＤＡ」）システムに適している。ＳＣＡＤＡシステムは、センサーおよび他の装置などのデータ収集ハードウェア、通信ネットワーク、中央処理システム、ならびにプラントオペレータおよびエンジニアが彼らの産業プロセス内のデータを実時間で見るのを可能にするディスプレイ装置を含む。ＳＣＡＤＡシステムは、多くの場合、新しいレシピのキャンディ製造機へのアップロード、風力タービンに関するグローバル設定の変更、またはボイラーに対する高圧アラームの確認応答などの、調整および制御の監視レベルをサポートするインターフェースを含む。
【００３３】
ＳＣＡＤＡシステムは、長期間にわたって進化してきた。第１世代システムは、「モノリシック」であり、個々のコンピュータ上で動作して、フィールド装置に直接接続した。第２世代は、ローカルエリアネットワーク（「ＬＡＮ」）を介して相互に通信し、専用制御ネットワークを経由してフィールド装置と通信する、複数のコンピュータを使用して、「分散」処理を可能にした。現在の「ネットワーク化された」世代は、パーソナルコンピュータならびにＴＣＰ／ＩＰなどのオープン標準およびローカルエリアネットワーキングに対するオープンプロトコルを使用する。このように、今では、かかる機能の広範な採用を制限しているセキュリティに関する根本的な問題があるが、ＳＣＡＤＡシステムおよびデータにインターネットからアクセスすることが可能である。
【００３４】
ネットワーク化したＳＣＡＤＡシステムは、クライアント／サーバモデルを使用して設計される。サーバ（装置またはソフトウェアアプリケーション）は、データ項目の集合を含む。これらのデータ項目は、クライアント（装置またはソフトウェアアプリケーション）によって要求されると、そのクライアントに対して利用可能になる。暗黙の了解は、サーバはデータ値の信頼できるソース（ａｕｔｈｏｒｉｔａｔｉｖｅ  ｓｏｕｒｃｅ）であり、それがどのデータ値を供給するかの先験的知識を有するということである。クライアントは信頼できないソースであり、サーバに問い合わせることによりどのデータ項目を使用し得るかを決定する。明確にするために、データの信頼できるソースは、それがどのデータ項目を含み、そのクライアントに対して利用可能にするかを決定する責任を負い、信頼できるソース内で保持されるデータ値は正確で最新であると推定される。クライアントはどのデータ項目が存在するかを判断できず、サーバ内で定義されたデータ項目の値および／またはプロパティに作用し得るだけである。
【００３５】
重要なことには、サーバは同時に、信頼できるデータソースであり、クライアントからの入接続に対するリスナーでもある。ネットワーク化したシステムでは、これは、データを使用する任意のクライアントは、サーバへの接続を開始することが可能でなければならないことを意味する。ＳＣＡＤＡシステムでは、これは、例えば、（クライアントとして機能する）オペレータワークステーションは、ＳＣＡＤＡサーバに接続することが可能でなければならないことを意味するであろう。これは、その結果として、ＳＣＡＤＡサーバは、クライアントの位置からネットワークを経由して到達可能であることを必要とする。インターネットベースまたはクラウドベースのシステムの場合、これは、ＳＣＡＤＡサーバはインターネットから到達可能でなければならないことを意味して、許容できないセキュリティリスクをもたらす。明確にするために、用語「クラウド」および「インターネット」は、本開示全体にわたって区別しないで使用され得る。
【００３６】
プロセス制御エンジニアの間でクラウドコンピューティングが話題に上る場合、セキュリティに関する多くのもっともな懸念がある。ＳＣＡＤＡならびに他の製造および制御システムは多くの場合、高価格の製造ラインをサポートし、そこでは妨害または不正行為が数千または数百万ドルの損害を与え得る。最近、いくつかの作業現場で、プロセスデータを会社の残りの人々に対して企業ＬＡＮ上で利用可能にすることを始めたが、インターネットからの入接続を可能にするためにプラントファイアウォールにポートをオープンすることに対する強い抵抗がある。
【００３７】
他方、クラウドシステムは一般に、通常ウェブブラウザＨＭＩ（「ヒューマンマシンインターフェース」）もしくはＲＩＡまたはプロセス側のサーバに接続するための他の種類のクライアントを使用して、インターネットアクセスを必要とする。本発明まで、これは、ウェブブラウザを接続可能にするために工場ファイアウォールにポートをオープンする必要があったことを意味した。そして、これは、ほとんどのプラントエンジニアが進んで冒そうとしないセキュリティリスクである。セキュリティエクスプロイトの主な源は、インバウンド接続を許可するファイアウォールである。これらが除去されない限り、プラントは攻撃にさらされる。
【００３８】
ＳＣＡＤＡシステムのミッションクリティカルな特質に起因して、産業プロセスに対して責任があるエンジニアおよびマネージャは、それらを直接インターネットに公開するのを嫌がり、侵入者およびハッカーを寄せ付けないために安全なファイアウォールの背後で実行する。問題を悪化させているのが、最もインストールされている産業システムのアーキテクチャが、インターネットを考慮して開発されなかったことである。産業ユーザの懸念事項に適切に対処するために、データネットワーキングに対する根本的に異なるアプローチが必要である。本発明は、実時間データの産業ユーザの厳密な要件を満たすセキュリティに対する新規のアプローチを採用することにより、この問題を解決する。
【発明の概要】
【００３９】
本発明は、ウェブブラウザで少ない待ち時間の実時間データアプリケーションを提供するために、少なくとも１つの実時間データサーバと協働する、ウェブブラウザ、ＲＩＡフレームワークおよび専用アプリケーションなどのネットワーククライアントのグラフィック特性およびネットワーク特性を使用するためのシステムおよび方法を提供する。本発明は、データソースのデータがウェブブラウザ内で使用できないデータソースを同時に扱いながら、現在のＡＪＡＸおよびストリーミングＡＪＡＸの限定を克服する。
【００４０】
本発明は、既存のブラウザおよびＲＩＡ技術と共に動作可能であると同時に、ＨＴＴＰまたはＨＴＴＰＳを通じて、好ましくは既存のＨＴＴＰ動詞（例えば、ＧＥＴおよびＰＯＳＴ）を使用して、完全に実行され得るウェブクライアントからの永続する双方向通信メカニズムも提供する。本開示を通して、用語「ＲＩＡ」、「リッチインターネットアプリケーション」、「ウェブブラウザ」、「ネットワーククライアント」および「クライアント」は、ＨＴＴＰまたはＨＴＴＰＳプロトコルを用いて通信する任意のソフトウェアまたはハードウェアアプリケーションを区別しないで指すと理解される。
【００４１】
本発明は、インターネットを経由した実時間データを可能にする安全なエンドツーエンドデータサービスのためのシステムおよび方法も提供する。本発明は、センサー、装置、および機械、ならびにインターネットに接続されている任意の遠隔位置からのそれらのデータのユーザの間の実時間接続性を、毎秒２５，０００を超えるデータ変更、好ましくは、毎秒５０，０００を超えるデータ変更、より好ましくは、毎秒７５，０００を超えるデータ変更、最も好ましくは、毎秒１００，０００を超えるデータ変更であり得るデータスループット率で提供する。インターネット自体を介した接続の待ち時間を超える、データストリームの追加の待ち時間は、ミリ秒単位で測定され得、好ましくは２００ミリ秒未満、より好ましくは１００ミリ秒未満、さらにより好ましくは５０ミリ秒未満、さらにより好ましくは２５ミリ秒未満、さらにより好ましくは１０ミリ秒未満、最も好ましくは５ミリ秒未満であり得る。本発明は、産業システム、組込み機器、「スマート」デバイスまたは金融システムからの実時間データで作業する人にとって特に有益である。
【００４２】
本発明は、最先端の技術により、あるポイントまでのデータ待ち時間を縮小することでウェブブラウザおよびネットワーククライアントへの実時間データの送達を改善し、視覚化コンポーネントは、補間値ではなく実際のデータ値を使用して活発化できる。これにより、データの一時的な動作がユーザに対して一層正確に提示される。一時的なデータの動作は、通常、そのデータにより提示される実際の動的な実時間システムの理解に重要である。例えば、物理的ゲージを観察する者は、ゲージ針の動作に振動またはオーバーシュートを観察することにより重要なシステムの特性を判別することができる。本発明の一実施形態では、物理的ゲージのデジタル表現は針の原動力を捕獲し、物理的ゲージとして同じように高品質の情報を提供することができる。
【００４３】
本発明は、ＣＰＵおよびネットワークのコストを抑え、待ち時間を低減させながら、ユーザからデータサーバへのデータ送信の速度を大幅に改善する。これにより、ユーザは、システムの反応が現在の動作に重要な、一層高機能な制御シナリオに参加することが可能となる。例えば、システムは、容器に水を注ぐ間に、相互作用を維持および解除するための相互作用を必要とし得る。ユーザはボタンを押し、容器が満タンになるまで維持し、次いでボタンを離す。システムが、容器から溢れないように迅速に応答しなければならないことは明白である。この種の制御は、データ伝達の待ち時間が予測できないことに起因して、典型的なウェブベース・アプリケーションでは実行できない。驚くべきことに、本発明は、以前は遅すぎ、信頼性がなく、またはウェブブラウザを通して検討されるには原始的であったこの種の制御および実時間データアプリケーションを可能にする。
【００４４】
典型的なウェブアプリケーションは、アプリケーション設計者による特異的なフォーマットで提供されるデータを扱う。これは、エンドユーザの選択を限定する意図的な方法であり得、または単に設計に対する限定であり得る。データフォーマットが（ＸＭＬまたはＪＳＯＮなどの）業界基準に従っている場合でも、データソースはアプリケーションに特異的である。本発明はまた、業界基準および所有者のソースの両方を発信元とする多種多様な実時間データを送達するための汎用的なメカニズムも提供する。有利に、本発明はさらに、種々のデータフォーマットでそのデータを提供することができる。
【００４５】
多くのデータソース、実時間および非実時間は、ネットワークの使用（すなわち、ネットワークを通した送信）を意図しない。本発明によれば、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌ（商標）（マイクロソフト株式会社）のようなデータソースからのデータをネットワークを通して任意のＲＩＡまたはウェブベース・アプリケーションに確実かつ迅速に送達することが可能となる。ＯＰＣに基づいたデータソースのようなデータソースは、ネットワークの使用を意図するものであったが、ウェブブラウザと通信するようには設計されていない。本発明によれば、ウェブベース・アプリケーションに確実かつ迅速にこれらのソースを送達することが可能となる。データベース・システムのような他のデータソースは、実時間情報について全くインターフェースを提供していない。本発明によれば、データベース・アプリケーショのようなソースからの非実時間データを実時間データのように送達することが可能となり、それにより、ＲＩＡまたはウェブベース・アプリケーションのために非効率的なデータベースのポーリングの必要性を排除する。
【００４６】
データソースおよびデータシンクは、持続的な接続または一時的な接続によりサーバと接続し得る。サーバに接続する方法は、特定のデータソースまたはデータシンクの要求を反映させることが理解される。
【００４７】
本発明は、一または複数のデータソースからの実時間データがリッチインターネットアプリケーションで効率的に利用できる方法を提供する。本発明はさらに、ＲＩＡが、効率的に実時間データに変更するか、またはソースデータ（単数または複数）に再び送信することができる新規の実時間データを生成するための方法を提供する。ソースデータ（単数または複数）は、ネットワーク上の他のＲＩＡにそのデータを再送信することができる。従って、本発明によれば、効率的に任意の数のＲＩＡアプリケーションが実時間で別のＲＩＡアプリケーションと通信し、一つまたは多くの実時間データソースと協働して通信することが可能となる。抽出することにより提示可能な任意のデータが発信元のソース、提示、または転送プロトコルの有無に関わらずＲＩＡで利用できるように、本発明は実時間データの抽出が可能である。
【００４８】
本発明は、接続されたデータソースおよびクライアント（例えば、産業施設、エンドユーザクライアント装置）のためにオープンした着信ファイアウォールポートを必要としないインターネットまたはクラウドベースの通信フレームワークおよびサービスのためのシステムおよび方法を提供し、それにより、潜在的な攻撃にさらすのを除外する。本発明は、プラントとクラウドサーバとの間のクライアント／サーバ関係を逆転することによりこの新規の改善を提供する。サーバとして機能するプラントデータソースの代わりに、本発明では、プラントデータソースがクライアントとして機能し、クラウドサービスがサーバとして機能する。これは、インターネットと接続が行われる方法の方向を逆にする。プラントデータソースサーバは、アウトバウンド接続要求をクラウド内のサーバに送信し、従って、プラントファイアウォールにインバウンドポートをオープンする必要がない。この新規のアプローチは、プラントファイアウォールを閉じたままにして、潜在的な攻撃表面をゼロまで縮小する。
【００４９】
本発明より前には、認識された必要性がなく、直観的にすることもアーキテクチャ的意義もなかったので、クライアント／サーバ関係の逆転は行われなかった。既存のＳＣＡＤＡおよび制御システム、ならびにＯＰＣなどの標準産業プロトコルは、サーバがデータセットの信頼できる所有者であると期待する。データはプロセスで生成され、次いで、他の場所で使用されているので、データの消費者（例えば、外部ユーザ）がクライアントであること、およびクライアントがプロセス、サーバからデータを要求することは必然である。クライアントは、当然ながらサーバに接続して、データセットを問い合わせ、クライアントが要求するデータに登録すると期待される。この従来技法は、既存のプロトコルが設計されたクローズドシステム内では十分にうまくいく。しかし、クラウドベースシステムは根本的に新しいアプローチを必要とする。
【００５０】
クライアントとサーバの役割を変更することにより、本発明は、クライアントがデータセットの信頼できる所有者になる独特で新規の事例を提供する。クライアントとして機能する、プロセスは、クラウドサーバに接続し、そのサーバをその現在のデータセットで構成する。データセットに対する更新情報が後に、プロセスからクラウドサーバに渡される。他方、データのユーザ（クライアント）は、同様の方法でクラウドサーバに接続する。クライアントは、クラウドサーバにアウトバウンドクライアント接続も行い、実時間でデータセットとやりとりできる。クライアント側でも同様に、着信ファイアウォールポートをオープンする必要がない。このように機能することにより、本発明は、プラントファイアウォールまたはクライアントのファイアウォールに１つの着信ポートもオープンすることなく、クラウドサーバがプロセスデータへのアクセスを提供できるようにする。
【００５１】
本発明は、クライアント／サーバ関係を逆転する。すなわち、クライアント・アプリケーションは任意選択で信頼できるデータソースとして機能でき、サーバはそのデータの信頼できない消費者として機能できる。実際には、本発明は、信頼できるサーバ、信頼できるクライアント、信頼できないサーバおよび信頼できないクライアントとして同時に機能するための単一のアプリケーションを提供する。これは、サーバアプリケーションを、信頼できないサーバとして機能しているパブリックにアクセス可能なクラウドコンピュータ上に置き、安全なネットワーク内のＳＣＡＤＡシステムを信頼できるクライアントとして構成することを可能にする。ＳＣＡＤＡシステムは、安全なＳＣＡＤＡネットワーク内からクラウドサーバへのアウトバウンド接続を行い、クラウドサーバにそのデータセットを投入する。クラウドサーバはそのデータセットの先験的知識を必要とせず、代わりに、そのデータセットをＳＣＡＤＡシステム内の信頼できるクライアントから学習する。ＳＣＡＤＡシステムのデータにアクセスする必要のある公衆ネットワーク上の他のクライアントは、クラウドサーバに信頼できないクライアントとして接続し、このようにして、クラウドサーバを、実際にはＳＣＡＤＡシステムから出ているデータに対する信頼できるサーバとして扱う。従って、クライアント・アプリケーションは、クラウドシステムに接続し、あたかもそれがＳＣＡＤＡシステムに接続しているかのようにＳＣＡＤＡシステムのデータとやり取りすることが可能であるが、ＳＣＡＤＡシステムは公衆ネットワークに決して公開されていない。本発明の予期しない結果は、ＳＣＡＤＡシステム自体のネットワークセキュリティ問題を生じることなく、ＳＣＡＤＡシステムのデータへの遠隔アクセスを提供することである。
【００５２】
追加のセキュリティのために、本発明は、ＳＣＡＤＡシステムへの信頼できないサーバとして、かつクラウドシステムへの信頼できるクライアントとして機能する、アプリケーションの第２インスタンスが、産業プラント内部の別個のネットワーク内にインストールされるのを可能にして、この第２インスタンスが安全なＳＣＡＤＡネットワークにアクセスできないようにする。ＳＣＡＤＡシステムは次いで、データをこの第２インスタンスに放出し、この第２インスタンスはそのデータをクラウドサーバに放出する。この構成では、ＳＣＡＤＡシステムは、インターネットへの直接アウトバウンド接続さえ有していないが、代わりに、第２インスタンスを含むネットワークによってさらに分離される。
【００５３】
ＳＣＡＤＡシステムは一般に、（オペレータパネルのような）クライアント・アプリケーションが値変化をあるデータ項目に放出できるようにするためのメカニズムを提供する。例えば、オペレータは、プラント内のマシンを起動または停止することを望み得る。プラント所有者は、ＳＣＡＤＡデータを遠隔位置から修正したがらない場合がある。本発明は、ユーザ許可が通常はそれを許可する場合でさえ、（クラウドへの信頼できるクライアントとして機能する）ＳＣＡＤＡシステムが、データ項目の値を修正しようとする全ての試行を拒否できるようにする。加えて、クラウドサーバは、あるユーザが、彼らのユーザ認証情報および彼らが接続しているコンピュータのＩＰアドレスに基づき、あるデータ項目の値を修正できるように構成できる。従って、本発明は、クラウドサーバがセキュリティ侵害されている場合でさえ、公衆ネットワークを経由した攻撃およびデータを修正しようとする権限のない試行の両方からセキュリティを提供する。
【００５４】
別の実施形態では、安全なネットワーク接続を提供する方法が、サーバにおいて、そのサーバとクライアントとの間のネットワーク上でそのサーバへのインバウンド接続要求をリッスンすること、サーバにおいてクライアントからの第１インバウンド接続要求を受信すること、その第１インバウンド接続要求からサーバとクライアントとの間に第１ネットワーク接続を確立すること、およびサーバにおいてその第１ネットワーク接続を通じてクライアントから第１データセットを受信することによって実行され、クライアントは第１データセットの信頼できるソースであり、インバウンド接続要求を経由してアクセスできない。
【００５５】
別の実施形態では、安全なデータネットワークを提供するためのシステムが提供される。本システムは、サーバとクライアントとの間のネットワークに通信可能に接続されたサーバを含み、サーバは：インバウンド接続要求をリッスンし、サーバによって受信した第１インバウンド接続要求に基づきサーバとクライアントとの間に第１データ接続を確立し、第１データ接続を経由してクライアントから第１データセットを受信するように動作可能であり、第１データセットは信頼できるソースによって生成される。クライアントはインバウンド接続要求を経由してアクセス不能であり、クライアントは信頼できるソースである。
【００５６】
本説明はＳＣＡＤＡシステムへの適用に言及しているが、この同じメカニズムが公衆ネットワークを経由して利用可能にされ得る任意のデータに対して広く適用可能であることが理解されるはずである。そのデータは、任意のプログラムまたはプロセス、例えば、金融取引システム、家庭の電力量計、遠隔機械類、携帯電話、組込み機器など、またはデータを生成する任意の他のプログラムもしくは装置から出ているかも知れないが、依然として本発明の範囲内である。本発明の一態様では、共通の要件は、データソースは、そのデータをそのデータのユーザに対して利用可能にするために、インバウンドネットワーク接続を受け入れる必要がないということである。
【図面の簡単な説明】
【００５７】
【図１】本発明の一実施形態に係る、ＲＩＡとデータサーバとの間の直接接続を示す例示的なブロック図である。
【図２】本発明の一実施形態に係る、ＲＩＡと、サーバと、別離したデータソースとの間の接続を示す例示的なブロック図である。
【図３】本発明の一実施形態に係る、複数のＲＩＡと、サーバと、複数の別離したデータソースとの間の接続を示す例示的なブロック図である。
【図４】本発明の一実施形態に係る、ＲＩＡの制御フローの一方法を示すフローチャートである。
【図５ａ】本発明の一実施形態に係る、サーバ操作の一方法を示す例示的なフローチャートである。
【図５ｂ】本発明の一実施形態に係る、サーバ操作の一方法を示す例示的なフローチャートである。
【図６】本発明の一実施形態に係る、複数のＲＩＡへの同時接続を管理するデータサーバを示す例示的なブロック図である。
【図７】本発明の一実施形態に係る、表計算アプリケーションとＲＩＡとの間のローカルネットワークまたは広域ネットワークを介したデータの実時間通信を示す例示的なブロック図である。
【図８】本発明の一実施形態に係る、システムの実施を示す例示的なブロック図である。
【図９ａ】本発明の一実施形態に係る、クライアントおよびサーバの操作の一方法を示す例示的なフローチャートである。
【図９ｂ】本発明の一実施形態に係る、クライアントおよびサーバの操作の一方法を示す例示的なフローチャートである。
【図９ｃ】本発明の一実施形態に係る、クライアントおよびサーバの操作の一方法を示す例示的なフローチャートである。
【図１０】従来技術のシステム実装を示す例示的なブロック図である。
【図１１】本発明の一実施形態に係る、システム実装を示す例示的なブロック図である。
【図１２】本発明の一実施形態に係る、システム実装を示す例示的なブロック図である。
【発明を実施するための形態】
【００５８】
以下の記載は、どの当業者も本発明を成すことができ、使用できるように提示され、本発明の特定のアプリケーションを背景として提供される。開示される実施形態に対する種々の変更が当業者には容易に明らかとなり、本明細書で定義される一般原則は、本発明の範囲から逸脱することなく他の実施形態およびアプリケーションに適用され得る。種々の実施形態および実施例に対する言及は、本発明の範囲を限定せず、本明細書に添付した請求の範囲によってのみ限定される。従って、本明細書で説明する例のどれもが限定されることを意図しておらず、主張する本発明について、可能性のある多くの実施形態のうちの幾つかを説明するにすぎない。
【００５９】
本発明の実施形態が実行されるプログラム環境には、例示的に、汎用コンピュータ、または携帯用コンピュータ、携帯電話もしくはＰＬＣのような特殊目的の装置が組み込まれる。そのような装置（例えば、プロセッサ、メモリ、データストレージ、ディスプレイ）の詳細は、明瞭さのために省略され得る。
【００６０】
本発明の技術は、種々の技術を使用することにより実装され得ることも理解される。例えば、本明細書に記載される方法は、コンピュータシステムで実行されるソフトウェアに実装されるか、またはマイクロプロセッサ、もしくは他の特別に設計されたアプリケーションに特異的な集積回路、プログラム可能な倫理装置のいずれかの組み合わせもしくは種々の組み合わせを用いてハードウェアに実装され得る。詳細には、本明細書に記載される方法は、コンピュータで読み取り可能な好適な媒体に存在する、コンピュータが実行可能な一連の命令により実施され得る。コンピュータで読み取り可能な好適な媒体は、揮発性（例えばＲＡＭ）および／または不揮発性（例えばＲＯＭ、ディスク）メモリ、搬送波、ならびに通信媒体（例えば、銅線、同軸ケーブル、光ファイバ媒体）を含み得る。例示的な搬送波は、ローカルネットワーク、インターネットまたは他の幾つかの通信リンクのような公的にアクセス可能なネットワークに従ってデジタルデータ・ストリームを搬送する電気信号、電磁信号、または光信号の形態を取り得る。
【００６１】
図面に示される例示の実施形態を参照すると、簡易化された例は明瞭さのために選択されたことが理解される。図面に見受けられる一つの構成要素における単一の例（例えば、ＲＩＡ、サーバ、クライアント、データソース、データシンクなど）は、複数の同じ構成要素と置換され得、それも本発明の範囲内に含まれる。
【００６２】
従って、一態様において、本発明は、ＲＩＡに実時間データを提供する方法を提供する。その方法は、データソースでデータを生成することと、サーバにデータを伝搬することと、サーバでデータを収集することと、ＲＩＡからサーバへの持続的な接続を作り出すことと、登録されたデータに前記ＲＩＡを登録させることとを含み、登録されたデータは、サーバで収集された少なくとも幾つかのデータを含み、サーバは、データがサーバで収集されるように持続的な接続を介して登録されたデータをＲＩＡに伝搬する。方法はさらに、ＲＩＡが発信元のデータをサーバに送信することを含み得る。ＲＩＡが発信元のデータは、持続的な接続を通したデータまたはサーバへの少なくとも１つのコマンドに対する少なくとも１つの変化リクエストを含み得る。さらにデータは、少なくとも１つの中間コンポーネントを介して伝搬され得る。サーバは、少なくとも１つの変化リクエストを受信し得、少なくとも１つの変化リクエストをデータソースに送信し得る。少なくとも１つの変化リクエストは、中間コンポーネントを介して伝達され得る。中間コンポーネントは、中間ハードウェアコンポーネントまたは中間ソフトウェアコンポーネントであり得る。任意に、ＲＩＡが登録されたデータに登録し得る。データソースでデータを生成し、そのデータをサーバに伝搬することは、サーバでデータを収集することとともに行われ得る。ＲＩＡは、計算またはグラフィック描写の変更など、データに基づいてアクションを遂行し得る。ＲＩＡは、ユーザディスプレイ上にデータの視覚表示を提供し、ユーザはＲＩＡが発信元のデータを生成するために視覚表示とやり取りし得る。視覚表示は、ＲＩＡフレームワーク内で実行するプログラムであり得る。ＲＩＡが発信元のデータは、サーバを停止させるか、またはどのデータがサーバから届いたのか変えるなど、その動作を変えるために、サーバに命令してアクションを遂行させ得る。
【００６３】
例えば、ＲＩＡが発信元のデータは、ユーザとの処理の結果、タイマーイベント、サーバに由来するデータへの応答、スクリプト、またはユーザではなく生成された別のイベントであり得る。
【００６４】
別の態様では、本発明は、実時間データをＲＩＡに提供する方法を提供する。前記方法は、データソースからデータを提供することと、データソースからサーバにデータソースを伝搬することと、サーバでデータを収集することと、ＲＩＡでデータを生成することと、サーバからＲＩＡへの第１持続接続を作り出すことと、ＲＩＡからサーバへの第２持続接続を作り出すことと、第２持続接続を介してＲＩＡからサーバにデータを伝搬することと、登録されたデータにＲＩＡを登録することとを含み、登録されたデータは、サーバで収集された少なくとも幾つかのデータを含み、サーバは、第１持続接続を介してＲＩＡに登録されたデータを伝搬する。方法はさらに、サーバからデータシンクにデータを伝搬することを含む。第１持続接続および第２持続的な接続は、単一接続から成り得る。データソース、データシンク、およびサーバは、単一のコンポーネントまたは２つ以上のコンポーネントの任意の組み合わせから成り得る。データは、ソフトウェアコンポーネント、ハードウェア、コンポーネント、およびネットワークを含む群から選択される少なくとも１つの中間物を介して伝搬され得る。
【００６５】
データ項目は、登録に基づいてＲＩＡとサーバとの間で伝搬され得、データ項目はデータ項目の変化に応じて直ぐに伝搬される。伝搬されたデータは、数値データ、非数値データ、構成設定、および実行コマンドを含む群から選択され得る。ＲＩＡは、データに基づいてアクションを遂行し得、該アクションは、ユーザディスプレイの視覚表示の変更、計算、新規データの生成、既存データの変更、データの格納、可聴表示、スクリプトの実行、サーバへのデータの伝搬、ユーザ可視なプログラミングの応答、ユーザ不可視なプログラミングの応答を含む群から選択される。ＲＩＡで生成されたデータは、サーバに命令して、サーバ内でのデータの変更、サーバに接続されたデータシンクへのデータの伝搬、スクリプトの実行、ファイルシステムへのデータの格納、新規データの作成、サーバに接続されたデータシンクへの新規データの伝搬、サーバ構成の変更、サーバ動作の変更、ユーザ可視なプログラミングの応答、およびユーザ不可視なプログラミングの応答を含む群から選択されるアクションを遂行させ得る。
【００６６】
さらに別の態様では、本発明は、上述したように、一または複数のコンピュータで実行される場合に、実時間データをＲＩＡに提供する方法をコンピュータに行わせる命令を記憶したコンピュータ読み取り可能な記憶媒体を提供する。
【００６７】
別の態様では、本発明は、ＲＩＡに実時間を提供するためのシステムを提供する。前記システムは、少なくとも１つのデータソースと、少なくとも１つのデータソースからデータを収集するためのデータ収集コンポーネント、および少なくとも１つのデータクライアントにデータを放出するためのデータ放出コンポーネントを備える少なくとも１つのサーバと、少なくとも１つのＲＩＡと、任意に少なくとも１つのデータシンクとを備える。サーバはさらに、データ放出コンポーネントにより放出するためにデータ収集コンポーネントにより収集されたデータの形態を変更するためのデータ変更コンポーネントを備え得る。少なくとも１つのデータソースと少なくとも１つのサーバは、少なくとも１つのコンピュータプログラム（すなわち、単一のコンピュータプログラム、または２つ以上の別箇のコンピュータプログラム）に実装され得ることが理解される。
【００６８】
サーバはさらに、データ変更コンポーネントと、データ生成コンポーネントと、ユーザインターフェース用コンポーネントと、コンピュータファイルシステム相互作用コンポーネントと、サーバで実行するコンピュータ上で実行する他のプログラムと相互作用するためのプログラム相互作用コンポーネントと、プログラム可能なアクションを行うためのスクリプト言語コンポーネントと、クライアントプログラムからＨＴＴＰリクエストを受け、それらリクエストに特定される文書を用いて、「ウェブサーバ」に類似する方法で応答するためのＨＴＴＰコンポーネントであって、前記リクエストに応じる文書を動的に構築し、サーバに在るデータの現在の値とサーバが内蔵するスクリプト言語で実行制御文の結果を文書内に含める能力を備えるＨＴＴＰコンポーネントと、任意のローカルまたはネットワークでアクセス可能なコンピュータで実行する別の一例のサーバとデータを交換または同期すし、両方のサーバがそのデータの基本的に同一の複製を維持することができ、それにより、いずれかの一例のサーバに接続されたクライアント・アプリケーションが相互に作用する 同じデータセットと相互作用することができる、同期コンポーネントと、データが収集される割合を限定するための第１調整コンポーネントと、データが放出される割合を限定するための第２調整コンポーネントと、他のサーバへの接続性の損失を検出し、接続性が取り戻せる場合は他のサーバに再接続する接続コンポーネントと、他のサーバからのデータが、一または複数の他のサーバがアクセスできないように同一または類似する情報を持つ複数の他のサーバと重複して接続する重複コンポーネントと、ソース内の幾つかまたは全てのデータが別のデータと類似する値を維持するようにデータソースのデータを橋絡するか、または１つのソースにあるデータが他のソースにあるデータの数学的変換として維持されるように橋絡するブリッジングコンポーネントであって、双方向のブリッジング操作を介して順方向にも逆方向にも数学的変換を適用する能力を備えるブリッジングコンポーネントと、から選択される一または複数のコンポーネントを備え得る。この一式のサーバコンポーネントは、他のデータの収集、ならびに通信メカニズム、他の処理メカニズム、および他の記憶メカニズムをサポートするために、サーバに追加機能を追加することにより拡張することができることが理解される。
【００６９】
データ収集コンポーネントは、一または複数の以下の方法でデータを収集し得る：
オンデマンドであって、サーバは、別のサーバに在る幾つかまたは全てのデータのためにリクエストを送信し、他のサーバはそのリクエストに応じて、リクエストされたデータの現在の値（単数または複数）を用いて一度だけ応答する、方法と、登録による方法であって、サーバは、別のサーバにある幾つかまたは全てのデータに対し登録のためのリクエストを送信し、他のサーバは、そのデータの現在の値（単数または複数）を送信することにより応答し、次いでサーバが他のサーバとの接続を終了するか、または他のサーバが更新の送信を中止することをリクエストするまで、データの値（単数または複数）に対する逐次的変化を送信し続ける方法と、
トリガによる方法であって、クライアント、スクリプトまたはヒト（ユーザ）が、あるトリガの状況が、タイマ、時刻、データ変化、システム状態の変化、ユーザアクション、または他の幾つかの検出可能なイベントを満たす場合にのみデータを収集するようにサーバを構成する方法と、
サーバにデータを送信するために「クライアント」アプリケーションを受動的に待つ方法。
【００７０】
データ放出コンポーネントは、一または複数の以下の方法でデータを放出し得る：
オンデマンドであって、「クライアント」アプリケーションは、幾つかまたは全てのデータに対してリクエストを送信し、サーバはリクエストに応じて、リクエストされたデータの現在の値（単数または複数）を用いて一度だけ応答する方法と、
登録による方法であって、クライアント・アプリケーションは、幾つかまたは全てのデータを登録するためのリクエストを送信し、サーバがデータの現在の値（単数または複数）を送信することにより応答し、次いでクライアントがサーバとの接続を終了するか、またはサーバが更新の送信を中止することをリクエストするまでデータの値（単数または複数）に対する逐次的変化を送信し続ける、方法と、
トリガによる方法であって、クライアント、スクリプト、またはヒト（ユーザ）が、あるトリガの条件がタイマ、時刻、データ変化、システム状態の変化、ユーザアクション、または他の幾つかの検出可能なイベントを満たす場合にのみデータを放出するようにサーバを構成する方法。
【００７１】
データ収集コンポーネントで収集されるデータは、Ｄｙｎａｍｉｃ  Ｄａｔａ  Ｅｘｃｈａｎｇｅ（ＤＤＥ）、ＯＬＥ  ｆｏｒ  Ｐｒｏｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＯＰＣ）、ＯＰＣアラームおよびイベント仕様（ＯＰＣ  Ａ＆Ｅ）、Ｕｎｉｆｉｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＯＰＣ−ＵＡ）、ＯＰＣ  Ｅｘｐｒｅｓｓ  インターフェース（ＯＰＣ−Ｘｉ）、ＴＣＰ／ＩＰ、カスタムインターフェースを介してＴＣＰ／ＩＰを渡るＳＳＬ（セキュア・ソケット・レイヤー）、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）、Ｓｅｃｕｒｅ  ＨＴＴＰ（ＨＴＴＰＳ）、オープン・データベース・コネクティビティ（ＯＤＢＣ）、Ｍｉｃｒｏｓｏｆｔ  Ｒｅａｌ−Ｔｉｍｅ  Ｄａｔａ  ｓｐｅｃｉｆｉｃａｔｉｏｎ  （ＲＴＤ）、メッセージ・キュー、Ｗｉｎｄｏｗｓ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｆｏｕｎｄａｔｉｏｎ  （ＷＣＦ）、ＰｒｏｆｉｂｕｓおよびＭｏｄｂｕｓなどの工業用バスのプロトコル、Ｗｉｎｄｏｗｓ  Ｓｙｓｔｅｍパフォーマンス・カウンタ、システムに組み込まれたＴＣＰ／ＩＰ通信、ＭＳ−Ｗｉｎｄｏｗｓではないシステムに由来するＴＣＰ／ＩＰ通信、Ｌｉｎｕｘ（登録商標）に由来するＴＣＰ／ＩＰ通信、ＱＮＸに由来するＴＣＰ／ＩＰ通信、ＴＲＯＮに由来するＴＣＰ／ＩＰ通信、ＣコンパイラおよびＴＣＰ実装を提供する任意のシステムに由来するＴＣＰ／ＩＰ通信、内蔵のスクリプト言語を使用して記載されたスクリプト、ユーザインターフェースを介してヒトが入力したデータ、ローカルディスクファイルから読み込まれたデータ、遠隔でアクセス可能なディスクファイルから読み込まれたデータ、所有者のフォーマット、ユーザが定義したフォーマット、ならびにサーバへの拡張を通じて追加されたフォーマットから選択される一または複数の通信プロトコルを使用して受信され得る。所有者のフォーマットの一例は、Ｗｏｎｄｅｒｗａｒｅ  ＳｕｉｔｅＬｉｎｋ（商標）である。
【００７２】
データ放出コンポーネントから放出されるデータは、Ｄｙｎａｍｉｃ  Ｄａｔａ  Ｅｘｃｈａｎｇｅ  （ＤＤＥ）、ＯＬＥ  ｆｏｒ  Ｐｒｏｃｅｓｓ  Ｃｏｎｔｒｏｌ  （ＯＰＣ）、ＯＰＣアラームおよびイベント仕様（ＯＰＣ  Ａ＆Ｅ）Ｕｎｉｆｉｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＯＰＣ−ＵＡ）、（ＯＰＣ−ＵＡ）、ＯＰＣ  Ｅｘｐｒｅｓｓ  インターフェース  （ＯＰＣ−Ｘｉ）、ＴＣＰ／ＩＰ、カスタムインターフェースを介してＴＣＰ／ＩＰを渡るＳＳＬ（セキュア・ソケット・レイヤー）、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）、Ｓｅｃｕｒｅ  ＨＴＴＰ（ＨＴＴＰＳ）、オープン・データベース・コネクティビティ（ＯＤＢＣ）、Ｍｉｃｒｏｓｏｆｔ  Ｒｅａｌ−Ｔｉｍｅ  Ｄａｔａ  ｓｐｅｃｉｆｉｃａｔｉｏｎ  （ＲＴＤ）、メッセージ・キュー、Ｗｉｎｄｏｗｓ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｆｏｕｎｄａｔｉｏｎ  （ＷＣＦ）、ＰｒｏｆｉｂｕｓおよびＭｏｄｂｕｓなどの工業用バスのプロトコル、Ｗｉｎｄｏｗｓ  Ｓｙｓｔｅｍパフォーマンス・カウンタ、システムに組み込まれたＴＣＰ／ＩＰ通信、ＭＳ−Ｗｉｎｄｏｗｓではないシステムに由来するＴＣＰ／ＩＰ通信、Ｌｉｎｕｘ（登録商標）に由来するＴＣＰ／ＩＰ通信、ＱＮＸに由来するＴＣＰ／ＩＰ通信、ＴＲＯＮに由来するＴＣＰ／ＩＰ通信、ＣコンパイラおよびＴＣＰ実装を提供する任意のシステムに由来するＴＣＰ／ＩＰ通信、内蔵のスクリプト言語を使用して記載されたスクリプト、ユーザインターフェースを介してヒトに提示されるデータ、ローカルディスクファイルから読み込まれたデータ、遠隔でアクセス可能なディスクファイルから読み込まれたデータ、所有者のフォーマット、ユーザが定義したフォーマット、サーバへの拡張を通じて追加されたフォーマット、電子メール（Ｅメール）、ならびにショート・メッセージ・サービス（ＳＭＳ）のメッセージフォーマットから選択される一または複数の通信プロトコルを使用して送信され得る。
【００７３】
さらに、データ収集コンポーネントで収集されたデータは、通信プロトコルに適したフォーマットであり得る。データ放出コンポーネントから放出されたデータは、通信プロトコルに適したフォーマットであり得る。データ収集コンポーネントで収集されたデータおよびデータ放出コンポーネントから放出されたデータもまた、括弧付き表現（ＬＩＳＰなど）のフォーマット、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ）、Ｊａｖａｓｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ  （ＪＳＯＮ、登録商標）、プロプライエタリ・バイナリ・フォーマット、ユーザ定義可能なテキストフォーマット、ならびにサーバの拡張を通じて追加されたフォーマットから選択されるフォーマットであり得る。
【００７４】
システムはさらに、ＴＣＰ／ＩＰ接続およびサーバによりサポートされた一または複数のデータフォーマットを実装するアプリケーション・プログラミング・インターフェース（ＡＰＩ）を備え、ＡＰＩは上述した接続の確立においてプログラマを支援し得る。ＡＰＩは、以下のプラットフォーム：「Ｃ」プログラミング言語、「Ｃ＋＋」プログラミング言語、ＭｉｃｒｏｓｏｆｔのＮｅｔプログラミング環境、Ｍｉｃｒｏｓｏｆｔ  ＳｉｌｖｅｒｌｉｇｈｔのＲＩＡフレームワーク、Ａｄｏｂｅ  ＦｌａｓｈのＲＩＡフレームワーク、Ａｄｏｂｅ  ＡｉｒのＲＩＡフレームワーク、ＴＣＰ／ＩＰ通信をサポートするプログラミング言語（任意のスクリプト言語を含む）、ならびにＴＣＰ／ＩＰ通信をサポートするＲＩＡフレームワークのうち一または複数のプラットフォームのために実装され得る。
【００７５】
ＲＩＡは、Ｍｉｃｒｏｓｏｆｔ  Ｓｉｌｖｅｒｌｉｇｈｔ、Ａｄｏｂｅ  Ａｉｒ、およびＴＣＰ／ＩＰ通信をサポートするＲＩＡフレームワークから選択されるＲＩＡフレームワークを使用して実装され得る。ＲＩＡフレームワークは、データを受信するためサーバへの第１の永続的ＴＣＰ／ＩＰデータ接続を作り出し、サーバからデータを受信し、第２ＴＣＰ／ＩＰデータ接続を通じてサーバにデータを送信するためのサポートを備え得る。データは、オンデマンド、または登録によりサーバから受信され得る。第１ＴＣＰ／ＩＰデータ接続および第２ＴＣＰ／ＩＰデータ接続は、同じ接続であり得る。第２ＴＣＰ／ＩＰデータ接続永続的接続であり得る。第２ＴＣＰ／ＩＰデータ接続は、一時的な接続であり得る。サーバへのＴＣＰ／ＩＰデータ接続は、上述したＡＰＩ直接のＴＣＰ／ＩＰ接続、ＨＴＴＰ、およびＨＴＴＰＳから選択されるプロトコルであり得る。
【００７６】
クライアントは、ＲＩＡフレームワーク、ウェブブラウザ、コンパイル済みコンピュータ言語、解読済みコンピュータ言語、ハードウェア装置、またはＨＴＴＰおよび／もしくはＨＴＴＰＳプロトコルをサポートする別の実装メカニズムを使用して実装され得る。クライアントは：データを受信するためのサーバへの第１永続ＴＣＰ／ＩＰデータ接続の作成；サーバからのデータの受信；および第２永続ＴＣＰ／ＩＰデータ接続を通じたサーバへのデータ伝送；に対するサポートを含み得る。データは、オンデマンド、または登録によりサーバから受信され得る。サーバへのＴＣＰ／ＩＰデータ接続は、ＨＴＴＰおよびＨＴＴＰＳから選択されたプロトコルにおいてなされ得る。
【００７７】
サーバからのデータは、括弧付き表現（ＬＩＳＰなど）のフォーマット、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ）、Ｊａｖａｓｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）プロプライエタリ・バイナリ・フォーマット、ユーザ定義可能なテキストフォーマット、ならびにサーバへの拡張により追加されたフォーマットから選択される一または複数のフォームで受信され得るか、またはサーバへのデータは送信され得る。
【００７８】
ＲＩＡフレームワークはさらに、データを示すグラフィックディスプレイをユーザに提示するためのサポートを備え得る。グラフィックディスプレイは、テキスト表示、スライダ、チャート、傾向グラフ、環状ゲージ、線形ゲージ、ボタン、チェックボックス、ラジオボタン、プログレスバー、基本のグラフィカル・オブジェクト、ＲＩＡフレームワークにサポートされているコントロール、ＲＩＡフレームワークを拡張するために作成されたカスタムコントロール、ＲＩＡフレームワークを使用して実装された第三者コントロール、およびカスタム化されたグラフィック要素から選択される一または複数のグラフィック要素を備え得る。
【００７９】
グラフィックディスプレイの構成情報は、サーバ上で保存されるとともにサーバからロードされ得る。グラフィック要素は、グラフィックディスプレイにおいて作成および変更され得る。グラフィック要素は、ユーザがカスタム可能なカスタム化されたグラフィック要素であり得、カスタム化はサーバ上で保存され得る。カスタム化は、ＲＩＡフレームワークに実装されたアプリケーションに変更を必要とすることなくプログラマにより行われ得る。カスタム化されたグラフィック要素は、他のグラフィック描写でユーザが使用するために利用可能であり得る。これらのカスタム化は、ユーザインターフェース・アプリケーションにより元々サポートされているグラフィック要素に全て追加して、新たなディスプレイを作成し、既存のディスプレイを変更するためのものであり得る。グラフィック要素は、ユーザが変更可能な一または複数の特性を備え得、プログラマにより選択可能であり得る。ユーザのグラフィック要素との相互作用により、ユーザインターフェース・アプリケーションがデータに対する変更をサーバに放出させる。ユーザ専用モードが提供されると、ユーザによるグラフィックディスプレイの作成または変更を許可せず、また読み取り専用モードが提供されると、ユーザによるグラフィック要素との相互作用を許可しない。システム・アドミニストレータは、ユーザと、ユーザインターフェース・アプリケーションがユーザ専用モードおよび読み取り専用モードの１つで動作するグラフィックディスプレイを選択し得る。ユーザは、識別が必要とされる場合に自身を識別することが必要とされ、ユーザインターフェース・アプリケーションは、ユーザ専用モードおよび読み取り専用モードの少なくとも１つのモードで動作し得る。有利に、本発明の特徴によると、任意のユーザＲＩＡ端末を通してグラフィックディスプレイの変更が可能であり、保存により生じた変更は、サーバに接続された他の全てのＲＩＡ端末が直ぐに利用することができる。
【００８０】
別の態様では、本発明は、ＨＴＴＰまたはＨＴＴＰＳを介してクライアントとサーバとの間で双方向ストリーミング通信を提供する方法を提供する。その方法は、セッションＩＤを生成することと、クライアントからサーバへの第１のＨＴＴＰトランザクションを経由して第１ソケットをオープンすることと、サーバおよびクライアントにおいてセッションＩＤを第１ソケットと関連付けることと、クライアントからサーバへの第２のＨＴＴＰトランザクションを経由して第２ソケットをオープンすることと、サーバおよびクライアントにおいてセッションＩＤを第２ソケットと関連付けることと、第１ソケット上で永続的接続を維持することと、第２ソケット上で永続的接続を維持することとを含み、セッションＩＤ、第１ソケットおよび第２ソケットの間で対応が作成され、クライアントとサーバ間で双方向通信が確立される。
【００８１】
方法は、構成情報、コマンド、実時間情報、以前のトランザクションからの保留中のデータ、および他のデータを含む群から選択される少なくとも１つのデータメッセージを送信するクライアントをさらに含み得る。方法は、第１ソケットからのイベントを待つことと、第１ソケットからのイベントがエラーであるかを検証することと、イベントがエラーでない場合に第１ソケットから利用可能なデータを読み取ることと、そのデータを処理して結果を生じることと、任意選択で、その結果を第２ソケット経由でサーバに送信することとを含み得る。方法は、クライアントが：第１ソケットをクローズすることと、第１ソケットからのイベントがエラーである場合に、第２ソケットをクローズすることとをさらに含み得る。方法は、クライアントが：クライアント生成イベントを待つことと、クライアント生成イベントを処理して結果を生じることと、任意選択でその結果を第２ソケット経由でサーバに送信することとをさらに含み得る。クライアント生成イベントは、内部的に生成されたスティミュラス、ユーザ活動の結果、タイマ、外部的スティミュラスを含む群から選択され得る。方法は、クライアントが：サーバへの送信用のデータを保留にマーキングすることと、第２ソケットをクローズすることと、新しい第２ソケットをオープンすることと、その新しい第２ソケットをセッションＩＤと関連付けることとをさらに含み得る。
【００８２】
方法は、サーバが：第２ソケットからのイベントを待つことと、第２ソケットからのイベントがエラーであるかを検証することと、イベントがエラーでない場合に第２ソケットから利用可能なデータを読み取ることと、そのデータを処理して結果を生じることと、任意選択で、その結果を第１ソケット経由でクライアントに送信することとをさらに含み得る。方法は、サーバが第２ソケットをクローズすることをさらに含み得、第２ソケットからのイベントはエラーである。方法はサーバが：サーバ生成イベントを待つことと、サーバ生成イベントを処理して結果を生じることと、任意選択でその結果を第１ソケット経由でクライアントに送信することとをさらに含み得る。サーバ生成イベントは、内部的に生成されたスティミュラス、ユーザ活動の結果、タイマ、別の接続クライアントからの結果、データソースからのデータ、および外部的スティミュラスを含む群から選択され得る。方法は、サーバが：第１ソケットをクローズすることと、第２ソケットをクローズすることとをさらに含み得る。
【００８３】
上述の方法では、第１のＨＴＴＰトランザクションは、ＨＴＴＰ  ＧＥＴトランザクションおよびＨＴＴＰ  ＨＥＡＤトランザクションを含む群から選択され得、第２のＨＴＴＰトランザクションは、ＨＴＴＰ  ＰＯＳＴトランザクション、ＨＴＴＰ  ＰＵＴトランザクション、ＨＴＴＰ  ＰＡＴＣＨトランザクション、およびＨＴＴＰ  ＴＲＡＣＥトランザクションを含む群から選択され得る。好ましくは、第１のＨＴＴＰトランザクションは、ＨＴＴＰ  ＧＥＴトランザクションであり、第２のＨＴＴＰトランザクションは、ＨＴＴＰ  ＰＯＳＴトランザクションである。
【００８４】
さらに別の態様では、本発明は、ＨＴＴＰまたはＨＴＴＰＳプロトコルを介して双方向ストリーミング通信を提供するためのシステムを提供する。そのシステムは、少なくとも１つのクライアントと、少なくとも１つのサーバを含み、少なくとも１つのクライアントは上述の方法を実装するように適合され、少なくとも１つのサーバは上述の方法を実装するように適合される。少なくとも１つのクライアントはＲＩＡを含み得る。少なくとも１つのサーバは、少なくとも１つのデータソースからデータを収集するためのデータ収集コンポーネント、および少なくとも１つのデータクライアントにデータを放出するためのデータ放出コンポーネントを含み得る。
【００８５】
さらに別の態様では、本発明は、命令を格納するコンピュータ可読メモリを提供し、その命令は、１つ以上のコンピュータ上で実行される際に、コンピュータに、クライアントとサーバとの間でＨＴＴＰまたはＨＴＴＰＳを介して双方向ストリーミング通信を提供する方法を実行させる。その方法は、上述した方法のステップを含む。
【００８６】
前述のように、ＨＴＴＰプロトコルは、各トランザクションが一般に一時的なトランザクションモデルを実装する。各トランザクションはクライアントによって開始されて、サーバにデータを送信するか、またはサーバからデータを要求するように指定されるが、その両方ではない。
【００８７】
ウェブクライアントは、大量のデータを送受信する必要があり得る。この場合、それは、クライアントがデータを不完全なチャンクで送受信できるようにするＡＰＩを実装し得る。すなわち、完全なデータセットが送信されるまでに複数の送受信動作を必要とし得る。例えば、サーバから画像を受信するクライアントは、１ＫＢのチャンクで画像を受信し、そのため、画像全体が到着する前に画像のレンダリングを開始でき、漸進的なレンダリング効果を生じる。この挙動は、データの連続したストリームを生じるためにクライアント内で利用できる。クライアントは、ＵＲＬに対するＨＴＴＰ  ＧＥＴ要求を特別に設計されたサーバ（またはそのＵＲＬに対して特別に設計されたハンドラを備えた標準的なサーバ）上で作成し得る。サーバはＨＴＴＰヘッダで応答し、次いで、ソケットをオープンしたままにし得る。将来いつでも、サーバはデータをソケット上で送信し得、それは、クライアントに不完全な送信として到着するであろう。クライアントは、このデータを処理でき、次いで、さらなるデータを待つ。サーバがソケットをオープンしたままにしている限り、クライアントは、受信すべきデータがさらにあるという期待に従って単に動作し、それが到着すると処理する。サーバは、クライアントがＨＴＴＰ接続のオープンとクローズを繰り返す必要なく、いつでもクライアントに非同期的にさらなる情報を送信できる。このメカニズムは、ストリーミングＡＪＡＸの基礎となる手法である。開示のとおり、それは一方向である。このメカニズムは、クライアントからサーバへの高速通信は提供しない。
【００８８】
本発明の重要な技術革新の１つは、クライアントからサーバへの高速接続を作成する問題を解決することである。解決策は、クライアントがサーバとのＨＴＴＰ  ＰＯＳＴトランザクションをオープンして、必要なＨＴＴＰヘッダ情報を送信することである。サーバは次いで、ＰＯＳＴのデータペイロードが到着するのを待つ。将来いつでも、クライアントはオープンしたソケット上でデータを送信し得、事実上、逆方向のストリーミングＡＪＡＸメカニズムのように動作する。クライアントはソケットを無期限にオープンしたままにして、各新しい送信に対してＨＴＴＰ接続のオープンとクローズを繰り返す必要なく、必要に応じてデータを送信し得る。
【００８９】
サーバは、データがストリームとして到着することを知っている必要があり、それが到着すると情報を処理する。これは、サーバにおけるカスタム挙動を必要とし得る。
【００９０】
ＨＴＴＰプロトコルは、クライアントがサーバにＨＴＴＰヘッダ内のＨＴＴＰ  ＰＯＳＴメッセージのサイズ（コンテンツ長）を通知する必要があることを指定する。クライアントがコンテンツ長ヘッダで指定したよりも多いか少ないデータを送信することはＨＴＴＰプロトコル違反である。本発明は、クライアントからサーバに送信されるバイト数を追跡することによりこれを認識する。ＨＴＴＰ  ＰＯＳＴコンテンツ長は、クライアントにより任意のバイト数に指定される。クライアントがコンテンツ長のバイトを送信し終えると、クライアントはその既存の接続をクローズし、新しい接続をオープンして送信を継続する。ＰＯＳＴメッセージ内のバイト数は大きくすることができ（例えば、最大で２３１バイトまで）、従ってこのオープンとクローズは非常に稀にしか起こらない。その結果、いくつかのデータの送信において若干の待ち時間があり得るが、情報の損失はない。
【００９１】
好ましい実施形態では、本発明は、２つのソケットを必要とし、その一方は、ＨＴＴＰ  ＧＥＴを介したサーバからクライアントへの通信を処理し、他方は、ＨＴＴＰ  ＰＯＳＴを介したクライアントからサーバへの通信を処理する。双方向ストリーミング通信を提供するためにこれら２つのソケットが同時に機能するために、ウェブサーバは、それらが、１つの会話の関連した半分であることを知る必要がある。この関係は、クライアントによって確立され得る。クライアントは、まずＨＴＴＰ  ＧＥＴ接続をオープンして、そのＵＲＬ内に一意のセッションハンドル（例えば、ランダムに生成されたＧＵＩＤ）を含める。クライアントが後にＨＴＴＰ  ＰＯＳＴ要求をオープンすると、そのＵＲＬ内に同じセッションハンドルを含める。サーバは次いで、２つの接続を関連付けることができる。コンテンツ長制限に到達したためにＨＴＴＰ  ＰＯＳＴ接続をクローズして再オープンする必要がある場合、クライアントは同じＧＵＩＤを再度送信する。サーバは次いで、この新しいＰＯＳＴソケットを既存のＧＥＴソケットと関連付けることができる。
【００９２】
ウェブサーバは、この手法が採用されていることを理解する必要がある。ウェブサーバは、元のＧＥＴ接続に対して特別に指定されたＵＲＬへのコールを追跡して、セッションハンドルをその接続と関連付け、次いで、ＰＯＳＴ接続をそのＧＥＴ接続と同じセッションハンドルと関連付ける必要がある。各接続ペアを処理するために、ウェブサーバが別個のスレッドを生成することは、必要ではないが、望ましくあり得る。
【００９３】
ＧＥＴおよびＰＯＳＴ接続を確立すると、クライアントは、ＧＥＴ接続を介してサーバから非同期データを受信し、ＰＯＳＴ接続を介してサーバに非同期データを送信することができる。サーバは逆を行い、ＧＥＴ接続を介してデータを送信し、ＰＯＳＴ接続を介してデータを受信する。クライアントおよびサーバの両方の挙動は、あたかも単一の双方向ソケットを経由して通信しているかのように、その他の点では同じである。
【００９４】
当業者には理解されるように、ＨＥＡＤ、ＰＵＴ、ＰＡＴＣＨおよびＴＲＡＣＥなどの他のＨＴＴＰ動詞も使用され得る。例えば、他の動詞を認識するようにサーバをさらに修正するか、またはＧＥＴのように挙動するためにＨＥＡＤトランザクションに関するプロトコル制約を緩和することが可能であることも理解されるであろう。従って、サーバが追加の／異なる挙動を認識するように修正されると、他の動詞が使用され得る。かかる修正は、ＨＴＴＰ仕様の厳密な実装から逸脱するが、依然として本発明の範囲内である。
【００９５】
本発明の予期しない利点が、安全な実時間クラウドサービスのためのシステムおよび方法に関して、いくつかある。セキュリティの懸念問題に対処するため、クラウド上でプロセスデータを共有するための１つの従来技術方法では、仮想プライベートネットワーク（「ＶＰＮ」）を使用する必要があった。しかし、ＶＰＮ上の全ての装置は他の全てのマシンに対してオープンであるので、セキュリティの観点から、ＶＰＮの使用には問題がある。各装置（および前記装置の各ユーザ）は、ＶＰＮ上で完全に信頼される必要がある。セキュリティが複雑で、あまり良好ではなく、事実上、企業間で通信をオープンするためにこのアプローチを使用することを不可能にする。その結果として、本発明は、第３者が既存のＶＰＮにアクセスすることを要求することなく、従って、ＶＰＮ上のコンピュータおよび装置をそれらの第３者に決して公開することなく、第３者企業間でのデータの共有を可能にする。その上、ＶＰＮは性能ペナルティを招くか、実時間性能を損なうか、または埋め合わせのための（例えば、システムに対して追加のハードウェア、計算リソースおよび複雑性を必要とすることにより）著しい追加費用を招くかのいずれかとなる。
【００９６】
さらに好都合なことに、本発明は、プラントサイトにおいて、特定のデータストリームがアップロードまたはダウンロードできるようにするために、クライアント企業によって構成されるソフトウェアを使用して、ユーザが、作業場設備をパートナおよび第３者企業だけでなく、経営者に接続できるようにする。
【００９７】
本発明は、完全にソフトウェアベースであり、既存のハードウェア上で実装でき、従って、著しい複雑性を、確立されたネットワークにもたらさない。
【００９８】
好都合なことに、本明細書で開示する方法を使用すると、一旦クライアント／サーバ接続が接続されると、データはいずれの方向にも流れることができる。クライアントユーザは、あたかもローカルシステムで作業しているかのように、システムを実時間で監視し、変化を及ぼし、自分の動作の効果を直ちに見ることができる。あるいは、必要に応じて、システムは、プラントから一方向、読み取り専用に構成できる。
【００９９】
本発明は、ＯＰＣ、ＴＣＰ、およびＯＤＢＣのようなオープンで標準的なプロトコルを使用して、任意の産業システムに接続する機能を提供する。かかる柔軟性は、既存の機器における投資を十分に利用することによりさらなるコスト削減を可能にするか、または新しい設備をクラウド接続性で強化する。本発明の使用例は、既存のＳＣＡＤＡシステムへの追加、個々のマシンに対するＨＭＩとしての機能強化、またはＲＴＵもしくは個々の組込み機器さえのアクセスである。
【０１００】
本明細書で開示する方法と組み合わせて、本発明は、クライアントがデータ変更を一度登録すると、それらが生じた直後に後続のアップデートを受信する、データ配信の公開／登録、イベント駆動モデルをサポートする。この低遅延、クラウドベースシステムは、極めて低いオーバーヘッドをデータ送信時間全体に追加し、事実上、スループット速度をネットワーク伝搬時間よりもほんの数ミリ秒（未満）多いだけに保つ。
【０１０１】
一実施形態では、本発明は、データを可能な限り単純な形式で処理することにより、超高速性能を達成し得る。データを中心とする設計を提供することにより、本システムは、様々な種類のデータソースおよびユーザ、例えば、制御システム、ＯＰＣサーバ、データベース、スプレッドシート、ウェブページ、および組込み機器で機能できる。好ましくは、クラウドサーバに対して接続が作成されると、着信データから不必要なフォーマッティング（ＸＭＬ、ＨＴＭＬ、ＯＰＣ、ＳＱＬなど）が取り除かれて、任意の登録されたクライアントに可能な限り迅速に渡される。受信側において、データは、クライアントが要求するいかなるフォーマットでも配信される。
【０１０２】
本明細書で開示する方法を用いると、安全なクラウドサービスに対するＲＩＡまたはウェブベースのユーザインターフェースにより、サービスに登録して、データ接続オプションを構成し、利用および費用を監視するエニウェアアクセス（ａｎｙｗｈｅｒｅ−ａｃｃｅｓｓ）を提供する。追加として、全てのデータ表示画面が、ウェブベースのインターフェースを経由して提供され得る。このウェブベースＨＭＩは、ユーザがどこからでもページを作成して、それらを直ちに配置するのを可能にする。
【０１０３】
さらに好都合なことに、クラウドコンピューティングの利点の１つは、そのユーザの必要性を満たすようにスケールアップまたはスケールダウンする機能である。本発明は、データフローにおける高速活動のバーストを処理できるだけでなく、成長するシステムの必要性を満たすために迅速に構成することもできる。ユーザは、簡便なウェブベースの構成インターフェースを通じて、データポイントを特定の装置に追加するか、または新しい装置、新しいＳＣＡＤＡシステム、新しい位置および設備にさえ持ってくることができる。
【０１０４】
本発明は、実時間産業システムとして動作可能であり、クラウド環境において適切なレベルの性能およびセキュリティを維持できる。その高性能な接続オプションによって、プラントにおける主要な制御システムが、切断することなく機能を継続できるようにする。結果として、企業にライブのプロセスデータを堅牢で安全な方法で供給して、実時間監視、協業、および予測保守の機会を提供する。
【０１０５】
図１を参照すると、一実施形態において、ＲＩＡ１０１は、データソースおよびデータサーバ１００の両方として機能するプログラムに対しデータが直接接続する。この状況は、データソースがＴＣＰ／ＩＰプロトコルを用いる生データのコレクタおよびトランスミッタの両方である場合に生じ得る。ＰＬＣ内に組み込まれたＯＰＣ−ＵＡサーバがこの例である。別の例は、データソースとして機能し、カスタム用ＴＣＰ／ＩＰインターフェースを提供するＴＣＰ／ＩＰサーバの能力を提供する組み込み装置である。さらに別の例は、ＴＣＰ／ＩＰインターフェースを提供する株式市場のデータ供給である。
【０１０６】
図２を参照すると、一実施形態において、別の構成は別個になったデータソース２０２とサーバ２０３とを含む。この構成は、データソース２０２のデータプロトコルを、ＲＩＡ２０１が処理できるＴＣＰ／ＩＰプロトコルに変換することにより通信モデルを拡張する。これにより、サーバ２０３がＴＣＰ／ＩＰのインターフェースを直接提供しないデータソース２０２と相互作用することが可能になるため、データソース２０２の数および種類が非常に拡大される。
【０１０７】
図３を参照すると、一実施形態において、サーバ３０３は、同時に２つ以上のデータソース３０２と２つ以上のＲＩＡ３０１との接続を維持し得る。この一層複雑な構成は、データソース３０２とＲＩＡ３０１とからのデータを、ＴＣＰ／ＩＰネットワーク上のどこからでもアクセス可能な単一のデータセットに集約する。
【０１０８】
別の実施形態では、システムは、複数のデータソースおよび／または一もしくは複数のＲＩＡと内部接続された複数のサーバを含み得る。
【０１０９】
図４を参照すると、一実施形態におけるＲＩＡ動作の方法および制御フローが示される。ＲＩＡは、一または複数は組み込まれ得るが、明確な停止基準を必要としない。ＲＩＡは、ユーザＲＩＡを含むウェブブラウザまたはウェブページを閉じたときに暗黙的に停止される。ＲＩＡは、２つの制御フローを同時に従い、単一のプログラムスレッドにインターリーブされるか、または別個のプログラムスレッドに実装され得る。方法は、ＲＩＡに特異的な追加処理を含み得る。
【０１１０】
１つ目の制御フローでは、ＲＩＡはサーバへの接続を確立および維持、ならびにサーバから利用可能なデータにおける変化への応答を試みる。まず、ＲＩＡは接続の確立を試みる（ステップ４０１）。接続が成功しない場合、ＲＩＡはただひたすらその接続を試みる。接続が成功する場合（ステップ４０２）、次いでＲＩＡは、全てまたは一部分のデータセットに参加し得る（ステップ４０３）。代替的に、接続していることに基づいてサーバがデータにＲＩＡを黙示的に加えることが可能であり、この場合ステップ４０３は省略されてよい。参加に加えて、ＲＩＡは、接続の更新の最短時間またはタイムアウトパラメータなどデータ送信動作を構成するため、サーバに他の情報も送信し得る。
【０１１１】
接続を確立すると、ＲＩＡはサーバからデータにおける変化通知を待つ（ステップ４０４）。データ変更が生じている場合（ステップ４０５）、次いでＲＩＡは何らかの方法でそのデータを処理する（ステップ４０７）。この処理は、ＲＩＡの内部状態を変更、グラフィック描写を変更、ＲＩＡ設計者が決定する音または他の任意のログラミングの応答を出すためであり得る。データ変化が生じない場合、ＲＩＡは何等かの理由でサーバへの接続が切れたかを特定するために調べる（ステップ４０６）。接続が切れていない場合、ＲＩＡは再びデータ変化が生じるのを待つ（ステップ４０４）。接続が切れている場合、その時ＲＩＡは再びサーバへの接続を試みる（ステップ４０１）。
【０１１２】
ステップ４０１〜ステップ４０７と同時に、ＲＩＡはユーザ入力を受入れ、ユーザは、サーバに伝搬できるデータの変化を作成することが可能となる。ＲＩＡは、別個のプログラムスレッドまたはステップ４０１〜ステップ４０７と多重化してユーザ入力を待つ（ステップ４２０）。
【０１１３】
図４は、別々にスレッド構成された方法を例示する。ユーザ入力が生じた場合（ステップ４２１）、次いでＲＩＡは、結果生じたデータのサーバへの送信を試みることができる。ＲＩＡは、サーバが接続されているか（ステップ４２２）を確かめるためにまず調べることでこの試みを行う。接続されている場合、ＲＩＡは新しいデータをサーバに送信する（ステップ４２３）。接続されていない場合、ＲＩＡはさらに入力を待つ（ステップ４２０）。サーバ接続のチェック（ステップ４２２）は、データを送信するために暗黙的に試みられ、この場合、ステップ４２２およびステップ４２３は実質的に組み合わせられる。
【０１１４】
ＲＩＡはまた、ユーザ入力が受入れられないなど相互作用できない場合、ステップ４２０〜ステップ４２３を省略することができる。
【０１１５】
図５を参照すると、一実施形態におけるデータサーバの動作方法が示される。サーバは、０以上のＲＩＡ接続にデータを出しながら、同時に０以上のデータソースからデータを収集し得る。主要な２つの制御フローを別々のスレッドか、または単一のスレッド内で２つの制御フローパスをインターリーブすることにより実装することができる。
【０１１６】
データソースと相互に作用するために、サーバはまずそのデータソースとの接続を確立しなければならない（ステップ５０１）。通常、サーバがデータソースへの該接続を開始する。場合によっては、データソースがサーバへのその接続を開始する。接続が成功する場合（ステップ５０２）、サーバはデータソースからデータを収集し始める（ステップ５０３）。接続が失敗する場合、サーバはデータソースへの接続を再度試みる（ステップ５０１）。データソースがサーバへの接続の開始側である場合、次いでステップ５０１およびステップ５０２は単一の待ち状態へと折り重なり、サーバは接続するため受動的にデータソースを待つ。データの収集（ステップ５０３）は、データソースに適した方法に従い、一方のデータソースと別のデータソースで異なり得る。サーバは、データをサーバに表示することができる任意のデータソースと適応するように作成することができる。新規データがデータソースから利用可能になると（ステップ５０４）、サーバはそのデータをサーバの内部のデータ表現に変換する。これにより、サーバは異なるデータ表現を使用して種々のデータソースを集めることが可能となる。ステップ５０６は、データソース、サーバ、およびＲＩＳが全て同じデータ表現を使用する簡単なケースの場合に省略することができる。次いでサーバは、データの各ＲＩＡへの送信を試みる。サーバはまず、ＲＩＡが接続されるように確立し得る（ステップ５０７）。一または複数のＲＩＡが接続される場合、サーバはＲＩＡに好適な表現へとデータを変換し（ステップ５０８）、そのデータを接続された各ＲＩＡに送信する（ステップ５０９）。ＲＩＡが接続されない場合、サーバはデータソースからデータを収集し続ける（ステップ５０３）。サーバは無期限にこのシーケンスを繰り返す（ステップ５０１〜ステップ５０９）。データシンクがデータソースからデータを必要とするサーバに接続されていないとき、サーバはそのデータソースからデータを収集しないように選択し得る。
【０１１７】
データソースからデータを収集することと同時に、またはインターリーブして、サーバはＲＩＡからの接続も管理する。サーバはＲＩＡからの接続を待つ（ステップ５２０）。ＲＩＡがサーバとの接続を試みるとき（ステップ５２１）、サーバは接続を受入れ（ステップ５２２）、他のＲＩＡからの接続を待ち続ける。ＲＩＡとの接続を待つ間に、サーバは既存のＲＩＡ接続が切れているかを特定しなければならない（ステップ５２３）。ＲＩＡが切れている場合、ＲＩＡ接続はサーバにおける追跡から解除され（ステップ５２４）、それにより、接続が切れたＲＩＡにはその後データを送信するための試みはなされない（ステップ５０９）。サーバは、このシーケンスを無期限に繰り返す（ステップ５２０〜ステップ５２４）。サーバは、認証失敗またはサーバがＲＩＡインスタンスからの同時接続の最大数に限定を加えるなど、何らかの理由でサーバが接続を拒否し得るように、ＲＩＡが接続を試みる（ステップ５２２）ときに、承認基準を適用し得る。
【０１１８】
データソースからデータを収集すること、ＲＩＡからの新規接続を管理することと同時に、またはインターリーブして、サーバはまた、既に接続されたＲＩＡからデータを受信し得る。サーバはＲＩＡから届くまでデータを待つ（ステップ５３０）。新規データが届くと（ステップ５３１）サーバはこのデータをサーバの内部のデータフォーマットに変換する（ステップ５３２）。次いでサーバは、いずれかのＲＩＡが現在接続されているかを特定する（ステップ５３３）。次いでサーバは、データＲＩＡが受信するのに好適なフォーマットにデータを変換し（ステップ５３４）、現在接続されている各ＲＩＡにデータを送信する（ステップ５３５）。次いでサーバは、この情報の変更を必要とするいずれかのデータソースが現在接続されているかを判断する（ステップ５３６）。現在サーバに接続されている情報を必要とする各データソースのため、サーバはそのデータソースに好適なフォーマットにデータを変換し（ステップ５３７）、データを送信する（ステップ５３８）。サーバはこのシーケンスを無期限に繰り返す（ステップ５３０〜ステップ５３８）
【０１１９】
ステップ５０１〜ステップ５０９は、サーバが接続し得る各データソースに対し、繰り返し反復することができる。
【０１２０】
ステップ５２０〜ステップ５２４は、サーバが接続を受信し得る各ＲＩＡに対し、繰り返し反復することができる。
【０１２１】
ステップ５３０〜ステップ５３８は、接続された各ＲＩＡに対し反復され得るか、ステップ５３０は接続された全てのＲＩＡを同時に待つように多重に行われるか、またはこれらの選択肢を組み合わせて行われ得る。
【０１２２】
図４および図５で例示した方法は、ＲＩＡおよびデータサーバの両方に対する明確な停止条件、サーバに接続するためデータソースを受動的に待つサーバの能力、ＲＩＡに積極的に接続するサーバの能力、複数のデータソースへの接続を同時に管理するサーバの能力、複数のＲＩＡへの接続を同時に管理するサーバの能力、および複数のＲＩＡからデータを同時に受信するサーバの能力を含む追加の能力を備えるように改良され得ることが理解される。
【０１２３】
図６を参照すると、一実施形態において、複数のＲＩＡ６０１への接続を同時に管理するデータサーバ６０３の能力によると、有利にＲＩＡ６０１はサーバを介して別のＲＩＡ６０１と通信することが可能となる。ＲＩＡ６０１からサーバ６０３に送信される任意の情報は、ＲＩＡ６０１がデータソースのように扱われ、サーバに接続されており、データに参加している他の任意のＲＩＡ６０１にそのデータを伝搬する。驚くべきことに、これにより実時間で互いに更新するＲＩＡのネットワークを効果的に作り出す。実際に、サーバ６０３は、サーバがサポートするプロトコルの任意の組み合わせを使用して、任意の数のクライアント・アプリケーション間で通信することができるように使用され得る。
【０１２４】
図７を参照すると、一実施形態では、本発明の実質的な利益は、そうでなければネットワークを介してアクセスできないソースが発信元であるデータをＲＩＡ７０１に提示する能力である。この実施形態では、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌのような表計算アプリケーション７０５を基にしたデータは、本発明の前は可能ではなかったローカルまたは広域ネットワークを介して送信され得る。Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌからのデータ送信は、ＤＤＥ、ＲＴＤまたは不安定なスクリプトを用いたアドホック通信に限定される。ＲＩＡとの実時間通信を可能とするＤＤＥ、ＲＴＤまたはスクリプトを通じたアドホック通信を含む、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌから供給されるプロトコルはＲＩＡと実時間で通信できない。本発明によれば、任意のアプリケーションが任意のＴＣＰ／ＩＰネットワークを用いて表計算データと実時間で通信することが可能となり、表計算データ用アプリケーションの範囲が広大に拡大する。ＲＩＡ７０１とのこの通信能力の組み合わせは、単一のウェブブラウザ接続を介した単一の表計算と複数の同時ユーザが相互接続する能力を提供する。この同一の機能性は、サーバ７０３がサポートする任意のプロトコルにまで拡張する。
【０１２５】
ウェブブラウザ内でＲＩＡを実行する場合、ＲＩＡは、ウェブサーバを使用してウェブブラウザに提供されなければならない。すなわち、ユーザは、ウェブブラウザにＵＲＬを入力するか、またはそのＵＲＬのためにウェブページ内のリンクをクリックしてＲＩＡを含むウェブページをウェブブラウザにロードさせる。ＵＲＬは、Ｍｉｃｒｏｓｏｆｔ  ＩＩＳ（商標）またはＡｐａｃｈｅ（商標）などのウェブサーバによりサービスが提供されている。よって、ＲＩＡをロードおよび接続するイベントのシーケンスは以下の通り。
１．ユーザがウェブブラウザでＵＲＬを選択する
２．ウェブブラウザがウェブサーバからＲＩＡを含むページをロードする
３．ウェブブラウザがＲＩＡを開始する
４．ＲＩＡがＴＣＰ／ＩＰを介してデータサーバと接続する
５．ＲＩＡがデータサーバのデータに参加する
６．データサーバが参加に従ってデータを送信する
７．ＲＩＡが接続を絶つかまたは停止するまでデータサービスが続く
【０１２６】
このシーケンスには、ウェブサーバが存在し、ＲＩＡに配信するように構成されていることが必要である。システムコンポーネントの数を縮小し、ＲＩＡのデータ機能とウェブの機能とを一層強く一体化するため、データサーバにウェブサーバの能力を組み込むことが便利であろう。
【０１２７】
組み込まれたブラウザまたは別個の非ブラウザホスト（ＲＩＡ用ブラウザ外モードと呼ぶ場合もある）から実行されてＲＩＡセッションを起動し得ることが当業者には容易に明らかになるであろう。ＵＲＬおよびウェブブラウザは、ユーザにとって明らかではない場合がある。従って、上述したイベントの最初の３つのステップが変更されてこれらの代替の実施形態を反映し得る。
【０１２８】
本発明では、ＲＩＡはデータを使用または生成することができるＲＩＡフレームワークを使用して記載された任意のアプリケーションであり得る。
【０１２９】
一実施形態では、ＲＩディスプレイはユーザにとって視覚的な実時間データである。視覚コンポーネントは、ゲージ、傾向グラフ、プログレスバー、ボタン、画像、およびデスクトップのアプリケーションで一般的な他の視覚表現であり得る。可能性として多種多様な表現が存在するため、特定のデータセットに最も好適な表現は、別のデータセットに最も好適な表現と異なり、ＲＩＡは、ユーザが設定可能とすべきである。これは、ユーザがデータを視覚「オブジェクト」と関連付けることが可能な視覚構成ツールとともに提示されることを意味する。これらの視覚オブジェクトの収集は共に、関連情報を表示するために共通して使用される視覚「ページ」に配置することができる。次いで、ユーザは、異なる一式の関連情報を表示するために複数のページを作成することができる。
【０１３０】
データの視覚化をカスタマイズさせる能力をユーザに提供するために、ＲＩＡは、エディタとして一層共通して参照される、一体化したカスタム機能、または別々になったカスタム機能のいずれかを提供しなければならない。このエディタは、ユーザが実時間データを表示するページの視覚的なデザインを特定する手段を提供する。また、エディタは、視覚オブジェクトの特殊なバージョンを設計する能力も提供し得る。
【０１３１】
個々の視覚オブジェクトのデザイン、視覚ページのデザインに関する情報は、ウェブサーバに格納されるべきである。これにより、ユーザは、ウェブサーバで必要なアクセス特権を用いて他の任意のユーザが閲覧できるデータの視覚化を作り出すことが可能となる。ＲＩＡは、ウェブサーバと相互作用して文書を格納し、 ＸＭＬなどのフォーマットで格納された文書を回収する。この情報通信は、既存の実時間データ接続を用いるか、またはＨＴＴＰ接続を使用して行われ得る。データサーバ内に内蔵されたウェブサーバは、必要ではないがこの送信の実施を簡易にする。
【０１３２】
本発明の一実施形態では、本発明の方法を実装するシステムは、以下のソフトウェアアプリケーションを含む。
１．データサーバとして機能するＣｏｇｅｎｔ  ＤａｔａＨｕｂ（商標）（Ｃｏｇｅｎｔ  Ｒｅａｌ−Ｔｉｍｅ  Ｓｙｓｔｅｍｓ  Ｉｎｃ．）
２．ウェブサーバとして機能するＣｏｇｅｎｔ  ＤａｔａＨｕｂ（Ｃｏｇｅｎｔ  Ｒｅａｌ−Ｔｉｍｅ  Ｓｙｓｔｅｍｓ  Ｉｎｃ．）
３．ＲＩＡフレームワークとして機能するＭｉｃｒｏｓｏｆｔ  Ｓｉｌｖｅｒｌｉｇｈｔ（マイクロソフト株式会社）
４．Ｍｉｃｒｏｓｏｆｔ  Ｓｉｌｖｅｒｌｉｇｈｔのためのプロトコル実装層として機能するＤａｔａＨｕｂ  ＡＰＩ  ｆｏｒ  ．Ｎｅｔ（Ｃｏｇｅｎｔ  Ｒｅａｌ−Ｔｉｍｅ  Ｓｙｓｔｅｍｓ  Ｉｎｃ．）
５．ウェブブラウザに実時間データを表示するためのＲＩＡとして機能するＤａｔａＨｕｂ  ＷｅｂＶｉｅｗ（商標）（Ｃｏｇｅｎｔ  Ｒｅａｌ−Ｔｉｍｅ  Ｓｙｓｔｅｍｓ  Ｉｎｃ．）
６．視覚オブジェクトおよびページ設計のためのディスプレイ・エディタとして機能するＤａｔａＨｕｂ  ＷｅｂＶｉｅｗ（Ｃｏｇｅｎｔ  Ｒｅａｌ−Ｔｉｍｅ  Ｓｙｓｔｅｍｓ  Ｉｎｃ．）
【０１３３】
加えて、Ｃｏｇｅｎｔ  ＤａｔａＨｕｂは以下を含む様々なデータソースからデータを送信または受信し得る。
１．表計算アプリケーションとして機能するＭｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌ（商標）（マイクロソフト株式会社）
２．データ通信インターフェースとして機能するＯＰＣ−ＤＡサーバ（各社）
３．データ通信インターフェースとして機能するＯＰＣ−ＵＡサーバ（各社）
４．データ通信インターフェースとして機能するＯＰＣ  Ｘｉサーバ（各社）
５．データベースインターフェースとして機能するＯＤＢＣサーバ（各社）
【０１３４】
図８を参照すると、一実施形態では、特定の実装に応じて、０以上のデータソース８０１がＣｏｇｅｎｔ  ＤａｔａＨｕｂ（商標）８０２に配置され、それは次いで、実時間データ表示を配信するためにＣｏｇｅｎｔ  ＤａｔａＨｕｂ  ＷｅｂＶｉｅｗ（商標）ＲＩＡ  ８０３に配置される。
【０１３５】
本発明の代替的な実施形態では、ＲＩＡフレームワークは、持続したネットワーク接続をサポートすることが可能な任意のＲＩＡフレームワークであり得る。そのような代替的なＲＩＡフレームワークの例は、Ａｄｏｂｅ  Ｆｌａｓｈ（商標）、およびＡｄｏｂｅ  Ｆｌｅｘ（商標）を含む。他のＲＩＡフレームワークもまた好適であり得ることが想定される。
【０１３６】
ＲＩＡは、サーバのＴＣＰ／ＩＰ通信プロトコルを使用してデータを消費または生成することができるＲＩＡフレームワークを使用して作成された任意のアプリケーションであり得る。
【０１３７】
ＲＩＡフレームワークは、例えば、ＨＴＭＬ５が必要とされるＴＣＰ通信メカニズムをサポートしている場合など、ウェブブラウザに不可欠なものであり得る。
【０１３８】
データサーバは、構築されたＲＩＡがアクセスできるＴＣＰ／ＩＰ通信方法を供給できる限り、データソースからデータを収集、またはデータソース自体として機能するように設計された任意のアプリケーションであってよい。
【０１３９】
データソースは、サーバにおける表示に好適なフォーマットに変換できる実時間データを生成することが可能な任意のアプリケーションまたはシステムであり得る。
【０１４０】
また、データソースは、サーバにおける表示に好適なフォーマットに変換できる非実時間データを生成することが可能な任意のアプリケーションまたはシステムであり得る。サーバは、発信元のデータが実時間でない場合でもＲＩＡにデータを提供するために、前記データを繰り返しポーリングするか、または参加により収集することができる。例えば、データベース管理システム（ＤＢＭＳ）は、一般的に実時間でなくても、データは繰り返してポーリングしてサーバ内で定期的に更新データを生成し、ＤＢＭＳにおける疑似的な実時間のデータ図をＲＩＡに供給することができる。
【０１４１】
サーバおよびデータソースは、単一のアプリケーションに組み合わされ得、その場合、ＴＣＰ／ＩＰ接続を介してそのデータへのアクセスを提供するＯＰＣ−ＵＡサーバ、または内蔵された装置であり得る。
【０１４２】
ウェブサーバは、ＲＩＡを含むウェブページを提供することができる任意のアプリケーションであり得る。
【０１４３】
ＴＣＰ／ＩＰソケットを開き、相互に作用することができるコンパイルまたは解釈された任意のコンピュータ言語を使用して開発されたプログラムは、ウェブブラウザ内で実行または実行しないＲＩＡの代わりに使用され得る。同様に、本発明の方法はまた、ＲＩＡの代わりに、ブラウザ、ブラウザ以外のホストで直接またはブラウザの拡張を通じて実行可能なコードを使用して実施され得、ブラウザ、ブラウザ外のホスト、またはブラウザの拡張は開くことができ、ＴＣＰ／ＩＰソケットと相互に作用することができ、持続したネットワーク接続することができ、任意にグラフィック能力を提供することができる。
【０１４４】
図９を参照すると、一実施形態において、２つのＨＴＴＰ接続を使用するクライアントとサーバとの間の双方向ストリーミング通信のためのメカニズムが示されている。サーバは既に動作していて、サーバおよびクライアントによって合意されたポート上でＴＣＰ接続をリッスンしていると仮定する。明確にするために、ＨＴＴＰプロトコルの仕様は、業界で明確に定義されていて、当業者には知られているので、図示されず説明もされていない。また、重要でないエラー処理条件は省略されている。
【０１４５】
図９ａに示すように、クライアントは、双方向ＨＴＴＰストリーミングを経由してサーバと通信する試行を開始する（ステップ９００）。まず、クライアントは、現在の通信セッションを識別するためにＧＵＩＤを生成する（ステップ９０１）。代替として、サーバがクライアントの要求によりＧＵＩＤを生成し得る（図示せず）。このＧＵＩＤは、サーバにより、ＧＥＴとＰＯＳＴソケットを相互に、およびクライアント接続と関連付けるために使用される。次に、クライアントはＨＴＴＰ  ＧＥＴトランザクションをオープンし、そのＧＵＩＤをＵＲＬの一部として供給する（ステップ９０２）。サーバはこのＧＵＩＤを記録し、それをＨＴＴＰ  ＧＥＴソケットと関連付ける（ステップ９０３）。サーバはこのソケットをオープンしたままにする。クライアントは次いで、サーバとのＨＴＴＰ  ＰＯＳＴトランザクションをオープンし（ステップ９０４）、再度、そのＧＵＩＤを、ＵＲＬの一部として、またはＰＯＳＴメッセージの本体内で供給する。クライアントは、このＨＴＴＰ  ＰＯＳＴトランザクションのコンテンツ長を、サーバで受け入れ可能な任意のバイト数になるように指定する。サーバは、ＨＴＴＰ  ＰＯＳＴソケットをＧＵＩＤと関連付け、従って、クライアント、ＰＯＳＴソケットおよびＧＥＴソケットの間で通信を作成する。
【０１４６】
一旦、ＰＯＳＴおよびＧＥＴソケットのオープンが成功すると、クライアントは構成情報および以前の接続からの保留中のデータをＰＯＳＴソケット経由で送信し得る（ステップ９０６）。クライアントは、所与のセッションに対するＰＯＳＴソケットの第１接続においてだけ構成情報を送信するように選択し得る。後続のＰＯＳＴソケット接続では、以前に配信できず、この時点で配信されるデータがあり得る。コマンドまたはデータがステップ９０６で送信された場合、サーバはそれらを処理して（ステップ９０７）、クライアントがステップ９０８で受信する０個以上の応答を生成する。
【０１４７】
一旦、接続が完全に確立されると、クライアントおよびサーバはそれぞれ待ち状態に入り、そこで、それらは、他からデータが到着するか、またはそれらに他にデータを放出させるイベントのいずれかを待つ。すなわち、サーバは、図９ｃに示すように、クライアントからデータが到着するか、またはローカルに生成された（サーバ生成）イベントが生じるのを待ち得る（ステップ９１９）。同様に、クライアントは、図９ｂに示すように、サーバからデータが到着するか、またはローカルに生成された（クライアント生成）イベントが生じるのを待ち得る（ステップ９０８）。
【０１４８】
図９ｂを参照すると、クライアントはその後、イベントを待つループに入り（ステップ９０８）、そのタイプに応じてイベントを処理する（ステップ９０９）。イベントがＧＥＴソケットから生じているイベントの場合、クライアントはまず、そのイベントがソケットエラーであるかどうかをチェックする（ステップ９１１）。そうである場合、クライアントは、ＧＥＴおよびＰＯＳＴソケットのその端部をクローズして（ステップ９１５）、事実上サーバとの通信セッションをクローズし、ステップ９０２に、または代替としてステップ９０１に戻ることによりサーバとの新しいセッションを作成しようとする（図示せず）。イベントがＧＥＴソケットから生じていて、エラーでないイベントの場合、クライアントは、ソケットから利用可能なデータを読み取り（ステップ９１２）、それを何らかの方法で処理する（ステップ９１３）。この処理は、ＰＯＳＴソケット経由でサーバに返送できる結果を生成し得る（ステップ９１４）。結果はゼロ結果であり得、その場合、サーバには何も返送されない。代替として、クライアントは、任意選択で、サーバに何も返送しないことを選択し得る。
【０１４９】
ステップ９１４でＰＯＳＴソケットを経由した結果送信が失敗し得る。少なくとも１つの故障モードはＨＴＴＰプロトコル違反である。すなわち、一旦、クライアントがコンテンツ長バイトをサーバに送信すると、ＰＯＳＴソケット上でさらに多くのバイトを送信することはＨＴＴＰプロトコル違反である。ＰＯＳＴソケット上でデータを送信しようとする後続の試行は失敗し、従って、クライアントはこのことおよび他の失敗をチェックする（ステップ９１６）。送信失敗が生じると、クライアントはこの送信に対するデータを保留としてマーキングして（ステップ９１７）、ＰＯＳＴソケットをクローズする（ステップ９１８）。クライアントは次いで、ステップ９０４に戻ることにより、ＰＯＳＴソケットを再オープンしようとする。この場合、それはセッション全体を終了して保留中の送信を失わせるので、クライアントは、ＧＥＴソケットをクローズして再オープンすべきではない。ＰＯＳＴソケットを再オープンすることにより、たとえソケット再接続が行われても、クライアントおよびサーバは、それらのセッションを維持する。
【０１５０】
クライアントがイベントを内部で、またはユーザ活動、タイマ、もしくはステップ９０９でサーバとの通信を必要とする他の外部的なスティミュラスの結果として、生成する場合、クライアントは、サーバに送信されるデータを計算するために必要な何らかの処理を実行する（ステップ９１０）。このデータが事実上、イベントの結果データであり、それは次いでサーバに送信されて（ステップ９１４）、ソケットイベントからの結果データに対するのと同じ送信方法を辿る。
【０１５１】
クライアントは、無期限にループして、サーバへの接続を確立し、機能しなくなった場合にはその接続を再確立し得る。クライアントは、失敗および再接続状態をユーザもしくは他のプログラムにシグナル通知することを選択し得るか、または通知することなく単にサーバに再接続し得る。
【０１５２】
ステップ９０７の後、図９ｃに示すように、サーバもループに入り、そこで、ステップ９１９でイベントを待ち、そのタイプに応じてイベントを処理する（ステップ９２０）。イベントがＰＯＳＴソケットから生じているイベントの場合、サーバはまず、そのイベントがソケットエラーであるかどうかをチェックする（ステップ９２２）。イベントがソケットエラーである場合、サーバは、ＰＯＳＴソケットのその端部をクローズして（ステップ９２３）、事実上、クライアントがそのＰＯＳＴソケットを再確立することを要求する。これは、クライアントが、２つの通信ソケットの１つを再確立することだけで、サーバとのそのセッションを維持できるようにする。イベントがＰＯＳＴソケットから生じていて、エラーでないイベントの場合、サーバは、ソケットから利用可能なデータを読み取り（ステップ９２４）、それを何らかの方法で処理する（ステップ９２５）。この処理は、ＧＥＴソケット経由でクライアントに返送できる結果を生成し得る（ステップ９２６）。結果はゼロ結果であり得、その場合、クライアントには何も返送されない。代替として、サーバは、任意選択で、クライアントに何も返送しないことを選択し得る。
【０１５３】
ステップ９２６でＧＥＴソケットを経由した結果送信が失敗し得る。サーバは、送信失敗をチェックし（ステップ９２７）、送信失敗が生じた場合、サーバは、ＰＯＳＴおよびＧＥＴソケットの両方をクローズして、事実上セッションを終了する（ステップ９２８）。サーバはクライアントとの接続を再確立しようとするのではなく、クライアントが、必要ならば、接続を再確立するのを待つ。これにより、事実上、クライアント／サーバシステムがステップ９０２に、代替として、ステップ９０１に戻る（図示せず）。いくつかの実施態様では、複数のセッションを通じて同じＧＵＩＤを維持することが望ましくあり得るが、これは必須の機能ではない。
【０１５４】
サーバが内部で、またはユーザ活動、タイマ、別の接続クライアント、データソースからのデータ、もしくはステップ９１９でクライアントとの通信を必要とする他の外部的なスティミュラスの結果として、イベントを生成する場合、サーバは、クライアントに送信されるデータを計算するために必要な何らかの処理を実行する（ステップ９２１）。このデータが事実上、イベントの結果データであり、それは次いでクライアントに送信されて（ステップ９２６）、ソケットイベントからの結果データに対するのと同じ送信方法を辿る。
【０１５５】
当業者には容易に理解されるように、オープンしているソケットをクローズしてステップ９０１での接続プロセスを再スタートし得るステップ９０１〜９０７において、エラー処理があり得る。これらのエラー処理は、明確にするために、図９では示されていないが、好ましい実施形態に含まれ得る。当業者には理解されるように、クライアントは、接続を終了すること（例えば、ブラウザクライアントのクローズ）を選択し得、任意のかかる終了は、送信エラーと同じ方法でサーバによって処理され得る。すなわち、サーバは、ＧＥＴおよびＰＯＳＴソケットの両方をクローズして、セッションを終了し、クライアントが接続するのを待つ（ステップ９００）。
【０１５６】
クライアントおよびサーバは、同期待ちを実行する新しい処理スレッドを作成するか、または単一スレッド内で複数のイベント待ちを実行するなど、任意の数の方法で待ち状態を実装できる。これらは、クライアントおよびサーバ実装中に行われた選択によって決まる実装詳細であるが、本発明の範囲から逸脱しない。
【０１５７】
驚くべきことに、本発明の実質的な利益は、ＨＴＴＰプロトコルにおける制約を克服し、また既存のブラウザおよびＲＩＡ技術との操作性も維持しながら、ＨＴＴＰまたはＨＴＴＰＳを介したソケットを使用して、クライアントとサーバとの間に高速な双方向通信を提供する能力である。
【０１５８】
代替実施形態では、本発明および双方向通信方法は、ＲＩＡを採用しているウェブクライアント／サーバにも適用可能である。
【０１５９】
好都合にも、本発明は、ＨＴＴＰまたはＨＴＴＰＳを介したソケットをオープン可能な任意の装置上で動作可能である。例えば、クライアント／サーバ実装は、既存のインフラ（例えば、セキュリティポリシー、ファイアウォール、ソフトウェア、ハードウェアなど）における大きな、従って費用のかかる変更なしで、データを実時間でネットワークまたはインターネットを通じて、任意選択でＨＴＴＰＳを介した安全な方法で、伝搬する複数のサーバを含み得る。
【０１６０】
図１０を参照すると、ネットワーク１００７によって分離されたサーバ１００２とクライアント１００１との間に直接通信を提供するための従来技術システムが、従来のＳＣＡＤＡシステムによって描かれるように、示されている。この実装例では、サーバ１００２およびクライアント１００１は、ネットワーク１００７上の任意の第３者（図示せず）からの許可されていないアクセスを防ぐために、ファイアウォール１００３、１００４の背後に置かれている。矢印１００６は、サーバ１００２上に置かれたデータに対する要求を出しているクライアント１００１をシンボル的に示し、矢印１００５は、クライアント１００１からの着信要求を待っているサーバ１００２を示す。クライアント１００１がサーバ１００２上のデータにアクセスするために、サーバのファイアウォール１００３は、ファイアウォール１００３の外側からの入接続を許可するように構成される必要がある。この例では、サーバ１００２は、ネットワーク１００７から生じている着信要求にさらされており、従って、ファイアウォール１００３は、利用され得る攻撃場所または脆弱性をもたらす。
【０１６１】
ネットワーク１００７がプライベートネットワークである場合、ファイアウォール１００３上のオープンしたポートを通じたサーバ１００２への悪意のある一斉攻撃の可能性は低く、許容リスクであると仮定する。しかし、ネットワーク１００７が公衆ネットワーク（例えば、インターネット）である場合、サーバ１００２への一斉攻撃の可能性は高く、リスクは容認できない。
【０１６２】
図１１を参照すると、一実施形態において、ネットワーク１１０７を通して安全な実時間データを提供するためのシステムが示されている。図１０に示す従来技術システムとは対照的に、図１１に示す新規のシステムでは、直接のクライアント／サーバ接続と、本発明によって提供されるようなクラウドベースシステムとの差を図解する。
【０１６３】
本発明では、クラウドサーバ１１００は、信頼できるクライアントとして機能する、サーバ１１０２と、ユーザクライアント１１０１（信頼できない）の両方から離れて位置付けられる。サーバ１１０２およびクライアント１１０１の両方が、矢印１１０５および１１０６で示すように、それらそれぞれのファイアウォール１１０３、１１０４を通して、クラウドサーバ１１００へのアウトバウンド接続を開始する。ファイアウォール１１０３、１１０４は、任意のオープンされたインバウンドポートを提供するように要求されない。この構成は、サーバ１１０２とクライアント１１０１との間のネットワーク１１０７がプライベートか公衆ネットワークかに関わらず、同等に安全である。
【０１６４】
サーバまたは信頼できるクライアント１１０２は、どのデータをクラウドサーバ１１００に送信するかを決定する。さらに、各サーバ１１０２は、各データストリームを一方向または双方向に設定でき、その必要性に応じて、そのデータの一部または全部を送信できる。好ましくは、この構成は、上述したソフトウェアアプリケーション（ＤａｔａＨｕｂ）の形で提供される、コネクタを用いて、信頼できるクライアントにおいて顧客によって設定される。その結果、構成は、クラウドサーバにおいてではなく、コネクタ内で完全に設定され得、それにより、任意選択で、クラウドサーバが不正アクセスされても、追加のセキュリティの層を提供する。
【０１６５】
図１１には、信頼できるクライアントとして機能する複数のサーバ１１０２も示されており、それは、本発明によって恐らくなされる予期しない結果である。具体的には、本発明は、複数のサーバ１１０２が、それら自身のデータセットに対して信頼できるクライアントとして機能して（図示せず）、クラウドサーバ１１０２において１つ以上のクライアント１１０１による効率的な消費のために統合されるのを可能にする。驚くべきことに、これは、クラウドサーバにおいて設定されたデータセットを生成し、それにより、クライアント（複数可）１１０１が、その統一されたデータセットを、あたかもそれが単一システムから生成されたかのように見せながら、サーバ１１０２が、物理的に互いに離れた位置（例えば、世界中に設置された異なるプラント設備内）に配置されるのを可能にする。すなわち、分散システムは、クライアントには単一システムのように見える。かかる機能は従来のＳＣＡＤＡシステムでは可能でない。これは、少なくとも便宜を提供し、システムのネットワーク全体を同時に監視して、サーバ１１０２間でデータを共有するための能力を提供することは好都合である。かかる用途の例は広く、例えば、車両群の協調オペレーション、装置のネットワーク、グローバルな金融取引システムおよび冗長並列システムなどがある。
【０１６６】
信頼できるクライアント（サーバ１１０２）がクラウドサーバ１１００に接続する場合、信頼できるクライアントは、信頼できるクライアント１１０２が公開しようとするデータ項目をサーバ１１００が含むかどうか、また、それらのデータ項目がサーバ１１００内のどこに存在するかを知らず、クライアント１１０１はそれらの現在の値を知らない。通常、クライアントは、項目およびそれらの値を提供するサーバに依存するが、信頼できるクライアント１１０２の場合、項目およびそれらの値を提供する必要があるのはクライアント１１０２である。従って、最初の接続が行われると、信頼できるクライアント１１０２はそのデータセット全体および現在の値を放出して、サーバ１１００に既に存在する値を無視して上書きする必要がある。本発明は、任意選択で、この挙動を提供して、任意のクライアントが、特定のデータセットに対してそれが信頼できるかどうかを選択できるようにする。
【０１６７】
同様に、信頼できるクライアント１１０２がクラウドサーバ１１００から切断されると、それは他の接続クライアントに、そのデータの信頼できるソースがもはやデータを提供していないことを通知することが可能でなければならない。信頼できるクライアント１１０２はサーバに、それが信頼できることを通知し、追加として、クライアントが切断される際にそれらのデータ項目が「接続されていない」ことを示すために、サーバ１１００に指示してサーバ内のデータ項目のプロパティを変更させる。データ項目が「接続されていない」とマーキングされる前に信頼できるクライアントが既に切断されているので、クラウドサーバ１１００は、このプロセスにおいて協働する必要があり、サーバは（時々「品質」と呼ばれる）この状態変更を他の接続クライアントに伝搬する必要がある。
【０１６８】
これらの重要な特徴を組み合わせると、サーバ１１００上のデータが信頼できるクライアント１１０２上のデータと一致するか、または信頼できるクライアント１１０２がクラウドサーバ１１００に接続されていないことを示す既知のエラー状態のいずれかであることを確実にする。
【０１６９】
図１２を参照すると、別の実施形態において、図１１に示したものに類似したシステムが、より視覚的に説明する方法で、示されている。特に、サーバの例示的なタイプに、組込み機器、ＳＣＡＤＡシステムまたは接続された様々な消費者製品が含まれており、全てがデータを生成、伝搬、送信および／または受信する（あるものは実時間で、あるものは実時間ではない）。図１２に示すように、これらの装置は、着信ファイアウォールポートをオープンすることなく、ファイアウォールの背後にあり、それによって、公衆ネットワーク上の自称ハッカー（図示せず）からの直接攻撃を排除する。同じ公衆ネットワーク上で、安全なクラウドサーバは、ファイアウォールを横切ってクラウドサーバに達する大きな矢印でシンボル的に示されるように、ファイアウォールの背後の装置によって開始されたアウトバウンド接続を受け取り得る。大きな矢印内では、データは安全に装置に返送され得る。
【０１７０】
本発明の別の態様も図１２に示されており、それによって、クラウドサーバは、予測保守もしくはＨＭＩ表示のため、データ分析（例えば、主要な性能指数の生成）のためにデータをＲＩＡに、もしくはデータベースに送信するため、またはアラートを提供するため（例えば、電子メールもしくはＳＭＳを用いて）に、上述した方法を採用し得る。
【０１７１】
別の実施形態（図示せず）では、ファイアウォールは、ネットワーク上のサーバ、クライアントまたは装置の前に提供されておらず、その場合、サーバ／クライアント／装置は、インバウンド接続要求を拒絶するように構成される。これは、ファイアウォールの背後にあるサーバ／クライアント／装置へのインバウンド接続要求を無視するファイアウォールを採用するのと対比される。この実施形態では、サーバ／クライアント／装置のオペレーティングシステムは、曲がりなりにも、「誰もリッスンしていない」応答で、インバウンド接続要求に応答する。この構成はファイアウォールを採用するよりも安全ではない可能性があるが、サーバ／クライアント／装置が、ファイアウォールを含めることが可能でないポイントに、リソースが制約されるような状況がある。驚くべきことに、本発明は、このようにリソースに制約のある装置との通信の、より安全な方法を提供するための方法を提供する。
【０１７２】
例えば、サーバとクライアントとの間に存在するネットワークに言及する場合、ネットワーク自体は、一連のネットワーク接続を含み得る、すなわち、直接接続の含意はないことが理解されるはずである。同様に、インターネット「上」の任意のサーバ、クライアントまたは装置は、インターネットにアクセス可能なネットワーク接続に接続されているサーバ、クライアントまたは装置を意味すると理解される。
【０１７３】
データセットに関する権限、またはデータセットの信頼できる所有者は、データセットの作成者を指し、データセットの他の全ての受信側は信頼できないコピーを保持することも理解されたい。本発明では、サーバ、クライアントまたは装置は、別のサーバ、クライアントまたは装置から権限を継承でき；例えば、クラウドサーバは、別のクライアント／エンドユーザ装置に対するデータセットに関して権限として機能し得；クライアント／エンドユーザ装置は、クラウドサーバをそのデータセットに関する権限として見るが、クライアント／エンドユーザ装置に知られておらず、クラウドサーバはデータをクラウドサーバに接続された「真の」信頼できるクライアント／エンドユーザ装置から伝搬し得る。本発明は、無数の相互に接続されたサーバ、クライアント、および装置の組合せが、それらの間で共有された複数のデータセットにわたり権限の継承を可能にすることを理解されたい。
【図１】
0006689838.tif 000002
【図２】
0006689838.tif 000003
【図３】
0006689838.tif 000004
【図４】
0006689838.tif 000005
【図５ａ】
0006689838.tif 000006
【図５ｂ】
0006689838.tif 000007
【図６】
0006689838.tif 000008
【図７】
0006689838.tif 000009
【図８】
0006689838.tif 000010
【図９ａ】
0006689838.tif 000011
【図９ｂ】
0006689838.tif 000012
【図９ｃ】
0006689838.tif 000013
【図１０】
0006689838.tif 000014
【図１１】
0006689838.tif 000015
【図１２】
0006689838.tif 000016