(57)【特許請求の範囲】
【請求項１】
サーバデバイスであって、該サーバデバイスが少なくともひとつのプロセッサとメモリとを有する第１処理システムを含み、該メモリがキャッシュを含み、前記第１処理システムが、
ウェブアプリケーションによって提供されるユーザインタフェースに表示可能な複数のウィジェットのデータを、複数のユーザのそれぞれについて、保持するよう前記キャッシュを設定することと、
前記ユーザインタフェースがクライアントデバイスで起動されたことに応じて、前記複数のウィジェットのうちのひとつ以上についての前記キャッシュのリフレッシュを開始することと、
前記開始されたリフレッシュに応じて前記キャッシュが更新される前に前記ウィジェットのうちのひとつ以上についての前記キャッシュから取得されたデータの第１集合を前記クライアントデバイスに送信し、その後、前記開始されたリフレッシュに応じて前記キャッシュが更新された後に前記ひとつ以上のウィジェットのうちの少なくともいくつかについての前記キャッシュから取得されたデータの第２集合を前記クライアントデバイスに送信することと、を含む動作を行うよう構成される、サーバデバイスと、
クライアントデバイスであって、該クライアントデバイスが少なくともひとつのプロセッサとディスプレイデバイスとネットワーク通信インタフェースとを有する第２処理システムを含み、該ネットワーク通信インタフェースが前記サーバデバイスとの通信用に構成されており、前記第２処理システムが、
ウェブアプリケーションによって提供されるユーザインタフェースを表示するための要求を受信することであって、前記ユーザインタフェースがそこに配置される複数のウィジェットを有するよう構成される、受信することと、
前記ユーザインタフェースを表示するための前記要求を受信した後に前記サーバデバイスに送信される第１データ要求に応じて、データの前記第１集合を受信することと、
前記第１データ要求の後に前記サーバデバイスに送信される第２データ要求に応じて、データの前記第２集合を受信することと、
データの前記第２集合を用いて前記ディスプレイデバイスに前記ユーザインタフェースを表示することと、を含む動作を行うよう構成される、クライアントデバイスと、を備え、
前記表示することは、前記ウィジェットのうちのひとつ以上について、データの前記第１集合を用いて以前に表示された情報を上書きすることを含むシステム。
【請求項２】
前記クライアントデバイスは、前記ウィジェットのうちの少なくともひとつについてのデータ要求を繰り返し送信することであって、前記ウィジェットのうちの少なくともひとつについて直近に返ってきたデータが、前記少なくともひとつのウィジェットについて前記キャッシュが更新される前の前記キャッシュからのものである、送信することを含むさらなる動作を行うよう構成される請求項１に記載のシステム。
【請求項３】
前記キャッシュのリフレッシュを開始することは前記リフレッシュを非同期的に行うことを含む請求項２に記載のシステム。
【請求項４】
前記サーバデバイスは、
前記クライアントデバイスからのデータ要求を受信することに応じて、データ要求の繰り返し数が設定しきい値を上回ったか判定することと、
前記繰り返しデータ要求が前記しきい値を上回った場合、データソースに直接アクセスしてデータを取得することと、
前記クライアントデバイスに取得データを返すことと、を含むさらなる動作を行うよう構成される請求項２に記載のシステム。
【請求項５】
前記ユーザインタフェースは、複数のウィジェットが配置されたダッシュボードを含む請求項１から４のいずれか一項に記載のシステム。
【請求項６】
前記クライアントデバイスは、再試行数を示すものを含む形で各データ要求を送信するよう構成され、
前記サーバデバイスは、各データ要求に関連付けられた前記再試行数の値のそれぞれに対して異なるアクションを行うよう構成される請求項１から５のいずれか一項に記載のシステム。
【請求項７】
前記サーバデバイスは、
前記リフレッシュを開始するとき、前記キャッシュ内のウィジェットのデータ状態を示す少なくともひとつのフラグを設定することと、
所定の再試行数に対応する再試行数を有するデータ要求を受信することに応じて、（１）前記少なくともひとつのフラグが設定されていない場合、前記キャッシュのリフレッシュを開始すると共に前記少なくともひとつのフラグを設定し、（２）前記少なくともひとつのフラグが設定されている場合、前記キャッシュからのデータを前記クライアントデバイスに返すことと、を含むさらなる動作を行うよう構成される請求項６に記載のシステム。
【請求項８】
前記サーバデバイスは、第１再試行数を伴うデータ要求を受信することに応じて前記キャッシュの非同期リフレッシュを開始し、第２再試行数を伴うデータ要求を受信することに応じて前記キャッシュの同期更新を開始するよう構成され、前記第１再試行数と前記第２再試行数とは異なる請求項６に記載のシステム。
【請求項９】
前記クライアントデバイスは、
前記ユーザインタフェースに配置された複数のウィジェットのキャッシュ期限を監視することと、
前記監視に基づいて、前記ウィジェットのうちの第１ウィジェットのキャッシュデータの失効を判定することと、
前記ウィジェットのうちの前記第１ウィジェットについての前記キャッシュ内のデータをリフレッシュさせることと、を含むさらなる動作を行うよう構成される請求項１から８のいずれか一項に記載のシステム。
【請求項１０】
前記第１処理システムは、
複数のウィジェットのそれぞれについての対応する更新タイマを保持することと、
前記更新タイマを監視することと、
ウィジェットの更新の期限がくると、更新を要求することと、を含むさらなる動作を行うよう構成される請求項１から９のいずれか一項に記載のシステム。
【請求項１１】
キャッシュ用のメモリと、少なくともひとつのプロセッサを有する処理システムと、を備えるサーバデバイスであって、
前記処理システムが、
ウェブアプリケーションによって提供されるユーザインタフェースに表示可能な複数のウィジェットのデータを、複数のユーザのそれぞれについて、保持するよう前記キャッシュを設定することと、
前記ユーザインタフェースがクライアントデバイスで起動されたことに応じて、前記複数のウィジェットのうちのひとつ以上についての前記キャッシュのリフレッシュを開始することと、
前記開始されたリフレッシュに応じて前記キャッシュが更新される前に前記ウィジェットのうちのひとつ以上についての前記キャッシュから取得されたデータの第１集合を前記クライアントデバイスに送信し、その後、前記開始されたリフレッシュに応じて前記キャッシュが更新された後に前記ひとつ以上のウィジェットのうちの少なくともいくつかについての前記キャッシュから取得されたデータの第２集合を前記クライアントデバイスに送信することと、を含む動作を行うよう構成されるサーバデバイス。
【請求項１２】
ディスプレイデバイスと、サーバデバイスと通信するよう構成されたネットワーク通信インタフェースと、少なくともひとつのプロセッサを有する処理システムと、を備えるクライアントデバイスであって、
前記処理システムが、
ウェブアプリケーションのユーザインタフェースを表示するための要求を受信することであって、前記ユーザインタフェースがそこに配置される複数のウィジェットを有するよう構成される、受信することと、
前記ユーザインタフェースを表示するための前記要求を受信した後に前記サーバデバイスに送信される第１データ要求に応じて、データの第１集合を受信することと、
前記第１データ要求の後に前記サーバデバイスに送信される第２データ要求に応じて、データの第２集合を受信することと、
データの前記第２集合を用いて前記ディスプレイデバイスに前記ユーザインタフェースを表示することと、を含む動作を行うよう構成され、
前記表示することは、前記ウィジェットのうちのひとつ以上について、データの前記第１集合を用いて以前に表示された情報を上書きすることを含み、
データの前記第１集合は、前記ユーザインタフェースが前記クライアントデバイスで起動されることに応じて前記サーバデバイスにより開始されたキャッシュのリフレッシュによって前記キャッシュが更新される前に、前記ウィジェットのうちのひとつ以上についての前記キャッシュであって前記サーバデバイスにより設定される前記キャッシュから取得され、データの前記第２集合は、前記開始されたリフレッシュによって前記キャッシュが更新された後に前記キャッシュから取得されるクライアントデバイス。
【請求項１３】
ウェブアプリケーションによって提供されるユーザインタフェースに表示可能な複数のウィジェットのデータを、複数のユーザのそれぞれについて、コンピュータのメモリに保持するようキャッシュを設定することと、
前記ユーザインタフェースがクライアントデバイスで起動されたことに応じて、前記複数のウィジェットのうちのひとつ以上についての前記キャッシュのリフレッシュを開始することと、
前記開始されたリフレッシュに応じて前記キャッシュが更新される前に前記ウィジェットのうちのひとつ以上についての前記キャッシュから取得されたデータの第１集合を前記クライアントデバイスに送信し、その後、前記開始されたリフレッシュに応じて前記キャッシュが更新された後に前記ひとつ以上のウィジェットのうちの少なくともいくつかについての前記キャッシュから取得されたデータの第２集合を前記クライアントデバイスに送信することと、を含む方法。
【請求項１４】
ウェブアプリケーションのインストラクションを保持するコンピュータプログラムであって、前記インストラクションはコンピュータによって実行された場合、前記コンピュータに、
ウェブアプリケーションによって提供されるユーザインタフェースに表示可能な複数のウィジェットのデータを、複数のユーザのそれぞれについて、保持するよう、前記コンピュータのメモリ内のキャッシュを設定することと、
前記ユーザインタフェースがクライアントデバイスで起動されたことに応じて、前記複数のウィジェットのうちのひとつ以上についての前記キャッシュのリフレッシュを開始することと、
前記開始されたリフレッシュに応じて前記キャッシュが更新される前に前記ウィジェットのうちのひとつ以上についての前記キャッシュから取得されたデータの第１集合を前記クライアントデバイスに送信し、その後、前記開始されたリフレッシュに応じて前記キャッシュが更新された後に前記ひとつ以上のウィジェットのうちの少なくともいくつかについての前記キャッシュから取得されたデータの第２集合を前記クライアントデバイスに送信することと、を含む動作を行わせるコンピュータプログラム。
【請求項１５】
ウェブアプリケーションのインストラクションを保持するコンピュータプログラムであって、前記インストラクションはコンピュータによって実行された場合、前記コンピュータに、
前記ウェブアプリケーションのユーザインタフェースを表示するための要求を受信することであって、前記ユーザインタフェースがそこに配置される複数のウィジェットを有するよう構成される、受信することと、
前記ユーザインタフェースを表示するための前記要求を受信した後にサーバデバイスに送信される第１データ要求に応じて、データの第１集合を受信することと、
前記第１データ要求の後に前記サーバデバイスに送信される第２データ要求に応じて、データの第２集合を受信することと、
データの前記第２集合を用いてディスプレイデバイスに前記ユーザインタフェースを表示することと、を含む動作を行わせ、
前記表示することは、前記ウィジェットのうちのひとつ以上について、データの前記第１集合を用いて以前に表示された情報を上書きすることを含み、
データの前記第１集合は、前記ユーザインタフェースがクライアントデバイスで起動されることに応じて前記サーバデバイスによって開始されたキャッシュのリフレッシュによって前記ウィジェットのうちのひとつ以上についての前記キャッシュが更新される前に前記サーバデバイスによって設定される前記キャッシュから取得され、データの前記第２集合は、前記開始されたリフレッシュによって前記キャッシュが更新された後に前記キャッシュから取得されるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願へのクロスリファレンス
本願は、２０１５年７月３０日に出願されたインド特許出願第2346/DEL/2015号の優先権の利益を享受する。その出願の開示全体は、参照により本明細書に組み入れられる。
【背景技術】
【０００２】
多くの商用ソフトウエアアプリケーションはウェブベースアプリケーション（「ウェブアプリケーション」）として設計されており、その結果、それらはどこからでもアクセス可能であり、および／またはウェブブラウザを実行可能なほぼ全ての処理デバイスを用いてアクセス可能である。ウェブアプリケーションはクライアント側コンポーネントとサーバ側コンポーネントとを備え、それらはＨＴＴＰプロトコルを含むプロトコルを用いて互いに通信する。ウェブアプリケーションのクライアント側コンポーネントは、多くの場合、ユーザのアクセスデバイス上のユーザインタフェースを通じてユーザに情報を提供する（例えば、表示する）ことによってユーザインタフェースを扱うこと、ユーザ入力を受けること、等の責を負う。サーバ側コンポーネントはデータソースから情報を取得するか該情報を自身で生成することを含むタスクについて責を負う。該情報は受けた入力に従いユーザに提示されるものである。
【０００３】
基礎となるウェブアプリケーションの複雑さが増えるにつれて、サーバ側コンポーネントからクライアント側コンポーネントへ送信されるデータのボリュームも増大している。さらに、ユーザ数および／またはアプリケーションがアクセスされる頻度が増大するにつれて、サーバの処理負荷も増大しうる。サーバからクライアントデバイスへ送信されるデータボリュームの増大、処理負荷などによるサーバ遅延、および／またはリモートデータソースへのネットワークアクセスに関連するレイテンシにより、多くの場合、ウェブアプリケーションのユーザは長い応答時間に耐えなければならなくなる。
【０００４】
ユーザインタフェースが次回起動されたときに同じデータが素早く表示されるよう描画データをキャッシングすることを含む種々の技術を用いて、ユーザ体験を改善し、および／またはユーザインタフェースの性能を向上することができる。ダッシュボードの正確さおよび性能の両方を改善することによってウェブアプリケーションを強化するために、これらの技術をさらに改良することが望ましい。
【０００５】
著作権表示
本特許書類の開示の一部は著作権保護の対象となるものを含む。著作権者は、任意の者による本特許書類または本特許開示の特許商標庁にて現れる態様での複製について反対することはないが、そうでない場合は何であれ全ての著作権を留保する。
【発明の概要】
【０００６】
例示的な実施の形態は、キャッシュを含むサーバデバイスと、クライアントデバイスと、を備えるシステムを提供する。キャッシュは、クライアントデバイスのウェブアプリケーションによって提供されるユーザインタフェースに表示可能な複数のウィジェットのデータを、複数のユーザのそれぞれについて、保持するよう設定される。サーバデバイスは、前記ユーザインタフェースがクライアントデバイスで起動されたことに応じて、前記複数のウィジェットのうちのひとつ以上についての前記キャッシュのリフレッシュを開始することと、前記開始されたリフレッシュに応じて前記キャッシュが更新される前の前記ウィジェットのうちのひとつ以上についての前記キャッシュから取得されたデータの第１集合を前記クライアントデバイスに送信し、その後、前記開始されたリフレッシュに応じて前記キャッシュが更新された後の前記ひとつ以上のウィジェットのうちの少なくともいくつかについての前記キャッシュから取得されたデータの第２集合を前記クライアントデバイスに送信することと、を行うよう構成される。クライアントデバイスは、ウェブアプリケーションによって提供されるユーザインタフェースを表示するための要求を受信することであって、前記ユーザインタフェースがそこに配置される複数のウィジェットを有するよう構成される、受信することと、前記ユーザインタフェースを表示するための前記要求を受信した後に前記サーバデバイスに送信される第１データ要求に応じて、データの前記第１集合を受信することと、前記第１データ要求の後に前記サーバデバイスに送信される第２データ要求に応じて、データの前記第２集合を受信することと、データの前記第２集合を用いて前記ディスプレイデバイスに前記ユーザインタフェースを表示することと、を行うよう構成される。前記表示することは、前記ウィジェットのうちのひとつ以上について、データの前記第１集合を用いて以前に表示された情報を上書きすることを含む。
【０００７】
前記クライアントデバイスは、前記ウィジェットのうちの少なくともひとつについてのデータ要求を繰り返し送信することであって、前記ウィジェットのうちの少なくともひとつについて直近に返ってきたデータが、前記少なくともひとつのウィジェットについて前記キャッシュが更新される前の前記キャッシュからのものである、送信することを含むさらなる動作を行うよう構成されてもよい。
【０００８】
前記キャッシュのリフレッシュを開始することは前記リフレッシュを非同期的に行うことを含んでもよい。
【０００９】
サーバデバイスは、前記クライアントからのデータ要求を受信することに応じて、データ要求の繰り返し数が設定しきい値を上回ったか判定することと、前記繰り返しデータ要求が前記しきい値を上回った場合、データソースに直接アクセスしてデータを取得することと、前記クライアントデバイスに取得データを返すことと、を含むさらなる動作を行うよう構成されてもよい。
【００１０】
前記ユーザインタフェースは、複数のウィジェットが配置されたダッシュボードを含んでもよい。
【００１１】
前記クライアントデバイスは、再試行数を示すものを含む形で各データ要求を送信するよう構成されてもよい。前記サーバデバイスは、各データ要求に関連付けられた前記再試行数の値のそれぞれに対して異なるアクションを行うよう構成されてもよい。
【００１２】
サーバデバイスは、前記リフレッシュを開始するとき、前記キャッシュ内のウィジェットのデータ状態を示す少なくともひとつのフラグを設定することと、所定の再試行数に対応する再試行数を有するデータ要求を受信することに応じて、（１）前記少なくともひとつのフラグが設定されていない場合、前記キャッシュのリフレッシュを開始すると共に前記少なくともひとつのフラグを設定し、（２）前記少なくともひとつのフラグが設定されている場合、前記キャッシュからのデータを前記クライアントデバイスに返すことと、を含むさらなる動作を行うよう構成されてもよい。
【００１３】
前記サーバデバイスは、第１再試行数を伴うデータ要求を受信することに応じて前記キャッシュの非同期リフレッシュを開始し、第２再試行数を伴うデータ要求を受信することに応じて前記キャッシュの同期更新を開始するよう構成されてもよい。前記第１再試行数と前記第２再試行数とは異なってもよい。
【００１４】
クライアントデバイスは、前記ユーザインタフェースに配置された複数のウィジェットのキャッシュ期限を監視することと、前記監視に基づいて、前記ウィジェットのうちの第１ウィジェットのキャッシュデータの失効を判定することと、前記ウィジェットのうちの前記第１ウィジェットについての前記キャッシュ内のデータをリフレッシュさせることと、を含むさらなる動作を行うよう構成されてもよい。
【００１５】
サーバデバイスは、複数のウィジェットのそれぞれについての対応する更新タイマを保持することと、前記更新タイマを監視することと、ウィジェットの更新の期限がくると、更新を要求することと、を含むさらなる動作を行うよう構成されてもよい。
【００１６】
他の実施の形態は、キャッシュ用に構成されたメモリを備えるサーバデバイスを提供する。サーバデバイスは、ウェブアプリケーションによって提供されるユーザインタフェースに表示可能な複数のウィジェットのデータを、複数のユーザのそれぞれについて、保持するよう前記キャッシュを設定することと、前記ユーザインタフェースがクライアントデバイスで起動されたことに応じて、前記複数のウィジェットのうちのひとつ以上についての前記キャッシュのリフレッシュを開始することと、前記開始されたリフレッシュに応じて前記キャッシュが更新される前の前記ウィジェットのうちのひとつ以上についての前記キャッシュから取得されたデータの第１集合を前記クライアントデバイスに送信し、その後、前記開始されたリフレッシュに応じて前記キャッシュが更新された後の前記ひとつ以上のウィジェットのうちの少なくともいくつかについての前記キャッシュから取得されたデータの第２集合を前記クライアントデバイスに送信することと、を含む動作を行うよう構成される。
【００１７】
他の実施の形態は、ディスプレイデバイスと、サーバデバイスと通信するよう構成されたネットワーク通信インタフェースと、を備えるクライアントデバイスを提供する。サーバデバイスは、ウェブアプリケーションのユーザインタフェースを表示するための要求を受信することであって、前記ユーザインタフェースがそこに配置される複数のウィジェットを有するよう構成される、受信することと、前記ユーザインタフェースを表示するための前記要求を受信した後に前記サーバデバイスに送信される第１データ要求に応じて、データの第１集合を受信することと、前記第１データ要求の後に前記サーバデバイスに送信される第２データ要求に応じて、データの第２集合を受信することと、データの前記第２集合を用いて前記ディスプレイデバイスに前記ユーザインタフェースを表示することと、を含む動作を行うよう構成される。前記表示することは、前記ウィジェットのうちのひとつ以上について、データの前記第１集合を用いて以前に表示された情報を上書きすることを含む。データの前記第１集合は、前記ユーザインタフェースが前記クライアントデバイスで起動されることに応じて開始された前記キャッシュのリフレッシュによって前記キャッシュが更新される前の前記ウィジェットのうちのひとつ以上についてのキャッシュから取得されてもよい。データの前記第２集合は、前記開始されたリフレッシュによって前記キャッシュが更新された後の前記キャッシュから取得されてもよい。
【００１８】
他の例示的な実施の形態は、ウェブアプリケーションによって提供されるユーザインタフェースに表示可能な複数のウィジェットのデータを、複数のユーザのそれぞれについて、コンピュータのメモリに保持するようキャッシュを設定することと、前記ユーザインタフェースがクライアントデバイスで起動されたことに応じて、前記複数のウィジェットのうちのひとつ以上についての前記キャッシュのリフレッシュを開始することと、前記開始されたリフレッシュに応じて前記キャッシュが更新される前の前記ウィジェットのうちのひとつ以上についての前記キャッシュから取得されたデータの第１集合を前記クライアントデバイスに送信し、その後、前記開始されたリフレッシュに応じて前記キャッシュが更新された後の前記ひとつ以上のウィジェットのうちの少なくともいくつかについての前記キャッシュから取得されたデータの第２集合を前記クライアントデバイスに送信することと、を含む方法を提供する。
【００１９】
他の実施の形態は、ウェブアプリケーションのインストラクションを保持する非一時的コンピュータ可読保持媒体を提供する。前記インストラクションはコンピュータによって実行された場合、前記コンピュータに動作を行わせる。動作は、ウェブアプリケーションによって提供されるユーザインタフェースに表示可能な複数のウィジェットのデータを、複数のユーザのそれぞれについて、保持するよう、前記コンピュータの前記メモリ内のキャッシュを設定することと、前記ユーザインタフェースがクライアントデバイスで起動されたことに応じて、前記複数のウィジェットのうちのひとつ以上についての前記キャッシュのリフレッシュを開始することと、前記開始されたリフレッシュに応じて前記キャッシュが更新される前の前記ウィジェットのうちのひとつ以上についての前記キャッシュから取得されたデータの第１集合を前記クライアントデバイスに送信し、その後、前記開始されたリフレッシュに応じて前記キャッシュが更新された後の前記ひとつ以上のウィジェットのうちの少なくともいくつかについての前記キャッシュから取得されたデータの第２集合を前記クライアントデバイスに送信することと、を含む。
【００２０】
他の例示的な実施の形態は、ウェブアプリケーションのインストラクションを保持する非一時的コンピュータ可読保持媒体を提供する。前記インストラクションはコンピュータによって実行された場合、前記コンピュータに、前記ウェブアプリケーションのユーザインタフェースを表示するための要求を受信することであって、前記ユーザインタフェースがそこに配置される複数のウィジェットを有するよう構成される、受信することと、前記ユーザインタフェースを表示するための前記要求を受信した後に前記サーバデバイスに送信される第１データ要求に応じて、データの第１集合を受信することと、前記第１データ要求の後に前記サーバデバイスに送信される第２データ要求に応じて、データの第２集合を受信することと、データの前記第２集合を用いて前記ディスプレイデバイスに前記ユーザインタフェースを表示することと、を含む動作を行わせる。前記表示することは、前記ウィジェットのうちのひとつ以上について、データの前記第１集合を用いて以前に表示された情報を上書きすることを含む。データの前記第１集合は、前記ユーザインタフェースが前記クライアントデバイスで起動されることに応じて開始された前記キャッシュのリフレッシュによって前記ウィジェットのうちのひとつ以上についての前記キャッシュが更新される前のキャッシュから取得されてもよい。データの前記第２集合は、前記開始されたリフレッシュによって前記キャッシュが更新された後の前記キャッシュから取得される。
【００２１】
本概要は、発明の詳細な説明で以下にさらに説明される単純化された概念の選択を紹介するために提供される。本概要は、クレームに係る主題の主要な特徴または不可欠な特徴を識別することと、或いは、クレームに係る主題の範囲を限定するために用いられることとのいずれをも意図するものではなく、むしろ本概要は本書面で説明される主題の概観を提供することを意図するものである。したがって、上述した特徴は例示にすぎず、本明細書で説明される主題の他の特徴、態様、および利点は、後述する詳細な説明、図面、および請求項から明らかになるであろうということは理解されたい。
【図面の簡単な説明】
【００２２】
【図１】ある実施の形態に係る、例示的なウェブベースアプリケーションのダッシュボードを示す。
【００２３】
【図２】例えば図１のアプリケーションのようなウェブアプリケーションをユーザが使用できるようにするために、クライアントシステムとサーバシステムとがネットワークを介して互いに通信する例示的な計算環境を示す。
【００２４】
【図３Ａ】図３（３Ａおよび３Ｂ）は、ある実施の形態に係る、サーバ側キャッシュを用いて情報を描画するための処理のフローチャートを示す。
【図３Ｂ】図３（３Ａおよび３Ｂ）は、ある実施の形態に係る、サーバ側キャッシュを用いて情報を描画するための処理のフローチャートを示す。
【００２５】
【図４】ある実施の形態に係る、サーバ側キャッシュをリフレッシュするための処理のフローチャートを示す。
【００２６】
【図５】ある実施の形態に係る、ダッシュボードなどの表示ユーザインタフェースを設定するために使用可能な例示的ＸＭＬ設定ファイルの一部を示す。
【００２７】
【図６】ある実施の形態に係る、例示的なユーザインタフェースレイアウト設定のＸＭＬファイルを示す。
【００２８】
【図７】ある実施の形態に係る、サーバ側キャッシュを実装するために使用可能な例示的データベーススキームを示す。
【００２９】
【図８】ある実施の形態で使用されうるソフトウエア要素の例示的フレームワークの一部を模式的に示す。
【００３０】
【図９】ある実施の形態に係る、インタフェースクラスの例を示す。
【００３１】
【図１０】ある実施の形態に係る、図２に示されるシステムのハードウエアアーキテクチャの例示的ブロック図を示す。
【発明を実施するための形態】
【００３２】
本明細書で開示される実施の形態は、ウェブページの表示などのクライアント側ユーザインタフェースを、表示データを提供するためのサーバ側キャッシュを用いて、描画することに関する。ある例示的な実施の形態はインベスタリレーションウェブアプリケーション（「ＩＲアプリケーション」）に関するが、実施の形態はこれに限定されない。実施の形態に係るサーバ側キャッシュを用いると、ウェブページ描画の従来技術と比べて、ウェブアプリケーションの性能およびスケーラビリティを顕著に改善することができる。描画することが複数のデータソースから受信した情報でディスプレイを同時に更新することを含む場合に、性能の改善はより顕著となる。
【００３３】
例示的な実施の形態は、サーバ側キャッシュをバックグラウンドで非同期的にリフレッシュすることと、キャッシュされた情報を用いてクライアント側ユーザインタフェースを描画することと、を提供する。本明細書において、キャッシュをリフレッシュするとは、対応するデータソースからデータを取得し、取得データを新たにキャッシュに格納するかまたはキャッシュ内の現在の対応するデータを新たに取得したデータで置き換えることで、キャッシュを更新することを指す。クライアントからの要求を受けると、サーバは、キャッシュがバックグラウンドで非同期的にリフレッシュされている最中に、たとえ既存のキャッシュされたデータが最新のものでなくても、既存のキャッシュされたデータを返しうる。これにより、クライアントのディスプレイを、ユーザに関連がありそうではあるが必ずしも最新ではない少なくともいくらかのデータで、素早く更新することができる。続いて、典型的には初期表示の後の短期間内に、ディスプレイはキャッシュがリフレッシュされたときの最新の情報で更新される。少なくともいくらかの関連情報を所定のアプリケーションの起動時に素早く（例えば、ほぼ直ちに）表示させる能力は、ダッシュボードタイプのユーザインタフェースをよく利用するユーザにとって特に便利なものでありうる。ダッシュボード上のあるタイプの情報が常に完全に最新であることは重要ではない場合があるので、とても頻繁にダッシュボードに出入りするユーザは、ある関連情報が短い応答時間内に表示され、その後最新の情報で更新されることを好ましいと思うことがある。
【００３４】
本明細書において、ダッシュボードは、ユーザに情報を効果的に提示するために用いられるユーザインタフェースのタイプを指す。例えば、それは情報を整理して提示することで読みやすくする。ダッシュボードはいくつかのサブコンポーネントを含んでもよく、各サブコンポーネントは、個々異なる情報ピースおよび／または異なるデータソースから得られた情報ピースを表示するために用いられる。図１は、ある実施の形態に係る、例示的なＩＲアプリケーションのダッシュボード１００を示す。ダッシュボード１００は異なるデータソースからの複数タイプの情報をひとつのページに表示する。投資助言者が潜在的な投資家と相談しているときに、そのような情報を便利であると感じるであろう。ダッシュボード１００はコンテンツ集中的であり、多くのソースからコンテンツを集める。
【００３５】
ダッシュボード１００はコンポーネント１０２−１１０を含み、各コンポーネントは異なるソースからの情報を受けて表示するよう構成されたウィジェットであってもよい。本明細書において、ウィジェットなる用語は、ユーザが機能を実行するかまたはサービスにアクセスすることを可能とするアプリケーションまたはインタフェースのコンポーネントである。ウィジェット１０２−１１０のうちの少なくともいくつかは、ユーザの画面に初期表示された後、それらがユーザの画面において見える状態に維持されたまま、そのコンテンツ（内容）が継続的に更新されるよう設計されてもよい。
【００３６】
ウィジェット１０２は、特定の投資家のピアの金融パフォーマンスに関する情報を受けて表示するよう構成されてもよい。これは、各投資ポジションについて、値段情報、量情報、および値の変化情報を提供してもよい。その情報のうちのいくつか（例えば、値段、ボリューム等）は、データソースにおいて、連続的またはほぼ実時間で更新されてもよい。各ピアについてリサーチレポートや予想などの追加情報が利用可能であるか否かに関するインジケーションが提供されてもよく、それは動的にまたは周期的に更新されてもよい。ウィジェット１０４は特定の投資ポジションについてのより詳細な情報を表示してもよい。例えば、示されるように、１０２から選択された投資の値の実時間またはほぼ実時間チャートがウィジェット１０４に示されてもよい。ウィジェット１０６は特定の投資家に関する連絡先に関する情報を表示してもよい。ウィジェット１０８は特定の投資家に関係のあるハイライトを表示してもよい。ウィジェット１１０はフィードバックのサマリを提示してもよい。
【００３７】
ウィジェット１０２−１１０のうちの少なくともいくつかは外部ソースから得られたデータに依存し、あるウィジェットは外部ソースから受けた情報から導かれた情報を提示してもよい。例えば、投資ポジション値段等は第１外部購読サービスから受信されてもよいし、予想やリサーチレポート等に関する更新は第２購読サービスから得られてもよい。メッセージや投資ハイライト等に関する更新は、企業（すなわち、ユーザにウェブアプリケーションを展開している企業）自身のサーバから得られてもよい。タイプが異なること（例えば、異なるフォーマットやサイズ等）、更新要件が異なること（例えば、連続的またはほぼ連続的更新、間欠更新、スケジュールされた更新等）、および／またはウィジェットが表示用データを取得する先のソース（例えば、ローカルソース、異なるネットワークアクセスレイテンシを伴う外部ソース）が異なること、により引き起こされうる性能問題およびスケーラビリティ問題を軽減するように、実施の形態は作用する。
【００３８】
したがって、ダッシュボード１００はこれらの複数のウィジェットを同時に表示してもよい。これらのウィジェットは異なるソースからその情報を受ける。この場合、関連情報のサマリをユーザに提示することができる。ユーザが例示的なＩＲアプリケーションを起動したときに、ダッシュボード１００を「ランディングページ」としてユーザデバイスのディスプレイに描画することができる。例示的なＩＲアプリケーションのようなあるアプリケーションでは、全ての更新された情報が描画されるまで待つことで長い応答時間がかかるよりも、ユーザは、彼または彼女がアプリケーションを使用開始できる程度のいくらかの関連情報を初期に素早く表示させつつ、短い遅延の後に最新情報が得られることの方を好みうる。
【００３９】
図２は、例えば上述のＩＲアプリケーションのようなウェブアプリケーションをユーザが使用できるようにするために、クライアントシステム２０２とサーバシステム２０４とがネットワーク２０８を介して互いに通信する例示的な計算環境２００を示す。ネットワーク２０８がインターネットなどの相互に接続された計算デバイスのネットワークを含みうることは理解されるべきである。ネットワーク２０８はローカルエリアネットワーク（ＬＡＮ）を含んでもよく、および／またはクライアントシステム２０２とサーバシステム２０４との間のピアツーピア接続を含んでもよい。
【００４０】
ウェブアプリケーションは、クライアントシステム２０２で実行されるクライアント側ウェブアプリケーションコンポーネント（「クライアント側アプリケーション」）２１０と、サーバシステム２０４で実行されるサーバ側ウェブアプリケーションコンポーネント（「サーバ側アプリケーション」）２１２と、を含む。クライアント側アプリケーション２１０はブラウザ２１４などのユーザインタフェースアプリケーション２１４内で実行されてもよい。サーバ側アプリケーション２１２はサーバシステム２０４のウェブサーバ２１６および／またはアプリケーションサーバ２１８によって実行されてもよい。ウェブサーバ２１６は、ＨＴＴＰプロトコルを実装し、クライアントシステム２１０のウェブブラウザ２１４（後に詳述される）とＨＴＴＰを介して通信する機能などの機能を行う。設定データおよび／または性能データ、ユーザアクセスデータ等のウェブアプリケーション関連データアイテムはサーバシステム２０４のデータベース２２０に保持されてもよい。アプリケーションサーバ２１８は、例えば、サーバ側（または、「バックエンド」）アプリケーションサービスを実行できる。ウェブアプリケーションを実行する際、ウェブサーバ２１６および／またはアプリケーションサーバ２１８は、情報を取得するために、ネットワーク２０８を介して、ひとつ以上の外部データソース２２２にアクセスしてもよい。
【００４１】
サーバ側アプリケーション２１２はキャッシュ２２４およびジョブプロセス２２６を用いて情報をキャッシュし、キャッシュ２２４からクライアントシステム２０２へ情報を提供してもよい。そのような情報は例えばデータソース２２２から得られた情報、および／またはサーバシステム２０４で生成された情報である。サーバ側アプリケーション２１２はキュー２２５を用いることで、サーバ側アプリケーションによる要求に際してジョブプロセス２２６がキャッシュ２２４を非同期的にリフレッシュできるようにしてもよい。クライアントシステム２０２は、例えば、サーバ側アプリケーション２１２から受けた情報を、ダッシュボード２２８や他のウェブページを介してユーザに提供してもよい。
【００４２】
クライアントシステム２０２は、マルチプルシングルページアプリケーション（ＳＰＡ）や他のアーキテクチャに従い定義されるアプリケーションに関する処理を実行するためのソフトウエアコンポーネントを含んでもよい。非限定的な例として、クライアントシステム２０２は、描画モジュールとネットワーキングモジュールとジャバスクリプト（登録商標）モジュールと（個別には図示されていない）を少なくとも構成要素とするウェブブラウザアプリケーション２１４を有してもよい。描画モジュールは、グラフィカルディスプレイおよびウェブページの描画の機能を実装してもよい。例えば、それは、ウェブブラウザ２１４によって処理されたウェブページを定義するＨＴＭＬおよび／またはＤＯＭに対応するグラフィカルデータを生成することができる。このグラフィカルデータは、潜在的にはクライアントシステム２０２のオペレーティングシステムによるさらなる変更／変換の後に、クライアントシステム２０２のディスプレイに表示されてもよい。代替的にまたは追加的に、クライアントシステム２０２がウェブページを描画する／表示すると本明細書で記載されたときはいつでも、描画／表示モジュールがウェブページの描画／表示に関する機能を実行してもよい。ネットワーキングモジュールはＨＴＴＰプロトコルを実装し、クライアントシステム２０２とサーバシステム２０４内のウェブサーバ２１６との間の種々のＨＴＴＰメッセージを扱うために用いられてもよい。代替的にまたは追加的に、クライアントシステム２０２がＨＴＴＰを用いて通信すると本明細書で記載されたときはいつでも、ネットワーキングモジュールがそのような通信のＨＴＴＰ的側面を取り扱ってもよい。ジャバスクリプトモジュールは、ジャバスクリプトスクリプトを実行し、ジャバスクリプトオブジェクトを操作し、ウェブブラウザアプリケーション２１１にロードされたウェブページのＤＯＭを変更し、ジャバスクリプトに関する他の機能を実行するために用いられてもよい。ジャバスクリプトモジュールは、例えば、ジャバスクリプトエンジン、ジャバスクリプト仮想マシン、ジャバスクリプトランタイム、またはジャバスクリプトインストラクションを実行することができる任意の他のタイプのソフトウエアモジュールであってもよい。代替的にまたは追加的に、クライアントシステム２０２がジャバスクリプトに関する機能を実行すると本明細書で記載されたときはいつでも、そのような機能がジャバスクリプトモジュールによって取り扱われてもよい。
［０００１］
図３は、ある実施の形態に係る、サーバ側キャッシュ（例えば、キャッシュ２２４）を用いてクライアントユーザインタフェース情報を描画するための処理３００のフローチャートを示す。フローチャートは、ダッシュボード１００を含むウェブアプリケーションなどのクライアント側アプリケーション３０２と、ダッシュボード１００のウィジェットのサーバ側キャッシングを含むウェブアプリケーションの一部などのサーバ側アプリケーション３０４と、の間のやりとりを示す。以下の説明において、クライアント側アプリケーション３０２とサーバ側アプリケーション３０４との間で交換されるメッセージはＨＴＴＰプロトコルに従うメッセージを含む。少なくともある実施の形態では、クライアント側アプリケーション３０２はウェブブラウザの中で（そのコンテキストにおいて）実行される。
【００４３】
ユーザがウェブアプリケーションを起動したときおよび／またはユーザが特定のウェブページに到着すると、処理３００に入ってもよい。例えば、ユーザが例示的なＩＲアプリケーションを起動すると、処理３００に入り、「ランディングページ」としてのダッシュボード１００の表示が開始されてもよい。クライアント側アプリケーションモジュール２１０はサーバシステム２０４からユーザデバイスへダウンロードされてもよい。ＡｎｇｕｌａｒＪＳ（登録商標）モジュールを用い、ダッシュボード設定ファイル（例えば、図５および６）に定義されるコンポーネントに基づいてダッシュボードＡｎｇｕｌａｒＪＳアプリをロードするのを助けてもよい。オペレーション３１２において、クライアントからのモデルビューコントローラ（ＭＶＣ）アクションは、ダッシュボードの起動（またはダッシュボードをランディングページとして持つウェブアプリケーションの起動）をサーバに通知してもよい（例えば、ページロードＨＴＴＰ要求）。それに応じて、サーバはいくつかのアクション３１４を開始してもよい。オペレーション３１５で、サーバはクライアント側アプリケーションにクライアント側アプリケーションモジュール２１０を返してもよく、その結果ウェブアプリケーションが実行可能となる。
【００４４】
クライアントからＨＴＴＰウェブページ要求を受信し、クライアントでページを描画するおよび／またはアプリケーションを起動するためにＨＴＭＬ、ジャバスクリプトおよびＡｎｇｕｌａｒＪＳコンポーネントをクライアントにダウンロードする処理は、２０１６年７月２６日に提出されたUS15/219,913、タイトル「Software Application Framework」という同時係属中の譲受人共通の出願に記載されており、その出願の全体は参照により本願に組み入れられる。ブラウザ２１４のコンテキストにおいて、ダウンロードされたクライアント側アプリケーションモジュール２１０はダッシュボード１００の表示を始めてもよい。あるいはまた、以前にウェブアプリケーションを開始した後にユーザがダッシュボード１００を再表示するウェブページに返ってきたときに、ダッシュボード１００を表示するための処理が始められてもよい。例示的な実施の形態はクライアントブラウザコンテキストに関して説明されるが、実施の形態はＨＴＴＰを用いてサーバと通信する任意のクライアントアプリケーションと共に用いられてもよい。ある例示的な実施の形態では、クライアント側アプリケーションはＨＴＴＰおよびＪＳＯＮを用いてサーバ側アプリケーションと通信する。
【００４５】
サーバはダッシュボードに表示可能なウィジェットのデータを保持するためのキャッシュ（例えば、キャッシュ２２４）を含む。キャッシュは、特定のダッシュボード用の設定ファイルに規定されるように、特定のダッシュボードにより表示可能な個々全てのウィジェットのエントリを含んでもよい。キャッシュは最初、ウェブアプリケーションが起動されたときにサーバのメモリ（例えば、サーバシステム２０４のメモリ）内に設定されるか生成されてもよく、ユーザがダッシュボードから出て行った場合であってもウェブアプリケーションの継続期間（例えば、ユーザがログインしたままであることによって判定される）を通じて存続してもよい。あるいはまた、ウェブアプリケーションがアクティブである間であっても、ユーザがダッシュボードに戻ることなく所定の期間が経過した後にキャッシュを削除してもよい。図４に関連して後述されるように、キャッシュは、ダッシュボードでアクティブであるウィジェット用の間隔でリフレッシュされる。
【００４６】
サーバがダッシュボード１００の起動の通知を受けると、オペレーション３１６において、サーバはキュー３０６にキャッシュリフレッシュ要求を追加してもよい。サーバは、ダッシュボードの選択されたレイアウト（例えば、設定ファイルで規定されるもの）で配置される全てのウィジェットのデータのリフレッシュを要求してもよい。
【００４７】
ジョブプロセス３０８は、リフレッシュ要求が存在するかキュー３０６を周期的にポーリングする。ジョブプロセス３０８は、所定の間隔でキューをチェックするよう構成されてもよい。ある実施の形態では、リフレッシュ要求キュー３０６はＭＳＭＱ（登録商標）（マイクロソフトメッセージキューイング）であってもよく、ジョブプロセス３０８はウインドウズサービス（登録商標）ジョブであってもよい。ある実施の形態では、キューを監視する対応プロセス（例えば、ジョブプロセス３０８）がそのキューと同じサーバにある場合、ＭＳＭＱキューはプライベートキューとして定義されてもよい。しかしながら、実際のジョブプロセッサ（例えば、ジョブプロセッサ３０８）がサーバシステム内のいくつかの物理的マシンに亘って分散している場合、ある実施の形態は代わりにおよび／または追加的にリフレッシュ要求のためのパブリックＭＳＭＱキューを用いてもよい。ある実施の形態では、リフレッシュ要求のキュー３０６は先入れ先出し方式に従い動作する。この場合、より古い要求はより新しい要求の前に処理される。しかしながら、実施の形態はこれに限られず、他の実施の形態は他のキュー処理技術を実装してもよい。例えば、あるキュー処理技術は、あるウィジェットの要求（または、そのウィジェットを含む要求）を他のウィジェットの要求よりも高い優先度で処理してもよい。実施の形態では、ＭＳＭＱおよびウインドウズサービス技術を用いて、ユーザインタフェースを処理することに伴う負荷を任意の数のサーバに亘って分散させてもよい。これは、例えば、サーバシステム内の各サーバの対応するＭＳＭＱおよび対応するジョブプロセスをＩＲアプリケーションのバックエンドの一部として動作させることにより実現される。リフレッシュ要求をキューに入れるためのＭＳＭＱと、ジョブプロセス３０８のためのウインドウズサービスと、の組み合わせは、応答時間に影響を与えることなく、および／または、ウェブサーバの負荷を増やすことなく、キャッシュをリフレッシュすることを可能とする。
【００４８】
オペレーション３１７で、サーバは、ウィジェットのそれぞれについて、リフレッシュが開始されたこと（および対応するウィジェットのキャッシュデータが陳腐化したこと）を示すひとつ以上のフラグ（「陳腐フラグ」と称される）を設定する。すなわち、オペレーション３１６でキャッシュリフレッシュが要求されたウィジェットのそれぞれについて、少なくともひとつの陳腐フラグが設定される。各陳腐フラグは１ビットであってもよく、これは対応するウィジェットのデータが陳腐であるか否かを示すのに十分である。しかしながら、ある実施の形態では、ある陳腐フラグは少なくとも２ビットであってもよい。この場合、以下の３つの状態が表されうる。対応するデータが陳腐化していることを表す状態、対応するデータが部分的にリフレッシュされた（例えば、複数の別個のデータソースからリフレッシュされるデータをウィジェットが含む場合に用いられる）ことを表す状態、および対応するデータがリフレッシュされたことを表す状態。
【００４９】
オペレーション３１８で、クライアント側アプリケーション３０２は、ＨＴＴＰメッセージを用いて、サーバ側アプリケーション３０４からウィジェットデータを要求する。オペレーション３１８は、ウィジェットごとになされる別個の要求、ウィジェットのグループごとの要求、または全てのウィジェットについてのひとつの要求を含んでもよい。ある実施の形態では、クライアント側ＡｎｇｕｌａｒＪＳフレームワークはダッシュボード設定（例えば、図５および６）に基づいてウィジェットをコンテナにロードし、ウィジェットのデータを要求してもよい。サーバからウィジェットのデータが返ってくると、クライアントフレームワークは各ウィジェットの描画ｈｔｍｌをどこに配置するかについての情報を有する。コンテナは、応答データ内のウィジェット識別子から導かれうる識別子を伴うプレースホルダーｈｔｍｌ要素であってもよい。
【００５０】
要求は、これがウィジェットデータの最初の要求であることを示すパラメータを含んでもよい。要求は、データが要求されているウィジェットを特定してもよい。クライアントでページが描画された直後にウィジェットデータの最初の要求がなされてもよい。
【００５１】
サーバ側アプリケーション３０４は、それに応じて、オペレーション３１９でキャッシュ（例えば、キャッシュ２２４）をチェックする。ある実施の形態では、キャッシュはユーザごとおよびウィジェットごとにウィジェットデータを保持するよう構成されてもよい。例えば、キャッシュ２２４は、ユーザＸにより表示されるウィジェットＡのデータと、ユーザＹにより表示されるウィジェットＡのデータと、を別々に保持してもよい。ある実施の形態では、キャッシュはユーザごとおよびユーザデバイスごとおよびウィジェットごとにウィジェットデータを保持してもよい。この場合、同じユーザが複数のアクティブデバイスでセッションを有することができる。例えば、キャッシュ２２４は、ユーザＸによりユーザデバイスＰで表示されるウィジェットＡのデータと、ユーザＸによりユーザデバイスＱで表示されるウィジェットＡのデータと、を別々に保持してもよい。
【００５２】
その後、オペレーション３１９でのウィジェットデータがキャッシュにあるか否かを判定するためのチェックに基づいて、オペレーション３２１において、キャッシュで発見されたウィジェットデータはクライアント側アプリケーションに返される。ウィジェットデータは、オペレーション３１８で受信したＨＴＴＰ要求に対するＨＴＴＰ応答を用いて返されてもよい。キャッシュ内のデータはバイナリシリアル化されていてもよく、この場合、クライアント側描画技術が理解できるフォーマットに変換する必要がある。ＪＳＯＮは、ほとんどのクライアント側技術がデータ転送のために用いるスタンダードである。したがって、ある例示的な実施の形態では、キャッシュ内のバイナリシリアル化されたデータは、応答を返送する前に、その等価なＪＳＯＮ形式に変換される。
【００５３】
多くの場合、またはほとんどの場合、オペレーション３２１でサーバに返されるものは陳腐データを含むであろう。これは、リフレッシュ要求がなされる時から対応するウィジェットデータがユーザに送信される時までの間に経過する時間は、対応するキャッシュがリフレッシュされるようにデータソースの多くからデータを受信するのには不十分であろうからである。例えば、ネットワークレイテンシ等のために、ジョブプロセス３０８がひとつ以上の外部データソースにアクセスするのには経過時間が短すぎるかもしれない。ある状況では、ひとつ以上のウィジェットのデータは経過時間内にリフレッシュされうる一方、他のデータは陳腐なままであり得る。
【００５４】
ある実施の形態では、ひとつ以上のウィジェットは複数のソースからのデータを含みうる。そのような場合、異なるソースから得られる情報群のそれぞれに対して陳腐フラグが指定されうる。ウィジェットの陳腐フラグは、そのウィジェットの全てのグループのフラグがリフレッシュ済みを示す場合にのみリフレッシュ済みを示すよう設定される。ウィジェットの陳腐フラグが（例えば、リフレッシュが必要と示すよう）設定される場合、ウィジェット内のグループのそれぞれの陳腐フラグもまた設定される。
【００５５】
オペレーション３２２で、クライアント側アプリケーションはサーバ側アプリケーションから受信したウィジェットデータを用いてダッシュボードを描画する。返されるデータは、ウィジェットごとに、そのデータがリフレッシュ済みか否かを指定してもよい。ある例示的な実施の形態では、この情報は各ウィジェットの応答内の追加的パラメータ（例えば、ＩｓＳｔａｌｅフラグ）として渡される。
【００５６】
各ウィジェットのデータがリフレッシュされたか否かの情報は、現在リフレッシュ済みのデータを有さないウィジェットについてのみデータ要求（例えば、再試行データ要求）を生成する際に有益でありうる。ダッシュボードの描画中、各ウィジェットがリフレッシュ済みデータを有するかまたは陳腐データを有するかに関する情報を用いることで、ダッシュボードに表示されている陳腐（例えば、対応キャッシュエントリが陳腐であると示されているために潜在的に陳腐であると考えられる）情報とリフレッシュ済み情報とを視覚的に区別することができる。
【００５７】
ある実施の形態は陳腐情報をひとつ以上の所定のフォーマット（例えば、テキスト／バックグラウンドの色、テキストのスタイル、等）で表示してもよく、ユーザが潜在的に陳腐な情報をリフレッシュ済みの情報と容易に区別できる他の技術が用いられてもよい。ある実施の形態は、所定のウィジェットのみがキャッシュデータを表示することができると規定する設定を許してもよく、この場合、描画はダッシュボードを表示するが、キャッシング用に設定されたウィジェットについてのみキャッシュから受信した初期データと共に表示し、他のウィジェットについてはデータ値を表示しなくてもよい。
【００５８】
オペレーション３２３で、所定の間隔にしたがいジョブプロセス３０８が呼び出される。ジョブプロセス３０８がキューをチェックする間隔は設定可能（例えば、５秒）であってもよい。時間間隔は、キャッシュリフレッシュおよびその次の描画の応答性を少なくとも部分的に決定してもよい。しかしながら、ＭＳＭＱキューのチェックの頻度が高すぎると、処理負荷が不必要に増大しうる。オペレーション３２４で、ジョブプロセス３０８は、キャッシュリフレッシュ要求が係属しているか否かを繰り返しチェックする。上述の通り、チェックはＭＳＭＱキューに対して行われてもよく、このキューはキャッシュリフレッシュ要求をキューに入れるためにサーバ側アプリケーションによって用いられる。ジョブプロセス３０８がキャッシュリフレッシュ要求を見つけた場合（例えば、オペレーション３２４における「ｙｅｓ」）、オペレーション３２５で、ジョブプロセス３０８はデータのひとつ以上のデータソース３１０を要求する。各ウィジェットの設定は、そのデータのデータソースを特定してもよい。オペレーション３２５での要求は、ダッシュボードの全てのウィジェットについてのものであるか、または依然として陳腐データを有していると特定されるウィジェットのみについてのものであってよい。要求を受けると、オペレーション３２６でデータソース３１０は要求された情報を取得し、発見されたデータがあると、オペレーション３２７でそれはジョブ３０８に送信される。ある別の実施の形態では、ジョブプロセスはデータソース３１０から情報を直接取得してもよい。ジョブプロセス３０８が要求情報を有すると、ジョブプロセス３０８はオペレーション３２８でサーバ側アプリケーション３０４のキャッシュをリフレッシュする。ジョブプロセス３０８はキャッシュリフレッシュを反映させるために陳腐フラグを更新してもよい。
【００５９】
各ウィジェットのキャッシュデータがデータソースからリフレッシュされたので、対応する陳腐フラグ（または複数のフラグ）は設定解除される（すなわち、対応するキャッシュがリフレッシュされたか現在リフレッシュ中であることを示す）。陳腐フラグの設定解除はジョブプロセスによって行われてもよい。
【００６０】
クライアント側アプリケーション３０２は再試行を続けることで、それがまだキャッシュからデータを受けていないデータを取得してもよい。したがって、オペレーション３２９で、キャッシュから何のデータもまだ受けていないひとつ以上のウィジェットについて第１再試行が行われる。再試行間の間隔および再試行の数は設定可能であってもよい。再試行要求は、それが二番目の要求であることを示してもよい。再試行要求は、それが依然としてリフレッシュ済みデータを必要としている各ウィジェットを特定してもよい。
【００６１】
第１再試行要求を受けると、サーバ側アプリケーションはオペレーション３３０で、キャッシュがひとつ以上のウィジェットについてリフレッシュ済み情報を含む（すなわち、オペレーション３２８でのリフレッシュにより）と認識してもよい。したがって、オペレーション３２９において要求されたウィジェットのリフレッシュ済みデータがあれば、少なくともそのウィジェットのそのデータはオペレーション３３１で返される。ある実施の形態では、クライアント側アプリケーションへの応答が、キャッシュがリフレッシュされたウィジェットのデータと、キャッシュがまだリフレッシュされていないウィジェットのデータと、を含む場合、データが陳腐か否かに関するウィジェットごとの返送データの状態は、各ウィジェットについて含まれる値に基づいて特定可能であってもよい。
【００６２】
サーバ側アプリケーションからの返信を受けると、クライアント側アプリケーションはオペレーション３３２で、リフレッシュ済みデータを含む受信情報でダッシュボードを描画する。オペレーション３２２と同様に、描画は、リフレッシュ済みウィジェットを潜在的に陳腐なウィジェットから区別可能な態様で表示してもよい。
【００６３】
示されるシナリオでは、オペレーション３３１の後も、ひとつ以上のウィジェットが依然としてリフレッシュ済み情報を受信すべきものとして残る。オペレーション３３３で、別の再試行データ要求が行われる。データ要求メッセージは、再試行数と、リフレッシュが求められている特定のウィジェットと、を示す。それに応じて、サーバ側アプリケーション３３４は、ダッシュボード１００のデータを取得するために、所定数より多くの再試行が行われたと認識する。したがって、オペレーション３３５で、それはキャッシュリフレッシュ要求なしで要求データを要求する。要求は適切なデータソースに直接なされてもよい。キューをバイパスしてデータソースに直接アクセスすることは、キューがいっぱいになったときにデータを取得するための第２の技術を有することで、ダッシュボードの応答性および堅牢性を高める。
【００６４】
オペレーション３３６で、データソースは要求データを発見し、オペレーション３３７で要求データはサーバ側アプリケーションに返され、サーバ側アプリケーションは受信したデータでキャッシュをリフレッシュする。オペレーション３３８で、サーバ側アプリケーションはキャッシュからクライアント側アプリケーションへリフレッシュ済みデータを返す。サーバ側アプリケーションによる、データソースに直接アクセスすることによるキャッシュリフレッシュは、キャッシュの同期的リフレッシュ（リフレッシュ要求をキューに入れることにより行われる非同期リフレッシュに対して）であると見なされてもよい。
【００６５】
オペレーション３３９で、キャッシュリフレッシュが完了したことを表すようひとつ以上の陳腐フラグが更新される。
【００６６】
オペレーション３４０で、クライアント側アプリケーションは更新された情報を含む情報でダッシュボードを描画する。
【００６７】
ダッシュボードに現在表示されている全てのウィジェットについてキャッシュ（例えば、キャッシュ２２４）からの情報が受け取られた場合、クライアント側アプリケーションは表示を完了する。ウィジェットのうちのいずれかが依然として潜在的に陳腐な情報のままである場合、所定のオペレーション数だけ再試行が続いてもよい。
【００６８】
図４は、ある実施の形態に係る、サーバ側キャッシュ（例えば、キャッシュ２２４）をリフレッシュするための処理４００のフローチャートを示す。フローチャートは、クライアント側ウェブアプリケーション４０２とサーバ側ウェブアプリケーション４０４との間のやりとりにより、キャッシュリフレッシュ要求がキュー４０６に送られることが導かれることを示す。キャッシュリフレッシュプロセスおよびその後のクライアント側描画プロセスは、図３との関連で説明されたプロセスと同じであるか、それと同様である。
【００６９】
オペレーション４１２で、クライアント側アプリケーション４０２は、ひとつ以上のウィジェットのキャッシュからのデータと共に、そのひとつ以上のウィジェットの期限を受ける。キャッシュ内の各ウィジェットの期限は、サーバ側アプリケーションまたは他のプロセスによって継続的に（例えば、所定間隔で）更新される。期限はサーバにおいて、キャッシュエントリが失効する前に（すなわち、リフレッシュが望まれる前に）残っている時間（例えば、秒の単位）として、維持されてもよい。
【００７０】
クライアントにおいて、サーバから受けた期限はアレイとして、または複数の値を周期的に（例えば、周期タイマによりトリガされる）更新可能な他のデータ構造で維持されてもよい。オペレーション４１４で、クライアント側アプリケーションは受信した更新済み期限を含めるようアレイまたは他の構造を更新する。アレイは、ダッシュボードに表示されるウィジェットのそれぞれのリフレッシュ時間を表してもよい。サーバ側アプリケーションによって示されたウィジェットのそれぞれについてのリフレッシュまでに残された時間は、クライアントのアレイ内のウィジェットについてのリフレッシュまでの残存時間を更新するために用いられてもよい。
【００７１】
オペレーション４１６で、所定間隔で満了するタイマからの信号に基づいて、アレイ内のウィジェットのそれぞれの残存時間が所定量だけ減じられる。例えば、タイマが５秒間隔で切れるよう設定されている場合、各期限切れで減じられる量は５秒に設定されてもよい。
【００７２】
オペレーション４１８で、残存時間が０（または、リフレッシュを要求するまでのごく短時間を示す他の所定の小さな値）以下となるウィジェットがアレイ内に存在するか否かが判定される。
【００７３】
オペレーション４２０で、クライアント側アプリケーションは、データリフレッシュを要求するものとして特定されたウィジェットのそれぞれのデータを要求する。オペレーション４２０の要求は、それがリフレッシュの最初の要求であることを示してもよい。
【００７４】
オペレーション４２２で、データ要求を受け、それがウィジェットについての最初のデータ要求であると認識すると、サーバ側アプリケーションはそのウィジェットに対応する陳腐フラグを、リフレッシュが要求されたことを示すよう設定してもよい。
【００７５】
オペレーション４２４で、サーバ側アプリケーションはそのウィジェットのキャッシュリフレッシュ要求をＭＳＭＱキューに入れる。オペレーション４２６で、現在キャッシュ内にあるデータが要求元のクライアント側アプリケーションに返される。
【００７６】
この最初のデータ要求が４２４で受け付けられたときに陳腐フラグが既に設定されていれば、それはこのウィジェットについてのリフレッシュ要求が既にアクティブであることを示しており、したがって、オペレーション４２４でリフレッシュ要求がキューに入れられることはない。
【００７７】
以降のクライアント側およびサーバ側処理は、図３に関連して説明された、キャッシュリフレッシュ要求がキューに入れられて対応する陳腐フラグがリフレッシュが要求されたことを示すよう設定された後の処理と同じか、それと同様であってもよい。例えば、ジョブプロセスは、キューに入れられた要求に基づいて、データソースからデータを取得し、キャッシュを適切にリフレッシュしてもよい。キャッシュのリフレッシュが成功すると、ジョブプロセスによって対応する陳腐フラグはリセットされ、それはキャッシュがウィジェットの最新データを含むことを示す。サーバが所定数の再試行をクライアントから受けるまでにキャッシュがリフレッシュされない場合、サーバはデータソースに直接アクセスしてデータを取得し、キャッシュをリフレッシュする。リフレッシュ済みのデータは、次の要求再試行の際にクライアントによって取得される。
【００７８】
図５は、ダッシュボードなどの表示ユーザインタフェースを設定するために使用可能な例示的ＸＭＬ設定ファイル５００の一部を示す。設定ファイル５００は、複数のウィジェットのうちの各ウィジェットの設定データ（例えば、リサーチウィジェットおよび予想ウィジェットのそれぞれについての５０２および５０３）と、ウィジェットのデータを供給する提供者のそれぞれの詳細（例えば、リサーチウィジェットのデータ提供者および予想ウィジェットのデータ提供者のそれぞれについての５０４および５０５）と、を特定してもよい。
【００７９】
各ウィジェットについて、設定ファイルは、ウィジェットを一意に特定する識別子（例えば、５０６）と、ウィジェットがキャッシュ可能か否かを示すもの（例えば、５１０）と、ウィジェットのリフレッシュの頻度を示すリフレッシュ間隔（例えば、５１２）と、ウィジェットのデータの提供者の識別情報（例えば、５１４）と、を特定してもよい。各ウィジェットの識別子は、ウィジェットデータの要求において、ウィジェットデータを提供する応答において、キャッシュ（例えば、キャッシュ２２４）のインデクス化において、等でウィジェットを特定するために使用されてもよい。サーバ側アプリケーションはキャッシュ可能に設定されたウィジェットのみをキャッシュしてもよい。設定ファイルにおいてキャッシュ可能であると示されていないウィジェットについては、そのデータはサーバでキャッシュされなくてもよい。リフレッシュ間隔はウィジェットごとに指定され、サーバはこの設定値を用いて対応するキャッシュリフレッシュタイマを設定してもよい。ウィジェットの設定は、コンテキスト変更の際にウィジェットのデータがリフレッシュされるべきかを指定してもよい（例えば、５１６）。例示的なコンテキスト変更は、図１に示される「ピアの活動」ウィジェットにおいて現在選択されている投資ポジションがユーザによって変更されたときに生じてもよい。そのような変更があると、サーバは「ピアの活動」ウィジェットの設定を参照し、コンテキスト変更に際してそれをリフレッシュする必要があるかを判定してもよい。
【００８０】
各ウィジェットの設定が提供者名を指定できる一方で、各提供者の詳細（例えば、データ取得のためのアドレス等）は設定ファイルの別のセクションで提供される。
【００８１】
図６は、ある実施の形態に係る、例示的なユーザインタフェースレイアウト設定のＸＭＬファイル６００を示す。ファイル６００は２つのレイアウト６０２および６０４を指定する。レイアウト６０２はダッシュボード上に３つのウィジェットを配置するよう構成され、レイアウト６０４は１０個のウィジェットを配置するよう構成される。ユーザデバイスの各タイプについて異なるレイアウトが指定される、および／またはデフォルトのレイアウトが指定される。レイアウト設定は各ウィジェットの位置設定を指定してもよい。ユーザインタフェースを描画するフレームワークが各ウィジェットの位置設定を用いることで、その位置識別子に対応するコンテナにウィジェットをロードできる。ファイル６００に示される設定はただの例示であり、設定ファイルが任意の数のレイアウトを有してもよく、各レイアウトが異なるパターンに配置されたウィジェットの同じまたは異なる集合を有してもよいことは理解されるべきである。
【００８２】
図７は、ある実施の形態に係る、サーバ側キャッシュ（例えば、キャッシュ２２４）のために使用可能な例示的データベーススキーム７００を示す。各キャッシュエントリは一意の識別子７０２を有してもよく、対応するキャッシュデータが関係するウィジェット（すなわち、WidgetId７０４）とユーザ（すなわち、userId７０６）とを特定してもよい。異なるタイプのデータをキャッシュする柔軟性を提供するために、スキーマ中でデータ（すなわち、値７０８）は可変長バイナリデータとして指定されてもよい。
【００８３】
各キャッシュエントリは、期限（すなわち、expiry７１０）と、キャッシュエントリがいつ最後にリフレッシュされたかを示す最新リフレッシュ時間（すなわち、LastUpdated７１２）と、を指定してもよい。各キャッシュリフレッシュの際に期限を更新することで、それがリフレッシュされるべき次の時刻を表すようにしてもよい。例えば、次の期限は、現在のリフレッシュの時刻と、設定からのリフレッシュ間隔と、に基づいて決定されてもよい。
【００８４】
updatedByUI７１４フラグは、ユーザインタフェースがウィジェットのリフレッシュ済みデータを要求するか否かを表す。これは、キャッシュ内のデータがジョブプロセスではなくウェブサーバアプリケーションによってリフレッシュされたか否かを示す。このフラグが真に設定されるキャッシュアイテムが数多くあることは、ジョブが健康ではないか、またはキューの負荷を処理できていないことを示してもよい。
【００８５】
layoutId７１６は、ユーザインタフェース上のこのウィジェットの表示レイアウトを特定する。例えば、layoutID７１６はダッシュボード設定ファイルで定義される複数のレイアウトのうちのひとつを指定してもよい。ViewTypeId７１８は、ウィジェットの表示タイプを指定する。ソースからのデータをダッシュボードに表示する前に変換する必要がある場合に、ウィジェットのビュータイプを考慮してもよい。LayoutId７１６は、特定のダッシュボード内の全てのウィジェットのキャッシュデータを、そのダッシュボードの全てのウィジェット識別子をマッチする必要なく、容易に取得する際に役に立つものでありうる。これは主に性能向上ファクタである。ViewTypeId７１８は、ユーザによって切り替え可能なある基準に基づいてウィジェットがデータを見せることができる場合に用いられてもよい。任意の時点で、ユーザはひとつの基準のデータのみを見る。このフィールドは、現在選択されている基準に基づいてデータをフィルタする際に有益でありうる。鍵７２０は、どのウィジェットデータが取得されるべきかに基づいて動的鍵を保持するために用いられるフィールドであってもよい。
【００８６】
図８は、ある実施の形態で使用されうる例示的フレームワーク８００の一部を模式的に示す。フレームワーク８００は例えば、サーバ側キャッシュ（例えば、キャッシュ２２４）の態様を示してもよい。サーバ側キャッシュはWidgetCache８０２クラスの複数のオブジェクトを備えてもよい。例えば、サーバ側キャッシュはクラス８０２に対応する複数のオブジェクトを含んでもよい。WidgetCache８０２は、一般的なキャッシュタイプとして定義されてもよく、データソースから受けたデータをバイナリシリアル形式で保持してもよい。
【００８７】
実施の形態によると、サーバ側アプリケーションは、WidgetDataHelperクラス８０４を頼ることで、キャッシュを維持し、クライアントに要求データを提供してもよい。WidgetDataHelperクラス８０４はウィジェットの各タイプについて指定されたデータ提供者クラスに依拠してもよい。クラス８０４は、設定および資格等に基づいて表示可能ウィジェットを特定すること、全てのウィジェットのキャッシュデータを取得すること、全てのウィジェットの性能を取得すること、クライアントから受けた要求のタイプに基づいてデータ提供者の適切なメソッドを呼び出すこと、キャッシュへのデータの保存を促進すること、ウィジェットの性能をセーブすること、等を提供してもよい。例えば、ResearchWidgetタイプのウィジェットで表示されるデータは、ResearchWidgetProviderクラス８０６をコールするWidgetDataHelperクラス８０２により取得されてもよい。ResearchWidgetProviderクラス８０６はそのデータ提供者へのアクセスを司ってもよい。キャッシュされた情報がバイナリシリアル形式であるため、ReasearchWidgetDataProviderクラス８０６は、バイナリシリアル形式から特定のウィジェットにより要求される異なる形式へデータを翻訳／変換することを提供してもよい。
【００８８】
ResearchWidgetDataProviderクラス８０６はWidgetProviderBaseクラス８０８からの承継であってもよく、WidgetProviderBaseクラス８０８はインタフェースクラスIWidgetDataProvider８１０を実装してもよい。ウィジェットの各タイプの対応するデータ提供者オブジェクトを生成するために、ファクトリクラスWidgetDataProviderFactory８１２を用いてもよい。
【００８９】
図９は、IwidgetDataProvider８１０のインタフェースの例を示す。インタフェースは２つのメソッドを指定する：現在のウィジェット設定およびレイアウトタイプをパラメータとするGetDataと、キャッシュされたデータをパラメータとするGetData。キャッシュされたデータが利用可能か、または実際のソースから入力される必要があるか、に依存して、適切なGetDataメソッドがコールされる。
【００９０】
図１０は、ある実施の形態に係る、システム２００のハードウエアアーキテクチャの例示的ブロック図を示す。クライアントシステム１０１０はネットワーク１０４０を介してサーバシステム１０００と通信する。ネットワーク１０４０はインターネットなどの相互に接続された計算デバイスのネットワークを含みうる。ネットワーク１０４０はローカルエリアネットワーク（ＬＡＮ）を含んでもよく、またはクライアントシステム２１０とサーバシステム１０００との間のピアツーピア接続を含んでもよい。
【００９１】
例示的なクライアントシステム１０１０とサーバシステム１０００とは、図２に示されるクライアントシステム２０２とサーバシステム２０４とに対応しうる。すなわち、図２等を参照して本明細書で説明され示された種々のソフトウエアコンポーネントおよび動作を実装するために、図１０で説明されるハードウエア要素を用いることができる。例えば、クライアントシステム１０１０は、少なくともひとつのプロセッサＣＰＵ１０３１と、少なくともひとつのメモリ１０３２と、少なくともひとつの入出力デバイスＩ／Ｏ１０３３と、ユーザインタフェースＵＩ１０３４を生成して表示するためのコンポーネントと、を含んでもよい。Ｉ／Ｏデバイス１０３３は、データを送受するトランシーバ（例えば、無線トランシーバ、有線トランシーバ）などの通信デバイスを全て包含し、それを含みうるものであってもよい。Ｉ／Ｏデバイス１０３３は、データを送受するために非一時的コンピュータ可読保持媒体をクライアントシステム１０１０に接続するためのインタフェースを含んでもよい。
【００９２】
図２に示される例示的なウェブブラウザアプリケーション２１４を実装するためにクライアントシステム１０１０の要素の組み合わせを用いることができることは、理解されるべきである。例えば、メモリ１０３２はアプリケーションに関連付けられたファイル（例えば、ＨＴＭＬ、ＸＭＬ、ＪａｖａＳｃｒｉｐｔファイル）をロードし、ＣＰＵ１０３１は上述の描画モジュール、ネットワーキングモジュール、およびジャバスクリプトモジュールを動作させてアプリケーションを生成するために用いられてもよい。同様に、Ｉ／Ｏデバイス１０３３はＳＰＡを含む種々の要素をサーバシステム１０００から入力するためにネットワーキングモジュールによって用いられてもよい。
【００９３】
サーバシステム１０００は、図２に示されるサーバシステム２０４のソフトウエア要素を実装するために用いられる種々のハードウエアコンポーネントを備える。例えば、サーバシステム１０００は、少なくともひとつのプロセッサＣＰＵ１０２１と、少なくともひとつのメモリ１０２２と、少なくともひとつの入出力デバイスＩ／Ｏ１０２３と、のハードウエアコンポーネントを含んでもよい。Ｉ／Ｏデバイス１０２３は、データを送受するトランシーバ（例えば、無線トランシーバ、有線トランシーバ）などの通信デバイスを全て包含し、それを含みうるものであってもよい。Ｉ／Ｏデバイス１０２３は、データを送受するために非一時的コンピュータ可読保持媒体をクライアントシステム１０００に接続するためのインタフェースを含んでもよい。ひとつの例示的な実施の形態では、クライアントシステムのＩ／Ｏデバイス１０３３は、サーバシステムのＩ／Ｏ１０２３とのネットワークを介した通信を行うことができる。
【００９４】
クライアントシステム１０１０と同様に、サーバシステム１０００はアプリケーションを生成するためのコンポーネントを実装することができる。例えば、ウェブサーバ２１６およびアプリケーションサーバ２１８によって用いられるコンポーネントおよびファイルに加えて、データベース２２０に情報を格納するためにメモリ１０２２を用いることができる。ＣＰＵ１０２１は、クライアントシステム１０１０により要求されそれに送信される対応モジュールを生成するのに必要なソフトウエアを実行する際に用いられてもよい。例えば、ＣＰＵ１０２１は、アプリケーションサーバ２１８によって生成される必要なモジュールを生成するために用いられてもよい。同様に、Ｉ／Ｏデバイス１０２３は、クライアントシステム１０１０に異なるアプリケーション要素を送信するためにウェブサーバ２１６によって用いられてもよい。無論、これらの例は非限定的であり、システムはハードウエア要素を様々な態様で用いることを想定している。
【００９５】
本明細書の例では、説明を目的とし、限定を目的とせず、記載の技術の理解を提供するために、特定のノード、機能エンティティ、技術、プロトコル、規格等の具体的な詳細が説明される。他の実施の形態を、以下の詳細説明から離れて実施できることは当業者には明らかであろう。他の例では、周知の方法、デバイス、技術等の詳細説明は、不必要な詳細説明で説明を曖昧にしないために省略されている。個々の機能ブロックが図に示される。これらのブロックの機能は、個別のハードウエア回路を使用して、適切なプログラム化マイクロプロセッサあるいは汎用コンピュータと協働するソフトウエアプログラムおよびデータを使用して、特定用途集積回路（ＡＳＩＣ）を使用して、および／または１つ以上のデジタル信号プロセッサ（ＤＳＰ）を使用して、実現可能であることを当業者は理解するであろう。ソフトウエアプログラムインストラクションおよびデータは、コンピュータ可読保持媒体に保持されてもよく、このインストラクションがコンピュータあるいは他の適切なプロセッサ制御によって実行されると、コンピュータあるいはプロセッサは機能を実行する。以下でデータベースはテーブルとして示されている場合があるが、他のフォーマット（リレーショナルデータベース、オブジェクトベースモデル、および／または分散データベースを含む）を、データを保持し操作するために使用することができる。
【００９６】
処理ステップ、アルゴリズムあるいはその類が特定の順序で記載またはクレームされている場合があるが、このような処理は、異なる順序で動作するように構成設定することができる。換言すれば、明示されるかクレームされるいかなるシーケンスあるいはステップの順序も、そのステップがその順序で実行される必要性を示すものでは必ずしもない。本明細書で記載される処理のステップは、取り得る任意の順序で実行されうる。また、いくつかのステップは、非同時的に発生するように記載されているあるいは暗示されているが（例えば、あるステップは、他のステップの後に記載されているからである）、同時に実行されうる。さらに、図面における図示による処理の説明は、図示される処理が他の変形や変更について排他的であることを暗示しているのではなく、また、図示される処理あるいはその任意のステップが本技術に必要であることを暗示しているのではなく、また、図示される処理が好ましいことを暗示しているのでもない。
【００９７】
様々な形式のコンピュータ可読媒体／伝送は、プロセッサにデータ（例えば、インストラクションのシーケンス）を運ぶ際に含まれうる。例えば、データは、（ｉ）メモリからプロセッサへ送信されてもよく、（ｉｉ）任意のタイプの送信媒体（例えば、有線、無線、光等）を介して運ばれてもよく、（ｉｉｉ）イーサネット（あるいはＩＥＥＥ８０２．３）、ＡＴＰ、ブルートゥース（登録商標）、ＴＣＰ／ＩＰ、ＴＤＭＡ、ＣＤＭＡ、３Ｇ等のような、多くのフォーマット、規格あるいはプロトコルに従ってフォーマットおよび／または送信されてもよく、および／または（ｉｖ）周知の様々な方法の任意のものでプライバシーを確保するためにあるいは流出を防止するために暗号化されてもよい。  本明細書で使用されるように、「非一時的のコンピュータ可読ストレージ媒体」は、レジスタ、キャッシュメモリ、ＲＯＭ、（Ｄ−ＲＡＭ、Ｓ−ＲＡＭ、または他のＲＡＭのような）半導体メモリ装置、フラッシュメモリといった磁気記録媒体、ハードディスク、光磁気記録媒体、ＣＤ−ＲＯＭ、ＤＶＤ、もしくはＢｌｕ−Ｒａｙディスクといった光学記録媒体、または非一時的の電子データストレージのための他のタイプの装置、を含む。本明細書において用いられる「処理システム」という用語は、ＣＰＵ、ＧＰＵ、ＡＳＩＣ、ＦＰＧＡ、または上述のウェブアプリケーションを含むソフトウエアプログラムなどのインストラクションを実行するための他のハードウエア回路のうちの少なくともひとつを意味する。
【００９８】
本書で、動作が実行され「てもよく」、「ることができ」、もしくは「うる」ことと、機能、エレメント、もしくは構成が所与のコンテキストに含まれ「てもよく」、「ることができ」、もしくは「うる」、または適用可能なことと、所与のアイテムが所与の特性を有し「てもよく」、「ることができ」、もしくは「うる」こととが説明されるときはいつでも、または「〜てもよい」、「〜できる」もしくは「〜しうる」という用語を含む任意の類似の語句が使用されるときはいつでも、所与の動作、特徴、エレメント、構成、特性、などが少なくとも１つの実施形態に示されているが、全ての実施形態に示される必要はないことが理解されたい。
【００９９】
AngularJSとの関連で技術が説明されたが、これは説明を容易にするためになされたものであって、本明細書で説明された技術が他のＳＰＡ技術や他のウェブ技術やおよび／または他のソフトウエア技術のコンテキストにおいて適用可能であることは理解される。
【０１００】
最も実際的で好適な実施の形態であると現時点で考えられているものとの関係で本技術が説明されたが、本技術は開示された実施の形態に限定されるものではなく、むしろ種々の変形例および等価な構成をカバーするよう意図されていることは理解されるべきである。
【要約】
開示される技術は、ウェブページの表示などのクライアント側ユーザインタフェースを、表示データを提供するためのサーバ側キャッシュを用いて、描画することに関する。例示的な実装では、ユーザインタフェース（例えば、ウェブアプリケーションにおける複数のウィジェットを伴うダッシュボード）がクライアントデバイスで起動されたことに応じて、サーバは複数のウィジェットのキャッシュのリフレッシュを開始し、開始されたリフレッシュに応じてキャッシュが更新される前に、ユーザインタフェース内のウィジェットのキャッシュから取得されたデータの第１集合を送信する。データの第１集合の後に、開始されたリフレッシュに応じてキャッシュが更新された後のウィジェットのうちの少なくともいくつかについてのキャッシュから取得されたデータの第２集合が続く。クライアントデバイスは、データの第２集合を用いてユーザインタフェースを表示し、一方でウィジェットのうちのひとつ以上について、データの第１集合を用いて以前に表示された情報を上書きする。
【選択図】図１【図１】
0006363814.tif 000002
【図２】
0006363814.tif 000003
【図３Ａ】
0006363814.tif 000004
【図３Ｂ】
0006363814.tif 000005
【図４】
0006363814.tif 000006
【図５】
0006363814.tif 000007
【図６】
0006363814.tif 000008
【図７】
0006363814.tif 000009
【図８】
0006363814.tif 000010
【図９】
0006363814.tif 000011
【図１０】
0006363814.tif 000012