特許 6091644 モバイル・ネットワークにおける持続性ＴＣＰ接続なしのプッシュ・サービス

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

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

(11)【特許番号】6091644

(24)【登録日】2017年2月17日

(45)【発行日】2017年3月8日

(54)【発明の名称】モバイル・ネットワークにおける持続性ＴＣＰ接続なしのプッシュ・サービス

(51)【国際特許分類】

   H04W 12/08 20090101AFI20170227BHJP

   H04W 4/12 20090101ALI20170227BHJP

   G06F 13/00 20060101ALI20170227BHJP

   H04M 11/00 20060101ALI20170227BHJP

【ＦＩ】

   H04W12/08

   H04W4/12

   G06F13/00 510A

   H04M11/00 302

【請求項の数】10

【全頁数】15

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

(86)(22)【出願日】2013年11月8日

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

(43)【公表日】2016年3月3日

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

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

(87)【国際公開日】20140605

【審査請求日】2015年7月24日

(31)【優先権主張番号】13/686,659

(32)【優先日】2012年11月27日

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

(73)【特許権者】

【識別番号】391030332

【氏名又は名称】アルカテル−ルーセント

(74)【代理人】

【識別番号】100094112

【弁理士】

【氏名又は名称】岡部 讓

(74)【代理人】

【識別番号】100106183

【弁理士】

【氏名又は名称】吉澤 弘司

(74)【代理人】

【識別番号】100114915

【弁理士】

【氏名又は名称】三村 治彦

(74)【代理人】

【識別番号】100120363

【弁理士】

【氏名又は名称】久保田 智樹

(74)【代理人】

【識別番号】100125139

【弁理士】

【氏名又は名称】岡部 洋

(72)【発明者】

【氏名】グリンシュパン，エドワード

(72)【発明者】

【氏名】カーン，コリン

(72)【発明者】

【氏名】ヴァーバスキ，ミラ

(72)【発明者】

【氏名】サティアナラヤン，サンカラナラヤナン

(72)【発明者】

【氏名】スミス，マーク，エー．

【審査官】 望月 章俊

(56)【参考文献】

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

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

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

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

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

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

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

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

Ｇ０６Ｆ１３／００

Ｈ０４Ｍ１１／００

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

【請求項1】

プッシュ・サーバにおいて、持続性伝送制御プロトコル（ＴＣＰ）接続のない第１の内部インターフェースを経由して、プッシュ・クライアントからモバイル・デバイスについての登録情報を受信するステップであって、前記登録情報は、前記モバイル・デバイスについてのプライベート・インターネット・プロトコル（ＩＰ）アドレスと、前記モバイル・デバイスの上のアプリケーション・クライアントのインスタンスに関連するモバイル・デバイス・セッション識別子とを含む、受信するステップと、
前記プッシュ・サーバにおいて、サービス・プロバイダ・ファイアウォールの外側にさらされる第２のインターフェースを経由して、アプリケーション・サーバのイベントに関連するプッシュ・トリガを受信するステップであって、前記プッシュ・トリガは、プッシュ・トリガ・セッション識別子を含む、受信するステップと、
前記プッシュ・トリガ・セッション識別子が前記モバイル・デバイス・セッション識別子にマッチするときに、前記プッシュ・トリガが、前記モバイル・デバイスの上の前記アプリケーション・クライアントの前記インスタンスに関連づけられることを決定するステップと、
前記プッシュ・トリガを前記プッシュ・クライアントに対して送信するステップと
を含む方法。

【請求項2】

前記プッシュ・トリガは、持続性ＴＣＰ接続のない前記第１の内部インターフェース、またはセルラー方式ネットワーク上のうちの一方を経由して前記プッシュ・クライアントに対して送信される、請求項１に記載の方法。

【請求項3】

前記第１の内部インターフェースを経由した前記プッシュ・サーバと前記プッシュ・クライアントとの間の接続は、ユーザ・データグラム・プロトコル（ＵＤＰ）ベースの接続である、請求項１に記載の方法。

【請求項4】

前記第１の内部インターフェースを経由した前記プッシュ・サーバと前記プッシュ・クライアントとの間の接続は、非持続性ＴＣＰ接続である、請求項１に記載の方法。

【請求項5】

アプリケーション特有のＴＣＰ接続をサポートするインターフェースを経由して前記アプリケーション・クライアントから前記アプリケーション・サーバへと前記モバイル・デバイス・セッション識別子を送信するステップ
をさらに含む、請求項１に記載の方法。

【請求項6】

前記モバイル・デバイスは、前記モバイル・デバイス・セッション識別子が前記アプリケーション・サーバに対して送信され、送信すべきアプリケーション・データがなくなった後に、アイドル状態に設定される、請求項５に記載の方法。

【請求項7】

前記モバイル・デバイスは、前記プッシュ・トリガに関連するページング・メッセージが前記プッシュ・クライアントにおいて受信されるときに、非アイドル状態に設定される、請求項５に記載の方法。

【請求項8】

前記プッシュ・クライアントにおいて、前記プッシュ・トリガを受信するステップと、
前記プッシュ・トリガを前記アプリケーション・クライアントに対して通信するステップと
をさらに含む、請求項１に記載の方法。

【請求項9】

前記アプリケーション・クライアントにおいて、前記プッシュ・トリガを受信するステップと、
前記プッシュ・トリガに関連するデータを受信するために、前記アプリケーション・クライアントと前記アプリケーション・サーバとの間のアプリケーション特有のＴＣＰベースの接続を確立するステップと
をさらに含む、請求項７に記載の方法。

【請求項10】

前記モバイル・デバイスが第１のアクセス・ネットワークから第２のアクセス・ネットワークへと移動するときに、前記プライベートＩＰアドレスまたは前記セッション識別子が前記の第１のアクセス・ネットワークと第２のアクセス・ネットワークとの間で変化する場合に、前記プッシュ・クライアントから前記プッシュ・サーバへ前記登録情報を送信するステップをさらに含む、請求項１に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一般に、モバイル・ネットワークに関し、より詳細には、モバイル・ネットワーク・プッシュ・サービスに関する。

【背景技術】

【0002】

モバイル・デバイス・アプリケーションは、一般的には、クライアント・サーバ・モデルで動作し、このモデルでは、モバイル・デバイスの上のアプリケーション・クライアントは、１つまたは複数のネットワーク・ベースのアプリケーション・サーバからデータを受信し、処理する。サーバからデータを取得するために、アプリケーション・クライアントは、プル・モードまたはプッシュ・モードのいずれかを使用することができる。プル・モードにおいては、アプリケーション・クライアントは、新しいデータを求めてアプリケーション・サーバを定期的にポーリングする。プッシュ・モードにおいては、アプリケーション・サーバは、アプリケーション・クライアントがポーリングする必要性なしに、新しいデータが使用可能であるときに、アプリケーション・クライアントに対してデータを「プッシュする」。

【0003】

多くの場合に、ネットワークをポーリングするアプリケーションは、プッシュ・サービスから恩恵を受けることができる。プッシュ・サービスは、伝統的な電子メール（例えば、新しい電子メールが、サーバに到着するときに、モバイル・デバイスに対してプッシュ通知を送信するための）と、ショート・メッセージ・サービス（ＳＭＳ：Ｓｈｏｒｔ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）（例えば、ＳＭＳメッセージが、サーバに到着するときに、プッシュ通知を送信するための）と、ボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ：ｖｏｉｃｅ ｏｖｅｒ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）（例えば、着信コールの通知のための）と、ウェブ・ブラウジング（例えば、いつウェブ・ページをリフレッシュすべきかについての通知のための）と、３Ｇ／４Ｇスマート・モバイル・デバイスのための成長するビデオ・アプリケーションとを含む。そのようなビデオ・アプリケーションのためのプッシュ・イベント通知の例は、それだけには限定されないが、ネットワーク状態変化通知と、ポリシー変化通知と、アプリケーション・クライアント応答を必要とする可能性がある他の通知とを含む。

【0004】

プッシュ・モードは、セルラー方式ネットワークの上で動作するモバイル・デバイスのために特に重要である。一般的に、モバイル・デバイスが、送信すべきデータ、または受信すべきデータを有していないときに、モバイル・デバイスは、アイドル（例えば、休眠、スリープ）モードへと入って、デバイスの無線オペレーションに関連するバッテリ電力と、オーバー・ザ・エア・リソースとを節約する。無線アクセス・ネットワークは、アイドル・デバイスのロケーション状態情報を維持し、また対応するセルラー方式アクセス技術規格によって規定されるページング・メカニズムを使用して、データがデバイスのために到着するときに、モバイル・デバイスをウェイクアップさせる。

【0005】

対照的に、プル・モードは、アプリケーション・クライアントが新しいデータを求めてアプリケーション・サーバにポーリングする必要があるときに、サーバがそのような新しいデータを有しているか否かにかかわらず、モバイル・デバイスが、定期的にアイドル・モードを抜け出ることを必要としており、結果的にモバイル・デバイスのバッテリ・リソースの浪費をもたらし、またエア通信の上で不必要である。さらに、アプリケーション応答時間を改善することは、ポーリング頻度を増大させることを必要とし、より多くのバッテリと、オーバー・ザ・エア・リソースとが、浪費される。ポーリング頻度を低下させることは、アプリケーション・サーバ・イベントに対するアプリケーション・クライアント応答においてより多くの遅延をもたらす可能性がある。

【0006】

すべてのＩＰベースのデータ・サービスを使用する３Ｇネットワークと４Ｇネットワークとを用いて、現在のセルラー方式サービス・プロバイダのための典型的なネットワーク・アーキテクチャは、サービス・プロバイダのコア・ネットワークと、公衆インターネットとの間のファイアウォールとともに、モバイル・デバイスのためのプライベートＩＰアドレスを使用する。これは、プッシュ実装形態のためのかなり厳しい課題を提示する。モバイル・デバイス（プライベートＩＰアドレスを有する）の上のアプリケーション・クライアントと、アプリケーション・サーバとの間に位置する、ネットワーク・アドレス変換（ＮＡＴ：ｎｅｔｗｏｒｋ ａｄｄｒｅｓｓ ｔｒａｎｓｌａｔｉｏｎ）を有する典型的なファイアウォールは、アプリケーション・クライアントと、アプリケーション・サーバとの間の伝送制御プロトコル（ＴＣＰ：ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）ベースのクライアントにより開始された通信だけを可能にする。しかしながら、アプリケーション・クライアントと、アプリケーション・サーバとの間のそのようなＴＣＰ接続を維持することは、定期的な「ハートビート（ｈｅａｒｔ−ｂｅａｔｉｎｇ）」を必要とし、このハートビートは、モバイル・デバイス・アイドル・モードの上のプル・モードと類似した影響を有する、プル・モード（クライアントにより開始されたＴＣＰパケットは、定期的に交換される必要がある）に本質的に同等である。

【0007】

ファイアウォールの背後にプライベートＩＰアドレスを有するアプリケーション・クライアントを用いて、ファイアウォールの外側に位置するアプリケーション・サーバは、クライアントのプライベートＩＰアドレスが、サービス・プロバイダのネットワークの外側から到達可能ではないので、ファイアウォールの中に特別な「ホール（ｈｏｌｅ）」のないアプリケーション・クライアントに対してＩＰパケットを送信することができない。そのような「ファイアウォールの中のホール」は、一般的に、アプリケーション・サーバとのＴＣＰ接続が、アプリケーション・クライアントによって開始されるときに、自動的に生成される。ファイアウォールＮＡＴ機能は、クライアントによって送信されたＴＣＰ／ＩＰパケットの中で、＜多数のクライアントのために共通のパブリックＩＰアドレス＋固有の新しいソースＴＣＰポート番号＞のペアで、ペア＜ソースＩＰアドレス、ソースＴＣＰポート番号＞を置換し、またある種の持続時間の間に、ペア＜ソースＩＰアドレス、ソースＴＣＰポート番号＞と、＜固有の新しいソースＴＣＰポート番号＞との間のマッピングを生成し、このようにして＜多数のクライアントのために共通のパブリックＩＰアドレス＋固有の新しいソースＴＣＰポート番号＞に対してアドレス指定されるアプリケーション・サーバからのパケットが、アプリケーション・クライアントの＜ソースＩＰアドレス、ソースＴＣＰポート番号＞へと転送されることを可能にしている。そのようなマッピングは、アプリケーション・サーバが、アプリケーション・クライアントに対してパケットを送信することを可能にする、ファイアウォールの中の「ホール」を生成する。ＴＣＰトラフィックのないときに（例えば、クライアントが、アイドル・モードへと進むときに）、マッピングは、機能しなくなり（ａｇｅ ｏｕｔ）、またクライアントは、サーバから到達できないようになる。しかしながら、このマッピングをリフレッシュするために定期的なＴＣＰトラフィックを送信することにより、持続性ＴＣＰ接続を維持することは、高くつき、またモバイル・デバイスが、定期的にアイドル状態を抜け出してそのようなトラフィックを生成することを必要とする。また、「エージング」タイマー構成は、異なるファイアウォールの場合に変化することもあり、そのようなトラフィックが、不必要に頻繁になるための要件を結果的にもたらしている。

【0008】

既存の問題解決手法は、ファイアウォールの課題の重要性を示しているが、またサービス・プロバイダ・ネットワークと、公衆インターネットとの間のファイアウォールを有するプッシュ実装形態についての単一の満足できるアプローチが存在しないことも示している。

【0009】

例えば、ＴＣＰベースのモバイル・オペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）またはモバイル・デバイス・ベンダのプッシュ・サービスは、一般的に、インターネットの中のどこにでも位置している（ワイヤレス・サービス・プロバイダのファイアウォールによって保護されたコアの外側の）プッシュ・サーバと、モバイル・デバイスＯＳと結合されたプッシュ・クライアント・ミドルウェアと、アプリケーションのクライアントとサーバとにさらされて、プッシュ・サービスを登録し、また受信するモバイル・デバイスＯＳに特有のＡＰＩの組とから構成される。しかしながら、持続性ＴＣＰ接続は、ファイアウォールを通して維持される必要がある。そのような接続を維持することは、定期的なＴＣＰトラフィックが、モバイル・デバイスと、プッシュ・サーバとの間で交換されることを必要とし、バッテリ寿命と、オーバー・ザ・エア・リソースとの両方の浪費を結果的にもたらしている。ＴＣＰキープ・アライブの頻度（いくつかの場合には、それは、毎秒当たりである）および／またはファイアウォール・エージング・リフレッシュ交換に応じて、モバイル・デバイスは、アイドル・モードに入ることを完全に防止している（キープ・アライブ交換が、あまりにも頻繁である場合）か、またはキープ・アライブ交換のために定期的にアイドル・モードを抜け出るように強制されるかのいずれかである。ＴＣＰ交換の頻度は、一般的に、ＯＳ−特有の考慮（例えば、モバイル・デバイスが、電源を遮断し、または急激にワイヤレス・カバレッジ範囲の外に出るときに、サーバが、死んでいるＴＣＰ接続を検出することを可能にするＴＣＰキープ・アライブ・メカニズム、または他のメカニズム）により、また同様にサーバからクライアントへの逆方向のＴＣＰトラフィックについてのファイアウォール・ホール・エージング・タイマーにより、指示される。また、数千万個のモバイル・クライアントとの持続性ＴＣＰ接続を維持することは、かなりのサーバ・リソースが、割り付けられることを必要とする。加えて、この方法は、それが、サード・パーティのプッシュ・サーバが、モバイル・デバイスと、それらのアプリケーションの使用とを追跡することを可能にすることができるので、モバイル・デバイス・ユーザについてのプライバシー問題を引き起こす可能性がある。

【0010】

図１は、持続性ＴＣＰ接続ベースのベンダによって制御されたプッシュ・サービスを実装するためのモバイル・ネットワークの機能図を示すものである。ネットワーク１００は、一般に、１つまたは複数のモバイル・デバイス１０２についてのプライベートＩＰアドレスの使用を通して、モバイル・ネットワーク・サービス（例えば、音声サービス、テキスト・サービス、ビデオ・サービス、および他のデータ・サービス）を提供する。モバイル・デバイス１０２は、カスタマイズされた、ベンダによって実装されたプッシュ・サービスを利用して、モバイル・デバイス・オペレーティング・システム（ＯＳ）と、様々なモバイル・ネットワーク・サービス・アプリケーションを実行するように構成されている。ネットワーク１００は、モバイル・サービス・プロバイダのコア・ネットワーク１０６と、公衆インターネット１０８との間のネットワーク・アドレス変換（ＮＡＴ）を有するファイアウォール１０４を含んでいる。コア・ネットワーク１０６は、パケット・データ・ネットワーク・ゲートウェイ（ＰＤＮ−ＧＷ：ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋ ｇａｔｅｗａｙ）１１０、ホーム加入者サーバ（ＨＳＳ：ｈｏｍｅ ｓｕｂｓｃｒｉｂｅｒ ｓｅｒｖｅｒ）１１２、モビリティ管理エンティティ（ＭＭＥ：ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）１１４、サービング・ゲートウェイ（Ｓ−ＧＷ：ｓｅｒｖｉｎｇ ｇａｔｅｗａｙ）１１６、１つまたは複数のｅノードＢ（ｅＮｏｄｅＢ）セルラー方式アクセス・ポイント１１８など、ＬＴＥモバイル通信システムを実装するために一般的に使用されるコンポーネントを含んでいる。しかしながら、コア・ネットワーク１０６は、コンポーネントが、任意のそのような規格によって規定されたネットワーク・アーキテクチャを実装するように構成されている、２Ｇネットワーク、３Ｇ（例えば、ＷＣＤＭＡ−ＵＭＴＳ、ＣＤＭＡ）ネットワーク、または４Ｇ（例えば、ＬＴＥ、ＷＩＭＡＸ）ネットワークとすることができる。それゆえに、図１は、ＬＴＥモバイル通信システムを示すものであるが、当業者なら、１つまたは複数のこれらのコンポーネントと、様々な他のよく知られているコンポーネントとは、２Ｇ、３Ｇ、４Ｇまたは他のモバイル通信システム・ネットワーク・アーキテクチャを実装するために追加され、または組み合わされ得ることを認識するであろう。

【0011】

ネットワーク１００は、ファイアウォール１０４の外側の公衆インターネット１０８を経由してアクセス可能なプッシュ・サーバ１２０をさらに含むことができる。モバイル・デバイス１０２は、プッシュ・クライアント１２２（例えば、モバイル・デバイス・オペレーティング・システム（ＯＳ）と結合されたミドルウェア）と、持続性ＴＣＰベースの接続を経由してモバイル・デバイス／ＯＳベンダに特有のプッシュ・サービスを登録し、また受信するためのアプリケーション・クライアント１２６とアプリケーション・サーバ１２８とにさらされる１つまたは複数のアプリケーション・プログラミング・インターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅｓ）１２４とを含むことができる。例えば、モバイル・デバイス１０２は、ＴＣＰベースの接続を維持するためにハートビート・タイプの通信を送信するように定期的に「ウェイクアップ」することができる。

【0012】

ネットワーク１００において、アプリケーション・サーバ１２８は、ファイアウォールの中の特別な「ホール」なしに、プライベートＩＰアドレスを有するモバイル・デバイス１０２に対して、ＩＰパケットを送信することができない（すなわち、クライアントのプライベートＩＰアドレスは、サービス・プロバイダのコア・ネットワーク１０６の外側から到達可能でない）。例えば、ファイアウォール１０４の中のそのような「ホール」は、アプリケーション・サーバ１２８とのＴＣＰベースの接続がモバイル・デバイス１０２によって開始されるときに、自動的に生成されることもある。特に、ファイアウォールＮＡＴ機能は、モバイル・デバイス１０２によって送信されるＴＣＰ／ＩＰパケットの中で、パブリック・アドレス／ポート番号ペアで、例えば、＜多数のモバイル・デバイスのために共通のパブリックＩＰアドレス＋固有の新しいソースＴＣＰポート番号＞で、プライベート・アドレス／ポート番号ペアを、例えば、＜ソースＩＰアドレス、ソースＴＣＰポート番号＞を置換し、また、ペア、すなわち＜ソースＩＰアドレス、ソースＴＣＰポート番号＞と、固有の新しいソースＴＣＰポート番号との間のマッピングを（例えば、ある種の持続時間の間に）生成する。そのようにして、アプリケーション・サーバ１２８は、特定のモバイル・デバイス１０２のプライベート・アドレス／ポート番号ペア、すなわち、＜ソースＩＰアドレス、ソースＴＣＰポート番号＞に対して転送され得る＜多数のクライアントのために共通のパブリックＩＰアドレス＋固有の新しいソースＴＣＰポート番号＞に対してアドレス指定されるパケットを送信することができる。ファイアウォールの中で「ホール」を生成することとして規定されるこのマッピング・プロシージャは、アプリケーション・サーバ１２８が、アプリケーション・クライアント１２６に対してパケットを送信することを可能にする。しかしながら、ＴＣＰベースの通信トラフィックが、ないときに（例えば、モバイル・デバイス１０２が、アイドル・モードへと切り替わるときに）、パブリック／プライベート・マッピングは、有効期限が切れる可能性があり、アプリケーション・クライアント１２６が、アプリケーション・サーバ１２８から到達不可能になるであろうことを意味する。

【0013】

ユーザ・データグラム・プロトコル・ベースのセッション開始プロトコル（ＵＤＰベースのＳＩＰ：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ−ｂａｓｅｄ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）モデルは、特別なセッション境界制御装置デバイスが、ネットワークに対するモバイル・デバイス登録中に、モバイル・デバイスに到達するようにホールをファイアウォールの中に動的に「パンチで孔を開ける（ｐｕｎｃｈ）」ように、ファイアウォールと一緒に動作することを必要とする。この方法により、モバイル・デバイスは、着信コールを受信することができるようになる。しかしながら、ＵＤＰベースのＳＩＰモデルは、新しいアプリケーションが、マーケットに現れるたびごとに、おのおのの新しいアプリケーションと、セッション境界制御装置の再構成とのための専門分野に特化したセッション境界制御機能を必要とする可能性もある。

【0014】

ＳＭＳメッセージはまた、非−ＳＭＳインスタント・メッセージ・アプリケーションについてのプッシュ通知のために利用されることもある。しかしながら、多数のサービス・プロバイダ・プランは、ＳＭＳメッセージを受信することについてユーザに課金することを計画している。それゆえに、プッシュ通知のためにＳＭＳを使用することは、そのようなプランを有するユーザにとって予期せぬ課金、および歓迎されない課金を引き起こす可能性がある。

【発明の概要】

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

【0015】

２Ｇ／３Ｇ／４Ｇモビリティ・ネットワークの上でサービスを受信するデバイスのアイドル（例えば、スリープまたは休眠）モード要件と互換性のある、ワイヤレス・サービス・プロバイダ・コア・ネットワークにおけるプッシュ・サービスのための製造の方法、システム、および物品が、開示される。一実施形態においては、プッシュ・サーバは、２つのインターフェースを含んでいる。第１のインターフェースは、ファイアウォールの背後のサービス・プロバイダのプライベート・ネットワークの内部にあり、その結果、モバイル・デバイスは、モバイル・デバイスのプライベートＩＰアドレスを使用して、プッシュ・サーバから到達可能である。第２のインターフェースは、ファイアウォールの外側に位置するアプリケーション・サーバが、プッシュ・トリガを開始することができるように、公開されている（すなわち、サービス・プロバイダのファイアウォールの外側にさらされている）。

【0016】

このアーキテクチャは、プッシュ・サーバと、モバイル・デバイスとの間の持続性ＴＣＰ接続のための必要性を取り除いている。例えば、モバイル・デバイスの内部のプッシュ・サーバとプッシュ・クライアントとの間のインターフェースは、単一のプッシュ通知を配信するためのプッシュ・サーバによって開始される、信頼性または非持続性ＴＣＰ接続のためのいくつかの追加された肯定応答メッセージを有するコネクション・レス型（例えば、ＵＤＰ）プロトコルをサポートすることができる。

【0017】

アプリケーション・サーバの上に新しいデータのないときに、モバイル・デバイスは、アイドル（例えば、スリープまたは休眠）モードに進んで、バッテリ電力を節約することができ、またモバイル・デバイスに対応するセルラー方式アクセス・ネットワークは、プッシュ・サーバからのパケットが、アイドル状態にあるモバイル・デバイスに対して送信される必要があるときに、ロケーション・アップデート・メカニズムが、モバイル・デバイスをウェイクアップさせ、またモバイル・デバイスが、プッシュ・サーバからプッシュ・トリガを受信することを可能にすることができるように、ネットワーク特有の（すなわち、ネイティブの）ロケーション・アップデート・メカニズムを維持することができる。

【0018】

一実施形態においては、方法は、プッシュ・サーバにおいて、持続性ＴＣＰ接続なしに第１の内部インターフェースを経由して、プッシュ・クライアントからモバイル・デバイスについての登録情報を受信するステップを含む。登録情報は、モバイル・デバイスについてのプライベートＩＰアドレスと、モバイル・デバイスの上のアプリケーション・クライアントのインスタンスに関連するモバイル・デバイス・セッション識別子とを含んでいる。後で、アプリケーション・サーバのイベントに関連するプッシュ・トリガが、サービス・プロバイダ・ファイアウォールの外側にさらされる第２のインターフェースを経由して、プッシュ・サーバにおいて受信され、そこではプッシュ・トリガは、プッシュ・トリガ・セッション識別子を含んでいる。プッシュ・トリガ・セッション識別子がモバイル・デバイス・セッション識別子にマッチするときに、プッシュ・トリガは、モバイル・デバイスの上のアプリケーション・クライアントのインスタンスに関連づけられると決定され、またプッシュ・トリガ・セッション識別子がモバイル・デバイス・セッション識別子にマッチするときに、プッシュ・トリガは、モバイル・デバイスの上のプッシュ・クライアントに対してプッシュ・サーバによって送信される。プッシュ・トリガは、内部の第１のインターフェース（モバイル・デバイスが、セルラー方式２Ｇ〜３Ｇ〜４Ｇインターフェースを経由して接続される場合）または外部の第２のインターフェース（モバイル・デバイスが、Ｗｉ-Ｆｉインターフェースを経由して接続される場合）のうちの一方を経由してプッシュ・クライアントに対して送信されることもあり、また内部の第１のインターフェースの上のプッシュ・トリガは、ＵＤＰまたは非持続性ＴＣＰを使用して送信されることもある。プッシュ・クライアントとのＴＣＰ接続は、プッシュ・トリガを配信するようにプッシュ・サーバによって開始され、また次いでプッシュ・トリガが配信された後に、終了されることもある。

【0019】

一実施形態によれば、セッション識別子は、アプリケーション特有のクライアント・サーバ通信を経由してアプリケーション・クライアントからアプリケーション・サーバへと送信される。通信は、ＴＣＰに基づいたものとすることができる。

【0020】

一実施形態によれば、セッション識別子が、アプリケーション・サーバに対して送信された後に、モバイル・デバイスは、アイドル状態に設定される。モバイル・デバイスは、プッシュ・トリガに関連するページング・メッセージが、プッシュ・クライアントにおいて受信されるときに、非アイドル状態に設定される。

【0021】

一実施形態によれば、プッシュ・トリガは、プッシュ・トリガにおけるセッション識別子を使用して、アプリケーション・クライアント・インスタンスを識別して、プッシュ・クライアントにおいて受信され、またアプリケーション・クライアントに対して通信される。

【0022】

一実施形態によれば、プッシュ・トリガは、アプリケーション・クライアントにおいて受信され、またアプリケーション特有のＴＣＰベースの接続が、アプリケーション・クライアントと、アプリケーション・サーバとの間で確立されて、プッシュ・トリガに関連するデータを受信する。

【0023】

一実施形態によれば、登録情報は、モバイル・デバイスが、第１のアクセス・ネットワークから第２のアクセス・ネットワークへと移動するときに、プライベートＩＰアドレスまたはセッション識別子が、第１のアクセス・ネットワークと、第２のアクセス・ネットワークとの間で変化する場合に、送信される。

【0024】

これらの利点、および他の利点は、以下の詳細な説明と、添付の図面とを参照することにより当業者にとって明らかになるであろう。

【図面の簡単な説明】

【0025】

【図1】持続性ＴＣＰ接続ベースのベンダによって制御されたプッシュ・サービスを実装するためのモバイル・ネットワークの機能図である。

【図2】一実施形態による、持続性ＴＣＰ接続のないプッシュ・サービスを実装するためのモバイル・ネットワークの機能図である。

【図3】一実施形態によるプッシュ・サービス実装フローチャートを示す図である。

【図4】一実施形態による、持続性ＴＣＰ接続のない代替的なプッシュ・サービスを実装するためのモバイル・ネットワークの機能図である。

【図5】一実施形態による、持続性ＴＣＰ接続のない別の代替的なプッシュ・サービスを実装するためのモバイル・ネットワークの機能図である。

【図6】持続性ＴＣＰ接続のないプッシュ・サービスを実装するために使用され得る例示のコンピュータの高レベル・ブロック図である。

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

【0026】

多数の現在のモバイル・ネットワーク（例えば、３Ｇ／４Ｇ／ＬＴＥ）は、伝送制御プロトコル（ＴＣＰ）／インターネット・プロトコル（ＩＰ）ベースのデータ・サービスを使用しており、これらのデータ・サービスを使用して、様々なベンダによって制御されたプッシュ・サービスを提供する。アプリケーション・クライアントが、サービス・プロバイダ・ネットワークなどにおいて、ファイアウォールの背後に常駐するときに、新しいデータを求めて多くの場合にネットワーク・サーバをポーリングする必要があるアプリケーションは、本明細書において開示されるように、プッシュ・サービスを確立する非ＴＣＰのやり方から恩恵を受けることができる。そのようなアプリケーションの例は、伝統的な電子メール（新しい電子メールが、サーバに到着するときに、プッシュ通知が、モバイル・デバイスに対して送信される）と、ＳＭＳ（ＳＭＳがサーバに到着するときに、プッシュ通知が、送信される）と、ＶｏＩＰ（着信コールのためのプッシュ通知）と、ウェブ・ブラウジング（いつウェブ・ページをリフレッシュすべきかについてのプッシュ通知）と、３Ｇ／４Ｇスマート・モバイル・デバイスのためのますます多くのビデオ・アプリケーションとを含む。そのようなビデオ・アプリケーションについてのプッシュ・イベント通知の例は、それだけには限定されないが、ネットワーク状態変化通知と、ポリシー変化通知と、堅牢なアプリケーション・クライアント応答を必要とする可能性がある他の通知とを含む。

【0027】

本明細書において提供される様々な実施形態は、ワイヤレス・サービス・プロバイダのコア・ネットワークにおける、持続性ＴＣＰ接続のないプッシュ・サービスについて詳しく述べている。図２は、一実施形態による、持続性ＴＣＰ接続のないプッシュ・サービスを実装するためのモバイル・ネットワーク２００の機能図を示すものである。図２に示されるプッシュ・サービスは、２Ｇ／３Ｇ／４Ｇモビリティ・ネットワークまたは他のモビリティ・ネットワークの上でサービスを受信するモバイル・デバイス１０２のアイドル・モード要件と互換性がある。例えば、非ＴＣＰプッシュ・サーバ２０２は、２つの通信インターフェースを有している。第１のインターフェース２０４は、公開されており、すなわち、サービス・プロバイダのファイアウォールの外側にさらされており、その結果、ファイアウォール１０４の外側のアプリケーション・サーバ１２８は、プッシュ・トリガ（すなわち、アプリケーション・サーバ・イベントの通知）を開始することができる。第２の内部インターフェース２０６は、ファイアウォール１０４の背後のサービス・プロバイダのプライベート・ネットワーク１０６の内部にあり、その結果、モバイル・デバイス１０２は、モバイル・デバイス１０２のプライベートＩＰアドレスを使用して、非ＴＣＰプッシュ・サーバ２０２から到達可能である。

【0028】

このアーキテクチャは、プッシュ・サーバと、モバイル・デバイス１０２との間の持続性ＴＣＰベースの接続のための必要性を取り除いている。例えば、モバイル・デバイス１０２における非ＴＣＰプッシュ・サーバ２０２と、非ＴＣＰプッシュ・クライアント２０８との間のインターフェースは、ＵＤＰまたは別の非持続性接続に基づいたものとすることができる。当業者なら、一実施形態においては、ＵＤＰベースの非持続性接続が、信頼性のための肯定応答メッセージを含むことができることを認識するであろう。さらに、持続性ＴＣＰ接続のないプッシュ・サービスについての様々な通信プロトコルのうちの任意のものは、非ＴＣＰプッシュ・クライアント２０８と、非ＴＣＰプッシュ・サーバ２０２との間の通信のために使用されることもある。本明細書において使用される場合、非ＴＣＰという用語は、ＴＣＰ（例えば、ＵＤＰベースの接続または通信）と、また非持続性ＴＣＰの接続または通信とを使用していない接続または通信のことを意味しており、ここでは、例えば、ＴＣＰ接続は、単一のメッセージを送信するように確立され、また次いで終了される。

【0029】

アプリケーション・サーバ１２８の上に新しいデータがないときに、モバイル・デバイス１０２は、アイドル・モードへと切り替わって、バッテリ電力を節約することができる。例えば、モバイル・アクセス・ネットワーク１０６は、モバイル・デバイスの場所を見出すための対応するワイヤレス・アクセス技術によって規定された（すなわち、ネイティブの）ロケーション・アップデート・メカニズムを維持することができる。そのようにして、非ＴＣＰプッシュ・サーバ２０２からのパケットが、アイドル状態においてモバイル・デバイス１０２に対して送信される必要があるときに、ネイティブなページング・メカニズムは、モバイル・デバイス１０２をウェイクアップさせ、またモバイル・デバイスが、非ＴＣＰプッシュ・サーバ２０２からプッシュ・トリガを受信することを可能にすることができる。

【0030】

図３は、一実施形態によるプッシュ・サービス実装フローチャートを示すものである。ステップ３００において、ワイヤレス・サービス・プロバイダ・ネットワークを経由したＩＰ接続性が、確立され、またモバイル・デバイス１０２が、プライベートＩＰアドレスを受信する。ステップ３０１において、アプリケーション・クライアント１２６によるセッション開始のすぐ後に、アプリケーション・クライアント１２６は、固有のセッション識別子（ＩＤ）を生成することにより、プッシュ・サービスを求めて、モバイル・デバイス１０２の上で非ＴＣＰプッシュ・クライアント２０８に登録する。当業者なら、セッションＩＤは、本明細書における目的のためのアルゴリズムを生成する異なるＩＤの任意の番号によって生成され得ることを認識するであろう。セッションＩＤを使用して、（ａ）非ＴＣＰプッシュ・サーバ２０２が、モバイル・デバイス１０２を識別して、プッシュ・トリガを伝搬させることを可能にし、また（ｂ）非ＴＣＰプッシュ・クライアント２０８が、非ＴＣＰプッシュ・サーバ２０２からプッシュ・トリガを受信した後に、モバイル・デバイス１０２の上で対応するアプリケーション・クライアント・インスタンスを識別し、また特定のアプリケーション・クライアント１２６に対して着信プッシュ・トリガを伝搬させることを可能にしている。

【0031】

ステップ３０２において、プッシュ・クライアント２０８は、例えば、信頼性のために肯定応答を有するＵＤＰベースの接続を使用して、セッションＩＤ（ステップ３０１からの）と、ＩＰアドレス（ステップ３００からの）とを非ＴＣＰプッシュ・サーバ２０２に登録する。代わりに、非持続性ＴＣＰ接続が、単一のオペレーション（例えば、セッションＩＤの登録、または個別のメッセージの送信）のために確立され、また次いでオペレーションが完了した後に、終了されることもある。

【0032】

ステップ３０３において、アプリケーション・クライアント１２６（例えば、ネットワークにおいてアプリケーション・サーバ１２８とのＴＣＰベースの通信のためのネイティブのアプリケーションを使用した）は、アプリケーション・セッションを確立し、またセッションＩＤをアプリケーション・サーバ１２８に登録し、そのようにしてアプリケーション・サーバ１２８は、必要に応じてプッシュ・トリガを送信することができる。

【0033】

アプリケーション・セッションが、行われるときに、アプリケーション・クライアント１２６と、アプリケーション・サーバ１２８との間のＴＣＰベースの接続は、終了され、またモバイル・デバイス１０２は、ステップ３０４において、アイドル・モードへと切り替わって、バッテリ電力を節約する。一実施形態においては、モバイル・デバイス１０２は、ステップ３００において受信された同じＩＰアドレスをアイドル・モードにおいて保存することができる。次いで、モバイル・ネットワーク１０６は、ロケーション・アップデート機能を使用して、モバイル・デバイス・ロケーション情報を維持することができる。代わりに、モバイル・デバイスのＩＰアドレス変更が、（例えば、ネットワークの間のモビリティ・イベントに起因して）必要とされるときに、様々な３Ｇおよび４Ｇのネットワーキング規格（３ＧＰＰ、３ＧＰＰ２、ＷｉＭＡＸ）は、モバイル・デバイスが、アイドル・モードから切り替わり、また新しく割り当てられたＩＰアドレスを再送信するようにアクティブになることを必要とすることになる。

【0034】

ステップ３０５において、ネットワーク２００におけるアプリケーション・サーバ１２８は、モバイル・デバイス・データまたは状態情報のアップデートを必要とするトリガ・イベント、または新しいデータを受信する。トリガ・イベントは、任意の種類のイベントとすることができる（例えば、新しい電子メールが、電子メール・アプリケーションのために受信される；アプリケーション・サーバ・データベースのコンテンツが、アップデートされ、またアプリケーション・クライアント１２６は、自動的アップデートを受信するために加入される；ネットワークは、非混雑状態になっており、また大規模なビデオ・ファイルが、アプリケーションによってダウンロードされ、またはアップロードされる；アプリケーション・サーバ１２８は、進行中のビデオ・セッションに対する影響を有するアプリケーション・クライアント１２６に対して伝搬される必要があるポリシー・アップデートを受信するなど）。アプリケーション・サーバ１２８は、ステップ３０３においてアプリケーション・サーバ１２８が受信したセッションＩＤを含めて、サービス・プロバイダ・ファイアウォール１０４の外側にさらされた非ＴＣＰプッシュ・サーバ２０２のパブリックＩＰアドレスに対してプッシュ・トリガを送信する。当業者なら、アプリケーション・サーバ１２８が、何としても非ＴＣＰプッシュ・サーバ２０２のＩＰアドレスを取得することができることを認識するであろう（例えば、ＩＰアドレスは、よく知られている、または公開されたＩＰアドレスとすることができる）。代わりに、非ＴＣＰプッシュ・サーバ２０２のＩＰアドレスは、ステップ３０３においてセッションＩＤを有するアプリケーション・サーバ１２８によって受信されることもある。

【0035】

ステップ３０６において、セッションＩＤと、ステップ３００において割り当てられるモバイル・デバイスＩＰアドレスとの間のマッピングを使用して、プッシュ・トリガに関連するモバイル・デバイス１０２を決定して、非ＴＣＰプッシュ・サーバ２０２は、ＵＤＰベースのメッセージ（例えば、肯定応答を有する）を使用してモバイル・デバイス１０２の上の非ＴＣＰプッシュ・クライアント２０８に対してプッシュ・トリガを送信する。例えば、モバイル・デバイス１０２が、アイドル状態にある場合、定期的なページング・メカニズムが、モバイル・アクセス・ネットワーク１０６によって呼び出されて、モバイル・デバイス１０２に対してアドレス指定されるプッシュ・トリガを検出するとすぐに、モバイル・デバイス１０２をウェイクアップさせることができる。さらに、初期のパケットが失われる場合、非ＴＣＰプッシュ・サーバ２０２は、モバイル・デバイス１０２に対してプッシュ・トリガを再送信することができる。

【0036】

ステップ３０７において、モバイル・デバイス１０２の上の非ＴＣＰプッシュ・クライアント２０８は、プッシュ・トリガを受信し、またステップ３０１において生成されるセッションＩＤを使用して、アプリケーション・クライアント１２６に対してプッシュ・トリガを通信する。例えば、非ＴＣＰプッシュ・クライアント２０８は、プッシュ・トリガにおけるセッションＩＤを使用してアプリケーション・クライアント・インスタンスを識別し、またプッシュ・トリガをアプリケーション・クライアント１２６に対して転送することができる。

【0037】

ステップ３０８において、プッシュ・トリガを受信するとすぐに、アプリケーション・クライアント１２６は、アプリケーション・サーバ１２８との新しいＴＣＰベースの接続を確立し、またプッシュ・トリガに関連するデータ（すなわち、トリガ・イベント）をダウンロードする。

【0038】

別の実施形態においては、図２のプッシュ・サービスは、信頼された３Ｇ／４Ｇモバイル・ネットワークの、規格によって規定されたマルチ・アクセス・ネットワーキングの場合に、適用可能である。図４は、一実施形態による、持続性ＴＣＰ接続のない代替的なプッシュ・サービスを実装するためのモバイル・ネットワークの機能図を示すものである。図４において、３Ｇ／４Ｇネットワーク１０６は、１つまたは複数の非３ＧＰＰ基地局４０２を有する信頼された非３ＧＰＰアクセス・ネットワーク４００と相互に作用しているように示されている。実施形態の目的のために、相互作用は、３ＧＰＰ規格におけるように（すなわち、共通のＰＤＮ ＧＷ１１０をＩＰアンカーとして使用して）規定される。上記の図３において説明される同じメカニズムは、ＰＤＮ ＧＷ１１０が、モバイル・デバイス１０２に対してＩＰアクセスをアンカーして、図４における持続性ＴＣＰ接続のないプッシュ・サービスのために利用される可能性がある。一実施形態においては、プッシュ・クライアント−プッシュ・サーバの再登録は、モバイル・デバイス１０２のＩＰアドレスが、変化し、または新しいセッションＩＤが、生成されるたびごとに（例えば、アプリケーション・クライアント１２６が、再開し、またはアプリケーション・クライアントの新しいインスタンスが、開始されるときに）、行われる可能性がある。

【0039】

図５は、一実施形態による、持続性ＴＣＰ接続のない別の代替的なプッシュ・サービスを実装するためのモバイル・ネットワークの機能図を示すものである。図５において、プッシュ・サービスは、ローカル・ブレイクアウトを伴うＷｉ-Ｆｉアクセスをサポートしている。具体的には、ＰＤＮ ＧＷ１１０は、Ｗｉ-Ｆｉアクセス・ポイント５００の上でＩＰセッションをアンカーしてはいない。むしろ、ＩＰセッションが、Ｗｉ-Ｆｉアクセス・ポイント５００の上で確立される（一般的には、Ｗｉ-Ｆｉアクセスのための独立したファイアウォール５０２が存在している）ときに、プッシュ・クライアント２０８は、プッシュ・サーバ２０２の外部で使用可能なパブリックＩＰアドレスを使用して、プッシュ・サーバ２０２とＷｉ-Ｆｉの上で持続性ＴＣＰベースの接続５０４を確立し、また維持する。結果として、モバイル・デバイス１０２が、モバイル・ネットワークを経由して接続されるときに、プッシュ・トリガは、非ＴＣＰ接続５０６を経由して伝搬させられることもあり、モバイル・ネットワーク１０６の上にあるときに、アイドル・モードの完全な利点を可能にする。モバイル・デバイス１０２が、Ｗｉ-Ｆｉアクセス・ポイント５００を経由して接続されるときに、持続性ＴＣＰベースの接続５０４が、維持される。Ｗｉ-Ｆｉアクセスについてはアイドル・モードは存在していないので、Ｗｉ-Ｆｉの上のそのような持続性ＴＣＰベースの接続５０４は、あまり否定的な影響を有してはいない。

【0040】

様々な実施形態は、ネットワーク・オペレータが、接続を設定することに関連する信号伝達負荷を低減させるための固有のやり方を提供している。現在では、これらの接続は、持続性ＴＣＰベースの接続（競合するプッシュ・モデル）を維持するために、データ（プル・モデル）を求めてサーバをポーリングするか、または定期的なハートビートを送信するかのいずれかのように構成されている。本明細書において提案されるＵＤＰベースの、または非持続性ＴＣＰベースの接続を使用することにより、これらの両方を取り除くことは、所与のレベルのネットワーク・トラフィックをサポートするために必要とされるオペレータ投資を低減させる。

【0041】

加えて、このアプローチは、ＴＣＰベースのプッシュ・サービスについての他の一般的な課題に対処している。様々な実施形態においては、ワイヤレス・サービス・プロバイダによってホストされるプッシュ・サービスを有することは、モバイル・デバイスの顧客についての追跡情報に対するアクセスを獲得するサード・パーティの企業についてのプライバシーの問題を軽減する助けを行う。追跡情報は、様々な実施形態を実装するために必要であるが、ワイヤレス・サービス・プロバイダは、顧客との理解されたサービスの契約の一部分としてモバイル・デバイスを追跡して、モバイル・サービスを提供する。また、非ＴＣＰプッシュ・サーバ２０２と、非ＴＣＰプッシュ・クライアント２０８との間の非ＴＣＰ（例えば、ＵＤＰベースの）接続を使用することは、ＵＤＰが、接続のない、非持続性のプロトコルであるので、データ・トラフィック容量に関するプッシュ・サーバのスケーラビリティの課題を解決する。

【0042】

モバイル・デバイス１０２は、もはや、ハートビートの目的、またはポーリングの目的のためなど、ネットワーク・サーバに対する不必要な接続のために構成されている必要はないことになるので、それらの実施形態はまた、モバイル・バッテリ寿命を延ばすことにより、加入者に恩恵を与えることもある。さらに、それらの実施形態は、モバイル・ベンダに独立したプッシュ・サービスをホストする機会をサービス・プロバイダに提供している。これは、それらが、もはや、コンテンツをモバイル・デバイスに対して送信するためのモバイル・デバイス・ベンダまたはオペレーティング・システムに特有のメカニズムを実装する必要はないので、これは、アプリケーション・プロバイダに対して特別な魅力を有する。

【0043】

モバイル・デバイスまたはサーバによって実装されているように説明されるこれらのステップを含めて、上記で説明された方法ステップは、よく知られているコンピュータ・プロセッサと、メモリ・ユニットと、ストレージ・デバイスと、コンピュータ・ソフトウェアと、他のコンポーネントとを使用して、コンピュータの上で実装されることもある。図６は、持続性ＴＣＰ接続のないプッシュ・サービスを実装するために使用され得る例示のコンピュータの高レベル・ブロック図である。コンピュータ６００は、プロセッサ６１０を含んでおり、このプロセッサは、そのようなオペレーションを規定するコンピュータ・プログラム命令を実行することにより、コンピュータ６００の全体的なオペレーションを制御する。コンピュータ・プログラム命令は、ストレージ・デバイス６２０（例えば、磁気ディスク）に記憶され、またコンピュータ・プログラム命令の実行が望ましいときに、メモリ６３０へとロードされることもある。したがって、図３の方法のステップは、メモリ６３０および／またはストレージ６２０に記憶されるコンピュータ・プログラム命令によって規定され、またコンピュータ・プログラム命令を実行するプロセッサ６１０によって制御されることもある。コンピュータ６００は、図３の方法のステップを実施するためにネットワークを経由して他のデバイスと通信するための１つまたは複数のネットワーク・インターフェース６４０を含むことができる。コンピュータ６００は、コンピュータ６００とのユーザ相互作用を可能にする他の入出力デバイス６５０（例えば、ディスプレイ、キーボード、マウス、スピーカ、ボタンなど）を含むこともできる。当業者なら、実際のコンピュータの実装形態は、同様に他のコンポーネントを含む可能性もあること、また図６は、例証の目的のためのそのようなコンピュータのコンポーネントのうちのいくつかの高レベル表現であることを認識するであろう。

【0044】

上記の詳細な説明は、あらゆる点で、例証的であり、また例示的であるが、限定的ではないように理解されるべきであり、また本明細書において開示される本発明の範囲は、詳細な説明から決定されるべきではないが、むしろ、適用可能な特許法によって許可される全容に従って解釈されるように、特許請求の範囲から決定されるべきである。本明細書において示され、また説明される実施形態は、本発明の原理について例証しているにすぎないこと、および様々な修正形態は、本発明の範囲と趣旨とを逸脱することなく、当業者によって実施され得ることを理解すべきである。当業者なら、本発明の範囲と趣旨とを逸脱することなく、様々な他の特徴の組合せを実施することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】