与应用的上下文式交互的制作方法

与应用的上下文式交互的制作方法
【专利摘要】本发明涉及与应用的上下文式交互。一个示例可包括其上安装了应用的集合的计算机。该示例还可包括被配置成接收上下文定义URI的URI管理器，该URI管理器可被配置成运行由上下文定义URI指定的应用子集，并如上下文定义URI所指定地为该应用子集设置通用上下文。
【专利说明】与应用的上下文式交互
[0001] 背景
[0002] 传统上，计算场景涉及用户孤立地与应用交互。更高级的场景涉及多个应用提供 与通用上下文有关的不同功能。例如，诸如临床医生之类的用户可在诊断患者时利用成像 应用和记录管理应用。上下文管理系统可使得能够针对通用上下文对不同应用进行生存周 期管理以及协调。将应用集成到通用上下文中是往往需要上下文管理系统以及尤其需要用 户的大量活动的复杂任务。


【发明内容】

[0003] 本发明涉及与应用的上下文式交互。一个示例可包括其上安装了应用的集合的计 算机。该示例还可包括被配置成接收上下文定义URI的通用资源标识符（URI)管理器。URI 管理器被配置为运行上下文定义URI所指定的应用子集并如上下文定义URI所指定地为该 应用子集设置通用上下文。
[0004] 另一示例可接收与实体相关的信息。该示例可生成诸如上下文定义URI之类的链 接，该链接指定安装在计算机上的应用以及用于该应用的与该实体相关的上下文。
[0005] 另一示例可接收指定要运行的应用并为该应用定义上下文的上下文定义URI。该 示例可运行该应用并如上下文定义URI所定义地设置应用的上下文。
[0006] 以上列出的示例旨在提供快速参考以帮助读者，并且不旨在限定此处所描述的概 念的范围。

【专利附图】

【附图说明】
[0007] 附图示出了本申请中传达的概念的实现。所示实现的特征可通过参考以下结合 附图的描述来更容易地理解。只要可行，各附图中相同的附图标记用来指代相同的元素。 此外，每一个如图标记的最左边的数字传达其中首次引入该附图标记的附图及相关联的讨 论。
[0008] 图1示出了根据某些实现可在其上采用与应用上下文式交互的概念的系统。
[0009] 图2-3示出了根据本发明的概念的一些实现用于与应用上下文式交互的用例的 示例。
[0010] 图4-5示出了根据本发明的概念的一些实现用于与应用上下文式交互的方法的 流程图的示例。

【具体实施方式】
[0011] 概览
[0012] 本专利涉及允许在通用上下文下进行应用启动。更具体地，可利用统一资源标识 符（URI)来自动启动一个或多个应用。URI还可仅通过用户激活URI来为应用建立通用上 下文。本发明的概念可允许web或其它应用（诸如，门户网站）能够启动应用并选择上下 文而无需复杂集成。
[0013] 系统示例
[0014] 图1示出了其中可实现通用上下文应用启动的系统100。在该例中，系统100包 括计算机102。计算机可经由网络106与远程应用104 (诸如web应用或web门户）通信。 计算机102还可包括本地应用108 (将在以下更详细描述）。
[0015] 出于说明的目的，计算机102可被表示为包括应用层110,应用层110操作在操作 系统层112上，而操作系统层112操作在硬件层114上。。应用层110可包括URI管理器 116。URI管理器可包括上下文协议处理器118和接收组件120或与之上下文协议处理器 118和接收组件120交互。应用层110还可包括上下文管理系统122,该上下文管理系统 122可包括应用管理组件124或与之交互。应用层还可包括多个应用。出于说明的目的，示 出了四个应用126 (1) -126 (N)(后缀表明可包括任何数目的应用）。硬件层144可包括 处理器128和存储130以及附加的硬件组件，诸如输入/输出设备、总线、图形卡等，为简明 起见在此未示出或讨论。
[0016] URI管理器116可被配置成管理计算机102接收的URI。URI管理器的上下文协议 处理器118可被配置成处理计算机102上的URI模式，具体而言被配置成代表URI管理器 处理上下文定义URI。在某些情况下，上下文协议处理器118可以显现为被注册来处理上下 文定义URI的动态链接库（DLL)或可执行代码。
[0017] 从一个角度来看，上下文协议处理器118可被配置成在隔离的安全环境中操作以 从上下文定义URI读取信息。上下文协议处理器可向接收组件120传达信息，接收组件120 被配置成以允许与上下文管理系统和应用管理系统通信的特权级别操作。在一种情况下， 上下文协议处理器118可将包含来自上下文定义URI的信息的消息传递给接收组件120。 例如，信息可涉及应用启动和/或上下文改变信息。
[0018] 接收组件120可在计算机102上配置有足够的特权，以便能够与上下文管理系 统122和/或应用管理组件124交互。该配置可允许上下文协议处理器118在隔离的安 全环境中运行。例如，在一种情况下，上下文协议处理器118可在图形web浏览器（诸如 Internet Explorer? )的受保护模式中运行。接收组件120可从上下文协议处理器118接 收信息，并可与上下文管理系统122交互以便触发应用安全启动。
[0019] 上下文管理系统122可以是用于在一组应用之间提供共享状态或上下文的机制。 上下文管理系统可提供允许应用操纵该共享状态的API。例如，上下文管理系统可包括向应 用告知关于对上下文改变的API。此外，上下文管理系统可包括在特定上下文改变被实际实 现之前检查集合中的各个应用以确定该上下文改变是否对各个应用是可接受的。例如，如 果个别应用已经在不同的上下文中运行并具有未被保存的数据，那么改变状态可能会引起 未被保存的数据丢失。上下文管理系统可与各个应用协商来采取动作以允许安全的上下文 改变。例如，上下文管理系统可使得应用保存各个应用的当前上下文，使得应用可安全地将 上下文改变为上下文定义URI中定义的上下文。
[0020] 应用管理组件124可验证对于共享的上下文采取特定的动作是被允许的。例如， 在某些情况下，管理员可能定义了什么动作被授权和/或什么动作不被授权。应用管理组 件可访问该授权信息，并确保实际上仅允许授权的动作，而禁止的动作不被运行进行。在某 些情况下，接收组件120可与应用管理组件124协作操作，以确保来自上下文定义URI的启 动请求匹配授权的动作。
[0021] 如本文所使用的术语"计算机"或"计算设备"可指的是具有某种处理能力和/或 存储能力的任何类型的设备。处理能力可由一个或多个处理器（诸如处理器128)提供，处 理器可执行计算机可读指令形式的数据以提供功能。诸如计算机可读指令的数据可被存储 在对于计算机而言可内置或外置的存储130上。存储可包括易失性或非易失性存储器、硬 盘驱动器、闪存设备、和/或光存储设备（例如，CD、DVD等）等等中的任何一个或多个。如 本文所使用地，术语"计算机可读介质"可包括瞬态以及非瞬态计算机可读指令。作为对比， 术语"计算机可读存储介质"不包括瞬态实例。计算机可读存储介质包括"计算机可读存储 设备"。计算机可读存储设备的实例包括易失性存储介质（诸如RAM)和非易失性存储介质 (诸如硬盘驱动器、光盘和闪存等等）。
[0022] 计算设备的示例可包括传统的计算设备，诸如个人计算机、蜂窝电话、智能电话、 个人数字助理，或者无数不断发展或尚未被开发的类型的计算设备中的任何一个。此外，系 统100的各方面可显现在单个计算设备上、或分布在多个计算设备上。例如，在后一情况 下，计算机120可担当客户机设备并可通过网络106与服务器计算机协作操作。在另一情 况下，计算机102可通过网络106和/或另一网络操作基于云的计算资源。
[0023] 如上所介绍地，系统100可允许通用上下文应用启动。在一个这样的场景中，远程 应用104可如136所示生成上下文定义URI132。如将在以下说明地，当被激活时，上下文定 义URI132可使得应用126 (1)-126 (N)中的一个或多个根据URI132定义的上下文来运行。 出于说明的目的，假定上下文定义URI132指示启动应用126 (1)-126 (N)(或其子集）并将 这些应用的每一个的上下文设置为假设患者标识号12345。例如，假定远程应用104正在 远程计算机上运行，并被配置成处理患者的化验结果。还假定远程应用104被配置成只要 新的化验结果准备好，就向该患者的临床医生提供通知。在一种情况下，远程应用可生成 一通知，诸如包括写成以下形式的模板的电子邮件"亲爱的_医生：已经接收到患者 _的新的化验结果。点击该链接来自动查看新的化验结果。"远程应用可用进行请求的 医生的名字（例如，请求化验的医生）填充第一字段，并可用患者标识（例如，12345)填充 第二字段。在该链接中嵌入上下文定义URI，当临床医生点击该连接时，该上下文定义URI 可自动打开应用，并将应用设置为患者12345。
[0024] 在这种配置中，如138所示，由UIR应用管理器116在计算机102处接收上下文定 义URI132。URI管理器的上下文协议处理器118被配置成处理URI模式并理解上下文定义 URI132中包含的信息。上下文协议处理器118可如140所示将包含关于应用启动和上下文 的信息的消息传输给接收组件120。
[0025] 可在计算机102用足够的特权配置接收组件120,使得接收组件120如142所示能 够与上下文管理系统122交互。接收组件120可与上下文管理系统122交互，以便如144、 146、148和150所示触发应用126 (1)-126 (N)安全运行。上下文管理系统122可了解各个 应用已经正在运行且因此不必被启动。在这样的情况下，上下文管理系统122可检查各个 应用以确定对患者标识号12345的上下文改变是否可接受。例如，应用126(1)可能正在运 行，并另一上下文中具有未被保存的数据（例如，用于另一患者标识号），使得改变上下文 可能会引起未被保存的数据丢失。上下文管理系统122可与应用126(1)协商，以采取适当 的动作来允许上下文改变。一旦上下文管理系统解决了任何上下文改变问题，应用可被自 动设置成显示患者标识123456的信息。因此，通过临床医师点击通知链接的单个动作，一 个或多个应用可被自动启动，并被设置为该患者的上下文，使得临床医师可立即在其计算 机102上审阅新的化验结果。
[0026] 如上所述，在一些实现中，接收组件120可如152所示与应用管理组件124-起工 作，来检查根据各个授权和/或安全参数，上下文定义URI132的启动请求是否被授权。
[0027] 在一个实现中，接收组件120可利用应用触发，应用触发是对应用管理组件124的 请求，请求应用管理组件开启被配置成上下文管理系统的其设置的一部分的应用。以下描 述一个这样的详细示例。
[0028] 在这一示例中，上下文管理系统122可被显现为Microsoft? Corporation提供的 Vergence Launchpad?。示例上下文定义URI可以是：
[0029] launchpad://epic/ ? Method = SetContext&itemsName = patient, id. mrn. clinic
[0030] patient, id. mrn. hospital&itemValues = 123|456|&LaunchAppFirst = True&
[0031] ContinueOnFail = False&AppTitle = Eureka&AllowContextChangeCancel
[0032] 1 at ion = true
[0033] 这一上下文定义URI告知"launchpad"组件开启由"印ic"标识的应用。在这样 做之前，launchpad将两项设置到"印ic"能够访问的通用上下文数据中--两个患者ID， 一个来自于诊所而一个来自于医院，因此epic知道要查看哪个患者。这不仅将允许印ic 软件被启动并通过URI调节为一患者，而且上下文将被其它应用共享。
[0034] 在替换配置中，上下文定义URI可以是开启管理员已经安装的应用上下文适配 器（"bridge"）的请求，该应用上下文适配器可开启一个或多个应用并与之交互。例如， "bridge"协议处理器可被注册以启动Vergence bridge来与应用交互：
[0035] bridge : //crm/ ? InitiateFol lowupfforkf low = true&patient. id. mrn. hospital = 1
[0036] 2345
[0037] 这一上下文定义URI告知上下文管理系统122来启动"crm" bridge，参数传递给 bridge来告知CRM系统开启患者跟踪工作流。这示出了安全启动可启动和控制本地安装的 应用的更复杂的本地脚本的能力。
[0038] 在以上讨论中，上下文定义URI132从计算机102远程生成并被发送给计算机 102。然后，不必如此。例如，本地应用108可生成在154指定的类似的上下文定义URI。 本地应用108可以是或可以不是由上下文管理系统122和应用管理组件124管理的应用 126(1)-126 (N)中的一个。在这一示例中，本地应用108可生成上下文定义URI154,该上下 文定义URI154可被配置成使得一个或多个应用在通用上下文下操作。上下文定义URI154 可被上下文协议处理器118接收，并以类似于上述对于上下文定义URI132的方式处理。
[0039] 总而言之，本申请可提供通过使用一劳永逸（fire-and-forget)的上下文定义URI 来与上下文管理系统交互的安全机制。随着更多的应用移向web,业务工作流中存在显著的 断开，因为web应用不能启动安装在客户机工作站或终端服务器上的应用、向其发送数据 或以其方式与之交互。这使得例如集成云托管的应用或门户困难得多。
[0040] 用例示例
[0041] 图2示出了用于与应用上下文式交互的用例场景。该场景涉及平板型计算机202， 但适用于其它类型的计算机。在此场景中，平板类型的计算机202属于临床医生204。出 于说明的目的，该场景通过"实例1"以及随后的"实例2"来说明。以实例1开始，临床医 生正在使用基于web的电子记录管理器206来审阅关于个体患者的信息。在这一示例中， 患者被列为John Smith,具有如208所示的"患者ID"形式的唯一标识符。此外，基于web 的电子记录管理器206正在210显示该患者的化验结果。在这一示例中，化验结果涉及'肝 功能组'。此外，基于web的电子记录管理器在212指示'新图像可用'。在这一示例中，假 定图像查看者是安装在平板型计算机202上的本地应用。还假定临床医生希望查看图像， 并轻击/触摸如214所示的"点击这里"图标。（该临床医生或者可使用其它选择方法，诸 如语音或手势等等。）"点击这里"图标可包括如以上相对于图1引入的上下文定义URI和 /或与之相关联，但不必对用户明显。此外，平板型计算机202可包括可管理对上下文定义 URI的处理的URI管理器216。
[0042] 如在实例2明显地，临床医师的点击启动在平板型计算机202上运行的本地成像 应用220。此外，在没有用户/临床医生的任何劳动的情况下，本地成像应用220被设置为 与基于web的电子记录管理器206相同的上下文（例如，本地成像应用正在显示患者ID SM12345的新图像）。在这一示例中，新图像222来自日期2012-12-27。在这一示例中，上 下文涉及患者ID，但这仅仅是一个示例。在另一示例中，上下文可涉及患者ID和日期，使得 上下文被设置成显示同一天从患者获取的化验结果和图像。总而言之，单个用户动作可使 得多个应用在用于该用户的通用上下文中操作。在这种情况下，一个应用是web用于而一 个应用是远程应用。然而，本发明的概念适用于其它场景，诸如使得多个本地应用根据通用 上下文操作。一个这样的示例以下对于图3描述。
[0043] 图3示出了用于与应用上下文式交互的另一用例场景。该场景涉及智能电话型计 算机302,但适用于其它类型的计算机。该场景以以上相对于临床医生及其患者的示例继 续，但是当然可涉及医疗上下文中的其它场景，或医疗上下文以外的场景。在这一场景中， 临床医生经由智能电话型计算机302接收关于患者的通知。在这一示例中，通知是在实例1 中接收到的电子邮件通知304。电子邮件在306指示有新结果可用于具有患者ID SM12345 的John Smith。电子邮件还包括用户可激活URI308,它写为'点击这里来查看新结果'。还 注意到智能电话型计算机302可包括URI管理器316, URI管理器316可管理对上下文定义 URI的处理，如实例2中明显地。假定临床医生激活用户可激活上下文定义URI308。
[0044] 实例2示出作为临床医生激活上下文定义URI308的结果，两个应用由URI管理器 316在智能电话型计算机302上启动。在这一情况下，应用包括化验记录应用318和成像 应用320。两个应用均被设置成患者ID SM12345的上下文，如分别在322和324所指示。 在化验记录应用318的情况下，上下文使得应用为上下文定义URI308中定义的上下文（例 如，患者ID SM12345)呈现肝功能组326。在成像应用320的情况下，上下文使得应用为上 下文定义URI中定义的上下文呈现图像328。从而，临床医生可简单地通过点击上下文定 义URI308来快速地审阅关于其患者John Smith (例如，患者ID SM12345)的最近信息，而 无需对上下文定义URI的上下文定义元素或URI管理器316提供的功能的任何理解。临床 医生仅仅点击上下文定义URI而不采取任何其它动作，可在化验记录应用318中查看该患 者的化验结果，并在成像应用320中查看图像。URI管理器316可处理应用的启动和/或应 用的上下文的改变而不会导致数据丢失，并使得上下文在临床医生的两个应用中显示。总 而言之，这些用例场景可适用于除临床医生以外的任何其它类型的用户。本发明的技术可 为用户的方便起见，允许用户通过激活上下文定义URI来自动启动一个或多个应用并自动 设置这些应用的上下文。
[0045] 方法示例
[0046] 图4示出了用于与应用上下文式交互的技术或方法400的流程图。
[0047] 在框402,方法可接收涉及实体的信息。例如，信息可以是涉及实体的触发事件。 在以上描述的一个示例中，实体可以是患者。在该示例中，当新的化验结果被获取，该信息 可作为对于患者的触发。
[0048] 在框404,该方法可生成一链接，该链接指定安装在计算机上的应用以及涉及该实 体的用于该应用的上下文。在一些实现中，链接可被显现为上下文定义URI。上下文定义 URI可使得应用在计算机上运行以呈现关于实体（例如，在此例中为患者）的信息。当上 下文定义URI被激活时，URI中定义的上下文可自动将应用设置成呈现关于该实体的数据 (例如，应用被设置成该实体的上下文）。
[0049] 图5示出了用于与应用上下文式交互的技术或方法500的流程图。
[0050] 在框502,该方法可接收指定要运行的应用并为该应用定义上下文的URI。在某些 情况下，URI可在应用被安装时在计算机上接收。
[0051] 在框504,该方法可运行该应用并如URI所定义地设置应用的上下文。在一些配 置中，该方法可确定运行的应用是否在计算机上被授权。例如，计算机的管理员可能手动定 义在计算机上什么动作被授权以及哪些动作不被授权。或者或另外地，管理员可能定义了 在计算机上被禁止的动作。该方法可确保仅被授权的动作被实际实现。在其它实现中，URI 可被检查以确定是否要实现URI传达的指令。例如，如果URI包含来自可信源的有效授权 (例如，签名），URI指令可关于或不关于为该计算机建立的授权来实现。换言之，伴随URI 的授权和/或源的可信度可在判断是否要实现URI时评估。
[0052] 在一些实现中，该方法可检查应用是否已经在运行。如果应用尚未运行，且运行应 用被授权，则应用可被启动。
[0053] 在应用已经运行的情况下，该方法可确定设置如URI定义的上下文是否应被允 许。例如，如果改变上下文将导致数据丢失，则上下文改变可被延迟。该方法可采取各种动 作，诸如通过与应用协商直到上下文改变可被安全作出。
[0054] 描述各示例方法的次序并不旨在解释为限制，并且任何数量的所述框或动作都可 以按任何次序组合以实现各方法或实现替换方法。此外，方法还可以用任何合适的硬件、软 件、固件或其组合来实现，以使得计算设备可实现该方法。在一种情况下，方法作为指令集 被存储在一个或多个计算机可读存储介质上，以使得计算设备的执行使得该计算设备执行 该方法。
[0055] 结语
[0056] 尽管已用对结构特征和/或方法动作专用的语言描述了涉及与应用的上下文式 交互的技术、方法、设备、系统等，但可以理解，所附权利要求书中定义的主题不必限于所述 具体特征或动作。相反，上述具体特征和动作是作为实现所要求保护的方法、设备、系统等 的示例性形式而公开的。
【权利要求】
1. 至少一种其上存储有指令的计算机可读存储介质，所述指令在被处理器执行时，使 所述处理设备执行以下动作： 接收涉及实体的信息；以及 生成链接，所述链接指定安装在计算机上的应用以及涉及所述实体的用于所述应用的 上下文。
2. 如权利要求1所述的计算机可读存储介质，其特征在于，所述接收信息包括接收触 发事件。
3. 如权利要求1所述的计算机可读存储介质，其特征在于，所述生成链接包括生成统 一资源标识符（URI)。
4. 如权利要求1所述的计算机可读存储介质，其特征在于，还包括向所述计算机发送 所述链接。
5. 如权利要求1所述的计算机可读存储介质，其特征在于，所述计算机可读存储介质 被体现为被包括在也包含所述处理器的远程计算机上的计算机可读存储设备。
6. 一种系统，包括： 其上安装了应用的集合的计算机；以及 被配置成接收上下文定义统一资源标识符（URI)的URI管理器，所述URI管理器被配 置成运行由所述上下文定义URI指定的所述应用的子集，并如所述上下文定义URI所指定 地为所述应用的子集设置通用上下文。
7. 如权利要求16所述的系统，其特征在于，所述URI管理器包括上下文协议处理器，所 述上下文协议处理器被配置成在隔离的安全环境中操作以从所述上下文定义URI读取信 息，并将所述信息传达给接收组件，所述接收组件被配置成以允许与上下文管理系统和应 用管理系统通信的特权级别操作。
8. 如权利要求17所述的系统，其特征在于，所述接收组件被配置成与所述应用管理系 统协作操作以确定在所述计算机上是否允许在所述上下文定义URI中定义的动作。
9. 如权利要求17所述的系统，其特征在于，所述应用的集合是由所述上下文管理系统 管理的受管应用。
10. 如权利要求16所述的系统，其特征在于，所述计算机包括不是所述应用的集合的 一部分的另一应用，且其中所述另一应用被配置成生成所述上下文定义URI。
【文档编号】G06F9/06GK104115112SQ201380009925
【公开日】2014年10月22日 申请日期:2013年2月11日 优先权日:2012年2月17日
【发明者】G·E·哈兹, D·福萨利 申请人:微软公司