特許 6276709 コンテキストに基づくアプリケーションとの対話処理

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

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

(11)【特許番号】6276709

(24)【登録日】2018年1月19日

(45)【発行日】2018年2月7日

(54)【発明の名称】コンテキストに基づくアプリケーションとの対話処理

(51)【国際特許分類】

   G06F 9/48 20060101AFI20180129BHJP

   G06F 9/54 20060101ALI20180129BHJP

【ＦＩ】

   G06F9/46 452H

   G06F9/46 480Z

【請求項の数】19

【全頁数】14

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

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

(65)【公表番号】特表2015-507311(P2015-507311A)

(43)【公表日】2015年3月5日

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

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

(87)【国際公開日】20130822

【審査請求日】2016年2月12日

(31)【優先権主張番号】13/399,981

(32)【優先日】2012年2月17日

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

(73)【特許権者】

【識別番号】314015767

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

(74)【代理人】

【識別番号】100140109

【弁理士】

【氏名又は名称】小野 新次郎

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100106208

【弁理士】

【氏名又は名称】宮前 徹

(74)【代理人】

【識別番号】100120112

【弁理士】

【氏名又は名称】中西 基晴

(74)【代理人】

【識別番号】100173565

【弁理士】

【氏名又は名称】末松 亮太

(72)【発明者】

【氏名】ハーツ，ジョージ・イー

(72)【発明者】

【氏名】フサリ，デーヴィッド

【審査官】 小林 哲雄

(56)【参考文献】

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

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

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

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

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

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

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

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

【文献】 国際公開第２０１１／０２７４９２（ＷＯ，Ａ１）

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

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

Ｇ０６Ｆ ９／４６−９／５４

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

【請求項1】

１つのコンピューター読み取り可能記憶媒体であって、コンピューターに、
第１アプリケーションが前記コンピューター上で実行されている間に、コンピューター・ネットワークを通じてユニバーサル・リソース識別子（ＵＲＩ）を受信させ、前記ＵＲＩが、
ＵＲＩ方式と、
前記コンピューターにインストールされている第２アプリケーションであって、前記ＵＲＩを受信するときには起動していない第２アプリケーションと、
前記第１アプリケーションおよび前記第２アプリケーションによって使用可能な共有コンテキストを定義する少なくとも２つの異なるアプリケーション・パラメーターと
を指定し、
前記ＵＲＩがユーザーによって選択されたことを検出させ、前記第１アプリケーションにおいて表示されたユーザー・インターフェースを介して前記ユーザーが前記ＵＲＩを選択しており、
前記第１アプリケーションにおいて前記表示されたユーザー・インターフェースを介して前記ユーザーによって前記ＵＲＩが選択されたことの検出に応じて、前記ＵＲＩによって指定される前記第２アプリケーションを起動させ、
前記第１アプリケーションが保存されていないデータを有する場合、前記第１アプリケーションに該第１アプリケーションの現在のコンテキストを保存させ、
前記第１アプリケーションおよび前記第２アプリケーションを、前記少なくとも２つの異なるアプリケーション・パラメーターによって定義される前記共有コンテキストを用いて実行させる、
プログラムを記録したコンピューター読み取り可能記憶媒体。

【請求項2】

請求項１記載のコンピューター読み取り可能記憶媒体であって、更に、前記プログラムが、前記コンピューターに、前記第２アプリケーションを起動する前に、前記第２アプリケーションの起動が前記コンピューター上で許可されているかを判断させる、コンピューター読み取り可能記憶媒体。

【請求項3】

請求項２記載のコンピューター読み取り可能記憶媒体であって、更に、前記プログラムが、前記コンピューターに、前記第２アプリケーションの起動が前記コンピューターについて規定された許可済みアクションのリスト上にあることを検証させる、コンピューター読み取り可能記憶媒体。

【請求項4】

請求項１記載のコンピューター読み取り可能記憶媒体であって、更に、前記プログラムが、前記コンピューターに、前記ＵＲＩによって指定される前記第２アプリケーションの起動の前に、前記ＵＲＩのソースの信頼性を評価させる、コンピューター読み取り可能記憶媒体。

【請求項5】

請求項１記載のコンピューター読み取り可能記憶媒体であって、更に、前記プログラムが、前記コンピューターに、前記ＵＲＩによって指定される前記第２アプリケーションの起動の前に、前記ＵＲＩの署名を評価させる、コンピューター読み取り可能記憶媒体。

【請求項6】

前記ＵＲＩが別のコンピューター上のリモート・アプリケーションから受信される、請求項１記載のコンピューター読み取り可能記憶媒体。

【請求項7】

前記少なくとも２つの異なるアプリケーション・パラメーターが前記ＵＲＩ方式の後の前記ＵＲＩのクエリ部に含まれる、請求項１記載のコンピューター読み取り可能記憶媒体。

【請求項8】

前記第２アプリケーションを指定する識別子が前記ＵＲＩ内でコロン記号の後、前記ＵＲＩの前記クエリ部の前に現れる、請求項７記載のコンピューター読み取り可能記憶媒体。

【請求項9】

請求項１記載のコンピューター読み取り可能記憶媒体であって、更に、前記プログラムが、前記コンピューターに、前記第１アプリケーションが前記保存されていないデータを有する場合、前記第１アプリケーションに該第１アプリケーションの前記現在のコンテキストを保存させるまで、前記共有コンテキストへの変更を遅延させる、コンピューター読み取り可能記憶媒体。

【請求項10】

コンピューターであって、
当該コンピューターにインストールされる、第１アプリケーションおよび第２アプリケーションを含む１組のアプリケーションを備え
コンテキスト定義ＵＲＩのＵＲＩ方式と、
前記第１アプリケーションと、
前記第２アプリケーションと、
前記第１アプリケーションおよび前記第２アプリケーションについての共有コンテキストであって、前記コンテキスト定義ＵＲＩが受信されるときに、前記第１アプリケーションが起動しており、前記第２アプリケーションが起動していない、共有コンテキストと
を指定する前記コンテキスト定義ＵＲＩを受信し、
前記第１アプリケーションが保存されていないデータを有する場合、前記第１アプリケーションに該第１アプリケーションの現在のコンテキストを保存させ、
前記第１アプリケーションおよび前記第２アプリケーションに、前記コンテキスト定義ＵＲＩによって指定される前記共有コンテキストを使用させる
ように構成される、コンピューター。

【請求項11】

請求項１０記載のコンピューターにおいて、更に、
前記コンテキスト定義ＵＲＩを電子メール・メッセージで受信し、
当該コンピューターのディスプレイ上に前記電子メール・メッセージを表示し、
前記表示された電子メール・メッセージにおいて、前記コンテキスト定義ＵＲＩのユーザー選択を受け、
前記コンテキスト定義ＵＲＩの前記ユーザー選択に応じて、前記第２アプリケーションを起動するように構成される、コンピューター。

【請求項12】

前記コンテキスト定義ＵＲＩが、特定の人物の少なくとも２つの異なる識別子を用いて、前記共有コンテキストを指定する、請求項１０記載のコンピューター。

【請求項13】

請求項１２記載のコンピューターにおいて、前記ＵＲＩの第１フィールドが前記第１アプリケーションに対して前記特定の人物を識別し、前記ＵＲＩの第２フィールドが前記第２アプリケーションに対して前記特定の人物を識別する、コンピューター。

【請求項14】

請求項１０記載のコンピューターであって、更に、前記１組のアプリケーションの一部ではなく、また、前記コンテキスト定義ＵＲＩを生成するように構成される別のアプリケーションを含む、コンピューター。

【請求項15】

コンピューターによって実行される方法であって、
第１アプリケーションを前記コンピューター上で起動するステップと、
第１アプリケーションが実行されている間に、ユニバーサル・リソース識別子（ＵＲＩ）を受信するステップであって、前記ＵＲＩが、
ＵＲＩ方式と、
前記コンピューターにインストールされている第２アプリケーションであって、前記ＵＲＩを受信するときには起動していない、第２アプリケーションと、
前記第１アプリケーションおよび前記第２アプリケーションについての共有コンテキストの少なくとも２つの異なるアプリケーション・パラメーターと
を指定する、ステップと、
前記ＵＲＩが選択されたことを検出するステップと、
前記ＵＲＩが選択されたことの検出に応じて、前記ＵＲＩによって指定される前記第２アプリケーションを起動するステップと、
前記第１アプリケーションが保存されていないデータを有する場合、前記第１アプリケーションに該第１アプリケーションの現在のコンテキストを保存させるステップと、
前記第１アプリケーションおよび前記第２アプリケーションの両方を、前記共有コンテキストを用いて実行させるステップと
を含む、方法。

【請求項16】

請求項１５記載の方法であって、更に、
前記コンピューター上の隔離されたセキュリティ環境でコンテキスト・プロトコル・ハンドラーを実行するステップと、
前記ＵＲＩを受信すると、前記隔離されたセキュリティ環境で実行している前記コンテキスト・プロトコル・ハンドラーを用いて前記ＵＲＩを処理するステップと、
前記隔離されたセキュリティ環境で実行している前記コンテキスト・プロトコル・ハンドラーによって前記ＵＲＩが処理された後に、前記第２アプリケーションの起動をトリガーするステップと
を含む、方法。

【請求項17】

請求項１５記載の方法であって、更に、
前記受信したＵＲＩをグラフィカル・ウェブ・ブラウザーの保護モードで処理するステップと、
前記ＵＲＩが前記グラフィカル・ウェブ・ブラウザーの保護モードで処理された後に、前記第２アプリケーションの起動をトリガーするステップと
を含む、方法。

【請求項18】

請求項１５記載の方法において、前記第１アプリケーションがウェブ・ベース電子記録マネージャーであり、前記第２アプリケーションが画像ビューアである、方法。

【請求項19】

請求項１８記載の方法において、
前記ＵＲＩによって定義される前記共有コンテキストが人物であり、
前記ウェブ・ベース電子記録マネージャーが、前記ＵＲＩの前記共有コンテキストによって識別される前記人物についての電子記録を提供し、
前記画像ビューアは、前記ＵＲＩの前記共有コンテキストによって識別される前記人物に関連づけられるイメージを提供する、方法。

【発明の詳細な説明】

【背景技術】

【0001】

従前より、計算のシナリオは、ユーザーが個別にアプリケーションと対話処理することを伴う。更に進んだシナリオでは、共通のコンテキストに関する異なる機能を提供する複数のアプリケーションを伴う。例えば、医者のようなユーザーが、患者を診察するときに、撮像アプリケーションおよび記録管理アプリケーションを利用することがあり得る。コンテキスト管理システムは、共通のコンテキストに対する異種アプリケーションのライフサイクル(lifecycle)管理およびその調整を可能にすることができる。アプリケーションの共通コンテキストへの統合は、複雑な作業であり、コンテキスト管理システムによる、そして更に特記すべきは、ユーザーによる大量のアクションを必要とすることが多い。

【発明の概要】

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

【0002】

本明細書は、コンテキストに基づくアプリケーションとの対話処理に関する。一例として、１組のアプリケーションがインストールされたコンピューターを含むことができる。また、この例は、コンテキスト定義ＵＲＩを受信するように構成されたユニバーサル・リソース識別子（ＵＲＩ）マネージャーも含むことができる。ＵＲＩマネージャーは、これらのアプリケーションの内、コンテキスト定義ＵＲＩによって指定された部分集合を実行させ、コンテキスト定義ＵＲＩによって指定されたとおりに、アプリケーションの部分集合に対して共通のコンテキストを設定するように構成される。

【0003】

他の例では、エンティティに関する情報を受信することができる。この例は、コンテキスト定義ＵＲＩのようなリンクを生成することができる。このリンクは、コンピューター上にインストールされたアプリケーション、およびエンティティに関係するコンテキストをアプリケーションに対して指定する。

【0004】

更に他の例では、実行するアプリケーションを指定し、このアプリケーションに対してコンテキストを定めるコンテキスト定義ＵＲＩを受信することができる。この例では、そのアプリケーションを実行し、コンテキスト定義ＵＲＩによって定められるとおりに、このアプリケーションのコンテキストを設定することができる。

【0005】

以上に列挙した例は、読み手を補助するための素早い参考を提供することを意図するものであり、本明細書において説明する概念の範囲を定めることを意図するものではない。
添付図面は、本願において伝えられる概念の実施態様を例示する。例示される実施態様の特徴は、添付図面と併せて以下の説明を参照することによって、一層容易に理解することができる。種々の図面において、同様のエレメントを示すために使用可能なときはいつでも、同様の参照番号が使用される。更に、各参照番号の左端の数値は、その参照番号が最初に導入される図および関連する論述を伝える。

【図面の簡単な説明】

【0006】

【図1】図１は、実施態様にしたがって、コンテキストに基づいてアプリケーションと対話処理する概念を採用することができるシステムを示す。

【図2】図２は、本概念の実施態様にしたがって、コンテキストに基づいてアプリケーションと対話処理する使用事例を示す。

【図3】図３は、本概念の実施態様にしたがって、コンテキストに基づいてアプリケーションと対話処理する使用事例を示す。

【図4】図４は、本概念の実施態様にしたがって、コンテキストに基づいてアプリケーションと対話処理する方法のフローチャートの例を示す。

【図5】図５は、本概念の実施態様にしたがって、コンテキストに基づいてアプリケーションと対話処理する方法のフローチャートの例を示す。

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

【0007】

全体像
本特許は、共通のコンテキストの下におけるアプリケーションの起動を可能にすることに関するものである。更に特定すれば、１つ以上のアプリケーションを自動的に起動するために、ユニフォーム・リソース識別子（ＵＲＩ）を利用することができる。また、ＵＲＩは、ＵＲＩをアクティブ化するユーザーによって単純に、アプリケーションに対する共通のコンテキストを設定する(establish)こともできる。本発明の概念は、ウェブ、またはポータル・ウェブサイトのような他のアプリケーションが、複雑な統合をすることなく、アプリケーションを起動しコンテキストを選択することができる。
システム例
図１は、共通コンテキスト・アプリケーション起動を実現することができるシステム１００を示す。この場合、システム１００はコンピューター１０２を含む。このコンピューターは、ウェブ・アプリケーションまたはウェブ・ポータルのようなリモート・アプリケーション１０４と、ネットワーク１０６を通じて通信することができる。また、コンピューター１０２は、ローカル・アプリケーション１０８も含むことができる。ローカル・アプリケーション１０８については、以下に更に詳しく説明する。

【0008】

説明の目的に限って、コンピューター１０２は、ハードウェア・レイヤー１１４上で動作するオペレーティング・システム・レイヤー１１２上で動作するアプリケーション・レイヤー１１０を含むことを特徴とすることができる。アプリケーション・レイヤー１１０は、ＵＲＩマネージャー１１６を含むことができる。ＵＲＩマネージャーは、コンテキスト・プロトコル・ハンドラー１１８および受信コンポーネント１２０を含む、またはこれらと相互作用することができる。また、アプリケーション・レイヤー１１０は、アプリケーション管理コンポーネント１２４を含むまたはこれと対話処理することができるコンテキスト管理システム１２２も含むことができる。また、アプリケーション・レイヤーは、多数のアプリケーションを含むことができる。説明の目的に限って、４つのアプリケーション１２６（１）〜１２６（Ｎ）が例示される（添え字「Ｎ」は、任意の数のアプリケーションを含むことができることを示す）。ハードウェア・レイヤー１１４は、プロセッサー１２８およびストレージ１３０、ならびに入力／出力デバイス、バス、グラフィクス・カード等のような、追加のハードウェア・コンポーネントを含むことができる。これらのハードウェア・コンポーネントは、簡潔にするために、ここでは図示も論述もされない。

【0009】

ＵＲＩマネージャー１１６は、コンピューター１０２によって受信されたＵＲＩを管理するように構成することができる。ＵＲＩマネージャーのコンテキスト・プロトコル・ハンドラー１１８は、コンピューター１０２上においてＵＲＩ方式を扱い、具体的には、ＵＲＩマネージャーの代わりにコンテキスト定義ＵＲＩを扱うように構成することができる。場合によっては、コンテキスト・プロトコル・ハンドラー１１８が、コンテキスト定義ＵＲＩを扱うように登録されたダイナミック・リンク・ライブラリ（ＤＬＬ）または実行可能ファイルのような、マニフェストとすることもできる。

【0010】

１つの観点から見ると、コンテキスト・プロトコル・ハンドラー１１８は、コンテキスト定義ＵＲＩからの情報を読み出すために、隔離されたセキュリティ環境において動作するように構成することができる。コンテキスト・プロトコル・ハンドラーは、この情報を受信コンポーネント１２０に伝えることができる。受信コンポーネント１２０は、コンテキスト管理システムおよびアプリケーション管理システムとの通信を許可する特権レベルで動作するように構成される。ある場合には、コンテキスト・プロトコル・ハンドラー１１８は、コンテキスト定義ＵＲＩから受信コンポーネント１２０へ、情報を収容したメッセージを伝達することができる。例えば、この情報は、アプリケーションの起動および／またはコンテキスト変更情報に関することができる。

【0011】

受信コンポーネント１２０には、コンピューター１０２上においてコンテキスト管理システム１２２および／またはアプリケーション管理コンポーネント１２４と相互作用することができるように十分な特権を設定する(configure)ことができる。この構成では、コンテキスト・プロトコル・ハンドラー１１８を、隔離されたセキュリティ環境において実行させることができる。例えば、一例では、コンテキスト・プロトコル・ハンドラー１１８は、Internet Explorer（登録商標）のような、グラフィカル・ウェブ・ブラウザーの保護モードで実行してもよい。受信コンポーネント１２０は、コンテキスト・プロトコル・ハンドラー１１８から情報を受け、アプリケーションを安全に起動させるために、コンテキスト管理システム１２２と相互作用することができる。

【0012】

コンテキスト管理システム１２２は、１組のアプリケーション間において共有状態またはコンテキストを提供するメカニズムとすることができる。コンテキスト管理システムは、アプリケーションがこの共有状態を操作することを可能にするＡＰＩを供給することができる。例えば、コンテキスト管理システムは、コンテキストに対する変更についてアプリケーションに知らせるＡＰＩを含むことができる。更に、コンテキスト管理システムは、特定のコンテキスト変更が実際に実施される前にこのコンテキスト変更が個々のアプリケーションに容認可能か否か判断するために、１組の中の種々のアプリケーションのチェックを行うＡＰＩも含むことができる。例えば、個別のアプリケーションが異なるコンテキストにおいて既に実行しており、保存されていないデータがある場合、その状態を変更すると、この保存されてないデータが失われる原因となり得る。コンテキスト管理システムは、個別のアプリケーションとネゴシエートして、安全なコンテキスト変更を可能にする措置を講ずることができる。例えば、コンテキスト管理システムは、アプリケーションがコンテキスト定義ＵＲＩに定められたコンテキストに安全にコンテキストを変更することができるように、アプリケーションに個々のアプリケーションの現在のコンテキストを保存させることができる。

【0013】

アプリケーション管理コンポーネント１２４は、共有コンテキストに関して特定のアクションを行うことが許可されることを検証することができる。例えば、場合によっては、どのアクションが許可されるか、および／またはどのアクションが許可されないか、アドミニストレーターが定めていることもある。アプリケーション管理コンポーネントは、この許可情報にアクセスし、許可されたアクションだけが実際に許され、禁止されたアクションを行わせないことを確保することができる。場合によっては、受信コンポーネント１２０がアプリケーション管理コンポーネント１２４と共同して動作して、コンテキスト定義ＵＲＩからの起動要求が、許可されたアクションと一致する(match)ことを確認することもできる。

【0014】

本明細書において用いる場合、「コンピューター」または「計算デバイス」という用語は、ある量の処理能力および／または記憶能力を有するあらゆるタイプのデバイスを意味することができる。処理能力は、機能を提供するコンピューター読み取り可能命令の形態で、データを実行することができる１つ以上のプロセッサー（プロセッサー１２８のような）によって提供することができる。コンピューター読み取り可能命令のようなデータは、ストレージ１３０上に格納することができる。ストレージ１３０は、コンピューターに対して内部でも外部でも可能である。ストレージは、とりわけ、揮発性または不揮発性メモリ、ハード・ドライブ、フラッシュ記憶デバイス、および／または光記憶デバイス（例えば、ＣＤ、ＤＶＤ等）の内いずれか１つ以上を含むことができる。本明細書において用いる場合、「コンピューター読み取り可能媒体」という用語は、一時的および非一時的コンピューター読み取り可能命令を含むことができる。対照的に、「コンピューター読み取り可能記憶媒体」という用語は、一時的なインスタンスを除外する。コンピューター読み取り可能記憶媒体は、「コンピューター読み取り可能記憶デバイス」を含む。コンピューター読み取り可能記憶デバイスの例には、とりわけ、ＲＡＭのような揮発性記憶媒体、ならびにハード・ドライブ、光ディスク、およびフラッシュ・メモリのような不揮発性記憶媒体が含まれる。

【0015】

計算デバイスの例には、パーソナル・コンピューターのような従前からの計算デバイス、セル・フォン、スマート・フォン、パーソナル・ディジタル・アシスタント、あるいは増々発展しつつあるまたは未だ開発されていない無数のタイプの計算デバイスの内いずれでも含むことができる。更に、システム１００の態様は、１つの計算デバイス上におけるマニフェストであることができ、または多数の計算デバイスに跨がって分散することもできる。例えば、後者の場合、コンピューター１０２はクライアント・デバイスとして動作し、ネットワーク１０６を通じてサーバーと共同して動作することができる。他の場合では、コンピューター１０２が、ネットワーク１０６および／または他のネットワークを通じて、クラウド・ベースの計算リソースを用いて動作するのでもよい。

【0016】

先に紹介したように、システム１００は、共通コンテキストにおけるアプリケーションの起動を可能にすることができる。このようなシナリオの１つでは、リモート・アプリケーション１０４が、１３６に示すように、コンテキスト定義ＵＲＩ１３２を生成することができる。以下で説明するが、アクティブ化されると、コンテキスト定義ＵＲＩ１３２は、ＵＲＩ１３２によって定められるコンテキストにしたがって、アプリケーション１２６（１）〜１２６（Ｎ）の内１つ以上を実行させることができる。説明の目的に限って、コンテキスト定義ＵＲＩ１３２がアプリケーション１２６（１）〜１２６（Ｎ）（またはその部分集合）を起動し、これらのアプリケーションの各々のコンテキストを、架空の患者識別番号１２３４５に設定することを示すと仮定する。例えば、リモート・アプリケーション１０４がリモート・コンピューター上で実行しており、患者の検査結果を処理するように構成されると仮定する。更に、リモート・アプリケーション１０４が、新たな検査結果が準備できたときはいつでも、その患者の医者に通知するように構成されると仮定する。ある場合には、リモート・アプリケーションが、「 先生：患者 の新たな検査結果を受け取りました」と書かれたテンプレートを含む電子メールというような、通知を生成することができる。このリンク上でクリックすると、自動的に新たな検査結果が見られる。リモート・アプリケーションは、第１フィールドに要求元の医者の名前（例えば、検査を要求した医者）を入力し、第２フィールドに患者の識別（例えば、１２３４５）を入力することができる。このリンクに埋め込まれるのは、コンテキスト定義ＵＲＩであり、医者がリンクをクリックしたときに、自動的にアプリケーションを開き、アプリケーションを患者識別１２３４５に設定することができる。

【0017】

この構成では、１３８に示すように、コンテキスト定義ＵＲＩ１３２は、コンピューター１０２において、ＵＲＩアプリケーション・マネージャー１１６によって受信される。ＵＲＩマネージャーのコンテキスト・プロトコル・ハンドラー１１８は、ＵＲＩ方式を扱うように構成され、コンテキスト定義ＵＲＩ１３２に収容された情報を理解することができる。１４０に示すように、コンテキスト・プロトコル・ハンドラー１１８は、アプリケーション起動およびコンテキストについての情報を収容したメッセージを、受信コンポーネント１２０に伝えることができる。

【0018】

１４２に示すように、受信コンポーネント１２０には、コンピューター１０２上においてコンテキスト管理システム１２２と相互作用することができるように、十分な特権を設定することができる。受信コンポーネント１２０は、１４４，１４６，１４８，１５０に示すように、アプリケーション１２６（１）〜１２６（Ｎ）を安全に実行するために、コンテキスト管理システム１２２と相互作用することができる。コンテキスト管理システム１２２は、個々のアプリケーションが既に実行しており、したがって起動する必要がないことを知ることができる。このような場合、コンテキスト管理システム１２２は、個々のアプリケーションをチェックして、患者識別番号１２３４５に対するコンテキスト変更が容認可能か否か判断することができる。例えば、アプリケーション１２６（１）は他のコンテキストにおいて（例えば、他の患者識別番号に対して）実行しており、保存していないデータを有するかもしれず、コンテキストを変更すると、保存されていないデータが失われる原因となる可能性がある。コンテキスト管理システム１２２は、アプリケーション１２６（１）とネゴシエートし、コンテキスト変更を許可するための然るべきアクションを実行することができる。一旦コンテキスト管理システムがコンテキスト変更問題を解決したなら、アプリケーションが患者識別１２３４５についての情報を示すように自動的に設定することができる。このように、医者が通知リンクをクリックすることによる１つのアクションによって、１つ以上のアプリケーションを自動的に起動し、患者のコンテキストに設定することができるので、医者は瞬時に彼／彼女のコンピューター１０２上で新たな検査結果を調べることができる。

【0019】

前述のように、実施態様では、受信コンポーネント１２０は、１５２に示すように、アプリケーション管理コンポーネント１２４と共に動作して、コンテキスト定義ＵＲＩ１３２の起動要求が許可されるか否か、種々の許可および／またはセキュリティ・パラメーターにしたがってチェックすることができる。

【0020】

一実施態様では、受信コンポーネント１２０は、アプリケーション・トリガーを利用してもよい。アプリケーション・トリガーは、アプリケーション管理コンポーネント１２４が、コンテキスト管理システムの設定の一部として構成されたアプリケーションを開始することを、アプリケーション管理コンポーネントに対して行う要求である。以下に、このような例の詳細について説明する。

【0021】

この例では、コンテキスト管理システム１２２は、Microsoft Corporationによって提供されるVergence Launchpad（登録商標）のようなマニフェストとすることができる。コンテキスト定義ＵＲＩの一例は、次のようにすることができる。
launchpad://epic/?Method=SetContext&itemsName=patient.id.mrn.clinic|patient.id.mrn.hospital&itemValues=123|456|&LaunchAppFirst=True&ContinueOnFail=False&AppTitle=Eureka&AllowContextChangeCancellation=true
このコンテキスト定義ＵＲＩは、「launchpad」コンポーネントに、「epic」によって識別されるアプリケーションを開始するように命令する。こうするより前に、Lauchpadは「epic」がアクセスする共通コンテキスト・データに２つの項目を設定する。即ち、２つの患者ＩＤであり、１つは医者からのＩＤ、もう１つは病院からのＩＤであり、どの患者を見るべきかepicが分かるようにする。これは、ＵＲＩによってepicソフトウェアを起動させて患者に合わせて調整することを可能にするだけでなく、そのコンテキストが他のアプリケーションによって共有される。

【0022】

代わりの構成では、コンテキスト定義ＵＲＩは、アドミニストレーターがインストールしたアプリケーション・コンテキスト・アダプター（「ブリッジ」）を開始する要求としてもよく、このアプリケーション・コンテキスト・アダプターは、開始して１つ以上のアプリケーションと相互作用することができる。例えば、アプリケーションと相互作用するVergenceブリッジを起動するために、「ブリッジ」プロトコル・ハンドラーを登録するのでもよい。
bridge://crm/?InitiateFollowupWorkflow=true&patient.id.mrn.hospital=12345
このコンテキスト定義ＵＲＩは、コンテキスト管理システム１２２に、「crm」ブリッジを起動するように命令し、ＣＲＭシステムに患者事後点検ワークフローを開始することを命令するために、パラメーターがブリッジに渡される。これは、ローカルにインストールされたアプリケーションを開始および制御することができる一層精巧なローカル・スクリプトを安全に起動する能力を例示する。

【0023】

以上の論述では、コンテキスト定義ＵＲＩ１３２は、コンピューター１０２から離れて生成され、コンピューター１０２に送られる。しかしながら、このようにする必要はない。例えば、ローカル・アプリケーション１０８が、１５４において指定される同様のコンテキスト定義ＵＲＩを生成することができる。ローカル・アプリケーション１０８は、コンテキスト管理システム１２２およびアプリケーション管理コンポーネント１２４によって管理されるアプリケーション１２６（１）〜１２６（Ｎ）の内の１つとしてもそうでなくてもよい。この例では、ローカル・アプリケーション１０８は、コンテキスト定義ＵＲＩ１５４を生成することができ、コンテキスト定義ＵＲＩ１５４は、１つ以上のアプリケーションを共通コンテキストの下で実行させるように構成することができる。コンテキスト定義ＵＲＩ１５４は、コンテキスト・プロトコル・ハンドラー１１８によって受信することができ、コンテキスト定義ＵＲＩ１３２に関して以上で説明したのと同様にして扱うことができる。

【0024】

要約すると、本願は、撃ちっぱなし(fire-and-forget)コンテキスト定義ＵＲＩの使用によって、コンテキスト管理システムと相互作用するための安全なメカニズムを提供することができる。増々多くのアプリケーションがウェブに移動するに連れて、業務ワークフローには多大な切断が生ずる。なぜなら、こうしなければ、ウェブ・アプリケーションは、クライアント・ワークステーションまたは端末サーバーにインストールされたアプリケーションを起動することができず、データを送ることができず、言い換えると、相互作用することができないからである。これは、一例として、クラウド・ホスト・アプリケーションまたはポータルの統合(integration)を著しく困難にする。

【0025】

使用事例
図２は、コンテキストに基づいてアプリケーションと相互作用する使用事例シナリオを示す。このシナリオは、パッド型コンピューター２０２を伴うが、他のタイプのコンピューターにも適用可能である。このシナリオでは、パッド型コンピューター２０２は医者２０４に属する。説明の目的に限って、このシナリオを「実例１」および続く「実例２」によって説明する。実例１から開始すると、医者はウェブ・ベース電子記録マネージャー２０６を使用して、個々の患者についての情報を見直している。この例では、患者は、２０８に示すように、「患者ＩＤ」の形態で一意の識別子を有するJohn Smithとしてリストに載せられる。更に、ウェブ・ベース電子記録マネージャー２０６は、２１０において、患者のために検査結果を表示している。この例では、検査結果は「肝機能パネル」(liver function panel)に関する。更に、ウェブ・ベース電子記録マネージャーは、２１２において、「新たな画像が入手可能である」ことを示す。この例では、画像ビューアはパッド型コンピューター２０２上にインストールされたローカル・アプリケーションであると仮定する。更に、医者がこれらの画像を見ることを望み、２１４に示すように「ここをクリックして下さい」アイコンをタップ／タッチすると仮定する。（医者は、とりわけ、音声またはジェスチャというような他の選択方法を代わりに使用してもよい）。「こちらをクリック」アイコンは、図１に関して先に紹介したようなコンテキスト定義ＵＲＩを含むこと、および／またはこれと関連することができるが、ユーザーに明白である必要はない。更に、パッド型コンピューター２０２は、コンテキスト定義ＵＲＩの扱いを管理することができるＵＲＩマネージャー２１６も含むことができる。

【0026】

実例２において証明されるように、医者によるクリックが、ローカル撮像アプリケーション２２０を起動し、このローカル撮像アプリケーション２２０はパッド型コンピューター２０２上で実行している。更に、ユーザー／医者の手間を全く要さずに、ローカル撮像アプリケーション２２０は、ウェブ・ベース電子記録マネージャー２０６と同じコンテキストに設定される（例えば、ローカル撮像アプリケーションが患者ＩＤ ＳＭ １２３４５に対して新たな画像を表示している）。この例では、新たな画像２２２は、日付２０１２−１２−２７からである。この例では、コンテキストは患者ＩＤに関するが、これは一例に過ぎない。他の例では、同じ日に患者から得られる検査結果および画像を示すためのコンテキストが設定されるように、コンテキストが患者ＩＤおよび日付に関係することもできる。要約すると、１つのユーザー・アクションが、多数のアプリケーションを、ユーザーにとって共通のコンテキストにおいて動作させることができる。この場合、１つのアプリケーションはウェブ・アプリケーションであり、もう１つはリモート・アプリケーションである。しかしながら、本概念は、共通コンテキストにしたがって多数のローカル・アプリケーションを動作させるというような他のシナリオにも適用可能である。このような例の１つについて、以下に図３に関して説明する。

【0027】

図３は、コンテキストに基づいてアプリケーションと相互作用する他の使用事例シナリオを示す。このシナリオは、小型電話機型コンピューター３０２を伴うが、他のタイプのコンピューターにも適用可能である。このシナリオでは、医者と彼／彼女の患者に関して先に紹介した例を続けるが、勿論、医療コンテキストにおける他のシナリオ、または医療コンテキスト以外のシナリオにも関係することができる。このシナリオでは、医者は、小型電話機型コンピューター３０２を通じて、患者についての通知を受信する。この例では、通知は、実例１において受信される電子メール通知３０４である。この電子メールは、３０６において、患者ＩＤがＳＭ１２３４５であるJohn Smithに新たな結果が入手可能であることを示す。また、この電子メールは、ユーザーがアクティブ化可能なＵＲＩ３０８も含む。このＵＲＩ３０８には、「新たな結果を見るためにはこちらをクリック」と書かれている。尚、小型電話機型コンピューター３０２は、ＵＲＩマネージャー３１６を含むことができ、このＵＲＩマネージャー３１６は、実例２において証明されるように、コンテキスト定義ＵＲＩの扱いを管理できることを注記しておく。尚、医者はユーザーがアクティブ化可能なコンテキスト定義ＵＲＩ３０８をアクティブ化すると仮定する。

【0028】

実例２は、医者がコンテキスト定義ＵＲＩ３０８をアクティブ化した結果として、ＵＲＩマネージャー３１６によって小型電話機型コンピューター３０２上で起動された２つのアプリケーションを示す。この場合、これらのアプリケーションは、検査記録アプリケーション３１８および撮像アプリケーション３２０を含む。両アプリケーションは、それぞれ、３２２および３２４において示されるように、患者ＩＤ ＳＭ１２３４５のコンテキストに設定される。検査結果記録アプリケーション３１８の場合、コンテキストは、コンテキスト定義ＵＲＩ３０８において定められるコンテキストに合わせて、アプリケーションに肝機能パネル３２６を提示させる（例えば、患者ＩＤ ＳＭ１２３４５）。撮像アプリケーション３２０の場合、コンテキストは、コンテキスト定義ＵＲＩにおいて定められるコンテキストに合わせてアプリケーションに画像３２８を提示させる。したがって、医者は、単にコンテキスト定義ＵＲＩ３０８上でクリックすることによって、そしてコンテキスト定義ＵＲＩのコンテキスト定義エレメントやＵＲＩマネージャー３１６によって提供される機能性を全く理解することなく、彼／彼女の患者John Smith（例えば、患者ＩＤ ＳＭ１２３４５）についての最新情報を素早く調べることができる。医者は、単に、コンテキスト定義ＵＲＩをクリックし、他のアクションを全く行うことなく、検査記録アプリケーション３１８における患者の検査結果、および撮像アプリケーション３２０における画像を見ることができる。ＵＲＩマネージャー３１６は、データ損失を生ずることなく、アプリケーションの起動および／またはアプリケーションのコンテキスト変更を扱うことができ、更に医者のために双方のアプリケーションにおいてコンテキストを表示させることができる。要約すると、これらの使用事例シナリオは、医者以外のあらゆる他のタイプのユーザーにも応用することができる。本技術により、ユーザーは、コンテキスト定義ＵＲＩのアクティブ化によって、１つ以上のアプリケーションを自動的に起動し、ユーザーの都合に合わせてこれらのアプリケーションのコンテキストを自動的に設定することができる。
方法例
図４は、コンテキストに基づいてアプリケーションと相互作用する技法または方法４００のフローチャートを示す。

【0029】

ブロック４０２において、本方法は、エンティティに関する情報を受信することができる。例えば、この情報は、エンティティに関するトリガー・イベントであることができる。以上で説明した一例では、このエンティティは患者であることができる。その例では、新たな検査結果が得られるとき、この情報は患者に関するトリガーとして機能することができる。

【0030】

ブロック４０４において、本方法は、コンピューター上にインストールされたアプリケーション、およびエンティティに関係するコンテキストをアプリケーションに対して指定するリンクを生成することができる。実施形態では、リンクがコンテキスト定義ＵＲＩのようなマニフェストであることもできる。コンテキスト定義ＵＲＩは、アプリケーションにコンピューター上で実行させ、エンティティ（例えば、この場合、患者）に関する情報を提示させることができる。ＵＲＩにおいて定められたコンテキストは、コンテキスト定義ＵＲＩがアクティブ化されたときにエンティティについての情報を提示するようにアプリケーションを自動的に設定することができる（例えば、アプリケーションがエンティティのコンテキストに設定される）。

【0031】

図５は、コンテキストに基づいてアプリケーションと相互作用する技法または方法５００のフローチャートを示す。
ブロック５０２において、本方法は、実行すべきアプリケーションを指定し、このアプリケーションに対してコンテキストを定めるＵＲＩを受信することができる。場合によっては、ＵＲＩは、アプリケーションがインストールされたコンピューター上で受信することもできる。

【0032】

ブロック５０４において、本方法は、ＵＲＩによって定められたように、アプリケーションを実行し、このアプリケーションのコンテキストを設定することができる。構成の中には、本方法が、アプリケーションを実行することがコンピューター上で許可されるか否か判断できる場合もある。例えば、コンピューターのアドミニストレーターが、どのアクションをコンピューター上で許可し、どのアクションを許可しないか、手作業で定めている場合もある。代わりにまたはこれに加えて、アドミニストレーターが、コンピューター上で禁止されるアクションを定めている場合もある。本方法は、許可されたアクションだけが実際に実施されることを確保することができる。他の実施態様では、ＵＲＩを検査して、ＵＲＩによって伝えられた命令を実装するか否か判断することもできる。例えば、ＵＲＩが、信頼のおけるソースからの有効な許可（例えば、署名）を含む場合、コンピューターに対して確定された許可に関して、または関せずに、ＵＲＩの命令を実装することができる。言い換えると、このＵＲＩを採用する(implement)か否か判断するときに、ＵＲＩに伴う許可および／またはソースの信頼性を評価することができる。

【0033】

実施態様では、本方法は、アプリケーションが既に実行しているか否かチェックすることもできる。アプリケーションが未だ実行しておらず、このアプリケーションの実行が許可されている場合、アプリケーションを起動することができる。

【0034】

アプリケーションが既に実行している場合、本方法は、ＵＲＩによって定められたとおりにコンテキストを設定することが許可されるべきか否かについて判断することができる。例えば、コンテキストの変更がデータ損失の原因となる場合、このコンテキスト変更を遅らせることもできる。本方法は、コンテキスト変更が安全に行えるまで、アプリケーションとネゴシエートすることによってというように、種々のアクションを行うことができる。

【0035】

方法例を説明した順序は、限定として解釈されることを意図しておらず、説明したブロックまたは行為は、これらの方法または代わりの方法を実現するために、いずれの数でもそしていずれの順序でも組み合わせることができる。更に、これらの方法は、計算デバイスが当該方法を実現できるように、適したハードウェア、ソフトウェア、ファームウェア、またはその組み合わせであればいずれでも実現することができる。１つの事例では、本方法は、計算デバイスによる実行が、当該計算デバイスに本方法を実行させるように、１つ以上のコンピューター読み取り可能記憶媒体上に１組の命令として格納される。

【0036】

結論
以上、構造的特徴および／または方法論的行為に特定的な文言で、コンテキストに基づくアプリケーションとの相互作用に関する技法、方法、デバイス、システム等について説明したが、添付する特許請求の範囲において定められる主題は、必ずしも、説明した具体的な特徴や行為には限定されないことは理解されて然るべきである。逆に、これら具体的な特徴および行為は、特許請求する方法、デバイス、システム等を実現する形態例として開示したまでである。

【図1】

【図2】

【図3】

【図4】

【図5】