第1のコンテンツを第2のコンテンツをレンダリングするノードに送信する装置であり、前記第1及び第2のコンテンツは、それぞれのサービスにそれぞれ関連付けられている装置であって、前記第1のコンテンツに関連付けられた前記サービスが前記第2のコンテンツに関連付けられた前記サービスと共通するか否かを判定し、前記第1及び第2のサービスが共通のサービスであることに応じて、前記第1のコンテンツを送信させ、前記ノードにより処理させるように構成された処理段を含む装置。前記装置は、前記ノードへの先の送信のためにサービスモジュールからのコンテンツを通信ネットワークで受信するインタフェース段を含む、請求項1に記載の装置。前記処理段は、前記サービスモジュールから受信した要求に応じて、前記第1及び第2のコンテンツが共通のサービスに関連付けられているか否かを判定するように構成され、前記要求は、前記第1のコンテンツに関連付けられた前記サービスの指標を含む、請求項2に記載の装置。前記処理段は、前記第1及び第2のコンテンツが共通のサービスに関連付けられていることの肯定的又は否定的指標のうちいずれか1つで、前記サービスモジュールからの前記要求に応答するように構成される、請求項3に記載の装置。前記ノードからサービス要求を受信するように構成された通信段を含み、前記処理段は、記憶装置を有し、前記ノードから少なくとも最後に受信したサービス要求に関連付けられた前記サービスの指標を格納するように構成される、請求項1ないし4のうちいずれか1項に記載の装置。前記処理段は、コンテンツ要求を生成するように構成され、前記通信段は、前記コンテンツ要求を前記ノードに送信するように構成され、前記コンテンツ要求は、前記ノードに対して、前記ノードにおいて前記第2のコンテンツに関連付けられた前記サービスの指標で応答させるように構成される、請求項1ないし5のうちいずれか1項に記載の装置。前記処理段は、前記第1及び第2のコンテンツが前記ノードからの前記応答を使用して共通のサービスに関連付けられているか否かを判定するように構成される、請求項6に記載の装置。前記第1のコンテンツ及び前記第2のコンテンツに関連付けられた前記サービスは、識別情報が一致したサービスに関係する場合、共通である、請求項1に記載の装置。第1のコンテンツを第2のコンテンツをレンダリングするノードに提供する方法であり、前記第1及び第2のコンテンツは、サービスモジュールからの所与のサービスにそれぞれ関連付けられている方法であって、前記第1のコンテンツの前記所与のサービスが前記第2のコンテンツの前記所与のサービスと共通するか否かを判定するステップと、前記第1及び第2のサービスが共通のサービスであることに応じて、前記第1のコンテンツを前記ノードに送信するステップとを含む方法。前記第1のコンテンツ及び前記第2のコンテンツに関連付けられた前記サービスは、前記第1のサービスの識別情報が前記第2のサービスの識別情報に一致した場合、共通である、請求項9に記載の方法。前記ノードがサービスに関連付けられたコンテンツを受信するためにコンテンツ要求を送信するように構成され、前記方法は、要求されたコンテンツが関連付けられた少なくとも最後のサービスの指標を格納するステップを含む、請求項10に記載の方法。前記最後に要求されたサービスの前記格納された指標が前記第1のコンテンツの前記所与のサービスと一致しない場合、前記第2のコンテンツが前記第1のコンテンツのサービスに関連付けられていないことを推測するステップを含む、請求項11に記載の方法。前記第1のコンテンツは、少なくとも部分的に無線リンクで前記ノードに送信される、請求項1に記載の装置。前記コンテンツは、ディスプレイにレンダリングされ得る画像データを含む、請求項1に記載の装置。前記ノードは、電話ハンドセットである、請求項1に記載の装置。情報をプッシュすることは、通信に必要な帯域幅を低減するという利点を有する。この理由は、情報が望まれる毎にユーザが要求を送信する必要がないからである。しかし、情報のプッシュが問題になる状況が存在し得る。本発明の一態様によれば、ノードの外部で生じた命令に応じて第1のコンテンツをノードに送信する装置が提供される。第1のコンテンツは、受信された場合、存在する場合にはノードでレンダリング表示されている第2のコンテンツの代わりに、ノードに対して第1のコンテンツをレンダリングさせるように構成される。第1及び第2のコンテンツは、それぞれのサービスにそれぞれ関連付けられており、この装置は、第1及び第2のコンテンツが共通のサービスに関連付けられているか否かを判定し、第1及び第2のコンテンツが共通のサービスに関連付けられているか否かに応じて、第1のコンテンツを送信させるように構成された処理段を含む。この装置は、第1及び第2のコンテンツが共通のサービスに関連付けられているか否かに応じて第1のコンテンツをノードに送信させるように構成されるため、第1及び第2のコンテンツが異なるサービスに関連付けられていることが判定された場合、この装置は、第1のコンテンツをノードに送信させることを控えてもよい。その結果、1つのサービスを実行しているノードが他のサービスから予想外に新たなコンテンツを受信し、新たなコンテンツが元のサービスを中断させる可能性が低減される。このことは、ノードの外部で生じた命令に応じて送信されるコンテンツの場合に特に重要になる。この理由は、通常では、ノードのユーザは新たなコンテンツの到達を予測できないからである。コンテンツは、サービスモジュールから生じてもよく、処理段は、制御命令をサービスモジュールに送信することにより、コンテンツを送信させてもよい。サービスモジュールは装置の一部でもよく、この場合、制御命令は内部命令であることが好ましい。すなわち、好ましくは、処理段は、通信段に対してコンテンツを事実上送信させる。別法として、サービスモジュールは、装置の外部に存在してもよく、通信ネットワークで装置と通信するように構成されてもよい。この場合、制御命令は、通信ネットワークで送信され、ノードに転送するコンテンツは、通信ネットワークで受信されることが好ましい。サービスモジュールはローカライズされてもよい。この場合、コンテンツは、制御命令の宛先と同じ位置から受信されることが好ましい。しかし、サービスモジュールは分散されてもよい。この場合、コンテンツの発生源と制御命令の宛先とは異なる位置に存在してもよい。サービスモジュールが遠隔に存在する場合、装置は、ノードへの先の送信のために通信ネットワークでサービスモジュールからのコンテンツを受信するインタフェース段を有することが好ましい。好ましい実施例では、コンテンツをノードに送信する前に、サービスモジュールは、ノードが第1のコンテンツすなわち、サービスモジュールが送信しようとするコンテンツに関連付けられたサービスと同じサービスを実行しているか否かの指標indicationを取得するために、装置に要求を送信するように構成される。要求は、第1のコンテンツに関連付けられたサービスの指標を含むことが好ましい。この要求に応じて、装置は第1及び第2のコンテンツが共通のサービスに関連付けられているか否かを判定するように構成されることが好ましい。処理段は、制御命令でサービスモジュールからの要求に応答するように構成される。好ましい実施例では、制御命令は、第1及び第2のコンテンツが共通のサービスに関連付けられていることの肯定的指標及び否定的指標のうち一方である。肯定的指標が受信された場合、サービスモジュールは、ノードに転送するためにコンテンツを装置に送信することが可能になる。そうでない場合、サービスモジュールは、ノードへの先の送信のためにコンテンツを装置に送信することを控える。肯定的指標又は否定的指標のうちいずれか1つを送信することにより、装置が現在実行されているサービス又はノードで最後に実行されたサービスの識別情報を明らかにする必要性が低減される。これにより、ノードのユーザのプライバシが増加する。しかし、装置は、ノードで実行されているサービスの識別情報をサービスモジュールに送信してもよく、次に、サービスモジュールは、第1及び第2のコンテンツが同じサービスに関連付けられているか否かを判定してもよい。ノードは、サービスに関連付けられたコンテンツを取得するために、サービス要求を装置に送信するように構成されることが好ましい。サービス要求は、要求されたサービスの指標を含む。通信段は、サービス要求を受信するように構成されることが好ましい。処理段は、少なくともノードから最後に受信したサービス要求に関連付けられたサービスの指標を格納するように構成されることが好ましい。ノードから送信されるサービス要求又は特定のクラスのサービス要求は、装置を通過しなければならない。しかし、更に好ましくは、サービスモジュールからのサービスが装置を通じてアクセス可能になった場合、ノードは、そのサービスのサービス要求が装置を通過しなければならないように構成される。処理段は、最後のサービスの格納された指標が所与のコンテンツのサービスに一致しない場合、ノードでの現在のコンテンツが所与のコンテンツと同じサービスの一部になり得ないことを推測してもよい。しかし、別法として又は更に、装置は、最後に実行したサービス又は実行されているサービスの指標すなわち、第2のコンテンツに関連付けられたサービスの指標で応答するようにノードに促す要求をノードに送信することにより、ノードで実行されているサービスの指標を取得してもよい。処理段は、第1及び第2のコンテンツが共通のサービスに関連付けられているか否かを判定するためにノードからの応答を使用してもよい。ノードがノードで生じている1つ以上のローカルサービス又は装置への要求なしにアクセス可能なサービスにアクセスできる場合には、このような手法は特に有用である。好ましい実施例では、ノードにアクセス可能な異なるサービス毎に、複数のサービスモジュールが提供される。1つ以上のサービスモジュールは、装置の一部でもよく、1つ以上のサービスモジュールは、ノードに存在するにしろ、通信ネットワークの異なるポイントに存在するにしろ、装置から離れていてもよい。ノードは、直接的に、又はネットワークとして構成されてもよい1つ以上のルータ及びリンクによって、無線リンクで装置と通信するように構成されたもののような、移動ノードであることが好ましい。コンテンツは、少なくとも部分的に便宜的に無線リンクでノードに送信されてもよい。更に好ましくは、ノードは、電話ハンドセットのようなハンドセットである。このようなデバイスは、しばしば限られたメモリを有しており、現在実行しているサービスに関連付けられていないコンテンツの受信がサービスを中断させる可能性を高くする。ハンドセットはディスプレイを有し、コンテンツは、ディスプレイでレンダリングされ得る画像データであることが好ましい。好ましい実施例では、コンテンツは、ディスプレイに表示するページに関係し、更に好ましくは、ディスプレイ内又はディスプレイの単一のページとしてレンダリングされ得るように構成される。装置は、一方でドメスティックデバイスdomesticdeviceへのルータ機能を有し、他方で通信ネットワークへの接続を有するホームゲートウェイでもよい。しかし、好ましい実施例では、装置はDECT基地局のような電話基地局である。本発明の他の実施例によれば、ノードの外部で生じた命令に応じて第1のコンテンツをノードに送信する方法が提供される。第1のコンテンツは、受信された場合、存在する場合にはノードで現在レンダリング表示されている第2のコンテンツの代わりに、ノードに対して第1のコンテンツをレンダリングさせる。第1のコンテンツは、所与のサービスに関連付けられており、この方法は、第2のコンテンツが第1のコンテンツの所与のサービスに関連付けられているか否かを判定し、第2のコンテンツが第1のコンテンツの所与のサービスに関連付けられているか否かに応じて、第1のコンテンツをノードに送信することを含む。本発明について一例のみとして図面を参照して更に説明する。図1に、移動端末ここでは、ハンドセット12が無線ネットワークリンク16でインタフェースモジュール32以下では、ゲートウェイと呼ばれると通信することができるシステム10が示されている。概要として、ハンドセットは、特定のサービスに関係する更新ページのようなプッシュ情報をゲートウェイ14から受信するように構成される。プッシュ方式で情報を受信することにより、情報が利用可能であるか否かを発見するためにハンドセットがゲートウェイにポーリングする必要性が低減される。これにより、帯域幅及びハンドセットの電力を節約する。しかし、プッシュ情報は、ハンドセットデバイスにより現在レンダリング表示されている情報と競合する場合には不便になる可能性がある。従って、プッシュ情報を送信する前に、ゲートウェイは、プッシュ情報がハンドセットで現在実行されているサービスに関係するか否か又はこのようなサービスと競合するか否かを判定するために、要求メッセージをハンドセットに送信するように構成される。ハンドセットは、ハンドセットで現在実行されているサービスの指標indicationでゲートウェイに応答するように構成される。ゲートウェイは、実行されているサービスがプッシュされる情報に対応するサービスに一致するか競合するかを判定するように構成される。サービスの競合が存在する場合、ゲートウェイは、プッシュ情報を送信することを控える。このようにして、プッシュ情報がハンドセットで実行されている他のサービスを中断する可能性が低減される。ハンドセットの電力及び無線帯域幅を節約するために、ゲートウェイは、少なくとも最後に提供されたサービスの識別情報を保持するように構成される。この識別情報が送信されるプッシュ情報に関連付けられたサービスの識別情報に一致しない場合、ハンドセットの現在のサービスがプッシュ情報のものと競合することが推測され、ゲートウェイは、プッシュ情報をハンドセットに送信することを控える。ハンドセットの現在のサービスがプッシュ情報と競合することを推測することにより、現在実行されているサービスを判定するために要求メッセージをハンドセットに送信する必要性が低減される。更に詳細には、ゲートウェイ14は、例えばDSL又はDigitalSubscriberLine技術を使用したツイストペア接続のような接続20で、インターネット18と呼ばれるネットワークと通信するように構成される。ゲートウェイ14は、ハンドセットに存在するブラウザ24のインタフェースとして機能するサービスマネージャ22を有する。ブラウザ及びサービスマネージャ22の双方は、WMLの種類であり、すなわち、WMLWirelessMarkupLanguageを使用して通信するように構成されるWMLは、狭帯域のデバイスを対象としたコンテンツ及びユーザインタフェースを生成する既知のドキュメント記述言語である。ブラウザ24は、無線リンク16でサービスマネージャ22に送信される情報の要求を生成する。これに応じて、サービスマネージャは、所要のフォーマットで要求された情報を返信する。ブラウザ24は、ブラウザにより使用されるフォーマットでハンドセット12のディスプレイ26に情報を表示する。キーパッド28のようなユーザ入力デバイスは、ユーザコマンドを入力するために提供される。ブラウザ24及びキーパッド28は、例えばキーパッドのコマンドがブラウザに対して情報の要求をサービスマネージャに送信させることができるように、動作可能に接続される。このように、ユーザは、情報を取得するためにプルコマンドを促すためにキーパッドを使用してもよい。別々に示されているが、キーパッド28及びディスプレイ26は、タッチセンシティブディスプレイとして一体的に形成されてもよい。別法として又は更に、情報の要求を促すためにディスプレイ上の複数のコマンドのうち1つを選択するために、ポインタデバイスが提供されてもよい。ハンドセット12は、複数のサービスサービス1、2及び3のうち少なくとも1つから情報をレンダリングするように構成される。ここで使用されるサービスという用語は、コンテンツデータ及びコンテンツデータを提供するための一連のコンピュータ実行可能命令、局所的に又は分散的にコンピュータ可読媒体に格納されている所与のサービスの命令及びデータ、1つ以上のプロセッサで実行されている命令を示す。これらのサービスのそれぞれは、履歴サービス情報を含むコンテキストデータベース30にアクセスする。これらのサービスのうち1つサービス2はローカルサービスである。このサービスは、ハンドセットに存在してメッセージルータ25を通じてブラウザ24と動作可能に通信するものとして考えられてもよいが、サービス1及びサービス3は遠隔サービスである。メッセージルータ25は、メッセージがサービス1又はサービス3のようなローカルでないサービスに関係する場合、ブラウザから外部リンク16にメッセージをルーティングするために提供される。メッセージがサービス2のようにローカルサービスすなわち、ハンドセットから提供されるサービスに関係する場合、メッセージルータ25は内部にメッセージをルーティングする。サービス1及びサービス3はゲートウェイに存在するものとして示されているが、第4のサービスのような1つ以上のサービスは、ネットワークの異なるポイントに存在してもよく、このサービス又はこれらのサービスからの情報は、インターネット18で提供される。外部サービスインタフェース32は、このような外部サービスを管理するためにゲートウェイに提供される。サービスは、プッシュモデル及びプルモデルの一方又は双方で動作してもよい。プルモデルでは、情報は、ハンドセットのユーザにより促された要求に応じてハンドセットに提供される。これは、要求毎に行われる。従って、通常では、要求は所与のドキュメント、画像又は他の要求時に存在する情報の空間的又は時間的にグループ化されたアイテムに関係する。ユーザにより要求された情報が送信されると、サービスは、更なる情報を送信する前に、新たな要求を待機する。プルモデルでは、ユーザは、ユーザ要求で識別された特定の情報を遅延なく予期していることが想定される。プル要求の一例は、検索エンジンページで入力される検索文字列である。検索エンジンは、一致する要素のリストで応答する。プッシュモデルでは、サービス自体が、送信毎にユーザ要求を待機するのではなく、ハンドセットへの情報の送信を促す。プッシュモデルの送信は、スケジューリングされてもよく、特に重要なニュース項目又は閾値に到達した株価の値のような外部イベントにより起動されてもよい。前述のいずれかで動作するサービスでは、ハンドセットのブラウザ24は、そのサービスからの情報を受信し、受信時に表示されている情報の上に重ねてディスプレイ26に表示するように構成される。サービスから受信した情報が表示ページを表す場合、情報は制御命令を含み、制御命令に応じて、ハンドセットのブラウザはディスプレイをリフレッシュし、前のページの代わりに受信したページを表示する。制御命令は明示的である必要はない。ここでは、制御命令は、入来するコンテンツが到達しているというフォーマットの一部として提供され、明示的ではない。ハンドセットは、フォーマットを認識し、コンテンツが到達したときに認識されたフォーマットで到達するコンテンツをレンダリングするように構成される。図2は、ゲートウェイ14のハードウェアアーキテクチャを示している。インターネット18に送信される情報及びインターネット18から受信した情報をそれぞれ変調及び復調するADSLAsymmetricDigitalSubscriberLineインタフェース40と、無線リンク16でハンドセット12への無線信号及びハンドセット12からの無線信号を通信するように構成されたアンテナ44を備えた無線モジュール42とが提供される。ADSLインタフェース40及び無線モジュール42は、これらからのデータを処理し、処理されたデータをこれらに出力するように構成されたプロセッサモジュール46に接続される。プロセッサは、メモリモジュール48にアクセスする。メモリモジュール48は、ROMメモリとフラッシュメモリとを含む。コンテキストデータベースを格納するRAMメモリも提供される。様々なゲートウェイ構成要素の電力は、外部主電源図示せずに接続された電源50により提供される。サービス1及び3は、フラッシュメモリに格納されたソフトウェアエンティティであり、所与のサービスが実行されているときに、そのサービスに対応するデータベース48からのコンテンツが無線モジュール42によるハンドセットへの送信のためにプロセッサにより取得され得るように、その実行可能命令はプロセッサ46により実行される。コンテンツは、サービスの性質に応じて、メモリモジュール48又はインターネット18内の位置から取得される。同様に、サービスマネージャ22及び外部サービスインタフェースは、フラッシュに格納されてプロセッサ46による使用中に実行されるソフトウェアエンティティである。サービスマネージャ22は、ハンドセットについて検出された最後のサービスの識別情報を記録するように構成される。識別情報は、プロセッサ46によりコンテキストデータベース30に格納される。ローカルでないサービスは、便宜的にサービス要求に基づいてサービスマネージャ22で検出されてもよい。この理由は、ハンドセットからのローカルでないサービスの要求は、サービスマネージャを通じてチャネル設定されるからである。ローカルでないサービスもまた、所与のサービスからハンドセットに送信される情報に基づいて検出されてもよい。この理由は、この情報がサービスを示す識別子を含むからである。別法として又は更に、サービスマネージャは、一般的なコンテキスト要求generalcontextrequestをブラウザに送信することにより、サービスを検出してもよい。これは、応答時にブラウザ22が最後にブラウズされたサービス又は現在ブラウズされているサービスの識別情報を示すコンテキストメッセージをサービスマネージャに返信するように構成された要求を表す。明らかに、一般的なコンテキスト要求は、ローカルサービスを検出するのに適している。この理由は、ブラウザはサービスマネージャを通じてこのようなサービスにアクセスしていないからである。図3を参照すると、ハンドセット12は、メモリモジュール54及びアンテナ57を有する無線モジュール56に接続されたプロセッサ52を有する。これらの構成要素のそれぞれは、これらの通常の機能を実行するように構成される。メモリモジュールは、ROMメモリと、RAMメモリと、フラッシュメモリとを含む。ディスプレイ26及びキーパッド28は、オーディオ出力及び入力デバイスここでは、それぞれイヤホン59及びマイクロフォン58と同様にプロセッサに接続される。ハンドセットの構成要素は、必要に応じて典型的には10時間の使用後に再充電可能なバッテリ電源60により電力供給される。ブラウザ24及びメッセージルータ25のそれぞれは、メモリモジュール54に格納されて、使用される場合にプロセッサ52により実行されるソフトウェアエンティティである。システム10が複数のハンドセットを含む場合、そのフラッシュメモリに格納されたそれぞれのIDをそれぞれ有する。図4に、サービスS1とサービスマネージャ22とハンドセットのブラウザ24との間で送信されるメッセージシーケンスが示されている。各メッセージは、水平方向の矢印で表されており、矢印の元及び先端は、それぞれ対応するメッセージの発生源及び宛先を示す。時間の増加は、下方向に示す矢印により示されており、点線は、メッセージ間の拡大する時間間隔を表す。入来するメッセージと出力するメッセージとを結ぶ曲がった矢印は、出力するメッセージが入来するメッセージに応じて送信されることを示す。メッセージは、時間的に2つの段階にグループ化される。図4の第1段階Iでは、ブラウザは、サービスS1をブラウズする。まず、ハンドセットのブラウザは、サービスを要求する要求をサービスマネージャに送信するS1要求。サービスマネージャ22は、要求を適切なサービスここではサービスS1に転送する。この要求に応じて、サービスS1は、図4に示すようにS1応答の形式で要求された情報を送信する。サービスマネージャは、S1応答をハンドセットのブラウザ24に中継する。ハンドセットのブラウザは、S1応答メッセージを受信したことに応じて、受信した情報を表すページをディスプレイ26に表示するために、応答メッセージの情報を使用する。このように、ハンドセットのブラウザ24は、S1サービスをブラウズする。サービスマネージャ22は、ハンドセットのブラウザ24からのS1要求をコンテキストデータベースに格納するように構成される。第1段階の終了後の或る時間後に生じる第2段階IIでは、プッシュモデルに従って動作しているサービスS1は、情報ページP1を送信することを希望する。すなわち、サービスS1は、情報ページP1のプッシュ送信を開始するために、ハンドセットの外部のイベントにより起動される。ページP1がハンドセットで現在ブラウズされているサービスと競合するか否かを判定するために、まず、サービスS1は、コンテキストがS1であるか否かを問い合わせるというメッセージとして図4に示すように、特定のコンテキスト要求をサービスマネージャ22に送信するように構成される。この特定のコンテキスト要求は、現在ブラウズされているサービスがサービスS1であるか否かのバイナリすなわち、肯定的又は否定的の指標の要求を表す。このような指標は、ハンドセットのユーザのブラウズ習慣について提供される情報量を制限し、サービスがゲートウェイの外部である場合に特に有用である。特定のコンテキスト要求に応じて、サービスマネージャ22は、ハンドセットのブラウザにより最後に要求されたサービスがS1であったか否かを判定するために、コンテキストデータベース30に問い合わせるように構成される。最後のサービスがS1でなかった場合、サービスマネージャは、S1をブラウズしていないというメッセージを返信する。この否定的なバイナリメッセージは、サービスS1が新たなページをプッシュすることを妨げる。他方、コンテキストデータベース30に格納された最後のサービスがS1であった場合、サービスS1が依然としてハンドセットで実行しているすなわち、このサービスに関係するページがハンドセットにより現在表示されている可能性が存在する。これが当てはまるか否かを判定するために、サービスマネージャは、ハンドセットに送信する一般的なコンテキスト要求を生成する。一般的なコンテキスト要求は、コンテキストを問い合わせるというメッセージとして図4に示されている。コンテキストを問い合わせるというメッセージは、命令を含むフィールドを有し、命令に応じてハンドセットが現在実行されているサービスを示すメッセージで応答する。この例では、ブラウザは依然としてサービスS1をブラウズしているためすなわち、サービスS1からのページが依然として表示されているため、ハンドセットのブラウザは、サービスS1が現在ブラウズされていることを示すコンテキストメッセージここでは、S1をブラウズしているというメッセージをサービスマネージャ22に返信する。S1をブラウズしているというメッセージは、サービスマネージャにより、肯定的なバイナリ応答に変換され、サービスS1に送信される。肯定的な応答により、サービスS1は、情報ページP1をサービスマネージャに送信することが可能になる。この理由は、ブラウズされているサービスが情報をプッシュすることを希望するサービスに対応するからである。サービスマネージャは、このページをハンドセットのブラウザ22に転送し、ハンドセットのブラウザ22は、ページをディスプレイ26に表示する。前述の実施例では、サービスマネージャは、ハンドセットのユーザのプライバシを保護するために、バイナリ応答でコンテキストがS1であるか否かを問い合わせるに応答している。しかし、別の実施例では、サービスマネージャは、ブラウズされているサービスを示す識別子で応答し、サービスS1は、現在ブラウズされているサービスここではS1の識別情報と自分の識別情報とを比較し、2つの識別情報が一致する場合に、ページP1を送信するように構成される。図4の例は、特定のコンテキスト要求を送信することにより、ハンドセットがこのサービスを現在ブラウズしているか否かをサービスS1がサービスマネージャに事実上問い合わせる状況として考えられてもよい。応答を提供するために、サービスマネージャは、一般的なコンテキスト要求をハンドセットに送信し、ハンドセットは、現在ブラウズされているサービスのIDで応答する。肯定的又は否定的な応答は、サービスS1に中継され、それぞれページP1を送信することを可能又は不可能にする。図5は、サービスS1が新たなページを送信することを控えなければならない状況におけるメッセージシーケンスを示している。ここで、図2のものに対応するラベルは同様の意味を有する。図4と同様に、図5のシーケンスは、ハンドセットがS1をブラウズしている第1段階Iを有する。しかし、サービスS1をブラウズした後に、ブラウザは、サービスS1とは異なるローカルのサービスS2をブラウズし始める。このブラウズは、サービスS2からのS2応答により後続されるブラウザからのS2要求として図5に表されている。第2段階IIでは、新たなページP1をプッシュすることを希望するサービスS1は、コンテキストがS1であるか否かを問い合わせるという特定のコンテキスト要求をサービスマネージャに送信する。図4と同様に、サービスマネージャは、一般的なコンテキスト要求を用いて、ハンドセットで現在ブラウズされているサービスの識別情報の指標を求める。しかし、ハンドセットでブラウズされた最後のサービスは現在ではサービスS2であるため、ブラウザは、S2をブラウズしているというメッセージを返信する。次に、サービスマネージャは、S1をブラウズしていないというメッセージを生成する。S1をブラウズしていないというメッセージは、サービスS1からのコンテキスト要求に対する否定的な応答を表す。従って、サービスS1は、ページP1を送信することができない。次にサービスS1は、新たな特定のコンテキスト要求を開始する。サービスマネージャは、再びS1をブラウズしていないというメッセージの形式で否定的な応答を提供する。サービスS1は、肯定的な応答がサービスマネージャから取得されるまで、或る時間間隔でコンテキスト要求の送信を繰り返すように構成される。肯定的な応答がサービスマネージャから取得された時点で、サービスS1は、新たなページP1を送信することが可能になる。図6は、更に他の考えられるメッセージシーケンスを示している。ここでは、段階Iにおいて、ブラウザは、図5と同様にサービスS1をブラウズする。しかし、ブラウザは、他のローカルでないサービスここでは、サービスS3の要求をサービスマネージャに送信する。受信した要求に基づいて、サービスマネージャはサービスS3を検出し、最後に検出されたサービスとしてS3をコンテキストデータベース30に格納する。その後、サービスS1がコンテキストがS1であるか否かを問い合わせるという特定のコンテキスト要求をサービスマネージャに送信した場合、サービスマネージャ22は、コンテキストデータベース30に問い合わせる。最後に検出されたサービスがS1ではないため、サービスマネージャは、S1をブラウズしていないというメッセージで応答する。サービスS1は、新たなページP1をプッシュすることができない。明らかに、サービスマネージャは、ブラウザがS1をブラウズしていないことを推測することができる。この理由は、S1要求又はサービスS1によりプッシュされた情報は、サービスマネージャを通過するため、サービスマネージャにより検出されるからである。図7では、サービスS1は、特定のコンテキスト要求ではなく、一般的なコンテキスト要求をサービスマネージャに送信する。サービスマネージャは、新たな一般的なコンテキスト要求を生成する。これは、S2をブラウズしているというメッセージの形式でブラウザにより応答される。サービスマネージャは、肯定的又は否定的な応答を提供するのではなく、現在ブラウズされているサービスの識別情報をサービスS1に転送する。図7に示す状況も可能であるが、サービスS1が特定のコンテキスト要求を送信し、肯定的又は否定的な応答を受信する図4~6の実施例が好ましい。この理由は、これらの実施例では、ハンドセットのユーザのプライバシがより良く保護されるからである。図4の状況は、以下の例によって示されてもよい。ユーザは、サービスS1に対応する通話ログサービスという名前のサービスによりゲートウェイで管理されているハンドセットの通話ログにアクセスすることを希望する。ユーザは、ゲートウェイへの要求図4ではS1要求を送信し、通話ログサービスを要求する。通話ログサービスは、通話ログドキュメントを構築するために或る時間を必要とするため、通話ログサービスは、ユーザの要求が受信されて処理されていることをユーザに示すお待ちくださいというドキュメントS1応答に対応するをハンドセットに送信する。通話ログドキュメントの用意ができた場合、通話ログサービスは、コンテキストがS1であるか否かを問い合わせるというメッセージの形式で通話ログサービスが依然としてハンドセットでブラウズされているか否かをサービスマネージャに問い合わせる。サービスマネージャは、ハンドセットとの無線接続をオープンし、現在ブラウズされているサービスの識別情報を取得するために、コンテキストを問い合わせるというメッセージを送信する。サービスが変更されていない場合、ハンドセットのブラウザは、依然として通話ログサービスをブラウズしていること、すなわち、通話ログに対応する表示ページが依然として表示されていることを示す指標をサービスマネージャに返信する。サービスマネージャは、通話ログサービスが依然としてブラウズされていることを示す肯定的な応答を通話ログサービスに送信する。通話ログサービスは、最終的なドキュメントを送信する。しかし、通話ログサービスが通話ログを構築するのを待機している間に、ユーザは我慢できなくなり、他のゲートウェイサービス例えば、イエローページサービスにアクセスすることを判断することがある。サービスマネージャがイエローページサービスの要求を受信すると、そのコンテキストデータベースを更新する。この場合、図6に示す状況に対応して、コンテキストがS1であるか否かを通話ログサービスがサービスマネージャに問い合わせた場合、サービスマネージャは、コンテキストデータベースに問い合わせ、ハンドセットとの新たな無線リンクを設定する必要なく、否定的な応答を返信することができる。通話ログサービスは、イエローページサービスを中断してユーザを混乱させる可能性がある通話ログページを送信することを控える。このように、サービスがハンドセットで競合するリスクが低減され、高コストの無線リンクをオープンする必要性も低減され得る。無線リンクは、オープンされた場合、通常では無線デバイス間で交換される同期パケットを伝達し、その結果、非接続状態より多くの電力消費を生じる。更に、無線接続帯域幅は、しばしば他のデバイスと共有される。オープンされた接続は、他のデバイスの間の接続を妨げるリスクを意味する。いずれかの回避可能なリンクを回避することは非常に有利である。図8~15は、サービス、サービスマネージャ及びハンドセットのブラウザで行われるステップを示すフローチャートの様々な段階を示している。図8に、ハンドセットで実行されるステップを示す。ブラウザは、サービスS1を要求する。例えば、この要求は、ユーザ入力の結果でもよい。メッセージルータ25は、サービスがローカルであるか否かを判定し、そうである場合、サービス要求をローカルサービスに送信する。そうでない場合、サービス要求は、無線リンク16でゲートウェイに送信される。図9は、サービスマネージャにおけるステップを示している。サービスマネージャは、サービス要求を受信する。要求を受信すると、サービスマネージャは、最後のサービスS1の形式で、サービスの識別子S1をコンテキスト情報としてコンテキストデータベースに格納する。事実上、サービスマネージャは、ゲートウェイを通じてアクセスされた最後のサービスがS1であるという事実をメモリに格納する。サービスマネージャは、要求をサービスS1に送信する。図10では、サービスS1は、サービスマネージャから転送された要求を受信し、要求を処理する。サービスは、異なる方法で例えば、要求への応答として、又は既に送信されたドキュメントへの更新としてドキュメントを送信してもよい。言い換えると、サービスは、プルモード及びプッシュモードの双方で動作してもよい。しかし、図11に示すように、サービスS1がドキュメントを送信する前に、サービスS1からの情報が要求の発信源により現在ブラウズされているか否かを問い合わせる。これは、特定のコンテキスト要求をサービスマネージャに送信することにより行われる。図12は、サービスここでは、サービスS1からの特定のコンテキスト要求に応じて、サービスマネージャにより実行されるステップを示している。サービスS1から特定のコンテキスト要求を受信すると、サービスマネージャは、コンテキストデータベースから最後のサービスの値がS1に等しいか否かを判定する。最後のサービスの値がS1に等しくない場合、否定的な応答がサービスS1に返信される。すなわち、S1がハンドセットによりブラウズされていないという指標S1をブラウズしていないというメッセージがサービスS1に送信される。図13に示すように、サービスマネージャからのメッセージがサービスS1で受信された場合、サービスS1は、S1がハンドセットで現在ブラウズされていることをメッセージが示すか否かを判定する。S1がブラウズされていない場合、サービス中断コマンドが発行され、サービスが終了する。そうでない場合、新たなページP1のようなドキュメントが送信される。図12に戻り、最後のサービスS1が真である場合、コンテキストを問い合わせるというメッセージの形式の一般的なコンテキスト要求がサービスマネージャによりハンドセットのブラウザに送信される。コンテキストを問い合わせるというメッセージは、所望のサービスを指定しない。この理由は、このことが無線リンクをオープンするコストにあまり影響を及ぼさないからである接続はそれぞれの場合にオープンされる必要があり、ここでは、サービスマネージャがハンドセットのブラウザから入来する各メッセージ及びハンドセットのブラウザに進む各メッセージにより通過されるため、機密性の問題は存在しない。更に、コンテンツを問い合わせるというメッセージとサービスが実行しているか否かを問い合わせるというメッセージとの間でのペイロードのコストの差は数バイトの長さのみである。このコンテキストを問い合わせるというメッセージは、図14に示すようにハンドセットのブラウザで受信される。ここでは、現在ブラウズされているアプリケーションの識別情報がコンテキストメッセージでゲートウェイに返信される。再び図12に戻り、ハンドセットからのコンテキストメッセージは、ゲートウェイのサービスマネージャで受信され、ここで、ブラウズされているサービスがS1であるか否かが判定される。ブラウズされているサービスがS1でない場合、S1をブラウズしていないというメッセージがサービスに返信され、コンテキストデータベースは、ブラウズされているサービスの識別情報で更新される。この更新情報は、ゲートウェイがハンドセットへの無線リンクをオープンする必要なくコンテキスト要求メッセージに応答することを可能にするために、将来的に有用になる。受信したハンドセットコンテキストメッセージからハンドセットのコンテキストがS1であると判定された場合、この情報は、S1をブラウズしているというメッセージの形式でサービスS1に送信される。図15は、サービスS1からページP1のようなドキュメントを受信したときにサービスマネージャで実行されるステップを示している。ドキュメントを受信した後に、サービスマネージャは、ドキュメントが生じたサービスの識別情報がコンテキストデータベースに格納されたものと一致するか否か、すなわち、S1がデータベースの最後のサービスの値に等しいか否かを判定する。いずれの場合でも、ドキュメントはハンドセットに送信される。しかし、最後のサービスの値がS1に一致しない場合、コンテキストデータベースは、新たなサービス情報で更新され、最後のサービスの値は、S1の値に設定されるサービスS1が現在のブラウザが実行しているサービスがどんなものであれ、送信される必要がある警報サービスである場合、このような状況が生じ得る。このように、コンテキストデータベースは、コンテキスト要求をハンドセットに送信する必要性を低減するために、新たなサービス要求の受信時に問い合わされてもよい。前述の実施例では、単一のハンドセットのみが提供されているが、複数のハンドセットが提供されてもよい。この場合、コンテキストデータベースは、例えば参照テーブルの形式で、ハンドセットの各識別子に関連付けて各ハンドセットの最後のサービスの値を格納する。図16aは、様々な論理機能又はソフトウェアモジュールを示すハンドセット12のアーキテクチャの更なる図である。ブラウザ24及びローカルサービスS2に加えて、メッセージルータが示されている。この目的は、ブラウザからゲートウェイ又はローカルサービスS2に要求及びイベントをルーティングすることである図16bは、ゲートウェイの対応する詳細を示す図である。メッセージルータにより受信される遠隔又はローカルサービスからの応答及びイベントのフォーマットの例は、表1に示されている。ハンドセットにより受信される可能なドキュメントの種別は表2に示されている。ハンドセットにより受信される可能なドキュメントの完全なフォーマットが表3に示されている。画像ドキュメントのフォーマットは表4に示されている。イベントのフォーマットは表5に示されている。イベントは、ブラウザの要求の間にエラーを報告するメッセージドキュメントが見つからない、サービスが応答していない、ドキュメントが大きすぎる、又はブラウザに通知されなければならない他のエラーメッセージでもよい。コンテキスト要求のフォーマットは表6に示されている。ハンドセットからゲートウェイへの応答は、コンテキスト方式でのhttp要求フォーマットを通じて送信される。この方式は、サービスがローカルであるかhandset、ゲートウェイに埋め込まれているかbase又はシステムの外部に存在するかインターネット、httpを識別するために使用される。例えば、phonesettingsがハンドセットのローカルサービスである場合、GEThandsetphonesettingscalllogがゲートウェイに存在するサービスである場合、GETbasecalllogyellowpagesがインターネットに存在するサービスである場合、GEThttpyellowpages標準的なhttp要求フォーマットを使用することにより、コンテキスト管理機構を埋め込んでいないベース/ゲートウェイとのDectハンドセットのような無線デバイスに完全な互換性を与えることが可能になる。図17~19は、競合の可能性を低減するためのコンテキスト管理を備えた複数サービスのアクセスの例に関する。図17に示す一例では、ユーザは、ハンドセットの通話ログにアクセスすることを希望する。通話ログは、通話ログサービスと呼ばれるサービスによりゲートウェイで管理されている。まず、ハンドセットは要求をゲートウェイに送信する。通話ログドキュメントを構築するために或る時間を必要とするため、通話ログサービスは、ユーザの要求が受信されて現在処理されていることをユーザに通知するお待ちくださいというドキュメントをハンドセットに送信する。また、この待ち時間を使用し、最終的なドキュメントが利用可能になる前に宣伝をプッシュすることも可能である。図17のシナリオでは、ユーザは、ハンドセットで動作せずにサービスの応答を待機する。通話ログドキュメントの用意ができた場合、通話ログサービスは、依然としてハンドセットで使用されているか否かをWMLサービス/マネージャに問い合わせる。WMLサービス/マネージャは、ハンドセットとの無線リンクをオープンし、コンテキスト情報を問い合わせる。サービスが交換されていないため、依然としてブラウズされていることを通話ログサービスに通知する。通話ログサービスは、最終的なドキュメントを送信する。要するに、図17は、通話ログサービスが新たなページ無かった通話をプッシュすることを希望し、最後のハンドセットの動作がこのサービスをブラウズしているシナリオを示している。無かった通話ページを送信する前に、通話ログサービスは、ハンドセットがこのサービスを現在ブラウズしているか否かをWMLサービス/マネージャの構成要素に問い合わせる。ハンドセットでローカルのブラウズが存在するか否かを検査するために、次に、WMLサービス/マネージャは、このサービスが現在ブラウズされていると応答するコンテキスト検査をハンドセットに送信する。そして、通話ログサービスは、無かった通話ページを送信することができる。WMLサービス/マネージャを通じた最後の活動が通話ログサービスのものであったため、ハンドセットが通話ログサービスを依然としてブラウズしているか否かすなわち、ローカルサービスに切り替えていないかを検査するために、ハンドセットとの接続が必要になる。この接続コストは無視できるほど小さい。この理由は、接続を閉じて他のものをオープンする必要なく、無かった通話ページを送信するために再利用されるからである。或る無線技術では、接続を閉じること及びオープンすることは、1秒以上まで続いてもよい。同じ接続を使用することは、より反応の良いシステム及び短い無線リンクの使用期間を意味する。図18は、通話ログサービスが新たなページ無かった通話をプッシュすることを希望するが、ハンドセットが他のローカルサービス電話設定に切り替えているシナリオを示している。無かった通話ページを送信する前に、通話ログサービスは、ハンドセットがこのサービスS1を現在ブラウズしているか否かをWMLサービス/マネージャの構成要素に問い合わせる。ハンドセットでローカルのブラウズが存在するか否かを検査するために、次に、WMLサービス/マネージャは、ローカルの電話設定サービスをブラウズしていると応答するコンテキスト検査をハンドセットに送信する。WMLサービス/マネージャは、通話ログサービスが現在ブラウズされていないと結論付け、通話ログサービスに通知する。通話ログサービスは、無かった通話ページを送信しないことを判定する。WMLサービス/マネージャは、ハンドセットが電話設定サービスに切り替えたことを認識している。次に通話ログサービスが通話ログコンテキストを問い合わせた場合2、WMLサービス/マネージャは、ハンドセットに接続せずに、通話ログサービスをブラウズしていないと応答することができる。図19は、通話ログサービスが新たなページ無かった通話をプッシュすることを希望するが、ハンドセットが他の遠隔サービスに切り替えているシナリオを示している。無かった通話ページを送信する前に、通話ログサービスは、ハンドセットがこのサービスを現在ブラウズしているか否かをWMLサービス/マネージャの構成要素に問い合わせる。全てのページのプッシュはこの構成要素を通過しなければならないため、WMLサービス/マネージャは、最後の通話ログページがプッシュしてから他のサービスがアクセスされたことを認識している。ブラウズされていない通話ログサービスに応答するために、ハンドセットの接続は回避されてもよい。この対策を通じて、1つのみのWMLバッファを備えたハンドセットについて説明したが、複数バッファのデバイスにも有利に拡張され得る。コンテキスト要求への応答として、複数バッファのハンドセットは、現在ブラウズされているサービスのリストを送信する。ゲートウェイのWMLサービス/マネージャは、そのコンテキストデータベースにおいてブラウズされているサービスのリストを管理する。この拡張はこの対策の原理を変更しないが、デバイスが同時に1つのみのドキュメントをブラウズできるものであれ、複数のドキュメントをブラウズできるものであれ、どのようにこの対策がブラウザを備えた全てのデバイスに適用され得るかを示しているこれらの全ては限られたメモリ空間を有するため。要するに、これらの実施例は、異なるサービスへのアクセスを提供するブラウザを埋め込んだ無線デバイスに当てはまる。このようなデバイスは、独立しており、通常ではこれらの間例えば、天気予報サービスとイエローページサービスとの間に通信リンクを有さない複数のサービスへの共通のユーザインタフェース1つの画面、1つのキーパッド、1つのオーディオ入力/出力を提供する。小さいメモリ又は帯域幅の制限を備えたデバイスでは、そのメモリ内にいくつかの異なるドキュメントを格納することができ、サービスのアクセスを非常に容易に管理する例えばマルチタブのブラウザ。しかし、1つのみのドキュメントが格納可能な又は限られた数が格納可能な非常に小さいメモリを備えたデバイスでは、特にプッシュモデルでサービスは競合するようになる。プルモデルでは、ハンドセットは、ドキュメントをサービスに問い合わせ、その要求の1つへの応答で全てのドキュメントを受信する。サービスの間の競合を容易に管理することができるが、サービスをプルして最新のドキュメントを取得するコストが必要になる。このプルは、帯域幅及び消費電力の点で高コストな無線接続を必要とし、これは、ドキュメントの更新が存在しない場合には無駄になる。この問題への解答は、プッシュモデルのサポートである。プッシュモデルでは、サービスは、更新が利用可能である場合にいつドキュメントをプッシュするかを判定する。単一のサービスでは、ハンドセットにより提供される単一のユーザインタフェースは効率的に動作することができる。しかし、複数のサービスでは、これらは同時発生的になり、ユーザが他のものをブラウズしているときにサービスのドキュメントがプッシュされた場合、ユーザインタフェースを損なう可能性がある。前述の実施例は、以下の利点を備え、プッシュモデルで動作するサービスへの方法を提供することができる。ハンドセットは、更新を取得するためにサービスをプルする必要はない。サービスは、ドキュメントの更新を送信する前に、ハンドセットの状態及び動作を認識できる。この認識は、いずれかの無駄なハンドセットの接続を回避する制約で与えられる。これはプッシュモデルで動作するが、この対策はプルモデルと互換性がある。