一种在演进分组系统EPS中操作的用户代理设备，所述用户代理设备包括：用于在非接入层NAS协议层中产生NAS服务请求消息的装置，所述NAS服务请求消息包括扩展服务请求并标识与电路交换CS回退相关的服务类型；以及用于在接入层AS协议层中设置无线电资源控制RRC连接请求消息的RRC建立原因EC的装置，所述EC基于与NAS服务请求消息所标识的CS回退相关的服务类型，其中在所述服务类型是“移动发起MO CS回退”时，所述RRC EC被设置为“MO数据”。

检索结论

我按“公开日在2009年1月15日前”作严格处理，即只纳入最迟于2009年1月14日已经公开的英文专利文本，并以Google Patents中的WO、EP、US英文公开文本为主要检索对象；同族文献只按一项技术披露评价，不重复计算证据权重。

CN102356691B权利要求1的核心并非一般意义上的“LTE到CS网络回退”，而是以下连续技术链：

该特征链可以从目标权利要求及说明书中的映射描述得到确认；目标专利的优先权日为2009年1月15日。(谷歌专利)

本轮多路径检索的核心判断是：

1. 找到了一批公开日在截止日前、对T1—T4分别有明显贡献的英文专利；

2. 尚未找到一篇截止日前的英文专利，同时明确、无歧义地公开T1—T5全部特征；

3. 特别是，没有找到截止日前的英文专利明确公开：

   • Extended Service Request携带MO CS fallback业务类型；以及

   • MO CS fallback → mo-Data这一具体映射；

4. 精确短语、同族及引证网络检索所命中的完整映射，主要集中在目标同族WO2010081233A1/US8625506B2及更晚文献，均不满足本次公开日条件。(谷歌专利)

因此，现阶段更稳妥的无效路径是：以创造性组合为主，而不是直接主张某一篇英文专利单独破坏权利要求1的新颖性。

一、最有价值的英文专利

1. WO2008148432A1

Title: Circuit switched fallback mechanism
公开日：2008年12月11日
建议地位：首选最接近现有技术D1

该文献直接处于LTE/SAE与CS fallback领域，公开了终端驻留在LTE系统时，为使用CS业务回退到2G/3G系统；并且明确说明类似流程适用于mobile-originated CS services：终端在LTE中触发主叫CS业务后，回退到2G/3G并在那里发起CS业务。(谷歌专利)

可贡献：

• T1：LTE/SAE用户设备；

• T3的一部分：MO CS业务触发CS fallback；

• 与目标权利要求相同的总体目的和应用场景。

未公开：

• NAS层的Extended Service Request；

• NAS业务类型到AS层RRC建立原因的映射；

• RRC Connection Request中的具体establishment cause；

• MO CS fallback设置为mo-Data。

评价：
这是目前最适合作为创造性评价起点的专利，因为它与目标权利要求解决的是同一类问题，而且明确涉及MO CS fallback。但单独使用不能完整覆盖权利要求1。

2. EP1983789A1 / WO2008125652A1

Title: Service redirection in evolved communication systems
EP公开日：2008年10月22日
建议地位：LTE侧“业务信息进入RRC Connection Request”的关键桥接文献

该文献涉及SAE/E-UTRAN/EPC中的业务重定向。其重要披露是：在用户设备由空闲状态进入专用连接状态时，业务信息可以识别所请求的业务类型，并且用户设备可将该业务信息包括在RRC Connection Request中。文献还将该机制联系到MOC，即mobile-originated call重定向。(谷歌专利)

可贡献：

• T1：SAE/E-UTRAN环境；

• T3的一部分：识别所请求的业务类型；

• T4的重要功能桥梁：业务类型/业务信息被带入RRC Connection Request；

• 支持“RAN在建立连接时需要知道业务目的”的技术动机。

未公开：

• 业务信息来自NAS Extended Service Request；

• 业务信息被写入的是establishment cause字段；

• MO CS fallback；

• mo-Data映射。

评价：
该文献不能直接证明“NAS业务类型决定establishment cause”，但对于证明“业务类型进入RRC连接建立请求，以便进行重定向或资源处理”非常重要。它比一般性的RRC建立原因文献更接近目标专利。

3. US20080233947A1 / WO2008113775A2

Title: Mobility management (MM) and session management (SM) for SAE/LTE
公开日：2008年9月25日
建议地位：EPS/LTE中的NAS Service Request基础文献

该文献明确描述LTE/SAE协议结构，包括AS低层、NAS、UE、MME，以及UE向MME发送Service Request以建立安全逻辑连接。文献还说明既有移动性管理程序，包括Service Request消息、参数和信息元素，可以应用于LTE/SAE。(谷歌专利)

可贡献：

• T1：LTE/SAE用户设备；

• T2的一部分：NAS层Service Request及UE—MME NAS信令；

• 证明在申请日前，LTE/SAE中NAS层承担业务请求和移动性管理已经是已知架构。

未公开：

• Extended Service Request；

• Service Request中的CS fallback业务类型；

• NAS到AS的establishment cause映射；

• mo-Data。

评价：
适合与WO2008148432A1组合，说明在LTE下发起MO CS fallback时，使用NAS业务请求程序是技术人员已知的协议路径。但“普通Service Request”不能直接等同于权利要求中的“Extended Service Request”。

4. WO2008084316A1

Title: Method for fast circuit switched service enabling handover from packet-switched only networks
公开日：2008年7月17日
建议地位：NAS CS请求与RRC建立原因之间最直接的早期桥接文献之一

该文献针对仅支持分组交换的接入网络向CS网络转移。其披露包括：

• CS-initiating NAS PDU；

• 用户设备请求CS语音业务；

• RRC Connection Request带有与业务有关的建立原因，例如“conversational call”；

• 可使用域指示或建立原因触发向CS网络重定向。

目标专利本身也将WO2008084316A1列为引用文献。(谷歌专利)

可贡献：

• T2的类比：用于启动CS业务的NAS PDU；

• T3的类比：请求的业务是CS语音；

• T4的主要部分：在RRC Connection Request中使用与所请求业务相对应的establishment cause；

• 证明PS-only接入向CS业务切换时，利用RRC建立原因向接入网表明业务目的属于已知技术。

未公开：

• EPS/LTE环境，主要实施方式是WCDMA/PS-only接入；

• Extended Service Request；

• 明确的NAS层业务类型到AS层字段设置步骤；

• MO CS fallback → mo-Data。

评价：
它与WO2008148432A1组合的价值很高：前者提供“NAS CS请求＋RRC建立原因”，后者提供“LTE＋MO CS fallback”。

5. US20050090224A1 / WO2005043478A2

Title: Emergency call placement method
公开日：2005年4月28日
建议地位：MO呼叫业务类型与RRC establishment cause语义对应的补强文献

在普通非紧急呼叫流程中，该文献公开：

• UE发送RRC Connection Request，其establishment cause为“originating conversational call”；

• 随后发送CM Service Request；

• CM Service Request中的CM service type为“mobile originating call establishment”。(谷歌专利)

可贡献：

• T3的类比：业务请求明确识别mobile-originating call establishment；

• T4的类比：同一呼叫流程中使用与MO呼叫相对应的RRC establishment cause；

• 支持“业务目的与RRC建立原因之间存在预定语义对应关系”属于早期已知做法。

限制：

• 非LTE/EPS；

• RRC Connection Request在CM Service Request之前发送，不能直接表述为“NAS收到CM Service Request后才设置establishment cause”；

• 没有CS fallback和mo-Data。

评价：
适合作为“映射语义已知”的辅助文献，但不宜单独表述成已经明确公开NAS层驱动AS层设置。

6. US20070041343A1 / WO2007020528A2

Title: Apparatus, method and computer program product providing simultaneous radio resource and service requests
公开日：2007年2月22日
建议地位：RRC请求与NAS/CM业务请求联动的桥接文献

该文献将RRC Connection Request与包含CM Service Request的Initial Direct Transfer结合或同时发送。CM Service Request中的CM service type可以表示：

• mobile originating call establishment；

• emergency call；

• SMS等不同业务类型。

其权利要求还明确涉及面向CS业务的RRC Connection Request和CM Service Request。(谷歌专利)

可贡献：

• T2、T3的类比：业务请求具有明确的service type；

• T4的类比：无线资源请求与业务请求在同一接入过程中联动；

• 证明RRC层请求和高层业务类型之间建立接口并非目标专利首次提出。

未公开：

• LTE/EPS；

• Extended Service Request；

• establishment cause根据业务类型取值；

• CS fallback和mo-Data。

7. WO2008087518A2 / US20080214190A1

Title: Circuit switched domain services with LTE/SAE access
公开日：2008年7月24日
建议地位：LTE/SAE承载MO CS业务信令的补强文献

该文献公开LTE用户设备、MME和MSC之间支持既有CS业务，并公开了与mobile-originated call有关的呼叫控制信令通过LTE/SAE及MME传递到CS域。(谷歌专利)

可贡献：

• T1：LTE/SAE环境；

• T3的背景部分：LTE接入下的MO CS业务及其信令路径；

• 证明申请日前已存在从LTE侧发起CS域主叫业务的技术需求。

未公开：

• 严格意义上的CS fallback流程；

• Extended Service Request；

• RRC establishment cause映射；

• mo-Data。

评价：
技术背景价值较大，但与权利要求1的具体信令映射距离比前四篇更远。

8. US20080039109A1

Title: Signaling connection admission control in a wireless network
公开日：2008年2月14日
建议地位：RRC establishment cause功能常识的补强文献

该文献公开，空闲UE发送Connection Request时可以包括establishment cause，用于通知无线接入网为什么建立连接；接纳控制可根据该建立原因作出决定。(谷歌专利)

可贡献：

• 证明establishment cause用于表示连接目的，并影响接入网资源或接纳处理；

• 支持目标权利要求所述映射的技术动机。

未公开：

• EPS、NAS Service Request、CS fallback及具体映射均未公开。

二、技术特征覆盖矩阵

“✓”表示明确公开；“△”表示部分公开或可类比；“—”表示未找到相应公开。

这个矩阵显示：截止日前的英文专利能够拼接出权利要求1的大部分技术逻辑，但T2中的“Extended”和T5中的“mo-Data具体取值”仍是关键缺口。

三、建议的创造性组合路线

组合路线A：同领域、同目的的主攻组合

D1：WO2008148432A1

提供：

• LTE/SAE；

• MO CS业务；

• 从LTE向2G/3G执行CS fallback。

D2：US20080233947A1

提供：

• LTE/SAE中的NAS协议架构；

• UE向MME发送NAS Service Request。

D3：EP1983789A1

提供：

• SAE/E-UTRAN中的业务重定向；

• 所请求的业务类型/业务信息进入RRC Connection Request；

• MOC重定向场景。

D4：WO2008084316A1

提供：

• CS-initiating NAS PDU；

• 在PS-only接入中，为请求CS业务而发送具有相应establishment cause的RRC Connection Request。

组合逻辑

从WO2008148432A1出发，技术人员已经面对如下问题：

当LTE驻留终端发起MO CS业务、必须回退到CS网络时，如何在连接建立阶段让无线接入网获知本次接入的业务目的，以便执行重定向和适当的无线资源处理？

US20080233947A1表明LTE/SAE中的业务请求由NAS处理；EP1983789A1表明所请求的业务信息可以进入RRC Connection Request；WO2008084316A1则表明在PS-only接入向CS服务转移时，可以通过RRC建立原因表示CS业务目的。由此可形成“MO CS fallback业务目的—NAS业务请求—AS/RRC连接建立请求—建立原因”的技术链。

该组合的弱点仍然是：

• 为什么必须采用名为Extended Service Request的消息，而不是普通Service Request或其他NAS消息；

• 为什么MO CS fallback应映射为mo-Data，而不是目标说明书同时讨论的mo-Signalling或其他建立原因。

因此，该路线对T1—T4较有说服力，对T5仍需同期标准文件或另一篇更精确的文献补足。

组合路线B：以NAS/AS层间业务语义映射为主

建议组合：

• WO2008148432A1；

• US20080233947A1；

• US20050090224A1；

• 必要时加入US20070041343A1。

其中：

• WO2008148432A1提供LTE MO CS fallback；

• US20080233947A1提供LTE NAS Service Request；

• US20050090224A1提供“mobile originating call establishment”业务类型与“originating conversational call”RRC建立原因的语义对应；

• US20070041343A1进一步证明CM Service Request与RRC Connection Request可以被紧密结合。

该组合有利于主张：根据高层/NAS业务目的选择RRC接入原因，是申请日前在UMTS协议体系中已经存在的设计原则，将其应用于LTE CS fallback具有明确技术动机。

其风险是需要解释为什么技术人员会把UMTS/CM Service Request中的做法移植到EPS Extended Service Request，以及为什么最终取值是mo-Data。

组合路线C：备用CS/LTE证据链

以下英文专利可作为WO2008148432A1的替代或补强证据：

这些文献分别补强“LTE下CS业务需求”“PS→CS转移”和“MO/MT CS业务在LTE中的既有技术背景”，但均没有填补Extended Service Request及mo-Data映射。(谷歌专利)

四、新颖性与创造性攻击强度

1. 单篇新颖性攻击：目前证据不足

本轮检索没有发现一篇符合截止日的英文专利同时公开：

• EPS；

• Extended Service Request；

• 其中的MO CS fallback service type；

• NAS业务类型决定AS层RRC establishment cause；

• establishment cause具体为mo-Data。

因此，不建议仅凭上述任一专利主张其完整公开了权利要求1。特别不能把：

• 普通Service Request直接等同于Extended Service Request；

• 一般CS业务直接等同于CS fallback；

• “originating conversational call”直接等同于EPS中的mo-Data；

• “业务信息包含在RRC Connection Request中”直接等同于“业务类型被映射为establishment cause”。

这些等同关系可以作为创造性论证，但用于单篇新颖性判断会存在明显风险。

2. 创造性攻击：具有实质基础

创造性攻击的较强部分是：

• LTE中的MO CS fallback已公开；

• LTE中的NAS Service Request已公开；

• 在LTE/SAE接入过程中把业务类型信息放入RRC Connection Request已公开；

• 在更早的UMTS/PS-only系统中，以RRC establishment cause表示MO呼叫或CS业务目的已公开；

• establishment cause用于接纳、资源配置或重定向也已公开。

因此，权利要求1中“根据MO CS fallback业务目的选择RRC建立原因”的总体思路，可以构建出较完整的组合论证。

真正可能决定成败的是T5：为什么选择mo-Data。
若没有申请日前文件证明该具体取值已被标准化、讨论过或属于唯一/惯常选择，仅凭多篇专利拼接容易被认为带有事后分析。

五、应重点核查的2008年非专利文件

虽然本次清单限定为英文专利，但为了补足最关键的T4、T5，建议重点核查以下申请日前3GPP资料：

1. 3GPP C1-083834，题名为
   P-CR on 24.301: Provision of RRC establishment cause values by EPS NAS。
   3GPP官方会议文件目录确认该文件属于2008年资料。目标专利说明书也专门提到该文件，并将其描述为解决一般EPS NAS程序与RRC establishment cause映射、但未覆盖CS fallback及Extended Service Request。需要以该文件完整原文为准，不能只依据目标专利对它的评价。(3GPP)

2. 截止日前版本的：

   • 3GPP TS 24.301：EPS NAS；

   • 3GPP TS 36.331：E-UTRA RRC；

   • 3GPP TS 23.272：EPS中的CS fallback。

这些标准的标题和技术范围可由3GPP官方资料确认，但仍需进一步核对2009年1月15日前具体版本的发布日期、表格和变更记录，尤其要查找“MO CS fallback对应mo-Data或mo-Signalling”的明确规定。(3GPP)

若同期3GPP提案或规范版本已经明确规定：

Extended Service Request service type = mobile originating CS fallback
→ RRC establishment cause = mo-Data

则其与WO2008148432A1、US20080233947A1组合后，会显著提高无效论证的强度。

六、日期和语言方面的排除结果

检索中需要特别避免以下误用：

• WO2010081233A1/US8625506B2虽然完整出现“Extended Service Request、MO CS fallback、mo-Data”等表达，但属于目标同族且在2010年公开，不能满足本次公开日要求。(谷歌专利)

• 一些文献虽然优先权日在2009年1月15日前，但公开日在该日之后；按本次条件仍应排除。公开日不能被较早的优先权日替代。

• CN102356691B的引用文献中包括公开于2008年12月31日的CN101335924A，但其是CN中文公开文本；Google Patents提供英文机器翻译，并不会使其成为英文公开专利，因此未列入本次英文专利主清单。(谷歌专利)

最终优先级

建议按以下顺序组织证据：

1. WO2008148432A1：首选最接近现有技术，解决LTE中的MO CS fallback；

2. US20080233947A1：补足EPS/LTE NAS Service Request；

3. EP1983789A1：补足业务类型/业务信息进入RRC Connection Request；

4. WO2008084316A1：补足CS-initiating NAS PDU与RRC establishment cause；

5. US20050090224A1：补足MO call service type与RRC建立原因的语义对应；

6. US20070041343A1：补足NAS/CM业务请求与RRC请求联动；

7. C1-083834及截止日前3GPP版本：重点寻找MO CS fallback→mo-Data的最终映射证据。

综合来看，**上述英文专利对权利要求1的T1—T4具有较强组合贡献，但尚不足以仅靠专利文献稳妥填补T5。**正式无效程序中，应以WIPO、EPO或USPTO的官方英文公开文本核实公开日、段落和附图，并把同族专利、机器翻译和正式英文公开文本严格区分。以上属于专利检索及技术特征比对，不构成法律意见。

检索与比对结论

一、结论先行

我按“公开日严格早于2009年1月15日”理解截止日，即纳入范围最迟到 2009年1月14日；仅将英文原始公开或英文PCT/美国/英国公开列为核心证据。CN102356691B的最早优先权日为2009年1月15日，其英文同族权利要求明确要求以下完整链条：

NAS层生成包含 EXTENDED SERVICE REQUEST 且标识CS fallback服务类型的请求；AS层依据该服务类型设置RRC CONNECTION REQUEST中的EC；当服务类型为 mobile originating CS fallback 时，EC设为 MO data。 (谷歌专利)

本次在Google Patents中经过精确短语、同义词、同族、审查引证、被引证、申请人及发明人等多轮交叉检索后，得到以下核心判断：

1. 没有检出一篇截止日前英文专利直接、完整公开A—E全部技术特征。

2. 截止日前英文专利能够较强地覆盖：

   • NAS/上层发起CS服务请求；

   • CM Service Request及其CM Service Type；

   • RRC Connection Request及其Establishment Cause；

   • 同一呼叫意图在NAS服务类型和RRC建立原因中的对应表达；

   • PS-only或LTE/SAE网络中请求CS业务。

3. 没有检出的两个关键点是：

   • B的完整限定：消息必须是EPS中的EXTENDED SERVICE REQUEST，且其中标识CS fallback相关service type；

   • E的精确映射：MO CS fallback → MO data。

4. 因此，现有英文专利更适合构造创造性组合证据链，不宜单独作为权利要求1全部特征的单篇新颖性证据。

5. 从技术贡献看，权利要求1真正需要重点攻击的组合核心是 B+D+E，其中最难填补的是 E。

这里的“未检出”指本次Google Patents检索范围内的结果，不等同于断言全球不存在其他未被数据库索引或使用不同术语的材料。

二、检索路径

本次主要采用了以下几组检索式并反复交叉：

• 精确短语：

  • "EXTENDED SERVICE REQUEST"

  • "mobile originating CS fallback"

  • "MO CS fallback"

  • "MO data"

  • "RRC establishment cause"

• 早期UMTS/GERAN对应术语：

  • "CM Service Request" + "service type"

  • "mobile originating call establishment"

  • "originating conversational call"

  • "establishment cause" + NAS

• 技术场景：

  • "packet switched only" + circuit switched service

  • "LTE SAE" + circuit switched service

  • "CS domain indicator" + RRC

  • "upper layer request" + RRC connection

• 沿CN、EP、US同族的审查引证、family citations及相关专利的前后向引证继续扩展。

检索结果与目标专利审查引证链出现明显收敛：CN同族列出的截止日前核心引证包括WO2008084316A1；美国同族进一步列出US20050090224A1和US20080039109A1。该收敛不能证明检索绝对穷尽，但说明下面的核心文献组与既有审查过程高度一致。 (谷歌专利)

三、最有贡献的截止日前英文专利

D1：WO2008084316A1

Method for fast circuit switched service enabling handover from packet-switched only networks
公开日：2008年7月17日

这是本次检索中与权利要求整体场景最接近的专利，也是目标CN及US同族的审查引证。

主要披露：

• UE位于PS-only WCDMA网络并请求CS语音业务；

• UE可发送带有“conversational call”建立原因的RRC Connection Request；

• Initial Direct Transfer PDU中包含用于发起CS语音呼叫的NAS消息；

• CS-domain indicator可用于识别请求的是CS业务；

• 文献还指出，该NAS消息可能需要由NAS协议层重传。 (谷歌专利)

对无效的贡献：

• 对A：部分贡献，公开了NAS层处理/重传发起CS呼叫的NAS消息；

• 对B：部分贡献，公开CS服务请求、CS域识别，但不是EPS EXTENDED SERVICE REQUEST，也未公开CSFB service type IE；

• 对C：较强，明确RRC Connection Request及establishment cause；

• 对D：仅为功能性接近，未明确“AS依据NAS消息中的service type设置EC”；

• 对E：未检出。

评价：最接近的总体基础文献，但不能单独破坏权利要求1。

D2：US20050090224A1

Emergency call placement method
公开日：2005年4月28日

该文献在同一个移动发起普通呼叫流程中明确并列公开：

• UE先发送RRC Connection Request；

• RRC establishment cause设为originating conversational call；

• RRC连接建立后，UE发送CM Service Request；

• CM service type设为mobile originating call establishment。 (谷歌专利)

对无效的贡献：

• 对A：部分贡献，CM Service Request属于典型NAS信令，但文献没有采用EPS/NAS层生成装置的表述；

• 对B：较强的早期类比，明确“服务请求消息+移动发起呼叫service type”，但不是ESR，也不是CS fallback service type；

• 对C：直接、明确公开；

• 对D：较强类比，同一MO呼叫意图分别确定RRC EC与NAS service type，但没有明确记载EC是从NAS消息的service type计算得到；

• 对E：未公开MO data。

评价：攻击D之“服务类型与EC之间对应关系”的最重要早期专利之一。

D3：WO2008036961A2

Method and apparatus for resource management
公开日：2008年3月27日

在紧急呼叫实施例中，该文献公开：

• UE发起移动主叫紧急呼叫；

• UE建立RRC连接，establishment cause为emergency call；

• 在上层请求后，UE发送CM Service Request；

• CM Service Type设为Emergency Call Establishment；

• 后续GA-CSR连接建立原因同样指示紧急呼叫。 (谷歌专利)

对无效的贡献：

• 对A：公开上层请求触发CM Service Request；

• 对B：公开NAS类服务请求中的明确service type，但不是ESR/CSFB；

• 对C：公开RRC连接建立原因；

• 对D：对“业务类型决定相应连接建立原因”具有较强功能性启示；

• 对E：只涉及紧急呼叫映射，未公开MO CS fallback到MO data。

评价：适合与D1或LTE背景文献组合，用于论证从呼叫类型选择RRC原因属于既有设计方式。

D4：US20080039087A1

同族：WO2008009016A2
Generic Access to the Iu Interface
公开日：2008年2月14日

主要披露：

• GA-RRC作为UTRAN-RRC的替代资源管理层；

• GA-RRC负责CS/PS传输，并直接传送UE与核心网之间的NAS消息；

• UE的GA-RRC层接收来自NAS层的上行NAS PDU传送请求；

• 文献明确把CM Service Request称为NAS PDU；

• 上层请求建立连接；

• GA-RRC REQUEST包含Establishment Cause以及CS/PS Domain Indicator。 (谷歌专利)

对无效的贡献：

• 对A：本组文献中对NAS消息、CM Service Request和RRC层间接口公开得最系统；

• 对B：公开CM Service Request、NAS PDU和CS domain indicator，但没有ESR和CSFB service type；

• 对C：GA-RRC是UTRAN-RRC的替代机制，属于较强结构类比，但不是权利要求所述E-UTRA RRC Connection Request；

• 对D：上层/NAS到RRC连接建立的层间传递结构较清楚，但未公开从NAS service type直接计算EC；

• 对E：未公开。

评价：适合用于补强A、层间接口及D的体系结构基础。

D5：WO2008041085A2

美国同族：US20080080428A1
PS network with CS service enabling functionality
公开日：2008年4月10日；美国同族公开日为2008年4月3日

主要披露：

• PS-only的iHSPA网络需要区分UE请求的是PS业务还是CS业务；

• 对移动发起呼叫，网络读取RRC消息中的Establishment Cause IE；

• Establishment Cause可包含所请求的业务类别；

• 示例原因包括Originating conversational call，用于将UE导向支持CS的网络。 (谷歌专利)

对无效的贡献：

• 对B：公开CS业务类别；

• 对C：公开RRC Establishment Cause；

• 对D：公开建立原因中承载所请求业务类别，功能上非常接近“按业务类型设置EC”；

• 但没有NAS EXTENDED SERVICE REQUEST，也没有明确的NAS service type→AS EC层间计算；

• 对E：未公开。

评价：对D的技术效果及“业务类别置入RRC建立原因”的常规性具有贡献。

D6：GB2439768A

Emergency Call-Back in a Mobile Telecommunications Terminal without a Smart Card
公开日：2008年1月9日

该文献公开：

• 移动终端发起CS紧急呼叫；

• 无线连接的establishment cause为originating conversational call；

• 随后终端发送CM Service Request；

• 该请求标识service type为emergency call。 (谷歌专利)

对无效的贡献：

• 对A、B、C均有部分贡献；

• 对D提供了另一组“RRC原因+CM service type”并列实例；

• 但其RRC原因与NAS service type并非完全同名，反而说明不同协议层可采用不同编码表达同一业务；

• 对E没有贡献。

评价：可以辅助说明NAS service type与RRC cause并不要求文字相同，只需实现业务语义对应。

D7：US20080039109A1

Signaling connection admission control in a wireless network
公开日：2008年2月14日

该文献明确说明：

• 空闲UE通过Connection Request请求信令连接；

• Connection Request中的establishment cause用于通知RAN建立连接的原因；

• RRC Connection Request的原因可以为Originating Conversational Call。 (谷歌专利)

对无效的贡献：

• 对C为直接证据；

• 可用于解释EC的公知目的及作用；

• 对A、B、D、E没有实质性直接披露。

评价：典型的C特征补强文献，也是目标美国同族的审查引证。

D8：US20080214190A1

Circuit switched domain services with LTE/SAE access
公开日：2008年9月4日

该文献公开LTE/SAE移动设备继续使用现有CS核心网业务，并通过MME、MSC-S及LTE接入架构实现CS业务。 (谷歌专利)

对无效的贡献：

• 证明在截止日前，LTE/SAE接入下继续提供移动主叫CS业务已经是明确研究方向；

• 对B中的“EPS/LTE环境下CS业务”具有背景贡献；

• 未公开ESR、service type到EC的映射或MO data。

评价：LTE/EPS场景桥接文献，不宜作为主文献。

D9：WO2008088258A1

Method and arrangements for circuit switched services in communication networks
公开日：2008年7月24日

该文献针对连接到LTE/SAE网络的UE访问CS网络业务，并在移动主叫流程中由UE经2G/3G RAN向MSC/VLR发送CM Service Request。 (谷歌专利)

对无效的贡献：

• 同时提供LTE/SAE、移动主叫CS业务和CM Service Request背景；

• 对A、B具有场景性贡献；

• 未公开EPS ESR、NAS service type决定RRC EC及MO data。

评价：比D8更接近“LTE环境中的MO CS请求”，但仍缺少关键映射。

四、A—E特征比对矩阵

符号说明：

• ●：直接或基本明确公开；

• △：只公开了部分内容、功能类比或旧制式对应机制；

• —：本次全文检索未发现实质性披露。

特别说明：

• B只有同时满足“EXTENDED SERVICE REQUEST+CS fallback相关service type”才能认定为完整公开，因此表中的△均不代表完整B；

• D只有明确公开“RRC EC基于NAS服务请求消息所标识的service type”才算完整公开；

• E要求精确的MO CS fallback → MO data。

注：

1. D4明确把CM Service Request认定为NAS PDU，并公开NAS层到GA-RRC层的传送请求；但不是EPS ESR。

2. D4使用GA-RRC REQUEST，属于UTRAN-RRC替代机制，不是权利要求中的E-UTRA RRC Connection Request。

3. D8只公开LTE/SAE环境中的CS业务，不公开权利要求B所限定的消息结构。

五、逐特征的综合判断

特征A

现有专利基础较强。

D2、D3、D4、D6、D9均公开CM Service Request或NAS PDU；D4尤其明确NAS层向RRC替代层发出上行NAS PDU传送请求，并将CM Service Request称为NAS PDU。 (谷歌专利)

虽然早期文献通常不采用“用于在NAS协议层中产生……的装置”这一权利要求式表述，但从协议体系结构看，A很难成为独立的实质区别点。

特征B

仅有外围和类比披露，没有完整披露。

截止日前文献分别公开了：

• CM Service Request及其service type；

• CS-domain indicator；

• PS-only/LTE网络中的CS业务请求；

• 移动主叫呼叫、紧急呼叫等不同业务类别。

但是本次未检出截止日前英文专利明确公开：

EPS NAS消息为EXTENDED SERVICE REQUEST，并在该消息中标识mobile originating CS fallback等CSFB service type。

目标专利说明书本身也指出，EPS中新增了UMTS没有使用的EXTENDED SERVICE REQUEST，而既有一般NAS→RRC映射没有计及该消息。 (谷歌专利)

因此，B是第一处实质缺口。

特征C

现有专利基础最强。

D1、D2、D7直接公开RRC Connection Request中的Establishment Cause；D3、D5、D6也公开了相同或高度接近的RRC/无线连接建立原因机制。 (谷歌专利)

C本身不宜作为权利要求1的主要创造性支撑点。

特征D

功能思想已有较强基础，但精确的数据依赖关系没有被直接公开。

D2公开同一MO呼叫对应：

• RRC EC：originating conversational call；

• CM service type：mobile originating call establishment。

D3、D6也公开同一业务在RRC建立原因和NAS service type中的对应表达；D4公开NAS层与RRC替代层之间的层间请求关系；D5公开根据所请求业务类别设置/读取Establishment Cause。 (谷歌专利)

这些文献能够支持如下技术论证：

一旦NAS或上层已经知道请求的CS业务类别，在AS/RRC层选择与该业务类别相对应的establishment cause，属于既有协议设计思路。

但它们没有明确公开权利要求所要求的完整因果链：

从EXTENDED SERVICE REQUEST中读取CSFB service type，并据此设置EPS RRC EC。

因此，D可以通过组合论证，但直接文字基础不够完整。

特征E

本次没有找到有效的截止日前英文专利披露。

检索中出现的早期映射主要是：

• 普通MO呼叫 → originating conversational call；

• 紧急呼叫 → emergency call或originating conversational call；

• CS/PS业务 → 对应domain indicator或业务类别。

没有文献明确给出：

mobile originating CS fallback服务类型 → EPS RRC establishment cause MO data。

目标专利说明书将该映射作为其严格映射表的一部分，并明确提出在service type为mobile originating CS fallback时可设置MO data。 (谷歌专利)

因此，E是专利证据链中的决定性缺口，也是权利要求1最可能保有区分度的特征。

六、可构造的无效组合路径

组合路径一：D1 + D2 + D7

D1作为最接近基础文献

D1提供：

• PS-only网络请求CS语音业务；

• RRC Connection Request；

• conversational-call EC；

• NAS消息发起CS业务；

• CS域识别。

D2补充service type与EC的对应

D2提供：

• mobile originating call establishment这一NAS/CM service type；

• 同一MO呼叫的RRC EC为originating conversational call。

D7补充EC的公知目的

D7说明Establishment Cause就是用于向RAN表示UE请求连接的原因。

组合后能够较好覆盖：A、C以及B/D的大部分技术思想。

仍然无法解决：

• 为什么采用EXTENDED SERVICE REQUEST；

• 为什么其service type必须是MO CS fallback；

• 为什么对应的EPS EC选择MO data而不是MO signaling或其他原因。

评价：这是最强的“纯专利”组合，但对E仍存在实质缺口。

组合路径二：D8或D9 + D4 + D2

D8/D9

提供LTE/SAE环境下访问CS业务、移动主叫CS业务及CM Service Request背景。

D4

提供：

• NAS PDU；

• CM Service Request；

• NAS层与RRC替代层接口；

• Establishment Cause；

• CS/PS Domain Indicator。

D2

提供MO呼叫service type和RRC cause的对应实例。

优势：

该组合比路径一更接近EPS/LTE的协议层次和CS业务场景。

弱点：

• 需要三篇不同体系文献拼接；

• D4是GAN/GA-RRC架构，D2是传统UMTS呼叫流程；

• 仍未得到ESR及MO CS fallback → MO data的精确映射。

评价：体系结构较完整，但组合距离更远，容易被质疑存在事后拼接。

组合路径三：D5 + D2 + D8/D9

D5说明PS-only网络需要依据请求业务类别和RRC Establishment Cause识别、转移CS业务；D2给出MO call service type与RRC cause的具体并列关系；D8/D9补入LTE/SAE环境。

该组合可以形成如下技术论证：

在PS-only或LTE接入网络中，为使网络及时识别移动主叫CS业务，本领域技术人员有动机把已知的MO CS业务类别映射为适当的RRC建立原因。

但从“适当的建立原因”进一步跳到**特定的MO data**仍没有专利文字依据。

七、3GPP非专利材料的关键作用

虽然您本次要求的是英文专利，但从无效证据完整性看，截止日前的3GPP材料可能比继续寻找泛化专利更关键。

目标美国同族列出的截止日前非专利材料包括：

• 3GPP TS 23.272 V8.2.0，2008年12月，CS Fallback；

• 3GPP TS 24.301 V8.0.0，2008年12月，EPS NAS；

• 3GPP TS 36.331 V8.4.0，2008年12月，E-UTRA RRC；

• Samsung C1-083834，2008年10月，题为“Provision of RRC Establishment Cause Values by EPS NAS”。 (谷歌专利)

目标专利说明书承认：

• UMTS中已有NAS procedure到RRC EC的映射；

• C1-083834讨论了EPS NAS提供RRC建立原因；

• 但其认为C1-083834只处理一般映射，没有解决CS fallback，也没有计及EXTENDED SERVICE REQUEST。 (谷歌专利)

这段“自认背景”对无效分析有双重影响：

1. 有利部分：NAS决定EC、通过层间请求交给AS/RRC，可能已经是截止日前的一般技术机制；

2. 不利部分：目标专利明确把ESR、CSFB service type及严格映射作为既有材料未解决的问题。

目标专利对C1-083834的描述不是该文献内容的最终法律认定，仍需以3GPP原件、会议上传时间、公开可获得性及具体CR版本为准。但若无法在这些原始材料中找到MO CS fallback → MO data，仅靠目前检出的英文专利很难完整填补E。

八、因公开日晚于截止日而排除的近似文献

下列英文专利主题更直接涉及CS fallback，但按照您要求的“公开日”口径不能作为2009年1月15日前公开的文献：

这些文献虽然优先权日在目标日前，但在本次设定的公开日标准下应排除，不能仅因优先权较早就纳入截止日前公开文献集合。 (谷歌专利)

此外，目标CN审查引证还包括CN101335924A，公开日为2008年12月31日；由于本次要求的是英文专利，未把该CN公开作为核心英文文献，但在正式无效检索中仍应单独审查其中文原文，而不能只依赖Google机器翻译。 (谷歌专利)

九、最终总结

对单篇新颖性证据的判断

在本次Google Patents多轮检索中，没有发现一篇公开日在2009年1月15日前的英文专利能够直接、完整覆盖A—E。

最接近的D1仍然缺少：

• EPS EXTENDED SERVICE REQUEST；

• ESR中的CSFB service type；

• NAS service type到EPS RRC EC的明确映射；

• MO CS fallback → MO data。

所以，以目前英文专利证据单独攻击权利要求1的全部新颖性，技术基础不足。

对创造性组合的判断

英文专利可以形成较强组合证据，证明以下内容在截止日前已经分别存在：

• NAS/CM Service Request及service type；

• 上层或NAS请求触发RRC连接；

• RRC Connection Request带Establishment Cause；

• 同一业务类别在NAS service type和RRC EC中的对应；

• PS-only/LTE/SAE环境中的移动主叫CS业务。

最强专利组合建议以：

D1 WO2008084316A1 + D2 US20050090224A1 + D7 US20080039109A1

作为主线，并使用D3、D4、D5补强“业务类型—建立原因”及NAS/RRC层间关系。

但该组合最终仍停留在：

“根据MO CS业务类型选择适当的RRC建立原因”

而不是权利要求的：

“根据EXTENDED SERVICE REQUEST中标识的MO CS fallback service type，将RRC EC精确设置为MO data”。

因此，权利要求1无效攻击的真正胜负点是：能否从2009年1月15日前已公开的3GPP原始版本、会议提案、CR附件或其他非专利材料中，直接找到或无歧义推出E的精确映射。 若不能，纯专利组合对E的补足会面临明显困难。

以上为专利检索和技术特征分析，不构成对中国专利无效程序结果的法律意见。

CN102356691B权利要求1：截止2009年1月15日前的日文专利检索与比对

一、检索结论

本次将“日文专利”理解为：在日本以日文公开的JP公报，包括日本国内“特开”公报以及进入日本国家阶段的“特表”公报；并严格采用以下时间口径：

日本公报自身的公开日必须早于2009年1月15日。

仅有更早优先权日、但日本公报在2009年1月15日以后公开的文献，不纳入本次有效文献集合。

经过日文关键词、英文协议术语、同族、被引证/引用、申请人、发明人及RRC/NAS相关分类的反复交叉检索，结论是：

1. 未检出一件合格的日文专利单独、完整公开A—E全部特征。

2. 日文专利对以下内容已有较强公开：

   • 移动终端/MM实体生成或发送CM SERVICE REQUEST；

   • 服务请求中包含表示普通呼、紧急呼、SMS-MO或移动发起呼的service type；

   • UE在RRC CONNECTION REQUEST中设置Establishment Cause；

   • 同一业务语义分别在NAS/MM服务类型和接入层建立原因中表达；

   • 在LTE/SAE场景下，RRC请求可同时携带服务设置信息和EC，并可根据EC或NAS/Layer 3消息决定后续S1建立。

3. 本次未检出的关键内容仍然是：

   • B的完整限定：EPS中的EXTENDED SERVICE REQUEST，并由该消息标识CS fallback相关service type；

   • D的精确因果链：AS层EC直接基于上述NAS消息中的CSFB service type设置；

   • E的精确映射：MO CS fallback → MO data。

4. 最有价值的三件日文公开是：

   • JP2003244284A：同一流程中同时公开NAS CM Service Request和RRC EC；

   • JP2007295523A：明确处于LTE/SAE场景，并把EC、服务设置信息、NAS/Layer 3消息联系起来；

   • JP2008544608A：明确公开移动发起呼的CM service type。

因此，现有日文专利适合构造创造性组合证据链，但目前不适合作为单篇破坏权利要求1全部新颖性的证据。

二、检索方法

主要使用了下列日文及英文关键词，并进行精确短语与组合检索：

• 拡張サービス要求、EXTENDED SERVICE REQUEST

• 回線交換フォールバック、CSフォールバック、CS fallback

• モバイル発信CSフォールバック

• MO data、ＭＯデータ

• 非アクセス階層、NAS message

• CM SERVICE REQUEST、CMサービス要求

• サービス種別、CMサービス・タイプ

• 確立要因、確立理由、Establishment cause

• RRC CONNECTION REQUEST

• LTE/SAE、EPS

• Mobile originated call、移動体発信

• 回線交換サービス、パケット交換専用

同时沿下列路径扩展：

• CN102356691B及其US、EP、JP同族的审查引证；

• 已找到的英文核心文献对应的日本同族；

• NEC、松下/松下电器、NTT DoCoMo等申请人的RRC/NAS相关专利；

• RRC Connection Request + Establishment Cause文献的前后向引证；

• LTE/SAE呼建立、CM Service Request、紧急呼及MO呼相关分类。

需要特别指出：目标专利的日本公开为 JP2012515475A，公开日为2012年7月5日；其最早优先权日为2009年1月15日。该日本公报明确出现拡張サービス要求、CS fallback及MO data映射，但显然不能作为2009年1月15日前的公开文献。(谷歌专利)

三、核心日文专利

J1：JP2003244284A

名称： 移動端末、緊急呼管理装置、緊急呼管理システム及び緊急呼の管理方法
申请人： NEC
公开日： 2003年8月29日
类型： 日本原始申请

这是本次日文专利检索中，针对“同一服务语义跨NAS层和RRC层表达”最有价值的单篇文献。

主要披露

移动终端在请求紧急呼时：

1. 在RRC CONNECTION REQUEST中将Establishment Cause设置为Emergency call；

2. 完成RRC连接建立后，在INITIAL DIRECT TRANSFER携带的NAS message中，将CM service request设置为Emergency call establishment；

3. 网络先从RRC EC判断是紧急呼，再从NAS CM Service Request进行确认。

文献甚至明确说明，由于RRC Establishment Cause和NAS CM Service Request中都包含表示紧急呼的数据，网络能够对紧急呼作两次确认。(谷歌专利)

对A—E的贡献

• A：较强部分公开。 明确由移动终端设置并发送NAS message中的CM Service Request，但没有采用“在EPS NAS层产生EXTENDED SERVICE REQUEST”的表述。

• B：部分公开。 公开了NAS服务请求以及表示具体服务类别的值，但不是EXTENDED SERVICE REQUEST，也不是CS fallback service type。

• C：直接公开。 明确设置并发送带有EC的RRC CONNECTION REQUEST。

• D：较强功能性启示。 同一“紧急呼”业务语义在RRC EC和NAS service request中分别编码。

• E：未公开。

重要限制

J1中的顺序是先发送RRC Connection Request，后发送NAS CM Service Request。因此，它没有直接公开：

AS层从已经生成的NAS service type中读取信息，然后计算或设置RRC EC。

它能够证明的是“同一服务类型在NAS和AS中采用对应编码”的既有机制，而不是权利要求D所要求的明确数据依赖关系。

J2：JP2007295523A

名称： 無線通信基地局装置及び呼接続方法
申请人： 松下电器产业株式会社
公开日： 2007年11月8日
类型： 日本原始申请

这是截止日前日文专利中，最接近LTE/SAE技术环境的文献。

主要披露

文献明确以3GPP正在标准化的LTE/SAE为技术背景，指出呼连接主要包括RRC建立和呼控制两部分。终端发送的RRC CONNECTION REQUEST中可设置：

• 上位节点认证所需信息；

• 服务设置所需信息；

• 无线资源信息；

• 表示建立RRC连接理由的Establishment Cause。

其EC示例包括Mobile originated call。当EC表示需要用户数据传输的移动发起呼时，基站可据此决定发送S1 setup request。(谷歌专利)

更重要的是，该文献还公开了两种功能上并列的处理方式：

• 根据RRC消息中的Establishment Cause决定是否发送S1 setup request；

• 或者接收NAS message等Layer 3消息，根据该NAS/Layer 3消息决定是否发送S1 setup request。

另一实施例中，上位节点也可根据Direct Transfer中携带的“服务设置信息”作出相同的S1建立决定，其中服务设置信息的例子是Mobile originating call。(谷歌专利)

对A—E的贡献

• A：部分公开。 明确涉及NAS/Layer 3消息和终端服务设置信息，但没有明确产生EPS NAS服务请求消息。

• B：部分公开。 涉及Mobile originating call服务信息，但不是ESR，也不是CSFB service type。

• C：直接公开。 终端在RRC Connection Request中设置EC。

• D：较强功能性启示。 EC和NAS/Layer 3服务信息可以作为实现同一后续连接决策的替代输入。

• E：未公开。

重要意义

J2使得无效组合不必完全从传统UMTS或GSM跨越到LTE。它能够证明，在目标优先权日前：

LTE/SAE呼建立中，服务信息、NAS/Layer 3消息和RRC Establishment Cause之间的功能联系已经被考虑。

但J2采用的EC示例是Mobile originated call，而不是MO data。这一差异不能忽略。

J3：JP2008544608A

名称： ワイヤレス位置検出システムにおいて位置検出に基づくサービスを適用するための高度トリガ
申请人： TruePosition
公开日： 2008年12月4日
类型： 日文特表公报

主要披露

对于SMS-MO，文献公开：

• 接入阶段的CHANNEL REQUIRED原因值表示初始建立用于SMS-MO；

• 随后移动设备发送CM SERVICE REQUEST；

• CM Service Request包含CM service type，表示请求SMS-MO服务。

对于移动发起呼，文献更明确公开：

• 移动设备发送CM SERVICE REQUEST；

• 该请求包含CM service type；

• 该service type表示服务是为移动发起呼而请求。(谷歌专利)

对A—E的贡献

• A：较强部分公开。 移动设备生成并发送CM Service Request。

• B：较强的旧制式对应公开。 服务请求中明确包含移动发起呼service type，但不是ESR，也不是CSFB。

• C：仅为类比。 使用的是GSM接入原因，不是RRC Establishment Cause。

• D：部分启示。 接入原因和CM service type均反映正在请求的业务类别。

• E：未公开。

该文献是将J1、J2中的“业务类型”具体连接到移动发起呼service type的最佳日文补强文献之一。

J4：JP2008500751A

名称： 無認可モバイル・アクセス遠隔通信システムにおけるメッセージング
申请人： Kineto Wireless
公开日： 2008年1月10日
类型： 日文特表公报

主要披露

文献公开了MM子层与无线资源层之间的层间关系：

• MS的MM子层请求建立新的UMA-RR连接；

• 随后发送CM-SERVICE-REQUEST；

• UMA-RR实体在新连接时设置UCI=1；

• 紧急呼连接则采用特殊UCI值，以便网络优先处理。

这说明，在既有协议体系中，上层/MM服务请求触发下层无线资源连接建立，并使无线资源层设置相应的连接指示值，已经是明确的层间处理模式。(谷歌专利)

对A—E的贡献

• A：部分公开。 MM子层发送CM Service Request。

• B：部分公开。 存在服务请求，但没有ESR/CSFB service type。

• C：未直接公开。 使用UMA-RR/UCI而非RRC EC。

• D：结构性启示。 MM服务请求触发无线资源连接并设置接入层指示值。

• E：未公开。

J4适合补强“NAS/MM层请求—接入层连接参数”的因果体系结构，但不宜作为最接近文献。

J5：JP2005527149A

名称： ワイヤレスネットワークにおけるシグナリング接続アドミッション制御
申请人： InterDigital
公开日： 2005年9月8日
类型： 日文特表公报

主要披露

空闲UE通过Connection Request请求控制平面信令连接，该消息包含Establishment Cause，用于向RAN说明UE请求连接的原因。文献进一步明确：

• RRC CONNECTION REQUEST含有EC信息元素；

• EC示例包括originating conversational call；

• 网络可以根据不同EC采用不同资源接纳方式。(谷歌专利)

对A—E的贡献

• A、B：未公开。

• C：直接公开。

• D：弱功能性启示。 EC本身承载连接所对应的服务/原因。

• E：未公开。

J5是C特征的稳固补强文献，而且其英文同族也出现在目标专利同族的既有引证链中。

J6：JP2008166878A

名称： 無線基地制御局、移動体通信システム及びそれらに用いる優先セル選択方法
申请人： NEC
公开日： 2008年7月17日
类型： 日本原始申请

主要披露

权利要求4明确规定，RNC可以根据移动终端最初的无线连接请求消息中所表示的下列信息进行选择：

• 终端能力与版本；

• 终端准备启动的服务类型；

• 建立理由；

• 是否存在协议错误。

其说明书还保留“高速服务对象的建立理由”和“优先服务类型”内部数据。(谷歌专利)

对A—E的贡献

• A：未公开。

• B：部分公开。 有“准备启动的服务类型”，但不是NAS ESR中的CSFB service type。

• C：较强公开。 最初无线连接请求中含建立理由。

• D：部分启示。 服务类型和建立理由被共同用于无线连接处理。

• E：未公开。

该文献不能证明service type直接生成EC，但可证明在接入连接阶段联合考虑“服务类型”和“建立原因”并非目标专利首次提出。

J7：JP2006229384A

名称： 移動通信システム、基地局制御装置及びそれらに用いる移動局差別化方法並びにそのプログラム
申请人： NEC
公开日： 2006年8月31日
类型： 日本原始申请

主要披露

文献明确公开RRC Connection Request中的Establishment Cause可以设置为：

• Originating Interactive Call

• Originating Background Call

• Terminating Interactive Call

• Terminating Background Call

RNC读取这些值，以判断移动台及进行相应的资源或小区处理。(谷歌专利)

对A—E的贡献

• A、B：未公开。

• C：直接公开。

• D：一般性启示。 RRC EC根据呼叫/业务类别采用不同值。

• E：未公开。

J7适合证明C以及“按照业务类别区分EC值”的常规性。

J8：JP2002501353A

名称： 通信システムおよびマルチプルキャパシティの無線通信トランクにおけるアドレッシング方法
申请人： Omnipoint
公开日： 2002年1月15日
类型： 日文特表公报

主要披露

文献明确公开：

• GSM-MM实体发起正常呼的移动管理连接；

• MM实体向MSC发送CM Service Request；

• 请求包含表示正常呼的service type field；

• 对紧急呼，MM实体同样发送CM Service Request，并使CM service type field表示紧急呼。(谷歌专利)

对A—E的贡献

• A：较强旧制式对应公开。

• B：部分公开。 服务请求携带明确service type，但不是ESR/CSFB。

• C、D、E：未公开。

其通信终端并非典型EPS智能手机架构，因此更适合作为A、B上位概念的辅助证据。

四、技术特征比对表

符号说明：

• ●：直接或基本明确公开；

• △强：高度相关，但缺少权利要求中的特定协议、消息或明确因果关系；

• △：部分公开、旧制式对应或功能类比；

• —：本次全文检索未发现实质性公开。

特别注意：

• B只有同时具备EXTENDED SERVICE REQUEST和CSFB service type才是完整公开；

• D只有明确公开“AS层EC基于该NAS请求中标识的CSFB service type设置”才是完整公开；

• E要求精确的MO CS fallback → MO data。

五、逐特征综合判断

特征A：NAS层产生服务请求消息

日文专利的基础较强。

J1明确公开移动终端在NAS message中设置并发送CM Service Request；J3公开移动设备发送包含CM service type的CM Service Request；J4公开MM子层请求无线资源连接并随后发送CM Service Request；J8则明确由GSM-MM实体发起并发送该消息。

剩余区别主要是：

• 既有消息是CM SERVICE REQUEST；

• 权利要求要求EPS中的EXTENDED SERVICE REQUEST；

• 部分文献没有采用“用于在NAS协议层中产生消息的装置”这一装置式表述。

因此，A的上位功能本身不强，但A与特定ESR结合后的限定仍需其他证据。

特征B：ESR并标识CS fallback service type

这是第一处重要缺口。

日文文献已经分别公开：

• 服务请求消息；

• service type field；

• 移动发起呼、紧急呼或SMS-MO等服务类型；

• LTE/SAE中的服务设置信息。

但本次未检出截止日前日文公报明确公开：

在EPS NAS层产生EXTENDED SERVICE REQUEST，并使该消息标识“MO CS fallback”等CSFB service type。

因此，J1、J3、J8只能证明B的传统NAS/MM上位概念，不能完整公开B。

特征C：RRC Connection Request中设置EC

这是最容易被既有日文专利覆盖的特征。

J1、J2、J5、J7均直接公开RRC CONNECTION REQUEST和Establishment Cause；J6则公开最初无线连接请求中的建立理由。

C不应被视为权利要求1的主要创造性来源。

特征D：EC基于NAS消息标识的CS fallback服务类型

日文专利已经给出若干接近机制：

• J1：同一紧急呼语义同时表示为RRC EC和NAS CM Service Request值；

• J2：在LTE/SAE中，EC和NAS/Layer 3消息可分别驱动同一种S1连接决策；

• J4：MM服务请求触发无线资源连接，并由无线资源层设置连接指示；

• J6：最初无线连接请求阶段同时考虑服务类型和建立理由。

这足以支持以下一般性技术论证：

当上层或NAS已经识别出待启动的业务类型时，在接入层设置与该业务相匹配的连接原因，是截止日前已有的协议设计思想。

但是，没有一篇合格日文专利明确公开：

从EXTENDED SERVICE REQUEST中取得CS fallback service type，并据此在AS层设置EPS RRC EC。

所以D的上位思想可被组合攻击，但其具体数据路径仍不完整。

特征E：MO CS fallback时设置为MO data

这是日文专利证据中的决定性缺口。

截止日前文献中的常见映射是：

• 紧急呼 → Emergency call

• 移动发起会话呼 → Originating conversational call

• 交互或后台业务 → 对应的Originating/Terminating Interactive/Background Call

• LTE/SAE移动发起呼 → Mobile originated call

本次没有发现任何合格日文公开将：

MO CS fallback映射到MO data。

尤其值得注意的是，J2虽然处于LTE/SAE场景并明确涉及移动发起呼，但其示例EC仍是Mobile originated call，不是MO data。因此，不能仅以J2直接填补E。

目标日本同族中的精确映射直到2012年7月5日公开的JP2012515475A才出现；该公报明确记载MO CS fallback时EC可为MO signaling或MO data，并进一步记载将MO CS fallback设置为MO data的实施方式。(谷歌专利)

六、推荐的组合证据路径

路径一：J2 + J1 + J3

这是当前日文专利中最强的组合。

J2作为LTE/SAE基础文献

J2提供：

• LTE/SAE呼连接环境；

• 终端在RRC Connection Request中设置EC；

• EC示例为Mobile originated call；

• RRC请求中还可含服务设置信息；

• EC或NAS/Layer 3消息均可用于后续S1建立决策。

J1补充NAS与RRC的双层业务语义

J1提供：

• NAS CM Service Request；

• RRC Establishment Cause；

• 同一紧急呼业务在两个协议层分别编码。

J3补充MO service type

J3提供：

• CM Service Request中明确包含移动发起呼的CM service type。

组合效果

该组合可以较有力地覆盖：

• A的上位概念；

• B中“服务请求+移动发起服务类型”的传统对应机制；

• C；

• D中“根据业务类型选择相应EC”的一般技术思想。

剩余缺口

仍然缺少：

1. 为什么传统CM Service Request应替换为EXTENDED SERVICE REQUEST；

2. 为什么service type应具体定义为MO CS fallback；

3. 为什么该服务必须映射为MO data。

因此，该组合有利于攻击A、C和D的上位创造性，但不能自然、无歧义地得到E。

路径二：J2 + J4 + J5

该路径重点攻击层间体系结构：

• J2：LTE/SAE、NAS/Layer 3消息、EC及S1连接决策；

• J4：MM服务请求触发无线资源连接，并由无线资源实体设置接入指示；

• J5：RRC Connection Request及EC的标准作用。

该组合可以论证：

NAS/MM业务请求驱动AS/RRC连接建立，并设置反映连接原因的参数，属于既有分层协议实现方式。

但J4采用UMA-RR/UCI，J5采用UMTS EC，跨体系组合距离较大，并且仍无法得到MO data。

路径三：J1 + J8 + J7

该路径适合证明传统机制：

• J8：MM实体产生CM Service Request及service type；

• J1：同一服务语义分别进入NAS服务请求和RRC EC；

• J7：不同业务类别对应不同RRC Establishment Cause值。

它可以证明“服务类型—建立原因”映射不是全新思想，但缺乏LTE/EPS和CS fallback场景，因此更适合作为辅助组合而不是主组合。

七、无效使用价值排序

综合技术距离、披露完整度和组合价值，可按以下顺序使用：

八、最终判断

就目前检出的截止日前日文专利而言：

• A：已有较强基础；

• B：仅覆盖传统CM Service Request及service type，不覆盖完整ESR+CSFB；

• C：基本属于已知技术；

• D：一般映射思想已有较强组合基础，但精确NAS→AS数据依赖仍有缺口；

• E：没有找到有效日文专利披露。

因此：

不存在已检出的单篇日文专利新颖性证据；最强日文专利组合为JP2007295523A + JP2003244284A + JP2008544608A，但该组合仍无法直接填补“MO CS fallback → MO data”。

从无效证据组织角度，日文专利最适合用于压缩权利要求的技术贡献范围：证明NAS服务类型、RRC建立原因、跨层业务语义对应以及LTE/SAE中的EC/NAS关联均已有基础。真正需要继续寻找直接证据的，是EXTENDED SERVICE REQUEST、CSFB service type以及MO data精确映射。下一证据层应优先核查2009年1月15日前公开可获得的3GPP原始提案、会议文稿、变更请求及对应版本记录。

以上是基于Google Patents的技术检索和特征分析，不构成对中国专利无效案件结果的法律意见。

CN102356691B权利要求1：2009年1月15日前韩文专利检索与特征比对

一、结论先行

本次将“韩文专利”限定为：

由韩国知识产权主管机关以韩文公开的KR公报，并且韩国公报自身的公开日早于2009年1月15日。

因此，即使某一专利族具有更早的美国、欧洲或PCT公开，只要其韩国公报在2009年1月15日以后才公开，就不列入本次合格韩文文献。

经Google Patents中的韩文全文、英文协议术语、目标专利引证链、韩国同族、被引证文献、申请人及相关分类反复交叉检索，得到以下结论：

1. 未检出一件截止日前韩文专利单独、完整公开A—E全部技术特征。

2. 截止日前韩文专利已经较强地公开了：

   • 移动终端发送或设置CM SERVICE REQUEST；

   • CM SERVICE REQUEST中包含CM service type；

   • service type可以表示Mobile originating call establishment、紧急呼或SMS-MO；

   • RRC CONNECTION REQUEST中设置Establishment Cause；

   • 同一业务语义可分别在NAS/MM服务请求和RRC建立原因中表示；

   • 上层/MM服务请求触发无线资源层连接建立或连接参数设置。

3. 本次没有检出的完整限定是：

   • B：EPS中的EXTENDED SERVICE REQUEST并标识CS fallback相关service type；

   • D：AS层RRC EC明确基于上述NAS消息中标识的CSFB service type设置；

   • E：MO CS fallback → MO data。

4. 按特征重合度，最强韩文基础文献是：

   • KR20030069855A；

   • KR20060067235A；

   • KR20050000429A。

5. 按LTE/SAE与CS网络场景，KR20080086781A具有桥接价值，但其讨论的是LTE/SAE与CS之间的语音呼叫切换，不是权利要求中的MO CS fallback服务请求流程。

6. 最强组合可以表述为：

KR20030069855A + KR20060067235A + KR20050000429A
可再以 KR20080086781A 补充LTE/SAE—CS应用背景。

但该组合仍不能直接得到EXTENDED SERVICE REQUEST + MO CS fallback service type + MO data这一精确链条。

目标专利韩国同族的权利要求明确要求：NAS层生成包含EXTENDED SERVICE REQUEST且标识CS fallback服务类型的消息，AS层据此设置RRC EC，并在服务类型为MO CS fallback时将EC设为MO data。该韩国同族最早优先权日为2009年1月15日，韩国A公开日则为2011年9月22日。(Google Patents)

二、检索路径

本次重点使用了下列韩文、英文及混合关键词：

• 확장 서비스 요청、확장된 서비스 요청

• EXTENDED SERVICE REQUEST

• 회선 교환 폴백、CS 폴백、CS fallback

• 모바일 발신 CS 폴백

• MO 데이터、MO data

• 비접속 계층、NAS

• CM 서비스 요청、CM SERVICE REQUEST

• CM 서비스 유형、CM service type

• 모바일 발신호 설정

• Mobile originating call establishment

• RRC 연결 요청、RRC CONNECTION REQUEST

• 설정 원인、구축 원인、Establishment Cause

• LTE/SAE、CS service、PS-only

扩展检索路径包括：

• 目标CN、KR、US、EP同族的前后向引证；

• 英文核心专利对应的韩国国家阶段；

• NEC、LG、三星、Kineto、Nokia、InterDigital等申请人的相关专利；

• RRC Connection Request、CM Service Request和Establishment Cause文献的被引证关系；

• UMTS、GSM、UMA、LTE/SAE及CS互操作场景。

精确检索EXTENDED SERVICE REQUEST + CS fallback + MO data时，本次未发现韩国公报公开日在2009年1月15日前的直接命中；相关韩文公报主要在截止日以后出现。

三、核心韩文专利

K1：KR20030069855A

名称： 이동국, 및 긴급호 관리 장치, 긴급호 관리 시스템 및 긴급호 관리 방법
中文概括： 移动台、紧急呼叫管理装置、系统及方法
申请人： NEC
公开日： 2003年8月27日

这是本次检索中，对权利要求1整体协议流程贡献最大的韩文文献。

主要披露

移动台发起紧急呼叫时：

1. 在RRC CONNECTION REQUEST中，将Establishment Cause设置为Emergency call；

2. 网络根据该EC判断其为紧急呼叫；

3. 完成RRC连接建立后，移动台通过INITIAL DIRECT TRANSFER发送NAS消息；

4. 在该NAS消息中，将CM SERVICE REQUEST设置为Emergency call establishment。

换言之，同一“紧急呼叫”业务语义分别在：

• AS/RRC层表示为Emergency call EC；

• NAS/MM层表示为Emergency call establishment CM service request。

文献还明确说明，网络可通过RRC EC进行初步判断，再通过NAS CM Service Request进行最终确认。(Google Patents)

对权利要求1的贡献

• A：较强部分公开。 移动台设置并发送NAS消息中的CM Service Request。

• B：较强部分公开。 服务请求中表示特定业务类型，但不是EPS ESR，也不是CSFB service type。

• C：直接公开。 明确在RRC Connection Request中设置EC。

• D：较强功能性启示。 同一业务类型在NAS和RRC层分别采用对应原因值。

• E：未公开。

关键限制

该文献的信令时序是：

先发送RRC CONNECTION REQUEST，后发送NAS CM SERVICE REQUEST。

因此，它没有直接公开：

AS层从已经生成的NAS服务请求中的service type读取信息，并据此设置RRC EC。

其能够证明的是“业务类型在两个协议层对应表达”，而不是权利要求D所要求的具体数据依赖关系。

K2：KR20060067235A

名称： WCDMA 이동 통신 시스템 및 그 발신자 이름 정보표시 방법
中文概括： WCDMA移动通信系统及主叫名称显示方法
申请人： LG电子
公开日： 2006年6月19日

主要披露

该文献明确指出：

• 对语音呼叫，发起终端首先发送CM Service Request；

• 该消息结构采用3GPP TS 24.008；

• 消息中包括CM service type字段；

• CM service type表示向网络请求的CM服务类别；

• 文献列出的类型包括：

  • Mobile originating call establishment

  • Emergency call establishment

  • Voice group call establishment

  • Voice broadcast call establishment

因此，它是本次韩文检索中对“服务请求消息包含明确的移动发起呼service type”披露最清楚的文献。(Google Patents)

对权利要求1的贡献

• A：较强部分公开。 移动终端发送CM Service Request。

• B：较强的旧制式对应公开。 请求消息包含Mobile originating call establishment service type。

• C：未公开。

• D：未公开。

• E：未公开。

关键限制

其消息属于UMTS/WCDMA中的CM Service Request，不是EPS中的EXTENDED SERVICE REQUEST；Mobile originating call establishment也不能直接等同于MO CS fallback。

K3：KR20080021651A

名称： 무선 로케이션 시스템에서 로케이션 기반의 서비스 어플리케이션을 위한 개선된 트리거
中文概括： 无线定位系统中用于位置服务应用的改进触发器
申请人： TruePosition
公开日： 2008年3月7日

主要披露

文献在移动发起流程中公开：

• 移动设备向网络发送CM Service Request；

• 请求包含CM service type；

• 对SMS-MO，该service type表示请求的是SMS-MO服务；

• 对移动发起呼，该service type表示服务是为移动发起呼而请求。

其表述尤其明确：

CM Service Request包含CM service type，该service type指示服务是为mobile originating call请求的。(Google Patents)

对权利要求1的贡献

• A：较强部分公开。

• B：较强部分公开。 明确存在服务请求和MO service type。

• C：未公开RRC EC。

• D：仅有一般业务类别与接入流程的联系。

• E：未公开。

K3可以作为K2的独立补强文献，证明在截止日前“移动发起呼类型由CM Service Request中的service type标识”不是孤立披露。

K4：KR20050000429A

名称： 무선 네트워크에서의 신호 접속 승인 제어 방법
中文概括： 无线网络中的信令连接接纳控制方法
申请人： InterDigital
公开日： 2005年1月3日

主要披露

文献明确公开：

• RRC CONNECTION REQUEST包含Establishment Cause信息元素；

• Establishment Cause向RAN表示请求连接的原因；

• 示例EC为Originating Conversational Call；

• 网络可根据该EC预测后续接入量、业务时延敏感性并进行资源接纳。(Google Patents)

对权利要求1的贡献

• A、B：未公开。

• C：直接公开。

• D：一般性启示。 EC反映呼叫或业务类别。

• E：未公开。

K4适合用于证明：

在RRC Connection Request中设置表示移动发起业务原因的EC，是截止日前已经成熟的技术。

但其EC是Originating Conversational Call，不是EPS EC中的MO data。

K5：KR20080046664A

名称： RACH(Random Access Channel)을 통한 전송 방법
中文概括： 通过随机接入信道进行传输的方法
申请人： LG电子
公开日： 2008年5月27日

主要披露

文献公开：

• UE初始接入通过连接请求消息开始；

• 连接请求消息包含请求理由；

• 该理由称为Establishment Cause；

• EC用于说明为什么建立连接；

• 不同业务类别可以采用不同建立原因，包括会话、流媒体、交互、后台等原因。(Google Patents)

对权利要求1的贡献

• A、B：未公开。

• C：直接或基本明确公开。

• D：一般性启示。 连接建立原因依业务类别而异。

• E：未公开。

K5主要用于补强C以及“按业务类别选择EC值”的常规性。

K6：KR20070044402A

名称： 비허가 모바일 액세스 통신 시스템에서의 메시징
中文概括： 非授权移动接入通信系统中的消息传送
申请人： Kineto Wireless
公开日： 2007年4月27日

主要披露

在UMA/GAN架构中，该文献公开：

• 移动台MM子层请求建立新的UMA-RR连接；

• 随后发送CM-SERVICE-REQUEST；

• UMA-RR实体在新连接时设置连接指示；

• 紧急呼叫采用特别指示值，以使网络进行优先处理。

它反映了一种截止日前已存在的分层处理模式：

MM/NAS类业务请求触发下层无线资源连接，并使无线资源层设置与连接用途有关的参数。(Google Patents)

对权利要求1的贡献

• A：部分公开。

• B：部分公开。

• C：结构类比。 使用UMA-RR而非E-UTRA RRC。

• D：较强结构性启示。

• E：未公开。

该文献适合用于补强NAS/MM层与无线资源层之间的因果关系，但不能作为C或D的直接同制式公开。

K7：KR20060063317A

名称： 비동기망과 동기망이 중첩된 이동통신망에서의 핸드오버 조건 설정 방법
中文概括： 异步网与同步网重叠移动通信网络中的切换条件设置方法
申请人： SK Telecom
公开日： 2006年6月12日

主要披露

该文献把以下步骤置于同一移动终端呼叫建立流程：

1. UE发送RRC Connection Request；

2. 网络发送RRC Connection Setup；

3. UE发送RRC Connection Setup Complete；

4. UE通过Initial Direct Transfer发送CM Service Request；

5. 完成实际业务的呼叫建立。(Google Patents)

对权利要求1的贡献

• A：部分公开。

• B：仅公开传统CM Service Request。

• C：公开RRC连接请求，但未明确EC取值。

• D：只能说明RRC连接与后续NAS服务请求位于同一呼叫建立流程。

• E：未公开。

其价值主要是协议层次和信令时序补强。

K8：KR20080086781A

名称： 이종의 무선 통신 네트워크에서 핸드오버 장치 및 방법
中文概括： 异构无线通信网络中的切换装置及方法
申请人： 三星电子、延世大学
公开日： 2008年9月26日

主要披露

该文献明确处于：

• LTE/SAE系统；

• GSM/WCDMA CS系统；

• LTE/SAE VoIP呼叫与CS呼叫之间的转换；

• 单无线或异构网络语音业务连续性场景。

说明书涉及LTE/SAE VoIP呼叫切换为GSM/WCDMA CS呼叫，以及CS呼叫转换为LTE/SAE VoIP呼叫。(Google Patents)

对权利要求1的贡献

• A：未公开ESR。

• B：仅对“LTE/SAE环境与CS业务相互操作”提供背景贡献。

• C、D、E：未公开。

关键限制

该文献本质上是异构系统呼叫切换或语音业务连续性机制，不是：

空闲LTE UE为了发起CS语音业务而执行CS fallback，并由ESR service type决定RRC EC。

因此，K8只能作为应用场景桥接文献，不能替代B、D或E的直接披露。

四、其他辅助韩文专利

这两件文献可以补强“接入层信号反映待请求服务或上层消息类型”的一般技术思想，但不能作为核心对比文件。

五、A—E技术特征比对表

符号含义：

• ●：直接或基本明确公开；

• △强：高度相关，但缺少权利要求中的特定消息、制式或明确因果链；

• △：部分公开、旧制式对应或功能类比；

• —：未发现实质性公开。

特别说明：

• B必须同时具备EXTENDED SERVICE REQUEST和CS fallback service type才算完整公开；

• D必须明确记载RRC EC基于该NAS消息标识的CSFB service type设置；

• E必须是精确映射MO CS fallback → MO data。

注1：K8只贡献LTE/SAE与CS系统共存、切换的应用背景，不公开权利要求B所要求的NAS消息结构。

六、逐项技术判断

特征A：NAS层产生服务请求消息

该特征的上位概念已有较强基础。

K1明确由移动台设置NAS消息中的CM Service Request；K2、K3明确由移动终端发送CM Service Request；K6公开MM子层请求无线资源连接并发送CM Service Request；K7把RRC连接建立与随后通过Initial Direct Transfer发送CM Service Request置于同一流程。(Google Patents)

不过，上述文献的服务请求主要是UMTS/GSM中的CM SERVICE REQUEST，而不是EPS中的EXTENDED SERVICE REQUEST。因此：

A的“NAS/MM层生成或发送服务请求”较弱，但其与特定EPS ESR的结合仍存在区别。

特征B：ESR并标识CS fallback service type

本次韩文专利已经公开：

• 服务请求消息；

• CM service type；

• Mobile originating call establishment；

• Emergency call establishment；

• SMS-MO；

• LTE/SAE与CS网络之间的业务互操作。

但未检出截止日前韩文公报明确公开：

EXTENDED SERVICE REQUEST中包含或标识MO CS fallback等CSFB service type。

K2和K3能够证明“移动发起呼类型由服务请求中的service type表示”是已知机制；K8能够补入LTE/SAE与CS系统共存的背景。但把两者结合起来，仍然不能直接得到EPS ESR中的CSFB专用service type。

因此，B是第一处实质性证据缺口。

特征C：RRC Connection Request中设置EC

该特征已有直接、充分的韩文专利基础。

K1明确将Emergency call设置为RRC Connection Request的EC；K4明确公开RRC Connection Request中的Establishment Cause IE及Originating Conversational Call示例；K5明确连接请求消息包含表示请求理由的Establishment Cause。(Google Patents)

因此，C本身不宜视为权利要求1的主要创造性贡献。

特征D：RRC EC基于NAS消息标识的CSFB服务类型

现有韩文专利对其一般技术思想已有较强贡献：

• K1：同一紧急呼叫语义分别表示为RRC EC和NAS CM Service Request；

• K2、K3：NAS/MM服务请求中存在明确的MO service type；

• K4、K5：RRC EC用于反映连接所对应的呼叫或业务原因；

• K6：MM层业务请求触发无线资源层建立连接并设置连接指示。

由此可以形成一般性论证：

当NAS/MM或上层已经识别待启动的业务类别时，在无线资源控制层选择与该业务相对应的建立原因或接入指示，是截止日前已有的分层协议设计方式。

但上述文献均没有明确公开：

AS层从EXTENDED SERVICE REQUEST中读取CSFB service type，并依据该service type计算或设置EPS RRC EC。

尤其是K1的时序为RRC请求在前、NAS CM Service Request在后，不能将其直接表述成“EC是根据NAS消息中的service type生成”。

因此，D的上位映射思想可以组合攻击，但其具体数据依赖关系仍未被直接公开。

特征E：MO CS fallback时EC设置为MO data

这是当前韩文专利证据中的决定性缺口。

检出的截止日前EC主要包括：

• Emergency call

• Originating Conversational Call

• 不同会话、流媒体、交互或后台业务原因

• UMA/GAN中的连接用途指示

检出的service type主要包括：

• Mobile originating call establishment

• Emergency call establishment

• SMS-MO

• 其他传统CM服务类别

本次没有发现任何合格韩文公报明确给出：

MO CS fallback → MO data。

目标专利韩国同族反而说明，UMTS建立原因与EPS建立原因不同，传统UMTS映射不能简单一一复制，并把ESR service type映射到EPS EC作为其解决方案；其权利要求进一步将MO CS fallback明确限定为MO data。(Google Patents)

因此，E是纯韩文专利证据链中最难填补、区分度最高的技术特征。

七、推荐的无效组合路径

组合路径一：K1 + K2 + K4

K1作为最接近基础文献

K1提供：

• 移动终端；

• NAS CM Service Request；

• RRC Connection Request；

• RRC Establishment Cause；

• 同一业务语义在NAS和AS/RRC层的对应表达。

K2补充移动发起service type

K2提供：

• CM Service Request消息结构；

• CM service type；

• Mobile originating call establishment。

K4补充RRC EC的作用

K4提供：

• RRC Connection Request中的EC；

• Originating Conversational Call；

• 网络根据EC识别连接用途和资源需求。

组合效果

该组合能够较强地覆盖：

• A的传统NAS/MM上位概念；

• B中“服务请求包含MO service type”的传统部分；

• C；

• D中“同一业务类型在NAS服务类型和RRC建立原因中对应表达”的一般思想。

剩余缺口

仍然不能得到：

1. EXTENDED SERVICE REQUEST；

2. MO CS fallback这一特定service type；

3. EC明确从该ESR service type生成；

4. MO CS fallback → MO data。

所以该组合适合作为创造性攻击主线，但不能在不补充其他证据的情况下完整覆盖权利要求1。

组合路径二：K1 + K2 + K4 + K8

在路径一基础上，以K8补充：

• LTE/SAE环境；

• LTE/SAE与GSM/WCDMA CS系统的互操作；

• 单无线语音呼叫在LTE/SAE和CS之间转换。

该组合可以形成更接近目标应用场景的论证：

传统的NAS service type—RRC EC对应机制，在LTE/SAE与CS业务互操作环境中继续使用。

但其弱点也很明显：

• K8是呼叫切换或业务连续性，不是MO CS fallback初始接入；

• 需要四件文献跨越UMTS、WCDMA、LTE/SAE及CS切换场景；

• 容易被质疑存在事后拼接；

• 即使完成组合，仍缺少MO data的具体选择理由。

因此，K8只宜作为场景桥接材料，不宜作为填补B、D或E的直接文件。

组合路径三：K2 + K6 + K4

该路径主要攻击分层协议结构：

• K2：NAS/MM服务请求及MO service type；

• K6：MM请求触发无线资源层连接和连接用途指示；

• K4：RRC Connection Request及EC。

可用于论证：

从NAS/MM业务请求向AS/RRC层传递业务类别并设置接入参数，是传统协议栈中的常规设计。

但K6采用UMA-RR和UCI，K4采用UMTS RRC EC，两者不是EPS NAS/RRC，因此只能支持上位技术启示，不能作为精确同制式披露。

八、因韩国公开日晚于截止日而排除的近似文献

1. KR20090079224A

名称： 이동 디바이스, 통신 방법 및 네트워크 유닛
主题： PS-only网络中的CS业务使能
优先权日： 2006年10月3日
韩国公开日： 2009年7月21日

该文献技术上与PS-only网络请求CS业务较为接近，但韩国公报公开日晚于2009年1月15日。因此，即使其英文/PCT同族在截止日前已经公开，也不能按照本次“韩国公报自身公开日”的口径列为合格韩文文献。(Google Patents)

2. KR20100060353A

名称： CS fallback 기능을 제공하는 시스템 및 방법
主题： 提供CS fallback功能的系统和方法
优先权日： 2008年11月27日
韩国公开日： 2010年6月7日

虽然其韩国申请日在目标优先权日前，但在2009年1月15日前尚未公开，按本次公开日标准应排除。(Google Patents)

3. KR20110104563A

这是目标专利的韩国A公开文本，公开日为2011年9月22日。它直接记载ESR、CSFB service type和MO CS fallback → MO data，但显然不能作为目标优先权日前的现有技术。(Google Patents)

这些例子说明：

不能仅凭优先权日或外国同族公开日较早，就将一件后来公开的韩国公报计入“2009年1月15日前公开的韩文专利”。

九、最终证据评价

1. 单篇新颖性证据

本次未检出一件2009年1月15日前公开的韩文专利能够完整覆盖A—E。

其中最接近整体结构的K1仍缺少：

• EPS；

• EXTENDED SERVICE REQUEST；

• CS fallback service type；

• NAS service type到AS RRC EC的明确因果关系；

• MO data映射。

因此，现有韩文专利不适合作为单篇破坏权利要求1全部新颖性的核心证据。

2. 创造性组合证据

韩文专利可以较强地证明以下内容在截止日前已经存在：

• NAS/MM服务请求；

• 服务请求中的MO service type；

• RRC Connection Request中的Establishment Cause；

• 根据呼叫或业务类别选择不同EC；

• 同一业务语义在NAS和RRC层分别编码；

• 上层/MM业务请求触发无线资源层连接或连接参数设置；

• LTE/SAE与CS网络之间的语音业务互操作背景。

最强韩文专利组合建议为：

KR20030069855A + KR20060067235A + KR20050000429A

并可用：

KR20080086781A

补充LTE/SAE—CS场景。

3. 仍待解决的核心问题

即使采用上述组合，仍然只能较好地推导：

“根据移动发起CS业务类型设置相应RRC建立原因。”

却不能直接推导：

“根据EXTENDED SERVICE REQUEST中标识的MO CS fallback service type，将EPS RRC EC特定设置为MO data。”

所以，韩文专利最有价值的作用是：

• 压缩A、C及D上位概念的技术贡献；

• 证明传统NAS service type—RRC cause对应机制；

• 证明LTE/SAE与CS互操作的应用背景。

真正决定权利要求1无效攻击成败的，仍是能否在2009年1月15日前公开可获得的3GPP原始提案、技术规范版本、会议文稿或变更请求中，找到：

1. EXTENDED SERVICE REQUEST的CSFB service type；

2. NAS service type向EPS RRC EC的明确映射；

3. 尤其是MO CS fallback → MO data。

正式提交无效证据前，还应以韩国知识产权主管机关的原始韩文公报PDF核对段落、附图和公开日，避免完全依赖Google Patents的文本解析或机器翻译。以上为专利技术检索与特征分析，不构成法律意见。

CN102356691B权利要求1：2009年1月15日前中文专利检索与比对

一、检索口径与结论

本次将“中文专利”限定为：

在中国以中文公开的CN专利公报，包括中国原始申请和进入中国国家阶段的中文公开文本；其CN公报公开日必须严格早于2009年1月15日。

因此，最迟纳入日期为2009年1月14日。仅有较早申请日或优先权日、但CN公报在2009年1月15日以后才公开的文献，均予排除。

CN102356691B权利要求1的实质技术链条是：

1. 在NAS层产生NAS服务请求消息；

2. 消息是EXTENDED SERVICE REQUEST，并标识CS fallback相关service type；

3. 在AS层设置RRC Connection Request中的EC；

4. EC基于NAS消息标识的CSFB service type；

5. MO CS fallback → MO data。
   目标专利最早优先权日为2009年1月15日。(谷歌专利)

总体结论

经过精确短语、中文同义词、传统UMTS术语、EPS/LTE场景、目标专利引证链、相关CN专利前后向引证及相似文献的多轮交叉检索，结论如下：

1. 没有检出一件截止日前中文专利单独、完整公开A—E全部特征。

2. 中文专利已经较强公开：

   • UE或终端NAS/MM实体生成、处理或发送CM SERVICE REQUEST；

   • CM SERVICE REQUEST中包含CM service type；

   • service type可以表示“建立移动始发呼叫”“紧急呼叫”或其他具体业务；

   • RRC CONNECTION REQUEST中设置Establishment Cause；

   • 同一个移动始发呼叫或紧急呼叫，在NAS service type和RRC EC中采用对应的业务语义；

   • NAS业务请求触发MM/RRC连接建立；

   • 甚至已有文献将NAS业务请求直接封装进RRC Connection Request，使NAS业务信息在RRC建立阶段已经可用。

3. 本次未检出的完整限定是：

   • B： EXTENDED SERVICE REQUEST且标识CS fallback相关service type；

   • D： AS层EC明确基于该ESR中的CSFB service type设置；

   • E： MO CS fallback → MO data。

4. 当前最有价值的中文专利组合是：

CN101335924A + CN1937827A + CN1853424A

其中：

• CN101335924A补入EPS NAS协议架构和NAS消息设置/发送装置；

• CN1937827A证明NAS业务请求可以在RRC Connection Request阶段直接提供；

• CN1853424A给出普通移动始发呼叫的NAS service type与RRC EC对应实例。

但该组合仍没有直接给出MO CS fallback → MO data。因此，E仍是纯中文专利证据链的决定性缺口。

二、检索路径

主要检索词包括：

• 扩展服务请求、EXTENDED SERVICE REQUEST

• 电路交换回退、CS回退、CS fallback

• 移动发起CS回退、MO CS fallback

• MO数据、移动发起数据

• 非接入层、NAS业务请求

• CM SERVICE REQUEST、CM服务请求

• CM service type、CM服务类型

• RRC CONNECTION REQUEST

• 建立原因、建立动机、Establishment Cause

• 建立移动始发呼叫

• 始发会话呼叫

• LTE/SAE、EPS、电路域业务

交叉检索还覆盖：

• 目标CN专利的审查引证和同族引证；

• RRC Connection Request与CM Service Request同流程文献；

• NAS消息封装进RRC消息的快速呼叫建立文献；

• LTE/SAE与CS域互操作、SRVCC、PS域承载CS业务文献；

• 华为、中兴、展讯、NEC、摩托罗拉、InterDigital等申请人的相关专利。

Google Patents所列目标CN专利的两件直接审查引证为WO2008084316A1和CN101335924A，其中后者是本次中文专利检索的重要基础文件。(谷歌专利)

三、核心中文专利

C1：CN1853424A

名称： 紧急呼叫拨打方法
申请人： Motorola
公开日： 2006年10月25日
类型： 中国国家阶段中文公开

这是本次检索中，对“移动发起呼叫的NAS service type与RRC EC对应关系”公开最明确的文献。

关键披露

对于普通非紧急移动始发呼叫：

• UE发送RRC Connection Request；

• Establishment Cause设为“始发会话呼叫”；

• RRC连接建立后，UE发送CM Service Request；

• CM service type设为“建立移动始发呼叫”。

对于紧急呼叫：

• RRC EC设为“紧急呼叫”；

• CM service type设为“建立紧急呼叫”。(谷歌专利)

对A—E的贡献

• A：较强部分公开。 UE产生并发送NAS/MM层的CM Service Request。

• B：较强上位公开。 NAS服务请求明确携带具体业务类型，但不是ESR和CSFB类型。

• C：直接公开。

• D：较强功能性对应。 同一MO呼叫意图分别对应NAS service type和RRC EC。

• E：未公开。

关键限制

该文献的RRC请求在CM Service Request之前发送。因此，不能直接表述为：

EC是从已经发送的CM Service Request中的service type读取并计算得到。

它证明的是对应关系，而不是权利要求D要求的明确数据依赖关系。

C2：CN1937827A

名称： 移动通信系统中快速呼叫建立的方法
申请人： 展讯通信（上海）有限公司
公开日： 2007年3月28日
类型： 中国原始申请

这是本次中文检索中新发现的、对“NAS业务请求在RRC建立阶段已经可用”贡献最强的文献。

关键披露

文献明确区分：

• RRC连接建立；

• NAS信令连接建立和NAS信令交互；

• RAB建立。

其改进方案是：

• UE发送RRC Connection Request；

• 该RRC请求中直接封装NAS消息；

• 封装的NAS消息包括“业务请求”以及PDP激活请求或CS域的SETUP消息；

• RNC从RRC请求中解析NAS消息，并转发给核心网。(谷歌专利)

对A—E的贡献

• A：直接或基本明确公开。 NAS业务请求由UE产生并置入发送消息。

• B：部分公开。 有NAS Service Request，但不是EPS ESR或CSFB service type。

• C：仅公开RRC Connection Request，未明确EC取值。

• D：较强结构性贡献。 NAS业务请求在形成RRC Connection Request时已存在并可被使用。

• E：未公开。

重要意义

传统UMTS流程通常是先发RRC请求，再发CM Service Request，容易形成“NAS消息还不存在，AS如何基于它设置EC”的抗辩。C2通过把NAS业务请求提前封装进RRC请求，削弱了这一时序障碍。

但它仍没有记载：

AS读取NAS service type并据此选择EC。

C3：CN1835627A

名称： 一种建立主叫的方法
申请人： 华为技术有限公司
公开日： 2006年9月20日
类型： 中国原始申请

关键披露

该文献在同一移动主叫流程中明确公开：

• UE发送RRC Connection Request；

• RRC请求中携带“建立原因值”；

• 建立原因可以是特定快速主叫原因，例如PTT私密呼叫主叫建立或PTT组呼建立；

• 后续NAS信令中的CM Service Request和SETUP被合并为IMMEDIATE SETUP；

• 该NAS类消息携带“业务类型”。(谷歌专利)

对A—E的贡献

• A：较强部分公开。

• B：部分公开。 CM Service Request携带业务类型，但不是ESR/CSFB。

• C：直接公开。

• D：较强功能性对应。 RRC建立原因与NAS业务类型均反映同一次主叫的业务性质。

• E：未公开。

C3的优点是中国原始申请，并且同时出现了“RRC建立原因”和“NAS业务类型”。其不足是没有明确说明EC由NAS业务类型计算产生。

C4：CN1933656A

名称： 宽带码分多址系统中的紧急呼叫处理方法
申请人： 中兴通讯股份有限公司
公开日： 2007年3月21日
类型： 中国原始申请

关键披露

一般呼叫流程包括：

• UE向RNC发送带有建立原因的RRC请求；

• UE向核心网发送CM Service Request；

• CM Service Request中的service type为话音呼叫。

针对紧急呼叫：

• RRC根据EC识别紧急呼叫；

• 核心网根据CM Service Request携带的service type识别紧急或普通呼叫；

• 文献进一步指出，CM Service Request对RNC透明，因此核心网识别出的紧急业务信息需要通过其他指示传递给RNC。(谷歌专利)

对A—E的贡献

• A：较强部分公开。

• B：部分公开。

• C：直接公开。

• D：较强功能性启示。 同一业务类型分别通过NAS service type和RRC EC表达；业务类型还用于驱动无线资源侧的后续处理。

• E：未公开。

C4特别适合用于证明：

service type是一种可供网络选择相应接入或无线处理参数的业务语义信息。

C5：CN1909718A

名称： 一种WCDMA系统中的紧急呼叫处理方法
申请人： 中兴通讯股份有限公司
公开日： 2007年2月7日
类型： 中国原始申请

关键披露

文献明确描述：

• UE发送带建立原因的RRC连接建立请求；

• RRC连接建立后，UE发送CM Service Request；

• CM Service Request表示服务类型为话音呼叫；

• 对紧急呼叫，RNC通过RRC EC识别业务；

• 核心网通过CM Service Request中的service type识别业务。(谷歌专利)

对A—E的贡献

• A、B：部分公开。

• C：直接公开。

• D：较强功能性对应。

• E：未公开。

C5与C4属于不同申请，可作为“NAS业务类型与RRC建立原因表达同一呼叫属性”的独立中文佐证。

C6：CN1980453A

名称： 一种在终端中实现移动管理连接的方法
申请人： 中兴通讯股份有限公司
公开日： 2007年6月13日
类型： 中国原始申请

关键披露

文献在终端内部明确设置：

• CM实体；

• MM实体；

• RRC实体。

其流程为：

1. CM实体向MM实体发送业务请求，要求MM向网络发送CM业务请求；

2. MM实体向RRC实体发出建立MM连接请求；

3. 没有RR/RRC信令连接时，RRC实体发送连接建立请求；

4. 建立后，RRC实体发送包含CM Service Request的信令数据。(谷歌专利)

对A—E的贡献

• A：最强文献之一。 明确公开终端内部CM/MM实体生成、处理服务请求并驱动RRC层。

• B：仅有传统CM业务请求。

• **C：公开RRC连接建立请求，但没有具体EC。

• D：较强结构性启示。 NAS/MM服务请求直接触发RRC连接建立。

• E：未公开。

C6对“NAS层装置—AS/RRC层装置”的终端协议栈结构具有重要补强作用。

C7：CN101335924A

名称： 非接入层消息传输方法、装置及系统
申请人： 中兴通讯股份有限公司
公开日： 2008年12月31日
类型： 中国原始申请；目标专利直接审查引证

这是截止日前中文文献中，与EPS NAS协议架构最接近的文件。

关键披露

文献明确公开：

• UE与MME之间通过NAS消息完成移动性管理和会话管理；

• EPS NAS至少包括EMM和ESM类型；

• NAS消息中的message type可以表示附着请求、连接请求等；

• 信息元素用于标识消息具体内容；

• NAS消息发送装置包括“设置模块”和“发送模块”。(谷歌专利)

Google Patents明确将CN101335924A列为CN102356691B的审查员引证。(谷歌专利)

对A—E的贡献

• A：较强结构性公开。 EPS NAS消息的设置和发送装置已存在。

• B：较弱部分公开。 有连接请求类NAS消息和信息元素，但没有ESR及CSFB service type。

• C、D、E：未公开。

C7的主要价值不是独立覆盖权利要求，而是把传统UMTS文献中的NAS/RRC机制桥接到EPS NAS装置环境。

C8：CN1835629A

名称： 一种呼叫连接建立方法
申请人： 华为技术有限公司
公开日： 2006年9月20日
类型： 中国原始申请

关键披露

文献把以下消息合并：

• RRC Connection Request；

• CM Service Request；

• SETUP。

CM Service Request和SETUP形成的立即指配消息内容，被包含在主叫UE发送的RRC Connection Request中，从而在完成RRC连接建立之前即把NAS呼叫信息提供给网络。(谷歌专利)

对A—E的贡献

• A：较强公开。

• B：部分公开。

• **C：仅公开RRC请求，没有明确EC。

• D：结构性贡献。 证明NAS呼叫请求内容可在形成RRC请求时同时存在。

• E：未公开。

四、辅助中文专利

C9：CN101189891A

名称： 无线定位系统中基于定位的服务应用的高级触发信号
公开日： 2008年5月28日

文献明确公开：移动设备发送CM Service Request，该请求包括CM service type，且该service type指示服务是为移动发起呼叫而请求。它对A以及B中的“服务请求消息携带MO service type”具有较强上位贡献，但属于GSM场景，不涉及RRC EC。(谷歌专利)

C10：CN1656707A

名称： 无线网络中信号连接允许控制
公开日： 2005年8月17日

文献公开RRC Connection Request中的建立原因，并以“始发对话呼叫”为例，网络根据建立原因预测资源需求和接入负载。它是C特征的稳固补强文件。(谷歌专利)

C11：CN101212722A

名称： 无线基站控制站、移动通信系统及其优先小区选择方法
公开日： 2008年7月2日

文献公开，UE的第一个RRC连接请求可以同时指示：

• 将由UE启动的服务类型；

• 建立原因；

• UE能力和协议版本。

RNC根据服务类型和建立原因进行小区及资源处理。该文献不能证明NAS service type生成EC，但能证明在RRC建立阶段联合考虑业务类型和EC已经存在。(谷歌专利)

C12：CN101227677A

名称： 一种单无线信道语音业务连续性的域切换方法
公开日： 2008年7月23日

文献公开LTE/SAE网络与CS域之间的语音业务连续性和切换。它只能补强“目标日前LTE/SAE与传统CS语音业务互操作已经是明确技术方向”，不能直接公开ESR、CSFB service type或RRC EC映射。(谷歌专利)

五、A—E特征比对表

符号说明：

• ●：直接或基本明确公开；

• ◐：高度相关的部分公开、旧制式对应或功能性对应；

• △：背景或结构类比；

• —：未发现实质性公开。

特别说明：

• B只有同时公开EXTENDED SERVICE REQUEST + CSFB service type才算完整；

• D只有明确公开“EC基于该NAS消息中的CSFB service type设置”才算完整；

• E要求精确的MO CS fallback → MO data。

注1：C12仅提供LTE/SAE—CS语音互操作背景，不是完整B。

六、逐特征综合判断

特征A：NAS层产生NAS服务请求消息

这一特征的上位概念已经有较强中文专利基础。

• C6明确公开终端CM实体向MM实体提出业务请求，MM实体驱动RRC实体建立连接；

• C2和C8把NAS业务请求直接置入RRC Connection Request；

• C7公开EPS NAS消息设置和发送装置；

• C1、C3、C4、C5和C9均公开UE发送CM Service Request。

因此，A本身很难构成主要创造性来源。其剩余区别主要来自与EPS ESR、CSFB service type及后续EC映射的结合。

特征B：ESR并标识CS fallback service type

截止日前中文专利已经公开：

• Service Request；

• CM Service Request；

• CM service type；

• 移动始发呼叫service type；

• 紧急呼叫service type；

• EPS NAS message type和信息元素；

• LTE/SAE与CS业务互操作。

但本次没有发现一件合格中文公报明确公开：

EPS NAS消息为EXTENDED SERVICE REQUEST，且该消息标识MO CS fallback等CSFB service type。

目标专利本身说明，ESR是EPS中新增、UMTS中没有使用的NAS消息，并认为传统UMTS映射不能直接复制到EPS。(谷歌专利)

因此，完整B仍是第一处实质缺口。

特征C：在RRC Connection Request中设置EC

这一特征已有充分中文专利基础。

C1、C3、C4、C5、C10和C11均直接公开RRC Connection Request及其Establishment Cause。不同EC被用于表示：

• 始发会话呼叫；

• 紧急呼叫；

• 特定快速主叫或PTT业务；

• 其他业务或连接原因。

因此，C本身不应被视为权利要求1的核心创造性贡献。

特征D：EC基于NAS消息所标识的CSFB服务类型

中文专利已经建立了三组重要基础：

1. 业务语义对应

C1明确给出：

• 建立移动始发呼叫 CM service type；

• 始发会话呼叫 RRC EC。

紧急呼叫也采用对应的两层编码。

2. NAS请求驱动RRC连接

C6明确公开CM实体→MM实体→RRC实体的层间请求链。

3. NAS请求在RRC阶段可用

C2和C8明确将NAS业务请求内容封装进RRC Connection Request。

由此可以形成如下创造性论证：

当终端的NAS/MM层已经确定正在请求的业务类型，而且该业务请求在RRC连接请求形成阶段已经可用时，在AS/RRC层设置与业务类型相对应的建立原因，是传统协议机制的自然延伸。

但这仍是一项组合推理。没有合格中文专利明确写出：

AS层从ESR读取CSFB service type，并据此设置RRC EC。

而且，C1、C3、C4、C5中的传统流程通常是RRC请求在前、CM Service Request在后。正式论证时，应使用C2、C6或C8补足层间数据可用性，不能仅以C1单独声称直接公开D。

特征E：MO CS fallback时设置MO data

这是最明显的证据缺口。

截止日前中文专利中的典型映射是：

• 普通MO语音呼叫 → 始发会话呼叫；

• 紧急呼叫 → 紧急呼叫；

• PTT业务 → 特定PTT建立原因；

• 传统CM service type → 建立移动始发呼叫或建立紧急呼叫。

本次没有发现合格中文专利给出：

MO CS fallback → MO data。

更值得注意的是，传统MO语音业务通常对应“始发会话呼叫”，而不是“MO数据”。从传统UMTS文件跨越到EPS后再选择MO data，需要额外技术理由，不能仅凭“业务类型对应EC”的一般原则自然得出。

目标专利说明书也承认：

• UMTS与EPS的EC集合不同；

• UMTS映射不能简单一对一复制；

• 在该方案之前，支持EPS的设备针对CS fallback不存在设置适当EC的机制；

• 其解决方案之一正是针对CS fallback建立新的严格映射。(谷歌专利)

因此，E是目前纯中文专利组合最难跨越的区别特征。

七、建议的无效组合路径

路径一：CN101335924A + CN1937827A + CN1853424A

这是当前最强的中文专利组合。

CN101335924A

提供：

• EPS；

• EMM/ESM NAS体系；

• NAS消息设置与发送装置；

• NAS message type及信息元素。

CN1937827A

提供：

• NAS业务请求；

• NAS业务请求在形成RRC Connection Request时已经存在；

• NAS消息直接封装在RRC请求中。

CN1853424A

提供：

• MO CM service type；

• 对应的MO RRC Establishment Cause；

• 紧急业务类型与EC的另一组对应实例。

可以形成的论证

该组合可以较强地证明：

在EPS NAS装置环境中，由NAS业务请求的业务类别确定或提供相应RRC建立原因，其上位技术思想属于传统NAS—RRC呼叫建立机制的延续。

剩余缺口

仍未直接公开：

1. EXTENDED SERVICE REQUEST；

2. MO CS fallback service type；

3. MO CS fallback → MO data。

因此，该组合主要适合攻击A、C以及D的上位创造性，不足以无争议地填补E。

路径二：CN1980453A + CN1835627A + CN1933656A

CN1980453A

证明终端内部CM/MM/NAS请求驱动RRC连接建立。

CN1835627A

证明RRC Connection Request携带EC，NAS CM Service Request携带业务类型。

CN1933656A

证明同一业务可分别由RRC EC和NAS service type识别，并且业务类型可以影响无线资源侧后续处理。

优势

该组合对“NAS服务类型—AS连接原因—无线资源处理”的协议链条比较完整，并且三件主要文件均为中国原始申请。

弱点

• 主要处于UMTS/WCDMA环境；

• service type是普通、紧急或PTT业务；

• 没有EPS ESR和CSFB；

• 没有MO data选择依据。

路径三：CN1937827A + CN1835629A + CN1853424A

该组合集中解决“传统流程中CM Service Request发送较晚”的问题：

• C2、C8证明NAS业务请求可以在RRC请求阶段提前存在；

• C1提供MO业务类型与RRC EC对应关系。

可以据此主张：

既然NAS服务请求已经被提前形成并置入RRC请求，使用其中的业务属性选择RRC建立原因，属于可以预期的协议实现。

但必须承认，这仍是推导，而非单篇直接记载；并且该推导无法自动确定应选择MO data。

路径四：补充LTE/SAE—CS场景

可在上述任一路径中加入CN101227677A，用于证明目标日前：

• LTE/SAE；

• CS域；

• 语音业务；

• LTE/SAE与CS网络之间互操作

均已进入专利技术方案。

但CN101227677A属于SRVCC/域切换背景，而不是空闲LTE UE发起MO CS fallback的ESR流程。因此，它只能作为应用场景桥接，不能直接填补B、D或E。

八、因公开日晚于截止日而排除的近似中文专利

1. CN101352090A

名称： 无线通信基站装置及呼叫连接方法
CN公开日： 2009年1月21日

该文献仅比截止日晚6天，且技术上非常重要：

• RRC Connection Request中可携带服务设置信息、资源信息和Establishment Cause；

• EC示例包括Mobile originated call；

• 网络既可根据EC，也可根据NAS/第三层消息或直传中的服务信息决定S1连接处理。(谷歌专利)

但按用户要求的CN公报公开日口径，它必须排除，不能因为其优先权日较早而列为2009年1月15日前中文公开。

2. CN101500212A

名称： 分组域用户处理电路域业务的方法、装置及系统
优先权日： 2008年2月1日
CN公开日： 2009年8月5日

该文献直接涉及分组域用户处理电路域业务，但CN公报公开日晚于截止日，不能纳入本次中文现有技术集合。(谷歌专利)

这两件文献说明：

不能把“早优先权、晚中文公开”的文献，直接当作2009年1月15日前已公开的中文专利使用。

九、证据价值排序

十、最终判断

单篇新颖性

本次没有检出一件公开日在2009年1月15日前的中文专利，可以直接、完整覆盖A—E。

最接近整体技术链的任何单篇文献，至少仍缺少：

• EXTENDED SERVICE REQUEST；

• CS fallback相关service type；

• ESR service type到RRC EC的明确数据依赖；

• MO CS fallback → MO data。

因此，现有中文专利不宜单独作为破坏权利要求1全部新颖性的文件。

创造性

中文专利可以较强地证明以下技术在截止日前已经存在：

• NAS/MM层产生和发送服务请求；

• 服务请求中携带MO、紧急或其他业务类型；

• NAS请求触发RRC连接建立；

• NAS请求内容可在RRC请求形成阶段提前存在；

• RRC Connection Request中设置EC；

• 同一业务语义分别编码为NAS service type和RRC EC；

• EPS NAS设置和发送装置；

• LTE/SAE与CS语音业务互操作背景。

据此，A、C以及D的上位技术思想均存在较强创造性攻击空间。

但目前中文专利组合最终只能较有力地推导：

“根据移动发起CS业务类别选择相应的RRC建立原因。”

仍不能直接推导：

“根据EXTENDED SERVICE REQUEST中的MO CS fallback service type，将EPS RRC EC特定设置为MO data。”

所以，纯中文专利证据链的胜负点仍是E。若要完成对权利要求1的强无效组合，应重点核查2009年1月15日前公开可获得的3GPP TS 24.301、TS 23.272、TS 36.331早期版本、会议提案和CR材料，寻找MO CS fallback → MO data的明确来源或选择动机。目标专利本身也把UMTS NAS过程到RRC EC的映射描述为已知背景，但同时强调ESR及CSFB到EPS EC的映射问题尚未解决；正式无效理由中应把“已知的一般映射机制”和“缺失的特定MO data映射”严格区分。(谷歌专利)

以上为基于Google Patents的专利技术检索与特征分析，不构成中国专利无效程序的法律意见。

CN102356691B权利要求1：3GPP现有技术检索与特征比对

以下按照用户指定的严格截止日——2009年1月15日之前，不含当日进行分析。CN102356691B及其PCT家族记载的最早优先权日为2009年1月15日；授权权利要求1的核心正是A—E所列“NAS扩展服务请求—CS回退服务类型—RRC建立原因”映射。(谷歌专利)

本报告是专利与标准文献的技术检索分析，不代替中国专利无效程序中的法律意见。尤其需要说明：本次未进一步核查两份美国临时申请对授权权利要求1各技术特征的书面支持情况。

一、检索结论

1. 截止日前，尚未直接核实到一篇同时公开A—E全部特征的3GPP文献

截至目前能够直接核实的2009年1月15日前材料，已经分别公开：

• A、B：NAS服务请求程序中发送EXTENDED SERVICE REQUEST，并在其中携带“mobile originating CS fallback”等服务类型；

• C：AS层构造RRCConnectionRequest，其中的establishmentCause根据上层提供的信息设置；

• D的一般原理：NAS/MM过程类型用于选择或向AS提供RRC建立原因；

• E中的候选值：RRC建立原因枚举已经包括mo-Data。

但尚未在一篇经直接核验的截止日前文献中找到规范性语句：

mobile originating CS fallback → mo-Data

因此，当前材料更适合以创造性无效为主线，而不是以单篇文献破坏新颖性为主线。

2. 最强的创造性组合

建议的核心组合是：

D1：24.301截止日前草案/会议稿
＋ D2：TS 36.331 V8.3.0
＋ D3：C1-083834
辅以 D4：TS 24.008 V8.3.0 和 D5：TS 23.272 V8.2.0

其中：

• D1负责A、B；

• D2负责C，并公开mo-Data这一可选建立原因；

• D3用于连接NAS服务类型与向AS提供RRC建立原因；

• D4证明“根据NAS过程类型选择RRC建立原因”是既有机制；

• D5证明MO CS回退的标准流程和服务请求触发背景。

3. 特征E是决定性争点

能够直接核实的、明确写出下述映射的3GPP规范，是截止日后的TS 24.301 V8.1.0：

该表通过CR 0027 rev.2、文稿C1-091298在CT1#57处理，并于2009年3月进入V8.1.0，晚于2009年1月15日，不能直接作为现有技术使用。(3GPP门户)

它的重要作用是作为时间序列控制证据：说明精确映射E在正式规范中的可核实落点晚于优先权日，也反向说明无效请求中不能仅以V8.1.0的文字倒推V8.0.0已经公开相同内容。

二、重点文献及其无效贡献

D1：C1-085191、C1-085520、24301-120-CL及TS 24.301 V8.0.0

公开时间链

• C1-085191题为“Pseudo-CR on introduction of Extended Service Request”；

• C1-085520为其修订稿；

• 官方3GPP档案显示两份文稿均在2008年11月17日进入会议档案；

• 草案24301-120-CL/24301-120.zip的档案时间为2008年11月25日；

• TS 24.301 V8.0.0的3GPP归档包时间为2008年12月18日。(3GPP)

需要注意：TS 24.301 V8.0.0的ETSI正式镜像晚于截止日，因此无效程序中主张其截止日前公开，应以3GPP会议稿、FTP目录、TDoc清单和会议记录形成证据链，而不应只提交后来的ETSI PDF。

直接公开内容

V8.0.0已经明确：

1. 当UE发起MO CS回退时，启动服务请求程序；

2. UE发送EXTENDED SERVICE REQUEST；

3. 该消息具有必选的Service type信息元素；

4. 服务类型编码0000表示“mobile originating CS fallback”，另有MT CS回退和MO紧急CS回退等值。(ETSI)

因此，D1对A、B具有最强贡献。

但V8.0.0中尚未直接核实到：

• 由该服务类型决定RRCConnectionRequest.establishmentCause；

• MO CS回退必须映射到mo-Data。

关于特征B的解释问题

3GPP规范把EXTENDED SERVICE REQUEST作为服务请求程序中发送的NAS消息。权利要求中的“NAS服务请求消息包括扩展服务请求”如果按说明书和标准语境理解为“服务请求类NAS消息为EXTENDED SERVICE REQUEST”，D1能够直接覆盖。

若专利权人将“包括”解释成一个NAS消息在字面上嵌套另一个完整消息，则需要先通过说明书、审查历史和标准语境固定权利要求解释。

D2：3GPP TS 36.331 V8.3.0

TS 36.331 V8.3.0在ETSI目录中的公开时间为2008年10月31日，早于截止日，公开证据强度较高。(ETSI)

该版本明确：

• UE在AS层执行RRC连接建立；

• RRCConnectionRequest包括establishmentCause字段；

• 该字段按照从上层收到的信息设置；

• 建立原因枚举包括：

  • emergency

  • highPriorityAccess

  • mt-Access

  • mo-Signalling

  • mo-Data。(ETSI)

因此，D2直接公开：

• 特征C；

• NAS/上层向AS提供建立原因信息的接口方向；

• 特征E中的目标枚举值mo-Data。

但D2本身不公开：

• EXTENDED SERVICE REQUEST；

• CS回退服务类型；

• 依据“MO CS fallback”选择mo-Data的具体映射。

D3：3GPP C1-083834

C1-083834题为：

“P-CR on 24.301: Provision of RRC establishment cause values by EPS NAS”

官方TDoc清单将其列为Samsung提交的pseudo-CR并记载处理结果为agreement；3GPP档案时间为2008年10月13日，会议为CT1#55bis。(3GPP)

这份文献在无效组合中极其重要，因为从标题和后续标准演进看，其技术主题正是：

由EPS NAS确定、提供RRC建立原因值。

但对该文献必须作证据上的严格区分：

1. 本次检索能够核实官方目录、标题、来源、会议状态和归档时间；

2. 3GPP服务器未能在当前检索环境中展开该压缩包正文；

3. 后来的EPO授权文本将其概括为：NAS根据CS回退服务类型确定RRC建立原因，并向AS提供；(欧洲专利局数据)

4. 同一专利家族原始说明书的背景部分又称，该既有建议只给出一般NAS过程到RRC建立原因的映射，未解决CS回退及EXTENDED SERVICE REQUEST的情况。(欧洲专利局数据)

两种后续表述存在明显张力。因此，现阶段最稳妥的定位是：

• C1-083834能够有力支持“由NAS确定并向AS提供RRC建立原因”这一桥接原理；

• 不能在未取得原始两页正文前，将其表述成已经直接公开特征B或特征E；

• 原始C1-083834是下一步最优先固定的证据。

D4：3GPP TS 24.008 V8.3.0

TS 24.008 V8.3.0的ETSI公开时间为2008年10月21日，早于截止日。(ETSI)

其规范性附录L已经采用了“根据NAS/MM过程或业务类型选择RRC建立原因”的机制。例如：

• 发起CS语音呼叫、CS数据呼叫，对应“Originating Conversational Call”；

• CS紧急呼叫对应“Emergency call”；

• MO SMS对应“Originating Low Priority Signalling”。(ETSI)

D4并非EPS/LTE中的mo-Data直接映射，原因名称和无线接入体系也不同，但它对创造性组合的意义很强：

• 证明“NAS业务类型决定RRC建立原因”不是本专利首次提出；

• 证明对MO CS语音/数据业务，既有3GPP设计倾向于按业务特性选取建立原因，而不是一律作为普通信令；

• 为从MO CS回退业务选择mo-Data提供技术动机。

D5：3GPP TS 23.272 V8.2.0

TS 23.272 V8.2.0的ETSI目录时间为2009年1月7日，明确早于截止日。(ETSI)

该版本的MO CS回退流程公开：

• UE因发起CS业务而触发CS fallback；

• UE向MME发送带CS Fallback Indicator的Service Request；

• Service Request通过RRC消息以及S1-AP被传递；

• 网络随后启动向GERAN/UTRAN的回退过程。(ETSI)

D5对A、B只有部分贡献，因为其Stage 2流程文字未直接使用24.301中的完整EXTENDED SERVICE REQUEST + Service type消息格式；但它是证明以下内容的重要背景文献：

• CS回退是服务请求的触发场景；

• NAS请求与RRC连接建立处于同一完整流程；

• MO CS业务在建立RRC连接后将进入CS接入网络继续呼叫。

D6：RAN2建立原因及CS回退会议文稿

检索还定位到：

• R2-082400：“Summary of email discussion on Establishment cause values”，档案时间2008年4月29日；

• R2-082492：“RRC Enhancements to support CS fallback”；

• R2-083936：“Remaining RAN2 issues for CS fallback”等。(3GPP)

这些材料可以用于证明：

• RRC建立原因的枚举和语义是RAN2在2008年已经讨论、固定的问题；

• CS fallback需要相应RRC增强；

• NAS/AS之间的原因传递具有明确的标准化背景。

但目前没有从这些文稿中直接核实出“MO CS fallback→mo-Data”，因此宜作为技术常识和组合动机材料，不宜作为特征E的直接公开证据。

三、权利要求1逐特征比对表

符号说明：

• ●：直接、明确公开；

• ◐：部分公开或公开一般原理；

• △：只有标题、后续概括或尚待原文核实；

• —：未见公开。

分特征评价

特征A

由D1直接覆盖；D5进一步确认MO CS回退的服务请求触发和传送流程。

特征B

由D1直接覆盖。尤其是EXTENDED SERVICE REQUEST的服务类型字段和“mobile originating CS fallback”编码，已在截止日前草案/会议文稿链中出现。

特征C

由D2直接覆盖。该文献明确规定AS层在RRCConnectionRequest中设置establishmentCause，并按照上层提供的信息赋值。

特征D

D2只公开“根据上层信息设置”；D3和D4公开或强烈指向“NAS过程决定/提供建立原因”。将D1的CS回退服务类型输入D3/D4的映射机制，能够较自然地得到D。

但若需要破坏新颖性，必须在同一篇文献中找到这种连接；现有直接核验材料尚不足。

特征E

这是唯一未被截止日前文献直接、明确覆盖的限制。

已知截止日前技术人员面对的候选至少包括：

• mo-Signalling：因为LTE侧最初建立连接的直接目的，是发送信令以启动CS回退；

• mo-Data：因为该过程最终服务于MO CS语音/数据业务，需要转入CS接入网继续呼叫。

专利说明书自身也承认，对MO CS回退可以考虑使用“MO signalling”或者“MO data”。这既可被无效方用于主张“有限选项中的常规选择”，也可被专利权人用于说明不存在唯一、必然的选择。(谷歌专利)

四、建议的创造性无效论证路径

路径一：D1作为最接近现有技术

D1已经公开：

• NAS服务请求程序；

• EXTENDED SERVICE REQUEST；

• MO CS fallback服务类型。

与权利要求1相比，区别集中在：

1. AS层设置RRC建立原因；

2. 该原因基于NAS中的CS回退服务类型；

3. MO CS fallback具体选择mo-Data。

路径二：用D2补足AS设置机制和mo-Data候选

D2明确要求RRCConnectionRequest.establishmentCause根据上层信息设置，并给出mo-Data枚举。

技术人员在实施D1的MO CS回退服务请求时，必然需要按照D2为RRC连接请求赋予一个合法建立原因。D1与D2属于同一EPS UE的相邻协议层，组合具有较强的接口和功能关联。

路径三：用D3或D4补足“NAS决定/提供原因”的桥梁

D3的主题本身就是“由EPS NAS提供RRC建立原因值”；D4则明确给出传统3GPP系统中依据NAS业务过程选择RRC建立原因的规范性映射。

由此可提出客观技术问题：

对于由NAS层的MO CS回退扩展服务请求触发的RRC连接，应当如何从36.331允许的原因值中选择并向AS提供一个适当的建立原因？

路径四：论证mo-Data属于有限候选中的常规选择

对无效方有利的理由包括：

• mo-Data在D2中已经是既定枚举，而非专利新创的原因值；

• D4把发起CS语音/数据业务与“发起会话类业务”的RRC原因相关联，而不是简单归入低优先级信令；

• MO CS fallback的最终目的正是建立MO CS语音或数据业务；

• 专利自身承认mo-Signalling和mo-Data均为可用候选，说明争议主要是标准化策略选择，而非创造一个新的技术机制。

该路径的主要风险

不能仅凭“后来标准最终选择了mo-Data”倒推截止日前必然如此。专利权人可以反驳：

• 在LTE侧建立RRC连接时，尚未承载CS语音用户面；

• 该RRC连接直接承载的是触发回退的NAS信令；

• 因而mo-Signalling同样具有技术合理性；

• V8.1.0直到2009年3月才规范化精确映射，反而说明此前存在选择不确定性。

所以，创造性论证能否达到较高强度，关键不在于A—D，而在于能否证明：

本领域技术人员在2009年1月15日前，有充分动机把MO CS fallback归入mo-Data，并且该选择不需要创造性劳动。

五、新颖性与创造性的证据评价

新颖性

依据目前直接核实的文献，不建议把单篇文献破坏新颖性作为主攻方向，原因是没有一篇截止日前文献直接、无歧义地覆盖特征E。

例外是：如果取得C1-083834原始正文后发现其中已经包含完整的EXTENDED SERVICE REQUEST映射表，特别是MO CS fallback→MO data，则应立即重新评估其作为单篇X类文献的可能性。

创造性

创造性组合具有实质基础：

D1＋D2＋D3
或
D1＋D2＋D4＋D5

其中A—D的组合逻辑较强，E可以构造成：

• 已知枚举中的选择；

• 对既有NAS业务—RRC原因映射原则的直接移植；

• 为使CS回退业务在接入控制、资源调度或业务识别方面得到恰当处理而作出的常规配置。

但应避免以后见之明引用V8.1.0作为选择动机。V8.1.0只能证明后来的标准结果，不能代替截止日前的技术启示。

六、证据固定的优先次序

第一优先：取得C1-083834原始两页正文

应从3GPP原始档案中固定：

• C1-083834.zip；

• 解压后的Word/PDF原件；

• ZIP和内部文件的哈希值；

• FTP目录时间戳；

• CT1#55bis会议TDoc清单；

• 会议报告中对该文稿的讨论和“agreement”记录。

这是决定D和E证据强度的首要材料。

第二优先：固定24.301截止日前草案链

建议同时固定：

• C1-085191；

• C1-085520；

• 24301-120-CL或24301-120.zip；

• 24301-800.zip；

• CT1#56会议报告；

• 各版本之间的红线对比。

由于V8.0.0的ETSI镜像晚于截止日，不能只提交后来的ETSI版本，而应证明相同实质内容已通过公开的3GPP会议稿或FTP档案向公众开放。

第三优先：制作V8.0.0与V8.1.0的逐条差异表

重点对比：

• V8.0.0中的服务请求程序、ESR消息及服务类型；

• V8.1.0新增的NAS过程—RRC建立原因附录；

• CR 0027 rev.2具体增加的行；

• C1-083834与C1-091298之间的继承和修改关系。

该差异表有助于回答：精确映射E究竟是2008年已经公开但尚未入版，还是2009年才首次提出。

七、最终意见

综合当前检索结果：

1. A、B已被2008年24.301草案和相关CT1会议文稿直接公开。

2. C以及mo-Data原因值已被2008年10月公开的36.331 V8.3.0直接公开。

3. 根据NAS过程选择或提供RRC建立原因的原则，已由C1-083834和24.008 V8.3.0公开或强烈提示。

4. MO CS回退的整体业务流程，已由2009年1月7日前公开的23.272 V8.2.0公开。

5. 尚未直接核实到截止日前文献明确写出E：MO CS fallback→MO data。

6. 精确映射E在可直接核实的正式标准中首次出现于截止日后的24.301 V8.1.0。

7. 因此，现阶段应采用：
   以D1＋D2＋D3为核心的创造性组合，D4、D5作为技术动机和公知映射机制补强；暂不把单篇文献破坏新颖性作为主攻。

8. 无效证据工作的首要任务是取得并固定C1-083834原始正文及其公开证据链。该文件是否已经写出特征E，将直接决定本案能够从“创造性组合”提升到“单篇新颖性攻击”。

一、综合结论

目前检索到的对比文件可以形成一条较完整的创造性无效链条，但尚不足以形成有把握的新颖性无效。

我对权利要求1的当前无效成功率评估为：

这里的“概率”是基于现有证据完整性、组合数量、区别特征强弱及可能抗辩作出的诉讼风险区间，不是统计概率。

一句话结论：A—C基本已经解决，D可以通过3GPP跨层机制解决，E是决定性瓶颈。

二、权利要求1的实质性技术特征

为便于比对，将权利要求1整理为：

从无效角度看，A和B属于NAS层，C属于RRC层，D是NAS到RRC的跨层关联，E则是一个非常具体的映射规则：

MO CS fallback → mo-Data

三、主要对比文件及作用

D1：3GPP TS 24.301 V8.0.0

3GPP官方归档时间为2008年12月18日，早于2009年1月15日。该版本规定UE在移动发起CS fallback时发送Extended Service Request，且Extended Service Request包含强制性的Service type信息元素；Service type编码“0000”对应“MO CS fallback”。(3GPP)

但是，V8.0.0中没有找到“establishment cause”“mo-Data”或“mo-Signalling”的对应映射规则。(ETSI)

因此：

• A：直接公开；

• B：直接公开；

• C—E：未直接公开。

D1是最适合的最接近现有技术。

D2：3GPP TS 36.331 V8.3.0

3GPP官方归档时间为2008年9月18日。该文件规定：

• UE建立RRC连接时发送RRCConnectionRequest；

• UE按照上层提供的信息设置establishmentCause；

• establishmentCause枚举值包括mo-Signalling和mo-Data。(3GPP)

该规范还分别提到“mobile originating calls”和“mobile originating signalling”，说明3GPP在接入控制语境下区分“发起呼叫”与“发起信令”。(ETSI)

因此：

• C：直接公开；

• D：部分公开，即EC依据上层信息设置；

• E：只公开了右侧的mo-Data选项，没有公开“MO CS fallback→mo-Data”的具体映射。

D3：3GPP C1-083834

3GPP官方会议资料将C1-083834列为：

“P-CR on 24.301: Provision of RRC establishment cause values by EPS NAS”

会议列表显示其在2008年10月提交并获得同意，时间早于截止日。(3GPP)

该文献最重要的价值是证明：

EPS NAS不是仅触发RRC连接，而是可以根据NAS过程向RRC提供相应的RRC establishment cause。

但是，目标专利说明书自身对C1-083834的描述表明：该提案没有解决CS fallback，也没有考虑后来引入的Extended Service Request。(谷歌专利)

因此，C1-083834适合用于补强D，但无法单独补足E。

还需要注意：目前已经核实了官方标题、会议时间和同意状态，但尚未取得并逐段核对C1-083834原始正文。因此，在正式无效请求中，不能仅依赖标题推断全部技术内容。

D4：3GPP TS 24.008 V8.3.0

该版本的3GPP官方归档时间为2008年9月24日。其规范性附件规定，当MM请求建立无线资源连接时，应当根据CS NAS过程选择RRC establishment cause；其中移动发起的CS语音或数据呼叫对应“Originating Conversational Call”，而MO SMS对应信令类原因。(3GPP)

它不能直接公开E，因为：

• 它针对的是较早的UTRAN/Iu体系；

• 使用的是“Originating Conversational Call”，不是LTE的mo-Data；

• 没有Extended Service Request和MO CS fallback服务类型。

但它提供了重要的组合动机：

当NAS正在为移动发起CS呼叫建立接入连接时，RRC cause通常反映底层呼叫/业务性质，而不只是反映当前承载该请求的NAS信令消息。

这是目前对E最有价值的辅助证据之一。

P1：US20050090224A1

该专利公开于2005年4月28日。其披露UE发送CM Service Request，其中服务类型表示“mobile originating call establishment”；对于非紧急移动发起呼叫，UE使用与“originating conversational call”相应的RRC establishment cause。(谷歌专利)

它与TS 24.008的作用相似：

• 不能直接公开“MO CS fallback→mo-Data”；

• 但可以证明在既有移动通信实践中，移动发起呼叫通常映射为呼叫/业务类RRC cause，而不是单纯的信令类cause。

在D4证据链完整时，P1的必要性较低；D4不足或受到公开性攻击时，P1可以作为替代或补强。

四、特征比对表

符号说明：

• ●：直接、明确公开；

• ◐：部分公开、隐含公开或仅能提供组合启示；

• —：未公开。

分特征证据强度

这些概率不能相乘。实际案件结果主要由E控制。

五、最优无效组合

最优主组合

D1：TS 24.301 V8.0.0

＋D2：TS 36.331 V8.3.0

＋D3：C1-083834

这是最适合作为正式创造性无效理由主线的组合。

1. 最接近现有技术

选择D1 TS 24.301 V8.0.0。

理由是D1与涉案权利要求具有相同的：

• EPS NAS环境；

• Extended Service Request；

• CS fallback目的；

• Service type信息元素；

• “MO CS fallback”服务类型。

相对于其他文件，D1所需补充的区别最少。

2. 区别特征

D1与权利要求1的主要区别为：

• 在AS层设置RRCConnectionRequest的EC；

• EC依据NAS服务类型确定；

• MO CS fallback对应mo-Data。

其中前两项可由D2、D3较强地补足，真正剩余的核心区别是：

MO CS fallback与mo-Data之间的具体映射。

3. 客观技术问题

建议将客观技术问题表述为：

在MO CS fallback的Extended Service Request触发RRC连接时，如何利用已有的RRC establishment cause机制，使接入层向网络反映本次接入所对应的业务性质。

不建议把技术问题表述成：

如何将MO CS fallback映射为mo-Data。

后一表述已经把区别特征包含在技术问题中，容易被认定为事后分析。CNIPA关于创造性三步法的解释同样强调，重新确定的技术问题不应包含对区别特征的指引。(国家知识产权局)

4. 结合启示

D2明确告诉本领域技术人员：

• establishmentCause由上层信息决定；

• 候选原因包括mo-Signalling和mo-Data。

D3进一步告诉本领域技术人员：

• EPS NAS应根据NAS过程向RRC提供EC值。

因此，在D1的MO CS fallback流程中，本领域技术人员有动机从D2所列cause中选择一个与该NAS业务相匹配的值。

5. E的推导

无效方应当强调：

1. MO CS fallback的真实业务目的是建立移动发起CS呼叫，而不是单纯完成一项独立NAS信令事务；

2. D2将“mobile originating calls”与“mobile originating signalling”区分；

3. 在D4所反映的既有3GPP实践中，移动发起CS语音/数据呼叫使用呼叫或业务类RRC cause，MO SMS等纯信令业务才使用信令类cause；

4. 因此，将MO CS fallback归入mo-Data，属于在既定有限cause集合中按照业务性质进行的常规选择，而不是新的协议结构。

这条论证有一定说服力，但仍然是创造性推导，不是直接公开。

六、增强组合

D1＋D2＋D3＋D4

这是当前证据下攻击力度最强的完整组合。

建议将D4定位为：

用于证明本领域技术人员选择mo-Data而不是mo-Signalling的技术动机和既有协议习惯。

不建议简单表述为D4“直接公开了E”，因为它采用不同RAT和不同cause名称。

专利替代组合

在D4的公开性、版本或证据形式受到质疑时，可提出：

D1＋D2＋D3＋US20050090224A1

US20050090224A1能够提供具体终端实现层面的“MO call service type→呼叫类RRC cause”佐证，但其规范性和与LTE/EPS的接近程度低于TS 24.008，因此应列为替代方案，而不是第一主组合。

七、为什么该无效组合可能成功

1. 三份核心文件属于高度关联的协议体系

D1和D2分别属于同一Release 8体系下相邻的NAS层和RRC层，D3直接处理EPS NAS向RRC提供建立原因的问题。将三者结合，不是跨越不相关技术领域拼凑。

2. A、B、C均为明确公开

争议并不在系统架构、消息名称或字段存在性，而只在一个字段值映射上。权利要求相对于现有标准体系增加的技术内容较窄。

3. 可选值数量有限

在普通移动发起场景下，与争议最相关的主要候选值就是：

• mo-Signalling；

• mo-Data。

无效方可以主张：在缺乏特殊技术效果的情况下，从有限候选值中按照业务性质完成映射，属于协议表格的常规完善。

4. 既有标准实践倾向于按底层业务分类

TS 24.008和US20050090224A1均表明，移动发起CS呼叫所使用的RRC cause反映的是呼叫/业务性质，而不是仅仅因为当前传输的是一条请求信令就归类为信令原因。(ETSI)

5. 目标专利自身承认存在两种候选选择

目标专利背景部分指出，对于由MO CS call触发的服务请求，可以考虑mo-Signalling或mo-Data。(谷歌专利)

这一记载：

• 对新颖性无效方帮助不大，因为它不是截止日前现有技术；

• 但可以用于反驳“存在复杂技术障碍”或“只有一种不可预见方案”的主张；

• 也可以说明争议本质更接近协议值选择，而不是新的信令机制。

八、为什么该无效组合也可能失败

1. 没有一份截止日前文件直接公开E

D1公开“MO CS fallback”，D2公开mo-Data，但二者分别只是映射关系的左右两端。

按照新颖性的单独对比原则，不能把两份文件拼接为单篇公开；标准相关特征原则上也要求能够从文件中直接、无歧义地确定。(国家知识产权局)

因此，新颖性理由基本不应作为主攻方向。

2. mo-Signalling同样具有表面合理性

专利权人会主张：

• Extended Service Request本身是一条NAS信令消息；

• CS fallback需要先通过信令触发网络侧流程；

• 因此本领域技术人员并不必然选择mo-Data；

• 至少存在mo-Signalling和mo-Data两个合理方向。

这会直接否定“唯一、必然推导”，并削弱E的显而易见性。

3. C1-083834没有解决CS fallback

目标专利对C1-083834的描述已经明确指出，原有映射未考虑Extended Service Request和CS fallback。专利权人会据此主张：从一般NAS过程映射跨越到新引入的CS fallback服务类型，需要新的技术判断，而不是机械套用。(谷歌专利)

4. D4使用不同cause体系

TS 24.008的“Originating Conversational Call”不等于LTE中的mo-Data。专利权人可以强调：

• UTRAN与E-UTRAN的cause分类不同；

• “conversational call”强调QoS或呼叫性质；

• mo-Data在LTE中可能具有不同的接入控制含义；

• 不能仅凭名称相似完成一一替换。

5. 精确规则是在优先权日后进入标准

3GPP记录显示，涉及TS 24.301后续修改的C1-091298/CR 24.301-0027在2009年后续会议中被处理，并进入后续V8.1.0体系。该文件不能作为2009年1月15日前的现有技术。(3GPP Portal)

专利权人会据此主张：

截止日前标准尚未确定该映射，后来专门通过CR增加规则，反而证明E不是既有标准内容。

无效方可以反驳“后续标准化不等于具有创造性”，但不能将后续CR反向作为截止日前公开证据。

6. 多篇组合存在事后拼接风险

当无效理由需要：

• D1取得MO CS fallback；

• D2取得mo-Data；

• D3取得跨层传递；

• D4取得历史映射惯例；

专利权人很容易主张，无效方是看到权利要求后才从不同层次和不同RAT的文件中挑选元素。

因此，正式无效理由必须把组合逻辑写成一条自然的工程路径，不能仅罗列“各文件分别公开某一特征”。

九、现有专利文献的相对价值

WO2008148432A1虽然公开于截止日前并涉及CS fallback，但未提供RRC establishment cause映射，因此其价值明显低于D1。(谷歌专利)

WO2008084316A1能够证明CS业务与“conversational call”类RRC cause的关系，但仍属于旧体系类比。(谷歌专利)

十、最终推荐的无效理由排序

第一无效理由：创造性

D1 TS 24.301 V8.0.0作为最接近现有技术
＋D2 TS 36.331 V8.3.0
＋D3 C1-083834

主张：

• D1公开A、B；

• D2公开C以及“上层信息→EC”和mo-Data；

• D3提供EPS NAS过程向RRC提供EC的明确结合动机；

• 将MO CS fallback按底层移动发起呼叫业务归入mo-Data，是在有限cause集合中的常规协议映射。

第二无效理由：增强创造性

D1＋D2＋D3＋D4 TS 24.008 V8.3.0

增加主张：

• 既有3GPP协议已经形成按照CS NAS业务性质选择RRC cause的惯例；

• 移动发起CS呼叫使用呼叫/业务类原因；

• 因此选择mo-Data而非mo-Signalling具有明确技术启示。

第三无效理由：专利文献替代增强

D1＋D2＋D3＋US20050090224A1

用于应对D4证据形式或不同标准版本的争议。

不建议作为主理由

• D1＋D2的新颖性；

• 将TS 23.272作为最接近现有技术；

• 仅以WO2008148432A1等CS fallback专利与D2组合；

• 使用2009年1月15日之后的CR或TS 24.301 V8.1.0作为现有技术。

十一、最终判断

当前最合理的结论是：权利要求1不存在明显的新颖性缺陷，但存在中等强度的创造性缺陷。

最优组合是：

TS 24.301 V8.0.0
＋TS 36.331 V8.3.0
＋C1-083834
并以TS 24.008 V8.3.0作为E的增强结合证据。

综合成功率评估：

当前约40%～55%，中心值约45%。

决定结果的不是A—D，而是审查合议组是否接受以下判断：

对于以建立移动发起CS呼叫为目的的MO CS fallback，本领域技术人员会按照底层呼叫业务性质选择mo-Data，而不会仅因Extended Service Request本身是信令消息就选择mo-Signalling。

正式提交前，最优先事项是取得并固定C1-083834原始正文、官方会议目录、会议纪要及公开可获得时间证据。若正文中存在更具体的NAS procedure到EC映射表，或者能够找到2009年1月15日前的CT1讨论明确将MO CS call归入mo-Data，整体成功率可提高到约55%～65%。

如权利要求1所述的用户代理设备，其中在所述服务类型是“移动终止MT CS回退”时，所述RRC EC被设置为“MT接入”、“移动发起MO信令”和“MO数据”之一。

如权利要求1所述的用户代理设备，其中在所述服务类型是“移动发起MO CS回退紧急呼叫”时，所述RRC EC被设置为“紧急呼叫”。

如权利要求1所述的用户代理设备，其中所述RRC EC与CS回退服务的给定类型相对应。

如权利要求1所述的用户代理设备，还包括：用于在启动电路交换CS回退服务时在NAS协议层中标识正在启动的CS回退服务的类型并基于正在启动的CS回退服务的类型来确定所述RRC EC的装置。

如权利要求1所述的用户代理设备，还包括：在所述NAS协议层基于所述服务类型确定所述RRC EC并向所述AS协议层提供所述RRCEC的装置。

如权利要求6所述的用户代理设备，其中根据NAS过程向RRC EC的映射来确定基于所述服务类型的RRC EC。

如权利要求1所述的用户代理设备，其中所述NAS服务请求消息是扩展服务请求消息。

一种在演进分组系统EPS中操作的用户代理设备执行的方法，包括：在非接入层NAS协议层中产生NAS服务请求消息，所述NAS服务请求消息包括扩展服务请求并标识与电路交换CS回退相关的服务类型；以及在接入层AS协议层中设置RRC连接请求消息的无线电资源控制RRC建立原因EC，所述EC基于与NAS服务请求消息所标识的CS回退相关的服务类型，其中在产生“移动发起MO CS回退”的服务类型时，将所述RRC EC设置为“MO数据”。

如权利要求9所述的方法，其中在产生“移动终止MT CS回退”的服务类型时，将RRC EC设置为“MT接入”、“移动发起MO信令”或“MO数据”。

如权利要求9所述的方法，其中在产生“移动发起MO CS回退紧急呼叫”的服务类型时，将RRC EC设置为“紧急呼叫”。

如权利要求9所述的方法，其中所述RRC EC与CS回退服务的给定类型相对应。

如权利要求9所述的方法，其中 在启动电路交换CS回退服务时，在NAS协议层中标识正在启动的CS回退服务的类型，并基于正在启动的CS回退服务的类型来确定所述RRC EC。

如权利要求9所述的方法，还包括：在NAS协议层基于所述服务类型确定所述RRC EC，并向所述AS协议层提供所述RRC EC。

如权利要求14所述的方法，其中根据NAS过程向RRC EC的映射，基于所述服务类型来确定所述RRC EC。

如权利要求9所述的方法，其中产生NAS服务请求消息包括产生扩展服务请求消息。