特表 2020-526817 クライアントサーバシステムにおいてウェブ通知を管理する技術

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】特表2020-526817(P2020-526817A)

(43)【公表日】2020年8月31日

(54)【発明の名称】クライアントサーバシステムにおいてウェブ通知を管理する技術

(51)【国際特許分類】

   G06F 15/00 20060101AFI20200803BHJP

【ＦＩ】

   G06F15/00 470

【審査請求】未請求

【予備審査請求】未請求

【全頁数】24

(21)【出願番号】特願2019-571247(P2019-571247)

(86)(22)【出願日】2018年7月2日

(85)【翻訳文提出日】2020年1月31日

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

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

(87)【国際公開日】20190103

(31)【優先権主張番号】15/639,141

(32)【優先日】2017年6月30日

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

(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DJ,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JO,JP,KE,KG,KH,KN,KP,KR,KW,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT

(71)【出願人】

【識別番号】518279875

【氏名又は名称】イングラム マイクロ インコーポレーテッド

(74)【代理人】

【識別番号】100138760

【弁理士】

【氏名又は名称】森 智香子

(72)【発明者】

【氏名】ハキミャノフ，ティムール

(72)【発明者】

【氏名】ヴァグリン，イゴール

(57)【要約】

クライアントサーバシステムにおいて、ウェブブラウザとアプリケーション統合の間のウェブ通知を管理する技術は、アプリケーション統合の動作状態変更イベントについて（すなわち、ウェブブラウザを介して）ユーザの階層へのウェブ通知を管理するように構成されるウェブ通知管理プラットフォームを含む。そのために、ウェブ通知管理プラットフォームは、通知チャネルを作成して、通知チャネルが作成されているユーザの機能として決定される次元のチャネル階層に基づいて通知チャネルと関連しているメッセージセレクタを識別するように構成される。したがって、メッセージセレクタは、ウェブ通知を適切な通知チャネルおよび適用されるウェブブラウザにロングポーリングトピック購読またはウェブソケット接続を介して送るために用いることができる。さらなる実施形態は、本願明細書に記載されている。

【特許請求の範囲】

【請求項1】

ウェブブラウザとアプリケーション統合クライアントサーバシステムの間のウェブ通知を管理する方法であって、
ウェブ通知管理プラットフォームによって、エンドユーザコンピューティングデバイスの前記ウェブブラウザから通知チャネル要求を受信したことに応答して前記ウェブ通知管理プラットフォームで通知チャネルを作成するステップと、
前記ウェブ通知管理プラットフォームによって、前記通知チャネルの通知チャネル状態をセットして、前記通知チャネル状態が新規な状態にあることを示すステップと、
前記ウェブ通知管理プラットフォームによって、前記通知チャネルと関連しているメッセージセレクタを識別するステップであって、前記メッセージセレクタは、前記通知チャネルが作成されているユーザの機能として決定される次元チャネル階層に基づき、前記メッセージセレクタは、ウェブ通知を前記通知チャネルへ送るのに使用可能であるステップと、
前記ウェブ通知管理プラットフォームによって、前記メッセージセレクタの機能としてロングポーリングトピック購読を作成するステップと、
前記ウェブ通知管理プラットフォームによって、前記ウェブブラウザからウェブソケット接続要求を受信するステップと、
前記ウェブ通知管理プラットフォームによって、前記ウェブソケット接続要求が受け入れられたかどうかの表示を送信するステップと、
を含む方法。

【請求項2】

前記ウェブ通知管理プラットフォームによって、前記ウェブソケット接続要求が受け入れられたという決定に応答して、前記通知チャネル状態をセットして、前記通知チャネル状態がウェブソケット状態にあることを示すステップと、
前記ウェブ通知管理プラットフォームによって、前記ウェブソケット接続要求が受け入れられたことを示すウェブソケット受け入れ応答を前記ウェブブラウザに送信するステップと、
をさらに含む請求項１に記載の方法。

【請求項3】

前記ウェブ通知管理プラットフォームによって、前記通知チャネルがうまく作成されたことを示す通知チャネル作成応答を送信するステップをさらに含む請求項１に記載の方法。

【請求項4】

前記通知チャネルを作成するステップは、前記通知チャネルを識別するために使用可能な通知チャネル識別子を生成するステップを含み、前記通知チャネル作成応答を送信するステップは、前記通知チャネル識別子を送信するステップを含む請求項３に記載の方法。

【請求項5】

前記ウェブ通知管理プラットフォームによって、前記ウェブソケット接続要求が受け入れられなかったことを示すウェブソケット受け入れ応答を前記ウェブブラウザに送信するステップと、
前記ウェブ通知管理プラットフォームによって、ロングポーリング要求を受信するステップと、
前記ウェブ通知管理プラットフォームによって、前記ウェブソケット接続要求が受け入れられたという決定に応答して、前記通知チャネル状態がロングポーリング状態にあることを示すように前記通知チャネル状態をセットするステップと、
をさらに含む請求項１に記載の方法。

【請求項6】

前記ウェブ通知管理プラットフォームによって、前記アプリケーション統合からメッセージを受信するステップと、
前記ウェブ通知管理プラットフォームによって、前記受信メッセージを前記ウェブ通知管理プラットフォームのメッセージデータベースに書き込むステップと、
前記ウェブ通知管理プラットフォームによって、前記受信メッセージをロングポーリングトピックに書き込むステップと、
前記ウェブ通知管理プラットフォームによって、前記受信メッセージをウェブソケットキューに書き込むステップと、
をさらに含む請求項１に記載の方法。

【請求項7】

前記メッセージは、前記アプリケーション統合によって実行した動作状態変更イベントを示すウェブ通知を含む請求項６に記載の方法。

【請求項8】

前記ウェブ通知管理プラットフォームによって、前記ウェブブラウザから通知要求を受信するステップと、
前記ウェブ通知管理プラットフォームによって、前記メッセージセレクタの関数として、前記ロングポーリングトピックが前記アプリケーション統合から受信した一つ以上のメッセージを含むかどうか決定するステップと、
前記ウェブ通知管理プラットフォームによって、前記ロングポーリングトピックが前記一つ以上のメッセージを含むという決定に応答して、前記一つ以上のメッセージを前記ロングポーリングトピックから読み込むステップと、
前記ウェブ通知管理プラットフォームによって、前記一つ以上のメッセージを含む応答を前記ウェブブラウザに送信するステップと、
をさらに含む請求項１に記載の方法。

【請求項9】

前記ウェブ通知管理プラットフォームによって、前記ロングポーリングトピックが前記一つ以上のメッセージを含まないという決定に応答して、空であるという応答を前記ウェブブラウザに送信するステップをさらに含む請求項８に記載の方法。

【請求項10】

前記ウェブ通知管理プラットフォームによって、前記アプリケーション統合からウェブソケットメッセージを受信するステップと、
前記ウェブ通知管理プラットフォームによって、前記ウェブソケットメッセージをウェブソケットキューに入れるステップと、
前記ウェブ通知管理プラットフォームによって、前記ウェブソケットキューから前記ウェブソケットメッセージを検索するステップと、
前記ウェブ通知管理プラットフォームによって、前記ウェブソケットメッセージのメッセージセレクタと関連した通知チャネルのリストを検索するステップと、
前記ウェブ通知管理プラットフォームによって、通知チャネルの前記リストの少なくとも一つの通知チャネルの通知チャネル状態が新規な状態にあるかどうか決定するステップと、
前記ウェブ通知管理プラットフォームによって、通知チャネルの前記リストの一つの通知チャネルが新規な状態にないと決定したことに応答して、前記受信ウェブソケットメッセージを通知チャネルの前記リストの前記各通知チャネルに書き込むステップと、
をさらに含む請求項１に記載の方法。

【請求項11】

前記ウェブ通知管理プラットフォームによって、通知チャネルの前記リストの少なくとも一つの通知チャネルが新規な状態にあると決定したことに応答して、前記受信ウェブソケットメッセージを前記ウェブソケットキューに再び入れるステップをさらに含む請求項１０に記載の方法

【請求項12】

クライアントサーバシステムにおいて、ウェブブラウザとアプリケーション統合の間でウェブ通知を管理するウェブ通知管理プラットフォームであって、
命令を含む一つ以上のコンピュータ可読媒体と、
前記一つ以上のコンピュータ可読媒体に連結して、
エンドユーザコンピューティングデバイスの前記ウェブブラウザから通知チャネル要求を受信したことに応答して、前記ウェブ通知管理プラットフォームで通知チャネルを作成し、
通知チャネル状態が新規な状態にあることを示すように前記通知チャネルの前記通知チャネル状態をセットし、
前記通知チャネルと関連しているメッセージセレクタを識別し、前記メッセージセレクタは、前記通知チャネルが作成されているユーザの機能として決定される次元チャネル階層に基づき、前記メッセージセレクタは、ウェブ通知を前記通知チャネルへ送るために使用可能であるところ、
前記メッセージセレクタの機能としてロングポーリングトピック購読を作成し、
前記ウェブブラウザからウェブソケット接続要求を受信し、
前記ウェブソケット接続要求が受け入れられたかどうかの表示を送信する
ために前記命令を実行するように構成される一つ以上のプロセッサと、
を備えるウェブ通知管理プラットフォーム。

【請求項13】

前記一つ以上のプロセッサは、
前記ウェブソケット接続要求が受け入れられたという決定に応答して、前記通知チャネル状態がウェブソケット状態にあることを示すように前記通知チャネル状態をセットし、
前記ウェブソケット接続要求が受け入れられたことを示すウェブソケット受け入れ応答を前記ウェブブラウザに送信する
ために前記命令を実行するようにさらに構成される請求項１２に記載のウェブ通知管理プラットフォーム。

【請求項14】

前記一つ以上のプロセッサは、前記通知チャネルがうまく作成されたことを示す通知チャネル作成応答を送信する前記命令を実行するようにさらに構成される請求項１２に記載のウェブ通知管理プラットフォーム。

【請求項15】

前記通知チャネルを作成することは、前記通知チャネルを識別するために使用可能な通知チャネル識別子を生成することを含み、前記通知チャネル作成応答を送信することは、前記通知チャネル識別子を送信することを含む請求項１４に記載のウェブ通知管理プラットフォーム。

【請求項16】

前記一つ以上のプロセッサは、
前記ウェブソケット接続要求が受け入れられなかったことを示すウェブソケット受け入れ応答を前記ウェブブラウザに送信し、
ロングポーリング要求を受信し、
前記通知チャネル状態がロングポーリング状態にあることを示すように前記通知チャネル状態をセットする
ために前記命令を実行するようにさらに構成される請求項１２に記載のウェブ通知管理プラットフォーム。

【請求項17】

前記一つ以上のプロセッサは、
前記アプリケーション統合からメッセージを受信し、
前記受信メッセージを前記ウェブ通知管理プラットフォームのメッセージデータベースに書き込み、
前記受信メッセージをロングポーリングトピックに書き込み、
前記受信メッセージをウェブソケットキューに書き込む
ために前記命令を実行するようにさらに構成される請求項１２に記載のウェブ通知管理プラットフォーム。

【請求項18】

前記メッセージは、動作状態変更イベントが前記アプリケーション統合によって実行したことを示すウェブ通知を含む請求項１７に記載のウェブ通知管理プラットフォーム。

【請求項19】

前記一つ以上のプロセッサは、
前記ウェブブラウザから通知要求を受信し、
前記メッセージセレクタの機能として、前記ロングポーリングトピックが前記アプリケーション統合から受信した一つ以上のメッセージを含むかどうか決定し、
前記ロングポーリングトピックが前記一つ以上のメッセージを含むという決定に応答して、前記ロングポーリングトピックから前記一つ以上のメッセージを読み込み、
前記一つ以上のメッセージを含む応答を前記ウェブブラウザに送信する
ために前記命令を実行するようにさらに構成される請求項１２に記載のウェブ通知管理プラットフォーム。

【請求項20】

前記一つ以上のプロセッサは、前記ロングポーリングトピックが前記一つ以上のメッセージを含まないという決定に応答して、空であるという応答を前記ウェブブラウザへ送信するために前記命令を実行するようにさらに構成される請求項１９に記載のウェブ通知管理プラットフォーム。

【請求項21】

前記一つ以上のプロセッサは、
前記アプリケーション統合からウェブソケットメッセージを受信し、
前記ウェブソケットメッセージをウェブソケットキューに入れ、
前記ウェブソケットキューから前記ウェブソケットメッセージを検索し、
前記ウェブソケットメッセージのメッセージセレクタと関連した通知チャネルのリストを検索し、
通知チャネルの前記リストの少なくとも一つの通知チャネルの通知チャネル状態が新規な状態にあるかどうか決定し、
通知チャネルの前記リストの一つの通知チャネルが新規な状態にないと決定したことに応答して、前記受信ウェブソケットメッセージを通知チャネルの前記リストの前記各通知チャネルに書き込む
ために前記命令を実行するようにさらに構成される請求項１２に記載のウェブ通知管理プラットフォーム。

【請求項22】

前記一つ以上のプロセッサは、通知チャネルの前記リストの少なくとも一つの通知チャネルが前記新規な状態にあると決定したことに応答して、前記受信ウェブソケットメッセージを前記ウェブソケットキューに再び入れるために前記命令を実行するようにさらに構成される請求項２１に記載のウェブ通知管理プラットフォーム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、国際特許出願であり、２０１７年６月３０日に出願された米国特許出願第１５／６３９,１４１号の優先権の利益を主張するものであり、それの本文および図面全体を本願明細書に引用したものとする。

【背景技術】

【0002】

独立系ソフトウェアベンダー（ＩＳＶ）は、一つ以上のコンピュータハードウェアまたはオペレーティングシステムプラットフォーム上で動作するように通常は設計されるソフトウェアアプリケーションを開発し販売している。この種のソフトウェアアプリケーションは、基本ユーティリティまたは生産性向上アプリケーションから企業用ビジネスプロセスアプリケーション（例えば、顧客関係管理（ＣＲＭ）、企業資源計画（ＥＲＰ）、オートメーションツールなど）に及んでいる。クラウドコンピューティングがより普及したので、ソフトウェアを配信する一つの方法は、サービスとしてのソフトウェア（ＳａａＳ）ベースのモデルを使用してクラウド経由で行われた。この配信方法を使用して、ＩＳＶは、パブリッククラウドまたはクラウドマーケットプレースを通じて、それらのソフトウェアアプリケーション、またはそれらのソフトウェアアプリケーションの購読を販売できる。

【発明の概要】

【発明が解決しようとする課題】

【0003】

クラウドマーケットプレースが、オンライン店頭をクラウドベースのサービスおよびソフトウェアアプリケーションへの顧客アクセスのために提供すると共に、クラウドサービスブローカーは、ＩＳＶとエンドユーザ、再販業者、小売業者などの間の取引を容易にするために用いることができる。クラウドサービスブローカーが、いろいろなクラウドベースのサービスおよびソフトウェアアプリケーションを単一のポータルに統合するためにプラットフォームとして役立つと共に、それらは、高度に分散した構成要素、例えば、支払いゲートウェイ、第三者クラウドサービス、フロード防止サービスなど間の通信を送受信するためにウェブ通知に依存する。現在のウェブ通知システムは、クラウドベースのシステムおよびセルフホスティングされたシステムを含む。しかしながら、各解決策は、固有の課題のセットを呈する。例えば、クラウドベースの解決策において、機密情報が外部サーバを通過しなければならないという可能性が存在し、それは特定の法域において合法でないことがあり得る。セルフホスティングされた解決策において、例えば、追加構成要素が、メッセージを集合して水平スケーラビリティを達成するためにインストールされることを通常は必要とし、それはウェブベースのアプリケーションのサーバ側配備を難しくすることがあり得る。

【0004】

さらに、ウェブ通知システムのより挑戦的な態様の一つは、通知当たり、且つブラウザセッションオーバーヘッド当たり低く達成することにある。例えば、１秒当たり１，０００のメッセージを有するサーバは、各メッセージを処理するためにおよそ１ｍｓを要し、それは有効なサーバ側ｄｉｆｆ集約およびクイアントへの一括配信を通常は必要とする。したがって、クライアントサーバシステムのウェブ通知を管理する技術の改良の必要が存在する。

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

【0005】

一つの態様において、クライアントサーバシステムにおいてウェブブラウザとアプリケーション統合の間のウェブ通知を管理する方法は、ウェブ通知管理プラットフォームによって、エンドユーザコンピューティングデバイスのウェブブラウザからの通知チャネル要求を受信したことに応答してウェブ通知管理プラットフォームに通知チャネルを作成するステップと、ウェブ通知管理プラットフォームによって、通知チャネル状態が新規な状態にあることを示すように通知チャネルの通知チャネル状態をセットするステップと、ウェブ通知管理プラットフォームによって、通知チャネルと関連するメッセージセレクタを識別するステップであって、メッセージセレクタは、通知チャネルが作成されているユーザの機能として決定される次元チャネル階層に基づいて、メッセージセレクタは、ウェブ通知を通知チャネルへ送るために使用可能であるステップと、
ウェブ通知管理プラットフォームによって、メッセージセレクタの機能としてロングポーリングトピック購読を作成するステップと、ウェブ通知管理プラットフォームによって、ウェブブラウザからウェブソケット接続要求を受信するステップと、ウェブ通知管理プラットフォームによって、ウェブソケット接続要求が受け入れられたかどうかの表示を送信するステップとを含む。

【0006】

いくつかの実施形態において、方法は、ウェブ通知管理プラットフォームによって、ウェブソケット接続要求が受け入れられたという決定に応答して、通知チャネル状態がウェブソケット状態にあることを示すように通知チャネル状態をセットするステップと、ウェブ通知管理プラットフォームによって、ウェブソケット接続要求が受け入れられたことを示すウェブソケット受け入れ応答をウェブブラウザに送信するステップとをさらに含む。

【0007】

いくつかの実施形態において、方法は、ウェブ通知管理プラットフォームによって、通知チャネルがうまく作成されたことを示す通知チャネル作成応答を送信するステップをさらに含む。他の実施態様において、通知チャネルを作成するステップは、通知チャネルを識別するのに有用な通知チャネル識別子を生成することを含み、通知チャネル作成応答を送信するステップは、通知チャネル識別子を送信することを含む。

【0008】

いくつかの実施形態において、方法は、ウェブ通知管理プラットフォームによって、ウェブソケット接続要求が受け入れられなかったことを示すウェブソケット受け入れ応答をウェブブラウザに送信するステップと、ウェブ通知管理プラットフォームによって、ロングポーリング要求を受信するステップと、ウェブ通知管理プラットフォームによって、ウェブソケット接続要求が受け入れられたという決定に応答して、通知チャネル状態がロングポーリング状態にあることを示すように通知チャネル状態をセットするステップとをさらに含む。

【0009】

いくつかの実施形態において、方法は、ウェブ通知管理プラットフォームによって、アプリケーション統合からメッセージを受信するステップと、ウェブ通知管理プラットフォームによって、受信メッセージをウェブ通知管理プラットフォームのメッセージデータベースに書き込むステップと、ウェブ通知管理プラットフォームによって、受信メッセージをロングポーリングトピックに書き込むステップと、ウェブ通知管理プラットフォームによって、受信メッセージをウェブソケットキューに書き込むステップとをさらに含む。他の実施態様では、メッセージは、アプリケーション統合により実行される動作状態変更イベントを示すウェブ通知を含む。

【0010】

いくつかの実施形態において、方法は、ウェブ通知管理プラットフォームによって、ウェブブラウザから通知要求を受信するステップと、ウェブ通知管理プラットフォームによって、メッセージセレクタの機能として、ロングポーリングトピックがアプリケーション統合から受信する一つ以上のメッセージを含むかどうか決定するステップと、ウェブ通知管理プラットフォームによって、ロングポーリングトピックが一つ以上のメッセージを含むという決定に応答して、ロングポーリングトピックから一つ以上のメッセージを読み込むステップと、ウェブ通知管理プラットフォームによって、一つ以上のメッセージを含むウェブブラウザに応答を送信するステップとをさらに含む。他の実施態様において、方法は、ウェブ通知管理プラットフォームによって、ロングポーリングトピックが一つ以上のメッセージを含まないという決定に応答して、空であるという応答をウェブブラウザに送信するステップをさらに含む。

【0011】

いくつかの実施形態において、方法は、ウェブ通知管理プラットフォームによって、アプリケーション統合からウェブソケットメッセージを受信するステップと、ウェブ通知管理プラットフォームによって、ウェブソケットメッセージをウェブソケットキューに入れるステップと、ウェブ通知管理プラットフォームによって、ウェブソケットキューからウェブソケットメッセージを検索するステップと、ウェブ通知管理プラットフォームによって、ウェブソケットメッセージのメッセージセレクタと関連した通知チャネルのリストを検索するステップと、ウェブ通知管理プラットフォームによって、通知チャネルのリストの少なくとも一つの通知チャネルの通知チャネル状態が新規な状態にあるかどうか決定するステップと、ウェブ通知管理プラットフォームによって、通知チャネルのリストの一つの通知チャネルが新規な状態にないと決定したことに応答して、受信ウェブソケットメッセージを通知チャネルのリストの各通知チャネルに書き込むステップとをさらに含む。

【0012】

いくつかの実施形態において、方法は、ウェブ通知管理プラットフォームによって、通知チャネルのリストの少なくとも一つの通知チャネルが新規な状態にあると決定したことに応答して、受信ウェブソケットメッセージをウェブソケットキューに再び入れるステップをさらに含む。

【0013】

別の態様において、ウェブブラウザとアプリケーション統合の間のウェブ通知を管理するためのウェブ通知管理プラットフォームを示す。ウェブ通知管理プラットフォームは、
命令を含む一つ以上のコンピュータ可読媒体と、一つ以上のコンピュータ可読媒体に連結して、エンドユーザコンピューティングデバイスのウェブブラウザから通知チャネル要求を受信したことに応答してウェブ通知管理プラットフォームで通知チャネルを作成し、通知チャネル状態が新規な状態にあることを示すように通知チャネルの通知チャネル状態をセットし、通知チャネルと関連するメッセージセレクタを識別し、メッセージセレクタは、通知チャネルが作成されているユーザの機能として決定される次元チャネル階層に基づき、メッセージセレクタは、ウェブ通知を通知チャネルへ送るために使用可能であるところ、メッセージセレクタの機能としてロングポーリングトピック購読を作成し、ウェブブラウザからウェブソケット接続要求を受信し、ウェブソケット接続要求が受け入れられたかどうかの表示を送信する命令を実行するように構成される一つ以上のプロセッサとを含む。

【0014】

いくつかの実施形態において、一つ以上のプロセッサは、ウェブソケット接続要求が受け入れられたという決定に応答して、通知チャネル状態がウェブソケット状態にあることを示すように通知チャネル状態をセットして、ウェブソケット接続要求が受け入れられたことを示すウェブソケット受け入れ応答をウェブブラウザに送信する命令を実行するようにさらに構成される。

【0015】

いくつかの実施形態において、一つ以上のプロセッサは、通知チャネルがうまく作成されたことを示す通知チャネル作成応答を送信する命令を実行するようにさらに構成される。他の実施形態において、通知チャネルを作成することは、通知チャネルを識別するために使用可能な通知チャネル識別子を生成することを含み、通知チャネル作成応答を送信することは、通知チャネル識別子を送信することを含む。

【0016】

いくつかの実施形態において、一つ以上のプロセッサは、ウェブソケット接続要求が受け入れられなかったことを示すウェブソケット受け入れ応答をウェブブラウザに送信し、ロングポーリング要求を受け入れて、通知チャネル状態がロングポーリング状態にあることを示すように通知チャネル状態をセットする命令を実行するようにさらに構成される。他の実施形態において、一つ以上のプロセッサは、アプリケーション統合からメッセージを受信し、受信メッセージをウェブ通知管理プラットフォームのメッセージデータベースに書き込み、受信メッセージをロングポーリングトピックに書き込んで、受信メッセージをウェブソケットキューに書き込む命令を実行するようにさらに構成される。

【0017】

いくつかの実施形態において、メッセージは、アプリケーション統合により実行される動作状態変更イベントを示すウェブ通知を含む。他の実施形態において、一つ以上のプロセッサは、ウェブブラウザから通知要求を受信し、メッセージセレクタの機能として、ロングポーリングトピックがアプリケーション統合から受信した一つ以上のメッセージを含むかどうか決定し、ロングポーリングトピックが一つ以上のメッセージを含むという決定に応答して、ロングポーリングトピックから一つ以上のメッセージを読み込んで、一つ以上のメッセージを含む応答をウェブブラウザに送信する命令を実行するようにさらに構成される。他の実施形態において、一つ以上のプロセッサは、ロングポーリングトピックが一つ以上のメッセージを含まないという決定に応答して、空であるという応答をウェブブラウザに送信する命令を実行するようにさらに構成される。

【0018】

いくつかの実施形態において、一つ以上のプロセッサは、アプリケーション統合からウェブソケットメッセージを受信し、ウェブソケットメッセージをウェブソケットキューに入れ、ウェブソケットキューからウェブソケットメッセージを検索し、ウェブソケットメッセージのメッセージセレクタと関連した通知チャネルのリストを検索し、通知チャネルのリストの少なくとも一つの通知チャネルの通知チャネル状態が新規な状態にあるかどうか決定して、通知チャネルのリストの一つの通知チャネルが新規な状態にないと決定したことに応答して、受信ウェブソケットメッセージを通知チャネルのリストの各通知チャネルに書き込む命令を実行するようにさらに構成される。

【0019】

いくつかの実施形態において、一つ以上のプロセッサは、通知チャネルのリストの少なくとも一つの通知チャネルが新規な状態にあると決定したことに応答して、受信ウェブソケットメッセージをウェブソケットキューに再び入れる命令を実行するようにさらに構成される。

【0020】

実施形態および他の特徴、利点および本願明細書に含まれる開示、およびそれらを達成する方法は、明らかになり、本開示は、添付図面に関連してなされる本開示の様々な例示的実施形態の以下の説明を参照してよりよく理解される。

【図面の簡単な説明】

【0021】

【図1】エンドユーザコンピューティングデバイスおよびサービスブローカーコンピューティングデバイスに通信で連結するアプリケーションホストコンピューティングデバイスを含むウェブ通知を管理するクライアントサーバシステムの実施例のブロック図である。

【図2】図１のクライアントサーバシステムのコンピューティングデバイスの一つの実施例のブロック図である。

【図3】図１のクライアントサーバシステムのサービスブローカーコンピューティングデバイスの例示的な環境のブロック図である。

【図4】図１のクライアントサーバシステムのエンドユーザコンピューティングデバイスによって実行できる通知チャネルを設定する例示的な方法の概略フロー図である。

【図5A-5B】図１および３のクラウドサービスブローカーコンピューティングデバイスによって実行できる通知チャネルを作成する例示的な方法の概略フロー図である。

【図6】図１および３のクラウドサービスブローカーコンピューティングデバイスによって実行できるクラウドアプリケーション統合から受信したウェブ通知を管理する例示的な方法の概略フロー図である。

【図7】図１および３のクラウドサービスブローカーコンピューティングデバイスによって実行できるロングポーリングによってウェブ通知配信を管理する例示的な方法の概略フロー図である。

【図8】図１および３のクラウドサービスブローカーコンピューティングデバイスによって実行できるウェブソケット接続によってウェブ通知配信を管理する例示的な方法の概略フロー図である。

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

【0022】

本開示の原理の理解を促進するために、図面に示される実施形態に対する参照がここでなされて、特定の語法をそれを説明するために用いる。それでも、本開示の範囲の限定がこのことにより意図されないことを理解されたい。

【0023】

図１は、エンドユーザコンピューティングデバイス１０２およびアプリケーションホストコンピューティングデバイス１１２を含むウェブ通知を管理するクライアントサーバシステム１００を示し、エンドユーザコンピューティングデバイス１０２およびアプリケーションホストコンピューティングデバイス１１２の各々は、ネットワーク１０６を介してクラウドサービスブローカーコンピューティングデバイス１０８に通信で連結する。使用中、下記に詳述されるように、クラウドサービスブローカーコンピューティングデバイス１０８は、エンドユーザコンピューティングデバイス１０２のウェブブラウザ（例えば、ウェブブラウザ１０４）から要求を受信して、通知チャネルを開く。そうすると、クラウドベースのアプリケーションの統合（例えば、アプリケーション統合１１４のうちの一つ）とウェブブラウザ間の通知は、通知チャネルを介して、クラウドサービスブローカーコンピューティングデバイス１０８、またはより詳細には、クラウドサービスブローカーコンピューティングデバイス１０８のウェブ通知管理プラットフォーム１１０によって管理できる。

【0024】

要求を受信すると、即座に、ウェブ通知管理プラットフォーム１１０は、通知チャネル、ならびにロングポーリングトピック購読およびメッセージセレクタを作成するように構成されて、通知チャネルが作成されたとウェブブラウザに通知する。ウェブ通知管理プラットフォーム１１０は、メッセージセレクタを用いてウェブ通知をロングポーリング状態で配信するためにトピック購読を活用して、ウェブ通知を正しい通知チャネルに送るように構成される。

【0025】

通知チャネルが作成されたという通知を受信したことに応答して、ウェブブラウザは、ウェブソケット接続を開いて、要求をウェブ通知管理プラットフォーム１１０に送信して、ウェブソケット接続を受け入れる。したがって、ウェブ通知管理プラットフォーム１１０は、サポートされる場合、ウェブソケット接続を受け入れるか、またはウェブソケット接続が受け入れなかったとウェブブラウザに通知できる。ウェブ通知管理プラットフォーム１１０は、ウェブソケット接続を介してのウェブ通知の配信を除けば、上記のようにトピック購読と同様の方法でウェブソケット接続を活用するように構成される。

【0026】

ウェブソケット接続が受け入れられる場合、ウェブブラウザは、通知が受信されるまで待ち、さもなければ、ウェブブラウザは、ロングポーリングトピック購読にしたがって、通知要求をウェブ通知管理プラットフォーム１１０に送信する。したがって、ウェブ通知管理プラットフォーム１１０は、通知チャネルの作成中に遭遇する状態の下で必要とすることがあり得るものはどれでも、ウェブソケット接続またはロングポーリング購読を使用してウェブ通知の送信を管理できる。

【0027】

ロングポーリング購読およびウェブソケット接続の両方をサポートすることによって、ウェブ通知管理プラットフォーム１１０が、ブラウザの汎用性をサポートすることができることを理解すべきである。換言すれば、ウェブソケット接続は、サポートされる／受け入れられる場合、ブラウザ／サーバ中間層において効果的に処理できる。その一方で、ロングポーリングは、ブラウザ、プロキシ、ルータなどのいかなる組合せでも動作するフォールバックで使用できる。ここで、ハイパーテキスト転送プロトコル（ＨＴＴＰ）がサポートされる。

【0028】

したがって、この種のメッセージ指向のミドルウェアを用いて、ウェブ通知は、クラウドアプリケーションが、様々な計算集約的および／または時間依存の動作、例えば部分的に開かれたセッションを開く／管理することを実行し、開いたユーザーセッションの量によってイベント乗算を処理して、メッセージごとに適切なセッション選択を管理することを必要とせずに、クラウドアプリケーションからユーザーセッションに配信できる。換言すれば、ウェブ通知管理プラットフォーム１１０は、クラウドアプリケーションからエンドユーザまでの（例えば、イベントと関連する）ウェブ通知のフローを編成し、それによって、少し例を挙げれば、セッションネゴシエーション、再配信、および多重化のような、本解決策と関連した複雑さをクラウドアプリケーションから実質的に取り除くことによって通知当たり、ブラウザセッション当たり小さいオーバーヘッドを示す非常にスケーラブルな解決策を提供する。

【0029】

図示するエンドユーザコンピューティングデバイス１０２は、ウェブブラウザ１０４を含む。ウェブブラウザ１０４は、本願明細書に記載されている機能、例えば、通知チャネルを開く、格納された通知を読み込む、ロングポーリングまたはウェブソケットによって変更を能動的にモニタするか、あるいはウェブサーバ、ファイル、または他の情報ソースにより提供される情報へのアクセスを実行できるエンドユーザコンピューティングデバイス１０２にあるいかなるタイプのソフトウェアアプリケーション、ウェブブラウザ、または他のシン／ゼロクライアントアプリケーションとしても実施できる。図示するクラウドサービスブローカーコンピューティングデバイス１０８は、前述のように、ウェブ通知管理プラットフォーム１１０を含み、それは下記に詳述される。図示するアプリケーションホストコンピューティングデバイス１１２は、前述のように、一つ以上のアプリケーション統合１１４を含む。アプリケーション統合１１４は、一つ以上のウェブベースのサービス／アプリケーション、コネクタ、クラウドベースのサービス／アプリケーションなどとして実施できる。

【0030】

図示するクライアントサーバシステム１００に示すように、エンドユーザコンピューティングデバイス１０２、クラウドサービスブローカーコンピューティングデバイス１０８、およびアプリケーションホストコンピューティングデバイス１１２の各々は、コンピューティングデバイス１１６として実施される。したがって、それぞれのコンピューティングデバイス１１６の各々は、本願明細書に記載されている機能を実行できるあらゆるタイプのコンピュータおよび／または記憶装置として実施できることを理解すべきである。例えば、いくつかの実施形態において、エンドユーザコンピューティングデバイス１０２は、デスクトップコンピュータまたはモバイルコンピューティングデバイス（例えば、スマートフォン、ウェアラブル、タブレット、ラップトップ、ノートブックなど）として実施できる。その一方で、クラウドサービスブローカーコンピューティングデバイス１０２および／またはアプリケーションホストコンピューティングデバイス１１２は、クラウドアーキテクテッドネットワークまたはデータセンタにおいて、一つ以上のサーバ（例えば、独立型、ラック搭載型など）、コンピュートデバイス、記憶装置、および／またはコンピュートブレードとデータ記憶装置（例えば、記憶エリアネットワーク（ＳＡＮ）の）の組み合わせとして実施できる。

【0031】

エンドユーザコンピューティングデバイス１０２、クラウドサービスブローカーコンピューティングデバイス１０８、およびアプリケーションホストコンピューティングデバイスの各々が、単一コンピューティングデバイスコンピュータ１１６として例示的に示されると共に、アプリケーションベンダーコンピューティングデバイス１０２の一つ以上が、他の実施形態において、複数のコンピューティングデバイス１１６として実施できることをさらに理解すべきである。したがって、いくつかの実施形態において、本願明細書に記載されているクラウドサービスブローカーコンピューティングデバイス１０８の一つ以上の機能は、例えば、一つ以上のコンピューティングデバイス１１６で実行できる。その一方で、本願明細書に記載されているクラウドサービスブローカーコンピューティングデバイス１０８の一つ以上の同じであるか、付加的であるか、または代替の機能は、一つ以上の他のコンピューティングデバイス１１６で実行できる。

【0032】

ここで図２を参照すると、図示するコンピューティングデバイス１１６（例えば、エンドユーザコンピューティングデバイス１０２、クラウドサービスブローカーコンピューティングデバイス１０８、およびアプリケーションホストコンピューティングデバイス１１２の図示する一つ）は、中央演算処理装置（ＣＰＵ）２００、入出力（Ｉ／Ｏ）コントローラ２０２、主メモリ２０４、ネットワーク通信回路２０６、データ記憶装置２０８、および、いくつかの実施形態では、一つ以上のＩ／Ｏ周辺機器２１０を含む。いくつかの代替実施形態において、コンピューティングデバイス１１６は、図示するコンピューティングデバイス１１６のそれらに対する追加の、より少ない、および／または代替構成要素、例えばグラフィックス処理ユニット（ＧＰＵ）を含むことができる。図示する構成要素の一つ以上が、単一集積回路（ＩＣ）で単一システムオンチップ（ＳｏＣ）に組み込むことができることを理解すべきである。

【0033】

さらに、それぞれのコンピューティングデバイス１１６の構成要素および／またはハードウェア／ソフトウェアリソースのタイプが、それぞれのコンピューティングデバイス１１６のタイプおよび意図された使用に基づくことができることを理解すべきである。例えば、クラウドサービスブローカーコンピューティングデバイス１０８は、いかなる周辺装置２１０も含むことができないが、エンドユーザコンピューティングデバイス１０２は、複数の周辺装置２１０を含むことができる。さらに、上記したように、クラウドサービスブローカーコンピューティングデバイス１０８は、複数のコンピューティングデバイス１１６から成ることができる。したがって、この種の実施形態において、クラウドサービスブローカーコンピューティングデバイス１０８のコンピューティングデバイス１１６の一つ以上が、クラウドサービスブローカーコンピューティングデバイス１０８のコンピューティングデバイス１１６のもう一方と比較してより小さい計算能力およびより大きい記憶容量を有するデータベースサーバとして構成されることができることをさらに理解すべきである。同様に、クラウドサービスブローカーコンピューティングデバイス１０８の一つ以上の他のコンピューティングデバイス１１６は、クラウドサービスブローカーコンピューティングデバイス１０８のコンピューティングデバイス１１６のもう一方と比較してより大きい計算能力およびより小さい記憶容量を有するアプリケーションサーバとして構成できる。

【0034】

ＣＰＵ２００またはプロセッサは、データを処理できるハードウェアおよび回路のあらゆる組み合わせとして実施できる。いくつかの実施形態において、コンピューティングデバイス１１６は、複数のＣＰＵ２００を含むことができる。実施形態に応じて、ＣＰＵ２００は、例えば単一コアプロセッサアーキテクチャで、一つの処理コア（図示せず）、または、例えばマルチコアプロセッサアーキテクチャで、複数の処理コア（図示せず）を含むことができる。処理コアおよびＣＰＵ２００の数に関わりなく、ＣＰＵ２００は、プログラム命令を読み込んで、実行できる。いくつかの実施形態において、ＣＰＵ２００は、ＣＰＵ２００と直接集積化されるかまたはＣＰＵ２００と別々の相互接続を有する別々のチップに配置されることができるキャッシュメモリ（図示せず）を含むことができる。いくつかの実施形態において、パイプライン論理は、ＣＰＵ２００に出入りするコマンドよりもむしろ、ソフトウェアおよび／またはハードウェア動作（例えば、ネットワークトラフィック処理操作）を実行するために用いることができることを理解すべきである。

【0035】

Ｉ／Ｏコントローラ２０２またはＩ／Ｏインタフェースは、あらゆるタイプのコンピュータハードウェアまたは入出力用装置とコンピューティングデバイス１１６とのインタフェースをとることができる回路の組み合わせとして実施できる。例示的に、Ｉ／Ｏコントローラ２０２は、ＣＰＵ２００から入出力要求を受信して、それぞれの入力／出力装置に制御信号を送り、それによって、コンピューティングデバイス１１６に出入りするデータフローを管理するように構成される。

【0036】

メモリ２０４は、あらゆるタイプのコンピュータハードウェアまたは処理するためにデータおよび命令を保持できる回路の組み合わせとして実施できる。この種のメモリ２０４は、主メモリまたは主要なメモリと呼ばれる場合がある。いくつかの実施形態において、コンピューティングデバイス１１６の一つ以上の構成要素が、メモリに直接アクセスすることができて、そうすると、特定のデータは、ＣＰＵ２００と独立して直接メモリアクセス（ＤＭＡ）によって格納できることを理解すべきである。

【0037】

ネットワーク通信回路２０６は、あらゆるタイプのコンピュータハードウェアあるいは無線および／または有線通信モードによってネットワークインタフェース通信（例えば、メッセージ、データグラム、パケットなど）を管理できる回路の組み合わせとして実施できる。したがって、いくつかの実施形態において、ネットワーク通信回路２０６は、実施形態に応じて、コンピューティングデバイス１１６をコンピュータネットワークに接続するように構成できるネットワークインタフェースコントローラ（ＮＩＣ）、ならびに他の装置を含むことができる。

【0038】

データ記憶装置２０８は、あらゆるタイプのデータの不揮発性記憶（例えば、半導体記憶媒体、磁気記録媒体、光記憶媒体など）の可能性があるコンピュータハードウェアとして実施できる。この種のデータ記憶装置２０８は、一般に補助記憶装置または二次記憶装置と呼ばれて、上記のメモリ２０４と比較して大量のデータを格納するために通常は用いる。

【0039】

Ｉ／Ｏ周辺機器２１０は、あらゆるタイプのコンピューティングデバイス１１６に接続して、それと通信するように構成される補助装置として実施できる。実施形態に応じて、一つ以上のＩ／Ｏ周辺機器２１０は、ディスプレー、マイクロホン、スピーカ、マウス、キーボード、タッチスクリーン、カメラ、プリンタ、スキャナなどを含むことができる。したがって、いくつかの I/О装置が、一つの機能（すなわち、入力または出力）または両方の機能（すなわち、入力および出力）ができることを理解すべきである。

【0040】

いくつかの実施形態において、Ｉ／Ｏ周辺機器２１０は、その間でなされる通信がＩ／Ｏコントローラ２０２によって管理できるコンピューティングデバイス１１６の対応するポート（図示せず）に接続しているケーブル（例えば、リボンケーブル、ワイヤ、汎用シリアルバス（ＵＳＢ）ケーブル）、高解像度マルチメディアインタフェース（ＨＤＭＩ（登録商標））ケーブルなど）を介してコンピューティングデバイス１１６に接続できる。代替実施形態において、Ｉ／Ｏ周辺機器２１０は、ネットワーク通信回路２０６によって管理できる無線モードの通信（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉ（登録商標）など）を介してコンピューティングデバイス１１６に接続できる。

【0041】

図１に戻って参照すると、前述のように、エンドユーザコンピューティングデバイス１０２およびアプリケーションホストコンピューティングデバイス１１２は、ネットワーク１０６を介してクラウドサービスブローカーコンピューティングデバイス１０８に各々通信で連結する。ネットワーク１０６は、あらゆる有線および／または無線通信技術ならびにネットワーク通信伝送プロトコルを利用する、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、グローバルネットワーク（インターネット）などを含む、あらゆるタイプの有線および／または無線ネットワークとして実施できる。したがって、ネットワーク１０６は、一連の有線および／または無線相互接続を介してネットワーク通信トラフィックのフローおよび／または処理を容易にするために一つ以上の通信で連結したネットワークコンピューティングデバイス（図示せず）を含むことができる。

【0042】

この種のネットワークコンピューティングデバイスは、一つ以上のアクセスポイント、ルータ、スイッチ、サーバ、計算装置、記憶装置などを含むことができるが、これに限定されるものではない。ネットワークコンピューティングデバイスおよび／またはネットワーク構成の一つ以上が、仮想化する（例えば、仮想スイッチ、仮想ＬＡＮなど）ことができることを理解すべきである。多くの通信チャネルが、その間の通信を可能にするためにそこに確立できるように、エンドユーザコンピューティングデバイス１０２、クラウドサービスブローカーコンピューティングデバイス１０８、およびアプリケーションホストコンピューティングデバイス１１２が、ネットワーク１０６のバックボーンに接続するためにいろいろなネットワーク（例えば、ＬＡＮ、プロバイダネットワークなど）を使用できることをさらに理解すべきである。

【0043】

ここで図３を参照すると、クラウドサービスブローカーコンピューティングデバイス１０８の例示的な環境３００が示される。例示的な環境３００は、チャネル特性データベース３０２、メッセージデータベース３０４、ウェブソケットキュー３０６、およびロングポーリングトピック３０８を含む。いくつかの実施形態において、本願明細書に記載されているように提供されるおよび／または生成されるデータへのアクセスは、許可および／またはこの種のデータが記憶および／または通過の間に暗号化されることを必要とする場合がある。したがって、いくつかの実施形態において、当業者に知られている一つ以上の認証および／または暗号化技術は、記憶を確実にするために使用することができて、データへのアクセスは、いかなる法律および／または契約の要件に準拠する。

【0044】

いくつかの実施形態において、それぞれのデータベースに格納されるデータが、排他的でないことをさらに理解すべきである。換言すれば、あるデータベースに格納されているとして本願明細書に記載されている特定のデータは、本願明細書に記載されている別のデータベース、または別のデータベースに完全に、追加して、または代わりに格納できる。いくつかの実施形態において、データが、単一のデータベース、または代わりのデータベース／データ記憶配列に格納できることをさらに理解すべきである。さらに、本願明細書に記載されている例示的なデータベースは、他の実施形態において、結合するかまたはさらに分離することができる。

【0045】

例示的な環境３００は、図１のウェブ通知管理プラットフォーム１１０をさらに含み、これは、本願明細書に記載されている機能を実行できるあらゆるタイプのファームウェア、ハードウェア、ソフトウェア、回路、またはそれらの組み合わせとして実施できる。例示的なウェブ通知管理プラットフォーム１１０は、通知チャネルマネージャ３１０、アプリケーションインタフェース３１２、ウェブソケットディスパッチャ３１４、および一つ以上の通知チャネル３１６を含む。通知チャネルマネージャ３１０、アプリケーションインタフェース３１２、ウェブソケットディスパッチャ３１４、および一つ以上の通知チャネル３１６の各々は、あらゆるタイプのファームウェア、ハードウェア、ソフトウェア、回路、またはそれらの組み合わせとして実施できる。

【0046】

通知チャネルマネージャ３１０、アプリケーションインタフェース３１２、ウェブソケットディスパッチャ３１４、および一つ以上の通知チャネル３１６の一つ以上は、そこに格納される命令および一つ以上のコンピュータ可読媒体に連結して本願明細書に記載されている機能を実行するために命令を実行するように構成される一つ以上のプロセッサ（例えば、ＣＰＵ２００）を有する一つ以上のコンピュータ可読媒体（例えば、メモリ２０４、データ記憶装置２１０、および／またはその他のいかなる媒体記憶装置）を含むことができる。データが、アクセスされ、管理されて、適切に更新されることができるように、環境３００が、本願明細書に記載されている少なくとも一部のデータ要素（例えば、データベース）を格納するために使用可能な一つ以上の構造をさらに含むことができることを理解すべきである。しかしながら、この種の構造は、説明の明快さを守るために本願明細書には示されていない。

【0047】

通知チャネルマネージャ３１０は、通知チャネル（例えば、通知チャネル３１６）を管理するように構成される。そのために、通知チャネルマネージャ３１０は、入って来るセッション要求を認証し、対応するメッセージセレクタでロングポーリングトピック購読を開いて、入って来るＨＴＴＰ要求を通知チャネル３１６の適切な一つへ送るように構成される。メッセージセレクタは、通知チャネルが作成されているユーザの機能として決定される次元チャネル階層に基づくことができる。メッセージセレクタが、単一次元セレクタ（例えば、スタッフメンバー）または多次元セレクタ（例えば、サービスユーザ）であり得ることを理解すべきである。例えば、単一次元セレクタは、アカウント識別子を含むことができる。その一方で、二次元セレクタは、アカウント識別子およびユーザ識別子の対を含むことができる。ただし、メッセージセレクタの次元が、２次元を越えて拡張されることができることを理解すべきである。

【0048】

通知チャネルマネージャ３１０は、通知チャネル特性（すなわち、通知チャネル特性）を管理するようにさらに構成される。いくつかの実施形態において、通知チャネル特性は、チャネル特性データベース３０２に格納できる。通知チャネル特性は、通知チャネルまたはそれとの関連の態様を識別するのに役立つあらゆる情報、例えば、通知チャネルの識別子、関連するメッセージセレクタ、現在の通知チャネル状態（すなわち、「新規」、「ロングポーリング」、および「ウェブソケット」）、トピック購読、およびウェブソケット接続を含むことができる。通知チャネル特性のいくつかが、いろいろな目的のために使うことができることを理解すべきである。

【0049】

例えば、通知チャネル識別子は、ウェブブラウザから受信したメッセージ用にウェブブラウザ（例えば、図１のウェブブラウザ１０４）に送信できる。その一方で、他の通知チャネル特性の残りは、いくつかの実施形態において、ウェブ通知管理プラットフォーム１１０だけによって使うことができる。通知チャネル識別子およびメッセージセレクタが、ユーザまたはスタッフメンバーの証明書に通常は密接に結びつくので、通知チャネル識別子が、メッセージセレクタに特定の時点で密接に結びつくことができることを理解すべきである。換言すれば、同一のメッセージセレクタを除いたいろいろな通知チャネル識別子を有する複数の通知チャネルを有することは不可能でない。

【0050】

アプリケーションインタフェース３１２は、アプリケーション統合１１４から動作状態変更イベントを受信して、アプリケーション統合１１４から受信する受信動作状態変更イベントと関連したウェブ通知（例えば、動作状態変更通知）を送信するように構成される。例えば、動作状態変更イベントは、図１のアプリケーション統合１１４のうちの一つとインタフェースをとるときにクラウドサービスブローカーが遭遇することがあり得るあらゆる動作／機能、例えば、新しい顧客を生じさせる、顧客のために購読を買う、サービスを作成する／割り当てる、サービスユーザを生じさせる、購読計画／限度を変更する、購読を無効にする／終了する、支払いを処理する、アプリケーションを提供するなどによってトリガされることができる。

【0051】

この実施例を促進すると、アプリケーションインタフェース３１２は、「プロセス順序」動作に対応する動作状態変更イベントを受信できる。したがって、このような条件下で、アプリケーションインタフェース３１２は、プロセス順序動作、例えば、「順序予定」、「支払い受領」、「提供完了」などに関連して受信されるあらゆるウェブ通知、ならびにプロセス順序動作に関連したあらゆるエラー状態、例えば、「フロード防止の失敗」、「支払いエラー」などを送信するように構成される。そうすることで、ユーザは、（例えば、それらのエンドユーザコンピューティングデバイス１０２のウェブブラウザ１０４を介して）動作状態変更イベントの状態を識別できる。

【0052】

アプリケーションインタフェース３１２は、現在ログオフしている意図された受取人のためにデータベース（例えば、メッセージデータベース３０４）にアプリケーション統合１１４からの受信動作状態変更イベントを格納するようにさらに構成される。そうすると、意図された受取人がログインするときに、メッセージは、意図された受取人に送信されることができる。さらに、アプリケーションインタフェース３１２は、メッセージを（例えば、通知チャネル状態が「ウェブソケット」にセットされる場合）ウェブソケット通知セッションのためにウェブソケットキュー３０６に、（例えば、通知チャネル状態が「ロングポーリング」にセットされる場合）ロングポーリング通知セッションのためにロングポーリングトピック３０８にプッシュするように構成される。

【0053】

ウェブソケットディスパッチャ３１４は、ウェブソケットキューに配置されるウェブ通知を管理するように構成される。そのために、ウェブソケットディスパッチャ３１４は、ウェブソケットキューに配置されたウェブ通知を適切なチャネルにプッシュするように構成される。さらに、ウェブソケットディスパッチャ３１４は、永続記憶装置から読み込まれる通知が未送付にならないことを確実にするように構成される。そのために、意図されたアカウントまたはユーザのためのウェブ通知と関連したチャネルが、「新規な」状態にある場合、ウェブソケットディスパッチャ３１４は、あらゆるウェブ通知をキューに再び入れるように構成される。ルックアップが（例えば、ユーザおよび／またはアカウントによって）そこで実行されることができるように、すべての開かれたウェブソケットが格納されること、ウェブソケットキュー３０６のすべてのウェブ通知が発信ユーザおよび／またはアカウントのすべての開かれたウェブソケットに書き込まれることを理解すべきである。

【0054】

通知チャネル３１６の各々は、サーバ側の開いた通知セッションを表すように構成される。通知チャネル３１６は、３つの状態、すなわち「新規」、「ロングポーリング」、または「ウェブソケット」のうちの一つにあることができる。各通知チャネル３１６は、チャネルが「新規」または「ロングポーリング」状態にある場合に購読をロングポーリングトピックに維持するように構成される。したがって、ロングポーリングトピックに対する購読は、飛行中の通知の全てが送られることを確実にすることができる。ロングポーリングトピック購読の方にプッシュされるウェブ通知の全てが、どの実体がウェブ通知と関連した動作をトリガしたかに基づいて関連するメッセージセレクタを有することを理解すべきである。したがって、二次元メッセージセレクタを有するユーザが、ウェブ通知と関連した動作をトリガする場合、ウェブ通知は、そのユーザのブラウザセッションに、ユーザの二次元メッセージセレクタと同じアカウントに基づいて単一次元メッセージセレクタを有する適切なスタッフメンバーと関連したあらゆるブラウザセッションに送られる。さらに、ウェブブラウザが、ユーザーセッションを開始するが通知のために戻らないか、または通知に対する最後のロングポーリング要求が受信されてからあまりに多くの時間が過ぎた場合、各通知チャネル３１６は、（例えば、タイムアウト、要求などにより）自動的に閉じるように構成される。

【0055】

ウェブ通知管理プラットフォーム１１０が、Java（登録商標） Platform、Enterprise Edition で表される例示的な実施例において、アプリケーションインタフェース３１２は、アプリケーションサーバがプールサイズ（すなわち、同時処理された要求の量）を管理する国籍のないセッションビーンとして抽象化できる。さらに、アプリケーションインタフェース３１２は、アプリケーションサーバが同時並列管理を引き受けるシングルトンエンタープライズビーンとして抽象化できる。さらに、ウェブソケットディスパッチャ３１４は、ウェブソケットメッセージキューのメッセージによりアクティブ化されるメッセージ駆動エンタープライズビーンとして抽象化できる。さらには、通知チャネル３１６は、アプリケーションサーバが未使用時間間隔を追跡して、適用できる場合は、チャネルを適切に閉じるタイムアウトを有する状態フルエンタープライズビーンとして抽象化できる。

【0056】

ここで図４を参照すると、例示的な方法４００は、エンドユーザコンピューティングデバイス（例えば、図１のエンドユーザコンピューティングデバイス１０２）によって、またはより詳細には、エンドユーザコンピューティングデバイスのウェブブラウザ（例えば、ウェブブラウザ１０４）によって実行できる通知チャネルをセットアップするために提供される。方法４００は、ブロック４０２で始まり、ウェブブラウザ１０４は、クラウドサービスブローカーコンピューティングデバイス（例えば、図１のクラウドサービスブローカーコンピューティングデバイス１０８）によって、またはより詳細には、クラウドサービスブローカーコンピューティングデバイスのウェブ通知管理プラットフォーム（例えば、図１のウェブ通知管理プラットフォーム１１０）によって通知チャネルを開くべきかどうか決定する。そうすると、通知チャネルは、アプリケーション統合（例えば、図１のアプリケーションホストコンピューティングデバイス１１２のアプリケーション統合１１４のうちの一つ）からウェブ通知（例えば、動作状態変更通知）を受信するために用いることができる。

【0057】

ウェブブラウザ１０４が、ウェブ通知管理プラットフォーム１１０で通知チャネルを開くと決定する場合、方法４００は、ブロック４０４へ進み、ウェブブラウザ１０４は、要求をウェブ通知管理プラットフォーム１１０に送信して、通知チャネルを作成する。ブロック４０６において、ウェブブラウザ１０４は、通知チャネルが作成されたかどうか決定して、例えば、ウェブ通知管理プラットフォーム１１０からの肯定的な応答によって示すことができる。通知チャネルが作成された場合、方法４００は、ブロック４０８へ進み、ウェブブラウザ１０４は、ウェブソケット接続を確立する。ブロック４１０において、ウェブブラウザ１０４は、要求をウェブ通知管理プラットフォーム１１０に送信して、ウェブソケット接続を受け入れる。いくつかの実施形態において、要求は、ウェブ通知管理プラットフォーム１１０がウェブソケット接続を受け入れるべきかどうか決定するのに必要なウェブソケット接続に関するあらゆる情報を含むことができることを理解すべきである。

【0058】

ブロック４１２において、ウェブブラウザ１０４は、ウェブソケット接続が受け入れられたかどうか（すなわち、ウェブ通知管理プラットフォーム１１０によって）決定する。そうでない場合には、方法４００は、ブロック４１８へ分岐するが、それは後述する。さもなければ、ウェブブラウザ１０４が、ウェブソケット接続が受け入れられたと決定する場合、方法４００は、ブロック４１４へ分岐する。ブロック４１４において、ウェブブラウザ１０４は、ウェブ通知が受信されたかどうか決定する。その場合は、方法４００は、ブロック４１６へ進み、ウェブブラウザ１０４は、あらゆる受信した通知を読み込んで、受信した通知に基づいて出力をエンドユーザコンピューティングデバイス１０２のディスプレーへレンダリングする。換言すれば、ウェブブラウザ１０４は、ウェブブラウザ１０４のユーザが（例えば、メッセージセレクタに基づいて）関連するアプリケーション統合により実行されている動作の現状を示す通知と関連したテキストおよび／またはグラフィックスを表示する。

【0059】

ブロック４１２に戻って参照すると、上記したように、ウェブブラウザ１０４が、ウェブソケット接続が受け入れられなかった（例えば、ウェブ通知管理プラットフォーム１１０がウェブソケット接続をサポートしない、通知管理プラットフォーム１１０の前に発生したあるエラーがウェブソケット接続を受け入れることが可能であるなど）と決定する場合、方法は、ブロック４１８へ分岐する。ブロック４１８において、ウェブブラウザ１０４は、通知要求（例えば、ロングポーリング要求）をウェブ通知管理プラットフォーム１１０に送信する。ブロック４２０において、ウェブブラウザ１０４は、通知が通知要求に応答して受信されたかどうか決定する。いくつかの実施形態において、ウェブブラウザ１０４が、タイマーがタイムアウト期間に等しくなると通知が受信されなかったと決定できるように、タイムアウト期間が通知要求と関連できることを理解すべきである。

【0060】

通知が受信されなかった場合、方法４００はブロック４２２へ分岐し、ウェブブラウザ１０４は、ブロック４０２に戻る前にタイムアウト期間の間スリープする。さもなければ、通知が受信された場合、ウェブブラウザ１０４は、通知が空かどうか決定する。ウェブブラウザ１０４が、通知が空であると決定する場合、方法４００はブロック４１８に戻って、別の通知要求を送信し、さもなければ、方法４００はブロック４２６へ進む。ブロック４２６において、ウェブブラウザ１０４は、あらゆる受信した通知を読み込んで、方法４００がブロック４１８に戻って別の通知要求を送信する前に、受信した通知に基づいてエンドユーザコンピューティングデバイス１０２のディスプレーに出力を提供する。換言すれば、ブロック４１６に記載されているプロセスと同様に、ウェブブラウザ１０４は、ウェブブラウザ１０４のユーザが（例えば、メッセージセレクタに基づいて）関連するアプリケーション統合により実行されている動作の現状を識別するために使用可能である通知の内容に基づいてテキストおよび／またはグラフィックスを表示する。

【0061】

ここで図５Ａおよび５Ｂを参照すると、例示的な方法５００は、クラウドサービスブローカーコンピューティングデバイス（例えば、図１のクラウドサービスブローカーコンピューティングデバイス１０８）によって、または、より詳細には、クラウドサービスブローカーコンピューティングデバイスのウェブ通知管理プラットフォーム（例えば、図１のウェブ通知管理プラットフォーム１１０）によって実行できる通知チャネルを作成するために提供される。方法５００は、ブロック５０２において始まり、ウェブ通知管理プラットフォーム１１０は、通知チャネル要求がウェブブラウザ（例えば、図１のウェブブラウザ１０４）から受信したかどうか決定する。

【0062】

通知チャネル要求が受信された場合、方法５００は、ブロック５０４へ進み、ウェブ通知管理プラットフォーム１１０は、通知チャネル要求によって受信した情報に基づいて通知チャネル（例えば、図３の例示的なウェブ通知管理プラットフォーム１１０の通知チャネル３１６のうちの一つ）を作成する。さらに、ブロック５０６において、ウェブ通知管理プラットフォーム１１０は、通知チャネル（すなわち、通知チャネル要求）を識別するために使用可能な固有識別子を生成する。ブロック５０８において、ウェブ通知管理プラットフォーム１１０は、通知チャネルと関連する状態（すなわち、通知チャネル状態）をさらに「新規」にセットする。

【0063】

ブロック５１０において、ウェブ通知管理プラットフォーム１１０は、チャネル階層に従ってメッセージセレクタによってロングポーリングトピック購読を作成する。上記したように、メッセージセレクタは、通知チャネルが作成されているユーザまたはスタッフメンバーの機能として決定できる単一または多次元チャネル階層に基づくことができる。ブロック５１２において、ウェブ通知管理プラットフォーム１１０は、ウェブ通知管理プラットフォーム１１０がさらなる通知を送る動作の状態を決定するために永続記憶装置からあらゆる通知を読み込む。現在の状態は、最後の動作状態変更に関する最後の通知から受信できる。ブロック５１４において、ウェブ通知管理プラットフォーム１１０は、通知チャネルがうまく作成されたことを示す通知チャネル作成応答をウェブブラウザ１０４に送信する。さらに、ブロック５１６において、ウェブ通知管理プラットフォーム１１０は、ブロック５０６において発生した通知チャネル識別子と共に応答を送信する。

【0064】

ブロック５１８において、ウェブ通知管理プラットフォーム１１０は、ウェブソケット接続要求が受信されたかどうか決定する。その場合は、方法５００は、ブロック５２０へ進み、ウェブ通知管理プラットフォーム１１０は、ウェブソケット接続が受け入れられたかどうか（例えば、ウェブ通知管理プラットフォーム１１０がウェブソケット接続をサポートするかどうか、エラーがウェブソケット接続の受け入れの間またはその前に発生したかどうかなど）決定する。ウェブソケット接続が受け入れられなかった場合、方法５００は、ブロック５２６（図５Ｂに示す）へ分岐するが、それは後述する。さもなければ、方法５００は、ブロック５２２へ分岐する。ブロック５２２において、ウェブ通知管理プラットフォーム１１０は、通知チャネル状態を「ウェブソケット」にセットする。ブロック５２４において、ウェブ通知管理プラットフォーム１１０は、ウェブソケット接続が受け入れられたことを示す応答をウェブブラウザ１０４に送信する。

【0065】

上記したように、ウェブ通知管理プラットフォーム１１０が、ブロック５２０において、ウェブソケット接続を受け入れない場合、方法５００は、ブロック５２６へ分岐する。ブロック５２６において、ウェブ通知管理プラットフォーム１１０は、ウェブソケット接続が受け入れなかったことを示す応答を送信する。ブロック５２８において、ウェブ通知管理プラットフォーム１１０は、第１のロングポーリング要求がウェブブラウザ１０４から受信されたかどうか決定する。そうでない場合には、方法５００は、ブロック５３２へ分岐して、チャネルが閉じるのを待つ。さもなければ、方法５００は、ブロック５３０へ分岐する。ブロック５３０において、ウェブ通知管理プラットフォーム１１０は、方法５００がブロック５３２に進む前に通知チャネル状態を「ロングポーリング」にセットし、ウェブ通知管理プラットフォーム１１０は、通知チャネルが閉じるのを待つ。ウェブ通知管理プラットフォーム１１０が、通知チャネルが閉じたと決定する場合、方法５００は、ブロック５０２に戻って、別の通知チャネル要求が受信されたかどうか決定する。

【0066】

ここで図６を参照すると、例示的な方法６００は、クラウドサービスブローカーコンピューティングデバイス（例えば、図１のクラウドサービスブローカーコンピューティングデバイス１０８）によって、または、より詳細には、クラウドサービスブローカーコンピューティングデバイスのウェブ通知管理プラットフォーム（例えば、図１のウェブ通知管理プラットフォーム１１０）によって、実行できるクラウドアプリケーション統合（例えば、図１のアプリケーション統合１１４のうちの一つ）から受信するウェブ通知を管理するために提供される。ウェブソケット接続が、すでにウェブブラウザ（例えば、図１のウェブブラウザ１０４）により確立されて、方法６００が開始される前にウェブ通知管理プラットフォーム１１０によって受け入れられたことを理解すべきである。

【0067】

方法６００は、ブロック６０２において始まり、ウェブ通知管理プラットフォーム１１０は、メッセージ（例えば、動作状態変更イベントと関連したウェブ通知）がアプリケーション統合１１４から受信したかどうか決定する。その場合は、方法６００は、ブロック６０４へ進み、ウェブ通知管理プラットフォーム１１０は、送信アプリケーションおよび意図された受取人に関する情報を有する受信メッセージをメッセージデータベース（例えば、図３のメッセージデータベース３０４）に書き込む。ブロック６０６において、ウェブ通知管理プラットフォーム１１０は、送信アプリケーションおよび意図された受取人に関する情報を有する受信メッセージをウェブブラウザ１０４とウェブ通知管理プラットフォーム１１０の間に以前確立された通知チャネルと関連したロングポーリングトピック（例えば、図３のロングポーリングトピック３０８）に書き込む。ブロック６０８において、ウェブ通知管理プラットフォーム１１０は、メッセージをウェブソケットキュー（例えば、図３のウェブソケットキュー３０６）に書き込む。

【0068】

適切なロングポーリングトピック購読が、ロングポーリングトピックに書き込まれる受信メッセージと関連できるように、ロングポーリングトピックに書き込まれる受信メッセージが、対応するメッセージセレクタをさらに含むことを理解すべきである。それがユーザおよびアカウントルックアップによって識別することができて、ウェブソケットキューのすべてのメッセージが、発信ユーザおよびアカウントと関連したすべての開かれたウェブソケットに書き込まれるように、ウェブソケットキューに書き込まれる受信メッセージが、格納されることをさらに理解すべきである。

【0069】

ここで図７を参照すると、例示的な方法７００は、クラウドサービスブローカーコンピューティングデバイス（例えば、図１のクラウドサービスブローカーコンピューティングデバイス１０８）によって、または、より詳細には、クラウドサービスブローカーコンピューティングデバイスのウェブ通知管理プラットフォーム（例えば、図１のウェブ通知管理プラットフォーム１１０）によって実行できるロングポーリングによるウェブ通知配信を管理するために提供される。通知チャネルが、方法７００が開始される前にウェブブラウザ（例えば、図１のウェブブラウザ１０４）とウェブ通知管理プラットフォーム１１０の間にすでに確立されたことを理解すべきである。

【0070】

方法７００は、ブロック７０２において始まり、ウェブ通知管理プラットフォーム１１０は、通知要求がウェブブラウザ１０４から受信されたかどうか決定する。その場合は、方法７００は、ブロック７０４へ進み、ウェブ通知管理プラットフォーム１１０は、通知チャネルと関連した使用されないタイマーをリセットする。ブロック７０６において、ウェブ通知管理プラットフォーム１１０は、ロングポーリングトピック（例えば、図３のロングポーリングトピック３０８）から一つ以上のメッセージを読み込む。さらに、ブロック７０８において、ウェブ通知管理プラットフォーム１１０は、読み込みタイムアウトを所定のタイムアウト期間にセットする。

【0071】

ブロック７１０において、ウェブ通知管理プラットフォーム１１０は、読み込みタイムアウト期間に達する前に、あらゆるメッセージがロングポーリングトピックから読み込まれたかどうか決定する。そうでない場合には、方法７００は、ブロック７１０へ分岐し、ウェブ通知管理プラットフォーム１１０は、別の通知要求が受信されたかどうか決定するためにブロック７０２に戻る前に空の応答を送信する。さもなければ、ウェブ通知管理プラットフォーム１１０が、一つ以上のメッセージがロングポーリングトピックから読み込まれたと決定する場合、方法７００は、ブロック７１４へ進む。ブロック７１４において、方法７００が別の通知要求が受信されたかどうか決定するためにブロック７０２に戻る前に、ウェブ通知管理プラットフォーム１１０は、ロングポーリングトピックからの読み込まれたメッセージを含む応答をウェブブラウザ１０４に送信する。

【0072】

ここで図８を参照すると、例示的な方法８００は、クラウドサービスブローカーコンピューティングデバイス（例えば、図１のクラウドサービスブローカーコンピューティングデバイス１０８）によって、または、より詳細には、クラウドサービスブローカーコンピューティングデバイスのウェブ通知管理プラットフォーム（例えば、図１のウェブ通知管理プラットフォーム１１０）によって実行できるウェブソケット接続によるウェブ通知配信を管理するために提供される。通知チャネルがウェブブラウザ（例えば、図１のウェブブラウザ１０４）とウェブ通知管理プラットフォーム１１０の間にすでに確立されたこと、方法８００が開始される前までにウェブソケット接続がウェブブラウザ１０４により確立されてウェブ通知管理プラットフォーム１１０によって受け入れられたことを理解すべきである。

【0073】

方法８００は、ブロック８０２において始まり、ウェブ通知管理プラットフォーム１１０は、ウェブソケットメッセージがアプリケーション統合から（例えば、図３のウェブソケットディスパッチャ３１４によって）受信されて、ウェブソケットキュー（例えば、図３のウェブソケットキュー３０６）に格納されたかどうか決定する。その場合は、方法８００は、ブロック８０４へ進み、ウェブ通知管理プラットフォーム１１０は、ウェブソケットメッセージと関連したチャネル階層に従ってメッセージセレクタを決定する。上記したように、メッセージセレクタは、通知チャネルが作成されているユーザの機能として決定できる単一または多次元チャネル階層に基づくことができる。ブロック８０６において、ウェブ通知管理プラットフォーム１１０は、例えば、チャネル特性データベース（例えば、図３のチャネル特性データベース３０２）に格納できる、メッセージセレクタと関連するチャネルのリストを得る。

【0074】

ブロック８０８において、ウェブ通知管理プラットフォーム１１０は、リストの各通知チャネルのチャネル通知状態を読み込む。ブロック８１０において、ウェブ通知管理プラットフォーム１１０は、リストの通知チャネルの通知チャネル状態のどれが「新規な」状態にあるかどうか決定する。その場合は、方法８００は、ブロック８１２へ分岐し、ウェブ通知管理プラットフォーム１１０は、ウェブソケットメッセージをキューに再び入れる。さもなければ、方法８００は、ブロック８１４へ分岐し、ウェブ通知管理プラットフォーム１１０は、メッセージをリストのすべての関連する通知チャネルに書き込む。

【0075】

クライアントサーバシステム１００の本開示が、クラウドサービスブローカーシステムとの関連で例示的に示されたが、本願明細書に記載されているメッセージ指向のミドルウェア（すなわち、ウェブ通知管理プラットフォーム１１０）が多くの第三者アプリケーション／サービスが使われるあらゆるシステムにおいて用いることができて、ウェブ通知が、第三者アプリケーション／サービスの動作状態変更イベントのまわりのユーザの階層に送られることを理解すべきである。さらに、本開示が例示されて、図面および上記の説明に詳述されたが、それは、特性において例示的であり限定的でないと考えるべきであり、特定の実施形態だけが示されて説明されたこと、本開示の精神の範囲に入るすべての改変と変更態様が保護されることが望ましいことが理解される。

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【国際調査報告】