Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed on 27 July 2026 have been fully considered but they are not persuasive
In the remarks, Applicant argued in substance that:
(a) Chauhan does not disclose “evaluating one or more factors to determine that the entity is not simultaneously placed in another step of the journey,” arguing that the cited ACCA capacity logic merely prevents an agent from being over-assigned, rather than determining step-placement within a single journey.
(b) Because Chauhan fails to disclose the determination limitation, it necessarily fails to disclose using a state machine to process the event “in response to” that determination.
(c) The rejection improperly combines distinct embodiments of Chauhan (events, workflows, agent routing, and workflow engine) to assemble the claimed method, which is improper for a 35 U.S.C. 102 rejection.
Examiner respectfully traverses Applicant’s remarks:
As to points (a) and (b), Applicant’s argument focuses narrowly on the ACCA capacity routing logic while overlooking the explicit disclosures regarding Chauhan’s Workflow Execution Engine. Under the broadest reasonable interpretation, the claimed “journey” reads on Chauhan’s “Flows/Workflows,” and the “steps” read on Chauhan’s “Blocks.” Chauhan explicitly discloses scenarios where a workflow contains parallel executions or “forks” (Chauhan, paragraphs [0611]-[0612], FIG. 65A/65B). Because an entity/execution can travel down parallel branches, Chauhan’s system must evaluate factors to ensure an incoming event is processed in the correct step and not simultaneously placed or processed in the wrong parallel step of the journey.
Specifically, Chauhan discloses at paragraph [0658] that when an event (webhook callback) is received, the system evaluates a specific factor, a “Token”, to determine exactly which step the execution is parked on. Chauhan explicitly states: “The Token is used to determine the step the Execution is parked on. The system may need a token because, if there are forks and each branch is separately and awaiting a callback, the system otherwise wouldn’t know which on branch to continue the execution” (Chauhan, [0658]). By evaluating this Token, the system determines exactly which step the entity occupies, inherently determining that it is not simultaneously placed in the other parallel branch/step of the journey.
Furthermore, in response to evaluating this Token and determining the correct step, the API passes the context to the flow engine, where a state machine (Temporal-server) is used to “actually run the execution code and persist the state of the flow” (Chauhan, [0623]), thereby “propagat[ing] the execution to the next step” (Chauhan, [0658]). Therefore, Chauhan explicitly discloses evaluating a factor (the Token) to determine step placement among parallel branches, and in response, using a state machine to process the event to a subsequent step.
As to point (c), Applicant’s argument that the rejection improperly combines distinct embodiments is not persuasive. Chauhan does not describe isolated, mutually exclusive embodiments, but rather a single, integrated cloud-based SaaS architecture (Chauhan, FIG. 1, [0088]-[0094]). The workflow definitions, event webhooks, and the Temporal-based execution engine are explicitly described as integrated components of the “Flows service” architecture (see Chauhan, FIG. 73 “Workflow Architecture”; and FIGS. 58-60 showing the end-to-end flow from event trigger, to routing, to interaction creation). Because these components are explicitly disclosed as operating together within the same system architecture to execute a workflow, reading them together does not constitute an improper combination of distinct embodiments under 35 U.S.C. 102. Accordingly, the rejections under 35 U.S.C. 102(a)(1) are maintained.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless -
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Chauhan et al. (US 2023/0351290, hereinafter Chauhan).
Regarding claim 1, Chauhan discloses
A method comprising (fig. 1-81):
detecting an event associated with an entity, the event including a state object (Paragraphs [0179]-[0190], [0200]-[0212], FIG. 42 (interaction states): Interactions/Channels/Participants have lifecycle events and webhooks with payloads carrying state (e.g., InteractionCreateRequest/Response; InteractionStatusUpdate; channel states Active/Inactive/Closed; participant states Joined/Left));
determining that the event is mapped to a journey that comprises a plurality of steps configured by the entity (Paragraphs [0136]-[0138] (Journeys; FIG. 18); [0599]-[0619]: (Workflows/Flows overview): Journeys and developer-configured Workflows/Flows composed of blocks/steps; mapping incoming communications/events into those flows/journeys);
placing the entity in a current step in the journey, the current step matching the state object of the event (Paragraphs [0621]-[0660] (engine/execution context); [0661]-[0684] (Steps tracking/APIs); see also FIG. 66 (wait for incoming webhook): Flow executions maintain execution context and a current step; executions can be “parked” and resumed on incoming webhook/event, aligning step progression with event/state.);
evaluating one or more factors to determine that the entity is not simultaneously placed in another step of the journey (Paragraphs [0112]-[0117] (Users: Capacity/Activity/Capability/Skills); [0240]-[0249] (Invites and capacity); [0299]-[0319] (Queues/membership): Orchestrator/Router evaluate ACCA predicates (Availability/Capacity/Capability/Activity), skills, queue membership; invite/reservation semantics (reserve → accept commits; reject/timeout/rescind releases) gate assignment to avoid double-booking capacity-bearing entities; Note: As further detailed in Chauhan’s workflow execution engine, the system evaluates factors to ensure an entity/execution is not simultaneously placed or processed in the wrong step, particularly during parallel branches. See Paragraph [0658]: “The Token is used to determine the step the Execution is parked on. The system may need a token because, if there are forks and each branch is separately and awaiting a callback, the system otherwise wouldn’t know which on branch to continue the execution.” By evaluating this factor (the Token), the system determines exactly which step the entity occupies, inherently determining it is not simultaneously placed in another parallel step of the journey); and
in response to the determining that the entity is not simultaneously placed in another step of the journey (Paragraphs [0112]-[0117] (Users: Capacity/Activity/Capability/Skills); [0240]-[0249] (Invites and capacity); [0299]-[0319] (Queues/membership): Orchestrator/Router evaluate ACCA predicates (Availability/Capacity/Capability/Activity), skills, queue membership; invite/reservation semantics (reserve to accept commits; reject/timeout/rescind releases) gate assignment to avoid double-booking capacity-bearing entities.), using a state machine to process the event based on an operation associated with a step subsequent to the current step in the journey (Paragraphs [0403]-[0416]; [0621]-[0684]; see FIG. 73 (workflow architecture) and FIGs. 38-41 (orchestration examples): State-machine-like workflow engine (Temporal-based) processes events and advances execution to subsequent blocks/steps; orchestrations show stepwise progression on events (accept invite, inbound handling, close channel, etc.); Note: As further detailed in Paragraphs [0623] and [0658], in response to evaluating the token/factors to determine the correct step, the API passes the context to the flow engine, where a state machine (Temporal-server) is used to “actually run the execution code and persist the state of the flow” ([0623]), which “propagates the execution to the next step” ([0658]) based on the incoming event).
Regarding claim 11 referring to claim 1, Chauhan discloses A system comprising:
one or more hardware processors; and a non-transitory machine-readable medium for storing instructions that, when executed by the one or more hardware processors, cause the one or more hardware processors to perform operations comprising: … (FIG. 1-81).
Regarding claim 20 referring to claim 1, Chauhan discloses A non-transitory machine-readable medium for storing instructions that, when executed by one or more hardware processors, cause the one or more hardware processors to perform operations comprising:: … (FIG. 1-81).
Regarding claims 2 and 12, Chauhan discloses
wherein the entity is associated with a profile, comprising: updating the profile based on the processing of the event (Paragraphs [0122]-[0131], [0619]-[0620]: Customer profile lookup/update as part of workflow orchestration (profile retrieval and update in flow examples and orchestration sequences).).
Regarding claims 3 and 13, Chauhan discloses
the determining that the event is mapped to the journey comprises: mapping the event to the journey based on content of the event, the mapping of the event including determining that the content of the event satisfies a definition of the journey; and identifying the state machine associated with the journey (Paragraphs [0179]-[0190], [0599]-[0619], [0621]-[0660]: Event payloads used to select workflows/journeys, and identifies/uses a workflow engine (state-machine/Temporal) associated with the chosen workflow.).
Regarding claims 4 and 14, Chauhan discloses
wherein the event is a first event, and wherein the entity is a first entity, comprising: detecting a second event associated with a second entity; determining that the event does not map to any journey associated with the second entity; and discarding the event (Paragraphs [0179]-[0190], [0240]-[0259]: Event reception and handling of unmatched/failed offers (invite failures, timeouts, declines) and discarding/timeout semantics for unmatched requests.).
Regarding claims 5 and 15, Chauhan discloses
wherein the one or more factors correspond to one or more of evaluation of memberships, setting of evaluation windows, setting of priorities, existing entities, moving of profiles, and support analytics (Paragraphs [0112]-[0117], [0299]-[0319], [0540]-0546): ACCA predicates (Capacity/Activity/Capability/Skills), queue membership and routing parameters (priority/TTL), and reporting/analytics used in routing/evaluation decisions.).
Regarding claims 6 and 16, Chauhan discloses
wherein each step in the journey is associated with metadata that is used to reference another step within the journey or a step in another journey (Paragraphs [0619]-[0660], [0675]-[0684]: Compound/core block model and block identifiers/metadata (nested block context and step/block IDs) enable referencing/linking between steps and blocks.).
Regarding claims 7 and 17, Chauhan discloses
comprising: identifying an attribute of the event; and storing the attribute of the event in the journey (Paragraphs [0191]-[0197], [0675]-[0684]: Interaction Attributes APIs and flow execution context persist event attributes in the execution/IDR context).
Regarding claims 8 and 18, Chauhan discloses
wherein the attribute of the event comprises contextual data that includes one or more of a journey identifier, a step identifier, and timestamp data (Paragraphs [0675]-[0684], [0141]-[0148]: Execution context/IDR and segment model capture identifiers (interaction/journey/step IDs) and timestamps as stored contextual data.).
Regarding claims 9 and 19, Chauhan discloses
wherein the journey comprises one or more steps sequentially arranged in a logical order, the journey allowing a user to trigger an operation associated with a step of the journey once an operation associated with a previous step of the journey has been triggered (Paragraphs [0621]-[0660], [0675]-[0684]: Flow engine and step execution model support ordered, sequential steps; engine parks/waits for events and resumes to enforce ordered advancement.).
Regarding claim 10, Chauhan discloses
wherein the event corresponds to a system-generated event or a user-triggered event (Paragraphs [0179]-[0190], [0240]-[0249], [0403]-[0416]: both system/webhook-originated events and user-triggered actions (accept/reject invites, UI actions) as inputs to orchestrations/workflows.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s Shah et al. (US 11,818,115 B1) discloses “Receiving input via the one or more selectable/input areas may in turn cause the user device to initiate the one or more multi-step workflow journeys, for example, by generating and transmitting a signal or instruction to the platform 200. In some embodiments, the one or more workflow journeys may be initiated by launching one or more software applications that (among other things) provides links to available workflow journeys and/or enables any number of users to initiate any number workflow journeys simultaneously” (col. 18, lines 45-55).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y. Blair can be reached on (571)270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 9/4/2026
Prosecution Insights