特許 6138791 ステートレスアプリケーション通知

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

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

(11)【特許番号】6138791

(24)【登録日】2017年5月12日

(45)【発行日】2017年5月31日

(54)【発明の名称】ステートレスアプリケーション通知

(51)【国際特許分類】

   H04W 68/02 20090101AFI20170522BHJP

   H04L 12/701 20130101ALI20170522BHJP

【ＦＩ】

   H04W68/02

   H04L12/701

【請求項の数】9

【全頁数】22

(21)【出願番号】特願2014-528576(P2014-528576)

(86)(22)【出願日】2012年8月30日

(65)【公表番号】特表2014-528199(P2014-528199A)

(43)【公表日】2014年10月23日

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

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

(87)【国際公開日】20130307

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

(31)【優先権主張番号】13/224,217

(32)【優先日】2011年9月1日

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

【前置審査】

(73)【特許権者】

【識別番号】314015767

【氏名又は名称】マイクロソフト テクノロジー ライセンシング，エルエルシー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ジョイ，ジョージ

(72)【発明者】

【氏名】ラウ，チェク ワン ウィリアム

(72)【発明者】

【氏名】ルイ，ダレン

(72)【発明者】

【氏名】ファーステンバーグ，ヨセフ

(72)【発明者】

【氏名】チェルクリ，ラヴィカント

(72)【発明者】

【氏名】ウオレイ，ケヴィン マイケル

(72)【発明者】

【氏名】エアーズ，マシュー アール

(72)【発明者】

【氏名】アナンド，ガウラヴ エス

【審査官】 脇岡 剛

(56)【参考文献】

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

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

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

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

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

【文献】 国際公開第０２／０３３５１６（ＷＯ，Ａ１）

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

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

Ｈ０４Ｗ ６８／０２

Ｈ０４Ｌ １２／７０１

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

【請求項1】

コンピューティングデバイスに通知サービスを実施させるコンピュータプログラムであって、前記コンピューティングデバイスに、
前記通知サービスが、アプリケーションサービスとクライアントアプリケーションとの間で通知を送達する通信チャネルを、前記クライアントアプリケーションと確立するステップと、
通知サービスを通じて前記通信チャネルで、前記アプリケーションサービスが通知を宛てるのに使用可能な前記通信チャネルのための難読化ルーティングデータを生成するステップであって、前記難読化ルーティングデータは、前記アプリケーションサービスによって解釈可能でない、ステップと、
前記難読化ルーティングデータを前記アプリケーションサービスにキャッシュさせるステップと、
前記アプリケーションサービスから前記難読化ルーティングデータと共にパッケージ化された通知を取得するステップであって、前記難読化ルーティングデータは、インプロセスで前記難読化ルーティングデータから、かつ、前記通信チャネルのためにキャッシュされた状態データをルックアップせずに、前記通知サービスによって把握されることができる、前記通信チャネルの経路を符号化する、ステップと、
前記通知サービスが、前記難読化ルーティングデータを解釈して、前記通信チャネルを識別し、前記クライアントアプリケーションに前記通知を宛てるステップと
を実行させるコンピュータプログラム。

【請求項2】

前記難読化ルーティングデータは、前記通信チャネルのアドレスの抽象化として導出されたチャネルハンドルを備える、請求項１に記載のコンピュータプログラム。

【請求項3】

前記難読化ルーティングデータは、前記通知サービスによって解釈可能なルーティングデータを搬送するようにフォーマットされたトークンを備え、前記通信チャネルで前記トークンに関連づけられて送信された通知を宛てる、請求項１に記載のコンピュータプログラム。

【請求項4】

前記通知サービスはさらに、前記難読化ルーティングデータを暗号化し、デジタル署名することによって、前記通信チャネルをセキュアにするステップを含む動作を実行するように構成される、請求項１に記載のコンピュータプログラム。

【請求項5】

前記通信チャネルを確立するステップは、前記通知サービスと前記クライアントアプリケーションとの間の永続的なグローバルに一意のアドレスとしてチャネル識別子を割り当てるステップを含む、請求項１に記載のコンピュータプログラム。

【請求項6】

前記難読化ルーティングデータのフォーマットおよびコンテンツは、前記通知サービスによって制御され、前記クライアントアプリケーションと前記アプリケーションサービスの両方に分かりにくくされる、請求項１に記載のコンピュータプログラム。

【請求項7】

前記難読化ルーティングデータを生成するステップは、前記クライアントアプリケーションからの要求に応答して、クライアントでキャッシュされ、前記要求において提供された状態データに基づいて、前記通信チャネルのチャネルハンドルを構成するステップを含む、請求項１に記載のコンピュータプログラム。

【請求項8】

前記難読化ルーティングデータを解釈するステップは、
前記難読化ルーティングデータを復号するステップと、
前記復号されたルーティングデータの妥当性を検査する満了時間をチェックするステップと、
サインインするために前記アプリケーションサービスによって使用されたクレデンシャルと、前記難読化ルーティングデータ内に埋め込まれたクレデンシャルとの比較に基づいて、通知を送信するために前記アプリケーションサービスを認証するステップと、
前記復号されたルーティングデータを処理して、前記通知のための前記通信チャネルを識別するステップと
を含む、請求項１に記載のコンピュータプログラム。

【請求項9】

一以上のプロセッサと、
前記一以上のプロセッサに通知サービスを実施させるコンピュータプログラムを記憶したメモリとを含み、前記コンピュータプログラムは、前記一以上のプロセッサに、
前記通知サービスが、アプリケーションサービスとクライアントアプリケーションとの間で通知を送達する通信チャネルを、前記クライアントアプリケーションと確立するステップと、
通知サービスを通じて前記通信チャネルで、前記アプリケーションサービスが通知を宛てるのに使用可能な前記通信チャネルのための難読化ルーティングデータを生成するステップであって、前記難読化ルーティングデータは、前記アプリケーションサービスによって解釈可能でない、ステップと、
前記難読化ルーティングデータを前記アプリケーションサービスにキャッシュさせるステップと、
前記アプリケーションサービスから前記難読化ルーティングデータと共にパッケージ化された通知を取得するステップであって、前記難読化ルーティングデータは、インプロセスで前記難読化ルーティングデータから、かつ、前記通信チャネルのためにキャッシュされた状態データをルックアップせずに、前記通知サービスによって把握されることができる、前記通信チャネルの経路を符号化する、ステップと、
前記通知サービスが、前記難読化ルーティングデータを解釈して、前記通信チャネルを識別し、前記クライアントアプリケーションに前記通知を宛てるステップと
を実行させる、
システム。

【発明の詳細な説明】

【技術分野】

【0001】

一実施形態は、通知サービスに関し、より具体的にはステートレスアプリケーション通知に関する。

【背景技術】

【0002】

サービスプロバイダがクライアントにメッセージを送達するためにサーバ側で通知サービスを実現するクライアント−サーバ環境において、サービスは、第三者に代わり、通知メッセージを処理してクライアントに送達するように構成され得る。いくつかの従来のアプローチでは、メッセージングは、多数のクライアントのためにサーバ側でサービスプロバイダによって永続的に維持される、アドレス、ルーティングデータ、アカウントデータ、認証データ、および／または他の状態データといった、クライアントの状態データに基づき得る。

【0003】

しかしながら、多数のクライアントのためにそのようなクライアントの状態データを維持することは、そうでなければ他の目的のためにサービスプロバイダによって確保されることができたリソース（たとえば、メモリおよび処理容量）が状態データの格納と管理に拘束されるので、費用がかかり得る。さらに、まれに接続し得るおよび／または一度接続し得るもののその後二度と接続し直すことのないクライアントのために、サービスプロバイダで状態データを永続的に格納することは、非効率的で不経済である。加えて、集中化した格納は、ハッカーがクライアントのデータを取得する標的としてセキュリティ上のリスクであり得、通知は、集中化した単一の格納の信頼性に依存する。

【発明の概要】

【0004】

この概要は、詳細な説明において以下にさらに説明される概念の選択を単純化した形態で紹介するために提供されるものである。この概要は、本発明の主題のキーとなる特徴または不可欠な特徴を特定することを意図したものでなく、本発明の主題の範囲を限定するために使用されることを意図したものでもない。

【0005】

さまざまな実施形態は、クライアントアプリケーションに通知を提供することを第三者に可能にさせるように設計されたステートレスアプリケーション通知を提供する。少なくともいくつかの実施形態において、通知サービスは、クライアントアプリケーションのために通信チャネルを確立し、そのチャネルでアプリケーションに通知を宛てるために用いられ得る難読化ルーティングデータを生成する。いくつかの実施形態において、ルーティングデータは、チャネル経路またはアドレスの抽象化として導出されたチャネルハンドルとして構成され得る。チャネルハンドルまたは他の適切なルーティングデータはまた、暗号化されデジタル署名されたトークンとして符号化されることができるので、トークンのコンテンツとフォーマットは、第三者から分かりにくくされ、改ざんから保護される。

【0006】

何らかの形態の難読化ルーティングデータを所持するアプリケーションサービスは、データと共に通知をパッケージ化し、そのパッケージを送達のために通知サービスに送信することができる。アプリケーションサービスは、難読化ルーティングデータを理解せずに、または、チャネルに関する経路／アドレスを知らずに、難読化ルーティングデータを使用して通知をチャネルに宛てることができる。難読化ルーティングデータを生成する通知サービスは、難読化ルーティングデータを解読および解釈し、改ざんを防止するためにデータ内に含まれた署名を検査し、アプリケーションサービスに代わって適切なエンドポイントアプリケーションにチャネルで通知を送達することができる。

【0007】

同一の番号が同様の特徴を参照するために全図面にわたって使用される。

【図面の簡単な説明】

【0008】

【図1】図１は、１つ以上の実施形態に係る、本明細書に説明されるさまざまな原理が用いられ得る動作環境を示す図である。

【0009】

【図2】図２は、１つ以上の実施形態に係る、チャネルおよびチャネルハンドルを作成するための例示的なシナリオを示す図である。

【0010】

【図3】図３は、１つ以上の実施形態に係る、チャネルハンドルを用いて通知を送達するための例示的なシナリオを示す図である。

【0011】

【図4】図４は、１つ以上の実施形態に係る方法のステップを説明するフロー図である。

【0012】

【図5】図５は、１つ以上の実施形態に係る別の方法のステップを説明するフロー図である。

【0013】

【図6】図６は、１つ以上の実施形態に係る別の方法のステップを説明するフロー図である。

【0014】

【図7】図７は、１つ以上の実施形態を実現するために使用され得る例示的なシステムを示す図である。

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

【0015】

概要
クライアントアプリケーションにメッセージを提供することを第三者に可能にさせるステートレスアプリケーション通知が説明される。通信チャネルが、通知サービスとアプリケーションとの間で確立されることができる。要求に応じて通知サービスは、そのチャネルのための難読化ルーティングデータを生成することができ、難読化ルーティングデータは、チャネルハンドルまたはトークンの形態であることができる。ルーティングデータは、ルーティングデータのコンテンツとフォーマットを第三者に分かりにくくし、改ざんを防止するために、暗号化およびデジタル署名されることができる。難読化ルーティングデータを所持するアプリケーションサービスは、データと共に通知をパッケージ化し、そのパッケージを送達のために通知サービスに送信することができる。アプリケーションサービスは、難読化ルーティングデータによって符号化されたチャネルの詳細を知らずに、そのようにする。難読化ルーティングデータを生成する通知サービスは、データを解読および解釈し、アプリケーションサービスに代わって適切なエンドポイントアプリケーションにチャネルで通知を送達することができる。

【0016】

以下の説明では、「動作環境」と題するセクションが提供され、１つ以上の実施形態が用いられ得る１つの環境を説明する。これに続き、「ステートレスアプリケーション通知の例」と題するセクションが、１つ以上の実施形態に係るステートレスアプリケーション通知の例示的な詳細を説明する。次に、「例示的な方法」と題するセクションが、１つ以上の実施形態に係るステートレスアプリケーション通知のための例示的な技法を説明する。最後に、「例示的なシステム」と題するセクションが、１つ以上の実施形態を実現するために利用され得る例示的なコンピューティングシステムおよびデバイスを説明する。

【0017】

動作環境
図１は、１つ以上の実施形態に係る動作環境を、一般的に１００で示す。環境１００は、１つ以上のプロセッサ１０４と、１つ以上のコンピュータ可読媒体１０６と、コンピュータ可読媒体上に存在し、プロセッサによって実行可能な、１つ以上のアプリケーション１０８とオペレーティングシステム１１０と、を有するクライアント１０２を含む。クライアント１０２は、限定ではなく例として、デスクトップコンピュータ、ポータブルコンピュータ、タブレットまたはスレートデバイス、ハンドヘルドコンピュータ、たとえば、携帯情報端末（ＰＤＡ）、携帯電話、セットトップボックス等といった、任意の適切なコンピューティングシステムおよび／またはデバイスとして具体化され得る。クライアント１０２を含むさまざまなシステムおよび／またはデバイスを表し得るコンピューティングシステムの一例が、図７に示され、以下に説明される。

【0018】

コンピュータ可読媒体は、限定ではなく例として、コンピューティングデバイスに典型的に関連づけられる、すべての形態の揮発性および不揮発性メモリおよび／または記憶媒体を含み得る。そのような媒体は、ＲＯＭ、ＲＡＭ、フラッシュメモリ、ハードディスク、取り外し可能な媒体等を含み得る。コンピュータ可読媒体は、「コンピュータ可読記憶媒体」と「通信媒体」の両方を含むことができ、その例は、図７の例示的なコンピューティングシステムの説明中に見出され得る。

【0019】

加えて、クライアント１０２は、上述および後述されるようにステートレス通知を容易にするために用いられ得る、チャネル状態データ１１１を含む。チャネル状態データ１１１は、クライアントのアプリケーション１０８のための通知を提供するためにクライアント１０２と通知サービスとの間で確立され得る、送達経路または「チャネル」に関連する。チャネル状態データ１１１は、数例を挙げると、１つ以上のチャネルに関連する、識別子、ルーティングデータ、トークン、認証データ、および満了データを含み得る。クライアント１０２は、サーバ側でのステートレスな処理を可能にするために、それら自身のチャネル状態データ１１１をキャッシュし得る。

【0020】

図１にさらに示されるように、クライアント１０２は、上述および後述のごとく、さまざまなリソース（たとえば、コンテンツおよびサービス）を提供する１つ以上のサービスプロバイダ１１４と、インターネットのようなネットワーク１１２を介して通信可能に結合され得る。例として、クライアント１０２は、サービスプロバイダ１１４とインタラクトし、メッセージを交換して、チャネルを作成し、そのチャネルを用いて通知を取得し得る。

【0021】

サービスプロバイダ１１４は各々、１つ以上のプロセッサ１１６および１つ以上のコンピュータ可読媒体１１８を有するものとして示されている。サービスプロバイダ１１４はさらに、リソースマネジャ１２０を含むものとして示されている。リソースマネジャ１２０は、ネットワーク１１２を介して利用可能にされ得るさまざまなリソース１２２を管理するためにサービスプロバイダ１１４によって動作可能な機能を表す。たとえば、さまざまなリソース１２２は、クライアント１０２による出力のためにネットワークにわたって通信される、ウェブページまたは他のユーザインターフェースを介して提供され得る。リソースマネジャ１２０は、リソース１２２へのアクセス、リソース１２２のパフォーマンス、リソース１２２を提供するためのユーザインターフェースまたはデータの構成等を管理することができる。

【0022】

サービスプロバイダ１１４は、リソース１２２にアクセスするためにクライアント１０２がナビゲートし得る、１つ以上のウェブサーバおよび／またはサイトを提供することができる。リソース１２２は、典型的には１つ以上のプロバイダによりネットワークにわたって利用可能にされるサービスおよび／またはコンテンツの任意の適切な組み合わせを含み得る。サービスのいくつかの例は、検索サービス、ｅメールを送受信するためのｅメールサービス、クライアント１０２間でインスタントメッセージを提供するためのインスタントメッセージングサービス、および共通の関心とアクティビティを共有するユーザのグループ間の繋がりと対話を容易にするためのソーシャルネットワーキングサービスを含むが、これらに限定されない。コンテンツは、テキスト、映像、広告、音声、マルチメディアストリーム、動画、画像、ウェブページ、ウェブアプリケーション、デバイスアプリケーション、ブラウザによる表示のためのコンテンツ、または他のデバイスアプリケーション等のさまざまな組み合わせを含み得る。

【0023】

加えて、サービスプロバイダ１１４は、クライアント１０２と他のエンティティとの間の通知１２６の通信を管理するように動作可能な機能を表す、通知サービス１２４を含むことができ、またはそうでなければ利用することができる。通知サービス１２４は、単独で、および／または、他のサービスと共に、動作して、１つ以上の異なるタイプのメッセージングのための機能を提供することができる。限定ではなく例として、通知サービスによって提供される複数の異なるタイプのメッセージングは、ｅメール、テキストメッセージ、アプリケーションコンテンツにおけるアプリケーションおよび／またはオペレーティングシステム通知、ソーシャルネットワーキングの通知および招待、インスタントメッセージング、ボイスメッセージ、ピアツーピアメッセージング等を含み得る。

【0024】

通知サービス１２４はまた、本明細書に説明されるステートレスアプリケーション通知のための技法を実現するように動作可能である。特に、通知サービス１２４は、１つ以上のアプリケーションサービス１２８に代わってクライアント１０２への通知１２６の通信を容易にするために実現され得る。通知１２６は、宣伝、アプリケーションのアップデート、警告、アプリ内のフィーチャー等といった、アプリケーションサービスに対応するアプリケーション１０８に宛てられたメッセージとして構成されることができる。通知サービス１２４は、クライアント１０２への通知１２６のルーティングおよび送達を担う。クライアント１０２によってキャッシュされたチャネル状態データ１１１は、必要に応じて通知サービス１２４によりオンデマンドで取得されることができる。しかしながら、通知サービス１２４は、通知要求を備えた難読化ルーティングデータを使用して、サーバ側でチャネルおよび通知のための「ステートレス」な処理を実行することができる。通知サービス１２４は、クライアントが現在接続中である場合、クライアントに関する状態情報を一時的に格納することができる。状態データは、現在接続中のクライアントの識別情報、どの種類／タイプの通知が許可されるかまたはブロックされるかについての情報等を含み得る。しかしながら、クライアントが接続を切ると、一時的な状態データは通知サービス１２４によって破棄されることができるので、処理は「ステートレス」であると考えられる。

【0025】

以下においてより詳細に説明するように、通知１２６は、クライアント１０２とサービスプロバイダ１１４との間で確立されたチャネルで送達されることができる。通知は、通知サービス１２４を通じて提供されるチャネルハンドルまたはトークンといった難読化ルーティングデータと通知とを関連づけることにより、チャネルを介して送信されることができる。チャネルを介して通知を提供する１つの例示的なアプローチにおいて、通知サービス１２４は、チャネルメタデータ１３２を搬送するように構成されたトークン１３０を用い得る。チャネルメタデータ１３２は、要求の処理、チャネルの確立、通知のルーティング等のために、通知サービス１２４によって「インプロセス」で使用されるデータを表し得る。これは、クライアント１０２から必要に応じて取得される、さまざまなチャネル状態データ１１１を含み得る。しかしながら、通知サービス１２４が必ずしもクライアント１０２に代わってチャネルメタデータ１３２をキャッシュするわけではない。

【0026】

チャネルに関連するさまざまなデータが、チャネルＩＤ、チャネルハンドル、およびルーティングデータを含む、チャネルメタデータ１３２の一部として含まれ得る。チャネルＩＤは、チャネルを一意に識別し、チャネルＩＤが第三者にさらされないように維持される。しかしながら、第三者は、チャネルのために生成され、トークンで提供されたチャネルハンドルを用いることができ、またはそうでなければ、ハンドルを解釈せずに、または対応するチャネルＩＤを知らずに、エンドポイントに通知サービス１２４を通じてメッセージを宛てることができる。特に、チャネルハンドルは、チャネルの特性を分かりにくくするためにチャネルＩＤの抽象化として導出され得る。チャネル、チャネルハンドル、およびステートレスアプリケーション通知のこれらの態様および他の態様についての詳細が、以下の図面に関連して提供される。

【0027】

例示的な動作環境が説明されたので、ここでは、１つ以上の実施形態に係るいくつかのステートレスアプリケーション通知の例の説明を考慮する。

【0028】

ステートレスアプリケーション通知の例
このセクションは、１つ以上の実施形態に係るステートレスアプリケーション通知についての例示的な詳細を説明する。以下の説明ではまず、「通知送達のためのチャネル」と題するサブセクションが、アプリケーション通知を容易にするために確立され得るチャネルを説明する。次に、「ステートレストークン」と題するサブセクションが、チャネルを使用して適切なエンドポイントに通知をルーティングするために使用されるルーティングデータを搬送するためにいくつかの実施形態において用いられ得る、トークンについての詳細を提供する。以下において、ステートレスアプリケーション通知を実現するための、サービスプロバイダ１１４、クライアント１０２、およびアプリケーションサービス１２８間の例示的なインタラクションが、図２および図３に示す例示的な動作シナリオに関連して説明される。

【0029】

通知送達のためのチャネル
上で紹介したように、通知は、クライアント１０２とサービスプロバイダ１１４との間で確立されたチャネルで送達されることができる。一般的に、チャネルは、アプリケーションサービス１２８から特定のエンドポイントまでの通知の送達経路の表現（たとえば、アドレス）である。本明細書において使用されるエンドポイントは、特定のユーザ、デバイス、および／またはアプリケーションの一意の組み合わせに対応する。すなわち、チャネルは、特定のクライアント１０２にインストールされ、クライアント１０２の特定のユーザによって使用される、特定のアプリケーション１０８のために確立され関連づけられた通信経路と考えられ得る。チャネルは、グローバルに一意のアドレスがエンドポイントアプリケーションに割り当てられ得る、メカニズムである。

【0030】

各チャネルは、対応するチャネル識別子（ＩＤ）を有し得る。チャネルＩＤは、対応するエンドポイントまでの送達経路を一意に識別する永続的な識別子である。チャネルをセキュアにし、アタッカーがチャネルをハイジャックまたは誤用することを防止するために、チャネルＩＤは分かりにくい状態で保持され得る。少なくともいくつかの実施形態において、チャネルＩＤは、クライアント１０２によってセキュアに維持され、第三者にさらされない。たとえば、１つ以上のアプリケーション１０８のためのチャネルＩＤは、オペレーティングシステム１１０の内部のパラメータ／オブジェクトとして構成されることができる。オペレーティングシステム１１０は、通知サービス１２８とのインタラクションにおいてチャネルＩＤを利用することができるが、そうでなければチャネルＩＤを非公開の状態で保持する。

【0031】

したがって、チャネルでの通知を可能にするために、チャネルＩＤそのものをさらすおよび／または使用する代わりに第三者に発行されることができるチャネルハンドルが作成される。たとえば、アプリケーションのインストールまたは実行時に、アプリケーションのために通知がアクティブにされた場合、アプリケーションに固有のコンテンツをアップデートするために使用され得るチャネルが確立されることができる。１つのアプローチにおいて、アプリケーションは、オペレーティングシステム１０８を通じてチャネルハンドルの発行を要求することができる。たとえば、要求は、ローカルアプリケーションプログラミングインターフェース（ＡＰＩ）を通じて行われ得る。オペレーティングシステムが次に、通知サービス１２４とインタラクトして、通知サービス１２４にチャネルハンドルを発行させ、チャネルハンドルをアプリケーション１０８に返送させる。通知サービス１２４はまた、既存のチャネルがない場合、新たなチャネルを確立することができる。アプリケーション１０８は次に、アプリケーションサービス１２８にチャネルハンドルを供給して、アプリケーションサービス１２８からの対応する通知を可能にすることができる。

【0032】

より具体的には、チャネルハンドルが、アプリケーションおよび第三者への供給のために、チャネルＩＤの抽象化として導出されることができる。チャネルハンドルは、クライアントからの要求に応答して通知サービス１２４によって構成されることができる。クライアントからの要求は、対応するチャネルハンドルを作成するために通知サービス１２４によって使用される、チャネルＩＤおよび他のクライアント状態データ１１１を含むように構成され得る。ハンドルは、チャネルの特性を難読化させ、ハンドルの変更を防止するために暗号化されることができる。デジタル署名が、変更または改ざんを防止するために使用されることもできる。通知サービス１２４は、チャネルハンドルの作成を担い、また、チャネルハンドルのフォーマットおよびコンテンツを制御する。したがって、ハンドルのフォーマットおよびコンテンツは、クライアント１０２および／または第三者アプリケーションサービス１２８の両方に分かりにくくされることができる。このように、チャネルハンドルは、ハンドルが通知サービス１２４には解釈可能で他の当事者には解釈可能でないように、構成されることができる。

【0033】

チャネルハンドルは、任意の適切な手法でフォーマットされることができる。一般的に、チャネルハンドルは、エンドポイントアプリケーションまでの経路またはアドレスを表現するように構成される。このように、チャネルハンドルは、チャネルのためのさまざまなルーティングデータを符号化することができる。限定ではなく例として、通知サービス１２４は、特定のアプリケーション、クライアントデバイス、およびクライアントデバイスのユーザのための識別子の組み合わせを符号化するユニフォーム・リソース・アイデンティファイア（ＵＲＩ）として、チャネルハンドルを作成することができる。より一般的には、チャネルハンドルは、通知を識別し、対応するエンドポイントにルーティングするのに十分な、ルーティングデータの任意の組み合わせを表現し得る。ハンドルは、基礎をなすチャネルＩＤに基づいて作成されることができるので、通知サービス１２４は、ハンドルを解釈し、送信された通知をそのハンドルを使用して適切なチャネルで対応するエンドポイントに送達することができる。

【0034】

複数のチャネルハンドルが特定のチャネルＩＤのために発行されることができる。したがって、満了したまたは危殆化されたチャネルハンドルは、基礎をなすチャネルＩＤに影響せずに無効化され得る。チャネルハンドルはまた、チャネルハンドルを満了時間に関連づけることによって、限られた生存期間を有するように構成されることができる。満了時間の後、チャネルハンドルはもはや通知を送達するために使用されることはできない。しかしながら、アプリケーションは、同一のチャネルで新たなチャネルハンドルの発行を要求することができる。チャネルハンドルはまた、通知の送達を絶え間なくチャネルに提供するために、満了に先立って更新されることができる。チャネルハンドルが更新された場合、通知サービス１２４は、同一のチャネルで以前のハンドルの置き換えとして使用され得る新たなハンドルを提供する。複数のチャネルハンドルが同一の時間に、あるチャネルのためにアクティブであることができる。ハンドルの更新についてのさらなる詳細は、以下の例示的な方法に関連して説明される。

【0035】

チャネルそのものは、無期限に開かれたままであり得、多くのチャネルハンドルが、チャネルの生存期間にわたってチャネルに割り当てられることができる。チャネルは明示的に閉じられ得、その時点で、閉じられたチャネルに関連づけられたいずれのチャネルハンドルも、もはや通知を送信するために使用可能ではないだろう。クライアント１０２によって維持されたデータは、そのようなチャネルの閉鎖を制御する。チャネルの閉鎖は、クライアント１０２からチャネルＩＤを永久的に取り去る問題であるので、そのチャネルＩＤに関連づけられたハンドルの使用はいずれも、チャネルＩＤがもはや存在しないのでクライアント１０２によって拒絶されるだろう。そして、新たなチャネルＩＤが、特定のアプリケーション１０８のために確立された新たなチャネルを表現するために発行されるだろう。それに応じて、永続的なチャネルが確立されることができ、それに基づいて、複数の限られた使用チャネルハンドルが、チャネルを攻撃またはそうでなければ危殆化から保護しながらチャネルを介した通信を可能にするために発行されることができる。

【0036】

ステートレストークン
説明したように、クライアント１０２によってキャッシュされたチャネル状態データ１１１は、チャネルを使用した通知サービス１２４によるステートレスな通知の送達を可能にすることができる。クライアントに代わって状態データを格納するのではなく、通知サービス１２４は、必要に応じて、クライアント１０２からチャネル状態データ１１１を「ルックアップする」かまたはそうでなければ提供されることが可能である。したがって、サービスプロバイダ１１４は、状態データを格納することに関連づけられたコストを回避することができる。したがって、クライアント１０２は、それら独自のチャネル状態データ１１１の一部または全部をキャッシュし、必要に応じてサービスプロバイダ１１４にデータを提供するように構成されることができる。クライアントからまたは別の手法で取得されたチャネルに関連するデータは、図１においてチャネルメタデータ１３２として表される。

【0037】

動作中、トークン１３０は、通知サービス１２４を通じて暗号化およびデジタル署名されたチャネルメタデータ１３２を受け渡すために使用されることができる。トークン１３０を生成するために使用されるチャネルメタデータ１３２は、必要に応じて通知サービス１２４によりクライアント１０２から取得され、サービスプロバイダ１１４によって実際に永続的に格納され得ない、「インプロセス」データであり得るので、トークン１３０は、ステートレスであると考えられ得る。

【0038】

トークン１３０は、さまざまな手法で構成されることができる。一般的に、トークン１３０は、通知サービス１２４によって解釈可能な特定のフォーマットで構成されたルーティングデータを含み、トークンを使用した通知を対応するエンドポイントにルーティングするために使用され得る。例として、トークン１３０は、ペイロードとして選択チャネルメタデータ１３２と共にパッケージ化されたＢＬＯＢ（バイナリ・ラージ・オブジェクト）として構成されることができる。さまざまな他のトークンの構成もまた意図される。たとえば、トークン１３０は、ＵＲＩまたは他の適切なチャネルハンドルを含むように構成されることができる。トークン１３０はまた、バージョンデータ、認証データ、満了時間、および／または、トークンの妥当性を制御および検査するために使用される他のセキュリティ情報といった、セキュリティ情報を含むように構成されることができる。セキュリティ情報は、異なるトークンのバージョンのための異なる秘密鍵および／または異なるフォーマットの使用を可能にする。さらに、トークンは、改ざんを防止するために暗号化および／またはデジタル署名されることができる。いくつかの実施形態において、通知サービス１２４は単独で、トークン１３０を解読および解釈し、それに応じて、トークンに含まれたチャネルメタデータ１３２（たとえば、チャネルハンドルまたは他のルーティングデータ）によって特定されたエンドポイントに通知をルーティングすることが可能である。

【0039】

いくつかの実施形態において、トークン１３０内で暗号化されたチャネルメタデータ１３２は、直接的にルーティングデータを含むことができる。このルーティングデータは、トークン１３０において受け渡される自己完結型の情報を使用して、メッセージをステートレスに処理してエンドポイントにルーティングすることを、通知サービス１２４に可能にさせる。ルーティングデータは例として、バージョンデータ、チャネルハンドル、対応するアプリケーション１０８、クライアント１０２、および／または機械のための識別子、デジタル証明書、暗号のために使用される公開鍵等を含み得る。通知サービス１２４はトークンを発行するので、通知サービス１２４は、トークンを使用して送信されたメッセージを解釈し、（たとえば、秘密鍵を使用して）トークン１３０を解読してチャネルメタデータ１３２を取得し、トークンに含まれたルーティングデータを検査し、適切なチャネルに通知をルーティングすることが可能である。

【0040】

いくつかのケースにおいて、通知のルーティングは、チャネルハンドルおよび／またはトークン１３０内に含まれる他の適切なルーティングデータそのものを使用して、「インプロセス」で行われることができる。加えて、またはあるいは、通知サービス１２４は、トークンに含まれる情報に基づいて、適切なエンドポイントを「ルックアップ」することができる。たとえば、通知サービス１２４は、トークンにおいて提供されたチャネルハンドルをチャネルＩＤと突き合わせ、メッセージを対応するエンドポイントにルーティングすることができる。このように、上述したトークン１３０は、通知サービス１２４がアプリケーションサービス１２８に代わってアプリケーション１０８に対しステートレスに通知を送達することができる、１つの例示的なメカニズムを提供する。

【0041】

チャネルおよびステートレストークンの上記説明のコンテキストで、図２および図３に示したいくつかの例示的な動作シナリオをここで考慮する。特に、図２は、ステートレスアプリケーション通知のためにチャネルハンドルを提供するトランザクションの例示的なシーケンスを示す図２００を示す。図３は、チャネルハンドルを用いて通知サービス１２４を通じて通知を送達することに含まれるトランザクションの例示的なシーケンスを示す図３００を示す。

【0042】

図２の例を参照すると、例示的なシナリオ２００は、チャネルおよびチャネルハンドルの作成に含まれる動作を示す。２０２で、アプリケーション１０８は、チャネル要求を開始し得る。たとえば、アプリケーションは、アプリケーションがインストールまたは実行された場合、ユーザが通知をアクティブにした場合、またはそうでなければ、通知を取得するためにアクティブになると、要求を開始し得る。要求によって、コンピューティングデバイス１０２による処理は、通知を可能にするためにアプリケーション１０８によって使用され得るチャネルデータを有する適切な応答を提供することになる。いくつかの実施形態において、チャネル要求および応答は、オペレーティングシステム１１０によって提供されるローカルアプリケーションプログラミングインターフェース（ＡＰＩ）によって処理されることができる。

【0043】

要求に応答して、２０４で、オペレーティングシステム１１０は、アプリケーションのための既存のチャネルＩＤをルックアップし得る。チャネルが存在する場合には、既存のチャネルＩＤが要求と共に提供され得る。オペレーティングシステム１１０はまた、新たなチャネルハンドルの作成を要求するか否か、または、既存のチャネルハンドルを使用するか否かを、ポリシーに基づいて決定することができる。既存のチャネルがない場合、新たなチャネルを作成する要求が行われ得る。

【0044】

２０６で、オペレーティングシステム１１０は、チャネル作成メッセージ中にアプリケーションに固有の情報および／またはチャネルＩＤをパッケージ化し、チャネル作成メッセージを通知サービス１２４に送信する。アプリケーション情報は、前述のごとく、チャネルハンドルを作成し、および／または、トークン１３０を発行するために、通知サービス１２４によって使用され得る、ルーティングデータおよび／または他のチャネル状態データ１１１を含み得る。

【0045】

２０８で、通知サービス１２４は、適切な場合、チャネル要求に応答して、要求されたチャネルを作成し得る。加えて、またはあるいは、通知サービス１２４は、チャネルのために新たなチャネルハンドルを作成し得る。いくつかの実施形態において、通知サービス１２４は、要求におけるチャネルＩＤによって示されたチャネルに通知を宛てるのに十分な、または、新たに作成されたチャネルのための、チャネルハンドルおよび／またはルーティングデータを含むように、上述したトークン１３０を形成する。トークン１３０は、通知サービス１２４によって暗号化およびデジタル署名されることができる。

【0046】

２１０で、通知サービス１２４は、クライアント１０２のオペレーティングシステム１１０にチャネルデータを返送する。返送されるチャネルデータは、チャネルハンドル、トークンが用いられる場合にはトークン、難読化ルーティングデータ、および／または、適切な場合には新たなチャネルＩＤを含み得る。返送されるチャネルデータは、通知をルーティングするための情報を含むので、通知サービス１２４は、クライアントに代わってデータをキャッシュせずに、要求および対応する情報を破棄することができる。引き続いて起こるチャネルハンドルおよび／またはトークンの処理は、通知メッセージで提供し返されたチャネルデータを使用してステートレスに行われることができる。一般的に、この処理は、提供されたチャネルデータを使用し、チャネルのための追加の状態データをルックアップせずに、「インプロセス」で行われる。しかしながら、通知サービス１２４は、いくつかのシナリオにおいて、追加のチャネル状態データ１１１をルックアップするか、またはクライアントに要求し得る。

【0047】

２１２で、オペレーティングシステム１１０は、返送されたチャネルデータをキャッシュする。これは、チャネルＩＤとアプリケーションエンドポイントとの間のマッピングを作成することを含み得る。説明したように、チャネルＩＤとマッピングは、オペレーティングシステム１１０により非公開の状態で保持され得る。したがって、オペレーティングシステム１１０は、チャネルＩＤを抽出し、チャネルＩＤとマッピングを秘密の状態で保持することができる。しかしながら、２１４で、他のチャネルデータは、通知を容易にするためにアプリケーション１０８に提供され返され得る。これは、チャネルハンドル、ハンドルを有するトークン、および／またはチャネルに関連する他のチャネルデータを、アプリケーション１０８に提供し返すことを含み得る。

【0048】

チャネルでの通知を可能にするために、２１６で、アプリケーション１０８は、適切なチャネルデータを対応するアプリケーションサービス１２８に提供する。再びこれは、アプリケーションにメッセージをルーティングし返すためにアプリケーションサービス１２８によって用いられ得る、チャネルハンドル、トークン、および／または他のチャネルデータを含み得る。２１８で、アプリケーションサービスは、引き続いて起こる使用のためにチャネルデータを格納して、アプリケーションに通知を送達し返すことができる。

【0049】

アプリケーション１０８、オペレーティングシステム１１０、およびアプリケーションサービス１２８はいずれも、通知のために使用されるハンドルまたはトークンのフォーマットおよびコンテンツを知り得ない、ということに再度注意するべきである。アプリケーション１０８、オペレーティングシステム１１０、およびアプリケーションサービス１２８は、ハンドルまたはトークンを解釈し、解読し、またはそうでなければ処理するように構成されないことができる。むしろ、アプリケーション１０８およびアプリケーションサービス１２８は、所与のハンドルおよび／またはトークンが使用されて、通知が通知サービス１２４を通じて対応するエンドポイントに送達され得ることを理解するように構成される。１つのアプローチにおいて、通知は、アプリケーションサービス１２８によりハンドル／トークンにペイロードとして添付され、通知をルーティングおよび送達するための処理を実行する通知サービス１２４に通信される。ハンドル／トークンを使用して通知を送達することに関する詳細が、図３に関連してすぐ下に説明される。

【0050】

特に、図３は、通知サービス１２４を通じて通知を送達するためにチャネルハンドルを用いるための１つの例示的なシナリオ３００を示す。チャネルハンドルは、個々に提供され得るか、またはトークン１３０内に含まれ得る。いずれのケースにおいても、チャネルハンドルは、暗号化されることおよび／またはデジタル署名されることによって保護される。この例において、チャネルハンドルは、通知サービスによって解釈され、正しいエンドポイントに通知を送達するために使用され得る、符号化されたルーティングデータを表す。そのようなルーティングデータは、前述したように、暗号化され署名されたトークン内に含まれ得る。

【0051】

アプリケーションサービス１２８は、特定のアプリケーションに関連する通知を生成し得る。通知は、アプリケーションコンテンツにおけるアプリケーションのアップデート、宣伝または特別なオファー、警告等を提供するように構成され得る。通知は、特定のアプリケーションを有する任意のエンドポイントに宛てられたグローバルなメッセージ、または、デバイスのタイプ、ユーザの基準、プラットフォーム等の選択基準に基づいて１つ以上の特定のエンドポイントをターゲットとしたメッセージ、であることができる。

【0052】

３０２で、アプリケーションサービスは、通知のためにチャネルハンドルをルックアップする。たとえば、アプリケーションサービス１２８は、特定のアプリケーション（または選択基準）を有し通知がアクティブにされた１つ以上のエンドポイントのためのチャネルハンドルをキャッシュすることができる。したがって、アプリケーションサービス１２８は、通知を適切なチャネルハンドルと突き合わせるために、キャッシュされたデータを参照し得る。

【0053】

３０４で、通知が通知サービス１２４に送信される。通知は、チャネルハンドルにペイロードとして添付されることができる。複数のエンドポイントへの送達のケースでは、通知は、エンドポイントに対応する複数のチャネルハンドルに関連づけられることができる。

【0054】

３０６で、通知サービス１２４は、通知を処理し、それは、チャネルハンドルを解読すること、およびチャネルハンドルの妥当性を検査することを含み得る。たとえば、通知サービス１２４は、解読鍵を使用して、チャネルハンドルおよび／またはチャネルハンドルを含むトークン１３０を解読することができる。これは、通知サービス１２４に、通知を送達するのに十分な符号化されたルーティングデータを取得することを可能にさせる。通知サービス１２４はまた、チャネルハンドルが満了していないかどうか、または無効になっていないかどうか、対応するチャネルが未だアクティブであるかどうか、を確認するためにチェックし得る。

【0055】

さらに、通知サービス１２４は、通知を許可する前に、所定のクレデンシャル（たとえば、秘密鍵、パスワード／ＩＤ、または共有された他の秘密）を用いてサインインするようアプリケーションサービス１２８に要求することにより、アプリケーションサービス１２８を認証することができる。所定のクレデンシャルは、アプリケーションサービス１２８によって提供されたチャネルハンドル内に含まれるクレデンシャルと突き合わせられ得る。比較が行われ、クレデンシャルが一致しない場合、通知の送達は拒絶され得る。クレデンシャルの比較を可能にするために、チャネルハンドルは、ハンドルが作成されるときに、認証のための特定の同一性に結び付けられることができる。これは、ハンドルが作成されるときに、ハンドル中に、オペレーティングシステム１１０または別の手法によってクライアント１０２から提供されたクレデンシャルを、通知サービス１２４が埋め込むことによって達成されることができる。

【0056】

チャネルハンドルが妥当であると仮定すると、通知サービス１２４は、チャネルハンドルを解釈して、どこに通知を送信するかを決定する。特に、３０８で、通知サービス１２４は、チャネルハンドルを使用して、クライアントエンドポイントおよび対応するチャネルＩＤを決定する。たとえば、チャネルハンドルは、チャネルＩＤを再構成するために通知サービス１２４によって処理されることができる。別のアプローチでは、チャネルハンドルは、対応するチャネルＩＤをルックアップするために参照として使用されることができる。トークンのケースでは、トークン内に符号化されたルーティングデータは、トークンが解読および検査された後に通知を直接ルーティングするのに十分であり得る。

【0057】

いずれのケースにおいても、通知サービス１２４は、どこに通知を送信するかを識別し、３１０で、クライアント１０２に通知を通信する。たとえば、通信は、チャネルＩＤを参照してクライアント１０２のオペレーティングシステム１０８に宛てられることができる。３１２で、オペレーティングシステム１０８は、通知が宛てられたアプリケーション１０８をチャネルＩＤに基づいて把握するための処理を実行する。これが行われ得る１つの手法は、オペレーティングシステム１０８のローカルＡＰＩによるものである。適切なアプリケーション１０８が識別されると、通知が、３１４でアプリケーション１０８に送達される。アプリケーション１０８は、通知を処理し、それに応じて通知によって命令された任意の対応する動作を実行することができる。たとえば、アプリケーション１０８は、ユーザインターフェース内で見るために通知を提示し、アップデートを実行またはスケジューリングし、通知に関する警告および／または視覚的なインジケータを提供し、通知を格納し得る、といった具合である。

【0058】

ステートレスアプリケーション通知のいくつかの例を考慮したので、ここでは、１つ以上の実施形態に係るステートレスアプリケーション通知のための例示的な手順を考慮する。

【0059】

例示的な方法
図４は、１つ以上の実施形態に係る方法のステップを説明するフロー図である。方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせに関連して実現されることができる。少なくともいくつかの実施形態において、方法は、通知サービス１２４を含む、またはそうでなければ利用する、図１の例示的なサービスプロバイダ１１４のような、適切に構成されたコンピューティングデバイスによって実現されることができる。

【0060】

ステップ４００は、チャネルに関連づけられたトークンについてクライアントから要求を取得する。たとえば、通知を受信するためにアプリケーションがアクティブになると、アプリケーションは、前述のごとくチャネル要求を送信し得る。要求は、クライアント１０２の特定のアプリケーションのためのトークンを作成するために使用され得るクライアント状態データ１１１を含み得る。通知サービス１２４は、チャネル、および／または、既存のチャネルにアクセスするために使用され得る難読化ルーティングデータ、を作成するための要求を受信および処理することができる。

【0061】

特に、ステップ４０２は、クライアントのためのルーティングデータを含むトークンを生成する。ルーティングデータは、チャネルハンドル、または、チャネルの詳細を符号化するクライアント状態データ１１１の他の組み合わせの形態、であることができる。有効に、ルーティングデータは、通知１２６をルーティングするために通知サービス１２４によって後に回復され得るチャネルに関する送達経路またはアドレスを符号化する。ルーティングデータは、通知サービス１２４によって生成されたトークンの一部として提供されることができる。トークンは、要求において提供されたクライアント状態データ１１１を使用して、ステートレスに作成され、用いられることができる。トークンは、表、データベース、または外部のソースからデータをルックアップせずに、トークンのみに基づいて、「インプロセス」で、チャネルに関する経路またはアドレスを後に決定することを、通知サービス１２４に可能にさせるのに十分な、ルーティングデータを含むように構成されることができる。トークンはまた、満了時間、セキュリティデータ、および他のメタデータを含み得る。

【0062】

ステップ４０４は、トークンを解読し、トークンに署名する。これは、トークンを保護し、ルーティングデータを第三者から難読化させる。ステップ４０６は、通知のためにチャネルを用いることをクライアントに可能にさせるためにクライアントにトークンを返送する。トークンは、オペレーティングシステム１１０を通じてアプリケーション１０８に提供されることができ、アプリケーション１０８が次に、アプリケーションサービス１２８による使用のためにトークンを供給することができる。

【0063】

ステップ４０８は、トークンを使用するクライアントへの送達のための通知を取得する。たとえば、通知サービス１２４は、パケット化されたまたはそうでなければトークンに関連づけられた通知を、アプリケーションサービス１２８から取得することができる。

【0064】

ステップ４１０は、トークンを解読して、ルーティングデータを取り出し、ルーティングデータの妥当性を検査する。通知サービス１２４はトークンを発行し、トークンのセキュリティを制御するので、通知サービス１２４は、トークンを解読および解釈することが可能である。通知サービス１２４はまた、満了時間をチェックすること、チャネルがアクティブであるかどうかを確認すること、通知がチャネルのために可能にされていると確認すること、およびそうでなければさまざまなセキュリティ情報をチェックすること、によって、ルーティングデータの妥当性を検査することができる。

【0065】

ルーティングデータまたはトークンに伴う問題が発見されると、エラーハンドリング処理が開始されることができる。エラーメッセージが通知の送信元に送り返されることができ、トークンの再発行、クライアントへのエラー通知の送信、チャネルのロック、送信元の認証解除等といった、他の訂正動作が実行されることができる。そうでなければ、ルーティングデータが妥当である場合、通知サービスは、解読されたルーティングデータを処理して、チャネルＩＤを再構成することができ、またはそうでなければ、ルーティングデータによって記述されたチャネルを識別することができる。そして、ステップ４１２は、トークンから取り出されたルーティングデータに基づいてクライアントに通知を送達する。

【0066】

図５は、１つ以上の実施形態に係る別の方法のステップを説明するフロー図である。方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせに関連して実現されることができる。少なくともいくつかの実施形態において、方法は、図１の例示的なクライアント１０２のような、適切に構成されたコンピューティングデバイスによって実現されることができる。たとえば、方法は、ステートレスアプリケーション通知のためのクライアント側の技法を可能にするように適応したオペレーティングシステム１０８のローカルアプリケーションプログラミングインターフェース（ＡＰＩ）によって実現されることができる。

【0067】

ステップ５００は、通知サービスにチャネルのためのチャネルハンドルを要求する。特定のチャネルのためのチャネルハンドルが、さまざまな時間にアプリケーションのために要求され得る。これは、アプリケーションが最初にインストールされたときに、アプリケーションの実行時に、または通知がユーザまたは別の手法によってアクティブにされたときに、行われることができる。オペレーティングシステム１１０は、前述のごとくＡＰＩを通じてアプリケーション要求を処理することができる。

【0068】

アプリケーションが、チャネルハンドルを取得するためにオペレーティングシステム１０８を呼び出すと、オペレーティングシステム１０８は、以前にキャッシュされたハンドル（利用可能な場合）を提供すべきか、新たなハンドルを要求すべきかを、ポリシーに基づいて決定することができる。新たなハンドルは、たとえば、既存のハンドルが存在しない場合、キャッシュされたハンドルが満了している場合、新たなチャネルを取得することが適切である場合等に要求されることができる。

【0069】

新たなハンドルは、ハンドルが満了する前にハンドルを更新するために要求されることができる。これは、たとえば、更新されたハンドル（またはトークン）を取得するタイミングを規定するポリシーに基づいて行われ得る。更新のために、ハンドルは、以前から存在するチャネルで要求される。新たなハンドルは、以前から存在するチャネルのために発行されることができる。説明したように、複数のハンドルが同一の時間に、あるチャネルのためにアクティブであることができる。したがって、チャネルのために以前に作成されたハンドルは、そのハンドルが満了しない限り、無効にならない限り、またはそうでなければ非アクティブにされない限り、更新後に使用され続けることができる。しかしながら、更新後、アプリケーションは、引き続き起こる通知による使用のために最新のハンドルを供給することができる。

【0070】

更新はまた、個々にまたはグループとしてアプリケーションサービス１２８によって維持されたハンドルまたはトークンを更新するためにアプリケーションサービス１２８によって開始されることができる、ということに注意すべきである。これは、通知の継続性を保証するためにチャネルのためのルーティングデータを定期的にリフレッシュすることをアプリケーションサービス１２８に可能にさせる。更新は、通知サービス１２４を通じて行われ、更新されたデータが、要求するアプリケーションサービス１２８に通信し返され得る。通知サービス１２４はまた、更新されたハンドルまたはトークンを適切なクライアント１０２に提供することができる。

【0071】

ステップ５０２は、チャネルを難読化させるチャネルハンドルを含む応答を取得する。たとえば、通知サービス１２４は、要求されたチャネルハンドルをクライアント１０２に返送し返すことができる。チャネルハンドルは、通知サービス１２４によって解釈され得る難読化ルーティングデータを組み込むことができる。加えて、チャネルＩＤが応答と共に含まれ得る。クライアント１０２は、返送されたデータ（たとえば、ハンドル、トークン、ルーティングデータ、チャネルＩＤ）を、引き続いて起こる使用のためにキャッシュすることができる。

【0072】

ステップ５０４は、アプリケーションサービスからの通知のアクティブ化を可能にするためにアプリケーションにチャネルハンドルを提供する。キャッシュされたチャネルハンドルまたは新たに作成されたハンドルが、要求に応じてアプリケーションに提供されることができる。アプリケーションは次に、チャネルハンドルを対応するアプリケーションサービス１２８に通信して、通知をアクティブにすることができる。チャネルハンドルを所持するアプリケーションサービス１２８は、上述および後述するように、チャネルハンドルによって符号化された難読化ルーティングデータを実際に理解せずに、通知サービス１２４を通じて、対応するチャネルに通知を宛てることができる。

【0073】

ステップ５０６は、チャネルハンドルを使用して通知サービスを通じてチャネルに送信された通知を受信する。通知は、通知サービスからクライアント１０２へと通信されることができる。通知は、本明細書に説明されるように、オペレーティングシステム１０８および／またはローカルＡＰＩによって受信および処理されることができる。特に、通知サービス１２４は、チャネルハンドルを使用してアプリケーションサービス１２８に代わって通知を解釈およびルーティングする。したがって、クライアント１０２は、クライアント１０２のために確立されたそれぞれのチャネルで通知サービス１２４を通じてさまざまな通知を受信することができる。通知は、前述のごとくさまざまな手法で、クライアント１０２で、処理され、格納され、および／または出力されることができる。

【0074】

図６は、１つ以上の実施形態に係る方法のステップを説明するフロー図である。方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせに関連して実現されることができる。少なくともいくつかの実施形態において、方法は、図１の例示的なアプリケーションサービス１２８を提供するように構成された１つ以上のサーバといった、適切に構成されたコンピューティングデバイスによって実現されることができる。

【0075】

ステップ６００は、難読化ルーティングデータをクライアントから受信して、クライアントの対応するアプリケーションへの通知をアクティブにする。たとえば、アプリケーションサービス１２８は、アプリケーション１０８から、チャネルハンドル、トークン、または他の難読化ルーティングデータを取得し、格納することができる。難読化ルーティングデータは、対応するチャネルによってアプリケーション１０８に通知を送信することをサービスに可能にさせる。チャネルそのものは、本明細書に説明される手法でアプリケーションサービス１２８に分かりにくくされ得る。

【0076】

ステップ６０２は、アプリケーションへの送達のための通知を生成する。通知は、特定のアプリケーションへの送達のためのメッセージとして構成され得る。通知は、アプリケーションのコンテンツにおけるプログラムのアップデート、宣伝、警告、リンク、報酬、達成メッセージ等を含み得る。

【0077】

ステップ６０４は、難読化ルーティングデータと共に通知をパッケージ化する。特に、アプリケーションサービス１２８は、通知を含むパッケージを作成することができ、このパッケージは、難読化ルーティングデータをそのパッケージ中に含むことによってチャネルに宛てられる。たとえば、アプリケーションのアップデートは、チャネルＵＲＩ、ハンドル、トークン、またはチャネルのために発行された他のルーティングデータと共にパッケージ化されることができる。通知は、パッケージ中に含まれた難読化ルーティングデータによって表される送達命令に添付された、またはそうでなければ関連づけられた、ペイロードと考えられることができる。

【0078】

ステップ６０６は、難読化ルーティングデータと共に通知を通信して、通知サービスに、難読化ルーティングデータによって指定されたアプリケーションに通知を送達させる。アプリケーションサービス１２８は、ルーティングデータの詳細またはルーティングデータ中に符号化されたエンドポイントの実際のアドレスを必ずしも知らずに、難読化ルーティングデータを使用してエンドポイントにメッセージを宛てることができる、ということに再度注意すべきである。難読化ルーティングデータを伴う通知のパッケージは、通知サービス１２４によって提供されるサービスを利用するためにアプリケーションサービス１２８によって構成される。通知サービス１２４は、難読化ルーティングデータを解読し、それに応じて通知を送達することを担う。したがって、アプリケーションサービス１２８は、通知を宛てるために、単にさまざまな形態の難読化ルーティングデータを利用するだけでよく、正しいエンドポイントを識別し、通知をルーティングするための処理を、通知サービス１２４に引き継ぐ。

【0079】

ステートレスアプリケーション通知のためのさまざまな例示的な方法を考慮したので、ここでは、１つ以上の実施形態に係るステートレスアプリケーション通知のさまざまな態様を実現するために用いられ得る例示的なシステムを考慮する。

【0080】

例示的なシステム
図７は、上述したさまざまな実施形態を実現することができる１つ以上のコンピューティングシステムおよび／またはデバイスを表す例示的なコンピューティングデバイス７０２を含む例示的なシステムを、一般的に７００で示す。コンピューティングデバイス７０２は、たとえば、サービスプロバイダ１１４のサーバ、コンピューティングデバイス１０２に関連づけられたデバイス（たとえば、クライアントデバイス）、アプリケーションサービス１２８を提供するサーバ、オンチップのシステム、および／または任意の他の適切なコンピューティングデバイスまたはコンピューティングシステムであり得る。

【0081】

例示的なコンピューティングデバイス７０２は、１つ以上のプロセッサ７０４または処理ユニット、１つ以上のメモリおよび／またはストレージコンポーネント７０８を含み得る１つ以上のコンピュータ可読媒体７０６、入力／出力（Ｉ／Ｏ）デバイスのための１つ以上の入力／出力（Ｉ／Ｏ）インターフェース７１０、および、さまざまなコンポーネントおよびデバイスに互いに通信することを可能にさせるバス７１２を含む。コンピュータ可読媒体７０６および／または１つ以上のＩ／Ｏデバイスは、コンピューティングデバイス７０２の一部として含まれることができ、またはあるいは、コンピューティングデバイス７０２に結合されることができる。バス７１２は、メモリバスまたはメモリコントローラ、周辺機器バス、アクセラレイティッド・グラフィックス・ポート、および、さまざまなバスアーキテクチャのうちのいずれかを使用するプロセッサまたはローカルバス、を含むいくつかのタイプのバス構造のうちの１つ以上を表す。バス７１２は、有線および／または無線バスを含み得る。

【0082】

１つ以上のプロセッサ７０４は、それらを形成する材料、またはその中で用いられる処理メカニズムによって限定されるものではない。たとえば、プロセッサは、半導体および／またはトランジスタ（たとえば、電子集積回路（ＩＣ））からなり得る。そのようなコンテキストで、プロセッサ実行可能な命令は、電子的に実行可能な命令であり得る。メモリ／ストレージコンポーネント７０８は、１つ以上のコンピュータ可読媒体に関連づけられたメモリ／ストレージ容量を表す。メモリ／ストレージコンポーネント７０８は、揮発性媒体（たとえば、ランダムアクセスメモリ（ＲＡＭ））および／または不揮発性媒体（たとえば、読み出し専用メモリ（ＲＯＭ）、フラッシュメモリ、光学ディスク、磁気ディスク等）を含み得る。メモリ／ストレージコンポーネント７０８は、固定媒体（たとえば、ＲＡＭ、ＲＯＭ、固定ハードドライブ等）だけでなく、取り外し可能な媒体（たとえば、フラッシュメモリドライブ、取り外し可能なハードドライブ、光学ディスク等）も含み得る。

【0083】

入力／出力インターフェース７１０は、ユーザによるコンピューティングデバイス７０２へのコマンドおよび情報の入力を可能にし、また、さまざまな入力／出力デバイスを使用したユーザおよび／または他のコンポーネントまたはデバイスへの情報の提示を可能にする。入力デバイスの例は、キーボード、タッチスクリーンディスプレイ、カーソルコントロールデバイス（たとえば、マウス）、マイクロフォン、スキャナ等を含む。出力デバイスの例は、ディスプレイデバイス（たとえば、モニタまたはプロジェクタ）、スピーカー、プリンタ、ネットワークカード等を含む。

【0084】

さまざまな技法は、ソフトウェア、ハードウェア（固定論理回路）、またはプログラムモジュールの一般的なコンテキストで本明細書に説明され得る。一般的に、そのようなモジュールは、特定のタスクを実行し、または、特定の抽象データ型を実現する、ルーチン、プログラム、オブジェクト、要素、コンポーネント、データ構造等を含む。これらのモジュールおよび技法の実現は、何らかの形態のコンピュータ可読媒体によって記憶または伝送され得る。コンピュータ可読媒体は、コンピューティングデバイスによってアクセスされ得る、さまざまな利用可能な単数の媒体または複数の媒体を含み得る。限定ではなく例として、コンピュータ可読媒体は、「コンピュータ可読記憶媒体」および「通信媒体」を含み得る。

【0085】

「コンピュータ可読記憶媒体」は、単なる信号伝送、搬送波、または信号そのものとは対照的に、情報の永続的および／または非一時的な記憶を可能にする媒体および／またはデバイスのことを言い得る。このように、コンピュータ可読記憶媒体は、信号ではない搬送媒体のことを言う。コンピュータ可読記憶媒体はまた、所望の技法の態様を実現するためにいくつかの実施形態において用いられ得るハードウェアの形態で実装された、命令、モジュール、および／または固定デバイス論理を有する、ハードウェア要素を含む。

【0086】

コンピュータ可読記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、論理要素／回路、または他のデータ、といった情報の記憶に適した方法または技術において実現される、揮発性および不揮発性の、取り外し可能および取り外し不可能な媒体および／またはストレージデバイスを含む。コンピュータ可読記憶媒体の例は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ストレージ、ハードディスク、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、集積回路またはチップのハードウェア要素（たとえば、固定論理）、または他のストレージデバイス、有形媒体、または、所望の情報を記憶するのに適し、コンピュータによってアクセスされ得る製造物、を含むことができるが、それらに限定されない。

【0087】

「通信媒体」は、コンピューティングデバイスのハードウェアに、たとえばネットワークを介して、命令を伝送するように構成された信号搬送媒体のことを言い得る。通信媒体は典型的に、変調されたデータ信号、たとえば、搬送波、データ信号、または他のトランスポートメカニズムに、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを組み込み得る。通信媒体はまた、任意の情報送達媒体を含む。「変調されたデータ信号」という用語は、信号中に情報を符号化するようにその特徴のうちの１つ以上が設定または変更された信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークまたはダイレクト有線接続のような有線媒体、および、音響、ＲＦ、赤外線、および他の無線媒体、といった無線媒体を含む。

【0088】

上記のうちのいずれかの組み合わせもまた、コンピュータ可読媒体の範囲内に含まれるべきである。したがって、ＡＰＩ、通知サービス１２４、オペレーティングシステム１１０、アプリケーション１０８、および他のプログラムモジュールを含む、ソフトウェア、ハードウェア、またはプログラムモジュールは、何らかの形態のコンピュータ可読媒体に組み込まれた１つ以上の命令および／または論理として実現され得る。

【0089】

したがって、本明細書に説明された特定のモジュール、機能、コンポーネント、および技法は、ソフトウェア、ハードウェア、ファームウェア、および／またはそれらの組み合わせで実現され得る。コンピューティングデバイス７０２は、コンピュータ可読媒体上で実現されるソフトウェアおよび／またはハードウェアモジュールに対応する特定の命令および／または機能を実現するように構成されることができる。命令および／または機能は、ステートレスアプリケーション通知のための技法ならびに他の技法を実現するために、１つ以上の製造物（たとえば、１つ以上のコンピューティングデバイス７０２および／またはプロセッサ７０４）によって実行可能／動作可能であり得る。そのような技法は、本明細書に説明された例示的な手順を含むが、それに限定されない。したがって、コンピュータ可読媒体は、本明細書に説明される１つ以上のデバイスによって実行されると、ステートレスアプリケーション通知のためのさまざまな技法をもたらす命令を記憶し、またはそうでなければ提供するように構成され得る。

【0090】

結論
チャネルハンドルおよび／またはトークンの形態の難読化ルーティングデータが通知サービスを通じて通知を送信するために用いられ得るステートレスアプリケーション通知が説明された。ルーティングデータは、ルーティングデータのコンテンツとフォーマットを第三者に分かりにくくするために、暗号化およびデジタル署名されることができる。難読化ルーティングデータを所持するアプリケーションサービスは、データと共に通知をパッケージ化し、そのパッケージを送達のために通知サービスに送信することができる。通知サービスは、データを解読および解釈し、アプリケーションサービスに代わって適切なエンドポイントに通知を送達するように構成される。

【0091】

主題が、構造上の特徴および／または方法の動作に固有の表現で説明されているが、添付の請求項において定義される主題は、上述した特定の特徴または動作に必ずしも限定されるものではない、ということが理解されるべきである。むしろ、上述した特定の特徴および動作は、請求項を実現する例示的な形態として開示されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】