特許 6382218 通信セッションを管理するためのメカニズム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6382218

(24)【登録日】2018年8月10日

(45)【発行日】2018年8月29日

(54)【発明の名称】通信セッションを管理するためのメカニズム

(51)【国際特許分類】

   H04M 3/00 20060101AFI20180820BHJP

   H04M 11/00 20060101ALI20180820BHJP

【ＦＩ】

   H04M3/00 D

   H04M11/00 302

【請求項の数】10

【全頁数】13

(21)【出願番号】特願2015-548740(P2015-548740)

(86)(22)【出願日】2013年12月20日

(65)【公表番号】特表2016-503261(P2016-503261A)

(43)【公表日】2016年2月1日

(86)【国際出願番号】FR2013053233

(87)【国際公開番号】WO2014096742

(87)【国際公開日】20140626

【審査請求日】2016年12月1日

(31)【優先権主張番号】1262440

(32)【優先日】2012年12月20日

(33)【優先権主張国】FR

(73)【特許権者】

【識別番号】591034154

【氏名又は名称】オランジュ

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】ファブリス・フォンテーヌ

(72)【発明者】

【氏名】ファブリス・バランスキー

【審査官】 山田 倍司

(56)【参考文献】

【文献】 米国特許出願公開第２０１２／０１２０８５８（ＵＳ，Ａ１）

【文献】 特開２０１０−０２１６６１（ＪＰ，Ａ）

【文献】 特開２００９−０４９５５０（ＪＰ，Ａ）

【文献】 特表２００７−５１５８５２（ＪＰ，Ａ）

【文献】 特開２００４−１８５１３８（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

１５／００

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｌ １２／００−１２／２８

１２／４４−１２／９５５

Ｈ０４Ｍ ３／００

３／１６− ３／２０

３／３８− ３／５８

７／００− ７／１６

１１／００−１１／１０

Ｈ０４Ｗ ４／００−９９／００

(57)【特許請求の範囲】

【請求項1】

通信セッション（SS_WS）を介して少なくとも１つのサーバ(3)とアプリケーションメッセージ（MSG_WS）を交換するのに適した端末(1)の通信セッション（SS_WS）を管理するための管理方法において、前記方法は、管理装置によって実行される、
端末(1)とサーバ(3)間でアプリケーションメッセージを交換するための通信セッション（SS_WS）をセットアップするステップ（E1）と、
期間（T_timer）を初期化するステップ（E2）と、
通信セッション（SS_WS）に関するアプリケーションメッセージ（MSG_WS）が受信されなかった場合に、期間（T_timer）の終わりに端末と管理装置間の通信セッション（SS_WS）を部分的に閉じるステップ（E3）と、
サーバから来る通信セッションに関する少なくとも１つのアプリケーションメッセージ（MSG_WS）を検出するステップ（E4, LST）と、
通知サーバに、通信セッション（SS_WS）を復旧する（E4）ことを要求するステップとを有していて、前記通知サーバは、セッションとは関係ない通知の形で復旧要求を送信し、
端末によって送信されるセッション開始メッセージは、管理装置に、端末が前記通知の形でセッションを再開するための要求を受信するように準備されていることを知らせる情報を含んでいる
ことを特徴とする方法。

【請求項2】

端末(1)に、通信セッション（SS_WS）上で検出されたメッセージ（MSG_WS）を転送するステップ（E6）を更に有していることを特徴とする請求項１に記載の方法。

【請求項3】

通信セッションは、ウェブソケットタイプであることを特徴とする請求項１に記載の方法。

【請求項4】

通信セッション（SS_WS）を介して少なくとも１つのサーバ(3)とアプリケーションメッセージを交換するのに適した端末(1)のための通信方法において、前記方法は、
通信セッションを開くためにメッセージを送信するステップ（E10 - ハンドシェイク）と、
通信セッション（SS_WS）のためのセッション識別子（NUM）を受信するステップ（E11）と、
セッション（SS_WS）を閉じるステップ（E12）と、
セッションとは関係ない通知の形でセッションを再開するための要求を受信するステップ（E13）と、
通信セッション（SS_WS）を再開するためのメッセージを送信するステップ（E14）とを有していて、前記メッセージは、セッションの識別子（NUM）を含んでいて、
端末によって送信されるセッション開始メッセージは、管理装置に、端末が前記通知の形でセッションを再開するための要求を受信するように準備されていることを知らせる情報を含んでいる
ことを特徴とする方法。

【請求項5】

通信セッション（SS_WS）を介して少なくとも１つのサーバ(3)とアプリケーションメッセージ（MSG_WS）を交換するのに適した端末(1)の通信セッション（SS_WS）を管理するための装置（2, PWS）において、前記装置は、
端末(1)とサーバ(3)間でアプリケーションメッセージを交換するために、通信セッション（SS_WS）をセットアップするためのモジュールと、
期間（T_timer）を初期化するためのモジュールと、
通信セッション（SS_WS）に関するアプリケーションメッセージ（MSG_WS）を検出するためのモジュールと、
メッセージが検出されなかった場合に、期間（T_timer）の終わりに端末と管理装置間の通信セッション（SS_WS）を部分的に閉じるためのモジュールと、
通知サーバに、通信セッションを復旧することを要求するためのモジュールとを備えていて、前記モジュールは、サーバから受信する通信セッションに関するアプリケーションメッセージを検出することで起動し、前記通知サーバは、セッションとは関係ない通知の形で復旧要求を送信し、
端末によって送信されるセッション開始メッセージは、管理装置に、端末が前記通知の形でセッションを再開するための要求を受信するように準備されていることを知らせる情報を含んでいる
ことを特徴とする装置。

【請求項6】

請求項５に記載の装置を含むホームゲートウェイ(10)。

【請求項7】

通信セッション（SS_WS）を介して少なくとも１つのサーバ(3)とアプリケーションメッセージを交換するのに適した端末(1)において、前記端末は、
通信セッション（E10 - ハンドシェイク）を開くために、メッセージを送信するのに適したモジュールと、
通信セッション（SS_WS）のためのセッション識別子（NUM）を受信するためのモジュールと、
セッション（SS_WS）を閉じるためのモジュールと、
セッションとは関係ない通知の形でセッションを再開するための要求を受信するためのモジュールと、
通信セッション（SS_WS）を再開するためのメッセージを送信するためのモジュールとを備えていて、前記メッセージは、セッションの識別子（NUM）を含んでいて、
端末によって送信されるセッション開始メッセージは、管理装置に、端末が前記通知の形でセッションを再開するための要求を受信するように準備されていることを知らせる情報を含んでいる
ことを特徴とする端末(1)。

【請求項8】

請求項７に記載の端末と、請求項５に記載の管理装置とを備えていることを特徴とするシステム。

【請求項9】

請求項５に記載の装置上で動作するのに適したコンピュータプログラムにおいて、前記プログラムは、プログラムがプロセッサによって実行される時に、請求項１の管理方法のステップを形成するためのコード命令を含んでいることを特徴とするコンピュータプログラム。

【請求項10】

請求項７に記載の端末上で動作するのに適したコンピュータプログラムにおいて、前記プログラムは、プログラムがプロセッサによって実行される時に、請求項４の通信方法のステップを形成するためのコード命令を含んでいることを特徴とするコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、電気通信ネットワークの一般的な分野に関し、より詳しくは、インターネットタイプの電気通信ネットワーク上でのクライアント端末とサーバ装置間の通信に関する。

【背景技術】

【0002】

知られている方法において、インターネットタイプのネットワーク内で、クライアント端末とサーバ装置間の通信は、ハイパーテキスト転送プロトコル（HTTP）を用いて行われる。これは、ワールドワイドウェブのために特に開発されたクライアント-サーバ通信プロトコルである。最も良く知られているHTTPクライアントは、遠隔でアクセスされるように設計されたアプリケーションを利用可能にするウェブブラウザである。ハイパーテキストマークアップ言語（HTML）は、このようなアプリケーションのウェブページを表示するように設計されたデータフォーマットである。

【0003】

HTMLプロトコルの最初のバージョンは、クライアントとサーバ間の双方向通信のための準備をしていなかった。クライアントは、HTTPプロトコルを用いるポーリングメカニズム（すなわち、要求および応答メカニズム）を介してサーバに接続しなければならなかった。最近、ウェブソケットプロトコルが、クライアントとサーバ間の双方向通信を提供するために導入された。ウェブソケットは、ネットワークプロトコルおよびプログラミングインターフェースを規定する標準であり、それは、任意のウェブサーバまたはクライアント上のアプリケーションによって用いられ得る。このプロトコルは、インターネット技術タスクフォース（IETF）によって、そのリクエストフォーコメンツ（RFC）6455の中で標準化され、対応するプログラミングインターフェースは、現在、W3Cとして知られている団体によって標準化されている（参照：ウェブソケットAPI；W3Cワーキングドラフト）。

【0004】

ウェブソケットは、サーバとクライアント間の通信を相当に改善するが、サーバと任意の時間に通信することができるように、クライアントに、ウェブソケット通信セッションを維持すること、従ってアクティブなインターネット接続を維持することを要求する。このような接続を維持することは、無意味に高価であり得る。端末は、そのインターネット接続がアクティブで、データが交換されている時に、エネルギーを消費する。ある装置、特にスマートフォンのようなモバイル機器では、それを用いる必要がない時に、インターネット接続を切断することが可能である。インターネット接続を切断することは、端末のエネルギー消費を減らすのに役立つが、いかなる通信も妨げる。エネルギー消費を減らすために、そのタイプのデータを受信しかつ送信することをやめるように、ウェブソケットアプリケーションのみを停止することも可能である。しかしながら、このような状況では、端末は、現在のセッションを失い、その後、サーバと通信しようとする場合、新しいウェブソケットセッションを確立する必要がある。

【0005】

本発明は、従来技術の欠点を示さない解決策を提供する。

【発明の概要】

【課題を解決するための手段】

【0006】

このため、機能的態様において、本発明は、通信セッションを介して少なくとも１つのサーバとアプリケーションメッセージを交換するのに適した端末の通信セッションを管理するための管理方法を提供する。前記方法は、管理装置によって実行される、
端末とサーバ間でアプリケーションメッセージを交換するための通信セッションをセットアップするステップと、
期間を初期化するステップと、
通信セッションに関するアプリケーションメッセージが受信されなかった場合に、期間の終わりに端末と管理装置間の通信セッションを部分的に閉じるステップと、
サーバから来る通信セッションに関する少なくとも１つのアプリケーションメッセージ（MSG_WS）を検出する（E4, LST）ステップと、
通知サーバに通信セッション（SS_WS）を復旧することを要求する（E4）ステップとを有していて、前記通知サーバは、セッションとは関係ない通知の形で復旧要求を送信することを特徴とする。

【0007】

従って、本発明は、端末のエネルギー消費がインテリジェントな方法で管理されることを可能にする。あまりにも長い間続く、端末とサーバ間にセットアップされた通信セッションの不活動の期間は、このセッションを、管理方法によって閉じられるように導く。セッションが閉じている間、端末は、より少ないエネルギーを消費するが、これは、電力消費を減らすことが重要な移動端末（例えば、スマートフォン、コンピュータタブレットなど）に対して特に有益である。この管理方法は、メッセージがこの通信セッションの間に受信されるとすぐに、部分的に閉じたセッションを復旧することを可能にする。端末とサーバ間の通信セッションに関するメッセージを検出することによって、この管理方法は、一種のプロキシとして動作する。プロキシは、セッションを「ひそかに監視する」ように配置され、それは、端末に対するメッセージを検出した際に、セッションが、端末とサーバ間で、より正確には端末とそれ自体の間で復旧することを要求する。従って、メッセージは、あたかもセッションが部分的に閉じることがなかったかのように、端末とサーバ間でもう一度交換され得る。特定の実施態様において、セッションが部分的に閉じた後、通信チャネルは切断され得る。そして、その後、管理装置が、サーバから来るメッセージを受信した時に、復旧され得る。

【0008】

この実施形態の変形例において、管理方法は、端末に、通信セッション上で検出されたメッセージを転送するステップを更に含んでいる。

【0009】

従って、この管理方法は、端末と管理装置間のセッションが部分的に閉じていた間に端末に前もって送信されたメッセージが、そのメッセージが失われないように端末に転送されることを可能にする。サーバと端末間の通信は、このように透過的（transparent）である。

【0010】

上記の実施態様に代わるものとして、または上記の実施態様と共に実行され得る、本発明の第２の特定の実施態様において、通信セッションは、ウェブソケットタイプである。

【0011】

ウェブソケットアプリケーションは、ほとんどバッテリ寿命を有しない端末、例えばスマートフォンまたはタブレットに対して、大量のエネルギーを消費する。本発明は、通信が、それがもう一度望まれるとすぐに再開され得ることを保証する一方で、端末をインターネットに接続しているチャネル（Zigbee(登録商標), WiFiなど）上にいかなる動作もないとすぐに、切断することを可能にする。

【0012】

管理方法の他の実施態様において、端末によって送信されるセッション開始メッセージは、管理装置に、端末が、セッションを再開するために要求を受信するように準備されていることを前記通知の形で知らせる情報を含んでいる。

【0013】

従って、管理装置は、セッションとは関係ない通知の形でセッションを再開するための要求を受信するのに適した端末と、この機能をサポートしていない端末とを区別することができる。

【0014】

他の機能的態様において、本発明は、通信セッションを介して少なくとも１つのサーバとアプリケーションメッセージを交換するのに適した端末のための通信方法を提供し、前記方法は、
通信セッションを開くためにメッセージを送信するステップと、
通信セッションのためのセッション識別子を受信するステップと、
セッションを閉じるステップと、
セッションとは関係ない通知の形でセッションを再開するための要求を受信するステップと、
通信セッションを再開するためにメッセージを送信するステップとを有していて、メッセージは、セッションの識別子を含んでいることを特徴とする。

【0015】

エネルギーの節約は、このように、端末でなされるべきである。

【0016】

通信方法の特定の実施態様において、端末によって送信されるセッション開始メッセージは、管理装置に、端末が、前記通知の形でセッションを再開するための要求を受信するように準備されていることを知らせる情報を含んでいる。

【0017】

このように、少量のエネルギーしか消費しない一方で、例えばウェブソケットタイプの通信セッションをセットアップしようとしている端末は、「標準」セッションをセットアップしようとしている端末とは異なる要求をすることができる。要求を交渉する段階の間、例えば、特定のパラメータによって信号を送られる、最適化されたセッションが望まれることの表示は、その後、ウェブソケットセッションのために、閉じられ、そしてサーバに対して透過的であり、かつ端末に対して非常に簡単である方法で再開されることを可能にする。なぜなら、パラメータをウェブソケット交渉段階における既存のコマンドに加え、そして再開目的のために、その後、用いられるであろうセッション識別子を保存することは、端末にとって十分であるからである。

【0018】

ハードウェア態様において、本発明は、さらに、通信セッションを介して少なくとも１つのサーバとアプリケーションメッセージを交換するのに適した端末の通信セッションを管理するための装置を提供し、前記装置は、
端末とサーバ間でアプリケーションメッセージを交換するために通信セッションをセットアップするためのモジュールと、
期間を初期化するためのモジュールと、
通信セッションに関するアプリケーションメッセージを検出するためのモジュールと、
メッセージが検出されなかった場合に、期間の終わりに端末と管理装置間の通信セッションを部分的に閉じるためのモジュールと、
通知サーバに、通信セッションを復旧することを要求するためのモジュールとを備えていて、前記モジュールは、サーバから受信する通信セッションに関するアプリケーションメッセージを検出することで起動することを特徴とする。

【0019】

他のハードウェア態様において、本発明は、さらに、上述したような装置を含むホームゲートウェイを提供する。

【0020】

他のハードウェア態様において、本発明は、さらに、通信セッションを介して少なくとも１つのサーバとアプリケーションメッセージを交換するのに適した端末を提供し、前記端末は、
通信セッションを開くためにメッセージを送信するのに適したモジュールと、
通信セッションのためのセッション識別子を受信するためのモジュールと、
セッションを閉じるためのモジュールと、
セッションとは関係ない通知の形でセッションを再開するための要求を受信するためのモジュールと、
通信セッションを再開するためにメッセージを送信するためのモジュールとを備えていて、メッセージは、セッションの識別子を含んでいる。

【0021】

他のハードウェア態様において、本発明は、さらに、上述したような端末および管理装置を備えるシステムを提供する。

【0022】

他のハードウェア態様において、本発明は、さらに、上述したような装置上で動作するのに適したコンピュータプログラムを提供し、このプログラムは、プログラムがプロセッサによって実行される時に、上記で定義したような通信セッションの管理方法のステップを実行するコード命令を含んでいる。

【0023】

このプログラムは、ローカルネットワーク内の機器の任意の部分に挿入される装置内で動作することができ、特に、上記で定義したホームゲートウェイ内で動作することができる。

【0024】

さらにもう１つのハードウェア態様において、本発明は、さらに、上述したような端末上で動作するのに適したコンピュータプログラムを提供し、コード命令を含んでいるこのプログラムは、プログラムがプロセッサによって実行される時に、上記で定義したような端末の通信方法のステップを実行する。

【0025】

本発明は、例として与えられ、かつ添付図面を参照して作られた以下の説明を読むことで、よりよく理解され得る。

【図面の簡単な説明】

【0026】

【図1】本発明の実施態様の一般的な状況を示している。

【図2】本発明の実施態様を実行するホームゲートウェイの構成を示している。

【図3】本発明を実行する時の機器の様々な部分の間での交換を示しているタイミング図である。

【発明を実施するための形態】

【0027】

図１は、本発明の実施態様の一般的な状況を示している。

【0028】

アプリケーションサーバ(3)が、インターネット(5)に接続されている。サーバ(3)とクライアント端末(1)の間の通信は、HTTPプロトコルを用いるインターネットを介して行われる。ウェブページは、例えば、HTMLフォーマット、すなわちこのようなページを表示するために設計されたデータフォーマットでクライアント端末に与えられ得る。

【0029】

クライアント端末(1)は、ウェブクライアントを有している。アプリケーションページは、通常、ウェブブラウザを用いることによって端末(1)に与えられる。サーバ(3)は、サーバと端末間で双方向モードで転送されるべきデータを要求するウェブタイプアプリケーション、例えば、このようなブラウザによって端末に与えられるように設計されたページを有する、天気予報アプリケーションまたはインスタントメッセージングアプリケーションを提供する。アプリケーションサーバは、端末に定期的にデータ、例えば新しいメッセージが届くたびの通知を送信する。

【0030】

この例では、クライアント端末(1)は、サーバと通信するのに適した、スマートフォンとして知られている、コンピュータおよびインターネット閲覧機能と関連した携帯電話であるが、それは、同様に、ラップトップコンピュータ、タブレットコンピュータなどであってもよい。以下、用語「クライアント端末」またはより簡単に「端末」は、通信チャネルを介してウェブサーバ(3)に接続して、双方向モード、すなわちアプリケーションメッセージが双方向に交換されることを可能にするモードとも呼ばれる、全二重モードでサーバと通信するのに適した任意の装置を示すために用いられる。上述したように、ウェブソケットプロトコルは、ウェブ上のクライアントとサーバ間での双方向通信メカニズムを定義する。選択された実施態様において、メッセージは、ウェブソケットタイプであり、それらは、より簡単にウェブソケットセッションと称され、図１および３の中ではSS_WSと略記される、ウェブソケット通信セッションの間に交換される。

【0031】

クライアント端末(1)は、ネットワーク(6)、例えばモバイルネットワークの中にある。端末(1)が、双方向プロトコル、特にウェブソケットプロトコルでサーバ(3)と通信するのに適しているという条件で、ネットワーク(6)は、より広く、かつ本発明の範囲を越えずに、任意のタイプのネットワーク（セルラ、global system for mobile communications（GSM(登録商標)）、universal mobile telecommunications system（UMTS）、無線（WiFi）など）であり得る。他の実施態様において、端末(1)は、同様に、有線モードでインターネット(5)に直接接続されてもよい。

【0032】

サーバ(4)もインターネットに接続されている。このサーバは、モバイルネットワーク(6)の端末(1)にデータを送信する。このサーバは、時には、通知サーバと呼ばれるが、例えば、Zigbee(登録商標)タイプのメッセージを通知するためのサーバであってもよいし、実は、ショートメッセージサービスセンター（SMSC）タイプのメッセージを通知するためのサーバであってもよい。すなわち、それは、サーバとモバイルネットワーク間に確立されたリンク(9)を介して携帯電話に（テキストまたはバイナリモードで）ショートメッセージサービス（SMS）メッセージを転送することを管理するのに役立つ。サーバは、メッセージを保存して、宛先がネットワーク上に存在する（携帯のスイッチがオンの）時、それを宛先に転送する。この実施態様において、特に、サーバ(4)は、端末(1)を、それがより少ないエネルギーを消費するように、その機能のいくつかを停止させる目的で、スタンバイ状態にすることができる。逆に、サーバ(4)は、端末の特定の機能を起動させることもできる。通知サーバは、このように、クライアント端末とアプリケーションサーバの間に確立されているセッションとは関係ない通知を転送することができる。用語「関係ない」は、通知が、セッションによって伝達されるのではないことを意味するために用いられる。

【0033】

本発明は、「ウェブプロキシ」と呼ばれる（図２中ではPWSと示される）１個の装置またはモジュール(2)を導入することによって、クライアントとサーバ間に確立されたウェブソケットセッションが、安価な方法で管理されることを可能にする。ウェブプロキシは、ウェブソケットセッションが停止して、端末が、サーバ(3)から来るウェブソケットメッセージに応答することができなくなる時に、それ自体を端末(1)の代わりにすることができる。プロキシモジュールは、（図中の点線によって表される）一種の代替通信チャネルを提案する。それは、ウェブソケットセッションSS_WSのメッセージを遮断して、この状況において、それ自体を端末の代わりにするのに適している。

【0034】

本発明が、図２および３を参照して、より詳細に説明される。

【0035】

図２は、本発明の実施態様を実行する機器の構成を示している。プロキシモジュール（2, PWS）は、インターネットに接続された任意の機器の中に置くことができ、この実施態様の例では、ホームゲートウェイ(10)の中に置かれる。この機器は、様々な端末とそれが接続されるネットワークとの間でデータパケットをリダイレクトする、または「ルートを決める」ことを可能にする。

【0036】

従来の方法において、ゲートウェイ(10)は、プロセッサ（CPU）と関連するメモリ（M）を備えている。メモリは、読み出し専用メモリ(ROM)タイプまたはランダムアクセスメモリ(RAM)タイプまたは実はフラッシュタイプであってもよい。本発明において、メモリ（M）の一部は、本発明の装置（PWS）のソフトウェア部分を含み、それは、ソフトウェアおよび／またはハードウェアコンポーネントによって実行される。用語「モジュール」は、同様に、ソフトウェアコンポーネントまたはハードウェアコンポーネントまたはハードウェアおよびソフトウェアコンポーネントの組に対応し得る。ソフトウェアコンポーネント自体は、１つ以上のコンピュータプログラムまたはサブプログラム、または、より一般的な方法で、記載されたような、問題のモジュールのための１つまたは１組の機能を実行するのに適した任意のプログラム要素に対応する。同様に、ハードウェアコンポーネントは、問題のモジュール（集積回路、スマートカード、メモリカードなど）のための１つまたは１組の機能を実行するのに適したハードウェアアセンブリの任意の要素に対応する。ゲートウェイ10は、さらに、それが、種々の物理リンク上の様々なプロトコルを介して外部と通信することを可能にする、ある数のモジュールを有している。従って、図２の中に、インターネットとの有線通信および無線通信のためのイーサネット(登録商標)モジュール、WiFiモジュール、およびZigbee(登録商標)モジュールが概略的に示されている。

【0037】

図３は、クライアント端末(1)、本発明のプロキシモジュール(2)、ウェブソケットサーバ(3)、およびモバイルサーバ(4)の間での交換を示している。

【0038】

本発明は、任意のタイプの端末ネットワーク、および端末とインターネット間の任意のタイプのリンクに適用され得る。端末(1)とインターネット間の物理リンク（C1）は、有線タイプ（イーサネット(登録商標)）または無線タイプ（WiFi, 3G, 4G, Zigbee(登録商標)）であってもよい。端末をホスティングする（hosting）ネットワークは、ローカルネットワークまたはモバイルネットワーク、または実はZigbee(登録商標)プロトコル（IEE 802.15.4標準に基づく、Zigbee(登録商標)プロトコルに準拠するメッセージが、無線チャネルを通じて交換されることを可能にする、低電力無線を用いる無線技術）を用いる通信のための無線媒体であり得る。この実施態様の状況において、サーバと端末間の通信のために用いられるアプリケーションプロトコルは、ウェブソケットタイプであると仮定される。しかし、本発明は、ウェブソケットに限定されない。それは、サーバと通信間の任意の他の双方向通信セッションの状況に適用され得る。

【0039】

ウェブソケットセッションまたは接続を確立するために、従来の交渉は、クライアント(1)とサーバ(3)間でHTTPメッセージを交換することによって行われる。この交渉は、ハンドシェイキングと呼ばれ、ネットワークのクライアントとサーバ間のウェブソケットプロトコルに従ってアプリケーションメッセージを交換するための通信セッション（SS_WS）をセットアップするのに役立つ。データは、その後、ウェブソケット接続またはセッションが閉じられるまで、ウェブソケットプロトコルを用いて、スマートフォン(1)およびサーバ(3)によってこの実施態様の中で構成されている２つのエンドポイントによって送受信され得る。この実施態様において、図３に示すように、プロキシ(2)は、この初期段階のメッセージを受信する。特に、ステップE10の間に、移動端末(1)は、標準によって定義されている標準メッセージに、付加的なパラメータを加えることによってハンドシェイキングを開始する。このパラメータは、最適化されたウェブソケットセッション（WSO）のためのプロキシに対する要求をなす。あるいは、このパラメータは、用いられる実施態様に応じて、命令、要求などの形であり得る。従って、端末によって送信されるセッション開始メッセージは、プロキシに、端末がセッションとは関係ない通知の形でセッション再開要求を受信するように準備されていることを告げる情報を含んでいる。従って、他の端末（コンピュータなど）は標準セッションをセットアップするのに対して、例えばエネルギーを節約する目的で、セッションを停止させる必要がある端末（スマートフォンなど）のみが、この最適化されたモードを要求する必要がある。

【0040】

例えば、（上述したRFC 6455仕様に従う）ウェブソケット機能拡張フィールドは、この情報を送信するために用いられ得る。例えば、ハンドシェイク交換の間、
１．クライアントは、図３中のメッセージHS_WS（WSO）またはメッセージHS_WS（WSO, NUM）に対応するフレームを送信する。

【0041】

【表1】

【0042】

その後、クライアントが以前受信した番号を有するか否かに応じて、すなわちメッセージがHS_WS（WSO）またはHS_WS（WSO, NUM）であったかどうかに応じて、

【0043】

【表2】

【0044】

変形例において、パラメータとして（後述するような、停止を検出する前に経過するのを許すべき時間に対応する）時間カウント値を加えることも可能である。

【0045】

２．サーバは、メッセージに応答する（図３中のメッセージSS_OK（NUM）に対応する）。

【0046】

【表3】

【0047】

プロキシモジュール(2)は、通信セッションのセットアップを管理するステップE1の間、ハンドシェイクメッセージ（HS_WS）を受信する。その後、このステップE1の間、プロキシモジュールは、ハンドシェイクメッセージ（HS_WS）を、本来意図されていたウェブサーバに再送信して、それがセッションを許可する場合、すなわち端末(1)とのウェブソケットセッションを受け入れるために、全ての必要条件がそれのために満たされる場合、サーバから確認を受信し（SS_OK）、端末(1)に接続承認（SS_OK）を再送信する。セッション番号（NUM）も端末(1)に送信される。これは、端末とサーバを関連付けることを可能にする、プロキシモジュールによって管理されるユニークな識別子である。例えば、この目的のために、プロキシモジュールは、各セッション番号に対する、端末のアドレスおよびサーバの対応するアドレスを有するテーブルを維持することができる。

【0048】

ステップE2の間、プロキシモジュールは、期間（T_timer）を例えば５分に初期化する。上述した変形例において、このパラメータは、クライアントが停止を検出する前の待ち時間の長さを指定することを可能にするSec-WebSocket-Extensionsを用いて再送信され得る。

【0049】

この期間の終わりに、ウェブソケットセッション（SS_WS）上でサーバから来るメッセージが検出されなかったら、通信セッションは停止していると宣言され、ステップE3の間に、プロキシが端末にウェブソケットセッションコマンドの終わりを送信する（メッセージ：END_SS_WS）。このタイプのメッセージは、RFC 6455の中で標準化されている。

【0050】

この時点から、ウェブソケットセッション（SS_WS）は、端末とプロキシモジュール間で部分的に閉じられる。端末でのエネルギー消費を減らすために、対応する物理リンク（無線、モバイルなど）は、選択的に切断され得る。この可能性が、本発明による閉じられるセッションによって利用できるようにされるが、それは、本発明それ自体ではなく、本発明の一部分を形成する。

【0051】

終了に続くステップE4の間、プロキシモジュールは、特に、このセッション上で交換されるアプリケーションメッセージを聞く（LST）ことにより、ウェブソケットセッション（SS_WS）を担当する。メッセージが検出されない限り、プロキシは聞く（LST）ことを続け、セッションは閉じたままである。サーバから来るウェブソケット情報メッセージ（MSG_WS）が検出される時、この方法は、メッセージを、セッション（SS_WS）をウェイクアップさせるためにそれを要求する通知サーバ(4)に送信して、ステップE4を出る。通知サーバは、通知を送信することによって、例えば、パラメータとして渡された以前中断されたウェブソケットセッションの番号（NUM）と共に、ウェブソケットセッションを再開させるためにそれを要求するバイナリSMSメッセージ（SMS：WK_UP）を用いることによって、セッションをウェイクアップさせる。通知がセッションとは無関係に送信されることは、この点で思い出されるべきである。このステップの目的は、停止のこの期間の利点を維持するために、ほとんどエネルギーを消費しないことが可能な手段（SMS, Zigbee(登録商標)、など）によって、端末にウェブソケット再接続情報を送信することである。

【0052】

通知、例えばメッセージは、ステップE13の間に、端末によって受信される。

【0053】

セッションのウェイクアップに続くステップE14の間に、新たな交渉またはハンドシェイク段階が、移動端末によって開始される。この段階は、ステップE10のそれと非常に似ている。移動端末(1)は、標準によって定義されるような標準メッセージに、最適化されたウェブソケットセッション（WSO）を要求するための追加パラメータを加えて、更にステップE10とは異なり、そのメッセージ（HS_WS(WSO, NUM)）の中のセッション番号（NUM）を呼び戻すことによって、ウェブソケットハンドシェイクを開始する。プロキシ(2)は、ステップE5の間、通信セッションの復旧を管理するために、このメッセージを受信して、セッション番号（NUM）と共に、端末に接続承認（SS_OK）を送信する。

【0054】

一旦セッションが復旧されると、ステップE6の間、プロキシモジュールは、サーバから端末に以前受信されていたウェブソケットメッセージ（MSG_WS）を転送する必要がある。

【0055】

従って、サーバから見て、あたかもセッションが中断されなかったかのように、全ては行われた。本発明によって利用可能にされた最適化されたセッションモードが要求された場合には、同じことが端末にも当てはまる。端末のために、この方法は、特に有益である。なぜなら、それは、セッションを運ぶ物理リンクの終了および／または切断（例えば、無線チャネルまたはイーサネット(登録商標)リンクC1を切断すること、端末のイーサネット(登録商標)、WiFi、Zigbee(登録商標)モジュールを停止させること、など）によって、特定の実施態様に応じて、おそらく続くセッションの終了によって、停止の期間の間、セッションを閉じることを可能にするからである。

【0056】

当然、上記の実施態様は、純粋に非限定的な提示として与えられ、当業者によって、多数の修正が、それによって本発明の範囲を越えずに、それに対して容易になされ得る。

【0057】

特に、本発明は、端末をスタンバイ状態にして、サーバ情報がそれに対して送信される時にのみ、それがウェイクアップすることを可能にするための装置とも関連付けられ得る。

【符号の説明】

【0058】

1 クライアント端末
2 プロキシモジュール
3 アプリケーションサーバ
4 通知サーバ
5 インターネット
6 ネットワーク
9 リンク
10 ゲートウェイ

【図1】

【図2】

【図3】