一种计算装置，包括： 处理资源，其操作以提供多个消息接发程序，其中每一消息接发程序可操作以使用不同于所述消息接发程序中的其他消息接发程序的格式和协议来接收传入消息或发送传出消息； 消息接发数据库，其与所述多个消息接发程序对接，以使用所述多个消息接发程序中的任一消息接发程序来记录传入或传出消息的实例； 其中所述处理资源结合维持所述消息接发数据库而执行，以便： 作出针对单个传入消息或传出消息是否存在接发消息线程的确定，所述传入消息和传出消息是经由所述多个消息接发程序中的任一消息接发程序而接收或发送的； 响应于确定针对传入消息或传出消息不存在接发消息线程，为所述传入消息或所述传出消息创建新的消息接发线程； 响应于确定针对传入消息或传出消息的确存在接发消息线程，使所述传入消息或传出消息与现有消息接发线程相关联；且显示每一新的和现有消息接发线程。

## 关于目标专利权利要求1的专利有效性分析意见

致：客户

来自：经验丰富的专利代理师

日期：202X年X月X日

主题：目标专利混合输送消息接发系统有效性分析

作为开场，我已仔细审阅了您提供的目标专利说明书、权利要求1文件，以及六份相关的对比文件（D1-D6）。基于我作为专利代理师的专业经验，现紧密结合目标专利说明书的规定，对权利要求1进行术语解释，并结合对比文件原文进行详细的特征比对和创造性分析，最后指出若提出无效请求时最薄弱的技术特征。

### 第一部分：权利要求术语的解释

根据专利法原则，权利要求的保护范围应当根据说明书及附图来解释。以下紧密结合目标专利说明书的规定，对权利要求1中的关键术语进行界定：

1. **技术特征B中的“格式和协议不同”：**

* **说明书依据：** [0026]段指出，“每一消息接发程序...经配置以使用特定种类的消息接发协议(包含消息接发格式)来发送和接收来自计算装置的消息。”并举例SMS程序、MMS程序与无线运营商资源通信，而IM程序寻找网络侧服务器，使用通信套接字。

* **代理师解释：** 此特征是指消息接发程序并非仅仅是同一协议下的不同客户端（例如两个不同的电子邮件客户端），而是底层通信机制、数据包结构或传输路径存在本质差异。例如，基于电路域的SMS与基于分组域的IM协议（如SIP、XMPP）之间的区别。

2. **技术特征C中的“消息接发数据库...对接...记录记录传入或传出消息的实例”：**

* **说明书依据：** [0028]段指出，“当计算装置...发送或接收消息时，消息数据库140记录或存储所述消息的实例。”且“传出或传入消息...由数据库逻辑142剖析...分析...识别和存储消息信息135...包含对应于...消息输送识别符161，...时间163，或...消息主体165。”

* **代理师解释：** 此处的消息接发数据库并非仅仅是各个独立程序自带的本地存储，而是一个统一的、能够与多个不同协议的消息程序交互，集中存储并剖析所有协议类型消息（无论传入还是传出）的核心数据仓库。

3. **技术特征D中的“接发消息线程（Messaging Thread）”：**

* **说明书依据：** [0014]段定义，“混合输送消息接发线程涉及在用户与另一方之间交换的消息的群集或列表，其中使用不同类型的消息接发输送来传送包含于线程中的消息。群集可表现为聊天或谈话，或以列表形式提供。”表1进一步说明了不同发送者识别符（手机号和IM标记）如何归属于同一个联系人名称下的同一线程。

* **代理师解释：** 权利要求中的“接发消息线程”应理解为**“混合输送（Mixed-Transport）消息接发线程”**。其核心在于，虽然消息通过不同协议（特征B）收发，但数据库资源（特征C和D）能基于特定逻辑（如关联到同一联系人）将它们逻辑上归类为同一个对话序列，而非按协议类型分开显示。

4. **技术特征D中的“作出...确定”、特征E中的“创建新的...线程”、特征F中的“使...与现有...相关联”：**

* **说明书依据：** [0028]段和图2详细描述了剖析传入消息，分析发送者识别符，对照联系人存储库交叉参考以识别匹配联系人，进而确定是否存在针对该联系人的线程。

* **代理师解释：** 这一系列特征构成了“线程化”的核心逻辑。它并非简单的按时间顺序排列所有消息，而是特指：接收消息 -> 剖析识别符 -> 关联联系人 -> 检查该联系人已有线程 -> 归入已有线程或创建新线程。这一自动化逻辑处理过程是实现“混合输送线程”的关键。

---

### 第二部分：特征比对表格及详细出处分析

以下指代对比文件时，D1指US20040054646A1，D2指US20040137884A1，D3指CN1801990A，D4指WO2006108705A1，D5指US20080059587A1，D6指US20080270556A1。

#### 特征比对表格

*注：“√”表示毫无异议公开或实质公开；“-”表示未公开；“+/-”表示存在争议或仅部分公开。*

#### 特征对比及原文出处分析

**1. 前序部分：一种计算装置**

* **实质公开：** D1-D6均公开了计算装置（如PC、移动电话、PDA）。

* **D2原文出处：** [0003] "...wireless mobile phones (also referred to as cellular telephones)..." (无线移动电话（也称为蜂窝电话）)

**A. 包括：处理资源，其操作以提供多个消息接发程序，**

* **毫无异议公开：** D2、D5、D6均明确公开。D1公开了Email和IM。

* **D2原文出处：** [0017] "...transmitting and receiving email and short message service (SMS) text messages." (...发送和接收电子邮件和短消息服务(SMS)文本消息。)

**B. 其中每一消息接发程序可操作以使用不同于所述消息接发程序中的其他消息接发程序的格式和协议来接收传入消息或发送传出消息；**

* **毫无异议公开：** D1、D2、D5、D6均明确公开了使用不同格式和协议的消息类型（如Email、SMS、IM、MMS）。

* **D2原文出处：** [0024] "Transceiver 276... enable access to several types of communication services including global system for mobile (GSM) voice communications, short message service (SMS) text messaging, simple mail transfer protocol (SMTP) email, and the like. Each type of service may use its own communications format, storage format, user presentation format, as well as response format." (收发器276...能够访问几种类型的通信服务，包括蜂窝系统的语音通信、短消息服务(SMS)文本消息、简单邮件传输协议(SMTP)电子邮件等。每种类型的服务可以使用其自己的通信格式、存储格式、用户呈现格式以及回复格式。)

**C. 消息接发数据库，其与所述多个消息接发程序对接，以使用所述多个消息接发程序中的任一消息接发程序来记录传入或传出消息的实例；**

* **毫无异议公开：** D2、D5、D6实质公开了统一存储不同格式消息。D1偏重联系人地址簿整合。

* **D2原文出处：** [0018] "Embodiments of the present invention provide a single stack or message box for messages in multiple message formats. For instance, rather than having one inbox for calls received, another inbox for voice mail, another inbox for email, and yet another inbox for text messages, embodiments of the present invention list two or more types (e.g. all types) of incoming messages in a single inbox." (本发明的实施例为多种消息格式的消息提供单个栈或消息箱。例如，本发明的实施例不在单个收件箱中列出已接电话、语音邮件收件箱、电子邮件收件箱、文本消息收件箱，而是将两种或更多种类型（例如，所有类型）的来电消息列在一个收件箱中。)

* **分析：** 此处描述的“single stack or message box”实质上公开了一个统一记录所有程序传入传出消息实例的数据库（特征C）。

**D. 其中所述处理资源结合维持所述消息接发数据库而执行，以便：作出针对单个传入消息或传出消息是否存在接发消息线程的确定，所述传入消息和传出消息是经由所述多个消息接发程序中的任一消息接发程序而接收或发送的；**

* **毫不起义公开：** D2、D5、D6明确公开了线程化逻辑。D3和D4侧重于特定协议（如SMS或SIP）内的处理。

* **D2原文出处：** [0040] "...regardless of the messaging protocol used, information is filtered from the message to identify the sender, if possible... The identifying information is compared to the contact records. If a match is found, the message is associated with that contact. So, for instance, all messages from a particular contact can be listed in the unified stack has having been sent from that contact, whether the messages are voice mail notifications, emails, text messages, etc." (...无论使用何种消息协议，都会从消息中过滤信息以识别发送者，如果可能的话...将识别信息与联系人记录进行比较。如果找到匹配项，则消息与该联系人关联。因此，例如，来自特定联系人的所有消息可以列在统一栈中，表明其是从该联系人发送的，无论这些消息是语音邮件通知、电子邮件、文本消息等。)

* **D6原文出处：** Summary部分 "presenting the first message and the second message in a list of stored messages received from or sent to the selected communication device." (将第一消息和第二消息呈现在选自或发送到所选通信装置的存储消息列表中。) 以及[0029]段 "all supported message types are listed in a single view according to the contact that the messages were received from or sent to." (所有支持的消息类型都根据发送或接收消息的联系人列在单个视图中。)

* **分析：** D2描述的识别发送者并将其与联系人记录关联，进而将消息列在统一栈中的过程，实质公开了“确定是否存在消息线程”的处理逻辑，且明确指出了消息可以是Email、SMS等不同格式（满足“经由所述多个消息接发程序中的任一消息接发程序”）。

**E. 响应于确定针对传入消息或传出消息不存在接发消息线程，为所述传入消息或所述传出消息创建新的消息接发线程；**

* **毫不起义公开：** D2、D5、D6实质公开。

* **D2原文出处：** 虽然未明确使用“创建”一词，但[0040]段所述的关联逻辑隐含了这一特征。当一个新的不同识别符（新手机号/Email）未能在已有联系人记录中找到匹配，或者该联系人之前没有消息时，系统必然会开始记录并逻辑上作为一个新的群集显示，这就是创建新的混合线程。

* **D6原文出处：** 图8显示了联系人列表，选择联系人进入图9显示消息列表，这明确暗示了对每一个消息都要检查归属联系人，若为新联系人消息，则构成新的联系人消息列表结构，即创建新线程。

**F. 响应于确定针对传入消息或传出消息的确存在接发消息线程，使所述传入消息或传出消息与现有消息接发线程相关联；**

* **毫不起义公开：** D2、D5、D6明确公开。

* **D2原文出处：** [0040]段“If a match is found, the message is associated with that contact.” (如果找到匹配项，则消息与该联系人关联。) 此处将不同协议消息与联系人关联，实质就是将其归入该联系人的现有“混合输送线程”。

**G. 显示每一新的和现有消息接发线程。**

* **毫不起义公开：** D1、D2、D3、D5、D6均公开。

* **D2原文出处：** [0019]段和图3a、3b明确公开。图3a显示混合消息收件箱，图3b显示特定联系人的统一通信线程（特征G）。

---

### 第三部分：最接近对比文件的创造性分析

在进行创造性分析时，选择合适的“最接近对比文件”至关重要。最接近的对比文件通常应当是属于相同或相近的技术领域，具有最多的共同技术特征，或者能够解决权利要求所解决的技术问题、达到相同的技术效果的文件。

#### 一、最接近对比文件的确定：

根据特征比对表格及详细分析，我认为：**2004-07-15_US2004137884A1 (D2)** 适合做最接近的对比文件。

* **理由如下：**

* **整体解决的技术问题和技术效果：**

* 目标专利：致力于解决用户在小形状因数装置上使用多种不同传输媒体（Email、IM、SMS）时，由于协议和格式不同导致消息分散显示、手动动作多的问题。其技术效果是提供一种统一的、以联系人为中心的混合输送线程呈现。

* D2：明确旨在解决用户不得不浏览不同的收件箱（语音邮件、电子邮件、文本消息）来查找与某人的通信的问题，由于各种通信服务的多样性以及它们具有不同的格式。D2提出的解决方案是提供一个统一的线程化通信，包括不同格式的消息，使用户能够轻松地跟踪通信线程。

* **共同的技术特征：** D2毫无异议地公开了特征B（不同格式协议）、特征C（统一记录所有实例）、特征F（存在则关联现有线程）和特征G（显示线程）。对于特征D和E，D2描述的识别发送者、匹配联系人并将消息归入统一栈的过程，从整体逻辑上构成了“作出确定是否存在线程”和“创建新线程或归入旧线程”的处理过程（正如我在代理师术语解释中界定的），实质公开了这些特征。

#### 二、其他对比文件的分析及补充情况：

虽然D2足以涵盖权利要求1的大部分核心逻辑，为了严谨，仍需分析其他相关文件：

* **D5 (US20080059587A1 - UNIFIED COMMUNICATION ESCALATION)：**

* **公开情况：** D5明确公开了多模式消息线程（特征B和D），允许在Email和IM之间无缝切换回复。图10和[0032]明确描述了多模式消息表结构（实质公开特征C）。[0021]段明确描述了显示包括第一Email、第一IM、第二IM和第二Email的消息序列（特征G）。

* **缺点：** 相比D2，D5更侧重于消息模式在回复时的“升级”或“降级”（根据状态自动选择模式），而D2更侧重于对已有不同来源消息在核心数据层面上的统一整合和线程呈现，D2的技术背景与目标专利更加契合。因此，D5可作为D2的有力补充，但不适合做唯一的“最接近对比文件”。

* **D6 (US20080270556A1 - Contact-based communication threading system)：**

* **公开情况：** D6公开了在便携式消息装置上基于联系人进行消息线程化处理。摘要和图9明确公开了在一个屏幕上（特征G）按联系人聚合Email、IM、手机呼叫、语音邮件等不同类型的消息（特征B、实质公开D和F）。[0028]明确描述了 control button用于选择联系人，Implied公开了数据库存储机制（特征C和E）。

* **缺点：** D6的公开日期为2008年，与目标专利属于同一时代，D2（2004年）在先公开了核心思想，对后序专利更具破坏力。此外，D2不仅提到了多种格式，还提到了“每一服务有其自己的通信格式...以及响应格式”以及“physical storage device”，这比D6的纯概念性描述对“不同协议”和“数据库对接记录实例”的支持更好。因此，D2仍是更优选的最接近对比文件。

* **D1, D3, D4：**

* **D1：** 侧重联系人地址簿整合Email和IM地址，虽然提到了从Email启动IM会话，但未公开核心的“将两种不同来源消息自动线程化归并显示”的数据库逻辑（特征D和F）。

* **D3：** 纯粹侧重于单一协议（SMS）内的线程化和编辑器优化，未公开技术特征B（不同协议）。

* **D4：** 侧重于客户端消息管理器如何避免向网络重复发起SIP订阅（即节省网络带宽），而非核心的“针对不同协议消息实现以联系人为中心的线程化聚合显示”。

### 第四部分：最薄弱的技术特征点

基于我作为经验丰富的代理师对所有对比文件的分析，以及对权利要求1和说明书的界定，我认为如果提出专利无效请求，权利要求1中最薄弱、最具争议、最可能由于不具备创造性而被无效的技术特征在于：

#### **特征D、E、F所构成的自动化“线程化处理逻辑”**

* **理由：**

1. **对比文件的强力破坏性：** 虽然目标专利声称在说明书[0028]描述了剖析识别符、交叉参考联系人、作出决定的过程。但是，**D2 (US2004137884A1)** 在其背景技术[0006]中已经指出了用户需要在多个收件箱（“inbox”和“outbox”）之间反复导航查找与某 party（另一方）的通信的不便。D2在[0040]段中明确指出了“If a match is found, the message is associated with that contact.” (如果找到匹配项，则消息与该联系人关联。) 并进一步明确了“all messages from a particular contact can be listed in the unified stack” (来自特定联系人的所有消息可以列在统一栈中)。这实质上毫无异议公开了特征D和F。对于特征E（创建新线程），如前分析，这是当找不到匹配时必然发生的逻辑处理步骤，不具备任何发明高度。

2. **技术效果的预期性：** 基于D2，将不同来源消息（ Email、SMS）基于公知的发送者/联系人标识符聚合到一起显示，本就是D2明确旨在达到的技术效果。对于本领域技术人员而言，在实现了D2所述的关联逻辑后，将新收到的Email和IM消息在界面上自动作为同一个对话序列的后续内容呈现（技术特征G），完全是可预期的必然结果。目标专利在此并没有引入特殊的算法或解决特殊的聚合难题。

#### **结论**

鉴于权利要求1所解决的技术问题、拟达到的技术效果以及大多数技术特征已被D2、D5和D6充分公开，特别是核心的线程化聚合逻辑处理过程（特征D、E、F）已被D2实质性公开，权利要求1对于本领域技术人员而言是显而易见的，其有效性非常薄弱。

您好，我是您的专利代理师。针对您提供的目标专利权利要求1及其说明书，以及六份对比文件（D1-D6），我进行了深入的法律和技术分析。

以下是我的分析报告。本报告将紧密结合目标专利说明书来解释权利要求，详细比对对比文件原文，指出出处，并在此基础上确定最接近的对比文件，分析创造性，并指出无效请求中最薄弱的技术特征。

---

### 第一部分：权利要求解释

在进行特征比对前，必须结合目标专利说明书对权利要求1进行准确解释，特别是其中涉及的特定术语。

**技术特征A, B (多消息程序、不同协议):**

* **权利要求：**“处理资源……提供多个消息接发程序……使用不同于……格式和协议来接收传入消息或发送传出消息”

* **说明书解释：**说明书[0004], [0014], [0026]明确指出了这些不同的消息接发输送/程序包含：即时消息（IM，如GTALK, AIM, MSN）、SMS协议消息、MMS协议消息，甚至电子邮件（POP3/SMTP）。它们在程序、消息格式以及实施协议上各不相同。

**技术特征C (消息接发数据库):**

* **权利要求：**“消息接发数据库，其与所述多个消息接发程序对接，以使用所述多个消息接发程序中的任一消息接发程序来记录传入或传出消息的实例”

* **说明书解释：**说明书[0028]解释，无论通过哪种程序发送或接收消息，数据库140都会记录消息实例。数据库逻辑142会剖析消息，识别包括发送者/接收者的消息输送识别符161、时间163、消息主体165等信息，并将其存储为数据库记录（如表1所示）。**关键在于，该数据库集中记录了所有不同协议的消息实例。**

**技术特征D, E, F, G (消息接发线程管理):**

* **权利要求：**“处理资源结合维持所述消息接发数据库而执行……作出针对单个传入消息或传出消息是否存在接发消息线程的确定……为所述传入消息或所述传出消息创建新的消息接发线程……使所述传入消息或传出消息与现有消息接发线程相关联……且显示……”

* **说明书解释：**这是目标专利的核心。说明书[0014]定义“混合输送消息接发线程”涉及“在用户与另一方之间交换的消息的群集或列表，其中使用不同类型的消息接发输送来传送包含于线程中的消息”。说明书[0031]-[0034]及表1详细描述了这一过程：数据库逻辑142根据消息识别符（如电话号码或IM标记）对照联系人存储库146交叉参考，将具有不同识别符但属于同一个人的消息（如同一联系人的SMS和IM）关联到同一个线程。**技术特征D中“接发消息线程”的确定是基于数据库逻辑对消息实例的剖析和与联系人信息的整合，而非仅仅基于单一协议的会话标识。**

---

### 第二部分：特征比对表格

以下表格概括了各对比文件（D1-D6）对权利要求1各项技术特征的公开情况。

---

### 第三部分：对比文件详细分析（附原文出处）

在此部分，我将紧密结合对比文件原文，分析其是否毫无异议公开或实质公开了权利要求的技术特征。

#### 1. 对比文件D1: KR100475539B1 (无线即时信使……实时语音传输方法……)

**结论：** D1公开了同一程序内的不同消息类型（文字、语音），但未公开目标专利所指的基于集中数据库的、跨越不同协议程序的混合线程管理。

* **P (装置), A (多程序), B (不同协议): 毫无异议公开**

* **原文出处：** [10], [15], [16]

* **原文：**

* "[10] 本发明是……在无线因特网信使（WIM）中……实时传输语音信息的……”

* "[15] 无线因特网信使终端11、13是通过信使服务器12交换消息和用户状态信息的……终端间的信息交换有限制文字信息的缺点。”

* "[16] ……无线即时消息系统……虽然可以立即和对话方通信，但是交换的信息有局限文字信息的限制。”

* **分析：** D1描述了一个无线信使系统（WIM），它可以在同一信使框架内处理文字和语音（PTT）信息，这属于不同的消息类型，实质公开了技术特征A和B。

* **C (数据库记录实例): 未公开**

* **分析：** D1虽然提到了存储用户信息的“버디(Buddy) 디렉토리 데이터베이스”（Buddy目录数据库，[39]），但该数据库用于管理联系人和状态信息，并非目标专利中用于记录所有不同协议程序传入/传出消息实例的消息接发数据库。D1未公开记录消息实例供后续线程管理使用的特征。

* **D, E, F (线程管理): 未公开**

* **分析：** D1提到了基于“그룹 콜아이디(CALL-ID)”（组呼叫ID，[18],[31]）或“즉시통화 요청”（立即通话请求，[29]）来管理组通话。然而，这种依据CALL-ID的关联仅限于PTT语音会话（或单一即时消息协议内），并非目标专利所述的基于集中数据库、跨越不同协议程序（如SMS和IM）的混合线程管理。D1未公开技术特征D, E, F。

* **G (显示): 毫无异议公开**

* **原文出处：** [37], [62]

* **原文：**

* "[37] ……为了成组进行语音通话，用户在信使提供的버디(Buddy)信息……”

* "[62] ……发送者地址发送到用户状态列表处理部(643)……显示在用户界面(642)……”

* **分析：** D1公开了在用户界面上显示对话者列表和状态信息，毫无异议公开了显示特征G。

#### 2. 对比文件D2: EP1713219A1 / D4: EP1891781A1 / D3: CN101160880A

*注：这三份文件为同族申请或内容高度相似，为简便起见，以下统称为“D2组”，以CN101160880A（D5）为例进行详细比对。*

**结论：** D2组文件完全未涉及消息接发线程管理，其关注的是网络事件订阅消息（如SIP NOTIFY）在不同应用程序（如地址本、IM客户端）间的本地分发。

* **P (装置), A (多程序), B (不同协议): 实质公开**

* **原文出处：** [0014], [0015], [0021]

* **原文：**

* "[0014] 通信设备10提供多个（在当前例子中为3个）应用程序。在当前例子中，应用程序为即时消息（IM）22、地址本24、以及应用n26。”

* "[0015] 应用程序22、24、26……通过消息管理器30传送去向与来自网络50的消息。”

* "[0021] 网络实体60可以为IMS服务器……发送与接收SIP消息。”

* **分析：** D2组公开了一个通信设备，运行多个应用程序（IM, 地址本），这些程序通过不同协议（如SIP）通信。

* **C (数据库记录实例): 未公开**

* **分析：** D2组公开了“订阅表35” [0023]，用于存储消息事件与订阅了该事件的应用程序之间的关联。该表用于分发网络通知（如SIP NOTIFY），而非目标专利所述的集中记录传入/传出消息实例的消息数据库。

* **D, E, F, G (线程管理、显示): 未公开**

* **分析：** D2组的核心是管理消息的本地分发（“通过在应用程序之外管理消息……禁止向与从网络复制相同的SIP消息”，[0017]），完全未涉及根据消息发送者/接收者或联系人信息将不同消息实例组成线程并进行管理或显示的任何特征。其不仅未公开特征D, E, F，也未公开用于用户检视对话的显示特征G。

#### 3. 对比文件D3: US20070116195A1 (用于整合不同通信方法的……)

**结论：** D3公开了整合不同通信方法（Email, IM, SMS）的统一用户界面，用户可以在撰写消息时无缝切换通信方法，并显示参与者状态。虽然D3实现了视觉上的“对话连续性”，但其关注的是**发送时的前端界面切换和内容保存**，而非目标专利核心的**基于后端数据库逻辑对传入/传出消息实例进行自动化线程管理（判断存在->创建/关联）**。

* **P (装置), A (多程序), B (不同协议): 实质公开**

* **原文出处：** [0021], [0022], [0028]

* **原文：**

* "[0021] 桌面计算机101包括集成通信接口102。”

* "[0022] ……可以发送和接收消息……使用各种通信方法。通信方法的例子包括电子邮件（Email），即时消息（IM），短消息服务（SMS）……”

* "[0028] 撰写界面逻辑221包括撰写输入内容209的具有编辑能力的文本输入域208，选定通信方法204（此例中为Email），以及用于选择通信方法204的通信方法选择器205。”

* **分析：** D3实质公开了计算装置，其通过运行不同的消息接发程序/方法（Email, IM, SMS, 视频等）来处理不同格式和协议的消息。

* **C (数据库记录实例): 实质公开**

* **原文出处：** [0046], [0048]

* **原文：**

* "[0046] 参与者表1601包括关联于每个参与者条目1602的信息，包括关联于每个参与者条目1602的通信方法和具体地址列表的CommMethodToAddress表1603。”

* "[0048] D3还描述在用户提供输入内容（如文本、语音）时监视输入内容特征，并在切换通信方法时，“TranslateInputContent subroutine is called… translate the content” [0034]，“content... of the previous MessageContent field is copied or mapped into the new MessageContent field” [0043]。

* **分析：** D3描述了用于管理参与者和地址的表（Participants table, CommMethodToAddress table），实质公开了数据库结构（参与者条目和具体地址列表）。虽然D3侧重于在撰写新消息时保持输入内容（MessageContent），但这隐含了系统对消息内容的临时记录。尽管它未明确强调记录“历史记录消息实例”用于线程化，但其公开的用于无缝切换的数据维持实质上公开了技术特征C。

* **D, F (线程判断、关联): 未公开**

* **分析：** D3虽然描述了撰写消息时切换方法（如从Email切换到IM），但未公开其如何实现对目标专利所述混合线程管理的逻辑：在接收单个消息时，“作出针对单个传入消息或传出消息是否存在接发消息线程的确定”（D），并且“响应于确定……确实存在接发消息线程，使所述传入消息或传出消息与现有消息接发线程相关联”（F）。目标专利的线程化是以后端集中数据库的消息实例记录为基础，由数据库逻辑自动完成的；而D3更像是一种前端UI操作，用户可以通过点击特定联系人或地址来起始会话，或者在撰写消息时主动选择不同的发送路径。D3并未公开技术特征D, F。

* **E (创建新线程): 实质公开**

* **原文出处：** [0007], [0027]

* **原文：**

* "[0007] 根据一种情景，用户可以开始一段对话通过撰写一个即时消息发送给参与者。”

* "[0027] 用户可以通过在Participant Details... 选择 Ed Weber 211... 撰写界面逻辑221将被显示并被配置用于发送消息给关联于该地址的参与者... 使用选定地址（如即时消息地址）。”

* **分析：** 用户选择一个联系人开始会话，实质上对应于“创建新的消息接发线程”，对应目标专利的特征E。

* **G (显示线程): 毫无比议公开**

* **原文出处：** [0023], 图2

* **原文：**

* "[0023] 集成通信接口102包括消息显示，其显示电子消息。”

* **分析：** D3公开了显示消息，如图2和图5A-5D所示，包括参与者列表、撰写界面和显示消息内容的界面，毫无异议公开了显示特征G。

#### 4. 对比文件D6: US20080293403A1 (移动通信服务桥接)

**结论：** D6公开了整合主要IM客户端、SMS、全球通话功能的移动电话服务（EQO Mobile），并在服务数据库中存储用户消息。虽然D6提供了整合界面，用户可以通过联系人列表发起不同类型的通信，但其核心是解决移动语音呼叫和MMS消息的“桥接”（即解决 roaming 和 VoIP 的互通与成本问题），而非目标专利所述的基于数据库逻辑、针对单个消息传入/传出进行自动化混合协议线程管理的逻辑。

* **P (装置), A (多程序), B (不同协议): 毫无异议公开**

* **原文出处：** [0014], [0016], [0032]

* **原文：**

* "[0014] 本发明的一实施例可在于EQO Mobile，……使用户能够拨打全球电话……发送全球文字消息，以及使用所有主要即时消息客户端（诸如MSN Messenger，GoogleTalk，Yahoo，AIM，以及ICQ）进行聊天。”

* "[0016] 优选的用户界面是移动客户端……来自服务地址簿，服务用户可以发起呼叫并发送消息给其他服务和非服务用户，使用所有主要IM网络上的即时消息进行聊天……”。

* "[0032] 各个装置终端2。每个装置终端2优选地为移动通信装置……”。

* **分析：** D6公开了在移动通信装置（计算装置）上运行EQO Mobile客户端，该客户端提供服务地址簿，用户可以通过该地址簿在不同协议程序（电话、SMS、多个IM网络）上接收/发送消息，毫无异议公开了特征P, A, B。

* **C (数据库记录实例): 毫无比议公开**

* **原文出处：** [0048]

* **原文：**

* "[0048] 该服务数据库也充当服务用户消息和服务用户邀请请求的存储。”

* **分析：** D6明确指出服务数据库用于存储用户消息（实质公开了记录传入/传出消息实例），毫无异议公开了技术特征C。

* **D, F (线程判断、关联): 未公开**

* **分析：** 与D3类似，D6提供了一个整合的地址簿，用户可以从中选择不同的通信模式。虽然说明书[0023]提到了多媒体消息的推送和用户“可以回复消息或点击以发起语音或多媒体呼叫给消息发起者”，但这描述的是对单个接收消息的操作（“对单个传入消息……确实存在线程”的确定是暗含在回复操作中的）。然而，D6并未明确描述如何通过数据库逻辑，针对“单次”传入消息或传出消息，跨越“任一协议程序”，执行自动化的“存在判断（D）”和“与现有混合线程关联（F）”的特定逻辑过程。D6主要描述的是基于SMS的通知和多媒体消息推送机制（[0022], [0023]），不涉及目标专利所述的、以后端数据库为基础、针对单个不同协议消息实例进行自动整合线程管理的特征。D6并未公开特征D, F。

* **E (创建新线程): 实质公开**

* **原文出处：** [0016], [0041]

* **原文：**

* "[0016] ……从服务地址簿，服务用户可以发起呼叫并发送消息给其他服务和非服务用户……”

* "[0041] ……用户A可以发起呼叫或多媒体消息给其他服务用户……”

* **分析：** 用户通过地址簿选择联系人或手动添加号码来发起新的呼叫或发送消息，这实质对应于“创建新的消息接发线程”，对应目标专利的特征E。

* **G (显示): 毫无异议公开**

* **原文出处：** [0036], [0041]

* **原文：**

* "[0036] ……应用程序客户端1优选地处理……呼叫请求、在线状态、消息……在装置终端的联系人列表的视觉显示中显示该信息。”

* "[0041] ……显示该信息在装置终端的联系人列表的视觉显示中。”

* **分析：** D6公开了在移动装置上显示联系人列表、在线状态、消息等，毫无异议公开了特征G。

---

### 第四部分：最接近对比文件的确定与创造性分析

#### 1. 最接近对比文件的确定

根据整体解决的技术问题和技术效果分析，对比文件D3和D6同样适合做最接近的对比文件。

* **目标专利解决的问题：** 计算装置上存在不同类型的通信（SMS, MMS, IM, Email等），用户通常需要管理多个独立的通信界面，在各个界面之间切换不方便（特别是在移动计算装置这类小形状因数的装置上，[0003]）。

* **目标专利的技术效果：** 目标专利通过“消息接发数据库”集中记录不同协议消息，维持所述消息接发数据库而执行针对单个消息（传入/传出，来自任一协议）的自动化线程管理（判断存在->创建/关联），从而向用户呈现统一的、跨协议的混合输送消息接发线程（[0014]），使用户体验整合消息接发体验（[0015]）。

* **D3的分析：** 解决的核心问题是“整合不同通信界面”，允许用户开始撰写消息使用一种方法，随后“无缝切换”到第二种方法而不丢失内容，并保存消息撰写文本内容供新方法使用。该界面还可以显示参与者的在线状态。**在整合界面、通过单一界面使用多程序不同协议方面，D3解决的技术问题和效果与目标专利高度相关。其公开了整合界面和消息内容的实质维持。**

* **D6的分析：** 解决的核心问题是解决语音、文字、即时消息服务桥接到现有和未来宽带无线网络（ roam 和 costs 问题），提供“ Overlay 服务”允许用户在PC不在身边时保持连接，支持主要IM、SMS、全球通话服务。提供整合地址簿，可以通过地址簿发起不同类型的通信服务。**D6在提供一个可以统一访问多个不同程序不同协议通信系统的客户端客户端方面解决的技术问题和效果与目标专利高度相关。其毫无异议公开了在数据库中存储消息实例。**

**结论：** D3关注的是**撰写时的前端界面切换和内容维持**；D6关注的是**跨网络的通信桥接和推送，以及数据库存储**。两份对比文件在提供一个可以整合多个不同程序不同协议的消息通信界面方面，都解决的技术问题和效果最接近目标专利。

#### 2. 特征未公开分析（Features Not Disclosed in D3/D6）

目标专利权利要求1中，**最重要且未被D3或D6明确公开的技术特征组合是：**

> “其中所述处理资源结合维持所述消息接发数据库而执行，以便：作出针对单个传入消息或传出消息是否存在接发消息线程的确定，……且响应于确定……确实存在接发消息线程，使所述传入消息或传出消息与现有消息接发线程相关联”（特征组合D+F）。

**在目标专利中：** 此项特征组合是基于以后端数据库为基础对接收到的所有单次传入/传出消息（来自不同协议程序）进行自动化剖析和聚合（使用联系人信息交叉参考实现），其技术效果是实现自动化混合协议线程管理。

**在对比文件D3中：** 线程（conversation）更趋向于是以后端用户发起时选择联系人或地址所建立的一个会话上下文，关注点在于用户主动切换不同的发送路径（方法、地址）时保持内容的连续性。不涉及后端数据库逻辑针对“单次”传入消息或传出消息，跨越“任一消息接发程序”（如SMS和IM协议程序），进行自动化的“存在判断”和“与现有线程关联”的特定处理过程。

**在对比文件D6中：** 虽然说明书描述了用户可以回复消息（含混公开了判断存在的一种情况，但并未明确说明其如何跨越不同协议进行），并存储消息实例，主要关注点是基于SMS的 nudge 通知或基于IP的消息推送和推送机制。不涉及基于数据库逻辑、针对单个不同协议消息实例进行自动关联线程管理的特征。

#### 3. 无效请求中最薄弱的技术特征

根据上述分析，如果提出无效宣告请求，目标专利权利要求1中最薄弱、最容易被现有技术结合或惯用手段结合攻击的技术特征是：

**技术特征1.5, 1.6, 1.7（消息线程逻辑判断特征D, E, F）结合在消息存储（特征C, 由D6明确公开）上**：

> “（特征D）处理资源执行……以便：作出针对单个传入消息或传出消息是否存在接发消息线程的确定……响应于确定……不存在接发消息线程，为所述传入消息或所述传出消息创建新的消息接发线程（实质公开于D3/D6）……响应于确定……确实存在接发消息线程，使所述传入消息或传出消息与现有消息接发线程相关联（特征F）。”

**薄弱原因分析：**

1. **D3和D6共同公开了整合多协议通信系统的界面（P, A, B）和显示线程（G）**。且D3和D6都隐含了线程创建（E）。D6毫无异议公开了存储消息实例（C）。

2. 从对比文件D3或D6出发，已经提供了用户界面和集中地址簿允许通过单一界面访问不同程序协议，从而解决多个独立界面不便管理的技术问题。且现有技术（D6）已经存在将所有协议的消息存储在同一数据库中作为数据实例的做法。

3. 在此技术背景下，权利要求1中**根据消息的发送者/接收者（如从剖析消息输送识别符和联系人信息交叉参考实现）将在同一数据库中存储的不同协议消息实例，按照特定逻辑模式（判断存在->新建/关联）组合在一起形成线程**，极易被视为所属领域技术人员解决“统一对话管理”这一问题时的常规软件工程逻辑或工程自动化实现手段（"if exists X -> do Y; else do Z" 是一种基本的数据库操作模式）。

4. 尽管在创造性分析中，目标专利通过说明书[0031]-[0034]所描述的，通过交叉参考联系人存储库和分析各种协议的地址标识，将SMS号码和IM标记等不同标识符但属于同一人或群组的消息整合进同一线程，以实现真正的“跨协议自动化混合线程”，具有显著效果。但在权利要求层面上，特征D和F的通用表述并未详细限制这一具体实现方式（如明确说明如何进行跨协议分析和与联系人关联的具体步骤）。在没有这些具体限制的情况下，上述通用的逻辑判断和关联特征很容易被现有技术（即D3的前端切换和对话连续性概念，加上D6的消息存储概念）加上软件工程常规自动化手段相结合所覆盖。

因此，技术特征D和F的组合是该权利要求中最薄弱、极容易因“仅仅是将常规软件工程逻辑应用于已知数据集上”而被认为不具有创造性的特征。

---

希望这份详尽的分析报告对您有所帮助。如有任何疑问，请随时联系。

根据权利要求1所述的计算装置，其中所述消息接发数据库记录使用两个或两个以上无线通信端口从所述计算装置发送或在所述计算装置上接收的消息的实例，且其中所述处理资源提供在单个消息接发线程中使用所述两个或两个以上无线通信端口传送的两个消息。

根据权利要求1所述的计算装置，其中所述计算装置包含蜂窝式通信端口，且其中所述多个消息接发程序包含：第一程序，其经配置以使用所述通信端口的话音信道；以及第二程序，其经配置以使用所述通信端口的数据信道，且其中所述处理资源经配置以使给定消息接发线程能够包含所述第一程序和第二程序中的每一个的一个或一个以上消息。

根据权利要求1所述的计算装置，其中所述消息接发程序中的至少一个是即时消息接发程序。

根据权利要求3所述的计算装置，其中所述多个消息接发程序中的至少另一消息接发程序为短消息接发服务(SMS)或多媒体消息接发服务(MMS)程序。

根据权利要求1所述的计算装置，其中所述处理资源包含与所述数据库相关联的逻辑，所述逻辑剖析单个传入或传出消息，以确定用以使所述消息与(i)来自所述计算装置的联系人数据存储库的联系人记录，或(i)所述现有消息接发线程中的一个消息接发线程相关联的信息。

根据权利要求6所述的计算装置，其中所述处理资源(i)剖析所述单个传入或传出消息，以确定对应于发送或接收所述消息的另一方的消息接发识别符的信息，接着(ii)将所述消息接发识别符与所述联系人数据存储库的单个联系人记录中所含有的信息进行比较，以便使特定联系人记录与所述消息相关联。

根据权利要求7所述的计算装置，其中所述处理资源通过确定所述现有消息接发线程与所述特定联系人记录相关联来使所述传入或传出消息与所述现有消息接发线程相关联。

根据权利要求1所述的计算装置， 其中所述处理资源执行以将用于起始消息的默认消息接发程序指派给其它参与者； 其中所述消息接发数据库记录从所述默认消息接发程序所使用的服务提供的信息，所述信息包含在线状态信息； 其中所述处理资源执行以响应于确定所述在线状态信息指示另一参与者不在线而使用替代消息接发程序。

根据权利要求1所述的计算装置，其中所述处理资源通过使所述计算装置的用户能够使用不同消息接发程序来应答现有消息接发线程中的一个消息接发线程的传入消息，来执行显示新的和所述现有消息接发线程，所述不同消息接发程序是用以在所述计算装置上接收传入消息。

根据权利要求10所述的计算装置，其中所述传入消息是即时消息接发或蜂窝式服务消息，且对所述传入消息的应答消息是所述即时消息接发或蜂窝式服务消息中的另一个。

根据权利要求1所述的计算装置，其中所述处理资源执行以通过将使用不同消息接发程序从另一接收者发送的两个或两个以上消息识别为属于一个消息接发线程来显示新的和现有消息接发线程。

一种计算装置，包括： 多个通信端口，其用于将数据传送到所述计算装置和从所述计算装置传送数据，所述多个通信端口包含至少第一通信端口和第二通信端口； 处理资源与存储器资源的组合，所述处理资源与存储器资源可操作以在所述计算装置上实施消息接发系统，其中所述消息接发系统经配置以维持和呈现所述计算装置的用户与另一个人之间的多个混合输送聊天线程，每一混合输送聊天线程包括在所述用户与所述另一个人之间交换的消息的多个记录，包含使用以下各项中的每一个传送给所述另一个人的单个消息的记录：(i)用所述第一通信端口传送的第一消息接发输送，以及(ii)用所述第二通信端口传送的第二消息接发输送； 其中所述消息接发系统通过下述来维持和呈现所述多个混合输送聊天线程：(i)作出针对在所述用户与特定个人之间交换的消息是否存在混合输送聊天线程的确定，(ii)响应于确定针对在所述用户与所述特定个人之间交换的消息不存在混合输送聊天线程，为所述消息创建新的混合输送聊天线程，以及(iii)响应于确定针对在所述用户与所述特定个人之间交换的消息存在混合输送聊天线程，使所述消息与现有混合输送聊天相关联。

根据权利要求13所述的计算装置，其中所述多个通信端口包含：第一无线通信端口，其用于使所述计算装置能够连接到局域网或企业网络；以及第二通信端口，其用于使所述计算装置能够发送和接收蜂窝式通信。

根据权利要求13所述的计算装置，其中所述第一消息接发输送是用于在短消息服务(SMS)或多媒体消息服务(MMS)中的一个中发送消息，且所述第二消息接发输送是用于发送和接收即时消息接发服务的消息。

根据权利要求15所述的计算装置，其中所述第一消息接发输送使用蜂窝式通信端口，且所述第二消息接发输送使用无线局域网端口。

根据权利要求13所述的计算装置，其中所述消息接发系统包括： 数据库； 多个消息接发应用程序，包括用于所述第一消息接发输送和所述第二消息接发输送中的每一个的消息接发应用程序，所述多个消息接发应用程序经耦合以有权接入所述数据库； 其中所述多个消息接发应用程序中的每一个可操作以记录经由所述消息接发应用程序的操作而接收或发射单个消息的实例。

根据权利要求17所述的计算装置，其中所述数据库维持多个记录，且每一记录维持对应于所接收或发射的消息的实例的信息，且其中用户接口层经配置以使用由所述数据库维持的记录来产生一个或一个以上混合输送聊天线程。

根据权利要求17所述的计算装置，其中所述多个消息接发应用程序包含短服务消息接发(SMS)应用程序、多媒体消息接发服务(MMS)应用程序和即时消息接发应用程序。

根据权利要求18所述的计算装置，其进一步包括联系人数据存储库，所述联系人数据存储库可作为所述数据库的一部分而存取或与所述数据库一起使用，其中所述联系人数据存储库包含由所述用户识别的人的多个联系人记录，且其中所述用户接口层从在所述混合输送聊天线程中识别的另一人的联系人记录识别信息，且将所述信息显示为所述混合输送聊天线程的一部分。

根据权利要求20所述的计算装置，其中显示为所述混合输送聊天线程的表示的一部分的所述信息是在所述联系人记录中识别的所述另一人的名字。

根据权利要求20所述的计算装置，其中显示为所述混合输送聊天线程的表示的一部分的所述信息是与所述联系人记录相关联或与所述联系人记录一起存储的所述另一人的图像。