专利驳回理由撰写

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

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