(57)【要約】  本発明は、少なくとも１つの通信ネットワークを介して、サーバと少なくとも１つのクライアント端末との間で、オブジェクトと呼ばれるデータを送信する方法であって、サーバによって送信された前記オブジェクトの少なくともいくつかを格納するようにされた少なくとも１つのキャッシュメモリが、ネットワーク内において、前記クライアント端末の少なくとも１つに関連付けられる方法に関する。本発明は、前記クライアント端末の少なくとも１つに関連付けられた前記キャッシュメモリに存在するオブジェクトの少なくとも１つのリストを前記クライアント端末のアップストリームで管理して、前記キャッシュメモリのコンテンツに関するデータ交換を、前記クライアント端末と前記サーバとの間で制限することを特徴とする。
2005513658.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つの通信ネットワークを介して、サーバと少なくとも１つのクライアント端末との間で、オブジェクトと呼ばれるデータを送信する方法であって、該サーバによって送信された該オブジェクトの少なくともいくつかを格納するようにされた少なくとも１つのキャッシュメモリが、前記ネットワーク内の前記クライアント端末の少なくとも１つに関連付けられ、
前記クライアント端末と前記サーバとの間での前記キャッシュメモリのコンテンツに関する情報交換を制限するために、前記クライアント端末の１つに関連付けられた前記キャッシュメモリに存在するオブジェクトの少なくとも１つのリストを管理することを特徴とする送信方法。
【請求項２】
前記オブジェクトの少なくとも１つに対して、前記オブジェクトの再生に関する情報とともに、前記オブジェクトの各々についての識別子を前記リスト内に格納することを特徴とする請求項１に記載の送信方法。
【請求項３】
前記オブジェクトの少なくとも１つの前記再生情報が、前記オブジェクトの微細レベルに関するものであることを特徴とする請求項２に記載の送信方法。
【請求項４】
前記オブジェクトの前記Ｏ識別子および前記オブジェクトの前記再生情報Ｌ0を含む、前記キャッシュメモリに格納された前記オブジェクトの各々に対して、前記リストが＜Ｏ，Ｌ0＞のペアを含むことを特徴とする請求項２または３に記載の送信方法。
【請求項５】
表示情報と呼ばれる、前記クライアント端末および／または前記クライアント端末のユーザに関する情報の少なくとも１つのアイテムが、前記クライアント端末の各々に対してコンテキストを形成するように前記リストに関連付けられることを特徴とする請求項１から４のいずれかに記載の送信方法。
【請求項６】
前記表示情報が、
前記ユーザの位置情報と、
前記ユーザの観察方向と、
前記オブジェクトの選択パラメータと
を含んでなる群に属することを特徴とする請求項５に記載の送信方法。
【請求項７】
前記サーバによってまたは前記ネットワークの中間要素によって、前記リストが管理されることを特徴とする請求項１から６のいずれかに記載の送信方法。
【請求項８】
前記サーバに初期表示情報が送信されるものである、前記クライアント端末の各々のための第１の送信ステップと、前記対応するコンテキスト中に前記サーバが前記初期表示情報を格納する格納ステップとを含む予備初期化段階を含むことを特徴とする請求項５から７のいずれかに記載の送信方法。
【請求項９】
前記予備初期化段階は、前記サーバが前記クライアント端末によって再生されるシーンのきめの粗いバージョンのものを前記クライアント端末に送信する第２の送信ステップをさらに含むことを特徴とする請求項４に記載の送信方法。
【請求項１０】
所定の時間間隔で、および／または、前記表示情報の修正時に、前記クライアント端末の各々が、前記表示情報アイテムの少なくともいくつかを前記サーバに転送するステップを実行することを特徴とする請求項５から９のいずれかに記載の送信方法。
【請求項１１】
前記所定の時間間隔が、前記クライアント端末によって固定されたものであることを特徴とする請求項１０に記載の送信方法。
【請求項１２】
前記所定の時間間隔が、前記通信ネットワークの少なくとも１つの特徴によるものであることを特徴とする請求項１１に記載の送信方法。
【請求項１３】
前記クライアント端末によって実行される前記転送ステップの終わりに、対応する前記コンテキスト内の前記表示情報を更新するステップを実行することを特徴とする請求項１０から１２のいずれかに記載の送信方法。
【請求項１４】
前記サーバが、
前記更新された表示情報の少なくともいくつかの関数として、前記クライアント端末に必要な少なくとも１つの識別子オブジェクトＯおよび対応する再生レベルＬ0を決定する決定ステップと、
前記クライアント端末に関連付けられた前記キャッシュメモリを表す前記リストを分析して、存在するならば、前記識別オブジェクトＯと前記クライアント端末に必要な再生レベルＬ0とに対応し、前記リストに記憶されていないペア＜Ｏ，Ｌ0＞を特定するステップと、
前記リストに記憶されていない前記ペア＜Ｏ，Ｌ0＞の任意のものに対応する、前記クライアント端末が必要とする再生レベルＬ0とともに、存在するならば、前記識別子オブジェクトＯを前記クライアント端末に送信するステップと、
存在するならば、送信された前記オブジェクトに対応する前記ペア＜Ｏ，Ｌ0＞を前記クライアント端末に追加して、前記クライアント端末に関連付けられた前記キャッシュメモリを表す前記リストを更新するステップと
を前記更新ステップの終わりに実行することを特徴とする請求項１３に記載の送信方法。
【請求項１５】
前記サーバが、
少なくとも１つの識別子オブジェクトＯと、前記クライアント端末にとって必要な可能性がある再生レベルＬ0とを、少なくとも１つの見込み基準によって決定するステップと、
前記少なくとも１つの識別子オブジェクトＯおよび再生レベルＬ0を、前記クライアント端末に前もって送信するステップと
をさらに実行することを特徴とする請求項１４に記載の送信方法。
【請求項１６】
前記サーバによって送信される少なくとも１つのオブジェクトを受信すると、前記クライアント端末が、
前記クライアント端末に関連付けられた前記キャッシュメモリの充填率が、所定のしきい値より低い場合には、前記キャッシュメモリに前記受信したオブジェクトを格納するステップと、
そうでない場合には、前記受信したオブジェクトの関連基準を評価するステップと
を実行するものであり、
前記キャッシュメモリに格納された前記オブジェクトの少なくとも１つが、前記受信したオブジェクトの前記関連基準より小さい値の関連基準を有している場合には、前記クライアント端末が、前記キャッシュメモリから前記値が小さな関連オブジェクトを除外するサブステップと、前記キャッシュメモリに前記受信したオブジェクトを格納するサブステップとを実行し、
そうでない場合には、前記クライアント端末が、前記受信したオブジェクトを拒絶するサブステップを実行することを特徴とする請求項１４または１５に記載の送信方法。
【請求項１７】
前記除外サブステップおよび／または前記拒絶サブステップの後に、前記クライアント端末が、前記クライアント端末に関連付けられた前記キャッシュメモリを更新するための少なくとも１つの情報アイテムを前記サーバに送信することによって、前記サーバは、前記除外サブステップ中に除外された前記オブジェクト、および／または、前記送信ステップ中に前記サーバによって送信されたオブジェクトに対応するが、前記キャッシュメモリには記憶されていない少なくとも１つの＜Ｏ，Ｌ0＞のペアを、前記キャッシュメモリを表す前記リストから除外することを特徴とする請求項１６に記載の送信方法。
【請求項１８】
前記関連付けされたインデックスから始まる前記オブジェクトの一部分を選択的に送信できるように、前記オブジェクトの少なくともいくつかが少なくとも１つのインデックスを含むことを特徴とする請求項１から１７のいずれかに記載の送信方法。
【請求項１９】
少なくとも１つの通信ネットワークを介して、サーバと少なくとも１つのクライアント端末との間で、オブジェクトと呼ばれるデータを送信するシステムであって、前記サーバによって送信された前記オブジェクトの少なくともいくつかを格納するようにされた少なくとも１つのキャッシュメモリが、前記ネットワーク内の前記クライアント端末の少なくとも１つに関連付けられ、
前記クライアント端末と前記サーバとの間での前記キャッシュメモリのコンテンツに関する情報交換を制限するために、前記クライアント端末の１つに関連付けられた前記キャッシュメモリに存在するオブジェクトの少なくとも１つのリストを、前記クライアント端末の入力側で管理するための手段を含むことを特徴とするシステム。
【請求項２０】
少なくとも１つの通信ネットワークを介して少なくとも１つのクライアント端末に接続された、オブジェクトと呼ばれるデータのためのデータサーバであって、前記サーバによって送信された前記オブジェクトの少なくともいくつかを格納するように与えられた少なくとも１つのキャッシュメモリが、前記ネットワーク内の前記クライアント端末の少なくとも１つに関連付けられ、
前記キャッシュメモリのコンテンツに関係する情報に関して、前記関連付けられたクライアント端末との情報交換を制限するために、前記クラアント端末の少なくとも１つに関連付けられた前記キャッシュメモリに存在するオブジェクトの少なくとも１つのリストを管理する手段を含むことを特徴とするデータサーバ。
【請求項２１】
前記端末に関連付けられた前記キャッシュメモリを表す前記リストを前記サーバが更新できるように、更新情報の少なくとも１つのアイテムを前記サーバに送信する手段を含むことを特徴とする請求項２０に記載のデータサーバ用のクライアント端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークを介したデータ送信の分野に関する。さらに詳しく言えば、本発明は、双方向に表示されるデータの送信およびそれに関連するキャッシュ管理に関する。
【背景技術】
【０００２】
現在、通信ネットワークの顕著な発展により、ユーザが、例えば、イメージ、テキスト、幾何学的タイプのモデル、または３Ｄシーンタイプのモデルを双方向にリアルタイムで表示することができる。従来、ユーザは、適切な端末を介して遠隔サーバに接続を行い、この遠隔サーバによって、ユーザがあるデータベースにおいてこの表示に必要なすべての情報を中央管理する（この場合には「表示」という用語が使用されているが、このタイプの情報は、すべてのタイプのデータを含み、特に、サウンドデータ、ページ付けデータなどを含むことに留意されたい）。
【０００３】
このようにして、ユーザは、例えば、仮想ミュージアム、地形の起伏（ground relief）、またはクラシック音楽のコンサートなどの３Ｄ仮想環境を動き回ることが可能なタイプの新しいアプリケーションにアクセスできる。したがって、これらのアプリケーションに関連して、サーバは、シーン内のユーザ位置により、ユーザの視野（または聴覚範囲）に入るシーンの異なるオブジェクトに関する情報とともに、広範囲のシーンの再構築に必要な情報をクライアントに送信する。
【０００４】
本発明は、特に、例えば、将来的に使用するための、データサーバを介したユーザによりアクセス可能なすべてのタイプの情報の上述したような送信および格納に応用可能であるが、これらの限定されるものではない。
【０００５】
例えば、（上述したように）シーンやビデオのリアルタイム表示ができるように、ユーザの端末はキャッシュと一般的に関連付けられており、端末がリアルタイムでシーンを再生するのに必要なすべての情報がキャッシュ内に格納される。
【０００６】
このタイプのキャッシュは、従来、「過去」のデータ、言い換えれば、シーンやイメージを再生するために端末がすでに使用したデータであるが、ユーザの必要により、後で使用されることがあるデータを記憶する。そして、これは、「現在」のデータ、つまり端末が現在使用中のデータと、近い未来に端末が必要とすることがあり、サーバがユーザの必要性を予想した結果得られる可能性がある「未来」のデータを最後に格納する。
【０００７】
容易に理解できるように、特に、ユーザが、非常に大きなデータアイテム、例えば、非常に大きな三次元シーンの表示を望む場合には、最初にサーバが送信する必要があり、次にキャッシュでの管理が必要な情報量は、かなりのものである。
【０００８】
クライアントと対応するサーバとの間での大量のデータ交換に関連する問題を解決するために、いくつかの体系的方法を導入することができ、特に、
キャッシュ充填率が高いとき、メモリ空間を解放するために、削除すべき格納データを選択するために使用可能な置換アルゴリズムや、
クライアントに送信されるデータのサーバが行う選択とこれらのデータの送信モードとを調整する送信方法を導入することができる。
【０００９】
このとき、クライアントとサーバとの間のダイアローグを作成し、クライアントに送信される情報についてサーバに通知するための２つの公知の主要な送信方法がある。
【００１０】
第１の公知の送信方法は、Ｊ．Ｈ．Ｐ．Ｃｈｅｍ  ｅｔ  ａｌ．による文献「Ｍｕｌｔｉ−Ｒｅｓｏｌｕｔｉｏｎ  Ｍｏｄｅｌ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｉｎ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｖｉｒｔｕａｌ  Ｅｎｖｉｒｏｎｍｅｎｔｓ」、ＶＲＳＴ’９８、２５−３４頁に詳しく記載されている。
【００１１】
この第１の方法によれば、サーバは、４つの連続ステップにおいて、クライアントが表示を望むデータを送信することができ、
第１のステップ中に、クライアント端末は、表示されるシーン内におけるユーザの位置に関する情報をサーバに送信し、
サーバがこの位置情報を受信すると、サーバは、ユーザに必要なすべてのオブジェクトを算出し、第２のステップ中に、オブジェクトの必要な＜Ｏ，Ｌ0＞のペアのリストを送信し、ここで、Ｏはオブジェクトの基準であり、Ｌ0はそれに対応する詳細レベルであり、
クライアント端末は、このリストを用いて、キャッシュのコンテンツに応じて、受信を望むオブジェクトに対応する対を選択し、第３のステップ中に、その選択結果をサーバに送信し、
第４のステップ中に、サーバは、クライアントの端末によってリクエストされたオブジェクトを転送する。
【００１２】
従来技術によるこの技術の１つの欠点は、シーン内でユーザ位置が変化すると、すなわち、サーバが１以上の新しいオブジェクトをユーザに送信する必要が生じると、キャッシュを介してユーザが必要なオブジェクトにアクセスできるようになる前に、サーバとクライアント端末との間に、往復運動（forward-return）の形態で２つの完全なデータ交換が必要になることである。
【００１３】
したがって、待ち時間が長い通信ネットワークを介したデータ送信にこのタイプの技術が適応されず、このタイプのネットワークに対して、この技術では、サーバによって送信されるデータをリアルタイムで表示することができない。
【００１４】
第２の公知の送信方法は、Ｊ．Ｈ．Ｐ．Ｃｈｉｍ  ｅｔ  ａｌ．による論文「Ｏｎ  Ｃａｃｈｉｎｇ  ａｎｄ  Ｐｒｅｆｅｔｃｈｉｎｇ  ｏｆ  Ｖｉｒｔｕａｌ  Ｏｂｊｅｃｔｓ  ｉｎ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｖｉｒｔｕａｌ  Ｅｎｖｉｒｏｎｍｅｎｔｓ」、Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ｓｉｘｔｈ  ＡＣＭ  ｉｎｔｅｒｎａｔｉｏｎａｌ  ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｍｕｌｔｉｍｅｄｉａ、１９９８、１７１−１８０頁に記載されている。
【００１５】
段階的にコード化されたオブジェクトの送信に特に適応されたこの第２の方法によれば、クライアント端末は、位置情報およびキャッシュのコンテンツに関する情報とともに、表示されるシーンにおける動きの各々に関する情報を＜Ｏ，Ｌ0＞のペアの形態でサーバに送信する。この場合も、Ｏはクライアントキャッシュに含まれるオブジェクトの基準を表し、Ｌ0はこのオブジェクトに関連した詳細なレベルについてサーバに知らせる。
【００１６】
そして、サーバは、シーン内でのユーザの位置に応じて、すべての視覚的に関連するオブジェクトを算出し、これらのオブジェクトがユーザのキャッシュに存在するか否かをチェックし、すべての不明オブジェクトをクライアントに送信する。
【００１７】
この方法を用いると、クライアントにシーンを表示するのに必要なデータを転送するのに、クライアントとサーバとの間での往復が１回で済む。
【００１８】
しかしながら、従来技術によるこの技術の１つの欠点は、特に、通過帯域という観点で、非常に多くのネットワークリソースを消費してしまうことである。シーン内でのユーザのそれぞれの動きについて、クライアント端末は、キャッシュのコンテンツに関するすべての情報（言い換えれば、キャッシュに含まれるオブジェクトに対応するすべての＜Ｏ，Ｌ0＞のペア）をサーバに転送する。
【００１９】
したがって、非常に大きなシーンを表示する場合には、クライアント端末からサーバに送信される情報量は非常に多くなり、このことは、低速通信ネットワークの場合には特に問題となる。
【発明の開示】
【発明が解決しようとする課題】
【００２０】
本発明の１つの特定の目的は、従来技術による欠点を解消することである。
【００２１】
より詳しく言えば、本発明の１つの目的は、サーバとクライアント端末との間の転送を最小限に抑えながら、大量のデータのリアルタイム表示に必要な情報をサーバからクライアント端末に送信する技術を提供することである。
【００２２】
本発明の別の目的は、単純で安価に構築できるこのタイプのデータ送信技術を構築することである。
【００２３】
本発明の別の目的は、あらゆるタイプのネットワークに適応され、特に、多くの待ち時間をもつネットワーク速度が遅いネットワークにも同様に適応される通信ネットワークを介して、このようなデータ送信技術を提供することである。
【００２４】
本発明の別の目的は、サーバからクライアント端末へのデータ送信の冗長を回避するために、このようなデータ送信技術を構築することである。
【００２５】
本発明のさらなる別の目的は、クライアント端末によってサーバに送信されたデータリクエストをなくし、または少なくとも減らすこのようなデータ送信技術を提案することである。
【課題を解決するための手段】
【００２６】
以下から明らかとなる上記目的および他の目的は、少なくとも１つの通信ネットワークを介したサーバと少なくとも１つのクライアント端末との間での、オブジェクトと呼ばれるデータの送信方法であって、前記サーバによって送信された前記オブジェクトの少なくともいくつかを格納することになる少なくとも１つのキャッシュメモリが、前記ネットワーク内の前記クライアント端末の少なくとも１つに関連付けられる方法によって達成される。
【００２７】
本発明によれば、前記クライアント端末と前記サーバとの間で、前記キャッシュメモリのコンテンツに関する情報交換を制限するために、前記クライアント端末の１つに関連付けられた前記キャッシュメモリに存在するオブジェクトの少なくとも１つのリストが、前記クライアント端末の入力側で管理される。
【００２８】
したがって、本発明は、キャッシュメモリの管理の革新的で進歩性のあるアプローチに基づくものである。本発明は、特に、データサーバにアクセス可能なクライアント端末の入力側（アップストリーム）において、クライアントに関連付けられたキャッシュのコンテンツを表すリストを維持するという革新的で有利な考えに基づく。したがって、この解決策を用いると、サーバは、これらのコンテンツをサーバで複製する必要がなく、いつでもクライアントキャッシュのコンテンツを知ることができる。したがって、本発明により、リソース、特に、サーバ用のメモリという観点で費用をかけずに、クライアントがシーンまたはオブジェクトセットを表示するとき、サーバとクライアントとの間で交換される情報量を著しく低減できる解決策が得られる。このタイプの解決策は、低容量のクライアント端末または性能が限定された通信ネットワークに対して特に有益である。
【００２９】
サーバとクライアント端末との間での交換のコンテキスト（context、または、文脈）下でオブジェクトリストまたはドキュメントリストの管理を行うようにする米国特許第６０９８０６４号明細書および同第５９５６０３９号明細書に特に記載されているいくつかの技術がすでに知られている。しかしながら、これらのリストは、本発明によるリストとは、形態の点からも役割の点からも異なる。
【００３０】
したがって、米国特許第６０９８０６４号明細書には、ドキュメントが将来的にユーザによって必要とされる見込みに応じて、コンピュータのキャッシュメモリに格納すべき（特に、ウェブページの形態などの）ドキュメントを決定するための技術が記載されている。この技術を用いると、端末のキャッシュメモリにあるか、または将来的にユーザの関心を引くであろうドキュメントをリストした要求リストが作製される。
【００３１】
本発明によるリストと異なり、上述したリストの役割は、クライアントがドキュメントを表示するときにサーバとクライアント端末との間で交換される情報の数および／または量を減らすことではないので、本願の目的のために使用することができない。
【００３２】
米国特許第５９５６０３９号明細書により、３Ｄシーンにおけるリアルタイムナビゲーションシステムの性能を高めるための技術が提供されている。このタイプの技術は、シーンの異なるオブジェクトにプライオリティ（優先順位）を与えることからなり、それによって、クライアント端末は、最も高いプライオリティのオブジェクトをまず受け取る。これらのプライオリティは、現在のシーンにある各オブジェクトに関する情報を含むデータベース内で管理される。
【００３３】
しかしながら、このデータベースは、（アップストリームである）クライアント端末の入力側で管理されないため、本発明のように、サーバと端末との間での交換を減少させる技術的な問題を解決できない。
【００３４】
前記オブジェクトの各々の識別子は、前記オブジェクトの少なくとも１つに対して、前記オブジェクトの再生に関する情報とともに、前記リスト内に格納されるのが有益である。
【００３５】
したがって、サーバは、クライアントのキャッシュに含まれたオブジェクトのリストだけでなく、クライアントによって再生可能な再生レベルにアクセスすることができる。
【００３６】
前記オブジェクトの少なくとも１つの前記再生情報は、前記オブジェクトの微細レベルに関するものであることが好ましい。
【００３７】
したがって、サーバは、クライアント端末が、例えば、きめの粗い形態または微細な形態でオブジェクトを再生可能であるかを認識できる。
【００３８】
前記リストが、前記オブジェクトの前記Ｏ識別子と前記オブジェクトの前記再生情報Ｌ0とを含む、前記キャッシュメモリに格納された前記オブジェクトの各々に対して＜Ｏ，Ｌ0＞のペアを含むことが好ましい。
【００３９】
本発明の１つの有益な特徴によれば、表示情報と呼ばれる、前記クライアント端末および／または前記クライアント端末のユーザに関する情報の少なくとも１つのアイテムは、コンテキストを形成するように、前記クライアント端末の各々に対して前記リストに関連付けられる。
【００４０】
サーバに接続された各クライアントに対して、サーバは、クライアントに関連付けられたキャッシュの状態を表すリストおよび表示情報を含むコンテキストを管理する。このタイプの情報は、特に、クライアント端末の容量、またはその速度を表すものでありうる。
【００４１】
前記表示情報は、
前記ユーザの位置情報と、
前記ユーザの観察方向と、
前記オブジェクトの選択パラメータと
を含んでなる群に属することが好ましい。
例えば、このタイプの選択パラメータは、オブジェクト選択しきい値（object selection threshold）と、オブザーバ視野(observer view)とを含む。クライアント端末による３Ｄシーンの表示の場合には、３Ｄ点の形態で位置情報を表現することができ、この場合には、軸は、シーンの中心に対するオブザーバの位置に相当する。３Ｄベクトルの形態で観察方向を表現することができる。
【００４２】
前記リストは、前記サーバによって、または前記ネットワークの中間要素によって管理される。
【００４３】
例えば、サーバとクライアントとの中間にあるプロキシサーバによってリストを管理することができる。そして、クライアントキャッシュのコンテンツの状態を決定するために、サーバは、リクエストをプロキシに送信する。この解決策の性能は、より多くの情報交換を生成するという点でかなり劣るが、サーバとプロキシとが高性能ネットワークによって接続されており、（例えば、サーバの容量が低い場合など）サーバを「軽減する（relieve）」ことが要求される場合には、興味深い場合がある。
【００４４】
本発明の１つの好適な実施形態によれば、このタイプの方法は、前記サーバに初期表示情報が送信される前記クライアント端末の各々の第１の送信ステップと、前記サーバが、前記対応するコンテキストに前記初期表示情報を格納する格納ステップとを伴う予備初期化段階(preliminary initialization phase)を含む。
【００４５】
また、前記予備初期化段階は、前記クライアント端末によって再生されるシーンのきめの粗いバージョンを送信するために、前記サーバが前記クライアント端末に送信を行う第２の送信ステップをさらに含むことが有益である。
【００４６】
したがって、本発明によれば、従来技術による解決策と異なり、クライアントが表示を望むオブジェクトを含むデータベースのすべてが初期化時に送信されるわけではないので、クライアントのメモリとネットワークの通過帯域との観点から著しい節減を図ることができる。データベースが約１００Ｍｂｉｔｓであり、クライアントとサーバとが最大速度５００ｋｂｉｔｓ／秒のＡＤＳＬ「非対称ディジタル加入者線（Asymmetric Digital Subscriber Line）」タイプのネットワークによって接続されているとする。したがって、クライアントとサーバとの間の接続が初期化されると、クライアントで表示される全シーンをロードするのに必要な全ベースが送信され、それには少なくとも２００秒かかる。本発明では、初期化時にこのような送信を行う必要がなく、したがって、ほぼ瞬時に少なくともシーンのきめの粗い表現を表示できるため、従来技術によって課されていた３分を超える少なくとも２００秒の長い待機時間がなくなるという点から、本発明は、クライアントにとって特に有益である。
【００４７】
所定の時間間隔で、および／または、前記表示情報の修正時に、前記クライアント端末の各々が、前記表示情報アイテムの少なくともいくつかを前記サーバに転送するステップを実行することが好ましい。
【００４８】
最後の送信以降の情報が修正されていれば、所定の時間間隔で表示情報を転送することからなる選択によって、送信の数が最小限に抑えられることに留意されたい。
【００４９】
本発明の第１の有益な実施形態によれば、前記所定の時間間隔が、前記クライアント端末によって固定される。
【００５０】
特に、例えば、クライアントが表示されるシーンをリフレッシュさせたい場合には、周波数に応じて、クライアントによって前記所定の時間間隔を要求することができる。
【００５１】
本発明の第２の有益な実施形態によれば、前記所定の時間間隔が、前記通信ネットワークの少なくとも１つの特徴によるものである。
【００５２】
特に、これらの時間間隔は、ネットワークロード、または、例えば、そのスループットや待ち時間によるものでありうる。
【００５３】
前記クライアント端末によって実行される前記転送ステップの終わりに、前記方法が、対応する前記コンテキスト内の前記表示情報を更新するステップを実行することが好ましい。
【００５４】
前記更新ステップの終わりに、前記サーバが、
前記更新された表示情報の少なくともいくつかに応じて、前記クライアント端末に必要な少なくとも１つの識別子オブジェクトＯおよび対応する再生レベルＬ0を決定する決定ステップと、
前記クライアント端末に関連付けられた前記キャッシュメモリを表す前記リストを分析して、存在すれば、前記識別オブジェクトＯと、前記クライアント端末に必要な再生レベルＬ0に対応し、前記リストに記憶されていないペア＜Ｏ，Ｌ0＞を特定するステップと、
前記リストに記憶されていない前記ペア＜Ｏ，Ｌ0＞の任意のものに対応する、前記クライアント端末が必要とする再生レベルＬ0とともに、存在すれば、前記識別子オブジェクトＯとを、前記クライアント端末に送信するステップと、
存在すれば、送信された前記オブジェクトに対応する前記ペア＜Ｏ，Ｌ0＞を前記クライアント端末に追加して、前記クライアント端末に関連付けられた前記キャッシュメモリを表す前記リストを更新するステップと
を実行することが有益である。
【００５５】
クライアントに必要な1以上のオブジェクトを決定するためのステップは、クライアントのコンテキストに格納された情報に応じて、サーバによって実行される算出の結果でありうる。また、このタイプの計算は、例えば、クライアント接続がなされる前に、サーバに関連付けられた独立計算エンティティによって実行可能である。そして、決定ステップは、クライアントに関連付けられた表示情報に応じて必要とされるオブジェクトを特定するように、サーバがこの計算の結果を見ることからなる。したがって、従来技術による技術を比較すると、本発明により、クライアントの端末からサーバに、またはそれに関連付けされた算出エンティティに、クライアントに必要なオブジェクトの計算を転送する手段が得られる。
【００５６】
また、前記サーバは、
少なくとも１つの見込み基準に従って、前記クライアント端末にとって必要な可能性がある少なくとも１つの識別子オブジェクトＯおよび再生レベルＬ0を決定するステップと、
前記少なくとも１つの識別子オブジェクトＯおよび再生レベルＬ0を、前記クライアント端末に前もって送信するステップと
をさらに使用できることが有益である。
【００５７】
例えば、オブザーバが、前の置換の変動に応じて、シーンのオブジェクトの方向へと移動している見込みをサーバが評価し、この見込みが所定のしきい値より大きい場合には、サーバは、同じ方向に移動を継続していれば、クライアントが近い将来必要とするオブジェクトを送信する主導権をとる。
【００５８】
前記サーバによって送信される少なくとも１つのオブジェクトを受信すると、前記クライアント端末は、
前記クライアント端末に関連付けられた前記キャッシュメモリの充填率が、所定のしきい値より低ければ、前記キャッシュメモリに前記受信したオブジェクトを格納するステップと、
そうでなければ、前記受信したオブジェクトの関連基準（relevance criterion）を評価するステップとを実行するものであり、
前記キャッシュメモリに格納された前記オブジェクトの少なくとも１つが、前記受信したオブジェクトの前記関連基準より小さい値の関連基準を有していれば、前記クライアント端末が、前記キャッシュメモリから前記値が小さな関連オブジェクトを除外するサブステップと、前記キャッシュメモリに前記受信したオブジェクトを格納するサブステップとを実行し、
そうでなければ、前記クライアント端末が、前記受信したオブジェクトを拒絶するサブステップを実行することが好ましい。
【００５９】
例えば、このような関連基準は、オブジェクトからオブザーバまでの距離によるものでありうる。
【００６０】
本発明の１つの有益な特徴によれば、前記除外サブステップおよび／または前記拒絶サブステップの後に、前記クライアント端末は、前記クライアント端末に関連付けられた前記キャッシュメモリを更新するための少なくとも１つの情報アイテム（項目）を、前記サーバに送信することによって、前記サーバは、前記除外サブステップ中に除外された前記オブジェクト、および／または、前記送信ステップ中に前記サーバによって送信されたオブジェクトに対応するが、前記キャッシュメモリには記憶されていない少なくとも１つの＜Ｏ，Ｌ0＞のペアを、前記キャッシュメモリを表す前記リストから除外する。
【００６１】
前記オブジェクトの少なくともいくつかは、少なくとも１つのインデックスを含むことにより、前記関連付けされたインデックスから始まる前記オブジェクトの一部分を選択的に送信できることが好ましい。
【００６２】
特に、これらのオブジェクトは、例えば、以下のタイプ、すなわち、
２Ｄイメージ、
メッシュ、
テクスチャ、
サウンド、
幾何学的モデル、
３Ｄシーン、
ビデオデータ、
ページ付けデータ、
からなるタイプの１つでありうる。
【００６３】
このリストは、完全なものではなく、例示目的のみのものであることは明らかである。
【００６４】
また、本発明は、少なくとも１つの通信ネットワークを介したサーバと少なくとも１つのクライアント端末との間での、オブジェクトと呼ばれるデータの送信システムであって、前記サーバによって送信された前記オブジェクトの少なくともいくつかを格納するようにされた少なくとも１つのキャッシュメモリが、前記ネットワーク内の前記クライアント端末の少なくとも１つに関連付けられた送信システムに関する。
【００６５】
本発明によれば、このタイプのシステムは、前記クライアント端末と前記サーバとの間で、前記キャッシュメモリのコンテンツに関する情報交換を制限するために、前記クライアント端末の入力側で、前記クライアント端末の１つに関連付けられた前記キャッシュメモリに存在するオブジェクトの少なくとも１つのリストを管理するための管理手段を含む。
【００６６】
また、本発明は、少なくとも１つの通信ネットワークを介して少なくとも１つのクライアント端末に接続された、オブジェクトと呼ばれるデータ用のデータサーバであって、前記サーバによって送信された前記オブジェクトの少なくともいくつかを格納するように与えられた少なくとも１つのキャッシュメモリが、前記ネットワーク内の前記クライアント端末の少なくとも１つに関連付けられたデータサーバに関する。このタイプのサーバは、前記キャッシュメモリのコンテンツに関係する情報に関して、前記関連付けられたクライアント端末との情報交換を制限するために、前記クラアント端末の少なくとも１つに関連付けられた前記キャッシュメモリに存在するオブジェクトの少なくとも１つのリストを管理する手段を含む。
【００６７】
また、本発明は、前記端末に関連付けられた前記キャッシュメモリを表す前記リストを前記サーバが更新できるように、更新情報の少なくとも１つのアイテム（項目）を前記サーバに送信する手段を含む上述したようなデータサーバのクライアント端末に関する。
【００６８】
本発明の他の特徴および利点は、例示的で非制限的な例として単に挙げた好適な実施形態の詳細な記載を読み、添付の図面を参照することにより、さらに明らかになるであろう。
【発明を実施するための最良の形態】
【００６９】
本発明の一般的な原理は、クライアント端末がオブジェクトリクエストをアドレス指定するサーバと、そのクライアント端末自体との間での情報交換を減少するように、この端末に関連付けられたキャッシュメモリに存在するオブジェクトリストを、クライアント端末の入力側（アップストリーム）から管理することに基づく。
【００７０】
本願明細書の以下の記載では、クライアントによってシーンのリアルタイム表示用に、通信ネットワークを介した順次データ送信への本発明の特定の応用について記載する。（なお、本発明は、オブジェクトの表示に限定されるものではなく、サウンドオブジェクトを聴くことなどにも適用することができる。）
【００７１】
以下、図１を参照しながら、本発明のコンテキスト内で使用できる１つの例示的なネットワークアーキテクチャについて記載する。
【００７２】
このタイプのネットワークアーキテクチャは、クライアント・サーバアーキテクチャである。キャッシュ１はクライアント２と関連付けられている。このキャッシュ１は、サーバ３により送信されるデータを、通信ネットワーク４を介して格納できるようにする。
【００７３】
キャッシュ１に格納されるデータは、「現在」のデータ（言い換えれば、クライアント端末２によって使用中のデータ）、または「未来」のデータ（言い換えれば、後で使用する予定のデータ）、または「過去」のデータ（言い換えれば、すでに使用したが、少なくとも一時的に使用されていないデータ）でありうる。
【００７４】
クライアント端末２内へとキャッシュ１を組み込むことができ、または、ネットワーク内の別のポイントにキャッシュ１を設置して、クライアント端末２に単に関連付けることができ、例えば、図１に図示していないサーバ３とクライアント２との間の中間サーバ、特に、プロキシタイプのサーバへとキャッシュ１を組み込むことができる。本発明の１つ別の実施形態において、いくつかのクライアント２によってキャッシュ１を共有することができる。単純化の理由から、本願明細書の以下の記載は、クライアント端末２にキャッシュ１を組み込んだ本発明の特定の実施形態を記載することに限定する。
【００７５】
クライアント端末２は、表示されるシーンでのクライアントの位置などの視覚や、観察方向や、オブジェクト選択しきい値や、視野などの表示または再生されるオブジェクトの選択パラメータに応じて、スクリーン上に表示されるオブジェクトの選択に必須な情報セットを管理する。
【００７６】
サーバ３は、クライアント２が表示したいオブジェクトセットがグループ化されたデータベース５を管理する。これらのオブジェクトは、サーバ３とクライアント２との両方によって認識可能なデータベース５内で、単一の識別子によって参照されることが好ましい。例えば、これらのオブジェクトは、好ましくは、順次送信、サウンド、または他のタイプの生データを有する３Ｄメッシュでありうる。また、データベース５は、クライアント端末２によりシーンの再生に必要な異なる特性のいくつかのオブジェクトを含み、例えば、クライアント２がクラシック音楽のコンサートを表示したければ、データベース５は、シーンをグラフィック的に再生するための３Ｄオブジェクトと、楽器によって生成される音を再生するための３Ｄサウンドとを含みうる。
【００７７】
本発明の１つの好適な実施形態によれば、図２に示すように、サーバ３は、クライアント２のキャッシュ１を参照するリスト６をさらに管理する。本発明の１つの変形例によれば、このリスト６は、サーバ３で管理されず、例えば、クライアント２とサーバ３との間の中間にある図２には図示していないプロキシサーバにおいて、クライアント端末２の入力側で管理される。単純化の理由のために、本明細書の以下の記載では、リスト６がサーバ３によって管理される本発明の特定の実施形態を簡単に記載するが、本明細書によれば、当業者が、リスト６がクライアント端末２のアップストリームにあるサーバ３の外側で管理される場合である本発明の実施形態を容易に想定できるであろう。
【００７８】
リスト６は、ペア＜Ｏ，Ｌ0＞のセットからなり、Ｏはオブジェクト識別子であり、Ｌ0は、クライアント端末２に転送された考慮されたオブジェクトの再生レベルに対応する。図４および図５を参照すると、本明細書の以下の記載に示すように、使用されるオブジェクトＯのタイプによって、Ｌ0はいくつかの別個の形態のものでありうる。
【００７９】
サーバ３は、図２に示されていないクライアントコンテキスト内において、リスト６と関連して、クライアント端末および／またはクライアント２に関する情報セットを管理することができる。例えば、この情報は、表示されるシーンに関連付けられたベースでのクライアントの位置と、クライアントの観察方向と、表示されるオブジェクトの選択パラメータ（特に、選択しきい値およびシーンにおけるオブジェクトの視野）とからなる。
【００８０】
本発明の文脈中において、図２に提示されたアーキテクチャは、表示されるデータの選択のいくつかの計算をクライアント端末２からサーバ３に転送するために使用することができ、これによって、クライアント２とサーバ３との間での交換が有益に減少される。本発明のこの態様は、図３を参照しながら、本明細書の以下の記載においてより詳細に記載される。
【００８１】
図２のアーキテクチャの状況において、図７を参照しながら、サーバ３とクライアント２との間のダイアローグの初期化段階（initialisation phase）中に伴う異なるステップについて記載する。したがって、クライアント２がサーバ３に接続されるとき、サーバ３を初期化するために、いくつかのデータが送信される。
【００８２】
ステップ参照番号７１の間に、クライアント端末２は、（特に、クライアント２が得たい詳細レベルに応じて）例えば、表示されるシーンにおけるクライアントの位置、クライアントの方向、視野、またはオブジェクト選択しきい値などの初期表示情報をサーバ３に送信する。選択しきい値のタイプは、本明細書において以下に記載して示すように、考慮するオブジェクトタイプに応じて変動できることに留意されたい。
【００８３】
格納ステップ７２において、サーバ３は、クライアント端末２に関連付けされたコンテキストの初期受信表示情報を格納する。
【００８４】
そして、サーバ３は、マッピングとも呼ばれる動作において、再生されるシーンのきめの粗いバージョンをクライアント端末２に送信する（ステップ７３）。このタイプのマッピングは、データベース５の基本バージョンに対応し、それによって、クライアント２は、接続の開始時に、端末において表示されるシーンの少なくともきめの粗いビューを表示することができる。
【００８５】
クライアント２がこのマップを受信すると、クライアントは、特に、キャッシュ１内において、サーバ３から受信したデータの格納に必要な異なるサブキャッシュを作成することができる。
【００８６】
本発明によれば、同一のサブキャッシュにおいて、サーバ３から受信した同一のタイプのすべてのオブジェクトを格納することが決定される。表示されるシーンのすべてのオブジェクトが同じ特性をもてば、キャッシュ１内にサブキャッシュを作成する必要がない。クライアント２が地形の起伏を端末において表示する特定の例では、地形の幾何学的形状に関係するデータを格納するためのキャッシュ１内の第１のサブキャッシュと、地形のテクスチャを格納するようにされた第２のサブキャッシュとを作成することが好ましい。
【００８７】
このタイプの初期化段階の後に、クライアント２およびサーバ３は、考慮されるシーンを表示するために、クライアント２に対して、ベース５からデータを送受信することができる。
【００８８】
以下、図３および図６を参照して、クライアント端末２によって再生されるシーンの表示中のクライアント・サーバダイアローグについて記載する。
【００８９】
このような表示段階（display phase）の一般的な原理は、サーバ３がクライアント２に関連付けられたコンテキストに格納した後に、シーンを表示し続けるのに必要なデータまたはオブジェクトをクライアント２に送信するために使用する、サーバ３へのクライアント２の送信情報に基づく。
【００９０】
この情報は、異なる特性のものからなり、特に、異なる頻度でクライアント２によって修正することができる。したがって、再生されるシーンにおけるクライアントの位置に関する情報およびクライアントの観察方向は、シーンが表示される限り修正され、それは、クライアント２が、または、より正確に言えば、クライアントに関連付けられた仮想オブザーバが、シーンを動き回ってその周りをみるからである。
【００９１】
クライアント２からサーバ３へのこのような情報の送信は、図３の実線で示す矢印で表される。これは、クライアント２によって規定可能な頻度（例えば、５秒間隔）で実行され、または、ネットワーク４およびクライアント端末２の容量に応じて決定することができる（例えば、表示情報が送信される頻度を、高速ネットワークの場合には２秒間隔に固定でき、低速ネットワークの場合には６秒間隔に固定できる）。また、この情報の送信（ａ）は、クライアント２とサーバ３との間での交換回数（ａ）を制限するために、イベント関連の基準によることが有益である。つまり、位置および観察方向の情報の送信（ａ）は、この情報がサーバ３に送信された（ａ）最後の時間以降に修正されていない場合には発生しないことになる。
【００９２】
例えば、位置および観察方向の情報がサーバ３に送信された最後の時間以降にクライアント２がシーン内で動いている場合には、（送信頻度が５秒で固定されている場合には）修正された情報は５秒後に再度送信される。
【００９３】
本発明によれば、クライアント２は、（ａ）の送信時にサーバ３からの応答を待たないので、（例えば、ＵＤＰ（ユーザデータグラムプロトコル）タイプの）非接続モードでこの送信を行うことができる。
【００９４】
図６に示すように、クライアント２によって送信される方向および位置情報が受信されると（ステップ６１）、サーバ３は、クライアント２に関連付けられたコンテキストを更新し（ステップ６２）、新しい受信位置および方向情報をコンテキストに記憶する。
【００９５】
送信されるオブジェクトの選択パラメータなどの他の情報や、キャッシュ１の更新情報は、イベント関連基準、すなわち、この情報の修正により送信されることが好ましい。クライアント２からサーバ３へのこのタイプの送信は、図３の破線で示す矢印（ｂ）で表される。受信すると、（キャッシュ更新情報の）リスト６、または、より一般的に、クライアント２に関連付けられたコンテキストのいずれかに、サーバ３がこの情報を格納する。
【００９６】
したがって、
サーバ３によって送信される新しいオブジェクトを格納するために、1以上のオブジェクトがクライアント端末２によってキャッシュ１から削除されるか、または、
サーバ３によって送信された1以上のオブジェクトが、クライアント端末２によって拒絶された場合には、
キャッシュ１（または、キャッシュ１のサブキャッシュの１つ）に存在するオブジェクトに対応する＜Ｏ，Ｌ0＞のペアのリストの形態で、クライアント２のキャッシュ１の更新情報はサーバ３に送信される。
【００９７】
サーバ３によって送信されたオブジェクトを受信した後に、クライアント端末２によって行われる方法を示した図８を参照して、以下に、これらの態様についてさらに詳細に記載する。
【００９８】
Ｏはシーンのオブジェクトの識別子を表し、Ｌ0はオブジェクトＯの再生詳細レベルに関する情報である。Ｌ0の構造は、オブジェクトタイプＯおよび関連付けされた詳細レベルをコード化するために使用される方法によることは明らかである。したがって、Ｌ0は、図４および図５を参照して以下に記載するように、（例えば、本発明は、ＨＬＯＤ「階層詳細レベル」タイプ技術を使用する場合の）詳細レベルを表す値、またはオブジェクトＯの幾何学的微細さをコード化した表現値のセットでありうる。
【００９９】
同様に、（例えば、オブジェクト選択しきい値、視野、またはオブジェクトの選択を修正するための任意の他の情報などの）オブジェクト選択パラメータは、この値が修正されるときに送信される。初期化段階において規定された選択しきい値を表示段階中に修正すること、例えば、シーンのより詳細な再生を行うために、クライアント２がこのしきい値を下げるように決定することが考えられる。
【０１００】
このタイプの選択しきい値は、多くのさまざまな方法により規定することができ、特に、角度や、投影ピクセルや、サイズなどで評価されうることに留意されたい。したがって、サーバ３は、クライアント端末２のスクリーン上で表示された後に、１°以上の角度で仮想オブザーバが見えるオブジェクトのみをクライアント２に送信することができる。ウェーブレットによってコード化されたメッシュに関連付けられたオブジェクトの場合には、例えば、２°以上のメッシュの変形を誘発するウェーブレット係数のみを選択するように選択しきい値を固定することができる。考慮するオブジェクトがサウンドであれば、選択しきい値は、このサウンドの周波数または持続時間によるものでありうる。クライアント２に送信される関連するオブジェクトをサーバ３が選択できる任意の他の方法により、選択しきい値とすべての他の選択パラメータとを規定することができる。
【０１０１】
クライアント２に関連付けられたコンテキストに含まれる情報（位置情報、観察方向情報、選択パラメータ、キャッシュ１のコンテンツに関する情報）によって、サーバ３は、クライアント２に視覚的に関連するオブジェクトまたはデータを送信する。この送信は、図３に示す連続的なグレー矢印（ｃ）によって表される。視覚的に関連するオブジェクトの決定は、サーバ３によって、またはネットワーク４の別のエンティティによって実行される計算から得られる。また、その決定は、サーバ３とクライアント２との間の接続が設定される前に計算されて、例えば、サーバ３のネットワーク内に記憶されていてもよい。
【０１０２】
したがって、図６に示す特定の実施形態において、サーバ３は、クライアント２のコンテキストに含まれる表示情報のいくつかまたはすべてに応じて（例えば、クライアント２の位置および観察方向情報および選択パラメータに応じて）、クライアント端末２に必要なオブジェクトＯを適切な再生レベルで決定する（ステップ６３）。
【０１０３】
そして、サーバ３は、受信した最新の更新データに応じて更新された、クライアント端末２のキャッシュ１に関連付けられたリスト６を分析し（ステップ６４）、クライアント２に必要なオブジェクトが、適切な微細レベルＬ0において、クライアント２のキャッシュ１にすでに格納されているか否かを決定する。
【０１０４】
格納されていなければ、サーバ３は、このオブジェクトまたはこれらのオブジェクトをクライアント端末２に送信する（ステップ６５）。
【０１０５】
本発明によれば、サーバが近い将来に必要になるであろうと予測すれば、クライアント２に現在必要ではないオブジェクトをサーバ３が送信できる（ｃ）ような予想方法を実行することもできる。例えば、サーバ３が、クライアント２が同じ方向に数回移動したと決定すれば、クライアント２に関係していないが、クライアント２が同じ方向に沿って移動し続けていれば、クライアントの視野に間もなく入るであろうオブジェクトをこのクライアント２に送信することができる。
【０１０６】
この送信（ｃ）の時に、サーバ３は、クライアントに送信されるすべてのデータがキャッシュ１に格納されたことを考慮しながら、ペア＜Ｏ，Ｌ0＞の形態でクライアント２に送信（ｃ）されたデータを追加することによって、クライアント２に関連付けられたリスト６を修正する。この更新ステップは、図６において、ステップ参照番号６６によって示される。リスト６のこのタイプの修正は、送信冗長を最小限に抑えることが有益である。クライアント２にサーバ３によって送信（ｃ）されたいくつかのデータが、例えば、ネットワークに関係する送信エラーの場合には、キャッシュ１に格納されず、キャッシュ１の状態とリスト６との間に一貫性が欠けることになる場合がある。本発明がこの問題を解消する方法を含むことは有益である。以下に図８を参照してさらに詳細に記載するように、キャッシュ１の状態とリスト６との間の一貫性が維持される。
【０１０７】
以下、図４Ａから図４Ｃを参照しながら、幾何学的ウェーブレットによってコード化された三次元モデルのクライアント２による例示的な表示について記載する。ベースメッシュに追加された詳細の連続としてメッシュを表すように、「ウェーブレット」コード化方法が使用されると留意されたい。この技術の一般的な理論は、Ｍ．Ｌｏｕｎｓｂｅｒｙ，Ｔ．ＤｅＲｏｓｅおよびＪ．Ｗａｒｒｅｎによる論文「Ｍｕｌｔｉｒｅｓｏｌｕｔｉｏｎ  Ａｎａｌｙｓｉｓ  ｆｏｒ  Ｓｕｒｆａｃｅｓ  ｏｆ  Ａｒｂｉｔｒａｒｙ  Ｔｏｐｏｌｏｇｉｃａｌ  Ｔｙｐｅ」（ＡＣＭ  Ｔｒａｎｓａｃｔｉｏｎ  ｏｎ  Ｇｒａｐｈｉｃｓ、Ｖｏｌ．１６、Ｎｏ．１、ｐｐ．３４−７３、Ｊａｎｕａｒｙ  １９９７）において特に記載される。
【０１０８】
上述したように、クライント・サーバダイアローグの初期化段階の後に、サーバ３は、ベース５のマッピングと呼ばれるきめの粗いバージョンをクライアント端末２に送信する。（図４Ａから図４Ｃに示す）３Ｄモデルのセットからなるベース５の場合には、例えばベース５の異なるオブジェクトの位置およびサイズについて、例えばこれらのオブジェクトの周りにあるボックス４１Ａおよび４２Ａの位置およびサイズの形態で、このマッピングは、クライアント端末２に通知する値のセットに対応する。
【０１０９】
これらのオブジェクトの視感度によって（言い換えれば、これらが、オブザーバの視野において部分的または全体的に存在するか否か、オブザーバからの距離などに応じて）、サーバ３は、これらのオブジェクトのメッシュ４１Ｂ、４２Ｂをクライアント２に送信する。そして、これらのベースメッシュ４１Ｂ、４２Ｂを用いて、クライアント２は、サーバ３から生じたデータの格納に必要な異なるサブキャッシュを構築し、ペア＜Ｏ，Ｌ0＞の対応する初期リストを作成する。
【０１１０】
図４Ａから図４Ｃの例において、ベースメッシュ４１Ｂ、４２Ｂの各々は、ｎ個の面を含むと考えられる。したがって、クライアント２に対してサーバ３によって管理されたリスト６は、ペア＜Ｏ，＜Ｎ１，．．．，Ｎｎ＞＞のセットからなることになり、Ｏは、オブジェクト識別子を表し、Ｎｉは、ベースメッシュ４１Ｂ、４２Ｂの面ｉのキャッシュ１に存在するウェーブレット係数の数を表す。ベースメッシュ４１Ｂ、４２Ｂが送信されると、ｉ［１，ｎ］のＮｉ値はすべてゼロに初期化される。
【０１１１】
各面についてのウェーブレット係数のソート順序が前もって決定されていれば、サーバ３が、クライアント２のキャッシュ１に存在するウェーブレット係数を正確に決定するには、ｉ∈［１，ｎ］のＮｉ値を正確に分かっていればよいことに留意されたい。したがって、クライアント２が、図３のステップ（ｂ）の間に、メッシュ４１Ｂの面Ｎｏ．８に対して３０個の係数があることをサーバ３に通知すれば、サーバ３は、３１番目の係数から始まりメッシュ４１Ｂの面Ｎｏ．８に関連付けられる、クライアント２に関連する係数の送信を開始することになる。位置情報や観察方向情報や選択パラメータなどの、クライアントコンテキストに記憶された表示情報が関連係数の選択には考慮されることに留意されたい。
【０１１２】
各メッシュ面に対して係数が格納される順番は、クライアント端末２に到着した順序のままであることが好ましい。
【０１１３】
クライアント端末２は、ベースメッシュ４１Ｂ、４１Ｃの可視面の各々に対して、サーバによって送信された係数から始まり、シーンのオブジェクトの詳細な表示４１Ｃ、４２Ｃを再構築することができる。
【０１１４】
以下、非順次詳細レベルを用いたオブジェクトに対して、図５を参照して、本発明の第２の例示的な実施形態を示す。オブジェクトまたはオブジェクトの部分がユーザの視点に応じて選択的に改良できるウェーブレットコード化技術を用いた前述の例と異なり、以下に、４つの連続的な詳細レベル参照番号５１〜５４によって表されたオブジェクトの場合を示す。
【０１１５】
図４Ａから図４Ｃの例にあるように、サーバ３は、どのデータが表示されるべきかを知るためにクライアント２が使用することになるデータベース５のマッピングをクライアント２に送信することによって始動する。そして、サーバ３は、見えると考えられるベース５の各オブジェクトに対して、このオブジェクトの最低詳細レベル５４（言い換えれば、オブジェクトの最もきめの粗いバージョン）をクライアント２に送信する。サーバ３は、シーン内でのクライアント２の位置によって、より高い詳細レベル５３から５１を表示中に送信する。このようにして、クライアント２が、図５のオブジェクトの方に次第に移動すれば、サーバ３は、オブザーバからオブジェクトまでの距離に応じて、詳細レベル５３、そして詳細レベル５２、そして詳細レベル５１を段階的に送信する。
【０１１６】
オブジェクトＯに関連付けられた微細レベルＬ0のコード化は、使用中のアプリケーションにより課される制約、特に、オブジェクトが関連付けされた詳細レベルの順序で送信されることが必須か否かによる。
【０１１７】
したがって、サーバ３が、微細レベルの順序でオブジェクトをクライアント２に送信する必要があれば、オブジェクトＯに対してキャッシュ１に存在する最高詳細レベルの値に等しいＬ0を設定することが決定される。キャッシュ１が、オブジェクトに対して微細レベル参照番号５４（微細レベル０および５３（微細レベル１）を含めば、Ｏ，Ｌ0は、値「１」に等しくなる。そして、リスト６は、ペア＜Ｏ，「１」＞を含み、サーバ３は、キャッシュ１がオブジェクトＯに対して微細レベル０および１を含むと推測する。そして、必要に応じて、次に高い詳細レベル、言い換えれば、微細レベル「２」に対応するレベル参照番号５２のみをクライアント２に送信する。
【０１１８】
サーバ３からクライアント２への送信が、成功レベルの順序でなされる必要がなければ、Ｌ0は、クライアントのキャッシュ１において、オブジェクトＯに対して記憶されたすべての微細レベルを表す。例えば、数ビットでＬ0をコード化することを選択することができ、クライアント２のキャッシュ１に記憶された詳細レベルにＬ0での位置が対応するビットは、値１に等しい。図５の例において、クライアント２のキャッシュ１が、表示参照番号５４および５２にそれぞれ対応する微細レベル「０」および「２」を含む場合には、Ｌ0は０１０１に等しくなる。そして、サーバ３は、（特に、考慮するオブジェクトからの距離と観察方向などの）シーン内のユーザの位置によって、表示参照番号５３および５１のそれぞれに対応した詳細レベル１および３を送信可能であることが分かる。
【０１１９】
同様に、８個の連続した詳細レベルが関連付けられたオブジェクトを考慮するとき、クライアント２のキャッシュ１が、このオブジェクトに対して詳細レベル１、２、４、および７を含む場合には、Ｌ0の値は「０１００１０１１」になる。そして、サーバ３は、関連付けされたコンテキストに格納された表示情報に基づいて、レベル３、５、６、および８をクライアント２に送信可能であることが分かる。
【０１２０】
Ｌ0のこのタイプのコード化は、面からなる３Ｄオブジェクトに対して制限されているが、例えば、マルチ解像度テクスチャなど、非順次詳細レベルからなる任意のタイプのデータに適用できることに留意されたい。
【０１２１】
サウンドやビデオタイプの生データの場合、または（在庫管理や人事管理などの）ページ付けデータの場合に関し、本発明の第３の例示的な実施形態について簡潔に記載する。
【０１２２】
例えば、サウンドタイプの生データの場合には、サーバ３がマッピングを送信する必要がないことがある。また、このことは、サーバ３が、時間内にデータセットを送信し、例えば、３０秒以内にバイオリンの音が演奏または再生すべきであることをクライアント２に知らせることに該当する。このタイプのサウンドオブジェクトの場合には、再生情報Ｌ0は、例えば、送信されるデータパーセンテージに相当する。したがって、サーバ３は、例えば、２分３０秒間続く音のうちの最初の１５秒がクライアント２のキャッシュ１に格納されていることをＬ0の値により知ることができる。
【０１２３】
ページ付けデータの場合には、初期化中にサーバ３によって送信されるマッピングは、例えば、データベース５の各データに対して存在するページ総数に対応するものでありうる。この場合には、再生情報Ｌ0は、形態＜Ｎ，Ｎ0，．．．，Ｎｎ＞の可変データであってよく、Ｎは、このオブジェクトに対する既知のページ番号（言い換えれば、このオブジェクトに対してクライアントキャッシュに格納されたページ数）を表し、Ｎｉは、ｉ番目のページの名称を示す。
【０１２４】
図８を参照して、図３の送信参照（ｃ）の間にサーバ３によって送信される1以上のオブジェクトＯRの受信８１において、クライアント端末２によって実行される異なるステップを記載する。単純化の理由により、サーバ３が１つのオブジェクトＯRをクライアント２に送信する場合について記載する。いくつかのオブジェクトＯRが、クライアント２および／またはキャッシュ１によって受信される場合に使用される技術は、この場合から容易に推測されるであろう。
【０１２５】
参照番号８２のステップの間に、クライアント端末は、それに関連付けられたキャッシュ１の充填率をチェックする。キャッシュ１が端末２に組み込まれていなければ、キャッシュ１の管理に責任のあるエンティティ、例えば、キャッシュ１が組み込まれているプロキシサーバによって、このチェックが実行される。
【０１２６】
キャッシュ１の充填率が、所定の充填しきい値より小さければ、すなわち、キャッシュ１に1以上の新しいオブジェクトを格納可能であることを示せば、受信したオブジェクトＯRは、クライアント２のキャッシュ１に記憶される（ステップ８３）。
【０１２７】
そうでなければ、既存の状態において、キャッシュ１にサーバ３から受信したオブジェクトＯRを格納することができない。そして、キャッシュ１に、オブザーバの受信したオブジェクトＯRより視覚的に関連性が低いオブジェクトＯSがあるかが決定される（ステップ８４）。例えば、最新の変位またはクライアント２の観察方向の変化に起因して、このタイプのオブジェクトＯSは、クライアント２の視野外のオブジェクトでありうる。
【０１２８】
このタイプの関連性の低いオブジェクトＯSがあれば、そのオブジェクトをキャッシュ１から削除することによって（ステップ８６）、サーバ３から受信した新しいオブジェクトＯRをキャッシュ１の適所に格納することができる。
【０１２９】
そして、クライアント端末２は、キャッシュ１の状態を更新するための情報を送信し（ステップ８７）、このオブジェクトＯSをキャッシュ１から削除し、オブジェクトＯRがこれに相応して格納されたことをサーバ３に示す。
【０１３０】
一方で、キャッシュ１に格納されたすべてのオブジェクトが、サーバ３から受信したオブジェクトＯRよりも視覚的に関連性があれば、キャッシュ１の管理に責任のあるエンティティ（例えば、クライアント端末２）は、このオブジェクトＯRを拒絶することになる。
【０１３１】
そして、クライアント端末２は、キャッシュ１の状態に関する更新情報を送信し（ステップ８７）、キャッシュ１にオブジェクトＯRを格納できないことをサーバ３に知らせる。
【０１３２】
また、サーバ３は、この更新情報を用いて、キャッシュ１の状態とそのコンテンツを表すリスト６とを保持する。この更新情報を受信した後に、特に、クライアント２に送信され、またはリスト６に追加されたすべてのオブジェクトが、サーバ３は、クライアント２および／またはキャッシュ１によってエラーなしに実際に受信されたことをチェックすることができる。特に、このことによって、ネットワーク４の障害に関連する送信問題を追跡することができる。
【０１３３】
したがって、サーバ３は、クライアント２から受信した更新情報およびリスト６を比較して、それらが一致しており、受信した更新情報に応じてリストを更新するのに適用可能であるかをチェックする。
【図面の簡単な説明】
【０１３４】
【図１】本発明を実施するのに適したクライアント・サーバアーキテクチャを示すブロック図である。
【図２】オブジェクトリスト管理ブロックをサーバに追加して完了した、本発明による図１のアーキテクチャを示すブロック図である。
【図３】本発明により使用されるクライアント・サーバダイアローグの一例を示す概略図である。
【図４】Ａ〜Ｃは、幾何学的ウェーブレットによってコード化された３Ｄモデルのコンテキスト内における本発明の１つの例示的な実施形態を示す概略図である。
【図５】非順次詳細レベルを用いたオブジェクトの本発明の１つの実施形態の第２の例を示す概略図である。
【図６】表示段階における本発明によりサーバによって使用される異なるステップのブロック図を示す流れ図である。
【図７】初期化段階における本発明により使用される異なるステップを示す流れ図である。
【図８】クライアント端末によるオブジェクトの受信中に本発明により使用される異なるステップを示す流れ図である。
【図１】
2005513658.tif 000003
【図２】
2005513658.tif 000004
【図３】
2005513658.tif 000005
【図４】
2005513658.tif 000006
【図５】
2005513658.tif 000007
【図６】
2005513658.tif 000008
【図７】
2005513658.tif 000009
【図８】
2005513658.tif 000010
【国際調査報告】
2005513658.tif 000011
2005513658.tif 000012
2005513658.tif 000013
2005513658.tif 000014
2005513658.tif 000015
2005513658.tif 000016