JP2016503536A

JP2016503536A - 共同セッションに加えるユーザに通知および勧誘を行うためのフレームワーク

Info

Publication number: JP2016503536A
Application number: JP2015541258A
Authority: JP
Inventors: ニールアンドリューサンチェ
Original assignee: カルガリーサイエンティフィックインコーポレイテッド
Priority date: 2012-11-12
Filing date: 2013-11-12
Publication date: 2016-02-04
Also published as: EP2917887A4; US20140143434A1; HK1210535A1; US10673909B2; CA2890995A1; US20190141092A1; EP2917887A2; CN104871184A; WO2014076578A3; WO2014076578A2

Abstract

勧誘を１つのデバイスから別のデバイスに迅速に送信して、デバイスを共同セッションに加える通知フレームワークおよび方法。デバイスは、ユーザがレジストリサービスに登録することを可能にするアプリケーションを提供し得る。レジストリサービスは、共同勧誘の配信および参加者が共同セッションへ加わることを可能にするためのメカニズムとして提供される。共同ＵＲＬを含む通知勧誘は、次いで勧誘された登録者にプッシュサービスを介して送付される。各勧誘された登録者は、次いで勧誘を受諾してセッションにユーザを自動的に加えるための選択肢を提供される。別の実施例では、ホストユーザは、勧誘された登録者にセッション加入させるというよりは勧誘された登録者に対しセッションを「送る」または「共有」し得る。【選択図】なし

Description

特定の環境では、アプリケーションおよびデータの共同がユーザ間に提供され得る。例えば、一部の画像保管通信システム（ＰＡＣＳ）は、患者検査に対して遠隔アクセスを提供し得る。これらのシステムでは、リンクをコピーしてそれらを電子メールで他の参加者に送ることにより、参加者を共同セッションに加えてアプリケーションと関連付けられたデータを視聴させるための勧誘を、送信することがしばしば行われる。こうすることは、負担が重く、リンクが意図しない受信者に誤って宛てられた場合、安全性についての懸念を生じ得る。

本明細書には、共同セッションに加えるための勧誘を、通知フレームワークを用いてデバイスに提供するシステムおよび方法が開示される。通知フレームワークは、ホストからユーザ登録情報および少なくとも１人の登録済みのユーザをセッションに加える勧誘要求を受信するレジストリサービスと、ユーザ登録情報および勧誘要求を格納するデータベースとを備える。レジストリサービスは、勧誘を、勧誘要求のプッシュ通知を少なくとも１人の登録済みのユーザと関連付けられたユーザデバイスに提供するプッシュサービスに通信し、フレームワークは、ホストと少なくとも１人の登録済みのユーザとの間のセッションをその場で開始するように適合される。

別の態様によれば、通知フレームワークを用いてホストと少なくとも１人の登録済みのユーザとの間でセッションを開始する方法が提供される。本方法は、ホストからセッションを始めるための指示を受信することと、ユーザインタフェースを、セッションに加えるべき少なくとも１人の登録済みのユーザであって、登録サービスにより登録済みのユーザのデータベースから取得される少なくとも１人の登録済みのユーザで設定することと、セッションに加えるべき少なくとも１人の登録済みのユーザを、少なくとも１人の登録済みのユーザと関連付けられたコンピューティングデバイスに対して勧誘要求をプッシュする通知処理を介して、勧誘することと、少なくとも１人の登録済みのユーザからの勧誘の受諾に応じて、少なくとも１人の登録済みのユーザをセッションに加えることと、を含む。

更に別の態様によれば、通知フレームワーク内でワークフローを管理する方法が提供される。本方法は、各々がユーザアカウントを有するユーザを、通知フレームワークの登録サービスに登録することと、少なくとも１つのユーザデバイスを各ユーザアカウントと関連付けることと、ホストからの通知要求に応じて規則を適用して、第２のユーザをセッションに加えるように勧誘することと、規則に応じて、通知を第２のユーザに送付することと、第２のユーザからの通知の確認応答の受領に際して、第２のユーザをセッションに加えることと、を含む。

上記において、セッションは、共同セッションまたはアプリケーション共有セッションであり得る。

以下の図面および詳細な説明を検討することによって、当業者には他のシステム、方法、特徴および／または利点が明らかとなる、あるいは明らかになり得る。すべてのそのような追加のシステム、方法、特徴および／または利点は、この説明に含まれ、添付のクレームによって保護されることが意図される。

図面における構成要素は、必ずしも互いに対して一定の縮尺であるとは限らない。同様の参照番号は、いくつかの図面を通して対応する部分を示している。

通知フレームワークを示す簡略化ブロック図である。図１のフレームワーク内に実装され得る動作フローを示す。図１のフレームワーク内での通信フローを示すコールフロー図を示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図２の動作フローおよび図３のコールフローに従って提示される種々のユーザインタフェースを示す。図１のフレームワークに実装され得る別の動作フローを示す。図１４の動作フローと関連付けられたユーザインタフェースを示す。図１４の動作フローと関連付けられたユーザインタフェースを示す。図１のフレームワークのユーザのための管理サービスが実装され得る汎組織ネットワークを示す。例示のコンピューティングデバイスを示す。

特に定義されない限り、本明細書において使用されるすべての技術的および科学的な用語は、当業者によって一般的に理解されるものと同一の意味を有する。本明細書において説明されるものと類似または同等とみなされる方法および用具は、本開示の実施または実験において使用され得る。実装例は、アプリケーションに遠隔的にアクセスすることについて説明されることになるが、実装例はそれに限定されるものではなくて、遠隔デバイスを介して任意の種類のデータまたはサービスに遠隔的にアクセスすることに適用可能であることが、当業者に明らかになるであろう。

概要

本開示の態様によれば、クライアントデバイスは、ユーザが通知フレームワーク内でレジストリサービスに登録することを可能にするアプリケーションを提供し得る。レジストリサービスは、共同勧誘の配信、および参加者が共同セッションへ加わることを可能にするメカニズムとして提供される。例えば、登録者のリストが、ホストユーザに対して、例えば、携帯デバイスの表示器上に表示され得る。ホストユーザは、セッションに加えるべき１人以上の登録者をリストから選択し得る。勧誘が、次いでプッシュサービスを介して勧誘された登録者に送付され得る。各勧誘された登録者には、次いで勧誘を受諾してユーザをセッションに自動的に加えるための選択肢が提供される。したがって、本開示は、ユーザが、参加者をセッションに共同するように迅速、容易かつ安全に勧誘することを可能にするためのメカニズムを提供する。別の実施例では、ホストユーザは、勧誘された登録者をセッションに加えさせるよりむしろ、セッションを勧誘された登録者に対し「送る」または「共有」し得る。共有動作を用いて、セッションが勧誘された登録者に送られ、ホストユーザはもはやセッションの一部ではないため勧誘された登録者がホストを引き継ぐ。

フレームワーク例

上記概要を導入説明として、図１を参照すると、通知フレームワーク１００が示されており、１つの携帯デバイスから別のものへなど、例えば、１つのデバイスから別のデバイスへＵＲＬを迅速に送信する。そのようなフレームワークには、例えば、別の人とウェブリンクを共有したり、または人々の間で共同セッションを立ち上げるなど、多くの限定されない可能な使用が存在する。フレームワーク１００は、１つのデバイスが、ＵＲＬ（複数可）を含む勧誘を別のデバイスに送信することを可能にする。加えて、フレームワーク１００は、メッセージ、文書、画像、マルチメディアデータ等の、ＵＲＬ以外の他の形式の情報をも共有し得る。情報には、ＳｋｙｐｅＩＤ、ＧｏｏｇｌｅＶｏｉｃｅ（または他の通信ＩＤ）等の、フレームワークの各ユーザ用のデータベース内に維持される情報を含み得る。一部の実装例では、勧誘は、デバイスにより暗号化されて、サーバ上で零知識を提供し得る。

フレームワーク１００内には、データベース１０３、レジストリサービス１０６およびプッシュサービス１０７が含まれ得る。一般的に、フレームワーク１００は、その場でユーザ間の共同セッションを開始するために、登録、通知および勧誘のサービスを提供し、例えば、勧誘の受諾に際して、ユーザは自動的かつ動的に加えられる。フレームワーク１００は、ユーザ間での静的に事前に定義された関係は必要としない。フレームワーク１００により提供されるサービスの例としては、ＣａｌｇａｒｙＳｃｉｅｎｔｉｆｉｃ，Ｉｎｃ．（Ｃａｌｇａｒｙ，Ａｌｂｅｒｔａ，Ｃａｎａｄａ）から入手可能なオンコール（Ｏｎｃａｌｌ）がある。レジストリサービス１０６は、ユーザが、フレームワーク１００内で共同またはアプリケーション共有のセッションへ対応可能な参加者として登録をし、かつ当該ユーザの対応可否を他者に公開することを可能にするために提供される。データベースサービス１０３は、ユーザ情報、勧誘、およびフレームワーク１００に関連付けられた他の文書を格納するために提供される。ユーザ情報は、限定はされないが、ユーザの電子メールアドレス、フルネーム、ユーザのコンピューティングデバイス識別子、連絡先情報等、を含み得る。プッシュサービス１０７は、レジストリサービス１０６から共同セッションに加える対応可能なユーザに勧誘のプッシュ通知を提供する。プッシュサービス１０７は、フレームワーク１００に通信可能に接続されるクライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎに情報を広めるために、レジストリサービス１０６により使用され得る。

クライアントコンピューティングデバイス１１２Ａまたは１１２Ｂは、例えば、ＩＯＳ系ＩＰＯＮＥ１１２Ａ等の、スマートフォン等の無線手持ち型デバイス、または、例えば、インターネット等のコンピュータネットワークを介してレジストリサービス１０６およびプッシュサービス１０７に接続されるＡＮＤＲＯＩＤ(登録商標)系デバイス１１２Ｂで構わない。同様に、クライアントコンピューティングデバイスも、通信ネットワークによりレジストリサービス１０６およびプッシュサービス１０７に接続されるデスクトップ／ノートブックパーソナルコンピュータ１１２Ｃまたはタブレットデバイス１１２Ｎを含み得る。通信ネットワークへの接続は、例えば、Ｗｉ−Ｆｉ（ＩＥＥＥ８０２．１１ｘ）、ＷｉＭａｘ（ＩＥＥＥ８０２．１６）、イーサネット(登録商標)、３Ｇ、４Ｇ等、任意の形式の接続でよいことには注目される。更に、データベース１０３、レジストリサービス１０６およびプッシュサービス１０７は、図１８に示すもののように、汎用コンピューティングデバイス上で実行され得る。データベース１０３、レジストリサービス１０６およびプッシュサービス１０７は、同一のまたは別個のデバイス上で実行され得る。

クライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎは、ウェブブラウザ等の、クライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎを実行でき、ユーザが、データを、例えば、タッチスクリーンで図形表示に表示することを可能にする。クライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎは、また、クライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎ間で、アプリケーションの共同を提供し得る。

本開示の態様によれば、通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎはレジストリサービス１０６と協力し、このことで通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎに対するサーバの機能を果たす。通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎは、ユーザが、レジストリサービス１０６で登録をして共同セッションに加えるユーザの対応可否を指示することを可能にする。通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎは、また、共同セッションに加えるための勧誘の通知を待ち得る。

デスクトップ型クライアントコンピューティングデバイス上で、ユーザは、勧誘を他のユーザに、ＨＴＭＬ５アプリケーション（ウェブクライアント）を動作させるウェブブラウザを介して送信し得る。ＪａｖａＳｃｒｉｐｔ(登録商標)ライブラリは、レジストリサービス１０６からダウンロードされ得、フレームワーク構成要素（例えば、レジストリサービス１０６）に通信するために使用され得る。ＪａｖａＳｃｒｉｐｔ(登録商標)ライブラリは、いずれのウェブアプリケーションにも含まれ得る。プッシュ通知は、以下に説明するプッシュサービス１０７によりウェブアプリケーションに提供され得る。ウェブクライアント用プッシュサービス１０７の例としては、ｐｕｓｈｅｒ．ｃｏｍがあり、それに対するホストＡＰＩは接続されたクライアントに通知を提供するために使用され得る。

Ａｎｄｒｏｉｄ(登録商標)およびｉＯＳ等の携帯デバイス上で、ユーザは、ネイティブ「オンコール（ＯｎＣａｌｌ）」クライアントアプリケーション（即ち、通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎ）を開いてレジストリサービス１０６に登録することにより、登録を行って対応可能となる。クライアントアプリケーションは、デバイス登録をレジストリサービス１０６に送信し得るので、プラットフォーム特有のプッシュ通知を受信し得る。Ａｎｄｒｏｉｄ(登録商標)デバイスの場合には、ＧｏｏｇｌｅＣｌｏｕｄＭｅｓｓａｇｉｎｇを使用し得る。Ａｐｐｌｅデバイスの場合には、ＡｐｐｌｅＰｕｓｈＮｏｔｉｆｉｃａｔｉｏｎサービスを使用し得る。一部の実装例では、通知アプリケーションがメッセージの重要部分を暗号化し得るので、データはデータベース１０３内への格納時に保護される。

クライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎのユーザは、レジストリサービス１０６により公開されるアプリケーションプログラミングインタフェース（ＡＰＩ）を用いて、レジストリサービス１０６に登録し得る。ＡＰＩは、ユーザが、レジストリサービス１０６にそのデバイス形式およびデバイス識別を登録することを可能にする。例えば、ユーザは、１つ以上のクライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎを登録し得る。また、ユーザは、レジストリサービス１０６による連絡をもはや望まないならば、登録を解除し得る。以下に説明するように、ユーザは現在登録済みのユーザのリストを要求することにより、共同セッションを開始し得る。リストは、特定のユーザに対して調べ得る。そのリストから、登録者は選択的に勧誘を送信されて、要求側のユーザとの共同セッションに加わり得る。受諾に際して、登録者は、以下に説明するように共同セッションに自動的に加えられる。

レジストリサービス１０６からの勧誘は、題名、本文、および参加者志望者が勧誘の受信確認をしたとき共同セッションへの参加を開始させる統一資源ロケータ（ＵＲＬ）を含み得る。本開示よれば、勧誘は、送信者ＩＤ、メッセージ、優先レベルまたは状態（例えば、高、中、低も含み得、医療分野ではこれは、例えば、緊急、即座、危篤、正規、再検討、セカンドオピニオン等、より具体的になり得る）、または「受諾」／「選択無視」（これは健康管理では「ループを閉鎖」するために使用され得、受信者により直ちに読まれることとは対照的に症例が公開される確認を提供する）を含み得る。受諾選択肢は、勧誘と関連付けられた情報が勧誘された登録者に実際に渡されたことについての確認応答を提供する。

レジストリサービス１０６は、ユーザ登録をメモリまたはデータベース１０３に格納し得る。レジストリサービス１０６により送信される勧誘は、サーバ側プロトコルを用いて、勧誘が通信されているデバイスの形式に従って通信され得る。レジストリサービス１０６により送付される勧誘は、題名、本文、およびＵＲＬを含み得る。

データベース１０３は、ユーザ、勧誘、および受領文書を格納し得る。データベース１０３は、また、予定表調整情報に基づいて、各ユーザに対する対応可否情報を維持し得る。加えてまたは任意選択的に、データベース１０３に格納される存在情報は、通知をユーザのデバイスに送付するかを決定するために使用され得る。更に、優先情報（例えば、通知が送信されるユーザの先行順位）が、ユーザ毎、グループ毎、または世界的基準で、データベース１０３内に格納される。優先情報は、受諾を可能にするために引き続く各受信者間の遅延により、順次メッセージを送信するように使用され得る。
勧誘は、各勧誘がクライアントに送信される一意のＩＤをプッシュ通知内に有するように格納され得る。クライアントは、格納された勧誘を取得しかつ復号化しなければならない。クライアントは、また、もはや必要なくなった勧誘を削除できる。受領書は、特定のユーザによる勧誘の配信、受諾、および拒否を示す原送信者の特別勧誘を送信することにより、勧誘の配信を追跡するように使用される。クライアントに送信される全メッセージが、勧誘通知である。クライアントはＵＲＬを調べて、勧誘が受領書であるのかを知ることができる。

登録情報は、データベース１０３内に安全な仕方で格納され得る。上述のように、登録情報は、ユーザの電子メールアドレス、フルネーム、クライアントデバイス識別子、ＳｋｙｐｅＩＤ、ＧｏｏｇｌｅＶｏｉｃｅ番号等を含み得る。ユーザの問い合わせは、上記情報またはその何らかの組合せを用いて行われ得る。レジストリサービス１０６は、また、組織に基づいてユーザの「カテゴリ」または制限を提供し得、使用により適した規模のユーザのリストを可能にする。例えば、百万人ものユーザをレジストリサービス１０６に登録するとすれば、リストはクライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎにダウンロードするのに長時間を要することになるであろう。会社、グループ、専門性、標識、についてのリストの分割メカニズムを付加することにより、登録済みのユーザのリストの検索および限定をより容易にナビゲート可能にし得る（例えば、図９Ｂ〜９Ｃを参照）。

プッシュサービス１０７は、勧誘のプッシュ通知を、レジストリサービス１０６から共同セッションに加えるために登録済みのユーザデバイスに提供する。プッシュサービス１０７は、レジストリサービス１０６により使用され得、情報をクライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎに広める。各クライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎは、プッシュサービス１０７との接続を確立し、この接続を介してその上で動作する通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎを介して通知を受信する。上述したように、勧誘には特定の情報を含み得る。

プッシュサービス１０７がＡｐｐｌｅＰｕｓｈＮｏｔｉｆｉｃａｔｉｏｎを遂行しているとき、ＡｐｐｌｅＰｕｓｈＮｏｔｉｆｉｃａｔｉｏｎ（ＡＮＰ）符号化メッセージは、公開キー署名入りメッセージのシステムを介して通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎに配信され得る。通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎは、勧誘通知を受信し、内蔵されたＵＲＬ起動メカニズムを介してクライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎを起動する。

Ａｎｄｒｏｉｄ(登録商標)クライアントコンピューティングデバイス上で、通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎは、機能性を区分化するためのスタンドアロンアプリケーションとして展開され得る。Ａｎｄｒｏｉｄ(登録商標)オペレーティングシステムは、別個のアプリケーションが「視聴」および「共有」など、ユーザが行う必要がある種々の動作に「リンクイン」する別個のアプリケーションを可能にする目的システムを含む。例えば、本開示に従った実装例では、通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎは、４部分に分割され得る。
１．登録をするユーザがいつでも使える（オンコール）ようにアイコンが提示される、主要アプリケーション。
２．着信プッシュ通知を受信する、Ｇ２ＤＭレシーバ構成要素。
３．オンコール用ＶＩＥＷアクションレシーバを設定する、テストメッセージアクティビティ：／／ｔｙｐｅＵＲＬｓ。
４．ｔｅｘｔ／ｐｌａｉｎおよびｔｅｘｔ／ｕｒｌｍｉｍｅｔｙｐｅｓに対してＡｎｄｒｏｉｄ(登録商標) ＳＥＮＤアクションを扱い、サーバに勧誘メッセージを送信する、ＳｅｎｄＡｃｔｉｖｉｔｙ。

上記により、アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎおよびクライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎは、他のクライアントコンピューティングデバイスプラットフォームに、当該クライアントコンピューティングデバイスプラットフォームのネイティブプッシュ通知メカニズムを用いて実装され得る。

したがって、フレームワーク１００は、ユーザが、参加者をセッションに共同するように迅速、容易かつ安全に勧誘することを可能にするためのメカニズムを提供する。

動作フロー（複数可）例

図２は、フレームワーク１００内に実装され得る動作フロー２００を示す。図３は、図１の部分間の通信フローを示す例示コールフローを示す。図４〜８、９Ａ〜９Ｃ、１０〜１２、および１３Ａ〜１３Ｂは、動作フロー２００およびコールフロー３００と関連付けられた例示ユーザインタフェースを示す。

２０２で、処理が開始し、２０４でクライアントデバイスが、レジストリサービス１０６で、例えば、共同セッション、に加えるために対応可能であるとして登録される。図４に示すように、ユーザは、フルネームおよび電子メールアドレスなど、ユーザ情報を要求する通知アプリケーション（例えば、オンコール（ＯｎＣａｌｌ））１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎを起動し得る。この情報は、クライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎに保存される。その後、通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎは、ユーザがレジストリサービス１０６で登録することを可能にするためのアイコンを提示する（フロー３０２および３０４）。例えば、図５に示すように、ユーザはボタンアイコンを押してレジストリサービス１０６に登録することができる。登録が２０４で成功裏になされたことを確認するために、確認メッセージが通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎに提供され、ユーザに提示され得る（図６）。

２０６で、クライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎが、第１のユーザにより、この第１のユーザと関連付けられたクライアントコンピューティングデバイスのうちの１つで起動される。例えば、ウェブブラウザが、クライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎの第１のユーザにより、クライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎとして起動され得る。第１のユーザが共同セッションの確立を望めば、ユーザは２０８でメニューを用いて共同モードを有効化すればよい（フロー３０６）。このワークフローでは、ユーザは、共同セッションの「ホスト」である。

動作フロー２００の態様によれば、２０２〜２０６の動作は省略でき、ホストは入り口箇所２０７で開始し得る。そのようなシナリオでは、ホストは通知フレームワーク１００の未登録のユーザであるだろう。ここで、ホストは、以下に説明するように、勧誘を送信し得る。しかし、ホストは、フレームワーク１００を介してホストの勧誘の首尾良い受諾の確認応答は受信することはなく、またホストはデータベース１０３にユーザ情報および状況についても問い合わせ得ない。

２１０で、共同モードを選択すると、図７に示すように、ホストには共同セッションにおけるユーザのリストが提示される。当初、ホストは共同セッションでの唯一の参加者であり、ホストには唯一の参加者であることが示される。ホストは、「オンコールで勧誘（ＩｎｖｉｔｅｗｉｔｈＯｎＣａｌｌ）」（図８Ａ）を選択することによりまたは共同図解ユーザインタフェース８００の「オンコール」アイコンをクリックすることにより、図１のフレームワーク１００を用いて勧誘を送信する決定を行える）。

２１２で、図９Ａ〜９Ｃのユーザインタフェースに受信された、「オンコールで勧誘」のユーザ選択に応じて、ホストのクライアントコンピューティングデバイスに、登録者が列挙される。登録者は、共同セッションに出席する、例えば、医療画像を見る、ことを利用でき、許可されおよび／または資格があるユーザであり得る。リストは、図９Ａに示すように、単なるユーザのリストとして提示され得る。図９Ｂに示すように、リストは、同様な状況下のユーザのグループ（例えば、精神医学、心臓病学、整形外科学）として提供され、グループ識別子９００下に編成され得る。図９Ｃに示すように、付加的な情報が登録済みのホストに対して、各ユーザの状況、例えば、ユーザは現在対応可能かまたは通知を受信できるか、に関して提示され得る。

したがって、上記では、ホストは、共同モードを有効化するためのレジストリサービス１０６に登録され得またはされ得ない。ホストが未登録であれば、登録者のリストを問い合わせるための、例えば、ウェブブラウザまたはクライアントアプリケーションを用いて、レジストリサービス１０６にアクセスし得る。ホストが登録済みであれば、ホストは、通知アプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎを用いて、レジストリサービス１０６に登録者に関して問い合わせ得る。レジストリサービス１０６は、次いで、登録者に、限定はされないが、通知を伴う勧誘内のホストユーザの識別子等の、通知付の付加的な情報を送付し得る。

２１４で、勧誘され得る登録者の（例えば、ホストからの）ユーザ選択が、ホストのクライアントコンピューティングデバイスに表示されるユーザインタフェース内に受信される。図１０に示すように、１人以上の登録者が２１４で選択され得る。あるいはまたは加えて、メッセージは、勧誘付で送付され得る。選択はレジストリサービス１０６（フロー３０８）に送付され得、勧誘と関連情報（例えば、メッセージ）とを含む通知が２１６（フロー３１０）で選択された登録者に送信されることを可能にする。例えば、図１１に示すように、通知メッセージが、選択された登録者のコンピューティングデバイス上に提示される。通知は、登録者のコンピューティングデバイス上の通知クライアントアプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎにより受信され得る（フロー３１２）。

一部の実装例によれば、グループ識別子９００を選択することにより、勧誘がグループ全体に送付され得る。よって、神経科医グループを選択したとき、全神経科医と関連付けられたコンピューティングデバイスが、通知を受信し得る。更に、図１８に関連して以下に説明するように、通知は、ユーザと関連付けられた所定のまたは全部のデバイスに送信され得る。例えば、ユーザがタブレット、携帯電話およびデスクトップと関連していれば、３つの全デバイスまたはこれらのデバイスの組合せは、フロー３１２で送付された勧誘を受信し得る。

２１８で、登録者は共同セッションに加えられる。参加者が通知／勧誘を受諾すれば、（フロー３１４）、登録者は参加者として自動的に、例えば、クライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎが、勧誘内のＵＲＬを介して参加者のコンピューティングデバイス上で起動される。任意選択的に、確認応答が勧誘された登録者からレジストリサーバ１０６に送信され得る（フロー３１６）かつ／または勧誘と共にメッセージが送付されていれば、読まれた受領書が登録済みのホストに送信され得る（フロー３１８）。ホストは、図１２に示すように、加えられた参加者の全員をユーザインタフェースで見ることができる。構成を行えば、全参加者が図１２に示す参加者のリストを見ることができる。２２０で、共同セッションは継続し、全ユーザがクライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎとやりとりを行うことができる。

動作フロー２００の特定の実施例では、ホストは、クライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎとして起動される画像視聴アプリケーションとやりとりを行っているかもしれず、医療画像アプリケーションは、ＣａｌｇａｒｙＳｃｉｅｎｔｉｆｉｃ，Ｉｎｃ．（Ｃａｌｇａｒｙ，Ａｌｂｅｒｔａ，Ｃａｎａｄａ）から入手可能なＲＥＳＯＬＵＴＩＯＮＭＤでよい。そのため、２０６で、図１３Ａに示すような、ユーザインタフェースが提示され得る。図１３Ａのユーザインタフェース内から、ユーザは、図１３Ｂに示すコントロールを有効化することにより共同セッションを開始でき、画像視聴アプリケーションを用いて画像を見る他のユーザに加えることができる。例えば、図１３Ｂの共同のコントロールは、図７〜９のユーザインタフェースを提示でき、上述したように、ユーザが共同セッションに勧誘するために他のユーザを選択することを可能にする。

任意選択的にまたは加えて、フレームワーク１００は、「アプリケーションプログラムの状態への遠隔アクセスを提供するための方法およびシステム（ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＰＲＯＶＩＤＩＮＧＲＥＭＯＴＥＡＣＣＥＳＳＴＯＡＳＴＡＴＥＯＦＡＮＡＰＰＬＩＣＡＴＩＯＮＰＲＯＧＲＡＭ）」と題する米国特許出願第１２／５９２、４７３号に開示されたもの等、遠隔アクセス環境に組み込まれ得る。遠隔アクセス環境の例としては、ＣａｌｇａｒｙＳｃｉｅｎｔｉｆｉｃ，Ｉｎｃ．（Ｃａｌｇａｒｙ，Ａｌｂｅｒｔａ，Ｃａｎａｄａ）から入手可能な、ＰＵＲＥＷＥＢがある。クライアントコンピューティングデバイスにより遠隔アクセスされたアプリケーションは、増大されて、遠隔アクセスしたアプリケーションのユーザが他者を迅速に共同させ得るように、通知および勧誘フレームワーク１００を含み得る。

図１４は、図１の環境内で実装され得る別の動作フロー１４００を示す。動作フロー１４００は、クライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎとしての画像視聴アプリケーションという面で説明するが、任意のアプリケーションをクライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎで実行させ得る。１４０２で、処理が開始するが、この場合ユーザは、１４０４で、画像視聴アプリケーションをクライアントアプリケーション１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎとして起動して、クライアントコンピューティングデバイス上で画像を見ることができる。コントロールメニュー１５０２を含むユーザインタフェース１５００（図１５）を表示でき、これは１４０６でユーザにより有効化されたときに表示され得る。１４０８で、ユーザは、コントロールメニュー１５０２に提示された選択肢の中から選択を行える。１４１０で、コントロールメニュー１５０２内でどの選択を受信するかが決定される。

１４１０での選択が「オンコール共同（ＯｎＣａｌｌＣｏｌｌａｂｏｒａｔｉｏｎ）」であるとであると決定されると、本開示のオンコール通知クライアントアプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎが、共同セッションを開始するように使用される。そのため、ステップ２１０〜２１４（図２）がステップ１４１２で遂行される。ユーザインタフェース１５００内から、共同勧誘窓１５０４が１４１４で提示され得る。１４１６で、ホストユーザは、勧誘の一部として選択された登録者（複数可）に通信される本文を入力し得る（例えば、２１４から）。標準の勧誘メッセージを用いて、共同勧誘窓１５０４を事前設定することができる。ホストユーザは、共同勧誘窓１５０４内に示される送信ボタンをクリックすることにより勧誘を送信し得る。１４１８で、ステップ２１６〜２２０が遂行され、それにより選択された登録者が共同セッションに加えられる。

１４１０での選択が「オンコール共有（ＯｎＣａｌｌＳｈａｒｅ）」であると決定されると、本開示のオンコール通知クライアントアプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎが共有動作を開始するために使用されて、セッションを選択された登録者に送る。図１６に示すようなユーザインタフェースが表示され得る。ユーザインタフェース１６００にはコントロールメニュー１５０２が示され、これは１４０６でユーザにより有効化されたときに表示される。１４２０で、共有勧誘窓１６０４がホストユーザに提示され得る。例えば、共有勧誘窓１６０４は、ホストユーザが、レジストリサービス１０６により提示されたユーザのリストから選択した後に提示され得る。この処理は、前述した共同動作モードと同様である。１４２２で、ホストユーザは、勧誘の一部として選択された登録者（複数可）に通信される本文を入力し得る。標準の勧誘メッセージを用いて、共有勧誘窓１６０４を事前設定できる。加えて、ホストユーザは、優先レベルまたは状態１６０６（例えば、緊急、即座、危篤、正規、再検討、セカンドオピニオン、など）を選択し得る。ホストユーザは、共有勧誘窓１６０４内に示された送信ボタンをクリックすることにより勧誘を送信し得る。１４２４で、勧誘がレジストリサービス１０６に送付され得、通知を選択された登録者（複数可）に２１６で送信することが可能になる。通知は、登録者のコンピューティングデバイス上の通知クライアントアプリケーション１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎにより受信され得る。登録者は、１４２６で応答が受信されかつアクションが遂行されるように、前述したように、「受諾」／「選択無視」を行える。登録者が受諾すると、１４２８で、セッションが登録者に転送される。

１４１０で選択が「共同」であれば、図１のフレームワーク１００を用いるのではなく、１４２０で既存の共同メカニズムを用いて共同が遂行され得る。

フレームワーク１００の管理例

前述に加えて、管理モジュールをフレームワーク１００上に階層形成して、フレームワーク１００の態様を管理および制御し得る。管理モジュールは、組織（例えば、健康管理組織、病院、内視鏡的粘膜切除術）に対するインタフェースを提供し得、フレームワーク１００を用いているであろうそれらの組織内の個人（例えば、放射線科医）のユーザデータをロードし得る。一般的に、組織管理者およびユーザは、管理モジュールにログインし、そのユーザアカウントと関連付けられたデバイスと、２つ以上のデバイスが単一のユーザと関連付けられたときにメッセージを受信する優位性とを特定し得る（例えば、勧誘をユーザのタブレットにその電話機に送信する前に送信するか、または同時に両方に送信する）。

態様例では、管理モジュールは、組織の管理者が、通知をユーザにまたはユーザのグループに送付する規則を設定することを可能にする。管理モジュールは、任意のユーザが別のユーザを共同セッションに勧誘することを可能にする。一部の実装例では、ユーザが共同要求を別のユーザに送信し得るかが、管理モジュールにより決定される。この決定は、現在の日付／時刻、ユーザの地理的位置、ユーザに対する所定のオンコール予定、またはそれらの状況を手動特定するユーザを（限定はされないが）含む、管理モジュール内の一連の規則により行われる。

管理モジュールは、データベース１０３内に格納された予定表調整情報に従って規則を適用する。任意選択的に、予定表調整情報はＧＯＯＧＬＥ等の、サービスで格納され得る。対応可否は、予定表調整情報に従って自動的にオフまたはオンに切り替えられ得る。管理モジュールは、ユーザが規則と関連付けられた位置（例えば、病院）を入力すると、通知がユーザのデバイスに送付されるように、存在情報を規則と組み合わせて使用し得る。一部の実装例では、近接度が対応可否の尺度として使用され得る。例えば、病院の特定の範囲内に存在すると決定されたユーザは、対応可能とみなされ得るが、ユーザが他の範囲にいる場合、そのユーザは対応可能ではないと決定され得る。管理モジュールは、また、共同への勧誘がプライバシーに関する法的規則に合致することを確実化し得る（例えば、ユーザが組織的境界を超えて医療画像を共有することを望む場合、管理モジュールは、データを匿名化することを確実化し得る）。付加的なワークフローが組み込まれ得る。

図１７を参照すると、通知を管理するために図１のフレームワークの管理モジュールを使用し得る汎組織ネットワークが示されている。管理モジュールは、１クラスまたはユーザまたは１位置を有する小組織内、数クラスまたはユーザまたは数位置を有する大組織内、または異なる実体にまたがる本質的に汎組織内で使用され得る。実施例では、健康管理関連のユーザは、診断に関する即時のセカンドオピニオンを得るための遠隔放射線診断等の、管理モジュールに付随する第３者サービスとの共同を開始し得る。更に、ユーザは、管理モジュールを、第３者放射線医学トレーニングサービスにより運営される共同トレーニングセッションの参加者またはリーダーのいずれかになるために使用し得る。他の使用例も考えられる。

多くの他の汎用または特別目的のコンピューティングシステム環境または構成が、使用され得る。使用に適するであろう周知のコンピューティングシステム、環境、および／または構成の例は、限定されるものではないが、パーソナルコンピュータ、サーバーコンピュータ、手持ち型またはラップトップ型デバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、ネットワークパーソナルコンピュータ（ＰＣ）、ミニコンピュータ、メインフレームコンピュータ、埋め込み型システム、上記システムまたはデバイスのいずれかを含む分散型コンピューティング環境、および同様のものを含む。

コンピュータによって実行される、例えばプログラムモジュールなどのコンピュータで実行可能な命令が、使用され得る。一般的に、プログラムモジュールは、特定のタスクを機能させるまたは特定の抽象データ種類を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。分散型コンピューティング環境が、使用され得、そこでは、タスクは、通信ネットワークまたは他のデータ伝送媒体を通してつなげられる遠隔処理デバイスによって機能される。分散型コンピューティング環境では、プログラムモジュールおよび他のデータは、メモリ記憶デバイスを含むローカルおよび遠隔の両方のコンピュータ記憶媒体内に位置し得る。

図１８は、例示的な実施形態および態様が実装されてもよい、例示的なコンピューティング環境を示す。このコンピューティングシステム環境は、適切なコンピューティング環境の一例に過ぎず、使用または機能の範囲の何らかの制限を示唆することを目的としない。

図１８を参照にして、本明細書において説明される態様を実装するための例示的なシステムは、コンピューティングデバイス１８００などのコンピューティングデバイスを含む。それの最も基本的な構成において、コンピューティングデバイス１８００は、典型的には少なくとも１つの処理部１８０２およびメモリ１８０４を含む。正確な構成およびコンピューティングデバイスの種類次第で、メモリ１８０４は、揮発性（例えば、ランダムアクセスメモリ（ＲＡＭ）など）、不揮発性（例えば、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリなど）、またはその２つのいくつかの組み合わせとすることができる。これの最も基本的な構成は、破線１８０６によって図１８に例示される。

コンピューティングデバイス１８００は、付加的な特徴／機能性を有し得る。例えば、コンピューティングデバイス１８００は、限定されるものではないが、磁気もしくは光学ディスクまたはテープを含む付加的な（取り外し可能および／または取り外し不可能な）記憶装置を含み得る。そのような付加的な記憶装置は、取り外し可能な記憶装置１８０８および取り外し不可能な記憶装置１８１０によって、図１８に例示される。

コンピューティングデバイス１８００は、典型的には、種々のコンピュータで読み取り可能な媒体を含む。コンピュータで読み取り可能な媒体は、デバイス１８００によってアクセスされ得る任意の可用な媒体とすることができ、揮発性と不揮発性の媒体、取り外し可能および取り外し不可能な媒体の両方を含む。

コンピュータ記憶媒体は、例えばコンピュータで読み取り可能な命令、データ構造、プログラムモジュールまたは他のデータなどの情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性の、ならびに取り外し可能および取り外し不可能な媒体を含む。メモリ１８０４、取り外し可能な記憶装置１８０８、および取り外し不可能な記憶装置１８１０は、すべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体は、限定されるものではないが、ＲＡＭ、ＲＯＭ、電気的に消去可能なプログラム読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を格納するために使用され得るおよびコンピューティングデバイス１８００によってアクセスされ得る任意の他の媒体を含む。任意のそのようなコンピュータ記憶媒体は、コンピューティングデバイス１８００の一部とすることができる。

コンピューティングデバイス１８００は、デバイスが他のデバイスと通信することを可能にする（複数可）通信接続１８１２を含み得る。コンピューティングデバイス１８００はまた、例えばキーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの（複数可）入力デバイス１８１４を含み得る。ディスプレイ、スピーカ、プリンタなどの（複数可）出力デバイス１８１６もまた、含まれ得る。すべてのこれらのデバイスは、当技術分野において周知であり、ここで長々と記述される必要はない。

本明細書において説明される様々な技法は、ハードウェアまたはソフトウェアに関して、あるいは適切な場合には両者の組み合わせに関して実装され得ることが理解されるべきである。それ故、現在開示された主題の方法および装置、あるいはそれらの一定の態様または部分は、例えばフロッピー(登録商標)ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または任意の他の機械で読み取り可能な記憶媒体などの具体的な媒体に具現化されたプログラムコード（すなわち、命令）の形態を取り得、プログラムコードがコンピュータなどの機械にロードされ、その機械によって実行されると、機械は、現在開示された主題を実践するための装置になる。プログラム化できるコンピュータ上のプログラムコードの実行の場合には、コンピューティングデバイスは、一般的に、プロセッサ、プロセッサによって読み取り可能な（揮発性および不揮発性メモリならびに／あるいは記憶要素を含む）記憶媒体、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含む。１つ以上のプログラムは、例えば、アプリケーションプログラミングインターフェース（ＡＰＩ）、再使用可能な制御装置、または同様のものの使用を通して、現在開示された主題に関して説明される処理を実装し得るまたは利用し得る。そのようなプログラムは、コンピュータシステムと通信するための高レベル手順またはオブジェクト指向プログラミング言語で実装され得る。しかしながら、（複数可）プログラムは、必要に応じて、アセンブリまたは機械言語で実装され得る。いずれの場合においても、言語は、コンパイルされたまたは解釈された言語であり得、それは、ハードウェア実装と組み合わされ得る。

主題は、構造的特徴および／または方法の動作に特有の言語で説明されたが、添付の特許請求の範囲において定義された主題は、必ずしも上記特有の特徴または動作に限定されないことが理解されることになる。むしろ、上記特有の特徴または動作は、特許請求の範囲を実施する形態例として開示される。

Claims

ホストからユーザ登録情報および少なくとも１人の登録済みのユーザをセッションに参加させるための勧誘要求を受信するレジストリサービスと、
前記ユーザ登録情報および前記勧誘要求を格納するデータベースと、を備え、
前記レジストリサービスは、前記勧誘要求を、前記勧誘要求のプッシュ通知を前記少なくとも１人の登録済みのユーザと関連付けられたユーザデバイスに提供するプッシュサービスに通信し、
前記フレームワークは、前記ホストと前記少なくとも１人の登録済みのユーザとの間のセッションをその場で開始するように適合される、通知フレームワーク。
前記レジストリサービスは、前記少なくとも１人の登録済みのユーザの対応可否情報を前記ホストに公開する、請求項１に記載の通知フレームワーク。
前記セッションに加えるための前記レジストリサービスにより送信される前記勧誘要求は、前記少なくとも１人の登録済みのユーザと関連付けられた前記ユーザデバイスを前記セッションに加えるための情報を含む、請求項１〜２のいずれかに記載の通知フレームワーク。
前記少なくとも１人の登録済みのユーザと関連付けられた前記ユーザデバイスを前記セッションに加えるための前記情報は、前記セッションの統一資源ロケータ（ＵＲＬ）を含む、請求項３に記載の通知フレームワーク。
前記勧誘要求の受諾の際に、前記少なくとも１人の登録済みのユーザと関連付けられた前記ユーザデバイスから確認応答が返送される、請求項３〜４のいずれかに記載の通知フレームワーク。
前記勧誘要求の受諾の際に、前記少なくとも１人の登録済みのユーザは、前記セッションに自動的に加えられる、請求項３〜５のいずれかに記載の通知フレームワーク。
前記ユーザデバイス上で実行される通知アプリケーションを更に含み、前記通知アプリケーションは前記勧誘要求を待ち、前記通知アプリケーションは前記ユーザデバイスを前記セッションに加える、請求項１〜６のいずれかに記載の通知フレームワーク。
前記通知アプリケーションは、前記ユーザ登録情報およびユーザ対応可否情報を前記レジストリサービスに通信するように適合される、請求項７に記載の通知フレームワーク。
前記通知アプリケーションは、前記ユーザデバイス上で動作するウェブブラウザを実行しているウェブクライアントである、請求項７〜８のいずれかに記載の通知フレームワーク。
前記ウェブクライアントはＨＴＭＬ５アプリケーションであり、前記レジストリサービスに通信するためにＪａｖａＳｃｒｉｐｔ(登録商標)ライブラリが用いられる、請求項９に記載の通知フレームワーク。
前記通知アプリケーションは、プラットフォーム特有のプッシュ通知メカニズムを使用して前記勧誘要求を受信する前記ユーザデバイス上で動作するネイティブアプリケーションである、請求項７〜１０のいずれかに記載の通知フレームワーク。
前記レジストリサービスは、組織構造に基づいて登録済みのユーザのカテゴリを提供する、請求項１〜１１のいずれかに記載の通知フレームワーク。
前記セッションは、共同セッションまたはアプリケーション共有セッションのうちの１つである、請求項１〜１２のいずれかに記載の通知フレームワーク。
前記ホストは登録済みのユーザである、請求項１〜１３のいずれかに記載の通知フレームワーク。
前記レジストリサービスは、勧誘要求が送付される登録済みのユーザの優先順位づけを提供する、請求項１〜１４のいずれかに記載の通知フレームワーク。
通知フレームワークを用いてホストと少なくとも１人の登録済みのユーザとの間でセッションを開始する方法であって、
前記ホストからセッションを始めるための指示を受信することと、
ユーザインタフェースを、前記セッションに加えるべき前記少なくとも１人の登録済みのユーザであって、登録サービスにより登録済みのユーザのデータベースから取得される少なくとも１人の登録済みのユーザで設定することと、
前記セッションに加えるべき前記少なくとも１人の登録済みのユーザを、前記少なくとも１人の登録済みのユーザと関連付けられたコンピューティングデバイスに対して勧誘要求をプッシュする通知処理を介して、勧誘することと、
前記少なくとも１人の登録済みのユーザからの前記勧誘の受諾に応じて、前記少なくとも１人の登録済みのユーザを前記セッションに加えることと、を含む、方法。
前記少なくとも１人の登録済みのユーザの対応可否状況を決定することを更に含む、請求項１６に記載の方法。
前記少なくとも１人の登録済みのユーザが対応可能である場合のみ、前記少なくとも１人の登録済みのユーザを前記ユーザインタフェースに設定することを更に含む、請求項１６〜１７のいずれかに記載の方法。
前記ユーザインタフェースを前記登録済みのユーザのグループで設定することを更に含み、前記グループは前記登録済みのユーザの属性に従って予め定義した、請求項１６〜１８のいずれかに記載の方法。
前記勧誘要求内に前記セッションの統一資源ロケータ（ＵＲＬ）を含むことを更に含む、請求項１６〜１９のいずれかに記載の方法。
前記勧誘要求の受諾の際に、前記少なくとも１人の登録済みのユーザを前記セッションに自動的に加えることを更に含む、請求項１６〜２０のいずれかに記載の方法。
前記勧誘要求が前記少なくとも１人の登録済みのユーザにより受信された前記ホストと関連付けられたユーザデバイスで、前記少なくとも１人の登録済みのユーザから確認応答を受信することを更に含む、請求項１６〜２１のいずれかに記載の方法。
前記少なくとも１人の登録済みのユーザと関連付けられたユーザデバイス上で実行される通知アプリケーションであって、前記勧誘要求を待つ通知アプリケーションを提供することと、
前記通知アプリケーションを用いて前記ユーザデバイスを前記セッションに加えることと、を更に含む、請求項１６〜２２のいずれかに記載の方法。
前記セッションは、共同セッションまたはアプリケーション共有セッションのうちの１つである、請求項１６〜２３のいずれかに記載の方法。
前記ホストは登録済みのユーザである、請求項１６〜２４のいずれかに記載の方法。
前記レジストリサービスは、勧誘要求が送付される登録済みのユーザの優先順位づけを提供する、請求項１６〜２５のいずれかに記載の方法。
通知フレームワーク内でワークフローを管理する方法であって、
各々がユーザアカウントを有するユーザを、前記通知フレームワークの登録サービスに登録することと、
少なくとも１つのユーザデバイスを各ユーザアカウントと関連付けることと、
ホストからの通知要求に応じて規則を適用して、第２のユーザをセッションに加えるように勧誘することと、
前記規則に応じて、前記通知を前記第２のユーザに送付することと、
前記第２のユーザからの前記通知の確認応答の受領に際して、前記第２のユーザを前記セッションに加えることと、を含む、方法。
ユーザアカウントと関連付けられた２つ以上のユーザデバイスが存在する場合に、優先順位を指示することと、
前記優先順位に基づいて前記２つ以上のユーザデバイスに通知を送付することと、を更に含む、請求項２７に記載の方法。
前記規則は、前記通知を送付するかについて、現在の日付または時刻、前記第２のユーザの地理的位置、前記第２のユーザに対する所定の予定、および状況を手動特定している前記第２のユーザのうちの少なくとも１つに従って決定することを含む、請求項２７〜２８のいずれかに記載の方法。
登録済みのユーザが前記セッションへ加える対応可否を、データベース内に維持することを更に含む、請求項２７〜２９のいずれかに記載の方法。
前記通知をユーザのグループに前記規則に従って送付することを更に含む、請求項２７〜３０のいずれかに記載の方法。
前記セッションは、共同セッションまたはアプリケーション共有セッションのうちの１つである、請求項２７〜３１のいずれかに記載の方法。