好的，作为一名经验丰富的资深专利代理师，我将对您提供的对比文件与目标专利权利要求的技术特征进行严谨、详尽的比对分析。
**对比文件名称：** 2011-10-11_US8036140B_发明授权_US08036140B2 Application programming interface for inviting participants in a serverless peer to peer network
**目标专利名称：** 1154多媒体通信服务处理CN105612730B
**模型名称：** 我无法获取本次调用的具体模型名称，因此无法提供。请务必在提问时附带模型名称。
---
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用（翻译） | 公开性论述 |
| 技术特征A：所述方法由所述UE执行，包括以下步骤<br><br>《隐含公开》 | [0040] “A response may include standard invitee options of ‘accept,’ ‘reject,’ or ‘ignore.’”<br><br>[0045] “FIG. 4 may be an illustration of a method 400 in accordance with the claims. The exemplary method for receiving an invitation may include one of three starting blocks 402, 426, or 456.”<br><br>【译文】[0040] “响应可以包括标准的被邀请方选项：‘接受’、‘拒绝’或‘忽略’。”<br><br>[0045] “图4可以是根据权利要求的方法400的图示。用于接收邀请的示例性方法可以包括三个起始框402、426或456中的一个。” | 对比文件明确描述了由端点（相当于目标专利中的UE）执行的、用于处理多媒体通信服务（邀请参与协作活动）的方法。图4及其相关描述详细说明了接收端（UE）接收邀请并做出响应的一系列步骤。该方法由端点自身执行，这与技术特征A限定的“由所述UE执行”的方法主题相符。虽然对比文件未使用“UE”这一术语，但“endpoint”/“computing device”在功能上完全等同。因此，可合理推断对比文件隐含公开了此特征。 |
| 技术特征B：经由第一用户接口应用处理(S102)进行中的多媒体通信服务<br><br>《未公开》 | [0047] “Similarly, blocks 456 through may execute if the invitee already happens to have the application running that supports the collaborative activity.”<br><br>【译文】[0047] “类似地，如果被邀请方恰好已经在运行支持该协作活动的应用，则可以执行框456至。” | 对比文件提到了接收端可能正在运行一个支持特定协作活动的应用（例如，游戏、网络电话）。这可以被理解为存在一个“进行中的活动”。然而，该文件的核心在于处理“新邀请”的接收，并未明示或暗示该“进行中的活动”是一个需要持续使用特定硬件资源（如麦克风、扬声器）的“多媒体通信服务”，也没有描述该服务是通过一个“第一用户接口应用”进行处理的。对比文件的主要场景是启动一个应用来执行新邀请的活动，而非管理一个进行中的多媒体通信服务。因此，该特征未被公开。 |
| 技术特征C：在所述处理期间，接收(S104)建立其它多媒体通信服务的请求<br><br>《直接公开》 | [0045] “upon receipt of an invitation at block 404, the Invitation API 282 determines if the endpoint supports the requested activity...”<br><br>【译文】[0045] “在框404处接收到邀请后，邀请API 282确定端点是否支持所请求的活动...” | 对比文件明确描述了接收端在其运行过程中（例如，正在运行一个应用，或正在运行一个通用邀请监听器）接收来自发送端的“邀请”。该“邀请”即对应于建立另一项活动的请求，在目标专利的上下文中可类比为“建立其它多媒体通信服务的请求”。该接收动作发生在端点处理某个任务（可能是空闲，也可能是运行应用）期间。因此，此特征被对比文件直接公开。 |
| 技术特征D：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务需要访问UE中一次只能够服务于一个进行中的多媒体通信服务的资源<br><br>《未公开》 | 无直接或相关的引用内容。 | 对比文件通篇未提及UE中存在“一次只能够服务于一个进行中的多媒体通信服务的资源”这一概念，也未提及任何因资源冲突而产生的问题。该文件描述的无服务器对等网络场景中，即使存在多个活动，也未考虑终端本地硬件资源（如麦克风、扬声器）的独占性冲突。对比文件关注的是网络层面的能力协商和连接建立，而非本地资源管理。因此，该特征未被公开。 |
| 技术特征E：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务通过操作系统来保持独立<br><br>《未公开》 | 无直接或相关的引用内容。 | 对比文件的核心是提供一套API来实现跨网络的应用交互，其背景和描述均未涉及操作系统层面对应用程序的隔离机制。虽然操作系统隔离是常见的技术，但对比文件并未将其作为解决任何问题的关键点或技术特征进行描述。目标专利明确指出了“通过操作系统来保持独立”是导致协调困难的根源，而对比文件完全没有触及这一技术问题。因此，该特征未被公开。 |
| 技术特征F：通过IMS服务管理器(21n)来协调(S106)所述进行中的多媒体通信服务和所述其它多媒体通信服务的处理<br><br>《未公开》 | 无直接或相关的引用内容。 | 对比文件的技术方案中不存在“IMS服务管理器”这一核心逻辑实体。对比文件中的邀请过程是通过“Invitation API 282”和“Communication System 260”以及“Presence System 204”等模块协作完成的，没有一个集中的管理器来负责协调两个并行的、可能冲突的多媒体通信服务。目标专利中IMS服务管理器是解决技术问题的关键，而对比文件采用的是完全不同的架构和机制。因此，该特征未被公开。 |
| 技术特征G：其中协调包括向用于处理所述其它多媒体通信服务的应用通知所述建立其它多媒体通信服务的请求<br><br>《隐含公开》 | [0046] “However, if the activity is supported by the listener endpoint, then the invitee may acknowledge the invitation, perhaps via a dialog box, by accepting, rejecting, or ignoring 410.”<br><br>[0047] “Similarly, blocks 456 through may execute if the invitee already happens to have the application running that supports the collaborative activity.”<br><br>【译文】[0046] “然而，如果监听器端点支持该活动，那么被邀请方可以通过对话框（通过接受、拒绝或忽略410）来确认该邀请。”<br><br>[0047] “类似地，如果被邀请方恰好已经在运行支持该协作活动的应用，则可以执行框456至。” | 尽管对比文件没有“IMS服务管理器”，但其邀请处理流程必然包含将接收到的邀请通知给适当的应用。例如，通过对话框或直接传递给正在运行的应用。这在逻辑上等同于“向用于处理所述其它多媒体通信服务的应用通知所述建立其它多媒体通信服务的请求”。虽然对比文件未明确指出“通知”动作是由一个统一的协调器完成，但该动作本身是实现邀请流程的必要步骤。因此，可以合理推断该特征被隐含公开。 |
| 技术特征H：其中所述用于处理所述其它多媒体通信服务的应用包括其它用户接口应用<br><br>《隐含公开》 | [0046] “the application supporting the activity is launched at block 412.”<br><br>【译文】[0046] “在框412处启动支持该活动的应用。” | 对比文件明确指出，在接收并接受邀请后，会“启动”（launch）一个支持该活动的“应用”（application）。这个被启动的应用，特别是像游戏、网络电话或协作白板这类应用，通常都包含用户界面，即“用户接口应用”。因此，用于处理新活动的应用属于“其它用户接口应用”。此特征被隐含公开。 |
| 技术特征I：并且中所述方法还包括：所述用于处理所述其它多媒体通信服务的应用通过启动其它用户接口应用并且使用所述其它用户接口应用获取用户指令来响应所述通知，所述用户指令指示接受还是拒绝所述建立其它多媒体通信服务的请求。<br><br>《隐含公开》 | [0040] “A response may include standard invitee options of ‘accept,’ ‘reject,’ or ‘ignore.’”<br><br>[0046] “However, if the activity is supported by the listener endpoint, then the invitee may acknowledge the invitation, perhaps via a dialog box, by accepting, rejecting, or ignoring 410.”<br><br>【译文】[0040] “响应可以包括标准的被邀请方选项：‘接受’、‘拒绝’或‘忽略’。”<br><br>[0046] “然而，如果监听器端点支持该活动，那么被邀请方可以通过对话框（通过接受、拒绝或忽略410）来确认该邀请。” | 对比文件描述了响应通知的典型过程：1. 通过启动应用或显示对话框来响应通知；2. 通过用户界面（对话框）获取用户指令（接受、拒绝或忽略）。这完全符合技术特征I的逻辑。虽然对比文件中的“应用”或“监听器”可能不是由“IMS服务管理器”通知的，但“响应通知”、“启动用户接口应用”、“获取用户指令”这一系列动作在对比文件中得到了体现。因此，该特征被隐含公开。 |
| 技术特征J：还包括响应于所获得的指示应当接受所述建立其它多媒体通信服务的请求的用户指令而接受所述其它多媒体通信服务<br><br>《隐含公开》 | [0046] “the application supporting the activity is launched at block 412. The application reads the environment variables at block 414, sends back acceptance notification 416 and starts its collaborative activity at block 418.”<br><br>【译文】[0046] “在框412处启动支持该活动的应用。该应用在框414处读取环境变量，在框416处发回接受通知，并在框418处开始其协作活动。” | 对比文件明确描述了当用户选择“接受”后，会启动应用并开始协作活动，这等同于“接受所述其它多媒体通信服务”。虽然对比文件没有使用“建立其它多媒体通信服务”这一表述，但“开始协作活动”在功能上与其等价。因此，可以合理推断该特征被隐含公开。 |
| 技术特征K：其中，接受所述其它多媒体通信服务包括：发起(S108a)所述进行中的多媒体通信服务的暂停过程<br><br>《未公开》 | 无直接或相关的引用内容。 | 对比文件完全没有提及在接受新邀请时，需要“暂停”一个进行中的活动。对比文件中的模型是独立于现有活动来处理新邀请，或者在现有活动结束后再处理，但并未描述一个明确的“暂停过程”来协调两个活动的资源。这是目标专利解决资源冲突的核心创新点之一，在对比文件中完全没有体现。 |
| 技术特征L：激活(S108b)所述其它多媒体通信服务<br><br>《隐含公开》 | [0046] “starts its collaborative activity at block 418.”<br><br>【译文】[0046] “在框418处开始其协作活动。” | 如前所述，接受邀请后启动并开始协作活动，即等同于激活该服务。该特征被隐含公开。 |
| 技术特征M：还包括响应于所获得的指示应当拒绝所述建立其它多媒体通信服务的请求的用户指令而拒绝所述其它多媒体通信服务<br><br>《直接公开》 | [0040] “A response may include standard invitee options of ‘accept,’ ‘reject,’ or ‘ignore.’”<br><br>[0046] “a decline message may be sent at block 408”<br><br>【译文】[0040] “响应可以包括标准的被邀请方选项：‘接受’、‘拒绝’或‘忽略’。”<br><br>[0046] “可以在框408处发送拒绝消息” | 对比文件明确将“拒绝”（reject）作为对邀请的标准响应之一，并描述了发送拒绝消息的动作。这与目标专利中“拒绝所述其它多媒体通信服务”的技术特征完全一致。因此，该特征被直接公开。 |
| 技术特征N：其中，拒绝所述其它多媒体通信服务包括：继续进行(S110a)所述进行中的多媒体通信服务<br><br>《未公开》 | 无直接或相关的引用内容。 | 对比文件在描述拒绝时，仅提及发送拒绝消息。并未描述一个“进行中的多媒体通信服务”需要被“继续进行”或“恢复”。对比文件的场景中，用户可能只是拒绝了一个弹出窗口，而不涉及对另一个并行服务的状态管理。因此，该特征未被公开。 |
| 技术特征O：拒绝(S110b)接受所述其它多媒体通信服务<br><br>《直接公开》 | [0040] “A response may include standard invitee options of ‘accept,’ ‘reject,’ or ‘ignore.’”<br><br>[0046] “a decline message may be sent at block 408”<br><br>【译文】[0040] “响应可以包括标准的被邀请方选项：‘接受’、‘拒绝’或‘忽略’。”<br><br>[0046] “可以在框408处发送拒绝消息” | 与特征M的分析类似，对比文件明确描述了“拒绝”（reject）这一动作，即拒绝接受邀请。这与目标专利中“拒绝接受所述其它多媒体通信服务”的技术特征完全一致。因此，该特征被直接公开。 |
| 技术特征P：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的一个是用于在所述UE上执行第一多媒体类型的多媒体服务的默认应用(24)。<br><br>《未公开》 | 无直接或相关的引用内容。 | 对比文件未提及“默认应用”的概念。其描述的“messenger application”和“computing application”是基于用户选择和应用注册，而非系统预设的、用于特定多媒体类型的“默认应用”。目标专利中的“默认应用”（如VoLTE电话应用）是运营商网络的标准化应用，对比文件的无服务器对等网络场景中没有此概念。 |
| 技术特征Q：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务二者是用于在所述UE上执行第一多媒体类型的多媒体服务的非默认应用(25a、25b)。<br><br>《未公开》 | 无直接或相关的引用内容。 | 对比文件虽然可以处理第三方应用（如游戏），但并未像目标专利那样明确区分“默认”和“非默认”应用。更重要的是，对比文件并未描述两个“非默认应用”之间因资源冲突而需要协调的场景。其更常见的场景是接收一个与当前活动无关的新邀请。 |
| 技术特征R：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务使用所述UE的默认因特网协议多媒体子系统“IMS”通信服务。<br><br>《未公开》 | 无直接或相关的引用内容。 | 对比文件的技术方案基于无服务器对等网络，完全不涉及“IMS”（IP多媒体子系统）架构。对比文件中使用的通信协议和网络模型与IMS完全不同。因此，该特征未被公开。 |
| 技术特征S：其中，所述默认IMS通信服务负责传送应用命令和所述第一多媒体类型的多媒体通信服务的数据。<br><br>《未公开》 | 无直接或相关的引用内容。 | 该特征是特征R的进一步限定。由于对比文件不涉及IMS，自然也不涉及默认IMS通信服务的具体功能。因此，该特征未被公开。 |
| 技术特征T：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的至少一个与IMS应用参考标识符“IARI”相关联。<br><br>《未公开》 | [0044] “The activity information may also include a globally unique identifier (GUID) to identify an appropriate application to the invitee (recipient) that may support the desired activity.”<br><br>【译文】[0044] “活动信息还可以包括一个全局唯一标识符（GUID），用于向被邀请方（接收方）标识可以支持期望活动的适当应用。” | 对比文件使用“GUID（全局唯一标识符）”来标识应用，这与目标专利的“IARI（IMS应用参考标识符）”在功能上有相似之处——都是用于标识特定应用的标识符。然而，GUID是一个通用的、在多种系统中使用的标识符，而IARI是IMS网络中专用的应用标识符。两者的应用场景和协议体系完全不同。更重要的是，对比文件中的GUID用于无服务器对等网络，目标专利中的IARI用于IMS网络，两者不能等同。因此，该特征未被公开。 |
---
**最终公开性判断代码：**
对比文件直接公开了技术特征 C、M、O。
对比文件隐含公开了技术特征 A、G、H、I、J、L。
根据指令要求，将判断结果编码如下：
<<<C>>>
<<<M>>>
<<<O>>>
<<<a>>>
<<<g>>>
<<<h>>>
<<<i>>>
<<<j>>>
<<<l>>>