The workbench

You confirm the analysis. PatentNode does the drafting.

Everything below is the real product, rendered from a real §103 rejection in the USPTO public corpus. On a run of your own the pipeline stops here and waits, and every field is yours to correct.

Get early access

patentnode.com / workbenchSample · read-only

About this sample

One real public case, with a single example in each panel. Most Office Actions run longer; your own is worked through in full.

PatentNode is working through this OA…

Our own models work on the analysis and the drafting; ★ marks the two points where you review; nothing drafts until you confirm the analysis, and nothing ships until you confirm the drafts.

Step 0 of 8

Reading
Specification
Soundness
Analysis
★ your reviewYou review the analysis
Drafting
★ your reviewYou review the drafts
Report

Sample Office Action

Application 18/823,881 · §103 rejection

Rejection summary, in the examiner's own words

Claims 1-20 are rejected under 35 U.S.C. § 103 as unpatentable over Agarwal in view of Masson. The examiner finds Agarwal teaches the claimed loan-processing/chat-interface features and relies on Masson to supply limitations such as mapping AUS results to system conditions and other lending-system integrations, and concludes it would have been obvious to combine these teachings.

§103Claims affected (first 5 shown):12345

Cited references:

Structured Analysis

Four sections per rejection, structured for partner-level skim-and-correct. In the live workbench every field is editable; drafts begin only after you confirm.

Why this layer: The drafters build directly on your validated Structured Analysis. Catch a missed gap here and every downstream argument and amendment is anchored on it; let a wobble through and the drafts amplify it. The fastest place to apply judgment.

Overall reasoning

Analysis is well-grounded on the examiner's specific cited passages (Agarwal Abstract/Para. 43-59; Masson Para. 16). The dispositive gap, Masson's static strategy list against the claimed dynamic status-responsive task library, is clearly supported by the cited text. The examiner's stated reason for the combination is a generic 'strategy quality' assertion, which does not explain why a person of ordinary skill in the art (POSITA) would restructure Masson's static repository into a dynamic generator.

Claim mapping

Claim 1
using a task library to generate tasks according to the current loan status including AUS findings
Identified gap: No disclosure in Masson of dynamic task generation responsive to AUS findings or current loan status. The static-vs-dynamic distinction is dispositive.
Claim 1
mapping Automated Underwriting System (AUS) results to system conditions
Identified gap: The AUS-to-system-conditions mapping is absent from both references; the examiner provides no cited passage on this point.

Reference mechanism

Masson (US 2023/0186385 A1)

Technical problem: Capturing industry knowledge in pre-developed lending strategies to optimize revenue
Technical means: A repository of automated lending strategies developed and finalized based on historical performance testing and optional manual changes (Masson ¶ 16)
Technical effect: Codifies institutional lending knowledge into reusable strategy modules; reduces strategy-development team load
Difference from the claims: Masson's task library is STATIC: strategies are finalized in advance. It is not a dynamic generator that iteratively updates in response to current loan status or AUS findings. The examiner's mapping of Masson's 'task library' to the claim's dynamic-generation requirement relies on the shared word 'library,' not on structural or functional equivalence.

Amendment risk

Written descriptionLow

ClarityMedium

New matterLow

Care needed on 'task library' vs 'strategy library' terminology: the spec uses 'task library' consistently; the amendment should preserve that term to avoid §112(b) issues. 'Current loan status' should be defined by reference to the spec's enumerated examples (borrower details, AUS findings) to avoid breadth ambiguity.

Did the Examiner cite and reason element by element?

quoted

reasoned

not addressed

Checked against the Examiner's own text; nothing missing.

Is this rejection sound?required

Yours to decide. Below is what this run concluded; adopt it or change it.

SoundPartly soundNot sound

What do you want to do about it?required

Required. This choice decides which documents get produced.

ArgueArgue and amendrecommendedAmendAppealRCEAbandon

Drafted response

Amendment and argument language produced from the validated Structured Analysis above. In the live workbench you edit either side and submit when ready.

Posture choice: Argue + amend paired. Argument hits the dispositive doctrinal gap (Masson static vs claimed dynamic); amendment narrows claim 1 to the limitation Masson can't reach, so the §103 vulnerability is removed even if the argument loses. Use argument-only on the cleanest first responses; amendment-only when you'd rather narrow than litigate. Both = belt and suspenders.

Amendment to claim 1

1. (Currently amended) A method for managing a loan origination process, the method comprising: by a chat manager, in response to receiving a message from a user conversation, extracting borrower details and loan conditions; using a task library to generate tasks according to the current loan status including AUS findings, wherein the task library is dynamically updated based on the current loan status and the AUS findings; and displaying a system-generated response to the user that directs subsequent steps in the loan process, wherein the AUS findings are mapped to system conditions to update the task library.

Rationale

Claim 1 is narrowed to recite (i) dynamic updating of the task library based on the current loan status and AUS findings, and (ii) mapping of AUS results to system conditions. Both limitations are explicitly disclosed in the spec at ¶¶ [0059] (dynamic generation based on real-time user interaction and the stage of a loan application process), [0062] (task library generates tasks based on a loan's current status), [0067] (task library generates further tasks based on the loan status), and [0069] (AUS results used to update system conditions and update the task library). These features are absent from Masson's static strategy list and from Agarwal's form-completion chat manager; the narrowing removes the §103 challenge without introducing new matter.

Traversal of the §103 rejection over Agarwal in view of Masson

Applicant respectfully submits that the rejection of claims 1-5 under 35 U.S.C. § 103 over Agarwal in view of Masson should be withdrawn because the Examiner has not established that the proposed combination teaches or suggests the dynamic task-library limitation that is central to independent claim 1. Claims 2-5 stand or fall with independent claim 1.

The Examiner's combination relies on Masson (¶ 16) to supply the limitation requiring the system to use a task library to generate tasks according to the current loan status. However, the cited passage from Masson describes a static list of pre-defined lending strategies, a repository developed and finalized based on strategy performance and optional manual changes. Masson's 'task library' is not a dynamic generator that iteratively updates in response to current loan status. The Examiner has not identified any passage in Masson disclosing a task library that dynamically generates tasks based on the current loan status, including AUS findings.

Furthermore, the Examiner has not articulated a sufficient motivation for a POSITA to modify Masson's static strategy list into the dynamically updatable task library recited in the claims. The Examiner's stated rationale, that Masson's system 'is unable to capture industry knowledge' and requires 'several teams' to produce a higher-quality strategy, addresses only the general problem of strategy quality and team coordination. It does not explain why a POSITA would have been led to restructure Masson's static strategy repository into a dynamic, status-responsive task generator. The reasoning is conclusory and does not satisfy KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), which requires a specific, articulable reason to combine.

Applicant further notes that the combination, even if accepted, would not yield the claimed invention. Neither Agarwal nor Masson discloses the iterative feedback loop in which AUS findings are mapped to system conditions and used to dynamically update the task library. Accordingly, Applicant respectfully requests withdrawal of the rejection of claims 1-5.

What the workbench shows beside each draft

Already done: all 4 cited paragraphs were found in the specification

A citation we cannot match in the specification is removed before the draft reaches you, so nothing here needs your action. They are listed so you can see what the amendment rests on.

[0059] At step 1004, the virtual assistant may be used to dynamically generate, e.g., based on real-time user interaction with the virtual assistant and the stage of a loan application process, actionable items that are to be displayed on the chat interface to advance the conversation toward the user's goals.
[0062] At step 1106, the chat manager uses a task library to generate tasks based on a loan's current status, e.g., to remain aligned with the user's progress in the loan application process.
[0067] At step 1122, the chat manager uses a task library to generate further tasks based on the loan status.
[0069] [the AUS] responds, at step 1128, with updated AUS results, which the chat manager uses to update the system conditions, at step 1130, and update the task library, at step 1132.

Fix before filing0

Nothing flagged on this draft. When a check does fire, it appears here beside the draft, with the sentence that triggered it and what to do about it.

Analysis report preview

The bilingual analysis report, drafted for you to review and take to your client. Full DOCX rendering happens after submission; this is the executive-summary snippet.

1 ground · claims 1-5 · 2 cited referencesthis sample

18823881_client_report.docx

DOCX

PatentNodeApplication No. 18/823,881

Patent Analysis Report

Response Strategy & Analysis

§103§103 over Agarwal in view of Masson

Executive summary

The §103 rejection rests on Masson's task library supplying the dynamic, status-responsive task-generation limitation of claim 1. Masson paragraph 16 actually discloses a STATIC repository of pre-developed lending strategies, not a dynamic generator. The examiner's mapping relies on the shared word library and reads the claim language back into the reference.

Recommendation

Amend and argue in a paired response. Narrow claim 1 to recite that the task library is dynamically updated from the current loan status including AUS findings, then traverse the §103 on the static-versus-dynamic distinction. Amendment support is explicit in the specification.

Risk caveats

Amendment (new-matter) risk is low: spec paragraphs [0059], [0062], [0067], [0069] support the dynamic-update behavior. §112(b) clarity risk is medium; keep the specification's task library terminology consistent to mitigate.

專利分析報告

答辯策略與分析

§103對 Agarwal 結合 Masson 之 §103 核駁

結論摘要

本件 §103 核駁援引 Masson 提供請求項 1 所述「動態且具狀態回應性之任務生成」。然而 Masson 第 16 段所揭示者實為「靜態策略清單」，即預先建構並依績效調整之策略集合，並非依當前貸款狀態動態生成任務之機制。審查委員之對應僅依賴於與請求項共用之 library 一詞，並將請求項語言反推回引證文獻。

建議回應

採修正與答辯雙軌應對。將請求項 1 限縮至敘明任務庫依當前貸款狀態（含 AUS findings）動態更新，再以「靜態與動態」之區別答辯 §103。修正之書面揭示於說明書中明確可稽。

風險提醒

修正（新增事項）風險低：說明書 ¶¶ [0059]、[0062]、[0067]、[0069] 對動態更新行為提供支持。§112(b) 明確性風險為中等；沿用說明書一致之 task library 用語可降低。

Privileged and confidential · 機密暨特權文件1 / 4

The bilingual report you send your client.

Showing an excerpt of the executive summaryApp. 18/823,881

A live run takes about 15 to 40 minutes of processing end to end (early figure)DOCX · plain text

Ready to run this on your own Office Actions?