专利驳回理由撰写

审查意见（驳回理由）

一、案件与技术领域概述
本申请涉及一种用于实验室溶剂分配的手持式喷雾器，属于手动加压喷雾/分配装置技术领域。权利要求书的核心方案为：在具备壳体、储液腔、弹簧复位按压泵、喷口及单向阀的手持喷雾器中，于喷口与储液腔之间设置可拆换限流件，并通过外部旋钮微调按压泵行程，以控制喷雾粒径与流量；从属权利要求进一步限定限流件为带微孔的聚合物片、卡扣式安装，以及单向阀位于喷口前端。

二、权利要求的技术方案概述
1. 权利要求1：手持喷雾器，包括壳体、储液腔、弹簧复位按压泵、喷口与单向阀；特征在于：喷口与储液腔之间设置可拆换限流件；按压泵行程可通过外部旋钮微调，以控制喷雾粒径与流量。
2. 权利要求2：根据权利要求1，所述限流件为带微孔的聚合物片，采用卡扣式安装。
3. 权利要求3：根据权利要求1或2，所述单向阀位于喷口前端以防回流。

三、现有技术状况与对比
根据本局对本领域常规技术的调查与公知常识（参见《专利审查指南》关于以公知常识作为审查依据的原则），手持式喷雾/分配装置长期以来广泛采用以下成熟结构与手段：
- 在喷嘴/喷头内部设置或可更换的限流孔板、节流片或节流塞（通常为聚合物或金属件，带有微孔或小孔径），用于调节流量与喷雾状态，且常见以卡扣、压入或螺接方式装配，便于维护或更换以适配不同流体。
- 在按压式手动泵中通过外部限位机构（如带刻度的旋钮、螺纹限位套或微调螺钉）调节活塞有效行程，从而线性或近似线性地改变每次行程的排液量；该思路广泛见于定量分配泵、手持计量分配器及部分喷雾头结构。
- 在喷口侧设置单向阀或防滴/止回结构以防回流与滴漏，提高喷雾响应性并避免污染或溶剂回渗，该布置属于喷雾头常规方案，位置上通常靠近喷口以减少死腔与滞留。

上述技术手段作为独立的通用部件与设计选项，在手持喷雾器及相近的分配器产品中属于本领域技术人员熟知并能够互换选用的成熟方案。

四、创造性（专利法第22条第3款）评价
（一）最接近现有技术的确定
最接近现有技术可确定为一种常规的手持式按压泵喷雾器，包含壳体、储液腔、弹簧复位的按压泵、喷口与单向阀，且在喷嘴通道内设置限流/节流孔板或小孔结构以调节流量和喷雾形态；该类装置在喷口附近配置止回结构以防止回流与滴漏，属于本领域普遍采用的成熟技术。

（二）区别特征与客观技术问题
与上述最接近现有技术相比，权利要求1的区别特征在于：
1. 将限流件明确限定为“可拆换”的部件，布置在喷口与储液腔之间；
2. 通过“外部旋钮”微调按压泵行程，以控制喷雾粒径与流量。

据此可归纳的客观技术问题为：在通用手持喷雾器的基础上，提供一种便于通过更换或微调手段对喷雾粒径与流量进行适配和调节的方案，以应对不同流体/工况需求并便于维护。

（三）是否显而易见
- 关于区别特征1（可拆换限流件）：在手持喷雾头及相关分配器中，采用可替换的孔板/限流片以适配不同粘度、目标流量和雾化状态属于常见设计选择。将限流件设置于喷口与储液腔之间是节流元件的常规布置位置，便于加工装配与清洁维护。该特征并未体现出超出常规的结构或功能协同，仅是将公知的节流件以可更换方式实施，属对现有技术的顺势选择，预期可获得对应的可维护性与适配性效果，技术效果可预见。
- 关于区别特征2（外部旋钮微调按压泵行程）：通过外部限位旋钮或螺纹微调件改变泵的行程以调节单次排液量，是手动定量泵和分配器的通用调节思路。将该思路用于手持喷雾器，以改变流量并间接影响雾化粒径，属于相邻领域的直接类推与简单替换，且技术效果可预期（行程减小→排量下降→在固定喷嘴/孔板条件下喷雾粒径与流量可被调低或改变）。该特征并未产生出乎预料的技术效果或功能耦合，也未解决本领域长期存在且未被克服的技术偏见。

- 组合动机与可预见性：为实现“控制喷雾粒径与流量”的目标，将“可拆换限流件”（实现离散/规格化的节流调节）与“外部旋钮行程微调”（实现连续/精细的排量调节）组合，以获得多级/精准调节能力，符合本领域在产品可维护性与可调性方面的常规设计动机。两者在功能上属于并列叠加，未形成彼此依存或相互作用的非线性意外效果。依据《专利审查指南》关于创造性评判的“三步法”，该组合对本领域技术人员而言系显而易见。

综上，权利要求1相对于上述最接近现有技术的组合，未体现出显著的实质性特点和显著进步，不符合《中华人民共和国专利法》第22条第3款关于创造性的规定。

五、从属权利要求的评价
- 权利要求2将限流件具体限定为“带微孔的聚合物片，卡扣式安装”。微孔孔板采用聚合物材料（如POM、PEEK、PP等）并以卡扣式安装，属于喷雾/分配器结构中的常见实施方式，兼顾成本与耐化学性；该限定仅属对常规材料与常规装配方式的选择和应用，未产生超出现有技术预期的效果，不具备克服权利要求1缺乏创造性的能力，亦不独立具备创造性。
- 权利要求3将单向阀位置限定为“喷口前端以防回流”。将止回阀/防滴结构尽可能靠近喷口设置以降低死腔、抑制滴漏与回流，为本领域的惯常布置手段。该附加限定属于显而易见的优化，不具备创造性。

因此，权利要求2-3均因从属于不具创造性的权利要求1而不具创造性，且即便单独评价亦属本领域常规选择，均不符合专利法第22条第3款的规定。

六、权利要求书的清楚性问题（专利法第26条第4款）
经审查，权利要求存在下述不清楚或以效果限定为主的问题：
1. 权利要求1以“以控制喷雾粒径与流量”限定技术效果，但未在权利要求中明确与该效果直接对应的结构参数或操作条件（如限流件微孔的孔径/孔密度范围、行程微调机构的结构特征与调节量程、配合的喷嘴结构等），该等效果性表述可能导致保护范围不明确。
2. “微调”“前端”等用语缺乏客观限定基准，“微调”的精度/步距或结构实现方式未限定，“喷口前端”的空间范围不清晰，易造成理解歧义。
上述问题不符合专利法第26条第4款关于“权利要求应当清楚、简要地限定要求保护的范围”的要求。

七、结论与处理意见
- 结论：权利要求1-3相对于本领域公知常识及常规结构的合理组合，系本领域技术人员容易想到的设计，未能体现出创造性，不符合《中华人民共和国专利法》第22条第3款的规定；同时，权利要求书存在不清楚之处，不符合第26条第4款的规定。
- 处理意见：本申请现阶段不予授权。申请人如欲继续推进，应对权利要求进行实质性修改，至少包括：
  1) 就“可拆换限流件”与“行程微调机构”给出区别于常规孔板/行程限位结构的具体结构限定和参数范围，并能够与实现的技术效果建立可验证的对应关系；
  2) 明确行程微调机构的构造（例如：螺纹传动机构类型、导向/限位方式、最小可调步距、调节范围）及与喷嘴/限流件协同的流体通道特定布局，证明存在非显而易见的协同效应或意外技术效果（如在特定孔径与行程耦合条件下实现粒径分布显著收窄或滴漏显著降低，并非常规组合可达到）；
  3) 对“微调”“前端”等用语作出结构化限定或以可测定义代替效果性表述，确保权利要求清楚。

如未能在规定期限内提交使权利要求具备创造性且清楚的修改文本，本申请将被驳回。上述意见系依据专利法第22条、第26条及相关审查指南对创造性与清楚性之要求作出。

Office Action – Rejection of Claims 1–3

I. Summary of the Claimed Subject Matter
The application is directed to a method for invoice authenticity verification that: (i) acquires invoice data; (ii) computes a hash over “key fields”; (iii) records the hash as a transaction on a consortium (permissioned) blockchain; and (iv) later queries the chain to obtain the stored hash, compares it with a newly computed hash of the current invoice, and outputs a verification result. Claim 2 specifies that the blockchain is a permissioned multi-node chain. Claim 3 adds pushing the verification result to an enterprise financial system.

II. Rejection under 35 U.S.C. § 101 (Patent-Ineligible Subject Matter)
Claims 1–3 are rejected under 35 U.S.C. § 101 as being directed to patent-ineligible subject matter.

A. Step 2A, Prong One (2019 Revised Guidance): The claims are directed to an abstract idea.
- The claims are directed to verifying the authenticity of business records (invoices) by computing a hash, recording it, and later comparing and reporting a result. Such activities constitute (1) methods of organizing human activity in the realm of commercial interactions and fundamental business practices, and (2) mental-process-like data analysis and comparison implemented on generic computer technology. See Alice Corp. v. CLS Bank, 573 U.S. 208, 219–20 (2014) (intermediated settlement as a fundamental economic practice); Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1353–56 (Fed. Cir. 2016) (collecting, analyzing, and displaying information is abstract); SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161, 1167–70 (Fed. Cir. 2018) (data analysis and reporting are abstract).
- The recited steps—receiving invoice data, hashing, writing/reading from a ledger, comparing, and outputting a result—are paradigmatic data processing operations that fall squarely within the abstract idea categories identified above.

B. Step 2A, Prong Two: The claims do not integrate the abstract idea into a practical application.
- The claims recite use of a generic “consortium/permissioned blockchain” as a storage and retrieval substrate and generic hashing. There is no recitation of any specific improvement to computer functionality, distributed systems, or blockchain technology (e.g., no new consensus mechanism, ledger data structure, network protocol, or resource management technique). See Alice, 573 U.S. at 223–26; Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335–36 (Fed. Cir. 2016) (patent-eligible when the claims improve the functioning of the computer itself; not present here).
- Pushing the result to an enterprise financial system is mere post-solution activity and does not meaningfully limit or transform the abstract idea. See, e.g., Electric Power Group, 830 F.3d at 1354–55 (presentation of results is insufficient).

C. Step 2B (Inventive Concept): The claims do not recite an “inventive concept.”
- Each recited operation—hashing data, storing a digest on a blockchain, retrieving and comparing digests, and notifying another system—was well-understood, routine, and conventional at the relevant time. Evidence includes:
  - NIST SP 800-107 Rev. 1, Recommendation for Using Approved Hash Algorithms (2012) (use of standard cryptographic hash functions).
  - Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (2008) (hash-based transactions, Merkle trees, and immutable ledger for recording data).
  - Peter Todd, OpenTimestamps (2016) (anchoring document digests on a blockchain to later verify integrity by recomputing and comparing the digest).
  - Christian Cachin, Architecture of the Hyperledger Blockchain Fabric (2016) (permissioned, multi-node blockchain infrastructure).
- Merely applying an abstract verification workflow to invoices and implementing it on a conventional permissioned blockchain does not supply an inventive concept. See BSG Tech LLC v. BuySeasons, Inc., 899 F.3d 1281, 1290–91 (Fed. Cir. 2018) (limiting the abstract idea to a particular context and invoking conventional components is insufficient); Solutran, Inc. v. Elavon, Inc., 931 F.3d 1161, 1167–68 (Fed. Cir. 2019) (reciting conventional steps of check verification using scanning and electronic processing is abstract and lacks an inventive concept).
- Under Berkheimer v. HP, 881 F.3d 1360, 1369 (Fed. Cir. 2018), this Office Action provides documentary evidence that the hashing, blockchain recording/verification, and permissioned ledgers were conventional, and the claims add no unconventional arrangement or improvement to computer technology.

Accordingly, claims 1–3 are ineligible under § 101.

III. Rejection under 35 U.S.C. § 103(a) (Obviousness)
Claims 1–3 are rejected under 35 U.S.C. § 103(a) as obvious over Todd (OpenTimestamps, 2016) in view of Cachin (Hyperledger Fabric, 2016), and in further view of the knowledge of a person of ordinary skill in the art (POSITA) as evidenced by NIST SP 800-107 Rev. 1 (2012) and routine enterprise-system integration practices.

A. References
- Todd, Peter. OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin (2016) (publicly describes computing a cryptographic digest of arbitrary data, committing/anchoring that digest into a blockchain transaction/Merkle tree, and later verifying data integrity by recomputing and comparing digests).
- Cachin, Christian. Architecture of the Hyperledger Blockchain Fabric, arXiv:1607.07449 (2016) (describes a permissioned, multi-node consortium blockchain platform for enterprise use).
- NIST SP 800-107 Rev. 1 (2012) (establishes the conventional nature of cryptographic hashing in integrity-checking workflows).

B. Claim 1
- “Obtaining invoice data”: Todd discloses obtaining arbitrary digital data to be timestamped/verified by hashing and anchoring on a blockchain. The identification of the data as “invoice” data is an intended use and does not distinguish the structural/functional steps of the method.
- “Computing a hash over key fields”: Todd teaches computing a cryptographic digest of the data to be verified. It would have been obvious to a POSITA to compute the digest over a subset of “key fields” rather than the entire file to accommodate benign changes (e.g., layout or non-substantive metadata) and/or to reduce computation and improve robustness—a predictable, routine design choice that yields no unexpected results. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007) (predictable variation); MPEP 2144.04(IV) (design choice).
- “Writing the hash as a transaction to a blockchain”: Todd expressly teaches anchoring the digest onto a blockchain via transactions and Merkle roots.
- “Querying the chain for the stored hash, comparing with the current hash, and outputting a verification result”: Todd teaches later verification by retrieving the committed digest (or Merkle inclusion proof) and comparing it to a recomputed digest to confirm authenticity; outputting a verification status is inherent to the verification workflow and is, in any event, an obvious reporting step. Electric Power Group, 830 F.3d at 1354–55.

Accordingly, claim 1 would have been obvious over Todd in view of ordinary design choice and common cryptographic practice (NIST SP 800-107).

C. Claim 2
- “The consortium chain is a permissioned multi-node chain”: Cachin (2016) teaches Hyperledger Fabric, a permissioned multi-node blockchain designed for enterprise/consortium deployments. It would have been obvious to a POSITA to implement Todd’s document-integrity anchoring and verification workflow on a permissioned blockchain in enterprise invoice contexts to meet privacy, governance, and performance requirements, a substitution of one known ledger substrate for another with predictable results. KSR, 550 U.S. at 416; MPEP 2143(I)(B).

Thus, claim 2 would have been obvious over Todd in view of Cachin.

D. Claim 3
- “Pushing the verification result to an enterprise financial system”: It would have been obvious to a POSITA to automatically provide the verification result to an enterprise finance/ERP system to trigger downstream accounting workflows, given the widespread, conventional use of APIs, message queues, and webhooks for system-to-system integration in enterprise environments at the time. This constitutes routine post-processing/notification. See KSR, 550 U.S. at 417–22 (common sense and market forces); Electric Power Group, 830 F.3d at 1354–55 (displaying/communicating results is ancillary). Official notice is taken that enterprise financial systems conventionally accept programmatic inputs via APIs for automated processing; if traversed, the Examiner will provide documentary support. See MPEP 2144.03.

Accordingly, claim 3 would have been obvious over Todd and Cachin in view of the general knowledge of a POSITA.

IV. Additional Notes on Claim Clarity
While not the basis of this rejection, the term “key fields” in claim 1 appears to be a term of degree that may render the scope uncertain unless supported by objective boundaries in the specification. See 35 U.S.C. § 112(b); MPEP 2173.05(b). Applicant is invited to clarify or provide explicit criteria for “key fields.”

V. Conclusion
- Claims 1–3 are rejected under 35 U.S.C. § 101 as directed to patent-ineligible subject matter without an inventive concept.
- Claims 1–3 are rejected under 35 U.S.C. § 103(a) as obvious over Todd (2016) in view of Cachin (2016), and further in view of the knowledge of a POSITA as evidenced by NIST SP 800-107 Rev. 1 and routine enterprise-integration practices.

Applicant may overcome the § 101 rejection by amending the claims to recite a specific, technical improvement to blockchain or distributed computing (e.g., a new consensus, data structure, or protocol that improves the functioning of the ledger itself) rather than claiming the abstract business verification workflow. To address the § 103 rejection, Applicant must amend to include non-obvious, specific technical features not taught or suggested by the cited art (e.g., a particular on-chain/off-chain protocol with defined message formats and security properties that yield an unexpected technical advantage, or a specialized hashing scheme tied to a novel ledger data structure). If Applicant traverses the taking of official notice as to claim 3, the Examiner will supply documentary evidence in a subsequent action.

驳回理由

一、申请概述
本申请涉及一种通过表面预处理与水性底涂相结合以提高铝合金基材上水性涂层附着力的方法。权利要求1限定：去油与微蚀；在常压下进行低温等离子体处理30–120 s；喷涂含羧基丙烯酸乳液的水性底涂并在80°C烘干。权利要求2进一步限定等离子体为氧/氩混合气。权利要求3限定底涂固含量为15–25%。

二、最接近现有技术与客观技术问题
- 就表面处理与水性底涂体系而言，针对铝及铝合金基材，为提高附着力，业内已普遍采用如下顺序的处理流程：脱脂/去油→化学微蚀/活化→常压低温等离子体（或电晕/火焰）表面活化→喷涂含羧基或其他极性基团的丙烯酸乳液底涂→低温烘干（约60–100°C）。上述流程及其目的（去除有机污染、去除致密氧化膜、引入极性官能团、提高表面能与涂料润湿性）属于本领域公知常识。
- 常压低温等离子体以氧、氩或其混合气体为放电气氛进行表面活化以提高金属表面与水性涂层的附着力亦为本领域的常规技术选择；其中氧/氩混合可稳定放电并兼具清洗与活化作用，处理时间在数十秒到数分钟的常规窗口内调节以获得期望的表面能。
- 水性丙烯酸乳液含羧基以增强与金属氧化层的氢键/配位作用，喷涂施工的固含量在约10–30%范围内选取以平衡流动性与成膜性，低温（约80°C）烘干以促进水分挥发与乳液成膜，均为常规工艺参数。

据此，客观技术问题至多应界定为：提供一种用于铝合金基材的替代性或常规的水性涂层表面处理方案，而非实现出乎意料的附着力提升。

三、对权利要求1的创造性评价（专利法第二十二条第三款）
1. 与最接近现有技术的一致之处
- 对铝合金进行去油与微蚀；
- 采用常压低温等离子体进行表面活化；
- 施涂含羧基的丙烯酸乳液型水性底涂；
- 低温烘干（约80°C属于常规烘干温区）。

2. 区别特征与技术效果
- 区别仅体现在对等离子体处理时间的限定为30–120 s，以及对底涂类型的表述为“含羧基丙烯酸乳液”、烘干温度“80°C”的具体列举。
- 前述时间窗口、涂料类别与烘干温度均落入本领域常规选择与常规优化范畴，未体现出相对于最接近现有技术的出乎意料的技术效果。申请文本未显示在所述宽泛时间范围内（30–120 s）或在80°C烘干条件下，相对于邻近常规条件存在非线性提升或协同效果。

3. 合理动机与技术启示
- 本领域技术人员面对提高水性涂层附着力的常规任务，会出于提高表面能、清除弱边界层与促进极性相互作用的动机，顺序地采用去油/微蚀→常压等离子体→水性丙烯酸底涂→低温烘干的流程。选择氧/氩为工作气体、将处理时间控制在几十至一百余秒、将乳液固含控制在适宜喷涂的中等范围并在80°C左右烘干，均属于无需创造性劳动的工艺设定。
- 在缺乏比较数据证明“指定的处理时长+指定的底涂+指定的烘干温度”的特定组合作用产生超出各自常规贡献之协同效应的情况下，上述参数限定不足以支撑创造性。

综上，权利要求1相对于现有技术不具备创造性，不符合专利法第二十二条第三款规定。

四、对权利要求2–3的创造性评价（从属项不具备独立的创造性贡献）
- 权利要求2限定“等离子体为氧/氩混合气”。氧/氩混合为常压等离子体处理中应用最为广泛的气氛之一，选择该混合气以兼顾放电稳定性与表面活化能力属常规设计，未产生出乎意料的技术效果，不具创造性。
- 权利要求3限定“底涂固含量为15–25%”。该固含区间落入喷涂法涂装工艺常用的中等固含范围，系常规的施工性与成膜性平衡选择，未见非常规效果，不具创造性。

据此，权利要求2–3亦不符合专利法第二十二条第三款的规定。

五、权利要求清楚性与支持问题（专利法第二十六条第四款）
- 权利要求以“提高附着力”为目的，但未包含实现该目的所必需的关键技术特征，具体包括：微蚀工艺（药液体系、温度、时间或目标蚀除量）、等离子体工艺参数（功率或功率密度、频率、气体流量、喷嘴至基材距离、扫描速度/次数、混合气比例）、烘干时间、底涂关键组成参数（酸值、中和度、玻璃化温度、粒径等）。上述要素对等离子体改性程度、底涂润湿/成膜行为及最终附着力结果具有决定性影响。
- 在未将上述必要技术特征纳入权利要求的情况下，权利要求的技术方案难以保证在其全范围内实现所述“提高附着力”的技术效果，构成权利要求未以清楚、简要的用语限定解决技术问题所必需的技术特征，且其范围超出说明书记载的可实现范围的风险。该问题违反专利法第二十六条第四款关于“权利要求应当以说明书为依据，并且清楚、简要地限定要求保护的范围”的规定。

六、结论
- 权利要求1–3相对于现有技术不具备创造性，不符合专利法第二十二条第三款的规定。
- 同时，权利要求未包含实现既定技术效果所必需的关键技术特征，存在不清楚且缺乏说明书支持的问题，不符合专利法第二十六条第四款的规定。

鉴于上述原因，本申请不予授予专利权。申请人如拟克服上述缺陷，应当对权利要求进行实质性限定，并提供能够证明出乎意料技术效果的对比实验数据；否则，创造性缺陷与第二十六条第四款问题难以消除。