DETAILED ACTION
Claims 1-18 and 33-34 are presented on 12/31/2024 for examination on merits. Claims 1, 33, and 34 are independent base claims.
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 .
Examiner's Instructions for filing Response to this Office Action
When the Applicant submits amendments regarding to the claims in response the Office Action, the Examiner would appreciate Applicant if a clean copy of the claims is provided to facilitate the prosecution which otherwise requires extra time for editing the marked-up claims from OCR.
Please submit two sets of claims:
Set #1 as in a typical filing which includes indicators for the status of claim and all marked amendments to the claims; and
Set #2 as an appendix to the Arguments/Remarks for a clean version of the claims which has all the markups removed for entry by the Examiner.
Claim Objections
Claims 1, 4-5, 7-8, 18, and 33 are objected to because of the following informalities:
Claim 1 first recites “the system” which appears to refer to the element “a distributed data processing system” in the preamble. However, claim 1 later recites the same element as “the distributed data processing system” in the providing step. For formality reasons, the consistency of recited terms is required. Claims 4-5, 7-8, 18, and 33 also have the same inconsistency issues.
Appropriate correction is 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 and 33-34 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
The rationale for this determination is explained below:
First – following Step 1 of the guidance, claims 1-18 and 33-34 are directed to a method comprising a series of functional steps, or computing device with processor coupled with memory, or non-transitory computer readable medium. Therefore, the claimed invention falls into one of the four statutory categories.
Secondly – following Step 2 of the guidance, claims 1-18 and 33-34 are analyzed for its underlying inventive concept with a new two-prong inquiry (1) does the claim recite an abstract idea, law of nature, or natural phenomenon, and/or judicial exceptions? And (2) does the claim recite additional elements that integrate the judicial exception into a practical application?
It is determined that claimed invention is directed to an abstract idea or at least one of the judicial exceptions, because the concept of the invention is basically a method of generating a specification specifying a consensus process implementation, and the specification is simply identifying the selected process modules for each process stage; the first prone of the inquiry. The idea of generating a specification specifying a consensus process implementation may be concepts performed in the human mind (including an observation, evaluation, judgment, opinion).
Regarding the second prone, the identified additional elements – such as a module database, fail to integrate the idea of “generating a specification specifying a consensus process” into a practical application. Claims 33 and 34 are each like claim 1 in terms of the recited limitations. As such, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Further, the claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Therefore, the claimed invention is abstract without significantly more.
Dependent claims of claim 1 as presented thus far, when analyzed individually or as a whole, are held to be patent ineligible under 35 U.S.C. 101 because, the additional recited limitation(s) fail(s) to amount to “significantly more” than the judicial exception, and thereby non-statutory.
Please see “The 2019 Revised Patent Subject Matter Eligibility Guidance (or “2019 PEG” for short) published in January 2019 at USPTO Website. Note that the groupings of abstract ideas in the 2019 PEG are not the same as those on the Abstract Ideas QRS or in the MPEP. The groupings in the 2019 PEG should be FOLLOWED for identifying abstract ideas. The 2019 PEG does not change the analysis at Step 2B which pertains to an improvement to conventional functioning of a computer or to technological processes; see also MPEP 2106.05(a).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-18 and 33-34 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
The rejection(s) under 35 U.S.C. 112(b) is/are determined by the following reasons:
Claims 2-18 each recite “a method” according to claim 1 directly or indirectly. The recitations are unclear. The Examiner suggests using “the claim” for clarity.
Claims 1 and 33-34 each recite a limitation “the process stage” in the providing and selecting steps unclearly or lacking sufficient antecedent basis.
Dependent claims 14-15 also recite the limitation “the process stage” without sufficient antecedent basis.
Claims 1 and 33-34 each recite an instance of “process modules in the database” without linking to the previously defined instance. As such, the recitation is not clear or lacks sufficient antecedent basis.
Claims 1 and 33-34 each recite “the module” describing “each impact attribute indicating an expected impact of the module” unclearly or lacking sufficient antecedent basis.
Claim 34 recites a limitation “the consensus process” without defining it as a modular consensus process and thus lacking sufficient antecedent basis.
Claim 34 recites a limitation “the distributed data processing system” without defining it and thus lacking sufficient antecedent basis.
Claims 2-18 are also rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, because they depend on the rejected base claim 1.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
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.
Claims 1-9, 18 and 33-34 are rejected under 35 U.S.C. 103 as being unpatentable over Zanpure (US 20210303553 A1; hereinafter “Zanp”) in view of Chapman (US 20180227116 A1; hereinafter “Chap”).
As per claim 1, Zanp teaches a computer-implemented method of implementing a modular consensus process for a distributed data processing system, the consensus process arranged to determine consensus between multiple processing nodes of the system (Zanp, the Abstract and par. 0008-0009: performing adaptive consensus in a distributed ledger network; The consensus node identifies the set of valid transactions in a shortest time when compared with remaining consensus nodes in the adaptively selected set of consensus nodes), the method comprising:
providing a module database storing information defining, for each of a predetermined set of process stages of the consensus process, one or more process modules for use in implementing the process stage (Zanp par. 0022-0023 and 0026: a database of sequential blocks that record state of each transaction in the distributed ledger network 100), …
receiving a set of implementation criteria for the consensus process (Zanp par. 0027-0028: receiving a set of predefined node parameters for the creator node selection unit 214; par. 0035-0036: adaptively selects a set of consensus nodes from the plurality of nodes based on a set of predefined node parameters and a plurality of sensitivity parameters);
selecting, for each of the predetermined process stages of the consensus process, a given one of the process modules for implementing the process stage, the given process module selected based on the impact attributes specified for process modules in the database and the received implementation criteria (Zanp par. 0033-0034: determine a predefined block threshold; A stakeholder may interact with the node 200, via a User Interface (UI) 222. The UI 222 of the node 200 may be displayed on a display 224 of the node 200. The UI 222 may be used by the user to provide the one or more transactions to the node 200. par. 0037-0038: adaptively selecting a set of consensus nodes based on comparing the nodes; performs consensus based on the computed hash value for identifying a set of valid transactions in the unverified blocks); and
generating an implementation specification specifying a consensus process implementation (Zanp par. 0055-0056: using the equation for a consensus process implementation wherein the equation (1) ensures that importance given to the set of predefined node parameters relating to the amount of crypto currency at stake for the node or the amount of crypto currency parked by the node is less compared to importance given to other set of predefined node parameters), the specification identifying the selected process modules for each process stage (par. 0057-0058: the equation (1) identifies or ensures that importance given to the set of predefined node parameters relating to the amount of crypto currency at stake for the node or the amount of crypto currency parked by the node is less compared to importance given to other set of predefined node parameters. See the example for a distributed ledger network with a total of 100 nodes; par. 0059-0066).
However, Zanp does not explicitly disclose any elements specifying impact attributes that may indicate an expected impact of modules on operation of the distributed data processing system with respect to a respective impact dimension This aspect of the claim is identified as a further difference.
In a related art, Chap teaches:
the information specifying, for each process module, one or more impact attributes, each impact attribute indicating an expected impact of the module on operation of the distributed data processing system with respect to a respective impact dimension (par. 0021-0022: monitoring digital event triggers, which are essentially the information specifying a consensus algorithm to use to validate the updated blockchain, such as a protocol to measure agreement of data between different nodes. For example, for system critical data and functionality, the network may implement a higher consensus threshold, for example 95%, to ascertain that the downloaded blockchain is, in fact, valid. For less critical data and functionality, the network node may implement a lower consensus threshold, for example 60%, to ascertain the validity of the downloaded blockchain, for example. The lowered consensus threshold allows a new block added with the updates and appended to the blockchain. It is noted that, in the meantime, the database is updated, and the blockchain is also updated upon execution of the executable code).
Zanp and Chap are analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify Zanp’s system with Chap’s teachings of monitoring digital event triggers and providing the information specifying a consensus algorithm to use to validate the updated blockchain. For this combination, the motivation would have been to improve the operation and execution of smart contracts.
As per claim 2, the references as combined above teach [the] method according to claim 1, comprising:
storing in a code library a plurality of code artefacts, each code artefact for implementing a given process module (Chap, par. 0018-0020: the code library for storing code to implement the condition and the system may automatically update the smart contracts; the library to retrieve the corresponding executable codes; see par. 0005 for a backend code library to allow a system user to generate and deploy smart contracts); and
generating software code based on code artefacts from the library associated with the selected process modules (Chap, par. 0009 and 0016: rendering a graphical user interface (GUI) containing a plurality of contract components and a plurality of document components retrieved from a library database of contract and document components).
As per claim 3, the references as combined above teach [the] method according to claim 2, comprising deploying the generated software code to a target system (Chap, par. 0007-0008 and 0016-0019: deploying a code block in a blockchain; For example, a system user may define a new condition and input an executable code to implement the condition and the system may automatically update the smart contracts library with the new define condition and the corresponding executable code).
As per claim 4, the references as combined above teach [the] method according to claim 1, wherein the implementation criteria comprise information defining a target operating architecture of the distributed data processing system (Chap, par. 0023-0024, 0030, and 0061: The system blockchain may operate as a distributed database that stores data records associated with users and transaction documents, where the data records … may be blocks of data that are hosted on distributed network nodes 111… defining a target operating conditions).
As per claim 5, the references as combined above teach [the] method according to claim 4, wherein the information defining a target operating architecture specifies a network architecture of the distributed data processing system, specifying one or more of (note that optional limitations are recited hereinafter):
a number of sub-networks (Chap, par. 0065: A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements);
numbers of nodes and/or controlling nodes in the network or in one or more sub- networks (Note: the omitted optional limitation).
a tiering architecture arranging sub-networks into a hierarchy (Note: the omitted optional limitation).
As per claim 6, the references as combined above teach [the] method according to claim 1, wherein the implementation criteria comprise one or more input parameters associated with the impact dimensions, the input parameters optionally received from a user via a user interface (Chap, par. 0017: The user interface may provide a graphical template for a system user to generate a text based contract using a plurality of graphical tools also provided by the user interface… selecting or interacting with elements in the user interface; par. 0018: The system may render the one or more conditions and the one or more text documents in the interface. When the user selects the one or more conditions, the system may use the library to retrieve the corresponding executable codes.).
As per claim 7, the references as combined above teach [the] method according to claim 6, wherein the input parameters define context characteristics relating to an operational context of the distributed processing system (Chap, par. 0053-0054: receive a digital event trigger. The digital event trigger, for example, may have been generated by a standalone application or a browser based application running on the network node, wherein the trigger determines that the counter function has reached a certain numerical value; par. 0059-0060: a private equity context. The operational context may be that a predetermined payment due date is passed,).
As per claim 8, the references as combined above teach [the] method according to claim 1, wherein the impact dimensions comprise one or more of (note: optional limitations are recited herein):
at least one performance dimension relating to technical performance of the distributed processing system (Note: the omitted optional limitation);
at least one security dimension relating to security of the distributed processing system (Chap, par. 0035 and 0043: a contract component for an electronic payment transaction may be a condition, such as a required level of security of a network connection);
at least one privacy dimension relating to data privacy for data processed by the distributed processing system (Note: the omitted optional limitation).
As per claim 9, the references as combined above teach [the] method according to claim 1, wherein one or more of the impact dimensions are associated with respective sub-dimensions (Chap, par. 0018: The text based documents may provide further non-executable information (e.g., a glossary) related to the one or more conditions. The system may render the one or more conditions and the one or more text documents in the interface, [while] a system user may define a new condition and input an executable code to implement the condition. Note that a new condition is mapped to the associated sub-dimensions).
As per claim 18, the references as combined above teach [the] method according claim1, wherein the consensus process is arranged to determine consensus between nodes of the distributed data processing system for recording one or more transactions, optionally a block of transactions, in a distributed database of the distributed data processing system, the distributed database optionally comprising a distributed ledger system or blockchain (Chap, par. 0007-0008: deploying a code block in a blockchain comprises: rendering, by a network node, a graphical user interface (GUI) containing a plurality of contract components and a plurality of document components retrieved from a library database of contract and document components; par. 0022-0033: a system blockchain, or a distributed ledger. The system blockchain may operate as a distributed database that stores data records associated with users and transaction documents).
Regarding claims 33 and 34, they each are similar to claim 1 in terms of recited features, respectively; and thus, they are rejected for the same reasons as discussed in claim 1 above
Allowable Subject Matter
Claim 10-17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 10 recites elements of “wherein the selecting step comprises computing a weight for each impact dimension based on the one or more input parameters associated with the impact dimension.” These elements and the features thereof in combination with the other limitations in the claims 1 and 6, are not anticipated by, nor made obvious over the prior art of record.
Claims 11-17 are allowed by virtue of their dependencies on claim 10 directly or indirectly as they each further limit the scope of the claimed invention.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as the prior art additionally discloses certain parts of the claim features (See “PTO-892 Notice of Reference Cited”).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DON ZHAO whose telephone number is (571)272.9953. The examiner can normally be reached on Monday to Friday, 7:30 A.M to 5:00 P.M EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Carl G Colin can be reached on 571.272.3862. The fax phone number for the organization where this application or proceeding is assigned is 571.273.8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800.786.9199 (IN USA OR CANADA) or 571.272.1000.
/Don G Zhao/Primary Examiner, Art Unit 2493 09/10/2026
Prosecution Insights