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 .
DETAILED ACTION
Status of the Application
The following is a Final Office Action.
In response to Examiner's communication of 2/27/2025, Applicant responded on 7/28/2025. Amended claims 1, 7, 8, 13.
Claims 1-18 are pending in this application and have been examined.
Response to Amendment
Applicant's amendments to claims 8 are sufficient to overcome the claim objection set forth in the previous action. The previous claim objection is hereby withdrawn.
Applicant's amendments to claims 1, 7, 13 are not sufficient to overcome the 35 USC 101 rejections set forth in the previous action.
Applicant's amendments to claims 1, 7, 13 are not sufficient to overcome the prior art rejections set forth in the previous action.
Response to Arguments – 35 USC § 101
Applicant’s arguments with respect to the rejections have been fully considered, but they are not persuasive.
Applicant submits, “…, the amendment to claims 1, 7 and 13 render the foregoing analysis moot as a new limitation has been added to claims 1, 7 and 13 which cannot be considered a "mental process" and which in any event reflects a unique technological computing environment in which the inventive data processing method, system and device is performed...explicitly recite (A) a common event bus of a host computing platform onto which events are posted by business object instances and which events are processed by different assigned event handlers executing by processing units of the host computing platform; and (B) a sandboxed process address space in a form of a container defined within the memory of the host computing platform, and with the container hosting a manager of the common event bus. As it is not possible to view the foregoing as a mental process, it is believed that the rejections to claims 1, 7 and 13 under 35 U.S.C. § 101 can be withdrawn….” The Examiner respectfully disagrees.
While Applicant’s amendments further prosecution, the claims are directed to, …Document workflow management… to generate, track, revise, approve, capture, retrieve, retain, and destroy documents that are linked to particular business processes.…, which is a problem directed to a mental process (i.e. humans managing business documents, human drafting business documents), as established in Step 2A Prong 1. Additionally, pursuant to the broadest reasonable interpretation, as an ordered combination, each of the additional elements are computing elements recited at high level of generality implementing the abstract idea, and thus, are no more than applying the abstract idea with generic computer components. Further, these additional elements generally link the abstract idea to a technical environment, namely the environment of a computer, performing extra solution activities. Therefore, as a whole, the additional elements applying the abstract ideas do not integrate the abstract ideas into a practical application in Step 2A Prong 2. Even novel and newly discovered judicial exceptions are still exceptions, despite their novelty. July 2015 Update, p. 3; see SAP America Inc. v. Investpic, LLC, No. 2017-2081, slip op. at 2 (Fed Cir. May 15, 2018).
Simply reciting specific limitations that narrow the abstract idea does not make an abstract idea non-abstract. 79 Fed. Reg. 74631; buySAFE Inc. v. Google, Inc., 765 F.3d 1350, 1355 (2014); see SAP America at p. 12. As discussed in SAP America, no matter how much of an advance the claims recite, when “the advance lies entirely in the realm of abstract ideas, with no plausibly alleged innovation in the non-abstract application realm,” “[a]n advance of that nature is ineligible for patenting.” Id. at p. 3.
Response to Arguments – Prior Art
Applicant’s arguments with respect to the rejections have been fully considered, but they are not persuasive.
Applicant submits, “…the provision by a sandboxed process address space of a logical execution environment in a form of a container defined within memory of a host computing platform. Further essentially present in claims 1, 7 and 13 is the hosting by the container of a manager of a common event bus of the host computing platform onto which events are posted by business object instances and which events are processed by different assigned event handlers executing by processing units of the host computing platform. The foregoing complex architecture is not present in Hunn...Throughout Hunn, there is reference to the term "event", however, not in the context of a computing event, but in the context of a contractual event, for example: " Objects are preferably immutably added to the graph in an append- only fashion when events, transactions, updates, and other operations occur under the contract and/or otherwise relate to the contract. " Those changes may be initiated by the contracting parties, third parties, and/or physical world or other events pertaining to the contract. As can be seen, the term event in Hunn relates to a contract event. However, as claimed in claims 1, 7 and 13, an "event" relates to a digital artifact placed upon an event bus and processed by "event handlers": events are posted by business object instances and which events are processed by different assigned event handlers executing by processing units of the host computing platform...” The Examiner respectfully disagrees.
Under the broadest reasonable interpretation, real world contractual events can be interpreted as computing events if the real world contractual events are digitalized and computed on computer systems and communicated via common event bus such as APIs and event handlers such as COGs, blockchain ledgers and virtual machines responding to POST events by objects. Thus, Hunn discloses:
providing a logical execution environment as a sandboxed process address space in a form of a container defined within memory of a host computing platform, the container hosting a manager of a common event bus of the host computing platform onto which events are posted by business object instances and which events are processed by different assigned event handlers executing by processing units of the host computing platform; (in at least [0331][0332][0064]-[0069][0038] FIG. 32 is an exemplary depiction of the components that may be used in the system [0070] the COG is preferably used for directing the dynamic functionality of a computable contract such as interacting with outside data sources, updating based on external data (e.g., from an API, IoT/client device, private data of a third party, data from a BDL etc.), driving or performing actions on external resources (e.g., transmitting commands via an API, executing transactions or compiling code to/on a BDL, etc.), performing internal logic, performing cross-contract logic, and the like. Such logic and state of a computable contract is preferably represented and maintained by the COG. Accordingly, executing formation of the COG can include one or more instances of receiving a state update S210 and appending at least one update object component to the COG in accordance with the contract state update S220 [0079] The COG 120 functions as a data structure or model used in representing the contract logic and/or state. The COG 120 can be a singular data structure but may alternatively be a set of data structures used to cooperatively represent the COG 120. The COG 120 preferably represents the terms and/or conditions of a computable, data-driven contract. In a full contract variation, the COG can represent the terms and the conditions—both logic and state. In a logical representation variation, a logic-based COG (i.e., a contract logic graph) can represent the logic. In a state representation variation, a state-based COG (i.e., a contract state graph) can represent the state of the computable, data-driven contract. In yet another variation, multiple COGs/graph data structures/databases may be used and managed in combination. For example, a logic-based COG could be used alongside a state-based COG in the execution and lifecycle management of a contract. The terms and logic of a COG 120 can be amended and updated during formation and post-formation. During the execution stage, the COG 120 can update and change in real time or near real time in response to logic, data, state updates, and external events. A computable contract can preferably act as a legal contract that is capable of being at least semi-autonomous or ‘self-managing’ in nature. [0092] all involved parties should execute the contract logic in a standardized execution environment which may include but is not limited to: a virtual machine, communicatively connected servers/virtual machines, BDL system(s), a centralized server, cloud environment, container or series of containers, computing cluster, or any other appropriate execution environment or combination thereof. In a preferred implementation, the execution environment consists of a peer-to-peer network (and preferably an overlay network on top of the World Wide Web) where each user (e.g. a contracting party) that uses the system and method is a node on the network as depicted in FIG. 40 [0095] facilitate inter-contract references at the formation stage as well as consistency and real-time updates between contracts (and/or other documentation that may use the system and method) at the post-formation stage. Similarly, the data structure may integrate with BDLs to the same qualities (see FIG. 8). The data structure may also be used to extend beyond the contract to manage workflows or other events that may pertain to the contract such as interfacing with an IoT device or platform, an API, or other external data resources and systems. [0102] the graph data structure may be queried or data may be otherwise extracted (e.g. when used in conjunction with a contract management system) to provide data and the base for descriptive, predictive, prescriptive, and any other appropriate form of analytics across pre- and post-execution of one or more contracts (see ‘Analytics System’ in FIG. 3). For example, the graph for each contract may be traversed and queried (e.g. via API or through use of a graph processing engine, or similar) to provide analytics such as causation (e.g. ‘versioning’ links) and other relationships between objects (which may be beneficial for contractual analytics, counterparty assessment, internal workflows, contractual enforcement and other reasons). [0127] An event object is an object type that can record post-formation events that occur in respect of the contract that may or may not update the state of the contract/COG. For example, event objects may be used to record outputs from the contract to external systems (e.g. update of a price to an invoice on an external system, via an API etc.); transactions that occur on BDLs; and/or inputs to the contract from external resources, the contracting parties, and/or third parties. Event objects may, in a preferred embodiment, be broadly categorized as either ‘modifying’ or ‘non-modifying’. A modifying event object may update the state of the contract/COG. A non-modifying event object may record an event (e.g., a party fulfilling some obligation) but without changing the state of the contract/COG. [0181] contracts may be formed and managed using a multi-signature mechanism. As shown in exemplary FIG. 14, the system and method can use a multi-signature mechanism as a placeholder while the contract is formed and executed. When the contract is complete for execution, the parties may sign using their private keys to execute the contract. The multi-signature mechanism may be ‘on-ledge’/‘on-chain’ (i.e. using a BDL instantiation or where this approach is used, preferably, an ‘object ledger’) or ‘off-ledge’/‘off-chain’ (e.g. using the graph data structure and preferably the MDAG variation). Upon completion of required signatures, the COG can be committed, transferred, or otherwise activated for post-formation execution. [0201] Where a centralized execution environment is used (e.g. a centralized server or cloud management platform), the centralized environment may contain a version of the graph for each party—as each graph may differ such as in the event that ‘party-side’ events are stored in the graph—and a singular executable version of the contract or, alternatively, each party may have an executable version to limit any potential issues with tampering of contract logic. The contract logic is preferably executed within a sandboxed environment. [0226] Each state update may contain data relating, but not limited to metadata relating to the change, the Merkle root of the contract, and/or a link to the previous state update or commit (depending on the implementation). [0227] The metadata may include data such as data inputs to the contract logic and/or graph such as data from an API, HTTP(S) client, ERP/CRM/IMS or other system, databases, BDL, ‘smart contract’ scripts that interacts with clauses. For example, such data input metadata may include timestamp, initiator(s) (e.g. external resource such as an API, BDL, database, event; contracting party, third party etc.), the value(s) relating to the change (e.g. humidity of 55%), and/or device data. [0235] Data input state updates include data external to the contract being exposed to the logic of the contract to execute updates to the logic and/or state of the contract. Examples of data input that can result in state updates can include receiving API data (e.g. payment made/confirmed, shipping arranged etc.); receiving, retrieving, or detecting a transaction or operation performed on a BDL or data otherwise stored on or a BDL; receiving data from databases, event stores, and other data storage systems; receiving data or communication input from edge computing devices (sensors, actuators, RFID etc.); receiving data from “smart contract” scripts, “oracles”, and the like; receiving inputs from Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Inventory Management (IMS) systems, and other systems/applications; receiving or detecting or receiving input from ‘Event Stream Processing’ (ESP) and ‘Complex Event Processing’ (CEP) events; and/or receiving data or events from analytics platforms/systems and cognitive computing system outputs. [0236] Data output state updates can involve the contract logic executing or otherwise performing or initiating an operation on one or more resources (e.g. a third party system, API, BDL, database, system, application etc.). One variation can include executing some operation through an API such as executing payment with a payment service, updating/reconciling invoices, and/or performing any action through an API. Another variation can include performing some operation on an edge computing device or machine. This may include communicating a machine interpretable instruction. Another variation can include performing a transaction on a BDL or similar system. For example, a transfer of an asset can be performed as a transaction on a BDL. Execution of a transaction. In this variation, a cryptographic hash/UUID from the data structure and/or metadata may be put on, or otherwise added to, the BDL by being referenced in “smart contract” script(s) when compiled to the ledger or executed by invoking ‘on-chain’/‘ion-ledger’ code (depending on the given implementation). Alternatively or in addition, objects from the graph data structure or parameters may be passed to ‘on-chain’/‘ion-ledger’ code. This creates a record between the contract data structure and the transaction(s) on a BDL. In a related BDL variation, data output can include executing pre-existing “smart contract” scripts deployed and invoked to a BDL. For example, this could be used in an implementation where “smart contract” scripts are not compiled from the contract logic. [0255] The cryptographic proof may be stored in the state update to provide an immutable record of the data that interfaced with/input into the contract from certain applicable external sources (e.g. APIs, HTTP clients) and that this data resulted in a given change to the state of the contract. This enables the data that interfaces with the contract to itself be verified, thereby improving the integrity of the post-formation versioning process. [0256] all input data happens, where supported, through a standardized CCN (or similar) where all data packets are ‘Merkelized’, tracked on commit servers, and signed by the original servers. An example would be a web-service or data-service API that output such signed CCN packets, as well as timestamps the packets on its own server. This way the system is independent of traditional certificate infrastructure and solely relies on public-private keys. Interoperability and cross-server versioning are the default this way, making tracking of input-output chains possible across any number of data producers and servers. [0261] the execution environments can include or use virtual machines, containers, servers, and/or alternative runtime engines. [0262] The VM may be distributed, centralized, or take any other appropriate form. In some variations, contracting parties act as a node in the execution environment and may each run a VM runtime environment (see FIG. 40). However, other variations may alternatively use server nodes in the execution environment and/or combination of contract party nodes and server nodes. Server nodes (or other non-party nodes) may be used to support the network, and may be particularly beneficial in the event that a contract party node is offline or unreachable. FIGS. 33 and 34 depict exemplary methods of implementing one or more virtual machines. [0263] to use a VM as the runtime environment to execute contracts between participants (contracting parties and any third parties). The VM may execute multiple contracts simultaneously/in parallel, but each contract is preferably executed separately. The VM runtime environment operates by managing the execution of the contract, transitioning of the graph data structure, and other services (see FIG. 40). [0264] Each party that runs the VM may be a node on a, preferably peer-to-peer, network and may be seen to represent: (a) a contracting party, entity, individual enterprise, company, group, or similar, or (b) where applicable, another entity. Data from that contract is replicated or otherwise distributed across all users of the VM whose users are participating in a given contract. The VM computes state updates and then broadcasts to the parties and third parties, as determined by the logic. These are then confirmed in accordance with any permissioning requirements. [0269] A container variation may execute a contract in part or whole in a container or series of containers (e.g. for each clause). The container may be deployed from contract repositories (where used) and interacted with via bi-directional RPC channels. Changes to the state of the contract in formation or post-formation may be applied to the graph data structure and/or executed on a BDL. Alternatively, containers may be used only to execute transactions/operations on the BDL, and the remainder of ‘off-chain’/‘off-ledger’ operations that relate to contracts are executed using the P2P networking protocol (DHT routing, transport, etc.) [0273] In the post-formation stage of the contract lifecycle, the execution environment is used to manage the process of executing, updating, and versioning the executed state of the contract and graph data structure. The contracting parties' servers/virtual machines use the COG data structure to compute and maintain a preferably consensus-based, cryptographically secure state of the legal contract. [0301] These structures may themselves connect to, or otherwise interact with, other BDLs and protocols through a suitable programmatic mechanism such as by using an atomic cross-chain protocol, ‘smart contract’ scripts, APIs, ‘sidechains’, parallel chains, relay chains, or similar interoperability protocol or mechanism of connecting homogenous or heterogeneous BDL protocols/implementations (e.g. Interledger, Polkadot etc.). A preferred embodiment uses a singular chain for both inputs and outputs to the contract that may be queried via API or other method to provide filterable lists of transactions, events, and other data to users. Multiple chains/ledgers may interact with the contract ledger/chain. An alternative embodiment may use one or more ‘input’ BDL(s) and one or more ‘output’ BDL(s). [0302] Objects from the COG data structure may be appended/added to the BDL (which may be transposed directly and unedited from the graph or may have metadata removed, obfuscated, or added). For example, an update object may be added to a BDL for the contract to make parties that are not privy to the contract, aware of a state change. Similarly, an event object may aid ‘workflow’ between participant nodes on the BDL. Further still, a transaction object may be used to replicate or record the performance of an operation or execution of a transaction performed on an external system, entity, application, protocol etc. [0304] data may be added to the BDL structures (e.g. in the same mechanisms as stated herein) that are not included in the graph data structure. For example, data from other systems, applications, BDLs, databases, APIs, “smart contract” code, ‘on-chain/on-ledger’ multi-signatures, and others as shown in exemplary FIG. 35. This enables the ledger state to the contract to store the state relevant to the contract that does not itself, emanate from, or is not related to, the contract logic or the graph data structure. [0308] Interaction with BDLs may occur in a number of different ways such as an API interaction, interaction involving compilation to virtual machine bytecode, interpretation of off-chain/off-ledger clauses, interaction with BDLs. [0309]-[0320][0324]-[0326])
Claim Objection
Claim 1, 7, 13 are objected due to the following informality.
Claim 1, 7, 13 recites, “…a host computing platform…”, “…a common event bus of the host computing platform…”, “…the common host computing platform…”. It is unclear if “host computing platform” and “the common host computing platform” refer to the same element. Appropriate correction required.
Claim Rejections – 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 1 (similarly 7 and 13) recites, “An extensible state-based workflow management method comprising:
providing a logical execution environment as a sandboxed process address space in a form of a container defined within …, the container hosting a manager of … onto which events are posted by business object instances and which events are processed by different assigned event handlers executing by …;
defining within the process address space a base workflow for a single business object type, the base workflow comprising a multiplicity of the event handlers, each of the event handlers responding to a canonicalized form of an input document with a canonicalized form of an output document, the base workflow specifying an initial state, a final state and one or more intermediate states;
augmenting the base workflow into multiple different extended workflows, each augmentation extending the base workflow differently for different ones of the instances of the single business object type, the different instances concurrently executing in the …, each extended workflow incorporating an expansion of one of the intermediate states into a sequence of sub-states; and,
executing each of the extended workflows concurrently in association with a corresponding one of the instances of the business object of the single business object type within the ….”
Analyzing under Step 2A, Prong 1:
The limitations regarding, … providing a logical execution environment as a sandboxed process address space in a form of a container defined within …, the container hosting a manager of … onto which events are posted by business object instances and which events are processed by different assigned event handlers executing by …; defining within the process address space a base workflow for a single business object type, the base workflow comprising a multiplicity of the event handlers, each of the event handlers responding to a canonicalized form of an input document with a canonicalized form of an output document, the base workflow specifying an initial state, a final state and one or more intermediate states; augmenting the base workflow into multiple different extended workflows, each augmentation extending the base workflow differently for different ones of the instances of the single business object type, the different instances concurrently executing in the …, each extended workflow incorporating an expansion of one of the intermediate states into a sequence of sub-states; and, executing each of the extended workflows concurrently in association with a corresponding one of the instances of the business object of the single business object type within the …, under the broadest reasonable interpretation, can include a human using their mind and using pen and paper to, … providing a logical execution environment as a sandboxed process address space in a form of a container defined within …, the container hosting a manager of … onto which events are posted by business object instances and which events are processed by different assigned event handlers executing by …; defining within the process address space a base workflow for a single business object type, the base workflow comprising a multiplicity of the event handlers, each of the event handlers responding to a canonicalized form of an input document with a canonicalized form of an output document, the base workflow specifying an initial state, a final state and one or more intermediate states; augmenting the base workflow into multiple different extended workflows, each augmentation extending the base workflow differently for different ones of the instances of the single business object type, the different instances concurrently executing in the …, each extended workflow incorporating an expansion of one of the intermediate states into a sequence of sub-states; and, executing each of the extended workflows concurrently in association with a corresponding one of the instances of the business object of the single business object type within the …; therefore, the claims are directed to a mental process.
Accordingly, the claims are directed to a mental process, and thus, the claims are directed to an abstract idea under the first prong of Step 2A.
Analyzing under Step 2A, Prong 2:
This judicial exception is not integrated into a practical application under the second prong of Step 2A.
In particular, the claims recite the additional elements beyond the recited abstract idea identified under Step 2A, Prong 1, such as:
Claim 1, 7, 13: address space in a form of a container defined within memory of a host computing platform, a common event bus of the host computing platform, processing units of the host computing platform, A data processing system adapted for extensible state-based workflow management, the system comprising: a host computing platform comprising one or more computers, each with memory and one or processing units including one or more processing cores; and, a workflow extensibility management module comprising computer program instructions enabled while executing in the memory of at least one of the processing units of the host computing platform, A computing device comprising a non-transitory computer readable storage medium having program instructions stored therein, the instructions being executable by at least one processing core of a processing unit to cause the processing unit
, and pursuant to the broadest reasonable interpretation, as an ordered combination, each of the additional elements are computing elements recited at high level of generality implementing the abstract idea, and thus, are no more than applying the abstract idea with generic computer components. Further, these additional elements generally link the abstract idea to a technical environment, namely the environment of a computer.
Additionally, with respect to, “defining…”, “augmenting…”, “executing…”, “publish…”, these elements do not add a meaningful limitations to integrate the abstract idea into a practical application because they are extra-solution activity, pre and post solution activity - i.e. data gathering – “defining…”, “augmenting…”, data output – “executing…”, “publish…”.
Analyzing under Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception under Step 2B.
As noted above, the aforementioned additional elements beyond the recited abstract idea are not sufficient to amount to significantly more than the recited abstract idea because, as an order combination, the additional elements are no more than mere instructions to implement the idea using generic computer components (i.e. apply it).
Additionally, as an order combination, the additional elements append the recited abstract idea to well-understood, routine, and conventional activities in the field as individually evinced by the applicant’s own disclosure, as required by the Berkheimer Memo, in at least:
[0023] Aspects of the process described in connection with Figure 1 can be implemented within a data processing system. In further illustration, Figure 2 schematically shows a data processing system adapted to perform extensible state-based workflow management. In the data processing system illustrated in Figure 1, a host computing platform 200 is provided. The host computing platform 200 includes one or more computers 210, each with memory 220 and one or more processing units 230. The computers 210 of the host computing platform (only a single computer shown for the purpose of illustrative simplicity) can be co-located within one another and in communication with one another over a local area network, or over a data communications bus, or the computers can be remotely disposed from one another and in communication with one another through network interface 260 over a data communications network 240.
[0024] A sandboxed process address space providing a logical execution environment in the form of a container 280 is defined within the memory 220 and hosts the management of a common event bus 265 onto which events are posted by business object instances 265 and which events are processed by different assigned event handlers 255 executing by the processing units 230 of the host computing platform 200. Each of the business object instances 265 has associated therewith, a base workflow 270A of different states for which transitions therefrom, transitions there between and transitions thereto, individually can trigger corresponding one of the event handlers 255. In this regard, ones of the event handlers 255 can be triggered upon selecting a transition to a designated one of the different states so as to determine whether or not the transition is permitted before assenting to the transition. As well, ones of the events handlers 255 can be triggered after a transition and upon arriving at a designated one of the different states.
[0032] Of import, the foregoing flowchart and block diagram referred to herein illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computing devices according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function or functions. In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
[0033] More specifically, the present invention may be embodied as a programmatically executable process. As well, the present invention may be embodied within a computing device upon which programmatic instructions are stored and from which the programmatic instructions are enabled to be loaded into memory of a data processing system and executed therefrom in order to perform the foregoing programmatically executable process. Even further, the present invention may be embodied within a data processing system adapted to load the programmatic instructions from a computing device and to then execute the programmatic instructions in order to perform the foregoing programmatically executable process. [0034] To that end, the computing device is a non-transitory computer readable storage medium or media retaining therein or storing thereon computer readable program instructions. These instructions, when executed from memory by one or more processing units of a data processing system, cause the processing units to perform different programmatic processes exemplary of different aspects of the programmatically executable process. In this regard, the processing units each include an instruction execution device such as a central processing unit or "CPU" of a computer. One or more computers may be included within the data processing system. Of note, while the CPU can be a single core CPU, it will be understood that multiple CPU cores can operate within the CPU and in either instance, the instructions are directly loaded from memory into one or more of the cores of one or more of the CPUs for execution.
[0035] Aside from the direct loading of the instructions from memory for execution by one or more cores of a CPU or multiple CPUs, the computer readable program instructions described herein alternatively can be retrieved from over a computer communications network into the memory of a computer of the data processing system for execution therein. As well, only a portion of the program instructions may be retrieved into the memory from over the computer communications network, while other portions may be loaded from persistent storage of the computer. Even further, only a portion of the program instructions may execute by one or more processing cores of one or more CPUs of one of the computers of the data processing system, while other portions may cooperatively execute within a different computer of the data processing system that is either co-located with the computer or positioned remotely from the computer over the computer communications network with results of the computing by both computers shared therebetween.
[0036] The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed.
Furthermore, as an ordered combination, these elements amount to generic computer components receiving or transmitting data over a network, performing repetitive calculations, electronic record keeping, and storing and retrieving information in memory, which, as held by the courts, are well-understood, routine, and conventional. See MPEP 2106.05(d).
Moreover, the remaining elements of dependent claims do not transform the recited abstract idea into a patent eligible invention because these remaining elements merely recite further abstract limitations that provide nothing more than simply a narrowing of the abstract idea recited in the independent claims.
Looking at these limitations as an ordered combination adds nothing additional that is sufficient to amount to significantly more than the recited abstract idea because they simply provide instructions to use a generic arrangement of generic computer components to “apply” the recited abstract idea, perform insignificant extra-solution activity, and generally link the abstract idea to a technical environment. Thus, the elements of the claims, considered both individually and as an ordered combination, are not sufficient to ensure that the claim as a whole amounts to significantly more than the abstract idea itself. Since there are no limitations in these claims that transform the exception into a patent eligible application such that these claims amount to significantly more than the exception itself, claims 1-18 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-18 is/are rejected under 35 U.S.C. 102 as being unpatentable by US Patent Publication to US20180005186A1 to Hunn, (hereinafter referred to as “Hunn”).
As per Claim 1, Hunn teaches: (Currently Amended) An extensible state-based workflow management method comprising:
providing a logical execution environment as a sandboxed process address space in a form of a container defined within memory of a host computing platform, the container hosting a manager of a common event bus of the host computing platform onto which events are posted by business object instances and which events are processed by different assigned event handlers executing by processing units of the host computing platform; (in at least [0331][0332][0064]-[0069][0038] FIG. 32 is an exemplary depiction of the components that may be used in the system [0070] the COG is preferably used for directing the dynamic functionality of a computable contract such as interacting with outside data sources, updating based on external data (e.g., from an API, IoT/client device, private data of a third party, data from a BDL etc.), driving or performing actions on external resources (e.g., transmitting commands via an API, executing transactions or compiling code to/on a BDL, etc.), performing internal logic, performing cross-contract logic, and the like. Such logic and state of a computable contract is preferably represented and maintained by the COG. Accordingly, executing formation of the COG can include one or more instances of receiving a state update S210 and appending at least one update object component to the COG in accordance with the contract state update S220 [0079] The COG 120 functions as a data structure or model used in representing the contract logic and/or state. The COG 120 can be a singular data structure but may alternatively be a set of data structures used to cooperatively represent the COG 120. The COG 120 preferably represents the terms and/or conditions of a computable, data-driven contract. In a full contract variation, the COG can represent the terms and the conditions—both logic and state. In a logical representation variation, a logic-based COG (i.e., a contract logic graph) can represent the logic. In a state representation variation, a state-based COG (i.e., a contract state graph) can represent the state of the computable, data-driven contract. In yet another variation, multiple COGs/graph data structures/databases may be used and managed in combination. For example, a logic-based COG could be used alongside a state-based COG in the execution and lifecycle management of a contract. The terms and logic of a COG 120 can be amended and updated during formation and post-formation. During the execution stage, the COG 120 can update and change in real time or near real time in response to logic, data, state updates, and external events. A computable contract can preferably act as a legal contract that is capable of being at least semi-autonomous or ‘self-managing’ in nature. [0092] all involved parties should execute the contract logic in a standardized execution environment which may include but is not limited to: a virtual machine, communicatively connected servers/virtual machines, BDL system(s), a centralized server, cloud environment, container or series of containers, computing cluster, or any other appropriate execution environment or combination thereof. In a preferred implementation, the execution environment consists of a peer-to-peer network (and preferably an overlay network on top of the World Wide Web) where each user (e.g. a contracting party) that uses the system and method is a node on the network as depicted in FIG. 40 [0095] facilitate inter-contract references at the formation stage as well as consistency and real-time updates between contracts (and/or other documentation that may use the system and method) at the post-formation stage. Similarly, the data structure may integrate with BDLs to the same qualities (see FIG. 8). The data structure may also be used to extend beyond the contract to manage workflows or other events that may pertain to the contract such as interfacing with an IoT device or platform, an API, or other external data resources and systems. [0102] the graph data structure may be queried or data may be otherwise extracted (e.g. when used in conjunction with a contract management system) to provide data and the base for descriptive, predictive, prescriptive, and any other appropriate form of analytics across pre- and post-execution of one or more contracts (see ‘Analytics System’ in FIG. 3). For example, the graph for each contract may be traversed and queried (e.g. via API or through use of a graph processing engine, or similar) to provide analytics such as causation (e.g. ‘versioning’ links) and other relationships between objects (which may be beneficial for contractual analytics, counterparty assessment, internal workflows, contractual enforcement and other reasons). [0127] An event object is an object type that can record post-formation events that occur in respect of the contract that may or may not update the state of the contract/COG. For example, event objects may be used to record outputs from the contract to external systems (e.g. update of a price to an invoice on an external system, via an API etc.); transactions that occur on BDLs; and/or inputs to the contract from external resources, the contracting parties, and/or third parties. Event objects may, in a preferred embodiment, be broadly categorized as either ‘modifying’ or ‘non-modifying’. A modifying event object may update the state of the contract/COG. A non-modifying event object may record an event (e.g., a party fulfilling some obligation) but without changing the state of the contract/COG. [0181] contracts may be formed and managed using a multi-signature mechanism. As shown in exemplary FIG. 14, the system and method can use a multi-signature mechanism as a placeholder while the contract is formed and executed. When the contract is complete for execution, the parties may sign using their private keys to execute the contract. The multi-signature mechanism may be ‘on-ledge’/‘on-chain’ (i.e. using a BDL instantiation or where this approach is used, preferably, an ‘object ledger’) or ‘off-ledge’/‘off-chain’ (e.g. using the graph data structure and preferably the MDAG variation). Upon completion of required signatures, the COG can be committed, transferred, or otherwise activated for post-formation execution. [0201] Where a centralized execution environment is used (e.g. a centralized server or cloud management platform), the centralized environment may contain a version of the graph for each party—as each graph may differ such as in the event that ‘party-side’ events are stored in the graph—and a singular executable version of the contract or, alternatively, each party may have an executable version to limit any potential issues with tampering of contract logic. The contract logic is preferably executed within a sandboxed environment. [0226] Each state update may contain data relating, but not limited to metadata relating to the change, the Merkle root of the contract, and/or a link to the previous state update or commit (depending on the implementation). [0227] The metadata may include data such as data inputs to the contract logic and/or graph such as data from an API, HTTP(S) client, ERP/CRM/IMS or other system, databases, BDL, ‘smart contract’ scripts that interacts with clauses. For example, such data input metadata may include timestamp, initiator(s) (e.g. external resource such as an API, BDL, database, event; contracting party, third party etc.), the value(s) relating to the change (e.g. humidity of 55%), and/or device data. [0235] Data input state updates include data external to the contract being exposed to the logic of the contract to execute updates to the logic and/or state of the contract. Examples of data input that can result in state updates can include receiving API data (e.g. payment made/confirmed, shipping arranged etc.); receiving, retrieving, or detecting a transaction or operation performed on a BDL or data otherwise stored on or a BDL; receiving data from databases, event stores, and other data storage systems; receiving data or communication input from edge computing devices (sensors, actuators, RFID etc.); receiving data from “smart contract” scripts, “oracles”, and the like; receiving inputs from Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Inventory Management (IMS) systems, and other systems/applications; receiving or detecting or receiving input from ‘Event Stream Processing’ (ESP) and ‘Complex Event Processing’ (CEP) events; and/or receiving data or events from analytics platforms/systems and cognitive computing system outputs. [0236] Data output state updates can involve the contract logic executing or otherwise performing or initiating an operation on one or more resources (e.g. a third party system, API, BDL, database, system, application etc.). One variation can include executing some operation through an API such as executing payment with a payment service, updating/reconciling invoices, and/or performing any action through an API. Another variation can include performing some operation on an edge computing device or machine. This may include communicating a machine interpretable instruction. Another variation can include performing a transaction on a BDL or similar system. For example, a transfer of an asset can be performed as a transaction on a BDL. Execution of a transaction. In this variation, a cryptographic hash/UUID from the data structure and/or metadata may be put on, or otherwise added to, the BDL by being referenced in “smart contract” script(s) when compiled to the ledger or executed by invoking ‘on-chain’/‘ion-ledger’ code (depending on the given implementation). Alternatively or in addition, objects from the graph data structure or parameters may be passed to ‘on-chain’/‘ion-ledger’ code. This creates a record between the contract data structure and the transaction(s) on a BDL. In a related BDL variation, data output can include executing pre-existing “smart contract” scripts deployed and invoked to a BDL. For example, this could be used in an implementation where “smart contract” scripts are not compiled from the contract logic. [0255] The cryptographic proof may be stored in the state update to provide an immutable record of the data that interfaced with/input into the contract from certain applicable external sources (e.g. APIs, HTTP clients) and that this data resulted in a given change to the state of the contract. This enables the data that interfaces with the contract to itself be verified, thereby improving the integrity of the post-formation versioning process. [0256] all input data happens, where supported, through a standardized CCN (or similar) where all data packets are ‘Merkelized’, tracked on commit servers, and signed by the original servers. An example would be a web-service or data-service API that output such signed CCN packets, as well as timestamps the packets on its own server. This way the system is independent of traditional certificate infrastructure and solely relie