JP2022107581A - モバイルデバイスへの通知の配信 - Google Patents

Abstract

【課題】通知をモバイルデバイスに安全に配信するための方法、システム及びコンピュータ読取可能媒体を提供する。【解決手段】ネットワーク１００環境において、クライアントデバイスの通知コアは、サーバシステムのアプリＡサーバからの通知を含むメッセージを、無線キャリアシステムのキャリアメッセージハブから受信し、ローカルに格納された秘密鍵を用いてメッセージを復号し、通知を含む復号されたメッセージに関連付けられたクライアントデバイスに対して実行されるメッセージングアプリを識別し、さらに、復号したメッセージをメッセージングアプリに配信する。【選択図】図１

Description

背景
通知は、スマートフォン、タブレット、ウェアラブルデバイス、ラップトップなどのデバイス上で実行される最近のソフトウェアアプリケーションの一般的な機能である。多くの場合、通知はサーバによって生成され、インターネットを介してデバイス上で実行されるアプリケーションに提供される。安全なメッセージ配信を保証するために、アプリケーションは、このようなサーバとの安全な接続、たとえば、トランスポートレイヤーセキュリティ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ：ＴＬＳ）接続を利用する場合がある。

無線キャリアネットワークを経由してデータ通信および音声通信を行うために無線キャリアネットワークに結合されているモバイルデバイスでは、このような接続の確立および維持のために、かなりのリソースを必要とすることがある。たとえば、無線キャリアシステム（たとえば、ネットワークアドレス変換を利用する）は、非アクティブな安全な接続（たとえば、ＴＬＳ接続）を閉じる場合がある。このような場合、アプリケーションは、通知を受信するために、サーバとの安全な接続を再確立することが要求される。

安全な接続を閉じないことを保証するメカニズムでは、アプリケーションが定期的にキープアライブメッセージを生成し、インターネットを介してサーバに送信する。しかしながら、このようなメッセージを送信するには、モバイルデバイスの無線送信機がアクティブである必要があるが、これによって電力が浪費され、バッテリー駆動のデバイスではバッテリーが消耗する。アプリケーションは、電力使用量を削減するために、たとえば数分に１回など、定期的にサーバに接続するように構成することが可能であるが、通知配信が遅れることがあり、安全な接続が確立される周期でしか行われないため、ユーザエクスペリエンスを低下させる可能性がある。さらに、無線キャリアネットワークに結合された複数のデバイスから受信されるキープアライブメッセージは、セルラーの輻輳につながる可能性もある。

本明細書に記載された背景の説明は、本開示の文脈を一般的に示すためのものである。本背景の項に記載されている範囲での本願発明者の研究、および出願時に他の態様では先行技術として認められない可能性のある説明の側面は、本開示に対する先行技術として明示的にも黙示的にも認められない。

ＥＰ２８９２２０６では、メッセージングサービス（ＭＳ）とプッシュメッセージの内容を共有しても構わないという意味でＭＳを信頼している開発者向けの「信頼モデル」と、ＭＳを信頼していない開発者向けの「非信頼モデル」という２つのエンドツーエンドメッセージセキュリティモデルを提供する、プッシュメッセージングフレームワークが提案されている。これらの２つのモデルの間には本質的なトレードオフがあり、非信頼モデルで高いレベルのセキュリティは、使いやすさのレベルを低下させるという代償を払うことになる。本提案は、非信頼モデルの使いやすさを提供する。さらに、本提案は、両セキュリティモデルにおける、クライアント上の秘密鍵の保管方法に関する。この方法では、攻撃者は、鍵が使用される瞬間に攻撃のタイミングを計らなければならないように、秘密鍵がメモリで露出する時間を最小限に抑える。このセキュリティ対策は、容易に漏洩する可能性のあるＡｎｄｒｏｉｄクライアントにとって、極めて重要である。最後に、提案するセキュリティモデルは、海賊版の防止を目的としたアプリケーション認証機能をサポートする。

ＣＮ１０４８１１３６５では、メッセージプッシュ方法、メッセージプッシュシステム、メッセージプロキシサーバ、および端末装置が提案されている。この方法は、メッセージプロキシサーバが、アプリケーションサーバによって送信されたプッシュメッセージを受信し格納するステップ、メッセージプロキシサーバが、プッシュメッセージに従って中間メッセージを生成するステップ、および、メッセージプロキシサーバが、中間メッセージをメッセージプッシュサーバに送信して、メッセージプッシュサーバが中間メッセージを端末機器に転送できるようにし、端末機器が、中間メッセージに従って、メッセージプロキシサーバからプッシュメッセージを取得するステップから構成されている。この発明によれば、メッセージプロキシサーバは、アプリケーションサーバによって送信されたプッシュメッセージを一時的に格納し、中間メッセージを生成し、プッシュサーバが受信するメッセージは、中間メッセージとなる。したがって、プッシュサーバは、プッシュメッセージの平文を受信することができず、機密性の高い企業のプッシュメッセージの内容が漏洩する可能性があるという問題を解決することができる。

Ｐｕｓｈ ＡＰＩ Ｗ３Ｃ Ｗｏｒｋｉｎｇ Ｄｒａｆｔ（２０１７年１２月１５日）では、プッシュサービスを経由してウェブアプリにプッシュメッセージを送信可能なＰｕｓｈ ＡＰＩの仕様が提案されている。アプリケーションサーバは、ウェブアプリまたはユーザエージェントが非アクティブな状態でも、いつでもプッシュメッセージを送信することができる。プッシュサービスは、ユーザエージェントへの信頼性の高い、効率的な配信を保証する。プッシュメッセージは、ウェブアプリのオリジンで実行されるサービスワーカーに配信され、サービスワーカーは、メッセージ内の情報を使用して、ローカルの状態の更新、またはユーザへの通知の表示を行うことができる。この仕様は、アプリケーションサーバまたはユーザエージェントがプッシュサービスとどのようにインタラクションを行うかを説明するウェブプッシュプロトコルと共に使用するために設計されている。

概要
本明細書に記載する実現例は、モバイルデバイスに通知を安全に配信するための方法、システム、およびコンピュータ読取可能媒体に関する。

ある態様では、コンピュータによって実現される方法は、受信者デバイスにおいて、アプリケーションサーバからの通知を含むメッセージを、無線キャリアから受信することを備える。本方法はさらに、受信者デバイスにローカルに格納された秘密鍵を使用してメッセージを復号することを備える。本方法はさらに、復号されたメッセージに関連付けられた受信者デバイス上で実行されるソフトウェアアプリケーションを識別することを備え、復号されたメッセージは、通知を含む。本方法はさらに、復号されたメッセージをソフトウェアアプリケーションに配信することを備える。

受信者デバイスは、無線キャリアによって操作されるセルラーネットワークに結合された無線デバイスであり、メッセージを受信することは、セルラーネットワーク上でリッチコミュニケーションサービス（Ｒｉｃｈ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅｓ：ＲＣＳ）プロトコルを介してメッセージを受信することを含む。いくつかの実現例では、メッセージは、セッション開始プロトコル（ＳＩＰ）メッセージとして受信されてもよい。いくつかの実現例では、ＳＩＰメッセージは、ＳＩＰ ＯＰＴＩＯＮＳメッセージでもよい。これらの実現例では、通知は、ＳＩＰ ＯＰＴＩＯＮＳメッセージのコンテンツ本体に含まれてもよい。

いくつかの実現例では、メッセージは、無線キャリアと通信しているデバイスモデムを経由して、受信者デバイスのネットワークアクセス層で受信されてもよい。これらの実現例では、ソフトウェアアプリケーションとアプリケーションサーバとの間にアクティブな接続は存在しない。

いくつかの実現例では、方法はさらに、復号の後に、確認メッセージを無線キャリアに送信することを備えてもよい。

いくつかの実現例では、方法はさらに、メッセージを受信する前に、受信者デバイスにおいて、公開鍵と秘密鍵とを含む暗号鍵ペアを生成することと、受信者デバイスのローカルストレージに秘密鍵を格納することと、公開鍵を含む登録メッセージをインターネットを介してメッセージ配信サーバに送信することとを備えてもよい。いくつかの実現例では、登録メッセージはさらに、ソフトウェアアプリケーションに関連付けられたトークンを含んでもよい。これらの実現例では、ソフトウェアアプリケーションの識別は、復号されたメッセージ内の受信されたトークンがソフトウェアアプリケーションに関連付けられたトークンと一致すると判断することに基づいてもよい。

他の態様では、デバイスは、プロセッサと、デバイスを無線キャリアに結合するように動作可能なモデムと、プロセッサに結合されたメモリとを備え、メモリは、プロセッサによって実行されると、プロセッサに動作を行わせる命令を格納し、動作は、アプリケーションサーバからの通知を含むメッセージを、無線キャリアから受信することと、秘密鍵を用いてメッセージを復号することと、通知を含む復号されたメッセージに関連付けられたソフトウェアアプリケーションを識別することと、復号されたメッセージを、ソフトウェアアプリケーションに配信することとを含む。メッセージは、無線キャリアと通信しているモデムを経由してデバイスのネットワークアクセス層で受信され、ソフトウェアアプリケーションとアプリケーションサーバとの間にアクティブな接続は存在しない。

いくつかの実現例では、デバイスは、無線キャリアによって操作されるセルラーネットワークに結合されてもよく、メッセージを受信することは、セルラーネットワーク上でリッチコミュニケーションサービス（ＲＣＳ）プロトコルを介してメッセージを受信することを含む。いくつかの実現例では、メッセージは、セッション開始プロトコル（ＳＩＰ）メッセージとして受信されてもよい。

いくつかの実現例では、動作はさらに、メッセージを受信する前に、公開鍵と秘密鍵とを含む暗号鍵ペアを生成することと、秘密鍵をデバイスのローカルストレージに格納することと、公開鍵を含む登録メッセージを、インターネットを介してメッセージ配信サーバに送信することとを含んでもよい。

他の態様では、メッセージを配信するためにコンピュータによって実現される方法は、メッセージ配信サーバにおいて、アプリケーションサーバから通知を受信することを備える。本方法はさらに、通知の受信者がメッセージ配信サーバに格納された公開鍵に関連付けられていると判断することを備え、公開鍵は受信者デバイスに関連付けられている。本方法はさらに、受信者が公開鍵に関連付けられているという判断に応答して、通知を公開鍵で暗号化することによりメッセージを生成することを備える。本方法はさらに、メッセージを無線キャリアに送信して、受信者デバイスに配信することを備える。

受信者デバイスは、無線キャリアによって操作されるセルラーネットワークに結合された無線デバイスであり、受信者へのメッセージの配信は、セルラーネットワーク上でリッチコミュニケーションサービス（ＲＣＳ）プロトコルを介して行われる。いくつかの実現例では、メッセージ配信サーバと無線キャリアとは、ＲＣＳのためのピアリング接続を維持してもよい。

いくつかの実現例では、方法はさらに、インターネットを介して１つ以上の他の受信者デバイスに通知を送信することを備えてもよい。

いくつかの実現例において、方法はさらに、通知を受信する前に、メッセージ配信サーバにおいて、公開鍵および受信者識別子を含む登録メッセージを、受信者デバイスから受信することを備えてもよい。いくつかの実現例では、通知の受信者が公開鍵に関連付けられていると判断することは、受信者が受信者識別子と一致すると判断することに基づいてもよい。いくつかの実現例では、受信者デバイスは、ソフトウェアアプリケーションを実行してもよく、受信者識別子は、ソフトウェアアプリケーションに関連付けられたトークンでもよい。

本明細書に記載する１つ以上の実現例に使用することができるネットワーク環境の例を示すブロック図である。 いくつかの実現例に係る、通知を受信するデバイスを登録する方法の例を示すフロー図である。 いくつかの実現例に係る、デバイスで通知を受信する方法の例を示すフロー図である。 いくつかの実現例に係る、通知の配信を説明するフロー図である。 本明細書に記載された１つ以上の特徴を実現するために使用され得るコンピューティングデバイスの例を示すブロック図である。

詳細な説明
無線キャリアを経由して（ネットワークアクセス層を介して）クライアントデバイスにメッセージを配信するための方法、システム、およびコンピュータ読取可能媒体（非一時的なコンピュータ読取可能媒体でもよいが、これらに限定されない）が本明細に記載される。メッセージは、クライアントデバイス上で実行されるアプリケーションのための通知を含んでもよい。記載された技術によれば、無線キャリアを経由したアプリの通知を含むメッセージの配信のために、デバイスが無線キャリアに登録される。

記載された技術は、クライアントデバイスと、アプリケーションサーバによって生成された通知をクライアントデバイスに配信するメッセージ配信サーバとの間、またはクライアントデバイスとアプリケーションサーバとの間の安全な接続を確立および維持する通知技術の技術的欠点に対処する。そのような通知技術は、典型的には、インターネット公共データネットワーク（ＰＤＮ）を介したオーバーザトップ（ｏｖｅｒ ｔｈｅ ｔｏｐ：ＯＴＴ）トランスポートレイヤーセキュリティ（ＴＬＳ）接続を使用する。

このような構成の技術的な問題は、無線キャリアバックエンドにおけるネットワークアドレス変換（ＮＡＴ）のタイムアウトが発生し、非活動であること、たとえば、無線キャリアが設定した閾値より長い期間、クライアントデバイスと無線キャリアシステムとの間で安全な接続を介したインタラクションがないために、安全な接続が閉じられる可能性があるということである。このような接続の閉鎖を回避するために、クライアントデバイス（たとえば、通知を受信するアプリケーション）は、定期的にキープアライブメッセージを送信することが要求される。このようなメッセージを送信するには、無線送信機（およびクライアントデバイスモデムを含む関連回路）をウェイクアップする必要がある。このような無線送信機のウェイクアップおよび使用は、電力を浪費する可能性がある。バッテリ駆動のデバイスでは、このようなアクティビティによって、デバイスのバッテリが消耗する可能性がある。さらに、キープアライブメッセージは、無線キャリアのセルラーネットワークの輻輳につながる可能性がある。

本明細書に記載する方法、システム、および非一時的なコンピュータ読取可能媒体は、クライアントデバイス（たとえば、携帯電話または他のセルラー通信デバイス）と無線キャリアシステムとの間の単一登録メッセージング（以下にさらに説明する）を利用して、メッセージ（たとえば、アプリ通知を含むもの）を配信する技術である。単一登録メッセージングは、クライアントデバイスが無線キャリアシステムに登録し、接続を開いたままにするために、（クライアントデバイスが定期的にウェイクアップすることを必要とする高価なキープアライブを必要とせずに）ＩＰマルチメディア（コアネットワーク）サブシステムＰＤＮ（ＩＭＳ ＰＤＮ）を活用するメカニズムである。たとえば、リッチコミュニケーションサービス（ＲＣＳ）プロトコルを、メッセージ配信に使用してもよい。

無線キャリアは、通常、（たとえば、ＩＰマルチメディア（コアネットワーク）サブシステムＰＤＮ（ＩＭＳ ＰＤＮ）上の単一のＩＰセキュリティ（ＩＰＳｅｃ）ソケットを介してＶｏｉｃｅ－ｏｖｅｒ－ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）およびＲＣＳ登録を経由したクライアントデバイスと無線キャリアシステムとの間の通信用に）クライアントデバイスの登録を共有する。クライアントデバイスは、セルラー通信用にＩＭＳネットワークへの接続を維持する。

本明細書に記載の技術により、デバイスの登録が成功すると、デバイスとＩＭＳネットワークとの間のこのような接続が、クライアントデバイス上のアプリケーションに対するメッセージ配信に利用される。ＴＬＳ（または他の安全なＯＴＴ接続）を確立し、それを生かし続けるオーバーヘッドを排除することによって、記載された技術は、クライアントデバイスを定期的にウェイクアップする必要またはメッセージを送信する必要がなくなり、それによって、電力消費を下げ、電池寿命を改善し、無線（セルラー）ネットワーク上のネットワークの輻輳を低減する。また、記載された技術は、クライアントデバイスが準最適なインターネット接続を有する場合に、通知配信の信頼性および性能を改善することができる。

さらに、ＩＭＳネットワークの重要な利点は、ネットワークアドレス変換がなく、インターネットプロトコルバージョン６（ＩＰｖ６）で展開されることである。記載された技術は、アプリ通知の確実な配信を可能にするデバイス登録を実行することによって、ＩＭＳ ＰＤＮのこの特徴を有利に利用する。ＩＭＳ ＰＤＮを経由したメッセージ配信の技術的な問題は、ＩＭＳ ＰＤＮが、しばしば、アプリケーションサーバおよび／またはメッセージ配信サーバへの直接接続を禁止するファイアウォール環境に配備されることである。さらに、クライアントデバイスのデバイスオペレーティングシステムは、このような接続がクライアントデバイスのハードウェア（たとえば、デバイスモデム）によって管理されることがあるため、ＩＭＳ ＰＤＮへの露出が制限される場合がある。記載された技術は、デバイス登録を利用することによってこの問題を克服する。

記載された技術は、有利に、安全なＯＴＴ接続の確立を必要とすることなく、アプリ通知が無線キャリアネットワークを介して安全に送信されることを保証するために、公開鍵暗号を使用する。特に、クライアントデバイスは、メッセージ配信サーバ（または通知を生成する他のサーバ）が通知を暗号化するために使用する公開鍵を提供する。暗号化されたメッセージは、メッセージコンテンツ（たとえば、アプリ通知）のセキュリティを損なうことなく、通常の通信チャネル（たとえば、非暗号化）を介して送信可能である。クライアントデバイスに安全に格納されている秘密鍵は、メッセージを復号し、通知を取得し、クライアントデバイス上のそれぞれのアプリケーションに提供するために利用される。

図１は、本明細書で説明するいくつかの実現例で使用され得る、ネットワーク環境１００の例を示すブロック図である。いくつかの実現例では、ネットワーク環境１００は、１つまたは複数のサーバシステム、たとえば、図１の例ではサーバシステム１０２および第２のサーバシステム１４０を含む。サーバシステム１０２および１４０は、たとえば、ネットワーク１３０と通信することができる。サーバシステム１０２は、サーバ装置１０４と、データベース１０６または他のストレージデバイスとを含み得る。いくつかの実現例では、サーバ装置１０４は、メッセージ配信アプリケーション１０８を提供してもよい。第２のサーバシステム１４０は、１つまたは複数のアプリケーションサーバ、たとえば、アプリＡサーバ１４２およびアプリＢサーバ１４４を含み得る。

メッセージ配信アプリケーション１０８は、ネットワーク１３０を介して、１つ以上のアプリケーションサーバ、たとえば、アプリＡサーバ１４２、アプリＢサーバ１４４と通信するように構成されてもよい。たとえば、アプリケーションサーバは、１つ以上のクライアントデバイスに送信される通知を生成するように構成されてもよく、メッセージ配信を実行し得るメッセージ配信サーバ１０４に当該通知を送信してもよい。いくつかの実現例では、メッセージ配信アプリケーション１０８は、クラウドベースのメッセージングサービスとして実現されてもよい。メッセージ配信アプリケーション１０８は、アプリケーションサーバがクライアントデバイス上のアプリ（たとえば、アプリＡ１５２、アプリＢ１５４）に通知を送信することを可能にしてもよい。たとえば、アプリＡが電子メールアプリケーションである場合、通知は、アプリＡに対して新しい電子メールメッセージまたは他のデータが利用可能であることを示してもよい。別の例では、アプリＢがショッピングアプリである場合、通知は、ユーザにオファーまたはクーポンを知らせ、注文に関するステータス更新を提供するなどしてもよい。さまざまな実現例において、通知は、テキスト、グラフィックス（たとえば、画像、ビデオ等）、または他のコンテンツを含み得る。

ネットワーク環境１００はまた、１つまたは複数のクライアントデバイス、たとえば、クライアントデバイス１２０，１２２，１２４および１２６を含み得、これらはネットワーク１３０を介して互いに、ならびに／または、サーバシステム１０２および／もしくは第２のサーバシステム１４０と通信してもよい。クライアントデバイス１２０～１２６は、無線キャリア、たとえば無線キャリアシステム（１６０）によって操作されるセルラーネットワークに結合されてもよい。いくつかの実現例では、クライアントデバイス１２０～１２６は、セルラーネットワーク上でリッチコミュニケーションサービス（ＲＣＳ）プロトコルを経由してメッセージを送受信するように構成されてもよい。

ネットワーク１３０は、任意のタイプの通信ネットワーク、たとえば、インターネットまたは広域ネットワークであり得る。いくつかの実現例では、２つ以上のクライアントデバイスは、たとえば、ピアツーピア無線プロトコル（たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ（登録商標）Ｄｉｒｅｃｔ等）などを用いて、ピアツーピア通信を行うように構成されてもよい。２つのクライアントデバイス１２０と１２２と間のピアツーピア通信の一例が、矢印１３２によって示される。

ネットワーク環境１００はまた、ネットワーク１３０に結合された無線キャリアシステム１６０を含む。無線キャリアシステム１６０は、たとえば、クライアントデバイス１２０～１２６のいずれかがセルラー接続を経由して無線キャリアシステム１６０と通信することを可能にするセルラーサービスインフラストラクチャを含んでもよい。いくつかの実現例では、セルラー接続は、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）接続、５Ｇ接続などでもよい。さまざまな実現例において、クライアントデバイス１２０～１２６は、ネットワークアクセス層を経由して無線キャリアシステム１６０との接続性を維持してもよい。たとえば、クライアントデバイスは、４Ｇもしくは５Ｇネットワークを介して、またはｅＰＤＧ（ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｄａｔａ Ｇａｔｅｗａｙ接続、たとえば、無線アクセスポイント（ＷｉＦｉ ＡＰ）に接続される場合）を経由して、無線キャリアシステム１６０（キャリアバックエンド）とのアクティブな接続を維持することができる。いずれの場合も、無線キャリアシステム１６０との接続は、ＩＰセキュリティ（ＩＰＳｅｃ）を介するため、信頼できるものであり、暗号化されている。クライアントデバイスが４Ｇまたは５Ｇネットワークを介して接続される場合、キープアライブメッセージは不要である。クライアントデバイスが無線ＡＰ（ＷｉＦｉ）を介して接続される場合、デバイスモデムは、デバイスの残りの部分をウェイクアップすることなく、ＩＰＳｅｃチャネル上でキープアライブを送信する。ＩＰＳｅｃチャネルはＶｏｉｃｅ ｏｖｅｒ ＷｉＦｉ（ＶｏＷｉＦｉ）用に維持されるため、モデムが送信するキープアライブメッセージは、クライアントデバイスまたは無線キャリアネットワークにさらに負担をかけることはない。

無線キャリアシステム１６０は、キャリアメッセージングハブ１６２を含んでもよい。たとえば、キャリアメッセージングハブ１６２は、１つまたは複数のサーバ装置を含んでもよい。いくつかの実現例では、キャリアメッセージングハブは、メッセージ配信アプリケーション１０８を実行するサーバ装置１０４とピアリング接続を確立してもよい。ピアリング接続は、メッセージ配信アプリケーションからキャリアメッセージングハブを経由して、クライアントデバイスへのメッセージの効率的かつ迅速な中継を可能にし得る。無線キャリアシステム１６０は、ネットワーク１３０、たとえば、インターネットまたは他の広域ネットワークを経由して、サーバ装置１０４およびサーバシステム１４０に結合される。

図１では、説明を容易にするために、サーバシステム１０２、サーバ装置１０４、データベース１０６、第２のサーバシステム１４０、アプリＡサーバ１４２、およびアプリＢサーバ１４４について１つのブロックを示し、クライアントデバイス１２０，１２２，１２４および１２６について４つのブロックを示している。サーバブロック１０２，１０４，１０６，１４０，１４２および１４４は、複数のシステム、サーバ装置、およびネットワークデータベースを表す場合があり、ブロックは、図示とは異なる構成で提供可能である。たとえば、サーバシステム１０２および／または第２のサーバシステム１４０は、ネットワーク１３０を経由して他のサーバシステムと通信可能な複数のサーバシステムを表すことができる。いくつかの実現例では、サーバシステム１０２および／または第２のサーバシステム１４０は、たとえば、クラウドホスティングサーバを含み得る。いくつかの例では、データベース１０６および／または他のストレージデバイスは、サーバ装置１０４とは別個のサーバシステムブロック（複数可）において提供可能であり、ネットワーク１３０を経由してサーバ装置１０４および他のサーバシステムと通信可能である。いくつかの実現例では、複数のアプリケーションが同じサーバ上で実行されてもよく、たとえば、アプリＡサーバ１４２が追加のアプリケーションを実行してもよい、または単一のアプリケーションが、たとえば分散構成で、複数のサーバにまたがってもよい。

また、クライアントデバイスは何台でもよい。各クライアントデバイスは、任意のタイプの電子デバイス、たとえば、デスクトップコンピュータ、ラップトップコンピュータ、ポータブルまたはモバイルデバイス、携帯電話、スマートフォン、タブレットコンピュータ、テレビ、テレビセットトップボックスまたは娯楽装置、ウェアラブル装置（たとえば、ディスプレイ眼鏡またはゴーグル、腕時計、ヘッドセット、アームバンド、宝石等）、パーソナルデジタルアシスタント（ＰＤＡ）、メディアプレーヤー、ゲームデバイスなどでもよい。いくつかのクライアントデバイスは、データベース１０６と同様のローカルデータベースまたは他のストレージを有してもよい。いくつかの実現例では、ネットワーク環境１００は、示された構成要素のすべてを有していなくてもよい、および／または、本明細書に記載された要素の代わりに、もしくはそれらに加えて、他のタイプの要素を含む他の要素を有してもよい。

さまざまな実現例において、エンドユーザであるユーザ１、ユーザ２、ユーザ３およびユーザ４は、それぞれのクライアントデバイス１２０，１２２，１２４および１２６を用いて、サーバシステム１０２と、および／または互いに通信してもよい。いくつかの例では、ユーザ１、ユーザ２、ユーザ３およびユーザ４は、それぞれのクライアントデバイスおよび／またはサーバシステム１０２もしくは第２のサーバシステム１４０上で実行されるアプリケーションを経由して、および／またはサーバシステム１０２もしくは第２のサーバシステム１４０上で実現されるネットワークサービス、たとえばソーシャルネットワークサービスまたは他の種類のネットワークサービスを経由して、互いにインタラクションしてもよい。たとえば、それぞれのクライアントデバイス１２０，１２２，１２４および１２６は、１つまたは複数のサーバシステム（たとえば、システム１０２、第２のサーバシステム１４０）との間でデータを通信してもよい。

いくつかの実現例では、サーバシステム１０２および／または第２のサーバシステム１４０は、各クライアントデバイスが、サーバシステム１０２もしくは第２のサーバシステム１４０にアップロードされる通信コンテンツもしくは共有コンテンツ、および／またはネットワークサービスを受信できるように、クライアントデバイスに適切なデータを提供してもよい。いくつかの例では、ユーザ１～ユーザ４は、音声もしくはビデオ会議、音声、ビデオ、もしくはテキストチャット、または他の通信モードもしくはアプリケーションを経由してインタラクション可能である。

いくつかの実現例では、クライアントデバイス１２０，１２２，１２４および／または１２６のいずれかが、１つまたは複数のアプリケーションを提供することができる。たとえば、図１に示すように、クライアントデバイス１２０は、アプリＡ１５２、アプリＢ１５４、メッセージングアプリケーション１５６（本明細書ではメッセージングアプリ１５６とも呼ばれる）、および通知コア１５８を提供し得る。他のクライアントデバイスもまた、さまざまなアプリケーションを含んでもよい。異なるクライアントデバイスは、異なるアプリケーションを含んでもよい。

いくつかの実現例では、メッセージングアプリケーション１５６は、デフォルトのメッセージングアプリケーションでもよい。これらの実現例では、クライアントデバイス１２０のモデムは、セルラー接続を介して、たとえば、キャリアメッセージングハブ１６２からリッチコミュニケーションサービス（ＲＣＳ）プロトコルを用いてメッセージを受信し、メッセージを受信すると、メッセージをメッセージングアプリケーション１５６に自動的に提供するように構成されてもよい。メッセージングアプリケーション１５６は、さまざまなメッセージ処理機能を実行し得る。たとえば、メッセージングアプリケーション１５６は、メッセージをユーザインターフェイスに表示してもよい。別の例では、メッセージングアプリケーション１５６は、通知コア１５８を呼び出してもよく、通知コア１５８にメッセージを提供してもよい。これらの実現例において、通知コア１５８は、１つ以上のアクション、たとえば、メッセージを復号してメッセージコンテンツ（たとえば、通知）を取得し、通知が宛てられたアプリケーションを（たとえば、通知内のトークンに基づいて）識別し、識別されたアプリケーションに通知を転送する、等を実行してもよい。いくつかの実現例では、メッセージングアプリ１５６および通知コア１５８は、単一のアプリケーションとして実現されてもよい。いくつかの実現例では、メッセージングアプリ１５６は、クライアントデバイス１２０のオペレーティングシステムの一部として提供されてもよい。いくつかの実現例では、通知コア１５８は、クライアントデバイス１２０とともに配布される（たとえば、プリインストールされる）、またはクライアントデバイス１２０にダウンロード可能な別個のアプリケーション（もしくはソフトウェアパッケージ）として提供されてもよい。

アプリケーション１５２～１５８は、クライアントデバイス１２０のハードウェアおよび／またはソフトウェアを用いて実現されてもよい。異なる実現例では、アプリケーション１５２～１５８のうちの１つまたは複数は、たとえば、クライアントデバイス１２０～１２４のいずれかの上で実行されるスタンドアロンクライアントアプリケーションでもよい。

さまざまな実現例において、クライアントデバイス１２０は、メッセージングアプリ１５６および通知コア１５８の他に、１つ、２つ、またはそれ以上のアプリケーションを含んでもよい。たとえば、そのようなアプリケーションは、さまざまな種類の機能、たとえば、カレンダー、アドレス帳、電子メール、ウェブブラウザ、ショッピング、交通（たとえば、タクシー、列車、航空会社の予約等）、娯楽（たとえば、音楽プレーヤー、ビデオプレーヤー、ゲームアプリケーション等）、ソーシャルネットワーク（たとえば、チャット、オーディオ／ビデオ通話、画像／ビデオの共有等）などを提供してもよい。いくつかの実現例では、アプリケーション１５４の１つまたは複数は、クライアントデバイス１２０上で実行されるスタンドアロンアプリケーションでもよい。いくつかの実現例では、他のアプリケーション１５４のうちの１つもしくは複数は、データおよび／または機能を提供するサーバシステム、たとえば、サーバシステム１０２および／または第２のサーバシステム１４０にアクセスしてもよい。

クライアントデバイス１２０，１２２，１２４および／または１２６上のユーザインターフェイスは、画像、ビデオ、データ、および他のコンテンツ、ならびに通信、プライバシー設定、通知、および他のデータを含むユーザコンテンツおよび他のコンテンツの表示を可能にすることができる。そのようなユーザインターフェイスは、クライアントデバイス上のソフトウェア、サーバ装置１０４上のソフトウェア、ならびに／またはサーバ装置１０４および／もしくはサーバシステム１４０上で実行されるクライアントソフトウェアとサーバソフトウェアとの組合わせ、たとえば、サーバシステム１０２および／またはサーバシステム１４０と通信するアプリケーションソフトウェアもしくはクライアントソフトウェアを用いて表示可能である。ユーザインターフェイスは、クライアントデバイスまたはサーバ装置の表示装置、たとえば、タッチスクリーンまたは他の表示画面、プロジェクタ等によって表示可能である。いくつかの実現例では、サーバシステム上で実行されるアプリケーションプログラムは、クライアントデバイスと通信して、クライアントデバイスでユーザ入力を受信し、クライアントデバイスで視覚データ、音声データなどのデータを出力可能である。

図２は、いくつかの実現例に係る、通知を受信するデバイスを登録する方法２００の例を示すフロー図である。いくつかの実現例では、方法２００は、たとえば、図１に示すように、クライアントデバイス１２０，１２２，１２４または１２６のうちの１つまたは複数で実現可能である。説明された例では、実装システムは、１つもしくは複数のデジタルプロセッサまたは処理回路（「プロセッサ」）、および１つもしくは複数のストレージデバイスを含む。いくつかの実現例では、１つもしくは複数のサーバ（たとえば、サーバ装置１０４）および／またはクライアントデバイスの異なる構成要素は、方法２００の異なるブロックまたは他の部分を実行可能である。

いくつかの実現例では、方法２００、または方法の一部は、システムによって自動的に開始可能である。たとえば、方法（またはその一部）は、定期的に実行可能である、または１つ以上の特定のイベントもしくは条件、たとえば、クライアントデバイス上の特定のアプリケーション（たとえば、アプリＡ，アプリＢ）のインストールまたは更新の検出、クライアントデバイスがＲＣＳメッセージング可能であることの検出、クライアントデバイスの先行登録が失効したことの検出、方法２００の最後の実行から所定の時間が経過したこと、および／または方法の実行において読み取られる設定において規定され得る１つ以上の他の条件の発生に基づいて、実行可能である。

方法２００は、ブロック２０２で開始してもよい。ブロック２０２で、方法２００の実現においてユーザデータを使用するためのユーザ許可が得られる。たとえば、許可が得られるユーザデータは、ユーザの電話番号（クライアントデバイス１２０に関連付けられている）、トークン（複数可）、クライアントデバイス１２０にインストールされ実行可能なアプリケーションの識別子などを含み得る。ユーザには、そのようなユーザデータへのアクセス許可を選択的に提供するためのオプションが提供される。たとえば、ユーザは、要求されたユーザデータの全てにアクセスする、要求されたデータの任意のサブセットにアクセスする、または要求されたデータのいずれにもアクセスしない許可を提供するように選択してもよい。本明細書に記載される方法の１つ以上のブロックは、いくつかの実現例において、そのようなユーザデータを使用してもよい。ブロック２０２の後に、ブロック２０４が続く。

ブロック２０４で、本明細書で説明するような方法２００の残りの部分（ブロック２１２～２１８）が、ユーザによって提供された許可で、たとえば、ユーザによって許可されたようにデータにアクセスすることによって、実現可能かどうかが判断される。ブロック２０２でユーザによって提供された許可がブロック２１２～２１８の１つ以上を実現するのに不十分であると、ブロック２０４で判断される場合、ブロック２０４の後にブロック２０６が続き、そうでなければ、ブロック２０４の後にブロック２１２が続く。

ブロック２０６で、ユーザデータにアクセスするためのユーザ許可が要求される。たとえば、ブロック２１２～２１８において使用され得るユーザデータの１つ以上の部分に対する許可をユーザが拒否した場合、ユーザデータの当該部分に対する許可をユーザが提供するために、ユーザインターフェイスが提供されてもよい。ユーザインターフェイスは、データがどのように使用され得るかをユーザに示してもよく、かつ／または、そのような許可を提供することが、たとえば、クライアントデバイス１２０の登録を可能にすることによって、ユーザに利益をもたらし得るという表示を提供してもよい。代替的に、たとえば、ユーザがユーザデータへのアクセスの要求を却下する、または他の態様では許可の拒否を示す場合、方法は、ユーザデータにアクセスされないように、ブロック２０６で終了する。そのような場合、ブロック２１２～２１８は実行されない。

ユーザによって提供された許可がブロックを実現するのに十分である場合、ブロック２０４の後にブロック２１２が続く。方法の残りの部分、たとえば、ブロック２１２～２１８は、ユーザによって許可されたように、ユーザデータへの選択的なアクセスで実現される。いくつかの実現例では、ユーザには、ユーザデータへのアクセスを提供するため、または許可を修正するために、追加のプロンプトが提供されてもよい。

ブロック２１２で、クライアントデバイス（たとえば、クライアントデバイス１２０）が単一登録メッセージングが可能であるかどうかが判断される。いくつかの実現例では、単一登録メッセージングは、クライアントデバイスが無線キャリアシステム（たとえば、無線キャリアシステム１６０）を経由して１つまたは複数の他のクライアントデバイス、サーバ装置などとメッセージ交換することを指す場合がある。単一登録の下では、クライアントデバイスは、無線キャリアシステムがクライアントデバイスを登録し（たとえば、登録メッセージで送信されたクライアントデバイス情報をデータベースに格納し）、他のクライアントデバイスまたはサーバ装置で発信されたメッセージをクライアントデバイスに配信することを可能にする登録メッセージを、無線キャリアシステムに送信してもよい。たとえば、メッセージ配信は、リッチコミュニケーションサービス（ＲＣＳ）プロトコルを介して実行されてもよい。クライアントデバイスが単一登録メッセージングが可能であると判断される場合、ブロック２１２の後にブロック２１４が続く。そうでなければ、ブロック２１２の後にブロック２１８が続く。

ブロック２１４で、暗号鍵ペアが生成される。暗号鍵ペアは、秘密鍵および公開鍵を含む。鍵ペアは、任意の標準的な暗号技術を使用して生成されてもよい。いくつかの実現例では、鍵ペアは、Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｉｖａｃｙ（ＰＧＰ）暗号化を使用して生成されてもよい。鍵ペアは、公開鍵を用いて暗号化されたデータを秘密鍵を用いてのみ復号できるように、使用することができる。秘密鍵は、生成されると、鍵ペアを生成したクライアントデバイス１２０のローカルストレージに格納される。ブロック２１４の後に、ブロック２１６が続く場合がある。

ブロック２１６で、登録メッセージが生成され、メッセージ配信サーバ（たとえば、配信アプリケーション１０８を実行するサーバ装置１０４）へ送信される。いくつかの実現例では、登録メッセージは公開鍵を含む。いくつかの実現例では、登録メッセージは受信者識別子も含む。他の実現例では、公開鍵および／または受信者識別子は、登録メッセージとは別にメッセージ配信サーバに送信されてもよい。たとえば、受信者識別子は、たとえば特定のアプリケーション（たとえば、アプリＡ１５２）から受信したトークンでもよい。いくつかの実現例では、登録メッセージは、方法２００を実現するクライアントデバイス（たとえば、クライアントデバイス１２０）に関連付けられた電話番号も含む。クライアントデバイスが登録されると、メッセージ配信サーバ（たとえば、配信アプリケーション１０８を実行するサーバ１０４）は、たとえば、クライアントデバイスが無線キャリアシステム（１６０）とインタラクションするネットワークアクセス層を経由して、クライアントデバイスにメッセージを配信してもよい。クライアントデバイスと無線キャリアシステムとの間のインタラクションは、無線キャリアによって操作される公衆データネットワーク（ＰＤＮ）のＩＰマルチメディアサブシステム（ＩＭＳ）上の単一のＩＰセキュリティ（ＩＰＳｅｃ）ソケットを介してもよい。

クライアントデバイスが単一登録メッセージングを行うことができないとブロック２１２で判断された場合に実現されるブロック２１８で、デフォルトの通知技術が実現される。たとえば、アプリＡ１５２は、クライアントデバイス上で実行中のアプリケーション、たとえば、アプリＡ１５２、アプリＢ１５４のためのアプリケーションサーバ（たとえば、アプリＡサーバ１４２、アプリＢサーバ１４４）によって生成される通知を受信するために、メッセージ配信サーバ（たとえば、サーバ１０４）とのトランスポートレイヤーセキュリティ（ＴＬＳ）を使用して、デバイスが安全な接続を開始し維持することを必要とするインターネットプロトコル接続を介して、メッセージを受信するように構成されてもよい。

図３は、いくつかの実現例に係る、デバイスで通知を受信する方法の例を示すフロー図である。いくつかの実現例では、方法３００は、たとえば、図１に示すように、クライアントデバイス１２０，１２２，１２４または１２６のうちの１つもしくは複数で実現可能である。説明された例では、実装システムは、１つもしくは複数のデジタルプロセッサまたは処理回路（「プロセッサ」）、および１つもしくは複数のストレージデバイスを含む。いくつかの実現例では、１つもしくは複数のサーバ（たとえば、サーバ装置１０４）および／またはクライアントデバイスの異なる構成要素は、方法３００の異なるブロックまたは他の部分を実行することができる。

方法３００は、ブロック３０２で開始してもよい。ブロック３０２で、方法３００の実現においてユーザデータを使用するためのユーザ許可が得られる。たとえば、許可が得られるユーザデータは、ユーザの着信メッセージ、たとえば、ＲＣＳプロトコルを経由して無線キャリアから受信したメッセージ、トークン（複数可）、クライアントデバイス１２０にインストールされ実行可能なアプリケーションの識別子等を含み得る。ユーザには、そのようなユーザデータへのアクセス許可を選択的に提供するためのオプションが提供される。たとえば、ユーザは、要求されたユーザデータの全てにアクセスする、要求されたデータの任意のサブセットにアクセスする、または要求されたデータのいずれにもアクセスしない許可を提供するように選択してもよい。本明細書に記載される方法の１つ以上のブロックでは、いくつかの実現例において、そのようなユーザデータが使用されてもよい。ブロック３０２の後に、ブロック３０４が続く。

ブロック３０４で、本明細書で説明する方法３００の残りの部分（ブロック３１２～３２０）が、ユーザによって提供された許可で、たとえば、ユーザによって許可されたようにデータにアクセスすることによって、実現可能かどうかが判断される。ブロック３０２においてユーザによって提供された許可が、１つまたは複数のブロック３１２～３２０を実現するには不十分であると、ブロック３０４で判断される場合、ブロック３０４の後にブロック３０６が続き、そうでなければ、ブロック３０４の後にブロック３１２が続く。

ブロック３０６で、ユーザデータにアクセスするためのユーザ許可が要求される。たとえば、ブロック３１２～３２０において使用され得るユーザデータの１つ以上の部分に対する許可をユーザが拒否した場合、ユーザデータの当該部分に対する許可をユーザが提供するために、ユーザインターフェイスが提供されてもよい。ユーザインターフェイスは、データがどのように使用され得るかをユーザに示し、かつ／または、そのような許可を提供することが、たとえば、クライアントデバイス１２０の登録を可能にすることによって、ユーザに利益をもたらし得るという表示を提供し得る。代替的に、たとえば、ユーザがユーザデータへのアクセスの要求を却下する、または他の態様では許可の拒否を示す場合、ユーザデータにアクセスされないように、方法はブロック３０６で終了する。そのような場合、ブロック３１２～３２０は実行されない。

ブロック３１２で、受信者デバイス（たとえば、クライアントデバイス１２０～１２６のいずれか）において、無線キャリアからメッセージが受信される。たとえば、メッセージは、ＲＣＳプロトコルを介して受信されてもよい。いくつかの実現例では、メッセージは、セッション開始プロトコル（ＳＩＰ）メッセージとして受信されてもよい。いくつかの実現例では、ＳＩＰメッセージは、ＳＩＰ ＯＰＴＩＯＮＳメッセージでもよい。いくつかの実現例では、通知（たとえば、メッセージ配信サーバを経由して送信される、アプリケーションサーバからのアプリ通知）が、メッセージに、たとえば、ＳＩＰ ＯＰＴＩＯＮＳメッセージのコンテンツ本体に含まれてもよい。いくつかの実現例では、メッセージは、無線キャリアシステムと通信しているクライアントデバイスのデバイスモデムを経由して、クライアントデバイスのネットワークアクセス層で受信されてもよい。これらの実現例では、ソフトウェアアプリケーションとアプリケーションサーバとの間に、アクティブな接続（たとえば、ＴＬＳ接続または他のインターネットプロトコル接続などの安全な接続）が存在しない。

たとえば、特定のアプリケーション、たとえば、アプリＡ（１５２）、アプリＢ（１５４）等のためのアプリケーションサーバは、通知を生成し、メッセージ配信サーバ上のメッセージ配信アプリケーション（１０８）に送信してもよい。メッセージ配信サーバは、（たとえば、図２を参照して説明したような方法２００を用いて）通知がメッセージ配信サーバに登録されている受信者デバイスに関連付けられているかどうかを判断するために、（たとえば、データベース１０６において）データベースルックアップを実行してもよい。たとえば、データベースは、受信者識別子、たとえば、登録メッセージにおいて受信されたトークンに一致するレコードを含んでもよい。データベースレコードは、たとえば、｛トークン、デバイス識別子、公開鍵｝の形式のタプルを含んでもよく、公開鍵は登録メッセージに含まれ、デバイス識別子は登録メッセージで受信される電話番号でもよい。トークンは、アプリおよび通知対象デバイスを識別するために使用可能であり、登録プロセス中に受信するため（図２を参照して説明したように）、メッセージ配信サーバに既知である。

メッセージ配信サーバは、データベースルックアップに基づいて、通知内の受信者識別子（たとえば、トークン）がアプリケーションサーバから受信した通知内のトークンと一致すると判断することに基づいて、通知の受信者が公開鍵に関連付けられているかどうかを判断する。さらに、メッセージ配信サーバは、（トークンを含むデータベースタプルから）受信者デバイスに関連付けられた公開鍵を識別する。メッセージ配信サーバは、通知を公開鍵で暗号化することにより、メッセージを生成してもよい。メッセージ配信サーバは、受信者デバイスに関連付けられたデバイス識別子（たとえば電話番号または他の識別子）に基づいて、メッセージ（暗号化された通知を含む）を無線キャリア、たとえばキャリアメッセージングハブ（１６２）を含む無線キャリアシステム（１６０）に送信してもよい。いくつかの実現例では、メッセージ配信サーバ（１０４）から無線キャリアシステム（１６０）へのメッセージの送信は、ＲＣＳプロトコルを使用して実行されてもよい。これらの実現例では、メッセージ配信サーバは、メッセージを無線キャリアシステムに送信する前に、（たとえば、適切なメッセージヘッダなどを含むように）メッセージをＲＣＳメッセージとしてフォーマットしてもよい。これにより、無線キャリアシステムは、ＲＣＳに準拠するようにメッセージをフォーマットする操作を行うことなく、メッセージ配信サーバから受信したメッセージをＲＣＳプロトコルを用いてクライアントデバイスに転送することができるので、無線キャリアシステムの統合要件を削減することができる。さらに、これにより、通知を生成するサーバ（たとえば、アプリＡサーバ１４２、アプリＢサーバ１４４等）に変更を加えることなく、ＲＣＳプロトコルをメッセージ配信に使用することが保証される。

無線キャリアは、（たとえば、順番に）受信者デバイスにメッセージを配信してもよい。たとえば、キャリアメッセージングハブ（１６２）は、たとえば、ＲＣＳプロトコルを使用して、メッセージを受信者デバイスに送信してもよい。メッセージは、受信者デバイスがウェイクアップ動作なしにメッセージを受信するように、ネットワークアクセス層を介して送信されてもよい。いくつかの実現例では、メッセージ配信サーバおよび無線キャリアは、高性能ネットワークアクセス層と組合わせてＲＣＳの高信頼性アーキテクチャを活用するメッセージ配信を可能にし得る、ＲＣＳ用のピアリング接続を維持してもよい。

いくつかの実現例では、同じトークンが複数の受信者デバイスに関連付けられる場合がある。たとえば、通知を受信するアプリは、（ＲＣＳメッセージング用に構成された）携帯電話、および１つ以上の他のデバイス、たとえば、ＲＣＳメッセージング用に構成されていない携帯電話、ラップトップコンピュータ、タブレット、またはセルラー通信機能を含まない他のデバイス等にもインストール可能なソフトウェアアプリケーションでもよい。１つ以上のそのような受信者デバイスがアプリケーションサーバから受信した通知内のトークンに関連付けられている場合、メッセージ配信サーバは、通知を（公開鍵を用いた暗号化なしで）そのような１つ以上のデバイスに送信してもよい。ブロック３１２の後に、ブロック３１４が続く場合がある。

ブロック３１４で、受信されたメッセージは、メッセージを受信した受信者デバイスにローカルに格納された秘密鍵を用いて復号される。メッセージ配信サーバは、受信者識別子（たとえば、トークン）に基づいて識別される公開鍵を用いてメッセージを暗号化するので、秘密鍵は、公開鍵とともに鍵ペアの一部であり、メッセージを復号するために利用可能である。ブロック３１４の後に、ブロック３１６が続く場合がある。

ブロック３１６で、復号されたメッセージに関連付けられた受信者デバイス上で実行されるソフトウェアアプリケーションを識別する。たとえば、アプリの識別は、メッセージに含まれるトークンに基づいてもよい。ブロック３１６の後に、ブロック３１８が続く場合がある。

ブロック３１８で、通知（復号されたメッセージ）がソフトウェアアプリケーションに配信される。たとえば、メッセージを復号するメッセージングアプリおよび／または通知コアは、任意の適切なメカニズム、たとえば、アプリケーションへのアプリケーションプログラミングインターフェイス（ＡＰＩ）呼び出しを経由して、ソフトウェアアプリケーションに通知を配信することができる。いくつかの実現例では、メッセージを配信することは、特定のアプリケーションをウェイクアップすること（アプリケーションが非アクティブである場合）、アプリケーションを起動すること（実行中でない場合）などを含み得る。ブロック３１８の後に、ブロック３２０が続く場合がある。

ブロック３２０で、確認メッセージをメッセージ配信サーバに送信する。たとえば、確認メッセージは、メッセージの受信の成功、メッセージの復号の成功、またはソフトウェアアプリケーションへのメッセージの配信の成功のうちの１つ以上を示すものとして機能し得る。いくつかの実現例では、確認メッセージは、ＲＣＳプロトコルを介して配信される「ＳＩＰ ２００ ＯＫ」メッセージでもよい。確認メッセージは、メッセージが受信者デバイスで正常に受信および／または処理されたことを示す役割を果たし得る。いくつかの実現例では、メッセージ配信サーバは、確認メッセージを受信すると、通知が正常に配信されたことを（通知を生成した）アプリケーションサーバに送信してもよい。

方法３００のさまざまなブロックは、組合わされてもよい、複数のブロックに分割されてもよい、または、並行して実行されてもよい。たとえば、ブロック３１４および３１６は、並行して実行されてもよい。方法３００、またはその一部は、任意の回数繰り返されてもよく、たとえば、任意の数のメッセージを受信してもよい。

図４は、いくつかの実現例に係る、デバイス登録および通知の配信を示すフロー図である。通知の配信は、ネットワーク環境、たとえばネットワーク環境１００で行われ得る。

デバイス登録プロセスにおいて、アプリＡ１５２は、メッセージングアプリ１５６にトークンを送信してもよい（４０１）。たとえば、アプリＡ１５２は、トークンを使用して配信アプリケーション１０８を経由して、アプリＡサーバ１４２から通知を受信するように構成されてもよく、たとえば、通知は、アプリＡ１５２の特定のインスタンス（他のクライアントデバイスではなく、クライアントデバイス１２０上で実行される）を識別するのに役立つトークンを含んでもよい。いくつかの実現例では、トークンは、アプリＡサーバ１４２によって生成され、インターネットを介して特定のインスタンスアプリＡ１５２に提供されてもよい。

さまざまな実現例において、メッセージングアプリ１５６は、オペレーティングシステムと共に提供されてもよい、デバイス製造者によってプリインストールされてもよい、または、クライアントデバイスのユーザによってインストールされてもよい。メッセージングアプリ１５６は、無線キャリアから、たとえばキャリアメッセージングハブ１６２から受信したメッセージを処理し、無線キャリアを経由して他のクライアントデバイスにメッセージを送信するように構成されていてもよい。たとえば、メッセージングアプリケーション１５６は、ＲＣＳプロトコルメッセージを送受信可能なアプリケーションでもよい。無線キャリアとのメッセージ交換は、無線キャリアシステム１６０と通信するデバイスモデムを介して行われてもよく、アプリケーションがインターネットを介して通信するために利用し得るネットワーク通信スタックの上位層ではなく、デバイスのネットワークアクセス層を利用してもよい。

メッセージングアプリ１５６は、登録メッセージ（４０２）を生成し、通知コア１５８に送信してもよい。いくつかの実現例では、登録メッセージは、トークン、デバイス識別子（たとえば、クライアントデバイスに関連付けられた電話番号）、およびアプリケーションに関連付けられた公開鍵（たとえば、図２を参照して説明したように生成されている）を含んでもよい。

いくつかの実現例では、通知コア１５８は、クライアントデバイス１２０にインストールされた１つまたは複数のアプリと通信するように構成された通知処理ソフトウェアを含んでもよい。いくつかの実現例では、通知コア１５８およびメッセージングアプリ１５６は、単一のソフトウェアアプリケーションとして実現されてもよい。

通知コア１５８は、配信アプリケーション１０８にデバイス登録（４０４）を行ってもよい。たとえば、通知コア１５８は、インターネットを介して（たとえば、インターネットプロトコルを使用して）登録メッセージを配信アプリケーション（１０８）に送信してもよい。配信アプリケーション１０８は、メッセージ配信サーバ（たとえば、サーバ装置１０４）で実現されてもよい。いくつかの実現例では、メッセージ配信サーバは、１つ以上のアプリケーションサーバ、たとえば、アプリＡサーバ（１４２）、アプリＢサーバ（１４４）、および／または追加のアプリサーバと通信するように構成されてもよい。

登録メッセージを受信するアプリケーションサーバ（１４２）は、登録メッセージを用いてデータベースレコードを作成（または更新）してもよい。たとえば、データベースレコードは、｛トークン、デバイス識別子、公開鍵｝という形式のタプルを含んでもよい。

アプリケーションサーバは、通知を生成するように構成されてもよい。たとえば、アプリケーションサーバは、電子メールアプリケーション、チャットアプリケーション、ゲーム、ビデオ通話アプリケーションなど、クライアントデバイス上で実行されるソフトウェアアプリケーションに関連付けられている場合がある。通知は、このようなアプリケーションのイベントに基づいて生成されてもよい。たとえば、電子メールアプリケーション用のアプリケーションサーバは、ユーザが新しい電子メールを受信すると通知を生成してもよい、チャットアプリケーションは、チャットメッセージの受信に応答して通知を生成してもよい、などである。それぞれのアプリケーション用のアプリケーションサーバは、たとえば、クライアントデバイスにインストールされたアプリケーションを経由して提供されるように、通知を生成してもよい。

図４に示す例では、アプリＡサーバ（１４２）は、配信アプリケーション１０８にトークンを含む通知を送信してもよい（４０６）。いくつかの実現例では、通知の少なくとも一部（たとえば、ユーザに表示されるコンテンツ）は、通知を配信アプリケーションに送信する前に暗号化されてもよい。配信アプリケーション１０８は、通知内のトークンを使用してデータベースルックアップを実行して、受信者デバイスがトークンに基づいて識別されるかどうかを判断してもよい。たとえば、データベースルックアップは、通知内のトークンをデータベースに格納されたトークンと照合して、デバイス識別子および公開鍵を取得することを含んでもよい。

受信者デバイスが識別される場合、配信アプリケーション１０８は、メッセージを生成するために通知にエンベロープを追加してもよい（４１０）。たとえば、配信アプリケーション１０８は、たとえば、受信者デバイスから登録メッセージで受信したような、受信者に関連付けられた公開鍵を使用して、通知を暗号化してもよい。エンベロープを追加すること（通知を暗号化すること）は、対応する秘密鍵を格納している受信者デバイスのみが通知を取得するようにメッセージを復号することができるので、安全な配信を保証することができる。いくつかの実現例では、メッセージ配信サーバ（１０４）から無線キャリアシステム（１６０）へのメッセージの送信は、ＲＣＳプロトコルを用いて実行されてもよい。これらの実現例では、エンベロープを追加することは、メッセージ配信サーバが、メッセージを無線キャリアシステムに送信する前に、メッセージをＲＣＳメッセージとしてフォーマットするため、たとえば、適切なメッセージヘッダおよび／または他の情報を含むための動作を実行することを含んでもよい。メッセージを無線キャリアシステムに送信する前にメッセージをＲＣＳメッセージとしてフォーマットすることは、無線キャリアシステムがＲＣＳに準拠するようにメッセージをフォーマットする操作を実行しなくても、メッセージ配信サーバから受信したメッセージをＲＣＳプロトコルを使用してクライアントデバイスに転送することができるので、無線キャリアシステムの統合要件を削減または排除する利点を有する。

配信アプリケーション１０８は、メッセージを無線キャリア、たとえば、キャリアメッセージングハブ（１６２）に送信してもよい（４０８）。いくつかの実現例では、メッセージ配信サーバ（１０４）と無線キャリアシステム（１６０）との間にピアリング接続が確立されて、メッセージ配信を可能にしてもよい。配信アプリケーション１０８は、データベースルックアップにおいて識別されたデバイス識別子（たとえば、電話番号）に基づいて、無線キャリアシステムを識別してもよい。

無線キャリアシステム１６０におけるキャリアメッセージングハブ１６２は、メッセージを受信者デバイスに、たとえば、メッセージングアプリ１５６に配信してもよい（４１２）。たとえば、メッセージは、ネットワークアクセス層を経由してＲＣＳプロトコルを介して配信されてもよい。キャリアメッセージングハブ１６２からメッセージングアプリ１５６へのメッセージ配信は、ネットワークアクセス層を介して行われてもよく、たとえば、キャリアシステム１６０は、ＲＣＳメッセージを受信者デバイスに送信してもよく、受信者デバイスのモデムは、メッセージを受信し、モデムを経由してメッセージを受信するように構成されているメッセージングアプリ１５６に知らせてもよい。いくつかの実現例では、メッセージは、ＳＩＰ ＯＰＴＩＯＮＳメッセージとして送信されてもよい。メッセージの一例を以下に示す。

ＯＰＴＩＯＮＳ ｔｅｌ：＋１２２２３３３ｘｘｘｘ ＳＩＰ／２．０
Ｆｒｏｍ：ｓｉｐ：ａｐｐ＠ｍｅｓｓａｇｅｄｅｌｉｖｅｒｙｓｅｒｖｅｒ．ｃｏｍ
Ｐ－Ａｓｓｅｒｔｅｄ－Ｉｄｅｎｔｉｔｙ：ｓｉｐ：ａｐｐ＠ｍｅｓｓａｇｅｄｅｌｉｖｅｒｙｓｅｒｖｅｒ．ｃｏｍ
Ｔｏ：ｔｅｌ：＋１－２２２３３３ｘｘｘｘ
Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ： ２３
Ｃｏｎｔｅｎｔ－Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ－ｔｙｐｅ／ｘ－ｅｎｃｒｙｐｔｅｄ－ｎｏｔｉｆｉｃａｔｉｏｎ
<ＥＮＣＲＹＰＴＥＤ―ＭＥＳＳＡＧＥ>
上記メッセージ例において、「＋１２２２３３３ｘｘｘｘ」は受信者装置の電話番号であり、「ａｐｐ＠ｍｅｓｓａｇｅｄｅｌｉｖｅｒｙｓｅｒｖｅｒ．ｃｏｍ」は配信アプリケーション（たとえば、配信アプリケーション１０８）のことを言う。「＜ＥＮＣＲＹＰＴＥＤ―ＭＥＳＳＡＧＥ＞」は、配信アプリケーションによって暗号化された状態のメッセージを含む。

いくつかの実現例では、メッセージは、ＳＩＰ ＮＯＴＩＦＹメッセージとして送信されてもよい。たとえば、クライアントデバイスは、ＳＩＰ ＳＵＢＳＣＲＩＢＥを利用して、リモートノード（たとえば、無線キャリアシステム１６０）から現在の状態および／または状態の更新を要求してもよい。そのような要求が受信されると、リモートノードは、たとえば、配信アプリケーション１０８からの通知を含むメッセージの受信に基づいて現在の状態の変化が生じたという判断に応答して、ＳＩＰ ＮＯＴＩＦＹメッセージを送信してもよい。

メッセージを受信すると、メッセージングアプリ１５６は、通知内容を取得するためにエンベロープを除去してもよい（４１４）。エンベロープの除去は、格納された秘密鍵を使用してメッセージを復号することを含んでもよい。エンベロープの除去後、メッセージングアプリ１５６は、通知を通知コア（１５８）に送信してもよい（４１６）。

通知コア１５８は、たとえば、通知内のトークンを特定のアプリケーション、たとえば、アプリＡ１５２に関連付けられたトークンと照合することに基づいて、通知に関連付けられたアプリを識別してもよい（４１８）。アプリを識別すると、通知コアは、通知をアプリに配信してもよい（４２０）。

アプリＡ１５２は、さまざまな方法で通知を処理してもよい。たとえば、通知がアプリケーションサーバによって暗号化される場合、通知を処理することは、通知を復号することを含んでもよい。これらの実現例において、アプリＡ１５２は、任意の従来の技術を使用して、アプリＡサーバ１４２と共有秘密を確立し、通知を復号するために共有秘密を利用してもよい。アプリＡ１５２は、通知内容に基づいてユーザに通知（たとえば、「Ａｌｙｓｓａからの新しい電子メールがあります」）してもよい、または、他の動作を実行してもよい。

配信アプリケーション１０８が受信者デバイスを識別できない状況で、たとえば、通知内のアプリトークンが任意のデータベースレコードと一致しない場合、配信アプリケーション１０８は、キャリアメッセージングハブまたはデバイス識別子（電話番号）を利用しない従来のメカニズムによって、たとえば、インターネットを経由して、アプリＡに通知を配信してもよい。さらに、配信アプリケーション１０８は、たとえば、ユーザが、キャリアネットワークに結合されていないラップトップまたはタブレットコンピュータ、ウェアラブルデバイスといった、無線キャリアを経由してメッセージを受信することができないデバイス上で実行しているアプリケーションを有する場合、通知を追加のユーザデバイスに配信してもよい。このような場合、通知内のトークンを利用して、通知を配信してもよい。たとえば、（たとえば、データベースレコードと一致しない）そのようなデバイスを実行するアプリケーションは、アプリケーションサーバが通知を配信できるように、インターネットを介してアプリケーションサーバと接続、たとえば、トランスポートレイヤーセキュリティ（ＴＬＳ）接続などの安全な接続を確立するように構成されてもよい。

記載された技術は、クライアントデバイスと、アプリケーションサーバによって生成された通知をクライアントデバイスに配信するメッセージ配信サーバとの間、またはクライアントデバイスとアプリケーションサーバとの間で安全な接続を確立し維持する従来の通知技術の技術的欠点に対処する。そのような通知技術は、典型的には、インターネット公衆データネットワーク（ＰＤＮ）を介したオーバーザトップ（ＯＴＴ）トランスポートレイヤーセキュリティ（ＴＬＳ）接続を使用する。

このような構成には、無線キャリアバックエンドにおけるネットワークアドレス変換（ＮＡＴ）のタイムアウトが発生し、不活性状態（たとえば、無線キャリアが設定した閾値より長い期間、クライアントデバイスと無線キャリアシステムとの間で安全な接続を介してインタラクションが行われないこと）に起因して、安全な接続が終了することがあるという技術的な問題が存在する。このような接続の終了を回避するために、クライアントデバイス（通知を受信するアプリケーション）は、定期的にキープアライブメッセージを送信することが要求される。このようなメッセージの送信には、無線送信機（およびクライアントデバイスのモデムを含む関連回路）をウェイクアップする必要がある。このような無線送信機のウェイクアップおよび使用は、電力を浪費する可能性がある。バッテリ駆動のデバイスでは、このようなアクティビティによってデバイスのバッテリが消耗する可能性がある。さらに、キープアライブメッセージは、無線キャリアのセルラーネットワークの輻輳につながる可能性がある。

本明細書に記載する技術では、クライアントデバイス（たとえば、携帯電話または他のセルラー通信デバイス）と無線キャリアシステムとの間の単一登録メッセージングを利用して、（たとえば、アプリ通知を含む）メッセージを配信する。たとえば、リッチコミュニケーションサービス（ＲＣＳ）プロトコルは、メッセージ配信のために使用されてもよい。

無線キャリアは通常、Ｖｏｉｃｅ―ｏｖｅｒ―ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）経由でクライアントデバイスと無線キャリアシステムとの間で通信するためのクライアントデバイス登録、およびＩＰマルチメディア（コアネットワーク）サブシステムＰＤＮ（ＩＭＳ ＰＤＮ）上の単一のＩＰセキュリティ（ＩＰＳｅｃ）ソケットを介したＲＣＳ登録を共有する。クライアントデバイスは、携帯電話通信のためにＩＭＳネットワークへの接続を維持する。

本明細書に記載された技術により、（図２および図４を参照して説明したように）デバイス登録が成功すると、このような接続は、（図３および図４を参照して説明したように）クライアントデバイス上のアプリケーションへのメッセージ配信に利用される。ＴＬＳ（または他の安全なＯＴＴ接続）を確立し、かつ、その状態を保ち続けるオーバーヘッドを排除することによって、記載された技術は、クライアントデバイスを定期的にウェイクアップする必要、またはメッセージを送信する必要を排除し、それによって電力消費を低減し、電池寿命を改善し、無線（セルラー）ネットワーク上のネットワークの輻輳を低減する。また、記載された技術は、クライアントデバイスが準最適なインターネット接続を有する場合に、通知配信の信頼性および性能を改善することができる。

さらに、ＩＭＳネットワークの重要な利点は、ネットワークアドレス変換がなく、インターネットプロトコルバージョン６（ＩＰｖ６）で展開されることである。記載された技術は、アプリ通知の確実な配信を可能にするデバイス登録を実行することによって、ＩＭＳ ＰＤＮのこの特徴を有利に利用する。ＩＭＳ ＰＤＮを経由したメッセージ配信の技術的な問題は、ＩＭＳ ＰＤＮが、しばしば、アプリケーションサーバおよび／またはメッセージ配信サーバへの直接接続を禁止するファイアウォール環境に展開されることである。さらに、クライアントデバイスのデバイスオペレーティングシステムは、このような接続がクライアントデバイスのハードウェア（たとえば、デバイスモデム）によって管理されることがあるため、ＩＭＳ ＰＤＮへの露出が制限されることがある。記載された技術は、デバイス登録を実行し、トークン、デバイス識別子、および公開鍵などの情報を含む、登録されたデバイスのデータベースを使用することによって、この問題を克服する。

さらに、記載された技術は、有利に、安全なＯＴＴ接続の確立を必要とせずに、アプリ通知が無線キャリアネットワークを介して安全に送信されることを保証するために公開鍵暗号を使用する。特に、クライアントデバイスは、メッセージ配信サーバ（または通知を生成する他のサーバ）が通知を暗号化するために使用する公開鍵を提供する。暗号化されたメッセージは、メッセージコンテンツ（たとえば、アプリ通知）のセキュリティを損なうことなく、通常の通信チャネル（たとえば、非暗号化）を介して送信することができる。クライアントデバイスに安全に格納されている秘密鍵は、メッセージを復号し、通知を取得し、クライアントデバイス上のそれぞれのアプリケーションに提供するために利用される。

図５は、本明細書に記載される１つ以上の特徴を実現するために使用され得るデバイス５００の例を示すブロック図である。一例では、デバイス５００は、クライアントデバイス、たとえば、図１に示されるクライアントデバイス１２０～１２６のいずれかを実現するために使用されてもよい。または、デバイス５００は、サーバ装置、たとえばサーバ装置１０４、または無線キャリアシステム１６０を実現可能である。いくつかの実現例では、デバイス５００は、クライアントデバイス、サーバ装置、またはクライアントデバイスおよびサーバ装置の両方を実現するために使用されてもよい。デバイス５００は、上述したように、任意の適切なコンピュータシステム、サーバ、または他の電子もしくはハードウェアデバイスであり得る。

本明細書に記載される１つ以上の方法は、任意のタイプのコンピューティングデバイス上で実行可能なスタンドアロンプログラム、ウェブブラウザ上で実行されるプログラム、モバイルコンピューティングデバイス（たとえば、携帯電話、スマートフォン、タブレットコンピュータ、ウェアラブルデバイス（腕時計、アームバンド、宝石、ヘッドウェア、仮想現実ゴーグルまたは眼鏡、拡張現実ゴーグルまたは眼鏡、ヘッドマウントディスプレイ等）、ラップトップコンピュータ、サーバコンピュータ等）上で実行されるモバイルアプリケーション（「アプリ」）において実行可能である。

いくつかの実現例では、デバイス５００は、プロセッサ５０２、メモリ５０４、Ｉ／Ｏ（入出力）インターフェイス５０６、およびモデム５１６を含む。プロセッサ５０２は、プログラムコードを実行し、デバイス５００の基本動作を制御するための１つもしくは複数のプロセッサおよび／または処理回路であり得る。「プロセッサ」は、データ、信号または他の情報を処理する任意の適切なハードウェアシステム、メカニズムまたは構成要素を含む。プロセッサは、１つ以上のコアを有する汎用中央処理装置（ＣＰＵ）（たとえば、シングルコア、デュアルコア、またはマルチコア構成）、（たとえば、マルチプロセッサ構成の）複数の処理装置、グラフィックス・プロセッシング・ユニット（ＧＰＵ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、複合プログラマブル論理デバイス（ＣＰＬＤ）、機能実現専用回路、ニューラルネットワークモデルベース処理を実現する専用プロセッサ、ニューラル回路、行列計算（たとえば、行列乗算）に最適なプロセッサ、または他のシステムを含んでもよい。

いくつかの実現例では、プロセッサ５０２は、ニューラルネットワーク処理を実現する１つまたは複数のコプロセッサを含んでもよい。いくつかの実現例では、プロセッサ５０２は、確率的出力を生成するためにデータを処理するプロセッサでもよく、たとえば、プロセッサ５０２によって生成される出力は不正確であってもよい、または、期待される出力からの範囲内で正確でもよい。処理は、特定の地理的位置に限定される必要はない、または、時間的な制限を有する必要もない。たとえば、プロセッサは、「リアルタイム」、「オフライン」、「バッチモード」などでその機能を実行してもよい。処理の一部は、異なる時間に異なる場所で、異なる（または同じ）処理システムによって実行されてもよい。コンピュータは、メモリと通信している任意のプロセッサでもよい。

メモリ５０４は、典型的には、プロセッサ５０２によるアクセスのために装置５００に設けられ、プロセッサによる実行のための命令を格納するのに適した、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電気消去可能読取専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリなどの任意の適切なプロセッサ読取可能記憶媒体でもよく、プロセッサ５０２から分離して、および／またはそれと統合されて配置されてもよい。メモリ５０４は、オペレーティングシステム５０８、メッセージングアプリケーション５１０（たとえば、図１のメッセージングアプリケーション１５６と同じでもよい）、他のアプリケーション５１２、およびアプリケーションデータ５１４を含む、プロセッサ５０２によってサーバ装置５００上で動作するソフトウェアを格納することができる。メッセージングアプリケーション５１０は、無線キャリアネットワークを介して（たとえば、ネットワークアクセス層を介したモデム５１６で）メッセージを受信すると、メッセージングアプリケーション５１０が自動的に呼び出されるように、キャリアメッセージングのデフォルトのアプリケーションとして構成されてもよい。

他のアプリケーション５１２は、データ表示エンジン、ウェブホスティングエンジン、マップアプリケーション、画像表示エンジン、通知エンジン（たとえば、通知コア１５８を実現してもよい）、ソーシャルネットワーキングエンジンなどのアプリケーションを含んでもよい。いくつかの実現例では、メッセージングアプリケーション５１０は、プロセッサ５０２が本明細書に記載の機能、たとえば図２、図３または図４の方法の一部または全てを実行することを可能にする命令を含み得る。他のアプリケーション５１２（アプリＡ１５２およびアプリＢ１５４を含み得る）は、たとえば、地図アプリケーション、画像編集アプリケーション、メディア表示アプリケーション、通信アプリケーション、ウェブホスティングエンジンまたはアプリケーション、通知エンジン、メディア共有アプリケーション等を含み得る。本明細書に開示される１つ以上の方法は、たとえば、任意のタイプのコンピューティングデバイス上で実行可能なスタンドアロンコンピュータプログラムとして、ウェブページを有するウェブアプリケーションとして、モバイルコンピューティングデバイス上で実行されるモバイルアプリケーション（「アプリ」）としてなど、複数の環境およびプラットフォームで動作可能である。

メモリ５０４内の任意のソフトウェアは、代替的に、任意の他の適切な記憶場所またはコンピュータ読取可能媒体に格納することができる。さらに、メモリ５０４（および／または他の接続されたストレージデバイス（複数可））は、１つもしくは複数のメッセージ、１つもしくは複数の分類法、電子百科事典、辞書、デジタルマップ、類義語、知識ベース、メッセージデータ、文法、ユーザプリファランス、および／または本明細書に記載の特徴で使用する他の命令とデータとを格納可能である。メモリ５０４および任意の他のタイプのストレージ（磁気ディスク、光ディスク、磁気テープ、または他の有形媒体）は、「ストレージ」または「ストレージデバイス」と考えることができる。

入出力インターフェイス５０６は、サーバ装置５００を他のシステムおよびデバイスとインターフェイス接続することを可能にする機能を提供可能である。インターフェイス接続されたデバイスを、デバイス５００の一部として含むことが可能であり、または、別個であり、デバイス５００と通信することが可能である。たとえば、ネットワーク通信デバイスと、ストレージデバイス（たとえば、メモリおよび／またはデータベース）と、入力／出力デバイスとは、入出力インターフェイス５０６を経由して通信することができる。いくつかの実現例では、入出力インターフェイスは、入力デバイス（キーボード、ポインティングデバイス、タッチスクリーン、マイク、カメラ、スキャナ、センサ等）および／または出力デバイス（表示デバイス、スピーカデバイス、プリンタ、モータ等）などのインターフェイスデバイスに接続可能である。

入出力インターフェイス５０６に接続可能なインターフェイス接続されたデバイスのいくつかの例は、コンテンツ、たとえば、画像、ビデオ、および／または本明細書に記載するようなアプリケーションのユーザインターフェイスを表示するために使用可能な１つまたは複数の表示デバイス５２０を含み得る。表示デバイス５２０は、ローカル接続（たとえば、ディスプレイバス）を経由して、および／またはネットワーク接続を経由して、デバイス５００に接続可能であり、任意の適切な表示デバイスであり得る。表示デバイス５２０は、ＬＣＤ、ＬＥＤ、またはプラズマ表示画面、ＣＲＴ、テレビ、モニター、タッチスクリーン、３Ｄ表示画面、または他の視覚表示デバイスなどの任意の適切な表示デバイスを含み得る。表示デバイス５２０はまた、入力デバイス、たとえばタッチスクリーン入力デバイスとして機能してもよい。たとえば、表示デバイス５２０は、モバイルデバイス上で提供されるフラットディスプレイ画面、眼鏡もしくはヘッドセットデバイスにおいて提供される複数のディスプレイ画面、またはコンピュータデバイスのモニタ画面であり得る。

入出力インターフェース５０６は、他の入出力デバイスとインターフェイス接続可能である。いくつかの例は、画像の取込み、および／またはジェスチャの検出が可能な１つもしくは複数のカメラを含む。いくつかの実現例は、（たとえば、取込まれた画像、音声コマンドなどの一部として）音を取込むためのマイク、ジェスチャを検出するためのレーダーまたは他のセンサ、音を出力するためのオーディオスピーカデバイス、または他の入力および出力デバイスを提供可能である。

モデム５１６は、無線キャリアシステム（たとえば、無線キャリアシステム１６０）と通信するように構成されたセルラーモデムでもよい。異なる実現例において、モデム５１６は、プロセッサ５０２と同じチップもしくはダイ上に実現されてもよい、または、別個のハードウェアとして実現されてもよい。モデム５１６は、ネットワークアクセス層を介した無線キャリアシステムと通信可能でもよい。いくつかの実現例では、モデム５１６は、メッセージングアプリケーション５１０によって提供されるメッセージを、たとえばＲＣＳプロトコルを介して送信するように構成されてもよい。いくつかの実現例では、モデム５１６は、たとえば、ＲＣＳプロトコルを介してメッセージを受信し、メッセージをメッセージングアプリケーション５１０に提供するように構成されてもよい。

図５では、説明を容易にするために、プロセッサ５０２、メモリ５０４、入出力インターフェイス５０６、ならびにソフトウェアブロック５０８，５１０および５１２の各々について１つのブロックを示している。これらのブロックは、１つもしくは複数のプロセッサまたは処理回路、オペレーティングシステム、メモリ、入出力インターフェイス、アプリケーション、および／またはソフトウェアモジュールを表してもよい。他の実現例では、デバイス５００は、示されたすべての構成要素を有していなくてもよい、および／または、本明細書に示された要素の代わりに、もしくはそれらに加えて、他のタイプの要素を含む他の要素を有してもよい。いくつかの構成要素は、本明細書でいくつかの実現例で説明されるようなブロックおよび動作を実行するものとして説明されているが、環境１００、デバイス５００、類似のシステム、またはそのようなシステムに関連付けられた任意の適切な１つもしくは複数のプロセッサの任意の適切な構成要素または構成要素の組合せは、説明したブロックおよび動作を実行し得る。

コンピューティングデバイス５００は、さまざまな構成で、ここで図５に示されている追加のハードウェアおよび／またはソフトウェアを含んでもよい。たとえば、コンピューティングデバイス５００が無線キャリアシステムを実現するために利用される場合、それは、キャリアメッセージングハブ（１６２）を実現してもよく、無線通信ハードウェアを含んでもよい。他の例では、コンピューティングデバイス５００がメッセージ配信サーバを実現するために利用される場合、コンピューティングデバイス５００は、配信アプリケーション１０８を実現し、および／またはデータベース１０６を格納してもよい。

本明細書に記載される方法は、コンピュータ上で実行可能なコンピュータプログラム命令またはコードによって実現可能である。たとえば、コードは、１つもしくは複数のデジタルプロセッサ（たとえば、マイクロプロセッサまたは他の処理回路）によって実現可能であり、非一時的なコンピュータ読取可能媒体（たとえば、記憶媒体）、たとえば、半導体もしくはソリッドステートメモリ、磁気テープ、取外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、フラッシュメモリ、磁気ハードディスク、光ディスク、ソリッドステートメモリドライブなどの磁気、光、電磁、または半導体記憶媒体などを含むコンピュータプログラム製品に格納可能である。プログラム命令はまた、たとえば、サーバ（たとえば、分散システムおよび／またはクラウドコンピューティングシステム）から配信されるサービスとしてのソフトウェア（ＳａａＳ）の形態で、電子信号に含まれ、電子信号として提供され得る。または、１つもしくは複数の方法は、ハードウェア（論理ゲート等）で、またはハードウェアとソフトウェアとの組合わせで実現可能である。ハードウェアの例は、プログラマブルプロセッサ（たとえば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、複合プログラマブル論理デバイス）、汎用プロセッサ、グラフィックスプロセッサ、および特定用途向け集積回路（ＡＳＩＣ）等であり得る。１つもしくは複数の方法は、システム上で実行されるアプリケーションの一部もしくは構成要素として、または他のアプリケーションおよびオペレーティングシステムと連動して実行されるアプリケーションもしくはソフトウェアとして、実行可能である。

特定の実現例に関して説明したが、これらの特定の実現例は例示に過ぎず、制限的なものではない。例に説明された概念は、他の例および実現例に適用することができる。

上記の説明に加えて、ユーザには、本明細書に記載のシステム、プログラム、または機能がユーザ情報（たとえば、ユーザのソーシャルネットワーク、ソーシャルアクション、または活動、職業、ユーザの好み、またはユーザの現在の場所に関する情報）の収集を可能にするか否か、およびユーザがサーバからコンテンツまたは通信を送信されるか否かの両方について選択することを可能にするコントロールが設けられる場合がある。さらに、特定のデータは、保存または使用される前に、個人を特定可能な情報が削除されるように、一つまたは複数の方法で処理されることがある。たとえば、ユーザの身元を処理して、ユーザについて個人を特定可能な情報を判断できないようにすることができる、または、ユーザの地理的位置を一般化して位置情報を取得して（都市、郵便番号、州レベル等）、ユーザの特定の位置を判断できないようにすることができる。このように、ユーザは、ユーザについてどのような情報が収集されるか、その情報がどのように使用されるか、およびどのような情報がユーザに提供されるかを制御し得る。

本開示に記載の機能ブロック、動作、特徴、方法、装置、およびシステムは、当業者に知られているように、システム、装置、および機能ブロックの異なる組合わせに統合または分割することができることに留意されたい。特定の実現例のルーチンを実現するために、任意の適切なプログラミング言語およびプログラミング技術が使用されてもよい。異なるプログラミング技術、たとえば、手続き型またはオブジェクト指向型が採用されてもよい。ルーチンは、単一の処理装置で実行されてもよい、または、複数の処理装置で実行されてもよい。ステップ、動作、または計算が特定の順序で示される場合があるが、その順序は異なる特定の実現例で変更されてもよい。いくつかの実現例では、本明細書で順次として示される複数のステップまたは動作が、同時に実行されてもよい。

Claims (15)

1. 受信者デバイスにおいて、アプリケーションサーバからの通知を含むメッセージを、無線キャリアから受信することと、
   前記受信者デバイスにおいてローカルに格納された秘密鍵を用いて、前記メッセージを復号することと、
   前記通知を含む復号された前記メッセージに関連付けられた前記受信者デバイスに対して実行されるソフトウェアアプリケーションを識別することと、
   復号された前記メッセージを、前記ソフトウェアアプリケーションに配信することとを備える、コンピュータによって実現される方法。
2. 前記受信者デバイスは、前記無線キャリアによって操作されるセルラーネットワークに結合された無線デバイスであり、前記メッセージを受信することは、リッチコミュニケーションサービス（ＲＣＳ）プロトコルを介して前記メッセージを受信することを含む、請求項１に記載のコンピュータによって実現される方法。
3. 前記復号の後に、確認メッセージを前記無線キャリアに送信することをさらに備える、請求項１または２に記載のコンピュータによって実現される方法。
4. 前記メッセージを受信する前に、
   前記受信者デバイスにおいて、公開鍵と秘密鍵とを含む暗号鍵ペアを生成することと、
   前記秘密鍵を、前記受信者デバイスのローカルストレージに格納することと、
   前記公開鍵を含む登録メッセージを、インターネットを介してメッセージ配信サーバに送信することとをさらに備える、請求項１、２または３に記載のコンピュータによって実現される方法。
5. 前記登録メッセージはさらに、前記ソフトウェアアプリケーションに関連付けられたトークンを含み、前記ソフトウェアアプリケーションを識別することは、復号された前記メッセージ内の受信されたトークンが前記ソフトウェアアプリケーションに関連付けられた前記トークンに一致するという判断に基づく、請求項４に記載のコンピュータによって実現される方法。
6. デバイスであって、
   プロセッサと、
   前記デバイスを無線キャリアに結合するように動作可能なモデムと、
   前記プロセッサに結合されたメモリとを備え、前記メモリは、前記プロセッサによって実行されると、前記プロセッサに動作を行わせる命令を格納し、前記動作は、
   アプリケーションサーバからの通知を含むメッセージを、無線キャリアから受信することと、
   秘密鍵を用いて前記メッセージを復号することと、
   前記通知を含む復号された前記メッセージに関連付けられたソフトウェアアプリケーションを識別することと、
   復号された前記メッセージを、前記ソフトウェアアプリケーションに配信することとを含む、デバイス。
7. 前記デバイスは、前記無線キャリアによって操作されるセルラーネットワークに結合され、前記メッセージを受信することは、リッチコミュニケーションサービス（ＲＣＳ）プロトコルを介して前記メッセージを受信することを含む、請求項６に記載のデバイス。
8. 前記メッセージは、セッション開始プロトコル（ＳＩＰ）メッセージとして受信され、任意に、前記ＳＩＰメッセージはＳＩＰ ＯＰＴＩＯＮＳメッセージであり、前記通知は、前記ＳＩＰ ＯＰＴＩＯＮＳメッセージのコンテンツ本体に含まれる、請求項２に記載の方法または請求項１０に記載のデバイス。
9. 前記メッセージは、前記無線キャリアと通信する前記モデムを経由して、前記デバイスのネットワークアクセス層において受信され、アクティブな接続は前記ソフトウェアアプリケーションと前記アプリケーションサーバとの間に存在しない、請求項１、２もしくは８に記載の方法、または請求項６、７および８に記載のデバイス。
10. 前記動作はさらに、前記メッセージの受信の前に、
    公開鍵と秘密鍵とを含む暗号鍵ペアを生成することと、
    前記秘密鍵を、前記デバイスのローカルストレージに格納することと、
    前記公開鍵を含む登録メッセージを、インターネットを介してメッセージ配信サーバに送信することとを含む、請求項６～９のいずれか１項に記載のデバイス。
11. メッセージを配信するためにコンピュータによって実現される方法であって、
    メッセージ配信サーバにおいて、アプリケーションサーバから通知を受信することと、
    前記通知の受信者が前記メッセージ配信サーバに格納された公開鍵に関連付けられていると判断することとを備え、前記公開鍵は、受信者デバイスに関連付けられ、前記方法はさらに、
    前記受信者が前記公開鍵に関連付けられているという判断に応答して、前記通知を前記公開鍵で暗号化することによって、前記メッセージを生成することと、
    前記メッセージを無線キャリアに送信して、前記受信者デバイスに配信することとを備える、方法。
12. 前記受信者デバイスは、前記無線キャリアによって操作されるセルラーネットワークに結合された無線デバイスであり、前記受信者に対する前記メッセージの配信は、リッチコミュニケーションサービス（ＲＣＳ）プロトコルを介し、必要に応じて、前記メッセージ配信サーバおよび前記無線キャリアは、ＲＣＳのためにピアリング接続を維持する、請求項１１に記載のコンピュータによって実現される方法。
13. 前記通知を、インターネットを介して１つまたは複数の受信者デバイスに送信することをさらに備える、請求項１１または１２に記載のコンピュータによって実現される方法。
14. 前記通知の受信の前にさらに、前記メッセージ配信サーバにおいて、前記受信者デバイスから登録メッセージを受信することを備え、
    前記登録メッセージは、前記公開鍵と受信者識別子とを含む、請求項１１、１２または１３に記載のコンピュータによって実現される方法。
15. 前記通知の前記受信者が前記公開鍵に関連付けられていると判断することは、前記受信者が前記受信者識別子と一致すると判断することに基づき、かつ／または、前記受信者デバイスは、ソフトウェアアプリケーションを実行し、前記受信者識別子は、前記ソフトウェアアプリケーションに関連付けられたトークンである、請求項１４に記載のコンピュータによって実現される方法。

Images