软件平台到设备生态系统的自动配设

摘要

一种用于将平台实现包自动配设到客户端设备的方法可包括从在客户端设备上执行的应用接收对功能的请求。可经由与应用一起配送的客户端库来接收该请求，并且该请求可针对由平台实现包提供的功能。平台实现包可提供客户端库不提供的功能。还可由客户端设备自动判定该功能要求对平台实现包的更新。作为响应，对于对平台实现包的更新的请求可被传达到计算系统。可从计算系统接收对平台实现包的更新，并且可在客户端设备上安装对平台实现包的更新。可由更新后的平台实现包向应用提供所请求的功能。

说明书

相关申请的交叉引用

本申请要求2012年11月8日递交的美国专利申请第13/672,005号和 2012年6月26日递交的美国临时申请第61/664,670号的优先权，特此通过 引用并入这些申请的每一个的内容。

技术领域

本申请的各方面概括而言涉及数据处理领域。更具体而言，本公开的某 些实现方式涉及软件平台到设备生态系统的自动配设(automatic provisioning  of a software platform to a device ecosystem)。

背景技术

随着移动设备的越来越普及，在运行不同的软件平台版本的这种移动设 备的多样集合上创建无缝的应用开发者和用户交互，常常是有挑战性的。例 如，如果开发者在设备软件平台本身中包括开发者应用编程接口(application  programming interface，API)，则开发者体验因具有不同API和能力的每个平 台版本而碎片化。例如，移动设备软件平台的较旧版本可利用一种处理认证 令牌的方法，而该软件平台的后续版本可使用不同的方法。在此，每个应用 开发者于是必须多次实现由给定API处理的特定特征以覆盖在不同软件平台 下工作的可用设备的宽广度。

此外，如果开发者API被包括在与应用捆绑的客户端库中，则那些客户 端库可在单个移动设备上的不同版本级别运行，从而创建了碎片化的用户体 验，因为相同的特征将被在不同客户端库版本下运行的不同API所覆盖。例 如，一视频播放器可被包括作为安装在移动设备上的应用A和B内部的客户 端库。然而，应用A可具有实现该视频播放器的较旧版本的客户端库的旧版 本，该视频播放器的较旧版本与应用B中使用的更新近的客户端库所实现的 视频播放器的较新版本相比具有略微不同的用户界面。

本领域技术人员通过将常规和传统方案与本公开的余下部分参照附图记 载的本方法和装置的一些方面相比较，将清楚常规和传统方案的更多限制和 缺点。

发明内容

提供了一种基本上如附图中的至少一幅所示和/或如联系附图中的至少 一幅所描述的、如权利要求中更完整记载的用于软件平台到设备生态系统的 自动配设的系统和/或方法。

根据本公开的示例实施例，一种用于将平台实现包自动配设到客户端设 备的方法可包括在客户端设备处从在客户端设备上执行的应用接收对功能的 请求。可经由与应用一起配送的客户端驻留客户端库来接收该请求。该请求 可针对由平台实现包提供的功能。平台实现包可提供客户端库不提供的功能。 客户端设备可自动判定该功能要求平台实现包的安装或者对平台实现包的更 新。

响应于该判定，对于对平台实现包的更新的请求可被传达到计算系统。 客户端设备可从计算系统接收对平台实现包的更新。可在客户端设备上安装 对平台实现包的更新。更新后的平台实现包可向应用提供所请求的功能。可 在客户端设备初始执行应用时传达对功能的请求。可在客户端设备初始执行 应用之后传达对功能的请求。自动判定可包括判定平台实现包过时，判定在 客户端设备中未安装平台实现包，或者判定平台实现包被禁用。

判定平台实现包过时可包括通过将客户端库的版本与平台实现包的版本 相比较来执行版本依从性检查(version dependency check)。在传达之前，客 户端设备可通过在客户端库中调用用于对话界面的显示的方法来显示对话界 面，用于接收对于对更新的请求的用户确认。对客户端库的更新可与对平台 实现包的更新一起从计算系统接收。可利用进程间通信(inter-process  communication，IPC)经由客户端库来接收请求。向计算系统传达对于对平 台实现包的更新的请求可被推迟，直到对于在客户端设备上执行的至少一个 另外的应用要求至少一个另外的更新为止。

根据本公开的另一示例实施例，一种用于将平台实现包自动配设到客户 端设备的方法可包括在客户端设备处从在客户端设备上执行的应用接收对功 能的请求。可经由与应用一起配送的客户端驻留客户端库来接收该请求。该 请求可针对由平台实现包提供的功能。客户端设备可判定执行功能的平台实 现包是否要求更新。如果平台实现包要求更新，则可向计算系统传达对于更 新平台实现包的请求。如果平台实现包要求更新，则可禁用客户端设备内的 该功能。

如果在客户端设备上执行的应用不要求该功能，则禁用可发生。如果功 能不要求更新，则可利用在客户端设备上安装的平台实现包来执行该功能。 客户端库可不提供由平台实现包提供的功能。客户端库可以是瘦客户端库。

根据本公开的另一示例实施例，一种用于将平台实现包自动配设到客户 端设备的方法可包括从执行带有客户端库的应用的客户端设备接收对于对平 台实现包的更新的请求。响应于该请求，向客户端设备传达对平台实现包的 更新。平台实现包可操作来执行与客户端库相关联的至少一个功能。平台实 现包可配送到执行带有客户端库的相应应用的至少多个其他客户端设备。

向客户端设备传达对平台实现包的更新可在从客户端设备接收到请求时 自动发生。在没有来自应用或者来自客户端设备的用户的任何通信的情况下， 可将平台实现包的更新推送到客户端设备。更新的推送可按预定的时间间隔 自动发生。

通过以下描述和附图将更充分理解本公开的这些和其他优点、方面和新 颖特征以及所例示的其(一个或多个)实现方式的细节。

附图说明

图1是根据本公开的实施例图示出多部分(multi-part)API的框图。

图2A是根据本公开的实施例图示出软件平台到设备生态系统的自动配 设的框图。

图2B是根据本公开的另一实施例图示出软件平台到设备生态系统的自 动配设的框图。

图3是根据本公开的实施例图示出软件更新到设备生态系统的自动配设 的框图。

图4是根据本公开的实施例图示出用于软件平台到客户端设备的自动配 设的方法的示例步骤的流程图。

图5是根据本公开的实施例图示出用于软件平台到客户端设备的自动配 设的另一方法的示例步骤的流程图。

图6是根据本公开的实施例图示出用于软件平台到设备生态系统的自动 配设的方法的示例步骤的流程图。

具体实施方式

本公开涉及用于软件平台到设备生态系统的自动配设的方法和系统。在 各种实现方式中，可通过实现多部分应用编程接口(API)并且将该多部分 API的至少一部分自动配设到设备生态系统内的设备来进一步改善应用开发 者、用户和配设网络之间的交互。更具体而言，给定API的功能可被分成至 少两个群组——接口功能(这些功能不太可能随着时间而变化)，以及实现功 能(这些功能可能是动态的并随着时间而变化，从而要求后续的更新)。接口 功能可实现在客户端库中，该客户端库可被开发者使用来在设备应用中实现。 实现功能可实现在服务应用(或者平台实现包)中，该服务应用在整个设备 生态系统中可被自动配设和自动更新。在此，通过分离平台实现包中的实现 功能并且在整个设备生态系统中自动对其更新，不需要由于API或者操作软 件的更新而发布新的应用。

例如，一种用于将平台实现包自动配设到客户端设备的方法可包括在客 户端设备处从在客户端设备上执行的应用接收对功能的请求。该请求可经由 与应用一起配送的客户端驻留客户端库来接收。该请求可以是针对由平台实 现包提供的功能的，客户端库不提供该功能。可由客户端设备进一步自动确 定该功能要求安装平台实现包或者对平台实现包的更新。响应于该确定，对 于对平台实现包的更新的请求可被传达到计算系统。可从计算系统接收对平 台实现包的更新。可在客户端设备上安装对平台实现包的更新。可由更新后 的平台实现包向该应用提供所请求的功能。

当在本文中使用时，术语“电路”指的是物理电子组件(即硬件)以及 可配置该硬件、由该硬件执行和/或以其他方式与该硬件相关联的任何软件和 /或固件(“代码”)。当在本文中使用时，“和/或”指的是由“和/或”连接的 列表中的项目中的任何一个或多个。作为示例，“x和/或y”指的是三元素集 合{(x),(y),(x,y)}中的任何元素。作为另一示例，“x、y和/或z”指的是七元 素集合{(x),(y),(z),(x,y),(x,z),(y,z),(x,y,z)}中的任何元素。当在本文中使 用时，术语“块”和“模块”指的是可由一个或多个电路执行的功能。当在 本文中使用时，术语“例如”引出一个或多个非限制性示例、实例或例示的 列表。

图1是根据本公开的实施例图示出多部分API的框图。参考图1，示出 了应用编程接口(API)102。API 102可包括可操作来提供多个功能的适当 代码。例如，API 102可提供接口功能104和实现功能106。接口功能104可 包括可操作来提供到API 102的接口的适当代码(例如，开发者可使用接口 功能104来接口到API 102并且调用API 102)。实现功能106可包括可操作 来实现API 102的一个或多个特征的适当代码。

在本公开的示例实施例中，接口功能104和实现功能106可与API 102 分离。例如，接口功能104可实现在客户端库(client library，CL)108中。 例如，客户端库108可以是瘦客户端库。此外，实现功能106可实现在平台 实现包(platform implementation package，PIP)110中。PIP 110可以例如是 应用包(例如，应用包(.APK)文件)，其可被安装在客户端设备中并且可 用于实现应用所要求的给定功能。

图2A是根据本公开的实施例图示出软件平台到设备生态系统的自动配 设的框图。图2B是根据本公开的另一实施例图示出软件平台到设备生态系统 的自动配设的框图。参考图2A，示例软件配设环境200a可包括多个，即N 个客户端设备210,…,212、配设管理器202和开发者(developer)214。

配设管理器202可包括可操作来将应用编程接口(例如，图1中的API 102)的接口和实现功能分离到客户端库(例如，CL1 206)和相应的平台实 现包(例如，PIP1 208)中的适当逻辑、电路、接口和/或代码。配设管理器 202还可包括CPU 216和存储器218，在本文公开的配设功能中的一个或多个 期间可使用该CPU 216和存储器218。

开发者214可以是软件开发者，其在开发例如供客户端设备210,…,212 中的一个或多个使用的应用时可使用由配设管理器202提供的一个或多个 API。在示例实施例中，开发者214在应用A 204的开发期间可使用客户端库 206。更具体而言，开发者214可将客户端库206实现为应用A 204内的瘦客 户端库。在开发完成之后，开发者214可将应用A 204经由通信路径203c传 达到配设管理器202。

例如，配设管理器202可包括应用存储库，并且开发者可在这种应用存 储库中发布完成的应用A 204。配设管理器还可发布与客户端库(CL1)206 相对应的平台实现包(PIP1)208。配设管理器202可进一步将应用204(带 有客户端库206)与相应的平台实现包208一起经由通信路径203a,…,203b 配送(例如，经由下载)到多个客户端设备210,…,212中的一个或多个。例 如，应用204和平台实现包208的这种配送可发生在客户端设备210,…,212 中的一个或多个购买了应用206来下载时。

参考图2B，示例软件配设环境200b可与软件配设环境200a基本上相似， 差别在于应用204(带有客户端库206)可由设备210直接从开发者214下载。 例如，配设管理器202可以向多个客户端库206,…,207提供对开发者214的 访问，其中客户端库206,…,207对应于平台实现包208,…,209。客户端库206 (或者任何其他客户端库)可经由通信路径203f被传达到开发者214。完成 的应用204(带有客户端库206)可由设备210,…,212经由通信路径203e来 下载。相应的平台实现包208可由设备210,…,212从配设管理器202下载。

在设备210的示例操作期间，一旦应用204(带有客户端库206)和平台 实现包208被安装在设备210处，用户就可执行应用204。在应用204被执 行之后，客户端库206可用于向平台实现包208传达对于特定实现功能的请 求。这种对功能的请求可在启动应用204时立即被传达到平台实现包208， 或者在应用204运行期间的任何时间被传达到平台实现包208。此外，可以 因为应用204实际上对于其进程中的一个或多个需要该功能而在设备210内 发起对这种功能的请求。对功能的请求也可因为应用204在尝试验证相应的 平台实现包208被安装并且能够提供这种功能而被发起——如果应用要求这 样做的话。

在对功能的请求被传达到平台实现包208之后，可以判定平台实现包208 是否要求更新。例如，可以对照平台实现包208的版本检查客户端库206的 版本。如果平台实现包208是过时的(或者被禁用或者未被安装)，则可以断 定平台实现包208要求更新。响应于该判定，对更新的请求可被传达到配设 管理器202。配设管理器202可以向设备210发回所请求的更新，并且平台 实现包208可被更新。

图3是根据本公开的实施例图示出软件更新到设备生态系统的自动配设 的框图。参考图3，示例软件配设环境300可包括客户端设备304,…,306和 配设管理器302。图示的客户端设备304,…,306和配设管理器302可分别具 有与图2A-2B中的客户端设备210,…,212和配设管理器202的功能基本上相 似的功能。

在示例实施例中，配设管理器302可周期性地发布其提供的客户端库和 相应的平台实现包的更新。例如，配设管理器302可提供(例如，发布)对 平台实现包316的更新318。类似地，配设管理器302可提供(例如，发布) 对客户端库312的更新314。

在设备304的示例操作期间，在对功能的请求被传达到平台实现包316 之后，可以判定平台实现包316是否要求更新。在判定要求更新之后，对更 新的请求可被传达到配设管理器302。配设管理器302随后可经由通信路径 303b向设备304(和/或任何其他设备306)发回所请求的更新318。

在示例实施例中，配设管理器302也可配设对客户端库312的更新314。 这种更新314可被传达到设备304(和/或任何其余设备306)，使得任何设备 应用(例如，设备304中的应用320、322；设备306中的应用320和324) 使用的客户端库312可被更新到客户端库314。客户端库更新314可经由通 信路径303a来传达，并且其可以与对平台实现包316的更新318的传达同时 进行。在本公开的另一实施例中，客户端库更新314可与对平台实现包316 的更新分开进行。

在本公开的另一示例实施例中，平台实现包更新218可作为静默更新由 配设管理器302直接推送到设备304,…,306中的一个或多个。平台实现包更 新318到设备304,…,306中的一个或多个的推送可自动发生，无需来自设备 304,…,306的(一个或多个)用户或者在这种设备上运行的应用的任何动作 或通信。例如，平台实现包更新318可按规律的24小时周期被自动推送到设 备304,…,306中的一个或多个。

在另一示例实施例中，通信路径203a,…,203f,303a和303b可包括一个 或多个有线和/或无线通信链路。

此外，配设管理器302和/或示例软件配设环境300内的设备304,…,306 中的一个或多个对于平台实现包316的不同版本(例如，更新318)可使用 单独的二进制文件以便保持平台的最低限度足迹。更具体而言，配设管理器 302可在沿着功能线分解的多个二进制文件而不是单个二进制文件中将平台 (例如，平台实现包316)递送到示例软件配设环境300内的设备304,…,306 中的一个或多个。这可具有如下益处：允许存储受限环境中的增量式更新或 安装，以及通过让用户禁用个体组件(与个体二进制文件相关联)而不是禁 用所有功能(如果使用单个二进制文件的话)来限制对系统的损坏。

类似地，在本公开的另一示例实施例中，配设管理器302和/或示例软件 配设环境300内的设备304,…,306中的一个或多个也可对不同的运行时体系 结构、语言和屏幕密度使用针对性二进制文件，从而改善由平台实现包316 提供的服务的带宽和存储影响。更具体而言，配设管理器302可以为不同的 目标平台维护单独的构建(build)，以便节省存储空间和移动数据传送成本。 例如，原生代码可被编译到目标设备的特定体系结构。图像资源可针对特定 的设备显示密度(而不是在每种可能的密度中有一个)。字符串资源也可限于 设备支持的语言集合。在此，不同的二进制文件可用于不同的平台版本，不 同的平台版本可具有在较新的设备上包括的库或资产(并且在较旧的设备上 可不存在)。

图4是根据本公开的实施例图示出用于软件平台到客户端设备的自动配 设的方法的示例步骤的流程图。参考图2A—图4，示例方法400可开始于402， 此时在客户端设备处(例如204)从在客户端设备(例如210)上执行的应用 (例如204)接收对功能的请求。该请求可经由与应用204一起配送的客户 端库(例如206)来接收。该请求可以是针对由相应的平台实现包(例如208) 提供的功能的。平台实现包208可提供客户端库206不提供的功能。

在404，可自动判定该功能要求对平台实现包208的更新。在406，响应 于该判定，对于对平台实现包208的更新的请求可被传达到计算系统(例如 配设管理器202)。在408，可从计算系统(例如202)接收对平台实现包208 的更新(例如318)。在410，可在客户端设备(例如210)上安装对平台实 现包208的更新318。在412，可由更新后的平台实现包318在客户端设备 202内提供所请求的功能。

对功能的请求可在应用204的初始执行时(例如，作为初始执行步骤的 一部分)被传达到配设管理器202。对功能的请求也可在应用204的初始执 行之后传达(例如，在应用的初始步骤的执行之后，应用或客户端设备可判 定未安装应用204的某些额外功能)。自动判定可包括判定平台实现包208过 时；判定在客户端设备210中未安装平台实现包208；和/或判定平台实现包 208被禁用。判定平台实现包208过时可包括通过将客户端库206的版本与 平台实现包208的版本相比较来执行版本依从性检查。

在传达更新请求之前，可在设备210上显示对话界面，用于接收用户对 于更新请求的确认。在客户端库206中可调用一种方法来用于对话界面的显 示。可从计算系统将对客户端库的更新(例如314)与对平台实现包的更新 (例如318)一起接收。可利用进程间通信(IPC)经由客户端库(例如206) 接收请求。

在示例实施例中，向计算系统(例如202)传达对于对平台实现包208 的更新的请求可被推迟(或延迟)，直到对于在客户端设备210上执行的至少 一个另外的应用要求至少一个另外的更新为止。

图5是根据本公开的实施例图示出用于软件平台到客户端设备的自动配 设的另一方法的示例步骤的流程图。参考图2A—图5，示例方法500可开始 于502，此时可从在客户端设备(210)上执行的应用(例如204)接收对功 能的请求。可经由与应用204一起配送的客户端库(例如206)接收该请求， 并且该请求可以是针对由平台实现包(例如208)提供的功能的。在504，可 判定执行该功能的平台实现包208是否要求更新。

如果判定平台实现包208要求更新，则在508，可判定该功能是否实际 上是在客户端设备210上执行的应用(204)所要求的。如果该功能不是应用 (204)所要求的，则在510，可判定是否要禁用由平台实现包208执行的该 功能。如果判定该功能要被禁用，则在512，该功能被禁用并且该方法结束。 如果判定该功能不应当被禁用，则处理可在步骤514继续。

如果判定该功能实际上是应用(204)所要求的，则在514，可在客户端 设备处显示对话界面，用于接收用户对于对更新的请求的确认。该对话界面 可通过在客户端库中调用方法来显示。在接收到确认之后，对于对平台实现 包208的更新的请求可被传达到计算系统(例如配设管理器202)。

在516，可从计算系统(例如202)接收对平台实现包208的更新(例如 318)。在518，可在客户端设备(例如210)上安装对平台实现包208的更新 318。在520，可由更新后的平台实现包318在客户端设备202内提供所请求 的功能。

如果在504判定平台实现包208要求更新，则在506，可由平台实现包 208执行该功能。

图6是根据本公开的实施例图示出用于软件平台到设备生态系统的自动 配设的方法的示例步骤的流程图。参考图2A—图3和图6，示例方法600可 开始于602，此时可在配设管理器处(例如302)从执行带有客户端库(例如 312)的应用(例如320)的客户端设备(例如304)接收对于对平台实现包 (例如316)的更新的请求。在604，响应于该请求，对平台实现包的更新(例 如318)可被传达到客户端设备(304)。更新后的平台实现包(318)可操作 来执行与客户端库(312)相关联的至少一个功能。更新后的平台实现包(318) 也可配送到执行带有该客户端库的相应应用的至少多个其他客户端设备。

对平台实现包的更新(318)到客户端设备(304)的传达可在接收到来 自客户端设备(304)的请求时自动发生。如果有客户端库更新(例如314) 可用，则该客户端库更新(例如314)可被传达到客户端设备(304)和/或多 个其他客户端设备(306)中的一者或两者。客户端库更新(314)可作为静 默更新被推送到客户端设备(304)和/或多个其他客户端设备(306)。

参考图2A—图3，在示例实施例中，公开了一种用于将平台实现包自动 配设到客户端设备的系统，该系统可包括客户端设备(例如210)中的至少 一个处理器(例如，CPU 220)。CPU 220可使能接收来自在客户端设备(例 如210)上执行的应用(例如204)的对功能的请求。该请求可经由与应用 204一起配送的客户端库(例如206)来接收。该请求可以是针对由相应的平 台实现包(例如208)提供的功能的。平台实现包208可提供客户端库206 不提供的功能。

CPU 220可使能自动判定该功能要求对平台实现包208的更新。响应于 该判定，CPU 220可使能把对于对平台实现包208的更新的请求传达到计算 系统(例如配设管理器202)。CPU 220可使能从计算系统(例如202)接收 对平台实现包208的更新(例如318)。CPU 220可使能在客户端设备(例如 210)上安装对平台实现包208的更新318。CPU 220可使能由更新后的平台 实现包318在客户端设备202内提供所请求的功能。

CPU 220可使能在应用204的初始执行时或者在应用204的初始执行之 后把对功能的请求传达到配设管理器202。自动判定可包括判定平台实现包 208过时；判定在客户端设备210中未安装平台实现包208；和/或判定平台 实现包208被禁用。判定平台实现包208过时可包括由CPU 220通过将客户 端库206的版本与平台实现包208的版本相比较来执行版本依从性检查。

在传达更新请求之前，CPU 220可使能在设备210上显示对话界面，用 于接收用户对于更新请求的确认。CPU 220可使能在客户端库206中调用一 种方法来用于对话界面的显示。CPU 220可使能从计算系统(例如202)将对 客户端库的更新(例如314)与对平台实现包的更新(例如318)一起接收。 可利用进程间通信(IPC)经由客户端库(例如206)接收该请求。

参考图2A—图3，在示例实施例中，公开了一种用于将平台实现包自动 配设到客户端设备的系统，该系统可包括计算系统(例如，配设管理器202 或302)中的至少一个处理器(例如，CPU 216或308)。CPU 308可使能在 配设管理器处(例如302)从执行带有客户端库(例如312)的应用(例如 320)的客户端设备(例如304)接收对于对平台实现包(例如316)的更新 的请求。响应于该请求，CPU 308可使能将平台实现包更新(例如318)传达 到客户端设备(304)。更新后的平台实现包(318)可操作来执行与客户端库 (312)相关联的至少一个功能。CPU 308还可使能将更新后的平台实现包 (318)配送到执行带有该客户端库(320)的相应应用的至少多个其他客户 端设备(例如306)。

CPU 308可使能在接收到来自客户端设备(304)的请求时自动地将对平 台实现包的更新(318)传达到客户端设备(304)。如果有客户端库更新(例 如314)可用，则CPU 308可使能将该更新(例如314)传达到客户端设备(304) 和/或多个其他客户端设备(306)中的一者或两者。CPU 308还可使能将客 户端库更新(314)作为静默更新推送到客户端设备(304)和/或多个其他客 户端设备(306)。

其他实现方式可提供非暂态计算机可读介质和/或存储介质，和/或非暂态 机器可读介质和/或存储介质，其上存储有具有可由机器和/或计算机执行的至 少一个代码段的机器代码和/或计算机程序，从而使得该机器和/或计算机执行 如本文描述的用于将平台实现包自动配设到客户端设备的步骤。

从而，本方法和/或系统可以用硬件、软件或者硬件和软件的组合来实现。 本方法和/或系统可以以集中方式实现在至少一个计算机系统中，或者以分布 方式实现，其中不同的元件散布在若干个互连的计算机系统上。任何种类的 适用于执行本文描述的方法的计算机系统或其他系统都是合适的。硬件和软 件的典型组合可以是通用计算机系统，该通用计算机系统具有计算机程序， 该计算机程序当被加载和执行时控制计算机系统，以使其执行本文描述的方 法。

本方法和/或系统也可被嵌入在计算机程序产品中，该计算机程序产品包 括使能实现本文描述的方法的所有特征，并且当在计算机系统中被加载时能 够实施这些方法。本上下文中的计算机程序指的是旨在使得具有信息处理能 力的系统直接地或者在以下两者中的任一者或两者之后执行特定功能的一组 指令的采取任何语言、代码或符号的任何表述：a)转换到另一语言、代码或 符号；b)以不同的物质形式再现。

虽然已参考某些实现方式描述了本方法和/或装置，但本领域技术人员将 会理解，在不脱离本方法和/或装置的范围的情况下，可以进行各种改变并且 可以用等同物来替换。此外，在不脱离本公开的范围的情况下，可进行许多 修改来使特定的情形或材料适应于本公开的教导。因此，希望本方法和/或装 置不受限于所公开的特定实现方式，而是本方法和/或装置将包括落在所附权 利要求的范围内的所有实现方式。