DETAILED ACTION
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 . Claims 1-24 are pending.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Such limitations are seen in claim 1:
a change-request engine configured to create, for an editing user, a draft procedure-flow graph as an editable copy of the live procedure-flow graph and to associate the draft with a baseline identifier of the live procedure-flow graph, the draft procedure-flow graph comprising a plurality of graph nodes and a plurality of graph edges.
Corresponding structure can be found in pages 7-8 of applicant’s specification as filed.
a graph engine configured to…
Corresponding structure can be found in pages 7-11 of applicant’s specification as filed.
a conflict-resolution engine configured to, upon detection of a conflict…
Corresponding structure can be found in pages 7-8 of applicant’s specification as filed.
an approval module configured to publish an approved draft by replacing the live procedure-flow graph in the repository and to flag other drafts associated with a prior baseline identifier as out-of-date.
Corresponding structure can be found in pages 7-8 of applicant’s specification as filed.
Claim Rejections - 35 USC § 101
Claims 1-24 are rejected under 35 USC § 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03.
Per Step 1, claim 1 is directed to a system (i.e., a machine), and claim 17 is directed to a method (i.e., a process) Thus, the claims are directed to statutory categories of invention. However, the claims are rejected under 35 USC § 101 because they are directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The analysis proceeds to Step 2A Prong One.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04.
The abstract idea from claim 1 is:
storing a live procedure-flow graph comprising nodes and directed edges, each node representing a step in a procedure and each edge representing a navigation link between steps;
(a) create, for an editing user, a draft procedure-flow graph as an editable copy of the live procedure-flow graph and to associate the draft with a baseline identifier of the live procedure-flow graph, the draft procedure-flow graph comprising a plurality of graph nodes and a plurality of graph edges;
(i) compute differences between the draft procedure-flow graph and the live procedure-flow graph;
(ii) detect a baseline mismatch when a baseline identifier of the draft procedure-flow graph differs from a current identifier of the live procedure- flow graph;
(iii) in response to the baseline mismatch, perform a rebase operation that:
- aligns the graph nodes and the graph edges of the draft procedure-flow graph to corresponding graph nodes and graph edges of the current live procedure-flow graph; and
merges non-conflicting edits from the draft while retaining those edits in the rebased draft;
(iv) detect conflicts under predetermined conflict rules including at least one of: concurrent edits to a same node attribute, deletion of a node or edge in one graph while modified in the other, and reassignment of an edge endpoint altered by both graphs;
(c) upon detection of a conflict:
(i) present a side-by-side visualization of the current live procedure- flow graph and the conflicting draft procedure-flow graph with highlighted differences;
(ii) enable flow-scoped discard that discards edits to a portion of the draft without discarding other edits to one or more other portions; and (iii) enable a placeholder-copy workflow that:
- copies local conflicting edits into a temporary placeholder graph,
- discards the conflicting portion of the graph, and
- reapplies the discarded edits from the placeholder graph onto a corresponding subgraph of the current live procedure-flow graph;
(d) publish an approved draft by replacing the live procedure-flow graph and to flag other drafts associated with a prior baseline identifier as out-of-date; and
(i) render, for an editing user, a side-by-side view of the live procedure-flow graph and the draft procedure-flow graph with visual highlighting of graph-node-level and graph-edge-level edits; and
(ii) receive user inputs to initiate the rebase operation, resolve conflicts using the flow-scoped discard and placeholder-copy workflows, and submit the draft for approval.
The abstract idea from claim 17 is:
storing a live procedure-flow graph comprising graph nodes and graph edges;
creating, for an editing user, a draft procedure-flow graph as a copy of the live procedure-flow graph and associating the draft with a baseline identifier of the live procedure-flow graph;
rendering a side-by-side view of the live procedure-flow graph and the draft procedure-flow graph with highlighted edits;
detecting that the baseline identifier of the draft does not match a current identifier of the live procedure-flow graph;
in response, performing a rebase operation comprising aligning corresponding graph nodes and corresponding graph edges of the draft procedure-flow graph to the graph nodes and the graph edges of the current live procedure-flow graph and merging non-conflicting edits from the draft into a rebased draft while retaining the edits;
detecting conflicts based on predetermined conflict rules including at least concurrent modification of a same node attribute and deletion-versus-modification of a same graph node or a same graph edge;
presenting a conflict-resolution including:
(i) flow-scoped discard of edits; and
(ii) a placeholder-copy workflow that copies local edits into a temporary placeholder, discards a conflicting portion of the draft procedure-flow graph, initializes a subgraph from the current live procedure-flow graph, and reapplies the local edits from the placeholder thereto; and
publishing, upon approval, the draft procedure-flow graph as the live procedure-flow graph and flagging other drafts with mismatched baselines as out-of-date.
The abstract idea above constitutes a process that, under its broadest reasonable interpretation (BRI), covers managing personal behavior relationships, interactions between people. That is, organizing collaborative editing among editing users and approvers through draft creation, conflict handling, approval, publication, and management of out-of-date drafts. This is further supported by paragraph [0039] of applicant’s specification as filed. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitations of social activities, teaching, following rules or instructions, then it falls within the Certain Methods of Organizing Human Activity – Managing Personal Behavior Relationships, Interactions Between People grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Additionally and alternatively, the abstract idea steps italicized above are those which cover managing collaborative modifications to procedure information, including comparing versions, identifying conflicting changes, resolving the changes, and obtaining approval for publication. This is further supported by paragraph [0029] of applicant’s specification as filed. This constitutes a process that, under its broadest reasonable interpretation (BRI), covers performance of the limitation in the mind, including observations, evaluations, judgements, and/or opinions, therefore, it falls within the Mental Processes – Concepts Performed in the Human Mind grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP §2106.04.
This judicial exception is not integrated into a practical application because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP §2106.05(f).
Claim 1 recites the following additional elements: A collaborative procedure-flow editing system comprising: a repository; a server comprising a processor and memory storing instructions that, when executed, implement; change-request engine; graph engine; conflict-resolution engine; approval module; one or more client devices.
Claim 17 recites the following additional elements: computer-implemented; repository; client device; interface.
These elements are merely instructions to apply the abstract idea to a computer, per MPEP §2106.05(f). Applicant has only described generic computing elements in their specification, as seen in ¶ [0027] of applicant’s specification as filed, for example. Further, the combination of these elements is nothing more than a generic computing system.
Accordingly, these additional elements, alone and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP §2106.05.
Step 2B involves evaluating the additional elements to determine whether they amount to significantly more than the judicial exception itself.
The examination process involves carrying over identification of the additional element(s) in the claim from Step 2A Prong Two and carrying over conclusions from Step 2A Prong Two on the considerations discussed in MPEP §2106.05(f).
The additional elements and their analysis are therefore carried over: applicant has merely recited elements that facilitate the tasks of the abstract idea, as described in MPEP §2106.05(f).
Further, the combination of these elements is nothing more than a generic computing system. When the claim elements above are considered, alone and in combination, they do not amount to significantly more.
Therefore, per Step 2B, the additional elements, alone and in combination, are not significantly more. The claims are not patent eligible.
Further, the analysis takes into consideration all dependent claims as well:
Regarding claims 2-8, 10-16, and 18-24, applicant further narrows the abstract idea with additional step(s). There are no further additional elements to consider, beyond those highlighted above. This further narrowing of the abstract idea, similar to above, is also not patent eligible.
Regarding claim 9, applicant further narrows the abstract idea with additional step(s): approval module; client devices; one-click "merge from live" control. There are no further additional elements to consider beyond those highlighted above. This further narrowing of the abstract idea, similar to above, is also not patent eligible.
Accordingly, claims 1-24 are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, and 11-13 are rejected under 35 U.S.C. § 103 as being unpatentable over Phinney (US 20200151671) in view of Frantz (US 20240111949).
Claim 1
Phinney discloses:
A collaborative procedure-flow editing system comprising: {“Referring now to FIG. 1, a procedure flow administration system, generally referred to using the reference numeral 10, will now be described.” [0037]}
a repository storing a live procedure-flow graph comprising nodes and directed edges, each node representing a step in a procedure and each edge representing a navigation link between steps; {The system supports a data repository storing procedure flows composed of procedures steps interconnected by directional flow arrows indicating the order of the procedure. [0037], [0039]}
a server comprising a processor and memory storing instructions that, when executed, implement: {“The server side 12 of the procedure flow administration system 10 comprises a load balancer 14 and one or more web-application servers 16 on which one or more procedure flow applications 18 are running and each which can access a data repository (SQL database server) 20.” [0037]}
(a) a change-request engine configured to create, for an editing user, a draft procedure-flow graph as an editable copy of the live procedure-flow graph and to associate the draft with a baseline identifier of the live procedure-flow graph, the draft procedure-flow graph comprising a plurality of graph nodes and a plurality of graph edges; {The system creates a draft from the current live procedure flow when a draft does not already exist and permits the user to edit that draft. It further establishes that the draft is based on a particular live version and detects when the live version subsequently advances beyond the draft. The editable draft maintains the procedure flow structure composed of multiple steps and links. [0045] – [0046]}
(b) a graph engine configured to: (i) compute differences between the draft procedure-flow graph and the live procedure-flow graph; {The system identifies modified, added, and deleted portions of the draft and compares them against the live version. [0048]}
(ii) detect a baseline mismatch when a baseline identifier of the draft procedure-flow graph differs from a current identifier of the live procedure- flow graph; {The system detects the corresponding condition that the live version changed after the user’s draft was created. [0056]}
merges non-conflicting edits from the draft while retaining those edits in the rebased draft; {In response to intervening approved edits, the user is prompted to merge the approved live changes into the procedure flow being edited. The system compares corresponding old and new procedure flow structures and highlights changes. It further distinguishes conflicting changes from edits affecting sub-procedure flows and permits the latter to be merged. [0055] – [0056]}
(c) a conflict-resolution engine configured to, upon detection of a conflict: (i) present a side-by-side visualization of the current live procedure- flow graph and the conflicting draft procedure-flow graph with highlighted differences; {The system presents live and procedure flows side by side and highlights corresponding edits. [0048], [0057]}
(ii) enable flow-scoped discard that discards edits to a portion of the draft without discarding other edits to one or more other portions; and {The system treats conflicting changes at the procedure-flow or sub-procedure flow level: conflicting modifications to the same flow are discarded, whereas changes to different subflows may still be merged. [0056]}
- discards the conflicting portion of the graph, and {“Of note is that changes to the same procedure flow give rise to a conflict requiring the proposed modifications to be discarded and the approved live procedure flow reedited to incorporate the proposed modifications.” [0056]}
- reapplies the discarded edits from the placeholder graph onto a corresponding subgraph of the current live procedure-flow graph; {“Of note is that changes to the same procedure flow give rise to a conflict requiring the proposed modifications to be discarded and the approved live procedure flow reedited to incorporate the proposed modifications.” [0056]}
(d) an approval module configured to publish an approved draft by replacing the live procedure-flow graph in the repository and to flag other drafts associated with a prior baseline identifier as out-of-date; and {“On approval the live version is replaced with the proposed changes in the draft version and the changes are indicated as being approved.” [0052]; “the user receives a warning 178 to the effect that the current live version is ahead of the draft, and that changes to the current approved live procedure flow should be merged before continuing.” [0056]}
one or more client devices each configured to: {“The user side 22 of the procedure flow administration system 10 comprises one or more client devices as in 24 which access the one or more web-application servers 16 remotely using a broadband network 26 such as the Internet.” [0037]}
(i) render, for an editing user, a side-by-side view of the live procedure-flow graph and the draft procedure-flow graph with visual highlighting of graph-node-level and graph-edge-level edits; and {The client renders live and draft procedure-flows side by side and visually highlights edited steps; links are separated disclosed as editable flow elements. [0046], [0048]}
(ii) receive user inputs to initiate the rebase operation, resolve conflicts using the flow-scoped discard and placeholder-copy workflows, and submit the draft for approval. {“on selecting the Merge the new changes link 170”, the merge process proceeds. Conflicting edits are discarded, and the approved flow reedited. [0056]; The system allows the user to submit the draft for approval. [0050]}
Phinney does not disclose, however, Frantz, in a similar field of endeavor directed to live editing a workbook with multiple clients teaches:
(iii) in response to the baseline mismatch, perform a rebase operation that: - aligns the graph nodes and the graph edges of the draft procedure-flow graph to corresponding graph nodes and graph edges of the current live procedure-flow graph; and {In response to detecting that a client’s base version does not match the confirmed version, reintegrating the client’s local edits with the updated confirmed version by reverting to the prior version, applying intervening edits, and then attempting to reapply the client’s edit. [0074] – [0079]}
(iv) detect conflicts under predetermined conflict rules including at least one of: concurrent edits to a same node attribute, deletion of a node or edge in one graph while modified in the other, and reassignment of an edge endpoint altered by both graphs; {The system supports detecting conflicts by comparing the edit’s base version to the current workbook version and rejecting the edit or presenting an error when the versions do not match. [0061], [0064], [0074] – [0079]}
(iii) enable a placeholder-copy workflow that: - copies local conflicting edits into a temporary placeholder graph, {The system supports creating a temporary workbook file separate from the underlying workbook and applying the user’s local exploration edits to that temporary copy. [0037], [0040]}
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the collaborative procedure-flow editing and version-management features of Phinney to include the collaborative editing, synchronization, and conflict-resolution features of Frantz, to improve the robustness of collaborative editing operations. (See [0070] of Frantz).
Claim 11
The combination of Phinney and Frantz teaches the limitations set above. Phinney further discloses:
when performing the flow-scoped discard, only edits to a selected flow within a multi-flow change request are discarded, leaving edits to other flows intact. {a changeset may contain edits to “more than one main procedure flow or sub-procedure flow” [0048]; same-flow changes may require “the proposed modification to be discarded”, while “changes to different sub-procedure flows… can be merged together” [0056]}
Claim 12
The combination of Phinney and Frantz teaches the limitations set above. Frantz further teaches:
wherein the placeholder-copy workflow serializes local edits into a patch artifact, discards the conflicted portion from the draft, reinitializes the portion from the current live procedure-flow graph, and reapplies the patch artifact, thereby surfacing any residual conflicts. {The system supports storing local edits in a workbook patch, reverting the locally edited version, updating it with the current confirmed changes, and reapplying the local edit, with an error surfaced if reapplication fails. [0056] – [0058], [0079]}
The motivation and rationale to include the additional features of Frantz is the same as set forth previously.
Claim 13
The combination of Phinney and Frantz teaches the limitations set above. Phinney further discloses:
role-based access controls wherein contributors can create and edit drafts but cannot approve, approvers can approve and publish, and viewers can view only published drafts, and wherein side-by-side visualization and rebase controls are disabled for viewers. {The system provides role-based access involving viewer, contributor, approver, and admin roles and selectively restricts a user’s ability to create amend and approve procedure flows. [0038], [0051], [0058] – [0060]}
Claim 2 is rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Phinney and Frantz in further view of Mandal (US 20250209300).
Claim 2
While the combination of Phinney and Frantz teaches the limitations set above it does not explicitly teach, however, Mandal, in a similar field of endeavor directed to predictive inferences related to a graph representation of data, teaches:
wherein each of the plurality of graph nodes includes a persistent identifier and a step type selected from Action, Decision, Data, and Backstory, and wherein the graph engine aligns graph nodes using the persistent identifier and, when absent, using a similarity heuristic based on at least the step type, label text, and adjacency. {The system supports graph nodes having identifiers, attributes, labels, and neighboring relationships, and comparing nodes using similarity based on node features and adjacency. [0063], [0065], [0073], [0102], [0136] – [0138]}
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Phinney and Frantz to include the graph data processing features of Mandal, to improve the managing and processing of graph data. (See [0035] of Mandal).
Claim 3 is rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Phinney, Frantz, and Mandal in further view of Lipman (US 20200311688).
Claim 3
While the combination of Phinney, Frantz, and Mandal teaches the limitations set above it does not explicitly teach, however, Lipman, in a similar field of endeavor directed to facilitating the creation, communication and management of documents, teaches:
wherein the similarity heuristic comprises at least one of: hashing node content, attribute-vector comparison, and neighborhood overlap scoring. The system supports comparing information using hashing and attribute vector representations, including generating hashes from content and sorting textual tokens into vectors for subsequent analysis. [0059], [0140] – [0142]}
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Phinney, Frantz, and Mandal to include the document management and revision features of Lipman, to improve the document review and revision process. (See [0097] of Lipman).
Claims 4, 8-9, and 14 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Phinney and Frantz in further view of Frew (US 20140281873).
Claim 4
While the combination of Phinney and Frantz teaches the limitations set above it does not explicitly teach, however, Frew, in a similar field of endeavor directed to formatting a hierarchical data structure having structural elements, teaches:
wherein the graph engine represents edits as operations selected from: add-node, remove-node, modify-node-attribute, add-edge, remove-edge, and retarget-edge, and merges the operations against the current live procedure-flow graph during the rebase operation. {The system supports representing procedure flow edits through adding, deleting, editing, moving, copying, and linking steps and subsequently merging approved live changes into a procedure flow being edited. [0047] – [0048], [0056]}
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Phinney and Frantz to include the draft synchronization and conflict-handling features of Frew, to improve management of collaborative edits. (See [0057] of Frew).
Claim 8
While the combination of Phinney and Frantz teaches the limitations set above it does not explicitly teach, however, Frew, in a similar field of endeavor directed to formatting a hierarchical data structure having structural elements, teaches:
wherein the client devices provide a changes panel listing edits by operation type and affected node identifiers, each item navigable to a synchronized side-by-side visualization region. {The system presents a changes panel listing modified, added, and deleted procedure flows, allowing selection of a listed flow, and synchronizing adjacent live/draft views so the user can focus on the modified region. [0049] – [0050]}
The motivation and rationale to include the additional features of Frew is the same as set forth previously.
Claim 9
While the combination of Phinney and Frantz teaches the limitations set above it does not explicitly teach, however, Frew, in a similar field of endeavor directed to formatting a hierarchical data structure having structural elements, teaches:
wherein the approval module, upon publishing an approved draft, transmits out-of-date notifications to client devices holding drafts with mismatched baselines and provides a one-click "merge from live" control to trigger the rebase operation. {The system supports notifying users that an approved live version has changed, warning a user when the live version is ahead of the draft, and providing a “Merge the new changes” control for merging live changes into the draft. [0054], [0056] – [0057]}
The motivation and rationale to include the additional features of Frew is the same as set forth previously.
Claim 14
While the combination of Phinney and Frantz teaches the limitations set above it does not explicitly teach, however, Frew, in a similar field of endeavor directed to formatting a hierarchical data structure having structural elements, teaches:
wherein the client devices provide a draft navigation mode that executes navigation across the draft procedure-flow graph to validate link integrity and expected branching behavior prior to approval. {The “draft functions as the live version” and can be operated through the same linked procedure and sub-procedure flows before the draft is approved and made live. [0043], [0046]}
The motivation and rationale to include the additional features of Frew is the same as set forth previously.
Claim 5 is rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Phinney and Frantz in further view of McGee (US 20140310243).
Claim 5
While the combination of Phinney and Frantz teaches the limitations set above it does not explicitly teach, however, McGee, in a similar field of endeavor directed to adaptive procedural template comprised of common building blocks forming template frameworks, teaches:
wherein the rebase operation preserves a topological ordering and validates that mandatory navigation links remain connected post-merge, raising a conflict when a validation check fails. {The system supports preserving the sequence of steps and maintaining required links during changs, while identifying a problem when required conditions are not met. [0209], [0263], [0266]}
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Phinney and Frantz to include the workflow validation and connectivity maintenance features of McGee, to improve workflow integrity and consistency. (See [0266] of McGee).
Claims 6-7, and 15-16 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Phinney and Frantz in further view of Lipman (US 20200311688).
Claim 6
While the combination of Phinney and Frantz teaches the limitations set above it does not explicitly teach, however, Lipman, in a similar field of endeavor directed to facilitating the creation, communication and management of documents, teaches:
wherein the predetermined conflict rules are applied deterministically such that identical inputs produce identical merged graphs and conflict sets. {The system supports executing predetermined computer coded rules through smart contracts to validate and govern transactions, applying predefined processing logic to submitted information. [0060] – [0062]}
The motivation and rationale to include the additional features of Lipman is the same as set forth previously.
Claim 7
While the combination of Phinney and Frantz teaches the limitations set above it does not explicitly teach, however, Lipman, in a similar field of endeavor directed to facilitating the creation, communication and management of documents, teaches:
wherein the conflict-resolution engine supports iterative resolution across multiple conflicting subgraphs, persisting resolved portions while other conflicts remain outstanding. {The system supports iterative conflict resolution through repeated reviewer revision loops in which previously addressed edits are retained while remaining comments, questions, or proposed edits continue through further rounds of review. [0096] – [0097], [0165] – [0166]}
The motivation and rationale to include the additional features of Lipman is the same as set forth previously.
Claim 15
While the combination of Phinney and Frantz teaches the limitations set above it does not explicitly teach, however, Lipman, in a similar field of endeavor directed to facilitating the creation, communication and management of documents, teaches:
wherein the graph engine maintains a baseline provenance record for each draft including the baseline identifier, creation timestamp, and a list of merged live updates applied via rebase. {The system supports maintaining provenance and history for stored information, including transaction history, sequence information, version records, and information identifying the exact document provided to particular users at particular times. [0052], [0056], [0084]}
The motivation and rationale to include the additional features of Lipman is the same as set forth previously.
Claim 16
The combination of Phinney, Frantz, and Lipman teaches the limitations set above. Lipman further teaches:
wherein the baseline provenance record further includes a parent commit identifier and a rebase lineage. {The system supports maintaining a lineage between successive stored records using hash pointers identifying previous blocks and recording the sequence in which transactions become part of the blockchain. [0056], [0058]}
The motivation and rationale to include the additional features of Lipman is the same as set forth previously.
Claim 10 is rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Phinney, Frantz, and Frew in further view of Ayyar (US 20170357646).
Claim 10
While the combination of Phinney, Frantz, and Frew teaches the limitations set above it does not explicitly teach, however, Ayyar, in a similar field of endeavor directed to computing, applying, and displaying document deltas, teaches:
wherein the notifications comprise serialized deltas of node- and edge-level changes that update local baselines without transmitting full graph states. {The system supports serializing hierarchical document states, computing and storing incremental deltas between successive states, and transmitting the resulting feed information to clients rather than requiring transfer and comparison of the complete underlying document data. [0089] – [0091], [0110], [0118]}
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Phinney, Frantz, and Frew to include the node alignment and content comparison features of Ayyar, to improve the identification and comparison of corresponding content elements. (See [0062] of Ayyar).
Claims 17, 21, and 23-24 are rejected under 35 U.S.C. § 103 as being unpatentable over Phinney (US 20200151671) in view of Frantz (US 20240111949) in further view of Tulshibagwale (US 20250094924).
Claim 17
Phinney discloses:
A computer-implemented method for collaborative editing of a procedure- flow graph, comprising: {“In order to improve the ease and efficiency of developing and enforcing standardized operating procedures, a number of tools have been developed. These tools are typically implemented in a networked environment to better leverage collaboration between those developing the operating procedures, simplify roll out and simplify the production of usage reports for audits and governance amongst other reasons.” [0005]}
storing, in a repository, a live procedure-flow graph comprising graph nodes and graph edges; {The system supports storing procedure flows in a data repository, where the flows comprise procedure steps interconnected by directional flow arrows. [0037], [0039]}
creating, for an editing user, a draft procedure-flow graph as a copy of the live procedure-flow graph and associating the draft with a baseline identifier of the live procedure-flow graph; {The system creates a user’s editable draft by copying the current live procedure flow, establishing that the draft is based on a particular live version. [0045]}
rendering, on a client device, a side-by-side view of the live procedure-flow graph and the draft procedure-flow graph with highlighted edits; {“Changes introduced via the editing environment can be viewed adjacent the live version by selecting the “Review Your Changes” menu item 100. Referring now to 7C, selecting the “Review Your Changes” menu item 100 provides display of the live version 102 of the procedure flow and the draft version 104 in a double pane mode in adjacent side-by-side panes as in 106. Steps that have been edited in the edited procedure flow are surrounded with a corresponding highlighting 108.” [0048]}
presenting a conflict-resolution interface including: (i) flow-scoped discard of edits; and {Edits to a conflicting procedure flow are discarded while changes to different sub-procedure flows remain capable of being merged. [0048], [0056]}
publishing, upon approval, the draft procedure-flow graph as the live procedure-flow graph and flagging other drafts with mismatched baselines as out-of-date. {“On approval the live version is replaced with the proposed changes in the draft version and the changes are indicated as being approved.” [0052]; “in the event a user is working on modifications based on a live procedure flow which has subsequently been the subject of approved modifications on behalf of another user, as shown in FIG. 9C, the user receives a warning 178 to the effect that the current live version is ahead of the draft.” [0056]}
Phinney does not disclose, however, Frantz, in a similar field of endeavor directed to live editing a workbook with multiple clients, teaches:
detecting that the baseline identifier of the draft does not match a current identifier of the live procedure-flow graph; {The system supports detecting that a client’s base version ID does not match the version ID of the confirmed workbook. [0074], [0077]}
in response, performing a rebase operation comprising aligning corresponding graph nodes and corresponding graph edges of the draft procedure-flow graph to the graph nodes and the graph edges of the current live procedure-flow graph and merging non-conflicting edits from the draft into a rebased draft while retaining the edits; {The system supports reintegrating local edits with the updated confirmed workbook by applying intervening edits and then reapplying the local edit to the updated version. [0079]}
(ii) a placeholder-copy workflow that copies local edits into a temporary placeholder, discards a conflicting portion of the draft procedure-flow graph, initializes a subgraph from the current live procedure-flow graph, and reapplies the local edits from the placeholder thereto; and {The system supports storing edits in a temporary workbook, reverting the conflicting local version, applying the current confirmed changes, and the reapplying the local edit to the updated version. [0037], [0040], [0079]}
The motivation and rationale to include the additional features of Frantz is the same as set forth previously.
The combination of Phinney and Frantz does not disclose, however, Tulshibagwale, in a similar field of endeavor directed to resolve conflicts between records of a collaboration environment, teaches:
detecting conflicts based on predetermined conflict rules including at least concurrent modification of a same node attribute and deletion-versus-modification of a same graph node or a same graph edge; {The system supports detecting conflicting changes to the same record value and resolving them using predetermined rules. [0073] – [0074], [0079] – [0082]}
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Phinney and Frantz to include the conflict detection and resolution features of Tulshibagwale, to improve the consistency and reliability of conflict resolution. (See [0081] of Tulshibagwale).
Claim 21
The combination of Phinney, Frantz, and Tulshibagwale teaches the limitations set above. Phinney further discloses:
wherein publishing triggers notifications to client devices maintaining drafts with mismatched baselines and provides a user- selectable control to initiate the rebase operation. {The system supports notifying a user when the live version has advanced beyond the user’s draft and provides a selectable “Merge the new changes” control to initiate merging of the updated live changes into the draft. [0055] – [0056]}
Claim 23
The combination of Phinney, Frantz, and Tulshibagwale teaches the limitations set above. Phinney further discloses:
when performing the flow-scoped discard, only edits to a selected flow within a multi-flow change request are discarded, preserving other edits in the change request. {“Of note is that more than one main procedure flow or sub procedure flow of a given entry point may be edited by a user.” [0048]; “Of note is that changes to the same procedure flow give rise to a conflict requiring the proposed modifications to be discarded and the approved live procedure flow reedited to incorporate the proposed modifications. On the other hand, changes to different sub procedure flows, for example, can be merged together. Similarly, in the event a user is working on modifications based on a live procedure flow which has subsequently been the subject of approved modifications on behalf of another user, as shown in FIG. 9C, the user receives a warning 178 to the effect that the current live version is ahead of the draft, and that changes to the current approved live procedure flow should be merged before continuing.” [0056]}
Claim 24
The combination of Phinney, Frantz, and Tulshibagwale teaches the limitations set above. Phinney further discloses:
enforcing role-based permissions defining contributor, approver, and viewer roles with corresponding capabilities. {The system enforces role-based permissions by assigning users different roles and selectively limiting their ability to create, amend, view, and approve procedure flows. [0038], [0051], [0058] – [0060]}
Claim 18 is rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Phinney, Frantz, and Tulshibagwale in further view of Mandal (US 20250209300).
Claim 18
While the combination of Phinney, Frantz, and Tulshibagwale teaches the limitations set above it does not explicitly teach, however, Mandal, in a similar field of endeavor directed to predictive inferences related to a graph representation of data, teaches:
wherein aligning nodes employs persistent node identifiers and, absent such identifiers, employs a similarity heuristic using step type, label text, and neighboring topology. {The system supports resolving graph entities and comparing nodes based on associated entity identifiers, and neighboring graph relationships, including heuristics weighting, vector similarity, and adjacent information. [0063], [0065], [0073], [0102], [0106], [0136]}
The motivation and rationale to include the additional features of Mandal is the same as set forth previously.
Claims 19 and 22 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Phinney, Frantz, and Tulshibagwale in further view of Lipman (US 20200311688).
Claim 19
While the combination of Phinney, Frantz, and Tulshibagwale teaches the limitations set above it does not explicitly teach, however, Lipman, in a similar field of endeavor directed to facilitating the creation, communication and management of documents, teaches:
validating the rebased draft for link integrity and mandatory-step connectivity and, upon validation failure, surfacing a conflict requiring user action. {The system supports validating linked data and proposed operations according to predefined system rules and, when review or validation is unsuccessful, requiring further user action to resolve the issue before approval. [0056], [0058], [0096] – [0097]}
The motivation and rationale to include the additional features of Lipman is the same as set forth previously.
Claim 22
While the combination of Phinney, Frantz, and Tulshibagwale teaches the limitations set above it does not explicitly teach, however, Lipman, in a similar field of endeavor directed to facilitating the creation, communication and management of documents, teaches:
recording, for each draft, a baseline provenance including at least the baseline identifier and a log of applied rebases. {The system supports recording provenance for document versions and changes by maintaining transaction histories and records identifying the sequence and history of updates regarding stored documents. [0052], [0056], [0084]}
The motivation and rationale to include the additional features of Lipman is the same as set forth previously.
Claim 20 is rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Phinney, Frantz, and Tulshibagwale in further view of Frew (US 20140281873).
Claim 20
While the combination of Phinney, Frantz, and Tulshibagwale teaches the limitations set above it does not explicitly teach, however, Frew, in a similar field of endeavor directed to formatting a hierarchical data structure having structural elements, teaches:
listing edit operations in a changes panel and, upon selection of an item, focusing the side-by-side view on the affected subgraph. {The system supports listing edited procedure flows in a changes panel and, upon selection of an item, navigating to that procedure flow while providing synchronized side by side live and draft views that focus on the modified portions. [0049] – [0050]}
The motivation and rationale to include the additional features of Frew is the same as set forth previously.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure (additional pertinent references can be found on attached form PTO-892):
US 20110161284 A1, which teaches: Exemplary data management, data integration, and workflow systems and methods are disclosed. An exemplary method includes a data integration subsystem maintaining data representative of a set of one or more workflow rules configured for use by a workflow engine within the data integration subsystem to screen one or more data integration conflicts for workflow processing based on the set of one or more workflow rules and generate one or more workflow tasks for the screened one or more data integration conflicts based on the set of one or more workflow rules, receiving user input requesting an update to the set of one or more workflow rules, and dynamically updating, during a runtime of the workflow engine, the data representative of the set of one or more workflow rules to reflect the update. Corresponding systems and methods are also disclosed.
US 20170024437 A1, which teaches: An authoring platform for authoring a client workflow includes an arrangement of shapes representing steps and connections representing relationships between the steps. Online content retrieved from an online resource may be associated with steps of the client workflow. An authoring service receives the client workflow from the client interface via a network and directs a graph database to store a database workflow corresponding to the client workflow. A search platform is provided for creating and searching workflows using a tag database taxonomy. An author creates a workflow wherein a tag is linked to a workflow item. The workflow is stored as a database workflow and a node in the database workflow representing the workflow item is linked to a node in the database taxonomy representing the tag. Multiple workflows are created in a similar manner to link the workflows to the database taxonomy to provide efficient searching of the workflows.
US 20220122038 A1, which teaches: An artificial intelligence (AI) platform to support workflow version process control. One or more workflows corresponding to one or more workflow engines are monitored. A neural network is employed to capture a relationship associated with a detected change in the monitored workflows. The neural network is leveraged to identify and assess an impact of the detected change to one or more additional workflows. Responsive to the assessment, the impacted workflow engines are optimized. The optimization includes automatically mapping and encoding changes corresponding to the impacted workflow. The one or more workflows containing the encoded changes are then executed.
“A novel collaborative optimization algorithm in solving complex optimization problems” (NPL attached), which teaches: To overcome the deficiencies of weak local search ability in genetic algorithms (GA) and slow global convergence speed in ant colony optimization (ACO) algorithm in solving complex optimization problems, the chaotic optimization method, multi-population collaborative strategy and adaptive control parameters are introduced into the GA and ACO algorithm to propose a genetic and ant colony adaptive collaborative optimization (MGACACO) algorithm for solving complex optimization problems. The proposed MGACACO algorithm makes use of the exploration capability of GA and stochastic capability of ACO algorithm. In the proposed MGACACO algorithm, the multi-population strategy is used to realize the information exchange and cooperation among the various populations. The chaotic optimization method is used to overcome long search time, avoid falling into the local extremum and improve the search accuracy. The adaptive control parameters is used to make relatively uniform pheromone distribution, effectively solve the contradiction between expanding search and finding optimal solution. The collaborative strategy is used to dynamically balance the global ability and local search ability, and improve the convergence speed. Finally, various scale TSP are selected to verify the effectiveness of the proposed MGACACO algorithm. The experiment results show that the proposed MGACACO algorithm can avoid falling into the local extremum, and takes on better search precision and faster convergence speed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS F MONTALVO whose telephone number is (703)756-5863. The examiner can normally be reached Monday - Friday 8:00AM - 5:30PM; First Fridays OOO.
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, Sarah Monfeldt can be reached at 571-270-1833. 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.
/C.F.M./Examiner, Art Unit 3629 /SARAH M MONFELDT/Supervisory Patent Examiner, Art Unit 3629
Prosecution Insights