与一个或多个扩展应用程序对接的消息应用程序

摘要

本发明涉及与一个或多个扩展应用程序对接的消息应用程序。本发明在一个实施方案中提供了一种消息系统，该消息系统包括被配置为创建被显示在由消息应用程序托管的视图中的内容的消息应用程序、以及一个或多个扩展应用程序。该消息应用程序可启动一个或多个扩展应用程序并且通过进程间通信来在每个扩展应用程序和消息应用程序之间传送内容。

说明书

本申请是申请日为2017年6月12日的、名称为“与一个或多个扩展应 用程序对接的消息应用程序”的发明专利申请No.201710435784.4的分案申 请。

技术领域

本公开所述的实施方案涉及蜂窝电话或其他通信设备或数据处理系统 上的消息系统诸如文本消息系统。

背景技术

对文本消息系统的使用开始于许多年前。例如，在20世纪90年代在 智能手机可用之前，无线蜂窝电话运营商诸如Verizon或AT&T通过用于 蜂窝电话的短消息服务(SMS)而允许该文本消息。通常，所传输的数据量受 限于运营商所制定的规则。最近，随着智能电话(例如，iPhone)和平板电 脑(例如，iPad)的使用增加，文本消息系统已开发出发送图像诸如照片或 表情符号的能力。此外，消息系统诸如得自Apple Inc.(Cupertino,California)的iMessage已允许用户通过“公共”网络来发送和接收文本和图像，该 “公共”网络包括“公共”WiFi接入点和互联网(除使用无线运营商的专 用蜂窝电话网络之外)，并且消息系统诸如iMessage可根据例如WiFi接入 点的可用性或其他用户设备的兼容性(其可能与iMessage不兼容)来在对 公共网络和专用网络的使用之间进行无缝转换。

发明内容

本文所述的实施方案的一个方面涉及消息系统，该消息系统在客户端 设备上包括被配置为创建被显示在由即时消息应用程序托管的视图中的内 容的即时消息应用程序以及一个或多个扩展应用程序即时消息应用程序可 启动一个或多个扩展应用程序，并且在一个实施方案中，该内容通过进程 间通信在每个扩展应用程序和即时消息应用程序之间被传送。在一个实施 方案中，方法可包括：通过第一设备上的第一即时消息应用程序來从第二 设备接收消息以及相关联的元数据，该消息包括由与所述第二设备上的第 二即时消息应用程序一起操作的第二扩展应用程序创建的内容。在一个实 施方案中，第一即时消息应用程序和第二即时消息应用程序各自被配置为 传输短消息服务(SMS)文本消息以及其他内容，并且将那些文本消息显示在 消息记录中。该方法还可包括将消息记录中的内容显示在即时消息应用程 序的用户界面视图中，并且将该内容从第一即时消息应用传送至由元数据 中的应用程序标识符所识别的第一扩展应用程序，该内容通过进程间通信(IPC)从在第一进程中执行的第一即时消息应用程序而被传送至在不同于第 一进程的第二进程中执行的第一扩展应用程序。该方法还包括将第一扩展 应用程序的用户界面显示在第一即时消息应用程序的用户界面内。

在一个实施方案中，第一扩展应用程序的用户界面被配置为显示内容 诸如由第二设备上的第二扩展应用程序创建的内容，并且接收用户输入以 修改内容。在一个实施方案中，扩展应用程序中的每个扩展应用程序的用 户界面在被显示时可替代即时消息应用程序的屏幕键盘。在一个实施方案 中，第一扩展应用程序可修改内容并且通过IPC来将经修改的内容传送到 第一即时消息应用程序，以用于传输至用于递送至所述第二设备上的所述 第二扩展应用程序的所述第二即时消息应用程序。在一个实施方案中，第 一扩展应用程序和第二扩展应用程序为相同的扩展应用程序的两个实例并 且各自由相同的应用程序标识符所识别，该相同的应用程序标识符可由应 用程序市场或提供扩展应用程序的下载的其他服务来提供。

在一个实施方案中，第一扩展应用程序可被配置为接收其他设备(第 二设备)的用户的模糊标识符，其中模糊标识符可被配置为对于相对于第 一设备上的所有其他扩展应用程序的第一扩展应用程序是唯一的。模糊标 识符允许每个扩展应用程序在协同环境下识别用户，诸如其中多个用户尝 试安排会议或预订餐厅处的桌位的环境等。

在一个实施方案中，第一扩展应用程序可改变由即时消息应用程序所 托管的视图。例如，在一个实施方案中，第一扩展应用程序可通过应用程 序编程接口(API)来调用第一即时消息应用程序，以请求改变第一即时消息 应用程序内的扩展应用程序的视图。在一个实施方案中，扩展应用程序的 视图的改变是在紧凑视图和展开视图之间的切换。在一个实施方案中，处 于紧凑视图中的扩展应用程序的用户界面可被显示在其中在第一即时消息 应用程序的消息记录保持可见时显示第一即时消息应用程序的屏幕键盘的 屏幕区域中。在另一个实施方案中，扩展应用程序的紧凑视图可作为叠层 而被显示在屏幕键盘上。在一个实施方案中，处于扩展视图中的扩展应用 程序的视图被显示在其中屏幕键盘和消息记录两者被显示以使得消息记录 不可见并且第一即时消息应用程序的屏幕键盘也不可见的屏幕区域中。

在一个实施方案中，从第二设备接收的元数据可包括通过IP通过由第 一即时消息应用程序而被传送至第一扩展应用程序的统一资源定位符(URL) 或其他类型或形式的资源定位符(例如，统一资源标识符(URI)、XML 等)、以及数据，其中资源定位符和数据保持第二设备上的第二扩展应用 程序和第一设备上的第一扩展应用程序之间的会话信息。在一个实施方案 中，扩展应用程序通过将其视图托管在每个设备上的相应的即时消息应用程序来进行通信。在一个实施方案中，每个扩展应用程序可被配置为修改 资源定位符或数据中的至少一者并且通过两个即时消息应用程序来将经修 改的资源定位符或数据传送到其他扩展应用程序。在一个实施方案中，资 源定位符或数据的改变可在会话中实现，其中由于气泡内的信息随通信两 侧的用户交互而改变，因此消息记录中的相同的会话气泡随时间的推移而 被显示。在一个实施方案中，每个扩展应用程序还可从其对应的即时消息应用程序接收用于指示其他扩展应用程序是否接收到经修改的内容诸如经 修改的资源定位符或数据的回调。

本文所述的实施方案的另一方面涉及扩展应用程序如何响应于由即时 消息应用程序呈现的对消息记录中的消息气泡的选择而被启动。根据这一 方面的方法可包括：通过第一设备上的第一即时消息应用程序来从第二设 备接收消息和元数据，该消息包括由与所述第二设备上的第二即时消息应 用程序一起操作的第二扩展应用程序创建的内容。该方法还包括将信息容 器中的内容诸如消息气泡显示在即时消息应用程序的消息记录内，并且然 后接收对消息容器的选择，诸如用户的手指在消息气泡上的轻击。如果第 一扩展应用程序响应于选择消息气泡而被安装在第一设备上，该方法还可 包括启动该第一扩展应用程序，其中第一扩展应用程序通过从第二设备接 收的元数据中的应用程序标识符而被识别，以用于进行启动。在一个实施 方案中，该方法还包括在启动之后将第一扩展应用程序的用户界面显示在 第一即时消息应用程序的用户界面内。在一个实施方案中，消息容器可为 由元数据中的气泡标识符所指定的消息气泡，并且内容可与气泡标识符相 关联，使得由第二扩展应用程序创建的内容出现在具有该气泡标识符的消 息气泡内。在一个实施方案中，第一即时消息应用程序和第二即时消息应 用程序各自被配置为传输SMS文本消息以及其他内容，并且将消息气泡中 的文本消息显示在消息记录中在一个实施方案中，第一即时消息应用程序 和第一扩展应用程序被配置为通过IPC进行通信，并且第一即时消息应用 程序在第一沙箱进程中执行，并且第一扩展应用程序在不同于第一沙箱进 程的第二沙箱进程中执行。在一个实施方案中，在选择消息气泡之前，该 内容由第一即时消息应用程序来显示，而无需启动或执行第一扩展应用程 序；换句话讲，在一个实施方案中，无需执行第一扩展应用程序，以便使 内容由第一即时消息应用程序显示在消息气泡中。在一个实施方案中，API 可存在于第一即时消息应用程序和第一扩展应用程序之间，以允许通过利用API的调用来进行通信。

在一个实施方案中，由第一即时消息应用程序接收的内容以加密形式 接收并且通过第一即时消息应用程序来解密，并且解密形式通过IPC而被 传送到第一扩展应用程序。

在一个实施方案中，如果第一扩展应用程序未被安装，则第一即时消 息应用程序可提供对第一扩展应用程序的下载和安装。第一即时消息应用 程序可保持所安装的扩展应用程序的注册表(例如，列表)，并且该注册 表可用于确定扩展应用程序是否在例如用户轻击或选择具有由特定扩展程 序创建的内容的消息气泡时被安装。如果响应于对该消息气泡的选择，第 一即时消息应用程序确定处理内容(如与消息一起提供的应用程序标识符所指定的)所需的特定扩展应用程序未被安装，则第一即时消息应用程序 可向用户呈现为用户提供用于选择哪个选项将使得设备下载和安装扩展应 用程序的选项的通知。在一个实施方案中，在第一即时消息应用程序将前 台应用程序保持在设备上时，可在后台中执行扩展应用程序的下载和安 装。

本文所述的实施方案的另一方面涉及用于提供向后兼容性的方法，其 可在一个设备与旧设备或具有与新消息系统不完全兼容的旧消息系统的设 备进行通信时发生。在一个实施方案中，根据这一方面所述的方法可包 括：通过在第一进程中执行的扩展应用程序来创建在由第一设备上的第一 即时消息应用程序托管的视图内显示的内容，其中第一即时消息应用程序 在不同于第一进程的第二进程中执行，并且响应于对发送命令的选择，该 内容通过进程间通信从扩展应用程序传送至第一即时消息应用程序，以使 得该内容被发送至第二设备。该方法还可包括通过第一即时消息应用程序 来从关于第二设备的数据确定第二设备上的第二即时消息应用程序与扩展 应用程序不兼容，并且然后通过第一即时消息应用程序来将另选内容发送 至第二即时消息应用程序。在一个实施方案中，该另选内容可包括以下各 项中的一者或多者：(a)标准格式的图像；或(b)可检索＝第二设备上的网页 的资源定位符。

本文所述的实施方案的另一方面涉及在一个实施方案中可提供扩展应 用程序的可浏览视图的应用程序市场或类似的服务，该可浏览视图可从应 用程序市场或类似的服务下载和安装。在一个实施方案中，应用程序可免 费获取或者可购买，并且然后下载并且被安装在用户设备上。在一个实施 方案中，下载可响应于对消息气泡的选择而发生，该消息气泡包含由尚未 安装在接收设备上的扩展应用程序创建的内容。在一个实施方案中，方法 可包括以下操作：通过第一设备上的第一即时消息应用程序(应用程序) 来从第二设备接收消息以及相关联的元数据，其中消息包括由与所述第二 设备上的第二即时消息应用程序一起操作的第二扩展应用程序创建的内 容，其中相关联的元数据包括与第二扩展应用程序相关联的应用程序标识 符；将消息记录中的内容显示在第一即时消息应用程序的用户界面视图 中；确定由应用程序标识符所识别的第一扩展应用程序是否被安装，以用于与第一即时消息应用程序一起使用；向用户显示包括使得第一设备下载 和安装第一扩展应用程序的选项的通知，其中通知响应于确定第一扩展应 用程序未被安装以用于与第一即时消息应用程序一起使用而被显示；并且 响应于对选项的选择，下载并安装第一扩展应用程序。在一个实施方案 中，响应于消息记录中的内容(例如，用户轻击消息记录的消息气泡中的 内容)的用户选择，第一设备确定由应用程序标识符所识别的第一扩展应 用程序未被安装。在一个实施方案中，第一扩展应用程序从提供用于下载 的多个消息扩展应用程序的服务进行下载，并且应用程序标识符由该服务 提供。在一个实施方案中，服务包括具有可从服务下载的消息扩展应用程 序的可浏览目录的一个或多个服务器系统。在一个实施方案中，第一扩展 应用程序的下载和安装可在第一即时消息应用程序保持前台应用时发生。 在一个实施方案中，该方法还可包括：向已安装的扩展应用程序的可浏览 视图添加表示第一扩展应用程序的图标，该可浏览视图由第一即时消息应 用程序显示，并且对图标的添加可在第一扩展应用程序被安装之后发生。

在一个实施方案中，已安装的第一扩展应用程序可通过IPC与第一即 时消息应用程序进行通信，该第一即时消息应用程序在不同于执行第一扩 展应用程序的第二进程的第一进程中执行。

本文所述的实施方案的另一方面涉及扩展应用程序，该扩展应用程序 为图像创建应用程序，诸如可创建贴纸并且可修改那些贴纸的外观并且可 允许将那些贴纸放置在由即时消息应用程序提供的消息记录中的一个或多 个消息气泡上的应用程序。在这一方面的一个实施方案中，方法可包括下 以下操作：接收选择，以在由即时消息应用程序托管的贴纸扩展应用程序 (应用程序)的用户界面视图内创建贴纸图像；接收用于指定对所选择的 贴纸图像的改变的一个或多个用户输入，该一个或多个用户输入限定图像 元数据；通过贴纸扩展应用程序和第一即时消息应用程序之间的进程间通 信来将贴纸图像和图像元数据传送至第一即时消息应用程序；通过第一即 时消息应用程序来将贴纸图像、消息和图像元数据上传至用于将消息、贴 纸图像和图像元数据递送至接收设备的一个或多个消息服务器；通过第一 即时消息应用程序来接收和存储来自所述一个或多个消息服务器的令牌， 该令牌表示贴纸图像；响应于用于将贴纸图像发送至接收设备或发送至其 他接收设备的后续请求，通过第一即时消息应用程序来将令牌发送至一个 或多个消息服务器，而无需再同时发送贴纸图像。在一个实施方案中，该 方法还可包括通过由第一即时消息应用程序托管的视图中的贴纸扩展应用 程序来显示一组贴纸图像，每个贴纸图像可由用户进行选择，以使得与由 第一即时消息应用程序提供的消息记录视图中的消息气泡中的消息相关 联。在一个实施方案中，用户通过将贴纸图像拖动到消息气泡上来使贴纸 图像与消息气泡相关联。在一个实施方案中，图像元数据可包括以下各项 中的一者或多者：(a)改变贴纸图像的尺寸的缩放数据；(b)改变消息气泡上 的贴纸图像的旋转或取向的旋转数据；(c)消息或消息气泡上的贴纸图像的 位置数据；或其他图像修改数据(例如，透明度或色差等)。在一个实施 方案中，贴纸图像的数据量受消息系统的约束，以保持低于预先确定的限值。第一即时消息应用程序将消息记录中的消息上的贴纸图像显示在第一 即时消息应用程序的视图内，并且消息上的贴纸图像的尺寸、旋转和位置 可由图像元数据指定。在一个实施方案中，当消息(与贴纸图像)被发送 至多个接收设备时，第一即时消息应用程序可对每个接收设备的贴纸图像 进行加密，以生成多个加密贴纸图像。例如，在一个实施方案中，每个接 收设备的公钥可用于对贴纸图像进行加密(或对用于加密贴纸图像的密钥 进行加密)，并且每个不同的接收设备可具有不同的公钥。在一个实施方 案中，非对称加密算法诸如公钥/私有密钥加密算法可用于对贴纸图像进行 加密(或用于对那些图像的密钥进行加密)。该方法还可包括从一个或多 个消息服务器接收令牌的生存时间(TTL)值，该TTL值响应于用于发送与令 牌对应的贴纸图像的后续请求来在第一即时消息应用程序处和一个或多个 消息服务器处进行刷新。在一个实施方案中，该方法还可包括通过第一即 时消息应用程序来从关于接收设备的数据确定接收设备上的即时消息应用 程序与贴纸应用程序不兼容，并且在其与贴纸应用程序不兼容时，通过第 一即时消息应用程序来将另选内容发送至接收设备。

本文所述的实施方案的另一方面涉及在接收设备上使用图像元数据来 再现最终贴纸图像的方法。在一个实施方案中，根据这一方面所述的方法 包括以下操作：通过第一设备上的第一即时消息应用程序来从第二设备接 收消息和令牌、以及相关联的元数据(其可包括图像元数据)，该令牌涉 及由与第二设备上的第二即时消息应用程序一起操作的第二贴纸扩展应用 程序所创建的贴纸图像；通过第一即时消息应用程序来将令牌发送至一个 或多个消息服务器，以获取贴纸图像；通过第一即时消息应用程序来接收 贴纸图像，以通过将图像元数据应用至贴纸图像来对发送令牌并生成最终 图像进行响应；以及通过第一即时消息应用程序来将最终图像显示在包含 该消息的消息气泡处或附近。在一个实施方案中，第一即时消息应用程序 在第一进程中执行，并且第一贴纸扩展应用程序在不同于第一进程的第二 进程中执行，并且其中消息气泡由气泡标识符所识别。在一个实施方案中，第一即时消息应用程序接收加密形式的贴纸图像并且对贴纸图像进行 解密，并且通过IPC来将解密形式的贴纸图像提供至第一贴纸扩展应用程 序。在一个实施方案中，图像元数据包括以下数据中的一者或多者：(a)改 变贴纸图像的尺寸的缩放数据；(b)改变图像贴纸的旋转的旋转数据；或(c) 其他图像修改数据。在一个实施方案中，第一即时消息应用程序使用贴纸 图像的散列来确定在发送令牌之前第一即时消息应用程序是否已具有贴纸图像的副本；在一个实施方案中，该散列可被包含在相关联的元数据或图 像元数据中。在一个实施方案中，该方法还可包括自动响应于接收到消息 来启动第一贴纸扩展应用程序，其中发生启动，而无需用户操作或干预。

本文所述的实施方案的另一方面涉及一种用于操作消息系统中的一个 或多个消息服务器的系统和方法。在一个实施方案中，根据这一方面所述 的方法包括以下操作：从第一即时消息应用程序接收用于递送至多个接收 人的多个加密贴纸图像，该多个加密贴纸图像中的每个加密贴纸图像在被 解密时表示相同的贴纸图像；创建多个令牌并将其传输至第一即时消息应 用程序，该多个令牌中的每个令牌被分配至多个接收人中的一个接收人； 创建加密贴纸图像中的每个加密贴纸图像的生存时间(TTL)值并且将TTL值 中的至少一个TTL值传输至第一即时消息应用程序；存储多个加密贴纸图 像以及多个令牌和TTL值；以及响应于第一即时消息应用程序再次将相同 的贴纸图像发送至多个接收人中的一个接收人并且刷新与所接收的令牌对 应的TTL值来从第一即时消息应用程序接收多个令牌中的一个令牌。在一 个实施方案中，该方法还可包括响应于第二即时消息应用程序发送多个令 牌中的一个令牌来将加密贴纸图像发送至接收设备上的第二即时消息应用 程序，所发送的令牌对应于所发送的加密贴纸。在一个实施方案中，可执 行该方法的一个或多个消息服务器还可接收多个加密消息，一个加密消息 针对多个接收人中的每个接收人。在一个实施方案中，所述一个或多个消 息服务器可存储所述所述多个加密贴纸图像、多个令牌以及一组一个或多 个数据库中的TTL值。在一个实施方案中，该方法还可包括从第一即时消 息应用程序接收与相同的贴纸图像相关联的元数据并且将元数据传输至第 二即时消息应用程序。在一个实施方案中，该元数据可为以下各项中的至 少一者：(a)由从中可下载扩展应用程序的服务提供的贴纸扩展应用程序标 识符；或(b)由贴纸扩展应用程序使用的图像元数据，该贴纸扩展应用程序 与第二即时消息应用程序一起操作，以创建经修改的贴纸图像。

虽然前述示例描述了对贴纸和贴纸图像的TTL值的使用，但在本文所 述的一个或多个实施方案中，TTL值可用于被发送或存储或接收在消息系 统中的其他对象和内容。

在一个或多个实施方案中，可显示消息记录中的贴纸源的指示符。这 样可允许贴纸的接收人查看发送贴纸的人员。在一个实施方案中，指示符 可为消息记录中突出显示或围绕贴纸的颜色，或者另选地接收人可选择使 得显示贴纸详细信息窗口的贴纸，该贴纸详细信息窗口显示关于贴纸的详 细信息，包括贴纸的原始艺术家或开发者(或其他来源)、以及可已能修 改贴纸的发送者。在一个实施方案中，在消息记录中显示的贴纸的来源或 其他属性可在接收设备第一次接收到贴纸时的短时间内自动被显示在消息 记录中，并且然后不显示有关贴纸的来源或属性的信息。

在一个实施方案中，一种用于结合即时消息应用程序进行操作的方法 可根据扩展应用程序的类型或根据有关扩展应用程序的策略来以不同的方 式启动扩展应用程序。在一个实施方案中，一种方法可包括以下操作：响 应于接收到包含由扩展应用程序创建的内容的消息，通过即时消息应用程 序来确定扩展应用程序的类型；如果扩展应用程序为第一类型的扩展应用 程序或用于扩展应用程序的策略允许此类启动(例如，扩展应用程序请求 立即启动并且即时消息应用程序授权此类扩展应用程序的请求，或扩展应 用程序为预先确定类型或其内容为预先确定的类型)，则响应于接收到消 息而自动启动扩展应用程序；如果扩展应用程序为第二类型的扩展应用程 序(或策略决定推迟启动)，则推迟启动扩展应用程序，直到接收到对被 显示在消息记录中的消息气泡的选择，该消息记录由即时消息应用程序显 示。在一个实施方案中，该选择从选择消息记录中的消息气泡的用户接 收。在一个实施方案中，扩展应用程序指定其作为第一类型的扩展应用程 序还是作为第二类型的扩展应用程序进行操作，并且即时消息应用程序可 应用一种或多种策略，以允许自动启动或推迟启动扩展应用程序。在一个 实施方案中，第一类型的扩展应用程序在被接收到时进行启动，但是保持 在后台中(并且在一个实施方案中，可在处于后台中时，更新其消息气泡 中的内容)，直到在用户选择用于显示来自扩展应用程序的内容的消息气 泡时使得扩展应用程序显示在前台中(例如，选择替代屏幕键盘而被显示 在紧凑视图模式下)。

本文所述的实施方案的另一方面涉及在两个设备上的两个扩展应用程 序之间的会话中使用面包屑。在一个实施方案中，使用面包屑的方法可包 括以下操作：在消息记录中显示包含由第一扩展应用程序创建的第一内容 或与该第一内容相关联的第一消息气泡，该第一消息气泡具有保持用于由 第一即时消息应用程序使用的会话标识符；在第一设备的第一即时消息应 用程序处接收发生在第二设备上的第一扩展应用程序和第二扩展应用程序 之间的会话的第二内容，其中会话由会话标识符所识别；将第一内容转换 为面包屑并且显示包含第二内容或与第二内容相关联的第二消息气泡，其 中第一即时消息应用程序使会话标识符与面包屑和第二消息气泡两者相关 联。在一个实施方案中，第一扩展应用程序提供待显示为面包屑的至少一 部分的第三内容。在一个实施方案中，第二内容由第二设备上的第二扩展 应用程序创建并且通过第二设备上的第二即时消息应用程序传输至第一设 备。在一个实施方案中，第一即时消息应用程序将第一内容转换为面包 屑。

本文所述的方法和系统可由数据处理系统诸如一种或多种智能手机、 平板电脑、台式计算机、膝上型计算机、智能手表、可穿戴音频附件、机 载计算机、以及其他数据处理系统和其他消费电子设备来实现。本文所述 的方法和系统还可由一种或多种数据处理系统来实现，该一种或多种数据 处理系统执行被存储在一种或多种非暂态机器可读介质中的可执行计算机 程序指令，使得一种或多种数据处理系统在执行程序指令时执行本文所述 的一种或多种方法。因此，本文所述的实施方案可包括方法、数据处理系 统和非暂态机器可读介质。

以上概述不包括本公开的所有实施方案的详尽列表。所有系统和方法 可根据以上概述的各个方面和实施方案以及以下具体实施方式中所公开的 那些的所有合适组合来实践。

附图说明

本发明以举例的方式进行说明，并且不仅限于各个附图的图形，在附 图中类似的标号指示类似的元件。

图1A示出通信设备上的即时消息应用程序的用户界面的示例。

图1B示出通信设备上的即时消息应用程序的用户界面的另一个示例。

图2示出采用一种或多种消息服务器以向一组客户端设备提供消息服 务的消息系统的示例。

图3A示出根据一个实施方案的用于提供扩展应用程序以用于与即时 消息应用程序一起使用的架构的框图。

图3B示出根据本文所述的一个实施方案的至少部分地由扩展应用程序 创建的消息气泡的用户界面的示例。

图3C示出基于模板的消息气泡的部分的示例。

图4A为示出根据一个实施方案的用于从根据本文所述的一个或多个 实施方案所述的即时消息应用程序内浏览、选择和启动扩展应用程序的方 法的流程图。

图4B示出即时消息应用程序的用户界面的示例，其包括根据本文所述 的一个实施方案的已安装的扩展应用程序的可浏览视图。

图5A示出即时消息应用程序的用户界面的示例，其包括即时消息应 用程序的用户界面内的扩展应用程序的视图。

图5B示出在用户已在扩展应用程序中创建内容之后的扩展应用程序的 用户界面，其中扩展应用程序的视图托管在即时消息应用程序的用户界面 内被托管。

图5C示出在用户已使用扩展应用程序创建内容并且使用用于发送内容 的即时消息应用程序发送内容之后的通信设备上的即时消息应用程序的用 户界面的示例。

图5D示出在接收设备接收到由发送设备上的扩展应用程序所创建的 内容之后的接收设备上的即时消息应用程序的用户界面的示例。

图5E示出在接收设备的用户选择包含由发送设备上的扩展应用程序所 创建的内容的消息气泡以使得接收设备的用户可编辑接收设备上的内容时 的接收设备上的用户界面的示例。

图5F示出提供对用于与设备上的即时消息应用程序一起使用的扩展应 用程序的下载和安装的用户界面的示例。

图6为示出根据本文所述的一个实施方案的可在接收设备上执行的方 法的流程图。

图7A为示出根据一个实施方案所述的方法的流程图，在该方法中， 扩展应用程序可根据一个实施方案来改变其由即时消息应用程序托管的视 图。

图7B示出根据一个实施方案的处于扩展视图中的扩展应用程序的用户 界面的示例。

图8示出根据一个实施方案的其中两个或更多个设备上的扩展应用程 序可通过每个设备上的即时消息应用程序彼此进行交互的示例。

图9A为示出根据本文所述的一个或多个实施方案的用于允许不同设 备上的扩展应用程序之间的交互的方法的流程图。

图9B示出用户界面中的消息气泡的示例，该用户界面可在两个或多个 扩展应用程序在会话中进行交互时由图9A所示的方法引起。

图9C示出根据一个实施方案的消息气泡的示例，其中针对所需的扩展 应用程序下载和安装在即时消息应用程序保持在前台中时发生。

图9D、图9E、图9F、图9G和图9H示出参与两个即时消息应用程序 (每个设备上一个)之间的会话的两个不同设备上的消息记录的示例，其 中该会话涉及两个扩展应用程序之间的会话。图9D、图9E、图9F、图9G 和图9H所示的用户界面示出根据本文所述的一个或多个实施方案的由扩展 应用程序创建的消息气泡中的内容如何能够被转换为面包屑。

图10为示出根据本文所述的一个实施方案的方法的流程图。

图11为示出根据本文所述的一个实施方案的方法的流程图。

图12示出即时消息应用程序的用户界面，其中来自两个或更多个扩展 应用程序的内容存在于由即时消息应用程序提供的相同的消息记录内。

图13A为示出根据一个实施方案的用于提供对旧设备或旧消息系统的 向后兼容性的方法的流程图。

图13B示出已在即时消息应用程序内提供向后兼容性的用户界面的示 例。

图14A示出根据一个实施方案的方法，其中接收设备(其已接收到消 息)下载和安装所需的扩展应用程序，以检查消息中的一个消息的内容或 与该内容进行交互。

图14B示出可从中下载和安装扩展应用程序的扩展应用程序市场或服 务的用户界面的示例。

图15示出根据一个实施方案的用于提供使用发送设备和接收设备两者 上的贴纸扩展应用程序的消息系统的示例。

图16A为示出根据一个实施方案的可在如图15所示的系统中执行的方 法的流程图。

图16B为示出根据一个实施方案的可在如图15所示的系统中执行的另 一种方法的流程图。

图16C示出根据即时消息应用程序的一个实施方案的用户界面，该即 时消息应用程序托管已用于创建贴纸并且将贴纸应用于即时消息应用程序 的消息记录中的消息的贴纸扩展应用程序的视图。

图17为示出可用于本文所述的实施方案中的一个或多个实施方案的示 例性API架构的框图。

图18示出了例示可包括操作系统中的一种或多种应用程序和服务的软 件栈的框图。

图19示出可用于本文所述的一个或多个实施方案中的数据处理系统的 示例。

具体实施方式

将参考以下讨论的细节来描述各种实施方案和方面，并且附图将对各 种实施方案进行说明。以下说明书和附图为例示性的，并且不应被理解为 限制性的。描述许多的具体细节，以提供对各种实施方案的彻底理解。然 而，在某些实例中，熟知的或常规的细节并未被描述，以便提供对实施方 案的简明论述。

在本说明书中提到的“一个实施方案”或“实施方案”是指结合该实 施方案所述的特定特征、结构或特性可被包括在至少一个实施方案中。在 本说明书中的不同位置出现的短语“在一个实施方案中”不一定都是指同 一个实施方案。下图中示出的进程通过处理逻辑部件来执行，该处理逻辑 部件包括硬件(例如，电路、专用逻辑部件等)、软件、或两者的组合。 虽然下文按照某些顺序操作来描述该进程，但应当理解，所描述的某些操 作可以不同的顺序执行。此外，某些操作也可并行执行而非按顺序执行。

本文所述的各种实施方案涉及消息系统，诸如文本消息系统、或“聊 天”消息系统、或允许设备在设备之间传送消息的其他系统。例如，Apple Inc.(Cupertino,California)的iMessage为iOS设备和Mac(OS X)计算机的消 息服务的一个示例。通常，消息系统包括多个客户端设备，每个客户端设 备包括至少一个即时消息应用程序以及可从客户端设备接收消息并且将消 息传输至客户端设备的一组一个或多个消息服务器。图1A示出客户端设备 上的即时消息应用程序的用户界面的示例。客户端设备可为通信设备10，该通信设备10可为智能手机、或平板电脑、或台式计算机、或膝上型计算 机、可穿戴机载计算机、或其他数据处理系统或其他消费电子设备。在一 个实施方案中，设备可包括可显示图像并且还从用户接收触摸输入的常规 触摸屏。通信设备上的触摸屏12可显示即时消息应用程序的用户界面，该 用户界面可包括消息记录16以及消息记录16下方的屏幕键盘20。此外， 在一个实施方案中，即时消息应用程序的用户界面可包括指示从通信设备 10发送的消息的接收人的用户名14。此外，用户界面可包括在被发送之前 指示由用户输入的文本的内容的文本输入区域18；在某种意义上，文本输 入区域18为指示文本已准备好发送中接收人的文本暂存区域。

图1B示出通信设备10A上的即时消息应用程序的用户界面的更详细 的示例。在该实施方案中，用户界面被显示在触摸屏12A中，并且包括屏 幕键盘20A、文本输入区域18A、消息记录16A、和示出向其发送消息和 接收消息的其他用户的名字的用户名14A。文本输入区域18A为内容诸如 文本、贴纸、扩展应用程序内容、图像等中的一者或多者的暂存区域，这 些内容准备好响应于对发送命令的用户选择而被发送(并且在一个实施方 案中，该内容可在暂存区域中进行编辑)。在图1B所示的示例中，来自 Freddy(用户名14A)被显示在消息记录16A的左侧，并且由通信设备 10A的用户所发送的消息被显示在消息记录16A的右侧。因此，消息气泡 17示出由通信设备10A的用户发送至Freddy的消息“在哪里？”以作为对来自Freddy的消息“今晚一起吃饭如何？”的回答。消息气泡17中的消息 使得Freddy以消息气泡19中所示的“怎么样？”作为回答。对字词“气 泡”诸如消息气泡或会话气泡等的使用并非意在暗示任何具体的形状或形 式；而是旨在表示两个或更多个参与者之间的消息之间的任何形状或形式 的分界线，并且因此分界线可使用方块或线条或消息容器或不同的颜色 等。因此，短语“消息气泡”旨在覆盖两个或更多个参与者之间的消息之 间的所有此类分界线(或其他区分方式)，特别是在消息记录中的此类分 界线或其他区分方式的上下文中。在一个实施方案中，消息记录可上下滚 动，并且消息记录中的消息按照其时间被顺序呈现，因此用户可通过向上 或向下滚动视图来查看随时间推移的实际聊天或会话。图1B中示出的用户 界面还包括位于屏幕键盘20A上方以及文本输入区域18A左侧的三个图标 22,23和24。根据本文所述的一个或多个实施方案，扩展应用程序视图图标 22在被选择之后使得显示可与即时消息应用程序一起操作的已安装的扩展 应用程序的视图，并且所提供的视图可为可浏览视图，诸如图4B中所示的 可浏览视图157，以允许用户滚动通过所有已安装的扩展应用程序的多个页 面，该已安装的扩展应用程序被配置为与即时消息应用程序一起操作。在 一个实施方案中，成像应用程序图标23可为在被选择之后使得启动即时消息应用程序的插件的图标，该即时消息应用程序的插件在即时消息应用程 序进程内提供图像创建，诸如图5A、图5B和图5C中所示的插件。在一个 实施方案中，相机应用程序图标24在被选择时可使得通信设备10A进入相 机模式，在相机模式中，设备的相机可捕获可被放置在消息中以便发送图 像或视频的静态图像或视频图像。

现在将结合图2来提供消息系统的示例的简要概述。消息系统50可包 括多个客户端设备，诸如客户端设备53和54。根据本文所述的一个或多个 实施方案，这些客户端设备中的每个客户端设备可包括被配置为与扩展应 用程序一起操作的至少一个即时消息应用程序，并且对于与即时消息应用 程序中的扩展应用程序架构不兼容的设备，还传送至少文本消息以及任选 的资源定位符、或图像、或其他内容(例如，相对于图13A所述)。在典 型的消息系统中，可存在通过一组消息服务器进行通信的数百万个客户端 设备。在一个实施方案中，多个消息服务器可被配置为从发送设备接收加 密消息，并且然后将那些加密消息传输至接收设备。另一组服务器可被配 置为接收非文本内容，诸如图像或其他“附件”，并且在下载操作中响应 于来自那些接收设备的用于获取图像或附件的请求力气将那些图像或附件 提供至接收设备。在一个实施方案中，发送者的输出消息针对接收者设备 中的每个接收者设备而被单独加密。在一个实施方案中，非对称RSA加密 算法可用于执行加密。在一个实施方案中，接收设备中的每个接收设备的 公开RSA加密密钥可从目录服务(由一个或多个消息服务器保持)进行检 索，该目录服务包括数据库，诸如耦接至所述一个或多个消息服务器51的 数据库52。当客户端设备诸如客户端设备53试图将消息发送至另一个客户端设备时，其将其他客户端设备识别(诸如通过电子邮件地址、或电话号 码、或其他标识符)为一个或多个消息服务器51。该标识符从客户端设备 诸如客户端设备53发送至一个或多个消息服务器51，其然后基于所提供的 标识符在数据库52中执行查找操作，以检索与该标识符对应的公钥。然后 将该公钥传输回请求该特定接收设备的公钥的客户端设备，并且然后客户 端设备可使用公钥或使用可随机生成的另外的密钥(例如，对称密钥)来 对消息进行加密，并且针对特定的接收设备，该其他密钥使用公开RSA加 密密钥而被加密。在一个实施方案中，随机生成的密钥可在每个消息的基 础上随机生成。在一个实施方案中，所得的消息(一条消息针对每个接收 设备)包括加密消息文本、加密消息密钥和发送者的数字签名，并且然后 将每个接收设备的所得消息上传至一个或多个消息服务器51，以用于递送至接收人客户端设备，诸如客户端设备54。在一个实施方案中，消息系统 50可配置为通过“公共”网络进行操作，该“公共”网络包括公共WiFi接 入点(诸如咖啡店、机场等地的WiFi接入点)、以及互联网。每个客户端 设备53和54上的即时消息应用程序还可被配置为与通过无线蜂窝电话运 营商诸如Verizon和AT&T提供的“专用”网络一起操作，并且即时消息应用程序可被配置为根据每个网络的可用性并且根据消息会话中的客户端 设备中的每个客户端设备的兼容性在对专用网络和公共网络的使用之间进 行无缝切换。在一个实施方案中，消息服务器51可包括接收上传的文本消 息并且将那些文本消息“推送”至接收设备的一组推送通知服务器。

在一个实施方案中，客户端设备上的消息系统包括即时消息应用程序 和各自作为独立的进程来操作的一个或多个扩展应用程序。在一个实施方 案中，消息应用程序和一个或多个扩展应用程序可各自为在其自身的存储 空间内操作或执行的独立的沙箱进程。此外，即时消息应用程序还可与插 件诸如图5A所示的图像创建插件一起操作，该插件与即时消息应用程序在 相同的进程和存储空间内操作。即时消息应用程序和每个扩展应用程序通 过进程间通信诸如在iOS和Mac OS X中提供的XPC框架而彼此通信。即 时消息应用程序被设计为从设备的用户接收有关发送设备的文本，并且显 示消息记录中的文本，并且通过一组一个或多个消息服务器来将文本发送 至接收设备，该接收设备通过接收设备上的对应即时消息应用程序来显示 在接收设备上的消息记录中的所接收的文本。接收设备和发送设备可各自 具有相同的扩展应用程序的副本，其被配置为根据特定的扩展应用程序来 创建一定类型的内容(或者，在另选的实施方案中，其各自可包括与它们 使用的内容兼容的不同扩展应用程序的副本)。

图3A示出其中即时消息应用程序和一个或多个扩展应用程序一起操 作以提供增强的消息系统的软件架构的示例。如图3A所示，消息系统75 包括即时消息应用程序76和一组插件模块，诸如被配置为通过进程间通信 (IPC)81与一个或多个扩展应用程序83进行通信的组合模块77和数据传输 模块79。如图3A所示，即时消息应用程序以及组合模块77和数据传输模 块79在内存空间中的即时消息应用程序进程内进行操作，该内存空间由执 行消息系统75的通信设备上的内核进行控制。在消息气泡显示或以其他方 式呈现通过IPC 81传送至即时消息应用程序的内容时，组合模块77包括消 息气泡的内容。数据传输模块79通过IPC 81来将内容及其他数据传送至扩 展应用程序，并且通过IPC 81来从扩展应用程序接收内容以及其他数据。 在一个实施方案中，模块77和79两者可具有允许添加新扩展应用程序的 新插件的可扩展的插件架构，该新扩展应用程序生成新的内容或需要新的 数据传输进程。在此上下文中，插件是与即时消息应用程序在相同进程内 操作的附加软件。组合模块77可使用模板来构建消息气泡，诸如下文相对 于图3C所述的“MSMessageTemplateLayout”。内核可包括用于提供IPC 81以允许在消息系统75和一个或多个扩展应用程序83之间进行通信的软 件库或软件框架。在一个实施方案中，IPC框架可包括被称为扩展点的系统 区域，该扩展点提供API以允许在两个不同的进程之间进行通信并且在允 许的通信类型方面增强策略。在一个实施方案中，通过IPC进行通信涉及 通过一个进程来将内容放置在(写入)存储区域中，并且IPC框架允许从 该存储区域读取另一个进程。在一个实施方案中，即时消息应用程序76可 自动启动扩展应用程序并且可管理其寿命，包括那些进程的结束。在一个 实施方案中，扩展应用程序83中的每个扩展应用程序在使用以系统框架为 媒介的IPC的扩展应用程序和即时消息应用程序之间的其自身的地址空间 通信中运行，并且它们无法访问彼此的文件或存储空间。在一个实施方案 中，每个扩展应用程序可为彼此分开的沙箱进程，并且即时消息应用程序 76还可为与扩展应用程序的沙箱进程分开的独立沙箱进程。此外，扩展应 用程序相对于即时消息应用程序可设置有较少的系统权限，使得扩展应用 程序相比于即时消息应用程序在更受限制的环境下操作。关于使用扩展引 用程序的进程间通信的更多信息可见于2014年9月16日提交并且作为美国专利公布U.S.2015/0347748公布的美国专利申请号14/488,122，该专利 申请以引用方式并入本文。

在一个实施方案中，即时消息应用程序提供通过进程间通信从扩展应 用程序获取的内容的视图。扩展应用程序可在其自身的进程中创建内容， 然后以已知即时消息应用程序可接收的格式(诸如标准图像格式或其他标 准格式)来提供该内容。这使得即时消息应用程序随后将来自扩展应用程 序的内容呈现在消息记录的一个或多个消息气泡内(无需至少在接收设备 上执行扩展应用程序)。图3B示出包含由扩展应用程序创建和提供的内容 的消息气泡17A的示例，如内容85所示，该消息气泡还可包括由扩展应用 程序创建或提供的文本消息诸如文本消息86。在一个实施方案中，消息气 泡17A还可包括可为创建内容85的扩展应用程序的图标的图标87。

在一个实施方案中，由扩展应用程序创建的对象在发送设备和接收设 备上的消息记录中示出，而无需启动扩展应用程序。扩展应用程序应提供 足够的信息，以构建作为对象的一部分的消息气泡。该对象可包括在资源 定位符中编码的一些不透明的数据、以及作为MSMessageTemplateLayout 对象而提供的布局规格。MSMessageTemplateLayout为MSMessageLayout 的子类并且表示指定消息气泡布局的一种方法。

在一个实施方案中，MSMessageTemplateLayout可具有以下属性，如 图3C所示：

1)图像或媒体文件URL：图像作为UIImage或文件URL而被提供至 图像文件或作为文件URL而被提供至视频

2)图像标题：将被再现在图像或电影顶部上的字符串

3)图像副标题：将被再现在图像标题下方的图像或电影顶部上的字 符串

4)标题：将被再现在图像或电影下方的标题栏中的字符串

5)末尾标题：将被再现在右侧的与图像或电影下方的标题栏对准的 字符串

6)子标题：将被再现在标题下方的标题栏中的字符串

7)末尾子标题：将被显示在右侧的与末尾标题下方的标题栏对准的 字符串

8)扩展应用程序图标：这并非是MSMessageTemplateLayout的一部 分，但是其由MSMessage创建的扩展应用程序的包标识符得出。

即时消息应用程序可使用该信息来构造类似于图3C所示的示例的消息 气泡。

MSMessageTemplateLayout被序列化并且与不透明数据一起被传输至 远程设备。在接收设备上接收到即时消息应用程序时，将使用序列化数据 创建MSMessageTemplateLayout并且使用该模板布局来绘制接收者的消息 记录中的消息气泡。

在一个实施方案中，被配置为与即时消息应用程序一起操作的扩展应 用程序不可在即时消息应用程序之外执行，并且因此其生命周期完全由即 时消息应用程序来管理。此外，如下文进一步所述的，在一个实施方案 中，扩展应用程序的下载和安装可唯一地由即时消息应用程序控制。

在一个实施方案中，每个扩展应用程序可购自应用程序市场或分销商 诸如针对消息扩展应用程序的Apple应用程序商店(商标)，并且可从即 时消息应用程序内启动。图4A示出根据一个实施方案的方法的示例，其中 已安装的扩展应用程序可从即时消息应用程序内浏览，并且可启动特定的 扩展应用程序以允许用户与特定的扩展应用程序进行交互。该方法可从操 作101开始，其中即时消息应用程序显示其消息记录和屏幕键盘。图1B示出此类即时消息应用程序的用户界面的示例。然后在操作103中，即时消 息应用程序可接收输入以将已安装的扩展应用程序的可浏览视图显示在即 时消息应用程序的视图内。例如，用户可轻击图标22(图1B中)以选择 该图标，继而使得在操作105中显示可浏览视图。在一个实施方案中，已 安装的扩展应用程序的可浏览视图选择替代屏幕键盘，并且从执行注册表 检索已安装的扩展应用程序的列表，使得显示已安装的扩展应用程序中的 每个已安装的扩展应用程序的图标。图4B示出显示可浏览视图157并且替 代即时消息应用程序的屏幕键盘的操作105的结果的示例，如图4B所示。

参见图4B，从中可看到，可浏览视图157包括各自表示可与即时消息 应用程序一起操作的已安装的扩展应用程序中的一个已安装的扩展应用程 序的多个图标，该即时消息应用程序提供如图4B所示的用户界面。图4B 所示的即时消息应用程序的用户界面包括执行该即时消息应用程序的通信 设备150上的触摸屏151的上部部分中所示的消息记录153。其他用户(从 通信设备150发送的消息的接收人)的用户名155被示出于即时消息应用程序的用户界面的顶部处。文本输入区域155(其显示已暂存或准备好发送 的文本或其他内容)被显示在消息记录153和可浏览视图157之间。在一 个实施方案中，可浏览视图可通过在触摸屏上轻扫用户手指以使得显示已 安装的扩展应用程序的各种视图中的页面来进行浏览(并且在一个实施方 案中，还可示出例如需要完成下载进程或需要完成安装进程的未安装的扩 展应用程序)。在一个实施方案中，用户界面的底部处的页指示符159可 指示已安装的扩展应用程序的当前页。在一个实施方案中，可保留图标中 的一个图标以启动或进入扩展应用程序市场，其一个示例在如图14B中示 出。在另一个实施方案中，扩展应用程序市场可响应于选择图标167而被 显示在可浏览视图157中。在图4B所示的实施方案中，图标167为可被选 择以使得呈现扩展应用程序市场诸如图14B所示的扩展应用程序市场的扩展应用程序市场图标。在图4B所示的实施方案中，可选择图标169(例 如，用户轻击图标169)，以使得显示最近发送的贴纸或手写的消息或其他 最近发送的条目或最近使用的应用程序等的可浏览视图。在一个实施方案 中，显示最近发送的条目等可由在即时消息应用程序的进程内操作的插件 来提供。其他扩展应用程序包括可为可用于接合餐厅预订服务诸如Open Table的扩展应用程序的餐厅预订应用程序图标161。扩展应用程序的另一 个示例由图标163表示，在该图标163被选择时启动餐厅评论应用程序， 该餐厅评论应用程序提供餐厅评论并且其类似于例如由Yelp提供的评论。 其他扩展应用程序图标165和171表示已被安装并且可通过选择那些扩展 应用程序图标中的一个扩展应用程序图标来启动的其他扩展应用程序。

重新参见图4A，一旦可浏览视图通过操作105显示，则用户可通过选 择对应的图标来选择扩展应用程序中的一个扩展应用程序，其继而使得所 选择的扩展应用程序在操作107中启动。在一个实施方案中，即时消息应 用程序调用系统服务以启动所选择的扩展应用程序并且使用例如图3A所示 的架构使其准备好作为即时消息应用程序的扩展应用程序来执行。一旦所 选择的扩展应用程序已启动并且执行，则即时消息应用程序诸如即时消息 应用程序76可通过本文所述的IPC框架来托管由执行扩展应用程序所提供 的内容的视图。例如，在图4A中所示的操作109中，即时消息应用程序可 将由扩展应用程序提供的内容的视图显示在即时消息应用程序的视图的一 部分内。图5A至图5F现在将被描述为即时消息应用程序如何托管执行扩 展应用程序的内容的视图的示例。

图5A示出托管即时消息应用程序的一个插件的视图的即时消息应用 程序的示例，该插件为通过选择图标207(例如，用户触摸或轻击或以其他 方式来选择图标207)来启动的图像创建应用程序。在另一个实施方案中， 如图5A所示的用户界面的底部部分中示出的插件可通过选择图4B中可浏 览视图157中的图标中的一个图标来启动。虽然图5A所示的示例可被实现 为即时消息应用程序的插件，但是在另一个实施方案中，图5A所示的示例可为扩展应用程序。在图5A所示的示例中，插件(或扩展应用程序)的视 图选择替代即时消息应用程序的屏幕键盘，但是在一个实施方案中，即时 消息应用程序的消息记录仍然可见并且被显示在用户界面中，从而允许用 户滚动消息记录以查看整个记录。在另一个实施方案中，插件或扩展应用 程序的视图为屏幕键盘顶部的叠加图，其一部分可以是可见的。在一个实 施方案中，记录被显示在通信设备200的触摸屏202上。消息应用程序的 用户界面还包括在一个实施方案中呈现会话或聊天中的其他用户的名字的 用户名203。消息应用程序的用户界面还包括类似于文本输入区域18A和 文本输入区域155的文本输入区域211。插件(或扩展应用程序)包括画布 215以及各种控件和选项，用户可选择这些控件和选项以绘制或创建图像。 在一个实施方案中，如果素描选项217被选择，则绘图控件212可允许用 户选择不同的颜色在画布上进行素描。如果轻击选项221被选择，则插件 (或扩展应用程序)还可提供轻击作为消息。如果心跳选项219被选择， 则插件(或扩展应用程序)还可提供心跳。在一个实施方案中，素描、心 跳和轻击类似于Apple Watch上可用的Digital Touch应用程序中的素描、心 跳和轻击。插件(或扩展应用程序)还包括扩展视图图标223，该扩展视图 图标223被选择时将使得插件(或扩展应用程序)从图5A所示的其当前的 紧凑视图切换成扩展视图诸如图7B所示的扩展视图。在图5A所示的示例 中，用户刚启动插件图像创建应用程序(或在另一个实施方案中，刚启动 扩展应用程序)并且尚未创建任何内容。这与图5B所示的插件(或扩展应 用程序)的状态形成对比，在图5B所示的插件(或扩展应用程序)中，用 户已使用素描选项217或通过用户手指在画布215绘图创建了笑脸略图。 然后用户可将该图画发送至作为消息的接收人的其他用户(或多个用 户)。因此，例如设备200的用户可从通信设备200上执行的即时消息应 用程序内选择发送命令，以使得由插件(或扩展应用程序)所创建的内容 被发送至接收人。发送操作的结果如图5C所示，其中笑脸被发送至Freddy，如用户名203所指示的那样。消息气泡230示出由插件(或扩展应 用程序)创建的笑脸略图；就扩展应用程序而言，该创建的内容通过IPC 框架从扩展应用程序发送至即时消息应用程序，并且然后呈现在消息气泡 230内，以表示包含该内容的消息被传输至一个或多个接收人。在一个实施 方案中，递送指示符231可指示消息已被递送并且可向用户提供保持控件 232，以允许用户在其中在一段时间之后自动清除内容的那些实施方案中保 留消息记录中的内容。

图5D、图5E和图5F示出响应于接收到如图5C所示的来自通信设备 200的内容而在接收者的设备上发生的情况。另外，图6所示的流程图可示 出在接收设备上执行的方法，该接收设备诸如图5D、图5E和图5F所示的 通信设备250。现在参见图5D，可看到通信设备250(由Freddy使用)已 接收到在消息气泡253中示出的笑脸内容。该内容由在通信设备200上执 行的扩展应用程序创建，该通信设备200将笑脸内容提供至正在通信设备 200上执行的即时消息应用程序，其继而通过消息服务(例如，一组消息服 务器，诸如图2所示的消息服务器51)来将该内容传输至正在通信设备 250上执行的即时消息应用程序，该通信设备250继而将该内容呈现在消息 气泡253中。在一个实施方案中，在该内容使用标准格式(在一个实施方 案中，包括标准图像、音频和视频格式)时，即时消息应用程序可再现该 内容，并且因此扩展应用程序无需安装或执行以便显示由发送设备上的对 应(远程)扩展应用程序创建的内容。因此，在图5D所示的情况下，即使 通信设备250上的对应扩展应用程序未被启动或甚至未被安装，消息气泡 253也可呈现内容。图5D所示的即时消息应用程序在其用户界面中包括消 息记录201A、文本输入区域211和屏幕键盘255。在一个实施方案中，从 远程扩展应用程序接收的内容将不使得接收设备上的对应扩展应用程序自 动启动，即使该对应扩展应用程序已被安装。在该实施方案中，接收设备 上的对应扩展应用程序可通过对包含由远程扩展应用程序创建的内容的消 息气泡的用户选择来启动。如果用户未通过例如触摸或以其他方式选择消 息气泡253来选择该内容，则与远程扩展应用程序对应的扩展应用程序在 被安装在通信设备250上的情况下被启动。在图5E所示的结果中，扩展应 用程序的用户界面已占据其中之前显示屏幕键盘255的空间并且在画布215 内示出笑脸图画，从而允许通信设备250的用户改变或其他方式修改该素 描并且可将其发送回到聊天会话或对话中的其他用户。换句话讲，如果对 应扩展应用程序未被安装在通信设备上，则在一个实施方案中，即时消息 应用程序可向用户发出用于询问或提供安装针对已选择的特定消息气泡的 应用程序的通知。这种情况的一个示例如图5F所示，其中通知259包括两 个用户可选择的选项，其中一个选项将安装消息气泡的所需的应用程序。 在另一个实施方案中，示出来自扩展应用程序市场的信息页的工作表可被 显示在即时消息应用程序的视图内。

在一个实施方案中，从远程设备传输至通信设备250的消息包含用于 指定用于创建内容的远程扩展应用程序的元数据。在一个实施方案中，该 元数据可为应用程序标识符，诸如由从中可下载和安装扩展应用程序的应 用程序市场或扩展应用程序市场所提供的标识符，或者可为与由应用程序 市场所使用的标识符相关联的不同标识符。在一个实施方案中，通知259 可由对消息气泡253的选择而得到，而在另一个实施方案中，如果在通信设备250接收到消息气泡253的内容时该内容的元数据中的应用程序标识 符被未安装，则该通知259可自动得到。

图6现在将结合图5D、图5E和图5F进行参考，以解释一个实施方案 中的方法，在该方法中，接收设备处理由远程扩展应用程序创建的内容， 该远程扩展应用程序诸如在通信设备200上的与即时消息应用程序一起执 行的远程扩展应用程序。在操作301中，通信设备可接收具有由扩展应用 程序创建的内容的消息，该扩展应用程序诸如发送设备上的与即时消息应 用程序一起操作的远程扩展应用程序。此外，通信设备还可接收元数据， 该元数据可包括消息气泡标识符、会话标识符和扩展应用程序标识符以及 可能的其他数据，诸如任选的资源定位符以及可与该任选的资源定位符相 关联的其他数据(状态信息)，并且资源定位符还可包括被编码到资源定 位符中的状态信息。相对于使用资源定位符以及与资源定位符相关联的数 据的更多信息将结合图8、图9A和图9B来提供。然后在操作303中，已在操作301中接收到消息的通信设备处理内容并且将该内容显示在消息气 泡中，该消息气泡由消息气泡标识符来识别，并且该消息气泡被显示在消 息记录内。在一个实施方案中，对内容的处理可包括对内容进行解密并再 现内容，以被呈现和显示在消息气泡内。在一个实施方案中，内容由即时 消息应用程序显示，而无需借助于扩展应用程序；换句话讲，扩展应用程 序可未被安装在通信设备上或在被安装时可不执行，并且因此在一个实施 方案中显示屏幕键盘。然后在操作305中，通信设备接收对显示由远程扩 展应用程序创建的内容的消息气泡的选择。在一个实施方案中，参见图 5D，用户可轻击触摸屏上的消息气泡或以其他方式选择(例如，用户使用 触摸屏上的触笔或将鼠标与台式计算机一起使用等)消息气泡253，以使得 在操作305中进行选择。响应于操作305，通信设备诸如通信设备250在操作307中确定扩展应用程序是否已被安装。在一个实施方案中，这可通过 检查由即时消息应用程序保持的已安装的扩展应用程序的列表或注册信息 来执行。在一个实施方案中，在操作301中接收的元数据包括应用程序标 识符，并且在操作307中，即时消息应用程序搜索列表，以确定标识符是 否存在于列表中。如果标识符不存在于列表中，则即时消息应用程序确定 该扩展应用程序未被安装，从而使得通信设备执行操作309，在该操作中可 向用户显示如图5F所示的通知259以提供对由应用程序标识符所指定的应 用程序的下载和安装，该应用程序标识符在操作301中作为元数据的一部 分而被接收。如果用户选择选项“是”，则执行操作311，其中即时消息应 用程序使得通信设备访问应用程序市场(诸如具有如图14B所示的用户界 面的扩展应用程序市场)，以通过下载来检索扩展应用程序的副本并使得 该扩展应用程序将被安装。在一个实施方案中，可完全在后台中执行操作 311，使得即时消息应用程序在下载和安装进程中保留前台应用程序。图 9C示出在下载和安装进程中保持在消息记录中的消息气泡471的示例，其 中消息气泡包括指示下载和安装操作的进度的进度条473，而即时消息应用 程序保留显示即时消息应用程序的消息记录中的消息气泡471的前台应用 程序。在操作311的另一个实施方案中，示出来自扩展应用程序市场的信息页面的工作表可被显示在即时消息应用程序上方(任选地仍然显示即时 消息应用程序的一部分)，并且该工作表可示出“购买”或安装或下载按 钮，在在选择相应按钮后，可导致对扩展应用程序的下载和安装，并且可 通过选择取消命令或通过选择购买或安装或下载来取消(从显示屏上移 除)该工作表。在下载和安装扩展应用程序之后，可继续进行图6中所示 的操作313，在该操作中启动扩展应用程序并且通过即时消息应用程序来将 由远程扩展应用程序使用或创建的内容及其他数据传送(经由IPC)至扩展 应用程序，并且在一个实施方案中，扩展应用程序被显示在紧凑视图或扩 展视图中，并且由远程扩展应用程序创建的内容被显示在该视图内。如图6 所示，如果操作307确定扩展应用程序已被安装，则在操作307之后还将 执行操作313。图5E示出操作313的结果的一个示例。

在一个实施方案中，即时消息应用程序可根据扩展应用程序的类型通 过不同方式来启动不同类型的扩展应用程序。例如，响应于接收到包含来 自具有特定预先确定类型的扩展应用程序的内容的消息气泡，可自动启动 一种类型的扩展应用程序。在一个实施方案中，具有不同类型的其他扩展 应用程序可仅响应于对包含来自该扩展应用程序的内容的消息气泡的选择 或对表示可浏览视图诸如可浏览视图571中的扩展应用程序的图标的选择 而被启动。可能希望允许具有特定类型的特定扩展应用程序响应于接收到 被显示在消息记录内的内容而被自动启动，同时不自动启动其他类型的扩 展应用程序。在另一个另选的实施方案中，可允许一个或多个扩展应用程 序在后台中执行并且可允许更新其被呈现在其相应的消息气泡中的相应的 用户界面，并且当用户选择这些消息气泡中的一个消息气泡时，扩展应用 程序出现在前台中(例如，显示其UI，以替代屏幕键盘)。

在另选的实施方案中，元数据可包括可用于确定可处理接收设备上的 那种图像格式的可用扩展应用程序的格式或扩展标识符，诸如图像格式的 标识符。

图7A和图7B示出本文所述的实施方案的另一方面，其中扩展应用程 序可导致视图的改变，通过将通信发送至即时消息应用程序来导致该改 变。在一个实施方案中，扩展应用程序和即时消息应用程序之间可设置有 应用程序编程接口(API)，以允许扩展应用程序调用该API，从而在托管该 扩展应用程序的视图的即时消息应用程序内改变其视图。在一个实施方案 中，扩展应用程序可具有可包括紧凑视图和扩展视图的至少两种不同的视图。在一个实施方案中，在消息记录保持被显示在即时消息应用程序的用 户界面中时，紧凑视图可为选择替代即时消息应用程序的屏幕键盘的视 图。在扩展视图中，不再显示消息记录，并且不显示屏幕键盘，但是显示 即时消息应用程序的用户界面的特定的其他部件，诸如文本输入区域211 和相机激活图标235。图7B示出其中画布215A占据触摸屏的大部分空间 的扩展视图的示例。如图7B所示，用户可选择紧凑视图图标223A，以使 得该系统从图7B所示的扩展视图改变回到紧凑视图，诸如图5A所示的视 图。

图7A中所示的方法为视图可如何改变的一个实施方案，并且应当理 解，在另选的实施方案中，可按不同顺序来执行操作的序列，并且可存在 省略步骤或居间步骤或附加步骤。

在图7A的操作351中，可通过具有特定视图或风格的即时消息应用程 序来显示扩展应用程序。在操作353中，扩展应用程序可调用即时消息应 用程序，以获取扩展应用程序的当前呈现视图/风格。在操作357中，即时 消息应用程序可针对来自操作353的调用来提供返回结果，并且该返回结 果可指示扩展应用程序的当前呈现视图/风格。响应于在操作357中接收到 的当前展示，扩展应用程序可通过提供即时消息应用程序对调用以使得改变发生来请求呈现视图/风格的改变，并且在操作361中接收该调用。在一 个实施方案中，即时消息应用程序可利用该视图正在改变或将要改变的确 认来初始对该调用进行响应。在操作363中，响应于调用，即时消息应用 程序改变呈现风格/视图并且将扩展应用程序显示在所请求的视图呈现视图/ 风格内，并且在操作365中，即时消息应用程序通知扩展应用程序视图的 改变已完成。重新参见图7B，如果用户选择紧凑视图图标223A，则将引 起从扩展应用程序到即时消息应用程序的调用，以改变扩展应用程序在即 时消息应用程序的用户界面内的视图。

现在将相对于本文所述的实施方案的另一方面来描述图8、图9A、图 9B和图9C。在该实施方案的一个方面，扩展应用程序以及另一设备上的对 应扩展应用程序可参与通信会话并且在其通信会话中前后交换信息，并且 所有这些操作在由两个即时消息应用程序保持的消息记录的上下文中发 生，该两个即时消息应用程序在两个扩展应用程序之间进行交互，如图8 所示。在一个实施方案中，即时消息应用程序的插件还可按照类似的方式操作，并且通过处于会话中的两个即时消息应用程序在插件之间交换信 息。图8所示的消息系统400包括至少两个客户端设备，即客户端设备401 和客户端设备405，并且还包括一组一个或多个消息服务器403。客户端设 备401和405类似于图2中的客户端设备53和54，并且一组一个或多个消 息服务器403可类似于图2中的一组消息服务器51。每个客户端设备可包 括特定扩展应用程序(诸如例如，在餐厅处进行预订的扩展应用程序)的 已安装的副本，并且每个设备上的扩展应用程序可用于创建内容(例如， 文本、图像、音频、视频等)，并且该内容通过进程间通信框架而被传送 至设备上的即时消息应用程序以用于特定消息，该特定消息可被称为特定 客户端设备上的消息记录中的消息气泡。消息应用程序接收内容(并且任 选地从扩展应用程序接收其他数据，包括例如扩展应用程序的标识符、资 源定位符以及任选地由其他设备上的对应或远程扩展应用程序使用的元数 据等)并且显示可显示的内容(诸如消息记录中的消息气泡中的由扩展应 用程序提供的餐厅的图像，该扩展应用程序为餐厅预订应用程序诸如 “Open Table”)。实际上，即时消息应用程序托管即时消息应用程序内的 视图，并且该视图的内容由扩展应用程序提供。在一个实施方案中，资源 定位符和元数据对于即时消息应用程序是不透明的(例如，无法由即时消 息应用程序识别)，但是可由每个设备上的扩展应用程序使用以保持扩展 应用程序之间的会话的状态信息，并且通过在扩展应用程序之间传送资源 定位符和元数据，每个设备上的即时消息应用程序用作扩展应用程序之间 的通信机制。在一个实施方案中，关于会话的状态信息可在资源定位符中 编码、或者可在元数据中提供、或者两者兼有。在一个实施方案中，从每 个设备上的会话创建的内容被显示在消息记录中相同单个消息气泡内(通 过可由即时消息应用程序保持的会话标识符来所识别)，并且每次内容改 变时(基于设备的改变)，更新的内容继续被显示在消息记录中的单个消 息气泡内，并且显示会话中的内容的任何之前的消息气泡可被转换为面包 屑，并且这些之前的消息气泡还将包括与最新消息气泡相同的会话标识 符。现在将同时参见图9A来描述图8所示的部件的操作和功能，图9A示 出在一个实施方案中操作消息系统400的方法。

在图9A的操作451中，扩展应用程序诸如扩展应用程序407可创建内 容并且生成资源定位符和数据(或可修改现有内容、资源定位符或数 据)。扩展应用程序可类似于扩展应用程序83，并且在一个实施方案中在 一个进程中执行，同时可类似于即时消息应用程序76的即时消息应用程序 在另一个进程中执行，并且通过IPC(诸如IPC 81)发生进程之间的通 信，其可为用于提供两个不同进程之间的进程间通信的软件框架或库。扩 展应用程序407可为例如通过网站来创建预订的餐厅预订应用程序，该网 站可提供与资源定位符一起使用的状态信息(或状态信息可被编码到资源 定位符中)。在一个实施方案中，具有资源定位符的数据可为从网站提供 的状态信息，并且该状态信息可包括有关特定餐厅和预定时间以及预订人 数的信息。扩展应用程序407可在紧凑视图或扩展视图中呈现用于通过网站来进行餐厅预订的用户界面，同时显示即时消息应用程序的其余部分， 包括例如消息记录。因此，扩展应用程序407的用户可看到消息记录中的 会话的上下文，同时与扩展应用程序和网站进行交互(通过扩展应用程 序)，以创建餐厅预订。在一个实施方案中，用户能够浏览各个餐厅(在 餐厅预订应用程序内)并且搜索餐厅。在扩展应用程序407的用户已选择餐厅并且输入预订之后，扩展应用程序407可通过IPC 415来将内容以及图 8所示的资源定位符和数据417传送至设备401上的即时消息应用程序。该 进程如图9A中的操作453所示。在操作455中，即时消息应用程序409使 从扩展应用程序407接收的内容与消息气泡相关联并且将消息记录的气泡 中的内容显示在即时消息应用程序409的用户界面中。然后在操作457 中，响应于从用户接收的发送命令，即时消息应用程序409通过一个或多 个消息服务器403来将消息(如果有的话)和从扩展应用程序407接收的 内容、以及识别应用程序407的应用程序标识符(以及任选的应用程序407 的图标)以及资源定位符和数据(如果有的话)和会话标识符发送至第二 设备，该一个或多个消息服务器403将通信419传送至第二设备405(也被 称为客户端设备405)。在一个实施方案中，操作453和455可响应于即时 消息应用程序接收到对发送命令的选择而作为操作457的一部分发生。应 用程序407的图标可被显示在接收设备的消息气泡上，即使对应扩展应用 程序未被安装时也是如此；参见例如图3B中的图标87。在图9A所示的操 作459中，客户端设备405上的即时消息应用程序411从一个或多个消息 服务器403接收内容并且将所识别的消息气泡421中的内容显示在由即时消息应用程序411的用户界面提供的消息记录内。图9B示出在一个实施方 案中的此类消息气泡471的更详细的示例，该消息气泡471具有由餐厅预 订扩展应用程序所创建的内容。在图9B所示的示例中，内容包括餐厅名 称、预订时间、和预订人数。在一个实施方案中，该内容可由即时消息应 用程序显示，而无需启动扩展应用程序413。在一个实施方案中，扩展应用 程序413未被启动，直到客户端设备405的用户选择消息气泡421从而向 客户端设备指示客户端设备405的用户旨在与消息气泡421中的内容进行 交互。在另选的实施方案中，扩展应用程序413可在由即时消息应用程序 411接收到内容时启动，但是保持在后台中，并且在客户端设备405的用户 输入命令以使得扩展应用程序出现时准备好执行。在操作461中，由通信 419中提供的应用程序标识符所识别的扩展应用程序413启动，如果尚未准 备好启动，则响应于地消息气泡421的选择，即时消息应用程序411通过 IPC 423来将与消息气泡421相关联的内容以及资源定位符和数据425传送 至即时消息应用程序413。在一个实施方案中，扩展应用程序413为对应扩 展应用程序，其与扩展应用程序407是相同的扩展应用程序，而在另一个 实施方案中，它们仅仅是兼容的，因为它们可处理相同类型的内容。

此处，扩展应用程序413可接收客户端设备405的用户的用户输入， 并且可修改内容、资源定位符或数据中的一者或多者。例如，客户端设备 405的用户可使得扩展应用程序413访问一个或多个网站以通过修改时间、 人数、特定餐厅等来进行经修改的餐厅预订。在一个实施方案中，扩展应 用程序413以及扩展应用程序407还可通过将资源定位符和数据发送至网 络服务器并且从网络服务器接收可能包括经修改的数据或经修改的资源定 位符或新数据和/或新资源定位符等的响应来与网络服务器直接交互(但是 单独且独立地)。在一个实施方案中，网络服务器可存储会话期间使用的 数据，并且该所存储的数据可包括用于同样可由会话中的两个扩展应用程 序保持的一部分或全部状态信息的信息。同样，如果呈现的扩展应用程序 413被显示在紧凑视图中，则设备405的用户可与扩展应用程序413交互一 进行餐厅预订，同时聊天或消息会话的上下文和对话被显示在即时消息应 用程序411的消息记录中。客户端设备405的用户可浏览消息记录，同时 继续查看并且与扩展应用程序413进行交互。因此，扩展应用程序413可 在操作463中接收用户输入并且可修改内容、资源定位符或数据中的至少 一者，并且然后可在操作465中将资源定位符和数据427(其可为经修改的 或全新的)传送至即时消息应用程序411。继而，即时消息应用程序411在 操作467中可将内容(其可为经修改的)以及应用程序标识符和资源定位 符(其可为经修改的)和数据(其可以为经修改的)以及气泡ID发送回到 客户端设备401。如操作469所示，由于两个用户可在本文所提供的示例中 从事设置餐厅预订，因此该进程可随时间推移而重复。

应当理解，许多不同类型的扩展应用程序可提供客户端设备401和 405的用户之间的协同环境，以交换信息并且一起合作，并且该餐厅预订为 一种此类扩展应用程序。因此，应当理解，本文相对于图8和图9A所述的 餐厅预订示例仅仅为此类扩展应用程序的示例，其可在即时消息应用程序 的用户界面的上下文中提供协同环境。可提供类似协同环境的其他类型的 扩展应用程序的示例包括例如：贴纸扩展应用程序；成像应用程序；绘图 应用程序；内容创建应用程序；游戏；音乐创建应用程序；内容消费应用 程序；投票应用程序；地图应用程序等。

在一个或多个实施方案中，如图8所示并且相对于图9A所述的协同环 境可利用面包屑，并且面包屑中的每个面包屑可由会话标识符识别。面包 屑表示被转换的消息气泡并且由会话标识符识别，该会话标识符在会话中 与其他消息气泡共享。在一个实施方案中，由相同会话标识符识别为新消 息气泡的每个之前的消息气泡可被转换为面包屑，该面包屑可与消息记录 所示的原始内容以不同的方式被显示。在一个实施方案中，随着会话中的每个新消息气泡到达或被添加至消息记录中，由相同会话标识符识别的之 前的消息气泡可被转换为面包屑，并且示于消息记录中，如图9D、图 9E、图9F、图9G和图9H所示。图9D和图9H示出Joe的设备上的消息 记录510，并且图9E、图9F和图9G示出Lester的设备上的消息记录17。 消息记录510示出Lester的用户名511，并且消息记录517示出Joe的用户 名518。在图9D、图9E、图9F、图9G和图9H所示的示例中，Lester和 Joe参与文本消息会话并且各自使用扩展应用程序，诸如图像创建应用程序 或其他扩展应用程序。例如，Lester可使用图8所示的扩展应用程序407， 并且Joe可使用图8所示的扩展应用程序413。Lester的设备可使用即时消 息应用程序409，而Joe的设备可使用即时消息应用程序411。重新参见图 9D，可看到消息记录510包括指示消息记录510内的会话的内容的消息气 泡512和消息气泡513。此外，Joe已使用扩展应用程序413来创建被追加 至消息气泡514中的内容515。例如，Joe可已输入作为文本消息的文本并 且还使用扩展应用程序413来创建内容，并且然后使得两种文本均被显示 在消息气泡514内，并且内容515(在一个实施方案中，其与消息气泡514 相关联或作为消息气泡514的一部分)被发送至Lester的设备。消息记录 510的右侧示出由Joe发送的消息，而消息记录510的左侧示出从Lester接 收的消息。现在参见图9E，可看到消息气泡513现在处于消息记录517的 右侧，同时消息气泡514和内容515处于Lester的设备上的消息记录517的 左侧。因此，Lester的设备已接收到消息气泡514内的文本消息，并且还接 收到由Joe的设备上的扩展应用程序所生成的内容515。然后，Lester可轻 击内容515以使得Lester的设备上的相应的或对应的扩展应用程序启动。 内容515与由Lester的设备上的扩展应用程序保持的会话标识符相关联。 例如，在一个实施方案中，在该进程中，作为用户选择内容515的结果， 此时如图9A所示的操作461可在Lester的设备上执行，该内容515可被显 示在消息气泡中。然后，Lester可使用Lester的设备上的扩展应用程序来创 建经修改的内容或新内容并且将该经修改的内容或新内容发送回到Joe。在 图9F中，可看到Lester已创建了被显示在暂存区域519内的经修改的内容 或新内容521，该暂存区域591响应于由用户进行的对发送命令的选择而示 出准备好发送并且将进行发送的文本以及其他内容，该发送命令诸如图9F 所示的发送按钮523。当Lester选择具有在暂存区域519中所示的内容的发 送命令时，这使得文本消息520以及新的或经修改的内容521被发送至 Joe，并且可从图9G中看出，其中消息气泡520A在消息记录517的右侧示 出文本消息520，其还示出内容521(在一个实施方案，该内容中与消息气 泡520A相关联或作为消息气泡520A的一部分)，该内容521由Lester使 用Lester的设备上的扩展应用程序407而被修改或创建为新内容。

可从图9G中看到，现在内容515已被转换为面包屑515A。在一个实 施方案中，这种转变可由即时消息应用程序执行或另选地由扩展应用程序 执行。在一个实施方案中，扩展应用程序可提供出现在面包屑515A内的文 本，并且即时消息应用程序将使用会话标识符来识别来将被转换为面包屑 的一个或多个消息气泡，并且在一个实施方案中，这将使得内容515被转 换为面包屑515A并且将面包屑显示在相关联的消息气泡514旁边，而无需 将该消息气泡514文本消息转换为面包屑。因此，图9G示出与之前的消息 气泡或由扩展应用程序创建的内容相关联的会话标识符如何能够用于在发 送设备上将之前的一个或多个消息气泡转换为面包屑。图9H示出在一个实 施方案中该转换在接收设备上如何被显示。在图9H所示的图中，消息气泡 520A与来自Lester的设备的扩展应用程序403的新内容或经修改的内容一 起示于消息记录510的左侧。Joe的设备上的内容515已被转换为消息记录 的右侧的面包屑515A并且被显示为与消息气泡514相邻，在内容515最初 被发送时，面包屑515A伴随该内容515。

如果在操作459中，接收设备诸如客户端设备405能够进行安装并且 使用扩展应用程序(由在通信419中提供的应用程序标识符所识别)，但 是该扩展应用程序未被安装在接收设备上，接收设备可在即时消息应用程 序的用户界面内提供下载和安装扩展应用程序(同样由接收设备上的通信 419中的应用程序标识符指定)。图9C示出一个示例，其中来自扩展应用 程序407的内容可被显示在消息气泡471的客户端设备405上，并且客户 端设备405处于下载和安装由通信419中的应用程序标识符所识别的扩展 应用程序的进程中。在图9C所示的示例中，在安装该扩展应用程序413 时，内容被显示在消息气泡471内。在一个实施方案中，在安装进程期 间，进度条473(或另选的进度圆环)可被显示在消息气泡471内。在一个 实施方案中，可在后台执行下载和安装进程，同时即时消息应用程序保持 前台应用程序。如果接收设备无法安装或使用扩展应用程序，则在一个实 施方案中，资源定位符和元数据可被传送至接收设备上的网络浏览器，并 且该网络浏览器可成为前台应用程序并且允许用户与资源定位符所指的网 页进行交互。

在一些实施方案中，期望将每个用户的标识符提供至在客户端设备上 执行的每个扩展应用程序，特别是在协同环境的情况下，其中两个或更多 个用户通过即时消息应用程序和扩展应用程序进行交互。图10示出提供每 个扩展应用程序的标识符而不影响用户隐私损失的方法的示例。如图10所 示的方法可通过每个客户端设备上的每个即时消息应用程序来执行。在一 个实施方案中，可响应于来自扩展应用程序的对应用程序编程接口(API)的 调用而执行该方法，该方法允许扩展应用程序请求本地用户的标识符。在 一个实施方案中，标识符可为本地用户的电子邮件地址、或电话号、码或 由消息系统使用的其他标识符。在一个实施方案中，被提供至扩展应用程 序的标识符为通过图10所示的方法创建的模糊标识符。在操作501中，即 时消息应用程序可响应于来自扩展应用程序的调用而生成特定扩展应用程 序的盐值。在一个实施方案中，盐值可为与该特定扩展应用程序相关联的 随机数字。然后，在操作503中，即时消息应用程序可生成用户或设备标 识符与盐值的组合的散列(诸如SHA-1散列)。例如，用户标识符可为用 户的电话号码或电子邮件地址，并且该电话号码或电子邮件地址与盐值组 合，并且然后在操作503中创建该组合的散列。然后在操作505中，通过 IPC来将散列提供至扩展应用程序，并且散列值可与资源定位符一起用作数 据，并且然后该资源定位符可被发送至其他扩展应用程序，以识别已改变 或创建该内容的用户。在另一个实施方案中，即时消息应用程序可通过保 持标识符与针对每个扩展应用程序的随机生成的唯一标识符的映射来使标 识符模糊化。换句话讲，对于给定的扩展应用程序，即时消息应用程序可 为扩展应用程序生成随机(并且唯一的)标识符，并且使该随机标识符关 联到(例如，映射到)用户的标识符(例如，本地用户的电子邮件地址、 或电话号码、或由消息系统使用的其他标识符)。给定扩展应用程序的这 一随机标记符可被提供至扩展应用程序，但是标识符不被提供至扩展应用 程序。另一个扩展应用程序将接收到不同的随机生成的标识符。然后，该 特定扩展应用程序标识符可被提供至另一设备上的对应扩展应用程序，使 得这两个扩展应用程序可在会话或其他协同环境的上下文中追踪执行具体 动作的用户。

在一个实施方案中，本文所述的消息系统可确认一个或多个扩展应用 程序接收到消息，并且这在某些情况下可为有用的，在这些情况下需要扩 展应用程序确保远程扩展应用程序与本地扩展应用程序具有相同的已知状 态。图11示出用于提供对接收的确认的方法的示例。在操作551中，即时 消息应用程序从用户接收“发送”命令并且对本地扩展应用程序将内容提 供至即时消息应用程序进行响应。继而，在操作553中，即时消息应用程序通过一个或多个消息服务器来将消息和消息气泡标识符以及内容和资源 定位符(如果有的话)发送至同样包括消息应用程序的接收设备。在某一 时刻，本地设备上的即时消息应用程序在操作555中接收对接收到消息以 及内容和任选的资源定位符的确认，并且然后在操作557中，通过ICP来 将对接收的确认传送至本地扩展应用程序，使得在扩展应用程序提供其内 容以用于传输至远程扩展应用程序时，本地扩展应用程序认识到远程扩展 应用程序具有相同的已知状态。

图12示出本文所述的实施方案的另一方面，并且该方面涉及将多个消 息气泡呈现在消息记录内，其中不同的消息气泡具有由不同扩展应用程序 创建的内容，并且消息气泡中的至少一个消息气泡可在即时消息应用程序 的用户界面的消息记录同样被显示时被执行(并且具有其被显示在紧凑视 图中的内容)。图12示出此类方面的一个示例。该实施方案中的通信设备 600包括显示包括两个消息气泡605和607的消息记录603的触摸屏601。此外，即时消息应用程序呈现扩展应用程序的紧凑视图609，其在这种情况 下为用于餐厅预订的扩展应用程序。在图12所示的示例中，用于餐厅预订 的扩展应用程序已用于发送显示餐厅预订内容的消息，如消息气泡607所 描绘的。这可作为接收到来自另一个用户的消息的结果而发生，该另一个 用户使用提供来自另一个扩展应用程序的餐厅评论的内容的另一个通信设 备。在图12所示的示例中，消息气泡605示出由远程扩展应用程序创建的 内容，该远程扩展应用程序提供不同于用于进行餐厅预订的扩展应用程序 的餐厅评论。在一个实施方案中，两种扩展应用程序均在作为消息会话或 聊天的一部分的通信设备上执行。

本文所述的实施方案的另一方面涉及向后兼容性，并且该方面如图 13A和图13B所示。某些旧设备可能与本文所述的扩展应用程序架构不兼 容，或者可能不使用该架构或甚至可能并非智能手机。在一个实施方案 中，发送消息的客户端设备能够自动或基于确定接收设备与扩展应用程序 不兼容而提供另选内容。一种提供向后兼容性的方法如图13A所示。在操 作651中，发送设备上的扩展应用程序创建发送设备(第一设备)上的内 容，以用于通过即时消息应用程序和消息服务而被递送至第二设备。这一 操作与图9A所示的操作451类似。在操作651中创建的内容然后可在操作 653中响应于即时消息应用程序接收到用户的“发送”选择通过进程间通信 而被传送至即时消息应用程序。然后，在操作655中，即时消息应用程序 可显示第一设备上的内容并且还确定第二设备与扩展应用程序不兼容。在一个实施方案中，这可作为接收到来自一个或多个消息服务器的关于接收 设备(第二设备)的信息的结果而被确定，该一个或多个消息服务器诸如 图2所示的一个或多个消息服务器51可保持有关每个设备的状态的信息， 诸如设备的操作系统的版本或设备的类型等。作为确定第二设备与扩展应 用程序不兼容的结果，即时消息应用程序可在操作657中将另选内容发送 至第二设备，并且图13B提供了该另选内容的示例。

图13B所示的通信设备675可为例如使用与本文所述的扩展应用程序 不兼容的旧操作系统的旧智能手机。然而，通信设备675包括供即时消息 应用程序的功能的触摸屏679以及文本输入区域683和屏幕键盘685提， 该即时消息应用程序还显示包括消息气泡687的消息记录681。消息气泡 687包含由远程设备上的发送消息应用程序提供的另选内容。在这种情况 下，该内容包括可由用户选择以使得显示资源定位符691所指的网页的图 像689和资源定位符691。换句话讲，资源定位符691可由用户选择以调用 通信设备675上的web浏览器，以允许通信设备675的用户通过web浏览 器与网页进行交互，该网页在某些情况下可与扩展应用程序具有与网站进 行交互的相同的作用。

本文所述的实施方案的另一方面涉及一种服务，诸如根据本文所述的 一个或多个实施方案的可提供多个不同扩展应用程序以用于即时消息应用 程序内的应用程序市场。该服务或应用程序市场可呈现多个不同扩展应用 程序和即时消息应用程序插件的可浏览视图，并且提供将那些扩展应用程 序下载至客户端设备以允许客户端设备安装一个或多个扩展应用程序。图 14A示出使用此类服务或应用程序市场的方法的示例，并且图14B示出消 息扩展应用程序市场的用户界面的示例。在一个实施方案中，图14B所示 的应用程序市场可从客户端设备上的即时消息应用程序的用户界面内的已 安装的扩展应用程序的可浏览视图中进行调用。例如，选择图4B所示的图 标167可使得呈现图14B所示的消息应用程序市场。然后，用户可浏览一 个或多个消息扩展应用程序的集合并且选择可能免费或可购买的一个或多 个扩展应用程序。在图14B所示的示例中，消息扩展应用程序市场725可包括一个或多个消息扩展应用程序的导航栏729和可浏览视图，该一个或 多个消息扩展应用程序诸如被显示在触摸屏727上的应用程序726,728和 731。在一个实施方案中，用户可通过在触摸屏上轻扫用户的手指或使用导 航栏729来浏览应用程序。然后，用户可选择下载和安装扩展应用程序中 的一个或多个扩展应用程序，并且由此，用户的客户端设备上的即时消息 应用程序可将表示新安装的扩展应用程序的图标添加至已安装的扩展应用 程序的可浏览视图中，诸如图4B所示的可浏览视图157。此外，即时消息 应用程序可将已安装的扩展应用程序与由应用程序市场提供的应用程序的 标识符(“应用程序标识符”)一起添加至已安装的扩展应用程序的列表 中。虽然用户使用如图14B所示的应用程序市场是安装扩展应用程序的一 种方式，但是另一种方式如图14A所示，其中安装进程作为与即时消息应 用程序的消息记录中的消息的用户交互的结果而开始。

现在参见图14A，操作701中的即时消息应用程序可接收由远程设备 诸如第一设备上的扩展应用程序创建的内容(以及任选的资源定位符和数 据)，并且还可接收远程设备上扩展应用程序的应用程序标识符。在一个 实施方案中，当扩展应用程序被安装在第一设备上时，应用程序标识符可 为由应用程序市场提供的相同的标识符，或者可为与应用程序商店的标识 符相关联的不同的标识符。然后在操作703中，第二设备上的即时消息应 用程序可将内容显示在消息气泡中，并且如果提供的话，保持资源定位符 和数据。此时，在该实施方案中，即时消息应用程序不试图启动扩展应用 程序，该扩展应用程序实际上此时并未被安装在第二设备上。然后在操作 705中，即时消息应用程序接收对包含由第一设备的扩展应用程序提供的内 容的消息气泡的选择诸如轻击，并且即时消息应用程序确定扩展应用程序 (如所接收到应用程序标识符所识别)未被安装在第二设备上。此时，如 图14A的操作707所示，即时消息应用程序提供对第二设备上的扩展应用 程序的下载和安装并且用户可选择安装在操作701中由应用程序标识符所 识别的扩展应用程序。在一些情况下，用户在下载和安装扩展应用程序之 前可能需要购买该扩展应用程序。提供下载和安装可呈现在通知中，诸如 图5F所示的通知259，并且该通知可包括可选择的选项，以导致对用于所选择的消息气泡的扩展应用程序的下载和安装。然后在操作709中，第二 设备下载和安装扩展应用程序并且可启动新安装的扩展应用程序。在一个 实施方案中，下载和安装可发生在后台中，同时即时消息应用程序保持在 前台中。在一个实施方案中，下载和安装的进度可在进度条中示出，该进 度条诸如在所选择的消息气泡内所示的进度条473。在操作709完成之后， 然后新安装的扩展应用程序可用于第二设备上，并且即时消息应用程序在 操作711中可在由即时消息应用程序托管的视图内将内容以及任选的资源 定位符和数据提供至第二设备上的扩展应用程序。

在一个实施方案中，即时消息应用程序可使得已安装的扩展应用程序 自动更新。在另一个实施方案中，即时消息应用程序可向用户提供特定扩 展应用程序需要更新的警示或通知，并且在一个实施方案中，有关这些更 新的通知可从扩展应用程序市场接收。这样可使用户选择性地决定是否更 新特定的即时消息应用程序。

本文所述的实施方案的另一方面涉及贴纸扩展应用程序，并且图15、 图16A、图16B和图16C示出这一方面的示例。贴纸扩展应用程序为作为 即时消息应用程序诸如图3A所示的即时消息应用程序76的扩展应用程序 来运行的应用程序，并且将与即时消息应用程序的消息记录中的消息气泡 相关联的图像提供至即时消息应用程序。在一个实施方案中，贴纸应用程 序可购自或以其他方式得自消息扩展应用程序商店(例如，参见图 14B)，并且购买的贴纸应用程序可包括一组贴纸。在一个实施方案中，图 像的文件大小受约束，以小于预先确定的数据量。在一个实施方案中，用 户可使用即时消息应用程序的视图内的贴纸扩展应用程序来创建图像，并 且然后将该图像从消息应用程序中的贴纸扩展应用程序的视图拖动到由即 时消息应用程序提供的记录中的消息气泡上。在一个实施方案中，将图像 拖动到消息气泡上之后，用户还可缩放(例如，放大或缩小)和旋转所选 择的消息气泡上的贴纸图像。在一个实施方案中，用户还可将贴纸应用至 已暂存以将被发送但是尚未被发送的消息气泡。在一个实施方案中，发送 设备将加密的图像文件发送至消息服务器并且接收下载令牌(以及相关联 的生存时间(TTL)值)，其中该令牌表示加密的图像文件。如本文所述，在 一个实施方案中，图像文件基于每个发送者进行加密，并且因此消息服务 器可存储各自采用不同发送设备的不同密钥进行加密并且各自具有生存时 间值的相同贴纸的多个实例，该生存时间值在适当的发送设备将下载令牌 (之前得自服务器)发送至用于后续消息的服务器时被刷新。在一个实施 方案中，贴纸可为动画。

在发送设备首先将可被加密的贴纸图像发送至一个或多个消息服务器 时，其接收到下载令牌和生存时间值。图15所示的消息系统800可类似于 图2所示的消息系统50。具体地，该一组消息服务器801可类似于消息服 务器51，并且发送设备803和接收设备805可类似于客户端设备53和客户 端设备54。此外，在一个实施方案中，发送设备803和接收设备805可使 用图3A所示的架构，其中即时消息应用程序76通过图3A所示的IPC与独 立的扩展应用程序一起操作。当发送设备803首先将贴纸图像(其可被加 密)与消息(其可被加密)一起发送811至一组一个或多个消息服务器801 时，发送设备803接收812下载令牌和TTL值，该TTL值指示加密的贴纸 图像何时被安排成在消息服务器801和发送设备803两者上截止(同 时)。如果发送设备803将消息中的贴纸(相同贴纸)再次发送819至相 同或不同的接收设备，同时TTL值尚未截止，则发送设备803不再上传贴 纸图像，而是将下载令牌发送819至还使得服务器801的生存时间值被刷 新(同时使得被存储在发送设备803中的TTL值被刷新)的一个或多个消 息服务器801。如果生存时间值截止，则发送设备803将再次上传加密贴纸 图像(其可采用不同的密钥进行加密)并且将从一个或多个消息服务器801 接收另一下载令牌。该一组一个或多个服务器801可保持针对每个加密贴 纸具有对应的令牌和对应的生存时间值的加密贴纸的数据库802。具体地， 加密贴纸1可具有如数据库802的行821中所示的令牌1的对应的令牌值、 以及TTL1的对应的生存时间值。相似地，加密贴纸图像在其数据库802中 的行823中可具有加密贴纸的副本2、以及行823中的对应的令牌2和 TTL2。在另选的实施方案中，贴纸1和贴纸2可为相同贴纸图像的加密图 像，但是针对不同的接收者(但是来自相同的发送设备)并且采用不同的 密钥进行加密，并且因此单独被存储在数据库的单独的行中。虽然本文相 对于图15所述的实施方案使用贴纸的TTL值，但是应当理解，从即时消息 应用程序发送的其他对象也以相同的方式使用TTL值，但是这些其他对象 可包括图像、文档、可执行文件(例如，游戏)等。

图16A示出根据一个实施方案的一种方法，其中发送设备803与一组 一个或多个消息服务器801进行交互。在操作851中，贴纸扩展应用程序 创建贴纸图像以及图像的散列，并且可接收用户输入以确定图像元数据， 诸如比例元数据和旋转元数据。在一个实施方案中，贴纸图像的创建可仅 涉及选择特定的贴纸图像，诸如来自图16C所示的可浏览贴纸视图835的 贴纸图像841，并且将所选择的贴纸诸如贴纸841拖动到消息上，该消息诸 如可由通信设备831发送的消息气泡839(或消息记录或文本暂存区域中的 任何其他消息气泡)。相似地，消息气泡839上的花朵贴纸的创建可仅涉 及将贴纸843从可浏览贴纸视图835中拖动至消息气泡839(或消息记录或 文本暂存区域中的任何其他消息气泡)上，并且执行任何图像操作诸如缩 放或旋转，同时花朵处于消息气泡839上。重新参见图16A，在操作851中，即时消息应用程序接收用于来自贴纸应用程序的特定消息气泡上的位 置贴纸图像和图像元数据(例如，旋转元数据和缩放元数据)、以及位置 元数据，并且使气泡标识符(其可被识别为特定的消息气泡)和贴纸扩展 应用程序标识符与贴纸图像相关联。然后在操作853中，发送设备上的即 时消息应用程序将加密消息(如果有的话)和加密贴纸图像以及用于递送 至接收设备的元数据上传至一个或多个消息服务器。该上传进程如图15中 的发送811所示。然后，在操作855中，发送设备(诸如发送设备803)从 一个或多个消息服务器801接收下载令牌，并且存储该令牌以及对应的加 密贴纸图像的相关联的TTL值。该进程如图15中的接收812所示。在图 16A的操作857中，发送设备还可任选地接收对接收到消息的确认。然 后，在将相同的图像贴纸后续发送至相同的接收设备或其他接收设备(在 一个实施方案中)的操作859中，发送设备803可将用于递送的贴纸图像 的相关联的令牌发送819至相同的接收设备或其他接收设备(在一个实施 方案中)，只要TTL值尚未截止即可。在一个实施方案中，发送令牌可刷 新消息服务器和发送设备803两者处的TTL值。因此，该一个或多个消息 服务器在接收到第二次发送以及后续发送的令牌时将刷新数据库802内的 对应的生存时间值。换句话讲，如果生存时间值已截止，则发送设备803 将再次上传加密贴纸图像的另一个副本，并且从一个或多个消息服务器801 接收新的下载令牌和新的生存时间值。

图16B所示的方法可由接收设备805来执行。在操作875中，接收设 备可接收加密消息以及下载令牌和对应的元数据，并且该进程如图15中的 接收813所示。在一个实施方案中，元数据可包括由远程贴纸扩展应用程 序创建的散列以及贴纸扩展应用程序标识符，并且还包括气泡标识符和用 于指示所识别的消息气泡上的位置的位置元数据、以及缩放元数据和旋转 元数据，该缩放元数据和旋转元数据由设备805上的即时消息应用程序用于对贴纸进行定位以及缩放和旋转。在操作877中，即时消息应用程序根 据操作875中所接收的散列来确定接收设备是否具有被存储在接收设备上 的贴纸图像的本地副本。如果这样，则在操作877之后继续执行操作881， 使得该处理跳至如图16B所示的操作891。如果不存在本地副本，则在操 作877之后继续执行操作879，并且在操作879中，接收设备805在图15 所示的发送815中将下载令牌发送至一个或多个消息服务器801，以检索加 密贴纸图像，并且然后在操作879中，即时消息应用程序对加密贴纸图像 进行解密。然后在操作891中，接收设备使用图像元数据来生成可包括图 像的一种或多种旋转以及放大或缩小(或图像的其他修改)的最终贴纸图 像；在一个实施方案中，接收设备上的即时消息应用程序执行操作891。然 后在操作893中，即时消息应用程序可将最终贴纸图像显示在消息记录中的气泡上(显示在由气泡标识符所识别的气泡上)。图16C示出一个示 例，其中用户已创建两个贴纸图像并且将它们放置在消息气泡839上。

在一个实施方案中，贴纸扩展应用程序可提供用户界面，该用户界面 允许一个或多个用户从贴纸部件库中的贴纸的部件或部分组装贴纸，以便 创建包括来自库的所选择的部件或部分的最终贴纸；该库可由贴纸扩展应 用程序提供。贴纸扩展应用程序可通过“向导”引导用户创建最终贴纸， 该向导引导用户完成创建最终贴纸所涉及的各个阶段。此类贴纸扩展应用 程序的一个示例描述于2016年6月12日提交的美国临时专利申请号 62/349,091的附录II中。

图15所示的示例是将贴纸分发或发送至接收设备的一个实施方案，并 且现在将描述两个另选的实施方案。在第一另选的实施方案中，当贴纸扩 展应用程序的开发者将扩展应用程序及其资源和资产(诸如贴纸图像)上 传至分发机构/服务诸如在线应用程序商店时，该分发机构/服务可提取资产 并且将它们存储在基于云端的存储系统(例如，支持iCloud存储的一个或 多个服务器)中，并且为每个贴纸图像提供唯一的标识符(诸如，全局唯 一标识符(GUID))，并且使GUID与对应的贴纸图像相关联。分发机构/服 务还可通过贴纸扩展应用程序来存储唯一的标识符(例如，作为包括贴纸 扩展应用程序的套装的一部分)，使得发送设备(例如，设备803)可利用 用于被包括在应用程序内的贴纸图像的唯一标识符来安装贴纸扩展应用程 序。当发送设备利用由贴纸扩展应用程序创建的贴纸来发送消息时，发送 设备上的即时消息应用程序将贴纸的唯一标识符发送至接收设备上的即时消息应用程序。然后，接收设备上的即时消息应用程序通过将唯一标识符 发送至基于云端的存储系统来检索贴纸图像(如果非本地被存储在接收设 备上)，该基于云端的存储系统通过将所识别的贴纸图像发送至接收设备 进行响应。

第二另选的实施方案支持可由用户(其使用图像创建或捕获应用程序 来生成新贴纸)生成的新贴纸，并且第二另选的实施方案还可使用在接收 设备请求贴纸时使用贴纸图像的标识符(例如，贴纸图像的散列)来检索 贴纸图像的基于云端的存储服务。当发送设备(例如，发送设备803)发送 贴纸时，其可检查本地存储装置以用于之前发送至一组一个或多个消息服 务器的贴纸的列表并且检查贴纸之前是否已被发送，发送设备将贴纸的标识符发送至接收设备。标识符可为贴纸图像的散列诸如SHA-1散列或MD1 散列，并且该标识符将取决于贴纸图像的内容，并且在几乎所有情况下均 为贴纸图像的可靠且唯一的标识符。在从发送设备接收到的标识符之后， 接收设备可使用标识符来检索来自使用该标识符的基于云端的存储服务的 贴纸，在一个实施方案中，该标识符作为密钥以查找数据库中的贴纸图 像，并且然后基于云端的存储服务来将所检索的贴纸图像发送至接收设 备。在其检查之前发送的贴纸的本地存储时，如果发送设备确定贴纸图像 之前尚未由发送设备的即时消息应用程序发送，则即时消息应用程序可将 贴纸图像发送至基于云端的存储服务(直接发送或通过一个或多个消息服 务器发送，该消息服务器可创建贴纸图像的散列(标识符)并且两者均被 存储在基于云端的存储服务中；发送设备还将标识符(例如，贴纸图像的 散列)发送至接收设备，该接收设备可使用标识符从基于云端的存储服务 检索贴纸图像)。

在一些实施方案中，可使用一个或多个应用程序编程接口(API)。 API是由程序代码部件或硬件部件(在下文中被称为“API实现部件”)实 现的接口，其允许不同的程序代码部件或硬件部件(在下文中被称为“API 调用部件”)访问和使用由API实现部件提供的一个或多个函数、方法、 流程、数据结构、类别、和/或其他服务。API可定义在API调用部件和API实现部件之间传送的一个或多个参数。

API允许API调用部件的开发者(可以是第三方开发者)利用由API 实现部件提供的指定特征。可存在一个API调用部件或可存在多于一个此 类部件。API可以是计算机系统或程序库提供的源代码接口，以便支持对 来自应用程序的服务的请求。操作系统(OS)可具有多个API，以允许运 行于OS上的应用程序调用那些API中的一个或多个API，并且服务(诸如 程序库)可具有多个API，以允许使用服务的应用程序调用那些API中的 一个或多个API。可按照在构建应用程序时可被解译或编译的编程语言来 指定API。

在一些实施方案中，API实现部件可提供各自提供由API实现部件实 现的功能的不同视图或提供用于访问由API实现部件实现的功能的不同方 面的多于一个API。例如，API实现部件的一个API可提供第一组功能，并 可暴露于第三方开发者，并且API实现部件的另一个API可被隐藏(不暴 露)并提供第一组功能的子组，并且还提供另一组功能，诸如不在第一组 功能中的测试或调试功能。在其他实施方案中，API实现部件本身可经由 下层API来调用一个或多个其他部件，并且因此既是API调用部件又是 API实现部件。

API定义在访问和使用API实现部件的指定特征时API调用部件所使 用的语言和参数。例如，API调用部件通过由API暴露的一个或多个API 调用或引用(例如由函数或方法调用来实现)来访问API实现部件的指定 特征，并经由API调用或引用使用参数来传送数据和控制信息。API实现 部件可响应于来自API调用部件的API调用而通过API返回值。尽管API 定义API调用的语法和结果(例如，如何引用API调用以及API调用可进 行什么操作)，但API可不揭示API调用如何完成由API调用指定的函 数。经由调用(API调用部件)和API实现部件之间的一个或多个应用程 序编程接口来传输各种API调用。传输API调用可包括发出、发起、引 用、调用、接收、返回或响应函数调用或消息；换句话讲，传输可通过 API调用部件或API实现部件来描述动作。API的函数调用或其他引用可通 过参数列表或其他结构来发送或接收一个或多个参数。参数可以是常数、 键、数据结构、对象、对象类别、变量、数据类型、指针、数组、列表或 指向函数或方法或援引要经由API传送的数据或其他项目的另一种方式的 指针。

此外，数据类型或类别可由API提供并由API实现部件实现。因此， API调用部件可通过使用在API中提供的定义来声明变量、使用指向这种 类型或类别的指针、使用或实例化这种类型或类别的恒定值。

通常，可使用API来访问由API实现部件提供的服务或数据、或启动 对由API实现部件提供的操作或计算的执行。以举例的方式，API实现部 件和API调用部件各自可以是操作系统、库、设备驱动程序、API、应用程 序或其他模块(应当理解，API实现部件和API调用部件可以是彼此相同 或不同类型的模块)中的任一者。在一些情况下，可至少部分地在固件、 微码或其他硬件逻辑部件中实现该API实现部件。在一些实施方案中，API 可允许客户端程序(例如，游戏中心应用程序)使用由软件开发工具包 (SDK)库提供的服务。在其他示例中，应用程序或其他客户端程序可使用由 应用程序框架提供的API。在这些示例中，应用程序或客户端程序可将调 用并入由SDK提供并且由API提供的函数或方法，或使用在SDK中定义 并由API提供的数据类型或对象。在这些示例中，应用程序框架可以为程 序提供主要事件循环，该程序对由框架定义的各种事件进行响应。API允 许应用程序使用应用程序框架来指定事件并对事件进行响应。在一些具体 实施中，API调用可向应用程序报告硬件设备的能力或状态，包括与方面 诸如输入能力和状态、输出能力和状态、处理能力、电源状态、存储容量 和状态、通信能力相关的那些能力或状态，并且API可部分地由固件、微 码或部分地在硬件部件上执行的其他低电平逻辑部件来实现。

API调用部件可以是经由网络通过API来与API实现部件进行通信的 本地部件(即在与API实现部件相同的数据处理系统上)或远程部件(即 在与API实现部件不同的数据处理系统上)。应当理解，API实现部件也 可充当API调用部件(即，其可对由不同API实现部件暴露的API进行 API调用)，并且API调用部件也可通过实现暴露于不同API调用部件的 API来充当API实现部件。

API可允许以不同编程语言编写的多个API调用部件与API实现部件 进行通信(从而API可包括用于转换API实现部件和API调用部件之间调 用和返回的特征)；然而，API可从具体编程语言方面实现。在一种嵌入 中，API调用部件可调用来自不同提供商的API，诸如来自OS提供商的一 组API和来自插件提供商的另一组API，以及来自另一提供商(例如软件 库的提供商)或另一组API的创建者的另一组API。

图17是示出可用于本发明的一个实施方案中的示例性API架构的框 图。如图17中所示，API架构3200包括实现API 3220的API实现部件3210(例如，操作系统、库、设备驱动程序、API、应用程序、软件或其他 模块)。API 3220指定可由API调用部件3230使用的API实现部件的一个 或多个函数、方法、类别、对象、协议、数据结构、格式和/或其他特征。 API3220可指定至少一个调用约定，该至少一个调用约定指定API实现部 件中的函数如何从API调用部件接收参数以及函数如何向API调用部件返 回结果。API调用部件3230(例如，操作系统、库、设备驱动程序、API、 应用程序、软件或其他模块)通过API 3220进行API调用，以访问并使用 由API 3220指定的API实现部件3210的特征。API实现部件3210可响应 于API调用而通过API 3220来向API调用部件3230返回值。

应当理解，API实现部件3210可包括未通过API 3220指定并且对于 API调用部件3230不可用的附加函数、方法、类别、数据结构、和/或其他 特征。应当理解，API调用部件3230可与API实现部件3210位于同一系统 上，或者可远程定位API实现部件3210并经由网络使用API 3220来访问 该API实现部件3210。尽管图17示出了单个API调用部件3230与API3220进行交互，但应当理解，可以不同语言(或相同语言)编写的与API 调用部件3230不同的其他API调用部件可使用API 3220。

API实现部件3210、API 3220和API调用部件3230可被存储在包括用 于以机器(例如，计算机或其他数据处理系统)可读形式存储信息的任何 机构的机器可读介质(例如，计算机可读介质)中。例如，机器可读介质 包括磁盘、光盘、随机存取存储器、只读存储器、闪存存储器设备等。

在图18(“软件栈”)中，在本发明的一个实施方案中，应用程序可 使用若干服务API来调用服务A或B，并且使用若干个OS API来调用操作 系统(OS)。服务A和B可使用若干个OS API来调用OS。

注意，服务2具有两个API，其中一个API(服务2API 1)从应用程 序1接收调用并返回值，另一个API(服务2API 2)从应用程序2接收调 用并返回值。服务1(例如，可以是软件库)调用OS API 1并接收返回 值，并且服务2(例如，可以是软件库)调用OS API 1和OS API2两者并 接收返回值。应用程序2调用OS API 2并接收返回值。

本文所述的系统和方法可在包括通用计算机系统、专用计算机系统、 或通用和专用计算机系统的混合系统我各种不同的数据处理系统和设备中 实现。可使用本文所述的方法中的任一种方法的示例性数据处理系统包括 台式计算机、膝上型计算机、平板电脑、智能手机、蜂窝电话、个人数字 助理(PDA)、嵌入式电子设备、或消费电子设备。

图19为根据一个实施方案的数据处理系统硬件的框图。需注意，虽然 图19示出了可结合到移动设备或手持式设备中的数据处理系统的各种部 件，但是其并不旨在表示使这些部件互连的任何特定构造或方式，因此此 类细节与本发明并无密切关系。还应理解，也可将具有比图19所示更少或 更多部件的其他类型的数据处理系统与本发明一起使用。

如图19中所示，数据处理系统包括用于将系统的各种部件互连的一个 或多个总线1309。如本领域中所熟知的，一个或多个处理器1303耦接至一 个或多个总线1309。存储器1305可为DRAM或非易失性RAM，或者可为 闪存存储器、或其他类型的存储器、或此类存储设备的组合。该存储器使 用本领域已知的技术而被耦接至一个或多个总线1309。数据处理系统还可 包括非易失性存储器1307，该非易失性存储器可为硬盘驱动器、或闪存存 储器、或磁性光盘驱动器、或磁性存储器、或光盘驱动器，或甚至在系统 断电之后仍保持数据的其他类型的存储器系统。非易失性存储器1307和存 储器1305均使用已知的接口以及连接技术而被耦接至一个或多个总线 1309。显示控制器1322耦接到一个或多个总线1309，以接收将要在显示设 备1323上显示的显示数据。显示设备1323可包括用于提供触摸屏的集成式触摸输入。数据处理系统还可包括为一个或多个I/O设备提供接口的一个 或多个输入/输出(I/O)控制器1315，该一个或多个I/O设备诸如一个或多个 鼠标、触摸屏、触摸板、操纵杆和其他输入设备(包括本领域已知的那些 I/O设备)，以及输出设备(例如，扬声器)。如本领域中所公知，输入/ 输出设备1317通过一个或多个I/O控制器1315而被耦接。

虽然图19示出了非易失性存储器1307和存储器1305直接地而不是通 过网络接口耦接至一个或多个总线，但应当理解，本发明可利用远离系统 的非易失性存储器，诸如通过网络接口诸如调制解调器或以太网接口而被 耦接至数据处理系统的网络存储设备。如本领域所熟知的，总线1309可通 过各种网桥、控制器和/或适配器彼此连接。在一个实施方案中，I/O控制 器1315包括用于控制USB外围设备的USB(通用串行总线)适配器、用 于IEEE1394兼容性外围设备的IEEE 1394控制器、或用于控制 Thunderbolt外围设备的Thunderbolt控制器中的一者或多者。在一个实施方 案中，一个或多个网络设备1325可被耦接到一个或多个总线1309。网络设 备1325可为有线网络设备(例如，以太网)或无线网络设备(例如，WI- FI、蓝牙)。

通过本描述将显而易见的是，本发明的各方面可至少部分地在软件中 体现。即，该技术可响应于其处理器执行被包含在存储介质诸如非暂态机 器可读存储介质(例如，DRAM或闪存存储器)中的一系列指令而在数据 处理系统中执行。在各种示例中，可将硬连线的电路与软件指令结合使用 来实施本发明。因此，该技术不限于硬件电路系统与软件的任何特定组 合，或不限于由数据处理系统执行的指令的任何特定源。此外，应当理 解，在描述移动设备或手持式设备时，本说明书涵盖移动设备(例如，膝 上型设备、平台设备)、手持式设备(例如，智能手机)、以及适用于可 穿戴电子设备中的嵌入式系统。

本公开认识到在本发明技术中使用个人信息数据可用于使用户受益。 例如，该个人信息数据可用于递送用户较感兴趣的信息或目标内容。因 此，使用此类个人信息数据可使得能够对所递送的内容进行有计划的控 制。另外，本公开还设想到有益于用户的个人信息数据的其他用途。

本公开还设想到负责此类个人信息数据的收集、分析、公开、传输、 存储或其他用途的实体将遵守已确立的隐私政策和/或隐私实践。具体地， 此类实体应当实行并坚持使用被公认为满足或超出用于保持个人信息数据 的隐私性和安全性的行业或政府要求的隐私政策和实践。例如，来自用户 的个人信息应当被收集用于实体的合法且合理的用途，并且不在这些合法 使用之外共享或出售。另外，此类收集应当仅在用户知情同意之后进行。另外，此类实体应采取任何所需的步骤，以用于保障和保护对此类个人信 息数据的访问，并且确保能够访问个人信息数据的其他人遵守他们的隐私 政策和程序。另外，此类实体可使其本身经受第三方评估，以证明其遵守 广泛接受的隐私政策和实践。

不管前述情况如何，本公开还预期用户选择性地阻止使用或访问个人 信息数据的实施方案。即本公开预期可提供硬件元件和/或软件元件，以防 止或阻止对此类个人信息数据的访问。例如，就健康信息或广告递送服务 而言，本发明的技术可被配置为在注册服务期间允许用户选择“加入”或 “退出”参与对个人信息数据的收集。又如，用户可选择不为目标内容递 送服务提供位置信息。再如，用户可选择不提供精确的位置信息，但准许 传输位置区域信息。

在前述说明书中，已描述了特定示例性实施方案。显而易见的是，可 在不脱离以下权利要求所示的更广泛的实质和范围的情况下对那些实施方 案作出各种修改。因此，说明书和附图应被认为是出于例示性目的而非限 制目的。

下列附录描述了用于使用Apple Inc.(Cupertino,California)的iOS操作 系统的iOS设备的应用程序编程接口的示例。该API用于在本文所述的扩 展应用程序和iOS设备上的即时消息应用程序之间进行交互。

对用于扩展应用程序的iMessage API的变化的汇总

·对所限定类型中的一些类型进行重命名，将一些协议改变为某类 别，并且反之亦然。受影响的类型为：

ο将MSMessageContext转变为类别并将其重命名为 MSConversation。该名称更准确地描述了该类别所表示的内 容。

ο将MSMessagePayload重命名为MSMessage。该新名称更好地 描述了该类别，因为该对象表示比将被发送的消息有效载荷的 更多的内容。

ο将MSBalloonLayout重命名为MSMessageLayout。该字词气球 用于描述当前UI，其不应被载入API中。

ο将MSBalloonTemplateLayout重命名为 MSMessageTemplateLayout。

ο将MSMessageTemplateLayout转变成协议并且添加具有相同名 称的类别以实现该协议。采用API的开发者在无法创建用于实 现MSBalloonLayout协议其自身的对象时发生混淆。该改变将 允许开发者提供其自身的MSMessageTemplateLayout贴合对 象。

ο将MSSticker协议转变成类别。贴纸类似于UIImage的概念， 因此也应当是具体类别。MSSticker和MSStickerView之间的 关系应当类似于UIImage和UIImageView之间的关系。

·新增功能：

ο新增MSSession类别。A利用会话初始化的MSMessages可参 与“面包屑”行为。即，在会话中与相同会话创建的所有消息 将更新会话记录中的单个气球，并且任选地在记录中留下面包 屑条目的痕迹。在该提议之前，该行为通过修改由 MSMessageContext提供的输入消息并且将经修改的对象传送 至-updateMessagePayload:completionHandler:来实现。

ο添加MSConversationDelegate协议，该协议定义了 MSConversation委托的委托接口。当用户轻击发送按钮，同时 MSMessage已暂存用于发送并且在用户从输入字段中删除暂 存的MSMessage时，该委托将接收回调。如果来自该扩展应 用程序类型的新消息到达会话，同时扩展应用程序活动时，该 委托将接收回调。

ο添加有关NSExtensionContext的类别，其允许扩展应用程序获 取有关如何展示的信息并且请求修改呈现风格。这使得扩展应 用程序请求展开或收缩呈现并且请求将其完全取消。

ο利用在UIApplicationDelegate中模式化的一组回调来替代MSMessagePayloadProvider上的回调。

ο将-updateMessagePayload:completionHandler:重命名为- insertMessage:localizedChangeDescription:completionHandler:字 词更新似乎造成混淆，因为该方法将在不存在暂存的 MSMessage以用于进行发送时插入新消息。这样还将添加允 许开发者提供面包屑文本的localizedChangeDescription参数。

添加用于替代MSBalloonLayout.h的MSMessageLayout.h