一种处理与乳房泵吸系统相关联的数据的方法，包括：生成和存储来自操作所述乳房泵吸系统的实时数据； 生成和存储来自操作所述乳房泵吸系统的历史数据；和 保持将实时数据流与历史数据流分开， 其中，在外部设备或程序与乳房泵之间具有双向通信，并且/或者所述乳房泵将过程数据写入其内部历史记录日志和/或所述外部设备，其中，所述实时数据能够被反映在外部设备的屏幕上并更新所述外部设备的屏幕，并且所述外部设备将下载所述历史数据以用于更新其非实时视图屏幕，其中，所述乳房泵吸系统被配置为对乳房采用空气抽吸以进行初始的闩锁和泵吸，然后转为利用所挤出的母乳以用于泵吸动作或动力，并且其中，所述乳房泵吸系统包括主动暂停模式，所述主动暂停模式允许所述乳房泵吸系统在保持闩锁真空的同时保持无声，以适应用户在需要与他人互动或不希望进行主动泵吸时的使用场景。

按照你给定的 A–I 技术特征，我对 Google Patents 做了多轮关键词、精确语句、同族、引证/被引证及同申请人早期文献的反向检索。现阶段已经找到一组相当有价值的 2016-02-10 之前公开的英文文献。其中最重要的不是目标专利审查过程中仅列出的 Medela 文献，而是 Exploramed NC7 自己在 2016-01-28 公开的三件 WO 文献。

先给结论：

当前最强组合是 WO2016014488A1 + WO2016014494A1。

• WO2016014488A1：对 A、B、D、E、F、G 以及 I 的大部分技术内容贡献非常强；

• WO2016014494A1：对 H 的贡献非常强，同时进一步强化“保持 latch suction / latch vacuum”的泵送原理；

• 特征 C“明确保持实时数据流与历史数据流分开”，目前尚未在临界日前文献中找到与目标权利要求同样明确的逐字公开，是目前最值得继续深挖的点；

• **特征 I 中的“主动暂停模式+保持闩锁真空”**在 WO2016014488A1 中已经相当接近甚至实质公开；但“为了与他人互动而保持 virtually silent”这一具体使用场景，我目前发现的完全一致措辞出现在 2016-02-10 之后的目标家族文本中。因此 I 的最后一小段目的性限定需要特别处理。

目标 CN113648473B 的优先权日正是 2016-02-10，权利要求1现在把 A–I 全部组合在一起。Google Patents 同时显示，其审查引证只有 CN105247563A 一件。(谷歌专利)

一、最重要的对比文件 D1：WO2016014488A1

文献：WO2016014488A1 — “Breast pump system and methods”
申请人：Exploramed NC7, Inc.
优先权：2014-07-22
公开日：2016-01-28
因此满足你要求的“公开日在 2016-02-10 之前”。(谷歌专利)

这件文献的重要性非常高，因为它不仅是同一技术路线，而且发明人包括 Joshua Makower、John Y. Chang 等，与目标家族高度重合。

D1 对 A–I 的覆盖

1. 对 D——双向通信——公开非常直接

D1 明确公开：

• controller 52 可以通过无线发射器把数据发送给 external device 470；

• 可使用 Bluetooth；

• 数据可在外部设备进入通信范围时自动发送；

• 反方向，external computer/app 又可以向 controller 52 发送具体 pumping mode、参数和命令；

• 甚至可以在 pumping session 中 real time 向控制器发送定制参数。(谷歌专利)

因此对你定义的：

D：在外部设备或程序与乳房泵之间具有双向通信

我会评为 直接公开/非常强。

这不是简单的单向“泵上传数据”，因为文献同时公开了外部 app 对乳房泵控制器的反向控制。

二、D1 对 A、B、E、F、G 的杀伤力实际上比目标审查引证更值得重视

D1 的 controller/app 架构公开：

• pumping session length；

• session开始时间；

• milk volume；

• pumping frequency；

• suction pressure waveform；

• maximum suction；

• latch suction；

• flow rate；

• 数据由 pump/controller 无线传输给外部 app。(谷歌专利)

同时，文献明确让 app 依据这些数据生成和显示历史统计：

histogram 可以按 days、weeks、sequential milk extraction sessions 的时间顺序显示。

而且 milk extraction volume、time、date、pump cycle data 可以自动采集，无需用户手工输入。(谷歌专利)

这已经非常接近 B、E、G 所要解决的技术问题。

特征 A——实时数据

D1 多处明确出现 real-time：

• controller 根据 pressure feedback real time 计算 milk flow；

• controller 可以实时调整 pumping parameters；

• external computer 可以在 pumping session 中 in real time 向控制器发送 pump functions。(谷歌专利)

因此“从乳房泵操作生成实时数据”没有太大争议。

至于 A 中的“存储实时数据”，D1 虽然没有按目标权利要求那种“live data stream”组织语言，但明确公开 controller 保存运行期间的参数变化至 memory，并把数据发送/保存供后续使用。(谷歌专利)

所以：

A：强贡献。

特征 B——历史数据

D1 对历史数据的公开实际上很强。

文献明确：

controller/app 可以在 multiple sessions 中比较 pumping results，并保存产生最佳结果的参数供下一次 session 使用。(谷歌专利)

同时历史图表基于：

• previous pumping sessions；

• days；

• weeks；

• sequential sessions；

• historical extraction volume。

例如 expected volume 还明确可以：

based on previous breast extraction volumes from previous sessions. (谷歌专利)

因此如果“历史数据”按普通技术含义解释：

B 基本已经公开。

特征 E——内部记录/外部设备

D1公开：

• 控制器可将用户对 pumping parameters 的修改 save ... in memory；

• sensor processed signals 可以存储在 memory；

• pump/controller 数据自动无线发送外部设备；

• app 自动记录 volume/time/date/pump-cycle information。(谷歌专利)

目标 E 使用的是：

“和/或者……内部历史记录日志 和/或 外部设备”

这是一个本身非常宽的“and/or”结构。

因此只要证明“写入外部设备”，就已经能满足其中一个分支。

所以我对：

E：倾向直接公开。

三、D1 对 F、G 特别有价值

F：实时数据反映在外部设备屏幕并更新

D1明确：

• external computer 有 display；

• processor 接收 controller 的数据；

• 根据接收数据计算结果；

• 把结果显示于 external computer display；

• pumping data 自动传给 app。(谷歌专利)

另外，文献明确讨论 real-time pumping feedback、实时流量计算以及外部 app 与控制器在 pumping session 内交互。(谷歌专利)

所以 F 不宜孤立理解成必须出现“update screen”四个字。

从技术功能上：

F：非常强。

G：历史数据更新非实时视图

这是 D1 非常值得用的一段。

文献明确：

app 474 receives pumping data and compiles a histogram；图表按照 days、weeks 或 sequential extraction sessions 显示 milk extraction volume。

并进一步明确：

milk extraction volume values, time/date values and other pump cycle data can all be handled automatically. (谷歌专利)

这就是典型：

当前 session → 数据采集；多 session 历史 → 非实时趋势图/历史图。

区别只在于目标权利要求采用了更具体的协议描述：

external device “downloads historical data” to update “non-live view screens”。

D1未被我检索到完全相同的“download historical stream”措辞。

所以：

G = 非常强的实质公开，但若做严格新颖性单篇逐字比对，我标为 △；用于创造性组合则非常强。

四、目前最大的缺口：特征 C

你定义的 C 是：

保持将实时数据流与历史数据流分开。

这是目标说明书中特别具体的一种软件/通信架构。

目标家族后来的英文说明书明确说：

real-time/live data and historical data are treated differently，and their data streams are maintained separately；

并进一步描述：

• live updates；

• historical stream；

• internal history log；

• external device query；

• download historical data；

• non-live view screen。(patents.google.com)

我对临界日前的 D1/D2/D3 做了逐词检索，目前：

• WO2016014488A1：没有检出 “historical data”；

• 没有检出 “two-way” 这一文字本身，但实际双向功能明确存在；

• 没有检出“live data stream / historical data stream maintained separately”。(谷歌专利)

因此目前不能把 C 夸大成“直接公开”。

当前结论

C 是权利要求1目前最清晰的差异点之一。

但它的问题在于：

D1已经客观存在两类不同用途的数据：

1. session 期间用于 feedback/control 的动态实时数据；

2. previous sessions 用于 histogram/trend/optimization 的历史数据。

因此下一阶段无效检索的核心，应当不是再泛搜“smart breast pump”，而是专门搜：

medical device / wearable / infusion / pump + live data + history log + external display + separate streams

寻找一件临界日前文献把 C 的数据通信架构补齐。

五、最重要的机械/液压对比文件 D2：WO2016014494A1

WO2016014494A1 — Breast pump system and methods
Exploramed NC7, Inc.
优先权：2014-07-22
公开日：2016-01-28。

同样早于 2016-02-10。(谷歌专利)

这篇针对你的 H 非常重要。

六、D2 对 H 的覆盖非常强

H要求：

先用空气抽吸实现初始闩锁和泵吸；
然后转为利用挤出的母乳进行泵吸动作/动力。

D2明确公开：

当开始 milk pumping/extraction session 时，tubing 32 内最初存在 air，需要先把这部分空气泵走以 prime the pumping system。(谷歌专利)

随后：

compression elements 36、38 压缩 tube 32，pumping fluid (milk) through one-way valve into milk collection container。(谷歌专利)

而且文献非常明确地区分：

pumping air versus pumping milk；

并说明：

• tubing 内是 air 时，需要更大 compression-member displacement；

• tubing filled with milk 后，因为液体不可压缩性不同，泵的动作/压力关系改变。(谷歌专利)

换言之，其工作序列就是：

初始：空气介质 → prime / establish vacuum → 乳汁进入管路 → 压缩乳汁所在柔性管路泵送。

这已经非常接近 H 的技术实质。

更关键的一点：D2 保持 latch suction 的结构也已经公开

D2明确：

当压力达到 minimum suction / latch suction，例如 −60 mmHg 时：

compression member 36 seals off portion 32S，从而 maintaining the minimum suction (latch suction) against the breast。(谷歌专利)

之后 compression member 38 继续压缩下游的乳汁，直至打开 one-way valve，把 milk 排入 collection container。

因此它实现了非常关键的：

乳房侧持续保持 latch vacuum，而下游以乳汁为实际泵送流体。

这对 H 的技术机理是非常直接的攻击材料。

H结论

我目前会把：

D2 → H：★★★★★，核心对比文件。

七、I 其实已经被 D1“打掉大半”

I不是单纯“pause”。

它包含三个层次：

1. active pause；

2. pause 时仍保持 latch vacuum；

3. virtually silent，并用于“与他人互动/暂时不想主动泵吸”的场景。

D1已经明确公开：

controller 52 can pause the pumping cycle for a predetermined pause time，然后恢复。(谷歌专利)

更加关键的是：

D1明确描述 pause period during which only latch suction is applied to the breast。(谷歌专利)

它的权利要求甚至写道：

latch suction is maintained throughout a pumping session. (谷歌专利)

所以：

I1：pause

直接公开。

I2：pause 时保持 latch vacuum

强烈公开。

这两点结合起来，已经非常接近目标“Active Pause Mode”的技术核心。

八、I 剩下的真正差异很窄：“virtually silent + 社交使用场景”

目标家族的后期文本才用非常明确的措辞：

Active Pause Mode allows the system to maintain latch vacuum while remaining virtually silent；

并解释：

用户需要与别人互动、不希望别人听到泵，或者暂时不想主动 pumping。(Eureka)

我暂时没有在 2016-01-28 的 D1/D2 中找到这一整段文字。

D1只公开了：

• pause；

• pause 时只保持 latch suction；

• 系统整体追求 quiet/discrete。(谷歌专利)

所以如果严格按你给的 I 整体划分：

I：D1 = 高度接近，但不是目前可以安全声称100%逐字公开。

不过用于创造性攻击时，这一点的防御价值可能比看起来弱：

已知“停止主动 pumping + 仅保持 latch suction”后，驱动部件活动减少乃至停止，其噪声自然显著降低。

“为了用户与他人互动”更多接近对已有 pause 工作状态的一种使用目的说明，而不一定形成很强的机械结构差异。

但这一点属于无效论证，应结合最终证据和专利法适用标准处理，我这里只作技术检索判断，不作法律意见。

九、D3：WO2016014469A1

WO2016014469A1 — Breast pump system and methods
Exploramed NC7, Inc.
优先权：2014-07-22
公开：2016-01-28。(谷歌专利)

这件文献更早系统公开：

• 初始 suction/vacuum；

• 乳房形成 seal；

• compression elements；

• milk进入 conduit；

• pumping过程中持续保持残余 suction；

• one-way valve；

• 下游压缩乳汁并排出。

例如其明确描述 compression element 36 建立 initial suction，并在泵送过程中留下 residual/minimum suction against the breast。(谷歌专利)

因此 D3 可以用作：

H及“persistent latch vacuum”技术思想的辅助证据。

但就目前文本匹配程度而言，我认为：

D2（WO2016014494A1）优于 D3。

十、D4：US20140263611A1 / Medela

US20140263611A1 — System and method for managing a supply of breast milk
Medela Holding AG
优先权：2013-03-13
公开：2014-09-18。

这是目标专利审查引证 CN105247563A 的英文同族路线之一。CN105247563A 本身公开日为 2016-01-13，也在临界日前。(谷歌专利)

这篇文献特别适合补强：

A、B、F、G。

它明确公开：

• pumping log；

• session milk amount；

• collection date/time；

• breast identification；

• performance charts；

• smartphone app；

• real-time performance feedback。(谷歌专利)

尤其：

smartphone app 从 pumping session 获取 date/time、milk amount 等数据，以生成 pumping log、performance charts、reminders。

以及：

video may be used for real-time performance feedback。(谷歌专利)

所以它很好地证明，在目标优先权日前：

“乳房泵实时信息 + pumping history/log + 手机显示历史图表”本身绝非新概念。

但它的泵—手机数据架构没有 D1 那么接近目标权利要求。

因此我建议把它定位为：

辅助组合文献，而不是首选主证据。

十一、目前推荐的无效特征矩阵

符号：

• ● = 强、接近直接公开

• ○ = 有明确贡献，但存在表达/结构差异

• — = 当前未发现有效贡献

十二、我认为目前最有价值的两条无效路线

路线一：D1 + D2

这是目前最强。

D1 = 数据、控制、app、历史数据、实时数据、双向通信、pause/latch
D2 = air→milk hydraulic pumping

组合后：

A+B+D+E+F+G + H + I的大部分内容已经连成一个非常完整的技术链。

更重要的是：

• 两件都属于 Exploramed NC7；

• 同一 2014-07-22 优先权；

• 同日 2016-01-28 公开；

• 同一 wearable breast pump 技术平台；

• 发明人高度重合；

• 结构、编号和 controller/pump 架构大量共通。(谷歌专利)

所以从纯技术组合动机来看，比任意拼接两个毫无关系的专利强得多。

目前真正需要补的是：

C。

路线二：D1 + D2 + D4

若要进一步削弱 A–G 的创造性：

D4证明早在 2014 年：

pumping session 信息→历史日志→performance chart + smartphone + real-time feedback

已经是乳房泵数字管理的已知方案。(谷歌专利)

D1则进一步提供：

pump controller↔external app、无线通信、实时运行参数、跨session历史分析。

所以：

D4提供领域背景；D1提供更接近的架构；D2提供H。

这是非常值得形成正式无效比对表的一组。

十三、一个值得高度关注的事实

目标 CN113648473B 自己的 Google Patents 页面显示，目前列出的 Patent Citation 只有：

CN105247563A / Medela。(谷歌专利)

但是同一个 Google Patents 家族页面又可以清楚追到，目标技术体系与：

• WO2016014469A1

• WO2016014488A1

• WO2016014494A1

这组三件 2016-01-28 已公开文献存在极深的技术连续性。

尤其目标权利要求中的：

• latch suction；

• persistent vacuum；

• flexible conduit；

• air/milk transition；

• controller；

• external device；

• pumping history；

• pause；

在这些早期文件里已经大量出现。

因此，在无效检索意义上，这三件比审查员引用的 Medela 更应该作为核心研究对象。

当前阶段排名

我会这样排序：

第一优先级

1. WO2016014488A1 —— A/B/D/E/F/G/I核心

2. WO2016014494A1 —— H核心 + latch vacuum

第二优先级
3. WO2016014469A1 —— H/latch基础结构
4. US20140263611A1 / WO2014160065 系列 —— A/B/F/G

当前最关键的未解决问题

只剩两个特别值得继续追：

① 找到一件 2016-02-10 前明确公开“live data stream 与 historical data stream 分开”的英文文献，专攻 C；

② 找到一件临界日前明确公开“pause + maintain latch vacuum + motor停止/静音”的文献，把 I 最后的“silent”也完全封死。

如果这两个点再各找到一篇强文献，权利要求1的 A–I 就可以形成非常完整的逐特征无效证据链。上述为技术检索与专利文献分析，不构成具体法律意见。

我按你的限制重新做了日文方向检索：只考虑在 2016-02-10 之前已经公开的日本专利公开文本；不把上一轮已经找到的 WO2016014488A1、WO2016014494A1、WO2016014469A1、US20140263611A1/CN105247563A 等反查成日文同族来充数。 这轮结果和英文方向差异比较明显：日文文献里，真正有独立价值的目前主要集中在 A/B/E 和乳房泵的负压/流体结构；对 C、D、F、G、I 的完整覆盖明显弱很多。

一、目前最值得用的日文文件：JP2013102867A

JP2013102867A《搾乳器およびその機構ユニット》
申请人：Pigeon Corporation（ピジョン株式会社）
申请日/优先权日：2011-11-11
公开日：2013-05-30。这是日本本土申请 JP2011247655A，不是上一轮英文文献反查得到的日文同族。(谷歌专利)

我目前认为这是这轮日文检索中，对目标权利要求1 最有实际无效贡献的一件。

它明确公开：

• 搾乳器具有控制部62；

• 控制部包括可读写存储器；

• 使用 SDカード65 保存数据；

• 保存的是实际搾乳过程中产生的吸引压力和吸引周期数据；

• 显示部68可以显示：

  • 运行信息；

  • 当时的运行状态；

  • 过去的记录；

• 再次使用时，可以读取过去的数据，再现相同吸引压力和吸引周期。(谷歌专利)

其原文的技术关系非常清楚：

「表示部68……使用者が必要とする運転情報、その時の運転状況、過去の記録等を表示する。」

以及：

「SDカードは、準備モードおよび搾乳モード使用時の吸引圧や吸引サイクルのデータを記録することが出来、再度使用する際に過去のデータを用いて同じ吸引圧や吸引サイクルを再現できる。」 (谷歌专利)

对 A：强贡献

你的 A 是：

生成和存储来自操作乳房泵吸系统的实时数据。

JP2013102867A 的：

• 当前运行状态；

• 搾乳中的吸引压力；

• 吸引周期；

• 控制器实时控制泵；

• 将搾乳模式过程中这些运行参数记录到可写存储器；

已经构成非常典型的运行过程中生成的过程数据+存储。(谷歌专利)

但严格讲，它没有使用“リアルタイムデータストリーム”这种表述。

所以我的评级是：

A = ●/○，很强，但做单篇新颖性时要区分“实时运行数据”与目标专利特定意义的“live data stream”。

对 B：直接而强

B：

生成和存储历史数据。

这件文献非常好。

它不仅记录历史，而且明确：

「過去の記録」

以及：

「過去のデータを用いて同じ吸引圧や吸引サイクルを再現」

更进一步，说明书后部明确说，默认参数可以根据最近的运行历史进行替换：

「直近における運転履歴から設定が変更されている場合のデータと置き換える」(谷歌专利)

因此：

B = ●，直接贡献。

对 E：部分直接公开

E包括：

乳房泵将过程数据写入其内部历史记录日志和/或外部设备。

这件文献把：

• preparation mode；

• pumping mode；

• suction pressure；

• suction cycle；

写入 SD 卡，SD卡本身属于乳房泵控制单元的数据存储器。(谷歌专利)

由于你的 E 是：

internal history log and/or external device

它实际上是一个非常宽的择一限定。

如果“内部历史记录日志”不要求必须名为“history log”，那么：

“泵内部可写存储器记录搾乳历史数据”与 E 的技术实质高度一致。

因此：

E = ●/○。

不足仅仅是没有明确叫“内部履歴ログ”。

对 C、D、F、G

这里必须严格。

我专门在全文检索了：

• 通信；

• 外部；

• Bluetooth；

• 外部端末；

目前没有找到相应公开。Google Patents 全文搜索“通信”和“外部”也没有命中。(谷歌专利)

所以不能把它扩大解释为手机或外部设备方案：

• C = —

• D = —

• F = —

• G = —

但它对后续创造性论证很有价值，因为它证明：

早在2013年的日本乳房泵专利中，“当前运行状态数据”和“过去历史数据”已经同时存在于同一个乳房泵控制系统中，而且历史数据被持久化并再次调用。

所以目标专利 A+B+E 这部分并不是 2016 年才出现的技术思想。

二、JP2013532540A：对负压泵、气动—液体隔离的结构贡献较强

JP2013532540A《搾乳器》
申请人：Koninklijke Philips
优先权日：2010-07-27
公开日：2013-08-19。(谷歌专利)

这件不是上一轮已经列出的 D1–D4 日文同族，因此本轮可以独立评价。

它公开一种很有意思的乳房泵结构：

• 第一压力腔22；

• 第二压力腔23；

• 两腔之间由 actuator 20 流体隔离；

• 第一压力腔产生压力差；

• actuator 因压力变化移动；

• 在第二压力腔产生相反方向的压力差；

• 第二压力腔包括乳房接收空间；

• 泵利用负压从乳房抽取乳汁。(谷歌专利)

文件明确解释传统乳房泵：

乳房泵利用真空诱发母乳挤出，泵作用将乳汁从乳头引向收集容器。(谷歌专利)

更关键的是，本发明专门避免乳汁进入真空泵机构：

第一、第二压力腔通过 actuator 流体分离，驱动侧的压力变化机械传递给乳房侧。(谷歌专利)

对 H 的作用

H非常具体：

先用空气抽吸实现初始 latch/pumping，然后转为利用挤出的母乳本身作为泵吸动作/动力。

JP2013532540A 不能完整公开 H。

它能证明的只是：

1. 负压/气动侧作为驱动力；

2. 乳房侧存在乳汁流体；

3. 气动压力与乳汁流路可以流体隔离；

4. 气动作用通过可动执行器转换成乳房侧压力作用。(谷歌专利)

但没有发现：

“一开始泵空气，随后母乳进入后转由母乳作为实际泵送介质”

这一关键的 air→milk transition。

因此我只给：

H = ○，辅助结构证据，不宜作为 H 的主引证。

它更适合证明“乳房泵利用气动压力驱动、同时乳汁与泵驱动机构隔离”本身早已公知。

三、JP2010167052A：对“先建立负压吸附乳房、再抽取并排出乳汁”的顺序有贡献

JP2010167052A《母乳搾乳器》
公开时间在2010年，明显早于临界日。(谷歌专利)

它是传统手动结构，但对 H 的“工作阶段顺序”有一定价值。

其明确公开：

1. 把杯体压在乳房；

2. 拉开内外筒，使内部容积增加；

3. 由此产生负压；

4. 负压作用于乳头；

5. 母乳被吸入乳汁储存部；

6. 随后压回内筒；

7. 利用内部压力打开止回阀；

8. 把母乳从储存部排出。 (谷歌专利)

也就是说，很早已经存在：

air/volume change → negative pressure → breast attachment/milk extraction → milk becomes the fluid being discharged through the pumping stroke

这种工作链。

但不能把它说成完整 H

目标 H 要求的是：

初始使用空气抽吸；
之后“转换为利用所挤出的母乳用于泵吸动作或动力”。

JP2010167052A 后半段确实利用压缩后的内部压力把乳汁通过阀排出，但它不是目标系统那种：

“先 air pumping，管路被 milk prime 后，由不可压缩的 milk 作为 hydraulic pumping medium”。

因此：

H = ○。

它是“概念性辅助文件”，不是最强 H 文件。

四、JP2009247558A / JP5204533B2：传统负压泵结构可作 H 背景证据

JP2009247558A《搾乳器》
日本申请人：Pigeon
优先权：2008-04-04
公开：2009-10-29。(谷歌专利)

这也是日本本土乳房泵技术路线。

其技术重点是：

• breast contacting part；

• negative pressure generating means；

• 与乳房一侧液密隔离的变形部件；

• 通过变形部件传递压力；

• 控制乳房空间内负压。(谷歌专利)

对权利要求1直接贡献不如 JP2013102867A。

主要作用是证明：

使用气体压力/真空建立乳房侧负压，并通过隔膜等结构把泵机构与乳汁环境隔开的结构，在日本乳房泵领域很早已经存在。

所以：

H = 弱到中等辅助。

五、JPH01171564A：非常早的“抽空气→形成负压→抽乳”技术公开

JPH01171564A《搾乳器》
申请：1987-12-28
公开：1989-07-06。(谷歌专利)

这件年代很早，但对于 H 的前半段特别干净。

其明确描述：

• 杯部贴合乳房；

• 电机驱动 diaphragm；

• 将瓶内空气吸走；

• 使瓶内形成负压；

• 因此母乳被吸出；

• 母乳沿搾乳部进入瓶中。(谷歌专利)

也就是：

「ボトル内の空気が……吸引されて、ボトル内が負圧になる。従って、母乳が……搾乳される」

这对 H 的：

“对乳房采用空气抽吸以进行初始……泵吸”

是很标准的早期公开。

但是其后没有：

改变工作机理，让母乳成为后续的液压泵送介质。

所以：

H前半段 = ●
H整体 = ○/弱

用于创造性组合的意义比用于完整新颖性攻击更大。

六、JP2013532540A 与 JPH01171564A 的组合意义

如果从日本乳房泵的技术演进来论证 H：

JPH01171564A已经说明：

抽走空气 → 建立乳房负压 → 母乳进入系统。(谷歌专利)

JP2013532540A进一步说明：

泵驱动侧和乳汁/乳房侧可以通过执行器分离，利用一侧气压变化驱动另一侧压力变化。(谷歌专利)

JP2010167052A又说明：

乳汁进入储液空间之后，可在后续压缩动作中将乳汁通过止回阀泵出。(谷歌专利)

三件连起来，其实已经把 H 所涉及的基本物理原理拆得比较完整：

空气产生负压 → 母乳进入 → 后续运动对乳汁实施正向输送。

但目前仍没有找到一件 2016-02-10 前的日本公开文本，像上一轮英文 WO2016014494A1 那样非常明确地写出：

“air initially occupies the pumping tube; after priming, milk fills the tube; displacement characteristic changes because milk is incompressible.”

所以在日文文献中，H目前没有出现比上一轮英文文件更强的单篇。

七、关于 I：日文公开目前没有发现足够强的文件

我专门围绕以下日文词组做了反复检索：

• 搾乳器 + 休止

• 搾乳器 + 一時停止

• 搾乳器 + 負圧維持

• 搾乳器 + 真空維持

• 搾乳器 + 静音

• 搾乳器 + 停止 + 真空

• 搾乳器 + 運転停止

目前没有找到一件 2016-02-10之前的日本公开文本同时公开：

暂停主动泵吸

• 仍然维持乳房吸附真空

• 泵保持安静。

这很重要。

有一些后来公开的日本文本虽然优先权早于临界日，但日本公开日是在临界日之后，我按照你的要求全部排除了。

例如一些 Philips/Pigeon 的申请：

• 优先权可能是2014或2015；

• 但日本公开日为2017/2018；

• 因此没有作为本轮“2016-02-10之前公开的日文对比文件”使用。例如 JP2017516578A 的日本公开直到 2017-06-22；JPWO2017082400A1 更晚。(谷歌专利)

这是本轮和上一轮最大的区别之一。

八、关于 C：仍然没有找到乳房泵领域的日文强文件

C：

实时数据流与历史数据流分开保持。

我针对日文概念检索了：

• リアルタイムデータ

• 履歴データ

• データストリーム

• 別々

• 分離

• 運転履歴

• 現在データ

• 過去データ

• 内部メモリ

• 外部端末

在乳房泵领域，目前最接近的是 JP2013102867A：

“その時の運転状況”
与
“過去の記録”

并存。(谷歌专利)

这意味着技术上已经把当前状态数据和历史数据作为两类不同用途信息处理。

但它并没有：

两套 data stream 分开传送/保持。

所以：

C仍然不能判直接公开。

不过 JP2013102867A 对 C 的创造性背景仍然有价值：

目标专利并不是首次想到“当前状态”和“过去记录”应该区别处理；真正剩下的只是把它们实现成彼此独立的数据流。

九、D/F/G：日文乳房泵公开目前是明显缺口

D：

外部设备与泵之间双向通信。

F：

实时数据更新外部设备屏幕。

G：

外部设备下载历史数据，更新非实时历史画面。

在严格限定：

“日文公开 + 日本公开日在2016-02-10之前 + 不能反查上一轮英文文献的日文同族”

之后，结果非常少。

我目前没有找到可以稳妥定为 D/F/G 直接公开的日本乳房泵专利。

这说明上一轮英文检索中的 WO2016014488A1 对 A–G 的价值依然明显高于目前这些日文材料。

十、目前日文文件的特征矩阵

按严格尺度：

其中：

● = 明确直接贡献
○ = 有实质技术贡献但不是完整公开
— = 当前不建议用来主张该特征

十一、这轮真正值得留下的两件

如果你不想在无效请求里堆大量弱文献，我建议重点保留：

1. JP2013102867A —— 日文数据类核心文件

它最重要。

原因是它可以很干净地证明，在 2013年日本乳房泵中已经有：

泵运行产生过程数据
→ 写入内部可写存储器
→ 保存历史
→ 当前运行状态和过去记录分别显示
→ 以后重新读取历史数据影响泵工作。

这直接削弱 A+B+E，并对 C 的“区分实时/历史信息”提供很好的技术启示。(谷歌专利)

2. JP2013532540A —— 日文气动/乳汁侧隔离核心文件

它对 H 的基础物理结构最有价值：

气压差驱动

• 乳房侧负压

• 泵驱动侧和乳汁侧流体隔离

• 压力通过可动执行器转换。(谷歌专利)

十二、目前日文检索最重要的结论

这轮没有为了数量把后公开日文同族混进来，因此结果比“直接查 JP family”少，但证据质量更干净。

目前可以把日文现有技术分成两条线：

数据线：

JP2013102867A
当前运行数据 + 内部存储 + 历史记录 + 重用历史参数
→ 主攻 A/B/E，辅助 C。

泵送线：

JPH01171564A + JP2010167052A + JP2013532540A
空气抽吸建立负压 + 母乳进入 + 后续压力作用输送乳汁 + 气动/乳汁侧分离
→ 对 H 提供分解式创造性攻击。

但现在不应该声称日文文件已经完整覆盖 A–I。

尤其：

C、D、F、G、I 仍然是日文检索需要进一步专攻的区域。

其中最值得继续扩展的不是只搜 A61M1/06“乳房泵”，而是搜日本在 2010–2015 年间的 医疗泵、输液泵、可穿戴医疗设备、家电设备 中：

“リアルタイム情報／履歴情報”
“履歴ログ”
“外部端末から問い合わせ”
“Bluetooth双方向通信”
“履歴データのダウンロード”
“リアルタイム画面／履歴画面”

这种数据架构。如果能找到这种日文横向文件，最有可能真正补上 C/D/F/G。对 I，则应继续沿“真空吸着を維持したままポンプ停止/休止”的医疗吸引装置方向，而不局限于乳房泵。

按你这次的限定，我重新以 Google Patents 的 KR 韩国公开文本为中心做了多轮检索，并严格执行：

• 公开日必须早于 2016-02-10；

• 不把前面已经找到的 WO2016014488A1、WO2016014494A1、WO2016014469A1、US20140263611A、JP2013102867A 等再反查成 KR 同族；

• 后于 2016-02-10 才在韩国公开的 Exploramed/Willow 系列全部排除；

• 对 A–I 仍按你最初给定的特征划分，不重新拆分。

这一轮韩文检索有两个比较有价值的新结果：

KR100755897B1《프로그램 가능한 유축기》 对 A、B、E、G 的贡献很强，尤其是“记录乳房泵运行数据→保存→下载至计算机”的历史数据链条。
KR20150118366A《스마트 유방마사지 방법 및 시스템》 虽然不是乳房泵，而是非常接近的乳房可穿戴装置，但对 D、F 的“智能手机↔乳房佩戴装置双向 Bluetooth 通信、传感数据反映到手机屏幕”有相当好的补强作用。

另外，韩国本土乳房泵文献 KR200466652Y1 对 H 的“空气抽吸→乳汁进入→乳汁排出”工作顺序有贡献，但还不能完整打掉 H。

一、最重要韩文数据文献：KR100755897B1

KR100755897B1《프로그램 가능한 유축기》

中文可译为：可编程乳房泵

申请人：Medela Holding AG
优先权：1999-12-10
韩国申请：2000-12-07
韩国公开体系还存在更早的 KR20020086857A；目前 Google Patents 可直接完整检索的授权公开 KR100755897B1 公开日为 2007-09-06，远早于 2016-02-10。(谷歌专利)

这件文件非常值得重视，因为它不仅仅公开“可编程泵”，而且专门有：

유축기 작동 데이터를 기록
记录乳房泵运行数据；

并明确说：

数据可以保存以后，通过互联网连接、磁记录介质、disk/card 等方式 download 检索。(谷歌专利)

更具体地：

数据可以由微处理器记录，然后下载/传送到 chip card；

以及：

带有 breast pump operating data 的 chip card 在 card station 中被读取/下载至 computer 77。(谷歌专利)

这个结构对本案 A/B/E/G 很有用。

1. 对特征 A：强贡献

A：

生成和存储来自操作乳房泵系统的实时数据。

KR100755897B1 的权利要求8直接要求：

产生表示乳房泵操作功能的信号；
并包括为了以后检索而记录该信号的装置。(谷歌专利)

说明书更明确写：

programmable pump 可以记录 data regarding its use and operation。

也就是说：

泵在实际运行过程中生成 operation data → 记录/存储。

严格说，它没有使用目标专利的专门术语：

“live data stream”

因此如果按照新颖性非常严格比对：

A = ●/○。

其中：

• “运行过程生成数据”：直接；

• “存储”：直接；

• “实时数据流”：没有明确叫这个名字。

二、KR100755897B1 对 B 非常强

B：

生成和存储来自操作乳房泵系统的历史数据。

这里几乎不存在技术上的疑问。

文献明确：

pump 可以记录其使用和操作数据；

这些数据：

stored and later retrieved

即：

保存以后再读取。(谷歌专利)

而权利要求8同样明确：

记录 operation signal for later retrieval。(谷歌专利)

这就是典型的：

当前 pumping session → 持久化 → 后续读取的历史运行数据。

因此：

B = ●●，非常强。

甚至从“历史数据”普通技术含义而言，可以考虑认定为直接公开。

三、KR100755897B1 对 E 很强

E：

乳房泵将过程数据写入其内部历史记录日志和/或外部设备。

文献公开了多种记录方式：

• microprocessor 记录数据；

• 数据写入 chip card；

• 数据可以直接写入 chip card；

• 后续通过 card reader 下载到 computer。(谷歌专利)

特别重要的是 E 自己采用：

内部历史记录日志 和/或 外部设备。

这是择一结构。

所以不必同时证明“内部 history log”和“外部设备”。

KR100755897B1 至少明确实现：

泵运行数据 → 非易失/可移动数据介质 → computer。

因此：

E = ●。

如果对方争辩 chip card 是“可移动存储卡而非内部历史日志”，也不会完全解决问题，因为 E 有：

and/or external device

这个分支。

四、KR100755897B1 对 G 的贡献比表面看起来更强

G：

外部设备将下载历史数据用于更新其非实时视图屏幕。

这件文献的图10专门就是：

breast pump operating data
→ chip card
→ card station/card reader
→ computer 77。(谷歌专利)

原文明确使用：

「다운로드」/ downloading

也就是说：

“外部设备下载乳房泵历史运行数据”

在 2000 年左右已经是明确技术方案。

这恰好打到 G 中非常关键的：

external device downloads historical data

部分。

但 G 不能全部说成直接公开

目标 G 还有一个进一步限定：

下载历史数据 用于更新非实时视图屏幕。

KR100755897B1 的目的主要是：

• monitoring；

• research；

• data transfer；

• programming/updating pump。

我目前没有找到它明确说：

下载后更新 external device 的 non-real-time view screen。

因此更严格评价：

G = ●/○

其中：

• 历史数据：●

• 外部计算机下载：●

• non-live screen update：○/未明确。

这件文件对 G 的价值仍然很高，因为它已经把目标 G 最重要的数据流向提前公开了。

五、KR100755897B1 对 D 也有一定贡献，但我不建议夸大

D：

外部设备/程序与乳房泵具有双向通信。

KR100755897B1 一方面：

泵运行数据可以向外输出/下载；

另一方面：

program/new data 可以写入 pump/controller；

并且说明从外部程序重新编程控制器。(谷歌专利)

因此功能上存在：

pump → external medium/computer

以及：

external program/media → pump controller

两个方向。

但它大量依赖：

• chip card；

• card reader；

• internet connection；

并不完全等同于目标专利强调的：

同一通信协议下的 external device ↔ pump two-way communication。

所以我建议：

D = ○

作为创造性背景很好；

作为 D 的单篇直接公开，不如下面这件 KR20150118366A。

六、非常值得组合的韩国本土文件：KR20150118366A

KR20150118366A《스마트 유방마사지 방법 및 시스템》

中文：智能乳房按摩方法及系统

韩国本土申请。
优先权/申请日：2014-04-14
韩国公开日：2015-10-22。(谷歌专利)

它不是乳房泵，这是必须明确的。

但是它的技术环境极接近：

乳房佩戴式 bra-pad + sensors + smartphone + Bluetooth + app + screen。

因此特别适合作为 D/F 的横向组合文献。

七、KR20150118366A 对 D：非常有价值

文献明确：

bra-pad 中设置传感器；

并：

通过 RFid/Bluetooth Smart Tag 与 smartphone 配合。(谷歌专利)

第一个通信方向：

手机 → bra-pad

手机 app 中：

• 用户设定 vibration level；

• 设定时间；

• 点击 start；

之后：

smartphone 发出信号；
Bluetooth Smart Tag 接收信号；
驱动 bra-pad 中对应装置。(谷歌专利)

这是非常明确的：

external device → wearable breast apparatus

第二个方向：bra-pad sensor → smartphone

文献又明确：

为了在 phone 上表示乳房的实际形状，可以在 bra-pad 上安装 contact sensor 和 position sensor，并通过 Bluetooth Smart Tag 将信息送给 phone 内的 3D program/App。(谷歌专利)

所以另一个方向是：

wearable breast apparatus → smartphone

两者组合后：

smartphone → bra-pad command
bra-pad sensor → smartphone

构成了非常明确的双向功能通信。

所以对于 D：

KR20150118366A → D = ●。

当然组合论证时必须解释：

为什么乳房佩戴式 Bluetooth massage device 的通信架构会被技术人员应用于智能乳房泵。

但这个组合动机并不弱，因为：

• 都佩戴在乳房；

• 都有 actuator；

• 都有传感器；

• 都有用户调节；

• 都要求外部 app 可视化/控制。

八、KR20150118366A 对 F 也很有贡献

F：

实时数据能够反映在外部设备屏幕上并更新屏幕。

KR20150118366A 明确设置手机 app 屏幕，包括：

• breast model；

• numbering table；

• level bar；

• time bar。(谷歌专利)

更加重要的是：

bra-pad 上的 contact sensor/position sensor 数据通过 Bluetooth Smart Tag 进入 phone 内的 3D program，使手机显示与真实 breast / bra-pad 状态相对应。(谷歌专利)

也就是说，它明确存在：

wearable sensor → Bluetooth → smartphone App → screen representation

这已经非常接近 F 的基本数据链。

严格讲，它没有逐字说：

screen is continuously updated in real time。

所以：

F = ●/○。

对于创造性非常好；

对于单篇严格新颖性，仍建议标成“强贡献”，而不是100%完全公开。

九、KR20150118366A 对 C/G 没有强公开

我目前没有找到：

• historical data stream；

• history log；

• historical download；

• live stream 与 historical stream 分开。

因此：

• C = —

• G = —

它适合专攻：

D + F

而不是历史数据。

十、韩国本土 H 文献：KR200466652Y1

KR200466652Y1《모유 착유기》

中文：母乳挤乳器/乳房泵

韩国本土申请。
申请/优先权：2011-07-18。
其公开文本包括：

• KR20130000616U：2013-01-28

• KR200466652Y1：2013-05-06。(谷歌专利)

所以公开时间毫无问题。

这篇对 H 的前半部分很明确。

十一、KR200466652Y1 对 H 的“空气抽吸”公开非常直接

它专门把：

공기의 흡·배기 통로
空气吸入/排出通道

和：

모유의 배출로
乳汁排出通道

分开设置。(谷歌专利)

工作时：

吸气阶段

自动泵吸气：

chamber 中空气被吸出；
breast 与吸着部之间的空气随之被吸走；
乳房/乳头受吸引；
母乳被挤出。(谷歌专利)

原文的工作关系非常清楚：

pump sucks air → suction is generated → milk is extracted。

这与 H 前半：

“对乳房采用空气抽吸以进行初始闩锁和泵吸”

高度一致。

所以：

H 的空气抽吸部分 = ●。

十二、它还公开后续乳汁排出，但不是目标 H 那种真正“milk hydraulic pumping”

在排出阶段：

自动泵反向排气，把空气推回 chamber；

空气作用使：

排出阀中积存的母乳经 outlet 排到奶瓶。(谷歌专利)

也就是：

air suction → milk extraction → milk accumulates → opposite pressure stroke → milk expelled through valve。

但是必须严格区分：

目标 H 要的是：

“然后转为利用所挤出的母乳以用于泵吸动作或动力。”

KR200466652Y1 仍然本质上使用：

空气压力作为驱动力

去推动乳汁。

它不是：

tubing primed with milk 后直接利用不可压缩 milk 作为 hydraulic working medium。

所以不能说完整公开 H。

评价：

H = ○，中等偏强的辅助文献。

它的价值在于把 H 拆成：

1. 空气抽吸乳房；

2. 母乳进入系统；

3. 后续单独排出母乳；

4. 空气通道与乳汁通道分别控制。

这几个基础步骤都已经存在。

十三、KR20130091863A：对可穿戴/隐蔽使用场景有辅助贡献

KR20130091863A《브레지어 유축기》

中文：文胸乳房泵

韩国本土申请人/发明人。
优先权：2012-02-09
公开日：2013-08-20。(谷歌专利)

它公开：

• breast pump 设置在 bra 中；

• breast cap 贴乳房；

• vacuum pump；

• milk container；

• 可以佩戴在身体上；

• pumping 时无需用手扶持；

• 用户可以同时做家务、兴趣活动；

• 设计目的之一是减少外形突出、避免不自然。(谷歌专利)

十四、它对 I 的“使用场景”有一点价值，但不能直接攻击 I

I的完整内容是：

active pause

• maintain latch vacuum

• virtually silent

• 用于需要与他人互动/不希望主动 pumping 的场景。

KR20130091863A 可以证明，临界日前韩国乳房泵领域已经明确考虑：

用户希望在穿戴泵的同时正常进行日常活动，而且尽量不显得突兀。(谷歌专利)

但它没有找到：

• pause；

• pause时维持 latch vacuum；

• pump停止后保持吸附；

• silent pause。

因此：

I = 很弱的目的/场景辅助。

绝对不建议把它作为 I 的主要证据。

十五、一个值得特别注意的韩国老文献：KR20040071258A

KR20040071258A《유축기 시스템》

Playtex Products

优先权：2001-12-27
韩国公开：2004-08-11。(谷歌专利)

这篇我也重新全文看了。

它本身：

• controller；

• user interface；

• pressure control；

• programmable breast pump；

• pumping sequences。

但是在 Google Patents 当前可检索文本中，我没有发现：

• memory data；

• live/history data；

• wireless；

• screen updating；

• pause。

所以相比 KR100755897B1，它对 A–G 的价值明显较低。

我的建议：

不把它列为当前韩文核心对比文件。

留下作为乳房泵 controller/programmability 的背景文献即可。

十六、当前韩文文献的严格 A–I 矩阵

我按比上一轮更严格的尺度评价：

其中：

● = 强/接近直接公开
○ = 明确贡献但不足以完整公开该特征
— = 当前不建议主张。

十七、这一轮最值得留下的组合

与其堆大量韩文弱文献，我认为这三件最有实际价值：

K1：KR100755897B1

负责：

A + B + E + G

其核心技术链：

pump operation signal/data
→ record/store
→ later retrieve
→ chip card
→ download to external computer。

这篇是本轮最重要的发现。(谷歌专利)

K2：KR20150118366A

负责：

D + F

核心技术链：

smartphone app → Bluetooth → breast wearable actuator

同时：

breast wearable sensor → Bluetooth → smartphone 3D/app screen。(谷歌专利)

所以它补 K1 最缺的：

外部智能设备双向通信+屏幕反映。

K3：KR200466652Y1

负责：

H 的空气抽吸及乳汁进入/排出工作阶段。

核心：

air suction → breast suction → milk extraction → valve controlled milk discharge。(谷歌专利)

十八、K1 + K2 的组合实际上很值得研究 A–G

把两件放在一起看：

K1，乳房泵本身已经公开：

运行数据生成
→ 保存
→ historical retrieval
→ download to computer。(谷歌专利)

K2，同样针对乳房穿戴装置已经公开：

smartphone app
↔ Bluetooth wearable breast device

• sensor information represented on phone screen。(谷歌专利)

所以到 2015-10-22：

把原来 breast pump 的 operation/history data 下载架构，换成当时已经成熟的 smartphone/Bluetooth wearable breast-device 通信架构

至少从技术发展脉络上并不突兀。

这对目标 A–G 的创造性攻击比仅用传统乳房泵文件要有意义得多。

十九、但 C 仍然没有被韩文文件真正解决

目前韩文方向最困难的依然是：

C：实时数据流与历史数据流分开保持。

K1有：

• current operating data；

• stored historical operating data。

K2有：

• Bluetooth sensor/command stream。

但是没有一件明确说：

“live data stream 和 historical data stream 作为不同数据流分别保持。”

因此我不会把 K1+K2 强行解释成 C 已经公开。

目前：

C = 韩文检索的核心缺口。

二十、I 也是明显缺口

韩国乳房泵文件中，我目前没有找到一件临界日前同时具有：

pause

• maintain breast latch vacuum

• silence/quietness。

特别是：

“暂停主动泵送但仍维持乳房吸附真空”

这一组合在韩文 2016-02-10 前公开文本中，目前没有出现强证据。

所以：

I 不能靠目前这些韩文文件独立打掉。

二十一、现阶段韩文文件价值排序

我建议无效检索底稿中这样排序：

第一梯队

1. KR100755897B1
最重要；主攻 A/B/E/G。

2. KR20150118366A
非常有意思的跨领域组合文件；主攻 D/F。

第二梯队

3. KR200466652Y1 / KR20130000616U
主攻 H 的前半及泵送阶段逻辑。

4. KR20130091863A
只适合作为 wearable/discreet-use 的背景证据。

当前韩文检索结论

与日文检索相比，这一轮反而找到了一件更好的数据类乳房泵文件：

KR100755897B1 已经在目标日前约十年明确公开“乳房泵运行数据记录、保存、后续下载到外部计算机”。

而 KR20150118366A 则进一步说明，在目标优先权日前：

乳房佩戴设备和 smartphone 通过 Bluetooth 双向传递控制信号和传感器信息，并将传感信息反映到手机 App/3D 屏幕

也已经属于已知技术。(谷歌专利)

因此，从韩文文献角度，目前最值得形成正式无效组合的是：

KR100755897B1 + KR20150118366A

用来重点攻击 A/B/D/E/F/G；
再用 KR200466652Y1 对 H 提供辅助。

**C 和 I 仍应继续专项检索，尤其应扩大到韩国 2010–2015 年的输液泵、负压治疗设备、可穿戴医疗设备和远程监控系统，而不能只搜“유축기”。**这两个特征是下一轮韩文深检索最有价值的目标。

按你这次的限定，我把检索口径进一步收紧了：只采用在 2016-02-10 之前已经公开的中文专利文本，并排除前几轮已经找到的英文、日文、韩文文献再反查出来的中文同族。 目标 CN113648473B 的最早优先权日为 2016-02-10，所以我按“公开日早于该日”执行。(谷歌专利)

这一轮有实质价值的新发现不少。最值得注意的是，中文文献已经可以把 A–G 的数据/手机架构拆得相当完整；对 I 也形成了“乳房保持负压 + 泵停止仍维持负压 + 吸奶器降噪”的三段式证据链。H 中最难的后半段——从空气过渡到直接以挤出的母乳作为液压泵送介质——仍没有找到临界日前中文文件直接公开。

一、这一轮最重要的中文文件

其中 CN105288759A、CN204520647U、CN202205202U、CN103605805A 等 Google Patents family 页面均显示中国单一申请/中国单一国家状态，尤其适合满足你“不以既有文件反查中文同组”的要求。(谷歌专利)

二、C1：CN105288759A——同领域攻击 A 的核心中文文件

CN105288759A《基于柔性压力传感器进行压力反馈控制的电动吸乳器》
申请人：上海师范大学
申请/优先权：2015-10-16
公开：2016-02-03，刚好早于临界日7天。 Google Patents 显示该 family 只有一个中国申请。(谷歌专利)

这件很重要，因为它不是泛医疗设备，而是吸乳器本身。

它明确公开：

• 压电薄膜传感器设置在吸乳护罩；

• 在吸乳过程中实时检测乳房承受的负压；

• 数据送入微控制器；

• 微控制器按毫秒采样时间处理；

• 根据实时压力数据计算并动态控制真空泵；

• 整个过程是实时闭环反馈控制。(谷歌专利)

说明书尤其明确：

压力 P 可由柔性压力传感器“实时测得”，采样时间单位为毫秒；

并且：

微控制器实时监控乳房与吸乳护罩之间的压力变化。

还进一步根据实时压力动态改变 PWM 占空比。(谷歌专利)

对 A 的判断

A要求：

生成和存储来自操作乳房泵吸系统的实时数据。

这里“生成实时数据”是非常直接的。

但是，我目前没有发现 CN105288759A 明确要求：

把这些实时数据持久存储下来。

所以不能把完整 A 评成100%直接公开。

我建议：

CN105288759A → A = ●/○

• 生成乳房泵实时运行数据：●

• 实时处理：●

• 存储实时数据：未明确

这件的战略价值在于先把：

“乳房泵本身产生实时过程数据”

牢牢落在同领域现有技术中。

三、C2：CN204520647U——目前中文方向攻击 A–G 最强的横向文件

CN204520647U《家庭智能健康监控一体机》
申请人：三明学院
申请/优先权：2015-03-11
公开：2015-08-05。 Family 仅一个中国申请。(谷歌专利)

虽然它不是吸乳器，但它属于：

传感医疗/健康设备 + 嵌入式控制器 + Android 手机 + Bluetooth + 实时数据 + 历史数据

技术架构与 A–G 异常接近。

这是这一轮非常重要的发现。

1. 对 D：几乎把“设备↔外部手机双向通信”写明了

说明书明确：

Android 智能手机客户端通过无线蓝牙发送指令来控制设备；

反方向：

Android 手机通过蓝牙接收检测数据，并存储到 Sqlite3 数据库。(谷歌专利)

所以：

手机 → 医疗设备：控制命令

以及：

医疗设备 → 手机：检测数据

两方向均直接存在。

更进一步，Bluetooth 模块明确：

支持设备与 Android 手机无线数据通信，并且支持全双工传输数据。(谷歌专利)

这对 D：

外部设备或程序与乳房泵之间具有双向通信

所采用的通信架构而言非常强。

当然它不是 breast pump，所以：

• 单篇新颖性：不能满足“乳房泵”主体

• 创造性横向组合：D = ●●

四、C2 对 F 也非常直接

文献明确：

用户通过 Android 智能手机启动测量；

随后：

当前测量结果通过 Android 智能手机显示出来。(谷歌专利)

它同时明确系统实现：

人体数据的实时记录；

和：

实时监控人体生理数据传送至远程监控中心。(谷歌专利)

因此其技术链就是：

设备实时检测 → Bluetooth → smartphone → 当前结果显示。

对 F：

实时数据反映在外部设备屏幕并更新屏幕

属于非常强的横向公开。

F = ●/○

唯一需要保守的是文献没有逐字使用：

“continuously update the screen”

但功能上当前检测结果进入手机并显示已经非常接近。

五、C2 对 B、E、G 也很有价值

文献明确说：

手机接收到检测数据后，将数据存储到 Sqlite3 database；

然后：

对所存储的历史数据进行分析。(谷歌专利)

而手机页面可以：

随时查看不同时间段数据；

并以：

折线图显示整体历史变化趋势。(谷歌专利)

所以它已经具备：

当前设备数据 → 外部手机 → 数据库 → 历史数据 → 非实时趋势页面

这一完整技术链。

对应：

• B = ●

• E = ●，设备过程数据写入外部设备数据库

• G = ●/○

G不能完全打成●，因为目标措辞要求：

外部设备“下载”乳房泵中的历史数据。

而 C2 更接近：

手机在每次测量时收取数据并逐渐形成历史数据库。

但 G 的后半：

历史数据用于更新非实时历史视图/趋势图

是非常明确的。

六、C3：CN202205202U——对 E、G 比 C2 还更接近

CN202205202U《基于蓝牙计步器的运动数据管理系统》
中国本土申请
申请/优先权：2011-07-29
公开：2012-04-25。
Family 仅一个中国申请。(谷歌专利)

这篇对目标的：

设备内部历史记录 → Bluetooth → 外部设备下载 → 历史页面

非常值得重视。

它明确在可穿戴计步器内部设置：

• sensor；

• MCU；

• time memory；

• 第一存储装置；

• Bluetooth。

工作过程：

传感器监测数据 → 加时间戳 → 存入第一存储装置；

当需要上传时：

Bluetooth 扫描第一存储装置中的带时间戳数据，然后上传。(谷歌专利)

这已经和 E/G 的数据流非常接近。

对 E

目标 E：

乳房泵将过程数据写入其内部历史记录日志和/或外部设备。

C3明确：

可穿戴设备传感数据在设备内加时间戳并写入第一存储装置。

然后又：

外部智能终端接收后写入第二存储装置。(谷歌专利)

也就是两边都写：

device internal storage + external device storage

这正是 E 的基本数据架构。

E = ●● 横向证据。

七、C3 对 G 非常强

外部智能终端明确：

从可穿戴设备接收存储的运动数据；

随后：

根据时间戳分析；

对历史数据进行比较；

以各种图表表现一定时期内上传的数据；

通过显示屏呈现给用户。(谷歌专利)

说明书甚至明确把目标描述为：

用户通过智能终端上传“各时期历史数据”，通过服务器存储、统计、对比，并取得数据图表展示。(谷歌专利)

所以如果暂时去掉“breast pump”这个应用领域：

G 的数据动作已经非常接近完整公开。

技术链为：

wearable device history storage
→ Bluetooth history upload
→ external smartphone/tablet/PC
→ history analysis
→ non-real-time historical charts.

因此：

G = ●● 横向证据。

在我目前找到的中文文件里，它是专攻 E/G 最值得保留的一件。

八、C4：CN103605805A——目前专攻 C 最强的中文文件

这是本轮另一个关键发现。

CN103605805A《一种海量时序数据的存储方法》
申请人：冶金自动化研究设计院
申请：2013-12-09
公开：2014-02-26。
Google Patents 显示 family 只有一个中国申请。(谷歌专利)

目标 C 是：

保持将实时数据流与历史数据流分开。

这件文献不是简单提到“实时”和“历史”两个概念，而是非常明确地做了分流处理。

首先，它按照数据新旧将数据明确分成：

“历史数据”
和
“实时数据”。

还明确规定：

实时数据和历史数据存在一个分割时刻。(谷歌专利)

接下来更加关键：

把实时数据存储于实时数据表中，把历史数据存储于历史数据表中。 (谷歌专利)

两者甚至采用不同存储结构：

• 实时数据：简单行存储；

• 历史数据：段存储。(谷歌专利)

说明书专门设一节：

“数据流动”

其中规定数据写操作按照类型分别写：

实时数据→实时数据表；

历史数据→历史数据表。(谷歌专利)

对 C 的判断

如果把 C 的“stream”理解为：

实时数据和历史数据形成不同的数据处理/存储路径并保持区别，

那么 CN103605805A 是非常强的公开。

C = ●● 横向证据。

它甚至比前面日韩方向找到的文件更适合专攻 C。

当然：

它不是乳房泵。

因此，我不会说 CN103605805A 单独破坏权利要求1的新颖性。

但对于创造性组合：

已经存在实时数据/历史数据 → 按用途分开 → 分别保持在不同数据表/数据处理路径

这件事情在 2014 年就是明确的数据处理技术。

这会显著削弱 C 单独作为创造性贡献的空间。

九、C5：CN104799831A——A/B/C/D/E 的另一件可穿戴证据

CN104799831A《一种用于情感监测的可穿戴设备》
申请人：夏新科技、四川九洲电器集团
申请：2015-03-18
公开：2015-07-29；family只有中国申请。(谷歌专利)

它明确具有：

• sensors；

• processor；

• memory；

• display；

• Bluetooth。(谷歌专利)

尤其关键的一句话：

蓝牙芯片将存储器中的历史数据或实时信息上传到智能手机或者云服务器。(谷歌专利)

并且：

模型在 wearable processor 和 smartphone/cloud 之间通过 Bluetooth 同步。(谷歌专利)

此外明确：

综合分析历史和实时数据；

以及：

存储器中的历史和实时数据上传到智能手机。(谷歌专利)

所以它非常适合补强：

• A：实时信息生成；

• B：历史信息；

• E：存储后向外部设备传输；

• C：明确将两类数据作为不同类别处理，但没有 CN103605805A 那么强；

• D：模型存在外部终端和 wearable 之间同步，但“设备控制命令”不如 CN204520647U 明确。

因此我把它作为 A–G 的辅助组合文件，而不是首选。

十、H/I方向：CN204890738U 很重要

CN204890738U《吸奶器》
申请人：Philips
优先权：2014-06-05
中国申请：2015-06-04
中国公开：2015-12-23。 (谷歌专利)

说明一下：这件虽然申请人为 Philips，但不是前面已经检索出的 JP2013532540A 那一族——其优先权日期、技术内容均不同；我是本轮中文检索独立命中的，因此没有违反“不反查已经检索文件中文同组”的条件。

这件对 latch 非常好。

十一、CN204890738U 已经明确公开“附连模式/latch模式”

它把乳房泵分成两个模式：

第一模式：附连模式

真空泵产生：

恒定负压

作用是：

允许乳房接收漏斗附连到乳房。(谷歌专利)

而且描述得非常明确：

乳房在恒定负压下被稍微吸入漏斗，挤奶套件“粘”到乳房上，即使妈妈松开手仍然保持附连。(谷歌专利)

这实际上就是目标专利中：

latch vacuum / 闩锁真空

的核心技术含义。

随后才能：

启动 milk extraction mode；

后者采用随时间变化的负压曲线进行主动吸乳。(谷歌专利)

因此：

对 H 前半

initial vacuum → establish breast attachment/latch → switch to pumping mode

贡献很强。

对 I

维持 latch vacuum 本身

贡献非常强。

但这件没有说：

pause 主动泵送时仍保持 latch；

也没有说：

virtually silent。

所以 I 不能靠它单篇完成。

十二、C6：CN1919365A——I 中“泵停止但负压保持”的关键横向文件

CN1919365A《带给药系统的灸火罐》
中国本土申请
申请：2005-08-25
公开：2007-02-28。 (谷歌专利)

虽然不是吸奶器，但它属于：

贴附人体皮肤的真空医疗设备。

而且它恰好公开目标 I 最有价值的控制逻辑。

工作方式：

真空泵工作，使负压增加；

达到设定负压：

限位开关断开，真空泵停止工作；

与此同时：

常闭截止阀关闭；

结果：

罐内负压处于保持状态。 (谷歌专利)

负压下降以后：

真空泵重新工作。

说明书还明确总结：

火罐内总是保持设定负压值。(谷歌专利)

这实际上已经完整公开一种：

人体吸附负压设备 → 达到负压 → pump off → valve closed → vacuum held → 必要时 pump restart

的控制原理。

对 I 的意义非常大

I技术核心之一：

主动泵送暂停，但是 latch vacuum 仍然保持。

CN1919365A恰好表明：

“为了保持附着/治疗负压，并不需要真空泵持续工作；可以停止泵并用阀封闭负压腔。”

因此：

I中“暂停动力泵但维持负压” = ● 横向贡献。

而且 pump off 后：

由泵机械运转造成的主要噪音自然消失。

不过这里后一句属于技术推论，不是 CN1919365A 自己明确说“silent”。

因此还需要下一件中文文件。

十三、C7：CN203763554U——I 中“吸奶器低噪音”的同领域证据

CN203763554U《一种电动吸奶器的主机》
中国本土申请
申请：2014-01-25
公开：2014-08-13。 (谷歌专利)

它专门解决：

吸奶器泵工作噪音。

明确说明：

泵体工作产生噪音、振动；

本实用新型的目的就是：

有效降低噪音。 (谷歌专利)

采用：

• 封闭泵体壳体；

• 密封结构；

• 减震海绵；

• 减震垫；

阻隔泵工作噪音传递。(谷歌专利)

其摘要直接说：

有效阻隔泵体工作噪音向外传递，从而有效降低电动吸奶器主机工作噪音。(谷歌专利)

所以：

I 中“保持无声/低声使用”的需求本身并非新的技术目的。

这件不是 pause 文件，但它与：

• CN204890738U：latch vacuum；

• CN1919365A：pump stop + vacuum held；

组合非常有意思。

十四、I目前形成的中文三段证据链

C5 / CN204890738U

已经知道：

乳房可以靠恒定 latch vacuum 持续粘附。 (谷歌专利)

↓

C6 / CN1919365A

已经知道：

达到目标负压后可以停止真空泵，同时关闭阀，仍保持附着负压。 (谷歌专利)

↓

C7 / CN203763554U

吸奶器领域已经明确认为：

减少泵运行噪音是需要解决的用户体验问题。 (谷歌专利)

因此目标 I 的物理工作状态：

active pumping停止

• latch vacuum不释放

• pump noise消失/显著下降

在中文现有技术中已经可以拆成非常紧密的技术组合。

真正剩下的目标文字是：

“为了与他人互动或者暂时不希望进行主动泵吸”。

这更像使用场景/目的性描述；是否构成创造性上的实质技术贡献，应在正式无效论证中结合审查标准判断，我这里只作技术证据分析。

十五、H：找到多件中国本土同领域文件，但必须严格区分“部分公开”和“完整公开”

CN203609694U《一种液气隔离式吸乳器》

中国本土申请，申请2013-10-23，公开2014-05-28，family只有中国一个申请。(谷歌专利)

它明确：

吸力装置吸气；

↓

吸乳罩内部变成负压；

↓

乳汁被吸入吸乳罩；

↓

泄气时乳汁在自身重力下流入承接瓶。(谷歌专利)

所以 H 前半：

空气抽吸 → 对乳房产生负压 → 母乳进入系统

公开非常清楚。

但是它反而强调：

液气完全隔离

且后续乳汁靠重力流入瓶子。

所以：

H整体 ≠ 直接公开。

甚至在“母乳成为后续液压泵送介质”这点上，它走的是相反技术路线。

十六、CN102380134A同样只能用于 H 前半

CN102380134A《一种电动控制的吸奶器》
中国本土申请
申请：2011-11-25
公开：2012-03-21。 (谷歌专利)

它采用：

电动气泵抽空气；

↓

膜片变形；

↓

负压腔、阀腔、吸奶部产生负压；

↓

从乳房吸出奶汁。(谷歌专利)

当抽气停止：

膜片恢复；

负压消失；

停止吸奶。(谷歌专利)

因此也是：

空气驱动负压 → 母乳进入

非常清楚，但并不是：

转换到以母乳自身作为液压泵送介质。

H = ○，只适合辅助。

十七、关于 H，这轮中文检索需要保持一个重要结论

我针对：

• “乳汁 不可压缩”

• “乳汁作为泵送流体”

• “空气→母乳”

• “液压吸乳器”

• “管路充满乳汁”

• “乳汁作为介质”

反复扩展检索。

确实能够检索到后来的中文公开，例如一些文献明确出现：

管路最终大部分充满乳汁，由于乳汁基本不可压缩，系统成为近似全液压系统；

但这些中文文件的公开日都在2016-02-10以后，因此这一轮不能使用。比如 CN107182202B 所述体系就是如此。(谷歌专利)

所以我目前不会为了“填满矩阵”而强行把 CN203609694U 等说成完整 H。

当前中文结果：

H前半：中国现有技术非常充分。

H后半“母乳成为实际泵送/液压介质”：目前没有找到满足公开日条件的新中文单篇。

这里仍然是此前英文文件更强。

十八、完整 A–I 中文特征矩阵

评级：

• ●● = 对该特征非常强

• ● = 明确实质贡献

• ○ = 部分公开/组合辅助

• — = 当前无实质贡献

十九、目前最值得形成正式无效组合的中文路线

路线一：专攻 A–G

我建议优先研究：

CN105288759A + CN204520647U + CN202205202U + CN103605805A

逻辑非常清晰。

CN105288759A

把应用主体落到乳房泵：

吸乳器本身实时生成、实时处理过程压力数据。(谷歌专利)

CN204520647U

给出：

智能设备 ↔ smartphone Bluetooth全双工；

phone发送控制命令；

device返回实时数据；

phone显示当前数据；

phone数据库形成历史数据和历史折线图。(谷歌专利)

CN202205202U

进一步给出：

wearable内部记录带时间戳数据；

内部历史存储；

Bluetooth上传历史记录；

外部智能终端存储、分析；

历史数据图表显示。(谷歌专利)

CN103605805A

最后补上目标最特别的 C：

实时数据与历史数据分类；

实时数据表与历史数据表分开；

分别读写；

不同存储结构和数据流动路径。(谷歌专利)

这样 A–G 中最难的 C 已经不再是没有先例的架构。

二十、路线二：专攻 I

建议：

CN204890738U + CN1919365A + CN203763554U

分别对应：

① latch vacuum
CN204890738U：

恒定负压使吸奶器粘附乳房，即使松手仍保持。(谷歌专利)

② pump-off but vacuum maintained
CN1919365A：

达设定负压 → 泵停止 → 截止阀关闭 → 负压保持。(谷歌专利)

③ quiet breast pump
CN203763554U：

吸奶器工作噪音本身就是明确需要降低的技术问题。(谷歌专利)

这是目前中文检索对 I 最有潜力的一条组合路线。

二十一、路线三：H建议只把中文材料作为辅助

可以用：

CN204890738U + CN203609694U / CN102380134A

证明：

• 初始真空吸附/latch；

• 空气抽吸；

• 乳汁由负压挤出；

• 乳汁随后进入输送通路。

但：

“之后转为利用挤出的母乳作为泵送动作或动力”

这一后半，在本轮满足临界日要求的中文文本里，我仍没有找到一件可以安全判定直接公开的文献。

因此 H 的主攻击文件仍应以此前找到的英文早期文件为核心，中文文件只做技术背景/组合辅助，不建议反过来。

二十二、这一轮相比前几轮最有价值的新进展

中文方向真正补上了之前最大的两个洞：

第一，C现在有了非常强的独立现有技术：CN103605805A。

它明确：

realtime / historical 分类 → 分表 → 分路径存储/读取。(谷歌专利)

第二，I现在形成了完整得多的技术组合：

吸奶器 latch vacuum

• pump停止仍保持负压

• 吸奶器降低泵噪音。

而且三部分全部在 2016-02-10之前已经中文公开。(谷歌专利)

所以，如果把前面英文、日文、韩文和这一轮中文结果合在一起看，权利要求1现在真正最值得继续死磕的已经不是 C，而是 H 后半“milk as pumping medium”的单篇中文证据，以及 I 中是否还能找到一件乳房泵本身直接写出“暂停主动泵送+保持latch vacuum”的临界日前文件。这两点如果再找到直接文件，整个 A–I 证据链会明显更完整。

综合目前已经检索到的英文、日文、韩文、中文对比文件，并重新核对核心文献后，我认为权利要求1真正应当主攻的是创造性，而不是新颖性。CN113648473B 权利要求1确实把 A–I 全部并入一个方法权利要求，Google Patents 所示最早优先权日为 2016-02-10；而 WO2016014488A1、WO2016014494A1 均在 2016-01-28 已经公开。(谷歌专利)

我的最终判断是：

最优主组合：D1 WO2016014488A1 + D2 WO2016014494A1 + D3 CN103605805A。

权利要求1因缺乏创造性被全部无效的工作概率：约 60%–70%，中心估计约 65%。

如果在无效请求中同时布置针对 G、I 的备用组合，而不是只提交这一条理由，我会把最终权利要求1被无效的综合概率估在约 65%–75%。

单纯依靠新颖性理由，我只给 5%–10%。

这不是统计学概率，而是基于目前证据覆盖程度、组合动机、可能的权利要求解释和中国创造性审查标准给出的案件风险区间。

一、为什么必须以 WO2016014488A1 作为最接近现有技术

这是目前所有文献里毫无疑问的第一主证据。

中国《专利审查指南》的创造性三步法要求优先选择技术领域相同或相近、尤其与发明所解决技术问题相关的现有技术作为最接近现有技术；创造性可以把一份或多份现有技术中的技术内容组合起来评价，但最终必须考察现有技术整体是否给出了组合的技术启示。(国家知识产权局)

D1 的优势不是简单“命中特征多”，而是它本身就是：

同一种可穿戴乳房泵 + 同样的 controller + external computer/app + latch suction + 实时反馈 + 历史 pumping sessions + pause。

它明确公开 controller 向 external computer 发送并接收信号，外部计算机又把定制泵参数发送回 controller，并可以在 pumping session 中 real time 完成；外部计算机还能追踪 previous pumping sessions、日期、历史泵奶量，并根据泵数据形成 histogram。(谷歌专利)

D1 甚至明确：

• Bluetooth 在外部设备进入范围后自动发送数据；

• 未发送的数据可以之后自动补发；

• app 可以按 days、weeks、sequential pumping sessions 显示历史趋势；

• controller/app 可以比较 multiple sessions 并保存结果；

• controller 可把运行期间的参数变化存入 memory。(谷歌专利)

因此，A/B/D/E/F/G 这一整个“智能乳房泵数据架构”的绝大部分，其实已经存在于 D1。

二、D1 对 I 的强度也需要上调

前几轮我对 I 比较保守；深入复核全文后，我认为 D1 对 I 的杀伤力应从“中等”提升到中高—高。

它明确说：

controller 可以 pause the pumping cycle，在预定 pause time 后恢复，而且把这一阶段直接描述为 pause times without pumping。(谷歌专利)

更重要的是，同一文献明确出现：

pause periods during which only latch suction is applied to the breast。(谷歌专利)

即已经具备：

暂停主动泵送 + 仍然保持 latch suction。

这就是 I 的机械/控制核心。

D1 背景部分还明确把该乳房泵的产品需求定位为：

user-friendly、quiet、discrete，并适于妈妈在不同场景中使用。(谷歌专利)

真正没有逐字出现的，只剩：

“Active Pause Mode”这个名称；
“virtually silent”这个程度词；
“需要与他人互动、不希望别人听到泵”这一具体使用目的。

所以 I 已经不是一个真正大的结构性缺口，而主要是名称、程度和使用情境上的剩余差异。

这也是我把整体无效概率上调的一个主要原因。

三、D2 WO2016014494A1 是 H 的决定性文件

D2 和 D1 的结合动机极强。

两者均：

• Exploramed NC7；

• 最早优先权 2014-07-22；

• 申请日 2015-07-21；

• 公开日 2016-01-28；

• 发明人包括 John Y. Chang、Joshua Makower 等；

• 使用相同的系统平台、controller、tube/compression member 等体系。(谷歌专利)

这种关系比“两个不同公司、不同医疗设备的随机拼接”强得多。

H最关键的第一句话，D2几乎逐字命中

D2明确：

在开始 milk pumping/extraction session 时，tubing 32 内存在空气；

并明确：

该 initial air volume 必须先被泵到 collection container，以 prime the pumping system。(谷歌专利)

然后它明确区分：

pumping air versus pumping milk，

并说明：

tubing 内有空气时，为形成相同压力变化，compression member 需要更大的位移；
管路进入乳汁状态以后，泵送行为发生变化。(谷歌专利)

这已经非常接近 H：

air → prime/latch → milk fills pumping conduit → pumping behavior transitions to milk-filled hydraulic system。

“用乳汁完成泵送”也有直接结构依据

D2进一步明确：

compression member 38 产生 positive pressure，直接把 tubing 中的 milk 推入 collection container。(谷歌专利)

同时：

达到 latch suction pressure 后 compression member 36 封闭管路，从而确保 latch pressure 保持在乳房上。(谷歌专利)

所以 H 的技术序列实际上已经相当完整：

空气建立/启动系统 → 乳汁进入管路 → 压缩含乳汁管路 → 乳汁作为被直接施压和传递泵送力的流体 → 排入容器。

我现在对：

D2 → H

给 90%左右的技术覆盖置信度。

H不再是本案最大风险点。

四、真正剩下的核心差异是 C

C要求：

保持实时数据流与历史数据流分开。

D1虽然已经分别处理：

• real-time feedback/current session；

• previous sessions/history/histograms；

但没有检出目标权利要求那种明确：

“live data stream and historical data stream are maintained separately”。

所以，主组合里第三件应当用：

D3：CN103605805A

它明确设置：

• 实时数据表；

• 历史数据表；

并专门定义“数据流动”。

实时数据先写入实时数据表，数据变旧后迁移进入历史数据表；而实时数据和历史数据在写入、读取和存储结构上分别处理。(谷歌专利)

因此，单看 C 的技术思想：

当前数据与历史数据具有不同访问特性 → 分开维护 → 分别存储/处理

D3 是目前所有中文、日韩文件中最干净的证据。

但 D3 是主组合最大的法律风险

它毕竟是：

HBase/海量时序数据存储，

不是乳房泵。

专利权人最强的反击肯定会是：

“本领域技术人员为什么会从一个可穿戴乳房泵跳到企业级海量时序数据库？”

所以无效请求的论证不能写成：

“D3公开C，所以把D3加到D1即可。”

这样很容易被认为是事后拼凑。

正确的实际技术问题应该表述成类似：

在 D1 已经同时处理当前 pumping data 和跨 pumping session 的历史数据的情况下，如何使具有不同更新频率、访问时效和显示目的的数据得到适合各自用途的存储和访问。

不能把技术问题写成：

“如何把实时数据和历史数据分开。”

因为这等于直接把区别特征塞进技术问题，容易落入 hindsight。

《审查指南》也明确要求技术问题应由区别特征产生的技术效果确定，不能包含对区别特征本身的指引；而如果技术问题会促使本领域技术人员寻找其他领域的技术手段，可以考虑其他领域的相关现有技术。(国家知识产权局)

五、最优三篇组合的 A–I 完整覆盖

D2 本身还明确记录并存储 extraction date/time、volume 等信息，乳房泵的数据可以自动或手动发送至 external computer，并关联到外部数据库，所以它对 A/B/E 也能够补 D1，而不仅仅是 H 文件。(谷歌专利)

六、G并没有看起来那么危险

目标 G 使用比较具体的文字：

外部设备“download”历史数据，更新 non-live view screens。

D1没有这句逐字表述。

但它已经明确：

controller 在存在尚未发送的数据时，进入通信范围即可自动发送；

同时：

external app 接收 pumping data 后按照 days、weeks、sequential sessions 形成 histogram/history trend。(谷歌专利)

因此其实际技术过程已经是：

乳房泵中未传数据 → 后续传到 external computer → external app形成跨日/周/session历史页面。

这与 G 之间主要是措辞差异，而不是技术体系差异。

如果合议组采取功能/实质理解，G 对专利权人帮助有限。

七、I建议单独设置两条备用攻击理由

虽然 D1 已经非常接近 I，我仍不建议把全部赌注压在“pump pause当然就 silent”的推理上。

第一备用：D1 + CN203763554U

CN203763554U 是乳房泵本领域文献，明确指出电动吸奶器的泵体工作会产生噪音和振动，并把“有效降低噪音”直接作为技术问题。(谷歌专利)

因此可以论证：

D1已经明确主动 pumping pause、pause时仅维持 latch suction，又明确追求 quiet/discrete；
本领域同时已知主动泵的机械运动正是噪声来源，因此在pause阶段减少/停止驱动以达到安静状态，是非常自然的技术结果或优化目标。

这条比跨领域的真空拔罐文献结合动机更自然。

第二备用：D1 + CN1919365A

CN1919365A不是乳房泵，但它非常干净地公开：

达到规定负压 → 真空泵停止工作 → 截止阀关闭 → 负压保持。(谷歌专利)

所以它专门证明一个基础真空控制原理：

保持吸附负压并不必然要求真空泵持续运行。

如果专利权人主张：

“D1虽然pause，但没有证明pause期间真正能做到泵停止、无声、而又保持latch”，

CN1919365A就是非常好的后手。

八、G的最佳备用文件不是日韩文件，而是 CN204520647U

CN204520647U 本身已经具有：

• 健康设备；

• Bluetooth；

• Android smartphone；

• 手机控制设备；

• 当前检测数据显示；

• 历史数据存储/分析；

• 历史折线图；

• Bluetooth full duplex。(谷歌专利)

所以如果 D1 的：

“自动传输历史未发送数据 → 外部 app历史图”

仍被认为没有明确满足 G，可以把 CN204520647U 放在备用创造性组合中，而不是主组合中。

原因是：

它与 D3 相比，对“医疗设备→智能手机→当前页面/历史页面”的技术问题更接近；

但它对 C 的“保持两类数据流分开”又没有 D3直接。

所以两者作用不同：

D3补C；CN204520647U补G/F/D的争议解释。

九、目前所有对比文件的最终分级

WO2016014469A1 与 D1/D2 同样是 Exploramed NC7、2014-07-22优先权、2016-01-28公开，技术上非常接近，但因为 D2 已经对 H 提供更精确的“air→milk”描述，所以我不会把它塞进主组合增加文件数量。(谷歌专利)

KR100755897B1、JP2013102867A、CN202205202U、US20140263611A1 等仍是好的备用证据，但在 D1/D2 已经把同领域主体架起来后，再加入这些文件不会明显提高主攻击的质量，反而可能让组合显得碎片化。(谷歌专利)

十、我建议正式无效理由不要只写一个“大杂烩组合”

最有效的提交结构是分层设置：

1. 主理由：D1 WO2016014488A1 + D2 WO2016014494A1 + D3 CN103605805A → 权1不具备创造性。

2. 第一备用：D1+D2+D3+CN203763554U → 专门封堵 I 的“silent”。

3. 第二备用：D1+D2+D3+CN1919365A → 专门封堵 I 的“暂停动力但保持真空”。

4. 第三备用：D1+D2+D3+CN204520647U → 专门封堵 G 的“历史数据→非实时外部视图”。

我不建议直接写：

D1+D2+D3+D4+D5+D6+D7……

这种六七篇拼接。

中国创造性审查虽然允许多篇现有技术组合，但仍要求存在技术启示和改进动机；文件越多，专利权人越容易强调“只有看过涉案权利要求后才知道如此拼装”。(国家知识产权局)

十一、专利权人最可能抓住的三个点

第一：C不是“数据库分表”，而是“通信数据流分离”

这是对方最强的抗辩。

如果合议组把：

“实时数据流与历史数据流分开”

解释成非常具体的：

pump↔app communication protocol 中分别维护 live stream 和 history stream，

那么 CN103605805A 的 realtime/history table separation 就不是完全等同。

这一个解释可以把案件成功率从约 70% 拉回 50%左右。

因此 C 的权利要求解释和说明书上下文会是口审重点。

第二：I是一个完整“Active Pause Mode”，不是普通pause

对方会说：

D1的pause只是为了乳房refill；
涉案专利pause的技术目的是用户社交，而且要求 virtually silent，同时不能掉泵。

但请求人一侧的优势是：

D1已经同时公开：

pause without pumping；

以及：

pause period 中 only latch suction。(谷歌专利)

所以涉案权利要求真正新增的技术结构非常有限。

“为了与他人互动”更偏向这一已经存在的工作状态的使用场景，而不是新增硬件结构。

这是对请求人明显有利的一点。

第三：H到底怎样解释“利用母乳以用于泵吸动作或动力”

这是第二个需要重点准备口审解释的问题。

如果解释成：

乳汁进入管路后成为受到压缩元件直接作用、传递泵压力的基本不可压缩工作流体，

D2非常强。

如果专利权人试图把它收窄成：

“母乳本身必须成为某种特殊意义上的动力源”，

则要回到目标说明书界定该术语。

D2明确区分 air-filled tubing 和 milk pumping，而且以 compression member 直接对 milk-filled tubing 施加正压力，把乳汁泵送到容器，这给请求人提供了很扎实的物理依据。(谷歌专利)

十二、概率评估

因此，如果现在必须给一个单一数字：

我会把 CN113648473B 权利要求1最终因创造性不足而被无效的当前工作概率定在约 68%。

这个概率不是来自“文献数量很多”，而是来自一个很特殊的证据结构：

D1和D2在目标优先权日前仅约两周已经公开，而且来自与目标技术高度连续的同一乳房泵平台；它们共同把乳房泵的数据通信、历史分析、实时控制、pause/latch，以及 air→milk 液路泵送的主体结构基本搭完。

剩下真正需要依靠跨文件补入的核心技术思想主要就是 C。而一旦 C 被认定只是已知的实时/历史数据分流手段，权利要求1剩余的创造性空间会明显收缩。根据现行专利法，申请日/优先权日前在国内外为公众所知的技术均可构成现有技术，因此这两件 2016-01-28 的 WO 公布本身具备作为现有技术使用的基本时间条件。(国家知识产权局)

下一步最值得投入检索资源的只有一个方向：继续寻找 2016-02-10 前、最好是“乳房泵/医疗泵/可穿戴医疗设备”领域内，明确写出 live/current data 与 historical data 使用独立通信或存储流的文件。 如果能找到一件比 CN103605805A 更接近医疗设备领域的 C 文件，我会把当前约 68% 的中心概率上调到 75%上下。

# CN113648473B 权利要求1无效补充检索报告：围绕 C/G 双路径数据架构、I 主动暂停保真空及桥梁文件

## 核心结论

本轮补充检索基本验证了你提出的检索重心调整，而且出现了几件**比“普通数据库文献”明显更有价值的新候选**。CN113648473B 的授权权利要求1确实同时限定了：实时运行数据、历史运行数据、两类数据流保持分开、与外部设备双向通信、实时界面更新、历史数据下载后更新非实时界面、空气泵送向乳汁泵送的转换，以及“主动暂停但维持 latch vacuum、使泵保持安静”的模式。该专利最早优先权日为 **2016年2月10日**；本报告严格沿用你设定的硬筛选标准，只把 **2016年2月9日及以前已公开**的文献作为可进入主证据池的候选。citeturn13view0turn13view2

本轮最重要的发现不是又增加了若干 A/B/D/E/F 文献，而是以下四点：

| 结论 | 本轮发现 | 战略意义 |
|---|---|---|
| **C 出现了很强的医疗领域直接候选** | Dexcom 的 US20140184422A1 明确区分 substantially real-time data 与 historical data 的传输策略，并明确说明历史数据较不具时间敏感性；gateway 还可以取得 current 和 historical data | **目前最值得替换通用数据库 C 证据的候选** |
| **C+G 出现了非常强的 reconnect/backfill 候选** | Fitbit US20140172362A1：设备本地保存断连期间数据，重新进入连接/应用打开后先高速下载 stored backlog，然后进入另一速率的 substantially real-time updates | 很接近你要找的“live + stored history + reconnect catch-up”架构 |
| **同领域桥梁文件得到明显加强** | Medela CN105247563A：乳房泵 + smartphone + pumping logs/performance graphs + real-time feedback + pump communication/closed-loop control | 可显著削弱“把医疗数据体系移植到吸奶器属于事后拼凑”的抗辩 |
| **I 找到重要的独立同领域补强，但还未达到完美停止条件** | Medela US20080255503A1/US8070715B2：泵停止继续抽真空后，压力调节机构仍把系统保持在 minimum vacuum；该最小负压还明确用于使 breastshield 保持在乳房上 | **直接消灭“I 中 pump-stop 与 vacuum-hold 不兼容”这一解释空间**，但尚缺“用户主动 pause + 明示 silent”同篇完整公开 |

因此，本轮最有价值的证据结构不是“再扩充 D4、D5、D6”，而是：

> **以原 D1 继续作为同领域基础文件；用 Dexcom US20140184422A1 主攻 C 及其技术动机；用 Medela CN105247563A 证明吸奶器领域本身已经存在实时反馈、历史泵送日志、手机交互与闭环控制；对 I，则以 D1 为主、Medela US20080255503A1/US8070715B2 作为独立同领域技术补强。**

如果你现有 D1 的内容确如你所述——已经有 “pause without pumping / only latch suction”——那么**I 不宜再强行加入另一篇文献作为必需区别特征文件**。Medela 文件的最佳用途是证明：在吸奶器领域，让主动抽真空停止而仍通过阀/压力控制保持足以附着乳房的最小负压，在临界日前早已存在，从而压缩专利权人围绕 I 的技术效果进行创造性解释的空间。citeturn16view4turn17view1

另一方面，**H 本轮没有找到满足你停止条件的独立新族**。精确搜索再次高度命中 Exploramed 的 WO2016014469A1/US9539377 系列，其中明确涉及 milk incompressibility，但该结果正是你要求排除的已知 Exploramed 族；因此 H 暂时仍应让 D2 承担，不值得重新扩展普通乳房泵检索。citeturn22search2

从当前证据质量看，我会把你原先约 **68%** 的中心判断做**有限而非激进的上调**：在假定 D1、D2 的现有摘录准确且同族/公开日没有问题的前提下，本轮成果更接近 **约 76%–81% 的研究层面区间**。这不是统计意义上的法律胜诉概率，而是对证据链完整度的主观评估；之所以没有直接提高到更高区间，是因为 **C 已经显著加强，但 I 仍未找到一篇独立乳房泵文件把“用户主动暂停 + 停止主动泵送 + latch vacuum + silent”四项完整写在一起**。这一判断属于基于下述现有技术证据的分析性推断。citeturn6view1turn21view3turn16view4

## 权利要求结构与当前无效评价框架

CN113648473B 是 Willow Innovation 相关乳房泵数据处理技术的中国授权文本。授权权利要求1可以较稳定地拆解为以下 A–I；这一拆分是本报告为了检索与无效分析所作的工作性标记，而不是专利原文中的标号。citeturn13view0

| 标记 | 授权权利要求1中的实质限定 |
|---|---|
| **A** | 生成并存储与乳房泵操作有关的实时数据 |
| **B** | 生成并存储历史数据 |
| **C** | 将实时数据流与历史数据流保持分开 |
| **D** | 外部设备/程序与乳房泵之间进行双向通信 |
| **E** | 乳房泵把过程数据写入内部历史日志和/或外部设备 |
| **F** | 实时数据反映在外部设备屏幕上，并用于更新实时显示 |
| **G** | 外部设备下载历史数据后更新非实时/历史视图 |
| **H** | 初始 latch / pumping 使用空气，随后转为利用所表达的乳汁进行泵送作用/动力传递 |
| **I** | active pause 时不进行主动泵送，但仍保持 latch vacuum，并使泵能够保持安静以便用户交互 |

目标说明书本身把 C 描述成对 live data 与 historical data 采取不同处理并使两种数据流保持分离；又明确描述外部设备取得历史数据用于更新 non-live view。对于 I，说明书明确把 active pause 与保持 latch vacuum、接近无声的运行状态联系在一起。citeturn13view0turn13view3

你的检索战略与现行中国创造性评价规则是吻合的。2025年《专利审查指南》修改自 **2026年1月1日**起施行；国家知识产权局在修改解读中再次强调，创造性评价要从最接近现有技术与发明实际解决的技术问题出发考察现有技术是否存在技术启示。当前《指南》还明确要求创造性应针对**权利要求限定的技术方案整体**评价，而不是孤立判断某个技术特征本身是否“有创造性”。citeturn21search1turn21search2turn21search3turn21search12

这对本案尤其重要。C、G、I 都不是适合用“某处有实时数据、某处有历史记录、再某处有 pause”机械拼接的区别点。更稳健的无效思路应当证明：

**对 C/G：** 本领域在面对“持续产生当前数据 + 连接可能间歇 + 历史记录仍需补齐”的问题时，已经有明确理由把 low-latency/current data 与 stored/historical data 按不同路径、时序或传输策略处理。

**对 I：** 在吸奶器/负压泵中，主动驱动停止与“仍保留足够负压保持贴附”并不矛盾，而是可以由阀、压力调节器或密闭流路承担；因此把这种已知的 vacuum-hold 状态用于短时间用户暂停，技术上的跨越应当重点评价，而不能仅因为早期文件没有使用“Active Pause Mode”这个名称就认定不存在技术启示。Medela 的早期乳房泵文献恰好为后一论点提供了同领域事实基础。citeturn16view4

## C 与 G 专项：本轮最有价值的命中

### Dexcom：目前最强的医疗领域 C 候选

**US20140184422A1，Remote monitoring of analyte measurements，Dexcom。** 该族优先权可追溯至 2012年12月31日，美国申请公开发生在 2014年7月3日，明显早于你的临界日。它针对连续分析物/葡萄糖监测，是典型的持续产生医疗数据、由接收器/gateway/远端系统进行传输与查看的设备架构。citeturn7view2

其价值主要在两个非常直接的段落。

第一，Dexcom 明确允许 gateway 从 receiver 获取 **current data 和 historical data**，既可以自行 pull，也可以响应服务器请求取得。这一公开对 G 的“外部侧按需获取历史记录”非常有帮助，因为它不是简单说数据库中“存在历史数据”，而是直接涉及医疗设备—gateway—服务器架构中的 current/history 数据访问。citeturn6view1

第二，也是本轮最重要的 C 结合动机证据：该文献明确区分 substantially real-time data 与 historical data 的通信策略，提出较实时的数据可以利用蜂窝连接，而历史数据因为**时间敏感性较低**，可以在 Wi‑Fi 等其他连接条件下传送。也就是说，文献不仅出现了两类数据，还直接解释了为什么技术人员会对它们采取不同的传输路径/时机。citeturn6view1

这恰好击中你提出的“技术问题检索”：

> 当前数据要求低时延，因此适合持续或优先传输；历史数据不具有同样的实时性要求，可以延后、按需或换用另一连接方式处理。

这比 CN103605805A 一类时序数据库文献强的地方，不在于它的“separate”字面更漂亮，而在于它属于**连续医疗监测体系**，而且文件自己给出了区分两类数据路径的技术理由。对于创造性第三步的技术启示分析，这一点比单纯证明“历史数据库属于公知”更有价值。该结论属于基于上述 Dexcom 公开内容和当前《指南》评价方法的推断。citeturn6view1turn21search2

它仍有一个需要正面处理的弱点：Dexcom 的优选实施例更容易被理解成**对实时和历史数据采取不同通信链路/时机**，而不一定逐字写成目标权利要求那种 “maintaining a real-time data stream separately from a historical data stream”。所以它对 C 是高度实质接近，而不是可以轻率宣称为逐字同义公开。无效理由中最好把“separate”解释落实到**数据类别被独立识别、独立请求并按不同时间敏感度与通信策略处理**，而不要只依赖文字近似。citeturn6view1

**本轮评分：88/100，S级。**

其中：关键区别特征直接度 27/30；领域距离 17/20；技术启示 20/20；减少组合数量 9/10；原文明晰度 9/10；时间/同族稳定度 5/5；对方解释空间 1/5。最后一项刻意压低，原因正是“different treatment/channel”与权利要求中“separate streams”的文字解释仍可能成为争议点。评分是本报告的分析性评价。citeturn6view1turn7view2

### Fitbit：最接近“断线保存—重连补历史—再转实时”的 C+G 文件

**US20140172362A1，Methods, Systems and Devices for Generating Real-Time Activity Data Updates to Display Devices，Fitbit。** 该申请的技术来源可追溯至 2010年，2014年公开，属于 wearable/activity-health device 路线，并涉及 BLE 等低功耗无线连接。citeturn7view0turn20view3

它几乎就是你在检索策略中假设的通信恢复场景：

设备持续采集活动数据；当外部计算设备/应用没有可用连接时，数据继续在 tracker 一侧积累；应用打开且连接可用后，设备把本地 storage 中累积的数据以**第一传输速率**下载给外部计算设备；完成这一 stored-data download 后，系统进入另一种连接/传输状态，对后续数据提供 substantially real-time updates。citeturn21view2turn21view3turn21view5

Fitbit 甚至明确把传输过程区分成 background updates、download updates、real-time updates，并指出实时更新显示到 smartphone 等客户端时可以达到用户感知上的实时效果。citeturn21view5

更重要的是，原 B2/同一公开内容中的实施例还说明：设备离开范围后可暂停向外发送而继续存储活动数据，连接恢复以后再把缺失期间保存的数据发送给计算设备，从而把外部指标补齐。这正是你所称的 **backfill / catch-up**。citeturn6view3

因此，若把 C 理解成一种实际的数据架构，而非必须出现 “historical stream” 字样，Fitbit 提供的是非常漂亮的：

**local stored backlog → connection/app open → bulk/high-rate download → subsequent live update stream**

结构。它同时非常接近 G，因为历史/遗漏数据确实由外部设备取得，用于使客户端所显示/记录的数据“追上”设备端已经发生的活动。citeturn6view3turn21view3

它的主要弱点不是技术内容，而是**领域距离**：Fitbit 属于 wearable/activity tracking，而不是治疗泵或乳房泵。因而，我不建议把它放在 Dexcom 前面作为第一 C 文件。其最佳角色是：

> **Dexcom 为主 C：负责医疗领域和“为什么实时/历史要不同处理”的技术启示；Fitbit 为强备用 C/G：负责把 reconnect、stored backlog、bulk download、live update 的完整架构展示得更直接。**

这样可以避免主理由中同时依赖 Dexcom + Fitbit 两件文件去证明同一个 C，从而违背你“减少组合数量”的目标。citeturn6view1turn21view3

**本轮评分：86/100，S级。**

它在 C+G 的实际架构直接度甚至可能高于 Dexcom；但领域接近程度明显低一档，所以最终略低于 Dexcom。citeturn21view3turn21view5

### Abbott：非常好的 G/backfill 备用证据

**US20100280782A1 / US8483967B2，Abbott Diabetes Care，Method and system for providing real time analyte sensor calibration with retrospective backfill。** 该申请在 2010年即公开，针对连续分析物监测。citeturn9view0

它明确描述：连续传感过程中，遇到不适合立即处理/显示的条件时，相应 sensor data 可以被保存；条件恢复后，再取回这一时间段的数据，处理并显示，从而回填此前缺失的时间区间。文献还把数据 processing terminal 描述成能够存储、取得、更新相关数据的终端。citeturn9view0

这非常适合证明：

> “当前连接/当前处理不能覆盖全部时间段 → 医疗设备保存数据 → 后续 retrieval/backfill → 历史图形重新完整”

在临界日前已经是连续医疗监测领域的现实技术问题，而不是目标专利首先发现的特殊乳房泵问题。citeturn9view0

但 Abbott 对 C 的“两类 stream 分离”明显不如 Dexcom/Fitbit，所以我把它定位为 **G 和 reconnect/backfill 的 A/B 级备用证据，而非主 C 文件**。

**本轮评分：77/100，B级。** citeturn9view0

### 可编程胰岛素泵：证明 medical pump 内部 history log → 外部下载早已存在

早期 programmable insulin pump 文献 US6852104B2 进一步提供了一个非常有价值、但不应过度使用的事实：其 RAM 可以保存 pump settings 和 historical log of events；外部设备/计算机可以通过 IR 等通信接口编程泵并**下载 historical data logs**，而无线 RF 等也被列为替代通信方式。citeturn6view2

它没有 C，也未必具有目标 G 那么完整的历史页面更新，但它非常适合证明：

> **医疗泵 + 内部 history log + 外部 programmer/computer 下载历史运行数据**

早在目标临界日前多年已经存在。citeturn6view2

因此，如果专利权人试图强调“泵类设备的历史 operating data 下载与连续监测器有本质距离”，这篇 insulin pump 文件是很好的领域桥接证据；但如果主组合已经有 Dexcom 和 D1，则没有必要为了 G 再把它作为第四篇必需文件。

**本轮评分：72/100，B级备用。** citeturn6view2

## I 专项：已经击中“停泵仍保压”，但尚未找到完整单篇

### Medela 早期乳房泵是本轮 I 的关键新补强

本轮 I 检索中，最值得保留的独立族是 Medela 的 **US20080255503A1 / US8070715B2**，题为 *Method and apparatus for minimum negative pressure control, particularly for breastpump with breastshield pressure control system*。其优先权为 2007年4月11日，美国申请公开日为 **2008年10月16日**，远早于本案临界日，而且 CPC 明确处于 A61M1/06 乳房泵领域。citeturn17view1turn17view0

这篇文献的 I 价值很高，因为它不是泛泛说“始终保持负压”。它给出了非常具体的 pump-off/vacuum-hold 过程：

在泵运行并达到较高真空后，**pump stops drawing a vacuum**；阀打开使负压向较低水平回落；当达到预设 minimum vacuum 时，调节器关闭通向环境的线路，于是系统被**保持在该 minimum vacuum**。文献还说明这一 minimum negative pressure 可以用于使 breastshield 保持在乳房上。citeturn16view4

其权利要求同样明确把 minimum negative pressure 与使 breastshield 持续贴附在乳房上的 suction 联系起来。citeturn16view4

这一点对 I 很重要，因为它直接打掉了一种潜在抗辩：

> “只要主动泵送/泵驱动停止，真空就必然消失；要保持 latch 必须继续运行泵。”

Medela 在 2008 年已经公开了相反的工程事实：**主动真空产生停止后，借助压力调节/阀机构仍可以把系统锁在一个足以保持乳房贴附的最小负压状态。** citeturn16view4

此外，另一件 programmable electric breast pump 文献 US8137305B2 也说明用户可手动选择 vacuum rate/vacuum level，控制器在 minimum 和 maximum setpoint 之间控制系统；其权利要求明确要求在 pumping session 中保持足够的 minimum vacuum，使 breast cup 留在乳房上，并包含在特定情况下 stopping the vacuum pump 的控制逻辑。citeturn15view2

不过，必须非常严格地区分：

**Medela 公开了：**
泵停止继续抽真空 + minimum vacuum 保持 + 负压用于保持 breastshield 贴附。citeturn16view4

**它没有在本轮检索到的直接段落中公开：**
“用户按 pause → 进入一种专门 pause state → 不主动抽奶 → 保持 latch vacuum → 明示 silent/quiet”。

也就是说，它没有完全达到你为 I 设置的停止条件。

因此，不应把这篇文件写成“单篇完整公开 I”。它最强的无效作用是：

> **D1 如果已经给出了用户可进入的 pause / no pumping / only latch suction，那么 Medela 独立同领域文件证明其中最容易被争论的工程动作——停止主动抽吸而仍通过阀系统保持乳房附着负压——不是 Exploramed/Willow 首创。**

这比再找一篇普通“quiet breast pump”要有价值得多。citeturn16view4

**本轮评分：82/100，A级。**

若只针对 I 的“pump stop + latch vacuum”子问题，可以打到接近 S；若按整个 I 限定评价，则因为缺少 user-selectable pause 和明确 silent，必须扣分。citeturn16view4

### “silent”仍然不宜单独做主区别特征检索

本轮未找到一件满足硬临界日、独立于已知 Exploramed 族、并在乳房泵中直接把：

**用户主动 pause + actuator/pumping 停止 + latch vacuum 保持 + silent/quiet**

四项同时写出的文件。

这意味着现在不应为了“silent”再增加一件孤立低噪声专利。这样会重新把无效理由拆成逐个小特征拼接，与当前《指南》要求的整体技术方案、技术问题和技术启示评价方向相反。citeturn21search3turn21search12

更好的写法是：如果 D1 已有 active/user pause 和 latch suction，Medela 又证明停泵时可机械/气动保持最低负压，那么**驱动机构减少或停止动作带来的噪声降低**可以被作为可预期的技术效果讨论；但“完全 silent”不应在新颖性意义上当成 Medela 的必然直接公开，因为现有文本没有明确这样说。这一点应在无效请求中保持克制，以免让对方抓住“停止抽真空≠绝对无声”的逻辑漏洞。citeturn16view4

### 邻近负压医疗泵提供了“用户 pause”桥梁，但不宜进入主组合

还有一篇非常值得保留的邻近领域文献：**US20150025482A1，Systems and methods for applying reduced pressure therapy**，属于 negative-pressure wound therapy。它具有 play/pause 控件，用户按下后可以暂停 negative pressure therapy。citeturn19view4turn20view0

这篇文件真正有意思的地方是它不仅有 pause。它同时公开：

记录 historical therapy data；通过通信接口向 remote computer 传输；允许 GUI 请求传输历史数据；按时间顺序显示 historical parameters；remote side 还能把新的 therapy parameter adjustment 返回给设备，并由控制器据此调整负压源。它还明确提到 pump assembly 可以与 laptop、tablet、smartphone 等通过有线或无线方式连接并上传日志、调整治疗设置。citeturn20view5turn20view6

因此，这一篇实际上同时触及：

**B + D + E/G + historical screen + bidirectional control + 用户 pause。** citeturn19view4turn20view5

它缺的恰恰是 C 的 live/history separation，以及 I 的 pause 状态下继续保持 attachment vacuum。

所以它不适合作为“完整 I 文件”，但它是本轮非常好的**负压医疗泵桥梁文件**。在需要说明“一个受控负压泵为什么会同时采用远端记录/下载、双向调参和用户暂停”等系统设计时，它比普通数据库或普通 Bluetooth 文献有明显更强的结合动机。citeturn20view5turn20view6

**本轮评分：83/100，A级桥梁。**

## 同领域桥梁文件与 H 检索结果

### Medela CN105247563A 是最值得使用的乳房泵数据桥梁

**CN105247563A，Medela Holding AG，2016年1月13日公开，优先权 2013年3月13日。** 它在你的硬截止日之前公开，而且本身属于 A61M1/06 乳房泵领域。citeturn10view0

它的技术内容非常适合作为 A–G 的“领域桥梁”，因为文件围绕母乳采集数据管理本身展开，并明确认识到人工记录每次 pumping 的数量、日期/时间、乳房侧别等很麻烦，因此希望由 smartphone 等计算设备自动收集和利用数据。citeturn11view3

更关键的是，它把两套你需要的功能放进了同一个乳房泵生态：

一方面，软件能够形成 **pumping logs、performance graphs** 等历史记录/表现信息；另一方面，通过视频/传感信息提供 **real-time performance feedback**，包括泌乳、泵送时间、流量、真空变化等信息。citeturn11view3

而且计算设备可以与乳房泵通信，甚至进行 closed-loop feedback/control；系统还包括显示、网络接口和数据存储。citeturn11view3

因此，CN105247563A 并不能单独证明 C——它没有清楚说 live stream 和 history stream 必须在内部或通信上“分开”；它也不完全证明目标 G 那种“外部设备主动下载泵内 history 后更新 non-live screen”。但是它能非常有力地证明：

> 到 2016年1月，**乳房泵领域本身已经把实时反馈、泵送历史日志/性能图、智能手机和双向泵控制视为同一产品体系内可以自然结合的功能。** citeturn11view3

这对于使用 Dexcom 解决 C 尤其重要。

如果单独看 Dexcom，专利权人可能说：

> CGM 的实时/历史通信与乳房泵无关。

但加入 Medela 的背景后，论证可以变成：

> 乳房泵本身已经存在 current/real-time feedback、history/pumping logs、smartphone communication 和 feedback control；面对如何进一步管理这两类已经产生的数据这一具体问题，连续医疗监测领域恰好已经明确教导按照不同时间敏感性处理 current/historical data。

这样的组合逻辑明显比：

> “D1 + 一个数据库专利，因为数据库也有历史数据”

更接近《指南》要求的“从实际技术问题出发寻找技术启示”。这是本报告基于 Medela、Dexcom 与 CNIPA 当前创造性标准作出的组合推断。citeturn11view3turn6view1turn21search2

还有一个实务提醒：CN105247563A 已出现在目标专利 Google Patents 页面列出的引用文献中，因此它很可能不是一件“从未进入过审查视野”的惊喜文件。它的价值主要在于**重新定位为 bridge/motivation document**，而不是把它包装成全新发现。citeturn3view1

**本轮评分：84/100，A级桥梁。**

### US20150025482A1 是“负压泵数据管理”桥梁的第二选择

如果希望从“乳房泵”向更宽的“负压医疗泵”扩展而仍保持较近技术距离，US20150025482A1 很有价值。它在单件文件里结合了负压源、GUI、设备历史记录、按需传输历史数据、远端计算设备、双向参数调整和 pause。citeturn20view5turn20view6turn19view4

从组合数量角度，它可以替代若干只分别证明“历史日志”“远端控制”“pause”的弱文件。

但它仍然不是 C 的终结者，因此最佳位置是**技术启示/系统设计桥梁**，而不是替换 Dexcom。

### H 本轮未出现满足停止条件的独立新族

按照你要求的精确搜索，本轮围绕：

air → milk、priming、milk-filled tubing、incompressible milk、hydraulic 等概念搜索后，最直接的命中再次落到 Exploramed/NC7 的 **US9539377 / PCT/US2015/041257 / WO2016014469A1** 族；Google Patents 直接显示该美国案的 related/priority PCT 即 WO2016014469A1。citeturn22search2

这恰好属于你要求严厉排除的已知族，所以不能当作新的 H 文献重复计数。citeturn22search2

本轮没有找到一件同时满足：

**独立于已知 Exploramed 族 + 2016年2月9日前已公开 + 明确“初始空气被排/泵送 → 通路被乳汁充满 → 后续利用乳汁/不可压缩液柱执行泵送”**

的第二文件。

因此 H 的结论非常明确：

> **停止广泛 H 检索是合理的。继续搜传统 air-vacuum breast pump 的边际价值极低；除非以后沿某篇独立文献的 backward citations 意外发现早期 hydraulic/milk-column 方案，否则继续由 D2 承担 H。**

这也是本轮“没有找到”本身有价值的地方：精确检索仍高度回收到已知同族，说明现阶段新增 H 文献的概率和价值都明显低于 C/I。citeturn22search2

## 候选文献排序与同族排除台账

以下排序严格按照你提出的思路，不按“命中特征数量”简单排序，而更重视关键区别特征、领域距离、组合动机及能否减少主组合文件数量。分值是本报告的研究评价，并非国家知识产权局的法定评分。

| 等级 | 文献 | 日期状态 | 主要贡献 | 关键缺口 | 本轮分数 |
|---|---|---|---|---|---:|
| **S** | **US20140184422A1 — Dexcom** | 临界日前公开 | **C；部分G；最强 C 技术问题/结合动机** | 未逐字写“separate streams” | **88** citeturn6view1turn7view2 |
| **S** | **US20140172362A1 — Fitbit** | 临界日前公开 | **C+G；stored backlog→download→live；reconnect/backfill** | wearable/activity，领域较 Dexcom 远 | **86** citeturn6view3turn21view3 |
| **A** | **CN105247563A — Medela** | 2016-01-13公开 | **乳房泵 bridge；real-time feedback + pumping logs/graphs + smartphone + pump control** | C 不直接；G 下载动作不完整 | **84** citeturn10view0turn11view3 |
| **A** | **US20150025482A1 — Smith & Nephew** | 临界日前公开 | **负压医疗泵 bridge；history transmission/display + bidirectional control + pause** | C 缺；pause 时保持负压缺 | **83** citeturn20view5turn19view4 |
| **A** | **US20080255503A1 / US8070715B2 — Medela** | 2008公开族 | **I核心子问题：pump stops + minimum vacuum held + breastshield attachment** | 无完整主动 pause；无明确 silent | **82** citeturn17view1turn16view4 |
| **B** | **US20100280782A1 — Abbott** | 2010公开 | **G/reconnect/backfill 医疗证据** | C 不够直接 | **77** citeturn9view0 |
| **B** | **US6852104B2 — programmable insulin pump** | 临界日前多年公开 | **medical pump internal historical log + external download** | 无 C；实时显示不足 | **72** citeturn6view2 |

本轮还识别到两个尤其重要的**排除项**。

第一类是一个“技术上几乎完美、法律上不能用”的 Dexcom 后公开族。其 *Distributed system architecture for continuous glucose monitoring* 明确讨论 bulk data 与 real-time data 的不同同步方式和分别处理/存储，技术上非常接近 C；但其实际公开发生在 **2016年11月**，晚于 2016年2月的硬临界日，因此即使优先权较早，也不能按照你设定的公开日标准作为本案主现有技术。它只能证明本轮检索方向是对的，不能混进证据表。citeturn8search0turn8search1turn8search2

第二类是 Exploramed 已知族。H 的高命中 US9539377 明确关联 PCT/US2015/041257、WO2016014469A1，正是要求排除的已检索技术族，不应因为出现 US/CN/JP/KR 不同公开号而重复计数。citeturn22search2

因此本轮建议的同族台账状态可以概括为：

| Publication / family | Applicant | 本轮处理 |
|---|---|---|
| US20140184422A1 | Dexcom | **新保留，C 主候选** |
| US20140172362A1 | Fitbit | **新保留，C/G 强备用** |
| CN105247563A | Medela | **保留为同领域 bridge；注意目标专利已有引用** |
| US20150025482A1 | Smith & Nephew | **保留为负压医疗泵 bridge** |
| US20080255503A1 / WO2008127991A1 / US8070715B2 | Medela | **视为一个族，仅引用一套最有利文本** citeturn17view1 |
| US20100280782A1 | Abbott Diabetes Care | **G/backfill备用** |
| US6852104B2 相关族 | 医疗泵 | **G领域桥接备用** |
| US20160335409A1 / WO2016183198A1 等 Dexcom 族 | Dexcom | **晚公开，排除** citeturn8search0turn8search2 |
| US9539377 / WO2016014469A1 等 | Exploramed NC7 | **已知族，排除为“新结果”** citeturn22search2 |

这里尤其值得坚持你提出的规则：最终无效证据表的“publication number”必须使用真正主张公众能够取得的具体早期公开文本，不能只因为某一 B2 授权页便于阅读，就把后来的授权公告日误认为现有技术形成时间。像 US8070715B2，真正更适合在时间证据栏记录的是其 **US20080255503A1 于 2008年10月16日公开**这一事实；B2 可以用于便于定位文字，但公开基础应落回 A1/PCT 等临界日前文本。citeturn17view1

## 推荐的无效组合与最终判断

### 主路线应改成“D1 + 一件医疗 C 文件 + D2”，而不是继续扩张横向文件

如果现有 D1 确实已经覆盖你所述的大部分 A–G 以及 I 的 pause/latch 基础，当前最干净的主路线应优先测试：

> **D1 + US20140184422A1（Dexcom） + D2**

其中：

**D1** 继续承担乳房泵主体结构、实时/历史运行信息、外部设备交互及 active pause/latch 的基本框架；

**Dexcom** 专门解决最有争议的 C，并辅助 G，同时提供“为什么 current 与 historical 要不同处理”的明确技术理由；

**D2** 继续承担 H。

这一结构的优势不是文献数量从三篇变成两篇——目前看来还没有达到这一程度——而是把原先最容易被攻击为“数据库跨领域拼接”的 C 文件替换成**连续医疗监测数据系统**，大幅改善技术领域距离和第三步技术启示。Dexcom 对实时数据与历史数据的不同时间敏感性及不同传输策略的明确说明，是这一组合最重要的新证据。citeturn6view1turn21search2

CN105247563A 最好不作为“必须补某个区别特征”的第四件主文件，而作为**结合动机和领域背景文件**使用：

> 在优先权日前，Medela 已经把乳房泵、智能手机、实时泵送反馈、pumping logs/performance graphs 和闭环泵控制放在同一个系统中；因此技术人员面对实时/历史数据如何管理的问题时，参考成熟连续医疗设备的数据同步设计并非无目的跨领域迁移。citeturn11view3

这使创造性论证从：

> “因为别的数据库有 historical data，所以把它加进来”

变成：

> “乳房泵已经产生并利用实时反馈和历史 pumping logs；所剩问题是如何在无线/移动环境下组织两类不同时间敏感度的数据，而连续医疗监测现有技术已经明确给出了 current/historical 的差异化传输方案。”

后者明显更符合当前 CNIPA 所强调的“从发明实际解决的技术问题出发寻找技术启示”的分析框架。citeturn21search2turn21search3

### C 的最佳主、备证据不要同时堆进一个组合

C 最优使用顺序应当是：

**主证据：Dexcom US20140184422A1。**

它的优势是**医疗领域距离 + 明确 current/historical + 明确不同传输理由**。citeturn6view1

**第一备用：Fitbit US20140172362A1。**

它的优势是**架构动作非常完整**：本地积累 → 重新连接/打开应用 → stored data 高速补下载 → 后续实时更新，并有客户端实时显示。citeturn21view3turn21view5

除非专利权人成功主张 Dexcom 的两类数据只是“选择不同网络”而不构成权利要求要求的“streams maintained separately”，否则没有必要在主理由中把两篇同时叠加。Fitbit 应保留为第二攻击路线。

换言之：

> **Dexcom 胜在“为什么分”；Fitbit 胜在“实际上怎么分并怎么补”。**

这两个文件的互补关系非常好，但最佳用途是**平行备选，而不是串联四文献组合**。citeturn6view1turn21view3

### I 应采用“D1直接攻 + Medela反驳工程不可行性”的方式

对于 I，本轮结果没有达到“彻底替换 D1”的程度。

但 Medela US20080255503A1 的作用其实非常精准：

> 在同一 A61M1/06 乳房泵领域，达到较高负压后，泵可以停止继续抽真空；阀/调节器随后把系统保持在一个 minimum vacuum；这个 minimum negative pressure 又明确可以用于维持 breastshield 与乳房的贴附。citeturn16view4turn17view1

因此，如果 D1 已经说：

> pause / not pumping / only latch suction，

那么对 I 最合理的论证不是再强行加一件“quiet pump”：

而是主张 D1 本身已经给出用户暂停与 latch 状态；Medela 则证明“停止主动抽吸却保持附件真空”在同一技术领域属于已实现的具体压力控制方式。将主动执行机构在 pause 阶段停止或降到最低，因而减少噪声，是一个可预期技术结果；但对“silent”应当作为创造性结果分析，而不应虚构成 Medela 的逐字公开。citeturn16view4

这是一条比“D1 + quiet pump + valve patent + generic pause patent”干净得多的攻击链。

### G 可以从“争议区别特征”降为“高度可补强特征”

G 目前已经不再像 C/I 那样危险。

至少有三条相互独立的技术线：

Fitbit 已经给出存储数据在连接恢复/应用打开后下载到外部计算设备，并用来补齐此前没有实时更新的数据；citeturn6view3turn21view3

Abbott 给出连续医疗数据在暂时不能处理/显示时保存，随后 retrieval 和 retrospective backfill，再把此前缺失期间的数据显示出来；citeturn9view0

早期 insulin pump 则直接存在内部 historical event log 和外部设备下载 historical data logs。citeturn6view2

再加上 Medela 自身的 pumping logs/performance graphs，同领域技术背景已经非常充足。citeturn11view3

因此 G 后续不值得再分配 10% 以上检索资源。除非为了找到一篇恰好同时写出 C+G 的更近领域文件，否则 G 的主要补强任务已经完成。

### H 应正式进入停止状态

本轮 H 精确检索没有发现比现有 D2 更有战略价值、又独立于 Exploramed 已知族的临界日前文件；高相关结果再次回到 WO2016014469A1 同族。citeturn22search2

所以 H 现在应进入你所定义的**停止状态**：

不再搜“air creates vacuum”“milk flows through tube”这一类普通文献；只有在 C/I 候选的 backward citations 中偶然出现明确 air→milk priming→liquid-column pumping 的早期独立文件时才重新打开 H。

### 对现有约 68% 判断的更新

本轮真正改变判断的是 **C，而不是 H**。

Dexcom 给出了一个临界日前、连续医疗监测领域、具有明确 current/historical differentiation 和不同时间敏感度/传输策略理由的文献；Fitbit 又独立给出 stored backlog/download/live update 的完整 reconnect 架构。它们显著改善了此前 C 只能依赖通用时序数据库时的跨领域结合问题。citeturn6view1turn21view3

I 也取得了实质进展：Medela 早期同领域文献非常明确地证明“泵停止继续抽真空—最小真空仍保持—该真空维持 breastshield 贴附”的工程状态早已存在。citeturn16view4

但 I 尚没有找到你设定的理想单篇：

> user-selectable pause  
> + active extraction stopped  
> + latch/baseline suction maintained  
> + actuator stopped/reduced  
> + explicit silent/quiet。

因此，把当前研究层面的中心值从约 68% 提升到 **约 76%–81%** 比直接提高十几二十个百分点更合理。最主要的上调来自 C/G 证据从“跨领域数据库”升级为“医疗/可穿戴医疗的数据同步架构”；I 的提升则主要是消灭工程可行性争议，而不是获得一篇完全 anticipatory 的 I 文件。这一数值是对证据结构的分析性判断，并非对国家知识产权局无效决定结果的统计预测。citeturn6view1turn21view3turn16view4

本轮之后，案件的真正剩余检索目标已经可以进一步收窄为一句话：

> **不再广泛搜 A–I。只继续尝试寻找一篇 2016年2月9日前公开、属于乳房泵或其他负压医疗泵的文件，把“用户主动暂停主动驱动 + 通过阀/密闭回路继续维持 attachment/latch vacuum”写在同一实施例里。C 的主证据池已经基本形成，G 已有多层备用，H 可以停止。**

就目前取得的文献而言，最干净、最值得正式做 claim chart 和无效理由深化的新增文件顺序是：

**US20140184422A1（Dexcom） → US20080255503A1（Medela） → CN105247563A（Medela bridge） → US20140172362A1（Fitbit备用 C/G） → US20150025482A1（负压医疗泵 bridge）。**

这一排序最大限度遵循了你最初设定的战略目标：**减少跨领域距离、把 C 的技术启示说清楚、把 I 的“停泵仍保真空”争议消掉，同时尽量不增加主组合中必须依赖的文件数量。** citeturn6view1turn16view4turn11view3turn21view3turn20view5

本轮定点补充检索结论

一、结论先行

本轮已经取得三项实质性进展：

1. I 找到一篇可进入主证据池的 A+/准 S 文件：WO2016103031A1。
   它在同一命名泵系统及明确适用于该系统的状态机中公开了：用户按键暂停、进入 standby、负压源关闭，以及泵不工作时由单向阀帮助保持负压；同时还有泵噪声衰减及限制噪声/振动的设计动机。剩余风险只在于：该装置属于负压伤口治疗而非乳房泵，而且没有一句话直接写成“用户暂停后，该阀关闭并保持 attachment/latch vacuum”。因此不宜无保留定为 S，但足以把 I 从“缺少工程机制”压缩成“领域对应和直接组合表述”问题。 (谷歌专利)

2. C 找到一篇行为层面达到 S 级的新文件：CN104055500A。
   它不是泛泛保存两类数据，而是设置实时缓冲区与病例历史库，由外部观察终端分别提出实时监护请求和历史查看请求，分别由实时采集控制模块和历史数据处理模块响应，并采用“按秒取得实时缓冲数据”与“压缩、断点传输历史数据”两套路径，历史数据最终在外部终端图形显示。它明显强于仅披露“保存实时和历史数据”的普通数据库文件。 (谷歌专利)

3. P3/P4 分别出现可用文件。
   WO2016103031A1 同时公开运行日志、向便携设备同步/上传/下载数据及远程调整治疗设置，可作为 I+G 桥梁，但不足以替代 C；US20150025482A1 则直接公开历史治疗参数上传到远程计算机、按时间顺序在 GUI 显示过去上传事件并下载历史报告，可作为更直接的 G 主备用文件。 (谷歌专利)

二、建议更新后的证据池

这里的评级含义是：S 表示同一文本直接、明确地把目标要素串联；A+ 表示同一系统链条中基本齐全，但尚有一个可争议的组合或领域对应环节；B+ 表示机制可用，但仍需另一文件完成关键功能连接。

三、I：WO2016103031A1 的四层对应

1. I-1：用户主动暂停

泵系统 1000 具有可由用户操作的按钮，明确可用于暂停泵系统，并描述为 play/pause 按钮。状态机进一步写明，用户通过按键可使系统从初始泵降状态转入 standby；暂停后可以再次按键恢复，也可以超时自动恢复。 (谷歌专利)

对应结论：直接满足。

2. I-2：负压源停止动作

文献将 standby 称为 paused state，并写明在该状态中治疗可以暂停，负压源可以被停用或关闭。该状态机明确适用于包括泵系统 1000 在内的多个具体泵系统。 (谷歌专利)

对应结论：直接满足，不只是降低抽吸频率。

3. I-3：泵停止时继续保持负压

在同一泵系统 1000 的结构描述中，伤口敷料与泵入口之间设置单向阀；该阀被明确说明用于在泵不工作时帮助维持一定负压，并减少泄漏。 (谷歌专利)

对应结论：工程状态直接满足。

但这里的负压是敷料下负压，文献没有将其称为 breastshield attachment vacuum 或 latch suction。因此：

• 对“泵关闭但密闭人体界面仍保压”的一般解释非常强；

• 对“乳罩仍靠该负压贴附乳房”的专门功能，需要由 D1 或 Medela 完成领域映射。

4. I-4：无需持续驱动的保压机制

结构机制明确为位于敷料与泵入口之间的 one-way valve。这正是目标检索中的 check valve/non-return valve 路线。 (谷歌专利)

对应结论：直接满足。

5. quiet/silent 层

同一泵系统还公开在泵出口与大气之间设置 noise-dampening component，以减少运行噪声；状态机的设计目标之一是限制负压源产生的噪声和振动。 (谷歌专利)

但不宜把它写成“明确公开 silent pause”，原因是：

• 没有检到 silent、virtually silent 等强词；

• 降噪部件针对泵运行时；

• “负压源关闭后当然更安静”属于合理工程推论，而不是文本中的直接表述。

因此 quiet 层只能算强化动机，不能据此把整篇文件提升为无争议 S。

四、为什么评级是 A+/准 S，而不是完整 S

这篇文件的优势在于，相关内容不是从无关实施例任意抽取：

• 段落 [0222]–[0226] 在同一 pump system 1000 下依次说明暂停按钮、电机泵、降噪部件和停泵保压单向阀；

• 后续 Figure 63 状态机明确适用于 pump systems 100、1000、1100、1200；

• 状态机明确把用户 pause、standby 和负压源关闭串在一起。 (谷歌专利)

但严格的新颖性式阅读仍可能遇到两个争点：

1. 各项常以 “in some embodiments” 表述，反方可能主张文献未直接且无歧义地指定“包含保压阀的那个具体配置必然执行该用户暂停状态”；

2. 文献没有用一句完整因果句写明：“用户按下 pause → 泵关闭 → 单向阀关闭 → 敷料下负压在暂停期间继续保持。”

所以它非常适合用于消除工程可实现性和组合动机风险，但如果目标是仅靠一篇文件完成全部乳房泵限定的新颖性覆盖，仍差最后半步。

五、Medela 锚点与 WO2016103031A1 的互补关系

Medela US20080255503A1 已经非常准确地公开：

• 泵停止抽真空；

• 压力向大气回落；

• 达到预设最低负压后调节器关闭管路；

• 系统保持最低负压；

• 该最低负压可使 breastshield 通过吸力保持在乳房上，并保持乳头居中；

• 还提出使用较小电机和较低转速以降低噪声。 (谷歌专利)

它缺少的仍是用户主动 pause 命令。因此当前最稳的 I 证据结构是：

D1：乳房泵中的用户暂停/非主动泵送/仅 latch suction
＋ WO2016103031A1：用户暂停→standby→负压源关闭，以及停泵保压单向阀
＋ Medela：最低负压在乳房泵中用于 breastshield attachment 的具体意义和调节器机制

这三者分别解决“模式名称和乳房泵状态”“暂停控制与被动保压机制”“attachment vacuum 的乳房泵语义”。WO 文件不应被描述为已经单篇公开乳房泵 latch vacuum，但它显著削弱了“泵关闭后如何仍能保压”的解释风险。

六、I 的备用与应排除近似文件

US20150100045A1：保留为 B+ 机制桥梁

该文件公开外部用户可访问的 play/pause 开关，允许暂停和重新启动泵，并公开单向/止回阀及约 0.05 mL/min 或更低的泄漏率，同时有泡棉、阻尼材料等降噪结构。 (谷歌专利)

不足是它没有明确说该止回阀在用户暂停期间保持敷料负压。它与 WO2013171585A2 属同一优先权族，只能算一个文件。 (谷歌专利)

US20160206794A1 / WO2016014469A1 同族的 rest phase：不能误用

该乳房泵文件确实允许用户主动启动 rest phase，但它同时明确规定，该 rest phase 中全部吸力/真空被移除，乳房暴露于大气；乳罩的继续定位依靠胸罩和可选粘合剂，而不是保留负压。 (谷歌专利)

因此应严格区分：

• retained-latch pause；

• vent-to-atmosphere rest phase。

二者不能混写。US20160206794A1 与 WO2016014469A1 是同一优先权链和同一 family，不应重复计数。 (谷歌专利)

七、C：CN104055500A 的证据强度

CN104055500A 的价值在于，它完整公开了“分别处理”，而不仅是“存在两类数据”。

上述链条在摘要和方法步骤中均有直接记载。 (谷歌专利)

对 Dexcom 的替换能力

需要根据最终权利要求措辞区分：

• 权利要求强调的是 current 与 historical 分别请求、分别处理、分别传输、历史在外部端显示：
  CN104055500A 可以作为 C 的行为主证据，甚至在这些点上比 Dexcom 更直观。

• 权利要求明确要求 two independently maintained streams、parallel streams、live stream 与 historical stream：
  Dexcom 仍更适合作主证据，因为 CN 的文本结构是“实时缓冲/历史档案＋两套请求路径”，未直接使用两条并行 stream 的表述。

• 权利要求要求 断线期间积累 history，重连后后台 backfill，同时恢复 live updates：
  CN 不是最直接文件，现有 Dexcom/Fitbit 仍应保留。

因此最稳妥的调整不是删除 Dexcom，而是：

Dexcom 负责“stream、不同时间敏感性和不同同步节奏”；
CN104055500A 负责“外部端分别请求、不同模块/传输机制以及历史图形界面”。

这可以显著降低仅依赖 Dexcom 时对“historical/bulk data 是否等同于权利要求中的历史数据流”的解释压力。

八、C 的独立备用：WO2000062664A1

这篇早期便携式患者远程监护文件公开：

• 远程监护站可以按预定时间下载存储数据，或者查看实时 live data；

• 软件设置不同 study mode，包括 real-time continuous viewing 和 historical data viewing；

• 操作者可以独立查看实时数据，也可以下载基站中已经存储的数据；

• 可分别选择实时和历史数据的时间尺度，并在远程站显示历史数据。 (谷歌专利)

其公开日为 2000年10月26日，时间非常安全。 (谷歌专利)

评级为 A+/S−，而非完整 S，主要因为其拨号通信架构更像两种不同工作流程，未明确公开在 live stream 持续的同时后台同步历史数据。但作为“外部端实时查看 versus 已存数据下载/历史界面”的独立 family 备用，证据很干净。

九、C 中应排除或仅阅读定位的文件

WO2008016621A1：泵领域近，但不够强

该输液泵文件只明确公开通过通信端口向外部计算机下载历史数据日志。“real-time clock”在该文献中是为事件提供实际时刻的时钟，并不是实时数据通信通道。因而它没有达到两条实时/历史数据路径的停止条件，不应进入 C 主池。 (谷歌专利)

US20160331233A1：高度直接，但晚五天

该 Dexcom 文件确实非常理想：它明确区分 real-time data 与 bulk/stored data，使用不同发送周期、不同服务器和 separate data streams。可是它实际公开日为 2016年11月17日，晚于临界日 2016年11月12日 五天，因此只能用于术语理解和定位更早 family/citation，不能进入当前主证据池。 (谷歌专利)

十、P3：桥梁文件的最终判断

WO2016103031A1 可作为 I+G 桥梁，因为除暂停/停泵/保压外，它还公开：

• 存储系统参数、运行数据和用户数据；

• 记录操作日志；

• 在泵与平板、智能手机等便携设备之间同步、上传或下载数据；

• 上传日志、报警和运行数据；

• 远程选择、调整治疗设置，以及升级软件/固件。 (谷歌专利)

但它没有清楚区分 live flow 与 historical flow，也没有历史趋势界面。因此：

• I+G：可用，B+/A−；

• I+C：不足；

• 不应为了“单篇桥梁”而弱化现有 Dexcom/CN 的 C 证据。

本轮未发现一篇在临界日前同时达到“主动 pause＋被动保压＋两类实时/历史数据流”的真正 S 级文件。

十一、P4：G 可用更直接文件收口

US20150025482A1 的 G 证据比普通“上传日志”更直接：

• 控制器记录历史负压治疗参数；

• 经通信接口发送到远程计算机；

• 可以周期性发送，也可以由 GUI 请求发送；

• GUI 按时间顺序显示历史参数；

• 远程治疗日志显示全部过去上传的 ON/OFF、模式和压力调整事件；

• 可下载过去及当前设备记录的报告；

• 系统还支持从外部下载治疗选择、参数和软件更新到泵。 (谷歌专利)

因此 G 已经具备“历史上传/下载→远程历史界面＋双向设置”的直接备用证据，继续为 G 扩充普通日志文件的边际价值很低。

十二、建议后的主路线

I

主解释路线：

D1
＋ WO2016103031A1
＋ Medela US20080255503A1

其中：

• D1 固定乳房泵中的 pause/no active pumping/only latch suction；

• WO2016103031A1 固定用户动作、standby、负压源关闭、被动阀停泵保压及降噪动机；

• Medela 固定 minimum vacuum 在乳房泵中就是 breastshield attachment vacuum，并提供调节器/阀关闭的具体机制。

**剩余唯一风险：**还没有找到一篇临界日前的乳房泵文件，用一句直接表述把“用户主动 pause”“泵停止”和“乳罩 attachment vacuum 由关闭阀保持”全部连接起来。

C

建议维持：

D1 ＋ Dexcom ＋ D2

同时把 CN104055500A 加入为 C 的行为主证据或独立备用：

• Dexcom：负责 literal streams、不同时间敏感性和不同更新周期；

• CN104055500A：负责分别请求、分别处理、不同传输机制和历史外部图形界面；

• WO2000062664A1：负责早期独立 wearable/remote monitoring 备用。

G

以 US20150025482A1 作为“历史数据上传/下载→历史 GUI”的直接备用即可。

H

继续停止，不再投入普通 air→milk 检索。

最终停检判断

• I：可以停止宽泛检索。 后续如仍保留资源，只应做一次非常窄的乳房泵 family/citation-chain 检索，目标唯一限定为：“user pause/source off + breastshield minimum attachment vacuum retained by closed valve”同篇直接表述。

• C：达到停止泛搜条件。 未发现同等强度的泵专用文件，但 CN104055500A 已经补齐独立请求、独立传输及历史界面的解释风险。

• P3：接受 I+G 桥梁，不再强求 I+C 单篇。

• G、H：均可停止。

以上是专利文献检索与技术证据映射判断，不是对特定司法程序中新颖性、创造性或权利要求解释结果的法律意见。

专项检索结果

检索截止条件：公开日严格早于 2016-11-12。
同一最早优先权链下的 US、WO、EP、JP、KR、CN 文献按一个家族计数；后公开的授权文本仅用于核对原始公开内容，不作为满足截止日的新文件。

评级符号：✓＝直接公开；△＝部分公开、效果补强或需跨实施方式组合；×＝缺失或存在相反公开。

一、结论总览

二、I 方向：主动暂停且保留人体界面负压

1. 候选文件评级

* I-3 对应的是伤口敷料—人体界面，而不是乳罩—乳房界面。

2. 最强桥梁：WO2016103033A2

该文件的状态机直接公开：

1. 用户按键主动暂停治疗，从 initial pump-down 或 maintenance mode 进入 standby；

2. standby 中治疗暂停，负压源被 deactivated/turned off；

3. 用户再次按键，或者暂停超时，系统恢复到 initial pump-down/maintenance；

4. 另一泵实施方式公开在敷料与泵入口之间设置单向阀，该阀在泵不活动时帮助维持负压并减少泄漏。(Google Patents)

因此，它对 I-1、I-2、I-3、I-5 很强，对 I-4 也具有实质性公开。但其问题是：

• 用户暂停状态机主要结合 pump systems 1100/1200 描述；

• “泵不活动时由单向阀维持负压”的段落结合 pump system 1000 描述；

• 说明书虽允许这些泵系统具有彼此“相同或相似的部件和特征”，但没有一句明确写成“用户暂停进入 standby 后，由该单向阀维持敷料侧负压”。(Google Patents)

按照你要求的“至少 I-1～I-4 在同一实施方式或明确共用状态机”的严格口径，I-4 应评为 △，不宜升入严格主池。

I-6 也只能评为部分补强。文件提到状态控制需要兼顾限制负压源产生的噪声和振动，但没有把“用户暂停”明确表述为静音模式或临时交流模式，不能推导为直接公开“暂停后完全无声”。(Google Patents)

此外，WO2016103033A2 与种子 WO2016103031A1 属于 Smith & Nephew 的同一 2014-12-22 关联优先权簇。依照你的种子去重规则，它可以补强 WO2016103031A1 的技术链条，但不作为新独立优先权结果计数。(Google Patents)

I 方向实质判断

若采用相对宽松的“说明书明确允许泵系统特征互换”解释，WO2016103033A2 可以形成：

用户按键暂停 → 负压源关闭 → 单向阀在泵不活动时保持敷料负压 → 按键或超时恢复。

但在要求“同一具体状态机实施方式直接绑定阀保压”的单篇严格比对下，仍然存在组合解释风险；且它属于 NPWT 邻近领域，不能替代乳房泵同领域文献。

3. Willow/ExploraMed 乳房泵家族：明确命中排除项

这里需要对前述阶段性判断作一项精确修正：该家族并非完全没有用户可选择的中断状态。说明书明确允许用户自行启动 rest phase，休止后重新建立真空并恢复 extraction/expulsion phases。(Google Patents)

但同一段同时明确：

• rest phase 中全部 suction/vacuum 被移除；

• 乳房暴露于大气压力；

• 乳房适配器依靠文胸支撑及可选粘合剂继续留在乳房上；

• 休止结束后才重新建立真空并恢复挤奶。(Google Patents)

所以该家族虽然可以给出 I-1、I-2、I-5，却直接违反：

• 排除项 2：rest phase 向大气泄压或完全移除真空；

• 排除项 9：停泵后靠文胸/粘合剂保持位置，而非负压。

该家族在其他抽吸阶段确实公开 latch suction、封闭夹管元件及单向阀维持乳房侧真空，但这些机制没有用于上述用户 rest phase；不能把正常泵循环中的闭阀保压移植到明确泄压的 rest phase。(Google Patents)

“very discreet”指装置在文胸中的外观隐蔽性，并非暂停场景中的静音或临时交流用途，因此只能给 I-7 部分补强，不能满足 I-6。(Google Patents)

4. 日文乳房泵代表性假阳性：JP2011516175A

该日本公开申请所属家族公开免手持乳房泵，但其运行逻辑是：

• 泵抽真空时阀关闭；

• 泵循环关闭、负压降低时，阀打开以使乳汁排出；

• 装置通过粘合层支持在乳房上。(Google Patents)

它不具备用户主动暂停，也不是停泵后由阀保持乳房侧负压，反而是泵关闭时阀开启；因此不能进入 I 主池。

I 方向最终结论

本轮没有发现新的独立 JP/KR 家族达到 I-1～I-4 的严格最低标准。

目前最合理的分层是：

• 主池：0；

• 最强桥梁：WO2016103033A2 / WO2016103031A1 关联优先权簇；

• 乳房泵条件池但明确排除：Willow/ExploraMed 家族；

• JP/KR 严格命中：本轮未检得。

因此，I 方向目前不宜表述为存在一篇新的单篇文件完整公开全部暂停保真空链条。

三、C 方向：实时数据与历史数据分开维护、请求和传输

1. 主证据池评级

2. 第一优先：US20150359490A1

Physiological sensor history backfill system and method

申请人：Medtronic MiniMed
公开日：2015-12-17；优先权日：2014-06-13。

该文件直接公开了非常完整的同一系统流程：

• 生理传感器持续取得并存储读数；

• 当前读数通过 current reading message 发送给本地基站设备，具体实施例为葡萄糖传感器与胰岛素泵；

• 本地设备把既有数据作为 historic physiological readings 存储；

• 通信中断造成历史记录缺口；

• 链路恢复后，传感器先发送当前读数；

• 本地设备检测历史缺口，另行发出 backfill record request；

• 传感器选择缺失的历史读数并分包回传；

• 正常的当前读数取得、传输和存储可以在历史 backfill 过程中继续进行。(Google Patents)

这不是“实时数据最终写入数据库后自然成为历史”的普通架构，而是明确存在：

当前消息路径 + 历史缺口检测 + 独立回填请求 + 缺失历史包传输。

因此：

• C-1：✓ 当前数据按预定间隔继续产生；

• C-2：✓ 传感器侧和泵侧均保存历史读数；

• C-3：✓ 传感器历史区、泵历史区、回填缓存及事件标记分别维护；

• C-4：✓ 当前读数消息与 backfill request/selected records 是不同请求和传输行为；

• C-5：✓ 明确由断连造成 gap，重连后回填，且正常当前读数可在回填期间继续；

• C-6：强补强 历史图表可按时间段显示，并可用颜色区分实时收到与后续回填的数据，还公开按日历史及统计摘要；不过它未必严格使用两个完全独立页面，因此在最保守口径下可记为 △。(Google Patents)

相对现有种子的价值

与 US20140172362A1 相比，它更直接地写出了：

• 历史缺口的检测；

• 对缺失记录的独立请求；

• 在 backfill 进行时正常当前读取可以继续。

与 CN104055500A 相比，它在医疗泵/连续葡萄糖监测系统中的应用距离更近，并且对“断连—重连—历史补齐—实时继续”的状态过程公开得更完整。

这是本轮最适合放入 C 主证据首位的文件。

3. 第二优先及最强 JP/KR 结果：InfoBionic 家族

代表公开号

• US20120265029A1，2012-10-18；

• WO2012142462A1，2012-10-18；

• KR20140061995A，2014-05-22；

• JP2014516626A，2014-07-17。

上述文件共享 2011-04-15 优先权链，应按一个家族计数。日本授权 JP6025819B2 的公开日为 2016-11-16，晚于截止日，但对应日本公开申请 JP2014516626A 已于 2014-07-17 公开，因此日本公开本身满足日期条件。(Google Patents)

技术链条

该家族在可穿戴/动态生理监测系统中公开：

• 传感器产生完整的生理数据；

• 完整、高分辨率数据作为 more detailed data 存储在患者侧装置的存储器；

• 较低分辨率或较低采样率的 less detailed data 子集持续、无线、实时传输到远程服务器；

• 服务器基于实时子集发现异常后，另行向患者侧装置发信号；

• 患者侧装置随后从存储器中提取相应早期时间段的详细数据，并另行传送；

• 服务器可先生成基于实时较低详细度数据的第一显示，再根据用户输入生成基于存储详细数据的第二显示。(Google Patents)

其特征评价为：

• C-1：✓ 较低详细度子集持续实时流送；

• C-2：✓ 完整详细数据在患者侧持续存储，随后可追溯取得；

• C-3：✓ 实时子集与本地完整数据在数据粒度和维护方式上明确分开；

• C-4：✓ 一路是持续实时传输，另一路是服务器信号触发的存储数据抓取；两者还具有不同分辨率、采样率和传输时序；

• C-5：× 没有把该抓取明确限定为断连后的 backfill；

• C-6：✓ 明确有第一显示和第二显示，分别基于两类数据。(Google Patents)

证据价值

它未必把两类数据字面命名为 “real-time stream” 和 “historical stream”，但其架构比普通的实时/历史共存文件更强：

低分辨率数据持续实时上传；高分辨率完整数据本地独立保存；服务器另行请求并追溯取得存储数据。

因此，它是本轮最符合“比 Dexcom 更直接说分开维护，同时存在 JP/KR 公开”的结果。

4. 日本补强文件：JP2008532587A

该家族包括：

• JP2008532587A，2008-08-21；

• WO2006090371A2，2006-08-31；

• US20080214903A1，2008-09-04。(Google Patents)

它明确公开：

• 图表连续更新并显示实时数据；

• 另一图表可以显示 previously logged data；

• 某些图表可以显示实时数据，同时另一个图表显示先前记录的数据；

• 远程服务器可以访问主体历史数据，并将历史数据传给 viewing station，用于结合当前信号进行分析。(Google Patents)

所以 C-1、C-2、C-6 较强，但其不足是：

• 没有明确的两个独立设备端队列、缓存或索引；

• 当前数据主要走传感器—手机路径，而历史数据主要由服务器访问；

• 没有像 Medtronic 那样的独立历史缺口请求和 backfill；

• 也没有像 InfoBionic 那样明确的持续实时流与按需详细数据提取。

故它适合作为日本文献中的显示层及实时/历史并行补强，不宜取代前两篇主证据。

5. 典型桥梁：US20120029311A1

CareFusion 文件公开循环缓冲区中新记录写入与旧记录读取相互独立、异步进行；传输中断时数据会在缓冲区积累，恢复读取后逐步清空。(Google Patents)

但它处理的是同一连续数据记录的 store-and-forward：

• 没有明确划分独立的当前数据类与历史数据类；

• 没有分别请求两类数据；

• 没有实时页面与历史页面的差异化处理。

因此只能作为 C-3/C-5 的缓冲与断连积累技术桥梁，不能进入严格主池。

四、代表性排除结果

五、建议的技术证据排序

C 方向

1. US20150359490A1
   用于证明：断连存储、当前消息恢复、独立历史回填请求、回填期间实时处理可继续。

2. JP2014516626A / KR20140061995A 所属 InfoBionic 家族
   用于证明：患者侧对完整历史/详细数据独立存储，实时子集持续传输，服务器另行请求存储数据，并采用不同粒度、时序和显示。

3. JP2008532587A
   用于补强：实时图表与先前记录图表可同时存在，服务器访问并发送历史数据。

这三个层次分别覆盖：

重连回填状态机 + 数据类别/传输分路架构 + JP 实时/历史界面公开。

I 方向

目前只能形成：

1. WO2016103033A2 / WO2016103031A1 关联簇：暂停、停负压源、阀在泵不活动时保压、恢复状态机的最强邻近领域桥梁；

2. Willow/ExploraMed 家族：乳房泵中的乳房侧阀保真空、latch suction 和隐蔽使用，但其用户 rest phase 明确泄压，不能用于证明严格暂停保真空。

因此，I 方向目前的检索结果更适合做技术组合关系或术语桥接，不支持声称已找到一篇新的独立乳房泵文件单篇完整公开 I-1～I-4。

本报告属于专利技术公开检索与特征比对，不构成对专利有效性、新颖性、创造性或侵权问题的法律意见。

我按 Google Patents 围绕以下几组词反复检索并交叉核对了公开日：real-time/live data stream + historical data stream、separate/separately、real-time database + historian、real-time vs non-real-time subset、live/historical data + external/mobile display，又补做了乳房泵/医疗设备方向检索。

先说结论：针对 CN113648473B 权利要求1中的“将实时数据流与历史数据流分开”这一子特征，目前最强的英文对比文件是 US20130139166A1；如果要构建更完整、技术领域更接近的创造性组合，则优先考虑 US20160082166A1 或 US20160220743A1 与 US20130139166A1 组合。

CN113648473B 的英文文本不仅在权利要求1写了“real-time data stream remains separate from the historical data stream”，说明书还进一步解释：实时更新由泵产生并存储，可由外部设备取得并实时刷新屏幕；历史数据则以流/历史日志形式保存，外部设备另行下载，用于非实时界面。也就是说，这里的“分开”不是单纯概念分类，而至少涉及实时链路与历史链路的不同处理、存储和访问方式。(谷歌专利)

其中最值得重点打的三件

**第一，US20130139166A1 是目前最直接的 X 级子特征文献。**它不是简单出现“real-time data”和“historical data”两个名词，而是在独立权利要求里明确实施“原始流→实时数据流+历史数据流”的划分，再分别处理；说明书还说历史流进入 historical data processing systems，而实时流进入 real-time processing system。(谷歌专利)

从纯粹技术特征比对看：

CN113648473B：实时数据流与历史数据流保持分开。
US20130139166A1：原始数据流被划分成实时数据流和历史数据流，并由不同处理路径处理。

二者在“实时/历史数据流分离”这一抽象层级上的差别已经非常小。

第二，US20070078555A1 对“保持分开”的解释价值很高。这件文献甚至把当时既有系统描述为可以分别访问 live data 与 historical data，实时数据取自运行过程/RAM，历史数据则独立从 database/log file 获取；不同数据类型还可以使用不同接口。(谷歌专利) 这和 CN113648473B 说明书所说的“实时数据刷新外部屏幕，而历史数据由设备另外下载来更新 non-real-time view screen”在数据通路思想上高度一致。目标专利相应说明见 (谷歌专利)。

**第三，US20080215641A1 对目标专利的“分开以后怎么用”尤其有杀伤力。**它不仅把 current operational data 存在 real-time database，把历史值存入 historian，还给外部客户端设置了分别访问实时数据和历史数据的 real-time query page / historian query page。(谷歌专利) 这比单纯的“数据库分开”更接近 CN113648473B 的“实时 view 与非实时历史 view”。

我更建议的组合路线

如果你的目标是针对权利要求1整体创造性搭组合，而不仅是证明这个子特征早已存在，我认为目前最值得深入展开的是：

US20160082166A1 + US20130139166A1。

前者与目标专利技术领域完全一致，且在 2016-03-24 已公开：乳房泵传感器产生泵奶数据、泵端存储多次 pumping session、BLE 向手机实时发送、手机界面实时刷新，同时对 session 数据进行长期趋势分析。(谷歌专利) 后者则明确教导：面对同时存在实时数据和历史数据的数据处理需求，可以直接将数据流划分成 real-time data stream 和 historical data streams，并使两者采用不同处理系统/方式。(谷歌专利)

也就是说，在技术问题层面可以形成很清楚的链条：

乳房泵已经同时产生“当前泵奶数据”和“多个历史泵奶会话数据” → 当前数据需要低延迟刷新手机，而历史数据用于会话/趋势查询 → 已知通用数据架构明确教导把实时流和历史流分开处理。

另一路也很强：US20160220743A1 + US20070078555A1。前者甚至已经区分“real-time”显示与“post-session / daily / weekly trends”；后者则告诉技术人员实时与历史数据本来就可以分别访问、来自不同数据源和不同接口。(谷歌专利)

需要特别区分一点：上述检索结论足以说明**“将实时数据流与历史数据流分开”这一子特征本身远早于 2016-11-12 已有非常明确的英文专利公开**；但若主张 CN113648473B 权利要求1整体缺乏新颖性，仍需要单一文献覆盖权利要求1全部限定。对于创造性，上述“同领域乳房泵文献 + 数据流分离文献”的组合价值明显更高。这是技术检索和证据比对意见，不是法律结论。

如果按无效实战价值排序，我目前会把 US20130139166A1、US20160082166A1、US20160220743A1、US20070078555A1、US20080215641A1 作为第一梯队，尤其前三件值得继续向前追它们的家族、引用文献、审查员引用及更早优先权文本。

我对 Google Patents 的日本公开文本又做了几轮交叉检索，包括日文同义词、数据流/数据库/服务器架构词、医疗监测词以及英文强文献的 JP 家族追踪。结论比第一轮更明确：

**针对 CN113648473B 权利要求1中的单一技术特征“将实时数据流与历史数据流分开”，目前检出的最强日文对比文件是 JP2014531092A。它不是“间接暗示”，而是直接把原始数据流分成“リアルタイムデータストリーム”和“過去データストリーム”，分别送往不同处理系统，并进一步明确历史/过去数据流不送入实时处理系统。**其日本公开日为 2014年11月20日，显著早于你给出的临界日 2016年11月12日。(谷歌专利)

一、目前最值得用于无效的日文文献

二、JP2014531092A 应当作为这个子特征的第一主证据

这件文献的重要程度明显高于其他文献。

Google Patents 对 JP2014531092A 的记录显示，其优先权日为 2011-11-24，日本公开日为 2014-11-20。摘要已经把核心方案概括为：原始数据流被分为实时数据流与过去数据流，并分别处理。(谷歌专利)

更关键的是说明书的具体实施方式：

原始数据流根据与数据相关联的时间戳，被时序地分成：

30日超数据流200 → 过去数据处理系统20

实时数据流300 → 实时数据处理系统30

30日以内数据流400 → 过去数据处理系统40

而且三个处理步骤并行执行。(谷歌专利)

说明书随后进一步把其抽象成“实时流”和“过去流”的两分结构：实时数据流送到实时处理系统，过去数据流送到过去数据处理系统；过去数据流因为已经保存在文件中，所以不发送给实时处理系统。随后又明确说实时处理系统与过去处理系统并行处理不同时间区间的数据，并明确说明过去数据与实时数据分别处理能够减轻实时计算负担。(谷歌专利)

因此针对目标特征，可以形成非常直接的技术特征对应：

这里唯一可能被专利权人拿来做文字区别的点，是 JP2014531092A 使用的是 「過去データストリーム」，而不是目标权利要求可能对应的日文表达 「履歴データストリーム」。

但从这件文献自己的定义看，这个差别很弱：所谓“過去データストリーム”就是按时间分割点以前的数据，已经存储在文件中，可以离线处理，与当前实时数据采用不同处理路径。也就是说，它在技术含义上就是 historical/past data stream，并非另一种性质的数据流。(谷歌专利)

所以，对“将实时数据流与历史数据流分开”这一单独技术特征，我会把 JP2014531092A 定为目前日文检索中的最强文献。

三、JP2015018540A 是很值得与第一篇并列提交的第二强证据

这篇的价值和 JP2014531092A 不完全相同。

JP2014531092A 最强的是：明确“分流”。

JP2015018540A 最强的是：明确“分开维护/访问两条数据路径”。

其说明书先定义：

• ライブデータ：实质实时或近实时的数据；

• 履歴データ：已经取得、存储的过去数据；

• 系统可以有 live server、history server、live/history server。(谷歌专利)

然后在具体实施方式中：

live request → receiver（接收器）→刚刚从设备/数据提供者收到的数据→客户端

而：

historical request → storage system（存储系统）→已经保存的数据→客户端。

如果一项服务器请求同时含 live 与 history 两部分，说明书还提出需要活动化至少两个 policy request handlers。(patents.google.com)

更重要的是，这不是只藏在说明书里。其权利要求3、4直接分别限定：

权利要求3：live request 时，异步数据流来自服务器的 receiver；

权利要求4：historical request 时，异步数据流来自服务器的 storage system。(谷歌专利)

这对 CN113648473B 的“保持实时数据流与历史数据流分开”尤其有用，因为“保持分开”可能会被解释成不只是建立两个名称，而是要在数据取得/数据传送路径上维持独立性。JP2015018540A 正好提供这一层证据。

四、JPH10143238A 对目标专利的“实时界面/历史界面”语境尤其强

这件1998年的日本公开非常值得重视。

它已经把：

实时数据库 → 实时趋势画面

与

历史数据库 → 历史趋势画面

明确做成两套处理关系。

实时图表从实时数据库抽取时序数据，并不断更新最新设备数据；历史图表从 historical database 抽取数据，并明确“不进行实时更新”。(谷歌专利)

而权利要求1又把这两个数据库抽象成：

第一数据库：短期保存来自设备的时序测量数据

第二数据库：长期保存需要长期监视的数据。(谷歌专利)

所以如果 CN113648473B 的专利权人在无效中强调：

“本发明的特殊之处并不是有实时数据和历史数据，而是二者要分开，以分别服务实时view与非实时历史view。”

那么 JPH10143238A 恰恰是很好的反证——这种“实时数据库/实时显示”与“历史数据库/历史显示”的分开架构，1998年已经明确公开。其公开日为1998-05-29。(谷歌专利)

五、JP2008250672A 对“同一原始数据产生实时与历史两条用途”的证明很好

这件 Yokogawa 文献的结构尤其值得用于创造性论证。

它公开：

设备数据首先被实时取得；

同时，这些刚取得的数据又被保存为非易失的履歴データ；

实时模式中，数据选择器使用实时数据；

历史数据模式中，则从历史数据存储器取得历史数据。(谷歌专利)

所以它回答了一个可能的争议点：

实时数据与历史数据是否必须来自两个不同的数据生成源？

答案显然是否定的。

同一设备实时产生的数据完全可以一条用于实时处理，同时又写入历史存储，随后通过历史数据路径访问。

这与很多 IoT、医疗设备、泵类设备的典型数据架构高度一致，而且该文献日本公开日早至 2008-10-16。(谷歌专利)

六、医疗设备方向，JPH11299740A 比一般IT文献更值得用于组合

这件1999年的《生体モニタ装置》值得单独提出，因为技术场景已经从工业数据库进入了便携式医疗监测设备。

文献公开设备：

实时检测生理信号；

把检测值/计算值存进设备存储器；

显示器既可以显示传感器的实时信号，也可以显示存储器中的过去累计数据；

通信模块还能把实时传感器信号和存储的过去累计数据传给外部信息处理设备。(谷歌专利)

而且设备可通过无线方式与外部信息处理装置通信。(谷歌专利)

它与 CN113648473B 的设备场景有一个很重要的共同逻辑：

便携设备/医疗设备 → 实时传感/运行数据 + 已存历史数据 → 外部信息处理终端。

因此，如果需要降低 JP2014531092A 属于互联网大数据领域所带来的“技术领域距离”争议，JPH11299740A 是非常好的桥梁文件。

七、同为搾乳领域的 JP2016518874A，应当怎样使用

这件我不建议单独拿来证明“实时流与历史流保持分开”。

因为它没有像 JP2014531092A 那样明确写：

“把流A与流B分离。”

但是，它的价值在于技术领域极近。

Google Patents 显示该日本A公开为 JP2016518874A，2016-06-30公开，在你的2016-11-12临界日前。(谷歌专利)

同一日本申请文本明确公开：

计算设备可以与搾乳器通信；

可以建立、更新 搾乳ログ、実績チャート；

又可以用视频实现 リアルタイムでの実績フィードバック；

权利要求还明确规定反馈可以实时提供、计算设备可以与搾乳器通信。(谷歌专利)

因此它最适合回答：

在乳房泵/搾乳这一具体领域，本领域技术人员在2016-11-12以前是否已经面对“实时反馈数据”和“历史搾乳记录/趋势数据”这两种不同数据需求？

答案显然是肯定的。

所以它与 JP2014531092A 的组合尤其值得研究：

JP2016518874A：同领域，提供搾乳器＋实时反馈＋搾乳历史日志/趋势；

加上：

JP2014531092A：明确教导将实时数据流与过去/历史数据流分割，并使用不同的数据处理路径。

从技术问题的衔接看，这个组合比“单纯工业数据库＋乳房泵”的距离更短。

八、我目前建议的无效证据层级

如果只针对你指定的这一个技术特征，我目前会按下面的顺序投入精力：

1. **JP2014531092A —— 第一主证据。**直接披露“实时数据流/过去数据流分割＋不同系统＋历史流不进入实时系统”，是目前最强的字面/技术实质对应。

2. **JP2015018540A —— 第二主证据。**live/history 请求分别从 receiver 和 storage system 获取数据流，特别适合证明“保持分开”。

3. **JPH10143238A —— 第三主证据。**实时数据库/历史数据库及实时显示/非实时历史显示双重分离。

4. **JP2008250672A、JP2005346562A、JP2003050622A —— 公知架构证据。**证明设备实时数据与历史数据采用不同存储、取得和处理路径是很早就成熟的技术。

5. **JPH11299740A —— 医疗设备桥接证据。**证明医疗/便携设备本身就存在“实时传感数据＋存储历史数据→外部设备”。

6. **JP2016518874A —— 搾乳领域锚点。**不要单独承担“数据流分开”的全部证明任务，而应和 JP2014531092A 或其他明确分流文献组合。

一个关键判断

经过这轮日文检索，我认为对“将实时数据流与历史数据流分开”这一子特征，已经不是“通过多个文献可以推导”的程度，而是存在2014年的日本公开公报直接明文公开。

尤其是 JP2014531092A 的：

“原始流→实时数据流＋过去数据流”

再加：

“实时流→实时处理系统；过去流→过去处理系统；过去流不进入实时处理系统”

已经把“separate”的技术含义披露得相当完整。(谷歌专利)

因此，若无效请求中把这一特征作为专利权人主张创造性的核心差异点，我会优先用 JP2014531092A 把这个差异点本身压掉，再用 JP2016518874A/JPH11299740A 解决“乳房泵/医疗设备领域为什么会采用这种架构”的组合动机问题。

另需注意：以上是基于 Google Patents 的技术检索和公开文本比对，不是法律意见。正式作为中国无效程序证据使用前，建议再以 J-PlatPat/日本特许厅原始A公报PDF逐件核对公开日、段落及页码，尤其是 JP2016518874A；Google Patents 当前对该A公报日文页抓取存在异常，我是通过同一日本申请的公报记录及B2文本进行了交叉核验。

我又围绕 Google Patents 做了多轮韩文关键词检索、英文强文献的韩国国家阶段反查、KR 同族追踪，并逐件核对了韩国公开公报的实际公开日。检索重点不是只找同时出现“실시간 데이터（实时数据）”和“이력 데이터（历史数据）”，而是进一步要求存在分开的处理部、数据源、存储系统、请求处理器或数据库路径。

结论是：在2016年11月12日以前的韩文公开中，目前最值得用于攻击“将实时数据流与历史数据流分开”这一技术特征的是 KR20150005428A 与 KR20140007300A。 前者对“保持两条数据访问路径分开”特别强；后者则直接使用“实时传感器流数据＋历史数据处理部”的 stream 架构。另有 KR20130022760A 对“为什么要把历史数据与实时系统隔离”给出了非常明确的技术动机。

第一梯队韩国对比文件

1. KR20150005428A —— 我认为是韩国文献中最值得主打的一件

Google Patents 显示该韩国A公开于 2015年1月14日，优先权日为2013年7月5日，申请人为 Boeing。(谷歌专利)

它的重要之处在于，说明书和权利要求不是泛泛讲“实时数据”和“历史数据”。

文献首先明确：

• live request 是对实时或近实时数据的请求；

• historical request 是对过去选定时间段已经取得的数据的请求。(谷歌专利)

然后给出两条明显不同的数据路径：

实时路径：

data provider → receiver → live request handler → client

服务器收到 live request 时，以 receiver 412 作为输入数据源；这些数据点是在接收器收到时直接用于客户端响应。(谷歌专利)

历史路径：

receiver → storage system → historical request handler → client

historical request 时，服务器改为选择 storage system 414 作为输入数据源，从已经存储的数据点中检索历史数据。(谷歌专利)

最关键的是它的权利要求已经把这种关系写到了 data stream 层面：

• receiver 被配置为接收多个异步数据流；

• live data 请求时，取得的是这些异步数据流被存入 storage system 之前由 receiver 接收的数据；

• historical data 请求时，则从 storage system 检索输入数据。(谷歌专利)

而且，如果服务器请求同时含 live 和 historical 两部分，文献明确提出启动至少两个 policy request handlers分别处理。(谷歌专利)

因此，若把 CN113648473B 的“将实时数据流与历史数据流分开”理解为：

实时数据保持在低延迟实时访问路径，而历史数据通过存储后的历史访问路径取得，两者不混用同一取数路径，

那么 KR20150005428A 是非常强的直接证据。

它甚至比普通“实时数据库＋历史数据库”的文献更有价值，因为它明确到了流、数据源和请求处理器三个层级。

2. KR20140007300A —— “stream”字面和处理架构最接近

该文献名称为：

KR20140007300A《하둡 기반 센서 스트림 데이터 처리 시스템 및 방법》
即“基于 Hadoop 的传感器流数据处理系统及方法”。

Google Patents 确认：

• 优先权日：2012-07-09；

• 公开日：2014-01-17；

• 申请人：釜山大学产学协力团。(谷歌专利)

其说明书开门见山地说系统同时具备：

실시간 센서 스트림 데이터를 처리하는 컴포넌트

即“处理实时传感器流数据的组件”，以及：

이력 센서 데이터의 통계 분석을 지원하는 컴포넌트

即“支持历史传感器数据统计分析的组件”。(谷歌专利)

这还不是最强的地方。

其实施方式进一步规定：

数据采集部214实时采集传感器 stream data，然后把采集的数据送往：

• 실시간 데이터 처리부(20) —— 实时数据处理部；

• 이력 데이터 처리부(21) —— 历史数据处理部。

历史数据处理部再从 HDFS 中取得：

스트림 센서 이력 데이터

即 stream sensor historical data，并使用 MapReduce 处理和分析。(谷歌专利)

而且其权利要求4明确限定：

历史数据处理部从 HDFS 获取已预先存储的 stream sensor data 的历史信息，进行历史统计分析，再与实时 stream sensor data 的处理结果组合。(谷歌专利)

因此可以把它画成：

传感器产生 stream data

→ 实时数据处理部20 → 实时流处理

同时

→ 历史数据处理部21 / HDFS → 存储及历史流数据处理

这种结构与目标子特征之间的对应关系非常明显：

唯一需要谨慎的是：它没有逐字写成一句“将实时数据流与历史数据流分开”。但是，结构上确实建立了两个不同处理组件和不同数据取得方式，而且涉及的原始对象就是 sensor stream data。(谷歌专利)

所以，如果强调“stream”文字匹配，我会把它与 KR20150005428A 并列第一梯队。

3. KR20130022760A —— 对“为什么要分开”的创造性论证特别有价值

**KR20130022760A《배전계통 관리 시스템 및 방법》**公开日为 2013年3月7日，申请人为韩国电力公社。(谷歌专利)

这件文献先把当时已有配电管理系统明确描述为包括：

• 실시간 데이터베이스(54)——实时数据库；

• 이력 데이터베이스(58)——历史数据库；

• 另有 history server 等。

也就是设备运行数据的实时和历史管理本身已经采用不同数据库组件。(谷歌专利)

但这件文献真正有杀伤力的地方是后面的技术动机。

它明确写道，存储历史DB、设备DB等的管理数据库：

실시간 시스템운영에 지장을 주지 않도록 오프라인으로 구성

意思非常清楚：

为了不妨碍实时系统运行，将包含历史数据库的管理数据库构造成 offline。(谷歌专利)

这对创造性论证非常有用，因为它直接回答：

为什么本领域技术人员会想到让实时数据路径和历史数据路径保持分开？

答案早在2013年韩国专利中就写得很明确：

避免历史数据存储、维护、编辑等操作影响实时系统运行。

这和 CN113648473B 采用实时流来持续更新实时界面、而历史数据另作历史查看的工程目的具有非常容易理解的技术联系。

因此这件文献我会更多用于：

“分流的技术动机／技术常识”证据

而不是单独承担“data stream”字面覆盖任务。

4. KR20090032395A —— 很早的“实时DB/历史DB”公知证据

**KR20090032395A《배전지능화 시스템 및 그 방법》**由韩国电力公社申请，公开日早至 2009年4月1日。(谷歌专利)

其 SCADA/DMS 架构明确列出：

• 실시간DB(96)；

• 제어DB(97)；

• 이력DB(98)。

也就是说，实时数据库与历史数据库本身就是独立组件。(谷歌专利)

服务器还负责：

• 远程数据测量；

• 设备运行状态监视；

• 事件记录；

• 이력데이터 저장 관리——历史数据存储管理。(谷歌专利)

这件文献的弱点是没有把两个对象直接命名为两个“data streams”。

但它的优势也很明显：

2009年以前，设备实时运行数据和历史数据采用实时DB/历史DB分别管理，已经属于明确公开的监控系统架构。

所以如果专利权人试图把“separate”解释得很宽，仅仅理解为实时数据和历史数据在系统内分别维护，那么该文献会很有用。

5. KR20150027277A —— “实时数据流＋历史数据”的补强证据

**KR20150027277A《빅 데이터 분석 시스템》**由 Applied Materials 申请，日本？不是，韩国A公报公开日为 2015年3月11日。(谷歌专利)

它明确写：

실시간 데이터 스트림

即 real-time data stream，系统从制造设备的数据源接收实时数据流。(谷歌专利)

然后根据规则把实时流中的数据分别放入：

• memory-resident operational storage；

• distributed storage。

同时系统又明确具有：

• 실시간 데이터(253)；

• 히스토리 데이터(historical data; 255)，

历史数据可供 crawler/batch 分析获取额外信息。(谷歌专利)

而实时数据流的一部分被识别为即时运行数据，进入快速访问的 memory-resident storage；其他实时数据进入 distributed storage，留作后续使用/处理。(谷歌专利)

这件文件不如前两件直接，因为历史数据并没有始终被明确称为“historical data stream”。所以我不会把它排在 KR20150005428A 或 KR20140007300A 前面。

但对以下论点很有贡献：

本领域早已知道从设备产生的实时数据流中区分当前运行数据与需持久保存、后续历史分析的数据，并赋予不同存储和处理路径。

从无效攻击角度，我建议这样使用

如果只攻击**“将实时数据流与历史数据流分开”这个单一子特征**，我会形成三层证据链：

第一层——直接数据流/数据路径证据：

KR20150005428A + KR20140007300A

前者证明：

data streams → live 在存储前直接取得 / historical 从存储后取得 → 不同 handler

后者证明：

sensor stream → realtime processor / history processor + HDFS

两件结合起来，“实时与历史数据路径分别维护”已经很难说是2016年的新技术构思。(谷歌专利)

第二层——为什么要分开的明确技术动机：

KR20130022760A

它直接告诉技术人员：

把历史数据库做成 offline，就是为了不影响 realtime system operation。(谷歌专利)

这是创造性组合中非常好用的一句话。

第三层——长期公知性：

KR20090032395A

用于证明设备监控领域在2009年已经明确采用：

实时DB / 历史DB分别设置。(谷歌专利)

一个需要特别说明的检索结论

这次韩国检索与上一轮日本检索存在一个差异。

我目前没有找到一件2016-11-12以前的 KR A公开，像上一轮的 JP2014531092A 那样，以一句几乎完全相同的话明确写：

“将原始数据流分割为实时数据流和历史数据流”。

韩国文献中目前最接近的是两种形式：

KR20140007300A：
“实时传感器 stream data”与“历史 stream sensor data”使用不同 processing component；

以及：

KR20150005428A：
同一组 asynchronous data streams 在实时访问时从 receiver 直接输出，在历史访问时从 storage system 输出，而且可以由两个独立 handler 处理。(谷歌专利)

从技术实质看已经非常接近“keep the real-time data stream separate from the historical data stream”，但在正式无效请求中，我不建议把它描述成“完全逐字相同”，而应表述为：

“通过不同的数据源、存储状态、处理单元及请求处理器，使实时数据路径与历史数据路径保持相互区分。”

这样更准确，也更不容易被对方抓住翻译措辞上的漏洞。

另外，我专门对截止日期进行了排除：例如有些韩国文献虽优先权早于2016-11-12，但韩国公开日在2016-11-12之后，这类文件我没有纳入上述主表；无效检索这里应当以能够证明在临界日前已经向公众公开的日期为准，而不能仅凭优先权日在前。

**如果以目前这批韩文材料排无效价值，我的顺序是：KR20150005428A ≈ KR20140007300A ＞ KR20130022760A ＞ KR20090032395A ＞ KR20150027277A。**其中前两件建议全文下载后做成正式的“权利要求1子特征—韩文原文—中文译文—附图/权利要求位置”证据对照表。以上是专利技术检索和对比分析，不构成法律意见。

按你这次的限制，我重新做了一轮仅以韩文关键词正向检索 Google Patents 的检索：没有从此前英文、日文对比文件的 Family / Also Published As / Priority family 去反查 KR 同族，也没有把这种方式找到的文件计入本轮结果。上一轮曾出现的同族追踪型候选（例如 KR20150005428A）因此本轮不纳入排序。

先把目标特征的技术含义固定下来。CN113648473B 权利要求1要求“The real-time data stream remains separate from the historical data stream”；说明书又解释为实时数据和历史数据可采用不同处理方式、数据流分别维持，实时数据用于更新外部设备实时画面，而历史数据保存在泵内历史日志/stream 中、由外部设备下载后更新非实时历史画面。(谷歌专利)

本轮正向检索后，我认为真正值得用于无效的韩国文献如下。

1. KR20140007300A——本轮不反查同族后，我认为最强

这是本轮最值得深入做证据比对的一件。

Google Patents 确认其韩国公开日为 2014年1月17日。(谷歌专利)

它在说明书中直接说明系统具有：

“실시간 센서 스트림 데이터를 처리하는 컴포넌트”
和“이력 센서 데이터…컴포넌트”

也就是实时传感器流数据处理组件与历史传感器数据统计分析组件两个不同组件。更具体地说，数据采集部实时采集 stream sensor data，达到条件后分别发送给 실시간 데이터 처리부(20) 与 이력 데이터 처리부(21)。(谷歌专利)

历史数据处理部的路径又非常明确：

已存的 stream sensor data → HDFS → 历史数据处理部21 → MapReduce历史统计分析

而实时路径则：

当前 sensor stream → 实时数据处理组件 → 连续查询/实时处理

说明书明确写到历史处理部从 HDFS 取得 스트림 센서 이력 데이터，以及取得已经存储的 stream sensor data history information；权利要求4也明确限定这一历史数据处理部，并把它与 실시간 스트림 센서 데이터 区分。(谷歌专利)

对应关系可以做得很清楚：

这里有一个非常重要的诉讼措辞问题：

我建议不要说它“逐字公开了实时流与历史流永远保持分离”。

因为该文献后面明确说两个处理组件的处理结果最终可以结合。(谷歌专利)

更稳妥而且技术上更准确的表述是：

KR20140007300A 已明确教导，将实时传感器流数据和已经存储的历史流数据置于相互不同的数据处理组件及处理路径中分别处理。

这一表述对“将实时数据流与历史数据流分开”的创造性攻击非常强。

2. KR20150033210A——“同一输入→实时处理/历史处理”结构非常漂亮

该韩国公报公开日为 2015年4月1日。(谷歌专利)

它的图2架构非常值得画进无效对比图。系统明确包含：

입출력관리부 101 → 数据处理部102

以及独立的：

이력 처리부 104 → 이력 데이터베이스 108

说明书进一步规定：

数据处理部102对来自输入输出管理部的实时数据进行确认，然后送至 alarm processor；

与此同时，独立的历史处理部104基于输入数据和数据处理结果生成历史数据，再周期性或实时写入历史数据库。(谷歌专利)

因此可以概括成：

远程设备数据

→ 实时数据处理部102 → alarm/实时监控

同时

→ 历史处理部104 → 历史数据 → 历史数据库108

这与 CN113648473B 的实质关系非常接近：

泵当前运行数据→实时用途

与

过程数据→history log→后续历史用途

目标专利说明书恰好就是把两类数据的处理方式、存储及外部显示用途进行区分。(谷歌专利)

它没有把词写成 실시간 데이터 스트림 / 이력 데이터 스트림，因此“stream”的字面匹配弱于 KR20140007300A；但是从同一设备输入数据被功能性分成实时路径和历史路径来看，反而非常直观。

我会把它作为本轮的第二主证据。

3. KR20160022713A——对“设备运行数据”的场景匹配尤其好

这件文件公开于 2016年3月2日，满足2016-11-12以前的时间条件。(谷歌专利)

其独立权利要求1本身就建立了多个不同模块：

实时路径：

DCS → 实时接收设备数据 → 阈值检查模块 → 实时异常判断/告警

历史路径：

同一设备数据 → 历史数据存储模块 → 生成历史数据 → Hadoop分布式保存 → 历史数据分析模块

而用户界面又能够分别查询当前设备数据与历史数据。(谷歌专利)

尤其值得引用的是说明书的实际数据流：

设备数据首先被实时接收；系统把该数据发送给历史数据存储模块，生成并保存历史数据；历史分析模块以后再把历史数据调出分析。与此同时，UI能够查询：

실시간 데이터(S6) 与 이력 데이터(S7)

即实时数据和历史数据。(谷歌专利)

这件文件的价值在于，它不像纯数据库专利那样离“泵运行数据”很远，而是：

真实物理设备 → 连续产生运行数据 → 当前实时监控/告警 + 历史保存/分析。

所以即使它没有逐字说 separate data streams，它对证明本领域工程人员自然会把同一设备运行数据分成实时处理路径与历史存储/分析路径非常有用。

4. KR20130022760A——对“为什么要分开”的技术动机极强

这件我建议在创造性论证中重点使用，而不是只当普通数据库文件。

公开日为 2013年3月7日。(谷歌专利)

其背景及系统架构明确并列：

• 실시간 데이터베이스(54)——实时数据库；

• 이력 데이터베이스(58)——历史数据库；

• 另有控制数据库等。

DMS服务器分别管理上述数据库。(谷歌专利)

更重要的是，其实施例进一步规定，保存历史数据、设备数据等的管理数据库以 offline 状态运行，并明确写：

실시간 시스템운영에 지장을 주지 않도록 오프라인으로 구성

即：为了不妨碍实时系统运行，将其配置为离线。(谷歌专利)

这个公开对无效非常有价值，因为它不只是告诉技术人员“可以把实时和历史数据分开”，而是直接给出了为什么要分开的工程理由：

历史数据的保存、维护、编辑、分析等非实时工作不应影响实时系统。

这与 CN113648473B 将实时数据用于即时外部屏幕更新、历史数据另写 history log 并用于 non-real-time view 的技术逻辑是高度一致的。目标专利对此的表述见说明书及权利要求1。(谷歌专利)

所以如果做创造性“三步法”，这件文件非常适合承担技术启示/组合动机。

5. KR20090032395A——证明“实时DB/历史DB分别设置”至少2009年已公开

该文件韩国公开日早至 2009年4月1日。(谷歌专利)

其权利要求相关架构直接出现：

실시간DB(96), 제어DB(97), 이력DB(98)

即实时DB、控制DB、历史DB为不同数据库组件。(谷歌专利)

而服务器功能同时包括远程数据测量、运行状态监控、事件记录以及历史数据存储管理。(谷歌专利)

它不是最好的“stream”文件，因为数据库虽然结构独立，却还通过 middleware 分享数据。

因此，我不会用它证明：

“两个stream绝对互不接触”。

但它特别适合证明一个更基础的公知事实：

将设备运行的实时状态数据与历史记录分别由实时数据库和历史数据库管理，在2009年前后已经是明确公开的系统架构。

6. KR20100012929A——实时传感器处理与后续历史存储的早期IoT证据

该文件公开日为 2010年2月9日。(谷歌专利)

其系统包含：

• 실시간 센서 데이터 처리 미들웨어부——实时传感器数据处理 middleware；

• 实时数据处理部；

• 独立的数据库管理部。

实时传感器数据由 middleware 采集、净化和处理；而数据库管理部又把提取出的实时传感器数据另外存进数据库，明确用于以后包括传感器使用历史等用途。(谷歌专利)

所以它体现：

当前sensor data → realtime processing

同时：

当前sensor data → database → subsequent history use

这和 CN113648473B 中“同一泵运行产生的数据，一方面承担实时更新，另一方面沉淀成历史记录”的数据生命周期逻辑很接近。

它对“两个独立stream”的直接程度不如前三件，但作为传感器/设备数据领域的早期常规架构证明很有价值。

对本轮检索结果的判断

在严格执行“不反查同组”之后，我认为最应该投入无效证据制作精力的是：

KR20140007300A ＞ KR20150033210A ≈ KR20160022713A ＞ KR20130022760A ＞ KR20090032395A ＞ KR20100012929A。

其中可以形成一条很完整的证据逻辑：

KR20140007300A解决“stream + 实时/历史分别处理”；

KR20150033210A解决“同一设备输入→实时处理部/历史处理部两条路径”；

KR20160022713A解决“物理设备运行数据→实时用途/历史存储分析用途”；

KR20130022760A进一步解决“为什么本领域技术人员有动机保持历史数据处理与实时系统相分离”。

特别是 KR20140007300A 的结构：

实时 sensor stream → 实时处理组件

对照

已存 sensor stream history → HDFS → 历史处理组件

在2014年已经明确出现，而且两个组件的输出是处理完成以后才组合。(谷歌专利)

因此，如果 CN113648473B 的专利权人把“将实时数据流与历史数据流分开”主张为权利要求1的创造性贡献点，仅凭本轮不依赖同族反查获得的韩国公报，也已经有相当有力的证据证明这种分开处理思想在2016-11-12以前是成熟技术路线。

不过，对证据强度要准确表述：本轮我尚未发现一件韩国正向检索文件像英文某些文献那样，逐字写出“divide a raw stream into a real-time data stream and a historical data stream，并始终保持二者分离”这一完整句式。目前最强的是 KR20140007300A 的“两个不同stream/history处理组件”，以及 KR20150033210A/KR20160022713A 的结构性双路径。因此，前者很适合打该子特征的创造性，后两者适合进一步证明这种分流在设备监控领域属于常规工程设计；若要单独主张该子特征被一件韩文文献完全、直接、无歧义公开，措辞应比创造性论证更谨慎。

以上属于专利检索及技术特征比对，不是法律意见。

按照你这次的限定，我重新做了多轮 Google Patents 中文关键词正向检索，检索词覆盖“实时数据流/历史数据流、实时数据/历史数据、分开/分离/分路/分别、实时服务器/历史服务器、实时数据库/历史数据库、实时显示/历史显示、传感器/设备/客户端”等组合。本轮没有通过英文、日文、韩文文献反查中国同族，也没有利用 Family/同组作为发现路径；并严格以 2016年11月12日以前已经公开 为筛选标准。

这轮有一个很重要的新发现：CN202009405U 的技术披露比单纯“实时数据库＋历史数据库”更直接——它在权利要求1中明确要求采集后的传感器数据“分两路输出”，分别进入实时服务器和历史服务器；说明书进一步明确“一路”传实时数据，“另一路”周期发送历史数据。就“将实时数据流与历史数据流分开”这一子特征而言，它是目前中文正向检索中我认为最值得主打的文件之一。

一、建议优先使用的中文对比文件

二、CN202009405U 应当重点前移——它真正出现了“分两路”

这件文件值得特别重视。

其公开日是 2011年10月12日，远早于2016年11月12日。(谷歌专利)

其权利要求1不是仅仅说“有实时服务器和历史服务器”，而是：

传感器 → 采集模块 → 格式模块 → 分两路输出 → 网络模块 → 分别接入实时服务器和历史服务器。

权利要求原文的核心就是：

“格式模块……分两路输出……分别接入实时服务器和历史服务器。”

(谷歌专利)

说明书进一步把这“两路”是什么说得非常清楚：

第一路：

传感器实时采集的数据
→ 格式模块
→ 网络模块
→ 实时服务器4

第二路：

传感器数据
→ 生成历史数据统一格式文件
→ 按一定周期发送
→ 网络模块
→ 历史服务器5

Google Patents 的中文文本明确写道：格式模块把传感器实时采集的数据分两路输出，一路传到实时服务器，另一路将历史数据文件周期发送到历史服务器进行存储分析。(谷歌专利)

这与目标特征的对应程度很高：

尤其值得注意的是，目标特征的关键词是“将……分开”。

CN202009405U 用的不是抽象意义上的“两个库”，而是非常物理、非常结构化的：

“分两路”。

因此，如果争点是“separate”到底要求什么，我会优先把这件文件作为证据之一。

三、CN103605805A——对“实时流与历史流在时间维度上切开”最强

如果 CN202009405U 是网络路径意义上的分开，那么 CN103605805A 就是数据流生命周期意义上的分开。

该A公开日为 2014年2月26日。(谷歌专利)

它首先面对的就是时序数据。

说明书明确规定：

按照数据新旧，把具体时序数据分为两类：历史数据和实时数据。

进一步甚至定义了：

“历史数据和实时数据的分割时刻实际也是实时数据起始时刻。”

(谷歌专利)

然后两类数据采用完全不同的存储路线：

实时数据：

→ HBase 实时数据表
→ 每条实时记录独立写入
→ 提供实时读写

历史数据：

→ HBase 历史数据表
→ 按时间段段存储
→ 使用针对历史时间区间的访问方式

(谷歌专利)

并且随着时间推移：

实时数据 → 变成历史数据 → 从实时数据表迁移到历史数据表。

也就是说，这件文献清楚体现了：

一个持续产生的时序数据序列

在某一时间分界点被划分为：

当前实时部分

和

过去历史部分

再采用不同的数据处理和存储路径。

如果专利权人认为“data stream”不能简单等同于“数据库里的数据”，这件文献会特别重要，因为它本身讨论的就是连续时序数据和数据流动。

我会把它和 CN202009405U 组合起来理解：

CN103605805A解决“怎么把实时与历史数据从连续时序数据中划开”；

CN202009405U解决“划开以后怎么走两条独立路径”。

这两件互补性非常强。

四、CN101499070A——对“保持分开”三个层级同时有贡献

这件2009年的文件价值很容易被低估。

其公开日为 2009年8月5日。(谷歌专利)

它不是只有两个名称，而是在至少四个层级保持实时/历史数据相互区分。

首先是数据物理来源不同：

实时数据 = 内存型实时数据

历史数据 = 文件型历史数据

其次是服务组件不同：

内存型实时数据服务组件

与

文件型历史数据服务组件

第三是数据抽象表不同：

实时数据表

与

历史数据表

第四是访问请求不同：

历史请求由历史数据服务组件从历史文件取得；

实时请求由实时数据服务组件从内存实时数据取得。

甚至请求标识本身都是不同的：

历史数据请求采用类似 HISASK；

实时数据请求采用类似 REALASK。

(谷歌专利)

所以这件文件对“保持实时数据流与历史数据流分开”尤其有力。

即使专利权人解释“保持分开”不是简单存到两个数据库，而要求从处理、存储、读取路径上保持相互区分，CN101499070A 都已经提供了很完整的回答。

五、CN103617161A——中文原文直接出现“分开处理”

这件文献的优势是文字非常好用。

公开日为 2014年3月5日。(谷歌专利)

其说明书直接说：

建立两个数据库，即生产数据库和历史数据库：

分别存储当前实时数据和历史数据。

并明确把这一方案与：

“历史数据不能分开处理”

的情况作对比。

文献说采用这种分别存储后，可以减少系统负担、提高数据处理速度；而且历史库可以独立维护。(谷歌专利)

它的逻辑实际上就是：

当前实时数据 → 生产数据库

历史数据 → 独立历史数据库

而且实时数据随着时间经过会迁入历史数据库。

所以在创造性陈述中，这件文献很适合用来证明：

在2014年前，本领域已经明确认识到实时数据与历史数据由于使用需求和访问性能不同，应当分别存储、分开处理。

它虽然属于SAAS/database领域，与乳房泵技术领域距离较远，但作为数据处理这一争议子特征本身的公知技术证据非常好。

六、CN104182820A 与 CN113648473B 相邻限定特别接近

如果不只是打一句“分开”，而要考虑 CN113648473B 权利要求1中紧邻的：

设备产生数据 → 外部设备实时屏幕显示 → 历史数据下载/历史屏幕显示

那么我认为 CN104182820A 应当重点保留。

公开日为 2014年12月3日。(谷歌专利)

这件文件中的物理设备是无人驾驶车辆。

其数据路径为：

车载终端实时产生车辆信息

然后分成两种处理：

实时路径：

车载终端
→ 数据服务器
→ 直接发送网站客户端
→ 客户端实时显示

历史路径：

车载终端
→ 数据服务器
→ 数据库服务器保存
→ 网站服务器以后从数据库中调取
→ 客户端显示历史数据

(谷歌专利)

说明书还直接解释：

对于实时性要求高的数据采用 SignalR 直接传输，以降低延时；

对于后续用途则存储到数据库，供历史数据分析。

这在功能逻辑上与 CN113648473B 非常接近：

当前设备数据 → 快速实时链路 → external screen

而

已经保存的数据 → 历史访问链路 → historical/non-real-time view

因此，虽然 CN104182820A 没有把两条路径命名为“real-time data stream / historical data stream”，但在解释目标专利所谓“separate”的技术实质时，它很有价值。

七、CN1881744A——2006年已经有“实时服务器/历史服务器/客户端”三角结构

这是目前找到的比较早、又非常具有设备监控意义的一件。

公开日为 2006年12月20日。(谷歌专利)

换流站的现场数据：

现场采集装置

→ 前置数据服务器

→ 实时数据服务器

实时服务器向客户端提供当前实时数据。

与此同时：

实时服务器按照一定时间间隔

→ 历史数据服务器

历史服务器负责保存数据，并：

→ 单独为客户端提供历史数据。

说明书明确说实时服务器用于为客户端提供实时数据服务，而历史数据服务器用于保存历史数据并为客户端提供历史数据。(谷歌专利)

所以早在2006年就已经形成：

设备运行数据 → 实时服务器 → 客户端实时使用

以及：

设备运行数据 → 历史服务器 → 客户端历史查询

两套明显不同的用途路径。

从目标专利的“乳房泵→external device”角度，这件文件比纯数据库文件更容易建立技术类比。

八、CN102236873A 特别适合证明“为什么本领域人员会主动分开”

这件文件公开日 2011年11月9日。(谷歌专利)

其摘要几乎已经替创造性组合论证写好了理由：

将对实时性要求很高的实时报价数据服务器和实时性要求不高的……历史数据服务器分开。

分开后：

提高服务器运行效率

并且：

降低服务器成本。

(谷歌专利)

虽然它属于行情系统，但争议技术问题本身并不是“怎么泵奶”，而是：

实时数据与历史数据为什么采用不同数据路径？

这件文件给出的技术动机非常直接：

实时数据有低延迟要求，历史数据没有相同实时性要求，因此把两类处理路径分开。

这种技术动机非常适合与设备监控类文件搭配使用。

九、值得特别保留的“设备/移动终端”补强证据

CN102562451A 的价值不是“分开”文字最强，而是它的系统关系非常接近 IoT：

风机、风电场等现场设备持续上传运行数据；

系统内设置实时数据库8和历史数据库9；

外部又设置普通客户端和通过互联网连接的移动客户端15；

用户可以查看实时信息、实时运行数据以及历史记录。其公开日为 2012年7月11日。(谷歌专利)

CN204633816U 更进一步，已经是典型：

物理设备（逆变器）→采集器→云数据中心→PC/手机/平板客户端

且云数据中心内部采用：

实时数据库和数据处理服务器集群

以及独立的：

历史数据库集群。

说明书甚至明确说：

把采集、实时数据和数据处理、历史库分布到不同的服务器上，实现并行处理。

其公开日为 2015年9月9日。(谷歌专利)

后者对于证明：

截至2015年，物联网设备产生的数据采用实时数据路径和历史数据存储路径，再由手机等外部终端访问

已经是常见工程架构，非常有帮助。

十、如果现在就做无效，我会这样排证据

针对**“将实时数据流与历史数据流分开”这一子特征本身**，我的技术证据优先级已经比较清晰：

1. CN202009405U —— 最强“物理分路”：传感器实时数据明确“分两路输出”，一路实时服务器、一路历史服务器。

2. CN103605805A —— 最强“数据流/时间分割”：时序数据明确分成实时/历史两类，并存在明确“分割时刻”，分别进入实时表和历史表。

3. CN101499070A —— 最强“保持分开”：实时/历史数据在存储介质、服务组件、数据表、请求路径四个层级分别维护。

4. CN103617161A —— 最强“文字论证”：明确说建立两个库“分别存储当前实时数据和历史数据”，并直接谈到历史数据“分开处理”。

5. CN104182820A —— 最强“目标使用场景类比”：设备当前数据直接送客户端实时显示，历史数据经数据库路径另行显示。

6. CN1881744A / CN101255947A —— 很早的物理设备实时服务器/历史服务器分离架构。

7. CN102236873A —— 非常好的“为什么要分开”的明确技术动机。

8. CN102562451A / CN204633816U —— 用于把“设备＋实时/历史分离＋外部/移动客户端”串起来。

因此，这一轮中文检索后的判断比前几轮更强：

仅就“将实时数据流与历史数据流分开”这个技术思想而言，不只是存在“两个数据库”的泛泛现有技术，而是在2011年的 CN202009405U 中已经出现了“传感器实时数据分两路，一路进实时服务器、另一路生成历史数据并进历史服务器”的非常具体架构；2014年的 CN103605805A 又进一步明确了连续时序数据中实时数据和历史数据的“分割时刻”以及两套不同存储机制。(谷歌专利)

如果把“separate”理解得更严格，例如要求实时链路与历史链路不仅名称不同，而且处理、存储和访问路径均不同，那么 CN202009405U + CN101499070A 的组合尤其有力：前者解决物理“分两路”，后者解决实时/历史数据在服务组件、存储介质和请求处理上持续保持区分。(谷歌专利)

反过来，若专利权人强调目标发明特殊之处是实时数据用于外部终端即时显示，而历史数据用于非实时历史界面，则 CN104182820A、CN1881744A、CN102562451A 是很有价值的桥接文件，因为它们在2016年前已经把物理设备运行数据→实时客户端显示和历史数据→数据库/历史服务器→客户端历史显示作为不同的数据通路来使用。(谷歌专利)

需要准确区分的是：上述结论足以对该子技术特征的创造性/公知性形成很强的攻击基础；若要主张 CN113648473B 权利要求1整体缺乏新颖性，仍需在一件单独的临界日前公开文件中寻找权利要求1全部限定的直接、无歧义披露。以上属于专利检索和技术特征比对分析，不构成法律意见。

我按公开日严格早于 2016-11-12，在 Google Patents 中围绕 breast pump / pumping session / extraction session / session history / latch suction / latch vacuum / rest phase / pause / resume / five minutes / session start / session duration / stored session data 等组合反复检索后，结论比较明确：

目前没有检到一件 2016-11-12 前公开的英文乳房泵专利，在同一实施方式中逐字、完整公开“存储过程数据 + 过程以 latch 开始定义 + ≤5分钟暂停仍属于同一过程”这三个限定。
但已经找到一组相当有价值的文件，其中几件把该区别特征拆得非常接近。对权利要求3而言，创造性攻击明显强于单篇新颖性攻击。

一、最值得进入主证据池的英文文件

其中前三件尤其重要。它们虽然均来自 Exploramed NC7 的早期乳房泵研发，但属于不同 PCT 公开，不应把同一披露的美国国家阶段版本重复计算为新的独立技术来源。

二、D1：WO2016014469A1——目前最重要的“骨架文件”

WO2016014469A1，Breast pump system and methods，公开日 2016-01-28，优先权 2014-07-22。 Google Patents明确记载其属于 A61M1/06 乳房泵领域。(谷歌专利)

它对本次权3区别特征至少贡献三个关键环节。

第一，它已经把 latch suction 与 pumping session 本身直接绑定。权利要求1明确要求：先在乳房泵与乳房之间形成密封，然后进行泵乳，并在整个 pumping session 中维持至少 latch suction。系统权利要求也同样规定 latch suction throughout a pumping session。(谷歌专利)

第二，它明确公开了在一个尚未结束的 session 中插入休息/暂停。文件称，系统可进入 rest phase，用来模拟婴儿“taking a break”，而此时 feeding session has not yet ended；rest phase 可以在预定数量的抽吸循环之后或经过预定时间后发生。(谷歌专利)

第三，它已经把数据按 single extraction session / multiple extraction sessions 进行组织：外部设备接收控制器数据、计算泌乳量、跟踪单次 extraction session 以及多次 session 的效率，并记录以前 session、日期和相应奶袋/容器。(谷歌专利)

因此，D1已经非常接近目标逻辑：

latch → pumping session → session中可发生break/rest且session尚未结束 → 按session跟踪数据。

它真正欠缺的只有两个非常窄的表述：

1. 没有明确说“session 被定义为 latch 的开始”；

2. 没有把允许的 rest/pause 上限明确限定为5分钟。

所以我认为 D1应当作为权3区别特征的第一主证据。

三、D2：WO2016014494A1——“latch + session存储 + 5分钟时间阈值”非常有价值

WO2016014494A1，公开日 2016-01-28，优先权 2014-07-22。 (谷歌专利)

这件文件对“存储过程数据”尤其强。它明确公开：

• 系统跟踪奶袋进入系统进行 extraction session、离开系统即 session 结束；

• 可记录奶量、抽取日期和时间、extraction session length；

• milk volume 可以与唯一标识关联并stored；

• 可以计算 average volume per extraction session 等统计数据；

• 数据还能上传至外部计算机或云端。(谷歌专利)

更重要的是，它同属早期 Exploramed 可穿戴乳房泵体系，对 latch vacuum 有明确技术定义，并把 latch 与设备附着、泵乳运行联系起来。

而对“5分钟”，该文献已经明确存在一个同领域 session termination 时间逻辑：

当一组事件满足时，例如 after five minutes if flow is at zero for at least one minute，系统可以自动关闭。(谷歌专利)

这一点不能夸大——它不是“pause≤5分钟仍算同一session”。但它的重要性在于证明：

在同一时期、同一可穿戴乳房泵体系中，技术人员已经在用分钟级阈值、特别是5分钟来判断持续泵乳状态与结束/关闭状态。

所以它特别适合与 D1 的“rest phase 发生但 feeding session 尚未结束”结合。

四、D3：WO2016014488A1——非常接近“pause + latch + 5分钟”

WO2016014488A1，公开日 2016-01-28。 (谷歌专利)

这篇对本次权3也非常有用。

它直接公开 pause periods during which only latch suction is applied to the breast，即在 pause period 中只维持 latch suction。(谷歌专利)

同时，该文件对 pumping session 的大量过程参数进行处理，包括：

• pumping session length；

• session initiated 的时间；

• 当前 session 奶量；

• latch suction pressure；

• rest times；

• pumping session time。(谷歌专利)

更值得注意的是，该文件明确把5分钟列为 pumping session 的一个可选预定时间参数：如果在预期 session 结束时尚未达到目标奶量，可以继续泵送 1、2、5、10 分钟或其他预定时间。(谷歌专利)

因此 D3 单篇已经出现：

latch suction + pause period + pumping session + session 时间数据 + 5分钟这一明确时间值。

但仍应严格区分：其“5分钟”对应的是延长当前 pumping session，并非明确规定“pause≤5分钟不切分session”。

尽管如此，从创造性角度看，它对证明“5分钟仅是一个常规可选时间阈值”非常有利。

五、最精确击中“暂停5分钟仍属于一个session”的文件：US20140228905A1

这是本轮检索中，针对“5分钟暂停 + session不中断 + 保存session数据”命中程度最高的一篇。

US20140228905A1，Obstructive sleep apnea treatment devices, systems and methods，公开日 2014-08-14。 (谷歌专利)

它明确公开：

• therapy 以 session 为单位，有 start 和 stop；

• 用户可以在 therapy session 中执行 pause；

• pause 时间可以编程；

• smart pause 的明确例子是：first pause is five minutes, second pause is ten minutes；

• pause 完成后刺激重新 ramp up，即继续原来的 therapy session；

• summary history data from each session 保存于 device memory；

• 保存的数据明确包括该 session 的 start、pause、stop times。(谷歌专利)

也就是说，它实际上已经直接给出了：

一个被记录/存储的 session → 有明确开始时间 → session 中可以暂停 → 第一暂停5分钟 → 暂停后恢复 → session history记录start/pause/stop。

这与目标权3中“过程能够持续到并经历最多5分钟的暂停”的数据 sessionization 逻辑非常接近。

它唯一缺失的是乳房泵特有的 latch。

因此：

WO2016014469A1 + US20140228905A1 是我认为目前“文字/逻辑命中度最高”的双篇组合。

弱点也很明确：US20140228905A1属于睡眠呼吸暂停神经刺激设备，不是乳房泵，所以无效程序中需要充分论证结合动机，不能简单说“都是医疗设备”就结束。

六、另一件独立的“存储 session + pause时间 + 5分钟”证据：WO2016089751A1

WO2016089751A1，Systems and methods for providing non-invasive neurorehabilitation of a patient，公开日 2016-06-09。 (谷歌专利)

其数据记录内容非常接近目标权3的数据结构。文件明确记录：

• date/time of session start；

• total session time；

• total session pause time；

• session length；

• 上述信息可记录并发送至移动设备。(谷歌专利)

而其实施例又直接说：

患者可以在 therapy session 中休息，例如在30分钟 therapy session 中休息5分钟。(谷歌专利)

而且文件还进一步公开真正的 pause/resume 状态机：按下 pause 后 therapy session 被暂停，停止刺激；随后可 resume，继续同一治疗 session。(谷歌专利)

所以这篇可以非常明确地证明：

“5分钟休息/暂停”并不当然导致 session 结束；5分钟可以包含在一个持续的 session 内，而且系统可以记录 session start 和 session pause time。

从“5分钟是否具有创造性”的角度，这是一件非常好的辅助证据。

七、两个独立乳房泵文件可进一步增强“存储session数据属于常规技术”

WO2014058430A1

公开日2014-04-17。 文件名称直接就是 Breast pump system，其发明主题之一即“controller stores pumping session information”。(谷歌专利)

它公开：

• controller 存储至少一个 pumping session 的信息；

• GUI 中有 session duration clock、session history；

• session history 可包括日期、时间、奶量、吸力、速度和 duration；

• 停止泵后，用户可以resume the session，而不是必须生成新的 session；

• 可以保存10次、20次、50次、100次甚至更多 session。(谷歌专利)

这一点实际上也很有意义：

“暂时停止主动泵送”与“session结束”在2014年的乳房泵中已经不是必然等同关系。

因此它可以作为独立申请人的强辅助文件，避免无效理由完全建立在 Exploramed 自身早期专利上。

WO2013166462A1

公开日2013-11-07。 (谷歌专利)

它公开乳房泵中：

• pumping session；

• usage log；

• milk flow、air flow、vacuum strength；

• pumping sessions 数据用于 daily/monthly log；

• 微处理器记录 pumping session；

• 相关数据存入服务器。(谷歌专利)

同时，它的泵乳程序明确包含periodic pause，pause 可以按照预设间隔、持续预设时间，之后泵乳程序继续运行。(谷歌专利)

这是一件很好的独立乳房泵桥梁文件，可以证明“一个 pumping process/session 中包含预设暂停”本身早已存在。

八、针对权3，我建议的最优无效组合

第一组合：优先推荐——同领域结合最自然

WO2016014469A1 + WO2016014494A1，必要时加入 WO2016014488A1。

逻辑链可以做成：

WO2016014469A1：

latch suction throughout pumping session
＋
pumping session 中存在 rest phase / taking a break
＋
break 时 feeding session “has not yet ended”
＋
按单次和多次 extraction session 跟踪历史数据。(谷歌专利)

WO2016014494A1：

latch/attachment 技术
＋
存储 date/time/session length/volume 等 session data
＋
同一乳房泵体系已经使用 5 分钟作为泵乳停止判断时间参数。(谷歌专利)

WO2016014488A1进一步补强：

pause 中仅保留 latch suction
＋
session/rest time 可由控制器调整
＋
“5分钟”本身已经是 pumping-session 可选择的预定时间参数。(谷歌专利)

这个路线的最大优点是：全部都是乳房泵，且都是2016-01-28公开，比2016-11-12早约9个半月。

其最大争议点仅剩：

为什么本领域技术人员会把已有的“session中允许rest”与“5分钟时间参数”具体设为“≤5分钟则继续视为同一session”。

这已经更像一个数据聚合/session boundary 的参数选择问题，而不像新的乳房泵结构或控制原理。

第二组合：技术特征命中最直接

WO2016014469A1 + US20140228905A1

这是我认为对权3附加特征的文字逻辑最强组合：

• D1：乳房泵 + latch + session + session不中断的break；

• D2：session history存储 + start/pause/stop + 5分钟pause + pause后继续同一session。(谷歌专利)

如果无效请求中需要回答“为什么偏偏是5分钟”，US20140228905A1的价值甚至高于 WO2016014494A1，因为它的5分钟确实就是 pause duration，而不是5分钟后的自动关闭时间。

缺点是跨到神经刺激医疗设备，需要围绕共同技术问题建立结合启示：

如何对可穿戴/便携医疗设备的一次用户操作过程进行 session 化记录，并在短暂用户中断后继续把数据归入原 session，而非错误拆分为两个 session。

第三组合：备用的“5分钟+记录pause”攻击

WO2016014469A1 + WO2016089751A1

后者已经明确公开：

session start time + total session pause time + 5分钟rest仍位于30分钟session内部。(谷歌专利)

比普通“5分钟定时器”证据强得多。

九、逐子特征看，目前证据强度

将目标权3附加特征拆成：

K3-1：存储过程/session数据
这一点已经属于非常强的现有技术。WO2014058430A1、WO2016014494A1、WO2013166462A1等均直接命中。(谷歌专利)

K3-2：过程以 latch 的开始定义
这是当前最难找到逐字公开的部分。WO2016014469A1已经把“形成seal—latch suction—整个 pumping session”紧密联系起来；WO2016014488A1也把 attachment、latch suction、session统一在同一状态机里，但我尚未找到临界日前英文文件明确写成 “session begins when latch is achieved”。(谷歌专利)

K3-3：过程可以经历最多5分钟pause而继续
“session中pause后继续”本身证据很强；“5分钟pause”也已经被 US20140228905A1直接公开；WO2016089751A1甚至直接给出“30分钟session中休息5分钟”。(谷歌专利)

所以真正剩余的创造性焦点并不是“存储”“pause”或“5分钟”本身，而是：

把乳房泵的数据 session 起点选择为 latch，并把5分钟设为区分“暂时中断”和“新session”的切分阈值。

这一点很重要，因为无效理由应当把技术问题准确收窄为session数据归属和会话边界识别，而不要把它描述成“如何实现乳房泵暂停”，否则容易把目标专利包装出不必要的技术高度。

十、当前检索结论

如果只评价你指定的权利要求3新增技术特征，我目前的排序是：

第一梯队：

WO2016014469A1
WO2016014494A1
WO2016014488A1
US20140228905A1

第二梯队：

WO2016089751A1
WO2014058430A1
WO2013166462A1
US20160082166A1

目前不建议声称某一篇文件单独破坏该完整复合特征的新颖性；现有成果更适合做创造性。其中，若追求同领域结合合理性，优先用 WO2016014469A1 + WO2016014494A1/WO2016014488A1；若追求对“5分钟暂停仍属于一个session”的最直接文字证据，则 WO2016014469A1 + US20140228905A1 最强。

此外，这一轮检索后我认为还有一个非常值得继续“定点爆破”的最后目标：2016-11-12以前英文乳房泵/可穿戴医疗设备文件中，明确写出“若两次活动间隔小于5分钟，则归并为同一session；超过5分钟则开始/结束新session”一类 sessionization 规则。 如果能再找到这种文件，权3这个新增特征的无效证据链会明显进一步收紧。

按照你本轮的限定，我重新用日文关键词在 Google Patents 独立检索，并严格执行：

• 公开日 < 2016-11-12；

• 只保留日文公开文本；

• 不把上一轮已经找到的 WO/US 英文文件再反查其 JP 同族作为新证据；

• 优先日本本土申请，其次是独立检出的日文日本公开；

• 对“5分钟”尤其区分：普通5分钟定时 ≠ 5分钟以内中断仍属于同一过程/session。

检索后的结论是：暂未发现一件临界日前日文文件在同一实施方式中完整逐字公开“存储过程数据 + 过程从 latch 开始定义 + 允许经历最多5分钟暂停”全部三项。 但找到了一组相当有价值的独立日文文件，其中 JP2006172408A 对“5分钟过程切分规则”命中非常高，JP2013102867A 则是目前最有价值的同领域乳房泵文件。

一、第一优先级：JP2006172408A——“5分钟仍属于原过程”的直接证据

JP2006172408A，電子表示装置の作業時間管理システム
公开日：2006-06-29；日本本土申请，EYE POWER SPORTS Inc.。(谷歌专利)

这是本轮日文检索中，对权3这一部分：

“过程能够持续到并经历最多5分钟的暂停”

命中最直接的一件。

其逻辑非常清楚：

1. 通过接近传感器/输入装置检测作业开始；

2. 将该时刻作为开始时间存入 memory；

3. 开始后如果暂时没有检测到活动，系统不会立即认定过程结束；

4. 系统开始判断是否已经经过5分钟；

5. 文献明确解释，这5分钟就是为了判断用户究竟是：

   • 暂时离开/中断；

   • 还是已经真正休息并结束该连续作业；

6. 未经过5分钟时，程序返回监视步骤，继续等待用户回来，也就是原过程没有被切断；

7. 经过5分钟后，才将该中断认定为“休憩”，输出结束信号，将该工作过程切分，并记录结束时间；

8. 多组开始时间和结束时间均保存到 memory/记录装置。(谷歌专利)

Google Patents原文尤其关键：

「この５分間は作業者Ｈが作業を中断して休憩したのか…判断する目安」；

以及：

「５分経過していなければ…一時席を離れた作業者が戻るか…観測する」。

也就是说，它公开的技术思想几乎就是：

过程开始 → 存储开始时间 → 暂时中断 → 中断＜5 min仍保持原过程 → 中断达到5 min才结束该过程并记录结束时间 → 后续活动开始新过程。 (谷歌专利)

对权3的贡献

因此这篇的价值不是证明乳房泵结构，而是非常有力地证明：

利用一个5分钟阈值将短暂中断归入原过程、超过阈值才结束并建立新的过程记录，是早在2006年已经公开的数据/session划分技术。

这是我建议正式进入权3主证据池的文件。

二、第一优先级同领域文件：JP2013102867A——乳房密闭/负压 + 存储/过去记录 + 0～5分钟

JP2013102867A，搾乳器およびその機構ユニット
申请人：Pigeon Corp（ピジョン株式会社）
优先权/申请日：2011-11-11
公开日：2013-05-30。(谷歌专利)

这是一篇非常值得保留的日本乳房泵文件，而且不是通过上一轮 Exploramed/Willow 英文文件反查同族得到的。

1. 对“latch”的同领域对应公开很强

它明确公开：

• 搾乳部与使用者乳房接触/当接；

• 乳房与喇叭部接触后形成空间；

• 在该空间中形成负压；

• 乳房与喇叭部密着；

• 进一步明确存在密闭空間，负压升高时凸状刺激部还可以提高乳房与密闭空间之间的密闭性。(谷歌专利)

这与目标专利所谓 latch / latch vacuum 的物理基础高度相近：

乳罩/搾乳部贴合乳房 → 建立密闭空间 → 建立负压 → 保持乳房与乳罩的负压连接状态。

当然，严谨来说，它没有使用“ラッチ”这个词，更没有明确说：

“process begins exactly when latch is achieved”。

因此应表述为latch起点限定的同领域技术基础，不能夸成完整公开。

2. 明确存在存储器和“过去的记录”

其控制部包括用于读写的存储器/SD卡，显示部可以显示：

使用者需要的运行信息、当前运行状态以及过去的记录（過去の記録）。(谷歌专利)

这对于“存储过程数据”是明显贡献。

3. 更重要的是：乳房泵本身已经明确使用0～5分钟的过程时间参数

其搾乳流程设置有：

• 准备模式；

• 随后的搾乳模式。

其中准备模式持续时间明确：

0ないし5分間（0ないし300秒）の間で任意に指定できる

即可以在 0～5分钟之间任意设置。(谷歌专利)

这不能直接等同于目标权3的“pause最多5分钟”——它是准备阶段持续时间而不是暂停持续时间。

但是创造性论证价值不低，因为它直接证明：

在2013年的乳房泵控制系统中，“0～5分钟”本身已经是技术人员可以任意设定的常规泵乳过程时间尺度，并不存在5分钟这一数值本身带来的特殊技术效果。

综合价值

这篇单篇已经包含：

乳房贴合/密闭/负压 + 控制器/存储器/过去记录 + 过程模式 + 0～5分钟时间参数。

因此我把它列为此次日文检索中同领域价值最高的文件。

三、JP2015521927A——乳房泵中“暂停后恢复”，证明暂停≠过程必然结束

JP2015521927A，搾乳器システム及びその使用方法
Philips
公开日：2015-08-03，明确早于2016-11-12。(谷歌专利)

其核心公开非常直接：

当检测到电源输出电压低于第一阈值时：

对乳房泵电动机/执行器的供电一時停止；

电压恢复至第二阈值以上时：

对相同执行器重新再開供电。(谷歌专利)

因此在一个乳房泵运行过程中：

运行 → temporary suspension → 条件恢复 → resume

已经是明确公开的控制方式。

它不具有两个要素：

• 没有5分钟；

• 没有明确说暂停前后存入同一个 session record。

但它对于反驳这样的潜在抗辩非常有用：

“乳房泵一旦暂停，就意味着一次泵乳过程已经结束，因此将暂停前后划为同一过程具有创造性。”

至少从乳房泵运行控制而言，2015年前已经明确知道暂时停止后恢复原运行，不存在“pause必然等于termination”的技术定见。(谷歌专利)

四、JP2014530674A——乳房泵领域的“记录数据”强证据

JP2014530674A，搾乳器による母乳分泌の流量及びパターンを制御するための装置と方法
公开日：2014-11-20。(谷歌专利)

Google Patents分类甚至明确落入：

A61M2205/52 — 带存储器并提供设备或患者变化参数历史的微处理器/计算机。 (谷歌专利)

说明书进一步直接公开：

• 测量乳儿引起的母乳流量及吸吮模式；

• 对这些流量及模式进行測定及び記録；

• 将記録された流量及び乳飲パターン用于控制乳房泵；

• 控制器利用这些记录数据形成相应的真空力及真空模式。(谷歌专利)