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